Bug#1016750: sbcl breaks cl-ironclad autopkgtest on armhf: Heap exhausted, game over.

[Paul Gevers]

Hi Sean,

On 09-08-2022 05:08, Sean Whitton wrote:

It looks like Lisp just ran out of memory.


Yes, but it does so systematically.


Indeed, I can't see this
failure on debci.debian.org at present,


Huh? Did you check 
https://ci.debian.net/packages/c/cl-ironclad/testing/armhf/ or 
https://ci.debian.net/packages/c/cl-ironclad/testing/armel/ You'll see 
there that cl-ironclad was retried with sbcl about 11 + 10 times and 
every time it failed (and never succeeded).



which makes sense if it's a
random OOM problem on weaker architectures like armhf -- so, not the
fault of the new sbcl upload.


This isn't random. And, our armhf box has 255 GB of RAM (and armel VM 
has 26 GB), so running out of memory isn't likely. What can happen is 
that threads use too much resources for the address space, but that's 
something under control of the packages in question if I'm correct (but 
please correct me if I misunderstand). I'm not saying it's (easily) 
fixable, just that it systematically runs out of reachable memory during 
the particular test.



Is it possible to label the tests as
flaky on only a single architecture?


Yes [1], but I'm not seeing flaky behavior.

Paul

[1] add the skippable restriction to the test you want to be able to 
ignore and exit with exit code 77 when the failure happens on the 
architecture you want to ignore. If you want to skip the test on armhf 
and armel altogether, I rather suggest you use an "Architecture: !armel 
!armhf" line in the d/t/control section of the test.


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1016750: sbcl breaks cl-ironclad autopkgtest on armhf: Heap exhausted, game over.

[Sean Whitton]

Hello Paul,

On Sat 06 Aug 2022 at 04:19PM +02, Paul Gevers wrote:

> With a recent upload of sbcl the autopkgtest of cl-ironclad fails in testing
> when that autopkgtest is run with the binary packages of sbcl from
> unstable. It passes when run with only packages from testing.
> 
> ; wrote
>   
> /tmp/autopkgtest-lxc.d2c27h4h/downtmp/autopkgtest_tmp/usr/share/common-lisp/source/ironclad/src/ciphers/tea-tmp93OFNPHA.fasl
> ; compilation finished in 0:00:00.160
> ; compiling file
>   "/usr/share/common-lisp/source/ironclad/src/ciphers/threefish.lisp" (written
>  18 FEB 2022 01:39:10 PM):
> Heap exhausted during garbage collection: 16 bytes available, 48 requested.
> Immobile Object Counts
>  Gen   GF type  fdefn symbol   code  Boxed   ConsRaw   Code  SmMix   Mixed
>  LgRaw LgCode  LgMix Waste%   AllocTrig   Dirty GCs Mem-age
>   1 00  0  0  0   7121939   9668  5273 827
>   0  0 17   19.96186748032499253   18850   1   1.1503
>   2 00  0  0  0  19865   2766  12586 848361681
>   10 34127   11.7   137430448 5368709   23089   0   0.9496
>   3 00  0  0  0  45116   7190   7447604   35521673
>   2394673311.0   270091288 2007806   0   0.4559
>   4 00  0  0  0  0  0  0  0  0   0
>   0  0  00.0   0 200   0   0   0.
>   5 00  0  0  0  0  0  0  0  0   0
>   0  0  00.0   0 200   0   0   0.
>   6 00  0  0  0   1370471   1242   3507314  40
>   2551342811.930584464 200 251   0   0.
> Tot 00  0  0  0  73472  11366  30943   4200   4975   4221
> 5046357566.9   499973680 [93.1% of 536870912 max]
> GC control variables:
>*GC-INHIBIT* = true
>*GC-PENDING* = true
> fatal error encountered in SBCL pid 1357:
> Heap exhausted, game over.

It looks like Lisp just ran out of memory.  Indeed, I can't see this
failure on debci.debian.org at present, which makes sense if it's a
random OOM problem on weaker architectures like armhf -- so, not the
fault of the new sbcl upload.  Is it possible to label the tests as
flaky on only a single architecture?

-- 
Sean Whitton

Bug#1016887: heaptrack: Grammar error in package description, misuse of contraction "it's" for possessive "its"

[Jason L. Quinn]

Package: heaptrack
Version: up to current (which is 1.3.0-1)
Severity: minor
X-Debbugs-Cc: jason.lee.quinn+deb...@gmail.com

Dear Maintainer,

The Debian package description says

"Heaptrack is notable for it's ability..."

it should be

"Heaptrack is notable for its ability..."

I noticed on Bullseye but checked that it still exists
up in 1.3.0-1 package on testing (Bookworm) and unstable (sid).

This bug also applies to the packages

libheaptrack and heaptrack-gui

Small bug report but hopefully one that helps polish Debian.

Thanks for what you do.

Cheers,
Jason Quinn

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

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

Versions of packages heaptrack depends on:
ii  libboost-iostreams1.74.01.74.0-9
ii  libboost-program-options1.74.0  1.74.0-9
ii  libc6   2.31-13+deb11u3
ii  libgcc-s1   10.2.1-6
pn  libheaptrack
ii  libstdc++6  10.2.1-6

heaptrack recommends no packages.

Bug#1016886: CVE-2020-1752: 'glob' use-after-free bug

[Masami Ichikawa]

Package: libc6
Version: 2.28-10+deb10u1
Severity: normal
Tags: patch

The CVE-2020-1752 was reported to glibc bugzilla[1].

CVE-2020-1752 description from NVD.
A use-after-free vulnerability introduced in glibc upstream version 2.14 was 
found in the way the tilde expansion was carried out. Directory paths 
containing an initial tilde followed by a valid username were affected by this 
issue. A local attacker could exploit this flaw by creating a specially crafted 
path that, when processed by the glob function, would potentially lead to 
arbitrary code execution. This was fixed in version 2.32.

This CVE has been fixed in release/2.28/master branch[2] about two years ago 
but there is no new upstream release for 2.28 series yet.

I ported upstream patch to 2.28-10+deb10u1.
 
1. https://sourceware.org/bugzilla/show_bug.cgi?id=25414
2. 
https://sourceware.org/git/?p=glibc.git;a=patch;h=21344a3d62a29406fddeec069ee4eb3c341369f9


*** submitted-Fix-use-after-free-in-glob-when-expanding-user-bug.diff
Index: glibc-2.28/NEWS
===
--- glibc-2.28.orig/NEWS
+++ glibc-2.28/NEWS
@@ -69,6 +69,7 @@ The following bugs are resolved with thi
   [24228] old x86 applications that use legacy libio crash on exit
   [24476] dlfcn: Guard __dlerror_main_freeres with __libc_once_get (once)
   [24744] io: Remove the copy_file_range emulation.
+  [25414] 'glob' use-after-free bug (CVE-2020-1752)
 
 Security related changes:
 
@@ -97,6 +98,10 @@ Security related changes:
   CVE-2019-9169: Attempted case-insensitive regular-expression match
   via proceed_next_node in posix/regexec.c leads to heap-based buffer
   over-read.  Reported by Hongxu Chen.
+
+  CVE-2020-1752: A use-after-free vulnerability in the glob function when
+  expanding ~user has been fixed.
+
 
 Version 2.28
 
Index: glibc-2.28/posix/glob.c
===
--- glibc-2.28.orig/posix/glob.c
+++ glibc-2.28/posix/glob.c
@@ -827,31 +827,32 @@ __glob (const char *pattern, int flags,
  {
size_t home_len = strlen (p->pw_dir);
size_t rest_len = end_name == NULL ? 0 : strlen (end_name);
-   char *d;
+   char *d, *newp;
+   bool use_alloca = glob_use_alloca (alloca_used,
+  home_len + rest_len + 1);
 
-   if (__glibc_unlikely (malloc_dirname))
- free (dirname);
-   malloc_dirname = 0;
-
-   if (glob_use_alloca (alloca_used, home_len + rest_len + 1))
- dirname = alloca_account (home_len + rest_len + 1,
-   alloca_used);
+   if (use_alloca)
+ newp = alloca_account (home_len + rest_len + 1, alloca_used);
else
  {
-   dirname = malloc (home_len + rest_len + 1);
-   if (dirname == NULL)
+   newp = malloc (home_len + rest_len + 1);
+   if (newp == NULL)
  {
scratch_buffer_free ();
retval = GLOB_NOSPACE;
goto out;
  }
-   malloc_dirname = 1;
  }
-   d = mempcpy (dirname, p->pw_dir, home_len);
+   d = mempcpy (newp, p->pw_dir, home_len);
if (end_name != NULL)
  d = mempcpy (d, end_name, rest_len);
*d = '\0';
 
+   if (__glibc_unlikely (malloc_dirname))
+ free (dirname);
+   dirname = newp;
+   malloc_dirname = !use_alloca;
+
dirlen = home_len + rest_len;
dirname_modified = 1;
  }


-- System Information:
Debian Release: 10.12
  APT prefers oldstable-updates
  APT policy: (500, 'oldstable-updates'), (500, 'oldstable')
Architecture: amd64 (x86_64)

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

Versions of packages libc6 depends on:
ii  libgcc1  1:8.3.0-6

Versions of packages libc6 recommends:
ii  libidn2-0  2.0.5-1+deb10u1

Versions of packages libc6 suggests:
ii  debconf [debconf-2.0]  1.5.71+deb10u1
pn  glibc-doc  
ii  libc-l10n  2.28-10+deb10u1
ii  locales2.28-10+deb10u1

-- debconf information:
  libraries/restart-without-asking: false
  glibc/restart-services:
  glibc/restart-failed:
  glibc/kernel-not-supported:
  glibc/kernel-too-old:
  glibc/upgrade: true
  glibc/disable-screensaver:

Bug#1016885: obs-studio: IPv6 bind address handling totally broken

[Tj]

Package: obs-studio
Version: 26.1.2+dfsg1-2
Severity: wishlist

Due to a bug in upstream all IPv6 address handling is broken. The 
specific problem is incorrect setting of sin_addr for calls to 
inet_ntop()/inet_pton() resulting in broken string representation of 
IPv6 addresses, which percolates up into the user interface.


OBS tries to figure out the correct IPv6 source address to bind to, but 
when setting the BindIP with the corrupted string, causes bind() to fail 
with "address does not exist" GUI message and:


info: [rtmp stream: 'adv_stream'] Binding to IPv6 



info: RTMP_Connect0, failed to bind socket: unknown error (99)

The fix is in upstream as commit #fb7a037bc "obs-outputs: Fix binding to 
IPv6 addresses on *nix".


I've added this patch on top of the current Debian version and confirmed 
it fixes the bug.

Bug#1016880: fbasics: FTBFS on hppa - /usr/bin/ld: cannot find /usr/lib/gcc/hppa-linux-gnu/11/libgcc.a

[Dirk Eddelbuettel]

On 8 August 2022 at 19:53, John David Anglin wrote:
| On 2022-08-08 3:32 p.m., Dirk Eddelbuettel wrote:
| > The problem is the build now uses the gcc-12 toolchain.  I think the R
| > | build environment needs updating.
| >
| > Could you test with a local binary rebuild of r-base on hppa?  I am not 
aware
| > of other architectures having or needing a static gcc library...
| >
| > CRAN already uses gcc-12 on x86_64 
(seehttps://cloud.r-project.org/web/checks/check_flavors.html)
| > so it is not that gcc-12 should be an issue per se. I can update the 
package,
| > I just fear it may ruffle other feathers...
| Rebuilding r-base package with gcc-12 resolves issue.

Thanks for confirming. I can trigger a rebuild.

Will I need an explicit depends or is gcc-12 now the default in unstable (as
I suspect it is)?

| I tend to think linking with libgcc.a shouldn't be necessary on hppa as the 
gcc driver should add it to the link
| command automatically.

Right. It looked a little weird.

Upstream for R is actually rather good about autoconf and the GNU toolchain
so generally things 'just work'.

Dirk

-- 
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Bug#1007887: xxd autoremoved - please recommend or suggest

[James McCoy]

On Sat, Aug 06, 2022 at 08:55:50AM +0100, RjY wrote:
> Hi, this morning I was surprised to see xxd being removed by the latest
> apt upgrade (because it was marked as automatically installed - I have
> since marked it as manual).

Which is the logical step, since you actually want xxd installed.

> I agree it should not be a "Depends:" but would it make sense to retain
> a "Recommends:" or "Suggests:" relationship between the packages to
> avoid surprising users?

I'm not sure how many people that use Vim actually know or care about
xxd.  For those that do, manually installing the package (now that it
has its own) is pretty easy.

Other than a menu item that uses xxd, there's nothing else in Vim that
directly uses it.

I guess I can add the Recommends to (neo)vim so there's a common
baseline, and people can uninstall if they don't want it.

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Bug#1011749: Uploaded package for interception-tools

[Osamu Aoki]

I have done complete new packaging with correct COPYRIGHT

Also minimized renaming and followed the upstream preferred set.

  intercept -> interception (intercept available in -compat package.)
  udevmon   -> udevmon (no change)
  uinput-> uinput (no change)
  mux   -> mux (no change)

Regards,

Osamu

Bug#1016880: fbasics: FTBFS on hppa - /usr/bin/ld: cannot find /usr/lib/gcc/hppa-linux-gnu/11/libgcc.a

[John David Anglin]

On 2022-08-08 3:32 p.m., Dirk Eddelbuettel wrote:

The problem is the build now uses the gcc-12 toolchain.  I think the R
| build environment needs updating.

Could you test with a local binary rebuild of r-base on hppa?  I am not aware
of other architectures having or needing a static gcc library...

CRAN already uses gcc-12 on x86_64 
(seehttps://cloud.r-project.org/web/checks/check_flavors.html)
so it is not that gcc-12 should be an issue per se. I can update the package,
I just fear it may ruffle other feathers...

Rebuilding r-base package with gcc-12 resolves issue.

I tend to think linking with libgcc.a shouldn't be necessary on hppa as the gcc 
driver should add it to the link
command automatically.

Dave

--
John David Anglin  dave.ang...@bell.net

Bug#1016180: transition: gnome-desktop 43

[Jeremy Bicha]

The gnome-desktop transition completed successfully in Ubuntu.

chatty was uploaded to Unstable so it can be NMU'd when ready.

Thank you,
Jeremy Bicha

Bug#1016455: cryptsetup-initramfs: fix for #902943 breaks image building use case

[Sean Whitton]

Hello,

On Sat 06 Aug 2022 at 12:12AM +02, Guilhem Moulin wrote:

> Could you please double check that
>
> 
> https://salsa.debian.org/cryptsetup-team/cryptsetup/-/commit/3854ce68641ba84b04df35828ccb9abcb569e5c6
>  and
> 
> https://salsa.debian.org/cryptsetup-team/cryptsetup/-/commit/e03fcc0d3e3285b4e72208f40a4ac59db3022b48
>
> suit your use case?  (No need to build the package, you can just patch
> the initramfs hook and boot script in /usr/share/initramfs-tools.)

Tested building an image, and now it generates a crypttab in the
initramfs that I am pretty sure will work -- thank you.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1016884: heimdal: FTBFS with glibc >= 2.34

[Samuel Thibault]

Source: heimdal
Version: 1.6~rc2+dfsg-9+deb8u1
Severity: serious
Justification: FTBFS

Hello,

Now that glibc provides a closefrom function, heimdal doesn't build its
own rk_closefrom function any more, and thus the
libroken18-heimdal.symbols check complains:

- rk_closefrom@HEIMDAL_ROKEN_1.0 1.4.0+git20110226
+#MISSING: 7.7.0+dfsg-4+b1# rk_closefrom@HEIMDAL_ROKEN_1.0 1.4.0+git20110226

Samuel

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

Kernel: Linux 5.19.0 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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

-- 
Samuel
---
Pour une évaluation indépendante, transparente et rigoureuse !
Je soutiens la Commission d'Évaluation de l'Inria.

Bug#1016877: org-mode-doc: The info documentation doesn't override the version shipped with emacs

[David Bremner]

Diane Trout  writes:

>
> Though debian-el might be a better example to follow where the info file
> and its dir file are added to the elpa-src directory.
>

Although that's my doing (I think) I have to note that it makes the info
files inaccessible to /usr/bin/info, so might not be an ideal solution.

d

Bug#976626: Similar package

[Francois Marier]

This seems very similar to the tldr package:

  https://packages.debian.org/stable/tldr

See https://tldr.sh/ for examples.

Francois

Bug#1012898: assimp: diff for NMU version 5.2.4~ds0-1.1

[Timo Röhling]

I've prepared an NMU for assimp (versioned as 5.2.4~ds0-1.1) and
uploaded it to DELAYED/2, going with the minimally invasive patch
proposed by Pino Toscano.

Cheers

--
⢀⣴⠾⠻⢶⣦⠀   ╭╮
⣾⠁⢠⠒⠀⣿⡁   │ Timo Röhling   │
⢿⡄⠘⠷⠚⠋⠀   │ 9B03 EBB9 8300 DF97 C2B1  23BF CC8C 6BDD 1403 F4CA │
⠈⠳⣄   ╰╯
diff -Nru assimp-5.2.4~ds0/debian/changelog assimp-5.2.4~ds0/debian/changelog
--- assimp-5.2.4~ds0/debian/changelog	2022-05-14 23:07:16.0 +0200
+++ assimp-5.2.4~ds0/debian/changelog	2022-08-08 23:24:46.0 +0200
@@ -1,3 +1,11 @@
+assimp (5.2.4~ds0-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Disable -Werror for the build.
+Thanks to Pino Toscano for the patch (Closes: #1012898)
+
+ -- Timo Röhling   Mon, 08 Aug 2022 23:24:46 +0200
+
 assimp (5.2.4~ds0-1) unstable; urgency=medium
 
   * New upstream version 5.2.4~ds0
diff -Nru assimp-5.2.4~ds0/debian/.gitattributes assimp-5.2.4~ds0/debian/.gitattributes
--- assimp-5.2.4~ds0/debian/.gitattributes	2022-05-14 23:07:16.0 +0200
+++ assimp-5.2.4~ds0/debian/.gitattributes	1970-01-01 01:00:00.0 +0100
@@ -1 +0,0 @@
-changelog merge=dpkg-mergechangelogs
diff -Nru assimp-5.2.4~ds0/debian/rules assimp-5.2.4~ds0/debian/rules
--- assimp-5.2.4~ds0/debian/rules	2022-05-14 23:07:16.0 +0200
+++ assimp-5.2.4~ds0/debian/rules	2022-08-08 23:23:43.0 +0200
@@ -45,6 +45,7 @@
 		-DASSIMP_BUILD_TESTS=OFF \
 		-DASSIMP_BUILD_ZLIB=OFF \
 		-DASSIMP_LIB_INSTALL_DIR=lib/$(DEB_HOST_MULTIARCH) \
+		-DASSIMP_WARNINGS_AS_ERRORS=OFF \
 		-DCMAKE_SHARED_LINKER_FLAGS="-Wl,--version-script=$(CURDIR)/debian/libassimp.ver $(LDFLAGS)" \
 		-DCMAKE_EXE_LINKER_FLAGS="$(LDFLAGS)" \
 		-DCMAKE_BUILD_RPATH_USE_ORIGIN=ON \


signature.asc
Description: PGP signature

Bug#1016363: fix for fvwm

[Matthieu Herrb]

XCheckIfEvent() holds the X display lock and the predicate
function it calls is not allowed to call any Xlib function that
would re-enter the lock.
libX11 1.8.1 enables X display locks unconditionnaly (it was only
enabled by XInitThreads() when called explicitely before) and
thus exposes the issue.

So don't process events in the FCheckPeekIfEvent() predicate, but
instead use a separate handler that is called for the returned event
out of the lock.
---
 fvwm/events.c |  9 -
 libs/FEvent.c | 22 ++
 libs/FEvent.h |  8 
 3 files changed, 38 insertions(+), 1 deletion(-)

diff --git a/fvwm/events.c b/fvwm/events.c
index ae179d62..72d85707 100644
--- a/fvwm/events.c
+++ b/fvwm/events.c
@@ -267,6 +267,12 @@ static int _pred_weed_accumulate_expose(
return 1;
 }
 
+static int _pred_weed_is_expose(
+   Display *display, XEvent *event, XPointer arg)
+{
+   return (event->type == Expose);
+}
+
 static int _pred_weed_handle_expose(
Display *display, XEvent *event, XPointer arg)
 {
@@ -4546,7 +4552,8 @@ void handle_all_expose(void)
 
saved_event = fev_save_event();
FPending(dpy);
-   FWeedIfEvents(dpy, _pred_weed_handle_expose, NULL);
+   FWeedAndHandleIfEvents(dpy, _pred_weed_is_expose,
+  _pred_weed_handle_expose, NULL);
fev_restore_event(saved_event);
 
return;
diff --git a/libs/FEvent.c b/libs/FEvent.c
index f3bf54d3..7e062118 100644
--- a/libs/FEvent.c
+++ b/libs/FEvent.c
@@ -534,6 +534,28 @@ int FWeedIfEvents(
return weed_args.count;
 }
 
+int FWeedAndHandleIfEvents(
+   Display *display,
+   int (*weed_predicate) (Display *display, XEvent *event, XPointer arg),
+   int (*handler) (Display *display, XEvent *event, XPointer arg),
+   XPointer arg)
+{
+   _fev_weed_args weed_args;
+   XEvent e;
+
+   assert(fev_is_invalid_event_type_set);
+   memset(_args, 0, sizeof(weed_args));
+   weed_args.weed_predicate = weed_predicate;
+   weed_args.arg = arg;
+   if (FCheckPeekIfEvent(display, , _fev_pred_weed_if,
+ (XPointer)_args)) {
+   handler(display, , arg);
+   }
+   _fev_pred_weed_if_finish(_args);
+
+   return weed_args.count;
+}
+
 int FWeedIfWindowEvents(
Display *display, Window window,
int (*weed_predicate) (
diff --git a/libs/FEvent.h b/libs/FEvent.h
index ecfb164c..f17ac5e9 100644
--- a/libs/FEvent.h
+++ b/libs/FEvent.h
@@ -114,6 +114,14 @@ int FWeedIfEvents(
Display *display, XEvent *current_event, XPointer arg),
XPointer arg);
 
+/* Same as FWeedIfEvents but with a second callback out of XLockDisplay()
+ * to handle events in a lock-safe manner */
+int FWeedAndHandleIfEvents(
+   Display *display,
+   int (*weed_predicate) (Display *display, XEvent *event, XPointer arg),
+   int (*handler) (Display *display, XEvent *event, XPointer arg),
+   XPointer arg);
+
 /* Same as FWeedIfEvents but weeds only events for the given window.  The
  * weed_predicate is only called for events with a matching window.  */
 int FWeedIfWindowEvents(
-- 
2.37.1

This is: https://github.com/fvwmorg/fvwm3/pull/683
-- 
Matthieu Herrb

Bug#1016883: prometheus service ought depend on time-sync

[Nick Black (Public gmail account)]

Package: prometheus
Version: 2.24.1+ds-1
Severity: normal
X-Debbugs-Cc: dankamong...@gmail.com

Dear Maintainer,

I run prometheus on a Libre Computer Potato SBC, lacking an RTC,
collecting from prometheus-node-exporter on my workstation. In the
default configuration, prometheus fills logs with errors along the lines
of:

Aug 08 17:00:40 amoled prometheus[2337]: level=warn ts=2022-08-08T21:00:40.522Z 
caller=scrape.go:1372 component="scrape manager" scrape_pool=prometheus 
target=http://localhost:9090/metrics msg="Error on ingesting out-of-order 
samples" num_dropped=404

and doesn't append to my records. Upon restarting promtheus with

  systemctl restart prometheus

the problem goes away, and I can begin collecting stats anew.

I believe this is due to the prometheus service not depending on
time-sync.target. I've added

  [Unit]
  Before=time-sync.target
  Wants=time-sync.target

to a drop-in, and with this change, I do not hit the problem.

Given prometheus's fundamental dependency on time-ordered databases, I
feel this dependency ought be present in the default prometheus systemd
unit.

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

Kernel: Linux 5.18.15nlb2 (SMP w/64 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)

Versions of packages prometheus depends on:
ii  adduser  3.123
ii  fonts-glyphicons-halflings   1.009~3.4.1+dfsg-2
ii  init-system-helpers  1.64
ii  libc62.34-1
ii  libjs-bootstrap4 4.6.1+dfsg1-3
pn  libjs-eonasdan-bootstrap-datetimepicker  
ii  libjs-jquery 3.6.0+dfsg+~3.5.13-1
ii  libjs-jquery-hotkeys 0~20130707+git2d51e3a9+dfsg-2.1
pn  libjs-moment 
pn  libjs-moment-timezone
pn  libjs-mustache   
ii  libjs-popper.js  1.16.1+ds-5
pn  libjs-rickshaw   

Versions of packages prometheus recommends:
ii  prometheus-node-exporter  1.3.1-1+b1

prometheus suggests no packages.

Bug#1016882: broadcom-sta-dkms: The initrd is not automatically regenerated after installing 'wl' which makes the module unusable

[tanmayb]

Package: broadcom-sta-dkms
Version: 6.30.223.271-20
Severity: important
X-Debbugs-Cc: boratanmay00...@gmail.com




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

Kernel: Linux 5.18.0-3-amd64 (SMP w/2 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
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 broadcom-sta-dkms depends on:
ii  dkms  3.0.3-4

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

broadcom-sta-dkms suggests no packages.

-- no debconf information

After installing "broadcom-sta-dkms" package and running the modprobe commands 
provided in the Debian wiki for "wl", the WiFi starts working for that
instance but as soon as you reboot(or shutdown and start again) the WiFi stops 
working(the module is not loaded) and even the modprobe commands have no
effect. So after this, I tried doing 'dpkg-reconfigure broadcom-sta-dkms' and 
running the modprobe commands after that but it had no effect. I removed
the package using apt, rebooted my PC, reinstalled the package again and did 
the modprobe commands and the WiFi started working. But again after a reboot
or shutdown the WiFi stopped working. I did the same procedure of reinstalling 
the package again, but this time I noticed while installing the package
that the REMAKE_INITRD was present in the dkms conf but was deprecated and not 
followed so I regenerated the initrd manually using 
"update-initramfs -c -k all" and even after a reboot or shutdown the module was 
loaded and the WiFi was working.

--

Solution

The initrd should be regenerated automatically somehow after installing the 
package as it was done before REMAKE_INITRD was deprecated. If this is not 
possible then a note or something should be added to the Debian wiki page of 
'wl'. 

--

Also I have a question related to this
As far as I know the initrd contains the most basic drivers like ext4, etc. to 
get the root filesystem mounted and once that is done other modules can
be loaded dynamically by the kernel from the filesystem. Then why is the 'wl' 
driver required in the initrd image and why isn't it loaded automatically
/dynamically by the kernel when it is installed and available.(I am asking this 
here because the maintainers of this driver are the ones who would know
about this). 

Thank You!

Bug#1016283: onetbb: FTBFS: _segment_table.h:63:63: error: member ‘tbb::detail::d1::segment_table, 128>, tbb::detail::d1::cache_aligned_alloc

[Richard B. Kreckel]

I am unable to reproduce the above compile-time error.

Bug#993574: python3-virtualsmartcard: Cannot import virtualsmartcard module

[Michael Weghorn]

(...) With this in place, I still ran into another problem, 
described in upstream issue 
https://github.com/frankmorgner/vsmartcard/issues/218

("ModuleNotFoundError: No module named 'sha'").
With a logical backport of the suggested upstream PR 
https://github.com/frankmorgner/vsmartcard/pull/228 , running `vicc` 
then works without errors for me. Backport in the patch-queue branch of 
my local package looks like this:

(...)


FWIW, that upstream pull request has been merged now.

Bug#1016881: Please update chrome-gnome-shell to version 42

[Amr Ibrahim]

Package: chrome-gnome-shell

Hallo,

Upstream has renamed chrome-gnome-shell into gnome-browser-connector,
and released version 42. Please follow the new upstream source.

GNOME Shell browser integration homepage
https://wiki.gnome.org/Projects/GnomeShellIntegration

gnome-browser-connector source
https://gitlab.gnome.org/nE0sIghT/gnome-browser-connector


A question: is there a reason why gnome-browser-extension is not
packaged in Debian, and has to be installed from Firefox Add-ons?

gnome-browser-extension source
https://gitlab.gnome.org/GNOME/gnome-browser-extension


Best,
Amr

Bug#976793: libgcc-s1-*-cross is Important: yes

[Simon McVittie]

Control: tags -1 + moreinfo

On Tue, 08 Dec 2020 at 00:51:00 +0100, Adam Borowski wrote:
> While trying to uninstall cross toolchain:
> 
> WARNING: The following essential packages will be removed.
...
> Which is caused by:
> Package: libgcc-s1-arm64-cross
...
> Priority: optional
> Protected: yes
...
> Important: yes
> ^^

On Wed, 14 Jul 2021 at 08:00:19 +0200, Matthias Klose wrote:
> According to the build logs, all lib*-*-cross packages have optional priority,
> so it needs to be adjusted for the archive.

I believe Adam's concern was about the Protected and Important fields
(which are controlled by the maintainer in the usual way, I think?) and
not about the Priority field (which is controlled by the ftp team).

The Important field was an old name for the almost-Essential state that
apt now calls Protected, and should not be confused with Priority:
important, but obviously it's very easy to confuse them (hence the
rename).

None of the versions of libgcc-s1-arm64-cross visible to my apt-cache
seem to be Protected, Important, or have an inflated priority.

I can 'sudo apt install libgcc-s1-arm64-cross' and
'sudo apt purge gcc-12-cross-base libc6-arm64-cross libgcc-s1-arm64-cross'
without any warnings, on an unstable system with a fairly complete set
of apt sources (buster, bullseye, bookworm, sid, experimental). So I think
this has been dealt with somewhere/somehow?

smcv

Bug#1016873: grub2: enable "http" module for netboot

[Ansgar]

On Mon, 08 Aug 2022 18:54:41 +0200 Ansgar wrote:
> Ubuntu's grub has at least the following changes which seem related:
> 
> +---
> | grub2 (2.06-2ubuntu1) jammy; urgency=medium
> |   * Merge from Debian unstable; remaining changes:
> | [...]
> | - build-efi-images: Add http to netboot images
> | [...]
> | - Added patches:
> | [...]
> |   + rhboot-f34-efinet-also-use-the-firmware-acceleration-for-http.patch
> +---

I tried a local build with:
  - http added to NET_MODULES
  - patch suse-add-support-for-UEFI-network-protocols.patch
(required for the next patch)
  - patch rhboot-f34-efinet-also-use-the-firmware-acceleration-for-http.patch
with the patches from grub2_2.06-2ubuntu7.dsc.

With this grub looks for grub.cfg:

+---
| X.X.X.X - - [08/Aug/2022:22:09:19 +0200] "HEAD /patched/bootx64.efi HTTP/1.1" 
200 0 "-" "UefiHttpBoot/1.0"
| X.X.X.X - - [08/Aug/2022:22:09:19 +0200] "GET /patched/bootx64.efi HTTP/1.1" 
200 934240 "-" "UefiHttpBoot/1.0"
| X.X.X.X - - [08/Aug/2022:22:09:20 +0200] "GET /patched//grubx64.efi HTTP/1.1" 
200 1478656 "-" "UefiHttpBoot/1.0"
| X.X.X.X - - [08/Aug/2022:22:09:20 +0200] "HEAD /grub/x86_64-efi/command.lst 
HTTP/1.1" 404 0 "-" "UefiHttpBoot/1.0"
| X.X.X.X - - [08/Aug/2022:22:09:20 +0200] "HEAD /grub/x86_64-efi/fs.lst 
HTTP/1.1" 404 0 "-" "UefiHttpBoot/1.0"
| X.X.X.X - - [08/Aug/2022:22:09:20 +0200] "HEAD /grub/x86_64-efi/crypto.lst 
HTTP/1.1" 404 0 "-" "UefiHttpBoot/1.0"
| X.X.X.X - - [08/Aug/2022:22:09:20 +0200] "HEAD /grub/x86_64-efi/terminal.lst 
HTTP/1.1" 404 0 "-" "UefiHttpBoot/1.0"
| X.X.X.X - - [08/Aug/2022:22:09:21 +0200] "HEAD /grub/grub.cfg HTTP/1.1" 200 0 
"-" "UefiHttpBoot/1.0"
| X.X.X.X - - [08/Aug/2022:22:09:21 +0200] "GET /grub/grub.cfg HTTP/1.1" 200 
779 "-" "UefiHttpBoot/1.0"
+---

It would also be nice if grub searched for grub.cfg in a location
relative to grubx64.efi like shim does for grubx64.efi (shim is
bootx64.efi here).  (And/or DHCP options like pxelinux has[1].)

Ansgar

  [1]: https://wiki.syslinux.org/wiki/index.php?title=PXELINUX#DHCP_options

Bug#1009642: libnss-docker uses perl in postrm script

[Gioele Barabucci]

An updated patch that uses the `dh_installnss` debhelper addon can be 
found at .


--
Gioele Barabucci

Bug#1016863: libreoffice: Bad performance especially when dealing with pictures

[Rene Engelhard]

Hi again,

Am 08.08.22 um 14:10 schrieb Matteo A.:

Also installing libreoffice-qt5 the look doesn't change.


Oh, and this actually is completely expected. It only gets c hoosen per 
default if your desktop is KDE (well, kf5 which bases on it). As gtk3 
gets choosen for you per default that isn't the case. You can set it though:


cf. e.g. https://wiki.archlinux.org/title/LibreOffice#Theme

Regards,

Rene

Bug#1016880: fbasics: FTBFS on hppa - /usr/bin/ld: cannot find /usr/lib/gcc/hppa-linux-gnu/11/libgcc.a

[Dirk Eddelbuettel]

On 8 August 2022 at 19:10, John David Anglin wrote:
| Source: fbasics
| Version: 3042.89.2-1
| Severity: normal
| 
| Dear Maintainer,
| 
| The fbasic build on hppa fails here:
| gcc -shared -L/usr/lib/R/lib -o fBasics.so gld.o init.o nig.o -lblas 
-lgfortran -lm /usr/lib/gcc/hppa-linux-gnu/11/libgcc.a -L/usr/lib/R/lib -lR
| /usr/bin/ld: cannot find /usr/lib/gcc/hppa-linux-gnu/11/libgcc.a: No such 
file or directory
| collect2: error: ld returned 1 exit status
| make[1]: *** [/usr/share/R/share/make/shlib.mk:10: fBasics.so] Error 1
| 
| Full log is here:
| 
https://buildd.debian.org/status/fetch.php?pkg=fbasics=hppa=4021.92-1=1659965765=0
| 
| The problem is the build now uses the gcc-12 toolchain.  I think the R
| build environment needs updating.

Could you test with a local binary rebuild of r-base on hppa?  I am not aware
of other architectures having or needing a static gcc library...

CRAN already uses gcc-12 on x86_64 (see 
https://cloud.r-project.org/web/checks/check_flavors.html)
so it is not that gcc-12 should be an issue per se. I can update the package,
I just fear it may ruffle other feathers...

Dirk

| Same problem occurs building fgarch, funitroots and r-bioc-edger.
| 
| Regards,
| Dave Anglin
| 
| -- System Information:
| Debian Release: bookworm/sid
|   APT prefers buildd-unstable
|   APT policy: (500, 'buildd-unstable'), (500, 'unstable')
| Architecture: hppa (parisc64)
| 
| Kernel: Linux 5.18.16+ (SMP w/4 CPU threads)
| Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
| Shell: /bin/sh linked to /bin/dash
| Init: systemd (via /run/systemd/system)

-- 
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Bug#1009646: libnss-mdns uses perl in postrm script

[Gioele Barabucci]

An updated patch that uses the `dh_installnss` debhelper addon can be 
found at .


--
Gioele Barabucci

Bug#1016511: python3-pydevd: missing Breaks+Replaces: python3-omegaconf (<< ???)

[Julian Gilbey]

On Tue, Aug 02, 2022 at 07:41:51AM +0200, Andreas Beckmann wrote:
> Package: python3-pydevd
> Version: 2.8.0+git20220714.32dee0b+dfsg-2
> Severity: serious
> User: debian...@lists.debian.org
> Usertags: piuparts
> Control: block -1 with 1016510
> 
> Hi,
> 
> during a test with piuparts I noticed your package failed to install
> because it tries to overwrite other packages files without declaring a
> Breaks+Replaces relation.
> [...]

> python3-omegaconf still needs to drop the conflicting files (#1016510),
> so my guess would be that you need to add
> 
>   Breaks+Replaces: python3-omegaconf (<< 2.1.0~rc1-4~)

Thanks Andreas!  I had no idea any other packages were using the
pydevd namespace - I hadn't even thought to check.  Thomas has now
fixed python3-omegaconf (thanks Thomas!), so the new version of pydevd
that I'm just building and uploading should solve this one.

Best wishes,

   Julian

Bug#1016880: fbasics: FTBFS on hppa - /usr/bin/ld: cannot find /usr/lib/gcc/hppa-linux-gnu/11/libgcc.a

[John David Anglin]

Source: fbasics
Version: 3042.89.2-1
Severity: normal

Dear Maintainer,

The fbasic build on hppa fails here:
gcc -shared -L/usr/lib/R/lib -o fBasics.so gld.o init.o nig.o -lblas -lgfortran 
-lm /usr/lib/gcc/hppa-linux-gnu/11/libgcc.a -L/usr/lib/R/lib -lR
/usr/bin/ld: cannot find /usr/lib/gcc/hppa-linux-gnu/11/libgcc.a: No such file 
or directory
collect2: error: ld returned 1 exit status
make[1]: *** [/usr/share/R/share/make/shlib.mk:10: fBasics.so] Error 1

Full log is here:
https://buildd.debian.org/status/fetch.php?pkg=fbasics=hppa=4021.92-1=1659965765=0

The problem is the build now uses the gcc-12 toolchain.  I think the R
build environment needs updating.

Same problem occurs building fgarch, funitroots and r-bioc-edger.

Regards,
Dave Anglin

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

Kernel: Linux 5.18.16+ (SMP w/4 CPU threads)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#1014907: rustc-mozilla 1.59.0+dfsg1-1~deb10u3 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 1014907 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: rustc-mozilla
Version: 1.59.0+dfsg1-1~deb10u3

Explanation: include mips(el) stage0 binaries

Bug#1014875: freecad: FTBFS on armel and armhf: error: ‘GL_PROJECTION’ was not declared in this scope;

[Tobias Frost]

Package: freecad
Version: 0.20+dfsg1-2
Followup-For: Bug #1014875
Control: tags -1 +patch

Dear Maintainer,

with attached patch makes I could compile FreeCAD on the amdahl armhf porterbox.

-- 
Cheer,
tobi

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

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

Versions of packages freecad depends on:
ii  freecad-python3  0.20+dfsg1-2

Versions of packages freecad recommends:
ii  calculix-ccx  2.19-1
ii  graphviz  2.42.2-7

Versions of packages freecad suggests:
ii  povray  1:3.7.0.10-2

-- no debconf information

Bug#1014875: freecad: FTBFS on armel and armhf: error: ‘GL_PROJECTION’ was not declared in this scope;

[Tobias Frost]

Package: freecad
Version: 0.20+dfsg1-2
Followup-For: Bug #1014875

(Attaching patch)
Description: Fix FTBFS on armhf/armel, undefined GL_PROJECTION
 This define is defined in GL/gl.h, so there  must be some missing include
 somewhere. This patch just adds the include…
Author: t...@debian.org
Bug-Debian: https://bugs.debian.org/1014875
Forwarded: no
Last-Update: 2022-08-08 
---
This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
--- a/src/Gui/Quarter/QuarterWidget.cpp
+++ b/src/Gui/Quarter/QuarterWidget.cpp
@@ -54,6 +54,11 @@
 
 #include 
 
+#include "config.h"
+#ifdef  HAVE_GL_GL_H
+#include 
+#endif
+
 #include 
 #include 
 #include 

Bug#1015419: gnome-calls: ftbfs with LTO (link time optimization) enabled

[Evangelos Ribeiro Tzaras]

control: forwarded -1 https://gitlab.gnome.org/GNOME/calls/-/issues/427

Hi Matthias and thanks for your report!

On Tue, 19 Jul 2022 16:52:35 + Matthias Klose  wrote:
> Package: src:gnome-calls
> Version: 43~alpha.1-1
> Severity: minor
> Tags: sid bookworm
> User: debian-...@lists.debian.org
> Usertags: ftbfs-lto
> 
> This package currently fails to build (at least on the amd64
> architecture) with link time optimizations enabled.  For a background
> for LTO please see
> 
> https://wiki.debian.org/ToolChain/LTO
> 
> The goal is to enable this optimization by default in an upcoming
> Debian release in dpkg-buildflags for 64bit architectures.  The goal
> is to get this package to build with link time optimizations, or to
> explicitly disable link time optimizations for this package build.
> 
> To reproduce the build failure, enable the lto optimization in
> testing/unstable by adding "optimize=+lto" to DEB_BUILD_MAINT_OPTIONS
> in the debian/rules file, or if this macro is unset, just set it:
> 
> export DEB_BUILD_MAINT_OPTIONS = optimize=+lto

I could reproduce the issue just now, thanks for the pointer.

Part of the problem seems to be that some wrapped symbols
(`--wrap` is passed to `ld`)
is being stripped/optimized away.

I will investigate and try to come up with a fix upstream
so that the we don't need to be wrapping the symbol any more.

It is currently used to stop the code from making contact lookups
which I've expected to fail in test environments such as in CI or buildd.
For this reason the tests use --wrap to stub out the relevant functions.

The correct fix would be making sure that the contact lookups with folks
are using some sort of dummy backend
as discussed in the upstream issue.

-- 
Cheers,

Evangelos
PGP: B938 6554 B7DD 266B CB8E 29A9 90F0 C9B1 8A6B 4A19


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

Bug#1015132: meson: FTBFS: ./b 52a78b9866/../test cases/failing build/2 hidden symbol/bobuser.c:4: undefined reference to `hidden_function'

[Eli Schwartz]

On Sat, 16 Jul 2022 20:55:02 +0200 Lucas Nussbaum  wrote:
> Hi,
> 
> The script I use to extract the failure from the log might have guessed
> badly indeed, however the build still fails, as shown by the full log
> linked in the bug:
> http://qa-logs.debian.net/2022/07/16/meson_0.63.0-1_unstable.log
> SO I wouldn't call that a "spurious failure".
> 
> However looking at the log I don't really understand why the
> override_dh_auto_test target fails. Can you explain? Maybe I can improve
> my script.
> 
> Lucas


The testsuite has two parts. The first part (that actually fails in this
case) is a standard python-unittest run, and presumably you have
heuristics that can catch that.

The second part is a very custom setup, you'll undoubtedly need to
manually code support for it. Since Debian includes the environment
variable $MESON_PRINT_TEST_OUTPUT for extra extra extra debug spew, it
logs full configure/build/test/install output for all tests, not just
the ones that represent test failures... including, as stated above,
passing tests that attempt to assert that certain things aren't expected
to work.

Let's take a look at run_project_tests.py which is driving these very
verbose tests:

class TestStatus(Enum):
OK = normal_green(' [SUCCESS] ')
SKIP = yellow(' [SKIPPED] ')
ERROR = red('  [ERROR]  ')
UNEXSKIP = red('[UNEXSKIP] ')
UNEXRUN = red(' [UNEXRUN] ')
CANCELED = cyan('[CANCELED] ')
RUNNING = blue(' [RUNNING] ')  # Should never be actually printed
LOG = bold('   [LOG]   ')  # Should never be actually printed


Individual test logs are always separated by lines beginning with the
string " [XXX]".

error, unexskip, and unexrun are the only failure states.

unexskip and unexrun can only happen in Meson's internal CI
($MESON_CI_JOBNAME is set and isn't "thirdparty").



So you can just filter for:

- any python-unittest matching logs (e.g. in between "===" and
  "\nRan  tests in s")

- anything in between " [ERROR]" and " []"



-- 
Eli Schwartz

Bug#1016878: mozjs91: no longer needed

[Simon McVittie]

Control: severity -1 important

On Mon, 08 Aug 2022 at 13:55:35 -0400, Jeremy Bicha wrote:
> gjs 1.73.2 has switched from mozjs91 to mozjs102. Once we update our
> gjs packaging, there won't be anything in Debian using mozjs91.

This seems a little premature. Let's not make mozjs91 (and gjs, and GNOME)
RC-buggy until we're actually using mozjs102, which as far as I can see
isn't in NEW yet.

smcv

Bug#959985: ifupdown: This bug persists in version 0.8.37 and renders /etc/network/interfaces useless.

[Richard Sonnenfeld]

Package: ifupdown
Version: 0.8.37
Followup-For: Bug #959985
X-Debbugs-Cc: richard.sonnenf...@nmt.edu

Dear Maintainer,

This is my first bug report -- but am a 20 year Linux user and hope I 
am doing it right.  My main point is that this bug persists in 0.8.37
and the "important" severity is justified.  The effect of this bug for
those of us who still use /etc/network/interfaces to wrest control from
NetworkManager is to make this impossible.  So one workaround that
I tested is to use NetworkManager, unpleasant as it is, to configure 
interfaces.  
The other successful workaround (my preference) is that suggested by Jonas 
Meurer.  

"systemctl mask ifupdown-pre.service".  

Let me add the output of
"systemctl status ifupdown-pre.service" 
This occurs before it is masked, obviously, and also when the interfaces
have not been defined in network manager (but do exist in 
/etc/network/interfaces)

● ifupdown-pre.service - Helper to synchronize boot up for ifupdown
 Loaded: loaded (/lib/systemd/system/ifupdown-pre.service; static)
 Active: failed (Result: exit-code) since Mon 2022-08-08 11:25:14 MDT; 1min 
15s ago
Process: 354 ExecStart=/bin/sh -c if [ "$CONFIGURE_INTERFACES" != "no" ] && 
[ -n "$(ifquery --read-environment --list --exclude=lo)" ] && [ -x /bin/udevadm 
]; then udevadm settle; fi (code=exited, status=1/FAILURE)
   Main PID: 354 (code=exited, status=1/FAILURE)
CPU: 4.226s

Aug 08 11:25:14 feynman systemd[1]: ifupdown-pre.service: Main process exited, 
code=exited, status=1/FAILURE
Aug 08 11:25:14 feynman systemd[1]: ifupdown-pre.service: Failed with result 
'exit-code'.
Aug 08 11:25:14 feynman systemd[1]: Failed to start Helper to synchronize boot 
up for ifupdown.
Aug 08 11:25:14 feynman systemd[1]: ifupdown-pre.service: Consumed 4.226s CPU 
time.

More background:

I have used Debian etch/stretch/jessie and I just upgraded to bullseye
and hit this problem.  I am fortunate to have fixed/wired IP addresses which
I configure via /etc/network/interfaces (shown below).  
Note that the error occurs both with the old names "eth0", "eth1"
and the "predictable names"  enp1s0, enp2s10.  (I switched back to eth0/eth1
because I thought perhaps the interface names hadn't been assigned yet
and that is why the network/interfaces file didn't work.)  Regardless,
this bug does not seem to be affected by the interface naming convention
used.

Clearly, noobs who use NetworkManager and DHCP and pointy clicky things to 
configure their interface are well taken careof.  This bug is freaking out
the old farts though.  I thought perhaps support for the interfaces file
had been dropped entirely ... but clearly not.

-- All the best to you wonderful package maintainers.


-- Package-specific info:
--- /etc/network/interfaces:
auto eth0
iface eth0 inet static
address 155.178.12.11
netmask 255.255.255.0
network 155.178.12.0
gateway 155.178.12.254

auto eth1
iface eth1 inet static
address 10.90.8.111
netmask 255.0.0.0
network 10.0.0.0
#gateway 10.90.8.254 


#auto enp2s10
#iface enp2s10 inet static
#As above deleted for security reasons

# auto enp1s0
# iface enp1s0 inet static
#As above deleted for security reasons

--- up and down scripts installed:
/etc/network/if-down.d:
total 8
-rwxr-xr-x 1 root root 1015 Feb  6  2021 avahi-autoipd
-rwxr-xr-x 1 root root  372 May 14  2021 openvpn
lrwxrwxrwx 1 root root   32 Feb 25  2021 wpasupplicant -> 
../../wpa_supplicant/ifupdown.sh

/etc/network/if-post-down.d:
total 4
-rwxr-xr-x 1 root root 1409 Mar  7  2020 wireless-tools
lrwxrwxrwx 1 root root   32 Feb 25  2021 wpasupplicant -> 
../../wpa_supplicant/ifupdown.sh

/etc/network/if-pre-up.d:
total 8
-rwxr-xr-x 1 root root 4191 Mar  7  2020 wireless-tools
lrwxrwxrwx 1 root root   32 Feb 25  2021 wpasupplicant -> 
../../wpa_supplicant/ifupdown.sh

/etc/network/if-up.d:
total 8
-rwxr-xr-x 1 root root 923 Feb  6  2021 avahi-autoipd
-rwxr-xr-x 1 root root 385 May 14  2021 openvpn
lrwxrwxrwx 1 root root  32 Feb 25  2021 wpasupplicant -> 
../../wpa_supplicant/ifupdown.sh


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

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

Versions of packages ifupdown depends on:
ii  adduser   3.118ubuntu2
ii  iproute2  5.10.0-4
ii  libc6 2.33-8
ii  lsb-base  11.1.0

Versions of packages ifupdown recommends:
ii  isc-dhcp-client [dhcp-client]  4.4.1-2.3

Versions of packages ifupdown suggests:
ii  ppp 2.4.9-1+1
pn  rdnssd  

-- no debconf information

Bug#1016879: prometheus-mysqld-exporter: Replace 'auth_socket' with 'unix_socket' in /etc/default/prometheus-mysqld-exporter

[Thomas Deutschmann]

Package: prometheus-mysqld-exporter
Version: 0.14.0-1+b1
Severity: normal

Dear Maintainer,

in /etc/default/prometheus-mysqld-exporter it is written

> [...]
> ### Monitoring user creation.
> #
> # You need a user with enough privileges for the exporter to run.
> #
> # Example to create a user to connect (only) via UNIX socket:
> #   CREATE USER IF NOT EXISTS 'prometheus'@'localhost' IDENTIFIED WITH
auth_socket;
> #
> [...]

However, when you will follow this advice you will get the error message

> /* SQL Error (1524): Plugin 'auth_socket' is not loaded */

That's because in MariaDB 10.4.3 and later, "auth_socket" was replaced
by "unix_socket".

I would suggest to update the default config file.

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

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

Versions of packages prometheus-mysqld-exporter depends on:
ii  adduser  3.123
ii  init-system-helpers  1.64
ii  libc62.33-8

prometheus-mysqld-exporter recommends no packages.

Versions of packages prometheus-mysqld-exporter suggests:
ii  default-mysql-server1.0.8
ii  mariadb-server-10.6 [virtual-mysql-server]  1:10.6.8-1

-- Configuration Files:
/etc/default/prometheus-mysqld-exporter changed [not included]

-- no debconf information

Bug#1016878: mozjs91: no longer needed

[Jeremy Bicha]

Source: mozjs91
Severity: serious
Version: 91.10.0-1

gjs 1.73.2 has switched from mozjs91 to mozjs102. Once we update our
gjs packaging, there won't be anything in Debian using mozjs91.

However, maybe Cinnamon will switch from mozjs78?

Thank you,
Jeremy Bicha

Bug#1016877: org-mode-doc: The info documentation doesn't override the version shipped with emacs

[Diane Trout]

Package: org-mode-doc
Version: 9.5.2-1
Severity: normal
X-Debbugs-Cc: none, Diane Trout 

Dear Maintainer,

I was trying to read the info documentation provided by the org-mode-doc
package which matched the version of org mode I was using (9.5.2) but by
default was actually getting the org documentation shipped with emacs
version 9.3.

After digging for a while into how the Info-directory-list variable was
defined, the default looked like the following, and with the 9.5
documentation found in "/usr/share/info".

("/usr/share/emacs/site-lisp/elpa/debian-el-37" "/usr/share/info/emacs"
"/usr/share/info/" "/usr/share/info/")

I tried figure out how to adjust the construction of the
Info-directory-list to put a "/usr/share/info" before the flavor
directory "/usr/share/info/emacs" but couldn't figure it out.

But then I tried to figure out why there was the debian-el-37 directory on
the Info-directory-list path.

What I found is if the info dir file is present in one of the
automatically loaded package directories that directory will be
pre-pended to the Info-directory-list path.

Somehow adding a dir file to
/usr/share/emacs/site-lisp/elpa/org-9.5.2/ causes info to find the newer
version. I'd copied the dir file and a decompressed version of
org.info.gz into /usr/share/info/emacs/site-lisp/elpa/org-9.5.2 

Though debian-el might be a better example to follow where the info file
and its dir file are added to the elpa-src directory.

Thanks,
Diane

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

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

org-mode-doc depends on no packages.

org-mode-doc recommends no packages.

Versions of packages org-mode-doc suggests:
ii  elpa-org [org-mode]  9.5.2+dfsh-4

-- no debconf information

Bug#1016876: netkit-telnetd: missing Conflicts: telnetd-ssl

[Andreas Beckmann]

Package: netkit-telnetd
Version: 0.17-46
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'sid' to 'experimental'.
It installed fine in 'sid', then the upgrade to 'experimental' fails
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.
This error may also be triggered by having a predecessor package from
'sid 'installed while installing the package from 'experimental'.

See policy 7.6 at
https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces

>From the attached log (scroll to the bottom...):

  Preparing to unpack .../netkit-telnetd_0.17-46_amd64.deb ...
  Unpacking netkit-telnetd (0.17-46) ...
  dpkg: error processing archive 
/var/cache/apt/archives/netkit-telnetd_0.17-46_amd64.deb (--unpack):
   trying to overwrite '/usr/lib/telnetlogin', which is also in package 
telnetd-ssl 0.17.41+0.2-3.3+b1
  Errors were encountered while processing:
   /var/cache/apt/archives/netkit-telnetd_0.17-46_amd64.deb

These files are in conflict:
usr/lib/telnetlogin
usr/sbin/in.telnetd
usr/share/man/man5/issue.net.5.gz
usr/share/man/man8/in.telnetd.8.gz
usr/share/man/man8/telnetlogin.8.gz

telnetd-ssl has a 'Conflicts: telnetd', but that is no longer effective
after the rename to netkit-telnetd.


cheers,

Andreas


telnetd-ssl=0.17.41+0.2-3.3+b1_netkit-telnetd=0.17-46.log.gz
Description: application/gzip

Bug#1016778: timeshift: app from bullseye-backports can't be installed on bullseye

[Boyuan Yang]

Control: tags -1 +confirmed

Caused by compatibility issue with util-linux. For more information, check
out https://bugs.debian.org/992921 and
https://github.com/teejee2008/timeshift/issues/753 .

Thanks,
Boyuan Yang

On Sun, 07 Aug 2022 13:40:56 +0300 =?koi8-r?b?4dLUo80g8MHT2MvP?=
 wrote:
> Package: timeshift
> Version: 22.06.5-1~bpo11+1
> Severity: normal
> 
> kodi@deb:~$ uname -a
> Linux deb 5.10.0-16-amd64 #1 SMP Debian 5.10.127-2 (2022-07-23) x86_64 
> GNU/Linux
> kodi@deb:~$ sudo apt install -t bullseye-backports timeshift
> [sudo] password for kodi:
> Reading package lists... Done
> Building dependency tree... Done
> Reading state information... Done
> The following packages were automatically installed and are no longer 
> required:
>   accountsservice apg appstream apt-config-icons bolt colord-data
>   dns-root-data dnsmasq-base fwupd fwupd-amd64-signed
>   gir1.2-accountsservice-1.0 gir1.2-dazzle-1.0 gir1.2-gck-1 gir1.2-gcr-3
>   gir1.2-gdm-1.0 gir1.2-gmenu-3.0 gir1.2-gnomebluetooth-1.0
>   gir1.2-graphene-1.0 gir1.2-grilo-0.3 gir1.2-handy-0.0 gir1.2-ibus-1.0
>   gir1.2-malcontent-0 gir1.2-mediaart-2.0 gir1.2-mutter-7 gir1.2-nm-1.0
>   gir1.2-nma-1.0 gir1.2-packagekitglib-1.0 gir1.2-polkit-1.0 
> gir1.2-rsvg-2.0
>   gir1.2-upowerglib-1.0 gnome-control-center-data gnome-session-bin
>   gnome-session-common gnome-settings-daemon-common gnome-shell-common
>   gnome-software-common gstreamer1.0-pipewire hyphen-en-us ibus 
> ibus-data
>   ibus-gtk ibus-gtk3 im-config iptables libaccountsservice0 
> libappstream-glib8
>   libappstream4 libbluetooth3 libcolord-gtk1 libcolorhug2 libept1.6.0
>   libflashrom1 libflatpak0 libfreerdp2-2 libftdi1-2 libfuse3-3 libfwupd2
>   libfwupdplugin1 libgail-common libgail18 libgcab-1.0-0 libgdm1
>   libgnome-menu-3-0 libgtk2.0-0 libgtk2.0-bin libgtk2.0-common 
> libibus-1.0-5
>   libip6tc2 libjcat1 libjim0.79 liblzo2-2 libmalcontent-0-0
>   libmalcontent-ui-0-0 libmbim-glib4 libmbim-proxy libmutter-7-0 libndp0
>   libnetfilter-conntrack3 libnfnetlink0 libnm0 libnma-common libnma0
>   libnss-myhostname libntfs-3g883 libostree-1-1 libpipewire-0.3-0
>   libpipewire-0.3-modules libplymouth5 libpulse-mainloop-glib0 
> libqmi-glib5
>   libqmi-proxy libreoffice-help-common libreoffice-help-en-us 
> libsmbios-c2
>   libspa-0.2-modules libteamdctl0 libtss2-esys-3.0.2-0 libtss2-mu0
>   libtss2-sys1 libtss2-tcti-cmd0 libtss2-tcti-device0 
> libtss2-tcti-mssim0
>   libtss2-tcti-swtpm0 libvncserver1 libwinpr2-2 libxapian30 libxcb-res0
>   libxkbcommon-x11-0 libxmlb1 mobile-broadband-provider-info 
> mutter-common
>   mythes-en-us node-normalize.css pipewire pipewire-bin 
> python3-distro-info
>   python3-ibus-1.0 python3-software-properties realmd
>   software-properties-common software-properties-gtk switcheroo-control
>   tpm-udev unattended-upgrades usb-modeswitch usb-modeswitch-data 
> xwayland
> Use 'sudo apt autoremove' to remove them.
> The following additional packages will be installed:
>   fonts-lato gist initscripts insserv inxi libglew2.1 libjs-jquery
>   libmbim-glib4 libmbim-proxy libmm-glib0 libnm0 libqmi-glib5 
> libqmi-proxy
>   libruby2.7 libsystemd0 libudev1 libxapp1 lm-sensors mesa-utils rake 
> rsync



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

Bug#1016873: grub2: enable "http" module for netboot

[Ansgar]

Source: grub2
Version: 2.06-3
Severity: normal
Control: found -1 2.04-20

Hi,

I'm trying to netboot Debian via HTTP (on UEFI). grub2 seems to not
find its grub.cfg and the http server does not see any tried to
download it either.

I only get the grub rescue shell and running "set" shows no network
configurations (no net_* variables are set to something meaningful,
unlike when booting via PXE).

I tried with grubnetx64.efi.signed from both stable and
testing/unstable, chainloaded via shimx64.efi.signed.

Ubuntu's grub has at least the following changes which seem related:

+---
| grub2 (2.06-2ubuntu1) jammy; urgency=medium
|   * Merge from Debian unstable; remaining changes:
| [...]
| - build-efi-images: Add http to netboot images
| [...]
| - Added patches:
| [...]
|   + rhboot-f34-efinet-also-use-the-firmware-acceleration-for-http.patch
+---

The first change should be adding "http" to NET_MODULES in "build-efi-images":

+---
| NET_MODULES="$CD_MODULES
| http
| tftp
| "
+---[ debian/build-efi-images ]

This seems generally useful even when not booting via http.

I'm not sure if the second patch is relevant and what its upstream
status is, but I've attached it
(rhboot-f34-efinet-also-use-the-firmware-acceleration-for-http.patch
extracted from grub2_2.06-2ubuntu7.dsc).  It seems to change various
`net_ls_*` commands to use the EFI version of the command when booted
over http (instead of only when booted over https and opa).

It would be nice if http boot worked.

Ansgar
From: Peter Jones 
Date: Mon, 30 Jul 2018 14:06:42 -0400
Subject: efinet: also use the firmware acceleration for http

Signed-off-by: Peter Jones 

Patch-Name: rhboot-f34-efinet-also-use-the-firmware-acceleration-for-http.patch
---
 grub-core/net/efi/net.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/grub-core/net/efi/net.c b/grub-core/net/efi/net.c
index 9b7a218..b2fe4db 100644
--- a/grub-core/net/efi/net.c
+++ b/grub-core/net/efi/net.c
@@ -1336,7 +1336,9 @@ grub_efi_net_boot_from_https (void)
  && (subtype == GRUB_EFI_URI_DEVICE_PATH_SUBTYPE))
{
  grub_efi_uri_device_path_t *uri_dp = (grub_efi_uri_device_path_t *) 
dp;
- return (grub_strncmp ((const char*)uri_dp->uri, "https://;, sizeof 
("https://;) - 1) == 0) ? 1 : 0;
+ grub_dprintf ("efinet", "url:%s\n", (const char *)uri_dp->uri);
+ return (grub_strncmp ((const char *)uri_dp->uri, "https://;, sizeof 
("https://;) - 1) == 0 ||
+ grub_strncmp ((const char *)uri_dp->uri, "http://;, sizeof 
("http://;) - 1) == 0);
}
 
   if (GRUB_EFI_END_ENTIRE_DEVICE_PATH (dp))

Bug#1014720: FTBFS: test failure in t/update_mirror.t

[gregor herrmann]

On Mon, 08 Aug 2022 18:12:44 +0200, Lukas Märdian wrote:

> I think using the newer version of liburi-perl (using libregexp-ipv6-perl
> dependency) is just hiding the actuall issue.

[…]

Thanks!

Applied and uploaded.
 

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


signature.asc
Description: Digital Signature

Bug#1016803: [Pkg-utopia-maintainers] Bug#1016803: Generates unusable resolv.conf

[Michael Biebl]

Control: tags -1 + moreinfo
Am 07.08.22 um 19:22 schrieb Mark Brown:

Package: network-manager
Version: 1.30.6-1+deb11u1
Severity: important

On one of my systems whenever network-manager connects to a WiFi
network it generates an unusable resov.conf:

# Generated by NetworkManager
search example.org

Other devices on the same network manage to acquire a sensible
nameserver from DHCP, and this has manifested on every network
I've tried with recently.  The networks are set to use automatic
network configuration and DNS for both IPv4 and IPv6, and
resolv.conf does get updated automatically.  Setting an explicit
DNS server does generate a useful network configuration.


Can you provide the .(nm)connection file which shows this behaviour 
(make sure to redact any PSKs)?


They are stored in /etc/NetworkManager/system-connections

A debug log showing the problem would be helpful as well.
For that run
NetworkManager --log-level=DEBUG --debug





OpenPGP_signature
Description: OpenPGP digital signature

Bug#1014720: FTBFS: test failure in t/update_mirror.t

[Lukas Märdian]

Package: libcpan-mini-inject-perl
Version: 0.35-4
Followup-For: Bug #1014720
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu kinetic ubuntu-patch
X-Debbugs-Cc: sl...@ubuntu.com
Control: tags -1 patch

Hi Gregor,

I think using the newer version of liburi-perl (using libregexp-ipv6-perl
dependency) is just hiding the actuall issue.

In Ubuntu we dropped liburi-perl's libregexp-ipv6-perl dependency back to a
Suggests and this issue reappeared. After some investigation, I found an error
in the DIE signal handling of libcpan-mini-inject-perl (in t/update_mirror.t).

See https://github.com/AndyA/CPAN--Mini--Inject/pull/26 for more details.

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

  * d/p/ignore-die-in-eval.patch: Fix test failure if Regexp::IPv6 is missing
(LP: #1981608)

Thanks for considering the patch.


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

Kernel: Linux 5.15.0-40-generic (SMP w/4 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru libcpan-mini-inject-perl-0.35/debian/patches/ignore-die-in-eval.patch 
libcpan-mini-inject-perl-0.35/debian/patches/ignore-die-in-eval.patch
--- libcpan-mini-inject-perl-0.35/debian/patches/ignore-die-in-eval.patch   
1970-01-01 01:00:00.0 +0100
+++ libcpan-mini-inject-perl-0.35/debian/patches/ignore-die-in-eval.patch   
2022-08-08 17:37:52.0 +0200
@@ -0,0 +1,20 @@
+Description: Ignore DIE signal inside eval blocks
+ The process will still be running and the error handled.
+ See: https://www.perlmonks.org/?node_id=1173708
+Author: Lukas Märdian 
+Forwarded: https://github.com/AndyA/CPAN--Mini--Inject/pull/26
+---
+--- libcpan-mini-inject-perl-0.35.orig/t/update_mirror.t
 libcpan-mini-inject-perl-0.35/t/update_mirror.t
+@@ -24,7 +24,10 @@ my $pid= $server->background;
+ ok( $pid, 'HTTP Server started' );
+ sleep 1;
+ 
+-$SIG{__DIE__} = sub { kill( 9, $pid ) };
++$SIG{__DIE__} = sub {
++  return if $^S; # ignore die in an eval block, while process is still running
++  kill( 9, $pid )
++};
+ 
+ my $mcpi = CPAN::Mini::Inject->new;
+ $mcpi->parsecfg( 't/.mcpani/config' );
diff -Nru libcpan-mini-inject-perl-0.35/debian/patches/series 
libcpan-mini-inject-perl-0.35/debian/patches/series
--- libcpan-mini-inject-perl-0.35/debian/patches/series 1970-01-01 
01:00:00.0 +0100
+++ libcpan-mini-inject-perl-0.35/debian/patches/series 2022-08-08 
17:37:52.0 +0200
@@ -0,0 +1 @@
+ignore-die-in-eval.patch

Bug#1016806: request-tracker5: FTBFS with Perl 5.36: Subroutine JSON::PP::Boolean::(0+ redefined

[Niko Tyni]

Control: reassign -1 libcpanel-json-xs-perl 4.30-1
Control: affects -1 request-tracker5

On Mon, Aug 08, 2022 at 12:21:17AM +0200, gregor herrmann wrote:
> On Sun, 07 Aug 2022 21:09:49 +0300, Niko Tyni wrote:

> ># Subroutine JSON::PP::Boolean::(++ redefined at 
> > /usr/lib/x86_64-linux-gnu/perl-base/overload.pm line 52.
> >#  at /usr/lib/x86_64-linux-gnu/perl-base/overload.pm line 52.
> >#overload::OVERLOAD("JSON::PP::Boolean", "0+", 
> > CODE(0x561a9651eee0), "++", CODE(0x561a9651ef40), "--", 
> > CODE(0x561a9651efd0), "\"\"", ...) called at 
> > /usr/lib/x86_64-linux-gnu/perl-base/overload.pm line 61
> >#overload::import("overload", "0+", CODE(0x561a9651eee0), "++", 
> > CODE(0x561a9651ef40), "--", CODE(0x561a9651efd0), "\"\"", ...) called at 
> > /usr/lib/x86_64-linux-gnu/perl5/5.36/Cpanel/JSON/XS.pm line 2365
> >#Cpanel::JSON::XS::BEGIN() called at 
> > /usr/lib/x86_64-linux-gnu/perl5/5.36/Cpanel/JSON/XS.pm line 2366
> 
> Could this be https://github.com/rurban/Cpanel-JSON-XS/issues/198 in
> libcpanel-json-xs-perl?

Thanks! That bug didn't exist when I last looked :)

It's not quite the same thing but certainly looks related. I get the
overload warnings even with the older libjson-pp-perl bundled with
Perl 5.36:

  % perl -we 'use Cpanel::JSON::XS (); use JSON::PP ()'
  Subroutine JSON::PP::Boolean::(-- redefined at 
/usr/lib/x86_64-linux-gnu/perl-base/overload.pm line 52.
  Subroutine JSON::PP::Boolean::(0+ redefined at 
/usr/lib/x86_64-linux-gnu/perl-base/overload.pm line 52.
  Subroutine JSON::PP::Boolean::(++ redefined at 
/usr/lib/x86_64-linux-gnu/perl-base/overload.pm line 52.

Reassigning. I assume Cpanel-JSON-XS is the place that needs a fix.
-- 
Niko

Bug#1015254: transition: opencascade

[Graham Inggs]

Hi Tobi

On Sat, 6 Aug 2022 at 18:51, Tobias Frost  wrote:
> I'd suggest to start binNMU freecad

freecad is not in testing, and requires a source-only upload because
of the arch:all binaries uploaded by the last uploader.
Also, #1007013 and #1014875 need fixing.

> and maybe then proceed to remove netgen together with gmsh and deal.ii 
> temporarily from testing.
> (the later two need an updated netgen…)

deal.ii was removed from testing due to a collision with glibc 2.34.
There are some reverse dependencies of netgen and gmsh, so I'd prefer
to wait for auto-removal, and hopefully one of those maintainers steps
up with a fix for netgen in the meantime.

Regards
Graham

Bug#1016863: libreoffice: Bad performance especially when dealing with pictures

[Rene Engelhard]

tag 1016863 + moreinfo

found 1016863 1:7.0.4-4+deb11u1

thanks


Hi,

Am 08.08.22 um 14:10 schrieb Matteo A.:

Package: libreoffice
Not libreoffice-gtk3 as you say yourself it seems to be in -gtk3 since 
it goes away when removing -gtk3?

Severity: important
X-Debbugs-Cc: non.mi.ricordo...@gmail.com

Dear Maintainer,

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

* What led up to the situation? Installing the package libreoffice-gtk3.
* What exactly did you do (or not do) that was effective (or
  ineffective)? Uninstalling the package libreoffice-gtk3 seems to solve the
problem.
* What was the outcome of this action? Libreoffice looks really bad, but
performs well. Also installing libreoffice-qt5 the look doesn't change.
* What outcome did you expect instead?


This doesn't say anything abou what the problem is. This is only in the 
subject of the mail. Repeating it would make the mail actually 
understandable...



For reference: "ibreoffice: Bad performance especially when dealing with 
pictures"



Now the problem still is that this is pretty subjective and depending on 
your hardware. And this is stable and not release-critical nor a 
security bug so anything here will live as long as stable exists 
(especially like this when  there is NO other information  than "slow 
with -gtk3").



Can you try with some newer upstream versions? backports has 7.3.5 (and 
will, though maybe only with 7.4.1, didn't decide yet) get 7.4 soonish...



And:


Kernel: Linux 5.10.0-16-amd64 (SMP w/2 CPU threads)


Dual-core CPU? Maybe time to get some new hardware?


Regards,


Rene

Bug#1016871: transition: dpdk

[Luca Boccassi]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
X-Debbugs-CC: z...@debian.org bott...@debian.org 
team+colle...@tracker.debian.org pkg-dpdk-de...@lists.alioth.debian.org

Dear Release Team,

The new DPDK 21.11 LTS is ready for unstable/testing, and we wish to
begin the transition. It was already uploaded to experimental:

https://tracker.debian.org/pkg/dpdk

The reverse dependencies are collectd, uhd and openvswitch:

https://tracker.debian.org/pkg/collectd
https://tracker.debian.org/pkg/uhd
https://tracker.debian.org/pkg/openvswitch

src:collectd currently suffers from an unrelated FTBFS:

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

With a local workaround for that, it builds fine with the new src:dpdk,
so I don't think it should block the transition.

src:uhd rebuilds without any changes. 

src:openvswitch needs a new version, and thus its reverse dep src:ovn
needs one too, which we already uploaded to experimental and are ready
for unstable.

Auto-transition page:

https://release.debian.org/transitions/html/auto-dpdk.html

Thank you!

-- 
Kind regards,
Luca Boccassi


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

Bug#1015132: meson: FTBFS: test_junit_valid_gtest: Element 'testcase', attribute 'file': The attribute 'file' is not allowed

[Simon McVittie]

Control: retitle -1 meson: FTBFS: test_junit_valid_gtest: Element 'testcase', 
attribute 'file': The attribute 'file' is not allowed
Control: forwarded -1 https://github.com/mesonbuild/meson/pull/10634
Control: tags -1 + patch upstream

On Sat, 16 Jul 2022 at 20:55:02 +0200, Lucas Nussbaum wrote:
> The script I use to extract the failure from the log might have guessed
> badly indeed, however the build still fails
...
> However looking at the log I don't really understand why the
> override_dh_auto_test target fails.

I think it's probably this:

>debian/rules override_dh_auto_test
> make[1]: Entering directory '/<>'
> ./run_tests.py
...
> FAIL: test_junit_valid_gtest (unittests.allplatformstests.AllPlatformTests)
> --
> Traceback (most recent call last):
>   File "/<>/unittests/allplatformstests.py", line 3382, in 
> _test_junit
> schema.assertValid(junit)
>   File "src/lxml/etree.pyx", line 3638, in lxml.etree._Validator.assertValid
> lxml.etree.DocumentInvalid: Element 'testcase', attribute 'file': The 
> attribute 'file' is not allowed., line 3
> 
> During handling of the above exception, another exception occurred:
> 
> Traceback (most recent call last):
>   File "/<>/unittests/allplatformstests.py", line 3393, in 
> test_junit_valid_gtest
> self._test_junit(os.path.join(self.framework_test_dir, '2 gtest'))
>   File "/<>/unittests/allplatformstests.py", line 3384, in 
> _test_junit
> self.fail(e.error_log)
> AssertionError: 
> /<>/tmp30xzcj0v/meson-logs/testlog.junit.xml:3:0:ERROR:SCHEMASV:SCHEMAV_CVC_COMPLEX_TYPE_3_2_1:
>  Element 'testcase', attribute 'file': The attribute 'file' is not allowed.
> /<>/tmp30xzcj0v/meson-logs/testlog.junit.xml:3:0:ERROR:SCHEMASV:SCHEMAV_CVC_COMPLEX_TYPE_3_2_1:
>  Element 'testcase', attribute 'line': The attribute 'line' is not allowed.
> /<>/tmp30xzcj0v/meson-logs/testlog.junit.xml:4:0:ERROR:SCHEMASV:SCHEMAV_CVC_COMPLEX_TYPE_3_2_1:
>  Element 'testcase', attribute 'file': The attribute 'file' is not allowed.
> /<>/tmp30xzcj0v/meson-logs/testlog.junit.xml:4:0:ERROR:SCHEMASV:SCHEMAV_CVC_COMPLEX_TYPE_3_2_1:
>  Element 'testcase', attribute 'line': The attribute 'line' is not allowed.
> /<>/tmp30xzcj0v/meson-logs/testlog.junit.xml:7:0:ERROR:SCHEMASV:SCHEMAV_CVC_COMPLEX_TYPE_3_2_1:
>  Element 'testcase', attribute 'file': The attribute 'file' is not allowed.
> /<>/tmp30xzcj0v/meson-logs/testlog.junit.xml:7:0:ERROR:SCHEMASV:SCHEMAV_CVC_COMPLEX_TYPE_3_2_1:
>  Element 'testcase', attribute 'line': The attribute 'line' is not allowed.
> /<>/tmp30xzcj0v/meson-logs/testlog.junit.xml:8:0:ERROR:SCHEMASV:SCHEMAV_CVC_COMPLEX_TYPE_3_2_1:
>  Element 'testcase', attribute 'file': The attribute 'file' is not allowed.
> /<>/tmp30xzcj0v/meson-logs/testlog.junit.xml:8:0:ERROR:SCHEMASV:SCHEMAV_CVC_COMPLEX_TYPE_3_2_1:
>  Element 'testcase', attribute 'line': The attribute 'line' is not allowed.
...
> Ran 471 tests in 629.165s
> 
> FAILED (failures=1, skipped=59)

Ubuntu's meson package has this change vs. Debian which is probably the
solution:

  * googletest 1.12.1 started to emit additional JUnit4 schema invalid
testcase attributes, delete them when generating meson junit test
result. Fixing FTBFS with new googletest.

which seems to be the same change they sent upstream as
.

Ubuntu's meson package also applies patches to fix the regression #1014417.
http://launchpadlibrarian.net/614996822/meson_0.63.0-1_0.63.0-1ubuntu3.diff.gz

smcv

Bug#1016845: warn users about insecure webkit* packages

[Moritz Muehlenhoff]

On Mon, Aug 08, 2022 at 11:07:16AM +, Holger Levsen wrote:
> so, for bookworm, we should add 
> 
> - qtwebkit-opensource-src
> - qtwebengine-opensource-src
> 
> to security-support-limited ("only for trusted content") and that's it?

I think so, yes.

Cheers,
Moritz

Bug#1014473: vcswatch: track identity of committers of unuploaded commits

[Christoph Berg]

Re: To Jelmer Vernooij
> Does that work? I guess we could try extracting the authors
> (committers?) into a proper json structure if that helps.
> 
> Helmut was approaching me about extracting even more fields from git,
> Maintainer, Uploaders, Homepage, updated Vcs info, debian/watch, and
> expose that for an easier feedback into the packages file without
> requiring new uploads. That will likely happen shortly. (Mentioning
> that here since it seems similar.)

Fwiw, that has happened at DebConf, there is now new fields
"controlfile" and "upstream_metadata" in the json:

  {
"browser": "https://salsa.debian.org/debian/kanyremote;,
"vcslog": "commit 2461c1171fc9103e2fd9ec946208fe5e1bc2deb7\nAuthor: Philipp 
Huebner \n
Date:   Sat May 28 00:32:06 2022 +0200\n\nUpdated years in 
debian/copyright\n\ncommit a72ff16979f78545d0eb83
09370e47782536e4fd\nAuthor: Debian Janitor \nDate:   Fri Sep 
24 05:04:54 2021 +\n\nRe
move obsolete field Name from debian/upstream/metadata (already present in 
machine-readable debian/copyright).\n
\nChanges-By: lintian-brush\n\ncommit 
77bcda14a9bc556ecc7d5029ddf82282ff0c3303\nAuthor: Debian Janitor <
jani...@jelmer.uk>\nDate:   Fri Sep 24 05:04:43 2021 +\n\nTrim trailing 
whitespace.\n\nChanges-B
y: lintian-brush\nFixes: lintian: trailing-whitespace\nSee-also: 
https://lintian.debian.org/tags/trailin
g-whitespace.html",
"ci_url": "https://salsa.debian.org/debian/kanyremote/-/pipelines;,
"last_scan": "2022-08-04 18:18:12+00",
"issues": null,
"url": "https://salsa.debian.org/debian/kanyremote.git;,
"valid_checkout": 1,
"changelog_version": "8.1-1.2",
"watchfile": 
"version=4\nhttps://sf.net/anyremote/kanyremote-(.*)\\.tar\\.gz",
"package": "kanyremote",
"changelog_distribution": "UNRELEASED",
"branch": "master",
"merge_requests": 1,
"vcs": "Git",
"dumb_http": null,
"controlfile": "Source: kanyremote\nSection: kde\nPriority: 
optional\nMaintainer: Philipp Huebner \nBuild-Depends: debhelper-compat (= 13), dh-python, 
python3-all\nStandards-Version: 4.5.1\nRules-Re
quires-Root: no\nHomepage: http://anyremote.sourceforge.net\nVcs-Git: 
https://salsa.debian.org/debian/kanyremote
.git\nVcs-Browser: https://salsa.debian.org/debian/kanyremote\n\nPackage: 
kanyremote\nArchitecture: all\nDepends
: ${misc:Depends},\n ${python3:Depends},\n anyremote (>= 
6.7),\n python3-bluez (>= 0.9.1
),\n python3-pyqt5\nRecommends: bluez\nDescription: KDE frontend for 
anyRemote\n kAnyRemote package is K
DE GUI frontend for anyRemote.\n (http://anyremote.sourceforge.net/). The 
overall goal of this project is to\n p
rovide remote control service on Linux through Bluetooth, InfraRed, Wi-Fi\n or 
TCP/IP connection.",
"edited_at": null,
"edited_by": null,
"hash": "2461c1171fc9103e2fd9ec946208fe5e1bc2deb7",
"debian_dir": 1,
"changelog": "kanyremote (8.1-1.2) UNRELEASED; urgency=medium\n\n  * Trim 
trailing whitespace.\n  * Remove o
bsolete field Name from debian/upstream/metadata (already present in\n
machine-readable debian/copyright).\n\
n -- Debian Janitor   Fri, 24 Sep 2021 05:04:43 -",
"next_scan": "2022-08-12 12:11:00+00",
"commits": 3,
"package_version": "8.1-1.1",
"ci_status": null,
"status": "NEW",
"upstream_metadata": "Bug-Database: 
https://sourceforge.net/p/anyremote/discussion/\nBug-Submit: 
https://sourceforge.net/p/anyremote/discussion/\nChangelog: 
https://sourceforge.net/p/anyremote/code/HEAD/tree/kanyremote/trunk/ChangeLog\nRepository:
 svn://svn.code.sf.net/p/anyremote/code/kanyremote/trunk\nRepository-Browse: 
https://sourceforge.net/p/anyremote/code/HEAD/tree/kanyremote/\nRegistration: 
https://sourceforge.net/user/registration\nContact: 
anyrem...@mail.ru\nDocumentation: 
http://anyremote.sourceforge.net/docs.html\nFAQ: 
http://anyremote.sourceforge.net/faq.html;,
"avatar": 
"https://salsa.debian.org/uploads/-/system/project/avatar/1272/anyremote.png;,
"tag": "debian/8.1-1.1",
"error": null
  },

Christoph

Bug#1010469: [pkg-lxc-devel] Bug#1010469: Bug#1010437: autopkgtest: autopkgtest-build-lxc fails to build working lxc environment

[Julian Gilbey]

On Mon, Aug 01, 2022 at 10:44:16PM +0200, Pierre-Elliott Bécue wrote:
> Julian Gilbey  wrote on 08/06/2022 at 10:50:18+0200:
> 
> > notfixed 1010469 1:4.0.11-1
> > thanks
> >
> >> I decided to reinstall my system from scratch, and now this bug has
> >> gone away.  So as no-one else could reproduce it and I have no idea
> >> what has changed on my system as a result of reinstalling, I'm closing
> >> it with an "unreproducible" tag.
> >
> > Oh dear, oh dear, oh dear.  It's just happened again.
> >
> > I am so completely stumped by this one.
> 
> What apparmor profile are you trying to run your container with?

Dear Pierre-Elliott,

I'm not sure which profile I'm using; I just installed lxc and am
using whatever the default is.

Looking at /var/lib/lxc/containername/config, I see the lines:

lxc.apparmor.profile = generated
lxc.apparmor.allow_nesting = 1

which hopefully means something to you!

Best wishes,

   Julian

Bug#1016868: libc6-udeb: dangling ld-linux symlink

[Cyril Brulebois]

Package: libc6-udeb
Version: 2.34-1
Severity: grave
Justification: renders package unusable
X-Debbugs-Cc: debian-b...@lists.debian.org

Hi,

Checking fil's report regarding runtime issues related to libc6-udeb,
which I thought to be a major version mismatch (d-i built against
unstable from a few hours ago = 2.33, but running against current
unstable = 2.34), I ended up with a fresh build that doesn't boot:
failure to execute /init.

Smallest bisection ever:
 - Building d-i against testing's udebs fixes it.
 - There are only a handful of differences… picking one “at random”.
 - Building d-i against testing's udebs except libc6-udeb from unstable
   generates the problem.

To get the booting issue out of the way, I've verified that I was able
to start busybox from the build tree after a netboot build against
testing's udebs, using this:

cd build/tmp/netboot/tree
sudo chroot . /bin/busybox sh

That's not the case after a build against unstable's udebs. Of course,
strace cannot report much:

chroot(".") = 0
chdir("/")  = 0
execve("bin/busybox", […])  = -1 ENOENT (No such file or 
directory)

Looking at the contents of the udebs before/after, a number of files and
symlinks are different, and there's one missing piece:

 - before:

./lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 -> ld-2.33.so
./lib64/ld-linux-x86-64.so.2 -> /lib/x86_64-linux-gnu/ld-2.33.so

 - after:

./lib64/ld-linux-x86-64.so.2 -> /lib/x86_64-linux-gnu/ld-linux-x86-64.so.2

Thanks to Aurélien for investigating at the same time as I did, and for
the upcoming fix!


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant

Bug#1016848: librecast: unknown section 'unknown'

[Vagrant Cascadian]

Control: tags 1016848 pending

On 2022-08-08, Graham Inggs wrote:
> Source: librecast
> Version: 0.5.1-2
> Severity: serious
>
> Hi Maintainer
>
> debian/control contains:
>
> Section: unknown

This was fixed in git a couple days ago:

  
https://salsa.debian.org/vagrant/librecast/-/commit/3d1f704693c1bdefc8bc440ee360de5a10932fcf

live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1012245: nvidia-graphics-drivers-tesla-470: fails on ppc64el due to transitive GPL symbol usage

[Andreas Beckmann]

On Sun, 26 Jun 2022 15:26:07 +0200 Andreas Beckmann  wrote:

I've temporarily disabled the autopkgtest on ppc64el.


That seems to be a kernel specific issue and appears to be fixed with 
Linux 5.19 in experimental (but is still reproducible in Linux 5.18).

Re-enabling the autopkgtests on ppc64el.

Andreas

Bug#1016869: RFP: git-machete -- manage sets of related git branches

[David Bremner]

Package: wnpp
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

* Package name: git-machete
  Version : 3.11.4
  Upstream Author : Virtus Lab 
* URL : https://github.com/VirtusLab/git-machete
* License : MIT
  Programming Lang: python3
  Description : manage sets of related git branches

git-machete is a robust tool that simplifies your git workflows.

The bird's eye view provided by git-machete makes
merges/rebases/push/pulls hassle-free even when multiple branches are
present in the repository (master/develop, your topic branches,
teammate's branches checked out for review, etc.).

Using this tool, you can maintain small, focused, easy-to-review pull
requests with little effort.

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEkiyHYXwaY0SiY6fqA0U5G1WqFSEFAmLxHtAACgkQA0U5G1Wq
FSHDUQ//ewxzbdpjWJZndocNlv5DdhEInm5/PUlMssJPwTl5A8AhKPYk7R8z+bwn
4rlckdjG+c1lLUgRdkYuoMiaIHgRJUJeDpI5+XkqR3ROZfGmBDqgzQxXduCGO8tT
XiuVHy9CYIRylSyacLe5T0i8Lt8E0/+MLbCpWSm+4QpIBZzkNLTwYz+EFqvYsrIF
Sfba22JHctHzOoNh0GDpaBqJLX5G2yLgvckdOwdODTBod3Ha6oUdYCQXB76gPnyi
u2+B0SU9llP8mXwsR3O7x2f0M7pemxlJ/GCssCoc2SWIQd4dbhCjHdCWhFB9/GHf
x2ZgxIBA0kFIHkrPBrWNbLw7e5yWDegr9rsKNn/aRf9jZgI5c4kTrlEwcfRPgpS6
TtAAIJLMkUHHCVG04JRqaLNDI0VgD+woyHjP7MmhG/KCj7BfN/kMHJcLo00LgyPt
vbqKg7e78uRAMPq0TSOPtL73TR4wxmtVNfNbUREoN6IQhVqu/+49Dhd4KT93+G/B
3NB44cfuDXJPLuNWBK3PoL3tK1xeyCBz6e7FCg90L6cSZmBaca0QI9o7M8ja3Pmr
KYkzioK643x9vuZPSMvm/VXiRNEpyrgo8Pt0xl/lRuOEHMga0pd86tDXhlaTHVga
QOZNaUMiDsRbJcxsj3MHmH4d8ABBgA4FKh08bSfHDN4zBr7WUPQ=
=o2+4
-END PGP SIGNATURE-

Bug#1012547: linux: disable user namespaces per default

[Philippe Cerfon]

Apparently it's already Christmas:

The next two holes that likely allow privilege escalation and that
would have been mitigated by unprivileged user namespaces being
disabled:
 CVE-2022-1015, CVE-2022-1016

Cheers,
Phiippe

Bug#1016867: RFS: libnl3/3.7.0-0.1 [NMU] -- library for dealing with netlink sockets - generic netlink

[Matthieu Baerts]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: libnl3
   Version : 3.7.0-0.1
   Upstream Author : Thomas Haller 
 * URL : https://github.com/thom311/libnl
 * License : LGPL-2.1 License
 * Vcs : /
   Section : net

The source builds the following binary packages:

  libnl-3-200 - library for dealing with netlink sockets
  libnl-cli-3-200 - library for dealing with netlink sockets - cli helpers
  libnl-utils - Utilities for dealing with netlink sockets
  libnl-genl-3-200 - library for dealing with netlink sockets - generic
netlink
  libnl-idiag-3-200 - library for dealing with netlink sockets -
inetdiag interface
  libnl-nf-3-200 - library for dealing with netlink sockets - netfilter
interface
  libnl-route-3-200 - library for dealing with netlink sockets - route
interface
  libnl-xfrm-3-200 - library for dealing with netlink sockets - package
transformations
  libnl-3-dev - development library and headers for libnl-3
  libnl-cli-3-dev - development library and headers for libnl-cli-3
  libnl-genl-3-dev - development library and headers for libnl-genl-3
  libnl-idiag-3-dev - development library and headers for libnl-genl-3
  libnl-nf-3-dev - development library and headers for libnl-nf-3
  libnl-route-3-dev - development library and headers for libnl-route-3
  libnl-xfrm-3-dev - development library and headers for libnl-xfrm-3
  libnl-3-200-dbg - debug symbols for libnl3
  libnl-3-200-udeb - library for dealing with netlink sockets
  libnl-genl-3-200-udeb - library for dealing with netlink sockets -
generic netlink

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

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

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

  dget -x
https://mentors.debian.net/debian/pool/main/libn/libnl3/libnl3_3.7.0-0.1.dsc

Changes since the last upload:

 libnl3 (3.7.0-0.1) unstable; urgency=low
 .
   * Non-maintainer upload (Closes: #1016485)
   * Again for this NMU, modifications have been limited to:
 - Symbols have been updated
 - Patches have been refreshed

Like for the previous NMU upload I did for this package that seems no
longer maintained, I did the minimal changes. I contacted the maintainer
a week ago and I didn't get any replies. Please note that for the
previous update (v3.5.0), I didn't have any replies from the official
maintainer even after one year, see ticket #983310. Also, I didn't
notified the MIA like I did last time because I guess there is no need
to insist but feel free to tell me if this is still needed.

The last version in Debian is the v3.5.0 while the latest upstream
one -- v3.7.0 -- has been one month ago, a few months after the v3.6.0.

This lib is used by a bunch of apps to communicate with the Linux
kernel. The 3.7.0 version adds some new features but it also fixes bugs.
libnl devs don't seem to maintain any stable branches for this project.

This packages has a few lintian issues but if I'm not mistaken, no new
ones compared to the previous version. Because it is a NMU and the
situation is unclear with the official maintainer, these old lintian
issues have not been addressed.

Thank you for your help and your contributions to Debian!

Cheers,
Matt
-- 
Tessares | Belgium | Hybrid Access Solutions
www.tessares.net

Bug#1016843: apt: should probably use "sop" for OpenPGP

[Julian Andres Klode]

Control: tag -1 moreinfo

On Mon, Aug 08, 2022 at 01:54:16PM +0300, Lars Wirzenius wrote:
> Package: apt
> Severity: wishlist
> 
> Currently apt is using gpgv to verify Release.gpg files. It would
> probably be a good idea to use an implemenation of the SOP interface
> instead. SOP is short for "stateless OpenPGP", and it's a
> specification by Daniel Kahn Gillmor (dkg). See
> 
> https://datatracker.ietf.org/doc/draft-dkg-openpgp-stateless-cli/
> 
> There are many implementations of that, including one for GnuPG.
> Having a consistent interface makes it easier to switch to a different
> implementation. The OpenPGP Interoperabiolity Test Suite
> (https://tests.sequoia-pgp.org/) uses this.

It's a draft and to my knowledge there are no suitable implementations
yet?

> 
> If APT used SOP, it could even allow a sysadmin to choose what
> implementation they want. This would free apt from being locked into
> GnuPG without abandoning OpenPGP entirely.

APT must Depend on the default backend and we must make sure that
this dependency is not satisfiable by other packages. Any non-default
backend must be explicit configuration via config files, otherwise
the risk of breaking updates due to implementation-specific bugs is
just too great.

I want to phase out OpenPGP and do not see the point in undertaking
this work. This will likely introduce several CVEs, and still involves
spawning subprocesses and parsing their output which is the thing
that we want to get rid of in the first place.

-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer  i speak de, en


signature.asc
Description: PGP signature

Bug#960396: web security flaws in src:adminer/4.7.1-1 in stable?

[Alexandre Rossi]

Hi,

> > > We're in the process of arranging the final point release for
> > > buster,
> > > as support for it moves to the new LTS team.
> > > 
> > > Is this something you're still interested in updating in buster?
> > 
> > Yes, I even still have the built package ready for upload on
> > mentors.d.o .
> > 
> 
> In that case please feel free to get it uploaded, bearing in mind the
> time constraints mentioned.

After REJECTED (signature too old), debsign, REJECTED (not allowed as DM),
the source upload is awaiting comments or sponsorship at mentors.d.o .

https://mentors.debian.net/package/adminer/
https://mentors.debian.net/debian/pool/main/a/adminer/adminer_4.7.1-1+deb10u1.dsc

Any issues, do not hesitate to come back to me.

Many Thanks,

Alexandre

Bug#1016866: ITP: ngx-lua -- Lua module for Nginx

[Jérémy Lal]

Le lun. 8 août 2022 à 14:33, Jan Mojzis  a écrit :

> Package: wnpp
> Severity: wishlist
> Owner: Jan Mojzis 
> X-Debbugs-Cc: debian-de...@lists.debian.org
>
> * Package name: ngx-lua
>   Version : 0.10.21
>   Upstream Author : Yichun Zhang (agentzh) 
> * URL : https://github.com/openresty/lua-nginx-module
> * License : BSD-2-clause
>   Programming Lang: (C, Lua)
>   Description : Lua module for Nginx
>
>
> Lua module is currently a part of Debian Nginx package.
>
> I would like to move the module to the separate package ngx-lua.
>
>
> I would like to maintain the package using https://salsa.debian.org/
> Currently is the Debian package maintained here
> https://salsa.debian.org/janmojzis/ngx-lua
>
> I need sponsor only for the first upload (I'm DM).
>

I can sponsor this if needed.

Bug#1016866: ITP: ngx-lua -- Lua module for Nginx

[Jan Mojzis]

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

* Package name: ngx-lua
  Version : 0.10.21
  Upstream Author : Yichun Zhang (agentzh) 
* URL : https://github.com/openresty/lua-nginx-module
* License : BSD-2-clause
  Programming Lang: (C, Lua)
  Description : Lua module for Nginx


Lua module is currently a part of Debian Nginx package.

I would like to move the module to the separate package ngx-lua.


I would like to maintain the package using https://salsa.debian.org/
Currently is the Debian package maintained here 
https://salsa.debian.org/janmojzis/ngx-lua

I need sponsor only for the first upload (I'm DM).
Thank You!

Bug#1011456: ipv6toolkit: Update the package

[Sophie Brun]

Hello,

Le 05/08/2022 à 19:19, Octavio Alvarez a écrit :


Thanks for bringing this up. Upstream should make a release soon and I will 
update Debian's package asap. This should bring Debian's up to par or ahead of 
Kali's so Kali's could be reliably dropped after that.


Great! Thanks for the information.


My only worry is the shebang patch you have [3] which reverts Upstream's [4] 
for issue [5]. If I follow Upstream, this change would be dropped. Is this OK 
with you?


It's Ok. No problem for Kali.

Thank you
Sophie

Bug#1016863: libreoffice: Bad performance especially when dealing with pictures

[Matteo A.]

Package: libreoffice
Severity: important
X-Debbugs-Cc: non.mi.ricordo...@gmail.com

Dear Maintainer,

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

   * What led up to the situation? Installing the package libreoffice-gtk3.
   * What exactly did you do (or not do) that was effective (or
 ineffective)? Uninstalling the package libreoffice-gtk3 seems to solve the
problem.
   * What was the outcome of this action? Libreoffice looks really bad, but
performs well. Also installing libreoffice-qt5 the look doesn't change.
   * What outcome did you expect instead?

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


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

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

Versions of packages libreoffice-core depends on:
ii  fontconfig  2.13.1-4.2
ii  fonts-opensymbol2:102.11+LibO7.0.4-4+deb11u1
ii  libboost-locale1.74.0   1.74.0-9
ii  libc6   2.33-6
ii  libcairo2   1.16.0-5
ii  libclucene-contribs1v5  2.3.3.4+dfsg-1+b1
ii  libclucene-core1v5  2.3.3.4+dfsg-1+b1
ii  libcmis-0.5-5v5 0.5.2-3
ii  libcups22.3.3op2-3+deb11u2
ii  libcurl3-gnutls 7.74.0-1.3+deb11u2
ii  libdbus-1-3 1.12.20-2
ii  libdconf1   0.38.0-2
ii  libeot0 0.01-5+b1
ii  libepoxy0   1.5.5-1
ii  libexpat1   2.2.10-2+deb11u3
ii  libexttextcat-2.0-0 3.4.5-1
ii  libfontconfig1  2.13.1-4.2
ii  libfreetype62.10.4+dfsg-1+deb11u1
ii  libgcc-s1   10.2.1-6
ii  libglib2.0-02.66.8-1
ii  libgpgmepp6 1.14.0-1+b2
ii  libgraphite2-3  1.3.14-1
ii  libgstreamer-plugins-base1.0-0  1.18.4-2
ii  libgstreamer1.0-0   1.18.4-2.1
ii  libharfbuzz-icu02.7.4-1
ii  libharfbuzz0b   2.7.4-1
ii  libhunspell-1.7-0   1.7.0-3
ii  libhyphen0  2.8.8-7
ii  libice6 2:1.0.10-1
ii  libicu6767.1-7
ii  libjpeg62-turbo 1:2.0.6-4
ii  liblcms2-2  2.12~rc1-2
ii  libldap-2.4-2   2.4.57+dfsg-3+deb11u1
ii  libmythes-1.2-0 2:1.2.4-3+b1
ii  libneon27-gnutls0.31.2-1
ii  libnspr42:4.29-1
ii  libnss3 2:3.61-1+deb11u2
ii  libnumbertext-1.0-0 1.0.7-1
ii  liborcus-0.16-0 0.16.1-3+b2
ii  liborcus-parser-0.16-0  0.16.1-3+b2
ii  libpng16-16 1.6.37-3
ii  libpoppler102   20.09.0-3.1
ii  libqrcodegencpp11.6.0-1
ii  libraptor2-02.0.14-1.2
ii  librdf0 1.0.17-1.1+b1
ii  libreoffice-common  1:7.0.4-4+deb11u1
ii  librevenge-0.0-00.0.4-6+b1
ii  libsm6  2:1.2.3-1
ii  libstdc++6  10.2.1-6
ii  libuno-cppu31:7.0.4-4+deb11u1
ii  libuno-cppuhelpergcc3-3 1:7.0.4-4+deb11u1
ii  libuno-sal3 1:7.0.4-4+deb11u1
ii  libuno-salhelpergcc3-3  1:7.0.4-4+deb11u1
ii  libx11-62:1.7.2-1
ii  libx11-xcb1 2:1.7.2-1
ii  libxext62:1.3.3-1.1
ii  libxinerama12:1.1.4-2
ii  libxml2 2.9.10+dfsg-6.7+deb11u2
ii  libxmlsec1  1.2.31-1
ii  libxmlsec1-nss  1.2.31-1
ii  libxrandr2  2:1.5.1-1
ii  libxrender1 1:0.9.10-1
ii  libxslt1.1  1.1.34-4
ii  uno-libs-private1:7.0.4-4+deb11u1
ii  ure 1:7.0.4-4+deb11u1
ii  zlib1g  1:1.2.11.dfsg-2+deb11u1

Versions of packages libreoffice-core recommends:
ii  gstreamer1.0-libav 1.18.4-3
ii  gstreamer1.0-plugins-bad   1.18.4-3
ii  gstreamer1.0-plugins-base  1.18.4-2
ii  gstreamer1.0-plugins-good  1.18.4-2
ii  gstreamer1.0-plugins-ugly  1.18.4-2
ii  libpaper-utils 1.1.28+b1

Versions of packages libreoffice-writer depends on:
ii  libabw-0.1-1 0.1.3-1
ii  libc62.33-6
ii  libe-book-0.1-1  0.1.3-2
ii  libepubgen-0.1-1 0.1.1-1
ii  libetonyek-0.1-1 0.1.9-4
ii  libgcc-s110.2.1-6
ii  libicu67  

Bug#1016809: [UEFI] Installed (minimal) bookworm system hangs at boot

[Philip Hands]

Holger Wansing  writes:

> Holger Wansing  wrote (Sun, 7 Aug 2022 21:36:43 +0200):
>> Installing Debian on an UEFI-driven QEMU machine (minimal installation, only
>> standard system task) leads to a successful installation, but the newly 
>> installed system cannot complete its boot process.
>> It hangs forever (here on linux 5.18.0-3) with this messages
>
>
> I wonder why this is not detected by tests on
> https://openqa.debian.net/group_overview/10
> I see there are specific runs for UEFI, so it should be possible to detect
> this?
>
>
> The reason for this is, there are no standard-system-only tests there.

That's true, so I put one together last night, which (on my laptop at least)
seems to work fine, so I guess there's something about your setup that's
different (as kibi & rclobus suggest).

Thanks for pointing out that we were missing such tests, which I'd left
room for, but never got round to finishing off properly.  I just need to
tidy up my patch and then I'll enable some new DESKTOP=textmode tests.

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Bug#1016862: nautilus: SMB shares won't open anymore

[Tobias Koeck]

Package: nautilus
Version: 3.38.2-1+deb11u1
Severity: normal

Dear Maintainer,

Dear Maintainer,

I upgraded the package nautilus and nautilus-share with bullseye-backports.

After that the access to my nas won't work anymore.

I get after trying to access my NAS under 'Other localtions' a general

Unable to access location - Failed to retrieve share list from server:
Invalid argument.

If I try to mount it directly with smb://my.domain.info/share/ I'll get
an

Unable to access locatation - Failed to mount Windows share: Invalid
argument.

It seems to be the case that 'bullseye-backports' have broken something
with Files + Windows Network shares.

Greetings,
Tobias

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

Kernel: Linux 5.18.0-0.bpo.1-amd64 (SMP w/16 CPU threads; PREEMPT)
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)

Versions of packages nautilus depends on:
ii  bubblewrap  0.4.1-3
ii  desktop-file-utils  0.26-1
ii  gsettings-desktop-schemas   3.38.0-2
ii  gvfs1.46.2-1
ii  libatk1.0-0 2.38.0-1~bpo11+1
ii  libc6   2.31-13+deb11u3
ii  libcairo-gobject2   1.16.0-5
ii  libcairo2   1.16.0-5
ii  libgdk-pixbuf-2.0-0 2.42.2+dfsg-1
ii  libgexiv2-2 0.12.1-1
ii  libglib2.0-02.66.8-1
ii  libglib2.0-data 2.66.8-1
ii  libgnome-autoar-0-0 0.2.4-3
ii  libgnome-desktop-3-19   3.38.5-3
ii  libgstreamer-plugins-base1.0-0  1.18.4-2
ii  libgstreamer1.0-0   1.18.4-2.1
ii  libgtk-3-0  3.24.24-4+deb11u2
ii  libnautilus-extension1a 3.38.2-1+deb11u1
ii  libpango-1.0-0  1.46.2-3
ii  libpangocairo-1.0-0 1.46.2-3
ii  libselinux1 3.1-3
ii  libtracker-sparql-2.0-0 2.3.6-2
ii  nautilus-data   3.38.2-1+deb11u1
ii  shared-mime-info2.0-1
ii  tracker 2.3.6-2
ii  tracker-extract 2.3.5-2.1
ii  tracker-miner-fs2.3.5-2.1

Versions of packages nautilus recommends:
ii  gnome-sushi   3.38.0-1
ii  gvfs-backends 1.46.2-1
ii  libgdk-pixbuf2.0-bin  2.42.2+dfsg-1
ii  librsvg2-common   2.50.3+dfsg-1

Versions of packages nautilus suggests:
ii  eog 3.38.2-1
ii  evince [pdf-viewer] 3.38.2-1
ii  nautilus-extension-brasero  3.12.2-6
pn  nautilus-sendto 
ii  totem   3.38.0-2
ii  vlc [mp3-decoder]   3.0.17.4-0+deb11u1
ii  xdg-user-dirs   0.17-2

-- no debconf information

Bug#1014080: zutty: crashes on startup

[David Bremner]

Ricardo Mones  writes:
>
> Agreed, as currently is pretty obscure, IMHO.
>
> Could you build zutty on your system with the attached patch and check if it
> improves somehow?
>

Yes, it's clear what the issue is with this patch.

d

Bug#1016860: matanza: Dependency on telnet, telnet-client and explicit implementations

[Guillem Jover]

Source: matanza
Source-Version: 0.13+ds2-1
Severity: wishlist
Usertags: inetutils-default-telnet-switch

Hi!

This package has a dependency on telnet (which denotes either a specific
implementation or in the future the default one), and on the generic
telnet-client, which denotes any implementation. In addition to a list
of specific implementations, which seems redundant.

You could change that to simply: telnet | telnet-client | putty.

This was prompted while evaluating how to switch the current telnet
implementation in Debian, which is now in progress, although this is
not a blocker, as inetutils will provide telnet (and already provides
telnet-client, the same as telnet-ssl).

Thanks,
Guillem

Bug#1016858: nyancat: Dependency on telnetd but not telnet-server

[Guillem Jover]

Source: nyancat
Source-Version: 1.5.2-0.1
Severity: normal
Usertags: inetutils-default-telnetd-switch

Hi!

This package has a dependency on telnetd (which denotes either a specific
implementation or in the future the default one), but not on the
generic telnet-server, which denotes any implementation.

Please change it to: telnetd | telnet-server.

This was prompted while evaluating how to switch the current telnetd
implementation in Debian, which is now in progress, although this is
not a blocker, as inetutils will provide telnetd, but makes
alternative telnetd implementations not able to satisfy the dependency.

Thanks,
Guillem

Bug#1016859: netkit-telnet-ssl: Dependency on telnetd but not telnet-server

[Guillem Jover]

Source: netkit-telnet-ssl
Source-Version: 0.17.41+0.2-3.3
Severity: normal
Usertags: inetutils-default-telnetd-switch

Hi!

This package has a dependency on telnetd (which denotes either a specific
implementation or in the future the default one), but not on the
generic telnet-server, which denotes any implementation.

Please change it to: telnetd | telnet-server.

This was prompted while evaluating how to switch the current telnetd
implementation in Debian, which is now in progress, although this is
not a blocker, as inetutils will provide telnetd, but makes
alternative telnetd implementations not able to satisfy the dependency.

Thanks,
Guillem

Bug#1016857: procserv: Dependency on telnet but not telnet-client

[Guillem Jover]

Source: procserv
Source-Version: 2.7.0-1
Severity: normal
Usertags: inetutils-default-telnet-switch

Hi!

This package has a dependency on telnet (which denotes either a specific
implementation or in the future the default one), but not on the
generic telnet-client, which denotes any implementation.

Please change it to: telnet | telnet-client.

This was prompted while evaluating how to switch the current telnet
implementation in Debian, which is now in progress, although this is
not a blocker, as inetutils will provide telnet.

Thanks,
Guillem

Bug#1016856: libtelnet: Dependencies on telnet but not telnet-client

[Guillem Jover]

Source: libtelnet
Source-Version: 0.21-5
Severity: normal
Usertags: inetutils-default-telnet-switch

Hi!

This package has dependencies on telnet (which denotes either a specific
implementation or in the future the default one), but not on the
generic telnet-client, which denotes any implementation.

Please change them to: telnet | telnet-client.

This was prompted while evaluating how to switch the current telnet
implementation in Debian, which is now in progress, although this is
not a blocker, as inetutils will provide telnet.

Thanks,
Guillem

Bug#1016855: pdudaemon: Dependency on telnet but not telnet-client

[Guillem Jover]

Source: pdudaemon
Source-Version: 0.0.8.30.g74aba7c-1
Severity: normal
Usertags: inetutils-default-telnet-switch

Hi!

This package has a dependency on telnet (which denotes either a specific
implementation or in the future the default one), but not on the
generic telnet-client, which denotes any implementation.

Please change it to: telnet | telnet-client.

This was prompted while evaluating how to switch the current telnet
implementation in Debian, which is now in progress, although this is
not a blocker, as inetutils will provide telnet.

Thanks,
Guillem

Bug#1016854: ser2net: Dependency on telnet but not telnet-client

[Guillem Jover]

Source: ser2net
Source-Version: 4.3.4-2
Severity: normal
Usertags: inetutils-default-telnet-switch

Hi!

This package has a dependency on telnet (which denotes either a specific
implementation or in the future the default one), but not on the
generic telnet-client, which denotes any implementation.

Please change it to: telnet | telnet-client.

This was prompted while evaluating how to switch the current telnet
implementation in Debian, which is now in progress, although this is
not a blocker, as inetutils will provide telnet.

Thanks,
Guillem

Bug#1016852: dish: Dependency on telnet but not telnet-client

[Guillem Jover]

Source: dish
Source-Version: 1.19.1-1.1
Severity: normal
Usertags: inetutils-default-telnet-switch

Hi!

This package has a dependency on telnet (which denotes either a specific
implementation or in the future the default one), but not on the
generic telnet-client, which denotes any implementation.

Please change it to: telnet | telnet-client.

This was prompted while evaluating how to switch the current telnet
implementation in Debian, which is now in progress, although this is
not a blocker, as inetutils will provide telnet, but makes
alternative telnet implementations not able to satisfy the dependency.

Thanks,
Guillem

Bug#1016853: live-tasks: Dependencies on telnet but not telnet-client

[Guillem Jover]

Source: live-tasks
Source-Version: 12.0.1
Severity: normal
Usertags: inetutils-default-telnet-switch

Hi!

This package has dependencies on telnet (which denotes either a specific
implementation or in the future the default one), but not on the
generic telnet-client, which denotes any implementation.

Please change them to: telnet | telnet-client.

This was prompted while evaluating how to switch the current telnet
implementation in Debian, which is now in progress, although this is
not a blocker, as inetutils will provide telnet, but makes
alternative telnet implementations not able to satisfy the dependency.

Thanks,
Guillem

Bug#1016851: forensics-extra: Dependency on telnet but not telnet-client

[Guillem Jover]

Source: forensics-extra
Source-Version: 2.39
Severity: normal
Usertags: inetutils-default-telnet-switch

Hi!

This package has a dependency on telnet (which denotes either a specific
implementation or in the future the default one), but not on the
generic telnet-client, which denotes any implementation.

Please change it to: telnet | telnet-client.

This was prompted while evaluating how to switch the current telnet
implementation in Debian, which is now in progress, although this is
not a blocker, as inetutils will provide telnet, but makes
alternative telnet implementations not able to satisfy the dependency.

Thanks,
Guillem

Bug#1016850: vland: Dependency on telnet but not telnet-client

[Guillem Jover]

Source: vland
Source-Version: 0.8-1
Severity: normal
Usertags: inetutils-default-telnet-switch

Hi!

This package has a dependency on telnet (which denotes either a specific
implementation or in the future the default one), but not on the
generic telnet-client, which denotes any implementation.

Please change it to: telnet | telnet-client.

This was prompted while evaluating how to switch the current telnet
implementation in Debian, which is now in progress, although this is
not a blocker, as inetutils will provide telnet, but makes
alternative telnet implementations not able to satisfy the dependency.

Thanks,
Guillem

Bug#1016849: lava: Dependencies on telnet but not telnet-client

[Guillem Jover]

Source: lava
Source-Version: 2022.01.3-3
Severity: normal
Usertags: inetutils-default-telnet-switch

Hi!

This package has dependencies on telnet (which denotes either a specific
implementation or in the future the default one), but not on the
generic telnet-client, which denotes any implementation.

Please change them to: telnet | telnet-client.

This was prompted while evaluating how to switch the current telnet
implementation in Debian, which is now in progress, although this is
not a blocker, as inetutils will provide telnet, but makes
alternative telnet implementations not able to satisfy the dependency.

Thanks,
Guillem

Bug#1016848: librecast: unknown section 'unknown'

[Graham Inggs]

Source: librecast
Version: 0.5.1-2
Severity: serious

Hi Maintainer

debian/control contains:

Section: unknown

Regards
Graham

Bug#1016847: tucnak: Dependency on telnet but not telnet-client

[Guillem Jover]

Source: tucnak
Source-Version: 4.34-1
Severity: normal
Usertags: inetutils-default-telnet-switch

Hi!

This package has a dependency on telnet (which denotes either a specific
implementation or in the future the default one), but not on the
generic telnet-client, which denotes any implementation.

Please change it to: telnet | telnet-client.

This was prompted while evaluating how to switch the current telnet
implementation in Debian, which is now in progress, although this is
not a blocker, as inetutils will provide telnet.

Thanks,
Guillem

Bug#1016844: mininet: Dependency on telnet but not telnet-client

[Guillem Jover]

Source: mininet
Source-Version: 2.3.0-1
Severity: normal
Usertags: inetutils-default-telnet-switch

Hi!

This package has a dependency on telnet (which denotes either a specific
implementation or in the future the default one), but not on the
generic telnet-client, which denotes any implementation.

Please change it to: telnet | telnet-client.

This was prompted while evaluating how to switch the current telnet
implementation in Debian, which is now in progress, although this is
not a blocker, as inetutils will provide telnet, but makes
alternative telnet implementations not able to satisfy the dependency.

Thanks,
Guillem

Bug#1016846: zssh: Dependency on telnet but not telnet-client

[Guillem Jover]

Source: zssh
Source-Version: 1.5c.debian.1-8
Severity: normal
Usertags: inetutils-default-telnet-switch

Hi!

This package has a dependency on telnet (which denotes either a specific
implementation or in the future the default one), but not on the
generic telnet-client, which denotes any implementation.

Please change it to: openssh-client | telnet | telnet-client | telnet-ssl.

This was prompted while evaluating how to switch the current telnet
implementation in Debian, which is now in progress, although this is
not a blocker, as inetutils will provide telnet, but makes
alternative telnet implementations not able to satisfy the dependency.

Thanks,
Guillem

Bug#1016845: warn users about insecure webkit* packages

[Holger Levsen]

package: debian-security-support
severity: wishlist
x-debbugs-cc: trentb...@gmail.com, 1004...@bugs.debian.org, j...@inutil.org

Hi,

in #1004293 the status of src:khtml and src:webkitgtk was discussed and
as the discussion about the latter is more complicated, I've closed 
#1004293 with documenting the state of sec:khtml and am filing this
new bug to discuss webkit* based browsers in a new and fresh bug report.

On Thu, Feb 10, 2022 at 11:37:18AM +0100, Moritz Mühlenhoff wrote:
> Any reverse dependency of webkit2gtk is supported (i.e. applications like
> Epiphany, Evolution etc).
> 
> Other browsers which use engines which are similarly named since they
> share a common code history are not supported:
> - qtwebkit (only present up to Buster)
> - qtwebkit-opensource-src
> - qtwebengine-opensource-src
> - webkitgtk (only present up to Stretch)
> 
> This e.g. means that the default browser in KDE (Konqueror) is entirely
> unsupported with security updates.
> 
> Note this isn't the case for any distro out there, we're just the only one
> transparent about in in their release notes!
> 
> E.g. qtwebengine rebases to Chromium releases from time to time, but
> definitely not a pace which is needed and none of this reaches distros
> properly.
> 
> I understand this is probably a little confusing, so maybe we should
> instead list specific browsers as examples for webengine related components
> which are supported and which are not.

so, for bookworm, we should add 

- qtwebkit-opensource-src
- qtwebengine-opensource-src

to security-support-limited ("only for trusted content") and that's it?


-- 
cheers,
Holger

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

This too shall pass.


signature.asc
Description: PGP signature

Bug#1016843: apt: should probably use "sop" for OpenPGP

[Lars Wirzenius]

Package: apt
Severity: wishlist

Currently apt is using gpgv to verify Release.gpg files. It would
probably be a good idea to use an implemenation of the SOP interface
instead. SOP is short for "stateless OpenPGP", and it's a
specification by Daniel Kahn Gillmor (dkg). See

https://datatracker.ietf.org/doc/draft-dkg-openpgp-stateless-cli/

There are many implementations of that, including one for GnuPG.
Having a consistent interface makes it easier to switch to a different
implementation. The OpenPGP Interoperabiolity Test Suite
(https://tests.sequoia-pgp.org/) uses this.

If APT used SOP, it could even allow a sysadmin to choose what
implementation they want. This would free apt from being locked into
GnuPG without abandoning OpenPGP entirely.

The SOP interface is pretty good for programmatic use.

-- 
I want to build worthwhile things that might last. --joeyh


signature.asc
Description: PGP signature

Bug#987729: inetutils-telnet: provide upgrade path for orphan netkit-telnet

[Guillem Jover]

Hi!

On Fri, 2022-08-05 at 22:13:15 +0200, Simon Josefsson wrote:
> Guillem Jover  writes:
> > Sure. As per the plan on debian-devel, whenever you have some time, could
> > you prepare the netkit-telnet update targeting experimental, which
> > renames the binary packages to be prefixed with netkit-*? Then once these
> > get ACCEPTED from NEW, we can coordinate the upload of netkit-telnet and
> > inetutils into unstable.
> 
> Hi!  Great.  I have uploaded it now, and my main problem is thinking
> about upgrades.  In git, I have renamed telnet(d) to netkit-telnet(d)
> now, and added Replaces/Breaks on the old versions.  How do we test
> upgrade paths?  It is not clear to me what should happen in all cases
> (e.g., system with telnet+inetutils-telnet installed, alternatives
> pointing to netkit, do we want that to upgrade both packages and change
> alternative?).

And it seems it was ACCEPTed yesterday! I've prepared the following
changes inetutils:

  https://git.hadrons.org/cgit/debian/pkgs/inetutils.git/log/?h=pu/default

it seems to handle the upgrade correctly. For telnetd we need to
remove the inetd entry otherwise update-inetd will prompt, for
telnet we should remove the alternative otherwise there are warnings
about disappearing implementations for the alternative.

I've tested this by installing the telnet/telnetd package and then
just running the equivalent of «apt install ./inetutils-telnet*.deb
./telnet*.deb».

If you can have a peek that would be nice, then once we are satisfied
we can decide on a day, where I upload inetutils to sid first, to take
over the telnet/telnetd, then once that's accepted you could upload
the netkit from experimental to sid.

Thanks,
Guillem

Bug#1016842: vim-youcompleteme: vim-tests-gopls fails with gopls/1:0.1.12+ds-1

[Shengjing Zhu]

Source: vim-youcompleteme
Version: 0+20220402+git3ededae+ds-3
Severity: serious
X-Debbugs-Cc: z...@debian.org

The test is wrong to assume the fixtures provided by gopls are always same.
The failed test blocks gopls migrating to testing.

Bug#1016841: bolt: autopkgtest failure with libglib2.0-0=2.73.3-1: g_log_set_writer_func() called multiple times

[Simon McVittie]

Source: bolt
Version: 0.9.2-1
Severity: important
Tags: upstream
User: debian...@lists.debian.org
Usertags: needs-update
Forwarded: https://gitlab.freedesktop.org/bolt/bolt/-/issues/181

With GLib 2.73.3 from experimental, bolt's installed-tests started failing:

> 1..6
> # Start of logging tests
> Bail out! GLib-FATAL-ERROR: g_log_set_writer_func() called multiple times
> 
> (/usr/libexec/installed-tests/bolt/test-logging:2158): GLib-ERROR **: 
> 21:55:26.826: g_log_set_writer_func() called multiple times

Since https://gitlab.gnome.org/GNOME/glib/-/merge_requests/2617,
GLib considers it to be a fatal programming error to call
g_log_set_writer_func() more than once. The justification is
that this sets process-global state, with each call overwriting
the effect of previous calls in older versions of GLib; therefore
g_log_set_writer_func() should only be called once, near the beginning of
main() (or possibly from a wrapper function that is similarly documented
as only valid to call once, near the beginning of main()).

I've suggested a possible solution on the upstream issue
https://gitlab.freedesktop.org/bolt/bolt/-/issues/181.

This will become RC when GLib 2.73.x/2.74.x reaches unstable, which I
suspect will need to happen for GNOME 43.

smcv

Bug#1016840: elpa-jabber: consider switching to active fork

[David Bremner]

Package: elpa-jabber
Version: 0.8.92+git98dc8e-7
Severity: wishlist
X-Debbugs-Cc: debian-emac...@lists.debian.org


The fork at

https://codeberg.org/emacs-jabber/emacs-jabber

seems to be under active(-ish) development (it is now the repo melpa
points to).


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

Kernel: Linux 5.18.0-3-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
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 elpa-jabber depends on:
ii  dh-elpa-helper 2.0.10
ii  elpa-fsm   0.2.1-4
ii  emacs  1:27.1+1-3.1
ii  emacs-gtk [emacs]  1:27.1+1-3.1+b1
ii  emacsen-common 3.0.4

Versions of packages elpa-jabber recommends:
ii  emacs  1:27.1+1-3.1
ii  emacs-gtk [emacs]  1:27.1+1-3.1+b1
ii  gnutls-bin 3.7.7-2
ii  xprintidle 0.2.4-2

elpa-jabber suggests no packages.

-- no debconf information

Bug#1016839: /usr/lib/noweb/numarkup: not found

[Picca Frédéric-Emmanuel]

Source: noweb
Version: 2.12-1
Severity: important
X-Debbugs-Cc: pi...@debian.org

Hello,

I try to update the package cbflib. This package contain a nuweb file.
Since nuweb is not available, I try to use noweb, but it ends up with this error

$ nuweb2noweb pycbf.w 
/usr/bin/nuweb2noweb: 7: /usr/lib/noweb/numarkup: not found


to my opinion you forgot to install the lib pqrt of noweb

Cheers

Fred



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

Kernel: Linux 5.18.0-3-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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#1016838: ycmd.tests.go.subcommands_test.SubcommandsTest fails with gopls/1:0.1.12+ds-1

[Shengjing Zhu]

Source: ycmd
Version: 0+20220401+gitdbe806f+ds-2
Severity: serious
X-Debbugs-Cc: z...@debian.org


Go 1.19 changes the code format, so the test fails now.
Please exclude this test, as it prevents gopls migrating to testing.

Log:

==
FAIL: test_Subcommands_Format_WholeFile 
(ycmd.tests.go.subcommands_test.SubcommandsTest)
--
Traceback (most recent call last):
  File "/tmp/autopkgtest.nAXNu0/build.RqO/src/ycmd/tests/go/__init__.py", line 
59, in Wrapper
return test( test_case_instance, shared_app, *args, **kwargs )
  File 
"/tmp/autopkgtest.nAXNu0/build.RqO/src/ycmd/tests/go/subcommands_test.py", line 
213, in test_Subcommands_Format_WholeFile
RunTest( app, {
  File 
"/tmp/autopkgtest.nAXNu0/build.RqO/src/ycmd/tests/go/subcommands_test.py", line 
86, in RunTest
assert_that( response.json, test[ 'expect' ][ 'data' ] )
AssertionError: 
Expected: a dictionary containing {'fixits': a sequence containing [a 
dictionary containing {'chunks': a sequence containing [a dictionary containing 
{'range': a dictionary containing {'end': a dictionary containing 
{'column_num': <5>, 'filepath': 
'/tmp/autopkgtest.nAXNu0/build.RqO/src/ycmd/tests/go/go_module/goto.go', 
'line_num': <8>}, 'start': a dictionary containing {'column_num': <1>, 
'filepath': 
'/tmp/autopkgtest.nAXNu0/build.RqO/src/ycmd/tests/go/go_module/goto.go', 
'line_num': <8>}}, 'replacement_text': ''}, a dictionary containing {'range': a 
dictionary containing {'end': a dictionary containing {'column_num': <5>, 
'filepath': 
'/tmp/autopkgtest.nAXNu0/build.RqO/src/ycmd/tests/go/go_module/goto.go', 
'line_num': <8>}, 'start': a dictionary containing {'column_num': <5>, 
'filepath': 
'/tmp/autopkgtest.nAXNu0/build.RqO/src/ycmd/tests/go/go_module/goto.go', 
'line_num': <8>}}, 'replacement_text': '\t'}, a dictionary containing {'range': 
a dictionary containing {'end': a dictionary containing {'column_num': <5>, 
'filepath': 
'/tmp/autopkgtest.nAXNu0/build.RqO/src/ycmd/tests/go/go_module/goto.go', 
'line_num': <12>}, 'start': a dictionary containing {'column_num': <1>, 
'filepath': 
'/tmp/autopkgtest.nAXNu0/build.RqO/src/ycmd/tests/go/go_module/goto.go', 
'line_num': <12>}}, 'replacement_text': ''}, a dictionary containing {'range': 
a dictionary containing {'end': a dictionary containing {'column_num': <5>, 
'filepath': 
'/tmp/autopkgtest.nAXNu0/build.RqO/src/ycmd/tests/go/go_module/goto.go', 
'line_num': <12>}, 'start': a dictionary containing {'column_num': <5>, 
'filepath': 
'/tmp/autopkgtest.nAXNu0/build.RqO/src/ycmd/tests/go/go_module/goto.go', 
'line_num': <12>}}, 'replacement_text': '\t'}]}]}
 but: value for 'fixits' item 0: value for 'chunks' item 0: value for 
'replacement_text' was '\t'

Bug#1013269: catch: FTBFS with glibc 2.34 - are Tags: fixed-upstream, patch correct and if yes any chance to upload this soon?

[Timo Röhling]

Hi Andreas,

On Mon, 25 Jul 2022 11:34:49 +0200 Andreas Tille  wrote:

set since a long time but there is no actual upload.  I intend to fix
bug #1013269 by making terraphast depend from catch but I would prefer
if this bug would have been fixed first.

I have prepared an NMU and will upload it shortly.


Cheers
Timo

--
⢀⣴⠾⠻⢶⣦⠀   ╭╮
⣾⠁⢠⠒⠀⣿⡁   │ Timo Röhling   │
⢿⡄⠘⠷⠚⠋⠀   │ 9B03 EBB9 8300 DF97 C2B1  23BF CC8C 6BDD 1403 F4CA │
⠈⠳⣄   ╰╯


signature.asc
Description: PGP signature

Bug#1016837: bullseye-pu: package avahi/0.8-5+deb11u1

[Michael Biebl]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: pkg-utopia-maintain...@lists.alioth.debian.org

Hi,

I'd like to make a stable upload for avahi.
The changelog reads:

avahi (0.8-5+deb11u1) bullseye; urgency=medium

  [ Simon McVittie ]
  * Add patch to fix display of URLs containing '&' in avahi-discover.
Otherwise, a TXT entry containing a URL with '&' will cause an error.

  [ Michael Biebl ]
  * Do not disable timeout cleanup on watch cleanup.
This was causing timeouts to never be removed from the linked list that
tracks them, resulting in both memory and CPU usage to grow larger over
time. Thanks to Gustavo Noronha Silva. (Closes: #993051)
  * Fix NULL pointer crashes when trying to resolve badly-formatted hostnames.
Fixes a local DoS in avahi-daemon that can be triggered by trying to
resolve badly-formatted hostnames on the /run/avahi-daemon/socket
interface. (CVE-2021-3502, Closes: #986018)


Those are 3 cherry-picks from changes that are already part of 0.8-6
from unstable/testing.
I consider the regression potential low, as those fixes have been in
unstable/testing for a long time.

Regards,
Michael
diff --git a/debian/changelog b/debian/changelog
index 9ec4b413..88166628 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,21 @@
+avahi (0.8-5+deb11u1) bullseye; urgency=medium
+
+  [ Simon McVittie ]
+  * Add patch to fix display of URLs containing '&' in avahi-discover.
+Otherwise, a TXT entry containing a URL with '&' will cause an error.
+
+  [ Michael Biebl ]
+  * Do not disable timeout cleanup on watch cleanup.
+This was causing timeouts to never be removed from the linked list that
+tracks them, resulting in both memory and CPU usage to grow larger over
+time. Thanks to Gustavo Noronha Silva. (Closes: #993051)
+  * Fix NULL pointer crashes when trying to resolve badly-formatted hostnames.
+Fixes a local DoS in avahi-daemon that can be triggered by trying to
+resolve badly-formatted hostnames on the /run/avahi-daemon/socket
+interface. (CVE-2021-3502, Closes: #986018)
+
+ -- Michael Biebl   Mon, 08 Aug 2022 11:27:46 +0200
+
 avahi (0.8-5) unstable; urgency=medium
 
   * d/avahi-daemon.maintscript: Drop removal of symlink, they're not normal
diff --git a/debian/gbp.conf b/debian/gbp.conf
index 76a4dd12..c220725b 100644
--- a/debian/gbp.conf
+++ b/debian/gbp.conf
@@ -1,5 +1,5 @@
 [DEFAULT]
 pristine-tar = True
-debian-branch = debian/master
+debian-branch = debian/bullseye
 upstream-branch = upstream/latest
 patch-numbers = False
diff --git 
a/debian/patches/Do-not-disable-timeout-cleanup-on-watch-cleanup.patch 
b/debian/patches/Do-not-disable-timeout-cleanup-on-watch-cleanup.patch
new file mode 100644
index ..91d6acc5
--- /dev/null
+++ b/debian/patches/Do-not-disable-timeout-cleanup-on-watch-cleanup.patch
@@ -0,0 +1,24 @@
+From: Gustavo Noronha Silva 
+Date: Sun, 2 Jan 2022 22:29:04 -0300
+Subject: Do not disable timeout cleanup on watch cleanup
+
+This was causing timeouts to never be removed from the linked list that
+tracks them, resulting in both memory and CPU usage to grow larger over
+time.
+---
+ avahi-common/simple-watch.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/avahi-common/simple-watch.c b/avahi-common/simple-watch.c
+index 08d8090..2a4a989 100644
+--- a/avahi-common/simple-watch.c
 b/avahi-common/simple-watch.c
+@@ -238,7 +238,7 @@ static void cleanup_watches(AvahiSimplePoll *s, int all) {
+ destroy_watch(w);
+ }
+ 
+-s->timeout_req_cleanup = 0;
++s->watch_req_cleanup = 0;
+ }
+ 
+ static AvahiTimeout* timeout_new(const AvahiPoll *api, const struct timeval 
*tv, AvahiTimeoutCallback callback, void *userdata) {
diff --git a/debian/patches/Fix-NULL-pointer-crashes-from-175.patch 
b/debian/patches/Fix-NULL-pointer-crashes-from-175.patch
new file mode 100644
index ..1dc98d74
--- /dev/null
+++ b/debian/patches/Fix-NULL-pointer-crashes-from-175.patch
@@ -0,0 +1,149 @@
+From: Tommi Rantala 
+Date: Mon, 8 Feb 2021 11:04:43 +0200
+Subject: Fix NULL pointer crashes from #175
+
+avahi-daemon is crashing when running "ping .local".
+The crash is due to failing assertion from NULL pointer.
+Add missing NULL pointer checks to fix it.
+
+Introduced in #175 - merge commit 8f75a045709a780c8cf92a6a21e9d35b593bdecd
+
+(cherry picked from commit 9d31939e55280a733d930b15ac9e4dda4497680c)
+---
+ avahi-core/browse-dns-server.c   | 5 -
+ avahi-core/browse-domain.c   | 5 -
+ avahi-core/browse-service-type.c | 3 +++
+ avahi-core/browse-service.c  | 3 +++
+ avahi-core/browse.c  | 3 +++
+ avahi-core/resolve-address.c | 5 -
+ avahi-core/resolve-host-name.c   | 5 -
+ avahi-core/resolve-service.c | 5 -
+ 8 files changed, 29 insertions(+), 5 deletions(-)
+
+diff --git a/avahi-core/browse-dns-server.c b/avahi-core/browse-dns-server.c
+index 

Bug#1016836: qmmp: Not highdef / 4k ready

[Tobias Koeck]

Package: qmmp
Version: 1.4.4-1
Severity: normal

Dear Maintainer,

the window is very small. I have a 4k monitor and 2 x scaling enabled in
Gnome but it doesn't seem to honor this.

There also seem to be no option to set up the scaling.

Greetings
tobias

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

Kernel: Linux 5.18.0-0.bpo.1-amd64 (SMP w/16 CPU threads; PREEMPT)
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)

Versions of packages qmmp depends on:
ii  libarchive13  3.4.3-2+deb11u1
ii  libasound21.2.4-1.1
ii  libavcodec58  7:4.3.4-0+deb11u1
ii  libavformat58 7:4.3.4-0+deb11u1
ii  libavutil56   7:4.3.4-0+deb11u1
ii  libbs2b0  3.1.0+dfsg-2.2+b1
ii  libc6 2.31-13+deb11u3
ii  libcddb2  1.3.2-6+b1
ii  libcdio-cdda2 10.2+2.0.0-1+b2
ii  libcdio19 2.1.0-2
ii  libcurl3-gnutls   7.84.0-2~bpo11+1
ii  libenca0  1.19-1+b1
ii  libfaad2  2.10.0-1
ii  libflac8  1.3.3-2+deb11u1
ii  libgcc-s1 10.2.1-6
ii  libgme0   0.6.3-2
ii  libjack-jackd2-0 [libjack-0.125]  1.9.17~dfsg-1
ii  libmad0   0.15.1b-10
ii  libmms0   0.6.4-3
ii  libmodplug1   1:0.8.9.0-3
ii  libmpcdec62:0.1~r495-2
ii  libogg0   1.3.4-0.1
ii  libopusfile0  0.9+20170913-1.1
ii  libpulse0 14.2-2
ii  libqt5core5a  5.15.2+dfsg-9
ii  libqt5dbus5   5.15.2+dfsg-9
ii  libqt5gui55.15.2+dfsg-9
ii  libqt5multimedia5 5.15.2-3
ii  libqt5network55.15.2+dfsg-9
ii  libqt5sql55.15.2+dfsg-9
ii  libqt5widgets55.15.2+dfsg-9
ii  libqt5x11extras5  5.15.2-2
ii  libshout3 2.4.5-1+b1
ii  libsidplayfp5 2.0.5-2
ii  libsndfile1   1.0.31-2
ii  libsoxr0  0.1.3-4
ii  libstdc++610.2.1-6
ii  libtag1v5 1.11.1+dfsg.1-3
ii  libvorbis0a   1.3.7-1
ii  libvorbisenc2 1.3.7-1
ii  libvorbisfile31.3.7-1
ii  libwavpack1   5.4.0-1
ii  libwildmidi2  0.4.3-1
ii  libx11-6  2:1.7.2-1

qmmp recommends no packages.

Versions of packages qmmp suggests:
pn  ffmpeg
pn  mplayer   
pn  qmmp-plugin-projectm  
ii  udisks2   2.9.2-2+deb11u1
ii  unzip 6.0-26

-- no debconf information

Bug#1016516: notion: Notion fails on startup (in sid)

[Göran Weinholt]

Jurij Smakov  writes:

> On Wed, Aug 3, 2022 at 5:37 PM Dima Kogan  wrote:
>
>  Jurij Smakov  writes:
>
>  > I tried launching notion under rr, and then this assertion does not
>  > trigger, unfortunately.
>
>  That's too bad. Thanks for trying it out.
>
>  This issue is a race condition, and rr inherently limits the process to
>  one core. Can you try "rr record --chaos"? This randomizes the thread
>  switching, and is often effective and triggering these kinds of failures
>  under rr.
>
> Did not have much luck with --chaos either, the assertion does not trigger.

Hello everyone,

I decided to dig a bit deeper into this issue. I found that the phtreads
mutexes in libx11 were not being initialized by libc, but they were then
used in syscalls. Rebuilding with -pthread fixed the issue, but it
should also not be necessary to do so.

This led me to believe that the hangs/crashes are caused by libc6. I
have updated my system from libc6 2.33-8 to libc6 2.34-1 and I can no
longer reproduce the bug.

@Jurij: What happens if you update your libc6, could you give it a try?
It would be good to get confirmation that the bug was in libc6.

Regards,

-- 
Göran Weinholt   | https://weinholt.se/
Debian Developer | 73 de SA6CJK

Bug#1016835: pulseeffects: segfault

[Antonio]

Package: pulseeffects
Version: 4.8.7-1
Severity: normal

Dear Maintainer,
pulseeffect does not work and returns this error:

$ gdb pulseeffects
GNU gdb (Debian 12.1-3) 12.1
Copyright (C) 2022 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 


...

(pulseeffects:39451): pulseeffects-WARNING **: 11:16:24.286: 
pulse_manager: Pulseaudio 15.0 does not support norewinds. Loading the 
sink the old way. Changing apps volume will cause cracklings


(pulseeffects:39451): pulseeffects-CRITICAL **: 11:16:24.286: 
pulse_manager: failed to load module-null-sink with argument: 
sink_name=PulseEffects_apps 
sink_properties=device.description="PulseEffects(apps)"device.class="sound" 
channels=2 rate=44100


(pulseeffects:39451): pulseeffects-WARNING **: 11:16:24.286: 
pulse_manager: Pulseaudio 15.0 does not support norewinds. Loading the 
sink the old way. Changing apps volume will cause cracklings


(pulseeffects:39451): pulseeffects-CRITICAL **: 11:16:24.286: 
pulse_manager: failed to load module-null-sink with argument: 
sink_name=PulseEffects_mic 
sink_properties=device.description="PulseEffects(mic)"device.class="sound" 
channels=2 rate=44100


Thread 1 "pulseeffects" received signal SIGSEGV, Segmentation fault.
0x765427b4 in std::__cxx11::basic_stringstd::char_traits, std::allocator >::compare(char const*) 
const () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6


--- journal:

kernel: pulseeffects[39427]: segfault at 58 ip 7f636c7427b4 sp 
7ffd97eae890 error 4 in libstdc++.so.6.0.30[7f636c699000+101000]


kernel: Code: 3d 79 a7 05 00 e8 9c 6f f5 ff 66 2e 0f 1f 84 00 00 00 00 
00 66 90 f3 0f 1e fa 41 55 49 89 fd 41 54 49 89 f4 55 53 48 83 ec 08 
<48> 8b 5f 08 48 89 f7 e8 00 81 f5 ff 48 39 d8 48 89 da 48 89 c5 48


Thanks,
Antonio

Bug#945578: buster-pu: package libapache2-mod-auth-openidc/2.3.10.2-1

[Moritz Schlarb]

Dear Adam,

On 05.08.22 21:33, Adam D. Barratt wrote:


Ping? We're in the process of organising the final point release for
buster, as support for it transitions over to the LTS team, so if you
would still like to fix it via pu then the upload needs to happen soon.


Thanks for the additional reminder and I am so so sorry for simply 
forgetting about this until now...
Especially given that everything had been ready since I opened this 
buster-pu bug...


I have just now uploaded the package for the buster distribution.

Best wishes,
--
Moritz Schlarb
Unix und Cloud
Zentrum für Datenverarbeitung
Johannes Gutenberg-Universität Mainz

OpenPGP-Fingerprint: DF01 2247 BFC6
 5501 AFF2 8445 0C24 B841 C7DD BAAF


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1016834: gnucash: Debug package gnucash-gdb missing; GNC_DEBUG variable & --debug have no effect

[anonymous coward]

Package: gnucash
Version: 1:4.4-1
Severity: normal
X-Debbugs-Cc: debbug.gnuc...@sideload.33mail.com

Upstream devs have requested a stack trace from me, which is
documented here:

  https://wiki.gnucash.org/wiki/Stack_Trace

Running “aptitude search gnucash” indicates that there are no packages
named gnucash-dbg, contrary to what the wiki suggests. Ubuntu
apparently has a gnucash-dbg package.

The man page has no DEBUGGING section, but ENVIRONMENT mentions a
GNC_DEBUG variable without saying how to use it.  Since it’s a
boolean, I tried running GC this way:

  $ GNC_DEBUG=1 gnucash --debug $my_data_file

I made it crash, but there is no stack dump so it’s unclear if I
correctly guessed how to use that variable. This is the full complete
and total output from that command:

  ===8<--
  Found Finance::Quote version 1.50.
  Gdk-Message: 09:28:51.919: Lost connection to Wayland compositor.
  ===8<--

It may actually be enough information to troubleshoot the particular
bug I’m working on, but this output is too minimal. In fact, it’s the
same output as running with no debugging options. A /tmp/gnucash.trace
file was created but it’s empty.

The man page also mentions:

  --log  Log level overrides, of the form 
"log.ger.path={debug,info,warn,crit,error}" This option can be specified 
multiple times.

This syntax is bizarre and confusing. Is “log.ger.path” supposed to be
typed literally, or is that supposed to be replaced with something
else?  Is that whole equality string then passed as a space-separated
argument following --log?

The lack of gnucash-dbg package implies that users need to recompile
gnucash to get debugging symbols, IIUC. The
/etc/share/docs/gnucash/README file refers us here for building:

  https://wiki.gnucash.org/wiki/Building

But that wiki page above has no Debian-specific instructions. Debian
has a unique way of downloading source and building (unlike tarballs)
which uses Debian’s package management system. It seems we either need
a gnucash-dbg package, or Debian building instructions-- ideally both.

-- System Information:
Debian Release: 11.4
  APT prefers stable-updates
  APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 
'testing'), (990, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages gnucash depends on:
ii  gnucash-common 1:4.4-1
ii  guile-3.0  3.0.5-4
ii  guile-3.0-libs 3.0.5-4
ii  libaqbanking44 6.2.10-1
ii  libboost-filesystem1.74.0  1.74.0-9
ii  libboost-locale1.74.0  1.74.0-9
ii  libboost-program-options1.74.0 1.74.0-9
ii  libboost-regex1.74.0 [libboost-regex1.74.0-icu67]  1.74.0-9
ii  libc6  2.31-13+deb11u3
ii  libcairo2  1.16.0-5
ii  libcrypt-ssleay-perl   0.73.06-1+b3
ii  libdate-manip-perl 6.83-1
ii  libdbi10.9.0-6
ii  libfinance-quote-perl  1.50~rc2-2
ii  libgcc-s1  10.2.1-6
ii  libgdk-pixbuf-2.0-02.42.2+dfsg-1
ii  libglib2.0-0   2.66.8-1
ii  libgtk-3-0 3.24.24-4+deb11u2
ii  libgwengui-gtk3-79 5.6.0-2
ii  libgwenhywfar795.6.0-2
ii  libhtml-tableextract-perl  2.15-1.1
ii  libhtml-tree-perl  5.07-2
ii  libicu67   67.1-7
ii  libofx71:0.9.15-3
ii  libpango-1.0-0 1.46.2-3
ii  libpangocairo-1.0-01.46.2-3
ii  libpython3.9   3.9.2-1
ii  libsecret-1-0  0.20.4-2
ii  libstdc++6 10.2.1-6
ii  libwebkit2gtk-4.0-37   2.36.4-1~deb11u1
ii  libwww-perl6.52-1
ii  libxml22.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 gnucash recommends:
ii  gnucash-docs 4.4-1
ii  

Bug#1014907: buster-pu: package rustc-mozilla/1.59.0+dfsg1-1~deb10u1

[Emilio Pozuelo Monfort]

On 28/07/2022 18:23, Emilio Pozuelo Monfort wrote:

On 14/07/2022 11:02, Emilio Pozuelo Monfort wrote:

Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: pkg-rust-maintain...@alioth-lists.debian.net

Hi,

This updates rustc-mozilla in buster, in preparation for Firefox 102.

I'm attaching the debdiff from the bullseye update. The windows target
is disabled because it was already disabled in buster, and is something
we don't really care about for our purpose.

I've uploaded the package already to oldstable-new.


I've added a couple of changes to fix the FTBFS on i386 and arm64. debdiff 
attached and package uploaded.


Following the bullseye update, this one adds the mips(el) binaries to buster. 
Package uploaded, and debian/ diff attached.


Cheers,
Emiliodiff -ruNp debian.deb10u2/changelog debian.deb10u3/changelog
--- debian.deb10u2/changelog2022-07-28 18:16:59.0 +0200
+++ debian.deb10u3/changelog2022-08-04 09:50:12.0 +0200
@@ -1,3 +1,9 @@
+rustc-mozilla (1.59.0+dfsg1-1~deb10u3) buster; urgency=medium
+
+  * Include mips(el) stage0 binaries.
+
+ -- Emilio Pozuelo Monfort   Thu, 04 Aug 2022 09:50:12 +0200
+
 rustc-mozilla (1.59.0+dfsg1-1~deb10u2) buster; urgency=medium
 
   * Inline atomics on arm64.
diff -ruNp debian.deb10u2/rules debian.deb10u3/rules
--- debian.deb10u2/rules2022-07-28 18:16:54.0 +0200
+++ debian.deb10u3/rules2022-08-04 09:49:04.0 +0200
@@ -73,7 +73,7 @@ update-version:
 # README.Debian for more details of the cases described below.
 #
 PRECONFIGURE_CHECK = :
-HAVE_BINARY_TARBALL := $(shell ls -1 stage0/*/*$(DEB_HOST_RUST_TYPE)* 
2>/dev/null | wc -l)
+HAVE_BINARY_TARBALL := $(shell ls -1 stage0*/*/*$(DEB_HOST_RUST_TYPE)* 
2>/dev/null | wc -l)
 DOWNLOAD_BOOTSTRAP := false
 # allow not using the binary tarball although it exists
 #ifneq (,$(filter $(DEB_HOST_ARCH), amd64 arm64 armhf i386 powerpc ppc64el 
s390x))
@@ -193,6 +193,7 @@ build:
 override_dh_clean:
# Upstream contains a lot of these
dh_clean -XCargo.toml.orig
+   rm -f stage0/*/*-mips-* stage0/*/*-mipsel-*
 
 debian/config.toml: debian/config.toml.in debian/rules
u="$(DEB_VERSION_UPSTREAM)"; \
@@ -251,6 +252,12 @@ debian/dh_auto_configure.stamp: debian/c
echo 'fn main() { println!("cargo:rustc-link-lib=lzma"); }' > 
vendor/lzma-sys/build.rs
# We don't run ./configure because we use debian/config.toml directly
ln -sf debian/config.toml config.toml
+   # set up links for the mips* tarballs, as bootstrap.py expects them in 
stage0/
+   for fmips in stage0-mips/*/*; do \
+   f0="`echo $$fmips | sed 's/stage0-mips/stage0/'`"; \
+   # we use a hardlink here, for some reason bootstrap.py doesn't 
like symlinks \
+   ln $$fmips $$f0; \
+   done
touch "$@"
 
 override_dh_auto_configure-arch: debian/dh_auto_configure.stamp