Bug#932989: gcc-avr: which upstream to track

[Hakan Ardo]

Hi,
thanx a lot for the great summary of the situation! Historically, the issue
with "community" versions of the avr toolchain have been the lack of
support for all AVR devices. Especially newer once. I don't know what the
situation is there with the Arduino toolcahin.

I agree that providing two version of gcc (one with Arduino as upstream and
one with microchip) is probably the best solution. That will however
require some packaging work, and I'm afraid that my current
personal situation wont allow me to put in that work anytime soon. But I
will gladly support it if anyone steps up to do the work.

So, the plan is to have a new release based on Atmel-3.6.2 from microchip
soon, and we can then make a separate release adding the Arduino version as
an alternative once it is packaged.


On Sun, Jan 12, 2020 at 2:30 AM Osamu Aoki  wrote:

> Hi again,
>
> I checked meaning of GCC versions.
>
> GCC development time lines:
>https://gcc.gnu.org/develop.html#timeline
>
> As for ISO C99 conformance:
>https://gcc.gnu.org/c99status.html
>
> The last mentioned version was GCC 5 for "extended identifiers".  So GCC
> 5 as supported by the vendor (microchip) isn't bad choice for C programs
> mostly used by embedded programs.
>
> Since Arduino sketches are in-essence C++ program(*), let's see C++
> conformance:
>https://gcc.gnu.org/projects/cxx-status.html
>
> For C++14, GCC 5 is good enough.
> For C++17, GCC 7 is needed and is good enough.
> For C++2a, GCC 8-10 are addressing some features.
>
> Unicode UTF-8 support is important. This u8 character literals support
> is made available at GCC 6 as a part of C++17 feature:
>http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4267.html
>https://gcc.gnu.org/gcc-6/changes.html#cxx
>
> This kind of explains why Arduino is updating GCC 7.
>
> Osamu
>
> (*) https://github.com/arduino/arduino-preprocessor
> https://github.com/arduino/arduino-builder
>
> https://github.com/arduino/Arduino/wiki/Arduino-IDE-1.5-3rd-party-Hardware-specification
>


-- 
Håkan Ardö

Bug#939989: transition: gdal

[Sebastiaan Couwenberg]

On 1/11/20 9:48 PM, Paul Gevers wrote:
> gdal triggers autopkgtest regressions in two packages and looking at the
> logs I am wondering if that point to a missing dependency relation, as
> the tests pass in unstable once they were binNMU'ed.
> 
> In both tests, libgdal20 from testing is installed (due to the package
> in testing not being build against the new library) but the new
> gdal-data package is installed. Both tests show:
> ERROR:  GDAL OpenFailed [4] Unable to open EPSG support file gcs.csv.
> Try setting the GDAL_DATA environment variable to point to the directory
> containing EPSG csv files.

I saw that, and it shouldn't pull in only gdal-data from unstable. That
seems like an issue in autopkgtest.

> Is this something that needs fixing in the gdal package somehow?

I don't think so.

> Probably I am saying something stupid, but e.g. gdal-data () breaks
> libgdal* . I notice that the library already has a larger than
> relation on gdal-data, but apparently there should have been a smaller
> than relation as well. (As we can't fix the package in testing, I
> proposed the breaks).
> 
> Can you please share your view of this problem?

This kind of inter-package dependency should use "(= ${source:Version})"
like done between arch:any packages with "(= ${binary:Version})", but
using the exact source version between arch:any and arch:all packages
breaks arch:all binNMUs, so >= is used instead.

I don't think the gdal source should be changed just to accommodate debci.

Kind Regards,

Bas

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



signature.asc
Description: OpenPGP digital signature

Bug#930195: avr-libc: Upstream avr-libc maintainers appear to be MIA; can another source be found?

[Hakan Ardo]

Thanx for the info! I'll make suer to upgrade the Debian packages.

On Sat, Jan 11, 2020 at 10:09 AM Ronald Sutherland <
ronald.sutherl...@gmail.com> wrote:

> Hi,
>
> Just want to note that a new upstream version is available for avr
> toolchain
>
>
>
> The old location
>
>
>
> http://distribute.atmel.no/tools/opensource/Atmel-AVR-GNU-Toolchain/
>
>
>
> has changed (look for heading: AVR GCC, then AVR GCC 3.6.2)
>
>
>
> https://www.microchip.com/mplab/avr-support/avr-and-sam-downloads-archive
>
>
>
> On Mon, 10 Jun 2019 12:50:21 +0200 Hakan Ardo  wrote:
>
> > Hi,
>
> > Apache 2.0 licence is fine, but for the main distribution we need the
>
> > source as well.
>
> >
>
> > On Mon, Jun 10, 2019 at 12:28 PM Paul "LeoNerd" Evans <
>
> > leon...@leonerd.org.uk> wrote:
>
> >
>
> > > On Mon, 10 Jun 2019 11:07:29 +0200
>
> > > Hakan Ardo  wrote:
>
> > >
>
> > > > There have been a sugestion to use Microchip Packs Repository:
>
> > > >
>
> > > > http://packs.download.atmel.com/
>
> > > >
>
> > > > But as far as I can tell, these are binary distributions and thus not
>
> > > > suitable for mainstream debian (I suppose placing them i non-free
>
> > > > could be an option).
>
> > >
>
> > > This is the preferred method I believe. In fact, it's what I use as a
>
> > > workaround at the moment.
>
> > >
>
> > > I've written myself a "reminder to self" blog post, which illustrates
>
> > > the steps I took to fix this problem:
>
> > >
>
> > >
>
> > >
> https://leonerds-code.blogspot.com/2019/06/building-for-new-attiny-1-series-chips.html
>
> > >
>
> > > Having done that, I can build code for these new chips just fine.
>
> > >
>
> > > Maybe that's all that is required? The pack files are Apache 2.0
>
> > > licenced, so hopefully that is acceptable to Debian?
>
> > >
>
> > > --
>
> > > Paul "LeoNerd" Evans
>
> > >
>
> > > leon...@leonerd.org.uk  |  https://metacpan.org/author/PEVANS
>
> > > http://www.leonerd.org.uk/  |  https://www.tindie.com/stores/leonerd/
>
> > >
>
> >
>
> >
>
> > --
>
> > Håkan Ardö
>


-- 
Håkan Ardö

Bug#948700: scikit-learn: re-enable build and installation of -doc package

[Sandro Tosi]

Source: scikit-learn
Version: 0.22.1+dfsg-1
Severity: important

Hello,
in order to package 0.22.1, we had to disable the build of the documentation via
sphinx, as that's requires sphinx 2.* while debian currently only ships 1.8.5

Refer to:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=944913
https://github.com/scikit-learn/scikit-learn/issues/16087#issuecomment-573092993

Please re-enable as soon as #944913 is addressed.

Regards,
Sandro

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

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

Bug#948699: ITP: pytest-mpi -- a plugin for pytest testing MPI-related code

[Drew Parsons]

Package: wnpp
Severity: wishlist
Owner: Drew Parsons 

* Package name: pytest-mpi
  Version : 0.3
  Upstream Author : James Tocknell
* URL : https://github.com/aragilar/pytest-mpi
* License : BSD
  Programming Lang: Python
  Description : a plugin for pytest testing MPI-related code

pytest-mpi provides a number of things to assist with using pytest
with MPI-using code, specifically:
 - Displaying of the current MPI configuration (e.g. the MPI
 version, the number of processes)
 - Sharing temporary files/folders across the MPI processes
 - Markers which allow for skipping or xfailing tests
based on whether the tests are being run under MPI

Further documentation can be found at https://pytest-mpi.readthedocs.io.


This plugin is required by future releases of h5py to run h5py tests
on MPI functionality, see https://github.com/h5py/h5py/pull/1255

To be maintained under the Debian Python Modules Team, alongside pytest.

Bug#948698: [Python-modules-team] Bug#948698: python3-flask-sqlalchemy: Please update to latest release 2.4.1

[Emmanuel Arias]

Hi,

I've just push to salsa, the new upstream release.

I will need sponsorship, please.

Thanks

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

El sáb., 11 de ene. de 2020 a la(s) 23:51, Nick Gasson
(nick+deb...@nickg.me.uk) escribió:
>
> Package: python3-flask-sqlalchemy
> Version: 2.1-4
> Severity: important
>
> Dear Maintainer,
>
> The version of flask-sqlalchemy currently packaged in Debian is quite
> old, and gives some deprecation warnings when used with the latest
> version of sqlalchemy in Debian:
>
>   /usr/lib/python3/dist-packages/sqlalchemy/dialects/sqlite/base.py:1453: 
> SADeprecationWarning: The create_engine.convert_unicode parameter and 
> corresponding dialect-level parameters are deprecated, and will be removed in 
> a future release.  Modern DBAPIs support Python Unicode natively and this 
> parameter is unnecessary.
> default.DefaultDialect.__init__(self, **kwargs)
>
>   /usr/lib/python3/dist-packages/flask_sqlalchemy/__init__.py:169: 
> SADeprecationWarning: Use .persist_selectable
> info = getattr(mapper.mapped_table, 'info', {})
>
> These warnings disappear if I install the latest 2.4.1 from pip.
>
>
> -- System Information:
> Debian Release: bullseye/sid
>   APT prefers unstable
>   APT policy: (500, 'unstable')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 5.4.0-1-amd64 (SMP w/12 CPU cores)
> Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
> LANGUAGE=en_GB:en (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> Versions of packages python3-flask-sqlalchemy depends on:
> ii  python3 3.7.5-1
> ii  python3-flask   1.1.1-2
> ii  python3-sqlalchemy  1.3.10+ds1-1
>
> python3-flask-sqlalchemy recommends no packages.
>
> python3-flask-sqlalchemy suggests no packages.
>
> -- no debconf information
>
> ___
> Python-modules-team mailing list
> python-modules-t...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/python-modules-team

Bug#947208: Need new version

[積丹尼 Dan Jacobson]

As noted in #946995, sound is stripped.

Bug#948451: ITP: python-cliapp -- cliapp is a Python framework for Unix-like command line programs. It contains the typical stuff such programs need to do, such as parsing the command line for options

[Paul Wise]

On Thu, Jan 9, 2020 at 1:48 AM Paul Wise wrote:
> On Wed, Jan 8, 2020 at 7:39 PM JAIR REIS wrote:
>
> > * Package name: python-cliapp
>
> Since this package is already available in Debian

I just noticed that this package is orphaned, so you can adopt the package:

https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#adopting-a-package

The first step is to retitle the Orphaned bug to ITA (Intent To Adopt):

https://www.debian.org/devel/wnpp/#l3

Once you have done that, read through the intro guide:

https://mentors.debian.net/intro-maintainers

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Bug#948698: python3-flask-sqlalchemy: Please update to latest release 2.4.1

[Nick Gasson]

Package: python3-flask-sqlalchemy
Version: 2.1-4
Severity: important

Dear Maintainer,

The version of flask-sqlalchemy currently packaged in Debian is quite
old, and gives some deprecation warnings when used with the latest
version of sqlalchemy in Debian:

  /usr/lib/python3/dist-packages/sqlalchemy/dialects/sqlite/base.py:1453: 
SADeprecationWarning: The create_engine.convert_unicode parameter and 
corresponding dialect-level parameters are deprecated, and will be removed in a 
future release.  Modern DBAPIs support Python Unicode natively and this 
parameter is unnecessary.
default.DefaultDialect.__init__(self, **kwargs)

  /usr/lib/python3/dist-packages/flask_sqlalchemy/__init__.py:169: 
SADeprecationWarning: Use .persist_selectable
info = getattr(mapper.mapped_table, 'info', {})

These warnings disappear if I install the latest 2.4.1 from pip.


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

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

Versions of packages python3-flask-sqlalchemy depends on:
ii  python3 3.7.5-1
ii  python3-flask   1.1.1-2
ii  python3-sqlalchemy  1.3.10+ds1-1

python3-flask-sqlalchemy recommends no packages.

python3-flask-sqlalchemy suggests no packages.

-- no debconf information

Bug#948697: apt-listbugs: Listbugs-spawned QueryBTS can't find Firefox

[Calum McConnell]

Subject: apt-listbugs: Listbugs-spawned QueryBTS can't find Firefox
Package: apt-listbugs
Version: 0.1.31
Severity: normal

I triggered an update, and apt-listbugs found some bugs.  I used the
b1/b2/b3 notation to query the BTS about said bugs, and read thru the
briefs on screen.  I then tried to use the 'b' menu option to open
firefox, however, I got a rapid fire series of errors instead, along
with
window popups about how the firefox profile was not found.  After I hit
'okay' to each window, it eventually gave me a reasonable text view of
the
bugs.
I would have reproduced the errors below, however, a few other packages
are
having bugs that cause them to spam the terminal with useless,
identical errors,
so the errors from query-bts all got buried (ie, they are above the
viewable
terminal window.)
As a guess, I would say that the root user doesnt have a firefox
profile,
When I ran querybts as a normal user, it was able to open a firefox
page:
sudo querybts wound up opening a text page, and printing about how it
failed to find various browsers, but had no popups about firefox
profiles,
and the error messages were less aggressive.
Thanks for taking the time to review this!
-Calum

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

Kernel: Linux 5.4.0-1-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=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 apt-listbugs depends on:
ii  apt 1.8.4
ii  ruby1:2.5.2
ii  ruby-debian 0.3.10
ii  ruby-gettext3.2.9-1
ii  ruby-soap4r 2.0.5-4
ii  ruby-unicode0.4.4-2+b9
ii  ruby-xmlparser  0.7.3-3+b2

Versions of packages apt-listbugs recommends:
ii  ruby-httpclient  2.8.3-2
ii  s6   2.9.0.1-2

Versions of packages apt-listbugs suggests:
iu  firefox-esr [www-browser]  68.4.1esr-1
ii  lynx [www-browser] 2.9.0dev.4-1
ii  reportbug  7.6.0
ii  sensible-utils 0.0.12+nmu1
ii  w3m [www-browser]  0.5.3-37+b1
ii  xdg-utils  1.1.3-1

-- Configuration Files:
/etc/apt/apt.conf.d/10apt-listbugs changed:
// Before installing packages, check whether they have release-critical 
bugs.
// If you don't like it, comment it out.
DPkg::Pre-Install-Pkgs {"/usr/bin/apt-listbugs apt";};
DPkg::Tools::Options::/usr/bin/apt-listbugs "";
DPkg::Tools::Options::/usr/bin/apt-listbugs::Version "3";
DPkg::Tools::Options::/usr/bin/apt-listbugs::InfoFD "20";
AptListbugs::Severities "critical,grave,serious,important,minor";
// AptListbugs::IgnoreRegexp "FTBFS";


-- no debconf information

Bug#948696: Concerning libtimezonemap in Debian (ITP #948696)

[Norbert Preining]

Hi Jeremy,

you have done the packaging/development of libtimezonemap for Ubuntu.
Is there any reason why you didn't upload to Debian?

We need it for Cinnamon 4.4 which I am currently preparing to upload to
experimental, and for now I have packaged libtimezonemap in the
cinnamon-team, just changing the minimal fields in d/control to point to
the Debian Cinnamon team.

But if you prefer to upload it to Debian, or propose any other
organization, I would be happy to pass it over.

Please let me know your preferences!

All the best

Norbert

On Sun, 12 Jan 2020, Norbert Preining wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Debian Cinnamon Team 
> 
> * Package name: libtimezonemap
>   Version : 0.4.6
>   Upstream Author : Ubuntu Developers 
> * URL : https://code.launchpad.net/~timezonemap-team/timezonemap/
> * License : GPL
>   Programming Lang: C
>   Description : GTK+3 timezone map widget
> 
> Timezone map widget for GTK+3 to be used in Cinnamon (4.4)
> 

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

Bug#948696: ITP: libtimezonemap -- GTK+3 timezone map widget

[Norbert Preining]

Package: wnpp
Severity: wishlist
Owner: Debian Cinnamon Team 

* Package name: libtimezonemap
  Version : 0.4.6
  Upstream Author : Ubuntu Developers 
* URL : https://code.launchpad.net/~timezonemap-team/timezonemap/
* License : GPL
  Programming Lang: C
  Description : GTK+3 timezone map widget

Timezone map widget for GTK+3 to be used in Cinnamon (4.4)

Bug#932989: gcc-avr: which upstream to track

[Osamu Aoki]

Hi again,

I checked meaning of GCC versions.

GCC development time lines:
   https://gcc.gnu.org/develop.html#timeline

As for ISO C99 conformance:
   https://gcc.gnu.org/c99status.html

The last mentioned version was GCC 5 for "extended identifiers".  So GCC
5 as supported by the vendor (microchip) isn't bad choice for C programs
mostly used by embedded programs.

Since Arduino sketches are in-essence C++ program(*), let's see C++
conformance:
   https://gcc.gnu.org/projects/cxx-status.html

For C++14, GCC 5 is good enough.
For C++17, GCC 7 is needed and is good enough.
For C++2a, GCC 8-10 are addressing some features.

Unicode UTF-8 support is important. This u8 character literals support
is made available at GCC 6 as a part of C++17 feature:
   http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4267.html
   https://gcc.gnu.org/gcc-6/changes.html#cxx

This kind of explains why Arduino is updating GCC 7.

Osamu

(*) https://github.com/arduino/arduino-preprocessor
https://github.com/arduino/arduino-builder

https://github.com/arduino/Arduino/wiki/Arduino-IDE-1.5-3rd-party-Hardware-specification

Bug#839102: (no subject)

[Michael Bemmerl]

David Bremner schrieb:
> 
> This is almost certainly related to the maintainer scripts using : as a
> replacement for newline when storing /etc/nullmailer/remotes in the
> debconf database.

I can confirm it is the sed command in postinst, line 36.
https://sources.debian.org/src/nullmailer/1:2.2-3/debian/postinst/#L36

I just executed that command manually on a dummy remotes file and it
exactly corrupted the config as described above.

Regards,
Michael



signature.asc
Description: OpenPGP digital signature

Bug#948694: [Python-modules-team] Bug#948694: Please consider upgrading to 0.7.11 to add python3.8 support

[Emmanuel Arias]

Hello Louis-Philippe,

I'ves just push to salsa the new upstream release. I will need
sponsorship for upload.

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

El sáb., 11 de ene. de 2020 a la(s) 21:09, Louis-Philippe Véronneau
(po...@debian.org) escribió:
>
> Package: src:ponyorm
> Version: 0.7.9-1
> Severity: whislist
>
> Dear maintainer, the current version of python3-pony in unstable isn't
> python3.8 compatible. As a result, I can't build the supysonic package
> (currently in NEW) with python3.8.
>
> Please consider uploading the latest upstream version (0.7.11), that
> supports python3.8.
>
> Cheers, and thanks for maintaining ponyorm in Debian!
>
> --
>   ⢀⣴⠾⠻⢶⣦⠀
>   ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
>   ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
>   ⠈⠳⣄
>
> ___
> Python-modules-team mailing list
> python-modules-t...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/python-modules-team

Bug#946242: fatal: privsep_preauth: preauth child terminated by signal 31

[Colin Watson]

On Sat, Jan 11, 2020 at 01:20:49PM +, Colin Watson wrote:
> I have some other things to do this weekend, but I'll chase this up with
> upstream and arrange for this to get into appropriate Debian packages.

It turned out that upstream had committed a fix a few days ago [1], so I
cherry-picked that into unstable and have filed a stable update request
as https://bugs.debian.org/948695.

[1] 
https://anongit.mindrot.org/openssh.git/commit/?id=30f704ebc0e9e32b3d12f5d9e8c1b705fdde2c89

-- 
Colin Watson   [cjwat...@debian.org]

Bug#948041: impossible to update libbpf without updating the kernel

[Sudip Mukherjee]

X-Debbugs-Cc: debian-de...@lists.debian.org

On Fri, Jan 03, 2020 at 08:23:58PM +, Sudip Mukherjee wrote:
> On Fri, Jan 3, 2020 at 7:49 PM Bastian Blank  wrote:
> >
> > Hi Marco
> >
> > On Fri, Jan 03, 2020 at 06:59:36PM +0100, Marco d'Itri wrote:
> > > On Jan 03, Sudip Mukherjee  wrote:
> > > > Do we package libbpf from their github repo independent of the kernel
> > > > update? Then we will need to remove the libbpf building bits from the
> > > > Debian kernel source and create a separate package for libbpf.
> > > This is what some of the upstream libbpf developers requested us to do.
> >
> > What I don't understand is, if the kernel git tree is the primary
> > location for this library, why should we use an external copy?
> >
> > What are the benefits of doing so?
> 
> The only benefit will be that we will be able to update the libraries
> irrespective of kernel update. libbpf v0.0.6 has been released in
> December but we will not be able to move to that version. The
> userspace application using this library is deprived of the benefit of
> the fixes that v0.0.6 brings.

Any thoughts on this please...

I have now done an initial packaging and can open an ITP if everyone
thinks we should move this out of debian kernel packaging.

And, I think I should also point out here that libtraceevent developers
are also moving to a separate repo which will have their final releases
rather then using the kernel repo. I will open a separate bug report for
them after they have decided where they want their new repo. And, libperf
might also follow suit after libtraceevent.

It might be better if we decide now what we want to do and tell them
accordingly.


--
Regards
Sudip

Bug#948695: buster-pu: package openssh/1:7.9p1-10+deb10u2

[Colin Watson]

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

https://bugs.debian.org/946242 reports an OpenSSH regression on old
kernels on certain architectures (e.g. i386) prompted by the interaction
between an OpenSSL update and a seccomp filter.  It's essentially the
same as https://bugs.debian.org/941663, but at the time we didn't notice
that the exact set of syscalls involved varies between architectures due
to details of how the shm* library functions are implemented in glibc.
I've attached the diff and would like approval to upload it.

In https://bugs.debian.org/941810 we decided that it was best to issue
this via buster-security; I think that would be the correct thing to do
here as well, so I've CCed team@security.  However, I'm filing this as a
stable update request just in case there's disagreement about that for
some reason.

Thanks,

-- 
Colin Watson   [cjwat...@debian.org]
diff -Nru openssh-7.9p1/debian/.git-dpm openssh-7.9p1/debian/.git-dpm
--- openssh-7.9p1/debian/.git-dpm   2019-10-06 19:17:34.0 +0100
+++ openssh-7.9p1/debian/.git-dpm   2020-01-12 00:06:24.0 +
@@ -1,6 +1,6 @@
 # see git-dpm(1) from git-dpm package
-35956d8211ef0a606a117ca3f0ba3ae163c31a39
-35956d8211ef0a606a117ca3f0ba3ae163c31a39
+6f794127bd7d332c1d88a3e35eda97dac4530a15
+6f794127bd7d332c1d88a3e35eda97dac4530a15
 3d246f10429fc9a37b98eabef94fe8dc7c61002b
 3d246f10429fc9a37b98eabef94fe8dc7c61002b
 openssh_7.9p1.orig.tar.gz
diff -Nru openssh-7.9p1/debian/changelog openssh-7.9p1/debian/changelog
--- openssh-7.9p1/debian/changelog  2019-10-06 19:18:07.0 +0100
+++ openssh-7.9p1/debian/changelog  2020-01-12 00:06:36.0 +
@@ -1,3 +1,13 @@
+openssh (1:7.9p1-10+deb10u2) UNRELEASED; urgency=medium
+
+  * Apply upstream patch to deny (non-fatally) ipc in the seccomp sandbox,
+fixing failures with OpenSSL 1.1.1d and Linux < 3.19 on some
+architectures (closes: #946242).  Note that this also drops the previous
+change to allow ipc on s390, since upstream has security concerns with
+that and it doesn't currently seem to be needed.
+
+ -- Colin Watson   Sun, 12 Jan 2020 00:06:36 +
+
 openssh (1:7.9p1-10+deb10u1) buster-security; urgency=high
 
   * Apply upstream patch to deny (non-fatally) shmget/shmat/shmdt in preauth
diff -Nru openssh-7.9p1/debian/patches/sandbox-seccomp-ipc.patch 
openssh-7.9p1/debian/patches/sandbox-seccomp-ipc.patch
--- openssh-7.9p1/debian/patches/sandbox-seccomp-ipc.patch  1970-01-01 
01:00:00.0 +0100
+++ openssh-7.9p1/debian/patches/sandbox-seccomp-ipc.patch  2020-01-12 
00:06:24.0 +
@@ -0,0 +1,48 @@
+From 6f794127bd7d332c1d88a3e35eda97dac4530a15 Mon Sep 17 00:00:00 2001
+From: Jeremy Drake 
+Date: Fri, 11 Oct 2019 18:31:05 -0700
+Subject: Deny (non-fatal) ipc in preauth privsep child.
+
+As noted in openssh/openssh-portable#149, i386 does not have have
+_NR_shmget etc.  Instead, it has a single ipc syscall (see man 2 ipc,
+https://linux.die.net/man/2/ipc).  Add this syscall, if present, to the
+list of syscalls that seccomp will deny non-fatally.
+
+[cjwatson: For backporting to buster, I've dropped the previous change
+to allow ipc on s390.  Upstream refused that since it opens security
+weaknesses and doesn't currently seem to be needed, so I'd already
+dropped that for bullseye.]
+
+Bug-Debian: https://bugs.debian.org/946242
+Origin: backport, 
https://anongit.mindrot.org/openssh.git/commit/?id=30f704ebc0e9e32b3d12f5d9e8c1b705fdde2c89
+Last-Update: 2020-01-11
+
+Patch-Name: sandbox-seccomp-ipc.patch
+---
+ sandbox-seccomp-filter.c | 6 +++---
+ 1 file changed, 3 insertions(+), 3 deletions(-)
+
+diff --git a/sandbox-seccomp-filter.c b/sandbox-seccomp-filter.c
+index e8f31555e..9b6aea8db 100644
+--- a/sandbox-seccomp-filter.c
 b/sandbox-seccomp-filter.c
+@@ -158,6 +158,9 @@ static const struct sock_filter preauth_insns[] = {
+ #ifdef __NR_shmdt
+   SC_DENY(__NR_shmdt, EACCES),
+ #endif
++#ifdef __NR_ipc
++  SC_DENY(__NR_ipc, EACCES),
++#endif
+ 
+   /* Syscalls to permit */
+ #ifdef __NR_brk
+@@ -205,9 +208,6 @@ static const struct sock_filter preauth_insns[] = {
+ #ifdef __NR_getuid32
+   SC_ALLOW(__NR_getuid32),
+ #endif
+-#if defined(__NR_ipc) && defined(__s390__)
+-  SC_ALLOW(__NR_ipc),
+-#endif
+ #ifdef __NR_madvise
+   SC_ALLOW(__NR_madvise),
+ #endif
diff -Nru openssh-7.9p1/debian/patches/series 
openssh-7.9p1/debian/patches/series
--- openssh-7.9p1/debian/patches/series 2019-10-06 19:17:34.0 +0100
+++ openssh-7.9p1/debian/patches/series 2020-01-12 00:06:24.0 +
@@ -33,3 +33,4 @@
 scp-handle-braces.patch
 revert-ipqos-defaults.patch
 seccomp-handle-shm.patch
+sandbox-seccomp-ipc.patch

Bug#839102: (no subject)

[David Bremner]

Michael Bemmerl  writes:

>
> FYI: This bug is also present in Version 1:2.2-3 (updating from stretch
> to buster).

This is almost certainly related to the maintainer scripts using : as a
replacement for newline when storing /etc/nullmailer/remotes in the
debconf database.

It all looks like a pretty bad idea to me, but I don't know how easy it
is to change.

d

Bug#948694: Please consider upgrading to 0.7.11 to add python3.8 support

[Louis-Philippe Véronneau]

Package: src:ponyorm
Version: 0.7.9-1
Severity: whislist

Dear maintainer, the current version of python3-pony in unstable isn't
python3.8 compatible. As a result, I can't build the supysonic package
(currently in NEW) with python3.8.

Please consider uploading the latest upstream version (0.7.11), that
supports python3.8.

Cheers, and thanks for maintaining ponyorm in Debian!

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



signature.asc
Description: OpenPGP digital signature

Bug#857454: qtltools: please make the build reproducible

[Chris Lamb]

Hi Andreas,

> > This appears to have reoccured:
[…]
> As Michael explained this is not the case in his recent upload
> any more.

Thanks for fixing. However, I think I'm missing something as I do not
see this aforementioned explanation on #857454?


Regards,

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

Bug#948693: RM: garmin-plugin -- RoQA; Useless; Upstream Dead;

[Boyuan Yang]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove

Dear FTP Masters,

Please remove package garmin-plugin from Sid archive. According to 
https://bugs.debian.org/948449 , this is a NPAPI plugin that has no support
from major web browsers now. Besides, its upstream (
https://github.com/adiesner/GarminPlugin) saw no activity since 2016.

Thanks,
Boyuan Yang


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

Bug#948692: "postconf -d maillog_file" doesn't show actual value

[Brian Wengel]

Package: postfix

Version:  3.4.7


Value in my main.cf:

maillog_file = /var/log/postfix.log


Result of "postconf -d | grep log_file":

maillog_file =
maillog_file_compressor = gzip
maillog_file_prefixes = /var, /dev/stdout
maillog_file_rotate_suffix = %Y%M%d-%H%M%S

Content in master.cf

 postlog   unix-dgram n  -   n   -   1   postlogd


I did restart the Postfile service and I can confirm logning to the file is
active and working (it was not before I activated it in the mail.cf file)

Bug#932989: gcc-avr: which upstream to track

[Osamu Aoki]

Hi

(The URL for avr-gcc for Linux in my previous post was wrong but it
isn't important ...)

Arduino seems to built avr-gcc with
  https://github.com/arduino/toolchain-avr

It's opening page states:
binutils-2.26
gcc-5.4.0
avr-libc-2.0.0
gdb-7.8

Not gcc-7.3.0 as released as 1.8.10 at
https://www.arduino.cc/en/Main/Software
as I see today.  It seems to patch upstream a bit.

Further check realized that, staging branch was using gcc-7.3.0 in code
   
https://github.com/arduino/toolchain-avr/commit/3e30e20948a5e3445823ecef23c007937b36583e
The applied patches are extensive!!! (Readme.md was not updated yet)

So this is one key resource.  Providing both avr-gcc 5.4.0 and 7.3.0 as
patched by Arduino toolchain-avr main and staging branches with
update-alternatives may be the best for next release.

I also found
   https://gcc.gnu.org/gcc-10/changes.html#avr

| Support for the XMEGA-like devices
|
| ATtiny202, ATtiny204, ATtiny402, ATtiny404, ATtiny406,
| ATtiny804, ATtiny806, ATtiny807, ATtiny1604, ATtiny1606,
| ATtiny1607, ATmega808, ATmega809, ATmega1608, ATmega1609,
| ATmega3208, ATmega3209, ATmega4808, ATmega4809
|
| has been added.
| A new command line option -nodevicespecs has been added. It allows
| to provide a custom device-specs file by means of
|
| avr-gcc -nodevicespecs -specs=my-spec-file 
|
| and without the need to provide options -B and -mmcu=. See AVR
| command line options for details. This feature is also available in
| v9.3+ and v8.4+.  New command line options -mdouble=[32,64] and
| -mlong-double=[32,64] have been added. They allow to chose the size
| (in bits) of the double and long double types, respectively. Whether
| or not the mentioned layouts are available, whether the options act
| as a multilib option, and what is the default for either option is
| controlled by the new AVR configure options --with-double= and
| --with-long-double=.  A new configure option --with-libf7= has been
| added. It controls to which level avr-libgcc provides 64-bit
| floating point support by means of Libf7.  A new configure option
| --with-double-comparison= has been added. It's unlikely you need to
| set this option by hand.

So gcc-10 had some AVR support efforts.

Osamu

Bug#948563: beignet and LLVM 8+

[Rebecca N. Palmer]

Progress so far:


compiler_rotate()ASSERTION FAILED: Unsupported intrinsics


The intrinsic in question is an fshl (funnel shift left).  I suspect 
this issue appeared because LLVM started optimizing rotates to this 
intrinsic:


https://github.com/llvm/llvm-project/commit/654e6aabb9f25d0d0fbad194ae6e26dd96c9e9db
https://github.com/llvm/llvm-project/commit/d023dd60e944886a9d5a0b1dbf46f67d43293af8

They say this shouldn't break targets that don't have a rotate 
instruction, but we may be doing weird enough things that this doesn't 
apply to us.



compiler_subgroup_buffer_block_write_ui1()ASSERTION FAILED: index <
this->size()


GenRegAllocator::Opaque::allocate 
(backend/src/backend/gen_reg_allocation.cpp:1268) uses reg = 
insn.src(srcID).reg() as an index, and this assert is that it is out of 
range.


As insn.src(srcID).physical=1 on the failing GenRegister object, it was 
probably created with the physical registers form of the constructor 
(backend/src/backend/gen_register.hpp:219), which leaves reg unset.


These tests start passing if I set it to 0, but I suspect this may not 
be a proper solution:


--- beignet-1.3.2.orig/backend/src/backend/gen_register.hpp
+++ beignet-1.3.2/backend/src/backend/gen_register.hpp
@@ -225,6 +225,7 @@ namespace gbe
uint32_t width,
uint32_t hstride)
 {
+this->value.reg = 0;//fix subgroup crash??
   this->type = type;
   this->file = file;
   this->nr = nr;

Bug#948691: firefox: breaks .config/mimeapps.list if started by thunderbird, breaking xdg-settings for whole system

[Bjørn Bürger]

Package: firefox
Version: 72.0.1-1
Severity: important

Hi,

if (and only if) firefox is spawned by clicking a link,
something in the detection code for "default browser"
setting is going crazy.

Steps to reproduce:

1) make firefox default webbrowser on a clean system
   and check current setting:

   $ xdg-settings get default-web-browser
   firefox.desktop

   $ cat .config/mimeapps.list

   [Default Applications]
   text/html=firefox.desktop
   x-scheme-handler/http=firefox.desktop
   x-scheme-handler/https=firefox.desktop
   x-scheme-handler/about=firefox.desktop
   x-scheme-handler/unknown=firefox.desktop

   This is fine.

2) start firefox, select preferences.
   It will tell you that ff is default

3) stop firefox

4) start thunderbird, click on any http(s) link
   wait for firefox to come up and check
   preferences again.

   Now, it will tell you, that it is NOT the default
   browser.

   However, it still is:

   $ xdg-settings get default-web-browser
   firefox.desktop

   $ cat .config/mimeapps.list

   [Default Applications]
   text/html=firefox.desktop
   x-scheme-handler/http=firefox.desktop
   x-scheme-handler/https=firefox.desktop
   x-scheme-handler/about=firefox.desktop
   x-scheme-handler/unknown=firefox.desktop


5) In firefox preferences, hit the "make default browser" button.
   Now, everything gets crazy:

   $ xdg-settings get default-web-browser
   thunderbird.desktop

   $ cat .config/mimeapps.list
   [Default Applications]
   text/html=thunderbird.desktop
   x-scheme-handler/http=thunderbird.desktop
   x-scheme-handler/https=thunderbird.desktop
   x-scheme-handler/about=firefox.desktop
   x-scheme-handler/unknown=firefox.desktop
   x-scheme-handler/ftp=thunderbird.desktop
   x-scheme-handler/chrome=thunderbird.desktop
   application/x-extension-htm=thunderbird.desktop
   application/x-extension-html=thunderbird.desktop
   application/x-extension-shtml=thunderbird.desktop
   application/xhtml+xml=thunderbird.desktop
   application/x-extension-xhtml=thunderbird.desktop
   application/x-extension-xht=thunderbird.desktop

   [Added Associations]
   x-scheme-handler/http=thunderbird.desktop;
   x-scheme-handler/https=thunderbird.desktop;
   x-scheme-handler/ftp=thunderbird.desktop;
   x-scheme-handler/chrome=thunderbird.desktop;
   text/html=thunderbird.desktop;
   application/x-extension-htm=thunderbird.desktop;
   application/x-extension-html=thunderbird.desktop;
   application/x-extension-shtml=thunderbird.desktop;
   application/xhtml+xml=thunderbird.desktop;
   application/x-extension-xhtml=thunderbird.desktop;
   application/x-extension-xht=thunderbird.desktop;

6) Now, links in any application using xdg-open
   won't work anymore. Thunderbird just crashes
   or ignores the load requests.

Please note:

* This Bug also affects firefox.esr
* If started from any other applikation, firefox behaves
  just normal. So far, only Thnuderbird triggers this
  behaviour.

-- Package-specific info:


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

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

Versions of packages firefox depends on:
ii  debianutils   4.9.1
ii  fontconfig2.13.1-2+b1
ii  libatk1.0-0   2.34.1-1
ii  libc6 2.29-8
ii  libcairo-gobject2 1.16.0-4
ii  libcairo2 1.16.0-4
ii  libdbus-1-3   1.12.16-2
ii  libdbus-glib-1-2  0.110-5
ii  libevent-2.1-72.1.11-stable-1
ii  libffi6   3.2.1-9
ii  libfontconfig12.13.1-2+b1
ii  libfreetype6  2.10.1-2
ii  libgcc1   1:9.2.1-22
ii  libgdk-pixbuf2.0-02.40.0+dfsg-2
ii  libglib2.0-0  2.62.4-1
ii  libgtk-3-03.24.13-1
ii  libnspr4  2:4.24-1
ii  libnss3   2:3.49-1
ii  libpango-1.0-01.42.4-8
ii  libsqlite3-0  3.30.1+fossil191229-1
ii  libstartup-notification0  0.12-6
ii  libstdc++69.2.1-22
ii  libx11-6  2:1.6.8-1
ii  libx11-xcb1   2:1.6.8-1
ii  libxcb-shm0   1.13.1-3
ii  libxcb1   1.13.1-3
ii  libxcomposite11:0.4.4-2
ii  libxdamage1   1:1.1.5-1
ii  libxext6  2:1.3.3-1+b2
ii  libxfixes31:5.0.3-1
ii  libxrender1   1:0.9.10-1
ii  libxt61:1.1.5-1+b3
ii  procps2:3.3.15-2+b1
ii  zlib1g1:1.2.11.dfsg-1+b1

Versions of packages firefox recommends:
ii  libavcodec57  7:3.4.3-1
ii  libavcodec58  7:4.2.1-2+b1

Versions of packages firefox suggests:
ii  

Bug#948687: libclc-amdgcn: OpenCL does not work for amdgpu : LLVM Error message

[Olaf Flebbe]

Oops the libclc source is current with respect to current llvm. Problem 
maybe located elsewhere

Bug#948690: RM: copyfs -- ROM; abandoned upstream

[Anuradha Weeraman]

Package: ftp.debian.org
Severity: normal

I request that this package be removed from the distribution as it is
unmaintained upstream with no upstream releases in over a decade.

-- 
Regards
Anuradha

Bug#948689: RM: jacksum -- ROM; unmaintained upstream

[Anuradha Weeraman]

Package: ftp.debian.org
Severity: normal

I request that this package be removed from the distribution as it is
unmaintained upstream with the last release made in 2006.

-- 
Regards
Anuradha

Bug#944078: [Pkg-utopia-maintainers] Bug#944078: firewall-applet: applet does not appear

[Michael Biebl]

Hi

On Mon, 4 Nov 2019 00:13:00 +0100 Michael Biebl  wrote:
> Am 04.11.19 um 00:11 schrieb Michael Biebl:
> > Am 03.11.19 um 23:51 schrieb Toni Mueller:
> 
> >> Now what...
> > 
> > I'd talk to the awesome maintainer and/or Qt5 maintainers.
> > 
> > I'm not really familiar with either of them.
> 
> That's the same buster VM, btw.


any updates here?
Since I'm not able to reproduce the issue, I'm not sure I can help you
unfortunately.


Regards,
Michael



signature.asc
Description: OpenPGP digital signature

Bug#856179: ITP: polybar -- fast and easy-to-use status bar

[Samuel Henrique]

Hello Jason,

I'm interested in having polybar packaged on Debian,

I can see that you closed the ITP of the other two libs libxpp and i3ipcpp
stating that they are no longer needed, and that the repository for
polybar's
packaging on salsa is not available anymore.

Do you have update0s on its packaging? I'd be happy to help or takeover from
where you stopped (if you have given up).

>From reading the discussion, I'm tempted to not split polybar's libs into
different
packages. I assume that's the current direction you're going as well.


Regards,

-- 
Samuel Henrique 

Bug#948681: [Pkg-utopia-maintainers] Bug#948681: firewalld: Nukes the existing network system without warning

[Michael Biebl]

Control: tags -1 moreinfo unreproducible

Am 11.01.20 um 21:42 schrieb Brad Rigby:
> Source: firewalld
> Severity: normal
> 
> Dear Maintainer,
> 
> The debian wiki notes that debian is moving from iptables to nftables, and 
> the nftables page suggests installing this package.  So I did.  
> Unfortunately, I did so via an ssh connection, as the computer in question is 
> a headless router.  As soon as aptitude quit I was booted from the system.  I 
> therefore needed to find a keyboard and monitor, and cables, to hook up to 
> this somewhat antiquated system in order to fix the problem.
> 
> Please give a warning somewhere that before installing, a person should have 
> physical access to the machine.  Even better would be a debconf wrapper to 
> allow configuration before the default completely nukes everything.

It doesn't nuke everything.
Installing firewalld will install a firewall with a default policy.
The default policy is to allow SSH for the public zone which is what you
should get after installation.

Fwiw, installing firewalld (which version are you using btw) in buster
via SSH works fine for me without interruptions:

> root@debian:~# iptables -L -n
> Chain INPUT (policy ACCEPT)
> target prot opt source   destination 
> ACCEPT all  --  0.0.0.0/00.0.0.0/0ctstate 
> RELATED,ESTABLISHED
> ACCEPT all  --  0.0.0.0/00.0.0.0/0   
> INPUT_direct  all  --  0.0.0.0/00.0.0.0/0   
> INPUT_ZONES_SOURCE  all  --  0.0.0.0/00.0.0.0/0   
> INPUT_ZONES  all  --  0.0.0.0/00.0.0.0/0   
> DROP   all  --  0.0.0.0/00.0.0.0/0ctstate INVALID
> REJECT all  --  0.0.0.0/00.0.0.0/0reject-with 
> icmp-host-prohibited
> 
> Chain FORWARD (policy ACCEPT)
> target prot opt source   destination 
> ACCEPT all  --  0.0.0.0/00.0.0.0/0ctstate 
> RELATED,ESTABLISHED
> ACCEPT all  --  0.0.0.0/00.0.0.0/0   
> FORWARD_direct  all  --  0.0.0.0/00.0.0.0/0   
> FORWARD_IN_ZONES_SOURCE  all  --  0.0.0.0/00.0.0.0/0   
> FORWARD_IN_ZONES  all  --  0.0.0.0/00.0.0.0/0   
> FORWARD_OUT_ZONES_SOURCE  all  --  0.0.0.0/00.0.0.0/0   
> FORWARD_OUT_ZONES  all  --  0.0.0.0/00.0.0.0/0   
> DROP   all  --  0.0.0.0/00.0.0.0/0ctstate INVALID
> REJECT all  --  0.0.0.0/00.0.0.0/0reject-with 
> icmp-host-prohibited
> 
> Chain OUTPUT (policy ACCEPT)
> target prot opt source   destination 
> OUTPUT_direct  all  --  0.0.0.0/00.0.0.0/0   
> 
> Chain INPUT_direct (1 references)
> target prot opt source   destination 
> 
> Chain INPUT_ZONES_SOURCE (1 references)
> target prot opt source   destination 
> 
> Chain INPUT_ZONES (1 references)
> target prot opt source   destination 
> IN_public  all  --  0.0.0.0/00.0.0.0/0   [goto] 
> 
> Chain FORWARD_direct (1 references)
> target prot opt source   destination 
> 
> Chain FORWARD_IN_ZONES_SOURCE (1 references)
> target prot opt source   destination 
> 
> Chain FORWARD_IN_ZONES (1 references)
> target prot opt source   destination 
> FWDI_public  all  --  0.0.0.0/00.0.0.0/0   [goto] 
> 
> Chain FORWARD_OUT_ZONES_SOURCE (1 references)
> target prot opt source   destination 
> 
> Chain FORWARD_OUT_ZONES (1 references)
> target prot opt source   destination 
> FWDO_public  all  --  0.0.0.0/00.0.0.0/0   [goto] 
> 
> Chain OUTPUT_direct (1 references)
> target prot opt source   destination 
> 
> Chain IN_public (1 references)
> target prot opt source   destination 
> IN_public_log  all  --  0.0.0.0/00.0.0.0/0   
> IN_public_deny  all  --  0.0.0.0/00.0.0.0/0   
> IN_public_allow  all  --  0.0.0.0/00.0.0.0/0   
> ACCEPT icmp --  0.0.0.0/00.0.0.0/0   
> 
> Chain IN_public_log (1 references)
> target prot opt source   destination 
> 
> Chain IN_public_deny (1 references)
> target prot opt source   destination 
> 
> Chain IN_public_allow (1 references)
> target prot opt source   destination 
> ACCEPT tcp  --  0.0.0.0/00.0.0.0/0tcp dpt:22 
> ctstate NEW,UNTRACKED
> 
> Chain FWDI_public (1 references)
> target prot opt source   destination 
> FWDI_public_log  all  --  0.0.0.0/00.0.0.0/0   
> FWDI_public_deny  all  --  0.0.0.0/00.0.0.0/0 

Bug#948688: RM: python-pyvcf [s390x] -- RoQA; remove unsupported arch binaries to allow testing migration

[Juhani Numminen]

Package: ftp.debian.org
X-Debbugs-Cc: debian-med-packag...@lists.alioth.debian.org

Hi,

Please remove binaries of src:python-pyvcf on s390x from unstable.
A new build-dependency of python-pyvcf, python-pysam, is not built on s390x.
Otherwise the old python-pyvcf binaries in sid that cannot be built anymore
will block the testing migration.


Thanks,
Juhani

Bug#948687: libclc-amdgcn: OpenCL does not work for amdgpu : LLVM Error message

[Olaf Flebbe]

Package: libclc-amdgcn
Version: 0.2.0+git20190827-2
Severity: important

Running an OpenCL application fails on amdgpu on (for instance Vega (RX470)
cards) with error messages

ac_rtld error: !s->is_rx
LLVM failed to upload shader

The upstream bugtracker seems to suggest that libclc may be outdated:

https://gitlab.freedesktop.org/mesa/mesa/issues/1431




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

Kernel: Linux 5.3.0-3-amd64 (SMP w/16 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_DE.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 libclc-amdgcn depends on:
ii  libclang-common-9-dev  1:9.0.1-2
ii  libclc-dev 0.2.0+git20190827-2

libclc-amdgcn recommends no packages.

libclc-amdgcn suggests no packages.

-- no debconf information

Bug#948567: elpa-elpy: elpa-find-file-in-project will not be automatically installed

[Nicholas D Steeves]

Dear Salman,

Thank you for reporting this bug and bringing the issue to my attention.
P.S. I'm treating this bug as a mentoring opportunity instead of just
fixing and closing, because we've worked together on MRs for this
package, but let me know if you'd rather I take care of it :-)

Salman Mohammadi  writes:

> A fresh installation of elpa-elpy does not install
> elpa-find-file-in-project automatically and running the command C-c C-f
> shows us this warning message:
>
> elpy-find-file: ‘elpy-find-file’ necessitates ‘projectile’ or
> ‘find-file-in-project’ to be installed.
>

With the new release upstream made ffip optional, and this message
indicates that the user can enable the desired functionality using
either projectile or ffip.  I'm of course biased towards ffip because I
use it, and maintain it and its dependency ivy.  As much as I'd like to
encourage users to use the software I work on and use by forcing them to
install it, that position isn't supported by Policy §7.2 [1].  Please
take the time to read it, and reply with which of the five dependency
types is most correct for this case--and why.  Keep in mind we try to
accommodate users who prefer to install as little as possible (to a
reasonable degree), the users who want "everything and the kitchen
sink", and everyone in between these two poles (the majority).  While I
might not be online when you are, someone at #debian-emacs or
#debian-mentors should be willing to discuss §7.2.

I plan to put the following in the appropriate field, preferring ffip,
because 1) It was previously a required dep  2) I don't know if
projectile works "out of the box", and I'm more comfortable supporting
ffip as a first choice  3) Elpy docs §"IDE Features" claims they're
alternatives to each other for the purpose of `elpy-find-file`  4) What
is probably the cause of #948567:

  elpa-find-file-in-project | projectile

> But as I checked the control file, elpa-find-file-in-project is in
> Build-Depends.
>

This is because one or more unit tests depend on it.  Optional
functionality that requires additional packages should be tested at
build time.  IIRC autopkgtest-pkg-elpa is installing the Build-Depends
in the autopkgtest environment, which is why they also pass there.


Regards,
Nicholas

[1] https://www.debian.org/doc/debian-policy/ch-relationships.html


signature.asc
Description: PGP signature

Bug#948686: RM: minizinc-ide [armel mips64el ppc64el s390x] -- RoQA; remove unsupported arch binaries to allow testing migration

[Juhani Numminen]

Package: ftp.debian.org
X-Debbugs-Cc: Kari Pahula 

It seems that a recent upload changed the build-dependencies
so the package now can't be built on [armel mips64el ppc64el s390x].
Please remove the binaries indicated in the message subject so that they
won't block eventual testing migration.

--
Juhani

Bug#948569: elpa-elpy: elpy-find-file: Symbol’s value as variable is void: ffip-prune-patterns

[Nicholas D Steeves]

Control: tags -1 + moreinfo

Dear Salman,

Salman Mohammadi  writes:
> after installing elpa-find-file-in-project, running the command C-c C-f
> shows us the following error message:
>
> elpy-find-file: Symbol’s value as variable is void: ffip-prune-patterns
>

Please provides steps to reproduce.  Here is what I see in the
minibuffer after installing Elpy into a clean schroot, elpy-enable,
opening a python file, and then C-c C-f:

  `elpy-find-file' necessitates `projectile' or `find-file-in-project' to be 
installed

This appears in the minibuffer and is consistent with upstream's claim
that ffip is no longer required (eg: it now gracefully handles missing
ffip).  They dropped the dependency because an ido user complained that
ffip, and thus Ivy, was cruft.  How were you able to trigger behaviour
that differs from what you reported in #948567?

ffip-5.7.7 has 'ffip-prune-patterns'
  debcheckout find-file-in-project
  ag ffip-prune-patterns find-file-in-project


Regards,
Nicholas


signature.asc
Description: PGP signature

Bug#948685: RM: gubbins [arm64 armel armhf mips64el mipsel ppc64el s390x] -- RoQA; remove unsupported arch binaries to allow testing migration

[Juhani Numminen]

Package: ftp.debian.org
X-Debbugs-Cc: debian-med-packag...@lists.alioth.debian.org

Hi,

Please remove gubbins binaries of release architectures other than amd64 & i386 
from unstable.
The package iqtree is x86-only, and it's a new build-dependency of gubbins.
Otherwise the old gubbins binaries in sid that cannot be built anymore
will block the testing migration.


Thanks,
Juhani

Bug#948684: RM: paleomix [arm64 mips64el ppc64el] -- RoQA; remove unsupported arch binaries to allow testing migration

[Juhani Numminen]

Package: ftp.debian.org
X-Debbugs-Cc: debian-med-packag...@lists.alioth.debian.org

Hi,

Please remove paleomix binaries of release architectures other than amd64 from 
unstable.
A build-dependency of paleomix, picard-tools, has become amd64-only.
Otherwise the remaining 1.2.13.3-1 binaries in sid will block the testing 
migration.


Thanks,
Juhani

Bug#948683: ruby-aws-sdk: pakage is broken

[David Suárez]

Package: ruby-aws-sdk
Version: 2.9.32-2
Severity: grave
Justification: renders package unusable

Hi,

The current version in experimental is broken, Running the tests on it 
gives:


/usr/bin/ruby2.5 /usr/bin/rspec 
/home/deiv/dev-dinamic/debian/pkgs/ruby/ruby-aws-sdk/aws-sdk-core/spec 
-I /usr/share/rubygems-integration/all/gems/aws-sdk-core-2.9.32/lib -I 
/home/deiv/dev-dinamic/debian/pkgs/ruby/ruby-aws-sdk/aws-sdk-core/spec
Warning: Error occurred while trying to load 
/home/deiv/dev-dinamic/debian/pkgs/ruby/ruby-aws-sdk/.simplecov. Error 
message: cannot load such file -- coveralls


An error occurred while loading 
/home/deiv/dev-dinamic/debian/pkgs/ruby/ruby-aws-sdk/aws-sdk-core/spec/aws/partitions_spec.rb.
Failure/Error: self.load(File.open(path, 'r', encoding: 'UTF-8') { |f| 
f.read })


Errno::ENOENT:
  No such file or directory @ rb_sysopen - 
/usr/share/rubygems-integration/all/gems/aws-sdk-core-2.9.32/lib/aws-sdk-core/../../endpoints.json
# 
/usr/share/rubygems-integration/all/gems/aws-sdk-core-2.9.32/lib/aws-sdk-core/json.rb:32:in 
`initialize'
# 
/usr/share/rubygems-integration/all/gems/aws-sdk-core-2.9.32/lib/aws-sdk-core/json.rb:32:in 
`open'
# 
/usr/share/rubygems-integration/all/gems/aws-sdk-core-2.9.32/lib/aws-sdk-core/json.rb:32:in 
`load_file'
# 
/usr/share/rubygems-integration/all/gems/aws-sdk-core-2.9.32/lib/aws-sdk-core/partitions.rb:148:in 
`defaults'
# 
/usr/share/rubygems-integration/all/gems/aws-sdk-core-2.9.32/lib/aws-sdk-core/partitions.rb:155:in 
`default_list'
# 
/usr/share/rubygems-integration/all/gems/aws-sdk-core-2.9.32/lib/aws-sdk-core.rb:388:in 
`partitions'
# 
/home/deiv/dev-dinamic/debian/pkgs/ruby/ruby-aws-sdk/aws-sdk-core/spec/aws/partitions_spec.rb:204:in 
`block (2 levels) in '
# 
/home/deiv/dev-dinamic/debian/pkgs/ruby/ruby-aws-sdk/aws-sdk-core/spec/aws/partitions_spec.rb:203:in 
`block in '
# 
/home/deiv/dev-dinamic/debian/pkgs/ruby/ruby-aws-sdk/aws-sdk-core/spec/aws/partitions_spec.rb:5:in 
`'
# 
/home/deiv/dev-dinamic/debian/pkgs/ruby/ruby-aws-sdk/aws-sdk-core/spec/aws/partitions_spec.rb:4:in 
`'
# 
/home/deiv/dev-dinamic/debian/pkgs/ruby/ruby-aws-sdk/aws-sdk-core/spec/aws/partitions_spec.rb:3:in 
`'

sh: 1: unsigns: not found
sh: 1: signs: not found
sh: 1: signs: not found


Finished in 0.00064 seconds (files took 1.23 seconds to load)
0 examples, 0 failures, 1 error occurred outside of examples

---



Updating this file 
(/usr/share/rubygems-integration/all/gems/aws-sdk-core-2.9.32/lib/aws-sdk-core/../../endpoints.json) 
by hand gives:


/usr/bin/ruby2.5 /usr/bin/rspec 
/home/deiv/dev-dinamic/debian/pkgs/ruby/ruby-aws-sdk/aws-sdk-core/spec 
-I /usr/share/rubygems-integration/all/gems/aws-sdk-core-2.9.32/lib -I 
/home/deiv/dev-dinamic/debian/pkgs/ruby/ruby-aws-sdk/aws-sdk-core/spec
Warning: Error occurred while trying to load 
/home/deiv/dev-dinamic/debian/pkgs/ruby/ruby-aws-sdk/.simplecov. Error 
message: cannot load such file -- coveralls


An error occurred while loading 
/home/deiv/dev-dinamic/debian/pkgs/ruby/ruby-aws-sdk/aws-sdk-core/spec/aws/partitions_spec.rb.
Failure/Error: self.load(File.open(path, 'r', encoding: 'UTF-8') { |f| 
f.read })


Errno::ENOENT:
  No such file or directory @ rb_sysopen - 
/usr/share/rubygems-integration/all/gems/aws-sdk-core-2.9.32/lib/aws-sdk-core/../../service-models.json
# 
/usr/share/rubygems-integration/all/gems/aws-sdk-core-2.9.32/lib/aws-sdk-core/json.rb:32:in 
`initialize'
# 
/usr/share/rubygems-integration/all/gems/aws-sdk-core-2.9.32/lib/aws-sdk-core/json.rb:32:in 
`open'
# 
/usr/share/rubygems-integration/all/gems/aws-sdk-core-2.9.32/lib/aws-sdk-core/json.rb:32:in 
`load_file'
# 
/usr/share/rubygems-integration/all/gems/aws-sdk-core-2.9.32/lib/aws-sdk-core/partitions.rb:164:in 
`service_ids'
# 
/usr/share/rubygems-integration/all/gems/aws-sdk-core-2.9.32/lib/aws-sdk-core/partitions/region.rb:49:in 
`region_services'
# 
/usr/share/rubygems-integration/all/gems/aws-sdk-core-2.9.32/lib/aws-sdk-core/partitions/region.rb:42:in 
`build'
# 
/usr/share/rubygems-integration/all/gems/aws-sdk-core-2.9.32/lib/aws-sdk-core/partitions/partition.rb:72:in 
`block in build_regions'
# 
/usr/share/rubygems-integration/all/gems/aws-sdk-core-2.9.32/lib/aws-sdk-core/partitions/partition.rb:70:in 
`each'
# 
/usr/share/rubygems-integration/all/gems/aws-sdk-core-2.9.32/lib/aws-sdk-core/partitions/partition.rb:70:in 
`inject'
# 
/usr/share/rubygems-integration/all/gems/aws-sdk-core-2.9.32/lib/aws-sdk-core/partitions/partition.rb:70:in 
`build_regions'
# 
/usr/share/rubygems-integration/all/gems/aws-sdk-core-2.9.32/lib/aws-sdk-core/partitions/partition.rb:60:in 
`build'
# 
/usr/share/rubygems-integration/all/gems/aws-sdk-core-2.9.32/lib/aws-sdk-core/partitions/partition_list.rb:52:in 
`block in build'
# 
/usr/share/rubygems-integration/all/gems/aws-sdk-core-2.9.32/lib/aws-sdk-core/partitions/partition_list.rb:51:in 
`each'
# 

Bug#839102: (no subject)

[Michael Bemmerl]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


Version: 1:2.2-3

FYI: This bug is also present in Version 1:2.2-3 (updating from stretch
to buster).
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (MingW32)

iEYEARECAAYFAl4aNgsACgkQKmk3pLlDYV77rQCcCvg66nbyPwE7wZ+Lf72AlDjy
MvwAn2ZqFfQXhSAYO78xXACjSLcZEa9C
=WYSA
-END PGP SIGNATURE-

Bug#948682: libparse-win32registry-perl FTBFS in the year 2020

[Adrian Bunk]

Source: libparse-win32registry-perl
Version: 1.0-2
Severity: serious
Tags: ftbfs

https://tests.reproducible-builds.org/debian/rb-pkg/stretch/amd64/libparse-win32registry-perl.html

...
Test Summary Report
---
t/entry.t   (Wstat: 6144 Tests: 536 Failed: 24)
  Failed tests:  120, 132, 144, 162, 168, 174, 252, 258
264, 270, 276, 282, 331, 343, 355, 373
379, 385, 463, 469, 475, 481, 487, 493
  Non-zero exit status: 24
t/file.t(Wstat: 512 Tests: 16 Failed: 2)
  Failed tests:  14-15
  Non-zero exit status: 2
t/key.t (Wstat: 18432 Tests: 613 Failed: 72)
  Failed tests:  314-315, 317, 322, 331-332, 334, 339, 348-349
351, 356, 365-366, 368, 373, 382-383, 385
390, 399-400, 402, 407, 416-417, 419, 424
433-434, 436, 441, 450-451, 453, 458, 467-468
470, 475, 484-485, 487, 492, 501-502, 504
509, 518-519, 521, 526, 535-536, 538, 543
552-553, 555, 560, 569-570, 572, 577, 586-587
589, 594, 603-604, 606, 611
  Non-zero exit status: 72
t/misc.t(Wstat: 14592 Tests: 217 Failed: 57)
  Failed tests:  65-66, 68-70, 72-74, 76-78, 80-82, 84-86
88-90, 92-94, 96-98, 100-102, 104-106, 108-110
112-114, 116-118, 120-122, 124-126, 128-130
132-134, 136-138, 140
  Non-zero exit status: 57
Files=13, Tests=4079,  3 wallclock secs ( 0.58 usr  0.04 sys +  1.90 cusr  0.26 
csys =  2.78 CPU)
Result: FAIL
Failed 4/13 test programs. 155/4079 subtests failed.
Makefile:1000: recipe for target 'test_dynamic' failed
make[1]: *** [test_dynamic] Error 255

Bug#948681: firewalld: Nukes the existing network system without warning

[Brad Rigby]

Source: firewalld
Severity: normal

Dear Maintainer,

The debian wiki notes that debian is moving from iptables to nftables, and the 
nftables page suggests installing this package.  So I did.  Unfortunately, I 
did so via an ssh connection, as the computer in question is a headless router. 
 As soon as aptitude quit I was booted from the system.  I therefore needed to 
find a keyboard and monitor, and cables, to hook up to this somewhat antiquated 
system in order to fix the problem.

Please give a warning somewhere that before installing, a person should have 
physical access to the machine.  Even better would be a debconf wrapper to 
allow configuration before the default completely nukes everything.



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

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

Bug#939989: transition: gdal

[Paul Gevers]

Hi,

On 11-01-2020 17:38, Sebastiaan Couwenberg wrote:
> On 1/9/20 6:52 PM, Sebastiaan Couwenberg wrote:
>> On 1/8/20 4:53 PM, Sebastiaan Couwenberg wrote:
>>> gdal (3.0.2+dfsg-1) is now built & installed on all release architectures.
>>>
>>> Please schedule the binNMUs.
>>
>> Thanks for scheduling the initial batch, everything has built now.
>> Please schedule the rest of Dependency level 1.
> 
> Now that openscenegraph is built & installed everywhere, please schedule
> osgearth.

gdal triggers autopkgtest regressions in two packages and looking at the
logs I am wondering if that point to a missing dependency relation, as
the tests pass in unstable once they were binNMU'ed.

In both tests, libgdal20 from testing is installed (due to the package
in testing not being build against the new library) but the new
gdal-data package is installed. Both tests show:
ERROR:  GDAL OpenFailed [4] Unable to open EPSG support file gcs.csv.
Try setting the GDAL_DATA environment variable to point to the directory
containing EPSG csv files.

Is this something that needs fixing in the gdal package somehow?
Probably I am saying something stupid, but e.g. gdal-data () breaks
libgdal* . I notice that the library already has a larger than
relation on gdal-data, but apparently there should have been a smaller
than relation as well. (As we can't fix the package in testing, I
proposed the breaks).

Can you please share your view of this problem?

Paul



signature.asc
Description: OpenPGP digital signature

Bug#948680: libtimedate-perl FTBFS in the year 2020

[Adrian Bunk]

Source: libtimedate-perl
Version: 2.3000-2
Severity: serious
Tags: ftbfs patch
Forwarded: https://github.com/gbarr/perl-TimeDate/pull/19

https://tests.reproducible-builds.org/debian/rb-pkg/stretch/amd64/libtimedate-perl.html

...
t/getdate.t .. 
1..146
# offset = 315576
--
FAIL 1
1995-01-24
Diff:-315576
Expect: 3946665600.00 Sun Jan 23 12:00:00 2095
Got:790905600.00 Mon Jan 23 12:00:00 1995
--
...
Test Summary Report
---
t/getdate.t (Wstat: 0 Tests: 0 Failed: 0)
  Parse errors: Bad plan.  You planned 146 tests but ran 0.
Files=5, Tests=362,  1 wallclock secs ( 0.13 usr  0.02 sys +  0.27 cusr  0.04 
csys =  0.46 CPU)
Result: FAIL
Failed 1/5 test programs. 0/362 subtests failed.
Makefile:942: recipe for target 'test_dynamic' failed
make[1]: *** [test_dynamic] Error 255

Bug#948679: speech-dispatcher: doesn't start, first due to /var/run/…/cache/… then Can't bind local socket

[Thorsten Glaser]

Package: speech-dispatcher
Version: 0.9.1-3
Severity: important

I installed orca to test something, but it doesn’t read out anything.


Following https://wiki.debian.org/accessibility#Speech-Dispatcher
I edited the config file and tried to stop and start it:

# /etc/init.d/speech-dispatcher start
Starting Speech Dispatcher: speech-dispatcherln: failed to create symbolic link 
'/var/run/speech-dispatcher/.cache/speech-dispatcher/log': No such file or 
directory


Creating that as root leads to:

# /etc/init.d/speech-dispatcher start
Starting Speech Dispatcher: speech-dispatcher[Sat Jan 11 21:20:08 2020 : 
170553] speechd: Speech Dispatcher 0.9.1 starting
Fatal error [speechd.c:849]:Can't bind local socket

The local socket appears to be in the filesystem, since after…

# chown -R speech-dispatcher /var/run/speech-dispatcher/

… it starts:

# /etc/init.d/speech-dispatcher start
Starting Speech Dispatcher: speech-dispatcher[Sat Jan 11 21:23:59 2020 : 
214754] speechd: Speech Dispatcher 0.9.1 starting
.

This is likely too over-zealous, though…


Going on further (no sound output), the logs aren’t happy:

= dummy.log
Error opening configuration file '/etc/speech-dispatcher/modules/dummy.conf'
 Sat Jan 11 21:27:33 2020 [275613] ALSA: Closing ALSA device
 Sat Jan 11 21:27:33 2020 [275702] ALSA: ALSA closed.
= generic.log
Error opening configuration file '/etc/speech-dispatcher/modules/generic.conf'
 Sat Jan 11 21:27:33 2020 [277118] ALSA: Closing ALSA device
 Sat Jan 11 21:27:33 2020 [277214] ALSA: ALSA closed.
= mary-generic.log
/etc/speech-dispatcher/modules/mary-generic.conf:33: Missing argument to option 
'GenericPunctNone'
 Sat Jan 11 21:27:33 2020 [277118] ALSA: Closing ALSA device
 Sat Jan 11 21:27:33 2020 [277214] ALSA: ALSA closed.

Line 33 reads:
   33 GenericPunctNone ""

This seems to be not liked.

Commenting out that line fixes this issue…

root@tglase-nb:/var/log/speech-dispatcher # cat mary-generic.log

 Sat Jan 11 21:30:19 2020 [279375] ALSA: Closing ALSA device
 Sat Jan 11 21:30:19 2020 [279475] ALSA: ALSA closed.

… but still, no sound.


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

Kernel: Linux 5.4.0-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

Versions of packages speech-dispatcher depends on:
ii  adduser  3.118
ii  init-system-helpers  1.57
ii  libc62.29-7
ii  libdotconf0  1.3-0.3
ii  libglib2.0-0 2.62.4-1
ii  libltdl7 2.4.6-11
ii  libsndfile1  1.0.28-6
ii  libspeechd2  0.9.1-3
ii  lsb-base 11.1.0
ii  speech-dispatcher-audio-plugins  0.9.1-3

Versions of packages speech-dispatcher recommends:
pn  pulseaudio   
pn  sound-icons  
pn  speech-dispatcher-espeak-ng  

Versions of packages speech-dispatcher suggests:
pn  espeak  
pn  libttspico-utils
pn  mbrola  
pn  speech-dispatcher-cicero
pn  speech-dispatcher-doc-cs
pn  speech-dispatcher-espeak
pn  speech-dispatcher-festival  
pn  speech-dispatcher-flite 

-- Configuration Files:
/etc/speech-dispatcher/speechd.conf changed:
LogLevel  3
LogDir  "default"
DefaultVolume 100
AudioOutputMethod "alsa"
DefaultModule espeak-ng
Include "clients/*.conf"


-- no debconf information

Bug#948634: debian-security-support: please elaborate on binutils' status

[Daniel Shahaf]

Good morning Salvatore,

Salvatore Bonaccorso wrote on Sat, Jan 11, 2020 at 09:07:30 +0100:
> Control: clone 948634 -1
> Control: reassign -1 src:binutils
> Control: retitle -1 binutils: Please add a README.Debian.security documenting 
> security support for binutils
> Control: blocked 948634 with -1
> 
> On Sat, Jan 11, 2020 at 02:28:14AM +, Daniel Shahaf wrote:
> > +++ b/security-support-limited
> > @@ -7,7 +7,7 @@
> > -binutilsNot covered by security support
> > +binutilsOnly suitable for trusted content; see 
> > https://lists.debian.org/msgid-search/87lfqsomtg@mid.deneb.enyo.de
> >  ganglia See README.Debian.security, only supported behind an 
> > authenticated HTTP zone, #702775
> >  ganglia-web See README.Debian.security, only supported behind an 
> > authenticated HTTP zone, #702776
> >  glpiOnly supported behind an authenticated HTTP zone for 
> > trusted users
> > 
> > @Florian That linked message is yours; any objections from you?
> 
> yes we can add that, but OTOH we asked the binutils maintainer already
> when we decided to mark it as unsupported, to please add a
> README.Debian.security file shipped in the package with a explanation,
> similar to the above, that there is none covering binutils by security
> updates (including upstream!). That would then be a slightly better
> reference to add, so I would rather go with that.

Yes, this make sense: binutils would document its own support status and
security-support-limited would simply point to README.Debian.security, as
it does for some other packages.

> The README.Debian.security file could contain something along the
> following lines:
> 
> > binutils (the tools the included libraries like libbfd) are not
> > covered by security support, i.e. bugfixes are not backported to
> > stable releases and will only land in the next release.
> 
> Matthias, could you add this?

I suggest to state not only the negative promise ("no security support") but
also the positive one (e.g., "Only suitable for use on trusted content").

Nitpicking: Suggest to change "next release" either to "next release (bullseye)"
or to "next point release" to clarify the intended meaning.

Thanks for the quick answer,

Daniel

Bug#948678: stretch-pu: package libbusiness-hours-perl/0.13-0+deb9u1

[Adrian Bunk]

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

  * New upstream release.
- Only change is a fix for a build and runtime failure
  with dates after 2018-12-31. (Closes: #934842)

Except for upstream metadata not shipped in the binary package
the changes in the new upstream version are this bugfix and
the version bump.
diff -Nru libbusiness-hours-perl-0.12/Changes 
libbusiness-hours-perl-0.13/Changes
--- libbusiness-hours-perl-0.12/Changes 2013-08-22 18:13:59.0 +0300
+++ libbusiness-hours-perl-0.13/Changes 2019-01-11 21:27:48.0 +0200
@@ -1,5 +1,10 @@
 Revision history for Perl module Business::Hours
 
+0.13
+  * Use explicit 4 digit years when using localtime. This fixes
+some test failures that started after 2018-12-31 because of
+date math.
+
 0.12
   * merge of 0.11 and 0.10_01:
   ** support shifts over midnight
diff -Nru libbusiness-hours-perl-0.12/debian/changelog 
libbusiness-hours-perl-0.13/debian/changelog
--- libbusiness-hours-perl-0.12/debian/changelog2016-03-17 
19:31:02.0 +0200
+++ libbusiness-hours-perl-0.13/debian/changelog2020-01-11 
21:36:25.0 +0200
@@ -1,3 +1,12 @@
+libbusiness-hours-perl (0.13-0+deb9u1) stretch; urgency=medium
+
+  * Non-maintainer upload.
+  * New upstream release.
+- Only change is a fix for a build and runtime failure
+  with dates after 2018-12-31. (Closes: #934842)
+
+ -- Adrian Bunk   Sat, 11 Jan 2020 21:36:25 +0200
+
 libbusiness-hours-perl (0.12-1) unstable; urgency=low
 
   * Initial Release. (Closes: #810812)
diff -Nru libbusiness-hours-perl-0.12/lib/Business/Hours.pm 
libbusiness-hours-perl-0.13/lib/Business/Hours.pm
--- libbusiness-hours-perl-0.12/lib/Business/Hours.pm   2013-08-22 
18:14:59.0 +0300
+++ libbusiness-hours-perl-0.13/lib/Business/Hours.pm   2019-01-11 
21:18:25.0 +0200
@@ -7,7 +7,7 @@
 use Set::IntSpan;
 use Time::Local qw/timelocal_nocheck/;
 
-our $VERSION = '0.12';
+our $VERSION = '0.13';
 
 =head1 NAME
 
@@ -272,6 +272,7 @@
 # jump back to the first day (Sunday) of the last week before the period
 # began.
 my @start= localtime( $args{'Start'} );
+$start[5] += 1900;  # Set 4 digit year, see perldoc localtime
 my $month= $start[4];
 my $year = $start[5];
 my $first_sunday = $start[3] - $start[6];
@@ -320,6 +321,7 @@
 
 my @today = (localtime($week_start))[3, 4, 5];
 $today[0]--; # compensate next increment
+$today[2] += 1900;  # Set 4 digit year
 
 # foreach day in the week, find that day's business hours in
 # seconds since the epoch.
@@ -352,6 +354,7 @@
 if ( my @holidays = $self->holidays ) {
 my $start_year = $year;
 my $end_year = (localtime $args{'End'})[5];
+$end_year += 1900;  # Set 4 digit year
 foreach my $holiday (@holidays) {
 my ($year, $month, $date) = ($holiday =~ 
/^(?:(\d\d\d\d)\D)?(\d\d)\D(\d\d)$/);
 $month--;
diff -Nru libbusiness-hours-perl-0.12/META.json 
libbusiness-hours-perl-0.13/META.json
--- libbusiness-hours-perl-0.12/META.json   2013-08-22 18:16:00.0 
+0300
+++ libbusiness-hours-perl-0.13/META.json   2019-01-11 21:32:15.0 
+0200
@@ -4,7 +4,7 @@
   "Jesse Vincent (je...@cpan.org)"
],
"dynamic_config" : 1,
-   "generated_by" : "ExtUtils::MakeMaker version 6.72, CPAN::Meta::Converter 
version 2.131560",
+   "generated_by" : "ExtUtils::MakeMaker version 7.3, CPAN::Meta::Converter 
version 2.150005",
"license" : [
   "unknown"
],
@@ -38,5 +38,6 @@
   }
},
"release_status" : "stable",
-   "version" : "0.12"
+   "version" : "0.13",
+   "x_serialization_backend" : "JSON::PP version 2.27300"
 }
diff -Nru libbusiness-hours-perl-0.12/META.yml 
libbusiness-hours-perl-0.13/META.yml
--- libbusiness-hours-perl-0.12/META.yml2013-08-22 18:16:00.0 
+0300
+++ libbusiness-hours-perl-0.13/META.yml2019-01-11 21:32:15.0 
+0200
@@ -3,21 +3,22 @@
 author:
   - 'Jesse Vincent (je...@cpan.org)'
 build_requires:
-  ExtUtils::MakeMaker: 0
+  ExtUtils::MakeMaker: '0'
 configure_requires:
-  ExtUtils::MakeMaker: 0
+  ExtUtils::MakeMaker: '0'
 dynamic_config: 1
-generated_by: 'ExtUtils::MakeMaker version 6.72, CPAN::Meta::Converter version 
2.131560'
+generated_by: 'ExtUtils::MakeMaker version 7.3, CPAN::Meta::Converter version 
2.150005'
 license: unknown
 meta-spec:
   url: http://module-build.sourceforge.net/META-spec-v1.4.html
-  version: 1.4
+  version: '1.4'
 name: Business-Hours
 no_index:
   directory:
 - t
 - inc
 requires:
-  Set::IntSpan: 1.12
-  Time::Local: 0
-version: 0.12
+  Set::IntSpan: '1.12'
+  Time::Local: '0'
+version: '0.13'
+x_serialization_backend: 'CPAN::Meta::YAML version 0.012'
diff -Nru libbusiness-hours-perl-0.12/SIGNATURE 
libbusiness-hours-perl-0.13/SIGNATURE
--- libbusiness-hours-perl-0.12/SIGNATURE   

Bug#948676: at-spi2-core: /etc/X11/Xsession.d/90qt-a11y does not enable Qt5 support as the Wiki indicates

[Thorsten Glaser]

Package: at-spi2-core
Version: 2.34.0-3
Severity: normal

https://wiki.debian.org/accessibility-devel says it should export
QT_LINUX_ACCESSIBILITY_ALWAYS_ON=1 but it doesn’t.

Exporting that before starting MuseScore makes the latter show up
in “orca -l” output, so it’s probably needed.

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

Kernel: Linux 5.4.0-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

Versions of packages at-spi2-core depends on:
ii  libatspi2.0-0  2.34.0-3
ii  libc6  2.29-7
ii  libdbus-1-31.12.16-2
ii  libglib2.0-0   2.62.4-1
ii  libx11-6   2:1.6.8-1
ii  libxtst6   2:1.2.3-1

at-spi2-core recommends no packages.

at-spi2-core suggests no packages.

-- no debconf information

Bug#948677: RM: ncl [mips64el] -- RoQA; Architecture specific issue

[Bas Couwenberg]

Package: ftp.debian.org
Severity: normal

Please remove ncl from mips64el where it FTBFS due to an architecture specific 
issue.

It depends on libgdal20 which is going away after the transition (#939989).

Kind Regards,

Bas

Bug#948671: libsmbclient: mounting a share from Windows XP fails on timeout

[Горбешко Богдан]

#samba:freenode.net, sorry.

On 11.01.2020 18:24, Горбешко Богдан wrote:

Package: libsmbclient
Version: 2:4.11.3+dfsg-1
Severity: important

Dear Maintainer,

after an upgrade to smbclient=2:4.11.3+dfsg-1 (actually, some earlier 
version
is affected too) I lost an ability to mount a share from Windows XP 
machine.

Several clients that utilize libsmbclient (smbclient, Double Commander's
"Windows Network" plugin, gio mount) hang for a while and fail on 
timeout. So I
had to roll smbclient back to 2:4.9.5+dfsg-5+deb10u1, as well as some 
other

dependencies, where it works well.

I have already asked about it on #smbclient:freenode.net, and qman__ 
told:


Jan 01 01:44:25     there have been several breaking security
patches to SMB both on windows and samba since Windows XP went EOL
Jan 01 01:44:55     I would be more surprised if you could 
get it

to work

But I couldn't see any CVE fixes in recent changelog that should 
prevent SMB1
from working at all, and the support for it doesn't seem to be removed 
from

libsmbclient yet, so it looks like an unintentional bug.



-- System Information:
Debian Release: bullseye/sid
  APT prefers testing-debug
  APT policy: (500, 'testing-debug'), (500, 'oldoldstable-updates'), 
(500, 'oldoldstable'), (500, 'testing')

Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.3.0-2-amd64 (SMP w/2 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=ru_UA.UTF-8, LC_CTYPE=ru_UA.UTF-8 (charmap=UTF-8), 
LANGUAGE=ru_UA:ru (charmap=UTF-8)

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

Versions of packages libsmbclient depends on:
ii  dpkg    1.19.7
ii  libbsd0 0.10.0-1
ii  libc6   2.29-7
ii  libtalloc2  2.3.0-3
ii  libtevent0  0.10.1-4
hi  samba-libs  2:4.9.5+dfsg-5+deb10u1

libsmbclient recommends no packages.

libsmbclient suggests no packages.

-- no debconf information

Bug#832370: ITA: autopsy -- graphical interface to SleuthKit

[jmsrdebian]

Hi,

I intent to adopt the autopsy -- graphical interface to SleuthKit.

Jair Reis

Sent with [ProtonMail](https://protonmail.com) Secure Email.

Bug#946931: [Pkg-kde-extras] Bug#946931: Bug#946931: quassel-core: apparmor denials

[Scott Kitterman]

On Saturday, January 11, 2020 9:59:53 AM EST Felix Geyer wrote:
> On 11.01.20 02:58, Scott Kitterman wrote:
> > I gave this a try and I still get apparmor denials:
> > 
> > Jan 10 20:54:13 relay02 kernel: [ 1372.562938] audit: type=1400
> > audit(1578707653.245:28): apparmor="DENIED" operation="open"
> > profile="/usr/bin/ quasselcore" name="/proc/sys/kernel/random/boot_id"
> > pid=1588
> > comm="quasselcore" requested_mask="r" denied_mask="r" fsuid=116 ouid=0
> > 
> > Jan 10 20:54:13 relay02 kernel: [ 1372.562955] audit: type=1400
> > audit(1578707653.245:29): apparmor="DENIED" operation="open"
> > profile="/usr/bin/ quasselcore" name="/var/lib/dbus/machine-id" pid=1588
> > comm="quasselcore" requested_mask="r" denied_mask="r" fsuid=116 ouid=0
> > 
> > Jan 10 20:54:13 relay02 kernel: [ 1372.576629] audit: type=1400
> > audit(1578707653.257:30): apparmor="DENIED" operation="link"
> > profile="/usr/bin/ quasselcore" name="/var/lib/quassel/quasselcore.conf"
> > pid=1588
> > comm="quasselcore" requested_mask="l" denied_mask="l" fsuid=116 ouid=116
> > target="/var/lib/quassel/#523668"
> > 
> > Suggestions?
> 
> Are you sure you have reloaded the AppArmor profile (apparmor_parser -r
> /etc/apparmor.d/usr.bin.quasselcore)?
> Maybe restart quasselcore if that still does not work.
> 
> I can't see how these denials can happen with the updated profile.

That did it.  I'd neglected to tell apparmor to load the updated profile.

> On 11.01.20 14:49, Thomas Schneider wrote:
>  > I agree on the change '/var/lib/quassel/** rwkl' (although AA convention
>  > seems to be 'rwkl', but that’s just cosmetic), but I would suggest
>  > adding '#include ' instead of
>  > specifying the IDs manually.
> 
> quasselcore doesn't use dbus. Qt just happens to read the the dbus
> machine-id file. The intent for the dbus-session-strict abstraction is
> "allow access to the dbus session bus" so that's not appropriate for
> quasselcore.
> 
>  > Said 'abstractions/dbus-session-strict' does not allow access to
>  > '@{PROC}/sys/kernel/random/boot_id', but I didn’t get any audit messages
>  > about that after including the abstraction.  I haven’t looked any
>  > further into it, but maybe it isn’t needed?
> 
> These files are only read when quasselcore updates its config which likely
> doesn't happen very often.
> 
> Cheers,
> Felix

Thanks.  Now that I've successfully tested it, I'll upload.

Scott K



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

Bug#943654: anbox: GUI crashes after "starting"

[Matheus]

Hello,
Sorry for the late reply.

I've downloaded the android image in
, renamed from
"android_amd64.img" to "android.img" and put in `/var/lib/anbox`.
But I couldn't start the systemd services mentioned in `README.Debian`.

Here it is the output of the commands:

> maeslor@hactar:~$ ls /var/lib/anbox/android.img
> /var/lib/anbox/android.img
>
> maeslor@hactar:~$ systemctl status anbox-container-manager.service
> ● anbox-container-manager.service - Anbox Container Manager
> Loaded: loaded (/lib/systemd/system/anbox-container-manager.service; enabled;
> Active: inactive (dead)
> Condition: start condition failed at Sat 2020-01-11 15:07:43 -03; 43min ago
>Docs: man:anbox(1)
>
> maeslor@hactar:~$ systemctl --user status anbox-session-manager.service
> ● anbox-session-manager.service - Anbox Session Manager
> Loaded: loaded (/usr/lib/systemd/user/anbox-session-manager.service; disabled
> Active: inactive (dead)
>Docs: man:anbox(1)





Em dom., 27 de out. de 2019 às 14:53, Shengjing Zhu  escreveu:
>
> On Sun, Oct 27, 2019 at 10:48 PM Matheus Mello  
> wrote:
> >
> > Package: anbox
> > Version: 0.0~git20190124-1
> > Severity: grave
> > Justification: renders package unusable
> >
> > Dear Maintainer,
> >
> > Anbox does not start the Graphical Application after correctly installing 
> > the
> > Debian package. The application shows a boot image with "Starting", but it
> > crashes after a few seconds and the program turns unusable.
> >
>
> Have you ever followed the instructions in /usr/share/doc/anbox/README.Debian?
>
> Notably, is the Android image downloaded, and the status of two
> systemd services.
>
> Please run following commands and give back your results.
>
> ls /var/lib/anbox/android.img
> systemctl status anbox-container-manager.service
> systemctl --user status anbox-session-manager.service
>
> --
> Shengjing Zhu

Bug#948674: RFP: otter-browser -- Fast and configurable web browser inspired by Opera 12

[Laurence Colombet]

Package: wnpp
Severity: wishlist

* Package name: otter-browser
  Version : 
  Upstream Author : Emdek (https://github.com/Emdek)
* URL : https://www.otter-browser.org/
* License : GPL v3.0
  Programming Lang: C++
  Description : Fast and configurable web browser inspired by Opera 12

Otter Browser aims to recreate the best aspects of Opera 12 and to revive
its spirit. It is focused on providing the powerful features power users
want while keeping the browser fast and lightweight.

Among its advantages over other web browsers, it is fast, its user interface
is configurable, it allows per-site overriding of configuration options, it
aims to be modular. On the scale of coercing its users into a predefined
path for the sake of "simplicity" and allowing them to stay in control of
their own web browsing experience, it stands firmly on the side of the user.

The source code is hosted on GitHub:
https://github.com/OtterBrowser/otter-browser

Bug#948673: version 2019.11

[Bastian Germann]

Package: src:swupdate
Severity: normal

The swupdate project has release the stable version 2019.11. I have
prepared the necessary changes to the package information at
https://salsa.debian.org/debian/swupdate/merge_requests/1

Please consider uploading 2019.11-1 to sid.

Bug#947899: xerces-c: FTBFS on ports without java support

[Bill Blough]

Thanks for the report and patch.  I'm still getting caught up from the
holidays, so it will be a little bit longer before I get to this.

If it's a blocker for you, please feel free to NMU. Otherwise, I'll
update the package in the next week or two.

Bug#948670: wmauda FTCBFS: uses the build architecture pkg-config

[Jeremy Sowden]

On 2020-01-11, at 16:15:23 +0100, Helmut Grohne wrote:
> Source: wmauda
> Version: 0.9-1
> Tags: patch upstream
> User: debian-cr...@lists.debian.org
> Usertags: ftcbfs
>
> wmauda fails to cross build from source, because the upstream Makefile
> hard codes the build architecture pkg-config. After making it
> substitutable, wmauda cross builds successfully as dh_auto_build
> provides the correct substitution. Please consider applying the attached
> patch.

Applied.

J.


signature.asc
Description: PGP signature

Bug#931488: Fixed upstream in jack2 1.9.13

[Joseph Yasi]

This was marked fixed in NMU, but no NMU update was ever pushed. This
bug causes other programs (e.g. kodi) to crash that aren't even using
the jack daemon when they scan ALSA devices due to ALSA including the
jack plugin.

On Wed, Oct 30, 2019 at 10:40 AM Joseph Yasi  wrote:
>
> This was fixed upstream in jack2 1.9.13. Pushing a new release will
> take care of this.

Bug#944913: python3-sphinx: Please update to Sphinx 2.2.1

[Dmitry Shachnev]

Hi Sandro!

On Fri, Jan 10, 2020 at 07:06:08PM -0500, Sandro Tosi wrote:
> Hey Dmitry,
> please note that the relatively old version of sphinx we have in
> Debian now makes it not possible to upgrade scikit-learn
> (https://github.com/scikit-learn/scikit-learn/issues/16087#issuecomment-573092993),
> which we require to upgrade as the scikit-learn version we have in
> unstable now FTBFS due to other modules/libraries being upgraded,
> compatibility which is fixed in the new version and... you got the
> idea :)
>
> I understand it may be more work, but i suspect that splitting sphinx
> 1.8 and 2.* is probably the best way forward to allow continuous
> compatibility with already-existing packages and the upgrade of those
> modules that require a newer version.
>
> please let me know what you think

I am slowly working on Sphinx 2.x in Debian. It is quite tricky because some
builders have been split into separate modules on PyPI, so I need either to
package them separately or patch out dependencies on them.

As my time is limited, expect it to be ready in several weeks, not earlier.
After that I will see whether it’s possible to make it coexist with sphinx 1.8
for Python 2.

--
Dmitry Shachnev

Bug#948672: qa.debian.org: popcon-graph the graph does not show information later than 2019-12-31

[Felix Dörre]

Package: qa.debian.org
Severity: important

Dear Maintainer,

The popcon graphs on qa.debian.org stop showing data from 2019-12-31 on. 
Compare for example:

https://qa.debian.org/popcon-graph.php?packages=primus_installed=on_vote=on_old=on_recent=on_nofiles=on_legend=on_ticks=on_date=2019-12-01_date=2020-02-01_date=_fmt=%25Y-%25m-%25d=1

The graphs stop at 2019-12-31 although there should already be data for 10 
newer days. This issue seems to affect all packages.

Until this issue occured the package graphs contained recent data updating 
every day, so I expect the graphs to contain data until the current day.

Bug#939989: transition: gdal

[Sebastiaan Couwenberg]

On 1/9/20 6:52 PM, Sebastiaan Couwenberg wrote:
> On 1/8/20 4:53 PM, Sebastiaan Couwenberg wrote:
>> gdal (3.0.2+dfsg-1) is now built & installed on all release architectures.
>>
>> Please schedule the binNMUs.
> 
> Thanks for scheduling the initial batch, everything has built now.
> Please schedule the rest of Dependency level 1.

Now that openscenegraph is built & installed everywhere, please schedule
osgearth.

Kind Regards,

Bas

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



signature.asc
Description: OpenPGP digital signature

Bug#948671: libsmbclient: mounting a share from Windows XP fails on timeout

[Горбешко Богдан]

Package: libsmbclient
Version: 2:4.11.3+dfsg-1
Severity: important

Dear Maintainer,

after an upgrade to smbclient=2:4.11.3+dfsg-1 (actually, some earlier 
version

is affected too) I lost an ability to mount a share from Windows XP machine.
Several clients that utilize libsmbclient (smbclient, Double Commander's
"Windows Network" plugin, gio mount) hang for a while and fail on 
timeout. So I

had to roll smbclient back to 2:4.9.5+dfsg-5+deb10u1, as well as some other
dependencies, where it works well.

I have already asked about it on #smbclient:freenode.net, and qman__ told:

Jan 01 01:44:25     there have been several breaking security
patches to SMB both on windows and samba since Windows XP went EOL
Jan 01 01:44:55     I would be more surprised if you could 
get it

to work

But I couldn't see any CVE fixes in recent changelog that should prevent 
SMB1

from working at all, and the support for it doesn't seem to be removed from
libsmbclient yet, so it looks like an unintentional bug.



-- System Information:
Debian Release: bullseye/sid
  APT prefers testing-debug
  APT policy: (500, 'testing-debug'), (500, 'oldoldstable-updates'), 
(500, 'oldoldstable'), (500, 'testing')

Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.3.0-2-amd64 (SMP w/2 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=ru_UA.UTF-8, LC_CTYPE=ru_UA.UTF-8 (charmap=UTF-8), 
LANGUAGE=ru_UA:ru (charmap=UTF-8)

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

Versions of packages libsmbclient depends on:
ii  dpkg    1.19.7
ii  libbsd0 0.10.0-1
ii  libc6   2.29-7
ii  libtalloc2  2.3.0-3
ii  libtevent0  0.10.1-4
hi  samba-libs  2:4.9.5+dfsg-5+deb10u1

libsmbclient recommends no packages.

libsmbclient suggests no packages.

-- no debconf information

Bug#948670: wmauda FTCBFS: uses the build architecture pkg-config

[Helmut Grohne]

Source: wmauda
Version: 0.9-1
Tags: patch upstream
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

wmauda fails to cross build from source, because the upstream Makefile
hard codes the build architecture pkg-config. After making it
substitutable, wmauda cross builds successfully as dh_auto_build
provides the correct substitution. Please consider applying the attached
patch.

Helmut
--- wmauda-0.9.orig/Makefile
+++ wmauda-0.9/Makefile
@@ -1,5 +1,6 @@
 CC	?= gcc
 CFLAGS	?= -g -pipe
+PKG_CONFIG ?= pkg-config
 
 PREFIX	?= /usr/local
 
@@ -7,11 +8,11 @@
 PIXMAP_DIR	:= $(PREFIX)/share/pixmaps
 MANPAGE_DIR	:= $(PREFIX)/share/man/man1
 
-CFLAGS 	+= $(shell pkg-config dbus-glib-1 --cflags) -DPIXMAP_DIR="\"$(PIXMAP_DIR)\""
-LIBS 	:= $(shell pkg-config audclient --libs)  $(shell pkg-config dbus-glib-1 --libs)
+CFLAGS 	+= $(shell $(PKG_CONFIG) dbus-glib-1 --cflags) -DPIXMAP_DIR="\"$(PIXMAP_DIR)\""
+LIBS 	:= $(shell $(PKG_CONFIG) audclient --libs)  $(shell $(PKG_CONFIG) dbus-glib-1 --libs)
 
-CFLAGS  += $(shell pkg-config gtk+-2.0 --cflags)
-LIBS+= $(shell pkg-config gtk+-2.0 --libs) -lX11
+CFLAGS  += $(shell $(PKG_CONFIG) gtk+-2.0 --cflags)
+LIBS+= $(shell $(PKG_CONFIG) gtk+-2.0 --libs) -lX11
 
 OBJS 	= wmauda.o
 HEADERS = dock-master.xpm

Bug#948669: libtest-mocktime-perl: test fails in 2020

[Adrian Bunk]

Source: libtest-mocktime-perl
Version: 0.15-1
Severity: serious
Tags: ftbfs
Forwarded: https://rt.cpan.org/Public/Bug/Display.html?id=124508
Control: close -1 0.16-1

https://tests.reproducible-builds.org/debian/rb-pkg/stretch/amd64/libtest-mocktime-perl.html

...
#   Failed test 'localtime seems ok'
#   at t/test.t line 43.
# Looks like you failed 1 test of 11.
t/test.t . 
...

Bug#948668: libole-storage-lite-perl: y2k20 problem

[Adrian Bunk]

Source: libole-storage-lite-perl
Version: 0.19-1
Severity: serious
Tags: ftbfs
Forwarded: https://rt.cpan.org/Public/Bug/Display.html?id=124513
Control: close -1  0.20-1

https://tests.reproducible-builds.org/debian/rb-pkg/stretch/amd64/libole-storage-lite-perl.html

...

#   Failed test '   LocalDate2OLE: Thu Jan  1 00:00:00 1970
'
#   at t/01_date_conversion.t line 40.
#  got: '0040352757CF0D02'
# expected: '00803ED5DEB19D01'

#   Failed test '   LocalDate2OLE: Thu Jan  1 00:00:01 1970
'
#   at t/01_date_conversion.t line 40.
#  got: '80D6CD2757CF0D02'
# expected: '8016D7D5DEB19D01'

#   Failed test '   LocalDate2OLE: Mon Feb 16 06:28:15 1970
'
#   at t/01_date_conversion.t line 40.
#  got: '80A91C03B3F30D02'
# expected: '80E925B13AD69D01'

#   Failed test '   LocalDate2OLE: Fri Dec 11 08:49:03 1970
'
#   at t/01_date_conversion.t line 40.
#  got: '80A99C0DF2DD0E02'
# expected: '80E9A5BB79C09E01'
# Looks like you failed 4 tests of 198.
t/01_date_conversion.t .. 
...


libole-storage-lite-perl (0.20-1) unstable; urgency=medium

  * Import upstream version 0.20.
Fixes y2k20 problem, as seen also on ci.debian.net.
...
 -- gregor herrmann   Thu, 02 Jan 2020 17:26:42 +0100

Bug#948667: nautilus: Copying >32768 files over ssh causes hang

[André R . Offringa]

Package: nautilus
Version: 3.34.1-1
Severity: normal

Dear Maintainer,

Copying a directory with over approximately 32,768 files to a different server 
causes the process to hang when copying the approx 32,768th file. It was 
produced as follows:
- I'm trying to copy my home directory to a different server. The directory 
contains ~51,000 files
- In nautulus, I browse to /home, select my home directory, right click and 
press 'copy'
- I press "Other locations", and type in ssh:// followed by the ip address of 
my server
- I browse to the correct dir
- I right click and press paste.
- The copying commences and after a moment starts copying the files and making 
progress. It correctly lists that it is going to copy ~51,000 files.
- When it has reached file 32,768 (after 1h), the process hangs. The progress 
frame shows "Copying 51,000 files to ", and under the progress bar 
it says "32,768 / 51,000 - 5 hours left (3 mb/s)"
- The server has indeed received files. `find -type f|wc -l` results 32723, 
whereas `find|wc -l` results in 35765.

I'm not 100% the progress window said it was exactly at 32,768.

Restarting the copy, I am asked whether I want to merge the directories. 
Selecting to merge, and subsequently selecting skip on whether to overwrite 
files, causes the process in the end to hang at the same position. Only now it 
says (after waiting a while) 'Copying 17,721 files to ; 3,007 / 
17,721 - 596,523 hours left (0 bytes/sec)' -- of course because it has now 
skipped ~32768 files.

Regards,
Andre

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

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

Versions of packages nautilus depends on:
ii  bubblewrap  0.4.0-1
it  desktop-file-utils  0.24-1
ii  gsettings-desktop-schemas   3.34.0-2
ii  gvfs1.42.1-3
ii  libatk1.0-0 2.34.1-1
ii  libc6   2.29-7
ii  libcairo-gobject2   1.16.0-4
ii  libcairo2   1.16.0-4
iu  libgdk-pixbuf2.0-0  2.40.0+dfsg-2
ii  libgexiv2-2 0.12.0-1
it  libglib2.0-02.62.4-1
ii  libglib2.0-data 2.62.4-1
ii  libgnome-autoar-0-0 0.2.3-2
ii  libgnome-desktop-3-18   3.34.2-2
ii  libgstreamer-plugins-base1.0-0  1.16.2-2
ii  libgstreamer1.0-0   1.16.2-2
ii  libgtk-3-0  3.24.13-1
ii  libnautilus-extension1a 3.34.1-1
ii  libpango-1.0-0  1.42.4-7
ii  libpangocairo-1.0-0 1.42.4-7
ii  libselinux1 3.0-1
ii  libtracker-sparql-2.0-0 2.1.8-2
ii  nautilus-data   3.34.1-1
it  shared-mime-info1.10-1
ii  tracker 2.1.8-2
ii  tracker-extract 2.1.6-1
ii  tracker-miner-fs2.1.6-1

Versions of packages nautilus recommends:
pn  gnome-sushi  
ii  gvfs-backends1.42.1-3
ii  librsvg2-common  2.46.4-1

Versions of packages nautilus suggests:
pn  eog 
ii  mpg321 [mp3-decoder]0.3.2-3
ii  nautilus-extension-brasero  3.12.2-6
pn  nautilus-sendto 
ii  okular [pdf-viewer] 4:17.12.2-2.2+b1
iu  vlc [mp3-decoder]   3.0.8-3+b3
ii  xdg-user-dirs   0.17-2

-- no debconf information

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

[Laura Arjona Reina]

Hello

El 10/1/20 a las 20:55, Holger Wansing escribió:
> Hi Laura,
> 
> Laura Arjona Reina  wrote:
>> Hi
>>
>> El 9/1/20 a las 20:49, Holger Wansing escribió:
>>>
>>> To make a new build happen, manual intervention is
>>> needed now ( because there is no new source package
>>> version available for installation-guide since the last build, no new build 
>>> is trigered).
>>> One need to go to
>>> /srv/www.debian.org/cron/log/ig-stable-built.txt
>>> and change that file (for example just change into an
>>> empty file).
>>> This is documented in the 1installation-guide script in
>>> lessoften (cron git-repo).
>>> That will trigger a new build at the next day.
>>
>> I've just done this (copied /srv/www.debian.org/cron/log/ig-stable-built.txt 
>> to
>> /srv/www.debian.org/cron/log/ig-stable-built.txt.old and then changed
>> ig-stable-built.txt to be an empty file).
> 
> Hrr, this did not work. Sorry
> 
> The variant with the empty file was my first idea, but that did not work.
> So I changed that, now the file has to be removed.
> 
> May I bother you again, to remove the file instead?
> (Also, there is no need to keep the old file. You can remove it too.)
> I have just updated the documentation in the 1installation-guide lessoften
> script accordingly.
> 

No problem.

I have removed the file, unfortunately I couldn't do it before today's
lessoften script run, so we need to wait until tomorrow to see if that
worked.

Cheers
-- 
Laura Arjona Reina
https://wiki.debian.org/LauraArjona

Bug#948666: libperl4-corelibs-perl: Y2K20 problem in t/timelocal.t

[Adrian Bunk]

Source: libperl4-corelibs-perl
Version: 0.003-2
Severity: serious
Tags: ftbfs
Control: close -1 0.004-2

https://tests.reproducible-builds.org/debian/rb-pkg/stretch/amd64/libperl4-corelibs-perl.html

...
#   Failed test 'timelocal year for 1970 1 2 0 0 0'
#   at t/timelocal.t line 36.
#  got: '170'
# expected: '70'

#   Failed test 'timegm year for 1970 1 2 0 0 0'
#   at t/timelocal.t line 49.
#  got: '170'
# expected: '70'
# Looks like you failed 2 tests of 135.
t/timelocal.t ... 
...


libperl4-corelibs-perl (0.004-2) unstable; urgency=medium
...
  * Add t/timelocal.t to fix Y2K20 problem in t/timelocal.t.
...
 -- gregor herrmann   Fri, 03 Jan 2020 05:09:21 +0100

Bug#946931: [Pkg-kde-extras] Bug#946931: Bug#946931: quassel-core: apparmor denials

[Felix Geyer]

On 11.01.20 02:58, Scott Kitterman wrote:

I gave this a try and I still get apparmor denials:

Jan 10 20:54:13 relay02 kernel: [ 1372.562938] audit: type=1400
audit(1578707653.245:28): apparmor="DENIED" operation="open" profile="/usr/bin/
quasselcore" name="/proc/sys/kernel/random/boot_id" pid=1588
comm="quasselcore" requested_mask="r" denied_mask="r" fsuid=116 ouid=0

Jan 10 20:54:13 relay02 kernel: [ 1372.562955] audit: type=1400
audit(1578707653.245:29): apparmor="DENIED" operation="open" profile="/usr/bin/
quasselcore" name="/var/lib/dbus/machine-id" pid=1588 comm="quasselcore"
requested_mask="r" denied_mask="r" fsuid=116 ouid=0

Jan 10 20:54:13 relay02 kernel: [ 1372.576629] audit: type=1400
audit(1578707653.257:30): apparmor="DENIED" operation="link" profile="/usr/bin/
quasselcore" name="/var/lib/quassel/quasselcore.conf" pid=1588
comm="quasselcore" requested_mask="l" denied_mask="l" fsuid=116 ouid=116
target="/var/lib/quassel/#523668"

Suggestions?


Are you sure you have reloaded the AppArmor profile (apparmor_parser -r
/etc/apparmor.d/usr.bin.quasselcore)?
Maybe restart quasselcore if that still does not work.

I can't see how these denials can happen with the updated profile.

On 11.01.20 14:49, Thomas Schneider wrote:
> I agree on the change '/var/lib/quassel/** rwkl' (although AA convention
> seems to be 'rwkl', but that’s just cosmetic), but I would suggest
> adding '#include ' instead of
> specifying the IDs manually.

quasselcore doesn't use dbus. Qt just happens to read the the dbus machine-id
file. The intent for the dbus-session-strict abstraction is "allow access to
the dbus session bus" so that's not appropriate for quasselcore.

> Said 'abstractions/dbus-session-strict' does not allow access to
> '@{PROC}/sys/kernel/random/boot_id', but I didn’t get any audit messages
> about that after including the abstraction.  I haven’t looked any
> further into it, but maybe it isn’t needed?

These files are only read when quasselcore updates its config which likely
doesn't happen very often.

Cheers,
Felix

Bug#948248: opencv: Doesn't build on ports without java

[Samuel Thibault]

Samuel Thibault, le ven. 10 janv. 2020 11:41:12 +0100, a ecrit:
> (as a side note, the build failure on hurd-i386 is being handled in
> https://github.com/opencv/opencv/pull/16302 )

Here is the patch applied upstream, could you apply it as well?

Thanks,
Samuel
commit e57ceea3d3769ef130465bcbe45e32d2cb2954ca
Author: Samuel Thibault 
Date:   Wed Jan 8 01:32:12 2020 +0100

Fix build on non-Linux glibc-based systems

dl functions are provided by all glibc-based systems (GNU/Linux, but
also GNU/Hurd, GNU/kFreeBSD)

diff --git a/modules/videoio/src/backend_plugin.cpp 
b/modules/videoio/src/backend_plugin.cpp
index 617c3cda29..f73a9ad7ac 100644
--- a/modules/videoio/src/backend_plugin.cpp
+++ b/modules/videoio/src/backend_plugin.cpp
@@ -21,7 +21,7 @@ using namespace std;
 
 #if defined(_WIN32)
 #include 
-#elif defined(__linux__) || defined(__APPLE__) || defined(__OpenBSD__) || 
defined(__FreeBSD__)
+#elif defined(__linux__) || defined(__APPLE__) || defined(__OpenBSD__) || 
defined(__FreeBSD__) || defined(__GLIBC__)
 #include 
 #endif
 
@@ -77,7 +77,7 @@ void* getSymbol_(LibHandle_t h, const char* symbolName)
 {
 #if defined(_WIN32)
 return (void*)GetProcAddress(h, symbolName);
-#elif defined(__linux__) || defined(__APPLE__) || defined(__OpenBSD__) || 
defined(__FreeBSD__)
+#elif defined(__linux__) || defined(__APPLE__) || defined(__OpenBSD__) || 
defined(__FreeBSD__) || defined(__GLIBC__)
 return dlsym(h, symbolName);
 #endif
 }
@@ -91,7 +91,7 @@ LibHandle_t libraryLoad_(const FileSystemPath_t& filename)
 # else
 return LoadLibraryW(filename.c_str());
 #endif
-#elif defined(__linux__) || defined(__APPLE__) || defined(__OpenBSD__) || 
defined(__FreeBSD__)
+#elif defined(__linux__) || defined(__APPLE__) || defined(__OpenBSD__) || 
defined(__FreeBSD__) || defined(__GLIBC__)
 return dlopen(filename.c_str(), RTLD_LAZY);
 #endif
 }
@@ -101,7 +101,7 @@ void libraryRelease_(LibHandle_t h)
 {
 #if defined(_WIN32)
 FreeLibrary(h);
-#elif defined(__linux__) || defined(__APPLE__) || defined(__OpenBSD__) || 
defined(__FreeBSD__)
+#elif defined(__linux__) || defined(__APPLE__) || defined(__OpenBSD__) || 
defined(__FreeBSD__) || defined(__GLIBC__)
 dlclose(h);
 #endif
 }

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

[Andreas Tille]

On Sat, Jan 11, 2020 at 10:12:48AM +0100, Dylan Aïssi wrote:
> Le ven. 10 janv. 2020 à 00:30, Pages, Herve  a écrit :
> > Based on the traceback the error happens during evaluation of the 1st
> > argument ('target') passed to checkEqualsNumeric(), that is, during
> > evaluation of 'runmed(y, 7)'. Since this involves base R code only
> > (runmed() is implemented in the stats package) I would say that it's not
> > immediately obvious that the problem is in my court.
> 
> Thanks Hervé for this.

+1
 
> I just updated how to run Debian autopkgtests [1-2] by replacing:
> 
> > LC_ALL=C R --no-save < > require("S4Vectors")
> > S4Vectors:::.test()
> > EOT
> 
> with
> 
> > LC_ALL=C.UTF-8 R --no-save -e 'BiocGenerics:::testPackage("S4Vectors")'
> 
> which seems to be the recommended way to run tests for bioconductor
> packages. And now, there is no segfault anymore for S4vectors but
> IRanges is still crashing. Should we upload these fixes into
> Debian/unstable?

Thanks for the fix - IMHO it makes sense to upload in any way if we
are doing something differently than it should be done.  Would you
mind checking other BioConductor packages as well?

Kind regards and thanks for your investigation

  Andreas.
 
> [1] 
> https://salsa.debian.org/r-pkg-team/r-bioc-s4vectors/commit/51b8ca2571dac1685e748679568edf4463cbfd59
> [2] 
> https://salsa.debian.org/r-pkg-team/r-bioc-iranges/commit/06a76a22fa236f919fc0038c5c01aec35ec2ecda
> [3] 
> https://bioconductor.org/developers/how-to/unitTesting-guidelines/#RUnitConventions

-- 
http://fam-tille.de

Bug#948665: FTBFS with Boost 1.71

[Giovanni Mascellani]

Package: ciftilib
Version: 1.5.3-2
Severity: wishlist
Tags: patch
User: team+bo...@tracker.debian.org
Usertags: boost1.71

Dear Maintainer,

your package fails to build with boost1.71. You can find a build log
attached. If you want to attempt the build yourself, an updated version
of boost-defaults which brings in boost1.71 dependencies can be found
adding this line to your sources.list file:

  deb https://people.debian.org/~gio/reprepro gio main

This bug has severity whishlist for the moment, but it will raised to RC
as soon as version 1.71 of Boost is promoted to default.

More specifically, your package fails building because it uses some
deprecated Boost.Filesystem API. The attached patch should fix the bug.

Thanks and all the best, Giovanni.
-- 
Giovanni Mascellani 
Postdoc researcher - Université Libre de Bruxelles
From aec27618a020df16effa5819f842e7467131cdc1 Mon Sep 17 00:00:00 2001
From: Giovanni Mascellani 
Date: Sat, 11 Jan 2020 15:46:34 +0100
Subject: [PATCH] Fix compilation with Boost 1.71.

---
 ...0002-Fix-compilation-with-Boost-1.71.patch | 31 +++
 debian/patches/series |  1 +
 2 files changed, 32 insertions(+)
 create mode 100644 debian/patches/0002-Fix-compilation-with-Boost-1.71.patch

diff --git a/debian/patches/0002-Fix-compilation-with-Boost-1.71.patch b/debian/patches/0002-Fix-compilation-with-Boost-1.71.patch
new file mode 100644
index 000..0fe8348
--- /dev/null
+++ b/debian/patches/0002-Fix-compilation-with-Boost-1.71.patch
@@ -0,0 +1,31 @@
+From: Giovanni Mascellani 
+Date: Sat, 11 Jan 2020 15:44:14 +0100
+Subject: Fix compilation with Boost 1.71.
+
+Method file_string() is now obsolete and just calls string().
+---
+ src/CiftiFile.cxx | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/src/CiftiFile.cxx b/src/CiftiFile.cxx
+index 9bbb16d..6b15311 100644
+--- a/src/CiftiFile.cxx
 b/src/CiftiFile.cxx
+@@ -100,7 +100,7 @@ namespace
+ return QFileInfo(mypath).absoluteFilePath();
+ #else
+ #ifdef CIFTILIB_BOOST_NO_FSV3
+-	return filesystem::complete(AString_to_std_string(mypath)).file_string();
++	return filesystem::complete(AString_to_std_string(mypath)).string();
+ #else
+ return filesystem::absolute(AString_to_std_string(mypath)).native();
+ #endif
+@@ -113,7 +113,7 @@ namespace
+ return QFileInfo(mypath).canonicalFilePath();
+ #else
+ #ifdef CIFTILIB_BOOST_NO_FSV3
+-return filesystem::complete(AString_to_std_string(mypath)).file_string();
++return filesystem::complete(AString_to_std_string(mypath)).string();
+ #else
+ #ifdef CIFTILIB_BOOST_NO_CANONICAL
+ filesystem::path temp = AString_to_std_string(mypath);
diff --git a/debian/patches/series b/debian/patches/series
index 1348bdb..8dde55d 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1 +1,2 @@
 0001-force-endian-of-datatype-example-to-make-tests-pass-.patch
+0002-Fix-compilation-with-Boost-1.71.patch
-- 
2.25.0.rc2



ciftilib.log.gz
Description: application/gzip


signature.asc
Description: OpenPGP digital signature

Bug#948647: [Pkg-rust-maintainers] Bug#948647: rust-backtrace depends on non-existent librust-compiler-builtins

[Ximin Luo]

Steve Langasek:
> [..]
> 
> There is no rust-compiler-builtins package in the Debian archive or in the
> NEW queue.

It's in NEW.

We're aware of all of these issues you're filing bug reports for, and in fact 
there are many more than the ones you're filing for. These reports are not 
actually helpful, they just increase the amount of work we have to do fixing 
the packages.

Therefore, I'm going to close all of these bugs now to save time. All of them 
are getting fixed as part of the normal migration process.

They are also redundant, britney is already preventing these packages from 
migration, adding a "serious" bug therefore achieves nothing except extra 
paperwork for packagers in closing bug reports.

X

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

Bug#944219: synaptic: one-line diff window is unusable

[Emil Nowak]

I confirm bug still exists in synaptic 0.84.2 in debian.

Bug#944294: buster-pu: package libvirt-daemon/5.0.0-4

[Adam D. Barratt]

On Sat, 2020-01-11 at 11:33 +0100, Guido Günther wrote:
> Hi,
> On Fri, Jan 10, 2020 at 10:10:30PM +0100, Michal Arbet wrote:
> > Hi Guido,
> > 
> > Please, do you please now when will be new updated version in
> > buster-updated ?
> 
> Needs an ack from the release team to be uploaded.

Sorry about that, it's been a busy few weeks.

+libvirt (5.0.0-4+deb10u1) buster; urgency=medium
+
+  [ Tobias Wolter ]
+  * [711f612] apparmor: Allow one to run pygrup

I think that wants to be "pygrub"?

Please go ahead.

Regards,

Adam

Bug#945493: mcomix: Library shows not all Thumbnails

[Björn]

Package: mcomix
Version: 1.2.1mcomix3+git20191129-1
Followup-For: Bug #945493

Hello Emfox Zhou,

the error is still there. But I can now further specify it. Apparently only a
maximum of 500 different icons are displayed in the library. This number is not
limited to a single collection, but applies to all images that have been
displayed in the library since the program was started. All images going beyond
this (from 502) are then no longer displayed, but only created on the hard disk
in the cache.
To re-create the error, you can take the tip from this page to create random
images: https://loteks.de/tausende-zufaellige-bilder-mit-fortlaufenden-namen/
and then pack each image into a ZIP archive.



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

Kernel: Linux 5.3.0-3-amd64 (SMP w/4 CPU cores)
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 
(charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages mcomix depends on:
ii  gir1.2-gtk-3.03.24.13-1
ii  python3   3.7.5-3
ii  python3-cairo 1.16.2-2
ii  python3-gi3.34.0-3
ii  python3-gi-cairo  3.34.0-3
ii  python3-pil   6.2.1-2+b1

Versions of packages mcomix recommends:
ii  python3-chardet  3.0.4-4

Versions of packages mcomix suggests:
ii  mupdf-tools  1.15.0+ds1-1+b1
ii  p7zip16.02+dfsg-7
ii  unrar1:5.6.6-2

-- no debconf information

Bug#946931: quassel-core: apparmor denials

[Thomas Schneider]

Hello,

I stumbled upon the same issue and fixed it locally before searching the
BTS.

I agree on the change '/var/lib/quassel/** rwkl' (although AA convention
seems to be 'rwkl', but that’s just cosmetic), but I would suggest
adding '#include ' instead of
specifying the IDs manually.

Said 'abstractions/dbus-session-strict' does not allow access to
'@{PROC}/sys/kernel/random/boot_id', but I didn’t get any audit messages
about that after including the abstraction.  I haven’t looked any
further into it, but maybe it isn’t needed?

Thanks,
qsx

Bug#945602: closed by Gürkan Myczko (Bug#945602: fixed in qwinff 0.2.1+git20191128-1)

[nodiscc]

Dear Gürkan,
can you confirm the proposed patch is working? And confirm an upload
to proposed-updates would be ok?

I really hope to see this fix land in proposed-updates/the next point release.

Thank you

Le jeu. 28 nov. 2019 à 14:57, Debian Bug Tracking System
 a écrit :
>
> This is an automatic notification regarding your Bug report
> which was filed against the qwinff package:
>
> #945602: wrong path for constants.xml/presets.xml prevent the program from 
> starting
>
> It has been closed by Gürkan Myczko .
>
> Their explanation is attached below along with your original report.
> If this explanation is unsatisfactory and you have not received a
> better one in a separate message then please contact Gürkan Myczko 
>  by
> replying to this email.
>
>
> --
> 945602: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=945602
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>
>
>
> -- Forwarded message --
> From: "Gürkan Myczko" 
> To: 945602-cl...@bugs.debian.org
> Cc:
> Bcc:
> Date: Thu, 28 Nov 2019 14:53:00 +
> Subject: Bug#945602: fixed in qwinff 0.2.1+git20191128-1
> Source: qwinff
> Source-Version: 0.2.1+git20191128-1
>
> We believe that the bug you reported is fixed in the latest version of
> qwinff, which is due to be installed in the Debian FTP archive.
>
> A summary of the changes between this version and the previous one is
> attached.
>
> Thank you for reporting the bug, which will now be closed.  If you
> have further comments please address them to 945...@bugs.debian.org,
> and the maintainer will reopen the bug report if appropriate.
>
> Debian distribution maintenance software
> pp.
> Gürkan Myczko  (supplier of updated qwinff package)
>
> (This message was generated automatically at their request; if you
> believe that there is a problem with it please contact the archive
> administrators by mailing ftpmas...@ftp-master.debian.org)
>
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> Format: 1.8
> Date: Thu, 28 Nov 2019 10:31:49 +0100
> Source: qwinff
> Architecture: source
> Version: 0.2.1+git20191128-1
> Distribution: unstable
> Urgency: medium
> Maintainer: Gürkan Myczko 
> Changed-By: Gürkan Myczko 
> Closes: 945602
> Changes:
>  qwinff (0.2.1+git20191128-1) unstable; urgency=medium
>  .
>* New upstream version. (Closes: #945602)
>* Bump standards version to 4.4.1.
> Checksums-Sha1:
>  c435f8e800a824d82f2a63f8e7d48accae887ec3 1822 qwinff_0.2.1+git20191128-1.dsc
>  a695f1968edd8cf234e45ff9aad42f74e46e16b1 640284 
> qwinff_0.2.1+git20191128.orig.tar.gz
>  5d2639a410564a41aeff5e905b7b8d5d2f9cdb83 66484 
> qwinff_0.2.1+git20191128-1.debian.tar.xz
>  f916869c629b06ba198e1a3b088e0136d9fc47cf 5512 
> qwinff_0.2.1+git20191128-1_source.buildinfo
> Checksums-Sha256:
>  9461b39731c0a8dd591d9d2ed5ce538e336baee05a913e7cd35bd843de143499 1822 
> qwinff_0.2.1+git20191128-1.dsc
>  a4eb6143ed1e407df8d23766ba254aa6bee0471c53d3a4ba42cbef2b7ab6a3b4 640284 
> qwinff_0.2.1+git20191128.orig.tar.gz
>  0987db200a7b5d12cf81e4f453bcafae2925dc9ff434412953900440ee54bf04 66484 
> qwinff_0.2.1+git20191128-1.debian.tar.xz
>  50134b28e5aab8adf6ea553c9288314b5234112232eedceec6711043f2f33b21 5512 
> qwinff_0.2.1+git20191128-1_source.buildinfo
> Files:
>  08d0bea0f7ca208f85c03652c2e13190 1822 video optional 
> qwinff_0.2.1+git20191128-1.dsc
>  0307673249ac65c683206226f88f13b2 640284 video optional 
> qwinff_0.2.1+git20191128.orig.tar.gz
>  49af85a9edea7adfbec7f9ac654439ae 66484 video optional 
> qwinff_0.2.1+git20191128-1.debian.tar.xz
>  6fbc2f216a9c4dc746ce5c48c2299ed2 5512 video optional 
> qwinff_0.2.1+git20191128-1_source.buildinfo
>
> -BEGIN PGP SIGNATURE-
>
> iQIzBAEBCgAdFiEEkjZVexcMh/iCHArDweDZLphvfH4FAl3f0H0ACgkQweDZLphv
> fH7ZYg//aZae+iZMxu8xrsn4QgYXdOQD+ZkS2FjFYCxkJyhM0Dg94+hhqKl9oqzI
> vhcuBioNWTPnzgmMYhXYyTgoExsmqxbGyCIuUwWBC+kkPpXew2rEW0k3c7S0GILo
> CLhTCqZYuy0KW8VPB9ibDNYk4MGZHBSaDDeI9dMfhAwYOn0509/KqPcx8/Cp9jyh
> UPHcgYeCN3YarGA3USRRxzlMHTs9x/VbjbBsoUwvJ+yrfnYHJnCTWZKWJ1+ZgFPW
> f6m27oRCllAKP4QO7p4hOO5SwpCzaxLk+riGqup+6X6n2A3N1MiJGysam4JV3/VV
> Qj6kAhGg7OjkNbRIu+fJulAVHfgpfQLgWhlGAvAfMZWYJhHhHUQUhaBh0IM70Mbj
> 8R1q1MOc2ydRLF8HMOCIprQd9kNAQ9JGZGFcn2Yae8qsHIqNk6qPy9v2rgZxD83M
> 2zIJXHJ1hA0UszCL1XZO6DKZQEZV8kEAi643MjyJJ3Fpv12L2mz1pK6BMhfdiy5V
> trXjV6ixsHbfNXhFVkxAXswIn3w9XvM+mYEAHBrEE3hXFBX1TSPhtkQyLh0gX3vn
> OrDq5nbqC00/DhKympwxf1Z2hhWO0xyFGXgAZjDBPFra/RFEv/MRQOJrE3+5UftT
> Bk52I++lRxi0YkAtNLdCq6S7Wf6y1MpZPa8UuNVwH+vK0a/W8v4=
> =7dsM
> -END PGP SIGNATURE-
>
>
> -- Forwarded message --
> From: nodiscc 
> To: sub...@bugs.debian.org
> Cc:
> Bcc:
> Date: Wed, 27 Nov 2019 20:06:40 +
> Subject: wrong path for constants.xml/presets.xml prevent the program from 
> starting
> Package: qwinff
> Version: 0.2.1-1
> Severity: grave
>
> Steps to reproduce the problem:
>  - run qwinff from the desktop launcher of from a terminal emulator
>
> What happens:
>  - An error dialog is shown with the message "Cannot load
> 

Bug#932989: gcc-avr: which upstream to track

[Osamu Aoki]

Hi,

This is a review of CC/C++ for AVR.

Debian Buster:
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   VersionArchitecture Description
+++-==-==--===
ii  avr-libc   1:2.0.0+Atmel3.6.1-2   all  Standard C library for 
Atmel AVR de
ii  avrdude6.3-20171130+svn1429-2 amd64software for programming 
Atmel AVR
ii  gcc4:8.3.0-1  amd64GNU C compiler
ii  gcc-avr1:5.4.0+Atmel3.6.1-2   amd64GNU C compiler (cross 
compiler for
ii  gdb-avr7.7-4+b12  amd64GNU Debugger for avr

Choice of CC/C++ for AVR can be several choices.  As I googled situation, it 
looks
like:

(1) Hard ware vendor (microchip) supported CC:
GCC 5.4.0 based gcc-avr (current state in Debian)

Yah... it's old compared to the normal GCC 8.3 on buster
The vendor seems to have no intent to move to newer GCC.

(2) Latest GCC used as the cross-compiler:
Grntoo promote this: https://wiki.gentoo.org/wiki/Arduino

But it doesn't look good in near future 
https://gcc.gnu.org/ml/gcc-patches/2019-09/msg01256.html

https://www.reddit.com/r/linux/comments/e3flt6/bountysource_campaign_to_modernize_the_avr/
https://www.avrfreaks.net/forum/avr-gcc-and-avr-g-are-deprecated-now
GCC 10: AVR is deprecated
GCC 11: AVR will be dropped

So moving to the latest GCC is not easy to do.

(3) Forward port vendor patches by someone
GCC 9.2 ??? by Archlinux
https://www.archlinux.org/packages/community/x86_64/avr-gcc/

GCC 9.1 by stevenj
https://github.com/stevenj/avr-gcc-build-script/releases/tag/20190728
https://www.avrfreaks.net/forum/avr-gcc-91-avr-libc-xmega3-device-support

Following such efforts seems fragile at best ... we don't even know
how well they are tested.

(4) Stable updated GCC with forward ported vendor patches supported by
the active user community --- Arduino
Arduino 1.8.10 (Larest release)
avr-gcc-7.3.0

Considering gcc-avr is mostly aimed for use with Arduino platform and
Arduino forks seem to maintain and test GCC well, switching the UPSTREAM
of this Debian package to the Arduino ine seems good idea.

Arduino seems to just download binary from:
 
http://downloads.arduino.cc/tools/avr-gcc-7.3.0-atmel3.6.1-arduino5-x86_64-apple-darwin14.tar.bz2

So we need to find where is the source of above package.

Osamu

Bug#948664: ganglia-web: CVE-2019-20378 CVE-2019-20379

[Salvatore Bonaccorso]

Source: ganglia-web
Version: 3.6.1-3
Severity: important
Tags: security upstream
Forwarded: https://github.com/ganglia/ganglia-web/issues/351

Hi,

The following vulnerabilities were published for ganglia-web.

CVE-2019-20378[0]:
| ganglia-web (aka Ganglia Web Frontend) through 3.7.5 allows XSS via
| the header.php ce parameter.


CVE-2019-20379[1]:
| ganglia-web (aka Ganglia Web Frontend) through 3.7.5 allows XSS via
| the header.php cs parameter.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2019-20378
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-20378
[1] https://security-tracker.debian.org/tracker/CVE-2019-20379
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-20379
[2] https://github.com/ganglia/ganglia-web/issues/351

Regards,
Salvatore

Bug#948663: kdepim-runtime: account wizard cannot show kde widgets like KLineEdit

[Johannes Ranke]

Package: kdepim-runtime
Version: 4:18.08.3-4
Severity: normal

Dear Maintainer,

on a freshly installed buster system I would like to configure my PIM
accounts for use with kontact.

Upon the first start of kontact, the account wizard starts. When I
select kolab as the account type I would like to set up, I get a window
for entering personal settings which is incomplete.

On the command line where I started kontact I get


org.kde.pim.kidentitymanagement: IdentityManager: There was no default 
identity. Marking first one as default.
No text-to-speech plug-ins were found.
kf5.kxmlgui: cannot find .rc file "kontactsummary_part.rc" for 
component "kontact"
No such XML file "/home/jranke/.local/share/kontact/default-.rc"
org.kde.pim.akonadiplugin_indexer: unknown term  "birthday"
org.kde.pim.akonadiplugin_indexer: unknown term  "birthday"
"https://dot.kde.org/rss.xml;
"https://www.linux.com/feeds/rss;
"https://planetkde.org/rss20.xml;
"https://store.kde.org/content.rdf;
"https://planetkde.org/pt-br/rss20.xml;
"https://planet.kde-espana.org/atom.xml;
"http://planet.debian.org/rss20.xml;
"http://www.debian.org/News/news;
org.kde.pim.akonadiplugin_indexer: unknown term  "birthday"
org.kde.pim.akonadiplugin_indexer: unknown term  "birthday"
org.kde.pim.akonadiplugin_indexer: unknown term  "birthday"
org.kde.pim.akonadiplugin_indexer: unknown term  "birthday"
"QFormBuilder was unable to create a widget of the class 'KLineEdit'."
"Empty widget item in QFormLayout 'formLayout'."
"QFormBuilder was unable to create a widget of the class 'KLineEdit'."
"Empty widget item in QFormLayout 'formLayout'."
"QFormBuilder was unable to create a custom widget of the class 
'KPasswordLineEdit'; defaulting to base class 'QWidget'."
Kross: "Error error=TypeError: Result of expression 
'page.widget().nameEdit' [undefined] is not an object. lineno=27 
trace=\n() at /usr/share/akonadi/accountwizard/kolab/kolabwizard.es:27"


I was trying to find a missing dependency, but libkf5completion5 where
KLineEdit is defined is installed as can be seen below. Also,
libkf5widgetsaddons is installed, which should have KPasswordLineEdit.

Thanks for maintaining KDE PIM software!

Johannes


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

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

Versions of packages kdepim-runtime depends on:
ii  akonadi-server   4:18.08.3-7~deb10u1
ii  kio  5.54.1-1
ii  kio-ldap 18.08.3-1
ii  libc62.28-10
ii  libgcc1  1:8.3.0-6
ii  libkf5akonadiagentbase5  4:18.08.3-7~deb10u1
ii  libkf5akonadicalendar5abi1   4:18.08.3-1
ii  libkf5akonadicontact54:18.08.3-1
ii  libkf5akonadicore5abi2   4:18.08.3-7~deb10u1
ii  libkf5akonadimime5   4:18.08.3-1
ii  libkf5akonadinotes5  4:18.08.3-1
ii  libkf5akonadiwidgets5abi14:18.08.3-7~deb10u1
ii  libkf5alarmcalendar5abi1 4:18.08.3-2
ii  libkf5calendarcore5abi2  4:18.08.3-1
ii  libkf5codecs55.54.0-1
ii  libkf5completion55.54.0-1
ii  libkf5configcore55.54.0-1+deb10u1
ii  libkf5configgui5 5.54.0-1+deb10u1
ii  libkf5configwidgets5 5.54.0-1
ii  libkf5contacts5  4:18.08.3-1
ii  libkf5coreaddons55.54.0-1
ii  libkf5dbusaddons55.54.0-1
ii  libkf5i18n5  5.54.0-1
ii  libkf5identitymanagement518.08.3-2
ii  libkf5imap5  18.08.3-1
ii  libkf5itemmodels55.54.0-1
ii  libkf5jobwidgets55.54.0-1
ii  libkf5kdelibs4support5   5.54.0-1
ii  libkf5kiocore5   5.54.1-1
ii  libkf5kiowidgets55.54.1-1
ii  libkf5mailtransport5 18.08.3-2
ii  libkf5mailtransportakonadi5  18.08.3-2
ii  libkf5mbox5  18.08.3-1
ii  libkf5mime5abi1  18.08.3-1
ii  libkf5notifications5 5.54.0-1
ii  libkf5notifyconfig5  5.54.0-1
ii  libkf5service-bin5.54.0-1
ii  libkf5service5   5.54.0-1
ii  libkf5textwidgets5   5.54.0-1
ii  libkf5wallet-bin 5.54.0-1
ii  libkf5wallet55.54.0-1
ii  libkf5widgetsaddons5 5.54.0-1
ii  libkf5windowsystem5  5.54.0-1
ii  libkf5xmlgui55.54.0-1
ii  libkolabxml1v5   1.1.6-4
ii  libkpimgapicalendar5 18.08.3-2
ii  libkpimgapicontacts5 18.08.3-2
ii  libkpimgapicore5abi1 18.08.3-2
ii  

Bug#948626: kicad: Closing pcbnew hangs main kicad process

[Bernhard Übelacker]

Hello Paul,
I am not involved in packaging kicad or wxwidgets,
just trying to collect some more information.

Could you recheck - could it be that this pid 309563
was still running from a previous kicad session and
your hanging kicad was another, newer process?

Because, I guess, the __run_exit_handlers should just
run at process exit.

The last line in your backtrace point to this line,
with a loop which would fit into the picture:
  
https://sources.debian.org/src/wxwidgets3.0/3.0.4+dfsg-15/src/common/object.cpp/#L177

When you are in gdb and try to leave the current function
by "finish", do you get again to the debugger prompt,
or is it causing already the 100% CPU usage again?

Kind regards,
Bernhard

Bug#946242: fatal: privsep_preauth: preauth child terminated by signal 31

[Colin Watson]

Ian Jackson (CCed) just ran into this and we debugged it together on
IRC.  This turns out to be a variant of https://bugs.debian.org/941663
that only affects certain architectures, because glibc implements
shmget/shmat/shmdt using the ipc syscall on certain architectures.  For
example, shmget is:

  int
  shmget (key_t key, size_t size, int shmflg)
  {
  #ifdef __ASSUME_DIRECT_SYSVIPC_SYSCALLS
return INLINE_SYSCALL_CALL (shmget, key, size, shmflg, NULL);
  #else
return INLINE_SYSCALL_CALL (ipc, IPCOP_shmget, key, size, shmflg, NULL);
  #endif
  }

And:

  sysdeps/unix/sysv/linux/i386/kernel-features.h:#undef 
__ASSUME_DIRECT_SYSVIPC_SYSCALLS
  sysdeps/unix/sysv/linux/kernel-features.h:#define 
__ASSUME_DIRECT_SYSVIPC_SYSCALLS  1
  sysdeps/unix/sysv/linux/m68k/kernel-features.h:#undef 
__ASSUME_DIRECT_SYSVIPC_SYSCALLS
  sysdeps/unix/sysv/linux/mips/kernel-features.h:# undef 
__ASSUME_DIRECT_SYSVIPC_SYSCALLS
  sysdeps/unix/sysv/linux/powerpc/kernel-features.h:#undef 
__ASSUME_DIRECT_SYSVIPC_SYSCALLS
  sysdeps/unix/sysv/linux/s390/kernel-features.h:#undef 
__ASSUME_DIRECT_SYSVIPC_SYSCALLS
  sysdeps/unix/sysv/linux/sh/kernel-features.h:#undef 
__ASSUME_DIRECT_SYSVIPC_SYSCALLS
  sysdeps/unix/sysv/linux/sparc/kernel-features.h:#undef 
__ASSUME_DIRECT_SYSVIPC_SYSCALLS

I think a fix for this that applies to buster would be:

diff --git a/sandbox-seccomp-filter.c b/sandbox-seccomp-filter.c
index e8f31555e..121760418 100644
--- a/sandbox-seccomp-filter.c
+++ b/sandbox-seccomp-filter.c
@@ -134,6 +134,9 @@ static const struct sock_filter preauth_insns[] = {
 #ifdef __NR_fstat64
SC_DENY(__NR_fstat64, EACCES),
 #endif
+#ifdef __NR_ipc
+   SC_DENY(__NR_ipc, EACCES),
+#endif
 #ifdef __NR_open
SC_DENY(__NR_open, EACCES),
 #endif

I have some other things to do this weekend, but I'll chase this up with
upstream and arrange for this to get into appropriate Debian packages.

-- 
Colin Watson   [cjwat...@debian.org]

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

[/dev/fra]

Package: firejail-profiles
Version: 0.9.62-2
Followup-For: Bug #948558

Similar issue here, I have two webexts installed via apt:
- webext-https-everywhere
- webext-ublock-origin

after the upgrade to firejail-profiles 0.9.62-2, firefox-esr now loads only
the ublock extension but not https-everywhere, for whatever reason.

Chromium web browser running under firejail loads both webexts, so the issue
might be specific to the firefox related firejail profiles.


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

Kernel: Linux 5.3.0-3-amd64 (SMP w/8 CPU cores)
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.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 firejail-profiles depends on:
ii  firejail  0.9.62-2

firejail-profiles recommends no packages.

firejail-profiles suggests no packages.

-- no debconf information

Bug#948593: [pkg-cryptsetup-devel] Bug#948593: Unable to open LUKS device (error allocating crypto tfm) for aes / cbc-essiv:sha256 sha1 LUKS header

[Guilhem Moulin]

Hi OdyX,

On Sat, 11 Jan 2020 at 11:56:35 +, Didier 'OdyX' Raboud wrote:
> From diffing the initramfs'es, I see that kernel/arch/x86/crypto/aes-x86_64.ko
> was present in 5.3.0-3 kernels, but not present anymore in 5.4.0-1 or 5.4.0-2
> kernels.

kernel/arch/x86/crypto/aes-x86_64.ko isn't in 5.4.0-2's module tree.  Do
you build the initramfs with MODULES="most", MODULES="dep", or something
else?  Looking at the output of

cut -d" " -f1 /proc/modules | xargs -d"\\n" /sbin/modinfo -F filename | 
grep /crypto/

before and after (formatting and) opening a cbc-essiv:sha256 device
with

$ cryptsetup luksFormat --type luks1 --cipher aes-cbc-essiv:sha256 --hash 
sha1 /tmp/disk.img <<

signature.asc
Description: PGP signature

Bug#948661: www.debian.org: Outdated translations not deleted

[Alban Vidal]

Package: www.debian.org

Dear Webmaster Team,

Some translations provides from deleted original english files.
We can remove them.
This bug is opened to trace those deletions.

english/devel/debian-nonprofit (directory) - Deleted on 2019/08/01,
linked files :
- german/devel/debian-nonprofit/
- greek/devel/debian-nonprofit/
- japanese/devel/debian-nonprofit/
- portuguese/devel/debian-nonprofit/
- polish/devel/debian-nonprofit/

english/doc/docpolicy.wml - Delete on 2019/04/25, linked files :
- croatian/doc/docpolicy.wml
- catalan/doc/docpolicy.wml
- finnish/doc/docpolicy.wml
- german/doc/docpolicy.wml
- polish/doc/docpolicy.wml

english/devel/cvs_packages.wml - Delete on 2019/03/17, linked files :
- japanese/devel/cvs_packages.wml
- german/devel/cvs_packages.wml
- polish/devel/cvs_packages.wml
- portuguese/devel/cvs_packages.wml

Bests regards,
Alban

Bug#948584: libc6: Mounting nfsv4-export from my NAS there is a segfault in libc

[Bernhard Übelacker]

Dear Maintainer,
I could reproduce the crash now in an minimal unstable VM with the
given config and the command line from the coredumpctl output.

It seems that the function conf_parse_line is not prepared
for missing quotation marks for the argument in the section head [1].

Therefore, if quotes are ommitted, the variable arg gets not filled,
and therefore the cb->arg contains then a null pointer [2], that leads
given to strcasecmp to the crash.

@Miriam: I guess the crash should go away if change the config like following?
- [ Server mirunas.mirulan.net ]
- [ MountPoint /media/MiruNAS/Medienwerkstatt ]
+ [ Server "mirunas.mirulan.net" ]
+ [ MountPoint "/media/MiruNAS/Medienwerkstatt" ]

Kind regards,
Bernhard

[1] 
https://sources.debian.org/src/nfs-utils/1:1.3.4-2.5/support/nfs/conffile.c/#L274
[2] 
https://sources.debian.org/src/nfs-utils/1:1.3.4-2.5/support/nfs/conffile.c/#L582

Bug#948660: python3-ns3 depends/suggests on Python2 modules

[Matthias Klose]

Package: python3-ns3
Version: 3.30+dfsg-3
Severity: serious
Tags: sid bullseye

python3-ns3 depends/suggests on Python2 modules, python-pygraphviz and 
python-kiwi.

Bug#948271: exim4-daemon-heavy: smtp_ratelimit_rcpt breaks connection instead of just delaying RCPT verbs

[Andreas Metzler]

On 2020-01-06 "Ralf G. R. Bergs"  wrote:
[...]
> I have the following config snippet active to hamper spammers
> brute-force trying local-parts on my server:

> --- 8x -
> smtp_ratelimit_hosts = *
> smtp_ratelimit_rcpt = 4,0.25s,1.2,4m
> --- 8x -

> I tried to send a message from Thunderbird to 10 recipients, but
> instead of accepting the message an SMTP-level error occurred. Same
> happened with macOS Mail client.

> Apparently the implementation of Exim is faulty, because instead of
> just delaying RCPT verbs it seems to close the connection.

[...]
> After the 5th occurence of an RCPT verb (for address
> "ral...@example.org" in this case) the server seems to close the
> connection:

> --- 8x -
>  33 0.338365   2a00:6020:1eea:3420:0123:4567:89ab:cdef
> 2a01:4f8:fff:fff::2   SMTP 131C: RCPT TO:
>  34 0.397162   2a01:4f8:fff:fff::2
> 2a00:6020:1eea:3420:0123:4567:89ab:cdef TCP  74 587 → 63730
> [ACK] Seq=4151 Ack=1287 Win=29952 Len=0
>  35 0.602293   2a01:4f8:fff:fff::2
> 2a00:6020:1eea:3420:0123:4567:89ab:cdef SMTP 117S: 250 Accepted
>  36 0.603927   2a00:6020:1eea:3420:0123:4567:89ab:cdef
> 2a01:4f8:fff:fff::2   SMTP 131C: RCPT TO:
>  37 0.617940   2a01:4f8:fff:fff::2
> 2a00:6020:1eea:3420:0123:4567:89ab:cdef SMTP 138S: 421
> example.net lost input connection
> --- 8x -

> When I removed the above config snippet I could properly send the
> message with more than 5 recipients.

> Unfortunately at the moment I have no means of trying a more recent
> version of Exim -- I can only update to the latest oldstable version.

> Many thanks in advance for looking into this.
[...]

Hello,

I cannot reproduce this with 4.93, it just works as expected.

cu Andreas

Bug#948659: ITP: pinball-table-hurd -- HURD Pinball table for emilia pinball

[Philippe Coval]

Package: wnpp
Severity: wishlist
Owner: Philippe Coval 

* Package name: pinball-table-hurd
  Version : 0.3.1
  Upstream Author : Paolo Caroni, Philippe Coval 
* URL : https://github.com/rzr/pinball-table-hurd
* License : GPL+ and Other free licences
  Programming Lang: C++
  Description : HURD Pinball table for emilia pinball

Extra table for emilia pinball already shipped into debian:

https://packages.qa.debian.org/p/pinball.html

To avoid license mess, extra tables are maintained separately:

https://github.com/rzr/pinball/issues/4


As upstream developer and debian maintainer,
and for developer convenience
I already started to package it in upstream tree.
Effort can also be tracked at:

https://github.com/rzr/pinball-table-hurd/issues/5

Co-maintainers (ie debian-games) are also welcome,
feel free to contact us here or un above link.

Note, package is not yet released, it's pending on this change:

https://github.com/rzr/pinball-table-hurd/pull/6

Then I will upload to mentors.debian.net,
but I am looking for sponsorship.

PS: pinball is orphaned too,
I plan to adopt it too and release new upstream version too.


Regards

Bug#923464: carbon-cache unusable in Buster

[Mark Hymers]

On Thu, 07, Nov, 2019 at 10:57:23AM +0100, Morten Brekkevold spoke thus..
> The carbon-cache package in Debian Buster is definitely BROKEN - it just
> keeps crashing.

Hi,

We've been running with the attached patch since December which fixes
the problem.

Thorsten (as you're the last uploader) - I'm happy to prepare a stable
update to fix this, but the version is the same in stable/testing so
can't do so currently.  There are two point release (1.1.5 and 1.1.6)
for this package but they seem to be tied into other graphite-* package
updates too.  Would you accept an NMU to unstable with just this patch
and then an accompanying stable update?  This problem basically makes
graphite-carbon unusable in buster.

Thanks.

Mark

-- 
Mark Hymers 
--- graphite-carbon/lib/carbon/cache.py	2020-01-11 11:58:15.877162033 +
+++ cache.py	2020-01-11 11:55:19.516768965 +
@@ -184,7 +185,8 @@
 if not self:
   return (None, [])
 if self.strategy:
-  metric = self.strategy.choose_item()
+  with self.lock:
+metric = self.strategy.choose_item()
 else:
   # Avoid .keys() as it dumps the whole list
   metric = next(iter(self))
@@ -206,18 +208,18 @@
 
   def store(self, metric, datapoint):
 timestamp, value = datapoint
-if timestamp not in self[metric]:
-  # Not a duplicate, hence process if cache is not full
-  if self.is_full:
-log.msg("MetricCache is full: self.size=%d" % self.size)
-events.cacheFull()
-  else:
-with self.lock:
+with self.lock:
+  if timestamp not in self[metric]:
+# Not a duplicate, hence process if cache is not full
+if self.is_full:
+  log.msg("MetricCache is full: self.size=%d" % self.size)
+  events.cacheFull()
+else:
   self.size += 1
   self[metric][timestamp] = value
-else:
-  # Updating a duplicate does not increase the cache size
-  self[metric][timestamp] = value
+  else:
+# Updating a duplicate does not increase the cache size
+self[metric][timestamp] = value
 
 
 _Cache = None


signature.asc
Description: PGP signature

Bug#923464: carbon-cache unusable in Buster

[Mark Hymers]

On Sat, 11, Jan, 2020 at 12:05:17PM +, Mark Hymers spoke thus..
> On Thu, 07, Nov, 2019 at 10:57:23AM +0100, Morten Brekkevold spoke thus..
> > The carbon-cache package in Debian Buster is definitely BROKEN - it just
> > keeps crashing.
> 
> Hi,
> 
> We've been running with the attached patch since December which fixes
> the problem.
> 
> Thorsten (as you're the last uploader) - I'm happy to prepare a stable

Urgh - sorry, Thomas, not Thorsten.  My brain said one thing and my
fingers typed another. Sorry.

Mark

-- 
Mark Hymers 


signature.asc
Description: PGP signature

Bug#948257: Is there a fix coming down the pike?

[sixerjman]

Can we expect a fix soon in whatever package causes the console spam? It's
a rude awakening to get hit by these messages first thing in the morning
when doing maintenance.

Bug#910054: kmail: Fatal startup error: Could not create collection inbox, resourceId: 3

[Johannes Ranke]

Package: kmail
Version: 4:18.08.3-1
Followup-For: Bug #910054

For what it's worth, I can confirm that this is still happening on a fresh 
buster install.

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

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

Versions of packages kmail depends on:
ii  akonadi-server   4:18.08.3-7~deb10u1
ii  kdepim-runtime   4:18.08.3-4
ii  kio  5.54.1-1
ii  libc62.28-10
ii  libgcc1  1:8.3.0-6
ii  libgpgmepp6  1.12.0-6
ii  libkf5akonadiagentbase5  4:18.08.3-7~deb10u1
ii  libkf5akonadicontact54:18.08.3-1
ii  libkf5akonadicore5abi2   4:18.08.3-7~deb10u1
ii  libkf5akonadimime5   4:18.08.3-1
ii  libkf5akonadisearch-bin  4:18.08.3-1
ii  libkf5akonadisearch-plugins  4:18.08.3-1
ii  libkf5akonadisearchdebug54:18.08.3-1
ii  libkf5akonadisearchpim5  4:18.08.3-1
ii  libkf5akonadiwidgets5abi14:18.08.3-7~deb10u1
ii  libkf5bookmarks5 5.54.0-1
ii  libkf5calendarcore5abi2  4:18.08.3-1
ii  libkf5calendarutils5 4:18.08.3-2
ii  libkf5codecs55.54.0-1
ii  libkf5completion55.54.0-1
ii  libkf5configcore55.54.0-1+deb10u1
ii  libkf5configgui5 5.54.0-1+deb10u1
ii  libkf5configwidgets5 5.54.0-1
ii  libkf5contacts5  4:18.08.3-1
ii  libkf5coreaddons55.54.0-1
ii  libkf5crash5 5.54.0-1
ii  libkf5dbusaddons55.54.0-1
ii  libkf5followupreminder5  4:18.08.3-2
ii  libkf5grantleetheme-plugins  18.08.3-1
ii  libkf5gravatar5abi2  4:18.08.3-1
ii  libkf5guiaddons5 5.54.0-1
ii  libkf5i18n5  5.54.0-1
ii  libkf5iconthemes55.54.0-1
ii  libkf5identitymanagement518.08.3-2
ii  libkf5itemmodels55.54.0-1
ii  libkf5itemviews5 5.54.0-1
ii  libkf5jobwidgets55.54.0-1
ii  libkf5kcmutils5  5.54.0-1
ii  libkf5kiocore5   5.54.1-1
ii  libkf5kiofilewidgets55.54.1-1
ii  libkf5kiowidgets55.54.1-1
ii  libkf5kontactinterface5  18.08.3-1
ii  libkf5ksieveui5  4:18.08.3-2
ii  libkf5libkdepim-plugins  4:18.08.3-2
ii  libkf5libkdepim5 4:18.08.3-2
ii  libkf5libkdepimakonadi5  4:18.08.3-2
ii  libkf5libkleo5   4:18.08.3-2
ii  libkf5mailcommon5abi24:18.08.3-2
ii  libkf5mailtransport5 18.08.3-2
ii  libkf5mailtransportakonadi5  18.08.3-2
ii  libkf5messagecomposer5abi1   4:18.08.3-2
ii  libkf5messagecore5abi1   4:18.08.3-2
ii  libkf5messagelist5abi1   4:18.08.3-2
ii  libkf5messageviewer5abi1 4:18.08.3-2
ii  libkf5mime5abi1  18.08.3-1
ii  libkf5mimetreeparser5abi14:18.08.3-2
ii  libkf5notifications5 5.54.0-1
ii  libkf5notifyconfig5  5.54.0-1
ii  libkf5parts5 5.54.0-1
ii  libkf5pimcommon5abi2 4:18.08.3-2
ii  libkf5pimcommonakonadi5abi1  4:18.08.3-2
ii  libkf5pimtextedit5abi2   18.08.3-1
ii  libkf5sendlater5 4:18.08.3-2
ii  libkf5service-bin5.54.0-1
ii  libkf5service5   5.54.0-1
ii  libkf5sonnetui5  5.54.0-1
ii  libkf5templateparser54:18.08.3-2
ii  libkf5textwidgets5   5.54.0-1
ii  libkf5tnef5  4:18.08.3-1
ii  libkf5wallet-bin 5.54.0-1
ii  libkf5wallet55.54.0-1
ii  libkf5webengineviewer5abi1   4:18.08.3-2
ii  libkf5widgetsaddons5 5.54.0-1
ii  libkf5windowsystem5  5.54.0-1
ii  libkf5xmlgui55.54.0-1
ii  libqgpgme7   1.12.0-6
ii  libqt5core5a 5.11.3+dfsg1-1+deb10u1
ii  libqt5dbus5  5.11.3+dfsg1-1+deb10u1
ii  libqt5gui5   5.11.3+dfsg1-1+deb10u1
ii  libqt5network5   5.11.3+dfsg1-1+deb10u1
ii  libqt5widgets5   5.11.3+dfsg1-1+deb10u1
ii  libqt5xml5   5.11.3+dfsg1-1+deb10u1
ii  libstdc++6   8.3.0-6

Versions of packages kmail recommends:
ii  accountwizard   4:18.08.3-1
ii  gnupg   2.2.12-1+deb10u1
ii  kdepim-addons   18.08.3-2
ii  kdepim-themeeditors 4:18.08.3-1
ii  mbox-importer   4:18.08.3-1
ii  pim-data-exporter   4:18.08.3-1
ii  pim-sieve-editor4:18.08.3-1
ii  pinentry-qt [pinentry-x11]  1.1.0-2

Versions of packages kmail suggests:
pn  clamav 
ii  kaddressbook   4:18.08.3-3
pn  kleopatra  

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

[Johannes Schauer]

Hi,

Quoting Benjamin Drung (2020-01-10 17:43:49)
> > the reason I deactivated hooks for --dry-run is, that hooks are able to do
> > arbitrary stuff and when specifying --dry-run one probably does not expect
> > something meaningful to happen. With hooks you could shoot yourself in the
> > foot. I'm not strongly against allowing users to shoots themselves in the
> > foot, so another reason to disable them was, that it is then possible to
> > just add --dry-run to any command line (even including --hook options) and
> > have the result just work without errors and without the user having to
> > adjust the whole command line. But your example is a good argument to
> > actually leave hooks be and expect the user to handle whatever they do.
> 
> Executing the hooks in --dry-run has more drawbacks than benefits,
> because simple commands in the hooks would become much more complex.
> Because every invocation needs to learn the dry-run mode.

this is assuming that the user of mmdebstrap --dry-run does not just remove the
hooks altogether before adding --dry-run.

> How about adding --customize-hook-dry-run (etc.) and only execute those in
> dry-run mode? Then the users can decide on their own which hook needs a
> dry-run equivalent.

I think that would be too complex. If a user wants special hook A to be
executed in --dry-run mode and hook B in normal mode, then they would just
execute:

mmdebstrap --dry-run --hook A ...
mmdebstrap --hook B ...

I don't think it makes sense to move the logic into mmdebstrap.

> > This would not work anyways with --dry-run because you cannot chroot as the
> > directory does not contain any binaries.
> > 
> > In case you care: a much cleaner and robust way than the above fragile
> > grep/cut/sed to answer questions like "what would apt install" or "what are
> > dependency chains to this package" are to use apt's ability to rely on
> > third party solvers. You would pass apt your own EDSP script which would
> > intercept the communication between the apt frontend and the solver backend
> > and would then be able to parse the EDSP easily because it is in a format
> > similar to deb822.
> 
> Thanks for the pointer. I wasn't aware of doing that. Do you know any
> example third party solver doing that? Is it possible to add this hook
> to the apt call of mmdebstrap (and only to the apt call that installs
> the remaining packages)? If that is possible, then I don't need the
> dry-run hook support.

you would not replace the solver because you want to replicate the behaviour of
the apt solver. What you would do instead is to write a wrapper for the apt
solver that records the input and output in EDSP format and then uses deb822
aware tools like grep-dctrl to work with it. No regexes or other heuristics
needed then. You don't even need hooks, because in dry-run mode, apt is never
run inside the chroot, so you never need to put anything into it anyways. Here
is an example. Suppose you have a directory /tmp/mysolver and then put the
following script into /tmp/mysolver/mysolver and mark it as executable:

#!/bin/sh
set -exu
i=0
while [ -e /tmp/mysolver/$i ]; do i=$((i+1)); done
mkdir -p /tmp/mysolver/$i
cat > /tmp/mysolver/$i/input.edsp
cat /tmp/mysolver/$i/input.edsp | /usr/lib/apt/solvers/apt | tee 
/tmp/mysolver/$i/output.edsp
for aptid in $(grep-dctrl '' /tmp/mysolver/$i/output.edsp -s Install 
-n); do
grep-dctrl --exact-match --field APT-ID $aptid 
/tmp/mysolver/$i/input.edsp
done > /tmp/mysolver/$i/output.pkglist

And then you run mmdebstrap like this:

./mmdebstrap --mode=fakechroot --debug --dry-run \
--aptopt='apt::solver "mysolver"' \
--aptopt='Dir::Bin::solvers "/tmp/mysolver"' \
--variant=essential --include=linux-image-amd64 \
unstable debian-unstable.tar

Then in /tmp/mysolver/0/output.pkglist, /tmp/mysolver/1/output.pkglist and
/tmp/mysolver/2/output.pkglist you will find machine readable deb822 files
containing all packages that apt installed in each of the three times that it
was executed.

Thanks!

cheers, josch


signature.asc
Description: signature

Bug#939989: transition: gdal

[Sebastiaan Couwenberg]

On 1/10/20 11:06 PM, Sebastiaan Couwenberg wrote:
> On 1/9/20 6:52 PM, Sebastiaan Couwenberg wrote:
>> On 1/8/20 4:53 PM, Sebastiaan Couwenberg wrote:
>>> gdal (3.0.2+dfsg-1) is now built & installed on all release architectures.
>>>
>>> Please schedule the binNMUs.
>>
>> Thanks for scheduling the initial batch, everything has built now.
>> Please schedule the rest of Dependency level 1.
> 
> Now that pdal is built everywhere, please schedule grass & paraview.

grass is built & installed everywhere too, please schedule libgdal-grass
& qgis.

Kind Regards,

Bas

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



signature.asc
Description: OpenPGP digital signature

Bug#948257: initramfs-tools: Issue confirmation

[xiscu]

Package: initramfs-tools
Version: 0.135
Followup-For: Bug #948257

Dear Maintainer,
I can confirm that issue:

Processing triggers for initramfs-tools (0.135) ...
update-initramfs: Generating /boot/initrd.img-5.3.0-3-amd64
WARNING: Unknown X keysym "dead_belowmacron"
WARNING: Unknown X keysym "dead_belowmacron"
WARNING: Unknown X keysym "dead_belowmacron"
WARNING: Unknown X keysym "dead_belowmacron"
depmod: ERROR: ../libkmod/libkmod.c:515 lookup_builtin_file() could not open 
builtin file 
'/tmp/user/0/mkinitramfs_wGhhWc/lib/modules/5.3.0-3-amd64/modules.builtin.bin'
depmod: ERROR: ../libkmod/libkmod.c:515 lookup_builtin_file() could not open 
builtin file 
'/tmp/user/0/mkinitramfs_wGhhWc/lib/modules/5.3.0-3-amd64/modules.builtin.bin'

Thanks in advance,
xiscu

-- Package-specific info:
-- initramfs sizes
-rw-r--r-- 1 root root 34M Jan 11 12:14 /boot/initrd.img-5.3.0-3-amd64
-- /proc/cmdline
BOOT_IMAGE=/vmlinuz-5.3.0-3-amd64 root=/dev/mapper/r5--vg-root ro panic=5 quiet

-- resume
RESUME=/dev/mapper/r5--vg-swap_1
-- /proc/filesystems
btrfs
ext3
ext2
ext4

-- lsmod
Module  Size  Used by
ctr16384  3
ccm20480  9
bluetooth 659456  0
drbg   28672  1
ansi_cprng 16384  0
ecdh_generic   16384  1 bluetooth
ecc32768  1 ecdh_generic
msr16384  0
iwlmvm327680  0
snd_hda_codec_hdmi 65536  1
mac80211  872448  1 iwlmvm
snd_hda_codec_conexant24576  1
x86_pkg_temp_thermal20480  0
intel_powerclamp   20480  0
snd_hda_codec_generic94208  1 snd_hda_codec_conexant
ledtrig_audio  16384  2 snd_hda_codec_generic,snd_hda_codec_conexant
libarc416384  1 mac80211
binfmt_misc24576  1
kvm_intel 299008  0
i915 1949696  6
mei_wdt16384  0
intel_rapl_msr 20480  0
snd_hda_intel  49152  4
kvm   770048  1 kvm_intel
snd_hda_codec 159744  4 
snd_hda_codec_generic,snd_hda_codec_conexant,snd_hda_codec_hdmi,snd_hda_intel
drm_kms_helper212992  1 i915
iwlwifi   282624  1 iwlmvm
snd_hda_core  102400  5 
snd_hda_codec_generic,snd_hda_codec_conexant,snd_hda_codec_hdmi,snd_hda_intel,snd_hda_codec
irqbypass  16384  1 kvm
intel_cstate   16384  0
intel_uncore  147456  0
snd_hwdep  16384  1 snd_hda_codec
asus_nb_wmi28672  0
intel_rapl_perf16384  0
asus_wmi   36864  1 asus_nb_wmi
snd_pcm   118784  4 
snd_hda_codec_hdmi,snd_hda_intel,snd_hda_codec,snd_hda_core
evdev  28672  13
cfg80211  831488  3 iwlmvm,iwlwifi,mac80211
joydev 28672  0
pcspkr 16384  0
drm   552960  7 drm_kms_helper,i915
sparse_keymap  16384  1 asus_wmi
snd_timer  40960  1 snd_pcm
serio_raw  20480  0
iTCO_wdt   16384  0
processor_thermal_device20480  0
mei_me 45056  1
iTCO_vendor_support16384  1 iTCO_wdt
snd98304  16 
snd_hda_codec_generic,snd_hda_codec_conexant,snd_hda_codec_hdmi,snd_hwdep,snd_hda_intel,snd_hda_codec,snd_timer,snd_pcm
intel_rapl_common  28672  2 intel_rapl_msr,processor_thermal_device
rfkill 28672  6 asus_wmi,bluetooth,cfg80211
mei   122880  3 mei_wdt,mei_me
sg 40960  0
i2c_algo_bit   16384  1 i915
soundcore  16384  1 snd
watchdog   28672  2 iTCO_wdt,mei_wdt
intel_soc_dts_iosf 20480  1 processor_thermal_device
intel_pch_thermal  16384  0
acpi_als   20480  0
int3402_thermal16384  0
battery20480  0
int3400_thermal20480  0
int340x_thermal_zone16384  2 int3402_thermal,processor_thermal_device
nft_counter16384  1
kfifo_buf  16384  1 acpi_als
ac 16384  0
asus_wireless  20480  0
industrialio   90112  2 acpi_als,kfifo_buf
dell_smo8800   20480  0
acpi_thermal_rel   16384  1 int3400_thermal
intel_smartconnect 16384  0
button 20480  0
nft_ct 20480  1
nf_conntrack  167936  1 nft_ct
nf_defrag_ipv6 24576  1 nf_conntrack
nf_defrag_ipv4 16384  1 nf_conntrack
nf_tables_set  32768  1
nf_tables 163840  17 nft_ct,nft_counter,nf_tables_set
nfnetlink  16384  1 nf_tables
coretemp   20480  0
ip_tables  32768  0
x_tables   49152  1 ip_tables
autofs453248  3
ext4  757760  2
crc16  16384  2 bluetooth,ext4
mbcache16384  1 ext4
jbd2  131072  1 ext4
crc32c_generic 16384  0
btrfs1486848  0
zstd_decompress90112  1 btrfs
zstd_compress 184320  1 

Bug#948658: qemu: Qemu 4.2 hangs/freezes completely due to audio backend changes [regression][bisected]

[Matti Hamalainen]

Source: qemu
Severity: normal
Tags: upstream

Dear Maintainer,

After upgrading Qemu to 4.2-1 as packaged in Debian Testing, I encountered a
100% reproducible complete hang/freeze of Qemu/KVM while running a Windows 7
guest and starting Skype inside it. The Qemu GTK window would stop redrawing
and the program could only be ended with "kill -9". Obviously this is not good,
and can result in data loss inside the guest.

I took the effort to check if this issue appeared with upstream GIT Qemu and it
did, and doing a bisect I found that the first broken upstream commit was:

commit 286a5d201e432ed2963e5d860f239bb276edffeb
Author: Kővágó, Zoltán 
Date:   Thu Sep 19 23:24:10 2019 +0200

alsaaudio: port to the new audio backend api

Signed-off-by: Kővágó, Zoltán 
Message-id:
ab9768e73dfe7b7305bd6a51629846e0d77622a5.1568927990.git.dirty.ice...@gmail.com
Signed-off-by: Gerd Hoffmann 

As I am using ALSA (with DMIX, which may be a contributing factor - I had sound
issues previously with Virtualbox's ALSA support as well, related to DMIX, but
I haven't tested if it matters in this Qemu case), this new audio backend in
Qemu seems to be broken in some regard.

Interestingly enough the Win7 VM seems to work okay with some other sound-using
programs, like Firefox w/ youtube, but apparently Skype does something
different. Considering the nature of the issue, I suspect there are bound to be
other ways to trigger the problem, even with other guest OS etc.

Note: I have not reported this bug to the upstream, hoping for a forward
because I don't wish to create a "Ubuntu One" account (as silly as that may
sound) :D



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

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

Bug#948657: RM: paraview [armel armhf mips64el mipsel] -- RoQA; Architecture specific issue

[Bas Couwenberg]

Package: ftp.debian.org
Severity: normal

Please remove paraview for armel, armhf, mips64el & mipsel where it FTBFS due 
to architecture specific issues.

On mips64el it depends on libgdal20 which is going away after the transition 
(#939989).

Kind Regards,

Bas