Bug#1067061: RM: kvirc [armel ppc64el riscv64 s390x] -- RoM; ANAIS; new version needs qtwebengine5-dev

[Andrey Rahmatullin]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: kv...@packages.debian.org
Control: affects -1 + src:kvirc
User: ftp.debian@packages.debian.org
Usertags: remove

AFAICS this is the list of release architectures currently lacking
qtwebengine5-dev. All subpackages are AFAIK leaf packages.

Bug#1067047: Buildng the package removes debian/.gitlab-ci.yml

[Andrey Rahmatullin]

Source: gnucash
Version: 1:5.5-1.1
Severity: serious

Simply build the package from source produces a source package that doesn't
contain debian/.gitlab-ci.yml in debian.tar, one needs to rebuild the source
package separately, skipping the clean target. The reason for that is that the
file is listed debian/clean for some reason (alternatively, if it shouldn't be
in the package, please remove it from the package).


-- System Information:
Debian Release: trixie/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 
'unstable'), (500, 'testing'), (101, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.7.9-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.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

Bug#1066994: RM: libjconv -- RoQA; orphaned; dead upstream; RC-buggy; leaf library

[Andrey Rahmatullin]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: libjc...@packages.debian.org
Control: affects -1 + src:libjconv
User: ftp.debian@packages.debian.org
Usertags: remove

Last (the only) upstream upload 2001, last maintainer upload 2001, orphaned
since 2007. The upstream doesn't seem to exist anymore. While the description
says "it is used as helper in sylpheed mailer", sylpheed actually dropped it in
2003.
Currently FTBFS with -Werror=implicit-function-declaration.

wrar@coccia:~$ dak rm -Rn libjconv
Will remove the following packages from unstable:

  libjconv |  2.8-7 | source
libjconv-bin |  2.8-7 | riscv64
libjconv-bin |   2.8-7+b1 | amd64, arm64, armel, armhf, i386, mips64el,
ppc64el, s390x
libjconv-dev |  2.8-7 | riscv64
libjconv-dev |   2.8-7+b1 | amd64, arm64, armel, armhf, i386, mips64el,
ppc64el, s390x
 libjconv2 |  2.8-7 | riscv64
 libjconv2 |   2.8-7+b1 | amd64, arm64, armel, armhf, i386, mips64el, ppc64el,
s390x

Maintainer: Debian QA Group 

--- Reason ---

--

Checking reverse dependencies...
No dependency problem found.

Bug#1066993: RM: libpcl1 -- RoQA; orphaned; dead upstream; RC-buggy; leaf library

[Andrey Rahmatullin]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: libp...@packages.debian.org
Control: affects -1 + src:libpcl1
User: ftp.debian@packages.debian.org
Usertags: remove

Last upstream release 2010, orphaned since 2016 (but last maintainer upload
2006), FTBFS with -Werror=implicit-function-declaration.

wrar@coccia:~$ dak rm -Rn libpcl1
Will remove the following packages from unstable:

   libpcl1 | 1.12-2 | source, amd64, arm64, armel, armhf, i386, mips64el,
ppc64el, riscv64, s390x
libpcl1-dev | 1.12-2 | amd64, arm64, armel, armhf, i386, mips64el, ppc64el,
riscv64, s390x

Maintainer: Debian QA Group 

--- Reason ---

--

Checking reverse dependencies...
No dependency problem found.

Bug#1066990: RM: libgpiv -- RoQA; orphaned; dead upstream; RC-buggy; leaf library

[Andrey Rahmatullin]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: libg...@packages.debian.org
Control: affects -1 + src:libgpiv
User: ftp.debian@packages.debian.org
Usertags: remove

It now FTBFS with -Werror=implicit-function-declaration because it uses
gets(3).

Last upstream release 2008, orphaned since 2016.


wrar@coccia:~$ dak rm -Rn libgpiv
Will remove the following packages from unstable:

   libgpiv |  0.6.1-7.1 | source
   libgpiv |  0.6.1-7.2 | source
libgpiv-mpi3 | 0.6.1-7.1+b2 | armel, armhf
libgpiv-mpi3t64 |  0.6.1-7.2 | amd64, arm64, i386, mips64el, ppc64el, riscv64,
s390x
  libgpiv3 | 0.6.1-7.1+b2 | armel, armhf
libgpiv3-common | 0.6.1-7.1+b2 | armel, armhf
libgpiv3-common |  0.6.1-7.2 | amd64, arm64, i386, mips64el, ppc64el, riscv64,
s390x
libgpiv3-dev | 0.6.1-7.1+b2 | armel, armhf
libgpiv3-dev |  0.6.1-7.2 | amd64, arm64, i386, mips64el, ppc64el, riscv64,
s390x
libgpiv3-doc |  0.6.1-7.1 | all
libgpiv3-doc |  0.6.1-7.2 | all
libgpiv3t64 |  0.6.1-7.2 | amd64, arm64, i386, mips64el, ppc64el, riscv64,
s390x

Maintainer: Debian QA Group 

--- Reason ---

--

Checking reverse dependencies...
No dependency problem found.

Bug#1066930: nmu: vlc-plugin-pipewire_3-3

[Andrey Rahmatullin]

Package: release.debian.org
Severity: normal
X-Debbugs-Cc: vlc-plugin-pipew...@packages.debian.org
Control: affects -1 + src:vlc-plugin-pipewire
User: release.debian@packages.debian.org
Usertags: binnmu

nmu vlc-plugin-pipewire_3-3 . ANY . unstable . -m "Rebuild for time_t"

Bug#1065751: Incomplete fix for xz -T1

[Andrey Rahmatullin]

Package: pristine-tar
Version: 1.50+nmu1
Severity: serious
X-Debbugs-Cc: Sebastian Andrzej Siewior 

It looks like #1063252 was not enough to support tar.xz files created by new
xz-utils. I've created a tarball, committed it into my gbp repo, checked it out
and xz -lvv doesn't show the cu flags for it (and so it's not identical to the
original one). As making a minimal example involving git sounds too complicated
I tried to make a minimal example with raw commands, hopefully I did that
correctly:

$ mkdir 1
$ echo foo > 1/bar
$ tar cJf 1.tar.xz 1
$ xz -lvv 1.tar.xz
[...]
Flags
cu
[...]
$ pristine-tar gendelta 1.tar.xz 1.tar.xz.delta

$ cd 1
$ pristine-tar gentar ../1.tar.xz.delta ../2.tar.xz
$ xz -lvv ../2.tar.xz
[...]
Flags
--
[...]


-- System Information:
Debian Release: trixie/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 
'unstable'), (500, 'testing'), (101, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.7.7-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.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 pristine-tar depends on:
ii  bzip21.0.8-5+b2
ii  libbz2-1.0   1.0.8-5+b2
ii  libc62.37-15.1
ii  libsys-cpuaffinity-perl  1.13~03-2+b3
ii  pbzip2   1.1.13-1
ii  perl 5.38.2-3.2
ii  pixz 1.0.7-2
ii  tar  1.35+dfsg-3
ii  xdelta   1.1.3-10.6
ii  xdelta3  3.0.11-dfsg-1.2
ii  xz-utils 5.6.0-0.2
ii  zlib1g   1:1.3.dfsg-3.1

pristine-tar recommends no packages.

pristine-tar suggests no packages.

-- debconf-show failed

Bug#1065531: apt forced libexpat1 to be removed before python3.11-minimal

[Andrey Rahmatullin]

Package: apt,python3.11-minimal
Severity: normal

Control: affects -1 python3-scrapy

During piuparts testing of python3-scrapy piuparts asked apt to remove packages
including python3* and libexpat1, and libexpat1 was removed before e.g.
python3.11-minimal which depends on it, with dpkg printing a warning about this
fact. But as prerm of python3.11-minimal needs libexpat1, prerm and the apt
transaction failed with "/usr/bin/python3: error while loading shared
libraries: libexpat.so.1: cannot open shared object file". The full log is
currently available at
https://piuparts.debian.org/sid/fail/python3-scrapy_2.11.1-1.log and I'm also
attaching it. The relevant part is the last one.

There are several additional things to note:

1. "python3.11-minimal depends on libexpat1" is not the only dependency problem
reported for the transaction, there are several other problems reported later,
all involving python3{,.11} subpackages.
2. This happened during the t64 transition, involved versions of src:expat and
src:python3-defaults are older than that while src:python3.11 (= 3.11.8-2) is
related to it.
3. piuparts asked apt to remove (among other packages) libssl3t64 and install
libssl3:amd64=3.1.5-1, but libssl3* aren't related to libexpat1,
python3.11-minimal also doesn't depend on them.


-- System Information:
Debian Release: trixie/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 
'unstable'), (500, 'testing'), (101, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.7.7-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.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
Start: 2024-03-01 10:02:29 GMT

Package: python3-scrapy
Source: python-scrapy
Version: 2.11.1-1
Installed-Size: 1052
Maintainer: Debian Python Team 
Architecture: all
Depends: python3-lxml, python3-pydispatch, python3-cryptography (>= 36.0.0), 
python3-cssselect, python3-itemadapter, python3-itemloaders, python3-openssl, 
python3-packaging, python3-parsel (>= 1.8.1), python3-pkg-resources, 
python3-protego, python3-queuelib, python3-service-identity, 
python3-tldextract, python3-twisted, python3-w3lib, python3-zope.interface, 
python3:any
Recommends: ipython3, python3-brotli, python3-pil
Suggests: python3-boto3, python3-botocore, python-scrapy-doc (= 2.11.1-1)
Description: Python web scraping and crawling framework (Python 3)
Homepage: https://scrapy.org/
Description-md5: de81941edea93a8d65f470aa9a6bbc8a
Section: python
Priority: optional
Filename: pool/main/p/python-scrapy/python3-scrapy_2.11.1-1_all.deb
Size: 259188
MD5sum: 74540053503bba92acf4db683413d6c7
SHA256: 449a3cce5c5ebf1fe93141cecc0088e14a7f2997eacb20bf9dd14b27048e2edf

Executing: sudo env 
PYTHONPATH=/srv/piuparts.debian.org/lib/python3/dist-packages timeout -s INT -k 
5m 80m /srv/piuparts.debian.org/sbin/piuparts --scriptsdir 
/etc/piuparts/scripts-log-alternatives --scriptsdir /etc/piuparts/scripts 
--no-eatmydata --allow-database --warn-on-leftovers-after-purge --mirror 
'http://deb.debian.org/debian/ main' --tmpdir /srv/piuparts.debian.org/tmp 
--arch amd64 -b 
/srv/piuparts.debian.org/slave/basetgz/sid-merged-usr_amd64.tar.gz -d sid 
--no-upgrade-test --apt python3-scrapy=2.11.1-1
0m0.0s INFO: 
--
0m0.0s INFO: To quickly glance what went wrong, scroll down to the bottom of 
this logfile.
0m0.0s INFO: FAQ available at https://wiki.debian.org/piuparts/FAQ
0m0.0s INFO: The FAQ also explains how to contact us in case you think piuparts 
is wrong.
0m0.0s INFO: 
--
0m0.0s INFO: piuparts version 1.3.1~202401311836~1.3-2-g28295102 starting up.
0m0.0s INFO: Command line arguments: /srv/piuparts.debian.org/sbin/piuparts 
--scriptsdir /etc/piuparts/scripts-log-alternatives --scriptsdir 
/etc/piuparts/scripts --no-eatmydata --allow-database 
--warn-on-leftovers-after-purge --mirror 'http://deb.debian.org/debian/ main' 
--tmpdir /srv/piuparts.debian.org/tmp --arch amd64 -b 
/srv/piuparts.debian.org/slave/basetgz/sid-merged-usr_amd64.tar.gz -d sid 
--no-upgrade-test --apt python3-scrapy=2.11.1-1
0m0.0s INFO: Running on: Linux piu-slave-ubc-01 5.10.0-28-amd64 #1 SMP Debian 
5.10.209-2 (2024-01-31) x86_64
0m0.0s DEBUG: Created temporary directory 
/srv/piuparts.debian.org/tmp/tmpq3za2o4e
0m0.0s DEBUG: Unpacking 
/srv/piuparts.debian.org/slave/basetgz/sid-merged-usr_amd64.tar.gz into 
/srv/piuparts.debian.org/tmp/tmpq3za2o4e
0m0.0s DEBUG: Starting command: ['tar', '-C', 
'/srv/piuparts.debian.org/tmp/tmpq3za2o4e', '--auto-compress', '-xf', 
'/srv/piuparts.debian.org/slave/basetgz/sid-merged-usr_amd64.tar.gz']
0m0.6s DEBUG: Command ok: ['tar', '-C', 

Bug#1065469: Can't upgrade: trying to overwrite '/usr/share/doc/qemu-system-common/system/arm/aspeed.html'

[Andrey Rahmatullin]

On Tue, Mar 05, 2024 at 09:22:37AM +0300, Michael Tokarev wrote:
> > Package: qemu-system-data
> > Version: 1:8.2.2+ds-1
> > Severity: serious
> > 
> > 
> > Preparing to unpack .../qemu-system-data_1%3a8.2.2+ds-1_all.deb ...
> > Unpacking qemu-system-data (1:8.2.2+ds-1) over (1:8.2.1+ds-2) ...
> > dpkg: error processing archive /var/cache/apt/archives/qemu-system-
> > data_1%3a8.2.2+ds-1_all.deb (--unpack):
> >   trying to overwrite '/usr/share/doc/qemu-system-
> > common/system/arm/aspeed.html', which is also in package qemu-system-common
> > 1:8.2.1+ds-2
> 
> Hmm.
> 
> In 8.2.2 I moved common docs from arch-dependent package qemu-system-common
> to arch-indep package qemu-system-data.  Current control fields for the
> latter, among others, has:
> 
>  Breaks: qemu-system-common (<< 8.2.1+ds-3~),
>  Replaces: qemu-system-common (<< 8.2.1+ds-3~),
> 
> so... what's going on here?  q-s-d 8.2.2 replaces files from q-s-c 8.2.1
Can it be simply because the package has an epoch and relations should
include it?

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#1065469: Can't upgrade: trying to overwrite '/usr/share/doc/qemu-system-common/system/arm/aspeed.html'

[Andrey Rahmatullin]

Package: qemu-system-data
Version: 1:8.2.2+ds-1
Severity: serious


Preparing to unpack .../qemu-system-data_1%3a8.2.2+ds-1_all.deb ...
Unpacking qemu-system-data (1:8.2.2+ds-1) over (1:8.2.1+ds-2) ...
dpkg: error processing archive /var/cache/apt/archives/qemu-system-
data_1%3a8.2.2+ds-1_all.deb (--unpack):
 trying to overwrite '/usr/share/doc/qemu-system-
common/system/arm/aspeed.html', which is also in package qemu-system-common
1:8.2.1+ds-2


-- System Information:
Debian Release: trixie/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 
'unstable'), (500, 'testing'), (101, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.7.7-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.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

-- debconf-show failed

Bug#1065315: libcurl4t64 Provides libcurl3-gnutls

[Andrey Rahmatullin]

Package: libcurl4t64
Version: 8.6.0-3.1
Severity: serious
X-Debbugs-Cc: vor...@debian.org, aure...@debian.org

Yet another case of wrong X-Time64-Compat, found by Aurelien.


-- System Information:
Debian Release: trixie/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 
'unstable'), (500, 'testing'), (101, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.7-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.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 libcurl4t64 depends on:
ii  libbrotli11.1.0-2+b3
ii  libc6 2.37-15.1
ii  libgssapi-krb5-2  1.20.1-5+b1
ii  libidn2-0 2.3.7-2
ii  libldap-2.5-0 2.5.13+dfsg-5+b3
ii  libnghttp2-14 1.59.0-1
ii  libpsl5   0.21.2-1+b1
pn  libpsl5t64
ii  librtmp1  2.4+20151223.gitfa8646d.1-2+b2
ii  libssh2-1t64 [libssh2-1]  1.11.0-4.1
ii  libssl3t64 [libssl3]  3.1.5-1.1
ii  libzstd1  1.5.5+dfsg2-2
ii  zlib1g1:1.3.dfsg-3.1

Versions of packages libcurl4t64 recommends:
ii  ca-certificates  20240203

libcurl4t64 suggests no packages.

Bug#1065155: libpoppler-glib8t64 Provides libpoppler-cpp0v5 instead of libpoppler-glib8

[Andrey Rahmatullin]

Package: libpoppler-glib8t64
Version: 22.12.0-2.1
Severity: serious
X-Debbugs-Cc: Steve Langasek 

Actually, looking at the diff in #1064282, all packages have "X-Time64-Compat:
libpoppler-cpp0v5", I guess this is incorrect and a typo?


-- System Information:
Debian Release: trixie/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 
'unstable'), (500, 'testing'), (101, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.7-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.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 libpoppler-glib8t64 depends on:
ii  libc6 2.37-15.1
ii  libcairo2 1.18.0-1+b1
ii  libfreetype6  2.13.2+dfsg-1+b1
ii  libglib2.0-0t64   2.78.4-2.1
pn  libpoppler126t64  
ii  libstdc++614-20240221-2.1

libpoppler-glib8t64 recommends no packages.

libpoppler-glib8t64 suggests no packages.

Bug#1065154: libqt5sql5t64 Provides libqt5core5a instead of libqt5sql5

[Andrey Rahmatullin]

Package: libqt5sql5t64
Version: 5.15.10+dfsg-7.1
Severity: serious
X-Debbugs-Cc: vor...@debian.org

I haven't checked but the same problem may also be present for other
subpackages.


-- System Information:
Debian Release: trixie/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 
'unstable'), (500, 'testing'), (101, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.7-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.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

Bug#1063946: python-parsel: autopkgtest regression with pytest 8

[Andrey Rahmatullin]

Control: reassign -1 python3-sybil 6.0.2-1
Control: affects -1 + src:python-parsel src:python-scrapy 
src:python-testfixtures src:pytest-mpi
Control: retitle -1 Incompatible with pytest 8


On Thu, Feb 15, 2024 at 11:36:57AM +0100, roehl...@debian.org wrote:
> Package: python-parsel
> Version: 1.8.1+dfsg-1
> Severity: important
> User: debian-pyt...@lists.debian.org
> Usertags: pytest-8
> 
> Dear maintainer,
> 
> your package has a autopkgtest regression with pytest 8.
This is caused by code in python3-sybil and should be fixed by the 6.0.3-1
upload, let's see.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#992743: RFP: furo -- clean customisable Sphinx documentation theme

[Andrey Rahmatullin]

On Thu, Oct 28, 2021 at 09:57:37PM +0500, Andrey Rahmatullin wrote:

> My initial packaging is at
> https://salsa.debian.org/python-team/packages/python-furo
I've just found I've not pushed the debian/master branch (it probably
needs to be configured in debian/gbp.conf). This is now fixed. 



-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#1018759: ITP: sd - intuitive find and replace CLI

[Andrey Rahmatullin]

On Tue, Aug 30, 2022 at 06:44:36PM +0800, Blair Noctis wrote:
> An RFP is at #1016929 [1].
> 
> 1: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1016929
> 
You should have retitled and owned the RFP instead of creating a separate
ITP. You should do that now, as described on
https://www.debian.org/devel/wnpp/#l3 , and merge this bug into that one.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#1017855: Support Sybil 3.0

[Andrey Rahmatullin]

Source: flufl.lock
Version: 5.0.1-3
Severity: normal

The new version of python3-sybil, currently available in experimental, breaks
building of the sid version of flufl.lock. The new upstream version of
flufl.lock support it. As I intend to update python3-sybil in sid before the
bookworm freeze, please upgrade flufl.lock to the latest upstream version or
patch the sid version to support new sybil.


-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 
'unstable'), (500, 'testing'), (101, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.19.0-trunk-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.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

Bug#970146: still blocked

[Andrey Rahmatullin]

On Fri, Jul 15, 2022 at 10:44:42AM -0400, Matt Barry wrote:
> block -1 by 1014974
> thanks

On Wed, Jun 29, 2022 at 01:15:23PM -0400, Matt Barry wrote:
> block -1 by 1014067
> thanks

On Thu, Jun 16, 2022 at 12:16:12PM -0400, Matt Barry wrote:
> retitle -1 ITA: python-public -- @public decorator for adding names to __all__
> thanks

Hi Matt, in case you haven't see that, your emails didn't have any effect
because you need to either send the commands to control@ or send them in
Control: pseudo-headers (and if you don't have anything human-readable to
add, you should just use bts(1)).

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#1017854: Support Sybil 3.0

[Andrey Rahmatullin]

Source: python-public
Version: 2.3-2
Severity: normal

The new version of python3-sybil, currently available in experimental, breaks
building of the sid version of python-public. The new upstream version of
python-public support it. As I intend to update python3-sybil in sid before the
bookworm freeze, please upgrade python-public to the latest upstream version or
patch the sid version to support new sybil.


-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 
'unstable'), (500, 'testing'), (101, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.19.0-trunk-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.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

Bug#1013132: ITP: BabaSSL -- BabaSSL is a base library for modern cryptography and communication security protocols.

[Andrey Rahmatullin]

On Wed, Jun 29, 2022 at 01:43:25PM +, Lance Lin wrote:
> Hello everyone,
> 
> Thank you for your input and guidance. I've only been in Debian for a year so 
> 
> I still have many things to learn. I assumed there would be issues with 
> library
> name conflicts and wanted to get the group's opinion.
> 
> >> Or if the goal is rather to experiment and expose BabaSSL to the many archs
> >> we have in Debian, then keep it in unstable only by filing a bug to block
> >> it from testing.
> 
> > Or better: experimental, to avoid packages starting to (build-)depend on it.
> 
> It sounds like it would be suitable for the community if I continue the 
> packaging 
> work but restrict the package to experimental? 
As a drop-in OpenSSL replacement or with different file names and SONAMEs?


-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#1013132: ITP: BabaSSL -- BabaSSL is a base library for modern cryptography and communication security protocols.

[Andrey Rahmatullin]

On Wed, Jun 22, 2022 at 02:21:43PM +, Lance Lin wrote:
> > AFAIK this library is forked from OpenSSL with some extensive
> > modifications to support new crypto technologies, do you think we need
> > to involve the Security Team to review whether this package can be
> > supported during the next stable release cycle?
> > Also this project has a planned rename, and I'm a bit concerned this
> > could cause some maintenance burden if the rename is not well
> > coordinated at the time we accept it into Debian.
> 
> I think any reviews and oversight are a good thing. In making this ITP,
> I figured it would cause discussion as it's a "drop-in" replacement for
> OpenSSL and the libraries have the same name. I wasn't sure if this was
> directly permitted so the ITP is a good place to have the discussion.
Have you already designed how will this be packaged to work as a drop-in
replacement for libssl3? I see quite a lot of problems with that,
both Policy ones and technical ones.


-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#1010074: RFS: show-in-file-manager/1.1.4-1 [RFP] -- Open the system file manager and optionally select files in it

[Andrey Rahmatullin]

On Sun, Apr 24, 2022 at 10:32:05PM +0200, Tino Mettler wrote:
> > You have actually configured it in the package, so it would be better if
> > it actually works. :) Try just running `autopkgtest` in the source
> > directory..
> > 
> > https://wiki.debian.org/ContinuousIntegration/autopkgtest
> 
> Hi,
> 
> I was not aware that the package defines any test specific bits. Can you 
> point me to the relevant part? I had the impression that a package needs to 
> define the tests in debian/tests/, and the showinfilemanager package does not 
> have a debian/tests directory.
All Python module packages have a minimal automatic autopkgtest that tries
to import the module. Make sure the module name used by the test is
correct, and if it isn't you should set the correct one in
debian/tests/autopkgtest-pkg-python.conf (see e.g. python-xlib and the
relevant documentation in autodep8(1)).


-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#1009658: RFS: ncdu/1.16-0.1 [NMU] -- ncurses disk usage viewer

[Andrey Rahmatullin]

On Thu, Apr 21, 2022 at 02:49:42PM +0200, Santiago Ruano Rincón wrote:
> >  ncdu (1.16-0.1) unstable; urgency=medium
> 
> Is it really urgency=medium? low wouldn't fit?
medium is the default urgency since Nov 2013.



-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#1009313: RFS: nginx/1.18.0-10 -- small, powerful, scalable web/proxy server

[Andrey Rahmatullin]

On Tue, Apr 12, 2022 at 04:02:14PM +0800, Miao Wang wrote:
> >> I intended to leave it UNRELEASED so it can serve as a request for 
> >> comment. However, every time I upload an UNRELEASED package, it gets 
> >> deleted automatically. As a result, I have to set the codename to unstable 
> >> for successful uploading.
> > 
> > You misunderstood. You left a -9 revision UNRELELEASED and skipped it while 
> > publishing a -10 revision.
> 
> Yes, it is intended, because currently the version number of nginx is -9 in 
> https://salsa.debian.org/nginx-team/nginx/-/blob/master/debian/changelog 
No, the current version of nginx in the archive is -8.
Normally you are supposed to update an UNRELEASED entry in a VCS with your
changes and release it.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#994388: dpkg currently warning about merged-usr systems

[Andrey Rahmatullin]

On Fri, Apr 08, 2022 at 09:36:21AM +0200, Wouter Verhelst wrote:
> FWIW, I think the TC should punt this bug to a GR.
> 
> The dpkg maintainer has chosen not to engage with the TC in #994388, and
> now seems to be actively subverting a validly-made TC decision.
> 
> I do believe it reasonable to assume the dpkg maintainer has a point if
> he believes that the currently-chosen way of moving forward is harmful.
> However, the right way for him to make that point would have been to
> engage with the TC, the body constitutionally placed to resolve
> conflicts of this manner, not ignoring them and then doing whatever he
> wants when the decision inevitably doesn't go his way.
> 
> I encourage the dpkg maintainer (Cc'd) to engage with the TC in this
> matter. It is not yet too late; the TC can always roll back decisions it
> made earlier if it believes, in light of new arguments, those decisions
> to be wrong. However, if this does not happen, then that does not
> inspire me with confidence that whatever the TC decides after weighing
> all the arguments available to them, the dpkg maintainer will follow
> that ruling. Given that, in case the dpkg maintainer chooses to remain
> silent again, I believe the only way forward is for the TC to recommend
> a GR under §4.2.1 of the consitution.
This effectively means "TC cannot enforce its own decisions and everybody
can ignore them". Also, who would enforce the GR results and how?
Note that §2.1.1, at least in my opinion, forbids working against a TC
decision, but doesn't say who would enforce that and how.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#1008751: pytest-mpi: autopkgtest regression: versioned test depends only in experimental

[Andrey Rahmatullin]

On Fri, Apr 01, 2022 at 06:04:38PM +0200, Drew Parsons wrote:
> From
> /var/lib/apt/lists/deb.debian.org_debian_dists_unstable_main_source_Sources:
> 
> flufl.lock
Doesn't support Sybil 3.x in sid. The latest version, 7.0, supports it.
It's most likely easy to patch the sid version.

> pytest-mpi
-

> python-parsel
The fix is committed upstream but there was no release since then. It
should be easy to backport the fix.

> python-public
Doesn't support Sybil 3.x in sid. The latest version, 3.0.1, supports it.
It's most likely easy to patch the sid version.

> python-scrapy
Fixed upstream but the upload is postponed until the next bugfix release.
It should be easy to backport the fix.

> python-testfixtures
Should work.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#1008751: pytest-mpi: autopkgtest regression: versioned test depends only in experimental

[Andrey Rahmatullin]

On Fri, Apr 01, 2022 at 05:42:36PM +0200, Drew Parsons wrote:
> Source: pytest-mpi
> Followup-For: Bug #1008751
> X-Debbugs-Cc: Andrey Rahmatullin 
> 
> Hi Andrey,
> 
> I had pytest-mpi 0.6 quietly waiting in experimental for sybil 3 to be
> uploaded.
> 
> I saw that pytest-mpi finally got built (sybil 3 got uploaded), so
> I got enthusiastic and immediately uploaded pytest-mpi to unstable.
> 
> But I didn't think to check first what exactly had enabled pytest-mpi
> 0.6 to build in experimental. I assumed it was updates in unstable,
> but in fact it was python-sybil 3.0.1 from experimental.
> 
> At this point python3-sybil has no other reverse dependencies.
It has 6 reverse build-dependencies, most of which don't support
3.x, at least in sid but maybe at all. They need to be updated or patched
first.

> Therefore in order to work around my premature upload of pytest-mpi
> 0.6, could we now upload python-sybil 3.0.1 to unstable? It should be
> safe to do so since other packages are not using sybil yet.
No, sorry, due to the above.
Can you make pytest-mpi support both APIs? It's usually a simple
try+except ImportError.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#1006559: python-scrapy: FTBFS with OpenSSL 3.0

[Andrey Rahmatullin]

Control: retitle -1 FTBFS with New Twisted
Control: forwarded -1 https://github.com/scrapy/scrapy/issues/5400
Control: tags -1 + upstream fixed-upstream

On Sun, Feb 27, 2022 at 09:19:23PM +0100, Sebastian Andrzej Siewior wrote:
> | from twisted.web.test.test_webclient import PayloadResource
> | E   ImportError: cannot import name 'PayloadResource' from 
> 'twisted.web.test.test_webclient' 
> (/usr/lib/python3/dist-packages/twisted/web/tes t/test_webclient.py)
> | _ ERROR collecting tests/test_command_parse.py 
> _

> I'm not sure if this is comming from a fact that a dependency is not
> compiled against openssl 3.0 and python-scrapy is okay otherwise.
It's not related to OpenSSL.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#1006912: is it time to have account deletion in policy?

[Andrey Rahmatullin]

Previous, still open, bug from 2004: 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=228692

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#1000550: RM: elpy -- RoQA; FTBFS; unmaintained upstream

[Andrey Rahmatullin]

On Sat, Feb 26, 2022 at 09:12:10AM -0700, Nicholas D Steeves wrote:
> With that date fast approaching, I decided it was time to test another
> snapshot.  elpy_1.35.0+48.g4248dcc-1 (unreleased in git) is much
> improved. 
Great!

> The community is slow moving, but is making progress.  I won't be able
> to properly investigate the single failing test (down from hundreds
> IIRC) relevant to bookworm before late March.  Given the progress
> upstream has made, I believe this bug may be closed, because the current
> state of Elpy (on Salsa) is now a single failing test, where it was
> hundreds with stalled upstream development before.  If kept open, please
> feel free to ping me in April if progress on the remaining issue appears
> to have stalled.
I have no personal stakes in this except for QA considerations for the
Python Team so I'll let Scott decide.
Thank you for your contributions.


-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#1005814: ITP: debfetch -- Prints short info about Debian.

[Andrey Rahmatullin]

On Tue, Feb 15, 2022 at 12:38:17PM -0300, Ramon Mulin Lopes wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Ramon Mulin Lopes 
> X-Debbugs-Cc: debian-de...@lists.debian.org, mu...@disroot.org
> 
> * Package name: debfetch
>   Version : 1.0
>   Upstream Author : Blau Araujo 
> * URL : https://git.blauaraujo.com/blau_araujo/debfetch
> * License : GPL 3.0+
>   Programming Lang: Bash
>   Description : Prints short info about Debian.
> 
> Prints short info about Debian on terminal. Lists branch of Debian, kernel 
> version, uptime, local host, packages free and non-free installed and date of 
> last update with a red Debian logo.
> 
> The software can be an excellent minimalist alternative built in bash for 
> others with the same goal. I need a sponsor to do the software packaging as 
> it will be my first package.
I don't think we need a package for a low-effort 50-line bash script that
duplicates at least two already packaged tools.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#1001489: twodict: (autopkgtest) needs update for python3.10: 'collections' has no attribute 'KeysView'

[Andrey Rahmatullin]

I was looking at this bug report and while the patch is provided (and is
trivial), the package had its only maintainer upload in 2018, the last
upstream release was in 2016 (though one can say the software is perfect,
as it's just 270 lines of code), and it has popcon 9. So maybe it's better
to not spend effort on it.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#1004254: ITA: mpdscribble -- Last.fm reporting client for mpd

[Andrey Rahmatullin]

On Sun, Feb 06, 2022 at 08:22:15AM +0100, Geoffroy Youri Berret wrote:
> On Sun, 23 Jan 2022 21:28:34 +0500 Andrey Rahmatullin 
> wrote:
> > I request an adopter for the mpdscribble package.
> 
> I've imported v0.23 release and made some changes (mainly switch to meson).
> Keeping the package in MPD-team.
> 
> https://salsa.debian.org/kaliko/mpdscribble
Feel free to adopt it and thank you for your contributions!


-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#1004746: lintian: provide a check for Python package version numbers validity

[Andrey Rahmatullin]

On Tue, Feb 01, 2022 at 02:45:21PM +, Julian Gilbey wrote:
> I just hit two packages which gave me the following warning when
> pkg_resources tried to load them:
> 
> /usr/lib/python3/dist-packages/pkg_resources/__init__.py:116: 
> PkgResourcesDeprecationWarning: 1.12.1-git20200711.33e2d80-dfsg1-0.6 is an 
> invalid version and will not be supported in a future release
>   warnings.warn(
This looks strange to me. I wouldn't expect the package version
(especially with the Debian part) to be there.
I see flatbuffers runs `VERSION=$(DEB_VERSION) python$$pv setup.py build`,
I don't know why, or whether this is a good idea.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#1004254: RFA: mpdscribble -- Last.fm reporting client for mpd

[Andrey Rahmatullin]

Package: wnpp
Severity: normal
Control: affects -1 src:mpdscribble

I request an adopter for the mpdscribble package.

The package description is:
 Music Player Daemon client which collects information about played tracks and
 submits them to the Last.fm social music network (formerly known as
 Audioscrobbler). If submission servers are not reachable, submissions are
 enqueued and stored on disk cache.
 .
 The client can be also configured to use other scrobbling services like
 Libre.fm.
 .
 This package contains daemon which can be optionally installed system wide.

I'm currently not using mpd so I'm not going to use or maintain this package.
It should be in a good shape for now.

Bug#1001371: pytest-twisted: (autopkgtest) needs update for python3.10: E {'warnings': 2} != {'warnings': 1}

[Andrey Rahmatullin]

The upstream report at
https://github.com/pytest-dev/pytest-twisted/issues/146 was closed as the
additional warning is produced by Twisted. The Twisted fix isn't merged yet.
TBH as I don't need this package anymore (python3-scrapy doesn't use it
anymore) I'm considering orphaning it.


-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#1001759: RFS: qt6/6.2.2+ds-1 -- Qt for Android (x86_64)

[Andrey Rahmatullin]

Having a source package named "qt6" build Android-specific packages sounds
wrong to me. Is this intended to contain the normal Qt source code and so
be a duplicate of normal Qt packages?
This question would be asked in the ITP bug for this package but it
doesn't seem to have one...

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#1001009: Downloads external files on install

[Andrey Rahmatullin]

On Sun, Dec 05, 2021 at 09:56:02AM -0500, Tong Sun wrote:
> Thanks Andrey,
> 
> Two questions,
> 
> By "moved to contrib", did you meant to change
> 
> Section: net
> 
> to
> 
> Section: contrib
> 
> in d/control?
Please read
https://www.debian.org/doc/debian-policy/ch-archive.html#archive-areas and
https://www.debian.org/doc/debian-policy/ch-archive.html#s-subsections

> Now, let's define what "package cannot function" actually means. If
> functions normally without this or similar unpackaged file, but the
> program is completely data driven, i.e., no ads sites from the list
> are blocked unless the list is there.
> 
> So, strictly speaking, the package indeed cannot function without this
> or similar unpackaged file, right? And the solution is just above,
> right?
I don't know the current project consensus on this, if it exists.
If the software can only work with certain non-free files it should go
into contrib, if OTOH it can work with some user-provided files, or with
free files if those exist, it can stay in main. But downloading external
files in postinst is certainly not fit for main.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#1001009: Downloads external files on install

[Andrey Rahmatullin]

Package: dbab
Version: 1.3.2-1
Severity: serious

The package runs `dbab-get-list` in postinst, which downloads
http://pgl.yoyo.org/adservers/serverlist.php?hostformat=dnsmasq=0=plaintext

If the package cannot function without this or similar unpackaged file, it
should be moved to contrib. If it can, the downloading should be done by the
user/administrator.


-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 
'unstable'), (500, 'testing'), (101, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.15.0-1-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.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 dbab depends on:
ii  bind9-dnsutils [dnsutils]  1:9.17.20-3
ii  curl   7.79.1-2
pn  dnsmasq
ii  perl   5.32.1-6

dbab recommends no packages.

dbab suggests no packages.

Bug#1000824: The library package ships common files

[Andrey Rahmatullin]

Package: libxapp1
Version: 2.2.4-1
Severity: serious

Policy 8.2 says "If your package contains files whose names do not change with
each change in the library shared object version, you must not put them in the
shared library package. Otherwise, several versions of the shared library
cannot be installed at the same time without filename clashes, making upgrades
and transitions unnecessarily difficult."

The package ships the following files that violate this:

/etc/xdg/autostart/xapp-sn-watcher.desktop
/usr/lib/x86_64-linux-gnu/gtk-3.0/modules/libxapp-gtk3-module.so
/usr/lib/x86_64-linux-gnu/xapps/sn-watcher/xapp-sn-watcher


-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 
'unstable'), (500, 'testing'), (101, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.15.0-1-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.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 libxapp1 depends on:
ii  libc62.32-4
ii  libcairo-gobject21.16.0-5
ii  libcairo21.16.0-5
ii  libdbusmenu-gtk3-4   18.10.20180917~bzr492+repack1-2+b1
ii  libgdk-pixbuf-2.0-0  2.42.6+dfsg-2
ii  libglib2.0-0 2.70.1-1
pn  libgnomekbd8 
ii  libgtk-3-0   3.24.30-3
ii  libpango-1.0-0   1.48.10+ds1-1
ii  libx11-6 2:1.7.2-2+b1
pn  xapps-common 

libxapp1 recommends no packages.

libxapp1 suggests no packages.

Bug#997505: [Help] diskcache: FTBFS now even earlier due to Python3.10

[Andrey Rahmatullin]

On Mon, Nov 29, 2021 at 05:58:47PM +0100, Andreas Tille wrote:
> ERROR:   py310: could not install deps [django>=2.2.*, pytest, pytest-cov, 
> pytest-django, pytest-xdist]; v = 
> InvocationError("/build/diskcache-5.2.1/.tox/py310/bin/python -m pip install 
> 'django>=2.2.*' pytest pytest-cov pytest-django pytest-xdist", 1)
> E: pybuild pybuild:354: test: plugin distutils failed with: exit code=1: cd 
> /build/diskcache-5.2.1/.pybuild/cpython3_3.10_diskcache/build; tox -c 
> /build/diskcache-5.2.1/tox.ini --sitepa
The actual error:

ERROR: Could not find a version that satisfies the requirement 
typing-extensions>=3.6.4 (from importlib-metadata)
ERROR: No matching distribution found for typing-extensions>=3.6.4

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#1000554: RFS: libfm-qt/0.16.0-3.1 [NMU] [RC] -- Language package for libfm-qt

[Andrey Rahmatullin]

On Sun, Nov 28, 2021 at 03:23:34PM -0500, S. 7 wrote:
> I have decided to package  the newest version of LXQt (including libfm-qt),
> as such, this bug report no longer has relevance.
In that case you should close it.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#1000550: RM: elpy -- RoQA; FTBFS; unmaintained upstream

[Andrey Rahmatullin]

On Wed, Nov 24, 2021 at 04:18:23PM -0500, Nicholas D Steeves wrote:
> > Package: ftp.debian.org
> > Severity: normal
> > X-Debbugs-Cc: nstee...@gmail.com
> >
> > This package wasn't updated for the Python 3.9 transition and removed from
> > testing on 2021-03-07. The FTBFS with 3.9 bug isn't fixed upstream and
> > there are upstream maintenance problems documented at
> > https://github.com/jorgenschaefer/elpy/issues/1884
> >
> 
> Thank you for reminding me about this upstream thread.  Yes, it's
> definitely time that I post another follow-up message there.
> 
> Could we please defer this removal until at least 2022-03-07 as a
> reasonable compromise?  I think it's uncharitable and ablist to put more
> pressure than that on a project whose maintainer is suffering from hand
> injury/tendonitis...these things take a long time to resolve--years, not
> months--and if we're a project that truly believes in diversity,
> empathy, and equal opportunity, then we must accommodate people who are
> struggling.
Hi Nicholas. This is now up to ftp-masters but I'll state my opinion on
this.
Out of 8 or so RM requests for Python FTBFS stuff not in testing that I
filed yesterday this one was the hardest, but I decided to send it both
because a maintainer can object to it and because removing a package even
from sid is not the end of life for the package.
As I see this, if a package doesn't work it should be removed (I don't
know whether this package works with 3.9 and especially 3.10 or only the
tests fail), if a package works but FTBFS it should definitely stay out of
testing and may be removed from unstable if it hinders some progress like
some transitions (I think this isn't the case here). There may be also
other cases when a package should be removed even if it works, but it
always can be reuploaded later when the problems are fixed. This shouldn't
be viewed as a threat to the upstream, it's not "find a maintainer or we
will remove the package", it's "the package is RC-buggy by our standards
and also FTBFS, and so far nobody fixed that and if the upstream has no
maintainer then it's unlikely it will be fixed upstream soon".
So on one hand I'm fine with keeping this package in sid if it provides
some value to its users and will keep doing that when Python 3.10 is the
default in sid, though the FTP/Release/Security teams may have another
view on this as it FTBFS, and on the other hand I don't see a huge problem
with removing it, especially if it doesn't work, as it can always be
reinstated.

> I'm also not sure what would be a sensitive way to broach a deadline
> upstream.
As mentioned above, I don't think this is necessary. What is necessary is
fixing the RC bugs which can be done by the community.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#1000550: RM: elpy -- RoQA; FTBFS; unmaintained upstream

[Andrey Rahmatullin]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: nstee...@gmail.com

This package wasn't updated for the Python 3.9 transition and removed from
testing on 2021-03-07. The FTBFS with 3.9 bug isn't fixed upstream and
there are upstream maintenance problems documented at
https://github.com/jorgenschaefer/elpy/issues/1884


$ dak rm -Rn elpy
Will remove the following packages from unstable:

 elpa-elpy |   1.34.0-2 | all
  elpy |   1.34.0-2 | source

Maintainer: Debian Emacsen team 

--- Reason ---

--

Checking reverse dependencies...
No dependency problem found.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#1000548: RM: meliae -- RoQA; FTBFS; uninstallable; dead upstream?

[Andrey Rahmatullin]

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

This package wasn't updated for the Python 3.9 transition. It was removed from
testing even earlier than that, on 2019-09-03. Its FTBFS with 3.9 bug is
still not fixed upstream.

$ dak rm -Rn meliae
Will remove the following packages from unstable:

meliae | 0.5.1+bzr231-3 | source
python3-meliae | 0.5.1+bzr231-3 | amd64, arm64, armel, armhf, i386, mips64el, 
mipsel, ppc64el, s390x
python3-meliae-dbg | 0.5.1+bzr231-3 | amd64, arm64, armel, armhf, i386, 
mips64el, mipsel, ppc64el, s390x

Maintainer: Jelmer Vernooij 

--- Reason ---

--

Checking reverse dependencies...
No dependency problem found.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#1000547: RM: ROM; NPOASR; FTBFS; doesn't work

[Andrey Rahmatullin]

Package: ftp.debian.org
X-Debbugs-Cc: debian-pyt...@lists.debian.org, rodrilopez@gmail.com
Severity: normal

This package wasn't updated for the Python 3.9 transition and removed from
testing on 2020-11-27. Its FTBFS actually suggests it doesn't work with modern
celery, this was fixed upstream by
https://github.com/clokep/celery-batches/pull/21

$ dak rm -Rn celery-batches
Will remove the following packages from unstable:

celery-batches |  0.2-2 | source
python3-celery-batches |  0.2-2 | amd64, arm64, armel, armhf, i386, 
mips64el, mipsel, ppc64el, s390x

Maintainer: Debian Python Modules Team 


--- Reason ---

--

Checking reverse dependencies...
No dependency problem found.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#1000546: RM: logging-tree -- RoQA; FTBFS; unmaintained

[Andrey Rahmatullin]

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

This package wasn't updated for the Python 3.9 transition and removed from
testing on 2020-11-27. Its last maintainer upload was in 2019. 
There is a patch for the 3.9 FTBFS in the BTS and it's also fixed upstream.

$ dak rm -Rn logging-tree
Will remove the following packages from unstable:

logging-tree |  1.8.1-0.1 | source
python3-logging-tree |  1.8.1-0.1 | all

Maintainer: Federico Ceratto 

--- Reason ---

--

Checking reverse dependencies...
No dependency problem found.


-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#1000545: RM: doublex -- ROM; FTBFS; dead upstream

[Andrey Rahmatullin]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: debian-pyt...@lists.debian.org, david.vi...@gmail.com

This package wasn't updated for the Python 3.9 transition and removed from
testing on 2020-11-27. The test failures aren't fixed upstream, and
https://bitbucket.org/DavidVilla/python-doublex/issues/3/#comment-60228312
suggests the upstream is not active.

$ dak rm -Rn doublex
Will remove the following packages from unstable:

   doublex |1.9.2-1 | source
python3-doublex |1.9.2-1 | all

Maintainer: David Villa Alises 

--- Reason ---

--

Checking reverse dependencies...
No dependency problem found.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#1000544: RM: lasagne -- RoQA; FTBFS; orphaned

[Andrey Rahmatullin]

Package: ftp.debian.org
Severity: normal

This package wasn't updated for the Python 3.9 transition and removed from
testing on 2020-08-13. It was orphaned on 2020-11-18 with "Package has
bugs that cannot be easily solved and upstream is unresponsive."



$ dak rm -Rn lasagne
Will remove the following packages from unstable:

   lasagne | 0.1+git20200419.5d3c63c+ds-1 | source
lasagne-doc | 0.1+git20200419.5d3c63c+ds-1 | all
python3-lasagne | 0.1+git20200419.5d3c63c+ds-1 | all

Maintainer: Debian Science Maintainers 


--- Reason ---

--

Checking reverse dependencies...
No dependency problem found.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#1000543: RM: python-enable -- ROM; FTBFS; not installable

[Andrey Rahmatullin]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: debian-pyt...@lists.debian.org, va...@debian.org

This package wasn't updated for the Python 3.9 transition. It was removed
from testing even earlier than that, on 2019-10-19. It's not installable
as it requires Python 3.7 or 3.8.
The FTBFS bug is fixed upstream at
https://github.com/enthought/enable/issues/360 (according to the bug
metadata).

$ dak rm -Rn python-enable
Will remove the following packages from unstable:

python-enable |4.8.1-1 | source
python3-enable |4.8.1-1 | amd64, arm64, armel, armhf, i386, mips64el, 
mipsel, ppc64el, s390x

Maintainer: Debian Python Modules Team 


--- Reason ---

--

Checking reverse dependencies...
No dependency problem found.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#1000542: RM: celery-haystack -- ROM; FTBFS; doesn't work; dead upstream

[Andrey Rahmatullin]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: debian-pyt...@lists.debian.org, fl...@debian.org

This package wasn't updated for the Python 3.9 transition and removed from
testing on 2020-12-11. Its FTBFS actually suggests it doesn't work with modern
celery, the upstream bug is https://github.com/django-haystack/celery-
haystack/issues/64. There are some PRs and a fork
(https://pypi.org/project/celery-haystack-ng/) linked there.

Bug#999361: mypy ftbfs with python3.10 as supported (test failures)

[Andrey Rahmatullin]

On Wed, Nov 10, 2021 at 03:20:52PM +0100, Matthias Klose wrote:
> mypy ftbfs with python3.10 as supported (test failures):
> https://launchpadlibrarian.net/567976006/buildlog_ubuntu-jammy-amd64.mypy_0.910-3_BUILDING.txt.gz
This just says "The typed_ast package is not installed." which sounds like
it just wasn't rebuilt for 3.10 yet? 1.4.2-1 was used while only
1.4.3-1+b1 is rebuilt for 3.10.
As far as I can see these problems don't happen anymore, though the
package still FTBFS (see
https://buildd.debian.org/status/package.php?p=mypy):

FAILED mypy/test/testcmdline.py::PythonCmdlineSuite::testSrcPEP420Packages
FAILED mypy/test/testsamples.py::SamplesSuite::test_stdlibsamples
FAILED mypyc/test/test_commandline.py::TestCommandLine::testErrorOutput
FAILED mypyc/test/test_run.py::TestRun::testAsync

> python3-typed-ast is EOL according to upstream, so mypy needs to stop using
> this.
https://github.com/python/mypy/issues/10201 looks like mypy/typed_ast/3.10
problems are being properly tracked and fixed, also 1.5.0 was released on
Nov 12; though this doesn't seem related to the current failures.



-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#999785: built-using-field-on-arch-all-package emitted for non-Go packages

[Andrey Rahmatullin]

Package: lintian
Version: 2.112.0
Severity: normal

When lib/Lintian/Check/Debian/Control.pm was split, the Build-Depends: golang-
go | golang-any check was removed from built-using-field-on-arch-all-package
and so now it's emitted for all arch:all packages with Built-Using.

If it was done intentionally, which the tag name and description would suggest,
then I don't think they are correct. The statement in the description makes no
sense outside of Go context, and the tag name as submitted in
https://bugs.debian.org/891072 was golang-built-using-on-arch-all but was
changed by Lamby when applying.


-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 
'unstable'), (500, 'testing'), (101, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.15.0-trunk-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.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 lintian depends on:
ii  binutils2.37-9
ii  bzip2   1.0.8-4
ii  diffstat1.64-1
ii  dpkg1.20.9
ii  dpkg-dev1.20.9
ii  file1:5.39-3
ii  gettext 0.21-4
ii  gpg 2.2.27-2
ii  intltool-debian 0.35.0+20060710.5
ii  libapt-pkg-perl 0.1.40
ii  libarchive-zip-perl 1.68-1
ii  libcapture-tiny-perl0.48-1
ii  libclass-xsaccessor-perl1.19-3+b7
ii  libclone-perl   0.45-1+b1
ii  libconfig-tiny-perl 2.27-1
ii  libconst-fast-perl  0.014-1.1
ii  libcpanel-json-xs-perl  4.27-1
ii  libdata-dpath-perl  0.58-1
ii  libdata-validate-domain-perl0.10-1.1
ii  libdata-validate-uri-perl   0.07-1
ii  libdevel-size-perl  0.83-1+b2
pn  libdigest-sha-perl  
ii  libdpkg-perl1.20.9
ii  libemail-address-xs-perl1.04-1+b3
ii  libfile-basedir-perl0.09-1
ii  libfile-find-rule-perl  0.34-1
ii  libfont-ttf-perl1.06-1.1
ii  libhtml-html5-entities-perl 0.004-1.1
ii  libio-interactive-perl  1.023-1
ii  libio-prompt-tiny-perl  0.003-1
ii  libipc-run3-perl0.048-2
ii  libjson-maybexs-perl1.004003-1
ii  liblist-compare-perl0.55-1
ii  liblist-someutils-perl  0.58-1
ii  liblist-utilsby-perl0.11-1
ii  libmoo-perl 2.005004-2
ii  libmoox-aliases-perl0.001006-1.1
ii  libnamespace-clean-perl 0.27-1
ii  libpath-tiny-perl   0.120-1
ii  libperlio-gzip-perl 0.19-1+b7
ii  libperlio-utf8-strict-perl  0.008-1+b1
ii  libproc-processtable-perl   0.634-1
ii  libsereal-decoder-perl  4.018+ds-1+b1
ii  libsereal-encoder-perl  4.018+ds-1+b1
ii  libsort-versions-perl   1.62-1
ii  libsyntax-keyword-try-perl  0.26-1
ii  libterm-readkey-perl2.38-1+b2
ii  libtext-glob-perl   0.11-2
ii  libtext-levenshteinxs-perl  0.03-4+b8
ii  libtext-markdown-discount-perl  0.13-1
ii  libtext-xslate-perl 3.5.9-1
ii  libtime-duration-perl   1.21-1
ii  libtime-moment-perl 0.44-1+b3
ii  libtimedate-perl2.3300-2
ii  libtry-tiny-perl0.30-1
ii  libtype-tiny-perl   1.012004-1
ii  libunicode-utf8-perl0.62-1+b2
ii  liburi-perl 5.10-1
ii  libxml-libxml-perl  2.0134+dfsg-2+b1
ii  libyaml-libyaml-perl0.83+ds-1
ii  lzip1.22-4
ii  lzop1.04-2
ii  man-db  2.9.4-2
ii  patchutils  0.4.2-1
ii  perl [libencode-perl]   5.32.1-6
ii  t1utils 1.41-4
ii  unzip   6.0-26
ii  xz-utils5.2.5-2

lintian recommends no packages.

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

-- no debconf information

Bug#992743: RFP: furo -- clean customisable Sphinx documentation theme

[Andrey Rahmatullin]

Control: noowner -1
Control: retitle -1 RFP: furo -- clean customisable Sphinx documentation theme


I've made a bunch of RFPs for NodeJS things required to build the CSS
files here. It doesn't look possible to get these deps into Debian in
reasonable time (some of them even use Dart).

Note that the PyPI tarball contains pre-built CSS files instead of their
sources. As far as I understand we can't use those until all of their
build tools are in main.

My initial packaging is at
https://salsa.debian.org/python-team/packages/python-furo

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#998024: RFP: node-sass -- The reference implementation of Sass, written in Dart

[Andrey Rahmatullin]

Package: wnpp
Severity: wishlist
Control: block 992743 by -1

* Package name: node-sass
  Version : 1.43.4
  Upstream Author : Natalie Weizenbaum 
* URL : https://github.com/sass/dart-sass
* License : MIT
  Programming Lang: Dart
  Description : The reference implementation of Sass, written in Dart

This is a build-dep of furo.

Bug#998023: RFP: node-gulp-uglify -- Minify files with UglifyJS

[Andrey Rahmatullin]

Package: wnpp
Severity: wishlist
Control: block 992743 by -1

* Package name: node-gulp-uglify
  Version : 3.0.2
  Upstream Author : Terin Stock 
* URL : https://github.com/terinjokes/gulp-uglify
* License : MIT
  Programming Lang: JavaScript
  Description : Minify files with UglifyJS

This is a build-dep of furo.

Bug#998022: RFP: node-postcss-easy-import -- PostCSS plugin to inline @import rules content with extra features

[Andrey Rahmatullin]

Package: wnpp
Severity: wishlist
Control: block 992743 by -1

* Package name: node-postcss-easy-import
  Version : 3.0.0
  Upstream Author : Bogdan Chadkin 
* URL : https://github.com/TrySound/postcss-easy-import
* License : MIT
  Programming Lang: JavaScript
  Description : PostCSS plugin to inline @import rules content with extra
features

This is a build-dep of furo.

Bug#998021: RFP: node-cssnano -- A modular minifier, built on top of the PostCSS ecosystem

[Andrey Rahmatullin]

Package: wnpp
Severity: wishlist
Control: block 992743 by -1

* Package name: node-cssnano
  Version : 5.0.8
  Upstream Author : Ben Briggs 
* URL : https://github.com/cssnano/cssnano
* License : MIT
  Programming Lang: JavaScript
  Description : A modular minifier, built on top of the PostCSS ecosystem

cssnano is a modern, modular compression tool written on top of the PostCSS
ecosystem, which allows us to use a lot of powerful features in order to
compact CSS appropriately.

Our preset system allow you to load cssnano in a different configuration
depending on your needs; the default preset performs safe transforms, whereas
the advanced preset performs more aggressive transforms that are safe only when
your site meets the requirements; but regardless of the preset you choose, we
handle more than whitespace transforms!

This is a build-dep of furo.

Bug#998020: RFP: node-gulp-postcss -- PostCSS gulp plugin to pipe CSS through several plugins, but parse CSS only once

[Andrey Rahmatullin]

Package: wnpp
Severity: wishlist
Control: block 992743 by -1

* Package name: node-gulp-postcss
  Version : 9.0.1
  Upstream Author : Andrey Kuzmin 
* URL : https://github.com/postcss/gulp-postcss
* License : MIT
  Programming Lang: JavaScript
  Description : PostCSS gulp plugin to pipe CSS through several plugins,
but parse CSS only once


This is a build-dep of furo.

Bug#992743: RFP: furo -- clean customisable Sphinx documentation theme

[Andrey Rahmatullin]

This is also needed for the new sybil release.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#995851: qcelemental: please package latest upstream release

[Andrey Rahmatullin]

Control: severity -1 serious
Control: tags -1 + ftbfs upstream fixed-upstream
Control: found -1 0.17.0+dfsg-3
Control: retitle -1 FTBFS: tests fail with new pydantic

Unfortunately the build-time tests fail too so it FTBFS.
Fixed by https://github.com/MolSSI/QCElemental/pull/266

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#995836: O: gkrellm-gkrellmpc -- GKrellM plugin for controlling MPD

[Andrey Rahmatullin]

Package: wnpp
Severity: normal
Control: affects -1 src:gkrellm-gkrellmpc

I intend to orphan the gkrellm-gkrellmpc package.

The package description is:
 This GKrellM plugin works as a client for Music Player Daemon (MPD). It shows
 the current song and allows one to control the playback and change the
 playlist.


It works and the packaging is in a good shape but it's dead upstream. I'm also
not planning to use it anymore.

Bug#994758: libsgutils2-2: how to prevent the share lib from changing version to impact the package?

[Andrey Rahmatullin]

Control: severity -1 critical
Control: retitle -1 Soname change without package name change
Control: found -1 1.45-1
Control: block 994521 by -1

On Mon, Sep 20, 2021 at 05:25:32PM +0200, Chris Hofstaedtler wrote:
> > The ledmon package was reported by
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=994521 to cause ledmon
> > service was unable to run due to the broken dependency of libsgutils2-2.
> > 
> > It seems like the softlink will keep changing since 1.45:
> 
> Upstream change:
> https://github.com/hreinecke/sg3_utils/commit/b0042ccf801d0008c0f9f090ea93b3871e8a542e
> ("add ${PACKAGE_VERSION} to '.so' name")
> 
> *Maybe* libsgutils2-2 should now also carry the version in its
> package *name* :-(
Yes, the package name must be changed with any soname change, there is no
maybe (Policy 8.1). There should also be a proper transition on each such
change.
Note that the problem exists since bullseye, #957088 was filed for ledmon
for the 1.45-1 upload and this bug report for libsgutils2-2 should have
been filed then.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#994487: Incorrect systemd detection

[Andrey Rahmatullin]

Package: solaar
Version: 1.0.6+dfsg-2
Severity: normal

Not sure why I got this prompt only now, as solaar.config is 7 years old, but
it's outdated:

systemd_running() {
test -e /sys/fs/cgroup/systemd
}

/sys/fs/cgroup/systemd no longer exists.

Bug#992892: Please package 0.10.2

[Andrey Rahmatullin]

Source: python-toml
Version: 0.10.1-1
Severity: wishlist

New python3-ipdb for some reason that I didn't check requires python3-toml >=
0.10.2 so I would be glad if you updated it.
Thank you.

Bug#992891: Please package 1.8.2

[Andrey Rahmatullin]

Source: pydantic
Version: 1.7.4-1
Severity: wishlist


New python3-itemadapter supports pydantic, but only 1.8+ (as it uses
allow_mutation) so I would be glad if it's updated to the latest version.
Thank you.

Bug#990875: unblock: kvirc/4:5.0.0+dfsg-5

[Andrey Rahmatullin]

Control: tags -1 - moreinfo

On Sat, Jul 10, 2021 at 01:40:15PM +0200, Graham Inggs wrote:
> Control: tags -1 + moreinfo confirmed
> 
> Hi Andrey
> 
> On Sat, 10 Jul 2021 at 10:42, Andrey Rahmatullin  wrote:
> > unblock kvirc/4:5.0.0+dfsg-5
> 
> I don't see 4:5.0.0+dfsg-5 in unstable yet, so I'm not sure if this
> was meant to be a pre-approval request.  
Indeed it was, thanks.

> Assuming it was, please go ahead and upload to unstable.  Either way,
> please remove the moreinfo tag once it has built.
Done: https://buildd.debian.org/status/package.php?p=kvirc

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#990875: unblock: kvirc/4:5.0.0+dfsg-5

[Andrey Rahmatullin]

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

Please unblock package kvirc

[ Reason ]
This fixes a crash when starting it on Wayland.

[ Impact ]
This allows using the app on Wayland.

[ Tests ]
I've checked the app on a KDE Wayland session on testing.

[ Risks ]
This shouldn't affect X11 users.

[ Checklist ]
  [x] all changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in testing


unblock kvirc/4:5.0.0+dfsg-5
diff -Nru kvirc-5.0.0+dfsg/debian/changelog kvirc-5.0.0+dfsg/debian/changelog
--- kvirc-5.0.0+dfsg/debian/changelog   2020-11-10 22:44:22.0 +0500
+++ kvirc-5.0.0+dfsg/debian/changelog   2021-07-10 12:26:08.0 +0500
@@ -1,3 +1,9 @@
+kvirc (4:5.0.0+dfsg-5) unstable; urgency=medium
+
+  * Fix a crash on Wayland (Closes: #935726).
+
+ -- Andrey Rahmatullin   Sat, 10 Jul 2021 12:26:08 +0500
+
 kvirc (4:5.0.0+dfsg-4) unstable; urgency=medium
 
   * Team upload.
diff -Nru kvirc-5.0.0+dfsg/debian/patches/series 
kvirc-5.0.0+dfsg/debian/patches/series
--- kvirc-5.0.0+dfsg/debian/patches/series  2020-11-10 22:44:22.0 
+0500
+++ kvirc-5.0.0+dfsg/debian/patches/series  2021-07-10 12:26:08.0 
+0500
@@ -5,3 +5,4 @@
 enable-optimisation-with-debug.patch
 fix-rfc-links.patch
 upstream_fix-build-with-Qt-5.15.patch
+upstream-wayland-fixes.patch
diff -Nru kvirc-5.0.0+dfsg/debian/patches/upstream-wayland-fixes.patch 
kvirc-5.0.0+dfsg/debian/patches/upstream-wayland-fixes.patch
--- kvirc-5.0.0+dfsg/debian/patches/upstream-wayland-fixes.patch
1970-01-01 05:00:00.0 +0500
+++ kvirc-5.0.0+dfsg/debian/patches/upstream-wayland-fixes.patch
2021-07-10 12:26:08.0 +0500
@@ -0,0 +1,52 @@
+Description: Fix a crash and set the window icon on Wayland.
+Origin: backport, 
https://github.com/kvirc/KVIrc/commit/c8a6812fc26d6c240d7b99b517835e7cb9607e68
+Bug: https://github.com/kvirc/KVIrc/issues/2479
+Bug-Debian: https://bugs.debian.org/935726
+Last-Update: 2021-07-10
+
+diff --git a/src/kvirc/kernel/KviIpcSentinel.cpp 
b/src/kvirc/kernel/KviIpcSentinel.cpp
+index bfa60e6..df5f0e3 100644
+--- a/src/kvirc/kernel/KviIpcSentinel.cpp
 b/src/kvirc/kernel/KviIpcSentinel.cpp
+@@ -172,6 +172,12 @@ bool kvi_sendIpcMessage(const char * message)
+   }
+ #elif defined(COMPILE_X11_SUPPORT) && defined(COMPILE_QX11INFO_SUPPORT)
+ 
++#if QT_VERSION >= QT_VERSION_CHECK(5, 2, 0)
++  if (!QX11Info::isPlatformX11()) {
++  return false;
++  }
++#endif
++
+   kvi_ipcLoadAtoms();
+ 
+   Window sentinel = kvi_x11_findIpcSentinel(kvi_ipc_get_xrootwin());
+@@ -196,6 +202,12 @@ KviIpcSentinel::KviIpcSentinel() : QWidget(nullptr)
+   setWindowFlags(Qt::FramelessWindowHint);
+   setWindowTitle("kvirc4_ipc_sentinel");
+ #elif defined(COMPILE_X11_SUPPORT) && defined(COMPILE_QX11INFO_SUPPORT)
++
++#if QT_VERSION >= QT_VERSION_CHECK(5, 2, 0)
++  if (!QX11Info::isPlatformX11()) {
++  return;
++  }
++#endif
+   kvi_ipcLoadAtoms();
+ 
+   XChangeProperty(kvi_ipc_get_xdisplay(), winId(), 
kvi_atom_ipc_sentinel_window, XA_STRING, 8,
+diff --git a/src/kvirc/ui/KviMainWindow.cpp b/src/kvirc/ui/KviMainWindow.cpp
+index a3c6c50..c1b9391 100644
+--- a/src/kvirc/ui/KviMainWindow.cpp
 b/src/kvirc/ui/KviMainWindow.cpp
+@@ -105,7 +105,10 @@ KviMainWindow::KviMainWindow(QWidget * pParent)
+   // We try to avois this as much as possible, since it forces the use of 
the low-res 16x16 icon
+   setWindowIcon(*(g_pIconManager->getSmallIcon(KviIconManager::KVIrc)));
+ #endif
+-
++#if QT_VERSION >= QT_VERSION_CHECK(5, 7, 0)
++  // set name of the app desktop file; used by wayland to load the window 
icon
++  QGuiApplication::setDesktopFileName("kvirc");
++#endif
+   setWindowTitle(KVI_DEFAULT_FRAME_CAPTION);
+ 
+   m_pActiveContext = nullptr;

Bug#924009: closed by Dimitrios Eftaxiopoulos (Bug not reproduced)

[Andrey Rahmatullin]

Control: reassign -1 src:freefem++
Control: severity -1 serious
Control: retitle -1 Baseline violation in i386 (-mmx -msse2) and amd64 (-mavx)
Control: found -1 3.47+dfsg1-1

On Sun, Mar 24, 2019 at 09:52:28PM +0100, Bernhard Übelacker wrote:
> Unfortunately I saw some bugs in the debian bug tracker
> that were told a "baseline violation", I never saw it somewhere
> explained what exactly the cpu feature baseline is.
It's indeed unfortunate that this info is hard to find and many
mainatiners don't know it. It's currently available at
https://wiki.debian.org/ArchitectureSpecificsMemo#Architecture_baselines
The baseline for amd64 is basic amd64, so only SSE2 and below.
The baseline for i386 is i686 without MMX.

While for amd64 the problem appeared in 3.61.1 (so since buster), for i386
it exists even in stretch.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#989253: qbittorrent refuses to start after qt5 upgrade

[Andrey Rahmatullin]

Control: tags -1 moreinfo unreproducible

I cannot reproduce this on a freshly installed package.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#988489: ddcutil: Kernel 5.10 changes require ddcutil 1.1

[Andrey Rahmatullin]

On Sat, May 15, 2021 at 10:36:23AM -0400, Sanford Rockowitz wrote:
> ddcutil 1.1.0 was uploaded to mentors on 4/22.  Per the sponsor (Andrey
> Rahmatulin) it was not moved to sid because of the freeze for Bullseye.
If the package doesn't work with the bullseye kernel it's a grave bug, not
important, and the package should be fixed (or removed).
Ti be eligible for bullseye the update should be a minimal patch added to
the bullseye version.
What do you think?


> On 5/14/21 1:10 AM, Joris wrote:
> > Package: ddcutil
> > Version: 0.9.9-2
> > Severity: important
> > Tags: upstream
> > X-Debbugs-Cc: jo...@v5.be
> > 
> > 
> > 
> > 
> > -- System Information:
> > Debian Release: bullseye/sid
> >APT prefers testing-security
> >APT policy: (500, 'testing-security'), (500, 'testing')
> > Architecture: amd64 (x86_64)
> > 
> > Kernel: Linux 5.10.0-6-amd64 (SMP w/8 CPU threads)
> > Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
> > Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
> > LANGUAGE=en_GB:en
> > Shell: /bin/sh linked to /usr/bin/dash
> > Init: systemd (via /run/systemd/system)
> > LSM: AppArmor: enabled
> > 
> > Versions of packages ddcutil depends on:
> > ii  i2c-tools 4.2-1+b1
> > ii  libc6 2.31-11
> > ii  libdrm2   2.4.104-1
> > ii  libglib2.0-0  2.66.8-1
> > ii  libudev1  247.3-5
> > ii  libx11-6  2:1.7.0-2
> > ii  libxrandr22:1.5.1-1
> > ii  pci.ids   0.0~2021.02.08-1
> > ii  usb.ids   2021.03.31-1
> > ii  usbutils  1:013-3
> > 
> > ddcutil recommends no packages.
> > 
> > ddcutil suggests no packages.
> > 
> > -- no debconf information
> > 
> > 
> > >From the release information on ddcutil 
> > >(http://www.ddcutil.com/release_notes/) it seems Linux kernel 5.10 made 
> > >changes. They are listed as "docking stations" but in my experience also 
> > >apply to directly connected HDMI and Thunderbolt displays.
> > Ddcutil 1.0.1 and 1.1.0 include workarounds for this kernel. On my system 
> > bringing back the same capabilities I had under kernel 5.8, whereas with 
> > ddcutil 0.9.9 on kernel 5.10 there was simply no device detected.
> > 
> > As 5.10 seems to be the default in the upcoming Debian release, it would be 
> > very nice to get ddcutil updated as well.
> > I had no issue building ddcutil from source.
> > 
> 
> 

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#986692: crash at startup

[Andrey Rahmatullin]

I can confirm this, and the backtrace looks similar:

#0  0x00080005 in ?? ()
#1  0x77a1d879 in _Unwind_ForcedUnwind_Phase2 (exc=0x55614e90, 
context=0x7fffdd70, frames_p=0x7fffdc78) at 
../../../src/libgcc/unwind.inc:170
#2  0x77a1e14d in _Unwind_Resume (exc=exc@entry=0x55614e90) at 
../../../src/libgcc/unwind.inc:243
#3  0x55560c65 in __gnu_cxx::new_allocator::~new_allocator 
(this=, __in_chrg=) at 
/usr/include/c++/9/ext/new_allocator.h:89
#4  std::allocator::~allocator (this=0x7fffdeb0, __in_chrg=) at /usr/include/c++/9/bits/allocator.h:153
#5  std::__cxx11::basic_string, 
std::allocator >::_Alloc_hider::~_Alloc_hider (this=, 
__in_chrg=) at /usr/include/c++/9/bits/basic_string.h:150
#6  std::__cxx11::basic_string, 
std::allocator >::~basic_string (this=, 
__in_chrg=) at /usr/include/c++/9/bits/basic_string.h:658
#7  Levels::addLevel (this=, 
file="/usr/share/numptyphysics/L99_Gravity_Test.nph", rank=99, index=-1) at 
Levels.cpp:117

valgrind says:

Invalid read of size 8
   at 0x4DFA810: ??? (in /usr/lib/x86_64-linux-gnu/libgcc_s.so.1)
   by 0x4DFB14C: _Unwind_Resume (in /usr/lib/x86_64-linux-gnu/libgcc_s.so.1)
   by 0x114C64: ~new_allocator (new_allocator.h:89)
   by 0x114C64: ~allocator (allocator.h:153)
   by 0x114C64: ~_Alloc_hider (basic_string.h:150)
   by 0x114C64: ~basic_string (basic_string.h:658)
   by 0x114C64: Levels::addLevel(std::__cxx11::basic_string, std::allocator > const&, int, int) [clone .cold] 
(Levels.cpp:117)
   by 0x11C9B3: Levels::addPath(char const*) (Levels.cpp:93)
   by 0x11C8CD: Levels::addPath(char const*) (Levels.cpp:104)
   by 0x12C7FE: runGame (App.cpp:184)
   by 0x12C7FE: run (App.cpp:110)
   by 0x12C7FE: npmain(int, char**) (App.cpp:372)
   by 0x1174FA: main (OsFreeDesktop.cpp:133)
 Address 0x68ec6b8 is 0 bytes after a block of size 24 alloc'd
   at 0x4838DEF: operator new(unsigned long) (in 
/usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
   by 0x12BD89: runGame (App.cpp:173)
   by 0x12BD89: run (App.cpp:110)
   by 0x12BD89: npmain(int, char**) (App.cpp:372)
   by 0x1174FA: main (OsFreeDesktop.cpp:133)


Some debugging suggests that the string being destroyed when it crashes is
the "My Levels" std::string created from the static const char
MISC_COLLECTION[] in Levels::addLevel() (no idea what is the problem with
this code).

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#985891: dicompyler doesn't start

[Andrey Rahmatullin]

Control: severity -1 grave

On Thu, Mar 25, 2021 at 08:41:08PM +0100, Andreas Tille wrote:
> > raise DistributionNotFound(req, requirers)
> > pkg_resources.DistributionNotFound: The 'matplotlib<2.2,>=1.3.0' 
> > distribution
> > was not found and is required by dicompyler
> 
> This is a bit misleading error output.  The problem is that the code
> might work with some former matplotlib versions / Python3 versions but
> it is using a private module of matplotlib[1] which is simply forbidden.
(not really misleading, it says the installed matplotlib version is not
suitable for it)

> I have reported this issue upstream (see above).
> 
> Since this makes dicompyler unusable I have bumped the bug severity to
> serious ... which will possibly mean that dicompyler will not be
> distributed with the next Debian release if upstream does not come
> up with some solution in the next 2-3 weeks.
See also https://github.com/bastula/dicompyler/issues/122 (it mentions
using skimage.measure.find_contours instead but you'll probably need to
write a patch yourself).

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#985883: python3-pep8: Does not install /usr/bin/pep8

[Andrey Rahmatullin]

On Thu, Mar 25, 2021 at 07:30:14PM +1000, Russell Stuart wrote:
> Justification: renders package unusable

> python3-pep8 does not install the pep8 executable under /bin or
> /usr/bin.
There is no pep8 executable anymore, and the transitional package that
shipped a symlink from it to pycodestyle was dropped in 1.7.1-9 in 2020.
See https://pep8.readthedocs.io/

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#985705: courier-authlib: upgrades broken due the move of the tools

[Andrey Rahmatullin]

Control: tags -1 + moreinfo


On Mon, Mar 22, 2021 at 09:10:29AM -0400, PICCORO McKAY Lenz wrote:
> Package: courier-authlib
> Version: 0.71.0-1
Why is this version set here?

> i just try the upgrade case from stretch to lasted 
You can upgrade stretch only to buster.
On the other hand, 0.71.0-1 is present only in old testing, not in any
stable.

> when i try to upgrade got this error:
> 
> dpkg: error al procesar el archivo
> /var/cache/apt/archives/courier-authdaemon_0.71.1-2_i386.deb
> (--unpack):
>  intentando sobreescribir `/usr/sbin/authenumerate', que está también
> en el paquete courier-authlib 0.71.0-1
> dpkg: considerando la desconfiguración de courier-authdaemon, ya que
> lo rompería la instalación de `courier-base' ...
I cannot reproduce this. You need to explain how to reproduce this.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#982381: AttributeError: lowlevel due to trio usage in s3ql/block_cache.py

[Andrey Rahmatullin]

On Thu, Feb 18, 2021 at 03:28:36PM +0100, Francesco P. Lovergine wrote:
> I'm pretty sure this release should depend on >= 0.15,
> even due to #981906. Unfortunately, it is not expressed in the package
From setup.py:

 # Need trio.lowlevel
 'trio >= 0.15',

So it's expressed upstream but ignored in the Debian package, because
dh_python3 ignores version reqs by default.


-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#983702: voltron: Update package with new upstream release

[Andrey Rahmatullin]

Control: retitle -1 Doesn't work with current werkzeug
COntrol: tags -1 + upstream fixed-upstream patch

On Sun, Feb 28, 2021 at 05:52:23PM +0100, Thomas Nyberg wrote:
> The reason seems to be that the debian testing packaged version of werkzeug is
> 1.0.1 while the packaged version of voltran does not support it. There is a
> commit in the upstream repo that solves this problem:
> 
> 
> https://github.com/snare/voltron/commit/ba413dcbc1914c511d03e1d95f3663a91daf349a
> 
> Unfortunately that commit is not included in an official release. I'm unsure 
> if
> that is required for it to be packaged with debian. Regardless, the older
> version does not work as packaged (though the required changes are admittedly
> quite minor).
Assuming this patch fixes the problem, the correct way will be to apply it
to the current version and upload it.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#982704: ofxstatement-plugins: FTBFS: TypeError: expected str, bytes or os.PathLike object, not NoneType

[Andrey Rahmatullin]

On Sat, Feb 13, 2021 at 06:06:54PM +0100, Lucas Nussbaum wrote:
> > cd ofxstatement-be-argenta && python3 setup.py test
> > running test
> > [...]
> >   File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 
> > 1379, in __init__
> > self.module_path = os.path.dirname(getattr(module, '__file__', ''))
> >   File "/usr/lib/python3.9/posixpath.py", line 152, in dirname
> > p = os.fspath(p)
> > TypeError: expected str, bytes or os.PathLike object, not NoneType
> > make[1]: *** [debian/rules:32: plugin_test_ofxstatement-be-argenta] Error 1
So Python tries to find tests here and fails. I tried to debug why it
failes here but in ofxstatement-airbankcz and the difference seems to be
caused by unittest.loader.TestLoader._find_test_path() finding
ofxstatement/__init__.py here but not in ofxstatement-airbankcz. I'll
leave this at this point to someone more familiar with test discovery,
namespaces and packages.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#982712: tiledarray: FTBFS: gemm_helper.h:168:30: error: expected initializer before ‘const’

[Andrey Rahmatullin]

Control: -1 fixed-upstream

Looks like this was caused by an update of libmadness-dev. Feel free to
reassign this RC bug there, as it broke API compatibility when updated
from 0.10.1~gite4aa500e-10.1 to 0.10.1+git20200818.eee5fd9f-1:
 now #defines "MADNESS_RESTRICT" instead of "restrict".
This seems to be fixed upstream at
https://github.com/ValeevGroup/tiledarray/commit/dbb665cb5e400aeebc39be12d015981078eff72b


-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#983685: python-passlib: Homepage is 404

[Andrey Rahmatullin]

On Sun, Feb 28, 2021 at 02:49:00PM +0200, Adrian Bunk wrote:
> Source: python-passlib
> Version: 1.7.2-2
> Severity: normal
> 
> https://bitbucket.org/ecollins/passlib/wiki/Home is 404
> 
> A replacement might be https://pypi.org/project/passlib/
The new repo is at https://foss.heptapod.net/python-libs/passlib and there
is a wiki page at
https://foss.heptapod.net/python-libs/passlib/-/wikis/home so that can be
used as a direct replacement.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#917851: Failed build for seqan2 on i386

[Andrey Rahmatullin]

On Fri, Feb 12, 2021 at 11:21:38AM +0100, Hilmar Preuße wrote:
> > > You can't adjust anything to get more than 4GB virtual memory on 32-bit
> > > architectures.
> > > You can try adjusting compilation/linking parameters to make the
> > > compiler/linker use less memory though (not sure if the suggestions are
> > > documented anywhere).
> > 
> > But other 32bit architectures like armel and armhf are passing[2].  So I
> > fail to see why exactly i386 is failing.  Is this possibly an effect of
> > bug #917851?
> > 
> Maybe the memory of the whole builder is exhausted. 

Then it would get an OOM, not a *virtual* memory error.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#981660: Can't install vcrun2019 because hashsums are outdated

[Andrey Rahmatullin]

Package: winetricks
Version: 0.0+20200412-1
Severity: important
Tags: upstream fixed-upstream

Fixed in
https://github.com/Winetricks/winetricks/commit/4f690a2a3e62c59629c4c9e332ba59034fb2d1f6




-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 
'unstable'), (500, 'testing'), (101, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-2-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.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 winetricks depends on:
ii  binutils 2.35.1-7
ii  curl 7.74.0-1
ii  wget 1.21-1+b1
ii  wine [wine]  5.0.3-3

Versions of packages winetricks recommends:
ii  cabextract  1.9-3
pn  fuseiso | archivemount  
ii  kde-cli-tools   4:5.20.5-2
ii  kdialog 4:20.12.0-1
ii  p7zip-full  16.02+dfsg-8
ii  policykit-1 0.105-29
ii  sudo1.9.5p2-2
ii  unzip   6.0-26
ii  x11-utils   7.7+5
ii  xdg-utils   1.1.3-4
ii  xz-utils5.2.5-1.0
ii  zenity  3.32.0-6

Versions of packages winetricks suggests:
ii  tor0.4.4.6-1
ii  unrar  1:6.0.3-1

-- debconf-show failed

Bug#980333: librsync-dev: Please also build static library

[Andrey Rahmatullin]

On Sun, Jan 17, 2021 at 03:45:45PM -0600, John Goerzen wrote:
> In #918075, binary delta support for dar is discussed.  dar can optionally
> support it with librsync.  However, from the dar source package, dar-static is
> also built.  The dar maintainer doesn't want to enable binary deltas for only
> the dynamically-linked package.
> 
> Could you build a .a to include in librsync-dev, so that dar can take 
> advantage
> of librsync features in both its dynamically-linked and statically-linked
> versions?
Do you want this in bullseye?

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#978471: waybar fails to launch

[Andrey Rahmatullin]

Control: reassign -1 libspdlog1/1:1.8.1+ds-2+b1
Control: affects -1 waybar
Control: severity -1 serious
Control: retitle -1 libspdlog1 breaks ABI on rebuilds with different libfmt

On Sun, Dec 27, 2020 at 09:26:09PM +0100, Michele Cane wrote:
> waybar: symbol lookup error: waybar: undefined symbol: 
> _ZN6spdlog7details7log_msgC1ENS_10source_locEN3fmt2v617basic_string_viewIcEENS_5level10level_enumES6_
This is because libspdlog1 was rebuilt with newer libfmt and this caused
symbol renames.

#977454 says "The code is actually working with the new version, only the
symbols file is wrong here. spdlog uses fmtlib internal API and exposes it
through the symbols files. This looks wrong to me, as every new fmtlib
will cause spdlog ftbfs due to the symbols file.". If it's about the same
problem then it looks like it failed to mention that symbol changes cause
much worse problems than just needing to update the symbols file.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#977308: dpkg-shlibdeps: error: cannot find library (Was: Bug#977308: shasta: hardcoded dependencies on boost 1.71)

[Andrey Rahmatullin]

On Fri, Dec 18, 2020 at 04:07:50PM +0100, Andreas Tille wrote:
> On Fri, Dec 18, 2020 at 07:37:12PM +0500, Andrey Rahmatullin wrote:
> > On Fri, Dec 18, 2020 at 03:32:01PM +0100, Andreas Tille wrote:
> > > I tried no override_dh_shlibdeps in shasta debian/rules, which has lead
> > > to:
> > > 
> > > dpkg-shlibdeps: error: cannot find library 
> > > /usr/lib/python3/dist-packages/shasta.cpython-39-x86_64-linux-gnu.so 
> > > needed by debian/shasta/usr/bin/shasta (ELF format: 'elf64-x86-64' abi:   
> > >'0201003e'; RPATH: '')
> > Why are you linking an executable to a Python binary module?
> 
> That's a good question.  Its actually not me who did this.  I think
> that's done here:
> 
>https://salsa.debian.org/med-team/shasta/-/blob/master/debian/rules#L27
Eww.
But dynamicLibrary/README.md says:
"""
This directory builds the Shasta dynamic library `shasta.so`.
This library is used in three ways:

* It is linked in by the shasta dynamic executable `shastaDynamic`.
* It can be imported by a python script via `import shasta` to provide Shasta 
Python bindings.
* It can be statically linked in by other C++ code outside Shasta that uses 
Shasta as a library.
"""
So this sharing seems to be by design. That's unfortunate (can't say I'm
surprised, though).

> but I admit I have no idea why Shayan did so.
Well, otherwise the binary wouldn't find the library.

> I wonder what might be the proper way to do this to share the library
> between Python modules and the executable.
The proper way is to separate the common code from the Python bindings and
link this correctly separated shared library into both the executable and
the binary module libraries.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#977308: dpkg-shlibdeps: error: cannot find library (Was: Bug#977308: shasta: hardcoded dependencies on boost 1.71)

[Andrey Rahmatullin]

On Fri, Dec 18, 2020 at 03:32:01PM +0100, Andreas Tille wrote:
> Hi,
> 
> I tried no override_dh_shlibdeps in shasta debian/rules, which has lead
> to:
> 
> dpkg-shlibdeps: error: cannot find library 
> /usr/lib/python3/dist-packages/shasta.cpython-39-x86_64-linux-gnu.so needed 
> by debian/shasta/usr/bin/shasta (ELF format: 'elf64-x86-64' abi:  
> '0201003e'; RPATH: '')
Why are you linking an executable to a Python binary module?


-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#959138: Error in build time tests (Was: numpy breaks nipy autopkgtest: No module named 'numpy.testing.decorators')

[Andrey Rahmatullin]

On Tue, Dec 08, 2020 at 09:44:51PM +0100, Andreas Tille wrote:
> > https://github.com/nipy/nipy/issues/461
> 
> As far as I can see that's included into 0.4.3~rc1.
If by "it" you mean requiring sympy older than the Debian one then yes.
But the package evidently doesn't enforce this requirement.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#959138: Error in build time tests (Was: numpy breaks nipy autopkgtest: No module named 'numpy.testing.decorators')

[Andrey Rahmatullin]

On Tue, Dec 08, 2020 at 07:02:22PM +0100, Andreas Tille wrote:
> TypeError: unsupported operand type(s) for *: 'GreaterThan' and 'Add'
Consider starting to use Google to find at least some info related to
questions you ask.

https://github.com/nipy/nipy/issues/461

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#976779: Python3.9 issue: '"yield from" can't be applied to "Condition"' (Was: Bug#976779: mypy FTBFS with only python 3.9)

[Andrey Rahmatullin]

On Tue, Dec 08, 2020 at 01:27:57PM +0100, Andreas Tille wrote:
> test-data/samples/crawl.py:750: error: "yield from" can't be applied to 
> "Condition"
> test-data/samples/crawl.py:772: error: "yield from" can't be applied to 
> "Semaphore"
> test-data/samples/crawl.py:778: error: "yield from" can't be applied to 
> "Condition"
https://github.com/python/mypy/pull/9375

Also https://github.com/python/mypy/issues/9761

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#975953: libtorrent-rasterbar: diff for NMU version 1.2.9-0.2

[Andrey Rahmatullin]

Control: tags 975953 + patch
Control: tags 975953 + pending


Dear maintainer,

I've prepared an NMU for libtorrent-rasterbar (versioned as 1.2.9-0.2) and
uploaded it to DELAYED/0.

Regards.


-- 
WBR, wRAR
diff -Nru libtorrent-rasterbar-1.2.9/debian/changelog libtorrent-rasterbar-1.2.9/debian/changelog
--- libtorrent-rasterbar-1.2.9/debian/changelog	2020-11-25 13:34:56.0 +0500
+++ libtorrent-rasterbar-1.2.9/debian/changelog	2020-12-05 16:49:55.0 +0500
@@ -1,3 +1,11 @@
+libtorrent-rasterbar (1.2.9-0.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix building Python bindings with -std=c++14 (Closes: #975953), idea from
+Holger Hoffstätte, https://bugs.gentoo.org/739654.
+
+ -- Andrey Rahmatullin   Sat, 05 Dec 2020 16:49:55 +0500
+
 libtorrent-rasterbar (1.2.9-0.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru libtorrent-rasterbar-1.2.9/debian/rules libtorrent-rasterbar-1.2.9/debian/rules
--- libtorrent-rasterbar-1.2.9/debian/rules	2020-11-25 13:30:22.0 +0500
+++ libtorrent-rasterbar-1.2.9/debian/rules	2020-12-05 16:36:55.0 +0500
@@ -33,6 +33,8 @@
 		$(CONFIGURE_ARGS)
 	mv build-py$*/bindings/python build/bindings/python$*
 	cp -r bindings/python/* build/bindings/python$*
+	sed s/-std=c++11//g < build/bindings/python$*/compile_cmd > build/bindings/python$*/compile_cmd.new && \
+		mv -f build/bindings/python$*/compile_cmd.new build/bindings/python$*/compile_cmd
 
 override_dh_auto_configure: override_dh_auto_configure-nopy $(ALLPY:%=override_dh_auto_configure-%)
 


signature.asc
Description: PGP signature

Bug#975953: Can't be imported, undefined symbol: _ZNK10libtorrent5entry4dictEv

[Andrey Rahmatullin]

On Sat, Nov 28, 2020 at 07:24:27PM +0500, Andrey Rahmatullin wrote:
> * There is some magic parsing in bindings/python/setup.py related to extra
> flags, with -std= being explicitly mentioned in a comment.
This is indeed the cause.

The "compile_cmd" file contains "g++ -std=c++11", which is the contents
of the CXX autoconf variable. The setup.py code extracts the flags from
this file and appends them to the extra_cmd var. That var is then put into
the extra_compile_args var and so it gets appended to all compilation
commands. This is of course wrong (in a normal CXX var substitution those
flags would be at the beginning, not at the end), and nothing sane can be
done about it.

It also seems that I've repeated someone else's work:
https://bugs.gentoo.org/739654
I will try a patch provided there.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#976120: (QAbc packaging) debhelper version question

[Andrey Rahmatullin]

On Fri, Dec 04, 2020 at 10:08:29PM +0100, Benoît Rouits wrote:
> Thank you for your reply.
> 
> I used to put this line:
> Build-Depends: debhelper-compat (= 12), ...
> 
> Should I then remove "-compat" like this ?
> Build-Depends: debhelper (= 13), ...
No. Build-Depends: debhelper is a normal build-depends while
Build-Depends: debhelper-compat is both a build-depends on debhelper (with
a >=) and a declaration of the compat level.
Please read the "COMPATIBILITY LEVELS" section in debhelper(7) for more
information.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#976120: (QAbc packaging) debhelper version question

[Andrey Rahmatullin]

On Fri, Dec 04, 2020 at 08:39:26PM +0100, Benoît Rouits wrote:
> I use debhelper but I don't use specific features
> of debhelper 13.
> Anyway, should I set debhelper = 13 as build dependency
Yes.

> or can I set debhelper >= 12 to be more flexible
> for transition from sid to testing and to stable ?
It won't help "for transition from sid to testing" and there is no
"transition to stable".

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#957206: dh_testroot: error: Package needs targeted root but builder has not provided a gain-root command via ${DEB_GAIN_ROOT_CMD}

[Andrey Rahmatullin]

On Tue, Dec 01, 2020 at 09:08:23PM +0100, Andreas Tille wrote:
> Control: tags -1 pending
> 
> Hi,
> 
> upstream of fis-gtm package[1] confirmed that the build needs some root
> permissions.  Thus I've set
> 
>Rules-Requires-Root: yes
There is no "Rules-Requires-Root: yes", see the Policy.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#976135: Breaks tt-rss

[Andrey Rahmatullin]

Package: php-php-gettext
Version: 1.0.12-1
Severity: serious
Control: affects -1 tt-rss

After upgrading php-php-gettext from 1.0.12-0.1 to 1.0.12-1 my tt-rss
installation no longer works, showing some JS errors on load. Apache error.log
contains this traceback:

PHP Fatal error:  Uncaught Error: Call to a member function evaluate() on null 
in /usr/share/php/php-php-gettext/gettext.php:325
Stack trace:
#0 /usr/share/php/php-php-gettext/gettext.php(351): 
gettext_reader->select_string()
#1 /usr/share/php/php-php-gettext/gettext.inc(293): gettext_reader->ngettext()
#2 /usr/share/tt-rss/www/include/functions.php(1725): _ngettext()
#3 /usr/share/tt-rss/www/index.php(114): init_js_translations()
#4 {main}
  thrown in /usr/share/php/php-php-gettext/gettext.php on line 325, referer: 


As far as I can see, gettext.php:325 was modified by
0002-Use-custom-parser-for-parsing-plural-expressions-ins.patch:

$plural = $plural_header->expression->evaluate($n);





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

Kernel: Linux 5.5.0-1-amd64 (SMP w/1 CPU thread)
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages php-php-gettext depends on:
ii  php-mbstring2:7.4+76
ii  php-pear1:1.10.9+submodules+notgz-1
ii  php7.4-mbstring [php-mbstring]  7.4.11-1

php-php-gettext recommends no packages.

php-php-gettext suggests no packages.

-- no debconf information

Bug#976035: Doesn't work with Python 3.9

[Andrey Rahmatullin]

Package: mitmproxy
Version: 5.1.1-2
Severity: grave
Tags: upstream fixed-upstream 
Control: forwarded -1 https://github.com/mitmproxy/mitmproxy/issues/4021

[...]
  File "/usr/lib/python3/dist-packages/mitmproxy/utils/typecheck.py", line 73,
in check_option_type
elif not isinstance(value, typeinfo):
  File "/usr/lib/python3.9/typing.py", line 697, in __instancecheck__
return self.__subclasscheck__(type(obj))
  File "/usr/lib/python3.9/typing.py", line 700, in __subclasscheck__
raise TypeError("Subscripted generics cannot be used with"
TypeError: Subscripted generics cannot be used with class and instance checks



This is fixed at https://github.com/mitmproxy/mitmproxy/pull/4179 but there is
no release since it was merged.



-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 
'unstable'), (500, 'testing'), (101, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.9.0-1-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.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 mitmproxy depends on:
ii  dpkg  1.20.5
ii  fonts-font-awesome5.0.10+really4.7.0~dfsg-2
ii  python3   3.9.0-3
ii  python3-blinker   1.4+dfsg1-0.3
ii  python3-brotli1.0.9-2+b1
ii  python3-certifi   2020.6.20-1
ii  python3-click 7.1.2-1
ii  python3-cryptography  3.2.1-1
ii  python3-flask 1.1.2-2
ii  python3-h11   0.11.0-1
ii  python3-h23.2.0-2
ii  python3-hyperframe5.2.0-4
ii  python3-kaitaistruct  0.8-3
ii  python3-ldap3 2.7-2
ii  python3-openssl   19.1.0-2
ii  python3-passlib   1.7.2-2
ii  python3-pkg-resources 50.3.0-1
ii  python3-protobuf  3.12.3-2+b1
ii  python3-publicsuffix2 2.20191221-2
ii  python3-pyasn10.4.8-1
ii  python3-pyparsing 2.4.7-1
ii  python3-pyperclip 1.8.0-1
ii  python3-ruamel.yaml   0.16.12-2
ii  python3-sortedcontainers  2.1.0-2
ii  python3-tornado   6.1.0-1
ii  python3-urwid 2.1.1-1+b1
ii  python3-wsproto   0.15.0-3

mitmproxy recommends no packages.

mitmproxy suggests no packages.

-- no debconf information

Bug#975953: Can't be imported, undefined symbol: _ZNK10libtorrent5entry4dictEv

[Andrey Rahmatullin]

On Fri, Nov 27, 2020 at 02:21:04PM +0500, Andrey Rahmatullin wrote:
> >>> import libtorrent
> Traceback (most recent call last):
>   File "", line 1, in 
> ImportError: 
> /usr/lib/python3/dist-packages/libtorrent.cpython-39-x86_64-linux-
> gnu.so: undefined symbol: _ZNK10libtorrent5entry4dictEv
> 
> $ ldd -r /usr/lib/python3/dist-packages/libtorrent.cpython-39-x86_64-linux-
> gnu.so | fgrep undefined | fgrep -v Py
> undefined symbol: _ZNK10libtorrent5entry4dictEv (/usr/lib/python3/dist-
> packages/libtorrent.cpython-39-x86_64-linux-gnu.so)
> undefined symbol: _ZN10libtorrent5entry4dictEv  (/usr/lib/python3/dist-
> packages/libtorrent.cpython-39-x86_64-linux-gnu.so)

So far I see these interesting things:
* These symbols are libtorrent::entry::dict() and the const version of it.
* libtorrent-rasterbar.so.10 instead exports 
libtorrent::entry::dict[abi:cxx11]().
* The most recent upload has "debian/rules: Pass --std=c++14" without any
explanation (made with "export DEB_CXXFLAGS_MAINT_APPEND  = -std=c++14").
* The build log shows that most compilation commands have both --std=c++11
and -std=c++14, 463 of them having -std=c++14 later and 80 having
--std=c++11 later. All of the latter commands seem to be for Python
bindings.
* There is some magic parsing in bindings/python/setup.py related to extra
flags, with -std= being explicitly mentioned in a comment.
* There seem to be some ABI compatiblity hacks in the code itself, see
TORRENT_CXX11_ABI (though it looks like it's only in CMakeLists.txt while
the package uses autotools.), it's also says it's about "clients building
with C++14 against libtorrent build with C++11" not vice versa.

So it looks like the Python bindings are compiled incorrectly, but I don't
see an obvious way to fix that, probably the setup.py magic needs fixing.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#975953: Can't be imported, undefined symbol: _ZNK10libtorrent5entry4dictEv

[Andrey Rahmatullin]

Package: python3-libtorrent
Version: 1.2.9-0.1
Severity: grave
Control: affects -1 + deluge deluged

>>> import libtorrent
Traceback (most recent call last):
  File "", line 1, in 
ImportError: /usr/lib/python3/dist-packages/libtorrent.cpython-39-x86_64-linux-
gnu.so: undefined symbol: _ZNK10libtorrent5entry4dictEv

$ ldd -r /usr/lib/python3/dist-packages/libtorrent.cpython-39-x86_64-linux-
gnu.so | fgrep undefined | fgrep -v Py
undefined symbol: _ZNK10libtorrent5entry4dictEv (/usr/lib/python3/dist-
packages/libtorrent.cpython-39-x86_64-linux-gnu.so)
undefined symbol: _ZN10libtorrent5entry4dictEv  (/usr/lib/python3/dist-
packages/libtorrent.cpython-39-x86_64-linux-gnu.so)



-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 
'unstable'), (500, 'testing'), (101, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.9.0-1-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.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 python3-libtorrent depends on:
ii  libboost-python1.71.0 [libboost-python1.71.0-py39]  1.71.0-7+b1
pn  libboost-python1.71.0-py38  
ii  libc6   2.31-4
ii  libgcc-s1   10.2.0-19
ii  libssl1.1   1.1.1h-1
ii  libstdc++6  10.2.0-19
ii  libtorrent-rasterbar10  1.2.9-0.1
ii  python3 3.9.0-3

python3-libtorrent recommends no packages.

python3-libtorrent suggests no packages.

-- debconf-show failed

Bug#975637: debian-policy: deprecate Rules-Requires-Root other than "no", "binary-targets" in Debian

[Andrey Rahmatullin]

On Tue, Nov 24, 2020 at 01:49:59PM +0100, Bill Allombert wrote:
> > After a discussion in #-devel today I reviewed packages using other
> > choices of "Rules-Requires-Root" than "no" and "binary-targets".  The
> > query [1] found two uses:
> > 
> > - wfrench 1.2.6-1.  This could just use "no"; a bug was filed[2].
> > 
> > - libcap2 1:2.44-1.  Uses it for running tests as root, but doesn't support
> >   fakeroot anyway.  Rules-Requires-Root can't however communicate this so
> >   additional knowledge is needed.
> > 
> > The complexity to support arbitrary additional keywords as choices of
> > R³ seems overkill given there is just one real user (libcap2) and the
> > current R³ specification doesn't handle that usecase fully either.
> > 
> > Therefore I suggest to deprecate using R³ values other than "no" and
> > "binary-targets" within Debian.
> 
> What about 'Rules-Requires-Root: yes' ?
What about it? The current policy doesn't support this value.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#974846: RFS: robot-testing-framework/2.0.1-1 [ITP] -- Robot Testing Framework

[Andrey Rahmatullin]

On Mon, Nov 16, 2020 at 01:13:01AM +1100, Stuart Prescott wrote:
> Hi Daniele 
> 
> I've not looked carefully at this package at all, but this one stood out:
> 
> >librobottestingframework-python2 - Robot Testing Framework -
> > RTF_python library
> 
> Now is not the time to be introducing things that depend on Python 2, given 
> that Python 2 is almost completely removed from the next release of Debian. 
> Can this package support Python 3 instead? If not, can the Python 2 bindings 
> be omitted? (Perhaps upstream would like some help in porting the code to 
> Python 3?)
https://github.com/robotology/robot-testing-framework/issues/37 is open
since 2015.
Looks like nobody was able to port the C code to the new API.
The bindings are disabled upstream ane re-enabled in d/rules.

-- 
WBR, wRAR


signature.asc
Description: PGP signature