Bug#939188: grub-PC check_signatures=enforce support (non-EFI)

[Patrick Schleizer]

Package: grub2
Severity: wishlist
X-Debbugs-CC: whonix-de...@whonix.org

Could you please make it possible to do signature verification with
grub-pc too?

Rationale:

We, the maintainers of Linux distributions that primarily run inside VMs
(Whonix; Kicksecure) would like to implement verified boot. Not
necessarily Secure Boot.

At the moment, there are no tools that can create VM images (with Debian
Linux) which support EFI booting. Also, support by virtualizers such as
KVM, Xen, VirtualBox for Secure Boot is either non-existing or undocumented.

Another reason is, that inside VMs we don’t necessarily need the
complexity of EFI.

Instead we could boot unverified (usual virtual BIOS legacy boot) from a
virtual, read-only (write protected) boot medium (such as ISO). That
boot loader on the initial boot disk (grub2) could then verify and
chainload the boot loader (grub2) on the main disk. Which then would go
on to verify the kernel. In result, we would have a verified boot sequence.

Bug#934948: Unnecessary dependencies vs multiple binary packages

[Pirate Praveen]

On Sat, 24 Aug 2019 02:40:29 -0400 Scott Kitterman  wrote:
> Unless someone can figure out an actual resolvable controversy, I don't seen 
> any point in bothering other FTP team members with this. To the extent 
> anything is being requested, it seems like it's infeasible (write down exact 
> rules for what too small to split into multiple binaries would be and then 
> have all FTP team members apply the standard perfectly).

I don't think ruby-task-list was rejected because the new binary was small. In 
the reject mail it was already acknowledged.

"While the (compiled) javascript part is quite large (8k), this split is only 
done to save one dependency (either ruby or nodejs) from being installed. We've 
talked about this."

ruby-task-list depends on not just ruby,

ruby | ruby-interpreter, ruby-rack, ruby-activesupport, ruby-html-pipeline

So if I remove these dependencies from ruby-task-list, then every package 
depending on ruby-task-list will have to add these dependencies themselves.

I don't think its reasonable to expect every package depending on 
ruby-task-list to already depend on these packages too.

My contention is that ruby-task-list case is not same as node-autoprefixer  and 
it should be allowed to create two separate binary packages targeting ruby and 
nodejs environments.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Bug#934948: Unnecessary dependencies vs multiple binary packages

[Pirate Praveen]

On Mon, 26 Aug 2019 13:55:11 +0100 Simon McVittie  wrote:
> That doesn't answer my question.
> 
> I looked at this executable again and it seems as though its purpose is
> to query metadata about the autoprefixer nodejs library, analogous to
> the -config programs sometimes found in -dev packages (sdl2-config and
> so on). Is that correct?
> 
> Is it run automatically by some piece of Node infrastructure (like the
> way the build systems of some SDL games automatically run sdl2-config
> to learn which compiler and linker options they should use for SDL),
> or is it intended to be run manually by a developer, or what?
> 
> Is there any situation in which it would be run by a developer who does
> not already know that they have nodejs installed?

Since this package is already in the archive I'd like to focus on 
ruby-task-list only and reopen the discussion when another package fits the 
general question.

> > So in general there is two cases I want to be able to create multiple 
> > binaries.
> > 
> > 1. Cases like node-autoprefixer if the executable is useful (in specific 
> > case of node-autoprefixer , I can live without the executable for now).
> > 2. Cases like ruby-task-list where there is more dependencies than the 
> > interpreter.
> 
> I think these are different, and each should be considered on its own
> merits, so this bug might make more sense if it is cloned (split) to offer
> advice on the two different situations.

As said above, I'd like to drop node-autoprefixer  case from this discussion. 
It was mainly brought as a reference to ruby-task-list list rejection and from 
(my understanding of) ftp master position that both cases are similar.

> For the node-autoprefixer case, if we decide that the executable is not
> sufficiently important to the overall function of the package to merit a
> dependency, it's probably useful to compare and contrast with cleancss.deb
> from the node-clean-css source package (which *is* a separate binary
> package, and it looks to me as though that was the correct decision).

So can we focus on ruby-task-list case for this bug?

> smcv
> 
> 

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Bug#939187: bind9: Bind cache directory owned by root, not writable by bind user

[Steve Garcia]

Package: bind9
Version: 1:9.11.5.P4+dfsg-5.1
Severity: normal

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

This is a bug in the installation script of the bind9 package.

   * What led up to the situation?

I run bind as the bind user.  Upon a new install, using my previous
server's config files, I was unable to successfully start the daemon.
The error message cited an inability to write a file to /var/cache/bind.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

I changed the ownership of /var/cach/bind to bind:bind.  As installed it
was owned by root:root.  The package installation script needs to set the 
ownership to bind:bind.


   * What was the outcome of this action?

The daemon started successfully.

   * What outcome did you expect instead?

*** End of the template - remove these template lines ***


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

Kernel: Linux 4.19.0-5-amd64 (SMP w/1 CPU core)
Kernel taint flags: TAINT_CRAP
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages bind9 depends on:
ii  adduser3.118
ii  bind9utils 1:9.11.5.P4+dfsg-5.1
ii  debconf [debconf-2.0]  1.5.71
ii  dns-root-data  2019031302
ii  libbind9-161   1:9.11.5.P4+dfsg-5.1
ii  libc6  2.28-10
ii  libcap21:2.25-2
ii  libcom-err21.44.5-1
ii  libdns1104 1:9.11.5.P4+dfsg-5.1
ii  libfstrm0  0.4.0-1
ii  libgeoip1  1.6.12-1
ii  libgssapi-krb5-2   1.17-3
ii  libisc1100 1:9.11.5.P4+dfsg-5.1
ii  libisccc1611:9.11.5.P4+dfsg-5.1
ii  libisccfg163   1:9.11.5.P4+dfsg-5.1
ii  libjson-c3 0.12.1+ds-2
ii  libk5crypto3   1.17-3
ii  libkrb5-3  1.17-3
ii  liblmdb0   0.9.22-1
ii  liblwres1611:9.11.5.P4+dfsg-5.1
ii  libprotobuf-c1 1.3.1-1+b1
ii  libssl1.1  1.1.1c-1
ii  libxml22.9.4+dfsg1-7+b3
ii  lsb-base   10.2019051400
ii  net-tools  1.60+git20180626.aebd88e-1
ii  netbase5.6

bind9 recommends no packages.

Versions of packages bind9 suggests:
pn  bind9-doc   
pn  dnsutils
pn  resolvconf  
pn  ufw 

-- Configuration Files:
/etc/bind/named.conf.local changed:
//
// Do any local configuration here
//
zone "bgnet" IN {
type master;
file "/etc/bind/named.bgnet";
};
zone "7.7.10.in-addr.arpa" IN {
type master;
file "/etc/bind/named.rev.10.7.7";
};
// Consider adding the 1918 zones here, if they are not used in your
// organization
//include "/etc/bind/zones.rfc1918";


-- debconf information:
  bind9/different-configuration-file:
  bind9/start-as-user: bind
  bind9/run-resolvconf: false

Bug#445636:

[MAH Alli]

Bug#934206: buster-pu: package golang-github-docker-docker-credential-helpers/0.6.1-2+deb10u1

[Arnaud Rebillout]

On 8/23/19 9:54 AM, Adam D. Barratt wrote:

On 2019-08-18 15:41, Arnaud Rebillout wrote:

On 8/16/19 9:35 PM, Adam D. Barratt wrote:

So is the conclusion there that docker.io is or is not actually
affected?



Yes docker.io is affected as well.


Which of the binary packages are affected and need rebuilding? The 
packages produced are:


docker-doc  | 18.09.1+dfsg1-7.1 | stable | all
docker.io   | 18.09.1+dfsg1-7.1 | stable | 
source, amd64, arm64, armel, armhf, i386, ppc64el, s390x

golang-docker-dev   | 18.09.1+dfsg1-7.1 | stable | all
golang-github-docker-docker-dev | 18.09.1+dfsg1-7.1 | stable | all
vim-syntax-docker   | 18.09.1+dfsg1-7.1 | stable | all

If the answer is anything other than "just the docker.io binary 
package", then this will need to be a separate source upload, as we 
can't binNMU arch:all packages.



Only docker.io needs rebuild

Bug#931566: Don't complain about suite changes (Acquire::AllowReleaseInfoChange::Suite should be "true")

[Paul Wise]

On Sun, 7 Jul 2019 20:39:10 +0200 Christoph Berg wrote:

> I and #debian-devel in general were pretty surprised that our "buster"
> systems couldn't properly "apt-get update" anymore today:

I recently had a similar issue with the backports repos:

E: Repository 'https://incoming.debian.org/debian-buildd 
buildd-stretch-backports-sloppy InRelease' changed its default priority for 
apt_preferences(5) from 500 to 100.
E: Repository 'https://cdn-aws.deb.debian.org/debian stretch-backports-sloppy 
InRelease' changed its default priority for apt_preferences(5) from 500 to 100.

This was because those suites got a couple of settings added to their
Release files in the apt repository:

NotAutomatic: yes
ButAutomaticUpgrades: yes

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Bug#939186: HVM + Balloon crashes Xen hypervisor

[Elliott Mitchell]

Package: xen-hypervisor-4.8-amd64
Version: 4.8.5+shim4.10.2+xsa282-1+deb9u11

Trying to create a HVM domain with memory != maxmem reliably crashes
Debian's build of Xen 4.8.  This may be a nonsensical configuration, but
it still shouldn't cause everything, including the hypervisor to crash.

I recall running into this with 4.4 as well.


-- 
(\___(\___(\__  --=> 8-) EHM <=--  __/)___/)___/)
 \BS (| ehem+sig...@m5p.com  PGP 87145445 |)   /
  \_CS\   |  _  -O #include  O-   _  |   /  _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445

Bug#939185: pytimechart: Python2 removal in sid/bullseye

[Scott Talbert]

Package: src:pytimechart
Version:  1.0.0~rc1-3.3
Severity: normal
Tags: sid bullseye
User: debian-pyt...@lists.debian.org
Usertags: py2removal

Python2 becomes end-of-live upstream, and Debian aims to remove
Python2 from the distribution, as discussed in
https://lists.debian.org/debian-python/2019/07/msg00080.html

Your package either build-depends, depends on Python2, or uses Python2
in the autopkg tests.  Please stop using Python2, and fix this issue
by one of the following actions.

- Convert your Package to Python3. This is the preferred option.  In
  case you are providing a Python module foo, please consider dropping
  the python-foo package, and only build a python3-foo package.  Please
  don't drop Python2 modules, which still have reverse dependencies,
  just document them.

  This is the preferred option.

- If the package is dead upstream, cannot be converted or maintained
  in Debian, it should be removed from the distribution.  If the
  package still has reverse dependencies, raise the severity to
  "serious" and document the reverse dependencies with the BTS affects
  command.  If the package has no reverse dependencies, confirm that
  the package can be removed, reassign this issue to ftp.debian.org,
  make sure that the bug priority is set to normal and retitle the
  issue to "RM: PKG -- removal triggered by the Python2 removal".

- If the package has still many users (popcon >= 300), or is needed to
  build another package which cannot be removed, document that by
  adding the "py2keep" user tag (not replacing the py2remove tag),
  using the debian-pyt...@lists.debian.org user.  Also any
  dependencies on an unversioned python package (python, python-dev)
  must not be used, same with the python shebang.  These have to be
  replaced by python2/python2.7 dependencies and shebang.

  This is the least preferred option.

If the conversion or removal needs action on another package first,
please document the blocking by using the BTS affects command, like

  affects  + src:pytimechart

If there is no py2removal bug for that reverse-dependency, please file
a bug on this package (similar to this bug report).

If there are questions, please refer to the wiki page for the removal:
https://wiki.debian.org/Python/2Removal, or ask for help on IRC
#debian-python, or the debian-pyt...@lists.debian.org mailing list.

Bug#939184: paprass: Python2 removal in sid/bullseye

[Scott Talbert]

Package: src:paprass
Version: 2.06-2
Severity: normal
Tags: sid bullseye
User: debian-pyt...@lists.debian.org
Usertags: py2removal

Python2 becomes end-of-live upstream, and Debian aims to remove
Python2 from the distribution, as discussed in
https://lists.debian.org/debian-python/2019/07/msg00080.html

Your package either build-depends, depends on Python2, or uses Python2
in the autopkg tests.  Please stop using Python2, and fix this issue
by one of the following actions.

- Convert your Package to Python3. This is the preferred option.  In
  case you are providing a Python module foo, please consider dropping
  the python-foo package, and only build a python3-foo package.  Please
  don't drop Python2 modules, which still have reverse dependencies,
  just document them.

  This is the preferred option.

- If the package is dead upstream, cannot be converted or maintained
  in Debian, it should be removed from the distribution.  If the
  package still has reverse dependencies, raise the severity to
  "serious" and document the reverse dependencies with the BTS affects
  command.  If the package has no reverse dependencies, confirm that
  the package can be removed, reassign this issue to ftp.debian.org,
  make sure that the bug priority is set to normal and retitle the
  issue to "RM: PKG -- removal triggered by the Python2 removal".

- If the package has still many users (popcon >= 300), or is needed to
  build another package which cannot be removed, document that by
  adding the "py2keep" user tag (not replacing the py2remove tag),
  using the debian-pyt...@lists.debian.org user.  Also any
  dependencies on an unversioned python package (python, python-dev)
  must not be used, same with the python shebang.  These have to be
  replaced by python2/python2.7 dependencies and shebang.

  This is the least preferred option.

If the conversion or removal needs action on another package first,
please document the blocking by using the BTS affects command, like

  affects  + src:paprass

If there is no py2removal bug for that reverse-dependency, please file
a bug on this package (similar to this bug report).

If there are questions, please refer to the wiki page for the removal:
https://wiki.debian.org/Python/2Removal, or ask for help on IRC
#debian-python, or the debian-pyt...@lists.debian.org mailing list.

Bug#939182: drpython: Python2 removal in sid/bullseye

[Scott Talbert]

Package: src:drpython
Version:  1:3.11.4-1.1
Severity: normal
Tags: sid bullseye
User: debian-pyt...@lists.debian.org
Usertags: py2removal

Python2 becomes end-of-live upstream, and Debian aims to remove
Python2 from the distribution, as discussed in
https://lists.debian.org/debian-python/2019/07/msg00080.html

Your package either build-depends, depends on Python2, or uses Python2
in the autopkg tests.  Please stop using Python2, and fix this issue
by one of the following actions.

- Convert your Package to Python3. This is the preferred option.  In
  case you are providing a Python module foo, please consider dropping
  the python-foo package, and only build a python3-foo package.  Please
  don't drop Python2 modules, which still have reverse dependencies,
  just document them.

  This is the preferred option.

- If the package is dead upstream, cannot be converted or maintained
  in Debian, it should be removed from the distribution.  If the
  package still has reverse dependencies, raise the severity to
  "serious" and document the reverse dependencies with the BTS affects
  command.  If the package has no reverse dependencies, confirm that
  the package can be removed, reassign this issue to ftp.debian.org,
  make sure that the bug priority is set to normal and retitle the
  issue to "RM: PKG -- removal triggered by the Python2 removal".

- If the package has still many users (popcon >= 300), or is needed to
  build another package which cannot be removed, document that by
  adding the "py2keep" user tag (not replacing the py2remove tag),
  using the debian-pyt...@lists.debian.org user.  Also any
  dependencies on an unversioned python package (python, python-dev)
  must not be used, same with the python shebang.  These have to be
  replaced by python2/python2.7 dependencies and shebang.

  This is the least preferred option.

If the conversion or removal needs action on another package first,
please document the blocking by using the BTS affects command, like

  affects  + src:drpython

If there is no py2removal bug for that reverse-dependency, please file
a bug on this package (similar to this bug report).

If there are questions, please refer to the wiki page for the removal:
https://wiki.debian.org/Python/2Removal, or ask for help on IRC
#debian-python, or the debian-pyt...@lists.debian.org mailing list.

Bug#939183: openstv: Python2 removal in sid/bullseye

[Scott Talbert]

Package: src:openstv
Version: 1.6.1-1.2
Severity: normal
Tags: sid bullseye
User: debian-pyt...@lists.debian.org
Usertags: py2removal

Python2 becomes end-of-live upstream, and Debian aims to remove
Python2 from the distribution, as discussed in
https://lists.debian.org/debian-python/2019/07/msg00080.html

Your package either build-depends, depends on Python2, or uses Python2
in the autopkg tests.  Please stop using Python2, and fix this issue
by one of the following actions.

- Convert your Package to Python3. This is the preferred option.  In
  case you are providing a Python module foo, please consider dropping
  the python-foo package, and only build a python3-foo package.  Please
  don't drop Python2 modules, which still have reverse dependencies,
  just document them.

  This is the preferred option.

- If the package is dead upstream, cannot be converted or maintained
  in Debian, it should be removed from the distribution.  If the
  package still has reverse dependencies, raise the severity to
  "serious" and document the reverse dependencies with the BTS affects
  command.  If the package has no reverse dependencies, confirm that
  the package can be removed, reassign this issue to ftp.debian.org,
  make sure that the bug priority is set to normal and retitle the
  issue to "RM: PKG -- removal triggered by the Python2 removal".

- If the package has still many users (popcon >= 300), or is needed to
  build another package which cannot be removed, document that by
  adding the "py2keep" user tag (not replacing the py2remove tag),
  using the debian-pyt...@lists.debian.org user.  Also any
  dependencies on an unversioned python package (python, python-dev)
  must not be used, same with the python shebang.  These have to be
  replaced by python2/python2.7 dependencies and shebang.

  This is the least preferred option.

If the conversion or removal needs action on another package first,
please document the blocking by using the BTS affects command, like

  affects  + src:openstv

If there is no py2removal bug for that reverse-dependency, please file
a bug on this package (similar to this bug report).

If there are questions, please refer to the wiki page for the removal:
https://wiki.debian.org/Python/2Removal, or ask for help on IRC
#debian-python, or the debian-pyt...@lists.debian.org mailing list.

Bug#939181: cycle: Python2 removal in sid/bullseye

[Scott Talbert]

Package: src:cycle
Version: 0.3.1-14
Severity: normal
Tags: sid bullseye
User: debian-pyt...@lists.debian.org
Usertags: py2removal

Python2 becomes end-of-live upstream, and Debian aims to remove
Python2 from the distribution, as discussed in
https://lists.debian.org/debian-python/2019/07/msg00080.html

Your package either build-depends, depends on Python2, or uses Python2
in the autopkg tests.  Please stop using Python2, and fix this issue
by one of the following actions.

- Convert your Package to Python3. This is the preferred option.  In
  case you are providing a Python module foo, please consider dropping
  the python-foo package, and only build a python3-foo package.  Please
  don't drop Python2 modules, which still have reverse dependencies,
  just document them.

  This is the preferred option.

- If the package is dead upstream, cannot be converted or maintained
  in Debian, it should be removed from the distribution.  If the
  package still has reverse dependencies, raise the severity to
  "serious" and document the reverse dependencies with the BTS affects
  command.  If the package has no reverse dependencies, confirm that
  the package can be removed, reassign this issue to ftp.debian.org,
  make sure that the bug priority is set to normal and retitle the
  issue to "RM: PKG -- removal triggered by the Python2 removal".

- If the package has still many users (popcon >= 300), or is needed to
  build another package which cannot be removed, document that by
  adding the "py2keep" user tag (not replacing the py2remove tag),
  using the debian-pyt...@lists.debian.org user.  Also any
  dependencies on an unversioned python package (python, python-dev)
  must not be used, same with the python shebang.  These have to be
  replaced by python2/python2.7 dependencies and shebang.

  This is the least preferred option.

If the conversion or removal needs action on another package first,
please document the blocking by using the BTS affects command, like

  affects  + src:cycle

If there is no py2removal bug for that reverse-dependency, please file
a bug on this package (similar to this bug report).

If there are questions, please refer to the wiki page for the removal:
https://wiki.debian.org/Python/2Removal, or ask for help on IRC
#debian-python, or the debian-pyt...@lists.debian.org mailing list.

Bug#939180: bittornado: Python2 removal in sid/bullseye

[Scott Talbert]

Package: src:bittornado
Version: 0.3.18-10.3
Severity: normal
Tags: sid bullseye
User: debian-pyt...@lists.debian.org
Usertags: py2removal

Python2 becomes end-of-live upstream, and Debian aims to remove
Python2 from the distribution, as discussed in
https://lists.debian.org/debian-python/2019/07/msg00080.html

Your package either build-depends, depends on Python2, or uses Python2
in the autopkg tests.  Please stop using Python2, and fix this issue
by one of the following actions.

- Convert your Package to Python3. This is the preferred option.  In
  case you are providing a Python module foo, please consider dropping
  the python-foo package, and only build a python3-foo package.  Please
  don't drop Python2 modules, which still have reverse dependencies,
  just document them.

  This is the preferred option.

- If the package is dead upstream, cannot be converted or maintained
  in Debian, it should be removed from the distribution.  If the
  package still has reverse dependencies, raise the severity to
  "serious" and document the reverse dependencies with the BTS affects
  command.  If the package has no reverse dependencies, confirm that
  the package can be removed, reassign this issue to ftp.debian.org,
  make sure that the bug priority is set to normal and retitle the
  issue to "RM: PKG -- removal triggered by the Python2 removal".

- If the package has still many users (popcon >= 300), or is needed to
  build another package which cannot be removed, document that by
  adding the "py2keep" user tag (not replacing the py2remove tag),
  using the debian-pyt...@lists.debian.org user.  Also any
  dependencies on an unversioned python package (python, python-dev)
  must not be used, same with the python shebang.  These have to be
  replaced by python2/python2.7 dependencies and shebang.

  This is the least preferred option.

If the conversion or removal needs action on another package first,
please document the blocking by using the BTS affects command, like

  affects  + src:bittornado

If there is no py2removal bug for that reverse-dependency, please file
a bug on this package (similar to this bug report).

If there are questions, please refer to the wiki page for the removal:
https://wiki.debian.org/Python/2Removal, or ask for help on IRC
#debian-python, or the debian-pyt...@lists.debian.org mailing list.

Bug#939179: bibus: Python2 removal in sid/bullseye

[Scott Talbert]

Package: src:bibus
Version: 1.5.2+dfsg-1
Severity: normal
Tags: sid bullseye
User: debian-pyt...@lists.debian.org
Usertags: py2removal

Python2 becomes end-of-live upstream, and Debian aims to remove
Python2 from the distribution, as discussed in
https://lists.debian.org/debian-python/2019/07/msg00080.html

Your package either build-depends, depends on Python2, or uses Python2
in the autopkg tests.  Please stop using Python2, and fix this issue
by one of the following actions.

- Convert your Package to Python3. This is the preferred option.  In
  case you are providing a Python module foo, please consider dropping
  the python-foo package, and only build a python3-foo package.  Please
  don't drop Python2 modules, which still have reverse dependencies,
  just document them.

  This is the preferred option.

- If the package is dead upstream, cannot be converted or maintained
  in Debian, it should be removed from the distribution.  If the
  package still has reverse dependencies, raise the severity to
  "serious" and document the reverse dependencies with the BTS affects
  command.  If the package has no reverse dependencies, confirm that
  the package can be removed, reassign this issue to ftp.debian.org,
  make sure that the bug priority is set to normal and retitle the
  issue to "RM: PKG -- removal triggered by the Python2 removal".

- If the package has still many users (popcon >= 300), or is needed to
  build another package which cannot be removed, document that by
  adding the "py2keep" user tag (not replacing the py2remove tag),
  using the debian-pyt...@lists.debian.org user.  Also any
  dependencies on an unversioned python package (python, python-dev)
  must not be used, same with the python shebang.  These have to be
  replaced by python2/python2.7 dependencies and shebang.

  This is the least preferred option.

If the conversion or removal needs action on another package first,
please document the blocking by using the BTS affects command, like

  affects  + src:bibus

If there is no py2removal bug for that reverse-dependency, please file
a bug on this package (similar to this bug report).

If there are questions, please refer to the wiki page for the removal:
https://wiki.debian.org/Python/2Removal, or ask for help on IRC
#debian-python, or the debian-pyt...@lists.debian.org mailing list.

Bug#933857: solr-jetty: Jetty lacks necessary write permissions to /var/lib/solr/data/index/

[J.P. Larocque]

stephan, thanks for tracking this down.  I almost figured it out, and
then I found that you already reported this bug.  Your other bug
report was also super helpful for me to get Solr working after my
upgrade to Buster.

On Sun, Aug 04, 2019 at 03:31:52PM +0200, beirer wrote:
> The fix is also similar:
> 
> Copy /lib/systemd/system/jetty9.service to /etc/systemd/system and modify
> it by adding
> 
> ReadWritePaths=/var/lib/solr/data
> 
> to the # Security paragraph.

I found that adding a file
/etc/systemd/system/jetty9.service.d/override.conf (and making its
parent directory, both via `systemctl edit jetty9`) with these
contents allowed me to append to the ReadWritePaths list, overriding
just the right part to get Solr to work under Jetty:

-
[Service]
ReadWritePaths=/var/lib/solr/data/
-

Debian Java Maintainers, is there a sensible way to ship a systemd
override file like this with solr-jetty?  (The right path for such a
packaged override file might be under /lib/systemd/ somewhere, because
I think /etc/systemd/ is reserved for user-made customizations.)

-- 
J.P. Larocque 

Bug#929829: [Pkg-javascript-devel] Bug#929829: Bug#929829: Bug#929829: gulp 4 cannot build node-babel 7 - Cannot convert undefined or null to object

[Pirate Praveen]

On 2019, സെപ്റ്റംബർ 1 10:13:24 PM IST, Pirate Praveen 
 wrote:
>
>
>On Sun, Sep 1, 2019 at 9:15 PM, Pirate Praveen 
> wrote:
>> And fancy-log package.json wants chalk ^1.1.1 and we have chalk 2.4.2
>
>> which to me looks like a possible culprit.
>
>This was a false positive, I suspect 
>debian/patches/update-process-nextick-args.patch is not correct.

This is also false. I replaced async-done patch with upstream 1.3.2 release, 
but it still fails with same error message.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Bug#939178: release-notes: Describe name selection rules in the "Migrating from legacy network interface names" section

[Dmitry Semyonov]

Package: release-notes
Severity: important

The 5.1.5 section of the document[1] contains the following text:
[1]https://www.debian.org/releases/stable/amd64/release-notes/ch-information.en.html#migrate-interface-names

"(If the udevadm output includes an “onboard” name, that takes priority;
MAC-based names are normally treated as a fallback, but may be needed
for USB network hardware.)"

This text should be changed to something like this:

udevadm may list several potential names for a single interface. In this
case the final name is assigned according to the following list of
decreasing priorities:
 * ID_NET_NAME_FROM_DATABASE
 * ID_NET_NAME_ONBOARD
 * ID_NET_NAME_SLOT
 * ID_NET_NAME_PATH
 * ID_NET_NAME_MAC

(MAC-based names are normally used only for USB network hardware.)

It is important to make the right choice when migrating interface names
on a remote system!

-- 
...Bye..Dmitry.

Bug#939177: reportbug: With "outfile" rc option, text file does not start with Package line

[scott092707]

Package: reportbug
Version: 7.5.2
Severity: normal

Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: Scott Jacobs 
To: Debian Bug Tracking System 
Subject: reportbug: With "outfile" rc option, text file does not start with 
Package line
Bcc: Scott Jacobs 
Message-ID: 
<156739111211.4384.421396814260056422.reportbug@ASUS-PRIME-B350M-A-CSM>
X-Mailer: reportbug 7.5.2
Date: Sun, 01 Sep 2019 22:25:12 -0400
X-Debbugs-Cc: scott092...@aol.com

Dear Maintainer,

I run reportbug with the "outfile" option - that is, I don't have reportbug
SEND the bug report, just write the information to a text file that I then
cut/paste into the Compose field of my browser's email site.

Despite that fact that the BRS insists on the Package: line being the first
line of the bug report, it is NOT the first line of the text file - it is
preceded by 11 other lines, plus a blank line.

Each bug I submit must be edited, to move those 12 lines to after the Package
line (actually, I move it to below the Version: and bug Severity: lines + a
blank line...) before I can send the email, and have it accepted by the BRS.



-- Package-specific info:
** Environment settings:
INTERFACE="gtk"

** /home/scott/.reportbugrc:
reportbug_version "7.5.2"
mode standard
ui gtk
email "scott092...@aol.com"
list-cc-me
submit
smtphost reportbug.debian.org
query-bts
config-files
verify
outfile '~/reportbug_report.txt'
check-available
latest-first

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

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

Versions of packages reportbug depends on:
ii  apt1.8.2
ii  python33.7.3-1
ii  python3-reportbug  7.5.2
ii  sensible-utils 0.0.12

reportbug recommends no packages.

Versions of packages reportbug suggests:
pn  claws-mail 
pn  debconf-utils  
pn  debsums
pn  dlocate
pn  emacs24-bin-common | emacs25-bin-common
ii  exim4-daemon-light [mail-transport-agent]  4.92-8
ii  file   1:5.35-4
ii  gnupg  2.2.12-1
pn  python3-urwid  
ii  reportbug-gtk  7.5.2
ii  xdg-utils  1.1.3-1

Versions of packages python3-reportbug depends on:
ii  apt1.8.2
ii  file   1:5.35-4
ii  python33.7.3-1
ii  python3-apt1.8.4
ii  python3-debian 0.1.35
ii  python3-debianbts  2.8.2
ii  python3-requests   2.21.0-1

python3-reportbug suggests no packages.

-- no debconf information

Bug#825809: unclutter: diff for NMU version 8-21.1

[Sean Whitton]

Hello Axel,

On Sun 01 Sep 2019 at 08:54PM +02, Axel Beckert wrote:

> Sean Whitton wrote:
>> I've prepared an NMU for unclutter (versioned as 8-21.1) and uploaded it
>> to DELAYED/15. Please feel free to tell me if I should delay it longer.
>
> Yes, please remove it completely. It is incomplete and has unsolved
> issues which might be even harder to fix properly afterwards if the
> upload succeeds.

Done, quite gladly.  I decide whether to NMU based on activity in the
bugs to be closed by the NMU, not on how active a maintainer is in
general, since people who are active often don't have time for all of
their packages.  Anyway, I hope that no annoyance was generated.

> I'll try to upload unclutter 8-22 (to experimental) before that NMU
> passes throught, but for that, I need your feedback first:
>
> Please check the master branch under
> https://salsa.debian.org/debian/unclutter and especially the commits I
> made after applying your NMU patch minus the unnecessary NMU stuff:
>
> https://salsa.debian.org/debian/unclutter/commits/master
>
> Main points:
>
> * Make /etc/X11/Xsession.d/90unclutter a slave alternative, too.
> * Rename /etc/default/unclutter to /etc/default/unclutter-classic.
> * Make debian/unclutter.install executable. (Might have been lost when
>   you generated your patch as it clearly FTBFS else.)

Yeah, nmudiffs can't record mode changes.  It was executable in the
source package I uploaded, though.

> I'd appreciate if you could look over these changes and tell me if you
> agree (as we both should agree on at least the list of slave
> alternatives), have alternative suggestions or otherwise comments.

I thought about the issue of the Xsession.d file and
/etc/default/unclutter, and concluded that it could stay in
src:unclutter only.  My thought was that most contemporary users of
unclutter-xfixes will probably expect to have to start the program
themselves, e.g. in ~/.config/i3/config.  I was certainly surprised when
I first installed unclutter, rebooted for whatever reason and discovered
it had started itself.

Someone who *does* want to keep using the Xsession.d file with
unclutter-xfixes can just install both unclutter and unclutter-xfixes.

Without your additional changes on top of my patch, that will just work
(I've tested it): the priority of the unclutter-xfixes link group is 20,
such that if you have both packages installed unclutter-xfixes
automatically occupied /usr/bin/unclutter (since someone who has
installed unclutter-xfixes very likely wants to use that in preference
to unclutter-classic) but the Xsession.d file still works.

Does this make sense to you?  I'm certainly not wedded to the idea, but
I'd like to hear your opinion about it.

> Open issues and why I haven't uploaded the current state to
> experimental yet:
>
> * In the current setup, /etc/default/unclutter might need to be a
>   slave alternative, too. Not sure, though. Thoughts on this are
>   welcome!
>
> * /etc/default/unclutter and /etc/X11/Xsession.d/90unclutter could be
>   implementation-independent files, but then they need to be shipped
>   either by both packages (which causes a file conflict) or we create
>   some unclutter-common packages with just the common files between
>   both implementations.
>
>   Looks like the least complex implementation to me, but is probably
>   also the one with the most coordination effort between the
>   maintainers of both packages. (I suggest to maintain such a package
>   together in git so that either maintainer can easily upload fixes.)

If we decide want to go this route, I'd suggest that src:unclutter adds
a new bin:unclutter-common.  No need for a new source package.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#939176: RFS: ibus-keymagic/1.4-1 -- [ITP] Smart Keyboard Input (Multi Language Keyboard) is need your sponsor

[Ko Ko Ye`]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "ibus-keymagic"

 * Package name: ibus-keymagic
   Version : 1.4-1
   Upstream Author : kokoye2007 
 * URL : https://keymagic.net
 * License : GPL 2.0
 * Vcs : https://github.com/kokoye2007/ibus-keymagic
   Section : utils

It builds those binary packages:

  ibus-keymagic - keymagic engine for IBus
  ibus-keymagic-ayar-phonetic - ibus keymagic ayar-phonetic;
  ibus-keymagic-beolssalba - ibus keymagic beolssalba;
  ibus-keymagic-cessalba - ibus keymagic cessalba;
  ibus-keymagic-ddeolssalba - ibus keymagic ddeolssalba;
  ibus-keymagic-gugeolssalba - ibus keymagic gugeolssalba;
  ibus-keymagic-khmer-nida - ibus keymagic khmer-nida;
  ibus-keymagic-loringian-miu - ibus keymagic loringian-miu;
  ibus-keymagic-malayalam-inscript - ibus keymagic malayalam-inscript;
  ibus-keymagic-malayalam-mozhi - ibus keymagic malayalam-mozhi;
  ibus-keymagic-meolssalba - ibus keymagic meolssalba;
  ibus-keymagic-mon-anonta - ibus keymagic mon-anonta;
  ibus-keymagic-monbur - ibus keymagic monbur;
  ibus-keymagic-mon - ibus keymagic mon;
  ibus-keymagic-myanmar3 - ibus keymagic Myanmar3;
  ibus-keymagic-myanmar3x - ibus keymagic Myanmar3x;
  ibus-keymagic-myansan - ibus keymagic myansan;
  ibus-keymagic-mywin - ibus keymagic mywin;
  ibus-keymagic-ou-khamti - ibus keymagic ou-khamti;
  ibus-keymagic-ou-mon - ibus keymagic ou-mon;
  ibus-keymagic-ou-myanmar - ibus keymagic ou-Myanmar;
  ibus-keymagic-ou-palaung - ibus keymagic ou-palaung;
  ibus-keymagic-ou-pao - ibus keymagic ou-pao;
  ibus-keymagic-ou-shan - ibus keymagic ou-shan;
  ibus-keymagic-ou-taile - ibus keymagic ou-taile;
  ibus-keymagic-ou-taitham - ibus keymagic ou-taitham;
  ibus-keymagic-panglongshan - ibus keymagic panglongshan;
  ibus-keymagic-paoh - ibus keymagic paoh;
  ibus-keymagic-parabaik - ibus keymagic parabaik;
  ibus-keymagic-sunssalba - ibus keymagic sunssalba;
  ibus-keymagic-unimon - ibus keymagic unimon;
  ibus-keymagic-yunghkio - ibus keymagic yunghkio;
  ibus-keymagic-zawgyi - ibus keymagic zawgyi;
  ibus-keymagic-zawgyinonsmart - ibus keymagic zawgyinonsmart;
  ibus-keymagic-zawgyitai - ibus keymagic zawgyitai;
  ibus-keymagic-zawgyiunicode - ibus keymagic zawgyiunicode;
  ibus-keymagic-zgunicode - ibus keymagic zgunicode;
  ibus-keymagic-pyidaungsu - ibus keymagic pyidaungsu;

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

  https://mentors.debian.net/package/ibus-keymagic

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

  dget -x
https://mentors.debian.net/debian/pool/main/i/ibus-keymagic/ibus-keymagic_1.4-1.dsc

Changes since the last upload:

we need to upstream for 60++ smart keyboard in debian base distro.

 #933071 #925325 #925333

Regards,

Bug#939175: MainMenuSettings/Icon: Apparent maximum width causes long graphics to be very thin

[scott092707]

Package: lxqt-panel
Version: 0.14.1-1
Severity: wishlist

Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: Scott Jacobs 
To: Debian Bug Tracking System 
Subject: MainMenuSettings/Icon: Apparent maximum width causes long graphics to 
be very thin
Bcc: Scott Jacobs 
Message-ID: 
<156738784286.3691.7786862327068831120.reportbug@ASUS-PRIME-B350M-A-CSM>
X-Mailer: reportbug 7.5.2
Date: Sun, 01 Sep 2019 21:30:42 -0400
X-Debbugs-Cc: scott092...@aol.com

Dear Maintainer,

I have been playing around with Inkscape, trying to incorporate Debian's logo
and name into an custom "Icon" that can be selected from lxqt-panel's Main Menu
Settings.

If I just use Debian's logo, it's nice and large (Ditto with the default LXQt 
logo).
If I also include the Debian name in its official font, the combo becomes so
much smaller that I had to increase the panel height quite a bit to be able to 
read it,
and it's still really too small.

Lately I have felt guilty about not including LXQt's logo and/or name, so also
added the logo to Debian's logo+text, but things are miniscule, now...
(I also tried removing Debian's name, and just having their logo and LXQt's
logo and name - just as miniscule).

I am using a 49" QHD TV for my monitor, and I've got lots of screen real
estate, but apparently the panel will not use more than x number of pixels of
width, and scales the icon to fit the width, making the height way too small.

I wish that there could be an option that scales (one-to-one) the icon height
to the panel height, and uses whatever width results from the scaling.

I suppose there should be some sort of width limit, based upon how wide the
panel is, and what is already occupying it, but otherwise I would like to be
able to make an icon wider than the current limit - ideally, as wide as I want
to make it...



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

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

Versions of packages lxqt-panel depends on:
ii  libasound2  1.1.8-1
ii  libc6   2.28-10
ii  libdbusmenu-qt5-2   0.9.3+16.04.20160218-1
ii  libkf5solid55.54.0-1
ii  libkf5windowsystem5 5.54.0-1
ii  liblxqt-globalkeys-ui0  0.14.1-1
ii  liblxqt-globalkeys0 0.14.1-1
ii  liblxqt00.14.1-1
ii  libpulse0   12.2-4
ii  libqt5core5a5.11.3+dfsg1-1
ii  libqt5dbus5 5.11.3+dfsg1-1
ii  libqt5gui5  5.11.3+dfsg1-1
ii  libqt5widgets5  5.11.3+dfsg1-1
ii  libqt5x11extras55.11.3-2
ii  libqt5xdg3  3.3.1-2
ii  libqt5xml5  5.11.3+dfsg1-1
ii  libsensors5 1:3.5.0-3
ii  libstatgrab10   0.91-1+b2
ii  libstdc++6  8.3.0-6
ii  libsysstat-qt5-00.4.2-1
ii  libx11-62:1.6.7-1
ii  libxcb-xkb1 1.13.1-2
ii  libxcb1 1.13.1-2
ii  libxcomposite1  1:0.4.4-2
ii  libxdamage1 1:1.1.4-3+b3
ii  libxkbcommon-x11-0  0.8.2-1
ii  libxkbcommon0   0.8.2-1
ii  libxrender1 1:0.9.10-1
ii  lxmenu-data 0.1.5-2
ii  lxqt-policykit  0.14.1-1

Versions of packages lxqt-panel recommends:
ii  lxqt-about  0.14.1-1
ii  lxqt-config 0.14.1-2
ii  lxqt-notificationd  0.14.1-1
ii  lxqt-panel-l10n 0.14.1-1
ii  lxqt-qtplugin   0.14.0-3
ii  lxqt-runner 0.14.1-1
ii  lxqt-session0.14.1-2
ii  pavucontrol-qt  0.14.1-1
ii  qlipper 1:5.1.2-1

Versions of packages lxqt-panel suggests:
ii  lxqt   29
ii  lxqt-core  29

-- no debconf information

Bug#939174: RFS: fonts-myanmar/0.0-2 -- [ITP] Myanmar Font Package need Sponsor

[Ko Ko Ye`]

On Mon, Sep 2, 2019 at 8:18 AM Ko Ko Ye`  wrote:

> Package: sponsorship-requests
> Severity: wishlist
>
> Dear mentors,
>
> I am looking for a sponsor for my package "fonts-myanmar"
>
>  * Package name: fonts-myanmar
>Version : 0.0-2
>Upstream Author : kokoye2007 
>  * URL : https://github.com/kokoye2007/fonts-myanmar
>  * License : GPL 2.0
>  * Vcs : https://github.com/kokoye2007/fonts-myanmar
>Section : fonts
>
> It builds those binary packages:
>
>   fonts-myanmar - Myanmar fonts collection
>   fonts-myanmar-zawgyi - Myanmar font Zawgyi One v2008;
>   fonts-myanmar-myanmar3 - Myanmar fonts Myanmar3
>   fonts-myanmar-myanmarcensus - Myanmar fonts Myanmar Census
>   fonts-myanmar-pyidaungsu - fonts Pyidaungsu
>   fonts-myanmar-unicode - Myanmar Unicode fonts
>   fonts-myanmar-ayar - Myanmar fonts ayar
>   fonts-myanmar-angoun - Myanmar fonts angoun
>   fonts-myanmar-chatulight - Myanmar fonts chatulight
>   fonts-myanmar-chatu - Myanmar fonts chatu
>   fonts-myanmar-gantgaw - Myanmar fonts gantgaw
>   fonts-myanmar-khyay - Myanmar fonts khyay
>   fonts-myanmar-kuttar - Myanmar fonts kuttar
>   fonts-myanmar-nayone - Myanmar fonts nayone
>   fonts-myanmar-njaun - Myanmar fonts njaun
>   fonts-myanmar-pauklay - Myanmar fonts pauklay
>   fonts-myanmar-phetsot - Myanmar fonts phetsot
>   fonts-myanmar-phikselsmooth - Myanmar fonts phikselsmooth
>   fonts-myanmar-phiksel - Myanmar fonts phiksel
>   fonts-myanmar-ponenyet - Myanmar fonts ponenyet
>   fonts-myanmar-sabae - Myanmar fonts sabae
>   fonts-myanmar-sagar - Myanmar fonts sagar
>   fonts-myanmar-sanpya - Myanmar fonts sanpya
>   fonts-myanmar-squarelight - Myanmar fonts squarelight
>   fonts-myanmar-tagu - Myanmar fonts tagu
>   fonts-myanmar-thuriya - Myanmar fonts thuriya
>   fonts-myanmar-waso - Myanmar fonts waso
>   fonts-myanmar-yinmar - Myanmar fonts yinmar
>   fonts-myanmar-myanmarsanspro - Myanmar fonts Myanmar Sans Pro
>   fonts-myanmar-namkhone - Myanmar shan fonts Namkhone
>   fonts-myanmar-mon - Myanmar mon fonts MON3 Anonta 1
>
> To access further information about this package, please visit the
> following URL:
>
>   https://mentors.debian.net/package/fonts-myanmar
>
> Alternatively, one can download the package with dget using this command:
>
>   dget -x
> https://mentors.debian.net/debian/pool/main/f/fonts-myanmar/fonts-myanmar_0.0-2.dsc
>
> Changes since the last upload:
>
>   we fix
> infomation
> New Maintainer Guide Line
> New Packages Guide Line
> and Follow
> DFSG, Social Contract
>
> but we still need sponsor and ask again.
>   #896887  #899260 #924039 #923710 #924940
>
>
> Regards,
>


--

Bug#939174: RFS: fonts-myanmar/0.0-2 -- [ITP] Myanmar Font Package need Sponsor

[Ko Ko Ye`]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "fonts-myanmar"

 * Package name: fonts-myanmar
   Version : 0.0-2
   Upstream Author : [fill in name and email of upstream]
 * URL : [fill in URL of upstream's web site]
 * License : [fill in]
 * Vcs : [fill in URL of packaging vcs]
   Section : fonts

It builds those binary packages:

  fonts-myanmar - Myanmar fonts collection
  fonts-myanmar-zawgyi - Myanmar font Zawgyi One v2008;
  fonts-myanmar-myanmar3 - Myanmar fonts Myanmar3
  fonts-myanmar-myanmarcensus - Myanmar fonts Myanmar Census
  fonts-myanmar-pyidaungsu - fonts Pyidaungsu
  fonts-myanmar-unicode - Myanmar Unicode fonts
  fonts-myanmar-ayar - Myanmar fonts ayar
  fonts-myanmar-angoun - Myanmar fonts angoun
  fonts-myanmar-chatulight - Myanmar fonts chatulight
  fonts-myanmar-chatu - Myanmar fonts chatu
  fonts-myanmar-gantgaw - Myanmar fonts gantgaw
  fonts-myanmar-khyay - Myanmar fonts khyay
  fonts-myanmar-kuttar - Myanmar fonts kuttar
  fonts-myanmar-nayone - Myanmar fonts nayone
  fonts-myanmar-njaun - Myanmar fonts njaun
  fonts-myanmar-pauklay - Myanmar fonts pauklay
  fonts-myanmar-phetsot - Myanmar fonts phetsot
  fonts-myanmar-phikselsmooth - Myanmar fonts phikselsmooth
  fonts-myanmar-phiksel - Myanmar fonts phiksel
  fonts-myanmar-ponenyet - Myanmar fonts ponenyet
  fonts-myanmar-sabae - Myanmar fonts sabae
  fonts-myanmar-sagar - Myanmar fonts sagar
  fonts-myanmar-sanpya - Myanmar fonts sanpya
  fonts-myanmar-squarelight - Myanmar fonts squarelight
  fonts-myanmar-tagu - Myanmar fonts tagu
  fonts-myanmar-thuriya - Myanmar fonts thuriya
  fonts-myanmar-waso - Myanmar fonts waso
  fonts-myanmar-yinmar - Myanmar fonts yinmar
  fonts-myanmar-myanmarsanspro - Myanmar fonts Myanmar Sans Pro
  fonts-myanmar-namkhone - Myanmar shan fonts Namkhone
  fonts-myanmar-mon - Myanmar mon fonts MON3 Anonta 1

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

  https://mentors.debian.net/package/fonts-myanmar

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

  dget -x
https://mentors.debian.net/debian/pool/main/f/fonts-myanmar/fonts-myanmar_0.0-2.dsc

Changes since the last upload:

  we fix
infomation
New Maintainer Guide Line
New Packages Guide Line
and Follow
DFSG, Social Contract

but we still need sponsor and ask again.
  #896887  #899260 #924039 #923710 #924940


Regards,

Bug#939173: RFS: ibus-table-myanmar/0.0-1 -- [NMU] [ITP]

[Ko Ko Ye`]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "ibus-table-myanmar"

 * Package name: ibus-table-myanmar
   Version : 0.0-1
   Upstream Author : kokoye2007 
 * URL : https://launchpad.net/ibus-table-burmese/
 * License : GPL-3.0
 * Vcs : https://github.com/kokoye2007/ibus-table-myanmar
   Section : utils

It builds those binary packages:

  ibus-table-myanmar - ibus-table input method: Myanmar (dummy package)
  ibus-table-burmese - ibus-table input method: Burmese
  ibus-table-zawgyi - ibus-table input method: Zawgyi

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

  https://mentors.debian.net/package/ibus-table-myanmar

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

  dget -x
https://mentors.debian.net/debian/pool/main/i/ibus-table-myanmar/ibus-table-myanmar_0.0-1.dsc

Changes since the last upload:

Special Thanks
Boyuan Yang (Guide, Mentor, Support)
Osamu Aoki (Guide, Mentoring, Comment)
fix #925442 

[1]https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=925442
Regards,

Bug#939172: libclang-cpp9: broken-symlink /usr/lib/llvm-9/lib/libclang-cpp.so.1 -> libclang-cpp-9.so.1

[Paul Wise]

Package: libclang-cpp9
Version: 1:9~+rc3-1~exp1
Severity: normal
File: /usr/lib/llvm-9/lib/libclang-cpp.so.1
User: debian...@lists.debian.org
Usertags: obsolete-conffile adequate

There is one broken symlink in libclang-cpp9 since 1:9~+rc3-1~exp1.

The other symlinks in the directory properly link to the correct
installation dir but libclang-cpp.so.1 does not. Looks like this was
caused by the recent changes to libclang-cpp naming/installation.

This bug report brought to you by adequate:

https://bonedaddy.net/pabs3/log/2013/02/23/inadequate-software/

$ adequate libclang-cpp9
libclang-cpp9: broken-symlink /usr/lib/llvm-9/lib/libclang-cpp.so.1 -> 
libclang-cpp-9.so.1

$ chase /usr/lib/llvm-9/lib/libclang-cpp.so.1
chase: /usr/lib/llvm-9/lib/libclang-cpp-9.so.1: No such file or directory

$ apt-file search libclang-cpp-9.so.1
libclang-cpp9: /usr/lib/x86_64-linux-gnu/libclang-cpp-9.so.1

$ chase --verbose /usr/lib/llvm-9/lib/*.so.*
/usr/lib/llvm-9/lib/libclang-9.so.1
-> ../../x86_64-linux-gnu/libclang-9.so.1
/usr/lib/x86_64-linux-gnu/libclang-9.so.1
/usr/lib/llvm-9/lib/libclang-cpp.so.1
-> libclang-cpp-9.so.1
chase: /usr/lib/llvm-9/lib/libclang-cpp-9.so.1: No such file or directory
/usr/lib/llvm-9/lib/libclang-cpp.so.9
-> ../../x86_64-linux-gnu/libclang-cpp.so.9
-> libclang-cpp-9.so.1
/usr/lib/x86_64-linux-gnu/libclang-cpp-9.so.1
/usr/lib/llvm-9/lib/libclang.so.1
-> libclang-9.so.1
-> ../../x86_64-linux-gnu/libclang-9.so.1
/usr/lib/x86_64-linux-gnu/libclang-9.so.1

$ apt-get changelog libclang-cpp9 | grep -E 'libclang-cpp| naming'
  * Also install libclang-cpp in /usr/lib/llvm-X/lib/libclang-cpp.so.X
  * Rename libclang-cpp1-9 to libclang-cpp9 to match the soname and libllvm9
naming (at some point, all libs should do that ...)

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing-debug
  APT policy: (900, 'testing-debug'), (900, 'testing'), (800, 
'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700, 
'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental')
Architecture: amd64 (x86_64)

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

Versions of packages libclang-cpp9 depends on:
ii  libc6   2.28-10
ii  libgcc1 1:9.2.1-4
ii  libllvm91:9~+rc3-1~exp1
ii  libstdc++6  9.2.1-4

libclang-cpp9 recommends no packages.

libclang-cpp9 suggests no packages.

-- no debconf information

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Bug#939171: xdeb.desc: split out binary-is-wrong-architecture.desc

[Felix Lechner]

Hi Aaron,

On Sun, Sep 1, 2019 at 5:51 PM Aaron M. Ucko  wrote:
>
> [Copying Lintian maintainers for a sanity check.]

We generally do not know who uses custom profiles, and did not contact
you in advance. Thanks for copying us here.

> Running current Lintian with xdeb installed fails:
>
> AFAICT, the description for binary-is-wrong-architecture should move
> to a new /usr/share/lintian/tags/b/binary-is-wrong-architecture.desc,
> and gain a backreference to xdeb.desc by specifying "Check: elpa".

Sorry about the complications. Indeed, we split tags and checks the
way you described.

> Could you please take a look?

The fastest for you would be to emulate 'pkg-js-tools' or
'pkg-perl-tools', both of which resolved similar issues. If the bug
remains open, I will send you a patch.

'pkg-perl-tools' used these commits to address a similar issue:


https://salsa.debian.org/perl-team/modules/packages/pkg-perl-tools/commit/bfa237432097872ff9af45fadbcaba6bd3044db5

https://salsa.debian.org/perl-team/modules/packages/pkg-perl-tools/commit/fa98f03886d068c211779d3481adeed1a971c938

https://salsa.debian.org/perl-team/modules/packages/pkg-perl-tools/commit/d6a79fccb8331f986846b4eb6acdb2f3777c078a

Thank you for your patience with Lintian.

Kind regards,
Felix Lechner

Bug#939171: xdeb.desc: split out binary-is-wrong-architecture.desc

[Aaron M. Ucko]

Package: xdeb
Version: 0.6.7
Severity: important

[Copying Lintian maintainers for a sanity check.]

Running current Lintian with xdeb installed fails:

  /usr/share/lintian/checks/xdeb.desc does not have exactly one paragraph
Lintian::CheckScript::new("Lintian::CheckScript", 
"/usr/share/lintian/checks", "xdeb") called at 
/usr/share/perl5/Lintian/Profile.pm line 633
Lintian::Profile::_parse_check(Lintian::Profile=HASH(0x55bbf1eb57c8), 
"xdeb", "/usr/share/lintian/checks") called at 
/usr/share/perl5/Lintian/Profile.pm line 669
Lintian::Profile::_load_checks(Lintian::Profile=HASH(0x55bbf1eb57c8)) 
called at /usr/share/perl5/Lintian/Profile.pm line 174
Lintian::Profile::new("Lintian::Profile", undef, ARRAY(0x55bbeff0ee48), 
HASH(0x55bbf02bd290)) called at /usr/bin/lintian line 216
dplint::load_profile(undef) called at 
/usr/share/lintian/commands/lintian.pm line 1433
eval {...} called at /usr/share/lintian/commands/lintian.pm line 1433
main::load_profile_and_configure_tags() called at 
/usr/share/lintian/commands/lintian.pm line 652
main::main() called at /usr/bin/lintian line 46
eval {...} called at /usr/bin/lintian line 46
main::__ANON__("/usr/share/lintian/commands/lintian.pm") called at 
/usr/bin/lintian line 115
dplint::run_tool("/usr/bin/lintian", "lintian") called at 
/usr/bin/lintian line 291
dplint::main() called at /usr/bin/lintian line 374

AFAICT, the description for binary-is-wrong-architecture should move
to a new /usr/share/lintian/tags/b/binary-is-wrong-architecture.desc,
and gain a backreference to xdeb.desc by specifying "Check: elpa".

Could you please take a look?

Thanks!

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

Kernel: Linux 5.2.0-2-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages xdeb depends on:
ii  apt-utils1.8.3
ii  build-essential  12.7
ii  devscripts   2.19.6
ii  dpkg-cross   2.6.15-3
ii  dpkg-dev 1.19.7
ii  lintian  2.19.0
ii  python   2.7.16-1
ii  python-apt   1.8.4
ii  python-debian0.1.35
ii  sudo 1.8.27-1+b1
ii  wget 1.20.3-1+b1

Versions of packages xdeb recommends:
ii  fakeroot   1.23-1
ii  gcc4:9.2.1-3
ii  pseudo [fakeroot]  1.9.0+git20190515+996bead-2

xdeb suggests no packages.

-- no debconf information

Bug#881177: xdvi does not draw all the symbols properly

[Леон Майер]

It took me some time to understand how to turn back to Xorg; you didn't say it. 
Upon uncommenting the line

WaylandEnable=false

in  /etc/gdm3/daemon.conf and rebooting, I failed to reproduce the defect as of 
today. 


$ aptitude show texlive-binaries| grep Version

Version: 2018.20181218.49446-1

$ aptitude show xorg| grep Version

Version: 1:7.7+19


As far as I'm concerned, feel free to close the bug report.

Bug#933804: Improve dpt-forward documentation

[Alex Muntada]

Control: owner -1 !
Control: tags -1 + fixed pending

Hi Aniol,
thanks for trying dpt-forward and taking the time to report this
bug. Feedback is very welcome :)

> In the dpt-forward man page the need to belong in an
> organization when forwarding a patch to GitHub is not
> stated, so the user won't know that the default organization
> is pkg-perl-tools and it may have to be changed with the
> variable DPT_GITHUB_ORGNAME. I think that both the need to
> be in a organization and how to change it should be added to
> the man page.

The documentation for DPT_GITHUB_* variables and defaults is
available in man Debian::PkgPerl::GitHub. Unfortunately there
was no mention of that in man dpt-forward, so I just added it:
https://salsa.debian.org/perl-team/modules/packages/pkg-perl-tools/commit/ddb5d96a068a2af7ef91c161c007a14841e68a5e

> On the other hand, it is also not explained that the clone
> process is done through SSH, and it may cause problems if you
> expect it to be HTTPS. In this case I think that adding a
> variable DPT_GITHUB_PROTOCOL={https,ssh} would be very useful.

For the record, we've alreary addressed that in merge request !7:
https://salsa.debian.org/perl-team/modules/packages/pkg-perl-tools/merge_requests/7

Thank you!
Alex

--
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁   Alex Muntada 
  ⢿⡄⠘⠷⠚⠋   Debian Developer  log.alexm.org
  ⠈⠳⣄



signature.asc
Description: PGP signature

Bug#939170: linux: does not suspend completely, locks up

[Daniel M.]

Source: linux
Version: 5.2.9-2
Severity: important

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

*** End of the template - remove these template lines ***

Since the update from 4.19 to 5.2.9 my Lenovo Thinkpad E460 no longer suspends 
properly. If I 
close the lid or chose Suspend from the KDE launcher, the system will start to 
suspend but never 
reaches standby. Power light will blink as usual, display backlight turns off 
but keyboard LEDs 
don't turn off, fan is still active.

The system doesn't respond to Ctrl-Alt-Del or change to a Terminal. No input 
changes anything. 
Waiting (30min) doesn't help either. Rebooting to Kernel 4.19 fixes the problem 
immediatly.

Expected outcome would be a complete suspend/standby state and a complete 
recovery/powerup on
lid open or press of any key.


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

Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#939044: ocrmypdf: autopkgtest not compatible with new pikepdf, ghostscript and/or pytest

[Sean Whitton]

control: forcemerge 935749 -1

Hello Paul,

On Sat 31 Aug 2019 at 03:25PM +02, Paul Gevers wrote:

> With a recent upload of pikepdf and with a recent upload of ghostscript
> and with a recent upload of pytest (althought that pulls in the others)
> the autopkgtest of ocrmypdf fails in testing when that autopkgtest is
> run with the binary packages of those packages from unstable. It passes
> when run with only packages from testing. In tabular form, e.g.:
>passfail
> pikepdffrom testing1.6.1+dfsg-1
> ocrmypdf   from testing8.0.1+dfsg-1
> all others from testingfrom testing

I think this is a duplicate of #935749.

(Replying to you in case that's a bug in your tools for filing bugs.)

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#868527: [buildd-tools-devel] Bug#868527: Bug#868527: want sbuild --no-source or something

[Sean Whitton]

Hello Johannes,

On Sat 31 Aug 2019 at 12:55PM +02, Johannes Schauer wrote:

> It has been more than two years since the last message in this bugreport. As
> dgit becomes more and more mature, maybe we should revisit what sbuild could 
> do
> to improve on the current situation?
>
> For example I would not be opposed to a --dgit switch which would then do the
> right thing as it knows about the state of a source tree that dgit is able to
> work with and how it can (and should) be transported into an sbuild chroot.

Thank you for raising this topic again.

dgit can be used with several different branch layouts.  We probably
don't want to copy that knowledge from dgit into sbuild, so perhaps what
we want is for dgit to pass to sbuild the name of a git tree, which
sbuild will then try to build?

An issue with this is passing uncommitted changes to sbuild.  But
perhaps someone who wants to do that is probably best using the existing
sbuild wrapper where you just type 'sbuild' from the root of the source
tree.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#939126: Small optimization to patch

[Aaron Wyatt]

Just a minor improvement to the patch I submitted.
Cheers,
Aaron
--- jacktrip-1.1~repack/src/JackTrip.cpp	2019-09-02 07:57:44.0 +1000
+++ JackTrip.cpp	2019-09-02 07:58:29.098016907 +1000
@@ -450,7 +450,16 @@
   UdpSockTemp.readDatagram(buf, 1, , _port);
   UdpSockTemp.close(); // close the socket
 
-  mPeerAddress = peerHostAddress.toString();
+  // Convert any IPv4-mapped address to an actual IPv4 address
+  // (Due to a change in the way that QHostAddress works in Qt5)
+  bool couldConvert;
+  QHostAddress ipv4Address(peerHostAddress.toIPv4Address());
+  if (couldConvert) {
+mPeerAddress = ipv4Address.toString();
+  } else {
+mPeerAddress = peerHostAddress.toString();
+  }
+
   cout << "Client Connection Received from IP : " 
<< qPrintable(mPeerAddress) << endl;
   cout << gPrintSeparator << endl;

Bug#939168: systemd: LXC container fails to start after stretch->buster update inside container

[Sergey Aleynikov]

The init system that fails inside the container is the default one for
both stretch/buster - systemd, that's why i've reported this issue
here. LXC/init versions on the host haven't changed.

Bug#939168: systemd: LXC container fails to start after stretch->buster update inside container

[Michael Biebl]

Am 02.09.2019 um 00:30 schrieb Michael Biebl:
> Control: reassign -1 lxc
> 
> Am 01.09.2019 um 23:31 schrieb Sergey Aleynikov:
>> Source: systemd
>> Version: 241-5
>> Severity: important
>>
>> Dear Maintainer,
>>
>> *** Reporter, please consider answering these questions, where appropriate 
>> ***
>>
>>* What led up to the situation?
>> I'm running LXC containers (lxc version 1:2.0.7-2+deb9u2) on debian stretch. 
>> I have several containers
>> with different debian versions inside. After I've done stretch->buster 
>> upgrade in one of them, it stopped
>> working with 'lxc-start: tools/lxc_start.c: main: 366 The container failed 
>> to start.' message.
>>
>>* What exactly did you do (or not do) that was effective (or
>>  ineffective)?
>>
>> This is a reproducible sequence:
>>
>> lxc-create -n testupg -t download # choose debian - stretch - amd64
>> lxc-start -n testupg
>> lxc-attach -n testupg
>> # inside container
>> vi /etc/apt/sources.list # change stretch -> buster
>> apt-get update
>> apt-get dist-upgrade
>> exit
>> # outside of container
>> lxc-stop -n testupg
>> lxc-start -n testupg # won't work
>>
>> I'd expect containers to keep working after dist-upgrade.
> 
> Let's reassign that to lxc then. I don't see anything systemd specific here.

Especially since you seem to be using sysvinit.


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#939168: systemd: LXC container fails to start after stretch->buster update inside container

[Michael Biebl]

Control: reassign -1 lxc

Am 01.09.2019 um 23:31 schrieb Sergey Aleynikov:
> Source: systemd
> Version: 241-5
> Severity: important
> 
> Dear Maintainer,
> 
> *** Reporter, please consider answering these questions, where appropriate ***
> 
>* What led up to the situation?
> I'm running LXC containers (lxc version 1:2.0.7-2+deb9u2) on debian stretch. 
> I have several containers
> with different debian versions inside. After I've done stretch->buster 
> upgrade in one of them, it stopped
> working with 'lxc-start: tools/lxc_start.c: main: 366 The container failed to 
> start.' message.
> 
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
> 
> This is a reproducible sequence:
> 
> lxc-create -n testupg -t download # choose debian - stretch - amd64
> lxc-start -n testupg
> lxc-attach -n testupg
> # inside container
> vi /etc/apt/sources.list # change stretch -> buster
> apt-get update
> apt-get dist-upgrade
> exit
> # outside of container
> lxc-stop -n testupg
> lxc-start -n testupg # won't work
> 
> I'd expect containers to keep working after dist-upgrade.

Let's reassign that to lxc then. I don't see anything systemd specific here.


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#897040: fontconfig: .uuid files in font directories not removed during purge (piuparts issue)

[Alexis Murzeau]

Hi,

This bug seems to be fixed since merge requests !30 got merged [0].
I've read a bit what was made and it seems .uuid files were removed.

This change is in version 2.13.91, to be confirmed.


[0] https://gitlab.freedesktop.org/fontconfig/fontconfig/merge_requests/30

-- 
Alexis Murzeau
PGP: B7E6 0EBB 9293 7B06 BDBC  2787 E7BD 1904 F480 937F



signature.asc
Description: OpenPGP digital signature

Bug#826699:

[Meho Hodzić]

Bug#935485: Looking for help with a recently removed package, kcollectd

[Lisandro Damián Nicanor Pérez Meyer]

Hi Antonio! It seems you missed my mail to the wnpp bug, ( my fault, I
should have CCed you) but better yet if Sandro can help here, he definitely
knows the kde side of the team much better then I.

Of course, feel free to ping me if necessary.

Cheers, Lisandro

Bug#939168: systemd: LXC container fails to start after stretch->buster update inside container

[Sergey Aleynikov]

Source: systemd
Version: 241-5
Severity: important

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
I'm running LXC containers (lxc version 1:2.0.7-2+deb9u2) on debian stretch. I 
have several containers
with different debian versions inside. After I've done stretch->buster upgrade 
in one of them, it stopped
working with 'lxc-start: tools/lxc_start.c: main: 366 The container failed to 
start.' message.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

This is a reproducible sequence:

lxc-create -n testupg -t download # choose debian - stretch - amd64
lxc-start -n testupg
lxc-attach -n testupg
# inside container
vi /etc/apt/sources.list # change stretch -> buster
apt-get update
apt-get dist-upgrade
exit
# outside of container
lxc-stop -n testupg
lxc-start -n testupg # won't work

I'd expect containers to keep working after dist-upgrade.

-- System Information:
Debian Release: 9.9
  APT prefers oldstable-updates
  APT policy: (500, 'oldstable-updates'), (500, 'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.0-9-amd64 (SMP w/56 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Bug#923096: consider porting to Breezy

[Vagrant Cascadian]

Control: retitle 936618 RM: git-remote-bzr -- removal triggered by the Python2 
removal
Control: reassign 936618 ftp.debian.org

On 2019-08-31, Jelmer Vernooij wrote:
> On Sun, Mar 03, 2019 at 01:39:32PM -0800, Vagrant Cascadian wrote:
>> On 2019-02-24, Jelmer Vernooij wrote:
>> > bzr has long been dormant upstream. It will be replaced in Debian (in
>> > buster+1) with Breezy (www.breezy-vcs.org), which is actively
>> > maintained and has a Python 3 port. Breezy has a command-line that is
>> > backwards compatible with Bazaar.
>> >
>> > Please consider porting git-remote-bzr to the 'breezy' Python module
>> > instead of using Bazaar's 'bzrlib'. Most of the porting process should
>> > be a matter of running s/bzrlib/breezy/ on your code.
>> 
>> Given that git-remote-bzr provides a git frontend to a bzr repository,
>> I'm not sure the backwards compatible command-line interface sounds too
>> exciting... :)
>> 
>> I don't personally work with many bzr repositorys anymore, so I would be
>> inclined to orphan git-remote-bzr to someone with a more vested interest
>> if bzr/bzrlib was dropped for buster+1.
>> 
>> Upstream on git-remote-bzr hasn't been terribly active either:
>> 
>>   https://github.com/felipec/git-remote-bzr
>> 
>> Though it's largely continued to work, which isn't a bad sign.
> Bazaar will be removed with the Python 2 transition, with transitional
> packages being added to upgrade users to Breezy.
>
> git-remote-bzr is the only remaining blocker for the Bazaar to Breezy
> transition (and various plugin packages). Per the guidance in
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=936618, what are
> your plans for the package?

I don't use it anymore myself, as everything I was using it with
switched to git... so, let's remove it. With both the planned removal of
bzr and python2, and I don't see much recent activity upstream to switch
to breezy or python3, it should probably just be removed from Debian.

Thanks everyone, it was a fun ride!


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#939167: RFS: streamlink/1.2.0+dfsg-1~bpo10+1

[Alexis Murzeau]

Package: sponsorship-requests
Severity: wishlist
X-Debbugs-CC: debian-backpo...@lists.debian.org

Dear mentors and backports developers,

I am looking for a sponsor for my package "streamlink" into Debian
buster-backports repository.

 * Package name: streamlink
   Version : 1.2.0+dfsg-1~bpo10+1
   Upstream Author : Streamlink Team
 * URL : https://streamlink.github.io/
 * License : BSD-2-clause, Apache-2.0, MIT/Expat, SIL-OFL-1.1
   Section : python

It builds those binary packages:

  python3-streamlink - Python module for extracting video streams at
various websites
  python3-streamlink-doc - CLI for extracting video streams from various
websites (documentation)
  streamlink - CLI for extracting video streams from various websites to
a video player

To access further information about this package, please visit the
following URL:
  https://mentors.debian.net/package/streamlink


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

  dget -x
https://mentors.debian.net/debian/pool/main/s/streamlink/streamlink_1.2.0+dfsg-1~bpo10+1.dsc

More information about streamlink can be obtained from
https://streamlink.github.io/

Changes since the package in buster main (1.0.0+dfsg-1):
streamlink (1.2.0+dfsg-1~bpo10+1) buster-backports; urgency=medium

  * Rebuild for buster-backports.
  * Update d/README.source for buster-backports

 -- Alexis Murzeau   Sun, 01 Sep 2019 22:56:54 +0200

streamlink (1.2.0+dfsg-1) unstable; urgency=medium

  * New upstream version 1.2.0+dfsg
  * Update remove_new_version_check patch
  * Move from PyCrypto to pycryptodomex
  * Fix typo in manpage with patch plugins.pixiv-fix-doc-typo-thats-that-s

 -- Alexis Murzeau   Fri, 23 Aug 2019 19:31:42 +0200

streamlink (1.1.1+dfsg-1) unstable; urgency=medium

  * Use ignore-branch instead of having different gbp.conf over branches
  * Bump standard version to 4.4.0, no change required
  * Bump debhelper compat to 12
  * Remove livestreamer transitional package
  * Merge changes in experimental to unstable

 -- Alexis Murzeau   Tue, 16 Jul 2019 22:39:58 +0200

streamlink (1.1.1+dfsg-1~exp1) experimental; urgency=low

  * New upstream version 1.1.1+dfsg
  * Update patch remove_new_version_check

 -- Alexis Murzeau   Wed, 19 Jun 2019 21:58:59 +0200



Differences from testing package (1.2.0+dfsg-1):
  * Update d/README.source for buster-backports


Regards,
-- 
Alexis Murzeau
PGP: B7E6 0EBB 9293 7B06 BDBC  2787 E7BD 1904 F480 937F





signature.asc
Description: OpenPGP digital signature

Bug#934905: libaqbanking35: libaqbanking not ready for PSD2, will not work after 14 September 2019

[Felix Geyer]

On 25.08.19 13:33, Felix Geyer wrote:

Hi Micha,

On Mon, 19 Aug 2019 20:19:28 +0200 Micha Lenk  wrote:

Hi Christian,

I understand your bug report and confirm it to be an issue.

Unfortunately I don't have much capacity at the moment to work on an updated package in a timely 
manner. But I do appreciate and support any volunteer's help.


I've tested libaqbaking 5.8.1 in combination with gnucash 3.6 + patch for the 
registration key.
It seems to work fine, at least the unregistered software warning from the log 
is gone.

The only packaging changes are some new entries in the symbols file (diff 
attached).
Do you mind if I NMU 5.8.1 to unstable?


I've uploaded version 5.8.2 to DELAYED/2 now.

Cheers,
Felix

Bug#939048: transition: glibc

[Aurelien Jarno]

On 2019-09-01 22:00, Paul Gevers wrote:
> Hi Aurelien,
> 
> On 31-08-2019 18:37, Paul Gevers wrote:
> > On 31-08-2019 16:12, Aurelien Jarno wrote:
> >> I would like to get a transition slot for glibc 2.29. It is available in
> >> experimental for a bit more than 2 weeks and there is no known issue or
> >> regression.
> 
> > I can have the experimental-to-unstable pseudo britney run finish its
> > work for glibc soon. That can tell us if there are potential autopkgtest
> > regressions to be expected.
> 
> It's not 100% finished, but there seems to be already items worth
> checking. I think some items were already mentioned by you, and some
> items are involved in ongoing transitions, so may be false positives,
> but anyways:
> 
> https://release.debian.org/britney/pseudo-excuses-experimental.html#glibc

I picked up a few issues, and they were false positive:
- dante: needs to be binNMUed against the new libc
- dwarves-dfsg: debci issue, it looks like the experimental-debug
  repository is missing.
- gnuplot: temporary issue due to a new upload.
- haskell-hopenpgp: packages are not installable due to the haskell
  transition
- nemo: seems to be a bug in udisks2 postinst script
- pg-repack: debci issue, the regression is caused by libpq5 from
  experimental, which is wrongly selected instead of the unstable
  version.
- repmgr: ditto with libpq-dev.
- slurm-llnl: the packages are not installable, glibc doesn't seem to be
  the cause.

There are also a few failures that seems to be related to slight change
of precision of the math functions: pyfai, sextractor.

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net


signature.asc
Description: PGP signature

Bug#826699:

[Meho Hodzić]

Bug#935970: stretch-pu: package node-fstream/1.0.10-1+deb9u1

[Xavier]

Control: tags -1 - moreinfo

Le 01/09/2019 à 12:38, Adam D. Barratt a écrit :
> node-fstream is vulnerable to Arbitrary File Overwrite (#931408,
> CVE-2019-13173). This little patch fixes the problem.

Sorry, I forgot to push it. Done (see #939166)

Bug#939166: buster-pu: package node-fstream/1.0.10-1+deb10u1

[Xavier Guimard]

Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu

Hi all,

node-fstream is vulnerable to Arbitrary File Overwrite (#931408,
CVE-2019-13173). This little patch fixes the problem.
diff --git a/debian/changelog b/debian/changelog
index 8162572..9d3352a 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+node-fstream (1.0.10-1+deb10u1) buster; urgency=medium
+
+  * Team upload
+  * Clobber a Link if it's in the way of a File
+(Closes: #931408, CVE-2019-13173)
+
+ -- Xavier Guimard   Sun, 01 Sep 2019 22:37:19 +0200
+
 node-fstream (1.0.10-1) unstable; urgency=medium
 
   * New upstream version 1.0.10
diff --git a/debian/patches/CVE-2019-13173.diff 
b/debian/patches/CVE-2019-13173.diff
new file mode 100644
index 000..6adddad
--- /dev/null
+++ b/debian/patches/CVE-2019-13173.diff
@@ -0,0 +1,20 @@
+Description: Clobber a Link if it's in the way of a File
+Author: isaacs 
+Origin: upstream, https://github.com/npm/fstream/commit/6a77d2f
+Bug: https://www.npmjs.com/advisories/886
+Bug-Debian: https://bugs.debian.org/931408
+Forwarded: not-needed
+Reviewed-By: Xavier Guimard 
+Last-Update: 2019-08-28
+
+--- a/lib/writer.js
 b/lib/writer.js
+@@ -147,7 +147,7 @@
+ 
+ // if it's a type change, then we need to clobber or error.
+ // if it's not a type change, then let the impl take care of it.
+-if (currentType !== self.type) {
++if (currentType !== self.type || self.type === 'File' && current.nlink > 
1) {
+   return rimraf(self._path, function (er) {
+ if (er) return self.error(er)
+ self._old = null
diff --git a/debian/patches/series b/debian/patches/series
index d1851b7..3e5db07 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1 +1,2 @@
 fixtest.patch
+CVE-2019-13173.diff

Bug#937325: [3dprinter-general] Bug#937325: printrun: Python2 removal in sid/bullseye

[Rock Storm]

Control: tags -1 pending

On Fri, Aug 30, 2019 at 07:31:39AM +, Matthias Klose wrote:
> Your package either build-depends, depends on Python2, or uses Python2
> in the autopkg tests.  Please stop using Python2, and fix this issue
> [...].

A new version of Printrun is already in the NEW queue which will solve
this issue.

Thanks for the report,

--
Rock Storm
GPG KeyID: 4096R/C96832FD
GPG Fingerprint:
 C304 34B3 632C 464C 2FAF  C741 0439 CF52 C968 32FD

Bug#920040: ITP: waybar -- Highly customizable Wayland bar for Sway and Wlroots based compositors

[Martin Michlmayr]

* Birger Schacht  [2019-01-21 21:12]:
> * Package name: waybar

What's the status of this package?

I cannot find it on mentors anymore but I also don't see it in Debian.

Thanks for packaging sway!
-- 
Martin Michlmayr
https://www.cyrius.com/

Bug#931219: /usr/bin/autopkgtest-virt-qemu: should listen on 127.0.0.1 for SSH port forward

[Martin Pitt]

Control: tag -1 pending

Hello Raphaël,

Raphaël Hertzog [2019-06-28 15:07 +0200]:
> When qemu is run by autopkgtest-virt-qemu, it will happily forward the
> SSH port of the test VM to all network interfaces.
> 
> I'm not quite sure what's the purpose of this port forward (I thought
> everything happened over serial terminals), but IMO it should really be
> restricted to localhost only.

The serial console is much too slow for any "serious" data exchange, it's only
being used to establish the ssh connection. It's also useful for debugging
failed tests.

Indeed the forwarding should be restricted to localhost, thanks for spotting!
Patch tested and applied.

Martin

Bug#939096: RFS: oomd/0.1.0-1 [ITP] -- userspace Out-Of-Memory (OOM) killer for Linux systems

[Adam Borowski]

On Sun, Sep 01, 2019 at 05:48:14PM +0800, Yangfl wrote:
>  * Package name: oomd
>Version : 0.1.0-1
>Upstream Author : Dan Xu 
>  * URL : https://github.com/facebookincubator/oomd

> It builds those binary packages:
> 
>   oomd - userspace Out-Of-Memory (OOM) killer for Linux systems
>   liboomd0 - userspace Out-Of-Memory (OOM) killer for Linux systems - library

Hi!
I'm afraid the package FTBFSes due to symbol mismatches:
http://ix.io/1U0J


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋  The root of a real enemy is an imaginary friend.
⠈⠳⣄

Bug#939048: transition: glibc

[Paul Gevers]

Hi Aurelien,

On 31-08-2019 18:37, Paul Gevers wrote:
> On 31-08-2019 16:12, Aurelien Jarno wrote:
>> I would like to get a transition slot for glibc 2.29. It is available in
>> experimental for a bit more than 2 weeks and there is no known issue or
>> regression.

> I can have the experimental-to-unstable pseudo britney run finish its
> work for glibc soon. That can tell us if there are potential autopkgtest
> regressions to be expected.

It's not 100% finished, but there seems to be already items worth
checking. I think some items were already mentioned by you, and some
items are involved in ongoing transitions, so may be false positives,
but anyways:

https://release.debian.org/britney/pseudo-excuses-experimental.html#glibc

Paul



signature.asc
Description: OpenPGP digital signature

Bug#893497: buffer overflow in column(1)

[Julian Brost]

I just ran into the same problem and found that this happens due to
column_maxline.diff which allocates a buffer that is too small because
it implicitly assumes sizeof(wchar_t) == 2 which is wrong.

The attached patch should fix this issue.
From 4fbb900f04fd737d6422b613ada7034249fec5fc Mon Sep 17 00:00:00 2001
From: Julian Brost 
Date: Sun, 1 Sep 2019 21:48:27 +0200
Subject: [PATCH] column_maxline.diff: use correct size for buffer

By using a hard-coded shift left by one, the patch implicitly assumed
that sizeof(wchar_t) == 2, but this is not always the case and the
buffer may be too small. This commit fixes this by using sizeof(wchar_t)
to calculate the correct size for the buffer.

This fixes #893497
---
 debian/patches/column_maxline.diff | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/patches/column_maxline.diff b/debian/patches/column_maxline.diff
index c35e7f4..eab84c4 100644
--- a/debian/patches/column_maxline.diff
+++ b/debian/patches/column_maxline.diff
@@ -18,7 +18,7 @@ Author: Michael Meskes 
 -	wchar_t *p, buf[MAXLINELEN];
 +	wchar_t *p, *buf;
 +
-+	buf = malloc(MAXLINELEN<<1);
++	buf = malloc(MAXLINELEN * sizeof(wchar_t));
 +	if (!buf)
 +		err(1, (char *)NULL);
  
-- 
2.20.1

Bug#454595: spamassassin: create preferences for virtual users doesn't work by default

[Osric Wilkinson]

Package: spamassassin
Version: 3.4.2-1
Followup-For: Bug #454595

Dear Maintainer,

   * What led up to the situation?
Testing a new install of SpamAssassing
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
Submtted mail to a user without a config folder

   * What was the outcome of this action?
No new folder, and an error in the log:

 spamd[18039]: config: mkdir /home/vmail/mail/osric/sa failed: Insecure
 dependency in mkdir while running with -T switch at
 /usr/share/perl/5.28/File/Path.pm line 198,  line 2

My perl-fu is not strong, but I tried basic untainting, replacing

  mkpath($fname, 0, 0700);

with

  my $clean = $fname ~= /^(*.)$/;
  mkpath($clean, 0, 0700);

(around line 1925 in /usr/share/perl5/Mail/SpamAssassin.pm)

but there was no change (no new folder)
  
   * What outcome did you expect instead?
The folder specified in --virtual-config-dir to be created per
the manpage for spamd.


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

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

Versions of packages spamassassin depends on:
ii  adduser3.118
ii  init-system-helpers1.56+nmu1
pn  libarchive-tar-perl
ii  libhtml-parser-perl3.72-3+b3
ii  libhttp-date-perl  6.02-1
ii  libmail-dkim-perl  0.54-1
ii  libnet-dns-perl1.19-1
ii  libnetaddr-ip-perl 4.079+dfsg-1+b3
ii  libsocket6-perl0.29-1+b1
ii  libsys-hostname-long-perl  1.5-1
ii  libwww-perl6.36-2
ii  lsb-base   10.2019051400
ii  perl   5.28.1-6

Versions of packages spamassassin recommends:
ii  gnupg2.2.12-1
ii  libio-socket-inet6-perl  2.72-2
ii  libmail-spf-perl 2.9.0-4
pn  libsys-syslog-perl   
ii  sa-compile   3.4.2-1
ii  spamc3.4.2-1

Versions of packages spamassassin suggests:
pn  libcompress-zlib-perl  
pn  libdbi-perl
pn  libencode-detect-perl  
pn  libgeo-ip-perl 
ii  libio-socket-ssl-perl  2.060-3
pn  libnet-patricia-perl   
pn  pyzor  
pn  razor  

-- Configuration Files:
/etc/default/spamassassin changed:
OPTIONS="--allow-tell --create-prefs --nouser-config 
--virtual-config-dir=/home/vmail/mail/%l/sa --username=vmail --groupname=vmail 
--listen=127.0.0.1 --max-spare=2 -D"
PIDFILE="/var/run/spamd.pid"
CRON=1

/etc/spamassassin/local.cf changed:
report_safe 0
trusted_networks 127. 
required_score 10.0
ifplugin Mail::SpamAssassin::Plugin::Shortcircuit
shortcircuit USER_IN_WHITELIST   on
shortcircuit USER_IN_DEF_WHITELIST   on
shortcircuit USER_IN_ALL_SPAM_TO on
shortcircuit SUBJECT_IN_WHITELISTon
shortcircuit USER_IN_BLACKLIST   on
shortcircuit USER_IN_BLACKLIST_TOon
shortcircuit SUBJECT_IN_BLACKLISTon
shortcircuit ALL_TRUSTED on
endif # Mail::SpamAssassin::Plugin::Shortcircuit


-- no debconf information

Bug#936773: python-jupyter-console

[Gordon Ball]

Acknowledged.

The git repository already contains 6.0.0, which is python3 only.
Waiting on prompt-toolkit >= 2 (#914698). If this doesn't happen anytime
soon, I'll do a fresh upload of 5.2.0 to drop the python2 binary.

Bug#939165: nmh: spost execs /usr/lib/mh/nmh/post, could do with s:nmh/::

[Robert Waldner]

Package: nmh
Version: 1.7.1-4
Severity: normal
Tags: patch

Dear Maintainer (hi az!),

Upgraded jessie->strecch->buster, spost no longer coooperated. When used
via exmh I got
"/usr/lib/mh/spost: 13: exec: /usr/lib/mh/nmh/post: not found"

Fixed the path in spost to no longer contain the nmh part, everything works
again as expected. Looked at the source from testing, too - doesn't seem to
be fixed there, either.

Patch is as simple as:

===
$ diff -u ./nmh-1.7.1/debian/nmh/usr/lib/mh/spost /usr/lib/mh/spost
--- ./nmh-1.7.1/debian/nmh/usr/lib/mh/spost 2019-02-12 05:58:31.0 
+0100
+++ /usr/lib/mh/spost   2019-09-01 21:26:16.338481935 +0200
@@ -10,4 +10,4 @@
 
 prefix=''
 exec_prefix="${prefix}"
-exec "${prefix}/usr/lib/mh/nmh/post" -mts sendmail/pipe "$@"
+exec "${prefix}/usr/lib/mh/post" -mts sendmail/pipe "$@"
=== 

Thanks for continuing to maintain nmh!


cheers,



-- System Information:
Debian Release: 10.0
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-5-amd64 (SMP w/16 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.ISO-8859-15, LC_CTYPE=en_US.ISO-8859-15 
(charmap=ISO-8859-15), LANGUAGE=en_US.ISO-8859-15 (charmap=ISO-8859-15)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages nmh depends on:
ii  libc6   2.28-10
ii  libcurl47.64.0-4
ii  libdb5.35.3.28+dfsg1-0.5
ii  liblockfile11.14-1.1
ii  libsasl2-2  2.1.27+dfsg-1
ii  libssl1.1   1.1.1c-1
ii  libtinfo6   6.1+20181013-2
ii  mime-support3.62
ii  netbase 5.6
ii  sensible-utils  0.0.12

Versions of packages nmh recommends:
ii  postfix [mail-transport-agent]  3.4.5-1

Versions of packages nmh suggests:
ii  exmh1:2.9.0-1
ii  libmailtools-perl   2.18-1
ii  libmime-tools-perl  5.509-1
pn  mh-book 
pn  mh-e
pn  par 

-- no debconf information

Bug#939088: Unable to accept TLS connection: system call error: [104]

[Hilmar Preuße]

On 01.09.19 09:58, Frédéric Mathy wrote:

> Since update Debian 9 to 10, I can't connect via FTP TLS/SSL
> 
> TLS/TLS-C requested, starting TLS handshake
> unable to accept TLS connection: system call error: [104] Connexion
> ré-initialisée par le correspondant
> 
Unfortunately I don't speak french. What I found in [1] is that the
client disconnected the session.

1. Is the issue reproducible w/ a different client?
2. Do you have some logs from the client telling, why the client
disconnected the session?
3. Is #922307 similar to your one?

Hilmar

[1] https://sourceforge.net/p/proftp/mailman/message/25665563/
-- 
sigfault
#206401 http://counter.li.org



signature.asc
Description: OpenPGP digital signature

Bug#925473: tomcat9: sysvinit script missing (Policy §9.11¶2 “must”)

[Thorsten Glaser]

Dixi quod…

>branch and testing it; can we please merge it into master and upload
>to unstable once it has been tested (should be no problem, I already

FWIW, it builds and installs (as upgrade) and starts.

bye,
//mirabilos
-- 
15:41⎜ Somebody write a testsuite for helloworld :-)

Bug#939163: src:python-quantities: License in debian/copyright different than upstream

[Scott Kitterman]

Package: src:python-quantities
Version: 0.12.1-1
Severity: serious
Justification: Policy 2.3

While reviewing your package in the New queue, I noticed that the
license currently in the package is radically different than that in
debian/copyright.  I'm accepting the package anyway, since this is an
existing problem in the archive and not new to this update.  Please fix
when you do your source only upload following New.

See doc/user/license.rst for details.

Scott K

Bug#870529: Tested modification proposed by bug reporter

[Stefan Champailler]

Hello,

Just to mention that I've tested the modifications proposed by the person who 
reported the bug.
I'm not sure it works.

After the applying the proposed modification, squeezelite starts as expected 
and is usable (playing music from LMS).
However, other application (in this case firefox) gives strange results : all 
seems to work fine when playing a video from youtube, but there's no sound at 
all.

Before the modification, the youtube video was not even playing (i.e., no 
image, no sound).

Please note that in my set up, squeezelite, Logitech MEdia Server and Firefox 
are all run from the same machine.

Best regards,

Stefan

Bug#939154: lyx-common: convertDefault.py will not work with Python3

[Dr. Tobias Quathamer]

Am 01.09.19 um 18:36 schrieb Georges Khaznadar:
> The reason for this misbehavior is that either with Python2 or
> with Python3, os.popen deals with 'str' data, never 'bytes' data.
> 
> So, lines 37 and 38 of the script must be erased.
> 
> Here is a short diff which fixes this issue:

Hi Georges,

thanks a lot for spotting this bug and filing a report with patch! The
fixed package is on its way to unstable.

Regards,
Tobias



signature.asc
Description: OpenPGP digital signature

Bug#939117: grilo-plugins: Python2 removal in sid/bullseye -- drop python-dbusmock build dependency

[Martin Pitt]

Hello Alberta,

Alberto Garcia [2019-09-01 19:14 +0200]:
> I noticed this a few weeks ago and I already had a patch removing this
> build dependency, I was just waiting for the next upstream release.

Great to hear!

> If you don't mind waiting I'll do it then (we can set a deadline to
> make sure that it doesn't take too long). But if you prefer to have it
> done now I can take care of it later today or tomorrow, no problem for
> me.

No rush. There's plenty of other reverse dependencies to wait for, so just wait
for the next upstream release. Thanks!

Martin

Bug#936436: marked as done (dolfin: Python2 removal in sid/bullseye)

[Drew Parsons]

On 2019-09-02 02:44, Drew Parsons wrote:

On 2019-09-02 02:33, Graham Inggs wrote:

Hi Drew


From: Drew Parsons 
To: 936436-d...@bugs.debian.org
Cc:
Bcc:
Date: Sun, 01 Sep 2019 23:00:50 +0800
Subject: Re: #936436 dolfin: Python2 removal in sid/bullseye
> Your package either build-depends, depends on Python2, or uses Python2
in the autopkg tests.


No it doesn't.--


The control file of dolfin-bin_2019.1.0-4_all.deb contains "Depends:
python:any", see below.




oh hey!  Thanks Graham.




Still, no.  It's not in debian/control:

Package: dolfin-bin
Architecture: all
Depends:
 python3-dolfin (>= ${source:Version}),
 ${misc:Depends},
 ${python3:Depends}

Bug#934997: konsole does not display button for open new tab

[Antonio]

I have recompiled the new version, it simply limits itself to restore
a flag that is then reported in the configuration file konsolerc.
So, to restore the button, is sufficient this workaround :

F="/home/USER/.config/konsolerc"
grep  -q "NewTabButton=" "$F"||gawk -i inplace
'{print}/^\[TabBar\]/{print "NewTabButton=true"}' "$F"

Bug#936436: marked as done (dolfin: Python2 removal in sid/bullseye)

[Drew Parsons]

On 2019-09-02 02:46, Drew Parsons wrote:

On 2019-09-02 02:44, Drew Parsons wrote:

On 2019-09-02 02:33, Graham Inggs wrote:


The control file of dolfin-bin_2019.1.0-4_all.deb contains "Depends:
python:any", see below.




oh hey!  Thanks Graham.




Still, no.  It's not in debian/control:





I see it now, it's dolfin-order and dolfin-plot

Drew

Bug#936436: marked as done (dolfin: Python2 removal in sid/bullseye)

[Drew Parsons]

On 2019-09-02 02:33, Graham Inggs wrote:

Hi Drew


From: Drew Parsons 
To: 936436-d...@bugs.debian.org
Cc:
Bcc:
Date: Sun, 01 Sep 2019 23:00:50 +0800
Subject: Re: #936436 dolfin: Python2 removal in sid/bullseye
> Your package either build-depends, depends on Python2, or uses Python2
in the autopkg tests.


No it doesn't.--


The control file of dolfin-bin_2019.1.0-4_all.deb contains "Depends:
python:any", see below.




oh hey!  Thanks Graham.


Drew

Bug#825809: unclutter: diff for NMU version 8-21.1

[Axel Beckert]

Hi Sean,

Sean Whitton wrote:
> I've prepared an NMU for unclutter (versioned as 8-21.1) and uploaded it
> to DELAYED/15. Please feel free to tell me if I should delay it longer.

Yes, please remove it completely. It is incomplete and has unsolved
issues which might be even harder to fix properly afterwards if the
upload succeeds.

I'll try to upload unclutter 8-22 (to experimental) before that NMU
passes throught, but for that, I need your feedback first:

Please check the master branch under
https://salsa.debian.org/debian/unclutter and especially the commits I
made after applying your NMU patch minus the unnecessary NMU stuff:

https://salsa.debian.org/debian/unclutter/commits/master

Main points:

* Make /etc/X11/Xsession.d/90unclutter a slave alternative, too.
* Rename /etc/default/unclutter to /etc/default/unclutter-classic.
* Make debian/unclutter.install executable. (Might have been lost when
  you generated your patch as it clearly FTBFS else.)

I'd appreciate if you could look over these changes and tell me if you
agree (as we both should agree on at least the list of slave
alternatives), have alternative suggestions or otherwise comments.

Open issues and why I haven't uploaded the current state to
experimental yet:

* In the current setup, /etc/default/unclutter might need to be a
  slave alternative, too. Not sure, though. Thoughts on this are
  welcome!

* /etc/default/unclutter and /etc/X11/Xsession.d/90unclutter could be
  implementation-independent files, but then they need to be shipped
  either by both packages (which causes a file conflict) or we create
  some unclutter-common packages with just the common files between
  both implementations.

  Looks like the least complex implementation to me, but is probably
  also the one with the most coordination effort between the
  maintainers of both packages. (I suggest to maintain such a package
  together in git so that either maintainer can easily upload fixes.)

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#939162: Updated debconf PO translation for the package dbconfig-common [INT:nl]

[Maarten]

Package: dbconfig-common
Version: 2.0.12
Severity: wishlist
Tags: patch, l10n



Dear Maintainer


Benedict Verheyen did not seem to be around any more. Therefore, I
updated the translation for dbconfig-common.


Kind regards

Maarten
member of the Dutch translation team of Debian

nl.po.gz
Description: GNU Zip compressed data

Bug#937104: [Python-modules-team] Bug#937104: namebench: Python2 removal in sid/bullseye

[Scott Kitterman]

On Sunday, September 1, 2019 2:35:21 PM EDT Miguel Landaeta wrote:
> On Fri, Aug 30, 2019 at 07:27:39AM +, Matthias Klose wrote:
> > Package: src:namebench
> > Version: 1.3.1+dfsg-2
> > Severity: normal
> > Tags: sid bullseye
> > User: debian-pyt...@lists.debian.org
> > Usertags: py2removal
> > 
> > [...]
> > 
> > - Convert your Package to Python3. This is the preferred option.  In
> > 
> >   case you are providing a Python module foo, please consider dropping
> >   the python-foo package, and only build a python3-foo package.  Please
> >   don't drop Python2 modules, which still have reverse dependencies,
> >   just document them.
> >   
> >   This is the preferred option.
> 
> Not gonna happen.
> 
> > - If the package is dead upstream, cannot be converted or maintained
> > 
> >   in Debian, it should be removed from the distribution.  If the
> >   package still has reverse dependencies, raise the severity to
> >   "serious" and document the reverse dependencies with the BTS affects
> >   command.  If the package has no reverse dependencies, confirm that
> >   the package can be removed, reassign this issue to ftp.debian.org,
> >   make sure that the bug priority is set to normal and retitle the
> >   issue to "RM: PKG -- removal triggered by the Python2 removal".
> 
> This package is technically dead upstream [1], although its upstream
> has been working in a rewrite in Go for 2.0 since several years ago [2].
> 
> > - If the package has still many users (popcon >= 300), or is needed to
> > 
> >   build another package which cannot be removed, document that by
> >   adding the "py2keep" user tag (not replacing the py2remove tag),
> >   using the debian-pyt...@lists.debian.org user.  Also any
> >   dependencies on an unversioned python package (python, python-dev)
> >   must not be used, same with the python shebang.  These have to be
> >   replaced by python2/python2.7 dependencies and shebang.
> >   
> >   This is the least preferred option.
> 
> namebench has a popcon >= 300 so I'm hesitant to file a RM bug for now.
> I leave it to DPMT to decide if this package should be removed or not.
> 
> I think this package is still useful but I don't care if the team
> decide it should be removed because python2 is EOL.

If the future is definitely not python3, I think it's better to remove it now 
(I've seen people criticize packages being removed shortly before release and 
I understand why, people don't have time to react).  It's easy enough to re-
introduce the package should a modernized version appear.

Scott K

Bug#936654: Info received (graphy: Python2 removal in sid/bullseye)

[Miguel Landaeta]

On Sun, Sep 1, 2019 at 7:42 PM Debian Bug Tracking System
 wrote:
>
> Thank you for the additional information you have supplied regarding
> this Bug report.
>
> This is an automatically generated reply to let you know your message
> has been received.
>
> Your message is being forwarded to the package maintainers and other
> interested parties for their attention; they will reply in due course.
>
> Your message has been sent to the package maintainer(s):
>  Debian Python Modules Team 
>
> If you wish to submit further information on this problem, please
> send it to 936...@bugs.debian.org.
>
> Please do not send mail to ow...@bugs.debian.org unless you wish
> to report a problem with the Bug-tracking system.
>
> --
> 936654: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=936654
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems



-- 
Miguel Landaeta, miguel at miguel.cc
secure email with PGP 0x6E608B637D8967E9 available at http://keyserver.pgp.com/
"Faith means not wanting to know what is true." -- Nietzsche

Bug#939161: gdm3: blank screen when booting without firmware-linux-nonfree

[Patrick Frank]

Package: gdm3
Version: 3.30.2-3
Severity: normal

Dear Maintainers,

after the install of the Gnome desktop (with non-free enabled repos) the
system seems to be stuck after the boot when GDM3 should take over. A blank
screen with a blinking cursor is showing instead.

I then switched to a Terminal via ALT+F2 and installed the package
firmware-linux-nonfree. As soon as the system detected the firmware
everything loaded as expected.


-- System Information:

CPU: Dual Core - model: AMD A6-7400K Radeon R5

Graphics: Advanced Micro Devices [AMD/ATI] Kaveri [Radeon R5 Graphics]


Debian Release: 10.0
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')

Architecture: amd64 (x86_64)

Foreign Architectures: i386

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

Bug#936654: graphy: Python2 removal in sid/bullseye

[Miguel Landaeta]

graphy should be kept or removed together with namebench.
Please see #937104 for more info.

-- 
Miguel Landaeta, nomadium at debian.org
secure email with PGP 0x6E608B637D8967E9 available at http://miguel.cc/key.
"Faith means not wanting to know what is true." -- Nietzsche


signature.asc
Description: PGP signature

Bug#937104: namebench: Python2 removal in sid/bullseye

[Miguel Landaeta]

On Fri, Aug 30, 2019 at 07:27:39AM +, Matthias Klose wrote:
> Package: src:namebench
> Version: 1.3.1+dfsg-2
> Severity: normal
> Tags: sid bullseye
> User: debian-pyt...@lists.debian.org
> Usertags: py2removal
> 
> [...]
> 
> - Convert your Package to Python3. This is the preferred option.  In
>   case you are providing a Python module foo, please consider dropping
>   the python-foo package, and only build a python3-foo package.  Please
>   don't drop Python2 modules, which still have reverse dependencies,
>   just document them.
>   
>   This is the preferred option.

Not gonna happen.

> 
> - If the package is dead upstream, cannot be converted or maintained
>   in Debian, it should be removed from the distribution.  If the
>   package still has reverse dependencies, raise the severity to
>   "serious" and document the reverse dependencies with the BTS affects
>   command.  If the package has no reverse dependencies, confirm that
>   the package can be removed, reassign this issue to ftp.debian.org,
>   make sure that the bug priority is set to normal and retitle the
>   issue to "RM: PKG -- removal triggered by the Python2 removal".

This package is technically dead upstream [1], although its upstream
has been working in a rewrite in Go for 2.0 since several years ago [2].

> 
> - If the package has still many users (popcon >= 300), or is needed to
>   build another package which cannot be removed, document that by
>   adding the "py2keep" user tag (not replacing the py2remove tag),
>   using the debian-pyt...@lists.debian.org user.  Also any
>   dependencies on an unversioned python package (python, python-dev)
>   must not be used, same with the python shebang.  These have to be
>   replaced by python2/python2.7 dependencies and shebang.
> 
>   This is the least preferred option.

namebench has a popcon >= 300 so I'm hesitant to file a RM bug for now.
I leave it to DPMT to decide if this package should be removed or not.

I think this package is still useful but I don't care if the team
decide it should be removed because python2 is EOL.



1. https://code.google.com/archive/p/namebench/
2. https://github.com/google/namebench
3. https://qa.debian.org/popcon.php?package=namebench

-- 
Miguel Landaeta, nomadium at debian.org
secure email with PGP 0x6E608B637D8967E9 available at http://miguel.cc/key.
"Faith means not wanting to know what is true." -- Nietzsche


signature.asc
Description: PGP signature

Bug#936436: marked as done (dolfin: Python2 removal in sid/bullseye)

[Graham Inggs]

Hi Drew

> From: Drew Parsons 
> To: 936436-d...@bugs.debian.org
> Cc:
> Bcc:
> Date: Sun, 01 Sep 2019 23:00:50 +0800
> Subject: Re: #936436 dolfin: Python2 removal in sid/bullseye
> > Your package either build-depends, depends on Python2, or uses Python2
> in the autopkg tests.
>
>
> No it doesn't.--

The control file of dolfin-bin_2019.1.0-4_all.deb contains "Depends:
python:any", see below.

Regards
Graham


Package: dolfin-bin
Source: dolfin
Version: 2019.1.0-4
Architecture: all
Maintainer: Debian Science Team

Installed-Size: 83
Depends: python3-dolfin (>= 2019.1.0-4), python3-numpy, python3:any, python:any
Section: math
Priority: optional
Homepage: http://fenicsproject.org
Description: Executable scripts for DOLFIN
 DOLFIN is the Python and C++ interface of the FEniCS project for the
 automated solution of differential equations, providing a consistent
 PSE (Problem Solving Environment) for solving ordinary and partial
 differential equations. Key features include a simple, consistent and
 intuitive object-oriented API; automatic and efficient evaluation of
 variational forms; automatic and efficient assembly of linear
 systems; and support for general families of finite elements.
 .
 This package contains executable scripts for DOLFIN.

Bug#935753: FATAL:memory_linux.cc Out of memory

[積丹尼 Dan Jacobson]

MG> Can you figure out which library it was?  A serious bug needs to be
MG> filed against it.

Should be simple. On a fresh machine try something like
$ sudo apt -o "APT::Default-Release experimental;" install chromium
$ chromium

I've had enough with experimental for now.

Bug#939160: grub-efi-amd64-signed: not installable, broken dependencies

[Matteo F. Vescovi]

Package: grub-efi-amd64-signed
Version: 1+2.04+2
Severity: grave
Justification: renders package unusable

Hi!

While trying to enable Secure Boot on my laptop installing mandatory
packages, I faced this:

 $ sudo apt install grub-efi-amd64-signed
 Reading package lists... Done
 Building dependency tree   
 Reading state information... Done
 Some packages could not be installed. This may mean that you have
 requested an impossible situation or if you are using the unstable
 distribution that some required packages have not yet been created
 or been moved out of Incoming.
 The following information may help to resolve the situation:

 The following packages have unmet dependencies:
  grub-efi-amd64-signed : Depends: grub-common (= 2.04-2) but 2.04-3 is to be 
installed
 E: Unable to correct problems, you have held broken packages.

Thanks for the efforts spent fixing it.

Cheers.


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

Kernel: Linux 5.2.0-2-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages grub-efi-amd64-signed depends on:
ii  grub-common  2.04-3

Versions of packages grub-efi-amd64-signed recommends:
ii  shim-signed  1.33+15+1533136590.3beb971-7

grub-efi-amd64-signed suggests no packages.


signature.asc
Description: PGP signature

Bug#818008: How to proceed

[Lee Garrett]

Closing due to inactivity. Feel free to re-open if you would like to
challenge the assessment below.

On Tue, 16 Oct 2018 15:46:25 +0200 Lee Garrett  wrote:
> Hi Geert, hi Raphael,
> 
> personally, I think that the Debian package should stop shipping
> /etc/ansible/{ansible.cfg, hosts} alltogether. The reason is that those files
> have a systemwide affect, and can only be edited by root. The former is
> problematic if you have several projects, in that case you'd just ship a
> ansible.cfg and hosts file within each project. Both those files can be edited
> by the local user. For that reason I think adding debconf questions for that
> is the wrong approach. But if you really want systemwide hosts and ansible
> config, you can still template those with ansible. :)
> 
> What are you thoughts on this?
> 
> Greets,
> Lee
> 
> 
> 
> On Sun, 14 Oct 2018 14:09:23 +0200 Geert Stappers  wrote:
> > 
> > Found today this bugreport ( 
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=818008 )
> > even with a patch.
> > 
> > To find out if it stills applies there is now 
> > https://salsa.debian.org/stappers/ansible
> > which has branch 'br818008patch'.
> > 
> > Difference with 
> > https://github.com/rmedaer/ansible-debian-pkg/commit/7fa153bdcc368fad2c3dc8701fe4a8aa73c80d08
> > is that updating debian/changelong is skipped. If all goes well,
> > is @rmedaer the author of the commit.
> > 
> > 
> > However, the question is what to do next?
> > 
> > Would it make sense to have the patch also here in the Debian BTS?
> > 
> > Should Ansible be configurable by debconf?
> > 
> > 
> > Groeten
> > Geert Stappers
> > -- 
> > Leven en laten leven
> > 
> > 
> 
> 

Bug#935753: FATAL:memory_linux.cc Out of memory

[Michael Gilbert]

control: reopen -1
control: tag -1 - moreinfo

On Sat, Aug 31, 2019 at 9:57 AM Dan Jacobson wrote:
>
> MG> Could you try this again without packages from experimental?  I assume
> MG> its caused by the update to libc6 2.29?
>
> Some other one. So now I use pure sid. Problem solved.

Can you figure out which library it was?  A serious bug needs to be
filed against it.

Best wishes,
Mike

Bug#939159: dbconfig-common: [INTL:fr] French debconf templates translation

[Jean-Pierre Giraud]

Package: dbconfig-common
Severity: wishlist
Tags: patch l10n

Hi!

Please find attached the french debconf templates translation updated,
proofread
by the debian-l10n-french mailing list contributors.

This file should be put as debian/po/fr.po in your package build tree.

Kind Regards

jipege



fr.po.gz
Description: application/gzip

Bug#934877: chm2pdf: Please port to Python 3 (and drop python-chm dep)

[Sandro Tosi]

> Hello, please port chm2pdf to Python3 and/or drop the python 2
> package. This will help the goal of removing Python 2 from Debian,
> and would also (more immediately) allow to remove packages currently
> dependencies of this one.

I tried a brutal port to py3k: 2to3 + fixing some encoding/decoding
issue + port to html.parser but chm2pdf is still not working. not sure
it's worth the effort, so i'm gonna go ahead and ask for its removal
(replying here to leave some info if someone will pick up the work)
--- a/chm2pdf
+++ b/chm2pdf
@@ -1,4 +1,4 @@
-#!/usr/bin/python
+#!/usr/bin/python3
 '''
 CHM2PDF v. 0.9.1
 http://code.google.com/p/chm2pdf
@@ -23,7 +23,7 @@ A script that converts a CHM compiled HT
 
 import chm.chm as chm
 import sys
-import sgmllib
+import html.parser
 import os, os.path
 import re, glob
 import getopt
@@ -49,13 +49,13 @@ CHM2PDF_TEMP_ORIG_DIR=tempfile.mkdtemp()
 # YOU DON'T NEED TO CHANGE ANYTHING BELOW THIS LINE!
 
 
-class PageLister(sgmllib.SGMLParser):
+class PageLister(html.parser.HTMLParser):
 '''
 parser of the chm.chm GetTopicsTree() method that retrieves the URL of the HTML
 page embedded in the CHM file.
 '''
 def reset(self):
-sgmllib.SGMLParser.reset(self)
+html.parser.HTMLParser.reset(self)
 self.pages=[]
 
 def start_param(self,attrs):
@@ -66,12 +66,12 @@ class PageLister(sgmllib.SGMLParser):
if urlparam_flag and key=='value':
self.pages.append('/'+value)  
  
-class ImageCatcher(sgmllib.SGMLParser):
+class ImageCatcher(html.parser.HTMLParser):
 '''
 finds image urls in the current html page, so to take them out from the chm file.
 '''
 def reset(self):
-sgmllib.SGMLParser.reset(self)
+html.parser.HTMLParser.reset(self)
 self.imgurls=[]
 
 def start_img(self,attrs):
@@ -81,12 +81,12 @@ class ImageCatcher(sgmllib.SGMLParser):
 if not self.imgurls.count(value):
 self.imgurls.append(value)
  
-class CssCatcher(sgmllib.SGMLParser):
+class CssCatcher(html.parser.HTMLParser):
 '''
 finds CSS urls in the current html page, so to take them out from the chm file.
 '''
 def reset(self):
-sgmllib.SGMLParser.reset(self)
+html.parser.HTMLParser.reset(self)
 self.cssurls=[]
 
 def start_link(self,attrs):
@@ -101,7 +101,7 @@ def get_html_list(cfile):
 retrieves the list of HTML files contained into the CHM file, **in order** (that's the important bit).
 (actually performed by the PageLister class)
 '''
-topicstree=cfile.GetTopicsTree()
+topicstree=cfile.GetTopicsTree().decode('utf-8', errors='replace')
 lister=PageLister()
 lister.feed(topicstree)
 #print 'lister pages',lister.pages
@@ -338,10 +338,10 @@ def convert_to_pdf(cfile, filename, outp
 output_titlefile = CHM2PDF_WORK_DIR + os.sep + options['titlefile']
 
 if not options['titlefile']=='' and not output_titlefile:
-print '### WARNING: ' + options['titlefile'] + ' not found inside ' + filename + ' - possible spelling error.'
-print '### You can check it if you do  \'' + sys.argv[0] + ' --extract-only\','
-print '### then have a look at the files in  ' + CHM2PDF_ORIG_DIR + '.'
-print '### Option \'--titlefile ' + options['titlefile'] + '\' ignored'
+print('### WARNING: ' + options['titlefile'] + ' not found inside ' + filename + ' - possible spelling error.')
+print('### You can check it if you do  \'' + sys.argv[0] + ' --extract-only\',')
+print('### then have a look at the files in  ' + CHM2PDF_ORIG_DIR + '.')
+print('### Option \'--titlefile ' + options['titlefile'] + '\' ignored')
 options['titlefile'] = ''
 
 
@@ -373,7 +373,7 @@ def convert_to_pdf(cfile, filename, outp
 page_filename = re.sub('%20',' ',page_filename)
 
 if options['verbose']=='--verbose' and options['verbositylevel']=='high' and options['dontextract'] == '':
-print "Correcting " + page_filename
+print("Correcting " + page_filename)
 
  
 if os.path.exists(page_filename) and (options['titlefile'] == '' or not options['titlefile'] in url):
@@ -425,25 +425,25 @@ def convert_to_pdf(cfile, filename, outp
 if options['dontextract'] == '':
 # Correct links to files in the local collection.
 if options['verbose']=='--verbose' and options['verbositylevel']=='low':
-print 'Correcting links in the HTML files...'
+print('Correcting links in the HTML files...')
 
 if options['verbose']=='--verbose' and options['verbositylevel']=='high':
-print '### 1st pass ###'
+print('### 1st pass ###')
 for match_string in  match_strings:
 replace_string = replace_garbled_strings[match_strings.index(match_string)]
 if 

Bug#939022: [#939022] Re: pyresample: autopkgtest failure with PROJ 6 (epsg data file removed)

[Sebastiaan Couwenberg]

On 9/1/19 7:44 PM, Antonio Valentino wrote:
> It seems that the problem can be fixed by upgrading pyproj to v2.3.1
> (see [2]).
> I made a quick test with python3-pyproj 2.3.1+ds-1~exp1 (available in
> experimental) and I can confirm that all tests pass now.
> 
> I'm going to add a versioned dependency in pyresample but the upload can
> only happen once pyproj 2.3.1 is available in unstable.

As that was only uploaded today, I'm waiting for more builds to succeed.

Since the autopkgtest failures are likely going to block testing
migration of proj and the rdeps rebuilt for the transition. I'm
considering move proj 6.2.0 & pyproj 2.3.1 to unstable in the next few
days, but I'm first going to wait for the aging of the packages uploaded
during the transition. If the migration doesn't happen then, I'll upload
to unstable.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Bug#939022: [#939022] Re: pyresample: autopkgtest failure with PROJ 6 (epsg data file removed)

[Antonio Valentino]

Hi Sebastiaan,
after the workaround committed in [1], remaining issues are:

==
ERROR: test_create_area_def
(pyresample.test.test_geometry.TestStackedAreaDefinition)
Test create_area_def and the four sub-methods that call it in
AreaDefinition.
--
Traceback (most recent call last):
  File
"/home/antonio/debian/git/pyresample/pyresample/test/test_geometry.py",
line 1657, in test_create_area_def
radius=essentials[1], description=description, units=units,
rotation=45))
  File "/home/antonio/debian/git/pyresample/pyresample/area_config.py",
line 444, in create_area_def
center = _convert_units(center, 'center', units, p, proj_dict)
  File "/home/antonio/debian/git/pyresample/pyresample/area_config.py",
line 577, in _convert_units
var = _round_poles(var, units, p)
  File "/home/antonio/debian/git/pyresample/pyresample/area_config.py",
line 517, in _round_poles
center = p(*center, inverse=True, errcheck=True)
  File "/home/antonio/debian/git/pyresample/pyresample/_spatial_mp.py",
line 157, in __call__
radians=radians, errcheck=errcheck)
  File "/usr/lib/python3/dist-packages/pyproj/proj.py", line 183, in
__call__
self._inv(inx, iny, errcheck=errcheck)
  File "pyproj/_proj.pyx", line 165, in pyproj._proj.Proj._inv
pyproj.exceptions.ProjError: generic error of unknown origin: (Internal
Proj Error: proj_crs_get_sub_crs: Object is not a CompoundCRS)

==
ERROR: test_area_parser_yaml (pyresample.test.test_utils.TestYAMLAreaParser)
Test YAML area parser.
--
Traceback (most recent call last):
  File
"/home/antonio/debian/git/pyresample/pyresample/test/test_utils.py",
line 96, in test_area_parser_yaml
'test_latlong')
  File "/home/antonio/debian/git/pyresample/pyresample/area_config.py",
line 104, in parse_area_file
return _parse_yaml_area_file(area_file_name, *regions)
  File "/home/antonio/debian/git/pyresample/pyresample/area_config.py",
line 157, in _parse_yaml_area_file
res.append(create_area_def(**params))
  File "/home/antonio/debian/git/pyresample/pyresample/area_config.py",
line 444, in create_area_def
center = _convert_units(center, 'center', units, p, proj_dict)
  File "/home/antonio/debian/git/pyresample/pyresample/area_config.py",
line 577, in _convert_units
var = _round_poles(var, units, p)
  File "/home/antonio/debian/git/pyresample/pyresample/area_config.py",
line 517, in _round_poles
center = p(*center, inverse=True, errcheck=True)
  File "/home/antonio/debian/git/pyresample/pyresample/_spatial_mp.py",
line 157, in __call__
radians=radians, errcheck=errcheck)
  File "/usr/lib/python3/dist-packages/pyproj/proj.py", line 183, in
__call__
self._inv(inx, iny, errcheck=errcheck)
  File "pyproj/_proj.pyx", line 165, in pyproj._proj.Proj._inv
pyproj.exceptions.ProjError: generic error of unknown origin: (Internal
Proj Error: proj_crs_get_sub_crs: Object is not a CompoundCRS)


It seems that the problem can be fixed by upgrading pyproj to v2.3.1
(see [2]).
I made a quick test with python3-pyproj 2.3.1+ds-1~exp1 (available in
experimental) and I can confirm that all tests pass now.

I0m going to add a versioned dependency in pyresample but the upload can
only happen once pyproj 2.3.1 is available in unstable.

There seems to be still some warning regarding proj initialization but
as far as I can understand there is some activity upstream on this front
so I think all details will be fully fixed in the next upstream version
of pyresample.


[1]
https://salsa.debian.org/debian-gis-team/pyresample/commit/55eab16e711ff56bac48aee6920840d8ff6e86f0
[2] https://github.com/pyproj4/pyproj/issues/413


kind regards
antonio

On Sun, 1 Sep 2019 17:48:01 +0200 Antonio Valentino
 wrote:
> Hi Sebastiaan,
> I have a workaround for the basemap issue but there are still a couple
> of tests failing.
> 
> cheers
> antonio
> 
> Il 01/09/19 15:05, Sebastiaan Couwenberg ha scritto:
> > On 8/31/19 7:14 PM, Sebastiaan Couwenberg wrote:
> >>> I'm going to reassign.
> >>
> >> That doesn't seem appropriate, pyresample needs to be updated too. It
> >> does things like this:
> >>
> >>  pyresample/test/test_geometry.py:
> >> projections = {'+init=epsg:3006': 'init: epsg:3006'}
> >>
> >> Note the explicit use of init files, this is not going to work correctly
> >> with PROJ 6.
> > 
> > As sort term workaround may be to skip these tests when
> > /usr/share/proj/epsg doesn't exist (or when /usr/share/proj/proj.db does
> > exist).
> > 
> > Kind Regards,
> > 
> > Bas
> > 
> 
> -- 
> Antonio Valentino
> 
> 

-- 
Antonio Valentino

Bug#923510: Temporarily worked around via redirect

[Don Armstrong]

Control: severity -1 important

I've fixed this issue in the devel branch, but that required a ton of
other changes, so it is waiting for a new release of Debbugs.

In the meantime, I've put in a rewrite proxy rule to switch this
particular request to the devel branch so it should "work" seamlessly.

I've downgraded the severity because of the workaround, but the
underlying issue will still be present until I release the new version
of Debbugs.


-- 
Don Armstrong  https://www.donarmstrong.com

2: There is no out. There is only in.
  -- "The Prisoner (2009 Miniseries)"

Bug#939158: nstreams FTCBFS: uses the build architecture compiler

[Helmut Grohne]

Source: nstreams
Version: 1.0.4-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

nstreams fails to cross build from source, because it uses the build
architecture compiler. That is even though it uses dh_auto_configure and
thus passes --host and correctly detecting the host architecture,
configure happens to use plain "gcc". Exporting a suitable CC fixes
that. Please consider applying the attached patch.

Helmut
diff -u nstreams-1.0.4/debian/changelog nstreams-1.0.4/debian/changelog
--- nstreams-1.0.4/debian/changelog
+++ nstreams-1.0.4/debian/changelog
@@ -1,3 +1,10 @@
+nstreams (1.0.4-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Let dpkg's buildtools.mk supply a CC to configure. (Closes: 
#-1)
+
+ -- Helmut Grohne   Sat, 31 Aug 2019 20:56:33 +0200
+
 nstreams (1.0.4-1) unstable; urgency=medium
 
   * New upstream version
diff -u nstreams-1.0.4/debian/rules nstreams-1.0.4/debian/rules
--- nstreams-1.0.4/debian/rules
+++ nstreams-1.0.4/debian/rules
@@ -1,5 +1,8 @@
 #!/usr/bin/make -f
 
+-include /usr/share/dpkg/buildtools.mk
+export CC
+
 %:
dh $@ --with autotools_dev
 

Bug#925473: tomcat9: sysvinit script missing (Policy §9.11¶2 “must”)

[Thorsten Glaser]

Version: 9.0.24-1


Emmanuel,

> What is the issue with the dependency on systemd? I was under the

there is new data related to that:

In bullseye/sid, there’s elogind as desktop/logind alternative that
implements the logind API but does not otherwise try to take over
the system, allowing other inits (sysvinit, openrc, runit, …) to be
used, and it does not carry systemd-sysusers either.

More importantly, elogind Conflicts with systemd (both to ensure it
is not confused for systemd or accidentally installed and because it
implements only a subset necessary for the desktop stuff and network-
manager, which I’ve seen people even use for servers nowadays).

This makes it even more important that tomcat9 can be used without
a dependency on the systemd binary package. I’m updating the sysvinit
branch and testing it; can we please merge it into master and upload
to unstable once it has been tested (should be no problem, I already
tested it before, and the diff to 9.0.24-1 is minimal)?

This would also allow buster-backports to be used without systemd,
which is better than not at all.

Thanks,
//mirabilos
-- 
13:22⎜«neurodamage» mira, what's up man? I have a CVS question for you in #cvs
13:22⎜«neurodamage» since you're so good w. it │ «neurodamage:#cvs» i love you
13:28⎜«neurodamage:#cvs» you're a handy guy to have around for systems stuff ☺
16:06⎜ Thank god I found you =)   20:03│«bioe007:#cvs» mira2k: ty

Bug#939117: grilo-plugins: Python2 removal in sid/bullseye -- drop python-dbusmock build dependency

[Alberto Garcia]

Control: tags -1 pending

On Sun, Sep 01, 2019 at 01:02:57PM +0200, Martin Pitt wrote:

> Your package build-depends on python-dbusmock. Please convert the
> package to Python 3 and use python3-dbusmock instead. This is the
> only reverse (build)-depends of python-dbusmock, and thus blocks its
> removal.

Thanks Martin,

I noticed this a few weeks ago and I already had a patch removing this
build dependency, I was just waiting for the next upstream release.

If you don't mind waiting I'll do it then (we can set a deadline to
make sure that it doesn't take too long). But if you prefer to have it
done now I can take care of it later today or tomorrow, no problem for
me.

Berto

Bug#821130: debhelper: circular dependency with dh-autoreconf/dh-strip-nondeterminism

[Sven Joachim]

On 2016-04-15 21:57 +0200, Bill Allombert wrote:

> Package: debhelper
> Version: 9.20160403
> Severity: important
>
> Hello debhelper maintainers,
>
> There is a circular dependency between debhelper, dh-autoreconf and 
> dh-strip-nondeterminism:
>
> debhelper :Depends: dh-strip-nondeterminism, dh-autoreconf (>= 12~)
> dh-autoreconf :Depends: debhelper
> dh-strip-nondeterminism   :Depends: debhelper
>
> Circular dependencies are known to cause problems during upgrade, so we
> should try to avoid them.

The severity of this bug has been downgraded to minor by the maintainer,
which seems fair as the circular dependencies are unlikely to actually
cause problems.

Nevertheless, perhaps it is a good idea to split the debhelper perl
modules off to a libdebhelper-perl package.  Then addons like
dh-autoreconf and dh-strip-nondeterminism can depend on
libdebhelper-perl rather than debhelper.  This does not only break the
circular dependency, but also gives a better idea which packages that
currently depend on debhelper need the commands and which need the perl
modules.  After all, some day debhelper might be rewritten in
Python. ;-)

I have created a branch for the package split on salsa[1], assuming that
12.6 would the version where the split occurs.  If the debhelper
maintainer thinks this is a good idea, I can send a merge request.
Otherwise, tagging the bug as wontfix looks reasonable.

Cheers,
   Sven


1. https://salsa.debian.org/joachim-guest/debhelper/tree/libdebhelper-perl

Bug#939145: blender Version:2.80+dfsg-3 CPU opencl not working in combo with video card

[Matteo F. Vescovi]

Hi!

On 2019-09-01 at 16:18 (+02), claudio castelli wrote:
> Package:blender
> Version:2.80+dfsg-3
>
> Hello, I have an old dual xeon x5670 setup working with amd rx480,
> running
> debian testing buster , cinnamon desktop.

Please, follow up this bug report with the output of reportbug because
it adds important info to the basic info provided by the submitter.

Thanks.


-- 
Matteo F. Vescovi || Debian Developer
GnuPG KeyID: 4096R/0x8062398983B2CF7A


signature.asc
Description: PGP signature

Bug#935390: RFS: vnstat/2.4-0.1 [NMU]

[Rob Savoury]

Addendum to the most recent submission of the vnstat package (2.4-0.1)
to mentors is that the correct Vcs path for this particular build is a
fork of the vnstat repo maintained by Christian Göttsche, with the repo
for this mentors submitted build being:

https://salsa.debian.org/savoury1-guest/vnstat

Bug#939157: apt: package apt should depend on package dirmngr

[Martin Monperrus]

Package: apt
Version: 1.8.3
Severity: normal

Dear Maintainer,

When dirmngr is not installed, one gets the following error with apt-key.

$ apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 7EA0A9C3F273FCD8

Executing: /tmp/apt-key-gpghome.RXG41FeS1W/gpg.1.sh --keyserver
keyserver.ubuntu.com --recv-keys 7EA0A9C3F273FCD8
gpg: failed to start the dirmngr '/usr/bin/dirmngr': No such file or directory
gpg: connecting dirmngr at '/tmp/apt-key-gpghome.RXG41FeS1W/S.dirmngr' failed:
No such file or directory
gpg: keyserver receive failed: No dirmngr

To solve this, package apt should depend on package dirmngr.

Best regards, --Martin





-- Package-specific info:

-- (no /etc/apt/preferences present) --


-- (no /etc/apt/preferences.d/* present) --


-- (/etc/apt/sources.list present, but not submitted) --


-- (/etc/apt/sources.list.d/skype-stable.list present, but not submitted) --


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

Kernel: Linux 5.2.0-2-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_CRAP, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages apt depends on:
ii  adduser 3.118
ii  debian-archive-keyring  2019.1
ii  gpgv2.2.17-3
ii  libapt-pkg5.0   1.8.3
ii  libc6   2.28-10
ii  libgcc1 1:9.2.1-4
ii  libgnutls30 3.6.9-4
ii  libseccomp2 2.4.1-2
ii  libstdc++6  9.2.1-4

Versions of packages apt recommends:
ii  ca-certificates  20190110

Versions of packages apt suggests:
pn  apt-doc 
ii  aptitude0.8.12-1
ii  dpkg-dev1.19.7
ii  gnupg   2.2.17-3
ii  gnupg2  2.2.17-3
ii  powermgmt-base  1.36
ii  synaptic0.84.6+b1
ii  wajig   2.18.1

-- no debconf information

Bug#939156: RM: haskell-hastache -- ROM; obsolete, replaced by haskell-mustache

[Clint Adams]

Package: ftp.debian.org
Severity: normal

haskell-hastache has no more reverse dependencies, is unbuildable, and is
obsoleted by haskell-mustache

Bug#935485: Looking for help with a recently removed package, kcollectd

[Antonio Russo]

Thanks for looking at the package!  I've corrected the missing build 
dependencies,
and cleaned up the debian directory a bit, as you suggested.

I've changed the maintainer to be Qt/KDE, and changed my role to uploader (and
I've added you there as well, is that appropriate?).

The uploaded package was built by pbuilder.

Thanks,
Antonio

On 9/1/19 6:44 AM, Sandro Knauß wrote:
> Hey,
> 
> I can sponser you. But I can't build kcollectd pacakge from salsa[0]. It 
> looks 
> like you missing some dependencies from building.
> 
> Feel free to ping me, if you have any questions and, when the package is 
> ready 
> to review.
> 
> * you can remove the debian/patches directory completly, when there are no 
> patches to apply.
> 
> Additionally you list yourself as Maintainer, that is fine. Do you want to be 
> part of Qt/KDE team and shift the maintainership to Qt/KDE team? This gives 
> other members of the team the possibility to touch the package and maybe to a 
> release, if needed...
> 
> hefee
> 
> [0] https://salsa.debian.org/aerusso-guest/kcollectd/
> 
> On Sonntag, 1. September 2019 00:54:16 CEST Antonio Russo wrote:
>> Hello everyone,
>>
>> I am looking for a new home for kcollectd, a tool for viewing log
>> information, that was recently removed from unstable because it lacked a Qt
>> 5 port [1]. I have ported that package and I've taken over the upstream
>> (which has been dead for years) [2].  I'm offering to maintain the Debian
>> package, and I've been directed here, at the suggestion of another DD,
>> because this community may have interest in helping out with this package.
>>
>> Of note, I spoke with Scott Kitterman, who requested the removal of
>> kcollectd, and he said he knows of no other reason the package should be
>> removed.
>>
>> The updated packaging fixes several outstanding bugs, and makes the Debian
>> lintian report much cleaner (one is, I believe, a false positive, and the
>> other is due to lack of package tests which aren't really relevant to this
>> kind of UI software).
>>
>> Is anyone here willing to sponsor this package, offer any criticism of
>> the package, or further direct me to a place where I might get such help?
>>
>> Thank you,
>> Antonio Russo
>>
>> [1] https://bugs.debian.org/935223
>> [2] https://gitlab.com/aerusso/kcollectd
>> [3] https://bugs.debian.org/935485
> 

Bug#939155: libgnustep-gui0.27: Uses GifQuantizeBuffer - binary stops working with newer giflib

[Andreas Metzler]

Source: libgnustep-gui0.27
Version: 0.27.0-5
Severity: important

Hello,

this package uses GifQuantizeBuffer() from giflib. The symbol has been
dropped in giflib 5.2 (libgif-dev/libgif7 5.2.1 is available in
experimental) and therefore the package 
a) stops working when the gif library package is upgraded and
b) if built against libgif-dev >= 5.2 then GIF support is
disabled/limited.

I do not think giflib did the right thing by dropping the symbol without
a soname bump but that is beside the point.[1] Even with the correct way
(giflib soname bump) this package loses gif support. I am quite confident
that GifQuantizeBuffer() will not be reintroduced - It was ripped out to
"reduce libgif size and attack surface".

I am reporting this /now/ with severity important, but please treat it
as rc issue.

cu Andreas

[1] I have suggested to upstream to do a soname bump. If this is not
accepted we will probably end up with newer libgif7 having a Breaks for
GifQuantizeBuffer()-using-software.


checking for QuantizeBuffer... no
checking for GifQuantizeBuffer... no

Bug#925782: Patch for bug 925782

[Joachim Reichel]

tag 925782 + patch
thanks

Hi,

attached is a patch that fixes the FTBFS with g++-9.

Best regards,
  Joachim
Index: mp3check-0.8.7/texception.h
===
--- mp3check-0.8.7.orig/texception.h
+++ mp3check-0.8.7/texception.h
@@ -38,10 +38,10 @@ extern "C" {

 #define TExceptionN(n) public: virtual const char *name()  const { return #n; }
 #define TExceptionM(m) public: virtual const char *message() const { return m; }
-#define TExceptionM1(m,a) public: virtual const char *message() const { char *buf; asprintf(, m, a); return buf; }
-#define TExceptionM2(m,a,b) public: virtual const char *message() const { char *buf; asprintf(, m, a,b); return buf; }
-#define TExceptionM3(m,a,b,c) public: virtual const char *message() const { char *buf; asprintf(, m, a,b,c); return buf; }
-#define TExceptionM4(m,a,b,c,d) public: virtual const char *message() const { char *buf; asprintf(, m, a,b,c,d); return buf; }
+#define TExceptionM1(m,a) public: virtual const char *message() const { char *buf; int result = asprintf(, m, a); return result != -1 ? buf : "asprintf failure"; }
+#define TExceptionM2(m,a,b) public: virtual const char *message() const { char *buf; int result = asprintf(, m, a,b); return result != -1 ? buf : "asprintf failure"; }
+#define TExceptionM3(m,a,b,c) public: virtual const char *message() const { char *buf; int result = asprintf(, m, a,b,c); return result != -1 ? buf : "asprintf failure"; }
+#define TExceptionM4(m,a,b,c,d) public: virtual const char *message() const { char *buf; int result = asprintf(, m, a,b,c,d); return result != -1 ? buf : "asprintf failure"; }

 // base class of all exceptions
 class TException {
Index: mp3check-0.8.7/tstring.cc
===
--- mp3check-0.8.7.orig/tstring.cc
+++ mp3check-0.8.7/tstring.cc
@@ -111,7 +111,7 @@ tstring::Rep *tstring::Rep::clone(size_t
 tstring::Rep *tstring::Rep::create(size_t tmem) {
size_t m = sizeof(Rep) << 1;
while((m - 1 - sizeof(Rep)) < tmem) m <<= 1;
-   Rep *p = new (m - 1 - sizeof(Rep)) Rep;
+   Rep *p = new (/*tag*/ true, m - 1 - sizeof(Rep)) Rep;
p->mem = m - 1 - sizeof(Rep); p->ref = 1; p->vulnerable = false;
return p;
 }
Index: mp3check-0.8.7/tstring.h
===
--- mp3check-0.8.7.orig/tstring.h
+++ mp3check-0.8.7/tstring.h
@@ -71,9 +71,12 @@ class tstring {

   // static methods
   // operator new for this class
-  static void * operator new (size_t size, size_t tmem) {
+  // add a tag parameter to ensure that the signature of the delete operator does not collide with the (void*,size_t) overload
+  static void * operator new (size_t size, bool /*tag*/, size_t tmem) {
 	 return ::operator new (size + tmem + 1);}
-  static void operator delete (void *p, size_t) {
+  static void operator delete (void *p, bool /*tag*/, size_t) {
+	 ::operator delete (p); }
+  static void operator delete (void *p) {
 	 ::operator delete (p); }

   // create a new representation

Bug#929829: [Pkg-javascript-devel] Bug#929829: Bug#929829: gulp 4 cannot build node-babel 7 - Cannot convert undefined or null to object

[Pirate Praveen]

On Sun, Sep 1, 2019 at 9:15 PM, Pirate Praveen 
 wrote:
And fancy-log package.json wants chalk ^1.1.1 and we have chalk 2.4.2 
which to me looks like a possible culprit.


This was a false positive, I suspect 
debian/patches/update-process-nextick-args.patch is not correct.

Bug#939154: lyx-common: convertDefault.py will not work with Python3

[Georges Khaznadar]

Package: lyx-common
Version: 2.3.3-1
Severity: important
Tags: patch

Dear Maintainer,

I was porting one of my packages (pycode-browser) from Python2
to Python3, in order to close the bug report #937407 filed by
Matthias Klose, "Python2 removal in sid/bullseye".

The build raised a series of errors, due to the script
convertDefault.py, which is not properly ported to Python3:

--- for example---8<---
support/Systemcall.cpp (276): Systemcall: 'python3 -tt
"/usr/share/lyx/scripts/convertDefault.py" png
"/tmp/lyx_tmpdir.SihlAXIKJELT/lyx_tmpbuf0/47_home_georgesk_developpement_pycode-
browser_collab_pycode-browser_pybooksrc_pics_lsfit.png" eps
"/tmp/lyx_tmpdir.SihlAXIKJELT/lyx_tmpbuf0/47_home_georgesk_developpement_pycode-
browser_collab_pycode-browser_pybooksrc_pics_lsfit.eps"' finished with exit
code 1
Traceback (most recent call last):
  File "/usr/share/lyx/scripts/convertDefault.py", line 38, in 
output = output.decode()
AttributeError: 'str' object has no attribute 'decode'
-8<

The reason for this misbehavior is that either with Python2 or
with Python3, os.popen deals with 'str' data, never 'bytes' data.

So, lines 37 and 38 of the script must be erased.

Here is a short diff which fixes this issue:

---8<--
--- a/convertDefault.py 2019-09-01 18:16:59.833826411 +0200
+++ b/convertDefault.py 2019-09-01 18:18:38.622524626 +0200
@@ -33,9 +33,8 @@
 command = 'convert'
 fout = os.popen('convert -version 2>&1')
 output = fout.readline()
+# assert type(output)==type("") # os.popen deals with strings in Python3
 fout.close()
-if not PY2:
-output = output.decode()

 version = re_version.match(output)
 ---8<--

Best regards, Georges.



-- System Information:
Debian Release: 10.0
  APT prefers stable
  APT policy: (900, 'stable'), (499, 'testing'), (400, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_FR.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 lyx-common depends on:
ii  python3 3.7.3-1
ii  tex-common  6.11

Versions of packages lyx-common recommends:
ii  lyx  2.3.3-1

lyx-common suggests no packages.

-- debconf-show failed
--- a/convertDefault.py 2019-09-01 18:16:59.833826411 +0200
+++ b/convertDefault.py 2019-09-01 18:18:38.622524626 +0200
@@ -33,9 +33,8 @@
 command = 'convert'
 fout = os.popen('convert -version 2>&1')
 output = fout.readline()
+# assert type(output)==type("") # os.popen deals with strings in Python3
 fout.close()
-if not PY2:
-output = output.decode()
 
 version = re_version.match(output)
 

Bug#939097: [Debian-science-sagemath] Bug#939097: conway-polynomials needs to be pickled with Python 2 as long as sagemath uses Python 2

[Ximin Luo]

Do you know about 
https://salsa.debian.org/science-team/sagemath/merge_requests/12 ?

I was in the process of reviewing it but didn't finish it yet.

X

Tobias Hansen:
> I'm almost ready to upload sagemath 8.8. If you agree I could also just 
> revert commit f5187d87 of sagemath-database-conway-polynomialsand upload. 
> 
> Best,
> Tobias
> 
> On 9/1/19 11:45 AM, Tobias Hansen wrote:
>> Package: src:sagemath-database-conway-polynomials
>> Version: 0.5-6
>> Severity: important
>>
>> Hi Julien,
>>
>> I'm currently updating sagemath to version 8.8 and since version 0.5-5 
>> sagemath-database-conway-polynomials is pickled with Python 3 and is not 
>> compatible with Python 2 sagemath. Could you please revert to pickling with 
>> Python 2 until we update sagemath to Python 3? I want to start experimenting 
>> with Python 3 for sagemath soon but first I want to upload another working 
>> sagemath with Python 2.
>>
>> Best,
>> Tobias
>>
> 
> 
> ___
> Debian-science-sagemath mailing list
> debian-science-sagem...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-sagemath
> 


-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

Bug#935390: RFS: vnstat/2.4-1 [NMU] [ITA]

[Rob Savoury]

Package: sponsorship-requests
Severity: normal
Control: retitle 935390 RFS: vnstat/2.4-0.1 [NMU]

--

This package has been updated and is now passing Lintian, with thanks to
Christian Göttsche (great that he is back in action!) for pointing out
two small build issues.

--

Dear mentors,

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

 * Package name: vnstat
   Version : 2.4-0.1
   Upstream Author : Teemu Toivola 
 * URL : https://humdi.net/vnstat/
 * License : GPL-2
 * Vcs : https://salsa.debian.org/cgzones-guest/vnstat
   Section : net

It builds those binary packages:

  vnstat - console-based network traffic monitor
  vnstati - image output support for vnStat

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

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

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

  dget -x
https://mentors.debian.net/debian/pool/main/v/vnstat/vnstat_2.4-0.1.dsc

Changes since the last upload:

   * Non-maintainer upload
   * New upstream version 2.4
 - Image output has been refactored since 1.x versions (Closes: #692330)
 - Single database file avoids issue with new interfaces (Closes:
#749019)
 - There is no "--create" interface option in vnstat 2.x (Closes:
#881811)
 - Daemon in 2.x handles operations for if-up/down events (Closes:
#722534)
 - Daemon in 2.x automatically populates vnstat database (Closes:
#668969)
 - Better handling of integer rollover in kernel traffic counters
including
   auto-adjust of UpdateInterval based on MaxBandwidth (Closes: #804131)
 .
   * debian/
 - control: bump to Standards version 4.4.0 and compat level 12
   + add libsqlite3-dev build dependency (vnstat 2.x requirement)
 - patches/
   + drop timeout patch (fixed upstream) and rebase pidfile/systemd
patches
   + add systemd_man.diff to fix vnstatd man path due file move upstream
 - tests/
   + remove loopback test due no "--create" option with vnstat 2.x
   + add fulltest using similar commands upstream uses for build tests
 - copyright: update entries for maintainers in debian/* files paragraph
  and change upstream email to the correct current address

--

Regards,
Rob Savoury

Bug#935391: ITS: vnstat

[Rob Savoury]

Hi Christian,

Thank you for your message and very glad to hear that your personal
matters have been resolved sufficiently that you can continue with your
maintainership of vnstat (and also logrotate).

It has been an enjoyable couple of weeks of learning for me relative to
the art of packaging for Debian-based systems. My intention to become a
maintainer only began when Teemu (upstream dev of vnstat) wrote me back
in response to a bug report I sent him (about that vnstatd man page
issue) and mentioned that he'd had trouble getting in touch with you. So
that prompted me to "step in" and see if I could be of help.

If you are open to working as a team to maintain vnstat that would be
wonderful, as it would give me continued opportunities for learning and
collaboration relative to the whole matter of Debian packaging. If you
would like to ask for a shared repository then I would be very happy to
participate as a team member.

Also, thank you for the two technical notes you supplied about build
issues with vnstat. The past few days since my commits last Wednesday
have been busy with other packaging matters for Ubuntu-based systems,
however I have now done two new commits this morning for those issues
you mentioned and have uploaded a new NMU [1] to mentors. It seems to be
passing Lintian now, though with one small side comment about me not
being in the "Maintainers" or "Uploaders" field of debian/control.

Well, once again very glad you are back in action and I look forward to
the possibilities of collaboration on maintaining vnstat together.

Thanks,
Rob


[1] https://mentors.debian.net/package/vnstat


On 09/01/2019 05:14 AM, Christian Göttsche wrote:
> Hi Rob,
> 
> Thanks for taking interest in the vnStat Debian package.
> As I mentioned in the MIA thread, I was indisposed due to personal matters.
> 
> I appreciate your done work of packaging vnStat 2.4 and your ambition
> to become a maintainer.
> vnStat is a great tool I'm still using and I like to continue caring
> about the Debian package.
> Perhaps we could package vnStat together in a team, so we can support
> each other in matters of time and knowledge.
> 
> Technically I can ask for a shared repository
> salsa.debian.org/debian/vnstat with access for us and we need to
> update the Maintainer/Uploaders control field.
> 
> Regards,
>Christian Göttsche
> 
> 
> 
> p.s.:
> 
> While trying your package from
> https://salsa.debian.org/savoury1-guest/vnstat I noticed two issues:
> 
> * Due to the move of the vnstatd man page, the build fails, because
> the path is not updated in debian/vnstat.install
> * Lintian recommends adding "Pre-Depends: ${misc:Pre-Depends}" to
> debian/control (see
> https://lintian.debian.org/tags/skip-systemd-native-flag-missing-pre-depends.html)
>