Bug#1021235: python-pymeasure: please switch to QtWidgets.QTreeWidgetItem

[Gianfranco Costamagna]

Source: python-pymeasure
Version: 0.9.0-1
Severity: serious

Hello, I noticed there is also a 0.10.0 version, but probably in order to fix 
autopkgtests/build against new python-pyqtgraph
some additional patches are needed, e.g.
4d35e9eebb548453867b4c562a80eb5851918186
fcd8df95e9f1da17c87917c64f3f5abf96a9aa3d
7014231851cf731aa253c41da9e6e38abfd81ead
26f8bdbf236527bbe3c1800f37ccbe1e6be8b841
ee586f4f5ee0fba1b77d48f3052549b99f520324


Sorry for breaking your package in sid, I didn't know there was this 
reverse-dependency when I uploaded.

G.

Bug#1021140: vlc: No video when "Integrate video in interface" is enabled

[KeyofBlueS]

Yes. At the time to reporting this, #1021032 had issue on mp4 videos only, so
I thought it was a complete different problem here.

In any case vlc 3.0.17.4-5 solves this issue so it can be now closed.

Thanks.

Bug#1021234: librust-gtk4-sys-dev: uninstallable

[Jonas Smedegaard]

Package: librust-gtk4-sys-dev
Version: 0.3.1-1+b1
Severity: grave
Justification: renders package unusable

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Package is uninstallable: depends on missing librust-system-deps-3+default-dev

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmM7uiYACgkQLHwxRsGg
ASE+Mg//WX8RPN+9bsfRs7rlx2UOXZxkXiNoL3lkLPaKMnnTyY0c7MK98MUOBiDp
yjRkrhDtShvUogKJ9mxfAgqD4WYhjXha9Duej322mGvB+QEEaMXnLyhRDJ8Tv5M+
QNeBbyAPHQKrPXwSXDpf3ytpmzJxVGh5zRhbKZLwXxnnIr4Fb+rsfhEhPaDeybjz
RVLRW8+BBjRtzObMknx+RIw+iI2EtTu4uflEKqfGqALIYiedT9BYULoIYUMr2np0
+0qcRAB8FXHo0QfXb9+oFbsRN0J95JVzjHmXlOz0TKr6Kigd7rjY2MLa8QGtbmNf
/MudsFAJNQB3jC/zQnFegAPmDrADgX+bfHIktxNclqRxcco7LUCF4AOXlvFKgXvm
QJ+Imx0nVLglKsJdgvTLAwFwYHorKqgtgaejrZ5u/MjIdoI0MD2eIYpHBZMibO3p
61jSF3RXoOVKlbwpv1NzFQIe1xQG+7Sam9e0jjBwFjP2kRwbAuFkRhZdFJK2+wRd
kH9EwfzT4zug21rWiPNSUrUJhs/molpzzBH2wPZ+WTi8DNdF1sCReaA4I0rPio5X
hZl2L1aIffSnqPDXJNf8wEqI6W+WO0S9PEP/o+ehdptDol+RhG/iHdB/DZBs4PEL
S014jOOKd29m0w5nlZwGB1kjn4tpaIrDR2/pA52U2CYLRMRZAFI=
=q2vb
-END PGP SIGNATURE-

Bug#1021233: librust-gsk4-sys-dev: uninstallable

[Jonas Smedegaard]

Package: librust-gsk4-sys-dev
Version: 0.3.1-1+b1
Severity: grave
Justification: renders package unusable

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Package is uninstallable: depends on missing librust-system-deps-3+default-dev

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmM7ueEACgkQLHwxRsGg
ASEy5A//WegyNEHMRDKgii15c0JiYqk0uC59SB/FRITDzweTaCLy0wc9ZrE5bfIg
NiE5lWIWvZngBqAl45Cw5Mm3C3Y4ni2IrpA+Kh/Oiav5pY0eQBEbSfqC40xVyFXY
LYbyVg4sR9Qq+IAX/S0ab5sPmCBjxu/BmqyY6Yq87nDpOInm7ap7oKX7EPf84DxM
jgJUV/dRqAScJRLH3OPm9UvQ9ApUUDz5sAE6LPwigSkbtcMswOUwND/Ebr6Ym6/W
8JkrXSHIQC1yASzs98w0QPXO5ixgO+HHW/oyd/Pjhyg2b702YkTsqEngCbF0kk6F
/lcyrT/T0hpfJvrxaR7f0js6T3D89WFL5FIw3+K7YzRwM/o6sLgsVsoRZJtne0cS
CNMZOXWEO8+BhRFgL0nAij2kSCAnsyPwWRFiDYUoxl7cTYfwkj8Eq22PyVxa+RMX
HDHEaI6c0w11xMay1dgCUVBRE2ywtNRkOnUh7sCZ3O4vNvdQ6fRXi7uSmMnR26dD
c80weUu1cPnh5fid7w9SCfQbcBGjaRsqqPv8QuLkMNfH2uyEY8zrjD2qIrh3akIN
GzwLGUz6qziTi5i1xjgqMcf47kZ7Hk0B+QsNZ7/wnVMj5/lDh90LWQqezKqEj/XM
w5zkY+PlhhUXsxbFSIFJukbiKsjkg++G9TYKCw+tSoMoRUFdORw=
=zaIf
-END PGP SIGNATURE-

Bug#1021232: librust-gdk4-sys-dev: uninstallable

[Jonas Smedegaard]

Package: librust-gdk4-sys-dev
Version: 0.3.1-1+b1
Severity: grave
Justification: renders package unusable

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Package is uninstallable: depends on missing librust-system-deps-3+default-dev

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmM7uZYACgkQLHwxRsGg
ASHRVxAAk2wc9cdkLsLW7nXvVRkEh/IwV3OTCZik6sk2vg7Es/Q1VHVm2m3JHwAq
II7jaGDDHy39HaTjyWoLW7oc0mElXkWdWR3hY2jcjEDwXaIBM68VO17ufDD4D7UH
U+6jDeeJbnY2qqX1n/7Ok24WwBhrP6dAtJKDISlwShd4NPwKAkwINjcciJ5tAYx9
FUmg3cQyduCVrm8A6mgcWrqFev5R2pac0EH7A8QNCJRrRAqy//JD21bGIIZJe6wn
M2C06BQULco87xM1JE4NNV/wbKEHNTE379cNEbtovxq72ggghcfAz9PWIByowbT9
u1LrowwVX6KHbzfQMHdP2zBq/V5wLd48d45OIiJ3wnmhbqAhxNNu2Ubhq53DZWhT
vVbxSegxhOxttMRt+U3xpz7zVSsa0VnRW4EI1X7lylrJMb2hygmJfEGYR3aCBK8u
W2E5r4BRUmUDjb6gMGlU+AeIRCJZtVSvJoA3tRLFdiEWwwif4wfVWbvsPtKOvpKr
xcjWE9p3i7RM8pdrXylHo0UyYl6MFk86pRj7HNYSEwKWEb5w4wKMKo07HdVSEGg6
UOdKxA8Hi707JpngN/CBtBFkTd15/9E6fJ4hSIhaRzsjnfn8ReNQ1yY24u0TxywY
dMXzWnTypaGlFiK1gfpzKhdVGM76SMKub067RgH/pGChveOGRlw=
=MRFc
-END PGP SIGNATURE-

Bug#1010126: FYI working example .service

[Trent W. Buck]

Please find attached the .service I am using on Debian 11.
You don't need all of this crap, I guess.

 * The msmtp stuff is only needed if you have a git post-commit hook that
   makes git send an email.

 * The nginx stuff is only needed if you want to have >1 web app on the 
standard port.

 * The tmpfiles stuff (and git config core.sharedRepository)
   is only needed if users want to bypass the web UI and edit .pages directly.
   It's also a bit broken (adds needless execute permissions) right now.

 * The theme stuff is only needed if you hate the default theme.
   https://github.com/trentbuck/gitit-bootstrap-theme/


For simple cases, you could probably replace the sysusers file with 
DynamicUser=yes,
and just have gitit store all its state in /var/lib/gitit (StateDirectory=%p).


The only issue I've had with this setup so far is gitit claiming static files 
disappear, when they don't.
There's no user-visible impact when this happens.
It wasn't happening on the old (2010-era) gitit install I had running under 
upstart.

-- Journal begins at Sat 2022-08-06 18:32:36 AEST, ends at Tue 2022-10-04 
15:29:20 AEDT. --
Sep 26 12:54:20 heavy systemd[1]: Started gitit.service.
Sep 26 12:55:19 heavy gitit[2522]: HTTP request failed with: 
Network.Socket.sendBuf: resource vanished (Broken pipe)
Sep 26 12:55:29 heavy gitit[2522]: HTTP request failed with: 
/usr/share/javascript/gitit-bootstrap-theme/static/bootstrap4/css/bootstrap.min.css:
 withFd: resource vanished (Broken pipe)
Sep 26 12:55:29 heavy gitit[2522]: HTTP request failed with: 
/usr/share/javascript/gitit-bootstrap-theme/static/img/logo.svg: withFd: 
resource vanished (Broken pipe)
Sep 26 12:55:29 heavy gitit[2522]: HTTP request failed with: 
/usr/share/javascript/gitit-bootstrap-theme/static/css/screen.css: withFd: 
resource vanished (Broken pipe)
Sep 26 12:55:29 heavy gitit[2522]: HTTP request failed with: 
/usr/share/gitit/data/static/css/highlighting.css: withFd: resource vanished 
(Broken pipe)
Sep 26 12:55:41 heavy gitit[2522]: HTTP request failed with: 
Network.Socket.sendBuf: resource vanished (Broken pipe)
Sep 26 12:55:46 heavy gitit[2522]: HTTP request failed with: 
Network.Socket.sendBuf: resource vanished (Broken pipe)
Sep 26 16:26:34 heavy gitit[2522]: HTTP request failed with: 
/usr/share/javascript/gitit-bootstrap-theme/static/img/icon.png: withFd: 
resource vanished (Broken pipe)
Sep 26 18:00:09 heavy gitit[2522]: HTTP request failed with: 
Network.Socket.sendBuf: resource vanished (Broken pipe)
Sep 26 23:43:33 heavy gitit[2522]: HTTP request failed with: 
/usr/share/javascript/gitit-bootstrap-theme/static/css/screen.css: withFd: 
resource vanished (Broken pipe)
Sep 26 23:43:33 heavy gitit[2522]: HTTP request failed with: 
/usr/share/javascript/gitit-bootstrap-theme/static/css/print.css: withFd: 
resource vanished (Broken pipe)
Sep 26 23:43:33 heavy gitit[2522]: HTTP request failed with: 
/usr/share/javascript/gitit-bootstrap-theme/static/fonts-fork-awesome/fonts/forkawesome-webfont.woff2:
 withFd: resource vanished (Broken pipe)
Sep 26 23:43:33 heavy gitit[2522]: HTTP request failed with: 
/usr/share/javascript/gitit-bootstrap-theme/static/img/icon.png: withFd: 
resource vanished (Connection reset by peer)
Sep 27 12:53:13 heavy gitit[2522]: HTTP request failed with: 
/usr/share/javascript/gitit-bootstrap-theme/static/img/icon.png: withFd: 
resource vanished (Broken pipe)
Sep 28 19:24:59 heavy gitit[2522]: HTTP request failed with: 
/usr/share/gitit/data/static/js/footnotes.js: withFd: resource vanished (Broken 
pipe)
Sep 28 19:24:59 heavy gitit[2522]: HTTP request failed with: 
/usr/share/javascript/gitit-bootstrap-theme/static/img/logo.svg: withFd: 
resource vanished (Broken pipe)
Sep 28 19:24:59 heavy gitit[2522]: HTTP request failed with: 
/usr/share/gitit/data/static/js/jquery.min.js: withFd: resource vanished 
(Broken pipe)
Sep 28 19:24:59 heavy gitit[2522]: HTTP request failed with: 
/usr/share/javascript/gitit-bootstrap-theme/static/css/screen.css: withFd: 
resource vanished (Broken pipe)
Sep 28 19:24:59 heavy gitit[2522]: HTTP request failed with: 
/usr/share/gitit/data/static/css/highlighting.css: withFd: resource vanished 
(Broken pipe)
Sep 28 19:24:59 heavy gitit[2522]: HTTP request failed with: 
/usr/share/javascript/gitit-bootstrap-theme/static/css/print.css: withFd: 
resource vanished (Broken pipe)
Sep 28 19:25:00 heavy gitit[2522]: HTTP request failed with: 
/usr/share/javascript/gitit-bootstrap-theme/static/img/icon.png: withFd: 
resource vanished (Broken pipe)
Sep 28 19:25:27 heavy gitit[2522]: HTTP request failed with: 
/usr/share/javascript/gitit-bootstrap-theme/static/img/icon.png: withFd: 
resource vanished (Broken pipe)
Sep 29 10:02:17 heavy gitit[2522]: HTTP request failed with: 
/usr/share/javascript/gitit-bootstrap-theme/static/img/icon.png: withFd: 
resource vanished (Broken pipe)
Oct 03 06:44:23 heavy 

Bug#1021231: dpdk: Consider increasing the timeout for test-fastsuite

[Arnaud Rebillout]

Source: dpdk
Version: 21.11-5
Severity: normal
User: de...@kali.org
Usertags: origin-kali

Dear Maintainer,

I've noticed that the autopkgtests for dpdk tend to fail. Looking at  
https://ci.debian.net/packages/d/dpdk/testing/amd64/, the 10 most recent
test failures are all caused by a timeout of pflock_autotest and
ticketlock_autotest, which are part of test-fastsuite.

I wonder if it's expected, and if the timeout should be increased.
Timeout is defined in debian/tests/test-fastsuite, the option "-t 3"
causes the timeout to be 3 x 10 = 30 seconds.

NB: I don't know anything about dpdk, I just took a bit of time to
investigate why the autopkgtests fail.  We also see these failures
when those tests run on the Kali Linux infra:
https://autopkgtest.kali.org/packages/d/dpdk/kali-rolling/amd64/

Best regards,

Arnaud

Bug#1021230: ITP: golang-github-abiosoft-ishell -- Library for creating interactive cli applications

[Ben Westover]

Package: wnpp
Severity: wishlist
Owner: Ben Westover 
X-Debbugs-CC: debian-de...@lists.debian.org, debian...@lists.debian.org

* Package name: golang-github-abiosoft-ishell
  Version : 2.0.2-1
  Upstream Author : Abiola Ibrahim
* URL : https://github.com/abiosoft/ishell
* License : Expat
  Programming Lang: Go
  Description : Library for creating interactive cli applications

 ishell is an interactive shell library for creating interactive cli
 applications.

I am packaging this library because it's a dependency of proton-bridge.

--
Ben Westover


OpenPGP_signature
Description: PGP signature

Bug#1021229: dracut: dracut-shutdown.service fails because dracut looks for initramfs instead initrd

[Thomas Deutschmann]

Package: dracut-core
Version: 056-3
Severity: important

Dear Maintainer,

I noticed that on shutdown, dracut-shutdown.service failed on my box:

  Oct 04 03:33:16 foo.example.org systemd[1]: dracut-shutdown.service: 
Control process exited, code=exited, status=1/FAILURE
  Oct 04 03:33:16 foo.example.org systemd[1]: dracut-shutdown.service: 
Failed with result 'exit-code'.
  Oct 04 03:33:16 foo.example.org systemd[1]: Stopped Restore 
/run/initramfs on shutdown.


That's because Debian is using "initrd.img-${KERNEL_VERSION}" naming but
/usr/lib/dracut/dracut-initramfs-restore does NOT take this into account.

I guess that the initrd-not-initramfs.patch needs a refresh:

You will either want to rename initramfs- to initrd.img- in 
https://salsa.debian.org/debian/dracut/-/blob/29707b9061841432a4ac466aa03f813d279cd46d/dracut-initramfs-restore.sh#L41-42 
or add another elif clause to match Debian's initrd.img.


At least this fixed the problem for me.

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

Kernel: Linux 5.19.0-2-amd64 (SMP w/6 CPU threads; PREEMPT)
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 dracut-core depends on:
ii  cpio   2.13+dfsg-7.1
ii  e2fsprogs  1.46.6~rc1-1
ii  kmod   30+20220630-3
ii  kpartx 0.9.0-4
ii  libc6  2.35-1
ii  libkmod2   30+20220630-3
ii  udev   251.4-3

Versions of packages dracut-core recommends:
ii  binutils   2.39-6
ii  console-setup  1.210
ii  cryptsetup 2:2.5.0-3
pn  dmraid 
ii  dmsetup2:1.02.185-1
ii  lvm2   2.03.16-1
pn  mdadm  
ii  pigz   2.6-1
ii  pkg-config 0.29.2-1
ii  systemd251.4-3

dracut-core suggests no packages.

-- no debconf information

Bug#1020924: GIMP crashed with a fatal error: fatal error: Segmentation fault

[small bussiness]

Package: GIMP
Version: 2.10.32

as previously tested on Glib 2.73.3, it's still the same with Glib 2.74.0

BUG is :




```
GNU Image Manipulation Program version 2.10.32
git-describe: GIMP_2_10_32
Build: unknown rev 0 for linux
# C compiler #
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/aarch64-linux-gnu/12/lto-wrapper
Target: aarch64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 12.1.0-8'
--with-bugurl=file:///usr/share/doc/gcc-12/README.Bugs
--enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,m2 --prefix=/usr
--with-gcc-major-version-only --program-suffix=-12
--program-prefix=aarch64-linux-gnu- --enable-shared
--enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --libdir=/usr/lib --enable-nls --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-libquadmath --disable-libquadmath-support --enable-plugin
--enable-default-pie --with-system-zlib --enable-libphobos-checking=release
--with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch
--enable-fix-cortex-a53-843419 --disable-werror --enable-checking=release
--build=aarch64-linux-gnu --host=aarch64-linux-gnu
--target=aarch64-linux-gnu
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.1.0 (Debian 12.1.0-8)

# Libraries #
using babl version 0.1.96 (compiled against version 0.1.92)
using GEGL version 0.4.38 (compiled against version 0.4.38)
using GLib version 2.74.0 (compiled against version 2.72.3)
using GdkPixbuf version 2.42.9 (compiled against version 2.42.9)
using GTK+ version 2.24.33 (compiled against version 2.24.33)
using Pango version 1.50.10 (compiled against version 1.50.9)
using Fontconfig version 2.13.1 (compiled against version 2.13.1)
using Cairo version 1.16.0 (compiled against version 1.16.0)

```
> fatal error: Segmentation fault

Stack trace:
```
/lib/aarch64-linux-gnu/libgimpbase-2.0.so.0(gimp_stack_trace_print+0x354)[0x7fad304928]
gimp-2.10(+0xde548)[0x556025e548]
gimp-2.10(+0xde93c)[0x556025e93c]
gimp-2.10(+0xdefb8)[0x556025efb8]
linux-vdso.so.1(__kernel_rt_sigreturn+0x0)[0x7fada48790]
/lib/aarch64-linux-gnu/libgobject-2.0.so.0(+0x27a18)[0x7fac8b4a18]
/lib/aarch64-linux-gnu/libgobject-2.0.so.0(+0x1cd64)[0x7fac8a9d64]
/lib/aarch64-linux-gnu/libgobject-2.0.so.0(+0x1d594)[0x7fac8aa594]
/lib/aarch64-linux-gnu/libgobject-2.0.so.0(g_object_new_with_properties+0x188)[0x7fac8abd18]
gimp-2.10(gimp_image_undo_push+0x1dc)[0x55605e3f60]
gimp-2.10(gimp_image_undo_push_text_layer+0x158)[0x55605e7398]
gimp-2.10(gimp_text_tool_apply+0xf0)[0x556030eef0]
gimp-2.10(+0x190838)[0x5560310838]
gimp-2.10(+0x190a54)[0x5560310a54]
/lib/aarch64-linux-gnu/libgobject-2.0.so.0(g_closure_invoke+0x178)[0x7fac8a42f8]
/lib/aarch64-linux-gnu/libgobject-2.0.so.0(+0x2c51c)[0x7fac8b951c]
/lib/aarch64-linux-gnu/libgobject-2.0.so.0(g_signal_emit_valist+0xd4c)[0x7fac8bf84c]
/lib/aarch64-linux-gnu/libgobject-2.0.so.0(g_signal_emit+0x7c)[0x7fac8bfa60]
gimp-2.10(+0x1930a4)[0x55603130a4]
/lib/aarch64-linux-gnu/libgobject-2.0.so.0(g_closure_invoke+0x178)[0x7fac8a42f8]
/lib/aarch64-linux-gnu/libgobject-2.0.so.0(+0x2c51c)[0x7fac8b951c]
/lib/aarch64-linux-gnu/libgobject-2.0.so.0(g_signal_emit_valist+0xd4c)[0x7fac8bf84c]
/lib/aarch64-linux-gnu/libgobject-2.0.so.0(g_signal_emit_by_name+0x1cc)[0x7fac8bfc5c]
/lib/aarch64-linux-gnu/libgobject-2.0.so.0(g_closure_invoke+0x178)[0x7fac8a42f8]
/lib/aarch64-linux-gnu/libgobject-2.0.so.0(+0x2c51c)[0x7fac8b951c]
/lib/aarch64-linux-gnu/libgobject-2.0.so.0(g_signal_emit_valist+0xd4c)[0x7fac8bf84c]
/lib/aarch64-linux-gnu/libgobject-2.0.so.0(g_signal_emit_by_name+0x1cc)[0x7fac8bfc5c]
/lib/aarch64-linux-gnu/libgtk-x11-2.0.so.0(+0x12b298)[0x7fad5e5298]
/lib/aarch64-linux-gnu/libgtk-x11-2.0.so.0(+0x12b758)[0x7fad5e5758]
gimp-2.10(gimp_text_tool_editor_key_press+0xac)[0x5560314290]
gimp-2.10(+0x1e77f0)[0x55603677f0]
gimp-2.10(gimp_display_shell_canvas_tool_events+0xa0)[0x5560368570]
/lib/aarch64-linux-gnu/libgtk-x11-2.0.so.0(+0x1470a4)[0x7fad6010a4]
/lib/aarch64-linux-gnu/libgobject-2.0.so.0(g_closure_invoke+0x178)[0x7fac8a42f8]
/lib/aarch64-linux-gnu/libgobject-2.0.so.0(+0x2c51c)[0x7fac8b951c]
/lib/aarch64-linux-gnu/libgobject-2.0.so.0(g_signal_emit_valist+0x6c8)[0x7fac8bf1c8]
/lib/aarch64-linux-gnu/libgobject-2.0.so.0(g_signal_emit+0x7c)[0x7fac8bfa60]
/lib/aarch64-linux-gnu/libgtk-x11-2.0.so.0(+0x2770c0)[0x7fad7310c0]
/lib/aarch64-linux-gnu/libgtk-x11-2.0.so.0(gtk_window_propagate_key_event+0xf4)[0x7fad747734]
gimp-2.10(+0x309734)[0x5560489734]
/lib/aarch64-linux-gnu/libgtk-x11-2.0.so.0(+0x1470a4)[0x7fad6010a4]
/lib/aarch64-linux-gnu/libgobject-2.0.so.0(g_closure_invoke+0x178)[0x7fac8a42f8]
/lib/aarch64-linux-gnu/libgobject-2.0.so.0(+0x2c224)[0x7fac8b9224]
/lib/aarch64-linux-gnu/libgobject-2.0.so.0(g_signal_emit_valist+0x6c8)[0x7fac8bf1c8]
/lib/aarch64-linux-gnu/libgobject-2.0.so.0(g_signal_emit+0x7c)[0x7fac8bfa60]

Bug#1021228: ITP: golang-github-flynn-archive-go-shlex -- Fork of go-shlex from Google Code

[Ben Westover]

Package: wnpp
Severity: wishlist
Owner: Ben Westover 
X-Debbugs-CC: debian-de...@lists.debian.org, debian...@lists.debian.org

* Package name: golang-github-flynn-archive-go-shlex
  Version : 0.0~git20150515.3f9db97-1
  Upstream Author : Google Inc.
* URL : https://github.com/flynn-archive/go-shlex
* License : Apache-2.0
  Programming Lang: Go
  Description : Fork of go-shlex from Google Code

 go-shlex is a simple lexer for go that supports shell-style quoting,
 commenting, and escaping.

I am packaging this library because it's a dependency of proton-bridge.

--
Ben Westover


OpenPGP_signature
Description: PGP signature

Bug#1021227: gnome-boxes: Window 11 22H2 ISO freeze on beginning

[Hajib]

Package: gnome-boxes
Version: 3.38.2-1
Severity: normal
X-Debbugs-Cc: lutfi.a...@gmail.com

Dear Maintainer,

I got this problem both Gnome-Boxes and Virt-Manager trying to install Windows
11 22H2 using ISO file official from Microsoft website.

Windows 11 21H2 OK and no problem untill full install
Windows 11 22H2 not OK and it's freezing Gnome-box windows few second after
booting that ISO

but triying using terminal:

 qemu-system-x86_64 -m 4096 -cdrom ./Win11_22H2_English_x64v1.iso

No problem and no freezing . I got Windows Setup


Any solution?



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

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

Versions of packages gnome-boxes depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.38.0-2
ii  genisoimage  9:1.1.11-3.2
ii  libarchive13 3.4.3-2+deb11u1
ii  libc62.31-13+deb11u4
ii  libcairo21.16.0-5
ii  libfreerdp2-22.3.0+dfsg1-2+deb11u1
ii  libgdk-pixbuf-2.0-0  2.42.2+dfsg-1+deb11u1
ii  libgdk-pixbuf2.0-0   2.40.2-2
ii  libglib2.0-0 2.66.8-1
ii  libgtk-3-0   3.24.24-4+deb11u2
ii  libgtk-vnc-2.0-0 1.0.0-1
ii  libgtksourceview-4-0 4.8.0-1
ii  libgudev-1.0-0   234-1
ii  libhandy-0.0-0   0.0.13-3
ii  libosinfo-1.0-0  1.8.0-1
ii  libosinfo-bin1.8.0-1
ii  libpango-1.0-0   1.46.2-3
ii  libsecret-1-00.20.4-2
ii  libsoup2.4-1 2.72.0-2
ii  libspice-client-glib-2.0-8   0.39-1
ii  libspice-client-gtk-3.0-50.39-1
ii  libtracker-sparql-2.0-0  2.3.6-2
ii  libusb-1.0-0 2:1.0.24-3
ii  libvirt-daemon   8.0.0-1~bpo11+1
ii  libvirt-glib-1.0-0   3.0.0-1
ii  libvte-2.91-00.62.3-1
ii  libwebkit2gtk-4.0-37 2.38.0-1~deb11u1
ii  libwinpr2-2  2.3.0+dfsg1-2+deb11u1
ii  libxml2  2.9.10+dfsg-6.7+deb11u2
ii  tracker  2.3.6-2

Versions of packages gnome-boxes recommends:
ii  qemu-system-x86  1:5.2+dfsg-11+deb11u2

gnome-boxes suggests no packages.

Bug#1021226: ITP: golang-github-chzyer-test -- test

[Ben Westover]

Package: wnpp
Severity: wishlist
Owner: Ben Westover 
X-Debbugs-CC: debian-de...@lists.debian.org, debian...@lists.debian.org

* Package name: golang-github-chzyer-test
  Version : 1.0.0-1
  Upstream Author : ChenYe
* URL : https://github.com/chzyer/test
* License : Expat
  Programming Lang: Go
  Description : test

 test

I am packaging this library because it's a dependency of proton-bridge.

--
Ben Westover


OpenPGP_signature
Description: PGP signature

Bug#1021225: ITP: golang-github-chzyer-logex -- Golang log library that supports tracking and level

[Ben Westover]

Package: wnpp
Severity: wishlist
Owner: Ben Westover 
X-Debbugs-CC: debian-de...@lists.debian.org, debian...@lists.debian.org

* Package name: golang-github-chzyer-logex
  Version : 1.2.1-1
  Upstream Author : ChenYe
* URL : https://github.com/chzyer/logex
* License : Expat
  Programming Lang: Go
  Description : Golang log library, supporting tracking and level

 Logex is a Golang log library that supports tracing and level, wrapped
 by the standard log library.

I am packaging this library because it's a dependency of proton-bridge.

--
Ben Westover


OpenPGP_signature
Description: PGP signature

Bug#1021224: ITP: golang-github-abiosoft-readline -- Pure Go implementation for GNU-Readline kind library

[Ben Westover]

Package: wnpp
Severity: wishlist
Owner: Ben Westover 
X-Debbugs-CC: debian-de...@lists.debian.org, debian...@lists.debian.org

* Package name: golang-github-abiosoft-readline
  Version : 0.0~git20180607.155bce2-1
  Upstream Author : Abiola Ibrahim
* URL : https://github.com/abiosoft/readline
* License : Expat
  Programming Lang: Go
  Description : Pure Go implementation of GNU-Readline kind library

 This is powerful readline Go library for Linux, macOS, Windows,
 Solaris, and more.

I am packaging this library because it's a dependency of proton-bridge.

--
Ben Westover


OpenPGP_signature
Description: PGP signature

Bug#1013957: unbound: Rethink debian license GPL-3+

[Bastian Germann]

On Thu, 11 Aug 2022 18:42:11 +0300 Michael Tokarev  wrote:

On Tue, 28 Jun 2022 01:47:34 +0200 Bastian Germann  wrote:
> The debian/ directory including debian/patches is currently licensed under 
GPL-3+.
> As the patches are not exempt from that license the resulting binaries have 
to comply with GPL-3+ as well.
> This causes a problem for reverse dependencies that have incompatible 
licenses, e.g., monero includes files
> licensed under RSA-MD.

Umh. Personally I don't care at all about which license to use for my work.
And while quite some code in debian/ is written by me, it is based on prior
work there, and not everything is mine. Patches are mine though.

> Would you please consider relicensing at least debian/patches?

I wonder how this can be done for the other parts...

I've added entry for d/patches/* for now.


Hi Michael,

Thanks, but GPL-2 has the same problem in this context as GPL-3+, i.e.,
it does not allow any additional requirements on code combined with it.

Of the already existing licenses in d/copyright I would suggest ISC.

Thanks for your consideration.
Bastian

Bug#1021223: FTBS: *** You must specify a valid ANT_HOME directory.

[Adam Borowski]

Source: nekohtml
Version: 1.9.22-1.1
Severity: important
User: debian...@lists.debian.org
Usertags: ftbs

Hi!
I'm afraid that your package fails to repack its sources, failing if only
Build-Depends (no Build-Depends-Indep) are installed:

 dpkg-source --before-build .
 fakeroot debian/rules clean
test -x debian/rules
/usr/share/cdbs/1/class/ant.mk:31: *** You must specify a valid ANT_HOME 
directory.  Stop.

Meow!
-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), 
(120, 'experimental'), (1, 'experimental-debug')
merged-usr: no
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.0.0-00071-gceb3937667d3 (SMP w/64 CPU threads)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Bug#1021222: FTBS: *** You must specify a valid ANT_HOME directory.

[Adam Borowski]

Source: libswarmcache-java
Version: 1.0RC2+cvs20071027-7.1
Severity: important
User: debian...@lists.debian.org
Usertags: ftbs

Hi!
I'm afraid that your package fails to repack its sources, failing if only
Build-Depends (no Build-Depends-Indep) are installed:

 dpkg-source --before-build .
 fakeroot debian/rules clean
test -x debian/rules
/usr/share/cdbs/1/class/ant.mk:31: *** You must specify a valid ANT_HOME 
directory.  Stop.

Meow!
-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), 
(120, 'experimental'), (1, 'experimental-debug')
merged-usr: no
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.0.0-00071-gceb3937667d3 (SMP w/64 CPU threads)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Bug#1021221: FTBS: *** You must specify a valid ANT_HOME directory.

[Adam Borowski]

Source: c3p0
Version: 0.9.1.2-10
Severity: important
User: debian...@lists.debian.org
Usertags: ftbs

Hi!
I'm afraid that your package fails to repack its sources, failing if only
Build-Depends (no Build-Depends-Indep) are installed:

 dpkg-source --before-build .
 fakeroot debian/rules clean
test -x debian/rules
/usr/share/cdbs/1/class/ant.mk:31: *** You must specify a valid ANT_HOME 
directory.  Stop.

Meow!
-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), 
(120, 'experimental'), (1, 'experimental-debug')
merged-usr: no
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.0.0-00071-gceb3937667d3 (SMP w/64 CPU threads)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Bug#1020553: cryptsetup-suspend: resume from suspend to RAM stuck after upgrading to 2:2.5.0-3

[Guilhem Moulin]

Control: tag -1 = pending
Control: severity -1 important

On Tue, 27 Sep 2022 at 14:22:13 +0900, Yuya Nishihara wrote:
> The attached log file shows /run/udev/control exists, but it might not be what
> you suggested because the log is captured out of the chroot environment. Maybe
> that's why udevd is found in my environment.

Oh I see, my bad indeed (the test doesn't cover resuming of non-early boot 
devices).  Fixed in
https://salsa.debian.org/cryptsetup-team/cryptsetup/-/commit/9030b6fe48d1e9caaeb61e370fe7071f7c9aa35a

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#1020411: RFP: sphinxcontrib-ditaa -- sphinx extension for embedding block diagram using ditaa

[Bastian Germann]

git repo set-up at 
https://salsa.debian.org/python-team/packages/sphinxcontrib-ditaa
Bo YU, please ping me when you want this to be reviewed.

Bug#1021220: FTBS: make[1]: ./build: No such file or directory

[Adam Borowski]

Source: c++-annotations
Version: 12.2.0-1
Severity: important
User: debian...@lists.debian.org
Usertags: ftbs

Hi!
I'm afraid that your package fails to repack its source; it's because
a script you call in the "clean" target has hashbang #!/usr/bin/icmake
but icmake is only in Build-Depends-Indep rather than Build-Depends.

 dpkg-source --before-build .
 debian/rules clean
dh clean
   debian/rules override_dh_auto_clean
make[1]: Entering directory '/<>'
rm -rf build-stamp debian/c++-annotations
./build clean
make[1]: ./build: No such file or directory
make[1]: *** [debian/rules:17: override_dh_auto_clean] Error 127


Meow!
-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), 
(120, 'experimental'), (1, 'experimental-debug')
merged-usr: no
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.0.0-00071-gceb3937667d3 (SMP w/64 CPU threads)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Bug#1014815: kiwipy initial packaging

[Bastian Germann]

What is the status on kiwipy?

Bug#1021219: lomiri-indicator-network: Depends: indicator-common but it is not installable

[Adrian Bunk]

Package: lomiri-indicator-network
Version: 1.0.0~git20220718.2ca3619-3
Severity: serious

The following packages have unmet dependencies:
 lomiri-indicator-network : Depends: indicator-common but it is not installable

Bug#1021218: FTBS: /bin/sh: 1: po4a: not found

[Adam Borowski]

Source: fortunes-debian-hints
Version: 2.01.4
Severity: important
User: debian...@lists.debian.org
Usertags: ftbs

Hi!
I'm afraid that your package fails to repack its source:

 dpkg-source --before-build .
 debian/rules clean
dh clean
   debian/rules override_dh_auto_clean
make[1]: Entering directory '/<>'
dh_auto_clean
rm -f *.dat
po4a --msgid-bugs-address "Kartik Mistry " --previous 
--rm-translations --rm-backups po4a.cfg
/bin/sh: 1: po4a: not found
make[1]: *** [debian/rules:52: override_dh_auto_clean] Error 127

I've verified that moving po4a from Build-Depends-Indep to Build-Depends
is enough to fix this.


Meow!
-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), 
(120, 'experimental'), (1, 'experimental-debug')
merged-usr: no
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.0.0-00071-gceb3937667d3 (SMP w/64 CPU threads)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Bug#1021217: FTBS: /bin/sh: 1: po4a: not found

[Adam Borowski]

Source: adduser
Version: 3.129
Severity: important
User: debian...@lists.debian.org
Usertags: ftbs

Hi!
I'm afraid that your package fails to repack its source:

 dpkg-source --before-build .
 fakeroot debian/rules clean
dh clean
   debian/rules override_dh_auto_clean
make[1]: Entering directory '/<>'
cd doc/po4a && po4a --previous --rm-translations po4a.conf
/bin/sh: 1: po4a: not found
make[1]: *** [debian/rules:16: override_dh_auto_clean] Error 127

I've verified that moving po4a from Build-Depends-Indep to Build-Depends
is enough to fix this.


Meow!
-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), 
(120, 'experimental'), (1, 'experimental-debug')
merged-usr: no
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.0.0-00071-gceb3937667d3 (SMP w/64 CPU threads)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Bug#1018727: bash: after upgrade, aliases with embedded $() subcommands don't work

[Piotr Jawidzyk]

Still an issue in 5.2-1.

Bug#1021216: FTBS: ModuleNotFoundError: No module named 'docutils'

[Adam Borowski]

Source: arandr
Version: 0.1.10-1.1
Severity: important
User: debian...@lists.debian.org
Usertags: ftbs

Hi!
I'm afraid that your package fails to repack its source if only declared
Build-Depends are installed:

 dpkg-source --before-build .
 debian/rules clean
dh clean --with python3 --buildsystem=pybuild
   dh_auto_clean -O--buildsystem=pybuild
I: pybuild base:240: python3.10 setup.py clean 
Traceback (most recent call last):
  File "/<>/setup.py", line 26, in 
import docutils.core
ModuleNotFoundError: No module named 'docutils'
E: pybuild pybuild:379: clean: plugin distutils failed with: exit code=1: 
python3.10 setup.py clean 
dh_auto_clean: error: pybuild --clean -i python{version} -p 3.10 returned exit 
code 13
make: *** [debian/rules:4: clean] Error 25

I guess that moving python3-docutils from Build-Depends-Indep to
Build-Depends should do the trick.


喵!
-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), 
(120, 'experimental'), (1, 'experimental-debug')
merged-usr: no
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.0.0-00071-gceb3937667d3 (SMP w/64 CPU threads)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Bug#1021140: vlc: No video when "Integrate video in interface" is enabled

[Lyndon Brown]

>From the log, this looks to be a duplicate of #1021032.

Bug#1021215: Kind request for backports of libtraceevent and libtracefs

[Hans van Kranenburg]

Package: src:libtraceevent
Version: 1:1.1.2-1

Hi maintainer, :)

Linux commit fe4d0d5dde ("rtla/Makefile: Properly handle dependencies")
helps making the dependency on libtraceevent and libtracefs more
explicit, so that the users run into less weird problems on the go.

Linux 5.19 is in Debian unstable now, and for the stable-backports
packages that our kernel team is providing, this means that it will
FTBFS, unless we either:
- exclude rtla for bullseye-backports
- have backports for libtraceevent and libtracefs present

So, the question for you is: Do you want to also provide
bullseye-backports packages for libtraceevent and libtracefs?

About making dependencies explicit in the kernel package:
https://salsa.debian.org/kernel-team/linux/-/merge_requests/539

Currently shipping without rtla, so far:
https://salsa.debian.org/benh/linux/-/commit/15b6859742d404abdcd68bcb589f8a8e2dfb6ce4

Thanks,
Hans

Bug#1015245: reproducible build

[matthias . geiger1024]

 This is fixed in the latest version.
 ---

Cheers werdahias

Bug#1021214: bullseye-pu: package libconfuse/3.3-2+deb11u1

[Aurelien Jarno]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: t...@security.debian.org

[ Reason ]
A heap-based buffer over-read has been found in libconfuse, labeled as
CVE-2022-40320, and reported as bug #1019596. The security team
considers this vulnerability as low severity which does not warrant a
DSA.

[ Impact ]
In case the update isn't approved, the vulnerability will still be
present users systems.

[ Tests ]
The changed code is tested by the testsuite, but there is no specific
test to check the vulnerability is fixed.

[ Risks ]
The fix is very simple and comes from upstream. It has been in
testing/sid for 2 weeks.

[ Checklist ]
  [x] *all* changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in (old)stable
  [x] the issue is verified as fixed in unstable

[ Changes ]
There is a single change in this version:
  * Add debian/patches/CVE-2022-40320.patch from upstream to fix a heap-based
buffer over-read in cfg_tilde_expand (CVE-2022-40320).  Closes: #1019596.

The change is to ensure the string copied with strncpy is always zero
terminated.

[ Other info ]
Given the changes are minimal, I have already uploaded the package to
the archive. Thanks for considering.
diff -Nru libconfuse-3.3/debian/changelog libconfuse-3.3/debian/changelog
--- libconfuse-3.3/debian/changelog 2021-01-10 15:30:20.0 +0100
+++ libconfuse-3.3/debian/changelog 2022-10-04 00:14:59.0 +0200
@@ -1,3 +1,10 @@
+libconfuse (3.3-2+deb11u1) bullseye; urgency=medium
+
+  * Add debian/patches/CVE-2022-40320.patch from upstream to fix a heap-based
+buffer over-read in cfg_tilde_expand (CVE-2022-40320).  Closes: #1019596.
+
+ -- Aurelien Jarno   Tue, 04 Oct 2022 00:14:59 +0200
+
 libconfuse (3.3-2) unstable; urgency=medium
 
   * German translation update, by Fabian Baumanis.  Closes: #978117.
diff -Nru libconfuse-3.3/debian/patches/CVE-2022-40320.patch 
libconfuse-3.3/debian/patches/CVE-2022-40320.patch
--- libconfuse-3.3/debian/patches/CVE-2022-40320.patch  1970-01-01 
01:00:00.0 +0100
+++ libconfuse-3.3/debian/patches/CVE-2022-40320.patch  2022-09-14 
22:39:16.0 +0200
@@ -0,0 +1,37 @@
+commit d73777c2c3566fb2647727bb56d9a2295b81669b
+Author: Joachim Wiberg 
+Date:   Fri Sep 2 16:12:46 2022 +0200
+
+Fix #163: unterminated username used with getpwnam()
+
+Signed-off-by: Joachim Wiberg 
+
+diff --git a/src/confuse.c b/src/confuse.c
+index 6d1fdbd..05566b5 100644
+--- a/src/confuse.c
 b/src/confuse.c
+@@ -1894,18 +1894,20 @@ DLLIMPORT char *cfg_tilde_expand(const char *filename)
+   passwd = getpwuid(geteuid());
+   file = filename + 1;
+   } else {
+-  /* ~user or ~user/path */
+-  char *user;
++  char *user; /* ~user or ~user/path */
++  size_t len;
+ 
+   file = strchr(filename, '/');
+   if (file == 0)
+   file = filename + strlen(filename);
+ 
+-  user = malloc(file - filename);
++  len = file - filename - 1;
++  user = malloc(len + 1);
+   if (!user)
+   return NULL;
+ 
+-  strncpy(user, filename + 1, file - filename - 1);
++  strncpy(user, [1], len);
++  user[len] = 0;
+   passwd = getpwnam(user);
+   free(user);
+   }
diff -Nru libconfuse-3.3/debian/patches/series 
libconfuse-3.3/debian/patches/series
--- libconfuse-3.3/debian/patches/series2021-01-10 15:12:53.0 
+0100
+++ libconfuse-3.3/debian/patches/series2022-09-14 22:39:16.0 
+0200
@@ -1 +1,2 @@
 de.po.patch
+CVE-2022-40320.patch

Bug#1009343: please consider adding Boost-1.0 and Expat to /usr/share/common-licenses

[Santiago Vila]

reassign 1009343 debian-policy
thanks

El 12/4/22 a las 5:41, Daniel Kahn Gillmor escribió:

Package: base-files
Severity: wishlist
Version: 12.2

Expat and Boost-1.0 are both fairly common licenses in debian.  I
believe they are both well-defined, stable, and reasonably
well-understood variants of the MIT family of licenses.

https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/ even
explicitly recommends that software with an "MIT" license that matches
the Expat terms should instead refer to Expat.

It would seem reasonable to include both of these licenses in
/usr/share/common-licenses/ to discourage adoption of other
less-well-known variants in the MIT family.

Boost has the advantage over "Expat" of being explicitly included in the
SPDX listing with a short name of "BSL-1.0":

 https://spdx.org/licenses/

while Expat doesn't get its own identifier in that list, but instead has
the discouraged "MIT".


This kind of requests should be handled by the policy group first, as 
explained in the base-files FAQ. I'm reassigning the bug.


Thanks.

Bug#924094: base-files: Missing Artistic-2.0 in /usr/share/common-licenses/

[Santiago Vila]

reassign 924094 debian-policy
thanks

El 9/3/19 a las 15:13, Steffen Moeller escribió:

Package: base-files
Version: 10.1
Severity: normal

Dear Maintainer,

* What led up to the situation?

I was packaging a tool with that license without shipping it.

* What outcome did you expect instead?

I wished I could refer to a file /usr/share/common-licenses/Artistic-2.0 
instead of copying it.
The original license is on https://opensource.org/licenses/Artistic-2.0


This kind of requests should be handled by the policy group first, as 
explained in the base-files FAQ. I'm reassigning the bug.


Thanks.

Bug#1013195: base-files: Please add AGPL-3 license

[Santiago Vila]

reassign 1013195 debian-policy
thanks

El 18/6/22 a las 23:45, Salvo 'LtWorf' Tomaselli escribió:

Package: base-files
Version: 12.2
Severity: normal
X-Debbugs-Cc: tipos...@tiscali.it

Dear Maintainer,
AGPL-3 license is not present in the base files.

This forces me to include verbatim the very long text of the license which
also gets duplicated if many binary packages are generated.

For ease of read from FTPmaster it would be preferrable to have the text
in base-files so that it can just be referenced.


This kind of requests should be handled by the policy group first, as 
explained in the base-files FAQ. I'm reassigning the bug.


Thanks.

Bug#1020828: base-files: machine-readable copyright file

[Bastian Germann]

Am 03.10.22 um 23:04 schrieb Santiago Vila:

For completeness: Do you have any idea about what we could do with the non-GNU 
licenses? (regarding copyright, that is).


Not really. I do not think legal texts are considered to be copyrightable.
One could insert a block like this in front of the GNU license block:

Files: licenses/*
Copyright: (authors of the licenses)
License: legal-texts
 Debian does not claim copyright on the included legal texts.

Bug#1008735: base-files: /etc/os-release should contain VERSION variables for testing and unstable

[Santiago Vila]

El 3/10/22 a las 11:55, Sedat Dilek escribió:

VERSION_ID=sid
VERSION_CODENAME=bookworm


This is "schizophrenic", so to speak, and I don't think it is a good idea.

I've simply added VERSION_CODENAME=bookworm.

The only caveat is that testing and unstable are sides of the same coin,
but this is already explained in /usr/share/doc/base-files/FAQ.

As a result, if you take the VERSION_CODENAME string and include it in a 
kernel version string somewhere, the meaning of such string is that the 
kernel image was created in either a bookworm or a sid distribution.


I think this is good enough for most purposes. If you need more 
fine-tuning, somebody should investigate what kind of magic lsb_release 
did in the past and reenable part of it.


Thanks.

Bug#1012563: wireplumber: right click broken in firefox 100.0.2-1

[Gabriel Corona]

Hi,

I found that killing pipwire-pulse unfeezes the frozen application. 
After that, pipwire-pulse can be restarted.


This is in contrast to killing wireplumber or pipewire: this would not 
unfreeze the frozen applications; restarting the frozen application was 
needed in these cases.


Maybe some kind of deadlock in dbus communications?

Gabriel

Bug#1020244: fonts-urw-base35: A monospaced font shouldn't have ligatures

[Markus Hitter]

That's an odd reasoning. So you want to keep the bug, because removing it would 
solve the problem not only for one, but for many applications and thousands of 
users? For me, such a huge impact would encourage me even more (and was 
actually the reason why I filed a bug at all and spent 3 days to find not only 
a simple works-for-me fix, but the best possible solution I could find).

There is no reason to believe that upstream fixes this bug anytime soon (by 
applying the patch or some other way). Upstream bug is over a year old, with no 
attempts to solve it, not even a comment from the repo owner. Last commit to 
the upstream repository is almost a year old. URW++'s last contribution is over 
5 years old. Clear signs of abandoned development.

Also, once upstream solved the problem, removing the packaging patch again is 
trivial. Even better, upstream might see next year that the fix works fine and 
commit it as 'proven working'.

I'm not surprised at all that Debian runs into unmaintained upstream software. 
That's simply how the software world works. Developers write some code, are 
happy with the result, then they move on to their next project. 5 years later 
this software is still useful, but original developers have long forgotten what 
they did back then. When a bug is found, they're just as clueless as anybody. 
Only few very big projects receive continued development for many years.

Debian's answer to this can't be to ignore known bugs in unmaintained projects. 
Or worse, drop their packages. Much better is to also maintain fixes. AFAIK, 
all major OS developers do this, Apple, Microsoft, Google, you name it. 
Debian's packaging patch mechanism is there for a reason, it should be used for 
the best experience of Debian users: bug-free software packages.

Markus

Bug#1016407: Solved

[Ron Murray]

   I found that I had all device_file options for sda, sdb and sdc in
~/.config/udiskie/config.yml set to "ignore: true". sdd was ok, and
that was where removeable drives ended up until I removed hard drives
sdb and sdc. Removeable drives then went to sdb, which was ignored.

   udiskie's "--verbose" mode helped solve this.

   You can close this bug now.

Thanks,

 .Ron

-- 
Ron Murray 
PGP Fingerprint: 4D99 70E3 2317 334B 141E 7B63 12F7 E865 B5E2 E761

Bug#1020828: base-files: machine-readable copyright file

[Santiago Vila]

Thanks for the report.

For completeness: Do you have any idea about what we could do with the 
non-GNU licenses? (regarding copyright, that is).

Bug#1021213: librust-libgit2-sys-dev: Depends: libgit2-dev (< 1.4~~) but 1.5.0+ds-6 is to be installed

[Adrian Bunk]

Package: librust-libgit2-sys-dev
Version: 0.12.24-5
Severity: serious
Tags: ftbfs
Control: affects -1 src:rust-bat src:rust-cargo-c src:rust-cargo-outdated 
src:rust-debcargo src:rust-git-absorb
Control: close -1 0.13.2-1

The following packages have unmet dependencies:
 librust-libgit2-sys-dev : Depends: libgit2-dev (< 1.4~~) but 1.5.0+ds-6 is to 
be installed
 

Bug#749400: dh_installinit: disable init scripts on removal of package

[Michael Biebl]

Control: tags -1 + pending

On Mon, 26 May 2014 18:23:20 -0007 Cameron Norman 
 wrote:

Package: debhelper

Greetings,

It would be much cleaner to disable init scripts when the package is 
uninstalled, so that a bunch of shell scripts that just run "[ -x 
$DAEMON ] || exit 0" are not slowing down the boot.


Additionally, this causes problems for Upstart, as the "starting" event 
is emitted before the job can tell if its daemon is installed or not. 
It also poses a problem for socket activation with Upstart, as the 
upstart-socket-bridge will create the socket for the job even if the 
daemon is not installed.


I think it would just be overall cleaner to disable the init 
configuration on removal of the package with a "update-rc.d disable 
$daemon".


I think this is fixed by
https://salsa.debian.org/debian/debhelper/-/merge_requests/90

I deliberately did not use "update-rc.d disable" to mark a SysV init 
script as disabled once uninstalled, since I consider "update-rc.d 
disable" an interface that is used by the local admin, so a distinct 
state seemed preferable.


In any case, I'll mark this issue as pending.
If you disagree or this solution in MR90 is not sufficient, please let 
us know.



Michael


OpenPGP_signature
Description: OpenPGP digital signature

Bug#968997: fwupdmgr: "Successfully" updates BIOS firmware, no effect on reboot

[Steve McIntyre]

On Mon, Oct 03, 2022 at 09:22:02PM +0200, Vincent Bernat wrote:
>On Fri, 10 Sep 2021 10:35:31 +0200 Julian Andres Klode 
>wrote:
>> Control: reassign -1 shim
>> Control: affects -1 fwupd
>> 
>> On Fri, Sep 10, 2021 at 09:27:11AM +0200, Norbert Schulz wrote:
>> > Package: fwupd
>> > Version: 1.2.14-1~deb10u1
>> > Followup-For: Bug #968997
>> > > Dear Maintainer,
>> > > this bug still exist for a long time. I removed all packages relating
>> fwupd and install it from scratch but > no install of the firmware on
>> reboot.
>> 
>> Sure, that's expected, shim 15.4 is not able to load fwupd without
>> additional patches, which have not been applied yet, so it's
>> not going to get better by reinstalling fwupd.
>
>shim-unsigned has been updated to 15.6 which has the right patches in. But
>for some reason, shim-signed is still at 15.4.

We've had problems in submitting shim 15.6 to Microsoft for
signing. We're working on a solution, but it's going to take a little
longer yet.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
< liw> everything I know about UK hotels I learned from "Fawlty Towers"

Bug#1021212: ITP: biometryd -- biometryd mediates/multiplexes to biometric devices

[Mike Gabriel]

Package: wnpp
Severity: wishlist
Owner: Mike Gabriel 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: biometryd
  Version : 0.0.2
  Upstream Author : UBports Foundation 
* URL : https://gitlab.com/ubports/development/core/biometryd/
* License : LGPL-3.0
  Programming Lang: C++
  Description : biometryd mediates/multiplexes to biometric devices

 biometryd mediates and multiplexes access to biometric devices present
 on the system, enabling applications and system components to leverage
 them for identification and verification of users.
 .
 This package is part of the Lomiri operating environment and will be
 maintained by the UBports Packaging Team.

Bug#1021032: VLC sound

[Miguel A. Vallejo]

Hi!

Has anyone noticed the actual version on Sid and the previous one do not
reproduce sound from videos with AAC audio?

I have some MKV videos with AAC ( aac (LC), 48000 Hz, 5.1, fltp) and they
sound nicely in any other player but complete silence with VLC.

I don't know if it could be related to this bug. Should I create a new bug?

Thank you

Bug#1015179: Please update ppxlib to latest upstream

[julien . puydt]

Hi,

Le jeudi 22 septembre 2022 à 14:46 +0200, julien.pu...@gmail.com a
écrit :
> 
> I'll try to work on checking again what is needed to push to unstable
> when I find the time.
> 

I found some time this evening ; but the problem I have is I don't know
how to handle deps correctly for OCaml packages!

For Coq packages, I have a script and I can run:
$ ./planif_transition coq-foo
which tells me which packages are to be handled -- and in which order.
For example:
$ ./planif_transition.py ssreflect
'ssreflect'
'coq-deriving', 'coq-reglang', 'coq-relation-algebra', 'coquelicot',
'mathcomp-bigenough', 'mathcomp-finmap', 'mathcomp-zify'
'coq-extructures', 'coq-interval', 'coq-quickchick', 'mathcomp-algebra-
tactics', 'mathcomp-analysis', 'mathcomp-multinomials', 'mathcomp-real-
closed'
'coqeal', 'mathcomp-abel'
where on each line the packages can be parallel-built.

Is there something like this for OCaml packages?

J.Puydt

PS: I should really clean my Coq script and put them somewhere to limit
the bus factor...

Bug#968997: fwupdmgr: "Successfully" updates BIOS firmware, no effect on reboot

[Vincent Bernat]

On Fri, 10 Sep 2021 10:35:31 +0200 Julian Andres Klode  
wrote:

Control: reassign -1 shim
Control: affects -1 fwupd

On Fri, Sep 10, 2021 at 09:27:11AM +0200, Norbert Schulz wrote:
> Package: fwupd
> Version: 1.2.14-1~deb10u1
> Followup-For: Bug #968997
> 
> Dear Maintainer,
> 
> this bug still exist for a long time. I removed all packages relating fwupd and install it from scratch but 
> no install of the firmware on reboot. 


Sure, that's expected, shim 15.4 is not able to load fwupd without
additional patches, which have not been applied yet, so it's
not going to get better by reinstalling fwupd.


shim-unsigned has been updated to 15.6 which has the right patches in. 
But for some reason, shim-signed is still at 15.4.

Bug#1021211: remmina: switch to libsoup3

[Jeremy Bicha]

Source: remmina
Version: 1.4.27+dfsg-2
Forwarded: https://gitlab.com/Remmina/Remmina/-/merge_requests/2431
User: pkg-webkit-maintain...@lists.alioth.debian.org
Usertags: webkit-4.0

Please switch remmina to build with libsoup3 and webkit2gtk 4.1
instead of libsoup2.4 and webkit2gtk 4.0. You can backport the commits
from the linked merge proposal.

This will also allow you to re-enable the spice plugin.

Thank you,
Jeremy Bicha

Bug#1021132: pyqt5-dev-tools: pylupdate5 will not work in a cowbuilder shell

[Dmitry Shachnev]

Hi Georges!

On Sun, Oct 02, 2022 at 07:45:44PM +0200, Georges Khaznadar wrote:
> Dear Maintainer,
>
> When I run `gbp buildpackage --git-pbuilder` to check debian packages,
> it fails when pylupdate5 is invoked:
>
> ---8<--
>   File "/usr/lib/python3/dist-packages/PyQt5/pylupdate_main.py", line 73, in
> _encoded_path
> return path.encode(locale.getdefaultlocale()[1])
> TypeError: encode() argument 'encoding' must be str, not None
> ---8<--
>
> This happens since Python3 became Python3.10: in a cowbuilder shell,
> locale.getdefaultlocale() returns now (None, None), which may be legitimate.
> However it should not prevent pylupdate to make its work. In this case,
> the rigth thing to do might be: `encoding="C"; return path.encode(encoding)`

Thanks for the patch.

What is upstream status of it? Can you forward it (subscribe to the mailing
list [1] and send an email there) or you prefer if I do it?

[1]: https://www.riverbankcomputing.com/mailman/listinfo/pyqt

> I pushed such a change into our Salsa repository, and I shall make an upload 
> to
> DELAYED+15; please feel free to tell me to cancel this upload.
>
> Thank you in advance for any comment.

As you are member of python-team, you can do "Team upload" instead of
"Non-maintainer upload" (with normal version bump).

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#1021210: ITP: woof -- continuation of the Doom source port MBF targeted at modern systems

[Fabian Greffrath]

Package: wnpp
Severity: wishlist
Owner: Fabian Greffrath 
X-Debbugs-Cc: debian-de...@lists.debian.org, Debian Games Team 


* Package name: woof
  Version : 10.3.0
  Upstream Author : Fabian Greffrath 
* URL : Debian Games Team
* License : GPL-2.0+ and others
  Programming Lang: C (with CMake build system)
  Description : continuation of the Doom source port MBF targeted at modern 
systems

Woof! is a continuation of Lee Killough's Doom source port MBF
targeted at modern systems.
.
MBF stands for "Marine's Best Friend" and is widely regarded as the
successor of the Boom source port by TeamTNT. It serves as the code
base for popular Doom source ports such as PrBoom+/DSDA-Doom or The
Eternity Engine. As the original engine was limited to run only under
MS-DOS, it has been ported to Windows by Team Eternity under the name
WinMBF in 2004. Woof! is developed based on the WinMBF code with the
aim to make MBF more widely available and convenient to use on modern
systems.
.
To achieve this goal, this source port is less strict regarding its
faithfulness to the original MBF. It is focused on quality-of-life
enhancements, bug fixes and compatibility improvements. However, all
changes have been introduced in good faith that they are in line with
the original author's intentions and even for the trained eye, this
source port should still look very familiar to the original MBF.
.
In summary, this project's goal is to forward-port MBF.EXE from DOS to
21st century and remove all the stumbling blocks on the way.
Furthermore, just as MBF was ahead of its time, this project dedicates
itself to early adoption of new modding features such as
DEHEXTRA+DSDHacked, UMAPINFO and MBF21.

I am the project's upstream developer and would like to maintain this
package under the umbrella of the Debian Games Team. It is a Doom
source port somewhere between Crispy Doom and PrBoom+ in terms of
complexity and may be considered as PrBoom+'s successor for casual
play whereas DSDA-Doom (the other source port I am going to package
next) is focussed more on demo recording and speed running.

Bug#1001064: Assign grave severity

[Soren Stoutner]

severity 1001064 grave

The version of Electrum currently available in Debian is too old to connect to 
the Electrum network, making the package unusable for all Debian users.

-- 
Soren Stoutner
so...@stoutner.com

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

Bug#971965: man-db: man --html fails with a message beginning "command exited with status 3: [...]"

[Tianyu Chen]

Package: man-db
Version: 2.9.4-2
Followup-For: Bug #971965
X-Debbugs-Cc: billchenchina2...@gmail.com

It seems this bug is caused by Apparmor policies.

Oct  4 02:49:04 xiaoxin-air14 kernel: [13675.566441] audit: type=1400
audit(1664822943.998:45): apparmor="DENIED" operation="file_inherit"
profile="man_groff" name="/tmp/hmanAuLiu7/cp.html" pid=75783 comm="preconv"
requested_mask="w" denied_mask="w" fsuid=1000 ouid=1000
Oct  4 02:49:04 xiaoxin-air14 kernel: [13675.568706] audit: type=1400
audit(1664822943.998:46): apparmor="DENIED" operation="file_inherit"
profile="man_groff" name="/tmp/hmanAuLiu7/cp.html" pid=75784 comm="tbl"
requested_mask="w" denied_mask="w" fsuid=1000 ouid=1000


Related bugs:

https://bugs.debian.org/948238
https://bugs.debian.org/926450

Also Ubuntu and LinuxMint:

https://bugs.launchpad.net/man-db/+bug/1389682/
https://bugs.launchpad.net/linuxmint/+bug/1443604


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

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

Versions of packages man-db depends on:
ii  bsdextrautils  2.36.1-8+deb11u1
ii  debconf [debconf-2.0]  1.5.77
ii  dpkg   1.20.12
ii  groff-base 1.22.4-6
ii  libc6  2.31-13+deb11u4
ii  libgdbm6   1.19-2
ii  libpipeline1   1.5.3-1
ii  libseccomp22.5.1-1+deb11u1
ii  zlib1g 1:1.2.11.dfsg-2+deb11u2

man-db recommends no packages.

Versions of packages man-db suggests:
ii  apparmor2.13.6-10
ii  firefox-esr [www-browser]   102.3.0esr-1~deb11u1
ii  google-chrome-stable [www-browser]  106.0.5249.61-1
pn  groff   
ii  less551-2

-- debconf information:
  man-db/auto-update: true

Bug#1021032: Your mail

[mh]

On Mon, 3 Oct 2022 07:46:54 +0100 Rik Mills  wrote:
...

> Since it seems to affect only the Qt UI, it is most probably a
> problem with the last Qt update. Again, please check with
> --no-embedded-video."
>
>

I have the same black screen problem. "vlc --no-embedded-video"
circumvents/solves the problem.

My timeline as well strengthens your statement that QT
might be responsible for the black screen as this fits my update
timeline:

last vlc update was September, 23., and it worked until yesterdays QT
update.

Thanks

Michael

Bug#1012250: gscan2pdf: flaky autopkgtest: regularly times out

[Paul Gevers]

Hi Jeff,

On 03-10-2022 13:39, Jeff wrote:
This morning, I see that for s390x in testing, there was a timeout and 
failure (both in 380_cancel_user_defined_with_pids), as well as two passes:


https://ci.debian.net/packages/g/gscan2pdf/testing/s390x/


Ends with:
"""
"Too many open files" at t/380_cancel_user_defined_with_pids.t line 40.
"""
Might that be a hint? Maybe a race condition under a high amount of 
parallelism built?


Again, the failure rate with 27 hour timeout wasn't that high, but 27 
hours is really long... Hmm, autopkgtest should have sane default 
timeouts, and now I take a careful look, I notice that the timeout 
happens during *building* of your package, even *before* the test is 
started. Do you really need the "build-needed" restriction? Our spec [1] 
has this:

Please use this considerately, as for large builds it unnecessarily
builds the entire project when you only need a tiny subset (like the
tests/ subdirectory). It is often possible to run ``make -C tests``
instead, or copy the test code to ``$AUTOPKGTEST_TMP`` and build it
there with some custom commands. This cuts down the load on the
Continuous Integration servers and also makes tests more robust as
it prevents accidentally running them against the built source tree
instead of the installed packages.
What's more, autopkgtest is really ment to test as-installed packages, 
building the binaries again makes it very easy to test the freshly built 
binaries *instead of* the installed binaries. (Not saying that's the 
case here, but building the binaries is something that I think tests 
should hardly ever do.)


I also see that all the other architectures have passes, but this is not 
reflected by the summary page:


https://ci.debian.net/packages/g/gscan2pdf/

Any idea why?


This page only shows "pure" runs because showing failures cause by 
packages in other suites that are not allowed to migrate is confusing. 
We do want to change that page, but UI is difficult and we haven't found 
the time and energy to implement it.


Given that gscan2pdf is a desktop app, I assume there are no users on 
s390x. Hence, I'm not sure of the value of debugging on s390x. According 
to:


https://www.debian.org/doc/debian-policy/ch-source.html

DEB_HOST_ARCH and DEB_TARGET_ARCH should be set. I'm tempted to test for 
s390x in the test target in debian/rules and skip accordingly. Objections?


autopkgtest also supports an "Architecture" field in the d/t/control 
file that takes negation. So, why not use "Architecture: !s390x" if you 
just want to disable the test there?


Given that the packages in stable are, well, stable, and I made no 
changes to those parts of gscan2pdf, I wonder what happened in the rest 
of the environment between stable and testing. I'd be interested to 
confirm this by pushing the stable version of gscan2pdf through testing 
s390x a couple of times.


Not sure you can do that, except by using "+really" version number 
uploads. Also, see:

https://ci.debian.net/data/autopkgtest/stable/armel/g/gscan2pdf/23364480/log.gz
So stable is not free from the issue.


Paul

[1] 
https://salsa.debian.org/ci-team/autopkgtest/-/raw/master/doc/README.package-tests.rst


OpenPGP_signature
Description: OpenPGP digital signature

Bug#986047: Second bug report

[Simon McVittie]

On Mon, 03 Oct 2022 at 14:23:42 -0400, Daniel wrote:
> Dear maintainer, I had the same problem using Gimp on my machine, as well.

I suspect you had a different problem with the same high-level
symptoms. This is a very old bug report against a version of gimp from
Debian 10, but you seem to be using Debian testing/unstable.

libglib2.0-0 version 2.74.0-1 in testing is known to cause gimp to crash.
Version 2.74.0-2 should fix that, and should reach testing today (but
it might be a few hours or days before your mirror receives that version).

If you can reproduce this crash *after* upgrading to libglib2.0-0 version
2.74.0-2, please report it separately so that your bug report has all
the details of the packages you have installed.

Thanks,
smcv

Bug#986047: Second bug report

[Daniel]

Dear maintainer, I had the same problem using Gimp on my machine, as well.
If it helps, here's a second bug report (from my machine)




```
GNU Image Manipulation Program version 2.10.32
git-describe: GIMP_2_10_32
Build: unknown rev 0 for linux
# C compiler #
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/12/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 12.1.0-8'
--with-bugurl=file:///usr/share/doc/gcc-12/README.Bugs
--enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,m2 --prefix=/usr
--with-gcc-major-version-only --program-suffix=-12
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-plugin --enable-default-pie
--with-system-zlib --enable-libphobos-checking=release
--with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch
--disable-werror --enable-cet --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none=/build/gcc-12-WXbu70/gcc-12-12.1.0/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-12-WXbu70/gcc-12-12.1.0/debian/tmp-gcn/usr
--enable-offload-defaulted --without-cuda-driver --enable-checking=release
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.1.0 (Debian 12.1.0-8)

# Libraries #
using babl version 0.1.96 (compiled against version 0.1.92)
using GEGL version 0.4.38 (compiled against version 0.4.38)
using GLib version 2.74.0 (compiled against version 2.72.3)
using GdkPixbuf version 2.42.9 (compiled against version 2.42.9)
using GTK+ version 2.24.33 (compiled against version 2.24.33)
using Pango version 1.50.10 (compiled against version 1.50.9)
using Fontconfig version 2.13.1 (compiled against version 2.13.1)
using Cairo version 1.16.0 (compiled against version 1.16.0)

```
> fatal error: Segmentation fault

Stack trace:
```

# Stack traces obtained from PID 60419 - Thread 60419 #

[New LWP 60420]
[New LWP 60421]
[New LWP 60422]
[New LWP 60423]
[New LWP 60424]
[New LWP 60425]
[New LWP 60426]
[New LWP 60427]
[New LWP 60428]
[New LWP 60429]
[New LWP 60496]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
__GI___libc_read (nbytes=256, buf=0x7ffcfcc5dd70, fd=16) at
../sysdeps/unix/sysv/linux/read.c:26
  Id   Target Id   Frame
* 1Thread 0x7f5a34e8a380 (LWP 60419) "gimp"__GI___libc_read
(nbytes=256, buf=0x7ffcfcc5dd70, fd=16) at
../sysdeps/unix/sysv/linux/read.c:26
  2Thread 0x7f5a343ff640 (LWP 60420) "worker"  syscall () at
../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
  3Thread 0x7f5a33bfe640 (LWP 60421) "worker"  syscall () at
../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
  4Thread 0x7f5a333fd640 (LWP 60422) "worker"  syscall () at
../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
  5Thread 0x7f5a32bfc640 (LWP 60423) "worker"  syscall () at
../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
  6Thread 0x7f5a2a3fb640 (LWP 60424) "worker"  syscall () at
../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
  7Thread 0x7f5a323fb640 (LWP 60425) "worker"  syscall () at
../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
  8Thread 0x7f5a31bfa640 (LWP 60426) "worker"  syscall () at
../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
  9Thread 0x7f5a2bfff640 (LWP 60427) "gmain"   0x7f5a358fda3f
in __GI___poll (fds=0x558e29aa34a0, nfds=2, timeout=-1) at
../sysdeps/unix/sysv/linux/poll.c:29
  10   Thread 0x7f5a2b7fe640 (LWP 60428) "gdbus"   0x7f5a358fda3f
in __GI___poll (fds=0x558e29abb4a0, nfds=3, timeout=-1) at
../sysdeps/unix/sysv/linux/poll.c:29
  11   Thread 0x7f59fe9ff640 (LWP 60429) "async"   syscall () at
../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
  12   Thread 0x7f59fe1fe640 (LWP 60496) "swap writer" syscall () at
../sysdeps/unix/sysv/linux/x86_64/syscall.S:38

Thread 12 (Thread 0x7f59fe1fe640 (LWP 60496) "swap writer"):
#0  syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
#1  0x7f5a35ba043f in g_cond_wait () at
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#2  0x7f5a361397e9 in  () at /lib/x86_64-linux-gnu/libgegl-0.4.so.0
#3  0x7f5a35b76aed in  () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#4  0x7f5a35887b27 in start_thread (arg=) at
./nptl/pthread_create.c:435
ret = 
pd = 
unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140024492320320,
-3472451944112346351, 140024492320320, 11, 140025421920416, 0,
3565904660874242833, 

Bug#1017098: decopy: may overturn the hierarchy of files w.r.t. the base debian/copyright file

[Maximiliano Curia]

On 2022-09-29 10:22, Jochen Sprickerhof wrote:

But why does decopy strip "et al."?


I looked into the git history but there is no comment why it was added.


It's part of the name normalization logic, it could be extended so if 
the author is set as "$name et all" somewhere to show the entry as such, 
even if it's listed as "$name" everywhere else. But I don't really see 
value in the added information (see bellow), thus it's just dropped.
(in retrospective, it would have been better to call that piece of code 
name normalization instead of simply applying some regexps.)


What's the copyright information that you are adding by that? Who is 
others, who would you contact if you need to relicense?  Why et all in 
french and, not any of the other languages of the world? Any of this 
information is relevant to a Debian package?



And what's the correct way to specify that a copyright is owned
by one main owner plus many other co-owners?



I'm actually not sure of the implication of this. Stating that there
is someone besides the named person holding the copyright does not
really give you any information.


:)


I mean, the correct way for decopy.



If you really want to add it, you could first off all separate it from
the first name. So in your example make Masato Taruishi and et al. two
separate entries:

2002-2020, Masato Taruishi
2002-2020, et alii (or others or..)


Whatever you add in the debian/copyright should be maintained, that's 
the original intention (unless the files mentioned are no longer 
present).


Sadly this part also is missing a normalization logic to merge with the 
found authors. I thought I would do that for the diff mode.


--
Saludos /\/\ /\ >< `/

Bug#1021209: pyqt6: Import latest version

[Bastian Germann]

Source: pyqt6
Version: 6.3.1-1
Severity: wishlist

Please import version 6.4 once the Qt 6.4 packages have arrived in unstable.
You can then add python3-pyqt6.qtpdf based on qt6-pdf-dev.

Bug#728024: rejected upstream

[Joey Hess]

I have rejected this idea in upstream commit 
28ec94ee7fb080ec31a29fe121f2e94bc68e6fba:

> I think this is out of scope for git-annex. It's not its place to change
> what files git allows to be version controlled.

I will not change my mind regarding this. Of course, Debian can patch
git-annex to behave differently if they like, but I would strongly
advise against it.

I recommend this Debian bug report be closed.

-- 
see shy jo


signature.asc
Description: PGP signature

Bug#1021208: New upstream version 0.4.1

[Guido Günther]

Source: libgusb
Version: 0.3.10-1
Severity: wishlist

Version 0.4.1 was just released and 0.4.0 is about 1mo old. Would be
great to have the package updated.

Cheers,
 -- Guido

Bug#789225: seems fixed?

[Joey Hess]

I don't know the version, but I'm sure this was fixed years ago.

-- 
see shy jo


signature.asc
Description: PGP signature

Bug#1021207: lintian: Please reconsider the type and size of field-too-long

[Mathias Behrle]

Package: lintian
Version: 2.115.3
Severity: normal
X-Debbugs-Cc: team+tryton-t...@tracker.debian.org


Dear Maintainers,

I was hit by

E: tryton-modules-all: field-too-long Depends (5604 chars > 5000)
N:
N:   The length of the specified field is too long.
N: 
N:   Overly-long fields not only can break some tools tools (eg.
reprepro(1))
N:   they can waste space as they are shipped to all users. 
N: 
N:   Please reduce the number of characters.
N: 
N:   Please refer to Bug#942493 for details.
N:
N:   Visibility: error
N:   Show-Always: no
N:   Check: fields/length   

The one and only purpose of tryton-modules-all is to list all
available Tryton modules in Depends (or Recommends, but that shouldn't
matter). For now I have added a lintian-override, but of course I don't
want to break infrastructure.

Looking at #942943 and #942487 it looks as if the issue with reprepro
should be mitigated with 
https://salsa.debian.org/debian/reprepro/-/commit/7cb8fcf53c077467c4f38b5a48f706e7b5f75f4c

So I am asking for re-evaluation and/or advice

- if this limitation still stands?
- if the former is true this shouldn't be rather a warning than an
  error?
- if the former is true the only way out is to split the Depends into
  sub-packages?



-- 

Mathias Behrle
PGP/GnuPG key availabable from any keyserver, ID: 0xD6D09BE48405BBF6
AC29 7E5C 46B9 D0B6 1C71  7681 D6D0 9BE4 8405 BBF6

Bug#1021175: calibre - content server only listen on IPv4

[yokota]

Hello, Bastian.

> The embedded only listens on 0.0.0.0, aka AF_INET, aka IPv4.  This makes
> the content server quite unusable in the current internet, where IPv4
> connectivity gets sparingly, either by CG-NAT used by the provider or by
> IPv6-only environments.

You can change listening address from preferences window.
Change listening address from "Preferences"->"Sharing"->"Sharing over
the net"->"Advanced"->"The interface on which to listen for
connections:".
The default value is "0.0.0.0", but you can change to "::" for IPv6.
And use "127.0.0.1" or "::1" to limit access from localhost.

Here is document text for this option:
> The default is to listen on all available IPv4 interfaces. You can change 
> this to, for example, "127.0.0.1" to only listen for connections from the 
> local machine, or to "::" to listen to all incoming IPv6 and IPv4 connections.

--
YOKOTA

Bug#1021043: closed by Debian FTP Masters (reply to Dennis Filder ) (Bug#1021043: fixed in linphone 5.0.37-6)

[Daniel Kahn Gillmor]

On Mon 2022-10-03 08:51:05 +, Debian Bug Tracking System wrote:
>  linphone (5.0.37-6) unstable; urgency=medium
>  .
>* Import upstream fix for crashes on PUBLISH messages without
>  SIP-Etags (Closes: #1021043).

Dennis, thanks for this prompt fix!

To confirm: I've upgraded to liblinphone10 5.0.37-6, and
linphone-desktop works for me again without any of the crashes i was
seeing.

With great appreciation,

 --dkg


signature.asc
Description: PGP signature

Bug#1021200: wrong build-dependency libservlet-api-ava

[tony mancill]

On Mon, Oct 03, 2022 at 10:13:22AM -0700, tony mancill wrote:
> On Mon, Oct 03, 2022 at 05:36:17PM +0200, Pierre Gruet wrote:
> > Package: groovy
> > Version: 2.4.21-3
> > Severity: important
> > 
> > Hello,
> > 
> > The version 2.4.21-3 of groovy that was uploaded yesterday wrongly includes
> > libservlet-api-ava
> > as a build-dependency. This mispelled package name has been introduced in an
> > attempt to solve Bug #1020429.
> > 
> > Build dependencies of groovy and of its rdeps cannot be satisfied.
> 
> Thank you in advance for suggestions on how to get the auto-builders to
> build 2.4.21-4.  The package builds successfully against 2.4.21-2.  Do I
> need to request manual removal of 2.4.21-3 from the archive, or is there
> another way to introduce a binary build of 2.4.21-4 to unstable?

I found it.  I need to request a binNMU [1] as per [2].

Apologies to all for the expensive typo...

[1] https://wiki.debian.org/binNMU
[2] https://release.debian.org/wanna-build.html


signature.asc
Description: PGP signature

Bug#1012196: buglist

[André]

Control: tags -1 -moreinfo

I did not receive the bts email.

> No. Please check the copyright format description for the "with" keyword.
> Also, please try to present the copyright info in a more consice way. 
When two file groups have the same copyright
> holders please merge them (combining the years to a year enumeration 
or year range).
I'm not sure if I understand correct but tried to merge groups with same 
copyright holders and licence.


> I have already given you a hint that
> "plugins/ipconsole/ipython_view.py by IBM Corporation is licensed 
under another variant of the BSD-3-Clause."
> So, please do not use Michael Bostock's version for that file match 
but add a BSD-3-clause-IBM variant.
> You should also remove his copyright line from the License: section 
because that is already in the Copyright: section.

Thinking this is fixed now.

> You have not explained "override_dh_usrlocal:".
Removed. This was legacy code.

Bug#1004043: seems fixed

[Joey Hess]

I was able to reproduce this using version 8.20210128.

It seems to be fixed in version 10.20220526.

I think this was fixed by commit
1cacfd1b199b1a9a093716e04afd7e5ef4bd26a5. While that commit was fixing
problems caused by test suite parallization that happened well after
this bug was filed, so cannot be the cause of the bug itself, the commit
really fixes a deeper concurrency problem that could have also affected
older versions of git-annex.

-- 
see shy jo


signature.asc
Description: PGP signature

Bug#1021206: new upstream release fixes numerous reversions and bugs

[Joey Hess]

Package: git-annex
Version: 10.20220724-1
Severity: normal

The current git-annex release is 10.20221003, and it fixes a number of
reversions and bugs that are present in the version in Debian.

I've gathered the main ones here, although if you chose to cherry-pick
these commits, you would need to watch out for other commits they may
depend on. My recommendation would be to update to the new version
instead.

This one avoids data loss, although only when someone has an
unfortunately placed symlink:

ed39979ac8ec6ff2a279939440574927d5cc894a
  * import: Avoid following symbolic links inside directories being
imported. 

Git integration fixes:

a23fd7349fb9cd5b5b0d6c4790d58fe205ca6f3b
  * Work around bug in git 2.37 that causes a segfault
when core.untrackedCache is set, which broke git-annex init.
ce65f11de081ec3903ac388c59f5fdf021ccd237
bfa451fc4e621700883fb3b34600bdf71f515a62
  * enable-tor: Fix breakage caused by git's fix for CVE-2022-24765.

Fixes for regressions in git-annex:

94029995fa2754ed8c22f23cf7bf0157edeeef7a
Fix a regression in 10.20220624 that caused git-annex add to crash when
there was an unstaged deletion.
8a4cfd4f2d672b57a97e53b6d141378770171e66
Fix crash importing from a directory special remote that contains a broken
symlink.
1fe9cf7043e9c24bd8719d45f68f349c0c87e215
  * Improve handling of directory special remotes with importtree=yes whose
ignoreinode setting has been changed. When getting a file from such a
remote, accept the content that would have been accepted with the
previous ignoreinode setting.
8d26fdd6709ba341570bf665f1ace0556bdcf5cb
  * Fix a reversion that prevented git-annex from working in a
repository when --git-dir or GIT_DIR is specified to relocate the git
directory to somewhere else.
(Introduced in version 10.20220525)

Other significant bug fixes:

0756f4453d988776e689855851b472f1060889c3
0ffc59d34107a3ee671b90fc7c59ca09c00abbf5
  * directory, adb: Fixed a bug with importtree=yes and multiple files
in the special remote have the same content, that caused it to
refuse to get a file from the special remote, incorrectly complaining
that it had changed, due to only accepting the inode+mtime of one file
(that was since modified or deleted) and not accepting the inode+mtime
of other duplicate files.
f1c85ac11b3b7004bf1b1917f9c504622d15e1aa
  * p2p: Pass wormhole the --appid option before the receive/send command,
as it does not accept that option after the command

-- 
see shy jo


signature.asc
Description: PGP signature

Bug#1021205: transition: simdjson

[M. Zhou]

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

Hi release team,

I'd like to start the transition of simdjson. It has only two reverse
dependencies in testing:

 cloudflare-ddns
 pcm

Both of them passed my local test with amd64 host.


Ben file:

title = "simdjson";
is_affected = .depends ~ "libsimdjson9" | .depends ~ "libsimdjson13";
is_good = .depends ~ "libsimdjson13";
is_bad = .depends ~ "libsimdjson9";
Thank you for using reportbug

Bug#1019745: RFP: sphinx-enum-tools -- expand Python's enum module in Sphinx documentation

[Bastian Germann]

The work -in-progress packaging is at 
https://salsa.debian.org/python-team/packages/enum-tools

Bug#1020997: mirror.sitsa.com.ar: out-of-date

[Franco E. Lazos - SiTSA Telecomunicaciones]

Hi Julien and team!,

The mirror is now up to date and working properly.

You can check that ftpsync was able to successfully update the file 
"http://mirror.sitsa.com.ar/debian/project/trace/mirror.sitsa.com.ar; after 
syncing.

You can now re-add this repository to the Debian repository mirror list.

Best regards,

Franco E. Lazos
Departamento Técnico
SiTSA – Telecomunicaciones
Entre Rios 1435 – (X5900AGI) – Villa María – CBA-ARG
Fijo (54 353) 453-1146 | INT 107
Móvil (54 351) 248-2514
e-Mail franco.la...@sitsa.com.ar 
Website www.sitsa.com.ar  / www.trackmaster.com.ar 

 
P Proteja el medio ambiente, no imprima este mail sino es necesario.
 
ATTORNEY - CLIENT PRIVILEGED INFORMATION
 
Este mensaje es privado y confidencial, y está dirigido exclusivamente  a su(s) 
destinatario(s). Si usted ha recibido este mensaje por error,  debe abstenerse 
de distribuirlo, copiarlo o usarlo en cualquier sentido. 
Asimismo, le agradecemos comunicarlo al remitente y borrar el mensaje y 
cualquier documento adjunto
 
This email and any files transmitted with it are confidential and  intended 
solely for the use of the individual or entity to whom they are  addressed.
Please notify the sender immediately by e-mail if you have received this e-mail 
by mistake and delete this e-mail from your system.



> El 2 oct. 2022, a las 01:32, Franco E. Lazos - SiTSA Telecomunicaciones 
>  escribió:
> 
> Hi Julien,
> 
> I think I found some data inconsistencies when migrating the mirror (the 
> /debian/ directory) from the old server to the new one.
> 
> I will immediately proceed to recreate it completely. I will confirm the 
> operability of this mirror soon.
> 
> Please excuse the inconvenience caused.
> 
> Regards,
> 
> Franco E. Lazos
> Departamento Técnico
> SiTSA – Telecomunicaciones
> Entre Rios 1435 – (X5900AGI) – Villa María – CBA-ARG
> Fijo (54 353) 453-1146 | INT 107
> Móvil (54 351) 248-2514
> e-Mail franco.la...@sitsa.com.ar 
> Website www.sitsa.com.ar  / www.trackmaster.com.ar 
> 
>  
> P Proteja el medio ambiente, no imprima este mail sino es necesario.
>  
> ATTORNEY - CLIENT PRIVILEGED INFORMATION
>  
> Este mensaje es privado y confidencial, y está dirigido exclusivamente  a 
> su(s) destinatario(s). Si usted ha recibido este mensaje por error,  debe 
> abstenerse de distribuirlo, copiarlo o usarlo en cualquier sentido. 
> Asimismo, le agradecemos comunicarlo al remitente y borrar el mensaje y 
> cualquier documento adjunto
>  
> This email and any files transmitted with it are confidential and  intended 
> solely for the use of the individual or entity to whom they are  addressed.
> Please notify the sender immediately by e-mail if you have received this 
> e-mail by mistake and delete this e-mail from your system.
> 
> 
> 
>> El 30 sep. 2022, a las 09:04, Julien Cristau > > escribió:
>> 
>> Hi Franco,
>> 
>> http://mirror.sitsa.com.ar/debian/project/trace/mirror.sitsa.com.ar 
>>  is
>> dated July 20.  ftpsync should be updating it after each successful
>> sync.
>> 
>> Cheers,
>> Julien
>> 
>> On Fri, Sep 30, 2022 at 08:40:46AM -0300, Franco E. Lazos - SiTSA 
>> Telecomunicaciones wrote:
>>> Hi Julien and team,
>>> 
>>> Our replica server is working properly and is up to date.
>>> The only thing that was done (perhaps approximately 2 months ago) was to
>>> migrate it to a machine with greater processing and storage capacity.
>>> 
>>> Feel free to request any modification that you think is convenient.
>>> 
>>> Best regards,
>>> 
>>> P.S: the migration was quick in terms of availability because no changes 
>>> were
>>> made to production until all the installation processes for the new machine
>>> were complete.
>>> 
>>> Franco E. Lazos
>>> Departamento Técnico
>>> SiTSA – Telecomunicaciones
>>> Entre Rios 1435 – (X5900AGI) – Villa María – CBA-ARG
>>> Fijo (54 353) 453-1146 | INT 107
>>> Móvil (54 351) 248-2514
>>> e-Mail franco.la...@sitsa.com.ar 
>>> Website www.sitsa.com.ar / www.trackmaster.com.ar
>>> 
>>> P Proteja el medio ambiente, no imprima este mail sino es necesario.
>>> 
>>> 
>>> 
>>> ATTORNEY - CLIENT PRIVILEGED INFORMATION
>>> 
>>> Este mensaje es privado y confidencial, y está dirigido exclusivamente  a 
>>> su(s)
>>> destinatario(s). Si usted ha recibido este mensaje por error,  debe 
>>> abstenerse
>>> de distribuirlo, copiarlo o usarlo en cualquier sentido. 
>>> Asimismo, le agradecemos comunicarlo al remitente y borrar el mensaje y
>>> cualquier documento adjunto
>>> 
>>> This email and any files transmitted with it are confidential and  intended
>>> solely for the use of the individual or entity to whom they are  addressed.
>>> Please notify the sender immediately by e-mail if you have 

Bug#1021200: wrong build-dependency libservlet-api-ava

[tony mancill]

On Mon, Oct 03, 2022 at 05:36:17PM +0200, Pierre Gruet wrote:
> Package: groovy
> Version: 2.4.21-3
> Severity: important
> 
> Hello,
> 
> The version 2.4.21-3 of groovy that was uploaded yesterday wrongly includes
> libservlet-api-ava
> as a build-dependency. This mispelled package name has been introduced in an
> attempt to solve Bug #1020429.
> 
> Build dependencies of groovy and of its rdeps cannot be satisfied.

Thank you in advance for suggestions on how to get the auto-builders to
build 2.4.21-4.  The package builds successfully against 2.4.21-2.  Do I
need to request manual removal of 2.4.21-3 from the archive, or is there
another way to introduce a binary build of 2.4.21-4 to unstable?


signature.asc
Description: PGP signature

Bug#1021183: opendkim: Opendkim complaining insecure keys by assumption

[Patrik Schindler]

Hello David,

thanks for the quick response. After comparing your configuration to mine, I 
resolved the issue by trading possible security implications. See below.


Am 03.10.2022 um 15:15 schrieb David Bürgin :

> Can you include the steps to reproduce this? I don’t see this behaviour on my 
> installation (opendkim 2.11.0~beta2-5).

Will try to do so.

> Some of my configuration bits below:
> 
> $ grep -i -e keyfile -e userid -e umask -e socket -e requiresafekeys 
> /etc/opendkim.conf
> KeyFile /etc/dkimkeys/2020.private
> UserID  opendkim
> UMask   007
> Socket  local:/var/spool/postfix/opendkim/opendkim.sock

Mine is here.

UMask   002
Socket  local:/var/run/opendkim/opendkim.sock
RequireSafeKeys no
UserID  opendkim

> $ sudo ls -ld /etc/dkimkeys{,/2020.private}
> drwx-- 2 opendkim opendkim 4096 Aug 25  2021 /etc/dkimkeys
> -rw--- 1 opendkim opendkim 1679 Nov 20  2020 /etc/dkimkeys/2020.private

I do have multiple domains configured and thus use /etc/opendkim/domainname as 
base directory for keyfiles. Those belong to root:opendkim and are mode 2755.

-rw-r- 1 root opendkim 887 Oct 26  2015 
/etc/opendkim/pocnet.net/m201510.private
-rw-r--r-- 1 root opendkim 323 Oct 26  2015 /etc/opendkim/pocnet.net/m201510.txt

> $ sudo ls -ld /var/spool/postfix/opendkim{,/opendkim.sock}
> drwxr-x--- 2 opendkim opendkim 27 Sep 29 16:32 /var/spool/postfix/opendkim
> srwxrwx--- 1 opendkim opendkim  0 Sep 29 16:32 
> /var/spool/postfix/opendkim/opendkim.sock

-rw-r--r-- 1 root root 7 Oct  3 14:18 /var/run/opendkim/opendkim.pid
srwxrwxr-x 1 opendkim opendkim 0 Oct  3 14:18 /var/run/opendkim/opendkim.sock

> $ groups postfix | grep -o opendkim
> opendkim

# groups postfix | grep -o opendkim
opendkim


When I've configured opendkim for the first time, I tried to keep the key files 
belonging to root, so they couldn't be changed from opendkim itself — lessen 
attack surface.

After chown opendkim, and chmod 400 to the private key files, the warning 
message is — to be expected — gone, because there is no group access granted 
anymore. But there is a small — probably mostly theoretical — decrease in 
security, because key files now belong to the opendkim user, and a missing 
write bit can be overridden on owner match — having done this sometimes with vi 
and text files.

What's your opinion on that?

Thanks!

:wq! PoC

Bug#1021204: RFP: whey -- A simple Python wheel builder for simple projects

[Bastian Germann]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: debian-pyt...@lists.debian.org, nilsonfsi...@hotmail.com
Control: block -1 by 1020324
Control: block 1019745 by -1

* Package name: whey
  Version : 0.0.23
  Upstream Author : Dominic Davis-Foste 
* URL : https://github.com/repo-helper/whey
* License : Expat
  Programming Lang: Python
  Description : A simple Python wheel builder for simple projects

whey:
  * supports PEP 621 metadata.
  * can be used as a PEP 517 build backend.
  * creates PEP 427 wheels.
  * handles type hint files (py.typed and *.pyi stubs).

Bug#761045: Fw: Franz Schrober

[Redwanul Numan]

https://bit.ly/3e2k44M

Bug#790750: Fw:Franz Schrober

[Redwanul Numan]

https://bit.ly/3rsKqju

Bug#1019974: uim: FTBFS on armhf: [Makefile:871: installed-modules.scm] Segmentation fault

[Adrian Bunk]

Control: tags -1 patch

On Sat, Sep 17, 2022 at 09:43:49PM +0300, Dmitry Shachnev wrote:
>...
> make  -C ../uim uim-module-manager && \
> LIBUIM_SYSTEM_SCM_FILES=/home/mitya57/uim-1.8.8/sigscheme/lib 
> LIBUIM_SCM_FILES=/home/mitya57/uim-1.8.8/scm 
> LIBUIM_PLUGIN_LIB_DIR=/home/mitya57/uim-1.8.8/uim/.libs UIM_DISABLE_NOTIFY=1 
> ../uim/uim-module-manager \
> --path ../scm --register "anthy" "anthy-utf8"  "skk" "tutcode" 
> "byeoru" "latin" "elatin" "m17nlib" "xmload" "pyload" "viqr" "ipa-x-sampa" 
> "look" "ajax-ime" "google-cgiapi-jp" "baidu-olime-jp" "yahoo-jp"
> make[3]: Entering directory '/home/mitya57/uim-1.8.8/uim'
> make[3]: 'uim-module-manager' is up to date.
> make[3]: Leaving directory '/home/mitya57/uim-1.8.8/uim'
> make[2]: *** [Makefile:871: installed-modules.scm] Segmentation fault
> 
> Full build log is attached.
> 
> This can also be seen on reproducible builds server:
> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/armhf/uim.html
> 
> Also attached is valgrind output of the failed command.

The workaround below fixes the build.

I looked through the backtrace in gdb, but debugging a Scheme 
interpreter is outside of what I am feeling comfortable doing.

> Dmitry Shachnev

cu
Adrian

--- debian/rules.old2022-10-03 08:32:51.572032357 +
+++ debian/rules2022-10-03 08:34:11.469273120 +
@@ -8,6 +8,12 @@
 
 export DEB_LDFLAGS_MAINT_APPEND = -Wl,--as-needed
 
+# workaround for #1019974
+ifneq (,$(filter $(DEB_HOST_ARCH), armel armhf x32))
+  export DEB_CFLAGS_MAINT_APPEND += -O1
+endif
+
+
 DPKG_EXPORT_BUILDFLAGS = 1
 include /usr/share/dpkg/buildflags.mk
 

Bug#900173: probably fixed

[Joey Hess]

commit 947d2a10bcf80e74758f65b3cc3fd5ac1bff3fa8
Author: Joey Hess 
Date:   Wed May 12 15:08:03 2021 -0400

assistant: Fix a crash on startup by avoiding using forkProcess

ghc 8.8.4 seems to have changed something that broke code that has been
successfully using forkProcess since 2012. Likely a change to GC internals.

Since forkProcess has never had clear documentation about how to
use it safely, avoid using it at all. Instead, when git-annex needs to
daemonize itself, re-run the git-annex command, in a new process group
and session.

-- 
see shy jo


signature.asc
Description: PGP signature

Bug#1021203: ITP: node-postcss-modules -- PostCSS plugin to use CSS Modules everywhere

[Yadd]

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

* Package name: node-postcss-modules
  Version : 5.0.0
  Upstream Author : Alexander Madyankin 
* URL : https://github.com/madyankin/postcss-modules
* License : Expat
  Programming Lang: JavaScript
  Description : PostCSS plugin to use CSS Modules everywhere

node-postcss-modules will provide a PostCSS plugin to use CSS Modules
everywhere. Not only at the browser side.

This package is needed at least to update vue.js (libjs-vue and
node-vue) to version 4.x

It will be maintained under JS Team umbrella

Bug#965135: probably fixed in 8.20201007

[Joey Hess]

This bug seems very similar to a known fixed git-annex bug.

commit 922621301ae750e9ee86807ae21709e2e5b2d352
Author: Joey Hess 
Date:   Thu Sep 17 17:27:42 2020 -0400

Serialize use of C magic library, which is not thread safe.

This fixes failures uploading to S3 when using -J.

-- 
see shy jo


signature.asc
Description: PGP signature

Bug#1009643: [Pkg-puppet-devel] Bug#1009643: Puppet: Fails to work with Ruby 3.0

[Michael Prokop]

* Antoine Beaupré [Mon Oct 03, 2022 at 12:28:06PM -0400]:
> On 2022-10-03 18:21:46, Michael Prokop wrote:
> > AFAICT (thanks to our daily Grml ISO builds) this RC bug caused
> > puppet to get removed from Debian/testing, so unless this gets fixed
> > we won't have puppet in bookworm? Is anyone taking care of this?
> 
> Puppet 5 has been EOL for years. It's a good thing it's gone from
> bookworm, and a deliberate act on part of the Puppet package
> maintainers.

ACK :)

> We've packaged puppet-agent 7 and uploaded to unstable, it should
> trickle down in bookworm in a day or two if all goes well.

Oh, that's great news! :)

> We're working on packaging puppetserver 7. You can follow that work and
> more here:
> https://wiki.debian.org/Teams/Puppet/Work

Thanks, both for your fast response as well as working on the puppet
packaging! \o/

regards
-mika-


signature.asc
Description: PGP signature

Bug#976052: ITP: zola -- static site generator

[Jonas Smedegaard]

Quoting Mohd Bilal (2022-10-03 17:21:45)
> On Mon, 02 May 2022 23:04:58 +0200 Jonas Smedegaard  wrote:
> > 0.15.3 draft 2, needs embedding 107 crates (60 missing, 5 broken, 20 
> > outdated, 22 ahead); builds in ~25 minutes; runs except subcommand serve 
> > which needs web assets separately packaged.
> 
> Thanks for working on packaging zola. This is something that I use and 
> would love to see in Debian. I would like to offer my help for making 
> this happen (like packaging missing deps? ). I've had some experience 
> packaging ruby gems.
> 
> Let me know if I can be of any help to you. I'm ready to learn some rust 
> packaging if required.

That sounds lovely - yes, your help packaging dependencies would be much
appreciated!

I see two reasonable approaches to that:

 a) join the Rust team, and follow their packaging style
 b) package *outside* the Rust team using a more common Debian style

What I do personally is b) and I am happy to help guide you.
If you prefer to join the Rust team instead, then let them guide you.
There should be no problem in us using different styles, if only you
please file ITPs for each package that you decide to work on.

As mentioned earlier in this bugreport, I maintain a list of packages
needing packaging - feel free to work on any of those that you like:
https://salsa.debian.org/debian/zola/-/blob/debian/latest/debian/TODO


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#1021202: RM: puppet -- ROM; EOL upstream

[Antoine Beaupre]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: pkg-puppet-de...@alioth-lists.debian.net

Hi,

We've had many discussions about this in the past, but it seems the
time has come to remove src:puppet from Debian.

The 5.5 Puppet agent and "puppetmaster" code that is shipped by this
package has been EOL for almost two years now[1]. It is broken by the
Ruby 3.0 upgrade in Debian[2], and, generally, is just mostly dead code.

Multiple RC bugs have just kicked it out of testing:

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

We have been working on repackaging everything from scratch. Puppet
agent 7 has landed in unstable yesterday[3] and we're still trying to
figure out how to package the Puppet Server 7 code base. This is
currently blocked on jruby things, but we are confident this can be
solved before the bookworm freeze.

Therefore, we hope to ship Puppet Agent and Server 7 in bookworm. The
src:puppet codebase is just one of the blockers we have of course, but
it's a blocker and should therefore be removed from Debian for now.

Details and progress of our work can be seen here:

https://wiki.debian.org/Teams/Puppet/Work

A.

[3] 
https://tracker.debian.org/news/1368401/accepted-puppet-agent-7160-3-source-into-unstable/

Bug#1009643: [Pkg-puppet-devel] Bug#1009643: Puppet: Fails to work with Ruby 3.0

[Antoine Beaupré]

On 2022-10-03 18:21:46, Michael Prokop wrote:
> AFAICT (thanks to our daily Grml ISO builds) this RC bug caused
> puppet to get removed from Debian/testing, so unless this gets fixed
> we won't have puppet in bookworm? Is anyone taking care of this?

Puppet 5 has been EOL for years. It's a good thing it's gone from
bookworm, and a deliberate act on part of the Puppet package
maintainers.

We've packaged puppet-agent 7 and uploaded to unstable, it should
trickle down in bookworm in a day or two if all goes well.

We're working on packaging puppetserver 7. You can follow that work and
more here:

https://wiki.debian.org/Teams/Puppet/Work

A.

-- 
Imagine a world in which every single person on the planet is given
free access to the sum of all human knowledge.
 - Jimmy Wales, co-founder of Wikipedia

Bug#1009643: [Pkg-puppet-devel] Bug#1009643: Puppet: Fails to work with Ruby 3.0

[Michael Prokop]

Hi!

* Antoine Beaupré [Tue Aug 30, 2022 at 05:15:58PM -0400]:
> On 2022-08-25 14:19:42, Antoine Beaupré wrote:
> 
> > For what it's worth, I have tested lavamind's Puppet 7 package from
> > experimental, on bookworm, and it works fine:
> >
> > https://tracker.debian.org/pkg/puppet-agent
> >
> > ... I am not sure how to express this in the BTS here, because it's a
> > different source package, so I can't mark it as fixed there without
> > first marking it as affecting that other package, but it never affected
> > it.
> 
> The correct way seems to be to move this bug report back to src:puppet
> where it belongs, which this message should do.

AFAICT (thanks to our daily Grml ISO builds) this RC bug caused
puppet to get removed from Debian/testing, so unless this gets fixed
we won't have puppet in bookworm? Is anyone taking care of this?

regards
-mika-


signature.asc
Description: PGP signature

Bug#1018232: closed by Debian FTP Masters (reply to Jörg Frings-Fürst ) (Bug#1018232: fixed in libunistring 1.0-2)

[Samuel Thibault]

Hello,

Thanks for uploading a fixed version. However,

Debian Bug Tracking System, le lun. 03 oct. 2022 09:24:06 +, a ecrit:
>* debian/libunistring2.symbols.hurd-i386:
>  - Refresh symbols (Closes: #1018232).

I don't understand why keeping such a file? The 

(arch=hurd-any)

qualifier allows to keep just one file that covers both cases.

Having two files only means that the updating problem will come up over
and over and over and over with each new libunistring release that
introduces a new function, while having one file means that the problem
will come up only when divergence appears, which is *way* more seldom.

The libunistring2.symbols file is already using an arch= qualifier, why
not using it with hurd-any?

Samuel

Bug#1021200: wrong build-dependency libservlet-api-ava

[tony mancill]

On Mon, Oct 03, 2022 at 05:36:17PM +0200, Pierre Gruet wrote:
> Package: groovy
> Version: 2.4.21-3
> Severity: important
> 
> Hello,
> 
> The version 2.4.21-3 of groovy that was uploaded yesterday wrongly includes
> libservlet-api-ava
> as a build-dependency. This mispelled package name has been introduced in an
> attempt to solve Bug #1020429.
> 
> Build dependencies of groovy and of its rdeps cannot be satisfied.

:facepalm: !   Thank you Pierre.

I am uploading a new source package now.  It may require some manual
help given that the package won't build against unstable.


signature.asc
Description: PGP signature

Bug#1021201: vulkan-loader: new upstream stable point release 1.3.224.1

[Simon McVittie]

Source: vulkan-loader
Version: 1.3.224.0-1
Severity: wishlist

vulkan-loader is currently at upstream version 1.3.224.0, but upstream's
sdk-1.3.224 stable branch now has a 1.3.224.1 point release with these
release notes:

> Enable layer interception of unknown functions
>
> Re-add previously reverted behavior that allows layers to setup
> dispatch chains for unknown physical device and device functions during
> vkCreateInstance. Previously, functions not known to the loader could
> not be queried by a layer during vkCreateInstance (when dispatch tables
> should be setup). The change adds support for unknown functions in the
> trampolines of vkGetInstanceProcAddr and vkGetPhysicalDeviceProcAddr.

If I'm reading correctly, this is a backport of part of
https://github.com/KhronosGroup/Vulkan-Loader/pull/999,
which seems to be a fix for bugs seen with the RenderDoc and
GFXReconstruct development tools.

smcv

Bug#1021200: wrong build-dependency libservlet-api-ava

[Pierre Gruet]

Package: groovy
Version: 2.4.21-3
Severity: important

Hello,

The version 2.4.21-3 of groovy that was uploaded yesterday wrongly includes
libservlet-api-ava
as a build-dependency. This mispelled package name has been introduced in an
attempt to solve Bug #1020429.

Build dependencies of groovy and of its rdeps cannot be satisfied.

Cheers,

-- 
Pierre

Bug#976052: ITP: zola -- static site generator

[Mohd Bilal]

Hello,

On Mon, 02 May 2022 23:04:58 +0200 Jonas Smedegaard  wrote:
0.15.3 draft 2, needs embedding 107 crates (60 missing, 5 broken, 20 
outdated, 22 ahead); builds in ~25 minutes; runs except subcommand serve 
which needs web assets separately packaged.


Thanks for working on packaging zola. This is something that I use and 
would love to see in Debian. I would like to offer my help for making 
this happen (like packaging missing deps? ). I've had some experience 
packaging ruby gems.


Let me know if I can be of any help to you. I'm ready to learn some rust 
packaging if required.


Thanks
--
Mohammed Bilal
2D65 BC1E B966 5A6E 97F9 730A B3F5 9452 8521 9E1F


OpenPGP_0xB3F5945285219E1F.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#944785: pufferfish wants to link with twopaco and ntcard

[Andreas Tille]

Hi Andrius,

Am Mon, Oct 03, 2022 at 10:19:41AM +0300 schrieb Andrius Merkys:
> twopaco has entered testing (yay!), thus I gave its reverse dependency,
> pufferfish (ITP bug #944785), a look. pufferfish carries embedded copies
> of twopaco and ntcard with a modified build system to create static (or
> is it shared?) libraries for these two and then links pufferfish with
> them. For Debian twopaco and ntcard have been un-embedded from
> pufferfish and packaged as separate binary packages instead. However,
> they do not build neither shared nor static libraries, just executables.
> 
> I think we can get around by patching twopaco and ntcard builds to
> include static libraries in their binary packages. Does this sound right?

My main motivation to start ntcard and twopaco packages was to avoid
code duplication in pufferfish.  I admit it seems I faild in doing this
sensibly to forget creating a library package.  Simply do whatever
brings you forward with pufferfish and fix what I failed to do.

Kind regards

  Andreas.

-- 
http://fam-tille.de

Bug#1010957: status update? Re: Bug#1010957: man-db: unreproducible index.db: contents depend on directory read order

[Holger Levsen]

On Sun, Oct 02, 2022 at 04:00:58PM +0100, Colin Watson wrote:
> Control: tag -1 fixed-upstream
> Success!
>   https://gitlab.com/cjwatson/man-db/-/compare/5d2594d0a0...866c3571d3

awesome!

On Sun, Oct 02, 2022 at 05:56:19PM +0100, Colin Watson wrote:
> I thought I'd set SOURCE_DATE_EPOCH, but I'd failed to pass it through
> sudo.  After fixing that, I indeed get cmp-identical tarballs.

very nice! much cheers!


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

Plastic bottles: made to last forever, designed to throw away.


signature.asc
Description: PGP signature

Bug#1021180: usrmerge may break user-mode-linux rootfs

[Marco d'Itri]

On Oct 03, Ritesh Raj Sarraf  wrote:

> There was nothing mounted onto /usr/lib/modules before. Instead, all
Sure, I meant /lib/modules/ .
Do you have another UML system where you can repeat this test?

> this time it was mounted on /lib/modules/ just like on the host. I
> think it failed because usrmerge script was invoking mv command while
> /lib/modules was independently mounted 'read-only'
It failed because it tried to move a mount point, which mv cannot do.

> After facing this error, I switched the fstab to /usr/lib/modules and
> rebooted. I first rebooted because unmounting /lib/modules was not
> possible as it was held by the linux process.
> 
> After the reboot, re-running the usrmerge script worked proper. 
This is a good solution as well.

> > What is the canonical way to detect UML?
> systemd does it nicely with:
I cannot have usrmerge depend on systemd.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#1021199: ITP: rust-lru -- A LRU cache implementation

[Timo Aaltonen]

Package: wnpp
Severity: wishlist
Owner: Timo Aaltonen 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: rust-lru
  Version : 0.7.8
  Upstream Author : Jerome Froelich
* URL : https://github.com/jeromefroe/lru-rs.git
* License : MIT
  Programming Lang: Rust
  Description : A LRU cache implementation


Required by rust-concread.

Bug#1021096: ITP: spaghetti -- Analysis of Network-constrained Spatial Data

[Bastian Germann]

On Sat, 01 Oct 2022 23:18:20 -0300 Josenilson Ferreira da Silva 
 wrote:
 Note: 
 Module needed for packaging: https://github.com/pysal/spot


You probably mean https://github.com/pysal/spopt.

When you are packaging dependencies for non-existing packages it is good 
practise to file a RFP/ITP
for those packages as well and let them be blocked by the dependency.

Bug#1009799: puppet: reproducible builds: domain name embedded in puppet.conf.5 man page

[Chris Lamb]

Vagrant Cascadian wrote:

> This patch appears to apply to puppet from experimental too, although I
> was unable to get that to build to confirm the fix.

See also bug #1021198, which is a parallel bug in the "puppet-agent"
source package.


Regards,

-- 
  o
⬋   ⬊  Chris Lamb
   o o reproducible-builds.org 
⬊   ⬋
  o

Bug#1021198: puppet-agent: please make the build reproducible

[Chris Lamb]

Source: puppet-agent
Version: 7.16.0-3
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: environment
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

Whilst working on the Reproducible Builds effort [0] we noticed that
puppet-agent could not be built reproducibly.

This is because the domain name of the system is embedded in the
manual page.

A patch is attached, which is based on the parallel (if not identical)
patch attached to bug #1009799 in the "puppet" source package that was
authored by Vagrant Cascadian.

 [0] https://reproducible-builds.org/


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
--- a/lib/puppet/defaults.rb2022-10-03 07:24:21.733301222 -0700
--- b/lib/puppet/defaults.rb2022-10-03 07:35:15.654024548 -0700
@@ -1613,7 +1613,7 @@
   :desc   => "Whether the server will search for SRV records in DNS 
for the current domain.",
 },
 :srv_domain => {
-  :default=> lambda { Puppet::Settings.domain_fact },
+  :default=> lambda { ENV.has_key?('SOURCE_DATE_EPOCH') ? '(node\'s 
fully qualified domain name)' : Puppet::Settings.domain_fact },
   :desc   => "The domain which will be queried to find the SRV records 
of servers to use.",
 },
 :http_extra_headers => {

Bug#1021197: fwupd: Blocked executable in the ESP, ensure grub and shim are up to date

[Alex Muntada]

Package: fwupd
Version: 1.5.7-4
Severity: normal
Tags: fixed-upstream

Dear Maintainer,
there's an issue in bullseye fwupd that seems to need an upgrade
or a backport from unstable for the following update to succeed
(see https://github.com/fwupd/fwupd/issues/5035 for details):

$ sudo fwupdmgr update
Devices with no available firmware updates:
 • ...
Upgrade available for UEFI dbx from 77 to 217
UEFI dbx and all connected devices may not be usable while updating. Continue 
with update? [Y|n]:
Downloading… [***]
Decompressing…   [***]
Authenticating…  [***]
Authenticating…  [***]
Updating UEFI dbx…   [***]
Verifying…   [***]
Blocked executable in the ESP, ensure grub and shim are up to date: 
/boot/efi/EFI/Boot/shimx64.efi Authenticode checksum 
[47b31a1c7867644b2ee8093b2d5fbe21e21f77c1617a2c08812f57ace0850e9f] is present 
in dbx



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

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

Versions of packages fwupd depends on:
ii  libc6  2.31-13+deb11u3
ii  libcurl3-gnutls7.74.0-1.3+deb11u2
ii  libefiboot137-6
ii  libelf10.183-1
ii  libflashrom1   1.2-5
ii  libfwupd2  1.5.7-4
ii  libfwupdplugin11.5.7-4
ii  libglib2.0-0   2.66.8-1
ii  libgnutls303.7.1-5+deb11u2
ii  libgudev-1.0-0 234-1
ii  libgusb2   0.3.5-1
ii  libjcat1   0.1.3-2
ii  libjson-glib-1.0-0 1.6.2-1
ii  libpolkit-gobject-1-0  0.105-31+deb11u1
ii  libsmbios-c2   2.4.3-1
ii  libsqlite3-0   3.34.1-3
ii  libsystemd0247.3-7
ii  libtss2-esys-3.0.2-0   3.0.3-2
ii  libxmlb1   0.1.15-2
ii  shared-mime-info   2.0-1

Versions of packages fwupd recommends:
ii  bolt   0.9.1-1
ii  dbus   1.12.20-2
ii  fwupd-amd64-signed [fwupd-signed]  1.5.7+4
ii  python33.9.2-3
pn  secureboot-db  
ii  udisks22.9.2-2+deb11u1

Versions of packages fwupd suggests:
pn  gir1.2-fwupd-2.0  

-- no debconf information

Cheers,
Alex

--
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁   Alex Muntada 
  ⢿⡄⠘⠷⠚⠋   Debian Developer  log.alexm.org
  ⠈⠳⣄



signature.asc
Description: PGP signature

Bug#1012196: buglist

[Bastian Germann]

Control: tags -1 moreinfo

On Sun,  2 Oct 2022 18:02:38 +  wrote:

Control: tags -1 -moreinfo

 > d/copyright
 > ===
 >
 > Some GPL-2+ licensed files have the following additional exception:
 > # The developers of the Exaile media player hereby grant permission
 > # for non-GPL compatible GStreamer and Exaile plugins to be used and
 > # distributed together with GStreamer and Exaile. This permission is
 > # above and beyond the permissions granted by the GPL license by which
 > # Exaile is covered. If you modify this code, you may extend this
 > # exception to your version of the code, but you are not obligated to
 > # do so. If you do not wish to do so, delete this exception statement
 > # from your version.

I reworked the copyright file based on 
https://sources.debian.org/src/exaile/3.4.0.2-1/debian/copyright/

Is the extension represented correct?


No. Please check the copyright format description for the "with" keyword.
Also, please try to present the copyright info in a more consice way. When two file groups have the same copyright 
holders please merge them (combining the years to a year enumeration or year range).


You can also use broader wildcards in Files: and override parts of the matches 
with a later Files: match.

I have already given you a hint that
"plugins/ipconsole/ipython_view.py by IBM Corporation is licensed under another 
variant of the BSD-3-Clause."
So, please do not use Michael Bostock's version for that file match but add a 
BSD-3-clause-IBM variant.
You should also remove his copyright line from the License: section because 
that is already in the Copyright: section.


 > d/rules
 > ===
 >
 > Please remove or explain the lines:
 >
 > dh_auto_clean
 > make manpage
 > make completion
 > ...
 > #override_dh_installdocs:
 > # dh_installdocs readme
 > override_dh_usrlocal:
 >
 > Please think of a different method instead of calling dh_auto_clean 
during install time to get rid of __pycache__ if
 > that is the reason for it. Maybe just copy the Makefile line '-find . 
-name "__pycache__" -exec rm -rf {} \;' ?


The point was to remove __pychache__.
Now I prevent dh_auto_build to do `make compile`



You have not explained "override_dh_usrlocal:".