Bug#948562: ITP: fonts-le-murmure -- titling font with many variated glyphs

[Gürkan Myczko]

Package: wnpp
Severity: wishlist

* Package name: fonts-le-murmure
  Version : 0.2
  Upstream Authors: Jérémy Landes 
Alex Slobzheninov
* URL : https://gitlab.com/velvetyne/murmure
* License : OFL-1.1
  Description : titling font with many variated glyphs
 This is a custom typeface designed for the design agency Murmure
 and released by Velvetyne Type Foundry. Cyrillic has been added later 
on.
 The font plays on a skillful mismatch between characters, creating a 
unique

 rhythm which carries our voice.

Package is available at http://phd-sid.ethz.ch/debian/fonts-le-murmure/

Bug#947004: S4Vectors Segmentation fault after r-base-core update (Was: Bug#947004: Tests segfaults (since the r-base-core update?))

[Andreas Tille]

Hi Herve,

I've read your other analysis - thanks for this hint.

On Thu, Jan 09, 2020 at 06:33:35PM +, Pages, Herve wrote:
> For me to be able to troubleshoot this, I would need to have access to 
> your setup. How do I do that?

Just to answer this question that might come up again in future.
You might like to have a look here:


https://wiki.debian.org/singularity#Example_3:_Build_a_larger_image_from_scratch

There are also docker containers of Debian unstable around that
should be able to reproduce the issue.

Thanks again for your input

  Andreas.

-- 
http://fam-tille.de

Bug#948561: libsoup2.4-1 Depends on glib-networking -> gsettings-desktop-schemas -> dconf-gsettings-backend -> dconf-service, which wants a running dbus

[Josh Triplett]

Package: libsoup2.4-1
Version: 2.68.2-1
Severity: normal

libsoup2.4-1, which is pulled in by various libraries and development
packages, has a dependency chain through glib-networking to
dconf-service, which in turn depends on having a running dbus. This
seems a bit much for a library to expect, especially if the user is just
installing build dependencies and -dev packages.

Would it be possible for some part of this dependency chain to move to
libsoup-gnome2.4-1, or otherwise not get pulled in when just trying to
do development and builds?

Thanks,
Josh Triplett

Bug#948491: centengine crashes regulary

[Pascal Vibet - ADACIS]

I sorry for delay to respond.

I do what you want to do:

janv. 10 06:44:50 centreon-01 sudo[15910]:   pvibet : TTY=pts/0 ;
PWD=/home/pvibet ; USER=root ; TSID=JX ; COMMAND=/usr/bin/systemctl
restart centengine.service
janv. 10 06:44:50 centreon-01 sudo[15910]: pam_unix(sudo:session): session
opened for user root by pvibet(uid=0)
janv. 10 06:44:50 centreon-01 systemd[1]: Started Centreon Engine.
janv. 10 06:44:50 centreon-01 sudo[15910]: pam_unix(sudo:session): session
closed for user root
janv. 10 06:44:50 centreon-01 centengine[15914]: [1578635090] [15914]
Reading main configuration file '/etc/centreon-engine/centengine.cfg'.
janv. 10 06:44:50 centreon-01 centengine[15914]: [1578635090] [15914]
Processing object config file '/etc/centreon-engine/hostTemplates.cfg'
janv. 10 06:44:50 centreon-01 centengine[15914]: [1578635090] [15914]
Processing object config file '/etc/centreon-engine/hosts.cfg'
janv. 10 06:44:50 centreon-01 centengine[15914]: [1578635090] [15914]
Processing object config file '/etc/centreon-engine/serviceTemplates.cfg'
janv. 10 06:44:50 centreon-01 centengine[15914]: [1578635090] [15914]
Processing object config file '/etc/centreon-engine/services.cfg'
janv. 10 06:44:50 centreon-01 centengine[15914]: [1578635090] [15914]
Processing object config file '/etc/centreon-engine/commands.cfg'
janv. 10 06:44:50 centreon-01 centengine[15914]: [1578635090] [15914]
Processing object config file '/etc/centreon-engine/contactgroups.cfg'
janv. 10 06:44:50 centreon-01 centengine[15914]: [1578635090] [15914]
Processing object config file '/etc/centreon-engine/contacts.cfg'
janv. 10 06:44:50 centreon-01 centengine[15914]: [1578635090] [15914]
Processing object config file '/etc/centreon-engine/hostgroups.cfg'
janv. 10 06:44:50 centreon-01 centengine[15914]: [1578635090] [15914]
Processing object config file '/etc/centreon-engine/servicegroups.cfg'
janv. 10 06:44:50 centreon-01 centengine[15914]: [1578635090] [15914]
Processing object config file '/etc/centreon-engine/timeperiods.cfg'
janv. 10 06:44:50 centreon-01 centengine[15914]: [1578635090] [15914]
Processing object config file '/etc/centreon-engine/escalations.cfg'
janv. 10 06:44:50 centreon-01 centengine[15914]: [1578635090] [15914]
Processing object config file '/etc/centreon-engine/dependencies.cfg'
janv. 10 06:44:50 centreon-01 centengine[15914]: [1578635090] [15914]
Processing object config file '/etc/centreon-engine/connectors.cfg'
janv. 10 06:44:50 centreon-01 centengine[15914]: [1578635090] [15914]
Processing object config file '/etc/centreon-engine/meta_commands.cfg'
janv. 10 06:44:50 centreon-01 centengine[15914]: [1578635090] [15914]
Processing object config file '/etc/centreon-engine/meta_timeperiod.cfg'
janv. 10 06:44:50 centreon-01 centengine[15914]: [1578635090] [15914]
Processing object config file '/etc/centreon-engine/meta_host.cfg'
janv. 10 06:44:50 centreon-01 centengine[15914]: [1578635090] [15914]
Processing object config file '/etc/centreon-engine/meta_services.cfg'
janv. 10 06:44:50 centreon-01 centengine[15914]: [1578635090] [15914]
Reading resource file '/etc/centreon-engine/resource.cfg'
janv. 10 06:44:50 centreon-01 centreon-engine[15914]: [1578635090] [15914]
Centreon Engine 18.10.0 starting ... (PID=15914)
janv. 10 06:44:50 centreon-01 centreon-engine[15914]: [1578635090] [15914]
Local time is Fri Jan 10 06:44:50 2020
LOG VERSION: 2.0
janv. 10 06:44:50 centreon-01 centreon-engine[15914]: [1578635090] [15914]
Event broker module '/usr/lib/centreon-broker/cbmod.so' initialized
successfully
janv. 10 06:44:50 centreon-01 centreon-engine[15914]: [1578635090] [15914]
Event broker module '/usr/lib/centreon-engine/externalcmd.so' initialized
successfully
janv. 10 06:44:50 centreon-01 centreon-engine[15914]: [1578635090] [15914]
INITIAL HOST STATE: srv.local.lan;UP;HARD;1;OK - 192.168.1.45: rta 0,592ms,
lost 0%

(...)

janv. 10 07:44:50 centreon-01 kernel: centengine[15914]: segfault at 0 ip
5580663a0868 sp 7ffdec3e5bb0 error 4 in
centengine[55806627d000+134000]
janv. 10 07:44:50 centreon-01 kernel: Code: 89 c2 4c 89 ee 4c 89 e7 e8 35
d0 ed ff ba 01 00 00 00 48 8d 35 03 94 01 00 4c 89 e7 e8 21 d0 ed ff 48 8b
5b 18 48 85 db 74 58 <48> 83 3b 00 74 f1 ba 01 00 00 00 48 8d 35 07 9a 01
00 48 89 ef e8
janv. 10 07:44:50 centreon-01 systemd[1]: Started Process Core Dump (PID
18427/UID 0).
janv. 10 07:44:50 centreon-01 systemd[1]: centengine.service: Main process
exited, code=dumped, status=11/SEGV
janv. 10 07:44:50 centreon-01 systemd[1]: centengine.service: Failed with
result 'core-dump'.
janv. 10 07:44:51 centreon-01 systemd-coredump[18428]: Process 15914
(centengine) of user 108 dumped core.

 Stack trace of
thread 15914:
 #0
 0x5580663a0868
_ZN3com8centreon6engine9retention4dump15customvariablesERSoRK28customvariablesmember_struct

Bug#948560: Use of 'is' token for comparing string in knownhosts.py

[Witold Baryluk]

Package: python3-twisted
Version: 18.9.0-6
Severity: normal


During update to new python3-twisted:

Setting up python3-twisted (18.9.0-6) ...
/usr/lib/python3/dist-packages/twisted/conch/client/knownhosts.py:492: 
SyntaxWarning: "is" with a literal. Did you mean "=="?
  if keytype is "EC":


It appears to be fixed in twisted 19.2.0+ tho:
https://github.com/twisted/twisted/commit/de05fee07a39d3415e4a3e9738d141b43b54f95c
which was released almost a year ago.



-- 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.3.0-2-amd64 (SMP w/12 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 python3-twisted depends on:
ii  python3   3.7.5-3
ii  python3-attr  18.2.0-1
ii  python3-automat   0.6.0-1
ii  python3-constantly15.1.0-1
ii  python3-hamcrest  1.9.0-2
ii  python3-hyperlink 19.0.0-1
ii  python3-idna  2.6-2
ii  python3-incremental   16.10.1-3.1
ii  python3-openssl   19.0.0-1
ii  python3-service-identity  18.1.0-5
ii  python3-twisted-bin   18.9.0-6
ii  python3-zope.interface4.6.0-4

python3-twisted recommends no packages.

Versions of packages python3-twisted suggests:
pn  python3-glade2
pn  python3-gtk2  
pn  python3-pampy 
pn  python3-qt4   
ii  python3-serial3.4-5
pn  python3-tk
pn  python3-wxgtk2.8  

-- no debconf information

Bug#948559: double-conversion: Please make autopkgtests cross-test-friendly

[Steve Langasek]

Package: double-conversion
Version: 3.1.5-4
Severity: minor
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu focal ubuntu-patch

Hi Mo,

In Ubuntu, we are in the process of moving the i386 architecture to a
compatibility-only layer on amd64, and therefore we are also moving our
autopkgtest infrastructure to test i386 binaries in a cross-environment.

This requires changes to some tests so that they are cross-aware and can do
the right thing.

The double-conversion tests currently fail in this environment, because
there are build tests that do not invoke the toolchain in a cross-aware
manner.  I've verified that the attached patch lets the tests successfully
build (and run) i386 tests on an amd64 host.

As part of the patch I am dropping the first of the two tests listed in
debian/tests/control, after determining that the two tests are redundant
with one another since both are just building and running the test suite.

Note that upstream autopkgtest doesn't currently set DEB_HOST_ARCH so this
is a complete no-op in Debian for the moment.  Support for cross-testing in
autopkgtest is currently awaiting review at
https://salsa.debian.org/ci-team/autopkgtest/merge_requests/69 and once
landed, will still have no effect unless autopkgtest is invoked with a '-a'
option.  So this change should be safe to land in your package despite this
not being upstream in autopkgtest.

Thanks for considering,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru double-conversion-3.1.5/debian/tests/control 
double-conversion-3.1.5/debian/tests/control
--- double-conversion-3.1.5/debian/tests/control2019-07-09 
19:40:33.0 -0700
+++ double-conversion-3.1.5/debian/tests/control2020-01-09 
22:28:28.0 -0800
@@ -1,7 +1,3 @@
-# build and run upstream unit tests
-Test-Command: g++ test/cctest/*.cc -ldouble-conversion -o run_tests; make test
-Depends: @, build-essential
-
 Tests: unittest.sh
 Depends: @, build-essential
 
diff -Nru double-conversion-3.1.5/debian/tests/unittest.sh 
double-conversion-3.1.5/debian/tests/unittest.sh
--- double-conversion-3.1.5/debian/tests/unittest.sh2019-11-23 
22:40:08.0 -0800
+++ double-conversion-3.1.5/debian/tests/unittest.sh2020-01-09 
22:28:13.0 -0800
@@ -3,18 +3,24 @@
 
 elfname="run_tests"
 
+if [ -n "${DEB_HOST_GNU_TYPE:-}" ]; then
+CROSS_COMPILE="$DEB_HOST_GNU_TYPE-"
+else
+CROSS_COMPILE=
+fi
+
 # compile src into object files
 srcs=$(find test/cctest -type f -name '*.cc' -print)
 for src in $srcs; do
if ! test -r ${src%.cc}.o; then
-   g++ -march=native -c $src -o ${src%.cc}.o
+   ${CROSS_COMPILE}g++ -march=native -c $src -o ${src%.cc}.o
echo CXX $src
fi
 done
 
 # link
 objs=$(find test/cctest -type f -name '*.o' -print)
-g++ -o $elfname $objs -ldouble-conversion
+${CROSS_COMPILE}g++ -o $elfname $objs -ldouble-conversion
 echo LD $elfname
 
 # execute

Bug#948332: extended next hop capability not working in Buster

[David Lamparter]

Hi Thomas,


could you maybe cherrypick the same patches from the 6.0 branch?
The relevant commit IDs are
e933c6dd9d62bf8ed09f5eb47d3f1cc59405a492
048586179fe635ee01af371411b81c49238e3581

This should come down to the exact same changes, just with a lower
chance for error & is a bit more useful when looking up details about
the patches (e.g. you can get to the upstream CI PASS for 6.0 from these
IDs, which is way more relevant than the fact that it passed on 7.2.)

Cheers,


-David

Bug#948558: firejail-profiles: firefox running under firejail cannot load system-wide add-ons

[Mad Horse]

Package: firejail-profiles
Version: 0.9.62-2
Severity: normal

Dear Maintainer,

In current profiles for firefox (maybe for other browsers, too),
/usr/share/webext/ is not whitelisted,
causing system-wide add-ons installed via apt and dpkg cannot get loaded by
firefox running under firejail.

A 'whitelist /usr/share/webext/' might be added to profiles for browsers
using
webext in order to fix this,
as I walkaround it by putting this in my ~/.config/firejail/firefox.local .



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

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

Versions of packages firejail-profiles depends on:
ii firejail 0.9.62-2

firejail-profiles recommends no packages.

firejail-profiles suggests no packages.

-- no debconf information

Bug#948557: mark libforms-bin Multi-Arch: foreign

[Helmut Grohne]

Package: libforms-bin
Version: 1.2.3-1.4
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs
Control: affects -1 + src:mancala

mancala fails to cross build from source, because it fails to run
fdesign, which comes from the libforms-bin package. libforms-bin is
installed for the host architecture and thus cannot be run. To get it
for the build architecture, some dependency needs to be annotated with
:native or :any or some package needs to be marked Multi-Arch: foreign.
I think that libforms-bin is the package that needs this marking. It's
nice to see that libforms-bin and libforms-dev are already laid out in
exactly the way needed for doing so. libforms-bin contains two tools
that convert textual files (fd) into other textual files (C source and
postscript). As such their behaviour is not architecture-dependent. This
property is usually expressed as "Multi-Arch: foreign". Therefore please
consider applying the attached patch.

Helmut
diff --minimal -Nru libforms-1.2.3/debian/changelog 
libforms-1.2.3/debian/changelog
--- libforms-1.2.3/debian/changelog 2019-11-11 03:33:39.0 +0100
+++ libforms-1.2.3/debian/changelog 2020-01-10 06:11:39.0 +0100
@@ -1,3 +1,10 @@
+libforms (1.2.3-1.5) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Mark libforms-bin Multi-Arch: foreign. (Closes: #-1)
+
+ -- Helmut Grohne   Fri, 10 Jan 2020 06:11:39 +0100
+
 libforms (1.2.3-1.4) unstable; urgency=medium
 
   * Non-maintainer upload.
diff --minimal -Nru libforms-1.2.3/debian/control libforms-1.2.3/debian/control
--- libforms-1.2.3/debian/control   2019-11-11 03:32:34.0 +0100
+++ libforms-1.2.3/debian/control   2020-01-10 06:11:36.0 +0100
@@ -61,6 +61,7 @@
 
 Package: libforms-bin
 Architecture: any
+Multi-Arch: foreign
 Section: devel
 Suggests: libforms-dev
 Depends: ${shlibs:Depends}, ${misc:Depends}

Bug#948556: security-tracker: Replace use of SOAPpy (bin/src2bin_text.py, check-external/unknown-packages.py)

[Salvatore Bonaccorso]

Package: security-tracker
Severity: normal

This is to track the following for future updates to
bin/src2bin_text.py and check-external/unknown-packages.py .

As per #948555 as python-soappy might be removed from bullseye, for
later updates of security-tracker when running under bullseye those
would need porting.

The former is currently unused, the later used in a cronjob (but right
now disabled).

Regards,
Salvatore

Bug#948349: multipath issue on Debian 9.11

[Ritesh Raj Sarraf]

Control: tag -1 moreinfo


Hi Ranjan,

On Thu, 2020-01-09 at 17:33 +, Kumar Ranjan wrote:
> Thanks for responding, Ritesh.
> 
> I have used the latest multipath-tools, 

Can you please confirm which specific version you have tested ?
I pushed version 0.8.3 to Unstable yesterday. That's the other thing
you can try out.


> and the problem is not io_setup failed message (which gets rectified
> via fs.aio-max-nr setting), but the “multipath –ll” freezing for 30
> seconds.
> 

I do not have NVMe devices so you'll have to help debug this issue.
When preparing the new version (0.8.3) of multipath-tools, I realized
that the there were some commits added lately. I am not sure if the
older version of multipath-tools had support for NVMe devices.

I also recollect sg3-utils added support for NVMe devices only in the
last version.

https://www.researchut.com/blog/sg3-utils-nvme/


> I have put the snippet for strace during that time. Please let me
> know if you need further information.

Please run multipath-tools in debug mode and see if it provides any
pointers.

-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System


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

Bug#936536: fmcs: Python2 removal in sid/bullseye

[Stuart Prescott]

As noted in #733861, FMCS is now part of python3-rdkit. 

With python3-rdkit installed, the following provides fmcs with Python 3 (once 
#945985 is sorted out)

$ python3
>>> from rdkit.Chem import fmcs
>>> 

I propose that we simply drop the fmcs source package; it has no rdeps other 
than the debichem-cheminformatics blends package (which already includes 
python3-rdkit). Explicitly adding FMCS to the description of python3-rdkit and 
perhaps a Provides python3-fmcs would make it more discoverable.

(It would be possible to expose fmcs so that a simple "import fmcs" worked but 
that doesn't seem like the direction that upstream is going, so I don't 
propose we do so)

If there are no objections over the coming days, I'll implement this plan.

-- 
Stuart Prescotthttp://www.nanonanonano.net/   stu...@nanonanonano.net
Debian Developer   http://www.debian.org/ stu...@debian.org
GPG fingerprint90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7

Bug#948555: python-soappy: should this package be removed?

[Sandro Tosi]

Package: python-soappy
Version: 0.12.22-1
Severity: serious

Hello,
i believe we should remove python-soappy from Debian:

* python2-only code base
* leaf package
* even upstream suggests to use `suds` instead of this project
* the relatively high popcon is because reportbug used to depend on this
  package, but it has migrated to simplesoap/debianbts a long ago.

if i dont hear back within a week with a good reason to keep this package
around, i'll file for its removal.

Regards,
Sandro

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

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

Versions of packages python-soappy depends on:
ii  python 2.7.16-1
ii  python-defusedxml  0.5.0-2
ii  python-wstools 0.4.3-3

python-soappy recommends no packages.

python-soappy suggests no packages.

-- no debconf information

Bug#948554: glib2.0: CVE-2020-6750: Socks5 Proxy: Proxy on a SocketClient set via set_proxy_resolver ignored

[Salvatore Bonaccorso]

Source: glib2.0
Version: 2.62.4-1
Severity: important
Tags: security upstream
Forwarded: https://gitlab.gnome.org/GNOME/glib/issues/1989

Hi,

The following vulnerability was published for glib2.0.

CVE-2020-6750[0]:
| GSocketClient in GNOME GLib through 2.62.4 may occasionally connect
| directly to a target address instead of connecting via a proxy server
| when configured to do so, because the proxy_addr field is mishandled.
| This bug is timing-dependent and may occur only sporadically depending
| on network delays. The greatest security relevance is in use cases
| where a proxy is used to help with privacy/anonymity, even though
| there is no technical barrier to a direct connection. NOTE: versions
| before 2.60 are unaffected.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2020-6750
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-6750
[1] https://gitlab.gnome.org/GNOME/glib/issues/1989

Please adjust the affected versions in the BTS as needed. Please
double check as well that the tracking in the security-tracker is
correct. So it appears that this does not affect buster and older, but
please confirm.

Regards,
Salvatore

Bug#948553: Tomcat9 startup script ignores CATALINA_PID

[Stephane Tranchemer]

Package: tomcat9
Version: 9.0.16-4

In debian 10 (buster)

/usr/share/tomcat9/bin/catalina.sh is ignoring the CATALINA_PID
variable therefore does not generate a PID file accordingly.

example startup command :

set -a; JAVA_HOME="/usr/lib/jvm/java-11-openjdk-amd64"; source
"/etc/default/tomcat9"; CATALINA_HOME="/usr/share/tomcat9";
CATALINA_BASE="/var/lib/tomcat9"; JAVA_OPTS="-Djava.awt.headless=true
-server -Xmx1280M -Xms1280M -Xss2M -Dfile.encoding=EUC-JP
-XX:+PrintGCDetails -XX:+HeapDumpOnOutOfMemoryError
-XX:HeapDumpPath=/volatile/dump/db2-11-test2 -Dcom.atson.test=true
-Dcom.atson.local=false -Dcom.atson.webapp=true
-Dcom.atson.useDB2Type4=false -Dcom.atson.useDataSourceResource=true
-Dcom.atson.XLINK_VIA_GW=true"; \ CATALINA_PID="/var/run/tomcat9.pid";
CATALINA_TMPDIR="/tmp/tomcat9-tomcat9-tmp"; LANG="C.UTF-8";
JSSE_HOME=""; cd "/var/lib/tomcat9";
"/usr/share/tomcat9/bin/catalina.sh" start

The origin of the problem can be found in this line (actually 2 identical
lines) :

2\>\&1 \&\& echo \$! \>\"$catalina_pid_file\" \; \} $catalina_out_command "&"

with this change it works as expected :

-2\>\&1 \&\& echo \$! \>\"$catalina_pid_file\" \; \}
$catalina_out_command "&" +2\>\&1 \& echo \$! \>\"$catalina_pid_file\"
\; \} $catalina_out_command "&"

Bug#945985: rdkit: rebuild with libschroedinger-maeparser1/1.2.2-1

[Stuart Prescott]

Control: blocks -1 by 948552

It actually looks more like schroedinger-coordgenlibs that needs the binNMU to 
pick up the new filename for libmaeparser.so.1 (not libmaeparser.so.1.2).

-- 
Stuart Prescotthttp://www.nanonanonano.net/   stu...@nanonanonano.net
Debian Developer   http://www.debian.org/ stu...@debian.org
GPG fingerprint90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7

Bug#948552: nmu: schroedinger-coordgenlibs_1.3-1

[Stuart Prescott]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu

nmu schroedinger-coordgenlibs_1.3-1 . ANY . unstable . -m "Rebuild against 
libschroedinger-maeparser-dev >= 1.2.2-1"

The binNMU of rdkit (#946247) did not fix #945985; it appears that it is
schroedinger-coordgenlibs that actually needs rebuilding to pick up the new
filename of libmaeparser:

$ ldd /usr/lib/x86_64-linux-gnu/libcoordgen.so.1.3
linux-vdso.so.1 (0x7fff9f9bd000)
libmaeparser.so.1.2 => not found
libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 
(0x7f5445999000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7f5445854000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 
(0x7f544583a000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f544567a000)
/lib64/ld-linux-x86-64.so.2 (0x7f5445c12000)

(rebuilding the package has the linking pick up libmaeparser.so.1 instead)

thanks
Stuart

Bug#948551: docutils-common: conffiles not removed: /etc/emacs/site-start.d/50python-docutils.el

[Paul Wise]

Package: docutils-common
Version: 0.15.2+dfsg-2
Severity: normal
User: debian...@lists.debian.org
Usertags: obsolete-conffile adequate

The recent upgrade did not deal with obsolete conffiles properly.
Please use the dpkg-maintscript-helper support provided by
dh_installdeb to remove these obsolete conffiles on upgrade.

https://www.debian.org/doc/debian-policy/ch-files.html#s-config-files
https://manpages.debian.org/man/1/dh_installdeb

This bug report brought to you by adequate:

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

$ p=docutils-common ; adequate $p ; dpkg-query -W -f='${Conffiles}\n' $p | grep 
obsolete

docutils-common: obsolete-conffile /etc/emacs/site-start.d/50python-docutils.el
 /etc/emacs/site-start.d/50python-docutils.el 4990891acb4f250008e154560e9f235d 
obsolete

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

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

Versions of packages docutils-common depends on:
ii  sgml-base  1.29.1
ii  xml-core   0.18+nmu1

Versions of packages docutils-common recommends:
ii  python-docutils   0.15.2+dfsg-2
ii  python3-docutils  0.15.2+dfsg-2

docutils-common suggests no packages.

-- no debconf information

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#948468: (unplanned) transition: gpsd

[Paul Wise]

On Thu, Jan 9, 2020 at 8:45 AM Paul Gevers wrote:

> Did I just failed to spot it, or is there no bug against gpsd filed
> about this?

The bugs are filed against reverse dependencies (navit/foxtrotgps for eg).

PS: there are two complementary tools that could be used to detect ABI breakage:

https://github.com/lvc/pkg-abidiff
https://sourceware.org/libabigail/manual/abipkgdiff.html

A thread that includes a comparison of the tool:

https://lists.debian.org/msgid-search/192731475679...@web2g.yandex.ru

--
bye,
pabs

https://wiki.debian.org/PaulWise

Bug#948550: buster-pu: package e2fsprogs/1.44.5-1+deb10u2

[Theodore Y. Ts'o]

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

The reason is to fix two security issues which are fixed in 1.45.5.  The
debdiff is attached.  Let me know if this looks good for uploading.

Thanks!!

diff -Nru e2fsprogs-1.44.5/debian/changelog e2fsprogs-1.44.5/debian/changelog
--- e2fsprogs-1.44.5/debian/changelog   2019-09-25 13:37:44.0 -0400
+++ e2fsprogs-1.44.5/debian/changelog   2020-01-09 20:19:57.0 -0500
@@ -1,3 +1,10 @@
+e2fsprogs (1.44.5-1+deb10u3) buster; urgency=medium
+
+  * Fix CVE-2019-5188: potential stack underflow in e2fsck (Closes: #948508)
+  * Fix use after free in e2fsck (Closes: #948517)
+
+ -- Theodore Y. Ts'o   Thu, 09 Jan 2020 20:19:57 -0500
+
 e2fsprogs (1.44.5-1+deb10u2) buster-security; urgency=high
 
   * Fix CVE-2019-5094: potential buffer overrun in e2fsck (Closes: #941139)
diff -Nru 
e2fsprogs-1.44.5/debian/patches/e2fsck-abort-if-there-is-a-corrupted-directory-block.patch
 
e2fsprogs-1.44.5/debian/patches/e2fsck-abort-if-there-is-a-corrupted-directory-block.patch
--- 
e2fsprogs-1.44.5/debian/patches/e2fsck-abort-if-there-is-a-corrupted-directory-block.patch
  1969-12-31 19:00:00.0 -0500
+++ 
e2fsprogs-1.44.5/debian/patches/e2fsck-abort-if-there-is-a-corrupted-directory-block.patch
  2020-01-09 20:19:57.0 -0500
@@ -0,0 +1,53 @@
+From: Theodore Ts'o 
+Date: Thu, 19 Dec 2019 19:37:34 -0500
+Subject: e2fsck: abort if there is a corrupted directory block when rehashing
+
+In e2fsck pass 3a, when we are rehashing directories, at least in
+theory, all of the directories should have had corruptions with
+respect to directory entry structure fixed.  However, it's possible
+(for example, if the user declined a fix) that we can reach this stage
+of processing with a corrupted directory entries.
+
+So check for that case and don't try to process a corrupted directory
+block so we don't run into trouble in mutate_name() if there is a
+zero-length file name.
+
+Addresses-Debian-Bug: 948508
+Addresses: TALOS-2019-0973
+Addresses: CVE-2019-5188
+Signed-off-by: Theodore Ts'o 
+(cherry picked from commit 8dd73c149f418238f19791f9d666089ef9734dff)
+---
+ e2fsck/rehash.c | 9 +
+ 1 file changed, 9 insertions(+)
+
+diff --git a/e2fsck/rehash.c b/e2fsck/rehash.c
+index 7c4ab083..27e1429b 100644
+--- a/e2fsck/rehash.c
 b/e2fsck/rehash.c
+@@ -159,6 +159,10 @@ static int fill_dir_block(ext2_filsys fs,
+   dir_offset += rec_len;
+   if (dirent->inode == 0)
+   continue;
++  if ((name_len) == 0) {
++  fd->err = EXT2_ET_DIR_CORRUPTED;
++  return BLOCK_ABORT;
++  }
+   if (!fd->compress && (name_len == 1) &&
+   (dirent->name[0] == '.'))
+   continue;
+@@ -398,6 +402,11 @@ static int duplicate_search_and_fix(e2fsck_t ctx, 
ext2_filsys fs,
+   continue;
+   }
+   new_len = ext2fs_dirent_name_len(ent->dir);
++  if (new_len == 0) {
++   /* should never happen */
++  ext2fs_unmark_valid(fs);
++  continue;
++  }
+   memcpy(new_name, ent->dir->name, new_len);
+   mutate_name(new_name, _len);
+   for (j=0; j < fd->num_array; j++) {
+-- 
+2.24.1
+
diff -Nru 
e2fsprogs-1.44.5/debian/patches/e2fsck-don-t-try-to-rehash-a-deleted-directory.patch
 
e2fsprogs-1.44.5/debian/patches/e2fsck-don-t-try-to-rehash-a-deleted-directory.patch
--- 
e2fsprogs-1.44.5/debian/patches/e2fsck-don-t-try-to-rehash-a-deleted-directory.patch
1969-12-31 19:00:00.0 -0500
+++ 
e2fsprogs-1.44.5/debian/patches/e2fsck-don-t-try-to-rehash-a-deleted-directory.patch
2020-01-09 20:19:57.0 -0500
@@ -0,0 +1,47 @@
+From: Theodore Ts'o 
+Date: Thu, 19 Dec 2019 19:45:06 -0500
+Subject: e2fsck: don't try to rehash a deleted directory
+
+If directory has been deleted in pass1[bcd] processing, then we
+shouldn't try to rehash the directory in pass 3a when we try to
+rehash/reoptimize directories.
+
+Addresses-Debian-Bug: 948508
+Signed-off-by: Theodore Ts'o 
+(cherry picked from commit 71ba13755337e19c9a826dfc874562a36e1b24d3)
+---
+ e2fsck/pass1b.c | 4 
+ e2fsck/rehash.c | 2 ++
+ 2 files changed, 6 insertions(+)
+
+diff --git a/e2fsck/pass1b.c b/e2fsck/pass1b.c
+index 5693b9cf..bca701ca 100644
+--- a/e2fsck/pass1b.c
 b/e2fsck/pass1b.c
+@@ -705,6 +705,10 @@ static void delete_file(e2fsck_t ctx, ext2_ino_t ino,
+   fix_problem(ctx, PR_1B_BLOCK_ITERATE, );
+   if (ctx->inode_bad_map)
+   ext2fs_unmark_inode_bitmap2(ctx->inode_bad_map, ino);
++  if (ctx->inode_reg_map)
++  ext2fs_unmark_inode_bitmap2(ctx->inode_reg_map, ino);
++  ext2fs_unmark_inode_bitmap2(ctx->inode_dir_map, ino);
++  ext2fs_unmark_inode_bitmap2(ctx->inode_used_map, ino);
+   

Bug#948549: pgadmin3: Segfault when trying toi start query tool

[Erwin Brandstetter]

Package: pgadmin3
Version: 1.22.2-6.pgdg100+1
Severity: grave
Justification: renders package unusable

Introduced with installing pgadmin3 1.22.2-6.pgdg18.04+1
Now it segfaults every time when trying to open the essential query tool. Tried
with Postgres 10, 11, 12.

syslog contains:

Jan 10 03:39:46 brsanuc5 kernel: [15743.124489] pgadmin3[10026]: segfault at 4
ip 7f2b2c55f9a0 sp 7ffd7af56fc8 error 4 in
libcairo.so.2.11600.0[7f2b2c4ee000+cc000]
Jan 10 03:39:46 brsanuc5 kernel: [15743.124505] Code: c0 75 0f 5b c3 0f 1f 44
00 00 c3 0f 1f 80 00 00 00 00 48 89 df 89 c6 5b e9 2d f8 ff ff 66 66 2e 0f 1f
84 00 00 00 00 00 66 90 <8b> 47 04 85 c0 75 19 53 48 8b 47 20 48 89 fb ff
90 00 01 00 00 85

But that's probably irrelevant. Installed the same version or pgadmin3 on a
laptop with Ubuntu bionic. Same problem.
I mailed a related report to pgsql-pkg-debian(at)postgresql(dot)org
https://www.postgresql.org/message-
id/flat/CAGHENJ6W98kvtOOsOeqQjZ1RWfZxeXEq_n6Ebp8n-%2BHVsVQ2jA%40mail.gmail.com

Downgrading to version 1.22.2-5 fixed the problem:

sudo apt-get install pgadmin3=1.22.2-5 pgadmin3-data=1.22.2-5

Regards
Erwin



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

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

Versions of packages pgadmin3 depends on:
ii  libc6 2.28-10
ii  libgcc1   1:8.3.0-6
ii  libgcrypt20   1.8.4-5
ii  libpq512.1-1.pgdg100+1
ii  libstdc++68.3.0-6
ii  libwxbase3.0-0v5  3.0.4+dfsg-8
ii  libwxgtk3.0-gtk3-0v5  3.0.4+dfsg-8
ii  libxml2   2.9.4+dfsg1-7+b3
ii  libxslt1.11.1.32-2.2~deb10u1
ii  pgadmin3-data 1.22.2-6.pgdg100+1

Versions of packages pgadmin3 recommends:
ii  postgresql-client 12+210.pgdg100+1
ii  postgresql-client-10 [postgresql-client]  10.11-1.pgdg100+1
ii  postgresql-client-11 [postgresql-client]  11.6-1.pgdg100+1
ii  postgresql-client-12 [postgresql-client]  12.1-1.pgdg100+1

Versions of packages pgadmin3 suggests:
pn  pgagent 
ii  postgresql-contrib  12+210.pgdg100+1

-- no debconf information

Bug#929825: ping

[Dima Kogan]

Hi. Maintainers: is there a plan? Do yall need help?

Bug#948501: [Pkg-roundcube-maintainers] Bug#948501: roundcube-core: Elastic theme deps not accessible

[Guilhem Moulin]

Control: tag -1 unreproducible moreinfo

On Thu, 09 Jan 2020 at 23:39:57 +0900, Marc Dequènes wrote:
> The new Elastic theme dependencies cannot be loaded.

Works just fine for me with the supplied apache2 and lighttpd config
files, and also on nginx.  Please use reportbug(1) next time, or at
least tell which HTTPd you're using.  Did you perhaps disable symlinks?

> they stop pointing to the right place when accessed via the vhost
> document_root (/var/lib/roundcube/).

They do?

$ readlink /var/lib/roundcube/skins/elastic
/usr/share/roundcube/skins/elastic
$ readlink /var/lib/roundcube/skins/elastic/deps/*
../../../../nodejs/bootstrap/dist/js/bootstrap.bundle.min.js
../../../../nodejs/bootstrap/dist/css/bootstrap.min.css
../../../../javascript/less/less.min.js
$ readlink -e /var/lib/roundcube/skins/elastic/deps/*
/usr/share/nodejs/bootstrap/dist/js/bootstrap.bundle.min.js
/usr/share/nodejs/bootstrap/dist/css/bootstrap.min.css
/usr/share/javascript/less/less.min.js
$ strace -estat stat -L --printf="" /var/lib/roundcube/skins/elastic/deps/*
stat("/var/lib/roundcube/skins/elastic/deps/bootstrap.bundle.min.js", 
{st_mode=S_IFREG|0644, st_size=133657, ...}) = 0
stat("/var/lib/roundcube/skins/elastic/deps/bootstrap.min.css", 
{st_mode=S_IFREG|0644, st_size=146226, ...}) = 0
stat("/var/lib/roundcube/skins/elastic/deps/less.min.js", 
{st_mode=S_IFREG|0644, st_size=97984, ...}) = 0

FWIW ‘foo/bar/baz/../..’ isn't necessarily the same as directory ‘foo’;
that depends if there are any symlinks on the way.

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#948516: xterm: displays incorrect text when one scrolls backward while output is ongoing

[Vincent Lefevre]

On 2020-01-10 03:22:05 +0100, Vincent Lefevre wrote:
> On 2020-01-09 20:54:15 -0500, Thomas Dickey wrote:
> > maybe - but without a typescript which would show me what went to the
> > terminal, I'm missing most of the information needed to investigate it.
> 
> What do you mean exactly?
> 
> Note that the bug is reproducible with almost anything that
> generates output (but not too fast). Running a "./configure"
> is a good practical example.

And this is reproducible with the default X resources, except
scrollTtyOutput (which I had mentioned), e.g.

  unset XAPPLRESDIR
  /usr/bin/xterm -xrm "*scrollTtyOutput: false"

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

Bug#948516: xterm: displays incorrect text when one scrolls backward while output is ongoing

[Vincent Lefevre]

On 2020-01-09 20:54:15 -0500, Thomas Dickey wrote:
> maybe - but without a typescript which would show me what went to the
> terminal, I'm missing most of the information needed to investigate it.

What do you mean exactly?

Note that the bug is reproducible with almost anything that
generates output (but not too fast). Running a "./configure"
is a good practical example.

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

Bug#948548: RM: hsail-tools: please remove the hsail-tools binary for big-endian targets

[Matthias Klose]

Package: ftp.debian.org
Version: 0~20180830-1

please remove the hsail-tools binary for big-endian targets. it's an offload
compiler for AMD pgus, which really are not supported on such targets.

Bug#947754: [omv.dynamicpuzzle.ro] gitlab mattermost integration error

[David L]

Package: gitlab
Version: 12.6.2-2+fto10+1
Followup-For: Bug #947754

Hi,

I've updated to 12.6.2.2 but bug is still present.
I can view a difference on the request from 12.5.4 version:
  Processing by Oauth::AuthorizationsController#new as HTML
Parameters: {"response_type"=>"code", "client_id"=>"", 
"redirect_uri"=>"https:///oauth2/callback/gitlab", 
"state"=>""}
(These two lines are not present on the log in 12.5.4)

Log from 12.6.2, trying to use oauth from my on-premises sonarqube.

Started GET 
"/oauth/authorize?response_type=code_id=_uri=https%3A%2F%2F%2Foauth2%2Fcallback%2Fgitlab="
 for x.x.x.x at 2020-01-10 02:51:01 +0100
Processing by Gitlab::RequestForgeryProtection::Controller#index as HTML
  Parameters: {"response_type"=>"code", "client_id"=>"", 
"redirect_uri"=>"https:///oauth2/callback/gitlab", 
"state"=>""}
Completed 200 OK in 1ms (ActiveRecord: 0.0ms | Elasticsearch: 0.0ms)
Processing by Oauth::AuthorizationsController#new as HTML
  Parameters: {"response_type"=>"code", "client_id"=>"", 
"redirect_uri"=>"https:///oauth2/callback/gitlab", 
"state"=>""}
Completed 500 Internal Server Error in 5ms (ActiveRecord: 0.0ms | 
Elasticsearch: 0.0ms)

NoMethodError (undefined method `mapping' for Doorkeeper::Rails::Routes:Class):

lib/gitlab/request_profiler/middleware.rb:17:in `call'
lib/gitlab/middleware/go.rb:20:in `call'
lib/gitlab/etag_caching/middleware.rb:13:in `call'
lib/gitlab/middleware/correlation_id.rb:16:in `block in call'
lib/gitlab/middleware/correlation_id.rb:15:in `call'
lib/gitlab/middleware/multipart.rb:117:in `call'
lib/gitlab/middleware/read_only/controller.rb:48:in `call'
lib/gitlab/middleware/read_only.rb:18:in `call'
lib/gitlab/middleware/basic_health_check.rb:25:in `call'
lib/gitlab/request_context.rb:32:in `call'
config/initializers/fix_local_cache_middleware.rb:9:in `call'
lib/gitlab/metrics/requests_rack_middleware.rb:49:in `call'
lib/gitlab/middleware/release_env.rb:12:in `call'

I've only updated system (apt-get upgrade && apt-get dist-upgrade), for update 
gitlab and required gems and other apps on the system. I didn't change any 
configuration on gitlab nor sonarqube. Token / appID are the ones generated on 
the past.

Maybe there's another check I can do about this problem? I didn't try with my 
on-premises sentry (they fails also on 12.5.4, check previous reports on this 
bug).

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

Kernel: Linux 4.19.62-mod-std-ipv6-64-rescue (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages gitlab depends on:
ii  asciidoctor 2.0.10-2
ii  bc  1.07.1-2+b2
ii  bundler 1.17.3-3
ii  bzip2   1.0.8-2
ii  dbconfig-pgsql  2.0.13
ii  debconf [debconf-2.0]   1.5.73
ii  exim4-daemon-light [mail-transport-agent]   4.93-5
ii  gitlab-common   12.6.2-2+fto10+1
ii  gitlab-workhorse8.18.0+debian-1~bpo10+1
ii  libjs-bootstrap4 [node-bootstrap]   4.4.1+dfsg1-1
ii  libjs-pdf   1.5.188+dfsg-1~bpo10+1
ii  libjs-popper.js [node-popper.js]1.16.0+ds2-1
ii  libjs-uglify2.8.29-6
ii  lsb-base11.1.0
ii  nginx   1.16.1-2
ii  nginx-full [nginx]  1.16.1-2
ii  node-autosize   4.0.2~dfsg1-3
ii  node-axios  0.19.0+dfsg-2
ii  node-brace-expansion1.1.8-1
ii  node-cache-loader   2.0.1-2
ii  node-chart.js   2.9.3+dfsg-2
ii  node-core-js2.4.1-2
ii  node-css-loader 1.0.1-1
ii  node-d3 5.12.0-1~bpo10+1
ii  node-d3-array   1.2.4-2
ii  node-d3-axis1.0.12-2
ii  node-d3-brush   1.1.5-1
ii  node-d3-ease1.0.5-2
ii  node-d3-scale   2.2.2-1~bpo10+1
ii  node-d3-selection   1.4.0-5
ii  node-d3-shape   1.3.5-2
ii  node-d3-time1.0.11-3
ii  

Bug#948516: xterm: displays incorrect text when one scrolls backward while output is ongoing

[Thomas Dickey]

On Thu, Jan 09, 2020 at 06:05:37PM +0100, Vincent Lefevre wrote:
> Package: xterm
> Version: 351-1
> Severity: normal
> 
> With scrollTtyOutput set to "false", when one scrolls backward while
> output is ongoing, xterm displays incorrect text. This is reproducible
> with the xterm Debian package in the following versions (at least):
> 337-1, 341-1, 344-1, 348-2, 349-1, 351-1. It seems that xterm does not
> fully erase the previous line when scrolling.

maybe - but without a typescript which would show me what went to the
terminal, I'm missing most of the information needed to investigate it.

-- 
Thomas E. Dickey 
https://invisible-island.net
ftp://ftp.invisible-island.net


signature.asc
Description: PGP signature

Bug#948547: RFP: libmill -- Go-style concurrency library for C

[Dmitry Smirnov]

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

   Package name: libmill
Version: 1.18
Upstream Author: Martin Sustrik
License: Expat
URL: Go-style concurrency library for C
Vcs-Browser: https://salsa.debian.org/debian/libmill
Description: Go-style concurrency library for C
 Libmill is a library that introduces Go-style concurrency to C.

--

Packaging is pretty much completed on Salsa.


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

Bug#948546: New upstream release (0.3.2)

[Laurent Bigonville]

Source: libgusb
Version: 0.3.0-1
Severity: wishlist

Hi,

Would it be possible to package the new (0.3.2) upstream release?

Version 0.3.2
~
Released: 2020-01-06

Bugfixes:
 - Do not use deprecated libusb API (Richard Hughes)
 - Fix compilation on macOS (Richard Hughes)
 - Use a 1ms timeout in the Windows event thread (Richard Hughes)
 - Use has_link_argument() to detect linker flags (Richard Hughes)

Version 0.3.1
~
Released: 2019-11-16

New Features:
 - Add g_usb_device_get_spec() (Richard Hughes)
 - Add g_usb_version_string() for fwupd (Richard Hughes)

Bugfixes:
 - Add -Wswitch-enum (Benjamin Berg)
 - Fix GI length introspection annotations (grindhold)
 - Make gir generation optional (maxice8)

Kind regards,

Laurent Bigonville

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

Kernel: Linux 5.4.0-2-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_BE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Permissive - Policy name: refpolicy

Bug#936444: drmaa: Python2 removal in sid/bullseye

[Stuart Prescott]

Dear maintainers,

I've uploaded a new upstream version with Python 3 support to experimental; it 
needs to go through the NEW queue and then needs a source-only upload to 
unstable. I've done more in this upload that I'd often do in an NMU but that 
seems reasonable given that it's only uploading to experimental and that 
neither package nor VCS have seen any love in a very long time.

I've pushed my work to salsa at

https://salsa.debian.org/stuart/python-drmaa

I'd be happy to push the work directly into the package's git repo if you 
like.

While I've made a merge request so that these updates don't get lost, I don't 
think an MR is the best way of updating the multiple branches (master, 
upstream) or the multiple tags, particularly as the previous two maintainer 
uploads were also not found in the VCS.

https://salsa.debian.org/neurodebian-team/python-drmaa/merge_requests/1

(Also, is there a better team for this package to live in, the Python Modules 
team for example?)

regards
Stuart


-- 
Stuart Prescotthttp://www.nanonanonano.net/   stu...@nanonanonano.net
Debian Developer   http://www.debian.org/ stu...@debian.org
GPG fingerprint90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7

Bug#942353: python-evtx: ImportError: No module named hexdump

[Andreas Beckmann]

Followup-For: Bug #942353
Control: tag -1 pending

buster-pu request: https://bugs.debian.org/948545


Andreas

Bug#948545: buster-pu: package python-evtx/0.6.1-1+deb10u1

[Andreas Beckmann]

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

Hi,

let's make python-evtx usable in buster by fixing the hexdump import.
This change is cherry-picked from sid.
the package is already uploaded.


Andreas
diff -Nru python-evtx-0.6.1/debian/changelog python-evtx-0.6.1/debian/changelog
--- python-evtx-0.6.1/debian/changelog  2017-07-17 10:09:27.0 +0200
+++ python-evtx-0.6.1/debian/changelog  2020-01-10 01:26:07.0 +0100
@@ -1,3 +1,12 @@
+python-evtx (0.6.1-1+deb10u1) buster; urgency=medium
+
+  * Non-maintainer upload.
+
+  [ Hilko Bengen ]
+  * Fix hexdump import (Closes: #942353)
+
+ -- Andreas Beckmann   Fri, 10 Jan 2020 01:26:07 +0100
+
 python-evtx (0.6.1-1) unstable; urgency=medium
 
   * New upstream version 0.6.1
diff -Nru python-evtx-0.6.1/debian/patches/0001-Add-missing-hexdump.patch 
python-evtx-0.6.1/debian/patches/0001-Add-missing-hexdump.patch
--- python-evtx-0.6.1/debian/patches/0001-Add-missing-hexdump.patch 
2017-07-17 10:02:49.0 +0200
+++ python-evtx-0.6.1/debian/patches/0001-Add-missing-hexdump.patch 
2020-01-10 01:26:07.0 +0100
@@ -3,12 +3,27 @@
 Subject: Add missing hexdump
 
 ---
- Evtx/hexdump.py | 466 
- 1 file changed, 466 insertions(+)
- create mode 100755 Evtx/hexdump.py
+ Evtx/Nodes.py|   2 +-
+ Evtx/hexdump.py  | 466 +++
+ scripts/evtx_record_structure.py |   2 +-
+ 3 files changed, 468 insertions(+), 2 deletions(-)
+ create mode 100644 Evtx/hexdump.py
 
+diff --git a/Evtx/Nodes.py b/Evtx/Nodes.py
+index 216321d..20b1cbe 100644
+--- a/Evtx/Nodes.py
 b/Evtx/Nodes.py
+@@ -22,7 +22,7 @@ import base64
+ import itertools
+ 
+ import six
+-import hexdump
++import Evtx.hexdump as hexdump
+ 
+ from .BinaryParser import Block
+ from .BinaryParser import ParseException
 diff --git a/Evtx/hexdump.py b/Evtx/hexdump.py
-new file mode 100755
+new file mode 100644
 index 000..fc0e97e
 --- /dev/null
 +++ b/Evtx/hexdump.py
@@ -479,3 +494,14 @@
 +# [ ] document chunking API
 +# [ ] document hexdump API
 +# [ ] blog about sys.stdout text mode problem on Windows
+diff --git a/scripts/evtx_record_structure.py 
b/scripts/evtx_record_structure.py
+index 0da7afa..e19cd25 100755
+--- a/scripts/evtx_record_structure.py
 b/scripts/evtx_record_structure.py
+@@ -1,5 +1,5 @@
+ #!/usr/bin/env python
+-import hexdump
++import Evtx.hexdump as hexdump
+ 
+ import Evtx.Evtx as evtx
+ from Evtx.Nodes import RootNode

Bug#948491: centengine crashes regulary

[Bernhard Übelacker]

Am 09.01.20 um 22:18 schrieb Pascal Vibet - ADACIS:
> @Bernhard : I install 'systemd-coredump' and 'centreon-engine-dbgsym'
> packages. I restart centengine. What information do you need? When
> centengine process crashes ? Or i run a program in same time ? What do
> you want me to do?

Great. Just wait for the next crash and then look at the end of
the command "journalctl --no-pager".
There should be a line with the known 'segfault at'.
This line and the following at nearly the same time would be
interesting, if you could forward them to this bug?

Kind regards,
Bernhard

Bug#948544: buster-pu: package nvidia-graphics-drivers-legacy-340xx/340.108-2~deb10u1

[Andreas Beckmann]

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

Hi,

I'd like to update nvidia-graphics-drivers-legacy-340xx to the last (as
in final) upstream release 340.108. NVIDIA has declared the 340 legacy
driver series as End-of-Life and won't issue any further updates.
A NEWS entry is added to inform the users about this fact.
We did a similar update for nvidia-graphics-drivers-legacy-304xx in
stretch when the 304 legacy driver was EoL-ed.

The package contains all packaging updates and fixes that have
accumulated since the buster release and that I consider suitable for
buster. This helps us keeping the packaging in sync between the 4 driver
series and over the releases from oldstable to experimental.

I'll upload the package to buster-backports once 340.108-2 reached
testing to give it a wider exposure and reach more potential testers.

The attached diff is generated from the git repository and (as usual)
excludes the blobs.

A similar request for stretch will follow.


Andreas


nvidia-graphics-drivers-legacy-340xx_340.108-2~deb10u1.diff.gz
Description: application/gzip

Bug#948481: mmdebstrap: Please support dry-run/simulation mode

[Johannes Schauer]

Control: tag -1 + pending

Attached patch seems to work.
diff --git a/mmdebstrap b/mmdebstrap
index 6219035..003c1ca 100755
--- a/mmdebstrap
+++ b/mmdebstrap
@@ -1465,7 +1465,11 @@ sub setup {
 }
 
 # run setup hooks
-run_hooks('setup', $options);
+if (!$options->{dryrun}) {
+run_hooks('setup', $options);
+} else {
+info "not running setup-hooks because of --dry-run";
+}
 
 info "running apt-get update...";
 run_apt_progress({
@@ -1520,8 +1524,11 @@ sub setup {
 info "downloading packages with apt...";
 run_apt_progress({
 ARGV => [
-'apt-get','--yes',
-'-oApt::Get::Download-Only=true', 'install'
+'apt-get',
+'--yes',
+'-oApt::Get::Download-Only=true',
+$options->{dryrun} ? '-oAPT::Get::Simulate=true' : (),
+'install'
 ],
 PKGS => [@pkgs_to_install],
 });
@@ -1542,8 +1549,11 @@ sub setup {
 info "downloading packages with apt...";
 run_apt_progress({
 ARGV => [
-'apt-get','--yes',
-'-oApt::Get::Download-Only=true', 'dist-upgrade'
+'apt-get',
+'--yes',
+'-oApt::Get::Download-Only=true',
+$options->{dryrun} ? '-oAPT::Get::Simulate=true' : (),
+'dist-upgrade'
 ],
 });
 } elsif (
@@ -1648,8 +1658,11 @@ sub setup {
 info "downloading packages with apt...";
 run_apt_progress({
 ARGV => [
-'apt-get','--yes',
-'-oApt::Get::Download-Only=true', 'install'
+'apt-get',
+'--yes',
+'-oApt::Get::Download-Only=true',
+$options->{dryrun} ? '-oAPT::Get::Simulate=true' : (),
+'install'
 ],
 PKGS => [keys %ess_pkgs],
 });
@@ -1659,7 +1672,7 @@ sub setup {
 
 # extract the downloaded packages
 my @essential_pkgs;
-{
+if (!$options->{dryrun}) {
 my $apt_archives = "/var/cache/apt/archives/";
 opendir my $dh, "$options->{root}/$apt_archives"
   or error "cannot read $apt_archives";
@@ -1674,28 +1687,30 @@ sub setup {
 push @essential_pkgs, $deb;
 }
 close $dh;
-}
 
-if (scalar @essential_pkgs == 0) {
-# check if a file:// URI was used
-open(my $pipe_apt, '-|', 'apt-get', 'indextargets', '--format',
-'$(URI)', 'Created-By: Packages')
-  or error "cannot start apt-get indextargets: $!";
-while (my $uri = <$pipe_apt>) {
-if ($uri =~ /^file:\/\//) {
-error
-  "nothing got downloaded -- use copy:// instead of file://";
+if (scalar @essential_pkgs == 0) {
+# check if a file:// URI was used
+open(my $pipe_apt, '-|', 'apt-get', 'indextargets', '--format',
+'$(URI)', 'Created-By: Packages')
+  or error "cannot start apt-get indextargets: $!";
+while (my $uri = <$pipe_apt>) {
+if ($uri =~ /^file:\/\//) {
+error "nothing got downloaded -- use copy:// instead of"
+  . " file://";
+}
 }
+error "nothing got downloaded";
 }
-error "nothing got downloaded";
 }
 
 # We have to extract the packages from @essential_pkgs either if we run in
 # chrootless mode and extract variant or in any other mode.
 # In other words, the only scenario in which the @essential_pkgs are not
 # extracted are in chrootless mode in any other than the extract variant.
-if ($options->{mode} eq 'chrootless' and $options->{variant} ne 'extract')
-{
+#
+# or: if this is a dry run
+if (($options->{mode} eq 'chrootless' and $options->{variant} ne 'extract')
+or $options->{dryrun}) {
 # nothing to do
 } else {
 info "extracting archives...";
@@ -1742,7 +1757,8 @@ sub setup {
 '-oDPkg::Options::=--force-not-root',
 '-oDPkg::Options::=--force-script-chrootless',
 '-oDPkg::Options::=--root=' . $options->{root},
-'-oDPkg::Options::=--log=' . "$options->{root}/var/log/dpkg.log"
+'-oDPkg::Options::=--log=' . "$options->{root}/var/log/dpkg.log",
+$options->{dryrun} ? '-oAPT::Get::Simulate=true' : (),
 );
 if (defined $options->{qemu}) {
 # The binfmt support on the outside is used, so qemu needs to know
@@ -1773,7 +1789,11 @@ sub setup {
 )
 ) {
 # run essential hooks
-run_hooks('essential', 

Bug#948514: [Pkg-roundcube-maintainers] Bug#948514: roundcube-core: missing dependency on libjs-less

[Guilhem Moulin]

On Fri, 10 Jan 2020 at 00:15:25 +0100, Guilhem Moulin wrote:
> But I guess we could ship symlinks though in case someone wants to
> manually install libjs-less.

Didn't recall I did precisely that last summer:


https://salsa.debian.org/roundcube-team/roundcube/commit/9512c4378c9386840a0b369bd311b18a7767c7f6#1779df0686eda665ee449958bfd19da823410d45

The web console spews some warnings but AFAICT devel mode 
(‘$config['devel_mode'] = true;’)
works out of the box once libjs-less is installed.  Still I don't see the need 
to add it as
dependency, not even as Suggests:.

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#948543: gnome-logs: Unable to start gnome-logs due to Segmentation fault

[Teo]

Package: gnome-logs
Version: 3.30.0-2
Severity: important
Tags: upstream

Hi,
If I run gnome-logs by gui, it crashes instantly.
So I I wanted to investigate, and running it by terminal:
$ gnome-logs

** (gnome-logs:24155): WARNING **: 01:02:25.445: Error retrieving the sender
timestamps: Cannot assign requested address
Segmentation fault

But If I run it by root and not normal user, it works fine.
Finally, I'm agree that only administrator user can reads most of logs, but I
don't think that this behavior is right, rather I believe that a text field
should come out where to enter the administrator password and use it correctly.



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

Kernel: Linux 4.19.0-6-amd64 (SMP w/8 CPU cores)
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8), 
LANGUAGE=it_IT.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 gnome-logs depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.30.1-2
ii  gsettings-desktop-schemas3.28.1-1
ii  libc62.28-10
ii  libglib2.0-0 2.58.3-2+deb10u2
ii  libgtk-3-0   3.24.5-1
ii  libpango-1.0-0   1.42.4-7~deb10u1
ii  libsystemd0  241-7~deb10u2

gnome-logs recommends no packages.

gnome-logs suggests no packages.

-- no debconf information

Bug#948542: firefox: font settings ignored

[gregor herrmann]

Package: firefox
Version: 72.0.1-1
Severity: minor

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

firefox 72.0.1-1 ignores font settings in the preferences (both font
face and font size) and always just uses DejaVu Serif 16px (unless
overridden by the webpage of course). I've tested this is a new empty
profile as well.

This worked until at least 71.0-2, and I never started 72.0-1.


Cheers,
gregor

-BEGIN PGP SIGNATURE-

iQKTBAEBCgB9FiEE0eExbpOnYKgQTYX6uzpoAYZJqgYFAl4Xv4hfFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEQx
RTEzMTZFOTNBNzYwQTgxMDREODVGQUJCM0E2ODAxODY0OUFBMDYACgkQuzpoAYZJ
qgYtZg//dR9yLdwhbPU+AlHrS7kC21QeL87NqAFcM3dRFBcEdcQ4VhGDB/o0jbRi
ZZAT2fJF4Ch7XuFC0a2m3H81JVEWN2sQbmRxZG5M1xQ5g1xkbGu7dGNjohgcknGr
qIPgezXzeMm80itRHG1MfoNj0o918uIn/QCbBCFmsf/d0j1adXdpyYMxceP4upUM
CBhcgHl7oIo53cVXepNwsKfV9EaP+GEyZgvaOQXZe65bERdgN6Xn91y56p52PQk4
2cReS9WCSGdpE9s4SVhAw7+iAO86SRWYcwIS9Fdkcru2ivVEqPGWSVEDyNwU/Ocx
lPf2gpWhYomlQwkG66uEMv5I8xlLHuw8q/6flwsv9UnZhWJX/1iaTZMUIBqxVT1V
qg6Bomyi7ImYBqlmLY/u5LgisZz/jGWKbJ2sOg3iiKBRs5/CdwBEniz0Jgi2yDV/
dVCWA7g/n5ffcWoNjVHBs9ORZWX7M6Gpk5uKeST8rHDBQPtFjE7p/SJYs3pgKHIS
aegaySHgpVdWcvt+McAvM/9UYAXmawqIzbtA8e+cziNDO+6qW7llUikT0PVuwUdZ
CNMxRiOZijYOKn9i0wLeDcNH/JQBHBu2QDtSODMaLUQqXVrIq5rMB/WcGLtHR8kE
YKh07JsaTOp/OTletjBCtm0DUtCQ0HNmMTkNj8Cnq2QDc45iCCY=
=X44g
-END PGP SIGNATURE-

Bug#948541: decoratortools: should this package be removed?

[Sandro Tosi]

Source: decoratortools
Severity: serious

Hello,
recently python-peak.util was removed, and i believe decoratortools should see
the same destiny: it's a python2-only project with the latest release in 2010
and no upstream development.

If i dont hear back within a week with a good reason to keep it around, i'll
file for its removal.

Regards,
Sandro

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

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

Bug#929834: Found a workaround which also solves other oddities

[Christoph Groth]

Enrico Zini wrote:

> This happens with me because the interface appears in the screen where
> the mouse is: try moving the mouse cursor towards the screen that is
> on, and the login window should come with it.

For me this was not the case.  The UI would appear for half a second
immediately after the light-dm shows up, and then disappear from all
monitors.  The mouse cursor would be visible.

I have now installed slick-greeter and removed the file
/etc/X11/xorg.conf that I added as the workaround.  This has solved all
the problems for me.


signature.asc
Description: PGP signature

Bug#947004: S4Vectors Segmentation fault after r-base-core update (Was: Bug#947004: Tests segfaults (since the r-base-core update?))

[Pages, Herve]

Taking a closer look at this it seems that the segfault occurs in the 
following test (S4Vectors/inst/unitTests/test_Rle-utils.R, line 121):

  line 118:  y <- (-20:20)^2
  line 119:  y[c(1,10,21,41)] <- c(100L, 30L, 400L, 470L)
  line 120: checkEqualsNumeric(smoothEnds(y), as.vector(smoothEnds(Rle(y
  line 121: checkEqualsNumeric(runmed(y, 7), as.vector(runmed(Rle(y), 7)))

Based on the traceback the error happens during evaluation of the 1st 
argument ('target') passed to checkEqualsNumeric(), that is, during 
evaluation of 'runmed(y, 7)'. Since this involves base R code only 
(runmed() is implemented in the stats package) I would say that it's not 
immediately obvious that the problem is in my court.

H.

Bug#948519: insufficient boot-time entropy on arm64 virtual machines

[Noah Meyerhans]

On Thu, Jan 09, 2020 at 02:00:01PM -0500, Noah Meyerhans wrote:
> The 5.4 kernel currently in sid does not experience this lack of
> entropy.  It has been suggested that upstream commit 50ee7529ec45
> ("random: try to actively add entropy rather than passively wait for
> it") may be the difference here, but I have not confirmed this.

I've tested 4.19 with the changes from 50ee7529ec45, and it appears to
do the expected thing.  The kernel claims to have enough entropy at boot
that ssh host key generation happens quickly.

This change is likely to also address #931644.  I've asked the submitter
of that bug if they'd be able to test a proposed fix.

I will prepare a merge request and note it here when it's available.

noah

Bug#948540: colord: Please omit colord-sensor-argyll on Ubuntu/i386

[Steve Langasek]

Package: colord
Version: 1.4.4-1
Severity: minor
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu focal ubuntu-patch

Hi Chris,

In Ubuntu, we are in the process (as you may know) of moving the i386
architecture to a compatibility-only layer on amd64.  We are keeping colord
on i386 because it's a build-dependency of gtk+3.0, but the
colord-sensor-argyll binary package built from this source has dependencies
on other packages that are not being kept as part of the compatibility
library set (argyll).

We would like to drop this binary package rather than keeping it around in
the Ubuntu archive and uninstallable.  Would you please consider applying
the attached patch, or something like it, to omit building theis binary
package on Ubuntu?

Thanks for considering,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru colord-1.4.4/debian/rules colord-1.4.4/debian/rules
--- colord-1.4.4/debian/rules   2019-08-13 22:41:01.0 -0700
+++ colord-1.4.4/debian/rules   2020-01-09 15:15:23.0 -0800
@@ -34,6 +34,10 @@
indep_flags = -Dprint_profiles=false
 endif
 
+ifeq ($(shell dpkg-vendor --is Ubuntu && echo yes) $(DEB_HOST_ARCH), yes i386)
+   BUILD_PACKAGES += -Ncolord-sensor-argyll
+endif
+
 debian/stamps/generate_meson_build_system:
mkdir -p debian/stamps
touch debian/stamps/generate_meson_build_system
@@ -58,4 +62,4 @@
dh_makeshlibs -Xcolord-sensors -Xcolord-plugins -- -c4
 
 %:
-   dh $@ --builddirectory=$(BUILD_DIR) --with gir
+   dh $@ --builddirectory=$(BUILD_DIR) --with gir $(BUILD_PACKAGES)

Bug#948514: [Pkg-roundcube-maintainers] Bug#948514: roundcube-core: missing dependency on libjs-less

[Guilhem Moulin]

Control: tag -1 moreinfo

Hi,

On Fri, 10 Jan 2020 at 01:40:56 +0900, Marc Dequènes wrote:
> libjs-less is missing for the new Elastic theme.

Are clients being served .less files?  The intention is to use the .css
files (compiled from the .less sources) instead.  AFAICT .less files are
only used used in devel_mode, which doesn't warrant a new dependency.
But I guess we could ship symlinks though in case someone wants to
manually install libjs-less.

See also the “KNOWN ISSUES” section at the bottom of skins/elastic/README.md .

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#948460: xserver-xorg-video-nvidia-legacy-340xx: Xorg won't start with xserver-xorg-video-nvidia-legacy-340xx on testing/Bullseye

[Andreas Beckmann]

On 09/01/2020 21.17, Alexis wrote:
> I moved the nvidia_drv.so and I ran 'update-glx --config nvidia'. But the

That only updates the nvidia alternative (which is irrelevant to you if
you have only one driver series installed).

> system still has the following :
> ls -l /etc/alternatives/glx
> lrwxrwxrwx 1 root root 22 Jan  9 19:07 /etc/alternatives/glx -> /usr/lib/mesa-
> diverted
> Neither this command or the package nvidia-legacy-340xx-driver put the driver
> in the correct place.
> 
> Which package or command leads to install/link the nvidia_drv.so in the 
> correct
> place ?

The glx alternative is most likely set to manual mode by some earlier
actions you did, so it won't change if you install a "better" variant.

Use
  update-glx --config glx
to change the glx alternative, ideally set it to "auto".

Andreas

Bug#931644: Buster kernel entropy pool too low on VM boot

[Noah Meyerhans]

On Thu, Jul 11, 2019 at 09:42:17AM -0400, Michael J. Redd wrote:
> > The release notes for buster do mention this issue and provide a
> > link to:
> > 
> > https://wiki.debian.org/BoottimeEntropyStarvation
> > 
> > which has your Haveged solution as one of its suggestions.
> > 
> 
> D'oh! Serves me right for just skimming the release notes, then. After
> doing some in-depth reading, this is a problem for the Linux community
> at large. Wow. While I'm glad the kernel's getting choosier about where
> and how to harvest entropy and can personally live with the ~30 seconds
> added to VM boot times, it could be painful to, for example, bootstrap
> a Linux guest on AWS for the first time and wait for the initial SSH
> keys to be created.
> 
> Will be interesting to see how this evolves over time. In the meantime,
> as this is not actually a kernel defect, I suppose this bug can be
> closed.

I suspect that this bug might end up being mergeable with
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=948519.  In that bug,
I am investigating cherry-picking commit 50ee7529ec45 from the linux
mainline branch for buster.  At least on the arm64 ec2 instances where
I've tested, this change resolves the issue.

If I provide a package for you, would you be able to test it in your
environment to see if the proposed patch addresses the problem there?

Thanks
noah

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=50ee7529ec45

Bug#945055: linux: CPU runs at considerably higher temperatures

[Christoph Anton Mitterer]

Hey.

According to https://gitlab.freedesktop.org/drm/intel/issues/953 the
bug was introduced by:
drm/i915/gen8+: Add RC6 CTX corruption WA 
(d4360736a7c0a6326e3bbdf7d41181f6ed03d9a6)

which, AFAIU, is actually a security fix.


There seem to be some patches, but not sure when they'll be "final" (if
ever)... without opening the security issue again.


Also this would just fix my imminent showstopper of Cinnamon running at
extreme temperatures when being effectively idle.

As my test series shows the following issues likely remain:
- Cinnamon performs noticeably worse with video playback than GNOME
  even under 5.2 (where the offending commit isn't there)
- vaapi performs than xv (which I guess it shouldn't)
- intel_pstate makes the system hotter to.


Thanks,
Chris.

Bug#948539: ITP: ignition-transport8 -- Ignition Transport library v8

[Jose Luis Rivero]

Package: wnpp
Severity: wishlist
Owner: Jose Luis Rivero 

* Package name: ignition-transport8
  Version : 8.0.0
  Upstream Author : Open Source Robotics Foundation
* URL : http://ignitionrobotics.org/libraries/transport
* License : Apache
  Programming Lang: C++
  Description : Transport library which combines ZeroMQ and Protobuf

ignition transport library combines ZeroMQ with Protobufs to create a
fast and efficient message passing system. Asynchronous message
publication and subscription is provided along with service calls and
discovery.

The version 1 is already in Debian. Here is the version 8.

Bug#948538: ldm: privilege escalation

[Salvatore Bonaccorso]

Source: ldm
Version: 2:2.18.06-1
Severity: grave
Tags: security upstream
Justification: user security hole
Forwarded: https://bugs.launchpad.net/ubuntu/+source/ldm/+bug/1839431
Control: found -1 2:2.2.18-2
Control: fixed -1 2:2.2.18-2+deb9u1
Control: fixed -1 2:2.18.06-1+deb10u1

For easier tracking of the issue, as there is no CVE assigned (yet).

https://bugs.launchpad.net/ubuntu/+source/ldm/+bug/1839431 (not yet
public) fixed via
https://git.launchpad.net/~ltsp-upstream/ltsp/+git/ldm/commit/?id=c351ac69ef63ed6c84221cef73e409059661b8ba
.

DSA-4601-1 got released for the issue.

Regards,
Salvatore

Bug#948366: initramfs hook: do not copy SELinux file attributes

[Christian Göttsche]

Instead of adding the option `--no-preserve=context,xattr`, the option
`-Z` is a better way.

Bug#948365: mkinitramfs: do not copy SELinux file attributes

[Christian Göttsche]

Instead of adding the option `--no-preserve=context,xattr`, the option
`-Z` is a better way.

Bug#948537: ITP: ignition-common3 -- Ignition common classes and functions for robot apps (v3)

[Jose Luis Rivero]

Package: wnpp
Severity: wishlist
Owner: Jose Luis Rivero 

* Package name: ignition-common3
  Version : 3.3.0
  Upstream Author : jriv...@osrfoundation.org
* URL : https://bitbucket.org/ignitionrobotics/ign-common
* License : Apache2
  Programming Lang: C++
  Description : Ignition common classes and functions for robot apps (v3)

Ignition Common is a component in the ignition framework, a set of
libraries designed to rapidly develop robot applications.

Future version of Gazebo simulator and ignition transport (already in
debian) will use it as dependency.


Designed to be co-installable with ignition-common, already present
in Debian.

Bug#944565: O: ldm -- LTSP display manager

[Moritz Mühlenhoff]

On Fri, Dec 27, 2019 at 02:58:58PM -0800, Vagrant Cascadian wrote:
> On 2019-11-12, Jonathan Carter wrote:
> > On 2019/11/12 00:29, Vagrant Cascadian wrote:
> >> Newer versions of LTSP no longer make use of LDM; it is no longer
> >> maintained upstream.
> >
> > In my opinion, ltspfs, ldm-themes and ldm won't be of particular use of
> > anyone. Any objections if I file for them to be removed from the archive
> > instead?
> 
> Now that it has been several weeks and nobody has stepped up to take
> over, sure, go ahead and file removal requests! I'd also add
> ltsp-manager/experimental to the list, while you're at it.

I just filed an RM bug for ldm (as I had just released the DSA for it
and better to get it removed than spending another sid upload on it :)

Cheers,
Moritz

Bug#948536: nyancat: diff for NMU version 1.5.2-0.1

[Adrian Vondendriesch]

Package: nyancat
Version: 1.5.1-1+build1
Severity: normal
Tags: patch  pending

Dear maintainer,

I've updated the package and prepared an NMU for nyancat (versioned as
1.5.2-0.1)
The new version includes a new minor upstream version and some packaging
updates.

Regards.
 - Adrian

diff -Nru nyancat-1.5.1/debian/changelog nyancat-1.5.2/debian/changelog
--- nyancat-1.5.1/debian/changelog	2020-01-05 22:54:15.0 +0100
+++ nyancat-1.5.2/debian/changelog	2020-01-09 17:50:15.0 +0100
@@ -1,3 +1,22 @@
+nyancat (1.5.2-0.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * New upstream release.
+  * debian/compat: Switch from debian/compat to versioned debhelper-compat
+B-D.
+  * debian/rules:
++ Remove --with dh_systemd. It's no longer required by newer debhelper
+  versions.
+  * debian/control:
++ Bump Standards-Version to 4.4.1. No changes required.
++ B-Ds: Remove dh-systemd it's oboslet now.
++ B-Ds: Use debhelper-compat = 12 instead.
++ Switch from priority extra to optional.
++ Add Rules-Requires-Root flag.
+  * debian/copyright: Switch to secure Format URL.
+
+ -- Adrian Vondendriesch   Thu, 09 Jan 2020 17:50:15 +0100
+
 nyancat (1.5.1-1+build1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru nyancat-1.5.1/debian/compat nyancat-1.5.2/debian/compat
--- nyancat-1.5.1/debian/compat	2014-07-17 02:49:53.0 +0200
+++ nyancat-1.5.2/debian/compat	1970-01-01 01:00:00.0 +0100
@@ -1 +0,0 @@
-9
diff -Nru nyancat-1.5.1/debian/control nyancat-1.5.2/debian/control
--- nyancat-1.5.1/debian/control	2016-02-13 19:23:41.0 +0100
+++ nyancat-1.5.2/debian/control	2020-01-09 17:50:15.0 +0100
@@ -1,10 +1,11 @@
 Source: nyancat
 Section: misc
-Priority: extra
+Priority: optional
 Maintainer: Jonathan McCrohan 
-Build-Depends: debhelper (>= 9), dh-systemd
-Standards-Version: 3.9.6
+Build-Depends: debhelper-compat (= 12)
+Standards-Version: 4.4.1
 Homepage: https://github.com/klange/nyancat
+Rules-Requires-Root: no
 
 Package: nyancat
 Architecture: any
diff -Nru nyancat-1.5.1/debian/copyright nyancat-1.5.2/debian/copyright
--- nyancat-1.5.1/debian/copyright	2014-07-17 02:49:53.0 +0200
+++ nyancat-1.5.2/debian/copyright	2020-01-09 17:50:15.0 +0100
@@ -1,4 +1,4 @@
-Format: http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
+Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
 Upstream-Name: nyancat
 Source: https://github.com/klange/nyancat
 
diff -Nru nyancat-1.5.1/debian/rules nyancat-1.5.2/debian/rules
--- nyancat-1.5.1/debian/rules	2016-02-13 19:28:12.0 +0100
+++ nyancat-1.5.2/debian/rules	2020-01-09 17:50:15.0 +0100
@@ -10,4 +10,4 @@
 	debian/get-git-source.sh
 
 %:
-	dh $@ --with systemd
+	dh $@
diff -Nru nyancat-1.5.1/Makefile nyancat-1.5.2/Makefile
--- nyancat-1.5.1/Makefile	2015-11-24 06:05:00.0 +0100
+++ nyancat-1.5.2/Makefile	2018-08-18 15:40:20.0 +0200
@@ -1,5 +1,5 @@
 package = nyancat
-version = 1.5.1
+version = 1.5.2
 tarname = $(package)
 distdir = $(tarname)-$(version)
 
diff -Nru nyancat-1.5.1/nyancat.1 nyancat-1.5.2/nyancat.1
--- nyancat-1.5.1/nyancat.1	2015-11-24 06:05:00.0 +0100
+++ nyancat-1.5.2/nyancat.1	2018-08-18 15:40:20.0 +0200
@@ -61,7 +61,7 @@
 .B Repository:
 https://github.com/klange/nyancat
 .SH AUTHOR
-nyancat was written by Kevin Lange.
+nyancat was written by K. Lange .
 .PP
 This manual page was written by Jonathan McCrohan ,
 for the Debian project (and may be used by others).
diff -Nru nyancat-1.5.1/README.md nyancat-1.5.2/README.md
--- nyancat-1.5.1/README.md	2015-11-24 06:05:00.0 +0100
+++ nyancat-1.5.2/README.md	2018-08-18 15:40:20.0 +0200
@@ -8,7 +8,7 @@
 
 Nyancat is available in the following distributions:
 
-- [Arch](http://aur.archlinux.org/packages.php?ID=55279)
+- [Arch](https://www.archlinux.org/packages/?q=nyancat)
 - [Debian](http://packages.qa.debian.org/n/nyancat.html)
 - [Gentoo](http://packages.gentoo.org/package/games-misc/nyancat)
 - [Mandriva](http://sophie.zarb.org/rpms/928724d4aea0efdbdeda1c80cb59a7d3)
@@ -18,6 +18,7 @@
 
 - [FreeBSD](http://www.freshports.org/net/nyancat/)
 - [OpenBSD](http://openports.se/misc/nyancat)
+- [NetBSD](http://pkgsrc.se/misc/nyancat)
 
 ## Setup
 
diff -Nru nyancat-1.5.1/src/nyancat.c nyancat-1.5.2/src/nyancat.c
--- nyancat-1.5.1/src/nyancat.c	2015-11-24 06:05:00.0 +0100
+++ nyancat-1.5.2/src/nyancat.c	2018-08-18 15:40:20.0 +0200
@@ -1,7 +1,7 @@
 /*
- * Copyright (c) 2011-2013 Kevin Lange.  All rights reserved.
+ * Copyright (c) 2011-2018 K. Lange.  All rights reserved.
  *
- * Developed by:Kevin Lange
+ * Developed by:K. Lange
  *  http://github.com/klange/nyancat
  *  http://nyancat.dakko.us
  *
@@ -12,7 +12,7 @@
  * Build tools unified by:  Aaron Peschel
  *  https://github.com/apeschel
  *
- * For a complete 

Bug#948535: RM: ldm -- RoQA; dead upstream, no longer used in LTSP

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

ldm is no longer used in current LTSP releases and dead upstream, see #944565

Cheers,
Moritz

Bug#948533: datalad: FTBFS in unstable

[Steve Langasek]

Source: datalad
Version: 0.11.8-1
Severity: serious
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu focal

Dear maintainers,

The datalad package again fails to build in unstable:

[...]
==
ERROR: datalad.metadata.extractors.tests.test_audio.test_audio
--
Traceback (most recent call last):
  File 
"/tmp/datalad-0.11.8/.pybuild/cpython3_3.8_datalad/build/datalad/metadata/metadata.py",
 line 516, in _get_metadata
extractor_cls = extractors[mtype_key].load()
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 2442, 
in load
self.require(*args, **kwargs)
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 2465, 
in require
items = working_set.resolve(reqs, env, installer, extras=self.extras)
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 786, in 
resolve
raise DistributionNotFound(req, requirers)
pkg_resources.DistributionNotFound: The 'distro' distribution was not found and 
is required by the application

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/nose/case.py", line 197, in runTest
self.test(*self.arg)
  File 
"/tmp/datalad-0.11.8/.pybuild/cpython3_3.8_datalad/build/datalad/tests/utils.py",
 line 615, in newfunc
return t(*(arg + (filename,)), **kw)
  File 
"/tmp/datalad-0.11.8/.pybuild/cpython3_3.8_datalad/build/datalad/metadata/extractors/tests/test_audio.py",
 line 53, in test_audio
res = ds.aggregate_metadata()
  File "/usr/lib/python3/dist-packages/wrapt/wrappers.py", line 602, in __call__
return self._self_wrapper(self.__wrapped__, self._self_instance,
  File 
"/tmp/datalad-0.11.8/.pybuild/cpython3_3.8_datalad/build/datalad/distribution/dataset.py",
 line 527, in apply_func
return f(**kwargs)
  File "/usr/lib/python3/dist-packages/wrapt/wrappers.py", line 563, in __call__
return self._self_wrapper(self.__wrapped__, self._self_instance,
  File 
"/tmp/datalad-0.11.8/.pybuild/cpython3_3.8_datalad/build/datalad/interface/utils.py",
 line 499, in eval_func
return return_func(generator_func)(*args, **kwargs)
  File "/usr/lib/python3/dist-packages/wrapt/wrappers.py", line 563, in __call__
return self._self_wrapper(self.__wrapped__, self._self_instance,
  File 
"/tmp/datalad-0.11.8/.pybuild/cpython3_3.8_datalad/build/datalad/interface/utils.py",
 line 487, in return_func
results = list(results)
  File 
"/tmp/datalad-0.11.8/.pybuild/cpython3_3.8_datalad/build/datalad/interface/utils.py",
 line 431, in generator_func
for r in _process_results(
  File 
"/tmp/datalad-0.11.8/.pybuild/cpython3_3.8_datalad/build/datalad/interface/utils.py",
 line 529, in _process_results
for res in results:
  File 
"/tmp/datalad-0.11.8/.pybuild/cpython3_3.8_datalad/build/datalad/metadata/aggregate.py",
 line 1009, in __call__
errored = _dump_extracted_metadata(
  File 
"/tmp/datalad-0.11.8/.pybuild/cpython3_3.8_datalad/build/datalad/metadata/aggregate.py",
 line 379, in _dump_extracted_metadata
return _extract_metadata(
  File 
"/tmp/datalad-0.11.8/.pybuild/cpython3_3.8_datalad/build/datalad/metadata/aggregate.py",
 line 460, in _extract_metadata
dsmeta, contentmeta, errored = _get_metadata(
  File 
"/tmp/datalad-0.11.8/.pybuild/cpython3_3.8_datalad/build/datalad/metadata/metadata.py",
 line 526, in _get_metadata
raise ValueError(
ValueError: Failed to load metadata extractor for 'datalad_core', broken 
dataset configuration ()?: 
The 'distro' distribution was not found and is required by the application 
[__init__.py:resolve:786]

==

The failures appear to all be related to the introduction of python3.8 as a
supported python version in unstable.

Please find a full build log attached.

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


datalad_0.11.8-1_amd64.build.xz
Description: application/xz


signature.asc
Description: PGP signature

Bug#948534: ITP: ignition-math6 -- A small, fast, and high performance math library (v6)

[Jose Luis Rivero]

Package: wnpp
Severity: wishlist
Owner: Jose Luis Rivero 

* Package name: ignition-math6
  Version : 6.4.0
  Upstream Author : Open Source Robotics Foundation
* URL : http://ignitionrobotics.org/libraries/math
* License : Apache
  Programming Lang: C++
  Description : A small, fast, and high performance math library (v6)

Small, fast, and high performance math library. This library is a
self-contained set of classes and functions suitable for robot
applications.

Designed to be co-installable with ignition-math4, already present
in Debian.

Bug#948532: claws-mail: Please switch to enchant-2

[Laurent Bigonville]

Source: claws-mail
Version: 3.17.4-2
Severity: wishlist
Control: block 947979 by -1

Hi,

Could you please switch from enchant(1) to enchant-2?

Quickly looking at the code it looks it's just a matter of changing the
build-dependency.

Kind regards,

Laurent Bigonville

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

Kernel: Linux 5.4.0-2-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_BE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Permissive - Policy name: refpolicy

Bug#875180: [scribus] Future Qt4 removal from Buster

[Moritz Mühlenhoff]

On Sun, Aug 18, 2019 at 10:19:22PM +0200, Mattia Rizzolo wrote:
> On Mon, Apr 09, 2018 at 08:13:45AM +0200, intrigeri wrote:
> > Lisandro Damián Nicanor Pérez Meyer:
> > > Hi! As you might know we the Qt/KDE team are preparing to remove Qt4
> > 
> > It looks like the upstream 1.5.x development branch is based on Qt5.
> > The 1.5.3 release notes say it's now stable enough to be used for
> > actual workflows.
> 
> FTR of this bug, I've heard voices that 1.5.x might turn into a stable
> 1.6.0 within half a year.  I don't know how actually far we are from
> that, but it might be true :)
> 
> Guess bullseye will stay without a scribus for a few months then…

Has there been further development? qt4 will be removed from testing
today and the plan is to remove the remaining rdeps alonside withit.
But if a 1.6 release is very close, it's also an option to ask FTP
masters to force-remove qt4 despite rendering scribus uninstallable.

Cheers,
Moritz

Bug#948531: licensecheck incorrectly detects LGPL in a GPL COPYING license file

[Aurélien COUDERC]

Package: licensecheck
Version: 3.0.39-1
Severity: normal

Dear Maintainer,

running licensecheck against this [1] upstream repo, the COPYING file is
incorrectly detected as LGPL whereas it’s actually GPL.

$ licensecheck . | \grep "\./COPYING:"
./COPYING: GNU Lesser General Public License


I guess it is because the license preamble mentions:
(Some other Free Software Foundation software is covered by
the GNU Library General Public License instead.)


[1] git://anongit.kde.org/kcalc.git



Happy hacking !
--
Aurélien



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

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

Versions of packages licensecheck depends on:
ii  libgetopt-long-descriptive-perl0.104-1
ii  liblog-any-adapter-screen-perl 0.140-1
ii  liblog-any-perl1.707-1
ii  libmoo-perl2.003006-1
ii  libnamespace-clean-perl0.27-1
ii  libpath-iterator-rule-perl 1.014-1
ii  libpath-tiny-perl  0.108-1
ii  libpod-constants-perl  0.19-1
ii  libre-engine-re2-perl  0.13-4+b1
ii  libregexp-pattern-license-perl 3.1.99-1
ii  libregexp-pattern-perl 0.2.11-1
ii  libscalar-list-utils-perl  1:1.53-1
ii  libsort-key-perl   1.33-2+b2
ii  libstrictures-perl 2.06-1
ii  libstring-copyright-perl   0.003006-1
ii  libstring-escape-perl  2010.002-2
ii  libtry-tiny-perl   0.30-1
ii  perl   5.30.0-9
ii  perl-base [libscalar-list-utils-perl]  5.30.0-9

licensecheck recommends no packages.

Versions of packages licensecheck suggests:
ii  bash-completion  1:2.9-1

-- no debconf information

Bug#662942: New upstream version and new upstream location

[Carsten Leonhardt]

Hi,

the upstream project is now located at:

https://github.com/chaos/powerman

and the latest version is 2.3.25 at the moment.

The next person to upload this package should update the location.

 - Carsten

Bug#948491: centengine crashes regulary

[Pascal Vibet - ADACIS]

@Bernhard : I install 'systemd-coredump' and 'centreon-engine-dbgsym'
packages. I restart centengine. What information do you need? When
centengine process crashes ? Or i run a program in same time ? What do you
want me to do?

Regards

Le jeu. 9 janv. 2020 à 17:12, Bernhard Übelacker  a
écrit :

> Dear Maintainer,
> I just tried to get some more info from the
> dmesg line, which seems to point to:
>file ./src/retention/dump.cc, line 127. [1]
>
>
> @Pascal: More information could maybe retrieved from the journal
> if 'systemd-coredump' could be installed, even better if additionally
> package 'centreon-engine-dbgsym' would be installed [1].
>
>
> Kind regards,
> Bernhard
>
>
> [1]
> https://sources.debian.org/src/centreon-engine/18.10.0-4/src/retention/dump.cc/#L127
> [2]
> https://wiki.debian.org/HowToGetABacktrace#Installing_the_debugging_symbols
>

Bug#946213: RFS: git-delta/0.0.15 -- Syntax-highlighting pager for git and diff output

[Dan Davison]

Hi Adam, thanks! I definitely still want to get it into Debian, I just need
to decide what to do about the name clash, whether I'm prepared to rename
the project etc.

Alas, git-delta is written in some heathen language
> I don't know how to deal with (Rust's own package manager pollutes quite a
> bit of the system), thus it would be nice to have it properly packaged so
> doofuses like me can use it.
>

By the way, there's no reason to wait for it to be in Debian before using
it. Rust produces statically linked executables by default; executables for
the latest release are available at
https://github.com/dandavison/delta/releases.


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

Bug#948530: RFS: coinor-vol/1.5.4-1 [QA] -- Coin-or linear programming solver

[Sudip Mukherjee]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "coinor-vol"

 * Package name: coinor-vol
   Version : 1.5.4-1
   Upstream Author : Francisco Barahona, Laszlo Ladanyi.
 * URL : https://projects.coin-or.org/Vol
 * License : EPL-1
 * Vcs : https://salsa.debian.org/debian/coinor-vol
   Section : science

It builds those binary packages:

  coinor-libvol1 - Coin-or linear programming solver
  coinor-libvol-dev - Coin-or linear programming solver
  coinor-libvol-doc - Coin-or linear programming solver

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

  https://mentors.debian.net/package/coinor-vol

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

  dget -x 
https://mentors.debian.net/debian/pool/main/c/coinor-vol/coinor-vol_1.5.4-1.dsc

Changes since the last upload:

   * QA upload.
   * Update to upstream v1.5.4
   * Update d/copyright.
   * Rename package based on SONAME major version.
   * Remove dbg package in favor of dbgsym.
   * Mark QA as maintainer.
   * Update Standards-Version to 4.4.1
   * Update compat level to 12
   * Remove build dependency on cdbs.
   * Simplify d/rules and rework on d/*.
   * Update Vcs to salsa.
   * Mark source format as 3.0
   * Add Rules-Requires-Root: no

Note: The package name was changed, so might need to go via new queue.

-- 
Regards
Sudip

Bug#948529: looking-glass ftbfs with binutils 2.33.50

[Matthias Klose]

Package: src:looking-glass
Version: 0+b1-1
Severity: serious
Tags: sid bullseye

Please fix that, plus link with the static library and add a Built-Using: tag.


[...]
/<>/looking-glass-0+b1/common/src/crash.linux.c: In function
‘lookup_address’:
/<>/looking-glass-0+b1/common/src/crash.linux.c:101:8: error: implicit
declaration of function ‘bfd_get_section_flags’; did you mean
‘bfd_set_section_flags’? [-Werror=implicit-function-declaration]
  101 |   if ((bfd_get_section_flags(crash.fd, crash.section) & SEC_ALLOC) == 0)
  |^
  |bfd_set_section_flags
compilation terminated due to -Wfatal-errors.
cc1: all warnings being treated as errors
make[3]: *** [common/CMakeFiles/lg_common.dir/build.make:105:
common/CMakeFiles/lg_common.dir/src/crash.linux.c.o] Error 1
make[3]: *** Waiting for unfinished jobs

Bug#806947: coreutils: improve expr with huge numbers by GMP

[Валерий Заподовников]

Really, guys? You understand that even git for windows
https://git-scm.com/download/win comes with GMP activated by default in
windows compiled coreutils (C:\Program Files\Git\usr\bin)? And you still
DID NOT ACTIVATE IT? Wow.

Bug#948528: Package is 5 years out of date

[Melik Yuksel]

Package: unison
Version: 2.48.4-1+b1

The unison package on the repository should be updated to the latest version, 
which as of January 2020 is 2.51.2. Clients using version above 2.48 are not 
backwards compatible with 2.48, so this is absolutely necessary.

Bug#948527: gtkboard: Always hang up after selecting a game.

[nozzy123nozzy]

Package: gtkboard
Version: 0.11pre0+cvs.2003.11.02-9+b1
Severity: grave
Tags: patch

Dear Maintainer,

 The gtkboard always hangs up after selecting a game in Game menu.
It causes gtkboard completely useless.
 And when it hangs up,the following message is shown in stdin, 
  ' *** stack smashing detected ***:  terminated '

 I report this problem, and I attach the patch to fix this problem.
 In my Debian box, this patch works well.

 Would you release a newer package applied to this patch?

FYI:
  The root cause of this problem is the buffer overflow in
channel_process_input() in src/engine.c. The channel_process_input()
invokes g_io_channel_read; however, the type of the last argument of
g_io_channel should be 'gsize(unsigned long)',but it is 'int'. 

  It causes an overflow in the stack, and 'stack smashing' kills the
forked process. Then the parent process, which handles GUI, keeps
waiting for the response of the killed process forever, and it looks
hanging up.

 Additionally, I happen to find a possibility of 1 bytes of buffer
overflow. The linbuf in channel_process_input() has 4096bytes, but
there is a possibility that '\0' puts in 4097th. This patch fixes it
also.

 Finally, this problem comes from upstream. However, the site of
upstream says maintenance is over. So, I haven't reported upstream.
See. http://gtkboard.sourceforge.net/

Regards,
--
 Takahide Nojima

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

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

Versions of packages gtkboard depends on:
ii  libatk1.0-0  2.34.1-1
ii  libc62.29-8
ii  libcairo21.16.0-4
ii  libfontconfig1   2.13.1-2+b1
ii  libfreetype6 2.10.1-2
ii  libgdk-pixbuf2.0-0   2.40.0+dfsg-2
ii  libglib2.0-0 2.62.4-1
ii  libgtk2.0-0  2.24.32-4
ii  libpango-1.0-0   1.42.4-8
ii  libpangocairo-1.0-0  1.42.4-8
ii  libpangoft2-1.0-01.42.4-8
ii  libsdl-mixer1.2  1.2.12-16+b1
ii  libsdl1.2debian  1.2.15+dfsg2-5

gtkboard recommends no packages.

gtkboard suggests no packages.

-- no debconf information
diff -u -N -r a/debian/changelog b/debian/changelog
--- a/debian/changelog	2018-07-29 19:02:29.0 +0900
+++ b/debian/changelog	2020-01-10 04:19:52.749057611 +0900
@@ -1,3 +1,13 @@
+gtkboard (0.11pre0+cvs.2003.11.02-10) UNRELEASED; urgency=medium
+
+  * Fix stack overflow in engine.c.
+It has 2 overflows.
+  -The 'linebuf' have 4096 bytes,but '\0' puts in 4097th.
+  -The last argument of g_io_channel_read should be 
+   'unsigned long' not 'int'.
+
+ -- Takahide Nojima   Mon, 06 Jan 2020 02:01:42 +0900
+
 gtkboard (0.11pre0+cvs.2003.11.02-9) unstable; urgency=medium
 
   * recent list crash bug fix, thanks to Nelson Benítez León (closes: #820595)
diff -u -N -r a/debian/patches/fixed-stack-smash.patch b/debian/patches/fixed-stack-smash.patch
--- a/debian/patches/fixed-stack-smash.patch	1970-01-01 09:00:00.0 +0900
+++ b/debian/patches/fixed-stack-smash.patch	2020-01-10 03:09:20.792565886 +0900
@@ -0,0 +1,15 @@
+--- a/src/engine.c
 b/src/engine.c
+@@ -345,10 +345,10 @@
+ 
+ static gboolean channel_process_input ()
+ {
+-	static char linebuf[4096];
++	static char linebuf[4096+1];
+ 	char *linep = linebuf;
+ 	char *line;
+-	int bytes_read;
++	gsize bytes_read;
+ #if GLIB_MAJOR_VERSION > 1
+ 	// we need to call this again because we will get new events before returning
+ 	// from this function
diff -u -N -r a/debian/patches/series b/debian/patches/series
--- a/debian/patches/series	2018-07-29 19:02:29.0 +0900
+++ b/debian/patches/series	2020-01-06 02:07:43.243615139 +0900
@@ -1 +1,2 @@
 debian-changes
+fixed-stack-smash.patch

Bug#948526: ITP: genomethreader -- software tool to compute gene structure predictions

[Sascha Steinbiss]

Package: wnpp
Severity: wishlist
Owner: Sascha Steinbiss 

* Package name: genomethreader
  Version : 1.7.3
  Upstream Author : Gordon Gremme
* URL : http://genomethreader.org
* License : ISC
  Programming Lang: C
  Description : software tool to compute gene structure predictions

GenomeThreader is a software tool to compute gene structure predictions.
The gene structure predictions are calculated using a similarity-based
approach where additional cDNA/EST and/or protein sequences are used to
predict gene structures via spliced alignments. GenomeThreader was motivated
by disabling limitations in GeneSeqer, a popular gene prediction program
which is widely used for plant genome annotation.

The software has recently been liberated after being closed-source for a
while.

Bug#948460: xserver-xorg-video-nvidia-legacy-340xx: Xorg won't start with xserver-xorg-video-nvidia-legacy-340xx on testing/Bullseye

[Alexis]

Package: xserver-xorg-video-nvidia-legacy-340xx
Followup-For: Bug #948460

Hello,

no I didn't install nvidia-legacy-340xx-driver.
So I did that tonight :
root@akatendai:~# dpkg --no-pager -l 'nvidia*' 'xserver*nvidia*'
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ NameVersion  Architecture
Description
+++-===---=
un  nvidia-alternative(no
description available)
un  nvidia-alternative-legacy-173xx   (no
description available)
un  nvidia-alternative-legacy-71xx(no
description available)
un  nvidia-alternative-legacy-96xx(no
description available)
un  nvidia-cuda-mps   (no
description available)
un  nvidia-current(no
description available)
un  nvidia-current-updates(no
description available)
ii  nvidia-detect   430.64-4 amd64
NVIDIA GPU detection utility
un  nvidia-driver (no
description available)
un  nvidia-driver-bin-340.108 (no
description available)
un  nvidia-driver-binary  (no
description available)
un  nvidia-glx-any(no
description available)
ii  nvidia-installer-cleanup20151021+11  amd64
cleanup after driver installation with the nvidia-installer
ii  nvidia-kernel-common20151021+11  amd64
NVIDIA binary kernel module support files
un  nvidia-kernel-support-any (no
description available)
un  nvidia-legacy-304xx-alternative   (no
description available)
un  nvidia-legacy-304xx-driver(no
description available)
ii  nvidia-legacy-340xx-alternative 340.108-2amd64
allows the selection of NVIDIA as GLX provider (340xx legacy version)
un  nvidia-legacy-340xx-alternative--kmod-alias   (no
description available)
ii  nvidia-legacy-340xx-driver  340.108-2amd64
NVIDIA metapackage (340xx legacy version)
ii  nvidia-legacy-340xx-driver-bin  340.108-2amd64
NVIDIA driver support binaries (340xx legacy version)
ii  nvidia-legacy-340xx-driver-libs:amd64   340.108-2amd64
NVIDIA metapackage (OpenGL/GLX/EGL/GLES libraries) (340xx legacy version)
un  nvidia-legacy-340xx-driver-libs-i386  (no
description available)
un  nvidia-legacy-340xx-kernel-340.108(no
description available)
ii  nvidia-legacy-340xx-kernel-dkms 340.108-2amd64
NVIDIA binary kernel module DKMS source (340xx legacy version)
un  nvidia-legacy-340xx-kernel-source (no
description available)
hi  nvidia-legacy-340xx-kernel-support  340.108-2amd64
NVIDIA binary kernel module support files (340xx legacy version)
un  nvidia-legacy-340xx-kernel-support--v1(no
description available)
hi  nvidia-legacy-340xx-smi 340.108-2amd64
NVIDIA System Management Interface (340xx legacy version)
ii  nvidia-legacy-340xx-vdpau-driver:amd64  340.108-2amd64Video
Decode and Presentation API for Unix - NVIDIA driver (340xx legacy)
un  nvidia-libopencl1-dev (no
description available)
ii  nvidia-modprobe 430.50-1 amd64
utility to load NVIDIA kernel modules and create device nodes
rc  nvidia-persistenced 430.64-1 amd64
daemon to maintain persistent software state in the NVIDIA driver
ii  nvidia-settings-legacy-340xx340.107-2amd64tool
for configuring the NVIDIA graphics driver (340xx legacy version)
ii  nvidia-support  20151021+11  amd64
NVIDIA binary graphics driver support files
un  xserver-xorg-video-nvidia-any (no
description available)
ii  xserver-xorg-video-nvidia-legacy-340xx  340.108-2amd64
NVIDIA binary Xorg driver (340xx legacy version)

I moved the nvidia_drv.so and I ran 'update-glx --config nvidia'. But the
system still has the following :
ls -l /etc/alternatives/glx
lrwxrwxrwx 1 root root 22 Jan  9 19:07 /etc/alternatives/glx -> /usr/lib/mesa-
diverted
Neither this command or the package nvidia-legacy-340xx-driver put the driver
in the correct place.

Which package or command leads to install/link the nvidia_drv.so in the correct
place ?



-- Package-specific info:
uname -a:
Linux akatendai 5.3.0-3-amd64 #1 

Bug#948525: ITP: mopidy-gmusic -- Mopidy extension for playing music from Google Play Music

[Stein Magnus Jodal]

Package: wnpp
Severity: wishlist
Owner: Stein Magnus Jodal 

* Package name: mopidy-gmusic
  Version : 4.0.0
  Upstream Author : Ronald Hecht 
* URL : https://github.com/mopidy/mopidy-gmusic
* License : Apache-2.0
  Programming Lang: Python
  Description : Mopidy extension for playing music from Google Play Music

Mopidy plays music from local disk, Spotify, SoundCloud, Google Play Music,
and more. You can edit the playlist from any phone, tablet, or computer using
a variety of MPD and web clients.

This package provides a Mopidy extension for playing music from Google Play
Music, either music you've uploaded to the library, or music available through
a paid subscription.


The package will be maintained in the mopidy-team group on Salsa.


signature.asc
Description: PGP signature

Bug#948509: perl man page says to install perldoc, not perl-doc

[gregor herrmann]

Control: tag -1 + moreinfo

On Thu, 09 Jan 2020 11:06:54 -0500, anna wrote:

> The perl documentation package in "man perl" is wrong. The package name is 
> perl-doc, not perldoc.

Thanks for your bug report.

Could you please tell us which part of / sentence in the manpage you
consider to be wrong?

A quick search comes up with

On Debian systems, you need to install the perl-doc package which
contains the majority of the standard Perl documentation and the
perldoc program.

which seems correct and matches your expectations. Besides that, the
perldoc program is mentioned several times.


Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   NP: U2: Numb


signature.asc
Description: Digital Signature

Bug#948463: libai-fann-perl: Integer overflow leading to heap buffer overflow

[gregor herrmann]

On Wed, 08 Jan 2020 15:19:47 -0700, Jayakrishna Vadayath wrote:

> As a part of an academic project, we have discovered an integer overflow
> which can lead to a heap buffer overflow in the libai-fann-package.

Thanks for your bug report and your work.

As this is not a bug in the packaging, I've forwarded your bug report
to the upstream issue tracker:

https://rt.cpan.org/Ticket/Display.html?id=131404

For the future: If you find more of those cases, please try to submit
them directly to the upstream authors of the CPAN distributions.


Cheers,
gregor
 
-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   NP: A Glezele Wayn


signature.asc
Description: Digital Signature

Bug#948524: qrq FTCBFS: strips with the build architecture strip

[Helmut Grohne]

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

qrq fails to cross build from source, because it strips with the build
architecture strip during make install via the -s flag of the install
tool. Doing so also breaks DEB_BUILD_OPTIONS=nostrip and generation of
-dbgsym packages. It is best to defer stripping to dh_strip. Please
consider applying the attached patch.

Helmut
diff --minimal -Nru qrq-0.3.3/debian/changelog qrq-0.3.3/debian/changelog
--- qrq-0.3.3/debian/changelog  2019-06-30 21:15:45.0 +0200
+++ qrq-0.3.3/debian/changelog  2020-01-09 19:52:01.0 +0100
@@ -1,3 +1,10 @@
+qrq (0.3.3-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Defer stripping to dh_strip. (Closes: #-1)
+
+ -- Helmut Grohne   Thu, 09 Jan 2020 19:52:01 +0100
+
 qrq (0.3.3-1) unstable; urgency=medium
 
   * New upstream version.
diff --minimal -Nru qrq-0.3.3/debian/patches/cross.patch 
qrq-0.3.3/debian/patches/cross.patch
--- qrq-0.3.3/debian/patches/cross.patch1970-01-01 01:00:00.0 
+0100
+++ qrq-0.3.3/debian/patches/cross.patch2020-01-09 19:51:14.0 
+0100
@@ -0,0 +1,104 @@
+--- qrq-0.3.3.orig/Makefile
 qrq-0.3.3/Makefile
+@@ -31,6 +31,8 @@
+   CC=gcc
+ endif
+ 
++INSTALL ?= install
++
+ # build information may be added by CI scripts and will be
+ # displayed in the help text (qrq -h)
+ 
+@@ -83,20 +85,20 @@
+ ifeq ($(OSX_BUNDLE), YES)
+ 
+ install: qrq
+-  install -d -v   
qrq.app/Contents
+-  install -d -v   
qrq.app/Contents/MacOS
+-  install -d -v   
qrq.app/Contents/Resources
+-  install -d -v   
qrq.app/Contents/Resources/share/qrq/
+-  install -d -v   
qrq.app/Contents/Resources/share/man/man1/
+-  install-m 0755 qrq  
qrq.app/Contents/MacOS/
+-  install-m 0755 qrqscore 
qrq.app/Contents/MacOS/
+-  install-m 0644 qrq.1
qrq.app/Contents/Resources/share/man/man1/
+-  install-m 0644 callbase.qcb 
qrq.app/Contents/Resources/share/qrq/
+-  install-m 0644 english.qcb  
qrq.app/Contents/Resources/share/qrq/
+-  install-m 0644 qrqrc
qrq.app/Contents/Resources/share/qrq/
+-  install-m 0644 toplist  
qrq.app/Contents/Resources/share/qrq/
+-  install-m 0644 OSXExtras/qrq.icns   qrq.app/Contents/Resources/
+-  install-m 0755 OSXExtras/qrqsh  qrq.app/Contents/MacOS/
++  ${INSTALL} -d -v
qrq.app/Contents
++  ${INSTALL} -d -v
qrq.app/Contents/MacOS
++  ${INSTALL} -d -v
qrq.app/Contents/Resources
++  ${INSTALL} -d -v
qrq.app/Contents/Resources/share/qrq/
++  ${INSTALL} -d -v
qrq.app/Contents/Resources/share/man/man1/
++  ${INSTALL}-m 0755 qrq   
qrq.app/Contents/MacOS/
++  ${INSTALL}-m 0755 qrqscore  
qrq.app/Contents/MacOS/
++  ${INSTALL}-m 0644 qrq.1 
qrq.app/Contents/Resources/share/man/man1/
++  ${INSTALL}-m 0644 callbase.qcb  
qrq.app/Contents/Resources/share/qrq/
++  ${INSTALL}-m 0644 english.qcb   
qrq.app/Contents/Resources/share/qrq/
++  ${INSTALL}-m 0644 qrqrc 
qrq.app/Contents/Resources/share/qrq/
++  ${INSTALL}-m 0644 toplist   
qrq.app/Contents/Resources/share/qrq/
++  ${INSTALL}-m 0644 OSXExtras/qrq.icns
qrq.app/Contents/Resources/
++  ${INSTALL}-m 0755 OSXExtras/qrqsh   qrq.app/Contents/MacOS/
+   sed 's/VERSION/$(VERSION)/' OSXExtras/Info.plist > 
qrq.app/Contents/Info.plist
+ 
+ uninstall:
+@@ -105,16 +107,16 @@
+ else
+ 
+ install: qrq
+-  install -d -v  $(DESTDIR)/share/qrq/
+-  install -d -v  $(DESTDIR)/share/man/man1/
+-  install -d -v  $(DESTDIR)/bin/
+-  install -s -m 0755 qrq $(DESTDIR)/bin/
+-  install-m 0755 qrqscore$(DESTDIR)/bin/
+-  install-m 0644 qrq.1   $(DESTDIR)/share/man/man1/
+-  install-m 0644 callbase.qcb$(DESTDIR)/share/qrq/
+-  install-m 0644 english.qcb $(DESTDIR)/share/qrq/
+-  install-m 0644 qrqrc   

Bug#948523: nss FTCBFS for ppc64el: wrong OS_TYPE

[Helmut Grohne]

Source: nss
Version: 2:3.48-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

nss fails to cross build from source for ppc64el, because it passes a
wrong OS_TYPE. Thus detection of whether to build hw crypto disagrees on
the Makefile level with the C preprocessor level, which results in a
linker error missing symbols. Please consider applying the attached
patch.

Helmut
diff --minimal -Nru nss-3.48/debian/changelog nss-3.48/debian/changelog
--- nss-3.48/debian/changelog   2019-12-28 23:40:46.0 +0100
+++ nss-3.48/debian/changelog   2020-01-09 06:27:50.0 +0100
@@ -1,3 +1,10 @@
+nss (2:3.48-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS for ppc64el: Pass correct OS_TYPE. (Closes: #-1)
+
+ -- Helmut Grohne   Thu, 09 Jan 2020 06:27:50 +0100
+
 nss (2:3.48-1) unstable; urgency=medium
 
   * New upstream release. Closes: #947131.
diff --minimal -Nru nss-3.48/debian/rules nss-3.48/debian/rules
--- nss-3.48/debian/rules   2019-06-04 23:39:35.0 +0200
+++ nss-3.48/debian/rules   2020-01-09 06:27:50.0 +0100
@@ -40,7 +40,8 @@
 ifeq ($(origin RANLIB),default)
 TOOLCHAIN += RANLIB=$(DEB_HOST_GNU_TYPE)-ranlib
 endif
-TOOLCHAIN += OS_TEST=$(DEB_HOST_GNU_CPU)
+OS_TYPE_map_powerpc64le = ppc64le
+TOOLCHAIN += OS_TEST=$(or 
$(OS_TYPE_map_$(DEB_HOST_GNU_CPU)),$(DEB_HOST_GNU_CPU))
 TOOLCHAIN += KERNEL=$(DEB_HOST_ARCH_OS)
 endif
 

Bug#945472: python-datrie: FTBFS with recent hypothesis version

[Andreas Tille]

On Thu, Jan 09, 2020 at 07:45:09PM +0100, Michael Crusoe wrote:
> https://patches.ubuntu.com/p/python-datrie/python-datrie_0.7.1-3ubuntu1.patch
> 
> I can confirm that this patch fixes the build and I've opened a merge
> request at
> https://salsa.debian.org/python-team/modules/python-datrie/merge_requests/1
> 
> Can someone with more permissions than I have accept that merge request and
> upload the new package?

Uploaded.  Thanks for the merge request (which was accepted by Steffen)

   Andreas.

-- 
http://fam-tille.de

Bug#948522: If I rebuild src:file with libseccomp-dev installed, then "fakeroot file ..." crashes with "Bad system call"

[Daniel Schepler]

Source: file
Version: 1:5.38-3
Severity: normal

As the subject says: in my environment with libseccomp-dev installed,
the resulting file package gets a dependency on libseccomp2.  And if I
install that, then I subsequently get strange errors while trying to
build src:binutils, which I eventually tracked down to:

$ fakeroot file /usr/bin/file
Bad system call
$

"fakeroot strace file /usr/bin/file" shows:

...
futex(0x7ff6fb5b06f4, FUTEX_WAKE_PRIVATE, 2147483647) = 0
prctl(PR_SET_NO_NEW_PRIVS, 1, 0, 0, 0)  = 0
prctl(PR_SET_DUMPABLE, SUID_DUMP_DISABLE) = 0
prctl(PR_SET_NO_NEW_PRIVS, 1, 0, 0, 0)  = 0
seccomp(SECCOMP_SET_MODE_STRICT, 1, NULL) = -1 EINVAL (Invalid argument)
seccomp(SECCOMP_SET_MODE_FILTER, 0, 0x55c39592c300) = 0
futex(0x7ff6fb3f40c8, FUTEX_WAKE_PRIVATE, 2147483647) = 0
stat(0x55c39592d910, 0x7ffe668c02f0)= -1 ENOENT (No such file or directory)
stat(0x55c39592d910, 0x7ffe668c02f0)= -1 ENOENT (No such file or directory)
openat(AT_FDCWD, 0x55c39592d910, O_RDONLY) = -1 ENOENT (No such file
or directory)
stat(0x55c39592fb70, 0x7ffe668c02e0)= 0
msgget(0x41c5ccd5, IPC_CREAT|0600)  = ?
+++ killed by SIGSYS +++
Bad system call (core dumped)

(It might also be relevant here that I am running the Debian
environment within a systemd-nspawn container which already applies
its own seccomp filters, and also that I am running on a locally built
kernel not an official Debian kernel - and also the host system is a
custom built system so my systemd-nspawn does not have Debian
patches.)

I would guess the easiest way to resolve this would be to add an
explicit "--disable-libseccomp" to the dh_auto_configure command.
(Which I would certainly prefer to having the source package
Build-Conflicts: libseccomp-dev.)
-- 
Daniel Schepler

Bug#930846: New development of how to build the installation-guide for the website [ Re: Bug#930846: partman-auto-lvm: debconf show guided_size during auto install ]

[Holger Wansing]

Hi,

Am Donnerstag, 9. Januar 2020 schrieb Adam D. Barratt:
> On Thu, 2020-01-09 at 14:24 +0100, Laura Arjona Reina wrote:
> > So, please count my ACK to apply the patch adding fonts-nanum and
> > fonts-nanum-coding.
> 
> Thanks:
> 
> The following NEW packages will be installed:
>   fonts-nanum fonts-nanum-coding
> The following packages will be upgraded:
>   debian.org-www-master.debian.org
> 1 upgraded, 2 newly installed, 0 to remove and 0 not upgraded.
> Need to get 10.1 MB of archives.
> After this operation, 30.0 MB of additional disk space will be used.
> ...
> Setting up fonts-nanum (20140930-1) ...
> Setting up fonts-nanum-coding (2.0-10) ...
> Processing triggers for fontconfig (2.11.0-6.7+b1) ...
> Setting up debian.org-www-master.debian.org (68~20200109T190309.1) ...

Looks fine. Thanks!

To make a new build happen, manual intervention is
needed now ( because there is no new source package
version available for installation-guide since the last build, no new build is 
trigered).
One need to go to
/srv/www.debian.org/cron/log/ig-stable-built.txt
and change that file (for example just change into an
empty file).
This is documented in the 1installation-guide script in
lessoften (cron git-repo).
That will trigger a new build at the next day.

Thanks
Holger

-- 
Sent from my Jolla phone
http://www.jolla.com/

Bug#896516: closed by gustavo panizzo (new maintainer for rss2email)

[martin f krafft]

reopen 896516

This improvement suggestion still applies.

Thanks for taking over the package!!

--
 .''`.   martin f. krafft  @martinkrafft
: :'  :  proud Debian developer
`. `'`   http://people.debian.org/~madduck
  `-  Debian - when you have better things to do than fixing systems


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Bug#947220: lvm2: System unbootable with cached root and latest kernel

[Bastian Blank]

Control: reassign -1  thin-provisioning-tools
Control: forcemerge 931514 -1

Moin

On Mon, Dec 23, 2019 at 03:05:15AM +, Stefanos Harhalakis wrote:
> Justification: breaks the whole system

No, it does not.

However, this is fixed in thin-provisioning-tools.

Bastian

-- 
Peace was the way.
-- Kirk, "The City on the Edge of Forever", stardate unknown

Bug#455977: closed by gustavo panizzo (new maintainer for rss2email)

[martin f krafft]

reopen 455977
thanks

This feature request still applies.

Thanks for taking over the package!!

--
 .''`.   martin f. krafft  @martinkrafft
: :'  :  proud Debian developer
`. `'`   http://people.debian.org/~madduck
  `-  Debian - when you have better things to do than fixing systems


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Bug#948521: RFA: i8kutils -- Fan control for Dell laptops

[Vitor Augusto]

Package: wnpp
Severity: normal

Bug#948520: buster lacks package ecryptfs-utils

[Hadmut Danisch]

Package: security.debian.org

Hi,

I just tried to read encrypted files (ecryptfs) from a fileserver
(written with ubuntu) on a debian buster machine, but I can't, because
the ecryptfs-utils are missing in buster.

As far as I found by googleing, the reason for dropping it was

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765854

i.e. private directories not unmounted when logging out.


If that is true, it was a rather shortsighted decision, because it
breakes particular functions, i.e. add passwords to the keyring or
mounting directories as a normal user.


Even if root can mount ecryptfs-filesystems directly, it's not available
to regular users, and giving it through tools like sudo open the door
too wide.

This is odd since there's no good substitute

  * encfs is unsecure
  * gocryptfs has some problems and runs in user space, see here
https://defuse.ca/audits/gocryptfs.htm
  * cryfs is just based on a master thesis, and to the best of my
knowledge, not audited.

On the other hand, ecryptfs keeps keys and encryption within kernel
space, thus providing better security than a user space daemon.



regards

Hadmut

Bug#948512: libsdl2: FTBFS on armhf

[Timo Aaltonen]

On 9.1.2020 18.18, Timo Aaltonen wrote:
> Source: libsdl2
> Severity: normal
> 
> Hi,
> 
> libsdl2 fails to build on armhf:
> 
>   CC build/SDL_video.lo
> In file included from include/SDL_opengles.h:33,
>  from 
> /home/tjaalton/libsdl2-2.0.10+dfsg1/src/video/SDL_video.c:41:
> /usr/include/GLES/gl.h:63:25: error: conflicting types for 'GLsizeiptr'
>63 | typedef khronos_ssize_t GLsizeiptr;
>   | ^~
> In file included from include/SDL_opengl.h:2105,
>  from 
> /home/tjaalton/libsdl2-2.0.10+dfsg1/src/video/SDL_video.c:37:
> include/SDL_opengl_glext.h:472:19: note: previous declaration of 'GLsizeiptr' 
> was here
>   472 | typedef ptrdiff_t GLsizeiptr;
>   |   ^~
> In file included from include/SDL_opengles.h:33,
>  from 
> /home/tjaalton/libsdl2-2.0.10+dfsg1/src/video/SDL_video.c:41:
> /usr/include/GLES/gl.h:64:26: error: conflicting types for 'GLintptr'
>64 | typedef khronos_intptr_t GLintptr;
>   |  ^~~~
> In file included from include/SDL_opengl.h:2105,
>  from 
> /home/tjaalton/libsdl2-2.0.10+dfsg1/src/video/SDL_video.c:37:
> include/SDL_opengl_glext.h:473:19: note: previous declaration of 'GLintptr' 
> was here
>   473 | typedef ptrdiff_t GLintptr;
> 
> this is because the mesa/libglvnd header files got updated and libsdl needs 
> to sync it's own copy.

nope, that's not why.. GLES1 headers are shipped now, and it tries to
build with GLES1 support enabled and then this happens. So add
--disable-video-opengles1 to configure flags to get it built again.


-- 
t

Bug#948519: insufficient boot-time entropy on arm64 virtual machines

[Noah Meyerhans]

Package: src:linux
Version: 4.19.67-2+deb10u2
Severity: important 

See the thread at
https://lists.debian.org/debian-cloud/2020/01/threads.html#00013 for
some context.

When launching arm64 VMs on Amazon EC2, a lack of entropy at boot
results in the full boot process taking several minutes, when the
expectation is that it take a small number of seconds (<10).

Analysis of the boot process shows the ssh key generation is the
culprit, taking nearly 3 minutes.

admin@ip-10-0-1-87:~$ cloud-init analyze blame
-- Boot Record 01 --
 165.77300s (init-network/config-ssh)

The 5.4 kernel currently in sid does not experience this lack of
entropy.  It has been suggested that upstream commit 50ee7529ec45
("random: try to actively add entropy rather than passively wait for
it") may be the difference here, but I have not confirmed this.

A suggested workaround has been to install haveged in the image, but
this tends to make crypto people frown.

Bug#948287: bash: *** stack smashing detected *** ( SIGABRT crash )

[Bernhard Übelacker]

Am 09.01.20 um 17:56 schrieb crvi c:
> I am using the same bash / gnome-terminal as part of my daily work. The
> crash was random and it is not consistently reproducible. I have a
> couple of bash core files, if that would be of any help.

Ok, I see - had hoped it to be better reproducible.

In my tests I found that the function in question get executed
if I do for example "ls /" and tab.

Could be the crashing cases are related to absolute paths?


Otherwise you could try to run it by valgrind e.g. like following:
  valgrind --tool=memcheck--trace-children=no --child-silent-after-fork=yes 
bash
  valgrind --tool=exp-sgcheck --trace-children=no --child-silent-after-fork=yes 
bash


Another approach could be, if CPU support is given, to use
a timetravel debugger like rr to record bash executions and
replay a crashing one to find out where the stack canary got
overwritten.


Unfortunately a core did alreay run over the interesting instruction
changing that stack canary, will therefore not of so much use.
Maybe just if the stack would be overwritten with some recognizable
values ...

Kind regards,
Bernhard

Bug#930846: New development of how to build the installation-guide for the website [ Re: Bug#930846: partman-auto-lvm: debconf show guided_size during auto install ]

[Adam D. Barratt]

On Thu, 2020-01-09 at 14:24 +0100, Laura Arjona Reina wrote:
> So, please count my ACK to apply the patch adding fonts-nanum and
> fonts-nanum-coding.

Thanks:

The following NEW packages will be installed:
  fonts-nanum fonts-nanum-coding
The following packages will be upgraded:
  debian.org-www-master.debian.org
1 upgraded, 2 newly installed, 0 to remove and 0 not upgraded.
Need to get 10.1 MB of archives.
After this operation, 30.0 MB of additional disk space will be used.
...
Setting up fonts-nanum (20140930-1) ...
Setting up fonts-nanum-coding (2.0-10) ...
Processing triggers for fontconfig (2.11.0-6.7+b1) ...
Setting up debian.org-www-master.debian.org (68~20200109T190309.1) ...

Regards,

Adam

Bug#947936: chrony: Does (still) not start properly on boot on buster

[wferi]

Hi,

Don't you think #873057 is actually the same issue discovered with ntp?
Please consider merging it in if you agree.
-- 
Thanks,
Feri

Bug#945472: python-datrie: FTBFS with recent hypothesis version

[Michael Crusoe]

[whoops, forgot to CC everyone]

On Mon, 9 Dec 2019 12:14:02 +0100 Matthias Klose  wrote:
> On 09.12.19 11:46, Andreas Tille wrote:
> > Hi,
> >
> > I have upgraded python-datrie in Git[1] to latest upstream version
> > (0.8).  It shows the same issue - so I admit I have no better clue than
> > reporting the issue upstream which I'd rather leave to the official
> > Uploader of the package.
> >
> > BTW, we probably should expect build issues with Python 3.8[2]
>
>
https://patches.ubuntu.com/p/python-datrie/python-datrie_0.7.1-3ubuntu1.patch

I can confirm that this patch fixes the build and I've opened a merge
request at
https://salsa.debian.org/python-team/modules/python-datrie/merge_requests/1

Can someone with more permissions than I have accept that merge request and
upload the new package?

Thanks and happy new year!

Bug#948518: RM: grabix [s390x] -- ROM; upstream htslib broke s390x and is holding up several transitions

[Michael R. Crusoe]

Package: ftp.debian.org
Severity: important

A follow on to https://bugs.debian.org/948092 as I forgot to include
grabix in the list; this appears to be holding up the transition to
testing if I'm reading https://release.debian.org/britney/update_output.txt 
correctly.

Thanks!

Bug#947004: S4Vectors Segmentation fault after r-base-core update (Was: Bug#947004: Tests segfaults (since the r-base-core update?))

[Pages, Herve]

Hi,

None of our build machines is able to reproduce this sorry:

   https://bioconductor.org/checkResults/3.10/bioc-LATEST/S4Vectors/
   https://bioconductor.org/checkResults/3.11/bioc-LATEST/S4Vectors/

My own attempt with latest R devel was also unsuccessful:

   https://github.com/Bioconductor/S4Vectors/issues/57

For me to be able to troubleshoot this, I would need to have access to 
your setup. How do I do that?

Thanks,

H.


On 12/21/19 23:33, Andreas Tille wrote:
> Control: tags -1 upstream
> Control: forwarded -1 Bioconductor Package Maintainer 
> 
> 
> Hi,
> 
> as you can read below S4Vectors segfaults in its test.  Here you can
> find a complete test log
> 
> 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__ci.debian.net_data_autopkgtest_unstable_amd64_r_r-2Dbioc-2Ds4vectors_3725032_log.gz=DwIBAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=DHL7QJdlJrCrv38t_eLrYpMRBpEuSCg-d7MKzDbJj3U=ZjCPkSEcE-UgZ0StnEbjTm8Spw2ogduUSLVi36qppIk=
> 
> which says in the end:
> 
> ...
>> S4Vectors:::.test()
> 
>   *** caught segfault ***
> address 0x5586e27d4a60, cause 'invalid permissions'
> 
> Traceback:
>   1: runmed(y, 7)
>   2: runmed(y, 7)
>   3: as.vector(target)
>   4: mode(target)
>   5: attr.all.equal(target, current, tolerance = tolerance, scale = scale,
>  ...)
>   6: all.equal.numeric(as.vector(target), as.vector(current), tolerance = 
> tolerance, ...)
>   7: checkEqualsNumeric(runmed(y, 7), as.vector(runmed(Rle(y), 7)))
>   8: func()
>   9: system.time(func(), gcFirst = RUnitEnv$.gcBeforeTest)
> 10: doTryCatch(return(expr), name, parentenv, handler)
> 11: tryCatchOne(expr, names, parentenv, handlers[[1L]])
> 12: tryCatchList(expr, classes, parentenv, handlers)
> 13: tryCatch(expr, error = function(e) {call <- conditionCall(e)if 
> (!is.null(call)) {if (identical(call[[1L]], quote(doTryCatch)))   
>   call <- sys.call(-4L)dcall <- deparse(call)[1L]prefix 
> <- paste("Error in", dcall, ": ")LONG <- 75Lsm <- 
> strsplit(conditionMessage(e), "\n")[[1L]]w <- 14L + nchar(dcall, type 
> = "w") + nchar(sm[1L], type = "w")if (is.na(w)) w <- 14L 
> + nchar(dcall, type = "b") + nchar(sm[1L], type = "b")
> if (w > LONG) prefix <- paste0(prefix, "\n  ")}else 
> prefix <- "Error : "msg <- paste0(prefix, conditionMessage(e), "\n")
> .Internal(seterrmessage(msg[1L]))if (!silent && 
> isTRUE(getOption("show.error.messages"))) {cat(msg, file = outFile)   
>  .Internal(printDeferredWarnings())}invisible(structure(msg, 
> class = "try-error", condition = e))})
> 14: try(system.time(func(), gcFirst = RUnitEnv$.gcBeforeTest))
> 15: .executeTestCase(funcName, envir = sandbox, setUpFunc = .setUp, 
> tearDownFunc = .tearDown)
> 16: .sourceTestFile(testFile, testSuite$testFuncRegexp)
> 17: RUnit::runTestSuite(suite)
> 18: BiocGenerics:::testPackage("S4Vectors")
> 19: S4Vectors:::.test()
> An irrecoverable exception occurred. R is aborting now ...
> Segmentation fault
> 
> 
> Any idea how to fix this?
> 
> Kind regards
> 
>  Andreas.
> 
> On Thu, Dec 19, 2019 at 11:51:03AM +0100, Sebastien Bacher wrote:
>> Package: r-bioc-s4vectors
>> Version: 0.24.1-1
>>
>> The autopkgtest started failing on a segfault
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__ci.debian.net_packages_r_r-2Dbioc-2Ds4vectors_unstable_amd64_=DwIBAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=DHL7QJdlJrCrv38t_eLrYpMRBpEuSCg-d7MKzDbJj3U=RhjsZgmIre-LCJ6W9MTbYT6h-7GoeRVxSNNZRSIYvok=
>>
>> It seems to have started with the r-base update
>> -r-base-core 3.6.1-7
>> +r-base-core 3.6.1.20191206-1
>>
>> ___
>> R-pkg-team mailing list
>> r-pkg-t...@alioth-lists.debian.net
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__alioth-2Dlists.debian.net_cgi-2Dbin_mailman_listinfo_r-2Dpkg-2Dteam=DwIBAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=DHL7QJdlJrCrv38t_eLrYpMRBpEuSCg-d7MKzDbJj3U=UGzYFvbWg5wBrN_gos9Ue1RdLwcnqzdBasaqOwTW9Fg=
> 

-- 
Hervé Pagès

Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M1-B514
P.O. Box 19024
Seattle, WA 98109-1024

E-mail: hpa...@fredhutch.org
Phone:  (206) 667-5791
Fax:(206) 667-1319

Bug#920772: kdeinit5 crashing at MTP transfer to android device.

[Bernhard Übelacker]

Dear Maintainer,
I got today the same crash as the submitter.

It happened short after disconnecting one android device,
connecting another and opening/retrying the MTP connection.

This upstream bug looks related:
  https://bugs.kde.org/show_bug.cgi?id=415693
(Seems to be also from buster due to address offsets.)


This line seems to call member getDevice even when there is no object:

  102 LIBMTP_mtpdevice_t *device = 
deviceCache->get(pathItems.at(0))->getDevice();

  https://sources.debian.org/src/kio-extras/4:18.08.3-1/mtp/kio_mtp.cpp/#L102


This line got removed upstream in this commit:
  
https://cgit.kde.org/kio-extras.git/commit/mtp/kio_mtp.cpp?id=aaa1edbb74c4fb01affbde7b79bb45d3a9b61f83

Which points to this task and among others this bug:
  https://phabricator.kde.org/T9390
  https://bugs.kde.org/show_bug.cgi?id=396527


Because the offending line and function removed,
current testing 4:19.08.1-1 might be have this bug fixed.

One upstream mentions that Nautilus was working find,
this might be a workaround, as I guess MTP with KDE
will stay kind of fragile in Buster.


Kind regards,
Bernhard


Without debug symbols:
[KCrash Handler]
#6  0x7f9b372b417a in ?? () from 
/usr/lib/x86_64-linux-gnu/qt5/plugins/kf5/kio/mtp.so
#7  0x7f9b372b9457 in ?? () from 
/usr/lib/x86_64-linux-gnu/qt5/plugins/kf5/kio/mtp.so
#8  0x7f9b372bd65b in ?? () from 
/usr/lib/x86_64-linux-gnu/qt5/plugins/kf5/kio/mtp.so
#9  0x7f9b3272f39f in KIO::SlaveBase::dispatch(int, QByteArray const&) () 
from /usr/lib/x86_64-linux-gnu/libKF5KIOCore.so.5
#10 0x7f9b3272f876 in KIO::SlaveBase::dispatchLoop() () from 
/usr/lib/x86_64-linux-gnu/libKF5KIOCore.so.5
#11 0x7f9b372be7fd in kdemain () from 
/usr/lib/x86_64-linux-gnu/qt5/plugins/kf5/kio/mtp.so
#12 0x556b97c3fe1c in ?? ()
#13 0x556b97c40eea in ?? ()
#14 0x556b97c418fb in ?? ()
#15 0x556b97c3c645 in ?? ()
#16 0x7f9b3646b09b in __libc_start_main (main=0x556b97c3bc70, argc=5, 
argv=0x7ffc69537f98, init=, fini=, 
rtld_fini=, stack_end=0x7ffc69537f88) at ../csu/libc-start.c:308
#17 0x556b97c3d2ca in ?? ()
[Inferior 1 (process 2264) detached]

With debug symbols:
Thread 1 (Thread 0x7f9b32b26780 (LWP 2264)):
[KCrash Handler]
#6  CachedDevice::getDevice (this=0x0) at ./mtp/devicecache.cpp:64
#7  0x7f9b372b9457 in MTPSlave::getPath (this=0x7ffc695377b0, path=...) at 
/usr/include/x86_64-linux-gnu/qt5/QtCore/qlist.h:115
#8  0x7f9b372bd65b in MTPSlave::fileSystemFreeSpace (this=0x7ffc695377b0, 
url=...) at ./mtp/kio_mtp.cpp:946
#9  0x7f9b3272f39f in KIO::SlaveBase::dispatch(int, QByteArray const&) () 
from /usr/lib/x86_64-linux-gnu/libKF5KIOCore.so.5
#10 0x7f9b3272f876 in KIO::SlaveBase::dispatchLoop() () from 
/usr/lib/x86_64-linux-gnu/libKF5KIOCore.so.5
#11 0x7f9b372be7fd in kdemain (argc=, argv=) 
at ./mtp/kio_mtp.cpp:56
#12 0x556b97c3fe1c in launch (argc=4, _name=0x556b993ab398 
"/usr/lib/x86_64-linux-gnu/qt5/plugins/kf5/kio/mtp.so", args=, 
cwd=, envc=0, envs=, reset_env=false, tty=0x0, 
avoid_loops=false, startup_id_str=0x556b97c43187 "0") at 
./src/kdeinit/kinit.cpp:706
#13 0x556b97c40eea in handle_launcher_request (sock=8, who=) 
at ./src/kdeinit/kinit.cpp:1146
#14 0x556b97c418fb in handle_requests (waitForPid=0) at 
./src/kdeinit/kinit.cpp:1339
#15 0x556b97c3c645 in main (argc=5, argv=) at 
./src/kdeinit/kinit.cpp:1785
[Inferior 1 (process 2264) detached]


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

Kernel: Linux 4.19.0-7-amd64 (SMP w/16 CPU cores)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE= 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages kio-extras depends on:
ii  kio5.54.1-1
ii  kio-extras-data4:18.08.3-1
ii  libc6  2.28-10
ii  libgcc11:8.3.0-6
ii  libkf5activities5  5.54.0-1
ii  libkf5archive5 5.54.0-1
ii  libkf5bookmarks5   5.54.0-1
ii  libkf5codecs5  5.54.0-1
ii  libkf5configcore5  5.54.0-1+deb10u1
ii  libkf5configgui5   5.54.0-1+deb10u1
ii  libkf5configwidgets5   5.54.0-1
ii  libkf5coreaddons5  5.54.0-1
ii  libkf5dbusaddons5  5.54.0-1
ii  libkf5dnssd5   5.54.0-1
ii  libkf5guiaddons5   5.54.0-1
ii  libkf5i18n55.54.0-1
ii  libkf5iconthemes5  5.54.0-1
ii  libkf5khtml5   5.54.0-1
ii  libkf5kiocore5 5.54.1-1
ii  libkf5kiofilewidgets5  5.54.1-1
ii  libkf5kiowidgets5  5.54.1-1
ii  libkf5parts5   5.54.0-1
ii  libkf5pty5 5.54.0-1
ii  libkf5service-bin  5.54.0-1
ii  libkf5service5 5.54.0-1
ii  libkf5solid5   5.54.0-1
ii  

Bug#948498: libncurses-dev: Will not install

[Joseph Van Riper]

>This makes no sense to me.  Clearly your package lists are out of date, but 
>apt thinks they are not.  I don't have an explanation for that, but maybe it 
>helps to delete all the list files in /var/lib/apt/lists and rerun "apt 
>>update".  Be sure to keep the auxfiles/ and partial/ directories as well as 
>the lock file, though.

>$ sudo find /var/lib/apt/lists -type f '!' -empty -delete $ sudo apt update

That did the trick.

Maybe, because this runs as a virtual machine in a Hyper-V environment, and 
because the machine had run for months prior to starting it, I executed the 
'sudo apt update' command before the system's time updated.  I know too little 
about the innards of the Debian packaging system to understand if that could 
make any sense (for example, does the system take care to see if the fetched 
information from sudo apt update exist in the future, rather than the present?  
If it does check for this, then this theory doesn't hold up).  But, I figure, 
that is the one thing unusual about this system, versus the other Debian or 
Debian-derived OSes I've used.

In any event, this solved the issue for me.  Many thanks for your patience and 
effort!

- Trey
NOTICE TO RECIPIENT: This email, including attachments, may contain information 
which is confidential, proprietary, attorney-client privileged and / or 
controlled under U.S. export laws and regulations and may be restricted from 
disclosure by applicable State and Federal law. Nothing in this email shall 
create any legal binding agreement between the parties unless expressly stated 
herein and provided by an authorized representative of Comtech 
Telecommunications Corp. or its subsidiaries. If you are not the intended 
recipient of this message, be advised that any dissemination, distribution, or 
use of the contents of this message is strictly prohibited. If you received 
this message in error, please notify us immediately by return email and 
permanently delete all copies of the original email and any attached 
documentation from any computer or other media.

Bug#939989: transition: gdal

[Sebastiaan Couwenberg]

On 1/8/20 4:53 PM, Sebastiaan Couwenberg wrote:
> gdal (3.0.2+dfsg-1) is now built & installed on all release architectures.
> 
> Please schedule the binNMUs.

Thanks for scheduling the initial batch, everything has built now.
Please schedule the rest of Dependency level 1.

Kind Regards,

Bas

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



signature.asc
Description: OpenPGP digital signature

Bug#948504: (no subject)

[Steve Egbert]

Yes, that fixed it.

apt install libbsd-dev

Please close the ticket.

Bug#948517: e2fsprogs: malicious fs can cause use after free in e2fsck

[Theodore Y. Ts'o]

Package: e2fsprogs
Version: 
Severity: grave
Tags: security
Justification: user security hole

E2fsprogs 1.45.5 contains a bug fix for a use after free which could
potentially be used to run malicious code if a user can be tricked into
running e2fsck on a maliciously crafted file system.  The following
commit should be backported to Debian Buster (it is not applicable to
older versions of e2fsprogs):

101e73e9 - e2fsck: fix use after free in calculate_tree()

No exploit exists today as far as I know, but we should backport this
fix while we are addressing CVE-2019-5188 (Bug: #948508).

Bug#930532: xymon: imaps reports "unexpected service response"

[Greg Arnold]

I have a host that is consistently failing the imaps test - with debug
on, I get "tcp_got_expected: No data in banner"

If I run "sudo -u xymon /usr/lib/xymon/server/bin/xymonnet" from the
command line,it seems to always pass the test.

Bug#948349: multipath issue on Debian 9.11

[Kumar Ranjan]

Thanks for responding, Ritesh.
I have used the latest multipath-tools, and the problem is not io_setup failed 
message (which gets rectified via fs.aio-max-nr setting), but the "multipath 
-ll" freezing for 30 seconds.
I have put the snippet for strace during that time. Please let me know if you 
need further information.


Regards,
Ranjan

Bug#948462: pango1.0: Please omit libpango1.0-0 on Ubuntu/i386

[Steve Langasek]

On Thu, Jan 09, 2020 at 10:37:05AM +, Simon McVittie wrote:
> On Wed, 08 Jan 2020 at 13:54:47 -0800, Steve Langasek wrote:
> > We are keeping pango1.0 on i386 because
> > it's a relevant part of a GTK-based compatibility stack, but the
> > libpango1.0-0 package built from this source is a transitional package with
> > dependencies on other packages that are not being kept as part of the
> > compatibility library set (libpangox-1.0-0).

> I'd really prefer to drop libpango1.0-0 altogether, which is already
> pending in git for experimental, rather than making the same source code
> compile differently on Ubuntu.

> This would break flashplugin-nonfree and qtile, but both of those are
> RC-buggy already.

> % dak rm -R -n -b libpango1.0-0
> ...
> Checking reverse dependencies...
> # Broken Depends:
> flashplugin-nonfree/contrib: flashplugin-nonfree [amd64 i386]
> qtile: python3-qtile [amd64 arm64 armel armhf i386 mips64el mipsel 
> ppc64el]
> 
> # Broken Build-Depends:
> qtile: libpango1.0-0

> I see Ubuntu is already tracking pango1.0/experimental, so hopefully
> an upload of the current debian/master branch to experimental is enough
> for you?

Yes, that's fine (we won't automatically sync from experimental, but I
assume whoever did that sync will continue tracking it).  We have a few more
reverse-dependencies in Ubuntu so it will take more work for that sync to be
able to reach the release pocket, but I've already uploaded this delta to
Ubuntu to take care of the uninstallability, so it won't block us getting
this issue fixed in Ubuntu.

$ reverse-depends libpango1.0-0
Reverse-Depends
===
* flashplugin-installer [amd64]
* gkrellm-reminder [amd64]
* gkrellm-xkb [amd64]
* gtk2-engines-cleanice [amd64]
* gtk2-engines-moblin [amd64 armhf]
* gyrus [amd64 armhf]
* pepperflashplugin-nonfree [amd64]
* pidgin-guifications [amd64 armhf]
* python3-qtile
* tuxcmd [amd64 armhf]

Packages without architectures listed are reverse-dependencies in: amd64, 
arm64, armhf, ppc64el

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


signature.asc
Description: PGP signature