Bug#964770: lintian: lintian will get stuck on arm64

[Felix Lechner]

Hi Kentaro,

On Fri, Jul 10, 2020 at 2:42 AM Kentaro Hayashi  wrote:
>
> It seems that IO::Async::Loop related code will stuck:

Lintian no longer uses IO::Async (although our test suite does). Have
you seen this issue recently? Otherwise, I would like to close this
bug. Thanks!

Kind regards
Felix Lechner

Bug#968607: [pkg-apparmor] Bug#968607: Bug#968607: pidgin-openpgp: AppArmor profil prevents execution of XEP-0027.pl

[Seth Arnold]

On Thu, Oct 29, 2020 at 09:14:55AM +0100, intrigeri wrote:
> Seth Arnold (2020-10-29):
> > Hello intrigeri, I'm not comfortable with this approach.
> Thanks for sharing. I hear you and it matters to me.

<3 :D

> Works for me. I've just uploaded 1.29 that drops the problematic
> Conflicts :)

Thanks!

> I believe that in practice, during a Buster → Bullseye upgrade,
> pidgin-openpgp will be removed anyway because libgtk2-perl will get
> removed. So in this context, having this Conflicts or not does not
> matter much. (I understand Ubuntu adopted a different strategy wrt.
> deprecating libgtk2-perl so things would look different there.)

Oh curious, I'm not accustomed to 'leaf' packages being removed on
upgrades; for example, on my Focal system now, I've got eight packages
installed that aren't available for download. (I used to have a lot more,
either I didn't notice them being removed some other time, or I actively
cleaned up my mess.)

Anyway, thanks for the quick turnaround. :) I appreciate it.

Thanks


signature.asc
Description: PGP signature

Bug#973406: libreoffice-calc: some cells not automatically recalculated

[Heinrich Schuchardt]

Package: libreoffice-calc
Version: 1:7.0.2-4
Severity: normal

Dear Maintainer,

Version: 7.0.2.2
Build ID: 00(Build:2)
CPU threads: 8; OS: Linux 5.9; UI render: default; VCL: x11
Locale: en-US (en_US.UTF-8); UI: en-US
Debian package version: 1:7.0.2-4
Calc: threaded

Given a LibreOffice Calc sheet with:

A1: 1970-01-01
A2: 2000-01-08
A3: =A2-A1
A4: =A3/86400

When I change the value of A2 the cell A3 is updated.
But A4 is NOT updated.

Only after pressing F9 A4 is recalculated.

LibreOffice should recalculate all cells.

Best regards

Heinrich Schuchardt

-- Package-specific info:

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

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

Versions of packages libreoffice-calc depends on:
ii  coinor-libcoinmp1v5  1.8.3-3
ii  libc62.31-4
ii  libetonyek-0.1-1 0.1.9-3
ii  libgcc-s110.2.0-15
ii  libicu67 67.1-4
ii  libmwaw-0.3-30.3.17-1
ii  libodfgen-0.1-1  0.1.7-1
ii  liborcus-0.16-0  0.16.1-3
ii  liborcus-parser-0.16-0   0.16.1-3
ii  libreoffice-base-core1:7.0.2-4
ii  libreoffice-common   1:7.0.2-4
ii  libreoffice-core 1:7.0.2-4
ii  librevenge-0.0-0 0.0.4-6+b1
ii  libstaroffice-0.0-0  0.0.7-1
ii  libstdc++6   10.2.0-15
ii  libuno-cppu3 1:7.0.2-4
ii  libuno-cppuhelpergcc3-3  1:7.0.2-4
ii  libuno-sal3  1:7.0.2-4
ii  libuno-salhelpergcc3-3   1:7.0.2-4
ii  libwps-0.4-4 0.4.12-1
ii  libxml2  2.9.10+dfsg-6.1
ii  lp-solve 5.5.2.5-2
ii  ucf  3.0043
ii  uno-libs-private 1:7.0.2-4

libreoffice-calc recommends no packages.

Versions of packages libreoffice-calc suggests:
ii  ocl-icd-libopencl1  2.2.12-4

Versions of packages libreoffice-core depends on:
ii  fontconfig  2.13.1-4.2
ii  fonts-opensymbol2:102.11+LibO7.0.2-4
ii  libboost-locale1.71.0   1.71.0-7+b1
ii  libc6   2.31-4
ii  libcairo2   1.16.0-4
ii  libclucene-contribs1v5  2.3.3.4+dfsg-1+b1
ii  libclucene-core1v5  2.3.3.4+dfsg-1+b1
ii  libcmis-0.5-5v5 0.5.2-2+b1
ii  libcups22.3.3-3
ii  libcurl3-gnutls 7.72.0-1
ii  libdbus-1-3 1.12.20-1
ii  libdconf1   0.38.0-1
ii  libeot0 0.01-5+b1
ii  libepoxy0   1.5.4-1
ii  libexpat1   2.2.10-1
ii  libexttextcat-2.0-0 3.4.5-1
ii  libfontconfig1  2.13.1-4.2
ii  libfreetype62.10.2+dfsg-4
ii  libgcc-s1   10.2.0-15
ii  libglib2.0-02.66.1-2
ii  libgpgmepp6 1.14.0-1+b1
ii  libgraphite2-3  1.3.14-1
ii  libgstreamer-plugins-base1.0-0  1.18.0-2
ii  libgstreamer1.0-0   1.18.0-3
ii  libharfbuzz-icu02.6.7-1
ii  libharfbuzz0b   2.6.7-1
ii  libhunspell-1.7-0   1.7.0-3
ii  libhyphen0  2.8.8-7
ii  libice6 2:1.0.10-1
ii  libicu6767.1-4
ii  libjpeg62-turbo 1:2.0.5-1.1
ii  liblcms2-2  2.9-4+b1
ii  libldap-2.4-2   2.4.54+dfsg-1
ii  libmythes-1.2-0 2:1.2.4-3+b1
ii  libneon27-gnutls0.31.2-1
ii  libnspr42:4.29-1
ii  libnss3 2:3.58-1
ii  libnumbertext-1.0-0 1.0.6-1
ii  liborcus-0.16-0 0.16.1-3
ii  liborcus-parser-0.16-0  0.16.1-3
ii  libpng16-16 1.6.37-3
ii  libpoppler102   20.09.0-2
ii  libqrcodegencpp11.5.0-2
ii  libraptor2-02.0.14-1+b1
ii  librdf0 1.0.17-1.1+b1
ii  libreoffice-common  1:7.0.2-4
ii  librevenge-0.0-00.0.4-6+b1
ii  libsm6  2:1.2.3-1
ii  libstdc++6  10.2.0-15
ii  libuno-cppu31:7.0.2-4
ii  libuno-cppuhelpergcc3-3 1:7.0.2-4
ii  libuno-sal3 1:7.0.2-4
ii  libuno-salhelpergcc3-3  1:7.0.2-4
ii  libx11-62:1.6.12-1
ii  libx11-xcb1 2:1.6.12-1
ii  libxext62:1.3.3-1+b2
ii  libxinerama12:1.1.4-2
ii  libxml2 2.9.10+dfsg-6.1
ii  libxmlsec1  1.2.30-1
ii  libxmlsec1-nss  1.2.30-1
ii  libxrandr2  2:1.5.1-1
ii  libxrender1 1:0.9.10-1
ii  

Bug#972793: Patch attached

[Jelmer Vernooij]

The attached patch (also available on
https://salsa.debian.org/python-team/packages/hg-git/-/merge_requests/3)
fixes the compatibility with
the new Dulwich API and should allow both Dulwich and hg-git to
migrate to testing.

I couldn't easily work out how to prevent DeprecationWarnings from
breaking the tests, so I'll file a separate (normal severity) bug
about that.

Tristan, are you happy for me to upload the package with that
change?

-- 
Jelmer Vernooij 
PGP Key: https://www.jelmer.uk/D729A457.asc
=== modified file 'debian/changelog'
--- old/debian/changelog	2020-09-24 06:48:41 +
+++ new/debian/changelog	2020-10-30 00:05:53 +
@@ -1,10 +1,15 @@
 hg-git (0.9.0-2) UNRELEASED; urgency=medium
 
+  [ Ondřej Nový ]
   * d/control: Update Maintainer field with new Debian Python Team
 contact address.
   * d/control: Update Vcs-* fields with new Debian Python Team Salsa
 layout.
 
+  [ Jelmer Vernooij ]
+  * Add patch 0003-dulwich-compat.patch: avoid deprecation warning with newer
+versions of Dulwich. Closes: #972793
+
  -- Ondřej Nový   Thu, 24 Sep 2020 08:48:41 +0200
 
 hg-git (0.9.0-1) unstable; urgency=medium

=== modified file 'debian/control'
--- old/debian/control	2020-09-24 06:48:41 +
+++ new/debian/control	2020-10-30 00:05:53 +
@@ -10,7 +10,7 @@
  python3-mercurial,
  openssh-client,
  python3,
- python3-dulwich,
+ python3-dulwich (>= 0.20.6),
  python3-setuptools,
  unzip,
 Standards-Version: 4.5.0
@@ -23,7 +23,7 @@
 Architecture: all
 Depends:
  python3-mercurial,
- python3-dulwich (>= 0.9.7),
+ python3-dulwich (>= 0.20.6),
  ${misc:Depends},
  ${python3:Depends},
 Description: Git plugin for Mercurial

=== added file 'debian/patches/0003-dulwich-compat.patch'
--- old/debian/patches/0003-dulwich-compat.patch	1970-01-01 00:00:00 +
+++ new/debian/patches/0003-dulwich-compat.patch	2020-10-30 00:05:53 +
@@ -0,0 +1,13 @@
+=== modified file 'hggit/git_handler.py'
+--- old/hggit/git_handler.py	2020-08-13 11:43:06 +
 new/hggit/git_handler.py	2020-10-29 23:50:16 +
+@@ -1113,7 +1113,7 @@
+ 
+ try:
+ new_refs = client.send_pack(path, changed, genpack,
+-progress=callback)
++progress=callback).refs
+ if len(change_totals) > 0:
+ self.ui.status(_(b"added %d commits with %d trees"
+  b" and %d blobs\n") %
+

=== modified file 'debian/patches/series'
--- old/debian/patches/series	2020-08-13 14:15:34 +
+++ new/debian/patches/series	2020-10-30 00:05:53 +
@@ -1,2 +1,3 @@
 0001-Set-explicit-merge-messages.patch
 0002-Silence-git-pull-warning.patch
+0003-dulwich-compat.patch



signature.asc
Description: PGP signature

Bug#973402: RFS: zope.schema/6.0.0-1 [QA] -- zope.interface extension for defining data schemas

[Håvard Flaget Aasen]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "zope.schema":

 * Package name: zope.schema
   Version : 6.0.0-1
   Upstream Author : Zope Foundation and Contributors 
 * URL : https://pypi.python.org/pypi/zope.schema
 * License : Zope-2.1
   Section : zope

It builds those binary packages:

  python3-zope.schema - zope.interface extension for defining data schemas

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

  https://mentors.debian.net/package/zope.schema/

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

  dget -x
https://mentors.debian.net/debian/pool/main/z/zope.schema/zope.schema_6.0.0-1.dsc

Changes since the last upload:

 zope.schema (6.0.0-1) unstable; urgency=medium
 .
   * QA upload.
   * New upstream release.
   * Set upstream metadata fields: Bug-Database, Bug-Submit, Repository,
 Repository-Browse
   * d/control:
 - Update Standards-Version to 4.5.0
 - Bump debhelper to 13
 - Set minimum version on python3-zope.interface

Regards,
H??vard

Bug#969247:

[Marcos Raúl Carot]

"Boinc Manager is run as the local user and the file in question in not

readable by any user outside of root and boinc group. Changing the file to
world readable fixes the bug, but this might not be an ideal solution.
Alternatives are running Boinc Manager elevated or a manual sudo to read
the file and input the text into Boinc Manager manually."

Would making oneself member of the boinc group work?


Thanks!
-- 
Marcos R Carot

Bug#973405: fakeroot on amd64 stopped supporting armel, armhf and mipsel chroots

[Johannes 'josch' Schauer]

Package: fakeroot
Version: 1.25.2-1
Severity: important

Hi,

I'm the maintainer of mmdebstrap which uses fakeroot and fakechroot to
also create foreign architecture chroots. Doing something like this
worked fine until 2020-09-15:

$ mmdebstrap --mode=fakechroot --variant=apt --arch=armhf sid ./sid-chroot

With amd64 on my machine I also tried other architectures and as of
today, the following arches result in an infinite timeout with above
command: armel, armhf, mipsel and s390x.

For armhf I was able to bisect Debian using snapshot.debian.net and find
out that the first snapshot timestamp that produces the timeout is
2020-09-15 06:00:00+01:00. For the other architectures, I am not able to
produce a precise timestamp because fakeroot suffered from #971070 and
thus I was unable to test two weeks of snapshot.d.o data.

To run the precise command producing the infinite hang, try creating a
armhf chroot using mmdebstrap (I'm unaware of another tool that is able
to create foreign architecture chroots using fakeroot and fakechroot):

$ mmdebstrap --mode=fakechroot --variant=apt --arch=armhf unstable 
/tmp/debian-unstable

You have to ctrl+C above command at the "Installing..." step because
that one will stall forever. Then run:

$ fakechroot fakeroot sh -c 'env QEMU_LD_PREFIX=/tmp/debian-unstable 
LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/lib/arm-linux-gnueabihf/fakechroot:/usr/lib/arm-linux-gnueabihf/libfakeroot
 /usr/sbin/chroot debian-unstable dpkg --install /var/cache/apt/archives/*.deb'

If I run above via strace, then the last lines are:

1830621 msgget(0x223a3efb, IPC_CREAT|0600) = 6881280
1830621 msgget(0x223a3efc, IPC_CREAT|0600) = 6914049
1830621 getpid()= 1830621
1830621 semget(0x223a3efd, 1, IPC_CREAT|0600) = 3506176
1830621 semtimedop(3506176, [{0, -1, SEM_UNDO}], 1, NULL) = 0
1830621 msgsnd(6881280, {1, 
"\0\0\0\0\3\0\0\0\335\356\33\0\1\0\0\0\350\3\0\0\350\3\0\0.0\313\0\0\0\0\0"...},
 1088, 0) = 0
1830613 <... msgrcv resumed> {1, 
"\0\0\0\0\3\0\0\0\335\356\33\0\1\0\0\0\350\3\0\0\350\3\0\0.0\313\0\0\0\0\0"...},
 1096, 0, 0) = 1088
1830613 msgrcv(6881280,

A workaround for this problem is to explicitly use fakeroot-tcp. The
command will be much slower but it will finish successfully. So it seems
only fakeroot-sysv is broken between amd64 and armel, armhf, mipsel and s390x.

Thanks!

cheers, josch

Bug#973393: truncate less of the backtrace during failing ert tests

[Sean Whitton]

Hello,

On Thu 29 Oct 2020 at 03:42PM -04, Nicholas D. Steeves wrote:

> Thomas Koch added a nice workaround for truncated backtraces at:
>
>   https://wiki.debian.org/Teams/DebianEmacsenTeam/Tips
>
> that workaround is d/elpa-test:
>
>   ert_eval = (setq ert-batch-backtrace-right-margin 500)
>
> and I wonder if it should be activated by default, in the spirit of
> Policy §4.9 "The package build should be as verbose as reasonably
> possible".  Speaking for myself, I would find it helpful, especially
> for the rare corner cases where only noninteractive --batch ert tests
> will trigger a failure.  Also, I've been asked for untruncated
> backtraces by various upstreams.
>
> The only potential issue I can think of is that the reproducible and
> DebCI build logs will have then have long lines, but I feel like the
> benefit outweighs this consideration.  A possible, though not ideal,
> solution to this potential issue might be to word-wrap the backtrace,
> but that functionality should probably be enabled in upstream Emacs.
>
> Let's consider setting `ert-batch-backtrace-right-margin` to a large
> value in the meantime.

I think this is a good idea.  Patches welcome.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#971976: libtraceevent-dev: please build from git.kernel.org/pub/scm/libs/libtrace/libtraceevent.git

[Ben Hutchings]

On Wed, 2020-10-28 at 12:14 +, Sudip Mukherjee wrote:
> Hi Ben,
> 
> On Mon, Oct 19, 2020 at 09:35:00PM +0100, Sudip Mukherjee wrote:
[...]
> > Thanks.
> > I have opened the MR to remove libtracevent from kernel at:
> > https://salsa.debian.org/kernel-team/linux/-/merge_requests/275.
> > 
> > And the new package for libtraceevent is at:
> > https://salsa.debian.org/sudip/libtraceevent.
> > I have not uploaded yet, just thought if you will like to have a look at
> > it first (specially the copyright for debian/*).
> 
> Did you get the chance to have a look at it? Or if you are busy now I can
> upload and modify copyright for debian/* later after it has passed the
> NEW queue.

We've now discussed this on IRC and I'm basically happy with these
changes.  Minor issues to correct:

* The new source package no longer builds with V=1, which it should do
  by default (policy §4.9).
* The merge request should target the sid branch (master is going to be
  used for experimental uploads).

Ben.

-- 
Ben Hutchings
The first rule of tautology club is the first rule of tautology club.




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

Bug#973404: linux-config-5.9: T14 AMD Laptop (Renoir) - Microphone Doesn't Function

[Jonathan]

Package: linux-config-5.9
Version: 5.9.1-1
Severity: normal

Dear Maintainer,

My Lenovo T14 AMD laptop does not show a selectable microphone device. 
lspci -v shows a device without a driver attached and I assume that to be the 
related hardware:

07:00.5 Multimedia controller: Advanced Micro Devices, Inc. [AMD] 
Raven/Raven2/FireFlight/Renoir Audio Processor (rev 01)
Subsystem: Lenovo Raven/Raven2/FireFlight/Renoir Audio Processor
Flags: fast devsel, IRQ 255, IOMMU group 8
Memory at fd38 (32-bit, non-prefetchable) [disabled] [size=256K]
Capabilities: 

arch linux shows that the following requirements are needed though I am not 
well educated in Linux to know if this does apply:

"On the AMD version, the internal microphone requires a kernel version of at 
least 5.8-rc7 with CONFIG_SND_SOC_AMD_RENOIR=m and 
CONFIG_SND_SOC_AMD_RENOIR_MACH=m.
 4-pin jack plugs work with a linux kernel of 5.7."

I am currently on Bullseye 5.9 kernel.

Thank you




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

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

linux-config-5.9 depends on no packages.

Versions of packages linux-config-5.9 recommends:
ii  linux-source-5.9  5.9.1-1

linux-config-5.9 suggests no packages.

-- no debconf information

Bug#973392: cmake-data is not Multi-Arch: foreign

[Kyle Edwards]

Package: cmake-data
Version: 3.18.4-1
Severity: minor

The same cmake-data package can be used by cmake on any architecture. 
However, it is not marked it as "Multi-Arch: foreign", which makes it 
impossible to install a foreign-arch CMake on a multi-arch system (for 
example, installing i386 CMake on amd64).

Bug#973373: blueman: Blueman requires authentication twice on start-up

[Christopher Schramm]

Hi Andrew,

the 2.0.8 security update enabled Polkit-1 authorization. There is a 
rules file at /usr/share/polkit-1/rules.d/blueman.rules that allows 
access without authentication to users in the sudo and netdev groups. 
You should be fine if you add your user to netdev.


Cheers

Bug#973403: softether-common: hamcore.se2 broken

[Martin Sofaru]

Package: softether-common
Version: 5.01.9674+git20200806+8181039+dfsg-2
Severity: grave
Justification: renders package unusable
X-Debbugs-Cc: debian-b...@fhloston.org

Dear Maintainer,

neither softether-vpnserver nor softether-vpnbridge actually starts.

Following error is reported:

Oct 27 21:20:25 iceborg vpnbridge[1677]: -- Alert: SoftEther VPN Kernel --
Oct 27 21:20:25 iceborg vpnbridge[1677]: Fatal Error: The file "hamcore.se2" is 
missing or broken.
Oct 27 21:20:25 iceborg vpnbridge[1677]: Please check hamcore.se2.
Oct 27 21:20:25 iceborg vpnbridge[1677]: #015

It seems the hamcore.se2 file provided by softether-common is too 
small/contains only the authors.

-rw-r--r-- 1 root root 1832 Oct 19 14:14 /usr/share/softether-common/hamcore.se2

Thank you for providing softether as a debian package!

Martin

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

Bug#973395: clang-10: Unable to package LLVM/Clang on Buster (for backports) - libffi error

[Sylvestre Ledru]

Hello,

Le 29/10/2020 à 20:51, Maxime Lombard a écrit :


Dear Maintainer,

I'm an user of Debian Buster and i tried to backport LLVM-10 from Testing to 
have the latest version of Mesa.
There are no issues when i package LLVM for AMD64 architecture, the problem 
appears only when i package for i386 arch.

[...]

[...]

Obviously, libffi-dev package is installed at the beginning.
I tried to backports libffi too without success.


You should look at the content of CMakeError.log to find for the actual 
error.


Cheers,

S

Bug#972973: Please re-enable SECO HDMI CEC driver (CONFIG_VIDEO_SECO_CEC)

[Salvatore Bonaccorso]

Hi,

On Mon, Oct 26, 2020 at 07:37:52PM +0100, Sébastien Noel wrote:
> Package: src:linux
> Severity: wishlist
> 
> Dear Maintainer,
> 
> Could you please re-enable the option CONFIG_VIDEO_SECO_CEC ?
> I already did requested this via bug #951543,
> it worked for a time, but since linux-5.8 it seems you disabled it again :'(
> 
> # grep -i seco /boot/config-5.7.0-0.bpo.2-amd64
> CONFIG_VIDEO_SECO_CEC=m
> 
> $ grep -i seco /boot/config-5.8.0-0.bpo.2-amd64
> # CONFIG_CEC_SECO is not set
> 
> Could you explain why you did remove this module ?

The config option name is not the same in 5.7.y and 5.8.y. This
unintentionally got lost when we rebased to the 5.8 stable version, as
upstream did rename those in df823a8208c4 ("media: cec: rename CEC
platform drivers config options")[1] in 5.8-rc1.

 [1] https://git.kernel.org/linus/df823a8208c434eee6e4e9aa016c956d0968e2e2

So yes we should re-enable support.

So the following should be needed:

CONFIG_CEC_PLATFORM_DRIVERS=y
CONFIG_CEC_SECO=m

Regards,
Salvatore

Bug#924303: [Pkg-fonts-devel] Bug#924303: Bug#924303: fonts-noto-core: creates an obsolete config file

[Laurent Bonnaud]

On 10/29/20 6:10 PM, Jonas Smedegaard wrote:


Did you have fonts-noto-core 20181227-1 installed, or installed and then
removed, or installed and then purged, when you ran that command?


I don't remember exactly.  However I tried to reproduce the problem on a recent 
system both with fonts-noto-core 20181227-1 and 20201027-3 and could not 
reproduce the problem.  Therefore I consider it to be fixed.

You can close this bug if you wish or I can do it if you prefer.

Thanks for checking this issue!

--
Laurent.

Bug#973374: uscan: 'pgpmode=gittag' fails when USCAN_DESTDIR is set

[Xavier]

Control: tags -1 + pending

See https://salsa.debian.org/debian/devscripts/-/merge_requests/205

Cheers,
Xavier

Bug#972702: ruby-bundler: dependency resolution fails for compiled gems

[Antonio Terceiro]

On Thu, Oct 29, 2020 at 01:21:03PM +0100, David Rodríguez wrote:
> El 29/10/20 a las 13:14, Antonio Terceiro escribió:
> 
> > On Thu, Oct 29, 2020 at 11:17:59AM +0100, David Rodríguez wrote:
> > > Hi!
> > > 
> > > Just to clarify why I prefer the second solution, I think what debian 
> > > does is shipping precompiled versions of extensions, so technically the 
> > > gemspec shipped in the debian should include no extensions at all. This 
> > > is something some upstream gems already do. Take, for example, 
> > > google-protobuf. It has a precompiled version for linux: 
> > > https://rubygems.org/gems/google-protobuf/versions/3.13.0-x86_64-linux. 
> > > If we fetch and unpack this package, we can see it includes the prebuilt 
> > > `.so` extension, but no extensions in its gemspec:
> > > 
> > > $ gem fetch google-protobuf
> > > Fetching google-protobuf-3.13.0-x86_64-linux.gem
> > > Downloaded google-protobuf-3.13.0-x86_64-linux
> > > 
> > > $ gem unpack google-protobuf-3.13.0-x86_64-linux.gem
> > > Unpacked gem: 
> > > '/home/deivid/Code/playground/google-protobuf-3.13.0-x86_64-linux'
> > > 
> > > $ find google-protobuf-3.13.0-x86_64-linux -name '*.so'
> > > google-protobuf-3.13.0-x86_64-linux/lib/google/2.6/protobuf_c.so
> > > google-protobuf-3.13.0-x86_64-linux/lib/google/2.4/protobuf_c.so
> > > google-protobuf-3.13.0-x86_64-linux/lib/google/2.7/protobuf_c.so
> > > google-protobuf-3.13.0-x86_64-linux/lib/google/2.5/protobuf_c.so
> > > google-protobuf-3.13.0-x86_64-linux/lib/google/2.3/protobuf_c.so
> > > 
> > > $ gem unpack google-protobuf-3.13.0-x86_64-linux.gem --spec && grep 
> > > extensions google-protobuf-3.13.0-x86_64-linux.gemspec
> > > extensions: []
> > > 
> > > I think the cleanest solution would be for debian to do the same thing.
> > Fair enough. Now that I think about it, extensions is supposed to be
> > a list of extensions that need to be built, so indeed dropping it from
> > the gemspec included in the Debian packages make sense.
> Yeah, that's exactly how I expect the `extensions` field to be interpreted.

On the other hand, our packages that already use the rubygems machinery
to install, already contain the gem_build.complete file:

$ dpkg -L ruby-byebug | grep complete
/usr/lib/x86_64-linux-gnu/rubygems-integration/2.7.0/extensions/x86_64-linux/2.7.0/byebug-11.1.3/gem.build_complete

8<8<8<-
$ cat > Gemfile
source "https://rubygems.org/;
gem "byebug"
8<8<8<-
$ bundle --local
Resolving dependencies...
Using byebug 11.1.3
Using bundler 2.2.0.rc.1
Following files may not be writable, so sudo is needed:
  /usr/local/bin
  /var/lib/gems/2.7.0
Bundle complete! 1 Gemfile dependency, 2 gems now installed.
Use `bundle info [gemname]` to see where a bundled gem is installed.
8<8<8<-
$ echo 'gem "ffi"' >> Gemfile
8<8<8<-
$ bundle --local
Could not find gem 'ffi' in any of the gem sources listed in your Gemfile.
8<8<8<-

So this is only a problem for the "old-style" packages that install their
stuff to vendor_ruby and don't install as gems:

$ dpkg -L ruby-ffi | grep gem.build_complete
(nothing)

and they are quite a few packages yet:

$ apt-file search vendor_ruby/ | grep '\.so$' | wc -l
164


signature.asc
Description: PGP signature

Bug#973356: [pkg-apparmor] Bug#973356: apparmor-profiles: complain on syslog-ng opening system.journal until re-enabling profile

[Christian Boltz]

Hello,

Am Donnerstag, 29. Oktober 2020, 12:43:08 CET schrieb Lorenzo Iannuzzi:
> apparmor="ALLOWED" operation="open" profile="syslog-
> ng//null-/bin/dash//null-/usr/sbin/sshguard//null-/bin/journalctl"

This is interesting[tm] - syslog-ng executed dash, which then executed 
sshguard, which executed journalctl.

That looks like a funny way to read from the journal...

> name="/run/log/journal/ccca544565cf1834599ef913deceef00/system.journal
> " pid=6749 comm="journalctl" requested_mask="r" denied_mask="r"
> fsuid=0 ouid=0
> 
> I can see some rules from profile that should permit the access to
> that file:
>   /{var,var/run,run}/log/journal/ r,
>   /{var,var/run,run}/log/journal/*/ r,
>   /{var,var/run,run}/log/journal/*/*.journal r,

Right, but there are no rules that allow to execute dash, sshguard and 
journalctl.

> and if I disable and enable again the profile (with aa-disable and
> aa-complain) log messages doesn't show anymore.

aa-disable unloads the profile from the kernel, which also means that 
running processes become unconfined.

aa-complain loads the profile again (in complain mode), but it can't 
apply it to running processes, so they stay unconfined (until you 
restart them).

Note that this probably only affects the syslog-ng profile, not the 
processes running under the syslog-ng//null-* profiles.

The better way is to use only aa-complain, which will switch the profile 
to complain mode and leave running processes confined.

> Why those log are shown on boot, but disappear after I reload the
> syslog-ng profile?

See above, it's probably because you first unload the profile with aa-
disable and then have syslog-ng running unconfined.

Can you please check if there are processes running under a profile 
starting with "syslog-ng"? You can do this with
ps Zaux | grep ^syslog-ng
Ideally check it before and after reloading the profiles.
Also restart syslog-ng and check again.

Also, do fresh log messages appear if you restart syslog-ng?

Bonus question: Do you have a non-default syslog-ng config that could 
explain the exec chain I mentioned at the beginning?


Regards,

Christian Boltz
-- 
> Would it be ok to just switch all build sections to use lua?
> Probably much faster than the shells anyway :-P
Yast team has experience in converting strange languages to
each other - they can cook something! :)
[> Stefan Seyfried and Stephan Kulow in opensuse-factory]


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

Bug#972901: closed by Debian FTP Masters (reply to Andreas Beckmann ) (Bug#972901: fixed in nvidia-graphics-drivers 450.80.02-1)

[mando]

Dear maintainers,

I 'm still unable to install nvidia-kernel-dkms after fresh update + 
reboot + apt reinstall linux-image-$(uname -r) nvidia-kernel-dkms.


(mando@aldur) (~) $ cat /etc/apt/sources.list
deb http://ftp.fr.debian.org/debian/ testing main contrib non-free
deb http://security.debian.org testing-security main contrib non-free
deb http://ftp.fr.debian.org/debian/ testing-updates main contrib non-free

(mando@aldur) (~) $ sudo aptitude install nvidia-kernel-dkms
Les NOUVEAUX paquets suivants vont être installés :
  nvidia-kernel-common{a} nvidia-kernel-dkms nvidia-kernel-support{a} 
nvidia-modprobe{a}
0 paquets mis à jour, 4 nouvellement installés, 0 à enlever et 0 non mis 
à jour.
Il est nécessaire de télécharger 0 o/12,5 Mo d'archives. Après 
dépaquetage, 35,8 Mo seront utilisés.

Voulez-vous continuer ? [Y/n/?]
(Lecture de la base de données... 209575 fichiers et répertoires déjà 
installés.)
Préparation du dépaquetage de 
.../nvidia-kernel-common_20151021+12_amd64.deb ...

Dépaquetage de nvidia-kernel-common (20151021+12) ...
Sélection du paquet nvidia-modprobe précédemment désélectionné.
Préparation du dépaquetage de .../nvidia-modprobe_450.66-1_amd64.deb ...
Dépaquetage de nvidia-modprobe (450.66-1) ...
Préparation du dépaquetage de 
.../nvidia-kernel-support_450.66-1_amd64.deb ...

Dépaquetage de nvidia-kernel-support (450.66-1) ...
Sélection du paquet nvidia-kernel-dkms précédemment désélectionné.
Préparation du dépaquetage de .../nvidia-kernel-dkms_450.66-1_amd64.deb ...
Dépaquetage de nvidia-kernel-dkms (450.66-1) ...
Paramétrage de nvidia-kernel-common (20151021+12) ...
Paramétrage de nvidia-modprobe (450.66-1) ...
Paramétrage de nvidia-kernel-support (450.66-1) ...
Traitement des actions différées (« triggers ») pour nvidia-alternative 
(450.66-1) ...

Traitement des actions différées (« triggers ») pour man-db (2.9.3-2) ...
Paramétrage de nvidia-kernel-dkms (450.66-1) ...
Loading new nvidia-current-450.66 DKMS files...
Building for 5.9.0-1-amd64
Building initial module for 5.9.0-1-amd64
Error! Bad return status for module build on kernel: 5.9.0-1-amd64 (x86_64)
Consult /var/lib/dkms/nvidia-current/450.66/build/make.log for more 
information.

dpkg: erreur de traitement du paquet nvidia-kernel-dkms (--configure) :
 installed nvidia-kernel-dkms package post-installation script 
subprocess returned error exit status 10
Traitement des actions différées (« triggers ») pour 
glx-alternative-nvidia (1.2.0) ...
Traitement des actions différées (« triggers ») pour 
glx-alternative-mesa (1.2.0) ...

Traitement des actions différées (« triggers ») pour update-glx (1.2.0) ...
Traitement des actions différées (« triggers ») pour libc-bin (2.31-4) ...
Traitement des actions différées (« triggers ») pour 
glx-alternative-nvidia (1.2.0) ...

Traitement des actions différées (« triggers ») pour libc-bin (2.31-4) ...
Traitement des actions différées (« triggers ») pour initramfs-tools 
(0.139) ...

update-initramfs: Generating /boot/initrd.img-5.9.0-1-amd64
W: Possible missing firmware /lib/firmware/i915/rkl_dmc_ver2_01.bin for 
module i915

Des erreurs ont été rencontrées pendant l'exécution :
 nvidia-kernel-dkms
E: Sub-process /usr/bin/dpkg returned an error code (1)
Paramétrage de nvidia-kernel-dkms (450.66-1) ...
Removing old nvidia-current-450.66 DKMS files...

--
Deleting module version: 450.66
completely from the DKMS tree.
--
Done.
Loading new nvidia-current-450.66 DKMS files...
Building for 5.9.0-1-amd64
Building initial module for 5.9.0-1-amd64
Error! Bad return status for module build on kernel: 5.9.0-1-amd64 (x86_64)
Consult /var/lib/dkms/nvidia-current/450.66/build/make.log for more 
information.

dpkg: erreur de traitement du paquet nvidia-kernel-dkms (--configure) :
 installed nvidia-kernel-dkms package post-installation script 
subprocess returned error exit status 10

Des erreurs ont été rencontrées pendant l'exécution :
 nvidia-kernel-dkms

See also attached make.log. The problem seems to be related to some 
options of the compiler changing warnings to errors 
(-Werror=implicit-function-declaration, -Wimplicit-fallthrough=, 
-Werror=incompatible-pointer-types, etc). I don't know to disable these 
options (and if this is a good idea).


Best regards

Le 29/10/2020 à 01:39, Debian Bug Tracking System a écrit :

This is an automatic notification regarding your Bug report
which was filed against the nvidia-kernel-dkms package:

#972901: nvidia-kernel-dkms: Nvidia driver won't compile

It has been closed by Debian FTP Masters  (reply to 
Andreas Beckmann ).

Their explanation is attached below along with your original report.
If this explanation is unsatisfactory and you have not received a
better one in a separate message then please contact Debian FTP Masters 
 (reply to Andreas Beckmann ) 
by
replying to this email.


DKMS make.log for nvidia-current-450.66 for kernel 5.9.0-1-amd64 (x86_64)
jeu. 29 oct. 2020 22:15:05 CET
make 

Bug#973401: initscripts: TMPTIME=0 should mkfs for separate filesystem

[Nigel Horne]

Package: initscripts
Version: 2.96-5
Severity: wishlist

Dear Maintainer,

If TMPTIME is set to 0 (remove all files are removed regardless of age)
and /tmp is mounted as a separate filesystem on disk, why not simply
run mkfs on the filesystem before mounting it?  As well as clearing out
fluff more quickly, it'll also put the filesystem into a pristeen state.


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

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

Versions of packages initscripts depends on:
ii  lsb-base  11.1.0
ii  sysv-rc   2.96-5

Versions of packages initscripts recommends:
ii  e2fsprogs  1.45.6-1
ii  psmisc 23.3-1

initscripts suggests no packages.

-- Configuration Files:
/etc/default/rcS changed:
TMPTIME=14
FSCKFIX=yes

/etc/init.d/rc.local changed:
PATH=/sbin:/usr/sbin:/bin:/usr/bin
. /lib/init/vars.sh
. /lib/lsb/init-functions
do_start() {
if [ -x /etc/rc.local ]; then
[ "$VERBOSE" != no ] && log_begin_msg "Running local boot 
scripts (/etc/rc.local)"
/etc/rc.local start
ES=$?
[ "$VERBOSE" != no ] && log_end_msg $ES
return $ES
fi
}
do_stop() {
if [ -x /etc/rc.local ]; then
[ "$VERBOSE" != no ] && log_begin_msg "Stopping local boot 
scripts (/etc/rc.local)"
/etc/rc.local stop
ES=$?
[ "$VERBOSE" != no ] && log_end_msg $ES
return $ES
fi
}
case "$1" in
start)
do_start
;;
restart|reload|force-reload)
echo "Error: argument '$1' not supported" >&2
exit 3
;;
stop)
do_stop
;;
*)
echo "Usage: $0 start|stop" >&2
exit 3
;;
esac

/etc/rc.local changed:
if [ $# -eq 0 ]
then
arg=start
else
arg="$1"
fi
export http_proxy=http://127.0.0.1:3128
export no_proxy=localhost
export ftp_proxy=http://127.0.0.1:3128
case "$arg" in
  start|"")
echo "Starting local services..."

mount -o remount,rw,hidepid=2 /proc
if [ ! -d /var/run/clamav ]; then
mkdir /var/run/clamav
chown -R clamav:clamav /var/run/clamav
fi
# LD_LIBRARY_PATH=/usr/local/lib /usr/local/sbin/clamd&
# LD_LIBRARY_PATH=/usr/local/lib /usr/local/bin/freshclam --quiet&
echo 1 >/proc/sys/net/ipv4/ip_forward
iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE
# http://lists.netfilter.org/pipermail/netfilter/2002-May/034048.html
# eth1 is connected to the modem, eth0 to the internal network
## SYN-FLOODING PROTECTION
iptables -N syn-flood
iptables -A INPUT -i eth1 -p tcp --syn -j syn-flood
iptables -A syn-flood -m limit --limit 1/s --limit-burst 4 -j RETURN
iptables -A syn-flood -j DROP
## Make sure NEW tcp connections are SYN packets
iptables -A INPUT -i eth1 -p tcp ! --syn -m state --state NEW -j DROP
# Limit max connections per IP address
iptables -A INPUT -i eth1 -p tcp --syn -m connlimit --connlimit-above 
15 --connlimit-mask 32 -j REJECT --reject-with tcp-reset
# Allow 160 new connections per second before limit of 150 new
# connects per second is applied
iptables -A INPUT -i eth1 -m state --state RELATED,ESTABLISHED -m limit 
--limit 150/second --limit-burst 160 -j ACCEPT
## FRAGMENTS
# Log fragments just to see if we get any, and deny them too.
# iptables -A INPUT -i eth1 -f -j LOG --log-prefix "IPTABLES FRAGMENTS: 
"
# iptables -A INPUT -i eth1 -f -j DROP
## SPOOFING
# Refuse spoofed packets pretending to be from your IP address.
iptables -A INPUT -i eth1 -s 192.168.1.0/24 -j DROP
# Refuse packets claiming to be from a Class A private network.
iptables -A INPUT -i eth1 -s 10.0.0.0/8 -j DROP
# Refuse packets claiming to be from a Class B private network.
iptables -A INPUT -i eth1 -s 172.16.0.0/12 -j DROP
# Refuse packets claiming to be from a Class C private network.
# iptables -A INPUT -i eth1 -s 192.168.0.0/16 -j DROP
# Refuse Class D multicast addresses. Multicast is illegal as a source
# address.
# iptables -A INPUT -i eth1 -s 224.0.0.0/4 -j DROP
# Refuse Class E reserved IP addresses.
iptables -A INPUT -i eth1 -s 240.0.0.0/4 -j DROP
# Refuse packets claiming to be to the loopback interface.
iptables -A INPUT -i eth1 -d 127.0.0.1/27 -j DROP
# Refuse broadcast address packets.
# iptables -A INPUT -i eth1 -d 192.168.1.31 -j DROP
# Block spoofed traffic on LAN

Bug#973400: samba: CVE-2020-14318

[Salvatore Bonaccorso]

Source: samba
Version: 2:4.12.5+dfsg-3
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 
Control: found -1 2:4.9.5+dfsg-5
Control: found -1 2:4.9.5+dfsg-5+deb10u1

Hi,

The following vulnerability was published for samba.

CVE-2020-14318[0]:
| Missing handle permissions check in SMB1/2/3 ChangeNotify

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2020-14318
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-14318
[1] https://www.samba.org/samba/security/CVE-2020-14318.html

Regards,
Salvatore

Bug#973399: samba: CVE-2020-14323

[Salvatore Bonaccorso]

Source: samba
Version: 2:4.12.5+dfsg-3
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 
Control: found -1 2:4.9.5+dfsg-5+deb10u1
Control: found -1  2:4.9.5+dfsg-5

Hi,

The following vulnerability was published for samba.

CVE-2020-14323[0]:
| A null pointer dereference flaw was found in samba's Winbind service
| in versions before 4.11.15, before 4.12.9 and before 4.13.1. A local
| user could use this flaw to crash the winbind service causing denial
| of service.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2020-14323
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-14323
[1] https://security-tracker.debian.org/tracker/CVE-2020-14323

Regards,
Salvatore

Bug#973398: samba: CVE-2020-14383

[Salvatore Bonaccorso]

Source: samba
Version: 2:4.12.5+dfsg-3
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 
Control: found -1 2:4.9.5+dfsg-5+deb10u1
Control: found -1 2:4.9.5+dfsg-5

Hi,

The following vulnerability was published for samba.

CVE-2020-14383[0]:
| An authenticated user can crash the DCE/RPC DNS with easily crafted
| records

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2020-14383
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-14383
[1] https://www.samba.org/samba/security/CVE-2020-14383.html

Regards,
Salvatore

Bug#924303: [Pkg-fonts-devel] Bug#924303: fonts-noto-core: creates an obsolete config file

[Laurent Bonnaud]

On 10/29/20 4:30 PM, Jonas Smedegaard wrote:


Please elaborate: What_is_  the issue?


It is my understanding that packages should not create obsolete conffiles.  
That's what I understood when reading this:

https://raphaelhertzog.com/2010/10/07/the-right-way-to-remove-an-obsolete-conffile-in-a-debian-package/

Thanks,

--
Laurent.

Bug#913211: RFP: python-rt -- access Request Tracker API from python

[Birger Schacht]

Package: wnpp
Followup-For: Bug #913211
Owner: Birger Schacht 
X-Debbugs-Cc: bir...@debian.org

Control: retitle -1 ITP: python-rt -- access Request Tracker API from python

Bug#973378: cryptsetup-udeb: Cannot create '--type plain' device; "device-mapper: table: 253:0: crypt: Error allocating crypto tfm"

[Guilhem Moulin]

Control: retitle -1 crypto-modules-*-di lacks 'essiv' module (required for old 
default cipher aes-cbc-essiv:sha256)
Control: reassign -1 src:linux

Hi Nathan,

On Thu, 29 Oct 2020 at 13:17:54 -0500, Nathan Schulte wrote:
> Using cryptsetup to securely wipe a device before enabling encryption, e.g.:
> 
>  cryptsetup --key-file /dev/random open --type plain /path/to/device container

I hope this is not all the entire “secure wipe” operation, because
AFAICT this command doesn't perform any writes to the underlying device
let alone wipe it.  One would need to fill /dev/mapper/container in
order to wipe it in a way that's indistinguishable from random, but it's
not clear to me what's the advantage over simply using `dd
if=/dev/urandom of=/path/to/device` (once urandom has been properly
seeded).

> fails on my system during install, using the latest weekly snapshot of Debian 
> testing.
> Some messages are logged to the terminal and some are logged by the kernel:
 
Next time please provide --debug output, and maybe also /proc/modules
content.

cryptsetup(8) defaults to aes-cbc-essiv:sha256 in ‘plain’ dm-crypt mode,
which AFAICT (cf. #948593) requires the ‘essiv’ kernel module.  This
module currently missing from crypto-modules, so aes-cbc-essiv:sha256
isn't usable from d-i.

The installer doesn't have that problem since it explicitly sets aes-xts-plain64
also in ‘plain’ dm-crypt mode.  Unless you're really attached to ESSIV
you could pass `--cipher aes-xts-plain64` as a workaround.

But I'm reassigning this to src:linux as aes-cbc-essiv:sha256 used to be
the default cipher some years ago so devices created before 2013 might
no longer be accessible from d-i.

Cheers,
-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#973397: Ensure /etc/rsyncd.conf is copied into the package. Allow "systemctl start rsync" to run

[Eugene Losowski-Gallagher]

Package: rsync
Version: 3.1.3-6
Severity: wishlist
Tags: newcomer

{code:diff}
diff --git a/debian/rules-pre-dh b/debian/rules-pre-dh
index 01db177..b8ef76f 100755
--- a/debian/rules-pre-dh
+++ b/debian/rules-pre-dh
@@ -108,6 +108,7 @@ endif
$(INSTALL_SCRIPT) debian/postrm   debian/tmp/DEBIAN/
$(INSTALL_FILE) debian/buildtree/packaging/systemd/rsync.service
debian/tmp/lib/systemd/system/
$(INSTALL_FILE) debian/default  debian/tmp/etc/default/rsync
+   $(INSTALL_FILE) debian/rsyncd.conf  debian/tmp/etc/rsyncd.conf
$(INSTALL_SCRIPT) debian/init.d debian/tmp/etc/init.d/rsync
$(INSTALL_FILE) debian/lintian.overrides
debian/tmp/usr/share/lintian/overrides/rsync
(cd debian/tmp; find ./etc -type f | LC_ALL=C sort | sed s,.,,) >
debian/tmp/DEBIAN/conffiles
{code}



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

Kernel: Linux 4.19.0-9-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
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 /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages rsync depends on:
ii  base-files   10.3+deb10u6
ii  init-system-helpers  1.56+nmu1
ii  libacl1  2.2.53-4
ii  libattr1 1:2.4.48-4
ii  libc62.28-10
ii  libpopt0 1.16-12
ii  lsb-base 10.2019051400

rsync recommends no packages.

Versions of packages rsync suggests:
ii  openssh-client  1:7.9p1-10+deb10u2
ii  openssh-server  1:7.9p1-10+deb10u2

-- no debconf information

Bug#419523: RFH: libreoffice -- office productivity suite

[Laurin Hagemann]

On Thu, 26 Apr 2018 14:15:34 + eamanu15  wrote:
> If help is no longer needed, please close this thread

Is help still needed/appreciated?

-- 
/Laurin

-BEGIN PGP PUBLIC KEY BLOCK-

mQINBFiM64ABEAC1oAm0/aU+T+Tb4f5q9KALm/UfaZ34dmgXY3QcU3lF34MEpATC
JxRmiLJoQiBvLyDPpHEuQcAArUrMEImySQOWcst9S1TKlIE51CXNpvCXkA2RQ7BU
mV+UnRbMqndSXo5qkawgb2ogrppeztxvFjL6jkFHp+rnTqV5RvXRLZwOH2dnkDwz
0DP0J01tECFJo+wRaj/rDnaVlLrTEi+58isVv0HDf6JEiD9wp7U59VKqgeJWezUb
YKWbjn7s1KTNw7NG3SDDniwOAw8HCtV86Z4L6sfHUtX9CIn9S/ykLsXXCkbVlCd/
15VcPweblCtC+spXKcL2wY+80Y6QG+wW9Mg1Kd7ifi2sCM7o561hjPAd/nEQXqo5
8pUohCyAfySdTTwlV+rjIpGOARbZfIknCX1938P2ZnWU9QEBRVc2SdPNewJOMBHl
lHp7yUX1GZFXgzHiGhuo9fRyFLvMhDRYKduBpDrPLeuvGKpmbVdw60jjRQKYzluk
bUqnAfQ4k3K83ZxuDQMoNVw6XZqXSu86wGPcC6nGtTpAY56bCmZXVjgVJ5Adu8lT
vqhF2xxh0ikhzRXIO31sQDs19IJSduJD90UjAUe7B3di1FDspUvz/zH2c+OLNrVH
HoejAa2E8iU7dEvzlka0wiNT53mLeFW6OYrkrEoJkdo7tSRLZmb/Zmgp2wARAQAB
tChMYXVyaW4gSGFnZW1hbm4gKHByaXYpIDxsYXVyaW5oZ0BnbXguZGU+iQJVBBMB
CgA/AhsDBgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgBYhBNTe458o1Pr66+mJyJMF
9xHAQy4EBQJdimC0BQkIv9w0AAoJEJMF9xHAQy4Ed1UP/0gHxxM6LFDv87OaMvf3
dU0BlVAzGtS9B5icNmaEo+4avTywyEl/G//UL134bll9lQBkxzQeQheINxJ4MRTM
f/9lkigZA0pmY5VS29x9hidO6N8YfvDomYwzan6oZb+/8lgDru749zIGRbvGs/WT
IE8vrGP65/MEPbQ0Ok+57JYHh0DhOLGGVEO9eJE3QWsVyHiPXjaNILkDeOxHjK+u
wfyqx5VVDNtKqTbNsUCTu0M8g/jtwWbBl/EvhvzbkHrbEnL/7Yz421wN1gCreYZL
e3mEh/3aHo/TKqm8rG1EeLoD6PQbNVJQj0/wVUzwRS85R2us4ozy13G79AbS27qe
hEUc+4UJeN45h4LXTXzHrI/zQ3Ge14QhfeF+g0OMMC8F/yU9Mx8vGbR8p+6K3Z+L
mShIy6v8Vxg4HgM3gEkoQM8zRhSsjQrBzeuy1XZWsFRUuNmHylAW/oRCfKECg9jr
ZrDOUHxqunarGPGQp4LXfQiMnN3PrKoxHo0Cs1qT/j7J6qxjal9N5F4IwsRPbRAb
Of1j06IUi5e86+3oK2/27sjBS286TPTuuKr0RHU9iOJWHzsgKvCnyZfi1gHlluxI
OqMBvAu1Zs8NcWS6nvSkcIQLUwKiqEQMR3ePZmAP16dtZAV32/2alXQgD121uSZ0
00To44F8DrNB8Zx78bQ63reuuQINBFiM64ABEADzLYr10BFIdqpeiw21IPLXbChz
RfIxEV3xq4UlwtIdAoSTtQOm0AHfiweSJb1PeRMV9LAmu8UJZbhbLnZvDU4p/ecv
XN3dkrxhde9GqQZDij6WdYb2ZDtQG1uk4f1BrOACojP0KxgOEsRS5a8GRnl5GZXJ
gJb3+kpiM0o5OUockxtuSgH8eQimlkPlVDjTs92wQs0ZQgM8xdu0H7pQy36u9/wi
bhMQXWXHaUWmjQDnenRc8QFi3kNUsrzIRiKLgjWqHHGmKCce+FWvm7OQg32f/1r4
n6OViIZwCevjCrsTGv/WcxP6vev2upk8G6nOpucIt4XnUPTnMEE7hXRSE4lasUtG
kWaMATxheKk5su3+PzmsquG7tn5tgvikMZ0Ft0iTkWFez3IS1FA55+H4AW2zIl04
RkX6yhjRpud1mUwjFCBXU65g5BmVsyTuCMG5QhzkuiA9Sj9rYAQgqQITXVzRYxD7
eGhWJX6XtYOlUUKMOx32KMTLATqdkb59XdQ5/23gw6n/6GAlAgyu3fLNTYFwr60L
rRPcwtqwZENO7Bgm79lI6Ibn+oFrXY3C8UIbB7gJzLqbXgTzzGjDwM97+nWLc+B9
eGCu2C1UGXAuGfaZbpnYTF4vgoNzXeI0UpnQMmFmZgIuJRxZ9YJcZRsTVp0xc6SB
gQ20KoSWQKQvigE9HQARAQABiQI8BBgBAgAmAhsMFiEE1N7jnyjU+vrr6YnIkwX3
EcBDLgQFAl1cI0wFCQW8hcwACgkQkwX3EcBDLgRgGA/+Lz4ahjcNlpoQLZH/LVAE
y6lEj50YuVnWlVy2+08IsXEWtQFC+OCf1yahxynUQFg9EUJGkwGVkp6pOhQJhkYj
fDETv0T7CdKAY2qIKkIaJFFTORlDLpBtBB3bdYxZ9DlU4Yfv4Nsbs2RrHXZPp7x1
6dpoI3Yf9XG1CodhN6ez1X/BuiKeKFURb/pb6XhfSCGuSqgPoFmDMYDyJI2Qa+h2
cTaQVnBXoWHlC269u5kfiE1OLNjbhZs2tgx4sGjARI3eL1uj48A3lcGZpD05TZtx
Q6E57+hcd+IFh6In8ai8EarMv3jbx1lIY/qNvf9IwrLxIyCm5iVglbDOzsvMTDbo
dwkjaWil8Gj5GHtFPNHRLynqHgWCcPHPqzQ0GjGQ4IRitqS7Ysmd7GAQBnrdTWOX
HL1O3K9qNndFXYbCUTxy3rDTptm5eZ9iK1GyBP4m0M4tDIwmWxLySL71XMCpiJsj
5MM+2IfVVFu9th3RTAFFvdq+kDp95MXAxoBfKG+fvzUP6g2++5eiwBZaviA5+kBr
iFn6mHi1ul96Jm9auUd2QJvirWk5yxEaczwpWZBW7byyo4dIOeKzi4mwtpFCfWWl
T3BMYHPN0JY9KxJiVAviUFmCqseQuSYP+/wvnslGrFYotEDUS5g5gIApdut9xOKm
CYjPkDA2K1CR/XA27Y87NWg=
=lXQM
-END PGP PUBLIC KEY BLOCK-


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

Bug#973396: ITP: volume-el -- tweak your sound card volume from Emacs

[Sean Whitton]

Package: wnpp
Severity: wishlist
Owner: Sean Whitton 

* Package name: volume-el
  Version : 1.0+git.20201002.afb75a5
  Upstream Author : Daniel Brockman 
* URL : https://github.com/dbrock/volume.el
* License : GPL-2+
  Programming Lang: Emacs Lisp
  Description : tweak your sound card volume from Emacs

Companion to bongo, another ITP of mine.

I intend to maintain under pkg-emacsen.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#248397: Contributions

[Laurin Hagemann]

On Sat, 14 Feb 2015 13:01:37 -0500 Richard Winters  wrote:
> Hello,
> Is help still requested for this package?
^same question.

-- 
/Laurin

-BEGIN PGP PUBLIC KEY BLOCK-

mQINBFiM64ABEAC1oAm0/aU+T+Tb4f5q9KALm/UfaZ34dmgXY3QcU3lF34MEpATC
JxRmiLJoQiBvLyDPpHEuQcAArUrMEImySQOWcst9S1TKlIE51CXNpvCXkA2RQ7BU
mV+UnRbMqndSXo5qkawgb2ogrppeztxvFjL6jkFHp+rnTqV5RvXRLZwOH2dnkDwz
0DP0J01tECFJo+wRaj/rDnaVlLrTEi+58isVv0HDf6JEiD9wp7U59VKqgeJWezUb
YKWbjn7s1KTNw7NG3SDDniwOAw8HCtV86Z4L6sfHUtX9CIn9S/ykLsXXCkbVlCd/
15VcPweblCtC+spXKcL2wY+80Y6QG+wW9Mg1Kd7ifi2sCM7o561hjPAd/nEQXqo5
8pUohCyAfySdTTwlV+rjIpGOARbZfIknCX1938P2ZnWU9QEBRVc2SdPNewJOMBHl
lHp7yUX1GZFXgzHiGhuo9fRyFLvMhDRYKduBpDrPLeuvGKpmbVdw60jjRQKYzluk
bUqnAfQ4k3K83ZxuDQMoNVw6XZqXSu86wGPcC6nGtTpAY56bCmZXVjgVJ5Adu8lT
vqhF2xxh0ikhzRXIO31sQDs19IJSduJD90UjAUe7B3di1FDspUvz/zH2c+OLNrVH
HoejAa2E8iU7dEvzlka0wiNT53mLeFW6OYrkrEoJkdo7tSRLZmb/Zmgp2wARAQAB
tChMYXVyaW4gSGFnZW1hbm4gKHByaXYpIDxsYXVyaW5oZ0BnbXguZGU+iQJVBBMB
CgA/AhsDBgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgBYhBNTe458o1Pr66+mJyJMF
9xHAQy4EBQJdimC0BQkIv9w0AAoJEJMF9xHAQy4Ed1UP/0gHxxM6LFDv87OaMvf3
dU0BlVAzGtS9B5icNmaEo+4avTywyEl/G//UL134bll9lQBkxzQeQheINxJ4MRTM
f/9lkigZA0pmY5VS29x9hidO6N8YfvDomYwzan6oZb+/8lgDru749zIGRbvGs/WT
IE8vrGP65/MEPbQ0Ok+57JYHh0DhOLGGVEO9eJE3QWsVyHiPXjaNILkDeOxHjK+u
wfyqx5VVDNtKqTbNsUCTu0M8g/jtwWbBl/EvhvzbkHrbEnL/7Yz421wN1gCreYZL
e3mEh/3aHo/TKqm8rG1EeLoD6PQbNVJQj0/wVUzwRS85R2us4ozy13G79AbS27qe
hEUc+4UJeN45h4LXTXzHrI/zQ3Ge14QhfeF+g0OMMC8F/yU9Mx8vGbR8p+6K3Z+L
mShIy6v8Vxg4HgM3gEkoQM8zRhSsjQrBzeuy1XZWsFRUuNmHylAW/oRCfKECg9jr
ZrDOUHxqunarGPGQp4LXfQiMnN3PrKoxHo0Cs1qT/j7J6qxjal9N5F4IwsRPbRAb
Of1j06IUi5e86+3oK2/27sjBS286TPTuuKr0RHU9iOJWHzsgKvCnyZfi1gHlluxI
OqMBvAu1Zs8NcWS6nvSkcIQLUwKiqEQMR3ePZmAP16dtZAV32/2alXQgD121uSZ0
00To44F8DrNB8Zx78bQ63reuuQINBFiM64ABEADzLYr10BFIdqpeiw21IPLXbChz
RfIxEV3xq4UlwtIdAoSTtQOm0AHfiweSJb1PeRMV9LAmu8UJZbhbLnZvDU4p/ecv
XN3dkrxhde9GqQZDij6WdYb2ZDtQG1uk4f1BrOACojP0KxgOEsRS5a8GRnl5GZXJ
gJb3+kpiM0o5OUockxtuSgH8eQimlkPlVDjTs92wQs0ZQgM8xdu0H7pQy36u9/wi
bhMQXWXHaUWmjQDnenRc8QFi3kNUsrzIRiKLgjWqHHGmKCce+FWvm7OQg32f/1r4
n6OViIZwCevjCrsTGv/WcxP6vev2upk8G6nOpucIt4XnUPTnMEE7hXRSE4lasUtG
kWaMATxheKk5su3+PzmsquG7tn5tgvikMZ0Ft0iTkWFez3IS1FA55+H4AW2zIl04
RkX6yhjRpud1mUwjFCBXU65g5BmVsyTuCMG5QhzkuiA9Sj9rYAQgqQITXVzRYxD7
eGhWJX6XtYOlUUKMOx32KMTLATqdkb59XdQ5/23gw6n/6GAlAgyu3fLNTYFwr60L
rRPcwtqwZENO7Bgm79lI6Ibn+oFrXY3C8UIbB7gJzLqbXgTzzGjDwM97+nWLc+B9
eGCu2C1UGXAuGfaZbpnYTF4vgoNzXeI0UpnQMmFmZgIuJRxZ9YJcZRsTVp0xc6SB
gQ20KoSWQKQvigE9HQARAQABiQI8BBgBAgAmAhsMFiEE1N7jnyjU+vrr6YnIkwX3
EcBDLgQFAl1cI0wFCQW8hcwACgkQkwX3EcBDLgRgGA/+Lz4ahjcNlpoQLZH/LVAE
y6lEj50YuVnWlVy2+08IsXEWtQFC+OCf1yahxynUQFg9EUJGkwGVkp6pOhQJhkYj
fDETv0T7CdKAY2qIKkIaJFFTORlDLpBtBB3bdYxZ9DlU4Yfv4Nsbs2RrHXZPp7x1
6dpoI3Yf9XG1CodhN6ez1X/BuiKeKFURb/pb6XhfSCGuSqgPoFmDMYDyJI2Qa+h2
cTaQVnBXoWHlC269u5kfiE1OLNjbhZs2tgx4sGjARI3eL1uj48A3lcGZpD05TZtx
Q6E57+hcd+IFh6In8ai8EarMv3jbx1lIY/qNvf9IwrLxIyCm5iVglbDOzsvMTDbo
dwkjaWil8Gj5GHtFPNHRLynqHgWCcPHPqzQ0GjGQ4IRitqS7Ysmd7GAQBnrdTWOX
HL1O3K9qNndFXYbCUTxy3rDTptm5eZ9iK1GyBP4m0M4tDIwmWxLySL71XMCpiJsj
5MM+2IfVVFu9th3RTAFFvdq+kDp95MXAxoBfKG+fvzUP6g2++5eiwBZaviA5+kBr
iFn6mHi1ul96Jm9auUd2QJvirWk5yxEaczwpWZBW7byyo4dIOeKzi4mwtpFCfWWl
T3BMYHPN0JY9KxJiVAviUFmCqseQuSYP+/wvnslGrFYotEDUS5g5gIApdut9xOKm
CYjPkDA2K1CR/XA27Y87NWg=
=lXQM
-END PGP PUBLIC KEY BLOCK-


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

Bug#860116: [Pkg-rust-maintainers] Bug#860116: RFH: cargo -- Rust package manager

[Laurin Hagemann]

This is still listed as RFH - is there still help required/appreciated?
I like the rust eco-system and would like to contribute here. 

-- 
/Laurin

-BEGIN PGP PUBLIC KEY BLOCK-

mQINBFiM64ABEAC1oAm0/aU+T+Tb4f5q9KALm/UfaZ34dmgXY3QcU3lF34MEpATC
JxRmiLJoQiBvLyDPpHEuQcAArUrMEImySQOWcst9S1TKlIE51CXNpvCXkA2RQ7BU
mV+UnRbMqndSXo5qkawgb2ogrppeztxvFjL6jkFHp+rnTqV5RvXRLZwOH2dnkDwz
0DP0J01tECFJo+wRaj/rDnaVlLrTEi+58isVv0HDf6JEiD9wp7U59VKqgeJWezUb
YKWbjn7s1KTNw7NG3SDDniwOAw8HCtV86Z4L6sfHUtX9CIn9S/ykLsXXCkbVlCd/
15VcPweblCtC+spXKcL2wY+80Y6QG+wW9Mg1Kd7ifi2sCM7o561hjPAd/nEQXqo5
8pUohCyAfySdTTwlV+rjIpGOARbZfIknCX1938P2ZnWU9QEBRVc2SdPNewJOMBHl
lHp7yUX1GZFXgzHiGhuo9fRyFLvMhDRYKduBpDrPLeuvGKpmbVdw60jjRQKYzluk
bUqnAfQ4k3K83ZxuDQMoNVw6XZqXSu86wGPcC6nGtTpAY56bCmZXVjgVJ5Adu8lT
vqhF2xxh0ikhzRXIO31sQDs19IJSduJD90UjAUe7B3di1FDspUvz/zH2c+OLNrVH
HoejAa2E8iU7dEvzlka0wiNT53mLeFW6OYrkrEoJkdo7tSRLZmb/Zmgp2wARAQAB
tChMYXVyaW4gSGFnZW1hbm4gKHByaXYpIDxsYXVyaW5oZ0BnbXguZGU+iQJVBBMB
CgA/AhsDBgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgBYhBNTe458o1Pr66+mJyJMF
9xHAQy4EBQJdimC0BQkIv9w0AAoJEJMF9xHAQy4Ed1UP/0gHxxM6LFDv87OaMvf3
dU0BlVAzGtS9B5icNmaEo+4avTywyEl/G//UL134bll9lQBkxzQeQheINxJ4MRTM
f/9lkigZA0pmY5VS29x9hidO6N8YfvDomYwzan6oZb+/8lgDru749zIGRbvGs/WT
IE8vrGP65/MEPbQ0Ok+57JYHh0DhOLGGVEO9eJE3QWsVyHiPXjaNILkDeOxHjK+u
wfyqx5VVDNtKqTbNsUCTu0M8g/jtwWbBl/EvhvzbkHrbEnL/7Yz421wN1gCreYZL
e3mEh/3aHo/TKqm8rG1EeLoD6PQbNVJQj0/wVUzwRS85R2us4ozy13G79AbS27qe
hEUc+4UJeN45h4LXTXzHrI/zQ3Ge14QhfeF+g0OMMC8F/yU9Mx8vGbR8p+6K3Z+L
mShIy6v8Vxg4HgM3gEkoQM8zRhSsjQrBzeuy1XZWsFRUuNmHylAW/oRCfKECg9jr
ZrDOUHxqunarGPGQp4LXfQiMnN3PrKoxHo0Cs1qT/j7J6qxjal9N5F4IwsRPbRAb
Of1j06IUi5e86+3oK2/27sjBS286TPTuuKr0RHU9iOJWHzsgKvCnyZfi1gHlluxI
OqMBvAu1Zs8NcWS6nvSkcIQLUwKiqEQMR3ePZmAP16dtZAV32/2alXQgD121uSZ0
00To44F8DrNB8Zx78bQ63reuuQINBFiM64ABEADzLYr10BFIdqpeiw21IPLXbChz
RfIxEV3xq4UlwtIdAoSTtQOm0AHfiweSJb1PeRMV9LAmu8UJZbhbLnZvDU4p/ecv
XN3dkrxhde9GqQZDij6WdYb2ZDtQG1uk4f1BrOACojP0KxgOEsRS5a8GRnl5GZXJ
gJb3+kpiM0o5OUockxtuSgH8eQimlkPlVDjTs92wQs0ZQgM8xdu0H7pQy36u9/wi
bhMQXWXHaUWmjQDnenRc8QFi3kNUsrzIRiKLgjWqHHGmKCce+FWvm7OQg32f/1r4
n6OViIZwCevjCrsTGv/WcxP6vev2upk8G6nOpucIt4XnUPTnMEE7hXRSE4lasUtG
kWaMATxheKk5su3+PzmsquG7tn5tgvikMZ0Ft0iTkWFez3IS1FA55+H4AW2zIl04
RkX6yhjRpud1mUwjFCBXU65g5BmVsyTuCMG5QhzkuiA9Sj9rYAQgqQITXVzRYxD7
eGhWJX6XtYOlUUKMOx32KMTLATqdkb59XdQ5/23gw6n/6GAlAgyu3fLNTYFwr60L
rRPcwtqwZENO7Bgm79lI6Ibn+oFrXY3C8UIbB7gJzLqbXgTzzGjDwM97+nWLc+B9
eGCu2C1UGXAuGfaZbpnYTF4vgoNzXeI0UpnQMmFmZgIuJRxZ9YJcZRsTVp0xc6SB
gQ20KoSWQKQvigE9HQARAQABiQI8BBgBAgAmAhsMFiEE1N7jnyjU+vrr6YnIkwX3
EcBDLgQFAl1cI0wFCQW8hcwACgkQkwX3EcBDLgRgGA/+Lz4ahjcNlpoQLZH/LVAE
y6lEj50YuVnWlVy2+08IsXEWtQFC+OCf1yahxynUQFg9EUJGkwGVkp6pOhQJhkYj
fDETv0T7CdKAY2qIKkIaJFFTORlDLpBtBB3bdYxZ9DlU4Yfv4Nsbs2RrHXZPp7x1
6dpoI3Yf9XG1CodhN6ez1X/BuiKeKFURb/pb6XhfSCGuSqgPoFmDMYDyJI2Qa+h2
cTaQVnBXoWHlC269u5kfiE1OLNjbhZs2tgx4sGjARI3eL1uj48A3lcGZpD05TZtx
Q6E57+hcd+IFh6In8ai8EarMv3jbx1lIY/qNvf9IwrLxIyCm5iVglbDOzsvMTDbo
dwkjaWil8Gj5GHtFPNHRLynqHgWCcPHPqzQ0GjGQ4IRitqS7Ysmd7GAQBnrdTWOX
HL1O3K9qNndFXYbCUTxy3rDTptm5eZ9iK1GyBP4m0M4tDIwmWxLySL71XMCpiJsj
5MM+2IfVVFu9th3RTAFFvdq+kDp95MXAxoBfKG+fvzUP6g2++5eiwBZaviA5+kBr
iFn6mHi1ul96Jm9auUd2QJvirWk5yxEaczwpWZBW7byyo4dIOeKzi4mwtpFCfWWl
T3BMYHPN0JY9KxJiVAviUFmCqseQuSYP+/wvnslGrFYotEDUS5g5gIApdut9xOKm
CYjPkDA2K1CR/XA27Y87NWg=
=lXQM
-END PGP PUBLIC KEY BLOCK-


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

Bug#973389: stress-ng FTCBFS: rebuilds stress-ng.c with the wrong compiler during make install

[Colin Ian King]

On 29/10/2020 16:48, Helmut Grohne wrote:
> Source: stress-ng
> Version: 0.11.22-1
> Tags: patch upstream
> User: debian-cr...@lists.debian.org
> Usertags: ftcbfs
> 
> stress-ng fails to cross build from source. The build step actually
> succeeds, but it also touches stress-ng.c, so that file gets rebuilt
> during make install. Unfortunately, dh_auto_install does not pass cross
> tools, so it uses the wrong compiler and fails. Please consider applying
> the attached patch to avoid this unnecessary rebuild. Once doing so,
> stress-ng cross builds successfully again.
> 
> Helmut
> 

Thanks for investigating this issue and sending a fix.  The commit is
applied to upstream repository:

https://kernel.ubuntu.com/git/cking/stress-ng.git/commit/?id=7cfebad15ff977813662cf1ea04d3e96b6cb7236

I'll get a new version of stress-ng uploaded in the next few days once
I've got it past all the regression tests.

Colin

Bug#973027: [Debichem-devel] Bug#973027: rdkit: FTBFS in unstable with postgresql 13

[Michael Banck]

Hi Steve,

On Thu, Oct 29, 2020 at 12:56:26PM -0700, Steve Langasek wrote:
> Package: rdkit
> Version: 202003.4-2
> Followup-For: Bug #973027
> User: ubuntu-de...@lists.ubuntu.com
> Usertags: origin-ubuntu hirsute ubuntu-patch
> 
> This bug has been tagged patch, and there is a PR linked from the upstream
> bug report, but no patch is attached to the bug.  The attached patch is what
> I have uploaded to Ubuntu to resolve this build failure.

Andrius has committed a similar patch to salsa two days ago:

https://salsa.debian.org/debichem-team/rdkit/-/commit/5994e329e094cf12c5b6be0a44b079e52f984843

However, his source-only upload was rejected due to the new pg13 binary
package.

Andrius, are you going to upload rdkit again? BTW, the changelog in
salsa still has UNRELEASED as distribution, are you going to update this
once the upload went through? Further, the bug isn't being closed in the
changelog.

Alternatively, we could revert those commits and sync from Ubuntu, I'm
leaving this to Andrius.


Michael

Bug#966671: coturn: unlimited number of /var/log/turn_*.log are created

[Jonas Smedegaard]

Package: coturn
Version: 4.5.1.3-1
Followup-For: Bug #966671

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

control: severity -1 minor

The package _permits_ the user to spew endless logfiles,
but by default rely on syslog, which by default rotates logfiles.

I see no bug here, but let's keep it at minor severity for now...

 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAl+bINIACgkQLHwxRsGg
ASEknQ//eAwFjY+FBxMKbhgrjzeoJ6ewOfeXUrgNJuAqF5f7xYadvEUq9XkgjVHL
yayjGvwZOy2ZugfOxzyuk7HS5LpZhxJwqMR7EeVUZBSSUX4EHevqgaw4A0j7lPoa
XW38C2c1AXXUKH6njSRz3jAlLhTgJSNPrQ/0DZJ1zmGS5hssCee+0DHTuzkTdaUT
ztMCex124B7ua59eEjDwKbfYhmRclCLFkkxU6sEoV2nxpx5k9wflGJK4By9IGwnP
uw3toKRoeyqFKh1AK0AdtAk192ZJuPqyZUWUsXR6NAqYu8Gn290Q+0/BuWCeZGN1
tfIHRnHTjszQqL9Ooq4rpoinA40OTgFIpV1cE9MeLTf6AAkT6Zbt6w81UMA7XKgi
JZBPL5s1U+rx5Rac5H3ugWNbKUsvwB5rpm2WVA2W+IYeJzAQyaluOFKDzZ869JNO
IPDzHqCUfWTCtPMZpnlOumaXRP4Q5W+5ZYSfFMANmd/W54f6dGMUL39VqNdfYTAS
pEKnj+pGH6Fx05jSfSK347dKVbTSyTcLsen1CUf21sERV8QgE9gHhGLwoJvpEnA4
SC6GZa7Dez5DPygwzWx9X8zdGt33tFAsXN1gOmkEvhkJCXcvnrnqknnvB2CgoytA
zID65t1h/Gc7oGXXVDZTqzaFdmujYbmTRMe8up4S97ETFzz6kaQ=
=gCo4
-END PGP SIGNATURE-

Bug#973362: Workaround

[Bálint Kovács]

Hi!

I have been afflicted by this issue too, and I have found a possible
workaround. If you boot into kernel 5.8.0-3, and run `dpkg-reconfigure
nvidia-kernel-dkms`, a usable kernel module is produced for that kenel.
Then, you can reboot or just `modprobe nvidia` and restart your X server.

Another "workaround" is upgrading to the nvidia driver packages at version
450.80.02-1, already included in sid. This implies that the bug has
thankfully been already fixed.

Bálint Kovács

Bug#973395: clang-10: Unable to package LLVM/Clang on Buster (for backports) - libffi error

[Maxime Lombard]

Package: clang-10
Version: 1:10.0.1-6
Severity: normal

Dear Maintainer,

I'm an user of Debian Buster and i tried to backport LLVM-10 from Testing to 
have the latest version of Mesa.
There are no issues when i package LLVM for AMD64 architecture, the problem 
appears only when i package for i386 arch.

To package LLVM for stable-backports, i use pbuilder and i use this command : 
"ARCH=i386 DIST=stable pdebuild" (i used the PbuilderTricks wiki)

I tried to do the same thing with LLVM-11 and same problem. Works with AMD64 
and crash with i386.

The error message in .build file is : 

[...]
CMake Error at cmake/config-ix.cmake:321 (message):
  libffi includes are not found.
Call Stack (most recent call first):
  CMakeLists.txt:655 (include)


-- Configuring incomplete, errors occurred!
See also 
"/build/llvm-toolchain-11-11.0.0/build-llvm/tools/clang/stage2-bins/CMakeFiles/CMakeOutput.log".
See also 
"/build/llvm-toolchain-11-11.0.0/build-llvm/tools/clang/stage2-bins/CMakeFiles/CMakeError.log".
make[5]: *** [tools/clang/CMakeFiles/stage2.dir/build.make:109: 
tools/clang/stage2-stamps/stage2-configure] Error 1
make[5]: Leaving directory '/build/llvm-toolchain-11-11.0.0/build-llvm'
make[4]: *** [CMakeFiles/Makefile2:50134: 
tools/clang/CMakeFiles/stage2.dir/all] Error 2
make[4]: Leaving directory '/build/llvm-toolchain-11-11.0.0/build-llvm'
make[3]: *** [CMakeFiles/Makefile2:50141: 
tools/clang/CMakeFiles/stage2.dir/rule] Error 2
make[3]: Leaving directory '/build/llvm-toolchain-11-11.0.0/build-llvm'
make[2]: *** [Makefile:14983: stage2] Error 2
make[2]: Leaving directory '/build/llvm-toolchain-11-11.0.0/build-llvm'
make[1]: *** [debian/rules:408: debian-full-build] Error 2
make[1]: Leaving directory '/build/llvm-toolchain-11-11.0.0'
make: *** [debian/rules:291: binary] Error 2
dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2
[...]

Obviously, libffi-dev package is installed at the beginning.
I tried to backports libffi too without success.

Thanks for your help,


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

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

Bug#973027: rdkit: FTBFS in unstable with postgresql 13

[Steve Langasek]

Package: rdkit
Version: 202003.4-2
Followup-For: Bug #973027
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu hirsute ubuntu-patch

This bug has been tagged patch, and there is a PR linked from the upstream
bug report, but no patch is attached to the bug.  The attached patch is what
I have uploaded to Ubuntu to resolve this build failure.

Cheers,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru rdkit-202003.4/debian/patches/postgresql-13-compat.patch 
rdkit-202003.4/debian/patches/postgresql-13-compat.patch
--- rdkit-202003.4/debian/patches/postgresql-13-compat.patch1969-12-31 
16:00:00.0 -0800
+++ rdkit-202003.4/debian/patches/postgresql-13-compat.patch2020-10-29 
11:44:36.0 -0700
@@ -0,0 +1,42 @@
+Author: Steve Langasek 
+Description: drop reference to obsolete header not shipped in Postgres 13
+ access/tuptoaster.h no longer exists and is also not needed, so drop
+ references to it.
+Last-Update: 2020-10-29
+
+Index: rdkit-202003.4/Code/PgSQL/rdkit/bfp_gist.c
+===
+--- rdkit-202003.4.orig/Code/PgSQL/rdkit/bfp_gist.c
 rdkit-202003.4/Code/PgSQL/rdkit/bfp_gist.c
+@@ -33,7 +33,6 @@
+ #include 
+ #include 
+ #include 
+-#include 
+ #include 
+ 
+ #include 
+Index: rdkit-202003.4/Code/PgSQL/rdkit/low_gist.c
+===
+--- rdkit-202003.4.orig/Code/PgSQL/rdkit/low_gist.c
 rdkit-202003.4/Code/PgSQL/rdkit/low_gist.c
+@@ -33,7 +33,6 @@
+ #include 
+ #include 
+ #include 
+-#include 
+ #include 
+ 
+ #include "rdkit.h"
+Index: rdkit-202003.4/Code/PgSQL/rdkit/rdkit_gist.c
+===
+--- rdkit-202003.4.orig/Code/PgSQL/rdkit/rdkit_gist.c
 rdkit-202003.4/Code/PgSQL/rdkit/rdkit_gist.c
+@@ -32,7 +32,6 @@
+ #include 
+ #include 
+ #include 
+-#include 
+ #include 
+ 
+ #include "rdkit.h"
diff -Nru rdkit-202003.4/debian/patches/series 
rdkit-202003.4/debian/patches/series
--- rdkit-202003.4/debian/patches/series2020-10-25 08:55:26.0 
-0700
+++ rdkit-202003.4/debian/patches/series2020-10-29 11:43:24.0 
-0700
@@ -6,3 +6,4 @@
 postgres_alternative_test_outputs.patch
 postgres_compile_fixes.patch
 sphinx_compile_fixes.patch
+postgresql-13-compat.patch

Bug#973394: please use flit to package fissix

[Louis-Philippe Véronneau]

Package: src:python-fissix
Version: 20.8.0-2
Severity: wishlist

Dear maintainer,

This package currently uses the tarball from PyPi instead of the one
from Github to circumvent `setup.py` not being present in the latter.

Sadly, as stated in d/README.source, this prevents running the testsuite
as an autokpgtest.

The Github tarball publishes a `pyproject.toml` file that uses `flit` as
a build-backend. It would thus be possible to solve this issue by using
`flit` as a pybuild system.

Here is an example of a package doing this:

https://salsa.debian.org/python-team/packages/python-mediafile

Cheers,

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

Bug#970357: fonts-adf-tribun: Inappropriate ligatures for ae and oe

[Mikko Rasa]

On 29.9.2020 11.49, Nathan Willis wrote:

Actually, don't mean to make assumptions — did you already try reaching out
to upstream? Worth a shot, IMO.


I hadn't before your message.  I did so shortly afterwards, but have yet 
to receive a response.  I need to get a publication using these fonts 
out the door very soon, so it's likely I'll have to edit the fonts 
myself.  I can contribute the edited files to Debian in the event the 
upstream proves unresponsive.


--
Mikko

Bug#973387: [Pkg-rust-maintainers] Bug#973387: does debian's libclang-dev support static linking?

[Sylvestre Ledru]

Hello,

Le 29/10/2020 à 20:39, peter green a écrit :
I was looking at an autopkgtest failure in rust-bindgen. The failure 
happened when when testing with the "static"

feature. It appears the failure was caused by a lack of libclang.a

We should disable this test in bindgen probably.


When looking at the file list of libclang-9-dev I noticed that there 
was no libclang.a but there were a number of
static libraries that looked like they may be parts of libclang.a. 
There did not seem to be a .pc file.


Can you clarify whether the debian libclang-dev package is supposed to 
support static linking and if-so how a

program should determine what libraries to link with?


Dunno :/

I have been focussing on shared libraries. Contributions to make 
libclang.a works properly are more than

welcome :)

S

Bug#973393: truncate less of the backtrace during failing ert tests

[Nicholas D Steeves]

Package: dh-elpa
Version: 2.0.4
Severity: normal

Hey team,

Thomas Koch added a nice workaround for truncated backtraces at:

  https://wiki.debian.org/Teams/DebianEmacsenTeam/Tips

that workaround is d/elpa-test:

  ert_eval = (setq ert-batch-backtrace-right-margin 500)

and I wonder if it should be activated by default, in the spirit of
Policy §4.9 "The package build should be as verbose as reasonably
possible".  Speaking for myself, I would find it helpful, especially
for the rare corner cases where only noninteractive --batch ert tests
will trigger a failure.  Also, I've been asked for untruncated
backtraces by various upstreams.

The only potential issue I can think of is that the reproducible and
DebCI build logs will have then have long lines, but I feel like the
benefit outweighs this consideration.  A possible, though not ideal,
solution to this potential issue might be to word-wrap the backtrace,
but that functionality should probably be enabled in upstream Emacs.

Let's consider setting `ert-batch-backtrace-right-margin` to a large
value in the meantime.

Regards,
Nicholas

Bug#973100: prometheus-postfix-exporter: FTBFS: src/github.com/alecthomas/kingpin/i18n_init.go:13:2: cannot find package "github.com/nicksnyder/go-i18n/i18n" in any of:

[Anthony Fok]

Dear all,

On Wed, Oct 28, 2020 at 12:18 PM Martina Ferrari  wrote:
>
> Hi!
>
> On 28/10/2020 15:06, Shengjing Zhu wrote:
> >> This bug is actually on the golang-github-nicksnyder-go-i18n-dev
> >> package. It seems the last upload brought a new API version, which
> >> changes import paths, and probably other API breaks. This should have
> >> been a new binary package and not an upgrade!
> >
> > The change in src:golang-github-nicksnyder-go-i18n could be reverted.
> > The v2 version is already packaged as a separated source
> > https://tracker.debian.org/pkg/golang-github-nicksnyder-go-i18n.v2
>
> I missed that there was already a v2 upload.. I really don't know what
> are the plans upstream, or whether this did more than changing the
> import path, but I think it would be good to upload some fix to the
> current situation.. In general, I think we should adopt a team policy
> regarding API breakages, similar to SONAME handling.

Sorry for the trouble caused by my upload of
golang-github-nicksnyder-go-i18n (2.1.1-1).
I thought no more package depends on golang-github-nicksnyder-go-i18n
v1 any longer,
with its sole reverse dependency golang-gopkg-alecthomas-kingpin.v3 no
longer needed
by any other package, and since golang-gopkg-alecthomas-kingpin.v3 is
essentially
abandoned upstream, I was planning to file a request to FTP masters to remove
golang-gopkg-alecthomas-kingpin.v3 from Debian altogether.

I did do a reverse dependency check, but somehow missed the fact that
prometheus-postfix-exporter still depended on
golang-gopkg-alecthomas-kingpin.v3-dev.
And of course, I totally missed the fact that
golang-github-nicksnyder-go-i18n.v2 already exists.

Anyhow, I am working on fixing the current situation, and here is the plan:

 1. Upload golang-gopkg-alecthomas-kingpin.v2 (2.2.6-2)
* Add github.com/alecthomas/kingpin to XS-Go-Import-Path
* debian/links: Add usr/share/gocode/src/github.com/alecthomas/kingpin
   as a symlink to usr/share/gocode/src/gopkg.in/alecthomas/kingpin.v2

 2. Change prometheus-postfix-exporter to build-depend on
 golang-gopkg-alecthomas-kingpin.v2-dev instead kingpin.v3
 as per https://github.com/kumina/postfix_exporter/blob/master/go.mod ,
 coincidentally fixing this FTBFS bug.

 3. Upload golang-gopkg-alecthomas-kingpin.v3 with the symlink
 usr/share/gocode/src/github.com/alecthomas/kingpin removed
 because it now belongs to golang-gopkg-alecthomas-kingpin.v2

 4. Upgrade golang-github-nicksnyder-go-i18n.v2 to 2.2.1,
 and merge my recent work on golang-github-nicksnyder-go-i18n to it.

 5. Change hugo to build-depend on golang-github-nicksnyder-go-i18n.v2

 6. Ask the FTP Masters to remove golang-gopkg-alecthomas-kingpin.v3
 and golang-github-nicksnyder-go-i18n from sid and testing
 as neither package would be used by any other packages once
 Steps 1 to 5 are completed.

Cheers,

Anthony Fok

Bug#929062: Updated and reworked log4cplus packaging

[Tobias Frost]

Control: tags -1 pending

Just uploaded to experimental to clear NEW and start the library transition.

-- 
tobi

Bug#973387: does debian's libclang-dev support static linking?

[peter green]

I was looking at an autopkgtest failure in rust-bindgen. The failure happened when when 
testing with the "static"
feature. It appears the failure was caused by a lack of libclang.a

When looking at the file list of libclang-9-dev I noticed that there was no 
libclang.a but there were a number of
static libraries that looked like they may be parts of libclang.a. There did 
not seem to be a .pc file.

Can you clarify whether the debian libclang-dev package is supposed to support 
static linking and if-so how a
program should determine what libraries to link with?

Bug#973389: stress-ng FTCBFS: rebuilds stress-ng.c with the wrong compiler during make install

[Helmut Grohne]

Source: stress-ng
Version: 0.11.22-1
Tags: patch upstream
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

stress-ng fails to cross build from source. The build step actually
succeeds, but it also touches stress-ng.c, so that file gets rebuilt
during make install. Unfortunately, dh_auto_install does not pass cross
tools, so it uses the wrong compiler and fails. Please consider applying
the attached patch to avoid this unnecessary rebuild. Once doing so,
stress-ng cross builds successfully again.

Helmut
--- stress-ng-0.11.22.orig/Makefile
+++ stress-ng-0.11.22/Makefile
@@ -424,7 +424,6 @@
 stress-vecmath.o: stress-vecmath.c
 	@echo CC $<
 	@$(CC) $(CFLAGS) -fno-builtin -c -o $@ $<
-	@touch stress-ng.c
 
 $(OBJS): stress-ng.h Makefile
 

Bug#973390: imgui FTCBFS: hard codes the build architecture pkg-config

[Helmut Grohne]

Source: imgui
Version: 1.79+ds-1
Tags: patch upstream
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

imgui fails to cross build from source, because the upstream Makefile
hard codes the build architecture pkg-config. Please consider applying
the attached patch to make pkg-config substitutable. dh_auto_build will
substitute the correct pkg-config and imgui becomes cross buildable
again.

Helmut
--- imgui-1.79+ds.orig/Makefile
+++ imgui-1.79+ds/Makefile
@@ -14,9 +14,10 @@
 CXXFLAGS += -fPIC
 
 LIBS := freetype2
-LIBS_CPPFLAGS := $(shell pkg-config --cflags-only-I $(LIBS))
-LIBS_CFLAGS := $(shell pkg-config --cflags-only-other $(LIBS))
-LIBS_LDFLAGS := $(shell pkg-config --libs $(LIBS))
+PKG_CONFIG ?= pkg-config
+LIBS_CPPFLAGS := $(shell $(PKG_CONFIG) --cflags-only-I $(LIBS))
+LIBS_CFLAGS := $(shell $(PKG_CONFIG) --cflags-only-other $(LIBS))
+LIBS_LDFLAGS := $(shell $(PKG_CONFIG) --libs $(LIBS))
 
 CPPFLAGS += $(LIBS_CPPFLAGS)
 CFLAGS += $(LIBS_CFLAGS)

Bug#973391: RM: python-ruamel.ordereddict -- ROM; Python2 removal

[Gianfranco Costamagna]

Package: ftp.debian.org
Severity: normal

Please let it go, looks like the upstream work [1] is stuck.


[1] https://sourceforge.net/p/ruamel-ordereddict/tickets/8/

Gianfranco

Bug#973388: mariadb-10.5 FTCBFS: missin Build-Depends: libssl-dev:native

[Helmut Grohne]

Source: mariadb-10.5
Version: 1:10.5.6-2
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

mariadb-10.5 fails to cross build from source, because it misses a build
dependency on the native libssl-dev. mariadb-10.5 needs to be built
natively before it can be cross built for building the
import_executables. While it doesn't actually need openssl for that, the
CMakeFiles.txt fail anyway when it goes missing. Thus the build fails. A
simple solution is adding libssl-dev:native to Build-Depends.

Helmut
diff --minimal -Nru mariadb-10.5-10.5.6/debian/changelog 
mariadb-10.5-10.5.6/debian/changelog
--- mariadb-10.5-10.5.6/debian/changelog2020-10-26 13:13:56.0 
+0100
+++ mariadb-10.5-10.5.6/debian/changelog2020-10-29 19:30:30.0 
+0100
@@ -1,3 +1,10 @@
+mariadb-10.5 (1:10.5.6-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Add native libssl-dev to Build-Depends. (Closes: #-1)
+
+ -- Helmut Grohne   Thu, 29 Oct 2020 19:30:30 +0100
+
 mariadb-10.5 (1:10.5.6-2) unstable; urgency=medium
 
   [ Miroslav Kure ]
diff --minimal -Nru mariadb-10.5-10.5.6/debian/control 
mariadb-10.5-10.5.6/debian/control
--- mariadb-10.5-10.5.6/debian/control  2020-10-26 13:13:56.0 +0100
+++ mariadb-10.5-10.5.6/debian/control  2020-10-29 19:30:29.0 +0100
@@ -29,6 +29,7 @@
libpcre2-dev,
libsnappy-dev,
libssl-dev,
+   libssl-dev:native,
libsystemd-dev [linux-any],
libxml2-dev,
libzstd-dev (>= 1.3.3),

Bug#973387: rust-bindgen: autopkg test failures for new featuresets.

[peter green]

Package: rust-bindgen
Version: 0.55.1-1
Severity: serious

rust-bindgen 0.55.1 introduced two new featuresets. The autopkgtests for these 
featuresets are failing
For the "runtime" feature we have.

>  test::commandline_multiple_headers stdout 
> bindgen tests/headers/16-byte-alignment.h --rust-target 1.40 
--no-derive-default --generate 
functions,types,vars,methods,constructors,destructors -- -include 
tests/headers/char.h -include tests/headers/func_ptr.h
> error: header 'tests/headers/16-byte-alignment.h' does not exist.
<--snip-->
> failures:
> test::commandline_multiple_headers
>
> test result: FAILED. 0 passed; 1 failed; 0 ignored; 0 measured; 0 filtered out
>
> error: test failed, to rerun pass '--bin bindgen'
> autopkgtest [16:17:20]: test librust-bindgen+runtime-dev: 
---]
> autopkgtest [16:17:20]: test librust-bindgen+runtime-dev:  - - - - - - - - - 
- results - - - - - - - - - -
> librust-bindgen+runtime-dev FAIL non-zero exit status 101
This failure looks similar to the failures for other featuresets where the 
tests are already marked as broken.
As such I think it makes sense to mark this one as broken too.

For the "static" feature we have.

> [clang-sys 1.0.1] thread 'main' panicked at 'could not find any static 
libraries', /tmp/tmp.DRdlTsehqq/registry/clang-sys-1.0.1/build/static.rs:96:9
<--snip-->
> error: build failed
> autopkgtest [16:17:33]: test librust-bindgen+static-dev: 
---]
> autopkgtest [16:17:33]: test librust-bindgen+static-dev:  - - - - - - - - - - 
results - - - - - - - - - -
> librust-bindgen+static-dev FAIL non-zero exit status 101

It appears to me that the failure is in the static feature of the clang-sys 
package. Unfortunately it
seems that the clang-sys autopkgtests do not test the static feature. The "all 
features" test is
marked as broken because "The `runtime` and `static` features can't be combined (see 
build.rs)"
and there does not seem to be a separate test for the "static" feature in the 
rust-clang-sys
autopkgtests.

It looks to me like the underlying reason for the failure is that debians 
libclang-9-dev package does
not appear to provide a libclang.a file. It does however provide a number of 
other .a files which look
like they may be bits of libclang. I don't see a .pc file in the libclang-9-dev 
package either. I'll send
a seperate mail to the llvm maintainers about that.

Bug#973386: /etc/nanorc contains malformed lines

[Benno Schulenberg]

Package: nano
Version: 5.2
Severity: minor

Hi,

Today I installed a Debian-derivative, and found the following
strange lines in the provided /etc/nanorc:

  # include "@PKGDATADIR@/html.nanorc"
  # include "@PKGDATADIR@/python.nanorc"
  # include "@PKGDATADIR@/sh.nanorc"

That "@PKGDATADIR@" shouldn't be there.  It looks like the file
'doc/sample.nanorc.in' instead of 'doc/sample.nanorc' has been
copied to /etc/.  There is a further malformed line:

  ## In @PKGDATADIR@/extra/ you can find some syntaxes that are

This is what those four lines from 'doc/sample.nanorc' look like:

  # include "/usr/share/nano/html.nanorc"
  # include "/usr/share/nano/python.nanorc"
  # include "/usr/share/nano/sh.nanorc"

  ## In /usr/share/nano/extra/ you can find some syntaxes that are


I've checked that a nano_5.3-1_amd64.deb downloaded from a Debian
mirror still contains those malformed lines in the included /etc/nanorc.

It would be nice if this would get fixed for the next iteration.

Benno



signature.asc
Description: OpenPGP digital signature

Bug#973384: CVE-2015-9284

[Moritz Muehlenhoff]

Package: ruby-omniauth
Severity: important
Tags: security
X-Debbugs-Cc: Debian Security Team 

Please see
https://github.com/omniauth/omniauth/pull/809
https://www.openwall.com/lists/oss-security/2015/05/26/11

Bug#973385: CVE-2020-27739 CVE-2020-27740 CVE-2020-27741 CVE-2020-27742

[Moritz Muehlenhoff]

Source: webcit
Severity: grave
Tags: security
X-Debbugs-Cc: Debian Security Team 

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-27739 
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-27740 
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-27741 
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-27742 

Bug#973367: lintian: example-wrong-path-for-interpreter false positive for tcsh

[Stephan Lachnit]

Package: lintian
Version: 2.99.0
Severity: normal

Hi,

Package: https://salsa.debian.org/stephanlachnit/geant4
File: examples/extended/medical/electronScattering2/run.csh
Shebang: `#!/bin/tcsh`
Lintian reports:  example-wrong-path-for-interpreter 
usr/share/doc/geant4/examples/extended/medical/electronScattering2/run.csh 
(#!/bin/tcsh != /usr/bin/tcsh)

However, I don't think that is correct. Looking at [1], for all architectures
`/bin/tcsh` exists, while only for [arm64, ia64, s390, sparc] there is
`/usr/bin/tcsh`.

Cheers,
Stephan

[1] 
https://packages.debian.org/search?searchon=contents=tcsh=exactfilename=unstable=any



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

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

Versions of packages lintian depends on:
ii  binutils2.35.1-2
ii  bzip2   1.0.8-4
ii  diffstat1.63-1
ii  dpkg1.20.5
ii  dpkg-dev1.20.5
ii  file1:5.38-5
ii  gettext 0.19.8.1-10
ii  gpg 2.2.20-1
ii  intltool-debian 0.35.0+20060710.5
ii  libapt-pkg-perl 0.1.36+b3
ii  libarchive-zip-perl 1.68-1
ii  libcapture-tiny-perl0.48-1
ii  libclass-xsaccessor-perl1.19-3+b5
ii  libclone-perl   0.45-1
ii  libconfig-tiny-perl 2.24-1
ii  libcpanel-json-xs-perl  4.24-1
ii  libdata-dpath-perl  0.58-1
ii  libdata-validate-domain-perl0.10-1
ii  libdevel-size-perl  0.83-1+b1
ii  libdpkg-perl1.20.5
ii  libemail-address-xs-perl1.04-1+b2
ii  libfile-basedir-perl0.08-1
ii  libfile-find-rule-perl  0.34-1
ii  libfont-ttf-perl1.06-1
ii  libhtml-html5-entities-perl 0.004-1
ii  libipc-run3-perl0.048-2
ii  libjson-maybexs-perl1.004002-1
ii  liblist-compare-perl0.55-1
ii  liblist-moreutils-perl  0.416-1+b5
ii  liblist-utilsby-perl0.11-1
ii  libmoo-perl 2.004000-1
ii  libmoox-aliases-perl0.001006-1
ii  libnamespace-clean-perl 0.27-1
ii  libpath-tiny-perl   0.114-1
ii  libperlio-gzip-perl 0.19-1+b6
ii  libproc-processtable-perl   0.59-2
ii  libsereal-decoder-perl  4.018+ds-1
ii  libsereal-encoder-perl  4.018+ds-1
ii  libtext-glob-perl   0.11-1
ii  libtext-levenshteinxs-perl  0.03-4+b7
ii  libtext-markdown-discount-perl  0.12-1
ii  libtext-xslate-perl 3.5.8-1
ii  libtime-duration-perl   1.21-1
ii  libtime-moment-perl 0.44-1+b2
ii  libtimedate-perl2.3300-1
ii  libtry-tiny-perl0.30-1
ii  libtype-tiny-perl   1.010006-1
ii  libunicode-utf8-perl0.62-1+b1
ii  liburi-perl 5.05-1
ii  libxml-libxml-perl  2.0134+dfsg-2
ii  libyaml-libyaml-perl0.82+repack-1
ii  lzip1.21-8
ii  lzop1.04-1
ii  man-db  2.9.3-2
ii  patchutils  0.4.2-1
ii  perl [libdigest-sha-perl]   5.30.3-4
ii  t1utils 1.41-4
ii  unzip   6.0-25
ii  xz-utils5.2.4-1+b1

lintian recommends no packages.

Versions of packages lintian suggests:
pn  binutils-multiarch 
ii  libtext-template-perl  1.59-1

-- no debconf information

Bug#973383: ITP: bongo -- buffer-based music player for GNU Emacs

[Sean Whitton]

Package: wnpp
Severity: wishlist
Owner: Sean Whitton 

* Package name: bongo
  Version : 1.1
  Upstream Author : Daniel Brockman 
* URL : https://github.com/dbrock/bongo
* License : GPL-2+
  Programming Lang: Emacs Lisp
  Description : buffer-based music player for GNU Emacs

This is a nice music player for Emacs.

I intend to maintain this under the pkg-emacsen team.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#973382: CVE-2020-18184 CVE-2020-18185

[Moritz Muehlenhoff]

Package: pluxml
Severity: grave
Tags: security
X-Debbugs-Cc: Debian Security Team 

CVE-2020-18185
https://github.com/pluxml/PluXml/issues/321

CVE-2020-18184
https://github.com/pluxml/PluXml/issues/320

Cheers,
Moritz

Bug#973381: CVE-2020-5421

[Moritz Muehlenhoff]

Source: libspring-java
Severity: important
Tags: security
X-Debbugs-Cc: Debian Security Team 

Please see https://tanzu.vmware.com/security/cve-2020-5421

Cheers,
Moritz

Bug#973050: needrestart: Use of uninitialized value in hex at /usr/share/perl5/NeedRestart/uCode/AMD.pm line 169

[Martin-Éric Racine]

[main] eval /etc/needrestart/needrestart.conf
[main] needrestart v3.5
[main] running in root mode
[Core] Using UI 'NeedRestart::UI::stdio'...
[main] systemd detected
[ucode] using NeedRestart::uCode::Intel
[ucode] using NeedRestart::uCode::AMD
[uCode/Intel] #0 current microcode revision not found in /proc/cpuinfo:
[uCode/AMD] #0 Failed to open /dev/cpu/0/cpuid (Missed `modprobe
cpuid`?): No such file or directory
[uCode/AMD] #0 cpuid 0x05a2  (/proc/cpuinfo)
Use of uninitialized value in hex at
/usr/share/perl5/NeedRestart/uCode/AMD.pm line 169.
[uCode/AMD] #0 running ucode 0x
[uCode/AMD] #0 no ucode updates available
The processor microcode seems to be up-to-date.

to 29. lokak. 2020 klo 20.30 Thomas Liske (tho...@fiasko-nw.net) kirjoitti:
>
> Hi,
>
> could you please provide the output of `needrestart -vw`?
>
>
> TIA & Regards,
> Thomas
>
>
> On 27.10.20 10:44, Martin-Éric Racine wrote:
>  > Package: needrestart
>  > Version: 3.5-1
>  > Severity: normal
>  >
> > Scanning processes...
> > Use of uninitialized value in hex at 
> > /usr/share/perl5/NeedRestart/uCode/AMD.pm line 169. 
> >]
> > Scanning processor microcode...
> > Scanning linux images...
> > Running kernel seems to be up-to-date.
> > The processor microcode seems to be up-to-date.
> > No services need to be restarted.
> > No containers need to be restarted.
> > No user sessions are running outdated binaries.
> >
> > This output appears on an AMD Geode LX800.
> >
> > -- Package-specific info:
> > needrestart output:
> >
> > checkrestart output:
> >
> >
> > -- System Information:
> > Debian Release: bullseye/sid
> >APT prefers testing-debug
> >APT policy: (1000, 'testing-debug'), (1000, 'testing'), (500, 'stable')
> > Architecture: i386 (i586)
> >
> > Kernel: Linux 5.9.0-1-686 (SMP w/1 CPU thread)
> > Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8), 
> > LANGUAGE=fi:en
> > Shell: /bin/sh linked to /bin/dash
> > Init: systemd (via /run/systemd/system)
> > LSM: AppArmor: enabled
> >
> > Versions of packages needrestart depends on:
> > ii  binutils   2.35.1-2
> > ii  dpkg   1.20.5
> > ii  gettext-base   0.19.8.1-10
> > ii  libintl-perl   1.26-2
> > ii  libmodule-find-perl0.15-1
> > ii  libmodule-scandeps-perl1.29-1
> > ii  libproc-processtable-perl  0.59-2
> > ii  libsort-naturally-perl 1.03-2
> > ii  libterm-readkey-perl   2.38-1+b1
> > ii  perl   5.30.3-4
> > ii  xz-utils   5.2.4-1+b1
> >
> > Versions of packages needrestart recommends:
> > ii  libpam-systemd  246.6-2
> >
> > Versions of packages needrestart suggests:
> > ii  iucode-tool  2.3.1-1
> > pn  needrestart-session | libnotify-bin  
> >
> > -- no debconf information
> >
>  >

Bug#973380: CVE-2020-6104 CVE-2020-6105 CVE-2020-6106 CVE-2020-6107 CVE-2020-6108

[Moritz Muehlenhoff]

Package: f2fs-tools
Severity: grave
Tags: security
X-Debbugs-Cc: Debian Security Team 

CVE-2020-6108
 https://talosintelligence.com/vulnerability_reports/TALOS-2020-1050

CVE-2020-6107
 https://talosintelligence.com/vulnerability_reports/TALOS-2020-1049
 
CVE-2020-6106
 https://talosintelligence.com/vulnerability_reports/TALOS-2020-1048
 
CVE-2020-6105
 https://talosintelligence.com/vulnerability_reports/TALOS-2020-1047
 
CVE-2020-6104
 https://talosintelligence.com/vulnerability_reports/TALOS-2020-1046
 
Cheers,
Moritz

Bug#971989: unblock: thunderbird/1:78.3.2-1

[Gregor Riepl]

>> I've pushed my work to https://salsa.debian.org/biebl/enigmail and
>> uploaded to DELAYED/14.
>>
> In the interest of getting thunderbird updated in bullseye, I've just
> gone ahead and rescheduled the NMU from 5-day to 0-day.

Thanks!

I just tested the published package from the perspective of a bullseye
install, and it looks good. The changelog message presented to users is
also good.

What I'm not so happy about is the fact that TB78 now stores PGP keys in
its keychain. There is still no libsecret support in TB and I'd rather
*not* use the TB keychain if it can be avoided. But that's out of scope
here, so please ignore my ramblings.

@biebl Do you have access to the main Salsa repo? It would be great if
you could merge back the changes from your fork.

Bug#973050: needrestart: Use of uninitialized value in hex at /usr/share/perl5/NeedRestart/uCode/AMD.pm line 169

[Thomas Liske]

Hi,

could you please provide the output of `needrestart -vw`?


TIA & Regards,
Thomas


On 27.10.20 10:44, Martin-Éric Racine wrote:
> Package: needrestart
> Version: 3.5-1
> Severity: normal
>

Scanning processes...
Use of uninitialized value in hex at /usr/share/perl5/NeedRestart/uCode/AMD.pm 
line 169.   
 ]
Scanning processor microcode...
Scanning linux images...
Running kernel seems to be up-to-date.
The processor microcode seems to be up-to-date.
No services need to be restarted.
No containers need to be restarted.
No user sessions are running outdated binaries.

This output appears on an AMD Geode LX800.

-- Package-specific info:
needrestart output:

checkrestart output:


-- System Information:
Debian Release: bullseye/sid
   APT prefers testing-debug
   APT policy: (1000, 'testing-debug'), (1000, 'testing'), (500, 'stable')
Architecture: i386 (i586)

Kernel: Linux 5.9.0-1-686 (SMP w/1 CPU thread)
Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8), LANGUAGE=fi:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages needrestart depends on:
ii  binutils   2.35.1-2
ii  dpkg   1.20.5
ii  gettext-base   0.19.8.1-10
ii  libintl-perl   1.26-2
ii  libmodule-find-perl0.15-1
ii  libmodule-scandeps-perl1.29-1
ii  libproc-processtable-perl  0.59-2
ii  libsort-naturally-perl 1.03-2
ii  libterm-readkey-perl   2.38-1+b1
ii  perl   5.30.3-4
ii  xz-utils   5.2.4-1+b1

Versions of packages needrestart recommends:
ii  libpam-systemd  246.6-2

Versions of packages needrestart suggests:
ii  iucode-tool  2.3.1-1
pn  needrestart-session | libnotify-bin  

-- no debconf information


>

Bug#972685: needrestart: Please add support for runit

[Thomas Liske]

Hi Lorenzo,


thanks for the updated patch. I've applied it upstream and will be part 
of needrestart 3.6+.



Regards,
Thomas



On 23.10.20 12:12, Lorenzo Puliti wrote:

Package: needrestart
Version: 3.5-1
Followup-For: Bug #972685


On 10/22/20 8:16 PM, Thomas Liske wrote:

Hi,

thanks for the patch. Would it possible that you provide a updated patch
  compatible with upstream's git HEAD?




Hi,

You should be able to git am the patch attached to this message.
Note that i've used 'service' instead of invoke-run, to be consistent
with upstream code, so this will need further work on Debian side,
updating and refreshing the quilt '01-use-invoke-rc.d.diff' patch.

Regards,
Lorenzo

Bug#332498: This bug report has been open for 12 years

[Laurin Hagemann]

On Fri, 24 Mar 2017 10:21:52 -0700 Dean Valentine 
wrote:
> This bug report has been open for 12 years
> 
> If you guys don’t need any more help you should close it or mark it as solved
> 
> I get that every project could use more people but if you don’t think that
this package is specifically and exceptionally in need of extra developers it
should probably be removed from the Developer’s corner “Packages for which help
was requested page"
> 

Is help here still needed/appreciated?
I've worked with openssl a lot in my day-job and would like to contribute.

/Laurin


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

Bug#973379: gimp: print dialog no labels on unselected tabs

[tom]

Package: gimp
Version: 2.10.8-2
Severity: minor

I opened the print dialog, and the upper tabs
had no labels. Only the one that is selected.
So, I have to select each one to see the label, 
until I find the one I want.



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

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

Versions of packages gimp depends on:
ii  gimp-data2.10.8-2
ii  libaa1   1.4p5-46
ii  libbabl-0.1-00.1.62-1
ii  libbz2-1.0   1.0.6-9.2~deb10u1
ii  libc62.28-10
ii  libcairo21.16.0-4
ii  libfontconfig1   2.13.1-2
ii  libfreetype6 2.9.1-3+deb10u2
ii  libgcc-s1 [libgcc1]  10.2.0-7
ii  libgcc1  1:8.3.0-6
ii  libgdk-pixbuf2.0-0   2.38.1+dfsg-1
ii  libgegl-0.4-00.4.12-2
ii  libgexiv2-2  0.10.9-1
ii  libgimp2.0   2.10.8-2
ii  libglib2.0-0 2.58.3-2+deb10u2
ii  libgs9   9.27~dfsg-2+deb10u4
ii  libgtk2.0-0  2.24.32-3
ii  libgudev-1.0-0   232-2
ii  libharfbuzz0b2.3.1-1
ii  libheif1 1.3.2-2~deb10u1
ii  libilmbase23 2.2.1-2
ii  libjpeg62-turbo  1:1.5.2-2+b1
ii  liblcms2-2   2.9-3
ii  liblzma5 5.2.4-1
ii  libmng1  1.0.10+dfsg-3.1+b5
ii  libmypaint-1.3-0 1.3.0-2.1
ii  libopenexr23 2.2.1-4.1+deb10u1
ii  libopenjp2-7 2.3.0-2+deb10u1
ii  libpango-1.0-0   1.42.4-8~deb10u1
ii  libpangocairo-1.0-0  1.42.4-8~deb10u1
ii  libpangoft2-1.0-01.42.4-8~deb10u1
ii  libpng16-16  1.6.36-6
ii  libpoppler-glib8 0.71.0-5
ii  librsvg2-2   2.44.10-2.1
ii  libstdc++6   10.2.0-7
ii  libtiff5 4.1.0+git191117-2~deb10u1
ii  libwebp6 0.6.1-2
ii  libwebpdemux20.6.1-2
ii  libwebpmux3  0.6.1-2
ii  libwmf0.2-7  0.2.8.4-14
ii  libx11-6 2:1.6.7-1+deb10u1
ii  libxcursor1  1:1.1.15-2
ii  libxext6 2:1.3.3-1+b2
ii  libxfixes3   1:5.0.3-1
ii  libxmu6  2:1.1.2-2+b3
ii  libxpm4  1:3.5.12-1
ii  xdg-utils1.1.3-1+deb10u1
ii  zlib1g   1:1.2.11.dfsg-1

Versions of packages gimp recommends:
ii  ghostscript  9.27~dfsg-2+deb10u4

Versions of packages gimp suggests:
ii  gimp-data-extras  1:2.0.2-1
ii  gimp-help-en [gimp-help]  2.8.2-1
ii  gimp-python   2.10.8-2
ii  gvfs-backends 1.38.1-5
ii  libasound21.1.8-1

-- no debconf information

Bug#973378: cryptsetup-udeb: Cannot create '--type plain' device; "device-mapper: table: 253:0: crypt: Error allocating crypto tfm"

[Nathan Schulte]

Source: cryptsetup-udeb
Severity: normal
Tags: d-i
X-Debbugs-Cc: guil...@debian.org

Using cryptsetup to securely wipe a device before enabling encryption, e.g.:

cryptsetup --key-file /dev/random open --type plain /path/to/device 
container

fails on my system during install, using the latest weekly snapshot of Debian 
testing.
Some messages are logged to the terminal and some are logged by the kernel:

device-mapper: reload ioctl on container (253:0) failed: No such file or 
directory

kernel: device-mapper: table: 253:0: crypt: Error allocating crypto tfm
kernel: device-mapper: ioctl: error adding target to table.

I am executing these commands at the partitioning step, after running these 
commands:

anna-install cdebconf-newt-entropy partman-crypto-dm cryptsetup-udeb 
crypto-dm-modules crypto-modules
insmod /lib/modules/$(uname -r)/kernel/drivers/md/dm-crypt.ko || insmod 
dm_crypt dm-crypt || modprobe dm_crypt dm-crypt
mkdir -p /run/cryptsetup

Using cryptsetup otherwise works fine, e.g. to format, open and close LUKS2 
devices.

Is there another package I should install or module I should load?  I tried 
inserting any crypto related module I could
find without success: cbc.ko, arch/*aes*.ko, aes_generic.ko, ...

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

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

Bug#973339: stlink FTCBFS: refuses to use gtk

[Luca Boccassi]

On Thu, 29 Oct 2020 06:04:31 +0100 Helmut Grohne  wrote:
> Source: stlink
> Version: 1.6.1+ds-2
> Tags: patch upstream
> User: debian-cr...@lists.debian.org
> Usertags: ftcbfs
> 
> stlink fails to cross build from source, because it insists that during
> cross builds gtk is unusable and thus it lacks components during
> dh_install. Once making it actually try using gtk, it cross builds just
> fine. Please consider applying the attached patch.
> 
> Helmut

Done. Could you please push it upstream?

-- 
Kind regards,
Luca Boccassi


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

Bug#972974: [Pkg-clamav-devel] Bug#972974: clamav-freshclam start faild.

[Michael Borgelt]

Success.
After adding 'capability dac_override' AND 'capability chown' to the  
/etc/apparmor.d/usr.bin.freshclam profile clamav-freshclam starts  
successfull.
To succsessfull start clamav-daemon you have to set 'capability chown'  
in '/etc/apparmor.d/usr.sbin.clamd' also.


Thank you
Michael.

Zitat von jean-christophe manciot :


I've just realized that lchown is only a system call, so it must be
used from within /usr/bin/freshclam.

On Thu, Oct 29, 2020 at 9:33 AM jean-christophe manciot
 wrote:


I have tried to add to /etc/apparmor.d/local/usr.bin.freshclam:
  capability dac_override,

and restarted apparmor then clamav-freshclam, the issue is still there:
# echo 'q' | sudo systemctl --no-pager --full status clamav-freshclam
● clamav-freshclam.service - ClamAV virus database updater
 Loaded: loaded (/lib/systemd/system/clamav-freshclam.service;
enabled; vendor preset: enabled)
 Active: failed (Result: exit-code) since Thu 2020-10-29 09:06:06
CET; 42s ago
   Docs: man:freshclam(1)
 man:freshclam.conf(5)
 https://www.clamav.net/documents
Process: 966650 ExecStart=/usr/bin/freshclam -d --foreground=true
(code=exited, status=9)
   Main PID: 966650 (code=exited, status=9)

Oct 29 09:06:06 hostname systemd[1]: Started ClamAV virus database updater.
Oct 29 09:06:06 hostname freshclam[966650]: ERROR: lchown to user
'clamav' failed on
Oct 29 09:06:06 hostname freshclam[966650]: log file
'/var/log/clamav/freshclam.log'.
Oct 29 09:06:06 hostname freshclam[966650]: Error was 'Operation  
not permitted'

Oct 29 09:06:06 hostname freshclam[966650]: Thu Oct 29 09:06:06 2020
-> ^lchown to user 'clamav' failed on log file
'/var/log/clamav/freshclam.log'.  Error was 'Operation not permitted'
Oct 29 09:06:06 hostname freshclam[966650]: Thu Oct 29 09:06:06 2020
-> !Failed to switch to clamav user.
Oct 29 09:06:06 hostname systemd[1]: clamav-freshclam.service: Main
process exited, code=exited, status=9/n/a
Oct 29 09:06:06 hostname systemd[1]: clamav-freshclam.service: Failed
with result 'exit-code'.

The error message regarding 'lchown' is strange: I have checked
/etc/init.d/clamav-freshclam, and also config and postinst included in
the DEBIAN folder of the package, none includes such a call.
However, postinst does include 'chown "$dbowner":adm
$FRESHCLAMLOGFILE' (with dbowner=clamav and
FRESHCLAMLOGFILE=/var/log/clamav/freshclam.log), so lchown does not
seem necessary wherever it is located.

On Thu, Oct 29, 2020 at 12:07 AM Sebastian Andrzej Siewior
 wrote:
>
> On 2020-10-27 07:22:22 [+], Michael Borgelt wrote:
> > I have tried different permissions for the file and the  
directory without

> > success. The obove permissions are after a clean reinstall off clamav
> > package.
>
> The problem appears to be the apparmor or freshclam's profile for it. So
> disabling apparmor should make freshclam work again.
> Probably adding
> | capability dac_override,
>
> to the profile will help, too. I will test it later today…
>
> Sebastian



--
Jean-Christophe




--
Jean-Christophe




--
Michael Borgelt
e-mail: mich...@borgelt.org

Bug#973365: On MacBook Pro (P8600) wifi card with BCM4322 chipset does not work

[Giuseppe Sacco]

Package: broadcom-sta
Version: 6.30.223.271-15
Severity: major

Hello,
on an Apple MacBook Pro running debian testing (kernel package is
version 5.9.1-1), I have this card:

# lspci | fgrep Netw
02:00.0 Network controller: Broadcom Inc. and subsidiaries BCM4322 
802.11a/b/g/n Wireless LAN Controller (rev 01)

The card is recognized and managed by the broadcom-sta driver but it
does not displays the list of available networks:

# iw wlp2s0 info
Interface wlp2s0
ifindex 3
wdev 0x1
addr d8:a2:5e:94:71:2f
type managed
wiphy 0
txpower 200.00 dBm

# iw wlp2s0 scan

# iwlist wlp2s0 scanning 
wlp2s0No scan results

some errors are collected by dmesg:

# dmesg | fgrep wl
[6.264433] wl: loading out-of-tree module taints kernel.
[6.264438] wl: module license 'MIXED/Proprietary' taints kernel.
[6.295680] wl: module verification failed: signature and/or required key 
missing - tainting kernel
[6.483541] wlan0: Broadcom BCM432b 802.11 Hybrid Wireless Controller 
6.30.223.271 (r587334)
[6.736188] wl :02:00.0 wlp2s0: renamed from wlan0
[   51.038418] ERROR @wl_notify_scan_status : 
[   51.038423] wlp2s0 Scan_results error (-22)
[   71.069924] ERROR @wl_notify_scan_status : 
[   71.069929] wlp2s0 Scan_results error (-22)
[  100.036085] ERROR @wl_notify_scan_status : 
[  100.036089] wlp2s0 Scan_results error (-22)
[  143.072119] ERROR @wl_notify_scan_status : 
[  143.072124] wlp2s0 Scan_results error (-22)
[  207.044072] ERROR @wl_notify_scan_status : 
[  207.044077] wlp2s0 Scan_results error (-22)
[  302.052066] ERROR @wl_notify_scan_status : 
[  302.052071] wlp2s0 Scan_results error (-22)
[  423.136013] ERROR @wl_notify_scan_status : 
[  423.136016] wlp2s0 Scan_results error (-22)
[  544.127948] ERROR @wl_notify_scan_status : 
[  544.127950] wlp2s0 Scan_results error (-22)
[  583.360026] ERROR @wl_notify_scan_status : 
[  583.360029] wlp2s0 Scan_results error (-22)
[  633.348078] ERROR @wl_notify_scan_status : 
[  633.348084] wlp2s0 Scan_results error (-22)

A more detailed output of lspci is:

# lspci -vv -s 02:00.0
02:00.0 Network controller: Broadcom Inc. and subsidiaries BCM4322 
802.11a/b/g/n Wireless LAN Controller (rev 01)
Subsystem: Apple Inc. AirPort Extreme
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort+ SERR- 
Capabilities: [e8] MSI: Enable- Count=1/1 Maskable- 64bit+
Address:   Data: 
Capabilities: [d0] Express (v1) Endpoint, MSI 00
DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <4us, L1 
unlimited
ExtTag+ AttnBtn- AttnInd- PwrInd- RBE+ FLReset- 
SlotPowerLimit 0.000W
DevCtl: CorrErr- NonFatalErr- FatalErr- UnsupReq-
RlxdOrd- ExtTag+ PhantFunc- AuxPwr- NoSnoop-
MaxPayload 128 bytes, MaxReadReq 128 bytes
DevSta: CorrErr+ NonFatalErr- FatalErr- UnsupReq- AuxPwr- 
TransPend-
LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Exit 
Latency L0s <4us, L1 <64us
ClockPM+ Surprise- LLActRep- BwNot- ASPMOptComp-
LnkCtl: ASPM L0s L1 Enabled; RCB 64 bytes, Disabled- CommClk+
ExtSynch- ClockPM+ AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s (ok), Width x1 (ok)
TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
Capabilities: [100 v1] Advanced Error Reporting
UESta:  DLP- SDES- TLP- FCP- CmpltTO+ CmpltAbrt- UnxCmplt- 
RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
UEMsk:  DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- 
RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
UESvrt: DLP+ SDES- TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- 
RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
CESta:  RxErr- BadTLP- BadDLLP- Rollover- Timeout- 
AdvNonFatalErr+
CEMsk:  RxErr- BadTLP- BadDLLP- Rollover- Timeout- 
AdvNonFatalErr+
AERCap: First Error Pointer: 0e, ECRCGenCap+ ECRCGenEn- 
ECRCChkCap+ ECRCChkEn-
MultHdrRecCap- MultHdrRecEn- TLPPfxPres- HdrLogCap-
HeaderLog: 0001 00a8000f d3203088 
Capabilities: [13c v1] Virtual Channel
Caps:   LPEVC=0 RefClk=100ns PATEntryBits=1
Arb:Fixed- WRR32- WRR64- WRR128-
Ctrl:   ArbSelect=Fixed
Status: InProgress-
VC0:Caps:   PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
Arb:Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256-
Ctrl:   Enable+ ID=0 ArbSelect=Fixed TC/VC=ff
Status: NegoPending- InProgress-
Capabilities: [160 v1] Device Serial Number 71-2f-5e-ff-ff-94-d8-a2
Capabilities: [16c 

Bug#972552: closed by Debian FTP Masters (reply to Julian Andres Klode ) (Bug#972552: fixed in apt 2.1.11)

[Otto Kekäläinen]

Hello!

I am still seeing this error with latest apt 2.1.11:

https://salsa.debian.org/mariadb-team/mariadb-10.5/-/jobs/1117112

E: Could not configure 'libc6:amd64'.
W: Could not perform immediate configuration on 'libnss-nis:amd64'.
Please see man 5 apt.conf under APT::Immediate-Configure for details.
(2)

Bug#972867: Patch

[Mathieu Malaterre]

Case sensitive systems are affected by 2.1.0 release.
diff --git a/CMake/FindCharLS.cmake b/CMake/FindCharLS.cmake
index 8f6bf19..b253a61 100644
--- a/CMake/FindCharLS.cmake
+++ b/CMake/FindCharLS.cmake
@@ -6,7 +6,7 @@
 #  For details see the accompanying COPYING-CMAKE-SCRIPTS file.
 #
 
-find_path(CHARLS_INCLUDE_DIR CharLS/charls.h
+find_path(CHARLS_INCLUDE_DIR charls/charls.h
 /usr/local/include
 /usr/include
 )
diff --git a/Utilities/gdcm_charls.h b/Utilities/gdcm_charls.h
index b80451c..e01d75b 100644
--- a/Utilities/gdcm_charls.h
+++ b/Utilities/gdcm_charls.h
@@ -18,7 +18,7 @@
 #include "gdcmTypes.h"
 #ifdef GDCM_USE_SYSTEM_CHARLS
 // It is expected that version 2.0.0 is used
-# include 
+# include 
 #else
 #include "gdcmcharls/charls.h"
 #endif

Bug#924303: [Pkg-fonts-devel] Bug#924303: Bug#924303: fonts-noto-core: creates an obsolete config file

[Jonas Smedegaard]

Quoting Laurent Bonnaud (2020-10-29 17:49:04)
> On 10/29/20 4:30 PM, Jonas Smedegaard wrote:
> 
> > Please elaborate: What_is_  the issue?
> 
> It is my understanding that packages should not create obsolete 
> conffiles.  That's what I understood when reading this:
> 
> https://raphaelhertzog.com/2010/10/07/the-right-way-to-remove-an-obsolete-conffile-in-a-debian-package/

Thanks for the additional information - that helps.

I agree that packages should cleanup conffiles no longer included with 
the package (assuming that's what you mean by "should not create 
obsolete conffiles").

I fail to recognize, however, that fonts-noto-core fails to such 
cleanup.

The command you share the output of indicates that you feel that the 
conffile /etc/fonts/conf.avail/30-droid-noto.conf is the one that is not 
cleaned up, and you reported this issue against version 20181227-1 of 
fonts-noto-core.

Did you have fonts-noto-core 20181227-1 installed, or installed and then 
removed, or installed and then purged, when you ran that command?


Kind regards,

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#973375: ITP: r-cran-optimx -- GNU R expanded replacement and extension of the 'optim' function

[Andreas Tille]

Package: wnpp
Severity: wishlist

Subject: ITP: r-cran-optimx -- GNU R expanded replacement and extension of the 
'optim' function
Package: wnpp
Owner: Andreas Tille 
Severity: wishlist

* Package name: r-cran-optimx
  Version : 2020
  Upstream Author : John C Nash,
* URL : https://cran.r-project.org/package=optimx
* License : GPL-2
  Programming Lang: GNU R
  Description : GNU R expanded replacement and extension of the 'optim' 
function
 Provides a replacement and extension of the optim() function to call to
 several function minimization codes in R in a single statement. These
 methods handle smooth, possibly box constrained functions of several or
 many parameters. Note that function 'optimr()' was prepared to simplify
 the incorporation of minimization codes going forward. Also implements
 some utility codes and some extra solvers, including safeguarded Newton
 methods. Many methods previously separate are now included here. This is
 the version for CRAN.

Remark: This package is maintained by Debian R Packages Maintainers at
   https://salsa.debian.org/r-pkg-team/r-cran-optimx

Bug#973374: uscan: 'pgpmode=gittag' fails when USCAN_DESTDIR is set

[Nicholas D Steeves]

Subject: uscan: 'pgpmode=gittag' fails when USCAN_DESTDIR is set
Package: devscripts
Version: 2.20.4
Severity: important

Hi,

See attachment for full log.  The short version is the repo is cloned,
the tarball is created; however tag verification appears to fail when
USCAN_DESTDIR is set, because "$PWD/../" appears to be the hardcoded
location for the temporary repository clone that 'pgpmode=gittag' uses.

I reported against 2.20.4, even though I'm using 2.20.4~bpo10+1, because I
believe it also affects 2.20.4.  I hope I'm not wrong!

...
uscan info: Successfully downloaded package: python-css-parser-1.0.6.tar.xz
fatal: not a git repository: '../python-css-parser-temporary.30699.git'
uscan: error: git --git-dir ../python-css-parser-temporary.30699.git
show-ref refs/tags/v1.0.6 subprocess returned exit status 1
28

Regards,
Nicholas

-- Package-specific info:

--- /etc/devscripts.conf ---
DEBCHANGE_MULTIMAINT_MERGE=yes
DEBCHANGE_MAINTTRAILER=yes
DEBSIGN_KEYID=E2A6261E3900AED7CDC667085A8830475F7D1061
DPKGSIG_KEYID=E2A6261E3900AED7CDC667085A8830475F7D1061
USCAN_DESTDIR=/home/sten/devel/tarballs

--- ~/.devscripts ---
Not present

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

Kernel: Linux 5.4.61-sten (SMP w/4 CPU cores; PREEMPT)
Kernel taint flags: TAINT_UNSIGNED_MODULE
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8),
LANGUAGE=en_CA:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages devscripts depends on:
ii  dpkg-dev  1.19.7
ii  fakeroot  1.23-1
ii  file  1:5.35-4+deb10u1
ii  gnupg 2.2.20-1~bpo10+1
ii  gnupg22.2.20-1~bpo10+1
ii  gpgv  2.2.20-1~bpo10+1
ii  libc6 2.28-10
ii  libfile-homedir-perl  1.004-1
ii  libfile-which-perl1.23-1
ii  libipc-run-perl   20180523.0-1
ii  libmoo-perl   2.003004-2
ii  libwww-perl   6.36-2
ii  patchutils0.3.4-2
ii  perl  5.28.1-6+deb10u1
ii  python3   3.7.3-1
ii  sensible-utils0.0.12
ii  wdiff 1.2.2-2+b1

Versions of packages devscripts recommends:
ii  apt 1.8.2.1
ii  at  3.1.23-1
ii  curl7.64.0-4+deb10u1
ii  dctrl-tools 2.24-3
ii  debian-keyring  2019.02.25
ii  dput1.0.3
ii  equivs  2.2.0
ii  libdistro-info-perl 0.21
ii  libdpkg-perl1.19.7
ii  libencode-locale-perl   1.05-1
ii  libgit-wrapper-perl 0.048-1
pn  libgitlab-api-v4-perl   
ii  liblist-compare-perl0.53-1
ii  liblwp-protocol-https-perl  6.07-2
ii  libsoap-lite-perl   1.27-1
ii  libstring-shellquote-perl   1.04-1
ii  libtry-tiny-perl0.30-1
ii  liburi-perl 1.76-1
ii  licensecheck3.0.31-3
ii  lintian 2.98.0~bpo10+1
ii  man-db  2.8.5-2
ii  patch   2.7.6-3+deb10u1
ii  pristine-tar1.46
ii  python3-apt 1.8.4.1
ii  python3-debian  0.1.35
ii  python3-magic   2:0.4.15-2
ii  python3-requests2.21.0-1
ii  python3-unidiff 0.5.4-1
ii  python3-xdg 0.25-5
ii  strace  4.26-0.2
ii  unzip   6.0-23+deb10u1
ii  wget1.20.1-1.1
ii  xz-utils5.2.4-1

Versions of packages devscripts suggests:
ii  adequate 0.15.2
ii  autopkgtest  5.10
pn  bls-standalone   
ii  bsd-mailx [mailx]8.1.2-0.20180807cvs-1
ii  build-essential  12.6
pn  check-all-the-things 
pn  cvs-buildpackage 
ii  debhelper13.2~bpo10+1
pn  devscripts-el
ii  diffoscope   160~bpo10+1
pn  disorderfs   
ii  dose-extra   5.0.1-12
pn  duck 
ii  faketime 0.9.7-3
ii  gnuplot  5.2.6+dfsg1-1+deb10u1
ii  gnuplot-qt [gnuplot] 5.2.6+dfsg1-1+deb10u1
ii  how-can-i-help   16
ii  libauthen-sasl-perl  2.1600-1
pn  libdbd-pg-perl   
ii  libfile-desktopentry-perl0.22-1
pn  libnet-smtps-perl
pn  libterm-size-perl
ii  libtimedate-perl 2.3000-2+deb10u1
ii  libyaml-syck-perl1.31-1+b1
ii  mailutils [mailx]1:3.5-4
ii  mozilla-devscripts   0.53
ii  mutt 1.10.1-2.1+deb10u3
ii  openssh-client [ssh-client]  1:7.9p1-10+deb10u2
ii  piuparts 1.0.0+deb10u1
pn  

Bug#962790: python-pairix_0.3.7-1_amd64.changes REJECTED

[Andreas Tille]

Hi Thorsten,

On Wed, Oct 28, 2020 at 10:00:10PM +, Thorsten Alteholz wrote:
> please mention all copyright holders in your debian/copyright.

Fixed in new upload

  Andreas.

-- 
http://fam-tille.de

Bug#973373: blueman: Blueman requires authentication twice on start-up

[Andrew]

Package: blueman
Version: 2.0.8-1+deb10u1
Severity: normal

Dear Maintainer,

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

   * I performaned a system update.
   * On start-up the next day I had authenticate blueman twice, once for 
Network and the second for RFKill
   * The outcome was that I could continue to use my computer
   * I didn't expect to have to enter my password twice following the update to 
blueman. Also all of the help I can reference appears to at aimed at a system 
with /etc/polkit-1/rules.d/81-blueman.rules versus what I'm seeing  
/etc/polkit-1/localauthority... on Raspberry Pi OS.

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


-- System Information:
Distributor ID: Raspbian
Description:Raspbian GNU/Linux 10 (buster)
Release:10
Codename:   buster
Architecture: armv7l

Kernel: Linux 5.4.72-v7l+ (SMP w/4 CPU cores)
Kernel taint flags: TAINT_CRAP
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set 
to en_US.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages blueman depends on:
ii  bluez 5.50-1.2~deb10u1+rpt2
ii  bluez-obexd   5.50-1.2~deb10u1+rpt2
ii  dbus  1.12.20-0+deb10u1
ii  dbus-user-session [default-dbus-session-bus]  1.12.20-0+deb10u1
ii  dbus-x11 [dbus-session-bus]   1.12.20-0+deb10u1
ii  dconf-gsettings-backend [gsettings-backend]   0.30.1-2
ii  gir1.2-appindicator3-0.1  0.4.92-7
ii  gir1.2-gdkpixbuf-2.0  2.38.1+dfsg-1
ii  gir1.2-glib-2.0   1.58.3-2
ii  gir1.2-gtk-3.03.24.5-1+rpt2
ii  gir1.2-notify-0.7 0.7.7-4
ii  gir1.2-pango-1.0  1.42.4-8~deb10u1
ii  gnome-icon-theme  3.12.0-3
ii  gnome-shell [notification-daemon] 3.30.2-11~deb10u2
ii  libbluetooth3 5.50-1.2~deb10u1+rpt2
ii  libc6 2.28-10+rpi1
ii  libglib2.0-0  2.58.3-2+deb10u2
ii  libpulse-mainloop-glib0   12.2-4+deb10u1
ii  libpython3.7  3.7.3-2+deb10u2
ii  librsvg2-common   2.44.10-2.1+rpi1
ii  python3   3.7.3-1
ii  python3-cairo 1.16.2-1+b1
ii  python3-dbus  1.2.8-3
ii  python3-gi3.30.4-1
ii  python3-gi-cairo  3.30.4-1

Versions of packages blueman recommends:
ii  policykit-1  0.105-25
ii  pulseaudio-module-bluetooth  12.2-4+deb10u1

blueman suggests no packages.

-- no debconf information

Bug#973372: linux: Select PINCTRL_TIGERLAKE to support current hardware

[Paul Menzel]

Package: src:linux
Version: 5.9.1-1
Severity: normal

Dear Debian folks,


On the Dell XPS 13 9310, Linux 5.9.1 from Debian Sid/unstable currently 
logs the message below [1].


[2.218614] psmouse serio1: synaptics: Your touchpad (PNP: 
DLL0991 PNP0f13) says it can support a different bus. If i2c-hid and 
hid-rmi are not used, you might want to try setting 
psmouse.synaptics_intertouch to 1 and report this to 
linux-in...@vger.kernel.org.


On Ubuntu 20.04.1 and 20.10, Linux does not show that message, and the 
reason seems to be, that it configures the Linux kernel with 
`PINCTRL_TIGERLAKE`. Big thanks to Dell’s Mario Limonciello for pointing 
that out.


It’d be great, if you also built the driver module in Debian.


Kind regards,

Paul


[1]: 
https://lore.kernel.org/linux-input/dm6pr19mb26367b8bbe1fe7912ababc14fa...@dm6pr19mb2636.namprd19.prod.outlook.com/T/#t

Bug#973370: onednn: FTBFS on non-amd64 due to immintrin.h missing

[Michael R. Crusoe]

I

On Thu, Oct 29, 2020 at 5:03 PM Michael R. Crusoe  wrote:

>
> This might be fixed by:
>
> 1) using the technique documented at
> https://wiki.debian.org/SIMDEverywhere


I've proposed a fix using solution #1 at
https://salsa.debian.org/deeplearning-team/onednn/-/merge_requests/1

>
> 2) adding 'skippable' to the 'Restrictions' list in debian/tests/control
> 3) or making this an 'Architecture: amd64' only package.
>
> Cheers,
>

Bug#970217: java-propose-classpath does not run as it does not find jcf-dump

[Pierre Gruet]

Control: severity -1 important

Hi,

I am raising the sevrity to important as I tested java-propose-classpath
on several other jars and naver had it work.

Feel free to contact me if I can provide further information.

Bye,
Pierre

Bug#973371: RFS: pytest-dependency/0.5.1-1 [ITP] -- Manages dependencies of pytest test cases

[Bastian Germann]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "pytest-dependency":

 * Package name: pytest-dependency
   Version : 0.5.1-1
   Upstream Author : Rolf Krahl 
 * URL : https://github.com/RKrahl/pytest-dependency
 * License : Apache-2.0
   Section : python
 * Vcs: https://salsa.debian.org/python-team/packages/pytest-dependency

It builds those binary packages:

  python-pytest-dependency-doc - Manages dependencies of pytest test
cases (common documentation)
  python3-pytest-dependency - Manages dependencies of pytest test cases
(Python 3)

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

  https://mentors.debian.net/package/pytest-dependency/

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

  dget -x
https://mentors.debian.net/debian/pool/main/p/pytest-dependency/pytest-dependency_0.5.1-1.dsc

Changes for the initial release:

 pytest-dependency (0.5.1-1) unstable; urgency=medium
 .
   * Initial release (Closes: #972718)

Regards,
Bastian

Bug#973370: onednn: FTBFS on non-amd64 due to immintrin.h missing

[Michael R. Crusoe]

Source: onednn
Version: 2.0~beta8+ds-3
Severity: normal
Tags: ftbfs

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear Debian AI Team,

Package onednn FTBFS on non-x86 and this is blocking its migration to
testing due to autopkgtest failures on arm64, armhf, and i386

https://buildd.debian.org/status/fetch.php?pkg=onednn=arm64=2.0%7Ebeta8%2Bds-3=1603121335=0
shows up

[01m[K../src/gpu/jit/gemm/../ngen/ngen_utils.hpp:22:10:[m[K [01;31m[Kfatal 
error: [m[Kimmintrin.h: No such file or directory
   22 | #include [01;31m[K[m[K
  |  [01;31m[K^[m[K

This might be fixed by:

1) using the technique documented at https://wiki.debian.org/SIMDEverywhere
2) adding 'skippable' to the 'Restrictions' list in debian/tests/control
3) or making this an 'Architecture: amd64' only package.

Cheers,

-BEGIN PGP SIGNATURE-

iQJGBAEBCgAwFiEEck1gkzcRPHEFUNdHPCZ2P2xn5uIFAl+a5wgSHGNydXNvZUBk
ZWJpYW4ub3JnAAoJEDwmdj9sZ+bigZQP+wUkhQi4Xkv/K5alArmIKJBkOK1hH+NE
0+r3oKG5h2xmgFjw14O61Tp0R9vBvOAfj5InGVsIFumk3PYRF6jh9qC5MVfW14Bb
OcdQ9QR2mCyBqXgD5TT0zZd5DHvPyDi2kl8PwF8zkieZDBrwLBP0XAxAgPPMQhD0
f9n93BFulRRCXc1fXgmVb1nRq8zlLrw3DvtDBA2O3Mkhwq17bVyTiucEIsF9OUG4
ssZvfINx09vr3qCarwHT2d/TYtbGxOT8uWDWZM5OUniJw+Kb24lcbG/X/g3QCPm9
VwVShpru0kHd4p4KdEbMkXX/t6fl4ZxULPxXZybqZhZ3xzsOkgIRbyOwoM8kiI5Q
oKfzgrD5SplzPFIWxgLQTfAWVLFnDcl2du2RrRtL7hftXaUiQiCLokZ1KCCviwOS
gZyNNXOfpEoMOkb4hXtBo++EuzTyVFXMh71BYZHjzhmLkhG5GzV8Iw1PLx5qWv9N
YOggNyBm2nu2yk5Ptprt1jRqRrbG/AJt4Jk9CuuDhK4gwD15my6XG/r/7jOqu8rp
+WcT3dVjSI/LuucH37iGM1CGeZ6+f6uxMLiyRjmKErrMN8VxsUkpT0RCQaxlUEeW
TvtdAgT78SX/SA0O/bIa0C9KmMQT1A153ecIew1OJbyvWa2xNytYJmgB+xwbN35F
xbGCOWcMFlW4
=Rk+N
-END PGP SIGNATURE-

Bug#924303: [Pkg-fonts-devel] Bug#924303: fonts-noto-core: creates an obsolete config file

[Jonas Smedegaard]

control: tags -1 moreinfo unreproducible

Hi Laurent,

Quoting Laurent Bonnaud (2019-03-11 10:28:25)
> here is the problem:
> 
> $ dpkg-query -W -f='${Conffiles}\n' | grep obsolete$
>  /etc/fonts/conf.avail/30-droid-noto.conf a34074694dce0a5ccc5844ec0a1315ea 
> obsolete

Thanks for reporting this issue.

So you are reporting _where_ you spotted an issue.

Please elaborate: What _is_ the issue?


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#972691: swupdate: mips platforms still do not build

[Bastian Germann]

On Thu, 22 Oct 2020 18:02:21 +0200 Bastian Germann wrote:
> Package: swupdate
> Version: 2020.04-2
> 
> The swupdate build still fails on mipsel and mips64el platforms due to
> the test runs failing. My first patch was not effective, so I attached
> another one.

Somehow, the mips*el still transitioned to bullseye... I do not get why.

Bug#973369: linux-image-5.9.0: No network at Banana Pi M3

[Bernhard]

Source: linux
Version: 5.9.1-1
Severity: important

Hello,

From Kernel 5.9, a correction was done within Ethernet PHY RTL8211e.

The correction was done with commit bbc4d71d63549bcd003a430de18a72a742d8c91e in 
kernel:
https://lkml.org/lkml/2020/10/12/833

But now, with this correction, there is no more network available at the Banana 
Pi M3.

Regarding the network problem at Banana Pi M3:
It seems, there is a correction available now in kernel mainline with commit 
57dbe558457bf4042169bc1f334e3b53a8480a1c:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts?h=next-20201029=57dbe558457bf4042169bc1f334e3b53a8480a1c

Currently, in kernel 5.9.2, this correction is not included.
Can you please add the patch to the Debian Kernel to have a working network at 
the Banana Pi M3?
Thank you.

I set this bug report to important, because after some Google, there are some 
boards affected regarding this topic.

Best regards
Bernhard



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

Bug#972514: fixed in nvidia-graphics-drivers 450.80.02-1

[David Headland]

Hi Heinz,

Good question, as I've gone back to 450.80 for the moment and that's
working perfectly for me. I've checked through the logs for when I was
running 455, and it seems I had the same package versions as you, with
the exception of:

* libcuda1and
* libnvidia-ptxjitcompiler1
* nvidia-detect
* nvidia-installer0cleanup

For the packages listed, I didn't (and still do not) have them
installed. So this is very strange. I suppose it could have been
something else installed on the system, but I'm not sure what. It does
seem like it's just a problem with my system, so I wouldn't want to put
anyone off trying the move to 455.

On 29/10/2020 13:34, Heinz Repp wrote:
> In reply to Dave:
> 
> Hmm, I have exactly the same card as you, my lspci says also:
> 
>> 01:00.0 VGA compatible controller: NVIDIA Corporation GP108 [GeForce
>> GT 1030] (rev a1)
> so this is not the culprit. Did you install all nvidia packages from
> experimental (=455), or do you still have rests from 450? For your
> information, I have installed:
> 
>> glx-alternative-nvidia/testing,unstable,now 1.2.0 amd64  [installiert]
>> libcuda1/now 455.23.04-1 amd64  [Installiert,lokal]
>> libegl-nvidia0/now 455.23.04-1 amd64  [Installiert,lokal]
>> libgl1-nvidia-glvnd-glx/now 455.23.04-1 amd64  [Installiert,lokal]
>> libglx-nvidia0/now 455.23.04-1 amd64  [Installiert,lokal]
>> libnvidia-cfg1/now 455.23.04-1 amd64  [Installiert,lokal]
>> libnvidia-eglcore/now 455.23.04-1 amd64  [Installiert,lokal]
>> libnvidia-glcore/now 455.23.04-1 amd64  [Installiert,lokal]
>> libnvidia-glvkspirv/now 455.23.04-1 amd64  [Installiert,lokal]
>> libnvidia-ml1/now 455.23.04-1 amd64  [Installiert,lokal]
>> libnvidia-ptxjitcompiler1/now 455.23.04-1 amd64  [Installiert,lokal]
>> nvidia-alternative/now 455.23.04-1 amd64  [Installiert,lokal]
>> nvidia-detect/now 455.23.04-1 amd64  [Installiert,lokal]
>> nvidia-driver-bin/now 455.23.04-1 amd64  [Installiert,lokal]
>> nvidia-driver-libs/now 455.23.04-1 amd64  [Installiert,lokal]
>> nvidia-driver/now 455.23.04-1 amd64  [Installiert,lokal]
>> nvidia-egl-common/now 455.23.04-1 amd64  [Installiert,lokal]
>> nvidia-egl-icd/now 455.23.04-1 amd64  [Installiert,lokal]
>> nvidia-installer-cleanup/testing,unstable,now 20151021+12 amd64 
>> [installiert]
>> nvidia-kernel-common/testing,unstable,now 20151021+12 amd64 
>> [installiert]
>> nvidia-kernel-dkms/now 455.23.04-1 amd64  [Installiert,lokal]
>> nvidia-kernel-support/now 455.23.04-1 amd64  [Installiert,lokal]
>> nvidia-legacy-check/now 455.23.04-1 amd64  [Installiert,lokal]
>> nvidia-modprobe/now 455.23.04-1 amd64  [Installiert,lokal]
>> nvidia-support/testing,unstable,now 20151021+12 amd64  [installiert]
>> nvidia-vdpau-driver/now 455.23.04-1 amd64  [Installiert,lokal]
>> nvidia-vulkan-common/now 455.23.04-1 amd64  [Installiert,lokal]
>> nvidia-vulkan-icd/now 455.23.04-1 amd64  [Installiert,lokal]
>> xserver-xorg-video-nvidia/now 455.23.04-1 amd64  [Installiert,lokal]
> 
> HTH
> 
> Heinz
> 



signature.asc
Description: OpenPGP digital signature

Bug#971259: azure-cli: Azure login is not working after installation

[Luca Boccassi]

Control: reassign -1 python3-azure 20200921+git-1
Control: fixed -1 20200927+git-1
Control: close -1

On Mon, 28 Sep 2020 12:02:48 +0200 Anthony Callegaro  wrote:
> Package: azure-cli
> Version: 2.11.1-1
> Severity: important
> X-Debbugs-Cc: cally...@free.fr

> 
> Hey there,
> 
> It seems the Azure-CLI package is not working for a new installation.
> 
> When running az login after a clean install I receive the following error :
> 
> $ az login
> You have logged in. Now let us find all the subscriptions to which you have
> access...
> The command failed with an unexpected error. Here is the traceback:
> 
> 'SubscriptionClient' object has no attribute 'config'
> Traceback (most recent call last):
>   File "/usr/lib/python3/dist-packages/knack/cli.py", line 215, in invoke
> cmd_result = self.invocation.execute(args)
>   File "/usr/lib/python3/dist-packages/azure/cli/core/commands/__init__.py",
> line 654, in execute
> raise ex
>   File "/usr/lib/python3/dist-packages/azure/cli/core/commands/__init__.py",
> line 718, in _run_jobs_serially
> results.append(self._run_job(expanded_arg, cmd_copy))
>   File "/usr/lib/python3/dist-packages/azure/cli/core/commands/__init__.py",
> line 711, in _run_job
> six.reraise(*sys.exc_info())
>   File "/home/letic/.local/lib/python3.8/site-packages/six.py", line 703, in
> reraise
> raise value
>   File "/usr/lib/python3/dist-packages/azure/cli/core/commands/__init__.py",
> line 688, in _run_job
> result = cmd_copy(params)
>   File "/usr/lib/python3/dist-packages/azure/cli/core/commands/__init__.py",
> line 325, in __call__
> return self.handler(*args, **kwargs)
>   File "/usr/lib/python3/dist-packages/azure/cli/core/__init__.py", line 782,
> in default_command_handler
> return op(**command_args)
>   File "/usr/lib/python3/dist-
> packages/azure/cli/command_modules/profile/custom.py", line 152, in login
> subscriptions = profile.find_subscriptions_on_login(
>   File "/usr/lib/python3/dist-packages/azure/cli/core/_profile.py", line 195,
> in find_subscriptions_on_login
> subscriptions = subscription_finder.find_through_authorization_code_flow(
>   File "/usr/lib/python3/dist-packages/azure/cli/core/_profile.py", line 849,
> in find_through_authorization_code_flow
> result = self._find_using_common_tenant(token_entry[_ACCESS_TOKEN],
> resource)
>   File "/usr/lib/python3/dist-packages/azure/cli/core/_profile.py", line 893,
> in _find_using_common_tenant
> client = self._arm_client_factory(token_credential)
>   File "/usr/lib/python3/dist-packages/azure/cli/core/_profile.py", line 812,
> in create_arm_client_factory
> configure_common_settings(cli_ctx, client)
>   File "/usr/lib/python3/dist-
> packages/azure/cli/core/commands/client_factory.py", line 79, in
> configure_common_settings

Hi,

This was fixed in python3-azure some time ago, closing.

-- 
Kind regards,
Luca Boccassi


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

Bug#951113: ITP: webp-pixbuf-loader -- WebP Image format GdkPixbuf loader.

[David Heidelberg]

Current debian packaging can be found here:
https://salsa.debian.org/okias-guest/webp-pixbuf-loader
Best regards
David Heidelberg

Bug#973368: Bluetooth mouse can not be connected with kernel linux-image-5.9.0-1-amd64

[gulfstream]

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


After the kernel was upgraded to linux-image-5.9.0-1-amd64 few days ago, the 
bluetooth mouse can not be connected which can be use with 
linux-image-5.8.0-3-amd64. If back to linux-image-5.8.0-3-amd64, the blue tooth 
mouse is also fine.

Would you please resolve it for us? Thank you very much!


Best regards,
Gulfstream



-- Package-specific info:
** Version:
Linux version 5.9.0-1-amd64 (debian-ker...@lists.debian.org) (gcc-10 (Debian 
10.2.0-15) 10.2.0, GNU ld (GNU Binutils for Debian) 2.35.1) #1 SMP Debian 
5.9.1-1 (2020-10-17)

** Command line:
BOOT_IMAGE=/vmlinuz-5.9.0-1-amd64 
root=UUID=db2908ea-7526-4516-844c-944d78f49385 ro

** Tainted: OE (12288)
 * externally-built ("out-of-tree") module was loaded
 * unsigned module was loaded

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

** Model information
sys_vendor: LENOVO
product_name: 20MES07K00
product_version: ThinkPad P1
chassis_vendor: LENOVO
chassis_version: None
bios_vendor: LENOVO
bios_version: N2EET49W (1.31 )
board_vendor: LENOVO
board_name: 20MES07K00
board_version: Not Defined

** Loaded modules:
snd_seq_dummy
snd_hrtimer
snd_seq
snd_seq_device
rfcomm
xfrm_user
l2tp_ppp
xfrm_algo
l2tp_netlink
l2tp_core
ip6_udp_tunnel
udp_tunnel
pppox
ppp_generic
slhc
xt_state
xt_conntrack
ctr
ccm
xt_CHECKSUM
ipt_REJECT
nf_reject_ipv4
xt_tcpudp
nft_compat
nft_counter
nft_chain_nat
nf_nat
nf_conntrack
nf_defrag_ipv6
nf_defrag_ipv4
nf_tables
nfnetlink
tun
bridge
stp
llc
cmac
algif_hash
algif_skcipher
af_alg
bnep
acpi_call(OE)
bbswitch(OE)
btusb
btrtl
btbcm
btintel
bluetooth
x86_pkg_temp_thermal
intel_powerclamp
snd_sof_pci
snd_sof_intel_hda_common
snd_sof_intel_hda
snd_sof_intel_byt
snd_sof_intel_ipc
coretemp
snd_sof
snd_sof_xtensa_dsp
snd_soc_skl
jitterentropy_rng
snd_soc_hdac_hda
snd_hda_ext_core
mei_wdt
kvm_intel
drbg
intel_rapl_msr
kvm
snd_soc_sst_ipc
irqbypass
iwlmvm
snd_hda_codec_realtek
snd_soc_sst_dsp
snd_soc_acpi_intel_match
aes_generic
ghash_clmulni_intel
aesni_intel
snd_soc_acpi
snd_soc_core
uvcvideo
crypto_simd
videobuf2_vmalloc
snd_hda_codec_generic
videobuf2_memops
cryptd
nls_ascii
snd_compress
mac80211
snd_hda_codec_hdmi
nls_cp437
videobuf2_v4l2
glue_helper
snd_hda_intel
videobuf2_common
ansi_cprng
vfat
snd_intel_dspcfg
fat
libarc4
rapl
ecdh_generic
tpm_crb
intel_cstate
videodev
snd_hda_codec
ecc
sg
tpm_tis
efi_pstore
joydev
crc16
mc
intel_uncore
libaes
iwlwifi
tpm_tis_core
snd_hda_core
iTCO_wdt
intel_pmc_bxt
rmi_smbus
iTCO_vendor_support
snd_hwdep
efivars
processor_thermal_device
tpm
pcspkr
wmi_bmof
intel_wmi_thunderbolt
rmi_core
thinkpad_acpi
mei_me
snd_pcm
watchdog
serio_raw
cfg80211
ucsi_acpi
mei
intel_rapl_common
snd_timer
intel_pch_thermal
typec_ucsi
intel_soc_dts_iosf
nvram
rng_core
typec
ledtrig_audio
snd
soundcore
rfkill
int3403_thermal
ac
int340x_thermal_zone
evdev
int3400_thermal
acpi_thermal_rel
intel_pmc_core
acpi_pad
parport_pc
ppdev
lp
parport
efivarfs
ip_tables
x_tables
autofs4
sd_mod
xfs
libcrc32c
crc32c_generic
wacom
hid_generic
usbhid
hid
uas
usb_storage
scsi_mod
i915
i2c_algo_bit
xhci_pci
nvme
e1000e
drm_kms_helper
xhci_hcd
nvme_core
t10_pi
crc_t10dif
cec
ptp
crct10dif_generic
crc32_pclmul
psmouse
intel_lpss_pci
i2c_i801
intel_lpss
usbcore
crc32c_intel
crct10dif_pclmul
drm
pps_core
i2c_smbus
crct10dif_common
idma64
usb_common
wmi
battery
video
button

** Network interface configuration:
*** /etc/network/interfaces:

source /etc/network/interfaces.d/*

auto lo
iface lo inet loopback

** Network status:
*** IP interfaces and addresses:
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group 
default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
   valid_lft forever preferred_lft forever
inet6 ::1/128 scope host 
   valid_lft forever preferred_lft forever
2: enp0s31f6:  mtu 1500 qdisc pfifo_fast 
state DOWN group default qlen 1000
link/ether 48:2a:e3:15:4a:e1 brd ff:ff:ff:ff:ff:ff
3: wlp0s20f3:  mtu 1500 qdisc noqueue state UP 
group default qlen 1000
link/ether 64:5d:86:d7:f7:26 brd ff:ff:ff:ff:ff:ff
inet 10.2.0.22/24 brd 10.2.0.255 scope global dynamic noprefixroute 
wlp0s20f3
   valid_lft 86078sec preferred_lft 86078sec
inet6 fe80::1daa:a34a:cdcc:56ae/64 scope link noprefixroute 
   valid_lft forever preferred_lft forever
4: virbr1:  mtu 1500 qdisc noqueue state 
DOWN group default qlen 1000
link/ether 52:54:00:d2:e3:c9 brd ff:ff:ff:ff:ff:ff
inet 192.168.65.1/24 brd 192.168.65.255 scope global virbr1
   valid_lft forever preferred_lft forever
5: virbr1-nic:  mtu 1500 qdisc pfifo_fast master virbr1 
state DOWN group default qlen 1000
link/ether 52:54:00:d2:e3:c9 brd ff:ff:ff:ff:ff:ff

*** Device statistics:
Inter-|   Receive|  Transmit
 face |bytespackets errs drop fifo frame compressed multicast|bytes
packets errs drop fifo colls carrier compressed
lo:9905 121   

Bug#973366: ITP: r-cran-lbfgsb3c -- GNU R limited memory BFGS minimizer with bounds on Parameters

[Andreas Tille]

Package: wnpp
Severity: wishlist

Subject: ITP: r-cran-lbfgsb3c -- GNU R limited memory BFGS minimizer with 
bounds on Parameters
Package: wnpp
Owner: Andreas Tille 
Severity: wishlist

* Package name: r-cran-lbfgsb3c
  Version : 2020
  Upstream Author : Matthew L Fidler,
* URL : https://cran.r-project.org/package=lbfgsb3c
* License : GPL-2
  Programming Lang: GNU R
  Description : GNU R limited memory BFGS minimizer with bounds on 
Parameters
 Interfacing to Nocedal et al. L-BFGS-B.3.0 (See
 ) limited
 memory BFGS minimizer with bounds on parameters. This is a fork of
 'lbfgsb3'. This registers a 'R' compatible 'C' interface to L-BFGS-B.3.0
 that uses the same function types and optimization as the optim()
 function (see writing 'R' extensions and source for details). This
 package also adds more stopping criteria as well as allowing the
 adjustment of more tolerances.

Remark: This package is maintained by Debian R Packages Maintainers at
   https://salsa.debian.org/r-pkg-team/r-cran-lbfgsb3c

Bug#973052: (unbound unaccountably crashes inside libevent (Assertion nread >= 0 failed in evmap_io_del_))

[Daniel Kahn Gillmor]

On Wed 2020-10-28 16:29:14 -0400, Robert Edmonds wrote:
> OK, I made a patch incorporating those fixes recommended by upstream and
> sent them to #962459. Looks like that doesn't work at all.

thanks for doing that, Robert.  Bummer that it didn't work.

> I'm not sure picking a random 1.9.x release is the right thing either.

well, Benno (from upstream) recommended 1.9.2 specifically, even though
1.9.2 isn't even their latest 1.9.x release (i think that'd be 1.9.6).

Maybe we should ask him why he proposed 1.9.2?

> Overhauling the packaging in the buster branch would probably make
> things unpleasant for stable reviewers, so I would not recommend doing
> that.

Sure, makes sense if we're cherry-picking patches.  but if we're moving
to a new upstream version maybe this change is enough "in the noise" to
make it make sense to align the packaging strategy with the unstable
packaging strategy?

Not sure what the next steps are, but i appreciate your looking into
this and thinking about it, Robert.  Users of Debian stable deserve to
have a non-crashy version one way or another.

  --dkg



signature.asc
Description: PGP signature

Bug#973135: Bug#973070: libsis-base-java: FTBFS: Could not delete the directory targets/unit-test-wd/ch.syst

[Markus Koschany]

Hi,

Am 29.10.20 um 15:11 schrieb Andreas Tille:

Hi,

here is a suggested patch for commons-io that would prevent making the
test in libsis-base-java fail.


It seems this is a six year old unresolved upstream bug.

https://issues.apache.org/jira/browse/IO-449

This should be fixed upstream in my opinion and not only in Debian. 
Other projects may rely exactly on that behavior.


Markus

Bug#956285: Problems identified in debian/copyright

[Petter Reinholdtsen]

[Moritz Mühlenhoff]
> JFTR, this is fixed in 1.2.9

Great.  Now if the maintainer or someone else could just upload it to
unstable, my vlc-plugin-bittorrent package would have a fighting chance
to become part of Bullseye...

Cristian or Andrew, please, do you have time to have a look?
 
-- 
Happy hacking
Petter Reinholdtsen

Bug#973135: Bug#973070: libsis-base-java: FTBFS: Could not delete the directory targets/unit-test-wd/ch.syst

[Andreas Tille]

Hi,

here is a suggested patch for commons-io that would prevent making the
test in libsis-base-java fail.

Kind regards

Andreas.

- Forwarded message from Bernd Rinn  -

Date: Wed, 28 Oct 2020 21:40:29 +0100
From: Bernd Rinn 
To: Andreas Tille 
CC: 973...@bugs.debian.org
Subject: Re: Bug#973070: libsis-base-java: FTBFS: Could not delete the 
directory targets/unit-test-wd/ch.syst

Hi Andreas,

I can confirm that this bug is in commons-io 2.8.0 while commons-io 2.6 workes
fine.

The bug is in PathUtils.deleteFile(), line 360 and 361:
"""
final boolean exists = Files.exists(file, LinkOption.NOFOLLOW_LINKS);
final long size = exists ? Files.size(file) : 0;
"""
It determines "exists" based on not following the symlink by using
LinkOption.NOFOLLOW_LINKS, but then in the next line uses Files.size(file) to
determine the size which *does* follow the symlink. Kaboom. This will prevent
PathUtils.deleteFile() to delete any dangling symlink (which it has to in my
test case).

I have attached a patch for commons-io 2.8.0 which fixes this bug.

Cheers,
Bernd

On 10/28/20 8:29 PM, Andreas Tille wrote:
> Control: forwarded -1 Bernd Rinn 
> 
> Hi,
> 
> I'd recommend reading the bug report log from here to get some hints
> about recommended changes in the code:
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=973070#17
> 
> For the moment I've excluded the affected tests.
> 
> Kind regards
> 
>Andreas.
> 
> - Forwarded message from Markus Koschany  -
> 
> Date: Wed, 28 Oct 2020 19:34:35 +0100
> From: Markus Koschany 
> To: Debian Java List 
> Cc: 973...@bugs.debian.org
> Subject: Bug#973070: Bug#973070: Help needed: Bug#973070: libsis-base-java: 
> FTBFS: Could not delete the directory
>   targets/unit-test-wd/ch.systemsx.cisd.base.unix.UnixTests because: 1 
> exceptions: [java.io.IOException: Unable to delete file:
>   
> targets/unit-test-wd/ch.systemsx.cisd.base.unix.UnixTests/someDanglingLink]
> X-Debian-PR-Message: followup 973070
> X-Debian-PR-Package: src:libsis-base-java
> X-Debian-PR-Keywords: bullseye ftbfs help sid
> X-Debian-PR-Source: libsis-base-java
> 
> 
> 
> Am 28.10.20 um 16:01 schrieb olivier sallou:
> [...]
> > *dumb* patch would be to simply remove those tests from code...
> 
> Either this or you can keep the override for dh_auto_test-arch empty.
> 
> The test creates a broken symlink but then FileUtils.deleteDirectory
> fails to delete the file, obviously because it is not a directory but
> I'm not sure how it really handles symlinks within directories. See also
> [1]. Probably upstream should switch to the java.nio.file API (they
> still use java.io.File), test for the existence of symlinks and then try
> File.delete instead of FileUtils.deleteDirectory first. Not tested, just
> a guess.
> 
> Markus
> 
> 
> [1] https://issues.apache.org/jira/browse/IO-576
> 
> 
> 
> 
> 
> ___
> Debian-med-packaging mailing list
> debian-med-packag...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-packaging
> 
> 
> - End forwarded message -

--- org/apache/commons/io/file/PathUtils.java.orig  2020-01-22 
15:10:16.0 +0100
+++ org/apache/commons/io/file/PathUtils.java   2020-10-28 21:32:24.874024999 
+0100
@@ -358,7 +358,8 @@
 }
 final PathCounters pathCounts = Counters.longPathCounters();
 final boolean exists = Files.exists(file, LinkOption.NOFOLLOW_LINKS);
-final long size = exists ? Files.size(file) : 0;
+final boolean existsFollowLink = Files.exists(file);
+final long size = existsFollowLink ? Files.size(file) : 0;
 if (overrideReadOnly(options) && exists) {
 setReadOnly(file, false, LinkOption.NOFOLLOW_LINKS);
 }




- End forwarded message -

-- 
http://fam-tille.de

Bug#972514: fixed in nvidia-graphics-drivers 450.80.02-1

[Heinz Repp]

In reply to Dave:

Hmm, I have exactly the same card as you, my lspci says also:


01:00.0 VGA compatible controller: NVIDIA Corporation GP108 [GeForce GT 1030] 
(rev a1)

so this is not the culprit. Did you install all nvidia packages from
experimental (=455), or do you still have rests from 450? For your
information, I have installed:


glx-alternative-nvidia/testing,unstable,now 1.2.0 amd64  [installiert]
libcuda1/now 455.23.04-1 amd64  [Installiert,lokal]
libegl-nvidia0/now 455.23.04-1 amd64  [Installiert,lokal]
libgl1-nvidia-glvnd-glx/now 455.23.04-1 amd64  [Installiert,lokal]
libglx-nvidia0/now 455.23.04-1 amd64  [Installiert,lokal]
libnvidia-cfg1/now 455.23.04-1 amd64  [Installiert,lokal]
libnvidia-eglcore/now 455.23.04-1 amd64  [Installiert,lokal]
libnvidia-glcore/now 455.23.04-1 amd64  [Installiert,lokal]
libnvidia-glvkspirv/now 455.23.04-1 amd64  [Installiert,lokal]
libnvidia-ml1/now 455.23.04-1 amd64  [Installiert,lokal]
libnvidia-ptxjitcompiler1/now 455.23.04-1 amd64  [Installiert,lokal]
nvidia-alternative/now 455.23.04-1 amd64  [Installiert,lokal]
nvidia-detect/now 455.23.04-1 amd64  [Installiert,lokal]
nvidia-driver-bin/now 455.23.04-1 amd64  [Installiert,lokal]
nvidia-driver-libs/now 455.23.04-1 amd64  [Installiert,lokal]
nvidia-driver/now 455.23.04-1 amd64  [Installiert,lokal]
nvidia-egl-common/now 455.23.04-1 amd64  [Installiert,lokal]
nvidia-egl-icd/now 455.23.04-1 amd64  [Installiert,lokal]
nvidia-installer-cleanup/testing,unstable,now 20151021+12 amd64  [installiert]
nvidia-kernel-common/testing,unstable,now 20151021+12 amd64  [installiert]
nvidia-kernel-dkms/now 455.23.04-1 amd64  [Installiert,lokal]
nvidia-kernel-support/now 455.23.04-1 amd64  [Installiert,lokal]
nvidia-legacy-check/now 455.23.04-1 amd64  [Installiert,lokal]
nvidia-modprobe/now 455.23.04-1 amd64  [Installiert,lokal]
nvidia-support/testing,unstable,now 20151021+12 amd64  [installiert]
nvidia-vdpau-driver/now 455.23.04-1 amd64  [Installiert,lokal]
nvidia-vulkan-common/now 455.23.04-1 amd64  [Installiert,lokal]
nvidia-vulkan-icd/now 455.23.04-1 amd64  [Installiert,lokal]
xserver-xorg-video-nvidia/now 455.23.04-1 amd64  [Installiert,lokal]


HTH

Heinz

Bug#973364: firmware-linux-free: Maybe missing soft dependency on wireless-regdb

[Axel Beckert]

Package: firmware-linux-free
Version: 20200122-1

Hi,

now that "iw" dropped the dependency on "crda" (see
https://bugs.debian.org/972994), "wireless-regdb" gets uninstalled, too,
as it was only pulled in via dependency by crda, at least on some of my
machines.

But according to
https://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/crda.git/commit/?id=f4ef2531698fb9ba006e8b31a223b3269be8bc7c
now the kernel itself seems to load wireless-regdb's
/lib/firmware/regulatory.db* files.

So I wonder if there should be a soft dependency from either
firmware-linux-free (feels like the proper place) or maybe the kernel
images itself instead, since this seems to be the kernel which will be
actually looking for that file. The latter looks like the right place
when pendanticly interpreting the Debian Policy with regards to package
relations.

P.S.: No idea about the severity, could be anything from RC due to being
(IMHO pedantic) policy violation due to missing package relation, down
to "minor" (nobody cared about that relation to the kernel since kernel
4.15, so it can't be that severe and it's clearly only needed only by
devices which use WiFi and there not even for functioning, just for
avoiding local legal issues and maybe local technical issues), therefore
leaving it at the default. Feel free to adjust and/or reassign.

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

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

firmware-linux-free depends on no packages.

firmware-linux-free recommends no packages.

Versions of packages firmware-linux-free suggests:
ii  initramfs-tools  0.139

-- no debconf information

Bug#972936: libgcc-s1 needs Breaks: libgcc1 (<< 1:10)

[Julian Andres Klode]

Control: subscribe -1

On Tue, Oct 27, 2020 at 03:45:59PM +0200, Adrian Bunk wrote:
> Control: severity -1 grave
> 
> On Tue, Oct 27, 2020 at 12:44:44PM +0100, Matthias Klose wrote:
> > Control: severity -1 important
> > 
> > On 10/26/20 1:04 PM, Adrian Bunk wrote:
> > > Package: libgcc-s1
> > > Version: 10.2.0-15
> > > Severity: grave
> > > 
> > > On a buster system, with unstable pinned to low priority:
> > 
> > Lowering the severity. Feel free to correct me if this specific 
> > configuration
> > deserves RC severity.
> 
> This is pretty exactly the problem described in
> https://www.debian.org/doc/debian-policy/ch-relationships.html#id11
> 
> Losing libgcc1 is extra bad, since so much (including apt) uses it.
> 
> Hard to recover when you hit the problem, and trivial to fix.

It's not trivial to fix, if it's fixable at all. Adding the Breaks
can cause the library to disappear in the middle of the upgrade,
because libgcc1 is upgraded first or temporarily removed, which
is the reason it's not there.

I thought about hacking a workaround into apt that prevents you
from removing libgcc-s1 if libgcc1 is installed, but that's not
super helpful as you need a current apt.

My suggestion is to set XB-Important: yes and Protected: yes on
libgcc-s1 such that people cannot easily remove it after it's
installed.

We can then remove that bit in bookworm.

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

Bug#973354: src:apt-cacher: fails to migrate to testing for too long: maintainer built arch:all binaries

[Mark Hindley]

Paul,

Many thanks for this.


On Thu, Oct 29, 2020 at 11:51:18AM +0100, Paul Gevers wrote:
> Your package is only blocked because the arch:all binary package(s)
> aren't built on a buildd. Unfortunately the Debian infrastructure
> doesn't allow arch:all packages to be properly binNMU'ed. Hence, I will
> shortly do a no-changes source-only upload to DELAYED/15, closing this
> bug. Please let me know if I should delay or cancel that upload.

I had been trying to get this resolved through my usual sponsor/uploader, but
have been unable to get a response from him. So you action is very
welcome. Thanks.

I am happy for there to be no delay, should you wish.

Thanks.

Mark

Bug#973363: node-uid-number: package does not install get-uid-gid.js file from source

[Moritz Schlarb]

Package: node-uid-number
Version: 0.0.6-1
Severity: grave
Tags: patch
Justification: renders package unusable

The source for this package also includes a file named get-uid-gid.js which is
not installed with the package files.

This causes an unrelated npm/npx command to fail with:

18116 silly postinstall core-js@3.6.5
18117 info lifecycle core-js@3.6.5~postinstall: core-js@3.6.5
18118 verbose lifecycle core-js@3.6.5~postinstall: unsafe-perm in lifecycle
false
18119 verbose stack Error: Cannot find module './get-uid-gid.js'
18119 verbose stack at Function.Module._resolveFilename
(internal/modules/cjs/loader.js:636:15)
18119 verbose stack at Function.resolve
(internal/modules/cjs/helpers.js:33:19)
18119 verbose stack at uidNumber (/usr/lib/nodejs/uid-number/uid-
number.js:31:24)
18119 verbose stack at runCmd (/usr/share/npm/node_modules/npm-
lifecycle/index.js:267:5)
18119 verbose stack at runPackageLifecycle
(/usr/share/npm/node_modules/npm-lifecycle/index.js:228:3)
18119 verbose stack at Array. (/usr/lib/nodejs/slide/lib/bind-
actor.js:15:8)
18119 verbose stack at LOOP (/usr/lib/nodejs/slide/lib/chain.js:15:14)
18119 verbose stack at chain (/usr/lib/nodejs/slide/lib/chain.js:20:5)
18119 verbose stack at lifecycle_ (/usr/share/npm/node_modules/npm-
lifecycle/index.js:167:3)
18119 verbose stack at /usr/share/npm/node_modules/npm-
lifecycle/index.js:104:9
18119 verbose stack at /usr/share/npm/node_modules/npm-
lifecycle/index.js:218:12
18119 verbose stack at /usr/lib/nodejs/graceful-fs/polyfills.js:287:18
18119 verbose stack at FSReqWrap.oncomplete (fs.js:154:5)
18120 verbose cwd /tmp/bla
18121 verbose Linux 4.19.0-12-amd64
18122 verbose argv "/usr/bin/node" "/usr/share/npm/bin/npm-cli.js" "install"
"sb@latest" "--global" "--prefix" "/root/schlarbm/.npm/_npx/19136" "--loglevel"
"error" "--json"
18123 verbose node v10.21.0
18124 verbose npm  v6.14.8
18125 error code MODULE_NOT_FOUND
18126 error Cannot find module './get-uid-gid.js'
18127 verbose exit [ 1, true ]



-- System Information:
Debian Release: 10.6
  APT prefers stable-updates
  APT policy: (700, 'stable-updates'), (700, 'stable'), (60, 'testing'), (50, 
'unstable')
Architecture: amd64 (x86_64)

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

Versions of packages node-uid-number depends on:
ii  nodejs  10.21.0~dfsg-1~deb10u1

node-uid-number recommends no packages.

node-uid-number suggests no packages.

Bug#973361: libassimp-dev: CMake target "assimp::assimp" is broken

[Timo Röhling]

Package: libassimp-dev
Version: 5.0.1~ds0

Dear maintainer,

The CMake target "assimp::assimp" is broken and cannot be used:

>   Imported target "assimp::assimp" includes non-existent path
>
>     "/usr/lib/include"
>
>   in its INTERFACE_INCLUDE_DIRECTORIES.  Possible reasons include:
>
>   * The path was deleted, renamed, or moved to another location.
>
>   * An install or uninstall procedure did not complete successfully.
>
>   * The installation package was faulty and references files it does
not provide.

As far as I can tell, this happens because debian/rules explicitly sets
-DASSIMP_LIB_INSTALL_DIR=lib/$(DEB_HOST_MULTIARCH) for Multi-Arch
support, but assimpTargets.cmake.in computes the install prefix by
always removing three directory levels from the CMake config location,
ending up in /usr/lib instead of /usr (lines 45-48).

Cheers
Timo

Bug#972702: ruby-bundler: dependency resolution fails for compiled gems

[Antonio Terceiro]

On Thu, Oct 29, 2020 at 11:17:59AM +0100, David Rodríguez wrote:
> Hi!
> 
> Just to clarify why I prefer the second solution, I think what debian does is 
> shipping precompiled versions of extensions, so technically the gemspec 
> shipped in the debian should include no extensions at all. This is something 
> some upstream gems already do. Take, for example, google-protobuf. It has a 
> precompiled version for linux: 
> https://rubygems.org/gems/google-protobuf/versions/3.13.0-x86_64-linux. If we 
> fetch and unpack this package, we can see it includes the prebuilt `.so` 
> extension, but no extensions in its gemspec:
> 
> $ gem fetch google-protobuf
> Fetching google-protobuf-3.13.0-x86_64-linux.gem
> Downloaded google-protobuf-3.13.0-x86_64-linux
> 
> $ gem unpack google-protobuf-3.13.0-x86_64-linux.gem
> Unpacked gem: 
> '/home/deivid/Code/playground/google-protobuf-3.13.0-x86_64-linux'
> 
> $ find google-protobuf-3.13.0-x86_64-linux -name '*.so'
> google-protobuf-3.13.0-x86_64-linux/lib/google/2.6/protobuf_c.so
> google-protobuf-3.13.0-x86_64-linux/lib/google/2.4/protobuf_c.so
> google-protobuf-3.13.0-x86_64-linux/lib/google/2.7/protobuf_c.so
> google-protobuf-3.13.0-x86_64-linux/lib/google/2.5/protobuf_c.so
> google-protobuf-3.13.0-x86_64-linux/lib/google/2.3/protobuf_c.so
> 
> $ gem unpack google-protobuf-3.13.0-x86_64-linux.gem --spec && grep 
> extensions google-protobuf-3.13.0-x86_64-linux.gemspec
> extensions: []
> 
> I think the cleanest solution would be for debian to do the same thing.

Fair enough. Now that I think about it, extensions is supposed to be
a list of extensions that need to be built, so indeed dropping it from
the gemspec included in the Debian packages make sense.

Thanks!


signature.asc
Description: PGP signature

Bug#973360: ITP: r-cran-gamm4 -- GNU R generalized additive mixed models using 'mgcv' and 'lme4'

[Andreas Tille]

Package: wnpp
Severity: wishlist

Subject: ITP: r-cran-gamm4 -- GNU R generalized additive mixed models using 
'mgcv' and 'lme4'
Package: wnpp
Owner: Andreas Tille 
Severity: wishlist

* Package name: r-cran-gamm4
  Version : 0.2
  Upstream Author : Simon Wood, Fabian Scheipl
* URL : https://cran.r-project.org/package=gamm4
* License : GPL-2+
  Programming Lang: GNU R
  Description : GNU R generalized additive mixed models using 'mgcv' and 
'lme4'
 Estimate generalized additive mixed models via a version of
 function gamm() from 'mgcv', using 'lme4' for estimation.

Remark: This package is maintained by Debian R Packages Maintainers at
   https://salsa.debian.org/r-pkg-team/r-cran-gamm4