Bug#1008926: gnome-shell crashes on login with GLib.TimeZone.get_offset JS ERROR

[Kipp Cannon]

Hi,

Thanks, yes, today (2022-04-05) I have found gnome-shell 42.0-2 to have
migrated into testing, and upgrading to this version has resolved the
problem.

This bug can be closed.

-Kipp


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

Bug#998739:

[Rich]

I was just going to report a similar bug to this, after attempting to
migrate a package from using distutils.sysconfig to sysconfig (due to 3.10
now screaming about distutils being removed Soon(tm)), and discovering that
distutils.sysconfig does report dist-packages, while sysconfig reports
site-packages, just as described in [1].

>>> distutils.sysconfig.get_python_lib(0,0)
/usr/lib/python3/dist-packages
>>> sysconfig.get_path('platlib')
'/usr/lib/python3.9/site-packages'

So I'd recommend changing _something_ so that these become at least
consistent, or people are just going to start having to add Debian-specific
hacks everywhere or just ignoring Debian's intended locations, and neither
strikes me as great for anyone.

- Rich

[1] -
https://ffy00.github.io/blog/02-python-debian-and-the-install-locations/

Bug#1008959: devscripts: misdetects new upstream version

[Vagrant Cascadian]

Package: devscripts
Version: 2.22.1
Severity: normal
X-Debbugs-Cc: none, Vagrant Cascadian 
File: /usr/bin/uscan


Using the following watch file where @PACKAGE@ is u-boot:

version=4

opts=dversionmangle=auto,\
 pgpmode=auto,\
 repacksuffix=+dfsg,\
 uversionmangle=s/-rc/~rc/ \
https://ftp.denx.de/pub/@PACKAGE@/ \
@PACKAGE@@ANY_VERSION@@ARCHIVE_EXT@

I get the following:

$ uscan --verbose
uscan info: uscan (version 2.22.1) See uscan(1) for help
uscan info: Scan watch files in .
uscan info: Check debian/watch and debian/changelog in .
uscan info: package="u-boot" version="2022.04+dfsg-1~20220404~0" (as seen in 
debian/changelog)
uscan info: package="u-boot" version="2022.04+dfsg" (no epoch/revision)
uscan info: ./debian/changelog sets package="u-boot" version="2022.04+dfsg"
uscan info: Found upstream signing keyring: debian/upstream/signing-key.asc
uscan info: Process watch file at: debian/watch
package = u-boot
version = 2022.04+dfsg
pkg_dir = .
uscan info: opts: 
dversionmangle=auto,pgpmode=auto,repacksuffix=+dfsg,uversionmangle=s/-rc/~rc/
uscan info: line: https://ftp.denx.de/pub/u-boot/ 
u-boot(?:[-_]?(\d[\-+\.:\~\da-zA-Z]*))(?i)(?:\.(?:tar\.xz|tar\.bz2|tar\.gz|tar\.zstd?|zip|tgz|tbz|txz))
uscan info: Parsing dversionmangle=auto
uscan info: Parsing pgpmode=auto
uscan info: Parsing repacksuffix=+dfsg
uscan info: Parsing uversionmangle=s/-rc/~rc/
uscan info: line: https://ftp.denx.de/pub/u-boot/ 
u-boot(?:[-_]?(\d[\-+\.:\~\da-zA-Z]*))(?i)(?:\.(?:tar\.xz|tar\.bz2|tar\.gz|tar\.zstd?|zip|tgz|tbz|txz))
uscan info: Last orig.tar.* tarball version (from debian/changelog): 
2022.04+dfsg
uscan info: Last orig.tar.* tarball version (dversionmangled): 2022.04
uscan info: Requesting URL:
   https://ftp.denx.de/pub/u-boot/
uscan info: Matching pattern:
   
(?:(?:https://ftp.denx.de)?\/pub\/u\-boot\/)?u-boot(?:[-_]?(\d[\-+\.:\~\da-zA-Z]*))(?i)(?:\.(?:tar\.xz|tar\.bz2|tar\.gz|tar\.zstd?|zip|tgz|tbz|txz))
uscan info: Found the following matching hrefs on the web page (newest first):
   https://ftp.denx.de/pub/u-boot/u-boot-2202.04-rc5.tar.bz2 (2202.04~rc5) 
index=2202.04~rc5-2
   https://ftp.denx.de/pub/u-boot/u-boot-2202.04-rc5.tar.bz2 (2202.04~rc5) 
index=2202.04~rc5-2
   https://ftp.denx.de/pub/u-boot/u-boot-2022.04.tar.bz2 (2022.04) 
index=2022.04-2
   https://ftp.denx.de/pub/u-boot/u-boot-2022.04.tar.bz2 (2022.04) 
index=2022.04-2
   https://ftp.denx.de/pub/u-boot/u-boot-2022.04-rc5.tar.bz2 (2022.04~rc5) 
index=2022.04~rc5-2
   https://ftp.denx.de/pub/u-boot/u-boot-2022.04-rc5.tar.bz2 (2022.04~rc5) 
index=2022.04~rc5-2
   https://ftp.denx.de/pub/u-boot/u-boot-2022.04-rc4.tar.bz2 (2022.04~rc4) 
index=2022.04~rc4-2
   https://ftp.denx.de/pub/u-boot/u-boot-2022.04-rc4.tar.bz2 (2022.04~rc4) 
index=2022.04~rc4-2
...
uscan info: Filename (filenamemangled) for downloaded file: 
u-boot-2202.04-rc5.tar.bz2
uscan: Newest version of u-boot on remote site is 2202.04~rc5, local version is 
2022.04
   (mangled local version is 2022.04)
uscan:  => Newer package available from:
=> https://ftp.denx.de/pub/u-boot/u-boot-2202.04-rc5.tar.bz2

I would expect it to download u-boot-2022.04.tar.bz2... or say it's not
downloading it because it's the same version or whatever.

The upstream site seems to confusingly have two u-boot-2022.04-rc5, not
sure if this is somehow triggering the issue...

Or maybe there is something amiss with my watch file that is not obvious
to me.


Thanks for maintaining devscripts/uscan.


live well,
  vagrant


-- Package-specific info:

--- /etc/devscripts.conf ---
Empty.

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

-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (500, 'testing'), (1, 'experimental'), (1, 'unstable')
Architecture: arm64 (aarch64)

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

Versions of packages devscripts depends on:
ii  dpkg-dev  1.21.2
ii  fakeroot  1.28-1
ii  file  1:5.41-2
ii  gnupg 2.2.27-3
ii  gpgv  2.2.27-3+b1
ii  libc6 2.33-7
ii  libfile-dirlist-perl  0.05-2
ii  libfile-homedir-perl  1.006-1
ii  libfile-touch-perl0.12-1
ii  libfile-which-perl1.23-1
ii  libipc-run-perl   20200505.0-1
ii  libmoo-perl   2.005004-3
ii  libwww-perl   6.61-1
ii  patchutils0.4.2-1
ii  perl  5.34.0-3
ii  python3   3.9.8-1
ii  sensible-utils0.0.17
ii  wdiff 1.2.2-2+b1

Versions of packages devscripts recommends:
ii  apt 2.4.4
ii  curl7.82.0-2
ii  dctrl-tools 2.24-3
ii  debian-keyring  2021.12.24
ii  dput 

Bug#1008958: ITP: martchus-qtforkawesome -- lib that enables ForkAwesome use within Qt applications using native methods

[Nicholas D Steeves]

Package: wnpp
Severity: wishlist
Owner: Nicholas D Steeves 
X-Debbugs-Cc: debian-de...@lists.debian.org, Hannah Rittich 
Control: block 884575 by -1

* Package name: martchus-qtforkawesome
  Version : 0.0.3
  Upstream Author : Martchus 
* URL : https://github.com/Martchus/qtforkawesome
* License : GPL-2+
  Programming Lang: C++
  Description : lib that enables ForkAwesome use within Qt applications 
using native methods

Long description is a WIP with likely errors, and I'm consulting upstream for 
clarification.

Qt Fork Awesome is a library that enables ForkAwesome use within Qt
applications using native methods.  Fork Awesome is a pictographic
language of web-related actions; it's an "icon font".  Qt Fork Awesome
provides an icon engine plugin and a QQuickImageProvider for use in
QQmlEngine.

Qt Fork Awesome is a dependency of Syncthing Tray.  It has been
namespaced like Martchus' c++utilities and qtutilities, to keep both
the Debian library and packaging namespaces clear for potential future 
c++utilities and/or qtutilities.

This package will be maintained under Debian Salsa namespace
(previously collab-maint), Hannah Rittich is the primary maintainer,
and I'm a comaintainer and the one who will upload the package.

Regards,
Nicholas

Bug#966178: ITP: rkdeveloptool -- tools for working with Rockchip ARM processors through the rockusb protocol

[Diederik de Haas]

On Fri, 1 Apr 2022 15:05:16 +0100 Christopher Obbard 
 wrote:
> I guess this time it would be best to move it to the debian salsa 
> namespace first - I do not have access there (yet?).

Or some rockchip-team group?

I created https://salsa.debian.org/diederik/rock64 which works enough for me 
to build basic images for my Rock64, but otherwise is of poor quality.
But some tool to make Debian images for Rockchip based devices, may be useful.
Then it's easiest when they're all under the same umbrella (group)

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

Bug#1008957: gnome-weather: can not select location on Mobian posh PinePhone

[Marek Bel]

Package: gnome-weather
Version: 42.0-1
Severity: important

Dear Maintainer,

it is impossible to search for location on Mobian posh PinePhone.
Steps to reproduce:
1. Tap on Search for a city or country
2. Start typing name of the city on on-screen keyboard.
Expected behaviour:
Search bar is updated with text typed.
Actual behaviour:
Search bar disappears once on-screen keyboard is tapped for the first time to
type first letter or shift or basically anything.

Best Regards,
Marek Bel


-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: arm64 (aarch64)

Kernel: Linux 5.15-sunxi64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_CRAP, TAINT_UNSIGNED_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=C.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 gnome-weather depends on:
ii  dconf-gsettings-backend [gsettings-  0.40.0-3
ii  geoclue-2.0  2.5.7+really2.5.7+git20211204-0mobian1
ii  gir1.2-adw-1 1.1.0-1
ii  gir1.2-geoclue-2.0   2.5.7+really2.5.7+git20211204-0mobian1
ii  gir1.2-glib-2.0  1.72.0-1
ii  gir1.2-gtk-4.0   4.6.2+ds-1
ii  gir1.2-gweather-4.0  4.0.0-1
ii  gjs  1.72.0-2
ii  libglib2.0-bin   2.72.0-1+b1

gnome-weather recommends no packages.

gnome-weather suggests no packages.

-- no debconf information

Bug#1008955: Add strace

[Lupe Christoph]

389   22:18:52.615037 execve("/lib/systemd/systemd-networkd-wait-online", 
["/lib/systemd/systemd-networkd-wait-online", "--ignore=tun0", 
"--ignore=dummy1"], 0x7fffbc86c690 /* 5 vars */) = 0
389   22:18:52.616756 brk(NULL) = 0x55e209ce8000
389   22:18:52.616818 access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such 
file or directory)
389   22:18:52.616924 openat(AT_FDCWD, 
"/lib/systemd/tls/haswell/x86_64/libsystemd-shared-247.so", O_RDONLY|O_CLOEXEC) 
= -1 ENOENT (No such file or directory)
389   22:18:52.617325 stat("/lib/systemd/tls/haswell/x86_64", 0x7fff73610790) = 
-1 ENOENT (No such file or directory)
389   22:18:52.617759 openat(AT_FDCWD, 
"/lib/systemd/tls/haswell/libsystemd-shared-247.so", O_RDONLY|O_CLOEXEC) = -1 
ENOENT (No such file or directory)
389   22:18:52.617790 stat("/lib/systemd/tls/haswell", 0x7fff73610790) = -1 
ENOENT (No such file or directory)
389   22:18:52.617814 openat(AT_FDCWD, 
"/lib/systemd/tls/x86_64/libsystemd-shared-247.so", O_RDONLY|O_CLOEXEC) = -1 
ENOENT (No such file or directory)
389   22:18:52.617839 stat("/lib/systemd/tls/x86_64", 0x7fff73610790) = -1 
ENOENT (No such file or directory)
389   22:18:52.617861 openat(AT_FDCWD, 
"/lib/systemd/tls/libsystemd-shared-247.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT 
(No such file or directory)
389   22:18:52.617885 stat("/lib/systemd/tls", 0x7fff73610790) = -1 ENOENT (No 
such file or directory)
389   22:18:52.617908 openat(AT_FDCWD, 
"/lib/systemd/haswell/x86_64/libsystemd-shared-247.so", O_RDONLY|O_CLOEXEC) = 
-1 ENOENT (No such file or directory)
389   22:18:52.617932 stat("/lib/systemd/haswell/x86_64", 0x7fff73610790) = -1 
ENOENT (No such file or directory)
389   22:18:52.617955 openat(AT_FDCWD, 
"/lib/systemd/haswell/libsystemd-shared-247.so", O_RDONLY|O_CLOEXEC) = -1 
ENOENT (No such file or directory)
389   22:18:52.617979 stat("/lib/systemd/haswell", 0x7fff73610790) = -1 ENOENT 
(No such file or directory)
389   22:18:52.618001 openat(AT_FDCWD, 
"/lib/systemd/x86_64/libsystemd-shared-247.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT 
(No such file or directory)
389   22:18:52.618025 stat("/lib/systemd/x86_64", 0x7fff73610790) = -1 ENOENT 
(No such file or directory)
389   22:18:52.618048 openat(AT_FDCWD, "/lib/systemd/libsystemd-shared-247.so", 
O_RDONLY|O_CLOEXEC) = 3
389   22:18:52.618079 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0 
\n\6\0\0\0\0\0@\0\0\0\0\0\0\0\340\35)\0\0\0\0\0\0\0\0\0@\08\0\n\0@\0\37\0\36\0\1\0\0\0\4\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0@f\5\0\0\0\0\0@f\5\0\0\0\0\0\0\20\0\0\0\0\0\0\1\0\0\0\5\0\0\0\0p\5\0\0\0\0\0\0p\5\0\0\0\0\0\0p\5\0\0\0\0\0\231\316\30\0\0\0\0\0\231\316\30\0\0\0\0\0\0\20\0\0\0\0\0\0\1\0\0\0\4\0\0\0\0@\36\0\0\0\0\0\0@\36\0\0\0\0\0\0@\36\0\0\0\0\0\230\217\t\0\0\0\0\0\230\217\t\0\0\0\0\0\0\20\0\0\0\0\0\0\1\0\0\0\6\0\0\0\270\320'\0\0\0\0\0\270\340'\0\0\0\0\0\270\340'\0\0\0\0\0xK\1\0\0\0\0\0\230Y\1\0\0\0\0\0\0\20\0\0\0\0\0\0\2\0\0\0\6\0\0\0\340\274(\0\0\0\0\0\340\314(\0\0\0\0\0\340\314(\0\0\0\0\\3\0\0\0\0\0\\3\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0p\2\0\0\0\0\0\0p\2\0\0\0\0\0\0p\2\0\0\0\0\0\0$\0\0\0\0\0\0\0$\0\0\0\0\0\0\0\4\0\0\0\0\0\0\0\7\0\0\0\4\0\0\0\270\320'\0\0\0\0\0\270\340'\0\0\0\0\0\270\340'\0\0\0\0\08\0\0\0\0\0\0\0\310\0\0\0\0\0\0\0\10\0\0\0\0\0\0\0P\345td\4\0\0\0\10\256#\0\0\0\0\0\10\256#\0\0\0\0\0\10\256#\0\0\0\0\0\214\205\0\0\0\0\0\0\214\205\0\0\0\0\0\0\4\0\0\0\0\0\0\0"...,
 832) = 832
389   22:18:52.618127 fstat(3, {st_mode=S_IFREG|0644, st_size=2696608, ...}) = 0
389   22:18:52.618152 mmap(NULL, 8192, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fee1403a000
389   22:18:52.618182 mmap(NULL, 2701904, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 
3, 0) = 0x7fee13da6000
389   22:18:52.618207 mprotect(0x7fee13dfd000, 2256896, PROT_NONE) = 0
389   22:18:52.618232 mmap(0x7fee13dfd000, 1626112, PROT_READ|PROT_EXEC, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x57000) = 0x7fee13dfd000
389   22:18:52.618259 mmap(0x7fee13f8a000, 626688, PROT_READ, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1e4000) = 0x7fee13f8a000
389   22:18:52.618301 mmap(0x7fee14024000, 86016, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x27d000) = 0x7fee14024000
389   22:18:52.618359 mmap(0x7fee14039000, 2640, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7fee14039000
389   22:18:52.618396 close(3)  = 0
389   22:18:52.618430 openat(AT_FDCWD, "/lib/systemd/libc.so.6", 
O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
389   22:18:52.618463 openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) 
= 3
389   22:18:52.618509 fstat(3, {st_mode=S_IFREG|0644, st_size=60875, ...}) = 0
389   22:18:52.618535 mmap(NULL, 60875, PROT_READ, MAP_PRIVATE, 3, 0) = 
0x7fee13d97000
389   22:18:52.618848 close(3)  = 0
389   22:18:52.618882 openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libc.so.6", 
O_RDONLY|O_CLOEXEC) = 3
389   22:18:52.618914 read(3, 

Bug#1008956: tex-common: Something in package "tex-common" causes dpkg to exit with exit code -1

[Ashleigh Moore]

Package: tex-common
Version: 6.16
Severity: grave
Justification: renders package unusable

Dear Maintainer,

(This is my first foray into bug reporting on a Linux distro, so if I make any 
mistakes, let me know!)

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

Preface regarding my system:
-
My system is a Lenovo ThinkPad W530, Type 2447; but with 32 GB RAM. This is why 
I have set APT to hold any packages matching the following critieria:
1) "*nvidia*"
2) "*cuda*"
I have the "nvidia-tesla-418-driver" package(s) installed, and I don't want 
anything else breaking it, so I have this held. I'm unsure if this is a cause 
of the error or not.
=


Prompt #1: What led up to the situation?
-
I went to install Blender and all the suggested / recommended packages so I 
could have the maximum funcionality out of the program. I used "apt install 
blender --install-suggests --install-recommends" (That last switch may be 
incorrect, if so, substibute the correct one there, I can't recall right now.)
=

Prompt #2 / #3: What exactly did you do (or not do) that was effective (or 
ineffective) / What was the outcome of this action?
---
I noticed the error that dpkg reported: exit code -1, and the package 
"tex-common". I saw that it made a error report with the name "fmtutil.", but I thought that perhaps it was a fluke brought on by the mammoth 
number of packages I had it installing.

I ran "dpkg --configure tex-common" to see, and the same error happened. I 
looked in the error file it generated, and it was really long, and quite 
frankly, I couldn't follow it. 
(I don't think it'll let me attach it to this report; this is the second time 
I've typed this due to a ironic error in reportbug: it failed to write the 
header in the bug report, and the file failed to attach there.)

Oddly, neither APT or dpkg report any broken deps with this erroring package; 
they just try to reconfigure it every time any action is performed with them, 
and Blender seems to be working fine? However, I doubt it's all functioning, 
since parts of the package are not configured.
===

Prompt #4: What outcome did you expect instead?

The package to not be stuck in a limbo of installed but not configured.


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

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

Versions of packages tex-common depends on:
ii  dpkg  1.20.9
ii  ucf   3.0043

tex-common recommends no packages.

Versions of packages tex-common suggests:
pn  debhelper  

Versions of packages texlive-base depends on:
ii  debconf [debconf-2.0]  1.5.77
ii  libpaper-utils 1.1.28+b1
ii  sensible-utils 0.0.14
ii  texlive-binaries   2020.20200327.54578-7
ii  ucf3.0043
ii  xdg-utils  1.1.3-4.1

Versions of packages texlive-base recommends:
ii  lmodern  2.004.5-6.1

Versions of packages texlive-base suggests:
ii  ghostscript [postscript-viewer]  9.53.3~dfsg-7+deb11u2
ii  okular [postscript-viewer]   4:20.12.3-2
pn  perl-tk  
pn  xpdf | pdf-viewer
pn  xzdec

Versions of packages texlive-binaries depends on:
ii  dpkg1.20.9
ii  install-info6.7.0.dfsg.2-6
ii  libc6   2.31-13+deb11u3
ii  libcairo2   1.16.0-5
ii  libfontconfig1  2.13.1-4.2
ii  libfreetype62.10.4+dfsg-1
ii  libgcc-s1   10.2.1-6
ii  libgraphite2-3  1.3.14-1
ii  libharfbuzz0b   2.7.4-1
ii  libicu6767.1-7
ii  libkpathsea62020.20200327.54578-7
ii  libmpfr64.1.0-3
ii  libpaper1   1.1.28+b1
ii  libpixman-1-0   0.40.0-1
ii  libpng16-16 1.6.37-3
ii  libptexenc1 2020.20200327.54578-7
ii  libstdc++6  10.2.1-6
ii  libsynctex2 2020.20200327.54578-7
ii  libteckit0  

Bug#949843: sbuild: add systemd-nspawn chroot mode

[Daniel Schepler]

On Mon, Apr 4, 2022 at 3:03 PM Luca Boccassi  wrote:
>
> On Sat, 25 Jan 2020 11:36:09 -0800 Daniel Schepler
>  wrote:
> > Package: sbuild
> > Version: 0.78.1-2
> > Severity: wishlist
> >
> > Here's my initial version of the cleaned up patch for adding a
> > --chroot-mode=systemd-nspawn.  Some things I'm not sure about:
> > - Should we maybe ping upstream and/or Debian maintainers on
> > https://github.com/systemd/systemd/issues/13297 to see how hard it
> > would be to get it fixed so I could remove that whole ugly
> workaround?
> >  (The workaround also only handles bind mount settings at present -
> > and for example, I've found that a lot of package builds will require
> > SystemCallFilter=@memlock due to a lot of crypto libraries and
> > utilities giving errors if they're denied access to mlock.  So I
> would
> > probably want to add that to my
> > /etc/systemd/nspawn/unstable-amd64-sbuild.nspawn config file.)
>
> As mentioned on https://github.com/systemd/systemd/issues/13297 adding
> --ephemeral means the machine name has a randomized suffix. Passing --
> machine=$chroot should ensure the config files are picked up as
> expected.

OK, if I did that, then would that mean that it's no longer possible
to have two sbuild processes using the same base chroot at the same
time?  (Not that that would be too much of an issue in practice.
Though I do admit it's convenient to be able to have my micro_buildd
script running one sbuild instance, while on another terminal I can
run a manual build with e.g. DEB_BUILD_OPTIONS=nocheck sbuild ...
--profiles=nocheck tobootstrap_1.0 .)

> > - It currently requires giving sudo access for systemd-run, which
> > essentially would open up execution of anything desired.  And the
> fact
> > that it requires NOPASSWD (because some of the commands redirect
> > stdin/stdout) makes things even worse.  And even if you restrict it
> to
> > e.g. "systemd-run -M unstable-amd64-sbuild*" it still seems it would
> > be possible to fool that with something like "sudo systemd-run -M
> > unstable-amd64-sbuild -M .host ~/myevilcmd".
>
> This seems to be used to implement manual synchronization, but this is
> not necessary as it's already implemented, see:
>
> https://www.freedesktop.org/software/systemd/man/systemd-nspawn.html#--notify-ready=

That's just one use of systemd-run, and a minor one at that.  The main
use is to run the commands that sbuild needs to invoke, from "apt-get
update", "apt-get dist-upgrade", "apt-get source package=ver",
"dpkg-source -x filename.dsc", "dpkg-buildpackage" (with
--property=PrivateNetwork=yes on this one), "cat *.changes" into a
pipe, etc.

And as for synchronization, I think I do remember seeing the
--notify-ready option.  But the man page said the notification would
be going to systemd, and I didn't immediately see any way for the
sbuild parent process to get that notification or to wait for it.
-- 
Daniel Schepler

Bug#949843: sbuild: add systemd-nspawn chroot mode

[Luca Boccassi]

On Sat, 25 Jan 2020 11:36:09 -0800 Daniel Schepler
 wrote:
> Package: sbuild
> Version: 0.78.1-2
> Severity: wishlist
> 
> Here's my initial version of the cleaned up patch for adding a
> --chroot-mode=systemd-nspawn.  Some things I'm not sure about:
> - Should we maybe ping upstream and/or Debian maintainers on
> https://github.com/systemd/systemd/issues/13297 to see how hard it
> would be to get it fixed so I could remove that whole ugly
workaround?
>  (The workaround also only handles bind mount settings at present -
> and for example, I've found that a lot of package builds will require
> SystemCallFilter=@memlock due to a lot of crypto libraries and
> utilities giving errors if they're denied access to mlock.  So I
would
> probably want to add that to my
> /etc/systemd/nspawn/unstable-amd64-sbuild.nspawn config file.)

As mentioned on https://github.com/systemd/systemd/issues/13297 adding
--ephemeral means the machine name has a randomized suffix. Passing --
machine=$chroot should ensure the config files are picked up as
expected.

> - It currently requires giving sudo access for systemd-run, which
> essentially would open up execution of anything desired.  And the
fact
> that it requires NOPASSWD (because some of the commands redirect
> stdin/stdout) makes things even worse.  And even if you restrict it
to
> e.g. "systemd-run -M unstable-amd64-sbuild*" it still seems it would
> be possible to fool that with something like "sudo systemd-run -M
> unstable-amd64-sbuild -M .host ~/myevilcmd".

This seems to be used to implement manual synchronization, but this is
not necessary as it's already implemented, see:

https://www.freedesktop.org/software/systemd/man/systemd-nspawn.html#--notify-ready=

-- 
Kind regards,
Luca Boccassi


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

Bug#1008954: [pkg-uWSGI-devel] Bug#1008954: uwsgi-plugin-python3: uWSGI uses Python 3.10 which is not yet the default

[Jonas Smedegaard]

Hi Adrien,

Quoting Adrien CLERC (2022-04-04 22:52:59)
> uwsgi was rebuilt with python 3.10 as default, but it is not yet the 
> Debian default version. I have some applications that use a virtualenv 
> with python 3.9, and uwsgi fails to load those applications since the 
> python version is not the same.
> Is it possible to wait for python 3.10 to be the default before 
> hitting testing?

Sorry, I am not sure I understand you.

I did a simple rebuild, so if that caused the package to treat Python 
3.10 as the default then that is because it is the default (at the 
Debian unstable environment where it was built).

If you mean to say that Python 3.10 is not yet the default in testing, 
then that seems like a chicken-and-egg scenario: For Python 3.10 to 
become the default in Debian testing, packages rebuild while Python 3.10 
was the default need to migrate to testing.

If your system is not yet ready for Python 3.10, then I suggest you hold 
back packages as appropriate.

If I somehow missed your point, then please try again, and sorry for not 
understanding you properly.


Kind regards,

 - Jonas

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

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

signature.asc
Description: signature

Bug#1007906: transition: mutter

[Sebastian Ramacher]

On 2022-04-04 12:28:13 +0100, Simon McVittie wrote:
> On Mon, 04 Apr 2022 at 12:19:31 +0100, Simon McVittie wrote:
> > On Mon, 04 Apr 2022 at 12:59:33 +0200, Sebastian Ramacher wrote:
> > > Will this issue also affect bullseye to bookworm upgrades?
> > 
> > At the moment, yes, it could affect partial upgrades.
> 
> Actually, I think it will not be able to happen once GNOME Shell 42 is
> in bookworm, because gir1.2-gweather-4.0 Depends on a version of
> libgweather-4-0 that already Breaks bullseye's gnome-shell.

Okay, that sounds good. I've added the hints. mutter and co should
migrate in the next run.

Cheers

> 
> > I was going to give
> > gir1.2-gweather-4.0 a Breaks: gnome-shell (<< 42)
> 
> I'll do that anyway (unless asked not to), because explicit is better
> than implicit.
> 
> smcv

-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#951128: emacs: Please build Emacs with modules support

[Martin]

Emacs is now build with module support (I did not check when the change
happened) and vterm works fine with Debian testing and unstable.
See also https://bugs.debian.org/1005080
IMHO, this bug can be closed.

Bug#827566: qpdfview: search option 'whole words' doesn't work

[Louis-Philippe Véronneau]

Now that I've cleaned and read the Debian patches, I tested this issue
again on my laptop to be sure it was still present before reporting it
upstream.

It seems I cannot reproduce it? My previous email said otherwise, but I
tested this on my desktop (which FWIW, runs pretty much the exact same
configuration as my laptop).

Maybe something changed in unstable since then, although I get the same
the Help/About report:

PDF support using Poppler 20.09.0
PS support using libspectre 0.2.9
DjVu support using DjVuLibre 3.5.28
PDF support using Fitz
Printing support using CUPS 2.3.3op2

I'll try to see if things work properly on my desktop too. If that's the
case, I'll consider closing this issue and marking it as fixed.

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

On Mon, 17 Jan 2022 15:09:43 -0500
=?UTF-8?Q?Louis-Philippe_V=c3=a9ronneau?=  wrote:
> found 827566 0.4.18-6
> thanks
> 
> I can reproduce this issue on the current Debian Sid, using an obviously
> more recent version of Poppler:
> 
> PDF support using Poppler 20.09.0
> PS support using libspectre 0.2.9
> DjVu support using DjVuLibre 3.5.28
> PDF support using Fitz
> Printing support using CUPS 2.3.3op2
> 
> There's currently no upstream bug about this.
> 
> I'm still looking at the Debian patches / how we build this package, but
> if I don't find anything, I'll forward this and try to get help :)
> 
> -- 
>   ⢀⣴⠾⠻⢶⣦⠀
>   ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
>   ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
>   ⠈⠳⣄

Bug#1008752: avifile: autopkgtest regression on armhf: Bus error

[Ying-Chun Liu (PaulLiu)]

Hi Paul,

Thanks for the report. Now I know why abel.debian.org or 
qemu-user-static doesn't reproduce the bug.
It is because your environment supports "neon" and ffmpeg will use that 
for acceleration.

But abel and qemu-user-static doesn't support neon.
I think if you "cat /proc/cpuinfo" and neon will be in the Features.

I'll see if I can use cpuflags in ffmpeg to disable neon on my test. So 
that it can pass.


Yours,
Paul

Paul Gevers 於 2022/4/5 03:16 寫道:

Hi

Bus error
autopkgtest [19:03:51]: test decoding-test-mp4-raw: 
---]
autopkgtest [19:03:51]: test decoding-test-mp4-raw:  - - - - - - - - - 
- results - - - - - - - - - -

decoding-test-mp4-raw FAIL non-zero exit status 135
autopkgtest [19:03:51]:  - - - - - - - - - - running shell - - - - - - 
- - - -
root@elbrus:/tmp/autopkgtest-lxc.ze1_2t2a/downtmp/build.e5m/src# cd 
debian/tests/decoding-test-data/
root@elbrus:/tmp/autopkgtest-lxc.ze1_2t2a/downtmp/build.e5m/src/debian/tests/decoding-test-data# 
./gentestavi.sh

Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
Redistribute latency...
Pipeline is PREROLLED ...
Setting pipeline to PLAYING ...
Redistribute latency...
New clock: GstSystemClock
Got EOS from element "pipeline0".
Execution ended after 0:00:00.215248380
Setting pipeline to NULL ...
Freeing pipeline ...
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
Pipeline is PREROLLED ...
Setting pipeline to PLAYING ...
Redistribute latency...
New clock: GstSystemClock
Got EOS from element "pipeline0".
Execution ended after 0:00:00.219812907
Setting pipeline to NULL ...
Freeing pipeline ...
root@elbrus:/tmp/autopkgtest-lxc.ze1_2t2a/downtmp/build.e5m/src/debian/tests/decoding-test-data# 

root@elbrus:/tmp/autopkgtest-lxc.ze1_2t2a/downtmp/build.e5m/src/debian/tests/decoding-test-data# 

root@elbrus:/tmp/autopkgtest-lxc.ze1_2t2a/downtmp/build.e5m/src/debian/tests/decoding-test-data# 
make

g++ -Wall -g -o test1 test1.cc \
    -laviplay -I/usr/include/avifile-0.7 \
    -laubio  \
    -lm
root@elbrus:/tmp/autopkgtest-lxc.ze1_2t2a/downtmp/build.e5m/src/debianroot@elbrus:/tmp/autopkgtest-lxc.ze1_2t2a/downtmp/build.e5m/src/debian/tests/decoding-test-data# 
apt install gdb libavcodec58-dbgsym


< installing gdb and libavcodec58-dbgsym >

root@elbrus:/tmp/autopkgtest-lxc.ze1_2t2a/downtmp/build.e5m/src/debian/tests/decoding-test-data# 
gdb ./test1

gdb: warning: Couldn't determine a path for the index cache directory.
GNU gdb (Debian 10.1-2+b1) 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 "arm-linux-gnueabihf".
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 ./test1...
(gdb) set args test_raw.avi
(gdb) run
Starting program: 
/tmp/autopkgtest-lxc.ze1_2t2a/downtmp/build.e5m/src/debian/tests/decoding-test-data/test1 
test_raw.avi

[Thread debugging using libthread_db enabled]
Using host libthread_db library 
"/lib/arm-linux-gnueabihf/libthread_db.so.1".

 : Avifile RELEASE-0.7.48-220318-20:07-../src/configure
 : Available CPU flags: fp asimd evtstrm aes pmull sha1 sha2 
crc32 atomics fphp asimdhp cpuid asimdrdm lrcpc dcpop asimddp ssbs

This binary was compiled for Avifile ver. 1840, the library is ver. 1840
 : Checking: test_raw.avi
 : MainHeader: MicroSecPerFrame=4 MaxBytesPerSec=6112800
 PaddingGranularity=0 Flags=[ HAS_INDEX IS_INTERLEAVED ] TotalFrames=250
 InitialFrames=0 Streams=2 SuggestedBufferSize=0 WxH=320x240
 Scale=0 Rate=0 Start=0 Length=0
 : StreamHeader: Type=vids Handler=DIVX Flags=[ ]
 InitialFrames=0 Scale=1 Rate=25 Start=0 Length=250
 SuggestedBufferSize=12413 Quality=0 SampleSize=0 Rect l,r,t,b=0,0,0,0
 : StreamHeader: Type=auds Handler=0x1 Flags=[ ]
 InitialFrames=0 Scale=1 Rate=44100 Start=0 Length=450559
 SuggestedBufferSize=8192 Quality=0 SampleSize=8 Rect l,r,t,b=0,0,0,0
 : Reading index from offset: 5581514
 : Stream 0 vids : DIVX (0x4944) 250 chunks (0.98KB)
 : WARNING: stream header has incorrect dwLength (450559 
-> 450560)

 : Stream 1 auds : Microsoft PCM (0x1) 440 chunks (3.44KB)
[New Thread 0xefdfea20 (LWP 6059)]
 : Initialized video stream (chunk tblsz: 250, fmtsz: 40)
 : Found 7 plugins 
(/usr/lib/arm-linux-gnueabihf/avifile-0.7,A:28,V:36)

 : looking for mpeg4  1482049860
 : Created video decoder: FF OpenDivX
 : Initialized audio stream (chunk tblsz: 450560, fmtsz: 18)
 : PCM audio decoder created
bh.biHeight = -240, bh.biWidth = 320
bh.biHeight < 0, 

Bug#1008951: openldap FTBFS on musl-linux-any: conflicting declaration of calloc

[Helmut Grohne]

Control: tags -1 + patch

On Mon, Apr 04, 2022 at 09:54:13PM +0200, Helmut Grohne wrote:
> The gentoo bug has a few more details and proposed two distinct
> workarounds:
>  a. Drop the _GNU_SOURCE define. Doing so makes musl's sched.h not emit
> a calloc declaration. I don't know what other consequences this
> would have.
>  b. Change LBER_LEN_T to size_t. I suppose doing so would break ABI on
> 64bit architectures.

Proposing a third one that practically works and has little risk of
breakage:

 c. Reorder the #define calloc vs #include 

This doesn't fix the root cause, but the symptom. :)

Helmut
--- a/libraries/librewrite/rewrite-int.h
+++ b/libraries/librewrite/rewrite-int.h
@@ -40,6 +40,11 @@

 #include 

+#ifndef NO_THREADS
+#define USE_REWRITE_LDAP_PVT_THREADS
+#include 
+#endif
+
 #define malloc(x)	ber_memalloc(x)
 #define calloc(x,y)	ber_memcalloc(x,y)
 #define realloc(x,y)	ber_memrealloc(x,y)
@@ -47,11 +52,6 @@
 #undef strdup
 #define	strdup(x)	ber_strdup(x)

-#ifndef NO_THREADS
-#define USE_REWRITE_LDAP_PVT_THREADS
-#include 
-#endif
-
 /*
  * For details, see RATIONALE.
  */

Bug#1008953: libarchive: CVE-2022-26280

[Salvatore Bonaccorso]

Source: libarchive
Version: 3.6.0-1
Severity: important
Tags: security upstream
Forwarded: https://github.com/libarchive/libarchive/issues/1672
X-Debbugs-Cc: car...@debian.org, Debian Security Team 
Control: found -1 3.4.3-2+deb11u1
Control: found -1 3.4.0-1

Hi,

The following vulnerability was published for libarchive.

CVE-2022-26280[0]:
| Libarchive v3.6.0 was discovered to contain an out-of-bounds read via
| the component zipx_lzma_alone_init.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2022-26280
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-26280
[1] https://github.com/libarchive/libarchive/issues/1672
[2] 
https://github.com/libarchive/libarchive/commit/cfaa28168a07ea4a53276b63068f94fce37d6aff

Regards,
Salvatore

Bug#1008952: grep FTBFS on musl: requires regex library

[Helmut Grohne]

Source: grep
Version: 3.7-1
Tags: ftbfs patch
User: helm...@debian.org
Usertags: rebootstrap

grep fails to build from source on musl-linux-any, because it assumes a
regex library, but musl doesn't provide it. Indeed, grep has its own
regex library and the packaging unconditionally disables that during
build. We should enable it for musl. Please consider applying the
attached patch.

Helmut
--- a/debian/rules
+++ b/debian/rules
@@ -26,10 +26,12 @@
 DEB_CONFIGURE_SCRIPT_ENV += CPPFLAGS="$(CPPFLAGS)"
 ##

+include /usr/share/dpkg/architecture.mk
+
 DEB_UPSTREAM_URL = http://ftp.gnu.org/gnu/grep/
 DEB_UPSTREAM_TARBALL_EXTENSION = tar.xz

-DEB_CONFIGURE_EXTRA_FLAGS += --without-included-regex
+DEB_CONFIGURE_EXTRA_FLAGS += --with$(if $(filter $(DEB_HOST_ARCH_LIBC),musl),,out)-included-regex
 DEB_CONFIGURE_SCRIPT_ENV += LIBS="$(LIBS)"

 # FIXME: CDBS should include a specific var for this

Bug#1008951: openldap FTBFS on musl-linux-any: conflicting declaration of calloc

[Helmut Grohne]

Source: openldap,musl
Tags: upstream
User: helm...@debian.org
Usertags: rebootstrap

Hi,

openldap fails to build from source on musl-linux-any. The issue is not
Debian-specific and has been reported for gentoo already
(https://bugs.gentoo.org/546556). The visible issue is this:

|   In file included from ../../../../libraries/librewrite/context.c:22:
|   ../../../../libraries/librewrite/rewrite-int.h:44:25: error: conflicting 
types for ‘ber_memcalloc’; have ‘void *(size_t,  size_t)’ {aka ‘void *(unsigned 
int,  unsigned int)’}
|  44 | #define calloc(x,y) ber_memcalloc(x,y)
| | ^
|   In file included from ../../../../libraries/librewrite/rewrite-int.h:34:
|   ../../../../include/lber.h:608:1: note: previous declaration of 
‘ber_memcalloc’ with type ‘void *(ber_len_t,  ber_len_t)’ {aka ‘void *(long 
unsigned int,  long unsigned int)’}
| 608 | ber_memcalloc LDAP_P((
| | ^

The gentoo bug explains this quite well. LBER_LEN_T is statically
defined as "long" in configure.ac. Then include/lber_types.h uses that:

| typedef unsigned LBER_LEN_T ber_len_t;

And then, it declares ber_memcalloc using ber_len_t in include/lber.h.
Finally, it #defines calloc (as be seen above) to point to
ber_memcalloc. That #define lives in libraries/librewrite/rewrite-int.h,
which happens to be #included before some musl header that happens to
pull the definition of calloc. Thus musl's declaration is renamed to
ber_memcalloc and since it uses size_t, which happens to be defined as
unsigned int rather than unsigned long, we get a conflicting
declaration.

Looking deeper things get a little surprising. rewrite-int.h is careful
to #include  early. Presumably, it wants to avoid such
conflicting declarations. Indeed, that's not the place the conflicting
ber_memcalloc declaration originates. After the #define calloc, there is
an #include , which happens to indirectly #include
, which happens to #include , which happens to
declare calloc, which was defined as ber_memcalloc earlier.

This is sounds doubly wrong. Why would openldap re#define calloc and
then #include system headers? That's risky and it makes the build fail.
Why would musl declare calloc in a header different from stdlib.h? I
understand neither and fixing either fixes the build.

The gentoo bug has a few more details and proposed two distinct
workarounds:
 a. Drop the _GNU_SOURCE define. Doing so makes musl's sched.h not emit
a calloc declaration. I don't know what other consequences this
would have.
 b. Change LBER_LEN_T to size_t. I suppose doing so would break ABI on
64bit architectures.

Any clue how we can move forward here?

Helmut

Bug#1008950: O: libevent -- Asynchronous event notification library

[Bálint Réczey]

Package: wnpp
Severity: normal

Orphaning the package.

Thanks,
Balint

Bug#1008949: r-cran-bbmle: autopkgtest needs update for new version of rmatrix: warning shows up in compared data

[Paul Gevers]

Source: r-cran-bbmle
Version: 1.0.24-3
Severity: serious
X-Debbugs-CC: rmat...@packages.debian.org
Tags: sid bookworm
User: debian...@lists.debian.org
Usertags: needs-update
Control: affects -1 src:rmatrix

Dear maintainer(s),

With a recent upload of rmatrix the autopkgtest of r-cran-bbmle fails in 
testing when that autopkgtest is run with the binary packages of rmatrix 
from unstable. It passes when run with only packages from testing. In 
tabular form:


   passfail
rmatrixfrom testing1.4-1-1
r-cran-bbmle   from testing1.0.24-3
versioned deps [0] from testingfrom unstable
all others from testingfrom testing

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

Currently this regression is blocking the migration of rmatrix to 
testing [1]. Of course, rmatrix shouldn't just break your autopkgtest 
(or even worse, your package), but it seems to me that the change in 
rmatrix was intended and your package needs to update to the new situation.


If this is a real problem in your package (and not only in your 
autopkgtest), the right binary package(s) from rmatrix should really add 
a versioned Breaks on the unfixed version of (one of your) package(s). 
Note: the Breaks is nice even if the issue is only in the autopkgtest as 
it helps the migration software to figure out the right versions to 
combine in the tests.


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

Paul

[0] You can see what packages were added from the second line of the log 
file quoted below. The migration software adds source package from 
unstable to the list if they are needed to install packages from 
rmatrix/1.4-1-1. I.e. due to versioned dependencies or breaks/conflicts.

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

https://ci.debian.net/data/autopkgtest/testing/arm64/r/r-cran-bbmle/20598754/log.gz

dpkg-architecture: warning: cannot determine CC system type, falling 
back to default (native compilation)

Test BIC passed
Test ICtab passed
Test binomtest1 passed
Test controleval passed
Test eval passed
Test formulatest passed
Test glmcomp passed
Test gradient_vecpar_profile passed
Test grtest1 passed
Test methods passed
Test mortanal passed
Test optimizers passed
Test order passed
Test parscale passed
Test predict passed
Test profbound passed
--- richards.Rout.save_ 2022-04-04 13:11:18.696832363 +
+++ richards.Rout_  2022-04-04 13:11:18.700832391 +
@@ -125,7 +125,4 @@
 > par(mfrow=c(1,2))
 > plot(pp1,show.points=TRUE)
 > plot(pp0,show.points=TRUE)
-Warning message:
-In .local(x, ...) :
-  non-monotonic profile: reverting to linear interpolation.  Consider 
setting std.err manually

 > autopkgtest [21:11:19]: test run-unit-test



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1008948: mitmproxy: CVE-2022-24766

[Salvatore Bonaccorso]

Source: mitmproxy
Version: 6.0.2-1
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for mitmproxy.

CVE-2022-24766[0]:
| mitmproxy is an interactive, SSL/TLS-capable intercepting proxy. In
| mitmproxy 7.0.4 and below, a malicious client or server is able to
| perform HTTP request smuggling attacks through mitmproxy. This means
| that a malicious client/server could smuggle a request/response
| through mitmproxy as part of another request/response's HTTP message
| body. While mitmproxy would only see one request, the target server
| would see multiple requests. A smuggled request is still captured as
| part of another request's body, but it does not appear in the request
| list and does not go through the usual mitmproxy event hooks, where
| users may have implemented custom access control checks or input
| sanitization. Unless mitmproxy is used to protect an HTTP/1 service,
| no action is required. The vulnerability has been fixed in mitmproxy
| 8.0.0 and above. There are currently no known workarounds.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2022-24766
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-24766
[1] 
https://github.com/mitmproxy/mitmproxy/security/advisories/GHSA-gcx2-gvj7-pxv3
[2] 
https://github.com/mitmproxy/mitmproxy/commit/b06fb6d157087d526bd02e7aadbe37c56865c71b

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1008947: pyresample breaks pytroll-schedule autopkgtest: TestSphericalPolygon.test_bool

[Paul Gevers]

Source: pyresample, pytroll-schedule
Control: found -1 pyresample/1.23.0-1
Control: found -1 pytroll-schedule/0.6.0-1
Severity: serious
Tags: sid bookworm
User: debian...@lists.debian.org
Usertags: breaks needs-update

Dear maintainer(s),

With a recent upload of pyresample the autopkgtest of pytroll-schedule 
fails in testing when that autopkgtest is run with the binary packages 
of pyresample from unstable. It passes when run with only packages from 
testing. In tabular form:


   passfail
pyresample from testing1.23.0-1
pytroll-schedule   from testing0.6.0-1
all others from testingfrom testing

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

Currently this regression is blocking the migration of pyresample 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?


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

Paul

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

https://ci.debian.net/data/autopkgtest/testing/amd64/p/pytroll-schedule/20586576/log.gz

=== python3.10 ===
= test session starts 
==

platform linux -- Python 3.10.4, pytest-6.2.5, py-1.10.0, pluggy-1.0.0
rootdir: /tmp/autopkgtest-lxc.k1ektsm2/downtmp/autopkgtest_tmp
collected 39 items

tests/test_satpass.py .. 
 [ 15%]
tests/test_schedule.py .. 
 [ 41%]
tests/test_spherical.py .F. 
 [100%]


=== FAILURES 
===
 TestSphericalPolygon.test_bool 



self = testMethod=test_bool>


def test_bool(self):
"""Test the intersection and union functions.
"""
vertices = np.array([[180, 90, 0, -90],
 [89, 89, 89, 89]]).T
poly1 = SphPolygon(np.deg2rad(vertices))
vertices = np.array([[-45, -135, 135, 45],
 [89, 89, 89, 89]]).T
poly2 = SphPolygon(np.deg2rad(vertices))
uni = np.array([[157.5,   89.23460094],
[-225.,   89.],
[112.5,   89.23460094],
[90.,   89.],
[67.5,   89.23460094],
[45.,   89.],
[22.5,   89.23460094],
[0.,   89.],
[-22.5,   89.23460094],
[-45.,   89.],
[-67.5,   89.23460094],
[-90.,   89.],
[-112.5,   89.23460094],
[-135.,   89.],
[-157.5,   89.23460094],
[-180.,   89.]])
inter = np.array([[157.5,   89.23460094],
  [112.5,   89.23460094],
  [67.5,   89.23460094],
  [22.5,   89.23460094],
  [-22.5,   89.23460094],
  [-67.5,   89.23460094],
  [-112.5,   89.23460094],
  [-157.5,   89.23460094]])
poly_inter = poly1.intersection(poly2)
poly_union = poly1.union(poly2)
self.assertTrue(poly_inter.area() <= poly_union.area())
self.assertTrue(np.allclose(poly_inter.vertices,
np.deg2rad(inter)))

  self.assertTrue(np.allclose(poly_union.vertices,

np.deg2rad(uni)))
E   AssertionError: False is not true

/usr/lib/python3/dist-packages/trollsched/tests/test_spherical.py:492: 
AssertionError


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1008946: RFS: golang-github-drone-envsubst/1.0.3-1 [ITP] -- Go library for performing Bash-style parameter expansion

[Sebastian Crane]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "golang-github-drone-envsubst":

 * Package name: golang-github-drone-envsubst
   Version : 1.0.3-1
   Upstream Author : Brad Rydzewski 
 * URL : https://github.com/drone/envsubst
 * License : Expat, BSD-3-Clause
 * Vcs : 
https://salsa.debian.org/go-team/packages/golang-github-drone-envsubst
   Section : golang

The source builds the following binary packages:

  golang-github-drone-envsubst - Go library for performing Bash-style parameter 
expansion

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

  https://mentors.debian.net/package/golang-github-drone-envsubst/

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

  dget -x 
https://mentors.debian.net/debian/pool/main/g/golang-github-drone-envsubst/golang-github-drone-envsubst_1.0.3-1.dsc

Changes for the initial release:

 golang-github-drone-envsubst (1.0.3-1) unstable; urgency=medium
 .
   * Initial release (Closes: 1008936)

Looking forward to hearing any feedback you might have on this package!

Best wishes,

Sebastian

Bug#1008945: salt: CVE-2022-22934 CVE-2022-22935 CVE-2022-22936 CVE-2022-22941

[Salvatore Bonaccorso]

Source: salt
Version: 3004+dfsg1-10
Severity: grave
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerabilities were published for salt.

CVE-2022-22934[0]:
| An issue was discovered in SaltStack Salt in versions before 3002.8,
| 3003.4, 3004.1. Salt Masters do not sign pillar data with the
| minion#8217;s public key, which can result in attackers
| substituting arbitrary pillar data.


CVE-2022-22935[1]:
| An issue was discovered in SaltStack Salt in versions before 3002.8,
| 3003.4, 3004.1. A minion authentication denial of service can cause a
| MiTM attacker to force a minion process to stop by impersonating a
| master.


CVE-2022-22936[2]:
| An issue was discovered in SaltStack Salt in versions before 3002.8,
| 3003.4, 3004.1. Job publishes and file server replies are susceptible
| to replay attacks, which can result in an attacker replaying job
| publishes causing minions to run old jobs. File server replies can
| also be re-played. A sufficient craft attacker could gain root access
| on minion under certain scenarios.


CVE-2022-22941[3]:
| An issue was discovered in SaltStack Salt in versions before 3002.8,
| 3003.4, 3004.1. When configured as a Master-of-Masters, with a
| publisher_acl, if a user configured in the publisher_acl targets any
| minion connected to the Syndic, the Salt Master incorrectly
| interpreted no valid targets as valid, allowing configured users to
| target any of the minions connected to the syndic with their
| configured commands. This requires a syndic master combined with
| publisher_acl configured on the Master-of-Masters, allowing users
| specified in the publisher_acl to bypass permissions, publishing
| authorized commands to any configured minion.

See [4] for the announce.

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2022-22934
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-22934
[1] https://security-tracker.debian.org/tracker/CVE-2022-22935
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-22935
[2] https://security-tracker.debian.org/tracker/CVE-2022-22936
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-22936
[3] https://security-tracker.debian.org/tracker/CVE-2022-22941
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-22941
[4] 
https://saltproject.io/security_announcements/salt-security-advisory-release/

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1008944: jellyfish1: autopkgtest failure on armhf and i386: Matrix is singular

[Paul Gevers]

Source: jellyfish1
Version: 1.1.11-7
Severity: serious
User: debian...@lists.debian.org
Usertags: fails-always

Dear maintainer(s),

You recently added an autopkgtest to your package jellyfish1, great. 
However, it fails on armhf and i386 (the two 32 bits ci architectures). 
Currently this failure is blocking the migration to testing [1]. Can you 
please investigate the situation and fix it?


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

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

Paul

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

https://ci.debian.net/data/autopkgtest/testing/armhf/j/jellyfish1/20325636/log.gz

run-unit-test: generating sample data
run-unit-test: generating md5 sums for verification
run-unit-test: running jellyfish1
terminate called after throwing an instance of 
'SquareBinaryMatrix::SingularMatrix'

  what():  Matrix is singular
Aborted
autopkgtest [04:55:00]: test run-unit-test


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1008943: O: grpc-proto -- Protobuf protocol definitions for gRPC services

[Bálint Réczey]

Package: wnpp
Severity: normal

Orphaning the package.

Thanks,
Balint

Bug#995903: chromium: Download manager, bookmark manager and extension manager is not showing when on there tab

[Andres Salomon]

On Fri, 19 Nov 2021 22:40:15 +0200 Sophoklis Goumas wrote:

> Package: chromium
> Version: 93.0.4577.82-1
> Followup-For: Bug #995903
>
> I too confirm this is affecting me in a way that makes Chromium's use 
deprived

> of core functionality as I can't access my bookmarks and extensions.
>


Hi,

There's been a ton of packaging changes since the chromium 93 release in 
Debian. Can you folks please tell me if history/bookmarks/extensions are 
still broken for you in chromium 100.0.4896.60-1, or if it is now fixed?


Thanks,

Andres

Bug#1008752: avifile: autopkgtest regression on armhf: Bus error

[Paul Gevers]

Hi

Bus error
autopkgtest [19:03:51]: test decoding-test-mp4-raw: ---]
autopkgtest [19:03:51]: test decoding-test-mp4-raw:  - - - - - - - - - - 
results - - - - - - - - - -

decoding-test-mp4-raw FAIL non-zero exit status 135
autopkgtest [19:03:51]:  - - - - - - - - - - running shell - - - - - - - 
- - -
root@elbrus:/tmp/autopkgtest-lxc.ze1_2t2a/downtmp/build.e5m/src# cd 
debian/tests/decoding-test-data/
root@elbrus:/tmp/autopkgtest-lxc.ze1_2t2a/downtmp/build.e5m/src/debian/tests/decoding-test-data# 
./gentestavi.sh

Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
Redistribute latency...
Pipeline is PREROLLED ...
Setting pipeline to PLAYING ...
Redistribute latency...
New clock: GstSystemClock
Got EOS from element "pipeline0".
Execution ended after 0:00:00.215248380
Setting pipeline to NULL ...
Freeing pipeline ...
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
Pipeline is PREROLLED ...
Setting pipeline to PLAYING ...
Redistribute latency...
New clock: GstSystemClock
Got EOS from element "pipeline0".
Execution ended after 0:00:00.219812907
Setting pipeline to NULL ...
Freeing pipeline ...
root@elbrus:/tmp/autopkgtest-lxc.ze1_2t2a/downtmp/build.e5m/src/debian/tests/decoding-test-data# 

root@elbrus:/tmp/autopkgtest-lxc.ze1_2t2a/downtmp/build.e5m/src/debian/tests/decoding-test-data# 

root@elbrus:/tmp/autopkgtest-lxc.ze1_2t2a/downtmp/build.e5m/src/debian/tests/decoding-test-data# 
make

g++ -Wall -g -o test1 test1.cc \
-laviplay -I/usr/include/avifile-0.7 \
-laubio  \
-lm
root@elbrus:/tmp/autopkgtest-lxc.ze1_2t2a/downtmp/build.e5m/src/debianroot@elbrus:/tmp/autopkgtest-lxc.ze1_2t2a/downtmp/build.e5m/src/debian/tests/decoding-test-data# 
apt install gdb libavcodec58-dbgsym


< installing gdb and libavcodec58-dbgsym >

root@elbrus:/tmp/autopkgtest-lxc.ze1_2t2a/downtmp/build.e5m/src/debian/tests/decoding-test-data# 
gdb ./test1

gdb: warning: Couldn't determine a path for the index cache directory.
GNU gdb (Debian 10.1-2+b1) 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 "arm-linux-gnueabihf".
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 ./test1...
(gdb) set args test_raw.avi
(gdb) run
Starting program: 
/tmp/autopkgtest-lxc.ze1_2t2a/downtmp/build.e5m/src/debian/tests/decoding-test-data/test1 
test_raw.avi

[Thread debugging using libthread_db enabled]
Using host libthread_db library 
"/lib/arm-linux-gnueabihf/libthread_db.so.1".

 : Avifile RELEASE-0.7.48-220318-20:07-../src/configure
 : Available CPU flags: fp asimd evtstrm aes pmull sha1 sha2 crc32 
atomics fphp asimdhp cpuid asimdrdm lrcpc dcpop asimddp ssbs

This binary was compiled for Avifile ver. 1840, the library is ver. 1840
 : Checking: test_raw.avi
 : MainHeader: MicroSecPerFrame=4 MaxBytesPerSec=6112800
 PaddingGranularity=0 Flags=[ HAS_INDEX IS_INTERLEAVED ] TotalFrames=250
 InitialFrames=0 Streams=2 SuggestedBufferSize=0 WxH=320x240
 Scale=0 Rate=0 Start=0 Length=0
 : StreamHeader: Type=vids Handler=DIVX Flags=[ ]
 InitialFrames=0 Scale=1 Rate=25 Start=0 Length=250
 SuggestedBufferSize=12413 Quality=0 SampleSize=0 Rect l,r,t,b=0,0,0,0
 : StreamHeader: Type=auds Handler=0x1 Flags=[ ]
 InitialFrames=0 Scale=1 Rate=44100 Start=0 Length=450559
 SuggestedBufferSize=8192 Quality=0 SampleSize=8 Rect l,r,t,b=0,0,0,0
 : Reading index from offset: 5581514
 : Stream 0 vids : DIVX (0x4944) 250 chunks (0.98KB)
 : WARNING: stream header has incorrect dwLength (450559 -> 
450560)

 : Stream 1 auds : Microsoft PCM (0x1) 440 chunks (3.44KB)
[New Thread 0xefdfea20 (LWP 6059)]
 : Initialized video stream (chunk tblsz: 250, fmtsz: 40)
 : Found 7 plugins 
(/usr/lib/arm-linux-gnueabihf/avifile-0.7,A:28,V:36)

 : looking for mpeg4  1482049860
 : Created video decoder: FF OpenDivX
 : Initialized audio stream (chunk tblsz: 450560, fmtsz: 18)
 : PCM audio decoder created
bh.biHeight = -240, bh.biWidth = 320
bh.biHeight < 0, correct the value to 240
Movie size: 320 x 240  [YV12]
audio format: 1, Channels: 2, Samples/sec: 44100, Bits/Sample: 32, 
Bytes/sec: 352800

Video Length: 250
Video Pos: 0
Audio Length: 450560
Audio Pos: 0
Decoder YUV capabilities: 0x8080
CAPS is CAP_YV12
TIME 0 0
 : using DR1
[mpeg4 @ 0x455690] Requested frame threading with a custom get_buffer2() 
implementation which is not marked as thread safe. This is not supported 
anymore, make your callback thread-safe.

Bug#1008156: telegram-desktop: Crash when switch account

[Nicholas Guriev]

Control: tags -1 - upstream

On Пн, 2022-03-28 at 13:20 +0300, Nicholas Guriev wrote:
> This will be fixed somehow in the upcoming upstream release, 3.6.2.

I was wrong and did incorrect test. In actual fact, the crash happens
due to memory allocator from glibc that is in use by default.

Can you please check my workaround? Run the next commands in terminal:

   sudo apt-get install libjemalloc2
   LD_PRELOAD=libjemalloc.so.2 telegram-desktop



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

Bug#1002059: [Pkg-samba-maint] Bug#1002059: Same problem?

[Michael Tokarev]

04.04.2022 12:16, Thibault Roulet wrote:

Hi all,

I'm not sure if my problem is the same but it looks pretty similar.
Everything was working fine when running samba 2:4.13.5+dfsg-2 and it broke my 
setup after upgrade to 2:4.13.13+dfsg-1~deb11u3

Last time I reverted to 4.13.5 but as there must be a solution to this problem, 
I'm trying again to fix that.

...

   Got user=[myusername] domain=[MYDOMAIN] workstation=[DRX1] len1=24 len2=266
[2022/04/04 10:48:44.844975,  3] 
../../source3/auth/user_util.c:353(map_username)
   Mapped user myusername to myusername
[2022/04/04 10:48:44.845054,  3] 
../../source3/auth/auth.c:200(auth_check_ntlm_password)
   check_ntlm_password:  Checking password for unmapped user 
[MYDOMAIN]\[myusername]@[DRX1] with the new password interface
[2022/04/04 10:48:44.845078,  3] 
../../source3/auth/auth.c:203(auth_check_ntlm_password)
   check_ntlm_password:  mapped user is: [MYDOMAIN]\[myusername]@[DRX1]
[2022/04/04 10:48:44.854933,  3] 
../../source3/auth/user_util.c:353(map_username)
   Mapped user MYDOMAIN\myusername to MYDOMAIN\myusername
[2022/04/04 10:48:44.859318,  3] 
../../source3/auth/auth_util.c:1928(check_account)
   Failed to find authenticated user MYDOMAIN\myusername via getpwnam(), 
denying access.


this most likely means your winbind does not work correctly or
nss_winbind isn't set up.  It is unlikely the same problem.

FWIW, I'm definitely not an expert in this part of samba, you
should really ask on the samba mailing list, I guess.

Thanks,

/mjt

Bug#1002059: regression: 2:4.9.5+dfsg-5+deb10u2 breaks SID to UID conversion

[Michael Tokarev]

Control: tag -1 + moreinfo

On Tue, 8 Feb 2022 00:54:18 + "McIntyre, Vincent (S, Marsfield)" 
 wrote:

One more followup.

I looked into migrating my samba machines to bullseye.
The config I had on buster works but with one change reqired.
On bullseye machines I need to add this to the configuration

  username map script = /etc/samba/usermap.sh

The usermap.sh works similarly to the script pasted in this bug:

   https://bugzilla.samba.org/show_bug.cgi?id=14901

ie it converts a 'DOMAIN\someuser' string to 'someuser',
depending on whether DOMAIN is an expected value or not.
This is not required on buster, more on that below.


Vincent, do you, by a chance, have the same usernames in
/etc/passwd and in the AD your samba server joined?

What you describe smells like you have the same username
here and there.

As the samba people told me, this is unsupported, a usee
should be either in AD or in local /etc/passwd but not
both. I think it is a bug (which is even easy to fix).

Is it the case here?

Thanks,

/mjt

Bug#1008941: python3-dbusmock: gnome-bluetooth3 FTBFS with python3-dbusmock 0.27.4-1

[Simon McVittie]

Package: python3-dbusmock
Version: 0.27.4-1
Severity: serious
Tags: patch upstream
Justification: FTBFS
Forwarded: https://github.com/martinpitt/python-dbusmock/issues/123
Control: affects -1 src:gnome-bluetooth

Upgrading python3-dbusmock from 0.27.3-1 to 0.27.4-1 causes the build
of gnome-bluetooth3_42.0-4 to regress. Please see the upstream bug report
for more details.

Fix proposed in https://github.com/martinpitt/python-dbusmock/pull/124

Thanks,
smcv

-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'stable-security'), (500, 
'oldstable-debug'), (500, 'oldoldstable'), (500, 'buildd-unstable'), (500, 
'unstable'), (500, 'testing'), (500, 'stable'), (500, 'oldstable'), (1, 
'experimental-debug'), (1, 'buildd-experimental'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages python3-dbusmock depends on:
ii  dbus-x11 1.14.0-1
ii  gir1.2-glib-2.0  1.72.0-1+b1
ii  python3  3.10.4-1
ii  python3-dbus 1.2.18-3+b1
ii  python3-gi   3.42.0-3

python3-dbusmock recommends no packages.

python3-dbusmock suggests no packages.

-- no debconf information

-- debsums errors found:
debsums: changed file 
/usr/lib/python3/dist-packages/dbusmock/templates/bluez5.py (from 
python3-dbusmock package)

Bug#983585: RFS: prometheus-cpp/1.0.0-1 [ITP] -- Prometheus Client Library for Modern C++

[Bastian Germann]

Hi Gregor,

Can you please relicense the debian/* files (currently GPL-2+) to a license that does not impose any more restrictions 
than the main project license (Expat)? With this change I am willing to sponsor the package.


Thanks,
Bastian

Bug#1006822: Fixed in 100.0.4896.60-1~deb11u1

[Andreas Juch]

I have good news on that issue: in the most recent security
update 100.0.4896.60-1~deb11u1 the issue is fixed for me. Chromium starts
with my usual flags in /etc/environment

CHROMIUM_FLAGS="--enable-features=UseOzonePlatform --ozone-platform=wayland"

So this is fixed for me.

Thanks, Andreas

Bug#1008940: angelfish: fails to start

[Marek Běl]

Package: angelfish
Version: 22.02-1
Severity: important

Dear Maintainer,
it is not possible to start angelfish on mobian PinePhone.
Error output is attached.
Both testing and unstable version of angelfish package is affected.
Possible cause of the problem is missing dependency on package 
qml-module-org-kde-kirigami2.
With this package manually installed it is possible to start angelfish.

Best Regards,
Marek Běl


-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing')
Architecture: arm64 (aarch64)

Kernel: Linux 5.15-sunxi64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_CRAP, TAINT_UNSIGNED_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=C.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 angelfish depends on:
ii  libc6  2.33-7
ii  libgcc-s1  12-20220319-1
ii  libkf5configcore5  5.90.0-1
ii  libkf5configgui5   5.90.0-1
ii  libkf5coreaddons5  5.90.0-1
ii  libkf5dbusaddons5  5.90.0-1
ii  libkf5i18n55.90.0-1
ii  libkf5notifications5   5.90.0-1
ii  libkf5windowsystem55.90.0-1
ii  libqt5core5a   5.15.2+dfsg-15
ii  libqt5gui5 5.15.2+dfsg-15
ii  libqt5network5 5.15.2+dfsg-15
ii  libqt5qml5 5.15.2+dfsg-10
ii  libqt5quick5   5.15.2+dfsg-10
ii  libqt5sql5 5.15.2+dfsg-15
ii  libqt5webengine5   5.15.8+dfsg-1+b1
ii  libqt5webenginecore5 [qtwebengine-abi-5-15-5]  5.15.8+dfsg-1+b1
ii  libqt5widgets5 5.15.2+dfsg-15
ii  libstdc++6 12-20220319-1
ii  qml-module-qtfeedback  5.0~git20180903.a14bd0b-3
ii  qml-module-qtwebengine 5.15.8+dfsg-1+b1

angelfish recommends no packages.

angelfish suggests no packages.

-- no debconf information

*** /home/mobian/angelfish.err
Warning: Ignoring XDG_SESSION_TYPE=wayland on Gnome. Use 
QT_QPA_PLATFORM=wayland to run on Wayland anyway.
QQmlApplicationEngine failed to load component
qrc:/mobile.qml:12:1: module "org.kde.kirigami" is not installed

Bug#1008939: use.t: allow empty lines in debian/tests/pkg-perl/use-name? (also use-whitelist)

[gregor herrmann]

Package: pkg-perl-autopkgtest
Version: 0.66
Severity: important
Tags: patch
X-Debbugs-Cc: nt...@debian.org

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

This is a kind of followup for #1008267:

While updating libchart-perl, I came across the following failure of
use.t:

  /usr/share/pkg-perl-autopkgtest/runtime-deps.d/use.t .. 
  1..8
  ok 1 -  /usr/bin/perl -w -M"Chart::Base" -e 1 2>&1 exited successfully
  ok 2 -  /usr/bin/perl -w -M"Chart::Base" -e 1 2>&1 produced no 
(non-whitelisted) output
  ok 3 - env PERL_DL_NONLAZY=1  /usr/bin/perl -w -M"Chart::Base" -e 1 2>&1 
exited successfully
  ok 4 - env PERL_DL_NONLAZY=1  /usr/bin/perl -w -M"Chart::Base" -e 1 2>&1 
produced no (non-whitelisted) output
  # Missing argument to -M.
  not ok 5 -  /usr/bin/perl -w -M"" -e 1 2>&1 exited successfully
  not ok 6 -  /usr/bin/perl -w -M"" -e 1 2>&1 produced no (non-whitelisted) 
output
  # Missing argument to -M.
  not ok 7 - env PERL_DL_NONLAZY=1  /usr/bin/perl -w -M"" -e 1 2>&1 exited 
successfully
  not ok 8 - env PERL_DL_NONLAZY=1  /usr/bin/perl -w -M"" -e 1 2>&1 produced no 
(non-whitelisted) output
  Dubious, test returned 4 (wstat 1024, 0x400)
  Failed 4/8 subtests 

So first (1-4) we have -M"Chart::Base", then (5-8) we see -M"". Where
does this come from? From debian/tests/pkg-perl/use-name which
starts with

  % cat debian/tests/pkg-perl/use-name
  # Chart.pm is only documentation. Let's check Chart::Base.
  Chart::Base

  # other options
  # Chart::Bars
  # Chart::Composite
  …


So @modules in use.t contains "Chart::Base" and "". Not ideal :)
This only appeared following the change in 0.66/#1008267 to allow
multiple module names (and multiple warnings), before that everything
was "fine" as only the first non-comment line was taken.

For now I've removed the empty line in libchart-perl's
debian/tests/pkg-perl/use-name but as this has potential for breaking
other packages' autopkgtests and is also counter-intuitive, I suggest
we accept and ignore empty lines in debian/tests/pkg-perl/use-name
(and also debian/tests/pkg-perl/use-whitelist).

Proposed patch:

#v+
- --- /usr/share/pkg-perl-autopkgtest/runtime-deps.d/use.t.packaged   
2022-04-04 17:48:42.204873999 +
+++ /usr/share/pkg-perl-autopkgtest/runtime-deps.d/use.t2022-04-04 
17:51:26.125604484 +
@@ -39,7 +39,7 @@
 or BAIL_OUT("$conffile exists but can't be read");
 while () {
 chomp;
- -next if /^\s*#/;
+next if /^\s*(#|$)/;
 push @ret, $_;
 }
 close M;
#v-


Cheers,
gregor

-BEGIN PGP SIGNATURE-

iQKTBAEBCgB9FiEE0eExbpOnYKgQTYX6uzpoAYZJqgYFAmJLM+lfFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEQx
RTEzMTZFOTNBNzYwQTgxMDREODVGQUJCM0E2ODAxODY0OUFBMDYACgkQuzpoAYZJ
qgYClQ//UrXonlEPwrfU8PD67ikxxUmw7/922MxJ5NOOWuQCPTWgBIJmsemcTArd
8OawqK+hmQM6qbd+8Eml2ALEZjtwW7xj/KvTScJpk/8x8RRb43ebxXOShLjy8Ah6
JeBI3624BLcivvplLdojJWHknTJiDKFiZqIiRq+Mcno7speFubN5d2VEA9JLnY5F
crxCIGpHZLNu+5ucAXBVGK6shz9a2ySs/5h8G4Qf6cuFbMYM72Zr6CNw4v35aV94
zACcsegrRb3YF9duCszOScwt/nGdoZPlTmYrCjpO2xtEuQruXSBP+V3uRxsCUMaJ
qMtCleJfTjMUwvxCxp4VbovFz/d41m0dDBLYmoR/opGiiq3DQeS+yg+07NS4NNkg
L/3di9cESvZtW3PELes6Yk6WRKAk0dfGxEB/ybTI1qKq3OHzPpgcQ50ELYjuNeQ2
bVzDdaagBT4ko04CFQ0Jrcx+xOK/kFLYQm1yrRmuMx1Raeo/c40iIhthrZpRMB4X
Qgspk4BJbgsIxIis+SCPVViH7v4gFm5utqmxK7ZX4YNd38c8NFBvzBeJB+4teywh
HMn8JP7rlODnREW9s7nHPGXMGIoLG+fVxnNcgFYyjwgawdbZLjcSNI0PMxYgCZO4
qp0xqDNVIHVaQ3DQwkzmZXEU0oJmxMtpSHuJMYPjz817/xIhw6M=
=CKrQ
-END PGP SIGNATURE-

Bug#1008603: geopy: python3-geographiclib no longer built from src:geographiclib

[Sebastiaan Couwenberg]

On 4/4/22 19:26, Daniele Tricoli wrote:

On Tue, Mar 29, 2022 at 08:51:43PM +0200, Sebastiaan Couwenberg wrote:

On 3/29/22 18:39, Sebastiaan Couwenberg wrote:
The distrib-Fortran directory appeared on SourceForge:

  https://sourceforge.net/projects/geographiclib/files/distrib-Fortran/

It links to the repo on GitHub where there is also one for Python:

  https://github.com/geographiclib/geographiclib-python


Thanks for the investigation, it appeared on SourceForge also the Python
distribution:
https://sourceforge.net/projects/geographiclib/files/distrib-Python/

The GitHub repository seems to be not updated yet. I will package it
from SourceForge.

Thanks for welcoming me to maintain it under the GIS team, but as you
said if it's not a problem I would prefer for now to maintain it under the
Python team to not have to deal with a different policy (but I have
bookmarked it and at a quick look it seems that only patches are handled
in a different way), since I also doing some rust stuff and it's a bit
time comsuming.

Do you know if this bug is enough for ftp masters os should I open an
ITP for the new packaging of python-geographiclib? I must confess it's
the first time I adopt something that was in a different source package.


As separate bugreport for a proper ITP is better.


Of course if you want to be added as a co-maintainer to the package, you
have just to tell me.


You may want to coordinate with Antonio Valentino who also expressed 
interest in packaging python-geographiclib:


 https://lists.debian.org/debian-gis/2022/03/msg8.html


I hope to be able to upload to experimental the 2.0a0 version during
this weekend.


Note that the Python versioning should be mangled to 2.0~a0.

Kind Regards,

Bas

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

Bug#1008603: geopy: python3-geographiclib no longer built from src:geographiclib

[Daniele Tricoli]

Hello Sebastiaan,

On Tue, Mar 29, 2022 at 08:51:43PM +0200, Sebastiaan Couwenberg wrote:
> On 3/29/22 18:39, Sebastiaan Couwenberg wrote:
> The distrib-Fortran directory appeared on SourceForge:
> 
>  https://sourceforge.net/projects/geographiclib/files/distrib-Fortran/
> 
> It links to the repo on GitHub where there is also one for Python:
> 
>  https://github.com/geographiclib/geographiclib-python

Thanks for the investigation, it appeared on SourceForge also the Python
distribution:
https://sourceforge.net/projects/geographiclib/files/distrib-Python/

The GitHub repository seems to be not updated yet. I will package it
from SourceForge.

Thanks for welcoming me to maintain it under the GIS team, but as you
said if it's not a problem I would prefer for now to maintain it under the
Python team to not have to deal with a different policy (but I have
bookmarked it and at a quick look it seems that only patches are handled
in a different way), since I also doing some rust stuff and it's a bit
time comsuming.

Do you know if this bug is enough for ftp masters os should I open an
ITP for the new packaging of python-geographiclib? I must confess it's
the first time I adopt something that was in a different source package.

Of course if you want to be added as a co-maintainer to the package, you
have just to tell me.

I hope to be able to upload to experimental the 2.0a0 version during
this weekend.

Regards,

-- 
  Daniele Tricoli 'eriol'
  https://mornie.org


signature.asc
Description: PGP signature

Bug#1008937: nmu: kopete_4:21.12.3-1

[Aurélien COUDERC]

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

nmu kopete_4:21.12.3-1 . ANY . experimental . -m "Rebuild with PIM 21.12."

Bug#483171: /usr/bin/tai64n: There should be a /commands symlink to /usr/bin

[Jan Mojzis]

Hello,
this bug seems to be obsolete,
we will close it.
If the problem persists in the new version (>= 0.76-8),
and the fix doesn't violate debian rules
please reopen the bug.

Thank You!

Bug#1008936: ITP: golang-github-drone-envsubst -- Go library for performing Bash-style parameter expansion

[Sebastian Crane]

Package: wnpp
Severity: wishlist
Owner: Sebastian Crane 

* Package name: golang-github-drone-envsubst
  Version : 1.0.3-1
  Upstream Author : Brad Rydzewski 
* URL : https://github.com/drone/envsubst
* License : Expat
  Programming Lang: Go
  Description : Go library for performing Bash-style parameter expansion

This library allows Go programs to expand strings which reference
environment variables with the ${var} syntax, as used by GNU Bash. It
supports most of the expansion syntaxes offered by Bash, including the
search and replace forms.

This is a required dependency of Woodpecker CI (see ITP #1008934). I
intend to maintain this package as a member of the Debian Go Packaging
Team.

Bug#1008934: ITP: woodpecker -- Container-based continuous integration (CI) system

[Sebastian Crane]

Package: wnpp
Severity: wishlist
Owner: Sebastian Crane 

* Package name: woodpecker
  Version : 0.15.0-1
  Upstream Author : Woodpecker CI
* URL : https://github.com/woodpecker-ci/woodpecker
* License : Apache-2.0
  Programming Lang: Go
  Description : Container-based continuous integration (CI) system

Woodpecker CI, also known simply as Woodpecker, is a continuous integration (CI)
system which utilises container technologies for performing tasks. It is a
community fork of Drone CI (which is no longer free software).

This package has many dependencies, but I am hoping to have it packaged for the
Debian 12 release. I intend to maintain this package as a member of the Debian
Go Packaging Team.

Bug#1008933: Include "CONFIG_ISCSI_IBFT=m" to linux-image-arm64 and linux-image-cloud-arm64

[Fabio Augusto Miranda Martins]

Package: linux-image-arm64 and linux-image-cloud-arm64
Version: 5.x and newer

We would like to use a basic Debian ARM image running on Oracle Cloud, and
the same way we currently do with x86_64 Debian image. We use the
ISCSI_IBFT module in our x86_64 image, and we would like to do the same on
ARM. We are using the linux-image-arm64 package in Debian for the kernel,
and it does not have the CONFIG_ISCSI_IBFT=m setting that we need.

Specifically we are trying to use the 5.x kernel in buster-backports
https://packages.debian.org/buster-backports/kernel/linux-image-arm64 This
points to specific kernel packages, that we would hope to have the config
option included in each build going forward

And we haven't tried it yet, but we want to start working on a Bullseye
image as well https://packages.debian.org/stable/kernel/linux-image-arm64

Ideally, we would like to get the config setting in the
linux-image-cloud-arm64 package too, since that seems to be a smaller
kernel that people sometimes prefer to use.

Would Debian kernel maintainers be able to include "CONFIG_ISCSI_IBFT=m" on
such arm kernels?

*Regards,*

Fabio Augusto Miranda Martins
Phone: +55 11 3197 6574 | +1 737 204 0305 (Ext.: 4120)
Mobile: +55 11 98564 0862
Technical Account Manager | Canonical


www.ubuntu.com | Ubuntu support: support.canonical.com
Toll-free to discuss or open a Support case: +1 737 204-0281 (US/Canada)

Bug#1008932: gitlab-sidekiq cannot find graphiql-rails

[Maximilian Stein]

Package: gitlab
Version: 14.7.7+ds1-2~fto11+2
Severity: normal

Dear Maintainer,

Recently, I tried to upgrade Gitlab to 14.7.7+ds1-2~fto11+2.
Unfortunately, gitlab-sidekiq does not start afterwards but fails as
it cannot find graphiql-rails:

gitlab-sidekiq[8334]: Could not find gem 'graphiql-rails (~> 1.8)' in any 
of the gem sources listed in your Gemfile

However, in /var/lib/gitlab/.gem/gems (I fixed the owner as described
in the wiki), the gem is present (in directory graphiql-rails-1.8.0).
Unfortunately, I cannot uninstall the apt package ruby-graphiql-rails
(version 1.4.10-1) as gitlab still depends on it.

So, I assumed that Gitlab finds the graphiql-rails package installed
by apt. After I had updated the Gemfile to require version 1.4 of
graphiql-rails, I can indeed successfully start gitlab-sidekiq.

With this, Gitlab starts again, however some features do not work.
Most notably, I cannot merge a morge request anymore.

Thanks for your support!

Best,
Maximilian

Bug#1008784: upgrade-system: Please restore cron.daily snippet for non-systemd systems

[Mark Hindley]

Martin-Éric,

On Sat, Apr 02, 2022 at 11:46:06AM +0300, Martin-Éric Racine wrote:
> As it so happens, unattended-upgrades leverages that too. This leaves
> exactly one feature of the script...
> 
> > > Which part of the cron snipet specifically do you find essential?
> >
> > Well, not essential but after upgrading I noticed I no longer got the daily
> > email I had come to expect about upgradable packages.
> 
> ... and apt-show-versions covers that. Would that work for you?

Yes, of course it will work as an alternative.

Mark

Bug#1008753: [DRE-maint] Bug#1008753: ITS: trocla

[Antonio Terceiro]

On Mon, Apr 04, 2022 at 11:00:32AM -0400, Antoine Beaupré wrote:
> On 2022-04-04 10:54:44, Antonio Terceiro wrote:
> > On Thu, Mar 31, 2022 at 03:31:08PM -0400, Antoine Beaupre wrote:
> >> Package: trocla
> >> Severity: important
> >> X-Debbugs-Cc: pkg-ruby-extras-maintain...@lists.alioth.debian.org, Jonas 
> >> Genannt 
> >> 
> >> Hi trocla maintainers!
> >> 
> >> It seems like the trocla package is lagging a little behind
> >> upstream. I filed a NMU (#988074) fixing RC bugs to experimental
> >> (because freeze) and it hasn't been acknowledged yet.
> >> 
> >> I am happy to take over the package. I am following the package
> >> salvaging process as described here:
> >> 
> >> https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#package-salvaging
> >> https://wiki.debian.org/PackageSalvaging
> >> 
> >> I consider the package fitting for salvaging based on the un-ack'd
> >> NMU, the two missed upstream releases, and the unanswered critical
> >> bugs.
> >> 
> >> I plan on uploading the current experimental (now NMU'd to unstable)
> >> release (0.3-0.1) to unstable, adding myself as uploader, keeping
> >> everything else intact. Which means that the current uploader and team
> >> maintainership would remain.
> >> 
> >> I am *not* (as far as I know?) part of the Ruby team but I'm happy to
> >> join if you consider it necessary.
> >> 
> >> I'm happy to cut this in any other shape you might desire, but I need
> >> this package at work so I'd love to see it in better shape. :)
> >
> > It's not necessary, but it's useful if this stays updated in the git
> > repository under the Ruby team because that makes it easier for us when
> > we need to fix packages that need work during Ruby interpreter
> > transitions.
> >
> > It's fine if you join the team and care only about this one package.
> > Otherwise please just go ahead and take over.
> 
> Thanks terceiro, I will see if i can join the team, but will otherwise
> keep the current maintainers/uploaders fields and just add myself.
> 
> Thanks for your confidence!

I just added you to the team on salsa.


signature.asc
Description: PGP signature

Bug#1008753: [DRE-maint] Bug#1008753: ITS: trocla

[Antoine Beaupré]

On 2022-04-04 10:54:44, Antonio Terceiro wrote:
> On Thu, Mar 31, 2022 at 03:31:08PM -0400, Antoine Beaupre wrote:
>> Package: trocla
>> Severity: important
>> X-Debbugs-Cc: pkg-ruby-extras-maintain...@lists.alioth.debian.org, Jonas 
>> Genannt 
>> 
>> Hi trocla maintainers!
>> 
>> It seems like the trocla package is lagging a little behind
>> upstream. I filed a NMU (#988074) fixing RC bugs to experimental
>> (because freeze) and it hasn't been acknowledged yet.
>> 
>> I am happy to take over the package. I am following the package
>> salvaging process as described here:
>> 
>> https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#package-salvaging
>> https://wiki.debian.org/PackageSalvaging
>> 
>> I consider the package fitting for salvaging based on the un-ack'd
>> NMU, the two missed upstream releases, and the unanswered critical
>> bugs.
>> 
>> I plan on uploading the current experimental (now NMU'd to unstable)
>> release (0.3-0.1) to unstable, adding myself as uploader, keeping
>> everything else intact. Which means that the current uploader and team
>> maintainership would remain.
>> 
>> I am *not* (as far as I know?) part of the Ruby team but I'm happy to
>> join if you consider it necessary.
>> 
>> I'm happy to cut this in any other shape you might desire, but I need
>> this package at work so I'd love to see it in better shape. :)
>
> It's not necessary, but it's useful if this stays updated in the git
> repository under the Ruby team because that makes it easier for us when
> we need to fix packages that need work during Ruby interpreter
> transitions.
>
> It's fine if you join the team and care only about this one package.
> Otherwise please just go ahead and take over.

Thanks terceiro, I will see if i can join the team, but will otherwise
keep the current maintainers/uploaders fields and just add myself.

Thanks for your confidence!

-- 
We must shift America from a needs- to a desires-culture. People must
be trained to desire, to want new things, even before the old have
been entirely consumed. Man's desires must overshadow his needs.
 - Paul Mazur, Lehman Brothers

Bug#1008752: avifile: autopkgtest regression on armhf: Bus error

[Ying-Chun Liu (PaulLiu)]

Hi Paul,

In debian/tests/decoding-test-data, please run "./gentestavi.sh". This 
command generates the test data (test_raw.avi).


And run "make". It will compile the test program (test1).
Then run "gdb ./test1".
In gdb prompt, execute "set args test_raw.avi".
And then "run".
When the bus error happened, execute "bt -full" and it will print out 
the backtrace.


You might want to install the debug symbols (-dbg) packages to get the 
symbol resolved.


Yours,
Paul

Ying-Chun Liu (PaulLiu) 於 2022/4/1 20:53 寫道:

Hi Paul,


I need some help. Actually I know this bug for a while but I just 
cannot fix it. I've tried to reproduce the bug on qemu-user-static 
armhf chroot envorionment and PorterBox (abel.debian.org), on both 
platform the autopkgtest just passed without problem.


I think the bug should be easy to locate if I can run gdb and see the 
backtrace when the bus error happened.
But I just cannot reproduce this bug on my side or on porter box. If 
possible I hope to get some core dump when bus error happened on the 
machine that runs the test.


Yours,
Paul




Paul Gevers 於 2022/4/1 03:31 寫道:

Source: avifile
Version: 1:0.7.48~20090503.ds-23
Severity: serious
User: debian...@lists.debian.org
Usertags: regression

Dear maintainer(s),

With a recent upload of avifile the autopkgtest of avifile fails in 
testing on armhf when that autopkgtest is run with the binary 
packages of avifile from unstable. It passes when run with only 
packages from testing. In tabular form:


   pass    fail
avifile    from testing    1:0.7.48~20090503.ds-23
all others from testing    from testing

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

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


More information about this bug and the reason for filing it can be 
found on

https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

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

https://ci.debian.net/data/autopkgtest/testing/armhf/a/avifile/20131436/log.gz 



Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
Redistribute latency...
Pipeline is PREROLLED ...
Setting pipeline to PLAYING ...
Redistribute latency...
New clock: GstSystemClock
Got EOS from element "pipeline0".
Execution ended after 0:00:00.312851570
Setting pipeline to NULL ...
Freeing pipeline ...
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
Pipeline is PREROLLED ...
Setting pipeline to PLAYING ...
Redistribute latency...
New clock: GstSystemClock
Got EOS from element "pipeline0".
Execution ended after 0:00:00.217510393
Setting pipeline to NULL ...
Freeing pipeline ...
g++ -Wall -g -o test1 test1.cc \
-laviplay -I/usr/include/avifile-0.7 \
-laubio  \
-lm
 : Avifile RELEASE-0.7.48-220318-20:07-../src/configure
 : Available CPU flags: fp asimd evtstrm aes pmull sha1 sha2 
crc32 atomics fphp asimdhp cpuid asimdrdm lrcpc dcpop asimddp ssbs

This binary was compiled for Avifile ver. 1840, the library is ver. 1840
 : Checking: ./test_raw.avi
 : MainHeader: MicroSecPerFrame=4 MaxBytesPerSec=6112800
 PaddingGranularity=0 Flags=[ HAS_INDEX IS_INTERLEAVED ] TotalFrames=250
 InitialFrames=0 Streams=2 SuggestedBufferSize=0 WxH=320x240
 Scale=0 Rate=0 Start=0 Length=0
 : StreamHeader: Type=vids Handler=DIVX Flags=[ ]
 InitialFrames=0 Scale=1 Rate=25 Start=0 Length=250
 SuggestedBufferSize=12413 Quality=0 SampleSize=0 Rect l,r,t,b=0,0,0,0
 : StreamHeader: Type=auds Handler=0x1 Flags=[ ]
 InitialFrames=0 Scale=1 Rate=44100 Start=0 Length=450559
 SuggestedBufferSize=8192 Quality=0 SampleSize=8 Rect l,r,t,b=0,0,0,0
 : Reading index from offset: 5581514
 : Stream 0 vids : DIVX (0x4944) 250 chunks (0.98KB)
 : WARNING: stream header has incorrect dwLength (450559 
-> 450560)

 : Stream 1 auds : Microsoft PCM (0x1) 440 chunks (3.44KB)
 : Initialized video stream (chunk tblsz: 250, fmtsz: 40)
 : Found 7 plugins 
(/usr/lib/arm-linux-gnueabihf/avifile-0.7,A:28,V:36)

 : creating dir: /home/debci/.avm
 : looking for mpeg4  1482049860
 : Created video decoder: FF OpenDivX
 : Initialized audio stream (chunk tblsz: 450560, fmtsz: 18)
 : PCM audio decoder created
bh.biHeight = -240, bh.biWidth = 320
bh.biHeight < 0, correct the value to 240
Movie size: 320 x 240  [YV12]
audio format: 1, Channels: 2, Samples/sec: 44100, Bits/Sample: 32, 
Bytes/sec: 352800

Video Length: 250
Video Pos: 0
Audio Length: 450560
Audio Pos: 0
Decoder YUV capabilities: 0x8080
CAPS is CAP_YV12
TIME 0 0
[mpeg4 @ 0x1ad7e40] Requested frame threading with a custom 
get_buffer2() implementation which is not marked as thread safe. This 
is not supported anymore, make your callback thread-safe.

 : using DR1
Audio read 192 samples, 1536 bytes.
Audio frequency 469.27 hz
Audio read 192 samples, 1536 bytes.
Audio frequency 469.188 hz
Audio read 192 samples, 1536 bytes.
Audio frequency 469.095 hz
Audio read 192 samples, 1536 

Bug#1006149: linux-image-5.16.0-1-686: Fails to boot on T41 Thinkpads

[Francesco C]

Axel Beckert wrote:

> ... but I actually have no idea how to cross-compile a
> kernel package from amd64 to i386.

The 64 bits compiler supports native build of 32 bits binaries through
the -m32 flag so you have just to install kernel build dependencies ,
multilibs support and point to the kernel source tree :

make ARCH=i386 menuconfig and then load your kernel config from elsewhere
make ARCH=i386 -j(number_of_cores) bindeb-pkg

You will obtain kernel-image--i386.deb and
kernel-headers--i386.deb for the 32 bit
architecture.

When installing the headers in the native 32 bit machine, the external
modules will not be built by dkms because the headers' scripts
"fixdep" and "genksym" are not cross-compiled but they're built for a
x86_64 environment : those scripts  can be simply replaced by copying
their 32 bit version from a pre installed 32 bit headers' scripts
location ( eg: /usr/src/linux-headers-5.16.0-6-common/scripts/basic/fixdep
, /usr/src/linux-headers-5.16.0-6-common/scripts/genksym/genksym )

modpost gives problems to be replaced : I found a solution by
installing qemu-x86_64 in the 32 bit environment , putting the 64 bits
libc-2.3x.so and ld.so somewhere and finally changing in
scripts/Makefile.modpost the line

MODPOST = scripts/mod/modpost

with

MODPOST = qemu-x86_64 -L  scripts/mod/modpost

You can now build your modules with :

dkms autoinstall -k 

It's an artifact that I use because I don't really want to set up a
native 32 bit build host.

So is the solution to this bug to not permit reading the
driver's log when attached to an ICH4 controller ? If that's the case
you will have to blacklist all the machines with that controller
installed, not only "Thinkpad" branded machines. I suspect that the
controller is the base for a bunch of different branded machines of a
certain period ( mine is an ACER )

P.s. for readers  for the next time , please sanitize the serial
number of the drives :)

Bug#1008813: ITP: cargo-strip -- subcommand that reduces the size of Rust binaries

[Tomas Pospisek]

On 02.04.22 03:46, Josenilson Ferreira da Silva wrote:

Package: wnpp
Severity: wishlist
Owner: Josenilson Ferreira da Silva 
X-Debbugs-Cc: debian-de...@lists.debian.org, nilsonfsi...@hotmail.com

* Package name: cargo-strip
   Version : 0.2.2
   Upstream Author : Guillaume Valadon 
* URL : https://github.com/guedou/cargo-strip/issues
* License : MIT/X,
   Programming Lang: rust
   Description : subcommand that reduces the size of Rust binaries

subcommand that reduces the size of Rust binaries
  As of Rust 1.59, the charge command is now able to remove a binary.
  This can be activated in your Cargo.toml.


"the charge command is now able to remove a binary". You mean like `rm 
/usr/local/bin/foobar`? I /think/ that's not what you wanted to express?

*t

Bug#999443: pulseaudio: Muted microphone is unmuted when resuming from sleep

[Ben Goodwin]

Package: pulseaudio
Version: 15.0+dfsg1-4
Followup-For: Bug #999443
X-Debbugs-Cc: vbgoodw...@gmail.com

It seems that I was mistaken and this bug is not resolved in 15.0+dfsg1-4.
The microphone seems to keep its muted status after a reboot but not
afer waking from being suspended to memory.


-- Package-specific info:
File '/etc/default/pulseaudio' does not exist


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

Kernel: Linux 5.16.0-4-amd64 (SMP w/8 CPU threads; PREEMPT)
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 not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages pulseaudio depends on:
ii  adduser 3.120
ii  init-system-helpers 1.62
ii  libasound2  1.2.6.1-2
ii  libasound2-plugins  1.2.6-1
ii  libc6   2.33-7
ii  libcap2 1:2.44-1
ii  libdbus-1-3 1.14.0-1
ii  libfftw3-single33.3.8-2
ii  libgcc-s1   12-20220319-1
ii  libglib2.0-02.70.4-1
ii  libgstreamer-plugins-base1.0-0  1.20.1-1
ii  libgstreamer1.0-0   1.20.1-1
ii  libice6 2:1.0.10-1
ii  libltdl72.4.6-15
ii  liborc-0.4-01:0.4.32-2
ii  libpulse0   15.0+dfsg1-4
ii  libsm6  2:1.2.3-1
ii  libsndfile1 1.0.31-2
ii  libsoxr00.1.3-4
ii  libspeexdsp11.2~rc1.2-3
ii  libstdc++6  12-20220319-1
ii  libsystemd0 250.4-1
ii  libtdb1 1.4.5-2
ii  libudev1250.4-1
ii  libwebrtc-audio-processing1 0.3-1+b1
ii  libx11-62:1.7.2-2+b1
ii  libx11-xcb1 2:1.7.2-2+b1
ii  libxcb1 1.14-3
ii  libxtst62:1.2.3-1
ii  lsb-base11.1.0
ii  pulseaudio-utils15.0+dfsg1-4

Versions of packages pulseaudio recommends:
ii  dbus-user-session1.14.0-1
ii  libpam-systemd [logind]  250.4-1
ii  rtkit0.13-4

Versions of packages pulseaudio suggests:
pn  paprefs  
ii  pavucontrol  5.0-2
pn  pavumeter
ii  udev 250.4-1

-- no debconf information
# This file is part of PulseAudio.
#
# PulseAudio is free software; you can redistribute it and/or modify
# it under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
#
# PulseAudio is distributed in the hope that it will be useful, but
# WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
# General Public License for more details.
#
# You should have received a copy of the GNU Lesser General Public License
# along with PulseAudio; if not, see .

## Configuration file for PulseAudio clients. See pulse-client.conf(5) for
## more information. Default values are commented out.  Use either ; or # for
## commenting.

; default-sink =
; default-source =
; default-server =
; default-dbus-server =

; autospawn = yes
; daemon-binary = /usr/bin/pulseaudio
; extra-arguments = --log-target=syslog

; cookie-file =

; enable-shm = yes
; shm-size-bytes = 0 # setting this 0 will use the system-default, usually 64 
MiB

; auto-connect-localhost = no
; auto-connect-display = no
# This file is part of PulseAudio.
#
# PulseAudio is free software; you can redistribute it and/or modify
# it under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
#
# PulseAudio is distributed in the hope that it will be useful, but
# WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
# General Public License for more details.
#
# You should have received a copy of the GNU Lesser General Public License
# along with PulseAudio; if not, see .

## Configuration file for the PulseAudio daemon. See pulse-daemon.conf(5) for
## more information. Default values are commented out.  Use either ; or # for
## commenting.

; daemonize = no
; fail = yes
; allow-module-loading = yes
; allow-exit = yes
; use-pid-file = yes
; system-instance = no
; local-server-type = user
; enable-shm = yes
; enable-memfd = yes
; shm-size-bytes = 0 # setting this 0 will use the system-default, usually 64 
MiB
; lock-memory = no
; cpu-limit = no

; high-priority = yes
; nice-level = -11

Bug#1008753: [DRE-maint] Bug#1008753: ITS: trocla

[Antonio Terceiro]

On Thu, Mar 31, 2022 at 03:31:08PM -0400, Antoine Beaupre wrote:
> Package: trocla
> Severity: important
> X-Debbugs-Cc: pkg-ruby-extras-maintain...@lists.alioth.debian.org, Jonas 
> Genannt 
> 
> Hi trocla maintainers!
> 
> It seems like the trocla package is lagging a little behind
> upstream. I filed a NMU (#988074) fixing RC bugs to experimental
> (because freeze) and it hasn't been acknowledged yet.
> 
> I am happy to take over the package. I am following the package
> salvaging process as described here:
> 
> https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#package-salvaging
> https://wiki.debian.org/PackageSalvaging
> 
> I consider the package fitting for salvaging based on the un-ack'd
> NMU, the two missed upstream releases, and the unanswered critical
> bugs.
> 
> I plan on uploading the current experimental (now NMU'd to unstable)
> release (0.3-0.1) to unstable, adding myself as uploader, keeping
> everything else intact. Which means that the current uploader and team
> maintainership would remain.
> 
> I am *not* (as far as I know?) part of the Ruby team but I'm happy to
> join if you consider it necessary.
> 
> I'm happy to cut this in any other shape you might desire, but I need
> this package at work so I'd love to see it in better shape. :)

It's not necessary, but it's useful if this stays updated in the git
repository under the Ruby team because that makes it easier for us when
we need to fix packages that need work during Ruby interpreter
transitions.

It's fine if you join the team and care only about this one package.
Otherwise please just go ahead and take over.


signature.asc
Description: PGP signature

Bug#1008424: audiofile: FTBFS: dh_auto_test: error: make -j8 check VERBOSE=1 returned exit code 2

[Alberto Garcia]

On Sat, Mar 26, 2022 at 10:03:42PM +0100, Lucas Nussbaum wrote:
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
> 
> > FAIL: FLAC

This started to happen after flac was updated from 1.3.3-2 to 1.3.4-1.

Downgrading the flac packages makes audiofile build fine again.

Berto

Bug#1008930: RFS: go-junit-report/1.0.0-1 -- Convert go test output to junit xml (program)

[Gabriel M. Dutra]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "go-junit-report":

* Package name : go-junit-report
Version : 1.0.0-1
Upstream Author : TODO
* URL : https://github.com/jstemmer/go-junit-report
* License : Expat
* Vcs : https://salsa.debian.org/go-team/packages/go-junit-report
Section : golang

The source builds the following binary packages:

go-junit-report - Convert go test output to junit xml (program)

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


https://mentors.debian.net/package/go-junit-report/

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

dget -x 
https://mentors.debian.net/debian/pool/main/g/go-junit-report/go-junit-report_1.0.0-1.dsc


Changes for the initial release:

go-junit-report (1.0.0-1) UNRELEASED; urgency=medium
.
* Initial release (Closes: TODO)

Regards,

Bug#1000810: python3-django-hyperkitty: Internal Server Error (500): ImportError: cannot import name 'url_has_allowed_host_and_scheme'

[Colin Turner]

Hi Pierre-Elliott,

At some point, and I don’t know why or when, this bug has gone away. Thank you!

Kind regards,

CT.

PS. I have a new one though, reporting shortly…

Bug#1008929: ModuleNotFoundError: No module named 'mistune.plugins'; 'mistune' is not a package

[Colin Turner]

Package: python3-django-hyperkitty
Version: 1.3.5.0-2
Severity: normal

Dear Maintainer,

Thanks for your work on this package. After the most recent upgrade to the 
version above, which also brought in python3-mistune as below, I am 
unfortunately finding my inbox flooded by cron errors, to the extent that I 
disabled "by minute" cron jobs. I'm not really sure why since mistune is 
installed. I have tried restarting the mailman3-web service but to no avail.

Traceback as below:

Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/django/template/backends/django.py", line 
121, in get_package_libraries
module = import_module(entry[1])
File "/usr/lib/python3.9/importlib/__init__.py", line 127, in import_module
return _bootstrap._gcd_import(name[level:], package, level)
File "", line 1030, in _gcd_import
File "", line 1007, in _find_and_load
File "", line 986, in _find_and_load_unlocked
File "", line 680, in _load_unlocked
File "", line 850, in exec_module
File "", line 228, in _call_with_frames_removed
File "/usr/lib/python3/dist-packages/hyperkitty/templatetags/decorate.py", line 
4, in 
from hyperkitty.lib.renderer import markdown_renderer, text_renderer
File "/usr/lib/python3/dist-packages/hyperkitty/lib/renderer.py", line 6, in 

from mistune.plugins.extra import plugin_url
ModuleNotFoundError: No module named 'mistune.plugins'; 'mistune' is not a 
package

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
File "/usr/share/mailman3-web/manage.py", line 10, in 
execute_from_command_line(sys.argv)
File "/usr/lib/python3/dist-packages/django/core/management/__init__.py", line 
419, in execute_from_command_line
utility.execute()
File "/usr/lib/python3/dist-packages/django/core/management/__init__.py", line 
413, in execute
self.fetch_command(subcommand).run_from_argv(self.argv)
File "/usr/lib/python3/dist-packages/django/core/management/base.py", line 354, 
in run_from_argv
self.execute(*args, **cmd_options)
File "/usr/lib/python3/dist-packages/django/core/management/base.py", line 393, 
in execute
self.check()
File "/usr/lib/python3/dist-packages/django/core/management/base.py", line 419, 
in check
all_issues = checks.run_checks(
File "/usr/lib/python3/dist-packages/django/core/checks/registry.py", line 76, 
in run_checks
new_errors = check(app_configs=app_configs, databases=databases)
File "/usr/lib/python3/dist-packages/django/contrib/admin/checks.py", line 78, 
in check_dependencies
for engine in engines.all():
File "/usr/lib/python3/dist-packages/django/template/utils.py", line 90, in all
return [self[alias] for alias in self]
File "/usr/lib/python3/dist-packages/django/template/utils.py", line 90, in 

return [self[alias] for alias in self]
File "/usr/lib/python3/dist-packages/django/template/utils.py", line 81, in 
__getitem__
engine = engine_cls(params)
File "/usr/lib/python3/dist-packages/django/template/backends/django.py", line 
25, in __init__
options['libraries'] = self.get_templatetag_libraries(libraries)
File "/usr/lib/python3/dist-packages/django/template/backends/django.py", line 
43, in get_templatetag_libraries
libraries = get_installed_libraries()
File "/usr/lib/python3/dist-packages/django/template/backends/django.py", line 
108, in get_installed_libraries
for name in get_package_libraries(pkg):
File "/usr/lib/python3/dist-packages/django/template/backends/django.py", line 
123, in get_package_libraries
raise InvalidTemplateLibrary(
django.template.library.InvalidTemplateLibrary: Invalid template library 
specified. ImportError raised when trying to load 
'hyperkitty.templatetags.decorate': No module named 'mistune.plugins'; 
'mistune' is not a package

A similar error is occuring on web access causing a 500 HTTP Error.

Kind regards,

CT.


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

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

Versions of packages python3-django-hyperkitty depends on:
ii  fonts-glyphicons-halflings   1.009~3.4.1+dfsg-2
ii  libjs-bootstrap4 4.6.1+dfsg1-1
ii  libjs-sphinxdoc  4.3.2-1
ii  python3  3.9.8-1
ii  python3-dateutil 2.8.1-6
ii  python3-django   2:3.2.12-2
ii  python3-django-compressor2.4.1-2
ii  python3-django-extensions3.1.5-2
ii  python3-django-gravatar2 1.4.4-2
ii  python3-django-haystack  3.1.1-1
ii  python3-django-mailman3  1.3.7-1
ii  python3-django-q 1.3.9-3
ii  python3-djangorestframework  3.12.4-2.1
ii  python3-elasticsearch7.16.2-1
ii  python3-flufl.lock   5.0.1-1
ii  python3-mailmanclient3.3.3-1
ii  python3-mistune  

Bug#1008741: whipper: please update to latest upstream version

[Krzysztof Krzyżaniak]

Feel free to move the project into Debian Python Team. As for the last
upstream version either the missing dependency has to be packaged first
(discid) or a small patch that replaces discid with python-libdiscid which
is already packaged in debian.

  eloy


czw., 31 mar 2022 o 17:24 Louis-Philippe Véronneau 
napisał(a):

> Package: whipper
> Severity: wishlist
>
> Dear maintainer,
>
> There's a new upstream version for this package (v0.10.0) and it solves
> quite a few bugs.
>
> Please consider updating to it.
>
> On a side note, I think it would be beneficial to move this package to
> the Debian Python Team (DPT). I would be more than happy to fix bugs and
> update this package myself if it was team maintained.
>
> Cheers,
>
> --
>   ⢀⣴⠾⠻⢶⣦⠀
>   ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
>   ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
>   ⠈⠳⣄
>

Bug#1008927: ITP: jaraco.context -- jaraco contextlib extensions

[Jeroen Ploemen]

Package: wnpp
Severity: wishlist

Needed for recent versions of jaraco.text.


pgpdu8KJJK9Kr.pgp
Description: OpenPGP digital signature

Bug#1007906: transition: mutter

[Simon McVittie]

On Mon, 04 Apr 2022 at 12:19:31 +0100, Simon McVittie wrote:
> On Mon, 04 Apr 2022 at 12:59:33 +0200, Sebastian Ramacher wrote:
> > Will this issue also affect bullseye to bookworm upgrades?
> 
> At the moment, yes, it could affect partial upgrades.

Actually, I think it will not be able to happen once GNOME Shell 42 is
in bookworm, because gir1.2-gweather-4.0 Depends on a version of
libgweather-4-0 that already Breaks bullseye's gnome-shell.

> I was going to give
> gir1.2-gweather-4.0 a Breaks: gnome-shell (<< 42)

I'll do that anyway (unless asked not to), because explicit is better
than implicit.

smcv

Bug#1007906: transition: mutter

[Simon McVittie]

On Mon, 04 Apr 2022 at 12:59:33 +0200, Sebastian Ramacher wrote:
> Will this issue also affect bullseye to bookworm upgrades?

At the moment, yes, it could affect partial upgrades. I was going to give
gir1.2-gweather-4.0 a Breaks: gnome-shell (<< 42) to prevent the
known-broken partial upgrades from happening, unless you consider the cost
of those Breaks to the apt solver to be higher than the risk of broken
partial upgrades.

There are probably other scenarios where a partial upgrade from bullseye
to bookworm will break bullseye's gnome-shell. I can try to scatter enough
Breaks through our ecosystem to prevent those, but it seems unlikely that
I'll find all of them.

Because testing is already broken (it's too late for a gir1.2-gweather-4.0
change to fix existing systems immediately), and partial upgrades are
not really supportable in general, I had been prioritizing like this:

1. fix full upgrades to testing by getting Shell 42 migrated
2. fix Shell upstream so this won't happen again in 42 -> 43
3. (please mind the gap)
4. a best-effort attempt to stop the breakage that already happened from
   affecting partial upgrades

smcv

Bug#998423: samba: Shares with variable substitutions cause core dump upon connection from macOS Big Sur or newer

[Michael Tokarev]

04.04.2022 03:48, Harry Sintonen wrote:

This is still broken in 2:4.13.14+dfsg-1+b3


That's true indeed, since this is just a rebuild of
the same source package as we had before,
without any source changes whatsoever.


Indeed, fixing this would be as simple as bringing over these two commits:

https://salsa.debian.org/samba-team/samba/-/commit/b4d8c62c4e8191e05fd03dd096a0bc989e224ed3
https://salsa.debian.org/samba-team/samba/-/commit/857045f3a236dea125200dd09279d677e513682b


I updated the bugreport with this information.
Hopefully we can make an upload of 4.13 for bullseye
fixing this and other serious issues in there, soon.

Thanks!

/mjt

Bug#1007906: transition: mutter

[Sebastian Ramacher]

On 2022-04-04 11:38:37, Simon McVittie wrote:
> On Mon, 28 Mar 2022 at 15:27:12 +0200, Graham Inggs wrote:
> > On Wed, 23 Mar 2022 at 17:21, Simon McVittie  wrote:
> > > As usual, lots of Shell
> > > extensions are affected by API changes and will need porting or removal,
> > > but as usual, I think removing the affected Shell extensions from testing
> > > is a better answer than waiting for all of them to be fixed
> 
> It looks as though the libgweather transition reaching bookworm has
> broken bookworm's version of gnome-shell 41 (#1008926), so I think it's
> time to take action to get gnome-shell 42 into testing. Please remove
> these extensions from testing:
> 
> # 1007906
> remove gnome-shell-extension-bluetooth-quick-connect/26-1
> remove gnome-shell-extension-draw-on-your-screen/11-2
> remove gnome-shell-extension-easyscreencast/1.5.0-1
> remove gnome-shell-extension-hamster/0.10.0+git20210628-2
> remove gnome-shell-extension-sound-device-chooser/39-1
> remove gnome-shell-extension-tiling-assistant/32-1
> remove gnome-shell-extension-top-icons-plus/27-6
> remove gnome-shell-extension-volume-mixer/41.1+dfsg-1
> remove gnome-shell-extension-weather/0.0~git20210509.d714eb1-2
> 
> Fixed versions of half of those packages are already available, so
> if you want to get them back into testing sooner, you could also put
> some appropriate age-days on these updated versions:
> 
> gnome-shell-extension-bluetooth-quick-connect/26-2
> gnome-shell-extension-hamster/0.10.0+git20210628-3
> gnome-shell-extension-top-icons-plus/27-7
> gnome-shell-extension-volume-mixer/41.1+dfsg-2
> gnome-shell-extension-weather/0.0~git20210509.d714eb1-3
> 
> but I think removing the broken versions and having the fixed versions
> migrate later is going to be a better outcome than having a broken
> gnome-shell in testing for a few more days.
> 
> I'm preparing a patch for gnome-shell 42 that should prevent a similar
> failure mode from happening at the 42 to 43 transition, but we cannot fix
> gnome-shell 41 without either testing-proposed-updates or a time machine.

Will this issue also affect bullseye to bookworm upgrades? Or will your
fix for 42->43 ensure that this won't happen?

Cheers
-- 
Sebastian Ramacher

Bug#1008910: mount-functions: Only allows for LABEL/UUID

[Mark Hindley]

Control: tags -1 patch

Thanks,

On Mon, Apr 04, 2022 at 12:48:07AM +0200, Thorsten Glaser wrote:
> On Sun, 3 Apr 2022, Elliott Mitchell wrote:
> 
> > Perhaps the test should be: "[A-Z][A-Z]*[A-Z][A-Z]=*"?
> 
> No, that’s a shellglob, no BRE.
> 
> I think it’s best here to update the list with whatever findfs(8)
> comes up when it does come up; anything else would require either
> ksh extglobs or really excessive parsing attempts few would want
> to maintain.

How the attached patch this seem?

I will look at  #677420/#724959

Mark
>From f2bb3c4db3b4b336f8bd74356ad13f2a24918f10 Mon Sep 17 00:00:00 2001
From: Mark Hindley 
Date: Mon, 4 Apr 2022 10:08:38 +0100
Subject: [PATCH] mount-functions.sh: add PARTUUID and PARTLABEL support.

Closes: #1008910
---
 debian/src/initscripts/lib/init/mount-functions.sh | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/debian/src/initscripts/lib/init/mount-functions.sh b/debian/src/initscripts/lib/init/mount-functions.sh
index 709323af..454006f0 100644
--- a/debian/src/initscripts/lib/init/mount-functions.sh
+++ b/debian/src/initscripts/lib/init/mount-functions.sh
@@ -32,8 +32,8 @@ selinux_enabled () {
 }
 
 # Read /etc/fstab, looking for:
-# 1) The root filesystem, resolving LABEL=*|UUID=* entries to the
-#	device node,
+# 1) The root filesystem, resolving LABEL=*|UUID=*|PARTUUID=*|PARTLABEL=* entries
+#	to the device node,
 # 2) Swap that is on a md device or a file that may be on a md
 #	device,
 _read_fstab () {
@@ -58,7 +58,7 @@ _read_fstab () {
 	;;
   /dev/*)
 	;;
-  LABEL=*|UUID=*)
+  LABEL=*|UUID=*|PARTUUID=*|PARTLABEL=*)
 	if [ "$MTPT" = "/" ] && [ -x /sbin/findfs ]
 	then
 		DEV="$(findfs "$DEV")"
-- 
2.35.1

Bug#1007906: transition: mutter

[Simon McVittie]

On Mon, 28 Mar 2022 at 15:27:12 +0200, Graham Inggs wrote:
> On Wed, 23 Mar 2022 at 17:21, Simon McVittie  wrote:
> > As usual, lots of Shell
> > extensions are affected by API changes and will need porting or removal,
> > but as usual, I think removing the affected Shell extensions from testing
> > is a better answer than waiting for all of them to be fixed

It looks as though the libgweather transition reaching bookworm has
broken bookworm's version of gnome-shell 41 (#1008926), so I think it's
time to take action to get gnome-shell 42 into testing. Please remove
these extensions from testing:

# 1007906
remove gnome-shell-extension-bluetooth-quick-connect/26-1
remove gnome-shell-extension-draw-on-your-screen/11-2
remove gnome-shell-extension-easyscreencast/1.5.0-1
remove gnome-shell-extension-hamster/0.10.0+git20210628-2
remove gnome-shell-extension-sound-device-chooser/39-1
remove gnome-shell-extension-tiling-assistant/32-1
remove gnome-shell-extension-top-icons-plus/27-6
remove gnome-shell-extension-volume-mixer/41.1+dfsg-1
remove gnome-shell-extension-weather/0.0~git20210509.d714eb1-2

Fixed versions of half of those packages are already available, so
if you want to get them back into testing sooner, you could also put
some appropriate age-days on these updated versions:

gnome-shell-extension-bluetooth-quick-connect/26-2
gnome-shell-extension-hamster/0.10.0+git20210628-3
gnome-shell-extension-top-icons-plus/27-7
gnome-shell-extension-volume-mixer/41.1+dfsg-2
gnome-shell-extension-weather/0.0~git20210509.d714eb1-3

but I think removing the broken versions and having the fixed versions
migrate later is going to be a better outcome than having a broken
gnome-shell in testing for a few more days.

I'm preparing a patch for gnome-shell 42 that should prevent a similar
failure mode from happening at the 42 to 43 transition, but we cannot fix
gnome-shell 41 without either testing-proposed-updates or a time machine.

smcv

Bug#1008926: gnome-shell crashes on login with GLib.TimeZone.get_offset JS ERROR

[Simon McVittie]

On Mon, 04 Apr 2022 at 18:44:48 +0900, Kipp Cannon wrote:
> I updated my system to debian testing as of 2022-04-04, after which logging in
> to a gnome desktop session became impossible.
...
> Apr  4 13:24:15 boron gnome-shell[4286]: JS ERROR: TypeError: method
> GLib.TimeZone.get_offset: At least 1 argument required, but only 0
> passed#012_clocksChanged/<@resource:///org/gnome/shell/ui/dateMenu.js:343:46#012_clocksChanged@resource:///org/gnome/shell/ui/dateMenu.js:342:25#012_init@resource:///org/gnome/shell/ui/dateMenu.js:309:14#012WorldClocksSection@resource:///org/gnome/shell/ui/dateMenu.js:275:1#012_init@resource:///org/gnome/shell/ui/dateMenu.js:870:28#012ButtonBox@resource:///org/gnome/shell/ui/panelMenu.js:11:1#012PanelMenuButton@resource:///org/gnome/shell/ui/panelMenu.js:97:4#012DateMenuButton@resource:///org/gnome/shell/ui/dateMenu.js:784:1#012_ensureIndicator@resource:///org/gnome/shell/ui/panel.js:915:25#012_updateBox@resource:///org/gnome/shell/ui/panel.js:926:34#012_updatePanel@resource:///org/gnome/shell/ui/panel.js:871:14#012_init@resource:///org/gnome/shell/ui/panel.js:681:14#012Panel@resource:///org/gnome/shell/ui/panel.js:639:1#012_initializeUI@resource:///org/gnome/shell/ui/main.js:221:13#012start@resource:///org/gnome/shell/ui/main.js:162:5#012@resource:///org/gnome/shell/ui/init.js:6:17

I think the problem here is that older versions of GNOME Shell did not
specify its required version of the GWeather API. When you upgraded some
other package that pulled in gir1.2-gweather-4.0, GNOME Shell started to
load that instead of gir1.2-gweather-3.0, but the newer version has an
incompatible API, causing this crash.

If that's correct, then upgrading to GNOME Shell 42 (from unstable) should
avoid the crash.

smcv

Bug#1006149: linux-image-5.16.0-1-686: Fails to boot on T41 Thinkpads

[Petra R.-P.]

On Mon 04 Apr 2022 at 18:09:59 +0900  Damien Le Moal 
 wrote:
 [...]
> hdparm -I /dev/sdX

,-[ 1st T41 ]-
| netty:~# hdparm -I /dev/sda
|
| /dev/sda:
|
| ATA device, with non-removable media
| Model Number:   IC25N030ATMR04-0
| Serial Number:  MRG2H0KBCYTR8R
| Firmware Revision:  MOAOAD4A
| Standards:
| Used: ATA/ATAPI-6 T13 1410D revision 3a
| Supported: 6 5 4
| Configuration:
| Logical max current
| cylinders   16383   16383
| heads   15  15
| sectors/track   63  63
| --
| CHS current addressable sectors:15481935
| LBAuser addressable sectors:58605120
| Logical/Physical Sector size:   512 bytes
| device size with M = 1024*1024:   28615 MBytes
| device size with M = 1000*1000:   30005 MBytes (30 GB)
| cache/buffer size  = 1740 KBytes (type=DualPortCache)
| Capabilities:
| LBA, IORDY(can be disabled)
| Standby timer values: spec'd by Vendor, no device specific minimum
| R/W multiple sector transfer: Max = 16  Current = 16
| Advanced power management level: 128
| Recommended acoustic management value: 128, current value: 254
| DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 *udma5
|  Cycle time: min=120ns recommended=120ns
| PIO: pio0 pio1 pio2 pio3 pio4
|  Cycle time: no flow control=240ns  IORDY flow control=120ns
| Commands/features:
| Enabled Supported:
|*SMART feature set
| Security Mode feature set
|*Power Management feature set
|*Write cache
|*Look-ahead
|*Host Protected Area feature set
|*WRITE_BUFFER command
|*READ_BUFFER command
|*NOP cmd
|*Advanced Power Management feature set
| Power-Up In Standby feature set
|*SET_FEATURES required to spinup after power up
| Address Offset Reserved Area Boot
| SET_MAX security extension
| Automatic Acoustic Management feature set
|*Device Configuration Overlay feature set
|*Mandatory FLUSH_CACHE
|*SMART error logging
|*SMART self-test
| Security:
| Master password revision code = 65534
| supported
| not enabled
| not locked
| frozen
| not expired: security count
| not supported: enhanced erase
| 26min for SECURITY ERASE UNIT.
| HW reset results:
| CBLID- above Vih
| Device num = 0 determined by the jumper
| Checksum: correct
| netty:~#
`



,-[ 2nd T41 ]-
| negrito:~# hdparm -I /dev/sda
|
| /dev/sda:
|
| ATA device, with non-removable media
| Model Number:   HTS548040M9AT00
| Serial Number:  MRL202L2K9PJ6B
| Firmware Revision:  MG2OA5BA
| Standards:
| Used: ATA/ATAPI-6 T13 1410D revision 3a
| Supported: 6 5 4
| Configuration:
| Logical max current
| cylinders   16383   16383
| heads   16  16
| sectors/track   63  63
| --
| CHS current addressable sectors:16514064
| LBAuser addressable sectors:78140160
| Logical/Physical Sector size:   512 bytes
| device size with M = 1024*1024:   38154 MBytes
| device size with M = 1000*1000:   40007 MBytes (40 GB)
| cache/buffer size  = 7877 KBytes (type=DualPortCache)
| Capabilities:
| LBA, IORDY(can be disabled)
| Standby timer values: spec'd by Vendor, no device specific minimum
| R/W multiple sector transfer: Max = 16  Current = 16
| Advanced power management level: 192
| Recommended acoustic management value: 128, current value: 254
| DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 *udma5
|  Cycle time: min=120ns recommended=120ns
| PIO: pio0 pio1 pio2 pio3 pio4
|  Cycle time: no flow control=240ns  IORDY flow control=120ns
| Commands/features:
| Enabled Supported:
|*SMART feature set
| Security Mode feature set
|*Power Management feature set
|*Write cache
|*Look-ahead
|*Host Protected Area feature set
|*WRITE_BUFFER command
|*READ_BUFFER command
|*NOP cmd
|*Advanced Power Management feature set
| Power-Up In Standby feature set
|*SET_FEATURES required to 

Bug#1008926: gnome-shell crashes on login with GLib.TimeZone.get_offset JS ERROR

[Kipp Cannon]

Package: gnome-shell
Version: 41.4-1
Severity: important
X-Debbugs-Cc: k...@resceu.s.u-tokyo.ac.jp

Dear Maintainer,

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

   * What led up to the situation?

I updated my system to debian testing as of 2022-04-04, after which logging in
to a gnome desktop session became impossible.

The following sequence of message in /var/log/user.log appears to point to the
culprit, but I might be mistaken.

Apr  4 13:24:15 boron gnome-shell[4286]: JS ERROR: TypeError: method
GLib.TimeZone.get_offset: At least 1 argument required, but only 0
passed#012_clocksChanged/<@resource:///org/gnome/shell/ui/dateMenu.js:343:46#012_clocksChanged@resource:///org/gnome/shell/ui/dateMenu.js:342:25#012_init@resource:///org/gnome/shell/ui/dateMenu.js:309:14#012WorldClocksSection@resource:///org/gnome/shell/ui/dateMenu.js:275:1#012_init@resource:///org/gnome/shell/ui/dateMenu.js:870:28#012ButtonBox@resource:///org/gnome/shell/ui/panelMenu.js:11:1#012PanelMenuButton@resource:///org/gnome/shell/ui/panelMenu.js:97:4#012DateMenuButton@resource:///org/gnome/shell/ui/dateMenu.js:784:1#012_ensureIndicator@resource:///org/gnome/shell/ui/panel.js:915:25#012_updateBox@resource:///org/gnome/shell/ui/panel.js:926:34#012_updatePanel@resource:///org/gnome/shell/ui/panel.js:871:14#012_init@resource:///org/gnome/shell/ui/panel.js:681:14#012Panel@resource:///org/gnome/shell/ui/panel.js:639:1#012_initializeUI@resource:///org/gnome/shell/ui/main.js:221:13#012start@resource:///org/gnome/shell/ui/main.js:162:5#012@resource:///org/gnome/shell/ui/init.js:6:17
Apr  4 13:24:15 boron gnome-shell[4286]: Execution of main.js threw exception:
Module resource:///org/gnome/shell/ui/init.js threw an exception
Apr  4 13:24:15 boron gnome-shell[4286]: Attempting to call back into JSAPI
during the sweeping phase of GC. This is most likely caused by not destroying a
Clutter actor or Gtk+ widget with ::destroy signals connected, but can also be
caused by using the destroy(), dispose(), or remove() vfuncs. Because it would
crash the application, it has been blocked and the JS callback not invoked.
Apr  4 13:24:15 boron gnome-shell[4286]: The offending signal was destroy on
Gjs_ui_dateMenu_DateMenuButton 0x564d79ae6870.
Apr  4 13:24:15 boron gnome-shell[4286]: Attempting to call back into JSAPI
during the sweeping phase of GC. This is most likely caused by not destroying a
Clutter actor or Gtk+ widget with ::destroy signals connected, but can also be
caused by using the destroy(), dispose(), or remove() vfuncs. Because it would
crash the application, it has been blocked and the JS callback not invoked.
Apr  4 13:24:15 boron gnome-shell[4286]: The offending signal was destroy on
Gjs_ui_dateMenu_MessagesIndicator 0x564d79af39b0.
Apr  4 13:24:15 boron gdm3: Gdm: GdmDisplay: Session never registered, failing


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

the computer can only be used by not using gnome on wayland, e.g., using an
older metacity based gnome classic session.

   * 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')
Architecture: amd64 (x86_64)

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

Versions of packages gnome-shell depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.40.0-3
ii  evolution-data-server3.44.0-3
ii  gir1.2-accountsservice-1.0   22.07.5-1
ii  gir1.2-atk-1.0   2.36.0-3
ii  gir1.2-atspi-2.0 2.44.0-3
ii  gir1.2-gcr-3 3.40.0-4
ii  gir1.2-gdesktopenums-3.0 42.0-1
ii  gir1.2-gdkpixbuf-2.0 2.42.8+dfsg-1
ii  gir1.2-gdm-1.0   42.0-1
ii  gir1.2-geoclue-2.0   2.5.7-3
ii  gir1.2-glib-2.0  1.72.0-1
ii  gir1.2-gnomebluetooth-1.03.34.5-7
ii  gir1.2-gnomedesktop-3.0  42.0-1
ii  gir1.2-graphene-1.0  1.10.8-1
ii  gir1.2-gstreamer-1.0 1.20.1-1
ii  gir1.2-gtk-3.0   3.24.33-1
ii  gir1.2-gtk-4.0   4.6.2+ds-1
ii  gir1.2-gweather-3.0  40.0-5
ii  gir1.2-ibus-1.0  1.5.26-2
ii  gir1.2-mutter-9  41.4-1
ii  gir1.2-nm-1.01.36.4-1
ii  gir1.2-nma-1.0   1.8.36-1
ii  gir1.2-pango-1.0 1.50.6+ds-1
ii  

Bug#1008919: phoc: Qt applications no longer receive any input

[Guido Günther]

control: tags -1 +patch

Hi,
On Mon, Apr 04, 2022 at 10:49:45AM +0200, Salvo 'LtWorf' Tomaselli wrote:
> https://gitlab.gnome.org/World/Phosh/phoc/-/issues/261

The above also links to a patch that fixes this.

Cheers,
 -- Guido

Bug#1008925: pytorch-vision FTBFS with Python 3.10 due to X-Python3-Version: 3.9

[Adrian Bunk]

Source: pytorch-vision
Version: 0.8.2-1
Severity: serious
Tags: ftbfs bookworm sid

https://buildd.debian.org/status/logs.php?pkg=pytorch-vision=0.8.2-1%2Bb3

...
dh clean -Spybuild --with python3
   dh_auto_clean -O-Spybuild
I: pybuild base:237: python3.9 setup.py clean 
Traceback (most recent call last):
  File "/<>/setup.py", line 12, in 
import torch
  File "/usr/lib/python3/dist-packages/torch/__init__.py", line 213, in 
raise ImportError(textwrap.dedent('''
ImportError: Failed to load PyTorch C extensions:
It appears that PyTorch has loaded the `torch/_C` folder
of the PyTorch repository rather than the C extensions which
are expected in the `torch._C` namespace. This can occur when
using the `install` workflow. e.g.
$ python setup.py install && python -c "import torch"

This error can generally be solved using the `develop` workflow
$ python setup.py develop && python -c "import torch"  # This should 
succeed
or by running Python from a different directory.
E: pybuild pybuild:367: clean: plugin distutils failed with: exit code=1: 
python3.9 setup.py clean 
dh_auto_clean: error: pybuild --clean -i python{version} -p 3.9 returned exit 
code 13
make: *** [debian/rules:6: clean] Error 25


https://sources.debian.org/src/pytorch-vision/0.8.2-1/debian/control/#L28

Bug#1008924: pytorch-text FTBFS with Python 3.10 due to X-Python3-Version: 3.9

[Adrian Bunk]

Source: pytorch-text
Version: 0.8.1-1
Severity: serious
Tags: ftbfs bookworm sid

https://buildd.debian.org/status/logs.php?pkg=pytorch-text=0.8.1-1%2Bb2

...
   dh_auto_clean -O-Spybuild
I: pybuild base:237: python3.9 setup.py clean 
Traceback (most recent call last):
  File "/<>/setup.py", line 10, in 
from build_tools import setup_helpers
  File "/<>/build_tools/setup_helpers/__init__.py", line 1, in 

from .extension import *  # noqa
  File "/<>/build_tools/setup_helpers/extension.py", line 6, in 

from torch.utils.cpp_extension import (
  File "/usr/lib/python3/dist-packages/torch/__init__.py", line 213, in 
raise ImportError(textwrap.dedent('''
ImportError: Failed to load PyTorch C extensions:
It appears that PyTorch has loaded the `torch/_C` folder
of the PyTorch repository rather than the C extensions which
are expected in the `torch._C` namespace. This can occur when
using the `install` workflow. e.g.
$ python setup.py install && python -c "import torch"

This error can generally be solved using the `develop` workflow
$ python setup.py develop && python -c "import torch"  # This should 
succeed
or by running Python from a different directory.
E: pybuild pybuild:367: clean: plugin distutils failed with: exit code=1: 
python3.9 setup.py clean 
dh_auto_clean: error: pybuild --clean -i python{version} -p 3.9 returned exit 
code 13
make: *** [debian/rules:4: clean] Error 25


https://sources.debian.org/src/pytorch-text/0.8.1-1/debian/control/#L28

Bug#1008923: please update libsocket-wrapper to a more recent version (1.3.3)

[Michael Tokarev]

Package: libsocket-wrapper
Version: 1.2.5-1
Severity: minor
X-Debbugs-Cc: pkg-samba-ma...@lists.alioth.debian.org

Current samba (4.16) testsuite requires soket-wraper to be >= 1.3.3,
so it fails right at the configure stage. I'll try to quickly update
the package locally to see how it goes, but it would be really nice
to have it in debian already.

Thanks!

/mjt

Bug#1008922: pytorch-audio FTBFS due to X-Python3-Version: 3.9

[Adrian Bunk]

Source: pytorch-audio
Version: 0.7.2-1
Severity: serious
Tags: ftbfs bookworm sid

https://buildd.debian.org/status/logs.php?pkg=pytorch-audio=0.7.2-1%2Bb3

...
I: pybuild base:237: python3.9 setup.py clean 
Traceback (most recent call last):
  File "/<>/setup.py", line 9, in 
from build_tools import setup_helpers
  File "/<>/build_tools/setup_helpers/__init__.py", line 1, in 

from .extension import *  # noqa
  File "/<>/build_tools/setup_helpers/extension.py", line 6, in 

from torch.utils.cpp_extension import (
  File "/usr/lib/python3/dist-packages/torch/__init__.py", line 213, in 
raise ImportError(textwrap.dedent('''
ImportError: Failed to load PyTorch C extensions:
It appears that PyTorch has loaded the `torch/_C` folder
of the PyTorch repository rather than the C extensions which
are expected in the `torch._C` namespace. This can occur when
using the `install` workflow. e.g.
$ python setup.py install && python -c "import torch"

This error can generally be solved using the `develop` workflow
$ python setup.py develop && python -c "import torch"  # This should 
succeed
or by running Python from a different directory.
E: pybuild pybuild:367: clean: plugin distutils failed with: exit code=1: 
python3.9 setup.py clean 
dh_auto_clean: error: pybuild --clean -i python{version} -p 3.9 returned exit 
code 13
make: *** [debian/rules:5: clean] Error 25



https://sources.debian.org/src/pytorch-audio/0.7.2-1/debian/control/#L25

Bug#1008921: verilator: Verilator is outdated

[Gonsolo]

Package: verilator
Version: 4.038-1
Severity: normal
X-Debbugs-Cc: gons...@gmail.com

Dear Maintainer,

   * What led up to the situation?

   I tried to play around with https://github.com/llvm/circt.

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

Compile PyCDE from Circt.

   * What was the outcome of this action?

   The following error: "CIRCT only supports Verilator version 4.110 and up.  
Found version: 4.038."

   * What outcome did you expect instead?

   Working PyCDE.


  The actual version of verilator at https://github.com/verilator is
  v4.220, the one in Debian is 4.038.1 from 2020.

-- System Information:
Debian Release: 11.0
  APT prefers impish-updates
  APT policy: (500, 'impish-updates'), (500, 'impish-security'), (500, 
'impish'), (100, 'impish-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.13.0-39-lowlatency (SMP w/24 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages verilator depends on:
ii  libc6  2.34-0ubuntu3.2

Versions of packages verilator recommends:
ii  libsystemc-dev  2.3.3-5

Versions of packages verilator suggests:
pn  gtkwave  

-- no debconf information

Bug#1008920: Versions table not rebuilt after latest Buster 10.2 point release

[Moritz Muehlenhoff]

Package: tracker.debian.org
Severity: normal

The last point release for buster updated various packages. The packages
updated as part of the release are showing up under "news", but the respective
versions are not updated in the "versions" table on the left.

And likewise for "versioned links". Two examples:

cups 2.2.10-6+deb10u5:
https://tracker.debian.org/pkg/cups

openssl 1.1.1n-0+deb10u1
https://tracker.debian.org/pkg/openssl

Cheers,
Moritz

Bug#1008744: ITP: mercurial-evolve -- This package provides the "evolve" extension for the Mercurial DVCS.

[Georges Racinet]

On 3/31/22 18:37, Georges Racinet wrote:

Package: wnpp
Severity: wishlist
Owner: Georges Racinet 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-pyt...@lists.debian.org

* Package name: mercurial-evolve
   Version : 10.5.0
   Upstream Author : Pierre-Yves David 
* URL : https://www.mercurial-scm.org/doc/evolution/
* License : GPLv2+
   Programming Lang: Python
   Description : evolve extension for Mercurial

  This package provides the experimental "evolve" extension for the Mercurial
  DVCS.
  .
  This extension provides several commands to mutate history and deal with 
issues
  it may raise.

There is an old RFP about this: #926398

The "evolve" and "topic" extensions have become central in many modern
Mercurial usages. The first exposes the core primitives for history
mutation (aka changeset obsolescence) in an user-friendly way, the
second provides volatile feature branches and handle them with evolve.

The upstream source repository already contains a debian/ subdirectory,
which various people have been using to generate a mercurial-evolve
package. It would probably be a good idea to provide the same content,
if the policy allows it. The above long description is the one given
in this existing packaging effort.

The corresponding project name on PyPI is hg-evolve, and also contains the
"topic", "pullbundles" and "serverminitopic" extensions.
The latter two are made of a single file.

I plan to maintain this package under the umbrella of the Debian Python
Team. As long as this is a pure Python package, upgrades should be
fairly simple.

I have a working prototype at https://salsa.debian.org/gracinet/mercurial-evolve
(feedback most welcome).
As far as I understand, I have enough rights to move it directly under
python-team/packages, but I will need a sponsor for the actual uploading.

This is my first actual packaging attempt, I would appreciate mentorship
and especially indications about the next steps.

I have been working upstream to unvendor the cbor library, the needed 
changes should be released with version 10.5.1.


Reference: https://foss.heptapod.net/mercurial/evolve/-/merge_requests/432

--
Georges Racinet
https://octobus.net, https://heptapod.net
GPG: BF5456F4DC625443849B6E58EE20CA44EF691D39, sur serveurs publics

Bug#1003907: fails to successfully associate

[Michael Biebl]

On Fri, 25 Mar 2022 07:07:03 +0900 Masashi Honma 
 wrote:

> Masashi, if I understand you correctly, you argue that this is an issue
> with the AP (or its firmware).

> If so, should the company AVM be contacted about this?
> I'm afraid I'm not too knowledgeable in that regard.

Michael, Hans-Peter Jansen already reported to AVM at 2022-02-06
(https://bugzilla.opensuse.org/show_bug.cgi?id=1195395).

According to his latest comment,
"Just a heads up: AVM is still investigating on this. Some tests with
newer hardware confirmed, that WPA3 is working well there."



I contacted the AVM support in the mean time as well. Unfortunately they 
were quite dismissive and didn't really acknowledge the problem. The 
support ticked was closed subsequently. I didn't further pursue this route.


That said, there might be a workaround available in NetworkManager
I filed 
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/964 
and a potential fix is now available in


https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1175

Thanks Beniamino and Thomas!


Andrew, could we keep this bug report at RC until we have a fix?
Even if the fix means a workaround in NM.

Regards,
Michael


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1006149: linux-image-5.16.0-1-686: Fails to boot on T41 Thinkpads

[Petra R.-P.]

Am Mo.,  4. Apr. 2022, um 10:05 +0200 schrieb Axel Beckert :
[...]
> "fdisk -l /dev/sda" should suffice.


,-[ 1st T41 ]---
| ~ > fdisk -l /dev/sda
| Disk /dev/sda: 27.95 GiB, 30005821440 bytes, 58605120 sectors
| Disk model: IC25N030ATMR04-0
| 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: 0xcaef08be
|
| Device BootStart  End  Sectors  Size Id Type
| /dev/sda1  *  63 56098979 56098917 26.8G 83 Linux
| /dev/sda2   56098980 58605119  2506140  1.2G  5 Extended
| /dev/sda5   56099043 58605119  2506077  1.2G 82 Linux swap / Solaris
| ~ >
`--


,-[ 2nd T41 ]---
| ~ > fdisk -l /dev/sda
| Disk /dev/sda: 37.26 GiB, 40007761920 bytes, 78140160 sectors
| Disk model: HTS548040M9AT00
| 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: 0x000942b7
|
| Device BootStart  End  Sectors  Size Id Type
| /dev/sda1  *  63 75119939 75119877 35.8G 83 Linux
| /dev/sda2   75119940 78140159  3020220  1.4G  5 Extended
| /dev/sda5   75120003 78140159  3020157  1.4G 82 Linux swap / Solaris
| ~ >
`--

 Looks rather "no name" to me ...

  Petra

Bug#1008919: phoc: Qt applications no longer receive any input

[Salvo 'LtWorf' Tomaselli]

Package: phoc
Version: 0.13.0-1
Severity: critical
Tags: upstream
Justification: breaks unrelated software
X-Debbugs-Cc: tipos...@tiscali.it

Dear Maintainer,

I'm reporting this from my desktop, so ignore all the attached info by 
reportbug.


After the last upgrade of phoc, any qt applications do not receive mouse input 
from
the touchscreen.

explosive-c4, parolottero are thus unplayable

telegram-desktop is unusable

The issue gets solved by downgrading phoc.


https://gitlab.com/mobian1/issues/-/issues/428

https://gitlab.gnome.org/World/Phosh/phoc/-/issues/261

I open this issue so people who haven't upgraded yet will be warned by 
apt-listbugs about this.

Thanks for your work, best.

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

Kernel: Linux 5.16.0-5-amd64 (SMP w/8 CPU threads; PREEMPT)
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 phoc depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.40.0-3
ii  gsettings-desktop-schemas42.0-1
ii  libc62.33-7
ii  libglib2.0-0 2.72.0-1
pn  libgnome-desktop-3-19
ii  libinput10   1.20.0-1
ii  libpixman-1-00.40.0-1
ii  libwayland-server0   1.20.0-1
pn  libwlroots10 
ii  libxcb1  1.14-3
ii  libxkbcommon01.4.0-1
pn  mutter-common

Versions of packages phoc recommends:
pn  phosh  

phoc suggests no packages.

Bug#1006149: linux-image-5.16.0-1-686: Fails to boot on T41 Thinkpads

[Axel Beckert]

Hi Petra,

Petra R.-P. wrote:
> Sorry for the stupid question, but:  How can I find out?
> What command shall I enter?

"fdisk -l /dev/sda" should suffice.

Look for a line like this:

  Disk model: SAMSUNG HM160HC

It's the second line of output in my case.

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

Bug#1006149: linux-image-5.16.0-1-686: Fails to boot on T41 Thinkpads

[Petra R.-P.]

Am Mo.,  4. Apr. 2022, um 16:39 +0900 schrieb Damien Le Moal 
:
[...]
> By the way, what is the drive connected on your Thinkpad ? Same as Axel, a
> Samsung HM160HC ? If it is a different drive, then patch 2 (big hammer) may
> be better as this may indicate that the adapter does not like read log
> commands...

Sorry for the stupid question, but:  How can I find out?
What command shall I enter?
What part of the output are you interested in?

   Petra

Bug#986856: RFP: dangerzone -- Take potentially dangerous PDFs, office documents, or images and convert them to a safe PDF

[Peymaneh]

Hi,

excuse the long silence!
I have packaged the latest version and I believe it is in a good state.

@Kunal
Would you mind having a look at it? This is my first package including 
post{inst,rm}-scripts and I am not sure if the way i did it is very robust.


I have uploaded the package on salsa[1] and am also asking for feedback 
on the mentors list.


For context:
For the new version upstream has decided to include build a whole 
Container-Image at build time and include the 700MB image in the .deb 
package. The absurd package size set aside, building the image on the 
Debian build servers would not be possible because a network connection 
is required for pulling the docker image.
My dangerzone.postinst is basically the build-script from upstream[2] 
only with some very basic error-handling added to it.


Kind regards,
Peymaneh


[1] https://salsa.debian.org/peymaneh/dangerzone
[2] 
https://salsa.debian.org/peymaneh/dangerzone/-/blob/53d3e5b75e7d97fb77f09e45db57195a8aa4ed7d/install/linux/build-image.sh


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1006149: linux-image-5.16.0-1-686: Fails to boot on T41 Thinkpads

[Axel Beckert]

Hi Damien,

Damien Le Moal wrote:
> > My T41 Thinkpads only have 500MB of ram and little space left on
> > their hd.  Added to that my inexperience and lack of time I'm
> > afraid I cannot be of much help for re-compiling kernels (which
> > AFAIK is quite a stress test for computers).
> > Sorry.
> > 
> >  Petra
> 
> OK. We just need to find a Debian user volunteer for this :)
> 
> Anyone ?

I'm on it. Still installing build-dependencies...

> I can always build a generic .deb from kernel source if needed, but not sure
> what patch sets the debian kernel adds, if any.

Might help for Petra. But I can also provide my .deb once its built.

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

Bug#1008918: unbound: New upstream version

[Joel Stanley]

Source: unbound
Version: 1.13.1-1
Severity: normal

Dear Maintainer,

I've been noticing segfaults in unbound on an internet facing server
running 1.13.1-1 on Debian stable. When hunting around for similar bug
reports I noticed there's since been a few new releases.

I took a stab at updating the packaging and I'm running this version
now:

 https://github.com/shenki/unbound-debian

It's been stable for a few weeks now. Please consider uploading the
latest version to unstable.

Bug#1008798: gdcm: FTBFS on s390x

[Mathieu Malaterre]

Control: fixed -1 3.0.12-1

Fixed in latest upload

Bug#1008356: GenABEL fails to build (Was: Bug#1008356: r-cran-genabel: FTBFS: fexact.c:1025:13: error: ‘PROBLEM’ undeclared (first use in this function))

[Andreas Tille]

Control: tags -1 upstream
Control: forwarded -1 yu...@bionet.nsc.ru
Control: tags -1 pending

Hi,

the Debian packaged version of GenABEL received a bug report once we
switched from R 4.1.2 to 4.1.3  The following patch solves this issue:

   
https://salsa.debian.org/r-pkg-team/r-cran-genabel/-/blob/master/debian/patches/fix_PROBLEM.patch

Kind regards

 Andreas.

Am Sat, Mar 26, 2022 at 09:47:51PM +0100 schrieb Lucas Nussbaum:
> Source: r-cran-genabel
> Version: 1.8-0-5
> Severity: serious
> Justification: FTBFS
> Tags: bookworm sid ftbfs
> User: lu...@debian.org
> Usertags: ftbfs-20220326 ftbfs-bookworm
> 
> Hi,
> 
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
> 
> 
> Relevant part (hopefully):
> > gcc -I"/usr/share/R/include" -DNDEBUG  -fpic  -g -O2 
> > -ffile-prefix-map=/build/r-base-yTleYq/r-base-4.1.3.20220324=. 
> > -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
> > -D_FORTIFY_SOURCE=2 -g  -c fexact.c -o fexact.o
> > fexact.c: In function ‘f3xact’:
> > fexact.c:1025:13: error: ‘PROBLEM’ undeclared (first use in this function)
> >  1025 | PROBLEM "Bug in FEXACT: gave negative key" 
> > RECOVER(NULL_ENTRY);
> >   | ^~~
> > fexact.c:1025:13: note: each undeclared identifier is reported only once 
> > for each function it appears in
> > fexact.c:1025:20: error: expected ‘;’ before string constant
> >  1025 | PROBLEM "Bug in FEXACT: gave negative key" 
> > RECOVER(NULL_ENTRY);
> >   |^~~
> >   |;
> > fexact.c: In function ‘prterr’:
> > fexact.c:1806:5: error: ‘PROBLEM’ undeclared (first use in this function)
> >  1806 | PROBLEM "FEXACT error %d.\n%s", icode, mes RECOVER(NULL_ENTRY);
> >   | ^~~
> > fexact.c:1806:12: error: expected ‘;’ before string constant
> >  1806 | PROBLEM "FEXACT error %d.\n%s", icode, mes RECOVER(NULL_ENTRY);
> >   |^~~
> >   |;
> > make[1]: *** [/usr/lib/R/etc/Makeconf:168: fexact.o] Error 1
> 
> 
> The full build log is available from:
> http://qa-logs.debian.net/2022/03/26/r-cran-genabel_1.8-0-5_unstable.log
> 
> A list of current common problems and possible solutions is available at
> http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!
> 
> If you reassign this bug to another package, please marking it as 
> 'affects'-ing
> this package. See https://www.debian.org/Bugs/server-control#affects
> 
> If you fail to reproduce this, please provide a build log and diff it with 
> mine
> so that we can identify if something relevant changed in the meantime.
> 
> ___
> R-pkg-team mailing list
> r-pkg-t...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/r-pkg-team

-- 
http://fam-tille.de

Bug#1006149: linux-image-5.16.0-1-686: Fails to boot on T41 Thinkpads

[Petra R.-P.]

Just for the record:

On Mon 04 Apr 2022 at 14:49:05 +0900  Damien Le Moal 
 wrote:
[...]
> There will be no issue with your 1GB of ram. Giving this amount of ram and
> CPU, step (4) will indeed take a while, but it will run fine.

My T41 Thinkpads only have 500MB of ram and little space left on
their hd.  Added to that my inexperience and lack of time I'm
afraid I cannot be of much help for re-compiling kernels (which
AFAIK is quite a stress test for computers).
Sorry.

Petra

Bug#1008916: [gnome-online-accounts] invalidated credentials

[Lyndon Brown]

Package: gnome-online-accounts
Version: 3.44.0-1
Severity: serious

Please forgive me if I try to block the migration to testing
temporarily.

Some days ago when the big Gnome v42 update was pushed, for some reason
it invalidated the gmail credentials on both my machine and my mother's
(which I also have running Sid - please don't criticise). Whilst I was
able to log back into my own accounts, since I have 2FA and such
properly set up, my mother's primary account unfortunately was in a
much poorer state, and she is being blocked from regaining access to
her account by an impassible verification page, both in g-o-a and when
trying to alternatively log in via a web browser.

She is desperate to recover her gmail account and will be bringing her
computer over to me to look at within the next couple of days if things
go to plan. I intend to try downgrading g-o-a/evolution packages to
testing versions to see if the existing stored credentials will work
once more under those previous versions. If so then perhaps this may
help allow her to login through a webpage to set up better verification
info, or at least migrate the contents of her account to a new one.

Bug#1001661: Info received (Bug#1001661: Info received ((no subject)))

[nick black]

wait...even the most recent of these logs shows that it is
testing notcurses 3.0.4, which indeed had this timing problem on
input, which was fixed in notcurses 3.0.5:

Get:1 http://deb.debian.org/debian testing/main notcurses 3.0.4+dfsg.1-1 (dsc) 
[3,148 B]   

 
Get:2 http://deb.debian.org/debian testing/main notcurses 3.0.4+dfsg.1-1 (tar) 
[7,391 kB]  

 
Get:3 http://deb.debian.org/debian testing/main notcurses 3.0.4+dfsg.1-1 (asc) 
[833 B] 

 
Get:4 http://deb.debian.org/debian testing/main notcurses 3.0.4+dfsg.1-1 (diff) 
[17.1 kB] 

but apt-show-versions confirms only 3.0.7 in the archive:

[schwarzgerat](0) $ apt-show-versions -a notcurses-bin
notcurses-bin:amd64 3.0.7+dfsg.1-1 install ok installed
No stable version
No testing version
notcurses-bin:amd64 3.0.7+dfsg.1-1 unstable ftp.us.debian.org
No experimental version
notcurses-bin:amd64/unstable 3.0.7+dfsg.1-1 uptodate
[schwarzgerat](0) $

oh, i guess "No testing version" indicates it's gone from
testing. so why isn't 3.0.7 in unstable the candidate for
testing? 3.0.4 is definitely known to be bad.

Bug#1001661: Info received ((no subject))

[nick black]

i'm tracking this upstream at 
https://github.com/dankamongmen/notcurses/issues/2645

Bug#1001661: notcurses: flaky autopkgtests on armhf

[nick black]

i'm pretty sure raspberry pi is armhf, so i ought be able to dig
that one RPi4 i've got up and explore this. if we can reproduce
the problem interactively, it ought fall pretty quickly.

Bug#1008915: BTS: setting to "notfound" doesn't work correctly

[Ole Streicher]

Package: bugs.debian.org
Severity: important
Control: affects -1 src:astropy

Dear bugs.d.o maintainer,

I had a bug [1] in the "astropy" source package that was fixed by a new 
upload. Since I forgot to mention the bug id, I resolved the bug with a 
mail to BTS (see attachment 1), making the mistake to use the wrong 
source package name (python-astropy instead of astropy). This was 
corrected with a subsequent mail (see attachment 2), which mentions that 
the error is not found in astropy (and the correct version). However, 
the BTS answered


Ignoring request to alter found versions of bug #1008441 to the same 
values previously set


and refused to set the bug fixed (Attachment 3). To me, this looks as 
the "notfound" algorithm doesn't compare the (explicitly given) source 
package name, but just the version number. This is obviously a bug.


Best regards

Ole


[1] https://bugs.debian.org/1008441--- Begin Message ---

Source: python-astropy
Source-Version: 5.0.2-2

This is fixed with the just-uploaded new release; I just forgot to mention
it in the changelog.

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Sun, 27 Mar 2022 12:25:58 +0200
Source: astropy
Architecture: source
Version: 5.0.2-2
Distribution: unstable
Urgency: medium
Maintainer: Debian Astronomy Maintainers 

Changed-By: Ole Streicher 
Changes:
 astropy (5.0.2-2) unstable; urgency=medium
 .
   * Update WCSLIB support to version 7.9
Checksums-Sha1:
 e52c1b0cc45c4bf3691a04486123955abb1e3a03 3069 astropy_5.0.2-2.dsc
 61707b00be06940605475740f1a2f34aa5410caf 27800 astropy_5.0.2-2.debian.tar.xz
Checksums-Sha256:
 b1e524e5ad9ca56bec95f31e82180a7c868448fe2c08214cfd8c24db11fa01ba 3069 
astropy_5.0.2-2.dsc
 5572895eecddef912f6c917e732d0d706562e42991531a29987320967bdc79cb 27800 
astropy_5.0.2-2.debian.tar.xz
Files:
 947410bcd02f6caad2c8f7102f0fd7a0 3069 python optional astropy_5.0.2-2.dsc
 1f71160e24823d760b03cf3a0336d5fe 27800 python optional 
astropy_5.0.2-2.debian.tar.xz

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEuvxshffLFD/utvsVcRWv0HcQ3PcFAmJAStkACgkQcRWv0HcQ
3PfUlA//Z8xpMvVDqJVpoPQuU8Zs+dU/V6u9YiYOa6tum/CsWrl0HXuH6E6Axful
zi2Zy2g/ww0gzmKaQxtTA6bVRpwqNknOwvkpjx043arj1AZOJt2jOIfp9ICM6xRT
GpLw54w8qwmCT7RVdzgG6BZ+MWF/CHsj2Z15EoOATdwrvQizwnKXBUZVPdFiDq22
2Fs0Mbs2fm+P6JjIJGKjwsm0PfJOo569imuD4DfGZjCvznExsKhnnZXo2TltGHDL
8hFxXuulpPly7sZcpWIx4BIZblHyTZBXgtDg5GobVCOdnhxPn0xF34TY91IDC1aa
BkCbKRxWq4FPYLhLcCOioeqatuL44OLxbyp+nfSf0UmIK/afeNEj1M5lgn+9woZK
0ipnh87VcYzvmuwmxQogEo0Kc+9/LocZtP4r3c6mZSN8/ubbpvt9QqfjuGXDg4FE
pm7oYT+COqahFwts6EvVGnALUQ1nLoz11vcmBcXP4KZcj/jaNbYiznXw/1dmsrIg
SV5gbdutokUZt8Y/GRieCVE4rH2feJkR640SgRMRqluEGYV9rhPMDujY7mnjfrGH
ep30yotx6I/9SiCcA14l2UtmiZ7fxjev1OGAUQIXULXBi5KNdKOa61wiXGsIvkYg
fcQ1vzGe5whsDgtehxKYowIJVPC+WFODksCvNnthcxP53Jv77WI=
=IhXl
-END PGP SIGNATURE End Message ---
--- Begin Message ---

notfound 1008441 astropy/5.0.2-2
thanks--- End Message ---
--- Begin Message ---
Processing commands for cont...@bugs.debian.org:

> notfound 1008441 astropy/5.0.2-2
Bug #1008441 {Done: Ole Streicher } [src:astropy] astropy: 
FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p 
"3.10 3.9" returned exit code 13
Ignoring request to alter found versions of bug #1008441 to the same values 
previously set
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
1008441: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1008441
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

--- End Message ---