Bug#977469: matplotlib: Please make package bootstrappable

[Sandro Tosi]

On Fri, Dec 18, 2020 at 2:27 AM John Paul Adrian Glaubitz
 wrote:
>
> On 12/18/20 2:44 AM, Sandro Tosi wrote:
> >> It seems that most of the Python dependencies in Build-Depends in 
> >> debian/control
> >> are optional when comparing those with the build dependencies in openSUSE 
> >> [1].
> >
> > they are not: they are either used to run tests or build the documentation.
>
> Well, that actually means they are optional for building the package. They 
> should
> be marked as  then or 

many of these b-d predate the introduction (or wide-spread use) of
build profiles and recently introduced b-d are being tagged, so this
is an unhelpful comment.

>
> >> I used the brute-force approach now and it built for me on powerpc with 
> >> those
> >> packages set to :
> >>
> >>python3-all-dbg,
> >>python3-all-dev,
> >>python3-cairocffi [!ia64] ,
> >>python3-certifi (>= 2020.6.20-1) ,
> >>python3-colorspacious ,
> >>python3-cxx-dev ,
> >>python3-cycler (>= 0.10.0) ,
> >>python3-dateutil ,
> >>python3-gi ,
> >>python3-ipython  ,
> >>python3-ipywidgets ,
> >>python3-kiwisolver ,
> >>python3-kiwisolver-dbg ,
> >>python3-mock ,
> >>python3-nose ,
> >>python3-numpy ,
> >>python3-numpy-dbg ,
> >>python3-numpydoc ,
> >>python3-pandas  ,
> >>python3-pil ,
> >>python3-pkg-resources ,
> >>python3-pyparsing (>= 1.5.6) ,
> >>python3-pyqt5 [!hurd-i386] ,
> >>python3-pytest ,
> >>python3-scipy  ,
> >>python3-setuptools,
> >>python3-six (>= 1.4) ,
> >>python3-sphinx  ,
> >>python3-sphinx-copybutton  ,
> >>python3-sphinxcontrib.svg2pdfconverter  ,
> >>python3-tk ,
> >>python3-tk-dbg ,
> >>python3-tornado ,
> >
> > this is not good enough, you just marked !stage1 for all the packages
> > that were on your way. please rework this patch to mark each of those
> > as either !nodoc or !nocheck where appropriate and run the build with
> > both profiles disabled; at that point i will be able to merge this.
>
> As Samuel already pointed out, the main problem is the incorrect use of
> the build profile markers. It should be  not 
> .

which, btw, you suggested in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=954071

>
> So, if you could fix this for the time being, we'd already be a step further.

are you saying that is the only problematic b-d that prevents
matplotlib bootstrap?

-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Bug#976918: memkind: FTBFS on ppc64el: GetArenaTest.test_TC_MEMKIND_ThreadHash failed

[Adam Borowski]

Control: tags -1 + moreinfo unreproducible

Hi Lucas!

> On Wed, Dec 09, 2020 at 09:39:08AM +0100, Lucas Nussbaum wrote:
> > Source: memkind

> > During a rebuild of all packages in sid, your package failed to build
> > on ppc64el. At the same time, it did not fail on amd64.
> 
> > I'm marking this bug as severity:serious since your package currently has
> > ppc64el binary packages in unstable (so this is a regression).

> > > [ RUN  ] GetArenaTest.test_TC_MEMKIND_ThreadHash
> > > test/get_arena_test.cpp:67: Failure
> > > Expected: (max_collisions) <= (collisions_limit), actual: 10 vs 5
> > > [  FAILED  ] GetArenaTest.test_TC_MEMKIND_ThreadHash (184 ms)

Ping:
> Is that fail reproducible for you?  I have a possible fix, but have no way
> of verifying it -- the package builds successfully on all machines I have
> access to, and did build fine on buildds (no major changes to toolchain
> since then).

The underlying code uses an assumption on the internal working for glibc,
that might possibly be invalid in some cases.  Even if it happens to be
wrong, correctness is not violated, there's just a performance loss.

The test that fails could thus be removed -- however, I'd like to know how
it did fail in the first place.  No matter how I tried, I did not manage to
reproduce the failure.

There are also multiple ways to improve this hash (an explicit mapping, a
"random" hash, etc) but as this code is used in large performance-critical
parts, I'd prefer to first understand.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ .--[ Makefile ]
⣾⠁⢠⠒⠀⣿⡁ # beware of races
⢿⡄⠘⠷⠚⠋⠀ all: pillage burn
⠈⠳⣄ `

Bug#977469: matplotlib: Please make package bootstrappable

[John Paul Adrian Glaubitz]

On 12/18/20 2:44 AM, Sandro Tosi wrote:
>> It seems that most of the Python dependencies in Build-Depends in 
>> debian/control
>> are optional when comparing those with the build dependencies in openSUSE 
>> [1].
> 
> they are not: they are either used to run tests or build the documentation.

Well, that actually means they are optional for building the package. They 
should
be marked as  then or 

>> I used the brute-force approach now and it built for me on powerpc with those
>> packages set to :
>>
>>python3-all-dbg,
>>python3-all-dev,
>>python3-cairocffi [!ia64] ,
>>python3-certifi (>= 2020.6.20-1) ,
>>python3-colorspacious ,
>>python3-cxx-dev ,
>>python3-cycler (>= 0.10.0) ,
>>python3-dateutil ,
>>python3-gi ,
>>python3-ipython  ,
>>python3-ipywidgets ,
>>python3-kiwisolver ,
>>python3-kiwisolver-dbg ,
>>python3-mock ,
>>python3-nose ,
>>python3-numpy ,
>>python3-numpy-dbg ,
>>python3-numpydoc ,
>>python3-pandas  ,
>>python3-pil ,
>>python3-pkg-resources ,
>>python3-pyparsing (>= 1.5.6) ,
>>python3-pyqt5 [!hurd-i386] ,
>>python3-pytest ,
>>python3-scipy  ,
>>python3-setuptools,
>>python3-six (>= 1.4) ,
>>python3-sphinx  ,
>>python3-sphinx-copybutton  ,
>>python3-sphinxcontrib.svg2pdfconverter  ,
>>python3-tk ,
>>python3-tk-dbg ,
>>python3-tornado ,
> 
> this is not good enough, you just marked !stage1 for all the packages
> that were on your way. please rework this patch to mark each of those
> as either !nodoc or !nocheck where appropriate and run the build with
> both profiles disabled; at that point i will be able to merge this.

As Samuel already pointed out, the main problem is the incorrect use of
the build profile markers. It should be  not 
.

So, if you could fix this for the time being, we'd already be a step further.

Adrian

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

Bug#977337: [Pkg-nagios-devel] Bug#977337: icingaweb2: Not compatible with php8.0

[Sebastiaan Couwenberg]

icingaweb2 (2.8.2-2~exp1) currently available in experimental mostly
works with php8.0, but the dashboard does not.

The browser console shows:

 Uncaught ReferenceError: Icinga is not defined

This appears to be caused by the JShrink failing,
from the apache error log:

 PHP Fatal error:  Maximum execution time of 30 seconds exceeded in
/usr/share/icingaweb2/library/vendor/JShrink/Minifier.php on line 292

Kind Regards,

Bas

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

Bug#977643: equivs: Can't specify spoofed package version

[5990]

Package: equivs

Version: 2.2.0

I can't manage to specify a package version on the template. In my particular 
case, I'm trying to fake a python version (I've already installed it through 
pyenv, so it's not recognized as an actual package), so I can install 
`python-dev (stable 2.7.16-1 amd64)` and get the damn `Python.h` to compile and 
install `pybluez`.

Anyway, I've tried with:
```
Provides: python 2.7.16-1
Provides: python: 2.7.16-1
Provides: python=2.7.16-1
Provides: python="2.7.16-1"
```

But when runing `equivs-build fakePython2.7.16` it's always rejected with some 
variant of:
`dpkg-gencontrol: warning: can't parse dependency python="2.7.16-1"`

Where the full contents of `fakePython2.7.16` are:
```
### Commented entries have reasonable defaults.
### Uncomment to edit them.
Source: fake.python
Section: misc
Priority: optional
# Homepage: 
Standards-Version: 3.9.2

Package: fake-python
Version: 1.1
# Maintainer: Your Name 
# Pre-Depends: 
# Depends: 
# Recommends: 
# Suggests: 
Provides: python="2.7.16-1", libpython-dev, python2.7-dev, python2-dev
# Replaces: 
# Architecture: all
# Multi-Arch: 
# Copyright: 
# Changelog: 
# Readme: 
# Extra-Files: 
# Links: 
# Files: 
# 
Description: 
long description and info
.
second paragraph
```

I've tried reading the source code of dpkg-gencontrol, but I just can't wrap my 
head around pearl (╯°□°）╯︵ ┻━┻
Any help would be greatly apreciated q.q

-- System Information:
Linux kali 5.8.0-kali3-amd64 #1 SMP Debian 5.8.14-1kali1 (2020-10-13) x86_64 
GNU/Linux

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

Bug#882584: openboard on Debian 10.7 build success

[肖盛文]

I'm on debian/Buster 10.7 + buster-backports (desktop and laptop) and confirms 
that openboard is working, not perfect, but good.

I also use these steps:

  $ git clone https://salsa.debian.org/debian-edu-pkg-team/openboard.git 

  $ cd openboard
  $ debian/rules get-orig-source
  $ debuild -uc -us -S -Zxz -d
  $ dpkg-source -x openboard_.dsc
  $ cd openboard-
  $ debuild -uc -us



-- 
肖盛文 xiao sheng wen Faris Xiao 
微信(wechat)：atzlinux
《铜豌豆 Linux》 
基于 Debian 的 Linux 中文桌面操作系统：https://www.atzlinux.com
Debian QA page: https://qa.debian.org/developer.php?login=atzlinux%40sina.com
GnuPG Public Key: 0x339240CB



OpenPGP_signature
Description: OpenPGP digital signature

Bug#973459: uim: FAIL: test-composer.scm

[Takatsugu Nokubi]

https://salsa.debian.org/debian/uim/-/merge_requests/9

This is the fix request.
Could you review the patch?


2020年12月14日(月) 18:24 :

> On Sun, Dec 13, 2020 at 02:35:58PM +0900, Takatsugu Nokubi wrote:
> > I made a simple patch to skip test-composer:
> >
> https://salsa.debian.org/debian/uim/-/commit/3cd351b6f2b15fb3161e1d00ed4c8ba26925429b
> > (Oh, I forgot to fix description of the patch)
>
> Thank you for your work.
> Please upload after description fix.
> --
> Regards,
> dai
>
> GPG Fingerprint = 0B29 D88E 42E6 B765 B8D8 EA50 7839 619D D439 668E
>

Bug#788666: [bts-link] source package liferea

[Paul Wise]

On Thu, 2020-12-17 at 21:18 +0100, Paul Gevers wrote:

> Sub-optimal, but upstream decided to close the Debian bugs that I
> forwarded. I don't think it makes sense to keep them open in the BTS
> any longer.

Fair enough, I'll file new issues upstream if I see crashes again.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#977648: Purging package noninteractively loops on 'No PAM profiles have been selected.'

[Josh Triplett]

Package: libpam-runtime
Version: 1.3.1-5
Severity: normal
X-Debbugs-Cc: j...@joshtriplett.org

As part of an mmdebstrap chroot creation for an embedded application
that will never have any interactive users or logins, I tried to purge
the libpam-runtime package
(dpkg --force-remove-essential --force-depends --purge libpam-runtime).
This resulted in the following:

Removing libpam-runtime (1.3.1-5) ...
PAM configuration
-

No PAM profiles have been selected.

No PAM profiles have been selected for use on this system.  This would
grant all users access without authenticating, and is not allowed.  Please
select at least one PAM profile from the available list.

No PAM profiles have been selected.

No PAM profiles have been selected for use on this system.  This would
grant all users access without authenticating, and is not allowed.  Please
select at least one PAM profile from the available list.

No PAM profiles have been selected.
...


It loops at this point, producing output continuously.

I realize that this is an essential package, but it does have a prerm
and postrm script, and on a system with absolutely no usage of PAM it
should be posible to remove without encountering an infinite loop like
this.

I can reliably reproduce this.

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

Kernel: Linux 5.9.0-4-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: systemd (via /run/systemd/system)

Versions of packages libpam-runtime depends on:
ii  debconf [debconf-2.0]  1.5.74
ii  libpam-modules 1.3.1-5

libpam-runtime recommends no packages.

libpam-runtime suggests no packages.

-- debconf information excluded

Bug#977647: 5.10.1 Debian kernel does not boot on amd64 with btrfs rootfs

[Ryutaroh Matsumoto]

Package: linux-image-5.10.0-trunk-amd64-unsigned
Version: 5.10.1-1~exp1
Severity: grave
Justification: renders package unusable

Dear Debian kernel maintainers,

Debian kernel 5.10.1 in experimental does not boot on my x86_64 notebook
with btrfs rootfs.
As I am suspecting btrfs as
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=977645

This strengthen my suspicion about 5.10.1 btrfs...

Photo of booting console is found at
https://photos.app.goo.gl/zyCg4ZH8zDgwoiBr8

We observe that systemd accessed some files in btrfs rootfs,
so the situation seems somewhat better than
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=977645

Best regards, Ryutaroh Matsumoto

Bug#976887: texlive-base: Should not migrate to testing for now.

[Norbert Preining]

clone 976887 -1
reassign -1 texlive-formats-extra
retitle -1 jadetex does not work with newer latex kernel
block 976887 -1
thanks

Cloning and reassigning the bug. Fix is prepared and uploaded after bug
number assigned.

Thanks

On Wed, 09 Dec 2020, Hilmar Preusse wrote:
> Package: texlive-base
> Version: 2020.20201203-2
> Severity: serious
> 
> Dear Maintainer,
> 
> The new texlive-base has an impact on docbook based documentations,
> see
> 
> https://bugs.debian.org/976475
> https://bugs.debian.org/976508
> https://bugs.debian.org/976519
> https://bugs.debian.org/976535
> https://bugs.debian.org/976538
> https://bugs.debian.org/976544
> https://bugs.debian.org/976547
> https://bugs.debian.org/976554
> https://bugs.debian.org/976556
> https://bugs.debian.org/976574
> https://bugs.debian.org/976586
> 
> Prevent it from migration to testing for now until the issue is sorted
> out.
> 
> Hilmar

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

Bug#977645: 5.10.1 Debian kernel does not boot on raspi 4 with ext4 rootfs and sdcard

[Ryutaroh Matsumoto]

Package: linux-image-5.10.0-trunk-arm64-unsigned
Version: 5.10.1-1~exp1
Severity: grave
Justification: renders package unusable

Dear Debian kernel maintainers,

Debian kernel 5.10.1 in experimental does not boot on my raspberry pi 4.
I tried to boot it from an SD card with ext4 root partition.
Partitioining is msdos (not gpt).

I was always able to boot it in the same configuration,
when I used my compiled vanilla 5.10.1 or "git clone"'ning from salsa.debian.

When I use vanilla or salsa.debian.org 5.10.1, booting ALWAYS fails
if rootfs is btrfs.

Photo of boot console is found at
https://photos.app.goo.gl/A755wZKvqneX1WvY6

We observe that booting fails at btrfs.
To me, 5.10.1 btrfs looks very suspicious...

I will see if what will happen with x86_64 with btrfs rootfs...

Best regards, Ryutaroh Matsumoto

Bug#977333: klayout: Vcs-* headers inaccurate

[Vagrant Cascadian]

Control: retitle 977333 klayout: Vcs-* headers inaccurate

On 2020-12-13, Vagrant Cascadian wrote:
> The Vcs headers in debian/control do not point to a publicly accessible
> git repository:
>
>   Vcs-Browser: https://salsa.debian.org/electronics-team/klayout
>   Vcs-Git: https://salsa.debian.org/electronics-team/klayout.git
>
> Please update the Vcs repository or update the Vcs headers in
> debian/control to point to the current respository and/or branch.
>
> Thanks for maintaining klayout!
>
> live well,
>   vagrant


signature.asc
Description: PGP signature

Bug#977643: equivs: Can't specify spoofed package version

[Axel Beckert]

Hi,

5990 wrote:
> Anyway, I've tried with:
> ```
> Provides: python 2.7.16-1
> Provides: python: 2.7.16-1
> Provides: python=2.7.16-1
> Provides: python="2.7.16-1"

These are all the wrong syntax. Please try to use the syntax for
dependencies (and provides) in Debian packages:

Provides: python (= 2.7.16-1)

(The blank after the equal sign is optional.)

The format and syntax are documented in the Debian Policy, e.g. here:
https://www.debian.org/doc/debian-policy/ch-relationships.html

So from my point of view this is not really a bug. It though suggests
that there is a proper reference to the Debian policy for the format
of some fields missing.

Do you have any suggestion where to add such a reference? Where in the
equivs documentation did you look for such information?

> Where the full contents of `fakePython2.7.16` are:
> ```
[…]
> Description: 
> long description and info
> .
> second paragraph
> ```

For me equivs-build bails out earlier with that control file:

  syntax error in control file: long description and info

In the last three lines (i.e. those after the line starting with
"Description:"), there must be at least one white space before every
line of the description. E.g. it should look like this:

Description: 
 long description and info
 .
 second paragraph

But maybe that was just a mail client or editor issue.

> Linux kali 5.8.0-kali3-amd64 #1 SMP Debian 5.8.14-1kali1
> (2020-10-13) x86_64 GNU/Linux

Kali should have much newer version of equivs than 2.2.0. It should
have 2.3.1.

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

Bug#977579: Yes, Andreas helped (Was: Bug#977579: gnumeric: Please ask upstream...)

[Kingsley G. Morse Jr.]

On 12/18/2020 09:58, Dmitry Smirnov wrote:
> On Thursday, 17 December 2020 3:22:28 PM AEDT Kingsley G. Morse Jr. wrote:
> > Thank you very much for maintaining gnumeric!
> 
> Thank you for your kind words.

You're welcome!

And thanks for the links to 

1.) Andreas' report of now()'s issue today at

https://gitlab.gnome.org/GNOME/gnumeric/-/issues/549


2.) and arguably the very important data about
COVID-19 lockdowns surprisingly INcreasing
mortality at 


https://medium.com/@JohnPospichal/questions-for-lockdown-apologists-32a9bbf2e247

My quick and dirty search for rebutals to it
at duckduckgo.com suggests it hasn't been
refuted!


Keep up the good work and HAPPY HOLIDAYS!
Kingsley

-- 
Time is the fire in which we all burn.

Bug#977644: RM: cloudprint -- ROM; Web service is deprecated

[David Steele]

Package: ftp.debian.org
Severity: normal
Control: affects -1 cloudprint
thanks

Please remove the source package "cloudprint" from sid. it supports the 
Google Cloud Print service, which is going offline at the end of 2020 [1].


Cloudprint sources the binary packages "cloudprint" and 
"cloudprint-service".


[1]: https://support.google.com/chrome/answer/1069693



OpenPGP_signature
Description: OpenPGP digital signature

Bug#975921: mali-midgard: Contains auto-generated file without corresponding source

[Wookey]

Not had an answer on how this is generated yet, but so far as I can
tell the consensus is that no-one really cares about this driver being
in debian now that the free drivers are in reasonable shape so
probably best to just quietly let this die.

I guess I should file a removal request.

Wookey
-- 
Principal hats:  Linaro, Debian, Wookware, ARM
http://wookware.org/


signature.asc
Description: PGP signature

Bug#977469: matplotlib: Please make package bootstrappable

[Sandro Tosi]

> It seems that most of the Python dependencies in Build-Depends in 
> debian/control
> are optional when comparing those with the build dependencies in openSUSE [1].

they are not: they are either used to run tests or build the documentation.

> I used the brute-force approach now and it built for me on powerpc with those
> packages set to :
>
>python3-all-dbg,
>python3-all-dev,
>python3-cairocffi [!ia64] ,
>python3-certifi (>= 2020.6.20-1) ,
>python3-colorspacious ,
>python3-cxx-dev ,
>python3-cycler (>= 0.10.0) ,
>python3-dateutil ,
>python3-gi ,
>python3-ipython  ,
>python3-ipywidgets ,
>python3-kiwisolver ,
>python3-kiwisolver-dbg ,
>python3-mock ,
>python3-nose ,
>python3-numpy ,
>python3-numpy-dbg ,
>python3-numpydoc ,
>python3-pandas  ,
>python3-pil ,
>python3-pkg-resources ,
>python3-pyparsing (>= 1.5.6) ,
>python3-pyqt5 [!hurd-i386] ,
>python3-pytest ,
>python3-scipy  ,
>python3-setuptools,
>python3-six (>= 1.4) ,
>python3-sphinx  ,
>python3-sphinx-copybutton  ,
>python3-sphinxcontrib.svg2pdfconverter  ,
>python3-tk ,
>python3-tk-dbg ,
>python3-tornado ,

this is not good enough, you just marked !stage1 for all the packages
that were on your way. please rework this patch to mark each of those
as either !nodoc or !nocheck where appropriate and run the build with
both profiles disabled; at that point i will be able to merge this.

Regards,
-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Bug#763419: apt ignoring check-valid-until flag

[Calum McConnell]

On Fri, 2020-12-18 at 01:15 +, Paul Wise wrote:
> On Thu, Dec 17, 2020 at 10:03 AM Ansgar wrote:
> 
> >     (Bonus points if this keeps the original signature if possible.)
> 
> Two separate signatures is possible for Release+Release.gpg, just
> rename the latter to .old, but what can you do for InRelease? Is it
> possible to have multiple signatures in one blob of signing data? Is
> it possible to take an existing signature and add a second one to it?
> Can the same thing be done for Release.gpg? Do apt, gpg and gpgv cope
> with this sort of thing?
> 

Okay, so maybe my deep dive into old Debian versions was worth it.

If you look at Etch, you will see a Release.gpg with two signatures.  Per
the Etch-era Debian Wiki page on this[1], that's because it was decided
that Etch should be signed with both the 2005 and the 2006, to keep an
upgrade path in place.  Now, due to a bug in apt (fixed in 0.6.43.1), the
systems began to expect both keys to be present, but assuming that there
hasn't been any regressions in that, I believe Apt will work as intended
if we add new signatures by appending them onto the release.gpg.   Apt was
totally fine processing the Etch release file when I tested it: it
complained separately about each key being expired, implying that it would
work of a third, unexpired key was in that list.

Calum

[1]: https://wiki.debian.org/SecureApt#Debian_archive_key_expiry


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

Bug#977438: linux: Pls. consider DRM_VC4_HDMI_CEC

[Ryutaroh Matsumoto]

Control: retitle -1 Pls. consider DRM_VC4_HDMI_CEC

I change the issue title following suggestion by Vinent.

From: Ryutaroh Matsumoto 
Subject: Re: Bug#977438: linux: Pls. consider DRM_VC4_HDMI_CEC
Date: Fri, 18 Dec 2020 09:30:49 +0900 (JST)

> Hi Vincent,
> 
> Thank you for your attention and MR.
> 
>> I see that in a follow-up
>> email you're asking for more configuration options to be enabled; It
>> would probably be better to open a new bug report for those.
> 
> I will do so, after a 5.10.x package enters into experimental or unstable,
> I built a Debian kernel pkg with proposed config, and test it.
> 
> Best regards, Ryutaroh

Bug#977642: 5.10 kernel needs disable_fw_kms_setup=1

[Ryutaroh Matsumoto]

Package: raspi-firmware
Version: 1.20201022-1
Severity: normal
X-Debbugs-CC: lu...@debian.org

Dear Debian raspi-firmware maintainers,

Linux 5.10 kernel's vc4.ko starts partial support of RPi 2/3/4 VideoCore 4 GPU,
and it enables 4K HDMI output, which is very welcome.

But in some situation, screen output is garbled as reported at
http://lists.infradead.org/pipermail/linux-rpi-kernel/2020-November/007894.html

The above symptom can be fixed by adding disable_fw_kms_setup=1 as
reported at
http://lists.infradead.org/pipermail/linux-rpi-kernel/2020-November/007900.html

I do not think this is a bug in raspi-firmware, but config.txt is handled by
raspi-firmware, please consider to add disable_fw_kms_setup=1.

Best regards, Ryutaroh Matsumoto

Bug#977321: O: autoconf2.13 -- automatic configure script builder (obsolete version)

[Axel Beckert]

Hi Ben,

Ben Pfaff wrote:
> This package is really obsolete.  It has several bug reports but the
> right thing to do is probably to get any packages that use autoconf2.13
> updated to use something else.  (Or removed; they are antiques
> themselves.)

While I hoped that you are right, there seem at least two big blockers
on a first glance: Firefox and Thunderbird.

I tried to make a quick list of affected packages:

→ grep-dctrl -s Package -FBuild-Depends,Build-Depends-Indep,Build-Depends-Arch 
autoconf2.13 /var/lib/apt/lists/*Source* | fgrep Package | sort -u
Package: firefox
Package: firefox-esr
Package: gcc-3.3
Package: gcc-m68hc1x
Package: grass
Package: maxima
Package: mozjs52
Package: mozjs78
Package: postgis
Package: thunderbird
Package: vflib3
Package: xemacs21

And yeah, some packages in this list are really old. gcc-3.3 recently
has been orphaned for similar reasons: https://bugs.debian.org/966317

So I tried to figure out which versions of Firefox and Thunderbird
exactly are affected and it started to look less bad:

→ apt-cache showsrc firefox firefox-esr thunderbird | egrep 
'Package:|autoconf|Version:|^$' | sed -e 's/autoconf2\.13.*/autoconf2\.13, …/g'
Package: firefox
Version: 81.0-2
Build-Depends: autotools-dev, debhelper (>= 9.20160114), autoconf2.13, …
Standards-Version: 3.9.8.0

Package: firefox
Version: 82.0.3-1
Standards-Version: 3.9.8.0

Package: firefox
Version: 83.0-1
Standards-Version: 3.9.8.0

Package: firefox
Version: 84.0-1
Standards-Version: 3.9.8.0

Package: firefox-esr
Version: 78.5.0esr-1
Build-Depends: autotools-dev, debhelper (>= 9.20160114), autoconf2.13, …
Standards-Version: 3.9.8.0

Package: firefox-esr
Version: 78.6.0esr-1
Build-Depends: autotools-dev, debhelper (>= 9.20160114), autoconf2.13, …
Standards-Version: 3.9.8.0

Package: thunderbird
Version: 1:78.5.1-1
Build-Depends: autoconf2.13, …
Standards-Version: 4.5.1

Package: thunderbird
Version: 1:78.6.0-1
Build-Depends: autoconf2.13, …
Standards-Version: 4.5.1

Package: thunderbird
Version: 1:84.0~b3-1
Build-Depends: autoconf2.13, …
Standards-Version: 4.5.1

So while the current Firefox-ESR and Thunderbird are affected, the
Firefox from version 82 onwards seem to no more be affected. (The list
contains versions from Unstable, Experimental and Testing.)

But then again Thunderbird 84 still is using autoconf2.13. So
hopefully the latter can be fixed by just replacing the
build-dependency and maybe some minor other tweaks.

So in the end, removing autoconf2.13 doesn't look too hard, but still
might need some time and work.

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

Bug#763419: apt ignoring check-valid-until flag

[Paul Wise]

On Thu, Dec 17, 2020 at 10:03 AM Ansgar wrote:

> (Bonus points if this keeps the original signature if possible.)

Two separate signatures is possible for Release+Release.gpg, just
rename the latter to .old, but what can you do for InRelease? Is it
possible to have multiple signatures in one blob of signing data? Is
it possible to take an existing signature and add a second one to it?
Can the same thing be done for Release.gpg? Do apt, gpg and gpgv cope
with this sort of thing?

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Bug#977387: python-lxml: [security regression] AttributeError when importing lxml.html.clean

[Stefan Ehmann]

There is an upstream fix available:

https://github.com/lxml/lxml/commit/4cb57362deb23bca0f70f41ab1efa13390fcdbb1

Bug#977438: linux: Pls. consider DRM_VC4_HDMI_CEC

[Ryutaroh Matsumoto]

Hi Vincent,

Thank you for your attention and MR.

> I see that in a follow-up
> email you're asking for more configuration options to be enabled; It
> would probably be better to open a new bug report for those.

I will do so, after a 5.10.x package enters into experimental or unstable,
I built a Debian kernel pkg with proposed config, and test it.

Best regards, Ryutaroh

Bug#977641: fckit: reproducible builds: Embeds running kernel in /usr/bin/fckit

[Vagrant Cascadian]

Source: fckit
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: kernel
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

The running kernel is embedded in /usr/bin/fckit:

  
https://tests.reproducible-builds.org/debian/rb-pkg/bullseye/i386/diffoscope-results/fckit.html

  echo·"··op.·system··:·Linux-4.19.0-12-amd64·(linux.32)"
  echo·"··op.·system··:·Linux-4.19.0-12-686-pae·(linux.32)"


The attached patch fixes by changing the call to "uname -sr" (e.g. Linux
4.19.0-13-amd64) to simply "uname -s" (e.g. Linux).


Thanks for maintaining fckit!


live well,
  vagrant
From 28c0a13e5aaa8875fc516695c94114d506984740 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Thu, 17 Dec 2020 23:44:52 +
Subject: [PATCH] src/apps/fckit.in: Use CMAKE_SYSTEM_NAME instead of
 CMAKE_SYSTEM.

CMAKE_SYSTEM captures the running kernel version.

https://tests.reproducible-builds.org/debian/issues/unstable/captures_kernel_version_via_CMAKE_SYSTEM_issue.html
---
 src/apps/fckit.in | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/apps/fckit.in b/src/apps/fckit.in
index 4a7d13e..5478ad6 100755
--- a/src/apps/fckit.in
+++ b/src/apps/fckit.in
@@ -42,7 +42,7 @@ info()
   echo ""
   echo "Build:"
   echo "  build type  : @CMAKE_BUILD_TYPE@"
-  echo "  op. system  : @CMAKE_SYSTEM@ (@EC_OS_NAME@.@EC_OS_BITS@)"
+  echo "  op. system  : @CMAKE_SYSTEM_NAME@ (@EC_OS_NAME@.@EC_OS_BITS@)"
   echo "  processor   : @CMAKE_SYSTEM_PROCESSOR@"
   echo "  c++ compiler: @CMAKE_CXX_COMPILER_ID@ @CMAKE_CXX_COMPILER_VERSION@"
   echo "  fortran compiler: @CMAKE_Fortran_COMPILER_ID@ @CMAKE_Fortran_COMPILER_VERSION@"
-- 
2.29.2



signature.asc
Description: PGP signature

Bug#977633: meson: support cups-config in debcrossgen

[Jussi Pakkanen]

On Thu, 17 Dec 2020 at 23:57, Helmut Grohne  wrote:

> cinnamon-settings-daemon fails to cross build from source, because meson
> fails to locate cups. meson tried methods pkg-config and config-tool.
> Unfortunately, cups upstream refuses to add a pkg-config file (see
> https://github.com/apple/cups/issues/3128) and the config-tool method
> refuses to use cups-config. The cups-config tool is architecture
> agnostic and can very well be used during cross compilation. All we have
> to do is add it to the cross file. I've attached a patch for your
> convenience.

Thanks, this will be in the next point release, which should come out
fairly soon.

Bug#977512: src:libconfig-identity-perl: Build-Depends on old gnupg1, but could use gnupg2

[gregor herrmann]

On Thu, 17 Dec 2020 22:59:31 +0100, Chris Hofstaedtler wrote:


> > Some quick thoughts:
> > - OOC: Is gnupg1 going away, or what is the reason for this proposal?
> I have asked about this, but nobody is really pushing for gnupg1 to
> go away. However, it currently FTBFS, so lets see if it will be in
> bullseye.

I see, thank you.
 
> > Alright, changes pushed to 
> > https://salsa.debian.org/perl-team/modules/packages/libconfig-identity-perl.git
> > but I wouldn't mind a second (yours or someone else's :)) pair of
> > eyes before uploading.
> Thanks for taking care of this. I didn't get to look at your changes
> before the upload :-/

No worries, and thanks for checking now!
(We can always do another upload if necessary :))
 
> The "save test data" machinery looks correct to me. Even though I
> might have written the logic inverted - the double negation took me
> me some time to understand.

Maybe I'm wrong, but that's the way I'm used to do it - with the
background to ensure that we get a(n early) true result for the
evaluation in make context.

Cheers,
gregor

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


signature.asc
Description: Digital Signature

Bug#977640: x2goserver-x2goagent: Suspending a session results in the session log growing to fill the /tmp filesystem

[Anthony G]

Package: x2goserver-x2goagent
Version: 4.1.0.3-5
Severity: important
X-Debbugs-Cc: d...@ruant.ie

Dear Maintainer,

This is my first bug report to Debian so I’m hoping it’s useful.  Please
let me know if there are issues (e.g., missing necessary details) with
it or how I might otherwise improve this report.

   * What led up to the situation?

I’ve been successfully using X2Go to run graphical applications on my
home Debian server for the past six months. I’ve never needed to know
much about how X2Go works as everything “just works” (like everything
else on Debian stable). About a month ago, I needed to use newer
software libraries so I changed my sources to use `testing` instead of
`stable`.


   * What exactly did you do (or not do) that was effective (or
 ineffective)?

Since upgrading to `testing`, when I suspend a session from the client,
the X2Go session stays running on the server (as you’d expect) but the
`session.log` (e.g,
`/tmp/.x2go-ant/C-ant-55-1607301555_stDLXDE_dp32/session.log` has the
following line appended to it:

nxagentPendingEvents: Returning error with display down.

I found that this line was being appended to the log file at the rate of
23786/second!  Connecting via SSH and running the `fuser` utility shows
that the process writing to is `x2goagent` (which is provided by the
`x2goserver-x2goagent` Debian package).

The session log file continues to grow and the /tmp filesystem
completely fill up (I’m now going to create a separate filesystem but
currently my /tmp is on my root filesystem and lots of services break
when this runs out of space).

After re-connecting, some sort of internal house-keeping code kicks in and
the size of the log file drops back to a much smaller size.


   * What outcome did you expect instead?

I suppose that I’d expect the server agent’s internal house-keeping to
prevent this log file from growing too large when a session is suspended
and there is no active display.


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

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

Versions of packages x2goserver-x2goagent depends on:
ii  nxagent  2:3.5.99.25-1

x2goserver-x2goagent recommends no packages.

Versions of packages x2goserver-x2goagent suggests:
ii  x2goserver  4.1.0.3-5

-- no debconf information

Bug#977617: udev: Failed to set up mount namespacing: Permission denied - after unattended-upgrade udev:amd64 241-7~deb10u5

[Michael Biebl]

Am 18.12.20 um 00:03 schrieb Michael Biebl:

control: tags -1 + moreinfo

Am 17.12.20 um 21:13 schrieb whil...@be-ext.globenet.org:
Failed at step NAMESPACE spawning /lib/systemd/systemd-udevd: 
Permission denied


Are you using selinux?


Or AppArmor?






OpenPGP_signature
Description: OpenPGP digital signature

Bug#977469: matplotlib: Please make package bootstrappable

[John Paul Adrian Glaubitz]

On 12/17/20 11:55 PM, Samuel Thibault wrote:
> John Paul Adrian Glaubitz, le jeu. 17 déc. 2020 23:47:42 +0100, a ecrit:
>> You just solved that mystery for me. I was already starting to question
>> my sanity when the --profile switch didn't work as expected :-).
> 
> It was driving me crazy in the past couple hours as well, I was
> questioning the support in sbuild, in pbuilder, and at the point of
> trying mk-build-deps with the nodoc profile instead of the stage1
> profile, I at last noticed that the  were working but not the
>   :)

I guess we'll just need to fix this bug then to make the package bootstrappable.

Adrian

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

Bug#977617: udev: Failed to set up mount namespacing: Permission denied - after unattended-upgrade udev:amd64 241-7~deb10u5

[Michael Biebl]

control: tags -1 + moreinfo

Am 17.12.20 um 21:13 schrieb whil...@be-ext.globenet.org:

Failed at step NAMESPACE spawning /lib/systemd/systemd-udevd: Permission denied


Are you using selinux?
Can you provide the dmesg/journal output from when the start failure 
happens?





OpenPGP_signature
Description: OpenPGP digital signature

Bug#977579: gnumeric: Please ask upstream to increase the precision of "=now()" to at least milliseconds.

[Dmitry Smirnov]

On Thursday, 17 December 2020 3:22:28 PM AEDT Kingsley G. Morse Jr. wrote:
> Thank you very much for maintaining gnumeric!

Thank you for your kind words.


> I'd like gnumeric's "=now()" time function to be
> more precise.

Upstream seems to have a relevant issue already. I've added a comment
to https://gitlab.gnome.org/GNOME/gnumeric/-/issues/549


> I tried to report this directly to the gnumeric
> guys at
> 
> https://gitlab.gnome.org/GNOME/gnumeric/-/issues
> 
> but it says
> 
> "new user registrations are disabled".

I think I've logged-in with my GitLab account (but GitHub should probably
work as well).

-- 
Kind regards,
 Dmitry Smirnov
 GPG key : 4096R/52B6BBD953968D1B

---

Questions for lockdown apologists
-- 
https://medium.com/@JohnPospichal/questions-for-lockdown-apologists-32a9bbf2e247



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

Bug#977639: bible-kjv: Possible GPL compliance problems

[Bastian Germann]

Package: bible-kjv
Version: 4.30
Severity: important

bible-kjv package claims to be GPLv2 licensed. One file has an "or 
later" clause but some files seem to GPLv2-only. However, with the 
switch to readline6 (#553733), it uses a GPLv3 library. GPLv3 and 
GPLv2-only are known to be incompatible licenses, so please build with 
libedit instead. A patch is enclosed.
From: Bastian Germann 
Date: Thu, 17 Dec 2020 23:37:12 +0100
Subject: Replace readline with libedit
---
diff a/Makefile b/Makefile
index 3b998b8..9f92ef4 100644
--- a/Makefile
+++ b/Makefile
@@ -90,7 +90,7 @@ DESTMAN1  = $(DESTMAN)/man1
 #CFLAGS	  = -g
 CFLAGS	  = -Wall -Wformat -Werror -Wshadow -W -Wmissing-declarations -Wmissing-prototypes -Wstrict-prototypes -Wcast-align -Wcast-qual -Wbad-function-cast -Wpointer-arith -g2 -ggdb -DDESTLIB=\"$(DESTLIB)\"
 LDFLAGS   = 
-LDADD = -lreadline
+LDADD = -ledit
 
 # release directories.  Nobody should care about this but me
 FTPHOME	  = /mnt/ftp
diff a/bible.c b/bible.c
index c399bb1..5aa7344 100644
--- a/bible.c
+++ b/bible.c
@@ -167,8 +167,8 @@
 #include 
 #include 
 #include 
-#include 
-#include 
+#include 
+#include 
 #include "tsl.h"
 #include "brl.h"
 #include "version.h"
diff a/debian/control b/debian/control
index 37f731b..852e96f 100644
--- a/debian/control
+++ b/debian/control
@@ -2,7 +2,7 @@ Source: bible-kjv
 Section: doc
 Priority: optional
 Maintainer: Matthew Vernon 
-Build-Depends: libreadline-dev
+Build-Depends: libedit-dev
 Standards-Version: 3.5.6
 
 Package: bible-kjv

Bug#977469: matplotlib: Please make package bootstrappable

[Samuel Thibault]

John Paul Adrian Glaubitz, le jeu. 17 déc. 2020 23:47:42 +0100, a ecrit:
> You just solved that mystery for me. I was already starting to question
> my sanity when the --profile switch didn't work as expected :-).

It was driving me crazy in the past couple hours as well, I was
questioning the support in sbuild, in pbuilder, and at the point of
trying mk-build-deps with the nodoc profile instead of the stage1
profile, I at last noticed that the  were working but not the
  :)

Samuel

Bug#977469: matplotlib: Please make package bootstrappable

[John Paul Adrian Glaubitz]

Hi Samuel!

On 12/17/20 11:39 PM, Samuel Thibault wrote:
> While at it:
> 
>python3-sphinx-gallery (>= 0.7.0)  ,
> 
> I believe you meant
> 
>python3-sphinx-gallery (>= 0.7.0) ,
> 
> So that the python3-sphinx-gallery dep is disable when using the stage1
> profile alone or when using the nodoc profile alone.

You just solved that mystery for me. I was already starting to question
my sanity when the --profile switch didn't work as expected :-).

Thanks a lot for pointer!

Adrian

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

Bug#977469: matplotlib: Please make package bootstrappable

[Samuel Thibault]

Hello,

While at it:

   python3-sphinx-gallery (>= 0.7.0)  ,

I believe you meant

   python3-sphinx-gallery (>= 0.7.0) ,

So that the python3-sphinx-gallery dep is disable when using the stage1
profile alone or when using the nodoc profile alone. Currently one has
to using both the stage1 and the nodoc profiles to break the

python3-matplotlib -> python3-sphinx-gallery -> python3-matplotlib

loop.

Samuel

Bug#977638: g++-10:s390x: Large classes of std::bitset and std::vector hash the same

[Benjamin Barenblat]

Package: g++-10
Version: 10.2.1-1
Severity: normal

On s390x, std::hash returns identical values for large classes of
std::bitset and std::vector:

$ cat bug.cc
#include 
#include 
#include 
#include 

int main() {
  std::bitset<2> a("00"), b("01");
  std::vector c = {false, true, false, true};
  std::vector d = {true, false, true, false};

  std::bitset<9> e("0"), f("010101010");
  std::vector g = {true, true, true, true, true, true, true, true, 
true};
  std::vector h = {false, false, false, true, true,
 false, false, false, false};

  std::hash> h1;
  std::hash> h2;
  std::hash> h3;

  std::cout << h1(a) << '\n'
<< h1(b) << '\n'
<< h3(c) << '\n'
<< h3(d) << "\n\n"
<< h2(e) << '\n'
<< h2(f) << '\n'
<< h3(g) << '\n'
<< h3(h) << '\n';
}
$ g++ -o bug bug.cc
$ ./bug
7857072875483051545
7857072875483051545
7857072875483051545
7857072875483051545

4158372090644325695
4158372090644325695
4158372090644325695
4158372090644325695

It appears that the hash value is completely dependent on the size of
the object in bytes. 1–8-bit values all hash to 7857072875483051545;
9–16-bit values all hash to 4158372090644325695; and though bug.cc
doesn’t demonstrate it, 17-bit values hash to 14756137038141193723.


signature.asc
Description: PGP signature

Bug#977637: libwebsockets: Please enable LWS_WITH_EXTERNAL_POLL support in libwebsockets

[Roger Light]

Package: libwebsockets
Severity: important

Dear Maintainer,

The libwebsockets support in Mosquitto requires the external poll
support, but this is not enabled in libwebsockets by default. Please
consider enabling it by adding LWS_WITH_EXTERNAL_POLL to the rules file.

Bug#977636: gitlab: Package upgrade hangs indefinitely and consumes all CPU/memory

[Maximilian Stein]

Package: gitlab
Version: 13.4.7-2~fto10+1
Severity: important

Dear Maintainer,

During an upgrade to version 13.4.7-1~fto10+1 or 13.4.7-2~fto10+1
there is a rake process in the postinst script that consumes 100 % cpu
and takes up a lot of memory but never finishes, even not after hours.
I finally killed the process with a SIGKILL, and gitlab seems to work
afterwards.

This is the last output I get during the installation:

 snip --

yarn install v1.22.4
[1/4] Resolving packages...
success Already up-to-date.
$ node ./scripts/frontend/postinstall.js

 
success Dependency postinstall check passed.
Done in 1.90s.   
WARNING on line 297, column 11 of 
/usr/share/gitlab/app/assets/stylesheets/framework/common.scss:
Compound selectors may no longer be extended.
Consider `@extend .card, .card-body` instead.
See http://bit.ly/ExtendCompound for details.   
 
WARNING on line 208, column 13 of 
/usr/share/gitlab/app/assets/stylesheets/framework/filters.scss:
Compound selectors may no longer be extended.
Consider `@extend .form-control, :hover` instead.
See http://bit.ly/ExtendCompound for details.   
  
 
WARNING on line 31, column 13 of 
/usr/share/gitlab/app/assets/stylesheets/pages/help.scss:
Compound selectors may no longer be extended.
Consider `@extend .badge, .badge-pill` instead.
See http://bit.ly/ExtendCompound for details.

WARNING on line 665, column 13 of 
/usr/share/gitlab/app/assets/stylesheets/pages/issuable.scss:
Compound selectors may no longer be extended.
Consider `@extend a, :hover` instead.
See http://bit.ly/ExtendCompound for details.

WARNING on line 580, column 15 of 
/usr/share/gitlab/app/assets/stylesheets/pages/pipelines.scss:
Compound selectors may no longer be extended.
Consider `@extend .build-content, :hover` instead.
See http://bit.ly/ExtendCompound for details.

 snip --

Is there a known workaround for that issue?

Apparently, at least for me, a clean upgrade of gitlab is not possible
right now.

Best,
Maximilian

Bug#949235: ip netns add race condition can wreak havoc in mount points

[Etienne Dechamps]

Hi Luca,

On Fri, 27 Nov 2020 at 18:09, Luca Boccassi  wrote:
> Can reproduce the issue - sent a patch to use flock():
>
> https://patchwork.ozlabs.org/project/netdev/patch/20201127180651.80283-1-bl...@debian.org/
>
> Please test it as well, cannot reproduce anymore once the fix is in.

Sorry for the delay. I can confirm that I cannot reproduce anymore
with your patch (commit 975c494 in the iproute2 git repo). Thanks for
the fix!

Bug#977512: src:libconfig-identity-perl: Build-Depends on old gnupg1, but could use gnupg2

[Chris Hofstaedtler]

* gregor herrmann  [201215 23:37]:
> On Tue, 15 Dec 2020 22:43:26 +0100, Chris Hofstaedtler wrote:
> 
> > a very long time ago, Build-Depends were changed so gnupg1 is explicitly
> > used, due to CPAN RT#112569. However, upstream has apparently fixed the
> > tests in 0.0019 - this is noted in the same RT bug.
> > Please consider switching the build dependency to gnupg2.
> 
> Thanks for the bug report!
> 
> Some quick thoughts:
> - OOC: Is gnupg1 going away, or what is the reason for this proposal?

I have asked about this, but nobody is really pushing for gnupg1 to
go away. However, it currently FTBFS, so lets see if it will be in
bullseye.

> - I guess rather gnupg and not gnupg2 (the latter is a transitional
>   package with just a dependency and a symlink gpg2 -> gpg; and the
>   test uses `gpg').

Right.

> - I wrote in the old changelog message:
[..]

> Alright, changes pushed to 
> https://salsa.debian.org/perl-team/modules/packages/libconfig-identity-perl.git
> but I wouldn't mind a second (yours or someone else's :)) pair of
> eyes before uploading.

Thanks for taking care of this. I didn't get to look at your changes
before the upload :-/

The "save test data" machinery looks correct to me. Even though I
might have written the logic inverted - the double negation took me
me some time to understand.

Thanks!
Chris

Bug#977635: djview FTCBFS: fails finding qmakej

[Helmut Grohne]

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

djview4 still fails to cross build from source after we fixed the
pkg-config issue, because its configure script fails to detect a working
qmake. In the mean time, qmake added a cross wrapper. djview4 tries the
regular build architecture qmake, but doesn't try the working host
architecture qmake cross wrapper. The attached patch makes it use the
host architecture one. With it, djview4 becomes cross buildable. Please
consider applying it.

Helmut
--- djview4-4.12.orig/config/acinclude.m4
+++ djview4-4.12/config/acinclude.m4
@@ -272,7 +272,7 @@
 path=$QTDIR/bin:$PATH
   fi
   if test -z "$QMAKE" ; then
-AC_PATH_PROGS([QMAKE], [qmake], [], [$path])
+AC_PATH_TOOL([QMAKE], [qmake], [], [$path])
   fi
   if test -z "$QMAKE" ; then
 AC_MSG_ERROR([Cannot find the Qt program qmake. 
@@ -327,7 +327,7 @@
 altrcc="rcc-${qtversion}"
 altlupdate="lupdate-${qtversion}"
 altlrelease="lrelease-${qtversion}"
-  else
+  elif test `basename "$QMAKE"` = qmake ; then
 AC_MSG_CHECKING([for real qmake path])
 test -x "$QT_INSTALL_BINS/qmake" && QMAKE="$QT_INSTALL_BINS/qmake"
 AC_MSG_RESULT([$QMAKE])

Bug#977634: id-utils FTCBFS: forces the build architecture compiler

[Helmut Grohne]

Source: id-utils
Version: 4.6.28-20200521ss15dab
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

id-utils fails to cross build from source. Even though configure detects
the correct compiler, the make invocation from debian/rules forces the
build architecture compiler. If the CC environment variable is set,
configure would pick it up already and otherwise $(CC) simply becomes
"cc", which is wrong for cross builds. Dropping the assignment gets the
build a lot further.

The build still fails due to use of help2man. For that problem, there
are many different solutions with different tradeoffs:
 * Stop using help2man and write real manual pages.
 * Build twice. Once natively for help2man and once for real.
 * Extract the --help output from the source by other means.
 * Don't regenerate manual pages during build.
 * Move manual pages to an arch:all packages.

Each of these has its own downsides. Do you have a preference?

In the mean time, please apply the attached patch and close this bug
when doing so.

Helmut
diff --minimal -Nru id-utils-4.6.28/debian/changelog 
id-utils-4.6.28/debian/changelog
--- id-utils-4.6.28/debian/changelog2020-05-23 17:00:36.0 +0200
+++ id-utils-4.6.28/debian/changelog2020-12-17 22:34:38.0 +0100
@@ -1,3 +1,11 @@
+id-utils (4.6.28-20200521ss150.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Improve cross building: Don't force the build architecture compiler.
+(Closes: #-1)
+
+ -- Helmut Grohne   Thu, 17 Dec 2020 22:34:38 +0100
+
 id-utils (4.6.28-20200521ss15dab) unstable; urgency=medium
 
   * New upstream snapshot from git://git.savannah.gnu.org/idutils.git 
15dabf93d63ec15e674bd049c839067e58ffb872
diff --minimal -Nru id-utils-4.6.28/debian/rules id-utils-4.6.28/debian/rules
--- id-utils-4.6.28/debian/rules2020-05-22 21:38:30.0 +0200
+++ id-utils-4.6.28/debian/rules2020-12-17 22:34:36.0 +0100
@@ -42,7 +42,7 @@
dh_testdir
 
 #  Compile the package.
-   $(MAKE) CC="$(CC)" CFLAGS="$(CFLAGS)" LDFLAGS="$(LDFLAGS)"
+   $(MAKE) CFLAGS="$(CFLAGS)" LDFLAGS="$(LDFLAGS)"
 
touch $@
 

Bug#977632: dv4l FTCBFS: misconfigures cross build

[Helmut Grohne]

Source: dv4l
Version: 1.0-5
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

dv4l fails to cross build from source. It replaces cdbs' configure flags
and thereby removes --build/--host flags while retaining its CC
environment variable. The configure script rightly becomes confused
about whether that is really a cross build. Please consider applying the
attached patch to put back the missing flags.

Helmut
diff -u dv4l-1.0/debian/changelog dv4l-1.0/debian/changelog
--- dv4l-1.0/debian/changelog
+++ dv4l-1.0/debian/changelog
@@ -1,3 +1,10 @@
+dv4l (1.0-5.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Pass --host to configure. (Closes: #-1)
+
+ -- Helmut Grohne   Thu, 17 Dec 2020 20:58:53 +0100
+
 dv4l (1.0-5) unstable; urgency=low
 
   * Remove vloopback-source from Recommends.
diff -u dv4l-1.0/debian/rules dv4l-1.0/debian/rules
--- dv4l-1.0/debian/rules
+++ dv4l-1.0/debian/rules
@@ -1,11 +1,14 @@
 #!/usr/bin/make -f
 
+include /usr/share/dpkg/architecture.mk
 include /usr/share/cdbs/1/rules/debhelper.mk
 include /usr/share/cdbs/1/class/autotools.mk
 include /usr/share/cdbs/1/rules/patchsys-quilt.mk
 
 DEB_CONFIGURE_NORMAL_ARGS = --prefix=/usr --libdir=/lib/dv4l \
-   --datarootdir=/share 
+   --datarootdir=/share \
+   --build=$(DEB_BUILD_GNU_TYPE) \
+   --host=$(DEB_HOST_GNU_TYPE)
 
 install/dv4l::
install -m 0644 -D debian/lintian-override \

Bug#977615: arm64: memory corruption bug

[Noah Meyerhans]

> Thanks. Pending currently with the ongoing rebase in the v4.19.y
> series in
> https://salsa.debian.org/kernel-team/linux/-/merge_requests/295 .
> 
> Just we need to check if this warrants a regression update issued
> earlier via stable-updates.

If possible, I'd vote for an release via stable-updates, and I'd be
happy to put together a merge request for such a release.

It seems that the bug is triggered during relatively uncommon
circumstances (CoW and MADVISE_FREE used together), but in places where
it is triggered, the impact is severe and there is no practical
workaround.

noah

Bug#977633: meson: support cups-config in debcrossgen

[Helmut Grohne]

Package: meson
Version: 0.56.0-1.1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs
Control: affects -1 + src:cinnamon-settings-daemon

cinnamon-settings-daemon fails to cross build from source, because meson
fails to locate cups. meson tried methods pkg-config and config-tool.
Unfortunately, cups upstream refuses to add a pkg-config file (see
https://github.com/apple/cups/issues/3128) and the config-tool method
refuses to use cups-config. The cups-config tool is architecture
agnostic and can very well be used during cross compilation. All we have
to do is add it to the cross file. I've attached a patch for your
convenience.

Helmut
diff --minimal -Nru meson-0.56.0/debian/changelog meson-0.56.0/debian/changelog
--- meson-0.56.0/debian/changelog   2020-11-28 15:30:07.0 +0100
+++ meson-0.56.0/debian/changelog   2020-12-17 17:30:01.0 +0100
@@ -1,3 +1,10 @@
+meson (0.56.0-1.2) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Add support for cups-config to debcrossgen. (Closes: #-1)
+
+ -- Helmut Grohne   Thu, 17 Dec 2020 17:30:01 +0100
+
 meson (0.56.0-1.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff --minimal -Nru meson-0.56.0/debian/debcrossgen 
meson-0.56.0/debian/debcrossgen
--- meson-0.56.0/debian/debcrossgen 2020-10-30 09:28:05.0 +0100
+++ meson-0.56.0/debian/debcrossgen 2020-12-17 17:30:01.0 +0100
@@ -110,6 +110,10 @@
 ofile.write("pkgconfig = '%s'\n" % locate_path("%s-pkg-config" % 
host_arch))
 except ValueError:
 pass # pkg-config is optional
+try:
+ofile.write("cups-config = '%s'\n" % locate_path("cups-config"))
+except ValueError:
+pass # cups-config is optional
 ofile.write('\n[properties]\n')
 write_args_from_envvars(ofile)
 ofile.write('\n[host_machine]\n')

Bug#977326: fuse-emulator-gtk: No display if window is tall. GTK warnings: drawing failure for widget 'GtkDrawingArea': invalid value for stride

[James Youngman]

> Did you try removing ~/.fuserc ?

I don't have one.

> The problem is that Fuse does not support arbitrary window sizes. What
> it does is provide a few scalers (double size, triple size) and tries
> to force the window size to the closest available scaler. That works
> fine with "small" resolutions (with the 3x scaler the height of
> the Spectrum screen is 240x3 = 720), but that's too small for your
> display.

It would seem reasonable to just not fill the window with the emulated
screen in that case.

Thanks for responding!
James.

Bug#977631: transition: soci

[William Blough]

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

Hi,

I'm requesting a transition for the soci package from 3.2.x to 4.0.x due
to new upstream release.

4.0.1-1 is currently in experimental.

There are no reverse dependencies present in Debian.


Ben file:

title = "soci";
is_affected = .depends ~ "libsoci-core3.2" | .depends ~ "libsoci-firebird3.2" | 
.depends ~ "libsoci-mysql3.2" | .depends ~ "libsoci-odbc3.2" | .depends ~ 
"libsoci-postgresql3.2" | .depends ~ "libsoci-sqlite3-3.2" | .depends ~ 
"libsoci-core4.0" | .depends ~ "libsoci-firebird4.0" | .depends ~ 
"libsoci-mysql4.0" | .depends ~ "libsoci-odbc4.0" | .depends ~ 
"libsoci-postgresql4.0" | .depends ~ "libsoci-sqlite3-4.0";
is_good = .depends ~ "libsoci-core4.0" | .depends ~ "libsoci-firebird4.0" | 
.depends ~ "libsoci-mysql4.0" | .depends ~ "libsoci-odbc4.0" | .depends ~ 
"libsoci-postgresql4.0" | .depends ~ "libsoci-sqlite3-4.0";
is_bad = .depends ~ "libsoci-core3.2" | .depends ~ "libsoci-firebird3.2" | 
.depends ~ "libsoci-mysql3.2" | .depends ~ "libsoci-odbc3.2" | .depends ~ 
"libsoci-postgresql3.2" | .depends ~ "libsoci-sqlite3-3.2";

Bug#977630: RM: kblog -- ROM; dead upstream

[Aurélien COUDERC]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: debian-qt-...@lists.debian.org

Dear FTP Masters,

on behalf of the Qt/KDE team I’d like to ask you to remove kblog from
the archive.
It used to be part of the KDE Frameworks libraries but is dead upstream
and hasn’t been part of the last 2 release series 20.08.x and 20.12.x.

It builds the libkf5blog5 library and doesn’t have any reverse
dependency.


Thanks & happy hacking !
--
Aurélien

Bug#977549: bpftrace: all programs fail with Segmentation fault

[Vincent Bernat]

clone 977549 -1
reassign -1 libbpfcc
retitle -1 libbpfcc: please compile with -DENABLE_LLVM_SHARED=on
severity -1 normal
found -1 0.17.0-8
block 977549 by -1
thanks

 ❦ 16 décembre 2020 16:48 +01, Emanuele Rocca:

> Package: bpftrace
> Version: 0.11.3-3
> Severity: grave
> Justification: renders package unusable
>
> Any attempt of running bpftrace programs fails on my sid workstation:
>
>  $ sudo bpftrace -e 'kprobe:do_nanosleep { printf("PID %d sleeping\n", pid); 
> }'
>  Two passes with the same argument (-tti) attempted to be registered!
>  Segmentation fault
>
> The issue isn't limited to kprobes, uprobes fail too:
>
>  $ sudo bpftrace -e 'uprobe:/bin/bash:readline { printf("Hello\n") }'
>  Two passes with the same argument (-tti) attempted to be registered!
>  Segmentation fault
>
> Even bpftrace -V fails, though with a different error:
>
>  $ sudo bpftrace -V
>  bpftrace v0.11.3
>  free(): double free detected in tcache 2
>  Aborted
>
> I'm running linux-image-5.9.0-4-amd64 5.9.11-1 and libllvm11
> 1:11.0.0-5+b1.

Downgrading libbpfcc to 0.17.0-7 fixes this issue. The change between
this version and 0.17.0-8 seems not related to this regression. I think
this is more a change from LLVM 9 to LLVM 11 that triggered that: the
versions used by libbcc and bpftrace are the same and the initialization
is done twice, once for the dynamic initialization from bpftrace and
once for static initialization from libbcc.

This can be fixed by compiling libbcc with -DENABLE_LLVM_SHARED=on
(tested by adding this flag in debian/rules, no other change). I
don't know if there is a drawback to that.
-- 
Modularise.  Use subroutines.
- The Elements of Programming Style (Kernighan & Plauger)

Bug#977628: RM: orage -- ROM; unmaintained upstream, depends on obsolete libraries

[Yves-Alexis Perez]

Package: ftp.debian.org
Severity: normal
Owner: debian-x...@lists.debian.org

Hi,
with the upcoming release of Xfce 4.16, some libraries have dropped
their GTK-2 variant, which breaks unported software like for example
Orage, which is also unmaintained.

In order to make room for Xfce 4.16 I think it'd be best to remove orage
from the distribution.

Regards,
-- 
Yves-Alexis

Bug#961283: libhttp-tiny-perl: Don't release with bullseye

[Paul Gevers]

Hi Dominic,

On Fri, 22 May 2020 16:15:31 +0100 Dominic Hargreaves
 wrote:
> Package: libhttp-tiny-perl
> Version: 0.076-1
> Severity: serious
> Justification: maintainer
> 
> libhttp-tiny-perl at this version should not be released with
> bullseye, since perl contains the same version.

This package is considered a key package by our tooling and will not be
automatically removed from bullseye. Why don't you request it to be
removed from unstable with a RM bug filed against ftp.debian.org? Than
it will automatically be removed from bullseye too.

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#977626: xfce4-equake-plugin: upcoming breakage of equake plugin with release of Xfce 4.16

[Yves-Alexis Perez]

Package: xfce4-equake-plugin
Severity: normal

Hi,
I'm very sorry to not have reported that earlier, but the upcoming 4.16
release of Xfce desktop environment drops the GTK-2 versions of various
libs, including xfce4-panel, which equake plugin uses.

If there's a GTK3/libxfce4panel-2.0 version of the plugin you might want
to update to that version, but if not we'll unfortunately have to remove
equake plugin from Debian.

Regards,
-- 
Yves-Alexis

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

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

Versions of packages xfce4-equake-plugin depends on:
ii  libatk1.0-0  2.36.0-2
ii  libc62.31-5
ii  libcairo21.16.0-4
ii  libcurl3-gnutls  7.72.0-1
ii  libfontconfig1   2.13.1-4.2
ii  libfreetype6 2.10.4+dfsg-1
ii  libgdk-pixbuf2.0-0   2.40.2-2
ii  libglib2.0-0 2.66.3-2
ii  libgtk2.0-0  2.24.32-5
ii  libpango-1.0-0   1.46.2-3
ii  libpangocairo-1.0-0  1.46.2-3
ii  libpangoft2-1.0-01.46.2-3
ii  libxfce4ui-1-0   4.14.1-1+b1
ii  libxfce4util74.15.3-1
ii  xfce4-panel  4.15.5-1

xfce4-equake-plugin recommends no packages.

xfce4-equake-plugin suggests no packages.

Bug#977627: librust-block-buffer-dev: should Provides: librust-block-buffer+block-padding-dev

[Daniel Kahn Gillmor]

Package: librust-block-buffer-dev
Version: 0.9.0-3
Control: affects -1 debcargo src:rust-sha3

In an attempt to avoid creating an empty "feature" package, the
packaging for rust-block-buffer removed the optionalness of
block-buffer's dependency on block-padding.

The result is that the debcargo-generated .deb doesn't know that it
should add any Provides: entries like
librust-block-buffer+block-padding-dev.

This makes it so a pending update to rust-sha3 can't currently build,
because it depends on block-buffer with the block-padding feature.

I tried patching in a few lines to rust-block-buffer's Cargo.toml:


[features]
block-padding = []


But the result from that was this error:


Something failed: failed to parse manifest at 
`…/debcargo-conf/build/block-buffer/Cargo.toml`

Caused by: Features and dependencies cannot have the same name: `block-padding`


If we can release a version of debcaro with the collapse_features
mechanism, then an update of rust-block-buffer with that enabled should
resolve this.

In the meantime, i'm going to work around it by fiddling with the
dependencies of rust-sha3.

--dkg


signature.asc
Description: PGP signature

Bug#977620: licensecheck: Add support for SPDX-License-Identifier tags in licensecheck

[Jonas Smedegaard]

Control: forcemerge -1 904518

Hi Jeremiah,

Quoting Jeremiah C. Foster (2020-12-17 21:39:07)
> SPDX-License-Identifier is a "tag" used by the SPDX project to 
> identify the license of individual files. The licensecheck tool may 
> benefit from have this functionality.

Thanks for reporting this issue.

It has been reported already in an earlier bugreport, however - see 
https://bugs.debian.org/904518

Hereby merging these bugs.


 - 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#976227: ITA: breathe -- Sphinx autodox support for languages with doxygen support

[Melvin Vermeeren]

Hi Chris,

On Wednesday, 9 December 2020 20:31:34 CET Chris Knadle wrote:
> In the WNPP page [1] above the suggestion is to rename the "O:" bug with
> "ITA:" and set ownership of the bug to yourself in order to start the
> process.

Done, thanks for this and all the other information given, it was very useful 
for me. As for Breathe I'm having a rather hectic month so far (which explains 
the late response) finalising many things in parallel. Once that's done I can 
also finish the preparation work for Debian and it should be smooth sailing 
from then onwards. I expect to be done with all of that before the end of 
January.

As for mumble and the other off-topic things: I'll await your email.

Cheers,

-- 
Melvin Vermeeren
Systems engineer

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

Bug#977625: libxstream-java: CVE-2020-26258: A Server-Side Forgery Request can be activated unmarshalling with XStream

[Salvatore Bonaccorso]

Source: libxstream-java
Version: 1.4.14-1
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 
Control: found -1 1.4.11.1-1+deb10u1
Control: found -1 1.4.11.1-1

Hi,

The following vulnerability was published for libxstream-java.

CVE-2020-26258[0]:
| XStream is a Java library to serialize objects to XML and back again.
| In XStream before version 1.4.15, a Server-Side Forgery Request
| vulnerability can be activated when unmarshalling. The vulnerability
| may allow a remote attacker to request data from internal resources
| that are not publicly available only by manipulating the processed
| input stream. If you rely on XStream's default blacklist of the
| Security Framework, you will have to use at least version 1.4.15. The
| reported vulnerability does not exist if running Java 15 or higher. No
| user is affected who followed the recommendation to setup XStream's
| Security Framework with a whitelist! Anyone relying on XStream's
| default blacklist can immediately switch to a whilelist for the
| allowed types to avoid the vulnerability. Users of XStream 1.4.14 or
| below who still want to use XStream default blacklist can use a
| workaround described in more detailed in the referenced advisories.


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-26258
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-26258
[1] https://github.com/x-stream/xstream/security/advisories/GHSA-4cch-wxpw-8p28
[2] https://x-stream.github.io/CVE-2020-26258.html

Regards,
Salvatore

Bug#977624: libxstream-java: CVE-2020-26259: XStream is vulnerable to an Arbitrary File Deletion on the local host when unmarshalling

[Salvatore Bonaccorso]

Source: libxstream-java
Version: 1.4.14-1
Severity: grave
Tags: security upstream
Justification: user security hole
X-Debbugs-Cc: car...@debian.org, Debian Security Team 
Control: found -1 1.4.11.1-1+deb10u1
Control: found -1 1.4.11.1-1

Hi,

The following vulnerability was published for libxstream-java.

CVE-2020-26259[0]:
| XStream is a Java library to serialize objects to XML and back again.
| In XStream before version 1.4.15, is vulnerable to an Arbitrary File
| Deletion on the local host when unmarshalling. The vulnerability may
| allow a remote attacker to delete arbitrary know files on the host as
| log as the executing process has sufficient rights only by
| manipulating the processed input stream. If you rely on XStream's
| default blacklist of the Security Framework, you will have to use at
| least version 1.4.15. The reported vulnerability does not exist
| running Java 15 or higher. No user is affected, who followed the
| recommendation to setup XStream's Security Framework with a whitelist!
| Anyone relying on XStream's default blacklist can immediately switch
| to a whilelist for the allowed types to avoid the vulnerability. Users
| of XStream 1.4.14 or below who still want to use XStream default
| blacklist can use a workaround described in more detailed in the
| referenced advisories.


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-26259
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-26259
[1] https://github.com/x-stream/xstream/security/advisories/GHSA-jfvx-7wrx-43fh
[2] https://x-stream.github.io/CVE-2020-26259.html

Regards,
Salvatore

Bug#975834: python-blosc: FTBFS: dh_auto_configure: error: pybuild --configure -i python{version} -p "3.8 3.9" returned exit code 13

[Håvard Flaget Aasen]

Hi Adrian

I believe there has been some mixing with the bugs here.
Bug #975834 [0] is not a duplicate of #976569 [1] and should not have
been merged.

I believe #975834 was a problem with CMake in python-blosc, which was
fixed in version 1.9.2+ds1-2 with this commit [2]. The bug #975834
happened when c-blosc was still at version 1.17.1+ds1-1.

Bug #976569 happened when c-blosc was updated to 1.20.1+ds1-1 and got
compiled without snappy support. which is the reason for the bug.

Regards,
Håvard

[0] https://bugs.debian.org/cgi-bin/#975834
[1] https://bugs.debian.org/cgi-bin/#976569
[2]
https://salsa.debian.org/python-team/packages/python-blosc/-/commit/8e961cd6ae1c82eed6170a6683acb209fb08714a

Bug#977622: golang-github-tidwall-gjson: CVE-2020-35380

[Salvatore Bonaccorso]

Source: golang-github-tidwall-gjson
Version: 1.1.5-2
Severity: important
Tags: security upstream
Forwarded: https://github.com/tidwall/gjson/issues/192
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for
golang-github-tidwall-gjson.

CVE-2020-35380[0]:
| GJSON before 1.6.4 allows attackers to cause a denial of service via
| crafted JSON.


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-35380
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-35380
[1] https://github.com/tidwall/gjson/issues/192

Regards,
Salvatore

Bug#141997: wishlist request for engrish filter

[Gürkan Myczko]

God eneving

I have try to dink about this, and find these informations:
https://engrish.com
https://www.reddit.com/r/engrish/
https://en.wikipedia.org/wiki/Engrish

But when I read these things, I get so much tears of laughing, very hard 
to concentration to write such filter!


Here's any simply replacements the filter must mkae:
All "Don't" could be replaced by "No"
Wi-Fi with Wi-fe or Fi-Wi
really -> really
understand -> under stans
glad -> gland

What would "Debian the universal system" become in engrish?

From the bottom of my heart,

Bug#977595: [Pkg-electronics-devel] Bug#977595: lepton-eda/lepton-attrib and lepton-eda/lepton-schematic can't find libgtk-x11-2.0

[Bdale Garbee]

severity 977595 serious
thanks

Vanessa Dannenberg  writes:

Hi Vanessa!

> Package: lepton-eda
> Version: 1.9.13-1
> Severity: grave
>
> [ This is a fresh install of Bullseye/testing, from a net-install
> image fetched just today]

I couldn't duplicate your problem on my "unstable" development system,
so I just installed a VM client using today's "Bullseye Alpha 3" netinst
image for amd64 to test with.  On that system, I was indeed able to
duplicate your failure.

> However, when I try to run lepton-schematic, it appears to compile
> something, and then fails.

Yes.  When first invoked, the lepton-* applications want to compile the
guile code.  The results are cached so that future invocations don't
have to replicate that, and are very fast.  There's supposedly a way to
force compilation of at least some of the guile code at package build
time, but I haven't tried that yet.  And that's the source of the
problem.

It turns out that compiling the guile code requires that libgtk2.0-dev
is installed on the system.  That's unfortunate since it pulls in a huge
chain of dependencies, but it means that the short-term workaround for
you is therefore simply:

apt install libgtk2.0-dev

The next time you try to run any of the lepton-* applications after
doing that, it should work fine.  If not, please let me know!

In the meantime, I'll leave this bug open and try to figure out how to
eliminate this dependency at run-time, perhaps by turning on the guile
pre-compile support if I can figure it out.  I will drop the severity to
serious, keeping it release-critical but not implying really bad
behavior like data loss or a security hole.

Thanks very much for reporting this!

Regards,

Bdale


signature.asc
Description: PGP signature

Bug#977621: murasaki: autopkgtest armhf regression: 6660 Bus error mbfa $f --fasta > testfile

[Paul Gevers]

Source: murasaki
Version: 1.68.6-10
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: regression

Dear maintainer(s),

With a recent upload of murasaki the autopkgtest of murasaki fails in
testing when that autopkgtest is run with the binary packages of
murasaki from unstable. It passes when run with only packages from
testing and on all other architectures that we test for. In tabular form:

   passfail
murasaki   from testing1.68.6-10 on armhf
all others from testingfrom testing

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

Currently this regression is blocking the migration to testing [1]. Can
you please investigate the situation and fix it?

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

Paul

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

https://ci.debian.net/data/autopkgtest/testing/armhf/m/murasaki/8582325/log.gz

autopkgtest [19:57:51]: test run-unit-test: [---
Test Murasaki on NZ_GG705055.fna
Created output directory:
/tmp/autopkgtest-lxc.razmgtoz/downtmp/autopkgtest_tmp/output
Verbosity level is: 0
Writing to: output/test
Pattern is: 101
Max usable hash bits: 27
Hit filter is: 0
Hash table type is: EcoHash
Hashing every: 1 base
Histogram detail is: 0
Hashing function is: 3
Collision profiling is: disabled
Repeats are: unmasked
Mergefilter is at: 100
Random seed: 1606939072 (automatic)
Bitscore output: on
Leave status records: no
Join neighbors is: off
Target memory is: 3.12 GB
Retain members is: true
Store repeatmap? yes
Reverse complement data is generated on the fly
Rifts allowed: 0
Fuzzy Extension: yes
Score by minimum pair: yes
Gapped anchors: no
Large sequence support is: enabled => seqpos is 4 bytes
Murasaki version 1.68.6 (LARGESEQ)
Loading NZ_GG705055.fna
Read 398859bp (389.51 KBp) in 0.035 seconds (11.0 MBp/s)
Done with forward strand (410644bp). Preparing reverse complement...
 <-> Reversing metdata.
Done.
Seq NZ_GG705055.fna loaded. 401.02 KB
Loading NZ_GG705055.gbk
Read 398859bp (389.51 KBp) in 0.048 seconds (7.9 MBp/s)
Done with forward strand (410644bp). Preparing reverse complement...
 <-> Reversing metdata.
Done.
Seq NZ_GG705055.gbk loaded. 401.02 KB
Sequence loading took: 0.083 seconds
Forward frequencies:  A:28.0367%  C:23.1004%  G:20.9036%  T:27.9593%
Global base frequencies:  A/T:55.996%  C/G:44.004%
Pat: 3 bases long with weight 2
   1 101
Computing hash parameters...
Using 4 hashbits
 0%. (T -0.170 seconds) ETA: Wed Dec  2 19:57:52 2020
10%. (T -0.152 seconds) ETA: Wed Dec  2 19:57:52 2020
20%. (T -0.133 seconds) ETA: Wed Dec  2 19:57:52 2020
30%. (T -0.114 seconds) ETA: Wed Dec  2 19:57:52 2020
40%. (T -0.095 seconds) ETA: Wed Dec  2 19:57:52 2020
50%. (T -0.076 seconds) ETA: Wed Dec  2 19:57:52 2020
60%. (T -0.057 seconds) ETA: Wed Dec  2 19:57:52 2020
70%. (T -0.038 seconds) ETA: Wed Dec  2 19:57:52 2020
80%. (T -0.017 seconds) ETA: Wed Dec  2 19:57:52 2020
91%
Acceptable hash function found after 1000 cycles.
Best uses 2/2 bases and has 0 empties from 2 inputs.
Score: 0.925992 (cf. worst: -4.54276)
Entropy: high: 1 lo: 1 total: 2 bases (mean: 1 stddev: 0)
Total correlation penalty: 0
Post cleanup: w[0]>>13 ^ w[0]>>14 {2}
10
==
w[ 0]>>13: -.C
w[ 0]>>14:  A.-
Ecolist (optimistic): (seqbits: 2 idxbits: 20 minBlocks: 1 initblocks: 1)
Ecolist (optimistic): Expcted entries per list: 17
Ecolist (optimistic): Minimum chunks per list: 1
Would take minimum 128.00 bytes to make perfect hash.
Hashing 1.52 MB of sequence requires:
 ~ linear (in seq length) hashing cost of 4.18 MB
 ~ linear (in seq length) expected anchor cost of 18.80 MB
Initial hash table uses: 128 bytes (4 bits, 16 entries)
Expected memory usage (without anchors): 4.18 MB
Expected memory usage (with anchors): 22.98 MB
Hash parameters computed in 0.187 seconds
Creating storage structures: 16 entries in 128 bytes space.
Storage structures created in: 0.000 seconds

Hashing NZ_GG705055.fna forwards
 0%. (T -0.050 seconds) ETA: Wed Dec  2 19:57:52 2020
10%. (T -0.047 seconds) ETA: Wed Dec  2 19:57:52 2020
20%. (T -0.043 seconds) ETA: Wed Dec  2 19:57:52 2020
30%. (T -0.037 seconds) ETA: Wed Dec  2 19:57:52 2020
40%. (T -0.031 seconds) ETA: Wed Dec  2 19:57:52 2020
50%. (T -0.025 seconds) ETA: Wed Dec  2 19:57:52 2020
60%. (T -0.019 seconds) ETA: Wed Dec  2 19:57:52 2020
70%. (T -0.013 seconds) ETA: Wed Dec  2 19:57:52 2020
80%. (T -0.006 seconds) ETA: Wed Dec  2 19:57:52 2020
90%.
Hashing NZ_GG705055.fna backwards
 0%. (T -0.058 seconds) 

Bug#977620: licensecheck: Add support for SPDX-License-Identifier tags in licensecheck

[Jeremiah C. Foster]

Package: licensecheck
Version: 3.0.31-3
Severity: wishlist

Dear Maintainer,

SPDX-License-Identifier is a "tag" used by the SPDX project to
identify the license of individual files. The licensecheck tool may
benefit from have this functionality.

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

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

Versions of packages licensecheck depends on:
ii  libgetopt-long-descriptive-perl0.103-2
ii  libmoo-perl2.003004-2
ii  libnamespace-clean-perl0.27-1
ii  libpath-iterator-rule-perl 1.014-1
ii  libpath-tiny-perl  0.108-1
ii  libpod-constants-perl  0.19-1
ii  libregexp-pattern-license-perl 3.0.31-4
ii  libscalar-list-utils-perl  1:1.50-1+b1
ii  libsort-key-perl   1.33-2+b1
ii  libstrictures-perl 2.05-1
ii  libstring-copyright-perl   0.003006-1
ii  libstring-escape-perl  2010.002-2
ii  libtry-tiny-perl   0.30-1
ii  perl   5.28.1-6+deb10u1
ii  perl-base [libscalar-list-utils-perl]  5.28.1-6+deb10u1

licensecheck recommends no packages.

Versions of packages licensecheck suggests:
ii  bash-completion  1:2.8-6

-- no debconf information

Bug#977619: libtemplate-plugin-xml-perl: autopkgtest failure: Failed test 'all modules in libtemplate-plugin-xml-perl pass the syntax check'

[Paul Gevers]

Source: libtemplate-plugin-xml-perl
Version: 2.17-4
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: fails-always

Dear maintainer(s),

You recently added an autopkgtest to your package
libtemplate-plugin-xml-perl, great. However, it fails. Currently this
failure is blocking the migration to testing [1]. Can you please
investigate the situation and fix it?

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

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

Paul

[1] https://qa.debian.org/excuses.php?package=libtemplate-plugin-xml-perl

https://ci.debian.net/data/autopkgtest/testing/amd64/libt/libtemplate-plugin-xml-perl/8516195/log.gz

autopkgtest [21:18:08]: test autodep8-perl-recommends:
[---

#   Failed test '/usr/bin/perl -wc
/usr/share/perl5/Template/Plugin/XML/LibXML.pm exited successfully'
#   at
/usr/share/pkg-perl-autopkgtest/runtime-deps-and-recommends.d/syntax.t
line 124.

#   Failed test '/usr/bin/perl -wc
/usr/share/perl5/Template/Plugin/XML/XPath.pm exited successfully'
#   at
/usr/share/pkg-perl-autopkgtest/runtime-deps-and-recommends.d/syntax.t
line 124.
# Looks like you failed 2 tests of 9.

#   Failed test 'all modules in libtemplate-plugin-xml-perl pass the
syntax check'
#   at
/usr/share/pkg-perl-autopkgtest/runtime-deps-and-recommends.d/syntax.t
line 127.
# Looks like you failed 1 test of 4.
/usr/share/pkg-perl-autopkgtest/runtime-deps-and-recommends.d/syntax.t ..
1..4
ok 1 - Package libtemplate-plugin-xml-perl is known to dpkg
ok 2 - Got status information for package libtemplate-plugin-xml-perl
ok 3 - Got file list for package libtemplate-plugin-xml-perl
# Subtest: all modules in libtemplate-plugin-xml-perl pass the syntax check
1..9
ok 1 - /usr/bin/perl -wc /usr/share/perl5/Template/Plugin/XML/DOM.pm
exited successfully
ok 2 - /usr/bin/perl -wc
/usr/share/perl5/Template/Plugin/XML/File.pm exited successfully
# Global symbol "$self" requires explicit package name (did you
forget to declare "my $self"?) at
/usr/share/perl5/Template/Plugin/XML/LibXML.pm line 115.
# /usr/share/perl5/Template/Plugin/XML/LibXML.pm had compilation errors.
not ok 3 - /usr/bin/perl -wc
/usr/share/perl5/Template/Plugin/XML/LibXML.pm exited successfully
ok 4 - /usr/bin/perl -wc /usr/share/perl5/Template/Plugin/XML/RSS.pm
exited successfully
ok 5 - /usr/bin/perl -wc
/usr/share/perl5/Template/Plugin/XML/Simple.pm exited successfully
ok 6 - /usr/bin/perl -wc
/usr/share/perl5/Template/Plugin/XML/Style.pm exited successfully
ok 7 - /usr/bin/perl -wc
/usr/share/perl5/Template/Plugin/XML/View.pm exited successfully
# Can't locate XML/XPath.pm in @INC (you may need to install the
XML::XPath module) (@INC contains: /etc/perl
/usr/local/lib/x86_64-linux-gnu/perl/5.32.0 /usr/local/share/perl/5.32.0
/usr/lib/x86_64-linux-gnu/perl5/5.32 /usr/share/perl5
/usr/lib/x86_64-linux-gnu/perl-base /usr/lib/x86_64-linux-gnu/perl/5.32
/usr/share/perl/5.32 /usr/local/lib/site_perl) at
/usr/share/perl5/Template/Plugin/XML/XPath.pm line 25.
# BEGIN failed--compilation aborted at
/usr/share/perl5/Template/Plugin/XML/XPath.pm line 25.
not ok 8 - /usr/bin/perl -wc
/usr/share/perl5/Template/Plugin/XML/XPath.pm exited successfully
ok 9 - /usr/bin/perl -wc /usr/share/perl5/Template/Plugin/XML.pm
exited successfully
not ok 4 - all modules in libtemplate-plugin-xml-perl pass the syntax check
Dubious, test returned 1 (wstat 256, 0x100)
Failed 1/4 subtests

Test Summary Report
---
/usr/share/pkg-perl-autopkgtest/runtime-deps-and-recommends.d/syntax.t
(Wstat: 256 Tests: 4 Failed: 1)
  Failed test:  4
  Non-zero exit status: 1
Files=1, Tests=4,  1 wallclock secs ( 0.04 usr  0.00 sys +  0.82 cusr
0.13 csys =  0.99 CPU)
Result: FAIL
autopkgtest [21:18:10]: test autodep8-perl-recommends:
---]



OpenPGP_signature
Description: OpenPGP digital signature

Bug#977618: dssp: reproducible builds: Embeds build time in /usr/bin/mkdssp

[Vagrant Cascadian]

Source: dssp
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps 
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

The build time is embedded in /usr/bin/mkdssp:

  
https://tests.reproducible-builds.org/debian/rb-pkg/bullseye/amd64/diffoscope-results/dssp.html

  Date:·2020-
  Date:·2022-


The attached patch fixes this by adjusting the date command in
GNUmakefile.in to use SOURCE_DATE_EPOCH for the timestamp.


Thanks for maintaining dssp!


live well,
  vagrant
From 044df2e01ee32761a8f3be0d467feb088cc0e449 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Thu, 17 Dec 2020 20:16:41 +
Subject: [PATCH] revision.hpp: Patch to use SOURCE_DATE_EPOCH.

https://reproducible-builds.org/docs/source-date-epoch/
---
 GNUmakefile.in | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/GNUmakefile.in b/GNUmakefile.in
index 23b8223..749bc2c 100644
--- a/GNUmakefile.in
+++ b/GNUmakefile.in
@@ -127,7 +127,7 @@ else
 src/revision.hpp:
 	@ echo 'const char kRevision[] = R"(' > $@
 	@ echo dssp-version: $(VERSION) >> $@
-	@ echo Date:   $$(date --iso-8601) >> $@
+	@ echo Date:   $$(date --utc --date=@$(SOURCE_DATE_EPOCH) --iso-8601) >> $@
 	@ echo ')";' >> $@
 
 endif
-- 
2.29.2



signature.asc
Description: PGP signature

Bug#977615: arm64: memory corruption bug

[Salvatore Bonaccorso]

Hi,

On Thu, Dec 17, 2020 at 08:08:28PM +, Noah Meyerhans wrote:
> Package: src:linux
> Version: 4.19.160-2
> Severity: important
> Tags: upstream fixed-upstream
> Control: fixed -1 5.9.15-1
> Control: fixed -1 5.10~rc7-1~exp1
> Control: found -1 5.9.11-1
> 
> Opening a bug for visibility.  Arguably this could be Severity: grave given
> that memory corruption can lead to data loss.  It has been fixed upstream in
> 4.19.161, 5.9.12, and 5.10.  I'm not sure about the status for 4.9/stretch
> LTS.
> 
> There is a memory corruption bug impacting arm64.  The upstream fix was made
> in 5.10 with commit ff1712f953e2 ("arm64: pgtable: Ensure dirty bit is
> preserved across pte_wrprotect()").  The upstream commit [1] describes the
> issue as:
> 
> With hardware dirty bit management, calling pte_wrprotect() on a
> writable, dirty PTE will lose the dirty state and return a
> read-only, clean entry.
> 
> Impact from the issue has been observed in the real world on systems running
> redis, as described at https://github.com/redis/redis/issues/8124 (note in
> particular comments [2] and [3], where the kernel connection is made).
> 
> 1. 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ff1712f953e27f0b0718762ec17d0adb15c9fd0b
> 2. https://github.com/redis/redis/issues/8124#issuecomment-745791340
> 3. https://github.com/redis/redis/issues/8124#issuecomment-745838911

Thanks. Pending currently with the ongoing rebase in the v4.19.y
series in
https://salsa.debian.org/kernel-team/linux/-/merge_requests/295 .

Just we need to check if this warrants a regression update issued
earlier via stable-updates.

Salvatore

Bug#977617: udev: Failed to set up mount namespacing: Permission denied - after unattended-upgrade udev:amd64 241-7~deb10u5

[whilelm]

Package: udev
Version: 241-7~deb10u5
Severity: important

Dear Maintainer,

   * What led up to the situation?

extract from apt/history.log:
Start-Date: 2020-12-13  06:22:21
Commandline: /usr/bin/unattended-upgrade
Upgrade: udev:amd64 (241-7~deb10u4, 241-7~deb10u5), libudev1:amd64 
(241-7~deb10u4, 241-7~deb10u5)
Error: Sub-process /usr/bin/dpkg returned an error code (1)
End-Date: 2020-12-13  06:22:31

Since, got this king of message 
déc. 17 20:56:55  systemd[1]: Starting udev Kernel Device Manager...
   
déc. 17 20:56:55  systemd[30292]: systemd-udevd.service: Failed to set up 
mount namespacing: Permission denied 
déc. 17 20:56:55  systemd[30292]: systemd-udevd.service: Failed at step 
NAMESPACE spawning /lib/systemd/systemd-udevd: Permission denied
dpkg: erreur de traitement du paquet udev (--configure) :
 installed udev package post-installation script subprocess returned error exit 
status 1 

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

tried `apt install -f`, same error message


-- Package-specific info:

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

Kernel: Linux 4.19.0-12-amd64 (SMP w/4 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 /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages udev depends on:
ii  adduser   3.118
ii  dpkg  1.19.7
ii  libacl1   2.2.53-4
ii  libblkid1 2.33.1-0.1
ii  libc6 2.28-10
ii  libkmod2  26-1
ii  libselinux1   2.8-1+b1
ii  libudev1  241-7~deb10u5
ii  lsb-base  10.2019051400
ii  systemd-sysv  241-7~deb10u5
ii  util-linux2.33.1-0.1

udev recommends no packages.

udev suggests no packages.

Versions of packages udev is related to:
ii  systemd  241-7~deb10u5

-- debconf information:
  udev/reboot_needed:
  udev/new_kernel_needed: false
  udev/sysfs_deprecated_incompatibility:
  udev/title/upgrade:
P: /devices/LNXSYSTM:00
L: 0
E: DEVPATH=/devices/LNXSYSTM:00
E: SUBSYSTEM=acpi
E: MODALIAS=acpi:LNXSYSTM:

P: /devices/LNXSYSTM:00/LNXCPU:00
L: 0
E: DEVPATH=/devices/LNXSYSTM:00/LNXCPU:00
E: SUBSYSTEM=acpi
E: MODALIAS=acpi:LNXCPU:

P: /devices/LNXSYSTM:00/LNXCPU:01
L: 0
E: DEVPATH=/devices/LNXSYSTM:00/LNXCPU:01
E: SUBSYSTEM=acpi
E: MODALIAS=acpi:LNXCPU:

P: /devices/LNXSYSTM:00/LNXCPU:02
L: 0
E: DEVPATH=/devices/LNXSYSTM:00/LNXCPU:02
E: SUBSYSTEM=acpi
E: MODALIAS=acpi:LNXCPU:

P: /devices/LNXSYSTM:00/LNXCPU:03
L: 0
E: DEVPATH=/devices/LNXSYSTM:00/LNXCPU:03
E: SUBSYSTEM=acpi
E: MODALIAS=acpi:LNXCPU:

P: /devices/LNXSYSTM:00/LNXPWRBN:00
L: 0
E: DEVPATH=/devices/LNXSYSTM:00/LNXPWRBN:00
E: SUBSYSTEM=acpi
E: DRIVER=button
E: MODALIAS=acpi:LNXPWRBN:

P: /devices/LNXSYSTM:00/LNXPWRBN:00/input/input6
L: 0
E: DEVPATH=/devices/LNXSYSTM:00/LNXPWRBN:00/input/input6
E: SUBSYSTEM=input
E: PRODUCT=19/0/1/0
E: NAME="Power Button"
E: PHYS="LNXPWRBN/button/input0"
E: PROP=0
E: EV=3
E: KEY=10 0
E: MODALIAS=input:b0019vp0001e-e0,1,k74,ramlsfw

P: /devices/LNXSYSTM:00/LNXPWRBN:00/input/input6/event3
N: input/event3
L: 0
E: DEVPATH=/devices/LNXSYSTM:00/LNXPWRBN:00/input/input6/event3
E: SUBSYSTEM=input
E: DEVNAME=/dev/input/event3
E: MAJOR=13
E: MINOR=67

P: /devices/LNXSYSTM:00/LNXSYBUS:00
L: 0
E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00
E: SUBSYSTEM=acpi
E: MODALIAS=acpi:LNXSYBUS:

P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00
L: 0
E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00
E: SUBSYSTEM=acpi
E: MODALIAS=acpi:PNP0A08:PNP0A03:

P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/INTC0102:00
L: 0
E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/INTC0102:00
E: SUBSYSTEM=acpi
E: MODALIAS=

P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/PNP0C01:00
L: 0
E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/PNP0C01:00
E: SUBSYSTEM=acpi
E: MODALIAS=acpi:PNP0C01:

P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/PNP0C02:05
L: 0
E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/PNP0C02:05
E: SUBSYSTEM=acpi
E: MODALIAS=acpi:PNP0C02:

P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:00
L: 0
E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:00
E: SUBSYSTEM=acpi

P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:01
L: 0
E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:01
E: SUBSYSTEM=acpi

P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:01/AWY0001:00
L: 0
E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:01/AWY0001:00
E: SUBSYSTEM=acpi
E: MODALIAS=

P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:01/PNP:00
L: 0
E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:01/PNP:00
E: SUBSYSTEM=acpi
E: 

Bug#976797: icewm: The "Terminal" menu does not work with terminal other than xterm

[Eduard Bloch]

Control: severity 976797 important

> I removed xterm because it is difficult to configure and now I cannot
> start terminal with the top menu item in the icewm menu.
>
> The menuitem is hardcoded to "x-terminal-emulator -ls". While -l support
> is common -s is specific to xterm. When x-terminal-emulator points to
> something else the menu fails to start a terminal.
>
> Please consider dropping the -s.

I agree. Those switches are basically Wild West across different
terminal emulators, they all should be removed where possible in the
caller's command line.

Unfortunatelly I forgot to apply this change in the last upload, this
should be changed in a couple of days, I want to get 2.0.x version into
Testing first.

Best regards,
Eduard.

Bug#977616: qemu: CVE-2020-27821: heap buffer overflow in msix_table_mmio_write() in hw/pci/msix.c

[Salvatore Bonaccorso]

Source: qemu
Version: 1:5.2+dfsg-2
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 
Control: found -1 1:5.1+dfsg-4

Hi,

The following vulnerability was published for qemu.

CVE-2020-27821[0]:
| A flaw was found in the memory management API of QEMU during the
| initialization of a memory region cache. This issue could lead to an
| out-of-bounds write access to the MSI-X table while performing MMIO
| operations. A guest user may abuse this flaw to crash the QEMU process
| on the host, resulting in a denial of service. This flaw affects QEMU
| versions prior to 5.2.0.

There are several issues here. First the above MITRE description
claims this affects version prior to 5.2.0 but 5.2 seems equally
affected still.

commit in [1] tracked this as fixed relating to upstream commit [2].
But it looks that further analysis did track down the issue leading to
[3] and the fixing commit beeing [4]. 


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-27821
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-27821
[1] 
https://tracker.debian.org/news/1200013/accepted-qemu-152dfsg-1-source-into-unstable/
[2] 
https://git.qemu.org/?p=qemu.git;a=commit;h=1370d61ae3c9934861d2349349447605202f04e9
[3] https://www.openwall.com/lists/oss-security/2020/12/16/6
[4] 
https://git.qemu.org/?p=qemu.git;a=commit;h=4bfb024bc76973d40a359476dc0291f46e435442


Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#977615: arm64: memory corruption bug

[Noah Meyerhans]

Package: src:linux
Version: 4.19.160-2
Severity: important
Tags: upstream fixed-upstream
Control: fixed -1 5.9.15-1
Control: fixed -1 5.10~rc7-1~exp1
Control: found -1 5.9.11-1

Opening a bug for visibility.  Arguably this could be Severity: grave given
that memory corruption can lead to data loss.  It has been fixed upstream in
4.19.161, 5.9.12, and 5.10.  I'm not sure about the status for 4.9/stretch
LTS.

There is a memory corruption bug impacting arm64.  The upstream fix was made
in 5.10 with commit ff1712f953e2 ("arm64: pgtable: Ensure dirty bit is
preserved across pte_wrprotect()").  The upstream commit [1] describes the
issue as:

With hardware dirty bit management, calling pte_wrprotect() on a
writable, dirty PTE will lose the dirty state and return a
read-only, clean entry.

Impact from the issue has been observed in the real world on systems running
redis, as described at https://github.com/redis/redis/issues/8124 (note in
particular comments [2] and [3], where the kernel connection is made).

1. 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ff1712f953e27f0b0718762ec17d0adb15c9fd0b
2. https://github.com/redis/redis/issues/8124#issuecomment-745791340
3. https://github.com/redis/redis/issues/8124#issuecomment-745838911

Bug#977532: gscan2pdf: save option not available

[ydirson]

>The version of libtiff-tools in testing still outputs to stderr, so I am 
>inclined to say this is not (yet) a Debian bug, and certainly not important.
>
>Indeed, your patch will break the version of gscan2pdf in testing.

Arguably, this is for this type of problems that we have the ability to
specify versions on Depends and Breaks.

Bug#977532: gscan2pdf: save option not available

[Jeff]

On 17/12/2020 20:05, Marc Dequènes (duck) wrote:
That's a tad rude. I understand you're preparing the release but the 
meaning of a bug is not up to discussion, problems in unstable, and even 
in experimental have always been considered bugs. As the package was 
almost unusable since my scans were lost I could even have raised the 
severity to prevent a broken version to enter testing and end-up in the 
release. I think you're confusing the severity of the bug itself and the 
priority generated by the situation (which has no real field in the BTS).


Yes, you are right. I misread 4.1.0+git201212-1 and didn't realise that 
it was the version in unstable. I apologise.


Yes it does. Using 'both' is clever and I think proposing the patch 
upstream would be a better solution (considering other distros and 
custom installs).


Thanks for the feedback. I'll push the fix ASAP.



OpenPGP_signature
Description: OpenPGP digital signature

Bug#977611: apt-cacher-ng: Daily cron job frequently hangs

[Eduard Bloch]

Hallo,
* Daniel Schepler [Thu, Dec 17 2020, 11:31:15AM]:
> Package: apt-cacher-ng
> Version: 3.5-3
> Severity: important
>
> Running apt-cacher-ng to serve an sbuild container which gets used
> heavily, I frequently get a hang in the daily cron job.  The process
> tree involved is:
>
> anacron -d -q -s
>   └─sh -c run-parts --report /etc/cron.daily
>   └─run-parts --report /etc/cron.daily
>   └─apt-cacher-ng /etc/cron.daily/apt-cacher-ng
>   └─acngtool maint -c /etc/apt-cacher-ng
> SocketPath=/var/run/apt-cacher-ng/socket
>
> This then prevents the system from reaching other /etc/cron.daily entries.

Oh crap. If it's still hanging at the time when you reach the console,
please make some analysis, like:

lsof > openfiles.txt
gcore -o acng.dmp $(pidof apt-cacher-ng)

and then compress them and send them directly to me.

Latest contents of /var/log/apt-cacher-ng/... would also be interesting.

Thanks,
Eduard.

Bug#977603: Problem solved (root cause unknown)

[Krzysztof Marczak]

I used:
apt-get purge apt-get purge g++ g++-10

then installed again build-enential and installed again build-essential.
Problem is gone. Compilation works without any issues.
What is strange is that I didn't mess in any configuration files for gcc or
clang. I don't know the reason why it failed and why it works again.

Bug#977614: ircd-irc2: reproducible builds: Embeds username and hostname in /etc/ircd/ircd.m4

[Vagrant Cascadian]

Source: ircd-irc2
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: username hostname
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

The configuration file /etc/ircd/ircd.m4 embeds the username and
hostname:

  
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/ircd-irc2.html

  define(HOSTNAME,ionos1-amd64)
  define(HOSTNAME,i-capture-the-hostname)

  define(USER,pbuilder1)
  define(USER,pbuilder2)


The attached patch fixes this by setting HOSTNAME to "HOSTNAME" And USER
to "USERNAME".


Thanks for maintaining ircd-irc2!


live well,
  vagrant
From 3aa4b00c030d4cf76fdf2cd0f1a3695fd17cba6e Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Thu, 17 Dec 2020 04:54:22 +
Subject: [PATCH 1/3] Use dummy values for HOSTNAME and USERNAME.

---
 ircd/buildm4 | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/ircd/buildm4 b/ircd/buildm4
index 9ef0554..d8cb857 100755
--- a/ircd/buildm4
+++ b/ircd/buildm4
@@ -34,9 +34,10 @@ if [ -n "$DEBUG" ] ; then
 else
 	echo "undefine(DEBUGMODE)" >>$M4
 fi
-HOST="`hostname | sed -e 's/\([a-zA-Z0-9\-]*\).*/\1/'`"
+HOST="HOSTNAME"
 echo "define(HOSTNAME,$HOST)" >> $M4
 
+USER="USERNAME"
 echo "define(USER,$USER)" >>$M4
 
 PORT=`egrep '^#define[ 	]*PORT[ 	]*[0-9]*' ../$INCLUDE/config.h | \
-- 
2.20.1



signature.asc
Description: PGP signature

Bug#977613: libcifpp: [INTL:nl] Dutch translation of debconf messages

[Frans Spiesschaert]

 
 
Package: libcifpp 
Severity: wishlist 
Tags: l10n patch 
 
 
 
Dear Maintainer, 
 
 
Please find attached the Dutch translation of libcifpp debconf
messages. 
It has been submitted for review to the debian-l10n-dutch mailing list. 
Please add it to your next package revision. 
It should be put as debian/po/nl.po in your package build tree. 
 

-- 
Met vriendelijke groet,
Frans Spiesschaert



nl.po.gz
Description: application/gzip

Bug#977612: ITP: komposter -- lightweight music composing system

[Gürkan Myczko]

Package: wnpp
Severity: wishlist
Owner: Gürkan Myczko 
X-Debbugs-Cc: debian-de...@lists.debian.org, 
debian-multime...@lists.debian.org


* Package name: komposter
  Version : 0+git20201216
  Upstream Author : Noora Halme, Trilkk/Faemiyah, Adrien Destugues
* URL : http://komposter.haxor.fi
https://github.com/electronoora/komposter
* License : GPL-2+ and MIT
  Description : lightweight music composing system
 This is a lightweight music composing system intended mainly to be used
 in applications where the size of the executable must be minimized such 
as 4K

 and 64K intros.
 .
 It is built using a modular "virtual analog" model, where the composer 
can
 build the synthesizers from scratch using simple basic building blocks. 
This
 minimizes the amount of code required and relies more on data, which 
can be

 compressed more effectively.
 .
 A simple pattern-based sequencer is used to create songs which use up 
to 24
 voices, each of which can use a different synthesizer. Each synthesizer 
can be
 programmed with a number of patches that can be switched between 
patterns.

 .
 Included with Komposter is a music player with full x86 assembly source 
code
 as well as a converter for generating nasm-includeable files from song 
files.

 Source code for the converter is also provided.

It will be maintained in the Multimedia team.
(it's already at mentors.d.n and sid.ethz.ch/debian)

Bug#977611: apt-cacher-ng: Daily cron job frequently hangs

[Daniel Schepler]

Package: apt-cacher-ng
Version: 3.5-3
Severity: important

Running apt-cacher-ng to serve an sbuild container which gets used
heavily, I frequently get a hang in the daily cron job.  The process
tree involved is:

anacron -d -q -s
  └─sh -c run-parts --report /etc/cron.daily
  └─run-parts --report /etc/cron.daily
  └─apt-cacher-ng /etc/cron.daily/apt-cacher-ng
  └─acngtool maint -c /etc/apt-cacher-ng
SocketPath=/var/run/apt-cacher-ng/socket

This then prevents the system from reaching other /etc/cron.daily entries.
-- 
Daniel Schepler

Bug#977610: webauth: reproducible builds: Embeds username, hostname and build time

[Vagrant Cascadian]

Source: webauth
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps username hostname
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

The running kernel is embedded in /usr/bin/webauth:

  
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/webauth.html

  (Built·by·pbuilder1@ionos5-amd64·on·2021-12-31·06:30:01·UTC)
  (Built·by·pbuilder2@i-capture-the-hostname·on·2020-11-28·00:10:17·UTC)


The attached patch fixes this by setting the username and hostname to
UNKNOWN and using SOURCE_DATE_EPOCH for the timestamp.


Thanks for maintaining webauth!


live well,
  vagrant
From 434ea84de3496aa04d17798d1e20566bf18b93de Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Wed, 16 Dec 2020 19:38:45 +
Subject: [PATCH] Remove embedding of username, hostname and set date to use
 SOURCE_DATE_EPOCH.

https://reproducible-builds.org/docs/source-date-epoch/
---
 configure.ac | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/configure.ac b/configure.ac
index 0dab897f..164d6285 100644
--- a/configure.ac
+++ b/configure.ac
@@ -28,9 +28,9 @@ AC_PROG_MKDIR_P
 
 dnl Store information about the time the package was configured and the person
 dnl who configured it into another variable.
-webauth_user=`(whoami || /usr/ucb/whoami || echo UNKNOWN) 2>/dev/null`
-webauth_host=`(hostname || echo UNKNOWN) 2>/dev/null`
-webauth_date=`(date -u +"%Y-%m-%d %T UTC" || echo UNKNOWN) 2>/dev/null`
+webauth_user=UNKNOWN
+webauth_host=UNKNOWN
+webauth_date=`(LC_ALL date -u --date=@${SOURCE_DATE_EPOCH} +"%Y-%m-%d %T UTC" || echo UNKNOWN) 2>/dev/null`
 AC_DEFINE_UNQUOTED([PACKAGE_BUILD_INFO],
 ["Built by $webauth_user@$webauth_host on $webauth_date"],
 [Define to information about when and by whom the package was built.])
-- 
2.20.1



signature.asc
Description: PGP signature

Bug#977532: gscan2pdf: save option not available

[duck]

Quack,

On 2020-12-16 16:54, Jeff wrote:


The version of libtiff-tools in testing still outputs to stderr, so I
am inclined to say this is not (yet) a Debian bug, and certainly not
important.


That's a tad rude. I understand you're preparing the release but the 
meaning of a bug is not up to discussion, problems in unstable, and even 
in experimental have always been considered bugs. As the package was 
almost unusable since my scans were lost I could even have raised the 
severity to prevent a broken version to enter testing and end-up in the 
release. I think you're confusing the severity of the bug itself and the 
priority generated by the situation (which has no real field in the 
BTS).



Indeed, your patch will break the version of gscan2pdf in testing.


As expected libtiff flowed into testing so this is no longer valid.


Does the attached patch also fix your problem?


Yes it does. Using 'both' is clever and I think proposing the patch 
upstream would be a better solution (considering other distros and 
custom installs).


Regards.

--
Marc Dequènes

Bug#977609: grap: reproducible builds: Embeds running kernel in /usr/bin/grap

[Vagrant Cascadian]

Source: grap
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: kernel
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

The running kernel is embedded in /usr/bin/grap:

  
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/grap.html

  349   Linux·5.9.0-0.bpo.2-amd64
  349   Linux·4.19.0-13-amd64


The attached patch fixes by changing the call to "uname -sr" (e.g. Linux
4.19.0-13-amd64) to simply "uname -s" (e.g. Linux).


Thanks for maintaining grap!


live well,
  vagrant
From 2ff1634b1df9ab3e3b11706ca37f1ba0c02c2733 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Thu, 17 Dec 2020 18:48:26 +
Subject: [PATCH] Do not include the running kernel version in the binaries.

https://tests.reproducible-builds.org/debian/issues/unstable/captures_kernel_version_issue.html

---
 grap.m4 | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/grap.m4 b/grap.m4
index 570133a..cc59090 100644
--- a/grap.m4
+++ b/grap.m4
@@ -272,7 +272,7 @@ fi
 dnl get the OS version.  Export it as OS_VERSION in an AC_SUBST
 AC_DEFUN([TVF_OS_VERSION],[
 AC_CACHE_CHECK(for OS version,tvf_cv_os_version,
-	tvf_cv_os_version=`uname -sr`
+	tvf_cv_os_version=`uname -s`
 )
 OS_VERSION=$tvf_cv_os_version
 AC_SUBST(OS_VERSION)
-- 
2.29.2



signature.asc
Description: PGP signature

Bug#977608: mpd hangs when curl dies

[Jos van den Oever]

Package: mpd
Version: 0.21.5-3
Severity: important

Dear Maintainer,

mpd plays internet streams via curl. If curl quits unexpectedly, this can hang 
mpd. This issue has been resolved in the bugfix release v0.21.23.

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

Kernel: Linux 5.4.79-v7+ (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), 
LANGUAGE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages mpd depends on:
ii  adduser   3.118
ii  init-system-helpers   1.56+nmu1
ii  libadplug-2.2.1-0v5   2.2.1+dfsg3-1
ii  libao41.2.2+20180113-1
ii  libasound21.1.8-1+rpt1
ii  libaudiofile1 0.3.6-5
ii  libavahi-client3  0.7-4+b1
ii  libavahi-common3  0.7-4+b1
ii  libavcodec58  7:4.1.6-1~deb10u1+rpt1
ii  libavformat58 7:4.1.6-1~deb10u1+rpt1
ii  libavutil56   7:4.1.6-1~deb10u1+rpt1
ii  libbz2-1.01.0.6-9.2~deb10u1
ii  libc6 2.28-10+rpi1
ii  libcdio-cdda2 10.2+0.94+2-4
ii  libcdio-paranoia2 10.2+0.94+2-4
ii  libcdio18 2.0.0-2
ii  libcurl3-gnutls   7.64.0-4+deb10u1
ii  libdbus-1-3   1.12.20-0+deb10u1
ii  libexpat1 2.2.6-2+deb10u1
ii  libfaad2  2.8.8-3
ii  libflac8  1.3.2-3
ii  libfluidsynth11.1.11-1
ii  libgcc1   1:8.3.0-6+rpi1
ii  libgcrypt20   1.8.4-5
ii  libgme0   0.6.2-1
ii  libicu63  63.1-6+deb10u1
ii  libid3tag00.15.1b-14
ii  libiso9660-11 2.0.0-2
ii  libixml10 1:1.8.4-2
ii  libjack-jackd2-0 [libjack-0.125]  1.9.12~dfsg-2
ii  libjs-sphinxdoc   1.8.4-1
ii  libmad0   0.15.1b-10
ii  libmikmod33.3.11.1-4
ii  libmms0   0.6.4-3
ii  libmodplug1   1:0.8.9.0-2
ii  libmp3lame0   3.100-2+b1
ii  libmpcdec62:0.1~r495-1+b1
ii  libmpdclient2 2.16-1
ii  libmpg123-0   1.25.10-2
ii  libnfs12  3.0.0-2
ii  libogg0   1.3.2-1+b2
ii  libopenal11:1.19.1-1
ii  libopus0  1.3-1
ii  libpcre3  2:8.39-12
ii  libpulse0 12.2-4+deb10u1+rpi2
ii  libsamplerate00.1.9-2
ii  libshout3 2.4.1-2
ii  libsidplayfp4 1.8.8-1
ii  libsmbclient  2:4.9.5+dfsg-5+deb10u1+rpi1
ii  libsndfile1   1.0.28-6
ii  libsoxr0  0.1.2-3
ii  libsqlite3-0  3.27.2-3+deb10u1
ii  libstdc++68.3.0-6+rpi1
ii  libsystemd0   241-7~deb10u5+rpi1
ii  libupnp13 1:1.8.4-2
ii  libvorbis0a   1.3.6-2
ii  libvorbisenc2 1.3.6-2
ii  libwavpack1   5.1.0-6
ii  libwildmidi2  0.4.3-1
ii  libyajl2  2.1.0-3
ii  libzzip-0-13  0.13.62-3.2
ii  lsb-base  10.2019051400+rpi1
ii  zlib1g1:1.2.11.dfsg-1

mpd recommends no packages.

Versions of packages mpd suggests:
ii  avahi-daemon  0.7-4+b1
pn  icecast2  
ii  mpc [mpd-client]  0.31-1
pn  pulseaudio

-- Configuration Files:
/etc/mpd.conf changed:
music_directory "/var/lib/mpd/music"
playlist_directory  "/var/lib/mpd/playlists"
db_file "/var/lib/mpd/tag_cache"
log_file"/var/log/mpd/mpd.log"
pid_file"/run/mpd/pid"
state_file  "/var/lib/mpd/state"
sticker_file   "/var/lib/mpd/sticker.sql"
user"mpd"
bind_to_address "0.0.0.0"
input {
plugin "curl"
}
input {
enabled"no"
plugin "qobuz"
}
input {
enabled  "no"
plugin   "tidal"
}
decoder {
plugin  "hybrid_dsd"
enabled "no"
}
audio_output {
type"alsa"
name"JustBoom"
device  "hw:0,0"# optional
mixer_type  "software"  # optional
mixer_device"digital"   # optional
}
filesystem_charset  

Bug#977607: auto detect rollup.config.js and rollup -c package.json#scripts#build

[Pirate Praveen]

Package: pkg-js-tools
Severity: wishlist

It'd be nice it pkg-js-tools can detect presence of rollup.config.js 
and rollup -c commands in package.json under scripts#build and run in 
dh_auto_build. Currently we have to create debian/nodejs/build or add 
override_dh_auto_build in rules.


Example module rollup-plugin-sass and probably many more

Bug#976440: [Pkg-javascript-devel] Bug#976440: pkg-js-tools: add a minimal test to check the dependencies in package.json does not differ by major versions

[Xavier]

Control: reassign -1 lintian

Le 17/12/2020 à 19:23, Jonas Smedegaard a écrit :
> Quoting Xavier (2020-12-17 19:00:00)
>> such test should not fail because it will creates a lot of
>> false-positive FTBFS. I can write a test that returns OK or SKIP but
>> then what is the benefit?
> 
> Quite helpful if such SemVer violations appeared as lintian warnings.
> 
> Having them appear there would help also outside of the JavaScript team 
> - e.g. as a "smell": https://trends.debian.net/#smells
> 
>  - Jonas

OK, let's do that. Note that is will check running dependencies only:
lintian isn't launched with build dependencies in debci machines AFAIK

@Felix, do you prefer a PR to lintian or a test in pkg-js-tools "extras"?

Cheers,
Xavier

Bug#976440: [Pkg-javascript-devel] Bug#976440: pkg-js-tools: add a minimal test to check the dependencies in package.json does not differ by major versions

[Jonas Smedegaard]

Quoting Xavier (2020-12-17 19:00:00)
> such test should not fail because it will creates a lot of
> false-positive FTBFS. I can write a test that returns OK or SKIP but
> then what is the benefit?

Quite helpful if such SemVer violations appeared as lintian warnings.

Having them appear there would help also outside of the JavaScript team 
- e.g. as a "smell": https://trends.debian.net/#smells


 - 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#977606: ITP: libtgowt -- telegram related WebRTC fork

[Nicholas Guriev]

Package: wnpp
Severity: wishlist
Owner: Nicholas Guriev 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: libtgowt
* URL : https://github.com/desktop-app/tg_owt
* License : BSD-3-Clause
  Programming Lang: C, C++, Assembler
  Description : telegram related WebRTC fork

I am going to package separately tg_owt, WebRTC fork from Telegram team.
The package will be needed for build Telegram Desktop with support of
video calls.

Although, a code of the fork really has a lot of implementation details
from Telegram and hardly will benefit other programs. I even intended to
incorporate the code as part of the telegram-desktop package. But
because of long compilation time, I reached the conclusion that it is
easier to not mix different things together.

-BEGIN PGP SIGNATURE-

iQJHBAEBCgAxFiEErCXL1OhKV/yjM8ucSd94pekx4+EFAl/bldATHG5pY2hvbGFz
QGd1cmlldi5zdQAKCRBJ33il6THj4c+WD/48DXZZjD36fjj2UvYNxeDIELhdF7PG
LEVHE5upTvXRb+wGnIp4gFKDGdG1osO/9ZCY9wrOFuCpjUzWAjjUYzlIRd6safgT
BZ8b7afRlJRfr+uDvVQIzHgErnanqfIK/KxvfQI/PtvZLjKm7atJf9KsjzkZ9sMM
V2PjIEf4X2bXaXYi06CUxJINL38agFGoDFOv5RMNCDyUfRPlOFlKujqXxDWvZsJo
/pblCmkonDzNb7zSjpqjJ+58J0fr0bQXHQuQsQ36r3rFvyWmXefAxrSKnk+tcEt6
QMa7Y7P3RIrBe2yMnxmUjqGQOb7ds3bANjjlN0U5zTIKu8Lq19sKCSx+7xe6pV8d
HVXZC+DrusxrJVZpH9VXs+ziYZhcZPRMIGnFihzZI0uEsty8EBQcy4/ZQNdYeAP0
G6kzMN8B5tjNFoO6ImDX4UM0KomaviItt9gbSCRHjhBqyQ8a3QXJuGDRVH9yWbCV
iO+kJEDVfA478V78M23AvIR9wpVBhRVSSxD12/PY4dsa/MtMDRsi84JLmy54yDF/
uChbX4VEGl0sAlIrFHXggxSks5gqXM43ve4NGNjbJgCfn2fFkCCQ1uea7E5vMuaH
JAfQao1RHVR/hex9XgoOx/dQ9TtDiDST/6BwsxO1ViJhXfWJAXC1Cwlam+Fa9W1+
2AzQpS3KyY3Pew==
=Kwvj
-END PGP SIGNATURE-

Bug#969140: linux-image-5.7.0-0.bpo.2-amd64: Please enable CONFIG_F2FS_FS in the cloud image kernel

[Bastian Blank]

Control: tag -1 wontfix

On Fri, Aug 28, 2020 at 10:41:42PM +0100, Ben Hutchings wrote:
> On Fri, 2020-08-28 at 14:43 +0800, Hamish Moffatt wrote:
> > Could you please enable CONFIG_F2FS_FS in the cloud kernel?
> What makes you think f2fs will be commonly used in cloud deployments?

Marking it was wontfix as the OP was not able to persuade as we it might
be needed.

Bastian

-- 
You!  What PLANET is this!
-- McCoy, "The City on the Edge of Forever", stardate 3134.0

Bug#976440: pkg-js-tools: add a minimal test to check the dependencies in package.json does not differ by major versions

[Xavier]

Hi,

such test should not fail because it will creates a lot of
false-positive FTBFS. I can write a test that returns OK or SKIP but
then what is the benefit?

Cheers,
Xavier

Bug#977594: liblist-moreutils-perl: autopkgtest regressions, breaks lintian

[gregor herrmann]

On Thu, 17 Dec 2020 14:11:26 +, Niko Tyni wrote:

> Some changes in this version seem to have broken other packages, at
> least libmakefile-dom-perl/0.008-2 and lintian/2.103.0.

For libmakefile-dom-perl it helps to add a build dependency on
liblist-moreutils-xs-perl to fix the test failures during build.

For lintian, I get the same errors when checking dehydrated (#977554)
-- both the versions currently in unstable -- but not when I
re-install liblist-moreutils-xs-perl.


So it looks like the simple fix is to add liblist-moreutils-xs-perl
as a dependency to liblist-moreutils-perl; and *cough* as a matter of
fact, I see now that liblist-moreutils-perl's META.yml has

requires:
  List::MoreUtils::XS: '0.430'

Sorry for missing this. And too bad liblist-moreutils-perl's test
suite as run during its autopkgtests didn't spot it.
 

Will upload this change shortly.


Cheers,
gregor

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


signature.asc
Description: Digital Signature

Bug#976440: pkg-js-tools: add a minimal test to check the dependencies in package.json does not differ by major versions

[Xavier]

Le 17/12/2020 à 19:00, Xavier a écrit :
> Hi,
> 
> such test should not fail because it will creates a lot of
> false-positive FTBFS. I can write a test that returns OK or SKIP but
> then what is the benefit?
> 
> Cheers,
> Xavier

For embedded components, see also
https://salsa.debian.org/debian/devscripts/-/merge_requests/207

Bug#958867: add an option to add-node-component to embed build only modules in debian/build_modules

[Xavier]

Design proposition:

  $ add-node-component --test foo
  $ add-node-component --build bar

will download compatible versions and push then in debian dir:

 -> debian/build_modules/bar
 -> debian/tests/test_module/foo

Bug#977581: ITP: deepin-wallpapers -- wallpapers

[Boyuan Yang]

Hi hufeng,

在 2020-12-17星期四的 13:43 +0800，hufeng写道：
> Package: wnpp
> Severity: wishlist
> Owner: Hu Feng 
> X-Debbugs-Cc: debian-de...@lists.debian.org
> 
> * Package name    : deepin-wallpapers
>    Version : 1.6.14
>    Upstream Author : amazingfate 
> * URL : https://github.com/linuxdeepin/deepin-wallpapers
>    License : GPL-3+, CC-BY-NC 3.0, CC-BY-SA 3.0
>    Programming Lang: Makefile
>    Description : DDE wallpapers
> 
> When users are ready to set their own desktop background,
> Deepin Wallpaper provides many beautiful background pictures for
> users 
> to choose.
> .
> It is part of Deepin software and DDE (Deepin Desktop Environment).
> 
> I intend to co-maintain this package inside pkg-deepin group.

This one is identical as https://bugs.debian.org/975510 , where some
critical problems were discussed. Since there was an old ITP entry
submitted by yourself, please do not open a new ITP bug. Please
continue the discussion at https://bugs.debian.org/975510 and have the
problem solved first.

Thanks,
Boyuan Yang


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

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

[Xavier]

Control: tags -1 + wontfix

Bug#975962: transition: qtbase-opensource-src

[Dmitry Shachnev]

On Thu, Dec 17, 2020 at 12:09:26PM +0100, Sebastian Ramacher wrote:
> And it's done.
>
> Cheers

Thanks for your help again!

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#977174: vcswatch: web hook for changed repositories

[Jelmer Vernooij]

On Thu, Dec 17, 2020 at 06:39:28PM +0100, Christoph Berg wrote:
> Re: Jelmer Vernooij
> > My bad, the word "changed" in my original bug was ambiguous. I'm
> > interested in notifications when there are new commits to the
> > packaging repository - rather than changes to the packaging repository URLs.
> Ah ok.
> 
> > For salsa repositories specifically, it may be possible to improve the
> > reponsiveness of vcswatch by installing a server-side hook that
> > notifies vcswatch whenever a salsa repository has changed.
> 
> That's actually already in place. We can proxy that to you I think,
> and/or write the info to some place. See
> 
> https://salsa.debian.org/qa/qa/-/blob/master/cgi-bin/vcstrigger
> https://qa.debian.org/cgi-bin/vcstrigger

Ah, awesome. :-)

Do you have any preference on how vcswatch could call a
janitor-related webhook? For the moment, I can just add a list of
webhook endpoints in vcswatch, prepopulate that with just the
janitor webhook URL and have vcswatch send a POST request inline
whenever a repository has seen new commits. Does that seem reasonable?

Jelmer

Bug#977174: vcswatch: web hook for changed repositories

[Christoph Berg]

Re: Jelmer Vernooij
> My bad, the word "changed" in my original bug was ambiguous. I'm
> interested in notifications when there are new commits to the
> packaging repository - rather than changes to the packaging repository URLs.

Ah ok.

> For salsa repositories specifically, it may be possible to improve the
> reponsiveness of vcswatch by installing a server-side hook that
> notifies vcswatch whenever a salsa repository has changed.

That's actually already in place. We can proxy that to you I think,
and/or write the info to some place. See

https://salsa.debian.org/qa/qa/-/blob/master/cgi-bin/vcstrigger
https://qa.debian.org/cgi-bin/vcstrigger

Christoph

Bug#977372: linux-image-cloud-amd64: please add e1000 module to the cloud image

[Bastian Blank]

Control: tags -1 wontfix
Control: close -1

Hi nameless

On Mon, Dec 14, 2020 at 03:06:55PM +0100, mc36 wrote:
> please enable e1000 module in the cloud images
> the rationale here is that qemu, virtualbox and openstack
> defaults to this device so it would ease the life...

Sorry, but no.  This kernel is marked as for a specific use-case only.
And all the qemu using cloud setups use virtio, not e1000.

Regards,
Bastian

-- 
Most legends have their basis in facts.
-- Kirk, "And The Children Shall Lead", stardate 5029.5

Bug#957037: biboumi: ftbfs with GCC-10

[Michel Le Bihan]

Hello,

I noticed that
https://salsa.debian.org/aluaces-guest/biboumi/-/commits/upstream
doesn't have upstream imported the same way you have it. I think that I
imported it correctly in
https://salsa.debian.org/mimi8/biboumi/-/commits/upstream .
However, I don't know how you generated the hash in `with Debian dir
49ca567d9a5a72a0874b26f332c3f441ca6783f5` in
https://salsa.debian.org/mimi8/biboumi/-/commit/4efa9c854464d9087b673a0ef5ead39b92e6d109
.

I would like to continue importing upstream releases the same way it
was done before.

Michel Le Bihan

Le jeudi 17 décembre 2020 à 15:18 +0100, Jonas Smedegaard a écrit :
> Quoting Michel Le Bihan (2020-12-17 14:37:38)
> > > @Michel: If you are interested in joining the VoIP team
> > > generally, 
> > > then please join the mailinglist and request membership to the
> > > Salsa 
> > > group - links are at https://wiki.debian.org/Teams/VoIP
> > 
> > Sorry, but I'm not really interested in VoIP software nor have much
> > experience with it. I'm interested in XMPP. Actually, I don't
> > really 
> > understand why this package is managed by the VoIP team and not by
> > the 
> > XMPP team.
> 
> Sorry, I expressed that badly: What I meant to say is that if you
> care 
> for *this* package more generally (i.e. not only this once) then I 
> encourage you to join as package maintainer to help look after it. 
> The 
> VoIP team provides infrastructure - you need not care for other
> packages 
> in the VoIP team.
> 
> Reason Biboumi is maintained in the VoIP team is that Vasudev wanted
> my 
> help maintaining it, and I - just like you, if I understand correctly
> - 
> wanted to limit the amount of teams to attend to.  I have an interest
> in 
> XMPP but am already involved with 20 other teams.
> 
> I am open to having you and Vasudev move the package to the XMPP
> team, 
> but would hate to see the package become badly maintained: Vasudev
> has 
> not had a lot of time for packaging lately, and I don't know the
> level 
> of your devotion - that's why I suggest to start maintain it at its 
> current home where I can help keep an eye on it, and then maybe move
> it 
> later if you still prefer that after tending to it for some time.
> 
> ...but if you are eager to help and joining the VoIP team is what
> holds 
> you back, then maybe it is best to simply hand over the package to
> you.  
> Please do share your thoughts on this.
> 
> 
> Kind regards,
> 
>  - Jonas
>