Bug#1061230: python3-fava: Incompatible with python3-flask-babel version 4

[Carl Suster]

Package: python3-fava
Version: 1.23.1+dfsg-1
Severity: important
Tags: upstream

Dear Maintainer,

Fava appears to be incompatible with the version of flask-babel in Debian. Any
attempt to run it results in:

Traceback (most recent call last):
  File "/usr/bin/fava", line 5, in 
from fava.cli import main
  File "/usr/lib/python3/dist-packages/fava/cli.py", line 13, in 
from fava.application import app
  File "/usr/lib/python3/dist-packages/fava/application.py", line 152, in 

BABEL.localeselector(get_locale)

AttributeError: 'Babel' object has no attribute 'localeselector'

This appears to have been fixed upstream, with the fix appearing in version
1.24 (https://github.com/beancount/fava/issues/1549).

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

Kernel: Linux 6.6.11-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.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-fava depends on:
ii  python3  3.11.6-1
ii  python3-babel2.10.3-3
ii  python3-beancount2.3.6-1
ii  python3-cheroot  10.0.0+ds1-1
ii  python3-click8.1.6-1
ii  python3-flask2.2.5-1
ii  python3-flask-babel  4.0.0-1
ii  python3-jinja2   3.1.2-1
ii  python3-markdown22.4.11-1
ii  python3-ply  3.11-6
ii  python3-simplejson   3.19.2-1+b1
ii  python3-werkzeug 2.3.8-1

python3-fava recommends no packages.

python3-fava suggests no packages.

-- no debconf information

Bug#1050211: openvpn-dco-dkms: module fails to build for kernel 6.4.0: fatal error: net/gso.h: No such file or directory

[Carl Suster]

Package: openvpn-dco-dkms
Version: 0.0+git20230816-1
Severity: important

Dear Maintainer,

The module does not build in kernel 6.4.0 due to the file net/gso.h not being
found. I note that this is the same file introduced by the fix for #1043116.
Log follows.

  DKMS make.log for ovpn-dco-0.0+git20230816 for kernel 6.4.0-2-amd64 (x86_64)
  Tue 22 Aug 2023 14:49:19 AEST
  /var/lib/dkms/ovpn-dco/0.0+git20230816/build/gen-compat-autoconf.sh 
/var/lib/dkms/ovpn-dco/0.0+git20230816/build/compat-autoconf.h
  make -C /lib/modules/6.4.0-2-amd64/build 
M=/var/lib/dkms/ovpn-dco/0.0+git20230816/build 
PWD=/var/lib/dkms/ovpn-dco/0.0+git20230816/build REVISION=0.0+git20230816 
CONFIG_OVPN_DCO_V2=m INSTALL_MOD_DIR=updates/   modules
  make[1]: Entering directory '/usr/src/linux-headers-6.4.0-2-amd64'
CC [M]  
/var/lib/dkms/ovpn-dco/0.0+git20230816/build/drivers/net/ovpn-dco/main.o
CC [M]  
/var/lib/dkms/ovpn-dco/0.0+git20230816/build/drivers/net/ovpn-dco/bind.o
CC [M]  
/var/lib/dkms/ovpn-dco/0.0+git20230816/build/drivers/net/ovpn-dco/crypto.o
CC [M]  
/var/lib/dkms/ovpn-dco/0.0+git20230816/build/drivers/net/ovpn-dco/ovpn.o
  
/var/lib/dkms/ovpn-dco/0.0+git20230816/build/drivers/net/ovpn-dco/ovpn.c:25:10: 
fatal error: net/gso.h: No such file or directory
 25 | #include 
|  ^~~
  compilation terminated.
  make[3]: *** 
[/usr/src/linux-headers-6.4.0-2-common/scripts/Makefile.build:257: 
/var/lib/dkms/ovpn-dco/0.0+git20230816/build/drivers/net/ovpn-dco/ovpn.o] Error 
1
  make[3]: *** Waiting for unfinished jobs
  make[2]: *** 
[/usr/src/linux-headers-6.4.0-2-common/scripts/Makefile.build:499: 
/var/lib/dkms/ovpn-dco/0.0+git20230816/build/drivers/net/ovpn-dco] Error 2
  make[1]: *** [/usr/src/linux-headers-6.4.0-2-common/Makefile:2051: 
/var/lib/dkms/ovpn-dco/0.0+git20230816/build] Error 2
  make[1]: Leaving directory '/usr/src/linux-headers-6.4.0-2-amd64'
  make: *** [Makefile:59: all] Error 2


Carl


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

Kernel: Linux 6.4.0-2-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.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 openvpn-dco-dkms depends on:
ii  dkms  3.0.11-3

openvpn-dco-dkms recommends no packages.

openvpn-dco-dkms suggests no packages.

-- no debconf information

Bug#1043316: git-delta is a binary in git-extras

[Carl Suster]

Source: git-delta
Version: 0.16.5-2
Severity: wishlist

Dear Maintainer,

The package git-extras provides /usr/bin/git-delta and an associated man page.
This is completely unrelated to /usr/bin/delta provided by git-delta, other
than that they both work with git. I assume that most people would be looking
for this git-delta, not the other one, which is a very minimal script.

There's no technical issue since the binaries are named differently, but the
fact that /usr/bin/git-delta and `man git-delta` are not related to git-delta
makes things slightly confusing as a user.

Perhaps it's worth a note in README.Debian or the package description? Feel
free to close this if you disagree; just thought it was worth pointing out.

Bug#1028258: ddcci-dkms: Module fails to build for kernel 6.1

[Carl Suster]

Package: ddcci-dkms
Version: 0.4.2-3
Severity: important

Dear Maintainer,

The ddcci module failed to build with linux-headers-6.1.0-1-common:

DKMS make.log for ddcci-0.4.2 for kernel 6.1.0-1-amd64 (x86_64)
Mon 09 Jan 2023 09:26:34 AEDT
make: Entering directory '/var/lib/dkms/ddcci/0.4.2/build'
make -C "ddcci"
make[1]: Entering directory '/var/lib/dkms/ddcci/0.4.2/build/ddcci'
make -C "/lib/modules/6.1.0-1-amd64/build" 
M="/var/lib/dkms/ddcci/0.4.2/build/ddcci" modules
make[2]: Entering directory '/usr/src/linux-headers-6.1.0-1-amd64'
  CC [M]  /var/lib/dkms/ddcci/0.4.2/build/ddcci/ddcci.o
/var/lib/dkms/ddcci/0.4.2/build/ddcci/ddcci.c:1813:27: error: 
initialization of ‘void (*)(struct i2c_client *)’ from incompatible pointer 
type ‘int (*)(struct i2c_client *)’ [-Werror=inc>
 1813 | .remove = ddcci_remove,
  |   ^~~~
/var/lib/dkms/ddcci/0.4.2/build/ddcci/ddcci.c:1813:27: note: (near 
initialization for ‘ddcci_driver.remove’)
cc1: some warnings being treated as errors
make[3]: *** 
[/usr/src/linux-headers-6.1.0-1-common/scripts/Makefile.build:255: 
/var/lib/dkms/ddcci/0.4.2/build/ddcci/ddcci.o] Error 1
make[2]: *** [/usr/src/linux-headers-6.1.0-1-common/Makefile:2017: 
/var/lib/dkms/ddcci/0.4.2/build/ddcci] Error 2
make[2]: Leaving directory '/usr/src/linux-headers-6.1.0-1-amd64'
make[1]: *** [Makefile:38: ddcci.ko] Error 2
make[1]: Leaving directory '/var/lib/dkms/ddcci/0.4.2/build/ddcci'
make: *** [Makefile:28: ddcci] Error 2
make: Leaving directory '/var/lib/dkms/ddcci/0.4.2/build'


It looks like this is not yet fixed upstream: 
https://gitlab.com/ddcci-driver-linux/ddcci-driver-linux/-/issues/31


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

Kernel: Linux 6.0.0-6-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.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 ddcci-dkms depends on:
ii  dkms  3.0.9-1

ddcci-dkms recommends no packages.

ddcci-dkms suggests no packages.

-- no debconf information

Bug#1025278: sra-toolkit: binary sratools installed on PATH

[Carl Suster]

Package: sra-toolkit
Version: 3.0.0+dfsg-1
Severity: wishlist

Dear Maintainer,

sra-toolkit installs a binary /usr/bin/sratools, which is intended to be used
via the symlinks installed by the package (since its behaviour is influenced by
the name of the executable):

lrwxrwxrwx 1 root root 8 Nov 14 14:22 /usr/bin/fasterq-dump -> sratools
lrwxrwxrwx 1 root root 8 Nov 14 14:22 /usr/bin/fastq-dump -> sratools
lrwxrwxrwx 1 root root 8 Nov 14 14:22 /usr/bin/prefetch -> sratools
lrwxrwxrwx 1 root root 8 Nov 14 14:22 /usr/bin/sam-dump -> sratools
lrwxrwxrwx 1 root root 8 Nov 14 14:22 /usr/bin/sra-pileup -> sratools
lrwxrwxrwx 1 root root 8 Nov 14 14:22 /usr/bin/srapath -> sratools
lrwxrwxrwx 1 root root 8 Nov 14 14:22 /usr/bin/vdb-dump -> sratools

Invoking the executable by its original name does nothing useful:

$  /usr/bin/sratools
An error occured: unrecognized tool sratools
If this continues to happen, please contact the SRA Toolkit at 
https://trace.ncbi.nlm.nih.gov/Traces/sra/

Perhaps sratools should be installed in a private directory like
/usr/lib/sra-toolkit, leaving only the symlinks in /usr/bin.

Given the absence of man pages for the tools, and not being familiar with them,
this caused me some confusion because it appeared something was broken.

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

Kernel: Linux 6.0.0-4-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.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 sra-toolkit depends on:
ii  libbz2-1.0 1.0.8-5+b1
ii  libc6  2.36-6
ii  libhdf5-103-1  1.10.8+repack-4
ii  libmagic1  1:5.41-4
ii  libncbi-vdb3   3.0.0+dfsg2-4
ii  libncbi-wvdb2  2.11.2+dfsg-6
ii  libncbi-wvdb3  3.0.0+dfsg2-4
ii  libre2-9   20220601+dfsg-1
ii  libxml22.9.14+dfsg-1.1+b2
ii  zlib1g 1:1.2.13.dfsg-1

Versions of packages sra-toolkit recommends:
ii  med-config  3.7.3

sra-toolkit suggests no packages.

-- no debconf information

Bug#927989: RFA: terminaltables -- Python library for printing tables to the console

[Carl Suster]

Hi Daniel,

Please go ahead! It would make sense to also take on colorclass 
(https://bugs.debian.org/929658) at the same time since it's a dependency of 
terminaltables.

I pushed updates to git for both packages to track the new upstream forks, but 
didn't attempt to package new upstream versions. Feel free to remove me from 
the Uploaders.

Cheers,
Carl

On 16/9/22 09:17, Daniel Baumann wrote:

> Hi Carl,
>
> I'm maintaining all of the dbi packages (mycli, pglci, etc.) in Debian,
> which use terminaltables. I'm happy to also take care about
> terminaltables if that's fine with you.
>
> Regards,
> Daniel

Bug#889691: gedit-plugin-git: AttributeError calling get_repository on None

[Carl Suster]

Package: gedit-plugin-git
Followup-For: Bug #889691

I can no longer reproduce this issue so I assume it was fixed by an upstream
updated in the meantime.

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

Kernel: Linux 5.18.0-2-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.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 gedit-plugin-git depends on:
ii  gedit 42.1-1
ii  gedit-plugins-common  42.1-1
ii  gir1.2-ggit-1.0   1.0.0.1-2
ii  gir1.2-glib-2.0   1.72.0-1+b1
ii  gir1.2-gtk-3.03.24.34-1
ii  gir1.2-gtksource-44.8.3-1
ii  python3   3.10.4-1+b1
ii  python3-gi3.42.1-1
ii  python3-gi-cairo  3.42.1-1

gedit-plugin-git recommends no packages.

gedit-plugin-git suggests no packages.

-- no debconf information

Bug#927989: Looking for a new uploader for terminaltables and colorclass

[Carl Suster]

Hi python team,

I'm looking for someone to take over two python-team-maintained
packages: terminaltables and colorclass. These are related packages for
formatting text for output to the terminal, and both have had RFAs for a
while (in CC). terminaltables has several reverse dependencies.
colorclass has only 1 reverse build dependency: terminaltables.

Since I last touched the packages, a new upstream maintainer has taken
over both of them so the Debian packages should track the new forks and
update copyright and upstream data accordingly (I filed bugs for this).
Other than that, there shouldn't be much to do besides replacing me as
the uploader for both packages, since the team has taken care of routine
maintenance in the meantime.

Thanks,
Carl

Bug#1014036: colorclass: New upstream maintainer and repository

[Carl Suster]

Source: colorclass
Version: 2.2.0-3
Severity: normal

The original upstream maintainer of colorclass has archived the repository
on GitHub. Development now occurs at a new fork:

https://github.com/matthewdeanmartin/colorclass

The new maintainer has also been given control of the package on PyPi.

The debian package should be updated to track the new upstream repository.

Bug#1014035: terminaltables: New upsteam maintainer and repository

[Carl Suster]

Source: terminaltables
Version: 3.1.0-4
Severity: normal

The original upstream maintainer of terminaltables has archived the repository
on GitHub. Development now occurs at a new fork:

https://github.com/matthewdeanmartin/terminaltables

The new maintainer has also been given control of the package on PyPi.

The debian package should be updated to track the new upstream repository.

Bug#929658: RFA: colorclass -- ANSI color text library for Python

[Carl Suster]

python3-terminaltables build-depends on python3-colorclass since it tests 
interoperability and provides examples of using the packages together. I 
cancelled the RM request.

Perhaps there should also be a Suggests relationship added to reflect the 
interoperability.

Bug#1011593: RM: colorclass -- ROM; leaf package, no longer needed

[Carl Suster]

Package: ftp.debian.org
Severity: normal

I packaged this Python library as a dependency for an ITP that I eventually
dropped because of its large number of dependencies. I files an RFA for
colorclass a long time ago (#929658) and emailed the team list but have had no
takers. There are no reverse dependencies, so I think we should rm colorclass.

Bug#1011590: RM: plowshare -- ROM; effectively unmaintained upstream

[Carl Suster]

Package: ftp.debian.org
Severity: normal

Plowshare is a tool for interacting with file sharing websites. The plowshare
package itself contains only the framework (implemented in shell scripts) but
separate "modules" are needed to actually implement support for specific
websites.

The modules need to change rapidly to keep up with developments on the file
sharing websites, and as such are not a great fit for Debian packaging (I tried
in the past but eventually removed them). The upstream-endorsed way to get the
modules is to use a bundled script to download them, but there are security
concerns with downloading a bunch of shell scripts from the internet and
blindly executing them. There is also a security concern with the use of
a javascript engine to interact with the sometimes sketchy file sharing sites
that resulted in a Debian patch to disable this feature by default. With the JS
engine disabled, many modules don't work.

Upstream development on these modules has essentially stopped, and presumably
many are now broken. In theory you can write your own modules, in which case
the plowshare package has some value by itself. I suspect that few people would
do this though, especially without any public place to share modules and the
burden of maintaining them.

Popcon stats show a decline in reports for plowshare since the removal of the
modules. It is a leaf package with no reverse dependencies.

Bug#1010836: biosyntax-gedit: No longer works with recent versions of gedit

[Carl Suster]

Package: biosyntax-gedit
Version: 1.0.0b-2
Severity: important

Dear Maintainer,

The gedit support for biosyntax works by dropping files in:

/usr/share/gtksourceview-3.0/

The README.Debian says that this should cause a theme to appear in gedit at

Edit > Preferences > Font & Color > bioSyntax

No such entry appears. I notice that gedit depends on libgtksourceview-4-0 and
that there exist directories

/usr/share/gtksourceview-4/
/usr/share/gtksourceview-5/

I tested copying the style definition to the corresponding place under
gtksourceview-4/ and gedit picked it up properly, so it seems that the files
should be installed at that path instead.

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

Kernel: Linux 5.17.0-1-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.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 biosyntax-gedit depends on:
ii  biosyntax-common  1.0.0b-2
ii  gedit 42.0-2

biosyntax-gedit recommends no packages.

biosyntax-gedit suggests no packages.

-- no debconf information

Bug#1010834: biosyntax-vim: Unusable with vim-addon-manager because of outdated manifest

[Carl Suster]

Package: biosyntax-vim
Version: 1.0.0b-2
Severity: important

Dear Maintainer,

The instructions in README.Debian say that the addon should be installed with
vim-addon-manager, however:

$ vim-addons install biosyntax
Warning: ignoring 'biosyntax' which is missing source files

Helpfully, vim-addon-manager can list the files it's complaining about:

$ vim-addons files biosyntax | while read -r f; do test -e 
"/usr/share/vim/addons/$f" || echo "$f"; done
ftdetect/cwl.vim
ftdetect/nexus.vim
ftdetect/pml.vim
syntax/cwl.vim
syntax/nexus.vim
syntax/pml.vim

It looks like the manifest file at debian/biosyntax-vim.yaml includes extra 
files
that are no longer included in the upstream package:


https://salsa.debian.org/med-team/biosyntax/-/blob/580479a8ea5f26f67608fa38f4910180f4136b20/debian/biosyntax-vim.yaml

vs


https://salsa.debian.org/med-team/biosyntax/-/tree/b87d9d2c964e1c30ff82ff7c0883e82576d89043/vim

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

Kernel: Linux 5.17.0-1-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.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 biosyntax-vim depends on:
ii  biosyntax-common  1.0.0b-2
ii  vim   2:8.2.4793-1
ii  vim-gtk3 [vim]2:8.2.4793-1

Versions of packages biosyntax-vim recommends:
ii  vim-addon-manager  0.5.10

biosyntax-vim suggests no packages.

-- no debconf information

Bug#1010788: spades: Mismatch correction / --careful mode broken by Debian patch

[Carl Suster]

Package: spades
Version: 3.15.4+dfsg-1
Severity: normal

Dear Maintainer,

Using spades with the --careful flag triggers the following error:

Traceback (most recent call last):
  File "/usr/libexec/spades/spades.py", line 683, in 
main(sys.argv)
  File "/usr/libexec/spades/spades.py", line 621, in main
cfg, dataset_data, command_line = parse_args(args, log)
  File "/usr/libexec/spades/spades.py", line 257, in parse_args
options, cfg, dataset_data = options_parser.parse_args(log, bin_home, 
spades_home,
  File "/usr/share/spades/spades_pipeline/options_parser.py", line 1157, in 
parse_args
add_to_cfg(cfg, log, bin_home, spades_home, options_storage.args)
  File "/usr/share/spades/spades_pipeline/options_parser.py", line 995, in 
add_to_cfg
if which("bwa-spades"):
NameError: name 'which' is not defined

Reproducible with e.g.:

f="$(mktemp .fq)"
echo -e "@a\nA\n+\n!" > "$f"
spades --careful --12 "$f" -o "/tmp"

The code path related to that flag in options_parser.py has been patched in
Debian to add the call to which():


https://salsa.debian.org/med-team/spades/-/blob/d3c54b2ae8f0ee29a639fe0246d670fcad54b45b/debian/patches/0003_accept-system-bwa.patch#L82-L95

When the patch was initially created in this commit:


https://salsa.debian.org/med-team/spades/-/commit/ac1cfa145bf4066ca7f3af47db1aae6dd28ac5ab

the call and definition of which() were both in spades.py but the call was
later moved to options_parser.py while the definition was left behind unused.
Rather than adding multiple definitions of which() in the patch, the single
version in support.py could be imported wherever it needs to be used.


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

Kernel: Linux 5.17.0-1-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.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 spades depends on:
ii  bamtools   2.5.1+dfsg-10+b1
ii  bwa0.7.17-7
ii  libc6  2.33-7
ii  libgcc-s1  12.1.0-1
ii  libgomp1   12.1.0-1
ii  libnlopt0  2.7.1-4+b1
ii  libssw01.1-13
ii  libstdc++6 12.1.0-1
ii  python33.10.4-1+b1
ii  python3-distutils  3.9.12-1
ii  python3-joblib 0.17.0-4
ii  python3-yaml   5.4.1-1+b1
ii  samtools   1.13-4
ii  zlib1g 1:1.2.11.dfsg-4

spades recommends no packages.

spades suggests no packages.

-- no debconf information

Bug#998801: peruse: Missing dependency on kcm - unable to start

[Carl Suster]

Package: peruse
Version: 1.80+dfsg-1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

When launching peruse from a terminal, it fails to launch, printing this
message:

Failed to load the component from disk. Reported error was: 
"qrc:/qml/Main.qml:26 Type PeruseMain unavailable\nqrc:/qml/PeruseMain.qml:357 
Type Settings unavailable\nqrc:/qml/Settings.qml:29 module \"org.kde.kcm\" is 
not installed\n"

If I manually install qml-module-org-kde-kcm it works, so I assume this is
a missing dependency.


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

Kernel: Linux 5.14.0-3-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_DIE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.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 peruse depends on:
ii  kio5.86.0-1
ii  libc6  2.32-4
ii  libgcc-s1  11.2.0-10
ii  libkf5archive5 5.86.0-1
ii  libkf5baloo5   5.86.0-1
ii  libkf5configcore5  5.86.0-1
ii  libkf5coreaddons5  5.86.0-1
ii  libkf5crash5   5.86.0-1
ii  libkf5declarative5 5.86.0-1
ii  libkf5filemetadata35.86.0-1
ii  libkf5guiaddons5   5.86.0-1
ii  libkf5i18n55.86.0-1
ii  libkf5kiocore5 5.86.0-1
ii  libkf5kiowidgets5  5.86.0-1
ii  libkf5newstuffcore55.86.0-3
ii  libqt5core5a   5.15.2+dfsg-12
ii  libqt5gui5 5.15.2+dfsg-12
ii  libqt5qml5 [qtdeclarative-abi-5-15-2]  5.15.2+dfsg-8
ii  libqt5quick5   5.15.2+dfsg-8
ii  libqt5sql5 5.15.2+dfsg-12
ii  libqt5widgets5 5.15.2+dfsg-12
ii  libstdc++6 11.2.0-10
ii  peruse-common  1.80+dfsg-1
ii  qml-module-org-kde-kirigami2   5.86.0-1
ii  qml-module-org-kde-newstuff5.86.0-3
ii  qml-module-qt-labs-folderlistmodel 5.15.2+dfsg-8
ii  qml-module-qt-labs-settings5.15.2+dfsg-8
ii  qml-module-qtquick-controls5.15.2-2
ii  qml-module-qtquick-dialogs 5.15.2-2
ii  qml-module-qtquick-layouts 5.15.2+dfsg-8

peruse recommends no packages.

peruse suggests no packages.

-- no debconf information

Bug#969521: Browserpass icon disappears

[Carl Suster]

Just to note, this is firefox bug #969174 and is not specific to 
browserpass.

Bug#975115: webext-dav4tbsync and webext-tbsync out of sync

[Carl Suster]

Package: webext-dav4tbsync
Followup-For: Bug #975115

Hi Mechtilde,

I've just upgraded to tbsync 2.19-1 and now I have the opposite problem: tbsync
recognises that dav4tbsync is is installed, but claims that eas4tbsync is
missing.

The situation for the EAS provider is now similar to what I reported above. The
debug log shows:

** Wed Nov 25 2020 09:14:49 GMT+1100 (AEDT) **
[EventLog] : FAILED to load provider 
API version mismatch, TbSync@2.4 vs eas@Beta 2.4

** Wed Nov 25 2020 09:14:52 GMT+1100 (AEDT) **
[Loaded provider] : dav::CalDAV & CardDAV (1.23)

There's also a message in the log concerning the DAV provider, though it's
perhaps unrelated:

Component returned failure code: 0x8000 (NS_ERROR_UNEXPECTED) 
[nsIPrefBranch.getCharPref]


promisifiedHttpRequest/<@chrome://dav4tbsync/content/includes/network.js:515:64

promisifiedHttpRequest@chrome://dav4tbsync/content/includes/network.js:494:12
sendRequest@chrome://dav4tbsync/content/includes/network.js:428:33

I wonder if it's just that the providers need a stricter versioned dependency
relationship with the main tbsync package to reflect whatever API version
checks tbsync is doing internally?

Cheers,
Carl

-- System Information:
thunderbird1:78.5.0-1
webext-tbsync  2.19-1
webext-dav4tbsync  1.23-1
webext-eas4tbsync  1.20-1

Bug#975115: [Pkg-mozext-maintainers] Bug#975115: webext-dav4tbsync and webext-tbsync out of sync

[Carl Suster]

I've just noticed this message in the debug log for tbsync about the 
provider failing to load:


   ** Mon Nov 23 2020 17:43:57 GMT+1100 (AEDT) **
   [Initializing module] : 

   ** Mon Nov 23 2020 17:43:57 GMT+1100 (AEDT) **
   [TbSync init] : Done

   ** Mon Nov 23 2020 17:43:57 GMT+1100 (AEDT) **
   [EventLog] : FAILED to load provider 
   API version mismatch, TbSync@Beta 2.4 vs dav@2.4

Bug#975115: webext-dav4tbsync and webext-tbsync out of sync

[Carl Suster]

Package: webext-dav4tbsync
Version: 1.23-1
Followup-For: Bug #975115

I'm also having problems with this on sid. When I open the thunderbird addon
manager, I see tbsync, dav4tbsync, and eas4tbsync all installed and enabled.
All of these come from the debian packages. However, when I open the tbsync
config window it claims that dav4tbsync is not installed. There is no such
problem with eas4tbsync (webext-eas4tbsync 1.20-1), which works fine.


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

Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.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 webext-dav4tbsync depends on:
ii  thunderbird1:78.5.0-1
ii  webext-tbsync  2.18-2

webext-dav4tbsync recommends no packages.

webext-dav4tbsync suggests no packages.

-- no debconf information

Bug#971689: #971689

[Carl Suster]

The patch is attached. Looks like it was just that the tweener library 
was moved rather than removed.


https://github.com/pixel-saver/pixel-saver/commit/cceefae50cf85f725385c492d756f4e3257473b7.patch
>From cceefae50cf85f725385c492d756f4e3257473b7 Mon Sep 17 00:00:00 2001
From: Pellegrino Prevete 
Date: Thu, 1 Oct 2020 15:49:03 +0200
Subject: [PATCH] remove Tweener Shell dependency for 3.38 support

---
 pixel-sa...@deadalnix.me/app_menu.js | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/pixel-sa...@deadalnix.me/app_menu.js b/pixel-sa...@deadalnix.me/app_menu.js
index 51efd4c..138e29d 100644
--- a/pixel-sa...@deadalnix.me/app_menu.js
+++ b/pixel-sa...@deadalnix.me/app_menu.js
@@ -3,7 +3,7 @@ const Main = imports.ui.main;
 const Mainloop = imports.mainloop;
 const Shell = imports.gi.Shell;
 const St = imports.gi.St;
-const Tweener = imports.ui.tweener;
+const Tweener = imports.tweener.tweener;
 
 const ExtensionUtils = imports.misc.extensionUtils;
 const Me = ExtensionUtils.getCurrentExtension();

Bug#971689: gnome-shell-extension-pixelsaver: Fails with "No JS module 'tweener' found in search path"

[Carl Suster]

Package: gnome-shell-extension-pixelsaver
Version: 1.20-1
Severity: important

Dear Maintainer,

Looking in the "Extensions" app, Pixel Saver is disabled with an error message
"No JS module 'tweener' found in search path". Apparently this JS library was
part of Gnome Shell, but has since been removed. There is an upstream commit to
fix this.


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

Kernel: Linux 5.8.0-2-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.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 gnome-shell-extension-pixelsaver depends on:
ii  gnome-shell  3.38.0-2

gnome-shell-extension-pixelsaver recommends no packages.

gnome-shell-extension-pixelsaver suggests no packages.

-- no debconf information

Bug#944687: terminaltables: please remove config from debian/gbp.conf

[Carl Suster]

Thanks for sponsoring!

Sure, I'd left this config there since my first attempts at learning the 
gbp workflow. I understand why things like the pbuilder config don't 
belong in the package repo, but the branch/tag naming config is still 
relevant, no?


Cheers,
Carl

Bug#944577: RM: colorclass -- ROM; low-popcon leaf package

[Carl Suster]

Package: ftp.debian.org
Severity: normal

This is a leaf package with few users that was added as a dependency for
a now-abandoned ITP. I advertised for new uploaders and put up an RFA (#929658)
but there has been no interest.

Bug#944576: RM: python-pynzb -- ROM; unmaintained

[Carl Suster]

Package: ftp.debian.org
Severity: normal

This is a leaf package that is unmaintained upstream for >10 years.
I advertised for new uploaders and put up an RFA (#929670) but there has been
no interest.

Bug#855092: beets: FTBFS randomly (failing tests)

[Carl Suster]

Hi,

I'm an upstream contributor to beets and I was looking into the failures 
you're seeing here. I'm interested in making these tests reliable.


I tried to build the package on my (sid) laptop using sbuild and the 
latest packaging repo from salsa. I'm not able to reproduce these test 
failures. If I remove the Debian patches disabling tests, I'm still not 
able to reproduce any of the failures that led you to add those patches 
in the first case. I'm seeing three categories of tests here:


  1) The test in skip-broken-test. If the failure you're seeing is the 
same error on the GitHub issue you mention in that patch 
('musicbrainz.host'), then my suspicion is that when running the test 
beets is unable to find/read the file beets/config_default.yaml. One way 
this can happen is if beets is being invoked as a zipped egg rather than 
unpacked source (unsupported). Otherwise it might be that the build 
environment has paths set in an unusual way that interferes with beets' 
mechanism to find that YAML file relative to the invoked module.


  2) There are two tests failing due to filesystem access 
(test_no_write_permission and test_add_tags). Maybe we can do a better 
job of mocking here so that the actual filesystem isn't being tested. 
I'll take a look.


  3) The two test_import_task_created* tests exercise a feature based 
on a coroutine implementation (beets.util.pipeline), so I wonder if 
that's related? It's the only unusual thing I can think of off-hand. I 
know that the Debian build infrastructure is a little unusual, but I'm 
not sure what specifically the difference could be here.


If you can help point me in the right direction to reproduce these 
issues that would be appreciated.


Cheers,
Carl

Bug#929670: RFA: python-pynzb -- unified API for parsing NZB files from NNTP (Usenet) servers

[Carl Suster]

Package: wnpp
Severity: normal

I am no longer interested in maintaining python-pynzb in Debian, and the other
listed uploader doesn't currently have the time to maintain it either.

The package is currently team-maintained in DPMT, however I have not yet had
a response for my request for new uploaders there
(https://lists.debian.org/debian-python/2019/04/msg00015.html).
The package is currently in good shape and is up-to-date with upstream, which
has not seen any activity in a while (10 years!).

Since python3-pynzb is a leaf package with no reverse dependencies, I'll file
an RM bug eventually if this RFA doesn't attract a new maintainer.

Bug#929658: RFA: colorclass -- ANSI color text library for Python

[Carl Suster]

Package: wnpp
Severity: normal

I am no longer interested in maintaining colorclass in Debian. I initially
packaged it as a dependency for a now-abandoned ITP (FlexGet).

The package is currently team-maintained in DPMT, however I have not yet had
a response for my request for new uploaders there
(https://lists.debian.org/debian-python/2019/04/msg00015.html).
The package is currently in good shape and is up-to-date with upstream, which
has not seen a new release in a while.

Since colorclass is a leaf package with no reverse dependencies, I'll file an
RM bug eventually if this RFA doesn't attract a new maintainer.

Bug#927989: RFA: terminaltables

[Carl Suster]

Package: wnpp
Severity: normal

I am no longer interested in maintaining terminaltables in Debian. I initially
packaged it as a dependency for a now-abandoned ITP. In the meantime it has
picked up rdeps independently. I have included the maintainers of these rdeps
in CC in case they are able to help out.

The package is currently team-maintained in DPMT, however I have not yet had
a response for my request for new uploaders there
(https://lists.debian.org/debian-python/2019/04/msg00015.html).
The package is currently in good shape and is up-to-date with upstream, which
has not seen a new release in a while.

Bug#927988: RM: rpyc -- ROM; RC buggy leaf package

[Carl Suster]

Package: ftp.debian.org
Severity: normal

I initially packaged rpyc as a dependency for FlexGet. I no longer intend to
package FlexGet and therefore rpyc is no longer needed. It has no rdeps, and
has a FTBFS bug related to a test suite failure that I couldn't work out.

Bug#927841: plowshare: plowmod is inherently insecure

[Carl Suster]

Control: severity -1 normal

Thanks for your report.  I have to disagree about the severity of this 
issue, however.


To start with some history, the upstream developer moved all of the 
plowshare modules some time ago into a separate git repository with a 
name that included the word "legacy". At the time he contacted distro 
packagers and requested that we not package these modules at all. I 
decided to ignore this request and created plowshare-modules.


More recently, the upstream developer has stopped maintaining the 
"legacy" repo hosting the modules, although there are still users from 
the community contributing (unanswered) pull requests there and helping 
each other fix compatibility issues as the file sharing websites change. 
Given that there are no upstream releases and not even any upstream 
commits that could be used as pseudo-releases for plowshare-modules, it 
didn't make sense to keep it as a package in Debian without also 
adopting its upstream development (which I have no interest in doing). A 
plowshare-modules package would simply break over time and would not 
receive security updates from upstream. If anything its existence just 
created a false impression of security.


As I see it the threat model here involves two layers. Firstly the file 
sharing websites themselves could serve malicious code. This is 
mitigated in plowshare in Debian by disabling javascript execution 
unless the user explicitly opts in. There's not much more that can be 
done here given that we ultimately need to interact with those websites, 
because that's the whole point of plowshare.


The second layer is in the creation and distribution of the plowshare 
modules. As I mentioned there is no longer an official up-to-date source 
for them. A user can write them from scratch or download them from 
various sources. Plowmod merely assists with this by making the process 
easier when the user chooses to use a git repo as the source for these 
modules. It's not necessary to use plowmod at all though, since all you 
need is the modules files, put in a directory where plowshare can find them.


On reflection I think it's a good idea to remove the 
plowshare-modules-legacy URL from plowmod which is currently used as a 
default. This made sense at the time of the last plowshare release, but 
doesn't really continue to make sense. With that small change to plowmod 
it would be made clearer to users that the onus is on them to trust the 
source since none are provided by default.


I agree that overall it would be nicer to have a curated and maintained 
set of modules in Debian, however without upstream commitment that seems 
like rather a lot of work for the benefit of O(100) users of the 
plowshare package in Debian. If you'd like to take on this work then I'd 
welcome it, but in its absence I don't believe that the plowshare itself 
needs to be removed, or that the threat model you've suggested 
constitutes a fatal security flaw in plowshare.


Cheers,
Carl

Bug#852241: beets fails to move album when modifying artist

[Carl Suster]

Is this an issue you still observe in the latest version of beets?

This is pretty difficult to help with without having more details. The 
verbose log output of beets for the relevant command, and the full 
configuration file would be a good start.

Bug#687849: beets: silently fails to rewrite tags

[Carl Suster]

This bug is pretty much impossible to investigate without having more 
information, such as the actual files that exhibit the issue, verbose 
output from beets, the output of `beet info` for the relevant files, etc..


I think this should be closed. If it can be reproduced on a modern 
version of beets with more details then that can be a new bug report, 
but in any case it's probably better off being reported upstream.

Bug#927460: RM: plowshare-modules -- ROM; superseded by script in plowshare

[Carl Suster]

Package: ftp.debian.org
Severity: normal

Plowshare is a tool for interacting with file sharing websites. The framework
itself lives in the package plowshare, while the scripts that implement the
APIs for specific websites live in plowshare-modules. These scripts are not
suitable for a stable release since they evolve rapidly. The upstream source
was also disowned by the maintainer and now appears to be unmaintained.

The alternative is to use plowshare with scripts from some other source, and
there is a tool, plowmod, bundled with it to make this process work. I have
uploaded a version of plowshare to mentors that removes all reference to the
plowshare-modules package, which it previously Suggested.

Bug#911280: smartmontools: DEVICESCAN pattern doesn't match /dev/nvme*

[Carl Suster]

Package: smartmontools
Version: 6.6-1
Severity: normal

Dear Maintainer,

I see the same systemd error status reported in #862908, however unlike that
reporter my system does have an SSD disk, mounted at /dev/nvme0n1. If
I manually execute smartctl --all /dev/nvme0 I get SMART data, so it's clearly
a supported NVMe disk.

/dev/nvm* paths don't seem to be included in the pattern searched by DEVICESCAN
leading it to conclude that there are no disks. Is there any reason why the
default pattern can't be extended to include NVMe paths?

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

Kernel: Linux 4.18.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_AU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages smartmontools depends on:
ii  debianutils  4.8.6
ii  libc62.27-6
ii  libcap-ng0   0.7.9-1
ii  libgcc1  1:8.2.0-7
ii  libselinux1  2.8-1+b1
ii  libstdc++6   8.2.0-7
ii  lsb-base 9.20170808

Versions of packages smartmontools recommends:
ii  mailutils [mailx]  1:3.4-2

Versions of packages smartmontools suggests:
pn  gsmartcontrol   
pn  smart-notifier  

-- no debconf information

Bug#910122: apt-listbugs: executes xdg-open as root user

[Carl Suster]

Hi Francesco,

Thanks for your reply, and sorry I missed the archived bugs on this 
topic. I'm not sure yet that I fully understand the problems, but 
perhaps the situation is slightly different now in that the browser is 
being launched with xdg-open rather than sensible-browser? I'll have a 
look soon and see what I can find out.




A similar bug browsing menu in reportbugs's text UI works fine,
including the 'b' action to launch a browser, since it's run as a normal
user.


Actually, the menu you were seeing (the one with "I'm bored; quit
please") comes from the querybts command (part of package "reportbug").
When you enter "b1", apt-listbugs launches querybts and passes control
to it.


Thanks for pointing this out.


Cheers,
Carl

Bug#908941: rpyc FTBFS: test_registry.TestUdpRegistry failures

[Carl Suster]

Control: tags -1 + help

Thanks for reporting this.

On Sun, 16 Sep 2018 13:36:51 +0300 Adrian Bunk  wrote> 
Looking at the changelog, I'd suspect this might be caused by

  * Remove TestUdpRegistry patch rejected upstream


I agree this was the cause, but I'm not able to reproduce the build 
failure locally. The reason that upstream rejected my patch was because 
they said the failure indicated a potentially misconfigured machine and 
so they would prefer to have the test fail in this case.


I'm not really sure what's different about the build machines here 
that's triggering this failure. The previous FTBFS was due to a genuine 
upstream bug when running on a single core machine, so this could be 
something along those lines. Or it could just be a restriction on the 
build machines.


I won't have the chance to look into this for a while, and in any case 
I'm not so familiar with the upstream code or the build machines so if 
anyone has any ideas that would be appreciated.

Bug#909655: plowshare: Please add libmozjs-24-bin as a suggested or recommended dependency

[Carl Suster]

Control: tags -1 + pending

Thanks for your suggestion - this will be done in the next upload.

Bug#910122: apt-listbugs: executes xdg-open as root user

[Carl Suster]

In fact it seems that xdg-open _does_ search for firefox but has other 
issues when trying to open a URL as root. In its man page it explicitly 
advises against running as root, so I think it's really up to 
apt-listbugs to honour that advice here.


A similar bug browsing menu in reportbugs's text UI works fine, 
including the 'b' action to launch a browser, since it's run as a normal 
user.


And to clarify I was referring to the case when apt-listbugs is run as 
"/usr/sbin/apt-listbug apt" within the apt hook.

Bug#910122: apt-listbugs: executes xdg-open as root user

[Carl Suster]

Package: apt-listbugs
Version: 0.1.24
Severity: normal

Dear Maintainer,

When inspecting a bug presented by apt-listbugs (e.g. 'b1'), one of the
possible actions is to type 'b' to open the list of bugs in the browser. When
I attempt to do this it fails with an error message about xdg-open not being
able to find a browser (reproduced below).

It's not the fault of apt-listbugs that the 'b' function is broken; that's down
to the fact that xdg-utils is not configured for the root user, and its
hard-coded list of fallback browsers is missing /usr/bin/firefox.

However I wonder how much sense it makes to be running xdg-open as the root
user in the first place. It seems like all of the possible external actions in
this menu (launching email client or web browser) are things you would expect
to do as a normal user and probably wouldn't have configured for the root user.

Is there any way that apt-listbugs could drop down to a normal user for the
context of this menu and xdg-utils?


-- Relevant output:

What do you want to do now? [p|x|O|r|b|e|q|?]? ?
p - Show previous message (followup).
x - Provide extra information.
O - (default) Show other bug reports (return to bug listing).
r - Redisplay this message.
b - Launch web browser to read full log.
e - Launch e-mail client to read full log.
q - I'm bored; quit please.
? - Display this help.
What do you want to do now? [p|x|O|r|b|e|q|?]? b
No protocol specified
Unable to init server: Could not connect: Connection refused
Error: cannot open display: :0
[28965:28965:1003/102348.181557:ERROR:zygote_host_impl_linux.cc(89)] Running as 
root without --no-sandbox is not supported. See https://crbug.com/638180.
No protocol specified
Unable to init server: Could not connect: Connection refused
Error: cannot open display: :0
/usr/bin/xdg-open: 870: /usr/bin/xdg-open: iceweasel: not found
/usr/bin/xdg-open: 870: /usr/bin/xdg-open: seamonkey: not found
/usr/bin/xdg-open: 870: /usr/bin/xdg-open: mozilla: not found
/usr/bin/xdg-open: 870: /usr/bin/xdg-open: epiphany: not found
/usr/bin/xdg-open: 870: /usr/bin/xdg-open: konqueror: not found
/usr/bin/xdg-open: 870: /usr/bin/xdg-open: chromium: not found
/usr/bin/xdg-open: 870: /usr/bin/xdg-open: chromium-browser: not found
[28995:28995:1003/102348.230314:ERROR:zygote_host_impl_linux.cc(89)] Running as 
root without --no-sandbox is not supported. See https://crbug.com/638180.
/usr/bin/xdg-open: 870: /usr/bin/xdg-open: www-browser: not found
/usr/bin/xdg-open: 870: /usr/bin/xdg-open: links2: not found
/usr/bin/xdg-open: 870: /usr/bin/xdg-open: elinks: not found
/usr/bin/xdg-open: 870: /usr/bin/xdg-open: links: not found
/usr/bin/xdg-open: 870: /usr/bin/xdg-open: lynx: not found
/usr/bin/xdg-open: 870: /usr/bin/xdg-open: w3m: not found
xdg-open: no method available for opening 
'https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=909770=False=no'
What do you want to do now? [p|x|O|r|b|e|q|?]? 

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

Kernel: Linux 4.18.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_AU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages apt-listbugs depends on:
ii  apt 1.7.0~rc2
ii  ruby1:2.5.1
ii  ruby-debian 0.3.9+b8
ii  ruby-gettext3.2.9-1
ii  ruby-soap4r 2.0.5-4
ii  ruby-unicode0.4.4-2+b9
ii  ruby-xmlparser  0.7.3-3+b2

Versions of packages apt-listbugs recommends:
ii  ruby-httpclient  2.8.3-1

Versions of packages apt-listbugs suggests:
ii  firefox [www-browser]   62.0.2-1
ii  google-chrome-stable [www-browser]  69.0.3497.100-1
ii  reportbug   7.5.0
ii  sensible-utils  0.0.12

-- no debconf information

Bug#906721: RFS: plowshare/2.1.7-2

[Carl Suster]

Hi Herbert,

Thanks for looking at my packages. I'm not really sure how the old 
changelog diff happened other than that the commit responsible must have 
been lost somewhere in the migration of the repository from GitHub to 
GitLab to salsa. I fixed the changelog in a new commit.


What did you want me to update about the copyright? Whenever I do a new 
snapshot I go through the upstream diff to check for copyright statement 
changes and I didn't notice anything. I've now updated the year range 
for the packaging copyright in case that's what you meant.


Cheers,
Carl

Bug#907821: guessit: Upstream source doesn't include copyright statement

[Carl Suster]

Source: guessit
Severity: normal
Tags: upstream

While the debian copyright file includes attribution (also historical) to
upstream authors, there is no evidence for this in the actual source code
upstream apart from a mention of the latest of the three entries in the doc
building config.



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

Kernel: Linux 4.17.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_AU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#724718: Dependency status for flexget 2.14.19 (2018-08-26)

[Carl Suster]

Here's another update on the dependency situation for FlexGet.

Things are looking good because upstream FlexGet has been updating the 
dependency versions for several tricky packages so that shortly even 
guessit should point to the latest major version.


On the Debian side the only thing missing now is a current version of 
guessit. That has some complications but once done will clear the way.



FlexGet 2.14.19:
PY-PACKAGE   REQUIREMENT   SRC PACKAGE V.  STATUS
-
FeedParser   >=5.2.1   python-feedparser   5.2.1   OK
SQLAlchemy   >=1.0.9, <1.999   sqlalchemy  1.2.8   OK
PyYAML   * [1] pyyaml  3.12OK
beautifulsoup4   >=4.5 beautifulsoup4  4.6.3   OK
html5lib >=0.11html5lib1.0.1   OK
PyRSS2Gen* python-pyrss2gen1.1 OK
pynzb* python-pynzb0.1.0   OK
rpyc ==3.3.0 [1]   rpyc4.2.0   OK
jinja2   * jinja2  2.10OK
requests ~=2.16.3  requests2.18.4  OK
python-dateutil  >=2.5.3 [2]   python-dateutil 2.7.3   OK
jsonschema   >=2.0 python-jsonschema   2.6.0   OK
path.py  >=8.1.1   path.py 11.0.1  OK
guessit  <=2.1.4 [2]   guessit 0.11.0  #867862
rebulk   ==0.9.0 [2]   python-rebulk   0.9.0   OK
apscheduler  >=3.2.0   apscheduler 3.5.3   OK
terminaltables   >=3.1.0   terminaltables  3.1.0   OK
colorclass   >=2.2.0   colorclass  2.2.0   OK
-
Web UI dependencies - feature can be disabled for now
-
cherrypy >=3.7.0   cherrypy3   8.9.1   OK
flask>=0.7 flask   1.0.2   OK
flask-restful>=0.3.3   flask-restful   0.3.6   OK
flask-restplus   ==0.10.1  flask-restplus  --  #850089
flask-compress   >=1.2.1   flask-compress  1.4.0   OK
flask-login  >=0.4.0   flask-login 0.4.1   OK
flask-cors   >=2.1.2   flask-cors  --  #850091
pyparsing>=2.0.3   pyparsing   2.2.0   OK
zxcvbn-python* python-zxcvbn   4.4.25  OK
future   >=0.15.2  python-future   0.15.2  OK
+ many node.js packages
--
Dev requirements - maybe not all needed
--
sphinx   ==1.6.3   sphinx  1.7.8   OK
click==6.7 python-click6.7 OK
mock ==2.0.0   python-mock 2.0.0   OK
vcrpy~=1.11.1  vcr.py  1.11.1  OK
boto3* python-boto31.4.2   OK
pytest   >=3.3.0   pytest  3.6.4   OK
pytest-catchlog  >=1.2.2   pytest-catchlog 1.2.2   OK
pytest-xdist ==1.20.0  pytest-xdist1.22.2  OK
gitpython==2.1.5   python-git  2.1.11  OK
twine==1.11.0  twine   1.11.0  OK
subliminal   >= 2.0rc1 subliminal  1.1.1   OUTDATED

[1] https://github.com/Flexget/Flexget/pull/2193
[2] https://github.com/Flexget/Flexget/pull/2197

Bug#906721: RFS: plowshare/2.1.7-2

[Carl Suster]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "plowshare" and the related 
package "plowshare-modules". The main reason this is worth an upload is 
that I'm shifting the way the two packages are related in order to 
follow upstream recommendations. Specifically plowshare-modules should 
be kept out of Debian releases (but I intend to keep it in unstable 
hence the placeholder RC bug to prevent migration), and this requires a 
slight adjustment in the dependencies of plowshare itself.


Package name: plowshare
Version : 2.1.7-2
URL : https://salsa.debian.org/arcresu-guest/plowshare
Section : web

It builds these binary packages:

  plowshare  - download and upload files from file sharing websites
  plowshare4 - transitional dummy package

AND

Package name: plowshare-modules
Version : 0~git20180325.e4bd365-1
URL : https://salsa.debian.org/arcresu-guest/plowshare-modules
Section : web

It builds these binary packages:

  plowshare-modules - plowshare drivers for various file sharing websites

Getting the packages:

  https://mentors.debian.net/package/plowshare
  https://mentors.debian.net/package/plowshare-modules

  dget -x 
https://mentors.debian.net/debian/pool/main/p/plowshare/plowshare_2.1.7-2.dsc
  dget -x 
https://mentors.debian.net/debian/pool/main/p/plowshare-modules/plowshare-modules_0~git20180325.e4bd365-1.dsc


Changes since the last upload:

plowshare (2.1.7-2) unstable; urgency=medium

  * Update VCS to point to Salsa.
  * Correct typo in patch description.
  * Update debhelper compat to 11 (no changes).
  * Update to standards version 4.2.0:
- use HTTPS URL in changelog.
  * Set Rules-Requires-Root to no.
  * De-emphasise plowshare-modules in favour of plowmod:
- drop from Recommends to Suggests and
- promote git from Suggests to Recommends since the plowmod script
  that replaces the modules package requires git.

 -- Carl Suster   Tue, 14 Aug 2018 10:54:27 +1000

plowshare-modules (0~git20180325.e4bd365-1) unstable; urgency=medium

  * New upstream snapshot (git e4bd365):
+ fixed: 1fichier, catshare, filer.net, mediafire, uptobox.
  * Update standards version to 4.2.0 (no changes).
  * Update debhelper compat to 11 (no changes).
  * Add upstream metadata file.
  * Change VCS URLs to point to Salsa.
  * Add watch file.

 -- Carl Suster   Tue, 14 Aug 2018 14:21:42 +1000

Bug#906719: RFS: rpyc/4.0.2-1 [RC]

[Carl Suster]

Package: sponsorship-requests
Severity: important
X-Debbugs-CC: debian-pyt...@lists.debian.org

Dear mentors,

I am looking for a sponsor for my package "rpyc" maintained within the 
python modules team.


Package name: rpyc
Version : 4.0.2-1
URL : https://salsa.debian.org/python-team/modules/rpyc
Section : python

It builds these binary packages:

  python-rpyc-doc - transparent and symmetric Remote Python Call 
library -- documenta
  python3-rpyc - transparent and symmetric Remote Python Call library 
-- Python3 m


Getting the package:

  https://mentors.debian.net/package/rpyc

  dget -x 
https://mentors.debian.net/debian/pool/main/r/rpyc/rpyc_4.0.2-1.dsc


Changes since the last upload:

rpyc (4.0.2-1) unstable; urgency=medium

  [ Ondřej Nový ]
  * d/control: Set Vcs-* to salsa.debian.org
  * d/control: Remove ancient X-Python3-Version field

  [ Carl Suster ]
  * New upstream release (Closes: #904615).
  * Recommend python3-gevent to support the new gevent server (however this
feature is currently disabled due to crashes that are not yet 
understood).

  * Build-Depend on python3-gevent for the corresponding test (however this
test is currently disabled to match upstream CI configuration).
  * Make the build reproducible by applying the patch provided by Chris 
Lamb

(Closes: #893611).
  * Build-Depend on python3-sphinx-rtd-theme which is now used by the docs.
  * Stop cleaning up (in debian/rules) screencasts and CI image from 
docs that

no longer exist upstream.
  * Remove GitHub "fork me" banner from documentation.
  * Update Standards-Version to 4.2.0 (no changes needed).
  * Mark the doc package as M-A: foreign as per multiarch hinter.
  * Add upstream metadata file.
  * Bump debhelper compat to 11.

 -- Carl Suster   Tue, 14 Aug 2018 18:35:11 +1000

Bug#906003: Keep plowshare-modules out of Debian releases

[Carl Suster]

It probably shouldn't have been in stretch, but as long as it does not
cause trouble, you can let it rot there :-)


Agreed that it shouldn't have been released in stretch; at the time I 
had the idea of supporting it through backports. Given the relatively 
low popcon statistics and activity in bts, I think I prefer to just 
leave the package in stretch alone for now. If anyone is caught out by 
the situation later I can proceed with the patching and removing as 
outline above.


Carl

Bug#906003: Keep plowshare-modules out of Debian releases

[Carl Suster]

By now the snapshot that's in stretch is ~20 months out of date. Some of 
the modules will work and some won't, but over time more and more will 
break. The version of plowshare itself in stretch includes the plowmod 
script, so stretch users don't need the modules. I suppose by the same 
logic it makes sense to remove the modules package from stretch.


Plowshare currently Recommends plowshare-modules (I demote that to a 
Suggests in a new version on mentors for sid/testing) so I suppose the 
best course would be:


  1) Patch the stable version of plowshare to change the dependencies 
(remove plowshare-modules from Recommends, add git to Recommends) and 
get this into stretch-proposed-updates.


  2) File an RM bug against release.d.o for plowshare-modules in stable.

Does that sound reasonable? The alternative is just to leave the package 
in stretch alone and accept that it will degrade in functionality over 
time. Users are already able to use the plowmod script and ignore the 
plowshare-modules package there if they need more recent modules.


Carl

Bug#906003: Keep plowshare-modules out of Debian releases

[Carl Suster]

Package: plowshare-modules
Severity: serious
Justification: none

The plowshare-modules package contains scripts that need frequent replacing to
keep pace with changes to the websites supported by the scripts since those
sites make frequent changes.

The main package plowshare contains a script (plowmod) to maintain a user-local
copy of the modules, and tools to write your own modules. Upstream treated this
as the preferred way to install and discouraged package maintainers from
packaging the modules at all after they were split into a different upstream
repository and designated as "unofficial".

Given this I don't think it makes sense to keep plowshare-modules in Debian
releases. Plowshare itself can stay (and changes only infrequently upstream),
but the user should install the modules with the plowmod script.

I will still try to update the modules package for unstable periodically, but
this RC bug is to stop that effort from migrating to testing.



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

Kernel: Linux 4.17.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_AU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages plowshare-modules depends on:
pn  plowshare  

plowshare-modules recommends no packages.

plowshare-modules suggests no packages.

Bug#902287: systemctl unmask --runtime no longer supported

[Carl Suster]

On Sun, 24 Jun 2018 16:25:14 +0200 Michael Biebl  
wrote> According to codesearch we currently have two packages in the archive

using unmask --runtime: avahi and policykit-1

https://sources.debian.org/src/avahi/0.7-3.1/debian/avahi-daemon.postrm/?hl=7#L7

https://sources.debian.org/src/policykit-1/0.105-20/debian/policykit-1.postinst/?hl=58#L58
https://sources.debian.org/src/policykit-1/0.105-20/debian/policykit-1.preinst/?hl=15#L15


The postrm script of modemmanager is also affected: see #902260.

Bug#902260: modemmanager: postrm script broken: --runtime cannot be used with unmask

[Carl Suster]

From the recent changelog of systemd:

systemd (239-3) unstable; urgency=medium

   * Revert "systemctl: when removing enablement or mask symlinks, 
cover both /run and /etc"
 We currently have packages in the archive which use "systemctl 
--runtime unmask" and are broken by this change. This is a intermediate 
step until it is clear whether upstream will revert this commit or 
whether we will have to update affected packages to deal with this 
changed behaviour.

See #902287 and https://github.com/systemd/systemd/issues/9393

-- Michael Biebl  Wed, 27 Jun 2018 14:46:06 +0200

Looks like this package is also affected by #902287

Bug#902260: modemmanager: postrm script broken: --runtime cannot be used with unmask

[Carl Suster]

Package: modemmanager
Version: 1.7.990-1
Severity: important

Dear Maintainer,

When trying to remove the modemmanager package dpkg reports an error:

Performing actions...
(Reading database ... 370879 files and directories currently installed.)
Removing modemmanager (1.7.990-1) ...
--runtime cannot be used with unmask
dpkg: error processing package modemmanager (--remove):
 installed modemmanager package post-removal script subprocess returned 
error exit status 1
Errors were encountered while processing:
 modemmanager
E: Sub-process /usr/bin/dpkg returned an error code (1)

The first few lines of the postrm script are:

#!/bin/sh
set -e

# drop the temporary mask from prerm
if [ -d /run/systemd/system ] && [ "$1" = remove ]; then
systemctl unmask --runtime ModemManager
fi

And checking the man page of systemctl under --runtime:

--runtime
When used with set-property, make changes only temporarily, so that
they are lost on the next reboot.

[...]

Note: this option cannot be used with disable, unmask, preset, or
preset-all, because those operations sometimes need to remove
symlinks under /etc to have the desired effect, which would cause a
persistent change.

So it seems that the script is indeed incorrect in its usage of that flag.


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

Kernel: Linux 4.16.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_AU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages modemmanager depends on:
ii  libc6  2.27-3
ii  libglib2.0-0   2.56.1-2
ii  libgudev-1.0-0 232-2
pn  libmbim-glib4  
pn  libmbim-proxy  
ii  libmm-glib01.7.990-1
ii  libpolkit-gobject-1-0  0.105-20
pn  libqmi-glib5   
pn  libqmi-proxy   
ii  libsystemd0239-1

Versions of packages modemmanager recommends:
ii  usb-modeswitch  2.5.2+repack0-2

modemmanager suggests no packages.

-- no debconf information

Bug#901828: beets: Does not support recent MPD protocol versions

[Carl Suster]

Package: beets
Version: 1.4.7-1
Severity: normal
Tags: upstream
Forwarded: https://github.com/beetbox/beets/issues/800

I use beet's mpd server with Sonata as a client. The recent update to Sonata in
unstable means that it has started using the 'consume' API from the mpd
protocol which is from a newer version of the protocol than is supported by
beets. It means that beets can no longer be used with Sonata, which prints
errors like this indicating that the consume field of status is missing:

Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/sonata/main.py", line 985, in 
update_status
self.consumemenu.set_active(self.status['consume'] == '1')
KeyError: 'consume'

The problem is on beets' side though; we just got lucky before that the old
version of sonata wasn't using newer MPD protocol APIs.

There is an upstream bug about improving the MPD support, but not much activity
on it. I just wanted to open this bug to document the incompatibility between
the current debian packages until the situation is supported.

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

Kernel: Linux 4.16.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_AU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages beets depends on:
ii  libjs-backbone  1.3.3~dfsg-3
ii  libjs-jquery3.2.1-1
ii  libjs-underscore1.8.3~dfsg-1
ii  python3 3.6.5-3
ii  python3-jellyfish   0.5.6-3+b1
ii  python3-munkres 1.0.12+ds-1
ii  python3-musicbrainzngs  0.6-3
ii  python3-mutagen 1.40.0-1
ii  python3-pkg-resources   39.2.0-1
ii  python3-six 1.11.0-2
ii  python3-unidecode   1.0.22-1
ii  python3-yaml3.12-1+b1

beets recommends no packages.

Versions of packages beets suggests:
pn  beets-doc  
pn  libav-tools
pn  mp3gain
ii  python3-acoustid   1.1.2-2
ii  python3-bs44.6.0-1
ii  python3-dbus   1.2.8-2
pn  python3-flask  
pn  python3-gst-1.0
ii  python3-mpd1.0.0-2
ii  python3-pylast 2.2.0-1
pn  python3-rarfile
ii  python3-requests   2.18.4-2
pn  python3-requests-oauthlib  
ii  python3-xdg0.25-4

-- no debconf information

Bug#889691: gedit-plugin-git: AttributeError calling get_repository on None

[Carl Suster]

Package: gedit-plugin-git
Version: 3.22.0-4
Severity: normal

The system logs for gedit contain lines like the following coming from the git
plugin:

Feb  6 11:21:47 colt org.gnome.gedit[1326]: Traceback (most recent call last):
Feb  6 11:21:47 colt org.gnome.gedit[1326]:   File 
"/usr/lib/x86_64-linux-gnu/gedit/plugins/git/windowactivatable.py", line 291, 
in root_changed
Feb  6 11:21:47 colt org.gnome.gedit[1326]: repo = 
self.get_repository(location, True)
Feb  6 11:21:47 colt org.gnome.gedit[1326]:   File 
"/usr/lib/x86_64-linux-gnu/gedit/plugins/git/windowactivatable.py", line 282, 
in get_repository
Feb  6 11:21:47 colt org.gnome.gedit[1326]: return 
self.app_activatable.get_repository(location, is_dir)
Feb  6 11:21:47 colt org.gnome.gedit[1326]: AttributeError: 'NoneType' object 
has no attribute 'get_repository'
Feb  6 11:21:47 colt org.gnome.gedit[1326]: Traceback (most recent call last):
Feb  6 11:21:47 colt org.gnome.gedit[1326]:   File 
"/usr/lib/x86_64-linux-gnu/gedit/plugins/git/windowactivatable.py", line 298, 
in inserted
Feb  6 11:21:47 colt org.gnome.gedit[1326]: repo = 
self.get_repository(location, msg.is_directory)
Feb  6 11:21:47 colt org.gnome.gedit[1326]:   File 
"/usr/lib/x86_64-linux-gnu/gedit/plugins/git/windowactivatable.py", line 282, 
in get_repository
Feb  6 11:21:47 colt org.gnome.gedit[1326]: return 
self.app_activatable.get_repository(location, is_dir)
Feb  6 11:21:47 colt org.gnome.gedit[1326]: AttributeError: 'NoneType' object 
has no attribute 'get_repository'

Incidentally, the version of the plugin included in the debian package seems to
be very old. The copyright information installed with the package is a decade
behind the latest release, though the year in the plugin's about dialog is only
about 3 years behind upstream.


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

Kernel: Linux 4.14.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_AU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages gedit-plugin-git depends on:
ii  gedit 3.22.1-3
ii  gedit-plugins-common  3.22.0-4
ii  gir1.2-ggit-1.0   0.26.2-1
ii  gir1.2-glib-2.0   1.54.1-4
ii  gir1.2-gtk-3.03.22.26-2
ii  gir1.2-gtksource-3.0  3.24.6-1
ii  python3   3.6.4-1
ii  python3-gi3.26.1-2
ii  python3-gi-cairo  3.26.1-2

gedit-plugin-git recommends no packages.

gedit-plugin-git suggests no packages.

-- no debconf information

Bug#889116: logcheck-database: enhance more wpasupplicant rules with optional regex group

[Carl Suster]

Package: logcheck-database
Version: 1.3.18
Severity: wishlist
Tags: patch

Logcheck output includes lines like:

Feb  2 15:53:18 local wpa_supplicant[777]: wlp4s0: CTRL-EVENT-EAP-STARTED EAP 
authentication started
Feb  2 15:53:18 local wpa_supplicant[777]: wlp4s0: 
CTRL-EVENT-EAP-PROPOSED-METHOD vendor=0 method=26 -> NAK
Feb  2 15:53:18 local wpa_supplicant[777]: wlp4s0: 
CTRL-EVENT-EAP-PROPOSED-METHOD vendor=0 method=25
Feb  2 15:53:18 local wpa_supplicant[777]: wlp4s0: CTRL-EVENT-EAP-METHOD EAP 
vendor 0 method 25 (PEAP) selected
Feb  2 15:53:18 local wpa_supplicant[777]: wlp4s0: CTRL-EVENT-EAP-SUCCESS EAP 
authentication completed successfully

There is already the following rule intended to capture these:

^\w{3} [ :0-9]{11} [._[:alnum:]-]+ wpa_supplicant\[[0-9]+\]: 
CTRL-EVENT-EAP-(STARTED EAP authentication started|SUCCESS EAP authentication 
completed successfully|METHOD EAP vendor 0 method (17 \(LEAP|25 \(PEAP)\) 
selected)$

However this is not capturing the "wlp4s0: " part. Some other rules in the file 
contain optional
regexp groups to capture this part in other log lines, e.g.:

^\w{3} [ :0-9]{11} [._[:alnum:]-]+ wpa_supplicant\[[0-9]+\]: 
((wlan[0-9]|wlp[0-9]s[0-9]): )?CTRL-EVENT-SUBNET-STATUS-UPDATE status=0$

So could we replace the first rule above with:

^\w{3} [ :0-9]{11} [._[:alnum:]-]+ wpa_supplicant\[[0-9]+\]: 
((wlan[0-9]|wlp[0-9]s[0-9]): )?CTRL-EVENT-EAP-(STARTED EAP authentication 
started|SUCCESS EAP authentication completed successfully|METHOD EAP vendor 0 
method (17 \(LEAP|25 \(PEAP)\) selected)$

Bug#876413: [feedparser] new upstream version available

[Carl Suster]

Thanks! I updated the changelog in git as well now.

On 11/12/17 08:59, Antoine Beaupré wrote:

I did a source-only upload with only the slightest changes (added the
Closes entry and fixed the distribution field in the changelog), but I
can't push those because I am not in the DPTM team.

Bug#876413: [feedparser] new upstream version available

[Carl Suster]

Thanks - I actually already am adding myself to Uploaders in the 
existing package on mentors. .



That looks good to me, let's see if the maintainer picks it up -
otherwise I'll take care of doing a NMU.


The maintainer is DPMT of which I'm a member so I don't think this would 
have been an NMU anyway though.

Bug#827313: cherrypy3: please make the build reproducible

[Carl Suster]

Control: fixed -1 8.9.1-1

Looks like the latest version in experimental is reproducible, either 
from changes upstream or in dependencies.

Bug#851638: beets: bpd plugin unintentionally returns floats for status.time

[Carl Suster]

This was fixed in the latest version of beets uploaded.

Bug#877103: Bug #877103: Re: ITP: python-rebulk

[Carl Suster]

Yes, hopefully they sort it out upstream since someone revived the 
effort a couple of weeks ago. You're right about backporting, I hadn't 
really thought about that but it makes sense as an option if the next 
upstream versions change other dependencies.


Thanks for getting rebulk into Debian! Should I push my changes to the 
flexget repo or have you already done more work offline for that too?


Carl

Bug#877103: Bug #877103: Re: ITP: python-rebulk -- Define simple search patterns in bulk to perform advanced matching on any string

[Carl Suster]

Hi Etienne,

I just saw that you've uploaded python-rebulk 0.9.0-1 to NEW. I guess 
that means you weren't willing to upload the older version that flexget 
needed? I'll see if I can make it work with 0.9.0 but the flexget 
developers included a note saying that versions of rebulk above 0.8.2 
change the behaviour of guessit in incompatible ways.


Carl

Bug#876413: [feedparser] new upstream version available

[Carl Suster]

Hi Antoine,

I've updated the packaging of feedparser and pushed 5.2.1-1 to mentors:

https://mentors.debian.net/debian/pool/main/f/feedparser/feedparser_5.2.1-1.dsc

https://mentors.debian.net/package/feedparser

> Unfortunately, it seems the newer version from the `devel` branch may
> be needed for 3.5 support. As it stands now, 5.2.1 works fine in
> Python 3.5 here.

5.2.1 is at least a start, and maybe afterwards we can look at improving 
the python3 support. However it does seem that the project has been 
semi-abandoned upstream.


If you're still interested in feedparser, could you perhaps review my 
package?


A couple of the tests were failing but it wasn't obvious to me why they 
should ever have passed in the first place. For now I disabled those, 
and then later in a subsequent version I intend to investigate in more 
detail while exploring the python3 situation.


Carl

Bug#724718: Dependency status for flexget 2.11.5

[Carl Suster]

Control: unblock ! by 850089
Control: unblock ! by 850091

Another dependency status report. This time I've taken the version 
requirements from the looser requirements file rather than the frozen 
one, to reflect versions that flexget works with rather than what it was 
built with. I've also separated the dependencies that are only needed 
for the web UI feature, which can at least initially be disabled. It 
will be a lot of work to enable that because of all the node 
dependencies on top of these extra python ones.


With all that done, the list is looking pretty good! I've refreshed my 
RFS for rpyc since that expired last time. Guessit and rebulk are pinned 
to older versions by upstream, so I'm hoping I can get those specific 
versions into Debian for now. Then there's only feedparser to go.



FlexGet 2.11.5:
PY-PACKAGE   REQUIREMENT   SRC PACKAGE V.  STATUS
-
FeedParser   >=5.2.1   python-feedparser   5.1.3   OUTDATED
   ( #876413
SQLAlchemy   >=1.0.9, <1.999   sqlalchemy  1.1.11  OK
PyYAML   * pyyaml  3.12OK
beautifulsoup4   >=4.5 beautifulsoup4  4.6.0   OK
html5lib >=0.11html5lib0.  OK
PyRSS2Gen* python-pyrss2gen1.1 OK
pynzb* python-pynzb0.1.0   OK
rpyc ==3.3.0   rpyc--  RFS
   ( ITP: #850097,  RFS: #850670
jinja2   * jinja2  2.10OK
requests ~=2.16.3  requests2.18.1  OK
python-dateutil  >=2.5.3   python-dateutil 2.6.1   OK
jsonschema   >=2.0 python-jsonschema   2.6.0   OK
path.py  >=8.1.1   path.py 10.5OK
guessit  <=2.0.4   guessit 0.11.0  OUTDATED
( #867862 [1][2]
rebulk   ==0.8.2   --  ITP
  ( ITP: #877103
apscheduler  >=3.2.0   apscheduler 3.4.0   OK
terminaltables   >=3.1.0   terminaltables  3.1.0   OK
colorclass   >=2.2.0   colorclass  2.2.0   OK
-
Web UI dependencies - feature can be disabled for now
-
cherrypy >=3.7.0   cherrypy3   3.5.0   OUTDATED
  ( 8.9.1 is in experimental
flask>=0.7 flask   0.12.2  OK
flask-restful>=0.3.3   flask-restful   0.3.6   OK
flask-restplus   ==0.10.1  flask-restplus  --  ITP
  ( ITP: #850089
flask-compress   >=1.2.1   flask-compress  1.4.0   OK
flask-login  >=0.4.0   flask-login 0.4.0   OK
flask-cors   >=2.1.2   flask-cors  --  ITP
  ( ITP: #850091
pyparsing>=2.0.3   pyparsing   2.1.10  OK
zxcvbn-python* python-zxcvbn   4.4.16  OK
future   >=0.15.2  python-future   0.15.2  OK
--
Dev requirements - maybe not all needed
--
sphinx   ==1.6.3   sphinx  1.6.5   OK?
click==6.7 python-click6.7 OK
mock ==2.0.0   python-mock 2.0.0   OK
vcrpy~=1.11.1  vcr.py  1.11.1  OK
boto3* python-boto33.9.8   OK
pytest   >=3.3.0   pytest  3.2.1   OUTDATED?
pytest-catchlog  >=1.2.2   pytest-catchlog 1.2.2   OK
pytest-xdist ==1.20.0  pytest-xdist1.18.2  OK
gitpython==2.1.5   python-git  2.1.7   OK

[1] https://github.com/Flexget/Flexget/pull/1398
[2] https://github.com/Flexget/Flexget/issues/1804

Bug#877103: ITP: python-rebulk -- Define simple search patterns in bulk to perform advanced matching on any string

[Carl Suster]

Hi Etienne,

Rebulk (and guessit) is a dependency for a new package I'm working on 
getting into Debian, flexget, but unfortunately that currently is 
lagging behind in compatibility with these libraries.


I need to have guessit at <= 2.0.4, and rebulk at 0.8.2 exactly. I'd 
really appreciate if I could get these versions of the libraries first 
so that I can finish the initial packaging of flexget before helping its 
upstream to support the latest versions of guessit and rebulk.


Have you made any progress with this ITP or would you be happy for me to 
take it over (within DPMT)? I also started work on updating guessit, but 
I haven't pushed to git yet.


Cheers,
Carl

Bug#850670: RFS: rpyc/3.4.4-1 [ITP]

[Carl Suster]

retitle ! RFS: rpyc/3.4.4-1 [ITP]
thanks

I've updated to a recent upstream release and modern packaging.

You an find the new version on mentors:

https://mentors.debian.net/package/rpyc

dget -x https://mentors.debian.net/debian/pool/main/r/rpyc/rpyc_3.4.4-1.dsc

Cheers,
Carl

Bug#883130: RFS: colorclass/2.2.0-2

[Carl Suster]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for a small update to a python module:

https://mentors.debian.net/package/colorclass

dget -x 
https://mentors.debian.net/debian/pool/main/c/colorclass/colorclass_2.2.0-2.dsc


colorclass (2.2.0-2) unstable; urgency=medium

  * Upload to unstable.
  * Tell dh_compress to leave example.py alone.
  * Enable autopkgtest-pkg-python test suite.
  * Bump standards to 4.1.1, no changes needed.

 -- Carl Suster <c...@contraflo.ws>  Fri, 24 Nov 2017 13:21:26 +1100


Thanks,
Carl


On 24/11/17 16:17, Carl Suster wrote:

Dear DPMT,

Could someone please help me upload my latest version of the colorclass 
module? This is just moving it from experimental (where it landed due to 
the ongoing freeze at the time I last touched the package) to unstable 
and doing some very minor packaging updates.


I've uploaded the package to mentors but I'm unable to push my changes 
to DPMT git since I don't have ssh access any more. I'm not sure if this 
is related to the alioth replacement or if there is some other problem. 
In the meantime I pushed my changes to a temporary home on GitLab: 
https://gitlab.com/arcresu/colorclass



Thanks,
Carl

Bug#724718: Dependency status for flexget 2.10.66

[Carl Suster]

Control: unblock -1 by 850098
Control: block -1 by 857865
Control: block -1 by 856619

Just to update, it's been a while since I worked on this because I 
realised that the dependency situation was rather more complicated than 
I'd thought. There are many many node and bower packages required, but 
most of this is just to enable the web UI so it's probably possible to 
disable that feature for now to make it easier to get started here.


Below is the dependency status, ignoring node/bower. Some previous 
dependencies were dropped and some new ones have appeared.


FLEXGET 2.10.66
REQUIREMENT  SRC PACKAGE   STATUS BUGS/NOTES

cherrypy==10.2.2cherrypy3  OUTDATED   #828942 [W]
feedparser==5.2.1   python-feedparser  OUTDATED   [W]
flask-restful==0.3.6flask-restful  OUTDATED
future==0.16.0  python-future  OUTDATED
guessit==2.0.4  guessitOUTDATED   #867862 [1][2][N]
jsonschema==2.6.0   python-jsonschema  OUTDATED   #857865
pyparsing==2.2.0pyparsing  OUTDATED
python-dateutil==2.6.0  python-dateutilOUTDATED   #867865
requests==2.16.5requests   OUTDATED   #856619 [N]
rpyc==3.3.0 rpyc   RFSITP: #850097,
  RFS: #850670
flask-cors==3.0.2   flask-cors ITPITP: #850091
flask-restplus==0.10.1  flask-restplus ITPITP: #850089
rebulk==0.8.2  MISSING
vcrpy~=1.11.1  MISSING[D]
pytest-capturelog  MISSING[D] [3]
sqlalchemy==1.1.10  sqlalchemy TOO-NEW1.1.11
zxcvbn-python==4.4.14   python-zxcvbn  OK experimental
colorclass==2.2.0   colorclass OK experimental
apscheduler==3.3.1  apschedulerOK
beautifulsoup4==4.6.0   beautifulsoup4 OK
flask-compress==1.4.0   flask-compress OK
flask-login==0.4.0  flask-loginOK
flask==0.12.2   flask  OK
html5lib==0.9   html5lib   OK
jinja2==2.9.6   jinja2 OK
path.py==10.3.1 path.pyOK
pynzb==0.1.0python-pynzb   OK
pyrss2gen==1.1  python-pyrss2gen   OK
pyyaml==3.12pyyaml OK
terminaltables==3.1.0   terminaltables OK
click   python-click   OK [D]
boto3   python-boto3   OK [D]
pytest>=2.7,!=3.0.2 pytest OK [D]
pytest-xdistpytest-xdist   OK [D]
pytest-runner   pytest-runner  OK [D]
gitpython   python-git OK [D]

[D] dev dependency, maybe not needed
[N] latest upstream would be TOO-NEW
[W] WIP in git repo
[1] https://github.com/Flexget/Flexget/pull/1398
[2] https://github.com/Flexget/Flexget/issues/1804
[3] pytest-catchlog is packaged, and is a fork of this

Bug#867865: python-dateutil: New upstream version 2.6.0

[Carl Suster]

Source: python-dateutil
Severity: wishlist
Control: block 724718 by -1

There is a new upstream version which I will need soon for packaging flexget.
Could you consider updating? Thanks.

Bug#867862: guessit: Please package latest upstream version

[Carl Suster]

Source: guessit
Severity: wishlist
Control: block 724718 by -1

The upstream version is currently at 2.1.0 while the debian version 0.11.0.
I will eventually need a more modern version as a dependency for flexget.

Bug#859155: openafs-modules-dkms: Please support kernel 4.10

[Carl Suster]

Package: openafs-modules-dkms
Version: 1.6.20-2
Severity: wishlist
Tags: fixed-upstream patch
Forwarded: 
http://git.openafs.org/?p=openafs.git;a=commitdiff;h=789319bf0f2b26ad67995f8cbe88cee87a1bbdc0;hp=961cee00b8f5c302de5f66beb81caa33242c7971

The openafs module fails to build on kernel 4.10, and the fix upstream (related 
to have_submounts) is in 789319bf0f2b26ad67995f8cbe88cee87a1bbdc0.

Cheers,
Carl

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

Kernel: Linux 4.10.0-rc6-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_AU.utf8, LC_CTYPE=en_AU.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages openafs-modules-dkms depends on:
ii  dkms   2.3-3
ii  libc6-dev  2.24-9
pn  perl:any   

Versions of packages openafs-modules-dkms recommends:
ii  openafs-client  1.6.20-2

openafs-modules-dkms suggests no packages.

-- no debconf information

Bug#851630: beets: UnicodeDecodeError: 'utf8' codec can't decode

[Carl Suster]

Control: forwarded -1 https://github.com/beetbox/beets/issues/2168

The problem with decoding errors in broken utf8 filenames was fixed upstream and 
the fix seems to have made it into releases starting from 1.4.1

Bug#851016: beets: FTBFS: Test failures

[Carl Suster]

This looks like https://github.com/beetbox/beets/issues/2153 i.e. that the 
current version of mutagen that we have in Debian (1.36) is incompatible with 
the version of beets (1.3.19). Quoting from that issue:


 > when beets 1.3.19 was released, Mutagen 1.33 didn't exist yet.
 > When that was released, it changed the way exceptions work, which
 > broke those tests. We've since fixed compatibility with the
 > latest version, but we can't go back in time and change the
 > version specifier for 1.3.19.

So the easiest way to fix this will be to update to the latest upstream beets in 
Debian.

Bug#851638: beets: bpd plugin unintentionally returns floats for status.time

[Carl Suster]

Package: beets
Version: 1.3.19-2
Severity: minor
Tags: upstream
Control: affects -1 + mpdris2
Control: forwarded -1 https://github.com/beetbox/beets/issues/2394

Dear Maintainer,

There is a minor bug in upstream beets which affects the bpd plugin. This
plugin implements an mpd server but the bug causes it to return non-integer
values in the time field of the status command.

This doesn't seem to affect a lot of mpd clients which manage to cope with the
values anyway, but at least mpDris2 crashes immediately when launched connected
to an instance of beet bpm (ValueError: invalid literal for int() with base
10). There is also an upstream issue open against mpDris2 about making it more
robust to server responses (https://github.com/eonpatapon/mpDris2/issues/84).

Hopefully this bug report will save someone else the debugging effort until the
problems are sorted out upstream.

Bug#850487: RFS: terminaltables/3.1.0-1 [ITP]

[Carl Suster]

I have uploaded a new package to mentors and git which now builds successfully 
in a sid chroot with sbuild when given colorclass as an --extra-package.


I would ideally like this in unstable, but since colorclass is already in NEW 
targeting experimental, and this package depends on that one, my understanding 
is that this also needs to go into experimental for now.

Bug#850093: ITP: terminaltables -- Python library for printing tables to the console

[Carl Suster]

I have uploaded a new package to mentors and git which now builds successfully 
in a sid chroot with sbuild when given colorclass as an --extra-package.


I would ideally like this in unstable, but since colorclass is already in NEW 
targeting experimental, and this package depends on that one, my understanding 
is that this also needs to go into experimental for now.

Bug#850664: RFS: python-pynzb/0.1.0-3

[Carl Suster]

Control: tag -1 -moreinfo

Hi Sean,



I think you forgot to `git push` :)


Oops! Done.



Also, it would be good if you could use the Forwarded: header to
indicate whether your patches have been sent upstream or not.  This is
especially useful in team-maintained packages.  If you add this now,
don't forget `dch -r` and `git push` ;)


I added the Forwarded headers to point to pull requests I made upstream.


Thanks again,
Carl

Bug#850664: RFS: python-pynzb/0.1.0-3

[Carl Suster]

Hi Gianfranco,

Thanks for your comments!



what about calling 2to3 in setup.py?


I somehow overlooked that this was possible. That's much more sensible than what 
I was doing.




and you can patch the code with a retro-compatible code
if you can't find a way that works with both python2 and 3, there is the 
version_info
variable that can help you in understanding what is the current interpreter


Ok, I've added a patch to do it the sys.version_info way since there doesn't 
seem to be a more elegant option.




I'm mostly sure upstream would appreciate a porting/retrocompatible patch :)


I hope so!


I've uploaded a new version which removes the d/rules hacks and implements 
proper patches (to be forwarded upstream at a later date). New diff from the 
same base is below.


Cheers,
Carl


$ git diff 281489c

diff --git a/debian/.git-dpm b/debian/.git-dpm
index b634411..f93cbbb 100644
--- a/debian/.git-dpm
+++ b/debian/.git-dpm
@@ -1,6 +1,6 @@
 # see git-dpm(1) from git-dpm package
-0a5a3e9b44be1ec1a150c027a07754a53f039189
-0a5a3e9b44be1ec1a150c027a07754a53f039189
+591e67b26a2d694d5aae2d77985eab4d8daf2d9e
+591e67b26a2d694d5aae2d77985eab4d8daf2d9e
 124074ce42e5d83c71e028a8757afb392cc96548
 124074ce42e5d83c71e028a8757afb392cc96548
 python-pynzb_0.1.0.orig.tar.gz
diff --git a/debian/changelog b/debian/changelog
index c9a8606..2895253 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -2,27 +2,33 @@ python-pynzb (0.1.0-3) unstable; urgency=medium

   * Add myself to uploaders.
   * Switch to pybuild and dh-python.
-  * Bump d/compat to 10.
+  * Bump d/compat to 10 and update version of B-D on debhelper.
   * Bump standards-version to 3.9.8 (no changes).
-  * d/copyright: add myself and fix license short names
-- "public domain" -> public-domain
+  * d/copyright: add myself and fix license short names:
+- "public domain" -> public-domain,
 - BSD -> BSD-3-clause.
   * Change Vcs to DPMT git repository and use https.
-  * Change Homepage to GitHub.
-  * Build the Python 3 module and drop the Python 2 module (no rdeps).
-  * Run the test suite with pytest.
-  * Call 2to3 during auto build.
-  * 0001-set-message_id-properly-in-expat-parser.patch: fix an upstream code.
-This change allows the tests to pass for Python 2.
+  * Change Homepage to Github.
+  * Build the Python 3 module.
+- replace B-D: python{,3}-setuptools and python{,3}-all
+  * Drop the Python 2 module (no rdeps):
+  * Run the test suite with pytest:
+- cleanup the produced .cache/ in d/clean,
+- add B-D on python3-pytest.
+  * 0001-set-message_id-properly-in-expat-parser.patch: fix an upstream code
+typo. This change allows the tests to pass for Python 2.
+  * 0002-enable-use_2to3-in-setup.py.patch: enable 2to3 invocation in setup.py.
   * Move lxml to Suggests rather than Depends since there are fallbacks using
 standard library XML parsers.
   * Build-Depend on lxml in order to run the test for the implementation of the
 NZB parser using lxml (LXMLNZBParser).
-  * For Python 3, add a command to PYBUILD_AFTTER_BUILD_python3 in d/rules to
-change the code to decode strings -> bytes as utf-8 for lxml's benefit.
-  * Fix watch file.
+  * 0003-give-lxml-etree-BytesIO-in-Python-3.patch: make the code Python 3
+compatible by decoding strings -> bytes as UTF-8 and substituting BytesIO
+for StringIO. This only affects the LXMLNZPParser.
+  * Fix watch file and declare version 4 format.
+  * Cleanup .egg-info files in d/clean and d/source/options.

- -- Carl Suster <c...@contraflo.ws>  Tue, 10 Jan 2017 15:49:05 +1100
+ -- Carl Suster <c...@contraflo.ws>  Wed, 11 Jan 2017 23:24:01 +1100

 python-pynzb (0.1.0-2) unstable; urgency=low

diff --git a/debian/patches/0002-enable-use_2to3-in-setup.py.patch 
b/debian/patches/0002-enable-use_2to3-in-setup.py.patch

new file mode 100644
index 000..16f2a85
--- /dev/null
+++ b/debian/patches/0002-enable-use_2to3-in-setup.py.patch
@@ -0,0 +1,21 @@
+From 01027917584eafdf4228bf0590123dfd47fe14a8 Mon Sep 17 00:00:00 2001
+From: Carl Suster <c...@contraflo.ws>
+Date: Wed, 11 Jan 2017 22:23:32 +1100
+Subject: enable use_2to3 in setup.py
+
+---
+ setup.py | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+diff --git a/setup.py b/setup.py
+index 0fd9d51..62f1ff3 100644
+--- a/setup.py
 b/setup.py
+@@ -168,4 +168,5 @@ setup(
+ include_package_data=True,
+ zip_safe=False,
+ install_requires=['setuptools'],
+-)
+\ No newline at end of file
++use_2to3=True,
++)
diff --git a/debian/patches/0003-give-lxml-etree-BytesIO-in-Python-3.patch 
b/debian/patches/0003-give-lxml-etree-BytesIO-in-Python-3.patch

new file mode 100644
index 000..aac136f
--- /dev/null
+++ b/debian/patches/0003-give-lxml-etree-BytesIO-in-Python-3.patch
@@ -0,0 +1,40 @@
+From 591e67b26a2d694d5aae2d77985eab4d8daf2d9e Mon Sep 17 00:00:00 2001
+From: Carl Suster <c...@contraflo.ws>
+Date: Wed, 11 Jan 2017 2

Bug#850910: python-zxcvbn: Please change upstream source to the active fork

[Carl Suster]

Source: python-zxcvbn
Severity: wishlist

Dear Maintainer,

Your package is tracking the original Python implementation by Dropbox [1]
however that codebase is abandoned and the parent project at Dropbox [2]
now points instead to the fork dwolfhub/zxcvbn-python [3].

Besides being actively maintained, the new fork includes a proper test suite
and declares Python 3 support. The API has changed a bit, so that for example

  # original
  zxcvbn.main.password_strength('password', user_input=[])

  # new
  zxcvbn.zxcvbn('password', user_input=[])

I would be willing to work on this within the DPMT if you do not have the time
or inclination.

[1] https://github.com/dropbox/python-zxcvbn
[2] https://github.com/dropbox/zxcvbn
[3] https://github.com/dwolfhub/zxcvbn-python

Bug#850664: RFS: python-pynzb/0.1.0-3

[Carl Suster]

Control: tag -1 -moreinfo

Hi Sean,

Sorry about that. At your prompting I've installed sbuild and now the package 
builds successfully in a chroot for unstable using sbuild -A.


I've uploaded a new version to git and mentors, with the diff below since the 
version you last saw. As you can see I also amended the changelog to add some 
previously missing details.


Cheers,
Carl


$ git diff 281489c

diff --git a/debian/changelog b/debian/changelog
index c9a8606..b54d9a2 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -2,27 +2,32 @@ python-pynzb (0.1.0-3) unstable; urgency=medium

   * Add myself to uploaders.
   * Switch to pybuild and dh-python.
-  * Bump d/compat to 10.
+  * Bump d/compat to 10 and update version of B-D on debhelper.
   * Bump standards-version to 3.9.8 (no changes).
-  * d/copyright: add myself and fix license short names
-- "public domain" -> public-domain
+  * d/copyright: add myself and fix license short names:
+- "public domain" -> public-domain,
 - BSD -> BSD-3-clause.
   * Change Vcs to DPMT git repository and use https.
-  * Change Homepage to GitHub.
-  * Build the Python 3 module and drop the Python 2 module (no rdeps).
-  * Run the test suite with pytest.
-  * Call 2to3 during auto build.
-  * 0001-set-message_id-properly-in-expat-parser.patch: fix an upstream code.
-This change allows the tests to pass for Python 2.
+  * Change Homepage to Github.
+  * Build the Python 3 module.
+- replace B-D: python{,3}-setuptools and python{,3}-all
+  * Drop the Python 2 module (no rdeps):
+  * Run the test suite with pytest:
+- cleanup the produced .cache/ in d/clean,
+- add B-D on python3-pytest.
+  * Call 2to3-3.Y during auto build for Python 3.X.
+  * 0001-set-message_id-properly-in-expat-parser.patch: fix an upstream code
+typo. This change allows the tests to pass for Python 2.
   * Move lxml to Suggests rather than Depends since there are fallbacks using
 standard library XML parsers.
   * Build-Depend on lxml in order to run the test for the implementation of the
 NZB parser using lxml (LXMLNZBParser).
   * For Python 3, add a command to PYBUILD_AFTTER_BUILD_python3 in d/rules to
 change the code to decode strings -> bytes as utf-8 for lxml's benefit.
-  * Fix watch file.
+  * Fix watch file and declare version 4 format.
+  * Cleanup .egg-info files in d/clean and d/source/options.

- -- Carl Suster <c...@contraflo.ws>  Tue, 10 Jan 2017 15:49:05 +1100
+ -- Carl Suster <c...@contraflo.ws>  Wed, 11 Jan 2017 15:53:36 +1100

 python-pynzb (0.1.0-2) unstable; urgency=low

diff --git a/debian/rules b/debian/rules
index e7aefc0..1300e4a 100755
--- a/debian/rules
+++ b/debian/rules
@@ -8,7 +8,7 @@ export PYBUILD_TEST_ARGS=pynzb/tests.py
 # utf-8 for the Python 3 build. If this turns out to be problematic, we can
 # instead disable lxml support for the Python 3 build in pynzb/__init__.py and
 # rely on the standard library fallbacks for XML parsing.
-export PYBUILD_AFTER_BUILD_python3=2to3 -n -w {build_dir}/pynzb/; sed -i -e 
's/StringIO/BytesIO/g' -e 's/BytesIO(xml)/BytesIO(bytes(xml,"utf-8"))/' 
{build_dir}/pynzb/lxml_nzb.py
+export PYBUILD_AFTER_BUILD_python3=2to3-{version} -n -w {build_dir}/pynzb/; sed 
-i -e 's/StringIO/BytesIO/g' -e 's/BytesIO(xml)/BytesIO(bytes(xml,"utf-8"))/' 
{build_dir}/pynzb/lxml_nzb.py



 %:

Bug#850607: RFS: flask-login/0.4.0-1 [ITA]

[Carl Suster]

Control: tag -1 -moreinfo

Hi Sean,

Thanks for your second review.



- The package does not build against sid.  See attached log.


I was having problems understanding how to setup a chroot build what with the 
array of tools available: pdebuild, cowbuilder, etc. I see you're using sbuild 
which I wasn't even aware of, so now I've installed and configured that. Thanks 
for the pointer.


The build now succeeds with sbuild -A since I've added the missing B-Ds.



- Updates to d/clean not mentioned in changelog.

> - Edits to d/source/options

- Lots of changes to the build-deps not mentioned in changelog.

> - The new 0002 patch is not in the changelog.
> - doc-base registration not in changelog
> - Installation of README.md not in changelog

Added/adjusted changelog entries to cover all of these.



- It's odd for the -doc package to recommend the main package.  See the
  description of Recommends: in Debian policy -- the relationship is
  quite strong, but someone might want to read the docs on their dev
  machine and use the library on some container/server.


Ok, I wasn't really sure of the convention and I think the first random package 
I checked had the asymmetrical relationship with its -doc package. I'll make it 
a Suggests in both directions.




- Could you explain why you have three "override_dh_sphinxdoc"?
  Possibly you're using some Makefile syntax I'm not familiar with.


Yes this is the syntax for specifying target-specific variables:

  https://www.gnu.org/software/make/manual/html_node/Target_002dspecific.html

I based the rule on the DPMT wiki, which uses this syntax:

  https://wiki.debian.org/Python/LibraryStyleGuide#Sphinx_documentation



If you're able to address the issues I've raised in this message,
please remove the moreinfo tag in this bug, and don't forget to
re-run `dch -r` to refresh the changelog timestamp.


Done! Uploaded to git and mentors, the diff since your last review is below.


Cheers,
Carl


$ git diff 57c7cc9
diff --git a/debian/changelog b/debian/changelog
index 33b9e0b..7c38769 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -2,20 +2,35 @@ flask-login (0.4.0-1) unstable; urgency=medium

   * New upstream release.
   * New maintainer (Closes: #836501).
-  * Update d/compat to 10.
-  * Switch to using dh-python.
+  * Update d/compat to 10 and raise B-D on debhelper accordingly.
+  * Switch to using dh-python:
+- add B-D on dh-python.
   * Add myself to d/copyright for debian/.
   * Change d/watch to follow GitHub releases.
   * Change homepage to GitHub.
-  * Build the Python 3 module (Closes: #802614).
+  * Build the Python 3 module (Closes: #802614):
+- replace B-Ds python{,3}-all and python{,3}-setuptools.
   * Stop building the Python 2 module (no rdepends).
   * Move Vcs to DPMT git.
   * Bump standards version to 3.9.8 (no changes).
-  * Build the documentation in a -doc package.
+  * Build the documentation in a -doc package:
+- add B-D on python-sphinx,
+- add links from the /usr/share/doc/python3-flask-login to
+  /user/share/doc/python3-flask-login-doc,
+- register with doc-base,
+- make the Python 3 module and -doc package Suggest each other.
+  * Install the upstream README file.
   * Add 0001-disable-github-fork-ribbon.patch to turn off the GitHub ribbon.
-  * Run the test suite using upstream's makefile.
+  * Add 0002-allow-choice-of-nosetests-executable-in-run-tests.sh.patch to
+allow the tests to be run with nosetests3 for the Python 3 package.
+  * Run the test suite using upstream's makefile:
+- add B-Ds on python3-flask, python3-mock, python3-nose, python3-werkzeug
+  and python3-blinker,
+- cleanup tests_output/ and .coverage in d/clean.
+  * Use more general rule to ignore egg-info directory in d/clean and
+d/source/options.

- -- Carl Suster <c...@contraflo.ws>  Tue, 10 Jan 2017 15:23:33 +1100
+ -- Carl Suster <c...@contraflo.ws>  Wed, 11 Jan 2017 14:23:07 +1100

 flask-login (0.2.6-1) unstable; urgency=low

diff --git a/debian/control b/debian/control
index 5af8224..49d3948 100644
--- a/debian/control
+++ b/debian/control
@@ -6,12 +6,14 @@ Priority: optional
 Build-Depends:
  debhelper (>= 10),
  dh-python,
- python-flask,
  python-sphinx,
  python3-all,
  python3-blinker,
+ python3-flask,
+ python3-mock,
  python3-nose,
  python3-setuptools,
+ python3-werkzeug,
 Standards-Version: 3.9.8
 Homepage: https://github.com/maxcountryman/flask-login
 X-Python3-Version: >= 3.3
@@ -38,7 +40,7 @@ Package: python3-flask-login-doc
 Architecture: all
 Section: doc
 Depends: ${misc:Depends}, ${sphinxdoc:Depends}
-Recommends: python3-flask-login
+Suggests: python3-flask-login
 Description: user session management for Flask -- documentation
  Flask-Login provides user session management for Flask. It handles the
  common tasks of logging in, logging out, and remembering your users'

Bug#850664: RFS: python-pynzb/0.1.0-3

[Carl Suster]

Control: tag -1 -moreinfo

Hi Sean,

Thanks for your review!



 The Python 2 module can still be built fine, but I removed it since
there were no rdeps.


As in my reponse to your other RFS, I'd like to confirm that this is
DPMT policy.


I don't think that it's a team policy specifically, I was just prompted by the 
lintian tag which was enabled to inform about the slowly approaching EOL of 
Python 2 in Debian, aimed at packages in the buster cycle 
(https://bugs.debian.org/829744) which is where this package is going.


If you prefer to keep the Python 2 module then I'm happy to reinstate it.



Changes since the last upload:

  * 0001-set-message_id-properly-in-expat-parser.patch: fix an upstream code.
Tests pass for Python 2 with only this change.


Your grammar is misleading.  ITYM "Tests pass for Python 2 only with
this change."


Now reads: "This change allows the tests to pass for Python 2."



  * Move lxml to Suggests since there are fallbacks, but Build-Depend on it to
run the tests.


It would be clearer to split this into two changlog entries, i.e.

* Move lxml to Suggests [from ??].
* Add build-dep on lxml to run the tests.


Now reads:

  * Move lxml to Suggests rather than Depends since there are fallbacks using
standard library XML parsers.
  * Build-Depend on lxml in order to run the test for the implementation of the
NZB parser using lxml (LXMLNZBParser).



  * For Python 3, decode strings -> bytes as utf-8 for lxml.


How did you make this change?  With a patch to the upstream code?
Please explain.


Actually this was something I wasn't quite sure about. Although I'm only 
building the Python 3 package, I wanted the source package to be able to easily 
build both the Python 2 & 3 packages in case that was desired. For that reason I 
put the Python 3 specific changes in d/rules instead of making a patch. I'm not 
sure if that's considered bad practice, but I think the only alternatives would 
be (a) forget about Python 2 support and just add a patch or (b) add a patch 
with a branch in the code based on the runtime version.


Anyway I clarified the changelog entry for now:

  * For Python 3, add a command to PYBUILD_AFTTER_BUILD_python3 in d/rules to
change the code to decode strings -> bytes as utf-8 for lxml's benefit.

And this is the relevant line of d/rules:

# lxml expects a bytes object in Python 3 so we simply decode the string as
# utf-8 for the Python 3 build. If this turns out to be problematic, we can
# instead disable lxml support for the Python 3 build in pynzb/__init__.py and
# rely on the standard library fallbacks for XML parsing.
export PYBUILD_AFTER_BUILD_python3=2to3 -n -w {build_dir}/pynzb/; sed -i -e 
's/StringIO/BytesIO/g' -e 's/BytesIO(xml)/BytesIO(bytes(xml,"utf-8"))/' 
{build_dir}/pynzb/lxml_nzb.py




  * Fix watch file (although the last release was some time ago).


Please consider dropping the parathetical remark.  It's not really
appropriate for a packaging changelog.


Done. There is a new version in mentors and git.


Cheers,
Carl

Bug#850607: RFS: flask-login/0.4.0-1 [ITA]

[Carl Suster]

Control: tag -1 -moreinfo

Hi Sean,

Thanks for your interest in flask-login!


> Can a potential sponsor work out of your Vcs-Git repository?

The Python modules team has a standard location for git repositories on alioth 
so that's where I've kept it. Commit access is automatic for all DDs and by 
request for anyone else. You just have to abide by the policy 
(https://python-modules.alioth.debian.org/policy.html) which amounts to "use a 
git-dpm workflow unless there's a good reason not to".



> I notice that the changelog suite in your repository is unstable,
> but in the RFS you indicate that you want this package to be
> uploaded to experimental.  Which is right?

I initially chose experimental because I didn't want to interfere with the 
stretch freeze, but I was since told that it was fine to upload to unstable 
since the migration to testing is handled differently during the freeze. I only 
want to upload to experimental if it's necessary because of the freeze (I'm not 
targeting stretch), otherwise unstable is preferable.



>> I have dropped the Python 2 module binary package since there
>> were no rdeps and my understanding is that going forward we
>> don't want to keep around unnecessary Python 2 packages.
>
> I'm not on the python modules team -- could you how you got this
> understanding?  I'm not doubting your knowledge, but I'd like to
> confirm.

From the lintian tag new-package-should-not-package-python2-module:

  This package appears to be the first packaging of a new upstream
  software package but it appears to package a module for Python 2.

  The 2.x series of Python is due for deprecation and will not be
  maintained past 2020 so it is recommended that Python 2 modules
  are not packaged unless necessary.

  This warning can be ignored if the package is not intended for
  Debian or if it is a split of an existing Debian package.

  Severity: wishlist, Certainty: certain

  Check: scripts, Type: binary

This is not a new package obviously, but since the Python 2 module has no rdeps 
I figured that dropping it was in line with the above goal. It's no problem to 
reinstate it though.



>>   * Relicense debian/* as Expat to match upstream.
>
> Only Tonnerre Lombard can relicense Tonnerre Lombard's work.
> Please revert this change.

I understand, but the reason I felt I could do this was because I've overwritten 
pretty much every line under debian/ apart from the old changelog entry and the 
upstream license text. Anyway I've reverted the copyright to GPL-2+ in a new 
upload to mentors & git.



> If you're able to address the issues I've raised in this message,
> please remove the moreinfo tag in this bug, and don't forget to
> re-run `dch -r` to refresh the changelog timestamp.

Done!


Cheers,
Carl

Bug#850098: #850098 subliminal: change of upstream structure

[Carl Suster]

I see that subliminal is currently using the tarballs from PyPI and then 
patching in the source for the nautilus extension which is of course absent 
from there. Also the Github-hosted tarballs include a test suite which is not 
in the PyPI tarballs.


It seems that the upstream nautilus extension has now moved to a different 
dedicated upstream repo:


  https://github.com/Diaoul/nautilus-subliminal

Unfortunately this repository does not seem to have versioned releases, and has 
not seen an update in several months. My thinking is that if we continue to 
provide the nautilus extension at all, it should be built by a new source 
package src:subliminal-nautilus (which could potentially also build the nemo 
extension provided in a different branch of the upstream repo) tracking 
snapshots of the upstream git.


I am happy to work on this as part of packaging the latest upstream release, 
but I just wanted to check before I do so that:


  1) the source split I proposed is sensible (if so I'll probably just drop 
the nautilus extension for now and reopen https://bugs.debian.org/821455 until 
I repackage the extension in its new home), and


  2) if the split is ok, which if either Python packaging team would make a 
good home for the nautilus extension, and


  3) it's ok to change the tarballs to the Github ones and update the d/watch 
accordingly. The point of this would be to be able to run the test suite.


Cheers,
Carl

Bug#850670: RFS: rpyc/3.3.0-1 [ITP]

[Carl Suster]

It's only because mentors doesn't support version=4.


That's right - I tested the watch files for all of my packages and they work 
fine locally.


For rpyc I chose GitHub rather than PyPI as the upstream tarball source since 
the former includes the tests and such, however there was a disagreement over 
the spelling of the version number for the current release. PyPI has 3.3.0 but 
GitHub has 3.3 - I added a uversionmange to turn version X.Y into X.Y.0 to 
normalise this since they normally use three components in the version string:


opts="filenamemangle=s/.+\/v?(\d\S*)\.tar\.gz/rpyc-$1\.tar\.gz/, \
uversionmangle=s/-[rR][cC]/~rc/; s/(^\d+\.\d+)([^.]*$)/$1.0$2/" \
  https://github.com/tomerfiliba/rpyc/releases .*/v?(\d\S*)\.tar\.gz debian 
uupdate


So the automatic d/watch template won't really work for this package anyway.

Cheers,
Carl

Bug#850670: RFS: rpyc/3.3.0-1 [ITP]

[Carl Suster]

Package: sponsorship-requests
Severity: wishlist
Control: block 850097 by -1

Dear mentors,

I am looking for a sponsor for my package "rpyc"

 Package name: rpyc
 Version : 3.3.0-1
 Upstream Author : Tomer Filiba 
 URL : https://github.com/tomerfiliba/rpyc
 License : MIT
 Section : python

I am packaging this as a dependency of flexget (ITP: #724718).

It builds these binary packages:

  python3-rpyc - transparent and symmetric Remote Python Call library -- 
Python3 module
  python3-rpyc-doc - transparent and symmetric Remote Python Call library -- 
documentation

To access further information about this package, please visit the following 
URL:

  https://mentors.debian.net/package/rpyc

Alternatively, one can download the package with dget using this command:

  dget -x https://mentors.debian.net/debian/pool/main/r/rpyc/rpyc_3.3.0-1.dsc

Cheers,
Carl

Bug#850664: RFS: python-pynzb/0.1.0-3

[Carl Suster]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "python-pynzb"

* Package name: python-pynzb
  Version : 0.1.0-3
* URL : https://github.com/ericflo/pynzb
* License : BSD-3-clause
  Section : python

I am interested in this package as a dependency for flexget (ITP: #724718).

The package has not received any attention from upstream, but it a very simple
set of wrappers for XML parsers to parse a simple XML format: NZB. For this
release I switch to building the Python 3 module which required the use of 2to3
in the build step. The Python 2 module can still be built fine, but I removed
it since there were no rdeps.

It builds these binary packages:

  python3-pynzb - unified API for parsing NZB files from NNTP (Usenet) servers

To access further information about this package, please visit the following 
URL:

  https://mentors.debian.net/package/python-pynzb

Alternatively, one can download the package with dget using this command:

  dget -x 
https://mentors.debian.net/debian/pool/main/p/python-pynzb/python-pynzb_0.1.0-3.dsc

Changes since the last upload:

python-pynzb (0.1.0-3) unstable; urgency=medium

  * Add myself to uploaders.
  * Switch to pybuild and dh-python.
  * Bump d/compat to 10.
  * Bump standards-version to 3.9.8 (no changes).
  * d/copyright: add myself and fix license short names
- "public domain" -> public-domain
- BSD -> BSD-3-clause.
  * Change Vcs to DPMT git repository and use https.
  * Change Homepage to GitHub.
  * Build the Python 3 module and drop the Python 2 module (no rdeps).
  * Run the test suite with pytest.
  * Call 2to3 during auto build.
  * 0001-set-message_id-properly-in-expat-parser.patch: fix an upstream code.
Tests pass for Python 2 with only this change.
  * Move lxml to Suggests since there are fallbacks, but Build-Depend on it to
run the tests.
  * For Python 3, decode strings -> bytes as utf-8 for lxml.
  * Fix watch file (although the last release was some time ago).

 -- Carl Suster <c...@contraflo.ws>  Mon, 09 Jan 2017 12:17:45 +1100


Cheers,
Carl

Bug#850607: RFS: flask-login/0.4.0-1 [ITA]

[Carl Suster]

Package: sponsorship-requests
Severity: normal
Control: block 836501 by -1

Dear mentors,

I am looking for a sponsor for my package "flask-login"

* Package name: flask-login
  Version : 0.4.0-1
* URL : https://github.com/maxcountryman/flask-login
* License : Expat
  Section : python

It builds these binary packages:

  python3-flask-login - user session management for Flask -- Python 3 module
  python3-flask-login-doc - user session management for Flask -- documentation

I am adopting this package in order to build the Python 3 module which is
a dependency of flexget (ITP: #724718) and has also been requested by multiple
people in #802614.

To be clear I am not targeting stretch even if that's somehow possible at this
stage. I have dropped the Python 2 module binary package since there were no
rdeps and my understanding is that going forward we don't want to keep around
unnecessary Python 2 packages.

To access further information about this package, please visit the following 
URL:

  https://mentors.debian.net/package/flask-login

Alternatively, one can download the package with dget using this command:

  dget -x 
https://mentors.debian.net/debian/pool/main/f/flask-login/flask-login_0.4.0-1.dsc

Changes since the last upload:

flask-login (0.4.0-1) experimental; urgency=medium

  * New upstream release.
  * New maintainer (Closes: #836501).
  * Update d/compat to 10.
  * Switch to using dh-python.
  * Relicense debian/* as Expat to match upstream.
  * Change d/watch to follow GitHub releases.
  * Change homepage to GitHub.
  * Build the Python 3 module (Closes: #802614).
  * Stop building the Python 2 module (no rdepends).
  * Move Vcs to DPMT git.
  * Bump standards version to 3.9.8 (no changes).
  * Build the documentation in a -doc package.
  * Add 0001-disable-github-fork-ribbon.patch to turn off the GitHub ribbon.
  * Run the test suite using upstream's makefile.

 -- Carl Suster <c...@contraflo.ws>  Sun, 08 Jan 2017 20:13:27 +1100

Cheers,
Carl

Bug#850589: yanc: Please build python3-nose-yanc

[Carl Suster]

Source: yanc
Version: 0.3.3-2
Severity: wishlist

Dear Maintainer,

Upstream yanc supports Python 3. Could you please consider building the Python
3 module in your package?

Cheers,
Carl

Bug#850089: #850089 ITP: flask-restplus - upstream version considerations

[Carl Suster]

This is wanted for flexget, which currently pins its dependency on 
flask-restplus==0.8.6. I have opened an upstream issue to ask that this be 
updated to the newest flask-restplus version 0.9.2:


  https://github.com/Flexget/Flexget/issues/1615

This will require some changes to flexget as it was patching some internal 
methods of flask-restplus which have changed.


If upstream does not want to change the dependency soon, then I will initially 
package flask-restplus at the older version 0.8.6 until I can work out how to 
help make the change with upstream.

Bug#850495: RFS: safe/0.4-1 [ITP]

[Carl Suster]

Package: sponsorship-requests
Severity: wishlist
Control: block #850088 by -1

Dear mentors,

I am looking for a sponsor for my package "safe"

* Package name: safe
  Version : 0.4
  Upstream Author : Hsiaoming Yang 
* URL : https://github.com/lepture/safe
* License : BSD
  Programming Lang: Python
  Description : password strength checking library for Python

I've packaged this because it is a dependency of flexget (ITP: #724718).

It builds those binary packages:

  python3-safe - password strength checking library for Python

To access further information about this package, please visit the following 
URL:

  https://mentors.debian.net/package/safe

Alternatively, one can download the package with dget using this command:

  dget -x https://mentors.debian.net/debian/pool/main/s/safe/safe_0.4-1.dsc


Cheers,
Carl

Bug#850487: RFS: terminaltables/3.1.0-1 [ITP]

[Carl Suster]

Package: sponsorship-requests
Severity: wishlist
Control: block #850093 by -1
Control: block -1 by #850412

Dear mentors,

I am looking for a sponsor for my package "terminaltables"

* Package name: terminaltables
  Version : 3.1.0-1
  Upstream Author : Robpol86 
* URL : https://github.com/Robpol86/terminaltables
* License : MIT
  Programming Lang: Python
  Description : Python library for printing tables to the console

I've packaged this because it is a dependency of flexget (ITP: #724718).
Note that this Build-Depends on colorclass (RFS: #850412) since it is used in
the test suite.

It builds those binary packages:

  python3-terminaltables - Python library for printing tables to the console
  python3-terminaltables-doc - Documentation for terminaltables table printer

To access further information about this package, please visit the following 
URL:

  https://mentors.debian.net/package/terminaltables

Alternatively, one can download the package with dget using this command:

  dget -x 
https://mentors.debian.net/debian/pool/main/t/terminaltables/terminaltables_3.1.0-1.dsc


Cheers,
Carl

Bug#850412: RFS: colorclass/2.2.0-1 [ITP]

[Carl Suster]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "colorclass"

* Package name: colorclass
  Version : 2.2.0-1
  Upstream Author : Robpol86 
* URL : https://github.com/Robpol86/colorclass
* License : MIT
  Programming Lang: Python
  Description : ANSI color text library for Python

I've packaged this because it is a dependency of flexget (ITP: #724718).

It builds these binary packages:

  python3-colorclass - ANSI color text library for Python

To access further information about this package, please visit the following 
URL:

  https://mentors.debian.net/package/colorclass

Alternatively, one can download the package with dget using this command:

  dget -x 
https://mentors.debian.net/debian/pool/main/c/colorclass/colorclass_2.2.0-1.dsc

Cheers,
Carl

Bug#724718: Dependency packaging for 2.8.15

[Carl Suster]

I have now more carefully investigated the dependencies and added blocking bugs:

REQUIREMENT   SRC PACKAGE  STATUS BUGS
--
Safe>=0.4 safe ITP#850088
colorclass>=2.2.0 colorclass   ITP#850087
flask-cors>=2.1.2 flask-cors   ITP#850091
flask-restplus==0.8.6 flask-restplus   ITP#850089
rpyc  rpyc ITP#850097
terminaltables>=3.1.0 terminaltables   ITP#850093
FeedParser>=5.2.1 feedparser   OUTDATED
cherrypy>=3.7.0   cherrypy3OUTDATED   #828942
subliminal >= 2.0rc1  subliminal   OUTDATED   #850098
vcrpy>=1.7.4  vcr.py   OUTDATED
flask-login>=0.4.0flask-login  PY2-ONLY   #802614
pynzb pynzbPY2-ONLY

Droppable dependencies: I think that coverage checks are not particularly 
relevant to the debian package, so I can avoid having to package 
codacy-coverage. Similarly, gitpython seems to only be used in a script to 
update the upstream changelog, so I can also omit that.


Pinned versions: Note that guessit and flask-restplus are pinned to old 
versions by upstream flexget. If flask-restplus can't be unpinned then I'll 
have to adjust the ITP to package the old version flexget wants. If guessit can 
be unpinned (which I suspect it can since the dependency conflict which cause 
the situation seems to have disappeared in new upstream guessit) then that will 
possibly also need to be updated before flexget can be packaged. See: 
https://requires.io/github/Flexget/Flexget/requirements/?branch=master


pynzb: Upstream seems abandoned as it hasn't been touched in 8 years. This is 
why it's a python2-only package. Only one flexget plugin needs this dependency 
so it could be reasonable to just patch that out for now to simplify things. 
Since pynzb is pretty small SLOC-wise it might be possible to eventually adopt 
it upstream or convince someone else to take over.


Since there is a lot of work to be done this could take me a while but I'll try 
not to let the effort lapse again! Hopefully I can get some help from the 
Python modules team.

Bug#850098: subliminal: please package new upstream version 2.0.x

[Carl Suster]

Source: subliminal
Severity: wishlist
Control: block 724718 by -1

The latest upstream version is currently 2.0.5. This request is to help with
the packaging of flexget (ITP: #724718) which depends on subliminal >=2.0rc1.

I would appreciate help packaging the new version of subliminal, but will get
around to it myself eventually within the DPMT once I deal with the other
dependencies.

Cheers,
Carl

Bug#850097: ITP: rpyc -- transparent and symmetric Remote Python Call library

[Carl Suster]

Package: wnpp
Severity: wishlist
Owner: Carl Suster <c...@contraflo.ws>
Control: block 724718 by -1

* Package name: rpyc
  Version : 3.3.0
  Upstream Author : Tomer Filiba <tomerfil...@gmail.com>
* URL : https://github.com/tomerfiliba/rpyc
* License : MIT
  Programming Lang: Python
  Description : transparent and symmetric Remote Python Call library

 RPyC (pronounced as are-pie-see), or Remote Python Call, is a transparent
 python library for symmetrical remote procedure calls, clustering and
 distributed-computing. RPyC makes use of object-proxying, a technique that
 employs python’s dynamic nature, to overcome the physical boundaries between
 processes and computers, so that remote objects can be manipulated as if they
 were local.

I intend to package this within in Python modules team and look for a sponsor
there. It is a dependency of flexget (ITP: #724718).

Bug#850093: ITP: terminaltables -- Python library for printing tables to the console

[Carl Suster]

Package: wnpp
Severity: wishlist
Owner: Carl Suster <c...@contraflo.ws>
Control: block 724718 by -1

* Package name: terminaltables
  Version : 3.1.0
  Upstream Author : Robpol86 <robpo...@gmail.com>
* URL : https://github.com/Robpol86/terminaltables
* License : MIT
  Programming Lang: Python
  Description : Python library for printing tables to the console

 Easily draw tables in terminal/console applications from a list of lists of
 strings.
 .
 Supports: multi-line rows, table titles, POSIX and Windows, Wide CJK
 (Chinese/Japanese/Korean) characters are displayed correctly, RTL Arabic and
 Hebrew characters are aligned correctly, alignment and justification.
 Colored text is supported thrugh colorclass, colorama, termcolor, or just
 plain ANSI escape codes.

I intend to package this within in Python modules team and look for a sponsor
there. It is a dependency of flexget (ITP: #724718).

Bug#850091: ITP: flask-cors -- Flask extension for handling Cross Origin Resource Sharing (CORS) in Python web apps

[Carl Suster]

Package: wnpp
Severity: wishlist
Owner: Carl Suster <c...@contraflo.ws>
Control: block 724718 by -1

* Package name: flask-cors
  Version : 3.0.2
  Upstream Author : Cory Dolphin <corydolp...@gmail.com>
* URL : https://github.com/corydolphin/flask-cors
* License : MIT
  Programming Lang: Python
  Description : Flask extension for handling Cross Origin Resource Sharing 
(CORS) in Python web apps

 This package has a simple philosophy, when you want to enable CORS, you wish
 to enable it for all use cases on a domain. This means no mucking around with
 different allowed headers, methods, etc. By default, submission of cookies
 across domains is disabled due to the security implications, please see the
 documentation for how to enable credentialed requests, and please make sure
 you add some sort of CRSF protection before doing so!

I intend to package this within in Python modules team and look for a sponsor
there. It is a dependency of flexget (ITP: #724718).

Bug#850089: ITP: flask-restplus -- Flask extension for building REST APIs in Python web apps

[Carl Suster]

Package: wnpp
Severity: wishlist
Owner: Carl Suster <c...@contraflo.ws>
Control: block 724718 by -1

* Package name: flask-restplus
  Version : 0.9.2
  Upstream Author : Axel Haustant <a...@haustant.fr>
* URL : https://github.com/noirbizarre/flask-restplus
* License : MIT
  Programming Lang: Python
  Description : Flask extension for building REST APIs in Python web apps

Flask-RESTPlus is an extension for Flask that adds support for quickly building
REST APIs. Flask-RESTPlus encourages best practices with minimal setup. If you
are familiar with Flask, Flask-RESTPlus should be easy to pick up. It provides
a coherent collection of decorators and tools to describe your API and expose
its documentation properly using Swagger.

I intend to package this within in Python modules team and look for a sponsor
there. It is a dependency of flexget (ITP: #724718).

Bug#850088: ITP: safe -- password strength checking library for Python

[Carl Suster]

Package: wnpp
Severity: wishlist
Owner: Carl Suster <c...@contraflo.ws>
Control: block 724718 by -1

* Package name: safe
  Version : 0.4
  Upstream Author : Hsiaoming Yang <m...@lepture.com>
* URL : https://github.com/lepture/safe
* License : BSD
  Programming Lang: Python
  Description : password strength checking library for Python

 Safe provides a small library to check a proposed password against some
 obviously insecure patterns, and also against a dictionary of 10k common
 passwords. It also checks for the presence of mixed case characters, numbers
 and symbols. Usage is as simple as:
 .
 import safe
 strength = safe.check('x*V-92Ba')
 strength.strength #=> 'strong'
 bool(strength)#=> True

I intend to package this within in Python modules team and look for a sponsor
there. It is a dependency of flexget (ITP: #724718).

Bug#850087: ITP: colorclass -- ANSI color text library for Python

[Carl Suster]

Package: wnpp
Severity: wishlist
Owner: Carl Suster <c...@contraflo.ws>
Control: block 724718 by -1

* Package name: colorclass
  Version : 2.2.0
  Upstream Author : Robpol86 <robpo...@gmail.com>
* URL : https://github.com/Robpol86/colorclass
* License : MIT
  Programming Lang: Python
  Description : ANSI color text library for Python

 Yet another ANSI color text library for Python. Provides "auto colors" for
 dark/light terminals. Works on Linux, OS X, and Windows.
 .
 In Python 2 this library subclasses unicode, while on Python 3 it subclasses
 str. Different colors are chosen using curly-bracket tags, such as
 {red}{/red}. For a list of available colors, call colorclass.list_tags().
 Auto colors are toggled by calling set_light_background() and
 set_dark_background().

I intend to package this within in Python modules team and look for a sponsor
there. It is a dependency of flexget (ITP: #724718).