Bug#961107: slic3r-prusa FTBFS on mipsel and i386

[Adrian Bunk]

Source: slic3r-prusa
Version: 2.2.0+dfsg1-1
Severity: serious
Tags: ftbfs patch

https://buildd.debian.org/status/fetch.php?pkg=slic3r-prusa&arch=mipsel&ver=2.2.0%2Bdfsg1-1&stamp=1586422709&raw=0

...
virtual memory exhausted: Cannot allocate memory
make[3]: *** [src/libslic3r/CMakeFiles/libslic3r_cgal.dir/build.make:66: 
src/libslic3r/CMakeFiles/libslic3r_cgal.dir/MeshBoolean.cpp.o] Error 1


https://buildd.debian.org/status/fetch.php?pkg=slic3r-prusa&arch=i386&ver=2.2.0%2Bdfsg1-1&stamp=1586426190&raw=0

...
test cases:  28 |  27 passed | 1 failed
assertions: 519 | 517 passed | 2 failed


E: Build killed with signal TERM after 150 minutes of inactivity


Fix/workaround:

--- debian/rules.old2020-04-07 15:08:57.0 +
+++ debian/rules2020-05-20 06:43:06.593960217 +
@@ -4,7 +4,11 @@
 
 # less debug info to avoid running out of address space
 ifneq (,$(filter $(DEB_HOST_ARCH), mips mipsel))
-   export DEB_CXXFLAGS_MAINT_APPEND += -g1
+   export DEB_CXXFLAGS_MAINT_APPEND += --param ggc-min-expand=5 -g0
+endif
+
+ifneq (,$(filter $(DEB_HOST_ARCH), i386))
+export DEB_CXXFLAGS_MAINT_APPEND += -ffloat-store
 endif
 
 %:

Bug#960808: node-babel7 7.9.6

[Xavier]

Le 19/05/2020 à 15:10, Xavier a écrit :
> Le 19/05/2020 à 14:37, Xavier a écrit :
>> Le 19/05/2020 à 10:21, Xavier a écrit :
>>> Le 18/05/2020 à 18:50, Pirate Praveen a écrit :


 On Sun, May 17, 2020 at 9:29 pm, Xavier  wrote:
> Control: blocked -1 by 952335
>
> Hi all,
>
> node-babel7 7.9.6 seems ready but it needs node-commander 4.
> node-commander upgrade is blocked by #952335 (uglify-js needs
> node-commander 2)
>

 Can we upload this to experimental till uglify-js is fixed in unstable?
>>>
>>> Yes of course, I'm going to do it
>>
>> Done
>>
 Also which branch you have used for this update?
>>>
>>> Not yet pushed. I'm cleaning my work and will push after
>>
>> Done also. I think babel-7.9.6 is a good candidate for bullseye
> 
> Hi,
> 
> node-babel7 7.9.6 is ready in experimental. It is able to build itself
> and was also tested with twitter-bootstrap4 4.5.0.
> 
> More tests welcome!

I launched a full rebuild of all reverse deps. All good except:

 * filesaver.js

babeljs -o dist/FileSaver.js --presets @babel/env --modules umd \
src/FileSaver.js
error: unknown option '--modules'

 * node-caniuse-lite

Error: Cannot find module 'babel-types'

 * node-string-decoder

Error: Cannot find module 'core-js/es6'
  at Function.Module._resolveFilename (internal/modules
 /cjs/loader.js:636:15)
  at Function.Module._load (internal/modules/cjs/loader.js:562:25)
  at Module.require (internal/modules/cjs/loader.js:692:17)
  at require (internal/modules/cjs/helpers.js:25:18)
  at Object.
 (/usr/share/nodejs/@babel/polyfill/lib/noConflict.js:3:1)

Bug#961097: htop: segfaults after ^Z+fg on x32

[Daniel Lange]

severity 961097 minor
user debian-...@lists.debian.org
usertag 961097 port-x32
--

Nab,

thank you very much for submitting that.
As it's a x32 issue, I have added the appropriate usertag.
It's an unofficial port and has lots of alignment / struct size issues 
which may be the case here as well.


Let's see whether the x32 team pick it up.

Best regards,
Daniel

Bug#961108: openmpi: providing 64-bit MPI

[Drew Parsons]

Source: openmpi
Severity: normal

Bug#953116 requests that petsc be built with 64 bit support for node
indices (for addressing arrays and datasets, not simply 64-bit double).
That's fair enough, it would enable massive systems to be modelled
with our software. Coronavirus protein-membrane docking, say. Ocean
currents and weather forecasting. Formation of galaxies. The big
projects. FEniCS will be able to use it.

If I understand correctly, it's dangerous to simply enable 64-bit in
PETSc alone. It needs to be done all along the computational library
stack.

blas already provides 64-bit builds.

MUMPS can be built for 64-bit handling (64-bit fortran integers), but
its documentation says 64-bit handling needs to be enabled in the
subsystems it uses:
METIS, SCOTCH (and BLAS, LAPACK, already 64-bit enabled)
and MPI.

Of the lower libraries, 64-bit build in MPI (i.e. 64-bit MPI_INTEGER,
counts) will be the most awkward for us, given the complexity of the
mpi packaging (with openmpi, mpich alternatives)

So I'm starting the discussion here with Debian Science and openmpi,
are we ready to take on 64-bit enablement of our entire
computational library stack?

Drew

Bug#961095: mkvtoolnix-gui: mkvtoolnix does not start undefined symbol: _ZN11libmatroska22KaxVideoProjectionType10ClassInfosE

[Bernhard Übelacker]

> On Tue, 2020-05-19 at 22:05 -0300, Mauro Dionisi wrote:
> > Versions of packages mkvtoolnix-gui depends on:
> > ii  libebml4v5 1:1.3.9-dmo0+deb9u1
> > ii  libmatroska6v5 1:1.4.5-dmo1

Hello,
might this be related to the above packages being
from the debian multimedia repository?

Could the issue resolve if these packages get installed
in the buster version?

Kind regards,
Bernhard

Bug#961095: mkvtoolnix-gui: mkvtoolnix does not start undefined symbol: _ZN11libmatroska22KaxVideoProjectionType10ClassInfosE

[Phil Wyett]

On Wed, 2020-05-20 at 09:28 +0200, Bernhard Übelacker wrote:
> > On Tue, 2020-05-19 at 22:05 -0300, Mauro Dionisi wrote:
> > > Versions of packages mkvtoolnix-gui depends on:
> > > ii  libebml4v5 1:1.3.9-dmo0+deb9u1
> > > ii  libmatroska6v5 1:1.4.5-dmo1
> 
> Hello,
> might this be related to the above packages being
> from the debian multimedia repository?
> 
> Could the issue resolve if these packages get installed
> in the buster version?
> 
> Kind regards,
> Bernhard
> 

I did not spot the presence of the dmo packages.

This app works correctly with Debian buster versions of the packages.

Regards

Phil

-- 

*** Playing the game for the games sake. ***

WWW: https://kathenas.org

Twitter: @kathenasorg

IRC: kathenas

GPG: 724AA9B52F024C8B



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

Bug#961096: texlive-binaries: Spurious /bin/ctangle is created

[Hilmar Preuße]

Am 20.05.2020 um 04:10 teilte Igor Liferenko mit:

> Sorry, I just discovered that /bin is a symlink to /usr/bin
> I wonder to that genius who did this...
> 
Package: usrmerge
Version: 23
Installed-Size: 39
Maintainer: Marco d'Itri 
Architecture: all
Depends: debconf (>= 0.5) | debconf-2.0, perl:any, libfile-find-rule-perl
Conflicts: 
Breaks: cruft-ng (<< 0.4.4~), initramfs-tools (<< 0.121~)
Description-en: Convert the system to the merged /usr directories scheme
 This package will automatically convert the system to the merged
 /usr directory scheme, in which the /{bin,sbin,lib}/ directories are
 symlinked to their counterparts in /usr/.

H.
-- 
sigfault
#206401 http://counter.li.org



signature.asc
Description: OpenPGP digital signature

Bug#960808: [Pkg-javascript-devel] Bug#960808: node-babel7 7.9.6

[Xavier]

Le 20/05/2020 à 09:02, Xavier a écrit :
> Le 19/05/2020 à 15:10, Xavier a écrit :
>> Le 19/05/2020 à 14:37, Xavier a écrit :
>>> Le 19/05/2020 à 10:21, Xavier a écrit :
 Le 18/05/2020 à 18:50, Pirate Praveen a écrit :
>
>
> On Sun, May 17, 2020 at 9:29 pm, Xavier  wrote:
>> Control: blocked -1 by 952335
>>
>> Hi all,
>>
>> node-babel7 7.9.6 seems ready but it needs node-commander 4.
>> node-commander upgrade is blocked by #952335 (uglify-js needs
>> node-commander 2)
>>
>
> Can we upload this to experimental till uglify-js is fixed in unstable?

 Yes of course, I'm going to do it
>>>
>>> Done
>>>
> Also which branch you have used for this update?

 Not yet pushed. I'm cleaning my work and will push after
>>>
>>> Done also. I think babel-7.9.6 is a good candidate for bullseye
>>
>> Hi,
>>
>> node-babel7 7.9.6 is ready in experimental. It is able to build itself
>> and was also tested with twitter-bootstrap4 4.5.0.
>>
>> More tests welcome!
> 
> I launched a full rebuild of all reverse deps. All good except:
> 
>  * filesaver.js
> 
> babeljs -o dist/FileSaver.js --presets @babel/env --modules umd \
> src/FileSaver.js
> error: unknown option '--modules'

Unable to reproduce

>  * node-caniuse-lite
> 
> Error: Cannot find module 'babel-types'

Fixed in node-caniuse-lite

>  * node-string-decoder
> 
> Error: Cannot find module 'core-js/es6'
>   at Function.Module._resolveFilename (internal/modules
>  /cjs/loader.js:636:15)
>   at Function.Module._load (internal/modules/cjs/loader.js:562:25)
>   at Module.require (internal/modules/cjs/loader.js:692:17)
>   at require (internal/modules/cjs/helpers.js:25:18)
>   at Object.
>  (/usr/share/nodejs/@babel/polyfill/lib/noConflict.js:3:1)

Fixed in node-babel7 7.9.6+~cs66.71.39-4 (core-js patch)

Bug#958103: chromium: Non-editable shortcuts on the new tab page

[jim_p]

Package: chromium
Followup-For: Bug #958103

I just noticed that the my issue is now gone. Some library must have been
updated since last month, because chromium didn't, and the issue was resolved
automatically. So please close this bug report :)

Sorry for not noticing it earlier. Chromium is my tertiary browser and I open
it very rarely.



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

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

Versions of packages chromium depends on:
ii  chromium-common  81.0.4044.92-1
ii  libasound2   1.2.2-2.1
ii  libatk-bridge2.0-0   2.34.1-3
ii  libatk1.0-0  2.36.0-2
ii  libatspi2.0-02.36.0-2
ii  libavcodec58 10:4.2.2-dmo8
ii  libavformat5810:4.2.2-dmo8
ii  libavutil56  10:4.2.2-dmo8
ii  libc62.30-8
ii  libcairo21.16.0-4
ii  libcups2 2.3.3-1
ii  libdbus-1-3  1.12.16-2
ii  libdrm2  2.4.101-2
ii  libevent-2.1-7   2.1.11-stable-1
ii  libexpat12.2.9-1
ii  libflac8 1.3.3-1
ii  libfontconfig1   2.13.1-4.2
ii  libfreetype6 2.10.1-2
ii  libgbm1  19.3.3-1
ii  libgcc-s110.1.0-1
ii  libgdk-pixbuf2.0-0   2.40.0+dfsg-4
ii  libglib2.0-0 2.64.2-1
ii  libgtk-3-0   3.24.20-1
ii  libharfbuzz0b2.6.4-1
ii  libicu63 63.2-3
ii  libjpeg62-turbo  1:1.5.2-2+b1
ii  libjsoncpp1  1.7.4-3.1
ii  liblcms2-2   2.9-4+b1
ii  libminizip1  1.1-8+b1
ii  libnspr4 2:4.25-1
ii  libnss3  2:3.52-1
ii  libopenjp2-7 2.3.1-1
ii  libopus0 1.3-1+b1
ii  libpango-1.0-0   1.44.7-4
ii  libpangocairo-1.0-0  1.44.7-4
ii  libpng16-16  1.6.37-2
ii  libpulse013.0-5
ii  libre2-6 20200401+dfsg-1
ii  libsnappy1v5 1.1.8-1
ii  libstdc++6   10.1.0-1
ii  libvpx6  1.8.2-dmo1
ii  libwebp6 0.6.1-2+b1
ii  libwebpdemux20.6.1-2+b1
ii  libwebpmux3  0.6.1-2+b1
ii  libx11-6 2:1.6.9-2+b1
ii  libx11-xcb1  2:1.6.9-2+b1
ii  libxcb-dri3-01.14-2
ii  libxcb1  1.14-2
ii  libxcomposite1   1:0.4.5-1
ii  libxcursor1  1:1.2.0-2
ii  libxdamage1  1:1.1.5-2
ii  libxext6 2:1.3.3-1+b2
ii  libxfixes3   1:5.0.3-2
ii  libxi6   2:1.7.9-1
ii  libxml2  2.9.10+dfsg-5
ii  libxrandr2   2:1.5.1-1
ii  libxrender1  1:0.9.10-1
ii  libxslt1.1   1.1.34-4
ii  libxss1  1:1.2.3-1
ii  libxtst6 2:1.2.3-1
ii  zlib1g   1:1.2.11.dfsg-2

Versions of packages chromium recommends:
pn  chromium-sandbox  

Versions of packages chromium suggests:
pn  chromium-driver  
pn  chromium-l10n
pn  chromium-shell   

Versions of packages chromium-common depends on:
ii  x11-utils  7.7+5
ii  xdg-utils  1.1.3-2

Versions of packages chromium-common recommends:
pn  chromium-sandbox 
ii  dunst [notification-daemon]  1.4.1-1
ii  fonts-liberation 1:1.07.4-11
ii  libgl1-mesa-dri  19.3.3-1
pn  libu2f-udev  
ii  notification-daemon  3.20.0-4
pn  system-config-printer
pn  upower   

-- no debconf information

Bug#945556: auto-render extension is built in node-katex 0.10.2

[Pirate Praveen]

Control: tags -1 pending
Control: block -1 by 961005

This is ready in git with new upstream version, but needs new version 
of node-less and node-mini-css-extract-plugin from NEW. If you are keen 
to test it right now, you can get the deb from 
https://people.debian.org/~praveen/new/

Bug#960892: po4a: --srcdir ignored by [po_directory]

[Martin Quinson]

Hello,

your patch was included in an upstream release. The debian package
should be updated shortly.

Thanks for your patience,
Mt.

-- 
You have a problem and decide to use floats. 
Now you have 2.0001 problems.


signature.asc
Description: PGP signature

Bug#956717: ITP: mystiq -- Powerful FFmpeg GUI front-end based on Qt5 and writed in C++

[Otto Kekäläinen]

Hi!

I am sponsoring this effort. It has now passed my review and I've
uploaded it to NEW:
https://ftp-master.debian.org/new/mystiq_20.03.23-1.html

Source now hosted at https://salsa.debian.org/debian/mystiq

-- 
- Otto

Bug#961064: reprotest: use of faketime causes newly created file to have very old modified time

[Holger Levsen]

control: retitle -1 reprotest: should not default to vary time and date
thanks

Hi James,

thanks for your bug report!

On Tue, May 19, 2020 at 02:49:58PM -0400, James Valleroy wrote:
> time(): 1631998736
> touch($cacheFile);
> clearstatcache();  // has no effect
> filemtime($cacheFile): 1589907896
> touch("debug-reprotest");  // a new file, see that it behaves the same way
> filemtime("debug-reprotest"): 1589907896
> 
> The difference between time() and filemtime($cacheFile) is 487+ days,
> the same value is shown passed to faketime in the log.

I'm not sure if this is a bug in reprotest or faketime, however we know about
several scenarios where faketime breaks stuff, thus reprotest should not
vary time and date by default, so that reprotest can be run more easily
and more successfullly in CI tests.

Maybe it's worth to clone this bug and fix the underlying issue too, dunno.


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C

There are no jobs on a dead planet.


signature.asc
Description: PGP signature

Bug#959236: ifenslave bonding doesn't work. Same here

[Miguel A. Novo]

  
  
After the last dist-upgrade bonding stopped
  working. I am using bullseye/sid and 5.6.0-1-amd64 #1 SMP Debian 5.6.7-1 (2020-04-29)
x86_64 GNU/Linux
  
  The "dist-upgrade" warned about not using ifenslave anymore but
  iproute2, so I tried to see how this would affect the server
  implied, and:
  
  This is my /etc/network/interfaces
  
  auto eth0
  auto eth1
  iface eth0 inet manual
  iface eth1 inet manual
  
  auto bond10
  iface bond10 inet static
      address 192.168.10.205
      netmask 255.255.255.0
      network 192.168.10.0
      broadcast 192.168.10.255
      gateway 192.168.10.254
      bond-slaves eth0 eth1
      bond-miimon 100
      bond-mode balance-rr
      bond-downdelay 200
      bond-updelay 200
  
  This is what it happens on every reboot:
  
  may 18 14:58:06 hermes systemd-udevd[374]: Using default interface
  naming scheme 'v245'.
  may 18 14:58:06 hermes systemd-udevd[374]: ethtool:
  autonegotiation is unset or enabled, the speed and duplex are not
  writable.
  may 18 14:58:06 hermes kernel: Ethernet Channel Bonding Driver:
  v3.7.1 (April 27, 2011)
  may 18 14:58:06 hermes ifup[611]:
  /etc/network/if-pre-up.d/ifenslave: 67: Maximum function recursion
  depth (1000) reached
  may 18 14:58:06 hermes ifup[610]: run-parts:
  /etc/network/if-pre-up.d/ifenslave exited with return code 2
  may 18 14:58:06 hermes ifup[584]: ifup: failed to bring up bond10
  may 18 14:58:06 hermes systemd[1]: networking.service: Main
  process exited, code=exited, status=1/FAILURE
  may 18 14:58:06 hermes systemd[1]: networking.service: Failed with
  result 'exit-code'.
  may 18 14:58:06 hermes systemd[1]: Failed to start Raise network
  interfaces.
  
  I have to say that the alternative systemd method to setup
  bonding, bridging, etc. is far to be a simple, clean and clear
  method as it should be, in my humble opinion.
  
  Also, but less important, I am using the traditional NIC naming
  scheme, using "biosdevname=0, net.ifnames=0" with GRUB, and I get
  these messages. I don't understand why (my /etc/udev/rules.d is
  empty):
  
  may 18 14:58:02 hermes systemd-udevd[365]: Using default interface
  naming scheme 'v245'.
  may 18 14:58:02 hermes systemd-udevd[365]: ethtool:
  autonegotiation is unset or enabled, the speed and duplex are not
  writable.
  may 18 14:58:02 hermes systemd-udevd[365]: Could not set
  AlternativeName= or apply AlternativeNamesPolicy= on eth0: File
  exists
  may 18 14:58:02 hermes systemd-udevd[365]: eth0: Could not apply
  link config, ignoring: File exists
  may 18 14:58:02 hermes systemd-udevd[365]: ethtool:
  autonegotiation is unset or enabled, the speed and duplex are not
  writable.
  may 18 14:58:02 hermes systemd-udevd[365]: Could not set
  AlternativeName= or apply AlternativeNamesPolicy= on eth1: File
  exists
  may 18 14:58:02 hermes systemd-udevd[365]: eth1: Could not apply
  link config, ignoring: File exists
  
  Why is systemd trying to do some NIC renaming is a mistery to me.
  
  Regards,

-- 

Miguel A. Novo

  

Bug#961104: t4kcommon FTBFS on !amd64

[Holger Levsen]

Hi Adrian,

On Wed, May 20, 2020 at 09:41:16AM +0300, Adrian Bunk wrote:
> Source: t4kcommon
> Version: 0.1.1-8
> Severity: serious
> Tags: ftbfs
> 
> https://buildd.debian.org/status/package.php?p=t4kcommon&suite=sid
> 
> ...
>dh_missing -a
> dh_missing: warning: usr/lib/aarch64-linux-gnu/libt4k_common.a exists in 
> debian/tmp but is not installed to anywhere (related file: 
> "debian/tmp/usr/lib/x86_64-linux-gnu/libt4k_common.a")
> dh_missing: warning: usr/lib/aarch64-linux-gnu/libt4k_common.la exists in 
> debian/tmp but is not installed to anywhere (related file: 
> "debian/tmp/usr/lib/x86_64-linux-gnu/libt4k_common.la")
> dh_missing: error: missing files, aborting
> ...

thanks for this bug report, I'll fix it ASAP, which could be some days...

I was surprised when I added these lines to debian/not-installed for
the 0.1.1-8 upload:

usr/lib/x86_64-linux-gnu/libt4k_common.a
usr/lib/x86_64-linux-gnu/libt4k_common.la

however as I could confirm with diffoscope that these files were not shipped
previously I thought this was ok. Now I can clearly see the problem this
causes and will look for a better solution...

Help/hints welcome!


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc
Description: PGP signature

Bug#961104: t4kcommon FTBFS on !amd64

[Adrian Bunk]

On Wed, May 20, 2020 at 08:12:35AM +, Holger Levsen wrote:
> Hi Adrian,

Hi Holger,

>...
> I was surprised when I added these lines to debian/not-installed for
> the 0.1.1-8 upload:
> 
> usr/lib/x86_64-linux-gnu/libt4k_common.a
> usr/lib/x86_64-linux-gnu/libt4k_common.la
> 
> however as I could confirm with diffoscope that these files were not shipped
> previously I thought this was ok. Now I can clearly see the problem this
> causes and will look for a better solution...
> 
> Help/hints welcome!

the paths do not include "x86_64-linux-gnu" on other architectures,
you should write these as

  usr/lib/*/libt4k_common.a
  usr/lib/*/libt4k_common.la

> cheers,
>   Holger

cu
Adrian

Bug#960620: openconnect: buffer overflow in certificate handling (CVE-2020-12823)

[Luca Boccassi]

On Tue, 2020-05-19 at 19:34 +0200, Moritz Mühlenhoff wrote:
> On Tue, May 19, 2020 at 11:59:05AM +0100, Luca Boccassi wrote:
> > On Tue, 2020-05-19 at 12:51 +0200, Moritz Mühlenhoff wrote:
> > > On Tue, May 19, 2020 at 10:02:46AM +0100, Luca Boccassi wrote:
> > > > On Thu, 14 May 2020 22:57:44 +0100 Luca Boccassi <
> > > > bl...@debian.org
> > > > > wrote:
> > > > > On Thu, 2020-05-14 at 18:50 +0100, Luca Boccassi wrote:
> > > > > > Package: openconnect
> > > > > > Version: 6.00-1
> > > > > > Severity: important
> > > > > > Tags: security
> > > > > > 
> > > > > > Openconnect is affected by a buffer overflow in certificate 
> > > > > > handling,
> > > > > > that goes back at least to 6.00-1 (old-old-stable).
> > > > > > 
> > > > > > Fixed upstream by:
> > > > > > 
> > > > > > 
> > > > https://gitlab.com/openconnect/openconnect/-/merge_requests/108
> > > > 
> > > > > Dear security team,
> > > > > 
> > > > > I uploaded to old-old-stable on request from the LTS team. How would
> > > > > you like to handle stable and old-stable?
> > > > 
> > > > Ping. Should I do an upload to security-master for buster-security and 
> > > > stretch-security?
> > > 
> > > It's not really clear to me why this was assigned a CVE ID, this doesn't
> > > appear to cross any reasonable trust boundary. Certificates need to come
> > > from a trusted source, otherwise you have many other insecurities at hand.
> > > 
> > > This appears to be "just a bug" (which would seem to reach the bar for
> > > being fixed in a point update), but I can't see why this would need a DSA.
> > > 
> > > I might totally miss something, ofc. So please correct me if I'm wrong :-)
> > > 
> > > Cheers,
> > > Moritz
> > 
> > Hi,
> > 
> > The upstream maintainer agrees that perhaps a CVE was not warranted.
> > The only way this check could be done on an somewhat-external
> > certificate is if it came from a PKCS#11 token, but it's pretty far
> > fetched.
> > 
> > Release notes say:
> > 
> > "This release is brought to you by CVE-2020-12823; a buffer overflow
> > when obtaining a pretty name to describe local certificates, when built
> > against GnuTLS. Note that this isn't used for remote certificates; this
> > is all local (client cert and supporting CAs provided locally) so not
> > easily remotely triggerable."
> 
> Thanks for doublechecking!
> 
> As such, we don't need a DSA. You could target this for a point update
> or we can stuff it in some git branch and piggyback on a potential
> future DSA in case there's a DSA-relevant issue at some point?
> 
> Cheers,
> Moritz

Queueing for the next time around sounds like a good idea - pushed to
the debian/buster branch.

-- 
Kind regards,
Luca Boccassi


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

Bug#961109: ITP: python-retry -- Easy to use retry decorator

[Adam Cecile]

Package: wnpp
Severity: wishlist
Owner: Adam Cecile 

* Package name: python-retry
  Version : 0.9.2
  Upstream Author : invl 
* URL : https://github.com/invl/retry
* License : Apache2
  Programming Lang: Python
  Description : Easy to use retry decorator

 Decorator (or function) to retry failing code featuring:
 .
  - No external dependency (stdlib only)
  - Preserve function signatures (pip install decorator)
  - Original traceback, easy to debug
 .
 This package installs the library for Python 3.

I intend to package this module inside DPMT.

Bug#961104: t4kcommon FTBFS on !amd64

[Holger Levsen]

On Wed, May 20, 2020 at 11:17:49AM +0300, Adrian Bunk wrote:
> the paths do not include "x86_64-linux-gnu" on other architectures,

I was aware of this...

> you should write these as
>   usr/lib/*/libt4k_common.a
>   usr/lib/*/libt4k_common.la

but not that I could use wildcards here. Thank you!


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C

In Europe there are people prosecuted by courts because they saved other people
from drowning in the  Mediterranean Sea.  That is almost as absurd  as if there
were people being prosecuted because they save humans from drowning in the sea.


signature.asc
Description: PGP signature

Bug#961110: racon FTBFS on i386: test failures

[Adrian Bunk]

Source: racon
Version: 1.4.13-1
Severity: important
Tags: ftbfs

https://buildd.debian.org/status/fetch.php?pkg=racon&arch=i386&ver=1.4.13-1&stamp=1586871206&raw=0

...
[==] 15 tests from 2 test suites ran. (1192254 ms total)
[  PASSED  ] 11 tests.
[  FAILED  ] 4 tests, listed below:
[  FAILED  ] RaconPolishingTest.ConsensusWithQualitiesLargerWindow
[  FAILED  ] RaconPolishingTest.FragmentCorrectionWithQualitiesFull
[  FAILED  ] RaconPolishingTest.FragmentCorrectionWithoutQualitiesFull
[  FAILED  ] RaconPolishingTest.FragmentCorrectionWithQualitiesFullMhap

 4 FAILED TESTS
make[1]: *** [debian/rules:18: override_dh_auto_test] Error 1


Fix/workaround:

--- debian/rules.old2020-04-13 16:51:32.0 +
+++ debian/rules2020-05-20 08:23:56.849314299 +
@@ -4,6 +4,10 @@
 
 DEB_CMAKE_EXTRA_FLAGS = -Dracon_build_tests=ON
 
+ifneq (,$(filter $(DEB_HOST_ARCH), i386))
+export DEB_CXXFLAGS_MAINT_APPEND += -ffloat-store
+endif
+
 %:
dh $@ --buildsystem=cmake
 

Bug#961111: add an option to specify build-only components in watch

[Pirate Praveen]

Package: pkg-js-tools
Version: 0.9.36
Severity: wishlist

Currently we use debian/build_modules to add build only modules, but 
that is manual and we cannot use uscan like other components. Can we 
add an option to watch file to specify a component is build-only and 
need not be installed in the binary package?


For example katex-fonts in node-katex, I'd like to use uscan to 
download the compnent, but I don't want it installed in node_modules in 
the final package. May be an option to specify which directory it 
should be symlinked to, for example, in this case, I want it symlinked 
to submodules and not node_modules (node_modules can be the default if 
nothing is specified).

Bug#960912: linux-image-5.5.0-0.bpo.2-amd64: Machine freeze from general protection fault in i915

[Pekka Paalanen]

It froze again:

May 20 11:48:03 eldfell kernel: general protection fault:  [#1] SMP PTI
May 20 11:48:03 eldfell kernel: CPU: 1 PID: 1393 Comm: Xorg Not tainted 
5.5.0-0.bpo.2-amd64 #1 Debian 5.5.17-1~bpo10+1
May 20 11:48:03 eldfell kernel: Hardware name: ASUS All Series/Z97-A, BIOS 2501 
04/27/2015
May 20 11:48:03 eldfell kernel: RIP: 0010:kmem_cache_alloc+0x74/0x220
May 20 11:48:03 eldfell kernel: Code: 9e 01 00 00 4d 8b 06 65 49 8b 50 08 65 4c 
03 05 02 d1 ba 56 49 8b 28 48 85 ed 0f 84 89 01 00 00 41 8b 46 20 49 8b 3e 48 
01 e8 <48> 8b 18 48 89 c1 49 33 9e 70 01 00 00 48 89 e8 48 0
May 20 11:48:03 eldfell kernel: RSP: 0018:bb50c076ba28 EFLAGS: 00010202
May 20 11:48:03 eldfell kernel: RAX: 7ee5051c9a3e1783 RBX:  
RCX: 
May 20 11:48:03 eldfell kernel: RDX: 00fb27f4 RSI: 0cc0 
RDI: 00031440
May 20 11:48:03 eldfell kernel: RBP: 7ee5051c9a3e1783 R08: 9db487a71440 
R09: 0009
May 20 11:48:03 eldfell kernel: R10: 9db46f1b5180 R11: 0010 
R12: 0cc0
May 20 11:48:03 eldfell kernel: R13: c0e85669 R14: 9db347c239c0 
R15: 9db347c239c0
May 20 11:48:03 eldfell kernel: FS:  7f0213e08f00() 
GS:9db487a4() knlGS:
May 20 11:48:03 eldfell kernel: CS:  0010 DS:  ES:  CR0: 
80050033
May 20 11:48:03 eldfell kernel: CR2: 7f01c71b CR3: 00023d24e001 
CR4: 001606e0
May 20 11:48:03 eldfell kernel: Call Trace:
May 20 11:48:03 eldfell kernel:  i915_active_ref+0x59/0x170 [i915]
May 20 11:48:03 eldfell kernel:  i915_vma_move_to_active+0x24/0x150 [i915]
May 20 11:48:03 eldfell kernel:  i915_gem_do_execbuffer+0xd53/0x1930 [i915]
May 20 11:48:03 eldfell kernel:  ? kmem_cache_free+0x28d/0x2b0
May 20 11:48:03 eldfell kernel:  ? unix_stream_read_generic+0x206/0x950
May 20 11:48:03 eldfell kernel:  ? __switch_to_asm+0x34/0x70
May 20 11:48:03 eldfell kernel:  ? _cond_resched+0x15/0x30
May 20 11:48:03 eldfell kernel:  ? i915_gem_execbuffer2_ioctl+0x8e/0x3d0 [i915]
May 20 11:48:03 eldfell kernel:  i915_gem_execbuffer2_ioctl+0x1df/0x3d0 [i915]
May 20 11:48:03 eldfell kernel:  ? i915_gem_execbuffer_ioctl+0x2e0/0x2e0 [i915]
May 20 11:48:03 eldfell kernel:  drm_ioctl_kernel+0xac/0xf0 [drm]
May 20 11:48:03 eldfell kernel:  drm_ioctl+0x201/0x3a0 [drm]
May 20 11:48:03 eldfell kernel:  ? i915_gem_execbuffer_ioctl+0x2e0/0x2e0 [i915]
May 20 11:48:03 eldfell kernel:  do_vfs_ioctl+0xa4/0x680
May 20 11:48:03 eldfell kernel:  ksys_ioctl+0x60/0x90
May 20 11:48:03 eldfell kernel:  __x64_sys_ioctl+0x16/0x20
May 20 11:48:03 eldfell kernel:  do_syscall_64+0x52/0x170
May 20 11:48:03 eldfell kernel:  entry_SYSCALL_64_after_hwframe+0x44/0xa9
May 20 11:48:03 eldfell kernel: RIP: 0033:0x7f0214538427
May 20 11:48:03 eldfell kernel: Code: 00 00 90 48 8b 05 69 aa 0c 00 64 c7 00 26 
00 00 00 48 c7 c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 b8 10 00 00 00 
0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 39 aa 0c 00 f7 d
May 20 11:48:03 eldfell kernel: RSP: 002b:7fff06b73e78 EFLAGS: 0246 
ORIG_RAX: 0010
May 20 11:48:03 eldfell kernel: RAX: ffda RBX: 563c73441340 
RCX: 7f0214538427
May 20 11:48:03 eldfell kernel: RDX: 7fff06b73ec0 RSI: 40406469 
RDI: 000c
May 20 11:48:03 eldfell kernel: RBP: 7fff06b73ec0 R08: 563c7347f5c0 
R09: 7f01e4d2d4e4
May 20 11:48:03 eldfell kernel: R10: 7f01e4d2d494 R11: 0246 
R12: 40406469
May 20 11:48:03 eldfell kernel: R13: 000c R14:  
R15: 
May 20 11:48:03 eldfell kernel: Modules linked in: xt_MASQUERADE 
nf_conntrack_netlink xfrm_user xfrm_algo nft_counter nft_chain_nat xt_addrtype 
nft_compat nf_tables nfnetlink xt_conntrack nf_nat nf_conntrack nf_defrag_
May 20 11:48:03 eldfell kernel:  usb_storage sr_mod cdrom sd_mod hid_generic 
usbhid hid crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel 
xhci_pci xhci_hcd sata_via ahci libahci libata ehci_pci ehci_hcd ae
May 20 11:48:03 eldfell kernel: ---[ end trace 42bc1353f2cc30da ]---
May 20 11:48:03 eldfell kernel: RIP: 0010:kmem_cache_alloc+0x74/0x220
May 20 11:48:03 eldfell kernel: Code: 9e 01 00 00 4d 8b 06 65 49 8b 50 08 65 4c 
03 05 02 d1 ba 56 49 8b 28 48 85 ed 0f 84 89 01 00 00 41 8b 46 20 49 8b 3e 48 
01 e8 <48> 8b 18 48 89 c1 49 33 9e 70 01 00 00 48 89 e8 48 0
May 20 11:48:03 eldfell kernel: RSP: 0018:bb50c076ba28 EFLAGS: 00010202
May 20 11:48:03 eldfell kernel: RAX: 7ee5051c9a3e1783 RBX:  
RCX: 
May 20 11:48:03 eldfell kernel: RDX: 00fb27f4 RSI: 0cc0 
RDI: 00031440
May 20 11:48:03 eldfell kernel: RBP: 7ee5051c9a3e1783 R08: 9db487a71440 
R09: 0009
May 20 11:48:03 eldfell kernel: R10: 9db46f1b5180 R11: 0010 
R12: 0cc0
May 20 11:48:03 eldfell kernel: R13: c0e85669 R14: 9db347c239c0 
R15: 9db347c239c0
May 20 11:48:03 eldfell k

Bug#923501: clementine: blank window when unminimising from system tray

[Thomas Pierson]

Hi Aurélien, Geoff,

On 01/03/2019 01:37, Aurélien Murith wrote:
> If Clementine is minimised in the system tray, clicking on its icon only opens
> a blank window from which you cannot handle anything. You have to quit and
> restart the program to get a usable window again.
> Clementine 1.3.1 on KDE Plasma 5.14.5 on current Debian Testing

I can't reproduce this bug with the last version of Clementine into
Debian unstable/testing and using Plasma. Can you tell me if you still
reproduce this?

Thanks,
Thomas Pierson



signature.asc
Description: OpenPGP digital signature

Bug#926539: rootskel: steal-ctty no longer works on s390x

[Valentin Vidić]

Similar change for console name on s390x was not accepted:

  https://lkml.org/lkml/2020/5/19/854

so please fix in rootskel.

-- 
Valentin

Bug#926539: rootskel: steal-ctty no longer works on s390x

[John Paul Adrian Glaubitz]

On 5/20/20 11:17 AM, John Paul Adrian Glaubitz wrote:
> I don't see any discussion in this thread. I would like to know the reasoning
> why kernel upstream thinks that this naming inconsistency is correct. It
> makes no sense, in my opinion and it can potentially trigger more problems.

Ah, sorry. I was seeing the cached version of the thread, refreshing helped.

In any case, the SPARC kernel maintainer (Dave Miller) had the same argument
that it would potentially break existing setups but eventually I could
convince him that the change was right.

Not sure which distributions he has in mind.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#926539: rootskel: steal-ctty no longer works on s390x

[John Paul Adrian Glaubitz]

Hi!

On 5/20/20 11:00 AM, Valentin Vidić wrote:
> Similar change for console name on s390x was not accepted:
> 
>   https://lkml.org/lkml/2020/5/19/854
> 
> so please fix in rootskel.

I don't see any discussion in this thread. I would like to know the reasoning
why kernel upstream thinks that this naming inconsistency is correct. It
makes no sense, in my opinion and it can potentially trigger more problems.

Also, this bug report should be merged with the other one that I referenced
yesterday.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#961111: [Pkg-javascript-devel] Bug#961111: add an option to specify build-only components in watch

[Xavier]

Le 20/05/2020 à 10:53, Pirate Praveen a écrit :
> Package: pkg-js-tools
> Version: 0.9.36
> Severity: wishlist
> 
> Currently we use debian/build_modules to add build only modules, but
> that is manual and we cannot use uscan like other components. Can we add
> an option to watch file to specify a component is build-only and need
> not be installed in the binary package?
> 
> For example katex-fonts in node-katex, I'd like to use uscan to download
> the compnent, but I don't want it installed in node_modules in the final
> package. May be an option to specify which directory it should be
> symlinked to, for example, in this case, I want it symlinked to
> submodules and not node_modules (node_modules can be the default if
> nothing is specified).

Hi,

you can do it: if you list components in debian/nodejs/submodules, only
listed components will be installed

Bug#961112: RFS: nornet/1.4.8-1

[Thomas Dreibholz]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

  * Package name: nornet
Version: 1.4.8-1
Upstream Author: Thomas Dreibholz mailto:dre...@simula.no>>
  * URL: https://www.nntb.no
  * License: CC-BY CC-BY-SA GPL-3+ MIT selected SIL-OFL
  * Section: net

NorNet is a testbed for multi-homed systems. This package contains the
management software for the testbed's infrastructure management software.

"nornet " builds these binary packages:

  * nornet-api - API tools for the NorNet system environment
  * nornet-artwork - Artwork tools for the NorNet system environment
  * nornet-autoupdate - Auto Update tools for the NorNet system environment
  * nornet-database - Database tools for the NorNet system environment
  * nornet-development - Development tools for the NorNet system environment
  * nornet-display - Display tools for the NorNet system environment
  * nornet-filesrv - File Server tools for the NorNet system environment
  * nornet-gatekeeper - Gatekeeper tools for the NorNet system environment
  * nornet-management - Management tools for the NorNet system environment
  * nornet-monitor - Monitor tools for the NorNet system environment
  * nornet-node - Node Control tools for the NorNet system environment
  * nornet-server - Server tools for the NorNet system environment
  * nornet-timesrv - Time Server tools for the NorNet system environment
  * nornet-tunnelbox - Tunnelbox Control tools for the NorNet system
environment
  * nornet-websrv - Web Server tools for the NorNet system environment
  * nornet-wikisrv - Wiki Server tools for the NorNet system environment
  * nornet-x11 - X11 Login tools for the NorNet system environment

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

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

dget -x https://mentors.debian.net/debian/pool/main/n/nornet/nornet_1.4.8-1.dsc

More information about "nornet " can be obtained
from https://www.nntb.no.

Most recent changelog entry:

nornet (1.4.8-1ubuntu1) bionic; urgency=medium

  * New upstream release.
  * debian/control: Updated standards version to 4.5.0.2.

-- Thomas Dreibholz > Tue, 05 May 2020
13:16:54 +0200

-- 
Best regards / Mit freundlichen Grüßen / Med vennlig hilsen

===
 Thomas Dreibholz

 Simula@OsloMet -- Simula Metropolitan Centre for Digital Engineering
 Centre for Resilient Networks and Applications
 Pilestredet 52
 0167 Oslo, Norway
---
 E-Mail: dre...@simula.no
 Homepage:   http://simula.no/people/dreibh
===



signature.asc
Description: OpenPGP digital signature

Bug#961113: RFS: rsplib/3.2.5-1

[Thomas Dreibholz]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

  * Package name: rsplib
Version: 3.2.5-1
Upstream Author: Thomas Dreibholz mailto:dre...@iem.uni-due.de>>
  * URL: https://www.uni-due.de/~be0001/rserpool/download/
  * License: GPL-3+
  * Section: net

RSPLIB is the Open Source implementation of the IETF Reliable Server
Pooling (RSerPool) architecture, a novel framework for pool and session
management. The Reliable Server Pooling (RSerPool) architecture (defined
by RFC 5351 to RFC 5356) is an overlay network framework to provide
server replication and session failover capabilities to its
applications. Server redundancy leads to load distribution and load
balancing, which are also covered by RSerPool. But in strong contrast to
other solutions in the area of cloud and high-performance computing, the
fundamental property of RSerPool is to be "lightweight", i.e. it can
also be used on devices providing only meagre memory and CPU resources
(e.g. embedded systems like telecommunications equipment or routers).

"rsplib " builds
these binary packages:

  * libcpprspserver3 - C++ RSerPool client/server API library
  * libcpprspserver-dev - headers of the C++ RSerPool client/server API
library
  * librsplib3 - RSerPool client/server API library for session management
  * librsplib-dev - headers of the RSerPool client/server API library rsplib
  * rsplib-all - RSerPool implementation RSPLIB
  * rsplib-doc - documentation of the RSerPool implementation RSPLIB
  * rsplib-fgp-cfgfiles - RSerPool Fractal Generator Service example
input files
  * rsplib-registrar - RSerPool Registrar service
  * rsplib-services - RSerPool example services
  * rsplib-tools - RSerPool test tools

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

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

dget -x https://mentors.debian.net/debian/pool/main/r/rsplib/rsplib_3.2.5-1.dsc

More information about "rsplib
" can be obtained
from https://www.uni-due.de/~be0001/rserpool/download/.

Most recent changelog entry:

rsplib (3.2.5-1ubuntu1) focal; urgency=medium

  * New upstream release.
  * debian/control: Updated standards version to 4.5.0.0.

-- Thomas Dreibholz > Fri, 07 Feb 2020
13:21:02 +0100

-- 
Best regards / Mit freundlichen Grüßen / Med vennlig hilsen

===
 Thomas Dreibholz

 Simula@OsloMet -- Simula Metropolitan Centre for Digital Engineering
 Centre for Resilient Networks and Applications
 Pilestredet 52
 0167 Oslo, Norway
---
 E-Mail: dre...@simula.no
 Homepage:   http://simula.no/people/dreibh
===



signature.asc
Description: OpenPGP digital signature

Bug#961114: RFS: sctplib/1.0.25-1

[Thomas Dreibholz]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

  * Package name: sctplib
Version: 1.0.25-1
Upstream Author: Thomas Dreibholz mailto:dre...@iem.uni-due.de>>
  * URL: https://www.uni-due.de/~be0001/sctplib/
  * License: LGPL-3+
  * Section: net

The SCTPLIB library is a prototype implementation of the Stream Control
Transmission Protocol (SCTP), a message-oriented reliable transport
protocol that supports multi-homing, and multiple message streams
multiplexed within an SCTP connection (also named association). SCTP is
described in RFC 4960. See https://www.uni-due.de/~be0001/sctplib/ for
details. The API of the library is modeled after Section 10 of RFC 4960,
and most parameters and functions should be self-explanatory to the user
familiar with this document. In addition to these interface functions
between an Upper Layer Protocol (ULP) and an SCTP instance, the library
also provides a number of helper functions that can be used to manage
callbacks and timers, as well as UDP sockets for simple IPC.
Furthermore, SCTPLIB provides support for UDP encapsulation, making it
possible to co-exist with kernel SCTP implementations.

"sctplib " builds these binary
packages:

  * libsctplib1 - User-space implementation of the SCTP protocol RFC 4960
  * libsctplib-dev - Headers and libraries of the user-space SCTP
implementation SCTPLIB
  * sctplib-doc - Documentation of the user-space SCTP implementation
SCTPLIB

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

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

dget -x 
https://mentors.debian.net/debian/pool/main/s/sctplib/sctplib_1.0.25-1.dsc

More information about "sctplib
" can be obtained from
https://www.uni-due.de/~be0001/sctplib/.

Most recent changelog entry:

sctplib (1:1.0.25-1ubuntu1) focal; urgency=medium

  * New upstream release.
  * debian/control: Updated standards version to 4.5.0.0.

-- Thomas Dreibholz > Fri, 07 Feb 2020
13:21:57 +0100

-- 
Best regards / Mit freundlichen Grüßen / Med vennlig hilsen

===
 Thomas Dreibholz

 Simula@OsloMet -- Simula Metropolitan Centre for Digital Engineering
 Centre for Resilient Networks and Applications
 Pilestredet 52
 0167 Oslo, Norway
---
 E-Mail: dre...@simula.no
 Homepage:   http://simula.no/people/dreibh
===



signature.asc
Description: OpenPGP digital signature

Bug#961115: RFS: socketapi/2.2.18-1

[Thomas Dreibholz]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

  * Package name: socketapi
Version: 2.2.18-1
Upstream Author: Thomas Dreibholz mailto:dre...@iem.uni-due.de>>
  * URL: https://www.uni-due.de/~be0001/sctplib/
  * License: GPL-3+
  * Section: net

SocketAPI is the socket API library for the SCTPLIB user-space SCTP
implementation.

"socketapi " builds these
binary packages:

  * libsctpsocket2 - Socket API library for sctplib
  * libsctpsocket-dev - Development package for Socket-API

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

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

dget -x 
https://mentors.debian.net/debian/pool/main/s/socketapi/socketapi_2.2.18-1.dsc

More information about "socketapi
" can be obtained from
https://www.uni-due.de/~be0001/sctplib/.

Most recent changelog entry:

socketapi (2:2.2.18-1ubuntu1) focal; urgency=medium

  * New upstream release.
  * debian/control: Updated standards version to 4.5.0.0.

-- Thomas Dreibholz > Fri, 07 Feb 2020
13:21:59 +0100

-- 
Best regards / Mit freundlichen Grüßen / Med vennlig hilsen

===
 Thomas Dreibholz

 Simula@OsloMet -- Simula Metropolitan Centre for Digital Engineering
 Centre for Resilient Networks and Applications
 Pilestredet 52
 0167 Oslo, Norway
---
 E-Mail: dre...@simula.no
 Homepage:   http://simula.no/people/dreibh
===



signature.asc
Description: OpenPGP digital signature

Bug#960660: cyrus-imapd: Test failure on armhf (at least on armv8)

[Xavier]

Hi,

with upstream help; I just built cyrus-imapd_3.2.0-4 which may fix this
issue.
@Adrian, could you test this on your armv8 ?

Cheers,
Xavier

Bug#960660: cyrus-imapd: Test failure on armhf (at least on armv8)

[Xavier]

Le 20/05/2020 à 11:26, Xavier a écrit :
> Hi,
> 
> with upstream help; I just built cyrus-imapd_3.2.0-4 which may fix this
> issue.
> @Adrian, could you test this on your armv8 ?
> 
> Cheers,
> Xavier

Note that there are still 4 tests that fail [1] (failed already at least
with i386). I'm waiting for [buildd] results.

[1]:
https://github.com/cyrusimap/cyrus-imapd/issues/3040#issuecomment-631367737
[buildd]:
https://buildd.debian.org/status/logs.php?pkg=cyrus-imapd&ver=3.2.0-4

Bug#888705: abseil-cpp packaging

[GCS]

On Tue, May 19, 2020 at 6:28 PM Benjamin Barenblat  wrote:
> Okay, we’re all set. I’ve pushed my work to
> https://salsa.debian.org/debian/abseil, and both command-line linking
> and CMake integration work. Comments and suggestions are welcome – if I
> don’t hear anything in the next day or two, I’ll go ahead and upload to
> NEW.
 Please do build static libraries with the following patch. Even
Google projects link with static Abseil libraries and the project
itself also allow it[1]:
"ALLOWED: Distribute a static library built with an LTS branch of
Abseil. Because LTS branches use inline namespaces for all absl::
symbols, collisions between potential Abseil “versions” should not
occur, though your library may incur code bloat."

I do not want to push it without being a co-maintainer or without
discussion, but please do it yourself.

Thanks,
Laszlo/GCS
[1] https://abseil.io/about/releases
diff -Nru abseil-0~20200225.2/debian/libabsl-dev.install abseil-0~20200225.2/debian/libabsl-dev.install
--- abseil-0~20200225.2/debian/libabsl-dev.install	2020-05-12 22:16:31.0 +
+++ abseil-0~20200225.2/debian/libabsl-dev.install	2020-05-20 09:43:24.0 +
@@ -13,5 +13,6 @@
 # the License.
 
 usr/include/absl
+usr/lib/*/*.a
 usr/lib/*/*.so
 usr/lib/*/cmake
diff -Nru abseil-0~20200225.2/debian/rules abseil-0~20200225.2/debian/rules
--- abseil-0~20200225.2/debian/rules	2020-05-12 22:16:31.0 +
+++ abseil-0~20200225.2/debian/rules	2020-05-20 09:43:24.0 +
@@ -15,12 +15,24 @@
 
 export DEB_BUILD_MAINT_OPTIONS = hardening=+bindnow
 
-%:
-	dh $@
+override_dh_auto_clean:
+	$(RM) -r $(CURDIR)/shared
+	$(RM) -r $(CURDIR)/static
 
 override_dh_auto_configure:
-	dh_auto_configure -- -DCMAKE_CXX_STANDARD=14 -DBUILD_SHARED_LIBS=ON
+	dh_auto_configure -Bshared \
+		-- -DCMAKE_CXX_STANDARD=14 -DBUILD_SHARED_LIBS=ON
+	dh_auto_configure -Bstatic \
+		-- -DCMAKE_CXX_STANDARD=14 -DBUILD_SHARED_LIBS=OFF
+
+override_dh_auto_build:
+	dh_auto_build -Bshared
+	dh_auto_build -Bstatic
 
 override_dh_auto_install:
-	dh_auto_install
+	dh_auto_install -Bshared
+	dh_auto_install -Bstatic
 	find debian/tmp -type d -empty -delete
+
+%:
+	dh $@

Bug#702110: hello

[robert55514 anderson]

helloone.pdf
Description: Adobe PDF document

Bug#942249: ITP: inkscape-ext-textext -- Re-editable LaTeX graphics for Inkscape

[Adrien Grellier]

Hi, 

Thank your for your package of TexText. I successfully compile your package for 
Buster, for a user of our laboratory, but failed to use it. 

Upstream developpers released a new version recently (1.0.1), do you intend to 
package it ? It can solve the bugs I encountered. 

Kind regards, 

Adrien 

-- 

Adrien Grellier < adrien.grell...@ec-nantes.fr > (02 40 37 15 55) 
Administrateur système du LHEEA 
CNRS – École Centrale de Nantes 

Bug#959225: libcap-ng: diff for NMU version 0.7.9-2.2

[Håvard Flaget Aasen]

Package: libcap-ng
Version: 0.7.9-2.1
Severity: normal
Tags: patch  pending

Dear maintainer,

I've prepared an NMU for libcap-ng (versioned as 0.7.9-2.2) and
uploaded it to mentors. Please feel free to tell me if I
should remove it.

Regards,
Håvard
diff -Nru libcap-ng-0.7.9/debian/changelog libcap-ng-0.7.9/debian/changelog
--- libcap-ng-0.7.9/debian/changelog	2019-10-17 23:30:59.0 +0200
+++ libcap-ng-0.7.9/debian/changelog	2020-05-19 14:54:57.0 +0200
@@ -1,3 +1,13 @@
+libcap-ng (0.7.9-2.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * d/control
+- Remove dependency on linux-kernel-headers closes: #959225
+- Remove libattr1-dev as build dependency closes: #953925
+- Build for default python3 version closes: #943627
+
+ -- Håvard Flaget Aasen   Tue, 19 May 2020 14:54:57 +0200
+
 libcap-ng (0.7.9-2.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru libcap-ng-0.7.9/debian/control libcap-ng-0.7.9/debian/control
--- libcap-ng-0.7.9/debian/control	2019-10-17 23:30:14.0 +0200
+++ libcap-ng-0.7.9/debian/control	2020-05-19 14:53:03.0 +0200
@@ -5,11 +5,10 @@
 dh-autoreconf,
 dh-python ,
 autotools-dev,
-libattr1-dev,
-linux-kernel-headers,
+linux-libc-dev,
 swig ,
-libpython3-all-dev ,
-python3-all-dev:any 
+libpython3-dev ,
+python3-dev:any 
 Standards-Version: 3.9.8
 Section: libs
 Homepage: http://people.redhat.com/sgrubb/libcap-ng

Bug#961116: gnome-shell-extension-suspend-button: Does not work with gnome 3.36

[Tobias Frost]

Package: gnome-shell-extension-suspend-button
Version: 0~git20191005-1
Severity: serious
Control: tags -1 upstream
Control: forwarded -1 
https://github.com/laserb/gnome-shell-extension-suspend-button/issues/53

This extension is currently not compatible with gnome 3.36 and it is unclear if 
it will be
adapted to he new interface as upstream seems a bit inactive. 

Filing this bug to keep this extension out of testing and to see if this gets 
resolved

Note: gnome 3.36 has built-in facilities like this plugin, but requires 
additional click.

-- 
tobi

Bug#901382: node-katex is now split into katex (which include katex command and provides node-katex), libjs-katex and fonts-katex

[Pirate Praveen]

Control: block -1 by 961005

This is fixed in git along with update to 0.10.2 but blocked by 
node-less (need new upstream version).

Bug#961111: [Pkg-javascript-devel] Bug#961111: Bug#961111: add an option to specify build-only components in watch

[Pirate Praveen]

On Wed, May 20, 2020 at 11:03 am, Xavier  wrote:

Le 20/05/2020 à 10:53, Pirate Praveen a écrit :

 Package: pkg-js-tools
 Version: 0.9.36
 Severity: wishlist

 Currently we use debian/build_modules to add build only modules, but
 that is manual and we cannot use uscan like other components. Can 
we add
 an option to watch file to specify a component is build-only and 
need

 not be installed in the binary package?

 For example katex-fonts in node-katex, I'd like to use uscan to 
download
 the compnent, but I don't want it installed in node_modules in the 
final

 package. May be an option to specify which directory it should be
 symlinked to, for example, in this case, I want it symlinked to
 submodules and not node_modules (node_modules can be the default if
 nothing is specified).


Hi,

you can do it: if you list components in debian/nodejs/submodules, 
only

listed components will be installed


Thanks, that works. Would it be a lot of work to do it in watch as a 
new option? Just checking if it can be done at single place easily.

Bug#958843: please don't depend on vim-nox

[Raphael Medaer]

Hi John,

The next version of vim-editorconfig (1.0.0) 
https://github.com/editorconfig/editorconfig-vim/pull/119.

I discussed with Michael Fladischer (the original package maintainer) about the 
upgrade.
As soon as the https://github.com/editorconfig/editorconfig-vim/issues/143 I 
will upgrade the package and remove the dependency(ies) no more required 
(including vim-nox).

Kind regards,

—
Raphaël Medaer 

​

Bug#961117: iptables: Packet and byte counters in default policy stay zero

[Zeilinger Markus]

Package: iptables
Version: 1.8.2-4
Severity: normal

Dear Maintainer,

when setting the default policy of a chain in the filter table to DROP
and testing with traffic that is not handled by another rule in the
chain and so it should be handled by the default policy the packet and
byte counters stay zero.

Example rule setup:

Chain INPUT (policy DROP 0 packets, 0 bytes)
num   pkts bytes target prot opt
in out source   destination 
1 9207   15M ACCEPT all  
--  *  *   0.0.0.0/00.0.0.0/0state ESTABLISHED
22   120 ACCEPT tcp  
--  ens40  *   172.16.61.0/24   172.16.61.128tcp
spts:1024:65535 dpt:22 state NEW

Chain FORWARD (policy DROP 0 packets, 0 bytes)
num   pkts bytes target prot opt
in out source   destination 
1  563 89057 ACCEPT all  
--  *  *   0.0.0.0/00.0.0.0/0state
ESTABLISHED
20 0 ACCEPT tcp  
--  ens38  ens33   172.16.254.0/24  0.0.0.0/0tcp
spts:1024:65535 multiport dports 80,443 state NEW

Chain OUTPUT (policy DROP 0 packets, 0 bytes)
num   pkts bytes target prot opt
in out source   destination 
1 5136  592K ACCEPT all  
--  *  *   0.0.0.0/00.0.0.0/0state
ESTABLISHED

Now when sending an ICMP ping from a system behind the firewall to an
IP
the firewall has (e. g. 172.15.61.128) which is no allowed by this rule
setup the pings get blocked but the counters in the iptables -nvL
--line-numbers output stay zero.

I also verified the same behaviour on a second freshly installed Debian
10 system.

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

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

Versions of packages iptables depends on:
ii  libc62.28-10
ii  libip4tc01.8.2-4
ii  libip6tc01.8.2-4
ii  libiptc0 1.8.2-4
ii  libmnl0  1.0.4-2
ii  libnetfilter-conntrack3  1.0.7-1
ii  libnfnetlink01.0.1-3+b1
ii  libnftnl11   1.1.2-2
ii  libxtables12 1.8.2-4

Versions of packages iptables recommends:
pn  nftables  

Versions of packages iptables suggests:
ii  kmod  26-1

-- no debconf information
-- 

Dipl.-Ing. Markus Zeilinger
Studiengänge Sichere Informationssysteme
Fakultät für Informatik, Kommunikation und Medien

FH Oberösterreich
FH-Gebäude 1, Raum A 005
Softwarepark 11
4232 Hagenberg
Tel.: +43 (0) 5 0804 22524
Mobil: +43 (0) 664 8048422524
Fax: +43 (0) 5 0804 22599
E-Mail: markus.zeilin...@fh-hagenberg.at
Web: www.fh-ooe.at

Firmenbuchgericht/Court of registry: Landesgericht Wels
Firmenbuchnummer/Company registration: FN 236729 g


smime.p7s
Description: S/MIME cryptographic signature

Bug#961111: [Pkg-javascript-devel] Bug#961111: Bug#961111: add an option to specify build-only components in watch

[Xavier]

Le 20 mai 2020 12:24:05 GMT+02:00, Pirate Praveen  a 
écrit :
>
>
>On Wed, May 20, 2020 at 11:03 am, Xavier  wrote:
>> Le 20/05/2020 à 10:53, Pirate Praveen a écrit :
>>>  Package: pkg-js-tools
>>>  Version: 0.9.36
>>>  Severity: wishlist
>>> 
>>>  Currently we use debian/build_modules to add build only modules, but
>>>  that is manual and we cannot use uscan like other components. Can 
>>> we add
>>>  an option to watch file to specify a component is build-only and 
>>> need
>>>  not be installed in the binary package?
>>> 
>>>  For example katex-fonts in node-katex, I'd like to use uscan to 
>>> download
>>>  the compnent, but I don't want it installed in node_modules in the 
>>> final
>>>  package. May be an option to specify which directory it should be
>>>  symlinked to, for example, in this case, I want it symlinked to
>>>  submodules and not node_modules (node_modules can be the default if
>>>  nothing is specified).
>> 
>> Hi,
>> 
>> you can do it: if you list components in debian/nodejs/submodules, 
>> only
>> listed components will be installed
>
>Thanks, that works. Would it be a lot of work to do it in watch as a 
>new option? Just checking if it can be done at single place easily.

Modifying debian/watch requires a pkg-js-tools-specific change in uscan, not 
easy


-- 
Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma 
brièveté.

Bug#926539: rootskel: steal-ctty no longer works on s390x

[Valentin Vidić]

On Wed, May 20, 2020 at 11:19:53AM +0200, John Paul Adrian Glaubitz wrote:
> Ah, sorry. I was seeing the cached version of the thread, refreshing helped.
> 
> In any case, the SPARC kernel maintainer (Dave Miller) had the same argument
> that it would potentially break existing setups but eventually I could
> convince him that the change was right.
> 
> Not sure which distributions he has in mind.

It is hard to tell, but it seems the current state is hardcoded
in different places:

https://www.redhat.com/archives/libguestfs/2017-May/msg00068.html
https://www.ibm.com/support/knowledgecenter/linuxonibm/com.ibm.linux.z.lhdd/lhdd_r_console_sum.html

I think it would be better to make debian-installer smarter about
this since we will probably run into the same problem again with
a different architecture/driver.

-- 
Valentin

Bug#961118: vlc: Rendering issues on scaled display

[Kyle Robbertze]

Package: vlc
Version: 3.0.10-1
Severity: normal

Dear Maintainer,

Opening video in VLC on a scaled display causes incorrect rendering to
occur. Under KDE the window gets broken up badly and the video is purely
a black screen. Moving it to an unscaled monitor fixes the issue. A
screenshot is attached. The playlist screen is not affected and renders
correctly.

Thanks
Kyle

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

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

Versions of packages vlc depends on:
ii  vlc-bin  3.0.10-1
ii  vlc-plugin-base  3.0.10-1
ii  vlc-plugin-qt3.0.10-1
ii  vlc-plugin-video-output  3.0.10-1

Versions of packages vlc recommends:
ii  vlc-l10n   3.0.10-1
ii  vlc-plugin-notify  3.0.10-1
ii  vlc-plugin-samba   3.0.10-1
ii  vlc-plugin-skins2  3.0.10-1
ii  vlc-plugin-video-splitter  3.0.10-1
ii  vlc-plugin-visualization   3.0.10-1

vlc suggests no packages.

Versions of packages libvlc-bin depends on:
ii  libc62.30-8
ii  libvlc5  3.0.10-1

Versions of packages libvlc5 depends on:
ii  libc62.30-8
ii  libvlccore9  3.0.10-1

Versions of packages libvlc5 recommends:
ii  libvlc-bin  3.0.10-1

Versions of packages vlc-bin depends on:
ii  libc6   2.30-8
ii  libvlc-bin  3.0.10-1
ii  libvlc5 3.0.10-1

Versions of packages vlc-plugin-base depends on:
ii  liba52-0.7.4 0.7.4-20
ii  libaom0  1.0.0.errata1-3
ii  libarchive13 3.4.2-1
ii  libaribb24-0 1.0.3-2
ii  libasound2   1.2.2-2.1
ii  libass9  1:0.14.0-2
ii  libavahi-client3 0.8-1
ii  libavahi-common3 0.8-1
ii  libavc1394-0 0.5.4-5
ii  libavcodec58 7:4.2.2-1+b1
ii  libavformat587:4.2.2-1+b1
ii  libavutil56  7:4.2.2-1+b1
ii  libbasicusageenvironment12020.01.19-1
ii  libbluray2   1:1.2.0-1
ii  libc62.30-8
ii  libcairo21.16.0-4
ii  libcddb2 1.3.2-6+b1
ii  libchromaprint1  1.5.0-1
ii  libdbus-1-3  1.12.16-2
ii  libdc1394-22 2.2.5-2.1
ii  libdca0  0.0.7-1
ii  libdvbpsi10  1.3.3-1
ii  libdvdnav4   6.1.0-1+b1
ii  libdvdread8  6.1.1-2
ii  libebml4v5   1.3.10-1
ii  libfaad2 2.9.2-1
ii  libflac8 1.3.3-1
ii  libfontconfig1   2.13.1-4.2
ii  libfreetype6 2.10.1-2
ii  libfribidi0  1.0.8-2
ii  libgcc-s110.1.0-1
ii  libgcrypt20  1.8.5-5
ii  libglib2.0-0 2.64.2-1
ii  libgnutls30  3.6.13-2
ii  libgpg-error01.37-1
ii  libgroupsock82020.01.19-1
ii  libharfbuzz0b2.6.4-1
ii  libixml101:1.8.4-2
ii  libjpeg62-turbo  1:1.5.2-2+b1
ii  libkate1 0.4.1-11
ii  liblirc-client0  0.10.1-6.1
ii  liblivemedia77   2020.01.19-1
ii  liblua5.2-0  5.2.4-1.1+b3
ii  libmad0  0.15.1b-10
ii  libmatroska6v5   1.5.2-3
ii  libmpcdec6   2:0.1~r495-2
ii  libmpeg2-4   0.5.1-9
ii  libmpg123-0  1.25.13-1
ii  libmtp9  1.1.17-3
ii  libncursesw6 6.2-1
ii  libnfs13 4.0.0-1
ii  libogg0  1.3.2-1+b1
ii  libopenmpt-modplug1  0.4.11-1
ii  libopus0 1.3-1+b1
ii  libpng16-16  1.6.37-2
ii  libpostproc557:4.2.2-1+b1
ii  libprotobuf-lite22   3.11.4-5
ii  libpulse013.0-5
ii  libraw1394-112.1.2-2
ii  libresid-builder0c2a 2.1.1-15+b1
ii  librsvg2-2   2.48.4+dfsg-1
ii  libsamplerate0   0.1.9-2
ii  libsdl-image1.2  1.2.12-12
ii  libsdl1.2debian  1.2.15+dfsg2-5
ii  libsecret-1-00.20.3-1
ii  lib

Bug#926539: rootskel: steal-ctty no longer works on s390x

[John Paul Adrian Glaubitz]

On 5/20/20 12:42 PM, Valentin Vidić wrote:
> It is hard to tell, but it seems the current state is hardcoded
> in different places:
> 
> https://www.redhat.com/archives/libguestfs/2017-May/msg00068.html

This wouldn't cause breakage as with your change, the console name
would actually be ttysclp0.

> https://www.ibm.com/support/knowledgecenter/linuxonibm/com.ibm.linux.z.lhdd/lhdd_r_console_sum.html

Well, IBM could just update their documentation.

> I think it would be better to make debian-installer smarter about
> this since we will probably run into the same problem again with
> a different architecture/driver.

It was only SPARC which had this issue as well and where it was fixed. For
all the other architectures, the console and driver names already match.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#961028: hplip: No scanner found: SANE cannot load the hpaio backend

[BERTRAND Joël]

Hello,

Same constatation here with a LaserJet CM2320. I haven't found a 
solution

Best regards,

JB

Bug#937093: mupdf: Python2 removal in sid/bullseye

[Bastian Germann]

The previously sent patch is not needed for the stable 1.17.0 version
anymore. I created a new merge request with the necessary changes for
the new version including the py2 to py3 change:
https://salsa.debian.org/koster/mupdf/-/merge_requests/5

Bug#961119: ansible: Ansible fails to work on a minimal system (missing python 2 dependency)

[Elena ``of Valhalla'']

Package: ansible
Version: 2.7.7+dfsg-1
Severity: important

Dear Maintainer,

on a minimal stable (buster) installation, ansible fails to run (at
least on the machine itself) because of a lack of the python (2)
interpreter.

To reproduce, debootstrap an image (but installing from netinst without
adding things with tasksel also works):

# mkdir buster
# debootstrap buster buster/
# mount -t devtmpfs udev buster/dev/
# chroot buster

# ansible -i localhost, -m setup -c local all

localhost | FAILED! => {
"changed": false,
"module_stderr": "/bin/sh: 1: /usr/bin/python: not found\n",
"module_stdout": "",
"msg": "MODULE FAILURE\nSee stdout/stderr for the exact error",
"rc": 127
}

Installing python (2) of course fixes the issue.

I've noticed that it seems to be hardcoded as such in quite a few
modules:

# grep -r '/usr/bin/python$' /usr/lib/python3/dist-packages/ansible | wc -l
2083

but I've also checked that in sid the original command is working, while
those files still have an hardcoded python2 executable, so I'm not sure
what is going on there.

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

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

Versions of packages ansible depends on:
ii  openssh-client1:8.2p1-4
ii  python3   3.8.2-3
ii  python3-crypto2.6.1-13.1+b1
ii  python3-cryptography  2.8-4
ii  python3-distutils 3.8.2-2
ii  python3-dnspython 1.16.0-2
ii  python3-httplib2  0.14.0-3
ii  python3-jinja22.10.1-2
ii  python3-netaddr   0.7.19-4
ii  python3-paramiko  2.6.0-2
ii  python3-yaml  5.3.1-1+b1

Versions of packages ansible recommends:
ii  python3-argcomplete  1.8.1-1.3
ii  python3-jmespath 0.9.5-1
ii  python3-kerberos 1.1.14-3.1+b1
ii  python3-libcloud 2.8.0-1
ii  python3-selinux  3.0-1+b3
ii  python3-winrm0.3.0-2
ii  python3-xmltodict0.12.0-2

Versions of packages ansible suggests:
ii  cowsay   3.03+dfsg2-7
ii  sshpass  1.06-1+b1

-- no debconf information

Bug#961120: nulib2 ftbfs on s390x (failing tests), built before

[Matthias Klose]

Package: src:nulib2
Version: 3.1.0-3
Severity: serious
Tags: sid bullseye

nulib2 ftbfs on s390x (failing tests), built before:

   debian/rules override_dh_auto_test
make[1]: Entering directory '/<>'
nufxlib/samples/test-basic
ERROR: kNuAttrNumRecords 12884901888 vs 3
Using NuFX library v3.1.0, built on or after
  May 19 2020 with [Debian]

... starting tests
... open zero-byte existing
... add 'bytes' record
... add 'English' record
... add 'long' record
... checking contents
... reopening archive read-only
... checking contents
... verifying CRCs
... extracting files
... reopening archive read-write
... checking contents
... deleting first and last
... tests ended, FAILURE
make[1]: *** [debian/rules:28: override_dh_auto_test] Error 1
make[1]: Leaving directory '/<>'
make: *** [debian/rules:7: binary-arch] Error 2
dpkg-buildpackage: error: debian/rules binary-arch subprocess returned exit 
status 2

Bug#960897: [Android-tools-devel] Bug#960897: Update android-platform-external-libunwind and build for ppc64el

[Hans-Christoph Steiner]

We are not keeping up with the maintenance on the Google supported
archs.  Adding archs that are explicitly not supported by upstream will
complicate things further.  To support other archs, someone will need to
contribute both to the ongoing maintenance on the supported arches, as
well as the patches to enable other archs.

Bug#961122: giac: FTBFS on armhf

[Graham Inggs]

Source: giac
Version: 1.5.0.87+dfsg1-1
Severity: serious
Tags: ftbfs bullseye sid

Hi Maintainer

d-workaround-armhf-hang.patch was recently dropped [1], however, as
can be seen on buildds [2] and reproducibles builds [3], that giac
still FTBFS on armhf with:

E: Build killed with signal TERM after 300 minutes of inactivity

Regards
Graham


[1] 
https://salsa.debian.org/science-team/giac/-/commit/67485addcc95870c3f4a5756cbba21a4d8889900
[2] https://buildd.debian.org/status/logs.php?pkg=giac&arch=armhf
[3] https://tests.reproducible-builds.org/debian/history/armhf/giac.html

Bug#955438: grpc: libupb.so.9 is not installed in any binary package

[Adrian Bunk]

On Sat, Apr 11, 2020 at 06:14:07PM +0200, László Böszörményi wrote:
> On Mon, Apr 6, 2020 at 2:02 PM Pirate Praveen  
> wrote:
> > This patch makes the build successful.
> >
> > https://salsa.debian.org/debian/grpc/-/blob/buster-backports/debian/patches/no-link-upb.patch
>  I still would be interested why it links with upb in your backport
> when in Sid it doesn't. Something is way different there.
>...

The difference is that the toolchain in sid defaults to as-needed,
but the toolchain in buster does not.

Which matters since this linking with libupb.so unnecessary
(all actual usage seems to be with libupb.a).

I need only the following change (which is a nop in sid)
for building otherwise unmodified 1.26.0-3 in buster:
-#export DEB_LDFLAGS_MAINT_APPEND = -Wl,--as-needed
+export DEB_LDFLAGS_MAINT_APPEND = -Wl,--as-needed

> Regards,
> Laszlo/GCS

cu
Adrian

Bug#926539: rootskel: steal-ctty no longer works on s390x

[Philipp Kern]

On 20.05.20 12:42, Valentin Vidić wrote:
> On Wed, May 20, 2020 at 11:19:53AM +0200, John Paul Adrian Glaubitz wrote:
>> Ah, sorry. I was seeing the cached version of the thread, refreshing helped.
>>
>> In any case, the SPARC kernel maintainer (Dave Miller) had the same argument
>> that it would potentially break existing setups but eventually I could
>> convince him that the change was right.
>>
>> Not sure which distributions he has in mind.
> 
> It is hard to tell, but it seems the current state is hardcoded
> in different places:
> 
> https://www.redhat.com/archives/libguestfs/2017-May/msg00068.html
> https://www.ibm.com/support/knowledgecenter/linuxonibm/com.ibm.linux.z.lhdd/lhdd_r_console_sum.html
> 
> I think it would be better to make debian-installer smarter about
> this since we will probably run into the same problem again with
> a different architecture/driver.

qemu-system-s390x is probably the least representative here. I recall
that the consoles for z/VM and LPAR were actually different. As alluded
to by the thread LPAR uses SCLP while you get 3215 on z/VM.

I'm all for making d-i smarter. But I think we should start by trying to
back merge all the improvements Canonical made on Ubuntu instead of
Debian as part of their s390x contract. Maybe trying ubuntu-installer
and seeing if that works correctly would be a good start.

But then I keep wondering how representative qemu is. Is VT220 SCLP even
something you get on a real z machine? Not that we shouldn't fix qemu,
of course. But Hercules might be closer to the real thing in this regard.

Kind regards
Philipp Kern

Bug#926539: rootskel: steal-ctty no longer works on s390x

[John Paul Adrian Glaubitz]

On 5/20/20 1:18 PM, Philipp Kern wrote:
> But then I keep wondering how representative qemu is. Is VT220 SCLP even
> something you get on a real z machine? Not that we shouldn't fix qemu,
> of course. But Hercules might be closer to the real thing in this regard.

Hercules shows the exact same behavior. I also don't think the emulation
is relevant as the underlying issue is a naming inconsistency in the kernel
which is only present on s390x and used to be present on sparc64.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#961123: opensc: support for CardOS 5.3 broken in 0.20.0

[Silvano Cirujano Cuesta]

Package: opensc
Version: 0.20.0-4
Severity: important
Tags: upstream patch

OpenSC version 0.20.0 broke the support for CardOS 5.3 smartcards. It
potentially also breaks CardOS 5.0 and other 5.x smartcards (if any
exist).

People with a CardOS 5.3 smartcard can reproduce the issue with the
command `pkcs11-tool --login --test`, which reports a couple of failures
in the signature verification.

There's a bugfix upstream for this issue: 
https://github.com/OpenSC/OpenSC/pull/1987

Just for reference, here is the equivalent Fedora bug report: 
https://bugzilla.redhat.com/show_bug.cgi?id=1830528

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

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

Versions of packages opensc depends on:
ii  libc6  2.30-8
ii  libreadline8   8.0-4
ii  libssl1.1  1.1.1g-1
ii  opensc-pkcs11  0.20.0-4
ii  zlib1g 1:1.2.11.dfsg-2

Versions of packages opensc recommends:
ii  pcscd  1.8.26-3

opensc suggests no packages.

-- Configuration Files:
/etc/opensc/opensc.conf changed [not included]

-- no debconf information

Bug#949762: [Python-modules-team] Bug#949762: Bug#949762: Please update hypothesis package to >= 5.1

[Emmanuel Arias]

Hi everybody,

Soory  for my delay.

I have had an issue with the a "lazy" test [0], This test assert if
numy isn't on
`sys.modules`. According I can understood about autopgktest, when
Depends: python3-* is written on d/tests/control, that  will "put into
sys.modules"
(installation path really) the package. So, that test will fail always
that python3-numpy
is mark as Depends on the autopkgtest.

For that reason, I decided skip the test [1]. Please, I need a more experience
review, or if it's all ok, I will need sponsorship to  upload.

Thanks!

[0] 
https://salsa.debian.org/python-team/modules/python-hypothesis/-/blob/debian/master/hypothesis-python/tests/numpy/test_lazy_import.py
[1] 
https://salsa.debian.org/python-team/modules/python-hypothesis/-/blob/debian/master/debian/patches/0002-Skip-lazy-test-that-fail-on-autopkgtest.patch

Cheers,
Arias Emmanuel
@eamanu
http://eamanu.com

El mar., 19 de may. de 2020 a la(s) 12:16, Sandro Tosi
(mo...@debian.org) escribió:
>
> On Mon, Apr 27, 2020 at 5:51 PM Emmanuel Arias
>  wrote:
> >
> > Hi Ole,
> >
> > I am working on the python-hypothesis.
> >
> > One of the test fail on autopkgtest, so I am workint on it.
> >
> > I push to salsa [0] my last change if you want to take a look.
> >
> > [0] https://salsa.debian.org/python-team/modules/python-hypothesis
>
> whta's the status here? more than 3 weeks passed from the last update
> and the newest numpy 1.19.0RC1 requires a newer version of hypothesis
> than we have in the archive.
>
> Regards,
> --
> Sandro "morph" Tosi
> My website: http://sandrotosi.me/
> Me at Debian: http://wiki.debian.org/SandroTosi
> Twitter: https://twitter.com/sandrotosi

Bug#960963: status?

[Tomas Pospisek]

What's the status of this problem? Is anybody working on dovecot to have 
this fixed in Debian stable?

*t

Bug#958843: please don't depend on vim-nox

[Raphael Medaer]

It seems there was an issue with my previous email. Here is the full text:


Hi John,

The next version of vim-editorconfig (1.0.0) won’t require Python anymore 
(https://github.com/editorconfig/editorconfig-vim/pull/119).


I discussed with Michael Fladischer (the original package maintainer) about the 
upgrade.
As soon as the upstream is ready (see 
https://github.com/editorconfig/editorconfig-vim/issues/143) I will upgrade the 
package and remove the dependency(ies) no more required (including vim-nox).

Kind regards,

--
Raphaël Medaer

Bug#959877: [Pkg-rust-maintainers] Bug#959877: rustc: soundness bug reintroduced by debian due to system LLVM

[Ximin Luo]

Control: reassign -1 llvm-toolchain-9
Control: affects -1 rustc
Control: tags -1 + upstream patch

LLVM maintainer, please backport the following upstream patch to LLVM 9: 
https://github.com/rust-lang/llvm-project/commit/7d5e7c023053660ffe494d72ce471e48ecc7f49b

Since rust has already backported it to their LLVM, I assume it applies 
cleanly, but if it doesn't please let me know and I'll try to fix it.

X

Jakub Kądziołka:
> Package: rustc
> Version: 1.42.0+dfsg1-1
> Severity: important
> Tags: security
> 
> [ NOTE: I have tried to check whether this reproduces on the 1.43
> package that reportbug can see on experimental, but apt claims there's
> no new version on experimental. ]
> 
> Steps to reproduce:
> 
> 1. Download this file from rustc's test suite:
> $ wget 
> https://raw.githubusercontent.com/rust-lang/rust/f8d394e5184fe3af761ea1e5ba73f993cfb36dfe/src/test/ui/issues/issue-69225-SCEVAddExpr-wrap-flag.rs
> 
> 2. Compile it.
> $ rustc -C opt-level=3 issue-69225-SCEVAddExpr-wrap-flag.rs
> 
> 3. Run the binary.
> $ ./issue-69225-SCEVAddExpr-wrap-flag
> 
> Actual output:
> Segmentation fault
> 
> Expected output (from rustc 1.42.0 obtained via rustup):
> thread 'main' panicked at 'index out of bounds: the len is 0 but the index is 
> 16777216', issue-69225-SCEVAddExpr-wrap-flag.rs:24:17
> note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
> 
> This bug stems from a miscompilation introduced in LLVM 9. The fix got
> backported into the LLVM vendored by Rust in 1.41.1:
> https://github.com/rust-lang/llvm-project/commit/7d5e7c023053660ffe494d72ce471e48ecc7f49b
> 
> This discussion on Rust's zulip might also be relevant:
> https://rust-lang.zulipchat.com/#narrow/stream/187780-t-compiler.2Fwg-llvm/topic/The.20LLVM.20release.20process
> 
> -- System Information:
> Debian Release: bullseye/sid
>   APT prefers unstable
>   APT policy: (500, 'unstable'), (1, 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 5.4.0-4-amd64 (SMP w/4 CPU cores)
> Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), 
> LANGUAGE=en_US:en (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/bash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> Versions of packages rustc depends on:
> ii  binutils  2.34-6
> ii  gcc   4:9.2.1-3.1
> ii  libc6 2.30-4
> ii  libc6-dev [libc-dev]  2.30-4
> ii  libgcc-s1 10-20200502-1
> ii  libstd-rust-dev   1.42.0+dfsg1-1
> 
> Versions of packages rustc recommends:
> pn  cargo 
> pn  rust-gdb | rust-lldb  
> 
> Versions of packages rustc suggests:
> pn  lld-9 
> pn  rust-doc  
> pn  rust-src  
> 
> -- no debconf information
> 
> ___
> Pkg-rust-maintainers mailing list
> pkg-rust-maintain...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-rust-maintainers
> 


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

Bug#961124: systemd: suspend for no apparent reasons when using light-locker and the screensaver becomes inactive

[Vincent Lefevre]

Package: systemd
Version: 245.5-2
Severity: important

When I use "light-locker --late-locking" for screen locking and
the screensaver becomes inactive, e.g. because I move the mouse,
systemd-logind suspends the system. The journalctl logs just say
"systemd-logind[xxx]: Suspending...". The system is automatically
resumed a few seconds later, but with indeterminate effects on
the status of the system (the X server may no longer work).

Details:

I have a laptop with 2 external monitors. The laptop screen is off and
the lid is usually closed (not completely, but as seen by the system).
The suspend due to lid closing is inhibited by a systemd-inhibit lock.
I just use the builtin X11 screensaver + "light-locker --late-locking"
for screen locking.

In the morning, while the screensaver was active, moving the mouse had
no visible effect, nor typing some keys on the USB keyboard. The lid of
the laptop was closed. I opened it completely to see whether there was
something, and at this time I heard the fan, which typically happens
when the laptop wakes up after a suspend.

According to the journalctl log excerpt below, the system was not
suspended before I moved to mouse to stop the screensaver.

More tests have shown that the system is suspended each time the
screensaver becomes inactive, and this does not occur if I do not
use light-locker.

-- Logs begin at Mon 2019-06-03 11:58:51 CEST, end at Wed 2020-05-20 09:50:47 
CEST. --
May 20 02:36:23 zira kernel: microcode: microcode updated early to revision 
0x27, date = 2019-02-26
May 20 02:36:23 zira kernel: Linux version 5.6.0-1-amd64 
(debian-ker...@lists.debian.org) (gcc version 9.3.0 (Debian 9.3.0-11)) #1 SMP 
Debian 5.6.7-1 (2020-04-29)
May 20 02:36:23 zira kernel: Command line: BOOT_IMAGE=/vmlinuz-5.6.0-1-amd64 
root=/dev/mapper/zira--vg-root ro quiet
[...]
May 20 09:13:09 zira inhibit-suspend[200484]: (vinc17) on-line: yes
May 20 09:13:09 zira inhibit-suspend[200489]: (vinc17) output: 3
May 20 09:13:19 zira inhibit-suspend[200497]: (vinc17) on-line: yes
May 20 09:13:19 zira inhibit-suspend[200502]: (vinc17) output: 3
May 20 09:13:29 zira inhibit-suspend[200511]: (vinc17) on-line: yes
May 20 09:13:29 zira inhibit-suspend[200516]: (vinc17) output: 3
May 20 09:13:39 zira inhibit-suspend[200527]: (vinc17) on-line: yes
May 20 09:13:39 zira inhibit-suspend[200532]: (vinc17) output: 3
May 20 09:13:49 zira inhibit-suspend[200541]: (vinc17) on-line: yes
May 20 09:13:49 zira inhibit-suspend[200546]: (vinc17) output: 3
May 20 09:13:59 zira inhibit-suspend[200554]: (vinc17) on-line: yes
May 20 09:13:59 zira inhibit-suspend[200559]: (vinc17) output: 3
May 20 09:14:09 zira inhibit-suspend[200567]: (vinc17) on-line: yes
May 20 09:14:09 zira inhibit-suspend[200572]: (vinc17) output: 3
May 20 09:14:19 zira inhibit-suspend[200580]: (vinc17) on-line: yes
May 20 09:14:19 zira inhibit-suspend[200585]: (vinc17) output: 3
May 20 09:14:29 zira inhibit-suspend[200593]: (vinc17) on-line: yes
May 20 09:14:29 zira inhibit-suspend[200598]: (vinc17) output: 3
May 20 09:14:39 zira inhibit-suspend[200606]: (vinc17) on-line: yes
May 20 09:14:39 zira inhibit-suspend[200611]: (vinc17) output: 3
May 20 09:14:49 zira inhibit-suspend[200620]: (vinc17) on-line: yes
May 20 09:14:49 zira inhibit-suspend[200625]: (vinc17) output: 3
May 20 09:14:59 zira inhibit-suspend[200634]: (vinc17) on-line: yes
May 20 09:14:59 zira inhibit-suspend[200639]: (vinc17) output: 3
May 20 09:15:01 zira CRON[200642]: pam_unix(cron:session): session opened for 
user root by (uid=0)
May 20 09:15:01 zira CRON[200643]: pam_unix(cron:session): session opened for 
user root by (uid=0)
May 20 09:15:01 zira CRON[200644]: (root) CMD (command -v debian-sa1 > 
/dev/null && debian-sa1 1 1)
May 20 09:15:01 zira CRON[200645]: (root) CMD (/sbin/hwclock --systohc)
May 20 09:15:01 zira CRON[200643]: pam_unix(cron:session): session closed for 
user root
May 20 09:15:02 zira CRON[200642]: pam_unix(cron:session): session closed for 
user root
May 20 09:15:09 zira inhibit-suspend[200653]: (vinc17) on-line: yes
May 20 09:15:09 zira inhibit-suspend[200658]: (vinc17) output: 3
May 20 09:15:19 zira inhibit-suspend[200666]: (vinc17) on-line: yes
May 20 09:15:20 zira inhibit-suspend[200671]: (vinc17) output: 3
May 20 09:15:30 zira inhibit-suspend[200679]: (vinc17) on-line: yes
May 20 09:15:30 zira inhibit-suspend[200684]: (vinc17) output: 3
May 20 09:15:40 zira inhibit-suspend[200693]: (vinc17) on-line: yes
May 20 09:15:40 zira inhibit-suspend[200698]: (vinc17) output: 3
May 20 09:15:50 zira inhibit-suspend[200706]: (vinc17) on-line: yes
May 20 09:15:50 zira inhibit-suspend[200711]: (vinc17) output: 3
May 20 09:16:00 zira inhibit-suspend[200719]: (vinc17) on-line: yes
May 20 09:16:00 zira inhibit-suspend[200724]: (vinc17) output: 3
May 20 09:16:10 zira inhibit-suspend[200732]: (vinc17) on-line: yes
May 20 09:16:10 zira inhibit-suspend[200737]: (vinc17) output: 3
May 20 09:16:20 zira inhibit-suspend[200745]: (vinc17) on-line: yes
May 20 09:16:20 zir

Bug#961125: vga= deprecated with grub2

[john doe]

Package: debian-installer
Version: debian-bullseye-DI-alpha2-amd64-netinst.iso

qemu-system-x86_64 -cdrom debian-bullseye-DI-alpha2-amd64-netinst.iso
-nographic -vga none -m 1024

At the Debian install prompt pressing the escape key get me to the boot
prompt.

boot: install console=ttyS0,115200n8 DEBIAN_FRONTEND=text gfxpayload=text
Undefined video mode number: 314
Press  to see video modes available,  to continue, or wait
30 sec


If I use 'vga=none' the above is suppressed but Debian will not start
properly after installation by saying that 'vga=none' is deprecated and
that 'set gfxpayload=text' should be used instead.

How can I specify 'set gfxpayload=text' to the boot prompt above?

In other words, how can i emulate 'vga=none' when this argument is
deprecated when installing Debian.

--
John Doe

Bug#961124: systemd: suspend for no apparent reasons when using light-locker and the screensaver becomes inactive

[Michael Biebl]

On Wed, 20 May 2020 13:59:06 +0200 Vincent Lefevre 
wrote:

> More tests have shown that the system is suspended each time the
> screensaver becomes inactive, and this does not occur if I do not
> use light-locker.

Let's reassign to light-locker then.



signature.asc
Description: OpenPGP digital signature

Bug#961124: systemd: suspend for no apparent reasons when using light-locker and the screensaver becomes inactive

[Vincent Lefevre]

On 2020-05-20 14:15:49 +0200, Michael Biebl wrote:
> On Wed, 20 May 2020 13:59:06 +0200 Vincent Lefevre 
> wrote:
> 
> > More tests have shown that the system is suspended each time the
> > screensaver becomes inactive, and this does not occur if I do not
> > use light-locker.
> 
> Let's reassign to light-locker then.

If it's light-locker that suspends the system, then why don't
the journalctl logs show that?

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#961127: fai-client: Error in class definition script does not stop installation

[Maximilian Stein]

Package: fai-client
Version: 5.8.4~bpo9+2
Severity: normal

Dear Maintainer,

Today I discovered that a task error raised in a class definition
script does not stop the installation/softupdate.

In my example (see log excerpt below) the class script
/var/lib/fai/config/class/95-dep.sh sets an error calling
"task_error 800". FAI detects this and uploads log files, however then
continues with the next task (the remaining class definition scripts
are not executed). The softupdate continues as usual and the log files
are finally uploaded again (causing a conflict).

Looking at the code, `/usr/lib/fai/subroutines` apparently calls
`fai-class` but does not check if a fatal task error was set (or if
`fai-class` exited with error). As far as I can tell, the issue still
seems to be present in version 5.9.4.

Thanks for your help!

Best,
Maximilian


-- fai.log

 -
   Fully Automatic Installation  -  FAI

   5.8.4~bpo9+2   (c) 1999-2019
   Thomas Lange  
 -
Starting FAI execution - 20200520_140231

Using configuration files from /etc/fai
Calling task_confdir
FAI_FLAGS: 
Setting SERVER=fai.example.org. Value extracted from FAI_CONFIG_SRC.
Monitoring to server fai-monitor.example.org enabled.
FAI_CONFIG_SRC is set to git+ssh://f...@fai.example.org/srv/git/fai.git
Updating git copy in /var/lib/fai/config
HEAD is now at 12345678... foobar
Source hook: setup.DEFAULT.sh
hostname: examplehost
setup.DEFAULT.sh OK.
Calling task_setup
FAI_FLAGS: 
Calling task_defclass
fai-class: Defining classes.
Executing /var/lib/fai/config/class/10-base-classes.sh.
./10-base-classes.sh defined classes:  LINUX AMD64 DHCPC
10-base-classes.sh   OK.
...
Executing /var/lib/fai/config/class/70-custom-classes.sh.
70-custom-classes.sh OK.
Executing /var/lib/fai/config/class/95-dep.sh.
FATAL ERROR: class ABC conflicts with DEF
Error in task defclass. Code: 800
Traceback: task_error conflicts source main
Calling hook: savelog.DEFAULT
'//var/log/fai/last-localhost' -> 'localhost/last'
savelog.DEFAULT  OK.
Source hook: savelog.ADBASE.sh
savelog.ADBASE.shOK.
Save log files via ssh to 
f...@fai.example.org:log//examplehost/softupdate-2020-05-20T14:02:33+02:00
FATAL ERROR. Installation stopped.
List of all classes:  DEFAULT LINUX AMD64 DHCPC GRUB ARCH_PC DEBIAN STRETCH ABC 
DEF
Calling task_defvar
Executing DEBIAN.var
...

Bug#961126: fig2dev fails autopkg test with stderr output on 32bit archs

[Matthias Klose]

Package: src:fig2dev
Version: 1:3.2.7b-3
Severity: serious
Tags: sid bullseye patch

fig2dev fails autopkg test with stderr output on 32bit archs

make  test1
make[1]: Entering directory 
'/tmp/autopkgtest.No5cFl/build.GqQ/src/fig2dev/tests'
gcc -DHAVE_CONFIG_H -I. -I../..  -DI18N_DATADIR="\"/usr/share/fig2dev/i18n\""
-Wdate-time -D_FORTIFY_SOURCE=2  -g -O2
-fdebug-prefix-map=/tmp/autopkgtest.No5cFl/build.GqQ/src=.
-fstack-protector-strong -Wformat -Werror=format-security -c -o test1.o test1.c
test1.c: In function ‘main’:
test1.c:60:33: warning: format ‘%ld’ expects argument of type ‘long int’, but
argument 2 has type ‘size_t’ {aka ‘unsigned int’} [-Wformat=]
   60 |   printf("File path too long, %ld > %d.\n", n + 10, BUFSIZ);
  |   ~~^   ~~
  | | |
  | long int  size_t {aka unsigned int}
  |   %d
gcc  -g -O2 -fdebug-prefix-map=/tmp/autopkgtest.No5cFl/build.GqQ/src=. 
-fstack-prote

patch at
http://launchpadlibrarian.net/480599135/fig2dev_1%3A3.2.7b-3_1%3A3.2.7b-3ubuntu1.diff.gz

Bug#948227: Does not save settings and does not connect to servers

[Thomas Arendsen Hein]

Source: linphone
Version: 3.12.0-3
Followup-For: Bug #948227

+1 (I just encountered the same issue)

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

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

-- 
Thomas Arendsen Hein 
OpenPGP key: https://intevation.de/~thomas/thomas_pgp.asc (0xD45DE28FF3A2250C)
Intevation GmbH, Neuer Graben 17, 49074 Osnabrueck - AG Osnabrueck, HR B 18998
Geschaeftsfuehrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner

Bug#961120: nulib2 ftbfs on s390x (failing tests), built before

[Stephen Kitt]

Le 20/05/2020 13:02, Matthias Klose a écrit :

nulib2 ftbfs on s390x (failing tests), built before:


Thanks, the tests fail on all 64-bit big-endian platforms:

ERROR: kNuAttrNumRecords 12884901888 vs 3

12884901888 is 0x3 ;-).

I’ll look into it...

Regards,

Stephen

Bug#961129: xscreensaver should not search for screensaver executables in PATH

[Andrew Gallagher]

Package: xscreensaver
Version: 5.42+dfsg1-1
Severity: important

Dear Maintainer,

Ever since I installed the magic-wormhole package, I have noticed that 
xscreensaver occasionally throws an error on the screen as follows:

```
Usage: wormhole [OPTIONS] COMMAND [ARGS]...
Try "wormhole --help" for help.

Error: no such option: -r
```

Luckily, invoking magic-wormhole with invalid options does not result in 
anything dangerous happening, but it raises the question whether potentially 
dangerous unintended behaviour is possible.

I believe this happens because xscreensaver is searching for known screensaver 
binaries, and finding `wormhole` in the PATH it blindly assumes that this is 
the `wormhole` from xscreensaver-data-extra, but it is not installed.

xscreensaver SHOULD search for screensavers only in /usr/lib/xscreensaver, 
where other packages are expected to install them. Any other executable on the 
PATH which may happen to have the same name as a known screensaver MUST NOT be 
invoked, as this may result in unintended behaviour.

Beware for example that `zoom` is the name of a known screensaver. I am glad 
that I do not have xscreensaver and zoom.us installed on the same machine. :-)

Andrew.


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

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

Versions of packages xscreensaver depends on:
ii  libatk1.0-0  2.30.0-2
ii  libc62.28-10
ii  libcairo21.16.0-4
ii  libfontconfig1   2.13.1-2
ii  libfreetype6 2.9.1-3+deb10u1
ii  libgdk-pixbuf2.0-0   2.38.1+dfsg-1
ii  libglade2-0  1:2.6.4-2+b1
ii  libglib2.0-0 2.58.3-2+deb10u2
ii  libgtk2.0-0  2.24.32-3
ii  libice6  2:1.0.9-2
ii  libpam0g 1.3.1-5
ii  libpango-1.0-0   1.42.4-8~deb10u1
ii  libpangocairo-1.0-0  1.42.4-8~deb10u1
ii  libpangoft2-1.0-01.42.4-8~deb10u1
ii  libsm6   2:1.2.3-1
ii  libx11-6 2:1.6.7-1
ii  libxext6 2:1.3.3-1+b2
ii  libxi6   2:1.7.9-1
ii  libxinerama1 2:1.1.4-2
ii  libxml2  2.9.4+dfsg1-7+b3
ii  libxmu6  2:1.1.2-2+b3
ii  libxrandr2   2:1.5.1-1
ii  libxrender1  1:0.9.10-1
ii  libxt6   1:1.1.5-1+b3
ii  libxxf86vm1  1:1.1.4-1+b2
ii  xscreensaver-data5.42+dfsg1-1

Versions of packages xscreensaver recommends:
ii  libjpeg-turbo-progs   1:1.5.2-2+b1
ii  perl  5.28.1-6
ii  wamerican [wordlist]  2018.04.16-1

Versions of packages xscreensaver suggests:
ii  firefox-esr [www-browser]  68.8.0esr-1~deb10u1
pn  fortune
ii  gdm3   3.30.2-3
ii  links [www-browser]2.18-2
ii  lynx [www-browser] 2.8.9rel.1-3
pn  qcam | streamer
ii  w3m [www-browser]  0.5.3-37
pn  xdaliclock 
pn  xfishtank  
pn  xscreensaver-data-extra
pn  xscreensaver-gl
pn  xscreensaver-gl-extra  

-- no debconf information

Bug#961128: apt-transport-https: https fails with segmentation fault

[Julian Andres Klode]

Control: tag -1 moreinfo

On Wed, May 20, 2020 at 02:41:12PM +0200, Mehturt wrote:
> Package: apt-transport-https
> Version: 1.4.10
> Severity: important
> 
> Dear Maintainer,
> 
> running "apt update" finishes with segmentation fault
> when the following entry is in my sources.list:
> 
> deb http://packages.matrix.org/debian stretch main
> 
> Removing the entry from sources.list produces no crash.
> 
> This seems to be similar to already reported
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=778375

Please obtain a full backtrace.


-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer  i speak de, en

Bug#960674: golang-go: "fatal error: gc_trigger underflow" on mipsel

[Sascha Steinbiss]

Hi,

first of all thanks for putting some energy into this issue!

> FTR, after giving back golang-1.14 mipsel several times, it's finally
> built, by a longson builder.
> So I guess it only occurs on octeon. Since the porterbox eller is also
> octeon, it also can't build any go program.

So what does that mean for package building -- will the Octeon builders
still be used long or short term? This impacts testing migration :/

Thanks
Sascha

Bug#960327: squid: autopkgtest regression: test_daemons (__main__.BasicTest)

[Sergio Durigan Junior]

reopen 960327
thanks

On Saturday, May 16 2020, Luigi Gangitano wrote:

> Hi Sergio,
>
>> On 14 May 2020, at 05:42, Sergio Durigan Junior  wrote:
>> 
>> Here's a patch that fixes the issue above.
>> 
>> Please note that even after fixing this specific issue, I still see
>> another failure with test_zz_apparmor.  I've posted a merge request to
>> also fix this problem here:
>> 
>>  https://salsa.debian.org/squid-team/squid/-/merge_requests/12 
>> 
>
>
> Thanks for looking into it. I’ve merged your patches and will upload shortly.

Hi Luigi,

I think there's been a confusion here :-).  The MR on salsa does *not*
fix this bug: it was meant to fix another apparmor bug I had found while
testing the package.  I attached the fix to this specific bug here:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=960327;msg=10

I can submit it as an MR as well, if you want.  Currently, the
autopkgtest is still failing.

Thanks, and sorry if this wasn't clear in my initial message.

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
https://sergiodj.net/


signature.asc
Description: PGP signature

Bug#843693: hello

[Gabriel Bertrand]

-- 

Hello

hope you are doing great. my name is Gabriel. We can be friends
I have important information I would like to share with you

Have a great day

Bug#954022: pipewire: New upstream release 0.3.x, required by mutter 3.36.x and xdg-desktop-portal 1.7.x

[Simon McVittie]

On Sun, 15 Mar 2020 at 20:14:33 +, Simon McVittie wrote:
> pipewire 0.3.x contains API changes which are needed for mutter
> 3.36.x (currently in experimental), xdg-desktop-portal 1.7.x and
> xdg-desktop-portal-gtk 1.7.x. It would be great to have it available in
> experimental too.

Passing this on:

<@bigon> if some one wants to have a look at pipewire, my work is at 
https://salsa.debian.org/bigon/pipewire/
<@bigon> it's not building ATM as there are still file to install (probably in 
new pkgs)

smcv

Bug#961130: ethtool can read DOM values

[Yannis Aribaud]

Package: ethtool
Version: 1:4.19-1
Severity: important
The command ethtool -m  is unable to read the transceiver DOM values.

Here is a transcript:

root@localhost:~# ethtool -i ens2f0
driver: mlx5_core
version: 5.0-0
firmware-version: 14.25.8000 (DEL2420110034)
expansion-rom-version: 
bus-info: :65:00.0
supports-statistics: yes
supports-test: yes
supports-eeprom-access: no
supports-register-dump: no
supports-priv-flags: yes

root@localhost:~# ethtool -m ens2f0 
 Identifier : 0x03 (SFP)
 Extended identifier : 0x04 (GBIC/SFP defined by 2-wire interface ID)
 Connector : 0x07 (LC)
 Transceiver codes : 0x10 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
 Transceiver type : 10G Ethernet: 10G Base-SR
 Encoding : 0x06 (64B/66B)
 BR, Nominal : 10300MBd
 Rate identifier : 0x00 (unspecified)
 Length (SMF,km) : 0km
 Length (SMF) : 0m
 Length (50um) : 80m
 Length (62.5um) : 20m
 Length (Copper) : 0m
 Length (OM3) : 300m
 Laser wavelength : 850nm
 Vendor name : Pureoptics
 Vendor OUI : 00:00:00
 Vendor PN : EX-SFP-10GE-SR
 Vendor rev : B4
 Option values : 0x00 0x1a
 Option : RX_LOS implemented
 Option : TX_FAULT implemented
 Option : TX_DISABLE implemented
 BR margin, max : 0%
 BR margin, min : 0%
 Vendor SN : M4787212
 Date code : 200222
 Optical diagnostics support : Yes
 Laser bias current : 0.000 mA
 Laser output power : 0. mW / -inf dBm
 Receiver signal average optical power : 0. mW / -inf dBm
 Module temperature : 0.00 degrees C / 32.00 degrees F
 Module voltage : 0. V
 Alarm/warning flags implemented : Yes
 Laser bias current high alarm : Off
 Laser bias current low alarm : Off
 Laser bias current high warning : Off
 Laser bias current low warning : Off
 Laser output power high alarm : Off
 Laser output power low alarm : Off
 Laser output power high warning : Off
 Laser output power low warning : Off
 Module temperature high alarm : Off
 Module temperature low alarm : Off
 Module temperature high warning : Off
 Module temperature low warning : Off
 Module voltage high alarm : Off
 Module voltage low alarm : Off
 Module voltage high warning : Off
 Module voltage low warning : Off
 Laser rx power high alarm : Off
 Laser rx power low alarm : Off
 Laser rx power high warning : Off
 Laser rx power low warning : Off
 Laser bias current high alarm threshold : 0.000 mA
 Laser bias current low alarm threshold : 0.000 mA
 Laser bias current high warning threshold : 0.000 mA
 Laser bias current low warning threshold : 0.000 mA
 Laser output power high alarm threshold : 0. mW / -inf dBm
 Laser output power low alarm threshold : 0. mW / -inf dBm
 Laser output power high warning threshold : 0. mW / -inf dBm
 Laser output power low warning threshold : 0. mW / -inf dBm
 Module temperature high alarm threshold : 0.00 degrees C / 32.00 degrees F
 Module temperature low alarm threshold : 0.00 degrees C / 32.00 degrees F
 Module temperature high warning threshold : 0.00 degrees C / 32.00 degrees F
 Module temperature low warning threshold : 0.00 degrees C / 32.00 degrees F
 Module voltage high alarm threshold : 0. V
 Module voltage low alarm threshold : 0. V
 Module voltage high warning threshold : 0. V
 Module voltage low warning threshold : 0. V
 Laser rx power high alarm threshold : 0. mW / -inf dBm
 Laser rx power low alarm threshold : 0. mW / -inf dBm
 Laser rx power high warning threshold : 0. mW / -inf dBm
 Laser rx power low warning threshold : 0. mW / -inf dBm
As you can see all mesuring values are zeros.
I am using Debian GNU/Linux 10 (buster), kernel 4.19.0-9-amd64 #1 SMP Debian 
4.19.118-2 (2020-04-29) x86_64 GNU/Linux and libc6 2.28-10

FYI, I get correct values using SystemRescueCD 6 (ethtool 5.0, kernel 
4.19.34-1-lts) on this same hardware, using the same command.

Regards,--
Yannis Aribaud

Bug#961124: systemd: suspend for no apparent reasons when using light-locker and the screensaver becomes inactive

[Michael Biebl]

Am 20.05.2020 um 14:19 schrieb Vincent Lefevre:

On 2020-05-20 14:15:49 +0200, Michael Biebl wrote:

On Wed, 20 May 2020 13:59:06 +0200 Vincent Lefevre 
wrote:


More tests have shown that the system is suspended each time the
screensaver becomes inactive, and this does not occur if I do not
use light-locker.


Let's reassign to light-locker then.


If it's light-locker that suspends the system, then why don't
the journalctl logs show that?



logind provides the mechanism (how to suspend), the desktop the policy 
(when to suspend).

In this case this appears to be light-locker/XFCE.

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

Bug#961131: freecad: autopkgtest regression with opencascade 7.4

[Graham Inggs]

Source: freecad
Version: 0.18.4+dfsg2-2
Tags: patch
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: regression

Hi Maintainer

Freecad fails its autopkgtests with opencascade 7.4 [1]:

testTaperedHole (PartDesignTests.TestHole.TestHole) ... FAIL

The attached patch is applied in Ubuntu.

Regards
Graham


[1] https://ci.debian.net/packages/f/freecad/
Description: partdesign: fix failing tapered hole test
 The given parameters return an invalid shape. This fails with occt7.4 but
 doesn't with occt7.3. If the angle is 45 degree the cone is
 self-intersecting as Hole.Depth > Hole.Diameter/2. Changing the 
 Hole.TaperedAngle to 60 degree solves this issue.
Author: lorenz 
Last-Update: 2020-05-03

--- a/src/Mod/PartDesign/PartDesignTests/TestHole.py
+++ b/src/Mod/PartDesign/PartDesignTests/TestHole.py
@@ -67,7 +67,7 @@
 def testTaperedHole(self):
 self.Hole.Diameter = 6
 self.Hole.Depth = 5
-self.Hole.TaperedAngle = 45
+self.Hole.TaperedAngle = 60
 self.Hole.ThreadType = 0
 self.Hole.HoleCutType = 0
 self.Hole.DepthType = 0

Bug#961095: mkvtoolnix-gui: mkvtoolnix does not start undefined symbol: _ZN11libmatroska22KaxVideoProjectionType10ClassInfosE

[Mauro Dionisi]

When I upgraded to buster I disabled deb-multimedia and I forgot to enable
it again.

After enabling deb-multimedia repository for buster and upgrading the
packages, mkvtoolnix-gui worked again.

Thanks for the advice.

Regards

--
Mauro

On Wed, May 20, 2020, 04:35 Phil Wyett  wrote:

> On Wed, 2020-05-20 at 09:28 +0200, Bernhard Übelacker wrote:
> > > On Tue, 2020-05-19 at 22:05 -0300, Mauro Dionisi wrote:
> > > > Versions of packages mkvtoolnix-gui depends on:
> > > > ii  libebml4v5 1:1.3.9-dmo0+deb9u1
> > > > ii  libmatroska6v5 1:1.4.5-dmo1
> >
> > Hello,
> > might this be related to the above packages being
> > from the debian multimedia repository?
> >
> > Could the issue resolve if these packages get installed
> > in the buster version?
> >
> > Kind regards,
> > Bernhard
> >
>
> I did not spot the presence of the dmo packages.
>
> This app works correctly with Debian buster versions of the packages.
>
> Regards
>
> Phil
>
> --
>
> *** Playing the game for the games sake. ***
>
> WWW: https://kathenas.org
>
> Twitter: @kathenasorg
>
> IRC: kathenas
>
> GPG: 724AA9B52F024C8B
>
>

Bug#923501: clementine: blank window when unminimising from system tray

[Geoff]

Package: clementine
Followup-For: Bug #923501

Hi Thomas,

I'd forgotten all about this bug, I stopped having this problem some months ago 
at least. 

I'm on Sid, Clementine version 1.4.0~rc1+git174-gcb64d9705+dfsg-2.

Thanks,
Geoff

Bug#850254: node-extract-zip: dependencies

[merkys]

Control: unblock 850254 by 862294 925181

Hello,

As of v2.0.0, extract-zip depends neither on node-rifraf nor
node-standard.js.

Best,
Andrius

Bug#961132: light-locker: with the nvidia driver, light-locker suspends the system when locking

[Vincent Lefevre]

Package: light-locker
Version: 1.8.0-3
Severity: important

With the nvidia driver, light-locker suspends the system when locking.
In the journalctl logs, I get a line like

May 20 09:16:43 zira systemd-logind[785]: Suspending...

and according to the systemd maintainer, this is light-locker's fault.

This happens at lock time, thus immediately with --no-late-locking,
and at the time of screensaver deactivation with --late-locking.

Note: Until yesterday, IIRC, using --no-late-locking (at least) did
not trigger a suspend, but the screen was unblanked after a few seconds
(it remained black, but the DPMS state was no longer off, which defeats
the purpose of the screensaver nowadays). So this may be related to
some conditions.

Moreover, after the resume, this puts the system in a bad state, and
the X server (thus lightdm) no longer works (apparently, according to
the lightdm Xorg logs, no screens found). I can switch to a VT, but
the login prompt is shown only for a fraction of second, after which
I just get a blinking cursor over a black screen.

In case this matters, my xrandr configuration is

  xrandr --output DP-3 --off \
 --output DP-4 --auto --primary \
 --output DP-5 --auto --right-of DP-4

where DP-3 corresponds to the laptop screen. But this is no longer
honored after the resume.

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

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

Versions of packages light-locker depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.36.0-1
ii  libc62.30-8
ii  libcairo21.16.0-4
ii  libdbus-1-3  1.12.16-2
ii  libdbus-glib-1-2 0.110-5
ii  libglib2.0-0 2.64.2-1
ii  libgtk-3-0   3.24.20-1
ii  libpango-1.0-0   1.44.7-4
ii  libpangocairo-1.0-0  1.44.7-4
ii  libsystemd0  245.5-2
ii  libx11-6 2:1.6.9-2+b1
ii  libxext6 2:1.3.3-1+b2
ii  libxss1  1:1.2.3-1
ii  lightdm  1.26.0-7

light-locker recommends no packages.

light-locker suggests no packages.

-- no debconf information

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#961133: qcustomplot: buildtest-plot autopkgtest fails with Qt 5.14 because of deprecation warning

[Dmitry Shachnev]

Source: qcustomplot
Version: 2.0.1+dfsg1-1
Tags: patch
User: debian-qt-...@lists.debian.org
Usertags: qt5.14

Dear Maintainer,

One of qcustomplot autopkgtests fails when run against Qt 5.14, currently
available in experimental. It fails because of stderr:

  [ 83%] Building CXX object CMakeFiles/plots.dir/mainwindow.cpp.o
  /tmp/tmp.vk2CMqIqRc/src/mainwindow.cpp: In member function ‘void 
MainWindow::realtimeDataSlot()’:
  /tmp/tmp.vk2CMqIqRc/src/mainwindow.cpp:1386:29: warning: ‘int 
QTime::elapsed() const’ is deprecated: Use QElapsedTimer instead 
[-Wdeprecated-declarations]
   1386 |   double key = time.elapsed()/1000.0; // time elapsed since start of 
demo, in seconds
| ^
  In file included from /usr/include/x86_64-linux-gnu/qt5/QtCore/QDateTime:1,
   from /usr/include/qcustomplot.h:61,
   from /tmp/tmp.vk2CMqIqRc/src/mainwindow.h:47,
   from /tmp/tmp.vk2CMqIqRc/src/mainwindow.cpp:42:
  /usr/include/x86_64-linux-gnu/qt5/QtCore/qdatetime.h:230:54: note: declared 
here
230 | QT_DEPRECATED_X("Use QElapsedTimer instead") int elapsed() const;
|  ^~~

Attached is a patch that changes the code to use QElapsedTimer, as suggested.
It works with Qt 5.12 too.

--
Dmitry Shachnev
Description: use QElapsedTimer instead of deprecated QTime::elapsed()
Author: Dmitry Shachnev 
Forwarded: no
Last-Update: 2020-05-19

--- a/examples/plots/mainwindow.cpp
+++ b/examples/plots/mainwindow.cpp
@@ -1381,9 +1381,11 @@ void MainWindow::setupFinancialDemo(QCus
 
 void MainWindow::realtimeDataSlot()
 {
-  static QTime time(QTime::currentTime());
+  static QElapsedTimer timer;
+  if (!timer.isValid())
+timer.start();
   // calculate two new data points:
-  double key = time.elapsed()/1000.0; // time elapsed since start of demo, in seconds
+  double key = timer.elapsed()/1000.0; // time elapsed since start of demo, in seconds
   static double lastPointKey = 0;
   if (key-lastPointKey > 0.002) // at most add point every 2 ms
   {


signature.asc
Description: PGP signature

Bug#961134: Mark one more symbol as optional for ppc64 when building with -O3

[Matthias Klose]

Package: src:spdlog
Version: 1:1.5.0+ds-3
Severity: important
Tags: sid bullseye

Mark one more symbol as optional for ppc64 when building with -O3.

patch at
http://launchpadlibrarian.net/480607863/spdlog_1%3A1.5.0+ds-3_1%3A1.5.0+ds-3ubuntu1.diff.gz

Bug#961124: systemd: suspend for no apparent reasons when using light-locker and the screensaver becomes inactive

[Vincent Lefevre]

On 2020-05-20 15:44:43 +0200, Michael Biebl wrote:
> logind provides the mechanism (how to suspend), the desktop the
> policy (when to suspend).
> In this case this appears to be light-locker/XFCE.

When I closed the lid (and handle-lid-switch was not inhibited),
I got the reason in the logs:

May 20 13:28:20 zira systemd-logind[786]: Lid closed.
May 20 13:28:20 zira systemd-logind[786]: Suspending...

But here, no reason was given, i.e. just the "Suspending..." line,
which made me assume that it was logind's own decision. The reason
is important enough to have something in the logs!

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#959619: urwid: FTBFS: dh_auto_test: error: pybuild --test -i python{version} -p 3.8 returned exit code 13

[Matthias Klose]

I see this on the Launchpad buildds, building the package. Adding a build
dependency on locales-all fixes this.  I assume that the same dependency needs
to be added for the autopkg test.

Bug#942249: ITP: inkscape-ext-textext -- Re-editable LaTeX graphics for Inkscape

[Antonio Russo]

Hello! I'm glad someone is finding use for this.  I updated the
packaging in [1].  Notice the change in package name to
inkscape-textext, which more closely matches other inkscape extension
packages.

It "works" in the sense that it compiles, installs, and creates
basic objects in inkscape, but I haven't tested the packaging
(or the actual extension) beyond that.

I'd appreciate any feedback you have while testing and using it.

I'll try to get around to uploading to debian-mentors again and
asking for a sponsor in the near-ish future.

Best,
Antonio

[1] https://salsa.debian.org/aerusso-guest/textext

On 5/20/20 3:59 AM, Adrien Grellier wrote:
> Hi,
> 
> Thank your for your package of TexText. I successfully compile your package 
> for Buster, for a user of our laboratory, but failed to use it.
> 
> Upstream developpers released a new version recently (1.0.1), do you intend 
> to package it ? It can solve the bugs I encountered.
> 
> Kind regards,
> 
> Adrien
> 
> *--
> 
> Adrien Grellier  (02 40 37 15 55)
> Administrateur système du LHEEA
> CNRS – École Centrale de Nantes*

Bug#961135: RFS: git-repo-updater/0.5.1-1 [ITP] -- Tool to update multiple git repositories at once (Python 3)

[Sudip Mukherjee]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "git-repo-updater"

 * Package name: git-repo-updater
   Version : 0.5.1-1
   Upstream Author : Ben Kurtovic 
 * URL : https://github.com/earwig/git-repo-updater
 * License : MIT
 * Vcs : https://salsa.debian.org/sudip/git-repo-updater
   Section : python

It builds those binary packages:

  python3-git-repo-updater - Tool to update multiple git repositories at once 
(Python 3)

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

  https://mentors.debian.net/package/git-repo-updater

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

  dget -x 
https://mentors.debian.net/debian/pool/main/g/git-repo-updater/git-repo-updater_0.5.1-1.dsc

Changes since the last upload:

   * Initial release (Closes: #950907)


-- 
Regards
Sudip

Bug#961136: recode: Consider switching upstream and package new version (3.7.1)?

[Boyuan Yang]

Source: recode
Severity: important
Version: 3.6-24
X-Debbugs-CC: sanv...@debian.org

Dear Debian recode maintainer,

According to https://www.gnu.org/software/recode/ , the new upstream
of package recode is now https://github.com/rrthomas/recode . GNU
is no longer hosting this software. Please consider switching the
upstream and package new version (3.7.1).

Thanks and please let me know if you have any questions.

-- 
Regards,
Boyuan Yang

Bug#960611: jengelman-shadow: Please update to version 5.1.0 or higher

[Olek Wojnar]

Update: I was able to temporarily work around this dependency so I don't
consider this time-sensitive anymore and I've removed the block. Once
checker-framework is through NEW, I'll create an upgrade bug for
checker-framework and set this bug to block the checker-framework upgrade
bug.

-Olek

Bug#960773: gr-gsm: FTBFS on s390x

[Adrian Bunk]

Control: retitle -1 gr-gsm FTBFS on big endian

On Sat, May 16, 2020 at 03:09:07PM +0200, Sebastian Ramacher wrote:
> Source: gr-gsm
> Version: 0.42.2.20200214-1
> Severity: serious
> Tags: ftbfs
> Justification: fails to build from source (but built successfully in the past)
> 
> gr-gsm failed to build on s390x:
> https://buildd.debian.org/status/fetch.php?pkg=gr-gsm&arch=s390x&ver=0.42.2.20200214-1&stamp=1589387991&raw=0

It also FTBFS on hppa/powerpc/ppc64, this is FTBFS on big endian.

The options forward are:
1. try to fix it for big endian with likely 0 users, or
2. submit a bug against ftp.debian.org asking for removal of the
   stale s390x binary, with lowering of the severity of this bug

> Cheers

cu
Adrian

Bug#888705: abseil-cpp packaging

[Benjamin Barenblat]

On Tuesday, May 19, 2020, at  8:59 PM +0200, László Böszörményi (GCS) wrote:
> Doesn't build with GCC 10 due to symbol changes.

Good point. Is there an established way to deal with this? Or should I
just upload this as-is to unstable and then upload a GCC-10-compatible
version to experimental?

> How do you plan Git tagging? Might be better to prefix current tags with
> 'upstream/' and have Debian releases under 'debian/'.

I generally try to keep upstream’s tags intact so that no signatures get
broken. Abseil doesn’t currently sign tags, but they might in the
future, and I’d be a bit bummed if we couldn’t benefit from that. I
think it’s totally reasonable to put Debian releases under debian/, so
if you prefer that approach, I’ll make sure to prefix my tags.

> Rules-Requires-Root might be set to 'no' I guess, but that's nitpicking.

Today I learned about Rules-Requires-Root! I’ve fixed that and pushed
the change.

On Wednesday, May 20, 2020, at 12:03 PM +0200, László Böszörményi (GCS) wrote:
> Please do build static libraries with the following patch.

This is great – thanks! I’m still unfamiliar with CMake; I really
appreciate you figuring out the incantations to get it to build both.

As written, this patch builds shared libraries first and then archives,
which causes abslTargets.cmake to prefer archives over shared objects
when linking against Abseil. I’d like to modify it to go in the other
order, thus preferring shared libraries over archives. Requiring an
explicit opt-in before using Abseil archives would make it more
difficult to accidentally violate the One Definition Rule by
accidentally double-linking an Abseil archive. Furthermore, it would
create less work for packagers trying to use the shared Abseil
libraries, which I expect will be the usual case inside Debian. Does
that sound reasonable?

Bug#960876: bcalm: diff for NMU version 2.2.2-1.1

[Stefano Rivera]

Control: tags 960876 + patch

Dear maintainer,

I've prepared an NMU for bcalm (versioned as 2.2.2-1.1). The diff
is attached to this message.

Regards.

SR
diff -Nru bcalm-2.2.2/debian/bcalm.install bcalm-2.2.2/debian/bcalm.install
--- bcalm-2.2.2/debian/bcalm.install	2020-05-05 12:21:17.0 -0700
+++ bcalm-2.2.2/debian/bcalm.install	2020-05-20 08:51:23.0 -0700
@@ -1,6 +1,5 @@
-debian/missing-sources/compare_fasta.py usr/share/doc/bcalm/test
-debian/missing-sources/reference.fasta usr/share/doc/bcalm/test
-debian/missing-sources/simple_test.sh usr/share/doc/bcalm/test
 example/* usr/share/doc/bcalm/test
 test/* usr/share/doc/bcalm/test
 debian/missing-sources/compare_fasta.py usr/share/doc/bcalm/test
+debian/missing-sources/reference.fasta usr/share/doc/bcalm/test
+debian/missing-sources/simple_test.sh usr/share/doc/bcalm/test
diff -Nru bcalm-2.2.2/debian/changelog bcalm-2.2.2/debian/changelog
--- bcalm-2.2.2/debian/changelog	2020-05-05 12:21:17.0 -0700
+++ bcalm-2.2.2/debian/changelog	2020-05-20 08:51:35.0 -0700
@@ -1,3 +1,11 @@
+bcalm (2.2.2-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Overwrite upstream's simple_test with our fixed version, so we test with
+Python 3, again. And depend on it for the test. (Closes: #960876)
+
+ -- Stefano Rivera   Wed, 20 May 2020 08:51:35 -0700
+
 bcalm (2.2.2-1) unstable; urgency=medium
 
   * Team upload.
diff -Nru bcalm-2.2.2/debian/tests/control bcalm-2.2.2/debian/tests/control
--- bcalm-2.2.2/debian/tests/control	2020-05-05 12:21:03.0 -0700
+++ bcalm-2.2.2/debian/tests/control	2020-05-20 08:51:33.0 -0700
@@ -1,3 +1,3 @@
 Tests: run-unit-test
-Depends: @
+Depends: @, python3
 Restrictions: allow-stderr

Bug#961138: autodep8 uses host APT packages to generate dependencies for pkg-r-autopkgtest tests

[Stefano Rivera]

Package: autodep8
Version: 0.16
Severity: normal

The autodep8 generator for pkg-r-autopkgtest uses APT lists to determine
which R packages from DESCRIPTION exist in Debian. autodep8 is run
outside the test runner, not inside it, so this makes the behaviour
dependant on the packages available to the test runner host.

Here's the code that introduced this approach:
https://salsa.debian.org/ci-team/autodep8/-/merge_requests/10

It all works when the autopkgtest runner has approximately the same
packages available as the release under test, but that's not always the
case.

I noticed that the r-bioc-hdf5 package's test misses a dependency on
r-cranc-bit64 when the test is run from an older stable release that
predates this package.

I don't know how else you can solve this particular problem, though...

SR

Bug#888705: abseil-cpp packaging

[GCS]

On Wed, May 20, 2020 at 5:56 PM Benjamin Barenblat  wrote:
> On Tuesday, May 19, 2020, at  8:59 PM +0200, László Böszörményi (GCS) wrote:
> > Doesn't build with GCC 10 due to symbol changes.
>
> Good point. Is there an established way to deal with this? Or should I
> just upload this as-is to unstable and then upload a GCC-10-compatible
> version to experimental?
 You don't have to - but please be prepared that when GCC 10 will be
the default in Sid, Abseil will FTBFS.

> On Wednesday, May 20, 2020, at 12:03 PM +0200, László Böszörményi (GCS) wrote:
> > Please do build static libraries with the following patch.
>
> This is great – thanks! I’m still unfamiliar with CMake; I really
> appreciate you figuring out the incantations to get it to build both.
>
> As written, this patch builds shared libraries first and then archives,
> which causes abslTargets.cmake to prefer archives over shared objects
> when linking against Abseil. I’d like to modify it to go in the other
> order, thus preferring shared libraries over archives. Requiring an
> explicit opt-in before using Abseil archives would make it more
> difficult to accidentally violate the One Definition Rule by
> accidentally double-linking an Abseil archive. Furthermore, it would
> create less work for packagers trying to use the shared Abseil
> libraries, which I expect will be the usual case inside Debian. Does
> that sound reasonable?
 Yup, please do so. Thanks go to you for packaging it and hopefully
uploaded soon.

Laszlo/GCS

Bug#961139: RFS: tolua++/1.0.93-3.1 [NMU, RC] -- extended tool to integrate C/C++ code with Lua (devel)

[Mateusz Łukasik]

Package: sponsorship-requests
Severity: important

Dear mentors,

I am looking for a sponsor for my package "tolua++"

 * Package name: tolua++
   Version : 1.0.93-3.1
   Upstream Author : [fill in name and email of upstream]
 * URL : http://www.codenix.com/~tolua/
 * License : Expat
 * Vcs : 
http://svn.debian.org/wsvn/collab-maint/deb-maint/tolua++/trunk
   Section : devel

It builds those binary packages:

  libtolua++5.1-dev - extended tool to integrate C/C++ code with Lua (devel)

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

  https://mentors.debian.net/package/tolua%2B%2B

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

  dget -x 
https://mentors.debian.net/debian/pool/main/t/tolua++/tolua++_1.0.93-3.1.dsc

Changes since the last upload:

   * Non-maintainer upload.
   * Take from Fedora patch for fix FTBFS with scons 3.1.2.
 (Closes: #947583)
   * Bump minimal dh version to 9.

Regards,

--
  Mateusz Łukasik

Bug#961140: vmdb2: documentation (including man page) missing from binary package

[Andrei POPESCU]

Package: vmdb2
Version: 0.14.1-1
Severity: normal

Dear Maintainer,

The source package contains a short manpage, a README, and two (?) other 
markdown files.  Unfortunately they are all missing from the binary 
package.

$ dpkg -L vmdb2 | grep -E '(README|man)'
/usr/share/man
/usr/share/man/man1


Kind regards,
Andrei


-- System Information:
Debian Release: 10.4
  APT prefers proposed-updates
  APT policy: (500, 'proposed-updates'), (500, 'stable'), (1, 'unstable'), (1, 
'testing')
Architecture: arm64 (aarch64)

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

Versions of packages vmdb2 depends on:
ii  cmdtest 0.32-3
ii  debootstrap 1.0.114
ii  kpartx  0.7.9-3
ii  parted  3.2-25
ii  python3 3.7.3-1
ii  python3-cliapp  1.20180812.1-2
ii  python3-jinja2  2.10-2
ii  python3-yaml3.13-2
ii  qemu-utils  1:3.1+dfsg-8+deb10u5

Versions of packages vmdb2 recommends:
pn  ansible  

vmdb2 suggests no packages.

-- no debconf information

Bug#961128: apt-transport-https: https fails with segmentation fault

[Mehturt]

Package: apt-transport-https
Version: 1.4.10
Severity: important

Dear Maintainer,

running "apt update" finishes with segmentation fault
when the following entry is in my sources.list:

deb http://packages.matrix.org/debian stretch main

Removing the entry from sources.list produces no crash.

This seems to be similar to already reported
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=778375


-- System Information:
Debian Release: 9.12
Architecture: amd64 (x86_64)

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

Versions of packages apt-transport-https depends on:
ii  libapt-pkg5.01.4.10
ii  libc62.28-10
ii  libcurl3-gnutls  7.52.1-5+deb9u10
ii  libgcc1  1:6.3.0-18+deb9u1
ii  libstdc++6   8.3.0-6

Versions of packages apt-transport-https recommends:
ii  ca-certificates  20161130+nmu1+deb9u1

apt-transport-https suggests no packages.

-- no debconf information

Bug#961142: snapshot.debian.org: python3 migration

[Baptiste BEAUPLAT]

Package: snapshot.debian.org
Severity: normal

Hi,

As discussed previously with pabs and weasel, I'm interested in taking
on the python 3 migration for snapshot.

With bullseye, the goal is to drop python 2 packages. As such the
framework used by snapshot, pylons, will be removed as the project is
mostly dead and not python3 compatible.

I'm willing to port snapshot to python 3, replacing the pylons framework
in the process.

After doing a bit of research on snapshot and how it works, I believe
that switching over to the flask framework [1] would be a fitting
option. flask is a lightweight python web framework, well maintained and
packaged in Debian.

That would allow us to keep the model part of snapshot, still using
psycopg2 as the driver to communicate with the postgreSQL backend.
Pylons specifics parts will have to be replaced with flask logic and
templates will have to be converted to jinja2.

Technically, I propose we use salsa to work our way on that migration:

- I port a small set of code to python3/flask on my fork
- I add the required tests to cover that set
- I submit a merge request to the snapshot project
- You review and merge the small set to a migration branch
- We go back to step 1 until migration is over

We can use this bug report to tracker progression or to exchange on
technical topics.

Once we are ready to migrate the production, you can merge the migration
branch to master.

To facilitate the migration, I do intend to cover the entire rewrite
with testing with stable+bpo and unstable as targets.

For easier communication, we could also create a #debian-snapshot on
OTFC. Else, I'm available on #-qa or #-admin.

Looking forward to your comments,

Best,
-- 
Baptiste BEAUPLAT - lyknode



signature.asc
Description: OpenPGP digital signature

Bug#961128: apt-transport-https: https fails with segmentation fault

[Julian Andres Klode]

Control: fixed -1 1.5~alpha4
Control: tag -1 unreproducible

On Wed, May 20, 2020 at 03:41:57PM +, meht...@protonmail.com wrote:
> ‐‐‐ Original Message ‐‐‐
> On Wednesday, May 20, 2020 3:04 PM, Julian Andres Klode  
> wrote:
> 
> > Control: tag -1 moreinfo
> >
> > On Wed, May 20, 2020 at 02:41:12PM +0200, Mehturt wrote:
> >
> > > Package: apt-transport-https
> > > Version: 1.4.10
> > > Severity: important
> > > Dear Maintainer,
> > > running "apt update" finishes with segmentation fault
> > > when the following entry is in my sources.list:
> > > deb http://packages.matrix.org/debian stretch main
> > > Removing the entry from sources.list produces no crash.
> > > This seems to be similar to already reported
> > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=778375
> >
> > Please obtain a full backtrace.
> 
> Sorry, not sure what full backtrace means, but I installed 
> apt-transport-https-dbgsym,
> run apt update again and got this using gdb and the core file:

well you clearly miss a libcurl-gnutls dbgsym package, and you need to pass
"full" to bt.

> 
> Core was generated by `/usr/lib/apt/methods/https.bin'.
> Program terminated with signal SIGSEGV, Segmentation fault.
> #0  0x7f0d6c04f4d7 in ?? () from 
> /usr/lib/x86_64-linux-gnu/libcurl-gnutls.so.4
> (gdb) bt
> #0  0x7f0d6c04f4d7 in ?? () from 
> /usr/lib/x86_64-linux-gnu/libcurl-gnutls.so.4
> #1  0x5638ad9bf74b in HttpsMethod::~HttpsMethod (this=0x7ffe4abe9690, 
> __in_chrg=) at ./methods/https.cc:538
> #2  main (argv=) at ./methods/https.cc:546

This fails in curl_easy_cleanup(curl) call.

It might need running this in valgrind to figure out what's going
on, as that seems like something that should work, and it might be
a corruption elsewhere. That said, no idea really how to run the
methods in valgrind.

-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer  i speak de, en

Bug#961143: gpg-wks-client: /usr/lib/gnupg/gpg-wks-client binary provided outside of $PATH

[Michael Prokop]

Package: gpg-wks-client
Version: 2.2.12-1+deb10u1
Severity: normal

Hi,

for example https://wiki.gnupg.org/WKDHosting is mentioning

| gpg --list-options show-only-fpr-mbox  -k $PATTERN | gpg-wks-client -v 
--install-key

But the gpg-wks-client package on Debian provides the
gpg-wks-client binary only as /usr/lib/gnupg/gpg-wks-client,
meaning it's outside of the user's common and default $PATH setting.
Is this by intention?

regards
-mika-


signature.asc
Description: Digital signature