Bug#1014041: yt-dlp: please make the build reproducible

[Chris Lamb]

Source: yt-dlp
Version: 2022.06.22.1-1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

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

This is because it does not iterate over a Python set() data structure
in a deterministic order.

Patch attached.

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


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
--- a/debian/patches/0005-Reproducible-build.patch  1970-01-01 
01:00:00.0 +0100
--- b/debian/patches/0005-Reproducible-build.patch  2022-06-29 
07:52:36.980838793 +0100
@@ -0,0 +1,15 @@
+Description: Make the build reproducible
+Author: Chris Lamb 
+Last-Update: 2022-06-29
+
+--- yt-dlp-2022.06.22.1.orig/devscripts/make_lazy_extractors.py
 yt-dlp-2022.06.22.1/devscripts/make_lazy_extractors.py
+@@ -91,7 +91,7 @@ def sort_ies(ies, ignored_bases):
+ for c in classes[:]:
+ bases = set(c.__bases__) - {object, *ignored_bases}
+ restart = False
+-for b in bases:
++for b in sorted(bases, key=lambda x: x.__name__):
+ if b not in classes and b not in returned_classes:
+ assert b.__name__ != 'GenericIE', 'Cannot inherit from 
GenericIE'
+ classes.insert(0, b)
--- a/debian/patches/series 2022-06-29 07:44:38.576411063 +0100
--- b/debian/patches/series 2022-06-29 07:51:47.433039603 +0100
@@ -2,3 +2,4 @@
 0002-Disable-upstream-s-autoupdate-mechanism.patch
 0003-Remove-use-of-git.patch
 0004-Makefile-Don-t-run-flake8-when-running-offlinetest.patch
+0005-Reproducible-build.patch

Bug#1013755: bullseye-pu: package ganeti/3.0.2-1~deb11u1

[Moritz Mühlenhoff]

Apollon wrote:
> I would like to update Ganeti to the current upstream bugfix version
> (3.0.2) - including all Debian packaging fixes currently in unstable - 
> and I seek your approval.
> 
> 3.0.2 was released a while back[1] as a bugfix-only release. Due to my 
> involvement upstream, I had full oversight of the release process and I 
> can confirm it solves important issues, the vast majority of which affect
> Bullseye, while it does not introduce any breaking changes in behavior.  

f0189ae15 is also relevant for buster->bullseye updates, since it
it leads to "gnt-cluster verify" alerting about a certificate mismatch
while actually everything is fine.

> I'm attaching a full source debdiff against 3.0.1-2. The following 
> information is for ease of review, please let me know if there is any 
> additional information I can provide.

JFTR, I've built 3.0.2-1~deb11u1 and deployed it to one of Wikimedia's
Ganeti clusters yesterday and everything is working fine.

Cheers,
Moritz

Bug#983405: concurrency

[Marc Haber]

On Tue, Jun 28, 2022 at 01:34:23PM -0400, Matt Barry wrote:
> Good call.  I've attached a minimal POC, which works in manual testing,
> but automated testing is tricky and there may be edge cases.  (This
> test is blocking; NB (erroring out) might be easier to test, but which
> is the better UX?)

A minimal test would be the test taking the lock, calling out to adduser
and seeing whether it fails. The other side (testing whether adduser
properly takes the lock) is probably harder.

Greetings
Marc

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421

Bug#752767: tracker-extract: Program tracker-extract eat more cpu on start kde session

[Manuel Bilderbeek]

Package: tracker-miner-fs
Followup-For: Bug #752767

Dear maintainer,

Yes, I'm also seeing that it uses a lot of CPU time on my (older) PC. It is
indeed a waste of CPU power and I'd like to let it stop, as locate is good
enough for me.

It constantly shows up at the top of top (but ideed, with a nice of 19):

top - 08:42:52 up 21 min,  1 user,  load average: 1,34, 1,68, 1,61
Tasks: 231 total,   1 running, 230 sleeping,   0 stopped,   0 zombie
%Cpu(s):  0,8 us,  2,2 sy, 23,8 ni, 70,7 id,  2,5 wa,  0,0 hi,  0,0 si,  0,0 st
KiB Mem :  8145424 total,  1486720 free,  2155596 used,  4503108 buff/cache
KiB Swap: 16772092 total, 16772092 free,0 used.  5676076 avail Mem 

PID USER  PR  NIVIRTRESSHR S  %CPU  %MEM TIME+ COMMAND  
 
   1538 manuel39  19 1217,6m 522,8m  19,8m S  76,4   6,6  16:41.76 
tracker-miner-f   
   1511 manuel39  19 1029,4m  75,5m  46,4m S  25,6   0,9   3:43.25 
tracker-extract   
   1687 manuel20   0 4030,6m 308,4m 112,8m S   1,7   3,9   0:18.50 
gnome-shell

But it would be great if it ca be disabled without installing the package (as
that would uninstall gnome).

Kind regards,
Manuel Bilderbeek

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

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

Versions of packages tracker-miner-fs depends on:
ii  init-system-helpers  1.63
ii  libc62.33-7
ii  libglib2.0-0 2.72.2-2
ii  libtracker-sparql-3.0-0  3.1.2-4+b1
ii  libupower-glib3  0.99.19-1
ii  procps   2:3.3.17-7+b1
ii  tracker  3.1.2-4+b1
ii  tracker-extract  3.1.3-4+b1

tracker-miner-fs recommends no packages.

tracker-miner-fs suggests no packages.

-- no debconf information

Bug#752767: tracker-miner-fs: It can be turned off...

[Manuel Bilderbeek]

Package: tracker-miner-fs
Followup-For: Bug #752767

Hi all,

As an addition to my previous e-mail, here are some hints on how to disable 
this service:
https://askubuntu.com/a/353450

(Thanks to dwfreed on IRC for pointing me to this.)

HTH...

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

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

Versions of packages tracker-miner-fs depends on:
ii  init-system-helpers  1.63
ii  libc62.33-7
ii  libglib2.0-0 2.72.2-2
ii  libtracker-sparql-3.0-0  3.1.2-4+b1
ii  libupower-glib3  0.99.19-1
ii  procps   2:3.3.17-7+b1
ii  tracker  3.1.2-4+b1
ii  tracker-extract  3.1.3-4+b1

tracker-miner-fs recommends no packages.

tracker-miner-fs suggests no packages.

-- no debconf information

Bug#1014041: yt-dlp: please make the build reproducible

[Chris Lamb]

forwarded 1014041 https://github.com/yt-dlp/yt-dlp/pull/4220
thanks

I've forwarded this upstream here:

  https://github.com/yt-dlp/yt-dlp/pull/4220


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-

Bug#1014042: gitg: Close button in info bar shows underscore instead having a shortcut key

[Roland Clobus]

Package: gitg
Version: 41-2
Severity: minor

Hello maintainers of gitg,

I noticed that the 'Close' button in the info bar has the text '_Close' (notice
the underscore) and does not have an active keyboard shortcut.

See https://sources.debian.org/src/gitg/41-2/gitg/resources/ui/gitg-
window.ui/?hl=229#L229

It is missing:
True

With kind regards,
Roland Clobus


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

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

Versions of packages gitg depends on:
ii  dbus-user-session [default-dbus-session-bus]  1.14.0-1
ii  dbus-x11 [dbus-session-bus]   1.14.0-1
ii  dconf-gsettings-backend [gsettings-backend]   0.40.0-3
ii  gir1.2-peas-1.0   1.32.0-1+b1
ii  git   1:2.35.1-1
ii  gsettings-desktop-schemas 42.0-1
ii  libc6 2.33-7
ii  libcairo2 1.16.0-5
ii  libdazzle-1.0-0   3.44.0-1
ii  libgdk-pixbuf-2.0-0   2.42.8+dfsg-1
ii  libgee-0.8-2  0.20.5-2
ii  libgirepository-1.0-1 1.72.0-1+b1
ii  libgit2-glib-1.0-01.0.0.1-2
ii  libglib2.0-0  2.72.2-2
ii  libgspell-1-2 1.11.1-1
ii  libgtk-3-03.24.34-1
ii  libgtksourceview-4-0  4.8.3-1
ii  libjson-glib-1.0-01.6.6-1
ii  libpango-1.0-01.50.7+ds-1
ii  libpeas-1.0-0 1.32.0-1+b1
ii  libsecret-1-0 0.20.5-2
ii  libxml2   2.9.14+dfsg-1

gitg recommends no packages.

gitg suggests no packages.

-- no debconf information

Bug#1014043: firefox: Emoji have small width

[Jonathan Rubenstein]

Package: firefox
Version: 101.0.1-1
Severity: normal
X-Debbugs-Cc: jrub...@gmail.com

Dear Maintainer,

Starting with Firefox 100, emoji characters get a tiny width and overlap 
the following characters.


I have attached a screenshot.


Best Regards,
Jonathan Rubenstein


-- Package-specific info:


-- Addons package information

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

Kernel: Linux 5.18.0-2-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8), 
LANGUAGE=fi:en_US:en_GB

Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages firefox depends on:
ii  debianutils  5.7-0.2
ii  fontconfig   2.13.1-4.4
ii  libasound2   1.2.6.1-2+b1
ii  libatk1.0-0  2.38.0-1
ii  libc62.33-7
ii  libcairo-gobject21.16.0-5
ii  libcairo21.16.0-5
ii  libdbus-1-3  1.14.0-1
ii  libdbus-glib-1-2 0.112-2
ii  libevent-2.1-7   2.1.12-stable-5+b1
ii  libffi8  3.4.2-4
ii  libfontconfig1   2.13.1-4.4
ii  libfreetype6 2.12.1+dfsg-3
ii  libgcc-s112.1.0-2
ii  libgdk-pixbuf-2.0-0  2.42.8+dfsg-1
ii  libglib2.0-0 2.72.2-2
ii  libgtk-3-0   3.24.34-1
ii  libnspr4 2:4.34-1
ii  libnss3  2:3.79-1
ii  libpango-1.0-0   1.50.7+ds-1
ii  libstdc++6   12.1.0-2
ii  libvpx7  1.11.0-2
ii  libx11-6 2:1.7.5-1
ii  libx11-xcb1  2:1.7.5-1
ii  libxcb-shm0  1.14-3
ii  libxcb1  1.14-3
ii  libxcomposite1   1:0.4.5-1
ii  libxdamage1  1:1.1.5-2
ii  libxext6 2:1.3.4-1
ii  libxfixes3   1:6.0.0-1
ii  libxrandr2   2:1.5.2-2+b1
ii  libxtst6 2:1.2.3-1.1
ii  procps   2:3.3.17-7+b1
ii  zlib1g   1:1.2.11.dfsg-4

Versions of packages firefox recommends:
ii  libavcodec58  7:4.4.2-1+b3
ii  libavcodec59  7:5.0.1-3

Versions of packages firefox suggests:
ii  fonts-lmodern  2.005-1
pn  fonts-stix | otf-stix  
ii  libcanberra0   0.30-10
ii  libgssapi-krb5-2   1.19.2-2+b2
pn  pulseaudio 

-- debconf-show failed

Bug#1011195: gtkpod: ftbfs on riscv64 arch

[肖盛文]

Source: gtkpod
Version: 2.1.5-9
Tags: patch
Followup-For: Bug #1011195
X-Debbugs-Cc: atzli...@sina.com, debian-ri...@lists.debian.org

Hi,

The attachment is a patch for fix this bug.
Please use this patch do a revision upload.

If you are busy, I would do NMU.

Thanks!

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

Kernel: Linux 5.16.0-5-riscv64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_UNSIGNED_MODULE
Locale: LANG=zh_CN.UTF-8, LC_CTYPE=zh_CN.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru gtkpod-2.1.5/debian/libatomicparsley0.symbols 
gtkpod-2.1.5/debian/libatomicparsley0.symbols
--- gtkpod-2.1.5/debian/libatomicparsley0.symbols   2016-04-28 
03:03:41.0 +0800
+++ gtkpod-2.1.5/debian/libatomicparsley0.symbols   2022-06-29 
15:56:43.0 +0800
@@ -33,8 +33,8 @@
  _Z13UTF8ToUTF16LEPhiPKhi@Base 0.0.1
  _Z13UTF8Toisolat1PhiPKhi@Base 0.0.1
  _Z13char4TOuint32jPc@Base 0.0.1
- (arch=alpha amd64 arm64 ia64 kfreebsd-amd64 mips64 mips64el ppc64 ppc64el 
s390x sparc64)_Z13char8TOuint64mPc@Base 0.0.1
- (arch=!alpha !amd64 !arm64 !ia64 !kfreebsd-amd64 !mips64 !mips64el !ppc64 
!ppc64el !s390x !sparc64)_Z13char8TOuint64yPc@Base 0.0.1
+ (arch=alpha amd64 arm64 ia64 kfreebsd-amd64 mips64 mips64el ppc64 ppc64el 
riscv64 s390x sparc64)_Z13char8TOuint64mPc@Base 0.0.1
+ (arch=!alpha !amd64 !arm64 !ia64 !kfreebsd-amd64 !mips64 !mips64el !ppc64 
!ppc64el !riscv64 !s390x !sparc64)_Z13char8TOuint64yPc@Base 0.0.1
  _Z13isolat1ToUTF8PhiPKhi@Base 0.0.1
  _Z13sha1_init_ctxP8sha1_ctx@Base 0.0.1
  _Z13sha1_read_ctxPK8sha1_ctxPv@Base 0.0.1
@@ -82,8 +82,8 @@
  _Z19UInt16FromBigEndianPKc@Base 0.0.1
  _Z19UInt32FromBigEndianPKc@Base 0.0.1
  _Z19UInt64FromBigEndianPKc@Base 0.0.1
- (arch=alpha amd64 arm64 ia64 kfreebsd-amd64 mips64 mips64el ppc64 ppc64el 
s390x sparc64)_Z20APar_AtomizeFileInfojjmPchhhjtP11uuid_vitals@Base 0.0.1
- (arch=!alpha !amd64 !arm64 !ia64 !kfreebsd-amd64 !mips64 !mips64el !ppc64 
!ppc64el !s390x !sparc64)_Z20APar_AtomizeFileInfojjyPchhhjtP11uuid_vitals@Base 
0.0.1
+ (arch=alpha amd64 arm64 ia64 kfreebsd-amd64 mips64 mips64el ppc64 ppc64el 
riscv64 s390x sparc64)_Z20APar_AtomizeFileInfojjmPchhhjtP11uuid_vitals@Base 
0.0.1
+ (arch=!alpha !amd64 !arm64 !ia64 !kfreebsd-amd64 !mips64 !mips64el !ppc64 
!ppc64el !riscv64 !s390x 
!sparc64)_Z20APar_AtomizeFileInfojjyPchhhjtP11uuid_vitals@Base 0.0.1
  _Z20APar_ExtractDataAtomi@Base 0.0.1
  _Z20APar_ExtractPicPrefsPc@Base 0.0.1
  _Z20APar_FindValueInAtomPcP8_IO_FILEsjj@Base 0.0.1

Bug#1014044: dcmtk: Multiple CVEs reported

[Mathieu Malaterre]

Package: dcmtk
Version: 3.6.5-1
Severity: important

Dear Maintainer,

Multiples CVEs have been reported against DCMTK:

- CVE-2022-2119
- CVE-2022-2120
- CVE-2022-2121

Should we track them ? Should it be handled by debian-security team ?

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

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

Versions of packages dcmtk depends on:
ii  adduser 3.118
ii  libc6   2.31-13+deb11u3
ii  libdcmtk17  3.6.7-5
ii  libgcc-s1   10.2.1-6
ii  libstdc++6  10.2.1-6
ii  libxml2 2.9.10+dfsg-6.7+deb11u2
ii  zlib1g  1:1.2.11.dfsg-2+deb11u1

dcmtk recommends no packages.

dcmtk suggests no packages.

-- no debconf information

Bug#1012627: Patch for 5.18 Issue

[Philipp Kolmann]

Hi,

I have faced the same issue and was also only on 5.18 anymore.

I used the Suse Patch Henrik provided in his mail, stripped it from the 
VBoxNetFlt-linux.c chunck, since this has already been added to the 
debian package in the 020-linux518.patch file.


I have now used the attached patch file and virtual box is now running 
with these changes on 2 AMD64 machines without issues again.


Hope that this patch can be included until 6.1.35 will be released into sid.

thanks
PhilippDescription: 
 TODO: Put a short summary on the line above and replace this paragraph
 with a longer explanation of this change. Complete the meta-information
 with other relevant fields (see below for details). To make it easier, the
 information below has been extracted from the changelog. Adjust it or drop
 it.
 .
 virtualbox (6.1.34-dfsg-3) unstable; urgency=medium
 .
   * Add patch from archlinux to fix a build failure with kernel 5.18
 (Closes: #1012122)
Author: Gianfranco Costamagna 
Bug-Debian: https://bugs.debian.org/1012122

---
The information above should follow the Patch Tagging Guidelines, please
checkout http://dep.debian.net/deps/dep3/ to learn about the format. Here
are templates for supplementary fields that you might want to add:

Origin: , 
Bug: 
Bug-Debian: https://bugs.debian.org/
Bug-Ubuntu: https://launchpad.net/bugs/
Forwarded: 
Reviewed-By: 
Last-Update: 2022-06-28

--- virtualbox-6.1.34-dfsg.orig/include/VBox/sup.h
+++ virtualbox-6.1.34-dfsg/include/VBox/sup.h
@@ -2142,7 +2142,25 @@ RT_IPRT_FORMAT_ATTR(1, 2) SUPR0Printf(co
  */
 SUPR0DECL(uint32_t) SUPR0GetKernelFeatures(void);
 
-/** @copydoc RTLogGetDefaultInstanceEx
+/**
+ * Notification from R0 VMM prior to loading the guest-FPU register state.
+ *
+ * @returns Whether the host-FPU register state has been saved by the host 
kernel.
+ * @param   fCtxHookWhether thread-context hooks are enabled.
+ *
+ * @remarks Called with preemption disabled.
+ */
+SUPR0DECL(bool) SUPR0FpuBegin(bool fCtxHook);
+
+/**
+ * Notification from R0 VMM prior to saving the guest-FPU register state (and
+ * potentially restoring the host-FPU register state) in ring-0.
+ *
+ * @param   fCtxHookWhether thread-context hooks are enabled.
+ *
+ * @remarks Called with preemption disabled.
+ */
+SUPR0DECL(void) SUPR0FpuEnd(bool fCtxHook); /** @copydoc 
RTLogGetDefaultInstanceEx
  * @remarks To allow overriding RTLogGetDefaultInstanceEx locally. */
 SUPR0DECL(struct RTLOGGER *) SUPR0GetDefaultLogInstanceEx(uint32_t 
fFlagsAndGroup);
 /** @copydoc RTLogRelGetDefaultInstanceEx
--- virtualbox-6.1.34-dfsg.orig/src/VBox/Additions/linux/sharedfolders/regops.c
+++ virtualbox-6.1.34-dfsg/src/VBox/Additions/linux/sharedfolders/regops.c
@@ -3823,7 +3823,9 @@ struct address_space_operations vbsf_reg
 .readpage   = vbsf_readpage,
 .writepage  = vbsf_writepage,
 /** @todo Need .writepages if we want msync performance...  */
-#if RTLNX_VER_MIN(2,5,12)
+#if RTLNX_VER_MIN(5,18,0)
+.dirty_folio= block_dirty_folio,
+#elif RTLNX_VER_MIN(2,5,12)
 .set_page_dirty = __set_page_dirty_buffers,
 #endif
 #if RTLNX_VER_MIN(5,14,0)
--- virtualbox-6.1.34-dfsg.orig/src/VBox/HostDrivers/Support/SUPDrv.cpp
+++ virtualbox-6.1.34-dfsg/src/VBox/HostDrivers/Support/SUPDrv.cpp
@@ -98,7 +98,18 @@
 # endif
 #endif
 
-
+#if defined(RT_OS_LINUX) && !defined(__NO_FORTIFY) && defined(__OPTIMIZE__) && 
defined(CONFIG_FORTIFY_SOURCE)
+/* In Linux 5.18-rc1, memcpy became a wrapper which does fortify checks
+ * before triggering __underlying_memcpy() call. We do not pass these checks 
here,
+ * so bypass them for now.  */
+# if RTLNX_VER_MIN(5,18,0)
+#  define SUPDRV_MEMCPY __underlying_memcpy
+# else
+# define SUPDRV_MEMCPY  memcpy
+# endif
+#else
+# define SUPDRV_MEMCPY  memcpy
+#endif
 /*
  * Logging assignments:
  *  Log - useful stuff, like failures.
@@ -267,6 +278,8 @@ static SUPFUNC g_aFunctions[] =
 SUPEXP_STK_BACK(2,  SUPR0ChangeCR4),
 SUPEXP_STK_BACK(1,  SUPR0EnableVTx),
 SUPEXP_STK_BACK(0,  SUPR0SuspendVTxOnCpu),
+SUPEXP_STK_OKAY(1,  SUPR0FpuBegin),
+SUPEXP_STK_OKAY(1,  SUPR0FpuEnd),
 SUPEXP_STK_BACK(1,  SUPR0ResumeVTxOnCpu),
 SUPEXP_STK_OKAY(1,  SUPR0GetCurrentGdtRw),
 SUPEXP_STK_OKAY(0,  SUPR0GetKernelFeatures),
@@ -1742,7 +1755,7 @@ static int supdrvIOCtlInnerUnrestricted(
 
 /* execute */
 pReq->u.Out.cFunctions = RT_ELEMENTS(g_aFunctions);
-memcpy(>u.Out.aFunctions[0], g_aFunctions, 
sizeof(g_aFunctions));
+   SUPDRV_MEMCPY(>u.Out.aFunctions[0], g_aFunctions, 
sizeof(g_aFunctions));
 pReq->Hdr.rc = VINF_SUCCESS;
 return 0;
 }
--- virtualbox-6.1.34-dfsg.orig/src/VBox/HostDrivers/Support/SUPLib.cpp
+++ virtualbox-6.1.34-dfsg/src/VBox/HostDrivers/Support/SUPLib.cpp
@@ -505,7 +505,7 @@ static int supInitFake(PSUPDRVSESSION *p
 if (g_pSupFunctions)
 {
 g_pSupFunctions->u.Out.cFunctions = 

Bug#1013324: Upgrade package to latest upstream version

[gregor herrmann]

On Tue, 28 Jun 2022 22:47:42 -0700, tony mancill wrote:

> Second, the build of 1.8.0 results in a lintian warning that I'm trying
> to understand, because when I run ldd against the library, it definitely
> appears to be linked against libc (and against the same libraries that
> the liblz4-java.so file in the 1.5.1 packaging is, yet that package
> doesn't trigger the lintian error).
> 
> E: liblz4-jni: library-not-linked-against-libc 
> [usr/lib/x86_64-linux-gnu/jni/liblz4-java.so]

That's probably a lintian false positive, we are also seeing this in
perl (arch:any) packages.
I forgot the details but looking at lintian bugs,
https://bugs.debian.org/896012
came up.


Cheers,
gregor

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

Bug#1000985: Mailman web interface shows Fedora icon on login page, which errors when clicked on

[Olivier Berger]

Hi.

Le Thu, Dec 02, 2021 at 08:34:03AM +0100, Alain Knaff a écrit :
> Hi,
> 
> Mailman3-web ships with a
> /usr/share/mailman3-web/settings_local.py.sample file that has
> django_mailman3.lib.auth.fedora included in INSTALLED_APPS
> 
> This causes appearance of a fedora logo on the mailing lists' login
> page. However, clicking on that logo results in an error message mailed
> to admin (see attach)
> 
> Removing django_mailman3.lib.auth.fedora from
> /etc/mailman3/mailman-web.py locally fixes the issue, but obviously
> packages should not ship with defaults that cause errors.
> 
> Thanks,
> 
> Alain

For what it's worth, some related discussion about this parameter's docs, in 
https://gitlab.com/mailman/mailman-suite-doc/-/issues/28

Hth,

-- 
Olivier BERGER
https://www-public.imtbs-tsp.eu/~berger_o/ - OpenPGP 2048R/0xF9EAE3A65819D7E8
Ingenieur Recherche - Dept INF
Institut Mines-Telecom, Telecom SudParis, Evry (France)

Bug#1013488: horizon: FTBFS: ImportError: cannot import name 'force_text' from 'django.utils.encoding' (/usr/lib/python3/dist-packages/django/utils/encoding.py)

[Thomas Goirand]

On 6/24/22 09:14, Lucas Nussbaum wrote:

Source: horizon
Version: 3:22.1.0-1
Severity: serious
Justification: FTBFS
Tags: bookworm sid ftbfs
User: lu...@debian.org
Usertags: ftbfs-20220624 ftbfs-bookworm

Hi,

During a rebuild of all packages in sid, your package failed to build
on amd64.


FYI, 51 out of 52 of the unit test failures were due to the lack of 
Django 4.x support in python3-django-compressor, which I fixed by 
uploading the latest django-compressor version.


Now trying to fix the remaining...

Cheers,

Thomas Goirand (zigo)

Bug#1014029: invisible malicious unicode in source code - detection and prevention

[Stephan Verbücheln]

Your text is quite chaotic, it is hard to distinguish the quotes from
your ideas what to do in Debian.

I think the main problem here are the programs which are presenting
source code to humans (text editors, terminals, HTML pages in Gitlab
etc.).
Quotes should always terminate everything. A control character within a
string literal should not have any effect outside of the quotes. The
rules should be similar as we know them from syntax highlighting. All
directional instructions should be terminated by the closing quote.

However, since it is not realistic to free all relevant tools from all
related bugs soon, compiler warnings make sense.
There I think it does not make sense to ban all Unicode. Unicode
clearly distinguishes printable and non-printable characters and so on.
So all characters that print something clearly visible can be
whitelisted.

Regards

Bug#1014040: Please package updated yt-dlp 2022.06.29

[shirish शिरीष]

Package: yt-dlp
Version: 2022.06.22.1-1
Severity: normal

Dear Maintainer,
Please package yt-dlp 2022.06.29 if possible -

https://github.com/yt-dlp/yt-dlp/releases/tag/2022.06.29

The latest release fixes quite a few issues including -

* [extractor/youtube] Mark videos as fully watched by
[Brett824](https://github.com/Brett824)

The above is from
https://github.com/yt-dlp/yt-dlp/commit/9d339c41e25b1a77495cebe3fbdc95e2cb837776

Looking forward to the new release and thank you for your maintainance
as well as speed in handling requests :)

-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (900, 'testing'), (500, 'testing-debug'), (100,
'unstable-debug'), (100, 'experimental'), (100, 'unstable'), (50,
'experimental-debug')
Architecture: amd64 (x86_64)

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

Versions of packages yt-dlp depends on:
ii  python33.10.4-1+b1
ii  python3-brotli 1.0.9-2+b3
ii  python3-certifi2020.6.20-1
ii  python3-mutagen1.45.1-3
ii  python3-pkg-resources  59.6.0-1.2
ii  python3-pycryptodome   3.11.0+dfsg1-3
ii  python3-websockets 10.2-1

Versions of packages yt-dlp recommends:
ii  ca-certificates  20211016
ii  curl 7.83.1-2
ii  ffmpeg   7:4.4.2-1+b3
ii  python3-xattr [python3-pyxattr]  0.9.9-1
ii  rtmpdump 2.4+20151223.gitfa8646d.1-2+b2
ii  wget 1.21.3-1+b2

Versions of packages yt-dlp suggests:
ii  bidiv  1.5-6
ii  mpv0.34.1-1+b2
ii  phantomjs  2.1.1+dfsg-2+b2

-- no debconf information

-- 
  Regards,
  Shirish Agarwal  शिरीष अग्रवाल
  My quotes in this email licensed under CC 3.0
https://creativecommons.org/licenses/by-nc/3.0/
https://flossexperiences.wordpress.com

E493 D466 6D67 59F5 1FD0 930F 870E 9A5B 5869 609C

Bug#983405: concurrency

[Matt Barry]

On Wed, 2022-06-29 at 11:13 +0200, Marc Haber wrote:
> On Tue, Jun 28, 2022 at 01:34:23PM -0400, Matt Barry wrote:
> > Good call.  I've attached a minimal POC, which works in manual
> > testing,
> > but automated testing is tricky and there may be edge cases.  (This
> > test is blocking; NB (erroring out) might be easier to test, but
> > which
> > is the better UX?)
> 
> A minimal test would be the test taking the lock, calling out to
> adduser
> and seeing whether it fails. The other side (testing whether adduser
> properly takes the lock) is probably harder.

I was thinking the same thing; this too is easier to test if adduser's
behavior is non-blocking (ie. fail instead of wait).  Is that the
desired response?

mb

Bug#996162: O: linux-ftpd -- File Transfer Protocol (FTP) server

[Bastian Germann]

X-Debbugs-Cc: a...@inittab.org

On Mon, 11 Oct 2021 18:03:43 +0200 Bastian Germann wrote:
ftpd is unmaintained/non-existing upstream and the package seems to be unmaintained as 
well (see related #986997). It should be removed in favour of another ftpd that is in the 
archive. None of them is fully command-line compatible. inetutils-ftpd seems to be the 
most compatible one with only a few options missing.


If no one wants to adopt the package, I am going to file a RM bug soon. In that case, 
inetutils-ftpd should provide a transitional package with more information on how to 
switch to inetutils-ftpd.


Whoever wants to use the linux-ftpd source can still install ftpd-ssl.


Hi Alberto,

Do you want to adopt the package (move from Uploaders to Maintainer)?
I see you are still occasionally active.

Thanks,
Bastian

Bug#1014046: O: netkit-telnet-ssl -- BSD-derived netkit-telnet with SSL patches

[Bastian Germann]

Package: wnpp
X-Debbugs-Cc: a...@inittab.org

netkit-telnet-ssl is unmaintained/non-existing upstream and the package seems to be unmaintained as well (see related 
#986997). I orphan it. A good candidate for adoption is Alberto Gonzalez Iniesta who is listed as an uploader and copied.

Bug#1014047: O: linux-ftpd-ssl -- BSD-derived ftpd with SSL patches

[Bastian Germann]

Package: wnpp
X-Debbugs-Cc: a...@inittab.org

linux-ftpd-ssl is unmaintained/non-existing upstream and the package seems to be unmaintained as well (see related 
#986997). I orphan it. A good candidate for adoption is Alberto Gonzalez Iniesta who is listed as an uploader and copied.

Bug#1013299: linux-image-4.19.0-20-amd64: NULL pointer deref in qdisc_put() due to missing backport

[Ben Hutchings]

Control: tag -1 patch
Control: tag -1 - help

On Wed, 2022-06-22 at 11:47 +0200, Diederik de Haas wrote:
> On Tuesday, 21 June 2022 16:11:42 CEST Diederik de Haas wrote:
> > > So yes, this needs to also be fixed upstream (hence me including that tag
> > > when reporbugging), but perhaps Debian can quickfix.
> > 
> > What I have observed so far is that a commit needs to be accepted upstream
> > (but doesn't have to have gone through the whole 'chain of command') before
> > a temporary patch is accepted to quickly fix it in Debian.
> 
> I made an initial attempt at a patch, see attachment.
> https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html#s4.2.2
> describes a way to test whether this patch fixes the issue.
> (Just in case. I'm reasonably sure you already know this)

Looks good to me.  Can you send it on to sta...@vger.kernel.org? 
You'll need to add your Signed-off-by.

Ben.

-- 
Ben Hutchings
Reality is just a crutch for people who can't handle science fiction.


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

Bug#1013324: Upgrade package to latest upstream version

[Jérôme Charaoui]

Le 2022-06-29 à 01 h 47, tony mancill a écrit :

On Thu, Jun 23, 2022 at 08:52:53PM -0700, tony mancill wrote:

On Tue, Jun 21, 2022 at 01:59:00PM -0400, Jérôme Charaoui wrote:

Package: lz4-java
Version: 1.5.1-3
Severity: wishlist

Dear maintainer,

Please upgrade lz4-java to the latest version, 1.8.0.

It includes several API and performance improvements, and a package I would
like to upload to Debian, nippy-clojure, depends on version 1.7.1 and above
of this package.


Hello Jerome,

Thank you for the bug report.  I am working on this now.  I have updated
the patches and am working through an issue with the mvel templating.  I
will update the bug if it looks like it's going to take much longer.


Hi Jérôme,

I have just uploaded to experimental because I have have a few open
questions about the update before uploading to unstable.

First, lz4-java now supports a "lz4-pure-java" build that results in
only a jar file with no need for the JNI package or the lz4 library.  It
is easy to build this, but I think we would want this in a separate
binary package that doesn't depend on the JNI binary package.  That
will necessitate the package going through NEW, so I am asking the team
first.  (IMO, a pure Java implementation is a nice improvement.)

Second, the build of 1.8.0 results in a lintian warning that I'm trying
to understand, because when I run ldd against the library, it definitely
appears to be linked against libc (and against the same libraries that
the liblz4-java.so file in the 1.5.1 packaging is, yet that package
doesn't trigger the lintian error).

E: liblz4-jni: library-not-linked-against-libc 
[usr/lib/x86_64-linux-gnu/jni/liblz4-java.so]

All of the r-deps that build against 1.5.1 are building against 1.8.0.
Please let me know if you have any issues with the new package.


Hi Tony, I've tested nippy-clojure with the latest lz4-java binaries and 
the testsuite is running fine.


Thanks for working on this!

-- Jérôme

Bug#1014045: source-is-missing doesn't seem to understand docbook

[Christoph Berg]

Package: lintian
Version: 2.115.1
Severity: normal

The latest lintian versions are throwing a lot of these errors on
postgresql-15:

E: postgresql-15 source: source-is-missing [doc/src/sgml/html/acronyms.html]
N:   The source of the following file is missing. Lintian checked a few 
possible paths to find the source, and did not find it.
E: postgresql-15 source: source-is-missing [doc/src/sgml/html/admin.html]
E: postgresql-15 source: source-is-missing [doc/src/sgml/html/adminpack.html]
E: postgresql-15 source: source-is-missing [doc/src/sgml/html/amcheck.html]
E: postgresql-15 source: source-is-missing 
[doc/src/sgml/html/app-clusterdb.html]
...

But the source is right there one level up:

$ ls -l doc/src/sgml/html/acronyms.html
-rw-r--r-- 1 cbe cbe 21242 27. Jun 22:15 doc/src/sgml/html/acronyms.html
$ ls -l doc/src/sgml/acronyms.sgml
-rw-r--r-- 1 cbe cbe 19714 27. Jun 22:11 doc/src/sgml/acronyms.sgml

Am I supposed to override these?

Christoph

Bug#1014049: ITP: rust-leptonica-sys -- FFI bindings for Leptonica

[Jonas Smedegaard]

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: rust-leptonica-sys
  Version : 0.4.1
  Upstream Author : Chris Couzens 
* URL : https://github.com/ccouzens/leptonica-sys
* License : Expat
  Programming Lang: Rust
  Description : FFI bindings for Leptonica

 leptonica-sys is Rust FFI bindings to Leptonica.
 .
 Leptonica is a pedagogically-oriented library
 broadly useful for image processing and image analysis applications.

This package will be maintained in the Debian section of Salsa, here:
.

 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmK8SsgACgkQLHwxRsGg
ASHeLg//Tcw5NN4RoskJnJ3PAXmEioqlpuebUqZV6325Ig2aUtihlSVOdwhyWw/K
bR+16K8GyVhF2h+ElKfIFr3ZocCJZ6+mDp+UkZ4CqnavP8uHrOdACmQg9sRyMwbe
AWawO0fMiWsi/CaSKiUUsan+6qpjxSpC/O0Cl0DCfPvjguExGvcu/YUJPe+a9rhK
z6FaN1vrhFv+MoDPHYKHstoII/+j32q7RVmQrH2t8eHJIMyv8UxUvABUZz+cjZLs
YdGcFmA0hF/jFa5/GFyVX01/41/tS4AyQCoicbz9kWTNLJj2jY78P4wjCIPn6RKw
lT76C52Xy9hUJJaqexSO81CnFi2Eyoy2lzIcx3zCwKO4YqgloHNwTW9fUcsovmFA
LOUggvDIRlOSUs3LyMZVZrZ1+Der4wPVFadBNnOP6wKJAQShkDvmjyq1qUL8mQTk
asNJj0ycltytlLIQnYBZueez6Ix1rNiVDpkyNu7RFokpYW0Gr034ScSjEw6ZYOuM
sqMYvNqkSbS5aKBB73jgsZQ90ZTVb26+dRN1aBBgAeMLGeQf1XrLsByOIpuKwwsv
AM4/CzGfB4QdBOD8+WUnfSAHNFGgnxjVHc8P+oZhgc6ANACCnvuXwa6hVJEp4pdf
bce18jvL4ulT3qjdTjzFcAZMr4qmGet6LIgiBmCYg68TK2ZZU3s=
=Klo4
-END PGP SIGNATURE-

Bug#1013132: ITP: BabaSSL -- BabaSSL is a base library for modern cryptography and communication security protocols.

[Andrey Rahmatullin]

On Wed, Jun 29, 2022 at 01:43:25PM +, Lance Lin wrote:
> Hello everyone,
> 
> Thank you for your input and guidance. I've only been in Debian for a year so 
> 
> I still have many things to learn. I assumed there would be issues with 
> library
> name conflicts and wanted to get the group's opinion.
> 
> >> Or if the goal is rather to experiment and expose BabaSSL to the many archs
> >> we have in Debian, then keep it in unstable only by filing a bug to block
> >> it from testing.
> 
> > Or better: experimental, to avoid packages starting to (build-)depend on it.
> 
> It sounds like it would be suitable for the community if I continue the 
> packaging 
> work but restrict the package to experimental? 
As a drop-in OpenSSL replacement or with different file names and SONAMEs?


-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#992409: Updated the upstream bug : not related to locale but to print formatting

[François Cerbelle]

/usr/share/prometheus-node-exporter-collectors/smartmon.sh line 20 is :
 20   printf "%s_raw_value{%s,smart_id=\"%s\"} %e\n", $2, labels, $1,
$10 the explicitly requested format is "%e" which is the scientific
notation and not the human float notation expected by prometheus. I
think that the right fix would be to print a "%f" format, which would
work in any locale. BTW, this formatting (%e) is also used in other
places in this script, but outside of my test hardware.

Bug#877914: eurephia -- flexible OpenVPN authentication module

[Bastian Germann]

Control: retitle -1 ITA: eurephia -- flexible OpenVPN authentication module
Control: owner -1 multipoc...@gmail.com

On Tue, 21 Jun 2022 15:14:33 +0500  wrote:

Hello! I would like to take a package, how to do it?


Please read https://mentors.debian.net/sponsors, package a new version which replaces the Maintainer field with your 
name, and hand it in as a request for sponsorship.

Bug#805266: RFA: libnss-gw-name -- nss module that names the current gateway’s IP address

[Bastian Germann]

Control: retitle -1 O: libnss-gw-name -- nss module that names the current 
gateway’s IP address

nomeata has moved to emeritus status and orphaned the package via upload on 
Sun, 03 Apr 2022.

Bug#985196: haveged: OpenRD "client" ( arch = armv5tel ) Upgraded from Buster to Bullseye and haveged stoped working

[Rick Thomas]

On Sun, 14 Mar 2021 00:39:40 -0800 Rick Thomas  wrote:
> Package: haveged
> Version: 1.9.14-1
> Severity: normal
> 
> Dear Maintainer,
> 
> I recently updated my OpenRD "client" ( arch = armv5tel ) from Buster to 
> Bullseye and now haveged crashes.
> 

I tried Dave Holland’s proposed workaround and it still doesn’t work — Any 
suggestions?

rbthomas@sheeva:~$ systemctl status haveged -n 100
* haveged.service - Entropy Daemon based on the HAVEGE algorithm
 Loaded: loaded (/lib/systemd/system/haveged.service; enabled; vendor 
preset: enabled)
 Active: failed (Result: signal) since Wed 2022-06-29 04:56:35 PDT; 2min 
13s ago
   Docs: man:haveged(8)
 http://www.issihosts.com/haveged/
Process: 14464 ExecStart=/usr/sbin/haveged --Foreground --verbose=1 
$DAEMON_ARGS (code=killed, signal=SYS)
   Main PID: 14464 (code=killed, signal=SYS)
CPU: 248ms

Jun 29 04:56:35 sheeva systemd[1]: haveged.service: Scheduled restart job, 
restart counter is at 5.
Jun 29 04:56:35 sheeva systemd[1]: Stopped Entropy Daemon based on the HAVEGE 
algorithm.
Jun 29 04:56:35 sheeva systemd[1]: haveged.service: Start request repeated too 
quickly.
Jun 29 04:56:35 sheeva systemd[1]: haveged.service: Failed with result 'signal'.
Jun 29 04:56:35 sheeva systemd[1]: Failed to start Entropy Daemon based on the 
HAVEGE algorithm.
rbthomas@sheeva:~$ 
rbthomas@sheeva:~$ cat /etc/systemd/system/haveged.service.d/override.conf
[Service]
SystemCallFilter=uname

rbthomas@sheeva:~$ ls -l /etc/systemd/system/haveged.service.d/override.conf
-rw-r--r-- 1 root root 34 Jun 29 04:56 
/etc/systemd/system/haveged.service.d/override.conf

rbthomas@sheeva:~$ uname -a
Linux sheeva 5.10.0-15-marvell #1 Debian 5.10.120-1 (2022-06-09) armv5tel 
GNU/Linux
rbthomas@sheeva:~$ arch
armv5tel

rbthomas@sheeva:~$ aptitude versions haveged
i   1.9.14-1   stable   500 

Thanks!
Rick

Bug#1014048: ITP: flocq -- Floating-point arithmetic for Coq

[Julien Puydt]

Package: wnpp
Severity: wishlist
Owner: Julien Puydt 
X-Debbugs-Cc: Debian OCaml Maintainers , 
jpu...@debian.org

* Package name: flocq
  Version : 4.1.0
  Upstream Author : Sylvie Boldo, Guillaume Melquiond
* URL : https://flocq.gitlabpages.inria.fr/
* License : LGPL-3
  Programming Lang: Coq
  Description : Floating-point arithmetic for Coq
 Flocq provides a formalization of floating-point arithmetic
 for Coq, in the form of a comprehensive library of
 theorems on a multi-radix multi-precision arithmetic,
 with efficient numerical computations.
 .
 Coq is a proof assistant for higher-order logic.


I plan to maintain it within the Debian OCaml Maintainers team, along with the
rest of the Coq-related packages.

Cheers,

J.Puydt

Bug#983405: concurrency

[Marc Haber]

On Wed, Jun 29, 2022 at 07:32:42AM -0400, Matt Barry wrote:
> On Wed, 2022-06-29 at 11:13 +0200, Marc Haber wrote:
> > On Tue, Jun 28, 2022 at 01:34:23PM -0400, Matt Barry wrote:
> > > Good call.  I've attached a minimal POC, which works in manual
> > > testing,
> > > but automated testing is tricky and there may be edge cases.  (This
> > > test is blocking; NB (erroring out) might be easier to test, but
> > > which
> > > is the better UX?)
> > 
> > A minimal test would be the test taking the lock, calling out to
> > adduser
> > and seeing whether it fails. The other side (testing whether adduser
> > properly takes the lock) is probably harder.
> 
> I was thinking the same thing; this too is easier to test if adduser's
> behavior is non-blocking (ie. fail instead of wait).  Is that the
> desired response?

You're of course right, if we want to wait for the lock to become free
(which probably is the sensible thing to do) the test is much harder.

The only method I think about is introducing an internal option --delay
which will sleep for a ten seconds or so after obtaining the lock,
sending an adduser --delay into the background and checking how much
wallclock time a foreground adduser will take while the background
adduser is still running. Or we would have a diagnostic output "waiting
for lock" and check for that.

Not nice at all, but we could for example steal code from a daemon
package such like openldap which does a lot of tests by invoking a
daemon in the background and hurling test requests at it. Disclaimer: I
don't know whether openldap's tests are written in perl.

Greetings
Marc

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421

Bug#1014053: sbd: manpage in bionic should replace /etc/sysconfig/sbd with /etc/default/sbd

[Michal Maloszewski]

Package: sbd
Severity: minor

Dear Maintainer,

The documentation for Ubuntu 18.04 says that the location of the sbd config 
file is in /etc/sysconfig/sbd
but it should be /etc/default/sbd. It may mislead users who are reading the 
documentation.

-- System Information:
Debian Release: bullseye/sid
  APT prefers focal-updates
  APT policy: (500, 'focal-updates'), (500, 'focal-security'), (500, 
'focal-proposed'), (500, 'focal'), (100, 'focal-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages sbd depends on:
ii  libaio1  0.3.112-5
ii  libc62.31-0ubuntu9.9
pn  libcib27 
pn  libcmap4 
pn  libcrmcluster29  
pn  libcrmcommon34   
ii  libglib2.0-0 2.64.6-1~ubuntu20.04.4
pn  libpe-status28   
pn  libqb0   
ii  libuuid1 2.34-0.1ubuntu9.3
pn  libvotequorum8   
ii  lsb-base 11.1.0ubuntu2

sbd recommends no packages.

sbd suggests no packages.

Bug#1014038: linux-image-5.10.0-15-amd64: write protected files deleted

[Diederik de Haas]

On Wednesday, 29 June 2022 03:38:47 CEST William Melgaard wrote:
>* What led up to the situation?
> Within Dolphin, a folder was highlighted. This folder was a development
> folder congaing read-only backup files. I clicked on a file that was
> obsolete, and instrcuted Dolphin to . I did not notice that
> clicking on the obsolete file did not un-highlight the development folder.
> 
>* What was the outcome of this action?
> Both the obsolete file and the development file were deleted entirely.

>* What outcome did you expect instead?
> A notice of failure because of attempt to delete a read-only file

https://lists.debian.org/debian-kde/2021/08/msg1.html is a discussion 
about being able to write a read-only file and that was resolved upstream here:
https://bugs.kde.org/show_bug.cgi?id=440986

While not exactly the same, it does seem similar.
And while its behavior seems *technically* correct, I can understand it is 
undesirable and unexpected.

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

Bug#1014050: ITP: rust-tesseract-sys -- Rust bindings for Tesseract OCR

[Jonas Smedegaard]

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: rust-tesseract-sys
  Version : 0.5.12
  Upstream Author : Chris Couzens 
* URL : https://github.com/ccouzens/tesseract-sys
* License : Expat
  Programming Lang: Rust
  Description : Rust bindings for Tesseract OCR

 tesseract-sys is Rust bindings for Tesseract.
 .
 Tesseract is an optical character recognition engine.

This package will be maintained in the Debian section of Salsa, here:
.

 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmK8S/cACgkQLHwxRsGg
ASFkLxAAjy44G7GumNtIz1mzZynIHqL+7zbbxKb0G+G6aolFjqNdgyB9te5ERVkz
KLvAcDGJntZP+bkWaWKBsRG5uU++JuG2YBv8HdfO2XSSbgRxmhLGqVyYrT6gywr4
NpoooUrYDm0bQZiW1119B/H71B+gpf51nY7niNNPYuRK5HOAGTTcUWf+fYnKsyMs
O9VpbqmXTr7BS8j4No1J+dZbtpzrAqNn/AMoXO1Mq0ZmECysaIygOEDeES8Sg7Ft
dvYu9v2Aw0qd9eeAcJZmH7TILLvywjLUTTsYHrwmB9WlazEhcfvUYiak4oK9swqF
iOTLzS8XVcxW3WnO1IIGbFAX6SLuWIyIfHZQvlP+GtfIw+Bziugeild57WWxMnon
fcwJX0mtl6NXaru+jMpaDeiKC6QsQUH2bqq+pemSBjbU9eBuSEckBiOvXSJUEEYx
eXthyiYnwx9DFm/1EKyVa27NZNo76FAPKN9gNO3GULVEX5nKopuWoDg722Jw3CdR
Wwsmno1M5dNPLgYNX9R8Vt76yDTCSNyTfVCvjkJlOPC+U23gjhu8IPve4gWhRsZP
ccist867iyvq3G73XZPzXVhENPQKC/Zc/oJPsEcTixhT1ewVqMtbnkrtA6ZYBpKi
f7YAme9mnYTE5lR1/BaweZ0BULwu0x1JuitCXW1r99HVycE74is=
=4Lur
-END PGP SIGNATURE-

Bug#1007002: Lintian breaks existing lintian-overrides due to added []

[Axel Beckert]

Hi Andreas,

Andreas Tille wrote:
> I realised that lintian (at least) starting with version 2.115.1 (may be
> earlier) wraps file names into [] which breaks existing
> lintian-overrides.

Correct, except that it happened for quite a while (7 months at least)
and was (and maybe still is — see below) a continuous transition. It
is present since at least 2.114.0 from November 2021. According to the
git history, the implementation started shortly before the 2.114.0
upload, but the bug report which requested this is actually from 2014:
https://bugs.debian.org/743226

And yes, 2.115.0 (but not 2.115.1 or 2.115.2 from today) had more such
changes as there were over 200 commits from Felix included which he
did after 2.114.0, but which weren't uploaded since then. Many of them
were (IMHO irresponsibly) marked "Gbp-Dch: Ignore" and hence didn't
show up in debian/changelog when I generated it with "gbp dch". (I
though ignored that in some cases and added them manually to the
debian/changelog entry, partially even retroactively.)

> I consider these [] not helpful […] no visible advantage.

The advantage is to clearly mark what is a file with potentially a
line number in the output of lintian so that further processors like
the lintian website can do deep links to the proper code position on
e.g. sources.debian.org or salsa.debian.org. Felix called it "pointed
hints".

From my point of view, that's quite an advantage.

See also https://bugs.debian.org/1007002 for the proper bug report
about the issue with invalidating overrides by this transition. I've
added it to the Cc of this thread and dropped lintian-ma...@debian.org
instead as mails to that bug report get forwarded to the Lintian Team
anyway.

> since it breaks lots of lintian-overrides

Felix decided that it's worth to implement this requested feature and
I at least partially agree as I do clearly see the advantage and also
like the possibilities which this now offers.

> Could this change in lintian please be reverted?

I clearly won't do that — for multiple reasons:

* Far too much work for the gain (IMHO)
* Losing a requested feature.
* Invalidating 7 months of already updated overrides.
* Better ways to invest your (and my) time. (See my proposition
  below.)

Background:

This seems not to have been one big commit but many small commits
whenever a tag was touched by Felix. Reverting it to the old format
would be a huge effort for which I don't have the time as there are
way more pressing issues in lintian. And I'm very sure it can't be
done by just doing a bunch of "git revert". So far I found 15 commits
by Felix mentioning  "pointed hint" reaching from November 2021 to
March 2022. With about 200 other, partially quite invasive commits
inbetween.

And in addition to that, it's IMHO _far_ too late, because many
maintainers already have updated their overrides in the past 7 months.

And I'm currently not sure if I would even accept a Merge Request
which tries to do that.

But I doubt that anyone would a) make that effort and b) make all
those maintainers angry who already updated their overrides in the
past 7 months or more.

Roberto C. Sánchez wrote:
> Or perhaps make the new format default

That was Felix' plan, yes. I just have currently no idea how many tags
have been and how many haven't been converted yet.

If there aren't too many tags left, I might finish this transition.

If there are many tags left, I'd only do that if we have a way to cope
with it with much less effort than it so far caused.

And from my point of view, the only way to get out of this mess
without causing too much work for anyone (maintainers of packages with
affected overrides as well as the current Lintian maintainers):

Someone should write a converter from the old to the new format. That
doesn't sound too difficult. Main work would be gathering for each tag
involved how it looked beforehand and how it looked now. This probably
can be gathered from changes in git to Lintian's test suite.

And maybe it should even try to output overrides which are compatible
with the old and new format, at least in cases where the order of
parameters didn't change. See lintian's own overrides for some examples:
https://salsa.debian.org/lintian/lintian/-/blob/master/debian/source/lintian-overrides
(Although this also accounts for a bug which only ever was present in
Lintian's git repository and never got uploaded, but still got an RC
bug report because people started using lintian off the git repo due
to it no having been maintained for months:
https://bugs.debian.org/1003353)

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


signature.asc
Description: PGP signature

Bug#575848: RM: dh-kpatches -- RoQA; unmaintained

[Bastian Germann]

Control: retitle -1 RM: dh-kpatches -- RoQA; unmaintained
Control: reassign -1 ftp.debian.org

dh-kpatches was not available in several releases and FTBFS.
I think we can get rid of it.

Bug#1014051: gtk+3.0: Unable to select items from a file dialog in a Wayland session

[Maurizio Avogadro]

Source: gtk+3.0
Version: 3.24.34-1
Severity: important

Dear Maintainer,

trying to select a file name by clicking an item from a file selection list or
even by typing the file name in the box results in this error (example from
pdfarranger file import dialog; the same happens on the file export dialog):

(pdfarranger:147955): Gdk-WARNING **: 13:40:24.960:
../../../../../gdk/wayland/gdkselection-wayland.c:280: error reading selection
buffer: Operation was cancelled

After such error there is no way to close the file selection dialog: even the
"cancel" button doesn't work anymore and the only way to quit the application
is by killing it.

This happens on this environment:
- Debian up-to-date testing
- KDE Plasma v5.24.5 (Wayland session)

Under a X11 session file selection works as expected.


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

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

Bug#1010073: Bug 1010073: kernel 4.19: nvme read overhead sometimes, system hangs

[Ben Hutchings]

On Thu, 9 Jun 2022 15:34:17 Андрій Василишин 
wrote:
> Because it is the latest kernel which supports aufs.
> Problem gone when I change to default  parameters NIC Mellanox Technologies
> MT28908 Family [ConnectX-6]
> ethtool -C enp161s0f0np0 rx-usecs 8 rx-frames 128 tx-usecs 8 tx-frames 128
[...]

So this seems to be a problem with the out-of-tree network driver you
are using.  You should ask Mellanox for support, as there's nothing we
can do about that.

Ben.

-- 
Ben Hutchings
Reality is just a crutch for people who can't handle science fiction.


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

Bug#1014052: ibus:After rebooted, I must do `ibus-daemon -rxd` change japanese to anthy with kanji key.

[Yukiharu YABUKI]

Package: ibus
Version: 1.5.26-4
Severity: normal
X-Debbugs-Cc: yyab...@debian.org

Dear Maintainer,

In unstable, after reboot, I hit kanji key, but ibus does not changed
japanse to anthy. Stable release version changed japanse to anthy.

So, I tried to fix. I do `ibus-daemon -xrd`. Then kanji key can
change japanse to anthy.

I set up same way between stable and unstable.


-- Package-specific info:
ibus is /usr/bin/ibus
ibus-setup is /usr/bin/ibus-setup
im-config -l =>  ibus xim
im-config -m => 'default' 'ibus' 'ibus' '' 'ibus'

XMODIFIERS=@im=ibus
GTK_IM_MODULE=ibus
QT_IM_MODULE=ibus
WAYLAND_DISPLAY=
XDG_CURRENT_DESKTOP=i3
XDG_MENU_PREFIX=
XDG_RUNTIME_DIR=/run/user/1000
XDG_SEAT=seat0
XDG_SESSION_CLASS=user
XDG_SESSION_DESKTOP=i3
XDG_SESSION_ID=2
XDG_SESSION_TYPE=x11

== ls -l /usr/lib/ibus/ibus-* /usr/libexec/ibus-* ==
/bin/ls: cannot access '/usr/lib/ibus/ibus-*': No such file or directory
-rwxr-xr-x 1 root root  22832 Apr 10 21:16 /usr/libexec/ibus-dconf
-rwxr-xr-x 1 root root   1119 Jan  2 05:25 /usr/libexec/ibus-engine-anthy
-rwxr-xr-x 1 root root  14640 Apr 10 21:16 /usr/libexec/ibus-engine-simple
-rwxr-xr-x 1 root root 166192 Apr 10 21:16 /usr/libexec/ibus-extension-gtk3
-rwxr-xr-x 1 root root  18736 Apr 10 21:16 /usr/libexec/ibus-memconf
-rwxr-xr-x 1 root root  92464 Apr 10 21:16 /usr/libexec/ibus-portal
-rwxr-xr-x 1 root root   1053 Jan  2 05:25 /usr/libexec/ibus-setup-anthy
-rwxr-xr-x 1 root root 121144 Apr 10 21:16 /usr/libexec/ibus-ui-emojier
-rwxr-xr-x 1 root root 321904 Apr 10 21:16 /usr/libexec/ibus-ui-gtk3
-rwxr-xr-x 1 root root 100280 Apr 10 21:16 /usr/libexec/ibus-x11

== dpkg-query -l 'ibus*' ==
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name  Version  Architecture Description
+++-=---
ii  ibus  1.5.26-4 amd64Intelligent Input Bus - core
ii  ibus-anthy1.5.14-1 amd64anthy engine for IBus
un  ibus-array  (no description available)
un  ibus-clutter(no description available)
ii  ibus-data 1.5.26-4 all  Intelligent Input Bus - data 
files
un  ibus-doc(no description available)
un  ibus-el (no description available)
un  ibus-googlepinyin   (no description available)
ii  ibus-gtk:amd641.5.26-4 amd64Intelligent Input Bus - GTK2 
support
ii  ibus-gtk3:amd64   1.5.26-4 amd64Intelligent Input Bus - GTK3 
support
ii  ibus-gtk4:amd64   1.5.26-4 amd64Intelligent Input Bus - GTK4 
support
un  ibus-mozc   (no description available)
un  ibus-pinyin (no description available)
un  ibus-qt5(no description available)

=== gsettings ===
org.freedesktop.ibus.general dconf-preserve-name-prefixes 
['/desktop/ibus/engine/pinyin', '/desktop/ibus/engine/bopomofo', 
'/desktop/ibus/engine/hangul']
org.freedesktop.ibus.general embed-preedit-text true
org.freedesktop.ibus.general enable-by-default false
org.freedesktop.ibus.general engines-order ['anthy', 'xkb:jp::jpn']
org.freedesktop.ibus.general preload-engines ['xkb:jp::jpn', 'anthy']
org.freedesktop.ibus.general switcher-delay-time 400
org.freedesktop.ibus.general use-global-engine true
org.freedesktop.ibus.general use-system-keyboard-layout false
org.freedesktop.ibus.general use-xmodmap true
org.freedesktop.ibus.general version '1.5.26'
org.freedesktop.ibus.general xkb-latin-layouts ['ara', 'bg', 'cz', 'dev', 'gr', 
'gur', 'in', 'jp(kana)', 'mal', 'mkd', 'ru', 'ua']
org.freedesktop.ibus.general.hotkey disable-unconditional @as []
org.freedesktop.ibus.general.hotkey enable-unconditional @as []
org.freedesktop.ibus.general.hotkey next-engine ['Alt+Shift_L']
org.freedesktop.ibus.general.hotkey next-engine-in-menu ['Alt+Shift_L']
org.freedesktop.ibus.general.hotkey prev-engine @as []
org.freedesktop.ibus.general.hotkey previous-engine @as []
org.freedesktop.ibus.general.hotkey trigger ['Control+space', 
'Zenkaku_Hankaku', 'Alt+Kanji', 'Alt+grave', 'Hangul', 'Alt+Release+Alt_R']
org.freedesktop.ibus.general.hotkey triggers ['Zenkaku_Hankaku']
org.freedesktop.ibus.panel auto-hide-timeout 1
org.freedesktop.ibus.panel custom-font 'Sans 16'
org.freedesktop.ibus.panel follow-input-cursor-when-always-shown false
org.freedesktop.ibus.panel lookup-table-orientation 1
org.freedesktop.ibus.panel property-icon-delay-time 500
org.freedesktop.ibus.panel show 2
org.freedesktop.ibus.panel show-icon-on-systray true
org.freedesktop.ibus.panel show-im-name false
org.freedesktop.ibus.panel use-custom-font true
org.freedesktop.ibus.panel use-glyph-from-engine-lang true
org.freedesktop.ibus.panel x -1
org.freedesktop.ibus.panel xkb-icon-rgba '#ff'
org.freedesktop.ibus.panel y -1

Bug#1011523: systemd-logind: lightdm ignores keyboard input for the first 3 seconds

[Vincent Lefevre]

On 2022-06-27 16:11:33 +0200, Vincent Lefevre wrote:
> cventin:~> systemd-analyze blame
> 10.812s NetworkManager-wait-online.service
[...]
> but the machine has 12 cores and I don't see a relation with
> systemd-logind.

Masking NetworkManager-wait-online.service doesn't solve the issue.

On 2022-06-27 15:39:51 +0200, Vincent Lefevre wrote:
> I'm wondering whether it could be related to this change:
> 
> Changes in udev:
> [...]
> * udevadm trigger gained a new --prioritized-subsystem= option to
>   process certain subsystems (and all their parent devices) earlier.
> 
>   systemd-udev-trigger.service now uses this new option to trigger
>   block and TPM devices first, hopefully making the boot a bit faster.
> 
> Also, I have plymouth installed on this machine. I should probably
> try without it to see if this makes a difference.

Uninstalling plymouth makes the boot faster, and in particular,
the display manager starts earlier, and I need to wait even more
before I can use the keyboard (there is still this 10-second
delay that appears in the logs).

However, reverting the change in systemd-udev-trigger.service by adding
/etc/systemd/system/systemd-udev-trigger.service with older contents
(from Debian/stable) as follows

--- /lib/systemd/system/systemd-udev-trigger.service2022-06-02 
20:07:11.0 +0200
+++ /etc/systemd/system/systemd-udev-trigger.service2022-06-29 
15:30:37.203967091 +0200
@@ -19,4 +19,5 @@
 [Service]
 Type=oneshot
 RemainAfterExit=yes
-ExecStart=-udevadm trigger --type=all --action=add 
--prioritized-subsystem=block,tpmrm
+ExecStart=udevadm trigger --type=subsystems --action=add
+ExecStart=udevadm trigger --type=devices --action=add

restores the old behavior. But I can see a 6-second freeze, e.g. on 2 tests:

Jun 29 15:36:57 cventin systemd[1]: Started Network Time Synchronization.
Jun 29 15:36:57 cventin systemd[1]: Reached target System Time Set.
Jun 29 15:37:03 cventin kernel: sr 2:0:0:0: Attached scsi generic sg0 type 5
Jun 29 15:37:03 cventin kernel: sr 3:0:0:0: Attached scsi generic sg1 type 5
Jun 29 15:37:03 cventin kernel: sd 6:0:0:0: Attached scsi generic sg2 type 0

and

Jun 29 15:38:02 cventin systemd[1]: Started Network Time Synchronization.
Jun 29 15:38:02 cventin systemd[1]: Reached target System Time Set.
Jun 29 15:38:08 cventin kernel: sr 2:0:0:0: Attached scsi generic sg0 type 5
Jun 29 15:38:08 cventin kernel: sr 3:0:0:0: Attached scsi generic sg1 type 5
Jun 29 15:38:08 cventin kernel: sd 6:0:0:0: Attached scsi generic sg2 type 0

Note that these "Attached scsi generic" messages occur only 1 second
after the boot without the change in systemd-udev-trigger.service, so
I'm wondering about the cause.

So it is possible that the new --prioritized-subsystem=block,tpmrm
option in systemd-udev-trigger.service introduced a side effect that
"fixes" the freeze (or was there a good reason for this freeze?) and
made an old keyboard issue appear, while it was previously hidden by
the freeze.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1007002: Lintian breaks existing lintian-overrides due to added []

[Samuel Thibault]

Hello,

Axel Beckert, le mer. 29 juin 2022 15:49:11 +0200, a ecrit:
> > I consider these [] not helpful […] no visible advantage.
> 
> The advantage is to clearly mark what is a file with potentially a
> line number in the output of lintian so that further processors like
> the lintian website can do deep links to the proper code position on
> e.g. sources.debian.org or salsa.debian.org. Felix called it "pointed
> hints".
> 
> From my point of view, that's quite an advantage.

Yes, I fully agree.  The format migration poses problem (I had to patch
quite a few lintian files), but it solves a lot other current-and-future
problems: we can now just ignore whole sets of warnings for a given file
(typically one that is generated by some tool such as doxygen)

Samuel

Bug#970146: blocked

[Matt Barry]

block -1 by 1014067
thanks

Bug#1014068: colmap: Application errors out at the start. Complains about logging

[Dima Kogan]

Package: colmap
Version: 3.7-2+b1
Severity: grave
X-Debbugs-Cc: Dima Kogan 

Hi. I just installed colmap. This happens:

  dima@shorty:$ colmap

  ERROR: something wrong with flag 'logtostderr' in file './src/logging.cc'.  
One possibility: file './src/logging.cc' is being linked both statically and 
dynamically into this executable.

Thanks.

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

Kernel: Linux 5.16.0-5-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.utf-8, LC_CTYPE=en_US.utf-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.utf-8), LANGUAGE=en_US.utf-8
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages colmap depends on:
ii  libc6  2.33-1
ii  libceres2  2.0.0+dfsg1-5
ii  libfreeimage3  3.18.0+ds2-6
ii  libgcc-s1  11.2.0-13
ii  libgl1 1.3.4-2+b1
ii  libglew2.2 2.2.0-4
ii  libgomp1   11.2.0-13
ii  libgoogle-glog0v6  0.6.0-1
ii  libqt5core5a   5.15.2+dfsg-14
ii  libqt5gui5 5.15.2+dfsg-14
ii  libqt5widgets5 5.15.2+dfsg-14
ii  libstdc++6 12-20220302-1

colmap recommends no packages.

colmap suggests no packages.

-- no debconf information

Bug#1007002: Lintian breaks existing lintian-overrides due to added []

[Axel Beckert]

Hi again,

Axel Beckert wrote:
> Andreas Tille wrote:
> > I'll start editing lintian-overrides then.
> 
> Maybe wait a bit with that. Given Lucas' comment, I feel a bit more
> urged to provide such a migration script.
> 
> I will look into this for the next upload. No promises as of now,
> though.

A first prototype is now available in git in the branch
"migrate-overrides":

https://salsa.debian.org/lintian/lintian/-/blob/migrate-overrides/bin/lintian-migrate-overrides-to-pointed-hints

So far the script only knows about the tags spelling-error-in-binary
and package-contains-documentation-outside-usr-share-doc, but it is
explicitly written to be expandable. Of course it will also get
support for more tags in the (near) future.

Additionally it currently only prints the transformed result to
STDOUT. The plan is to also support inline editing, either with an -i
option or maybe even by default if it detects that the package is
maintained in git.

Please give me feedback if this approach (especially after inline
editing is supported) is feasible — preferably from those who are
annoyed. :-)

It's not yet in the master branch as neither Perl::Critic nor myself
are happy about the usage of (the expression form of) "eval" in there.
(Maybe one of the other JAPH has an idea on this. :-)

Patches and other improvements suggestions as well as pattern sets for
further tags are of course welcome as well.

(Note: I will probably force-push that feature branch over and over
again until I'm satisfied. If someone else wants to work on the same
branch, too, we can also work without forced pushes and squash-merge
the result at the end. Please contact me, if you're interested.)

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

Bug#1013898: significantly slower than 3.0.17.4-3

[Sebastian Ramacher]

Control: forwarded -1 https://code.videolan.org/videolan/vlc/-/issues/26772
Control: tags -1 upstream confirmed

On 2022-06-26 20:44:12 -0400, Joey Hess wrote:
> Package: vlc
> Version: 3.0.17.4-4
> Severity: normal
> 
> I'm seeing only a few frames per second with -4 on 1080p H264 video.
> After downgrading to -3, it's back to ~60 FPS.
> 
> This is the last part of the output of -4. The VA-API stuff seems relevant
> somehow since the changelog says that was disabled in this version, but
> I'm only guessing.
> 
> [7fb0d8028210] gl gl: Initialized libplacebo v4.192.1 (API v192)
> libva info: VA-API version 1.14.0
> libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/iHD_drv_video.so
> libva info: Found init function __vaDriverInit_1_14
> libva info: va_openDriver() returns 0
> [7fb0f0c1f940] avcodec decoder: Using OpenGL/VAAPI backend for VDPAU for 
> hardware decoding
> 
> With -3, the output is the same except for the last line, which is:
> 
> [7fcc00c1d530] avcodec decoder: Using Intel iHD driver for Intel(R) Gen 
> Graphics - 22.4.3 () for hardware decoding

Given that -4 disabled VA-API support, that's expected. Once vlc gains
full support for ffmpeg 5, it will be re-enabled.

Cheers

> 
> -- System Information:
> Debian Release: bookworm/sid
>   APT prefers unstable-debug
>   APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), 
> (500, 'stable')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 5.17.0-1-amd64 (SMP w/4 CPU threads; PREEMPT)
> Kernel taint flags: TAINT_USER, TAINT_WARN
> Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (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 vlc depends on:
> ii  vlc-bin  3.0.17.4-4
> ii  vlc-plugin-base  3.0.17.4-4
> ii  vlc-plugin-qt3.0.17.4-4
> ii  vlc-plugin-video-output  3.0.17.4-4
> 
> Versions of packages vlc recommends:
> pn  vlc-l10n   
> pn  vlc-plugin-access-extra
> pn  vlc-plugin-notify  
> pn  vlc-plugin-samba   
> ii  vlc-plugin-skins2  3.0.17.4-4
> pn  vlc-plugin-video-splitter  
> pn  vlc-plugin-visualization   
> 
> Versions of packages vlc suggests:
> pn  vlc-plugin-fluidsynth  
> pn  vlc-plugin-jack
> ii  vlc-plugin-pipewire3-2
> pn  vlc-plugin-svg 
> 
> Versions of packages libvlc-bin depends on:
> ii  libc62.33-7
> ii  libvlc5  3.0.17.4-4
> 
> Versions of packages libvlc5 depends on:
> ii  libc62.33-7
> ii  libvlccore9  3.0.17.4-4
> 
> Versions of packages libvlc5 recommends:
> ii  libvlc-bin  3.0.17.4-4
> 
> Versions of packages libvlccore8 depends on:
> ii  dpkg 1.21.8
> ii  libc62.33-7
> ii  libdbus-1-3  1.14.0-1
> ii  libidn11 1.33-3
> 
> Versions of packages libvlccore8 recommends:
> ii  libproxy-tools  0.4.17-2
> 
> Versions of packages vlc-bin depends on:
> ii  libc6   2.33-7
> ii  libvlc-bin  3.0.17.4-4
> ii  libvlc5 3.0.17.4-4
> 
> Versions of packages vlc-plugin-base depends on:
> ii  liba52-0.7.4 0.7.4-20
> ii  libarchive13 3.6.0-1
> ii  libaribb24-0 1.0.3-2
> ii  libasound2   1.2.6.1-2+b1
> ii  libass9  1:0.16.0-1
> ii  libavahi-client3 0.8-6
> ii  libavahi-common3 0.8-6
> ii  libavc1394-0 0.5.4-5
> ii  libavcodec59 7:5.0.1-3
> ii  libavformat597:5.0.1-3
> ii  libavutil57  7:5.0.1-3
> ii  libbluray2   1:1.3.1-2
> ii  libc62.33-7
> ii  libcairo21.16.0-5
> ii  libcddb2 1.3.2-7
> ii  libchromaprint1  1.5.1-2+b1
> ii  libdav1d61.0.0-2
> ii  libdbus-1-3  1.14.0-1
> ii  libdc1394-25 2.2.6-4
> ii  libdca0  0.0.7-2
> ii  libdvbpsi10  1.3.3-1
> ii  libdvdnav4   6.1.1-1
> ii  libdvdread8  6.1.3-1
> ii  libebml5 1.4.2-2
> ii  libfaad2 2.10.0-2
> ii  libflac8 1.3.4-2
> ii  libfontconfig1   2.13.1-4.4
> ii  libfreetype6 2.12.1+dfsg-3
> ii  libfribidi0  1.0.8-2.1
> ii  libgcc-s112.1.0-4
> ii  libgcrypt20  1.10.1-2
> ii  libglib2.0-0 2.72.2-2
> ii  libgnutls30  3.7.6-2
> ii  libgpg-error01.45-2
> ii  libharfbuzz0b2.7.4-1+b1
> ii  libixml101:1.8.4-2
> 

Bug#1011688: Thank you!

[Michael Vogt]

Hey Boyuan Yang,

thank you so much your NMU and the diff. I will merge it into the git tree and 
may do a new upload with some more pending github fixes merged. Hope that is 
okay with you.

Thanks again for your help!
 Michael

Bug#1013437: cups: Nothing prints from driverless IPP queues unless added via lpadmin

[Brian Potkin]

On Tue 28 Jun 2022 at 11:47:57 +0100, Gareth Evans wrote:

> OK thanks for your help.  I have updated the upstream report and will
> update here when further info is available.

For printing your log shows:

D [28/Jun/2022:02:55:42 +0100] [Job 42] 6 filters for job:  

D [28/Jun/2022:02:55:42 +0100] [Job 42] bannertopdf 
(application/vnd.cups-pdf-banner to application/pdf, cost 32)   
D [28/Jun/2022:02:55:42 +0100] [Job 42] pdftopdf (application/pdf to 
application/vnd.cups-pdf, cost 66) 
D [28/Jun/2022:02:55:42 +0100] [Job 42] gstoraster (application/vnd.cups-pdf to 
application/vnd.cups-raster, cost 99
)   

D [28/Jun/2022:02:55:42 +0100] [Job 42] rastertopwg 
(application/vnd.cups-raster to image/urf, cost 100)
D [28/Jun/2022:02:55:42 +0100] [Job 42] - (image/urf to 
printer/cupsweb3/image/urf, cost 0) 
D [28/Jun/2022:02:55:42 +0100] [Job 42] - (printer/cupsweb3/image/urf to 
printer/cupsweb3, cost 0)

Searching for "exited with no errors" shows they all the filters
completed successfully. The everywhere model uses the same filter chain.

Cheers,

Brian.

Bug#1014072: ITP: python-srt -- Python library to handle SRT subtitle files

[Timo Röhling]

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: python-srt
  Version : 3.5.2
  Upstream Author : Christopher Down
* URL : https://github.com/cdown/srt
* License : Expat
  Programming Lang: Python
  Description : Python library to handle SRT subtitle files

srt is a tiny but featureful Python library for parsing, modifying, and
composing SRT subtitle files. It has a very robust parser that can deal with
many broken SRT files, and needs no dependencies beyond the Python Standard
Library.

The Python library is a required dependency for manim, the animation engine
for explanatory math videos.

The package will be team-maintained under the umbrella of
Debian Python Team 
at https://salsa.debian.org/python-team/packages/python-srt


-BEGIN PGP SIGNATURE-

iQGzBAEBCgAdFiEEJvtDgpxjkjCIVtam+C8H+466LVkFAmK8nYwACgkQ+C8H+466
LVkN/wv/Z7+VOlwj4iKxcEPVbOtJoG4/SUJwaN0YCnILA6gNn3HyDaOH0rU9aeca
z8cc1v9N4hYWEAzuiewIohE3zpMRHIw8PB6QoshMT6nwiakYQnGgc9igCNAvWBdk
43hU2k/2d6bIcZ+8LN7EB1wVb8WapnU4XXoMOGpcJpU5I1h+p2vwzrKJJEyX63wV
Zxl6CRV7qo8VQaxZ/83Yr7LbKhMDeiEME8+bScz45t/c2BHkR6B1Fl0SMhrf4CCE
po51zUILSCoY8URqYBiDwNQzVBcC5YBMXsVxPmxLE8FpRtbuNyyE3XDvESqGxHFc
drx5cFUagf9KK0UVepQpZ8Zel3ztfcpMeag7QCz91r1mzC7YxTB8VNsY2aAnhqTN
u53Eh23TeJmtiORevhTOVYKo0EvybIklM9wE+pUZ76BMZ0tAso/M7MLHYf6HqgB7
SUm0GumsmqzMp5ZoqhkRFOqvhztbaNCnv6n/tqg0OIm4zspajVkq+pk7Y57GKijo
11sLODDT
=V2Tz
-END PGP SIGNATURE-

Bug#1007002: Lintian breaks existing lintian-overrides due to added []

[Andreas Tille]

Hi Axel,

Am Wed, Jun 29, 2022 at 06:01:33PM +0200 schrieb Axel Beckert:
> Andreas: Sorry if I was a bit too opposing because of assuming that
> every DD uses Unstable by default.

No need to be sorry, really not.  I simply missed the point of that
change.

> (Actually I think the Dev Ref says
> you should, though. ;-) Or if DDs pinned Lintian to 2.111.0 from
> Testing…

I'm using testing but pinned lintian on unstable - so at least in my
case it was not what Lucas pointed out.  It was just that I beared the
change for some time ... and than my amount of patience spilled over.
;-P

But its correct that some users might use lintian from testing anyway.

Kind regards

 Andreas.

-- 
http://fam-tille.de

Bug#968467:

[Nilson Silva]

Hello Bastian!
Sorry for not being very clear in the answer.

But the story of python-librosa is this:

Numba has problems that have already been reported in this bug:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1008522

Even try to install numba on your machine. In mine and some people I ask for 
the test: .
It is roughly saying that only compatible with versions < python 3.10 but even 
if python 3.9 is installed, it gives the same error. Correct me if I'm wrong)

A newer version already exists in the project's official repository.
https://github.com/numba/numba/releases/tag/0.55.1
## ##


But here's a problem:
In the debian repositories, the most current version is
V0.52.0-5: https://tracker.debian.org/media/packages/n/numba/changelog-0.52.0-5

In salsa the Debian Science Team, is already in the newest version:
V(0.55.0) 
https://salsa.debian.org/science-team/numba/-/blob/debian/master/debian/changelog
I don't know why it hasn't moved up to Debian yet. But I suspect. which is 
related to libtbb-dev (>= 2021.4.0).
Because in debian it exists, in the lower version. 
https://tracker.debian.org/pkg/tbb 2020.3-1:.

I think for this reason they are breaking from the CI test 
https://salsa.debian.org/science-team/numba/-/pipelines/341420

There is even a new version of TBB
https://github.com/oneapi-src/oneTBB/releases/tag/v2021.5.0.
## ###

In short:

>From what I understand, I would have to update the TBB, then upload this new 
>version, making a new packaging.

Then upload numba to Debian, since salsa is ready. But I don't know if in fact 
it will solve this problem of numb



Nilson F. Silva



De: Bastian Germann 
Enviado: quarta-feira, 29 de junho de 2022 15:49
Para: 968...@bugs.debian.org <968...@bugs.debian.org>
Assunto: Bug#968467:

Control: retitle -1 ITP: librosa -- module for audio and music processing

On Mon, 27 Jun 2022 13:42:38 + Nilson Silva  
wrote:
> I already made the package However it is depending on the latest version of 
> "numba" which is still in progress!

setup.py has

install_requires:
numba >= 0.45.1

options.extras_require:
docs =
numba < 0.50

Debian has 0.55.1. Are you sure with your claim? Maybe this needs an older 
version...

Bug#1014069: black: Incoherence between Debian and Python for package version

[Laurent Cheylus]

Package: black
Version: 22.3.0-1
Severity: important

Dear Maintainer,

Black tool is installed on my desktop via Debian repository : for Debian 
testing,
latest version is 22.3.0-1

$ dpkg -l black
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name   Version  Architecture Description
+++-==---===
ii  black  22.3.0-1 all  uncompromising Python code 
formatter (Python 3)

But according to pip, version for Black Python package is 21.10b0 :

$ pip3 list |grep black
black   21.10b0

I have no other local install of black on this machine.

The directory /usr/lib/python3/dist-packages/black-21.10b0.egg-info/ installed
via black-22.3.0-1 package seems to me to be an error. Do you confirm ?

$ dpkg -S /usr/lib/python3/dist-packages/black-21.10b0.egg-info
black: /usr/lib/python3/dist-packages/black-21.10b0.egg-info

$ dpkg -L black|grep 21.10b0
/usr/lib/python3/dist-packages/black-21.10b0.egg-info
/usr/lib/python3/dist-packages/black-21.10b0.egg-info/PKG-INFO
/usr/lib/python3/dist-packages/black-21.10b0.egg-info/dependency_links.txt
/usr/lib/python3/dist-packages/black-21.10b0.egg-info/entry_points.txt
/usr/lib/python3/dist-packages/black-21.10b0.egg-info/not-zip-safe
/usr/lib/python3/dist-packages/black-21.10b0.egg-info/requires.txt
/usr/lib/python3/dist-packages/black-21.10b0.egg-info/top_level.txt


regards, Laurent

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

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

Versions of packages black depends on:
ii  python33.10.4-1+b1
ii  python3-click  8.0.3-1
ii  python3-mypy-extensions0.4.3-3
ii  python3-pathspec   0.9.0-1
ii  python3-pkg-resources  59.6.0-1.2
ii  python3-platformdirs   2.5.2-1
ii  python3-tomli  1.2.2-2
ii  python3-typing-extensions  3.10.0.2-1

black recommends no packages.

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

-- no debconf information

Bug#1014070: libengine-gost-openssl: Missing build dependency on pkg-config

[Adrian Bunk]

Source: libengine-gost-openssl
Version: 3.0.1-1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/package.php?p=libengine-gost-openssl=sid

...
-- Could NOT find PkgConfig (missing: PKG_CONFIG_EXECUTABLE) 
CMake Error at CMakeLists.txt:114 (message):
  Unable to discover the OpenSSL engines directory.  Provide the path using
  -DOPENSSL_ENGINES_DIR


-- Configuring incomplete, errors occurred!

Bug#1014073: llvm-toolchain-14: FTBFS on i386

[Sebastian Ramacher]

Source: llvm-toolchain-14
Version: 1:14.0.6-1
Severity: serious
Tags: ftbfs sid bookworm
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: sramac...@debian.org

https://buildd.debian.org/status/fetch.php?pkg=llvm-toolchain-14=i386=1%3A14.0.6-1=1656298705=0

[63/64] cd /<>/build-llvm/tools/clang/stage2-bins/tools/mlir/test 
&& /usr/bin/python3.10 
/<>/build-llvm/tools/clang/stage2-bins/./bin/llvm-lit -sv 
/<>/build-llvm/tools/clang/stage2-bins/tools/mlir/test
-- Testing: 1294 tests, 4 workers --
Testing: 0  2  4  6  8  10 12 14 16 18 20 22 24 26 28 30 32 34 36 38 40 42 44 
46 48 50 52 54 56 58 60 62 
FAIL: MLIR :: Transforms/loop-fusion-2.mlir (834 of 1294)
 TEST 'MLIR :: Transforms/loop-fusion-2.mlir' FAILED 

Script:
--
: 'RUN: at line 1';   
/<>/build-llvm/tools/clang/stage2-bins/bin/mlir-opt 
-allow-unregistered-dialect 
/<>/mlir/test/Transforms/loop-fusion-2.mlir -affine-loop-fusion 
-split-input-file | 
/<>/build-llvm/tools/clang/stage2-bins/bin/FileCheck 
/<>/mlir/test/Transforms/loop-fusion-2.mlir
: 'RUN: at line 2';   
/<>/build-llvm/tools/clang/stage2-bins/bin/mlir-opt 
-allow-unregistered-dialect 
/<>/mlir/test/Transforms/loop-fusion-2.mlir 
-affine-loop-fusion="fusion-maximal" -split-input-file | 
/<>/build-llvm/tools/clang/stage2-bins/bin/FileCheck 
/<>/mlir/test/Transforms/loop-fusion-2.mlir --check-prefix=MAXIMAL
--
Exit Code: 1

Command Output (stderr):
--
/<>/mlir/test/Transforms/loop-fusion-2.mlir:372:16: error: 
CHECK-NEXT: is not on the line after the previous match
// CHECK-NEXT: affine.store %{{.*}}, %{{.*}}[0, 0] : memref<1x1xf32>
   ^
:312:2: note: 'next' match was here
 affine.store %10, %0[0, 0] : memref<1x1xf32>
 ^
:176:29: note: previous match ended here
 affine.for %arg3 = 0 to 3 {
^
:177:1: note: non-matching line after previous match is here
 affine.store %cst_1, %0[0, %arg3] : memref<1x3xf32>
^

Input file: 
Check file: /<>/mlir/test/Transforms/loop-fusion-2.mlir

-dump-input=help explains the following input dump.

Input was:
<<
  .
  .
  .
307:  %6 = affine.apply #map1(%4, %arg1) 
308:  %7 = affine.apply #map2(%4, %arg1) 
309:  %8 = affine.apply #map3(%4, %arg1) 
310:  %9 = affine.apply #map4(%4, %arg1) 
311:  %10 = affine.load %1[%5, %6, %8, %9, %7, %c0] : 
memref<2x2x3x3x16x1xf32> 
312:  affine.store %10, %0[0, 0] : memref<1x1xf32> 
next:372  !~~~  error: match on 
wrong line
313:  %11 = affine.apply #map5(%arg2, %arg3) 
314:  %12 = affine.load %0[0, 0] : memref<1x1xf32> 
315:  } 
316:  affine.for %arg3 = 0 to 16 { 
317:  %4 = affine.apply #map5(%arg1, %arg3) 
  .
  .
  .
>>

--


Testing: 0  2  4  6  8  10 12 14 16 18 20 22 24 26 28 30 32 34 36 38 40 42 44 
46 48 50 52 54 56 58 60 62 64 
FAIL: MLIR :: mlir-cpu-runner/async-value.mlir (874 of 1294)
 TEST 'MLIR :: mlir-cpu-runner/async-value.mlir' FAILED 

Script:
--
: 'RUN: at line 1'; 
/<>/build-llvm/tools/clang/stage2-bins/bin/mlir-opt 
/<>/mlir/test/mlir-cpu-runner/async-value.mlir 
-async-to-async-runtime 
-async-runtime-ref-counting 
-async-runtime-ref-counting-opt 
-convert-async-to-llvm  
-convert-arith-to-llvm  
-convert-vector-to-llvm 
-convert-memref-to-llvm 
-convert-std-to-llvm
-reconcile-unrealized-casts   | 
/<>/build-llvm/tools/clang/stage2-bins/bin/mlir-cpu-runner 
  -e main 
-entry-point-result=void -O0
-shared-libs=/<>/build-llvm/tools/clang/stage2-bins/lib/libmlir_c_runner_utils.so
   
-shared-libs=/<>/build-llvm/tools/clang/stage2-bins/lib/libmlir_runner_utils.so
 
-shared-libs=/<>/build-llvm/tools/clang/stage2-bins/lib/libmlir_async_runtime.so
| /<>/build-llvm/tools/clang/stage2-bins/bin/FileCheck 
/<>/mlir/test/mlir-cpu-runner/async-value.mlir --dump-input=always
--
Exit Code: 134

Command Output (stderr):
--
free(): invalid next size (fast)
free(): invalid next size (fast)

Input file: 
Check file: /<>/mlir/test/mlir-cpu-runner/async-value.mlir

-dump-input=help explains the following input dump.

Input was:
<<
   1: 123.456 
   2: 456.789 
   3: Unranked Memref base@ = 0xe9d00610 rank = 0 offset = 0 sizes = [] strides 
= [] data =  
   4: [0.25] 
   5: Unranked Memref base@ = 0xe9d00610 rank = 0 offset = 0 sizes = [] 

Bug#1013946: lintian: wrongly report unknown-locale-code ber

[Axel Beckert]

Hi Tobias,

Dr. Tobias Quathamer wrote:
> The safest way for lintian would probably be to use ISO 639-3 as a source
> for locale checking, because those codes represent an individual language.
> The vast majority of program translations are into an individual language,
> so the check seems plausible.
> 
> For bonus points, you could also check ISO 639-5 and print a warning (or
> info) that this locale code represents a language group rather than an
> individual language. :-)
> 
> This is essentially Axel's latest suggestion -- except that I'd suggest to
> use ISO 639-3 instead of ISO 639-2 as authoritative source.

Thanks for this summary and especially also all the history! (And for
reading our long mails which showed bit by bit our experiences and
discoveries. :-)

> Sorry for this long e-mail, but languages and their codes are pretty
> hard ...

No need to be sorry!

Will try to implement this in lintian.

Thanks again!

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

Bug#1014062: Failure to load kernel modules at boot time

[Eduardo Casais]

Dear Maintainers,

I just noticed that the package name was incorrect. It is systemd and 
not system2 as mentioned in the original bug report.


Please categorize the bug report accordingly.

Sincerely

Eduardo Casais

Bug#1014071: digikam can no more be installed on unstable (needs rebuild with new kdepim packages)

[Eric Valette]

Package: digikam
Version: 4:7.6.0-1
Severity: normal

apt install digikam
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 digikam-private-libs : Depends: libkf5akonadicontact5-21.12
E: Unable to correct problems, you have held broken packages.


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

Kernel: Linux 5.10.125 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=fr_FR.UTF8, LC_CTYPE=fr_FR.UTF8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages digikam depends on:
ii  digikam-data  4:7.6.0-1
pn  digikam-private-libs  
ii  libc6 2.34-0experimental4
ii  libgcc-s1 12.1.0-4
ii  libkf5configcore5 5.94.0-3
ii  libkf5coreaddons5 5.94.0-1
ii  libkf5i18n5   5.94.0-1+b1
ii  libmagick++-6.q16-8   8:6.9.11.60+dfsg-1.3+b2
ii  libqt5core5a  5.15.4+dfsg-3
ii  libqt5gui55.15.4+dfsg-3
ii  libqt5sql55.15.4+dfsg-3
ii  libqt5sql5-mysql  5.15.4+dfsg-3
ii  libqt5sql5-sqlite 5.15.4+dfsg-3
ii  libqt5widgets55.15.4+dfsg-3
ii  libstdc++612.1.0-4
ii  perl  5.34.0-4

Versions of packages digikam recommends:
ii  ffmpegthumbs 4:22.04.2-1
ii  firefox-esr [www-browser]91.11.0esr-1
ii  google-chrome-stable [www-browser]   103.0.5060.53-1
ii  konqueror [www-browser]  4:21.12.3-1
ii  links2 [www-browser] 2.27-1
ii  lynx [www-browser]   2.9.0dev.10-1
ii  microsoft-edge-stable [www-browser]  103.0.1264.37-1
ii  w3m [www-browser]0.5.3+git20220429-1+b1

Versions of packages digikam suggests:
ii  breeze-icon-theme  4:5.94.0-1
pn  digikam-doc
ii  systemsettings 4:5.25.1-1

Bug#1013299: linux-image-4.19.0-20-amd64: NULL pointer deref in qdisc_put() due to missing backport

[Ben Hutchings]

On Wed, 2022-06-29 at 16:49 +0200, Diederik de Haas wrote:
> On Wednesday, 29 June 2022 15:24:45 CEST Ben Hutchings wrote:
> > Control: tag -1 patch
> > Control: tag -1 - help
> > 
> > On Wed, 2022-06-22 at 11:47 +0200, Diederik de Haas wrote:
> > > On Tuesday, 21 June 2022 16:11:42 CEST Diederik de Haas wrote:
> > > > > So yes, this needs to also be fixed upstream (hence me including that
> > > > > tag when reporbugging), but perhaps Debian can quickfix.
> > > > 
> > > > What I have observed so far is that a commit needs to be accepted
> > > > upstream
> > > > (but doesn't have to have gone through the whole 'chain of command')
> > > > before a temporary patch is accepted to quickly fix it in Debian.
> > > 
> > > I made an initial attempt at a patch, see attachment.
> > > https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html#
> > > s4.2.2 describes a way to test whether this patch fixes the issue.
> > > (Just in case. I'm reasonably sure you already know this)
> > 
> > Looks good to me.  Can you send it on to sta...@vger.kernel.org?
> > You'll need to add your Signed-off-by.
> 
> I proposed my patch to expedite things and (much) prefer that Thorsten would 
> send it (that's why I explicitly omitted the Signed-off-by statement).
> If there are follow up questions, they would also be directed to the person 
> who found the issue and is the right person to answer them. I'd have to relay 
> them and possibly introduce noise in the communication.

As Thorsten's email is in the Reported-by pseudo-header, he should be
cc'd on all discussions.

> I can do it, but I would like Thorsten to test the patch and confirm it 
> actually does fix it. Having a Tested-By tag would be nice.
> When submitting a MR to the Debian kernel, I'm rightfully expected to have 
> verified it does what it is supposed to do. For the upstream kernel, I'd 
> expect 
> the same at a minimum.
> 
> Is the prefix I used for the patch, the correct one?

"net/sched" seems to be preferred.

Ben.

-- 
Ben Hutchings
Reality is just a crutch for people who can't handle science fiction.


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

Bug#697700: New watch file for Ubuntu

[Steve McIntyre]

On Tue, Jun 21, 2022 at 11:19:01AM +0200, Alexandre Ghiti wrote:
>Hi,
>
>In Ubuntu, we intend to add the following watch file in case you're interested.

Feel free if you like - as I'm upstream I don't feel much benefit for
me... :-)

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
“Rarely is anyone thanked for the work they did to prevent the
 disaster that didn’t happen.”
   -- Mikko Hypponen (https://twitter.com/mikko/)

Bug#1014067: RFP: python-pdm -- next generation Python package management tool

[Matt Barry]

Package: wnpp
Severity: wishlist

* Package name: python-pdm
  Version : 1.15.4
  Upstream Author : frostming 
* URL : https://github.com/pdm-project/pdm
* License : MIT
  Programming Lang: Python
  Description : next generation Python package management tool

(from the site)
PDM is meant to be a next generation Python package management tool.  It was
originally built for personal use. If you feel you are going well with Pipenv
or Poetry and don't want to introduce another package manager, just stick to
it. But if you are missing something that is not present in those tools, you
can probably find some goodness in pdm.

This package includes a PEP517 backend that is required for packaging
pyproject.toml style modules.

Bug#1014069: [black Bug #1014069] Error in Debian patch

[Laurent Cheylus]

Package: black
Version: 22.3.0-1
Followup-For: Bug #1014069

After some debug, the root cause of this issue seems to be in debian/patches
black_version.patch :

--- black.orig/setup.py
+++ black/setup.py
@@ -47,10 +47,7 @@ else:
 
 setup(
 name="black",
-use_scm_version={
-"write_to": "src/_black_version.py",
-"write_to_template": 'version = "{version}"\n',
-},
+version="21.10b0",
 description="The uncompromising code formatter.",
 long_description=get_long_description(),
 long_description_content_type="text/markdown",

Wrong version 21.10b0 for black package 22.3.0. Either correct this patch for
22.3.0 version or maybe it is no longer necessary.


regards, Laurent

Bug#1013132: ITP: BabaSSL -- BabaSSL is a base library for modern cryptography and communication security protocols.

[Marco d'Itri]

On Jun 22, Lance Lin  wrote:

> Yes, from my understanding it is a "drop in" replacement for OpenSSL. One of 
> my packages (Workflow) uses it but can also use OpenSSL. 
> 
> I think this package will be beneficial to the Workflow users and downstream 
> OS's.
Can you explain exactly what benefits these users have from using 
BabaSSL instad of OpenSSL? And why only these users and not the users of 
other current dependencies of OpenSSL?

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#968467:

[Bastian Germann]

Control: retitle -1 ITP: librosa -- module for audio and music processing

On Mon, 27 Jun 2022 13:42:38 + Nilson Silva  
wrote:

I already made the package However it is depending on the latest version of 
"numba" which is still in progress!


setup.py has

install_requires:
numba >= 0.45.1

options.extras_require:
docs =
numba < 0.50

Debian has 0.55.1. Are you sure with your claim? Maybe this needs an older 
version...

Bug#1013946: lintian: wrongly report unknown-locale-code ber

[Dr. Tobias Quathamer]

Am 28.06.22 um 02:31 schrieb Axel Beckert:

Still would be happy about input from Toddy on this. :-)


Hi all,

thanks a lot for your research and insights ...

I'm not an ISO expert, either, but from my reading and understanding the 
relationship between the standards (and the intended use) is as follows:


First, ISO 639 (without the suffix -1) was created, and it included most 
of the major (spoken and written) languages of the world. All included 
languages had a two letter code (like "en" for English).


As it quickly turned out, the two letter code was not enough to 
categorize all written and spoken languages. :-)


Therefore, ISO 639 became ISO 639-1 and the development of ISO 639-2 
started. As far as I know, ISO 639-1 is a strict subset of ISO 639-2.


The standard ISO 639-2 introduced a three letter code, so they could 
include many more languages. As the standard was intended to be used in 
bibliographic contexts, they created a code for every individual 
language which has at least a "modest body of literature" (whatever 
"modest" means here.)


In order to accommodate languages with an even smaller proportion of 
literature, they created collections of languages, called "language 
groups" or "families". One such example are the Berber languages which 
you've discovered.


Lastly, ISO 639-3 and 639-5 have been created. Those standards aim to 
make a clear distinction between individual languages (in ISO 639-3) and 
language groups or families (ISO 639-5).


Apart from the language families (like Berber), every element that 
represents an individual language in ISO 639-2 is included in ISO 639-3. 
So for individual languages, ISO 639-2 is a strict subset of ISO 639-3.




I'm not entirely sure if it's a good idea to use a language family as a 
locale (or in this context, program translation). It might work for the 
Berber example, if the Berber languages are really so similar that it 
doesn't matter which language it is exactly. However, I don't know 
anything about Berber languages, so I cannot tell if this approach makes 
sense.


From a quick search, there are at least Kabyle language, Shilha 
language, the Tuareg languages, Tarifit, and Central Atlas Tamazight 
which are summed up as Berber languages.




The safest way for lintian would probably be to use ISO 639-3 as a 
source for locale checking, because those codes represent an individual 
language. The vast majority of program translations are into an 
individual language, so the check seems plausible.


For bonus points, you could also check ISO 639-5 and print a warning (or 
info) that this locale code represents a language group rather than an 
individual language. :-)


This is essentially Axel's latest suggestion -- except that I'd suggest 
to use ISO 639-3 instead of ISO 639-2 as authoritative source.


Sorry for this long e-mail, but languages and their codes are pretty 
hard ...


Regards,
Tobias


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1014054: bullseye-pu: package node-got/11.8.1+~cs53.13.17-3+deb11u1

[Yadd]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu

[ Reason ]
node-got allows redirection to unix sockets (#1013264, CVE-2022-33987)

[ Impact ]
Medium vulnerability: a remote host can redirect a node-got request to a
Unix socket

[ Tests ]
Sadly test aren't enabled: ava was introduced earlier in Debian

[ Risks ]
Low risk:
 * patch is trivial
 * package is built from TypeScript, then tsc compiler checks for
   a lot of errors

[ 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 ]
Just reject URL starting with "unix:" if original request wasn't a
"unix:" request.

Note that I had to add a typescript change: one ignored error is no more
an error.

Regards,
Yadd
diff --git a/debian/changelog b/debian/changelog
index 9cda1ef..a4bd358 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+node-got (11.8.1+~cs53.13.17-3+deb11u1) bullseye; urgency=medium
+
+  * Team upload
+  * Don't allow redirection to Unix socket (Closes: #1013264, CVE-2022-33987)
+
+ -- Yadd   Wed, 29 Jun 2022 16:30:16 +0200
+
 node-got (11.8.1+~cs53.13.17-3) unstable; urgency=medium
 
   * Team upload
diff --git a/debian/patches/CVE-2022-33987.patch 
b/debian/patches/CVE-2022-33987.patch
new file mode 100644
index 000..79c012f
--- /dev/null
+++ b/debian/patches/CVE-2022-33987.patch
@@ -0,0 +1,100 @@
+Description: Don't allow redirect to Unix socket
+Author: Sindre Sorhus 
+Origin: upstream, https://github.com/sindresorhus/got/commit/bce8ce7d
+Bug: https://github.com/sindresorhus/got/pull/2047
+Bug-Debian: https://bugs.debian.org/1013264
+Forwarded: not-needed
+Reviewed-By: Yadd 
+Last-Update: 2022-06-29
+
+--- a/source/core/index.ts
 b/source/core/index.ts
+@@ -2102,6 +2102,16 @@
+   const redirectString = redirectUrl.toString();
+   decodeURI(redirectString);
+ 
++  // eslint-disable-next-line 
no-inner-declarations
++  function isUnixSocketURL(url: URL) {
++  return url.protocol === 'unix:' || 
url.hostname === 'unix';
++  }
++
++  if (!isUnixSocketURL(url) && 
isUnixSocketURL(redirectUrl)) {
++  this._beforeError(new 
RequestError('Cannot redirect to UNIX socket', {}, this));
++  return;
++  }
++
+   // Redirecting to a different site, clear 
sensitive data.
+   if (redirectUrl.hostname !== url.hostname || 
redirectUrl.port !== url.port) {
+   if ('host' in options.headers) {
+--- a/test/redirects.ts
 b/test/redirects.ts
+@@ -1,7 +1,7 @@
+ import test from 'ava';
+ import {Handler} from 'express';
+ import nock = require('nock');
+-import got, {MaxRedirectsError} from '../source';
++import got, {MaxRedirectsError, RequestError} from '../source';
+ import withServer, {withHttpsServer} from './helpers/with-server';
+ 
+ const reachedHandler: Handler = (_request, response) => {
+@@ -509,3 +509,32 @@
+   t.is(response.body, 'SERVER2');
+   });
+ });
++
++const unixProtocol: Handler = (_request, response) => {
++  response.writeHead(302, {
++  location: 'unix:/var/run/docker.sock:/containers/json'
++  });
++  response.end();
++};
++
++const unixHostname: Handler = (_request, response) => {
++  response.writeHead(302, {
++  location: 'http://unix:/var/run/docker.sock:/containers/json'
++  });
++  response.end();
++};
++
++test('cannot redirect to unix protocol', withServer, async (t, server, got) 
=> {
++  server.get('/protocol', unixProtocol);
++  server.get('/hostname', unixHostname);
++
++  await t.throwsAsync(got('protocol'), {
++  message: 'Cannot redirect to UNIX socket',
++  instanceOf: RequestError
++  });
++
++  await t.throwsAsync(got('hostname'), {
++  message: 'Cannot redirect to UNIX socket',
++  instanceOf: RequestError
++  });
++});
+--- a/test/unix-socket.ts
 b/test/unix-socket.ts
+@@ -8,6 +8,13 @@
+   response.end('ok');
+ };
+ 
++const redirectHandler: Handler = (_request, response) => {
++  response.writeHead(302, {
++  location: 'foo'
++  });
++  response.end();
++};
++
+ if (process.platform !== 'win32') {
+   test('works', withSocketServer, async (t, server) => {
+   server.on('/', okHandler);
+@@ -53,3 +60,11 @@
+   t.is((await got(url)).body, 'ok');
+   });
+ }
++
++test('redirects work', withSocketServer, async (t, server) => {
++  server.on('/', 

Bug#1014055: ITP: pdm-pep517 -- Yet another PEP 517 backend for PDM projects

[Boyuan Yang]

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

* Package name: pdm-pep517
  Version : 1.0.0
  Upstream Author : Frost Ming
* URL : https://github.com/pdm-project/pdm-pep517
* License : Expat
  Programming Lang: Python
  Description : Yet another PEP 517 backend for PDM projects

 This is the backend for PDM projects, while you can also use it alone.
 It reads the metadata of PEP 621 format and coverts it to Core metadata.

This package is the build-dependency for several packages in Debian.
I intend to maintain this package as part of the Debian Python Team.
Packaging work will be stored at
https://salsa.debian.org/python-team/packages/pdm-pep517 .

Thanks,
Boyuan Yang


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

Bug#1013299: linux-image-4.19.0-20-amd64: NULL pointer deref in qdisc_put() due to missing backport

[Diederik de Haas]

On Wednesday, 29 June 2022 15:24:45 CEST Ben Hutchings wrote:
> Control: tag -1 patch
> Control: tag -1 - help
> 
> On Wed, 2022-06-22 at 11:47 +0200, Diederik de Haas wrote:
> > On Tuesday, 21 June 2022 16:11:42 CEST Diederik de Haas wrote:
> > > > So yes, this needs to also be fixed upstream (hence me including that
> > > > tag when reporbugging), but perhaps Debian can quickfix.
> > > 
> > > What I have observed so far is that a commit needs to be accepted
> > > upstream
> > > (but doesn't have to have gone through the whole 'chain of command')
> > > before a temporary patch is accepted to quickly fix it in Debian.
> > 
> > I made an initial attempt at a patch, see attachment.
> > https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html#
> > s4.2.2 describes a way to test whether this patch fixes the issue.
> > (Just in case. I'm reasonably sure you already know this)
> 
> Looks good to me.  Can you send it on to sta...@vger.kernel.org?
> You'll need to add your Signed-off-by.

I proposed my patch to expedite things and (much) prefer that Thorsten would 
send it (that's why I explicitly omitted the Signed-off-by statement).
If there are follow up questions, they would also be directed to the person 
who found the issue and is the right person to answer them. I'd have to relay 
them and possibly introduce noise in the communication.

I can do it, but I would like Thorsten to test the patch and confirm it 
actually does fix it. Having a Tested-By tag would be nice.
When submitting a MR to the Debian kernel, I'm rightfully expected to have 
verified it does what it is supposed to do. For the upstream kernel, I'd expect 
the same at a minimum.

Is the prefix I used for the patch, the correct one?

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

Bug#1007002: Lintian breaks existing lintian-overrides due to added []

[Axel Beckert]

Hi Lucas,

Lucas Nussbaum wrote:
> Just a note that since the last version of lintian to migrate to testing
> was 2.111 (which was also the last one to be backported to stable), some
> of us might not have updated since 2.111 and might be hit by changes
> that happened since then.

Oh, right! Thanks for that view on Andreas' mail.

I indeed did not think about that case because I do nearly all Debian
development work on Unstable (and occassionally on Stable when a new
package starts as a quick and dirty hack to scratch my own itches at
work :-).

And until my reply to Andreas I also wasn't aware of when Felix
actually started with this. Just knew that it wasn't a one-shot thing,
but quite distributed over at least the past half year (because that's
the timeframe of git commits I most often looked into in the past few
weeks).

Andreas: Sorry if I was a bit too opposing because of assuming that
every DD uses Unstable by default. (Actually I think the Dev Ref says
you should, though. ;-) Or if DDs pinned Lintian to 2.111.0 from
Testing…

Andreas Tille wrote:
> I'll start editing lintian-overrides then.

Maybe wait a bit with that. Given Lucas' comment, I feel a bit more
urged to provide such a migration script.

I will look into this for the next upload. No promises as of now,
though.

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

Bug#1014058: exim4-daemon-heavy: please compile with SPF and DMARC support

[Fabio Muzzi]

Package: exim4-daemon-heavy
Version: 4.94.2-7
Severity: wishlist

It should be useful if the binary package exim4-daemon-heavy could be
compiled to include SPF and DMARC support internally.

The current Debian config uses an external script for SPF checks on
received mail, but I'd like to be able to use the internal capabilities
in EXIM itself for SPF and DMARC checks.

This requires to include SUPPORT_SPF=yes and SUPPORT_DMARC in the
makefile, and of course it should probably be done only for the heavy
version of the Exim daemon.

Thanks

Fabio Muzzi

Bug#1013299: linux-image-4.19.0-20-amd64: NULL pointer deref in qdisc_put() due to missing backport

[Thorsten Glaser]

Diederik de Haas dixit:

>I proposed my patch to expedite things and (much) prefer that Thorsten would

I’m not the author…

>I can do it, but I would like Thorsten to test the patch and confirm it

It’s obviously correct, it moves the nil check to the correct place.

I tested “the reverse” by doing…

@@ -1275,11 +1275,12 @@ static void htb_destroy_class(struct Qdisc *sch, struct 
htb_class *cl)
WARN_ON(!cl->leaf.q);
 #if (LINUX_VERSION_CODE < KERNEL_VERSION(4, 20, 0)) && \
 (!defined(JENS_LINUX_4_19_SL) || (JENS_LINUX_4_19_SL < 221))
qdisc_destroy(cl->leaf.q);
 #else
-   qdisc_put(cl->leaf.q);
+   if (cl->leaf.q)
+   qdisc_put(cl->leaf.q);
 #endif
}
gen_kill_estimator(>rate_est);
tcf_block_put(cl->block);
kfree(cl);

… so the net effect is tested.

bye,
//mirabilos
-- 
Infrastrukturexperte • tarent solutions GmbH
Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/
Telephon +49 228 54881-393 • Fax: +49 228 54881-235
HRB AG Bonn 5168 • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

Bug#1014063: RM: gnome-phone-manager -- RoQA; unmaintained

[Jeremy Bicha]

Package: ftp.debian.org
Severity: normal
X-Debbugs-CC: gnome-phone-mana...@packages.debian.org

gnome-phone-manager has been abandoned upstream. It hadn't received
any updates except for translations in a decade. It is no longer
receiving any bug reports, patches, or translations.
https://gitlab.gnome.org/Archive/phonemgr

It depends on other abandoned libraries like dbus-glib, gconf, gnome-bluetooth.

When I tried running it, the app fails to start. Because no one uses it.

The recommended replacement is kdeconnect or gnome-shell-extension-gsconnect.

Thank you,
Jeremy Bicha

Bug#1014066: ghc: FTBFS on mipsel: out of memory

[Sebastian Ramacher]

Source: ghc
Version: 9.0.2-1exp1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

https://buildd.debian.org/status/fetch.php?pkg=ghc=mipsel=9.0.2-2=1656478402=0


- GHC.StgToCmm.Layout.slowArgs
Warning: GHC.Stg.Pipeline: could not find link destinations for:

- GHC.Stg.Pipeline.getStgToDo
Warning: GHC.ByteCode.Instr: could not find link destinations for:

- GHC.Bythaddock: out of memory (requested 1048576 bytes)
make[3]: *** [compiler/ghc.mk:300: compiler/stage2/doc/html/ghc/ghc.haddock] 
Error 251


Cheers
-- 
Sebastian Ramacher

Bug#1014056: apache2: /var/run/apache2 permissions too narrow for cgid

[MK]

Package: apache2
Version: 2.4.53-1~deb11u1
Severity: minor


Dear Maintainer,


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


Enabling cgid in apache2 (with a2enmod cgid) results in an error when using 
mpm_event:
    [cgid:error] [pid 8943:tid 140189712234240] (22)Invalid argument: [client 
x.x.x.x:49364] AH01257: unable to connect to cgi daemon after multiple tries: 
/usr/lib/cgi-bin/xx
Meanwhile, the user receives a 503 HTTP error, rather than the CGI content.

Upon launch, Apache creates /var/run/apache2/cgisock.PID (where PID is the PID 
in question), however it does that as the www-data user and root group, who 
does not have write access to /var/run/apache2 (where only the root user has 
write permission).

To fix this, chmod g+rwx /var/run/apache2 fixes the issue.  Since we're only 
adding the root group, this likely has a minimal security effect.

Alternately, the default directive of
    /etc/apache2/mods-available/cgid.conf:    ScriptSock 
${APACHE_RUN_DIR}/cgisock
Should not point to a folder that does not have write access by www-data user 
and a subfolder with more open permission should be created.

-- Package-specific info:


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


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


Versions of packages apache2 depends on:
ii  apache2-bin          2.4.53-1~deb11u1
ii  apache2-data         2.4.53-1~deb11u1
ii  apache2-utils        2.4.53-1~deb11u1
ii  dpkg                 1.20.10
ii  init-system-helpers  1.60
ii  lsb-base             11.1.0
ii  mime-support         3.66
ii  perl                 5.32.1-4+deb11u2
ii  procps               2:3.3.17-5


Versions of packages apache2 recommends:
ii  ssl-cert  1.1.0+nmu1


Versions of packages apache2 suggests:
pn  apache2-doc                                      
pn  apache2-suexec-pristine | apache2-suexec-custom  
pn  www-browser                                      


Versions of packages apache2-bin depends on:
ii  libapr1                  1.7.0-6+deb11u1
ii  libaprutil1              1.6.1-5
ii  libaprutil1-dbd-sqlite3  1.6.1-5
ii  libaprutil1-ldap         1.6.1-5
ii  libbrotli1               1.0.9-2+b2
ii  libc6                    2.31-13+deb11u3
ii  libcrypt1                1:4.4.18-4
ii  libcurl4                 7.74.0-1.3+deb11u1
ii  libjansson4              2.13.1-1.1
ii  libldap-2.4-2            2.4.57+dfsg-3+deb11u1
ii  liblua5.3-0              5.3.3-1.1+b1
ii  libnghttp2-14            1.43.0-1
ii  libpcre3                 2:8.39-13
ii  libssl1.1                1.1.1n-0+deb11u3
ii  libxml2                  2.9.10+dfsg-6.7+deb11u2
ii  perl                     5.32.1-4+deb11u2
ii  zlib1g                   1:1.2.11.dfsg-2+deb11u1


Versions of packages apache2-bin suggests:
pn  apache2-doc                                      
pn  apache2-suexec-pristine | apache2-suexec-custom  
pn  www-browser                                      


Versions of packages apache2 is related to:
ii  apache2      2.4.53-1~deb11u1
ii  apache2-bin  2.4.53-1~deb11u1


-- no debconf information

Bug#1014057: lintian man page: bad default for --color

[Jakub Wilk]

Package: lintian
Version: 2.115.1
Severity: minor

The Lintian man page says the default for --color is "never".
It is actually "auto" since Lintian 2.5.22:

+ [NT] Let --color default to "auto".

--
Jakub Wilk

Bug#1007002: Lintian breaks existing lintian-overrides due to added []

[Lucas Nussbaum]

On 29/06/22 at 15:49 +0200, Axel Beckert wrote:
> Correct, except that it happened for quite a while (7 months at least)
> and was (and maybe still is — see below) a continuous transition. It
> is present since at least 2.114.0 from November 2021. According to the
> git history, the implementation started shortly before the 2.114.0
> upload, but the bug report which requested this is actually from 2014:
> https://bugs.debian.org/743226
> 
> And yes, 2.115.0 (but not 2.115.1 or 2.115.2 from today) had more such
> changes as there were over 200 commits from Felix included which he
> did after 2.114.0, but which weren't uploaded since then.

Hi Axel,

Just a note that since the last version of lintian to migrate to testing
was 2.111 (which was also the last one to be backported to stable), some
of us might not have updated since 2.111 and might be hit by changes
that happened since then.

(I'm not arguing whether it should be kept or reverted, but I'm just
mentioning this as other disruptive changes might be discovered in the
coming days)

Lucas


signature.asc
Description: PGP signature

Bug#1014060: golang-github-masterminds-sprig FTBFS due to build-time test failure

[William 'jawn-smith' Wilson]

Package: golang-github-masterminds-sprig
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu kinetic ubuntu-patch

Dear Maintainer,

There is a build-time test using network access, which will not work
in Debian/Ubuntu package build environments.

In Ubuntu, the attached patch was applied to achieve the following:

 * Resolve FTBFS by skipping test that requires network access

Thanks for considering the patch.


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

Kernel: Linux 5.15.0-27-generic (SMP w/32 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru 
golang-github-masterminds-sprig-3.2.1/debian/patches/0001-skip-network-test.patch
 
golang-github-masterminds-sprig-3.2.1/debian/patches/0001-skip-network-test.patch
--- 
golang-github-masterminds-sprig-3.2.1/debian/patches/0001-skip-network-test.patch
   1969-12-31 18:00:00.0 -0600
+++ 
golang-github-masterminds-sprig-3.2.1/debian/patches/0001-skip-network-test.patch
   2022-06-29 10:04:49.0 -0500
@@ -0,0 +1,22 @@
+Description: Skip test that requires network access
+ There is a build-time test in this package that is failing
+ due to a lack of network access. Skip it to enable building
+ of the package
+Author: William 'jawn-smith' Wilson 
+Last-Update: 2022-06-29
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+Index: golang-github-masterminds-sprig-3.2.1/network_test.go
+===
+--- golang-github-masterminds-sprig-3.2.1.orig/network_test.go
 golang-github-masterminds-sprig-3.2.1/network_test.go
+@@ -8,6 +8,9 @@
+ )
+ 
+ func TestGetHostByName(t *testing.T) {
++  // This test requires network access, which does not
++  // work in package build environments
++  t.Skip()
+   tpl := `{{"www.google.com" | getHostByName}}`
+ 
+   resolvedIP, _ := runRaw(tpl, nil)
diff -Nru golang-github-masterminds-sprig-3.2.1/debian/patches/series 
golang-github-masterminds-sprig-3.2.1/debian/patches/series
--- golang-github-masterminds-sprig-3.2.1/debian/patches/series 1969-12-31 
18:00:00.0 -0600
+++ golang-github-masterminds-sprig-3.2.1/debian/patches/series 2022-06-29 
10:04:49.0 -0500
@@ -0,0 +1 @@
+0001-skip-network-test.patch

Bug#1014030: conmon: Hang with lots of terminal output

[Dan Nicholson]

Tags: patch

Attached is a debdiff that adds the upstream patch for bullseye.

--
Dan Nicholson  |  Endless OS Foundation
diff -Nru conmon-2.0.25+ds1/debian/changelog conmon-2.0.25+ds1/debian/changelog
--- conmon-2.0.25+ds1/debian/changelog	2021-07-14 11:46:07.0 -0600
+++ conmon-2.0.25+ds1/debian/changelog	2022-06-29 09:35:38.0 -0600
@@ -1,3 +1,10 @@
+conmon (2.0.25+ds1-1.1+deb11u1) bullseye; urgency=medium
+
+  * Backport upstream fix to not hang when forwarding container
+stdout/stderr with lots of output. (Closes: #1014030)
+
+ -- Dan Nicholson   Wed, 29 Jun 2022 09:35:38 -0600
+
 conmon (2.0.25+ds1-1.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru conmon-2.0.25+ds1/debian/patches/0002-conn_sock-do-not-fail-on-EAGAIN.patch conmon-2.0.25+ds1/debian/patches/0002-conn_sock-do-not-fail-on-EAGAIN.patch
--- conmon-2.0.25+ds1/debian/patches/0002-conn_sock-do-not-fail-on-EAGAIN.patch	1969-12-31 17:00:00.0 -0700
+++ conmon-2.0.25+ds1/debian/patches/0002-conn_sock-do-not-fail-on-EAGAIN.patch	2022-06-29 09:33:10.0 -0600
@@ -0,0 +1,37 @@
+From 2b873145a85a212f703c9c00db13717ab0204318 Mon Sep 17 00:00:00 2001
+From: Giuseppe Scrivano 
+Date: Tue, 2 Feb 2021 11:35:39 +0100
+Subject: [PATCH] conn_sock: do not fail on EAGAIN
+
+commit 6287bd884d9bf29e76ac877e0c7e6aad04bc24a4 introduced the
+regression.
+
+writes to the attached sockets must be blocking, otherwise the
+write_back_to_remote_consoles() shutdowns the socket when write fails
+with EAGAIN.
+
+I've verified the original issue fixed with commit 62887bd is not
+reintroduced with this patch.
+
+Closes: https://github.com/containers/conmon/issues/236
+
+Signed-off-by: Giuseppe Scrivano 
+---
+ src/conn_sock.c | 1 -
+ 1 file changed, 1 deletion(-)
+
+diff --git a/src/conn_sock.c b/src/conn_sock.c
+index e569113..02aee70 100644
+--- a/src/conn_sock.c
 b/src/conn_sock.c
+@@ -280,7 +280,6 @@ static gboolean attach_cb(int fd, G_GNUC_UNUSED GIOCondition condition, gpointer
+ 			pexit("Failed to allocate memory");
+ 		}
+ 		init_remote_sock(remote_sock, srcsock);
+-		g_unix_set_fd_nonblocking(new_fd, TRUE, NULL);
+ 		remote_sock->fd = new_fd;
+ 		g_unix_fd_add(remote_sock->fd, G_IO_IN | G_IO_HUP | G_IO_ERR, remote_sock_cb, remote_sock);
+ 		g_ptr_array_add(remote_sock->dest->readers, remote_sock);
+-- 
+2.30.2
+
diff -Nru conmon-2.0.25+ds1/debian/patches/series conmon-2.0.25+ds1/debian/patches/series
--- conmon-2.0.25+ds1/debian/patches/series	2021-07-14 11:46:07.0 -0600
+++ conmon-2.0.25+ds1/debian/patches/series	2022-06-29 09:33:10.0 -0600
@@ -1 +1,2 @@
 0001-Reset-OOM-score-back-to-0-for-container-runtime.patch
+0002-conn_sock-do-not-fail-on-EAGAIN.patch

Bug#1007002: Lintian breaks existing lintian-overrides due to added []

[Andreas Tille]

Hi Samuel and Axel,

Am Wed, Jun 29, 2022 at 04:10:49PM +0200 schrieb Samuel Thibault:
> Axel Beckert, le mer. 29 juin 2022 15:49:11 +0200, a ecrit:
> > > I consider these [] not helpful […] no visible advantage.

OK, thanks for making the advantages visible to me then.  I'll
start editing lintian-overrides then.

Kind regards

  Andreas. 

-- 
http://fam-tille.de

Bug#1013960: rapidjson: Rethink debian license GPL-2+

[Alexander Gerasiov]

On Tue, 28 Jun 2022 02:11:55 +0200
Bastian Germann  wrote:

> Source: rapidjson
> Severity: normal
> Version: 1.1.0+dfsg2-7
> 
> The debian/ directory including debian/patches is currently licensed
> under GPL-2+. As the patches are not exempt from that license the
> resulting binaries have to comply with GPL-2+ as well. This causes a
> problem for reverse dependencies that have incompatible licenses,
> e.g., monero includes files licensed under RSA-MD.
> 
> Would you please consider relicensing at least debian/patches?

I don't mind against this. At least we could license debian/patches
under expat license as most of upstream code is. (I should note, that
many patches were cherry-picked from upstream git.)

But there are some patches Rene Engelhard  added
previously, so we need him to approve license change too.

-- 
Best regards,
 Alexander Gerasiov

 Contacts:
 e-mail: a...@gerasiov.net  WWW: https://gerasiov.net  TG/Skype: gerasiov
 PGP fingerprint: 04B5 9D90 DF7C C2AB CD49  BAEA CA87 E9E8 2AAC 33F1

Bug#992409: Updated the upstream bug : not related to locale but to print formatting

[francois]

My mistake, sorry for the previous message, irrelevant and false. 
Please ignore

Bug#1014061: FTBFS on s390x: test suite failure when dumping a gif file

[Michael Biebl]

Source: exempi
Version: 2.6.1-2
Severity: serious
User: debian-s...@lists.debian.org
Forwarded: https://gitlab.freedesktop.org/libopenraw/exempi/-/issues/23
X-Debbugs-Cc: debian-s...@lists.debian.org


In the latest upload of exempi 2.6.1-2 I've enabled the test suite which
is now run during build.

This caused the build to fail on s390x (which is a release
architecture) and as it seems other BE architectures as well.

Starting program: /home/biebl/exempi/exempi-2.6.2/samples/source/dumpmainxmp 
samples/testfiles/BlueSquare.gif

Program received signal SIGABRT, Aborted.
0x03fffd7c1d60 in raise () from /lib/s390x-linux-gnu/libc.so.6
#0  0x03fffd7c1d60 in raise () from /lib/s390x-linux-gnu/libc.so.6
No symbol table info available.
#1  0x03fffd7a495c in abort () from /lib/s390x-linux-gnu/libc.so.6
No symbol table info available.
#2  0x03fffdbc9736 in __gnu_cxx::__verbose_terminate_handler() () from 
/usr/lib/s390x-linux-gnu/libstdc++.so.6
No symbol table info available.
#3  0x03fffdbc7026 in ?? () from /usr/lib/s390x-linux-gnu/libstdc++.so.6
No symbol table info available.
#4  0x03fffdbc70a0 in std::terminate() () from 
/usr/lib/s390x-linux-gnu/libstdc++.so.6
No symbol table info available.
#5  0x03fffdbc7392 in __cxa_throw () from 
/usr/lib/s390x-linux-gnu/libstdc++.so.6
No symbol table info available.
#6  0x02aa00024b1c in TXMPFiles, std::allocator > >::OpenFile (
this=this@entry=0x3ffee70, filePath=filePath@entry=0x3fff7ad 
"samples/testfiles/BlueSquare.gif",»
format=format@entry=538976288, openFlags=openFlags@entry=1) at 
../../public/include/client-glue/TXMPFiles.incl_cpp:313
wResult = {errMessage = 0x2aa001cb9b0 "Out of range seek operation", 
ptrResult = 0x2aa0013513c, floatResult = 0,»
  int64Result = 0, int32Result = 9}
ok = 
#7  0x02aa0001e90a in ProcessFile (fileName=0x3fff7ad 
"samples/testfiles/BlueSquare.gif") at DumpMainXMP.cpp:83
ok = 
buffer = "Dumping main XMP for 
samples/testfiles/BlueSquare.gif\000\217\314\000\000\002\252\000\033\371\240\000\000\002\252\000\a-\310\000\000\003\377\377\377\357X\000\000\003\377\377\377\357P\000\000\003\377\375\377W0\000\000\000\000\000\000\vg\000\000\002\252\000\033\367\300\000\000\003\377\375\372\257\230\000\000\002\252\000\a)\350\000\000\002\252\000\006S\210\000\000\003\377\377\377\356\250",
 '\000' , 
"\002\000\000\000\000\000\000\000\000\000\000\002\252\000\033\367\300\000\000\000\000MP2
 \000\000\002\252\000\034\256\260MP2 \000\006/$"...
xmpMeta = {
  _vptr.TXMPMeta = 0x2aa0016f4c8 , 
std::allocator > >+16>, xmpRef = 0x2aa001caf00}
xmpFile = {
  _vptr.TXMPFiles = 0x2aa0016f508 , 
std::allocator > >+16>, xmpFilesRef = 0x2aa001cb080}
format = 4294962648
openFlags = 1023
handlerFlags = 4256987410
xmpPacket = {offset = -1, length = -1, padSize = 0, charForm = 0 
'\000', writeable = 0 '\000', hasWrapper = 0 '\000',»
  pad = 0 '\000'}
offset = 
length = 
#8  0x02aa0001c258 in main (argc=, argv=) at 
DumpMainXMP.cpp:127
i = 
options = 2


The build logs on s390x show several warnings which might be related.

Help from porters is appreciated.


Regards,
Michael



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

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

Bug#1014062: Failure to load kernel modules at boot time

[Eduardo Casais]

Package: system2
Version: 247.3-7

Dear Maintainers,

At boot time, linux produces a series of error messages stating that a 
kernel module cannot be loaded.


Inspecting the output of journalctl, I find the following lines:

Jun 29 16:53:25 AREPPIM001 systemd-modules-load[218]: Failed to insert 
module 'firewire_sbp2': Key was rejected by service
Jun 29 16:53:25 AREPPIM001 systemd[1]: systemd-modules-load.service: 
Main process exited, code=exited, status=1/FAILURE
Jun 29 16:53:25 AREPPIM001 systemd[1]: systemd-modules-load.service: 
Failed with result 'exit-code'.

Jun 29 16:53:25 AREPPIM001 systemd[1]: Failed to start Load Kernel Modules.

Jun 29 16:53:30 AREPPIM001 systemd-modules-load[442]: Failed to insert 
module 'firewire_sbp2': Key was rejected by service
Jun 29 16:53:30 AREPPIM001 systemd[1]: systemd-modules-load.service: 
Main process exited, code=exited, status=1/FAILURE
Jun 29 16:53:30 AREPPIM001 systemd[1]: systemd-modules-load.service: 
Failed with result 'exit-code'.

Jun 29 16:53:30 AREPPIM001 systemd[1]: Failed to start Load Kernel Modules.

Jun 29 16:53:35 AREPPIM001 systemd-modules-load[458]: Failed to insert 
module 'firewire_sbp2': Key was rejected by service
Jun 29 16:53:35 AREPPIM001 systemd-fsck[456]: /dev/sda7: clean, 
10088/720896 files, 376406/2880512 blocks
Jun 29 16:53:35 AREPPIM001 systemd[1]: systemd-modules-load.service: 
Main process exited, code=exited, status=1/FAILURE
Jun 29 16:53:35 AREPPIM001 systemd[1]: systemd-modules-load.service: 
Failed with result 'exit-code'.

Jun 29 16:53:35 AREPPIM001 systemd[1]: Failed to start Load Kernel Modules.

All three attempts at loading the module firewire_sbp2 take place during 
the same boot sequence.


The error was definitely introduced by Bullseye / Debian 11, since the 
same machine under Buster / Debian 10 did not exhibit this behaviour:


Jun 21 16:06:42 AREPPIM001 kernel: firewire_ohci :02:01.1: added 
OHCI v1.10 device as card 0, 4 IR + 8 IT contexts, quirks 0x2
Jun 21 16:06:42 AREPPIM001 kernel: firewire_core :02:01.1: created 
device fw0: GUID 314fc000300d2430, S400
Jun 21 16:06:42 AREPPIM001 systemd-modules-load[204]: Inserted module 
'firewire_sbp2'


The machine is running Linux 5.10.0-15-686-pae #1 SMP Debian 5.10.120-1 
(2022-06-09) i686 GNU/Linux.


Sincerely

Eduardo Casais

Bug#1012524: libass: PGP signature and i386 assembly

[Oneric]

Control: tag 1012524 + patch - pending

A patch to match against any authorsied keys is attached.
Without this change uscan will error out when encoutering
future releases not signed with the current key — even if
the key used is authorised for release signatures.

The contents of signing-key.asc can be inspected
and verified with `gpg --list-packets`. Note that
not for all keys, signing and primary key are identical.
MAINTAINERS lists and the output of verification commands
typically shows the former, but both appear in gpg -k
and gpg --list-packets.

Alternatively, the new content can be reproduced by following these steps
(assuming gpg does not fetch additional signatures for the imported 
keys from its default keyring or so. If unsure, temporarily rename ~/.gnupg):

  alias gpg_t='command gpg --no-default-keyring --keyring /tmp/tmp.keys'
  curl https://github.com/astiob.gpg | gpg_t --import -
  curl https://github.com/TheOneric.gpg | gpg_t --import -
  curl https://github.com/rcombs.gpg | gpg_t --import -
  gpg_t --export --export-options export-minimal --armor > 
debian/upstream/signing-key.asc
  # To verify which keys are included
  gpg --list-packets debian/upstream/signing-key.asc

The export options are copied from uscan’s man page.


Cheers

Oneric
From ee09c54c1728e1757608b5160edf66b9a2109245 Mon Sep 17 00:00:00 2001
From: Oneric 
Date: Wed, 29 Jun 2022 17:05:40 +0200
Subject: [PATCH] Add alternate signing keys

Upstream's release note for 0.16.0 announced that the release may
be signed with other keys in the future. A list of authorised keys was
included in the MAINTAINERS file of (signed) tarball.
Additionally, the git commit adding this file is also signed by the
same key as the release tarball and future changes are promised to be
signed with an pre-existing key.
Without adding the additional authorised keys, uscan will error out
when encoutering future releases not signed with the current key.

To verify which keys are in signing-key.asc, `gpg --list-packets` can
be used and the output checked against the IDs listed in MAINTAINERS.
---
 debian/upstream/signing-key.asc | 137 +++-
 1 file changed, 133 insertions(+), 4 deletions(-)

diff --git a/debian/upstream/signing-key.asc b/debian/upstream/signing-key.asc
index 77c8d9f..c611b07 100644
--- a/debian/upstream/signing-key.asc
+++ b/debian/upstream/signing-key.asc
@@ -45,8 +45,137 @@ OtUMRG8I/EfGyhYH+PN2cHa9VGIss//OJWTpCfnAyD3g4qVRcYAnbtK2jVVe9wJS
 6zDhMMUJ9QHjMLRFi06f/MHxuES34UhFTmRx1oWv+OUlYCBFWTblI8OXSbgTjsJy
 i1zbNywyGrGjUVv0GrrWq7L0b/bukqBObhyeWpl2kED2+/llZb4rn93GB4VSqvkr
 jkGWoF8NU7ZhwpVEB3M0j3Z8GsctvQ6NIpFqGf3uNQsk1qngUnMqNZE3zHCnt8Do
-dUi2f9uJDlzXNQ5LAgj2pVnqreUwqIh4BBgRCAAJBQJNlOPMAhsMACEJEIB50Ywh
-qqr/FiEEVFjDEAZx8lKw9MdwgHnRjCGqqv+9QgEAoTdOzovu5crCzIbwpBw62IkC
-oe9yiIkrDfNxun95uWwA/jP6yvA884C98+/WFIl4JPtxpljOYlbtyab0zKhhaZwf
-=EtRt
+dUi2f9uJDlzXNQ5LAgj2pVnqreUwqIhhBBgRCAAJBQJNlOPMAhsMAAoJEIB50Ywh
+qqr/vUIBAKE3Ts6L7uXKwsyG8KQcOtiJAqHvcoiJKw3zcbp/eblsAP4z+srwPPOA
+vfPv1hSJeCT7caZYzmJW7cmm9MyoYWmcH5kCDQRhNOowARAA3MqpsowLf42S6qXe
+h1xrUHNTRMb1v3nEP29uGWx9SjJBB2TKw0U7+nTSQwInU0zHTaiAmbgG3v2sG6sw
+bI28iBPkb9hpF13zsFzlrb8ZSrqKRGyQ3J/O5w8/kcIn+OYeQCE8Up5nwkwWYnl0
+iyEJuoTZyKshm0HaDazxuGvlisQa8FXnT9V/6D99HJQEzVvC5Sghvh8iROW3+J3s
+geCVjGsFYtoM/xKneKUV9g6MD1tELlWTjPayzmbbzQzKGXk27hN1u88I2lY23ohQ
+6V1+jy5jZoJfyQnUFqIx/hGPuHg+frdhYFqD7IVmAaGFRuKJyqG3Re1UYTvTLSle
+kJXuLlfbeE3hTqec3/KLC1EaB5hB/rnGCGVP3muY/nJu3oF+hLheN6OEBH5WY7P0
+TKGINEGSOEJkW/mvsVnPJOCMzkDWvGpkLtmVZqjoa3jaVoQ17JCMAhKQlp038wC4
+/phEDte407EMD+UUVvians6baqSl7J9pkS9n1iPqF/BMc/x7lW5VeSFhVZEDq04T
+uWIzkkdqZERFt4MO71dJG4zf05adFZelz+hKLGr9nHL+vG2rYTj41j1BEMS6MvRH
+DoWwHzRG53SiulGDLVqWvn68YJul/5aByED+dfu6Il0cxFW3oE+C1e7tmdDGWgr8
+1lJtYudt8Q7WlF1/s7K3uNzOsksAEQEAAbQZT25lcmljIDxvbmVyaWNAb25lcmlj
+LmRlPokCVAQTAQgAPhYhBF7mPypxvxMs/jVn4d/+YV8oJMcgBQJhNOowAhsDBQkN
+KGiABQsJCAcCBhUKCQgLAgQWAgMBAh4BAheAAAoJEN/+YV8oJMcgPMAP/RMGUKjx
+MIeiyf0vLnvGpTSdVMX9jdm8A7MmOex44U/AB0UfpQEoYpLX59EPvxsMBhQLMQmA
+zILF1GGRncfLNetRbxaKrXbNSplC2FMFbVnDneX9lzjXsw8MXxT8K0P8D9NDgoUb
+AMn6o1MXyye9TjtgCKOEqXxSUAU0z8sh9ruEt0GKevfhU5OlExxaRRx6E1SSsFHp
+To2qyxRj8uF+vFuKppBlHuhP8sbWRiANgiUdAHGbyLbTJhj9qX6BITt5C9vPqExo
+uJUfUtnQs3C6P1wfYKobEPKodY52eBemE1w4hDAZivN+5AEUsApaYcxwzks4Dr9A
+vBfLDSKGWG+yPobS/LWqoDAOnjGzmEkjVkPwIElBEhitDZdh3WpYFYU848AEpVG+
+m8tic3vp5BleBxjH2WDDVTsHsOaL3loJ3YAluFWHuAp/IKNMO5tnU4x8FbCv1hoe
+H5s/m80aThGcGwJOwN9YGdUIG9KtqufghVfiBvpn2q3XujpKmN52EopauQw3sUda
+0pD2Q7BnXH30ggihOPVuTF64TkLOe4nXLbsrKu0PQfHOZMSbLRYO36/rZD4KRMBF
+RW4Ex7w9ijCjjgPE82Bvrf/T8n5ije+2SqbYl/WMkZd8e6H3wvP9VlbBKE4wDKNY
+U5tjB97pY3fyiCv9/P+kNcUl4EWcDHDqvBQEuQINBGE06sABEADcZCBCxKKF7yMk
+qQjZrZiHOknhUoUOV6rc7CYBji+30MZ9s2ml522OhH5eCsplM1a6Ya04OJBUDJzF
+aAj6zhgMnkJLXv4VIvJvCGbPYDsRm1eRpx7xyXN2LWWSv6gJ2Hl0yRUp5UjSsrjD
+Ym4Om326MbhvqDzKktWB8XDgftzMd8tOkblJl5eLVHtMp/3SPoyRw+NGrf3+m029
+aYovxgcGIDdWZ1n62k5MQ+G4IxYs5SUSPKoYY//h2SrTtOE6eXiBatPnjh8klq1U
+5UOg/rAbzWXCO2gksXDFkEJ1DfkZvdXMBWqfWum8qlHODMuf1cqPdcoMF5EwhV74

Bug#1013264: [Pkg-javascript-devel] Bug#1013264: node-got: CVE-2022-33987

[Yadd]

On 20/06/2022 13:12, Moritz Mühlenhoff wrote:

Source: node-got
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerability was published for node-got.

CVE-2022-33987[0]:
| The got package before 12.1.0 for Node.js allows a redirect to a UNIX
| socket.

https://github.com/sindresorhus/got/pull/2047

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2022-33987
 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-33987

Please adjust the affected versions in the BTS as needed.


Hi,

sorry for the delay, fixed in upstream and Bullseye-PU sent

Cheers,
Yadd

Bug#1013425: ITP: wnpp -- Python Airspeed is a powerful templating engine compatible with Velocity for Java

[Moessbauer, Felix]

Dear maintainers,

the initial packaging for python3-airspeed is now ready at [1] and has a green 
salsa CI.
It should be ready for a review.

@Stephan: Would you like to sponsor this package as well?

[1] https://salsa.debian.org/python-team/packages/airspeed

Best regards,
Felix Moessbauer
Siemens AG

Bug#1014059: ITP: coq-math-classes -- Abstract interfaces for mathematical structures for Coq

[Julien Puydt]

Package: wnpp
Severity: wishlist
Owner: Julien Puydt 
X-Debbugs-Cc: Debian OCaml Maintainers , 
jpu...@debian.org

* Package name: coq-math-classes
  Version : 8.15.0
  Upstream Author : Eelis van der Weegen, Bas Spitters, Robbert Krebbers
* URL : https://github.com/coq-community/math-classes
* License : Expat
  Programming Lang: Coq
  Description : Abstract interfaces for mathematical structures for Coq
 This library provides abstract interfaces for mathematical
 structures for Coq, such as:
 - algebraic hierarchy (groups, rings, fields, ...)
 - relations, orders, ...
 - Categories, functors, universal algebra, ...
 - Numbers: N, Z, Q, ...
 - Operations (shift, power, abs, ...).
 .
 Coq is a proof assistant for higher-order logic.

I plan to maintain it within the Debian OCaml Maintainers team, along with the
rest of the Coq-related packages.

Cheers,

J.Puydt

Bug#1014064: libqpid-proton-cpp12-dev: Missing CMake config files

[Sylvain Joubert]

Package: libqpid-proton-cpp12-dev
Version: 0.37.0-1+b1
Severity: normal
X-Debbugs-Cc: joubert...@gmail.com

Dear Maintainer,

While the pkg-config *.pc files are provided by this package, the relevant
CMake config files are not.
This make the library impossible to use in a standard CMake way (using
find_package)

I believe the same issue also applies to the libqpid-proton11-dev package

The missing files should be in /usr/lib/cmake/ProtonCpp/ and in
/usr/lib/cmake/Proton/ for libqpid-proton11-dev

Sylvain.


-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (990, 'testing'), (800, 'stable-updates'), (800, 'stable'), (700, 
'unstable'), (90, 'experimental')
Architecture: amd64 (x86_64)

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

Versions of packages libqpid-proton-cpp12-dev depends on:
ii  libqpid-proton-cpp12  0.37.0-1+b1
ii  libqpid-proton11-dev  0.37.0-1+b1

libqpid-proton-cpp12-dev recommends no packages.

libqpid-proton-cpp12-dev suggests no packages.

-- no debconf information

Bug#1014065: i915: Blank screen on resume from suspend to RAM on Intel Iris Xe i915

[Daniel Barta]

Package: src:linux
Version: 5.18.5-1
Severity: normal
File: i915




-- Package-specific info:
** Version:
Linux version 5.18.0-2-amd64 (debian-ker...@lists.debian.org) (gcc-11 (Debian 
11.3.0-3) 11.3.0, GNU ld (GNU Binutils for Debian) 2.38.50.20220615) #1 SMP 
PREEMPT_DYNAMIC Debian 5.18.5-1 (2022-06-16)

** Command line:
BOOT_IMAGE=/vmlinuz-5.18.0-2-amd64 root=/dev/mapper/debian_vg-debian_root ro 
rootflags=subvol=@rootfs net.ifnames=0 biosdevname=0 splash quiet

** Tainted: UW (576)
 * taint requested by userspace application
 * kernel issued warning

** Kernel log:
[ 2301.468336] i915 :00:02.0: [drm] *ERROR* Failed to read DPCD register 
0x92
[ 2304.801568] i915 :00:02.0: [drm] *ERROR* Failed to read DPCD register 
0x92
[ 2307.468246] i915 :00:02.0: [drm] *ERROR* Failed to read DPCD register 
0x92
[ 2312.416912] i915 :00:02.0: [drm] *ERROR* Failed to write source OUI
[ 2319.139810] i915 :00:02.0: [drm] *ERROR* [ENCODER:307:DDI A/PHY A][DPRX] 
Failed to enable link training
[ 2321.098775] i915 :00:02.0: [drm] *ERROR* Failed to read DPCD register 
0x92
[ 2324.431984] i915 :00:02.0: [drm] *ERROR* Failed to read DPCD register 
0x92
[ 2327.098973] i915 :00:02.0: [drm] *ERROR* Failed to read DPCD register 
0x92
[ 2332.044406] i915 :00:02.0: [drm] *ERROR* Failed to write source OUI
[ 2339.078966] i915 :00:02.0: [drm] *ERROR* [ENCODER:307:DDI A/PHY A][DPRX] 
Failed to enable link training
[ 2341.392741] i915 :00:02.0: [drm] *ERROR* Failed to read DPCD register 
0x92
[ 2344.059327] i915 :00:02.0: [drm] *ERROR* Failed to read DPCD register 
0x92
[ 2346.726030] i915 :00:02.0: [drm] *ERROR* Failed to read DPCD register 
0x92
[ 2351.650385] i915 :00:02.0: [drm] *ERROR* Failed to write source OUI
[ 2358.516906] i915 :00:02.0: [drm] *ERROR* [ENCODER:307:DDI A/PHY A][DPRX] 
Failed to enable link training
[ 2360.330289] i915 :00:02.0: [drm] *ERROR* Failed to read DPCD register 
0x92
[ 2363.663623] i915 :00:02.0: [drm] *ERROR* Failed to read DPCD register 
0x92
[ 2366.330695] i915 :00:02.0: [drm] *ERROR* Failed to read DPCD register 
0x92
[ 2371.420772] i915 :00:02.0: [drm] *ERROR* Failed to write source OUI
[ 2378.515903] i915 :00:02.0: [drm] *ERROR* [ENCODER:307:DDI A/PHY A][DPRX] 
Failed to enable link training
[ 2380.621812] i915 :00:02.0: [drm] *ERROR* Failed to read DPCD register 
0x92
[ 2383.288376] i915 :00:02.0: [drm] *ERROR* Failed to read DPCD register 
0x92
[ 2385.955030] i915 :00:02.0: [drm] *ERROR* Failed to read DPCD register 
0x92
[ 2390.881154] i915 :00:02.0: [drm] *ERROR* Failed to write source OUI
[ 2397.872907] i915 :00:02.0: [drm] *ERROR* [ENCODER:307:DDI A/PHY A][DPRX] 
Failed to enable link training
[ 2400.228249] i915 :00:02.0: [drm] *ERROR* Failed to read DPCD register 
0x92
[ 2402.894802] i915 :00:02.0: [drm] *ERROR* Failed to read DPCD register 
0x92
[ 2405.561459] i915 :00:02.0: [drm] *ERROR* Failed to read DPCD register 
0x92
[ 2410.292321] i915 :00:02.0: [drm] *ERROR* Failed to write source OUI
[ 2416.981272] i915 :00:02.0: [drm] *ERROR* [ENCODER:307:DDI A/PHY A][DPRX] 
Failed to enable link training
[ 2418.981803] i915 :00:02.0: [drm] *ERROR* Failed to read DPCD register 
0x92
[ 2422.315095] i915 :00:02.0: [drm] *ERROR* Failed to read DPCD register 
0x92
[ 2424.981741] i915 :00:02.0: [drm] *ERROR* Failed to read DPCD register 
0x92
[ 2429.923831] i915 :00:02.0: [drm] *ERROR* Failed to write source OUI
[ 2437.040902] i915 :00:02.0: [drm] *ERROR* [ENCODER:307:DDI A/PHY A][DPRX] 
Failed to enable link training
[ 2439.271490] i915 :00:02.0: [drm] *ERROR* Failed to read DPCD register 
0x92
[ 2441.938022] i915 :00:02.0: [drm] *ERROR* Failed to read DPCD register 
0x92
[ 2444.604655] i915 :00:02.0: [drm] *ERROR* Failed to read DPCD register 
0x92
[ 2449.529213] i915 :00:02.0: [drm] *ERROR* Failed to write source OUI
[ 2456.312453] i915 :00:02.0: [drm] *ERROR* [ENCODER:307:DDI A/PHY A][DPRX] 
Failed to enable link training
[ 2458.208989] i915 :00:02.0: [drm] *ERROR* Failed to read DPCD register 
0x92
[ 2461.542393] i915 :00:02.0: [drm] *ERROR* Failed to read DPCD register 
0x92
[ 2464.209041] i915 :00:02.0: [drm] *ERROR* Failed to read DPCD register 
0x92
[ 2469.199262] i915 :00:02.0: [drm] *ERROR* Failed to write source OUI
[ 2476.273890] i915 :00:02.0: [drm] *ERROR* [ENCODER:307:DDI A/PHY A][DPRX] 
Failed to enable link training
[ 2478.504395] i915 :00:02.0: [drm] *ERROR* Failed to read DPCD register 
0x92
[ 2481.170945] i915 :00:02.0: [drm] *ERROR* Failed to read DPCD register 
0x92
[ 2483.837685] i915 :00:02.0: [drm] *ERROR* Failed to read DPCD register 
0x92
[ 2488.763900] i915 :00:02.0: [drm] *ERROR* Failed to write source OUI
[ 2495.705784] i915 :00:02.0: [drm] *ERROR* [ENCODER:307:DDI A/PHY A][DPRX] 
Failed to enable link training
[ 2497.456781] i915 :00:02.0: [drm] *ERROR* Failed to 

Bug#1010073: Bug 1010073: kernel 4.19: nvme read overhead sometimes, system hangs

[Андрій Василишин]

ср, 29 черв. 2022 р. о 16:32 Ben Hutchings  пише:

> On Thu, 9 Jun 2022 15:34:17 Андрій Василишин 
> wrote:
> > Because it is the latest kernel which supports aufs.
> > Problem gone when I change to default  parameters NIC Mellanox
> Technologies
> > MT28908 Family [ConnectX-6]
> > ethtool -C enp161s0f0np0 rx-usecs 8 rx-frames 128 tx-usecs 8 tx-frames
> 128
> [...]
>
> So this seems to be a problem with the out-of-tree network driver you
> are using.  You should ask Mellanox for support, as there's nothing we
> can do about that.
>
> Ben.
>
> --
> Ben Hutchings
> Reality is just a crutch for people who can't handle science fiction.
>

Yes and no.
Problem reappeared.  Helped disable sendfile in nginx

Bug#1013670: transition: srt

[Sebastian Ramacher]

Control: tags -1 confirmed

On 2022-06-25 13:46:45 +0200, Sebastian Ramacher wrote:
> Control: forwarded -1 
> https://release.debian.org/transitions/html/auto-srt.html
> 
> On 2022-06-24 17:32:43, Florian Ernst wrote:
> > Package: release.debian.org
> > Severity: normal
> > User: release.debian@packages.debian.org
> > Usertags: transition
> > 
> > Dear Release Team,
> > 
> > please grant a transition slot for the srt transition.
> > 
> > Upstream has changed the soname from 1.4 to 1.5, and the srt packaging
> > has been adjusted to reflect this. The following source package have
> > been build-depending on srt:
> > 
> > ffmpeg
> > gst-plugins-bad1.0
> > nageru
> > vlc
> > 
> > I have successfully rebuilt all of them on amd64 against srt as present
> > in experimental, where srt itself has successfully built on all release
> > architectures..
> 
> Let's wait until ffmpeg migrated and then we should be good to go ahead
> with this one.

Please go ahead

Cheers

> 
> Cheers
> 
> > 
> > The information on
> > https://release.debian.org/transitions/html/auto-srt.html looks correct
> > to me.
> > 
> > Ben file:
> > 
> > title = "srt";
> > is_affected = .depends ~ "libsrt1.4-gnutls" | .depends ~ 
> > "libsrt1.4-openssl" | .depends ~ "libsrt1.5-gnutls" | .depends ~ 
> > "libsrt1.5-openssl";
> > is_good = .depends ~ "libsrt1.5-gnutls" | .depends ~ "libsrt1.5-openssl";
> > is_bad = .depends ~ "libsrt1.4-gnutls" | .depends ~ "libsrt1.4-openssl";
> > 
> > Cheers,
> > Flo
> 
> 
> 
> -- 
> Sebastian Ramacher
> 

-- 
Sebastian Ramacher

Bug#1014074: colmap: Build-Depends should include libmetis-dev

[Gürkan Myczko]

Hi Dima

Thanks for the hint, will try to get this fixed asap. (~ 2 weeks), feel free to 
add yourself to uploaders if you need it fixed earlier.

Best

Gürkan


> On 29 Jun 2022, at 22:33, Dima Kogan  wrote:
> 
> Package: colmap
> Version: 3.7-2+b1
> Severity: normal
> X-Debbugs-Cc: none, Dima Kogan 
> 
> I currently libmetis-dev is not included in the Build-Depends, so the
> package build says this:
> 
>  -- Could NOT find METIS (missing: METIS_INCLUDE_DIR METIS_LIBRARY) 
> 
> This is a warning, not an error, so the build still completes
> successfully. I don't know what colmap does internally when METIS isn't
> available. Presumably it has some other variable permutation strategy,
> but if it doesn't, METIS would speed up the bundle-adjustment solves by
> a lot. We should make this library available to the build.
> 
> Thanks for maintaining colmap!
> 
> 
> -- System Information:
> Debian Release: bookworm/sid
>  APT prefers unstable
>  APT policy: (800, 'unstable'), (700, 'testing'), (500, 'unstable-debug'), 
> (500, 'stable')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386, armhf
> 
> Kernel: Linux 5.16.0-5-amd64 (SMP w/4 CPU threads; PREEMPT)
> Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
> Locale: LANG=en_US.utf-8, LC_CTYPE=en_US.utf-8 (charmap=UTF-8) (ignored: 
> LC_ALL set to en_US.utf-8), LANGUAGE=en_US.utf-8
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> 
> Versions of packages colmap depends on:
> ii  libc6  2.33-7
> ii  libceres2  2.1.0+really2.0.0+dfsg1-2
> ii  libfreeimage3  3.18.0+ds2-7
> ii  libgcc-s1  12.1.0-4
> ii  libgl1 1.4.0-1
> ii  libglew2.2 2.2.0-4
> ii  libgomp1   12.1.0-4
> ii  libgoogle-glog0v6  0.6.0-1
> ii  libqt5core5a   5.15.4+dfsg-3
> ii  libqt5gui5 5.15.4+dfsg-3
> ii  libqt5widgets5 5.15.4+dfsg-3
> ii  libstdc++6 12.1.0-4
> 
> colmap recommends no packages.
> 
> colmap suggests no packages.
> 
> -- no debconf information

Bug#942400: NMU for gjiten: Please stop recommending gconf2

[Jeremy Bicha]

I have prepared a non-maintainer uploader for gjiten and uploaded it
to the DELAYED/10 queue. Please let me know if I should speed up or
slow down the upload.

I am attaching the change I made. It's more minimal than the original
proposed patch since the new release doesn't use gconf any more.

Thank you,
Jeremy Bicha
From 8b8236cbc072cf1917d132637aeb596d2f3b7617 Mon Sep 17 00:00:00 2001
From: Jeremy Bicha 
Date: Wed, 29 Jun 2022 16:43:49 -0400
Subject: [PATCH] debian/control: Drop unused gconf2 Recommends

Closes: #942400
---
 debian/changelog | 7 +++
 debian/control   | 2 +-
 2 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/debian/changelog b/debian/changelog
index 6b5987c..34553f8 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+gjiten (3.1-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload
+  * debian/control: Drop unused gconf2 Recommends (Closes: #942400)
+
+ -- Jeremy Bicha   Wed, 29 Jun 2022 16:43:25 -0400
+
 gjiten (3.1-1) unstable; urgency=medium
 
   * New upstream release.
diff --git a/debian/control b/debian/control
index 235773e..c26d47b 100644
--- a/debian/control
+++ b/debian/control
@@ -16,7 +16,7 @@ Package: gjiten
 Architecture: any
 Depends: ${shlibs:Depends}, ${misc:Depends}, kanjidic, edict
 Suggests: enamdict
-Recommends: fonts-ipafont-mincho | fonts-japanese-mincho, gconf2
+Recommends: fonts-ipafont-mincho | fonts-japanese-mincho
 Description: Japanese dictionary for GNOME
  Gjiten is a Japanese dictionary for GNOME with advanced word and kanji lookup
  features. Requires dictionary files (edict, kanjidic) to function.

Bug#1013879: bullseye-pu: package nvidia-graphics-drivers/470.129.06-5~deb11u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Sun, 2022-06-26 at 14:53 +0200, Andreas Beckmann wrote:
> in oder to fix some more CVEs in the proprietary NVIDIA driver, let's
> update the version in stable to a new upstream release. This is a
> rebuild of the package from sid with no further changes.
> 
> The biggest part of the diff are changes to the set of supported PCI
> IDs
> - according to the README from the 510 driver (in experimental), the
> 470 driver series still supports more legacy gpu models. (Looks like
> NVIDIA had planned to remove support for Kepler nodebook GPUs at some
> point, but that does not seem to have happened, only the 470 README
> "lost" any information about these cards at some point.)
> 

Please go ahead.

Regards,

Adam

Bug#1013880: bullseye-pu: package nvidia-graphics-drivers-tesla-470/470.129.06-5~deb11u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Sun, 2022-06-26 at 15:21 +0200, Andreas Beckmann wrote:
> Let's update nvidia-graphics-drivers-tesla-470 in stable (which is
> being
> introduced via -pu) to a new upstream release to fix some more CVEs.
> 

Please go ahead.

Regards,

Adam

Bug#1012331: buster-pu: package nvidia-graphics-drivers-tesla-450/450.191.01-1~deb11u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Sat, 2022-06-04 at 14:40 +0200, Andreas Beckmann wrote:
> Let's update the tesla-450 driver to the latest upstream release in
> order to fix some CVEs.
> 
> There are only minimal packaging changes this time because they were
> mostly included in the previous stable update ... ;-)
> 
> There are new patches fixing the module build for arm64 and ppc64el,
> these problems were found by the recently enabled dkms autopkgtests.
> 

Please go ahead.

Regards,

Adam

Bug#1012322: bullseye-pu: package nvidia-graphics-drivers-tesla-460/460.106.00-5~deb11u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Sat, 2022-06-04 at 07:23 +0200, Andreas Beckmann wrote:
> now that stable(-pu) has nvidia-graphics-drivers-tesla-470, we can
> turn
> nvidia-graphics-drivers-tesla-460 into transitional packages to aid
> switching to it.
> 

Please go ahead.

Regards,

Adam

Bug#1012323: bullseye-pu: package nvidia-graphics-drivers-tesla-418/418.226.00-5~deb11u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Sat, 2022-06-04 at 07:47 +0200, Andreas Beckmann wrote:
> With the tesla-418 driver series having reached EoL upstream, I'd
> like
> to update stable to the latest release from that branch along with
> all
> packaging fixes and add a NEWS entry for the EoL state. (As we had
> done
> with other EoL driver series in the past.)
> 
> This is a rebuild of the package from sid.
> 
> The packaging updates have reached stable already in the tesla-450,
> tesla-470, legacy-390xx and nvidia-graphics-drivers updates.
> 
> The corresponding request for buster is #1009652 (for
> nvidia-graphics-drivers).
> 

Please go ahead.

Regards,

Adam

Bug#1013755: bullseye-pu: package ganeti/3.0.2-1~deb11u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Sat, 2022-06-25 at 15:25 +0300, Apollon Oikonomopoulos wrote:
> I would like to update Ganeti to the current upstream bugfix version
> (3.0.2) - including all Debian packaging fixes currently in unstable
> - and I seek your approval.
> 
> 3.0.2 was released a while back[1] as a bugfix-only release. Due to
> my involvement upstream, I had full oversight of the release process
> and I  can confirm it solves important issues, the vast majority of
> which affect Bullseye, while it does not introduce any breaking
> changes in behavior.  
> Note that every commit since v3.0 has been tested against Debian
> Stable and Testing upstream using an automated CI/CD pipeline. I
> believe bumping to 3.0.2 is much safer and cleaner than cherry-
> picking at least a dozen of commits as patches on top of 3.0.1.
> 
> Apart from upstream fixes, this p-u also includes fixes for Debian
> bugs #993559 and #140 affecting Debian packaging, as well as the
> removal of an unnecessary dependency on bridge-utils. Note that I
> might revert the latter for the stable update to avoid breaking any
> custom scripts (e.g. hooks) that still rely on brctl mid-release.

Hmm, that does sound like it might be safest.

Please go ahead; thanks.

Regards,

Adam

Bug#1007714: bullseye-pu: package openssh/1:8.4p1-5+deb11u1

[Adam D. Barratt]

Hi Colin,

On Fri, 2022-03-18 at 08:43 +0100, Cyril Brulebois wrote:
> Adam D. Barratt  (2022-03-17):
> > As openssh builds a udeb, I'm CCing KiBi and tagging the bug
> > accordingly.
> 
> Making sure upgrades have a chance to work properly seems more
> important
> than any possible regressions at install time, for those deploying
> over
> SSH, so no objections at all.

Just a quick reminder on this, as the window for getting changes into
11.4 closes over the coming weekend.

Regards,

Adam

Bug#968467:

[Nilson Silva]

Hello Bastian!

> That is just not true:
https://tracker.debian.org/news/1335154/accepted-numba-0551-1-source-into-unstable/

> As I said: Debian has 0.55.1.

Of course, today it is already updated. At the time of packaging, I had these 
questions that I asked.

But the important thing at this point is that I just uploaded the package.

Thank you in advance for your help

By the way, could you sponsor Bastian?



Nilson F. Silva


De: Bastian Germann 
Enviado: quarta-feira, 29 de junho de 2022 15:49
Para: 968...@bugs.debian.org <968...@bugs.debian.org>
Assunto: Bug#968467:

Control: retitle -1 ITP: librosa -- module for audio and music processing

On Mon, 27 Jun 2022 13:42:38 + Nilson Silva  
wrote:
> I already made the package However it is depending on the latest version of 
> "numba" which is still in progress!

setup.py has

install_requires:
numba >= 0.45.1

options.extras_require:
docs =
numba < 0.50

Debian has 0.55.1. Are you sure with your claim? Maybe this needs an older 
version...

Bug#1014078: RFS: librosa/0.9.2-1 [ITP] -- Python package for music and audio analysis

[Nilson Silva]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

 * Package name: librosa
   Version : 0.9.2-1
   Upstream Author : https://github.com/librosa/librosa/issues
 * URL : https://github.com/librosa/librosa
 * License : ISC
 * Vcs : https://salsa.debian.org/debian/librosa
   Section : python

The source builds the following binary packages:

  python3-librosa - Python package for music and audio analysis

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/libr/librosa/librosa_0.9.2-1.dsc
  salsahttps://salsa.debian.org/nilsonfsilva/librosa

Changes for the initial release:

 librosa (0.9.2-1) experimental; urgency=medium
 .
   * Initial release. (Closes: #968467)

Regards,
--
  Josenilson Ferreira da SIlva





Nilson F. Silva

81-3036-0200

81-991616348

81-98546-9553