Bug#1071237: python3-pyunitsystem: the homepage of the project requires login to be accessed

[Diego Caraffini]

Package: python3-pyunitsystem
Version: 1.1.1-2
Severity: normal
Tags: upstream

Dear Maintainer,

the UL to the homepage of the pyunitsystem project:

https://gitlab.esrf.fr/tomotools/pyunitsystem

leads to a login page, so the source is only available after
subscription to gitla.esrf.fr
Since the package isa lso available via pypi, wehre the same URL is
given as the homepage, I surmise this to be an oversight in the
  repository configuration, that the authors intended make fully public
  like others under tomotools.

Note that, at the moment of writing, the version avaialble in pypi is only 
1.1.1-1.


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

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

Versions of packages python3-pyunitsystem depends on:
ii  python3  3.11.8-1

python3-pyunitsystem recommends no packages.

python3-pyunitsystem suggests no packages.

Bug#1065876: texlive-extra-utils: The shebang of script de-macro invokes 'python' rather than 'python3'

[Diego Caraffini]

Package: texlive-extra-utils
Version: 2023.20240207-1
Severity: normal

Dear Maintainer,

I have a paper written in LaTeX that the publisher required to not
contain any user macro, so I used de-macro to produce a distributable
version with a Makefile target.

Today I tried to recreate the distributable paper, and when de-macro was
called, as:
de-macro Paer.tex

I received the error:

bash: /usr/bin/de-macro: cannot execute: required file not found

however, using:

python3 $(which de-macro) Paper.tex

works.

inspecting the installed de-macro script i found that the cause is the
shebang, that is set as:

#!/usr/bin/python -O

which fails unless package python-is-python3 is installed (I didn't
bother checking if it works with python2).

The shebang should be changed to use a versioned python executable,
since python-is-python3 should not be a dependency of any other package.

Thank you for your precious work maintaining the texlive ecosystem.

-- Package-specific info:
IMPORTANT INFORMATION: We will only consider bug reports concerning
the packaging of TeX Live as relevant. If you have problems with
combination of packages in a LaTeX document, please consult your
local TeX User Group, the comp.text.tex user group, the author of
the original .sty file, or any other help resource. 

In particular, bugs that are related to up-upstream, i.e., neither
Debian nor TeX Live (upstream), but the original package authors,
will be closed immediately.

   *** The Debian TeX Team is *not* a LaTeX Help Desk ***

If you report an error when running one of the TeX-related binaries 
(latex, pdftex, metafont,...), or if the bug is related to bad or wrong
output, please include a MINIMAL example input file that produces the
error in your report.

Please run your example with
(pdf)latex -recorder ...
(or any other program that supports -recorder) and send us the generated
file with the extension .fls, it lists all the files loaded during
the run and can easily explain problems induced by outdated files in
your home directory.

Don't forget to also include minimal examples of other files that are 
needed, e.g. bibtex databases. Often it also helps
to include the logfile. Please, never send included pictures!

If your example file isn't short or produces more than one page of
output (except when multiple pages are needed to show the problem),
you can probably minimize it further. Instructions on how to do that
can be found at

http://www.minimalbeispiel.de/mini-en.html (english)

or 

http://www.minimalbeispiel.de/mini.html (german)

##
minimal input file


##
other files

##
 List of ls-R files

-rw-r--r-- 1 root root 2944 Mar  3 23:28 /var/lib/texmf/ls-R
lrwxrwxrwx 1 root root 29 Oct 12  2022 /usr/share/texmf/ls-R -> 
/var/lib/texmf/ls-R-TEXMFMAIN
lrwxrwxrwx 1 root root 31 Feb 14 09:08 /usr/share/texlive/texmf-dist/ls-R -> 
/var/lib/texmf/ls-R-TEXLIVEDIST
lrwxrwxrwx 1 root root 31 Feb 14 09:08 /usr/share/texlive/texmf-dist/ls-R -> 
/var/lib/texmf/ls-R-TEXLIVEDIST
##
 Config files
-rw-r--r-- 1 root root 475 Nov  1 02:41 /etc/texmf/web2c/texmf.cnf
lrwxrwxrwx 1 root root 33 Feb 14 09:08 /usr/share/texmf/web2c/fmtutil.cnf -> 
/var/lib/texmf/fmtutil.cnf-DEBIAN
lrwxrwxrwx 1 root root 32 Feb 14 09:08 /usr/share/texmf/web2c/updmap.cfg -> 
/var/lib/texmf/updmap.cfg-DEBIAN
-rw-r--r-- 1 root root 5334 Mar  3 23:22 
/var/lib/texmf/tex/generic/config/language.dat
##
 Files in /etc/texmf/web2c/
total 8
-rw-r--r-- 1 root root 283 Apr  1  2019 mktex.cnf
-rw-r--r-- 1 root root 475 Nov  1 02:41 texmf.cnf
##
 md5sums of texmf.d
ca40c66f144b4bafc3e59a2dd32ecb9c  /etc/texmf/texmf.d/00debian.cnf

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

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

Versions of packages texlive-extra-utils depends on:
ii  libfile-homedir-perl   1.006-2
ii  libunicode-linebreak-perl  0.0.20190101-1+b6
ii  libyaml-tiny-perl  1.74-1
ii  python33.11.6-1
ii  tex-common 6.18
ii  texlive-base   2023.20240207-1
ii  texlive-binaries   2023.20230311.66589-9
ii  texlive-latex-base 2023.20240207-1
ii  texlive-luatex 2023.20240207-1
ii  texlive-plain-generic  2023.20240207-1

Versions of packages texlive-extra-utils recommends:
ii  ghostscript10.02.1~dfsg-3
ii  liblog-log4perl-perl   1.57-1
ii  ruby

Bug#1008625: RFH: qiskit-terra

[Diego M. Rodriguez]

Hello Andreas,

I concur: the most reasonable course of action would be to remove the 
package(s) [1] [2] [3] from Debian. My availability and skills for working on 
the packages is at the same level or lower than at the time of the RFH, and the 
amount of effort has increased since then.

Best,

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1008625
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1008627
[3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1008626
---
Diego M. Rodriguez

Bug#1001105: RFP: pyvista -- 3D plotting and mesh analysis

[Diego M. Rodriguez]

Control: retitle 1001105 RFP: pyvista -- 3D plotting and mesh analysis
Control: noowner 1001105

Hello,

regrettably, I'm no longer able / interested in packaging this software. I'm 
attempting to officially signal it by removing my ownership, in the hopes it 
can be picked up by other contributor (specially in light of the recent 
blocking dependency from python-scooby).

Best, and thanks Drew for the collaboration that led to the initial ITP,
---
Diego M. Rodriguez

Bug#995581: ITP: python-oauthenticator -- OAuth authenticator for JupyterHub

[Diego M. Rodriguez]

Control: noowner 995581
Control: close 995581

Hello,

I am no longer interested in packaging this module. 

Best,
---
Diego M. Rodriguez

Bug#1007700: but the configured service works

[Diego Roversi]

I had the same problem, but if you use the service configured by the debian 
packages it works fine (like: systemctl omnidb start). For more information you 
can see:

/usr/share/doc/omnidb-server/README.Debian

Regards

-- 
Diego Roversi 

Bug#1053252: lcov: Missing runtime dependency on libdatetime-perl and libcapture-tiny-perl

[Diego Escalante Urrelo]

Package: lcov
Version: 2.0-3
Severity: important
X-Debbugs-Cc: die...@gnome.org

When running `lcov` on a fresh instance of `unstable`:

```
$ lcov --rc lcov_branch_coverage=1 --directory _build --capture --initial 
--output-file bup
Can't locate DateTime.pm in @INC (you may need to install the DateTime module) 
(@INC contains: /usr/lib/lcov /etc/perl 
/usr/local/lib/x86_64-linux-gnu/perl/5.36.0 /usr/local/share/perl/5.36.0 
/usr/lib/x86_64-linux-gnu/perl5/5.36 /usr/share/perl5 
/usr/lib/x86_64-linux-gnu/perl-base /usr/lib/x86_64-linux-gnu/perl/5.36 
/usr/share/perl/5.36 /usr/local/lib/site_perl) at /usr/lib/lcov/lcovutil.pm 
line 19.
BEGIN failed--compilation aborted at /usr/lib/lcov/lcovutil.pm line 19.
Compilation failed in require at /usr/bin/lcov line 102.
BEGIN failed--compilation aborted at /usr/bin/lcov line 102.

$ lcov --rc lcov_branch_coverage=1 --directory _build --capture --initial 
--output-file bup
Can't locate Capture/Tiny.pm in @INC (you may need to install the Capture::Tiny 
module) (@INC contains: /usr/lib/lcov /etc/perl 
/usr/local/lib/x86_64-linux-gnu/perl/5.36.0 /usr/local/share/perl/5.36.0 
/usr/lib/x86_64-linux-gnu/perl5/5.36 /usr/share/perl5 
/usr/lib/x86_64-linux-gnu/perl-base /usr/lib/x86_64-linux-gnu/perl/5.36 
/usr/share/perl/5.36 /usr/local/lib/site_perl) at /usr/lib/lcov/lcovutil.pm 
line 14.
BEGIN failed--compilation aborted at /usr/lib/lcov/lcovutil.pm line 14.
Compilation failed in require at /usr/bin/lcov line 102.
BEGIN failed--compilation aborted at /usr/bin/lcov line 102.
```

I noticed a `Build-Dep` was added in:
  
https://salsa.debian.org/mckinstry/lcov/-/commit/7bf96e9fd753a4805686b1b84e03db8df1cb72fe

But seems the packages are missed as runtime dependencies anyway.

Installing the mentioned packages allows `lcov` to run as before.

Thanks


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

Kernel: Linux 6.5.0-1-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_USER, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=UTF-8 (charmap=UTF-8) (ignored: LC_ALL set 
to en_US.UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages lcov depends on:
ii  gcc  4:13.2.0-1
ii  libjson-perl 4.1-1
ii  libperlio-gzip-perl  0.20-1+b1
ii  perl 5.36.0-9

Versions of packages lcov recommends:
ii  libgd-perl [libgd-gd2-perl]  2.76-4+b1

lcov suggests no packages.

-- no debconf information

Bug#1053100: omnidb-server crash when I try to create a new connection

[Diego Roversi]

Package: omnidb-server
Version: 3.0.3b+ds-4
Severity: important
X-Debbugs-Cc: die...@tiscali.it

After a fresh install of omnidb-server, I connect to localhost:8000 with the
browser, without problem, I can create a new user without problem, but when I
tried to create a new connection to a local postgresql server, it didn't save
it. In the log file I have the following errors:

[09/27/2023 09:50:03] INFO [OmniDB_app.Init:219] Running Database Migrations...
[09/27/2023 09:50:03] INFO [OmniDB_app.Init:19] Attempting to migrate users,
connections and monitoring units and snippets from OmniDB 2 to 3...
[09/27/2023 09:50:03] INFO [OmniDB_app.Init:19] Source database file does not
contain the required tables, skipping...
[09/27/2023 09:50:04] INFO [OmniDB_app.Init:543] Starting OmniDB server...
[09/27/2023 09:50:04] INFO [OmniDB_app.Init:477] Checking port availability...
[09/27/2023 09:50:04] INFO [OmniDB_app.Init:521] Starting server OmniDB 3.0.3b
at 127.0.0.1:8000.
[09/27/2023 10:00:59] INFO [OmniDB_app.views.login:162] User "admin" logged in.
[09/27/2023 10:04:04] ERROR [django.request:224] Internal Server Error:
/save_connection/
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/django/core/handlers/exception.py", line
47, in inner
response = get_response(request)
   ^
  File "/usr/lib/python3/dist-packages/django/utils/deprecation.py", line 119,
in __call__
response = self.process_response(request, response)
   
  File "/usr/lib/python3/dist-packages/django/contrib/sessions/middleware.py",
line 61, in process_response
request.session.save()
  File "/usr/lib/python3/dist-packages/django/contrib/sessions/backends/db.py",
line 83, in save
obj = self.create_model_instance(data)
  
  File "/usr/lib/python3/dist-packages/django/contrib/sessions/backends/db.py",
line 70, in create_model_instance
session_data=self.encode(data),
 ^
  File "/usr/lib/python3/dist-
packages/django/contrib/sessions/backends/base.py", line 114, in encode
return signing.dumps(
   ^^
  File "/usr/lib/python3/dist-packages/django/core/signing.py", line 110, in
dumps
return TimestampSigner(key, salt=salt).sign_object(obj,
serializer=serializer, compress=compress)
^^
  File "/usr/lib/python3/dist-packages/django/core/signing.py", line 172, in
sign_object
data = serializer().dumps(obj)
   ^^^
  File "/usr/lib/python3/dist-packages/django/contrib/sessions/serializers.py",
line 14, in dumps
return pickle.dumps(obj, self.protocol)
   
AttributeError: Can't pickle local object
'show_extra_help_command..placeholder'
[09/27/2023 10:04:14] ERROR [django.request:224] Internal Server Error:
/save_connection/
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/django/core/handlers/exception.py", line
47, in inner
response = get_response(request)
   ^
  File "/usr/lib/python3/dist-packages/django/utils/deprecation.py", line 119,
in __call__
response = self.process_response(request, response)
   
  File "/usr/lib/python3/dist-packages/django/contrib/sessions/middleware.py",
line 61, in process_response
request.session.save()
  File "/usr/lib/python3/dist-packages/django/contrib/sessions/backends/db.py",
line 83, in save
obj = self.create_model_instance(data)
  
  File "/usr/lib/python3/dist-packages/django/contrib/sessions/backends/db.py",
line 70, in create_model_instance
session_data=self.encode(data),
 ^
  File "/usr/lib/python3/dist-
packages/django/contrib/sessions/backends/base.py", line 114, in encode
return signing.dumps(
   ^^
  File "/usr/lib/python3/dist-packages/django/core/signing.py", line 110, in
dumps
return TimestampSigner(key, salt=salt).sign_object(obj,
serializer=serializer, compress=compress)
^^
  File "/usr/lib/python3/dist-packages/django/core/signing.py", line 172, in
sign_object
data = serializer().dumps(obj)
   ^^^
  File "/usr/lib/python3/dist-packages/django/contrib/sessions/serializers.py",
line 14, in dumps
return pickle.dumps(obj, self.protocol)
   
AttributeError: Can't pickle local object
'show_extra_help_command..placeholder'
[09/27/2023 10:04:35] ERROR [django.request:224] Internal Server Error:
/save_connection/
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/django/core/handlers/exception.py", line
47, in inner
response = 

Bug#1032447: Error debian Acer Nitro 5

[Diego Santos]

package: installation report Boot method:  Image version:  Data:  Machine:  External use hdc 1 2 with dual boot
windows I tested it without it as main Output from lspci -knn (or lspci
-nn): Basic system installation checklist: [O] = OK, [E] = Error (describe
below), [ ] = did not try Initial boot: [ ]ok Detect network card: [ ] ok
Configure network: [ ],,ok free kernel mode Detect installation medium: [ ]
gave installation error Load installer modules: [ ] loads davfail Detect
hard drives: [ ] ok Partition hard drives: [ ] ok Install base system: [ ]
ok Clock/time zone setting: [ ]ok Set username/password: [ ]ok Installation
tasks: [ ] ok Install boot loader: [ ] ok Installation total: [ ] not
installed Accepts Ubuntu 20.04 kernel firmware well

Bug#1028413: (no subject)

[Diego Roversi]

Hi,

  this bug is still there for me. All packages updated to bookworm/testing. Let 
me know, if you need more info.

Thanks in advance,
  Diego.

Bug#1026904: shellinabox: move javascript code in main page to a separate file

[Diego Roversi]

Package: shellinabox
Version: 2.21+b1
Severity: normal
X-Debbugs-Cc: die...@tiscali.it

Dear Maintainer,

  thanks for maintaing the package. Just a simple request, it's possible to 
move the javascript in the main page in to an external .js file? So that we can 
easily enable CSP (for example in a reverse proxy) for more protection

Thanks in advance,
  Diego.



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

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

Versions of packages shellinabox depends on:
ii  adduser3.118
ii  libc6  2.31-13+deb11u5
ii  libpam0g   1.4.0-9+deb11u1
ii  libssl1.1  1.1.1n-0+deb11u3
ii  lsb-base   11.1.0
ii  zlib1g 1:1.2.11.dfsg-2+deb11u2

shellinabox recommends no packages.

Versions of packages shellinabox suggests:
ii  openssl  1.1.1n-0+deb11u3

-- Configuration Files:
/etc/default/shellinabox changed [not included]

-- no debconf information

Bug#917868: xfce4-pulseaudio-plugin: Notifications when volume changes causes plugin to temporarily freeze

[Diego Ongaro]

I ran into this same problem when my notifications daemon was not
loading correctly. That was due to #899377 because I had
plasma-workspace installed. It also caused similar stalls with
nm-applet.

Once I had notifications working (and I verified that with
notify-send), I was able to re-enable the "Show notifications when
volume changes" and it worked fine.

Hope this helps someone,
Diego

Bug#1016505: patch: Fix `Incorrect netdev->dev_addr` errors in linux-5.17+ patch

[Diego Escalante Urrelo]

Package: broadcom-sta-dkms
Version: 6.30.223.271-22
Followup-For: Bug #1016505
X-Debbugs-Cc: die...@gnome.org

Bump.

I have pushed this and other fixes as a branch in salsa:
  https://salsa.debian.org/diegoe/broadcom-sta/-/commits/2022-various-fixes

At least the patch in this bug report is important, the other stuff is
mostly lintian warnings and nitpicks.

Thanks!

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

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

Versions of packages broadcom-sta-dkms depends on:
ii  dkms  3.0.6-4

Versions of packages broadcom-sta-dkms recommends:
ii  wireless-tools  30~pre9-13.1

broadcom-sta-dkms suggests no packages.

-- no debconf information

Bug#1016505: patch: Fix `Incorrect netdev->dev_addr` errors in linux-5.17+ patch

[Diego Escalante Urrelo]

Source: broadcom-sta
Version: 6.30.223.271-20
Severity: important
Tags: patch
X-Debbugs-Cc: die...@gnome.org

Dear Maintainer,

The patch for linux-5.17 deprecations incorrectly inverted the src/dest
of the copying of MAC addresses.

I have pushed a branch with the gbp-processed patch:
  https://salsa.debian.org/diegoe/broadcom-sta/-/tree/debian-diegoe-202208

I _think_ this potentially fixes two recent bugs that have the trace/bug
in the logs, but my card is a different PHY so I can't confirm that.

Here's the commit log for further explanation:

```
  d/patches: Fix the linux-5.17 deprecations patch

  The patch was enough to get things to build, but it accidentally
  inverted the direction of the copy of a few addresses.

  This was causing traces when the device address was set in the driver:

  ```
  wl :03:00.0 wlp3s0: Current addr:  NN NN NN NN NN NN 00 00 00 00 00 
00 00 00 00
  wl :03:00.0 wlp3s0: Expected addr: 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00
  [ cut here ]
  netdevice: wlp3s0: Incorrect netdev->dev_addr
  WARNING: CPU: 3 PID: 1178 at net/core/dev_addr_lists.c:517 
dev_addr_check.cold+0x43/0x7d
  (...)
  ```

  (where NN is the device MAC)

  Apparently this might be enough in some cards to make it impossible to
  connect to a network. See bugs below.

  See: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1011529
  See: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1016426
```

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

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

Bug#1016052: dracut: Missing `lz4` in `dracut-initramfs-restore`

[Diego Escalante Urrelo]

Package: dracut
Version: 056-3
Severity: normal
X-Debbugs-Cc: die...@gnome.org

Dear Maintainer,

In my logs I noticed:

/usr/lib/dracut/dracut-initramfs-restore: line 58: lz4: command not found

>From the context of the code, it seems to be a missing dependency.


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

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

Versions of packages dracut depends on:
ii  dracut-core  056-3

dracut recommends no packages.

Versions of packages dracut suggests:
pn  dracut-network  

-- no debconf information

Bug#1016051: dracut: Wrong path to `$prefix/dbus/system.d/bluetooth.conf`

[Diego Escalante Urrelo]

Package: dracut
Version: 056-3
Severity: normal
X-Debbugs-Cc: die...@gnome.org

Dear Maintainer,

When dracut rebuilds, I get the following errors:

```
dracut-install: ERROR: installing '/usr/share/dbus-1/system.d/bluetooth.conf'
dracut: FAILED: /usr/lib/dracut/dracut-install -D 
/var/tmp/dracut.Cho3S1/initramfs -a /usr/share/dbus-1/system.d/bluetooth.conf 
/lib/systemd/system/bluetooth.target /lib/systemd/system/bluetooth.service 
bluetoothctl
```

I'm guessing the above should rather to point to
`/etc/dbus-1/system.d/bluetooth.conf`, since my system doesn't have any
of the other.


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

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

Versions of packages dracut depends on:
ii  dracut-core  056-3

dracut recommends no packages.

Versions of packages dracut suggests:
pn  dracut-network  

-- no debconf information

Bug#1015922: dracut-core: grep missing in 90lvm/lvm_scan

[Diego Escalante Urrelo]

Package: dracut-core
Version: 056-3
Severity: normal
X-Debbugs-Cc: die...@gnome.org

Dear Maintainer,

I have noticed the following log output during boot:

```
dracut-initqueue[696]: /sbin/lvm_scan: 55: grep: not found
dracut-initqueue[695]:   Configuration node devices/filter not found
dracut-initqueue[699]: /sbin/lvm_scan: 61: grep: not found
dracut-initqueue[698]:   Configuration node devices/global_filter not found
dracut-initqueue[682]: Scanning devices dm-0  for LVM logical volumes 
debian-vg/debian-vg-swap
dracut-initqueue[682]: debian-vg/debian-vg-root
dracut-initqueue[702]:   WARNING: File locking is disabled.
dracut-initqueue[682]:   debian-vg/debian-vg-root linear
dracut-initqueue[682]:   debian-vg/debian-vg-swap linear
```

It seems it started happening some time in the last few months, but I
can't reliably point to a specific version.

Things still work, but FWIW I have the simplest lvm setup necessary for
LUKS.

Thanks

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

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

Versions of packages dracut-core depends on:
ii  cpio   2.13+dfsg-7
ii  e2fsprogs  1.46.5-2
ii  kmod   30+20220630-2
ii  kpartx 0.8.8-1
ii  libc6  2.33-8
ii  libkmod2   30+20220630-2
ii  udev   251.3-1

Versions of packages dracut-core recommends:
ii  binutils   2.38.90.20220713-2
ii  console-setup  1.209
ii  cryptsetup 2:2.4.3-1+b1
ii  dmraid 1.0.0.rc16-11
ii  dmsetup2:1.02.183-2
ii  lvm2   2.03.15-2
ii  mdadm  4.2-4
ii  pigz   2.6-1
ii  pkg-config 0.29.2-1
ii  systemd251.3-1

dracut-core suggests no packages.

-- no debconf information

Bug#1008625: RFH: qiskit-terra

[Diego M. Rodriguez]

Package: wnpp
Severity: normal
X-Debbugs-Cc: debian-de...@lists.debian.org
Control: affects -1 src:qiskit-terra

Hello,

I request help with maintaining this package. With upstream moving faster than 
originally anticipated and with my co-maintainer and mentor retiring from 
Debian, I no longer have the bandwidth and skills to realistically maintain the 
packaging effort on par with the latest upstream releases by myself.

One of the challenges in order to bring back the package to speed is packaging 
additional dependencies (~3 required, some of them not pure Python) into 
Debian. The package also has a strong relationship with (also RFH-ed) 
qiskit-aer, and ideally help would also be needed with the latter (potentially 
expanding to other future qiskit-related packages).

Best,
---
Diego M. Rodriguez

Bug#1008627: RFA: qiskit-ibmq-provider

[Diego M. Rodriguez]

Package: wnpp
Severity: normal
Control: affects -1 src:qiskit-ibmq-provider

Hello,

I request adoption (or likely removal) of this package. Upstream is phasing out 
this package [1] in favor of similar alternatives, and I no longer have the 
bandwidth and energy to maintain the packaging effort.

One of the new packages that will replace the current one 
("qiskit-ibm-provider") shares many similarities with the current package - 
ideally, the new maintainer would be able to reuse most of the current effort. 
Please note that this package has a strong relationship with (RFH-ed) 
qiskit-terra, and help/coordination would be encouraged/needed.

Best,

[1] https://github.com/Qiskit/qiskit-ibmq-provider/issues/1042
---
Diego M. Rodriguez

Bug#1008626: RFH: qiskit-aer

[Diego M. Rodriguez]

Package: wnpp
Severity: normal
X-Debbugs-Cc: debian-de...@lists.debian.org
Control: affects -1 src:qiskit-aer

Hello,

I request help with maintaining this package. With upstream moving faster than 
originally anticipated and with my co-maintainer and mentor retiring from 
Debian, I no longer have the bandwidth and skills to realistically maintain the 
packaging effort on par with the latest upstream releases by myself.

Since the version currently packaged in Debian, upstream has included usage of 
conan along with a number of dependencies and changes. The package also has a 
strong relationship with (also RFH-ed) qiskit-terra, and ideally help would 
also be needed with the latter (potentially expanding to other qiskit-related 
packages).

Best,
---
Diego M. Rodriguez

Bug#1001105: RFP: pyvista -- 3D plotting and mesh analysis

[Diego M. Rodriguez]

Control: retitle -1 ITP: pyvista -- 3D plotting and mesh analysis
Control: owner -1 !

Hello,

On Sat, 04 Dec 2021 12:51:13 +0100 Drew Parsons  wrote:
> Well suited to team maintenance under the Debian Python Team, but
> could be adopted by more specialized teams such as the Debian Science
> Team.

I intend to package this software, along with its unpackaged
dependencies ("scooby"), under the umbrella of the Debian Python Team.

Best,
-- 
Diego M. Rodriguez

Bug#1002318: python-nest-asyncio: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p "3.10 3.9" returned exit code 13

[Diego M. Rodriguez]

Control: tag -1 pending

Hello Lucas,

thanks for the bug report - I have prepared an upload of a new upstream
version that includes a fix [2] for Python 3.10 support.

Best,

[1] https://salsa.debian.org/python-team/packages/python-nest-asyncio
[2]
https://github.com/erdewit/nest_asyncio/commit/245dd5bd5902c724cd5478c865769f69c154f609

-- 
Diego M. Rodriguez

Bug#1001424: python-nest-asyncio: (autopkgtest) needs update for python3.10: TypeError: gather() got an unexpected keyword argument 'loop'

[Diego M. Rodriguez]

Control: tag -1 pending

Hi Paul,

thanks for the bug report - I have prepared an upload of a new upstream
version that includes a fix [2] for Python 3.10 support.

Best,

[1] https://salsa.debian.org/python-team/packages/python-nest-asyncio
[2]
https://github.com/erdewit/nest_asyncio/commit/245dd5bd5902c724cd5478c865769f69c154f609

-- 
Diego M. Rodriguez

Bug#1000457: virtualbox: Outdated dependency on libgsoap-2.8.104

[Diego Caraffini]

Package: virtualbox
Version: 6.1.28-dfsg-1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

Trying to upgrade virtualbox to Version: 6.1.28-dfsg-1 aptitude was not
able to resolve dependencies. I uninstalled the previous version and
then tryed to install again, but foud that virtualbox depends on
libgsoap-2.8.104, that is not available in unstable.

Proposed solution:
  depend on libgsoap-2.8.117


Thank you for maintaining the package.


*** 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 ***


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

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

Versions of packages virtualbox depends on:
ii  adduser   3.118
ii  iproute2  5.15.0-1
ii  libc6 2.32-4
ii  libcurl3-gnutls   7.79.1-2
ii  libdevmapper1.02.12:1.02.175-2.1
ii  libgcc-s1 11.2.0-10
ii  libgl11.3.4-2+b1
pn  libgsoap-2.8.104  
ii  liblzf1   3.6-3
ii  libopus0  1.3.1-0.1
ii  libpng16-16   1.6.37-3
ii  libpython3.9  3.9.9-1
ii  libsdl1.2debian   1.2.15+dfsg2-6
ii  libssl1.1 1.1.1l-1
ii  libstdc++611.2.0-10
ii  libvncserver1 0.9.13+dfsg-3
ii  libvpx6   1.10.0-2
ii  libx11-6  2:1.7.2-2+b1
ii  libxcursor1   1:1.2.0-2
ii  libxml2   2.9.12+dfsg-5+b1
ii  libxt61:1.2.0-1
ii  procps2:3.3.17-5
ii  python3   3.9.7-1
ii  python3.9 3.9.9-1
ii  virtualbox-dkms [virtualbox-modules]  6.1.28-dfsg-1~fto11+1
ii  zlib1g1:1.2.11.dfsg-2

Versions of packages virtualbox recommends:
ii  libqt5core5a5.15.2+dfsg-13
ii  libqt5gui5  5.15.2+dfsg-13
ii  libqt5opengl5   5.15.2+dfsg-13
ii  libqt5widgets5  5.15.2+dfsg-13
ii  libxcb1 1.14-3
ii  libxext62:1.3.4-1
pn  virtualbox-qt   

Versions of packages virtualbox suggests:
pn  vde2
pn  virtualbox-guest-additions-iso  

Bug#995450: buster->bullseye: octave segfaulting during configure (seems unrelated to #992405)

[Diego Zuccato]

Hello Sébastien.

I think it's quite important to have it fixed in stable since it's quite 
tricky to debug and results in an error while installing or upgrading 
octave. Does that qualify as a major impact? :)


Tks.

Il 05/11/2021 14:35, Sébastien Villemot ha scritto:

Control: retitle -1 segfault when running out of memory
Control: tags -1 = upstream fixed-upstream

Dear Diego,

Le vendredi 05 novembre 2021 à 06:34 +0100, Diego Zuccato a écrit :

Il 04/11/2021 12:27, Sébastien Villemot ha scritto:


I happen to have access to a machine with exactly the same CPU (and
Debian Bullseye). I fail to replicate your problem there. I can start
octave with libopenblas0-pthread and there is no segfault.
So there must be another factor at play.Uhm...


I use pam-limits and cgroups to limit the memory available to users.


I confirm that I can replicate the segfault with:

$ ulimit -d 1024000
$ octave

The crash occurs in function blas_memory_alloc(), as in your backtrace.

Thanks to your analysis, upstream has fixed the issue. I will therefore
fix it in Debian unstable (either with the next upstream release, or
possibly even earlier with a targeted patch).

Are you interested in having this bug fixed in Debian stable
(bullseye)? In theory this possibility is only open for bugs of
severity “important” or higher, while the bug is currently marked with
severity “normal”. A bug of severity important is defined as having “a
major effect on the usability of a package, without rendering it
completely unusable to everyone”. What do you think?

Best,



--
Diego Zuccato
DIFA - Dip. di Fisica e Astronomia
Servizi Informatici
Alma Mater Studiorum - Università di Bologna
V.le Berti-Pichat 6/2 - 40127 Bologna - Italy
tel.: +39 051 20 95786

Bug#995450: buster->bullseye: octave segfaulting during configure (seems unrelated to #992405)

[Diego Zuccato]

.

Octave was configured for "x86_64-pc-linux-gnu".

Additional information about Octave is available at https://www.octave.org.

Please contribute if you find this software useful.
For more information, visit https://www.octave.org/get-involved.html

Read https://www.octave.org/bugs.html to learn how to submit bug reports.
For information about changes from previous versions, type 'news'.

octave:1> version -blas
ans = OpenBLAS (config: OpenBLAS 0.3.13 NO_LAPACKE DYNAMIC_ARCH 
NO_AFFINITY Sandybridge MAX_THREADS=64)

octave:2>
-8<--

BTW seems my finding was correct :)
https://github.com/xianyi/OpenBLAS/issues/3441

--
Diego Zuccato
DIFA - Dip. di Fisica e Astronomia
Servizi Informatici
Alma Mater Studiorum - Università di Bologna
V.le Berti-Pichat 6/2 - 40127 Bologna - Italy
tel.: +39 051 20 95786

Bug#995450: buster->bullseye: octave segfaulting during configure (seems unrelated to #992405)

[Diego Zuccato]

Il 04/11/2021 12:27, Sébastien Villemot ha scritto:

So it seems that your problem is somehow related to multithreading
(with pthread) in openblas.

Exactly.


However I fail to understand the relationship with cdo. Could you
please expand on that?

cdo installed libopenblas-pthread as a dependency, and that broke octave.


I happen to have access to a machine with exactly the same CPU (and
Debian Bullseye). I fail to replicate your problem there. I can start
octave with libopenblas0-pthread and there is no segfault.
So there must be another factor at play.
Possible. That's a system that got upgraded many times (started as a 
Debian 6.0, IIRC!)



Do you confirm that octave and all its dependencies are pristine Debian
packages from Debian Bullseye? (and not binaries compiled by yourself
or packages obtained from another suite)
Yes. Till yesterday, the only packages not from Debian official repos 
were the PBIS ones (today I added Glusterfs repos).



Is there something special in /usr/local?

Nothing except pbis-open and some python scripts.


Is the segfault triggered by some computation? In particular, is there
something in your ~/.octaverc, ~/.config/octave/octaverc or
/etc/octaverc?

No. Just trying to run octave from a new user triggers the error.


Is the result different if your run “octave-cli” instead of “octave”
(to disable the GUI)?

No.
Not using octave myself, I noticed it because apt failed during the last 
dist-upgrade, and it uses octave-cli .


--
Diego Zuccato
DIFA - Dip. di Fisica e Astronomia
Servizi Informatici
Alma Mater Studiorum - Università di Bologna
V.le Berti-Pichat 6/2 - 40127 Bologna - Italy
tel.: +39 051 20 95786

Bug#966141: Please retest with current version

[Diego Roversi]

On Thu, 21 Oct 2021 16:10:58 +0100
Neil Williams  wrote:

> Version 18.9 is now only in oldstable - buster.
> 
> Stable has version 20.8 and testing/unstable have 21.4
> 
> Please can you retest with, preferably, 21.4 as the relevant code has
> changed substantially compared to 18.9
> 
 
I confirm that there is no problem with the new stable:

 Preparing to unpack .../black_20.8b1-4_all.deb ...
 Unpacking black (20.8b1-4) ...
 Setting up black (20.8b1-4) ...
 Processing triggers for man-db (2.9.4-2) ...


Thanks,
  Diego.

-- 
Diego Roversi 

Bug#995450: buster->bullseye: octave segfaulting during configure (seems unrelated to #992405)

[Diego Zuccato]

usato 
/usr/lib/x86_64-linux-gnu/openblas-pthread/libblas.so.3 per fornire 
/usr/lib/x86_64-linux-gnu/libblas.so.3 (libblas.so.3-x86_64-linux-gnu) 
in modalità automatica
update-alternatives: viene usato 
/usr/lib/x86_64-linux-gnu/openblas-pthread/liblapack.so.3 per fornire 
/usr/lib/x86_64-linux-gnu/liblapack.so.3 
(liblapack.so.3-x86_64-linux-gnu) in modalità automatica
update-alternatives: viene usato 
/usr/lib/x86_64-linux-gnu/openblas-pthread/libopenblas.so.0 per fornire 
/usr/lib/x86_64-linux-gnu/libopenblas.so.0 
(libopenblas.so.0-x86_64-linux-gnu) in modalità automatica

Elaborazione dei trigger per libc-bin (2.31-13+deb11u2)...
root@str957-cluster:~# octave
X11 connection rejected because of wrong authentication.
octave: unable to open X11 DISPLAY
octave: disabling GUI features
Errore di segmentazione (core dump creato)
root@str957-cluster:~# apt remove libopenblas0-pthread
Lettura elenco dei pacchetti... Fatto
Generazione albero delle dipendenze... Fatto
Lettura informazioni sullo stato... Fatto
I seguenti pacchetti saranno RIMOSSI:
  libopenblas0-pthread libopenblas0-pthread-dbgsym
0 aggiornati, 0 installati, 2 da rimuovere e 0 non aggiornati.
Dopo quest'operazione, verranno liberati 57,8 MB di spazio su disco.
Continuare? [S/n]
(Lettura del database... 295084 file e directory attualmente installati.)
Rimozione di libopenblas0-pthread-dbgsym:amd64 (0.3.13+ds-3)...
Rimozione di libopenblas0-pthread:amd64 (0.3.13+ds-3)...
update-alternatives: viene usato 
/usr/lib/x86_64-linux-gnu/openblas-serial/libblas.so.3 per fornire 
/usr/lib/x86_64-linux-gnu/libblas.so.3 (libblas.so.3-x86_64-linux-gnu) 
in modalità automatica
update-alternatives: viene usato 
/usr/lib/x86_64-linux-gnu/openblas-serial/liblapack.so.3 per fornire 
/usr/lib/x86_64-linux-gnu/liblapack.so.3 
(liblapack.so.3-x86_64-linux-gnu) in modalità automatica
update-alternatives: viene usato 
/usr/lib/x86_64-linux-gnu/openblas-serial/libopenblas.so.0 per fornire 
/usr/lib/x86_64-linux-gnu/libopenblas.so.0 
(libopenblas.so.0-x86_64-linux-gnu) in modalità automatica

Elaborazione dei trigger per libc-bin (2.31-13+deb11u2)...
root@str957-cluster:~# octave
X11 connection rejected because of wrong authentication.
octave: unable to open X11 DISPLAY
octave: disabling GUI features
X11 connection rejected because of wrong authentication.
GNU Octave, version 6.2.0
Copyright (C) 2021 The Octave Project Developers.
This is free software; see the source code for copying conditions.
There is ABSOLUTELY NO WARRANTY; not even for MERCHANTABILITY or
FITNESS FOR A PARTICULAR PURPOSE.  For details, type 'warranty'.

Octave was configured for "x86_64-pc-linux-gnu".

Additional information about Octave is available at https://www.octave.org.

Please contribute if you find this software useful.
For more information, visit https://www.octave.org/get-involved.html

Read https://www.octave.org/bugs.html to learn how to submit bug reports.
For information about changes from previous versions, type 'news'.

octave:1> version -blas
ans = OpenBLAS (config: OpenBLAS 0.3.13 NO_LAPACKE DYNAMIC_ARCH 
NO_AFFINITY Sandybridge SINGLE_THREADED)

octave:2>
-8<--

Hope it helps to pinpoint the issue.

Diego

Il 02/11/2021 11:45, Sébastien Villemot ha scritto:

Control: reassign -1 libopenblas0 0.3.13+ds-3
Control: tags -1 + moreinfo

Dear Diego,

Le vendredi 08 octobre 2021 à 09:04 +0200, Diego Zuccato a écrit :

Continuing a triage, I noticed that removing cdo and its dependencies
(including libopenblas0) and reinstalling octave got rid of the
segfault. Reinstalling cdo reintroduced the segfault.


Thanks for your report.

This seems to be a bug in openblas. Reassigning accordingly.

Could you please add the following information:
- the openblas flavour that you’re using, as reported by:
   update-alternatives --display libopenblas.so.0-x86_64-linux-gnu
- your CPU model (as reported by “lscpu”)
- the openblas kernel used at runtime, as reported by “version -blas”
run from the octave prompt

Best regards,



--
Diego Zuccato
DIFA - Dip. di Fisica e Astronomia
Servizi Informatici
Alma Mater Studiorum - Università di Bologna
V.le Berti-Pichat 6/2 - 40127 Bologna - Italy
tel.: +39 051 20 95786

Bug#995454: closed by Sandro Tosi (Re: Bug#995454: python3-numpy: segfault and core dump with a simple "import numpy")

[Diego Zuccato]

Hi Sandro.

I digged a bit more and it seems a bad interaction with 
libopenblas0-pthread (in my case it gets installed by cdo package, but 
it's a largely used lib, IIUC):

# gdb /usr/bin/python3 core
GNU gdb (Debian 10.1-1.7) 10.1.90.20210103-git
Copyright (C) 2021 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
<http://gnu.org/licenses/gpl.html>

This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/bin/python3...
(No debugging symbols found in /usr/bin/python3)
[New LWP 314439]
[New LWP 314432]
[New LWP 314434]
[New LWP 314435]
[New LWP 314433]
[New LWP 314436]
[New LWP 314438]
[New LWP 314437]
[New LWP 314440]
[New LWP 314429]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `python3'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x in ?? ()
[Current thread is 1 (Thread 0x7f6e9d75e700 (LWP 314439))]
(gdb) bt
#0  0x in ?? ()
#1  0x7f6ed15c9709 in blas_memory_alloc () from 
/usr/lib/x86_64-linux-gnu/libopenblas.so.0
#2  0x7f6ed15c9f04 in ?? () from 
/usr/lib/x86_64-linux-gnu/libopenblas.so.0
#3  0x7f6ed42e1ea7 in start_thread (arg=) at 
pthread_create.c:477
#4  0x7f6ed4074def in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:95


I get the same segfault (NULL access in blas_memory_alloc) when 
installing/running octave after installing cdo.


Can the bug be reopened and rerouted to libopenblas0 ?

Il 05/10/2021 05:03, Debian Bug Tracking System ha scritto:

This is an automatic notification regarding your Bug report
which was filed against the python3-numpy package:

#995454: python3-numpy: segfault and core dump with a simple "import numpy"

It has been closed by Sandro Tosi .

Their explanation is attached below along with your original report.
If this explanation is unsatisfactory and you have not received a
better one in a separate message then please contact Sandro Tosi 
 by
replying to this email.




--
Diego Zuccato
DIFA - Dip. di Fisica e Astronomia
Servizi Informatici
Alma Mater Studiorum - Università di Bologna
V.le Berti-Pichat 6/2 - 40127 Bologna - Italy
tel.: +39 051 20 95786

Bug#995450: buster->bullseye: octave segfaulting during configure (seems unrelated to #992405)

[Diego Zuccato]

Hello.
Just an update.
Continuing a triage, I noticed that removing cdo and its dependencies 
(including libopenblas0) and reinstalling octave got rid of the 
segfault. Reinstalling cdo reintroduced the segfault.


The updated backtrace (I used the wrong executable, sorry) is:
GNU gdb (Debian 10.1-1.7) 10.1.90.20210103-git
Copyright (C) 2021 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
<http://gnu.org/licenses/gpl.html>

This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/bin/octave-cli...
(No debugging symbols found in /usr/bin/octave-cli)
[New LWP 2442519]
[New LWP 2442512]
[New LWP 2442517]
[New LWP 2442514]
[New LWP 2442513]
[New LWP 2442516]
[New LWP 2442518]
[New LWP 2442515]
[New LWP 2442498]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `/usr/bin/octave-cli --silent --no-history 
--no-init-file --no-window-system --e'.

Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x in ?? ()
[Current thread is 1 (Thread 0x7f62c1316700 (LWP 2442519))]
(gdb) bt
#0  0x in ?? ()
#1  0x7f62f78b7709 in blas_memory_alloc () from 
/usr/lib/x86_64-linux-gnu/libopenblas.so.0
#2  0x7f62f78b7f04 in ?? () from 
/usr/lib/x86_64-linux-gnu/libopenblas.so.0
#3  0x7f62faae5ea7 in start_thread (arg=) at 
pthread_create.c:477
#4  0x7f62fbfbbdef in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:95

(gdb)

--
Diego Zuccato
DIFA - Dip. di Fisica e Astronomia
Servizi Informatici
Alma Mater Studiorum - Università di Bologna
V.le Berti-Pichat 6/2 - 40127 Bologna - Italy
tel.: +39 051 20 95786

Bug#994266: pyjwt breaks azure-cli autopkgtest: Could not deserialize key data. The data may be in an incorrect format or it may be encrypted with an unsupported algorithm.

[Diego M. Rodriguez]

On Tue, 14 Sep 2021 22:30:24 +0200 Paul Gevers  wrote:
> Currently this regression is blocking the migration of pyjwt to testing
> [1]. Due to the nature of this issue, I filed this bug report against
> both packages. Can you please investigate the situation and reassign the
> bug to the right package?

As part of the "investigate" part - this might be related to a hotfix
introduced in azure-cli 2.26.1 [1], which includes a change on how the
"jwt.decode()" call related to the "verify" parameter [2]. pyjwt seems
to have deprecated it in its 2.0 release [3] (and a number of similar in
its upstream repo also point to that parameter).

[1]
https://github.com/MicrosoftDocs/azure-docs-cli/blob/master/docs-ref-conceptual/release-notes-azure-cli.md#storage-2
[2] https://github.com/Azure/azure-cli/pull/18811
[3]
https://github.com/jpadilla/pyjwt/blob/master/CHANGELOG.rst#dropped-deprecated-verify_expiration-param-in-jwtdecode
-- 
Diego M. Rodriguez

Bug#995581: ITP: python-oauthenticator -- OAuth authenticator for JupyterHub

[Diego M. Rodriguez]

Package: wnpp
X-Debbugs-Cc: lola...@debian.org

Owner: "Diego M. Rodriguez" 
Severity: wishlist

* Package name: python-oauthenticator
  Version : 14.2.0
  Upstream Author : Jupyter Development Team 
* URL : https://github.com/jupyterhub/oauthenticator
* License : BSD-3-clause
  Programming Lang: Python
  Description : OAuth authenticator for JupyterHub

Provides plugins for JupyterHub to use common OAuth providers, as well
as base classes for writing custom authenticators with any OAuth 2.0
provider.

This package is an optional dependency of ITP "jupyterhub" [1]. My
intent is to package this software under the umbrella of the Debian
Python Team.

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=988775
-- 
Diego M. Rodriguez

Bug#995454: python3-numpy: segfault and core dump with a simple "import numpy"

[Diego Zuccato]

Package: python3-numpy
Version: 1:1.19.5-1
Severity: important

Dear Maintainer,

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

   * What led up to the situation?
Upgraded servers from Buster to Bullseye

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
Upgraded the whole system. After that, an user reported his script didn't work 
anymore.
Tried
apt purge python3-numpy libboost-numpy*
apt autoremove
apt install python3-numpy libboost-numpy*

   * What was the outcome of this action?
str957-cluster:~$ python3
Python 3.9.2 (default, Feb 28 2021, 17:03:44) 
[GCC 10.2.1 20210110] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import numpy
Errore di segmentazione (core dump creato)

   * What outcome did you expect instead?
That numpy package got imported


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

Kernel: Linux 5.10.0-8-amd64 (SMP w/12 CPU threads)
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.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 python3-numpy depends on:
ii  libatlas3-base [liblapack.so.3]3.10.3-10
ii  libblas3 [libblas.so.3]3.9.0-3
ii  libc6  2.31-13
ii  liblapack3 [liblapack.so.3]3.9.0-3
ii  libopenblas0-pthread [liblapack.so.3]  0.3.13+ds-3
ii  python33.9.2-3
ii  python3-pkg-resources  52.0.0-4
ii  python3.9  3.9.2-1

python3-numpy recommends no packages.

Versions of packages python3-numpy suggests:
ii  gcc4:10.2.1-1
ii  gfortran   4:10.2.1-1
pn  python-numpy-doc   
ii  python3-dev3.9.2-3
pn  python3-numpy-dbg  
pn  python3-pytest 

-- no debconf information

Bug#995450: buster->bullseye: octave segfaulting during configure (seems unrelated to #992405)

[Diego Zuccato]

Package: octave
Version: 6.2.0-1
Severity: normal

Dear Maintainer,

   * What led up to the situation?
Upgrade from Buster to Bullseye

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
Tried removing/purging and reinstalling octave and many dependencies.
When I reinstall it, it's left unconfigured. Trying to run it gives an 
immediate segfault.
root@str957-cluster:~# ls -l /usr/lib/x86_64-linux-gnu/libopenblas.so.0
lrwxrwxrwx 1 root root 51 30 set 11.51 
/usr/lib/x86_64-linux-gnu/libopenblas.so.0 -> 
/etc/alternatives/libopenblas.so.0-x86_64-linux-gnu
root@str957-cluster:~# gdb /usr/bin/octave /core
GNU gdb (Debian 10.1-1.7) 10.1.90.20210103-git
Copyright (C) 2021 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/bin/octave...
(No debugging symbols found in /usr/bin/octave)

warning: core file may not match specified executable file.
[New LWP 627072]
[New LWP 627067]
[New LWP 627065]
[New LWP 627066]
[New LWP 627068]
[New LWP 627069]
[New LWP 627070]
[New LWP 627071]
[New LWP 627064]
Core was generated by `/usr/bin/octave-cli --silent --no-history --no-init-file 
--no-window-system --e'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x in ?? ()
[Current thread is 1 (LWP 627072)]
(gdb) bt
#0  0x in ?? ()
#1  0x7fc06b416709 in ?? ()
#2  0x7fc06b416230 in ?? ()
#3  0x7fc06b4161d0 in ?? ()
#4  0x in ?? ()
(gdb)

   * What was the outcome of this action?
Segfault&core dump

   * What outcome did you expect instead?
regular octave prompt and no error during install.


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

Kernel: Linux 5.10.0-8-amd64 (SMP w/12 CPU threads)
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.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 octave depends on:
ii  libbz2-1.0  1.0.8-4
ii  libc6   2.31-13
ii  libfftw3-double33.3.8-2
ii  libfftw3-single33.3.8-2
ii  libfltk-gl1.3   1.3.5-3
ii  libfltk1.3  1.3.5-3
ii  libgcc-s1   10.2.1-6
ii  libgl1  1.3.2-1
ii  libglpk40   5.0-1
ii  liboctave8  6.2.0-1
ii  libportaudio2   19.6.0-1.1
ii  libqhull8.0 2020.2-3
ii  libqscintilla2-qt5-15   2.11.6+dfsg-2
ii  libqt5core5a5.15.2+dfsg-9
ii  libqt5gui5  5.15.2+dfsg-9
ii  libqt5help5 5.15.2-5
ii  libqt5network5  5.15.2+dfsg-9
ii  libqt5printsupport5 5.15.2+dfsg-9
ii  libqt5widgets5  5.15.2+dfsg-9
ii  libqt5xml5  5.15.2+dfsg-9
ii  libsndfile1 1.0.31-2
ii  libstdc++6  10.2.1-6
ii  libsundials-ida44.1.0+dfsg-4
ii  libsundials-sunlinsol2  4.1.0+dfsg-4
ii  libx11-62:1.7.2-1
ii  octave-common   6.2.0-1
ii  texinfo 6.7.0.dfsg.2-6
ii  zlib1g  1:1.2.11.dfsg-2

Versions of packages octave recommends:
ii  default-jre-headless  2:1.11-72
ii  epstool   3.09-3
ii  gnuplot-qt [gnuplot-x11]  5.4.1+dfsg1-1
ii  libatlas3-base3.10.3-10
ii  libopenblas0  0.3.13+ds-3
ii  octave-doc6.2.0-1
ii  pstoedit  3.75-1

Versions of packages octave suggests:
pn  liboctave-dev  

Bug#994975: xsmid: Please make another source-only upload to allow testing migration

[Diego M. Rodriguez]

Package: xsmid
Version: 7.5.0-1
Severity: wishlist

Dear Maintainer,

thanks for packaging xsmid for Debian - it was a pleasant surprise to
see it already on track while working on packaging pythran [1], which
has it as a dependency.

Would it be possible to make a source-only upload, in order to allow it
to progress to testing eventually?

Thanks in advance,

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=991143
-- 
Diego M. Rodriguez

Bug#993499: RFS: python-marshmallow-polyfield/5.10-1 -- marshmallow extension for polymorphic fields

[Diego M. Rodriguez]

On Sat, 18 Sep 2021 05:06:59 +0200 Jeroen Ploemen  wrote:
> It does. Copyrights have expiry dates too, so the most recent year matters.

Thanks - I updated the copyright line in order to include the most
recent year as well, along with the comment.

-- 
Diego M. Rodriguez

Bug#993460: RFS: python-jellyfish/0.8.8-1 -- Library for approximate and phonetic matching of strings

[Diego M. Rodriguez]

Control: tag -1 - moreinfo

Hello Jeroen,

> copyright:
>  * various copyright holders listed in d/copyright don't have their names
>appear anywhere in the sources. Please refresh and/or add comment
>fields detailing what the affected entries are based on.

The extra copyright holders were added during the initial ITP review
[1], and it seems they corresponded to the upstream git contributors to
each individual file by the time of the 0.5-3 release. I have refreshed
d/copyright to ensure it matches the authors explicitly mentioned in
upstream current LICENSE file and other headers.

> Please remove the moreinfo tag (and CC me directly) once you have an
> updated package ready.

Pinging back after tackling the rest of the issues too - thanks (once
again)!

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=807432#27

-- 
Diego M. Rodriguez

Bug#993499: RFS: python-marshmallow-polyfield/5.10-1 -- marshmallow extension for polymorphic fields

[Diego M. Rodriguez]

On Fri, 17 Sep 2021 11:30:24 +0200 Jeroen Ploemen  wrote:
> In that case, for lack of a better option, the upstream git commits could
> serve as a basis for the years.

Noted - in this instance, 2015 is also the date of the initial git
commit in the upstream repo. Could you let me know if your mention of
"years" implies also declaring the year of the last commit for this
release in d/copyright (ie. 2015-2021)?

Thanks,
-- 
Diego M. Rodriguez

Bug#993499: RFS: python-marshmallow-polyfield/5.10-1 -- marshmallow extension for polymorphic fields

[Diego M. Rodriguez]

Control: tags -1 - moreinfo

Hello Jeroen,

and thanks for the review!

> copyright: where does the 2015 upstream copyright year come from?

I think it was added during the initial packaging based on the year of
the first upstream public release, but indeed there is no explicit
mention of 2015 in the upstream sources. I have added a comment to
d/copyright, but I'm not sure if this is the best approach - any
guidance would be welcome.

> control:
>   * why hardcode the dependency on python3-marshmallow for the binary pkg?

Unintentional - and fixed.

>   * the build-dep on the same also seems unneeded (at least unless/until
> tests are re-enabled, see watch)
> 
> watch: consider using github for upstream releases, as the files
> published there include the upstream testsuite missing on pypi. And then
> put those tests to good use, of course :)

Switched to using github releases, re-enabling the tests during build
and also adding autopkgtests.


Thanks,
-- 
Diego M. Rodriguez

Bug#993933: RFS: python-gast/0.5.2-1 [ITP] -- compatibility layer for the AST of various Python versions

[Diego M. Rodriguez]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "python-gast":

 * Package name: python-gast
   Version : 0.5.2-1
   Upstream Author : Serge Guelton 
 * URL : https://github.com/serge-sans-paille/gast
 * License : BSD-3-clause-gast
 * Vcs :
https://salsa.debian.org/python-team/packages/python-gast
   Section : python

It builds those binary packages:

  python3-gast - compatibility layer for the AST of various Python
versions (Python3 version)

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

  https://mentors.debian.net/package/python-gast/

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

  dget -x
https://mentors.debian.net/debian/pool/main/p/python-gast/python-gast_0.5.2-1.dsc

Changes for the initial release:

 python-gast (0.5.2-1) UNRELEASED; urgency=medium
 .
   * Initial release (Closes: #993800)

Regards,
-- 
Diego M. Rodriguez

Bug#993346: pytest-mock: please upgrade to latest upstream release

[Diego M. Rodriguez]

Hello Sandro,

On Mon, 6 Sep 2021 22:20:29 -0400 Sandro Tosi  wrote:
> debian/changelog misses several of your changes, please update and
> i'll then sponsor it

Thanks - just pushed an update to debian/changelog.

-- 
Diego M. Rodriguez

Bug#993800: ITP: python-gast -- compatibility layer for the AST of various Python versions

[Diego M. Rodriguez]

Package: wnpp
X-Debbugs-Cc: debian-pyt...@lists.debian.org

Owner: "Diego M. Rodriguez" 
Severity: wishlist

* Package name: python-gast
  Version : 0.5.2
  Upstream Author : Serge Guelton 
* URL : https://github.com/serge-sans-paille/gast
* License : BSD
  Programming Lang: Python
  Description : compatibility layer for the AST of various Python versions

Provides an homogeneous API over the Abstract Syntax Trees of various
Python versions (including Python 2 and Python 3), which itself is
compatible with the standard library "ast" module API.

This package is a dependency of ITP "pythran" [1] (and also of ITP
"beniget" [2], another dependency itself). My intent is to package this
software under the umbrella of the Debian Python team.

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=991143
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=993797

---
Diego M. Rodriguez

Bug#993797: ITP: python-beniget -- collection of compile-time Python AST analyzers

[Diego M. Rodriguez]

Package: wnpp
X-Debbugs-Cc: debian-pyt...@lists.debian.org, debian-scie...@lists.debian.org

Owner: "Diego M. Rodriguez" 
Severity: wishlist

* Package name: python-beniget
  Version : 0.4.1
  Upstream Author : Serge Guelton 
* URL : https://github.com/serge-sans-paille/beniget
* License : BSD
  Programming Lang: Python
  Description : collection of compile-time Python AST analyzers

Collection of compile-time analyzers of Python Abstract Syntax Trees
that can be used as building blocks to write static analyzers or
compilers:
* Ancestors: map a node to the list of its enclosing nodes
* DefUseChains: map a node to the list of definition points in that node
* UseDefChains: map a node to its list of potential definitions

This package is a dependency of ITP "pythran" [1]. My intent is to
package this software under the umbrella of the Debian Python team.

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=991143
---
Diego M. Rodriguez

Bug#991143: RFP: pythran -- an ahead of time compiler for Python

[Diego M. Rodriguez]

Control: retitle ITP: pythran -- an ahead of time compiler for Python

Hello,

I intend to package this software, preferably under the umbrella of the
Debian Python Team (on the basis of being useful to a general Python
audience)- if the Debian Science Team has a stronger interest or
preference, please let me know, I'm fine with that approach as well.

On Thu, 15 Jul 2021 17:27:05 +0200 Drew Parsons  wrote:
> It may require some dependencies to be packaged:
>   gast
>   beniget

Indeed, it seems to be the case! I'll be filing ITPs for the
dependencies accordingly.

Best,
-- 
Diego M. Rodriguez

Bug#993499: RFS: python-marshmallow-polyfield/5.10-1 -- marshmallow extension for polymorphic fields

[Diego M. Rodriguez]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "python-marshmallow-polyfield":

 * Package name: python-marshmallow-polyfield
   Version : 5.10-1
   Upstream Author : Matt Bachmann 
 * URL : https://github.com/Bachmann1234/marshmallow-polyfield
 * License : Apache-2.0
 * Vcs :
https://salsa.debian.org/python-team/packages/python-marshmallow-polyfield
   Section : python

It builds those binary packages:

  python3-marshmallow-polyfield - marshmallow extension for polymorphic
fields

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

  https://mentors.debian.net/package/python-marshmallow-polyfield/

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

  dget -x
https://mentors.debian.net/debian/pool/main/p/python-marshmallow-polyfield/python-marshmallow-polyfield_5.10-1.dsc

Changes since the last upload:

 python-marshmallow-polyfield (5.10-1) UNRELEASED; urgency=medium
 .
   [ Ondřej Nový ]
   * d/control: Update Maintainer field with new Debian Python Team
 contact address.
   * d/control: Update Vcs-* fields with new Debian Python Team Salsa
 layout.
 .
   [ Diego M. Rodriguez ]
   * New upstream version 5.10
   * d/watch: version 4, use signature
   * d/control: bump Standards-Version to 4.6.0 (no changes needed)
   * d/control: set architecture to all

Regards,
-- 
Diego M. Rodriguez

Bug#993460: RFS: python-jellyfish/0.8.8-1 -- Library for approximate and phonetic matching of strings

[Diego M. Rodriguez]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "python-jellyfish":

 * Package name: python-jellyfish
   Version : 0.8.8-1
   Upstream Author : James Turk 
 * URL : https://github.com/jamesturk/jellyfish
 * License : BSD-2-clause
 * Vcs :
https://salsa.debian.org/python-team/packages/python-jellyfish
   Section : python

It builds those binary packages:

  python-jellyfish-doc - Library for approximate and phonetic matching
of strings (documentation)
  python3-jellyfish - Library for approximate and phonetic matching of
strings (Python 3)

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

  https://mentors.debian.net/package/python-jellyfish/

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

  dget -x
https://mentors.debian.net/debian/pool/main/p/python-jellyfish/python-jellyfish_0.8.8-1.dsc

Changes since the last upload:

 python-jellyfish (0.8.8-1) UNRELEASED; urgency=medium
 .
   [ Ondřej Nový ]
   * d/control: Update Maintainer field with new Debian Python Team
 contact address.
   * d/control: Update Vcs-* fields with new Debian Python Team Salsa
 layout.
 .
   [ Debian Janitor ]
   * Apply multi-arch hints.
 + python-jellyfish-doc: Add Multi-Arch: foreign.
 .
   [ Diego M. Rodriguez ]
   * d/watch: bump version to 4
   * New upstream version 0.8.8
   * d/control: bump Standards-Version to 4.6.0 (no changes needed)

Regards,
-- 
Diego M. Rodriguez

Bug#993346: pytest-mock: please upgrade to latest upstream release

[Diego M. Rodriguez]

Control: tags 993346 pending

Hello Sandro,

On Tue, 31 Aug 2021 00:29:37 -0400 Sandro Tosi  wrote:
> Please upgrade pytest-mock to the latest version; if you're short on time,
> please let me know and i can take care of the upgrade & upload.

I have prepared a 3.6.1-1 release in salsa [1] (it seems the existing
patches are no longer needed thanks to the work with upstream, and most
of the changes were adjustments related to the tests).

Still requires review and upload, though.

[1] https://salsa.debian.org/python-team/packages/pytest-mock
-- 
Diego M. Rodriguez

Bug#990235: RFS: python-pylatexenc/2.10-1 [ITP] -- Simple LaTeX parser providing conversion to/from unicode

[Diego M. Rodriguez]

Control: tags 990235 - moreinfo

Hello Jeroen,

thanks for the review and detailed reply:

On Fri, Aug 27, 2021, at 12:59, Jeroen Ploemen wrote:
> * The lintian hits on the binary pkg deserve an override:

Added two overrides - they are more vague than I would have liked, as it seems 
that the order in which the offending files are displayed in the warnings is 
not deterministic. The other alternative seemed to be adding 3x2 individual 
ones, but resulted in "mismatched-override" warnings.

> * Changelog: just the 'Initial release' line closing the ITP bug will do
>   for a new package.

Fixed the changelog, leaving the "Initial release" line.

> * Control: why the old compat level 12?

Likely it was the one I added when starting packaging a long time ago - bumped 
to 13.

> * Copyright: there's no mention of any copyright later than 2019 held by
>   Philippe Faist, yet grepping the upstream sources shows entries as
>   recent as 2021 for that person.

Thanks for catching these as well. I added explicit lines to d/copyright for 
the files that declare a copyright year different than the one declared in 
LICENSE.txt.

> * Rules: what is the override of dh_auto_clean trying to achieve?

Helping me clean up the package locally in previous iterations :) Removed, as 
indeed it was a leftover.

> * Rules: the help2man target seems to require an installed package in
>   order to succeed. Any way to make this work with just the extracted
>   source package? If not, a comment documenting the requirement would be
>   useful.

I could not find a sensible way to make it work - updated the comment in 
d/rules in the hopes of making it more explicit.

> * Tests: please add non-trivial autopkgtests, based on the upstream
>   testsuite.

Added, thanks again for the example.

> Please remove the moreinfo tag (and CC me directly) once you have an
> updated package ready.

Ditto - hopefully the latest version in salsa is ready for a new review.

Best,
---
Diego M. Rodriguez

Bug#935395: RFP: python3-anytree -- Tree data library

[Diego M. Rodriguez]

Hello Simon,

On Thu, 22 Aug 2019 10:32:26 +0100 Simon McVittie  wrote:
> For now I've replaced its use in gtk-doc-tools with a simple
> reimplementation (it's a tree data structure, it isn't rocket science),
> but in the long term either someone should package anytree, or someone
> needs to ask the upstream maintainer of gtk-doc to use a different tree
> implementation instead of depending on anytree (in which case this bug
> can be closed as wontfix).

I think you managed to solve it via the second approach [1], and thus
the bug can be indeed be closed?

For context, I'm doing a round for trying to work on some RFP packages,
and currently attempting to identify the ones with the higher chance of
helping improve existing packages.

[1] https://gitlab.gnome.org/GNOME/gtk-doc/-/merge_requests/56
-- 
Diego M. Rodriguez

Bug#985024: python3-num2words: SyntaxWarning during package installation

[Diego M. Rodriguez]

On Thu, 11 Mar 2021 22:01:47 +0100 Andreas Beckmann  wrote:
> during a test with piuparts I noticed your package emits a SyntaxWarning
> during installation:
>   [...]

The bug seems to have been fixed upstream [1], and is part of a newer
0.5.10 release [2] (which coincidentally seems that is not currently
picked up by uscan, likely due to the GitHub URL changes a while back).

[1] https://github.com/savoirfairelinux/num2words/pull/240
[2] https://github.com/savoirfairelinux/num2words/releases/tag/v0.5.10
-- 
Diego M. Rodriguez

Bug#990235: RFS: python-pylatexenc/2.10-1 [ITP] -- Simple LaTeX parser providing conversion to/from unicode

[Diego M. Rodriguez]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "python-pylatexenc":

 * Package name: python-pylatexenc
   Version : 2.10-1
   Upstream Author : Philippe Faist 
 * URL : https://github.com/phfaist/pylatexenc
 * License : Expat, Expat and W3C, W3C
 * Vcs :
https://salsa.debian.org/python-team/packages/python-pylatexenc
   Section : python

For context, the issues that I most struggled with were:
1. declaring the d/copyright correctly: hopefully this is addressed
thanks to the help of the helpful folks of the debian-legal list [1],
which involved switching to using GitHub releases as upstream and
incorporating their suggestions.
2. including manpages for the 3 executables (as setup.py
console_scripts)in the package: initially I attempted to generate them
dynamically at build time, but I switched to using a custom target as
recommended in [2]. As a side effect of 1, I was able to include a
documentation package (rendered from sphinx sources) - I'm unsure if
rendering the full documentation as a manpage would be preferred over
having individual help2man-generated entries.

Any help and further review is more than welcome - the package is
maintained at salsa [3].

It builds those binary packages:

  python3-pylatexenc - Simple LaTeX parser providing conversion to/from
unicode
  python-pylatexenc-doc - Simple LaTeX parser providing conversion
to/from unicode (Documentation)

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

  https://mentors.debian.net/package/python-pylatexenc/

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

  dget -x
https://mentors.debian.net/debian/pool/main/p/python-pylatexenc/python-pylatexenc_2.10-1.dsc

Changes for the initial release:

 python-pylatexenc (2.10-1) UNRELEASED; urgency=medium
 .
   [ Diego M. Rodriguez ]
   * Initial release (Closes: #950664)
 .
   [ Ondřej Nový ]
   * d/control: Update Maintainer field with new Debian Python Team
 contact address
   * d/control: Update Vcs-* fields with new Debian Python Team Salsa
 layout

Regards,

[1] https://lists.debian.org/debian-legal/2021/06/msg6.html
[2] https://wiki.debian.org/ManualPage/help2man
[3] https://salsa.debian.org/python-team/packages/python-pylatexenc
-- 
Diego M. Rodriguez

Bug#950664: ITP: pylatexenc -- Simple LaTeX parser providing conversion to/from unicode

[Diego M. Rodriguez]

Hello Sebastian,

and apologies for the long delay in replying.

On Wed, Dec 9, 2020, at 13:52, Sebastian Ramacher wrote:
> I'd be interested in the package. Have you been able to make any
> progress on it?

I did some groundwork at salsa [1] for the 2.1 upstream version. The main items 
that were left unresolved after that initial effort are:
1. seek advice and finalize d/copyright, as there was one particular file [2] 
where I was unsure how to reflect the licensing.
2. verify that the use of help2man is acceptable for generating the manpages 
for the scripts (and act accordingly, ie. dropping the help2man invocation in 
d/rules or create the documentation manually).

I still have the intent of continuing the work - any help is appreciated! Best,

[1] https://salsa.debian.org/python-team/packages/python-pylatexenc
[2] https://github.com/phfaist/pylatexenc/blob/master/tools/unicode.xml
---
Diego M. Rodriguez

Bug#984763: systemd: Please include configurable systemd prefixes in Debian 11's systemd (fixed upstream)

[Diego Escalante Urrelo]

Package: systemd
Version: 246.6-5
Severity: important
Tags: patch
X-Debbugs-Cc: die...@gnome.org

Dear Maintainer,

In systemd-247.*, the `systemd.pc` file was modified to hard-code
`/usr/lib` as the prefix of a bunch of systemd paths. This broke build
tools like `jhbuild`, that configure and install into a custom prefix
for development and testing purposes.

The above issue was fixed usptream in:
https://github.com/systemd/systemd/commit/60bce7c6d9606185114df1bdcd5ea100407688b8#diff-3dce99316f44198c53d8147020aaca9c8931b5248587c64c098fdcef8ed4da03

However the above has not been backported by upstream to v247-stable:
https://github.com/systemd/systemd-stable/blob/v247-stable/src/core/systemd.pc.in

I'm filling against Debian, and not upstream, since I don't know if
Debian plans to keep updating to the following 247.n versions, or if
247.3 will be frozen for all of Debian 11. If it's the second case, then
it would be really helpful to cherry-pick the above fix so that the
`systemd.pc` file is fully functional.

Thanks!

-- Package-specific info:

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

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

Versions of packages systemd depends on:
ii  adduser  3.118
ii  libacl1  2.2.53-9
ii  libapparmor1 2.13.6-3
ii  libaudit11:3.0-1
ii  libblkid12.36.1-7
ii  libc62.31-6
ii  libcap2  1:2.44-1
ii  libcrypt11:4.4.17-1
ii  libcryptsetup12  2:2.3.4-1
ii  libgcrypt20  1.8.7-2
ii  libgnutls30  3.7.0-5
ii  libgpg-error01.38-2
ii  libidn2-02.3.0-4
ii  libip4tc21.8.7-1
ii  libkmod2 28-1
ii  liblz4-1 1.9.3-1
ii  liblzma5 5.2.5-1.0
ii  libmount12.36.1-7
ii  libpam0g 1.4.0-2
ii  libpcre2-8-0 10.36-2
ii  libseccomp2  2.5.1-1
ii  libselinux1  3.1-2+b2
ii  libsystemd0  246.6-5
ii  libzstd1 1.4.8+dfsg-1
ii  mount2.36.1-4
ii  systemd-timesyncd [time-daemon]  246.6-5
ii  util-linux   2.36.1-4

Versions of packages systemd recommends:
ii  dbus  1.12.20-1

Versions of packages systemd suggests:
ii  policykit-10.118-1
pn  systemd-container  

Versions of packages systemd is related to:
ii  dracut   051-1
pn  initramfs-tools  
ii  libnss-systemd   246.6-5
ii  libpam-systemd   246.6-5
hi  udev 246.6-5

-- Configuration Files:
/etc/systemd/journald.conf changed [not included]
/etc/systemd/logind.conf changed [not included]

-- no debconf information

Bug#980076: command-not-found: Patch to speed up cnf-update-db

[Diego Ongaro]

Package: command-not-found
Version: 20.10.1-1
Severity: normal
Tags: patch

Dear Maintainer,

cnf-update-db is fairly slow on my machine. After I remove
/var/lib/command-not-found/commands.db.metadata, cnf-update-db takes about 16
seconds on my machine.

A large chunk of this time is checking whether files are in /usr/bin and
similar directories. I'm attaching a small patch that optimizes this check,
taking the same update down to about 10 seconds on my machine. It's a 4-line
change that seems like an easy win.

I confirmed that I have the same number of commands and packages in the
commands.db database with and without this change.

Please let me know if you prefer to receive this patch in a different format or
channel.

Regards,
Diego

-- System Information:
Debian Release: 10.7
  APT prefers stable-updates
  APT policy: (560, 'stable-updates'), (550, 'stable'), (160, 'testing'), (150, 
'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages command-not-found depends on:
ii  apt-file 3.2.2
ii  lsb-release  10.2019051400
ii  python3  3.7.3-1
ii  python3-apt  1.8.4.3

command-not-found recommends no packages.

Versions of packages command-not-found suggests:
pn  snapd  
From: Diego Ongaro 
Date: Wed, 13 Jan 2021 17:44:50 -0800
Subject: cnf-update-db: Speed up Contents files

---
 CommandNotFound/db/creator.py | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/CommandNotFound/db/creator.py b/CommandNotFound/db/creator.py
index 08564f5..fce5e67 100755
--- a/CommandNotFound/db/creator.py
+++ b/CommandNotFound/db/creator.py
@@ -4,6 +4,7 @@ import errno
 import json
 import logging
 import os
+import re
 import sqlite3
 import subprocess
 import sys
@@ -234,12 +235,12 @@ class DbCreator:
 def _parse_single_contents_file(self, con, f, fp):
 # read header
 suite=None  # FIXME
+pattern = re.compile(b'usr/sbin|usr/bin|sbin|bin')
 
 for l in fp:
-l = l.decode("utf-8")
-if not (l.startswith('usr/sbin') or l.startswith('usr/bin') or
-l.startswith('bin') or l.startswith('sbin')):
+if not pattern.match(l):
 continue
+l = l.decode("utf-8")
 try:
 command, pkgnames = l.split(None, 1)
 except ValueError:

Bug#973462: ITP: podcasts -- Podcast application for GNOME written in Rust

[Diego Escalante Urrelo]

Package: wnpp
Followup-For: Bug #973462
X-Debbugs-Cc: die...@gnome.org

FTR, figured some stuff out and opened a WIP merge that includes most of
the GNOME stack:
 https://salsa.debian.org/rust-team/debcargo-conf/-/merge_requests/134

I'm still a few GNOME-stack packages away from meeting the needs for
podcasts though.

Bug#973462: ITP: podcasts -- Podcast application for GNOME written in Rust

[Diego Escalante Urrelo]

Package: wnpp
Followup-For: Bug #973462
X-Debbugs-Cc: die...@gnome.org

I'm working on the GNOME stack side of things, with a bunch of updated
crates already:
 https://salsa.debian.org/marvil07/debcargo-conf/-/commits/diegoe_gnome-stack

At the very least, these should be updated and fine:
glib-macros: package 0.10.1
proc-macro-crate: package 0.1.5
pangocairo-sys: update to 0.11.0
gtk-sys: update to 0.10.0
gdk-sys: update to 0.10.0
cairo-sys-rs: update to 0.10.0
gdk-pixbuf-sys: update to 0.10.0
gio-sys: update to 0.10.1
winapi: update to 0.3.9
atk-sys: update to 0.10.0
pango-sys: update to 0.10.0
gobject-sys: update to 0.10.0
glib-sys: update to 0.10.1

Of course, it's all pointless unless the full chain of deps is updated,
but here's where I ran into problems:

I'm currently stuck trying to update futures-*, because futures-task
does not build its corresponding +feature packages when `debcargo` is
run with `--config` (which is the case when using the `debcargo-conf`
scripts), this stops me from updating other futures-* crates.

It seems that debcargo behaves differently when a config override is
passed, as the Provides: list and a few other things change:

With --config (...)/debcargo.toml:
```
Package: librust-futures-task-dev
Architecture: any
Multi-Arch: same
Depends:
 ${misc:Depends},
 librust-once-cell-1+default-dev (>= 1.3.1-~~)
Provides:
 librust-futures-task+default-dev (= ${binary:Version}),
 librust-futures-task+std-dev (= ${binary:Version}),
 librust-futures-task-0-dev (= ${binary:Version}),
 librust-futures-task-0+default-dev (= ${binary:Version}),
 librust-futures-task-0+std-dev (= ${binary:Version}),
 librust-futures-task-0.3-dev (= ${binary:Version}),
 librust-futures-task-0.3+default-dev (= ${binary:Version}),
 librust-futures-task-0.3+std-dev (= ${binary:Version}),
 librust-futures-task-0.3.7-dev (= ${binary:Version}),
 librust-futures-task-0.3.7+default-dev (= ${binary:Version}),
 librust-futures-task-0.3.7+std-dev (= ${binary:Version})
```

Without --config:
```
Package: librust-futures-task-dev
Architecture: any
Multi-Arch: same
Depends:
 ${misc:Depends}
Recommends:
 librust-futures-task+std-dev (= ${binary:Version})
Suggests:
 librust-futures-task+once-cell-dev (= ${binary:Version})
Provides:
 librust-futures-task+alloc-dev (= ${binary:Version}),
 librust-futures-task+cfg-target-has-atomic-dev (= ${binary:Version}),
 librust-futures-task+unstable-dev (= ${binary:Version}),
 librust-futures-task-0-dev (= ${binary:Version}),
 librust-futures-task-0+alloc-dev (= ${binary:Version}),
 librust-futures-task-0+cfg-target-has-atomic-dev (= ${binary:Version}),
 librust-futures-task-0+unstable-dev (= ${binary:Version}),
 librust-futures-task-0.3-dev (= ${binary:Version}),
 librust-futures-task-0.3+alloc-dev (= ${binary:Version}),
 librust-futures-task-0.3+cfg-target-has-atomic-dev (= ${binary:Version}),
 librust-futures-task-0.3+unstable-dev (= ${binary:Version}),
 librust-futures-task-0.3.7-dev (= ${binary:Version}),
 librust-futures-task-0.3.7+alloc-dev (= ${binary:Version}),
 librust-futures-task-0.3.7+cfg-target-has-atomic-dev (= ${binary:Version}),
 librust-futures-task-0.3.7+unstable-dev (= ${binary:Version})
```

I'm still learning about rust, so I'm clueless about what's going on
here, or if it's even a bug in debcargo (since this only happens when
passed a --config option).

Bug#971335: broadcom-sta: [patch] Driver improvements, cleanups, fixes

[Diego Escalante Urrelo]

Hey Roger,

Apologies for the radio silence. I just saw that this email ended up
in the spam folder :(.

Thanks for your comments and eagerness to welcome and test this, I'm
really glad that more people will find this useful :) :)

Some comments:

On Thu, Oct 1, 2020 at 11:08 AM Roger Shimizu  wrote:
> > My "frankenwl" branch is functionally the same as the above
> > "diegoe_debian" branch, but it certainly makes it less convoluted to try
> > and find problems in the code going forward. That said, I wasn't sure
> > what would be the best way to proceed, or if it was a smart thing to do
> > anyway. I guess this package is on "life support" on most distros, so I
> > doubt there would be a objections on creating a shared new upstream (but
> > I'm not familiar with the packaging of this driver in Debian, or other
> > distros).
>
> Since the upstream seems not active for quite a few years, so I think
> it's totally fine if you want to fork.
> And if you do so, I'm happy to update debian package to follow your
> forked git repo.
>

Do you think it would be worth it to reach out to maintainers at a few
main distros and see if there's any interest to collaborate on this?
When I was trying to figure out the issues with my card (see below) I
noticed that most distros either copy+paste patches, or brew their own
slightly different versions.

> > I'm also aware that cards supported by this driver are "old" but most
> > computers trapped in the broadcom-sta driver are perfectly functional
> > today and will be for a few more years. In my particular case I'm
> > running a macbookpro11,1 (2013) which works flawlessly except for the
> > wifi! (Hah!) -- And I understand most other macbookpro models from
> > around 2013 share this or similar Broadcom cards that use this driver.
> > All those machines should be perfectly functional with Debian right now,
> > and for a few more years.
>
> Yes, I also have two mac devices that use this driver.
> Thanks for your effort to make the driver better.

I wonder if you have run into the connection timeouts/unstable wifi
issues that many other users run into? I have been trying to debug why
and when this issue happens, but perhaps you might have any clue or
anecdote that might help figure this out.

The issue seems to appear when using certain (seemingly old) APs that
do not implement anything newer than 802.11n -- meaning that anything
with 802.11ac is usually free of the issue. The problem manifests as
sudden very high latency, and sometimes lost ARP/identity towards the
AP. I have been unable to debug the issue, but I have reasonably
eliminated WMM, power saving (both PCI/card and 802.11 protocol),
b/g/n, and a few other suspects.

>From my own testing it would seem that the firmware blob in the card
(or the blob uploaded by the driver) simply stops reporting new
packets, either queuing them, or simply dropping them silently, which
on user space manifests as progressively higher latency and eventual
lost of connectivity until resync/reconnection happens, or the
firmware behaves again. I don't have the proper network hardware to
test the router side, so I can't 100% confirm what's going on.

AFAIK, these cards have a hybrid firmware model where there's a ROM
firmware in the card, but by design you have/can upload a RAM firmware
that allows the OEM/IHV to upload new features or fix bugs. Fairly
standard, I understand. But my current hypothesis is that the
particular card I have is an slightly custom module by Apple that has
certain buggy behaviors that get corrected with the RAM firmware made
by Apple. To give some support to this hypothesis, my current card +
AP combo exhibited the same buggy behavior under OSX. However, this
buggy behavior got fixed on OSX a few months after the last ever
release of broadcom-sta for Linux. My hypothesis is that whatever bug
that this ROM firmware has with slow or old APs (whether a Broadcom or
Apple integration bug), got fixed by Apple or Broadcom in an updated
RAM firmware, but said fix missed the window of the last ever
broadcom-sta.

Anyway, my current understanding is that we can't fix the described
problem with the "open" part of the driver. It is the firmware part
that is the problem, so unless someone learns or knows how to extract
the firmware from the binary blob in OSX/Windows, and then use that in
Linux, or something like that, then the use case of "old weird AP +
this card" is broken under Linux (under some undetermined
circumstances).

Rant over. Thought I would share the above info anyway, in case you
might have any clue or anecdote that could help figure this out.

Bug#971728: malcontent-gui: Missing .policy file prevents service from working

[Diego Escalante Urrelo]

Package: malcontent-gui
Version: 0.9.0-1
Severity: grave
Tags: patch
Justification: renders package unusable
X-Debbugs-Cc: die...@gnome.org

Hi, it seems that there's a missing .policy file in the .install file
for `malcontent-gui`, specifically:
  `usr/share/polkit-1/actions/org.freedesktop.MalcontentControl.policy`

I opened a MR a few weeks ago for that:
  https://salsa.debian.org/freedesktop-team/malcontent/-/merge_requests/2

Since gnome-control-center now depends on malcontent, the broken
functionality (no ability to _use_ malcontent-gui) is now exposed to all
users.

You'll notice this issue when you open `malcontent-control`, which will
warn you that there's no data for users, and you should fix your
accountsservice. The message is somewhat confusing, because the reason
for the failure is that the .policy file is missing.

Thanks!

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

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

Versions of packages malcontent-gui depends on:
ii  libaccountsservice00.6.55-3
ii  libc6  2.31-3
ii  libcairo2  1.16.0-4
ii  libgdk-pixbuf2.0-0 2.40.0+dfsg-5
ii  libglib2.0-0   2.66.0-2
ii  libgtk-3-0 3.24.23-1
ii  libmalcontent-ui-0-0   0.9.0-1
ii  libpolkit-gobject-1-0  0.117-1
ii  malcontent 0.9.0-1

malcontent-gui recommends no packages.

malcontent-gui suggests no packages.

-- no debconf information

Bug#971335: broadcom-sta: [patch] Driver improvements, cleanups, fixes

[Diego Escalante Urrelo]

Source: broadcom-sta
Version: cfg80211 functionality updates, cleanups, fixes
Severity: normal
Tags: patch
X-Debbugs-Cc: die...@gnome.org

Hi,

I've been working on a few improvements to this driver, trying
(hopelessly) to fix the disconnect issues on my particular card + router
combination. Although my original goal has failed miserably, I was able
to figure out a couple of other fixes for common issues with this card.

I have pushed a branch to salsa, which includes the following fixes:
 * Make power management commands actually work (the driver ignores
 turning PM off)
 * Correctly read the value of TX power (the notorious "200dBm" bug)
 * Correctly refuse MAC address changing (fixes network-manager
 disconnects because of "random / custom mac address"
 * Cleanup a few compiler warnings, and cfg80211 API usage

The branch is here:
 https://salsa.debian.org/diegoe-guest/broadcom-sta/-/commits/diegoe_debian

While working on the above I also figured that I might as well try to
create a proof of concept "new upstream" without all the cruft from the
10 years of kernel versions conditionals:
 https://salsa.debian.org/diegoe-guest/broadcom-sta/-/commits/frankenwl

My "frankenwl" branch is functionally the same as the above
"diegoe_debian" branch, but it certainly makes it less convoluted to try
and find problems in the code going forward. That said, I wasn't sure
what would be the best way to proceed, or if it was a smart thing to do
anyway. I guess this package is on "life support" on most distros, so I
doubt there would be a objections on creating a shared new upstream (but
I'm not familiar with the packaging of this driver in Debian, or other
distros).

I also tried, naively, to contact cypress/broadcom to inquiry about a
newer firmware blob dump, or just a new code dump. Of course, no
response. I think it's worth highlighting that the kernel bcmf80211
driver is very similar to the broadcom-sta code, which lead me to
believe that it can work with the cards supported only by broadcom-sta,
we just need the firmware blob and plug the loose ends. Anyway, this is
probably never going to happen, unless someone figures out how to
extract the (say, in my case) BCM4360 software-side firmware blob from
the linux or mac or windows driver.

Anyway, I wanted to share this work here so it's considered for
inclusion for the upcoming Debian stable. At the very least this solves
a few nitpicks (power settings, tx set/get) that degrade the user
experience and a serious issue (mac address failures) that usually gets
new users stuck and confused (random NM disconnections).

I'm also aware that cards supported by this driver are "old" but most
computers trapped in the broadcom-sta driver are perfectly functional
today and will be for a few more years. In my particular case I'm
running a macbookpro11,1 (2013) which works flawlessly except for the
wifi! (Hah!) -- And I understand most other macbookpro models from
around 2013 share this or similar Broadcom cards that use this driver.
All those machines should be perfectly functional with Debian right now,
and for a few more years.

Hope to hear your feedback, I'm glad to cleanup this branch as you see
fit to get it merged into the package.

Diego

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

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

Bug#968670: dwz: Fails with "Unknown DWARF DW_OP_1"

[Diego López León]

Package: dwz
Version: 0.13-5
Severity: normal
X-Debbugs-Cc: qdcois...@relay.firefox.com

Hi,

I'm building a package for the liboqs library, a post quantum algorithms 
library,
for being proposed to be included in the archives, and when I run the build it 
fails with
"Unknown DWARF DW_OP_1".

This package can be built using Docker and I let a commit with the broken state 
at
https://github.com/lacchain/liboqs-debian/commit/482cb19fcca9449b286bb597b9b0e14ba0b7

I can provide the liboqs shared library on request if you can't reproduce it.

Best regards,
  Diego

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

Kernel: Linux 4.19.76-linuxkit (SMP w/4 CPU threads)
Kernel taint flags: TAINT_RANDSTRUCT
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Versions of packages dwz depends on:
ii  libc62.31-1
ii  libelf1  0.176-1.1

dwz recommends no packages.

dwz suggests no packages.

-- no debconf information

Bug#967923: dracut-network has the exact same description as dracut-core

[Diego Escalante Urrelo]

Package: dracut-network
Severity: minor
X-Debbugs-Cc: die...@gnome.org

It seems like dracut-network has the same description as dracut-core,
without the additional: "\n.\nThis package ..."

It would be helpful adding the snippet that gives some more details on
what's the difference with -core.

Thanks

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

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

Bug#967922: initramfs-tools-core: /run/cryptsetup should be configure with /usr/lib/tmpfiles.d/cryptsetup.conf

[Diego Escalante Urrelo]

Package: initramfs-tools-core
Version: 0.137
Severity: normal
X-Debbugs-Cc: die...@gnome.org

cryptsetup expects the `/run/cryptsetup` directory to exist, and
according to upstream the preferred way to get it to exist is with a
tmpfiles.d file:
  https://gitlab.com/cryptsetup/cryptsetup/-/merge_requests/99#note_390506222

`initramfs-core-tools` however just creates it manually:
```
/usr/share/initramfs-tools /scripts/local-top/cryptroot:
# Create locking directory before invoking cryptsetup(8) to avoid warnings
mkdir -pm0700 /run/cryptsetup
```

`dracut` does something similar in its scripts, but apparently in my
system systemd takes over and said script is never run, or ran too late?

```
/usr/lib/dracut/modules.d/90crypt/cryptroot-ask.sh:
mkdir -p -m 0700 /run/cryptsetup
```

So, I believe perhaps the above directory might follow upstream
recommendation and be created in a tmpfiles.d configuration file.

Note that /usr/lib/tmpfiles.d/cryptsetup.conf is installed by
`cryptsetup-bin`.

A similar bug was opened for `dracut`:
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=967921

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

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

Versions of packages initramfs-tools-core depends on:
ii  coreutils8.32-2
ii  cpio 2.13+dfsg-2
ii  e2fsprogs1.45.6-1
ii  klibc-utils  2.0.7-1
ii  kmod 27+20200310-2
ii  logsave  1.45.6-1
ii  udev 246-2

Versions of packages initramfs-tools-core recommends:
ii  busybox  1:1.30.1-4
ii  pigz 2.4-1+b1

Versions of packages initramfs-tools-core suggests:
ii  bash-completion  1:2.10-1

-- Configuration Files:
/etc/initramfs-tools/initramfs.conf changed [not included]

-- no debconf information

Bug#967921: dracut-core: Missing tmpfiles.d/cryptsetup.conf triggers cryptsetup "WARNING: Locking directory /run/cryptsetup is missing!" warning

[Diego Escalante Urrelo]

Package: dracut-core
Version: 050+65-1
Severity: important
X-Debbugs-Cc: die...@gnome.org

It seems like dracut is forgetting to include
/usr/lib/tmpfiles.d/cryptsetup.conf in the initrd image, which in turn
means that cryptsetup has to create its locking directory on the fly:

```
systemd[1]: Starting Cryptography Setup for sda5_crypt...
systemd[403]: systemd-cryptsetup@sda5_crypt.service: Executing: 
/lib/systemd/systemd-cryptsetup attach sda5_crypt /dev/dis
systemd-cryptsetup[403]: Allocating context for crypt device 
/dev/disk/by-uuid/abce6225-09ba-4b57-93b8-dda42635eafd.
systemd-cryptsetup[403]: Trying to open and read device 
/dev/disk/by-uuid/abce6225-09ba-4b57-93b8-dda42635eafd with direct
systemd-cryptsetup[403]: Initialising device-mapper backend library.
systemd-cryptsetup[403]: dm version   [ opencount flush ]   [16384] (*1)
systemd-cryptsetup[403]: dm versions   [ opencount flush ]   [16384] (*1)
systemd-cryptsetup[403]: Detected dm-ioctl version 4.42.0.
systemd-cryptsetup[403]: Device-mapper backend running with UDEV support 
enabled.
systemd-cryptsetup[403]: dm status sda5_crypt  [ opencount noflush ]   [16384] 
(*1)
systemd-cryptsetup[403]: Trying to load any crypt type from device 
/dev/disk/by-uuid/abce6225-09ba-4b57-93b8-dda42635eafd.
systemd-cryptsetup[403]: Crypto backend (OpenSSL 1.1.1g  21 Apr 2020) 
initialized in cryptsetup library version 2.3.3.
systemd-cryptsetup[403]: Detected kernel Linux 5.7.0-2-amd64 x86_64.
systemd-cryptsetup[403]: Loading LUKS2 header (repair disabled).
systemd-cryptsetup[403]: Acquiring read lock for device 
/dev/disk/by-uuid/abce6225-09ba-4b57-93b8-dda42635eafd.
systemd-cryptsetup[403]: WARNING: Locking directory /run/cryptsetup is missing!
systemd-cryptsetup[403]: Opening lock resource file /run/cryptsetup/L_8:5
systemd-cryptsetup[403]: Verifying lock handle for 
/dev/disk/by-uuid/abce6225-09ba-4b57-93b8-dda42635eafd.
systemd-cryptsetup[403]: Device 
/dev/disk/by-uuid/abce6225-09ba-4b57-93b8-dda42635eafd READ lock taken.
systemd-cryptsetup[403]: Trying to read primary LUKS2 header at offset 0x0.
systemd-cryptsetup[403]: Opening locked device 
/dev/disk/by-uuid/abce6225-09ba-4b57-93b8-dda42635eafd
systemd-cryptsetup[403]: Veryfing locked device handle (bdev)
systemd-cryptsetup[403]: LUKS2 header version 2 of size 16384 bytes, checksum 
sha256.
```

According to upstream, this should in fact be fatal, but as a
work-around they create the directory with default permissions anyway:
  https://gitlab.com/cryptsetup/cryptsetup/-/merge_requests/99#note_390506222

This does not happen with `initramfs-tools`, but apparently because they
just bite the bullet and manually create it (perhaps that should be a
bug too):

```
/usr/share/initramfs-tools /scripts/local-top/cryptroot:
# Create locking directory before invoking cryptsetup(8) to avoid warnings
mkdir -pm0700 /run/cryptsetup
```

`dracut` does something similar in its scripts, but apparently in my
system systemd takes over and said script is never run, or ran too late?

```
/usr/lib/dracut/modules.d/90crypt/cryptroot-ask.sh:
mkdir -p -m 0700 /run/cryptsetup
```

So, I believe perhaps the above directory might follow upstream
recommendation and be created in a tmpfiles.d configuration file.

Note that /usr/lib/tmpfiles.d/cryptsetup.conf is installed by
`cryptsetup-bin`.

I'll report a similar bug in initramfs-tools.

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

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

Versions of packages dracut-core depends on:
ii  bash5.0-6
ii  cpio2.13+dfsg-2
ii  e2fsprogs   1.45.6-1
ii  kmod27+20200310-2
ii  kpartx  0.8.4-3
ii  libc6   2.31-2
ii  libkmod227+20200310-2
ii  pkg-config  0.29.2-1
ii  udev246-2
ii  util-linux  2.36-2

Versions of packages dracut-core recommends:
ii  binutils   2.35-1
ii  console-setup  1.196
ii  cryptsetup 2:2.3.3-1+b1
pn  dmraid 
ii  dmsetup2:1.02.171-2
ii  lvm2   2.03.09-2
pn  mdadm  
ii  pigz   2.4-1+b1
ii  systemd246-2

dracut-core suggests no packages.

-- no debconf information

Bug#967920: Acknowledgement (debian-installer: ewq)

[Diego Escalante Urrelo]

Sorry, I can't figure out how to retitle the bug. I can't seem able to
email a single line instead of two lines to control@ so it can't retitle
the bug:

"EFI: Improve Apple/Mac experience with proper volume icon, label,
description and selectability of installation media"

Also the original title is wrong because of reportbug -__-

On Tue, Aug 4, 2020 at 8:27 PM Debian Bug Tracking System <
ow...@bugs.debian.org> wrote:

> Thank you for filing a new Bug report with Debian.
>
> You can follow progress on this Bug here: 967920:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=967920.
>
> This is an automatically generated reply to let you know your message
> has been received.
>
> Your message is being forwarded to the package maintainers and other
> interested parties for their attention; they will reply in due course.
>
> As you requested using X-Debbugs-CC, your message was also forwarded to
>   die...@gnome.org
> (after having been given a Bug report number, if it did not have one).
>
> Your message has been sent to the package maintainer(s):
>  Debian Install System Team 
>
> If you wish to submit further information on this problem, please
> send it to 967...@bugs.debian.org.
>
> Please do not send mail to ow...@bugs.debian.org unless you wish
> to report a problem with the Bug-tracking system.
>
> --
> 967920: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=967920
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>

Bug#967920: debian-installer: ewq

[Diego Escalante Urrelo]

Package: debian-installer
Severity: normal
X-Debbugs-Cc: die...@gnome.org

Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: Diego Escalante Urrelo 
To: Debian Bug Tracking System 
Subject: debian-installer: EFI: Improve Apple/Mac experience with proper volume 
icon, label, description and selectability of installation media

Package: debian-installer
Severity: wishlist
X-Debbugs-Cc: die...@gnome.org

(Tested with the 20200726-21:15 snapshot)

On Apple hardware, the installer image has no specific label or icon, it
defaults to a "drive" icon and "EFI boot" as label, and the drive is
reported as broken by macOS (and thus can't be selected in the Startup
Disk settings panel (_in_ macOS)).

The above can be handled in the following ways:

- The icon can be provided in a .VolumeIcon.icns file, at the root of
  the EFI partition

- The label is a custom data format next to the boot image, named
  '.disk-label', which is basically a prerendered image of the desired
  text

- Additionally, after fixing the disk detection in macOS, a description
  can be provided in a SystemVersion.plist file, next to the boot image,
  this is used by the Startup Disk panel in macOS setting


However, the above has some challenges too:

- libicns is outdated and does not know how to build .icns files that
  contain and handle all the necessary resolutions that modern Apple
  bootloaders expect, you will be limited to 128px icons. If you want a
  "retina" .VolumeIcon.icns, you need to use `iconutil` on macOS[1]

- the .disk-label file is a simple but custom format that would need a
  generator, or pre-rendering it on a macOS with `bless` (note the label
  is not device or boot specific, it's literally just data)[0]

You don't really need to generate the .VolumeIcon.icns or .disk-label
again, they are literally images, so I don't know what would be the
stance on accepting said files as already generated since they would be
generated using proprietary tools (although bless has its sources
published -- not sure about iconutil).

Generating the label+(retina)icon on a 100% libre pipeline would require
a non-trivial update to the abandoned `libicns` and writing a new script
or program that can create the custom data format[0] for .disk-label.

- the current partition table of the image is broken on macOS and the
  EFI partition is not mountable, thus, you can't choose it as your next
  boot option

Apparently the GPT partition table is broken and macOS is reading the
FAT EFI partition as HFS:

```
macOS:

$ diskutil list
(...)
/dev/disk2 (external, physical):
   #:   TYPE NAMESIZE   IDENTIFIER
   0: Apple_partition_scheme*4.0 GB disk2
   1:Apple_partition_map 4.1 KB disk2s1
   2:  Apple_HFS 3.0 MB disk2s2

Linux:

$ fdisk -t mbr -l /dev/sdc
Disk /dev/sdc: 3,77 GiB, 4048551936 bytes, 7907328 sectors
Disk model: Transcend 4GB   
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x51196c91

Device Boot StartEnd Sectors  Size Id Type
/dev/sdc1  *0 704511  704512  344M  0 Empty
/dev/sdc23908   98275920  2,9M ef EFI (FAT-12/16/32)

$ fdisk -t gpt -l /dev/sdc
Disk /dev/sdc: 3,77 GiB, 4048551936 bytes, 7907328 sectors
Disk model: Transcend 4GB   
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
```

Lookin in the graphical Disk Utility, the partition is labeled as type
"FAT-12", but it's impossible to mount it. This is likely just a bug in
how things are created for the image.

The SystemVersion file is a simple XML file.

---

I believe the above would enhance the installation experience, and
similar changes could be added to the _installed_ system too. Fedora
does something like this with a `mactel-boot` package[2] that drops the
right files in the right place (but note that they are limited to a
128px icon because of the libicns limitations[3]).

I can help provide the necessary files, if it's acceptable to use macOS'
`bless` and `iconutil` to generate them -- since I'm not interested in
becoming a new upstream for libicns :P :P :P.

Also happy to try to provide a patch that does the integration, perhaps
in the same vein as `mactel-boot`[2], if someone points me in the right
direction :) (where would this even go? d-i? a new package?).

0 - http://refit.sourceforge.net/info/vollabel.html
1 - https://github.com/diegoe/libreicns/
2 - https://src.fedoraproject.org/rpms/mactel-boot/tree/master
  - 
https://src.fedoraproject.org/rpms/mactel-boot/blob/master/f/mactel-boot-setup
3 - https://

Bug#746966: HiDPI support

[Diego Escalante Urrelo]

On Tue, Aug 4, 2020 at 7:04 PM Samuel Thibault  wrote:
>
> Diego Escalante, le mar. 04 août 2020 18:55:40 -0500, a ecrit:
> > The GRUB prompt indeed took over the efifb resolution, but because it was
> > using the default font, it was really tiny text.
>
> Mmm, so on your system the resolution you are getting in grub is already
> high and thus tiny text there?

Yeah, this is a MacBook with intel only graphics if it matters. It
defaults to its highest resolution on boot I guess(?).
On my installed system I had to change the GRUB font because otherwise
it was too tiny too.

As I said, the VTs are just fine and properly sized.

I can share a video of the boot process if it helps.

Bug#746966: HiDPI support

[Diego Escalante]

On mié, ago 5, 2020 at 12:50 am, Samuel Thibault 
 wrote:

Hello,

Diego Escalante Urrelo, le mar. 04 août 2020 17:39:34 -0500, a ecrit:

 I was trying to figure out how to fix this


Mmm, actually this should already be fixed, in the context of
#910227. In the latest images we just keep the grub resolution, which 
in
my tests is fine. That's lazy of course, but that's more 
long-term-prone
than tryine a 16x32 font, which sooner or later will again be too 
small.




I just tested with the daily at:
 
https://cdimage.debian.org/cdimage/daily-builds/daily/arch-latest/amd64/iso-cd/debian-testing-amd64-netinst.iso


its README says:
 Debian GNU/Linux testing "Bullseye" - Official Snapshot amd64 
NETINST

  20200726-21:15

The font size for the installer itself remained tiny, same size as 
grub. But the other VTs where "correctly" sized (let's call 16x32 
"correct" for my screen).



The GRUB prompt indeed took over the efifb resolution, but because it 
was using the default font, it was really tiny text.

Bug#859458: Because of displays with very high dpi, not only the keyboard, but the font has to be configured early

[Diego Escalante Urrelo]

Package: console-setup
Followup-For: Bug #859458
X-Debbugs-Cc: die...@gnome.org

I seem unable to reproduce in my current unstable/sid system. At first I
thought it was because I had switched to `dracut`, but seems like I
can't reproduce the original issue with `initramfs-tools`.

Perhaps something else solved this? Maybe a newer `udev`? Can anyone
confirm?

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

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

Versions of packages console-setup depends on:
ii  console-setup-linux 1.196
ii  debconf 1.5.74
ii  keyboard-configuration  1.196
ii  xkb-data2.29-2

console-setup recommends no packages.

Versions of packages console-setup suggests:
ii  locales   2.31-2
ii  lsb-base  11.1.0

Versions of packages keyboard-configuration depends on:
ii  debconf 1.5.74
ii  liblocale-gettext-perl  1.07-4

Versions of packages console-setup-linux depends on:
ii  init-system-helpers 1.58
ii  kbd 2.0.4-4
ii  keyboard-configuration  1.196

console-setup-linux suggests no packages.

Versions of packages console-setup is related to:
pn  console-common
pn  console-data  
pn  console-tools 
ii  gnome-control-center  1:3.36.4-1
ii  kbd   2.0.4-4
ii  systemd   246-2

-- debconf information:
* keyboard-configuration/xkb-keymap: es
* keyboard-configuration/compose: No compose key
* keyboard-configuration/layout:
  keyboard-configuration/unsupported_config_layout: true
  keyboard-configuration/unsupported_layout: true
* keyboard-configuration/other:
* console-setup/fontsize-fb47: 16x32 (framebuffer only)
* console-setup/fontface47: Terminus
* console-setup/codeset47: Guess optimal character set
* keyboard-configuration/variant: Spanish
  console-setup/framebuffer_only:
  console-setup/guess_font:
  console-setup/fontsize-text47: 16x32 (framebuffer only)
* keyboard-configuration/variantcode:
* keyboard-configuration/layoutcode: es
* keyboard-configuration/altgr: The default for the keyboard layout
  console-setup/store_defaults_in_debconf_db: true
* keyboard-configuration/toggle: No toggling
  keyboard-configuration/ctrl_alt_bksp: false
* keyboard-configuration/optionscode:
* keyboard-configuration/store_defaults_in_debconf_db: true
* keyboard-configuration/modelcode: pc105
  console-setup/use_system_font:
  keyboard-configuration/unsupported_options: true
* console-setup/charmap47: UTF-8
  console-setup/codesetcode: guess
* keyboard-configuration/switch: No temporary switch
  debian-installer/console-setup-udeb/title:
  console-setup/fontsize: 16x32
* keyboard-configuration/model: Generic 105-key PC (intl.)
  keyboard-configuration/unsupported_config_options: true

Bug#746966: HiDPI support

[Diego Escalante Urrelo]

Package: debian-installer
Followup-For: Bug #746966
X-Debbugs-Cc: die...@gnome.org

I was trying to figure out how to fix this so that there's a smarter
default that figures out if the screen is way too "big" (hinting that it
is HIDPI).

I thought this should go in console-setup, but perhaps it rather has to
be here. Figuring out the system's condition is not _that_ complex I
think, here's the snippet I was testing in console-setup:

```
# Our minimal HIDPI screen size defaults to 1600px wide, a common
# resolution on 13-14" panels.
#
# For example, a 2560x1600px screen will behave like this:
# * Using Terminus16 it will fit 320 cols (5px/col)
# * Using Terminus32x16 it will fit 160 cols (10px/col)

MIN_WIDTH_HIDPI=1600
virtual_size=/sys/class/graphics/fb0/virtual_size

if [ "$kernel" = linux -a -e "$virtual_size" ]; then
width=`cut -d',' -f2 < "$virtual_size"`

if [ "$width" -ge "$MIN_WIDTH_HIDPI" ]; then
FONTSIZE="16x32"
fi
else
FONTSIZE=16
fi
```

No doubt the check for the fb0 device could be more elegant, but I think
it's a _reasonable_ assumption that when a framebuffer device is
present, we are on a modern system + if the `virtual_size` is BIG, we
can reasonably assume it's a HIDPI screen.

On further reflection I think perhaps this should be in the startup or
configuration scripts of `debian-installer` (?), rather than
`console-setup`, and then, during the installation, inherit the detected
FONTSIZE to `console-setup` via debconf.

Note that there's also:
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=859458

which points out that `console-setup` has some issues with not running
`setupcon` early enough in initramfs, which also needs a solution to make
sure we get proper, readable fonts as early as possible.

I would like to help fix this but I'm not familiar enough with
_conceptually_ who should be changing this setting, but surprisingly it
seems to be rather simple to gather the info we need to make the
decision in whatever script should make it.

Thanks!

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

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

Bug#950334: aptitude: Help -> User's Manual contains special characters

[Diego Escalante]

Package: aptitude
Version: 0.8.13-1+b1
Followup-For: Bug #950334
X-Debbugs-Cc: die...@gnome.org

This is actually a broader bug and not related to specific locales.
The issue is that `src/ui.cc` defaults to transcoding the README files
to ISO-8859-1, and since all the README files are already UTF-8, you get
glitchy glyphs.

I'm attaching a patch for this specific issue, but note that I have an
open MR which includes this and a few more encoding related fixes:
  https://salsa.debian.org/apt-team/aptitude/-/merge_requests/10/commits

Note also that I wasn't able to properly test this because of the
current FTBFS in:
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=966875

But that said, this is merely a string replacement, shouldn't be
problematic.

-- Package-specific info:
Terminal: xterm-256color
$DISPLAY is set.
which aptitude: /usr/bin/aptitude

aptitude version information:
aptitude 0.8.13
Compiler: g++ 9.3.0
Compiled against:
  apt version 6.0.0
  NCurses version 6.2
  libsigc++ version: 2.10.2
  Gtk+ support disabled.
  Qt support disabled.

Current library versions:
  NCurses version: ncurses 6.2.20200212
  cwidget version: 0.5.18
  Apt version: 6.0.0

aptitude linkage:
linux-vdso.so.1 (0x7ffcc57a8000)
libapt-pkg.so.6.0 => /lib/x86_64-linux-gnu/libapt-pkg.so.6.0 
(0x7fbc70029000)
libncursesw.so.6 => /lib/x86_64-linux-gnu/libncursesw.so.6 
(0x7fbc6ffee000)
libtinfo.so.6 => /lib/x86_64-linux-gnu/libtinfo.so.6 
(0x7fbc6ffbf000)
libsigc-2.0.so.0 => /lib/x86_64-linux-gnu/libsigc-2.0.so.0 
(0x7fbc6ffb6000)
libcwidget.so.4 => /lib/x86_64-linux-gnu/libcwidget.so.4 
(0x7fbc6feb)
libsqlite3.so.0 => /lib/x86_64-linux-gnu/libsqlite3.so.0 
(0x7fbc6fd84000)
libboost_iostreams.so.1.71.0 => 
/lib/x86_64-linux-gnu/libboost_iostreams.so.1.71.0 (0x7fbc6fd5b000)
libxapian.so.30 => /lib/x86_64-linux-gnu/libxapian.so.30 
(0x7fbc6fb41000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 
(0x7fbc6fb1f000)
libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 
(0x7fbc6f952000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7fbc6f80e000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 
(0x7fbc6f7f4000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7fbc6f62d000)
libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 
(0x7fbc6f613000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x7fbc6f5f6000)
libbz2.so.1.0 => /lib/x86_64-linux-gnu/libbz2.so.1.0 
(0x7fbc6f5e3000)
liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x7fbc6f5ba000)
liblz4.so.1 => /lib/x86_64-linux-gnu/liblz4.so.1 (0x7fbc6f598000)
libzstd.so.1 => /lib/x86_64-linux-gnu/libzstd.so.1 (0x7fbc6f4ec000)
libudev.so.1 => /lib/x86_64-linux-gnu/libudev.so.1 (0x7fbc6f4c6000)
libsystemd.so.0 => /lib/x86_64-linux-gnu/libsystemd.so.0 
(0x7fbc6f41b000)
libgcrypt.so.20 => /lib/x86_64-linux-gnu/libgcrypt.so.20 
(0x7fbc6f2fe000)
/lib64/ld-linux-x86-64.so.2 (0x7fbc70684000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7fbc6f2f8000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x7fbc6f2eb000)
libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x7fbc6f2e2000)
libgpg-error.so.0 => /lib/x86_64-linux-gnu/libgpg-error.so.0 
(0x7fbc6f2bf000)

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

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

Versions of packages aptitude depends on:
ii  aptitude-common   0.8.13-1
ii  libapt-pkg6.0 2.1.7
ii  libboost-iostreams1.71.0  1.71.0-6+b2
ii  libc6 2.31-2
ii  libcwidget4   0.5.18-5
ii  libgcc-s1 10.2.0-3
ii  libncursesw6  6.2-1
ii  libsigc++-2.0-0v5 2.10.2-1
ii  libsqlite3-0  3.32.3-1
ii  libstdc++610.2.0-3
ii  libtinfo6 6.2-1
ii  libxapian30   1.4.15-1

Versions of packages aptitude recommends:
ii  libdpkg-perl1.20.5
ii  sensible-utils  0.0.12+nmu1

Versions of packages aptitude suggests:
pn  apt-xapian-index
pn  aptitude-doc-en | aptitude-doc  
pn  debtags 
ii  tasksel     3.59

-- no debconf information
>From 0cb1886fbbb0d6339bbd9458bc185b6d82d611af Mon Sep 17 00:00:00 2001
From: Diego Escalante Urrelo 
Date

Bug#966836: dracut-core: Typo in README.Debian

[Diego Escalante]

Package: dracut-core
Version: 050+65-1
Severity: normal
Tags: patch
X-Debbugs-Cc: die...@gnome.org

Dear Maintainer,

There's a typo in README.Debian. Patch attached :).

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

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

Versions of packages dracut-core depends on:
ii  bash5.0-6
ii  cpio2.13+dfsg-2
ii  e2fsprogs   1.45.6-1
ii  kmod27+20200310-2
ii  kpartx  0.8.4-3
ii  libc6   2.31-2
ii  libkmod227+20200310-2
ii  pkg-config  0.29.2-1
ii  udev245.7-1
ii  util-linux  2.36-1

Versions of packages dracut-core recommends:
ii  binutils   2.35-1
ii  console-setup  1.196
ii  cryptsetup 2:2.3.3-1+b1
pn  dmraid 
ii  dmsetup2:1.02.171-2
ii  lvm2   2.03.07-1+b1
pn  mdadm  
ii  pigz   2.4-1+b1
ii  systemd245.7-1

dracut-core suggests no packages.

-- no debconf information
>From f1470ca1120e17d3a5a7fa1ee4429a4ab261b075 Mon Sep 17 00:00:00 2001
From: Diego Escalante Urrelo 
Date: Mon, 3 Aug 2020 01:10:24 -0500
Subject: [PATCH] d: Fix a typo in dracut-core.README.Debian

---
 debian/dracut-core.README.Debian | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/dracut-core.README.Debian b/debian/dracut-core.README.Debian
index a90c66de..c4be1784 100644
--- a/debian/dracut-core.README.Debian
+++ b/debian/dracut-core.README.Debian
@@ -3,7 +3,7 @@ dracut for Debian
 
 1. Give it a try
 
-Currently dracut is not the default initrd craetion tool in Debian.
+Currently dracut is not the default initrd creation tool in Debian.
 You can try dracut without removing initramfs-tools from your machine
 by following these steps:
 
-- 
2.27.0

Bug#966834: debhelper: dh_missing has a confusing typo+msg in $has_related_files

[Diego Escalante]

Package: debhelper
Version: 13.2
Severity: important
X-Debbugs-Cc: die...@gnome.org

Dear Maintainer,

dh_missing prints the following message when $has_related_files is met:

+   if ($had_related_files) {
+   my ($missing, $alt_source) = $had_related_files->@*;
+   nonquiet_print();
+   nonquiet_print('Some of the files had a file that looked 
similar to a missing counter part. Perhaps');
+   nonquiet_print('one of the debhelper tools should installed the 
missing file instead of its related');
+   nonquiet_print('file assuming the content is identical.');
+   nonquiet_print();
+   nonquiet_print('As an example, perhaps you want to replace:');
+   nonquiet_print(" * ${alt_source}");
+   nonquiet_print('with:');
+   nonquiet_print(" * ${missing}");
+   nonquiet_print('in a file in debian/ or as argument to one of 
the dh_* tools called from debian/rules.');
+   nonquiet_print('(Note it is possible the paths are not used 
verbatim but instead directories ');
+   nonquiet_print('containing or globs matching them are used 
instead)');
+   nonquiet_print();
+   nonquiet_print('Alternatively, add the missing file to 
debian/not-installed if it cannot and should not');
+   nonquiet_print('be used.');
+   nonquiet_print();


The above message is confusing in precisely what "file" means, specially
in the second sentence where it goes about "the missing file instead of
its related file" (huh?)

Since there's a typo in "debhelpers tools should (?) installed", I
couldn't figure out what the original intention of the warning was. I
figured out my FTBFS, but mostly because I saw the printed references to
the offending files.

I would have sent you a patch but I didn't know what the message was
supposed to convey. Sorry :(.

I would be thankful if the message could be updated to be slightly more
precise, or at least remove the typo :P.

Thanks!

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

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

Versions of packages debhelper depends on:
ii  autotools-dev20180224.1
ii  dh-autoreconf19
ii  dh-strip-nondeterminism  1.9.0-1
ii  dpkg 1.20.5
ii  dpkg-dev 1.20.5
ii  dwz  0.13-5
ii  file 1:5.38-4
ii  libdebhelper-perl13.2
ii  libdpkg-perl 1.20.5
ii  man-db   2.9.3-1
ii  perl 5.30.3-4
ii  po-debconf   1.0.21

debhelper recommends no packages.

Versions of packages debhelper suggests:
pn  dh-make  

-- no debconf information

Bug#966141: black: syntax error during installation

[Diego Roversi]

Package: black
Version: 18.9b0-1-6
Severity: important

Hello,

  during installation it gives me this error:

Setting up black (18.9b0-1-6) ...
-V is ignored in pypycompile
Failed to byte-compile /usr/lib/python3/dist-packages/black.py:   File
"/usr/lib/python3/dist-packages/black.py", line 128
) -> "FileMode":
^
SyntaxError: invalid syntax


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

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

Versions of packages black depends on:
ii  python33.7.3-1
ii  python3-appdirs1.4.3-1
ii  python3-attr   18.2.0-1
ii  python3-click  7.0-1
ii  python3-pkg-resources  40.8.0-1
ii  python3-toml   0.10.0-1

black recommends no packages.

Versions of packages black suggests:
pn  python-black-doc  

-- debconf-show failed

Bug#963722: gnome-photos iOS photo import does not work without gvfs-fuse

[Diego Escalante]

Package: gnome-photos
Version: 3.34.2-1
Severity: important

Dear Maintainer,

* What led up to the situation?

I installed `gnome-photos` and tried to import photos from my iPhone,
but the app showed me a grid of "broken" (symbolic) thumbnails.

Trying to import photos anyway did not seem to work and many warnings
like the following would be printed to the journal:

Unable to get filename from URI 
gphoto2://Apple_Inc._iPhone_31c7f286debf300e6f6a929b7b72bcea8dd175f1/DCIM/113APPLE/IMG_3797.JPG:
 The URI 
“gphoto2://Apple_Inc._iPhone_31c7f286debf300e6f6a929b7b72bcea8dd175f1/DCIM/113APPLE/IMG_3797.JPG”
 is not an absolute URI using the “file” scheme

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

Mounting the iPhone in `nautilus`, or locking/unlocking did not make any
difference.

Finally, on a whim, installing `gvfs-fuse` solved the issue.

* What was the outcome of this action?

`gnome-photos` should -at least- recommends `gvfs-fuse` so that its
"Import" functionality works, because otherwise it's simply broken.

* What outcome did you expect instead?

`gnome-photos` recommends `gvfs-fuse` so that iOS import works out of
the box (on most boxes).


Note that `gnome-core` does have a relationship to `gvfs-fuse` BUT you
don't have to install `gnome-core` if you simply want `gnome-photos`.

I would suggest a `Recommends:` be added.

Thanks!

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

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

Versions of packages gnome-photos depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.36.0-1
ii  gnome-online-miners  3.34.0-2
ii  libatk1.0-0  2.36.0-2
ii  libbabl-0.1-00.1.78-1
ii  libc62.30-8
ii  libcairo-gobject21.16.0-4
ii  libcairo21.16.0-4
ii  libdazzle-1.0-0  3.36.0-1
ii  libgdata22   0.17.12-1
ii  libgdk-pixbuf2.0-0   2.40.0+dfsg-5
ii  libgegl-0.4-00.4.24-1
ii  libgeocode-glib0 3.26.2-2
ii  libgexiv2-2  0.12.1-1
ii  libgfbgraph-0.2-00.2.3-3
ii  libglib2.0-0 2.64.3-1
ii  libgoa-1.0-0b3.36.0-1
ii  libgrilo-0.3-0   0.3.12-1
ii  libgtk-3-0   3.24.20-1
ii  libjpeg62-turbo  1:1.5.2-2+b1
ii  libpango-1.0-0   1.44.7-4
ii  libpangocairo-1.0-0  1.44.7-4
ii  libpng16-16  1.6.37-2
ii  libtracker-control-2.0-0 2.3.4-1+b1
ii  libtracker-sparql-2.0-0  2.3.4-1+b1
ii  tracker  2.3.4-1+b1
ii  tracker-extract  2.3.3-2+b1

Versions of packages gnome-photos recommends:
ii  dleyna-renderer0.6.0-2
ii  grilo-plugins-0.3  0.3.11-1

gnome-photos suggests no packages.

-- no debconf information

Bug#954079: magic-wormhole: Fails to send with a type error

[Diego M. Rodriguez]

Hi Antoine and Guillem,

> I've reassigned this bug accordingly. It seems that upgrading the
> automat package would fix this.

I have prepared an upload of the latest automat version (20.2.0) in
salsa [1] that hopefully will go through once a sponsor is found.

Best,

[1] https://salsa.debian.org/python-team/modules/automat
-- 
Diego M. Rodriguez



signature.asc
Description: OpenPGP digital signature

Bug#959532: python-nest-asyncio FTBFS: test failures

[Diego M. Rodriguez]

On Sun, 03 May 2020 14:16:47 +0300 Adrian Bunk  wrote:

> Version 1.3.2 seems to be fixed.

Indeed - thanks for the report and the hint, Adrian. I have just
updated salsa [1] with the latest upstream version (1.3.3) and asked
for sponsorship for a new upload.

[1] https://salsa.debian.org/python-team/modules/python-nest-asyncio

-- 
Diego M. Rodriguez



signature.asc
Description: OpenPGP digital signature

Bug#958545: wrong homepage link for pgbouncer

[Diego Arroyo]

Package: pgbouncer
Version: 1.9.0-2
Severity: normal

Dear Maintainer,

Homepage link shown in package description and tracker.debian.org is 
wrong at this moment.
(Seems like domain expired and someone put a weight loss/bodybuilding 
website in pgfoundry.org)


I think the right one should be https://pgbouncer.org, but I am not 
completely sure, as link to the code repository in github did not work also.


Best Regards,

Diego Arroyo

Bug#934479: fails to detect linux update on arm64 (Re: false negative: linux-image-4.19.0.5-powerpc64le)

[Diego Arroyo]

Hello Thomas,

I could not reproduce it with last kernel update in buster powerpc64le.

If it happens again I will provide you the output.

Best Regards,

Diego Arroyo

Bug#942832: usbmuxd freezes when connecting iPhone6 while locked

[Diego Escalante Urrelo]

I went deeper into the GNOME issue and I believe it's a libgphoto2
issue, on Apple devices it stalls for at least 9 seconds or more
retrying to connect when the device is locked. A patched libgphoto2
solves this issue for me.

I don't know if it's worth opening a report on libgphoto2 for debian itself.

For reference, here's the report on libgphoto2:
https://github.com/gphoto/libgphoto2/issues/480

On Tue, Oct 22, 2019 at 3:14 AM Diego Escalante Urrelo  wrote:
>
> Forgot to add that when logging in into my GNOME session, if my iPhone
> is connected, I experience a long freeze too. I thought it was mtp or
> gvfs-gphoto2, but it's probably usbmuxd there too.
>
> Hope you can give me some ideas to fix this, thanks!

Bug#951961: androguard: FTBFS: dh_auto_test: error: pybuild --test --test-nose -i python{version} -p "3.8 3.7" returned exit code 13

[Diego M. Rodriguez]

Hi,

> > Failure: ModuleNotFoundError (No module named 'asn1crypto') ... ERROR
> > ...

I have attempted a fix as merge requests in salsa [1], as it seems to
be a dependencies issue.

[1] https://salsa.debian.org/python-team/modules/androguard/-/merge_requests/2

Best,
-- 
Diego M. Rodriguez



signature.asc
Description: OpenPGP digital signature

Bug#950664: ITP: pylatexenc -- Simple LaTeX parser providing conversion to/from unicode

[Diego M. Rodriguez]

Package: wnpp
Severity: wishlist
Owner: "Diego M. Rodriguez" 

* Package name: python-pylatexenc
  Version : 2.1
  Upstream Author : Philippe Faist 
* URL : https://github.com/phfaist/pylatexenc
* License : Expat
  Programming Lang: Python
  Description : Simple LaTeX parser providing conversion to/from unicode

 Provides a "unicode_to_latex()" function which converts a unicode
 string into LaTeX text and escape sequences, and a module with a
 series of routines that parse the LaTeX structure of given LaTeX code
 and return a logical structure of objects suitable for converting
 into another format such as plain text. The functionality is
 also exposed via command-line scripts (latexencode, latex2text,
 latexwalker).

This package is an optional dependency for updating the existing
qiskit-terra package to its newest version [1]. My intent is to
maintain this package under the umbrella of the Debian Python
Modules Team.

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=933060

-- 
Diego M. Rodriguez



signature.asc
Description: OpenPGP digital signature

Bug#950072: python-asttokens FTBFS with Python 3.8 as supported version

[Diego M. Rodriguez]

It seems the issues were also identified upstream and fixed (via [1] and
other 3.8-related commits), and made it into a new upstream release
(the 2.x line [2]) - I have updated the VCS preparing the new version.

[1] https://github.com/gristlabs/asttokens/pull/36
[2] https://github.com/gristlabs/asttokens/releases

-- 
Diego M. Rodriguez



signature.asc
Description: OpenPGP digital signature

Bug#949531: ITP: qiskit-aer -- Quantum Information Science Kit (Qiskit): Aer

[Diego M. Rodriguez]

Package: wnpp
Severity: wishlist
Owner: "Diego M. Rodriguez" 
User: debian-scie...@lists.debian.org
Usertags: field..science

* Package name: qiskit-aer
  Version : 0.3.4
  Upstream Author : Qiskit Development Team 
* URL : https://github.com/Qiskit/qiskit-aer
* License : Apache-2.0
  Programming Lang: Python, C++
  Description : Quantum Information Science Kit (Qiskit): Aer

 Qiskit (Quantum Information Science Kit) is a collection of software developed
 by IBM Research for working with short depth quantum circuits and building
 near term applications and experiments on quantum computers.
 .
 This package contains Aer, the element that contains high-performance quantum
 computing simulators with realistic noise models.

I intend to package this software under the umbrella of the Debian
Science team. In the same spirit as a recent ITP for
qiskit-ibmq-provider [0], this module was previously included in the
upstream Qiskit terra package, and is now available as a standalone
module (more details about the splitting of the currently packaged
version into smaller packages can be found at #933060 [1], along with
recent updates to the qiskit-terra debian repository [2]).

[0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=949383
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=933060
[2] https://salsa.debian.org/science-team/qiskit-terra

-- 
Diego M. Rodriguez



signature.asc
Description: OpenPGP digital signature

Bug#949383: ITP: qiskit-ibmq-provider -- Quantum Information Science Kit (Qiskit): IBM Q Provider

[Diego M. Rodriguez]

Package: wnpp
Severity: wishlist
Owner: "Diego M. Rodriguez" 
User: debian-scie...@lists.debian.org
Usertags: field..science

* Package name: qiskit-ibmq-provider
  Version : 0.4.5
  Upstream Author : Qiskit Development Team 
* URL : https://github.com/Qiskit/qiskit-ibmq-provider
* License : Apache-2.0
  Programming Lang: Python
  Description : Quantum Information Science Kit (Qiskit): IBM Q Provider

 Qiskit (Quantum Information Science Kit) is a collection of software developed
 by IBM Research for working with short depth quantum circuits and building
 near term applications and experiments on quantum computers.
 .
 This package contains a provider that allows accessing the online IBM Q
 quantum devices and simulators.

I intent to package this software under the umbrella of the Debian
Science team. This module was previously included in the upstream Qiskit
terra package, and is now available as a standalone module (more details
about the splitting of the currently packaged version into smaller
packages can be found at #933060 [1], along with recent updates to the
qiskit-terra debian repository [2]).

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=933060
[2] https://salsa.debian.org/science-team/qiskit-terra

-- 
Diego M. Rodriguez



signature.asc
Description: OpenPGP digital signature

Bug#936251:

[Diego Alvarez]

Package: src:bup
Version: 0.29.3-2
Severity: normal
Tags: sid bullseye
User: debian-pyt...@lists.debian.org
Usertags: py2removal py2keep

I believe this application should be kept in debian for the time being,
given its function as a backup tool.
There is active work being done on it in order to make it compatible with
python3.
I'm not aware of the popcon numbers for it, but I believe it to be popular
enough to warrant keeping it around until the port to python3 has been
finished.

Bug#942832: usbmuxd freezes when connecting iPhone6 while locked

[Diego Escalante Urrelo]

Forgot to add that when logging in into my GNOME session, if my iPhone
is connected, I experience a long freeze too. I thought it was mtp or
gvfs-gphoto2, but it's probably usbmuxd there too.

Hope you can give me some ideas to fix this, thanks!

Bug#942832: usbmuxd freezes when connecting iPhone6 while locked

[Diego Escalante Urrelo]

Package: usbmuxd
Version: 1.1.1~git20181007.f838cf6-1+b1
Severity: important

It seems that usbmuxd is freezing my whole system when I plug a locked
iPhone 6.

I'm attaching a log of journalctl -f and usbmuxd -f, both with the
iPhone locked and then unlocked.

I wasn't able to find any similar bug upstream but I see that usbmuxd is
a snapshot from 2018 while libusbmuxd is from 2019.

Perhaps, in the usual ABI break charm of libimobiledevice and friends,
this needs a bump and rebuild. On a quick test with dpkg-buildpackage
-us -uc of usbmuxd-1.1.1~git20181007.f838cf6, it seems to work "fine"
with the rebuild.

Note that I'm also running a rebuilt libimobiledevice6 because of
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=941703

Attaching the log. Happy to help debug.

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

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

Versions of packages usbmuxd depends on:
ii  adduser3.118
ii  libc6  2.29-2
ii  libimobiledevice6  1.2.1~git20181030.92c5462-1
ii  libplist3  2.0.1~git20190104.3f96731-1
ii  libusb-1.0-0   2:1.0.23-1

usbmuxd recommends no packages.

usbmuxd suggests no packages.

-- no debconf information
/*
/* Connecting iPhone 6 locked
/*

[02:46:59]libertad:debian$ journalctl -f

-- Logs begin at Fri 2019-10-04 16:08:34 -05. --
oct 22 02:42:17 libertad systemd[1]: packagekit.service: Succeeded.
oct 22 02:42:23 libertad NetworkManager[726]:   [1571730143.8598] dhcp4 
(wlx503eaaec81c0): state changed bound -> bound
oct 22 02:42:23 libertad dbus-daemon[691]: [system] Activating via systemd: 
service name='org.freedesktop.nm_dispatcher' 
unit='dbus-org.freedesktop.nm-dispatcher.service' requested by ':1.10' (uid=0 
pid=726 comm="/usr/sbin/NetworkManager --no-daemon")
oct 22 02:42:23 libertad systemd[1]: Starting Network Manager Script Dispatcher 
Service...
oct 22 02:42:23 libertad dbus-daemon[691]: [system] Successfully activated 
service 'org.freedesktop.nm_dispatcher'
oct 22 02:42:23 libertad systemd[1]: Started Network Manager Script Dispatcher 
Service.
oct 22 02:42:34 libertad systemd[1]: NetworkManager-dispatcher.service: 
Succeeded.
oct 22 02:46:53 libertad sudo[2807]:   diegoe : TTY=pts/0 ; 
PWD=/home/diegoe/debian ; USER=root ; COMMAND=/usr/bin/apt install usbmuxd
oct 22 02:46:53 libertad sudo[2807]: pam_unix(sudo:session): session opened for 
user root by (uid=0)
oct 22 02:46:53 libertad sudo[2807]: pam_unix(sudo:session): session closed for 
user root
oct 22 02:47:06 libertad sudo[2822]:   diegoe : TTY=pts/0 ; 
PWD=/home/diegoe/debian ; USER=root ; COMMAND=/usr/sbin/usbmuxd --user usbmux 
--systemd -f -v
oct 22 02:47:06 libertad sudo[2822]: pam_unix(sudo:session): session opened for 
user root by (uid=0)
oct 22 02:47:15 libertad kernel: usb 1-2.1: new high-speed USB device number 34 
using xhci_hcd
oct 22 02:47:15 libertad kernel: usb 1-2.1: New USB device found, 
idVendor=05ac, idProduct=12a8, bcdDevice= 7.02
oct 22 02:47:15 libertad kernel: usb 1-2.1: New USB device strings: Mfr=1, 
Product=2, SerialNumber=3
oct 22 02:47:15 libertad kernel: usb 1-2.1: Product: iPhone
oct 22 02:47:15 libertad kernel: usb 1-2.1: Manufacturer: Apple Inc.
oct 22 02:47:15 libertad kernel: usb 1-2.1: SerialNumber: 
31c7f286debf300e6f6a929b7b72bcea8dd175f1
oct 22 02:47:15 libertad mtp-probe[2827]: checking bus 1, device 34: 
"/sys/devices/pci:00/:00:14.0/usb1/1-2/1-2.1"
oct 22 02:47:15 libertad mtp-probe[2827]: bus: 1, device: 34 was not an MTP 
device
oct 22 02:47:15 libertad kernel: ipheth 1-2.1:4.2: Apple iPhone USB Ethernet 
device attached
oct 22 02:47:15 libertad NetworkManager[726]:   [1571730435.8924] 
manager: (eth0): new Ethernet device 
(/org/freedesktop/NetworkManager/Devices/25)
oct 22 02:47:15 libertad mtp-probe[2836]: checking bus 1, device 34: 
"/sys/devices/pci:00/:00:14.0/usb1/1-2/1-2.1"
oct 22 02:47:15 libertad mtp-probe[2836]: bus: 1, device: 34 was not an MTP 
device
oct 22 02:47:15 libertad colord[1037]: CdMain: failed to emit DeviceAdded: 
failed to register object: An object is already exported for the interface 
org.freedesktop.ColorManager.Device at 
/org/freedesktop/ColorManager/devices/sysfs__null_
oct 22 02:47:15 libertad colord[1037]: CdMain: failed to emit DeviceAdded: 
failed to register object: An object is already exported for the interface 
org.freedesktop.ColorManager.Device at 
/org/freedesktop/ColorManager/devices/sysfs__null_
oct 22 02:47:15 libertad systemd-udevd

Bug#941703: [Pkg-gtkpod-devel] Bug#941703: libimobiledevice6: Crashes upower with stack smashing when connecting an iPhone

[Diego Escalante Urrelo]

Sorry for the radio silence, I was away for a few days.
Just for reference, I run into the crash after updating my unstable
system on 2019-09-30, and it seems libusbmuxd was updated:
libusbmuxd4:amd64 (1.1.0~git20181007.07a493a-1, 1.1.0~git20190924.b097ea3-2)

I had no idea libusbmuxd behaved like that with its types/API, I got
to that same struct but didn't even consider it had been changed
without notice!

Anyway, thanks for your work on this. Let me know if I can help with
anything else.

On Sat, Oct 5, 2019 at 8:41 AM Yves-Alexis Perez  wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> On Sat, 2019-10-05 at 14:50 +0200, Yves-Alexis Perez wrote:
> > That beeing said, it would be helpful to know when the problem started
> > appearing for you. libimobiledevice wasn't updated recently, but libusbmuxd
> > was, and it seems that there might be a really tight dependency between 
> > both,
> > and the libimobiledevice currently in testing and sid (there's a one sitting
> > in NEW) was built against the previous version of libusbmuxd.
>
> If the crashed appeared recently, I'd guess it's due to the struct change in:
> https://github.com/libimobiledevice/libusbmuxd/commit/f5a7387a54ae08c9cd1d83a415393e0e909dc6e6#diff-038b1c435b1baca0fc7faaf5e375f401L37
>
> Unfortunately, there is no real SONAME tracking in libusbmuxd apparently, and
> I missed it too.
>
> I think a rebuild of libimobiledevice should fix the issue at hand, until the
> new one exits NEWS. Long term a proper solution should be found, I'll try to
> ask upstream about that.
>
> Regards,
> - --
> Yves-Alexis
> -BEGIN PGP SIGNATURE-
>
> iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAl2YnXcACgkQ3rYcyPpX
> RFskrggApmspfJRWofKg3JxrG5JSQpgWmNyk4GPqw2lAcMllqYnQZ2Gu7lPlHziN
> JNaADOPxze+frdyapaOHQBoccFT/gTcyyZ+y7nPvM7OiJux8GIENV8fKYV/YBBON
> Y5C8VeOQC080yBfB+V4zJadrLT1AdoOLPuD6ve9CH3UfClIsiHu1bcvIN5B0tAZW
> JKVK/J2kLMtJRLrH2Q9zkXkOrSC9q/Pb+6VkHN75pIbYc9K1YKK0Dim3cT++OXHb
> nqRKXWpX/275BxQpnuQuoXxqLSDsk6jSGEZUx2qikbJgyyBWAeT7iNds15iCu1j/
> nIs8wURnEXWMLDy4M+SMLsy+EcACXA==
> =Lm+g
> -END PGP SIGNATURE-

Bug#942132: ITP: python-nest-asyncio -- Patch asyncio to allow nested event loops

[Diego M. Rodriguez]

On 10/10/19 9:04 PM, Sam Hartman wrote:

> The above description should be improved.

Thanks for your prompt feedback, Sam - I resorted to keeping the same
description present in the project's documentation, not being aware
that the 3.4 policy actually discourages it explicitly.

I'll revise the description during packaging in the hopes of producing
a more accurate summary.

Best,
-- 
Diego M. Rodriguez



signature.asc
Description: OpenPGP digital signature

Bug#942136: python-marshmallow: Consider packaging new upstream version (3.2.1)

[Diego M. Rodriguez]

Package: python-marshmallow
Severity: wishlist

Dear Maintainer,

a few weeks ago, marshmallow published its first non-RC release of the
3.x branch [1], followed up by a number of releases. Would it be
possible to update the package accordingly, in order to ensure all the
changes in previous RC versions are received and be closer to the
stable version?

Best regards,

[1] https://github.com/marshmallow-code/marshmallow/releases/tag/3.0.0
-- 
Diego M. Rodriguez



signature.asc
Description: OpenPGP digital signature

Bug#942133: ITP: python-marshmallow-polyfield -- A marshmallow extension for polymorphic fields

[Diego M. Rodriguez]

Package: wnpp
Severity: wishlist
Owner: "Diego M. Rodriguez" 

* Package name: python-marshmallow-polyfield
  Version : 5.7
  Upstream Author : Matt Bachmann 
* URL : https://github.com/Bachmann1234/marshmallow-polyfield
* License : Apache-2.0
  Programming Lang: Python
  Description : A marshmallow extension for polymorphic fields

marshmallow extension that adds a custom field designed for polymorphic
types, allowing defining schemas that say "this field accepts anything
of type X". This field should support the same properties as other
marshmallow fields, including "required", "allow_none", and "many".


This package is a dependency for updating the existing qiskit-terra
package to its newest version. The intent is to maintain this package
under the umbrella of the Debian Python Modules Team.
-- 
Diego M. Rodriguez



signature.asc
Description: OpenPGP digital signature

Bug#942132: ITP: python-nest-asyncio -- Patch asyncio to allow nested event loops

[Diego M. Rodriguez]

Package: wnpp
Severity: wishlist
Owner: "Diego M. Rodriguez" 

* Package name: python-nest-asyncio
  Version : 1.2.0
  Upstream Author : Ewald R. de Wit 
* URL : https://github.com/erdewit/nest_asyncio
* License : BSD-2-clause
  Programming Lang: Python
  Description : Patch asyncio to allow nested event loops

 By design asyncio does not allow its event loop to be nested. This
 presents a practical problem: When in an environment where the event
 loop is already running it's impossible to run tasks and wait for the
 result. This module patches asyncio to allow nested use of asyncio.run
 and loop.run_until_complete.

This package is a dependency for updating the existing qiskit-terra
package to its newest version. The intent is to maintain this package
under the umbrella of the Debian Python Modules Team.

-- 
Diego M. Rodriguez



signature.asc
Description: OpenPGP digital signature

Bug#941764: osinfo-db: broken debian installer URL, needs update to latest upstream

[Diego Escalante Urrelo]

Package: osinfo-db
Version: 0.20190728-2
Severity: important

On sid, you can't use gnome-boxes to install Debian 10 because the
osinfo-db ISO url still points to the 10.0 release. Because those ISOs
don't exist anymore, the installation fails.

Upstream master already has the updated url.

Reference:
(gnome-boxes:9131): Boxes-WARNING **: 17:52:06.447: wizard.vala:666: Failed 
downloading media 
'http://cdimage.debian.org/cdimage/release/10.0.0/i386/iso-cd/debian-10.0.0-i386-netinst.iso'!
 Not Found

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

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

-- no debconf information

Bug#941703: [Pkg-gtkpod-devel] Bug#941703: libimobiledevice6: Crashes upower with stack smashing when connecting an iPhone

[Diego Escalante Urrelo]

Well I noticed the crash because upower uses idevice_new in
up-device-idevice.c, I guess to monitor idevice's batteries.
In my system upower was endlessly rebooting itself, and when checking
I saw the crash was in idevice_new itself. Further investigation lead
me to confirm that idevice utils crash themselves, thus the
observations in my previous email.

So I guess the short story is that I noticed the problem because it
crashed upower, but the bug was in libimobiledevice all along.
My apologies if my initial report wasn't very complete, I'll blame
myself for being rusty from years of non desktop work :P.

On Fri, Oct 4, 2019 at 4:11 AM Yves-Alexis Perez  wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> On Fri, 2019-10-04 at 03:18 -0500, Diego Escalante Urrelo wrote:
> > While trying to play around with this, I rebuild libimobiledevice
> > locally from the sources available in unstable and the crash went
> > away.
> > If I reinstall the .deb from the repositories I can get the crash
> > back, reinstalling the locally built package fixes the problem (from
> > apt source + dpkg-buildpackage -us -uc).
> >
> > I guess this is still a libimobiledevice bug since I can reproduce the
> > stack smash by running ideviceinfo and a few other of the idevice
> > utilities (idevicename, idevicesyslog):
>
> It seems there's a tight link between libimobiledevice and libusbmuxd
> versions, but I fail to see how UPower is related to that, to be honest.
> - --
> Yves-Alexis
> -BEGIN PGP SIGNATURE-
>
> iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAl2XDJkACgkQ3rYcyPpX
> RFufCggA4bLQqtUGNHdROTEZt3iOcKivQIwsu7t1JM47RdgXqwWhtSz2OqDwclpF
> KoL24Rep1NbseLkcUeACMpCnJupmwfV8nbaEv8JFymdHX75MrvYLuyaxk7NYgpbW
> sznhOa/8CUDIV2Z9z/CIA9vC3SoY2pbkjXJDABgH1gkd+A2nKkI3r7cwSuq0lwR9
> cIpfo7ItTHvq5F977JKcmsGDr/N9a3P7Ra1gbw98e7zOVbnrDBRD/9TISR8oF9dA
> Ni+Ic1x6Ipiz+RNo/6dXBF5c7e7wlFvvJJ/LEFkriChWQu9VsvH8842rlCwch6Gb
> xMInKU3OaOqUMK9nRS6G0M1mJpYsnw==
> =2ETL
> -END PGP SIGNATURE-

Bug#941703: [Pkg-gtkpod-devel] Bug#941703: libimobiledevice6: Crashes upower with stack smashing when connecting an iPhone

[Diego Escalante Urrelo]

Hi

While trying to play around with this, I rebuild libimobiledevice
locally from the sources available in unstable and the crash went
away.
If I reinstall the .deb from the repositories I can get the crash
back, reinstalling the locally built package fixes the problem (from
apt source + dpkg-buildpackage -us -uc).

I guess this is still a libimobiledevice bug since I can reproduce the
stack smash by running ideviceinfo and a few other of the idevice
utilities (idevicename, idevicesyslog):
(gdb) r
Starting program: /usr/bin/ideviceinfo
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
*** stack smashing detected ***:  terminated

Program received signal SIGABRT, Aborted.
__GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
50../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1  0x77dd0535 in __GI_abort () at abort.c:79
#2  0x77e26db8 in __libc_message (action=,
fmt=fmt@entry=0x77f318a2 "*** %s ***: %s terminated\n")
at ../sysdeps/posix/libc_fatal.c:181
#3  0x77eb581d in __GI___fortify_fail_abort
(need_backtrace=need_backtrace@entry=false,
msg=msg@entry=0x77f31880 "stack smashing detected")
at fortify_fail.c:28
#4  0x77eb57d2 in __stack_chk_fail () at stack_chk_fail.c:29
#5  0x77f744b7 in idevice_new () from
/lib/x86_64-linux-gnu/libimobiledevice.so.6
#6  0x in ?? ()

On Fri, Oct 4, 2019 at 2:26 AM Yves-Alexis Perez  wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> control: reassign -1 upower
>
> On Thu, 2019-10-03 at 18:23 -0500, Diego Escalante Urrelo wrote:
> > Whenever you connect an iPhone when upower is running, a crash in upower
> > is triggered, apparently because libimobiledevice is doing something
> > leading to a stack smash crash.
> >
> > The same happens if you already have the iPhone connected when upower
> > starts. I'm attaching a trace and log of the first case (connecting the
> > iPhone when upower is already running).
> >
> > Note that this crash triggers upower to endlessly reload because of the
> > crash-restart-crash cycle it gets into.
>
> Hi Diego,
>
> that looks spurious indeed, and I don't think I ever experienced that. When
> did this behavior appeared and can you link it to a specific upgrade?
>
> Also, I'm really not sure it's a problem in libimobiledevice. If UPower
> crashes, then it's likely a problem in UPower (maybe because it doesn't like
> the way a new battery is appearing or something).
>
> I'm reassigning to UPower and add their maintainer to CC:.
>
> @UPower maintainer: feel free to reassign back if you identify something wrong
> in libimobiledevice.
>
> Regards,
> - --
> Yves-Alexis
> -BEGIN PGP SIGNATURE-
>
> iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAl2W8/kACgkQ3rYcyPpX
> RFt2KQf9ETUPRbi30PtbN/dEwIZFDZwxZt8tGP/hw7ewn4Iq5ctQed5O2uyknC41
> txfBr2AuwnfIOcqr/0swRNRJ2t7pRvX6XJL3MmY11KLtI7FtZ/RJ4CdZmRLQGYRO
> b3rso4ZP7ueQcTpIYr1Fy5nXPBM/Mc4m8wKzFklYu6lc4izYDDCIoUJknBMudn2S
> YxUc72zSln6r3ExrPsr/XFnfMNH/gGTlKSmsyfcK7wQJk9B5e4Ofjvc49f+hU/gK
> 1yzvHnycwDz2QPahS5NNB0S7n/TmTiIXZ9rJLL0jQsFBYhu4FuShxY+5boRZvxaF
> 1tQsnWmTHxkhhrZ+wbWJVnS45Eu0TA==
> =pkib
> -END PGP SIGNATURE-

Bug#941703: libimobiledevice6: Crashes upower with stack smashing when connecting an iPhone

[Diego Escalante Urrelo]

Package: libimobiledevice6
Version: 1.2.1~git20181030.92c5462-1
Severity: important

Whenever you connect an iPhone when upower is running, a crash in upower
is triggered, apparently because libimobiledevice is doing something
leading to a stack smash crash.

The same happens if you already have the iPhone connected when upower
starts. I'm attaching a trace and log of the first case (connecting the
iPhone when upower is already running).

Note that this crash triggers upower to endlessly reload because of the
crash-restart-crash cycle it gets into.

TI:18:18:15 on_battery = no
TI:18:18:15 SYSFS add /sys/devices/pci:00/:00:14.0/usb1/1-2/1-2.2
TI:18:18:15 no changes
TI:18:18:15 failed to refresh 
/sys/devices/pci:00/:00:14.0/usb1/1-2/1-2.2
TI:18:18:15 object path = /org/freedesktop/UPower/devices/phone_1_2x2
TI:18:18:15 added /sys/devices/pci:00/:00:14.0/usb1/1-2/1-2.2
TI:18:18:15 emitting added: /org/freedesktop/UPower/devices/phone_1_2x2
TI:18:18:15 SYSFS add 
/sys/devices/pci:00/:00:14.0/usb1/1-2/1-2.2/1-2.2:1.0
TI:18:18:15 failed to coldplug 
/sys/devices/pci:00/:00:14.0/usb1/1-2/1-2.2/1-2.2:1.0
[New Thread 0x7532e700 (LWP 5588)]
TI:18:18:15 failed to coldplug 
/sys/devices/pci:00/:00:14.0/usb1/1-2/1-2.2/1-2.2:1.0
[Thread 0x7532e700 (LWP 5588) exited]
TI:18:18:15 failed to coldplug 
/sys/devices/pci:00/:00:14.0/usb1/1-2/1-2.2/1-2.2:1.0
TI:18:18:15 unhandled action 'bind' on 
/sys/devices/pci:00/:00:14.0/usb1/1-2/1-2.2
TI:18:18:15 SYSFS remove 
/sys/devices/pci:00/:00:14.0/usb1/1-2/1-2.2/1-2.2:1.0
TI:18:18:15 ignoring remove event on 
/sys/devices/pci:00/:00:14.0/usb1/1-2/1-2.2/1-2.2:1.0
TI:18:18:15 SYSFS add 
/sys/devices/pci:00/:00:14.0/usb1/1-2/1-2.2/1-2.2:4.0
TI:18:18:15 failed to coldplug 
/sys/devices/pci:00/:00:14.0/usb1/1-2/1-2.2/1-2.2:4.0
[New Thread 0x7532e700 (LWP 5594)]
TI:18:18:15 failed to coldplug 
/sys/devices/pci:00/:00:14.0/usb1/1-2/1-2.2/1-2.2:4.0
[Thread 0x7532e700 (LWP 5594) exited]
TI:18:18:15 failed to coldplug 
/sys/devices/pci:00/:00:14.0/usb1/1-2/1-2.2/1-2.2:4.0
TI:18:18:15 SYSFS add 
/sys/devices/pci:00/:00:14.0/usb1/1-2/1-2.2/1-2.2:4.2
TI:18:18:15 failed to coldplug 
/sys/devices/pci:00/:00:14.0/usb1/1-2/1-2.2/1-2.2:4.2
[New Thread 0x7532e700 (LWP 5596)]
TI:18:18:15 failed to coldplug 
/sys/devices/pci:00/:00:14.0/usb1/1-2/1-2.2/1-2.2:4.2
[Thread 0x7532e700 (LWP 5596) exited]
TI:18:18:15 failed to coldplug 
/sys/devices/pci:00/:00:14.0/usb1/1-2/1-2.2/1-2.2:4.2
TI:18:18:15 SYSFS add 
/sys/devices/pci:00/:00:14.0/usb1/1-2/1-2.2/1-2.2:4.1
TI:18:18:15 failed to coldplug 
/sys/devices/pci:00/:00:14.0/usb1/1-2/1-2.2/1-2.2:4.1
[New Thread 0x7532e700 (LWP 5598)]
TI:18:18:15 failed to coldplug 
/sys/devices/pci:00/:00:14.0/usb1/1-2/1-2.2/1-2.2:4.1
[Thread 0x7532e700 (LWP 5598) exited]
TI:18:18:15 failed to coldplug 
/sys/devices/pci:00/:00:14.0/usb1/1-2/1-2.2/1-2.2:4.1
TI:18:18:15 unhandled action 'bind' on 
/sys/devices/pci:00/:00:14.0/usb1/1-2/1-2.2/1-2.2:4.1
TI:18:18:15 unhandled action 'bind' on 
/sys/devices/pci:00/:00:14.0/usb1/1-2/1-2.2/1-2.2:4.2
TI:18:18:15 unhandled action 'bind' on 
/sys/devices/pci:00/:00:14.0/usb1/1-2/1-2.2/1-2.2:4.0
TI:18:18:16 Unknown state on supply 
/org/freedesktop/UPower/devices/battery_BAT0; forcing update after 1 seconds
TI:18:18:16 on_battery = no
TI:18:18:16 on_battery = no
TI:18:18:16 using min design voltage
TI:18:18:16 on_battery = no
TI:18:18:16 on_battery = no
TI:18:18:16 on_battery = no
TI:18:18:16 Setup poll for 'BAT0' every 120 seconds
TI:18:18:16 on_battery = no
TI:18:18:16 on_battery = no
TI:18:18:16 on_battery = no
TI:18:18:16 Setup poll for 'BAT0' every 120 seconds
TI:18:18:16 on_battery = no
TI:18:18:16 on_battery = no
TI:18:18:16 on_battery = no
TI:18:18:16 Setup poll for 'BAT0' every 120 seconds
TI:18:18:16 on_battery = no
TI:18:18:16 on_battery = no
TI:18:18:16 on_battery = no
TI:18:18:16 on_battery = no
TI:18:18:16 on_battery = no
TI:18:18:16 on_battery = no
TI:18:18:16 on_battery = no
[Thread 0x75b2f700 (LWP 5543) exited]
*** stack smashing detected ***:  terminated

Thread 1 "upowerd" received signal SIGABRT, Aborted.
__GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
50  ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0  0x77a1c081 in __GI_raise (sig=sig@entry=6) at 
../sysdeps/unix/sysv/linux/raise.c:50
#1  0x77a07535 in __GI_abort () at abort.c:79
#2  0x77a5ddb8 in __libc_message (action=, 
fmt=fmt@entry=0x77b688a2 "*** %s ***: %s terminated\n")
at ../sysdeps/posix/libc_fatal.c:181
#3  0x77aec81d in __GI_

Bug#939768: gimp: After the last upgrade, GIMP crashes when creating a new image or opening an existing one.

[Diego Caraffini]

Package: gimp
Version: 2.10.8-2+b1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

I currently use testing (bullseye), amd since the last upgrade, GIMP
keeps crashing whwnever I open am image or even create new one.

The images in question were edited minutes before the upgrade, so they
should adhere to the latest format specification.

The issue was noticed while using gimp-console and python-fu to convert
the images to pdf as part of the compilation of a latex document, and
later veriied to happen within the GUI.

This makes GIMP unusable.

The debug information is after the System information

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

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

Versions of packages gimp depends on:
ii  gimp-data2.10.8-2
ii  libaa1   1.4p5-46+b1
ii  libbabl-0.1-00.1.62-1
ii  libbz2-1.0   1.0.6-9.2
ii  libc62.28-10
ii  libcairo21.16.0-4
ii  libfontconfig1   2.13.1-2+b1
ii  libfreetype6 2.9.1-4
ii  libgcc1  1:9.2.1-4
ii  libgdk-pixbuf2.0-0   2.38.1+dfsg-1
ii  libgegl-0.4-00.4.12-2
ii  libgexiv2-2  0.10.9-1
ii  libgimp2.0   2.10.8-2+b1
ii  libglib2.0-0 2.60.6-2
ii  libgs9   9.27~dfsg-3.1
ii  libgtk2.0-0  2.24.32-3
ii  libgudev-1.0-0   232-2
ii  libharfbuzz0b2.6.1-2
ii  libheif1 1.5.1-1
ii  libilmbase24 2.3.0-6
ii  libjpeg62-turbo  1:1.5.2-2+b1
ii  liblcms2-2   2.9-3+b1
ii  liblzma5 5.2.4-1+b1
ii  libmng1  1.0.10+dfsg-3.1+b5
ii  libmypaint-1.3-0 1.3.0-2.1+b1
ii  libopenexr24 2.3.0-6
ii  libopenjp2-7 2.3.0-2
ii  libpango-1.0-0   1.42.4-7
ii  libpangocairo-1.0-0  1.42.4-7
ii  libpangoft2-1.0-01.42.4-7
ii  libpng16-16  1.6.37-1
ii  libpoppler-glib8 0.71.0-5+b1
ii  librsvg2-2   2.44.14-1
ii  libstdc++6   9.2.1-4
ii  libtiff5 4.0.10+git190818-1
ii  libwebp6 0.6.1-2+b1
ii  libwebpdemux20.6.1-2+b1
ii  libwebpmux3  0.6.1-2+b1
ii  libwmf0.2-7  0.2.8.4-14
ii  libx11-6 2:1.6.7-1
ii  libxcursor1  1:1.2.0-2
ii  libxext6 2:1.3.3-1+b2
ii  libxfixes3   1:5.0.3-1
ii  libxmu6  2:1.1.2-2+b3
ii  libxpm4  1:3.5.12-1
ii  xdg-utils1.1.3-1
ii  zlib1g   1:1.2.11.dfsg-1+b1

Versions of packages gimp recommends:
ii  ghostscript  9.27~dfsg-3.1

Versions of packages gimp suggests:
pn  gimp-data-extras  
pn  gimp-help-en | gimp-help  
ii  gimp-python   2.10.8-2+b1
ii  gvfs-backends 1.38.1-5
ii  libasound21.1.8-1

-- no debconf information


-- Debug information:
```
GNU Image Manipulation Program version 2.10.8
git-describe: GIMP_2_10_6-294-ga967e8d2c2
C compiler:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/9/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:hsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 9.2.1-6' 
--with-bugurl=file:///usr/share/doc/gcc-9/README.Bugs 
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,gm2 --prefix=/usr 
--with-gcc-major-version-only --program-suffix=-9 
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id 
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix 
--libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu 
--enable-libstdcxx-debug --enable-libstdcxx-time=yes 
--with-default-libstdcxx-abi=new --enable-gnu-unique-object 
--disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib 
--with-target-system-zlib=auto --enable-multiarch --disable-werror 
--with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 
--enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none,hsa 
--without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu 
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 9.2.1 20190827 (Debian 9.2.1-6) 

using GEGL version 0.4.12 (compiled against version 0.4.14)
using GLib version 2.60.6 (compiled against version 2.60.6)
using GdkPixbuf version 2.38.1 (compiled against version 2.38.1)
using GTK+ version 2.24.32 (compiled against version 2.24.32)
using Pango version 1.42.3 (compiled against version 1.42.3)
using Fontconfig version 2.13.1 (compiled against version 2.13.1)
using Cairo versio

Bug#936000: cheese-dev requires undeclared libgstreamer-plugins-bad1.0-dev in its pkg-config file

[Diego Escalante Urrelo]

Package: cheese
Version: 3.33.90.1-1
Severity: normal

cheese-dev in experimental requires libgstreamer-plugins-bad1.0-dev to be
used in pkg-config successfully:

pkg-config --cflags cheese
Package gstreamer-plugins-bad-1.0 was not found in the pkg-config search path.
Perhaps you should add the directory containing `gstreamer-plugins-bad-1.0.pc'
to the PKG_CONFIG_PATH environment variable
Package 'gstreamer-plugins-bad-1.0', required by 'cheese', not found

This dependency is currently not declared or enforced in the deb package.

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

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

Versions of packages cheese depends on:
ii  cheese-common  3.33.90.1-1
ii  gnome-video-effects0.5.0-1
ii  libc6  2.29-0experimental1
ii  libcanberra-gtk3-0 0.30-7
ii  libcheese-gtk253.33.90.1-1
ii  libcheese8 3.33.90.1-1
ii  libclutter-1.0-0   1.26.2+dfsg-12
ii  libclutter-gtk-1.0-0   1.8.4-4
ii  libgdk-pixbuf2.0-0 2.39.2-3
ii  libglib2.0-0   2.61.2-2
ii  libgnome-desktop-3-17  3.32.2-2
ii  libgstreamer1.0-0  1.16.0-2.1
ii  libgtk-3-0 3.24.10-1

Versions of packages cheese recommends:
ii  gvfs  1.41.91-1
ii  yelp  3.32.2-1

Versions of packages cheese suggests:
pn  gnome-video-effects-frei0r  

-- no debconf information

Bug#935992: gnome-builder crashes trying to install missing flatpak platform/runtime/sdk

[Diego Escalante Urrelo]

Package: gnome-builder
Version: 3.32.0-1
Severity: important
Tags: patch

If you try to load a project that needs to download its SDK from
flatpak, it will crash gnome-builder.

To reproduce simply make sure you don't have any of the GNOME sdks
installed in flatpak and then try to setup/clone any project like Polari
or gedit, when it tries to install the missing sdk it will crash.

(trace attached)

The problem can be work-around'd by patching something very simple like
a check for NULL (attached) but according to upstream this problem was
fixed by reworking other internal APIs, thus, not easily backportable.

I'm attaching a proof of concept patch that seems to work for me.

There's also the fact that gnome-builder is trying to add
gnome.flatpakrepo, which seems to be deprecated upstream, I'm attaching
the relevant upstream commit that disabled that. That said I'm not
100% sure if it even matters (I believe it should be silently failin).

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

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

Versions of packages gnome-builder depends on:
ii  clang1:7.0-47.1
ii  dconf-gsettings-backend [gsettings-backend]  0.33.2-1
ii  exuberant-ctags  1:5.9~svn20110310-12
ii  gir1.2-dazzle-1.03.33.90-1
ii  gir1.2-ggit-1.0  0.28.0.1-1
ii  gir1.2-glib-2.0  1.60.1-1
ii  gir1.2-gtk-3.0   3.24.10-1
ii  gir1.2-gtksource-3.0 3.24.11-1
ii  gir1.2-gtksource-4   4.3.1-2
ii  gir1.2-jsonrpc-1.0   3.32.0-1
ii  gir1.2-peas-1.0  1.22.0-4
ii  gir1.2-template-1.0  3.32.0-1
ii  gir1.2-vte-2.91  0.57.90-2
ii  gir1.2-webkit2-4.0   2.25.4-1
ii  libatk1.0-0  2.33.3+really2.33.3-1
ii  libc62.29-0experimental1
ii  libcairo-gobject21.16.0-4
ii  libcairo21.16.0-4
ii  libclang1-7  1:7.0.1-9+b1
ii  libdazzle-1.0-0  3.33.90-1
ii  libdevhelp-3-6   3.32.0-1
ii  libenchant1c2a   1.6.0-11.1+b1
ii  libflatpak0  1.4.2-2
ii  libfontconfig1   2.13.1-2+b1
ii  libgdk-pixbuf2.0-0   2.39.2-3
ii  libgirepository-1.0-11.60.1-1
ii  libgit2-glib-1.0-0   0.28.0.1-1
ii  libgladeui-2-6   3.22.1-3
ii  libglib2.0-0 2.61.2-2
ii  libgspell-1-11.6.1-2
ii  libgtk-3-0   3.24.10-1
ii  libgtksourceview-4-0 4.3.1-2
ii  libjson-glib-1.0-0   1.4.4-2
ii  libjsonrpc-glib-1.0-13.32.0-1
ii  libpango-1.0-0   1.42.4-7
ii  libpangocairo-1.0-0  1.42.4-7
ii  libpangoft2-1.0-01.42.4-7
ii  libpcre3 2:8.39-12+b1
ii  libpeas-1.0-01.22.0-4
ii  libsoup2.4-1 2.67.92-2
ii  libtemplate-glib-1.0-0   3.32.0-1
ii  libvala-0.44-0   0.44.7-1
ii  libvala-0.44-dev 0.44.7-1
ii  libvte-2.91-00.57.90-2
ii  libwebkit2gtk-4.0-37 2.25.4-1
ii  libxml2  2.9.8+dfsg-1+b1
ii  python3  3.7.3-1
ii  python3-gi   3.33.1-1
ii  sysprof  3.32.0-1
ii  valac-0.44-vapi  0.44.7-1

Versions of packages gnome-builder recommends:
ii  build-essential  12.7
ii  flatpak-builder  1.0.8-2
ii  gettext  0.19.8.1-9
ii  meson0.51.2-1
ii  pkg-config   0.29-6
ii  python3-jedi 0.14.1-1
ii  python3-lxml 4.4.1-1
pn  valgrind 

gnome-builder suggests no packages.

-- no debconf information
13:15:55.0181  main[ 5833]:  MESSAGE: 
Initializing with GNOME desktop and GTK+ 3.24.10.
13