Bug#967084: golang-1.14: FTBFS with gcc-10 on arm64

[Shengjing Zhu]

Control: forwarded -1 https://github.com/golang/go/issues/39466
Control: clone -1 -2
Control: reassign -2 src:golang-1.15 1.15~rc1-1
Control: retitle -2 golang-1.15: FTBFS with gcc-10 on arm64

clone again..

-- 
Shengjing Zhu

Bug#967084: golang-1.14: FTBFS with gcc-10 on arm64

[Shengjing Zhu]

Package: golang-1.14
Version: 1.14.6-1
Severity: serious
Justification: ftbfs

Control: forwarded -1 https://github.com/golang/go/issues/39466
Control: clone -1 -2
Control: reassign -2 src:golang-1.15 1.15~rc1-1
Control: retitle -2 golang-1.15: FTBFS with gcc-10 on arm64

# misc/cgo/test.test
libgcc(.text): unknown symbol __aarch64_have_lse_atomics
FAILmisc/cgo/test [build failed]
2020/08/03 19:38:58 Failed: exit status 2

https://buildd.debian.org/status/fetch.php?pkg=golang-1.14=arm64=1.14.6-1=1596483860=0

Bug#957977: xfce4-sensors-plugin: ftbfs with GCC-10

[Kentaro Hayashi]

control: tags -1 fixed-upstream

Hi, 
It seems that it was already fixed in upstream:

Here is the commit:
https://gitlab.xfce.org/panel-plugins/xfce4-sensors-plugin/-/commit/108ffac9eac23a5d87f142e36d162d62be0619e2

Bug#967082: grub-customizer: dmesg has error info:segfault at 50 ip 0000558a7f3024e1

[xiao sheng wen]

Package: grub-customizer
Version: 5.1.0-1
Severity: normal

Dear Maintainer,

 When I modify the "Boot default entry after" time,I find the dmesg has the 
following errors:

grub-customizer[1678]: segfault at 50 ip 558a7f3024e1 sp 7ffe94d1cd70 
error 4 in grub-customizer[558a7f282000+fa000]
[二 8月  4 10:17:27 2020] Code: 00 48 89 84 24 98 00 00 00 31 c0 48 8d 6c 24 40 
48 8d 45 10 48 89 ef 48 89 44 24 40 e8 e8 bb fa ff 48 8b 7b 08 48 85 ff 74 0d 
<48> 8b 07 48 8d 73 18 48 89 ea ff 50 18 48 8b 7c 24 40 48 8d 45 10

 When I click save,the dmesg errors is:
traps: grub-customizer[12997] general protection ip:5584c61924e1 
sp:7ffec6392f30 error:0 in grub-customizer[5584c6112000+fa000]

At last,the modify is successed in the /boot/grub/grub.cfg.

Is this a bug of grub-customizer?

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

Kernel: Linux 4.19.0-10-rt-amd64 (SMP w/4 CPU cores; PREEMPT)
Locale: LANG=zh_CN.utf8, LC_CTYPE=zh_CN.utf8 (charmap=UTF-8), LANGUAGE=zh_CN:zh 
(charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages grub-customizer depends on:
ii  hwinfo  21.63-3
ii  libarchive133.3.3-4+deb10u1
ii  libatkmm-1.6-1v52.28.0-2
ii  libc6   2.28-10
ii  libcairomm-1.0-1v5  1.12.2-4
ii  libgcc1 1:8.3.0-6
ii  libglib2.0-02.58.3-2+deb10u2
ii  libglibmm-2.4-1v5   2.58.0-2
ii  libgtk-3-0  3.24.5-1
ii  libgtkmm-3.0-1v53.24.0-2
ii  libpangomm-1.4-1v5  2.42.0-2
ii  libsigc++-2.0-0v5   2.10.1-2
ii  libssl1.1   1.1.1d-0+deb10u3
ii  libstdc++6  8.3.0-6
ii  policykit-1 0.105-25

grub-customizer recommends no packages.

grub-customizer suggests no packages.

-- no debconf information

Bug#967081: python-preshed: new upstream release 3.0.2 required for spaCy

[Paul Wise]

Source: python-preshed
Severity: wishlist

There is a new upstream version of preshed (3.0.2):

https://github.com/explosion/preshed/releases/tag/v3.0.2

This is required for packaging spaCy:

https://spacy.io/

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#967080: libapache2-mod-security2: causes syntax error in httpd config unless modsecurity-crs is installed as well

[Daniel Zahn]

Package: libapache2-mod-security2
Version: 2.9.1-2
Severity: important

Dear Maintainer,

if you install libapache2-mod-security2 without also installing modsecurity-crs
and then restart httpd there is a syntax error and the service goes down.

The reason is in the file /etc/apache2/mods-available/security2.conf
on line 12:

# Include OWASP ModSecurity CRS rules if installed
IncludeOptional /usr/share/modsecurity-crs/owasp-crs.load

Clearly the intention here from the comment and using IncludeOptional
is to only load this if it exists.

The bug is that this syntax does NOT make it optional but behaves like
an Include. So if you don't have that file, which comes from modsecurity-crs,
which is a recommendation but not a dependency things break.


Upstream apache httpd docs say about IncludeOptional:

" It works identically to the Include directive,
but it will be silently ignored (instead of causing an error)
if wildcards are used and they do not match any file or
directory or if a file path does not exist on the file system."

The key word here is "wildcards" and the logical "and".

In the line above there are no wildcards, it's just a path to
a single file.

This means the IncludeOptional is NOT optional, which means:

Could not open configuration file /usr/share/modsecurity-crs/owasp-crs.load: No 
such file or directory

and then finally:

Syntax error on line 12 of /etc/apache2/mods-enabled/security2.conf

and the service going down.

It seems really not obvious that IncludeOptional is not always optional
so I don't think that will be the only case and the impact was quite severe.

also see: https://httpd.apache.org/docs/2.4/mod/core.html#includeoptional

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

Kernel: Linux 4.9.0-9-amd64 (SMP w/24 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)

Versions of packages libapache2-mod-security2 depends on:
ii  apache2-bin [apache2-api-20120211]  2.4.25-3+deb9u9
ii  libapr1 1.5.2-5
ii  libaprutil1 1.5.4-3
ii  libc6   2.24-11+deb9u4
ii  libcurl3-gnutls 7.52.1-5+deb9u11
ii  liblua5.1-0 5.1.5-8.1+b2
ii  libpcre32:8.39-3
ii  libxml2 2.9.4+dfsg1-2.2+deb9u2
ii  libyajl22.1.0-2+b3

Versions of packages libapache2-mod-security2 recommends:
ii  modsecurity-crs  3.0.0-3

libapache2-mod-security2 suggests no packages.

-- no debconf information

Bug#967076: RFS: sslscan/2.0.0-1 [ITA] -- Fast SSL scanner

[Paul Wise]

On Mon, Aug 3, 2020 at 9:00 PM Ali Mezgani wrote:

> The package figure in the repository of Kali distribution.
> I don’t think that Debian security need it.

This is useful for sysadmins as well as pentesters so having it in
Debian is a good idea. Also Kali likes to contribute packages upstream
to Debian and we should encourage that. Eventually there could even be
a pentesting/security Debian pure blend, like there is a forensics
blend maintained by the Debian Security Tools team.

https://www.debian.org/blends/
https://wiki.debian.org/DebianPureBlends
https://wiki.debian.org/Teams/pkg-security
https://salsa.debian.org/pkg-security-team/forensics-all

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Bug#967079: gimp: After completing a batch conversion with David's Batch Processor, pressed Close button and got Crash message for the batch program and shortly after for GIMP itself.

[Detlev]

Package: gimp
Version: 2.10.8-2
Severity: normal
Tags: upstream

```
GNU Image Manipulation Program version 2.10.8
git-describe: GIMP_2_10_6-294-ga967e8d2c2
C compiler:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/8/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian
8.2.0-13' --with-bugurl=file:///usr/share/doc/gcc-8/README.Bugs --enable-
languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr --with-gcc-
major-version-only --program-suffix=-8 --program-prefix=x86_64-linux-gnu-
--enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-
included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls
--enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-
verify --enable-libmpx --enable-plugin --enable-default-pie --with-system-zlib
--with-target-system-zlib --enable-objc-gc=auto --enable-multiarch --disable-
werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32
--enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none
--without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 8.2.0 (Debian 8.2.0-13)

using GEGL version 0.4.12 (compiled against version 0.4.12)
using GLib version 2.58.3 (compiled against version 2.58.1)
using GdkPixbuf version 2.38.1 (compiled against version 2.38.0)
using GTK+ version 2.24.32 (compiled against version 2.24.32)
using Pango version 1.42.3 (compiled against version 1.42.3)
using Fontconfig version 2.13.1 (compiled against version 2.13.1)
using Cairo version 1.16.0 (compiled against version 1.16.0)

```
> fatal error: Segmentation fault

Stack trace:
```

# Stack traces obtained from PID 18194 - Thread 18194 #

[New LWP 18197]
[New LWP 18198]
[New LWP 18199]
[New LWP 18200]
[New LWP 18201]
[New LWP 18202]
[New LWP 18203]
[New LWP 18204]
[New LWP 18205]
[New LWP 18206]
[New LWP 18207]
[New LWP 18208]
[New LWP 18209]
[New LWP 18210]
[New LWP 18211]
[New LWP 18212]
[New LWP 18213]
[New LWP 18214]
[New LWP 18258]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
__libc_read (nbytes=256, buf=0x7ffd3ae21950, fd=31) at
../sysdeps/unix/sysv/linux/read.c:26
  Id   Target Id   Frame
* 1Thread 0x7f3e121fee00 (LWP 18194) "gimp-2.10"   __libc_read (nbytes=256,
buf=0x7ffd3ae21950, fd=31) at ../sysdeps/unix/sysv/linux/read.c:26
  2Thread 0x7f3e109df700 (LWP 18197) "gmain"   0x7f3e13e7a819 in
__GI___poll (fds=0x5604fecef020, nfds=2, timeout=-1) at
../sysdeps/unix/sysv/linux/poll.c:29
  3Thread 0x7f3e0fe4c700 (LWP 18198) "gdbus"   0x7f3e13e7a819 in
__GI___poll (fds=0x5604fed017c0, nfds=2, timeout=-1) at
../sysdeps/unix/sysv/linux/poll.c:29
  4Thread 0x7f3e00d12700 (LWP 18199) "gimp-2.10"
futex_abstimed_wait_cancelable (private=0, abstime=0x7f3e00d11760, expected=0,
futex_word=0x7f3dfbffdaa8) at ../sysdeps/unix/sysv/linux/futex-internal.h:205
  5Thread 0x7f3df6ef3700 (LWP 18200) "gimp-2.10"
futex_abstimed_wait_cancelable (private=0, abstime=0x7f3df6ef2760, expected=0,
futex_word=0x7f3dfbffdaa8) at ../sysdeps/unix/sysv/linux/futex-internal.h:205
  6Thread 0x7f3df66f2700 (LWP 18201) "gimp-2.10"
futex_abstimed_wait_cancelable (private=0, abstime=0x7f3df66f1760, expected=0,
futex_word=0x7f3dfbffdaa8) at ../sysdeps/unix/sysv/linux/futex-internal.h:205
  7Thread 0x7f3df5ef1700 (LWP 18202) "gimp-2.10"
futex_abstimed_wait_cancelable (private=0, abstime=0x7f3df5ef0760, expected=0,
futex_word=0x7f3dfbffdaa8) at ../sysdeps/unix/sysv/linux/futex-internal.h:205
  8Thread 0x7f3df56f0700 (LWP 18203) "gimp-2.10"
futex_abstimed_wait_cancelable (private=0, abstime=0x7f3df56ef760, expected=0,
futex_word=0x7f3dfbffdaa8) at ../sysdeps/unix/sysv/linux/futex-internal.h:205
  9Thread 0x7f3df4eef700 (LWP 18204) "gimp-2.10"
futex_abstimed_wait_cancelable (private=0, abstime=0x7f3df4eee760, expected=0,
futex_word=0x7f3dfbffdaa8) at ../sysdeps/unix/sysv/linux/futex-internal.h:205
  10   Thread 0x7f3de700 (LWP 18205) "gimp-2.10"
futex_abstimed_wait_cancelable (private=0, abstime=0x7f3defffe760, expected=0,
futex_word=0x7f3dfbffdaa8) at ../sysdeps/unix/sysv/linux/futex-internal.h:205
  11   Thread 0x7f3def7fe700 (LWP 18206) "gimp-2.10"
futex_abstimed_wait_cancelable (private=0, abstime=0x7f3def7fd760, expected=0,
futex_word=0x7f3dfbffdaa8) at ../sysdeps/unix/sysv/linux/futex-internal.h:205
  12   Thread 0x7f3deeffd700 (LWP 18207) "async"   syscall () at
../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
  13   Thread 0x7f3dee7fc700 (LWP 18208) "worker"  syscall () at

Bug#966640: build-depends: debhelper-compat (= 13) cannot be satisfied

[Robbie Harwood]

Control: reassign -1 aptitude

Aha, makes sense.  Sorry to bother!

Thanks,
--Robbie

Bug#966557: Blacklist nvidia-modeset and nvidia-drm

[Felix Dörre]

I've got a slight clue, what could be wrong here:

The posted update-glx --display glx shows the following line:

/usr/lib/nvidia - priority 100
  slave glx--libGL.so.1-x86_64-linux-gnu: 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1


but none libGLX_nvidia.so.0. From the maintainer-script however having 
at least one of libGL provided by nvidia or libGLX_nvidia present is 
required for the bumblebee alternative to be installed:

   libGL_nvidia_enabler="
    $(add_multiarch_slave /usr/lib "" libGL.so.1 /usr/lib 
nvidia/)
    $(add_multiarch_slave /usr/lib "" libGLX_nvidia.so.0 
/usr/lib "")


    if echo "$libGL_nvidia_enabler" | grep -q "slave" ; then
    bumblebee=1
    fi
...
    if [ -n "$bumblebee" ]; then
    # enable the alternative for GL usage via bumblebee 
(NVIDIA's libGL.so.1 available)
    update-alternatives --install /usr/lib/glx glx 
/usr/lib/nvidia/bumblebee $prio_bumblebee \



I hope this helps to understand what's wrong in this case.

--
Kind regards,
Felix Dörre

Bug#967060: Wishlist: package calibre-plugins-extra

[Norbert Preining]

Hi Andrzej,

On Mon, 03 Aug 2020, Andrzej A. Filip wrote:
> A package with additional calibre plugins (e.g. calibre-plugins-extra) would 
> be
> nice.

Agreed to that, but which one would you choose? 
(Besides the topic on how to package them)

Best

Norbert

--
PREINING Norbert  https://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#967039: marked as done (spamassassin: Unversioned Python removal in sid/bullseye)

[Noah Meyerhans]

Control: reopen -1

This isn't actually resolved.  The usage of python is still unversioned
(that is, the tests invoke /usr/bin/python, rather than python3, which
still fails).

The tests really have no need at all to use python.  Since
spamassassassin is a perl project, it'd be reasonable to reimplement
them in that; OTOH, since the tests are quite simple, it'd be reasonable
to reimplement them in bash.

Either way, the unversioned python issue is still present.  I'll work on
a more complete fix.

Bug#966557: Blacklist nvidia-modeset and nvidia-drm

[Joel Johnson]

On 2020-08-03 15:13, Andreas Beckmann wrote:

On 8/3/20 5:00 PM, Joel Johnson wrote:

On 2020-07-31 03:03, Andreas Beckmann wrote:

While this additional blacklisting sounds technically correct, I'm
curious why the driver gets loaded automatically in a bumblebee 
setup.



$(update-glx --display glx):
glx - auto mode
  link best version is /usr/lib/nvidia
  link currently points to /usr/lib/nvidia
  link glx is /usr/lib/glx
[...]


Hmm, that should have been a bumblebee alternative, but that is not
available in your case.

Does that change if you run
  dpkg-reconfigure glx-alternative-nvidia
manually?


There is no apparent change in output when running that command. 
Further, I'm only showing two registered alternatives for glx via 
update-alternatives --config glx.


There are 2 choices for the alternative glx (providing /usr/lib/glx).

  SelectionPathPriority   Status

* 0/usr/lib/nvidia  100   auto mode
  1/usr/lib/mesa-diverted   5 manual mode
  2/usr/lib/nvidia  100   manual mode

Joel

Bug#950334: aptitude: Help -> User's Manual contains special characters

[Diego Escalante]

Package: aptitude
Version: 0.8.13-1+b1
Followup-For: Bug #950334
X-Debbugs-Cc: die...@gnome.org

This is actually a broader bug and not related to specific locales.
The issue is that `src/ui.cc` defaults to transcoding the README files
to ISO-8859-1, and since all the README files are already UTF-8, you get
glitchy glyphs.

I'm attaching a patch for this specific issue, but note that I have an
open MR which includes this and a few more encoding related fixes:
  https://salsa.debian.org/apt-team/aptitude/-/merge_requests/10/commits

Note also that I wasn't able to properly test this because of the
current FTBFS in:
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=966875

But that said, this is merely a string replacement, shouldn't be
problematic.

-- Package-specific info:
Terminal: xterm-256color
$DISPLAY is set.
which aptitude: /usr/bin/aptitude

aptitude version information:
aptitude 0.8.13
Compiler: g++ 9.3.0
Compiled against:
  apt version 6.0.0
  NCurses version 6.2
  libsigc++ version: 2.10.2
  Gtk+ support disabled.
  Qt support disabled.

Current library versions:
  NCurses version: ncurses 6.2.20200212
  cwidget version: 0.5.18
  Apt version: 6.0.0

aptitude linkage:
linux-vdso.so.1 (0x7ffcc57a8000)
libapt-pkg.so.6.0 => /lib/x86_64-linux-gnu/libapt-pkg.so.6.0 
(0x7fbc70029000)
libncursesw.so.6 => /lib/x86_64-linux-gnu/libncursesw.so.6 
(0x7fbc6ffee000)
libtinfo.so.6 => /lib/x86_64-linux-gnu/libtinfo.so.6 
(0x7fbc6ffbf000)
libsigc-2.0.so.0 => /lib/x86_64-linux-gnu/libsigc-2.0.so.0 
(0x7fbc6ffb6000)
libcwidget.so.4 => /lib/x86_64-linux-gnu/libcwidget.so.4 
(0x7fbc6feb)
libsqlite3.so.0 => /lib/x86_64-linux-gnu/libsqlite3.so.0 
(0x7fbc6fd84000)
libboost_iostreams.so.1.71.0 => 
/lib/x86_64-linux-gnu/libboost_iostreams.so.1.71.0 (0x7fbc6fd5b000)
libxapian.so.30 => /lib/x86_64-linux-gnu/libxapian.so.30 
(0x7fbc6fb41000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 
(0x7fbc6fb1f000)
libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 
(0x7fbc6f952000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7fbc6f80e000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 
(0x7fbc6f7f4000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7fbc6f62d000)
libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 
(0x7fbc6f613000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x7fbc6f5f6000)
libbz2.so.1.0 => /lib/x86_64-linux-gnu/libbz2.so.1.0 
(0x7fbc6f5e3000)
liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x7fbc6f5ba000)
liblz4.so.1 => /lib/x86_64-linux-gnu/liblz4.so.1 (0x7fbc6f598000)
libzstd.so.1 => /lib/x86_64-linux-gnu/libzstd.so.1 (0x7fbc6f4ec000)
libudev.so.1 => /lib/x86_64-linux-gnu/libudev.so.1 (0x7fbc6f4c6000)
libsystemd.so.0 => /lib/x86_64-linux-gnu/libsystemd.so.0 
(0x7fbc6f41b000)
libgcrypt.so.20 => /lib/x86_64-linux-gnu/libgcrypt.so.20 
(0x7fbc6f2fe000)
/lib64/ld-linux-x86-64.so.2 (0x7fbc70684000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7fbc6f2f8000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x7fbc6f2eb000)
libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x7fbc6f2e2000)
libgpg-error.so.0 => /lib/x86_64-linux-gnu/libgpg-error.so.0 
(0x7fbc6f2bf000)

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

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

Versions of packages aptitude depends on:
ii  aptitude-common   0.8.13-1
ii  libapt-pkg6.0 2.1.7
ii  libboost-iostreams1.71.0  1.71.0-6+b2
ii  libc6 2.31-2
ii  libcwidget4   0.5.18-5
ii  libgcc-s1 10.2.0-3
ii  libncursesw6  6.2-1
ii  libsigc++-2.0-0v5 2.10.2-1
ii  libsqlite3-0  3.32.3-1
ii  libstdc++610.2.0-3
ii  libtinfo6 6.2-1
ii  libxapian30   1.4.15-1

Versions of packages aptitude recommends:
ii  libdpkg-perl1.20.5
ii  sensible-utils  0.0.12+nmu1

Versions of packages aptitude suggests:
pn  apt-xapian-index
pn  aptitude-doc-en | aptitude-doc  
pn  debtags 
ii  tasksel 3.59

-- no debconf information
>From 0cb1886fbbb0d6339bbd9458bc185b6d82d611af Mon Sep 17 00:00:00 2001
From: Diego Escalante Urrelo 
Date: Mon, 3 Aug 2020 17:29:17 -0500
Subject: [PATCH] ui: Default README encoding to UTF-8

The ui uses a hint string to 

Bug#967078: scilab,scilab-cli: both ship /usr/share/applications/scilab-cli.desktop etc.

[Andreas Beckmann]

Followup-For: Bug #967078

Actualy there are more files in both packages:

usr/share/applications/scilab-cli.desktop
usr/share/icons/hicolor/16x16/apps/scilab.png
usr/share/icons/hicolor/16x16/apps/scinotes.png
usr/share/icons/hicolor/16x16/apps/xcos.png
usr/share/icons/hicolor/16x16/mimetypes/application-x-scilab-bin.png
usr/share/icons/hicolor/16x16/mimetypes/application-x-scilab-cos.png
usr/share/icons/hicolor/16x16/mimetypes/application-x-scilab-cosf.png
usr/share/icons/hicolor/16x16/mimetypes/application-x-scilab-dem.png
usr/share/icons/hicolor/16x16/mimetypes/application-x-scilab-graph.png
usr/share/icons/hicolor/16x16/mimetypes/application-x-scilab-sav.png
usr/share/icons/hicolor/16x16/mimetypes/application-x-scilab-sce.png
usr/share/icons/hicolor/16x16/mimetypes/application-x-scilab-sci.png
usr/share/icons/hicolor/16x16/mimetypes/application-x-scilab-sod.png
usr/share/icons/hicolor/16x16/mimetypes/application-x-scilab-tst.png
usr/share/icons/hicolor/16x16/mimetypes/application-x-scilab-xcos.png
usr/share/icons/hicolor/16x16/mimetypes/application-x-scilab-zcos.png
usr/share/icons/hicolor/24x24/apps/scilab.png
usr/share/icons/hicolor/24x24/mimetypes/application-x-scilab-bin.png
usr/share/icons/hicolor/24x24/mimetypes/application-x-scilab-cos.png
usr/share/icons/hicolor/24x24/mimetypes/application-x-scilab-cosf.png
usr/share/icons/hicolor/24x24/mimetypes/application-x-scilab-dem.png
usr/share/icons/hicolor/24x24/mimetypes/application-x-scilab-graph.png
usr/share/icons/hicolor/24x24/mimetypes/application-x-scilab-sav.png
usr/share/icons/hicolor/24x24/mimetypes/application-x-scilab-sce.png
usr/share/icons/hicolor/24x24/mimetypes/application-x-scilab-sci.png
usr/share/icons/hicolor/24x24/mimetypes/application-x-scilab-sod.png
usr/share/icons/hicolor/24x24/mimetypes/application-x-scilab-tst.png
usr/share/icons/hicolor/24x24/mimetypes/application-x-scilab-xcos.png
usr/share/icons/hicolor/24x24/mimetypes/application-x-scilab-zcos.png
usr/share/icons/hicolor/256x256/apps/puffin.png
usr/share/icons/hicolor/256x256/apps/scilab.png
usr/share/icons/hicolor/256x256/apps/scinotes.png
usr/share/icons/hicolor/256x256/apps/xcos.png
usr/share/icons/hicolor/256x256/mimetypes/application-x-scilab-bin.png
usr/share/icons/hicolor/256x256/mimetypes/application-x-scilab-cos.png
usr/share/icons/hicolor/256x256/mimetypes/application-x-scilab-cosf.png
usr/share/icons/hicolor/256x256/mimetypes/application-x-scilab-dem.png
usr/share/icons/hicolor/256x256/mimetypes/application-x-scilab-graph.png
usr/share/icons/hicolor/256x256/mimetypes/application-x-scilab-sav.png
usr/share/icons/hicolor/256x256/mimetypes/application-x-scilab-sce.png
usr/share/icons/hicolor/256x256/mimetypes/application-x-scilab-sci.png
usr/share/icons/hicolor/256x256/mimetypes/application-x-scilab-sod.png
usr/share/icons/hicolor/256x256/mimetypes/application-x-scilab-tst.png
usr/share/icons/hicolor/256x256/mimetypes/application-x-scilab-xcos.png
usr/share/icons/hicolor/256x256/mimetypes/application-x-scilab-zcos.png
usr/share/icons/hicolor/32x32/apps/scilab.png
usr/share/icons/hicolor/32x32/apps/scinotes.png
usr/share/icons/hicolor/32x32/apps/xcos.png
usr/share/icons/hicolor/32x32/mimetypes/application-x-scilab-bin.png
usr/share/icons/hicolor/32x32/mimetypes/application-x-scilab-cos.png
usr/share/icons/hicolor/32x32/mimetypes/application-x-scilab-cosf.png
usr/share/icons/hicolor/32x32/mimetypes/application-x-scilab-dem.png
usr/share/icons/hicolor/32x32/mimetypes/application-x-scilab-graph.png
usr/share/icons/hicolor/32x32/mimetypes/application-x-scilab-sav.png
usr/share/icons/hicolor/32x32/mimetypes/application-x-scilab-sce.png
usr/share/icons/hicolor/32x32/mimetypes/application-x-scilab-sci.png
usr/share/icons/hicolor/32x32/mimetypes/application-x-scilab-sod.png
usr/share/icons/hicolor/32x32/mimetypes/application-x-scilab-tst.png
usr/share/icons/hicolor/32x32/mimetypes/application-x-scilab-xcos.png
usr/share/icons/hicolor/32x32/mimetypes/application-x-scilab-zcos.png
usr/share/icons/hicolor/48x48/apps/scilab.png
usr/share/icons/hicolor/48x48/mimetypes/application-x-scilab-bin.png
usr/share/icons/hicolor/48x48/mimetypes/application-x-scilab-cos.png
usr/share/icons/hicolor/48x48/mimetypes/application-x-scilab-cosf.png
usr/share/icons/hicolor/48x48/mimetypes/application-x-scilab-dem.png
usr/share/icons/hicolor/48x48/mimetypes/application-x-scilab-graph.png
usr/share/icons/hicolor/48x48/mimetypes/application-x-scilab-sav.png
usr/share/icons/hicolor/48x48/mimetypes/application-x-scilab-sce.png
usr/share/icons/hicolor/48x48/mimetypes/application-x-scilab-sci.png
usr/share/icons/hicolor/48x48/mimetypes/application-x-scilab-sod.png
usr/share/icons/hicolor/48x48/mimetypes/application-x-scilab-tst.png
usr/share/icons/hicolor/48x48/mimetypes/application-x-scilab-xcos.png
usr/share/icons/hicolor/48x48/mimetypes/application-x-scilab-zcos.png
usr/share/mime/packages/scilab.xml

Andreas

Bug#967078: scilab,scilab-cli: both ship /usr/share/applications/scilab-cli.desktop

[Andreas Beckmann]

Package: scilab,scilab-cli
Version: 6.1.0+dfsg1-5
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package failed to install
because it tries to overwrite other packages files.

>From the attached log (scroll to the bottom...):

  Selecting previously unselected package scilab.
  Preparing to unpack .../238-scilab_6.1.0+dfsg1-5_all.deb ...
  Unpacking scilab (6.1.0+dfsg1-5) ...
  dpkg: error processing archive 
/tmp/apt-dpkg-install-yQvaJu/238-scilab_6.1.0+dfsg1-5_all.deb (--unpack):
   trying to overwrite '/usr/share/applications/scilab-cli.desktop', which is 
also in package scilab-cli 6.1.0+dfsg1-5
  dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
  Errors were encountered while processing:
   /tmp/apt-dpkg-install-yQvaJu/238-scilab_6.1.0+dfsg1-5_all.deb


cheers,

Andreas


scilab=6.1.0+dfsg1-5_scilab-cli=6.1.0+dfsg1-5.log.gz
Description: application/gzip

Bug#966823: python2-doc: trying to overwrite '/usr/share/doc/python2/README.Debian', which is also in package python2 2.7.17-2

[Andreas Beckmann]

Followup-For: Bug #966823

Hi,

actually both python2 and python2-doc (both version 2.7.18-1) ship
  /usr/share/doc/python2/README.Debian


Andreas

Bug#966965: dune-grid-glue: FTBFS: terminate called after throwing an instance of 'Dune::Exception'

[Ansgar]

Control: tag -1 + upstream

Lucas Nussbaum writes:
> Source: dune-grid-glue
> Version: 2.7.0-2
>>   what():  Dune::Exception 
>> [eh:/<>/dune/grid-glue/test/ringcommtest.cc:24]: MPI ERROR -- 
>> MPI_ERR_TAG: invalid tag
>>   what():  Dune::Exception 
>> [eh:/<>/dune/grid-glue/test/ringcommtest.cc:24]: MPI ERROR -- 
>> MPI_ERR_TAG: invalid tag

The is probably caused by `int tag = 12345678;` in the code while
OpenMPI might have a lower limit, see [1].

  [1]: https://github.com/open-mpi/ompi/issues/6940

Ansgar

Bug#966554: how to apply the workaround?

[quixote]

Dumb question time, because I'm still not seeing the updates to fix 
grub, and running grub-install /dev/sda still gets me the same errors 
about "no space left on device." (I checked: it's 200MB, and has 98% 
free space.)


I only have two repositories in my sources.list, since I have a plain 
vanilla install of buster. (Plus a repo for virtualbox)

__
 Debian packages for stable
deb http://ftp.citylink.co.nz/debian/ stable main contrib

# Security updates for stable
deb http://security.debian.org/ stable/updates main contrib

Do I maybe not have the right repo?  Adding:

deb http://deb.debian.org/debian buster-updates main

and/or

deb http://deb.debian.org/debian/ buster-proposed-updates main


didn't seem to bring up any useful packages (just a ca-certificates one).

Any ideas what the issue might be?

Thanks!

Bug#966928: python-biopython: FTBFS: AssertionError: 0.018551002172574885 != 0.0194 within 4 places (0.00084899782742511518 difference)

[Étienne Mollier]

Control: tags -1 fixed-upstream

Good day,

Looking to upstream issue tracker, the problem has been hit as
well and seems triggered by the update past Scipy 1.5.0.  Here
are the details of the issue, and the fix implemented by zruan:

https://github.com/biopython/biopython/issues/2993
https://github.com/biopython/biopython/pull/2998

This test failure will thus most likely be solved with the next
upstream version of biopython.

Thanks for having caught that issue.
Kind Regards,
-- 
Étienne Mollier 
Old rsa/3072: 5ab1 4edf 63bb ccff 8b54  2fa9 59da 56fe fff3 882d
New rsa/4096: 8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
Sent from /dev/pts/12, please excuse my verbosity.


signature.asc
Description: PGP signature

Bug#967077: universal-ctags: install alternatives entry for etags

[Benjamin Barenblat]

Package: universal-ctags
Version: 0+git20181215-2
Severity: wishlist
Control: found -1 0+git20191013-1

I’d like to set ctags-universal as the etags on my system, but there’s
no alternatives entry for it. An entry in the postinst/prerm à la
exuberant-ctags [1] would fix this.

[1] 
https://sources.debian.org/src/exuberant-ctags/1:5.9~svn20110310-13/debian/postinst/#L7

Bug#966557: Blacklist nvidia-modeset and nvidia-drm

[Andreas Beckmann]

On 8/3/20 5:00 PM, Joel Johnson wrote:
> On 2020-07-31 03:03, Andreas Beckmann wrote:
>> While this additional blacklisting sounds technically correct, I'm
>> curious why the driver gets loaded automatically in a bumblebee setup.

> $(update-glx --display glx):
> glx - auto mode
>   link best version is /usr/lib/nvidia
>   link currently points to /usr/lib/nvidia
>   link glx is /usr/lib/glx
> [...]

Hmm, that should have been a bumblebee alternative, but that is not
available in your case.

Does that change if you run
  dpkg-reconfigure glx-alternative-nvidia
manually?

Andreas

Bug#966805: thunderbird: OAUTH2 no longer works ("NS_ERROR_NET_INADEQUATE_SECURITY" error)

[Andrea Borgia]

For unstable I pushed a fixed version (see #966806).


This explains why I could not find this bugreport when I searched for 
gmail at first: it was filed right after mine :D



As you opened this report against the version of Thunderbird in 
experimental I'll ket this report open until a fix is prepared, should 
be done by the next version for experimental.


Yeah, I noticed it too late that I ran reportbug when I had the 
experimental package instead of the one from testing. As a general rule, 
is it bad to file bugs against experimental?




You can fix your current problem by installing libnss3 from unstable.


Apparently it migrated already to testing, very well, checking now.

Yes, works fine, thank you.

Bug#966951: libpeas: FTBFS: dh_auto_test: error: cd obj-x86_64-linux-gnu && LC_ALL=C.UTF-8 MESON_TESTTHREADS=4 ninja test returned exit code 1

[Simon McVittie]

On Mon, 03 Aug 2020 at 13:09:55 +0100, Simon McVittie wrote:
> I've confirmed that this succeeds in a pure bullseye chroot and fails if
> I upgrade meson (only) to the version from unstable. I'm not completely
> sure whether this is a straightforward regression in meson, or whether
> libpeas is holding it wrong.
> 
> It seems that what is meant to happen here is that the libpeas build
> system builds tests/libpeas/introspection/*.[ch] into a shared library,
> introspects them, and uses the generated introspection data during the
> build-time tests.
> 
> With meson 0.54.3-1, I get:
> 
> obj-x86_64-linux-gnu/tests/libpeas/introspection/Introspection-1.0.typelib
> obj-x86_64-linux-gnu/tests/libpeas/introspection/Introspection-1.0.gir
> 
> With 0.55.0-2, the introspection data (typelib and GIR XML) isn't generated.

Bisection says this regressed in b1e3440e "ninjabackend: Treat GNOME
gir/typelib as libraries" - or maybe it's a pre-existing bug in libpeas
exposed by that commit, it isn't clear to me which.

smcv

Bug#967076: RFS: sslscan/2.0.0-1 [ITA] -- Fast SSL scanner

[Ali Mezgani]

Hello,

The package figure in the repository of Kali distribution.
I don’t think that Debian security need it.


Regards,

On Mon, Aug 3, 2020 at 21:45 Alejo Marín  wrote:

> Package: sponsorship-requests
> Severity: normal
>
> Dear mentors,
>
> I am looking for a sponsor for my package "sslscan":
>
>  * Package name: sslscan
>Version : 2.0.0-1
>Upstream Author : rbsec 
>  * URL : https://github.com/rbsec/sslscan
>  * License : GPL-3.0+ with OpenSSL exception
>  * Vcs : [fill in URL of packaging vcs]
>Section : utils
>
> It builds those binary packages:
>
>   sslscan - Fast SSL scanner
>
> To access further information about this package, please visit the following 
> URL:
>
>   https://mentors.debian.net/package/sslscan/
>
> Alternatively, one can download the package with dget using this command:
>
>   dget -x 
> https://mentors.debian.net/debian/pool/main/s/sslscan/sslscan_2.0.0-1.dsc
>
> Changes since the last upload:
>
>  sslscan (2.0.0-1) unstable; urgency=medium
>  .
>* New upstream release.
>* New maintainer. (Closes: #952385)
>* Update debian/watch.
>* Remove debian/compat.
>* debian/rules
>  + Remove override_dh_auto_install.
>  + add override_dh_auto_build.
>  + Remove innecesary "--parallel" from "dh $@".
>* debian/control
>  + Update Standard-Version to 4.5.0.
>  + Set myself as Maintainer.
>  + debhelper bump level to 13.
>  + Update priority to optional.
>  + Mark Rules-Requires-Root: no as we don't need root for building.
>* debian/copyright
>  + Update my email address.
>  + Extend debian copyright holder years.
>  + Update Upstream-Contact.
>  + Update License to GPL-3.0+.
>  + Update description license.
>* debian/upstream/metadata
>  + Add Bug-Database and Bug-Submit fields.
>* debian/patches
>  + Add 01_spelling_sslscanc.diff patch.
>
> Regards,
> --*Jhon Alejandro Marín Rodríguez - *jamarin90
>
>
>

Bug#966881: openafs: FTBFS: ld: vlib.a(volume.o):./src/vol/volume.c:128: multiple definition of `vol_io_params'; ihandle.o:./src/vol/ihandle.c:81: first defined here

[Benjamin Kaduk]

tags 966881 fixed-upstream
thanks

On Mon, Aug 03, 2020 at 10:04:57AM +0200, Lucas Nussbaum wrote:
> Source: openafs
> Version: 1.8.6-1
> Severity: serious
> Justification: FTBFS on amd64
> Tags: bullseye sid ftbfs
> Usertags: ftbfs-20200802 ftbfs-bullseye
> 
> Hi,
> 
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
> 
> Relevant part (hopefully):
> > gcc  -Wl,-z,relro -L/usr/lib/x86_64-linux-gnu/heimdal 
> > -L/usr/lib/x86_64-linux-gnu/heimdal -g -O   -Damd64_linux26  
> > -DFSSYNC_BUILD_SERVER -DFSSYNC_BUILD_CLIENT -g -O2 
> > -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
> > -Werror=format-security -g -O   -I/<>/src/config 
> > -I/<>/include -I. -I.   -I/usr/include/heimdal   -o volscan 
> > volscan-main.o vol-info.o physio.o ihandle.o \
> > /<>/lib/libcmd.a vlib.a /<>/lib/util.a 
> > /<>/lib/libdir.a /<>/lib/librx.a 
> > /<>/lib/libafshcrypto_lwp.a /<>/lib/liblwp.a 
> > /<>/lib/libsys.a /<>/lib/libacl.a 
> > /<>/lib/libopr.a -lroken -lresolv  
> > /usr/bin/ld: vlib.a(volume.o):./src/vol/volume.c:128: multiple definition 
> > of `vol_io_params'; ihandle.o:./src/vol/ihandle.c:81: first defined here
> > /usr/bin/ld: vlib.a(daemon_com.o):./src/vol/daemon_com.c:49: multiple 
> > definition of `V_BreakVolumeCallbacks'; 
> > vlib.a(fssync-server.o):./src/vol/fssync-server.c:83: first defined here
> > gcc -fPIC   -g -O2 -fdebug-prefix-map=/<>=. 
> > -fstack-protector-strong -Wformat -Werror=format-security -g -O   
> > -I/<>/src/config -I/<>/include -I. -I.   
> > -I/usr/include/heimdal   -o X11windows.o -c X11windows.c
> > collect2: error: ld returned 1 exit status

Looks like fallout from -fcommon being on by default, and is fixed in
upstream (to appear in 1.8.7).  We can pull in the relevant patches until
then, of course.

-Ben

Bug#967076: RFS: sslscan/2.0.0-1 [ITA] -- Fast SSL scanner

[Alejo Marín]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "sslscan":

 * Package name: sslscan
   Version : 2.0.0-1
   Upstream Author : rbsec 
 * URL : https://github.com/rbsec/sslscan
 * License : GPL-3.0+ with OpenSSL exception
 * Vcs : [fill in URL of packaging vcs]
   Section : utils

It builds those binary packages:

  sslscan - Fast SSL scanner

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/s/sslscan/sslscan_2.0.0-1.dsc

Changes since the last upload:

 sslscan (2.0.0-1) unstable; urgency=medium
 .
   * New upstream release.
   * New maintainer. (Closes: #952385)
   * Update debian/watch.
   * Remove debian/compat.
   * debian/rules
 + Remove override_dh_auto_install.
 + add override_dh_auto_build.
 + Remove innecesary "--parallel" from "dh $@".
   * debian/control
 + Update Standard-Version to 4.5.0.
 + Set myself as Maintainer.
 + debhelper bump level to 13.
 + Update priority to optional.
 + Mark Rules-Requires-Root: no as we don't need root for building.
   * debian/copyright
 + Update my email address.
 + Extend debian copyright holder years.
 + Update Upstream-Contact.
 + Update License to GPL-3.0+.
 + Update description license.
   * debian/upstream/metadata
 + Add Bug-Database and Bug-Submit fields.
   * debian/patches
 + Add 01_spelling_sslscanc.diff patch.

Regards,
--*Jhon Alejandro Marín Rodríguez - *jamarin90

Bug#737855: libnss3-dev: arch-dependent file in "Multi-Arch: same" package

[Mike Hommey]

On Mon, Aug 03, 2020 at 06:42:46AM +0200, Helmut Grohne wrote:
> Hi Mike,
> 
> On Mon, Aug 03, 2020 at 07:12:20AM +0900, Mike Hommey wrote:
> > Upstream's nss-config uses pkg-config for 3 things:
> > - getting exec_prefix. It's always /usr, independently of the pkg-config
> >   you use
> > - getting includedir. It's always /usr/include/nss, independently of the
> >   pkg-config you use
> 
> Agreed.
> 
> > - getting libdir. This varies dependending on the pkg-config you use,
> >   but so does the content of the current nss-config, and as was said
> >   up-thread, nothing uses that.
> 
> Subtly wrong. The --libdir flag is not used by anything in Debian.
> However the upstream nss-config --libs also emits:
> 
> -Wl,-rpath-link,$libdir -L$libdir
> 
> So we are injecting a wrong library directory in some practical
> situations. The rpath is a difference to the current nss-config. I
> suspect that it alone would break stuff.

How so? a) it's not -rpath, and doesn't do something very relevant to
the produced binary except add a search path for dependencies of
dependencies b) LD happily ignores libraries it finds in the various
search paths when they are not for the right architecture.

The worst that happens is that you get warnings like:
/usr/bin/ld: skipping incompatible /usr/lib/i386-linux-gnu/libnss3.so when 
searching for -lnss3

Mike

Bug#966854: iagno: FTBFS: ../src/perfs-tests-generator.vala:45.16-45.20: error: The name `Posix' does not exist in the context of `PerfsTestsGenerator.handle_local_options'

[Simon McVittie]

Control: reassign -1 iagno 1:3.36.2-1
Control: forwarded -1 https://gitlab.gnome.org/GNOME/iagno/-/issues/16
Control: tags -1 + fixed-upstream patch

On Mon, 03 Aug 2020 at 12:43:37 +0100, Simon McVittie wrote:
> In the failing build (on bullseye but with unstable's meson), the failing
> command seems to be:
> 
> valac -C --pkg gio-2.0 --color=always --directory 
> src/iagno-perfs-tests-generator.p --basedir ../src 
> --enable-experimental-non-null ../src/vapi/config.vapi 
> ../src/perfs-tests-generator.vala ../src/computer-player.vala 
> ../src/computer-reversi.vala ../src/game.vala ../src/player.vala
> 
> In the successful build (on pure bullseye) the corresponding command seems
> to be this:
> 
> [8/47] valac -C --pkg posix --pkg gio-2.0 --color=always --directory 
> src/25a6634@@iagno-perfs-tests-generator@exe --basedir ../src 
> --enable-experimental-non-null ../src/vapi/config.vapi 
> ../src/perfs-tests-generator.vala ../src/computer-player.vala 
> ../src/computer-reversi.vala ../src/game.vala ../src/player.vala
> 
> so it seems meson 0.55.0 has stopped passing "--pkg posix" to valac

On closer inspection this seems to be a pre-existing bug in iagno that
was exposed by a meson bugfix.

Bisecting meson indicates that the build failure is triggered by
7195c0ee "compilers: Fix accidental coredata mutations".

Two executables in iagno use the Posix module:
iagno-perfs-tests-generator, and the iagno game itself. However, only the
iagno game itself has the required posix_dependency. I think previously,
the meson bug fixed in 7195c0ee might have made that dependency leak into
the other dependency list.

The patch is to add the missing dependency:
https://gitlab.gnome.org/GNOME/iagno/-/commit/0100bab269f2102f24a6e41202b931da1b6e8dc5

smcv

Bug#967075: haskell-ghc-lib-parser: FTBFS on mips* and s390x: /usr/lib/ghc/include/stg/SMP.h:390:2: error: #error memory barriers unimplemented on this architecture

[Sebastian Ramacher]

Source: haskell-ghc-lib-parser
Version: 8.8.3.20200412.1-2
Severity: important
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

The package currently fails to build on mipsel, mips64el and s390x:
| /usr/lib/ghc/include/stg/SMP.h: In function ‘load_load_barrier’:
| /usr/lib/ghc/include/stg/SMP.h:390:2: error: #error memory barriers 
unimplemented on this architecture
|   390 | #error memory barriers unimplemented on this architecture
|   |  ^
| compiling dist-ghc/build/GHC/Exts/Heap/InfoTable_hsc_make.c failed (exit code 
1)

See
https://buildd.debian.org/status/fetch.php?pkg=haskell-ghc-lib-parser=mips64el=8.8.3.20200412.1-2=1595944286=0

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#967050: strongswan-starter.service: Standard output type syslog is obsolete, automatically updating to journal

[Christian Göttsche]

Package: strongswan-starter
Version: 5.8.4-1
File: /lib/systemd/system/strongswan-starter.service

systemc v246 complains about the strongswan-starter service:

Aug 03 17:54:46 host systemd[1]:
/lib/systemd/system/strongswan-starter.service:8: Standard output type
syslog is obsolete, automatically updating to journal. Please update
your unit file, and consider removing the setting altogether.

Bug#967049: java.lang.IllegalArgumentException: Width and height must be >= 0 since upgrade to 11.0.8+10

[anna]

Package: openjdk-11-jre
Version: 11.0.8+10-1~deb10u1
Severity: normal

Dear Maintainer,

Since upgrading openjdk-11-jre to 11.0.8+10-1~deb10u1 I get occasionally
IAEs running JOSM. This did not happen with previous java versions and
is likely bounded to the Metal Look-and-Feel.

See https://josm.openstreetmap.de/ticket/19585 for details.

Cheers


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

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

Versions of packages openjdk-11-jre depends on:
ii  libc62.28-10
ii  libgif7  5.1.4-3
ii  libgl1   1.1.0-1
ii  libjpeg62-turbo  1:1.5.2-2+b1
ii  libpng16-16  1.6.36-6
ii  libx11-6 2:1.6.7-1
ii  libxext6 2:1.3.3-1+b2
ii  openjdk-11-jre-headless  11.0.8+10-1~deb10u1
ii  zlib1g   1:1.2.11.dfsg-1

Versions of packages openjdk-11-jre recommends:
ii  fonts-dejavu-extra   2.37-1
ii  libatk-wrapper-java-jni  0.33.3-22

openjdk-11-jre suggests no packages.

-- no debconf information

Bug#967073: libmediainfo: CVE-2020-15395

[Salvatore Bonaccorso]

Source: libmediainfo
Severity: important
Tags: security upstream
Forwarded: https://sourceforge.net/p/mediainfo/bugs/1127/
X-Debbugs-Cc: Debian Security Team 

Hi,

The following vulnerability was published for libmediainfo.

CVE-2020-15395[0]:
| In MediaInfoLib in MediaArea MediaInfo 20.03, there is a stack-based
| buffer over-read in Streams_Fill_PerStream in Multiple/File_MpegPs.cpp
| (aka an off-by-one during MpegPs parsing).

There is an upstream report at [1], filling this bug for tracking the
upstream status.

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-2020-15395
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-15395
[1] https://sourceforge.net/p/mediainfo/bugs/1127/

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#967074: haskell-ghc-lib-parser: FTBFS on arm{el,hf}: ghc: out of memory (requested 1048576 bytes)

[Sebastian Ramacher]

Source: haskell-ghc-lib-parser
Version: 8.10.1.20200523
Severity: important
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

haskell-ghc-lib-parser currently fails to build on armel and armhf:
| [180 of 207] Compiling HsInstances  ( compiler/hsSyn/HsInstances.hs, 
dist-ghc/build/HsInstances.o )
| ghc: out of memory (requested 1048576 bytes)
| make: *** [/usr/share/cdbs/1/class/hlibrary.mk:147: build-ghc-stamp] Error 251

See
https://buildd.debian.org/status/fetch.php?pkg=haskell-ghc-lib-parser=armel=8.8.3.20200412.1-2=1595616637=0

This currently prevents haskell-ghc-lib-parser-ex and hlint from being
built on armel and armhf.

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#967007: Now dependencies are satisfied

[Pirate Praveen]

On Tue, Aug 4, 2020 at 00:25, Pirate Praveen  
wrote:
This was fixed in ruby-webpacker 4.2.2-3. Now the autopkgtest is 
passing.


It took almost a whole day to troubleshoot and fix this.


with ruby-webpacker 4.2.2-3 and ruby-webdrivers 4.4.1-1 in NEW, passed 
as local debs,


Run options: --seed 51583

# Running:

...

Finished in 18.984631s, 0.3687 runs/s, 0.4741 assertions/s.
7 runs, 9 assertions, 0 failures, 0 errors, 0 skips
autopkgtest [01:19:44]: test newapp: ---]
autopkgtest [01:19:44]: test newapp:  - - - - - - - - - - results - - - 
- - - - - - -

newapp   PASS

I have pushed the changes to 'newapp-autopkgtest` branch as I don't 
want to block further changes in master till we get  ruby-webpacker and 
ruby-webdrivers in the archive.

Bug#966869: nfs-ganesha: FTBFS with GCC-10

[Lucas Kanashiro]

Hi,

I submitted a merge request here to fix this FTBFS:

https://salsa.debian.org/debian/nfs-ganesha/-/merge_requests/2

Thanks in advance for considering this patch!

-- 
Lucas Kanashiro

Bug#967047: plymouth-start.service: Unit configured to use KillMode=none

[Christian Göttsche]

Package: plymouth
Version: 0.9.4-3
File: /lib/systemd/system/plymouth-start.service

systemd v246 complains about the plymouth-start service configuration
via a syslog warning:

Aug 03 17:40:48 dlaptop systemd[1]:
/lib/systemd/system/plymouth-start.service:16: Unit configured to use
KillMode=none. This is unsafe, as it disables systemd's process
lifecycle management for the service. Please update your service to
use a safer KillMode=, such as 'mixed' or 'control-group'. Support for
KillMode=none is deprecated and will eventually be removed.

Bug#967068: RM: freehep-graphicsio-pdf -- ROM; obsoleted by freehep-vectorgraphics

[Giovanni Mascellani]

Package: ftp.debian.org
Severity: normal

Package freehep-vectorgraphics provide a more recent version of
freehep-graphicsio-pdf, so the latter can be removed. Thanks!

Bug#967072: RM: freehep-graphicsio-tests -- ROM; obsoleted by freehep-vectorgraphics

[Giovanni Mascellani]

Package: ftp.debian.org
Severity: normal

Package freehep-vectorgraphics provide a more recent version of
freehep-graphicsio-tests, so the latter can be removed. Thanks!

Bug#967071: RM: freehep-graphicsio-swf -- ROM; obsoleted by freehep-vectorgraphics

[Giovanni Mascellani]

Package: ftp.debian.org
Severity: normal

Package freehep-vectorgraphics provide a more recent version of
freehep-graphicsio-swf, so the latter can be removed. Thanks!

Bug#967070: RM: freehep-graphicsio-svg -- ROM; obsoleted by freehep-vectorgraphics

[Giovanni Mascellani]

Package: ftp.debian.org
Severity: normal

Package freehep-vectorgraphics provide a more recent version of
freehep-graphicsio-svg, so the latter can be removed. Thanks!

Bug#967069: RM: freehep-graphicsio-ps -- ROM; obsoleted by freehep-vectorgraphics

[Giovanni Mascellani]

Package: ftp.debian.org
Severity: normal

Package freehep-vectorgraphics provide a more recent version of
freehep-graphicsio-ps, so the latter can be removed. Thanks!

Bug#967067: RM: freehep-graphicsio-java -- ROM; obsoleted by freehep-vectorgraphics

[Giovanni Mascellani]

Package: ftp.debian.org
Severity: normal

Package freehep-vectorgraphics provide a more recent version of
freehep-graphicsio-java, so the latter can be removed. Thanks!

Bug#967066: RM: freehep-graphicsio-emf -- ROM; obsoleted by freehep-vectorgraphics

[Giovanni Mascellani]

Package: ftp.debian.org
Severity: normal

Package freehep-vectorgraphics provide a more recent version of
freehep-graphicsio-emf, so the latter can be removed. Thanks!

Bug#967065: RM: freehep-graphicsio -- ROM; obsoleted by freehep-vectorgraphics

[Giovanni Mascellani]

Package: ftp.debian.org
Severity: normal

Package freehep-vectorgraphics provide a more recent version of
freehep-graphicsio, so the latter can be removed. Thanks!

Bug#967046: Possible missing instructions and rec: / sug: for sudo

[Christian Fischer]

Package: src:ospd-openvas
Version: 1.0.1-1

Dear Maintainer,

ospd-openvas is able to run / work without sudo. But if ospd-openvas is
running as a non-root user like done in Debian with "_gvm" it is highly
recommended to configure sudo as explained in [1].

As of today this text is now also available / included in the README.md
of ospd-openvas since [2].

Not sure if it a sudoers modification is something which should be done
/ is allowed to be done automatically but maybe a short additional note
for Debian users could be done?

In addition a rec: or sug: tag to sudo could be added to the package
(it's not a hard requirement / dependency).

Regards,

[1]
https://github.com/greenbone/openvas/blob/v7.0.1/INSTALL.md#setting-up-openvas
[2]
https://github.com/greenbone/ospd-openvas/pull/304

Bug#967064: RM: freehep-graphics2d -- ROM; obsoleted by freehep-vectorgraphics

[Giovanni Mascellani]

Package: ftp.debian.org
Severity: normal

Package freehep-vectorgraphics provide a more recent version of freehep-
graphics2d, so the latter can be removed. Thanks!

Bug#967063: ruby-faye: CVE-2020-15134

[Salvatore Bonaccorso]

Source: ruby-faye
Version: 1.2.4-1
Severity: grave
Tags: security upstream
Forwarded: https://github.com/faye/faye/issues/524
X-Debbugs-Cc: Debian Security Team 

Hi,

The following vulnerability was published for ruby-faye.

CVE-2020-15134[0]:
| Faye before version 1.4.0, there is a lack of certification validation
| in TLS handshakes. Faye uses em-http-request and faye-websocket in the
| Ruby version of its client. Those libraries both use the
| `EM::Connection#start_tls` method in EventMachine to implement the TLS
| handshake whenever a `wss:` URL is used for the connection. This
| method does not implement certificate verification by default, meaning
| that it does not check that the server presents a valid and trusted
| TLS certificate for the expected hostname. That means that any
| `https:` or `wss:` connection made using these libraries is vulnerable
| to a man-in-the-middle attack, since it does not confirm the identity
| of the server it is connected to. The first request a Faye client
| makes is always sent via normal HTTP, but later messages may be sent
| via WebSocket. Therefore it is vulnerable to the same problem that
| these underlying libraries are, and we needed both libraries to
| support TLS verification before Faye could claim to do the same. Your
| client would still be insecure if its initial HTTPS request was
| verified, but later WebSocket connections were not. This is fixed in
| Faye v1.4.0, which enables verification by default. For further
| background information on this issue, please see the referenced GitHub
| Advisory.


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-2020-15134
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-15134
[1] https://github.com/faye/faye/security/advisories/GHSA-3q49-h8f9-9fr9
[2] https://github.com/faye/faye/issues/524
[3] https://blog.jcoglan.com/2020/07/31/missing-tls-verification-in-faye/

Regards,
Salvatore

Bug#967061: ruby-faye-websocket: CVE-2020-15133

[Salvatore Bonaccorso]

Source: ruby-faye-websocket
Version: 0.10.7-1
Severity: grave
Tags: security upstream
X-Debbugs-Cc: Debian Security Team 

Hi,

The following vulnerability was published for ruby-faye-websocket.

CVE-2020-15133[0]:
| In faye-websocket before version 0.11.0, there is a lack of
| certification validation in TLS handshakes. The
| `Faye::WebSocket::Client` class uses the `EM::Connection#start_tls`
| method in EventMachine to implement the TLS handshake whenever a
| `wss:` URL is used for the connection. This method does not implement
| certificate verification by default, meaning that it does not check
| that the server presents a valid and trusted TLS certificate for the
| expected hostname. That means that any `wss:` connection made using
| this library is vulnerable to a man-in-the-middle attack, since it
| does not confirm the identity of the server it is connected to. For
| further background information on this issue, please see the
| referenced GitHub Advisory. Upgrading `faye-websocket` to v0.11.0 is
| recommended.


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-2020-15133
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-15133
[1] 
https://github.com/faye/faye-websocket-ruby/security/advisories/GHSA-2v5c-755p-p4gv
[2] https://github.com/faye/faye-websocket-ruby/pull/129
[3] https://blog.jcoglan.com/2020/07/31/missing-tls-verification-in-faye/

Regards,
Salvatore

Bug#967062: /lib/modules/4.19.0-10-amd64/kernel/drivers/gpu/drm/amd/amdgpu/amdgpu.ko: Only black screen after modeset when firmware is present

[Stephen Paul Weber]

Package: src:linux
Version: 4.19.132-1
Severity: important
File: /lib/modules/4.19.0-10-amd64/kernel/drivers/gpu/drm/amd/amdgpu/amdgpu.ko

Dear Maintainer,

After installing Debian 10, system booted and worked fine.  amdgpu was loaded.
Installed firmware-amd-graphics caused and rebooted: right after grub, upon
modeset, the display goes black (not no video, the display does not go to
sleep) and stays black until a power cycle.  System seems to boot fine, but
graphics are dead.

Booting with modprobe.blacklist=amdgpu works fine (that is how I am booted now)
-- running modprobe amdgpu causes display to immediately go black.  modprobe
amdgpu && sleep 1 && rmmod amdgpu the display also goes black and stays black,
no recovery.

Tried upgrading to the firmware package in testing, no change.

I have attached a kernel log from a boot where amdgpu was not blacklisted
(pulled from /var/log/kern.log after waiting and then power cycling to boot
with blacklisted again).



-- Package-specific info:
** Version:
Linux version 4.19.0-10-amd64 (debian-ker...@lists.debian.org) (gcc version 
8.3.0 (Debian 8.3.0-6)) #1 SMP Debian 4.19.132-1 (2020-07-24)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-4.19.0-10-amd64 
root=UUID=968ad1c1-b891-4f9f-b0c1-037f6f9d05ce ro modprobe.blacklist=amdgpu

** Not tainted

** Kernel log:
Unable to read kernel log; any relevant messages should be attached

** Model information
sys_vendor: Gigabyte Technology Co., Ltd.
product_name: A320M-S2H
product_version: Default string
chassis_vendor: Default string
chassis_version: Default string
bios_vendor: American Megatrends Inc.
bios_version: F50
board_vendor: Gigabyte Technology Co., Ltd.
board_name: A320M-S2H-CF
board_version: x.x

** Loaded modules:
ctr
ccm
fuse
arc4
appletalk
psnap
llc
ax25
edac_mce_amd
ccp
rng_core
kvm
irqbypass
crct10dif_pclmul
mt76x0
crc32_pclmul
mt76
snd_hda_codec_realtek
mac80211
snd_hda_codec_generic
ghash_clmulni_intel
uvcvideo
serio_raw
pcspkr
wmi_bmof
snd_hda_codec_hdmi
videobuf2_vmalloc
k10temp
videobuf2_memops
cfg80211
videobuf2_v4l2
videobuf2_common
snd_hda_intel
snd_usb_audio
snd_hda_codec
sp5100_tco
snd_hda_core
snd_usbmidi_lib
snd_hwdep
snd_rawmidi
snd_seq_device
videodev
snd_pcm
joydev
rfkill
snd_timer
snd
soundcore
media
sg
evdev
pcc_cpufreq
acpi_cpufreq
parport_pc
ppdev
lp
parport
ip_tables
x_tables
autofs4
ext4
crc16
mbcache
jbd2
crc32c_generic
fscrypto
ecb
sd_mod
hid_generic
usbhid
hid
crc32c_intel
xhci_pci
aesni_intel
aes_x86_64
crypto_simd
xhci_hcd
cryptd
glue_helper
ahci
libahci
libata
i2c_piix4
r8169
usbcore
realtek
scsi_mod
libphy
usb_common
wmi
thermal
video
gpio_amdpt
gpio_generic
button

** PCI devices:
00:00.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Raven/Raven2 
Root Complex [1022:15d0]
Subsystem: Advanced Micro Devices, Inc. [AMD] Raven/Raven2 Root Complex 
[1022:15d0]
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- 

00:01.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Family 17h 
(Models 00h-1fh) PCIe Dummy Host Bridge [1022:1452]
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- TAbort- Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: 
Kernel driver in use: pcieport

00:08.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Family 17h 
(Models 00h-1fh) PCIe Dummy Host Bridge [1022:1452]
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- TAbort- Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: 
Kernel driver in use: pcieport

00:08.2 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Raven/Raven2 
Internal PCIe GPP Bridge 0 to Bus B [1022:15dc] (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: 
Kernel driver in use: pcieport

00:14.0 SMBus [0c05]: Advanced Micro Devices, Inc. [AMD] FCH SMBus Controller 
[1022:790b] (rev 61)
Subsystem: Gigabyte Technology Co., Ltd FCH SMBus Controller [1458:5001]
Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap- 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- 
SERR- TAbort- 
SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- 

Bug#961814: Debian Bugs information: logs for Bug#961814

[Reinhard Tartler]

Thanks!

Will incorporate in the next upload.

Bug#967060: Wishlist: package calibre-plugins-extra

[Andrzej A. Filip]

Package: calibre
Version: 4.99.7+dfsg+really4.21.0-1
Severity: wishlist

A package with additional calibre plugins (e.g. calibre-plugins-extra) would be
nice.

Bug#619454: Init script missing

[Andreas Messer]

Hello again,

sorry, I'm stupid. This is not the same bug, will fill another ticket.


> Hello,

> I came across the same issue and found, that the the problem is
> changed behavior of 'dh_installinit'. The file 
>
> debian/lcdproc.init 
>
> should be renamed to
>
> debian/lcdproc.LCDd.init
>
> according to the man-page when using the --name argument.
>
> Hope that helps,

Regards,
Andreas


signature.asc
Description: PGP signature

Bug#966875: [Aptitude-devel] Bug#966875: aptitude: FTBFS: ../../../../src/generic/views/download_progress.cc:49:11: error: no match for ‘operator<<’ (operand types are ‘std::ostream’ {aka ‘std::basic_

[Axel Beckert]

Hi Lucas,

thanks for the bug report.

I first thought this seems to have changed with gcc 10.2 instead 10.1
since I had gcc 10 as default locally for quite while before it became
default. But at least my last local 0.8.13-1 build was done with still
gcc 9.

Also verified that it's not just an issue between gcc 10.1 and 10.2 by
downgrading gcc-10 and friends to 10.1.0-6 from testing: Didn't fix
this. So it might be a general FTBFS with gcc 10 — although I'm
surprised this didn't came up earlier.

Lucas Nussbaum wrote:
> Relevant part (hopefully):

Seems to boil down to these:

→ fgrep "no known conversion" ../aptitude_0.8.13-2_amd64.build | sort -u
../../../../src/generic/views/download_progress.cc:47:89: note:   no known 
conversion for argument 2 from ‘const char [10]’ to ‘const 
aptitude::views::download_progress::file_progress&’
../../../../src/generic/views/download_progress.cc:47:89: note:   no known 
conversion for argument 2 from ‘const char [17]’ to ‘const 
aptitude::views::download_progress::file_progress&’
../../../../src/generic/views/download_progress.cc:47:89: note:   no known 
conversion for argument 2 from ‘const char [18]’ to ‘const 
aptitude::views::download_progress::file_progress&’
../../../../src/generic/views/download_progress.cc:47:89: note:   no known 
conversion for argument 2 from ‘const char [2]’ to ‘const 
aptitude::views::download_progress::file_progress&’
../../../../src/generic/views/download_progress.cc:47:89: note:   no known 
conversion for argument 2 from ‘const char [3]’ to ‘const 
aptitude::views::download_progress::file_progress&’
../../../../src/generic/views/download_progress.cc:47:89: note:   no known 
conversion for argument 2 from ‘const char [6]’ to ‘const 
aptitude::views::download_progress::file_progress&’
../../../../src/generic/views/download_progress.cc:47:89: note:   no known 
conversion for argument 2 from ‘const char [7]’ to ‘const 
aptitude::views::download_progress::file_progress&’
../../../../src/generic/views/download_progress.cc:47:89: note:   no known 
conversion for argument 2 from ‘const long unsigned int’ to ‘const 
aptitude::views::download_progress::file_progress&’
../../../../src/generic/views/download_progress.cc:97:63: note:   no known 
conversion for argument 2 from ‘const char [18]’ to ‘const 
aptitude::views::download_progress::status&’
../../../../src/generic/views/download_progress.cc:97:63: note:   no known 
conversion for argument 2 from ‘const char [2]’ to ‘const 
aptitude::views::download_progress::status&’
../../../../src/generic/views/download_progress.cc:97:63: note:   no known 
conversion for argument 2 from ‘const char [3]’ to ‘const 
aptitude::views::download_progress::status&’
../../../../src/generic/views/download_progress.h:271:63: note:   no known 
conversion for argument 2 from ‘const char [10]’ to ‘const 
aptitude::views::download_progress::status&’
../../../../src/generic/views/download_progress.h:271:63: note:   no known 
conversion for argument 2 from ‘const char [17]’ to ‘const 
aptitude::views::download_progress::status&’
../../../../src/generic/views/download_progress.h:271:63: note:   no known 
conversion for argument 2 from ‘const char [2]’ to ‘const 
aptitude::views::download_progress::status&’
../../../../src/generic/views/download_progress.h:271:63: note:   no known 
conversion for argument 2 from ‘const char [6]’ to ‘const 
aptitude::views::download_progress::status&’
../../../../src/generic/views/download_progress.h:271:63: note:   no known 
conversion for argument 2 from ‘const char [7]’ to ‘const 
aptitude::views::download_progress::status&’
../../../../src/generic/views/download_progress.h:271:63: note:   no known 
conversion for argument 2 from ‘const long unsigned int’ to ‘const 
aptitude::views::download_progress::status&’

And this seems to be the hints what might help:

→ fgrep "candidate" ../aptitude_0.8.13-2_amd64.build | sort -u
../../../../src/generic/views/download_progress.cc:47:19: note: candidate: 
‘std::ostream& aptitude::views::operator<<(std::ostream&, const 
aptitude::views::download_progress::file_progress&)’
../../../../src/generic/views/download_progress.cc:96:19: note: candidate: 
‘std::ostream& aptitude::views::operator<<(std::ostream&, const 
aptitude::views::download_progress::status&)’
../../../../src/generic/views/download_progress.h:270:19: note: candidate: 
‘std::ostream& aptitude::views::operator<<(std::ostream&, const 
aptitude::views::download_progress::status&)’
/usr/include/c++/10/bits/basic_string.h:6458:5: note: candidate: 
‘template std::basic_ostream<_CharT, 
_Traits>& std::operator<<(std::basic_ostream<_CharT, _Traits>&, const 
std::__cxx11::basic_string<_CharT, _Traits, _Allocator>&)’
/usr/include/c++/10/bits/shared_ptr.h:69:5: note: candidate: ‘template 
std::basic_ostream<_CharT, _Traits>& std::operator<<(std::basic_ostream<_CharT, 
_Traits>&, const std::__shared_ptr<_Tp, _Lp>&)’
/usr/include/c++/10/cstddef:125:5: note: candidate: ‘template constexpr 

Bug#967058: Init script missing

[Andreas Messer]

Package: lcdproc
Version: 0.5.9-4

The init script /etc/init.d/LCDd is missing. 

Hello,

I think  the problem is changed behavior of 'dh_installinit'. The file 

debian/lcdproc.init 

should be renamed to

debian/lcdproc.LCDd.init

according to the man-page when using the --name argument.


Cheers, 
Andreas
-- 
gnuPG keyid: 8C2BAF51
fingerprint: 28EE 8438 E688 D992 3661 C753 90B3 BAAA 8C2B AF51


signature.asc
Description: PGP signature

Bug#967007: Now dependencies are satisfied

[Pirate Praveen]

Control: tags -1 pending

On Mon, Aug 3, 2020 at 23:31, Pirate Praveen  
wrote:
After skipping check for nodejs and yarn version checks in 
ruby-webpacker, I get this error. This looks like a bug in 
ruby-webpacker, it may be missing the required files in the binary 
package.


This was fixed in ruby-webpacker 4.2.2-3. Now the autopkgtest is 
passing.


It took almost a whole day to troubleshoot and fix this.

Bug#967059: lintian: Do not issue package-contains-no-arch-dependent-files for packages with arch-dependent dependencies

[Peter Wienemann]

Package: lintian
Version: 2.86.0
Severity: normal

Dear Lintian maintainers,

Lintian issues the tag package-contains-no-arch-dependent-files on
packages without "Architecture: all" if they only contain
architecture-independent files (at least this is my understanding).
That is fine unless they have architecture-dependent dependencies
(i. e. arch-dependent "Depends:" entries). In the latter case making
the package architecture-dependent is required to implement
architecture-dependent dependencies even though the package contents
is purely architecture-independent (see Debian Policy Manual
section 7.1).

Best regards,

Peter

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

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

Bug#619454: Init script missing

[Andreas Messer]

Hello,

I came across the same issue and found, that the the problem is
changed behavior of 'dh_installinit'. The file 

debian/lcdproc.init 

should be renamed to

debian/lcdproc.LCDd.init

according to the man-page when using the --name argument.

Hope that helps,

Cheers, 
Andreas
-- 
gnuPG keyid: 8C2BAF51
fingerprint: 28EE 8438 E688 D992 3661 C753 90B3 BAAA 8C2B AF51


signature.asc
Description: PGP signature

Bug#966640: build-depends: debhelper-compat (= 13) cannot be satisfied

[Sam Hartman]

> "rharwood" == rharwood   writes:

rharwood> In debian/control, you list the dependency as:

rharwood> Build-Depends: debhelper-compat (= 13)

rharwood> Could it be because 13 != 13.2 ?

No, for a while now virtual packages can be provided at a specific
version.
from apt-cache show debhelper, I see:

Provides: debhelper-compat (= 9), debhelper-compat (= 10),
debhelper-compat (= 11), debhelper-co
mpat (= 12), debhelper-compat (= 13), dh-sequence-dwz,
dh-sequence-elf-tools, dh-sequence-instal
linitramfs, dh-sequence-systemd 
   


I can reproduce your issue with aptitude but not with apt-get.
Which admittedly is surprising because in the past the aptitude resolver
has been better than the apt resolver.
But apparently it does not deal with provides of versioned packages.

The krb5 package is following the recommended syntax in the debhelper
manual.
Given that, I think it's reasonable for aptitude build-dep to be
expected to handle modern debhelper dependencies, so I think you've
found an aptitude bug.

Bug#967007: Now dependencies are satisfied

[Pirate Praveen]

On Mon, Aug 3, 2020 at 21:43, Pirate Praveen  
wrote:
This seems strange as rails metapackage has a dependency on webpack, 
and yarnpkg which should pull nodejs.


After skipping check for nodejs and yarn version checks in 
ruby-webpacker, I get this error. This looks like a bug in 
ruby-webpacker, it may be missing the required files in the binary 
package.


+ rake --trace webpacker:install
** Invoke webpacker:install (first_time)
** Invoke webpacker:check_node (first_time)
** Execute webpacker:check_node
Node.js version is v12.18.2
** Invoke webpacker:check_yarn (first_time)
** Execute webpacker:check_yarn
Yarn version is 1.22.4
** Execute webpacker:install
  identical  config/webpacker.yml
Copying webpack core config
  exist  config/webpack
  identical  config/webpack/development.js
  identical  config/webpack/environment.js
  identical  config/webpack/production.js
  identical  config/webpack/test.js
Copying postcss.config.js to app root directory
  identical  postcss.config.js
Copying babel.config.js to app root directory
  identical  babel.config.js
Copying .browserslistrc to app root directory
rails aborted!
Thor::Error: Could not find 
"/usr/share/rubygems-integration/all/gems/webpacker-4.2.2/lib/install/config/.browserslistrc" 
in any of your source paths.

Bug#967057: pmdk: FTBFS on arm64, ppc64el, due to test failure

[Andreas Hasenack]

Package: pmdk
Version: 1.9-1
Severity: normal

Dear Maintainer,

pmdk 1.9-1 fails to build on arm64 and ppc64el because at least this
build-time test fails:

obj_ctl_arenas/TEST3: SETUP (check/pmem/debug/drd)
obj_ctl_arenas/TEST3 failed with Valgrind. See drd3.log. Last 20 lines below.
obj_ctl_arenas/TEST3 drd3.log ==3225==by 0x4A0BD2B: thread_start
(clone.S:78)
obj_ctl_arenas/TEST3 drd3.log ==3225== Other segment start (thread 7)
obj_ctl_arenas/TEST3 drd3.log ==3225==at 0x4A0BD00: clone (clone.S:63)
obj_ctl_arenas/TEST3 drd3.log ==3225==by 0x490D197: create_thread
(createthread.c:101)
obj_ctl_arenas/TEST3 drd3.log ==3225==by 0x: ???
obj_ctl_arenas/TEST3 drd3.log ==3225== Other segment end (thread 7)
obj_ctl_arenas/TEST3 drd3.log ==3225==at 0x499E190: fputs (iofputs.c:41)
obj_ctl_arenas/TEST3 drd3.log ==3225==by 0x4883ADF: out_print_func
(out.c:279)
obj_ctl_arenas/TEST3 drd3.log ==3225==by 0x4883FB3: out_common (out.c:397)
obj_ctl_arenas/TEST3 drd3.log ==3225==by 0x488465F: out_log (out.c:530)
obj_ctl_arenas/TEST3 drd3.log ==3225==by 0x48C4917:
pmemobj_ctl_execU (obj.c:3312)
obj_ctl_arenas/TEST3 drd3.log ==3225==by 0x48C4A4F:
pmemobj_ctl_exec (obj.c:3349)
obj_ctl_arenas/TEST3 drd3.log ==3225==by 0x10B973:
worker_arenas_flag (obj_ctl_arenas.c:151)
obj_ctl_arenas/TEST3 drd3.log ==3225==by 0x4850987: ??? (in
/usr/lib/aarch64-linux-gnu/valgrind/vgpreload_drd-arm64-linux.so)
obj_ctl_arenas/TEST3 drd3.log ==3225==by 0x490E627: start_thread
(pthread_create.c:477)
obj_ctl_arenas/TEST3 drd3.log ==3225==by 0x4A0BD2B: thread_start
(clone.S:78)
obj_ctl_arenas/TEST3 drd3.log ==3225==
obj_ctl_arenas/TEST3 drd3.log ==3225==
obj_ctl_arenas/TEST3 drd3.log ==3225== For lists of detected and
suppressed errors, rerun with: -s
obj_ctl_arenas/TEST3 drd3.log ==3225== ERROR SUMMARY: 20942 errors
from 7 contexts (suppressed: 36867 from 89)
RUNTESTS: stopping: obj_ctl_arenas/TEST3 failed, TEST=check FS=any BUILD=debug

This can be seen in
https://buildd.debian.org/status/fetch.php?pkg=pmdk=arm64=1.9-1=1595322804=0
for arm64, and 
https://buildd.debian.org/status/fetch.php?pkg=pmdk=ppc64el=1.9-1=159531=0
for ppc64el.

The same failure happens in Ubuntu groovy.

I filed this issue upstream: https://github.com/pmem/pmdk/issues/4926

Bug#967056: ecryptfs-utils: The first login with password after boot will increment the mount count by two.

[Mad Horse]

Package: ecryptfs-utils
Version: 111-5
Severity: important

Dear Maintainer,

0) Use ecryptfs-setup-private to setup a Private directory in a user
account.

1) After a fresh boot, the first login authenticated with the password
to that
user account (either via gdm3, via console, or via ssh), increments the
mount
count in /dev/shm/ecryptfs-$USER-private by 2 instead of 1, and logging
out will
only decrement it by 1. Currently I handle it by manually executing
$ ecryptfs-umount-private (to decrement the mount count by 1) before logout,
otherwise it will leave the Private directory accessible after logout.

2) After this, all subsequent logins with password (either via gdm3, via
console, or via ssh) will only increment the mount count by 1. (Besides,
logins
without password, such as via ssh authenticated with a public key, will not
increment mount count. Accessing Private in such situation should be done by
manually executing $ ecryptfs-mount-private and providing password, and
mount
count will be decremented by one when logging out from this session.)

3) No matter how many logins without password, during which manually
mounting
Private may or may not occur, precede it, only "the first login with
password"
increments the mount count by 2.

I suspect this issue appears because "session optional pam_ecryptfs.so
unwrap"
is present both in /etc/pam.d/common-session-noninteractive and in
/etc/pam.d/common-session. The former acts on the first login,
(via "systemd --user") while the latter acts on every interactive login. If
password is available when they act, mount count will all increment by 1
each
time.

Further inspection shows that "systemd --user" is launched by the first
login,
either with or without password, and continue to run after logout, but
in "the
first login with password", the process tree with "systemd --user" as
its root
launched by the first login without password will be replaced with a new
launch
of "systemd --user", which will never be replaced any more during all
subsequent
logins.




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

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

Versions of packages ecryptfs-utils depends on:
ii gettext-base 0.19.8.1-10
ii keyutils 1.6.1-2
ii libc6 2.31-2
ii libecryptfs1 111-5
ii libgpgme11 1.13.1-9
ii libkeyutils1 1.6.1-2
ii libpam-runtime 1.3.1-5
ii libpam0g 1.3.1-5
ii libtspi1 0.3.14+fixed1-1+b1

ecryptfs-utils recommends no packages.

Versions of packages ecryptfs-utils suggests:
ii cryptsetup 2:2.3.3-1+b1
ii rsync 3.2.2-2

-- no debconf information

Bug#957151: drbd-utils: ftbfs with GCC-10

[Lucas Kanashiro]

Hi,

I submitted a merge request here to fix the FTBFS with GCC-10:

https://salsa.debian.org/ha-team/drbd-utils/-/merge_requests/6

Thanks for considering the patch!

-- 
Lucas Kanashiro

Bug#967055: TAG: PostgREST -- a standalone web server that turns your PostgreSQL database directly into a RESTful API

[Jérôme Bardot]

Package: wnpp
Severity: RFP

Hello,

I think it can be great to have http://postgrest.org/en/v7.0.0/ in debian.
It supports openApi and postgresql in order to provide a direct Rest
api for postgresql databases.

J.

hope i did the right thing for the wnpp

Bug#943610: 10 van uw nieuwe inkomende berichten zijn opgeschort voor toegang tot uw e-mailboxaccount

[Almerinda Duarte]

MICROSOFT DRINGEND MELDING MEMO

10 van uw nieuwe inkomende berichten zijn opgeschort voor toegang tot uw 
e-mailboxaccount omdat uw e-mailboxaccount al enkele maanden niet is 
geverifieerd. Verifieerdaarom onmiddellijk 
zodat al uw nieuwe inkomende berichten nu aan u kunnen worden vrijgegeven.


Bedankt voor uw begrip.


Microsoft-verificatieteam


Microsoft Outlook Copyright © 2020 .Inc. Alle rechten voorbehouden.

Bug#964858: Uploaded to unstable

[Martin Pitt]

Hello Reinhard,

Reinhard Tartler [2020-08-03 13:04 -0400]:
> I've uploaded 2.0.18 that I slated for experimental to unstable after some
> light testing with the 2.0.4 common package, and it seems to work fine.

Thanks, appreciated! Indeed I gave conmon 2.0.18 + podman 2.0.4 a thorough
testing today, and that fixes `podman exec. And lo and behold, it made *all*
cockpit-podman tests green: \o/

  
https://logs.cockpit-project.org/logs/pull-480-20200803-115505-90f29ffd-debian-testing/log.html

(That one retry is unrelated).

Martin

Bug#964795: Tag for 3.9.10 release ( just fyi )

[crvi c]

https://gitlab.gnome.org/GNOME/libdmapsharing/-/tags/LIBDMAPSHARING_3_9_10

Thanks !

Bug#961814: Debian Bugs information: logs for Bug#961814

[Reinhard Tartler]

On Mon, Aug 3, 2020 at 8:30 AM Shengjing Zhu  wrote:

> If I read the comments in upstream issue correctly, it will be solved in 2
> months (they said 6 months later at April). What's the urgent thing we need
> to address in this two months?
>

I realized that podman 2.0 requires this newer version of protobuf. I've
changed podman to vendor the sources for now. Urgency is in the eye of the
beholder, I guess.

It just seems weird to me to not be able to use this package until this bug
is addressed.

-rt

Bug#967054: RM: python-omniorb -- RoQA; Depends on Python 2, unmaintained, leaf package

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Please remove python-omniorb. It depends on Python 2 and the last maintainer 
upload
was in 2011. It's dropped from testing for over two years and there are no 
reverse
deps remaining.

Cheers,
Moritz

Bug#937490: pynifti: Python2 removal in sid/bullseye

[Moritz Mühlenhoff]

On Mon, Aug 03, 2020 at 07:39:12AM +0200, Michael Hanke wrote:
> Hi,
> 
> On Sun, Aug 2, 2020, 23:47 Moritz Mühlenhoff  wrote:
> 
> > On Fri, Jul 10, 2020 at 01:08:44PM +0200, Andreas Tille wrote:
> > > On Mon, Jun 29, 2020 at 08:37:58PM +0200, Moritz Mühlenhoff wrote:
> > > > On Fri, Aug 30, 2019 at 07:34:39AM +, Matthias Klose wrote:
> > > >
> > > > The upstream homepage states
> > > >
> > > > | PyNIfTI is no longer actively developed. At has been
> > > > | superseded by NiBabel -- a pure-Python package that
> > > > | provides everything that PyNIfTI could do, and a lot more.
> > > >
> > > > Given that nibabel is packaged, let's simply remove pynifti?
> > >
> > > Same answer from my side as for mrtrix - from my point of
> > > view it can go.
> >
> > Michael/Yaroslav, ping. Ack to remove pynifti from your end?
> 
> Yes, it can go. Thx.

Ack, I've just filed an RM bug.

Cheers,
Moritz

Bug#967053: RM: pynifti -- RoQA; Replaced by nibabel, Python 2

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Please remove pynifti. It depends on Python 2 and has been replaced
by nibabel. Acked by the maintainers in #937490.

Cheers,
Moritz

Bug#967029: reportbug: ThinkPad E595 trackpoint physical buttons stopped working after ipp-usb upgrade on 08/01

[bebyx]

Package: reportbug
Version: 7.7.0
Severity: important
Tags: upstream
X-Debbugs-Cc: be...@protonmail.com

Dear Maintainer,

I made a routine upgrade on 08/01, since then my trackpoint physical buttons
stopped working.

Laptop model: Lenovo ThinkPad E595 20NF001YRT

OS: Debian GNU/Linux bullseye/sid x86_64

Desktop: Gnome 3.36.4 Wayland

08/01 update:

Start-Date: 2020-08-01  12:24:10
Commandline: apt upgrade -y
Install: ipp-usb:amd64 (0.9.10-2, automatic)
Upgrade: libqmi-proxy:amd64 (1.26.0-0.1, 1.26.2-0.1), exim4-base:amd64 (4.94-6,
4.94-7), libdevmapper1.02.1:amd64 (2:1.02.167-1+b1, 2:1.02.171-1),
dmsetup:amd64 (2:1.02.167-1+b1, 2:1.02.171-1), libcups2:amd64 (2.3.3-1,
2.3.3-2), libsystemd0:amd64 (245.6-2, 245.7-1), libqmi-glib5:amd64 (1.26.0-0.1,
1.26.2-0.1), python3-pysimplesoap:amd64 (1.16.2-2, 1.16.2-3), node-pump:amd64
(3.0.0-3, 3.0.0-4), exim4-daemon-light:amd64 (4.94-6, 4.94-7), udev:amd64
(245.6-2, 245.7-1), cups-server-common:amd64 (2.3.3-1, 2.3.3-2), libnss-
mymachines:amd64 (245.6-2, 245.7-1), cups-common:amd64 (2.3.3-1, 2.3.3-2),
libudev1:amd64 (245.6-2, 245.7-1), systemd-timesyncd:amd64 (245.6-2, 245.7-1),
cups-ppdc:amd64 (2.3.3-1, 2.3.3-2), exim4-config:amd64 (4.94-6, 4.94-7),
libnss-myhostname:amd64 (245.6-2, 245.7-1), systemd-sysv:amd64 (245.6-2,
245.7-1), libpam-systemd:amd64 (245.6-2, 245.7-1), systemd:amd64 (245.6-2,
245.7-1), libwebkit2gtk-4.0-37:amd64 (2.28.3-2, 2.28.4-1), libnss-systemd:amd64
(245.6-2, 245.7-1), gir1.2-webkit2-4.0:amd64 (2.28.3-2, 2.28.4-1), systemd-
container:amd64 (245.6-2, 245.7-1), cups-bsd:amd64 (2.3.3-1, 2.3.3-2), cups-
core-drivers:amd64 (2.3.3-1, 2.3.3-2), bison:amd64 (2:3.6.3+dfsg-1,
2:3.7+dfsg-1), cups-daemon:amd64 (2.3.3-1, 2.3.3-2), libcupsimage2:amd64
(2.3.3-1, 2.3.3-2), cups:amd64 (2.3.3-1, 2.3.3-2), cups-client:amd64 (2.3.3-1,
2.3.3-2), libjavascriptcoregtk-4.0-18:amd64 (2.28.3-2, 2.28.4-1), cups-ipp-
utils:amd64 (2.3.3-1, 2.3.3-2), nfs-common:amd64 (1:1.3.4-3, 1:1.3.4-4),
gir1.2-javascriptcoregtk-4.0:amd64 (2.28.3-2, 2.28.4-1)
End-Date: 2020-08-01  12:25:13

dmidecode -t 21 output:

# dmidecode 3.2
Getting SMBIOS data from sysfs.
SMBIOS 3.1.1 present.

Handle 0x0032, DMI type 21, 7 bytes
Built-in Pointing Device
   Type: Track Point
   Interface: PS/2
   Buttons: 3

Handle 0x0033, DMI type 21, 7 bytes
Built-in Pointing Device
   Type: Touch Pad


That's really weird, ipp-usb doesn't seem to be connected with trackpoint,
libinput whatsoever.

Also I noticed that my brightness became somewhat broken, since the 08/01
update it always defaults to max brightness after restart.



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

** /home/bebyx/.reportbugrc:
reportbug_version "7.7.0"
mode standard
ui gtk
email "be...@protonmail.com"
no-cc
list-cc-me
smtphost reportbug.debian.org

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

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

Versions of packages reportbug depends on:
ii  apt2.1.7
ii  python33.8.2-3
ii  python3-reportbug  7.7.0
ii  sensible-utils 0.0.12+nmu1

reportbug recommends no packages.

Versions of packages reportbug suggests:
pn  claws-mail 
pn  debconf-utils  
pn  debsums
pn  dlocate
pn  emacs-bin-common   
ii  exim4-daemon-light [mail-transport-agent]  4.94-7
ii  file   1:5.38-5
ii  gnupg  2.2.20-1
pn  python3-urwid  
pn  reportbug-gtk  
ii  xdg-utils  1.1.3-2

Versions of packages python3-reportbug depends on:
ii  apt2.1.7
ii  file   1:5.38-5
ii  python33.8.2-3
ii  python3-apt2.1.3
ii  python3-debian 0.1.37
ii  python3-debianbts  3.0.2
ii  python3-requests   2.23.0+dfsg-2
ii  sensible-utils 0.0.12+nmu1

python3-reportbug suggests no packages.

-- no debconf information

Bug#964794: Update works fine in SID

[crvi c]

Tested libdmapsharing-3.0-2 ( 2.9.41-2 ) to work fine in debian SID.

Bug can be closed.

Bug#966640: build-depends: debhelper-compat (= 13) cannot be satisfied

[rharwood]

Source: krb5
Followup-For: Bug #966640

> 13 is the current compatibility level and is provided by the debhelper
> package.  I think there's something missing from your environment.  Could it
> be Debian stable instead of unstable, for example?  If so, you'll need to
> enable backports to get a current debhelper if you want to build the
> unstable version of krb5.

Hi, no, my system information is as reportbug put it in the footer - testing
with unstable and experimental available.

Some more information:

rharwood@eesha:~$ aptitude versions debhelper
i A 13.2 testing,unstable 700 
rharwood@eesha:~$ aptitude show debhelper-compat
No candidate version found for debhelper-compat
Package: debhelper-compat
State: not a real package
Provided by: debhelper (13.2), debhelper (13.2), debhelper (13.2), 
debhelper (13.2), debhelper (13.2)
rharwood@eesha:~$ sudo aptitude install debhelper=13
Unable to find a version "13" for the package "debhelper"
Unable to apply some actions, aborting
rharwood@eesha:~$ sudo aptitude install debhelper=13.2
debhelper is already installed at the requested version (13.2)
debhelper is already installed at the requested version (13.2)
No packages will be installed, upgraded, or removed.
0 packages upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 0 B of archives. After unpacking 0 B will be used.

rharwood@eesha:~$ 

In debian/control, you list the dependency as:

Build-Depends: debhelper-compat (= 13)

Could it be because 13 != 13.2 ?

Thanks,
--Robbie

Bug#964858: Uploaded to unstable

[Reinhard Tartler]

Hi,

I've uploaded 2.0.18 that I slated for experimental to unstable after some
light testing with the 2.0.4 common package, and it seems to work fine.

Thanks for the ping, Martin!

-- 
regards,
Reinhard

Bug#966459: linux: traffic class socket options (both IPv4/IPv6) inconsistent with docs/standards

[Thorsten Glaser]

Hi Ben,

> For what it's worth, FreeBSD/Darwin and Windows also put 4 bytes of
> data in a IPV6_TCLASS cmsg.  So whether or not it's "right", it's
> consistent between three independent implementations.

oh, thank you, I don’t have any of these systems around at the
moment, so checking them was tricky for me.

So basically I should read an int in host endianness then (or
keep the code I currently have that compares byte 0 and 3, using
the one that’s not 0, if any). Great, thank you!

After some minor porting work, it turns out that the current code
does work on MidnightBSD (equivalent to FreeBSD 10.4) for IPv6.
I guess I’ll keep ints then.

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

Bug#967052: live-boot: fixed handling of plymouth LUKS retry prompt

[Ronny Standtke]

Package: live-boot
Version: 1:20190614
Severity: normal
Tags: patch

When using a LUKS encrypted persistence partition and mistyping the
password, the plymouth retry prompt doesn't get deleted after answering.
The attached patch fixes this issue.

Best regards

Ronny
From 7b6d961d0bbabcc43385e092f4e25ce76b2d0c2e Mon Sep 17 00:00:00 2001
From: Ronny Standtke 
Date: Mon, 3 Aug 2020 18:35:33 +0200
Subject: [PATCH] delete plymouth retry promt after answer

---
 components/9990-misc-helpers.sh | 7 +--
 1 file changed, 1 insertion(+), 6 deletions(-)

diff --git a/components/9990-misc-helpers.sh b/components/9990-misc-helpers.sh
index 7994ecd..6ccdbc3 100755
--- a/components/9990-misc-helpers.sh
+++ b/components/9990-misc-helpers.sh
@@ -902,6 +902,7 @@ open_luks_device ()
 			true)
 plymouth display-message --text "${retryprompt}"
 answer=$(plymouth watch-keystroke --keys="YNyn")
+plymouth display-message --text ""
 ;;

 			*)
@@ -912,12 +913,6 @@ open_luks_device ()

 		if [ "$(echo "${answer}" | cut -b1 | tr A-Z a-z)" = "n" ]
 		then
-			case "${_PLYMOUTH}" in
-true)
-	plymouth display-message --text ""
-	;;
-			esac
-
 			return 2
 		fi
 	done
--
2.27.0

Bug#966544: Switching from extend to pass for custom endpoints

[Ian Campbell]

Hi all,

I switched from pass to extend for my custom endpoint since the latter
was not disabled with the security update. It's a bit more faff but not
intractable (just lots of boilerplate really) so maybe it's useful to
post here as a sort of recipe while things get sorted out some other
way in the packaging.

I went from snmpd.conf with (nb: /var/run/qcontrol.temp simply contains
a single integer value, nothing fancy, it's updated elsewhere):

   extend .1.3.6.1.4.1.65535.1 - /bin/cat /var/run/qcontrol.temp

To one with:

   pass .1.3.6.1.4.1.65535.1 /bin/bash /etc/snmp/qcontrol-mib

Where /etc/snmp/qcontrol-mib is:

   #!/bin/bash

   # https://sourceforge.net/p/net-snmp/code/ci/master/tree/local/passtest

PLACE=".1.3.6.1.4.1.65535.1"
OP="$1"
REQ="$2"

case "$OP" in
"-s") # SET
OP="SET"
logger -p daemon.debug "qcontrol-mib: $OP $REQ: ignored"
exit 0
;;
"-n") # GETNEXT
OP="GETNEXT"
case "$REQ" in
$PLACE|$PLACE.0|$PLACE.0.*|$PLACE.1) RET="$PLACE.1.0" ;;
*) exit 0 ;; # Nothing after this
esac
;;
"-g") # GET
OP="GET"
case "$REQ" in
$PLACE.1.0) RET="$REQ" ;;
*)
logger -p daemon.warn "qcontrol-mib: $OP $REQ: unknown"
exit 0
;;
esac
;;
esac

# GET and GETNEXT
logger -p daemon.debug "qcontrol-mib: $OP $REQ: OK"
echo "$RET"
case "$RET" in
$PLACE.1.0) echo "integer" ; printf "%d\n" $(cat /var/run/qcontrol.temp);;
esac

These were moderately useful resources:

   http://www.net-snmp.org/docs/man/snmpd.conf.html (see: MIB-Specific 
Extension Commands)
   
http://net-snmp.sourceforge.net/wiki/index.php/Tut:Extending_snmpd_using_shell_scripts
https://sourceforge.net/p/net-snmp/code/ci/master/tree/local/passtest

For people who want persistent_pass instead this looked like a good
resource but I didn't follow it myself since my needs were so trivial:
   https://vincent.bernat.ch/en/blog/2012-extending-netsnmp

That has links to Perl and Python helper libraries which I think you'd
likely want to use if you wanted multiple values since plumbing the
GETNEXT stuff together manually in the simple shell script case as
above would be fairly tedious.

HTH someone,
Ian.

Bug#945673: closed by Debian FTP Masters (reply to Vincent Bernat ) (Bug#966735: fixed in fvwm-crystal 3.4.1+dfsg-2)

[Sandro Tosi]

Adrian, now people are closing these bugs thinking they are handling
the py2unversioned requests while they are also closing the py2removal
bugs, because you decided to merge them! While your intentions may
have been good, this was a mistake (as the 2 requests are *not* the
same) that will cause great consequences in tracking and handling the
py2removal process.

Now please: unmerge all the bugs you merged; close the ones that need
to be closed and leave the ones still pending open; next time make
sure to coordinate further action on the python2 removal process with
debian-python@ first

Regards,
Sandro

On Mon, Aug 3, 2020 at 3:21 AM Debian Bug Tracking System
 wrote:
>
> This is an automatic notification regarding your Bug report
> which was filed against the src:fvwm-crystal package:
>
> #945673: fvwm-crystal: Python2 removal in sid/bullseye
>
> It has been closed by Debian FTP Masters  
> (reply to Vincent Bernat ).
>
> Their explanation is attached below along with your original report.
> If this explanation is unsatisfactory and you have not received a
> better one in a separate message then please contact Debian FTP Masters 
>  (reply to Vincent Bernat 
> ) by
> replying to this email.
>
>
> --
> 966735: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=966735
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>
>
>
> -- Forwarded message --
> From: Debian FTP Masters 
> To: 966735-cl...@bugs.debian.org
> Cc:
> Bcc:
> Date: Mon, 03 Aug 2020 07:18:57 +
> Subject: Bug#966735: fixed in fvwm-crystal 3.4.1+dfsg-2
> Source: fvwm-crystal
> Source-Version: 3.4.1+dfsg-2
> Done: Vincent Bernat 
>
> We believe that the bug you reported is fixed in the latest version of
> fvwm-crystal, which is due to be installed in the Debian FTP archive.
>
> A summary of the changes between this version and the previous one is
> attached.
>
> Thank you for reporting the bug, which will now be closed.  If you
> have further comments please address them to 966...@bugs.debian.org,
> and the maintainer will reopen the bug report if appropriate.
>
> Debian distribution maintenance software
> pp.
> Vincent Bernat  (supplier of updated fvwm-crystal package)
>
> (This message was generated automatically at their request; if you
> believe that there is a problem with it please contact the archive
> administrators by mailing ftpmas...@ftp-master.debian.org)
>
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Format: 1.8
> Date: Mon, 03 Aug 2020 08:19:33 +0200
> Source: fvwm-crystal
> Architecture: source
> Version: 3.4.1+dfsg-2
> Distribution: unstable
> Urgency: medium
> Maintainer: Vincent Bernat 
> Changed-By: Vincent Bernat 
> Closes: 966735
> Changes:
>  fvwm-crystal (3.4.1+dfsg-2) unstable; urgency=medium
>  .
>* d/control: B-D on python2 (Closes: #966735)
>* d/control: use debhelper-compat
>* d/NEWS: rename from d/NEWS.Debian to d/NEWS
>* d/control: update Vcs-* fields
>* d/lintian: remove unused overrides
>* d/NEWS: fix versions
> Checksums-Sha1:
>  5ff090b87289858f3698cf77db5569fd286e3ab5 1976 fvwm-crystal_3.4.1+dfsg-2.dsc
>  3dddca9fe374bead4a9c4a8d6bfb726b6e3a9f4a 5452811 
> fvwm-crystal_3.4.1+dfsg.orig.tar.gz
>  3bf38052669fc15a37a0aae502a1cba40dc64fe1 10312 
> fvwm-crystal_3.4.1+dfsg-2.debian.tar.xz
>  9e4b0f36ce25a0259c6d1239da6c24a6139a6470 6079 
> fvwm-crystal_3.4.1+dfsg-2_amd64.buildinfo
> Checksums-Sha256:
>  752723b94db598ba4ac9196ba2e9e3ebf5d4b72ba764f937c7665abf5d473593 1976 
> fvwm-crystal_3.4.1+dfsg-2.dsc
>  7f0c2fe738d6c3ef37834a051baeafc5170feb9b10b1fb3ee0472727e574d6e4 5452811 
> fvwm-crystal_3.4.1+dfsg.orig.tar.gz
>  5871097d52d67a81dbaa26fd5c99ec1c1e203e747ab5568ce674673f68ae453f 10312 
> fvwm-crystal_3.4.1+dfsg-2.debian.tar.xz
>  cfea15a2d05698f1b637ce2efa19e420a5ab191ae5d58056d1cee49a21677595 6079 
> fvwm-crystal_3.4.1+dfsg-2_amd64.buildinfo
> Files:
>  7b8798dfa1afc44c1513a504c9c71deb 1976 x11 optional 
> fvwm-crystal_3.4.1+dfsg-2.dsc
>  b6d0bae13067d6422388ba25bbaa55f9 5452811 x11 optional 
> fvwm-crystal_3.4.1+dfsg.orig.tar.gz
>  4086fa2d763c785d4ee9ce284cbe5cbc 10312 x11 optional 
> fvwm-crystal_3.4.1+dfsg-2.debian.tar.xz
>  0d30296045e833d262b839790c17ffc5 6079 x11 optional 
> fvwm-crystal_3.4.1+dfsg-2_amd64.buildinfo
>
> -BEGIN PGP SIGNATURE-
>
> iQJGBAEBCAAwFiEErvI0h2bzccaJpzYAlaQv6DU1JfkFAl8ntv4SHGJlcm5hdEBk
> ZWJpYW4ub3JnAAoJEJWkL+g1NSX5MC4P/RY9Y14OtcX0K29DW11ilVmqXVTiSbFU
> z5POkTIL3whKWpHRg/ZQbYrkDEwfJAlsuA83s5ZCH0NY1Xcj5BG0wxH509Qrcora
> nQpXGINbq9nHpU1GH1QBobVI0aC4ZqHqpNuKcvAPnGlhR9nEeckq9OO00LELwjPN
> 70PK37kvYZZl8PQ9eA/3qyvTPrBwshtVzSnWtRHRRxq0VsJAWcBlVOi/lMA89m+i
> 8LS7d2gtP1DPd2NKIx8waKGUX4trgGxH2Bak555IvE94AYQiqi8QJ5DNGe5wXYOD
> fBydh/MZcDSVxnnoNgeVOiZsJZHOP525iEO4/SQdesDx8fLX2PneVXB4rPRASp5U
> YM6knUq1enrFINEc4wpiM4qMnC1ZsugeHFLdWu+/tFwwZaPa6+g6/9/eVtQ53OrL
> 1Xc/YyB3EKCKJcq3iSIVuStvBP511UE3H3JZNxhyT+6/IlbvjOfXw0Rw64tKgkUF
> 0uzUXRvrK/NoHn+YFxNkxXJManHtiicYg5du5Tg2ebm25J+IMFkHvMxPbs5GF5LG
> 

Bug#964446: sane-airscan stuck in NEW

[Till Kamppeter]

sane-airscan got uploaded something like 3 weeks ago and is still stuck 
in NEW. What is happening? What is missing?


OdyX, as I like to add sane-airscan to Ubuntu 20.10 and it will most 
probably not get into unstable in time before Ubuntu's Feature Freeze on 
August 27, I would like to ask you whether you could send me the source 
files of your package (current version, 9.99.10-1, tarball, dsc, 
debian.tar.gz) and/or tell me whether there is a GIT repo for the packaging.


Thanks in advance.

   Till

Bug#966828: emacs: Fatal error 11: Segmentation fault

[Adrian Bunk]

Control: reassign -1 libx11-6
Control: forcemerge 966691 -1
Control: affects 966691 emacs

On Mon, Aug 03, 2020 at 01:23:59PM +0900, Winter Metasequoia wrote:
> FYI.  I just encountered similar situation, but downgrading libx11-6
> from 2:1.6.10-1 to 2:1.6.9-2+b1
> emacs has been recovered.  I hope someone confirms this.

Yes, this is a bug that is fixed in libx11-6 2:1.6.10-3.

cu
Adrian

Bug#967051: ITP: seqkit: Cross-platform and ultrafast toolkit for FASTA/Q file manipulation

[Nilesh Patra]

Package: wnpp
Severity: wishlist
Owner: Nilesh Patra 
X-Debbugs-CC: debian-de...@lists.debian.org


* Package name: seqkit
  Version : 0.12.1+ds-1
  Upstream Author : 2016-2020 Wei Shen, 2019 Oxford Nanopore Technologies

* License : MIT
  Programming Lang: Golang
  Description :cross-platform and ultrafast toolkit for FASTA/Q file
manipulation
 SeqKit describes a cross-platform ultrafast comprehensive toolkit for
 FASTA/Q processing. SeqKit provides executable binary files for all
 major operating systems, including Windows, Linux, and Mac OS X, and can
 be directly used without any dependencies or pre-configurations. SeqKit
 demonstrates competitive performance in execution time and memory usage
 compared to similar tools. The efficiency and usability of SeqKit enable
 researchers to rapidly accomplish common FASTA/Q file manipulations.

I will maintain this package.

Bug#967007: Now dependencies are satisfied

[Pirate Praveen]

On Mon, Aug 3, 2020 at 20:12, Pirate Praveen  
wrote:
Once ruby-webpacker and ruby-webdrivers clears NEW creating new rails 
app will work.


Now some tests for the newly created app fails. I think running rails 
webpacker:install will fix it.


+ rails webpacker:install
Warning: Running `gem pristine --all` to regenerate your installed 
gemspecs (and deleting then reinstalling your bundle if you use bundle 
--path) will improve the startup performance of Spring.
Node.js not installed. Please download and install Node.js 
https://nodejs.org/en/download/


This seems strange as rails metapackage has a dependency on webpack, 
and yarnpkg which should pull nodejs.

Bug#967048: unblock: win32-loader/0.10.1

[Didier 'OdyX' Raboud]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: debian-b...@lists.debian.org

Please unblock package win32-loader in its 0.10.1 version

[ Reason ]
win32-loader is one of the rare packages always blocked, because it has a
'byhand' counterpart per release: `/debian/tools/win32-loader/{release}`, and
therefore needs a manual action by FTP masters in sync ("around the time of")
with the unblock.

[ Impact ]
It's been since 0.9.5 (March 2019) that it hasn't been migrated, and I (as
co-maintainer), want the 0.10* changes in for Bullseye.

[ Tests ]
There are no significant error reports for the version in unstable, I deem
this version as really safe to migrate. If it were a normal package, it would
have migrated for every version.

Please CC ftpmas...@debian.org when granting this unblock, for them to proceed
with their magic.

Best regards, and thanks for your work,
OdyX

unblock win32-loader/0.10.1

Bug#957620: nvtv: diff for NMU version 0.4.7-8.1

[Sudip Mukherjee]

Control: tags 957620 + patch
Control: tags 957620 + pending

Dear maintainer,

I've prepared an NMU for nvtv (versioned as 0.4.7-8.1) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should cancel it.

--
Regards
Sudip

diff -Nru nvtv-0.4.7/debian/changelog nvtv-0.4.7/debian/changelog
--- nvtv-0.4.7/debian/changelog 2012-09-02 02:46:52.0 +0100
+++ nvtv-0.4.7/debian/changelog 2020-08-03 16:30:37.0 +0100
@@ -1,3 +1,10 @@
+nvtv (0.4.7-8.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix ftbfs with GCC-10. (Closes: #957620)
+
+ -- Sudip Mukherjee   Mon, 03 Aug 2020 16:30:37 
+0100
+
 nvtv (0.4.7-8) unstable; urgency=low
 
   * Updated standards.
diff -Nru nvtv-0.4.7/debian/patches/fix_ftbfs.patch 
nvtv-0.4.7/debian/patches/fix_ftbfs.patch
--- nvtv-0.4.7/debian/patches/fix_ftbfs.patch   1970-01-01 01:00:00.0 
+0100
+++ nvtv-0.4.7/debian/patches/fix_ftbfs.patch   2020-08-03 16:30:14.0 
+0100
@@ -0,0 +1,80 @@
+Description: Fix ftbfs with GCC-10.
+
+Author: Sudip Mukherjee 
+Bug-Debian: https://bugs.debian.org/957620
+Forwarded: no
+
+---
+
+--- nvtv-0.4.7.orig/src/data_cx.c
 nvtv-0.4.7/src/data_cx.c
+@@ -33,6 +33,19 @@
+ #include "data_cx.h"
+ #include "data_nv.h"
+ 
++TVCxRegs cx_ntsc_xbox; /* XBox BIOS */
++
++TVCxRegs cx_ntsc_small_a;  /* Mode 10, hoc=15.11 voc=14.81 */
++TVCxRegs cx_ntsc_normal_a; /* Mode 26, hoc=11.97 voc=11.93 */
++TVCxRegs cx_ntsc_tiny_a;   /* Mode 42, hoc=18.04 voc=18.11 */
++TVCxRegs cx_ntsc_small_b;  /* Mode 18, hoc=13.79 voc=13.58 */
++TVCxRegs cx_ntsc_tiny_b;   /* Mode 34, hoc=19.26 voc=19.34 */
++TVCxRegs cx_ntsc_mini_b;   /* Mode 40, hoc=15.59 voc=15.64 */
++
++TVCxRegs cx_pal_small_a;   /* Mode 11, hoc=13.44 voc=14.24 */
++TVCxRegs cx_pal_mini_a;/* Mode 43, hoc=16.20 voc=16.67 */
++
++
+ /*  CX  NTSC  */
+ 
+ /* FIXME I do not know if all XBoxes have the CX encoder. For now, we
+--- nvtv-0.4.7.orig/src/data_cx.h
 nvtv-0.4.7/src/data_cx.h
+@@ -37,16 +37,16 @@ void data_setup_cx (TVSettings *s, TVReg
+ 
+ void data_secam_cx (TVCxRegs *r);
+ 
+-TVCxRegs cx_ntsc_xbox; /* XBox BIOS */
++extern TVCxRegs cx_ntsc_xbox; /* XBox BIOS */
+ 
+-TVCxRegs cx_ntsc_small_a;  /* Mode 10, hoc=15.11 voc=14.81 */
+-TVCxRegs cx_ntsc_normal_a; /* Mode 26, hoc=11.97 voc=11.93 */
+-TVCxRegs cx_ntsc_tiny_a;   /* Mode 42, hoc=18.04 voc=18.11 */
+-TVCxRegs cx_ntsc_small_b;  /* Mode 18, hoc=13.79 voc=13.58 */
+-TVCxRegs cx_ntsc_tiny_b;   /* Mode 34, hoc=19.26 voc=19.34 */
+-TVCxRegs cx_ntsc_mini_b;   /* Mode 40, hoc=15.59 voc=15.64 */
++extern TVCxRegs cx_ntsc_small_a;  /* Mode 10, hoc=15.11 voc=14.81 */
++extern TVCxRegs cx_ntsc_normal_a; /* Mode 26, hoc=11.97 voc=11.93 */
++extern TVCxRegs cx_ntsc_tiny_a;   /* Mode 42, hoc=18.04 voc=18.11 */
++extern TVCxRegs cx_ntsc_small_b;  /* Mode 18, hoc=13.79 voc=13.58 */
++extern TVCxRegs cx_ntsc_tiny_b;   /* Mode 34, hoc=19.26 voc=19.34 */
++extern TVCxRegs cx_ntsc_mini_b;   /* Mode 40, hoc=15.59 voc=15.64 */
+ 
+-TVCxRegs cx_pal_small_a;   /* Mode 11, hoc=13.44 voc=14.24 */
+-TVCxRegs cx_pal_mini_a;/* Mode 43, hoc=16.20 voc=16.67 */
++extern TVCxRegs cx_pal_small_a;   /* Mode 11, hoc=13.44 voc=14.24 */
++extern TVCxRegs cx_pal_mini_a;/* Mode 43, hoc=16.20 voc=16.67 */
+ 
+ #endif /* _DATA_CX_H */
+--- nvtv-0.4.7.orig/src/nvtv.c
 nvtv-0.4.7/src/nvtv.c
+@@ -117,6 +117,8 @@ int opt_pci_func = -1;
+ 
+ TVSettings opt_set;
+ 
++int opt_tv_bus, opt_tv_addr;
++
+ static const char *short_options = "?12bcdf:ghlmno:pqr:s:tw:A:C:FNPS:T:W:X";
+ 
+ static struct option long_options[] =
+--- nvtv-0.4.7.orig/src/nvtv.h
 nvtv-0.4.7/src/nvtv.h
+@@ -58,7 +58,7 @@ extern TVConnect opt_connect;/* use
+ extern TVSettings opt_set;
+ 
+ extern TVChip opt_tv_chip;   /* use if != TV_NO_CHIP */
+-int opt_tv_bus, opt_tv_addr; /* use if == TV_CHIP_BY_ADDR */
++extern int opt_tv_bus, opt_tv_addr; /* use if == TV_CHIP_BY_ADDR */
+ 
+ #if HAVE_X
+ extern Window opt_window;/* use if != None */
diff -Nru nvtv-0.4.7/debian/patches/series nvtv-0.4.7/debian/patches/series
--- nvtv-0.4.7/debian/patches/series2012-09-01 18:30:48.0 +0100
+++ nvtv-0.4.7/debian/patches/series2020-08-03 16:24:25.0 +0100
@@ -3,3 +3,4 @@
 003_Gnu.patch
 004_makefile
 005_autotools.patch
+fix_ftbfs.patch

Bug#864701: Hello Friend

[Duncan Ferguson]

-- 
Dear Friend,

 I am Mr. Duncan Ferguson, I worked with the department of Audit and
accounting with Halifax Bank London, There is this fund that was
keep in my custody years ago by politicians from Africa who are no
more in power and  are not willing to be mentioned by name I need your
assistance for the transferring of this fund to your bank account
for our mutual benefits I have succeeded to move the money from
Halifax to a fund manager who lives in France and I have the documents
to make him believe you and release the
fund to your bank account in within 14 banking  days with your full
co-operation with me  Moreso after success Note 30% for you while 70% for
me after success of the transfer of the funds to your bank account.

Below information is what I need from you so we can be reaching each other,

1) Full name ...
2) Private telephone number...
3) Age...
4) Nationalities...
5) Occupations ...
They will be Financial commitment to make in this transaction but must
be refunded before sharing, I need you to handle this business
regardless of the fact that we have not met before. I am trusting that
I have found a new and good friend

Thanks.
Mr. Duncan Ferguson.

Bug#966575: Requested information about affected system (four disks, raid1, crypt)

[Devin T. Theriot-Orr]

Hi all,

I just recovered my system (supermicro server) from this and thought I
would share in case it is helpful.

1. Number of disks: 4

2. Filesystem setup

This is a raid1 setup with crypted lvm.

Grub is installed in MBR of /dev/sda

# fdisk -l

Disk /dev/sda: 465.8 GiB, 500107862016 bytes, 976773168 sectors
Disk model: Samsung SSD 850
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x953049db

Device BootStart   End   Sectors   Size Id Type
/dev/sda1  *2048585727583680   285M fd Linux raid autodetect
/dev/sda2 585728  39647231  39061504  18.6G fd Linux raid autodetect
/dev/sda3   39647232 918552575 878905344 419.1G fd Linux raid autodetect

Disk /dev/sdc: 931.5 GiB, 1000204886016 bytes, 1953525168 sectors
Disk model: WDC WD10JPLX-00M
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: dos
Disk identifier: 0x38784402

Device Boot StartEndSectors   Size Id Type
/dev/sdc12048 1953525167 1953523120 931.5G 83 Linux

Disk /dev/sdd: 931.5 GiB, 1000204886016 bytes, 1953525168 sectors
Disk model: WDC WD10JPLX-00M
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: dos
Disk identifier: 0xa1da09f8

Device Boot StartEndSectors   Size Id Type
/dev/sdd12048 1953525167 1953523120 931.5G 83 Linux

Disk /dev/sdb: 465.8 GiB, 500107862016 bytes, 976773168 sectors
Disk model: Samsung SSD 850
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x1efcfd6f

Device BootStart   End   Sectors   Size Id Type
/dev/sdb1  *2048585727583680   285M fd Linux raid autodetect
/dev/sdb2 585728  39647231  39061504  18.6G fd Linux raid autodetect
/dev/sdb3   39647232 918552575 878905344 419.1G fd Linux raid autodetect

Disk /dev/md0: 284.7 MiB, 298516480 bytes, 583040 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

Disk /dev/md2: 419 GiB, 449865318400 bytes, 878643200 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

Disk /dev/md1: 18.6 GiB, 19982712832 bytes, 39028736 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

Disk /dev/md3: 931.4 GiB, 169595136 bytes, 1953260928 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes

Disk /dev/mapper/md1_crypt: 18.6 GiB, 19980615680 bytes, 39024640 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

Disk /dev/mapper/vg0-root: 9.3 GiB, 220736 bytes, 19529728 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

Disk /dev/mapper/vg0-usr: 4.7 GiB, 4999610368 bytes, 9764864 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

Disk /dev/mapper/vg0-var: 4.7 GiB, 4978638848 bytes, 9723904 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

Disk /dev/mapper/md2_crypt: 419 GiB, 449863221248 bytes, 878639104 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

[bunch of lvms for vms]

3. History of the system

I installed jessie on this server in 2015 and remotely upgraded to
stretch and then to buster.

# uname -a
Linux X 4.19.0-10-amd64 #1 SMP Debian 4.19.132-1 (2020-07-24) x86_64
GNU/Linux

As with others, I was able to boot into d-i rescue mode and reinstall
grub and then it booted fine.

I hope this helps. It was definitely a surprise to find the server
unbootable at 1am this morning!

Thanks for all the work!

-Devin

Bug#941925: segfaults in testsuite

[Sébastien Villemot]

Le samedi 01 août 2020 à 16:36 +0200, Rafael Laboissière a écrit :
> * Sébastien Villemot  [2019-10-07 18:19]:
> 
> > Package: octave-vibes
> > Version: 0.2.0-3
> > Severity: important
> > 
> > Octave segfaults when executing the testsuite of octave-vibes (both at 
> > build 
> > time and in the autopkgtest).
> > 
> > This is not caused by the Octave 5 transition, the problem was already 
> > there 
> > with Octave 4.4.
> 
> Version 0.2.0-6 of octave-vibes builds fine on all architectures and the 
> autopkgtest pass.  Can we close this bug report ?

Of course, if the problem is fixed.

-- 
⢀⣴⠾⠻⢶⣦⠀  Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁  Debian Developer
⢿⡄⠘⠷⠚⠋⠀  https://sebastien.villemot.name
⠈⠳⣄  https://www.debian.org



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

Bug#967045: libtinyxml2-dev: Missing cmake configuration files

[Roger Leigh]

Package: libtinyxml2-dev
Version: 8.0.0+dfsg-2
Severity: normal


i
├── include
│   └── tinyxml2.h
└── lib
    ├── cmake
    │   └── tinyxml2
    │   ├── tinyxml2Config.cmake
    │   ├── tinyxml2Targets.cmake
    │   └── tinyxml2Targets-noconfig.cmake
    ├── libtinyxml2.so -> libtinyxml2.so.6
    ├── libtinyxml2.so.6 -> libtinyxml2.so.6.2.0
    ├── libtinyxml2.so.6.2.0
    └── pkgconfig
    └── tinyxml2.pc

The dev package is not including lib/cmake/tinyxml2 with its three
configuration files.  This is needed to be able to import the
tinyxml2 configuration with cmake find_package.

Please could these files be added?

Thanks,
Roger


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

Kernel: Linux 5.6.0-1-amd64 (SMP w/4 CPU threads)
Locale: LANG=en_GB.UTF8, LC_CTYPE=en_GB.UTF8 (charmap=UTF-8), 
LANGUAGE=en_GB:en

Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libtinyxml2-dev depends on:
ii  libtinyxml2-8  8.0.0+dfsg-2

libtinyxml2-dev recommends no packages.

libtinyxml2-dev suggests no packages.

-- no debconf information

Bug#966475: rspamd ftbfs with gcc-10

[Sebastien Badia]

On Tue, Jul 28, 2020 at 05:48:23PM (-0700), Steve Langasek wrote:
> Package: rspamd
> Version: 2.5-2
> Severity: serious
> Tags: patch
> Justification: ftbfs
> User: ubuntu-de...@lists.ubuntu.com
> Usertags: origin-ubuntu groovy ubuntu-patch
> 
> Dear maintainers,
> 
> In Ubuntu, we've found that rspamd fails to build from source with the
> current toolchain due to a missing C++ include file.  The attached patch
> fixes the build failure in unstable.

Hello Steve,

Many thanks for this patch/follow-up,
2.5-3 just uploaded.

Have a good day,

Seb


signature.asc
Description: PGP signature

Bug#967010: apache2: last debian 10.4 , last apache avail from repo hangs on install (and start phase)

[root]

Package: apache2
Version: 2.4.38-3+deb10u3
Severity: grave
Justification: renders package unusable

Dear Maintainer,


   * What led up to the situation?
package installing
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
apt-get install apache2
   * What was the outcome of this action?
packages did not start
   * What outcome did you expect instead?
packages will start ok


I have fresh debian 10 install, OS after full upgrade with:
`apt-get upgrade` and
`apt-get dist-upgrade`

I want to install apache2 packages, it hang on install (on post-install phase 
when apache starts):

(*my findings why is below)

apt-get install apache2  
Reading package lists... Done
Building dependency tree   
Reading state information... Done
The following additional packages will be installed:
  apache2-bin apache2-data apache2-utils libapr1 libaprutil1 
libaprutil1-dbd-sqlite3 libaprutil1-ldap libbrotli1 libjansson4 liblua5.2-0
Suggested packages:
  apache2-doc apache2-suexec-pristine | apache2-suexec-custom
The following NEW packages will be installed:
  apache2 apache2-bin apache2-data apache2-utils libapr1 libaprutil1 
libaprutil1-dbd-sqlite3 libaprutil1-ldap libbrotli1 libjansson4 liblua5.2-0
0 upgraded, 11 newly installed, 0 to remove and 1 not upgraded.
Need to get 0 B/2,606 kB of archives.
After this operation, 8,885 kB of additional disk space will be used.
Do you want to continue? [Y/n] y
Selecting previously unselected package libapr1:amd64.
(Reading database ... 85650 files and directories currently installed.)
Preparing to unpack .../00-libapr1_1.6.5-1+b1_amd64.deb ...
Unpacking libapr1:amd64 (1.6.5-1+b1) ...
Selecting previously unselected package libaprutil1:amd64.
Preparing to unpack .../01-libaprutil1_1.6.1-4_amd64.deb ...
Unpacking libaprutil1:amd64 (1.6.1-4) ...
Selecting previously unselected package libaprutil1-dbd-sqlite3:amd64.
Preparing to unpack .../02-libaprutil1-dbd-sqlite3_1.6.1-4_amd64.deb ...
Unpacking libaprutil1-dbd-sqlite3:amd64 (1.6.1-4) ...
Selecting previously unselected package libaprutil1-ldap:amd64.
Preparing to unpack .../03-libaprutil1-ldap_1.6.1-4_amd64.deb ...
Unpacking libaprutil1-ldap:amd64 (1.6.1-4) ...
Selecting previously unselected package libbrotli1:amd64.
Preparing to unpack .../04-libbrotli1_1.0.7-2_amd64.deb ...
Unpacking libbrotli1:amd64 (1.0.7-2) ...
Selecting previously unselected package libjansson4:amd64.
Preparing to unpack .../05-libjansson4_2.12-1_amd64.deb ...
Unpacking libjansson4:amd64 (2.12-1) ...
Selecting previously unselected package liblua5.2-0:amd64.
Preparing to unpack .../06-liblua5.2-0_5.2.4-1.1+b2_amd64.deb ...
Unpacking liblua5.2-0:amd64 (5.2.4-1.1+b2) ...
Selecting previously unselected package apache2-bin.
Preparing to unpack .../07-apache2-bin_2.4.38-3+deb10u3_amd64.deb ...
Unpacking apache2-bin (2.4.38-3+deb10u3) ...
Selecting previously unselected package apache2-data.
Preparing to unpack .../08-apache2-data_2.4.38-3+deb10u3_all.deb ...
Unpacking apache2-data (2.4.38-3+deb10u3) ...
Selecting previously unselected package apache2-utils.
Preparing to unpack .../09-apache2-utils_2.4.38-3+deb10u3_amd64.deb ...
Unpacking apache2-utils (2.4.38-3+deb10u3) ...
Selecting previously unselected package apache2.
Preparing to unpack .../10-apache2_2.4.38-3+deb10u3_amd64.deb ...
Unpacking apache2 (2.4.38-3+deb10u3) ...
Setting up libbrotli1:amd64 (1.0.7-2) ...
Setting up libapr1:amd64 (1.6.5-1+b1) ...
Setting up libjansson4:amd64 (2.12-1) ...
Setting up liblua5.2-0:amd64 (5.2.4-1.1+b2) ...
Setting up apache2-data (2.4.38-3+deb10u3) ...
Setting up libaprutil1:amd64 (1.6.1-4) ...
Setting up libaprutil1-ldap:amd64 (1.6.1-4) ...
Setting up libaprutil1-dbd-sqlite3:amd64 (1.6.1-4) ...
Setting up apache2-utils (2.4.38-3+deb10u3) ...
Setting up apache2-bin (2.4.38-3+deb10u3) ...
Setting up apache2 (2.4.38-3+deb10u3) ...
Enabling module mpm_event.
Enabling module authz_core.
Enabling module authz_host.
Enabling module authn_core.
Enabling module auth_basic.
Enabling module access_compat.
Enabling module authn_file.
Enabling module authz_user.
Enabling module alias.
Enabling module dir.
Enabling module autoindex.
Enabling module env.
Enabling module mime.
Enabling module negotiation.
Enabling module setenvif.
Enabling module filter.
Enabling module deflate.
Enabling module status.
Enabling module reqtimeout.
Enabling conf charset.
Enabling conf localized-error-pages.
Enabling conf other-vhosts-access-log.
Enabling conf security.
Enabling conf serve-cgi-bin.
Enabling site 000-default.
Created symlink /etc/systemd/system/multi-user.target.wants/apache2.service → 
/etc/systemd/system/apache2.service.
Created symlink 
/etc/systemd/system/multi-user.target.wants/apache-htcacheclean.service → 
/lib/systemd/system/apache-htcacheclean.service.

here it hangs. and after some time 

Job for apache2.service failed because a timeout was exceeded.
See "systemctl status apache2.service" and "journalctl -xe" for details.
invoke-rc.d: 

Bug#966628: slick-greeter: please default draw-grid to true (or some other eyecandy)

[Adam Borowski]

On Mon, Aug 03, 2020 at 11:30:51AM +0100, David Mohammed wrote:
> hmm - the grid change was made by linux mint upstream a while back
> hence the observation between buster and now.

I just installed Mint for a test, and the package's defaults are not used.
Instead, the installer writes a config that includes an image.

> I'm wondering if adding a Suggests: or possibly a Recommendation: for
> the package lightdm-settings would be better here so that end users
> will have a more obvious "this thing is actually configurable" - so
> adding a grid if they want, their own background etc etc.

Yeah, but it would be good to ship with nice defaults, as most people
wouldn't think about configuring a greeter.  I'm not insisting on the
grid -- just anything better than the black screen.

I've learned that the default eyecandy matters a lot for how people
score a system.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋⠀ It's time to migrate your Imaginary Protocol from version 4i to 6i.
⠈⠳⣄

Bug#966557: Blacklist nvidia-modeset and nvidia-drm

[Joel Johnson]

On 2020-07-31 03:03, Andreas Beckmann wrote:

On 7/30/20 6:41 PM, Joel Johnson wrote:

With more recent nvidia drivers and Debian packages of
nvidia-kernel-support, the nvidia-modeset and nvidia-drm modules are
attempted to be loaded. This causes the driver to always be loaded.
Locally I've added those two modules to the
/etc/modprobe.d/bumblebee.conf to blacklist them in addition to the
currently listed modules.


While this additional blacklisting sounds technically correct, I'm
curious why the driver gets loaded automatically in a bumblebee setup.

Please send the output of these commands:

update-glx --display nvidia
update-glx --display glx

Do you have bumblebee-nvidia installed?


Andreas


I do have the bumblebee-nvidia package installed, version 
3.2.1-22~bpo10+1 matching the bumblebee package. All of the related 
nvidia package versions are:


$(dpkg -l | grep -i nvidia | awk '{print $2 " - " $3}')
bbswitch-dkms - 0.8-9~bpo10+1
bumblebee - 3.2.1-22~bpo10+1
bumblebee-nvidia - 3.2.1-22~bpo10+1
glx-alternative-nvidia - 1.1.0~bpo10+1
libaccinj64-10.1:amd64 - 10.1.243-6~bpo10+1
libcuda1:amd64 - 440.100-1~bpo10+1
libcuinj64-10.1:amd64 - 10.1.243-6~bpo10+1
libnvidia-cfg1:amd64 - 440.100-1~bpo10+1
libnvidia-fatbinaryloader:amd64 - 440.100-1~bpo10+1
libnvidia-glcore:amd64 - 440.100-1~bpo10+1
libnvidia-ml1:amd64 - 440.100-1~bpo10+1
libnvidia-ptxjitcompiler1:amd64 - 440.100-1~bpo10+1
nvidia-alternative - 440.100-1~bpo10+1
nvidia-installer-cleanup - 20151021+12~bpo10+1
nvidia-kernel-common - 20151021+12~bpo10+1
nvidia-kernel-dkms - 440.100-1~bpo10+1
nvidia-kernel-support - 440.100-1~bpo10+1
nvidia-legacy-check - 440.100-1~bpo10+1
nvidia-modprobe - 418.56-1
nvidia-persistenced - 418.56-1
nvidia-profiler - 10.1.243-6~bpo10+1
nvidia-smi - 440.100-1~bpo10+1
nvidia-support - 20151021+12~bpo10+1
nvidia-vdpau-driver:amd64 - 440.100-1~bpo10+1
nvtop - 1.0.0-1
primus - 0~20150328-10~bpo10+1
xserver-xorg-video-nvidia - 440.100-1~bpo10+1

The command outputs are included below.

Thanks,
Joel

$(update-glx --display nvidia):

nvidia - auto mode
  link best version is /usr/lib/nvidia/current
  link currently points to /usr/lib/nvidia/current
  link nvidia is /usr/lib/nvidia/nvidia
  slave nvidia--libcuda.so-x86_64-linux-gnu is 
/usr/lib/x86_64-linux-gnu/libcuda.so
  slave nvidia--libcuda.so.1-x86_64-linux-gnu is 
/usr/lib/x86_64-linux-gnu/libcuda.so.1
  slave nvidia--libglxserver_nvidia.so is 
/usr/lib/nvidia/libglxserver_nvidia.so
  slave nvidia--libnvidia-cfg.so.1-x86_64-linux-gnu is 
/usr/lib/x86_64-linux-gnu/nvidia/libnvidia-cfg.so.1
  slave nvidia--libnvidia-ml.so.1-x86_64-linux-gnu is 
/usr/lib/x86_64-linux-gnu/libnvidia-ml.so.1
  slave nvidia--libnvidia-ptxjitcompiler.so.1-x86_64-linux-gnu is 
/usr/lib/x86_64-linux-gnu/libnvidia-ptxjitcompiler.so.1
  slave nvidia--libvdpau_nvidia.so.1-x86_64-linux-gnu is 
/usr/lib/x86_64-linux-gnu/vdpau/libvdpau_nvidia.so.1
  slave nvidia--nvidia-blacklists-nouveau.conf is 
/etc/nvidia/nvidia-blacklists-nouveau.conf
  slave nvidia--nvidia-drm-outputclass.conf is 
/etc/nvidia/nvidia-drm-outputclass.conf

  slave nvidia--nvidia-load.conf is /etc/nvidia/nvidia-load.conf
  slave nvidia--nvidia-modprobe.conf is /etc/nvidia/nvidia-modprobe.conf
  slave nvidia--nvidia-smi is /usr/bin/nvidia-smi
  slave nvidia--nvidia-smi.1.gz is /usr/share/man/man1/nvidia-smi.1.gz
  slave nvidia--nvidia_drv.so is /usr/lib/nvidia/nvidia_drv.so
/usr/lib/nvidia/current - priority 440
  slave nvidia--libcuda.so-x86_64-linux-gnu: 
/usr/lib/x86_64-linux-gnu/nvidia/current/libcuda.so
  slave nvidia--libcuda.so.1-x86_64-linux-gnu: 
/usr/lib/x86_64-linux-gnu/nvidia/current/libcuda.so.1
  slave nvidia--libglxserver_nvidia.so: 
/usr/lib/nvidia/current/libglxserver_nvidia.so
  slave nvidia--libnvidia-cfg.so.1-x86_64-linux-gnu: 
/usr/lib/x86_64-linux-gnu/nvidia/current/libnvidia-cfg.so.1
  slave nvidia--libnvidia-ml.so.1-x86_64-linux-gnu: 
/usr/lib/x86_64-linux-gnu/nvidia/current/libnvidia-ml.so.1
  slave nvidia--libnvidia-ptxjitcompiler.so.1-x86_64-linux-gnu: 
/usr/lib/x86_64-linux-gnu/nvidia/current/libnvidia-ptxjitcompiler.so.1
  slave nvidia--libvdpau_nvidia.so.1-x86_64-linux-gnu: 
/usr/lib/x86_64-linux-gnu/nvidia/current/libvdpau_nvidia.so.1
  slave nvidia--nvidia-blacklists-nouveau.conf: 
/etc/nvidia/current/nvidia-blacklists-nouveau.conf
  slave nvidia--nvidia-drm-outputclass.conf: 
/etc/nvidia/current/nvidia-drm-outputclass.conf

  slave nvidia--nvidia-load.conf: /etc/nvidia/current/nvidia-load.conf
  slave nvidia--nvidia-modprobe.conf: 
/etc/nvidia/current/nvidia-modprobe.conf

  slave nvidia--nvidia-smi: /usr/lib/nvidia/current/nvidia-smi
  slave nvidia--nvidia-smi.1.gz: /usr/lib/nvidia/current/nvidia-smi.1.gz
  slave nvidia--nvidia_drv.so: /usr/lib/nvidia/current/nvidia_drv.so

$(update-glx --display glx):
glx - auto mode
  link best version is /usr/lib/nvidia
  link currently points to /usr/lib/nvidia
  link glx is /usr/lib/glx
  slave glx--libEGL.so.1-x86_64-linux-gnu is 

Bug#966817: New dependency on lzip not documented in changelog

[Chris Lamb]

Hi Josh,

> > What is the proper remedy for your bug, please?
>
> Just an entry in the 2.86.0 changelog along the lines of "Add missing
> dependency on lzip, used to test for broken lzip files in packages."

I have added the following to the changelog entry to 2.85.0:

   * Add lzip to Depends and Build-Depends. Due to a particularity in the
 implementation of safe_qx via IO::Async it was not recognised as a
 requirement until now.

Unfortunately, the commit that made this change not only had a
"Gbp-Dch: ignore" line, even if this was absent the first line of the
commit would not have included enough context or justification.


Regards,

--
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org  chris-lamb.co.uk
   `-

Bug#965012: /usr/sbin/squid: ICAP-Error after Upgrade from 3.5.23-5+deb9u1 to 3.5.23-5+deb9u2 [TT#2398327]

[SerNet Support Kevin Ivory]

Just for the sake of completeness: we have this problem as well
and still have many systems with Debian Stretch that need Squid Icap
to communicate with Avira Savapi antivirus. Because this bugs hits
us as well, we are now holding on to version 3.5.23-5+deb9u1.

On Mon, 27 Jul 2020 00:15:18 +0200 Markus Koschany  wrote:

Hello Andreas,

On Tue, 14 Jul 2020 13:57:48 +0200 Andreas Schulz
 wrote:
> Package: squid
> Version: 3.5.23-5+deb9u2.1
> Severity: important
> File: /usr/sbin/squid
> 
> Dear Maintainer,
> 
> We installed the security update deb9u2 and learned that no more

> http-access (with icap) was possible.


I am not the maintainer but I have prepared the security update for
squid3 in Stretch. So far you are the only one who reported this
problem. I had sent a request for testing but never received any
feedback. [1] Please note that Stretch is now supported by the LTS team.
We have a dedicated mailing list where you can report problems dedicated
to packages in Stretch called debian-...@lists.debian.org.

Could you set debug_options to ALL,9 (which should enable full debugging
according to the squid wiki) and reproduce the issue again? Please
attach the complete log either to this bug report or send it to me via
private email directly.

The patch for CVE-2019-12523 contains only one line that appears to
touch icap related code in src/adaptation/icap/ModXact.cc. I have
reverted this change and attached a new CVE-2019-12523.patch. Could you
apply it and report back if it makes any difference? Otherwise only the
debug log could help to narrow down the problem.

Regards,

Markus



[1] https://lists.debian.org/debian-lts/2020/07/msg00018.html


Best regards
Kevin Ivory (SerNet Support)
--
SerNet GmbH, Bahnhofsallee 1b, 37081 Göttingen
phone: 0551-37-0, mailto:kont...@sernet.de
Gesch.F.: Dr. Johannes Loxen und Reinhild Jung
AG Göttingen: HR-B 2816 - http://www.sernet.de

Bug#966812: keepass2: Keepass2 crashes at startup after system update

[Adilson dos Santos Dantas]

Em seg., 3 de ago. de 2020 às 06:15, Adrian Bunk  escreveu:

> On Sun, Aug 02, 2020 at 02:15:53PM -0300, Adilson dos Santos Dantas wrote:
> > Package: keepass2
> > Version: 2.45+dfsg-1
> > Severity: grave
> > Justification: renders package unusable
> >
> > Dear Maintainer,
> >
> > After update my system packages, keepas2 stops working. It simply
> crashes at
> > startup. Maybe is something related to libc6 with mono. I'm attaching
> the crash
> > report below to check if the problem is with current keepass packages or
> it is
> > something with mono runtime.
> >...
> > Versions of packages keepass2 depends on:
> >...
> > ii  libx11-6 2:1.6.10-1
> >...
>
> Does upgrading libx11-6 to 2:1.6.10-3 fix your problem?
>

Yes, it does. I tested it with two machines now and it stopped crashing
after libx11-6 upgrade.

Thank you!


>
> cu
> Adrian
>


-- 
Adilson dos Santos Dantas
http://www.adilson.net.br
http://twitter.com/adilsond

Bug#967017: [request-tracker-maintainers] Bug#967017: request-tracker4: FTBFS: can't exec /usr/bin/gpg

[Dominic Hargreaves]

Control: retitle -1 request-tracker4: FTBFS: GPG test failures

On Mon, Aug 03, 2020 at 02:05:16PM +0200, Lucas Nussbaum wrote:
> Source: request-tracker4
> Version: 4.4.4-1
> Severity: serious
> Justification: FTBFS on amd64
> Tags: bullseye sid ftbfs
> Usertags: ftbfs-20200802 ftbfs-bullseye
> 
> Hi,
> 
> During a rebuild of all packages in sid, your package failed to build
> on amd64.

Relevant log extract is

[18290] [Sun Aug  2 17:07:59 2020] [warning]: Can't exec "/usr/bin/gpg": No 
such file or directory at /usr/share/perl5/GnuPG/Interface.pm line 349. 
(/<>/lib/RT/Test.pm:716)
exec() error: No such file or directory at /usr/share/perl5/GnuPG/Interface.pm 
line 349.
BEGIN failed--compilation aborted at t/crypt/gnupg/attachments-in-db.t line 10.
[18287] [Sun Aug  2 17:07:59 2020] [warning]: Use of uninitialized value $line 
in pattern match (m//) at /usr/share/perl5/GnuPG/Interface.pm line 822. 
(/<>/lib/RT/Test.pm:716)
[18287] [Sun Aug  2 17:07:59 2020] [warning]: Use of uninitialized value $a in 
split at /usr/share/perl5/GnuPG/Interface.pm line 836. 
(/<>/lib/RT/Test.pm:716)
[18287] [Sun Aug  2 17:07:59 2020] [warning]: Use of uninitialized value $a in 
split at /usr/share/perl5/GnuPG/Interface.pm line 836. 
(/<>/lib/RT/Test.pm:716)
GnuPG Version 1.4 or 2.2+ required at /<>/lib/RT/Crypt/GnuPG.pm 
line 1851.
BEGIN failed--compilation aborted at t/crypt/gnupg/attachments-in-db.t line 10.

...

This seems related to changes in libgnupg-interface-perl, which on the
face of it is ignoring the instruction to use 'gpg1' (configured via
the test_gnupg_interface_gpg1.diff patch). I can't immediately see why
that's happening but it seems related to the recent changes
libgnupg-interface-perl.

Andrew, any clues?

Dominic.

Bug#967007: Now dependencies are satisfied

[Pirate Praveen]

Once ruby-webpacker and ruby-webdrivers clears NEW creating new rails 
app will work.


Now some tests for the newly created app fails. I think running rails 
webpacker:install will fix it.


+ rake test
/usr/lib/ruby/vendor_ruby/capybara/selector/filter_set.rb:115: warning: 
Using the last argument as keyword parameters is deprecated; maybe ** 
should be added to the call
/usr/lib/ruby/vendor_ruby/capybara/selector/filters/node_filter.rb:9: 
warning: The called method `initialize' is defined here
/usr/lib/ruby/vendor_ruby/capybara/selector/filter_set.rb:19: warning: 
Using the last argument as keyword parameters is deprecated; maybe ** 
should be added to the call
/usr/lib/ruby/vendor_ruby/capybara/selector/filter_set.rb:111: warning: 
The called method `add_filter' is defined here
/usr/lib/ruby/vendor_ruby/capybara/selector/filter_set.rb:115: warning: 
Using the last argument as keyword parameters is deprecated; maybe ** 
should be added to the call
/usr/lib/ruby/vendor_ruby/capybara/selector/filters/base.rb:7: warning: 
The called method `initialize' is defined here
/usr/lib/ruby/vendor_ruby/capybara/selector/selector.rb:361: warning: 
Using the last argument as keyword parameters is deprecated; maybe ** 
should be added to the call
/usr/lib/ruby/vendor_ruby/capybara/selector/filters/locator_filter.rb:9: 
warning: The called method `initialize' is defined here
/usr/lib/ruby/vendor_ruby/capybara/selector/filters/locator_filter.rb:10: 
warning: Using the last argument as keyword parameters is deprecated; 
maybe ** should be added to the call
/usr/lib/ruby/vendor_ruby/capybara/selector/filters/node_filter.rb:9: 
warning: The called method `initialize' is defined here
DEPRECATION WARNING: Single arity template handlers are deprecated. 
Template handlers must
now accept two parameters, the view object and the source for the view 
object.

Change:
 >> JbuilderHandler.call(template)
To:
 >> JbuilderHandler.call(template, source)
(called from block (2 levels) in  at 
/usr/lib/ruby/vendor_ruby/jbuilder/railtie.rb:8)
RAILS_ENV=test environment is not defined in config/webpacker.yml, 
falling back to production environment
/usr/lib/ruby/vendor_ruby/capybara/selector/filter_set.rb:115: warning: 
Using the last argument as keyword parameters is deprecated; maybe ** 
should be added to the call
/usr/lib/ruby/vendor_ruby/capybara/selector/filters/node_filter.rb:9: 
warning: The called method `initialize' is defined here
/usr/lib/ruby/vendor_ruby/capybara/selector/filter_set.rb:19: warning: 
Using the last argument as keyword parameters is deprecated; maybe ** 
should be added to the call
/usr/lib/ruby/vendor_ruby/capybara/selector/filter_set.rb:111: warning: 
The called method `add_filter' is defined here
/usr/lib/ruby/vendor_ruby/capybara/selector/filter_set.rb:115: warning: 
Using the last argument as keyword parameters is deprecated; maybe ** 
should be added to the call
/usr/lib/ruby/vendor_ruby/capybara/selector/filters/base.rb:7: warning: 
The called method `initialize' is defined here
/usr/lib/ruby/vendor_ruby/capybara/selector/selector.rb:361: warning: 
Using the last argument as keyword parameters is deprecated; maybe ** 
should be added to the call
/usr/lib/ruby/vendor_ruby/capybara/selector/filters/locator_filter.rb:9: 
warning: The called method `initialize' is defined here
/usr/lib/ruby/vendor_ruby/capybara/selector/filters/locator_filter.rb:10: 
warning: Using the last argument as keyword parameters is deprecated; 
maybe ** should be added to the call
/usr/lib/ruby/vendor_ruby/capybara/selector/filters/node_filter.rb:9: 
warning: The called method `initialize' is defined here
DEPRECATION WARNING: Single arity template handlers are deprecated. 
Template handlers must
now accept two parameters, the view object and the source for the view 
object.

Change:
 >> JbuilderHandler.call(template)
To:
 >> JbuilderHandler.call(template, source)
(called from block (2 levels) in  at 
/usr/lib/ruby/vendor_ruby/jbuilder/railtie.rb:8)
RAILS_ENV=test environment is not defined in config/webpacker.yml, 
falling back to production environment

Run options: --seed 61677

# Running:

...E

Error:
ProductsControllerTest#test_should_get_edit:
ActionView::Template::Error: Webpacker configuration file not found 
/tmp/autopkgtest-lxc.60lhwj6z/downtmp/autopkgtest_tmp/foo/config/webpacker.yml. 
Please run rails webpacker:install Error: No such file or directory @ 
rb_sysopen - 
/tmp/autopkgtest-lxc.60lhwj6z/downtmp/autopkgtest_tmp/foo/config/webpacker.yml

   app/views/layouts/application.html.erb:9
   test/controllers/products_controller_test.rb:32:in `block in 
'


rails test test/controllers/products_controller_test.rb:31

E

Error:
ProductsControllerTest#test_should_get_new:
ActionView::Template::Error: Webpacker configuration file not found 
/tmp/autopkgtest-lxc.60lhwj6z/downtmp/autopkgtest_tmp/foo/config/webpacker.yml. 
Please run rails webpacker:install Error: No such file or directory @ 
rb_sysopen - 

Bug#958883: unattended-upgrades pegs CPU at 100% for an extended period

[Balint Reczey]

Hi Matt,

On Sat, Aug 1, 2020 at 12:03 AM Matt Taggart  wrote:
>
> I am also seeing unattended upgrade consume 100% CPU. Attached is a
> image of the cpu usage that started upon upgrade to buster. Each time uu
> runs the system has 30-40mins of 100% cpu spinning.
>
> The system is running the current buster version, 1.11.2.
>
> I see:
> #958883 (this bug) - fixed in 2.4, might be the same issue?
> #899366 - fixed in 1.4
> #960966 - still open but strace seems different
>
> The last things I see in strace -f are:
>
> 
> recvmsg(5, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base=NULL,
> iov_len=0}], msg_iovlen=1, msg_controllen=0,
> msg_flags=MSG_CTRUNC|MSG_TRUNC|MSG_CMSG_CLOEXEC},
> MSG_PEEK|MSG_TRUNC|MSG_CMSG_CLOEXEC) = 20
> recvmsg(5, {msg_name={sa_family=AF_NETLINK, nl_pid=0,
> nl_groups=}, msg_namelen=128->12, msg_iov=[{iov_base={{len=20,
> type=NLMSG_DONE, flags=NLM_F_MULTI, seq=0, pid=31505}, 0}, iov_len=20}],
> msg_iovlen=1, msg_controllen=0, msg_flags=MSG_CTRUNC|MSG_CMSG_CLOEXEC},
> MSG_CMSG_CLOEXEC) = 20
> brk(0x79c5000)  = 0x79c5000
> brk(0x7a1f000)  = 0x7a1f000
> mmap(NULL, 1052672, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
> 0) = 0x7f257770d000
> mremap(0x7f257770d000, 1052672, 2101248, MREMAP_MAYMOVE) = 0x7f257750c000
> mremap(0x7f257750c000, 2101248, 4198400, MREMAP_MAYMOVE) = 0x7f257710b000
> 
>
> I considered trying 2.5 from testing but it wants to pull in newer apt
> and some other things.
> Is a backport of 2.5 to buster possible for testing?
> Let me know if you want me to try anything.
> This seems important enough to fix in a stable update.

There were many performance-related fixes in unattended-upgrades. The
most significant ones need newer python-apt, so a potential backport
is blocked on a python-apt backport. Also while I'd be happy to
provide a backport at the moment I can't commit to maintaining one so
it needs a volunteer to do the unattended-upgrades backport.

If you are ok with running a patched version yourself there is a fix
in flight to disable the CPU intensive parts. Please read the change
carefully because it will keep more packages back:

https://github.com/mvo5/unattended-upgrades/pull/280

Cheers,
Balint

>
> --
> Matt Taggart
> tagg...@debian.org
>


-- 
Balint Reczey
Ubuntu & Debian Developer

Bug#954938: Occasional spice console freezes on boot after kernel upgrade

[Frank Otto]

Observing the same behaviour with version 4.19+105+deb10u5.
But here it is not occasional but happens on every boot.
The hung kworker causes a constant system load of 1.
After switching the video device from qxl to virtio, the problem disappears.



On Wed, 25 Mar 2020 16:01:02 +0100 IB Development Team  wrote:

Package: linux-image-amd64
Version: 4.19+105+deb10u3

After upgrading kernel from 4.19+105+deb10u1 to 4.19+105+deb10u3 in
debian 10 vm (qemu, kvm, virt-manager, qxl graphics) there are
occassional spice text console image corruptions during system boot
(boot with all text messages displayed, without quiet nor splash kernel
parameters).

Corrupted console contains many random characters witch different
colors and does not update (freezes just before switching to high
resolution text mode). 


Boot continues normally and one can unfreeze first console switching to
second console and back (Ctrl+Alt+F2 and then Ctrl+Alt+F1).

After a few minutes syslog starts to receive messages like below
(repeating every 2 minutes):

2020-03-25 15:50:04 myhost kernel: [  484.596112] INFO: task
kworker/1:1:42 blocked for more than 120 seconds.
2020-03-25 15:50:04 myhost kernel: [  484.596116]   Not tainted
4.19.0-8-amd64 #1 Debian 4.19.98-1
2020-03-25 15:50:04 myhost kernel: [  484.596118] "echo 0 >
/proc/sys/kernel/hung_task_timeout_secs" disables this message.
2020-03-25 15:50:04 myhost kernel: [  484.596120]
kworker/1:1 D042  2 0x8000
2020-03-25 15:50:04 myhost kernel: [  484.596149] Workqueue: events
drm_fb_helper_dirty_work [drm_kms_helper]
2020-03-25 15:50:04 myhost kernel: [  484.596152] Call Trace:
2020-03-25 15:50:04 myhost kernel: [  484.596163]  ?
__schedule+0x2a2/0x870
2020-03-25 15:50:04 myhost kernel: [  484.596168]  schedule+0x28/0x80
2020-03-25 15:50:04 myhost kernel:
[  484.596177]  qxl_ring_push+0x15e/0x1e0 [qxl]
2020-03-25 15:50:04 myhost kernel: [  484.596184]  ?
finish_wait+0x80/0x80
2020-03-25 15:50:04 myhost kernel:
[  484.596190]  qxl_push_command_ring_release+0x64/0x90 [qxl]
2020-03-25 15:50:04 myhost kernel:
[  484.596197]  qxl_draw_opaque_fb+0x25a/0x3f0 [qxl]
2020-03-25 15:50:04 myhost kernel: [  484.596203]  ?
__switch_to_asm+0x35/0x70
2020-03-25 15:50:04 myhost kernel:
[  484.596208]  qxlfb_framebuffer_dirty+0xeb/0x180 [qxl]
2020-03-25 15:50:04 myhost kernel: [  484.596214]  ?
syscall_return_via_sysret+0x33/0x83
2020-03-25 15:50:04 myhost kernel:
[  484.596227]  drm_fb_helper_dirty_work+0x14e/0x160 [drm_kms_helper]
2020-03-25 15:50:04 myhost kernel:
[  484.596236]  process_one_work+0x1a7/0x3a0
2020-03-25 15:50:04 myhost kernel:
[  484.596241]  worker_thread+0x30/0x390
2020-03-25 15:50:04 myhost kernel: [  484.596245]  ?
create_worker+0x1a0/0x1a0
2020-03-25 15:50:04 myhost kernel: [  484.596249]  kthread+0x112/0x130
2020-03-25 15:50:04 myhost kernel: [  484.596252]  ?
kthread_bind+0x30/0x30
2020-03-25 15:50:04 myhost kernel:
[  484.596257]  ret_from_fork+0x35/0x40