Bug#970532: ITP: pyemd -- Python library for the Earth Mover's Distance with NumPy

[Paul Wise]

Package: wnpp
Severity: wishlist
Owner: Paul Wise 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-scie...@lists.debian.org

* Package name: pyemd
  Version : 0.5.1
  Upstream Author : Will Mayner and others
* URL : https://github.com/wmayner/pyemd
* License : MIT
  Programming Lang: C++, Python
  Description : Python library for the Earth Mover's Distance with NumPy

This is a dependency of gensim and will be maintained in the Debian
Science team.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#970531: ITP: nmslib -- similarity search for evaluation of k-NN methods for generic non-metric spaces

[Paul Wise]

Package: wnpp
Severity: wishlist
Owner: Paul Wise 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-scie...@lists.debian.org

* Package name: nmslib
  Version : 2.0.6
  Upstream Author : Bilegsaikhan Naidan and others
* URL : https://github.com/nmslib/nmslib
* License : Apache 2.0
  Programming Lang: C++, Perl, Python and others
  Description : similarity search for evaluation of k-NN methods for 
generic non-metric spaces

This is a dependency of gensim and will be maintained within the Debian
Science team.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#960301: firefox-esr: [regression] cannot find the microphone

[Job Ryan C. Bautista]

Control: found -1 68.11.0esr-1

Firefox on the latest version of testing still doesn't detect my laptop's mic.
Seems like this is only a problem for systems without PulseAudio. I was able to
workaround this problem by wrapping firefox-esr around apulse, but I'd rather
have a true solution than a hack like apulse.

Students like me are going online for our classes, and it sucks that
Firefox out-
of-the-box won't detect our microphones. So please fix as soon as possible.

Job Bautista

Bug#970096: buster-pu: package libdbi-perl/1.642-1+deb10u1

[Xavier]

Le 17/09/2020 à 22:23, Xavier a écrit :
> Le 17/09/2020 à 21:26, Adam D. Barratt a écrit :
>> Control: tags -1 + confirmed
>>
>> On Sat, 2020-09-12 at 08:50 +0200, Xavier wrote:
>>>
>>
>> +libdbi-perl (1.642-1+deb10u1) buster; urgency=medium
>> +
>> +  * Fix memory corruption in XS functions when Perl stack is reallocated
>> +(Closes: CVE-2020-14392)
>> +  * Fix a buffer overflow on an overlong DBD class name
>> +(Closes: CVE-2020-14393)
>> +
>> + -- Xavier Guimard   Thu, 10 Sep 2020 10:04:13 +0200
>>
>> Please go ahead.
>>
>> Regards,
>>
>> Adam
> 
> Hi,
> 
> I'm going to try to add also this patch (for CVE-2019-20919:
> https://github.com/perl5-dbi/dbi/commit/eca7d7c8f
> 
> I'll push a new debdiff after tests
> 
> Cheers,
> Xavier

Here is the new debdiff
diff --git a/debian/changelog b/debian/changelog
index d2e35cc..3ea2f5e 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,13 @@
+libdbi-perl (1.642-1+deb10u1) buster; urgency=medium
+
+  * Fix memory corruption in XS functions when Perl stack is reallocated
+(Closes: CVE-2020-14392)
+  * Fix a buffer overflow on an overlong DBD class name
+(Closes: CVE-2020-14393)
+  * Fix a NULL profile dereference in dbi_profile() (Closes: CVE-2019-20919)
+
+ -- Xavier Guimard   Thu, 10 Sep 2020 10:04:13 +0200
+
 libdbi-perl (1.642-1) unstable; urgency=medium
 
   [ Xavier Guimard ]
diff --git a/debian/patches/CVE-2019-20919.patch 
b/debian/patches/CVE-2019-20919.patch
new file mode 100644
index 000..b25a3fd
--- /dev/null
+++ b/debian/patches/CVE-2019-20919.patch
@@ -0,0 +1,28 @@
+Description: Fix a NULL profile dereference in dbi_profile()
+ hv_fetch() documentation requires checking for NULL and the code does
+ that. But then calls SvOK(profile) uncoditionally two lines later.
+ This patch fixes it.
+Author: Petr Pisar 
+Origin: upstream, https://github.com/perl5-dbi/dbi/commit/eca7d7c8
+Bug: https://security-tracker.debian.org/tracker/CVE-2019-20919
+Forwarded: not-needed
+Reviewed-By: Xavier Guimard 
+Last-Update: 2020-09-17
+
+--- a/DBI.xs
 b/DBI.xs
+@@ -2904,8 +2904,12 @@
+ mg_get(profile); /* FETCH */
+ if (!profile || !SvROK(profile)) {
+ DBIc_set(imp_xxh, DBIcf_Profile, 0); /* disable */
+-if (SvOK(profile) && !PL_dirty)
+-warn("Profile attribute isn't a hash ref (%s,%ld)", 
neatsvpv(profile,0), (long)SvTYPE(profile));
++if (!PL_dirty) {
++if (!profile)
++warn("Profile attribute does not exist");
++else if (SvOK(profile))
++warn("Profile attribute isn't a hash ref (%s,%ld)", 
neatsvpv(profile,0), (long)SvTYPE(profile));
++}
+ return _sv_undef;
+ }
+ 
diff --git a/debian/patches/CVE-2020-14392.patch 
b/debian/patches/CVE-2020-14392.patch
new file mode 100644
index 000..99c7a3e
--- /dev/null
+++ b/debian/patches/CVE-2020-14392.patch
@@ -0,0 +1,318 @@
+Description: Fix memory corruption in XS functions when Perl stack is 
reallocated
+ Macro ST(*) returns pointer to Perl stack. Other Perl functions which use
+ Perl stack (e.g. eval) may reallocate Perl stack and therefore pointer
+ returned by ST(*) macro is invalid.
+ .
+ Construction like this:
+ .
+ ST(0) = dbd_db_login6_sv(dbh, imp_dbh, dbname, username, password, attribs) ? 
_sv_yes : _sv_no;
+ .
+ where dbd_db_login6_sv() driver function calls eval may lead to
+ reallocating Perl stack and therefore invalidating ST(0) pointer.
+ So that construction would cause memory corruption as left part of
+ assignment is resolved prior executing dbd_db_login6_sv() function.
+ .
+ Correct way how to handle this problem: First call dbd_db_login6_sv()
+ function and then call ST(0) to retrieve stack pointer.
+ .
+ In this patch are fixes all occurrences of such constructions.
+ .
+ When running perl under valgrind I got memory corruption in DBD::ODBC
+ driver in that dbd_db_login6_sv() function due to above problem.
+Author: Pali 
+Origin: upstream, https://github.com/perl5-dbi/dbi/commit/ea99b6aa
+Bug: https://security-tracker.debian.org/tracker/CVE-2020-14392
+Forwarded: not-needed
+Reviewed-By: Xavier Guimard 
+Last-Update: 2020-09-10
+
+--- a/DBI.xs
 b/DBI.xs
+@@ -5252,9 +5252,12 @@
+ SV *col
+ SV *ref
+ SV *attribs
++PREINIT:
++SV *ret;
+ CODE:
+ DBD_ATTRIBS_CHECK("bind_col", sth, attribs);
+-ST(0) = boolSV(dbih_sth_bind_col(sth, col, ref, attribs));
++ret = boolSV(dbih_sth_bind_col(sth, col, ref, attribs));
++ST(0) = ret;
+ (void)cv;
+ 
+ 
+@@ -5492,21 +5495,27 @@
+ FETCH(h, keysv)
+ SV *h
+ SV *keysv
++PREINIT:
++SV *ret;
+ CODE:
+-ST(0) = dbih_get_attr_k(h, keysv, 0);
++ret = dbih_get_attr_k(h, keysv, 0);
++ST(0) = ret;
+ (void)cv;
+ 
+ void
+ DELETE(h, keysv)
+ SV *h
+ SV *keysv
++PREINIT:
++SV *ret;
+ CODE:
+ /* only private_* keys can be deleted, for others DELETE acts like FETCH 
*/

Bug#970529: ITP: morfessor -- tool for unsupervised and semi-supervised morphological segmentation

[Paul Wise]

Package: wnpp
Severity: wishlist
Owner: Paul Wise 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-scie...@lists.debian.org

* Package name: morfessor
  Version : 2.0.6
  Upstream Author : Morpho project at Aalto University, Finland
* URL : http://morpho.aalto.fi/projects/morpho/morfessor2.html
* License : BSD
  Programming Lang: Python
  Description : tool for unsupervised and semi-supervised morphological 
segmentation

This is a dependency of gensim and it will be maintained within the
Debian Science team.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#970526: "mutt" is forced to use "utf-8" and "base64".

[Bjarni Ingi Gislason]

Package: reportbug
Version: 7.7.0
Severity: normal

Dear Maintainer,

  If an octet (8bit) character (mu, µ) is used in the body of a report,
"reportbug" changes the default encoding for "mutt" to "utf-8" and then
"mutt" encodes the body with "base64".

  The bug tracker does not accept such mails, as the header of the
report is missing (concealed in the encoded text).


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

Kernel: Linux 5.8.7-1 (SMP w/2 CPU threads)
Locale: LANG=is_IS.iso88591, LC_CTYPE=is_IS.iso88591 (charmap=ISO-8859-1), 
LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

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

reportbug recommends no packages.

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

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

python3-reportbug suggests no packages.

-- no debconf information


-- 
Bjarni I. Gislason

Bug#969781: RFP: libtoml-tiny-perl -- minimal, pure perl TOML parser and serializer

[Guillem Jover]

Hi!

On Tue, 2020-09-08 at 17:34:28 +0200, gregor herrmann wrote:
> On Tue, 08 Sep 2020 03:19:36 +0200, Guillem Jover wrote:
> > Attached a working and tested packaging, where only the ITP bug number
> > needs to be filled in the debian/changelog, Maintainer changed, and
> > Vcs fields added if appropriate.
> 
> Thanks!

Well, thank you for taking maintainership and uploading!

> libtoml-tiny-perl is in the NEW queue now.

Perfect, thanks! BTW upstream fixed the dependency problem for which
I included a patch, I think in a better way, and released a new
version. :)

Also, I guess you might not have removed me as maintainer out of
courtesy? :) If so, I think for now I'd prefer to not be listed, as
I'm afraid I've got too much on my plate, although I would not mind
lending a hand for specific issues or similar if needed!

Thanks,
Guillem

Bug#970525: docker.io: Unable to start minikube/kubernetes containers: unable to find user 0: invalid argument

[Matthew Gabeler-Lee]

Package: docker.io
Version: 19.03.12+dfsg1-4
Severity: important

Something in the change(s) for 19.03.12+dfsg1-4 has broken using the
docker.io package with some minikube configurations (particularly the "none"
driver which runs the kubernetes containers directly in the host docker
instance). All of minikube/kubelet's attempts to start the pods result in
docker logging errors like so:

Sep 17 20:28:35 nigripes dockerd[2793900]: 
time="2020-09-17T20:28:35.211635346-04:00" level=error msg="Handler for POST 
/v1.40/containers/e847bf6564589a04ca7a9a54f77d09a1cf6300fbaebce0224d7e86fc9f900754/start
 returned error: unable to find user 0: invalid argument"

Downgrading just one release to 19.03.12+dfsg1-3 and it works again, so
there's a pretty narrow window for what could have broken this.

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

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

Versions of packages docker.io depends on:
ii  adduser  3.118
ii  init-system-helpers  1.58
ii  iptables 1.8.5-3
ii  libc62.31-3
ii  libdevmapper1.02.1   2:1.02.171-3
ii  libltdl7 2.4.6-14
ii  libnspr4 2:4.28-1
ii  libnss3  2:3.56-1
ii  libseccomp2  2.4.3-1+b1
ii  libsystemd0  246.5-1
ii  lsb-base 11.1.0
ii  runc 1.0.0~rc92+dfsg1-5
ii  tini 0.18.0-1+b1

Versions of packages docker.io recommends:
ii  ca-certificates  20200601
ii  cgroupfs-mount   1.4
ii  git  1:2.28.0-1
ii  needrestart  3.5-1
ii  xz-utils 5.2.4-1+b1

Versions of packages docker.io suggests:
ii  aufs-tools   1:4.14+20190211-1
ii  btrfs-progs  5.7-1
ii  debootstrap  1.0.123
pn  docker-doc   
ii  e2fsprogs1.45.6-1
pn  rinse
ii  xfsprogs 5.6.0-1+b2
pn  zfs-fuse | zfsutils  

-- no debconf information

Bug#970460: qemu-user: trashes argv[0] breaking multi-call binaries

[Finn Thain]

On Thu, 17 Sep 2020, Thorsten Glaser wrote:

> 
>  Well, to be honest, you should never use the Debian QEMU package. 
>  It's almost always very outdated and would lack important patches 
>  like these. It's easier to use local builds from git.
> 
> Erm, excuse me?!?!?!
> 

It's an over-statement. Let's not over-react. Just read "not presently" in 
place of "never".

> ...
> >> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=916276
> >> [2] https://sourceware.org/bugzilla/show_bug.cgi?id=23960
> 
> This is the first time I'm being made aware of that.

Thanks for the link, Adrian, and thanks for raising this issue upstream. 
It's a monumental mess.

Bug#970524: pybuild: variable `allow_hosts` has been deprecated by setuptools

[Louis-Philippe Véronneau]

Package: dh-python
Version: 4.20200804
Severity: important

Hi!

While trying to build cherryp3, I encountered this error:

dh clean --buildsystem pybuild --with python3,sphinxdoc
   dh_auto_clean -O--buildsystem=pybuild
I: pybuild base:217: python3.8 setup.py clean
Traceback (most recent call last):
  File "setup.py", line 124, in 
main()
  File "setup.py", line 120, in main
setuptools.setup(**setup_params)
  File "/usr/lib/python3/dist-packages/setuptools/__init__.py", line
162, in setup
_install_setup_requires(attrs)
  File "/usr/lib/python3/dist-packages/setuptools/__init__.py", line
157, in _install_setup_requires
dist.fetch_build_eggs(dist.setup_requires)
  File "/usr/lib/python3/dist-packages/setuptools/dist.py", line 699, in
fetch_build_eggs
resolved_dists = pkg_resources.working_set.resolve(
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line
779, in resolve
dist = best[req.key] = env.best_match(
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line
1064, in best_match
return self.obtain(req, installer)
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line
1076, in obtain
return installer(requirement)
  File "/usr/lib/python3/dist-packages/setuptools/dist.py", line 758, in
fetch_build_egg
return fetch_build_egg(self, req)
  File "/usr/lib/python3/dist-packages/setuptools/installer.py", line
83, in fetch_build_egg
raise DistutilsError('the `allow-hosts` option is not supported '
distutils.errors.DistutilsError: the `allow-hosts` option is not
supported when using pip to install requirements.
E: pybuild pybuild:352: clean: plugin distutils failed with: exit
code=1: python3.8 setup.py clean
dh_auto_clean: error: pybuild --clean --test-pytest -i python{version}
-p 3.8 returned exit code 13

It seems the `allow_hosts=None` option used to prevent automatic
download of dependencies has been deprecated since setuptools 42.0.0 [1].

I'm not sure there is a solution to replicate that behavior at the moment...

I was able to build cherryp3 by removing the "*_requires" lines in
setup.py, but that doesn't seem very clean.

Cheers,

[1]: https://github.com/pypa/setuptools/issues/1916

-- 
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
  ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
  ⠈⠳⣄



signature.asc
Description: OpenPGP digital signature

Bug#970523: Missing fixes from gcc-10

[Ben Hutchings]

Package: src:gcc-10-cross
Version: 11
Severity: normal

Please update to the current version of gcc-10.  I am specifically
running into PR96377 which was already fixed in the native compiler.

Ben.

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

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

Bug#965130: RFS: logrotate/3.17.0-1 -- Log rotation utility

[Christian Göttsche]

I uploaded a new version to mentors (2020-09-17 17:53), which
re-disables the testsuite on non-Linux.

Also added a Closes: entry for #966016.

Bug#970522: systemd.automount fails to mount a CIFS share

[cbr...@t-online.de]

Sep 17 22:23:22 amiga5000 systemd[1]: Condition check resulted in FUSE Control 
File System being skipped.
Sep 17 22:23:22 amiga5000 systemd[1]: Condition check resulted in Kernel 
Configuration File System being skipped.
Sep 17 22:23:22 amiga5000 systemd[1]: Condition check resulted in FUSE Control 
File System being skipped.
Sep 17 22:23:22 amiga5000 systemd[1]: Condition check resulted in Kernel 
Configuration File System being skipped.
Sep 17 22:23:24 amiga5000 systemd[1]: Daten.automount: Got automount request 
for /Daten, triggered by 653 (daemon-init)
Sep 17 22:23:32 amiga5000 systemd[1]: Mounting /Daten...
Sep 17 22:23:32 amiga5000 mount[866]: mount error: could not resolve address 
for diskstation: Unknown error
Sep 17 22:23:32 amiga5000 systemd[1]: Daten.mount: Mount process exited, 
code=exited, status=1/FAILURE
Sep 17 22:23:32 amiga5000 systemd[1]: Daten.mount: Failed with result 
'exit-code'.
Sep 17 22:23:32 amiga5000 systemd[1]: Failed to mount /Daten.
Sep 17 22:23:32 amiga5000 systemd[1]: Daten.automount: Got automount request 
for /Daten, triggered by 653 (daemon-init)
Sep 17 22:23:32 amiga5000 systemd[1]: Mounting /Daten...
Sep 17 22:23:32 amiga5000 mount[871]: mount error: could not resolve address 
for diskstation: Unknown error
Sep 17 22:23:32 amiga5000 systemd[1]: Daten.mount: Mount process exited, 
code=exited, status=1/FAILURE
Sep 17 22:23:32 amiga5000 systemd[1]: Daten.mount: Failed with result 
'exit-code'.
Sep 17 22:23:32 amiga5000 systemd[1]: Failed to mount /Daten.
Sep 17 22:23:38 amiga5000 systemd[1]: Daten.automount: Got automount request 
for /Daten, triggered by 1044 (xfdesktop)
Sep 17 22:23:38 amiga5000 systemd[1]: Mounting /Daten...
Sep 17 22:23:38 amiga5000 mount[1158]: mount error: could not resolve address 
for diskstation: Unknown error
Sep 17 22:23:38 amiga5000 systemd[1]: Daten.mount: Mount process exited, 
code=exited, status=1/FAILURE
Sep 17 22:23:38 amiga5000 systemd[1]: Daten.mount: Failed with result 
'exit-code'.
Sep 17 22:23:38 amiga5000 systemd[1]: Failed to mount /Daten.
Sep 17 22:23:38 amiga5000 systemd[1]: Daten.automount: Got automount request 
for /Daten, triggered by 1044 (xfdesktop)
Sep 17 22:23:38 amiga5000 systemd[1]: Mounting /Daten...
Sep 17 22:23:38 amiga5000 mount[1161]: mount error: could not resolve address 
for diskstation: Unknown error
Sep 17 22:23:38 amiga5000 systemd[1]: Daten.mount: Mount process exited, 
code=exited, status=1/FAILURE
Sep 17 22:23:38 amiga5000 systemd[1]: Daten.mount: Failed with result 
'exit-code'.
Sep 17 22:23:38 amiga5000 systemd[1]: Failed to mount /Daten.
Sep 17 22:23:38 amiga5000 systemd[1]: Daten.automount: Got automount request 
for /Daten, triggered by 1044 (xfdesktop)
Sep 17 22:23:38 amiga5000 systemd[1]: Mounting /Daten...
Sep 17 22:23:38 amiga5000 mount[1164]: mount error: could not resolve address 
for diskstation: Unknown error
Sep 17 22:23:38 amiga5000 systemd[1]: Daten.mount: Mount process exited, 
code=exited, status=1/FAILURE
Sep 17 22:23:38 amiga5000 systemd[1]: Daten.mount: Failed with result 
'exit-code'.
Sep 17 22:23:38 amiga5000 systemd[1]: Failed to mount /Daten.
Sep 17 22:23:38 amiga5000 systemd[1]: Daten.automount: Got automount request 
for /Daten, triggered by 1044 (xfdesktop)
Sep 17 22:23:38 amiga5000 systemd[1]: Daten.mount: Start request repeated too 
quickly.
Sep 17 22:23:38 amiga5000 systemd[1]: Daten.mount: Failed with result 
'exit-code'.
Sep 17 22:23:38 amiga5000 systemd[1]: Failed to mount /Daten.
Sep 17 22:23:38 amiga5000 systemd[1]: Daten.automount: Failed with result 
'mount-start-limit-hit'.
Sep 17 22:23:45 amiga5000 systemd[1]: run-user-114.mount: Succeeded.




Bug#916276: glibc: Please add prelimenary patch to fix regression on qemu-user

[Thorsten Glaser]

Hello glibc maintainers,

would you please consider including this patch to unbreak things
(fix a regression) until the triangle between qemu, Linux and glibc
has figured out how to best deal with it?

Thanks,
//mirabilos
-- 
 you introduced a merge commit│ % g rebase -i HEAD^^
 sorry, no idea and rebasing just fscked │ Segmentation
 should have cloned into a clean repo  │  fault (core dumped)
 if I rebase that now, it's really ugh │ wuahh

Bug#970460: qemu-user: trashes argv[0] breaking multi-call binaries

[Thorsten Glaser]

Michael Tokarev dixit:
> 17.09.2020 10:56, John Paul Adrian Glaubitz wrote:
>> On 9/17/20 9:49 AM, Michael Tokarev wrote:
>>>17.09.2020 10:08, John Paul Adrian Glaubitz wrote:
 On 9/16/20 8:42 PM, Thorsten Glaser wrote:
> John Paul Adrian Glaubitz dixit:
>
>> That’s been fixed upstream and can be configured with the
>> qemu-binfmt.sh script and the option “preserved=yes”.
>
> $ locate qemu-binfmt.sh | wc
>   0   0   0
>>>
>>>It is scripts/qemu-binfmt-conf.sh script inside the qemu sources.
>>>It was a fork of debian's d/update-binfmts.sh, updated for other
>>>use cases.

Ah, okay.

 Well, to be honest, you should never use the Debian QEMU package. It's 
 almost
 always very outdated and would lack important patches like these. It's 
 easier
 to use local builds from git.

Erm, excuse me?!?!?!

Of *course*, when developing for (or on, most of the time)
Debian, I use as many tools in the form packaged in Debian
as possible.

When developing *for* Debian (that is, things that eventually
get uploaded), I think it’s correct to even have the *expectation*
that only packaged things get used throughout the chain.

If your qemu buildds have errors, where else would we fix them?
Also, how else would maintainers reproduce them?

I reported this bug *because* your qemu buildds had errors
building mksh and because I was able to reproduce them.

I *really* _expect_ qemu buildds to use the packaged version
of qemu-user, ideally the one from sid.

>>>You should not use upstream git of qemu, since it too lacks
>>>important patches like this, - please don't suggest people
>>>to use outdated sources.. :)

Thanks for the confirmation from the maintainer.

>> I think I'm one of the heaviest users of QEMU inside Debian and if
>> I had stuck with the Debian version of QEMU, the m68k and sh4 ports
>> would not be able to keep up due to QEMU issues. Laurent will confirm
>> the number of bugs I reported and that got fixed.

That asks for trying to work with the Debian maintainer of the
affected package (qemu in this case) to get the bugs not only
fixed but also available to Debian users. (Yes I know, but see
below.)

>>>(just as a matter of fact, debian usually has new version of
>>>qemu the next day it is released, and I usually keep it up
>>>to date in backports. With debian stable and current qemu 5.
>>>we have a bit of delay since there are a few other things to
>>>backport, but we have 5.0 there).

But a buildd can run unstable anyway, and especially with
qemu-user-static this should be a given.

>> Well, the first thing would be to switch QEMU in Debian to finally
>> use systemd-binfmt instead of the old binfmt-support package,
>> something that has happened in other distributions long ago.

Absolutely not! That will break it on all my systems.

> This will make other packages using binfmt-support to work with
> the systemd binfmt registration instantly, and things will continue
> to work if systemd is not in use (for those who prefer sysvinit
> or other init mechanisms, fwiw).

Thanks.

> Also, why didnbt you fix that on the m68k and sh4 qemu buildds then? ;-)

I did. But I'm updating the QEMU version on the buildds from time to time
by rebasing with git master and then I drop all the patches that have been
applied upstream.

Arrgh, no. Please use the packaged version. That avoids
many issues and ensures trust.

>> If you are willing to cooperate though, I'm happy to point you to
>> all the patches necessary to address all issues that we observed.
>
> I'm definitely interested in things being fixed in the end, tho
> it isn't obvious how much backporting should be done to _testing_
> version in Debian.

Thanks for being open to patching the version in Debian. Not all
maintainers are agreeable like that, unfortunately.

I know the burden of carrying local patches, but backports would
have been already accepted upstream, are scheduled to be removed
with a new upstream release, and are less likely to break things.
Patches that fix things for an architecture, whether guest or host,
should be considered IMHO, even if it’s not a release architecture,
at least during normal development, i.e. not just before a freeze
but all the other time.

>> There is also an important glibc patch necessary to unbreak qemu-user
>> that still hasn't been merged in glibc upstream or in Debian's glibc
>> package [1, 2].

>> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=916276
>> [2] https://sourceware.org/bugzilla/show_bug.cgi?id=23960

This is the first time I’m being made aware of that. (I had wondered
about the +qemu releases in unreleased.) This looks like another case
of prodding maintainers (and, perhaps, looking whether it can’t be
fixed in qemu as well).

But that’s what uploads to dpo unreleased are for, after all. And
if done with care and following normal Debian rules (and, incidentally,
being made using _only_ tools from Debian) I consider 

Bug#970522: systemd.automount fails to mount a CIFS share

[Michael Biebl]

Am 17.09.20 um 23:02 schrieb Christian Britz:
> Package: systemd
> Version: 246.5-1
> Severity: normal
> X-Debbugs-Cc: cbr...@t-online.de
> 
> Dear Maintainer,
> 
> for some time now, the automount feature of systemd fails to mount a CIFS
> share. Manually mounting the share works. It worked previously.
> The error message is: mount[1164]: mount error: could not resolve address for
> xxx: Unknown error
> 
> fstab entry:
> //xxx/yyy /zzz cifs
> uid=1000,gid=1000,file_mode=0600,dir_mode=0700,credentials=/home/abc/.smbcredentials,x-systemd.automount,noauto
> 0  0

Please post a full journal log showing the problem with some context.




signature.asc
Description: OpenPGP digital signature

Bug#970386: dovecot-imapd: assertion failure in message_part_finish when searching large folder

[Timo Sirainen]

On 15. Sep 2020, at 14.00, Matthew Vernon  wrote:
> One of my IMAP users reports failures when trying to do full-text
> searches of a large (3G) mailbox; subject-only searches are OK.
> 
> The backtrace in syslog is:
> 
> Sep 15 11:51:37 aragorn dovecot: imap(atreic): Panic: file message-parser.c: 
> line 174 (message_part_finish): assertion failed: (ctx->nested_parts_count > 
> 0)

The original backported patch for v2.2 was accidentally wrong. Also I'm not 
sure if Debian backport had the "--" suffix boundary fix either? Attached 
anyway patches for both fixes.



fix1.patch
Description: Binary data


fix2.patch
Description: Binary data

Bug#970241: gnome-weather 3.26.0-6~deb10u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 970241 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: gnome-weather
Version: 3.26.0-6~deb10u1

Explanation: prevent a crash when the locations configured are invalid

Bug#970296: qtbase-opensource-src 5.11.3+dfsg1-1+deb10u4 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 970296 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: qtbase-opensource-src
Version: 5.11.3+dfsg1-1+deb10u4

Explanation: fix buffer overflow in XBM parser [CVE-2020-17507]; fix clipboard 
breaking when timer wraps after 50 days

Bug#968723: incron 0.5.12-1+deb10u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 968723 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: incron
Version: 0.5.12-1+deb10u1

Explanation: fix cleanup of zombie processes

Bug#970239: gnome-shell 3.30.2-11~deb10u2 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 970239 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: gnome-shell
Version: 3.30.2-11~deb10u2

Explanation: loginDialog: Reset auth prompt on vt switch before fade in 
[CVE-2020-17489]

Bug#947464: gnome-maps 3.30.3.1-0+deb10u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 947464 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: gnome-maps
Version: 3.30.3.1-0+deb10u1

Explanation: fix an issue with misaligned shape layer rendering

Bug#968296: calamares-settings-debian 10.0.20-1+deb10u4 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 968296 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: calamares-settings-debian
Version: 10.0.20-1+deb10u4

Explanation: disable displaymanager module

Bug#969974: Blocked by #970519

[Patrik Dufresne]

Cannot continue working on packaging of Rdiffweb because of missing
dependencies to run the unit test. See #970519

-- 
IKUS Software inc.
https://www.ikus-soft.com/
514-971-6442
130 rue Doris
St-Colomban, QC J5K 1T9
[image: vcs]

Bug#970520: wesnoth: Crash on starting wesnoth - stack smash detected

[Max Hofer]

Package: wesnoth
Version: 1:1.14.13-1
Severity: important

Dear Maintainer,

when I start wesnoth it crashed with follwoing output:


 START OF TERMINAL OUTPUT -
Battle for Wesnoth v1.14.13
Started on Thu Sep 17 22:33:45 2020


Data directory:   /usr/share/games/wesnoth/1.14
User configuration directory: /home/USER/.config/wesnoth-1.14
User data directory:  /home/USER/.config/wesnoth-1.14
Cache directory:  /home/USER/.config/wesnoth-1.14/cache

Setting mode to 1280x720
*** stack smashing detected ***: terminated
Abgebrochen
 END OF TERMINAL OUTPUT 

My .xsession file does not contain much information.

- START .xsession 
powerdevil: Scheduling inhibition from ":1.15" "My SDL application" with cookie 
5 and reason "Playing a game"
qt.qpa.xcb: QXcbConnection: XCB error: 3 (BadWindow), sequence: 37711, resource 
id: 37752062, major code: 3 (GetWindowAttributes), minor code: 0
qt.qpa.xcb: QXcbConnection: XCB error: 9 (BadDrawable), sequence: 37712, 
resource id: 37752062, major code: 14 (GetGeometry), minor code: 0
powerdevil: Releasing inhibition with cookie  5
powerdevil: It was only scheduled for inhibition but not enforced yet, just 
discarding it
qt.qpa.xcb: QXcbConnection: XCB error: 3 (BadWindow), sequence: 37838, resource 
id: 79691790, major code: 15 (QueryTree), minor code: 0
qt.qpa.xcb: QXcbConnection: XCB error: 3 (BadWindow), sequence: 37844, resource 
id: 79691790, major code: 18 (ChangeProperty), minor code: 0
OpenGL vendor string:   Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel(R) HD Graphics 4600 (HSW 
GT2)
OpenGL version string:  3.0 Mesa 20.1.8
OpenGL shading language version string: 1.30
Driver: Intel
GPU class:  Unknown
OpenGL version: 3.0
GLSL version:   1.30
Mesa version:   20.1.8
X server version:   1.20.9
Linux kernel version:   5.8
Requires strict binding:yes
GLSL shaders:   yes
Texture NPOT support:   yes
Virtual Machine:no
BlurConfig::instance called after the first use - ignoring
DesktopGridConfig::instance called after the first use - ignoring
KscreenConfig::instance called after the first use - ignoring
PresentWindowsConfig::instance called after the first use - ignoring
SlideConfig::instance called after the first use - ignoring
SlidingPopupsConfig::instance called after the first use - ignoring
ZoomConfig::instance called after the first use - ignoring
powerdevil: Enforcing inhibition from ":1.15" "My SDL application" with cookie 
5 and reason "Playing a game"
powerdevil: By the time we wanted to enforce the inhibition it was already 
gone; discarding it
- END .xsession 

I haven't found valuable information in any other log file on my system.

I run KDE with sddm.


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

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

Versions of packages wesnoth depends on:
ii  wesnoth-1.14   1:1.14.13-1
ii  wesnoth-1.14-data  1:1.14.13-1

wesnoth recommends no packages.

wesnoth suggests no packages.

-- no debconf information

Bug#970521: ITP: raft -- Raft Consensus protocol implementation

[GCS]

Package: wnpp
Severity: wishlist
Owner: Laszlo Boszormenyi (GCS) 

* Package name: raft
  Version : 0.9.25
  Upstream Author : 2019- Canonical Ltd.
* URL : https://github.com/canonical/raft
* License : LGPL-3 with linking exception
  Programming Lang: C
  Description : Raft Consensus protocol implementation
Fully asynchronous C implementation of the Raft consensus protocol.
The library has modular design: its core part implements only the core Raft
algorithm logic, in a fully platform independent way. On top of that, a
pluggable interface defines the I/O implementation for networking
(send/receive RPC messages) and disk persistence (store log entries and
snapshots).

Bug#970519: python3-cherrypy3: Binary package should include include cherrypy/test/helper.py and cherrypy/test/webtest.py

[Patrik Dufresne]

Package: python3-cherrypy3
Version: 8.9.1-2
Severity: important

Dear Maintainer,

When trying to package Rdiffweb see ITP #969974, I'm facing an issue because
the unit test in Rdiffweb depends on cherrypy/test/helper.py and
cherrypy/test/webtest.py. While trying to build the package, the Rdiffweb's
unit test are failing because of missing modules.

The cherrypy documentation is pointing toward those helper modules to automate
and ease the unit test creation. Thus it's the recommended way to write unit
test. For this reason, I'm asking to include those two files as part of the
binary distribution.



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

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

Versions of packages python3-cherrypy3 depends on:
ii  python3  3.7.3-1
ii  python3-six  1.12.0-1

Versions of packages python3-cherrypy3 recommends:
ii  python3-openssl 19.0.0-1
pn  python3-routes  
ii  python3-simplejson  3.16.0-1

python3-cherrypy3 suggests no packages.

Bug#970096: buster-pu: package libdbi-perl/1.642-1+deb10u1

[Xavier]

Le 17/09/2020 à 21:26, Adam D. Barratt a écrit :
> Control: tags -1 + confirmed
> 
> On Sat, 2020-09-12 at 08:50 +0200, Xavier wrote:
>>
> 
> +libdbi-perl (1.642-1+deb10u1) buster; urgency=medium
> +
> +  * Fix memory corruption in XS functions when Perl stack is reallocated
> +(Closes: CVE-2020-14392)
> +  * Fix a buffer overflow on an overlong DBD class name
> +(Closes: CVE-2020-14393)
> +
> + -- Xavier Guimard   Thu, 10 Sep 2020 10:04:13 +0200
> 
> Please go ahead.
> 
> Regards,
> 
> Adam

Hi,

I'm going to try to add also this patch (for CVE-2019-20919:
https://github.com/perl5-dbi/dbi/commit/eca7d7c8f

I'll push a new debdiff after tests

Cheers,
Xavier

Bug#970518: buster-pu: package edk2/0~20181115.85588389-3+deb10u1

[dann frazier]

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

[ Reason ]
I'd like to fix CVE-2019-14562 in edk2 for buster.

[ Impact ]
Vulnerability to an integer overflow when parsing signatures of a specially
crafted PE file.

[ Tests ]
Regression tested only using the autopkgtests from the unstable version
of the package.

[ Risks ]
A regression could break the booting of QEMU-emulated machines.

[ Checklist ]
  [X] *all* changes are documented in the d/changelog
  [X] I reviewed all changes and I approve them
  [X] attach debdiff against the package in (old)stable
  [X] the issue is verified as fixed in unstable

[ Changes ]
Cherry-picks from upstream to resolve CVE-2019-14562.

[ Other info ]
N/A

-- 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.8.0-1-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru edk2-0~20181115.85588389/debian/changelog 
edk2-0~20181115.85588389/debian/changelog
--- edk2-0~20181115.85588389/debian/changelog   2020-04-23 13:33:06.0 
-0600
+++ edk2-0~20181115.85588389/debian/changelog   2020-09-17 13:45:52.0 
-0600
@@ -1,3 +1,13 @@
+edk2 (0~20181115.85588389-3+deb10u2) buster; urgency=medium
+
+  * Fix integer overflow in DxeImageVerificationHandler. (CVE-2019-14562)
+(Closes: #968819)
+ - d/p/0001-SecurityPkg-DxeImageVerificationLib-extract-SecDataD.patch
+ - d/p/0002-SecurityPkg-DxeImageVerificationLib-assign-WinCertif.patch
+ - d/p/0003-SecurityPkg-DxeImageVerificationLib-catch-alignment-.patch
+
+ -- dann frazier   Thu, 17 Sep 2020 13:45:52 -0600
+
 edk2 (0~20181115.85588389-3+deb10u1) buster; urgency=medium
 
   * Fix numeric truncation in S3BootScript[Save]*() API. (CVE-2019-14563)
diff -Nru 
edk2-0~20181115.85588389/debian/patches/0001-SecurityPkg-DxeImageVerificationLib-extract-SecDataD.patch
 
edk2-0~20181115.85588389/debian/patches/0001-SecurityPkg-DxeImageVerificationLib-extract-SecDataD.patch
--- 
edk2-0~20181115.85588389/debian/patches/0001-SecurityPkg-DxeImageVerificationLib-extract-SecDataD.patch
 1969-12-31 17:00:00.0 -0700
+++ 
edk2-0~20181115.85588389/debian/patches/0001-SecurityPkg-DxeImageVerificationLib-extract-SecDataD.patch
 2020-09-17 13:45:52.0 -0600
@@ -0,0 +1,87 @@
+From 503248ccdf45c14d4040ce44163facdc212e4991 Mon Sep 17 00:00:00 2001
+From: Laszlo Ersek 
+Date: Tue, 1 Sep 2020 11:12:19 +0200
+Subject: [PATCH 1/3] SecurityPkg/DxeImageVerificationLib: extract
+ SecDataDirEnd, SecDataDirLeft
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+The following two quantities:
+
+  SecDataDir->VirtualAddress + SecDataDir->Size
+  SecDataDir->VirtualAddress + SecDataDir->Size - OffSet
+
+are used multiple times in DxeImageVerificationHandler(). Introduce helper
+variables for them: "SecDataDirEnd" and "SecDataDirLeft", respectively.
+This saves us multiple calculations and significantly simplifies the code.
+
+Note that all three summands above have type UINT32, therefore the new
+variables are also of type UINT32.
+
+This patch does not change behavior.
+
+(Note that the code already handles the case when the
+
+  SecDataDir->VirtualAddress + SecDataDir->Size
+
+UINT32 addition overflows -- namely, in that case, the certificate loop is
+never entered, and the corruption check right after the loop fires.)
+
+Cc: Jian J Wang 
+Cc: Jiewen Yao 
+Cc: Min Xu 
+Cc: Wenyi Xie 
+Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2215
+Signed-off-by: Laszlo Ersek 
+Message-Id: <20200901091221.20948-2-ler...@redhat.com>
+Reviewed-by: Philippe Mathieu-Daudé 
+Tested-by: Wenyi Xie 
+Reviewed-by: Min M Xu 
+Reviewed-by: Jiewen Yao 
+
+Origin: 
https://github.com/tianocore/edk2/commit/503248ccdf45c14d4040ce44163facdc212e4991
+Bug: https://bugzilla.tianocore.org/show_bug.cgi?id=2215
+Bug-Debian: https://bugs.debian.org/968819
+Last-Update: 2020-09-17
+
+Index: 
edk2/SecurityPkg/Library/DxeImageVerificationLib/DxeImageVerificationLib.c
+===
+--- 
edk2.orig/SecurityPkg/Library/DxeImageVerificationLib/DxeImageVerificationLib.c
 edk2/SecurityPkg/Library/DxeImageVerificationLib/DxeImageVerificationLib.c
+@@ -1658,6 +1658,8 @@ DxeImageVerificationHandler (
+   UINT8*AuthData;
+   UINTNAuthDataSize;
+   EFI_IMAGE_DATA_DIRECTORY *SecDataDir;
++  UINT32   SecDataDirEnd;
++  UINT32   SecDataDirLeft;
+   UINT32  

Bug#970517: openjdk-11 (and openjdk-14 as well): copyright file does not specify the correct source

[Julian Gilbey]

Package: openjdk-11-jdk
Version: 11.0.8+10-1
Severity: serious

Justification: violates a "must" directive in policy section 12.5.

The current /usr/share/doc/openjdk-*/copyright files incorrectly
states that the upstream source is from download.java.net; that has
not been the case for a long time.

The copyright information is also very out of date.

It seems that all of the legal files have already been collected in
/usr/share/doc/openjdk-14-doc/legal (pointing to /usr/lib/jvm);
presumably it would be possible to refer to this directory in the
copyright file?

Best wishes,

   Julian

Bug#937184: Python 3 port of offlineimap underway

[Gaudenz Steinlin]

There is now a Python 3 port of offlineimap underway:
https://github.com/OfflineIMAP/offlineimap/issues/670

AFAICS it looks promising. Please wait with removing from 
unstable.


Gaudenz
--
PGP: 836E 4F81 EFBB ADA7 0852 79BF A97A 7702 BAF9 1EF5


signature.asc
Description: PGP signature

Bug#968991: jlink error: Hash of jdk.management.jfr differs to expected hash

[Julian Gilbey]

On Tue, Aug 25, 2020 at 02:40:43PM +0100, Julian Gilbey wrote:
> [...]
> output (where I have replace the path with QUPATHDIR); the failure
> appears to have happened in the jlink command, which gives the error
> message:
> 
> Error: Hash of jdk.management.jfr 
> (fe13cbaad9132f3aafe8db1febd951ded02ac6f6371c0b1b14fc4fc561ce3b70) differs to 
> expected hash 
> (8f4b914f856e98e19ec589e7c679b7ce7774a3985aa3c0ec79e5f831e0c3eec1) recorded 
> in java.base

It turns out that this bug is identical to the problem reported
against openjdk-11-jdk in https://bugs.debian.org/944738

Any help with this old bug would be much appreciated!

   Julian

Bug#970516: RFS: xbrzscale/1.8-1 [ITP] -- Intelligent graphics file upscaling tool

[Peter]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512


Package: sponsorship-requests
Severity: wishlist


Dear mentors,

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

 * Package name: xbrzscale
   Version : 1.8-1
   Upstream Author : Przemysław Grzywacz 
   : Zenju 
 * URL : https://github.com/atheros/xbrzscale
   : https://sourceforge.net/projects/xbrz/files/xBRZ/
 * License : GPL-3+
   Section : graphics


It builds those binary packages:
  xbrzscale - Intelligent graphics file upscaling tool

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

Alternatively, one can download the package with dget using this command:
  dget -x 
https://mentors.debian.net/debian/pool/main/x/xbrzscale/xbrzscale_1.8-1.dsc

Also, binary packages available via the OBS at
  
https://software.opensuse.org//download.html?project=home%3APeterBBB=xbrzscale


Changes for the initial release:
 xbrzscale (1.8-1) unstable; urgency=medium
 .
   * Initial release. Closes: #969652


Regards,
- --
  Peter Blackman

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEE33HzyvBUkEl4+kj4tty6Zj6hsVAFAl9jwacACgkQtty6Zj6h
sVCgJg//ZGPLRHAD9Is1CnCfbnRSmCMU/NLEmXgLAD53IOCT/twkeFPnQtCfz2e+
kFEUKgH7foryXrD+040ouVvgqTU9TVEKU7xKjj5hlXNvNdLKA1B6u96IAo1PZecj
MpoM9cZ8chJwBMyZvxuV+KzsayQMuPhJo1GJOKkgFByz6IdZw5owHWcdrJv+/sfN
fIkrUu3f2a9tfI3KouZBpfvous5+38E3tylQMxdeOcD05E8fq32oX2tVTqW+zhpg
P7SbRf8o16AFVl9i9+nARtZz8wfrDf7VYKQc6eB7ffNFlBbKcK7hIFVVIt0sqVTW
dKAxnpJ0SECDSMJsMldQUJ5Yy1Lmukh5HhTi/ojEadEIFKvqGVyIm/rb5kjWmMhg
RpSnAyLuV+agSkhIj+/vv2Y+92OGr+IbwRRAjgTRyq5eDEeDsHtZlBAm+ahwJ9DA
VNP4Wdeqhk8811yxjPb6CMl3D/0yOf+BM0ahUAmwGOcb6zAOEhenQOwZ3DJaK+LS
5aEtVvozDyB5aW1dqh6qcqBR8vqSAy2WudptXlf0VxZZIWB+/gnK00x8O+/g3nPz
rIBVr0fcDWAv9u7/eipej/PnfnEvNkwmrVHaWay4BZf6U9JW6w/ZCRhmkUUAxjTl
rdNf1IOKi9HTUQQoAu3tGDAzbvIvz191kjHpkmD99FIqR3MbhFs=
=p14Y
-END PGP SIGNATURE-

Bug#869799:

[Pho Chit]

Bug#968296: buster-pu: calamares-settings-debian 10.0.20-1+deb10u4

[Adam D. Barratt]

On Wed, 2020-08-12 at 17:59 +0200, Jonathan Carter wrote:
> package: release.debian.org
> thanks
> 

Please consider using reportbug in such cases. Or at least setting the
metadata that it would have. It makes things so much easier to find in
the BTS, particularly with the correct usertags.

Regards,

Adam

Bug#970514: p7zip-full: interprets file names with '*' in it in archives

[Marc Lehmann]

Package: p7zip-full
Version: 16.02+dfsg-6
Severity: normal

Dear Maintainer,

when unpacking (zip) archives with filenames containing '*', 7za seems to
interpret at least '*' in filenames in a weird (and worrying) way. For
example, when unpacking the solaris 10u11 recommended patchset zip, I get
this message (neither file existed on the filesystem when running 7za,
both are inside the archive):

   Would you like to replace the existing file:
 Path: 
./10_Recommended/patches/145006-09/SUNWwebminu/reloc/usr/sfw/lib/webmin/ldap-useradmin/config-sol-linux
 Size: 385 bytes (1 KiB)
 Modified: 2014-12-31 20:06:54
   with the file from archive:
 Path: 
10_Recommended/patches/145006-09/SUNWwebminu/reloc/usr/sfw/lib/webmin/ldap-useradmin/config-*-linux
 Size: 416 bytes (1 KiB)
 Modified: 2014-12-31 20:06:54
   ? (Y)es / (N)o / (A)lways / (S)kip all / A(u)to rename all / (Q)uit? (Y)es / 
(N)o / (A)lways / (S)kip all / A(u)to rename all / (Q)uit?

This happens whenever the archive contains filenames with '*' in
them. Obviously, 7za should handle '*' and related characters like any
other valid character in filenames.

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

Kernel: Linux 5.6.19-050619-generic (SMP w/8 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_DK.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 p7zip-full depends on:
ii  libc62.30-4
ii  libgcc-s1 [libgcc1]  10.2.0-6
ii  libgcc1  1:9.2.1-22
ii  libstdc++6   10.2.0-6
ii  p7zip16.02+dfsg-6

p7zip-full recommends no packages.

Versions of packages p7zip-full suggests:
pn  p7zip-rar  

-- no debconf information

Bug#970515: kde-plasma-desktop: Can't switch user in current session

[Max Hofer]

Package: kde-plasma-desktop
Version: 5:106
Severity: normal

Dear Maintainer,

until a couple weeks ago I could switch from the current KDE session to another
user by using a button 'Switch user', which would open a new X session, without
destroying my original KDE session I was on.

I belive (not sure) since the upgrade from 5:105 -> 5:106 this button 
disapeared.

To switch the user I have to leave the current session (logout).

Searching the intenet I found similar bugreport from other Linux distrubutions
(https://www.reddit.com/r/kde/comments/i94khf/suddenly_missing_switch_user_button/).

I seems there is a bug report in upstream: 
https://bugs.kde.org/show_bug.cgi?id=423526

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

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

Versions of packages kde-plasma-desktop depends on:
ii  kde-baseapps  4:20.04.0+5.106
ii  plasma-desktop4:5.17.5-3
ii  plasma-workspace  4:5.17.5-4
ii  udisks2   2.9.1-2
ii  upower0.99.11-2

Versions of packages kde-plasma-desktop recommends:
ii  kwin-x11  4:5.17.5-3
ii  sddm  0.18.1-1
ii  xserver-xorg  1:7.7+20

Versions of packages kde-plasma-desktop suggests:
ii  kdeconnect  20.04.3-1

-- no debconf information

Bug#970132: buster-pu: package rustc/1.41.1+dfsg1-1~deb10u1

[John Paul Adrian Glaubitz]

On 9/17/20 9:33 PM, peter green wrote:
>> I'll take a look, can't promise anything but I've had to deal with similar 
>> issues
>> in raspbian before.
> 
> No, my idea (treat it like a cross-build) didn't work.

Not sure why rustc-1.41 should be a problem, it has built in the past:

> https://buildd.debian.org/status/logs.php?pkg=rustc=armel

I can take a look over the weekend if no one else manages to fix it.

Adrian

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

Bug#969706: buster-pu: package grunt/1.0.1-8+deb10u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Sun, 2020-09-06 at 23:50 +0200, Xavier Guimard wrote:
> grunt is vulnerable to a medium CVE (CVE-2020-7729, #969668)
> 
> [ Impact ]
> The package grunt before 1.3.0 are vulnerable to Arbitrary Code
> Execution due to the default usage of the function load() instead of
> its secure replacement safeLoad() of the package js-yaml inside
> grunt.file.readYAML.

Please go ahead.

Regards,

Adam

Bug#969912: buster-pu: package diaspora-installer/0.7.6.1+debian1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Thu, 2020-09-10 at 00:28 +0530, Pirate Praveen wrote:

+diaspora-installer (0.7.6.1+debian1+deb10u1) buster; urgency=medium
+
+  * Use --frozen option to bundle install to use upstream Gemfile.lock
+  * Don't exclude Gemfile.lock during upgrades
+  * Don't overiwrite config/oidc_key.pem during upgrades
+  * Make config/schedule.yml writeable (Closes: #926968)
+
+ -- Pirate Praveen   Wed, 09 Sep 2020 01:27:58 +0530

Please go ahead.

Regards,

Adam

Bug#970098: buster-pu: package orocos-kdl/1.4.0-7+deb10u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Fri, 2020-09-11 at 18:38 +0200, Jochen Sprickerhof wrote:
> orocos-kdl ships KDLConfig.cmake providing a cmake variable with the
> location of the header files. For Debian this is /usr/include, but
> it's written as ${CMAKE_CURRENT_LIST_DIR}/../../../include. This
> breaks with gcc > 5 and cmake < 3.16 if the path is added as -isystem
> to the compiler.
> This is the case for the ROS packages using orocos-kdl, as discussed
> in
> https://github.com/ros/rosdistro/issues/26526.
> 

Please go ahead.

Regards,

Adam

Bug#970096: buster-pu: package libdbi-perl/1.642-1+deb10u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Sat, 2020-09-12 at 08:50 +0200, Xavier wrote:
> 

+libdbi-perl (1.642-1+deb10u1) buster; urgency=medium
+
+  * Fix memory corruption in XS functions when Perl stack is reallocated
+(Closes: CVE-2020-14392)
+  * Fix a buffer overflow on an overlong DBD class name
+(Closes: CVE-2020-14393)
+
+ -- Xavier Guimard   Thu, 10 Sep 2020 10:04:13 +0200

Please go ahead.

Regards,

Adam

Bug#970307: buster-pu: package node-mysql/2.16.0-1+deb10u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Mon, 2020-09-14 at 16:04 +0200, Xavier Guimard wrote:
> [ Reason ]
> node-mysql is vulnerable to CVE-2019-14939 (#934712)
> 
> [ Impact ]
> Default "LOAD DATA LOCAL INFILE" is too permissive
> 
> [ Tests ]
> Sadly tests were not enabled in buster
> 

I think the intention is also to describe how the patch was tested. :-)

Please go ahead.

Regards,

Adam

Bug#970349: buster-pu: package icinga2/2.10.3-2+deb10u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Tue, 2020-09-15 at 07:39 +0200, Bas Couwenberg wrote:
> icinga2 is buster is affected by CVE-2020-14004 as reported in
> #970252.
> 

Please go ahead.

Regards,

Adam

Bug#969349: buster-pu: package chrony/3.4-4+deb10u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Wed, 2020-09-16 at 14:54 +0200, Vincent Blut wrote:
> Hi,
> 
> On 2020-08-31T21:34+0200, Vincent Blut wrote:
[...]
> > chrony versions prior to 3.5.1 are vulnerable to a symlink race
> > when creating the PID file. CVE-2020-14367 has been assigned to
> > this vulnerability.
[...]
> In the meantime, Matt Corallo encountered a limitation in our
> AppArmor profile, which prevents the use of the “tempcomp” directive
> (#970421).
> 

Please go ahead.

Regards,

Adam

Bug#961843: buster-pu: package lighttpd/1.4.53-4

[Adam D. Barratt]

Control: tags -1 -moreinfo +confirmed

On Tue, 2020-06-02 at 09:16 +0200, Helmut Grohne wrote:
> Hi SRMs and Glenn,
> 
> On Sat, May 30, 2020 at 04:44:34AM -0400, Glenn Strauss wrote:
> > Greetings!  I am an upstream maintainer of lighttpd.
> > 
> > Please accept this backport of important patches from
> >   lighttpd 1.4.54 (released 2019.05.27)
> >   lighttpd 1.4.55 (released 2020.01.31)
> > 
> > The patches to backport have been hand-selected from the release
> > available in buster-backports lighttpd 1.4.55-1~bpo10+1 since
> > 2020.03.06
> > 
> > These patches fix important bugs from upstream lighttpd issue
> > tracker
> >   https://redmine.lighttpd.net/issues  (direct links below)
> > including a couple in the Debian Bug Tracker
> >   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=954759
> >   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=929203
> 
> I'm an uploader of the lighttpd Debian package and I second Glenn's
> request. I intend to perform this upload once there is an SRM ack.

Please go ahead.

Regards,

Adam

Bug#878875: [Pkg-javascript-devel] Packaging twemoji

[Felix Natter]

Jonas Smedegaard  writes:

> Hi Felix,

hi Jonas,
hi Debian-js,

> Quoting Felix Natter (2020-08-08 10:41:53)
>> hello Debian-js,
>>
>> I would like to package twemoji (SVGs for unicode emojis) [1], and I
>> think debian-js is the right team for this.
>>
>> However, I consider packaging only the SVGs and not the javascript code,
>> because that's all I need for the freeplane package, and the RFP author
>> Dominik (CC:) did not reply to my query (see #878875).
>>
>> What do you think, is Debian-js the right place for this, and do you
>> need the javascript code?
>
> You are most welcome to maintain twemoji in the JavaScript team and I
> agree that seems a good place to do it, given that upstream build
> framework seem tied to Node.js.  Other options you might consider are
> the fonts team and DebianArt (if the latter is a team, not sure about
> that: Maybe ask Valessio Brito directly).
>
> When packaging it, then yes, please package it reusable for other
> projects as well - that's an important attitude of Debian packaging.
> This (from a quick look) indeed seems to mean include the javascript,
> not only SVGs.  But maybe consult the fonts teams on that - they
> maintain several fonts where upstream ship Javascript stuff as well.
>
> Speaking of SVGs, are you sure this is the real source of those SVG
> files? It seems amchine-generated to me, and I suspect there is real
> concern as to freedom aspects of distributing only as provided here.
> Even if you choose to use the JavaScript team as platform for your
> package maintenance, I recommend that you discuss the issue of source of
> fonts with the font team, as there is collected quite some knowledge and
> experience in that team.

Finally I got a response from twitter (Justine De Caires
):

"The original sources are indeed the SVG files. When we update the package
with new emojis, I'm given SVG files by the designers, so there aren't any
AI files to be had anymore."

Now that this is resolved, can someone add me to Debian-js [1] (I am part of
Debian-java already), create a salsa repository for twemoji and maybe
suggest a similar package?

[1] I couldn't find a way to apply here:
https://salsa.debian.org/groups/js-team/-/group_members

> Hmm, maybe the fonts team would be a better place after all.  Not
> sure...

I'll let you decide.

> Good luck with the project - seems a great resource to have in Debian!

Many Thanks and Best Regards,
Felix
--
Felix Natter

Bug#970493: src:laptop-mode-tools: fails to migrate to testing for too long: maintainer built arch:all binaries

[Paul Gevers]

Hi Ritesh,

On 17-09-2020 16:45, Ritesh Raj Sarraf wrote:
> So, since you've already made the delayed upload, I don't have to act
> on anything. If so, thanks for taking care of this.

Correct.

On the other hand, personally I would love to not be the uploader of
tens of packages that I don't have a relation with. So if there's
anything, however minor, that you'd want to fix in the package, now is a
good time to upload it and avoid tagging me as an uploader of your package.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#970513: autopkgtest should gain arch support

[Paul Gevers]

Package: autopkgtest

On Sun, 13 Sep 2020 19:21:11 +0100 Ben Hutchings 
wrote:
> On Sat, 2020-09-12 at 15:59 +0100, Simon McVittie wrote:
> > Please add "Restrictions: skip-not-installable" to the amd64-* tests, so
> > that they will be skipped if the test-dependencies are uninstallable.
> [...]
> 
> I will do that, though what I really would like is for autopkgtests to
> support an Architecture field for tests.

I agree, so lets file a bug against the autopkgtest package to ask for
such a feature.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#944738: jlink: Hash of module differs to expected hash recorded in java.base

[Julian Gilbey]

affects 944738 openjdk-14-jdk
thanks

On Wed, Aug 19, 2020 at 10:02:05PM -0700, Bill Zaumen wrote:
> I just ran into a similar problem:
> 
> jlink --add-modules java.desktop --output test
> 
> fails with this message:
> 
> Error: Hash of java.xml
> (19574d688f234255aab0ff4ff8e88ae8190ecd7c8d2c422fbdb31cc10963b383)
> differs to expected hash
> (4473ef1f3d22979bd9136b21a520907553e3874435d88321999370312f1a)
> recorded in java.base
> [...]

The same problem is still present in openjdk-14 - see
https://bugs.debian.org/968991

Best wishes,

   Julian

Bug#970512: endlessh: Can not bind to port under 1024

[Heikki Levanto]

Package: endlessh
Version: 1.1-1~bpo10+1
Severity: normal

Dear Maintainer,

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

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
  -> Added a config file specifying Port 222
   * What was the outcome of this action?
  -> endlessh refuses to start. "Permission denied"
   * What outcome did you expect instead?
  -> Normal start, listening on port 222

I got around this by listening on , and forwarding things in my firewall.

Running endlessh manually from the command line, it could bind on 222 all right.
I suspect this has something to do with the way systemd starts the process.



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


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

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

Versions of packages endlessh depends on:
ii  init-system-helpers  1.56+nmu1
ii  libc62.28-10

endlessh recommends no packages.

endlessh suggests no packages.

-- no debconf information

Bug#969136: xserver-xorg-video-amdgpu: Xserver keeps crashing inside of /usr/lib/xorg/modules/drivers/amdgpu_drv.so

[Julien Cristau]

Control: found -1 20.1.7-1
Control: forwarded -1 https://gitlab.freedesktop.org/mesa/mesa/-/issues/3533

On Thu, Sep 17, 2020 at 09:21:02AM -0700, Phil Dibowitz wrote:
> Upstream bug: https://gitlab.freedesktop.org/mesa/mesa/-/issues/3533
> 
Thanks!

Cheers,
Julien

Bug#886419: systray-mdstat: complains at startup, despite everything appears to be fine

[Francesco Poli]

On Thu, 17 Sep 2020 01:13:06 +0200 Axel Beckert wrote:

[...]
> Francesco Poli wrote:
[...]
> > Well, I would call it a dialog window, since I have to click on the OK
> > button, in order to (cleanly) close it...
> > Please see the attached screenshot (or, rather, "windowshot").
> 
> Ok, I guess that's heavily depending on the notifyd being used. I've
> seen notification in many different styles. There are e.g. GNOME and
> KDE on the fancy side and dunst on the very simplistic side.

I this can be useful to know, I use Fluxbox...

> 
> The content is what I'd expect in a notification.
> 
> And yes, upon start it shows you the current state. Maybe I should add
> an option or so to disable this.

It could be nice, but it's not on the top of my priority list...

[...]
> > By looking at the code, it seems that the complaint is generated
> > because some exception is caught:
[...]
> > Does this ring some bell?
> 
> Not really. Load of the code is borrowed from code examples of the
> libraries or from fdpowermon and tweaked until it did what I wanted.
> So I don't have really an idea what exactly
> "Glib::Object::Introspection->setup" does and which reasons may exist
> for it to fail. I just know it's needed to make this run.

Well, that seems to be the direction in which the investigation has to
be pushed...

[...]
> > Please ping me, when the new version is in Debian testing (or, at
> > least, in unstable): I will give it a try.
> 
> Will do.

Thanks.


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


pgpXEimfFX0Xq.pgp
Description: PGP signature

Bug#969136: xserver-xorg-video-amdgpu: Xserver keeps crashing inside of /usr/lib/xorg/modules/drivers/amdgpu_drv.so

[Phil Dibowitz]

On 9/17/20 5:56 AM, Julien Cristau wrote:
> Which version of libgl1-mesa-dri is this on?

[phil@rider ~]$ dpkg -l libgl1-mesa-dri
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)
||/ Name  Version  Architecture Description
+++-=--->
ii  libgl1-mesa-dri:amd64 20.1.7-1 amd64free implementation
of the OpenG>
ii  libgl1-mesa-dri:i386  20.1.7-1 i386 free implementation
of the OpenG>


BTW I picked amdgpu because of:

>> [ 72995.802] (EE) 11: /usr/lib/xorg/modules/drivers/amdgpu_drv.so
(?+0x0) [0x7f880313d650]

> If you're still seeing this on the latest version it would probably be
> good to report at https://gitlab.freedesktop.org/mesa/mesa/-/issues for
> the mesa devs to take a look.

Several. Times. A. Day.

I'll file an upstream bug, thanks.

-- 
Phil Dibowitz p...@ipom.com
Open Source software and tech docsInsanity Palace of Metallica
http://www.phildev.net/   http://www.ipom.com/

"Be who you are and say what you feel, because those who mind don't
 matter and those who matter don't mind."
 - Dr. Seuss

Bug#969136: xserver-xorg-video-amdgpu: Xserver keeps crashing inside of /usr/lib/xorg/modules/drivers/amdgpu_drv.so

[Phil Dibowitz]

Ooops, accidentally replied to Julien instead of bugs.

On 9/17/20 5:56 AM, Julien Cristau wrote:
> Which version of libgl1-mesa-dri is this on?

[phil@rider ~]$ dpkg -l libgl1-mesa-dri
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)
||/ Name  Version  Architecture Description
+++-=--->
ii  libgl1-mesa-dri:amd64 20.1.7-1 amd64free implementation
of the OpenG>
ii  libgl1-mesa-dri:i386  20.1.7-1 i386 free implementation
of the OpenG>

BTW I picked amdgpu because of:

>> [ 72995.802] (EE) 11: /usr/lib/xorg/modules/drivers/amdgpu_drv.so
(?+0x0) [0x7f880313d650]

> If you're still seeing this on the latest version it would probably be
> good to report at https://gitlab.freedesktop.org/mesa/mesa/-/issues for
> the mesa devs to take a look.

It happens several times a day.

Upstream bug: https://gitlab.freedesktop.org/mesa/mesa/-/issues/3533


-- 
Phil Dibowitz p...@ipom.com
Open Source software and tech docsInsanity Palace of Metallica
http://www.phildev.net/   http://www.ipom.com/

"Be who you are and say what you feel, because those who mind don't
 matter and those who matter don't mind."
 - Dr. Seuss

Bug#970511: cvc4: test failures on various architectures

[Fabian Wolff]

Source: cvc4
Version: 1.8-1
Severity: important

CVC4 1.8-1 fails to build on several release architectures due to a
few test case failures [0]. I have reported the issue upstream [1].

I am going to reupload the cvc4 package soon with the test cases in
question disabled, as a temporary solution, and I'm opening this bug
report to remain aware of the problem.

[0] https://buildd.debian.org/status/logs.php?pkg=cvc4=1.8-1
[1] https://github.com/CVC4/CVC4/issues/5082

Bug#970510: why3: does not work with current version of cvc4

[Fabian Wolff]

Package: why3
Severity: important

Dear maintainer,

this seems to be the same issue as #942344, just this time it's cvc4
instead of z3: share/provers-detection-data.conf lists CVC4 versions
up to 1.7, but the current version is 1.8, so the autopkgtests for
why3 fail.

Best regards,
Fabian

Bug#970509: ldh-gui-suite: [INTL:de] updated German debconf translation

[Helge Kreutzmann]

Package: ldh-gui-suite
Version: 0.1~20200908-1
Severity: wishlist
Tags: patch l10n

Please find the updated German debconf translation for ldh-gui-suite
attached.

Please place this file in debian/po/ as de.po for your next upload.

If you update your template, please use 
'msgfmt --statistics '
to check the po-files for fuzzy or untranslated strings.

If there are such strings, please contact me so I can update the 
German translation.

Greetings
Helge
# SOME DESCRIPTIVE TITLE.
# Copyright (C) YEAR THE PACKAGE'S COPYRIGHT HOLDER
# This file is distributed under the same license as the ldh-gui-suite package.
# Helge Kreutzmann , 2019.
#
msgid ""
msgstr ""
"Project-Id-Version: ldh-gui-suite 0.1~20200908-1\n"
"Report-Msgid-Bugs-To: ldh-gui-su...@packages.debian.org\n"
"POT-Creation-Date: 2020-09-09 13:28+0200\n"
"PO-Revision-Date: 2020-09-17 17:58+0200\n"
"Last-Translator: Helge Kreutzmann \n"
"Language-Team: German \n"
"Language: de\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"

#. Type: string
#. Description
#. Translators, please do NOT translate 'Liberty Deckplan Host' which is
#. a specific concept defined at 
#: ../templates:1001
msgid ""
"The \"Liberty Deckplan Host\" (LDH) is a single domain implementing the "
"concrete configuration plan defined at ."
msgstr ""
"Der »Liberty Deckplan Host« (LDH) ist eine einzelne Domain, die den unter "
" definierten konkreten "
"Konfigurationsplan implementiert."

#. Type: string
#. Description
#: ../templates:1001
msgid ""
"This name will also be used by other programs. It should be the single, "
"fully qualified domain name (FQDN)."
msgstr ""
"Dieser Name wird auch von anderen Programmen verwandt. Er sollte ein "
"einfacher, vollständig qualifizierter Domain-Name (FQDN) sein."

#. Type: string
#. Description
#. Type: string
#. Description
#. Type: string
#. Description
#. Type: string
#. Description
#. Type: string
#. Description
#: ../templates:1001 ../templates:2001 ../templates:3001 ../templates:4001
#: ../templates:5001
msgid ""
"Leave blank to use a default value (currently \"${defaultvalue}\"), and to "
"permit eventual automatic change of that value without asking."
msgstr ""
"Um den Vorgabewert (derzeit »${defaultvalue}«) zu verwenden, lassen Sie ihn "
"leer und erlauben schließlich die automatische Änderung des Wertes ohne "
"Rückfrage."

#. Type: string
#. Description
#. Translators, please do NOT translate 'Liberty Deckplan Host' or 'Hub'
#. which are specific concepts defined at
#. 
#: ../templates:2001
msgid "Descriptive name for Liberty Deckplan Host service Hub:"
msgstr "Beschreibender Name für den »Liberty Deckplan Host«-Dienste-Hub:"

#. Type: string
#. Description
#. Translators, please do NOT translate 'Liberty Deckplan Host' or 'Hub'
#. which are specific concepts defined at
#. 
#: ../templates:2001
msgid "\"Hub\" is a service to manage your Liberty Deckplan Host account."
msgstr ""
"»Hub« ist ein Dienst, um Ihr »Liberty Deckplan Host«-Konto zu verwalten."

#. Type: string
#. Description
#: ../templates:2001
msgid ""
"This descriptive name will also be used by other programs. It should be a "
"short string usable within a longer description sentence."
msgstr ""
"Dieser beschreibende Name wird auch durch andere Programme verwandt. Er "
"sollte eine kurze Zeichenkette sein, die innerhalb eines längeren "
"beschreibenden Satzes verwandt werden kann."

#. Type: string
#. Description
#. Translators, please do NOT translate 'Liberty Deckplan Host' or 'Hub'
#. which are specific concepts defined at
#. 
#: ../templates:3001
msgid "URI for Liberty Deckplan Host service Hub:"
msgstr "URI für »Liberty Deckplan Host«-Dienste-Hub:"

#. Type: string
#. Description
#. Translators, please do NOT translate 'Liberty Deckplan Host' or 'Hub'
#. which are specific concepts defined at
#. 
#: ../templates:3001
msgid ""
"\"Hub\" is a service to manage your Liberty Deckplan Host account, online "
"accessible at this URI."
msgstr ""
"»Hub« ist ein Dienst, um Ihr »Liberty Deckplan Host«-Konto zu verwalten, das "
"online unter dieser URI erreichbar ist."

#. Type: string
#. Description
#. Type: string
#. Description
#. Type: string
#. Description
#: ../templates:3001 ../templates:4001 ../templates:5001
msgid ""
"This URI will also be used by other programs. It should be the single "
"Uniform Resource Identifier (URI)."
msgstr ""
"Diese URI wird auch durch andere Programme verwandt. Sie sollte der "
"einheitliche Bezeichner für Ressourcen (URI) sein."

#. Type: string
#. Description
#. Translators, please do NOT translate 'Liberty Deckplan Host' or
#. 'Chat' which are specific concepts defined at
#. 

Bug#969174: firefox: FF80 seems to have broken all add-ons on existing profiles

[Antoine Le Gonidec]

I think the severity of this bug should be upped to at least "important".

The reasoning here is that any privacy-related add-on installed through Debian 
repositories is automatically (and silently) disabled on launch, leading to 
privacy leaks when opening a link in Firefox from another application (like a 
mail client or a chat application). So the issues related to this bug are not 
limited to quality of life, they can have a real impact on user privacy and 
could hurt the trust users have for the Debian-packaged versions of Firefox and 
WebExtensions.

Bug#970132: buster-pu: package rustc/1.41.1+dfsg1-1~deb10u1

[peter green]

On 17/09/2020 15:06, Emilio Pozuelo Monfort wrote:

On 12/09/2020 11:09, Emilio Pozuelo Monfort wrote:

This updates buster's rustc to 1.41, as needed by the new firefox 78 ESR.
The bootstrap happens with the upstream binaries as we've done in the past.
I have also avoided the bump to LLVM 9/10, we use buster's LLVM 7 instead.


The updated rustc is in buster-proposed-updates now, but it failed to build for
armel. Looks like my change to debian/architecture.mk to use
arm-unknown-linux-gnueabi rather than armv5te-unknown-linux-gnueabi broke this a
bit. The reason for that change was that there were no armv5te binaries
upstream, and the arm ones are ARMv5 so should be good to bootstrap rustc on
armel. However, rustc now defaults to ARMv6 for arm-unknown-linux-gnueabi (see
vendor/cc/src/lib.rs), which could be causing some issues. Or perhaps the issue
lies elsewhere.

Anyway my attempts at getting rustc 1.41 bootstrapped on armel have failed so
far (I have tried to lower that -march to armv5te, and also attempted to build
for armv5te-unknown-linux-gnueabi while using the arm-unknown-linux-gnueabi
binaries). Any help from the armel porters would be appreciated.


I'll take a look, can't promise anything but I've had to deal with similar 
issues
in raspbian before.

Bug#970507: chezscheme-doc: trying to overwrite '/usr/lib/csv9.5.4/ta6le/chezscheme.boot', which is also in package chezscheme 9.5.4+dfsg-2

[Axel Beckert]

Hi,

Axel Beckert wrote:
> Upgrading chezscheme-doc (with chezscheme also being installed and
> already upgraded to 9.5.4+dfsg-2) fails for me as follows:

Small correction: It seems as if it was an installation and not an
upgrade of chezscheme-doc (due being suggested by chezscheme) after
chezscheme has been upgraded to 9.5.4+dfsg-2.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#969529: (no subject)

[Salvatore Bonaccorso]

Hi,

On Thu, Sep 17, 2020 at 03:11:43PM +0200, Mattia Rizzolo wrote:
> A note, that ubuntu links to a different commit (the same that is
> recorded at mitre).
> 
> https://bugs.launchpad.net/debian/+source/libxml2/+bug/1895839

Well I believe that is not correct, that was the commit it was tested
when reporting the issue but not actually beeing the fixing commit.

The upstream report
https://gitlab.gnome.org/GNOME/libxml2/-/issues/178 contains useful
information, though which leads to
https://gitlab.gnome.org/GNOME/libxml2/-/commit/50f06b3efb638efb0abd95dc62dca05ae67882c2
as the fixing commit for the underlying issue in xmlint.

Hope this make sense.

Regards,
Salvatore

Bug#946035: Request fo sponsor to uplad python-jsonrpc-server

[Pablo Mestre]

Now is updated...

Hope would be ready for upload.


Pablo

-- 
  ⢀⣴⠾⠻⢶⣦⠀  Pablo Mestre Drake
  ⣾⠁⢠⠒⠀⣿⡁  --
  ⢿⡄⠘⠷⠚⠋   https://debian.org
  ⠈⠳⣄  Debian, the universal operating system.

Bug#948739: Bug #948739: gparted should not mask .mount units

[Phillip Susi]

Just wanted to note in this copy of the bug that the recommendation from
upstream systemd was that gparted should not be masking mounts but
instead should take a bsd lock on the device to prevent auto mounts.

Bug#970474: Package: installation-reports - FAILURE

[Doug Smythies]

Holger wrote:

> This issue has been fixed shortly, latest dailies should be fine again.

Tested daily for 2020.09.17.
Confirmed, fixed.
Note: I did not do a complete installation, as I did not want to overwrite
My work from yesterday. I only went to the next step past the issue.

Bug#969789: RFS: elfio/3.7-1 [ITP] -- C++ library for reading and generating ELF files

[Serge Lamikhov-Center]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

 * Package name: elfio
   Version : 3.7-1
   Upstream Author : Serge Lamikhov-Center 
 * URL : http://serge1.github.io/ELFIO
 * License : Expat
 * Vcs : https://github.com/serge1/ELFIO
   Section : devel

It builds those binary packages:

  elfio - C++ library for reading and generating ELF files

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

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

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

  dget -x https://mentors.debian.net/debian/pool/main/e/elfio/elfio_3.7-1.dsc

Changes for the initial release:

 elfio (3.7-1) unstable; urgency=medium
 .
   * Initial release (Closes: #839382)
   * 'watch' file has been updated
   * Passes lintian check with command line:
 lintian --profile debian -i -I --show-overrides elfio_3.7-1_amd64.changes \
   --profile debian

Initially, the package was requested as a dependency for Apache Mesos (#839382).
The library is used by many processor design companies, academic institutions, 
performance
researchers.
FreeBSD OS already packages the library.

Regards,
--
  Serge Lamikhov-Center

Bug#970444: Can't connect to httpd stream on MPD

[James Klaas]

On 9/17/20, kaliko  wrote:
> Hi James
>
> On 16/09/2020 à 19:28, James Klaas wrote :
>> […]
>> root@myhost:~# service mpd stop
>> root@myhost:~# service mpd start
>> root@myhost:~# curl http://192.168.144.122:8000
>> curl: (7) Failed to connect to 192.168.144.122 port 8000: Connection
>> refused
>>
>> I tried other commands you mentioned:
>>
>> […]
>> root@myhost:/etc/cron.weekly# lsof -Pan -p 10880 -i
>> COMMAND   PID USER   FD   TYPEDEVICE SIZE/OFF NODE NAME
>> mpd 10880  mpd4u  IPv6 114131524  0t0  TCP *:6600 (LISTEN)
>>
>> root@myhost:/etc/cron.weekly# ss -antlp | grep mpd
>> LISTEN0 5*:6600
>> *:*users:(("mpd",pid=10880,fd=4),("systemd",pid=1,fd=108))
>>
>> I greped for mpd since the list of services is quite large. I wanted
>> to check there was nothing conflicting on port 8000:
>>
>> root@myhost:~# ss -antlp  | grep 8000
>
> Well it looks like MPD is listening on :6600 only (is it playing
> something?).
>
>> I don't see anything odd in the logs, when set to verbose:
>>
>> Sep 14 16:12 : zeroconf: No global port, disabling zeroconf
>> Sep 14 16:12 : state_file: Loading state file /var/lib/mpd/state
>> Sep 14 16:13 : client: [0] opened from 192.168.47.122:57198
>> Sep 14 16:13 : client: [0] malformed command "GET / HTTP/1.1"
>> Sep 14 16:13 : client: [0] closed
>> Sep 14 16:20 : client: [1] opened from local
>> Sep 14 16:20 : client: [1] process command "outputs"
>> Sep 14 16:20 : client: [1] command returned 0
>> Sep 14 16:20 : client: [1] closed
>
>
>> I tried adding port 8000 to /lib/systemd/system/mpd.socket under the
>> "[Socket]" section and ran "systemctl daemon-reload". But that seems
>> to only expose the socket to port 8000.
>>
>> Is another section needed in /lib/systemd/system/mpd.socket to open up
>> 8000 to the httpd server in mpd?
>
> Systemd socket activation is meant to launch MPD "on demand" when a client
> tries to
> connect on port 6600. IMO, you don't need to add 8000 here.
>
> HTTP output is set in the conf, something like:
>
>  /etc/mpd.conf ---8<---
>
> audio_output {
> type"httpd"
> port"8000"
> enabled "yes"
> ...
> }
>
> ->8---
>
> Also, you need to start playing something for MPD to listen on the HTTPD
> port.
>
> Please paste your MPD config as well.
>
> k.
>
>

Hrm. I didn't have 'enabled "yes"' as an option. I added that, but it
didn't make a difference.

So, you say

> Also, you need to start playing something for MPD to listen on the HTTPD port

but I can't even get there. Unless something has changed the way I
start things up is to run

mpc add http://192.168.47.122:8000
mpc play

Maybe I'm missing something simple. Perhaps we're getting somewhere
here though. When I attempt to play on the host machine or specifying
the host machine nothing seems to happen.

mpc play

on the local host or

mpc -h 192.168.47.122 play

doesn't seem to do anything.

Here are the verbose logs from mpd when attempt to "play":

Sep 17 10:48 : client: [0] opened from local
Sep 17 10:48 : client: [0] process command "play"
Sep 17 10:48 : client: [0] command returned 0
Sep 17 10:48 : client: [0] process command list
Sep 17 10:48 : client: process command "status"
Sep 17 10:48 : client: command returned 0
Sep 17 10:48 : client: process command "currentsong"
Sep 17 10:48 : client: command returned 0
Sep 17 10:48 : client: [0] process command list returned 0
Sep 17 10:48 : client: [0] closed
Sep 17 10:49 : client: [1] opened from local
Sep 17 10:49 : client: [1] process command list
Sep 17 10:49 : client: process command "status"
Sep 17 10:49 : client: command returned 0
Sep 17 10:49 : client: process command "currentsong"
Sep 17 10:49 : client: command returned 0
Sep 17 10:49 : client: [1] process command list returned 0
Sep 17 10:49 : client: [1] closed

Here's the output from "mpc stats", so I know there are songs to play:

Artists:317
Albums: 393
Songs: 3289

Play Time:0 days, 0:00:00
Uptime:   0 days, 0:02:05
DB Updated:   Thu Sep 17 10:41:23 2020
DB Play Time: 28 days, 17:57:48

Here's my mpd.conf file:

# An example configuration file for MPD.
# Read the user manual for documentation: http://www.musicpd.org/doc/user/
# or /usr/share/doc/mpd/user-manual.html


# Files and directories ###
#
# This setting controls the top directory which MPD will search to discover the
# available audio files and add them to the daemon's online database. This
# setting defaults to the XDG directory, otherwise the music directory will be
# be disabled and audio files will only be accepted over ipc socket (using
# file:// protocol) or streaming files over an accepted protocol.
#
#music_directory"/var/lib/mpd/music"
music_directory "/var/lib/mythtv/music"

#
# This setting sets the MPD internal playlist directory. The purpose of this
# directory is storage for playlists 

Bug#970508: dialog: --aspect and --tab-len options don't work

[Rainer Weikusat]

Package: dialog
Version: 1.3-20190211-ca-003-1
Severity: normal
Tags: patch upstream

The --aspect and --tab-len options are processed in the process_common_options 
subroutine called from main. The code changes the corresponding members of the 
dialog_state structure. After this has happened, the code in main calls then
init_dialog routine which unconditionally sets both the aspect ratio and the
tab len to its default value, thereby overwriting any changes which happened
as part of options processing.

The patch fixes this by changing the init_dialog code such that it only sets
these members to their default values if they don't have a value already (ie,
if their value is 0). It also removes a redundant "set aspect ratio to default
if still 0" statement from process_common_options.

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

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

Versions of packages dialog depends on:
ii  debianutils   4.8.6.1
ii  libc6 2.28-10
ii  libncursesw6  6.1+20181013-2+deb10u2
ii  libtinfo6 6.1+20181013-2+deb10u2

dialog recommends no packages.

dialog suggests no packages.

-- no debconf information
diff --git a/dialog.c b/dialog.c
index b6fa6d4..6ec740d 100644
--- a/dialog.c
+++ b/dialog.c
@@ -1827,9 +1827,6 @@ process_common_options(int argc, char **argv, int offset, 
bool output)
offset++;
 }
 
-if (dialog_state.aspect_ratio == 0)
-   dialog_state.aspect_ratio = DEFAULT_ASPECT_RATIO;
-
 return offset;
 }
 
diff --git a/util.c b/util.c
index 64b67d9..e0a5938 100644
--- a/util.c
+++ b/util.c
@@ -322,8 +322,10 @@ init_dialog(FILE *input, FILE *output)
 setlocale(LC_ALL, "");
 
 dialog_state.output = output;
-dialog_state.tab_len = TAB_LEN;
-dialog_state.aspect_ratio = DEFAULT_ASPECT_RATIO;
+if (dialog_state.tab_len == 0)
+dialog_state.tab_len = TAB_LEN;
+if (dialog_state.aspect_ratio == 0)
+dialog_state.aspect_ratio = DEFAULT_ASPECT_RATIO;
 #ifdef HAVE_COLOR
 dialog_state.use_colors = USE_COLORS;  /* use colors by default? */
 dialog_state.use_shadow = USE_SHADOW;  /* shadow dialog boxes by 
default? */

Bug#970493: src:laptop-mode-tools: fails to migrate to testing for too long: maintainer built arch:all binaries

[Ritesh Raj Sarraf]

Hello Paul,

So, since you've already made the delayed upload, I don't have to act
on anything. If so, thanks for taking care of this.

Ritesh

On Thu, 2020-09-17 at 10:30 +0200, Paul Gevers wrote:
> 
> Your package is only blocked because the arch:all binary package(s)
> aren't built on a buildd. Unfortunately the Debian infrastructure
> doesn't allow arch:all packages to be properly binNMU'ed. Hence, I
> will
> shortly do a no-changes source-only upload to DELAYED/15, closing
> this
> bug. Please let me know if I should delay or cancel that upload.
> 
> Paul
> 
-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System


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

Bug#970507: chezscheme-doc: trying to overwrite '/usr/lib/csv9.5.4/ta6le/chezscheme.boot', which is also in package chezscheme 9.5.4+dfsg-2

[Axel Beckert]

Package: chezscheme-doc, chezscheme
Severity: serious
Version: 9.5.4+dfsg-2

Upgrading chezscheme-doc (with chezscheme also being installed and
already upgraded to 9.5.4+dfsg-2) fails for me as follows:

Preparing to unpack .../chezscheme-doc_9.5.4+dfsg-2_all.deb ...
Unpacking chezscheme-doc (9.5.4+dfsg-2) ...
dpkg: error processing archive 
/var/cache/apt/archives/chezscheme-doc_9.5.4+dfsg-2_all.deb (--unpack):
 trying to overwrite '/usr/lib/csv9.5.4/ta6le/chezscheme.boot', which is also 
in package chezscheme 9.5.4+dfsg-2
Errors were encountered while processing:
 /var/cache/apt/archives/chezscheme-doc_9.5.4+dfsg-2_all.deb

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

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

Bug#970506: ITP: node-deepmerge -- Node.js module to merge properties of two objects deeply

[Xavier Guimard]

Package: wnpp
Severity: wishlist
Owner: Xavier Guimard 
X-Debbugs-Cc: debian-de...@lists.debian.org, 
pkg-javascript-de...@lists.alioth.debian.org

* Package name: node-deepmerge
  Version : 4.2.2
  Upstream Author : Josh Duff 
* URL : https://github.com/TehShrike/deepmerge
* License : Expat
  Programming Lang: JavaScript
  Description : Node.js module to merge properties of two objects deeply

deepmerge is a node.js module written to deep (recursive) merge Javascript
objects.

It is required to update node-rollup-plugin* packages, especially
node-rollup-node-resolve.

Bug#970132: buster-pu: package rustc/1.41.1+dfsg1-1~deb10u1

[Emilio Pozuelo Monfort]

On 12/09/2020 11:09, Emilio Pozuelo Monfort wrote:
> This updates buster's rustc to 1.41, as needed by the new firefox 78 ESR.
> The bootstrap happens with the upstream binaries as we've done in the past.
> I have also avoided the bump to LLVM 9/10, we use buster's LLVM 7 instead.

The updated rustc is in buster-proposed-updates now, but it failed to build for
armel. Looks like my change to debian/architecture.mk to use
arm-unknown-linux-gnueabi rather than armv5te-unknown-linux-gnueabi broke this a
bit. The reason for that change was that there were no armv5te binaries
upstream, and the arm ones are ARMv5 so should be good to bootstrap rustc on
armel. However, rustc now defaults to ARMv6 for arm-unknown-linux-gnueabi (see
vendor/cc/src/lib.rs), which could be causing some issues. Or perhaps the issue
lies elsewhere.

Anyway my attempts at getting rustc 1.41 bootstrapped on armel have failed so
far (I have tried to lower that -march to armv5te, and also attempted to build
for armv5te-unknown-linux-gnueabi while using the arm-unknown-linux-gnueabi
binaries). Any help from the armel porters would be appreciated.

Thanks,
Emilio

Bug#970505: ITP: vast -- network telemetry engine for data-driven security investigations

[Sascha Steinbiss]

Package: wnpp
Severity: wishlist
Owner: Sascha Steinbiss 

* Package name: vast
  Version : 2020.08.28
  Upstream Author : Tenzir GmbH 
* URL : https://github.com/tenzir/vast
* License : BSD-3-clause
  Programming Lang: C++
  Description : network telemetry engine for data-driven security 
investigations

VAST is a distributed platform for high-performance network forensics and
incident response that provides both continuous ingestion of voluminous event
streams and interactive query performance.

VAST leverages a native implementation of the actor model to scale both
intra-machine across available CPU cores, and inter-machine over a cluster of
commodity systems.

Bug#968324: Provide /usr/bin/python

[Norbert Preining]

Package: python3-minimal
Version: 3.8.2-3
Followup-For: Bug #968324
X-Debbugs-Cc: norb...@preining.info

Hi,

I am interested in bringing this up again. I have read through the
relevant threads on debian-python, and I consider this a gross
mis-decision to not ship /usr/bin/python. The reasons are the wide
variety of third party scripts that rely on an interpreter.
Most of third party scripts are already using Python3, so pointing
/usr/bin/python -> python3 is the correct way forward. Not providing
/usr/bin/python superficially breaks lots of scripts.

The counter-argument is that some scripts might be written for Python 2
- well, let only **those** break instead of all. 

Best

Norbert


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

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

Versions of packages python3-minimal depends on:
ii  dpkg   1.20.5
ii  python3.8-minimal  3.8.6~rc1-2

python3-minimal recommends no packages.

python3-minimal suggests no packages.

-- no debconf information

Bug#970156: systemd.socket fails with Failed to queue service startup job (Maybe the service file is missing or not a template unit?): Transport endpoint is not connected

[Wolfgang Walter]

Am Samstag, 12. September 2020, 18:45:07 CEST schrieb Michael Biebl:
> Am 12.09.20 um 13:33 schrieb Wolfgang Walter:
> > Package: systemd
> > Version: 246.4-1
> > Severity: important
> > 
> > Since upgrading (to 246 think) our socket services terminate sometimes
> > every hour with:
> > 
> > "Failed to queue service startup job (Maybe the service file is missing or
> > not a template unit?): Transport endpoint is not connected"
> > 
> > I think this is this bug:
> > 
> > https://www.spinics.net/lists/systemd-devel/msg04761.html
> > https://www.spinics.net/lists/systemd-devel/msg04784.html
> > 
> > So commit 86e045ecefc404d4fccbeb78aa212ec4714a5763 should fix this.
> > 
> > Would it be possible to include this fix into debian's systemd?
> 
> Sure. Would you be willing to confirm that this commit fixes your issue?

Thanks for releasing 246.5-1. Faster then I could test this patch :-).

246.5-1 fixes the issue.

By the way: thanks to all debian systemd maintainers for their great work.

Regards,
-- 
Wolfgang Walter
Studentenwerk München
Anstalt des öffentlichen Rechts

Bug#970444: Can't connect to httpd stream on MPD

[kaliko]

Hi James

On 16/09/2020 à 19:28, James Klaas wrote :
> […]
> root@myhost:~# service mpd stop
> root@myhost:~# service mpd start
> root@myhost:~# curl http://192.168.144.122:8000
> curl: (7) Failed to connect to 192.168.144.122 port 8000: Connection refused
> 
> I tried other commands you mentioned:
> 
> […]
> root@myhost:/etc/cron.weekly# lsof -Pan -p 10880 -i
> COMMAND   PID USER   FD   TYPEDEVICE SIZE/OFF NODE NAME
> mpd 10880  mpd4u  IPv6 114131524  0t0  TCP *:6600 (LISTEN)
> 
> root@myhost:/etc/cron.weekly# ss -antlp | grep mpd
> LISTEN0 5*:6600
> *:*users:(("mpd",pid=10880,fd=4),("systemd",pid=1,fd=108))
> 
> I greped for mpd since the list of services is quite large. I wanted
> to check there was nothing conflicting on port 8000:
> 
> root@myhost:~# ss -antlp  | grep 8000

Well it looks like MPD is listening on :6600 only (is it playing something?).

> I don't see anything odd in the logs, when set to verbose:
> 
> Sep 14 16:12 : zeroconf: No global port, disabling zeroconf
> Sep 14 16:12 : state_file: Loading state file /var/lib/mpd/state
> Sep 14 16:13 : client: [0] opened from 192.168.47.122:57198
> Sep 14 16:13 : client: [0] malformed command "GET / HTTP/1.1"
> Sep 14 16:13 : client: [0] closed
> Sep 14 16:20 : client: [1] opened from local
> Sep 14 16:20 : client: [1] process command "outputs"
> Sep 14 16:20 : client: [1] command returned 0
> Sep 14 16:20 : client: [1] closed


> I tried adding port 8000 to /lib/systemd/system/mpd.socket under the
> "[Socket]" section and ran "systemctl daemon-reload". But that seems
> to only expose the socket to port 8000.
> 
> Is another section needed in /lib/systemd/system/mpd.socket to open up
> 8000 to the httpd server in mpd?

Systemd socket activation is meant to launch MPD "on demand" when a client 
tries to
connect on port 6600. IMO, you don't need to add 8000 here.

HTTP output is set in the conf, something like:

 /etc/mpd.conf ---8<---

audio_output {
type"httpd"
port"8000"
enabled "yes"
...
}

->8---

Also, you need to start playing something for MPD to listen on the HTTPD port.

Please paste your MPD config as well.

k.



signature.asc
Description: OpenPGP digital signature

Bug#970446: Segmentation fault is gone, close #970446

[Kai Weber]

I can no longer reproduce this behaviour. Totem and other gstreamer
based applications work. I have no glue what caused the issue and why
it's gone now.

Sorry for the noise.
Kai

Bug#969529: (no subject)

[Mattia Rizzolo]

A note, that ubuntu links to a different commit (the same that is
recorded at mitre).

https://bugs.launchpad.net/debian/+source/libxml2/+bug/1895839

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
More about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-

Bug#970391:

[Felix Neuper]

Upon recreation of the behavior, it was noted, that the RequiredBy-statement 
was placed in the [Unit]-section.
When moving it to the  [Install]-section, expected behavior was seeen.

To clarify:
1) Starting point: two enabled services A & B with no connection
2) Change of A.service -file by adding RequiredBy=B.service (while A.service is 
enabled).
3) systemctl enable A.service ---> symlink 
/etc/systemd/system/B.service.requires/A.service created as expected
4) all good no bug present, behavior as expected

Expected behavior could be reproduced with the original services, as well as 
test services.

Bad behavior can be reproduced when putting RequiredBy=B.service in the [Unit] 
section of of A.service only (in that case the symlink is not created upon 
"systemctl enable A").


Kindly close and mark as wrongly reported. I will pay more attention and do 
proper testing and reproduction before reporting in future. My apologies.

Thank you.

Bug#961584: [pkg-lxc-devel] Bug#961584: Bug#961584: lxc-stop fails with exit code 1

[Antonio Terceiro]

Hi,

On Wed, Sep 16, 2020 at 11:14:58PM +0200, Pierre-Elliott Bécue wrote:
> Le mercredi 16 septembre 2020 à 22:08:24+0200, Pierre-Elliott Bécue a écrit :
> > Le vendredi 11 septembre 2020 à 11:12:25+0200, Iñaki Malerba a écrit :
> > > Hi Pebs,
> > > 
> > > Thanks for checking this.
> > > 
> > > On Sat, 5 Sep 2020 23:23:30 +0200 Pierre-Elliott =?utf-8?B?QsOpY3Vl?=
> > >  wrote:>
> > > > LXC's devs told me that 4.0.4 should solve it. I'm uploading this
> > > > release now. Please don't hesitate to tell me if it helps.
> > > 
> > > Run a pipeline removing the pinning of lxc, and the behaviour seems to
> > > be the same.
> > > 
> > > Image building:
> > > https://salsa.debian.org/ina/pipeline/-/jobs/990332
> > > > Setting up lxc (1:4.0.4-1) ..
> > > 
> > > Running lxc:
> > > https://salsa.debian.org/ina/pipeline/-/jobs/990352
> > > > : failure: ['sudo', 'timeout', '600', 'lxc-stop',
> > > '--quiet', '--kill', '--name', 'ci-254-b2fcad5f'] failed (exit status 1,
> > > stderr '')
> > > 
> > > Please let me know if you want us to test something else.
> > > 
> > > Abrazos,
> > 
> > Could you get me a full trace like the previous time? I have no
> > technical  means of running proper tests currently, sorry. :/
> > 
> > Cheers!
> 
> I found a way to run tests on my own.
> 
> Turns out I tried to add a lxc-attach autopkgtest-stable-amd64 -- ps
> auxf to see the process tree in case I could find something useful,
> and… the container successfully stopped that time. I retried and it kept
> working.
> 
> The process tree I see is:
> ─( 23:09:35 )─< /home/becue/tmp 
> >───[ 0 ]─
> root@dawaj # docker run --rm --privileged -i autopkgtest
> Starting LXC network bridge: :Starting LXC autoboot containers: :USER
> PID %CPU %MEMVSZ   RSS TTY  STAT START   TIME COMMAND
> root   4  0.0  0.0   7644  2760 ?R21:09   0:00 ps auxf
> root   1  0.0  0.0  20904  7492 ?Ds   21:09   0:00 /sbin/init
> ok
> 
> After some more tests, it seems that lxc-start && lxc-stop isn't working
> properly because the signal is sent before the container is ready to
> handle it.
> 
> After this test I decided to add a sleep 2 before the lxc-attach ... --
> ps command:
> 
> Starting LXC network bridge: :Starting LXC autoboot containers: :USER
> PID %CPU %MEMVSZ   RSS TTY  STAT START   TIME COMMAND
> root  52  0.0  0.0   7644  2768 ?R21:10   0:00 ps auxf
> root   1  2.5  0.1  21524  9596 ?Ss   21:10   0:00 /sbin/init
> root  17  0.5  0.1  27444  8404 ?Ss   21:10   0:00 
> /lib/systemd/systemd-journald
> root  27  0.0  0.0   2348  1772 ?Ss   21:10   0:00 /sbin/ifup 
> -a --read-environment
> root  42  0.0  0.0   2392   764 ?S21:10   0:00  \_ 
> /bin/sh -c /sbin/dhclient -4 -v -i -pf /run/dhclient.eth0.pid -lf 
> /var/lib/dhcp/dhclient.eth0.leases -I -df /var/lib/dhcp/dhclient6.eth0.leases 
> eth0 .
> root  43  0.0  0.0   8456  1936 ?S21:10   0:00 \_ 
> /sbin/dhclient -4 -v -i -pf /run/dhclient.eth0.pid -lf 
> /var/lib/dhcp/dhclient.eth0.leases -I -df /var/lib/dhcp/dhclient6.eth0.leases 
> eth0
> root  44  0.0  0.0   9492  5644 ?S21:10   0:00 \_ 
> /sbin/dhclient -4 -v -i -pf /run/dhclient.eth0.pid -lf 
> /var/lib/dhcp/dhclient.eth0.leases -I -df /var/lib/dhcp/dhclient6.eth0.leases 
> eth0
> message+  50  0.0  0.0   8696  3636 ?Ss   21:10   0:00 
> /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile 
> --systemd-activation --syslog-only
> root  51  0.5  0.0  19308  6376 ?Ss   21:10   0:00 
> /lib/systemd/systemd-logind
> ok
> 
> Turns out your lxc-stop is really fast, and therefore, not catched
> properly by LXC.
> 
> While I appreciate it shouldn't be a corner case that makes things
> explode, do you think there's a way to take this realization into
> account to lower the severity of this bug, having a temporary fix set up
> in place?
> 
> I'll still try to see what upstream could offer to handle this in a
> better way.

I did a little bit of debugging on this today. I think the provided
Dockerfile does not really reproduce the real issue. The lxc-stop call
from lxc comes after the tests are run, so plenty of time after the
lxc-start call.

I installed autopkgtest inside the container, did manually the mount
steps listed in the Dockerfile, and tried it directly. Failed as
expected:

root@665d38b2f9e3:~/pkg# autopkgtest -B . -- lxc autopkgtest-stable-amd64
autopkgtest [12:41:01]: starting date: 2020-09-17
autopkgtest [12:41:01]: version 5.14
autopkgtest [12:41:01]: host 665d38b2f9e3; command line: 
/usr/bin/autopkgtest -B . -- lxc autopkgtest-stable-amd64
autopkgtest [12:41:07]: testbed dpkg architecture: amd64
autopkgtest [12:41:08]: testbed running kernel: Linux 5.8.0-1-amd64 #1 SMP 
Debian 5.8.7-1 (2020-09-05)
autopkgtest [12:41:08]:  

Bug#969804: bart: autopkgtest should be marked superficial

[Andreas Tille]

Control: tags -1 normal

On Thu, Sep 17, 2020 at 01:40:29PM +0200, Paul Gevers wrote:
> The thread starts here:
> https://lists.debian.org/debian-devel/2020/09/msg00071.html
> 
> mostly follow-ups from here on:
> https://lists.debian.org/debian-devel/2020/09/msg00219.html

Thanks for the pointers and as I'd love to repeat for all your
work on this
 Andreas.

-- 
http://fam-tille.de

Bug#970496: gnuradio: Crash on missing gsettings

[Cédric Hannotier]

Package: gnuradio
Version: 3.8.2.0-2
Severity: important

Dear Maintainer,

Version 3.8.2.0 introduced the use of gsettings to detect dark theme.
It was introduced in [1].

However, I do not have gsettings, making grc unable start.

It was solved in [2]. Could you backport this patch [3]?

[1] 
https://github.com/gnuradio/gnuradio/commit/507e85722573cfdc3029b4fd7776a75987f332d7#diff-bf77b70d546aca561ea9162c8da2105c
[2] 
https://github.com/gnuradio/gnuradio/commit/7826795923375fef264070e9af4e21f5932737f6
[3] 
https://github.com/gnuradio/gnuradio/commit/7826795923375fef264070e9af4e21f5932737f6.patch

$ gnuradio-companion
Traceback (most recent call last):
  File "/usr/bin/gnuradio-companion", line 102, in 
run_main()
  File "/usr/bin/gnuradio-companion", line 95, in run_main
exit(main())
  File "/usr/lib/python3/dist-packages/gnuradio/grc/main.py", line 73, in main
from .gui.Platform import Platform
  File "/usr/lib/python3/dist-packages/gnuradio/grc/gui/Platform.py", line 26, 
in 
from . import canvas
  File "/usr/lib/python3/dist-packages/gnuradio/grc/gui/canvas/__init__.py", 
line 21, in 
from .param import Param
  File "/usr/lib/python3/dist-packages/gnuradio/grc/gui/canvas/param.py", line 
23, in 
from .. import ParamWidgets, Utils, Constants
  File "/usr/lib/python3/dist-packages/gnuradio/grc/gui/ParamWidgets.py", line 
66, in 
add_style_provider()
  File "/usr/lib/python3/dist-packages/gnuradio/grc/gui/ParamWidgets.py", line 
58, in add_style_provider
dark_theme = have_dark_theme()
  File "/usr/lib/python3/dist-packages/gnuradio/grc/gui/ParamWidgets.py", line 
48, in have_dark_theme
theme = subprocess.check_output(
  File "/usr/lib/python3.8/subprocess.py", line 411, in check_output
return run(*popenargs, stdout=PIPE, timeout=timeout, check=True,
  File "/usr/lib/python3.8/subprocess.py", line 489, in run
with Popen(*popenargs, **kwargs) as process:
  File "/usr/lib/python3.8/subprocess.py", line 854, in __init__
self._execute_child(args, executable, preexec_fn, close_fds,
  File "/usr/lib/python3.8/subprocess.py", line 1702, in _execute_child
raise child_exception_type(errno_num, err_msg, err_filename)
FileNotFoundError: [Errno 2] No such file or directory: 'gsettings'


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

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

Versions of packages gnuradio depends on:
ii  libboost-program-options1.71.0  1.71.0-6+b2
ii  libboost-thread1.71.0   1.71.0-6+b2
ii  libc6   2.31-3
ii  libcodec2-0.9   0.9.2-3
ii  libgcc-s1   10.2.0-7
ii  libgnuradio-analog3.8.2 3.8.2.0-2
ii  libgnuradio-audio3.8.2  3.8.2.0-2
ii  libgnuradio-blocks3.8.2 3.8.2.0-2
ii  libgnuradio-channels3.8.2   3.8.2.0-2
ii  libgnuradio-digital3.8.23.8.2.0-2
ii  libgnuradio-dtv3.8.23.8.2.0-2
ii  libgnuradio-fec3.8.23.8.2.0-2
ii  libgnuradio-fft3.8.23.8.2.0-2
ii  libgnuradio-filter3.8.2 3.8.2.0-2
ii  libgnuradio-pmt3.8.23.8.2.0-2
ii  libgnuradio-qtgui3.8.2  3.8.2.0-2
ii  libgnuradio-runtime3.8.23.8.2.0-2
ii  libgnuradio-trellis3.8.23.8.2.0-2
ii  libgnuradio-uhd3.8.23.8.2.0-2
ii  libgnuradio-video-sdl3.8.2  3.8.2.0-2
ii  libgnuradio-vocoder3.8.23.8.2.0-2
ii  libgnuradio-wavelet3.8.23.8.2.0-2
ii  libgnuradio-zeromq3.8.2 3.8.2.0-2
ii  liblog4cpp5v5   1.1.3-3
ii  libpython3.83.8.5-2
ii  libqt5core5a5.14.2+dfsg-6
ii  libqt5widgets5  5.14.2+dfsg-6
ii  libstdc++6  10.2.0-7
ii  libuhd3.15.03.15.0.0-3
ii  libvolk2-bin2.3.0-3
ii  python3 3.8.2-3
ii  python3-click   7.0-3
ii  python3-click-plugins   1.1.1-2
ii  python3-gi  3.36.1-1
ii  python3-gi-cairo3.36.1-1
ii  python3-lxml4.5.2-1
ii  python3-mako1.1.2+ds1-1
ii  python3-numpy   1:1.19.1-1
ii  python3-opengl  3.1.5+dfsg-1
ii  python3-pyqt5   5.15.0+dfsg-1+b1
ii  python3-pyqtgraph   0.11.0-6
ii  python3-sip 4.19.24+dfsg-1
ii  python3-yaml5.3.1-2
ii  python3-zmq 19.0.2-2

Versions of packages gnuradio recommends:
pn  gnuradio-dev
ii  python3-matplotlib  3.3.0-3
ii  python3-networkx   

Bug#969739: Segmentation fault on startup

[Julien Cristau]

Control: severity -1 important
Control: tag -1 moreinfo

On Mon, Sep 07, 2020 at 11:59:34AM -0400, Christophe Kalt wrote:
> Package: xserver-xorg-core
> Version: 2:1.20.9-1
> Severity: grave
> 
> Same setup was working with 2:1.20.7-2, but with 2:1.20.9-1 crashes on startup
> (xinit). /var/log/Xorg.0.log follows:
> 
There's a number of things going wrong here...

[...]
> [881147.372] (EE) dbus-core: error connecting to system bus:
> org.freedesktop.DBus.Error.FileNotFound (Failed to connect to socket 
> /run/dbus/
> system_bus_socket: No such file or directory)

That's not good for input but probably doesn't explain the crash in InitOutput.

[...]
> [881147.372] (II) xfree86: Adding drm device (/dev/dri/card0)
> [881147.372] (II) Platform probe for /sys/devices/pci:00/:00:02.0/drm/
> card0
> [881147.377] (--) PCI:*(0@0:2:0) 8086:3ea5:8086:2074 rev 1, Mem @ 
> 0x604b00/
> 16777216, 0x40/134217728, I/O @ 0x4000/64, BIOS @ 
> 0x/131072

That's Intel "Iris Plus Graphics 655".

[...]
> [881147.426] (II) modeset(G0): using drv /dev/dri/card0
> [881147.427] (II) modeset(0): Creating default Display subsection in Screen
> section
> "Default Screen Section" for depth/fbbpp 24/32
> [881147.427] (==) modeset(0): Depth 24, (==) framebuffer bpp 32
> [881147.427] (EE)
> [881147.427] (EE) Backtrace:
> [881147.428] (EE) 0: /usr/lib/xorg/Xorg (OsLookupColor+0x135) [0x557662d21f35]
> [881147.429] (EE) 1: /lib/x86_64-linux-gnu/libpthread.so.0 (funlockfile+0x50)
> [0x7f3bb952318f]
> [881147.430] (EE) 2: /usr/lib/xorg/Xorg (xf86PlatformMatchDriver+0x5c0)
> [0x557662c1a2b0]
> [881147.430] (EE) 3: /usr/lib/xorg/Xorg (xf86CollectOptions+0x77)
> [0x557662bfd197]
> [881147.431] (EE) unw_get_proc_name failed: no unwind info found [-10]
> [881147.431] (EE) 4: /usr/lib/xorg/modules/drivers/modesetting_drv.so (?+0x0)
> [0x7f3bb8a25940]
> [881147.432] (EE) 5: /usr/lib/xorg/Xorg (InitOutput+0x9ae) [0x557662c0085e]
> [881147.433] (EE) 6: /usr/lib/xorg/Xorg (InitFonts+0x1cc) [0x557662bc235c]
> [881147.434] (EE) 7: /lib/x86_64-linux-gnu/libc.so.6 (__libc_start_main+0xea)
> [0x7f3bb936ecca]
> [881147.434] (EE) 8: /usr/lib/xorg/Xorg (_start+0x2a) [0x557662babc9a]
> [881147.434] (EE)
> [881147.435] (EE) Segmentation fault at address 0x124
> [881147.435] (EE)
> Fatal server error:
> [881147.435] (EE) Caught signal 11 (Segmentation fault). Server aborting
> [881147.435] (EE)
> [881147.435] (EE)
> Please consult the The X.Org Foundation support
> at http://wiki.x.org
>  for help.
> [881147.435] (EE) Please also check the log file at "/var/log/Xorg.0.log" for
> additional information.
> [881147.435] (EE)
> [881147.467] (EE) Server terminated with error (1). Closing log file.

Any details you can provide as to the setup and how you're starting Xorg?

Please also provide a kernel log.

Cheers,
Julien

Bug#969136: xserver-xorg-video-amdgpu: Xserver keeps crashing inside of /usr/lib/xorg/modules/drivers/amdgpu_drv.so

[Julien Cristau]

Control: severity -1 important
Control: reassign -1 mesa

On Thu, Aug 27, 2020 at 06:36:27PM -0700, Phil Dibowitz wrote:
> Package: xserver-xorg-video-amdgpu
> Version: 19.1.0-1
> Severity: grave
> Justification: causes non-serious data loss
> 
> Dear Maintainer,
> 
> About once a day my Xserver crashes. The following stracktrace appears
> in the Xorg log:
> 
> ```
> [ 72995.788] (EE)
> [ 72995.788] (EE) Backtrace:
> [ 72995.793] (EE) 0: /usr/lib/xorg/Xorg (OsLookupColor+0x138) [0x56449292fe88]
> [ 72995.794] (EE) 1: /lib/x86_64-linux-gnu/libpthread.so.0 (funlockfile+0x50) 
> [0x7f8803c4e18f]
> [ 72995.794] (EE) 2: /lib/x86_64-linux-gnu/libc.so.6 
> (__nss_database_lookup+0x28131) [0x7f8803bfdc41]
> [ 72995.797] (EE) 3: /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so 
> (radeon_drm_winsys_create+0x112f0f) [0x7f880208227f]
> [ 72995.797] (EE) 4: /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so 
> (radeon_drm_winsys_create+0x138740) [0x7f88020ccd30]
> [ 72995.798] (EE) 5: /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so 
> (radeon_drm_winsys_create+0x13b601) [0x7f88020d22f1]
> [ 72995.799] (EE) 6: /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so 
> (nouveau_drm_screen_create+0x1db4ac) [0x7f88023cc4bc]
> [ 72995.799] (EE) 7: /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so 
> (nouveau_drm_screen_create+0x1d7a0f) [0x7f88023c4e6f]
> [ 72995.800] (EE) 8: /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so 
> (nouveau_drm_screen_create+0x1dbf83) [0x7f88023cd923]
> [ 72995.800] (EE) 9: /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so 
> (__driDriverGetExtensions_zink+0x210f9) [0x7f88018aa579]
> [ 72995.801] (EE) 10: /usr/lib/xorg/modules/libglamoregl.so 
> (glamor_destroy_pixmap+0x148) [0x7f87f80a0b68]
> [ 72995.802] (EE) unw_get_proc_name failed: no unwind info found [-10]
> [ 72995.802] (EE) 11: /usr/lib/xorg/modules/drivers/amdgpu_drv.so (?+0x0) 
> [0x7f880313d650]
> [ 72995.802] (EE) 12: /usr/lib/xorg/Xorg (BlockHandler+0xa5) [0x5644927d72c5]
> [ 72995.802] (EE) 13: /usr/lib/xorg/Xorg (WaitForSomething+0x11a) 
> [0x5644929296fa]
> [ 72995.802] (EE) 14: /usr/lib/xorg/Xorg (SendErrorToClient+0x113) 
> [0x5644927d2723]
> [ 72995.802] (EE) 15: /usr/lib/xorg/Xorg (InitFonts+0x3b4) [0x5644927d6914]
> [ 72995.803] (EE) 16: /lib/x86_64-linux-gnu/libc.so.6 
> (__libc_start_main+0xea) [0x7f8803a99cca]
> [ 72995.803] (EE) 17: /usr/lib/xorg/Xorg (_start+0x2a) [0x5644927c073a]
> [ 72995.803] (EE)
> [ 72995.803] (EE) Segmentation fault at address 0x7f87e07f9000
> [ 72995.803] (EE)
> Fatal server error:
> [ 72995.803] (EE) Caught signal 11 (Segmentation fault). Server aborting
> [ 72995.803] (EE)
> [ 72995.803] (EE)
> Please consult the The X.Org Foundation support
>  at http://wiki.x.org
>  for help.
> [ 72995.803] (EE) Please also check the log file at "/var/log/Xorg.0.log" for 
> additional information.
> [ 72995.803] (EE)
> [ 72995.803] (II) AIGLX: Suspending AIGLX clients for VT switch
> ```
> 
> There's nothing specific to trigger the bug, I've had it happen while
> doing a variety of different things.
> 
Which version of libgl1-mesa-dri is this on?

If you're still seeing this on the latest version it would probably be
good to report at https://gitlab.freedesktop.org/mesa/mesa/-/issues for
the mesa devs to take a look.

Cheers,
Julien

Bug#946035: Request fo sponsor to uplad python-jsonrpc-server

[Pablo Mestre]

Hi

Thanks for the feedback. I will solve this.

Pablo

El 9/17/20 a las 5:27 AM, PICCA Frederic-Emmanuel escribió:
> Hello,
>
> It compile fine :), but I have a concern about the license.
>
> It is considère a good practice to use the same license for the debian 
> directory and the source code.
> In your case, you chooses GPL-3+, but the code is MIT.
>
> Fred

-- 
  ⢀⣴⠾⠻⢶⣦⠀  Pablo Mestre Drake
  ⣾⠁⢠⠒⠀⣿⡁  --
  ⢿⡄⠘⠷⠚⠋   https://debian.org
  ⠈⠳⣄  Debian, the universal operating system.

Bug#970504: te923con FTCBFS: hard codes the build architecture compiler

[Helmut Grohne]

Source: te923con
Version: 0.6.1-4
Tags: patch upstream
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

te923con fails to cross build from source, because the upstream Makefile
hard codes the build architecture compiler gcc. Please consider applying
the attached patch to make gcc substitutable and te923con cross
buildable.

Helmut
--- te923con-0.6.1.orig/Makefile
+++ te923con-0.6.1/Makefile
@@ -6,6 +6,6 @@
 all: te923con
 
 te923con: te923con.c te923con.h te923usb.c te923usb.h te923com.c te923com.h
-	gcc $(CPPFLAGS) $(CFLAGS) $(CXXFLAGS) $(LDFLAGS) -Wall -o te923con te923con.c te923usb.c te923com.c -lusb
+	$(CC) $(CPPFLAGS) $(CFLAGS) $(CXXFLAGS) $(LDFLAGS) -Wall -o te923con te923con.c te923usb.c te923com.c -lusb
 
 

Bug#970495: python-livereload: autopkgtest regression: needs-internet but fails

[Antonio Terceiro]

> autopkgtest [03:13:34]: test command1: python3 setup.py test
> autopkgtest [03:13:34]: test command1: [---
> running test
> WARNING: Testing via this command is deprecated and will be removed in a
> future version. Users looking for a generic test entry point independent
> of test runner are encouraged to use tox.
> WARNING: The pip package is not available, falling back to EasyInstall
> for handling setup_requires/test_requires; this is deprecated and will
> be removed in a future version.
> Searching for tornado
> Reading https://pypi.org/simple/tornado/
> Download error on https://pypi.org/simple/tornado/: [SSL:
> CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get
> local issuer certificate (_ssl.c:1123) -- Some packages may not be found!
> Couldn't find index page for 'tornado' (maybe misspelled?)
> Scanning index of all packages (this may take a while)
> Reading https://pypi.org/simple/
> Download error on https://pypi.org/simple/: [SSL:
> CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get
> local issuer certificate (_ssl.c:1123) -- Some packages may not be found!
> No local packages or working download links found for tornado
> error: Could not find suitable distribution for Requirement.parse('tornado')
> autopkgtest [03:13:35]: test command1: ---]

Also:

- this log suggests that the test is trying/willing to install packages
  from outside of Debian, and this is not allowed.
- `setup.py test` tells you that it's deprecated so it will probably
  break at some point.
- Running test tests directly from the sources root like this will make
  python pick up the package code from the source tree, and not from the
  installed package.

I suggest you change the tests control file like this:

8<8<8<-
diff --git a/debian/tests/control b/debian/tests/control
index cc60693..ed182c7 100644
--- a/debian/tests/control
+++ b/debian/tests/control
@@ -1,5 +1,6 @@
-Test-Command: python3 setup.py test
+Test-Command: cd tests && python3 -m pytest
 Depends: @,
  python3-setuptools,
  python3-django,
+ python3-pytest,
 Restrictions: allow-stderr
8<8<8<-

If you don't want pytest for some reason, you can replace `-m pytest`
with `-m unittest` and not depend on python3-pytest. But the pytest
output in case of failure is a lot better for debugging.


signature.asc
Description: PGP signature

Bug#970500: network-manager does not start at boot

[Hans]

OK, I have rechecked my configurations. It appears, that network-manager is 
started, when I do a "systemctl enable NetworkManager". However, still /etc/
init.d/network-manager is missing. Dunno, if this is still needed.

I also discovered, that (maybe again?) the problem appears, that the applet , 
here exactly nm-applet got into a problem, when running in LXDE.


This problem appeared in the past, but was fixed. Now it appears agian.

When I am running plasma, then nm-applet gets access to the network-manager 
service, but when I start LXDE, I get the message, that the network-manger-
service is not running. So it looks for me, like a rights problem.

When I do start nm-applet as root in LXDE, then I get access to the network-
manager-service, but when I do the same as a normal user, access is forbidden 
(something dbus and so).

Please note, that I do not use a system with sudo, my installation is some 
years old, where sudo was not existent. However, this system is up-to-date 
debian/testing, and running well. 

I would not have changed to nemtwork-manager, because I was happy with wicd, 
but as wicd was removed from the repo, I chose the alternative.

Thanks for looking at this bug.

Best

Hans

Bug#970503: linux-image-5.8.0-1-amd64: using swap makes the machine hang

[Vincent Lefevre]

Package: src:linux
Version: 5.8.7-1
Severity: important

When swap is used (even a little), the machine hangs. A manual
power-off is needed.

To reproduce on my machine, which has 16 GB RAM and 20 GB swap:

$ memhog 15G

(command from the numactl package), e.g. just after the boot.

The machine still answers to ping, and if the command is run from
a VT (Linux console), I can still see things I type on the keyboard,
but I can't do anything else. Trying to interrupt the command with
Ctrl-C or Ctrl-\ has no effect. If I run the command from X, the
whole interface is frozen, e.g. the mouse pointer can no longer
move.

I initially found this issue with MPFR, using a little more than
15 GB. After 10 minutes, the interface was still completely frozen.

Note that nothing could be written in the logs.

-- Package-specific info:
** Version:
Linux version 5.8.0-1-amd64 (debian-ker...@lists.debian.org) (gcc-10 (Debian 
10.2.0-6) 10.2.0, GNU ld (GNU Binutils for Debian) 2.35) #1 SMP Debian 5.8.7-1 
(2020-09-05)

** Command line:
BOOT_IMAGE=/vmlinuz-5.8.0-1-amd64 root=/dev/mapper/zira--vg-root ro quiet

** Tainted: POE (12289)
 * proprietary module was loaded
 * externally-built ("out-of-tree") module was loaded
 * unsigned module was loaded

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

** Model information
sys_vendor: Hewlett-Packard
product_name: HP ZBook 15 G2
product_version: A3008CD10003
chassis_vendor: Hewlett-Packard
chassis_version: 
bios_vendor: Hewlett-Packard
bios_version: M70 Ver. 01.08
board_vendor: Hewlett-Packard
board_name: 2253
board_version: KBC Version 03.10

** Loaded modules:
uinput
rfcomm
ipt_REJECT
nf_reject_ipv4
xt_multiport
nft_compat
nft_counter
nf_tables
nfnetlink
cmac
algif_hash
algif_skcipher
af_alg
bnep
cpufreq_conservative
cpufreq_userspace
cpufreq_powersave
intel_rapl_msr
intel_rapl_common
iwlmvm
mac80211
mei_wdt
btusb
btrtl
snd_hda_codec_realtek
btbcm
binfmt_misc
snd_hda_codec_generic
btintel
libarc4
x86_pkg_temp_thermal
bluetooth
snd_hda_codec_hdmi
ledtrig_audio
intel_powerclamp
iwlwifi
coretemp
snd_hda_intel
uvcvideo
snd_intel_dspcfg
rapl
videobuf2_vmalloc
jitterentropy_rng
videobuf2_memops
intel_cstate
snd_hda_codec
joydev
videobuf2_v4l2
hp_wmi
intel_uncore
pcspkr
sparse_keymap
cfg80211
snd_hda_core
videobuf2_common
serio_raw
mxm_wmi
wmi_bmof
drbg
at24
snd_hwdep
videodev
snd_pcm
ansi_cprng
snd_timer
sg
tpm_infineon
iTCO_wdt
snd
intel_pmc_bxt
ecdh_generic
mei_me
ecc
iTCO_vendor_support
watchdog
mc
rfkill
apple_mfi_fastcharge
mei
soundcore
evdev
tpm_tis
tpm_tis_core
tpm
hp_accel
lis3lv02d
rng_core
hp_wireless
button
ac
nvidia_drm(POE)
drm_kms_helper
cec
nvidia_modeset(POE)
nvidia(POE)
ipmi_devintf
ipmi_msghandler
parport_pc
ppdev
drm
lp
parport
ip_tables
x_tables
autofs4
ext4
crc16
mbcache
jbd2
crc32c_generic
dm_crypt
dm_mod
sd_mod
sr_mod
cdrom
t10_pi
crc_t10dif
crct10dif_generic
hid_apple
hid_generic
usbhid
hid
crct10dif_pclmul
crct10dif_common
crc32_pclmul
crc32c_intel
ghash_clmulni_intel
rtsx_pci_sdmmc
mmc_core
ahci
aesni_intel
xhci_pci
libahci
xhci_hcd
libata
libaes
crypto_simd
cryptd
glue_helper
ehci_pci
ehci_hcd
psmouse
scsi_mod
rtsx_pci
e1000e
usbcore
i2c_i801
lpc_ich
i2c_smbus
ptp
pps_core
usb_common
battery
video
wmi

** Network status:
*** IP interfaces and addresses:
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group 
default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
   valid_lft forever preferred_lft forever
inet6 ::1/128 scope host 
   valid_lft forever preferred_lft forever
2: eth0:  mtu 1500 qdisc pfifo_fast state UP 
group default qlen 1000
link/ether 30:8d:99:25:ad:3f brd ff:ff:ff:ff:ff:ff
inet 192.168.1.3/24 brd 192.168.1.255 scope global dynamic noprefixroute 
eth0
   valid_lft 86268sec preferred_lft 86268sec
inet6 fe80::b735:e72d:ac2d:f50/64 scope link noprefixroute 
   valid_lft forever preferred_lft forever
3: wlp61s0:  mtu 1500 qdisc noqueue state 
DOWN group default qlen 1000
link/ether cc:3d:82:a9:e3:ea brd ff:ff:ff:ff:ff:ff

*** Device statistics:
Inter-|   Receive|  Transmit
 face |bytespackets errs drop fifo frame compressed multicast|bytes
packets errs drop fifo colls carrier compressed
lo:   36248 411000 0  0 036248 
411000 0   0  0
  eth0:  9903821110000 0  0 2   205014 
922000 0   0  0
wlp61s0:   0   0000 0  0 00 
  0000 0   0  0

*** Protocol statistics:
Ip:
Forwarding: 2
1041 total packets received
1 with invalid addresses
0 forwarded
0 incoming packets discarded
1026 incoming packets delivered
1069 requests sent out
20 outgoing packets dropped
547 dropped because of missing route
18 reassemblies 

Bug#953365: Horde DB fixed with PostgreSQL as DB backend

[Mike Gabriel]

Control: reassign -1 php-horde-db
Control: found -1 2.4.0-3
Control: fixed -1 2.4.0-7
Control: close -1

Hi Denis,

the interaction of Horde with the PostgreSQL backend as found in Debian buster 
and Debian bullseye should be fixed in php-horde-db 2.4.0-7.

I'll try to get a stable-release update into buster shipping the required 
patches.

Greets,
Mike


-- 

mike gabriel aka sunweaver (Debian Developer)
fon: +49 (1520) 1976 148

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: sunwea...@debian.org, http://sunweavers.net



signature.asc
Description: PGP signature

Bug#941162: autopkgtests fixed with PHPUnit 8.x

[Mike Gabriel]

Control: close -1
Control: fixed -1 2.11.0-7

Since php-horde-mimi 2.11.0-7 autopkgtests succeed again when running against 
PHPUnit 8.x (and likely 9.x).

Greets,
Mike

-- 

mike gabriel aka sunweaver (Debian Developer)
fon: +49 (1520) 1976 148

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: sunwea...@debian.org, http://sunweavers.net



signature.asc
Description: PGP signature

Bug#929392: autopkgtests fixed with PHPUnit 8.x

[Mike Gabriel]

Control: close -1
Control: fixed -1 2.6.1-2

Since php-horde-image 2.6.1-2 autopkgtests are fixed again (and ported to 
PHPunit 8.x/9.x.

Mike

-- 

mike gabriel aka sunweaver (Debian Developer)
fon: +49 (1520) 1976 148

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: sunwea...@debian.org, http://sunweavers.net



signature.asc
Description: PGP signature

Bug#970502: picard-tools: autopkgtest arm64 failure

[Paul Gevers]

Source: picard-tools
Version: 2.23.4+dfsg-2
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: fails-always

Dear maintainer(s),

Your package was recently removed from testing and now needs passing
autopkgtests to migrate to testing instead of mere "no regression".
However, it fails on arm64. Currently this failure is blocking the
migration to testing [1]. Can you please investigate the situation and
fix it?

Paul

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

https://ci.debian.net/data/autopkgtest/testing/arm64/p/picard-tools/6994074/log.gz



signature.asc
Description: OpenPGP digital signature

Bug#827492: php-horde-http autopkgtest fixed

[Mike Gabriel]

Control: close -1
Control: fixed -1 2.1.6-3

Since php-horde-http 2.3.6-3, all phpunit tests pass during autopkgtests. Thus 
cosing this bug.

Mike


-- 

mike gabriel aka sunweaver (Debian Developer)
fon: +49 (1520) 1976 148

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: sunwea...@debian.org, http://sunweavers.net



signature.asc
Description: PGP signature

Bug#668613: Bug still exists

[sixerjman]

I have the same situation with two Broadcom adapters, one is Ethernet and
the other is wireless.
The postinst script sees the Ethernet adapter first, finds no matching
firmware and defaults
to downloading latest firmware (now 1:019-6) which does not work with older
B43 adapters.
See open bug https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=964140

Bug#969804: bart: autopkgtest should be marked superficial

[Paul Gevers]

Hi Andreas,

On 17-09-2020 11:46, Andreas Tille wrote:
> Was there any outcome on your discussion of the severity of those
> bugs (and where did this discussion happened - I can not find anything
> on debian-devel or debian-ci list)?

The thread starts here:
https://lists.debian.org/debian-devel/2020/09/msg00071.html

mostly follow-ups from here on:
https://lists.debian.org/debian-devel/2020/09/msg00219.html

Paul



signature.asc
Description: OpenPGP digital signature

Bug#882792: [Pkg-xfce-devel] Bug#882792: Bug#882792: xfce4-panel: some icons not appearing in notification panel

[Julian Gilbey]

On Mon, Nov 27, 2017 at 08:12:44PM +, Julian Gilbey wrote:
> On Mon, Nov 27, 2017 at 08:17:43PM +0100, Yves-Alexis Perez wrote:
> > On Mon, 2017-11-27 at 20:03 +0100, Yves-Alexis Perez wrote:
> > > On Mon, 2017-11-27 at 18:24 +, Julian Gilbey wrote:
> > > > This might be a small hint as to what might be going on: the
> > > > .xsession-errors file (attached) is full of errors and warnings
> > > > related to /usr/share/themes/Xfce/gtk-3.0/gtk.css.
> > > 
> > > Was gtk-3 updated recently on your system?
> > 
> > Seems that gtk-3 broke theming again, but I'm unsure it's actually related.
> > Can you try with another theme like Arc?
> 
> Ha ha, good catch!  That's half the problem - I've just removed
> gtk3-engines-xfce, and now the window menu titles are back to
> something sensible.  My libgtk-3-0 is 3.22.24, but that's been
> installed for ages, so I don't know why it only just broke.
> 
> So the only remaining problem is the icons not appearing in the
> notification area, and removing gtk3-engines-xfce hasn't helped there,
> unfortunately.
> 
> Thanks!!
> 
>Julian

Dear all,

I have at last come back to this bug and solved the problem to my
satisfaction, though I don't know whether this will help Lionel or
Shannon.

Xfce4 very confusingly has multiple different notification applets:

* Notification Area: This shows (for me) the keyboard layout (IBus
  preferences), the Orage calender icon and the Notes icon.

* Status Notifier Plugin: This shows the SafeEyes icon and the
  bluetooth icon.

* StatusNotifier Plugin (note the lack of a space in the name): This
  also shows the SafeEyes icon and the bluetooth icon, only a little
  larger.

Why there should be two different panel applets showing different
icons I have no idea; this seems to be a very broken design to me.
But at least I can now see all my icons!

Best wishes,

   Julian

Bug#969882: wmxres is marked for autoremoval from testing

[Torrance, Douglas]

On 9/17/20 12:39 AM, Debian testing autoremoval watch wrote:
> wmxres 1.4-1 is marked for autoremoval from testing on 2020-10-07
> 
> It is affected by these RC bugs:
> 969882: wmxres: autopkgtest should be marked superficial
>   https://bugs.debian.org/969882

I've prepared a new version of wmxres fixing this RC bug:
https://salsa.debian.org/wmaker-team/wmxres

Andreas, would you be able to sponsor an upload?

Thanks!
Doug

Bug#970500: network-manager does not start at boot

[Hans-J. Ullrich]

Package: network-manager
Severity: important

Dear Maintainer,

as debian forces me to uninstall wicd, I had to change to network-manager. 
After installation and a fresh reboot, I discovered, that network-manager is 
not been started at boot.

My examination showed, that the file /etc/init.d/network-manager does not 
exist. Furthermore I tried to get systemd start network-manager automatically 
started. Also the command
systemctl enable NetworkManger did not work. At last I discovered, that the 
command service NetworkManager start did work, but only until next reboot. 

Of course I could make an entry in one of the files in /etc/rc.local, however, 
that is just a workaround, no solution.

Hope, this bug will be soon fixed, as there is no other easy alternative to 
easy wicd (which is now gone in debian).

Best regards

Hans

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

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

Versions of packages network-manager depends on:
ii  adduser3.118
ii  dbus   1.12.20-1
ii  init-system-helpers1.58
ii  libaudit1  1:2.8.5-3+b1
ii  libbluetooth3  5.50-1.2
ii  libc6  2.31-3
ii  libcurl3-gnutls7.72.0-1
ii  libglib2.0-0   2.66.0-1
ii  libgnutls303.6.14-2+b1
ii  libjansson42.13.1-1
ii  libmm-glib01.14.2-0.1
pn  libndp0
ii  libnewt0.520.52.21-4+b1
ii  libnm0 1.26.2-1
ii  libpam-systemd 246.5-1
ii  libpolkit-agent-1-00.105-29
ii  libpolkit-gobject-1-0  0.105-29
ii  libpsl50.21.0-1.1
pn  libreadline7   
ii  libreadline8   8.0-4
ii  libselinux13.1-2
ii  libsystemd0246.5-1
pn  libteamdctl0   
ii  libudev1   246.5-1
ii  libuuid1   2.36-3
ii  lsb-base   11.1.0
ii  policykit-10.105-29
ii  udev   246.5-1
ii  wpasupplicant  2:2.9.0-15

Versions of packages network-manager recommends:
ii  crda 4.14+git20191112.9856751-1
ii  dnsmasq-base [dnsmasq-base]  2.82-1
ii  iptables 1.8.5-3
ii  isc-dhcp-client  4.4.1-2.1+b2
ii  modemmanager 1.14.2-0.1
ii  ppp  2.4.7-2+4.1+deb10u1+b1

Versions of packages network-manager suggests:
ii  isc-dhcp-client  4.4.1-2.1+b2
pn  libteam-utils

Bug#970501: rhino breaks dojo autopkgtest: Cannot set property "dojo" of null to "[object Object]"

[Paul Gevers]

Source: rhino, dojo
Control: found -1 rhino/1.7.7.2-1
Control: found -1 dojo/1.15.3+dfsg1-1
Severity: serious
Tags: sid bullseye
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: breaks needs-update

Dear maintainer(s),

With a recent upload of rhino the autopkgtest of dojo fails in testing
when that autopkgtest is run with the binary packages of rhino from
unstable. It passes when run with only packages from testing. In tabular
form:

   passfail
rhino  from testing1.7.7.2-1
dojo   from testing1.15.3+dfsg1-1
all others from testingfrom testing

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

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

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

Paul

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

https://ci.debian.net/data/autopkgtest/testing/amd64/d/dojo/7045098/log.gz
autopkgtest [01:52:16]: test shrinksafe: [---
js: "../../dojo/dojo.js", line 1321: exception from uncaught JavaScript
throw: TypeError: Cannot set property "dojo" of null to "[object Object]"

autopkgtest [01:52:18]: test shrinksafe: ---]




signature.asc
Description: OpenPGP digital signature