Bug#1068354: ITP: python-github-webhook -- microframework for writing GitHub webhooks in Python

[Kunal Mehta]

Package: wnpp
Severity: wishlist
Owner: Kunal Mehta 
X-Debbugs-Cc: debian-de...@lists.debian.org, lego...@debian.org

* Package name: python-github-webhook
  Version : 1.0.4
  Upstream Contact: Alex Chamberlain 
* URL : https://github.com/bloomberg/python-github-webhook
* License : Apache 2.0
  Programming Lang: Python
  Description : microframework for writing GitHub webhooks in Python

This library allows writing GitHub webhook handlers in Python Flask
apps pretty trivially. Conceptually it's similar to 
src:libcgi-github-webhook-perl.
While it does rely on an upstream (proprietary) service, it's pretty stable,
with no real changes in a few years. I do plan to send a patch upstream to
remove the six dependency.

We use this for various CI/etc. integrations for SecureDrop[1], so I'm
planning to maintain this in my professional/work capacity.

[1] https://securedrop.org/

Bug#1064797: Mediawiki ships with .htaccess files containing outdated access control configuration

[Kunal Mehta]

forwarded 1064797 https://phabricator.wikimedia.org/T360850
thanks

Hi Alain,

On Sun, 25 Feb 2024 23:36:16 +0100 Alain Knaff  wrote:

Mediawiki ships with .htaccess files which contain outdated access
control directives.


Thanks for reporting this. This is an upstream issue, so I've forwarded 
your report to <https://phabricator.wikimedia.org/T360850> and submitted 
patches for it. Once there's a new MediaWiki release, it'll get picked 
up by Debian.


-- Kunal Mehta

Bug#1051782: ITP: kiwix-zim -- script to check for updates to your local ZIM library

[Kunal Mehta]

Package: wnpp
Severity: wishlist
Owner: Kunal Mehta 
X-Debbugs-Cc: debian-de...@lists.debian.org, lego...@debian.org

* Package name: kiwix-zim
  Version : 3.0
  Upstream Contact: jojo2357
* URL : https://github.com/jojo2357
* License : GPL-2
  Programming Lang: bash
  Description : script to check for updates to your local ZIM library

kiwix-zim accompanies kiwix/kiwix-tools by automatically downloading new
versions of ZIM files when they are available from the Kiwix server.

I've suggested a slightly more clear name like `kiwix-zim-updater` upstream
at <https://github.com/jojo2357/kiwix-zim/issues/29>.

Bug#1051561: RoM as well

[Kunal Mehta]

Thanks for filing, just adding/confirming as maintainer that src:zimlib 
should be removed now. :)


-- Kunal

Bug#1051382: mediawiki: Provide configuration option to run update.php automatically

[Kunal Mehta]

Hi Joseph,

On 9/7/23 11:59, Joseph Nuthalapati wrote:
Provide support in the Debian package for FreedomBox's use case. If the 
user

installed MediaWiki database using dbconfig and answered positively to a
question to auto-update the database, then run update.php during package
upgrade.


Ack. I agree we should do this in the mediawiki package and it's 
probably the best user experience for the majority of package users in 
addition to FreedomBox.


We are not currently compatible with dbconfig, we'll have to look into 
how complicated or not it'll be to hook into MediaWiki's installer and 
updater.


(And there's other stuff we should flip on by default like the jobrunner 
systemd service.)


-- Kunal

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#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#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#1032771: libzim7: Package name is wrong, should be 'libzim'

[Kunal Mehta]

tags 1032771 - wontfix
thanks

Hi,

On 3/22/23 11:41, Bastian Germann wrote:

Control: tags -1 wontfix

On Fri, 17 Mar 2023 20:12:26 -0400 James Valleroy 
 wrote:
Note that this request is about changing the source package name, from 
"zimlib" to "libzim". The bug was accidentally filed on the binary 
package instead of the source package.


There is no good reason to rename the source package.


I would like to do this for the trixie cycle, mostly to be in sync with 
upstream.


-- 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#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#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#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#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#1027464: RM: pdf-redact-tools -- ROM; broken, unmaintained

[Kunal Mehta]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: lego...@debian.org

Hi,

Please remove src:pdf-redact-tools, it's broken (see #1023251) and unmaintained 
upstream.

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#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#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#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#986856: RFP: dangerzone -- Take potentially dangerous PDFs, office documents, or images and convert them to a safe PDF

[Kunal Mehta]

Hi,

On 4/4/22 03:41, Peymaneh wrote:

@Kunal
Would you mind having a look at it? This is my first package including 
post{inst,rm}-scripts and I am not sure if the way i did it is very robust.


Yay! Comments unrelated to the postinst:

* I think dangerzone-container.1 might be outdated, it references 
`docker` instead of `podman`.
* in d/rules, just remove the `export DH_VERBOSE` line entirely and use 
the default.

* Is python3-stdeb needed? I might've missed something.
* You can drop d/source/local-options, everything is commented out.
* Please try to upstream the .desktop patch


For context:
For the new version upstream has decided to include build a whole 
Container-Image at build time and include the 700MB image in the .deb 
package. The absurd package size set aside, building the image on the 
Debian build servers would not be possible because a network connection 
is required for pulling the docker image.
My dangerzone.postinst is basically the build-script from upstream[2] 
only with some very basic error-handling added to it.


Definitely agreed that shipping the container in the package itself 
would be a big mistake and not feasible for multiple reasons.


I think what you have now is probably acceptable for contrib[1], but far 
from ideal, both practically and for the goal of getting it into main. 
My opinion of ideal behavior would be that the first time Dangerzone is 
opened, it notices the lack of the image, and then starts building it or 
pulling it from somewhere (with or without a prompt). It would be worth 
discussing such a behavior change with upstream first though. An Arch 
Linux maintainer has already asked for something similar at 
.


[1] I'll inquire with others if they know of other examples like this.

-- 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#986856: RFP: dangerzone -- Take potentially dangerous PDFs, office documents, or images and convert them to a safe PDF

[Kunal Mehta]

Hi Peymaneh,

On Tue, 20 Jul 2021 23:36:35 + Peymaneh Nejad  wrote:
I have done some initial packaging[1], but I think it should definitely ship 
with an autopkgtest at least for the cli binaries that are included. Hope I can 
look into that next month, but since testing is frozen anyway I think there is 
no hurry


I'm wondering if you have any update on packaging or anything I can help 
with. I would like to sunset src:pdf-redact-tools (now archived 
upstream) in favor of dangerzone.


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#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#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#998223: RFH: mailman3 packages -- Mailing list management system

[Kunal Mehta]

Hi,

On Mon, 01 Nov 2021 10:41:54 +0100 Jonas Meurer  
wrote:



So we're looking for you if you:

* happen to run mailman3 instances and have some spare cycles
* want to give your share to keep mailman3 packages in Debian
* are keen to get your hands dirty in python packages which touch a lot
   of different packaging aspects


I co-maintain Wikimedia's Mailman3 install and have also done a bit of 
work upstream. Please let me know how I can help.


-- Kunal

Bug#993676: prometheus-node-exporter-collectors: btrfs_stats.py doesn't work with Python 3

[Kunal Mehta]

Package: prometheus-node-exporter-collectors
Version: 0+git20210115.7d89f19-1
Severity: normal
Tags: patch

btrfs_stats.py fails with a RuntimeException when run with Python 3
on my bullseye system.

There's a trivial upstream patch for this: 
.

I tested the patch and it does fix the issue for me.

Thanks,
-- Kunal

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

Kernel: Linux 5.4.129-1.fc25.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#990336: mailman3: Improve logrotate configuration

[Kunal Mehta]

Package: mailman3
Version: 3.3.3-1
Severity: wishlist

Dear maintainer,

The Mailman3 package currently includes logrotate configuration for one file,
/var/log/mailman3/mailman.log. However, it is pretty common to enable other
logs, changing it to apply to /var/log/mailman3/*.log would be much nicer
IMO and what most sysadmins expect. I have tested this on Wikimedia's
Mailman3 install and it works properly.

I'm also somewhat curious why it only keeps 5 days worth of logs by default,
personally I think something like 7 days or 14 (what apache2 uses) would
be more reasonable.

Thanks,
-- Kunal

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

Kernel: Linux 5.4.120-1.fc25.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 mailman3 depends on:
pn  dbconfig-sqlite3 | dbconfig-pgsql | dbconfig-mysql | dbconfi  
ii  debconf [debconf-2.0] 1.5.71
ii  logrotate 3.14.0-4
ii  lsb-base  10.2019051400
ii  python3   3.7.3-1
pn  python3-aiosmtpd  
pn  python3-alembic   
ii  python3-click 7.0-1
pn  python3-dnspython 
pn  python3-falcon
pn  python3-flufl.bounce  
pn  python3-flufl.i18n
pn  python3-flufl.lock
pn  python3-lazr.config   
pn  python3-passlib   
pn  python3-psycopg2 | python3-pymysql
pn  python3-public
ii  python3-requests  2.21.0-1
pn  python3-sqlalchemy
pn  python3-zope.component
pn  python3-zope.configuration
pn  python3-zope.event
pn  python3-zope.interface
ii  ucf   3.0038+nmu1

Versions of packages mailman3 recommends:
ii  exim4-daemon-light [mail-transport-agent]  4.92-8+deb10u6

Versions of packages mailman3 suggests:
ii  chromium [www-browser]  90.0.4430.212-1~deb10u1
ii  firefox-esr [www-browser]   78.11.0esr-1~deb10u1
pn  mailman3-doc
pn  postgresql | default-mysql-server | virtual-mysql-  

Bug#987976: mediawiki: autopkgtests are missing restrictions and dependencies

[Kunal Mehta]

Hi,

On 5/2/21 7:42 PM, Tobias Wiese wrote:

The install-* autopkgtest require the start of services and should
therefore be tagged with the isolation-container restriction.
They also use the systemctl command from the systemd package which is
missing in the depends field.

I also think that the lint test should be marked with the superficial
restriction, as it doesn't test the installed packages functionality,
but its code style.


Thanks! I pushed these to the Git repo, will include it in the next 
upload or after the freeze. I assume that since you marked this as minor 
it isn't important to get in for bullseye?


-- Kunal

Bug#987654: Adjusting severity

[Kunal Mehta]

severity 987654 serious
thanks

Upping priority to serious as this is technically a violation of policy 
that all software in main should be self-contained to main, and I 
believe there is a general acceptance in Debian that such privacy 
breaches are not acceptable (see also #726998).


I can also confirm that I finished testing the upstream patch and it 
worked as expected after running "sudo mailman-web collectstatic --clear 
&& sudo mailman-web compress".


-- Kunal

Bug#987654: python3-django-hyperkitty: Loads Google Fonts (fonts.gstatic.com), causing privacy breach

[Kunal Mehta]

Package: python3-django-hyperkitty
Version: 1.3.4-2
Severity: important

Hyperkitty's CSS attempts to loads fonts from Google Fonts, causing a privacy 
breach:

@font-face {
  font-family: 'Droid Sans';
  font-style: normal;
  font-weight: 400;
  src: local('Droid Sans'), local('DroidSans'),
   
url(https://fonts.gstatic.com/s/droidsans/v6/s-BiyweUPV0v-yRb-cjciC3USBnSvpkopQaUR-2r7iU.ttf)
 format('truetype'),
   
url(/mailman3/static/hyperkitty/libs/fonts/droid/DroidSans.ttf?9a88e405c18d) 
format('truetype');
}

These fonts are already bundled in the package, so trying to load them from 
Google
causes a privacy breach for no good reason.

This has already been fixed upstream: 
,
I hope we can include this fix for bullseye.

Let me know if I can help with fixing (NMU, etc.), I've already prepared a 
fixed package
for our Mailman3 install at Wikimedia.

-- Kunal

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

Kernel: Linux 5.4.98-1.fc25.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 python3-django-hyperkitty depends on:
pn  fonts-glewlwyd   
pn  libjs-bootstrap  
ii  python3  3.7.3-1
ii  python3-dateutil 2.7.3-3
pn  python3-django   
pn  python3-django-compressor
pn  python3-django-extensions
pn  python3-django-gravatar2 
pn  python3-django-haystack  
pn  python3-django-mailman3  
pn  python3-django-q 
pn  python3-djangorestframework  
ii  python3-lockfile 1:0.12.2-2
pn  python3-mailmanclient
pn  python3-networkx 
pn  python3-robot-detection  
ii  python3-tz   2019.1-1

Versions of packages python3-django-hyperkitty recommends:
pn  mailman3-web  

python3-django-hyperkitty suggests no packages.

Bug#987630: python3-authheaders: missing .egg-info metadata

[Kunal Mehta]

Package: python3-authheaders
Version: 0.10.0-1
Severity: important

Dear maintainer,

The python3-authheaders package in Buster is missing the .egg-info metadata
so it can't be found by e.g. pkg-resources:

>>> import authheaders; authheaders

>>> import pkg_resources; pkg_resources.get_distribution('authheaders')
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 481, in 
get_distribution
dist = get_provider(dist)
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 357, in 
get_provider
return working_set.find(moduleOrReq) or require(str(moduleOrReq))[0]
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 900, in 
require
needed = self.resolve(parse_requirements(requirements))
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 786, in 
resolve
raise DistributionNotFound(req, requirers)
pkg_resources.DistributionNotFound: The 'authheaders' distribution was not 
found and is required by the application

I note that 0.11.0-1 (from snapshot.debian.org) has the correct files:

/usr/lib/python3/dist-packages/authheaders-0.11.0.egg-info
/usr/lib/python3/dist-packages/authheaders-0.11.0.egg-info/PKG-INFO
/usr/lib/python3/dist-packages/authheaders-0.11.0.egg-info/dependency_links.txt
/usr/lib/python3/dist-packages/authheaders-0.11.0.egg-info/not-zip-safe
/usr/lib/python3/dist-packages/authheaders-0.11.0.egg-info/requires.txt
/usr/lib/python3/dist-packages/authheaders-0.11.0.egg-info/top_level.txt

It wasn't obvious to me what change from 0.10.0-1 to 0.11.0-1 fixed this 
otherwise
I would have attempted to provide a patch.

I encountered this while trying to run a newer version of Mailman3 on Buster, 
which
depends on this package.

Thanks,
Kunal

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

Kernel: Linux 5.4.98-1.fc25.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 python3-authheaders depends on:
ii  publicsuffix  20190415.1030-1
ii  python3   3.7.3-1
ii  python3-authres   1.1.1-1
ii  python3-dkim  0.9.6-0+deb10u1
ii  python3-dnspython 1.16.0-1
ii  python3-publicsuffix  1.1.0-2

Versions of packages python3-authheaders recommends:
pn  python3-spf  

python3-authheaders suggests no packages.

-- no debconf information

Bug#984625: pygments: New 2.8.0 upstream version available

[Kunal Mehta]

Package: pygments
Version: 2.7.1+dfsg-1
Severity: wishlist

Dear maintainer,

Pygments has released version 2.8.0: 
https://pygments.org/docs/changelog/#version-2-8-0

It now includes the "dot" language, which had previously been requested by
Wikimedia users: .

0002-add-g-parameter-to-pygmentize-man-page.patch can also be dropped as it has 
been fixed upstream.

I prepared an update to 2.8.0 for Wikimedia on Buster, feel free to use any of 
my packaging work in case it is useful: 
.

Thanks,
-- Kunal

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

Kernel: Linux 5.4.88-1.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#981466: kiwix: switch data feed and download URLs to https

[Kunal Mehta]

On 2/14/21 8:15 PM, Paul Wise wrote:

On Sun, 2021-02-14 at 20:11 -0800, Kunal Mehta wrote:


I'm going to cherry-pick the upstream fix for this and upload its
hortly so it'll be in bullseye.


Thanks.


Uploaded with 2.0.5-3.


The catalog is used by other devices, and apparently some older
Android devices didn't have the correct certs for Let's Encrypt? I'll
continue following up with upstream on this, but I'm going to mark
this bug as closed by the first change since this latter part
shouldn't require any fixes/adjustments to the Kiwix code once the
catalog is updated.


I think extra code will be needed to try https for each domain and then
upgrade all future http connections where https works on the domain.


I was thinking it would just wait until the catalog itself uses HTTPS 
for all links, but your suggestion also works, so I'll leave this open then.


-- Kunal

Bug#982979: kiwix-serve: symbol lookup error

[Kunal Mehta]

Hi,

On 2/17/21 10:08 AM, Von wrote:

Package: kiwix-tools
Version: 3.1.2-2
Severity: important
X-Debbugs-Cc: rekae...@outlook.com

Dear Maintainer,

kiwix-serve fails to run and throws symbol lookup error regardless
command line arguments.

kiwix-serve was not usable at all.

outcome:
 --
$ kiwix-serve /srv/Library/Zim/wikipedia_en_computer_maxi_2021-01.zim 
-p 8000
kiwix-serve: symbol lookup error: kiwix-serve: undefined symbol: 
_ZN5kiwix5splitERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEES7_b

$ kiwix-serve
kiwix-serve: symbol lookup error: kiwix-serve: undefined symbol: 
_ZN5kiwix5splitERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEES7_b


Thanks for reporting!

That symbol demangles to:
kiwix::split(std::__cxx11::basic_string, 
std::allocator > const&, std::__cxx11::basic_stringstd::char_traits, std::allocator > const&, bool)


It looks like 
https://github.com/kiwix/kiwix-lib/commit/08464f23bc0756fc99e2e1559f95d325f52fba87 
was an unintentional ABI break.


I'll upload a fix shortly and add a (trivial) autopkgtest to catch these 
regressions automatically in the future.


-- Kunal

Bug#981466: kiwix: switch data feed and download URLs to https

[Kunal Mehta]

Hi,

Thanks for noticing and reporting this :)

On 1/31/21 7:19 AM, Paul Wise wrote:

I noticed that the data feed is not downloaded using https, so network
attackers could modify the data feed to change my choice of downloads
to something I didn't want to download.


I'm going to cherry-pick the upstream fix for this and upload it shortly 
so it'll be in bullseye.



Also most of the datasets point at http instead of https URLs even
though the servers do support https. It would be good if kiwix had a
list of download servers that support https and then always use https
to contact those download servers.


The catalog is used by other devices, and apparently some older Android 
devices didn't have the correct certs for Let's Encrypt? I'll continue 
following up with upstream on this, but I'm going to mark this bug as 
closed by the first change since this latter part shouldn't require any 
fixes/adjustments to the Kiwix code once the catalog is updated.


-- Kunal

Bug#979686: mediawiki: Cannot skip installing mariadb & postgresql

[Kunal Mehta]

Hi,

On 1/25/21 2:35 PM, Sunil Mohan Adapa wrote:

I propose a different solution:

What if we add 'sqlite3' into the mix like this: 'default-mysql-server |
virtual-mysql-server | postgresql-contrib | sqlite3'? This way, people
wanting to use sqlite only (including FreedomBox) can run 'apt install
mediawiki php-sqlite3 sqlite3' and get all the other recommends too.
sqlite3 is, strictly speaking, not needed for functioning of MediaWiki
with the sqlite3 DB because the package php-sqlite3 is sufficient.
However, this 1.2MiB package is a (hackish) placeholder to avoid
installing the other databases when installing with recommends. Let me
know if this is acceptable.


I like this idea.

I wonder if we can do:
 default-mysql-server | virtual-mysql-server | postgresql-contrib
 | php-sqlite3

So we're not actually installing anything extra but still get an 
alternative in for sqlite. I don't know if apt will let us have 
php-sqlite3 be in both Depends and Recommends, but I'll give it a try 
and if not use your sqlite3 suggestion.


-- Kunal

Bug#979686: mediawiki: Cannot skip installing mariadb & postgresql

[Kunal Mehta]

Hi Joseph,

On 1/9/21 7:07 PM, Joseph Nuthalapati wrote:

However, the Debian package for MediaWiki installs mariadb server,
client and libraries for PHP and Perl. The MariaDB daemon consumes 80-90
MB of memory which is a lot to spare on Single Board Computers.
Similarly, it also installs PostgreSQL server, client and libraries.


MediaWiki currently "Recommends" MariaDB/postgres, it's not a hard 
dependency. I do believe that for most users MariaDB is the best option 
and should be installed by default, but understand and agree that for 
FreedomBox SQLite is a better choice.



It is possible to install mediawiki without mariadb and postgreql using
the following command, but one has to guess the version numbers correctly.


The easiest and most foolproof way would be:

# apt install mediawiki --no-install-recommends


# apt install mediawiki mariadb-server-10.5- postgresql-13-


On Buster (didn't try unstable yet), the following seems to work as well:

# apt install mediawiki default-mysql-server-

You probably also want to install php-sqlite3 explicitly so php-mysql 
isn't pulled in.



Maybe a package like mediawiki-sqlite which doesn't install the other
databases would help.


I would be open to such a solution if we can't figure it out another way.

-- 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#971986: $wgRedirectOnLogin ignored

[Kunal Mehta]

tags 971986 fixed-upstream pending
thanks

This was fixed upstream in 
 which should 
be included in the next maintenance/security release.


-- Kunal

On 10/11/20 12:38 AM, Alain Knaff wrote:

Package: mediawiki
Version: 1:1.31.10-1~deb10u1

Hi,

The localSettings variable $wgRedirectOnLogin is ignored, apparently 
because the showReturnToPage function forgot to declare it global. This 
results in an unsightly warning in the web server log:


[Sun Oct 11 09:29:12.186114 2020] [proxy_fcgi:error] [pid 14121:tid 
139621415540480] [client 80.90.57.94:38882] AH01071: Got error 'PHP 
message: PHP Notice:  Undefined variable: wgRedirectOnLogin in 
/usr/share/mediawiki/includes/specials/helpers/LoginHelper.php on line 
68', referer: https://wiki.lll.lu/Special:UserLogin?returnto=HomePage



Adding the following to the top of the showReturnToPage in 
/usr/share/mediawiki/includes/specials/helpers/LoginHelper.php fixes the 
issue:

   global $wgRedirectOnLogin;


Thanks,

Alain

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#969435: ITP: mediawiki-extension-youtube -- Embed YouTube and other videos into MediaWiki pages

[Kunal Mehta]

Package: wnpp
Severity: wishlist
Owner: Kunal Mehta 

* Package name: mediawiki-extension-youtube
  Version : 1.9.3
  Upstream Author : Przemek Piotrowski 
* URL : https://www.mediawiki.org/wiki/Extension:YouTube
* License : GPL-2.0-or-later
  Programming Lang: PHP
  Description : Embed YouTube and other videos into MediaWiki pages

The YouTube MediaWiki extension allows embedding YouTube and other videos
into wiki pages.

Other supported sites include:
* Google Videos
* Archive.org video and audio
* WeGame
* Tangler forum
* Gametrailers
* Nicovideo
* GoGreenTube

I'll be maintaining this under the MediaWiki packaging team.

Bug#969434: ITP: mediawiki-skin-greystuff -- A fixed-width grey skin for MediaWiki

[Kunal Mehta]

Package: wnpp
Severity: wishlist
Owner: Kunal Mehta 

* Package name: mediawiki-skin-greystuff
  Version : 1.1.0
  Upstream Author : Calimonius the Estrange 
* URL : https://www.mediawiki.org/wiki/Skin:GreyStuff
* License : GPL-2.0-or-later
  Programming Lang: PHP/CSS
  Description : A fixed-width grey skin for MediaWiki

GreyStuff is a fixed-width grey skin for MediaWiki that is intended to
emphasise content over interface. It's responsive, supporting both desktop
and mobile screens.

I'll be maintaining this under the MediaWiki packaging team.

Bug#969196: zimlib: symbols updates for architectures built with -O3

[Kunal Mehta]

Hi,

On 2020-08-29 00:47, Gianfranco Costamagna wrote:
> Source: zimlib
> Version: 6.2.0-2
> Severity: serious
> tags: patch
> 
> Hello, zimlib symbols file seems to be really difficult to maintain, breaking 
> on each icu upload, each new gcc upload,
> different gcc optimization levels (such as -O2 and -O3) and so on.
> 
> Somebody thinks that symbols files for c++ applications are a waste of time, 
> but I'm sending you another patch that fixes the issue for now, by adding 
> some symbols, and marking some other as optional
> https://wiki.debian.org/UsingSymbolsFiles

Yeah, this all seems like an exercise in futility at this point. I see
very little benefit in continuing to maintain the symbols file given
that all of the dependent packages are usually updated lockstep and are
managed by the same upstreams.

Any objections to me dropping the symbols file?

-- Kunal

P.S. Thanks for all your work and help in getting libzim/libkiwix to
exist properly in Ubuntu.

Bug#831424: RFP: parsoid -- Web service converting HTML+RDFa to MediaWiki wikitext and back

[Kunal Mehta]

retitle 831424 ITP: parsoid -- bidirectional parser between wikitext and
HTML5
owner 831424 !
thanks

Parsoid has been ported to PHP and is now being bundled inside MediaWiki
as a library rather than a separate web service. I plan to close this
ITP with my next MediaWiki upload (upstream version 1.35) as it fulfills
the spirit of this request. If someone would like a separate Parsoid
package, let me know and I can see what's possible.

-- Kunal

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#966227: ITP: python-libzim -- Python bindings for the libzim library

[Kunal Mehta]

Package: wnpp
Severity: wishlist
Owner: Kunal Mehta 

* Package name: python-libzim
  Version : 0.0.3
  Upstream Author : openZIM developers 
* URL : https://github.com/openzim/python-libzim
* License : GPL-3
  Programming Lang: C++/Python
  Description : Python bindings for the libzim library

python-libzim contains Python bindings for the libzim library, allowing
for programmatic reading and creation of ZIM files in a manner that's
easier and faster than shelling out to zimwriterfs (part of zim-tools).

Many ZIM scrapers are being adapted to now use this Python library.

Bug#965994: RM: src:zimwriterfs -- ROM; merged into zim-tools

[Kunal Mehta]

Package: ftp.debian.org
Severity: normal

Hi,

src:zimwriterfs has been merged into the zim-tools package, which is now
also producing a zimwriterfs transitional package.

Please remove src:zimwriterfs from Debian.

Thanks,
-- Kunal

Bug#965975: libdocopt-dev: New upstream 0.6.3 version available

[Kunal Mehta]

Package: libdocopt-dev
Version: 0.6.2-2
Severity: wishlist

Hi,

A 0.6.3 upstream version is available, could the package be updated
please?

Notably, it contains pkg-config support[1], which would be nice for
meson-based projects. I'm specifically interested in it for zim-tools.

[1] 
https://github.com/docopt/docopt.cpp/commit/3dd23e3280f213bacefdf5fcb04857bf52e90917

Thanks,
-- Kunal

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

Kernel: Linux 4.19.128-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 libdocopt-dev depends on:
pn  libdocopt0  

libdocopt-dev recommends no packages.

libdocopt-dev suggests no packages.

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#964502: RM: ctpp2 -- ROM; unused in Debian, dead upstream

[Kunal Mehta]

Package: ftp.debian.org
Severity: normal

ctpp2 is no longer used by libkiwix and now has no dependencies in Debian
anymore. It's also dead upstream.

I checked with Vasudev and Jonas and they agreed on removal as well.

Thanks,
-- 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#641812: Packaging qtsingleapplication?

[Kunal Mehta]

Hi Qt maintainers,

I'm currently packaging kiwix (#763321) and came across
qtsingleapplication. It has had an open RFP (#641812) since 2011.

Currently upstream kiwix bundles a copy of qtsingleapplication in its
Git repo/tarballs, as there is no packaged version.

However, the Fedora kiwix packager has asked
() for
qtsingleapplication to be unbundled as they have it packaged.

I noticed via codesearch that there are other packages that also bundle
qtsingleapplication:
.

Is this something current Qt maintainers would be interested in
providing a package for? Or should I recommend to upstream to continue
bundling it?

Thanks,
-- Kunal

(please cc, not subscribed)



signature.asc
Description: OpenPGP digital signature

Bug#763321: ITP kiwix

[Kunal Mehta]

owner 763321 !
retitle 763321 ITP: kiwix -- An offline Wikipedia reader
thanks

Now that libzim and libkiwix are up to date, I'm going to start
packaging the Kiwix desktop client.

I have a local build working, but there's one licensing issue that I'm
working with upstream on:
.

-- Kunal



signature.asc
Description: OpenPGP digital signature

Bug#964171: meson build triggers blhc compiler-flags-hidden warning

[Kunal Mehta]

ibaudit1_1:2.8.5-3+b1 libbinutils_2.34-8 libblkid1_2.35.2-6 libbz2-1.0_1.0.8-3 
libc-bin_2.30-8 libc-dev-bin_2.30-8 libc6_2.30-8 libc6-dev_2.30-8 
libcap-ng0_0.7.9-2.2 libcc1-0_10.1.0-4 libcom-err2_1.45.6-1 libcroco3_0.6.13-1 
libcrypt-dev_1:4.4.16-1 libcrypt1_1:4.4.16-1 libcryptsetup12_2:2.3.3-1 
libctf-nobfd0_2.34-8 libctf0_2.34-8 libdb5.3_5.3.28+dfsg1-0.6 
libdebconfclient0_0.252 libdebhelper-perl_13.1 
libdevmapper1.02.1_2:1.02.167-1+b1 libdpkg-perl_1.20.3 libelf1_0.176-1.1 
libexpat1_2.2.9-1 libext2fs2_1.45.6-1 libfakeroot_1.24-1 libffi7_3.3-4 
libfile-stripnondeterminism-perl_1.8.1-1 libgcc-9-dev_9.3.0-14 
libgcc-s1_10.1.0-4 libgcrypt20_1.8.5-5 libgdbm-compat4_1.18.1-5 
libgdbm6_1.18.1-5 libglib2.0-0_2.64.3-2 libgmp10_2:6.2.0+dfsg-6 
libgnutls30_3.6.14-2 libgomp1_10.1.0-4 libgpg-error0_1.38-1 
libgtest-dev_1.10.0-3 libhogweed5_3.5.1+really3.5.1-2 libicu-dev_67.1-2 
libicu67_67.1-2 libidn2-0_2.3.0-1 libisl22_0.22.1-1 libitm1_10.1.0-4 
libjson-c4_0.13.1+dfsg-9 liblsan0_10.1.0-4 liblz4-1_1.9.2-2 
liblzma-dev_5.2.4-1+b1 liblzma5_5.2.4-1+b1 libmagic-mgc_1:5.38-5 
libmagic1_1:5.38-5 libmount1_2.35.2-6 libmpc3_1.1.0-1 libmpdec2_2.4.2-3 
libmpfr6_4.0.2-1 libncursesw6_6.2-1 libnettle7_3.5.1+really3.5.1-2 
libp11-kit0_0.23.20-1 libpam-modules_1.3.1-5 libpam-modules-bin_1.3.1-5 
libpam-runtime_1.3.1-5 libpam0g_1.3.1-5 libpcre2-8-0_10.34-7 libpcre3_2:8.39-13 
libperl5.30_5.30.3-4 libpipeline1_1.5.2-2 libpython3-stdlib_3.8.2-3 
libpython3.8-minimal_3.8.4~rc1-1 libpython3.8-stdlib_3.8.4~rc1-1 
libquadmath0_10.1.0-4 libreadline8_8.0-4 libseccomp2_2.4.3-1+b1 
libselinux1_3.0-1+b3 libsemanage-common_3.0-1 libsemanage1_3.0-1+b3 
libsepol1_3.0-1 libsigsegv2_2.12-2 libsmartcols1_2.35.2-6 libsqlite3-0_3.32.3-1 
libss2_1.45.6-1 libssl1.1_1.1.1g-1 libstdc++-9-dev_9.3.0-14 libstdc++6_10.1.0-4 
libsub-override-perl_0.09-2 libsystemd0_245.6-1 libtasn1-6_4.16.0-2 
libtinfo6_6.2-1 libtool_2.4.6-14 libtsan0_10.1.0-4 libubsan1_10.1.0-4 
libuchardet0_0.0.7-1 libudev1_245.6-1 libunistring2_0.9.10-4 libuuid1_2.35.2-6 
libxapian-dev_1.4.15-1 libxapian30_1.4.15-1 libxml2_2.9.10+dfsg-5+b1 
libzstd-dev_1.4.5+dfsg-3 libzstd1_1.4.5+dfsg-3 linux-libc-dev_5.7.6-1 
login_1:4.8.1-1 logsave_1.45.6-1 lsb-base_11.1.0 m4_1.4.18-4 make_4.3-4 
man-db_2.9.3-1 mawk_1.3.4.20200120-2 meson_0.54.3-1 mime-support_3.64 
mount_2.35.2-6 ncurses-base_6.2-1 ncurses-bin_6.2-1 ninja-build_1.10.0-2 
openssl_1.1.1g-1 passwd_1:4.8.1-1 patch_2.7.6-6 perl_5.30.3-4 
perl-base_5.30.3-4 perl-modules-5.30_5.30.3-4 pkg-config_0.29.2-1 
pkg-kde-tools_0.15.32 po-debconf_1.0.21 policyrcd-script-zg2_0.1-3 
python3_3.8.2-3 python3-minimal_3.8.2-3 python3.8_3.8.4~rc1-1 
python3.8-minimal_3.8.4~rc1-1 readline-common_8.0-4 
sbuild-build-depends-main-dummy_0.invalid.0 sed_4.7-1 
sensible-utils_0.0.12+nmu1 sysvinit-utils_2.96-3 tar_1.30+dfsg-7 tzdata_2020a-1 
util-linux_2.35.2-6 uuid-dev_2.35.2-6 xz-utils_5.2.4-1+b1 
zlib1g_1:1.2.11.dfsg-2 zlib1g-dev_1:1.2.11.dfsg-2

+--+
| Build|
+--+


Unpack source
-

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 3.0 (quilt)
Source: zimlib
Binary: libzim6, libzim-dev
Architecture: any
Version: 6.1.3-4
Maintainer: Jonas Smedegaard 
Uploaders:  Mike Gabriel , Kunal Mehta 

Homepage: https://www.openzim.org/wiki/Zimlib
Standards-Version: 4.5.0
Vcs-Browser: https://salsa.debian.org/debian/zimlib
Vcs-Git: https://salsa.debian.org/debian/zimlib.git
Build-Depends: debhelper-compat (= 12), liblzma-dev, zlib1g-dev, libicu-dev, 
libxapian-dev, libzstd-dev, uuid-dev, libgtest-dev, pkg-kde-tools, meson, 
ninja-build, pkg-config
Package-List:
 libzim-dev deb libdevel optional arch=any
 libzim6 deb libs optional arch=any
Checksums-Sha1:
 1ea81572cb51c95c31b8becae38351d42d3e3745 28587377 zimlib_6.1.3.orig.tar.gz
 01e3fe5a00ef32526bc0720c934fb15633041376 24636 zimlib_6.1.3-4.debian.tar.xz
Checksums-Sha256:
 629b7e4fb9d1dc75e755467362889688b4515d2c7982925c93bb974d04e033f3 28587377 
zimlib_6.1.3.orig.tar.gz
 47721be1e62d9dd89a9596ee43013845c600533e4011da3c63bb90bae0486ec7 24636 
zimlib_6.1.3-4.debian.tar.xz
Files:
 33f3f524f234344052f493d8136730a6 28587377 zimlib_6.1.3.orig.tar.gz
 a5f0bf47a21a146d14ab6cdd3ddd2c27 24636 zimlib_6.1.3-4.debian.tar.xz

-BEGIN PGP SIGNATURE-

iQJHBAEBCAAxFiEE2MtZ8F27ngU4xIGd8QX4EBsFJpsFAl7+UZsTHGxlZ29rdG1A
cmlzZXVwLm5ldAAKCRDxBfgQGwUmmyiNEACt5MNtUbiKfhR72jpKcku9Oau01XoH
55doiogz6Rz3PvH8S1L/j9qjFOOsXRChdQr168ZTTNC403e8+yco7U7S8I2ryZYQ
AhdR8ZD98iLegCO1WWps0Q5IVFdCYg09EtYOF03BULq9wWDNWkoOAEHFDa+xjktK
wYS2I21UoNYjkV3Age8ZGAgm3Givin1Gdjck/MjjcJjsW1tZsLMiutBtRuJytoKG
2z13i8Ynn/XcMbza0g/RKI8bwm4yf+ZF7HaR6d0dhpvbqWnXmWf1hJ3HYEnWl+lT
NUqeRRV7f8y2wpTvKlWjm8x9ub8RpoZJLRBB9XxtjOqIAItat2cUzYr+xRAflviQ
IH+riE8PLgG1kMYDiJgN207abYVSPyQNRv3l9Pysm8pkhOpdeA4w5ngn9XNHOHhO
Pc6iKfkBd3Hb

Bug#964163: ITP: zim-tools -- various ZIM command-line tools

[Kunal Mehta]

Package: wnpp
Severity: wishlist
Owner: Kunal Mehta 

* Package name: zim-tools
  Version : 1.2.1
  Upstream Author : openZIM/Kiwix developers 
* URL : https://github.com/openzim/zim-tools
* License : GPL-3.0-or-later
  Programming Lang: C++
  Description : various ZIM command-line tools

ZIM tools is a collection of various command-line utilities
for interacting with and working with the ZIM file format,
which is primarily used to power Kiwix, an offline Wikipedia
reader (among other things).

Upstream plans to merge zimwriterfs into this codebase in the
near future as well.

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#963231: mediawiki: Should not depend on php, should be php|php-fpm

[Kunal Mehta]

Hi,

On 2020-06-20 20:57, Russell Coker wrote:
> Mediawiki appears to work well with php-fpm, should not force the installation
> of php.

Correct, MediaWiki is fully supported using php-fpm.

I don't see a bug in the package's dependencies though. `php`, is a
metapackage that depends on `php7.X`, which in turn depends on
`libapache2-mod-php7.X | php7.X-fpm | php7.4-ci`. So by default, mod_php
is installed, but if you do e.g. `sudo apt install php-fpm mediawiki`,
it will install php-fpm, and not mod_php.

Is that what you're looking for or did you mean something else?

-- Kunal



signature.asc
Description: OpenPGP digital signature

Bug#942960: patch

[Kunal Mehta]

tags 942960 + patch
thanks

I submitted a pretty straightforward patch at
, please let
me know if you'd prefer I upload it to the BTS.

-- Kunal / Legoktm



signature.asc
Description: OpenPGP digital signature

Bug#947063: ITP: pass-import - MediaWiki API client in Python

[Kunal Mehta]

Hi,

I think you might have a copy/paste mistake in your bug title, I don't
see anything related to MediaWiki in this ITP.

-- Kunal



signature.asc
Description: OpenPGP digital signature

Bug#946665: mediawiki: autopkgtests may fail due to stderr messages

[Kunal Mehta]

Hi Mathieu,

Thanks for filing the bug. In the past (c.f. #911829), failing on stderr
has identified problems in MediaWiki when a new PHP version is released,
so I would like to keep the current behavior if possible.

Do you have any ideas or suggestions on other ways we could avoid this
problem? Would `sudo ... 2>&1` for all invocations be good enough?

Thanks,
-- Kunal

On 2019-12-12 17:59, Mathieu Trudel-Lapierre wrote:
> Package: mediawiki
> Version: 1:1.31.5-3
> Severity: minor
> 
> Dear Maintainer,
> 
> mediawiki autopkgtests may fail with sudo 1.8.29.
> 
> The new sudo version handles setting limits differently (actually honours 
> pam_limits),
> and as such you'd get an Operation not supported error when it tries to set 
> RLIMIT_CORE
> on some architectures, depending on the infrastructure being used.
> 
> This is the only message showing in stderr, and thus fails the tests because 
> of stderr.
> 
> I suggest adding allow-stderr to all the tests in debian/tests/control except 
> for lint
> to allow the presence of messages on stderr while running the tests.
> 
> 
> -- System Information:
> Debian Release: bullseye/sid
>   APT prefers focal
>   APT policy: (500, 'focal')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 5.3.0-23-generic (SMP w/4 CPU cores)
> Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
> Locale: LANG=fr_CA.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
> LANGUAGE=fr_CA:fr (charmap=UTF-8)
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> Versions of packages mediawiki depends on:
> pn  apache2 | httpd
> pn  mediawiki-classes  
> ii  mime-support   3.64ubuntu1
> pn  php
> pn  php-common 
> pn  php-mbstring   
> pn  php-mysql | php-pgsql | php-sqlite3 | php-mysqlnd  
> pn  php-xml
> 
> Versions of packages mediawiki recommends:
> pn  default-mysql-server | virtual-mysql-server | postgresql-co  
> pn  php-apcu 
> pn  php-cli  
> pn  php-curl 
> pn  php-intl 
> pn  php-wikidiff2
> ii  python3  
> 3.7.5-1ubuntu1
> 
> Versions of packages mediawiki suggests:
> pn  clamav
> pn  imagemagick | php-gd  
> pn  memcached 
> 



signature.asc
Description: OpenPGP digital signature

Bug#944650: Incompatible with Postgres-12

[Kunal Mehta]

Hi,

Thanks for filing a bug :) I had noticed this as well, and filed one
upstream: https://phabricator.wikimedia.org/T237931

On 2019-11-13 02:37, Christian Ehrhardt wrote:
> Package: mediawiki
> Version: 1:1.31.5-1
> 
> Hi,
> First of all I beg your pardon but didn't know how to better submit this.
> VCS-git says: https://gerrit.wikimedia.org/r/mediawiki/debian.git
> But this seems outdated, the latest is 1:1.31.2-1
> This is empty:
> $ git grep "1.31.5-1" $(git rev-list --all)

I haven't pushed the latest stuff to Gerrit yet, but will do so soon.

> Therefore I'm using a clssic bug+debdiff for this.
> 
> There is an Ubuntu PPA already test building this:
> https://launchpad.net/~paelzer/+archive/ubuntu/bug-1852408-mediawiki-pg12/+packages
> 
> And a test log with the fix:
> http://paste.ubuntu.com/p/Q4nkfxbTNB/

Awesome, thank you for testing.

> Now onto the issue, with Postgres-12 there are a few incompatibilities
> which make mediawiki fail to autopkgtest correctly (and break it in
> general).
> 
> Fixes are upstream in 1.33 already but can be backported to 1.31 for a
> quick fix upload.

Upstream has backported them into 1.31 as well, so I'm going to upload a
1:1.31.5-2 with the fix shortly.

-- Kunal



signature.asc
Description: OpenPGP digital signature

Bug#934104: [pkg-php-pear] Bug#934104: composer: Don't use debian/copyright for LICENSE when generating autoloader

[Kunal Mehta]

Hi,

On 8/7/19 3:26 PM, David Prévot wrote:
>> First, vendor/ directories are no longer identical with people who use an
>> upstream version of composer or from a different distribution (example:
>> https://gerrit.wikimedia.org/r/#/c/mediawiki/vendor/+/526262/1/composer/LICENSE).
> 
> Why is that a problem?

It causes divergence on the output of vendor/ simply based on how
composer was installed and decreases reproducibility. In cases where the
output of vendor/ is audited (like we do at Wikimedia), this is much
more noticeable.

> ...

> I’ve updated the package to provide the upstream LICENSE file from
> /usr/share/php/data/Composer, so both issues should be fixed after the
> next upload, thanks.

Thank you very much!

-- Kunal

Bug#934104: composer: Don't use debian/copyright for LICENSE when generating autoloader

[Kunal Mehta]

Package: composer
Version: 1.9.0-2
Severity: important

0005-Pick-up-copyright-instead-of-LICENSE.patch switches the composer autoload
generator to use debian/copyright instead of upstream's LICENSE file. This is
problematic for a few reasons:

First, vendor/ directories are no longer identical with people who use an
upstream version of composer or from a different distribution (example:
https://gerrit.wikimedia.org/r/#/c/mediawiki/vendor/+/526262/1/composer/LICENSE).

And secondly, minimal installations (e.g. docker containers) of Debian that
don't keep doc/ around can no longer run composer install.

Is there a reason we need the patch? I could totally be missing something.

Thanks,
-- Kunal



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

Kernel: Linux 4.14.74-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 composer depends on:
pn  jsonlint 
pn  php-cli  
pn  php-common   
pn  php-composer-ca-bundle   
pn  php-composer-semver  
pn  php-composer-spdx-licenses   
pn  php-composer-xdebug-handler  
pn  php-json-schema  
pn  php-psr-log  
pn  php-symfony-console  
pn  php-symfony-filesystem   
pn  php-symfony-finder   
pn  php-symfony-process  

Versions of packages composer recommends:
ii  git1:2.20.1-2
ii  unzip  6.0-23

Versions of packages composer suggests:
pn  fossil  
pn  mercurial   
pn  php-zip 
pn  subversion  

Bug#931738: ITP: libkainjow-mustache -- Mustache text templates for modern C++

[Kunal Mehta]

Package: wnpp
Severity: wishlist
Owner: Kunal Mehta 

* Package name: libkainjow-mustache
  Version : 3.2.1
  Upstream Author : Kevin Wojniak 
* URL : https://github.com/kainjow/Mustache
* License : BSL-1.0
  Programming Lang: C++
  Description : Mustache text templates for modern C++

A header-only Mustache template implementation for C++11, with no
additional dependencies.

This is a new dependency for the latest version of libkiwix, replacing the
unmaintained ctpp2 library.

Bug#924331: RFA: pdf-redact-tools -- PDF Redact Tools helps with securely redacting and stripping

[Kunal Mehta]

Hi,

On 6/24/19 5:21 PM, Loic Dachary wrote:
> The VCS repository is at 
> https://salsa.debian.org/pkg-privacy-team/pdf-redact-tools. Please let me 
> know if you need anything else.

Could you add me (salsa username: legoktm) to that repository? Or I
suppose transfer it to me?

Thanks,
-- Kunal

Bug#924331: RFA: pdf-redact-tools -- PDF Redact Tools helps with securely redacting and stripping

[Kunal Mehta]

Hi,

On Mon, 11 Mar 2019 18:23:15 +0100 Loic Dachary  wrote:
> pdf-redact-tools is one of many tools journalists need to protect the 
> anonymity of their sources. Despite my desire to maintain the package and my 
> best efforts, I do not feel safe within Debian to do so. I kindly ask someone 
> to takeover.

I'm happy to take over packaging for this, it looks rather
straightforward, and is in my field of interest.

Is the packaging in a VCS repository anywhere?

And if Vipul is still interested, I can work with them as well.

-- Kunal

Bug#930899: ITP: podman -- Tool for running OCI-based containers

[Kunal Mehta]

Hi Nicolas,

There's already an open ITP for podman at #930440.

-- Kunal

Bug#930503: ITP: php-wmerrors -- PHP extension that enhances and customizes handling of PHP errors

[Kunal Mehta]

Package: wnpp
Severity: wishlist
Owner: Kunal Mehta 

* Package name: php-wmerrors
  Version : 2.0.0
  Upstream Author : Tim Starling 
* URL : https://gerrit.wikimedia.org/g/mediawiki/php/wmerrors
* License : MIT/Expat
  Programming Lang: C
  Description : PHP extension that enhances and customizes handling of PHP 
errors

wmerrors allows for customizing how PHP errors are handled and displayed to
the user. It is specifically designed for situations where userland code is
insufficient (e.g. OOM errors), but stacktraces and logging are still needed.

Some more explanation of where PHP's built-in error handling is insufficient
is at <https://phabricator.wikimedia.org/T187147#4298721>. The current
wmerrors development is to get it at feature parity with what HHVM provided.

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#928716: mediawiki: File uploads broken (UploadStashBadPathException)

[Kunal Mehta]

Hi,

On 5/9/19 10:11 AM, Chris Boot wrote:
> This will apparently be fixed in MediaWiki 1.31.2 when that's released,
> but given that file uploads appear to be non-functional it may be worth
> carrying a patch locally for the Buster release or soon after.

1.31.2 should be coming out later this week so I'll wait a little more
for it and upload once it's out.

And, thank you for testing :)

-- Kunal



signature.asc
Description: OpenPGP digital signature

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#925068: doxygen: search.php uses

[Kunal Mehta]

Hi,

On Wed, 20 Mar 2019 18:52:04 +0100 Paolo Greppi 
wrote:
> Another option is to just backport the upstream fix.

I think this is probably the best option for both buster and stretch. As
much as I'd like to see a new doxygen version in buster, #919413 looks a
little too impactful to do now that the freeze has started.

I backported the upstream patch to the doxygen currently in buster, and
it applied perfectly. Attached a debdiff, and uploaded a built .deb to
<https://people.debian.org/~legoktm/doxygen/>.

What do you think about just uploading that? If that looks good, I can
also prep something for stretch as well.

Thanks,
-- Kunal

diff -Nru doxygen-1.8.13/debian/changelog doxygen-1.8.13/debian/changelog
--- doxygen-1.8.13/debian/changelog	2018-03-12 01:22:14.0 -0700
+++ doxygen-1.8.13/debian/changelog	2019-03-20 18:23:59.0 -0700
@@ -1,3 +1,10 @@
+doxygen (1.8.13-11) UNRELEASED; urgency=medium
+
+  * QA upload.
+  * Fix search.php to be compatible with PHP 7.0+. (Closes: #925068)
+
+ -- Kunal Mehta   Wed, 20 Mar 2019 18:23:59 -0700
+
 doxygen (1.8.13-10) unstable; urgency=medium
 
   * Orphan the package. See: #888580.
diff -Nru doxygen-1.8.13/debian/patches/0008-added-PHP7-support-for-the-search-engine-on-HTML-out.patch doxygen-1.8.13/debian/patches/0008-added-PHP7-support-for-the-search-engine-on-HTML-out.patch
--- doxygen-1.8.13/debian/patches/0008-added-PHP7-support-for-the-search-engine-on-HTML-out.patch	1969-12-31 16:00:00.0 -0800
+++ doxygen-1.8.13/debian/patches/0008-added-PHP7-support-for-the-search-engine-on-HTML-out.patch	2019-03-20 18:22:41.0 -0700
@@ -0,0 +1,78 @@
+From: daMaex 
+Date: Thu, 22 Mar 2018 13:36:58 +0100
+Subject: added PHP7 support for the search engine on HTML output. See:
+ http://php.net/manual/en/language.basic-syntax.phptags.php
+
+---
+ src/htmlgen.cpp  | 8 
+ templates/html/search_functions.php  | 4 ++--
+ templates/html/search_opensearch.php | 4 ++--
+ 3 files changed, 8 insertions(+), 8 deletions(-)
+
+diff --git a/src/htmlgen.cpp b/src/htmlgen.cpp
+index 8856baf..4873573 100644
+--- a/src/htmlgen.cpp
 b/src/htmlgen.cpp
+@@ -2267,7 +2267,7 @@ void HtmlGenerator::writeSearchPage()
+   if (cf.open(IO_WriteOnly))
+   {
+ FTextStream t();
+-t << "\n\n";
++t << "<?php\n\n";
+ t << "$config = array(\n";
+ t << "  'PROJECT_NAME' => \"" << convertToHtml(projectName) << "\",\n";
+ t << "  'GENERATE_TREEVIEW' => " << (generateTreeView?"true":"false") << ",\n";
+@@ -2285,7 +2285,7 @@ void HtmlGenerator::writeSearchPage()
+ t << "  'split_bar' => \"" << substitute(substitute(writeSplitBarAsString("search",""), "\"","\\\""), "\n","\\n") << "\",\n";
+ t << "  'logo' => \"" << substitute(substitute(writeLogoAsString(""), "\"","\\\""), "\n","\\n") << "\",\n";
+ t << ");\n\n";
+-t << "\n";
++t << "?>\n";
+   }
+ 
+   ResourceMgr::instance().copyResource("search_functions.php",htmlOutput);
+@@ -2314,10 +2314,10 @@ void HtmlGenerator::writeSearchPage()
+   t << "" << endl;
+ }
+ 
+-t << "\n";
++t << "<?php\n";
+ t << "require_once \"search_functions.php\";\n";
+ t << "main();\n";
+-t << "\n";
++t << "?>\n";
+ 
+ // Write empty navigation path, to make footer connect properly
+ if (generateTreeView)
+diff --git a/templates/html/search_functions.php b/templates/html/search_functions.php
+index caa9e3b..7374de9 100644
+--- a/templates/html/search_functions.php
 b/templates/html/search_functions.php
+@@ -1,4 +1,4 @@
+-
++<?php
+ require_once "search_config.php";
+ 
+ function end_form($value)
+@@ -363,4 +363,4 @@ function main()
+   report_results($sorted);
+   end_page();
+ }
+-
++?>
+diff --git a/templates/html/search_opensearch.php b/templates/html/search_opensearch.php
+index 58ee4ab..95c1c2c 100644
+--- a/templates/html/search_opensearch.php
 b/templates/html/search_opensearch.php
+@@ -1,4 +1,4 @@
+-
++<?php
+ require "search_functions.php";
+ 
+ $mode = array_key_exists('v', $_GET)?$_GET['v']:"";
+@@ -125,4 +125,4 @@ function invalid_format($query, array $results)
+   print "Search results for '$query':\n\n";
+   print_r($results);
+ }
+-
++?>
diff -Nru doxygen-1.8.13/debian/patches/series doxygen-1.8.13/debian/patches/series
--- doxygen-1.8.13/debian/patches/series	2018-03-12 01:22:14.0 -0700
+++ doxygen-1.8.13/debian/patches/series	2019-03-20 18:23:02.0 -0700
@@ -10,3 +10,4 @@
 no-rpath.diff
 #issue759241.diff
 avoid-compass.diff
+0008-added-PHP7-support-for-the-search-engine-on-HTML-out.patch

Bug#856595:

[Kunal Mehta]

Hi,

On 2/16/19 7:35 PM, Pavel Minaev wrote:
> It looks like all the dependencies are now in Buster, thanks to Kunal.
> It would be a shame to have it all, except for the actual user-facing
> app that uses it...
> 
> Is there any chance that this package might make it into Buster? Is
> there any assistance I could provide to accelerate the process?

Unfortunately, we missed the deadline for buster already. But your help
would be appreciated!

We need to figure out a resolution to
, as you found. I think
that was the main blocker.

I pushed my packaging work to
, there are probably some
lintian warnings, etc. that need to be cleaned up.

Once we have something working and Buster is released, we can definitely
aim to get kiwix-tools into buster-backports.

-- 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#918310: php-respect-validation: Drop dependency upon php-symfony-polyfill-mbstring

[Kunal Mehta]

Package: php-respect-validation
Version: 1.1.15-1
Severity: normal
Tags: patch

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

The dependency upon php-symfony-polyfill-mbstring can safely be replaced with
php-mstring, which provides the extension itself. There is some relevant
discussion in #911832 as well. It's unlikely that the php-symfony-polyfill
package will be included at Buster at this time.

See attached patch.

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

Kernel: Linux 4.19.12-301.fc29.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)

Versions of packages php-respect-validation depends on:
ii  php-common 2:69
ii  php-symfony-polyfill-mbstring  1.9.0-1

php-respect-validation recommends no packages.

Versions of packages php-respect-validation suggests:
pn  php-bcmath
pn  php-egulias-email-validator   
pn  php-fabpot-php-cs-fixer   
ii  php-mbstring  2:7.3+69
pn  php-symfony-validator 
pn  php-zendframework-zend-validator  
ii  php7.3-mbstring [php-mbstring]7.3.0-2

-BEGIN PGP SIGNATURE-

iQJHBAEBCgAxFiEE+h6fmkHn9DUCyl1jUvyOe+23/KIFAlwv3EoTHGxlZ29rdG1A
ZGViaWFuLm9yZwAKCRBS/I577bf8oqM1D/4j8fH4b95XILGV7vf0QEpheW6K0soe
/1cKpa4cOqCrwihSCgqKAG6Bv56fQczio5UMsE+Y8Y/L6kkSS0vDSk9SZXG9LENt
akpCPfT7BChCbCTVjn/Efz67eApqELIkGGTS99XU887ia4k+BijKrJybzfJOXZOl
b/01FmqzN0zEtoY32zqNjSrSWS8oPlzfabxekh070M60aDW7OnRKe5B7o4yE4tsX
vIdgICOCsmsd1Za7e/3XNVutObZ9AZe4zcWiM4rUvDIsaktMopGqrCTY2sMEXJT+
RqNBBQpYd4dNA3jcr3mMbznoBetneUhxt//fbIlc1yRBrVNo6rFL7GYzVndSj/jX
7O+dO2UtecrRGwivDBuOwv0RsKjzXSyPKAhsOk/bTRajNXIN/oKAhelOqnXEvLzh
FNC7pHXxjLUYqazwmWtQw+fEn0rFUu/xyYTKT4XJ7BFUX/4DFIBraMBFJuhN2xwA
rDNlxlzYsS48QeL0RKTTfbJhbmhTT3wL8tKPQhOQyaZJz/bPcNR/Qs4Q/PlA4ncv
Wz5shKZf/fzpctqnmDKX/sy7ngiPSw6YGmbNMlAfYvh9Vt2GPcCL8R79XDmGxl60
ekByNFdF87rZNb7bNkWaaJKPGFnQ92wo/Z+Y6JC9AE61d6Cq5p8DP2u8e71Ei0RG
xw7oB5PX7zzkMQ==
=bd+z
-END PGP SIGNATURE-
>From 025b159765ca33f2c49b66c2e68b3964a7491e30 Mon Sep 17 00:00:00 2001
From: Kunal Mehta 
Date: Fri, 4 Jan 2019 14:15:03 -0800
Subject: [PATCH] Drop dependency upon php-symfony-polyfill-mbstring in favor
 of php-mbstring

Instead of using a polyfill, we can simply depend upon the actual PHP
extension. There's some relevant discussion in #911832 as well.

Using the override file, we can disable the automatic dependency and add
php-mbstring in d/control.

Closes: #-1
---
 debian/control | 2 +-
 debian/pkg-php-tools-overrides | 1 +
 2 files changed, 2 insertions(+), 1 deletion(-)
 create mode 100644 debian/pkg-php-tools-overrides

diff --git a/debian/control b/debian/control
index 832d20f..892e2f8 100644
--- a/debian/control
+++ b/debian/control
@@ -11,7 +11,7 @@ Vcs-Browser: 
https://salsa.debian.org/tdtf-team/php-respect-validation
 
 Package: php-respect-validation
 Architecture: all
-Depends: ${misc:Depends}, ${phpcomposer:Debian-require}
+Depends: ${misc:Depends}, php-mbstring, ${phpcomposer:Debian-require}
 Recommends: ${phpcomposer:Debian-recommend}
 Suggests: ${phpcomposer:Debian-suggest}
 Replaces: ${phpcomposer:Debian-replace}
diff --git a/debian/pkg-php-tools-overrides b/debian/pkg-php-tools-overrides
new file mode 100644
index 000..f295d3d
--- /dev/null
+++ b/debian/pkg-php-tools-overrides
@@ -0,0 +1 @@
+symfony polyfill-mbstring none
-- 
2.20.1

Bug#918307: civicrm-common: Drop dependency upon php-symfony-polyfill-iconv

[Kunal Mehta]

Package: civicrm-common
Version: 5.8.2+dfsg-1
Severity: normal
Tags: patch

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

The dependency upon php-symfony-polyfill-iconv can safely be dropped, since
php-common already provides the iconv extension. There is some relevant
discussion in #911832 as well. It's unlikely that the php-symfony-polyfill
package will be included at Buster at this time.

See attached patch.

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

Kernel: Linux 4.19.12-301.fc29.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)

Versions of packages civicrm-common depends on:
pn  ckeditor  
pn  fonts-font-awesome
pn  libjs-backbone
pn  libjs-d3  
pn  libjs-jquery-datatables   
pn  libjs-jquery-form 
pn  libjs-jquery-mousewheel   
pn  libjs-jquery-ui   
pn  libjs-prettify
pn  libjs-qunit   
ii  php-common2:69
pn  php-dompdf
pn  php-htmlpurifier  
ii  php-mbstring  2:7.3+69
ii  php-psr-log   1.1.0-1
pn  php-psr-simple-cache  
pn  php-seclib
pn  php-symfony-config
pn  php-symfony-dependency-injection  
pn  php-symfony-event-dispatcher  
ii  php-symfony-filesystem3.4.20+dfsg-1
ii  php-symfony-finder3.4.20+dfsg-1
pn  php-symfony-polyfill-iconv
ii  php-symfony-process   3.4.20+dfsg-1
pn  php-tcpdf 
ii  php-xml   2:7.3+69
ii  php7.3-mbstring [php-mbstring]7.3.0-2
ii  php7.3-xml [php-xml]  7.3.0-2

Versions of packages civicrm-common recommends:
pn  civicrm-l10n
ii  php-curl2:7.3+69
ii  php-zip 2:7.3+69
ii  php7.3-curl [php-curl]  7.3.0-2
ii  php7.3-zip [php-zip]7.3.0-2
pn  wkhtmltopdf 
pn  xvfb

Versions of packages civicrm-common suggests:
pn  wordpress-civicrm  

-BEGIN PGP SIGNATURE-

iQJHBAEBCgAxFiEE+h6fmkHn9DUCyl1jUvyOe+23/KIFAlwv2VgTHGxlZ29rdG1A
ZGViaWFuLm9yZwAKCRBS/I577bf8ot4kD/4i8yPQS+hf4v1zb+Xi/Z2npt3/qkH2
c6yVqaYVZ7PfNtTIJqdzQHsTuEPaPwnoCfnIHmQpz1AjqtUSzJuSUQzehfYfRUVU
3pq9JP1rvfzz7Chr8iC8BxMgYE04bsFJGtAc2JlQg2o6Yfwoefu+wavb9ECfuylS
hI6YB12ICGqa475IeEpYzjTqn14KlbYcju223QzE2cVgL0k1NrqRBltwNcERJn6j
AN+mmo57OalXbdBg+3BxDsuP33V4zh3cnSa8BrO7k2vLg5LhkGeErs+a+roBrEVR
1Kt/RHTBxgZhhj8NHGKQ0vk8tEnVScJdC4LQpU6Ls3oEBeTX+uUonpLqbjWBYjgT
kH2rQs25bSjX6wV9G75V2E0jNLQ0KbRSFEA2DffkTdawIU3OEIakFMcEIEa+HnMN
h4IiY0EF7RTAozKyn48pxrOXSAxlg0WoPIssztUUFHQTLBWcGCDoaiFH5Gx+AGls
NVZ+wk30wW09WF/zpLDizHUJEgpqlBaEaeRyLvjOo6+d0BIdqkKRfahpGZt4MsJT
4vVoTIEMbqy3veXur51oJ2mBc4OaOJbCLtUrVFhRZ3iz//SYJHMu5UiFqv1044FB
BPPXwLSvaNzHD2f5ZiJU74PL1lQzffdIg+32RlKFXOH27VNJKVLVKEmGlzMAUT1M
QTFHrjIy8i4DIA==
=ARKH
-END PGP SIGNATURE-
>From 53113969df12cbc463ad1e480370cd3fa3191a4d Mon Sep 17 00:00:00 2001
From: Kunal Mehta 
Date: Fri, 4 Jan 2019 13:45:41 -0800
Subject: [PATCH] Don't depend on php-symfony-polyfill-iconv

The iconv extension is included in php-common, so there's no need to include
a polyfill for it. See discussion on #911832 for some more rationale.

Closes: #-1
---
 debian/pkg-php-tools-overrides | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/debian/pkg-php-tools-overrides b/debian/pkg-php-tools-overrides
index dd20818..f350393 100644
--- a/debian/pkg-php-tools-overrides
+++ b/debian/pkg-php-tools-overrides
@@ -23,3 +23,5 @@ pear  net_smtpnone
 #pear  net_socket  php-net-socket
 pear   net_socket  none
 
+## Provided by PHP
+symfonypolyfill-iconv  builtin
-- 
2.20.1

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#916680: RM: mediawiki-math -- ROM; removed upstream

[Kunal Mehta]

Package: ftp.debian.org
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

texvc (built from mediawiki-math) was removed upstream, and is no longer
supported in favor of a nodejs web service ("mathoid") that has a lot more
features. See  for the full details.

If/when mathoid is packaged for Debian, it will be in a different source
package anyways.

Thanks,
- -- Kunal

-BEGIN PGP SIGNATURE-

iQJHBAEBCgAxFiEE+h6fmkHn9DUCyl1jUvyOe+23/KIFAlwXeoATHGxlZ29rdG1A
ZGViaWFuLm9yZwAKCRBS/I577bf8ojTFD/0ZsTHW+PUx4JDXmeAMXvRNByKb/l5T
+4F01yMJaVqfevqnDblQql/6/sdlQDJioo6torleEF3g2HK9P8RRlGJFIOmC24/L
r9YauMCi8vwH/yoMCriJGASQEL9RDCgS7KsK7GbhLLu9UTrk289Va+YzxLuK1Vm9
tJsf+nI+bywx8Pxv+oP+23L/quLBsb1zr0LFWJbweB2LfJYL2Wkg//S6YHvmHWpY
pP2bXy0xRMngJUjhaT5D+QjzadfXUgedcetpT3WuEpX8qAyKKTWDdKaAWSHOEzsN
muImduINMUQI/ianqEF4+uVNDoesWIuEIgxbgVEXbLTw4ELGyBgaYNg1FtW57KJ3
L89fiRi9oeoNzYzcBAwCTMBOYXNV3oMrbzhUwOJksfyxUSLVo22Rhpo8AhhSNLQM
IrrFP4/54YoB5uPhYo9Z46AsQyfbjj/kK3SVaZ1b4eFg+HQF9B49Y23uQkg6yvxq
IjL+hYG42DNGBuTVzW+ldzc8X7961G8y0yO6dClTIIKhMjvJee/5+fVuORHlnU8z
wvVfVZBMiFRB4j6EAmhhbzgGjPKzZRmPf92bNFoXkWhG45jGEaRSDH9JZeEK0mAR
PdC+7+sVY2tl9rZKYTadeZ8hpyNMixz7EEeSN/TliZ2UUszqATHACGtswtN4uE1k
GbH5OkNO7upO6g==
=eibW
-END PGP SIGNATURE-

Bug#886120: ctpp2: diff for NMU version 2.8.3-25.1

[Kunal Mehta]

Hi,

On 12/2/18 11:56 AM, gregor herrmann wrote:
> I've prepared an NMU for ctpp2 (versioned as 2.8.3-25.1) and
> uploaded it to DELAYED/5. Please feel free to tell me if I
> should delay it longer.

Thanks, it seems fine to me. I'm also happy to do a standard upload, I'm
not sure if that would be preferred since you've already uploaded this one.

-- Kunal



signature.asc
Description: OpenPGP digital signature

Bug#915244: quassel: New 0.13.0 version available

[Kunal Mehta]

Source: quassel
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Quassel 0.13.0 was released on 2018-11-17: .

This release is expected to bring UI improvements, better IRCv3 support, and
increased support for mobile clients, among plenty of other changes. There's
a more complete changelog available:
.

It would be wonderful if this new version could be packaged in time for
Buster.

Thanks,

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

Kernel: Linux 4.19.4-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 /usr/bin/dash
Init: systemd (via /run/systemd/system)

-BEGIN PGP SIGNATURE-

iQJHBAEBCgAxFiEE+h6fmkHn9DUCyl1jUvyOe+23/KIFAlwDTXcTHGxlZ29rdG1A
ZGViaWFuLm9yZwAKCRBS/I577bf8otoUD/9Mdt6meZmp/JD4chFtsW6dJW6iXBdJ
LRWm2SAllbNMjtY7BFfX4mp024qYA/tlXNnURGDIcSDkDryKgwh0f7Halz2gJsgv
5kfUF7KVl6S631bX5qQ4OycAZIe+YI61i6rG8P34Td+JOThLCtHpQKYtKG99VAgf
UUjUUnoS6qATvRs1zSvppHbrO1WiEfegJ3uJU/QUqmbDjYxqOwp0/AxgJFzfUYmB
6anJOd7QU8hXBJQEWR0P5NZeEtRX4nx1FO3vIZuiujiZz3928q+c8j7HEIKMv3uD
sXEs1itbBsc6mVCGd6fU7fd3QVtrby+4JnG4IYGbeCIioRI5QU76VNA8gBRBmXU5
nSYKZQMOLi+PLdN3W4xZVLI6+yNWJirOt3WMvkQqtiMIgL75yZ3GW/82PT4NzF1m
oGPEjKql14zgb6+pKv3SsDqxM4cj7Z7e9xt+tXCjszjeBTPlF4Uc8jGn0X6/8yNb
TNiczSf7Vs1U3upbZxZjhjXZzj4MhcP9rkoAoXvz2dLEGuoua6chLAvg+BFn09f7
Ac93+SnW5pj1to+uGIMC2WvBcrBO/fvvCONKrYHjo5ME/RwWeCUzObbQSUreVX7n
HI2YLKc4YU4A+SrAWyx183tRnbqsW5X/CbrWNXB+MTpamFilnkcn1CZY0ONP0pIL
AmvpFWJUlXH7pg==
=wpM6
-END PGP SIGNATURE-

Bug#913773: dh-php: pkg-pecl.mk does not run extension tests during build

[Kunal Mehta]

Package: dh-php
Version: 0.34
Severity: wishlist
Tags: patch

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

I was looking into porting php-luasandbox to fully build with pkg-pecl.mk, and
I noticed that it wasn't running the luasandbox tests during the package
build process.

I have provided a patch at 
.

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 /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages dh-php depends on:
ii  debhelper   11.5.3
ii  liblist-moreutils-perl  0.416-1+b4
ii  perl5.28.0-3
ii  xml20.5-2

dh-php recommends no packages.

dh-php suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQJHBAEBCgAxFiEE+h6fmkHn9DUCyl1jUvyOe+23/KIFAlvsv68THGxlZ29rdG1A
ZGViaWFuLm9yZwAKCRBS/I577bf8ogGzD/9Tczv9fqT0Uufh46FO7JErFgeeCRMY
S249UynluTeBP2DLSNjnMvZsAYnSRoAwBkDm8HNOflLz/8h3FkhKzoC2auWDTLm4
nNv/mR7rN3L5ueDiw2KUV9GllBULKSd1PHJrdovdVlcuyBkoIDhs/3X/GkMBXI3c
G8uO2Q6q8JaIyUFIp0StgAHHMFJ2hSw7Wur1hVEAt5Uia5m7aVpWQ+mg86Tll4F2
dh87G/R1bcnqn/TqOEj9743y6yh4DAolL0XoEqWRwzeJvuFrXYeFweZkQIIoiGne
2Fdh7OahxdBnkyLoQAeCWdcdNNZzukXlxr8PDPpN43/i52bDlvkziVUHSUAOee75
9ByS0LSxeBlDrcwzVSskSxCqek4s4Ssr7d9TYH9MVjFjGFyCkAlsHJPvYf6K1hkT
sTICpqpPekhD0q2sNF9nFaFPvvKTuXWHqX2vRgoOqOVx1VaIpFMnzbufJMKYqD5V
9z0TW/osFakpYQmYgCJN3/+D34DXgEccQCKf/U4USLIZJLEfflrlDqtm9njZIpqy
1iEunvvlEHfO5/UU9xaHCRGuZVRGybIgsWvJ/8e0LqCn9+lqoNmBjrP1XTOrLVg7
pY+uaDAJa3W1WsdkzwSo2onasa844I6jeo0TADWYSyeW1CmiRY2DeoUOzTIZGMAP
WbFsBh1Xw1Tonw==
=WccA
-END PGP SIGNATURE-

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#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#913506: libkiwix FTBFS with ICU 63.1

[Kunal Mehta]

control: tags -1 fixed-upstream

Hi,

On 11/11/18 11:13 AM, László Böszörményi (GCS) wrote:
> ICU 63.1 recently released, packaged and uploaded to experimental.
> Its transition is going to start soon. However your package fails to
> build with this version. I attach a patch which fixes the problem.
> Please check if it works with the version in Sid and upload the
> package when it's feasible for you.

Thank you for the patch, it looks like upstream has already fixed
this[1]. Updating to the latest release is blocked on updating libzim
(currently in NEW/experimental), so hopefully I'll be able to do that soon.

[1]
https://github.com/kiwix/kiwix-lib/commit/9aaf82a36d6612b4826b8720de356be0f7110b00

-- Kunal



signature.asc
Description: OpenPGP digital signature

Bug#871594: mediawiki-extensions-universallanguageselector - package description not really understandable

[Kunal Mehta]

Hi,

On Fri, 18 Aug 2017 20:48:09 +0200 (CEST) Tomas Pospisek
 wrote:
> Hello Kartik Mistry,
> 
> the description you chose for your package is: "Tool to select a language 
> and configure for MediaWiki".
> 
> What does "select a configure" mean? Do you mean "select a configuration"?
> 
> Or do you mean "Tool to select and configure a language for MediaWiki"?

I think the following should be clearer: "Tool to select a language and
configure it for MediaWiki".

To clarify, ULS allows you to pick a language to render the interface
in, and then it allows you to configure that language by enabling web
fonts or an IME.

-- Kunal