Bug#946659: kopanocore: apparmor profile fails on Ubuntu because of /usr/sbin/ldconfig.real

[Carsten Schoenert]

Control: tags -1 pending

Hello Steve,

On Thu, Dec 12, 2019 at 02:33:00PM -0800, Steve Langasek wrote:
> Since 8.7.0-3, the autopkgtests for kopanocore have been failing in Ubuntu,
> due to an apparmor denial when kopano-search tries to access 
> /usr/sbin/ldconfig:
> 
> [413685.899592] audit: type=1400 audit(1576179514.224:92): apparmor="DENIED" 
> operation="open" profile="/usr/sbin/kopano-search" name="/usr/sbin/ldconfig" 
> pid=298626 comm="ldconfig" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
> 
> The reason for this is that ldconfig on Ubuntu is a wrapper script around 
> ldconfig.real.
> 
> The attached patch fixes the autopkgtest failure (and the subsequent runtime
> failures) on Ubuntu.  Please consider applying this in Debian.

thanks for the pointer, I've applied your provided patch.
Will get included within the next upload to unstable.

Regards
Carsten

Bug#946747: rust-buffered-reader: autopkgtest failure: no matching package named `bzip2` found

[Paul Gevers]

Source: rust-buffered-reader
Version: 0.11.0-1
Severity: serious
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: regression

Dear maintainers,

With a recent upload of rust-buffered-reader you added an autopkgtest to
rust-buffered-reader, great. However, it fails. I copied some of the
output at the bottom of this report.

Currently this regression is blocking the migration to testing [1]. Can
you please investigate the situation and fix it?

More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=rust-buffered-reader

https://ci.debian.net/data/autopkgtest/testing/amd64/r/rust-buffered-reader/3513209/log.gz

autopkgtest [03:58:52]: test command5:
/usr/share/cargo/bin/cargo-auto-test buffered-reader 0.12.0
--all-targets --features compression-deflate
autopkgtest [03:58:52]: test command5: [---
debian cargo wrapper: options, profiles, parallel: ['parallel=2'] [] ['-j2']
debian cargo wrapper: rust_type, gnu_type: x86_64-unknown-linux-gnu,
x86_64-linux-gnu
debian cargo wrapper: linking /usr/share/cargo/registry/* into
/tmp/tmp.3gOH0iUboN/registry/
debian cargo wrapper: options, profiles, parallel: ['parallel=2'] [] ['-j2']
debian cargo wrapper: rust_type, gnu_type: x86_64-unknown-linux-gnu,
x86_64-linux-gnu
debian cargo wrapper: running subprocess (['env', 'RUST_BACKTRACE=1',
'/usr/bin/cargo', '-Zavoid-dev-deps', 'test', '--verbose', '--verbose',
'-j2', '--target', 'x86_64-unknown-linux-gnu', '--all-targets',
'--features', 'compression-deflate'],) {}
error: no matching package named `bzip2` found
location searched: registry `https://github.com/rust-lang/crates.io-index`
required by package `buffered-reader v0.12.0
(/usr/share/cargo/registry/buffered-reader-0.12.0)`
autopkgtest [03:58:52]: test command5: ---]



signature.asc
Description: OpenPGP digital signature

Bug#946746: virtualbox: after upgrade virtualbox can not open it .

[alirezaimi]

Package: virtualbox
Version: 6.1.0-dfsg-1
Severity: important

Dear Maintainer,

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

   * What led up to the situation?
 apt-get dist-upgrade
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
 system upgrade
   * What was the outcome of this action?
 virtualbox can not open .
   * What outcome did you expect instead?
 open virtualbox .

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


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

Kernel: Linux 5.3.0-3-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.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages virtualbox depends on:
ii  adduser   3.118
ii  iproute2  5.4.0-1
ii  libc6 2.29-3
ii  libcurl3-gnutls   7.67.0-2
ii  libdevmapper1.02.12:1.02.155-3
ii  libgcc1   1:9.2.1-21
ii  libgl11.1.0-1+b1
ii  libgsoap-2.8.91   2.8.91-2
ii  libopus0  1.3-1+b1
ii  libpng16-16   1.6.37-1
ii  libpython3.7  3.7.5-2
ii  libsdl1.2debian   1.2.15+dfsg2-5
ii  libssl1.1 1.1.1d-2
ii  libstdc++69.2.1-21
ii  libvncserver1 0.9.11+dfsg-1.3
ii  libvpx6   1.8.1-2
ii  libx11-6  2:1.6.8-1
ii  libxcursor1   1:1.2.0-2
ii  libxml2   2.9.4+dfsg1-8
ii  libxt61:1.1.5-1+b3
ii  procps2:3.3.15-2+b1
ii  python3   3.7.5-1
ii  python3.7 3.7.5-2
ii  virtualbox-dkms [virtualbox-modules]  6.1.0-dfsg-1
ii  zlib1g1:1.2.11.dfsg-1+b1

Versions of packages virtualbox recommends:
ii  libqt5core5a5.12.5+dfsg-2
ii  libqt5gui5  5.12.5+dfsg-2
ii  libqt5opengl5   5.12.5+dfsg-2
ii  libqt5widgets5  5.12.5+dfsg-2
ii  libxcb1 1.13.1-2
ii  libxext62:1.3.3-1+b2
ii  libxmu6 2:1.1.2-2+b3
ii  virtualbox-qt   6.1.0-dfsg-1

Versions of packages virtualbox suggests:
pn  vde2
ii  virtualbox-guest-additions-iso  6.0.10-1

-- no debconf information

Bug#930679: Please add overridable tag for not using dh sequencer

[Felix Lechner]

Hi Sam,

On Tue, Jun 18, 2019 at 4:27 AM Sam Hartman  wrote:
>
> Based on that I think we'd like lintian to detect when dh is not used
> and allow maintainers to override the tag if they have an adequate
> justification for not using dh.

I tentatively added a new tag called 'no-dh-sequencer' to Lintian.
More details are available here:


https://salsa.debian.org/lintian/lintian/commit/d0b5b337a61e3ae17e2c7b22621fdd53a9932fad

> It would be even better to detect some of the adequate justifications
> automatically like Haskell packages.

I tried to exclude Haskell packages. The mechanism can probably be improved.

> I'm opening this bug to track the issue.

I kept the bug open to invite further discussion.

As a side note, it was pretty hard to construct a test case. I hadn't
used anything other than dh since Joey wrote his blog post about
everyone's grandpa.

Kind regards
Felix Lechner

Bug#945983: transition: petsc

[Drew Parsons]

On 2019-12-15 17:20, Paul Gevers wrote:



In that case in the spirit of a package deal, I suggest
throwing in scalapack 2.1.0 as well.


Go ahead.


Thanks Paul, proceeding.

Drew

Bug#945983: transition: petsc

[Paul Gevers]

Hi Drew,

On 15-12-2019 07:07, Drew Parsons wrote:
> Did I understand correctly you were in favour of lumping
> the MUMPS transition in at the same time to get the stack updated all
> together?

Yes

> In that case in the spirit of a package deal, I suggest
> throwing in scalapack 2.1.0 as well.

Go ahead.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#946745: tagpending: allow tagging wnpp bugs as pending by default

[Paul Wise]

Package: devscripts
Version: 2.19.7
Severity: wishlist
File: /usr/bin/tagpending

I am working on adopting libpst and so I added a closing for the RFA
bug (#856524) to debian/changelog, committed the change to git and ran 
tagpending, but it refused to allow me to tag the wnpp bug without the option 
to force the tagging.

I think it is reasonable to allow wnpp bugs to be tagged by default.

   $ tagpending
   Warning: #856524 is closed or does not belong to this package (check bug # 
or force)
   tagpending info: Nothing to do, exiting.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#945983: transition: petsc

[Drew Parsons]

On 2019-12-14 20:40, Paul Gevers wrote:


On 02-12-2019 09:31, Drew Parsons wrote:

I'd like to proceed with the PETSc 3.12 transition.

The MUMPS 5.2.1 is also ready to go, but I think it might be more
constructive to demonstrate via testing migration that the new petsc
is stable with the old mumps than to show the new mumps is stable 
with

the old petsc.

If you'd prefer to avoid the fuss of 2 transitions, then I'd be 
happy

to upgrade both at the same time.


Please go ahead.



Thanks Paul.  Did I understand correctly you were in favour of lumping 
the MUMPS transition in at the same time to get the stack updated all 
together?  In that case in the spirit of a package deal, I suggest 
throwing in scalapack 2.1.0 as well.


If not, confirm and I'll just start with petsc/slepc 3.12.

https://release.debian.org/transitions/html/auto-scalapack.html
https://release.debian.org/transitions/html/auto-mumps.html
https://release.debian.org/transitions/html/auto-petsc.html
https://release.debian.org/transitions/html/auto-slepc.html

Drew

Bug#946744: lintian-brush: deletes comments from with Build-Depends field

[Paul Wise]

Package: lintian-brush
Version: 0.46
Severity: normal

With libpst 0.6.71-0.1, after applying the debian/compat 9 -> 10 bump,
--allow-reformatting deleted comments in the Build-Depends field:

libpst $ lintian-brush --dry-run --diff  --allow-reformatting
...
--- a/debian/control
+++ b/debian/control
@@ -2,16 +2,13 @@ Source: libpst
 Section: utils
 Priority: optional
 Maintainer: Leo Costela 
-Build-Depends: debhelper (>= 10~),
-dh-autoreconf,
-#  for buildflags.mk
+Build-Depends: debhelper (>= 10),
 dpkg-dev (>= 1.16.1~),
-#   for pst2dii
 imagemagick,
 libgd-dev,
 libgsf-1-dev

-- 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.3.0-3-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:en 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages lintian-brush depends on:
ii  devscripts   2.19.7
ii  python3  3.7.5-1
ii  python3-breezy   3.0.1-2
ii  python3-debian   0.1.36
ii  python3-distro-info  0.22
ii  python3-dulwich  0.19.13-1+b1
ii  python3-levenshtein  0.12.0-3+b2
ii  python3-pkginfo  1.4.2-2
ii  python3-ruamel.yaml  0.15.89-3+b1

Versions of packages lintian-brush recommends:
ii  dos2unix   7.4.0-2
ii  gpg2.2.17-3
ii  libdebhelper-perl  12.7.1
ii  lintian2.41.0
pn  python3-asyncpg
pn  python3-pyinotify  

Versions of packages lintian-brush suggests:
ii  gnome-pkg-tools0.21.2
pn  postgresql-common  

-- no debconf information

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#946743: lintian-brush: generates bad debhelper dep (10 instead of 10~) when dropping dh-autoreconf

[Paul Wise]

Package: lintian-brush
Version: 0.46
Severity: normal

With libpst 0.6.71-0.1, after applying the debian/compat 9 -> 10 bump,
--allow-reformatting changed the debhelper dep from 10~ (which allows
backports) to 10 (which doesn't):

libpst $ lintian-brush --dry-run --diff  --allow-reformatting
...
--- a/debian/control
+++ b/debian/control
@@ -2,16 +2,13 @@ Source: libpst
 Section: utils
 Priority: optional
 Maintainer: Leo Costela 
-Build-Depends: debhelper (>= 10~),
-dh-autoreconf,
-#  for buildflags.mk
+Build-Depends: debhelper (>= 10),
 dpkg-dev (>= 1.16.1~),
-#   for pst2dii
 imagemagick,
 libgd-dev,
 libgsf-1-dev

-- 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.3.0-3-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:en 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages lintian-brush depends on:
ii  devscripts   2.19.7
ii  python3  3.7.5-1
ii  python3-breezy   3.0.1-2
ii  python3-debian   0.1.36
ii  python3-distro-info  0.22
ii  python3-dulwich  0.19.13-1+b1
ii  python3-levenshtein  0.12.0-3+b2
ii  python3-pkginfo  1.4.2-2
ii  python3-ruamel.yaml  0.15.89-3+b1

Versions of packages lintian-brush recommends:
ii  dos2unix   7.4.0-2
ii  gpg2.2.17-3
ii  libdebhelper-perl  12.7.1
ii  lintian2.41.0
pn  python3-asyncpg
pn  python3-pyinotify  

Versions of packages lintian-brush suggests:
ii  gnome-pkg-tools0.21.2
pn  postgresql-common  

-- no debconf information

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#946740: lintian-brush: detects pending changes when there are none

[Paul Wise]

On Sun, 2019-12-15 at 05:08 +, Jelmer Vernooij wrote:

> I can't reproduce this locally.

I guess this is caused by something in my git config then.

How does lintian-brush determine that files have changed?

> What does the output of "ls -l" in that directory look like?

libpst $ ls -l
total 14M
-rw-r- 1 pabs pabs  41K Dec 15 13:27 aclocal.m4
-rw-r- 1 pabs pabs 1.8K Dec 15 13:27 AUTHORS
-rw-r- 1 pabs pabs  35K Dec 15 13:27 ChangeLog
-rwxr-x--- 1 pabs pabs 3.6K Dec 15 13:27 compile*
-rwxr-x--- 1 pabs pabs  44K Dec 15 13:27 config.guess*
-rw-r- 1 pabs pabs 8.5K Dec 15 13:27 config.h.in
-rw-r- 1 pabs pabs  18K Dec 15 13:27 config.rpath
-rwxr-x--- 1 pabs pabs  34K Dec 15 13:27 config.sub*
-rwxr-x--- 1 pabs pabs 794K Dec 15 13:27 configure*
-rw-r- 1 pabs pabs  12K Dec 15 13:27 configure.in
-rw-r- 1 pabs pabs  15K Dec 15 13:27 COPYING
drwxr-x--- 4 pabs pabs 4.0K Dec 15 13:27 debian/
-rwxr-x--- 1 pabs pabs  15K Dec 15 13:27 depcomp*
-rw-r- 1 pabs pabs  63K Dec 15 13:27 Doxyfile
drwxr-x--- 3 pabs pabs 4.0K Dec 15 13:27 html/
-rw-r- 1 pabs pabs 9.1K Dec 15 13:27 INSTALL
-rwxr-x--- 1 pabs pabs 9.0K Dec 15 13:27 install-sh*
-rw-r- 1 pabs pabs  12M Dec 15 13:27 libpst.html.tar.gz
-rw-r- 1 pabs pabs  243 Dec 15 13:27 libpst.pc.in
-rw-r- 1 pabs pabs  21K Dec 15 13:27 libpst.spec
-rw-r- 1 pabs pabs  21K Dec 15 13:27 libpst.spec.in
-rwxr-x--- 1 pabs pabs 238K Dec 15 13:27 ltmain.sh*
drwxr-x--- 2 pabs pabs 4.0K Dec 15 13:27 m4/
-rw-r- 1 pabs pabs  409 Dec 15 13:27 Makefile.am
-rw-r- 1 pabs pabs  27K Dec 15 13:27 Makefile.in
drwxr-x--- 2 pabs pabs 4.0K Dec 15 13:27 man/
-rwxr-x--- 1 pabs pabs  11K Dec 15 13:27 missing*
-rw-r- 1 pabs pabs 6.5K Dec 15 13:27 NEWS
drwxr-x--- 2 pabs pabs 4.0K Dec 15 13:27 python/
-rw-r- 1 pabs pabs  225 Dec 15 13:27 README
drwxr-x--- 2 pabs pabs 4.0K Dec 15 13:27 src/
-rw-r- 1 pabs pabs  275 Dec 15 13:27 TODO
drwxr-x--- 2 pabs pabs 4.0K Dec 15 13:27 xml/

> Are you perhaps running on an unusual file system, e.g. vfat?

ext4

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#946742: RM: libmime-lite-tt-html-perl -- ROM; dead upstream; not needed anymore

[Sandro Tosi]

Package: ftp.debian.org
Severity: normal

this package was a dependency of checkgmail, which was recently removed; no
other rdep nor upstream releases, so lets just remove it.

Bug#946740: lintian-brush: detects pending changes when there are none

[Jelmer Vernooij]

Hi Paul,

On Sun, Dec 15, 2019 at 12:57:29PM +0800, Paul Wise wrote:
> Whenever I try to use lintian-brush it detects pending changes even
> though there are none and so it fails to apply changes:
> 
> $ git clone -q https://salsa.debian.org/debian/libpst.git
> $ cd libpst/
> libpst $ git status
> On branch master
> Your branch is up to date with 'origin/master'.
> 
> nothing to commit, working tree clean
> libpst $ git clean -n
> libpst $ lintian-brush 
> libpst: Please commit pending changes first.
> libpst $ lintian-brush --verbose
> libpst: Please commit pending changes first.
> modified:
>   compile*
>   config.guess*
>   config.sub*
>   configure*
>   debian/rules*
>   depcomp*
>   install-sh*
>   ltmain.sh*
>   missing*

I can't reproduce this locally. lintian-brush works fine in a checkout
of libpst here.

What does the output of "ls -l" in that directory look like?

Are you perhaps running on an unusual file system, e.g. vfat?

Cheers,

Jelmer


signature.asc
Description: PGP signature

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

[Sandro Tosi]

> The package is PAPT-maintained, so any help to upload the package is
> very welcome.

no worries, i'll take care of this

-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Bug#946741: librime: Version 1.5.3 ships broken pkg-config file

[Boyuan Yang]

Source: librime
Severity: grave
Version: 1.5.3+dfsg1-1

Currently the pkg-config file for librime is broken for includes dir and
libdir (not absolute path, the ${prefix} is missing). This needs to be fixed.

-- 
Thanks,
Boyuan Yang


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

Bug#946740: lintian-brush: detects pending changes when there are none

[Paul Wise]

Package: lintian-brush
Version: 0.46
Severity: important

Whenever I try to use lintian-brush it detects pending changes even
though there are none and so it fails to apply changes:

$ git clone -q https://salsa.debian.org/debian/libpst.git
$ cd libpst/
libpst $ git status
On branch master
Your branch is up to date with 'origin/master'.

nothing to commit, working tree clean
libpst $ git clean -n
libpst $ lintian-brush 
libpst: Please commit pending changes first.
libpst $ lintian-brush --verbose
libpst: Please commit pending changes first.
modified:
  compile*
  config.guess*
  config.sub*
  configure*
  debian/rules*
  depcomp*
  install-sh*
  ltmain.sh*
  missing*
libpst $ lintian-brush --dry-run
http://www.five-ten-sg.com/libpst/ is permanently redirected to 
https://www.five-ten-sg.com/libpst/ 

Lintian tags fixed: {'upstream-metadata-file-is-missing', 
'debian-changelog-has-wrong-day-of-week', 
'comma-separated-files-in-dep5-copyright', 'debian-watch-uses-insecure-uri', 
'package-uses-old-debhelper-compat-version'}
Some fixer scripts were unable to preserve formatting: 
{'homepage-field-uses-insecure-uri', 'useless-autoreconf-build-depends'}. Run 
with --allow-reformatting to reformat {'debian/control'}.

-- 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.3.0-3-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:en 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages lintian-brush depends on:
ii  devscripts   2.19.7
ii  python3  3.7.5-1
ii  python3-breezy   3.0.1-2
ii  python3-debian   0.1.36
ii  python3-distro-info  0.22
ii  python3-dulwich  0.19.13-1+b1
ii  python3-levenshtein  0.12.0-3+b2
ii  python3-pkginfo  1.4.2-2
ii  python3-ruamel.yaml  0.15.89-3+b1

Versions of packages lintian-brush recommends:
ii  dos2unix   7.4.0-2
ii  gpg2.2.17-3
ii  libdebhelper-perl  12.7.1
ii  lintian2.41.0
pn  python3-asyncpg
pn  python3-pyinotify  

Versions of packages lintian-brush suggests:
ii  gnome-pkg-tools0.21.2
pn  postgresql-common  

-- no debconf information

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#856524: RFA: libpst - library for reading Microsoft Outlook PST files

[Paul Wise]

On Thu, 02 Mar 2017 00:31:41 +0100 Leo Antunes wrote:

> I haven't used this package in years and have unfortunately (and
> regretably) let it fall out of shape for lack of time. It would be
> great if someone with more time could step up and adopt it.

We started using libpst at work and I just got approval to adopt the
package. I'll start by adding myself to uploaders and committing some
packaging updates to the Debian git repository. Are you OK with me
adopting the package and do you want to co-maintain the package?

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#946739: ibus-rime: libexecdir setting in d/rules is not working

[Boyuan Yang]

Source: ibus-rime
Version: 1.4.0-1
Severity: normal

Since ibus-rime upstream is using a Makefile as the wrapper of CMake
buildsystem, the settings for libexecdir is not working. For the background of
ibus-related libexecdir, see https://bugs.debian.org/712581 .

This is actually not affecting the function of ibus-rime since ibus-rime does
not provide a "ibus-setup-rime" binary yet. It may become a real problem in
the future, though.

-- 
Thanks,
Boyuan Yang


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

Bug#945920: chromium: me too

[radiodurans]

Package: chromium
Version: 79.0.3945.79-1
Followup-For: Bug #945920

Dear Maintainer,

Chromium just shuts down for me as well. Ran it from the command line
to get output until it crashed:

$ chromium 
[19595:19595:1214/103537.114652:ERROR:sandbox_linux.cc(372)] 
InitializeSandbox() called with multiple threads in process gpu-process.
[19595:19595:1214/103538.334600:ERROR:buffer_manager.cc(488)] 
[.DisplayCompositor]GL ERROR :GL_INVALID_OPERATION : glBufferData: <- error 
from previous GL command
[19595:19595:1214/103538.445816:ERROR:buffer_manager.cc(488)] 
[.DisplayCompositor]GL ERROR :GL_INVALID_OPERATION : glBufferData: <- error 
from previous GL command
[20313:224:1214/103605.269770:ERROR:child_process_sandbox_support_impl_linux.cc(79)]
 FontService unique font name matching request did not receive a response.
[20407:263:1214/103645.389388:ERROR:child_process_sandbox_support_impl_linux.cc(79)]
 FontService unique font name matching request did not receive a response.
[20448:297:1214/104032.934497:ERROR:child_process_sandbox_support_impl_linux.cc(79)]
 FontService unique font name matching request did not receive a response.
[21225:488:1214/105538.782192:ERROR:child_process_sandbox_support_impl_linux.cc(79)]
 FontService unique font name matching request did not receive a response.
[21295:536:1214/105601.810245:ERROR:child_process_sandbox_support_impl_linux.cc(79)]
 FontService unique font name matching request did not receive a response.
[21313:548:1214/105605.920231:ERROR:child_process_sandbox_support_impl_linux.cc(79)]
 FontService unique font name matching request did not receive a response.
[21550:650:1214/11.996094:ERROR:child_process_sandbox_support_impl_linux.cc(79)]
 FontService unique font name matching request did not receive a response.
[19595:19595:1214/110040.400802:ERROR:buffer_manager.cc(488)] 
[.DisplayCompositor]GL ERROR :GL_INVALID_OPERATION : glBufferData: <- error 
from previous GL command
[19595:19595:1214/110110.712748:ERROR:buffer_manager.cc(488)] 
[.DisplayCompositor]GL ERROR :GL_INVALID_OPERATION : glBufferData: <- error 
from previous GL command
[19595:19595:1214/110115.838422:ERROR:buffer_manager.cc(488)] 
[.DisplayCompositor]GL ERROR :GL_INVALID_OPERATION : glBufferData: <- error 
from previous GL command
[19595:19595:1214/110125.668184:ERROR:buffer_manager.cc(488)] 
[.DisplayCompositor]GL ERROR :GL_INVALID_OPERATION : glBufferData: <- error 
from previous GL command
[19595:19595:1214/110130.797087:ERROR:buffer_manager.cc(488)] 
[.DisplayCompositor]GL ERROR :GL_INVALID_OPERATION : glBufferData: <- error 
from previous GL command
[21703:735:1214/110422.208833:ERROR:child_process_sandbox_support_impl_linux.cc(79)]
 FontService unique font name matching request did not receive a response.
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
Received signal 11 SEGV_MAPERR 
#0 0x55f2650bea99 
#1 0x55f2650080a6 
#2 0x55f2650bd293 
#3 0x55f2650bea16 
#4 0x7f2b62292510 
#5 0x55f26642aee7 
#6 0x55f264c3bdb0 
#7 0x55f264c33e82 
#8 0x55f265063165 
#9 0x55f26507266b 
#10 0x55f265073fec 
#11 0x55f265024aca 
#12 0x7f2b61373ead g_main_context_dispatch
#13 0x7f2b61374130 
#14 0x7f2b613741bf g_main_context_iteration
#15 0x55f265024dd0 
#16 0x55f2650742a9 
#17 0x55f2650502fa 
#18 0x55f264b56217 
#19 0x55f262e7b1c6 
#20 0x55f262e7b375 
#21 0x55f262e515f7 
#22 0x55f264ade101 
#23 0x55f264ade338 
#24 0x55f264ade6a7 
#25 0x55f264b14802 
#26 0x55f264adc0c6 
#27 0x55f26200a3e5 ChromeMain
#28 0x7f2b5b597bbb __libc_start_main
#29 0x55f26200a22a _start
  r8: 55f26ed57da0  r9: 0001 r10:  r11: 
00ff
 r12: 7fff2ee2be80 r13: 7fff2ee2be60 r14: 7fff2ee2be80 r15: 
7f2b3815a320
  di:   si: 7fff2ee2be60  bp: 7fff2ee2be20  bx: 

  dx: 7fff2ee2be80  ax: 7f2b3826bc90  cx:   sp: 
7fff2ee2bde0
  ip: 55f26642aee7 efl: 00010202 cgf: 002b0033 erf: 
0004
 trp: 000e msk:  cr2: 
[end of stack trace]
Calling _exit(1). Core file will not be generated.



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

Kernel: Linux 5.3.0-3-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.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 chromium depends on:
ii  chromium-common79.0.3945.79-1
ii  libasound2 1.1.9-1
ii  libatk-bridge2.0-0 2.34.1-2
ii  libatk1.0-02.34.1-1
ii  

Bug#943656: python3-construct: please update to 2.9

[Johannes Schauer]

Hi,

On Sun, 27 Oct 2019 16:07:27 +0100 Andreas Beckmann  wrote:
> python-miio/experimental has a (currently unsatisfiable)
>   B-D: python3-construct (>= 2.9.45)

python-miio maintainer here. Could you please consider packaging the latest
upstream version of python-construct?

Thanks!

cheers, josch


signature.asc
Description: signature

Bug#946738: qsynth: new qsynth 0.6.0

[Jonatan Nyberg]

Package: qsynth
Version: 0.6.0

Please consider to upgrade to the current upstream version (0.6.0).

Regards
Jonatan

Bug#944367: coco-doc: diff for NMU version 20060919.0-1

[Boyuan Yang]

Control: tags 944367 + patch
Control: tags 944367 + pending

Dear maintainer,

I've prepared an NMU for coco-doc (versioned as 20060919.0-1) and
uploaded it to DELAYED/7. Please feel free to tell me if I
should delay it longer.

Regards.

diff -Nru coco-doc-20060919/debian/changelog coco-doc-
20060919.0/debian/changelog
--- coco-doc-20060919/debian/changelog  2006-11-10 09:40:53.0 -0500
+++ coco-doc-20060919.0/debian/changelog2019-12-14 22:29:44.0
-0500
@@ -1,3 +1,18 @@
+coco-doc (20060919.0-1) unstable; urgency=medium
+
+  * QA upload.
+  * Finish the package salvage process. (Closes: #944367)
+  * Regenerate new source package and use "3.0 (quilt)" format.
+  * debian/control:
++ Bump debhelper compat to v12.
++ Bump Standards-Version to 4.4.1.
++ Update Vcs-* fields to use git packaging repo under Salsa
+  Debian group.
+  * debian/rules: Use dh sequencer.
+  * debian/copyright: Rewrite with machine-readable format.
+
+ -- Boyuan Yang   Sat, 14 Dec 2019 22:29:44 -0500
+
 coco-doc (20060919-2) unstable; urgency=low
 
   * Added dokumentation as OpenOffice documents and removed
diff -Nru coco-doc-20060919/debian/compat coco-doc-20060919.0/debian/compat
--- coco-doc-20060919/debian/compat 2006-11-10 09:21:19.0 -0500
+++ coco-doc-20060919.0/debian/compat   1969-12-31 19:00:00.0 -0500
@@ -1 +0,0 @@
-5
diff -Nru coco-doc-20060919/debian/control coco-doc-20060919.0/debian/control
--- coco-doc-20060919/debian/control2006-11-10 09:08:05.0 -0500
+++ coco-doc-20060919.0/debian/control  2019-12-14 22:29:44.0 -0500
@@ -1,12 +1,18 @@
 Source: coco-doc
 Section: doc
 Priority: optional
-Maintainer: Loeberbauer Markus 
-Build-Depends: debhelper (>= 5)
-Standards-Version: 3.7.2
+Maintainer: Debian QA Group 
+Build-Depends: debhelper-compat (= 12)
+Standards-Version: 4.4.1
+Rules-Requires-Root: no
+Homepage: http://ssw.jku.at/Coco/
+Vcs-Git: https://salsa.debian.org/debian/coco-doc.git
+Vcs-Browser: https://salsa.debian.org/debian/coco-doc
 
 Package: coco-doc
 Architecture: all
+Multi-Arch: foreign
+Depends: ${misc:Depends}
 Description: Documentation for the Coco/R Compiler Generator
  Coco/R is a compiler generator, which takes an attributed grammar of a
source
  language and generates a scanner and a parser for this language. The scanner
@@ -15,4 +21,3 @@
  checks. Thus the class of accepted grammars is LL(k) for an arbitrary k.
  .
  See /usr/share/doc/cocosourcesdoc.
-
diff -Nru coco-doc-20060919/debian/copyright coco-doc-
20060919.0/debian/copyright
--- coco-doc-20060919/debian/copyright  2006-11-10 09:22:51.0 -0500
+++ coco-doc-20060919.0/debian/copyright2019-12-14 22:26:58.0
-0500
@@ -1,34 +1,38 @@
-Documentation for the Compiler Generator Coco/R,
-Copyright (c) 1990, 2004 Hanspeter Moessenboeck, University of Linz
-extended by M. Loeberbauer & A. Woess, Univ. of Linz
-with improvements by Pat Terry, Rhodes University
-
-Debian packaging: Copyright (c) 2004-2006 Markus Loeberbauer
-
-This program is free software; you can redistribute it and/or modify it 
-under the terms of the GNU General Public License as published by the 
-Free Software Foundation; either version 2, or (at your option) any 
-later version.
-
-This program is distributed in the hope that it will be useful, but 
-WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY 
-or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License 
-for more details.
-
-You should have received a copy of the GNU General Public License along 
-with this program; if not, write to the Free Software Foundation, Inc., 
-51 Franklin Street, Fifth Floor, Boston, MA  02110-1301, USA.
-
-As an exception, it is allowed to write an extension of Coco/R that is
-used as a plugin in non-free software.
-
-If not otherwise stated, any source code generated by Coco/R (other than 
-Coco/R itself) does not fall under the GNU General Public License.
-
-
--- 
-
-A copy of the GNU General Public License (GPL) is available at:
-Debian GNU/Linux: /usr/share/common-licenses/GPL
-World Wide Web: http://www.gnu.org/copyleft/gpl.html
-
+Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
+Upstream-Name: coco-doc
+Source: http://ssw.jku.at/Coco/
+
+Files: *
+Copyright: 1990, 2004, 2010 Hanspeter Moessenboeck, University of Linz
+   2010 Markus Löberbauer 
+   2010 Albrecht Wöß, University of Linz
+License: GPL-2.0+ with CocoR exception
+
+Files: debian/*
+Copyright: 2004-2006 Markus Loeberbauer
+License: GPL-2.0+ with CocoR exception
+
+License: GPL-2.0+ with CocoR exception
+ This program is free software; you can redistribute it and/or modify it 
+ under the terms of the GNU General Public License as published by the 
+ Free Software Foundation; either version 2, or (at your option) any 
+ later version.
+ .
+ This program is distributed in the hope that it will be useful, but 
+ WITHOUT ANY WARRANTY; without even 

Bug#944989: ITP: python-fissix -- backport of lib2to3, supporting the latest Python3 grammars, with enhancements

[Nicholas D Steeves]

Progress towards getting this package in Debian is currently blocked
by the following upstream issue:

  https://github.com/jreese/fissix/issues/8


signature.asc
Description: PGP signature

Bug#939095: RFS: axtls/2.1.5+ds-1 [ITP] -- Highly configurable client/server TLSv1.2 library

[Adam Borowski]

On Sun, Sep 01, 2019 at 05:46:15PM +0800, Yangfl wrote:
> I am looking for a sponsor for my package "axtls"

Sponsoring delays are not cool... :(

>  * Package name: axtls
>Version : 2.1.5+ds-1
>  * URL : http://axtls.sourceforge.net/

> It builds those binary packages:
> 
>   libaxtls-dev - Highly configurable client/server TLSv1.2 library
> (development files)
>   libaxtls1 - Highly configurable client/server TLSv1.2 library
>   libaxtlsp-perl - Highly configurable client/server TLSv1.2 library
> (Perl binding)
>   lua-axtlsl - Highly configurable client/server TLSv1.2 library (Lua binding)
>   axhttpd - Highly configurable client/server TLSv1.2 library (web server)

Alas, it fails to build, during tests:

   dh_auto_test
make -j64 test
make[1]: Entering directory '/<>'
cd ./_stage; OPENSSL_CONF=../config/open-ssl.cnf ./ssltest
./ssltest: error while loading shared libraries: libaxtls.so.1: cannot open 
shared object file: No such file or directory

Full log attached.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ A MAP07 (Dead Simple) raspberry tincture recipe: 0.5l 95% alcohol,
⣾⠁⢠⠒⠀⣿⡁ 1kg raspberries, 0.4kg sugar; put into a big jar for 1 month.
⢿⡄⠘⠷⠚⠋⠀ Filter out and throw away the fruits (can dump them into a cake,
⠈⠳⣄ etc), let the drink age at least 3-6 months.
sbuild (Debian sbuild) 0.78.1 (09 February 2019) on valinor.angband.pl

+==+
| axtls 2.1.5+ds-1 (amd64) Sun, 15 Dec 2019 03:21:04 + |
+==+

Package: axtls
Version: 2.1.5+ds-1
Source Version: 2.1.5+ds-1
Distribution: unstable
Machine Architecture: amd64
Host Architecture: amd64
Build Architecture: amd64
Build Type: full

I: NOTICE: Log filtering will replace 
'var/run/schroot/mount/unstable-amd64-sbuild-512c2c70-6088-4c5c-a06d-f8ee18e16abc'
 with '<>'
I: NOTICE: Log filtering will replace 'build/axtls-bDzn0Q/resolver-k8w5VY' with 
'<>'

+--+
| Update chroot|
+--+

Hit:1 http://apt-rosy.angband.pl:3142/debian unstable InRelease
Reading package lists...
Reading package lists...
Building dependency tree...
Reading state information...
Calculating upgrade...
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

+--+
| Fetch source files   |
+--+


Local sources
-

/home/kilobyte/tmp/pkg/axtls_2.1.5+ds-1.dsc exists in /home/kilobyte/tmp/pkg; 
copying to chroot
I: NOTICE: Log filtering will replace 'build/axtls-bDzn0Q/axtls-2.1.5+ds' with 
'<>'
I: NOTICE: Log filtering will replace 'build/axtls-bDzn0Q' with '<>'

+--+
| Install package build dependencies   |
+--+


Setup apt archive
-

Merged Build-Depends: debhelper-compat (= 12), swig, dh-lua, libperl-dev, 
gnutls-bin, build-essential, fakeroot
Filtered Build-Depends: debhelper-compat (= 12), swig, dh-lua, libperl-dev, 
gnutls-bin, build-essential, fakeroot
dpkg-deb: building package 'sbuild-build-depends-main-dummy' in 
'/<>/apt_archive/sbuild-build-depends-main-dummy.deb'.
Ign:1 copy:/<>/apt_archive ./ InRelease
Get:2 copy:/<>/apt_archive ./ Release [957 B]
Ign:3 copy:/<>/apt_archive ./ Release.gpg
Get:4 copy:/<>/apt_archive ./ Sources [397 B]
Get:5 copy:/<>/apt_archive ./ Packages [478 B]
Fetched 1832 B in 0s (178 kB/s)
Reading package lists...
Reading package lists...

Install main build dependencies (apt-based resolver)


Installing build dependencies
Reading package lists...
Building dependency tree...
Reading state information...
The following additional packages will be installed:
  dctrl-tools dh-lua gnutls-bin libevent-2.1-7 libfile-find-rule-perl
  libgnutls-dane0 liblua5.1-0 liblua5.1-0-dev liblua5.2-0 liblua5.2-dev
  liblua5.3-0 liblua5.3-dev libncurses-dev libncurses6 libnumber-compare-perl
  libopts25 libperl-dev libreadline-dev libreadline8 libtext-glob-perl
  libtool-bin libunbound8 lua5.1 lua5.2 lua5.3 pkg-config readline-common swig
  swig3.0
Suggested packages:
  debtags dns-root-data ncurses-doc readline-doc swig-doc swig-examples
  swig3.0-examples swig3.0-doc
Recommended packages:
  libgpm2
The following NEW packages will be installed:
  dctrl-tools dh-lua gnutls-bin libevent-2.1-7 libfile-find-rule-perl
  libgnutls-dane0 liblua5.1-0 liblua5.1-0-dev liblua5.2-0 liblua5.2-dev
  liblua5.3-0 

Bug#938511: solaar: Python 3 support

[John Scott]

Control: tags -1 fixed-upstream

I haven't been able to narrow it down to any particular release, but it 
appears that Solaar does support Python 3. See this issue adding support for 
Python 3.7 filed by the Fedora maintainer:
https://github.com/pwr-Solaar/Solaar/issues/447
And it looks to work with 3.8
https://apps.fedoraproject.org/packages/solaar/changelog/

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

Bug#938431: Fixing sambamba 0.8.6

[Matthias Klumpp]

Am Do., 28. Nov. 2019 um 16:37 Uhr schrieb Pjotr Prins :
>
> When 1.18 arrives I think it is a good time to get sambamba and biod
> in Debian again.

They always were in Debian, just not in a release because the packages
were broken ^^
The LDC transition went really well this time, I don't think it has
ever been this smooth! No regressions this time, hurray!
I had a bit of time to look into the sambamba/biod packages today, and
fixing them was actually really easy. Originally, I wanted to just
make use of the upstream-provided Makefiles, but unfortunately it was
really annoying to make them produce a proper static and dynamic
library, and then I would still have had the problem of installing all
pieces to the right locations and to write a pkg-config file.
Therefore, the way of least resistance was to just use Meson for
building, as that does everything we need in Debian. Both BioD and
Sambamba build well with Meson.

I applied a few tweaks to the packages, that haven't been there
before: BioD is now built as a shared as well as a static library, so
applications can choose between the two. That's pretty common in
Debian, and as a sideeffect this also guarantees that things are
rebuilt properly when a transition happens. The Sambamba package will
now prefer statically linking BioD if possible (so BioD is statically
linked by default now in Debian).
Additionally both packages now apply the optimization flags upstream
has set for releases (-O3, no bounds checks, etc.). Combined, these
two changes should make the Debian builds comparably fast to the
upstream builds, but I haven't tested that yet.

There are also two brand new remaining issues: Apparently, for some
reason, SONAME isn't set correctly for BioD, producing a Lintian error
- not sure what happens there, and which component is to blame for
that (Meson or LDC, most likely). Also, Sambamba doesn't *actually*
build yet:
```
roup -L=-rpath 
-L=/usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu:/usr/lib/x86_64-linux-gnu
slicereader.d:71: error: undefined reference to 'cram_to_bam'
collect2: error: ld returned 1 exit status
```
The cram_to_bam is private in htslib, so it shouldn't be used by other
applications. Not sure whether htslib or Sambamba needs to be changed
here, I simply worked around this issue for testing, and when this is
resolved, Sambamba builds & works.
Unfortunately I briefly forgot that this issue existed, so I already
uploaded the new sambamba package with this issue still present (I
remembered literally the moment the upload finished), so its builds
will fail. This is probably something for Andreas to look into :-)

Anyway, I hope this is helpful to you and the resulting binaries are
performant :-)

Cheers,
Matthias

-- 
I welcome VSRE emails. See http://vsre.info/

Bug#943872: RM: fontypython -- ROM; No longer active upstream, Python 2 only

[John Scott]

Control: tags -1 - moreinfo

> There are rdepends that need to be addressed first:
> 
> Checking reverse dependencies...
> # Broken Depends:
> open-font-design-toolkit: open-font-design-toolkit

That doesn't look right; that's the same package. Is this a mistake?

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

Bug#946737: please update maven to 3.6.3

[shirish शिरीष]

Package: maven
Version: 3.6.2-1
Severity: wishlist

Dear Maintainer,
Seems maven has been updated to 3.6.3 and seems to have some bug-fixes
as can be seen from
http://maven.apache.org/docs/3.6.3/release-notes.html . It would be
nice if we can have it in debian.


-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (900, 'testing'), (500, 'testing-debug'), (100,
'unstable-debug'), (100, 'experimental'), (100, 'unstable'), (50,
'experimental-debug')
Architecture: amd64 (x86_64)

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

Versions of packages maven depends on:
ii  default-jre-headless [java7-runtime-headless] 2:1.11-72
ii  libjansi-java 1.18-1
ii  libmaven3-core-java   3.6.2-1
ii  libwagon-file-java3.3.3-1
ii  libwagon-http-shaded-java 3.3.3-1
ii  openjdk-11-jre-headless [java7-runtime-headless]  11.0.5+10-2
ii  openjdk-14-jre-headless [java7-runtime-headless]  14~19-1

maven recommends no packages.

maven suggests no packages.

-- no debconf information

-- 
  Regards,
  Shirish Agarwal  शिरीष अग्रवाल
  My quotes in this email licensed under CC 3.0
http://creativecommons.org/licenses/by-nc/3.0/
http://flossexperiences.wordpress.com

E493 D466 6D67 59F5 1FD0 930F 870E 9A5B 5869 609C

Bug#946736: RM: defendguin -- RoM; questionable copyright status

[John Scott]

Package: ftp.debian.org
Severity: normal
X-Debbugs-CC: debian-rele...@lists.debian.org, n...@sonic.net
Control: block 934976 by -1

The maintainer and author acknowledges that the game uses Bill Gates's
likeness and likely non-free audio samples from the Defender arcade game
and requests that it be removed. See #934976

The package is in unstable, Buster, Stretch, and Jessie.

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

Bug#933865: adb crashes on startup with SIGBUS

[John Scott]

Control: reassign -1 android-libboringssl/8.1.0+r23-1
Control: tags -1 upstream patch fixed-upstream
Control: retitle -1  adb crashes on startup with SIGBUS (armhf)
Control: forwarded -1 
https://boringssl.googlesource.com/boringssl/+/672f6fc2486745d0cabc3aaeb4e0a3cd13b37b12%5E%21/
Control: affects -1 adb
Control: severity -1 serious
(justification: it works on other architectures)

> A package android-libboringssl build with that patch applied could
> successfuly create the keys and did no crash on "adb devices" (just tested
> without a device connected).

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

Bug#940463: fixed in falkon 3.1.0+dfsg1-4

[John Scott]

On Wed, 16 Oct 2019 10:00:15 + Georges Khaznadar  
wrote:
> Source: falkon
> Source-Version: 3.1.0+dfsg1-4
> 
> We believe that the bug you reported is fixed in the latest version of
> falkon, which is due to be installed in the Debian FTP archive.
> 
> A summary of the changes between this version and the previous one is
> attached.
> 
> Changes:
>  falkon (3.1.0+dfsg1-4) unstable; urgency=medium
>  .
>* Checked that falkon-3.1.0+dfsg1-3 does not crash.
>  Closes: #940463

Did a change to Falkon fix the issue, or is 3.1.0+dfsg-1-4 the same as 
3.1.0+dfsg-1-3? Was the submitter's issue resolved or were you unable to 
reproduce the crash?

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

Bug#946735: RFS: micro-httpd/20140814-1 -- really small HTTP server

[Sudip Mukherjee]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "micro-httpd"

 * Package name: micro-httpd
   Version : 20140814-1
   Upstream Author : Jef Poskanzer 
 * URL : http://www.acme.com/software/micro_httpd
 * License : BSD-2-Clause
 * Vcs : https://github.com/sudipm-mukherjee/micro-httpd.git
   Section : httpd

It builds those binary packages:

  micro-httpd - really small HTTP server

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

  https://mentors.debian.net/package/micro-httpd

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

  dget -x 
https://mentors.debian.net/debian/pool/main/m/micro-httpd/micro-httpd_20140814-1.dsc

Changes since the last upload:

   * Update to upstream 20140814 (Closes: #911932)
   * Add Rules-Requires-Root
   * Use https in copyright

-- 
Regards
Sudip

Bug#864997: DEP-5 copyright checker

[Luke Kenneth Casson Leighton]

[apologies i can't reply inline, very limited HTML mailer due to
seriously bandwidth/reliability-compromised internet connection]

hi felix,

violates my copyright by not containing my authorship assertion.  in
combination with no license file they should have contacted me for
permission to distribute.  whoops.  they *assumed* that because it was
in some other work that *was* licensed that it was "okay".

ironic, huh?

yes it's my work (entirely), yes, confirmed, GPLv2+ licensed.
("public domain" statements are *ineffective* due to the very annoying
Berne Convention).  the only modifications that people have made in
the copies that you can find online are to default paths (something
like that, it's been a while).

there is *one* annoying buglet in copyright_check.py: the search
mechanism i couldn't find a way to get it to go from the "root" level
using wildcards.  consequently, you have to use a copyright file that
specifies matches against files and subdirectories, *even if those are
wildcards*.

this is the primary reason why copyright_check.py doesn't "detect"
anything on lintian itself... because lintian's *own* copyright file
is a one-liner-wildcard-match.

a way to get round that would be to take one-liner-wildcard-match
files, do a sweep of the top-level root directory, and apply the
one-liner-wildcard-match to every single entry... *then* pass that
through to the algorithm.

no, god no, i'll never rewrite it in perl: perl is a "WORN" language -
write-once, read-never :)  i'm dead serious.  the readability is so
bad in perl, and the algorithm itself in copyright_check.py
sufficiently obtuse that it would be a... "inadviseable" combination
:)

those false positives look... err fun.  welcome to
arbitrary-pattern-matching against random human-written text: i used
qgrams to help with that, however, just as with when i was working for
Internet Security Systems and we were doing packet-pattern-recognition
it is *guaranteed* to be a losing battle that will *never* be
"complete" or "successful", please do bear that in mind, ok?

with many apologies, i have so much else going on: if you ping me
regularly and keep me interested in a conversation i will respond with
insights and so on (because i like copyright_check.py and the time it
saves), however i simply don't have time to take "initiative" if you
know what i mean, there.

thanks felix.

l.

On 12/14/19, Felix Lechner  wrote:
> Hi Luke,
>
>> so i wrote a program called copyright_check.py which covers every single
>> possibility of what is correctly matched, what is incorrectly matched,
>> and what is missing.
>
> That's great! I have been looking for such a tool.
>
>> copies of the original program are being made and distributed
>> arbitrarily.
>> one such copy (which ironically violates copyright) is here:
>> https://fossies.org/dox/drizzle-7.2.4-alpha/copyright__check_8py_source.html
>>
>> one version may also be found here:
>> https://github.com/jaredly/pyjamas/blob/master/contrib/copyright_check.py
>
> Does it violate your copyright or someone else's? I see an assertion
> of your authorship only in the second file. Neither file shows license
> terms.
>
> For Debian's benefit, would you please reply with a statement that the
> program is solely your work? Please also attach a copy (not a link) or
> alternatively, a pointer to a repository under your control. The copy
> you send must further include the terms of your DFSG-compliant license
> (preferably GPL-2+, which would be like Lintian) or a statement
> placing your work in the public domain. Thank you!
>
> Two more things: First, Lintian runs on Perl. Did you ever port your
> program to any other languages? Second, I plan to rework the copyright
> check, which has many open bugs. Please let me know if are interested
> in helping:
>
>
> https://salsa.debian.org/lintian/lintian/blob/master/checks/debian/copyright.pm
>
> https://bugs.debian.org/cgi-bin/pkgreport.cgi?repeatmerged=no=lintian
>
> Kind regards
> Felix Lechner
>

Bug#944205: spacefm: 100% cpu when creating files/folders

[Jack Barns]

Package: spacefm
Version: 1.0.6-4
Followup-For: Bug #944205

Dear Maintainer,

Hello, thank you for looking into this.
I can still reproduce the issue from a fresh install by not choosing
any desktop environment (only selecting "standard system utilities"
during the install) and downloading just a window manager. I have
tested cwm and openbox, which both freeze and get 100% cpu.
This is cwm's gdb output [1] and this is openbox's gdb output [2].

And in case it matters here is a list of the package's I had installed
for both in order: sudo xinit spacefm firefox cwm|openbox gdb
spacefm-dbgsym libgtk2.0-0-dbgsym libglib2.0-0-dbgsym.

[1] https://paste.debian.net/1121108/
[2] https://paste.debian.net/1121109/

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

Kernel: Linux 5.3.0-2-amd64 (SMP w/8 CPU cores)
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 spacefm depends on:
ii  desktop-file-utils0.24-1
ii  e2fsprogs 1.45.4-1
ii  libc6 2.29-5
ii  libcairo2 1.16.0-4
ii  libffmpegthumbnailer4v5   2.1.1-0.2+b1
ii  libgdk-pixbuf2.0-02.40.0+dfsg-1
ii  libglib2.0-0  2.62.3-2
ii  libgtk2.0-0   2.24.32-4
ii  libpango-1.0-01.42.4-7
ii  libpangocairo-1.0-0   1.42.4-7
ii  libstartup-notification0  0.12-6
ii  libudev1  244-3
ii  libx11-6  2:1.6.8-1
ii  shared-mime-info  1.10-1
ii  spacefm-common1.0.6-4

Versions of packages spacefm recommends:
ii  udisks2  2.8.4-1

Versions of packages spacefm suggests:
ii  dbus1.12.16-2
ii  eject   2.1.5+deb1+cvs20081104-14+b1
pn  gksu
pn  ktsuss  
ii  lsof4.93.2+dfsg-1
ii  sshfs   2.10+repack-2+b1
pn  udevil  
ii  wget1.20.3-1+b2

-- no debconf information

Bug#916076: [Retesting] kamoso: segmentation fault in GStreamer opening hamburger menu

[John Scott]

On Sat, 14 Dec 2019 22:55:17 +0100 Aurélien COUDERC  
wrote:
> Would you have the possibility to test again and comment here with more 
> information if the crash is still reproducible ?

Sure, I've attached a backtrace done with 'bt full' on the older version that 
looks more comprehensible. I've built Kamoso from source on Buster, so maybe 
the dependencies need to be tightened.

The new version fails to build from source for me, both on Buster and in an 
unstable pbuilder. Unfortunately it appears the buildd's are failing also:
https://buildd.debian.org/status/fetch.php?
pkg=kamoso=amd64=19.08.3-1=1576314481=0Starting program: /usr/bin/kamoso 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x70963700 (LWP 17457)]
[New Thread 0x7fffeae3b700 (LWP 17458)]
[New Thread 0x7fffe995f700 (LWP 17460)]
[New Thread 0x7fffe33b2700 (LWP 17461)]
[New Thread 0x7fffe2bb1700 (LWP 17462)]
[New Thread 0x7fffe0e1f700 (LWP 17463)]
[New Thread 0x7fffcd9a9700 (LWP 17465)]
[New Thread 0x7fffcd1a8700 (LWP 17466)]
[New Thread 0x7fffc7fff700 (LWP 17467)]
[New Thread 0x7fffc77fe700 (LWP 17468)]
[New Thread 0x7fffc6ffd700 (LWP 17469)]
[New Thread 0x7fffc67fc700 (LWP 17470)]
[New Thread 0x7fffc5dc5700 (LWP 17472)]
[New Thread 0x7fffc55c4700 (LWP 17473)]
[New Thread 0x7fffc4dc3700 (LWP 17474)]
[New Thread 0x7fffa3fff700 (LWP 17475)]
[New Thread 0x7fffa37fe700 (LWP 17476)]
[New Thread 0x7fffa2ffd700 (LWP 17477)]
[New Thread 0x7fffa27fc700 (LWP 17478)]
[New Thread 0x7fffa1ffb700 (LWP 17479)]
[New Thread 0x7fffa17fa700 (LWP 17480)]
[New Thread 0x7fffa0ff9700 (LWP 17482)]
[New Thread 0x7fff83fff700 (LWP 17483)]
[New Thread 0x7fff837fe700 (LWP 17484)]
[New Thread 0x7fff82ffd700 (LWP 17485)]
[New Thread 0x7fff827fc700 (LWP 17486)]
[New Thread 0x7fff81ffb700 (LWP 17487)]
[New Thread 0x7fff817fa700 (LWP 17488)]
[New Thread 0x7fff80ff9700 (LWP 17489)]
[New Thread 0x7fff63fff700 (LWP 17490)]
[New Thread 0x7fff637fe700 (LWP 17491)]
[New Thread 0x7fff62ffd700 (LWP 17492)]
[New Thread 0x7fff627fc700 (LWP 17493)]
[New Thread 0x7fff61ffb700 (LWP 17494)]
[New Thread 0x7fff617fa700 (LWP 17495)]
[New Thread 0x7fff60ff9700 (LWP 17496)]
[New Thread 0x7fff5bfff700 (LWP 17497)]
[New Thread 0x7fff5b7fe700 (LWP 17498)]
[New Thread 0x7fff5affd700 (LWP 17499)]
[New Thread 0x7fff5a7fc700 (LWP 17500)]
[New Thread 0x7fff59ffb700 (LWP 17501)]
[New Thread 0x7fff597fa700 (LWP 17502)]
[New Thread 0x7fff58ff9700 (LWP 17503)]
[New Thread 0x7fff53fff700 (LWP 17504)]
[New Thread 0x7fff537fe700 (LWP 17505)]
[New Thread 0x7fff52ffd700 (LWP 17506)]
[New Thread 0x7fff527fc700 (LWP 17507)]
[New Thread 0x7fff51ffb700 (LWP 17508)]
[New Thread 0x7fff517fa700 (LWP 17509)]
[New Thread 0x7fff50ff9700 (LWP 17510)]
[New Thread 0x7fff507f8700 (LWP 17511)]
[New Thread 0x7fff4fff7700 (LWP 17512)]
[New Thread 0x7fff4f7f6700 (LWP 17513)]
[New Thread 0x7fff4eff5700 (LWP 17514)]
[New Thread 0x7fff4e7f4700 (LWP 17515)]
[New Thread 0x7fff4dff3700 (LWP 17516)]
[New Thread 0x7fff4d7f2700 (LWP 17517)]
[New Thread 0x7fff4cff1700 (LWP 17518)]
[New Thread 0x7fff4c7f0700 (LWP 17519)]
[New Thread 0x7fff4bfef700 (LWP 17520)]
[New Thread 0x7fff4b7ee700 (LWP 17521)]
[New Thread 0x7fff4afed700 (LWP 17522)]
[New Thread 0x7fff411eb700 (LWP 17523)]
[New Thread 0x7fff409ea700 (LWP 17524)]
[New Thread 0x7fff401e9700 (LWP 17525)]
[New Thread 0x7fff3f9e8700 (LWP 17526)]
[New Thread 0x7fff3f1e7700 (LWP 17527)]
[New Thread 0x7fff3e9e6700 (LWP 17528)]
[New Thread 0x7fff3e1e5700 (LWP 17529)]
[New Thread 0x7fff3c5e4700 (LWP 17533)]
[New Thread 0x7fff3bde3700 (LWP 17534)]
[New Thread 0x7fff3b5e2700 (LWP 17535)]
[New Thread 0x7fff317e0700 (LWP 17536)]
[New Thread 0x7fff30fdf700 (LWP 17537)]
[New Thread 0x7fff307de700 (LWP 17538)]

Thread 1 "kamoso" received signal SIGSEGV, Segmentation fault.
0x7fffe3cb58d8 in linear_to_ytiled (mem_copy_align16=, 
mem_copy=, swizzle_bit=0, src_pitch=20, 
src=0x7fffb4973440 "", dst=0x7ffe7681e000 "", y3=32, y0=21845, 
x3=, x2=16, x1=, x0=0)
at ../src/mesa/drivers/dri/i965/intel_tiled_memcpy.c:364
364 ../src/mesa/drivers/dri/i965/intel_tiled_memcpy.c: No such file or 
directory.
#0  0x7fffe3cb58d8 in linear_to_ytiled (mem_copy_align16=, 
mem_copy=, swizzle_bit=0, src_pitch=20, 
src=0x7fffb4973440 "", dst=0x7ffe7681e000 "", y3=32, y0=21845, 
x3=, x2=16, x1=, x0=0)
at ../src/mesa/drivers/dri/i965/intel_tiled_memcpy.c:364
xo = 
swizzle = 0
xo0 = 0
swizzle1 = 0
yo = 
bytes_per_column = 512
y1 = 
xo1 = 0
x = 0
column_width = 16
y2 = 32
swizzle0 = 0
column_width = 
bytes_per_column = 
y1 = 
y2 = 
xo0 = 
xo1 = 
swizzle0 = 
swizzle1 = 
x = 
yo = 
xo = 
swizzle = 
xo = 
swizzle = 
xo = 
swizzle = 
#1  linear_to_ytiled_faster (x0=0, x1=, x2=16, x3=, 

Bug#944876: RFS: boogie 2.4.1-0.1 -- verifiable programming language [NMU, RC]

[Adam Borowski]

On Sat, Dec 14, 2019 at 01:52:21PM -0500, Benjamin Barenblat wrote:
> On Tuesday, December 10, 2019, at  6:33 PM +0100, Fabian Wolff wrote:
> > Would you be willing to relicense your work on the Boogie Debian package 
> > under the
> > Expat license? If so, and with your consent documented here in the bug 
> > tracker for
> > #944876, I'd simply change the license to Expat in debian/copyright.
> 
> That’s completely fine. I hereby relicense my work in that package under
> the Expat license.
> 
> I’d appreciate it if you’d be willing to update the copyright headers in
> the relevant files when you switch the license.

Fabian: I assume you'll be making a new upload to mentors.  If so, please
axe prebuilt Windows code from the tarball.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ A MAP07 (Dead Simple) raspberry tincture recipe: 0.5l 95% alcohol,
⣾⠁⢠⠒⠀⣿⡁ 1kg raspberries, 0.4kg sugar; put into a big jar for 1 month.
⢿⡄⠘⠷⠚⠋⠀ Filter out and throw away the fruits (can dump them into a cake,
⠈⠳⣄ etc), let the drink age at least 3-6 months.

Bug#941774: lintian: False positive for symbols-file-contains-current-version-with-debian-revision

[Felix Lechner]

Hi Ross,

On Sat, Oct 12, 2019 at 8:39 PM Ross Vandegrift  wrote:
>
> I'm seeing a similar false positive:

I do not. The symbols file in the control section of
libephysics1_1.21.1-5+b1_amd64.deb contains the following line:

$ fgrep -- -5 dir2/symbols
 
_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_M_constructIPcEEvT_S7_St20forward_iterator_tag@Base
1.21.1-5+b1

The symbol shows a Debian revision. Lintian is right.

The line furthermore matches Lintian's output:

$ frontend/lintian --no-tag-display-limit
../bugs/symbols/libephysics1_1.21.1-5+b1_amd64.deb
E: libephysics1:
symbols-file-contains-current-version-with-debian-revision on symbol
_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_M_constructIPcEEvT_S7_St20forward_iterator_tag@Base
N: 1 tag overridden (1 warning)

This is not a bug in Lintian (at least not anymore). I will close this
bug after writing to Scott, as well.

As a side note, I was surprised to find 188 additional Debian revisions:

$ fgrep -- -0~eo dir2/symbols | head -5
 ephysics_body_angular_movement_enable_get@Base 1.21.1-0~eo
 ephysics_body_angular_movement_enable_set@Base 1.21.1-0~eo
 ephysics_body_angular_velocity_get@Base 1.21.1-0~eo
 ephysics_body_angular_velocity_set@Base 1.21.1-0~eo
 ephysics_body_back_boundary_add@Base 1.21.1-0~eo

$ fgrep -- -0~eo dir2/symbols | wc -l
188

Finally, I am not sure why some symbols were decoded properly using
the appropriate pattern [1], while the offender is raw 'c++'. Did you
mix C and C++ symbols in the same shared library?

Kind regards
Felix Lechner

[1] https://wiki.debian.org/UsingSymbolsFiles

Bug#916076: [Retesting] kamoso: segmentation fault in GStreamer opening hamburger menu

[Aurélien COUDERC]

[resending with the correct recipients]

Hi John,

thank you for taking the time to report this bug and help make Debian better.

I’m not able to reproduce the bug that you describe here, neither on the 
former 18.04.0-3 version nor on the new 19.08.3 that I’ve just uploaded to 
unstable.
Would you have the possibility to test again and comment here with more 
information if the crash is still reproducible ?


Thanks & happy hacking !
--
Aurélien

Bug#940695: micro-httpd FTCBFS: uses the build architecture compiler

[Sudip Mukherjee]

Hi Helmut,

On Thu, Sep 19, 2019 at 06:07:45AM +0200, Helmut Grohne wrote:
> Source: micro-httpd
> Version: 20051212-15.1
> Tags: patch
> User: debian-cr...@lists.debian.org
> Usertags: ftcbfs

I have marked it as fixed on micro-httpd/20051212-16. Please test and
and I can close the bug after that.

--
Regards
Sudip

Bug#883310: [Retesting] kamoso: Text on buttons disappears

[Aurélien COUDERC]

Hi Victor,

thanks for taking the time to report this bug and help making Debian better.

I cannot reproduce the issue you describe here, but I see you’re using kamoso 
on a GTK or GNOME based desktop which is not my case.
Would you be able to test again on the version 19.08.3-1 that I just uploaded 
to unstable and confirm if you still experience the issue ?

It may be that we’re missing some dependencies that would always be there on a 
KDE / Plasma install but not on other desktops.
But if you could tell that it fixed with the new upstream version it would help 
me avoid some long and unfunny dependency hunting. :-)


Happy hacking !
--
Aurélien

Bug#916076: [Retesting] kamoso: segmentation fault in GStreamer opening hamburger menu

[Aurélien COUDERC]

control: tags -1 + moreinfo

Hi John,

thank you for taking the time to report this bug and help make Debian better.

I’m not able to reproduce the bug that you describe here, neither on the 
former 18.04.0-3 version nor on the new 19.08.3 that I’ve just uploaded to 
unstable.
Would you have the possibility to test again and comment here with more 
information if the crash is still reproducible ?


Thanks & happy hacking !
--
Aurélien

Bug#946734: rust-addr2line Build-Depends on librust-fallible-iterator-0.1+default-dev which isn't available

[Paul Gevers]

Source: rust-addr2line
Version: 0.7.0-1
Severity: serious
Tags: ftbfs

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Dear maintainers,

Your package was never build on a buildd, and was rescheduled 117 days
ago. Since then, the status is BD-Uninstallable. Can you please make sure that
we can actually build packages in Debian?

Please check https://release.debian.org/transitions/html/rust.html, there is at
least one more packages like this one: rust-nitrokey-test. Can/should I
reschedule all the red packages or will that fail anyways?

Paul

https://buildd.debian.org/status/package.php?p=rust-addr2line

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

Kernel: Linux 5.3.0-2-amd64 (SMP w/2 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, 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

-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEEWLZtSHNr6TsFLeZynFyZ6wW9dQoFAl31WOcACgkQnFyZ6wW9
dQp0Zgf/bA4UCAQxjVR5DtcSOLUqu6EUE95xVachj5+CU2Q9Qaxg9ZNn78vZs0QN
B0gitIAwPrCo+lMN3/asZcQNvpS/XPPo+7qlZkU5/bFlR/ND29wbccz+RdLm7f6k
Air/SA73bX6W2jYpS3Jrt3bqe7HX9T7ta7f3YBd0hCdAAvH1zVs9eyy//YOTRmxi
quU1I9rx5+JVJcw788iqMrof3vtns4CWwxkEMhQENXKF6xC5W43nIHBk/W9Ad6f4
LUGhutDXosX8cFJdV10Geowfxx7B8e1dyEHTOPh/RM20gYxbuiHQUvB0DNd6lyDZ
I7f7D7MbB808tAKmG5iTD+npXMEGSw==
=jGM4
-END PGP SIGNATURE-

Bug#946727: interimap: typo in html documentation: though -> through

[Jonas Smedegaard]

[ sent again, with ASCII-only headers to please Debian MTA ]

Quoting Guilhem Moulin (2019-12-14 21:50:34)
> On Sat, 14 Dec 2019 at 21:06:14 +0100, Jonas Smedegaard wrote:
> > Reads more sensible to me with word "though" replaced by "through".
> 
> Ah yeah, thanks!

You're most welcome.  Super excited to try the new pre-release!


> Removed “html” in the title: the source, in pandoc markdown, can be 
> found under /usr/share/doc/interimap.

Yeah, I kinda knew from how you mentioned it in changelog, but couldn't 
wait for the package to arrive at my doorstep and wanted to be honest 
about where I saw it.


> There is also a suggested workflow for multi-remote setups under the 
> same directory, by the way (though again pure IMAP, not sure how that 
> plays along with non IMAP-based MUAs).

Yup - in fact I went straight for the multi-remote setup documentation, 
and only read the introduction when it referenced a wrapper script 
there.

Thanks a lot for this pre-release,

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Bug#922658: linux-image-4.19.0-0.bpo.2-amd64: NETDEV WATCHDOG: enp1s0f1 (r8169): transmit queue 0 timed out

[Felipe Gaitán]

is this bugreport still open?  Because I no longer have this laptop, 
therefore can no longer give a status.

Sorry.  Please close it. (unless you got a reason to no doing so)

Bug#946733: rust-curl: autopkgtest failure: no matching package named `openssl-probe` found

[Paul Gevers]

Source: rust-curl
Version: 0.4.25-1
Severity: serious
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: regression

Dear maintainers,

With a recent upload of rust-curl you added an autopkgtest to your
package, great. However, it fails. I copied some of the output at the
bottom of this report.

Currently this regression is blocking the migration to testing [1]. Can
you please investigate the situation and fix it?

More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=rust-curl

https://ci.debian.net/data/autopkgtest/testing/amd64/r/rust-curl/3527290/log.gz

autopkgtest [09:36:59]: test command9: [---
debian cargo wrapper: options, profiles, parallel: ['parallel=2'] [] ['-j2']
debian cargo wrapper: rust_type, gnu_type: x86_64-unknown-linux-gnu,
x86_64-linux-gnu
debian cargo wrapper: linking /usr/share/cargo/registry/* into
/tmp/tmp.VN0uRNJyf9/registry/
debian cargo wrapper: options, profiles, parallel: ['parallel=2'] [] ['-j2']
debian cargo wrapper: rust_type, gnu_type: x86_64-unknown-linux-gnu,
x86_64-linux-gnu
debian cargo wrapper: running subprocess (['env', 'RUST_BACKTRACE=1',
'/usr/bin/cargo', '-Zavoid-dev-deps', 'test', '--verbose', '--verbose',
'-j2', '--target', 'x86_64-unknown-linux-gnu', '--all-targets',
'--features', 'static-ssl'],) {}
error: no matching package named `openssl-probe` found
location searched: registry `https://github.com/rust-lang/crates.io-index`
required by package `curl v0.4.25 (/usr/share/cargo/registry/curl-0.4.25)`
autopkgtest [09:37:00]: test command9: ---]



signature.asc
Description: OpenPGP digital signature

Bug#946732: python-django-braces: autopkgtest failure: No module named 'django_braces'

[Paul Gevers]

Source: python-django-braces
Version: 1.13.0-1
Severity: serious
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: regression

Dear maintainers,

With a recent upload of python-django-braces you added an autopkgtest to
your package, great. However, it fails. I copied some of the output at
the bottom of this report. The layout of your package doesn't seem to be
working with autodep8 out of the box. However, autodep8 recently grew
support [1] for modules named differently than the package name suggest.
Please follow the documentation.

Currently this regression is blocking the migration to testing [2]. Can
you please investigate the situation and fix it?

More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1]
https://salsa.debian.org/ci-team/autodep8/commit/f05b0babe551ac512a3543758d21ec329ec0e58d
[2] https://qa.debian.org/excuses.php?package=python-django-braces

https://ci.debian.net/data/autopkgtest/testing/amd64/p/python-django-braces/3483366/log.gz
autopkgtest [15:23:51]: test autodep8-python3: set -e ; for py in
$(py3versions -r 2>/dev/null) ; do cd "$AUTOPKGTEST_TMP" ; echo "Testing
with $py:" ; $py -c "import django_braces; print(django_braces)" ; done
autopkgtest [15:23:51]: test autodep8-python3: [---
Testing with python3.7:
Traceback (most recent call last):
  File "", line 1, in 
ModuleNotFoundError: No module named 'django_braces'
autopkgtest [15:23:52]: test autodep8-python3: ---]




signature.asc
Description: OpenPGP digital signature

Bug#946727: interimap: typo in html documentation: though → through

[Guilhem Moulin]

Control: tag -1 pending
Control: retitle -1 interimap: typo in documentation: though → through

Hi,

On Sat, 14 Dec 2019 at 21:06:14 +0100, Jonas Smedegaard wrote:
> Reads more sensible to me with word "though" replaced by "through".

Ah yeah, thanks!  Removed “html” in the title: the source, in pandoc
markdown, can be found under /usr/share/doc/interimap.  There is also a
suggested workflow for multi-remote setups under the same directory, by
the way (though again pure IMAP, not sure how that plays along with non
IMAP-based MUAs).

Cheers,
-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#864997: DEP-5 copyright checker

[Felix Lechner]

Hi Luke,

> so i wrote a program called copyright_check.py which covers every single
> possibility of what is correctly matched, what is incorrectly matched,
> and what is missing.

That's great! I have been looking for such a tool.

> copies of the original program are being made and distributed arbitrarily.
> one such copy (which ironically violates copyright) is here:
> https://fossies.org/dox/drizzle-7.2.4-alpha/copyright__check_8py_source.html
>
> one version may also be found here:
> https://github.com/jaredly/pyjamas/blob/master/contrib/copyright_check.py

Does it violate your copyright or someone else's? I see an assertion
of your authorship only in the second file. Neither file shows license
terms.

For Debian's benefit, would you please reply with a statement that the
program is solely your work? Please also attach a copy (not a link) or
alternatively, a pointer to a repository under your control. The copy
you send must further include the terms of your DFSG-compliant license
(preferably GPL-2+, which would be like Lintian) or a statement
placing your work in the public domain. Thank you!

Two more things: First, Lintian runs on Perl. Did you ever port your
program to any other languages? Second, I plan to rework the copyright
check, which has many open bugs. Please let me know if are interested
in helping:


https://salsa.debian.org/lintian/lintian/blob/master/checks/debian/copyright.pm
https://bugs.debian.org/cgi-bin/pkgreport.cgi?repeatmerged=no=lintian

Kind regards
Felix Lechner

Bug#946731: oz: autopkgtest failure on arm64: This host does not support virtualization type kvm or qemu for TDL arch (i686)

[Paul Gevers]

Source: oz
Version: 0.17.0-2
Severity: serious
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: regression

Dear maintainers,

You package has an autopkgtest, great. However, it fails on arm64. I
copied some of the output at the bottom of this report.

Currently this regression is blocking the migration to testing [1]. Can
you please investigate the situation and fix it? If you upload the fix,
make sure you upload source only, we don't allow binaries built by the
maintainer to migrate to testing and arch:all can't be binNMU'ed.

More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=oz

https://ci.debian.net/data/autopkgtest/testing/arm64/o/oz/3457325/log.gz

=== FAILURES
===
___ test_fedora_core
___

def test_fedora_core():
for version in ["1", "2", "3", "4", "5", "6"]:
for arch in ["i386", "x86_64"]:
for installtype in ["url", "iso"]:
runtest(distro='FedoraCore', version=version, arch=arch,
>   installtype=installtype, expect_success=True)

tests/factory/test_factory.py:122:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _
tests/factory/test_factory.py:98: in runtest
oz.GuestFactory.guest_factory(tdl, config, None)
/usr/lib/python3/dist-packages/oz/GuestFactory.py:103: in guest_factory
diskbus, macaddress)
/usr/lib/python3/dist-packages/oz/FedoraCore.py:97: in get_class
macaddress)
/usr/lib/python3/dist-packages/oz/FedoraCore.py:65: in __init__
macaddress)
/usr/lib/python3/dist-packages/oz/RedHat.py:46: in __init__
url_allowed, macaddress)
/usr/lib/python3/dist-packages/oz/Linux.py:39: in __init__
url_allowed, macaddress)
/usr/lib/python3/dist-packages/oz/Guest.py:1315: in __init__
url_allowed, macaddress)
/usr/lib/python3/dist-packages/oz/Guest.py:248: in __init__
self.connect_to_libvirt()
/usr/lib/python3/dist-packages/oz/Guest.py:129: in connect_to_libvirt
self._discover_libvirt_type()
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _

self = 

def _discover_libvirt_type(self):
"""
Internal method to discover the libvirt type (qemu, kvm, etc) that
we should use, if not specified by the user.
"""
if self.libvirt_type is None:
doc = lxml.etree.fromstring(self.libvirt_conn.getCapabilities())

# Libvirt calls the old intel 32-bit architecture i686, while we
# refer to it as i386.  Do the mapping here, since we need
to look
# up the libvirt name.
libvirtarch = self.tdl.arch
if libvirtarch == 'i386':
libvirtarch = 'i686'

if
len(doc.xpath("/capabilities/guest/arch[@name='%s']/domain[@type='kvm']"
% (libvirtarch))) > 0:
self.libvirt_type = 'kvm'
elif
len(doc.xpath("/capabilities/guest/arch[@name='%s']/domain[@type='qemu']"
% (libvirtarch))) > 0:
self.libvirt_type = 'qemu'
else:
>   raise oz.OzException.OzException("This host does not
support virtualization type kvm or qemu for TDL arch (%s)" % (libvirtarch))
E   oz.OzException.OzException: This host does not support
virtualization type kvm or qemu for TDL arch (i686)

/usr/lib/python3/dist-packages/oz/Guest.py:78: OzException
- Captured stdout call
-
Testing FedoraCore-1-i386-url
_ test_fedora
__

def test_fedora():
for version in ["7", "8", "9", "10", "11", "12", "13", "14",
"15", "16",
"17", "18", "19", "20", "21", "22", "23", "24",
"25", "26",
"27", "28"]:
for arch in ["i386", "x86_64"]:
for installtype in ["url", "iso"]:
runtest(distro='Fedora', version=version, arch=arch,
>   installtype=installtype, expect_success=True)

tests/factory/test_factory.py:137:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _
tests/factory/test_factory.py:98: in runtest
oz.GuestFactory.guest_factory(tdl, config, None)
/usr/lib/python3/dist-packages/oz/GuestFactory.py:103: in guest_factory
diskbus, macaddress)
/usr/lib/python3/dist-packages/oz/Fedora.py:323: in get_class
output_disk, macaddress, None)
/usr/lib/python3/dist-packages/oz/Fedora.py:250: in __init__
macaddress, self.config.use_yum)
/usr/lib/python3/dist-packages/oz/RedHat.py:729: in __init__
initrdtype, macaddress)
/usr/lib/python3/dist-packages/oz/RedHat.py:46: in __init__
url_allowed, macaddress)

Bug#874375: ebtables: 32 bit binary cannot communicate with 64 bit kernel on arm platform

[Tomas Janousek]

Hi Alberto,

On Sat, Dec 14, 2019 at 09:26:06PM +0100, Alberto Molina Coballes wrote:
> [...]
> Now, installing i386 ebtables userspace tool on an amd64 kernel I can't 
> reproduce this bug.
> [...]
> In all the combinations tested the behaviour was the expected not the 
> reported in your bug. Please, reply this message with any other information 
> needed if the bug remains in other scenario.

I have crossgraded to amd64 in the meantime so obviously I can't reproduce it
in this environment, and I think it'd be a waste of time trying to set up a VM
and try what you already tried. So as far as I'm concerned, this can be
closed.

Thanks.

-- 
Tomáš Janoušek, a.k.a. Pivník, a.k.a. Liskni_si, http://work.lisk.in/

Bug#874375: ebtables: 32 bit binary cannot communicate with 64 bit kernel on arm platform

[Alberto Molina Coballes]

Hi Wang and Tomáš,

When I adopted ebtables in 2018 and I was initially focused on putting the 
package in shape, but this bug has remained unattended for too many time.

Now, installing i386 ebtables userspace tool on an amd64 kernel I can't 
reproduce this bug.

I've tested both ebtables-legacy (provided by ebtables package) and 
ebtables-nft (provided by iptables package) on buster and sid, so I think that 
this bug has been solved at any moment since you reported on ebtables 
2.0.10.4-3.

ebtables versions tested:

buster:
ebtables:i386 2.0.10.4+snapshot20181205-3 i386
iptables 1.8.2-4
linux-image-4.19.0-6-amd64 4.19.67-2+deb10u2

sid:
ebtables:i386 2.0.11-1
iptables 1.8.4-1 
linux-image-5.3.0-3-amd64 5.3.15-1

In all the combinations tested the behaviour was the expected not the reported 
in your bug. Please, reply this message with any other information needed if 
the bug remains in other scenario.

Regards,

Alberto

Bug#946730: libconfig-model-itself-perl: autopkgtest needs update for new version of libconfig-model-perl

[Paul Gevers]

Source: libconfig-model-itself-perl
Version: 2.018-2
Severity: serious
Tags: sid bullseye
User: debian...@lists.debian.org
Usertags: needs-update
Control: affects -1 src:libconfig-model-perl
Control: affects -1 src:libconfig-model-tkui-perl

[X-Debbugs-CC: debian...@lists.debian.org,
libconfig-model-p...@packages.debian.org]

Dear maintainers,

With a recent upload of libconfig-model-perl the autopkgtest of
libconfig-model-itself-perl fails in testing when that autopkgtest is
run with the binary packages of libconfig-model-perl from unstable. It
passes when run with only packages from testing. In tabular form:
passfail
libconfig-model-perlfrom testing2.137-1
libconfig-model-itself-perl from testing2.018-2
all others  from testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration of
libconfig-model-perl (and libconfig-model-tkui-perl) to testing [1]. Of
course, libconfig-model-perl shouldn't just break your autopkgtest (or
even worse, your package), but it seems to me that the change in
libconfig-model-perl was intended and your package needs to update to
the new situation.

If this is a real problem in your package (and not only in your
autopkgtest), the right binary package(s) from libconfig-model-perl
should really add a versioned Breaks on the unfixed version of (one of
your) package(s). Note: the Breaks is nice even if the issue is only in
the autopkgtest as it helps the migration software to figure out the
right versions to combine in the tests.

More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=libconfig-model-perl

https://ci.debian.net/data/autopkgtest/testing/amd64/libc/libconfig-model-itself-perl/3660573/log.gz

not ok 6 - Compared the 2 full dumps

#   Failed test 'Compared the 2 full dumps'
#   at t/load_write_itself.t line 68.
#  got: '@@ -5,9 +5,11 @@
#  refer_to="! class"
#  computed_refer_to
#use_eval=0
# +  allow_override=0
#use_as_upstream_default=0 -
#  compute
#use_eval=0
# +  allow_override=0
#use_as_upstream_default=0 -
#  migrate_from
#use_eval=0 -
# @@ -20,6 +22,7 @@
#  value_type=uniline
#  compute
#use_eval=0
# +  allow_override=0
#use_as_upstream_default=0 -
#  migrate_from
#use_eval=0 -
# @@ -32,6 +35,7 @@
#  value_type=uniline
#  compute
#use_eval=0
# +  allow_override=0
#use_as_upstream_default=0 -
#  migrate_from
#use_eval=0 -
# @@ -44,6 +48,7 @@
#  value_type=enum
#  compute
#use_eval=0
# +  allow_override=0
#use_as_upstream_default=0 -
#  migrate_from
#use_eval=0 -
# @@ -60,6 +65,7 @@
#  value_type=boolean
#  compute
#use_eval=0
# +  allow_override=0
#use_as_upstream_default=0 -
#  migrate_from
#use_eval=0 -
# @@ -73,6 +79,7 @@
#  value_type=boolean
#  compute
#use_eval=0
# +  allow_override=0
#use_as_upstream_default=0 -
#  migrate_from
#use_eval=0 -
# @@ -86,6 +93,7 @@
#  value_type=boolean
#  compute
#use_eval=0
# +  allow_override=0
#use_as_upstream_default=0 -
#  migrate_from
#use_eval=0 -
# @@ -99,6 +107,7 @@
#  value_type=uniline
#  compute
#use_eval=0
# +  allow_override=0
#use_as_upstream_default=0 -
#  migrate_from
#use_eval=0 -
# @@ -111,6 +120,7 @@
#  value_type=uniline
#  compute
#use_eval=0
# +  allow_override=0
#use_as_upstream_default=0 -
#  migrate_from
#use_eval=0 -
# @@ -123,6 +133,7 @@
#  value_type=uniline
#  compute
#use_eval=0
# +  allow_override=0
#use_as_upstream_default=0 -
#  migrate_from
#use_eval=0 -
# @@ -140,6 +151,7 @@
#  value_type=enum
#  compute
#use_eval=0
# +  allow_override=0
#use_as_upstream_default=0 -
#  migrate_from
#use_eval=0 -
# @@ -174,6 +186,7 @@
#  value_type=string
#  compute
#use_eval=0
# +  allow_override=0
#use_as_upstream_default=0 -
#  migrate_from
#use_eval=0 -
# @@ -186,6 +199,7 @@
#  value_type=string
#  compute
#use_eval=0
# +  allow_override=0
#use_as_upstream_default=0 -
#  migrate_from
#use_eval=0 -
# @@ -197,6 +211,7 @@
#  value_type=string
#  compute
#use_eval=0
# +  allow_override=0
#use_as_upstream_default=0 -
#  migrate_from
#use_eval=0 -
# @@ -214,6 +229,7 @@
#value_type=uniline
#compute
#  use_eval=0
# +allow_override=0
#  use_as_upstream_default=0 -
#migrate_from
#  

Bug#946729: findutils: `find path/ -name file*` fails to find files

[Michel Le Bihan]

Package: findutils
Version: 4.6.0+git+20190209-2
Severity: normal

Dear Maintainer,

When I use find with the -name option, sometimes it fails to find files
that do exist. Example:

tape@storage ~/backup $ find db/ -name mysql_dump* | head
db/mysql_dump-201912100345.tar.bz2
db/mysql_dump-201912070345.tar.bz2
db/mysql_dump-201912010345.tar.bz2
db/mysql_dump-201912060345.tar.bz2
db/mysql_dump-201912080345.tar.bz2
db/mysql_dump-201912030345.tar.bz2
db/mysql_dump-201912140345.tar.bz2
db/mysql_dump-201912110345.tar.bz2
db/mysql_dump-201912120345.tar.bz2
db/mysql_dump-201911280345.tar.bz2
tape@storage ~/backup $ find db/ -name pg_dump*
tape@storage ~/backup $ ls db/pg_dump* | head
db/pg_dump-201910010445.tar.bz2
db/pg_dump-201910020445.tar.bz2
db/pg_dump-201910030445.tar.bz2
db/pg_dump-201910040445.tar.bz2
db/pg_dump-201910050445.tar.bz2
db/pg_dump-201910060445.tar.bz2
db/pg_dump-201910070445.tar.bz2
db/pg_dump-201910080445.tar.bz2
db/pg_dump-201910090445.tar.bz2
db/pg_dump-201910100445.tar.bz2


find found files that start with mysql_dump in the name, but failed to
find files with manes starting with pg_dump.

I don't think it is related to the encoding issue. My LANG is
`en_US.UTF-8` and all file names are encoded `UTF-8`.

The filesystem is XFS if that matters.

Michel Le Bihan

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

Kernel: Linux 4.19.0-6-amd64 (SMP w/1 CPU core)
Kernel taint flags: TAINT_WARN
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 findutils depends on:
ii  libc62.28-10
ii  libselinux1  2.8-1+b1

findutils recommends no packages.

Versions of packages findutils suggests:
ii  mlocate  0.26-3

-- no debconf information

Bug#946728: golang-github-kyokomi-emoji breaks hugo autopkgtest: got "I ❤ Hugo" expected "I ❤️ Hugo"

[Paul Gevers]

Source: golang-github-kyokomi-emoji, hugo
Control: found -1 golang-github-kyokomi-emoji/2.1.0-1
Control: found -1 hugo/0.58.3-1
Severity: serious
Tags: sid bullseye
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: breaks needs-update

Dear maintainers,

With a recent upload of golang-github-kyokomi-emoji the autopkgtest of
hugo fails in testing when that autopkgtest is run with the binary
packages of golang-github-kyokomi-emoji from unstable. It passes when
run with only packages from testing. In tabular form:
 passfail
golang-github-kyokomi-emoji  from testing2.1.0-1
hugo from testing0.58.3-1
all others   from testingfrom testing

I copied some of the output at the bottom of this report.

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

More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=golang-github-kyokomi-emoji

https://ci.debian.net/data/autopkgtest/testing/amd64/h/hugo/3658315/log.gz

--- PASS: TestInsertIsZeroFunc (0.02s)
ERROR 2019/12/13 20:32:33 failed.
--- FAIL: TestTemplateFuncsExamples (1.43s)
template_funcs_test.go:133: transform[0]: got "I ❤ Hugo" expected "I
❤️ Hugo"
FAIL
FAILgithub.com/gohugoio/hugo/tpl/tplimpl1.494s
?   github.com/gohugoio/hugo/tpl/tplimpl/embedded   [no test files]
?   github.com/gohugoio/hugo/tpl/tplimpl/embedded/generate  [no test files]

[...]

--- FAIL: TestEmojify (0.01s)
quicktest.go:306:
error:
  values are not equal
got:
  "I ❤ Hugo"
want:
  "I ❤️ Hugo"
stack:

/tmp/autopkgtest-lxc.v8t77u9s/downtmp/autopkgtest_tmp/obj-x86_64-linux-gnu/src/github.com/gohugoio/hugo/tpl/transform/transform_test.go:56
c.Assert(result, qt.Equals, test.expect)

FAIL
FAILgithub.com/gohugoio/hugo/tpl/transform  0.057s



signature.asc
Description: OpenPGP digital signature

Bug#946641: stops: Mark stops as 'Multi-Arch: foreign'

[Fabian Greffrath]

Am Freitag, den 13.12.2019, 20:45 +0100 schrieb Olivier Humbert:
> I just did (after reworking these) there: 
> https://salsa.debian.org/multimedia-team/stops/commit/437295d30fd719f14fa21b7b4c423c5393d3d528

Top, thanks!

 - Fabian



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

Bug#946727: interimap: typo in html documentation: though → through

[Jonas Smedegaard]

Package: interimap
Version: 0.5~rc-1
Severity: minor
Tags: upstream

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi Guilhem,

Seems https://guilhem.org/interimap/getting-started.html contains a typo:

> by seeing both local and remote mail storage though the same “IMAP lens”

Reads more sensible to me with word "though" replaced by "through".

Thanks,

 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAl31QLMACgkQLHwxRsGg
ASE+Kw//c97LNHMurVOwtz6pFoRU80TXLdcopnGNGoYZ7yF7mLpkCtI+mn3JTio2
NTUkey6wlKiw1S2c+4Md4jCRRpT57jMfsvTl9aa/lD2oanr+7wdkJ/Gd9Oq+yHNU
FSq52C+QcuCXRccMs81y2dIPq3BBMRRxRH6YtEgntfNkhj5rJYe8tA4ZJ0cdQGZP
O4oys/E6vGJQGpJy3Sq5ZPSEhWWHpIMQ1acIUzrKxLh90qqSbGh/vlvRK/dM4/+a
K07a1ch6aiKZ+hNQ8ExwTjS29oBRcq3nFr8Tw/Edl0wShYyQR/JZ24zy/brqxacj
1bIV29blStw7FyAAmGAfTO+5NxDkoZwnSMhQEgiTczWHgVas4cyQYjppjqJZlz+D
/TWMWBuApiqM0t1qHx0X4z55nMCEQz3mtRYO6wXzCjLwUsas15/erDYFTkZeLNwz
vsMDoPkj3yUxF+zbnbCE4006D+iixKKE0Cf1/Z/mE9HoRB77+q/H0XtlIt4ySFza
xzKGAymUpHZnnQKxZ8SKhoot/zHXFM3oQkmcV8UB85O1iBwBlF1OTHnJZ8tUu2gt
smkvRWvVi4I/5oeg3O+tUyYLIxAqDPxel8sO9bV2UB6LTs+yFWfDoBkm4ieZAv2B
RJz22cjGgqbl0sgjXr2IVwmFkLKlWev1B4rqUSWI6NatkHheals=
=Vtsd
-END PGP SIGNATURE-

Bug#946726: bsdmainutils: [calendar] -a results in loop, sending lots of mail

[Axel]

Package: bsdmainutils
Version: 11.1.2+b1
Severity: important

Dear Maintainer,

   * What led up to the situation?

I created ~/.calendar/calendar and then tried 'sudo calendar -a'. This
causes a loop sending lot's of email. It happens with any calendar
file, e.g. 

cat >$HOME/calendar <
ii  wamerican [wordlist]  2018.04.16-1
pn  whois 

-- no debconf information

Bug#944819: fixed in cyrus-imapd 3.0.12-2

[Paul Gevers]

Hi Xavier,

On 29-11-2019 22:47, Paul Gevers wrote:
> I don't know how CPAN works, but I hope this way of testing remains
> reproducible over the lifetime of a Debian release. I would hate it when
> a passing test turns bad because of changes on the internet At least
> make sure that the test fails gracefully (i.e. with the skippable
> restriction and proper error handling) in case your resources are
> (temporarily) not available. Would it make sense to ship your test
> vectors and other required code in a separate test package.

I don't think it is related, but your test suite has timed out several
times on arm64 (I have added it to the blacklist for now). Can you
please check?

Also, please note
https://lists.ubuntu.com/archives/ubuntu-devel/2019-December/040864.html
if ginggs didn't already point you to it.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#946725: lxc: Unprivileged containers fail with 'Failed to mount API filesystems'

[bauerfichtner]

Package: lxc
Version: 1:3.1.0+really3.0.3-8
Severity: important

Dear Maintainer,

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

   * What led up to the situation?
 Created an unprivileged container.
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
 Tried to start the unprivileged container.
  root@host:~# lxc-start --foreground --name testcontainer
  Failed to mount cgroup at /sys/fs/cgroup/systemd: Permission denied
  [!!] Failed to mount API filesystems.
  Exiting PID 1...
   * What was the outcome of this action?
 Container exited.
   * What outcome did you expect instead?
 Container starting up.
   * Additional information
 Debian buster amd64 container was created using 
 'lxc-create --template download'.
 Unprivileged containers created the same way run 
 fine on the same host (only difference in configuration are the 
 lxc.idmap lines in the container configuration.

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

Kernel: Linux 4.19.0-6-amd64 (SMP w/4 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: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages lxc depends on:
ii  debconf [debconf-2.0]  1.5.71
ii  libc6  2.28-10
ii  libcap21:2.25-2
ii  libgnutls303.6.7-4
ii  liblxc11:3.1.0+really3.0.3-8
ii  libseccomp22.3.3-4
ii  libselinux12.8-1+b1
ii  lsb-base   10.2019051400

Versions of packages lxc recommends:
ii  apparmor 2.13.2-10
ii  bridge-utils 1.6-2
ii  debootstrap  1.0.114
ii  dirmngr  2.2.12-1+deb10u1
ii  dnsmasq-base [dnsmasq-base]  2.80-1
ii  gnupg2.2.12-1+deb10u1
ii  iproute2 4.20.0-2
ii  iptables 1.8.2-4
ii  libpam-cgfs  1:3.1.0+really3.0.3-8
ii  lxc-templates3.0.3-1
ii  lxcfs3.0.3-2
ii  nftables 0.9.0-2
ii  openssl  1.1.1d-0+deb10u2
ii  rsync3.1.3-6
ii  uidmap   1:4.5-1.1

Versions of packages lxc suggests:
pn  btrfs-progs  
ii  lvm2 2.03.02-3
pn  python3-lxc  

-- Configuration Files:
/etc/lxc/default.conf changed:
lxc.net.0.type = veth
lxc.net.0.link = br0
lxc.net.0.flags = up
lxc.net.0.hwaddress = 00:16:3e:xx:xx:xx
lxc.start.auto = 0
lxc.idmap = u 0 886432 65536
lxc.idmap = g 0 886432 65536
lxc.cgroup.memory.limit_in_bytes = 256M
lxc.cgroup.cpuset.cpus = 3
lxc.apparmor.profile = unconfined

-- debconf information:
* lxc/auto_update_config: true

Bug#946723: openjdk-14: Please build with --enable-deprecated-ports=yes on sparc64

[John Paul Adrian Glaubitz]

On 12/14/19 7:36 PM, John Paul Adrian Glaubitz wrote:
> Thus, in order to build OpenJDK 14 on sparc64, we need to pass the
> following extra configure option
> 
> --enable-deprecated-ports=yes
> 
> which the attached patch does.

That patch was bogus. The attached patch should be correct.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
diff -Nru old/openjdk-14-14~27/debian/rules new/openjdk-14-14~27/debian/rules
--- old/openjdk-14-14~27/debian/rules	2019-12-14 11:21:53.0 +0100
+++ new/openjdk-14-14~27/debian/rules	2019-12-14 20:18:13.422753260 +0100
@@ -389,6 +389,10 @@
   ZERO_CONFIGURE_ARGS += --with-boot-jdk-jvmargs="-XX:ThreadStackSize=2240"
 endif
 
+ifneq (,$(filter $(DEB_HOST_ARCH), sparc64))
+  DEFAULT_CONFIGURE_ARGS += --enable-deprecated-ports=yes
+endif
+
 ifeq ($(with_check),yes)
   COMMON_CONFIGURE_ARGS += --with-jtreg=/usr
 endif

Bug#946682: debian-installer: Discard transmission by LVM

[Ben Hutchings]

On Fri, 2019-12-13 at 17:15 +0100, Frederic MASSOT wrote:
> Package: debian-installer
> Severity: wishlist
> Tags: d-i
> 
> Dear Maintainer,
> 
> Following a discussion on the list of Proxmox users, I understood
> that only LVM Thin transmits discard commands to SSD.

This seems to be incorrect.  LVM normally uses dm-table, which supports
discard if the underlying device(s) do.

> https://pve.proxmox.com/pipermail/pve-user/2019-December/171187.html
> 
> https://pve.proxmox.com/pve-docs/pve-admin-guide.html#qm_hard_disk_discard
> 
> When creating logical volumes with the Debian installer, they are not
> of the LVM Thin type.
> 
> Can you add to the Debian Installer the ability to create logical
> volume with thin provisioning?

"Thin provisioning" is a device-mapper layer that allows assigning more
logical storage space than the underlying physical storage.  Newly
written blocks are allocated from the physical storage pool and
discarded blocks are returned to the pool.

This can be appropriate for disk server / VM host applications where
storage can be over-committed to VMs and more physical storage will be
added to the pool depending on actual need.  It does not seem to be
appropriate for the OS installation and therefore should not be offered
in the installer.

Ben.

-- 
Ben Hutchings
Anthony's Law of Force: Don't force it, get a larger hammer.




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

Bug#946724: dh-elpa: fails on native package versions with '+'

[Roland Rosenfeld]

Package: dh-elpa
Version: 2.0.2
Severity: normal

Dear Maintainer,

trying to build lbdb with version 0.49+foo fails when calling
dh_elpa with the following message:

   dh_elpa
Invalid version syntax: `0.49+foo'
dh_elpa: emacs -batch -Q -l package --eval (add-to-list 'package-directory-list 
"/usr/share/emacs/site-lisp/elpa") --eval (add-to-list 'package-directory-list 
"/usr/share/emacs/site-lisp/elpa-src") -f package-initialize -l dh-elpa.el -f 
dhelpa-batch-install-directory 
debian/elpa-lbdb//usr/share/emacs/site-lisp/elpa-src 
/build/lbdb-0.49+foo/debian/.debhelper/elpa/lbdb 
/build/lbdb-0.49+foo/debian/.debhelper/elpa 1552316645 returned exit code 255
make: *** [debian/rules:15: binary] Error 255

(see https://salsa.debian.org/roland/lbdb/-/jobs/455490 for another
example).

I can reproduce the same behavior with dh-elpa 1.16 on buster as well
as with 2.0.2 on sid.

Using the "normal" version number 0.49 doesn't trigger the issue but
changing it to 0.49+foo or the like always triggers above failure.

According to deb-version(7) and policy chapter 5.6.12 the upstream
version of a package is allowed to contain a plus sign, so 0.49+foo is
a valid version number.

Greetings
Roland

Bug#907727: Empty directory is already present in orig tarball

[Russ Allbery]

Felix Lechner  writes:

> It is actionable in that we can contact upstream (if the project is
> alive), but it will not improve the relationship. The tag is a
> widespread problem in the archive and a nuisance to many people. The tag
> should be removed. May I please retitle this bug?

Sure, yes, please go ahead.  After thinking about this some more, I agree
with your reasoning.

-- 
Russ Allbery (r...@debian.org)  

Bug#890253: [Pkg-javascript-devel] node-jest

[Jonas Smedegaard]

Quoting Xavier (2019-12-14 19:37:23)
> Le 14/12/2019 à 19:10, Xavier a écrit :
> > I updated node-jest. Build is OK, TODO: remove or rebuild 
> > debian/build_modules compiled files (see lintian output)
> 
> TODO also: embed or package missing node modules (prompt,...)

Please write TODO items in debian/TODO of the package itself.

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Bug#946398: Downgrading severity now that certainty of fixer is downgraded

[Jelmer Vernooij]

severity 946398 normal
thanks

I'm going to downgrade the severity of this bug, since this fixer is
no longer run by default. lintian-brush needs to be forced to run its
experimental fixers.

My plan is to improve the quality of the fixer before upgrading its
certainty, and hopefully also add a fixer for removing superfluous
dependencies on lsb-base.

-- 
Jelmer Vernooij 
PGP Key: https://www.jelmer.uk/D729A457.asc


signature.asc
Description: PGP signature

Bug#907727: Empty directory is already present in orig tarball

[Felix Lechner]

Hi Russ,

On Fri, Oct 25, 2019 at 1:40 PM Russ Allbery  wrote:
>
> To me, an override implies that Lintian is wrong, and I don't think it
> is.

Why did you file a bug report? Please use an override. :)

Joking aside, I do not think you are right. An override indicates the
maintainer will not address something. When Lintian is wrong, people
file bug reports.

> (Whether the tag should exist is a different question; not all
> problems are worth fixing.)

The tag is not well-named, but its assertion is undisputed: The
upstream sources contain an empty directory.

Since your upstream is gone there is nothing you can do about it. You
should override it (caveat below).

> It's otherwise unactionable by the maintainer.

It is actionable in that we can contact upstream (if the project is
alive), but it will not improve the relationship. The tag is a
widespread problem in the archive and a nuisance to many people. The
tag should be removed. May I please retitle this bug?

> It's bad practice to ship empty directories
> in tarballs precisely because they're not representable in Git (and
> generally have a tendency to get lost in various ways).

I do not think it is necessarily bad practice to include empty
directories in tarballs, although I would not do so personally. They
are superfluous and should be ignored. If git, pristine-tar or other
tools cannot deal with them in ways that work for their users, those
are bugs over there.

> It means that if anything relied on the directory existing, the directory
> would be recreated by unpacking the source package and whatever relied on
> that would succeed.

Lintian can technically suppress the tag when a file is added the way
you describe (by comparing the patched index against the unpatched
index), but it would go against the spirit of the tag: Upstream
shipped an empty folder. No maintainer addition can change that.

As a side note, I disagree on the use of a placeholder. If the tag is
not removed, I would use an override instead.

Kind regards
Felix Lechner

Bug#944876: RFS: boogie 2.4.1-0.1 -- verifiable programming language [NMU, RC]

[Benjamin Barenblat]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On Tuesday, December 10, 2019, at  6:33 PM +0100, Fabian Wolff wrote:
> Would you be willing to relicense your work on the Boogie Debian package 
> under the
> Expat license? If so, and with your consent documented here in the bug 
> tracker for
> #944876, I'd simply change the license to Expat in debian/copyright.

That’s completely fine. I hereby relicense my work in that package under
the Expat license.

I’d appreciate it if you’d be willing to update the copyright headers in
the relevant files when you switch the license.
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEQbf+q7LkywHKVTMA5ZUVm53A7cMFAl31L2UACgkQ5ZUVm53A
7cO0KQ/+Mms5/suIeB9RC1b7qevboygnTjh5q4jdxnsvwSAN8/e20K3WR1i6MBJm
tP3SMtevHSH5c4h94/EpF0tg2RrJ4kZ5C8jTHN1AtSBsyuIS7bX8VgFADjKN+zKv
apnBCusH5DyUaWS4x6qO9tIBIl+r/oqmVjxbOu3OEwb1AQ7XVVq03yVHzo14RhTY
RK704x4h/5AtiY9YQCK/+5GUw51ZJfQwHevUpfYFe9AMDXGOO/NrUyeciCNTJ0Ue
sm/YMgF7EV13+QMB1sr5WKcJnsv4WagaRIX2SXUawDKHzayHyqiU66Q3JZgV10gE
keLASKx0RxQ+bX/EjZVhAOPlWjV5lIocq+Gwh7bSFVwuBBiudivXTUg1/ahwo4wx
466MrwUHskXy5LBGhmDo4K9fSZYhHAbO7Ou5i+qOT7OWoA/zHQ1rlI1U7nXo8h1n
mFcWuuN7vP2Bwo3HG5oJCwiX6003BGvYFN0DDOfRuaeFtvLPh4l9Z6w6zPGOOtjY
BYq7h9VS04HQk0i3qIUyGUfhqg50knlSOoVU9jQO3DcS1rbmd5WDepFtUbDLywNp
VbfbxOWN02Am9/m2059X9wQBVmIsSjugPvBwiUNgaWAUgcLryHKSBwZJXGGsUj1B
66SKnRNNSzE+z9E5dUuaqIeU1V7wjL/3rhmEbi2nSDIL3vxX7Jc=
=FvnM
-END PGP SIGNATURE-

Bug#919963: One more reason to remove that package

[Markus Koschany]

On Sat, 14 Dec 2019 18:17:01 + Maksim Svobonas 
wrote:
> One more reason to remove that package is here in the comments:
> https://github.com/ib/xarchiver/commit/d0575bcd1321dd0d7b47c242bd355e69067752c6
> 
> Upstream breaks functionality and does not care about LTS distros like Debian.
There is no reason to remove xarchiver from Debian. This bug report is
non-sense. Hence I am going to close it now.



signature.asc
Description: OpenPGP digital signature

Bug#870641:

[dinar qurbanov]

>Do you still have the issue? Which kernel are you running? Are you on stable
>or testing/unstable?

(this letter got to spam, so i answer a bit later). yes, still have.
stable debian 10, 32bit.

Kernel version (/proc/version):
---
Linux version 4.19.0-6-686-pae (debian-ker...@lists.debian.org) (gcc
version 8.3.0 (Debian 8.3.0-6)) #1 SMP Debian 4.19.67-2+deb10u2
(2019-11-11)

-- System Information:
Debian Release: 10.2
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: i386 (i686)

Bug#890253: [Pkg-javascript-devel] node-jest

[Xavier]

Le 14/12/2019 à 19:10, Xavier a écrit :
> Hi,
> 
> I updated node-jest. Build is OK, TODO: remove or rebuild
> debian/build_modules compiled files (see lintian output)

TODO also: embed or package missing node modules (prompt,...)

Bug#946723: openjdk-14: Please build with --enable-deprecated-ports=yes on sparc64

[John Paul Adrian Glaubitz]

Source: openjdk-14
Severity: normal
User: debian-sp...@lists.debian.org
Usertags: sparc64

Hi!

Despite being officially supported by Oracle until at least 2034 [1],
OpenJDK upstream has decided to deprecate the native SPARC port of
Hotspot in OpenJDK 14.

Thus, in order to build OpenJDK 14 on sparc64, we need to pass the
following extra configure option

  --enable-deprecated-ports=yes

which the attached patch does.

Could you include the change for the next upload? I will also try 
to debug the Zero crash over the holidays on sparc64 and will
hopefully provide a patch soon.

Thanks,
Adrian

> [1] 
> https://blogs.oracle.com/solaris/another-update-on-oracle-java-and-oracle-solaris

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
diff -Nru old/openjdk-14-14~27/debian/rules new/openjdk-14-14~27/debian/rules
--- old/openjdk-14-14~27/debian/rules   2019-12-14 11:21:53.0 +0100
+++ new/openjdk-14-14~27/debian/rules   2019-12-14 19:25:27.249410050 +0100
@@ -325,6 +325,10 @@
   CONFIGURE_ARGS += --with-alt-jar=/usr/bin/fastjar
 endif
 
+ifeq (,$(filter $(DEB_HOST_ARCH), $(hotspot_archs) sparc64))
+  CONFIGURE_ARGS += --enable-deprecated-ports=yes
+endif
+
 ifeq (,$(filter $(DEB_HOST_ARCH), $(hotspot_archs)))
   CONFIGURE_ARGS += --enable-zero
 endif

Bug#919963: One more reason to remove that package

[Maksim Svobonas]

One more reason to remove that package is here in the comments:
https://github.com/ib/xarchiver/commit/d0575bcd1321dd0d7b47c242bd355e69067752c6

Upstream breaks functionality and does not care about LTS distros like Debian.

Bug#848825: Overrides behave as intended

[Jérémy Lal]

Le sam. 14 déc. 2019 à 19:14, Felix Lechner  a
écrit :

> Hi Jérémy,
>
> On Sat, Dec 14, 2019 at 10:09 AM Jérémy Lal  wrote:
> >
> >  I saw that lintian has been recently fixed with respect to how overrides
> > were parsed/applied.
>
> I am happy to hear that those changes worked.
>
> > Thanks for the hard work !
>
> Anytime. Why do you add a minified file via patch? And where did you
> get it from?
>

I removed the minified file and added the source as patch.
I think i have put the origin of the file somewhere, either in
debian/copyright or in
the patch description.



>
> Kind regards
> Felix Lechner
>

Bug#890253: node-jest

[Xavier]

Hi,

I updated node-jest. Build is OK, TODO: remove or rebuild
debian/build_modules compiled files (see lintian output)

Bug#946326: python3-reportbug: reportbug runs bugscript in "C" locale

[Sandro Tosi]

On Sat, Dec 7, 2019 at 3:51 PM Nis Martensen  wrote:
>
> On 07 Dec 2019 Changwoo Ryu wrote:
> >
> > reportbug seems to run bugscript in "C" locale. In /usr/lib/python3/dist-
> > packages/reportbug/utils.py:
> >
> > rc = runner('LC_ALL=C %s %s %s' % (handler, pipes.quote(bugscript),
> > pipes.quote(filename)))
> >
> >
> > It prevents the ibus bugscript from getting "locale" command result. For
> > example: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=946201#5
> >
> > I understand that running locale dependent bugscript can be often buggy and
> > confusing, but some bugscripts want the locale dependent behavior. I think
> > settings locale settings should be up to the individual bugscript authors.
>
> When programs called by bugscripts provide output in the user's locale,
> this can make the information unintelligible to the debian maintainer.
> Please see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=546276
> for why the "LC_ALL=C" was introduced ten years ago. I am not sure that
> reverting this is a good idea. It should probably be documented in
> README.developers, so bugscript authors are aware of it.

i've just did that

> Note that reportbug already includes the most important locale
> information in all bug reports by default. In your example, it is this
> line in the "System Information" section of the report:
>   Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8),
> LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8)

mentioning this too

-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Bug#848825: Overrides behave as intended

[Felix Lechner]

Hi Jérémy,

On Sat, Dec 14, 2019 at 10:09 AM Jérémy Lal  wrote:
>
>  I saw that lintian has been recently fixed with respect to how overrides
> were parsed/applied.

I am happy to hear that those changes worked.

> Thanks for the hard work !

Anytime. Why do you add a minified file via patch? And where did you
get it from?

Kind regards
Felix Lechner

Bug#931438: reportbug: While sending an installation-report no checklist was presented

[Sandro Tosi]

> An empty check list in included but NO check list
> was presented to my from reportbug.

that's because the checklist is in the "Other system information"
section, arguably pretty hard to notice. Another GTK+ UI bug..

-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Bug#855380: reportbug: UI offers "Back", but doesn't allow to edit the data

[Sandro Tosi]

> this bug is still present with 7.5.3,

you can considere the GTK+ UI effectively orphaned; if someone wants
to step up and maintainer, we'd welcome that, otherwise only extremely
minimal fixes will be provided.

-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Bug#945263: numpy FTBFS on all

[Rebecca N. Palmer]

Probably because the arch:all build doesn't build python3-numpy (only 
python-numpy-doc), and hence the ls [0] providing the filename for that 
>> evaluates to empty.


The obvious fix (though I haven't tested it) is to wrap this in an "only 
if building arch:any / python3-numpy" conditional.


[0] 
https://salsa.debian.org/python-team/modules/numpy/commit/178302a8042ac98ae4ef5046843579e8b1f4b23a#8756c63497c8dc39f7773438edf53b220c773f67_48_55

Bug#870641: light-locker: More clues -- Unable to resume after blanking xfce4

[Ralph Katz]

Package: light-locker
Version: 1.8.0-3
Followup-For: Bug #870641

More clues to my bug report immediately above:
Unable to resume after blanking xfce4 as follows:
- on ac power, no resume after blanking from light-locker
- on ac power, resumes properly from sleep
- on battery, resumes properly after blanking
- on battery, resumes properly after sleep

No screensavers are installed.
Thanks.

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

Kernel: Linux 4.19.0-6-amd64 (SMP w/4 CPU cores)
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 light-locker depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.30.1-2
ii  libc62.28-10
ii  libcairo21.16.0-4
ii  libdbus-1-3  1.12.16-1
ii  libdbus-glib-1-2 0.110-4
ii  libglib2.0-0 2.58.3-2+deb10u2
ii  libgtk-3-0   3.24.5-1
ii  libpango-1.0-0   1.42.4-7~deb10u1
ii  libpangocairo-1.0-0  1.42.4-7~deb10u1
ii  libsystemd0  241-7~deb10u2
ii  libx11-6 2:1.6.7-1
ii  libxext6 2:1.3.3-1+b2
ii  libxss1  1:1.2.3-1
ii  lightdm  1.26.0-4

light-locker recommends no packages.

light-locker suggests no packages.

-- no debconf information



signature.asc
Description: OpenPGP digital signature

Bug#946722: opensc: broken documentation link in package description

[John Scott]

Source: opensc
Version: 0.19.0-1
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

In the package descriptions OpenSC warns
 Before purchasing any cards, please read carefully documentation in
 /usr/share/doc/opensc/html/wiki/index.html

As best as I can tell, this file isn't provided by any package, not
even OpenSC. Even if the package did have the file, it seemed strange
to me that I was suggested to install the OpenSC package before
determining what smartcards would work with it.

- -- System Information:
Debian Release: 10.2
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-debug'), (500, 
'proposed-updates-debug'), (500, 'proposed-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-6-amd64 (SMP w/4 CPU cores)
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

- -- no debconf information

-BEGIN PGP SIGNATURE-

iHUEARMIAB0WIQQd3xxna2VescxVfdXYKFckL7guMwUCXfUW8wAKCRDYKFckL7gu
M+eOAQDBgTUVAhZGP3NJ2nHa+WzsANHLX0dV0egqj3J2MoHxiAEAj4p1JYmtDfHt
ND6vPkKVKW3AR8nXYUhPyjh9il5z9Uc=
=8Qy1
-END PGP SIGNATURE-

Bug#946719: konclude: FTBFS in sid

[Jonas Smedegaard]

Quoting Gianfranco Costamagna (2019-12-14 16:35:11)
> Hello, you package FTBFS in sid...
> 
> Log is here:
[...]
> g++ -c -pipe -g -O2 -fdebug-prefix-map=/build/konclude-0.6.2~dfsg=. 
> -fstack-protector-strong -Wformat -Werror=format-security -fpermissive 
> -Wdate-time -D_FORTIFY_SOURCE=2 -w -D_REENTRANT -fPIC -DQT_XML_LIB 
> -DQT_NETWORK_LIB -DKONCLUDE_FORCE_ALL_DEBUG_DEACTIVATED -DQT_NO_DEBUG 
> -DQT_GUI_LIB -DQT_XML_LIB -DQT_NETWORK_LIB -DQT_CORE_LIB -I. 
> -I./generatedfiles -I./GeneratedFiles/Release -ISource -I. -isystem 
> /usr/include/x86_64-linux-gnu/qt5 -isystem 
> /usr/include/x86_64-linux-gnu/qt5/QtGui -isystem 
> /usr/include/x86_64-linux-gnu/qt5/QtXml -isystem 
> /usr/include/x86_64-linux-gnu/qt5/QtNetwork -isystem 
> /usr/include/x86_64-linux-gnu/qt5/QtCore -IGeneratedFiles/release -isystem 
> /usr/include/libdrm -I/usr/lib/x86_64-linux-gnu/qt5/mkspecs/linux-g++ -o 
> release/CKoncludeInfo.o Source/CKoncludeInfo.cpp
> make[1]: execvp: /bin/sh: Argument list too long
> make[1]: *** [Makefile:10157: release/CKoncludeInfo.o] Error 127
> make[1]: Leaving directory '/build/konclude-0.6.2~dfsg'
> dh_auto_build: make -j8 returned exit code 2
> make: *** [debian/rules:11: binary] Error 255
> dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 
> 2
> 
> 
> Not sure what it means...

Not sure either - but a newer upstream release seems to build fine :-)

thanks for reporting!

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Bug#931580: pbuilder: SOURCE_ONLY_CHANGES=yes fails to work with pdebuild-internal

[Francesco Poli]

On Sun, 07 Jul 2019 22:43:46 +0200 Francesco Poli (wintermute) wrote:

[...]
> I hereby release my patch under the same terms as pbuilder itself,
> that is to say, under the terms of the GNU GPL v2 or later.
> 
> 
> Please apply my patch, so that pdebuild-internal users may generate
> source .changes files.

Is there any progress on this?
I really would like to see my patch accepted into pbuilder.

Please note that I prepared a number of uploads with my modified
version of pdebuild and everything seems to have worked without any
issue.

Thanks again for your time.
Bye.

-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpkCdWMTFceZ.pgp
Description: PGP signature

Bug#946689: munin-node: cidr_allow directive is sensitive to order when mixing IPv4 and IPv6

[Stig Sandbeck Mathisen]

Raphaël Hertzog  writes:

> After a lot of tweaking, I noticed that all the "cidr_allow" for the
> IPv4 addresses have to be before the first cidr_allow for an IPv6
> address. So just sorting the rules differently like this makes it work
> as expected (at least when connecting over IPv4):

Hello,

Thanks for reporting a bug. :)

The munin-node network listener is managed by Net::Server::Fork
instance, from the libnet-server-perl package, and the cidr_allow
parameters are passed directly to that module.

The bug report mentions you have that package "purged", so I do not want
to guess a version. The oldoldstable release from your bug report has
libnet-server-perl version 2.008-1, and the current is 2.009-1. Are you
using any of these, or a replacement?

-- 
Stig Sandbeck Mathisen
Debian Developer

Bug#946721: python-levenshtein: tries to overwrite '/usr/share/doc-base/python-levenshtein'

[Lisandro Damián Nicanor Pérez Meyer]

Source: python-levenshtein
Version: 0.12.0-4
Severity: serious
Justification: Fails to upgrade

Hi! While updateting the package I get:

Preparing to unpack .../python3-levenshtein_0.12.0-4_amd64.deb ...
Unpacking python3-levenshtein (0.12.0-4) over (0.12.0-3+b2) ...
dpkg: error processing archive 
/var/cache/apt/archives/python3-levenshtein_0.12.0-4_amd64.deb (--unpack):
 trying to overwrite '/usr/share/doc-base/python-levenshtein', which is also in 
package python-levenshtein 0.12.0-3+b2
Errors were encountered while processing:
 /var/cache/apt/archives/python3-levenshtein_0.12.0-4_amd64.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)

Thanks for your work, Lisandro.

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

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

-- no debconf information

Bug#946563: there is no need for a versioned libxcrypt1-dev package

[Marco d'Itri]

On Dec 11, Marco d'Itri  wrote:

> On Dec 11, Matthias Klose  wrote:
> 
> > there is really no need for a versioned libxcrypt1-dev package. Please 
> > rename
> > that properly to libxcrypt-dev.
> Can you be more specific in why this would not be allowed?
> Currently I am not building libxcrypt2 and libxcrypt2-dev, but the 
> package is ready to do it.
> libxcrypt1-dev and libxcrypt2-dev cannot be installed at the same time, 
> but libxcrypt1 and libxcrypt2 can.
Do you have any comments on this?

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#944479: EDAC amd64 regression

[andreimpopescu]

Control: fixed -1 5.4.2-1~exp1

On Sb, 14 dec 19, 18:05:19, andreimpope...@gmail.com wrote:
> Control: fixed 5.4.2-1~exp1
> 
> On Sb, 14 dec 19, 08:43:10, Antonio Russo wrote:
> > Thanks for checking in on this.
> > 
> > On 12/14/19 3:59 AM, andreimpope...@gmail.com wrote:
> > > In the meantime unstable has 5.3.17, you should check if maybe this was 
> > > fixed.
> > 
> > I moved to Linux 5.4 (trunk, 5.4.2), and the problem is resolved 
> > there.
> 
> Thank you for confirming.
> 
> > I'm not sure the correct way to close this bug report given that 
> > version is still in experimental.
> 
> Doing so with this message, assuming you meant the current version in 
> experimental.

Ugh, messed up the syntax, should be correct now.

Kind regards,
Andrei
-- 
Looking after bugs reported against inexistent or removed packages


signature.asc
Description: PGP signature

Bug#946720: [wayland] apparent memory leak

[dann frazier]

Package: gnome-shell
Version: 3.34.1+git20191024-1
Severity: normal

Memory usage by the gnome-shell process continually increases on my system,
eventually consuming GiBs of memory.


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

Kernel: Linux 5.3.0-3-amd64 (SMP w/4 CPU cores)
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 gnome-shell depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.34.0-1
ii  evolution-data-server3.34.1-1+b1
ii  gir1.2-accountsservice-1.0   0.6.55-1
ii  gir1.2-atspi-2.0 2.34.0-3
ii  gir1.2-freedesktop   1.62.0-2
ii  gir1.2-gcr-3 3.34.0-1
ii  gir1.2-gdesktopenums-3.0 3.34.0-2
ii  gir1.2-gdm-1.0   3.34.1-1
ii  gir1.2-geoclue-2.0   2.5.5-1
ii  gir1.2-glib-2.0  1.62.0-2
ii  gir1.2-gnomebluetooth-1.03.34.0-1
ii  gir1.2-gnomedesktop-3.0  3.34.2-2
ii  gir1.2-gtk-3.0   3.24.13-1
ii  gir1.2-gweather-3.0  3.34.0-1
ii  gir1.2-ibus-1.0  1.5.21-3
ii  gir1.2-mutter-5  3.34.1+git20191107-1
ii  gir1.2-nm-1.01.20.8-1
ii  gir1.2-nma-1.0   1.8.24-1
ii  gir1.2-pango-1.0 1.42.4-7
ii  gir1.2-polkit-1.00.105-26
ii  gir1.2-rsvg-2.0  2.46.4-1
ii  gir1.2-soup-2.4  2.68.2-1
ii  gir1.2-upowerglib-1.00.99.11-1
ii  gjs  1.58.1-1
ii  gnome-backgrounds3.34.0-1
ii  gnome-settings-daemon3.34.1-1+b1
ii  gnome-shell-common   3.34.1+git20191024-1
ii  gsettings-desktop-schemas3.34.0-2
ii  libatk-bridge2.0-0   2.34.1-2
ii  libatk1.0-0  2.34.1-1
ii  libc62.29-6
ii  libcairo21.16.0-4
ii  libcroco30.6.13-1
ii  libecal-2.0-13.34.1-1+b1
ii  libedataserver-1.2-243.34.1-1+b1
ii  libgcr-base-3-1  3.34.0-1
ii  libgdk-pixbuf2.0-0   2.40.0+dfsg-1
ii  libgirepository-1.0-11.62.0-2
ii  libgjs0g 1.58.1-1
ii  libgles2 1.1.0-1+b1
ii  libglib2.0-0 2.62.3-2
ii  libglib2.0-bin   2.62.3-2
ii  libgnome-autoar-0-0  0.2.3-2
ii  libgstreamer1.0-01.16.2-2
ii  libgtk-3-0   3.24.13-1
ii  libical3 3.0.5-2
ii  libjson-glib-1.0-0   1.4.4-2
ii  libmutter-5-03.34.1+git20191107-1
ii  libnm0   1.20.8-1
ii  libpango-1.0-0   1.42.4-7
ii  libpangocairo-1.0-0  1.42.4-7
ii  libpolkit-agent-1-0  0.105-26
ii  libpolkit-gobject-1-00.105-26
ii  libpulse-mainloop-glib0  13.0-3
ii  libpulse013.0-3
ii  libsecret-1-00.19.1-1
ii  libsystemd0  244-3
ii  libwayland-server0   1.17.0-1
ii  libx11-6 2:1.6.8-1
ii  libxfixes3   1:5.0.3-1
ii  mutter   3.34.1+git20191107-1
ii  python3  3.7.5-3

Versions of packages gnome-shell recommends:
ii  bolt  0.8-4
ii  chrome-gnome-shell10.1-5
ii  gdm3  3.34.1-1
ii  gkbd-capplet  3.26.1-1
ii  gnome-control-center  1:3.34.2-1
ii  gnome-user-docs   3.34.0-2
pn  ibus  
ii  iio-sensor-proxy  2.8-1
ii  switcheroo-control1.3.1-2
ii  unzip 6.0-25

Versions of packages gnome-shell suggests:
ii  gir1.2-telepathyglib-0.12   0.24.1-2+b1
ii  gir1.2-telepathylogger-0.2  0.8.2-4

Versions of packages gnome-session depends on:
ii  gnome-session-bin  3.34.1-1
ii  gnome-session-common   

Bug#946717: Homepage moved

[gustavo panizzo]

Control: fixed -1 1:3.11-1
Control: merge -1 944358

thanks

Hello Slavko

On Sat, Dec 14, 2019 at 03:02:10PM +0100, Slavko wrote:

Package: rss2email
Version: 1:3.9-4.1

Hi,

the move page was moved to https://github.com/rss2email/rss2email where
development continues. It was officially approved in
https://github.com/wking/rss2email/issues/97#issuecomment-328346160 and
for now the PyPI page refers to this new home page.

At this new home are new versions available, the latest is (as today)
v3.11


3.11 is coming as you can see here
https://ftp-master.debian.org/deferred/
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=946013


a nicer view of the package status in Debian 
https://tracker.debian.org/pkg/rss2email but
it doesn't show 3.11 yet


cheers!



regards

--
Slavko
http://slavino.sk




--
IRC: gfa
GPG: 0x27263FA42553615F904A7EBE2A40A2ECB8DAD8D5
OLD GPG: 0x44BB1BA79F6C6333

Bug#944479: EDAC amd64 regression

[Antonio Russo]

Thanks for checking in on this.

On 12/14/19 3:59 AM, andreimpope...@gmail.com wrote:
> In the meantime unstable has 5.3.17, you should check if maybe this was 
> fixed.
> 


I moved to Linux 5.4 (trunk, 5.4.2), and the problem is resolved there.  I'm
not sure the correct way to close this bug report given that version is still
in experimental.

Antonio

Bug#946719: konclude: FTBFS in sid

[Gianfranco Costamagna]

Source: konclude
Version: 0.6.2~dfsg-6
Severity: serious

Hello, you package FTBFS in sid...

Log is here:


I: Running cd /build/konclude-0.6.2~dfsg/ && env 
PATH="/usr/sbin:/usr/bin:/sbin:/bin" HOME="/nonexistent" dpkg-buildpackage -us 
-uc 
dpkg-buildpackage: info: source package konclude
dpkg-buildpackage: info: source version 0.6.2~dfsg-6
dpkg-buildpackage: info: source distribution unstable
dpkg-buildpackage: info: source changed by Jonas Smedegaard 
 dpkg-source --before-build .
dpkg-buildpackage: info: host architecture amd64
 debian/rules clean
dh clean --parallel
   dh_auto_clean -O--parallel
   debian/rules override_dh_clean
make[1]: Entering directory '/build/konclude-0.6.2~dfsg'
dh_clean
rm -f debian/Konclude.1
rm -f test-response*.xml
make[1]: Leaving directory '/build/konclude-0.6.2~dfsg'
 dpkg-source -b .
dpkg-source: info: using source format '3.0 (quilt)'
dpkg-source: info: building konclude using existing 
./konclude_0.6.2~dfsg.orig.tar.gz
dpkg-source: info: using patch list from debian/patches/series
dpkg-source: info: building konclude in konclude_0.6.2~dfsg-6.debian.tar.xz
dpkg-source: info: building konclude in konclude_0.6.2~dfsg-6.dsc
 debian/rules binary
dh binary --parallel
   dh_update_autotools_config -O--parallel
   debian/rules override_dh_auto_configure
make[1]: Entering directory '/build/konclude-0.6.2~dfsg'
QT_SELECT=5 CXXFLAGS="-g -O2 -fdebug-prefix-map=/build/konclude-0.6.2~dfsg=. 
-fstack-protector-strong -Wformat -Werror=format-security -fpermissive" 
dh_auto_configure
qmake -makefile "QMAKE_CFLAGS_RELEASE=-g -O2 
-fdebug-prefix-map=/build/konclude-0.6.2~dfsg=. -fstack-protector-strong 
-Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2" 
"QMAKE_CFLAGS_DEBUG=-g -O2 -fdebug-prefix-map=/build/konclude-0.6.2~dfsg=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
-D_FORTIFY_SOURCE=2" "QMAKE_CXXFLAGS_RELEASE=-g -O2 
-fdebug-prefix-map=/build/konclude-0.6.2~dfsg=. -fstack-protector-strong 
-Wformat -Werror=format-security -fpermissive -Wdate-time -D_FORTIFY_SOURCE=2" 
"QMAKE_CXXFLAGS_DEBUG=-g -O2 -fdebug-prefix-map=/build/konclude-0.6.2~dfsg=. 
-fstack-protector-strong -Wformat -Werror=format-security -fpermissive 
-Wdate-time -D_FORTIFY_SOURCE=2" QMAKE_LFLAGS_RELEASE=-Wl,-z,relro 
QMAKE_LFLAGS_DEBUG=-Wl,-z,relro QMAKE_STRIP=: PREFIX=/usr
Info: creating stash file /build/konclude-0.6.2~dfsg/.qmake.stash
Project MESSAGE: Preparing source code of Konclude.
make[1]: Leaving directory '/build/konclude-0.6.2~dfsg'
   dh_auto_build -O--parallel
make -j8
make[1]: Entering directory '/build/konclude-0.6.2~dfsg'
g++ -c -pipe -g -O2 -fdebug-prefix-map=/build/konclude-0.6.2~dfsg=. 
-fstack-protector-strong -Wformat -Werror=format-security -fpermissive 
-Wdate-time -D_FORTIFY_SOURCE=2 -w -D_REENTRANT -fPIC -DQT_XML_LIB 
-DQT_NETWORK_LIB -DKONCLUDE_FORCE_ALL_DEBUG_DEACTIVATED -DQT_NO_DEBUG 
-DQT_GUI_LIB -DQT_XML_LIB -DQT_NETWORK_LIB -DQT_CORE_LIB -I. -I./generatedfiles 
-I./GeneratedFiles/Release -ISource -I. -isystem 
/usr/include/x86_64-linux-gnu/qt5 -isystem 
/usr/include/x86_64-linux-gnu/qt5/QtGui -isystem 
/usr/include/x86_64-linux-gnu/qt5/QtXml -isystem 
/usr/include/x86_64-linux-gnu/qt5/QtNetwork -isystem 
/usr/include/x86_64-linux-gnu/qt5/QtCore -IGeneratedFiles/release -isystem 
/usr/include/libdrm -I/usr/lib/x86_64-linux-gnu/qt5/mkspecs/linux-g++ -o 
release/CKoncludeInfo.o Source/CKoncludeInfo.cpp
make[1]: execvp: /bin/sh: Argument list too long
make[1]: *** [Makefile:10157: release/CKoncludeInfo.o] Error 127
make[1]: Leaving directory '/build/konclude-0.6.2~dfsg'
dh_auto_build: make -j8 returned exit code 2
make: *** [debian/rules:11: binary] Error 255
dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2


Not sure what it means...

Gianfranco

Bug#946718: gbrowse: autopkgtest regression: Can't call method "features" on an undefined value

[Paul Gevers]

Source: gbrowse
Version: 2.56+dfsg-5
Severity: serious
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: regression

Dear maintainers,

Your package has an autopkgtest, great. However, it fails. I copied some
of the output at the bottom of this report.

Currently this regression is blocking the migration to testing [1]. Can
you please investigate the situation and fix it? On top of that, your
package FTBFS on s390x.

More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=gbrowse

https://ci.debian.net/data/autopkgtest/testing/amd64/g/gbrowse/3555081/log.gz

t/01.yeast.t ..
1..7
not ok 1
# Failed test 1 in t/01.yeast.t at line 29
Can't call method "features" on an undefined value at t/01.yeast.t line 31.
Dubious, test returned 25 (wstat 6400, 0x1900)
Failed 7/7 subtests



signature.asc
Description: OpenPGP digital signature

Bug#921566: Reopen Bug#921566 closed by Andreas Tille (Bug#921566: fixed in deepnano 0.0+git20170813.e8a621e-3)

[Paul Gevers]

Hi Andreas,

On 13-12-2019 17:24, Andreas Tille wrote:
> However, even
> 
>  https://ci.debian.net/packages/p/deepnano
> 
> does not exist any more.  Am I missing something?

A typo: https://ci.debian.net/packages/d/deepnano/

However, because of the shear amount of tests and size of the logs, we
have to delete logs older than 3 months. There isn't anything to find
here anymore.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#942404: Tests seem to work again

[Paul Gevers]

Hi Andreas,

On 12-12-2019 17:21, Andreas Tille wrote:
> Hi Paul,
> 
> looking at the debci results[1] I see that the test is passing 10 tests
> in a row since 2019-10-29 05:19:47 UTC.  Do you agree that we can at
> least lower severity of this bug to something else than "serious".  I
> need to admit that also do not know what to do here as Olivier said in
> his response.

The reference run of 2019-12-13 12:36:40 UTC failed again, so no.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#946716: mirror submission for debian.apt-mirror.de

[Kevin Linnartz]

Package: mirrors
Severity: wishlist
User: mirr...@packages.debian.org
Usertags: mirror-submission

Submission-Type: new
Site: debian.apt-mirror.de
Type: leaf
Archive-architecture: amd64 armhf i386
Archive-http: /debian/
Maintainer: Kevin Linnartz 
Country: DE Germany
Location: France (OVH)




Trace Url: http://debian.apt-mirror.de/debian/project/trace/
Trace Url: 
http://debian.apt-mirror.de/debian/project/trace/ftp-master.debian.org
Trace Url: http://debian.apt-mirror.de/debian/project/trace/debian.apt-mirror.de

Bug#919295: closed by Gianfranco Costamagna (Re: Bug#919295: kmk_gmake is an embedded copy of make-dfsg)

[Helmut Grohne]

Hi Gianfranco,

On Sat, Dec 14, 2019 at 09:21:04AM +, Debian Bug Tracking System wrote:
> After a deeper analysis, while it is true that they share part of the code 
> (so adding it to tracker is fine),
> the sources are *needed* to build kmk, because make-dfsg is not exporting its 
> internal functionalities into a library.

Thank you for performing this analysis. I trust you on the results.
While the Debian policy discourages copies, it does not forbid them. I
think you have appropriately processed my report.

I do think that you should have used "modified-embed" rather than
"embed" in the security tracker though given that you do need changes to
make-dfsg. You're effectively saying that this is not a convenience
copy, but more like a fork. This is a minor difference with little
practical effect though.

> But TBH, I'm really not sure having a libmake-dfsg would help at all (it 
> would involve quite big changes in kbuild for no real gain)
> 
> Feel free to open a bug against libmake to exporting their functions as API

I won't.

Helmut

Bug#946715: texlive-lang-japanese: should recommend/suggest texlive-latex-recommended

[Ryutaroh Matsumoto]

Package: texlive-lang-japanese
Version: 2019.20191208-1
Severity: normal

Dear Maintainer,

Many files in texlive-lang-japanese need files in texlive-latex-recommended.
E.g., compiling the following file


\documentclass{ltjarticle}
\begin{document}
test.
\end{document}

gives the following error without texlive-latex-recommended.
It may be a good idea for texlive-lang-japanese to recommend/suggest
to texlive-latex-recommended. In my view, texlive-latex-recommended
is recommended by too few Debian packages, while texlive-latex-recommended seems
necessary by many texlive related Debian packages...

$ lualatex test-ja.tex
This is LuaTeX, Version 1.10.0 (TeX Live 2019/Debian) 
 restricted system commands enabled.
(./test-ja.tex
LaTeX2e <2019-10-01> patch level 3

luaotfload | main : initialization completed in 0.182 seconds
(/usr/share/texlive/texmf-dist/tex/luatex/luatexja/ltjarticle.cls
Document Class: ltjarticle 2019/10/17 v1.8c-ltj-17 Standard LuaLaTeX-ja class
(/usr/share/texlive/texmf-dist/tex/luatex/luatexja/luatexja.sty
(/usr/share/texlive/texmf-dist/tex/luatex/luatexja/luatexja-core.sty
(/usr/share/texlive/texmf-dist/tex/luatex/luatexbase/luatexbase.sty
(/usr/share/texlive/texmf-dist/tex/luatex/ctablestack/ctablestack.sty))
(/usr/share/texlive/texmf-dist/tex/generic/oberdiek/ltxcmds.sty)

! LaTeX Error: File `pdftexcmds.sty' not found.

Type X to quit or  to proceed,
or enter new name. (Default extension: sty)


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

Kernel: Linux 5.3.0-3-amd64 (SMP w/2 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.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 texlive-lang-japanese depends on:
ii  fonts-ipaexfont-gothic  00401-2
ii  fonts-ipaexfont-mincho  00401-2
ii  fonts-ipafont-gothic00303-20
ii  fonts-ipafont-mincho00303-20
ii  ruby1:2.5.2
ii  tex-common  6.13
ii  texlive-base2019.20191208-4
ii  texlive-binaries2019.20190605.51237-3
ii  texlive-lang-cjk2019.20191208-1

texlive-lang-japanese recommends no packages.

texlive-lang-japanese suggests no packages.

Versions of packages tex-common depends on:
ii  dpkg  1.19.7
ii  ucf   3.0038+nmu1

Versions of packages tex-common suggests:
ii  debhelper  12.7.1

Versions of packages texlive-lang-japanese is related to:
ii  tex-common6.13
ii  texlive-binaries  2019.20190605.51237-3

-- no debconf information

Bug#900774: Patch for opendkim-tools and adoption status

[David Bürgin]

Hello Felix,

On Sat, Dec 14, 2019 at 03:23:32AM -0800, Felix Lechner wrote:
> I worked on this package before the buster freeze, but don't actually
> use it anymore. (Exim has built-in support for DKIM.) Are you
> interested in taking over maintenance?

indeed I am! I still use OpenDKIM with Postfix.

May I take ownership of the wnpp bug with intent to adopt?

Cheers,
David

Bug#900774: Patch for opendkim-tools and adoption status

[Felix Lechner]

Hi,

On Sat, Dec 14, 2019 at 3:35 AM David Bürgin  wrote:
>
> May I take ownership of the wnpp bug with intent to adopt?

Yes, please. It is in better hands with you. Good luck!

Kind regards
Felix Lechner

Bug#900774: Patch for opendkim-tools and adoption status

[Felix Lechner]

Hi David,

I worked on this package before the buster freeze, but don't actually
use it anymore. (Exim has built-in support for DKIM.) Are you
interested in taking over maintenance?

Kind regards
Felix Lechner


On Mon, Dec 9, 2019 at 2:35 AM David Bürgin  wrote:
>
> Hello Felix,
>
> I have opened Debian bug #946386 with a patch that I would like to get
> into Debian.
>
> You are the prospective maintainer of opendkim, is that right? How can I
> help you with integrating the patch? It would be good to have a status
> update on your adoption and maintenance plans for opendkim.
>
> Thank you.
>
>
> --
> David