Bug#1042532: mediawiki: Vendoring a few javascript library without source

[Kunal Mehta]

severity 1042532 normal
tags 1042532 wontfix
thanks

Hi,

On 7/31/23 07:23, roucaries bastien wrote:

hi,
Le lun. 31 juil. 2023 à 08:27, Kunal Mehta  a écrit :

These are in the preferred form for modification so I don't think
there's any issue here, but please correct me if I'm wrong. MediaWiki
often patches these libraries (e.g. jquery.ui) in this format hence IMO
meeting the "preferred form of the work for making modifications to it"
requirement of the GPL.


No https://sources.debian.org/src/mediawiki/1%3A1.39.4-2/resources/lib/pako/
is webpacked in order to be transformed in es5 No source available
before webpack


IANAL, but as I understand it, there are two licenses to consider here: 
pako's MIT license (aka Expat) and MediaWiki's GPL v2 or later license. 
The pako_deflate.es5.js file contains the MIT license 
information/attribution, so we're in compliance for that.


MediaWiki's GPL v2 requires source code to be in "preferred form of the 
work for making modifications to it". In the context of MediaWiki, this 
is in the preferred form, since that's how we plan to (and do) modify 
it. If you want to patch MediaWiki, having the pre-transpiled sources is 
going to be way more work than the source we're providing right now. And 
the proof is that (AFAIK) MediaWiki devs will just patch these sources 
directly, they don't go to the upstream sources, adjust those, and then 
generate a patch. So I don't see a DFSG issue.



And do not stick to lastest jquery is a security problem. Are you sure
you have closed all the CVE ?


The ones that affect MediaWiki, I believe so. Upstream MediaWiki has at 
least one or two jQuery team members as core developers who follow that 
not to mention the Wikimedia Foundation's security team.



with my javascript hat, I believe that working with upstream to
improve the testing (using if needed selenium) will improve the
security of mediawiki by using packaged and up to date js


There is already upstream selenium-based testing, but using the latest 
version of everything isn't always a feature.



In all the case it decrease the burden from a security point of view


No, it really doesn't, it just shifts it elsewhere. The more deviations 
Debian makes, the less we can rely on upstream's QA processes for 
ensuring we're shipping working software, which will more likely slow 
down security updates. Since bundling is permitted by policy, we plan to 
continue doing it.


-- Kunal

Bug#1042532: mediawiki: Vendoring a few javascript library without source

[Kunal Mehta]

Hi,

On 7/29/23 16:44, Bastien Roucariès wrote:

Dear Maintainer,

resources/lib/
(https://sources.debian.org/src/mediawiki/1:1.39.4-2/resources/lib/)

include a few library already packaged for debian.

Moreover some source are missing (I have only checked pako).


These are in the preferred form for modification so I don't think 
there's any issue here, but please correct me if I'm wrong. MediaWiki 
often patches these libraries (e.g. jquery.ui) in this format hence IMO 
meeting the "preferred form of the work for making modifications to it" 
requirement of the GPL.



You could use the packaged library under debian


Older versions of the package did that, but the version mismatches were 
not worth it. Plus MediaWiki has a ton of user-written code that's 
stored and loaded on-wiki, so deviations from the official version are 
incredibly hard to test and just cause breakage everywhere.


-- Kunal

Bug#1041017: fonts-kacst: unclear licensing status, possibly non-free

[Kunal Mehta]

Package: fonts-kacst
Severity: serious
Justification: Policy 2.2.1
X-Debbugs-Cc: lego...@debian.org, kha...@aliftype.com

Khaled Hosny (cc'd) filed a bug against LibreOffice[1], writing:

The last versions of these fonts were prepared by me, over a decade
ago, when I was still believing these are FOSS fonts, but I’m no longer 
sure about their legal status. They disappeared entirely from KACST
website where they were once hosted, and attempts to get in contact
with anyone who knows anything about them failed. They appear to be
clones of other non-free fonts, so the whole thing is shady.

The fonts have since been removed from LibreOffice[2]. Filing as serious
given the questionable licensing.

[1] https://bugs.documentfoundation.org/show_bug.cgi?id=152376
[2] 
https://git.libreoffice.org/core/commit/6d6a2343b1d45695f3ea02818d317a022a7b259f

-- System Information:
Debian Release: 11.7
  APT prefers oldstable-security
  APT policy: (500, 'oldstable-security'), (500, 'oldstable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.35-1.qubes.fc32.x86_64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages fonts-kacst depends on:
ii  dpkg  1.20.12

Versions of packages fonts-kacst recommends:
pn  fonts-kacst-one  

fonts-kacst suggests no packages.

Bug#1039075: mediawiki: missing Breaks+Replaces: mediawiki-extensions-math (<= 2:1.0+git20120528-8)

[Kunal Mehta]

Hi,

On 6/25/23 09:33, Andreas Beckmann wrote:

during a test with piuparts I noticed your package fails to upgrade from
'wheezy' to 'jessie' to 'stretch' to 'buster' to 'bullseye' to 'bookworm'.
It installed fine in 'wheezy', and upgraded to 'jessie', 'stretch',
'buster' and 'bullseye' successfully,
but then the upgrade to 'bookworm' failed,
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.


Ack, thanks for the report. This seems mostly theoretical because the 
mediawiki package was dropped from jessie and had a number of breaking 
changes when it was re-introduced in stretch, so I would've expected 
anyone to have removed the Math package at that point.


In any case, should be trivial to get fixed and I'll see what to do 
about fixing it in bookworm too.


-- Kunal

Bug#1028041: php-excimer: FTBFS on mipsel

[Kunal Mehta]

severity 1028041 normal
thanks

Hi,

On 1/6/23 13:47, Adrian Bunk wrote:

On Fri, Jan 06, 2023 at 08:59:08AM +0100, Paul Gevers wrote:

=
FAILED TEST SUMMARY
-
ExcimerProfiler CPU profile [tests/cpu.phpt]
=

Please fix ASAP to not block the php8.2 transition.


It built after I gave it back to build on the right buildd,
so it's now rebuilt with PHP 8.2.


Thanks.


The issue might depend on buildd speed, or some weird difference
between buildds.


Looking through my email, it's flaked before in the past (#1014801). The 
test in question[1] has the following comment:


// Test aggregateByFunction
// Typically the parent functions foo() and bar() will have self=0 and
// inclusive ~= 30. The other 4 functions will have a count of about 
30/4 = 7.5.
// The probability of C::member() or baz() having a count of zero is 
about 1 in 5600.


Maybe the known flakiness is worse due to something on the mipsel build? 
I'll ask the upstream author. Worst case we can just skip the test on 
mipsel.


I'm lowering the severity because it no longer blocks the 8.2 transition 
(please revert me if I'm wrong on that).


[1] 
https://salsa.debian.org/mediawiki-team/php-excimer/-/blob/master/tests/cpu.phpt


-- Kunal

Bug#1030170: dh-virtualenv: diff for NMU version 1.2.2-1.3

[Kunal Mehta]

Control: tags 1030170 + pending


Dear maintainer,

I've prepared an NMU for dh-virtualenv (versioned as 1.2.2-1.3) and
uploaded it to DELAYED/5. Please feel free to tell me if I
should delay it longer.

Regards.

diff -Nru dh-virtualenv-1.2.2/debian/changelog dh-virtualenv-1.2.2/debian/changelog
--- dh-virtualenv-1.2.2/debian/changelog	2022-08-25 15:01:52.0 -0400
+++ dh-virtualenv-1.2.2/debian/changelog	2023-02-02 14:10:21.0 -0500
@@ -1,3 +1,10 @@
+dh-virtualenv (1.2.2-1.3) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Cherry-pick upstream patch for Python 3.11 support (Closes: #1030170)
+
+ -- Kunal Mehta   Thu, 02 Feb 2023 14:10:21 -0500
+
 dh-virtualenv (1.2.2-1.2) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru dh-virtualenv-1.2.2/debian/patches/0001-Replace-usage-of-inspect.getargspec-with-inspect.get.patch dh-virtualenv-1.2.2/debian/patches/0001-Replace-usage-of-inspect.getargspec-with-inspect.get.patch
--- dh-virtualenv-1.2.2/debian/patches/0001-Replace-usage-of-inspect.getargspec-with-inspect.get.patch	1969-12-31 19:00:00.0 -0500
+++ dh-virtualenv-1.2.2/debian/patches/0001-Replace-usage-of-inspect.getargspec-with-inspect.get.patch	2023-02-02 13:58:02.0 -0500
@@ -0,0 +1,24 @@
+From: Andrew Morgan 
+Date: Tue, 3 Jan 2023 14:29:53 +
+Subject: Replace usage of inspect.getargspec with inspect.getfullargspec
+
+It's debatable whether this check is even still needed, but for now
+let's do the simple thing and update it to be compatible with modern
+Python versions.
+---
+ bin/dh_virtualenv | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/bin/dh_virtualenv b/bin/dh_virtualenv
+index 8bafbcf..0a422ad 100755
+--- a/bin/dh_virtualenv
 b/bin/dh_virtualenv
+@@ -57,7 +57,7 @@ def main():
+ # passed the packages keyword argument. Newer (like Ubuntu
+ # Precise) expect the whole options to be passed.
+ 
+-arguments = inspect.getargspec(DebHelper.__init__).args
++arguments = inspect.getfullargspec(DebHelper.__init__).args
+ if 'packages' in arguments:
+ dh = DebHelper(packages=options.package or None)
+ else:
diff -Nru dh-virtualenv-1.2.2/debian/patches/series dh-virtualenv-1.2.2/debian/patches/series
--- dh-virtualenv-1.2.2/debian/patches/series	1969-12-31 19:00:00.0 -0500
+++ dh-virtualenv-1.2.2/debian/patches/series	2023-02-02 13:58:02.0 -0500
@@ -0,0 +1 @@
+0001-Replace-usage-of-inspect.getargspec-with-inspect.get.patch

Bug#1030170: dh-virtualenv: Broken on Python 3.11, AttributeError: module 'inspect' has no attribute 'getargspec'

[Kunal Mehta]

Package: dh-virtualenv
Version: 1.2.2-1.2
Severity: grave
Tags: patch
Justification: renders package unusable
X-Debbugs-Cc: lego...@debian.org

Hi,

Using dh-virtualenv with bookworm's Python 3.11 breaks:

Traceback (most recent call last):
  File "/usr/bin/dh_virtualenv", line 111, in 
sys.exit(main() or 0)
 ^^
  File "/usr/bin/dh_virtualenv", line 60, in main
arguments = inspect.getargspec(DebHelper.__init__).args
^^
AttributeError: module 'inspect' has no attribute 'getargspec'. Did you mean: 
'getargs'?

This was fixed upstream last month: 
.

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

Kernel: Linux 5.15.81-1.fc32.qubes.x86_64 (SMP w/4 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages dh-virtualenv depends on:
ii  libjs-sphinxdoc   3.4.3-2
ii  perl  5.32.1-4+deb11u2
ii  python3   3.9.2-3
pn  sphinx-rtd-theme-common   
pn  virtualenv | python3-virtualenv | python3.9-venv  

dh-virtualenv recommends no packages.

dh-virtualenv suggests no packages.

Bug#1027565: kiwix-tools: FTBFS: ld: /usr/lib/x86_64-linux-gnu/libkiwix.so: undefined reference to `zim::Item::getPath[abi:cxx11]() const'

[Kunal Mehta]

Hi,

On 1/1/23 06:31, Lucas Nussbaum wrote:

/usr/bin/ld: /usr/lib/x86_64-linux-gnu/libkiwix.so: undefined reference to 
`zim::Item::getPath[abi:cxx11]() const'
collect2: error: ld returned 1 exit status


My upload of src:zimlib 8.1.0 accidentally contained a breaking change, 
but this should be fixed when the libkiwix transition completes, see 
#1027959.


Thanks,
-- Kunal / Legoktm

Bug#1023251: pdf-redact-tools: Unusable since imagemagick disabled PDF support by default, unmaintained upstream

[Kunal Mehta]

Hi,

On 11/1/22 01:36, intrigeri wrote:

So I think this package should not be included in Bookworm,
hence the RC severity.


I didn't realize it wasn't working anymore, but agreed even without that 
solely because it's unmaintained upstream and I personally no longer use 
it. Will file an RM shortly.


-- Kunal

Bug#1016265: libkiwix: FTBFS: version.h:29:2: error: #warning The C++ ABI version of compiler you are using does not exactly match [-Werror=cpp]

[Kunal Mehta]

forcemerge 1012981 1016265
thanks


On 7/29/22 12:21, Lucas Nussbaum wrote:

/usr/include/xapian/version.h:29:2: error: #warning The C++ ABI version of 
compiler you are using does not exactly match [-Werror=cpp]
29 | #warning The C++ ABI version of compiler you are using does not 
exactly match
   |  ^~~


This has been fixed in experimental after being originally reported as 
#1012981.


Thanks,
-- Kunal

Bug#1012981: libkiwix: ftbfs with GCC-12

[Kunal Mehta]

Hi,

On 6/16/22 08:11, Matthias Klose wrote:

In file included from /usr/include/xapian.h:44,
  from ../src/library.cpp:35:
/usr/include/xapian/version.h:29:2: error: #warning The C++ ABI version of 
compiler you are using does not exactly match [-Werror=cpp]
29 | #warning The C++ ABI version of compiler you are using does not 
exactly match
   |  ^~~
/usr/include/xapian/version.h:30:2: error: #warning that of the compiler used 
to build the library. If linking fails [-Werror=cpp]
30 | #warning that of the compiler used to build the library. If linking 
fails
   |  ^~~
/usr/include/xapian/version.h:31:2: error: #warning due to missing symbols, 
this is probably the reason why. [-Werror=cpp]
31 | #warning due to missing symbols, this is probably the reason why.
   |  ^~~
/usr/include/xapian/version.h:32:2: error: #warning The Xapian library was 
built with g++ 11.2.0 [-Werror=cpp]
32 | #warning The Xapian library was built with g++ 11.2.0
   |  ^~~
cc1plus: all warnings being treated as errors


This happens every GCC bump, so I think rather than asking for a binNMU 
of xapian we can just turn off -Werror in the libkiwix build.


-- Kunal

Bug#997383: dh-virtualenv: FTBFS: AttributeError: 'Sphinx' object has no attribute 'add_stylesheet'

[Kunal Mehta]

severity 997383 minor
tags 997383 fixed-upstream
thanks

Hi,

On Sat, 23 Oct 2021 21:49:56 +0200 Lucas Nussbaum  wrote:

> Exception occurred:
>   File "/<>/doc/conf.py", line 30, in setup
> app.add_stylesheet('css/custom.css')
> AttributeError: 'Sphinx' object has no attribute 'add_stylesheet'
> The full traceback has been saved in /tmp/sphinx-err-qj3dzcul.log, if you 
want to report the issue to the developers.
> Please also report this if it was a user error, so that a better error 
message can be provided next time.
> A bug report can be filed in the tracker at 
. Thanks!
> make[1]: *** [debian/rules:28: override_dh_installdocs] Error 1


From what I can tell, the add_stylesheet removal was delayed upstream 
and as a result dh-virtualenv no longer FTBFS in sid, so I'm downgrading 
the severity to minor.


Fixing the deprecation warning should be as simple as cherry-picking 
, 
which I can do as a NMU if that's wanted.


-- Kunal

Bug#1003432: php-wmerrors: Incompatible with PHP 8.1

[Kunal Mehta]

Package: php-wmerrors
Version: 2.0.0~git20190628.183ef7d-3
Severity: serious
Tags: ftbfs upstream
Justification: ftbfs
X-Debbugs-Cc: lego...@debian.org

wmerrors is currently incompatible with PHP 8.1.

https://phabricator.wikimedia.org/T298421 tracks this upstream and I'm
working on a patch there.


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

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

Versions of packages php-wmerrors depends on:
ii  libc62.31-13+deb11u2
pn  php | php-cli
ii  php-common   2:76
ii  php7.4-cli [phpapi-20190902] 7.4.25-1+deb11u1
ii  php7.4-phpdbg [phpapi-20190902]  7.4.25-1+deb11u1

php-wmerrors recommends no packages.

php-wmerrors suggests no packages.

Bug#997440: python-libzim: FTBFS: dpkg-buildpackage: error: dpkg-source -b . subprocess returned exit status 2

[Kunal Mehta]

Hi,

Sorry, it took me a while to figure this one out.

On 10/23/21 13:27, Lucas Nussbaum wrote:


dh clean --with python3 --buildsystem=pybuild
dh_auto_clean -O--buildsystem=pybuild
I: pybuild base:232: python3.9 setup.py clean
[!] Warning: Couldn't find zim/*.h in ./include!
 Hint: You can install them from source from 
https://github.com/openzim/libzim
   or download a prebuilt release's headers into ./include/zim/*.h
   (or set CFLAGS='-I/include')
Compiling libzim/wrapper.pyx because it depends on 
/usr/lib/python3/dist-packages/Cython/Includes/libcpp/string.pxd.
[1/1] Cythonizing libzim/wrapper.pyx


This seems to be the issue, it is running Cython during the clean step, 
which dirties source tree, ironic. I codesearched and found that other 
packages modify setup.py to skip cythonize during clean and other steps, 
e.g. https://github.com/Unidata/cftime/issues/91. Will work on a patch 
for this and upstream it.


-- Kunal

Bug#975994: zimlib breaks python-libzim autopkgtest: segfaults

[Kunal Mehta]

Hi,

On 11/30/20 11:25 AM, Paul Gevers wrote:

That versioned Depends relation should be enough for CI. But what about
users that do a partial upgrade? (Yes, I know, officially not supported
in Debian, but in practice it works pretty well).


Good point. I'll do that as well.

-- Kunal

Bug#975994: zimlib breaks python-libzim autopkgtest: segfaults

[Kunal Mehta]

Control: reassign -1 python-libzim

Hi Paul,

On 11/27/20 12:11 PM, Paul Gevers wrote:

Currently this regression is blocking the migration of zimlib to testing
[1]. Due to the nature of this issue, I filed this bug report against
both packages. Can you please investigate the situation and reassign the
bug to the right package?


I filed this upstream: 
, it's likely 
there's some issue in the latest zimlib update, but it's probably 
easiest if we just rebuild python-libzim in the meantime to unblock the 
whole kiwix stack. I'll leave the upstream ticket open to make sure this 
doesn't happen for future updates.


So I plan to close this bug with an upload of python-libzim 0.0.3-2 that 
depends on libzim-dev >= 6.3.0. Will that be enough for the CI system or 
do I also need to have zimlib Break the older python-libzim versions?


Thanks,
-- Kunal

Bug#970896: lintian times out while analyzing package

[Kunal Mehta]

Package: lintian
Version: 2.95.0~bpo10+1
Severity: serious
Justification: fails to run properly

Trying to run lintian locally against src:mediawiki 1:1.35.0~rc.3-1 never
completed, I ^C'd the lintian command after 3+ hours.

A salsa CI run against a slightly older mediawiki package also failed
because it took more than an hour to run:
.

I don't know how to figure out if there's an infinite loop somewhere or
something specific to the size of mediawiki is causing problems, but I
really don't expect lintian to take this long.

Thanks,
-- Kunal

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

Kernel: Linux 4.19.132-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)

Versions of packages lintian depends on:
ii  binutils2.31.1-16
ii  bzip2   1.0.6-9.2~deb10u1
ii  diffstat1.62-1
ii  dpkg1.19.7
ii  dpkg-dev1.19.7
ii  file1:5.35-4+deb10u1
ii  gettext 0.19.8.1-9
ii  gpg 2.2.12-1+deb10u1
ii  intltool-debian 0.35.0+20060710.5
ii  libapt-pkg-perl 0.1.34+b1
ii  libarchive-zip-perl 1.64-1
ii  libcapture-tiny-perl0.48-1
ii  libclass-xsaccessor-perl1.19-3+b2
ii  libclone-perl   0.41-1+b1
ii  libconfig-tiny-perl 2.23-1
ii  libcpanel-json-xs-perl  4.09-1
ii  libdata-dpath-perl  0.57-2
ii  libdata-validate-domain-perl0.10-1
ii  libdevel-size-perl  0.82-1+b1
ii  libdpkg-perl1.19.7
ii  libemail-address-xs-perl1.04-1+b1
ii  libfile-basedir-perl0.08-1
ii  libfile-find-rule-perl  0.34-1
ii  libfont-ttf-perl1.06-1
ii  libhtml-html5-entities-perl 0.004-1
ii  libipc-run3-perl0.048-1
ii  libjson-maybexs-perl1.004000-1
ii  liblist-compare-perl0.53-1
ii  liblist-moreutils-perl  0.416-1+b4
ii  liblist-utilsby-perl0.11-1
ii  libmoo-perl 2.003004-2
ii  libmoox-aliases-perl0.001006-1
ii  libnamespace-clean-perl 0.27-1
ii  libpath-tiny-perl   0.108-1
ii  libperlio-gzip-perl 0.19-1+b5
ii  libproc-processtable-perl   0.56-1
ii  libsereal-decoder-perl  4.005+ds-1+b1
ii  libsereal-encoder-perl  4.005+ds-1+b1
ii  libtext-glob-perl   0.10-1
ii  libtext-levenshteinxs-perl  0.03-4+b6
ii  libtext-markdown-discount-perl  0.11-3+b1
ii  libtext-xslate-perl 3.5.6-1+b1
ii  libtime-duration-perl   1.20-1
ii  libtime-moment-perl 0.44-1+b1
ii  libtimedate-perl2.3000-2+deb10u1
ii  libtry-tiny-perl0.30-1
ii  libtype-tiny-perl   1.004004-1
ii  libunicode-utf8-perl0.62-1
ii  liburi-perl 1.76-1
ii  libxml-libxml-perl  2.0134+dfsg-1
ii  libyaml-libyaml-perl0.76+repack-1
ii  lzip1.21-3
ii  lzop1.03-4+b1
ii  man-db  2.8.5-2
ii  patchutils  0.3.4-2
ii  perl [libdigest-sha-perl]   5.28.1-6+deb10u1
ii  t1utils 1.41-3
ii  unzip   6.0-23+deb10u1
ii  xz-utils5.2.4-1

lintian recommends no packages.

Versions of packages lintian suggests:
pn  binutils-multiarch 
pn  libtext-template-perl  

-- no debconf information

Bug#957147: docopt.cpp: diff for NMU version 0.6.2-2.1

[Kunal Mehta]

Control: tags 957147 + patch
Control: tags 957147 + pending

Dear maintainer,

I've prepared an NMU for docopt.cpp (versioned as 0.6.2-2.1) and
uploaded it to DELAYED/5. Please feel free to tell me if I
should delay it longer.

Regards.

diff -Nru docopt.cpp-0.6.2/debian/changelog docopt.cpp-0.6.2/debian/changelog
--- docopt.cpp-0.6.2/debian/changelog	2017-04-21 00:54:33.0 -0700
+++ docopt.cpp-0.6.2/debian/changelog	2020-07-24 22:34:42.0 -0700
@@ -1,3 +1,10 @@
+docopt.cpp (0.6.2-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Add upstream patch to fix compilation with GCC 10 (Closes: #957147)
+
+ -- Kunal Mehta   Fri, 24 Jul 2020 22:34:42 -0700
+
 docopt.cpp (0.6.2-2) unstable; urgency=medium
 
   * Switch from git-dpm to gbp
diff -Nru docopt.cpp-0.6.2/debian/patches/0003-Add-missing-stdexcept-include-to-use-std-runtime_err.patch docopt.cpp-0.6.2/debian/patches/0003-Add-missing-stdexcept-include-to-use-std-runtime_err.patch
--- docopt.cpp-0.6.2/debian/patches/0003-Add-missing-stdexcept-include-to-use-std-runtime_err.patch	1969-12-31 16:00:00.0 -0800
+++ docopt.cpp-0.6.2/debian/patches/0003-Add-missing-stdexcept-include-to-use-std-runtime_err.patch	2020-07-24 22:34:42.0 -0700
@@ -0,0 +1,21 @@
+From: Cheney-Wang 
+Date: Wed, 31 Oct 2018 19:21:26 -0700
+Subject: Add missing  include to use std::runtime_error
+
+Origin: https://github.com/docopt/docopt.cpp/commit/72a8e3e01effe22ac0f4e29c14153743172efcb5
+---
+ docopt_value.h | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/docopt_value.h b/docopt_value.h
+index a923219..829ee55 100644
+--- a/docopt_value.h
 b/docopt_value.h
+@@ -9,6 +9,7 @@
+ #ifndef docopt__value_h_
+ #define docopt__value_h_
+ 
++#include 
+ #include 
+ #include 
+ #include  // std::hash
diff -Nru docopt.cpp-0.6.2/debian/patches/series docopt.cpp-0.6.2/debian/patches/series
--- docopt.cpp-0.6.2/debian/patches/series	2017-04-21 00:54:33.0 -0700
+++ docopt.cpp-0.6.2/debian/patches/series	2020-07-24 22:34:42.0 -0700
@@ -1,2 +1,3 @@
 Set-versioning-properties.patch
 Make-tests-compatible-with-Python-3.patch
+0003-Add-missing-stdexcept-include-to-use-std-runtime_err.patch

Bug#965033: debdiff

[Kunal Mehta]

I'm happy to NMU this since it's affecting some of my packages (zimlib,
libkiwix, zim-tools, etc.). debdiff is attached.

It's not clear to me why the dependency was commented out in the first
place, but it fixes the immediate issue. Let me know if that's OK and if
you'd like me to go ahead.

-- Kunal


diff -Nru meson-0.55.0/debian/changelog meson-0.55.0/debian/changelog
--- meson-0.55.0/debian/changelog   2020-07-12 07:29:15.0 -0700
+++ meson-0.55.0/debian/changelog   2020-07-15 15:48:39.0 -0700
@@ -1,3 +1,10 @@
+meson (0.55.0-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Add missing dependency on python3-pkg-resources Closes: #965033.
+
+ -- Kunal Mehta   Wed, 15 Jul 2020 15:48:39 -0700
+
 meson (0.55.0-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru meson-0.55.0/debian/control meson-0.55.0/debian/control
--- meson-0.55.0/debian/control 2020-07-12 07:29:07.0 -0700
+++ meson-0.55.0/debian/control 2020-07-15 15:48:37.0 -0700
@@ -94,7 +94,7 @@
  ${misc:Depends},
  ${python3:Depends},
  ninja-build(>=1.6),
-# python3-pkg-resources,
+ python3-pkg-resources,
 Description: high-productivity build system
  Meson is a build system designed to increase programmer
  productivity. It does this by providing a fast, simple and easy to

Bug#964495: libmicrohttpd: New 0.97.1-1 version causes libkiwix to FTBFS

[Kunal Mehta]

On 2020-07-07 17:54, Kunal Mehta wrote:
> Upstream libkiwix ticket discussing the issue is
> https://github.com/kiwix/kiwix-lib/issues/373, but I (and upstream) believe
> this is an unexexpected breaking change in libmicrohttpd.

According to
<https://lists.gnu.org/archive/html/libmicrohttpd/2020-07/msg00011.html>
upstream didn't realize it would break C++ users when making the change.

In any case, libkiwix upstream has a patch to fix this, which I'll
upload shortly and close this bug with since there don't seem to be any
other reports of broken packages.

-- Kunal

Bug#964495: libmicrohttpd: New 0.97.1-1 version causes libkiwix to FTBFS

[Kunal Mehta]

Package: libmicrohttpd
Version: 0.97.1-1
Severity: serious
Tags: ftbfs

The new 0.97.1 version is causing libkiwix to FTBFS.

[12/51] c++ -Isrc/25a6634@@kiwix@sha -Isrc -I../src -Iinclude -I../include 
-I/usr/include/kainjow -Istatic -I/usr/include/x86_64-linux-gnu 
-I/usr/include/p11-kit-1 -fdiagnostics-color=always -pipe 
-D_FILE_OFFSET_BITS=64 -Werror -std=c++11 -g -O2 
-fdebug-prefix-map=/build/libkiwix-9.3.0+dfsg=. -fstack-protector-strong 
-Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -pthread 
-MD -MQ 'src/25a6634@@kiwix@sha/server.cpp.o' -MF 
'src/25a6634@@kiwix@sha/server.cpp.o.d' -o 
'src/25a6634@@kiwix@sha/server.cpp.o' -c ../src/server.cpp
FAILED: src/25a6634@@kiwix@sha/server.cpp.o 
c++ -Isrc/25a6634@@kiwix@sha -Isrc -I../src -Iinclude -I../include 
-I/usr/include/kainjow -Istatic -I/usr/include/x86_64-linux-gnu 
-I/usr/include/p11-kit-1 -fdiagnostics-color=always -pipe 
-D_FILE_OFFSET_BITS=64 -Werror -std=c++11 -g -O2 
-fdebug-prefix-map=/build/libkiwix-9.3.0+dfsg=. -fstack-protector-strong 
-Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -pthread 
-MD -MQ 'src/25a6634@@kiwix@sha/server.cpp.o' -MF 
'src/25a6634@@kiwix@sha/server.cpp.o.d' -o 
'src/25a6634@@kiwix@sha/server.cpp.o' -c ../src/server.cpp
../src/server.cpp: In member function ‘bool kiwix::InternalServer::start()’:
../src/server.cpp:248:29: error: invalid conversion from ‘int (*)(void*, 
MHD_Connection*, const char*, const char*, const char*, const char*, size_t*, 
void**)’ {aka ‘int (*)(void*, MHD_Connection*, const char*, const char*, const 
char*, const char*, long unsigned int*, void**)’} to 
‘MHD_AccessHandlerCallback’ {aka ‘MHD_Result (*)(void*, MHD_Connection*, const 
char*, const char*, const char*, const char*, long unsigned int*, void**)’} 
[-fpermissive]
  248 | ,
  | ^~
  | |
  | int (*)(void*, MHD_Connection*, const 
char*, const char*, const char*, const char*, size_t*, void**) {aka int 
(*)(void*, MHD_Connection*, const char*, const char*, const char*, const char*, 
long unsigned int*, void**)}
In file included from ../src/server.cpp:39:
/usr/include/microhttpd.h:2428:45: note:   initializing argument 5 of 
‘MHD_Daemon* MHD_start_daemon(unsigned int, uint16_t, MHD_AcceptPolicyCallback, 
void*, MHD_AccessHandlerCallback, void*, ...)’
 2428 |   MHD_AccessHandlerCallback dh, void *dh_cls,
  |   ~~^~


Upstream libkiwix ticket discussing the issue is
https://github.com/kiwix/kiwix-lib/issues/373, but I (and upstream) believe
this is an unexexpected breaking change in libmicrohttpd.

-- Kunal

Bug#924858: also can't reproduce

[Kunal Mehta]

While working on #925068, I built the version of doxygen in buster
multiple times, and was unable to reproduce any build failures.

-- Kunal



signature.asc
Description: OpenPGP digital signature

Bug#909752: #909752 fixed in git but not uploaded

[Kunal Mehta]

control: tags -1 pending

Hi Ondřej,

It looks like you fixed this #909752 in git back in November[1], but it
was never uploaded to the archive. Is there anything blocking its upload?

[1]
https://salsa.debian.org/php-team/pecl/php-apcu-bc/commit/a4c7df39a4775cbf2988bb97bb07153ffbdb5f9e

Thanks,
-- Kunal



signature.asc
Description: OpenPGP digital signature

Bug#911832: polyfill should be dropped

[Kunal Mehta]

Hi,

On 1/3/19 6:57 PM, David Prévot wrote:
> Le 04/01/2019 à 12:50, Kunal Mehta a écrit :
>> This patch adds overrides for all symfony/polyfill-* packages to
>> pkg-php-tools itself, so all packages will automatically use it and no
>> longer automatically depend upon php-symfony-polyfill-* (and will cover
>> all current dependencies).
> 
> Overrides can be added “locally” (for the build, in
> debian/pkg-php-tools-overrides, see e.g. twig). Anyway, this is not the
> only needed step, see below.

Right. Are you saying you'd rather have the overrides in the individual
packages instead of in pkg-php-tools? I'm happy to prepare patches (and
NMUs if necessary) either way, but I think we still need a pkg-php-tools
patch to support dropping the version constraint, which is included in
my current merge request.

>> And this one drops php-symfony-polyfill-* build deps that I don't see
>> why they were required in the first place.
> 
> You also (rightfully) changed the autoload files. It’s not “just” a
> matter of removing the (build-)dependencies.

Ack, I just wrote the commit message before I realized those also needed
to be removed.

-- Kunal



signature.asc
Description: OpenPGP digital signature

Bug#911832: polyfill should be dropped

[Kunal Mehta]

On 1/2/19 11:57 PM, Kunal Mehta wrote:
> I'm not sure how exactly the best way to remove the dependency is since
> it's automatically generated from composer.json. We could update
> pkg-php-tools to modify php-symfony-polyfill-* dependencies?

https://salsa.debian.org/php-team/pear/pkg-php-tools/merge_requests/1

This patch adds overrides for all symfony/polyfill-* packages to
pkg-php-tools itself, so all packages will automatically use it and no
longer automatically depend upon php-symfony-polyfill-* (and will cover
all current dependencies).

https://salsa.debian.org/php-team/pear/symfony/merge_requests/1

And this one drops php-symfony-polyfill-* build deps that I don't see
why they were required in the first place.

-- Kunal



signature.asc
Description: OpenPGP digital signature

Bug#911832: polyfill should be dropped

[Kunal Mehta]

Hi,

First, I filed  upstream
about the test failures.

However, as I looked a bit more, I'm not sure why this package exists in
Debian in the first place. The purpose of the polyfill is to have pure
PHP fallback implementations for when the PHP install is missing an
extension or on an older version. But neither of those apply to Debian
where we can just depend on the PHP extension itself.

For example, instead of depending upon php-symfony-polyfill-mbstring,
the package should depend upon php-mbstring. All of the
php-symfony-polyfill-php* packages are useless since we're already
providing PHP 7.3.

The vast majority of dependencies are in src:symfony, so it shouldn't be
too difficult to remove:

km@km-pt:~$ reverse-depends src:php-symfony-polyfill
Reverse-Depends
===
* civicrm-common(for php-symfony-polyfill-iconv)
* php-respect-validation(for php-symfony-polyfill-mbstring)
* php-symfony   (for php-symfony-polyfill-php56)
* php-symfony   (for php-symfony-polyfill-ctype)
* php-symfony   (for php-symfony-polyfill-apcu)
* php-symfony   (for php-symfony-polyfill-mbstring)
* php-symfony   (for php-symfony-polyfill-php70)
* php-symfony   (for php-symfony-polyfill-intl-icu)
* php-symfony-cache (for php-symfony-polyfill-apcu)
* php-symfony-config(for php-symfony-polyfill-ctype)
* php-symfony-console   (for php-symfony-polyfill-mbstring)
* php-symfony-doctrine-bridge   (for php-symfony-polyfill-ctype)
* php-symfony-doctrine-bridge   (for php-symfony-polyfill-mbstring)
* php-symfony-dom-crawler   (for php-symfony-polyfill-ctype)
* php-symfony-dom-crawler   (for php-symfony-polyfill-mbstring)
* php-symfony-filesystem(for php-symfony-polyfill-ctype)
* php-symfony-form  (for php-symfony-polyfill-ctype)
* php-symfony-form  (for php-symfony-polyfill-mbstring)
* php-symfony-framework-bundle  (for php-symfony-polyfill-mbstring)
* php-symfony-http-foundation   (for php-symfony-polyfill-php70)
* php-symfony-http-foundation   (for php-symfony-polyfill-mbstring)
* php-symfony-http-kernel   (for php-symfony-polyfill-ctype)
* php-symfony-inflector (for php-symfony-polyfill-ctype)
* php-symfony-intl  (for php-symfony-polyfill-intl-icu)
* php-symfony-ldap  (for php-symfony-polyfill-php56)
* php-symfony-lock  (for php-symfony-polyfill-php70)
* php-symfony-property-access   (for php-symfony-polyfill-php70)
* php-symfony-security  (for php-symfony-polyfill-php70)
* php-symfony-security  (for php-symfony-polyfill-php56)
* php-symfony-security-bundle   (for php-symfony-polyfill-php70)
* php-symfony-security-core (for php-symfony-polyfill-php56)
* php-symfony-security-csrf (for php-symfony-polyfill-php56)
* php-symfony-security-csrf (for php-symfony-polyfill-php70)
* php-symfony-security-http (for php-symfony-polyfill-php56)
* php-symfony-security-http (for php-symfony-polyfill-php70)
* php-symfony-serializer(for php-symfony-polyfill-ctype)
* php-symfony-templating(for php-symfony-polyfill-ctype)
* php-symfony-translation   (for php-symfony-polyfill-mbstring)
* php-symfony-twig-bundle   (for php-symfony-polyfill-ctype)
* php-symfony-validator (for php-symfony-polyfill-mbstring)
* php-symfony-validator (for php-symfony-polyfill-ctype)
* php-symfony-var-dumper(for php-symfony-polyfill-mbstring)
* php-symfony-web-profiler-bundle  (for php-symfony-polyfill-php70)
* php-symfony-web-server-bundle  (for php-symfony-polyfill-ctype)
* php-symfony-yaml  (for php-symfony-polyfill-ctype)
* php-webmozart-assert  (for php-symfony-polyfill-ctype)

I'm not sure how exactly the best way to remove the dependency is since
it's automatically generated from composer.json. We could update
pkg-php-tools to modify php-symfony-polyfill-* dependencies?

HTH,
-- Kunal



signature.asc
Description: OpenPGP digital signature

Bug#913620: Happened before in #905187

[Kunal Mehta]

This is the same regression as #905187 - is there a good way we can
prevent this from happening again?

HTH,
-- Kunal



signature.asc
Description: OpenPGP digital signature

Bug#911460: upstream

[Kunal Mehta]

control: tags -1 upstream

This is being worked on upstream at .

Bug#909110: serious

[Kunal Mehta]

Hi,

On 10/14/18 11:45 PM, Ondřej Surý wrote:
> Version: 7.3.0~rc2-2
> 
> This had been already fixed in version in both unstable and testing.

That's not what I see...

$ php -v
PHP 7.3.0RC2 (cli) (built: Oct 14 2018 10:21:01) ( NTS )
Copyright (c) 1997-2018 The PHP Group
Zend Engine v3.3.0-dev, Copyright (c) 1998-2018 Zend Technologies
with Zend OPcache v7.3.0RC2, Copyright (c) 1999-2018, by Zend
Technologies
$ dpkg -l | grep php7.3-dev
ii  php7.3-dev 7.3.0~rc2-2+b1
 amd64Files for PHP7.3 module development

$ phpize7.3
Configuring for:
PHP Api Version: 20180731
Zend Module Api No:  20180731
Zend Extension Api No:   320180731
cp: cannot stat 'run-tests*.phpL': No such file or directory

Looking at the file directly, I can see the L:
$ grep "\"L" /usr/bin/phpize7.3
FILES="acinclude.m4 Makefile.global config.sub config.guess ltmain.sh
run-tests*.php"L


Am I missing something?

-- Kunal

Bug#897732: patches

[Kunal Mehta]

tags 897732 patch
thanks

Hi,

Attached is a series of patches to make this package build with gcc-8:

1. Fix invalid gbp.conf so `gbp buildpackage` can actually run.
2. Update the symbols file to remove the symbol that no longer exists in
gcc-8.
3. Update changelog for NMU.

I can't upload this myself, so feel free to take any parts of these
patches to make the package build again, or just upload my series of
patches as is.

Thanks!
-- Kunal

From 943ce8a954f2ba959cbadeda0fc9dc9b0a0fefcc Mon Sep 17 00:00:00 2001
From: Kunal Mehta 
Date: Sat, 21 Jul 2018 01:54:06 +0200
Subject: [PATCH 1/3] Fix invalid gbp.conf

---
 debian/gbp.conf | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/debian/gbp.conf b/debian/gbp.conf
index fc366af..1ef1248 100644
--- a/debian/gbp.conf
+++ b/debian/gbp.conf
@@ -1,7 +1,6 @@
 # Configuration file for git-buildpackage and friends
 [git-import-orig]
-filter = .gitignore
-filter = debian/
+filter = [ '.gitignore', 'debian/' ]
 
 [DEFAULT]
 pristine-tar = True
-- 
2.17.1

From 0f16dff1fea9c9e144946a6b4fb663a38d25a2c3 Mon Sep 17 00:00:00 2001
From: Kunal Mehta 
Date: Sat, 21 Jul 2018 01:59:29 +0200
Subject: [PATCH 2/3] Update symbols for gcc-8

Closes: #897732
---
 debian/libctpp2-2v5.symbols | 1 -
 1 file changed, 1 deletion(-)

diff --git a/debian/libctpp2-2v5.symbols b/debian/libctpp2-2v5.symbols
index 9507b84..b6e8190 100644
--- a/debian/libctpp2-2v5.symbols
+++ b/debian/libctpp2-2v5.symbols
@@ -1305,7 +1305,6 @@ libctpp2.so.2 libctpp2-2v5 #MINVER#
  (optional=templinst|arch=alpha amd64 arm64 armel armhf hppa hurd-i386 i386 kfreebsd-amd64 kfreebsd-i386 m68k mips mips64el mipsel powerpc powerpcspe ppc64 ppc64el s390x sh4 sparc64)_ZNSt8_Rb_treeINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESt4pairIKS5_N4CTPP3CDTEESt10_Select1stISA_ESt4lessIS5_ESaISA_EE7_M_copyINSG_11_Alloc_nodeEEEPSt13_Rb_tree_nodeISA_EPKSK_PSt18_Rb_tree_node_baseRT_@Base 2.8.3
  (arch=!alpha !amd64 !arm64 !armel !armhf !hppa !hurd-i386 !i386 !kfreebsd-amd64 !kfreebsd-i386 !m68k !mips !mips64el !mipsel !powerpc !powerpcspe !ppc64 !ppc64el !s390x !sh4 !sparc64)_ZNSt8_Rb_treeINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESt4pairIKS5_N4CTPP3CDTEESt10_Select1stISA_ESt4lessIS5_ESaISA_EE7_M_copyINSG_11_Alloc_nodeEEEPSt13_Rb_tree_nodeISA_EPKSK_SL_RT_@Base 2.8.3
  _ZNSt8_Rb_treeINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESt4pairIKS5_N4CTPP3CDTEESt10_Select1stISA_ESt4lessIS5_ESaISA_EE8_M_eraseEPSt13_Rb_tree_nodeISA_E@Base 2.8.3
- (arch=!armel !armhf !hurd-i386 !i386 !kfreebsd-i386 !mips !mipsel !powerpc)_ZNSt8_Rb_treeINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESt4pairIKS5_PvESt10_Select1stIS9_ESt4lessIS5_ESaIS9_EE24_M_get_insert_unique_posERS7_@Base 2.8.3
  _ZNSt8_Rb_treeINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESt4pairIKS5_PvESt10_Select1stIS9_ESt4lessIS5_ESaIS9_EE8_M_eraseEPSt13_Rb_tree_nodeIS9_E@Base 2.8.3
  (arch=!alpha !amd64 !arm64 !armel !armhf !hppa !hurd-i386 !i386 !kfreebsd-amd64 !kfreebsd-i386 !m68k !mips !mips64el !mipsel !powerpc !powerpcspe !ppc64 !ppc64el !s390x !sh4 !sparc64)_ZNSt8_Rb_treeINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESt4pairIKS5_S5_ESt10_Select1stIS8_ESt4lessIS5_ESaIS8_EE7_M_copyINSE_11_Alloc_nodeEEEPSt13_Rb_tree_nodeIS8_EPKSI_SJ_RT_@Base 2.8.3
  _ZNSt8_Rb_treeINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESt4pairIKS5_S5_ESt10_Select1stIS8_ESt4lessIS5_ESaIS8_EE8_M_eraseEPSt13_Rb_tree_nodeIS8_E@Base 2.8.3
-- 
2.17.1

From 94a19cf551abd836561faeb54b85b9dd68d88d28 Mon Sep 17 00:00:00 2001
From: Kunal Mehta 
Date: Sat, 21 Jul 2018 02:08:04 +0200
Subject: [PATCH 3/3] Update changelog

---
 debian/changelog | 8 
 1 file changed, 8 insertions(+)

diff --git a/debian/changelog b/debian/changelog
index 5b03301..5e9589e 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+ctpp2 (2.8.3-23.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix invalid gbp.conf
+  * Update symbols for gcc-8 (Closes: #897732)
+
+ -- Kunal Mehta   Sat, 21 Jul 2018 02:07:32 +0200
+
 ctpp2 (2.8.3-23) unstable; urgency=medium
 
   * Update symbols file for all architectures.
-- 
2.17.1



signature.asc
Description: OpenPGP digital signature

Bug#878549: uprightdiff FTBFS with OpenCV 3.2

[Kunal Mehta]

tags 878549 + pending
thanks

This has been fixed upstream, and I've asked my sponsor to review and
upload the new version.

-- Kunal



signature.asc
Description: OpenPGP digital signature

Bug#847293: php-ast: does not install ast.so

[Kunal Mehta]

Package: php-ast
Version: 0.1.2-2
Severity: grave
Justification: renders package unusable

Dear Maintainer,

Installing php-ast does not actually provide the ast.so file, so the extension
isn't usable.

$ apt-file list php-ast
php-ast: /etc/php/7.0/mods-available/ast.ini
php-ast: /usr/share/doc/php-ast/README.md.gz
php-ast: /usr/share/doc/php-ast/changelog.Debian.gz
php-ast: /usr/share/doc/php-ast/copyright

It should be installing a .so file to /usr/lib/php/20151012/ast.so
presumably.

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

Kernel: Linux 4.8.11-300.fc25.x86_64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages php-ast depends on:
ii  libapache2-mod-php7.0 [phpapi-20151012]  7.0.13-2
ii  php-common   1:46
ii  php7.0-cli [phpapi-20151012] 7.0.13-2

php-ast recommends no packages.

php-ast suggests no packages.

-- no debconf information

Bug#838551: mediawiki: Update breaks mediawiki-extensions, leaving unusable system

[Kunal Mehta]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

On 09/22/2016 01:06 AM, Thomas Erichsen wrote:
> Today I installed a pending upgrade for mediawiki, leaving my
> system in a complete mess: obviously, the upgrade breaks
> mediawiki-extensions, from which I used several and specifically
> the Ldap-authentication. I understand, that the former extensions
> are now partly included in the mediawiki package, right? Shouldn't
> there be a note how to configure the system to work again after
> breaking it by this upgrade?

Sorry to hear about that :(

I've updated  to note that the
mediawiki-extensions* packages are no longer supported. You should
download a more modern version of the extension from mediawiki.org.

The extensions which are bundled with the upstream tarball are
included in the "mediawiki" package itself.

Is there anywhere else you'd expect a note to let you know how to
upgrade/migrate?

- -- Kunal
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQI0BAEBCgAeBQJX5DwiFxxsZWdva3RtQG1lbWJlci5mc2Yub3JnAAoJEFL8jnvt
t/yiRL8P/0uL2Lh2Vd/aO4ZM0WnuY1SJApXrM9F6HHBQgcgyj9vQIWbF+5P4v1At
1TGZcVkFWb5cT4/EkMgsGBhOK20zfmnZptpauOUNm0lWuc1+KggXyqCTSOTTUejM
1H4XCMQRXibMarYAOZ1Ki41geuhFJLCYwx8V3QfmoJTmbFZ4JW/SD1pJf13Uld4L
dzg+66iHRQx4BpLEX28OebE6QiD2lalC7/JjMSXYkFs4J3ef4SDrYzzIXfGyb02l
yJUfMW//yHZPqoEmNS026cesT9kD47BgJm9lbETN18JX4GJUHsR51hWdNwWw4ZOL
4qQxL8eRT5VF4SWhgW/yOzgp5ETGg+U3CUkrnKmmU4DWYD/vCCur6C3e5By6Ibso
AFDq6cViPSm1VTTSyYXlPGQ9J4Js5Jk/atRW7orIUNbAmcqU3HsL56uUeOI+pJlU
U5KathWboYBJAP+L64hJyCdW/yGsfiUMDnqUEXbUfCGgUXmP/aEDN6axQp5P0sos
C+mUK14WwxS2oNq84K6yvGfN3qPNcV9CcvGSff2bQgE+1mRTk0g2EXCcU+z6BPJI
+SjCZh5lEqfr2HesPsop+vH/mr5W8QA9aRCVDA3nZ7aNWxXAZcnhN8qi1LLXD4gD
EWtp9d+RiY+KwHeV5xEgitkjMsniaN0ttvQdHXqkxAsT7lG8W3BA
=0arX
-END PGP SIGNATURE-

Bug#831874: mediawiki: fails to install: mediawiki.postinst: php5enmod: not found

[Kunal Mehta]

Hi,

On 07/20/2016 05:11 AM, Andreas Beckmann wrote:
>   Selecting previously unselected package mediawiki.
>   (Reading database ... 
> (Reading database ... 9448 files and directories currently installed.)
>   Preparing to unpack .../mediawiki_1%3a1.27.0-1_all.deb ...
>   Unpacking mediawiki (1:1.27.0-1) ...
>   Setting up mediawiki (1:1.27.0-1) ...
>   /var/lib/dpkg/info/mediawiki.postinst: 8: 
> /var/lib/dpkg/info/mediawiki.postinst: php5enmod: not found
>   dpkg: error processing package mediawiki (--configure):
>subprocess installed post-installation script returned error exit status 
> 127
>   Errors were encountered while processing:
>mediawiki
> 
> 
> Sounds a bit like an incorrect usage of the php packaging helpers,
> e.g. a missing substvar.

Thanks, I had noticed this as well - it was missed during the PHP5 ->
PHP7 transition. Additionally, MediaWiki no longer needs that
configuration at all, so I'm working removing it entirely:
.

-- Kunal

Bug#831227: mediawiki: fails to upgrade from 'jessie' - trying to overwrite /var/lib/mediawiki/extensions/Cite

[Kunal Mehta]

Hi,

On 07/14/2016 02:49 AM, Andreas Beckmann wrote:
>>From the attached log (scroll to the bottom...):
> 
>   Selecting previously unselected package mediawiki.
>   Preparing to unpack .../mediawiki_1%3a1.25.5-1_all.deb ...
>   Unpacking mediawiki (1:1.25.5-1) ...
>   dpkg: error processing archive 
> /var/cache/apt/archives/mediawiki_1%3a1.25.5-1_all.deb (--unpack):
>trying to overwrite '/var/lib/mediawiki/extensions/Cite', which is also in 
> package mediawiki-extensions-base 3.7
>   Processing triggers for systemd (215-17+deb8u4) ...
>   Errors were encountered while processing:
>/var/cache/apt/archives/mediawiki_1%3a1.25.5-1_all.deb

Thanks for reporting! Since mediawiki-extensions-base is basically
folded into the mediawiki package now, I changed[1] it to conflict for
all versions of the package and be a replaces as well.

I couldn't really figure out how to reproduce the piuparts run locally
though - the invocation at the top of the log file wasn't very useful to
me as it referenced tmp directories mostly, soany help on how to do so
would be appreciated.

[1] https://gerrit.wikimedia.org/r/#/c/299101/

-- Kunal

Bug#829701: mediawiki: nōn-DFSG-free files in package

[Kunal Mehta]

severity 829701 minor
block 829701 by 760306
thanks

On 07/08/2016 02:34 AM, Thorsten Glaser wrote:
> On Fri, 8 Jul 2016, Faidon Liambotis wrote:
>> On Wed, Jul 06, 2016 at 12:21:36PM +0200, Thorsten Glaser wrote:
>>> Let me quote:
>>>You are authorized to use our trademarks subject to this Trademark 
>>> Policy, and only on the further
>>>condition that you download images of the trademarks directly from our 
>>> [35]website. You are not
>>>
>>> Your packaging of Mediawiki does not do that. Users of your packaging
>>> do not do that. That alone is grounds for unfreeness.
>>
>> Well, first of all, "freeness" and "free software" are terms that apply
>> to copyright law and licenses, as is the DFSG for that matter. There is
>> no such thing as a "free" or "non-free" trademark license — neither
>> Debian nor the FL/OSS community at large have made any such definitions.
> 
> Independent of that, shipping the file as-is violates their trademark
> policy.
> 
>> 
> 
>> I don't interpret that clause like you do, but I'd be happy regardless
>> to raise this with Wikimedia's legal team.

Thorsten, I also do not interpret the clause as you do. Upstream
currently believes they are okay to distribute (by virtue of
distributing them), and I agree with that position.

I have also contacted the Wikimedia Foundation legal team for further
clarification on the matter. Barring a comment from them or the
ftp-masters, I plan on keeping the files in the MediaWiki package.

-- Kunal

Bug#829701: mediawiki: nōn-DFSG-free files in package

[Kunal Mehta]

Hi,

On Tue, 5 Jul 2016 14:58:49 +0200 (CEST) Thorsten Glaser
<t.gla...@tarent.de> wrote:
> the newly uploaded Mediawiki package contains nōn-free files under:
> mediawiki_1%%3a1.25.5-1_all.deb/deb://CONTENTS/usr/share/mediawiki/resources/assets/licenses/
> 
> See also: #758030

Are there any other discussions about this where others agree with your
interpretation about this? #760306 is still waiting for a comment from
the ftp masters.

IANAL, but my reading of
<https://creativecommons.org/policies/#trademark> is that it refers to
trademark licensing (which MediaWiki complies with), not copyright.

-- Kunal Mehta

Bug#821633: php-wikidiff2: PHP 7.0 Transition

[Kunal Mehta]

This is currently being worked on upstream at
 and additionally tracked at
.

I additionally was able to fix up all the packaging to be compatible
with PHP7 and use dh_php, but the upstream patch is currently segfaulting.