date:20210213

Source: node-webpack
Version: 4.43.0-6
Severity: serious

webpack depends on node-uglifyjs-webpack-plugin, which in turn has a
serious bug report against it because it is abandoned upstream.
According to webpack/package.json, webpack does not seem to actually
depend on this plugin, so it should be find to just remove this
dependency.

If this dependency is left, node-webpack will be dropped from
bullseye.

Best wishes,

   Julian

Bug#982741: ITP: rtl8821cu -- dkms source for the rtl8821cu network driver

2021-02-13 Thread Alexander Gerasiov

Thanks for pointing out on this moment. Totally miss it. I'll try to clarify 
that issue with copyright holder. (They have many of fws in 
kernel/firmware-realtek, so there should be some common practice for realtek to 
relicense or something like that)

On 14 February 2021 04:37:57 GMT+03:00, Paul Wise  wrote:
>On Sat, Feb 13, 2021 at 8:21 PM Alexander GQ Gerasiov wrote:
>
>> * License : GPL-2 with firmware BLOB
>...
>> Since there is the generated firmware BLOB is the source files
>
>That sounds like a violation of the GPL, so we probably cannot
>redistribute this?
>
>-- 
>bye,
>pabs
>
>https://wiki.debian.org/PaulWise

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Bug#982579: Failed to load firmware brcmfmac43430-sdio at BananaPi M2

2021-02-13 Thread Bernhard

Hello Maximilian

Thank you for working for my problem.

In the GIT repository, i found the NVRAM config file for the Ampak AP6212 named:
brcmfmac43430-sdio.AP6212.txt

This WIFI module is assembled at the Banana Pi M2 Ultra and also at the Banana 
Pi M3.

I'll do some tests by manually copy this file to the directory and let you 
know, if it works.

Best regards and thank you for your support
Bernhard




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

Bug#982765: libffi: update symbols for nios2

2021-02-13 Thread Helmut Grohne

Source: libffi
Version: 3.3-5
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

Please update symbols for nios2. I'm applying the relevant changes as a
.debdiff.

Helmut
diff --minimal -Nru libffi-3.3/debian/changelog libffi-3.3/debian/changelog
--- libffi-3.3/debian/changelog 2020-11-11 17:12:05.0 +0100
+++ libffi-3.3/debian/changelog 2021-02-12 17:53:33.0 +0100
@@ -1,3 +1,10 @@
+libffi (3.3-5.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Update nios2 symbols. Closes: #-1.
+
+ -- Helmut Grohne   Fri, 12 Feb 2021 17:53:33 +0100
+
 libffi (3.3-5) unstable; urgency=medium
 
   * Bump standards and debhelper version.
diff --minimal -Nru libffi-3.3/debian/libffi7.symbols 
libffi-3.3/debian/libffi7.symbols
--- libffi-3.3/debian/libffi7.symbols   2020-11-11 17:12:05.0 +0100
+++ libffi-3.3/debian/libffi7.symbols   2021-02-12 17:53:31.0 +0100
@@ -1,6 +1,6 @@
 libffi.so.7 libffi7 #MINVER#
  (symver)LIBFFI_BASE_7.0 3.3~20180313
  (symver)LIBFFI_CLOSURE_7.0 3.3~20180313
- (symver|arch=!hppa !ia64 !m68k !riscv64 !sh4)LIBFFI_GO_CLOSURE_7.0 
3.3~20180313
- (symver|arch=!hppa !ia64 !m68k !mips !mipsel !mips64 !mips64el !powerpc 
!powerpcspe !ppc64 !ppc64el !riscv64 !sh4)LIBFFI_COMPLEX_7.0 3.3~20180313
+ (symver|arch=!hppa !ia64 !m68k !nios2 !riscv64 !sh4)LIBFFI_GO_CLOSURE_7.0 
3.3~20180313
+ (symver|arch=!hppa !ia64 !m68k !mips !mipsel !mips64 !mips64el !nios2 
!powerpc !powerpcspe !ppc64 !ppc64el !riscv64 !sh4)LIBFFI_COMPLEX_7.0 
3.3~20180313
  (symver)LIBFFI_BASE_7.1 3.3~20180313

Bug#982764: wiki.debian.org: Access to wiki.debian.org is blocked with 403 Forbidden

2021-02-13 Thread Saroj Baral

Package: wiki.debian.org
Severity: normal

It appears some of our IPs have been blocked, and we receive a 403
Forbidden when trying to reach wiki.debian.org.


Can you please unblock

103.10.31.37



*thanks*

Bug#982716: [Aptitude-devel] Bug#982716: aptitude: FTBFS: tests failed

Hi David,

Axel Beckert wrote:
> > So I guess what is intended here is more like:
> > | char * endptr;
> > | errno = 0;
> > | auto score_tweaks = strtol(action.c_str(), , 10);
> > | if (errno != 0 || *endptr != '\0')
> 
> I applied the following patch locally:
> 
> --- a/src/generic/apt/aptitude_resolver.cc
> +++ b/src/generic/apt/aptitude_resolver.cc
> @@ -673,7 +673,10 @@
>else
>  {
>unsigned long score_tweak = 0;
> -  if(!StrToNum(action.c_str(), score_tweak, action.size()))
> +  char * endptr;
> +  errno = 0;
> +  auto score_tweaks = strtol(action.c_str(), , 10);
> +  if (errno != 0 || *endptr != '\0')
>   {
> // TRANSLATORS: actions ("approve", etc.) are keywords and should
> // not be translated
> 
> The initially failing test indeed seems fixed, but now another test
> fails:

Thanks for the hint on being untested and written without copy &
paste. There was indeed a typo in there which was not detected by the
compiler: score_tweak vs score_tweaks (singular vs plural in variable
name). Fixing that and removing the leading "auto" variable
declaration seems the proper fix.

Thanks for the help nevertheless!

Will upload the fix soon.

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#978257: pynwb is marked for autoremoval from testing

2021-02-13 Thread Andreas Tille

Hi Yaroslav,

could you please have a look.  I'm occupied by many other things and will not
care for this one.

Kind regards

   Andreas.

- Forwarded message from Debian testing autoremoval watch 
 -

Date: Sun, 14 Feb 2021 04:39:04 +
From: Debian testing autoremoval watch 
To: py...@packages.debian.org
Subject: pynwb is marked for autoremoval from testing

pynwb 1.2.1-2 is marked for autoremoval from testing on 2021-02-23

It is affected by these RC bugs:
978257: pynwb: FTBFS: dh_auto_test: error: pybuild --test -i python{version} -p 
3.9 returned exit code 13
 https://bugs.debian.org/978257



This mail is generated by:
https://salsa.debian.org/release-team/release-tools/-/blob/master/mailer/mail_autoremovals.pl

Autoremoval data is generated by:
https://salsa.debian.org/qa/udd/-/blob/master/udd/testing_autoremovals_gatherer.pl

___
Debian-med-packaging mailing list
debian-med-packag...@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-packaging

- End forwarded message -

-- 
http://fam-tille.de

Bug#944914: [pkg-gnupg-maint] Bug#944914: libgpgme11: Buffer overflow while using claws-mail

2021-02-13 Thread devel

Hello Daniel,

thanks for looking into the issue again!


Am Fri, 12 Feb 2021 11:11:58 -0500
schrieb Daniel Kahn Gillmor :

> > Due to repeated crashes, I started to collect stack traces.  
> 
> Are you still having these problems?

In fact the problem disappeared - probably around the time when I migrated my
32bit system to 64bit (just the Debian packages; not hardware).


> So i'm pretty stumped as to why or how this could be happening (and i
> haven't been able to hit it myself).  If it's still going on, or if
> you've found a way that i might be able to reproduce it, please respond
> to this bug report.

Thank you for digging further into the issue and for sharing your findings.
I looked through them, but failed to spot anything that could explain my
crashes.

Thus if my "32 bit theory" does not trigger any more ideas, then I would
suggest to close this bug report as non-reproducible or invalid.
Thanks again for your time!

Cheers,
Lars


pgpqxS4GzochJ.pgp
Description: Digitale Signatur von OpenPGP

Bug#982677: FTBFS - required network connection

2021-02-13 Thread Louis-Philippe Véronneau

Hi!

Thanks for reporting this bug.

Sadly, I can't reproduce it using sbuild (with and without network).
Utkarsh has asked Holger to try to build using pbuilder without network
to see if he can reproduce it (I don't really have the spoons to set it
up atm).

FWIW, it looks to me like this is not a network issue, but a dependency
one.

I've seen this exact error before while working on jruby-utils-clojure
and it was caused by an old pom.xml file used in a dependency:

https://sources.debian.org/src/puppetlabs-ring-middleware-clojure/1.0.0-2/debian/pom.xml/#L97

This has since been fixed in puppetlabs-ring-middleware-clojure and
1.3.0-2 (in sid) should be OK. Can you confirm you are using this
version when building?

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



OpenPGP_signature
Description: OpenPGP digital signature

Bug#978631: ufw does not work at all!

2021-02-13 Thread Jamie Strandboge

On Tue, 29 Dec 2020, Jamie Strandboge wrote:
> On Tue, 29 Dec 2020, Energo Koder wrote:
> > Anywhere on enp0s25LIMIT   Anywhere  
> > Anywhere on wlx08beac034eef LIMIT   Anywhere  
> 
> I suspect it is these two lines that are allowing the traffic. It is
> saying to allow (with rate limiting) anything coming in on the enp0s25
> and wlx08beac034eef interfaces. Is 192.168.1.40 associated with either
> of these interfaces?

Per the reporter, the traffic was matching one of the allowed rules so
this is not a bug.

Thanks for the report!
-- 
Email: ja...@strandboge.com
IRC:   jdstrand

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

2021-02-13 Thread Thorsten Glaser

Helge Deller dixit:

> For usage with buildd chroots, what will then be written to
> /proc/sys/fs/binfmt_misc/* ?
> Currently I see:
>   interpreter /usr/bin/qemu-foo-static
>   flags OCF

AIUI:
interpreter /usr/libexec/qemu-binfmt/foo-binfmt-P
flags OCFP

> With your idea, it seems you will then need to drop the "F" flag (which means

No, that’s the beauty of it.

> so that we generally still prefer an "clean" kernel patch as proposed by
> Laurent?

That won’t be available on pre-bookworm systems anyway,
so we’ll carry the -binfmt-P solution for a while.

bye,
//mirabilos
-- 
 Beware of ritual lest you forget the meaning behind it.
 yeah but it means if you really care about something, don't
ritualise it, or you will lose it. don't fetishise it, don't
obsess. or you'll forget why you love it in the first place.

Bug#912860: Don't ship libgtk2-perl in Bullseye

2021-02-13 Thread Thomas Groman

Gtk2 support and gtk2 for Perl shouldn't be removed. Lots of users
depend on it and GTK3 is not a replacement or viable upgrade path from
gtk2. It doesn't do the same things, it uses significantly more
resources, it's incredibly more buggy, and it puts a dependence on
redhatisms. It is also very poorly designed software.


pgp7MgwedDm8v.pgp
Description: OpenPGP digital signature

Bug#982716: [Aptitude-devel] Bug#982716: Bug#982716: aptitude: FTBFS: tests failed

Hi David,

David Kalnischkies wrote:
> On Sat, Feb 13, 2021 at 06:11:03PM +0100, Lucas Nussbaum wrote:
> > Relevant part (hopefully):
> […]
> > > FAIL: cppunit_test
> […]
> | aptitude_resolver.cc:680 ERROR - Invalid hint "-143 aptitude <4.3.0": the 
> action "-143" should be "approve", "reject", or a number.
[…]
> So I guess what is intended here is more like:
> | char * endptr;
> | errno = 0;
> | auto score_tweaks = strtol(action.c_str(), , 10);
> | if (errno != 0 || *endptr != '\0')

I applied the following patch locally:

--- a/src/generic/apt/aptitude_resolver.cc
+++ b/src/generic/apt/aptitude_resolver.cc
@@ -673,7 +673,10 @@
   else
 {
   unsigned long score_tweak = 0;
-  if(!StrToNum(action.c_str(), score_tweak, action.size()))
+  char * endptr;
+  errno = 0;
+  auto score_tweaks = strtol(action.c_str(), , 10);
+  if (errno != 0 || *endptr != '\0')
{
  // TRANSLATORS: actions ("approve", etc.) are keywords and should
  // not be translated

The initially failing test indeed seems fixed, but now another test
fails:


Test Results:
Run:  199   Failures: 1   Errors: 0

1) test: ResolverHintsTest::testHintParse (F) line: 147
../../tests/test_resolver_hints.cc
assertion failed
- Expression: h == t.h
- Checking 40 g++: tweak 0 ?exact-name("g++") installed == tweak 40 
?exact-name("g++") installed


Currently trying to understand why.

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#981128: libgmsh4: SIGABRT in dolfinx demo from gmsh polynomialBasis via Eigen::compute_inverse

2021-02-13 Thread Bernhard Übelacker






This flag is already in use, see https://salsa.debian.org/science-team/gmsh/-/
blob/master/debian/rules#L34




Hello everyone,
the ENABLE_SYSTEM_CONTRIB=1 seems not to be sufficient.

The build log shows this line:
-- Found Eigen
With this include given to c++:
-I/home/benutzer/source/libgmsh4/try2/gmsh-4.7.1+ds1/contrib/eigen

But in CMakeLists.txt we find these lines:
if(ENABLE_SYSTEM_CONTRIB)
find_path(EIGEN_INC "Eigen/Dense" HINTS eigen3)
if(EIGEN_INC)
include_directories(${EIGEN_INC})
set_config_option(HAVE_EIGEN "Eigen[system]")
endif()
endif()
if(NOT HAVE_EIGEN)
include_directories(contrib/eigen)
set_config_option(HAVE_EIGEN "Eigen")
endif()

Therefore it seems if it is not found in the system
and therefore it falls back to contrib.


Adding following to debian/rules:
-DEIGEN_INC:STRING="/usr/include/eigen3"

Would show this with an attempt to dpkg-buildpackage:
-- Found Eigen[system]
With this include given to c++:
-I/usr/include/eigen3


If its not desired to give the path directly maybe somehow retrieved by:
$ pkg-config --cflags eigen3
-I/usr/include/eigen3




But I built a package with that change, but the error remained.

So I rebuilt also dolfinx and saw that it gives to c++ this parameter:
"-DEIGEN_MAX_ALIGN_BYTES=32"
This define might change EIGEN_DEFAULT_ALIGN_BYTES,
and this controls how allocation is done inside
aligned_malloc/aligned_free.

Shouldn't either both have to override the default here
or both stay to the default?


Kind regards,
Bernhard

Bug#982381: AttributeError: lowlevel due to trio usage in s3ql/block_cache.py

2021-02-13 Thread Lorentz Kim

Hi,

I don't know if it'll help much, but I've also gotten this bug and
have resolved it by manually upgrading python3-trio with pip to its
latest version, overriding system's installed version (which is 0.13
last I checked).

pip install trio==0.18.0

Pretty sure the s3ql release notes for 3.7 suggests anything after
trio 0.9 is supported, but perhaps there's a bug in there somewhere?

Regards,
Lorentz

Bug#982688: wireless interface name unstable across reboots

2021-02-13 Thread Yuri D'Elia

On Sun, Feb 14 2021, Michael Biebl wrote:
>> I'd like, ideally, to keep stable interface names. I'm not sure if this
>> is intended, but so far after masking 80-iwd and removing "keep" from
>> the NamePolicy it seems that udev is always able to rename the interface
>> across reboots.
>>
>> It might entirely be because iwd started to operate on the original
>> device name, but didn't have time to bring it up before the rename
>> happens I guess.
>
> See also
> https://iwd.wiki.kernel.org/interface_lifecycle#udev_interface_renaming

I don't think there's anything specific to iwd here though.

My main point is that the race can technically affect anything that
needs to use the interface name during boot:

- interface names might change
- we're not using dbus
- as a result we'd like to rely on "stable" names provided by the udev
  policy
- but there's no way to wait for udev to settle without polling
  apparently?

this somehow contradicts the usefulness of the stable interface names
feature.

As an example, when loading ipt/nft rulesets I'd like to set the rules
*before* the interface is brought up. How to I sequence the service so
that this happens after the rename but before the interface is brought
up? Looks like I can incur in the same race as iwd.

Bug#982741: ITP: rtl8821cu -- dkms source for the rtl8821cu network driver

2021-02-13 Thread Paul Wise

On Sat, Feb 13, 2021 at 8:21 PM Alexander GQ Gerasiov wrote:

> * License : GPL-2 with firmware BLOB
...
> Since there is the generated firmware BLOB is the source files

That sounds like a violation of the GPL, so we probably cannot
redistribute this?

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Bug#976697: webext-umatrix: no longer developed upstream

I *relunctantly* agree that it makes sense to skip bullseye, but I hope
a fork will become a clear winner in time for bookworm. Similar to Axel,
I am still happily using it on buster with firefox-esr. Though I can
reproduce #919557 in a clean profile, it doesn't affect my main one for
some reason. I had a look at the uMatrix Network graph and believe
nuTensor to be the most maintained fork at this time.

https://github.com/gorhill/uMatrix/network
https://github.com/geekprojects/nuTensor

> uMatrix could be removed in favour of uBlock Origin's advanced mode.

While this may be sufficient for some (and in fact gorhill long ago
recommended this), I personally much prefer uMatrix. It may be
subjective, but it's the only extension that makes me feel like I have
control over the browsing experience, acting much like a firewall.
Especially since the introduction of recipes it has become very easy,
though it would be nice to have a larger set.
--
Phil Morrell (emorrp1)


signature.asc
Description: PGP signature

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

2021-02-13 Thread Andy Bennett


Hi,


updated packages are now uploaded to unstable. It might still take
some time for the mirrors to be updated. Please let me know if this
solves your problem.


Thanks for this!

I've had some delay with boards so I've just got to trying out the 
toolchain.


It seems to know about the ATtiny1614 part that the old one did not, 
however, it does not know about the ATtiny1604 and ATtiny804 parts that 
I am using. The latest Microchip Packs at 
http://packs.download.atmel.com/ have the relevant files for now: 
perhaps they updated them in stages?


Thanks for taking the time to upload the new packages.


--
andy...@ashurst.eu.org
http://www.ashurst.eu.org/
http://www.gonumber.com/andyjpb
0x7EBA75FF

Bug#982762: radicale: perhaps chown/chmod /var/lib/radicale/...

2021-02-13 Thread Rob Browning



Package: radicale
Version: 3.0.6-2

I noticed that /var/lib/radicale and /var/lib/radicale/collections are
root:root, and wondered if it might be preferable to change them to
radicale:radicale, and/or restrict world access as suggested upstream
(and expected by the included service file, if nothing else):

  https://radicale.org/3.0.html#tutorials/running-as-a-service

i.e. maybe

  chmod 750 /var/lib/radicale/collections
  chown radicale:radicale /var/lib/radicale/collections

or 770, and possibly something similar for /var/lib/radicale.

Thanks for maintaing the package.
-- 
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4

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

2021-02-13 Thread Helge Deller

On 2/13/21 11:58 PM, Michael Tokarev wrote:

I can think of another hack. Qemu-user binary may look at its
name and if it sees some magic prefix (eg, qemu-foo-binfmt-trigger),
it will assume it is run from within the binfmt subsystem with
the P flag in effect. Yes it is hacky, but it *might* work.

Actually this is something I like. Yes it is hackish but it works.
So I implemented this, using /usr/libexec/qemu-binfmt/foo-binfmt-P
symlinks to ../../bin/qemu-foo[-static], and detecting "-binfmt-P"
prefix in qemu-user/main.c.

It's not fully clear to me yet, how this solves all problems,
so I'm really looking forward to your patches!

For usage with buildd chroots, what will then be written to
/proc/sys/fs/binfmt_misc/* ?
Currently I see:
interpreter /usr/bin/qemu-foo-static
flags OCF
With your idea, it seems you will then need to drop the "F" flag (which means
you basically revert fix-binary binfmt-misc flag and #868030) ?
If so, you will then need to have the "foo-binfmt-P" symlink and qemu-foo-static
inside the chroots too (which mostly prevents usage of non-static qemu-foo
binaries).

I've picked up Laurents kernel patch:
https://patchwork.kernel.org/project/linux-fsdevel/patch/20200128132539.782286-1-laur...@vivier.eu/
into my parisc kernel git tree for inclusion into kernel v5.12 (if nobody
objects this happens next week or the week after).
But in case we now have a viable other solution I prefer to drop it again.
Or this your approach too hackish or has other downsides (like loosing F flags),
so that we generally still prefer an "clean" kernel patch as proposed by
Laurent?

Helge

Bug#982761: torbrowser-launcher: I can't start Tor Browser

2021-02-13 Thread Debian Live user

Package: torbrowser-launcher
Version: 0.3.3-3~bpo10+1
Severity: important

Dear Maintainer,

I can't start Tor Browser. After clicking the icon, nothing happens.
I am using Debian Live. I installed it with torbrowser-launcher from backports.
For me it looks like it is problem with AppArmor. Here are logs from dmesg. 
http://paste.debian.net/hidden/d4c44566/

Thanks in advance for fixing this issue.

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

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

Versions of packages torbrowser-launcher depends on:
ii  ca-certificates20190110
ii  gnupg  2.2.12-1+deb10u1
ii  libdbus-glib-1-2   0.110-4
ii  python33.7.3-1
ii  python3-gpg1.12.0-6
ii  python3-packaging  19.0-1
ii  python3-pyqt5  5.11.3+dfsg-1+b3
ii  python3-requests   2.21.0-1
ii  python3-socks  1.6.8+dfsg-1

Versions of packages torbrowser-launcher recommends:
ii  tor  0.3.5.12-1

Versions of packages torbrowser-launcher suggests:
ii  apparmor  2.13.2-10

-- no debconf information

Bug#982760: gcc-11: ftbfs on mips64el due to ada problem

2021-02-13 Thread YunQiang Su

Package: src:gcc-11
Version: 11-20210207-1
Control: forward -1 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98996


s-pack96.adb should generate   ldl/ldr pair + lwl/lwr pair since 96=64+32.
When generate the pairs, it use the type SUBREG instead of REG, while in
 mips_expand_ext_as_unaligned_load
it only process REG_P but without SUBREG_P.


mips64-ada.diff
Description: Binary data

Bug#982759: vrms does not recognise zoom as nonfree.

2021-02-13 Thread c01d

Package: vrms
Version: 1.27
Severity: normal

Dear Maintainer :)

   * What led up to the situation?

   I checked my system with vrms. I have zoom installed
   (.deb-file from their server).

   While my skypeforlinux-version is correctly shown as non-free,
   zoom is not:

% dpkg -l | grep zoom
  ii  zoom 5.4.57862.0110 amd64 Zoom, blabla

   but for example:

% vrms
Non-free packages installed on main
  [lots of stuff, not zoom]
  skypeforlinux
  [more stuff]

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

I expected zoom to be shown by vrms.

Thank you!

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

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

-- no debconf information

Bug#982743: Hurd: grub-probe returning invalid HDD numbers for several --target options

2021-02-13 Thread Stephen Lyons

Package: grub-common
Version: 2.02-2
Severity: important

Dear Maintainer,

I have a Debian/Hurd installation on an (oversized, it is 160GB but only
138GB can, I understand, be accessed) PATA HDD - i.e. on real hardware.
It is an old Dell Dimension 5150 which is a Pentium D unit so it is a
64-Bit Dual core machine with 1GB of memory - though none of that is
really important I think.

The installation was done on another machine where - due to the vagaries
of the multiple HDD interfaces it was presenting as - as far as the
Debian Hurd Installer (the 2020/07/31 Full DVD version) was concerned
meant it was "/dev/hd2" - though it was the sole hard-drive in the
system. However - and since it was a few days ago and I have been trying
things I cannot be certain so this next bit, between lines of "+"s may
NOT be the case:

+
When the installation was booted I *think* it started Grub and got to
the normal mode menu, but it wouldn't boot. I reviewed the commands that
Grub intended to perform and I spotted that instead of "hd2s1" being
used for the root device it was using "hd-47s1"! However I was able to
get it to boot by changing all those entries back to "hd2s1".
+

Note that due to a second bug which I haven't yet reported, there is a
duplicate call to:

prepare_grub_to_access_device "${GRUB_DEVICE}" | grub_add_tab| sed
"s/^/$submenu_indentation/"

at around line 127 of /etc/grub.d/10_hurd which means there is a batch
of extra, duplicated, commands in the Grub menu item that - fortunately
- would seem to be idempotent but also had to be edited to correct the
bogus "hd-47s1" entries.

Moving on, I transferred the HHD to the system I am SSHing into ("hunt")
to write this and expected to need to edit the same entries to be
"hd0s1" as the drive is now the only drive and the BIOS is happy for it
to be the first drive. Once booted I was able to run grub-update and
expected that to make things work upon the next boot. However on
inspecting the Grub menu item in the new system I have found that the
"/dev/hd0" drive is being misnumbered as "hd-49". Note that the bogus
designation has changed by the same amount as the correct one:

"2" -> "-47"
"0" -> "-49"

to my mind that suggests something is doing some maths or C code to
convert between a C char type to a C int type when it shouldn't or
vise-versa. This is confirmed by the following command and its output:

> root@hunt:~# /usr/sbin/grub-probe -v -d /dev/hd0s1 -t bios_hints
> /usr/sbin/grub-probe: info: cannot open `/boot/grub/device.map': No
such file or directory.
> /usr/sbin/grub-probe: info: /dev/hd0s1 is not present.
> /usr/sbin/grub-probe: info: Looking for /dev/hd0s1.
> /usr/sbin/grub-probe: info: /dev/hd0 is a parent of /dev/hd0s1.
> /usr/sbin/grub-probe: info: /dev/hd0s1 is present.
> /usr/sbin/grub-probe: info: Looking for /dev/hd0s1.
> /usr/sbin/grub-probe: info: /dev/hd0 is a parent of /dev/hd0s1.
> /usr/sbin/grub-probe: info: /dev/hd0s1 is present.
> /usr/sbin/grub-probe: info: /dev/hd0 is a parent of /dev/hd0s1.
> /usr/sbin/grub-probe: info: opening hostdisk//dev/hd0,1.
> /usr/sbin/grub-probe: info: drive = 0.
> /usr/sbin/grub-probe: the size of hostdisk//dev/hd0 is 268435455.
> hd-49,msdos1
> root@hunt:~#

Running the same commands for the other relevant -t targets shows the
same defect.

Obviously I would have expected the outcome for this command to have
been that the output was "hd0,msdos1" rather than "hd-49.msdos1".

It seems fair to assume that this is specifically a Hurd issue and
only affecting "real" hardware...



Stephen Lyons

-- Package-specific info:

*** BEGIN /proc/mounts
/dev/hd0s1 / ext2fs writable,no-inherit-dir-group,store-type=typed 0 0
/dev/hd0s7 /tmp /hurd/ext2fs writable,no-inherit-dir-group 0 0
/dev/hd0s5 /var /hurd/ext2fs writable,no-inherit-dir-group 0 0
/dev/hd0s8 /home /hurd/ext2fs writable,no-inherit-dir-group 0 0
*** END /proc/mounts

*** BEGIN /boot/grub/grub.cfg
#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#

### BEGIN /etc/grub.d/00_header ###
if [ -s $prefix/grubenv ]; then
  set have_grubenv=true
  load_env
fi
if [ "${next_entry}" ] ; then
   set default="${next_entry}"
   set next_entry=
   save_env next_entry
   set boot_once=true
else
   set default="0"
fi

if [ x"${feature_menuentry_id}" = xy ]; then
  menuentry_id_option="--id"
else
  menuentry_id_option=""
fi

export menuentry_id_option

if [ "${prev_saved_entry}" ]; then
  set saved_entry="${prev_saved_entry}"
  save_env saved_entry
  set prev_saved_entry=
  save_env prev_saved_entry
  set boot_once=true
fi

function savedefault {
  if [ -z "${boot_once}" ]; then
saved_entry="${chosen}"
save_env saved_entry
  fi
}
function load_video {
  if [

Bug#982688: wireless interface name unstable across reboots

2021-02-13 Thread Michael Biebl


Am 13.02.2021 um 19:02 schrieb Yuri D'Elia:

On Sat, Feb 13 2021, Andreas Henriksson wrote:

Is it possible to synthesize a target for network interface names, to be
reached when all network interface names have settled somehow?


As I see it the problem is that you currently have 2 options, but you
configured things to be in a broken middle state.

Either you don't care about interface names and you disable the udev
rules for wireless interfaces (iwd default config),
or you say that naming is more important than speed to you so you mask
the configuration shipped by iwd and then make iwd wait for udev rules
to be applied.


Sure. But then again it's exactly the question I have above: what do I
wait "on" in order to ensure interface names have settled?


I guess you could  write a small shell script which loops until the 
interface name has been renamed and order iwd after it.



I've not seen any other practically workable options available right now
without having to do fundamental changes to existing policies in other
software - not udev or iwd (eg. linux, et.al.)


I'd like, ideally, to keep stable interface names. I'm not sure if this
is intended, but so far after masking 80-iwd and removing "keep" from
the NamePolicy it seems that udev is always able to rename the interface
across reboots.

It might entirely be because iwd started to operate on the original
device name, but didn't have time to bring it up before the rename
happens I guess.



See also 
https://iwd.wiki.kernel.org/interface_lifecycle#udev_interface_renaming




OpenPGP_signature
Description: OpenPGP digital signature

Bug#982683: mysql-workbench: Uses no-longer existing package for build, remove?

2021-02-13 Thread Dmitry Smirnov

On Sunday, 14 February 2021 12:14:18 AM AEDT Joerg Jaspert wrote:
> mysql-workbench uses gcc-8 for building, known through bug #944177 for
> more than a year.
> 
> Nothing seems to happen, package looks unmaintained. gcc-8 is now
> removed from Debian, so this package either must have an update, or
> should be removed too.

Let's not panic please. Upstream held us for a while with transition
to Python-3 which finally happened in January (only some weeks ago).

gcc-8 fix has been already committed but there are still few unsolved
FTBFS problems that prevent upload of the package.

No need to demand fixing the package or threaten its removal (but help
is appreciated).

> I intend to do this myself in 3 weeks, if there is no reply. So if you
> are on it and need a little more time, please tell.

Please leave M-W alone as there is still hope to fix it... Thanks.

-- 
Best wishes,
 Dmitry Smirnov
 GPG key : 4096R/52B6BBD953968D1B

---

For every problem, there is a solution that is simple, neat, and wrong.
-- H. L. Mencken

---[ COVID-19(84) ]---

COVID-19: Majority testing positive have no symptoms.
-- 
https://thecritic.co.uk/issues/july-august-2020/ignoring-the-covid-evidence/

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

Bug#982758: webext-browserpass: Failed to install on upgrade to bullseye

2021-02-13 Thread Wookey

Package: webext-browserpass
Version: 3.4.1-4+b2
Severity: important


This is going to be a crappy bugreport because I didn't save the
upgrade log or state-at-fail on this machine (Sorry - I normally
do). But it's quite serious so I thought I'd log it in case others hit
it and can add info, or it's sufficiently obvious what might have gone wrong.

This package gave a dpkg error on upgrade about being unable to create
a file under .mozilla. (the filename had braces {} in it).

I removed it to complete the upgrade. It then re-installed OK.

A clue may well be that I copied an existing mozilla profile into the
.mozilla/firefox direcotry just before upgrading.

I have several 'webext-*' packages installed and the others did not
cause any trouble.  (-debianbuttons, -privacy-badger, -ublock-origin)
so there is something different about -browserpass
--
Wookey

Bug#757769: RFP: jitsi-videobridge depends on kotlin

Control: block -1 by 892842
thanks

> Nowadays the video bridge had been rewritten and has fewer
> dependencies. I'm also not sure about the state of Kotlin, is it yet
> in the repos, cause it is one of the dependencies?

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=760485#54


signature.asc
Description: PGP signature

Bug#982757: firmware-brcm80211: [REGRESSION] brcm/brcmfmac43340-sdio.bin missing in sid (20210208-1)

2021-02-13 Thread yan

Package: firmware-brcm80211
Version: 20201218-3
Severity: normal

Dear Maintainer,

after latest update wifi stopped working and I saw that 
brcm/brcmfmac43340-sdio.bin was missing,
so I downgraded to the version from testing and it works again. please include 
again!

Thank You!

 --Jan Hetges

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

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

firmware-brcm80211 depends on no packages.

firmware-brcm80211 recommends no packages.

Versions of packages firmware-brcm80211 suggests:
ii  initramfs-tools  0.139

-- no debconf information

Bug#952950: nss: Replace PKCS11 headers provided by OASIS

2021-02-13 Thread Timo Röhling

On Mon, 2 Mar 2020 17:16:09 +0800 Alvin Chen  wrote:
> You can use an alternative header like p11-kit which is licensed under
> a more liberal license.
I had a look at the PKCS #11 headers; the biggest problem is that NSS
uses version 3.00 while the p11-kit headers have been forked at 2.40 and
not (yet?) updated, so a few structs and #defines are missing.

There's also a minor issue with CK_GCM_PARAMS, which used to have the
wrong layout due to a documentation/header mismatch. NSS has two
candidates of that struct, CK_GCM_PARAMS_V3 and CK_NSS_PARAMS, and
selects one of those in pkcs11n.h depending on the NSS_PKCS11_2_0_COMPAT
macro.

I might be looking into this a bit more and see if I can fix the p11-kit
headers, if the Mozilla team agrees that this is a viable way to resolve
this
bug.

Cheers
Timo

signature.asc
Description: OpenPGP digital signature

Bug#982742: cups: config of usb printer now impossible due to usblp and libusb conficting (used to work!)

2021-02-13 Thread Brian Potkin

On Sat 13 Feb 2021 at 21:23:19 +0100, Michael Hatzold wrote:

> Package: cups
> Version: 2.3.3op2-3
> Severity: important
> 
> Dear Maintainer,
> 
> *** Reporter, please consider answering these questions, where appropriate ***
> 
>* What led up to the situation?
> 
> I tried to install an USB printer (oki B432).
> 
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
> localhost:631/administration -> new printer
> 
>* What was the outcome of this action?
> 
> The printer is not listed anymore and thus I cannot select the neccesary ppd-
> file, which used to work this way years ago (2017-2019/20). It still works
> *reliably* on a debian/sid(uction) live_ISO from 2020.07. But on my up to date
> installation it does not work anymore:

Thank you for your report, Michael, Let's see what we can do about this.

Are you using a USB connection? If so, give what you get for

  lsusb -v | grep -A 3 bInterfaceClass.*7

Regards,

Brian.

Bug#760485: RFP: jitsi-meet -- WebRTC video conferencing application

I've generated the Javascript Team's task list for jitsi-meet, there's
still quite a few build-deps that are needed to start with.

https://wiki.debian.org/Javascript/Nodejs/Tasks/jitsi-meet


signature.asc
Description: PGP signature

Bug#982697: afdko: FTBFS: build-dependency not installable: python3-cu2qu (>= 1.6.7)

2021-02-13 Thread Samuel Henrique

Related to:

RM: cu2qu -- ROM; merged to fonttools
https://bugs.debian.org/981426

-- 
Samuel Henrique

Bug#981426: RM: cu2qu -- ROM; merged to fonttools

2021-02-13 Thread Samuel Henrique

It seems like a build-dep was missed:

afdko: FTBFS: build-dependency not installable: python3-cu2qu (>= 1.6.7)
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=982697

Cheers,

-- 
Samuel Henrique

Bug#982756: emacs: On startup e complains: Symbol's value as variable is void: ispell-menu-map-needed

2021-02-13 Thread enno

Package: emacs
Version: 1:27.1+1-3
Severity: normal

Dear Maintainer,

This seems to be quite public but unknown to debian bug tracking:
Updated emacs to 27.1, and promptly emacs on startup complains:
Symbol's value as variable is void: ispell-menu-map-needed

This seems to be documented since Aug 2020.

Brgds, e.

-- System Information:
Debian Release: 10.0
  APT prefers testing
  APT policy: (500, 'testing'), (500, 'stable')
Architecture: i386 (x86_64)

Kernel: Linux 5.9.0-5-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_AT@euro, LC_CTYPE=de_AT@euro (charmap=ISO-8859-15)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages emacs depends on:
ii  emacs-lucid  1:27.1+1-3

emacs recommends no packages.

emacs suggests no packages.

-- no debconf information

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

Thanks to bits from the RT. I can't reproduce this issue on a minimal
installation, and the upgrade path has also been fixed #972820.
--
Phil Morrell (emorrp1)



```
$ sudo sbuild-createchroot --command-prefix=eatmydata --include=eatmydata 
buster --chroot-prefix=temporary /srv/chroot/temporary
...
$ sudo sbuild-shell source:temporary-amd64-sbuild
I: /bin/sh
# echo 'deb http://deb.debian.org/debian bullseye main' >> /etc/apt/sources.list
# cat >> /etc/apt/preferences
Package: *
Pin: release a=testing
Pin-Priority: 1
# apt update
Hit:1 http://deb.debian.org/debian buster InRelease
Get:2 http://deb.debian.org/debian bullseye InRelease [123 kB]
Get:3 http://deb.debian.org/debian buster/main Translation-en [5969 kB]
Get:4 http://deb.debian.org/debian bullseye/main amd64 Packages [8214 kB]
Get:5 http://deb.debian.org/debian bullseye/main Translation-en [6266 kB]
Fetched 20.6 MB in 5s (3751 kB/s)  
Reading package lists... Done
Building dependency tree... Done
All packages are up to date.
# apt install libgcc-s1 
Reading package lists... Done
Building dependency tree... Done
The following additional packages will be installed:
  gcc-10-base
The following NEW packages will be installed:
  gcc-10-base libgcc-s1
0 upgraded, 2 newly installed, 0 to remove and 0 not upgraded.
Need to get 243 kB of archives.
After this operation, 386 kB of additional disk space will be used.
Do you want to continue? [Y/n] 
Get:1 http://deb.debian.org/debian bullseye/main amd64 gcc-10-base amd64 
10.2.1-6 [201 kB]
Get:2 http://deb.debian.org/debian bullseye/main amd64 libgcc-s1 amd64 10.2.1-6 
[41.4 kB]
Fetched 243 kB in 0s (4449 kB/s) 
debconf: delaying package configuration, since apt-utils is not installed
Selecting previously unselected package gcc-10-base:amd64.
(Reading database ... 11956 files and directories currently installed.)
Preparing to unpack .../gcc-10-base_10.2.1-6_amd64.deb ...
Unpacking gcc-10-base:amd64 (10.2.1-6) ...
Selecting previously unselected package libgcc-s1:amd64.
Preparing to unpack .../libgcc-s1_10.2.1-6_amd64.deb ...
Unpacking libgcc-s1:amd64 (10.2.1-6) ...
Replacing files in old package libgcc1:amd64 (1:8.3.0-6) ...
Setting up gcc-10-base:amd64 (10.2.1-6) ...
Setting up libgcc-s1:amd64 (10.2.1-6) ...
Processing triggers for libc-bin (2.28-10) ...
# apt remove libgcc-s1
Reading package lists... Done
Building dependency tree   
Reading state information... Done
The following packages will be REMOVED:
  libgcc-s1
WARNING: The following essential packages will be removed.
This should NOT be done unless you know exactly what you are doing!
  libgcc-s1
0 upgraded, 0 newly installed, 1 to remove and 0 not upgraded.
After this operation, 119 kB disk space will be freed.
You are about to do something potentially harmful.
To continue type in the phrase 'Yes, do as I say!'
 ?] 
```


signature.asc
Description: PGP signature

Bug#982574: current php stable crash after configuring

2021-02-13 Thread PICCORO McKAY Lenz

El sáb, 13 de feb. de 2021 a la(s) 12:29, Ondřej Surý
(ond...@sury.org) escribió:
> > this problem is present in debian stable, also in php 7.0, it makes
>
> php7.0 is not part of any supported Debian release.
Debian 9  stretch

umm and this is the mantainer? dont know what debian php packages are supported?

> And yet, this is the first time somebody ever reported this feature
> request in Debian.

Cos you said in github that REPOS ARE IN DEBIAN! so you use your
debian work for your own fame?
>
> That would be against Debian policy. The PHP already gets a preferential
> treatment since stable Debian gets new upstream releases, but changing
> the configuration options within the stable release would be very frowned
> upon.

I understand the case... this is a problem that was more accentuated
with the virtualbox debian package, i understand that! but is not the
case here.. the problems in debian packages is that the maintainers
don't know complete the packages they managed.. and debian has a
strong policy about that, pretty ironic..

by example you are the php debian mantainer, and dont activate that
ACL feature since what? also php-http of oldstable have problems but
people just ignored to send debian mails cos dont understand the bug
system (mails only) and now confused the sury repos with debian ones
..

>
> > i was also blocked for saying what it is...
>
> In my personal space, I block people who are rude to me or act in entitled
> way demanding stuff and not being able to step back.

so if are your personal one.. but use the debian git, incusive debian
git has a branch with "sury" word.. interesting!

i remenber the case of marillat repos! in that case debian ask to
marillat to remove many things.. but what about sury repos? umm very
interesting that now freexian will have a very xpensive repos with php
only umm

Bug#982755: emacs 27.1 has no apt dependency mailutils, but rmail finds no mailmove

2021-02-13 Thread enno

Package: emacs
Version: 1:27.1+1-3
Severity: normal

Dear Maintainer,

I recently updated emacs and consort to 27.1.  On first `M-x rm' emacs (in an
Xsession) complained about having no mailmove available.  I googled mailmove
to find it a part of (gnu) mailutils, which as a debian package provides
mailmove (/usr/bin/).  Aptitude doesn't seem be aware of or just doesn't care
about this dependency.

Brgds e.

PS I suppose there aren't many people still using emacs as their MRT.

-- System Information:
Debian Release: 10.0
  APT prefers testing
  APT policy: (500, 'testing'), (500, 'stable')
Architecture: i386 (x86_64)

Kernel: Linux 5.9.0-5-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_AT@euro, LC_CTYPE=de_AT@euro (charmap=ISO-8859-15)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages emacs depends on:
ii  emacs-lucid  1:27.1+1-3

emacs recommends no packages.

emacs suggests no packages.

-- no debconf information

Bug#982753: installation-reports: Bullseye installation fails creating XFS fs

2021-02-13 Thread Cyril Brulebois

Hallo Andreas,

Andreas Schlager  (2021-02-13):
> I tried to create XFS filesystems on LVM logical volumes. When
> completing the partition process, the installer successfully creates
> LVM vg and lv's, but failed to create the XFS filesystems.
> 
> A look into /var/log/syslog states something like: "partman: mkfs.xfs
> error while loading shared libraries libinih.so.1". I switched to a
> tty console and tried to create the fs manually. The command "mkfs.xfs
> /dev/mapper/rootvg-rootlv" again failed with the above error.

Thanks for your report. That's unfortunately a known bug at the moment:
  https://bugs.debian.org/981662

This should get better once that one gets some attention:
  https://bugs.debian.org/981864

Hopefully we'll fix that before releasing the next Alpha, or a first
Release Candidate of the installer for Bullseye.


Mit freundlichen Grüßen,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

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

2021-02-13 Thread Michael Tokarev


Control: tag -1 pending

14.02.2021 00:56, Thorsten Glaser wrote:

Michael Tokarev dixit:

13.02.2021 13:19, Michael Tokarev wrote:



The problem with the wrapper is that it effectively nullifies
the F flag of binfmt. That is, with F and the binfmt interpreter
being the qemu binary directly, we can use regular, non-static,
qemu-user, or qemu-user-static, and run the thing from outside
of the foreign chroot.

But with the wrapper, we have to have the actual qemu-user binary
runnable within the foreign chroot *too*, - only the wrapper will


Oh? I’m always copying the qemu-user-static binaries into the
chroot and you’re really telling me I didn’t need to? õÕ


This is not needed since v.2.12. So this is buster, but not stretch.
This is fix-binary binfmt-misc flag and #868030 .  Many users got
used to that already in buster and buster-backports :)


I can think of another hack. Qemu-user binary may look at its
name and if it sees some magic prefix (eg, qemu-foo-binfmt-trigger),
it will assume it is run from within the binfmt subsystem with
the P flag in effect. Yes it is hacky, but it *might* work.


Actually this is something I like. Yes it is hackish but it works.
So I implemented this, using /usr/libexec/qemu-binfmt/foo-binfmt-P
symlinks to ../../bin/qemu-foo[-static], and detecting "-binfmt-P"
prefix in qemu-user/main.c.


Ah, with the P flag the argv[0] of the interpreter is not changed,
so this can work. Yes, this sounds like a really good idea.


Thank you! And it works well too. I plan to walk over the pile of
security issues tomorrow and hopefully upload a new version too.

Thanks,

/mjt

Bug#982591: grub-pc can't be updated non-interactively on debian/buster64

2021-02-13 Thread Thomas Lange

IMO we cannot know which device name is used  by the users virtualisation 
environment.
So, what is the be setting without knowing the device name?

Or is /dev/sda used in most enviroments?

-- 
viele Grüße Thomas

Bug#982716: [Aptitude-devel] Bug#982716: Bug#982716: aptitude: FTBFS: tests failed

Hi David,

you were quicker. Thanks! :-)

David Kalnischkies wrote:
> On Sat, Feb 13, 2021 at 06:11:03PM +0100, Lucas Nussbaum wrote:
> > Relevant part (hopefully):
> […]
> > > FAIL: cppunit_test
> […]
> | aptitude_resolver.cc:680 ERROR - Invalid hint "-143 aptitude <4.3.0": the 
> action "-143" should be "approve", "reject", or a number.

Yep, also found this to be the failing test and suspected apt
2.1.19/2.1.20 as the culprit. Especially "Forbid negative values in
unsigned StrToNum explicitly" of 2.1.19 looked suspiciously related.
;-)

> The test uses aptitude_resolver::hint::parse in 
> src/generic/apt/aptitude_resolver.cc
> which in line 676 uses StrToNum to parse the hint which fails with
> apt >= 2.1.19 as StrToNum is refusing to parse negative numbers now.
> 
> The data type of StrToNum is unsigned and using strtoull internally
> which works on an unsigned long long (ull), too, but defines that
> for negative numbers "the negation of the result of the conversion" is
> returned… which tends to be unexpected (Negative numbers played a minor
> role in e.g. CVE-2020-27350 for example).
[…]
> So I guess what is intended here is more like:
> | char * endptr;
> | errno = 0;
> | auto score_tweaks = strtol(action.c_str(), , 10);
> | if (errno != 0 || *endptr != '\0')

Will test, thanks!

> Note that I have not checked my hypotheses. (The code samples are also
> typed in my mail client, so I have probably included some typos letting
> them not even compile.)

I'm glad about your reply definitely.

> Sorry for this breaking change this late in the cycle!

Apology accepted. :-)

> If its any consolation I am also angry that I not only not managed
> to finish the fuzzing project in time, but also not managed to
> salvage the more useful bit in a more timely fashion either.

Actually, when I read that changelog summary, I just thought "Wow!" So
please please keep on that work! Better late than never! :-)

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#982754: python3-pychromecast: pulseaudio-dlna fails with a pychromecast exception while discovering chromecast

2021-02-13 Thread Kostis Anagnostopoulos

Package: python3-pychromecast
Version: 7.7.1-2 
Severity: important
X-Debbugs-Cc: ankos...@gmail.com


Dear Maintainer,

The package pulseaudio-dlna raises an exception while discovering a chromecast
device in the local network:

udio/core1/sink0 finished!
02-13 20:39:58 pychromecast   INFO Querying
device status
Exception in thread zeroconf-ServiceBrowser__googlecast._tcp.local.:
Traceback (most recent call last):
  File "/usr/lib/python3.9/threading.py", line 954, in _bootstrap_inner
self.run()
  File "/usr/lib/python3/dist-packages/zeroconf/__init__.py", line 1557, in run
self._service_state_changed.fire(
  File "/usr/lib/python3/dist-packages/zeroconf/__init__.py", line 1333, in
fire
h(**kwargs)
  File "/usr/lib/python3/dist-packages/zeroconf/__init__.py", line 1427, in
on_change
listener.add_service(*args)
  File "/usr/lib/python3/dist-packages/pychromecast/discovery.py", line 65, in
add_service
self._add_update_service(zconf, typ, name, self.add_callback)
  File "/usr/lib/python3/dist-packages/pychromecast/discovery.py", line 123, in
_add_update_service
callback(uuid, name)
  File "/usr/lib/python3/dist-packages/pychromecast/__init__.py", line 246, in
internal_callback
callback(
  File "/usr/lib/python3/dist-packages/pulseaudio_dlna/plugins/__init__.py",
line 36, in wrapper
device = f(*args, **kwargs)
  File "/usr/lib/python3/dist-
packages/pulseaudio_dlna/plugins/chromecast/__init__.py", line 47, in
_on_device_added
return ChromecastRendererFactory.from_pychromecast(device)
  File "/usr/lib/python3/dist-
packages/pulseaudio_dlna/plugins/chromecast/renderer.py", line 183, in
from_pychromecast
ip=pychromecast.host,
AttributeError: 'Chromecast' object has no attribute 'host'


The problem disappears when i downloaded and pip-install `mkchromecast` in its
place (needs hackish path surgery) because it is a dependency of `pulseaudio-
dlna), or
when  installing the sources from `pulseaudio-dlna` from the new taken-over
repository: https://github.com/Cygn/pulseaudio-dlna


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

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

Versions of packages python3-pychromecast depends on:
ii  python3   3.9.1-1
ii  python3-protobuf  3.12.4-1
ii  python3-requests  2.25.1+dfsg-2
ii  python3-zeroconf  0.26.1-1

python3-pychromecast recommends no packages.

Bug#982753: installation-reports: Bullseye installation fails creating XFS fs

2021-02-13 Thread Andreas Schlager

Package: installation-reports
Severity: normal

Dear Maintainer,

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

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

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


-- Package-specific info:

Boot method: USB-Stick
Image version: 
https://cdimage.debian.org/cdimage/weekly-builds/amd64/iso-cd/debian-testing-amd64-netinst.iso
 Build-Date:   2021-02-01 04:05
Date: 

Machine: Zotac Mini-PC
Partitions: 


Base System Installation Checklist:
[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it

Initial boot:   [O]
Detect network card:[O]
Configure network:  [O]
Detect CD:  [O]
Load installer modules: [O]
Clock/timezone setup:   [O]
User/password setup:[O]
Detect hard drives: [O]
Partition hard drives:  [E]
Install base system:[ ]
Install tasks:  [ ]
Install boot loader:[ ]
Overall install:[ ]

Comments/Problems:
I tried to create XFS filesystems on LVM logical volumes. When completing the 
partition process, the installer successfully creates LVM vg and lv's, but 
failed to create the XFS filesystems.
A look into /var/log/syslog states something like: "partman: mkfs.xfs error 
while loading shared libraries libinih.so.1".
I switched to a tty console and tried to create the fs manually. The command 
"mkfs.xfs /dev/mapper/rootvg-rootlv" again failed with the above error.




-- 

Please make sure that the hardware-summary log file, and any other
installation logs that you think would be useful are attached to this
report. Please compress large files using gzip.

Once you have filled out this report, mail it to sub...@bugs.debian.org.

Bug#980641: nml: builds with patch

On Sat, Feb 13, 2021 at 05:17:59PM +0100, Matthijs Kooijman wrote:
> > Upstream have re-exported the pcx files and I can confirm nml now builds
> > correctly with these 3 files copied into place before tests.
> Cool, thanks for confirming. It would be obvious to just backport these
> changes, but I think the quilt patches used by the Debian patches cannot
> represent changes to binary files, so it would be a bit more hassle
> (probably needs some scripting in debian/rules) to include these
> changes.

Indeed, I've cleaned up my local test and pushed to salsa:

https://salsa.debian.org/emorrp1/nml/-/commit/27c0aea7cd2670462c24246caf510d7dd8cb99dd

> I'll see if upstream maybe wants to do a release with these changes
> included, might be the easiest route...

With 84 commits to master, I'm not convinced that would qualify for an
unblock.


signature.asc
Description: PGP signature

Bug#982610: mark lmodern Multi-Arch: foreign

2021-02-13 Thread Hilmar Preuße


Control: tags -1 + pending

Am 12.02.2021 um 14:31 teilte Helmut Grohne mit:


Tags: patch


Tag pending.

H.
--
sigfault




OpenPGP_signature
Description: OpenPGP digital signature

Bug#892281: closed by Debian FTP Masters (Bug#954831: Removed package(s) from unstable)

2021-02-13 Thread Helmut Grohne

Control: reopen -1
Control: reassign -1 src:gcc-11

On Sat, Feb 13, 2021 at 01:09:15PM +, Debian Bug Tracking System wrote:
> as the package gcc-8 has just been removed from the Debian archive
> unstable we hereby close the associated bug reports.  We are sorry
> that we couldn't deal with your issue properly.

The issue persists in newer gcc releases.

Helmut

Bug#982751: freezer: [INTL:pt] Portuguese translation - debconf messages

2021-02-13 Thread Américo Monteiro

Package: freezer
Version: 9.0.0-2
Tags: l10n, patch
Severity: wishlist

Updated Portuguese translation for freezer's debconf messages
Translator: Américo Monteiro 
Feel free to use it.

For translation updates please contact 'Last Translator' 

-- 
Melhores cumprimentos/Best regards,

Américo Monteiro

-


freezer_9.0.0-2_pt.po.gz
Description: application/gzip

Bug#916376: closed by Debian FTP Masters (Bug#954831: Removed package(s) from unstable)

2021-02-13 Thread Helmut Grohne

Control: reopen -1
Control: reassign -1 gfortran-11

On Sat, Feb 13, 2021 at 01:09:30PM +, Debian Bug Tracking System wrote:
> as the package gcc-8 has just been removed from the Debian archive
> unstable we hereby close the associated bug reports.  We are sorry
> that we couldn't deal with your issue properly.

The issue persists in newer gcc releases.

Helmut

Bug#982752: ipywidgets: please include the javascript libraries

Source: ipywidgets
Version: 6.0.0-8
Severity: wishlist

Hi!

The upstream ipywidgets repository includes a subdirectory called
"packages" containing 6 JavaScript libraries.  It would be great if
these could be packaged along with the rest of the ipywidgets packages
(either as extra binary packages within the ipywidgets source package,
or as separate packages).

Reason: The jupyter-nbconvert package has a template which includes
trying to load @jupyter-widgets/html-manager@^0.18.0/dist/embed-amd.js
from unpkg.com.  Lintian throws up a complaint about this if this
appears within a Debian package's HTML documentation, understandably,
so I'd like to replace it with a local version.  But this JavaScript
library does not currently appear in Debian.  So it would be good if
it were packaged centrally, and this is the most appropriate place to
do that (though it will obviously be a newer version).

Thanks!

   Julian

Bug#982620: texinfo has mailcap entries with quoted %-escapes

2021-02-13 Thread Hilmar Preuße


Control: reassign -1 info
Control: tags -1 + pending

Am 13.02.2021 um 12:30 teilte Marriott NZ mit:

Hi,


BTW, this bug should have been filed against the "info" binary
package, sorry about that.


Reassign, tag.

Hilmar
--
sigfault




OpenPGP_signature
Description: OpenPGP digital signature

Bug#982374: xcwcp: using the mouse to emulate a paddle doesn't work

2021-02-13 Thread Federico Grau

Hello Ottavio Caruso,

Your bug description reads like a dup of #979113 "xcwcp: should dlopen
SO-versioned libpulse-simple", which is resolved for the next Debian stable
release (with xcwcp v3.5.1-4).

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

Could you try the following workaround, and install "libpulse-dev", then
report if the problem is corrected?

apt-get install libpulse-dev

regards,
donfede

On Tue, Feb 09, 2021 at 02:26:40PM +, Ottavio Caruso wrote:
> Package: xcwcp
> Version: 3.5.0-1+b1
> Severity: important
> 
> Dear Maintainer,
> 
> Selecting "receive keyed cw" and pressing either of the left/right
> button of the mouse generates endless dits or dahs. I also get "Unknown
> character received at 12 pwm" in the status bar and "receive buffer overrun"
> 
...

signature.asc
Description: PGP signature

Bug#982654: RFS: qtractor/0.9.20-1 - MIDI/Audio multi-track sequencer application

2021-02-13 Thread Dennis Braun

I saw no disadvantage so far without gtk2 support, anyways i uploaded 
the package again to mentors with gtk2 support.


Am 13.02.21 um 11:36 schrieb Adrian Bunk:

Control: tags -1 moreinfo

On Sat, Feb 13, 2021 at 01:13:00AM +0100, Dennis Braun wrote:

...
* Drop gtk Depends for now, gtk3 still not supported
* Fix build without gtk2

Why not go back to building with gtk2?


Regards,
Dennis

cu
Adrian

Bug#982716: [Aptitude-devel] Bug#982716: aptitude: FTBFS: tests failed

2021-02-13 Thread David Kalnischkies

On Sat, Feb 13, 2021 at 06:11:03PM +0100, Lucas Nussbaum wrote:
> Relevant part (hopefully):
[…]
> > FAIL: cppunit_test
[…]
| aptitude_resolver.cc:680 ERROR - Invalid hint "-143 aptitude <4.3.0": the 
action "-143" should be "approve", "reject", or a number.

The test uses aptitude_resolver::hint::parse in 
src/generic/apt/aptitude_resolver.cc
which in line 676 uses StrToNum to parse the hint which fails with
apt >= 2.1.19 as StrToNum is refusing to parse negative numbers now.

The data type of StrToNum is unsigned and using strtoull internally
which works on an unsigned long long (ull), too, but defines that
for negative numbers "the negation of the result of the conversion" is
returned… which tends to be unexpected (Negative numbers played a minor
role in e.g. CVE-2020-27350 for example).

You could convert to using strtoul directly to replicate the old
behaviour, with something like

| char * endptr;
| auto score_tweaks = strtoul(action.c_str(), , 10);
| if (*endptr != '\0')

(ideally you would check errno for failures of the conversion, but
 StrToNum wasn't doing that either in the past, so to replicate bugs…
 it does do a few other things instead, but they are not relevant here
 aka: it was an odd choice from the start and the only place it is used
 in aptitude)

BUT a bit further down the number is reinterpreted as a signed int which
suggests to me that aptitude wasn't actually expecting to get
a potentially huge positive value for a negative number, but would in
fact prefer to get a negative number if it parsed one and it just didn't
matter for this test either way (and negative hints by users are
probably not that common, too).

So I guess what is intended here is more like:
| char * endptr;
| errno = 0;
| auto score_tweaks = strtol(action.c_str(), , 10);
| if (errno != 0 || *endptr != '\0')

Note that I have not checked my hypotheses. (The code samples are also
typed in my mail client, so I have probably included some typos letting
them not even compile.)

Sorry for this breaking change this late in the cycle! If its any
consolation I am also angry that I not only not managed to finish the
fuzzing project in time, but also not managed to salvage the more useful
bit in a more timely fashion either.

Best regards

David Kalnischkies

signature.asc
Description: PGP signature

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

2021-02-13 Thread Thorsten Glaser

Michael Tokarev dixit:
> 13.02.2021 13:19, Michael Tokarev wrote:

>>The problem with the wrapper is that it effectively nullifies
>>the F flag of binfmt. That is, with F and the binfmt interpreter
>>being the qemu binary directly, we can use regular, non-static,
>>qemu-user, or qemu-user-static, and run the thing from outside
>>of the foreign chroot.
>>
>>But with the wrapper, we have to have the actual qemu-user binary
>>runnable within the foreign chroot *too*, - only the wrapper will

Oh? I’m always copying the qemu-user-static binaries into the
chroot and you’re really telling me I didn’t need to? õÕ

>> I can think of another hack. Qemu-user binary may look at its
>> name and if it sees some magic prefix (eg, qemu-foo-binfmt-trigger),
>> it will assume it is run from within the binfmt subsystem with
>> the P flag in effect. Yes it is hacky, but it *might* work.
>
> Actually this is something I like. Yes it is hackish but it works.
> So I implemented this, using /usr/libexec/qemu-binfmt/foo-binfmt-P
> symlinks to ../../bin/qemu-foo[-static], and detecting "-binfmt-P"
> prefix in qemu-user/main.c.

Ah, with the P flag the argv[0] of the interpreter is not changed,
so this can work. Yes, this sounds like a really good idea.

Thanks,
//mirabilos
-- 
Yay for having to rewrite other people's Bash scripts because bash
suddenly stopped supporting the bash extensions they make use of
-- Tonnerre Lombard in #nosec

Bug#980608: renderdoc autorm

2021-02-13 Thread Jordan Justen

Lucas,

The renderdoc package was marked with autorm based on this bug.

The issue arose because glslang 11.1.0-1 was uploaded to unstable.

I therefore released renderdoc 1.11+dfsg-5 which fixed the
compatibility issue with glslang 11.

Unfortunately, I then found out that glslang 11 was actually blocked
from migrating to testing because of an autopkgtest failure.

Timo released glslang 11.1.0-2 which we thought would fix the
autopkgtest failure. Unfortunately, it still did not fix it.

I reproduced this autopkgtest failure with glslang, and I think I have
a fix for it here:

https://salsa.debian.org/xorg-team/vulkan/glslang/-/merge_requests/3

My concern now is that the renderdoc package only has 5 days left in
the autorm countdown.

Do you have any suggestions for how I can prevent renderdoc from being
removed from testing?

Thanks for your time,

-Jordan


signature.asc
Description: signature

Bug#962495: php7.3-cli, php7.4-cli: segfault on openssl_pkey_get_details

2021-02-13 Thread Thorsten Glaser

Hi Ondřej,

>I guess the small RSA keysize is causing the problem here generating
>invalid key.

oh, interesting. Right, with 512 it works.

Now… if I could recall what I was trying to test with this… ;-)
I should add notes what I was working on to bugreports…

>JFTR I had to specify path to working OpenSSL config to make the
>reproducer work:

Huh, funny, it works for me (with s/384/512/ no crash).

>JFTR I would have been much faster to report this to the upstream bug
>tracker since this doesn't really look like a packaging bug.

Maybe. Upstream tends to ignore people who are running the packaged
versions of their software though, or at least used to; maybe it’s
better now?

bye,
//mirabilos
-- 
(gnutls can also be used, but if you are compiling lynx for your own use,
there is no reason to consider using that package)
-- Thomas E. Dickey on the Lynx mailing list, about OpenSSL

Bug#982647: spyder-reports FTBFS with Spyder 4.2.1

severity 982647 grave
thanks

On Fri, Feb 12, 2021 at 10:48:48PM +0200, Adrian Bunk wrote:
> Source: spyder-reports
> Version: 0.1.1-4
> Severity: serious
> Tags: ftbfs

Thanks for picking this one up, Adrian.  It turns out that it is
actually an upstream bug and this package is currently not being
actively worked on.  And it turns out this is not just a FTBFS bug,
but actually a "this package just doesn't work" bug.  So this bug will
keep it out of testing (which is good).

Best wishes,

   Julian

Bug#982716: [Aptitude-devel] Bug#982716: aptitude: FTBFS: tests failed

Control: tag -1 + confirm

Hi Lucas,

thanks for the bug report!

Lucas Nussbaum wrote:
> Source: aptitude
> Version: 0.8.13-2
> Severity: serious
[…]
> During a rebuild of all packages in sid, your package failed to build
> on amd64.

Indeed, can reproduce it here locally despite it still worked a few
weeks ago.

Wouldn't have expected this at this stage of the freeze. :-/ Wonder
who^Wwhat broke that.

Anyway, will investigate.

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#982750: eclipse-collections: FTBFS with OpenJDK 17: module java.base does not "opens java.lang" to unnamed module

2021-02-13 Thread Emmanuel Bourg

Source: eclipse-collections
Severity: important
Tags: ftbfs sid bookworm
User: debian-j...@lists.debian.org
Usertags: default-java17

eclipse-collections fails to build with OpenJDK 17 due to a test error:


  [INFO] ---
  [INFO]  T E S T S
  [INFO] ---
  [INFO] Running org.eclipse.collections.impl.test.VerifyTest
  [ERROR] Tests run: 92, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 
0.332 s <<< FAILURE! - in org.eclipse.collections.impl.test.VerifyTest
  [ERROR] shallowClone1(org.eclipse.collections.impl.test.VerifyTest)  Time 
elapsed: 0.003 s  <<< ERROR!
  java.lang.reflect.InaccessibleObjectException: Unable to make protected 
native java.lang.Object java.lang.Object.clone() throws 
java.lang.CloneNotSupportedException accessible: module java.base does not 
"opens java.lang" to unnamed module @7b68f21
  at 
org.eclipse.collections.impl.test.VerifyTest.shallowClone1(VerifyTest.java:417)
  
  [ERROR] shallowClone2(org.eclipse.collections.impl.test.VerifyTest)  Time 
elapsed: 0 s  <<< ERROR!
  java.lang.reflect.InaccessibleObjectException: Unable to make protected 
native java.lang.Object java.lang.Object.clone() throws 
java.lang.CloneNotSupportedException accessible: module java.base does not 
"opens java.lang" to unnamed module @7b68f21
  at 
org.eclipse.collections.impl.test.VerifyTest.shallowClone2(VerifyTest.java:430)

Bug#982749: apitrace: Switch from libbsd to libmd

2021-02-13 Thread Guillem Jover

Source: apitrace
Source-Version: 9.0+repack-1
Severity: normal
Tags: patch

Hi!

The MD5 functions in libbsd have been superseded by the ones in the
libmd project, and they might be removed in the next SONAME bump. The
current implementations in libbsd are just wrappers for the real
functions from libmd.

Attached a patch fixing this.

Thanks,
Guillem
diff -Nru apitrace-9.0+repack/debian/control apitrace-9.0+repack/debian/control
--- apitrace-9.0+repack/debian/control	2019-11-29 06:21:20.0 +0100
+++ apitrace-9.0+repack/debian/control	2021-02-13 00:10:39.0 +0100
@@ -17,7 +17,7 @@
  zlib1g-dev,
  libsnappy-dev,
  libpng-dev,
- libbsd-dev,
+ libmd-dev,
  libprocps-dev,
  libgtest-dev,
 Standards-Version: 4.4.0
diff -Nru apitrace-9.0+repack/debian/patches/use-system-md5 apitrace-9.0+repack/debian/patches/use-system-md5
--- apitrace-9.0+repack/debian/patches/use-system-md5	2019-11-29 06:17:05.0 +0100
+++ apitrace-9.0+repack/debian/patches/use-system-md5	2021-02-13 00:14:58.0 +0100
@@ -1,10 +1,14 @@
-Description: Use md5 implementation from system libbsd
+Description: Use md5 implementation from system libmd
 Forwarded: not-needed
 Author: Christopher James Halse Rogers 
 
+---
+ CMakeLists.txt |4 +---
+ 1 file changed, 1 insertion(+), 3 deletions(-)
+
 --- a/CMakeLists.txt
 +++ b/CMakeLists.txt
-@@ -534,9 +534,7 @@ if (CMAKE_EXECUTABLE_FORMAT STREQUAL "EL
+@@ -543,9 +543,7 @@ if (CMAKE_EXECUTABLE_FORMAT STREQUAL "EL
  add_definitions (-DHAVE_BACKTRACE=1)
  endif ()
  
@@ -15,14 +19,3 @@
  
  # We use bundled headers for all Khronos APIs, to guarantee support for both
  # OpenGL and OpenGL ES at build time, because the OpenGL and OpenGL ES 1 APIs
 a/lib/image/image_md5.cpp
-+++ b/lib/image/image_md5.cpp
-@@ -28,7 +28,7 @@
- #include 
- #include "image.hpp"
- 
--#include "md5.h"
-+#include 
- 
- 
- using namespace std;
diff -Nru apitrace-9.0+repack/debian/patches/use-system-snappy apitrace-9.0+repack/debian/patches/use-system-snappy
--- apitrace-9.0+repack/debian/patches/use-system-snappy	2019-11-29 06:17:05.0 +0100
+++ apitrace-9.0+repack/debian/patches/use-system-snappy	2021-02-13 00:14:58.0 +0100
@@ -6,9 +6,14 @@
 Forwarded: not-needed
 Author: Christopher James Halse Rogers 
 
+---
+ CMakeLists.txt  |   10 +-
+ wrappers/CMakeLists.txt |2 +-
+ 2 files changed, 6 insertions(+), 6 deletions(-)
+
 --- a/CMakeLists.txt
 +++ b/CMakeLists.txt
-@@ -476,10 +476,10 @@ if (NOT ENABLE_STATIC_SNAPPY)
+@@ -485,10 +485,10 @@ if (NOT ENABLE_STATIC_SNAPPY)
  find_package (SNAPPY)
  endif ()
  if (ENABLE_STATIC_SNAPPY OR NOT SNAPPY_FOUND)
@@ -23,6 +28,15 @@
  endif ()
  include_directories (${SNAPPY_INCLUDE_DIRS})
  
+@@ -543,7 +543,7 @@ if (CMAKE_EXECUTABLE_FORMAT STREQUAL "EL
+ add_definitions (-DHAVE_BACKTRACE=1)
+ endif ()
+ 
+-set (MD5_LIBRARIES bsd)
++set (MD5_LIBRARIES md)
+ 
+ # We use bundled headers for all Khronos APIs, to guarantee support for both
+ # OpenGL and OpenGL ES at build time, because the OpenGL and OpenGL ES 1 APIs
 --- a/wrappers/CMakeLists.txt
 +++ b/wrappers/CMakeLists.txt
 @@ -79,7 +79,7 @@ target_link_libraries (trace

Bug#982748: python3-pweave: SyntaxWarning: "is not" with a literal.

Package: python3-pweave
Version: 0.25-3
Severity: normal

On installing this package, I get the following warning:

Setting up python3-pweave (0.25-3) ...
/usr/lib/python3/dist-packages/pweave/__init__.py:47: SyntaxWarning: "is not" 
with a literal. Did you mean "!="?
  assert file != "" is not None, "No input specified"

This is clearly not what is intended, as the expression parses as:

  assert ((file != "") and ("" is not None)), "No input specified"

Presumably what is intended is:

  assert file != "", "No input specified"

Best wishes,

   Julian

Bug#982747: libyami-utils: Switch from libbsd to libmd

2021-02-13 Thread Guillem Jover

Source: libyami-utils
Source-Version: 1.3.0-2
Severity: normal
Tags: patch

Hi!

The MD5 functions in libbsd have been superseded by the ones in the
libmd project, and they might be removed in the next SONAME bump. The
current implementations in libbsd are just wrappers for the real
functions from libmd.

Attached a patch fixing this.

Thanks,
Guillem
From 4bebced8e1b654c915c473c4d85ef8dd26cc6c55 Mon Sep 17 00:00:00 2001
From: Guillem Jover 
Date: Sat, 13 Feb 2021 20:29:58 +0100
Subject: [PATCH] Switch from libbsd to libmd

The MD5 functions in libbsd have been superseded by the ones in the
libmd project, and they might disappear in the next SONAME bump.
---
 debian/control  |  2 +-
 debian/patches/0003-use-libmd.patch | 53 +
 debian/patches/series   |  1 +
 3 files changed, 55 insertions(+), 1 deletion(-)
 create mode 100644 debian/patches/0003-use-libmd.patch

diff --git a/debian/control b/debian/control
index 5e4706b..386ea8b 100644
--- a/debian/control
+++ b/debian/control
@@ -8,9 +8,9 @@ Build-Depends:
  libavcodec-dev,
  libavformat-dev,
  libavutil-dev,
- libbsd-dev,
  libegl1-mesa-dev,
  libgles2-mesa-dev,
+ libmd-dev,
  libva-dev,
  libwayland-dev,
  libx11-dev,
diff --git a/debian/patches/0003-use-libmd.patch b/debian/patches/0003-use-libmd.patch
new file mode 100644
index 000..3f161ad
--- /dev/null
+++ b/debian/patches/0003-use-libmd.patch
@@ -0,0 +1,53 @@
+Author: Guillem Jover 
+Subject: Use libmd instead of libbsd for message digest functions
+ The MD5 functions in libbsd have been superseded by the ones
+ in the libmd project. Switch to use those as the ones in libbsd
+ might disappear in the next SONAME bump.
+
+---
+ configure.ac  |2 +-
+ tests/Makefile.am |2 +-
+ tests/decodeinputavformat.cpp |2 +-
+ tests/decodeoutput.cpp|9 +
+ 4 files changed, 4 insertions(+), 11 deletions(-)
+
+--- a/configure.ac
 b/configure.ac
+@@ -250,7 +250,7 @@ fi
+ 
+ #check openssl
+ if test "$enable_md5" = "yes"; then
+-PKG_CHECK_MODULES([LIBBSD], [libbsd],
++PKG_CHECK_MODULES([LIBMD], [libmd],
+ [AC_DEFINE([__ENABLE_MD5__], [1],
+ [Defined to 1 if MD5 API and --enable-md5[default] are enabled])],
+ [])
+--- a/tests/Makefile.am
 b/tests/Makefile.am
+@@ -59,7 +59,7 @@ YAMI_DECODE_LIBS += $(LIBEGL_LIBS) $(LIB
+ endif
+ 
+ if ENABLE_MD5
+-YAMI_DECODE_LIBS += $(LIBBSD_LIBS)
++YAMI_DECODE_LIBS += $(LIBMD_LIBS)
+ endif
+ 
+ YAMI_ENCODE_LIBS = \
+--- a/tests/decodeoutput.cpp
 b/tests/decodeoutput.cpp
+@@ -23,14 +23,7 @@
+ #include "common/VaapiUtils.h"
+ 
+ #if __ENABLE_MD5__
+-// including bsd/md5.h produces a warning with __bounded__ attribute,
+-// libyami-utils chooses to ignore this particular warning by pushing the
+-// current environment, ignoring attributes and then poping to restore the
+-// environment.
+-#pragma GCC diagnostic push
+-#pragma GCC diagnostic ignored "-Wattributes"
+-#include 
+-#pragma GCC diagnostic pop
++#include 
+ #endif
+ 
+ #ifdef __ENABLE_X11__
diff --git a/debian/patches/series b/debian/patches/series
index 1b39d13..471321e 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1,2 +1,3 @@
 0001-decode-avformat-av_register_all-is-deprecated-since-.patch
 0002-decode-avformat-use-LIBAVFORMAT_VERSION_INT-instead.patch
+0003-use-libmd.patch
-- 
2.30.0.284.gd98b1dd5eaa7

Bug#982746: live-build: autopkgtest failure on arm64, armhf and ppc64el: Failed to prepare session write run

2021-02-13 Thread Paul Gevers

Source: live-build
Version: 1:20210122
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 live-build, great.
However, it fails on amd64, armhf and ppc64el. 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=live-build

https://ci.debian.net/data/autopkgtest/testing/arm64/l/live-build/9928393/log.gz

xorriso : NOTE : Environment variable SOURCE_DATE_EPOCH encountered with
value 1611350229
Drive current: -outdev 'stdio:live-image-arm64.hybrid.iso'
Media current: stdio file, overwriteable
Media status : is blank
Media summary: 0 sessions, 0 data blocks, 0 data, 19.7g free
xorriso : NOTE : -as mkisofs: Ignored option '-cache-inodes'
xorriso : WARNING : -volid text problematic as automatic mount point name
xorriso : WARNING : -volid text is too long for Joliet (30 > 16)
xorriso : WARNING : -volid text does not comply to ISO 9660 / ECMA 119 rules
Added to ISO image: directory '/'='/binary'
xorriso : UPDATE :  22 files added in 1 seconds
xorriso : UPDATE :  22 files added in 1 seconds
xorriso : NOTE : Copying to System Area: 432 bytes from file
'/usr/lib/ISOLINUX/isohdpfx.bin'
libisofs: MISHAP : Cannot patch isolinux boot image
xorriso : FAILURE : Failed to prepare session write run
xorriso : NOTE : -return_with SORRY 32 triggered by problem severity FAILURE
E: An unexpected failure occurred, exiting...
P: Begin unmounting filesystems...
P: Saving caches...
Reading package lists...
Building dependency tree...
Reading state information...
autopkgtest [06:09:10]: test build-default-image: ---]



OpenPGP_signature
Description: OpenPGP digital signature

Bug#735497: Bug#954831: Removed package(s) from unstable

2021-02-13 Thread Guillem Jover

Control: reopen -1
Control: reassign -1 gcc-9,gcc-10,gcc-11

On Sat, 2021-02-13 at 13:07:12 +, Debian FTP Masters wrote:
> Version: 1:8.4.0-7+rm

> as the package gcc-8 has just been removed from the Debian archive
> unstable we hereby close the associated bug reports.  We are sorry
> that we couldn't deal with your issue properly.
> 
> For details on the removal, please see https://bugs.debian.org/954831

Bug still relevant, reopening and reassigning.

Thanks,
Guillem

Bug#982691: xdg-desktop-portal-wlr: The package does not include a systemd-user unit

2021-02-13 Thread Arseny Maslennikov

Package: xdg-desktop-portal-wlr
Version: 0.1.0-2
Severity: normal

Dear Maintainer,

Citing the xdg-desktop-portal-wlr FAQ at 
https://github.com/emersion/xdg-desktop-portal-wlr/wiki/FAQ#how-do-i-run-xdpw:
> When a d-bus message is sent to xdg-desktop-portal, it will read a file
> we install called wlr.portal. That file specifies the name of the
> interfaces we implement, the d-bus name that we claim, as well as a
> value for XDG_CURRENT_DESKTOP for which our implementation is
> appropriate. Additionally, the systemd service file maps our d-bus name
> to the actual executable, so that d-bus knows what binary to start when
> xdg-desktop-portal forwards us a request.

% dpkg -L xdg-desktop-portal-wlr
/.
/usr
/usr/libexec
/usr/libexec/xdg-desktop-portal-wlr
/usr/share
/usr/share/dbus-1
/usr/share/dbus-1/services
/usr/share/dbus-1/services/org.freedesktop.impl.portal.desktop.wlr.service
/usr/share/doc
/usr/share/doc/xdg-desktop-portal-wlr
/usr/share/doc/xdg-desktop-portal-wlr/changelog.Debian.gz
/usr/share/doc/xdg-desktop-portal-wlr/copyright
/usr/share/xdg-desktop-portal
/usr/share/xdg-desktop-portal/portals
/usr/share/xdg-desktop-portal/portals/wlr.portal

On desktops running systemd the xdg-desktop-portal-wlr process gets
incorrectly attributed to the user ("session") DBus service.

Could you please install the systemd user service bundled with upstream
source as part of this package?
It is produced by the meson build process from this file:
https://github.com/emersion/xdg-desktop-portal-wlr/blob/68f9759a78935db01dbad34035e5fa2648ca1f71/contrib/systemd/xdg-desktop-portal-wlr.service.in
by this line:
https://github.com/emersion/xdg-desktop-portal-wlr/blob/68f9759a78935db01dbad34035e5fa2648ca1f71/meson.build#L78

This is not going to affect installations without systemd.

Thanks in advance!


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

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

Versions of packages xdg-desktop-portal-wlr depends on:
ii  libc6   2.31-9
ii  libpipewire-0.3-0   0.3.19-3
ii  libsystemd0 247.3-1
ii  libwayland-client0  1.18.0-2~exp1.1
ii  xdg-desktop-portal  1.8.0-3

xdg-desktop-portal-wlr recommends no packages.

xdg-desktop-portal-wlr suggests no packages.

-- no debconf information

Bug#982146: generating an initrd yields multiple "dracut-install: No SOURCE argument given" errors

2021-02-13 Thread Evgeni Golov

On Sat, Feb 13, 2021 at 09:22:58PM +0100, Evgeni Golov wrote:
> I have `hostonly` set, and it passes $(<"$i") to dracut_instmods, which is 
> empty in
> the dock.X case.

https://github.com/dracutdevs/dracut/pull/1096

This should fix it.

Bug#978440: RFS: paperwork/2.0.2-1 -- Personal document manager

2021-02-13 Thread Jérémy Lal

Le sam. 13 févr. 2021 à 11:28, Thomas Perret  a
écrit :

> Hi Jérémy,
>
> >
> > However, i don't quite understand the usefulness of these packages:
> > - openpaperwork-core
> > - openpaperwork-core-doc
> > - openpaperwork-gtk
> > - openpaperwork-gtk-doc
> >
> > I've installed openpaperwork-gtk and it seems it doesn't depend on
> > paperwork-gtk,
> > but maybe i'm missing some documentation, and the long package
> description
> > of
> > openpaperwork-gtk
> > doesn't help either.
>
> In fact, paperwork-gtk depends on openpaperwork-gtk.
>
> I agree that openpaperwork-* packages descriptions are not really helpful.
> The basic idea is that openpaperwork-* is the core of the concept
> implementation of paperwork and paperwork-* are the user interface
> implementations. The upstream idea behind that is to allow different
> implementations of user interfaces (e.g.: web interface, mobile
> interface,…).
>
> With paperwork 2.* there is a full support for plugins. You can check
> which plugins are enabled with command lines:
> $ paperwork-cli plugins list
> $ paperwork-gtk plugins list
> You can check the documentation on openpaperwork-core-doc or online[1]
> which explains the core & plugins aspects.




> >
> > Manually i had to do
> > dpkg -i paperwork-gtk_2.0.2-1_all.deb paperwork-backend_2.0.2-1_all.deb
> >   openpaperwork-core_2.0.2-1_all.deb
> > to get it, and that somehow looks wrong.
> >
> > On the other hand, once installed, it seems to be working all right. I'll
> > try to do actual scanning with it later.
>
> My guess is you will have some issues because paperwork-gtk needs
> plugins provided by openpaperwork-gtk (check the previous command).
>

Indeed openpaperwork-gtk should "Suggests: paperwork-gtk"
(at least).
Also the long description of the packages could be improved to avoid
users confusion.


Maybe the split of package is something that could be discussed,
> especially the openpaperwork-gtk one which doesn't make a lot of sense
> in retrospective.
>

I think splitting is all right as long as it's explained in the long
description,
so that a quick inspection of the package makes it obvious which does what.



> Note that the best way to install paperwork in to select the l10n
> package that correspond to your language, e.g.: paperwork-gtk-l10n-*
> because it depends on all localized dependencies and provides the
> localization translations. I don't like that but I couldn't find a
> correct way to depends on current user's localization.
>

That's nice.
Again, the "paperwork-gtk" package could tell that fact in its long
description.

> i really think it would be a bonus to Bullseye to have paperwork 2.
> > Maybe debian-release will allow it if we ensure the debian packaging is
> all
> > right very quickly.
> >
>
> I (obviously) agree with that ;-)
>

Well bullseye is in soft freeze.  Let's try to upload it asap to unstable,
(along with fixing the packages long descriptions and Suggests: as
described above).

Also i noticed autopkgtests are failing with lots of these (see below).
This needs to be fixed.

Jérémy


autopkgtest [22:23:03]: test paperwork: /usr/bin/paperwork-gtk --help
autopkgtest [22:23:03]: test paperwork: [---
Gio.GError
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/openpaperwork_gtk/fs/gio.py", line
543, in fs_mkdir_p
f.make_directory_with_parents()
gi.repository.GLib.GError: g-io-error-quark: Error creating directory
/home/dev: Permission denied (14)
Callback '>' failed
Failed to initialized plugin ''
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/openpaperwork_gtk/fs/gio.py", line
543, in fs_mkdir_p
f.make_directory_with_parents()
gi.repository.GLib.GError: g-io-error-quark: Error creating directory
/home/dev: Permission denied (14)

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/openpaperwork_core/__init__.py",
line 284, in _init
plugin.init(self)
  File
"/usr/lib/python3/dist-packages/openpaperwork_core/config/backend/configparser.py",
line 201, in init
self.base_path = self.core.call_success("paths_get_config_dir")
  File "/usr/lib/python3/dist-packages/openpaperwork_core/__init__.py",
line 509, in call_success
r = callback(*args, **kwargs)
  File "/usr/lib/python3/dist-packages/openpaperwork_core/paths/xdg.py",
line 27, in paths_get_config_dir
self.core.call_all("fs_mkdir_p", config_dir)
  File "/usr/lib/python3/dist-packages/openpaperwork_core/__init__.py",
line 410, in call_all
callback(*args, **kwargs)
  File "/usr/lib/python3/dist-packages/openpaperwork_gtk/fs/gio.py", line
546, in fs_mkdir_p
raise IOError("fs_mkdir_p({}): {}".format(url, str(exc)))
OSError: fs_mkdir_p(file:///home/dev/.config): g-io-error-quark: Error
creating directory /home/dev: Permission denied (14)
Gio.GError
Traceback (most recent call last):
  File

Bug#982742: this how it looks when the printer IS listed:

2021-02-13 Thread mh




# /usr/lib/cups/backend/usb
DEBUG: Loading USB quirks from "/usr/share/cups/usb". DEBUG: Loaded 181
quirks. DEBUG: list_devices DEBUG: libusb_get_device_list=9 DEBUG2:
Printer found with device ID: MANUFACTURER:OKI DATA CORP;COMMAND
SET:PJL,PCL,IBMPPR,EPSONFX,POSTSCRIPT,PCLXL,IPDL,XPS;MODEL:B432;CLASS:PRINTER;DESCRIPTION:OKI
B432;COMPATIBLE ID:OK_N_7800; Device URI:
usb://OKI%20DATA%20CORP/B432?serial=AK76039718 direct
usb://OKI%20DATA%20CORP/B432?serial=AK76039718 "OKI DATA CORP B432"
"OKI DATA CORP B432" "MANUFACTURER:OKI DATA CORP;COMMAND
SET:PJL,PCL,IBMPPR,EPSONFX,POSTSCRIPT,PCLXL,IPDL,XPS;MODEL:B432;CLASS:PRINTER;DESCRIPTION:OKI
B432;COMPATIBLE ID:OK_N_7800;" ""



I wonder why here are 181 quirks!

Bug#982745: nginx-common: don't enable TLSv1 or TLSv1.1 in default configuration

2021-02-13 Thread didi . debian

Package: nginx-common
Version: 1.18.0-6
Severity: normal
Tags: security, patch
Forwarded: https://salsa.debian.org/nginx-team/nginx/-/merge_requests/7
X-Debbugs-Cc: Debian Security Team 

TLSv1.2 was defined in 2008, so I don't think it's to 'wild' to use that
as a default for security in the default configuration of nginx for Bullseye.
If a user must, (s)he can still enable older TLS versions themselves.
But when upgrading nginx, I got asked to install a less secure version
(ie with TLSv1 and TLSv1.1).

Cheers,
  Diederik

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (990, 'testing'), (300, 'unstable')
Architecture: armhf (armv7l)

Kernel: Linux 4.9.0-6-rpi2 (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 nginx-common depends on:
ii  debconf [debconf-2.0]  1.5.74
ii  lsb-base   11.1.0

nginx-common recommends no packages.

Versions of packages nginx-common suggests:
pn  fcgiwrap   
pn  nginx-doc  
ii  ssl-cert   1.1.0

-- Configuration Files:
/etc/nginx/nginx.conf changed:
user www-data;
worker_processes auto;
pid /run/nginx.pid;
include /etc/nginx/modules-enabled/*.conf;
events {
worker_connections 768;
# multi_accept on;
}
http {
##
# Basic Settings
##
sendfile on;
tcp_nopush on;
types_hash_max_size 2048;
# server_tokens off;
# server_names_hash_bucket_size 64;
# server_name_in_redirect off;
include /etc/nginx/mime.types;
default_type application/octet-stream;
##
# SSL Settings
##
ssl_protocols TLSv1.2 TLSv1.3; # Dropping SSLv3, ref: POODLE
ssl_prefer_server_ciphers on;
##
# Logging Settings
##
access_log /var/log/nginx/access.log;
error_log /var/log/nginx/error.log;
##
# Gzip Settings
##
gzip on;
# gzip_vary on;
# gzip_proxied any;
# gzip_comp_level 6;
# gzip_buffers 16 8k;
# gzip_http_version 1.1;
# gzip_types text/plain text/css application/json 
application/javascript text/xml application/xml application/xml+rss 
text/javascript;
##
# Virtual Host Configs
##
include /etc/nginx/conf.d/*.conf;
include /etc/nginx/sites-enabled/*;
}


-- debconf information:
  nginx/log-symlinks:

Bug#982744: RFS: bdf2sfd/1.1.6-1 -- BDF to SFD converter

2021-02-13 Thread Gürkan Myczko


Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: bdf2sfd
   Version : 1.1.6-1
   Upstream Author : Frederic Cambus 
 * URL : https://github.com/fcambus/bdf2sfd
 * License : BSD-2-clause, ISC
 * Vcs : https://salsa.debian.org/fonts-team/bdf2sfd
   Section : fonts

It builds those binary packages:

  bdf2sfd - BDF to SFD converter

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


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

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


  dget -x 
https://mentors.debian.net/debian/pool/main/b/bdf2sfd/bdf2sfd_1.1.6-1.dsc


Changes since the last upload:

 bdf2sfd (1.1.6-1) experimental; urgency=medium
 .
   * New upstream version.

Regards,
--
  Gürkan Myczko

Bug#982146: generating an initrd yields multiple "dracut-install: No SOURCE argument given" errors

2021-02-13 Thread Evgeni Golov

Hey Thomas,

On Fri, Feb 12, 2021 at 10:40:06PM +0100, Thomas Lange wrote:
> I cannot confirm this problem.
> It works without problems on a bullseye VM.
> 
> Maybe you can strace the dracut call and see which parameters are
> given to the dracut-install call.

attached is the output of `dracut --debug`.

The install call that fails is:
/usr/lib/dracut/dracut-install -D /var/tmp/dracut.OUZAAd/initramfs --kerneldir 
/lib/modules/5.10.0-2-amd64/ -m --silent -s 
'drm_crtc_init|drm_dev_register|drm_encoder_init' -S iw_handler_get_spy

Looking at the lines before that, it seems it looks at
/sys/bus/platform/devices/dock.0/modalias, but that file is empty, so I
guess that's why it's not passing a source to d-install?

The other failures happen after looking at
/sys/bus/platform/devices/dock.1/modalias and
/sys/bus/platform/devices/dock.2/modalias, which are also both empty.

Looking at the code in /usr/lib/dracut/modules.d/50drm/module-setup.sh:

# if the hardware is present, include module even if it is not currently 
loaded,
# as we could e.g. be in the installer; nokmsboot boot parameter will 
disable
# loading of the driver if needed
if [[ $hostonly ]]; then
for i in 
/sys/bus/{pci/devices,platform/devices,virtio/devices,soc/devices/soc?}/*/modalias;
 do
[[ -e $i ]] || continue
if hostonly="" dracut_instmods --silent -s 
"drm_crtc_init|drm_dev_register|drm_encoder_init" -S "iw_handler_get_spy" 
$(<"$i"); then
if strstr "$(modinfo -F filename $(<"$i") 2>/dev/null)" 
radeon.ko; then
hostonly='' instmods amdkfd
fi
fi
done
else
dracut_instmods -o -s "drm_crtc_init|drm_dev_register|drm_encoder_init" 
"=drivers/gpu/drm" "=drivers/staging"
fi

I have `hostonly` set, and it passes $(<"$i") to dracut_instmods, which is 
empty in
the dock.X case.

FWIW, the hardware is a Thinkpad X201s, which has a dock port, but is
not docked right now.

HTH
Evgeni

Bug#982742: cups: config of usb printer now impossible due to usblp and libusb conficting (used to work!)

2021-02-13 Thread Michael Hatzold

Package: cups
Version: 2.3.3op2-3
Severity: important

Dear Maintainer,

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

   * What led up to the situation?

I tried to install an USB printer (oki B432).

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
localhost:631/administration -> new printer

   * What was the outcome of this action?

The printer is not listed anymore and thus I cannot select the neccesary ppd-
file, which used to work this way years ago (2017-2019/20). It still works
*reliably* on a debian/sid(uction) live_ISO from 2020.07. But on my up to date
installation it does not work anymore:

Investigating this on my computer I found the following:

 # uname -r
5.10.0-3-amd64

printer switched off:

# lsmod | grep usb
usbhid 65536  0
hid   147456  2 usbhid,hid_generic
usbcore   323584  6
ehci_pci,usbhid,em28xx_dvb,ehci_hcd,em28xx,uhci_hcd
usb_common 16384  3 usbcore,ehci_hcd,uhci_hcd

# /usr/lib/cups/backend/usb
DEBUG: Loading USB quirks from "/usr/share/cups/usb".
DEBUG: Loaded 98 quirks.
DEBUG: list_devices
DEBUG: libusb_get_device_list=8


printer switched on:

# lsmod | grep usb
usblp  28672  0
usbhid 65536  0
hid   147456  2 usbhid,hid_generic
usbcore   323584  8
ehci_pci,usbhid,usblp,em28xx_dvb,ehci_hcd,em28xx,uhci_hcd
usb_common 16384  3 usbcore,ehci_hcd,uhci_hcd

# /usr/lib/cups/backend/usb
DEBUG: Loading USB quirks from "/usr/share/cups/usb".
DEBUG: Loaded 98 quirks.
DEBUG: list_devices
DEBUG: libusb_get_device_list=9
DEBUG: Failed to detach "usblp" module from 06bc:0357

or

# /usr/lib/cups/backend/usb
DEBUG: Loading USB quirks from "/usr/share/cups/usb".
DEBUG: Loaded 95 quirks.
DEBUG: list_devices
DEBUG: libusb_get_device_list=9
DEBUG: Switching USB device configuration: 0 -> 1
DEBUG: Failed to set configuration 1 for 06bc:0357
DEBUG: Failed to set alternate interface 0 for 06bc:0357: Connection timed out


The difference I can't explain except for the following facts:

Today I downgraded cups and relatives to the version (cups_2.3.3-1_amd64.deb)
of the above Live_ISO. I added a missing package (libusbredirparser1).
Initially it worked, i.e. the printer was visible and installable in the web
admin panel after reloading the page some times. In the printing menue (for
example libreoffice) the printer showed up once. After rebooting and updating
the printer showed up with two slightly different names in the menues, and did
not show up in the administration anymore. I updated, used different kernels,
downgraded again. No more printer in the admin panel list. ***This is a
longstanding problem, not just today!***

I still reliably can install and use the printer using the above mentioned
live-ISO, but with my real installation, the few times I get it installed, it
does not work, as cups is "waiting for the printer becomming available"
(according to the cups job list), whereas the printer shows "ready to print" in
its LED panel.

To it seams usblp and libusb are blocking each other and/or there are timing
issues.

Any help or fix is very appreciated. If needed I could test. But my "skills"
are rather limited.


   * What outcome did you expect instead?

Obviously I would like to install and configure my printer to then be able to
print

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


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

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

Versions of packages cups depends on:
ii  cups-client2.3.3op2-3
ii  cups-common2.3.3op2-3
ii  cups-core-drivers  2.3.3op2-3
ii  cups-daemon2.3.3op2-3
ii  cups-filters   1.28.7-1
ii  cups-ppdc  2.3.3op2-3
ii  cups-server-common 2.3.3op2-3
ii  debconf [debconf-2.0]  1.5.74
ii  ghostscript9.53.3~dfsg-7
ii  libavahi-client3   0.8-5
ii  libavahi-common3   0.8-5
ii  libc6  2.31-9
ii  libcups2   2.3.3op2-3
ii  libgcc-s1  10.2.1-6
ii  libstdc++6 10.2.1-6
ii  libusb-1.0-0   2:1.0.24-2
ii  poppler-utils  20.09.0-3.1
ii  procps 2:3.3.17-2

Versions of packages cups recommends:
ii  avahi-daemon  0.8-5
ii  colord1.4.5-3

Versions of packages cups suggests:
pn  cups-bsd 
pn  cups-pdf 
ii  foomatic-db  20200820-1
ii  smbclient2:4.13.4+dfsg-1
ii  udev 247.3-1

-- debconf information:
  cupsys/backend: lpd, socket, usb,

Bug#975536: dh-python's autopkg tests fail with Python 3.9

2021-02-13 Thread Paul Gevers

Control: tags -1 patch

Hi,

On Mon, 23 Nov 2020 11:25:35 +0100 Matthias Klose  wrote:
> Package: src:dh-python
> Version: 4.20201102
> Severity: serious
> Tags: sid bullseye
> User: debian-pyt...@lists.debian.org
> Usertags: python3.9
> 
> dh-python's autopkg tests fail with Python 3.9. Please make these tests
> independent of the supported/default Python versions.
> 
> https://ci.debian.net/data/autopkgtest/testing/amd64/d/dh-python/8349970/log.gz
> 
> 

I've generate a MR to fix this:
https://salsa.debian.org/python-team/tools/dh-python/-/merge_requests/18

I intent to NMU with that change is this bug isn't fixed soon.

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#888649: apt-listbugs: Fails on ipv6

2021-02-13 Thread Marius Mikucionis

Package: ruby-httpclient
Version: 2.8.3-2
Followup-For: Bug #888649

While we wait for IPv6 adoption, here is a workaround for anyone interested:
configure getaddrinfo(3) to give precedence to IPv4-mapped addresses for sites 
that prefer IPv4 and then apt-listbugs (and many other stuff) just works.

In particular uncomment the following line in /etc/gai.conf:

precedence :::0:0/96  100

Best regards,
Marius

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

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

Versions of packages ruby-httpclient depends on:
ii  ruby1:2.7+2
ii  ruby-http-cookie1.0.3-1
ii  ruby2.1 [ruby-interpreter]  2.1.5-4
ii  ruby2.2 [ruby-interpreter]  2.2.4-1

ruby-httpclient recommends no packages.

ruby-httpclient suggests no packages.

-- no debconf information

Bug#982741: ITP: rtl8821cu -- dkms source for the rtl8821cu network driver

2021-02-13 Thread Alexander GQ Gerasiov

Package: wnpp
Severity: wishlist
Owner: Alexander GQ Gerasiov 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: rtl8821cu
  Version : 5.8.1.7
  Upstream Author : RealTek
* URL : https://github.com/gerasiov/rtl8821cu
* License : GPL-2 with firmware BLOB
  Programming Lang: C
  Description : dkms source for the rtl8821cu network driver

This is the driver for the RealTek RTL8811CU/RTL8821CU USB WiFi controllers,
which are not supported by mainline Linux kernel this days.
Since there is the generated firmware BLOB is the source files, the package
will go to non-free/kernel section of the archive.

Bug#982740: pulseaudio: FTBFS on ppc64el

2021-02-13 Thread Andres Salomon

Package: pulseaudio
Version: 14.2-1
Severity: serious

Pulseaudio is failing to build on ppc64el. The version of pulseaudio in
bullseye suffers from a pretty serious usability bug (see #980836)
which should arguably be a higher severity, but let's focus on getting
14.2-1 built properly.

https://buildd.debian.org/status/logs.php?pkg=pulseaudio=ppc64el

Here's where the ppc64el build fails:


FAIL: cpu-volume-test
=

Running suite(s): CPU
0%: Checks: 1, Failures: 1, Errors: 0
tests/cpu-volume-test.c:81:F:svolume:svolume_orc_test:0: Failed
FAIL cpu-volume-test (exit status: 1)



It's worth noting that 14.1-1 built just fine on ppc64el, and the only
non-debian change between 14.1 and 14.2 is this:

dilinger@e7470:/home/dev/pulseaudio$ git diff v14.1..v14.2
diff --git a/NEWS b/NEWS
index 308eedb17..72dd76fda 100644
--- a/NEWS
+++ b/NEWS
@@ -1,3 +1,14 @@
+PulseAudio 14.2
+
+A bug fix release.
+
+ * Fix port switching when unplugging headphones
+
+Contributors
+
+  Tanu Kaskinen
+
+
 PulseAudio 14.1
 
 A bug fix release.
diff --git a/src/modules/module-switch-on-port-available.c 
b/src/modules/module-switch-on-port-available.c
index f450004ca..99d61a4b8 100644
--- a/src/modules/module-switch-on-port-available.c
+++ b/src/modules/module-switch-on-port-available.c
@@ -278,8 +278,10 @@ static void switch_from_port(pa_device_port *port, struct 
port_pointers pp) {
  * profile is still available in the
  * PA_CORE_HOOK_CARD_PROFILE_AVAILABLE_CHANGED callback, as at this point
  * the profile availability hasn't been updated yet. */
-if (best_port)
-switch_to_port(best_port, pp);
+if (best_port) {
+struct port_pointers best_pp = find_port_pointers(best_port);
+switch_to_port(best_port, best_pp);
+}
 }
 


It doesn't appear to be a temporary thing, as there were multiple
build attempts that all fail in the same spot.

It's likely something that changed in the build environment. For
example, there were some major changes with the check package
between the version that PA 14.1-1 built with (check 0.12.0-0.2)
and the version that PA 14.2-1 built with (check 0.15.2-2). And in
particular, #961781 looks very suspect as a difference in
precision between ppc64el and other architectures, but we also don't
appear to be using long doubles in that specific liborc test. So
¯\_(ツ)_/¯

The version of liborc didn't change between the two builds. There
was only 5 days between the successful and failed builds, so it's
pretty easy to see which packages changed. The check package
seems the most suspect, so it might be worth someone getting on a
ppc64el porter box and trying to build PA 14.2-1 with the older
version of the check package.

Bug#981572: Problem disappeared.

2021-02-13 Thread Gert van de Kraats


After recent Debian updates the problem does not exist anymore.

So I think the bug can be closed.

Gert

Bug#982739: python3-nbconvert: should Depends or Recommends python3-jupyter-client