Bug#945267: FTBFS: FAIL: test_pylint (devscripts.test.test_pylint.PylintTestCase)

[Christoph Biedl]

Package: devscripts
Version: 2.19.7
Severity: serious

Dear Maintainer,

devscripts started failing in the "Run pylint on Python source code" test:

| ==
| FAIL: test_pylint (devscripts.test.test_pylint.PylintTestCase)
| Test: Run pylint on Python source code
| --
| Traceback (most recent call last):
|   File "/<>/scripts/devscripts/test/test_pylint.py", line 68, in 
test_pylint
| self.fail("\n".join(msgs))
| AssertionError: pylint found issues:
| * Module debdiff-apply
| debdiff-apply:190:8: C0415: Import outside toplevel (code) 
(import-outside-toplevel)
| debdiff-apply:274:12: R1720: Unnecessary "else" after "raise" (no-else-raise)
| * Module sadt
| sadt:369:8: R1720: Unnecessary "else" after "raise" (no-else-raise)

Christoph

-- Package-specific info:

--- /etc/devscripts.conf ---

--- ~/.devscripts ---
Not present

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

Kernel: Linux 4.19.84 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Versions of packages devscripts depends on:
ii  dpkg-dev  1.19.7
ii  fakeroot  1.24-1
ii  file  1:5.37-6
ii  gnupg 2.2.17-3
ii  gpgv  2.2.17-3
ii  libc6 2.29-3
ii  libfile-homedir-perl  1.004-1
ii  libfile-which-perl1.23-1
ii  libipc-run-perl   20180523.0-2
ii  libmoo-perl   2.003006-1
ii  libwww-perl   6.41-1
ii  patchutils0.3.4-2+b1
ii  perl  5.30.0-9
ii  pseudo [fakeroot] 1.9.0+git20190515+996bead-2
ii  python3   3.7.5-3
ii  sensible-utils0.0.12
ii  wdiff 1.2.2-2+b1

Versions of packages devscripts recommends:
ii  apt 1.8.4
pn  at  
ii  curl7.66.0-1+b1
ii  dctrl-tools 2.24-3+b1
ii  debian-keyring  2019.09.24
ii  dput-ng [dput]  1.28
pn  equivs  
pn  libdistro-info-perl 
ii  libdpkg-perl1.19.7
ii  libencode-locale-perl   1.05-1
pn  libgit-wrapper-perl 
ii  libgitlab-api-v4-perl   0.23-1
ii  liblist-compare-perl0.53-1
ii  liblwp-protocol-https-perl  6.07-2
pn  libsoap-lite-perl   
ii  libstring-shellquote-perl   1.04-1
ii  libtry-tiny-perl0.30-1
ii  liburi-perl 1.76-1
ii  licensecheck3.0.31-3
ii  lintian 2.37.0
ii  man-db  2.9.0-1
ii  patch   2.7.6-6
ii  python3-apt 1.8.4+b1
ii  python3-debian  0.1.36
ii  python3-magic   2:0.4.15-2
ii  python3-requests2.21.0-1
pn  python3-unidiff 
pn  python3-xdg 
ii  strace  4.26-0.2
ii  unzip   6.0-25
ii  wget1.20.3-1+b2
ii  xz-utils5.2.4-1+b1

Versions of packages devscripts suggests:
pn  adequate 
ii  autopkgtest  5.11
pn  bls-standalone   
pn  bsd-mailx | mailx
ii  build-essential  12.8
pn  check-all-the-things 
pn  cvs-buildpackage 
ii  debhelper12.7.1
pn  devscripts-el
ii  diffoscope   130
pn  disorderfs   
pn  dose-extra   
pn  duck 
ii  faketime 0.9.7-3
pn  gnuplot  
pn  how-can-i-help   
ii  libauthen-sasl-perl  2.1600-1
pn  libdbd-pg-perl   
pn  libfile-desktopentry-perl
pn  libnet-smtps-perl
pn  libterm-size-perl
ii  libtimedate-perl 2.3000-2
ii  libyaml-syck-perl1.31-1+b2
ii  mozilla-devscripts   0.54
pn  mutt 
ii  openssh-client [ssh-client]  1:8.1p1-1
pn  piuparts 
pn  postgresql-client
ii  quilt0.65-3
pn  ratt 
pn  reprotest
pn  svn-buildpackage 
pn  w3m  

-- no debconf information



signature.asc
Description: PGP signature

Bug#945266: sc: Switch to maintained upstream

[Seo Sanghyeon]

Package: sc
Version: 7.16-4+b3
Severity: wishlist

#933315 already suggested switching to sc-im, repository at
https://github.com/andmarti1424/sc-im

But maybe that is a too drastic change. In that case, I suggest
switching to another maintained upstream, repository at
https://github.com/n-t-roff/sc

Thanks!

Bug#945226: gudhi: please lower parallelism everywhere

[Gard Spreemann]

Thank you, Gianfranco. I've made the change in git, and will upload as
soon as the two transitions gudhi is currently part of are over
(python3.8 and cgal_5.0).

 Best,
 Gard

Bug#945265: new upstream version 0.102.1 to fix CVE-2019-15961

[Harald Dunkel]

Package: clamav
Version: 0.101.4+dfsg-1
Tag: security

Upstream provides a new version 0.102.1, including a patch for
CVE-2019-15961

See https://blog.clamav.net/2019/11/clamav-01021-and-01015-patches-have.html


Regards
Harri

Bug#945264: RM: python-backports.os -- RoM; no Python 3 support and no reverse deps; low popcon

[Andrey Rahmatullin]

Package: ftp.debian.org
Severity: normal
User: debian-pyt...@lists.debian.org
Usertags: py2removal

Not needed with Py3 and not used by any package in Debian anymore.

Popcon 82.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#936270: calibre: does not depend on cherrypy for a long time now

[Norbert Preining]

Hi Eli,

thanks for your bug report.

> Please be advised that the calibre program dropped its dependency on
> cherrypy in version 3.0, with the complete from-scratch rewrite of its

Thanks, I didn't know. I took over Calibre at around 3.7 and expected
somehow that the dependencies are ok.

I have already removed the deps in the git repo, will be in the next
upload.

Thanks

Norbert

--
PREINING Norbert   http://www.preining.info
Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Bug#945263: f2py3.8 fails with "Entry point not found" exception

[Matthias Klose]

Package: src:numpy
Version: 1:1.17.4-3
Severity: serious
Tags: sid bullseye patch
User: debian-pyt...@lists.debian.org
Usertags: python3.8

f2py3.8 fails with "Entry point not found" exception.

patch at
http://launchpadlibrarian.net/452313700/numpy_1%3A1.17.4-3ubuntu1_1%3A1.17.4-3ubuntu2.diff.gz

Another solution might be to loop around the py3 versions in building f2py_cmds
in setup.py.

Bug#945261: removed Python2 package without removing the Python2 autopkg test

[Matthias Klose]

Package: src:python-latexcodec
Version: 1.0.5-2
Severity: serious
Tags: sid bullseye patch

removed Python2 package without removing the Python2 autopkg test. patch at
http://launchpadlibrarian.net/452595834/python-latexcodec_1.0.5-2_1.0.5-2ubuntu1.diff.gz

Bug#945262: removed Python2 package without removing the Python2 autopkg test

[Matthias Klose]

Package: src:python-misaka
Version: 1.0.2-6
Severity: serious
Tags: sid bullseye patch

removed Python2 package without removing the Python2 autopkg test. patch at
http://launchpadlibrarian.net/452596015/python-misaka_1.0.2-6_1.0.2-6ubuntu1.diff.gz

Bug#945260: python-quantities ftbfs with Python 3.8

[Matthias Klose]

Package: src:python-quantities
Version: 0.12.3-2
Severity: serious
Tags: sid bullseye
User: debian-pyt...@lists.debian.org
Usertags: python3.8

==
ERROR: test_clip (quantities.tests.test_methods.TestQuantityMethods)
--
Traceback (most recent call last):
  File "/<>/.pybuild/cpython3_3.8/build/quantities/quantity.py",
line 247, in __array_prepare__
res._dimensionality = p_dict[uf](*objs)
KeyError: 

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File
"/<>/.pybuild/cpython3_3.8/build/quantities/tests/test_methods.py",
line 198, in test_clip
self.methodWithOut(
  File
"/<>/.pybuild/cpython3_3.8/build/quantities/tests/test_methods.py",
line 125, in methodWithOut
ret = getattr(q.copy(), name)(*args, out=out, **kw)
  File "/<>/.pybuild/cpython3_3.8/build/quantities/quantity.py",
line 579, in clip
clipped = self.magnitude.clip(
  File "/usr/lib/python3/dist-packages/numpy/core/_methods.py", line 131, in 
_clip
return _clip_dep_invoke_with_casting(
  File "/usr/lib/python3/dist-packages/numpy/core/_methods.py", line 85, in
_clip_dep_invoke_with_casting
return ufunc(*args, out=out, **kwargs)
  File "/<>/.pybuild/cpython3_3.8/build/quantities/quantity.py",
line 249, in __array_prepare__
raise ValueError(
ValueError: ufunc  not supported by quantities
please file a bug report at https://github.com/python-quantities


--
Ran 161 tests in 0.954s

FAILED (errors=1, expected failures=3)

Bug#945259: povray FTCBFS: broken, oudated, embedded copy of AX_BOOST_BASE

[Helmut Grohne]

Source: povray
Version: 1:3.7.0.8-1
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

povray fails to cross build from source, because it ships a broken,
outdated, embedded copy of AX_BOOST_BASE in
unix/config/ax_boost_base.m4. The actual bug #872256 is already fixed
for a while in autoconf-archive, but povray happens to ship a copy of
the bug. Please remove your embedded copy or - failing that - update it
and register it with the security tracker. This bug report comes without
a patch, because the actual bug is already fixed.

Helmut

Bug#936270: calibre: does not depend on cherrypy for a long time now

[Eli Schwartz]

Hi.

I notice you've all made quite a kerfuffle over the cherrypy module,
with some people wishing to remove it for python2 from the Debian
archives, and some people wishing to keep it because calibre depends on it.

Please be advised that the calibre program dropped its dependency on
cherrypy in version 3.0, with the complete from-scratch rewrite of its
content-server component. This was a full major version and (as of the
time of this writing) 52 feature releases ago. The removal occurred on
Sun May 21 04:09:11 2017 via this commit:
https://github.com/kovidgoyal/calibre/commit/5ed88a0bf596ea4389ac4fe08ccf249c7693d04d

Please remove this ancient, unused dependency from the Debian packaging
for calibre, thereby clearing the way to dropping the python2-cherrypy
module. All it does is waste the disk space of calibre users.

-- 
Eli Schwartz
Arch Linux Bug Wrangler and Trusted User



signature.asc
Description: OpenPGP digital signature

Bug#945232: ruby-benchmark-suite fails to build with ruby-benchmark-ips 2.7 in experimental

[Pirate Praveen]

On 2019, നവംബർ 22 2:07:15 AM IST, Utkarsh Gupta  
wrote:
>Furthermore, I've pushed the fix and the changes to the salsa repo,
>which could be found here[2].
>NOTE: Since there's no gemspec present (either in debian or
>upstream[3]), I've left it as is. This also means the autopkgtest would
>*not* be able to parse the dependencies and wouldn't proceed.
>I'll leave that to you and for the maintainer of this package to decide
>

This is because by default, the following command will be run by Testsuite: 
autopkgtest-pkg-ruby 

gem2deb-test-runner --autopkgtest --check-dependencies 2>&1

Since that does not work, you can remove that field and create 
debian/tests/control
and call this command without --check-dependencies  option.
 
>
>That said, ruby-benchmark-suite *now* works with ruby-benchmark-ips 2.7
>in experimental.

Thanks!

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

Bug#945258: qemu: Filesystem corruption caused by qemu in qcow2 images

[Shmerl]

Source: qemu
Severity: important

Dear Maintainer,

Currently qemu 4.1 periodically corrupts vm images (qcow2), due to this bug:
https://bugs.launchpad.net/qemu/+bug/1846427

Please temporarily apply the provided patches, until upstream will release the
fixed version:

https://patchwork.kernel.org/cover/11207161/
https://patchwork.kernel.org/patch/11207167/
https://patchwork.kernel.org/patch/11207139/
https://patchwork.kernel.org/patch/11207171/

Thanks!



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

Kernel: Linux 5.4.0-rc7+ (SMP w/24 CPU cores)
Kernel taint flags: 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

Bug#945256: Do not make `gcc` depend on one paticular version.

[Matthias Klose]

On 22.11.19 04:19, Gong S. wrote:
> Package: gcc
> Version: 4:9.2.1-3.1
> Severity: wishlist
> 
> It seems that the GCC-related packages (`cpp`, `g++`, etc.) have hard 
> dependencies to one particular version of said programs, so when a new 
> version of GCC is released and a package depends on `gcc` or `cpp`, I have to 
> install multiple versions of GCC or CPP.
> 
> I think that a better idea is to:
> 1. Make GCC-related packages virtual packages, and make various versions of 
> `gcc` like `gcc-8` and `gcc-9` provide the `gcc` package name.
> 2. Use the debian-alternatives system for the GCC-related binaries, so if a 
> program only needs to use a compiler, it would use the latest version (or 
> user-specifies version with `update-alternatives`), and if a program needs a 
> particular version, it would directly use `gcc-8` or `gcc-9`.

No. GCC versions usually come with different ABIs and APIs in some cases, like
having different soversions.  Handling different ABIs using alternatives is
simply wrong.

> Please limit your reply to 7-bit ASCII.
> I refuse to see your idiotic emoji in a TTY.

Please stop making idiotic requests.

Bug#945257: thunar: Thunar ignoger FREETYPE_PROPERTIES="truetype:interpreter-version=35"

[tubus]

Package: thunar
Version: 1.8.4-1
Severity: important

Dear Maintainer,

I have set environment variable FREETYPE_PROPERTIES in /etc/environment
FREETYPE_PROPERTIES="truetype:interpreter-version=35"
Most of the applicaton shows font as expected for type 35

But not in Thunar, it ignores it and uses type 40.

Please, take a look on my screenshot. You will be able to notice that anti-
alising on left and right windows is different.
Left is Thunar, on the right is mousepad. Mousepad makes anti-alising with
truetype:interpreter-version=35

Thunar is not, it uses version 40 or 38, which is the same.

Font anti-alising should be everywhere the same.



-- 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/2 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 thunar depends on:
ii  desktop-file-utils  0.23-4
ii  exo-utils   0.12.4-1
ii  libatk1.0-0 2.30.0-2
ii  libc6   2.28-10
ii  libcairo2   1.16.0-4
ii  libexo-2-0  0.12.4-1
ii  libgdk-pixbuf2.0-0  2.38.1+dfsg-1
ii  libglib2.0-02.58.3-2+deb10u2
ii  libgtk-3-0  3.24.5-1
ii  libgudev-1.0-0  232-2
ii  libice6 2:1.0.9-2
ii  libnotify4  0.7.7-4
ii  libpango-1.0-0  1.42.4-7~deb10u1
ii  libsm6  2:1.2.3-1
ii  libthunarx-3-0  1.8.4-1
ii  libxfce4ui-2-0  4.12.1-3
ii  libxfce4util7   4.12.1-3
ii  libxfconf-0-2   4.12.1-1
ii  shared-mime-info1.10-1
ii  thunar-data 1.8.4-1

Versions of packages thunar recommends:
ii  dbus-user-session [default-dbus-session-bus]  1.12.16-1
ii  dbus-x11 [dbus-session-bus]   1.12.16-1
ii  gnome-shell [polkit-1-auth-agent] 3.30.2-11~deb10u1
ii  gvfs  1.38.1-5
ii  libcairo-gobject2 1.16.0-4
ii  libpangocairo-1.0-0   1.42.4-7~deb10u1
ii  libxfce4panel-2.0-4   4.12.2-1
ii  thunar-volman 0.9.1-1
pn  tumbler   
ii  udisks2   2.8.1-4
ii  xdg-user-dirs 0.17-2

Versions of packages thunar suggests:
pn  thunar-archive-plugin 
pn  thunar-media-tags-plugin  

-- no debconf information

Bug#944875: calibre: ebook-convert to pdf aborts due to missing objects in QWebEngineProfile

[Norbert Preining]

Hi

> ebook-convert package aborts every time I'm trying to convert file to pdf 
> format.

Qt and PyQt is too old in Debian ... again ... 5.13 is necessary.
From
https://doc.qt.io/qt-5/qwebengineprofile.html#setUrlRequestInterceptor

This function was introduced in Qt 5.13.

Not sure what can be done here ... besides waiting

Norbert

--
PREINING Norbert   http://www.preining.info
Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Bug#945256: Do not make `gcc` depend on one paticular version.

[Gong S.]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Package: gcc
Version: 4:9.2.1-3.1
Severity: wishlist

It seems that the GCC-related packages (`cpp`, `g++`, etc.) have hard 
dependencies to one particular version of said programs, so when a new version 
of GCC is released and a package depends on `gcc` or `cpp`, I have to install 
multiple versions of GCC or CPP.

I think that a better idea is to:
1. Make GCC-related packages virtual packages, and make various versions of 
`gcc` like `gcc-8` and `gcc-9` provide the `gcc` package name.
2. Use the debian-alternatives system for the GCC-related binaries, so if a 
program only needs to use a compiler, it would use the latest version (or 
user-specifies version with `update-alternatives`), and if a program needs a 
particular version, it would directly use `gcc-8` or `gcc-9`.
--
Please limit your reply to 7-bit ASCII.
I refuse to see your idiotic emoji in a TTY.
-BEGIN PGP SIGNATURE-
Version: ProtonMail

wsBcBAEBCAAGBQJd11OtAAoJENi1YDlFXXQfk6IIAJQpYVtuOm0WaRGKRytF
r6C1+L+bU3FwIFs1PWxeZTlyeP5Z64CChl6EscU4j+JQgKZKE84tWCysnGgB
5986TmDHh6aD3Z3x8l4XiL/Ukz3kWhnvATvIBKAbQGHSDKhhNvs+7cUtQbrc
42W0JsQeSlMfgITPkMFV8VHZ17FA45+U4YA/hexzMk3TPGLgXVGcvRb1JYqX
O1UlV9h/OPce17v+YdOXSNPXY8Ob0DSrc7R7Sus/9YuMnE3rlouVowAy0G09
z8JfldBAHqp2CZKYvBkQQ+tAg3Otj0sgpQNlLgMlrWeI1oDqjKGWPc+qjbE8
dfYkWXrQAr2xIKCPVqSxcLA=
=vGb5
-END PGP SIGNATURE-



publickey - pthfdr@protonmail.ch - 0xAB77ABA4.asc
Description: application/pgp-keys


publickey - pthfdr@protonmail.ch - 0xAB77ABA4.asc.sig
Description: PGP signature

Bug#945255: gdb: package is lacking a man page

[Héctor Orón Martínez]

tags -1 wontfix
thank

Hello Andrew,

Missatge de Andrew Apted  del dia dv., 22 de nov.
2019 a les 3:21:
>
> Package: gdb
> Version: 8.2.1-2+b3
> Severity: normal
>
> Dear Maintainer,
>
> Section 12.1 of Debian Policy states: Each program, utility, and function
> should have an associated manual page included in the same package.
>
> The package "gdb" is in violation of that policy since the man page is
> not in the same package, but in the gdb-doc package.  I expect man pages
> for programs to be available without needing to install additional
> packages.

GNU GDB manpage lives in "src:gdb-doc" package, which is in
"non-free", since GFDL is considered a non-free license by the DFSG.

Regards

Bug#945255: gdb: package is lacking a man page

[Andrew Apted]

Package: gdb
Version: 8.2.1-2+b3
Severity: normal

Dear Maintainer,

Section 12.1 of Debian Policy states: Each program, utility, and function
should have an associated manual page included in the same package.

The package "gdb" is in violation of that policy since the man page is
not in the same package, but in the gdb-doc package.  I expect man pages
for programs to be available without needing to install additional
packages.

Please fix this package to follow Debian Policy.



-- System Information:
Debian Release: 10.2
  APT prefers stable-updates
  APT policy: (500, 'stable-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_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_AU:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages gdb depends on:
ii  libbabeltrace1  1.5.6-2+deb10u1
ii  libc6   2.28-10
ii  libexpat1   2.2.6-2+deb10u1
ii  libipt2 2.0-2
ii  liblzma55.2.4-1
ii  libncursesw66.1+20181013-2+deb10u2
ii  libpython3.73.7.3-2
ii  libreadline77.0-5
ii  libtinfo6   6.1+20181013-2+deb10u2
ii  zlib1g  1:1.2.11.dfsg-1

Versions of packages gdb recommends:
ii  libc6-dbg [libc-dbg]  2.28-10

Versions of packages gdb suggests:
ii  gdb-doc8.2.1-1
ii  gdbserver  8.2.1-2+b3

-- no debconf information

Bug#945254: py-libzfs: FTBFS against python3.8

[Andreas Beckmann]

Source: py-libzfs
Version: 0.0+git20191113.2991805-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source

py-libzfs FTBFS in sid since python3.8 was added to the list of python
versions to build against:

https://buildd.debian.org/status/package.php?p=py-libzfs=experimental


Andreas

Bug#945055: intel-microcode: CPU runs at considerably higher temperatures

[Christoph Anton Mitterer]

After some further tests I think it could be actually independent of
the microcode and rather be kernel 5.3's fault.


First perhaps some notes on that notebook:
It's an Fujitsu LIFEBOOK U757 with:
model name  : Intel(R) Core(TM) i7-7600U CPU @ 2.80GHz

When I got the system in around 2017, IIRC, I already had considerable
CPU overheating problems seeing often messages like:
ov 17 14:41:22 heisenberg kernel: [   36.347425] mce: CPU2: Core temperature 
above threshold, cpu clock throttled (total events = 1)
Nov 17 14:41:22 heisenberg kernel: [   36.347426] mce: CPU0: Core temperature 
above threshold, cpu clock throttled (total events = 1)
Nov 17 14:41:22 heisenberg kernel: [   36.347427] mce: CPU1: Package 
temperature above threshold, cpu clock throttled (total events = 1)
Nov 17 14:41:22 heisenberg kernel: [   36.347427] mce: CPU3: Package 
temperature above threshold, cpu clock throttled (total events = 1)
Nov 17 14:41:22 heisenberg kernel: [   36.347429] mce: CPU0: Package 
temperature above threshold, cpu clock throttled (total events = 1)
Nov 17 14:41:22 heisenberg kernel: [   36.347531] mce: CPU2: Package 
temperature above threshold, cpu clock throttled (total events = 1)
Nov 17 14:41:22 heisenberg kernel: [   36.348423] mce: CPU2: Core 
temperature/speed normal
Nov 17 14:41:22 heisenberg kernel: [   36.348424] mce: CPU0: Core 
temperature/speed normal
Nov 17 14:41:22 heisenberg kernel: [   36.348461] mce: CPU1: Package 
temperature/speed normal
Nov 17 14:41:22 heisenberg kernel: [   36.348461] mce: CPU3: Package 
temperature/speed normal
Nov 17 14:41:22 heisenberg kernel: [   36.348498] mce: CPU2: Package 
temperature/speed normal
Nov 17 14:41:22 heisenberg kernel: [   36.348568] mce: CPU0: Package 
temperature/speed normal

Just with many thousands of events and temperatures reaching pretty
exactly 100°C.

Fujitsu support had no real solution, claiming it wouldn't happen under
Windows.
Eventually the solution was to disable the turbo:
/sys/devices/system/cpu/intel_pstate/no_turbo = 1

(and all my previous tests as well as the ones from this mail have that
set).

Since then I rarely see the temperature warnings from above, and if
it's usually only exactly one event during boot.


I guess the cooling of that slim ultrabook is just not designed well
enough to transport enough heat away if the turbo is on.


One further constant thing is that playback of videos always lead to
considerable CPU utilisation (and higher temperatures), much worse than
the previous ~2012 lifebook the university bought me.

I've never found a real solution for that,... video decoding
acceleration is enabled and seems to work but still,...
Suspicion was that it might be some issue in cinnamon, cause the
cinnamon process also gets quite high CPU usage when I play back
videos.


But when I've reported this ticket, things had gotten much worse (and
it was like that already for a week till I've took action or even
noticed it), especially when the system was basically idle, the temps
were also much higher and the fan running much louder/faster.

And as I've described before, there are situations when it get's really
hot (80° and more) an doesn't cool down again a lot, even if the it
becomes idle again.






Just before I did some more testing with different kernel/microcode
combinations:

**
With 5.2.17 0xca-2019-09-26:

 Event/s PID  %CPU  PR  NI Task   Init Function
   59.821730   0.2   0   0 Xorg   hrtimer_wakeup   
   55.831730   0.2   0   0 Xorg   it_real_fn   
   14.963203   0.5   0   0 gnome-terminal-hrtimer_wakeup   
   13.963086   0.0   0   0 diodon hrtimer_wakeup   
7.983065   0.2   0   0 cinnamon   tick_sched_timer 
3.993203   0.5   0   0 gnome-terminal-tick_sched_timer 
2.99  32   0.0   0   0 [kworker/1:1]  intel_uncore_fw_release_timer
1.99 509   0.0   0   0 [kworker/u8:4] intel_uncore_fw_release_timer
1.991730   0.2   0   0 Xorg   intel_uncore_fw_release_timer
1.99  45   0.0   0   0 [kworker/2:1]  intel_uncore_fw_release_timer
1.00 847   0.0   0   0 gmain  hrtimer_wakeup   
1.002861   0.0   0   0 gmain  hrtimer_wakeup   
1.00 236   0.0   0   0 [kworker/3:2]  intel_uncore_fw_release_timer
1.00 751   0.0   0   0 havegedhrtimer_wakeup   
1.002920   0.0   0   0 gmain  hrtimer_wakeup   
1.001730   0.2   0   0 Xorg   tick_sched_timer 
1.003065   0.3   0   0 cinnamon   intel_uncore_fw_release_timer
173 Total events, 172.48 events/sec (kernel:  7.98, userspace: 164.51)

 Event/s PID  %CPU  PR  NI Task   Init 

Bug#940312: /etc/issue: /etc/issue is being updated by Debian when it doesn't need to

[Ben Wong]

Oh! I'm sorry. I had expected Debian's official "PRETTY NAME" in
/etc/os-release to be the preferred name for showing to users.

To show it without the code name, but to have it automatically update
whenever /etc/os-release is changed, this works:

\S{NAME} \S{VERSION_ID} \n \l

Thanks,

—Ben

Bug#945245:

[pham...@bluewin.ch]

After installation-test of the SID powertop_2.10-1+b1_amd64 version, it's are 
also bugged.
The Unbearable whistling in headphones is always present.
It should quickly publish and test a version 2.11 hoping that the problem has 
been corrected with this version.
Regards.

Bug#944858: qemu update causes FreeNAS VM to hang when vm is booted

[Bernhard Übelacker]

Hello Stuart Lindley,
I am not involved in packaging qemu and just looking
through some bug reports.

Some informations that might be interesting for the
maintainer might be, which version of freenas you are running?

Based on your screenshot you start it via libvirt?

Maybe you could deliver the comand line of qemu
shown by e.g. "ps aux | grep -i qemu" on the host.

Are there any suspicious messages in the host 'dmesg'?

Do you know which last qemu version did not show the hang?
Maybe that was also running on a previous kernel package version?

Kind regards,
Bernhard

Bug#945055: intel-microcode: CPU runs at considerably higher temperatures

[Christoph Anton Mitterer]

On Tue, 2019-11-19 at 15:30 -0300, Henrique de Moraes Holschuh wrote:
> I need the output of "cat /proc/cpuinfo" and also of "grep .
> /sys/devices/system/cpu/vulnerabilities/*" please.


All below running with:
# dmesg | head -n1
[0.00] microcode: microcode updated early to revision 0xca, date = 
2019-09-26

# uname -a
Linux heisenberg 5.3.0-2-amd64 #1 SMP Debian 5.3.9-2 (2019-11-12) x86_64 
GNU/Linux



# cat /proc/cpuinfo
processor   : 0
vendor_id   : GenuineIntel
cpu family  : 6
model   : 142
model name  : Intel(R) Core(TM) i7-7600U CPU @ 2.80GHz
stepping: 9
microcode   : 0xca
cpu MHz : 992.983
cache size  : 4096 KB
physical id : 0
siblings: 4
core id : 0
cpu cores   : 2
apicid  : 0
initial apicid  : 0
fpu : yes
fpu_exception   : yes
cpuid level : 22
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov 
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb 
rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology 
nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est 
tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt 
tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch 
cpuid_fault epb invpcid_single pti ssbd ibrs ibpb stibp tpr_shadow vnmi 
flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms 
invpcid rtm mpx rdseed adx smap clflushopt intel_pt xsaveopt xsavec xgetbv1 
xsaves dtherm ida arat pln pts hwp hwp_notify hwp_act_window hwp_epp md_clear 
flush_l1d
bugs: cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds 
swapgs taa itlb_multihit
bogomips: 5799.77
clflush size: 64
cache_alignment : 64
address sizes   : 39 bits physical, 48 bits virtual
power management:

processor   : 1
vendor_id   : GenuineIntel
cpu family  : 6
model   : 142
model name  : Intel(R) Core(TM) i7-7600U CPU @ 2.80GHz
stepping: 9
microcode   : 0xca
cpu MHz : 999.945
cache size  : 4096 KB
physical id : 0
siblings: 4
core id : 1
cpu cores   : 2
apicid  : 2
initial apicid  : 2
fpu : yes
fpu_exception   : yes
cpuid level : 22
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov 
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb 
rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology 
nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est 
tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt 
tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch 
cpuid_fault epb invpcid_single pti ibrs ibpb stibp tpr_shadow vnmi flexpriority 
ept vpid ept_ad fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm 
mpx rdseed adx smap clflushopt intel_pt xsaveopt xsavec xgetbv1 xsaves dtherm 
ida arat pln pts hwp hwp_notify hwp_act_window hwp_epp
bugs: cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds 
swapgs taa itlb_multihit
bogomips: 5799.77
clflush size: 64
cache_alignment : 64
address sizes   : 39 bits physical, 48 bits virtual
power management:

processor   : 2
vendor_id   : GenuineIntel
cpu family  : 6
model   : 142
model name  : Intel(R) Core(TM) i7-7600U CPU @ 2.80GHz
stepping: 9
microcode   : 0xca
cpu MHz : 994.502
cache size  : 4096 KB
physical id : 0
siblings: 4
core id : 0
cpu cores   : 2
apicid  : 1
initial apicid  : 1
fpu : yes
fpu_exception   : yes
cpuid level : 22
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov 
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb 
rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology 
nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est 
tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt 
tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch 
cpuid_fault epb invpcid_single pti ssbd ibrs ibpb stibp tpr_shadow vnmi 
flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms 
invpcid rtm mpx rdseed adx smap clflushopt intel_pt xsaveopt xsavec xgetbv1 
xsaves dtherm ida arat pln pts hwp hwp_notify hwp_act_window hwp_epp md_clear 
flush_l1d
bugs: cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds 
swapgs taa itlb_multihit
bogomips: 5799.77
clflush size: 64
cache_alignment : 64
address sizes   : 39 bits physical, 48 bits virtual
power management:

processor   : 3
vendor_id   : GenuineIntel
cpu family  : 6
model   : 142
model name  : Intel(R) Core(TM) i7-7600U CPU @ 2.80GHz
stepping 

Bug#945253: Fwd: O: djvusmooth -- graphical editor for DjVu

[Sandro Tosi]

Package: wnpp
Severity: normal

on behalf of Daniel Stender 

I'm orphaning this package due to retirement.

Thanks,
Daniel Stender

Bug#945252: bsdmainutils: [calendar] Using non-Russian locale ignores the month in Russian calendar

[Michael Krylov]

Package: bsdmainutils
Version: 11.1.2+b1
Severity: important
Tags: l10n

Dear Maintainer,

calendar program, if one uses non-RU locale (maybe it's ok with other
cyrillic ones, like Ukrainian), Russian holidays are displayed
regardless of the month.

For example:

$ LANG=en_GB.UTF8 calendar -t 1125 | grep Татьянин
Nov 25  Татьянин день. Студенческий праздник

which is not correct, it's in January 25th, and it has a correct entry in
the calendar file:

$ grep Татьянин /usr/share/calendar/ru_RU/calendar.common 
25 янв. Татьянин день. Студенческий праздник

But if you set $LANG to ru_RU.UTF8, it is ok:

$ LANG=ru_RU.UTF8 calendar -t 1125 | grep Татьянин
$

I have a hunch that it is caused by the date translations in the database.
Maybe it should be kept in english (neutral, C) date format?

Thanks in advance!

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

Kernel: Linux 4.19.0-6-686 (SMP w/4 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 /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages bsdmainutils depends on:
ii  bsdutils 1:2.33.1-0.1
ii  debianutils  4.8.6.1
ii  libbsd0  0.9.1-2
ii  libc62.28-10
ii  libtinfo66.1+20181013-2+deb10u2

bsdmainutils recommends no packages.

Versions of packages bsdmainutils suggests:
ii  cpp   4:8.3.0-1
pn  vacation  
pn  wamerican | wordlist  
pn  whois 

-- no debconf information

Bug#945195: [PATCH 3/3] email-print-mime-structure: decrypt S/MIME parts with OpenSSL

[Sean Whitton]

control: tag -1 -patch

Hello Daniel,

On Thu 21 Nov 2019 at 02:30PM +08, Daniel Kahn Gillmor wrote:

> diff --git a/email-print-mime-structure b/email-print-mime-structure
> index ab90976..069648a 100755
> --- a/email-print-mime-structure
> +++ b/email-print-mime-structure
> @@ -135,6 +137,27 @@ class MimePrinter(object):
>  pass
>  return None
>
> +def openssl_decrypt(self, keys:List[str], ciphertext:bytes) -> 
> Optional[Message]:
> +keyname:str
> +ret:Optional[Message] = None
> +for keyname in keys:
> +inp:int
> +outp:int
> +inp, outp = os.pipe()
> +with open(outp, 'wb') as outf:
> +outf.write(ciphertext)
> +cmd = ['openssl', 'smime', '-decrypt', '-inform', 'DER', 
> '-inkey', keyname]
> +try:
> +out:subprocess.CompletedProcess[bytes] = subprocess.run(cmd,
> +
> stdin=inp,
> +
> capture_output=True)
> +except Exception as e:
> +logging.warning(f'Failed to decrypt with openssl: {e}')
> +return None
> +if out.returncode == 0:
> +return email.message_from_bytes(out.stdout)
> +return None
> +

Again, this function is almost identical to gpg_decrypt, so please
refactor.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#945195: [PATCH 2/3] email-print-mime-structure: decrypt S/MIME parts using gpgsm

[Sean Whitton]

Hello Daniel,

On Thu 21 Nov 2019 at 02:30PM +08, Daniel Kahn Gillmor wrote:

> diff --git a/email-print-mime-structure b/email-print-mime-structure
> index 27fb532..ab90976 100755
> --- a/email-print-mime-structure
> +++ b/email-print-mime-structure
> @@ -81,6 +81,7 @@ class MimePrinter(object):
>  cryptopayload:Optional[Message] = None
>  ciphertext:Union[List[Message],str,bytes,None] = None
>  try_pgp_decrypt:bool = self.args.pgpkey or self.args.use_gpg_agent
> +try_cms_decrypt:bool = self.args.use_gpg_agent
>
>  if try_pgp_decrypt and \
> (parent is not None) and \
> @@ -99,6 +100,19 @@ class MimePrinter(object):
>  logging.warning(f'Unable to decrypt')
>  return
>
> +if try_cms_decrypt and \
> +   cryptopayload is None and \
> +   z.get_content_type().lower() == 'application/pkcs7-mime':
> +ciphertext = z.get_payload(decode=True)
> +if not isinstance(ciphertext, bytes):
> +logging.warning('encrypted part was not a leaf mime part 
> somehow')
> +return
> +if self.args.use_gpg_agent:
> +cryptopayload = self.gpgsm_decrypt(ciphertext)

I think self.args.use_gpg_agent will always be True at this point in the
control flow?

> +def gpgsm_decrypt(self, ciphertext:bytes) -> Optional[Message]:
> +inp:int
> +outp:int
> +inp, outp = os.pipe()
> +with open(outp, 'wb') as outf:
> +outf.write(ciphertext)
> +try:
> +out:subprocess.CompletedProcess[bytes] = 
> subprocess.run(['gpgsm', '--batch', '--decrypt'],
> +
> stdin=inp,
> +
> capture_output=True)
> +except Exception as e:
> +logging.warning(f'Failed to decrypt with gpgsm: {e}')
> +return None
> +if out.returncode == 0:
> +return email.message_from_bytes(out.stdout)
> +return None
> +

This function is almost identical to gpg_decrypt.  Please refactor.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#945195: [PATCH 1/3] email-print-mime-structure: prepare for multiple forms of decryption

[Sean Whitton]

Hello,

On Thu 21 Nov 2019 at 02:30PM +08, Daniel Kahn Gillmor wrote:

> As we prepare for S/MIME decryption, we want to identify pgp
> decryption as just one type of decryption.  There is no functional
> change here.

Acked-by: Sean Whitton 

and applied.

> Signed-off-by: Daniel Kahn Gillmor 
> ---
>  email-print-mime-structure | 11 +++
>  1 file changed, 7 insertions(+), 4 deletions(-)
>
> diff --git a/email-print-mime-structure b/email-print-mime-structure
> index 4f165b1..27fb532 100755
> --- a/email-print-mime-structure
> +++ b/email-print-mime-structure
> @@ -78,15 +78,16 @@ class MimePrinter(object):
>  nbytes = len(payload)
>
>  print(f'{prefix}{z.get_content_type()}{cset}{disposition}{fname} 
> {nbytes:d} bytes')
> -try_decrypt:bool = self.args.pgpkey or self.args.use_gpg_agent
> +cryptopayload:Optional[Message] = None
> +ciphertext:Union[List[Message],str,bytes,None] = None
> +try_pgp_decrypt:bool = self.args.pgpkey or self.args.use_gpg_agent
>
> -if try_decrypt and \
> +if try_pgp_decrypt and \
> (parent is not None) and \
> (parent.get_content_type().lower() == 'multipart/encrypted') and \
> (str(parent.get_param('protocol')).lower() == 
> 'application/pgp-encrypted') and \
> (num == 2):
> -cryptopayload:Optional[Message] = None
> -ciphertext:Union[List[Message],str,bytes,None] = z.get_payload()
> +ciphertext = z.get_payload()
>  if not isinstance(ciphertext, str):
>  logging.warning('encrypted part was not a leaf mime part 
> somehow')
>  return
> @@ -97,6 +98,8 @@ class MimePrinter(object):
>  if cryptopayload is None:
>  logging.warning(f'Unable to decrypt')
>  return
> +
> +if cryptopayload is not None:
>  newprefix = prefix[:-3] + ' '
>  print(f'{newprefix}↧ (decrypts to)')
>  self.print_tree(cryptopayload, newprefix + '└', z, 0)

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#940312: /etc/issue: /etc/issue is being updated by Debian when it doesn't need to

[Santiago Vila]

On Thu, Nov 21, 2019 at 11:22:00AM -0800, Ben Wong wrote:
> Hi, I know this is low-priority and everyone is busy on important matters,
> but I was wondering if anybody had looked at this yet. The fix I included
> is simple and easily verified. I'm hoping that it can be included in Debian
> 11 (Bullseye).

The suggested change would make /etc/issue to show "buster" in Debian 10.

However, Debian has never included the codename in /etc/issue in
stable releases.

Therefore, we can't just apply the suggested change.

Thanks.

Bug#945251: otrs2: CVE-2019-18179 CVE-2019-18180

[Salvatore Bonaccorso]

Source: otrs2
Version: 6.0.23-2
Severity: grave
Tags: security upstream
Justification: user security hole

Hi,

The following vulnerabilities were published for otrs2

CVE-2019-18179[0] and CVE-2019-18180[1].

If you fix the vulnerabilities please also make sure to include the
CVE (Common Vulnerabilities & Exposures) ids in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2019-18179
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-18179

https://community.otrs.com/security-advisory-2019-14-security-update-for-otrs-framework/
[1] https://security-tracker.debian.org/tracker/CVE-2019-18180
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-18180

https://community.otrs.com/security-advisory-2019-15-security-update-for-otrs-framework/

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#927340: plantuml: should depend on default-jre-headless (only recommend or suggest default-jre if at all)

[Matteo Settenvini]

> plantuml package declares a dependency on default-jre but is 
> usable from command-line so seems to only really need 
> default-jre-headless.

I second that. I even run it as a service on a server to generate
images fast. I would rather like to avoid the hundreds of megabytes of
dependencies that it carries with it when installing it e.g. in a
docker image.

For the vast majority of people, I would say they don't even know a
user interface exists (they are more likely to use it inside an editor
such as VS Code with automated preview functionalities).

Cheers,
Matteo


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

Bug#945250: glibc: CVE-2019-19126

[Salvatore Bonaccorso]

Source: glibc
Version: 2.29-3
Severity: important
Tags: security upstream
Forwarded: https://sourceware.org/bugzilla/show_bug.cgi?id=25204
Control: found -1 2.28-10
Control: found -1 2.24-11+deb9u1
Control: found -1 2.24-11+deb9u4
Control: found -1 2.24-11

Hi,

The following vulnerability was published for glibc, filling this bug
mainly for tracking purpose, it was reported upstream at [1].

CVE-2019-19126[0]:
| On the x86-64 architecture, the GNU C Library (aka glibc) before 2.31
| fails to ignore the LD_PREFER_MAP_32BIT_EXEC environment variable
| during program execution after a security transition, allowing local
| attackers to restrict the possible mapping addresses for loaded
| libraries and thus bypass ASLR for a setuid program.


If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2019-19126
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-19126
[1] https://sourceware.org/bugzilla/show_bug.cgi?id=25204

Regards,
Salvatore

Bug#945244: r-cran-sf: upstream regression, unaligned access on armhf

[Andreas Tille]

Thanks a lot - that was super quick!

On Thu, Nov 21, 2019 at 09:50:16PM +0100, Edzer Pebesma wrote:
> Thanks, this has probably been solved in
> 
> https://github.com/r-spatial/sf/pull/1154
> 
> and will be in the next release.
> 
> On 11/21/19 9:38 PM, Andreas Tille wrote:
> > Control: tags -1 upstream
> > Control: forwarded -1 Edzer Pebesma 
> > 
> > 
> > Hi Edzer,
> > 
> > as you can read below there is a test suite regression in Ubuntu for
> > the armhf architecture.  Do you have any idea how this can be fixed?
> > 
> > Kind regards
> > 
> >Andreas.
> > 
> > 
> > On Thu, Nov 21, 2019 at 11:08:59AM -0800, Steve Langasek wrote:
> >> Source: r-cran-sf
> >> Version: 0.8-0+dfsg-1
> >> Severity: serious
> >> User: ubuntu-de...@lists.ubuntu.com
> >> Usertags: origin-ubuntu focal
> >>
> >> Hi Andreas,
> >>
> >> With the upload of r-cran-sf 0.8-0+dfsg-1, the autopkgtests are failing in
> >> Ubuntu only on armhf due to a regression in alignment handling:
> >>
> >> [...]
> >> Attribute-geometry relationship: 0 constant, 1 aggregate, 1 identity
> >> geometry type:  MULTIPOLYGON
> >> dimension:  XY
> >> bbox:   xmin: 0 ymin: 0 xmax: 1 ymax: 1
> >> epsg (SRID):NA
> >> proj4string:NA
> >>   Group.1   a   geometry
> >> 1   1 1.5 MULTIPOLYGON (((0 0, 1 0, 1...
> >>> (a = aggregate(s, list(c(1,1)), mean, do_union = TRUE))
> >> Bus error (core dumped)
> >> autopkgtest [11:32:17]: test run-unit-test: ---]
> >> [...]
> >>
> >>   
> >> (https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/armhf/r/r-cran-sf/20191109_113707_4303b@/log.gz)
> >>
> >> Since Debian only runs autopkgtests on amd64, this did not block migration
> >> of the new version of the package to Debian testing; nevertheless this is a
> >> serious failure of the package on armhf.  I have grabbed a backtrace which
> >> points to a problem in r-cran-sf itself, not in any of its dependencies:
> >>
> >> Program received signal SIGBUS, Bus error.
> >> 0xf47431cc in wkb_read (wkb=, wkb=)
> >> at wkb.cpp:201
> >> 201double d = wkb_read(wkb);
> >> (gdb) bt
> >> #0  0xf47431cc in wkb_read (wkb=, wkb= >> out>)
> >> at wkb.cpp:201
> >> #1  read_numeric_matrix (wkb=wkb@entry=0xfffe7ddc, n_dims=n_dims@entry=2, 
> >> swap=swap@entry=false, cls=..., empty=empty@entry=0x0) at wkb.cpp:201
> >> #2  0xf47434b0 in read_matrix_list (wkb=wkb@entry=0xfffe7ddc, 
> >> n_dims=n_dims@entry=2, swap=swap@entry=false, cls=..., 
> >> empty=empty@entry=0xfffe7d27) at 
> >> /usr/include/c++/9/ext/new_allocator.h:89
> >> #3  0xf474430c in read_data (wkb=wkb@entry=0xfffe7ddc, 
> >> EWKB=EWKB@entry=true, 
> >> spatialite=spatialite@entry=false, endian=endian@entry=1, 
> >> addclass=addclass@entry=true, type=type@entry=0xfffe7dd4, 
> >> srid=srid@entry=0xfffe7dd8)
> >> at /usr/lib/R/site-library/Rcpp/include/Rcpp/vector/generic_proxy.h:37
> >> #4  0xf474590a in CPL_read_wkb (wkb_list=..., EWKB=EWKB@entry=true, 
> >> spatialite=spatialite@entry=false)
> >> at /usr/lib/R/site-library/Rcpp/include/Rcpp/vector/generic_proxy.h:37
> >> #5  0xf472d5da in sfc_from_geometry(GEOSContextHandle_HS*, 
> >> std::vector 
> >> >, std::allocator >> (GEOSGeom_t*)> > > >&, int, bool) (
> >> hGEOSCtxt=hGEOSCtxt@entry=0x2154c48, 
> >> geom=std::vector of length 1, capacity 1 = {...}, dim=, 
> >> free=free@entry=true)
> >> at /usr/lib/R/site-library/Rcpp/include/Rcpp/vector/traits.h:65
> >> #6  0xf472f542 in CPL_geos_union (sfc=..., by_feature=)
> >> at geos.cpp:600
> >> #7  0xf47100d8 in _sf_CPL_geos_union (sfcSEXP=0x1f0d988, 
> >> by_featureSEXP=0x419568)
> >> at /usr/lib/R/site-library/Rcpp/include/Rcpp/as.h:151
> >> #8  0xf7ce238c in ?? () from /usr/lib/R/lib/libR.so
> >> Backtrace stopped: previous frame identical to this frame (corrupt stack?)
> >> (gdb)
> >>
> >> -- 
> >> Steve Langasek   Give me a lever long enough and a Free OS
> >> Debian Developer   to set it on, and I can move the world.
> >> Ubuntu Developer   https://www.debian.org/
> >> slanga...@ubuntu.com vor...@debian.org
> > 
> > 
> > 
> >> ___
> >> R-pkg-team mailing list
> >> r-pkg-t...@alioth-lists.debian.net
> >> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/r-pkg-team
> > 
> > 
> 
> -- 
> Edzer Pebesma
> Institute for Geoinformatics
> Heisenbergstrasse 2, 48151 Muenster, Germany
> Phone: +49 251 8333081

pub   RSA 3072/EC55D64D 2018-08-28 Edzer Pebesma 
> sub   RSA 3072/3953CA4C 2018-08-28
> 

-- 
http://fam-tille.de

Bug#937330: Help with upgrading psychopy needed

[Rebecca N. Palmer]

This incompatibility is known upstream as
https://github.com/psychopy/psychopy/issues/2189
but has no activity beyond declaring the version restriction.

https://docs.pytest.org/en/latest/deprecations.html#pytest-namespace
has a suggested replacement.

Bug#945249: angular.js: CVE-2019-10768

[Salvatore Bonaccorso]

Source: angular.js
Version: 1.5.10-1
Severity: grave
Tags: security upstream
Justification: user security hole

Hi,

The following vulnerability was published for angular.js.

CVE-2019-10768[0]:
| In AngularJS before 1.7.9 the function `merge()` could be tricked into
| adding or modifying properties of `Object.prototype` using a
| `__proto__` payload.

There is a simple POC/verifier available on [1].

angular.merge({}, JSON.parse('{"__proto__": {"xxx": "polluted"}}'));
console.log(({}).xxx);

If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2019-10768
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-10768
[1] https://snyk.io/vuln/SNYK-JS-ANGULAR-534884
[2] 
https://github.com/angular/angular.js/commit/add78e62004e80bb1e16ab2dfe224afa8e513bc3

Regards,
Salvatore

Bug#945090: More Info on Dell XPS 13 9380 WIreless issue with intel-microcode update

[Chris Lapera]

Just a note: I'm running the non-free iso of Debian 10.2 
debian-live-10.2.0-amd64-gnome+nonfree.iso

Bug#945244: r-cran-sf: upstream regression, unaligned access on armhf

[Edzer Pebesma]

Thanks, this has probably been solved in

https://github.com/r-spatial/sf/pull/1154

and will be in the next release.

On 11/21/19 9:38 PM, Andreas Tille wrote:
> Control: tags -1 upstream
> Control: forwarded -1 Edzer Pebesma 
> 
> 
> Hi Edzer,
> 
> as you can read below there is a test suite regression in Ubuntu for
> the armhf architecture.  Do you have any idea how this can be fixed?
> 
> Kind regards
> 
>Andreas.
> 
> 
> On Thu, Nov 21, 2019 at 11:08:59AM -0800, Steve Langasek wrote:
>> Source: r-cran-sf
>> Version: 0.8-0+dfsg-1
>> Severity: serious
>> User: ubuntu-de...@lists.ubuntu.com
>> Usertags: origin-ubuntu focal
>>
>> Hi Andreas,
>>
>> With the upload of r-cran-sf 0.8-0+dfsg-1, the autopkgtests are failing in
>> Ubuntu only on armhf due to a regression in alignment handling:
>>
>> [...]
>> Attribute-geometry relationship: 0 constant, 1 aggregate, 1 identity
>> geometry type:  MULTIPOLYGON
>> dimension:  XY
>> bbox:   xmin: 0 ymin: 0 xmax: 1 ymax: 1
>> epsg (SRID):NA
>> proj4string:NA
>>   Group.1   a   geometry
>> 1   1 1.5 MULTIPOLYGON (((0 0, 1 0, 1...
>>> (a = aggregate(s, list(c(1,1)), mean, do_union = TRUE))
>> Bus error (core dumped)
>> autopkgtest [11:32:17]: test run-unit-test: ---]
>> [...]
>>
>>   
>> (https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/armhf/r/r-cran-sf/20191109_113707_4303b@/log.gz)
>>
>> Since Debian only runs autopkgtests on amd64, this did not block migration
>> of the new version of the package to Debian testing; nevertheless this is a
>> serious failure of the package on armhf.  I have grabbed a backtrace which
>> points to a problem in r-cran-sf itself, not in any of its dependencies:
>>
>> Program received signal SIGBUS, Bus error.
>> 0xf47431cc in wkb_read (wkb=, wkb=)
>> at wkb.cpp:201
>> 201  double d = wkb_read(wkb);
>> (gdb) bt
>> #0  0xf47431cc in wkb_read (wkb=, wkb=)
>> at wkb.cpp:201
>> #1  read_numeric_matrix (wkb=wkb@entry=0xfffe7ddc, n_dims=n_dims@entry=2, 
>> swap=swap@entry=false, cls=..., empty=empty@entry=0x0) at wkb.cpp:201
>> #2  0xf47434b0 in read_matrix_list (wkb=wkb@entry=0xfffe7ddc, 
>> n_dims=n_dims@entry=2, swap=swap@entry=false, cls=..., 
>> empty=empty@entry=0xfffe7d27) at 
>> /usr/include/c++/9/ext/new_allocator.h:89
>> #3  0xf474430c in read_data (wkb=wkb@entry=0xfffe7ddc, EWKB=EWKB@entry=true, 
>> spatialite=spatialite@entry=false, endian=endian@entry=1, 
>> addclass=addclass@entry=true, type=type@entry=0xfffe7dd4, 
>> srid=srid@entry=0xfffe7dd8)
>> at /usr/lib/R/site-library/Rcpp/include/Rcpp/vector/generic_proxy.h:37
>> #4  0xf474590a in CPL_read_wkb (wkb_list=..., EWKB=EWKB@entry=true, 
>> spatialite=spatialite@entry=false)
>> at /usr/lib/R/site-library/Rcpp/include/Rcpp/vector/generic_proxy.h:37
>> #5  0xf472d5da in sfc_from_geometry(GEOSContextHandle_HS*, 
>> std::vector >, 
>> std::allocator 
>> > > >&, int, bool) (
>> hGEOSCtxt=hGEOSCtxt@entry=0x2154c48, 
>> geom=std::vector of length 1, capacity 1 = {...}, dim=, 
>> free=free@entry=true)
>> at /usr/lib/R/site-library/Rcpp/include/Rcpp/vector/traits.h:65
>> #6  0xf472f542 in CPL_geos_union (sfc=..., by_feature=)
>> at geos.cpp:600
>> #7  0xf47100d8 in _sf_CPL_geos_union (sfcSEXP=0x1f0d988, 
>> by_featureSEXP=0x419568)
>> at /usr/lib/R/site-library/Rcpp/include/Rcpp/as.h:151
>> #8  0xf7ce238c in ?? () from /usr/lib/R/lib/libR.so
>> Backtrace stopped: previous frame identical to this frame (corrupt stack?)
>> (gdb)
>>
>> -- 
>> Steve Langasek   Give me a lever long enough and a Free OS
>> Debian Developer   to set it on, and I can move the world.
>> Ubuntu Developer   https://www.debian.org/
>> slanga...@ubuntu.com vor...@debian.org
> 
> 
> 
>> ___
>> R-pkg-team mailing list
>> r-pkg-t...@alioth-lists.debian.net
>> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/r-pkg-team
> 
> 

-- 
Edzer Pebesma
Institute for Geoinformatics
Heisenbergstrasse 2, 48151 Muenster, Germany
Phone: +49 251 8333081


pEpkey.asc
Description: application/pgp-keys

Bug#945147: KMail blank print

[Griera]

Thank you so much, John,

First, thanks for your contributions to the Debian project!

For many years now, I'm using Debian stable with Kde at work and at home. And I 
planned to use Debian 10 Buster with Kde for the next few years (until the 
release of the next version). As it stands, Kmail is not useful. In addition to 
not printing, it hangs very often. Is there any workaround to avoid these 
errors and not wait a few years until the next stable release is released?

Thank's for your help. Griera


On Thu, 21 Nov 2019 11:02:39 -0500
John Scott  wrote:

> reassign 945147 libqt5webengine5
> forcemerge 919504 945147
> 
> This issue in Qt WebEngine and has been fixed in Debian unstable. As such, 
> I'm 
> closing this bug, though unfortunately the fix is unlikely to land in Buster.

Bug#930492: pkg-config: Broken i686-w64-mingw32-pkg-config and x86_64-w64-mingw32-pkg-config

[Stephen Kitt]

Control: reassign -1 mingw-w64-tools

Hi Tollef,

On Thu, 21 Nov 2019 20:58:05 +0100, Tollef Fog Heen  wrote:
> > I noticed that the pkg-config hook is very careful to only
> > touch /usr/bin/*-pkg-config links it owns. Would it be acceptable to
> > continue shipping MinGW-w64 pkg-config instances there? Not using
> > crosswrapper, of course, but a MinGW-w64-hosted implementation.  
> 
> Without binding future pkg-config maintainers too much: I think this is
> fine for you to do.  It might change in the future, at which point
> we'll talk and figure the way forward, but I don't think that should be
> particularly problematic.

OK, thanks!

Regards,

Stephen


pgp3_PiQvmEaC.pgp
Description: OpenPGP digital signature

Bug#945244: r-cran-sf: upstream regression, unaligned access on armhf

[Andreas Tille]

Control: tags -1 upstream
Control: forwarded -1 Edzer Pebesma 


Hi Edzer,

as you can read below there is a test suite regression in Ubuntu for
the armhf architecture.  Do you have any idea how this can be fixed?

Kind regards

   Andreas.


On Thu, Nov 21, 2019 at 11:08:59AM -0800, Steve Langasek wrote:
> Source: r-cran-sf
> Version: 0.8-0+dfsg-1
> Severity: serious
> User: ubuntu-de...@lists.ubuntu.com
> Usertags: origin-ubuntu focal
> 
> Hi Andreas,
> 
> With the upload of r-cran-sf 0.8-0+dfsg-1, the autopkgtests are failing in
> Ubuntu only on armhf due to a regression in alignment handling:
> 
> [...]
> Attribute-geometry relationship: 0 constant, 1 aggregate, 1 identity
> geometry type:  MULTIPOLYGON
> dimension:  XY
> bbox:   xmin: 0 ymin: 0 xmax: 1 ymax: 1
> epsg (SRID):NA
> proj4string:NA
>   Group.1   a   geometry
> 1   1 1.5 MULTIPOLYGON (((0 0, 1 0, 1...
> > (a = aggregate(s, list(c(1,1)), mean, do_union = TRUE))
> Bus error (core dumped)
> autopkgtest [11:32:17]: test run-unit-test: ---]
> [...]
> 
>   
> (https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/armhf/r/r-cran-sf/20191109_113707_4303b@/log.gz)
> 
> Since Debian only runs autopkgtests on amd64, this did not block migration
> of the new version of the package to Debian testing; nevertheless this is a
> serious failure of the package on armhf.  I have grabbed a backtrace which
> points to a problem in r-cran-sf itself, not in any of its dependencies:
> 
> Program received signal SIGBUS, Bus error.
> 0xf47431cc in wkb_read (wkb=, wkb=)
> at wkb.cpp:201
> 201   double d = wkb_read(wkb);
> (gdb) bt
> #0  0xf47431cc in wkb_read (wkb=, wkb=)
> at wkb.cpp:201
> #1  read_numeric_matrix (wkb=wkb@entry=0xfffe7ddc, n_dims=n_dims@entry=2, 
> swap=swap@entry=false, cls=..., empty=empty@entry=0x0) at wkb.cpp:201
> #2  0xf47434b0 in read_matrix_list (wkb=wkb@entry=0xfffe7ddc, 
> n_dims=n_dims@entry=2, swap=swap@entry=false, cls=..., 
> empty=empty@entry=0xfffe7d27) at /usr/include/c++/9/ext/new_allocator.h:89
> #3  0xf474430c in read_data (wkb=wkb@entry=0xfffe7ddc, EWKB=EWKB@entry=true, 
> spatialite=spatialite@entry=false, endian=endian@entry=1, 
> addclass=addclass@entry=true, type=type@entry=0xfffe7dd4, 
> srid=srid@entry=0xfffe7dd8)
> at /usr/lib/R/site-library/Rcpp/include/Rcpp/vector/generic_proxy.h:37
> #4  0xf474590a in CPL_read_wkb (wkb_list=..., EWKB=EWKB@entry=true, 
> spatialite=spatialite@entry=false)
> at /usr/lib/R/site-library/Rcpp/include/Rcpp/vector/generic_proxy.h:37
> #5  0xf472d5da in sfc_from_geometry(GEOSContextHandle_HS*, 
> std::vector >, 
> std::allocator 
> > > >&, int, bool) (
> hGEOSCtxt=hGEOSCtxt@entry=0x2154c48, 
> geom=std::vector of length 1, capacity 1 = {...}, dim=, 
> free=free@entry=true)
> at /usr/lib/R/site-library/Rcpp/include/Rcpp/vector/traits.h:65
> #6  0xf472f542 in CPL_geos_union (sfc=..., by_feature=)
> at geos.cpp:600
> #7  0xf47100d8 in _sf_CPL_geos_union (sfcSEXP=0x1f0d988, 
> by_featureSEXP=0x419568)
> at /usr/lib/R/site-library/Rcpp/include/Rcpp/as.h:151
> #8  0xf7ce238c in ?? () from /usr/lib/R/lib/libR.so
> Backtrace stopped: previous frame identical to this frame (corrupt stack?)
> (gdb)
> 
> -- 
> Steve Langasek   Give me a lever long enough and a Free OS
> Debian Developer   to set it on, and I can move the world.
> Ubuntu Developer   https://www.debian.org/
> slanga...@ubuntu.com vor...@debian.org



> ___
> R-pkg-team mailing list
> r-pkg-t...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/r-pkg-team


-- 
http://fam-tille.de

Bug#930492: pkg-config: Broken i686-w64-mingw32-pkg-config and x86_64-w64-mingw32-pkg-config

[Tollef Fog Heen]

]] Stephen Kitt 

> I noticed that the pkg-config hook is very careful to only
> touch /usr/bin/*-pkg-config links it owns. Would it be acceptable to continue
> shipping MinGW-w64 pkg-config instances there? Not using crosswrapper, of
> course, but a MinGW-w64-hosted implementation.

Without binding future pkg-config maintainers too much: I think this is
fine for you to do.  It might change in the future, at which point
we'll talk and figure the way forward, but I don't think that should be
particularly problematic.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Bug#945232: ruby-benchmark-suite fails to build with ruby-benchmark-ips 2.7 in experimental

[Utkarsh Gupta]

Hi Praveen,

On Thu, 21 Nov 2019 20:51:44 +0530 Pirate Praveen
 wrote:
> Package: ruby-benchmark-suite
> Version: 1.0.0+git.20130122.5bded6-2
> Severity: important
>
> This package fails to build with ruby-benchmark-ips 2.7 in experimental
> and blocking its upload to unstable.
>
> /usr/bin/ruby2.5 /usr/bin/gem2deb-test-runner
>
>
┌──┐
> │ Run tests for ruby2.5 from debian/ruby-tests.rb │
>
└──┘
>
>
RUBYLIB=/<>/debian/ruby-benchmark-suite/usr/lib/ruby/vendor_ruby:.

>
GEM_PATH=/var/lib/gems/2.5.0:/usr/lib/ruby/gems/2.5.0:/usr/share/rubygems-integration/2.5.0:/usr/share/rubygems-integration/all:/usr/lib/x86_64-linux-gnu/rubygems-integration/2.5.0

> ruby2.5 debian/ruby-tests.rb
> /usr/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in
> `require': cannot load such file -- benchmark/helpers (LoadError)

This happens because upstream of benchmark-ips removed
benchmark/helpers; see here[1].
For the very same, I'm attaching the patch to fix this :)

Furthermore, I've pushed the fix and the changes to the salsa repo,
which could be found here[2].
NOTE: Since there's no gemspec present (either in debian or
upstream[3]), I've left it as is. This also means the autopkgtest would
*not* be able to parse the dependencies and wouldn't proceed.
I'll leave that to you and for the maintainer of this package to decide :)

That said, ruby-benchmark-suite *now* works with ruby-benchmark-ips 2.7
in experimental.


Best,
Utkarsh
---
[1]:
https://salsa.debian.org/ruby-team/ruby-benchmark-ips/commit/48eb77c13e731c30e4441ea55f954e6913695e57#e9d3ebbdb8340b26424c10e5a55e7d6ef26e1ce0
[2]: https://salsa.debian.org/ruby-team/ruby-benchmark-suite
[3]: https://github.com/evanphx/benchmark_suite

Description: Remove "requirement" of benchmark/helpers.
 This file is no longer provided by the upstream.
Author: Utkarsh Gupta 
Bug-Debian: https://bugs.debian.org/945232
Last-Update: 2019-11-21

--- a/lib/benchmark_suite.rb
+++ b/lib/benchmark_suite.rb
@@ -1,6 +1,5 @@
 require 'benchmark/suite'
 require 'benchmark/ips'
-require 'benchmark/helpers'
 
 class BenchmarkSuite
   VERSION = '1.0.0'


signature.asc
Description: OpenPGP digital signature

Bug#945247: ITP: python-django-rest-framework-guardian -- django-guardian support for Django REST Framework

[Michael Fladischer]

Package: wnpp
Severity: wishlist
Owner: Michael Fladischer 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: python-django-rest-framework-guardian
  Version : 0.3.0
  Upstream Author : Ryan P Kilby 
* URL : https://github.com/rpkilby/django-rest-framework-guardian/
* License : BSD-3-clause
  Programming Lang: Python
  Description : django-guardian support for Django REST Framework

 django-rest-framework-guardian provides django-guardian integrations for Django
 REST Framework.
 It provides an ObjectPermissionsFilter to which will ensure that querysets only
 returns objects for which the user has the appropriate view permission and an
 ObjectPermissionsAssignmentMixin that allows permissions to be easily assigned
 to users and/or groups through serializers.

I intend to maintain this package as part of the DPMT.

-BEGIN PGP SIGNATURE-

iQFFBAEBCgAvFiEEqVSlRXW87UkkCnJc/9PIi5l90WoFAl3W9CwRHGZsYWRpQGRl
Ymlhbi5vcmcACgkQ/9PIi5l90Wr8XggAtMRZvl0IZorRflGuVQR6p6c0sbI+NIhU
+P94bHDaq9sivb81J5ziXwgWGxKEmpwQa+KNCPEG579NL6N6+koAyhsKchyQX2WW
ny8iGz1J6apkyXlfYQPjCPto8UMIe0uW5LZR19dbGaXmAr/+COInaczKBYRneNkg
bftl8bK6nFar7y07JUwjuYXywTpTFGFST+L3kKG/Vx22lVBEUqeIk2Rg7OJKJIR4
RTYLsYIZLDejHmOP5NKMO9Jb09BFWZixzovDxc9bZ7bvStooASpAgj4Sd3BppU6g
qkZrkxQaIwkYz3r9KxD818PAjywbIZoPAdzyz/lCqYJkC6tXD4yX/w==
=cVy1
-END PGP SIGNATURE-

Bug#873677: porterboxes are off?

[Aaron M. Ucko]

Anton Gladky  writes:

> I wanted to try to fix this bug

Great, thanks!

> Is there an opportunity to get an access on hurd or kfreebsd machine?

Good question.  (To be clear, I'm not actually a porter myself, just a
regular DD who filed a bunch of portability bugs back when I wasn't
quite as busy.)  You might consider firing up a private VM.

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

Bug#944874: strange phenomenon with primus + nvidia-tesla

[Patrice Duroux]

Hi Andreas,

What I can say is that around the end of august and begin of september (ref. my 
previous posts at pkg-nvidia-devel) everything was fine with the couple 
optimus+nvidia up to 418.88-1
(no specific trouble nor log message).
Once its was removed from Sid to go for new releases, I saved a copy of this 
version using snapshot.debian.org. And then I tried
to use nouveau and vgaswitcheroo and discovered then that it was not supporting 
the video device of my laptop.

So today here is my situation:

1) 418.88-1 (using the backup)

- no specific error message in the boot log
- optirun is working fine using glxgears to test
- but now there is an error while closing the window:

nov. 21 20:53:37 hp-dark bumblebeed[718]: [  403.370951] [ERROR][XORG] (EE)
nov. 21 20:53:37 hp-dark bumblebeed[718]: [  403.370978] [ERROR][XORG] (EE) 
Backtrace:
nov. 21 20:53:37 hp-dark bumblebeed[718]: [  403.370983] [ERROR][XORG] (EE) 0: 
/usr/lib/xorg/Xorg (OsLookupColor+0x139) [0x55d4ce6b72c9]
nov. 21 20:53:37 hp-dark bumblebeed[718]: [  403.370986] [ERROR][XORG] (EE) 1: 
/lib/x86_64-linux-gnu/libpthread.so.0 (funlockfile+0x50) [0x7f8bd105855f]
nov. 21 20:53:37 hp-dark bumblebeed[718]: [  403.370990] [ERROR][XORG] (EE) 2: 
/usr/lib/x86_64-linux-gnu/libnvidia-glcore.so.418.88 (_nv015glcore+0x14170) 
[0x7f8bcf5>
nov. 21 20:53:37 hp-dark bumblebeed[718]: [  403.370994] [ERROR][XORG] (EE) 3: 
/usr/lib/x86_64-linux-gnu/libnvidia-glcore.so.418.88 (_nv015glcore+0x1434e) 
[0x7f8bcf5>
nov. 21 20:53:37 hp-dark bumblebeed[718]: [  403.370999] [ERROR][XORG] (EE) 4: 
/usr/lib/x86_64-linux-gnu/nvidia/libGL.so.1 (glXCreateNewContext+0x9c18) 
[0x7f8bd06aa1>
nov. 21 20:53:37 hp-dark bumblebeed[718]: [  403.371003] [ERROR][XORG] (EE)
nov. 21 20:53:37 hp-dark bumblebeed[718]: [  403.371007] [ERROR][XORG] (EE) 
Segmentation fault at address 0x8
nov. 21 20:53:37 hp-dark bumblebeed[718]: [  403.371010] [ERROR][XORG] (EE)
nov. 21 20:53:37 hp-dark bumblebeed[718]: [  403.371014] [ERROR][XORG] (EE) 
Caught signal 11 (Segmentation fault). Server aborting
nov. 21 20:53:37 hp-dark bumblebeed[718]: [  403.371017] [ERROR][XORG] (EE)
nov. 21 20:53:37 hp-dark bumblebeed[718]: [  403.371021] [ERROR][XORG] (EE)
nov. 21 20:53:37 hp-dark bumblebeed[718]: [  403.371025] [ERROR][XORG] (EE) 
Please also check the log file at "/var/log/Xorg.8.log" for additional 
information.
nov. 21 20:53:37 hp-dark bumblebeed[718]: [  403.371028] [ERROR][XORG] (EE)
nov. 21 20:53:37 hp-dark systemd-coredump[4066]: Process 4037 (Xorg) of user 0 
dumped core.
 
 Stack trace of thread 4037:
 #0  0x7f8bd0ebd081 
__GI_raise (libc.so.6)
 #1  0x7f8bd0ea8535 
__GI_abort (libc.so.6)
 #2  0x55d4ce6b9dea OsAbort 
(Xorg)
 #3  0x55d4ce6bf903 n/a 
(Xorg)
 #4  0x55d4ce6c0769 
FatalError (Xorg)
 #5  0x55d4ce6b7201 n/a 
(Xorg)
 #6  0x7f8bd1058510 
__restore_rt (libpthread.so.0)
 #7  0x7f8bcf57f430 n/a 
(libnvidia-glcore.so.418.88)
 #8  0x7f8bcf57f60e n/a 
(libnvidia-glcore.so.418.88)
 #9  0x7f8bd06a0578 n/a 
(libGL.so.1)
 #10 0x7f8bd07170d5 n/a 
(libGL.so.1)
 #11 0x7f8bd1fba965 
_dl_fini (ld-linux-x86-64.so.2)
 #12 0x7f8bd0ebf720 
__run_exit_handlers (libc.so.6)
 #13 0x7f8bd0ebf85a 
__GI_exit (libc.so.6)
 #14 0x7f8bd0ea9bc2 
__libc_start_main (libc.so.6)
 #15 0x55d4ce54667a _start 
(Xorg)
nov. 21 20:53:37 hp-dark systemd[1]: systemd-coredump@0-4065-0.service: 
Succeeded.

2) 418.87.01-1~git

(save result)

nov. 21 20:11:40 hp-dark bumblebeed[720]: [   62.769535] [ERROR][XORG] (EE)
nov. 21 20:11:40 hp-dark bumblebeed[720]: [   62.769558] [ERROR][XORG] (EE) 
Backtrace:
nov. 21 20:11:40 hp-dark bumblebeed[720]: [   62.769562] [ERROR][XORG] (EE) 0: 
/usr/lib/xorg/Xorg (OsLookupColor+0x139) [0x55655484f2c9]
nov. 21 20:11:40 hp-dark bumblebeed[720]: [   62.769565] [ERROR][XORG] (EE) 1: 
/lib/x86_64-linux-gnu/libpthread.so.0 (funlockfile+0x50) [0x7f277aa3255f]
nov. 21 20:11:40 hp-dark bumblebeed[720]: [   62.769568] [ERROR][XORG] (EE) 2: 
/usr/lib/x86_64-linux-gnu/libnvidia-glcore.so.418.87.01 (_nv015glcore+0x141a0>
nov. 21 20:11:40 hp-dark bumblebeed[720]: [   62.769571] [ERROR][XORG] 

Bug#945246: fails to build from source, attempts to install file in / rather than debian/tmp/

[Christopher Cramer]

Package: liquidsoap
Version: 1.4.0-1

While building the package, I received this error:

/usr/bin/install -c -m 644 scripts/bash-completion 
/usr/share/bash-completion/completions/liquidsoap
/usr/bin/install: cannot create regular file 
'/usr/share/bash-completion/completions/liquidsoap': Permission denied
make[2]: *** [Makefile:85: install-local] Error 1
make[2]: Leaving directory '/home/tsuyoshi/src/liquidsoap'
make[1]: *** [debian/rules:32: override_dh_auto_install] Error 2
make[1]: Leaving directory '/home/tsuyoshi/src/liquidsoap'
make: *** [debian/rules:14: binary] Error 2

This is because the installation of the bash-completion script is
not respecting DESTDIR, and thus installing it in / rather than
debian/tmp. The following patch fixes it.

diff --git a/debian/liquidsoap.install.in b/debian/liquidsoap.install.in
index 2f306d2..d2425e6 100644
--- a/debian/liquidsoap.install.in
+++ b/debian/liquidsoap.install.in
@@ -2,4 +2,4 @@ src/META @OCamlStdlibDir@/liquidsoap/
 etc/logrotate.d/liquidsoap
 usr/bin/liquidsoap
 usr/share/liquidsoap/*/* usr/share/liquidsoap
-etc/bash_completion.d/liquidsoap etc/bash-completion/completions
+usr/share/bash-completion/completions/liquidsoap
diff --git a/debian/rules b/debian/rules
index 808a3cb..697751e 100755
--- a/debian/rules
+++ b/debian/rules
@@ -31,6 +31,7 @@ override_dh_auto_install:
chrpath -d src/liquidsoap
$(MAKE) install DESTDIR=$(DESTDIR) \
prefix=$(DESTDIR)/usr sysconfdir=$(DESTDIR)/etc \
+  bashcompdir=$(DESTDIR)/usr/share/bash-completion/completions \
INSTALL_DAEMON=no OCAMLFIND_LDCONF=ignore
dh_install
 

Bug#944116: tasksel: Please make another source-only upload

[Boyuan Yang]

在 2019-11-21四的 20:54 +0100，Holger Wansing写道：
> Hi,
> 
> Ansgar  wrote:
> > We had an issue where old arch:all packages were detected as cruft
> > when
> > buildds had not built the new version yet (which should no longer
> > happen
> > thanks to Ivo De Decker's patch[1]), but here these are
> > maintainer-provided packages :/
> > 
> > Maybe a race between dak accepting the package from NEW (so it's
> > only
> > half-installed) and a parallel process generating the cruft report
> > based
> > on that half-installed state? (If this is the case, then the patch
> > from
> > above should also help.)
> > 
> >   [1]: https://salsa.debian.org/ftp-team/dak/merge_requests/163
> > 
> > I don't have resources to look into this in more detail currently
> > though. So I suggest to do an extra upload to NEW for now.
> 
> Does that mean I can do an extra upload for the 3.57 version (that
> version
> which was rejected yesterday) or do I need to create a new 3.58
> version 
> for that?
> (This is the first time I have to do such thing, sorry.)

I guess we need a 3.57 upload, a non-source-only upload, which needs to
go through NEW to add those missing packages back. After that, a
source-only 3.58 upload is also needed. I can help sponsor packages if
you find that necessary.

BTW: Any possibility to have https://bugs.debian.org/944115 fixed as
well?

-- 
Thanks,
Boyuan Yang

Bug#945203: fwupd: Cannot update firmware

[Mario.Limonciello]

Nothing fwupd can do about this.  It's either efivarfs NV store is full on your 
box or BIOS is locking it down.

Bug#944116: tasksel: Please make another source-only upload

[Holger Wansing]

Hi,

Ansgar  wrote:
> We had an issue where old arch:all packages were detected as cruft when
> buildds had not built the new version yet (which should no longer happen
> thanks to Ivo De Decker's patch[1]), but here these are
> maintainer-provided packages :/
> 
> Maybe a race between dak accepting the package from NEW (so it's only
> half-installed) and a parallel process generating the cruft report based
> on that half-installed state? (If this is the case, then the patch from
> above should also help.)
> 
>   [1]: https://salsa.debian.org/ftp-team/dak/merge_requests/163
> 
> I don't have resources to look into this in more detail currently
> though. So I suggest to do an extra upload to NEW for now.

Does that mean I can do an extra upload for the 3.57 version (that version
which was rejected yesterday) or do I need to create a new 3.58 version 
for that?
(This is the first time I have to do such thing, sorry.)


Holger


-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#945119: mmdebstrap: Fail to mmdebstrap Jessie with systemd components (missing /dev/urandom)

[Johannes Schauer]

Hi,

Quoting Vincent Caron (2019-11-20 02:45:07)
> Thanks a lot for mmdebstrap, I use it to generate images for my Xen
> cluster, it's efficient and works like a charm.
> 
> I have a small bug when using it to generate Jessie images with systemd
> components, when systemd's postinst invokes 'systemd-machine-id-setup'
> and this one fails because it cannot find any /dev/urandom. Reproduce
> with :
> 
> ./mmdebstrap --mode=unshare --include systemd jessie jessie.tar.gz
> ...
> Setting up systemd (215-17+deb8u7) ...
> Failed to read /proc/cmdline. Ignoring: No such file or directory
> Failed to open /dev/urandom: Function not implemented
> dpkg: error processing package systemd (--install):
>  subprocess installed post-installation script returned error exit
> status 1
> 
> I've worked around this by adding a
> --setup-hook='systemd-machine-id-setup --root $1' which is quite a hack
> and works because my host has systemd.

yes, I can reproduce this behaviour. I never tested mmdebstrap with Jessie, so
I'm surprised that there are not more bugs. :)

The reason is simple: when installing the Essential:yes packages, mmdebstrap
does this without first mounting /proc and /sys or setting up /dev. This is not
a problem with stretch, buster, testing or unstable because none of those have
any packages in the Essential:yes set which requires this setup. In Jessie
though, the package "init" is Essential:yes and thus, systemd will get
installed and that one needs all this setup.

The solution is thus also simple: also run the initial installation of
Essential:yes packages with the proper setup of /proc, /sys and /dev. I tried
this locally and it doesn't seem to break any test in the testsuite.

> And then I encounter a last (related?) bug :
> 
> ./mmdebstrap --mode=unshare --setup-hook='systemd-machine-id-setup --
> root $1' --include systemd jessie jessie.tar.gz
> ...
> I: installing apt...
> done
> E: run_chroot failed: E: cannot make_path ./dev/pts/
> 
> It seems than around line 777 when creating type==5/directory it goes
> thru the havemknod==false path and fails. But if I bypass this block, it
> proceeds with bind-mouting /dev/pts which works, and I get my working
> tarball.

This is a good find, thank you! Mmdebstrap uses File::Path::make_path and then
throws an error if no path was created. In your case, ./dev/pts already
existed, so an error is wrongly emitted. Instead, the make_path call not error
out when the path already exists.

Thanks!

cheers, josch


signature.asc
Description: signature

Bug#942893: ftp.debian.org: please drop MD5sum lines from Packages

[Steve McIntyre]

And another update...

On Fri, Nov 15, 2019 at 05:23:41PM +, Steve McIntyre wrote:
>
>On Fri, Oct 25, 2019 at 05:01:07PM +0100, Steve McIntyre wrote:
>>
>>I'll take a look at that shortly. Working on the core jigdo tool first.
>
>I have new versions of jigdo and jigit just about ready to go. I've
>defined a new format v2 for jigdo, which uses SHA256 instead of MD%
>throughout. The tools to produce jigdo files will now allow the user
>to choose which format to create (defaulting to v1 *for now*), while
>the client tools will auto-detect and work with either format.
>
>I'm working on a website for the new jigdo binaries, ready with
>Windows builds of the tools as well. Richard (original author of
>jigdo) is happy with what I've done and will redirect users to my new
>stuff.
>
>I'm going to get that finished, then start publicising the new tools
>and the version switch. After a reasonable period I'll switch our
>production code to format v2.

 * I've released and uploaded jigdo 0.8.0 with support for format v2
   (mainly for end user clients). I'll upload backports of this as
   soon as possible, so I can get more people using it on (old)stable
   too. I've prepped and published the new website, complete with a
   set of Windows binaries for people to use.

 * I've released and uploaded jigit 1.22 (including libjte 2) with
   support for format v2. I've pushed a patch at Thomas so the next
   xorriso release should get this support.

 * I've just uploaded all the changes needed for debian-cd to use the
   new xorriso version and generate jigdo v2 format. It's still set to
   do v1 by default until we decide to switch

I'll want to do a quick audit of the backend bits and pieces in the
cdimage production and publishing next, but that's not urgent yet
until...

I'm going to make a big song and dance about these changes and the new
software releases on my blog, and on the CD areas of the Debian
website. We need to get users in the field updated so we can switch to
the new format. I *want* to give people plenty of warning before we
switch, starting with testing/bullseye images.

/me heads off for an evening of game playing... :-)

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"I suspect most samba developers are already technically insane... Of
 course, since many of them are Australians, you can't tell." -- Linus Torvalds

Bug#942086: xpdf: Memory leak on large document (even w/ continuousView turned off)

[Bernhard Übelacker]

Hello Jean-Paul,
this might be the same issue as in following bug, which
has some more information and a patch:

https://bugs.debian.org/945188

Kind regards,
Bernhard

Bug#926501: xpdf: continuousView memory leak

[Bernhard Übelacker]

Hello all,
this might be the same issue as in following bug, which
has some more information and a patch:

https://bugs.debian.org/945188

Kind regards,
Bernhard

Bug#872864: Checkout upstream signatures as well when using pristine-tar

[Guido Günther]

Hi,
On Thu, Nov 21, 2019 at 05:19:04PM +0100, Christian Göttsche wrote:
> Control: severity -1 important
> Control: tags -1 patch
> 
> Hi,
> 
> what about the following patch:

The existence of the signature in the pristine-tar branch needs to be
checked beforehand instead of trying, failing and then retrying without
it (also on/off/auto need to be handled). See the preparation that went
into 0.9.17 for that.
Cheers,
 -- Guido

> 
> --- /usr/lib/python3/dist-packages/gbp/deb/git.py   2019-10-31
> 16:07:04.0 +0100
> +++ /root/git.py2019-11-21 17:07:41.485223303 +0100
> @@ -320,7 +320,15 @@
>  output = source.upstream_tarball_name(comp.type, component=component)
>  try:
>  self.pristine_tar.checkout(source.name,
> source.upstream_version, comp.type, output_dir,
> -   component=component, quiet=True)
> +   component=component,
> quiet=True, signature=True)
> +except CommandExecFailed:
> +gbp.log.info("Failed to create '%s' with attached
> signature file. Retrying without..." % output)
> +
> +try:
> +self.pristine_tar.checkout(source.name,
> source.upstream_version, comp.type, output_dir,
> +   component=component, quiet=True)
> +except Exception as e:
> +raise GitRepositoryError("Error creating %s: %s" % (output, 
> e))
>  except Exception as e:
>  raise GitRepositoryError("Error creating %s: %s" % (output, e))
>  return True
> 

Bug#940312: /etc/issue: /etc/issue is being updated by Debian when it doesn't need to

[Ben Wong]

Hi, I know this is low-priority and everyone is busy on important matters,
but I was wondering if anybody had looked at this yet. The fix I included
is simple and easily verified. I'm hoping that it can be included in Debian
11 (Bullseye).

Thanks,

—Ben

Bug#945234: cupp: Renaming cupp3 to cupp breaks Debian Sid/Bullseye repository

[Eriberto Mota]

Hi Marcio,

Em qui., 21 de nov. de 2019 às 14:10, Marcio Souza
 escreveu:
>
> Em 21/11/2019 13:50, Joao Eriberto Mota Filho escreveu:
> > Source: cupp
> > Version: 0.0+20160624.git07f9b8-1
> > Severity: normal
> >
> > Dear maintainer,
> Hi Eriberto
>
> > After renaming cupp3 to cupp suddenly and without coordinate with other
> > maintainers, forensics-extra packages (and maybe others) was affected.
> > If it is a forced needed transition, please coordinate the action before
> > make it.
> Sorry for this, I should have coordinated it.
>
> > If you only need rename the package from now on because a light reason
> > as Python 2 removing, please follow these instructions[1]. IMO, this is
> > the solution for cupp. Note that you package will arrives to NEW queue.
> The cupp source package generated two binaries: cupp and cupp3, respectively
> the version for python2 and python3. The new upstream version of cupp
> [1] removed
> the python2 implementation, so the cupp3 lost its purpose, as we started
> having only the python3 version.
>
> So in debian release [2], I removed the cupp3 of cupp source package, I
> don't rename the package.

Sorry, I didn't make myself understood. In other words, is not
recommendable remove a package from Debian without coordinate it.
Considering that you removed cupp3 suddenly, the best way to fix it
without disrupt other packages/users is adopt the same procedure as
renaming a package (this procedure is also used to rename but it not
just to rename).

> Could you modify the dependencies of forensics-extra to use cupp package
> instead of cupp3? [3].

Sure, I will do it soon.

Regards,

Eriberto

Bug#944116: tasksel: Please make another source-only upload

[Ansgar]

Boyuan Yang writes:
> What I understand so far is that something went *really* wrong with the 3.56
> upload made by nicoo:

Yes, for some reason task-hebrew-desktop_3.56 and a few others were
removed as cruft:

+---
| Date: Tue, 29 Oct 2019 04:41:29 +
| Ftpmaster: Scott Kitterman
| Suite: unstable
| Binaries:
|  task-chinese-s_3.56 [all]
|  task-cyrillic-kde-desktop_3.56 [all]
|  task-hebrew-desktop_3.56 [all]
|  task-macedonian_3.56 [all]
|  task-slovenian-kde-desktop_3.56 [all]
| Reason: [auto-cruft] NBS (no longer built by tasksel)
+---[ https://ftp-master.debian.org/removals.822 ]

We had an issue where old arch:all packages were detected as cruft when
buildds had not built the new version yet (which should no longer happen
thanks to Ivo De Decker's patch[1]), but here these are
maintainer-provided packages :/

Maybe a race between dak accepting the package from NEW (so it's only
half-installed) and a parallel process generating the cruft report based
on that half-installed state? (If this is the case, then the patch from
above should also help.)

  [1]: https://salsa.debian.org/ftp-team/dak/merge_requests/163

I don't have resources to look into this in more detail currently
though. So I suggest to do an extra upload to NEW for now.

Ansgar

Bug#945188: xpdf: memory leak when changing page

[Bernhard Übelacker]

Control: tags -1 + patch


Dear Maintainer,
I tried to have a look and found something.

This issue might be in the package since poppler-0.71.patch.
This patch makes some changes how containers get accessed.

Following I found and tried to change in attached patch:
- std::erase, std::clear, std::remove:
  These methods of STL containers containing pointer to objects do
  not delete the objects pointed to.
- In continuousView in PDFCore::addPage the next page was inserted
  at the first position.

For running with valgrind it was nice to have the additional cflag
HAVE_XTAPPSETEXITFLAG set, as then the application cleans up
instead of just exit(0).

Bug #942086 and #926501 might be related.

Kind regards,
Bernhard

# Unstable amd64 qemu VM 2019-11-21

apt update
apt dist-upgrade


apt install dpkg-dev devscripts quilt systemd-coredump xserver-xorg lightdm 
openbox xterm htop mc gdb valgrind heaptrack heaptrack-gui pari-doc xpdf 
xpdf-dbgsym libfreetype6-dbgsym libpoppler82-dbgsym
apt build-dep xpdf



mkdir /home/benutzer/source/xpdf/orig -p
cd/home/benutzer/source/xpdf/orig
apt source xpdf
cd

mkdir /home/benutzer/source/libpoppler82/orig -p
cd/home/benutzer/source/libpoppler82/orig
apt source libpoppler82
cd




export LANG=C
export DISPLAY=:0

/usr/bin/xpdf.real /usr/share/pari/doc/users.pdf

# ~10 times next page and previous page - memory usage doubles.





##


# wget 
https://github.com/WuBingzheng/memleax/releases/download/v1.1.1/memleax_1.1.1-1_amd64.deb
# dpkg -i memleax_1.1.1-1_amd64.deb
# memleax $(pidof xpdf.real)
# gdb -q --args xpdf.real /usr/share/pari/doc/users.pdf
#   Reading symbols from 
/usr/lib/debug/.build-id/ab/a6d385be8071a6a44247a89331bee9f0494091.debug...
# memleax -d 
/usr/lib/debug/.build-id/ab/a6d385be8071a6a44247a89331bee9f0494091.debug 
$(pidof xpdf.real)
# Had no output at all.


##


script -a valgrind-xpdf.real_$(date +%Y-%m-%d_%H-%M-%S).txt -c 'valgrind 
/usr/bin/xpdf.real /usr/share/pari/doc/users.pdf'

script -a valgrind-xpdf.real_$(date +%Y-%m-%d_%H-%M-%S).txt -c 'valgrind 
--leak-check=full --show-reachable=yes --leak-resolution=high --num-callers=100 
--trace-children=yes /usr/bin/xpdf.real /usr/share/pari/doc/users.pdf'


==35071== 34,438,272 bytes in 11 blocks are possibly lost in loss record 1,608 
of 1,608
==35071==at 0x483577F: malloc (vg_replace_malloc.c:309)
==35071==by 0x11F82C: gmalloc (gmem.h:41)
==35071==by 0x11F82C: gmallocn (gmem.h:115)
==35071==by 0x11F82C: XPDFCore::updateTileData(PDFCoreTile*, int, int, int, 
int, bool) (XPDFCore.cc:1276)
==35071==by 0x119C5C: PDFCore::clippedRedrawRect(PDFCoreTile*, int, int, 
int, int, int, int, int, int, int, int, bool, bool) (PDFCore.cc:2171)
==35071==by 0x119D5F: PDFCore::redrawCbk(void*, int, int, int, int, bool) 
(PDFCore.cc:2068)
==35071==by 0x1166F5: dump (CoreOutputDev.cc:53)
==35071==by 0x1166F5: CoreOutputDev::dump() (CoreOutputDev.cc:46)
==35071==by 0x4E6016F: Gfx::go(bool) (Gfx.cc:827)
==35071==by 0x4E6049D: Gfx::display(Object*, bool) (Gfx.cc:714)
==35071==by 0x4EB6940: Page::displaySlice(OutputDev*, double, double, int, 
bool, bool, int, int, int, int, bool, bool (*)(void*), void*, bool (*)(Annot*, 
void*), void*, bool) (Page.cc:548)
==35071==by 0x11AD82: PDFCore::needTile(PDFCorePage*, int, int) 
(PDFCore.cc:924)
==35071==by 0x11BBB0: PDFCore::update(int, int, int, double, int, bool, 
bool, bool) (PDFCore.cc:724)
==35071==by 0x122380: XPDFCore::update(int, int, int, double, int, bool, 
bool, bool) (XPDFCore.cc:297)
==35071==by 0x11734E: gotoNextPage (PDFCore.cc:963)
==35071==by 0x11734E: PDFCore::gotoNextPage(int, bool) (PDFCore.cc:947)
==35071==by 0x1223E1: XPDFCore::gotoNextPage(int, bool) (XPDFCore.cc:325)
==35071==by 0x127937: XPDFViewer::nextPageCbk(_WidgetRec*, void*, void*) 
(XPDFViewer.cc:2451)
==35071==by 0x49361BA: ??? (in /usr/lib/x86_64-linux-gnu/libXm.so.4.0.4)
==35071==by 0x505F4DE: ??? (in /usr/lib/x86_64-linux-gnu/libXt.so.6.0.0)
==35071==by 0x5060552: _XtTranslateEvent (in 
/usr/lib/x86_64-linux-gnu/libXt.so.6.0.0)
==35071==by 0x5038479: XtDispatchEventToWidget (in 
/usr/lib/x86_64-linux-gnu/libXt.so.6.0.0)
==35071==by 0x5038ED1: ??? (in /usr/lib/x86_64-linux-gnu/libXt.so.6.0.0)
==35071==by 0x5039030: XtDispatchEvent (in 
/usr/lib/x86_64-linux-gnu/libXt.so.6.0.0)
==35071==by 0x5044CFF: XtAppProcessEvent (in 
/usr/lib/x86_64-linux-gnu/libXt.so.6.0.0)
==35071==by 0x503944C: XtAppMainLoop (in 
/usr/lib/x86_64-linux-gnu/libXt.so.6.0.0)
==35071==by 0x11626C: main (xpdf.cc:310)



gdb -q --args /usr/bin/xpdf.real /usr/share/pari/doc/users.pdf

set width 0
set pagination off
directory /home/benutzer/source/xpdf/orig/xpdf-3.04/xpdf
directory /home/benutzer/source/libpoppler82/orig/poppler-0.71.0
b CoreOutputDev::CoreOutputDev
y
run


###


try1:

debian/rules
HAVE_XTAPPSETEXITFLAG 
--> XPDFApp::~XPDFApp get now reached

xpdf/XPDFApp.cc
void 

Bug#945245: Powertop v.2.8-1 + b2

[pham...@bluewin.ch]

Package: powertop 
Version: v.2.8-1 + b2
Bug Description :
Unbearable whistling in headphones plugged into 3,5 mm audio jack port during 
the absence of broadcast (music/movie ended, paused, etc.)
My Dell XPS 9570 with the kernel  4.19.0-6-amd64 (LTS) are impacted by this bug 
;(
I have to use headphones the night for 3-4 hours to make no noise, it hurts my 
ears and this situation starts very seriously to exasperate me.
When I uninstalled powertop v.2.8-1 + b2 from Debian 10 all work fine... except 
the autonomy of my laptop ;(
!!! Powertop are installed automatically on all laptops powered by Debian !!! 
=> Many other users must also have this very unpleasant bug <=
Bug declared as coming from the kernel before good diagnosis :
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=939545
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=939545#33
The current version of powertop is 2.11 :
https://01.org/powertop/
Your versions of powertop is v.2.8-1 + b2 in Buster and 2.10-1+b1 in SID : 
https://packages.debian.org/search?keywords=powertop
If you need help for more details or tests feel free to send me an e-mail.
I dare to hope for a quick/urgent fix from you.
Best regards.
Philippe

Bug#873677: porterboxes are off?

[Anton Gladky]

Hello,

I wanted to try to fix this bug, but it looks like the both
porterboxes (lemon.d.n and exodar.d.n) are off.

Is there an opportunity to get an access on hurd or kfreebsd machine?

Regards

Anton

Bug#945244: r-cran-sf: upstream regression, unaligned access on armhf

[Steve Langasek]

Source: r-cran-sf
Version: 0.8-0+dfsg-1
Severity: serious
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu focal

Hi Andreas,

With the upload of r-cran-sf 0.8-0+dfsg-1, the autopkgtests are failing in
Ubuntu only on armhf due to a regression in alignment handling:

[...]
Attribute-geometry relationship: 0 constant, 1 aggregate, 1 identity
geometry type:  MULTIPOLYGON
dimension:  XY
bbox:   xmin: 0 ymin: 0 xmax: 1 ymax: 1
epsg (SRID):NA
proj4string:NA
  Group.1   a   geometry
1   1 1.5 MULTIPOLYGON (((0 0, 1 0, 1...
> (a = aggregate(s, list(c(1,1)), mean, do_union = TRUE))
Bus error (core dumped)
autopkgtest [11:32:17]: test run-unit-test: ---]
[...]

  
(https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/armhf/r/r-cran-sf/20191109_113707_4303b@/log.gz)

Since Debian only runs autopkgtests on amd64, this did not block migration
of the new version of the package to Debian testing; nevertheless this is a
serious failure of the package on armhf.  I have grabbed a backtrace which
points to a problem in r-cran-sf itself, not in any of its dependencies:

Program received signal SIGBUS, Bus error.
0xf47431cc in wkb_read (wkb=, wkb=)
at wkb.cpp:201
201 double d = wkb_read(wkb);
(gdb) bt
#0  0xf47431cc in wkb_read (wkb=, wkb=)
at wkb.cpp:201
#1  read_numeric_matrix (wkb=wkb@entry=0xfffe7ddc, n_dims=n_dims@entry=2, 
swap=swap@entry=false, cls=..., empty=empty@entry=0x0) at wkb.cpp:201
#2  0xf47434b0 in read_matrix_list (wkb=wkb@entry=0xfffe7ddc, 
n_dims=n_dims@entry=2, swap=swap@entry=false, cls=..., 
empty=empty@entry=0xfffe7d27) at /usr/include/c++/9/ext/new_allocator.h:89
#3  0xf474430c in read_data (wkb=wkb@entry=0xfffe7ddc, EWKB=EWKB@entry=true, 
spatialite=spatialite@entry=false, endian=endian@entry=1, 
addclass=addclass@entry=true, type=type@entry=0xfffe7dd4, 
srid=srid@entry=0xfffe7dd8)
at /usr/lib/R/site-library/Rcpp/include/Rcpp/vector/generic_proxy.h:37
#4  0xf474590a in CPL_read_wkb (wkb_list=..., EWKB=EWKB@entry=true, 
spatialite=spatialite@entry=false)
at /usr/lib/R/site-library/Rcpp/include/Rcpp/vector/generic_proxy.h:37
#5  0xf472d5da in sfc_from_geometry(GEOSContextHandle_HS*, 
std::vector >, 
std::allocator > 
> >&, int, bool) (
hGEOSCtxt=hGEOSCtxt@entry=0x2154c48, 
geom=std::vector of length 1, capacity 1 = {...}, dim=, 
free=free@entry=true)
at /usr/lib/R/site-library/Rcpp/include/Rcpp/vector/traits.h:65
#6  0xf472f542 in CPL_geos_union (sfc=..., by_feature=)
at geos.cpp:600
#7  0xf47100d8 in _sf_CPL_geos_union (sfcSEXP=0x1f0d988, 
by_featureSEXP=0x419568)
at /usr/lib/R/site-library/Rcpp/include/Rcpp/as.h:151
#8  0xf7ce238c in ?? () from /usr/lib/R/lib/libR.so
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb)

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature

Bug#944603: Attempt to print checks crashes gnucash

[local10]

More info:

# cat /tmp/gnucash.trace
* 08:19:37  CRIT  free_check_format: assertion 'data' 
failed

Bug#945072: qemu 4.1 block size regression

[Jamie Heilman]

Michael Tokarev wrote:
> 21.11.2019 12:59, Jamie Heilman wrote:
> []
> >> Oh. That means the broken part is the part which did the conversion,
> >> that is qemu-img, which is part of qemu-utils.
> > 
> > Well that's not what my testing shows; after testing through various
> > different approaches, anytime I build an image with qemu-system-x86
> > 4.1 I wind up with corruption, the version of qemu-utils tools used at
> > any stage doesn't seem to matter.  Using qemu-system-x86 3.1 with any
> > version of qemu-utils tools works OK.
> 
> Interesting. What host filesystem it is, where your initial image is
> created on? Is it xfs by any chance?

yeah xfs
 
> []
> > qemu-img check never reports any problems in any combination.
> 
> Ok, so it's guest data corruption issue.
> 
> Would you be willing to run a version of qemu-system-x86_64 I'll
> build for you? I can sign it with the same pgp key I use to sign
> my debian package if that's okay with you.

sure

-- 
Jamie Heilman http://audible.transient.net/~jamie/

Bug#945243: libpsl FTBFS: ../libpsl-docs.sgml:27: element include: XInclude error : could not load ../xml/tree_index.sgml, and no fallback was found

[Helmut Grohne]

Source: libpsl
Version: 0.20.2-2
Severity: serious
Tags: ftbfs
User: helm...@debian.org
Usertags: rebootstrap

libpsl recently (within the last seven days) started to FTBFS in
unstable:

https://tests.reproducible-builds.org/debian/rbuild/unstable/amd64/libpsl_0.20.2-2.rbuild.log.gz
| gtkdoc-mkdb --module=libpsl --output-format=xml --expand-content-files="" 
--main-sgml-file=libpsl-docs.sgml ${_source_dir} --xml-mode --output-format=xml
| ./libpsl-unused.txt:1: warning: 1 unused declarations. They should be added 
to libpsl-sections.txt in the appropriate place.
| touch sgml-build.stamp
| rm -rf html && mkdir html && \
| mkhtml_options=""; \
| gtkdoc-mkhtml 2>&1 --help | grep  >/dev/null "\-\-verbose"; \
| if test "$?" = "0"; then \
|   if test "x" = "x1"; then \
| mkhtml_options="$mkhtml_options --verbose"; \
|   fi; \
| fi; \
| gtkdoc-mkhtml 2>&1 --help | grep  >/dev/null "\-\-path"; \
| if test "$?" = "0"; then \
|   mkhtml_options="$mkhtml_options 
--path=\"/build/1st/libpsl-0.20.2/docs/libpsl\""; \
| fi; \
| cd html && gtkdoc-mkhtml $mkhtml_options  libpsl ../libpsl-docs.sgml
| warning: failed to load external entity "../xml/tree_index.sgml"
| ../libpsl-docs.sgml:27: element include: XInclude error : could not load 
../xml/tree_index.sgml, and no fallback was found
| make[3]: *** [Makefile:874: html-build.stamp] Error 6
| make[3]: Leaving directory '/build/1st/libpsl-0.20.2/docs/libpsl'
| make[2]: *** [Makefile:535: all-recursive] Error 1
| make[2]: Leaving directory '/build/1st/libpsl-0.20.2'
| make[1]: *** [Makefile:444: all] Error 2
| make[1]: Leaving directory '/build/1st/libpsl-0.20.2'
| dh_auto_build: make -j16 returned exit code 2
| make: *** [debian/rules:6: binary] Error 255
| dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 
2

Also seen by crossqa, but crossqa also has a successful build from 7
days ago.
http://crossqa.debian.net/build/libpsl_0.20.2-2_s390x_20191121183814.log

This breaks bootstrap qa (among other things).

Helmut

Bug#939545: Debian 10 Buster - Sound on 3.5 jack audio problem with Kernel v 4.19.0-5-amd64 (LTS)

[pham...@bluewin.ch]

Hello,
The origin of the problem was discovered.
This is a bug of powertop v.2.8-1 + b2.
By uninstalling software everything works except the energy saving of the 
battery of my laptop ;(
It's possible for you to make a urgent report for a urgent upgrade from 
powertop to the members Debian and Intel Team's development ??
The current version is 2.11 :
https://01.org/powertop/
And your versions is 2.10 on SID : 
https://packages.debian.org/search?keywords=powertop
If you need help for more details or tests feel free to send me an e-mail.
I dare to hope for a quick fix from you.
Best regards.
Philippe

Bug#945236: mirror submission for mirror.infomaniak.com

[Thomas Goirand]

As per discussion on IRC, to avoid a race condition, please split this into:

mirror1.infomaniak.com
mirror2.infomaniak.com

FYI, mirror2 recieves a push from mirror1.

Thomas Goirand (zigo)

Bug#945162: Build fails on some (Ubuntu) builders due to lack of memory

[Kristian Nielsen]

Sebastien Bacher  writes:

> because it uses more memory than available. The attached patch makes it
> build with --no-parallel which workarounds the issue, what would you

Hm, this seems to be the wrong place to put this?

If a build machine has too little memory for a --parallel build of a
package, that is a property of the build machine, not of the package. So
better if the individual build machine sets DEB_BUILD_OPTIONS=parallel=1 or
similar. IIUC, this is how it is done in the Debian build infrastructure.

(A refinement could be if the build machine could set DEB_LOW_MEM_BUILDER or
something that could conditionally disable parallel build on heavy packages.
Such mechanism should be general across packages (not specific to openscad),
not sure if something like that is available).

The patch penalises _every_ build which is bad - building with -jN makes a
huge difference in compile time for openscad, and should work fine on
modern-sized machines.

Also, IIUC, the patch would disable parallel not just for the build but also
for the test run? That would again be bad, the testsuite also benefits
hugely from parallel build, and I do not think parallel test suite requires
a lot of memory.

 - Kristian.

Bug#944116: tasksel: Please make another source-only upload

[Boyuan Yang]

Hi,

在 2019-11-21四的 19:37 +0100，Holger Wansing写道：
> Hmm, my upload was rejected:
> 
> 
> Debian FTP Masters  wrote:
> > ACL dm: NEW uploads are not allowed
> > 
> > binary:task-chinese-s is NEW.
> > binary:task-cyrillic-kde-desktop is NEW.
> > binary:task-hebrew-desktop is NEW.
> > binary:task-macedonian is NEW.
> > binary:task-slovenian-kde-desktop is NEW.
> 
> However, my upload does not contain new binaries.
> And the above mentioned binaries are in the package for a long time...
> 
> I failed to see what I did wrong...

Well.

What I understand so far is that something went *really* wrong with the 3.56
upload made by nicoo:

-> % rmadison task-chinese-s
task-chinese-s | 3.31+deb8u1   | oldoldstable | all
task-chinese-s | 3.39  | oldstable| all
task-chinese-s | 3.53  | stable   | all
task-chinese-s | 3.55  | testing  | all

-> % rmadison task-macedonian
task-macedonian | 3.31+deb8u1   | oldoldstable | all
task-macedonian | 3.39  | oldstable| all
task-macedonian | 3.53  | stable   | all
task-macedonian | 3.55  | testing  | all

-> % rmadison task-hebrew-desktop
task-hebrew-desktop | 3.31+deb8u1   | oldoldstable | all
task-hebrew-desktop | 3.39  | oldstable| all
task-hebrew-desktop | 3.53  | stable   | all
task-hebrew-desktop | 3.55  | testing  | all

It is a non-source-only upload with all packages of arch:all so tasksel will
*not* be built on buildds at all.  Could it be that those missing packages are
not provided in that upload so those package actually are treated as if there
were removed from Sid? In that case, a new source-only upload will have to go
throught NEW.

-- 
Thanks,
Boyuan Yang

Bug#943527: [Pkg-mozext-maintainers] Bug#943527: umatrix unusable

[Ximin Luo]

Julien Aubin:
> Hi,
> 
> Same symptoms and same fix observed on my box.
> 

Do you guys have the same problem with firefox (not esr) version 69 or 70? 
Umatrix is working fine for me with those versions, after applying the 
workaround from #919557.

X

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

Bug#945242: libfile-rsyncp-perl misses source for FileList/configure

[Helmut Grohne]

Source: libfile-rsyncp-perl
Version: 0.74-2.1
Severity: serious
Justification: DFSG #2
Tags: upstream
File: FileList/configure

While trying to fix a problem with libfile-rsyncp-perl, I was looking
for the source of FileList/configure, but I couldn't find it anyhwere.
FileList/configure says that it is generated by autoconf/2.59.

Helmut

Bug#944116: tasksel: Please make another source-only upload

[Holger Wansing]

Hi,

Holger Wansing  wrote:
> Boyuan Yang  wrote:
> > Source: tasksel
> > Severity: important
> > X-Debbugs-CC: ni...@debian.org
> > Version: 3.56
> > 
> > Dear tasksel maintainers,
> > 
> > The last upload for tasksel was not a source-only upload. As a result, this
> > version of tasksel will never migrate to Debian Testing. Please consider
> > making another source-only upload. More information about source-only upload
> > can be found at https://wiki.debian.org/SourceOnlyUpload .
> 
> Just uploaded 3.57 'source-only'.
> So closing this report.

Hmm, my upload was rejected:


Debian FTP Masters  wrote:
> ACL dm: NEW uploads are not allowed
> 
> binary:task-chinese-s is NEW.
> binary:task-cyrillic-kde-desktop is NEW.
> binary:task-hebrew-desktop is NEW.
> binary:task-macedonian is NEW.
> binary:task-slovenian-kde-desktop is NEW.

However, my upload does not contain new binaries.
And the above mentioned binaries are in the package for a long time...

I failed to see what I did wrong...

Holger



-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#765899: [pkg-php-pear] Bug#765899: Bug#765899: Composer: Please, support OR-ed versions

[Thorsten Glaser]

David Prévot dixit:

>> Just fix the packaging tools, it can’t be *that* hard.
>
>If you say so. I’m impatient to see your fix part of the next version.

… as long as I don’t become the new maintainer because I happen to
be the last person to submit a patch… (had this happen to me multiple
times in Debian already).

bye,
//mirabilos
-- 
Thorsten Glaser (Founding Member)
Teckids e.V. — Digital freedom with youth and education
https://www.teckids.org/

Bug#817157: recoll: index corruption in version 1.17.3-2

[Nathaniel Morck Foley-Beaver]

On 11/8/19, Jean-Francois Dockes wrote:

I think that this was an old Xapian issue, and that it can be closed.

jf


I agree, this should be closed.

Nathaniel

On 11/8/19 12:08 AM, Kartik Mistry wrote:

Package: recoll

Hi,

Is this still happening with latest recoll and xapian (Since #808610
is done long time ago!)?

Thanks!



I have not observed this behavior in more recent versions.

Nathaniel

Bug#945241: ITP: libbio-db-hts-perl -- Perl interface to the HTS library

[Andreas Tille]

Package: wnpp
Severity: wishlist

Subject: ITP: libbio-db-hts-perl -- Perl interface to the HTS library
Package: wnpp
Owner: Andreas Tille 
Severity: wishlist

* Package name: libbio-db-hts-perl
  Version : 3.01
  Upstream Author : EMBL-European Bioinformatics Institute
* URL : https://metacpan.org/release/Bio-DB-HTS
* License : Apache-2.0
  Programming Lang: C
  Description : Perl interface to the HTS library
 HTSlib is an implementation of a unified C library for accessing common file
 formats, such as SAM (Sequence Alignment/Map), CRAM and VCF (Variant Call
 Format), used for high-throughput sequencing data, and is the core library
 used by samtools and bcftools. HTSlib only depends on zlib. It is known to be
 compatible with gcc, g++ and clang.
 .
 HTSlib implements a generalized BAM (binary SAM) index, with file extension
 'csi' (coordinate-sorted index). The HTSlib file reader first looks for the
 new index and then for the old if the new index is absent.
 .
 This package provides a Perl interface to the HTS library.

Remark: This package is maintained by Debian Med Packaging Team at
   https://salsa.debian.org/med-team/libbio-db-hts-perl

Bug#945234: cupp: Renaming cupp3 to cupp breaks Debian Sid/Bullseye repository

[Marcio Souza]

Em 21/11/2019 13:50, Joao Eriberto Mota Filho escreveu:

Source: cupp
Version: 0.0+20160624.git07f9b8-1
Severity: normal

Dear maintainer,

Hi Eriberto


After renaming cupp3 to cupp suddenly and without coordinate with other
maintainers, forensics-extra packages (and maybe others) was affected.
If it is a forced needed transition, please coordinate the action before
make it.

Sorry for this, I should have coordinated it.


If you only need rename the package from now on because a light reason
as Python 2 removing, please follow these instructions[1]. IMO, this is
the solution for cupp. Note that you package will arrives to NEW queue.

The cupp source package generated two binaries: cupp and cupp3, respectively
the version for python2 and python3. The new upstream version of cupp 
[1] removed
the python2 implementation, so the cupp3 lost its purpose, as we started 
having only the python3 version.


So in debian release [2], I removed the cupp3 of cupp source package, I 
don't rename the package.


Could you modify the dependencies of forensics-extra to use cupp package 
instead of cupp3? [3].


[1] - 
https://github.com/Mebus/cupp/commit/986658dd3e2f125d04f7ab4f806c0222ce161823
[2] - 
https://salsa.debian.org/debian/cupp/-/tags/debian%2F0.0+20190501.git986658-1

[3] - Attached file fix_cupp_depends.patch

Regards,

Marcio Souza
Description: Fixes the cupp3 dependency
Author: Marcio de Souza Oliveira 
Last-Update: 2019-11-21
Index: debian/control
===
--- debian.orig/control
+++ debian/control
@@ -36,7 +36,7 @@ Depends: bfbtester,
  comprez,
  crunch,
  cryptmount,
- cupp3,
+ cupp,
  curl,
  dact,
  dares,
@@ -177,7 +177,6 @@ Depends: bfbtester,
  xz-utils,
  zpaq,
  ${misc:Depends}
-Breaks: cupp (>= 0.0)
 Description: Forensics Environment - extra console components (metapackage)
  This package provides the extra components for a forensics environment. All
  here available tools are text console based. None of these tools were packaged
@@ -201,7 +200,7 @@ Description: Forensics Environment - ext
  The following packages were included in this metapackage:
  .
bfbtester, binutils, brotli, bruteforce-luks, bzip2, cabextract,
-   chntpw, clzip, comprez, crunch, cryptmount, cupp3, curl, dact,
+   chntpw, clzip, comprez, crunch, cryptmount, cupp, curl, dact,
dares, dcfldd, ddrutility, dhcpdump, dictconv, diffstat, disktype,
dmitry, dnsutils, dtach, ethstatus, ethtool, ewf-tools, exfat-fuse,
exfat-utils, exif, exiftags, exiv2, fatcat, fdupes, flasm, foremost,

Bug#943695: didjvu: FTBFS: ERROR: tests.test_timestamp.test_timezones

[Jakub Wilk]

* Santiago Vila , 2019-11-21, 13:55:

you seem to be the upstream author,


Indeed.


would you consider adopting it?


No. Sorry!

--
Jakub Wilk

Bug#945049: gnutls: Please prefer PFS ciphers over plain RSA ones.

[Sebastian Andrzej Siewior]

control: forwarded -1 https://gitlab.com/gnutls/gnutls/issues/862

On 2019-11-19 19:46:07 [+0100], Andreas Metzler wrote:
> On 2019-11-18 Sebastian Andrzej Siewior  wrote:
> [request for changing cipher list]
> 
> Could you please take this upstream? This is not a point where Debian
> will choose different defaults than upstream.

done.

> Thanks, cu Andreas

Sebastian

Bug#945202: [Python-modules-team] Bug#945202: pytest-pylint: FTBFS in sid

[Sandro Tosi]

> INTERNALERROR> Traceback (most recent call last):
> INTERNALERROR>   File "/usr/lib/python3/dist-packages/_pytest/main.py", line 
> 206, in wrap_session
> INTERNALERROR> session.exitstatus = doit(config, session) or 0
> INTERNALERROR>   File "/usr/lib/python3/dist-packages/_pytest/main.py", line 
> 249, in _main
> INTERNALERROR> config.hook.pytest_collection(session=session)
> INTERNALERROR>   File "/usr/lib/python3/dist-packages/pluggy/hooks.py", line 
> 286, in __call__
> INTERNALERROR> return self._hookexec(self, self.get_hookimpls(), kwargs)
> INTERNALERROR>   File "/usr/lib/python3/dist-packages/pluggy/manager.py", 
> line 92, in _hookexec
> INTERNALERROR> return self._inner_hookexec(hook, methods, kwargs)
> INTERNALERROR>   File "/usr/lib/python3/dist-packages/pluggy/manager.py", 
> line 83, in 
> INTERNALERROR> self._inner_hookexec = lambda hook, methods, kwargs: 
> hook.multicall(
> INTERNALERROR>   File "/usr/lib/python3/dist-packages/pluggy/callers.py", 
> line 208, in _multicall
> INTERNALERROR> return outcome.get_result()
> INTERNALERROR>   File "/usr/lib/python3/dist-packages/pluggy/callers.py", 
> line 80, in get_result
> INTERNALERROR> raise ex[1].with_traceback(ex[2])
> INTERNALERROR>   File "/usr/lib/python3/dist-packages/pluggy/callers.py", 
> line 187, in _multicall
> INTERNALERROR> res = hook_impl.function(*args)
> INTERNALERROR>   File "/usr/lib/python3/dist-packages/_pytest/main.py", line 
> 259, in pytest_collection
> INTERNALERROR> return session.perform_collect()
> INTERNALERROR>   File "/usr/lib/python3/dist-packages/_pytest/main.py", line 
> 501, in perform_collect
> INTERNALERROR> hook.pytest_collection_finish(session=self)
> INTERNALERROR>   File "/usr/lib/python3/dist-packages/pluggy/hooks.py", line 
> 286, in __call__
> INTERNALERROR> return self._hookexec(self, self.get_hookimpls(), kwargs)
> INTERNALERROR>   File "/usr/lib/python3/dist-packages/pluggy/manager.py", 
> line 92, in _hookexec
> INTERNALERROR> return self._inner_hookexec(hook, methods, kwargs)
> INTERNALERROR>   File "/usr/lib/python3/dist-packages/pluggy/manager.py", 
> line 83, in 
> INTERNALERROR> self._inner_hookexec = lambda hook, methods, kwargs: 
> hook.multicall(
> INTERNALERROR>   File "/usr/lib/python3/dist-packages/pluggy/callers.py", 
> line 208, in _multicall
> INTERNALERROR> return outcome.get_result()
> INTERNALERROR>   File "/usr/lib/python3/dist-packages/pluggy/callers.py", 
> line 80, in get_result
> INTERNALERROR> raise ex[1].with_traceback(ex[2])
> INTERNALERROR>   File "/usr/lib/python3/dist-packages/pluggy/callers.py", 
> line 187, in _multicall
> INTERNALERROR> res = hook_impl.function(*args)
> INTERNALERROR>   File "/build/pytest-pylint-0.14.1/pytest_pylint.py", line 
> 236, in pytest_collection_finish
> INTERNALERROR> result = lint.Run(args_list, reporter=reporter, 
> do_exit=False)
> INTERNALERROR>   File "/usr/lib/python3/dist-packages/pylint/lint.py", line 
> 1608, in __init__
> INTERNALERROR> linter.check(args)
> INTERNALERROR>   File "/usr/lib/python3/dist-packages/pylint/lint.py", line 
> 938, in check
> INTERNALERROR> self._do_check(files_or_modules)
> INTERNALERROR>   File "/usr/lib/python3/dist-packages/pylint/lint.py", line 
> 1071, in _do_check
> INTERNALERROR> self.check_astroid_module(ast_node, walker, rawcheckers, 
> tokencheckers)
> INTERNALERROR>   File "/usr/lib/python3/dist-packages/pylint/lint.py", line 
> 1154, in check_astroid_module
> INTERNALERROR> walker.walk(ast_node)
> INTERNALERROR>   File "/usr/lib/python3/dist-packages/pylint/utils.py", line 
> 1269, in walk
> INTERNALERROR> self.walk(child)
> INTERNALERROR>   File "/usr/lib/python3/dist-packages/pylint/utils.py", line 
> 1266, in walk
> INTERNALERROR> cb(astroid)
> INTERNALERROR>   File 
> "/usr/lib/python3/dist-packages/pylint/checkers/variables.py", line 1582, in 
> visit_import
> INTERNALERROR> module = next(node.infer_name_module(parts[0]))
> INTERNALERROR> AttributeError: 'Import' object has no attribute 
> 'infer_name_module'

this is pylint fault: i've uploaded astroid in preparation to upgrade
pylint too (old pylint is incompatibile with new astroid), but the
last step was delayed -- i'm working on it right now hopefully it will
hit the archive in a few hours

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

Bug#945240: evolution: HTML messages become unreadable after changing theme

[Ben Hutchings]

Package: evolution
Version: 3.30.5-1.1
Severity: important

I recently changed GNOME's theme from Adwaita to Adwaita-dark.  This
changed Evolution's default text colour for HTML display from black to
white, but the background colour remains white.  (The default colours
in the composer appear to be unchanged.)

If a received HTML message sets background and text colours, it
displays properly, but if it does not (which seems to be the default
behaviour of Thunderbird) then it is unreadable in Evolution.  (A
temporary workaround is to select all text.)

The same problem affects HighContrast and HighContrastInverse
themes, so this is an accessibility issue.

Ben.

-- System Information:
Debian Release: 10.1
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'stable-updates'), (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armhf, arm64

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

Versions of packages evolution depends on:
ii  dbus   1.12.16-1
ii  evolution-common   3.30.5-1.1
ii  evolution-data-server  3.30.5-1
ii  libc6  2.28-10
ii  libcamel-1.2-623.30.5-1
ii  libclutter-gtk-1.0-0   1.8.4-4
ii  libecal-1.2-19 3.30.5-1
ii  libedataserver-1.2-23  3.30.5-1
ii  libevolution   3.30.5-1.1
ii  libglib2.0-0   2.58.3-2+deb10u1
ii  libgtk-3-0 3.24.5-1
ii  libical3   3.0.4-3
ii  libnotify4 0.7.7-4
ii  libsoup2.4-1   2.64.2-2
ii  libwebkit2gtk-4.0-37   2.26.2-1~deb10+1
ii  libxml22.9.4+dfsg1-7+b3
ii  psmisc 23.2-1

Versions of packages evolution recommends:
ii  evolution-plugin-bogofilter  3.30.5-1.1
ii  evolution-plugin-pstimport   3.30.5-1.1
ii  evolution-plugins3.30.5-1.1
ii  yelp 3.31.90-1

Versions of packages evolution suggests:
ii  evolution-ews   3.30.5-1
pn  evolution-plugins-experimental  
ii  gnupg   2.2.12-1+deb10u1
ii  network-manager 1.14.6-2

-- debconf information:
  evolution/needs_shutdown:
  evolution/kill_processes:

-- 
Ben Hutchings, Software Developer Codethink Ltd
https://www.codethink.co.uk/ Dale House, 35 Dale Street
 Manchester, M1 2HF, United Kingdom

Bug#945237: libwebkit2gtk-4.0-37: AAC streams stop after 1:42

[Alberto Garcia]

Control: forwarded -1 https://bugs.webkit.org/show_bug.cgi?id=203194

On Thu, Nov 21, 2019 at 05:13:59PM +0100, Richard Lucassen wrote:
> Open the this stream using "surf":
> 
> surf http://tmp.xaq.nl/test-aac.html
> 
> After 1 minute and 42 seconds the stream starts to hic and stops
> completely after a few seconds. Tested on 3 Bullseye amd64 machines.

Reproduced, thanks! The bug is known and has been reported upstream.

Berto

Bug#945239: setup-storage: preserve_always is ignored

[Jens Schmidt]

Package: fai-setup-storage
Version: 5.8.9
Severity: important

Dear Maintainer,

consider the following disk config:

disk_config disk1 disklabel:gpt bootable:1 fstabkey:uuid align-at:4k 
preserve_always:4

primary /boot/efi 512vfat  rw
primary swap  1G swap  sw
primary - 32G- -
primary /home 32G-   btrfs subvol=@home,defaults,rw,relatime,compress,nodev

disk_config btrfs fstabkey:uuid
btrfs single   /disk1.3 
subvol=@buster,defaults,rw,relatime,compress
btrfs single   /var/cache   disk1.3 
subvol=@buster-var-cahce,defaults,rw,relatime,compress


When installing the releevant part of the log is this:

Calling task_partition
Starting setup-storage 2.2
Using config file: /var/lib/fai/config/disk_config/DISK_DESKTOP_GEN2T
/dev/nvme0n1p4 will be preserved
Adding mkfs command for '/dev/nvme0n1p3'.
Adding mkfs command for '/dev/nvme0n1p4'.
Executing: wipefs -af /dev/nvme0n1p1
Executing: wipefs -af /dev/nvme0n1p2
Executing: wipefs -af /dev/nvme0n1p3
Executing: parted -s /dev/nvme0n1 mklabel gpt
Executing: parted -s /dev/nvme0n1 mkpart primary "fat32" 1048576B 537919487B
Executing: parted -s /dev/nvme0n1 set 1 boot on
Executing: parted -s /dev/nvme0n1 mkpart primary "linux-swap" 537919488B 
1611661311B
Executing: parted -s /dev/nvme0n1 mkpart primary "" 1611661312B 35971399679B
Executing: parted -s /dev/nvme0n1 mkpart primary "btrfs" 35971399680B 
512110170111B
Executing: mkfs.vfat  /dev/nvme0n1p1
Executing: mkswap  /dev/nvme0n1p2
Executing: mkfs.btrfs -d single  -f /dev/nvme0n1p3
Executing: mount /dev/nvme0n1p3 /mnt
Executing: btrfs subvolume create   /mnt/@buster-var-cahce
Executing: umount /dev/nvme0n1p3
Executing: mkfs.btrfs -d single  -f /dev/nvme0n1p4
Executing: mount /dev/nvme0n1p4 /mnt
Executing: btrfs subvolume create   /mnt/@home
Executing: umount /dev/nvme0n1p4
Executing: mount /dev/nvme0n1p3 /mnt
Executing: btrfs subvolume create   /mnt/@buster
Executing: umount /dev/nvme0n1p3
Executing: parted /dev/nvme0n1 set 1 boot on
/dev/nvme0n1p3 UUID=b9e3ce83-aed9-4d3b-95eb-e86e2ab59d8a
/dev/nvme0n1p4 UUID=299d92a3-5d95-49e6-b18d-b73f2e4cc9ab
/dev/nvme0n1p3 UUID=b9e3ce83-aed9-4d3b-95eb-e86e2ab59d8a
/dev/nvme0n1p1 UUID=D380-1F2F
/dev/nvme0n1p2 UUID=ffcd663e-26a5-456c-86a0-61ce08a98f0a


As you can see wipefs honors the preserve_always, however the subsequent
mkfs calls do not, and the partition is recreated.

This appears to be a bug.

Cheers Jens



-- System Information:
Debian Release: 10.1
  APT prefers stable
  APT policy: (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 /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages fai-setup-storage depends on:
ii  e2fsprogs 1.44.5-1+deb10u2
pn  liblinux-lvm-perl 
pn  libparse-recdescent-perl  
ii  parted3.2-25
ii  perl  5.28.1-6

Versions of packages fai-setup-storage recommends:
ii  lvm2   2.03.02-3
pn  mdadm  

Versions of packages fai-setup-storage suggests:
pn  cryptsetup 
ii  dmsetup2:1.02.155-3
pn  dosfstools 
pn  jfsutils   
pn  ntfs-3g
pn  reiserfsprogs  
pn  xfsprogs   

Bug#874839: Bug#933019: Adjust for GlusterFS API change

[Jakob Haufe]

Control: tags + pending

I will prepare an NMU fixing this and #874839 and will upload it to
DELAYED/5.

-- 
ceterum censeo microsoftem esse delendam


pgpSsA9YZ6u5j.pgp
Description: OpenPGP digital signature

Bug#945238: gpsd: FTBFS with Python 3.8

[Graham Inggs]

Source: gpsd
Version: 3.19-2
Severity: serious
Tags: ftbfs

Hi Maintainer

A recent rebuild of gpsd with Python 3.8 failed [1].

I've copied what is hopefully the relevant part of the log below.

Regards
Graham

[1] https://buildd.debian.org/status/package.php?p=gpsd


Altered configuration variables:
nmea2000 = False (default True): NMEA2000/CAN support
rtcm104v2 = False (default True): rtcm104v2 support
pps = False (default True): PPS time syncing support
dbus_export = False (default True): enable DBUS export support
bluez = False (default True): BlueZ support for Bluetooth devices
libgpsmm = False (default True): build C++ bindings
qt = False (default True): build QT bindings
magic_hat = False (default True): special Linux PPS hack for Raspberry Pi et al
nostrip = True (default False): don't symbol-strip binaries at link time
gpsd_user = gpsd (default nobody): privilege revocation user
prefix = /usr (default /usr/local): installation directory prefix
qt_versioned = 5 (default ): version for versioned Qt
target_python = python3.7 (default python): target Python version as command
docdir = /usr/share/doc/gpsd (default share/doc): documents directory
libdir = /usr/lib/x86_64-linux-gnu (default lib): system libraries
RTCM2 regression tests suppressed because rtcm104v2 is off.
Part of the website build requires asciidoc, not installed.
scons: done reading SConscript files.
scons: Building targets ...
scons: *** [ais_json.os] ValueError : unsupported pickle protocol: 5
scons: building terminated because of errors.

Bug#945130: mingw-w64-x86-64-dev: strftime fails on %e and gives incorrect string for %z

[Bernhard Übelacker]

Am 21.11.19 um 16:13 schrieb Marius Mikučionis:
> 2019-11-21, th, 13:14 Bernhard Übelacker  > wrote:
> 
> 
> I forgot to mention that I used a local built wine-4.20.
> There were lately some changes in that area in Wine, therefore
> if you use an older Wine version it might behave different.
> 
>     https://source.winehq.org/git/wine.git/history/HEAD:/dlls/msvcrt
> 
> 
> OK.
>  
> 
> But does the executable with -lucrt print the expected
> output in Windows?
> 
> 
> Interesting: in windows with -lucrt prints correctly, but not in wine-4.0.2.
> I see that Debian has wine64-development-4.19 and 4.20, I will test those.
> 
> Summary for %e:
>            | no -lucrt  | with -lucrt
> windows    | fail       | pass
> wine-4.0.2 | fail       | fail
> wine-4.19  | fail       | pass
> wine-4.20  | fail*      | pass
> 
> Summary for %z:
>            | no -lucrt  | with -lucrt
> windows    | fail       | pass
> wine-4.0.2 | fail       | fail
> wine-4.19  | fail       | fail
> wine-4.20  | fail       | pass
> 
> * wine-4.20 also prints extra debug information for %e without -lucrt:
> 0009:err:msvcrt:MSVCRT__invalid_parameter (null):0 (null): (null) 0
> 
> Looks like the issue is with the runtime environment and not with mingw.
> I still would like to understand if/why -lucrt is necessary in this case.
> The documentation does not mention any libraries, only headers.
>  
> 
> >     At least the binaries produced in my tests behave the same
> >     in Wine and Windows.
> >
> > Even without -lucrt ?
> > The ucrt adds those api-ms-win-crt-* dependencies, which do not
> seem to
> > be necessary.
> 
> Looking at the complete output of i686-w64-mingw32-objdump shows that
> without -lucrt strftime is imported from msvcrt.dll.
> With -lucrt it imports strftime from api-ms-win-crt-time-l1-1-0.dll.
> That is what I guess makes the difference.
> 
> 
> Does that mean that strftime implementation in msvcrt.dll is faulty?
> 

>From my point of view, Microsoft cannot change msvcrt.dll because plenty
legacy software may rely on the "old" behaviour.
Therefore we got then msvcr90.dll and so on. And now they invented UCRT.
As Stephen wrote in message 20, if you compile with visual studio the
binary will link also against these UCRT libraries.

And documentation seems just to cover supported development
environments...

> -- 
> Marius

Kind regards,
Bernhard

Bug#931728: variety: privacy breach in variety

[James Lu]

Control: tags 931728 - patch
Control: severity 931728 wishlist
Control: retitle 931728 Allow disabling online access features

In version 0.7.2-2 I backported a patch adding a privacy policy notice
to Variety's first start - hopefully this addresses the transparency
part of what data Variety collects in order to function.

Unfortunately upstream does not consider a complete offline mode to be a
priority, since the bulk of Variety's features would become unusable.
See
https://github.com/varietywalls/variety/issues/198#issuecomment-510664947
for more background.

Best,
James



signature.asc
Description: OpenPGP digital signature

Bug#872864: Checkout upstream signatures as well when using pristine-tar

[Christian Göttsche]

Control: severity -1 important
Control: tags -1 patch

Hi,

what about the following patch:

--- /usr/lib/python3/dist-packages/gbp/deb/git.py   2019-10-31
16:07:04.0 +0100
+++ /root/git.py2019-11-21 17:07:41.485223303 +0100
@@ -320,7 +320,15 @@
 output = source.upstream_tarball_name(comp.type, component=component)
 try:
 self.pristine_tar.checkout(source.name,
source.upstream_version, comp.type, output_dir,
-   component=component, quiet=True)
+   component=component,
quiet=True, signature=True)
+except CommandExecFailed:
+gbp.log.info("Failed to create '%s' with attached
signature file. Retrying without..." % output)
+
+try:
+self.pristine_tar.checkout(source.name,
source.upstream_version, comp.type, output_dir,
+   component=component, quiet=True)
+except Exception as e:
+raise GitRepositoryError("Error creating %s: %s" % (output, e))
 except Exception as e:
 raise GitRepositoryError("Error creating %s: %s" % (output, e))
 return True

Bug#945237: libwebkit2gtk-4.0-37: AAC streams stop after 1:42

[Richard Lucassen]

Package: libwebkit2gtk-4.0-37
Version: 2.26.2-1
Severity: normal

Dear Maintainer,

Open the this stream using "surf":

surf http://tmp.xaq.nl/test-aac.html

After 1 minute and 42 seconds the stream starts to hic and stops completely 
after a few seconds. Tested on 3 Bullseye amd64 machines. 

Richard.

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

Kernel: Linux 5.2.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: sysvinit (via /sbin/init)

Versions of packages libwebkit2gtk-4.0-37 depends on:
ii  bubblewrap  0.3.3-2
ii  libatk1.0-0 2.34.1-1
ii  libc6   2.29-3
ii  libcairo2   1.16.0-4
ii  libegl1 1.1.0-1+b1
ii  libenchant1c2a  1.6.0-11.3
ii  libfontconfig1  2.13.1-2+b1
ii  libfreetype62.10.1-2
ii  libgcc1 1:9.2.1-19
ii  libgcrypt20 1.8.5-3
ii  libgdk-pixbuf2.0-0  2.40.0+dfsg-1
ii  libgl1  1.1.0-1+b1
ii  libglib2.0-02.62.2-3
ii  libgstreamer-gl1.0-01.16.1-1
ii  libgstreamer-plugins-base1.0-0  1.16.1-1
ii  libgstreamer1.0-0   1.16.1-1
ii  libgtk-3-0  3.24.12-1
ii  libharfbuzz-icu02.6.4-1
ii  libharfbuzz0b   2.6.4-1
ii  libhyphen0  2.8.8-7
ii  libicu6363.2-2
ii  libjavascriptcoregtk-4.0-18 2.26.2-1
ii  libjpeg62-turbo 1:1.5.2-2+b1
ii  libnotify4  0.7.8-1
ii  libopenjp2-72.3.1-1
ii  libpango-1.0-0  1.42.4-7
ii  libpng16-16 1.6.37-1
ii  libseccomp2 2.4.2-2
ii  libsecret-1-0   0.19.1-1
ii  libsoup2.4-12.68.2-1
ii  libsqlite3-03.30.1-1
ii  libstdc++6  9.2.1-19
ii  libtasn1-6  4.14-3
ii  libwayland-client0  1.17.0-1
ii  libwayland-egl1 1.17.0-1
ii  libwayland-server0  1.17.0-1
ii  libwebp60.6.1-2+b1
ii  libwebpdemux2   0.6.1-2+b1
ii  libwoff11.0.2-1+b1
ii  libx11-62:1.6.8-1
ii  libxcomposite1  1:0.4.4-2
ii  libxdamage1 1:1.1.5-1
ii  libxml2 2.9.4+dfsg1-8
ii  libxslt1.1  1.1.32-2.2
ii  xdg-dbus-proxy  0.1.2-1
ii  zlib1g  1:1.2.11.dfsg-1+b1

Versions of packages libwebkit2gtk-4.0-37 recommends:
ii  gstreamer1.0-alsa  1.16.1-1
ii  gstreamer1.0-gl1.16.1-1
ii  gstreamer1.0-libav 1.16.1-1
ii  gstreamer1.0-plugins-good  1.16.1-1
ii  libgl1-mesa-dri19.2.3-1

libwebkit2gtk-4.0-37 suggests no packages.

-- debconf-show failed

Bug#945236: Maintainer email

[Thomas Goirand]

Hi,

Small amendment to my submission. Please use product...@infomaniak.com
as maintainer email, rather than must myself.

Cheers,

Thomas Goirand (zigo)

Bug#945236: mirror submission for mirror.infomaniak.com

[Thomas Goirand]

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

Submission-Type: new
Site: mirror.infomaniak.com
Type: leaf
Archive-architecture: ALL amd64 arm64 armel armhf hurd-i386 i386 kfreebsd-amd64 
kfreebsd-i386 mips mips64el mipsel powerpc ppc64el s390x
Archive-http: /debian/
Archive-rsync: debian/
Maintainer: Thomas Goirand 
Country: CH Switzerland
Location: Geneva
Sponsor: Infomaniak https://www.infomaniak.com/
Comment: This is a super-fast link connected to 2 mirrors which are 2nd tier 
from ethz (ie: ftp.ch.debian.org), each server using RAID10 SSD, and connected 
with bonding of 2x 10 Gbits. Both servers are monitored 24/7 all year long by 
our dedicated L3 team that does the disaster recovery all year long for the 
rest of Infomaniak infrastructure. So in short: very fast and reliable servers.




Trace Url: http://mirror.infomaniak.com/debian/project/trace/
Trace Url: 
http://mirror.infomaniak.com/debian/project/trace/ftp-master.debian.org
Trace Url: 
http://mirror.infomaniak.com/debian/project/trace/mirror.infomaniak.com

Bug#945147: KMail blank print

[John Scott]

reassign 945147 libqt5webengine5
forcemerge 919504 945147

This issue in Qt WebEngine and has been fixed in Debian unstable. As such, I'm 
closing this bug, though unfortunately the fix is unlikely to land in Buster.

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

Bug#945235: calamares: Could not set ESP flag in manual partitionning.

[Alan Cole]

Package: calamares
Version: 3.2.16-1
Severity: minor

Dear Maintainer,

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

   * When trying to manual installation could not create an ESP flag
   to the new fat32 partition.

Thanks



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

Kernel: Linux 5.3.8-050308-generic (SMP w/8 CPU cores)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_CA.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 calamares depends on:
pn  kpackagetool5  
pn  libboost-python1.67.0  
ii  libc6  2.29-3
ii  libgcc11:9.2.1-19
pn  libkf5configcore5  
pn  libkf5coreaddons5  
pn  libkf5package5 
pn  libkf5parts5   
pn  libkf5service-bin  
pn  libkf5service5 
pn  libkpmcore8
ii  libparted2 3.3-1
ii  libpwquality1  1.4.2-1
ii  libpython3.7   3.7.5-2
ii  libqt5core5a   5.12.5+dfsg-2
ii  libqt5dbus55.12.5+dfsg-2
ii  libqt5gui5 5.12.5+dfsg-2
ii  libqt5network5 5.12.5+dfsg-2
ii  libqt5qml5 5.12.5-3
ii  libqt5quick5   5.12.5-3
pn  libqt5quickwidgets5
ii  libqt5svg5 5.12.5-2
pn  libqt5webkit5  
ii  libqt5widgets5 5.12.5+dfsg-2
ii  libqt5xml5 5.12.5+dfsg-2
ii  libstdc++6 9.2.1-19
pn  libyaml-cpp0.6 
ii  os-prober  1.77

Versions of packages calamares recommends:
ii  btrfs-progs 5.3.1-1
ii  squashfs-tools  1:4.4-1

calamares suggests no packages.

Bug#945208: "No such file or directory" when attempting to decrypt LUKS during init

[Amit Agnani]

Issue has been resolved.

During init, systemd-cryptsetup uses libcryptsetup to perform the actual
unlocking of the LUKS partition.

libcryptsetup itself requires a few kernel modules to work, or else it
fails with -ENOENT, which, through systemd's use of error no -> error
message, turns into a generic "No such file or directory" message.

Effectively, the message is bogus with reference to the keyfile, where
it actually referred to the missing kernel modules.

The missing kernel modules were "af_alg" and "algif_skcipher".





signature.asc
Description: PGP signature

Bug#945233: python-uinput: needs an explicit build dependency on dh-python

[Graham Inggs]

Source: python-uinput
Version: 0.11.2-2
Severity: serious
Tags: ftbfs

python3-all and python3-dev now dropped the dependency on dh-python:

[ Piotr Ożarowski ]
* Remove dh-python dependency from python3-all and python3-dev packages.
  Packages should build depend on dh-python or dh-sequence-python3
instead.

Please add an explicit build dependency on dh-python.

Bug#945234: cupp: Renaming cupp3 to cupp breaks Debian Sid/Bullseye repository

[Joao Eriberto Mota Filho]

Source: cupp
Version: 0.0+20160624.git07f9b8-1
Severity: normal

Dear maintainer,

After renaming cupp3 to cupp suddenly and without coordinate with other
maintainers, forensics-extra packages (and maybe others) was affected.
If it is a forced needed transition, please coordinate the action before
make it.

If you only need rename the package from now on because a light reason
as Python 2 removing, please follow these instructions[1]. IMO, this is
the solution for cupp. Note that you package will arrives to NEW queue.

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

Regards,

Eriberto

Bug#945232: ruby-benchmark-suite fails to build with ruby-benchmark-ips 2.7 in experimental

[Pirate Praveen]

Package: ruby-benchmark-suite
Version: 1.0.0+git.20130122.5bded6-2
Severity: important

This package fails to build with ruby-benchmark-ips 2.7 in experimental 
and blocking its upload to unstable.


/usr/bin/ruby2.5 /usr/bin/gem2deb-test-runner

┌──┐
│ Run tests for ruby2.5 from debian/ruby-tests.rb │
└──┘

RUBYLIB=/<>/debian/ruby-benchmark-suite/usr/lib/ruby/vendor_ruby:. 
GEM_PATH=/var/lib/gems/2.5.0:/usr/lib/ruby/gems/2.5.0:/usr/share/rubygems-integration/2.5.0:/usr/share/rubygems-integration/all:/usr/lib/x86_64-linux-gnu/rubygems-integration/2.5.0 
ruby2.5 debian/ruby-tests.rb
/usr/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in 
`require': cannot load such file -- benchmark/helpers (LoadError)
from /usr/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in 
`require'
from 
/<>/debian/ruby-benchmark-suite/usr/lib/ruby/vendor_ruby/benchmark_suite.rb:3:in 
`'
from /usr/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in 
`require'
from /usr/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in 
`require'
from /<>/test/test_benchmark_suite.rb:2:in `(required)>'
from /usr/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in 
`require'
from /usr/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in 
`require'

from debian/ruby-tests.rb:2:in `'
ERROR: Test "ruby2.5" failed. Exiting.

Bug#945231: fai-setup-storage: refine btrfs support (preserve_reinstall and more subvolumes)

[Jens Schmidt]

Package: fai-setup-storage
Version: 5.8.9
Severity: wishlist

Dear Maintainer,

consider the folowing:

disk_config disk1 disklabel:gpt bootable:1 fstabkey:uuid align-at:4k 
preserve_reinstall:3

primary /boot/efi 512vfat  rw
primary swap  1G swap  sw
primary - 32G- -

disk_config btrfs fstabkey:uuid
btrfs single   /disk1.3 
subvol=@buster,defaults,rw,relatime,compress


The above config would preserve the partition 1.3, however the following
btrfs setup does not support a preserve_reinstall flag and the partition
is overwritten.

Feature request: preserve_reinstal also for btrfs (and similar setups) 

Also, right now it is not possible to define multiple btrfs volumes on
the same partition, e.g.:

disk_config btrfs fstabkey:uuid
btrfs single   /disk1.3 
subvol=@buster,defaults,rw,relatime,compress
btrfs single   /var/cache   disk1.3 
subvol=@buster-var-cache,defaults,rw,relatime,compress

Best regards
Jens


-- System Information:
Debian Release: 10.1
  APT prefers stable
  APT policy: (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 /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages fai-setup-storage depends on:
ii  e2fsprogs 1.44.5-1+deb10u2
pn  liblinux-lvm-perl 
pn  libparse-recdescent-perl  
ii  parted3.2-25
ii  perl  5.28.1-6

Versions of packages fai-setup-storage recommends:
ii  lvm2   2.03.02-3
pn  mdadm  

Versions of packages fai-setup-storage suggests:
pn  cryptsetup 
ii  dmsetup2:1.02.155-3
pn  dosfstools 
pn  jfsutils   
pn  ntfs-3g
pn  reiserfsprogs  
pn  xfsprogs   

Bug#942106: rdeps of pandas cannot be built yet

[Graham Inggs]

Hi Bas

On Thu, 21 Nov 2019 at 14:12, Bas Couwenberg  wrote:
> Please add a depwait for pyresample, the binNMU failed because pandas
> (pulled in via xarray) hasn't been rebuilt with python3.8 yet.
>
>   dw pyresample_1.13.2-1 . ANY . -m 'python3-pandas (>=
> 0.25.3+dfsg-4+b1)'

I have give pyresample back with
--extra-depends 'python3-pandas (>= 0.25.3+dfsg-4+b1)'

I think that will do what we need.

Regards
Graham