Bug#1020452: kodi: 20 Nexus with upstream/Debian libdvdnav4 6.1.1 does not work - call to undefined functions

[Vasyl Gello]

> Do you mean the currently available Kodi stopped working after update or the 
> one you built from source?

P.S: Recently BTS reports started dropping into spam so I had to double-check 
it before replying the second email.
-- 
Vasyl Gello
==
Certified SolidWorks Expert

Mob.:+380 (98) 465 66 77

E-Mail: vasek.ge...@gmail.com
==
호랑이는 죽어서 가죽을 남기고 사람은 죽어서 이름을 남긴다

Bug#1020248: [Git][dbnpolicy/policy][master] 2 commits: Use stanza to refer to deb822 parts instead of paragraph

[Sean Whitton]

Hello Charles,

On Thu 22 Sep 2022 at 02:26PM +09, Charles Plessy wrote:

> So point taken about "paragraph", although interestingly, the
> Simple English definition of "paragraph" is quite spot on if one would
> replace "sentence" with "field": ”one or more sentences that are written
> together with no line breaks separating them.

I think that the quoted definition rather argues against 'paragraph' --
it makes it clear that being made up of sentences, and not
non-sentences, is essential to paragraph-hood.  In other words, it only
becomes spot on if you change the core meaning into a definition of
something else.

> I understand about avoiding ambiguity, but in my opinion it is the price
> to pay to be able to translate information into simple words from
> English to non-European languages.  Although the Policy itself is not
> going to be translated, I think that it can be advantageous if its
> contents can be discussed in simple words in people's native languages.

It may yet be translated!  We have the po4a setup :)

-- 
Sean Whitton

Bug#1020452: kodi: 20 Nexus with upstream/Debian libdvdnav4 6.1.1 does not work - call to undefined functions

[Vasyl Gello]

Hi Alban,

Do you mean the currently available Kodi stopped working after update or the 
one you built from source?
libdvdnav patches were upstreamed by enen92 and some of these were accepted.
We just need to check which patches in the debian folder are still relevant.
-- 
Vasyl Gello
==
Certified SolidWorks Expert

Mob.:+380 (98) 465 66 77

E-Mail: vasek.ge...@gmail.com
==
호랑이는 죽어서 가죽을 남기고 사람은 죽어서 이름을 남긴다

Bug#1020486: libffi-dev: Error in `/usr/share/doc-base/libffi-dev.libffi', line 18: all `Format' sections are invalid

[tv.debian]

Package: libffi-dev
Version: 3.4.3-1
Severity: normal

Dear Maintainer,

on upgrade of libffi-dev 3.4.2-4 dpkg interrupts the configuration:

"
dpkg: error processing package libffi-dev:amd64 (--configure):
 dependency problems - leaving unconfigured
Processing triggers for install-info (6.8-6) ...
Processing triggers for doc-base (0.11.1) ...
Processing 3 changed doc-base files...
Error in `/usr/share/doc-base/libffi-dev.libffi', line 18: all `Format' 
sections are invalid.
Note: `install-docs --verbose --check file_name' may give more details 
about the above error.

"

Thank you for your attention.

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

Kernel: Linux 5.19.10-deb64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr:en_US

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

Versions of packages libffi-dev depends on:
iu  libffi8  3.4.3-1

libffi-dev recommends no packages.

libffi-dev suggests no packages.

-- no debconf information

Bug#1020403: libzstd-dev: cmake file is unavailable

[Tino Didriksen]

An alternative would be for LLVM to fall back to 
https://cmake.org/cmake/help/latest/module/FindPkgConfig.html#command:pkg_check_modules 
to find libzstd. This should be a ~3 line patch.


-- Tino Didriksen



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1020248: [Git][dbnpolicy/policy][master] 2 commits: Use stanza to refer to deb822 parts instead of paragraph

[Charles Plessy]

Hi Russ,

Le Tue, Sep 20, 2022 at 06:08:16PM -0700, Russ Allbery a écrit :
> 
> I do find the use of paragraph the way we were previously using it to
> be confusing, particularly given that the paragraphs contain fields
> which in turn contain actual paragraphs in the normal sense of the
> term.

> I don't want to keep using paragraph, but I'd be open to some other term
> that Guillem was also open to (I think matching the terminology in dpkg is
> very important).  Section or block are commonly used for things like this,
> but aren't very precise, so I'm not that enthused by them.

In the spec, the word "paragraph" is only used in the specified context,
so I always felt that there is no ambiguity.  But of course, it can
create opportunities for misunderstanding when discussing about the
spec.  So point taken about "paragraph", although interestingly, the
Simple English definition of "paragraph" is quite spot on if one would
replace "sentence" with "field": ”one or more sentences that are written
together with no line breaks separating them.  Usually they are
connected by a single idea.” ()

The use of "paragraph" in the current spec is also consistent with
Chapter 5 of the Policy, which also uses the word "paragraph".  By the
way, in section 5.6.26 of the Policy, the word "stanza" is also used to
mean something else than a "paragraph".

I do not mind the word "section".  It is the term used in the manual
page "systemd.syntax" that describes systemd's unit files, which means
that readers may be already familiar with the concept.  One could argue
that its definition in Simple English
(, “A section of a thing or
place is a part of it”) would allow a reader to think that a Field is
also a section, but I feel it is unlikely to happen.  This said, one big
disadvantage of "section" is that when searching for this word in a
document, there may be a lot of noisy hits such as "refer to section xyz
for details".

I understand about avoiding ambiguity, but in my opinion it is the price
to pay to be able to translate information into simple words from
English to non-European languages.  Although the Policy itself is not
going to be translated, I think that it can be advantageous if its
contents can be discussed in simple words in people's native languages.

Cheers,

-- Charles

Bug#1019731: gitlab: failed to fetch comments in merge requests (500 Internal Server Error)

[Maximilian Stein]

Control: forwarded -1 https://gitlab.com/gitlab-org/gitlab/-/issues/374174


Hi there,

As discussed in the upstream Gitlab bug report [1], apparently the 
package `ruby-activerecord` in version 6.1.6.1 
(2:6.1.6.1+dfsg-3~fto11+1) is broken as it appears to contain file from 
version 6.1.6 (specifically 
/usr/share/rubygems-integration/all/gems/activerecord-6.1.6.1/lib/active_record/railtie.rb). 
So, probably, that package needs to be fixed to get merge request 
comments working again.


In the meantime, there is a workaround available for Gitlab [2].

Best,
Max


[1]: https://gitlab.com/gitlab-org/gitlab/-/issues/374174

[2]: https://gitlab.com/gitlab-org/gitlab/-/issues/374174#note_1105638411

Bug#1020049: r-cran-hdf5r: FTBFS: datatype_export.c:1903:19: error: storage size of ‘myenum’ isn’t known

[Andreas Tille]

Control: tags -1 upstream
Control: forwarded -1 https://github.com/hhoeflin/hdf5r/issues/192

Am Sun, Sep 18, 2022 at 08:21:55AM +0200 schrieb Lucas Nussbaum:
> > gcc -I"/usr/share/R/include" -DNDEBUG -I/usr/include/hdf5/serial
> > -D__USE_MINGW_ANSI_STDIO   -fpic  -g -O2 
> > -ffile-prefix-map=/build/r-base-J8F88F/r-base-4.2.1=. 
> > -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
> > -D_FORTIFY_SOURCE=2  -c datatype_export.c -o datatype_export.o
> > datatype_export.c: In function ‘create_DT_H5R_type_t’:
> > datatype_export.c:1903:19: error: storage size of ‘myenum’ isn’t known
> >  1903 |   enum H5R_type_t myenum;
> >   |   ^~
> > datatype_export.c:1904:41: error: invalid application of ‘sizeof’ to 
> > incomplete type ‘enum H5R_type_t’
> >  1904 |   hid_t base_type = get_h5_equiv(sizeof(enum H5R_type_t), 
> > issigned(enum H5R_type_t));
> >   | ^~~~
> > In file included from datatype_export.c:20:
> > datatype_export.c:1904:73: error: conversion to incomplete type
> >  1904 |   hid_t base_type = get_h5_equiv(sizeof(enum H5R_type_t), 
> > issigned(enum H5R_type_t));
> >   | 
> > ^~
> > datatype_export.h:29:24: note: in definition of macro ‘issigned’
> >29 | #define issigned(t) (((t)(-1)) < 0)
> >   |^
> > make[1]: *** [/usr/lib/R/etc/Makeconf:168: datatype_export.o] Error 1

I have forwarded this upstream.

Kind regards

Andreas.

-- 
http://fam-tille.de

Bug#1020485: sox: Please add a SoX sndio I/O library

[Job Bautista]

Oops, typo in the description for libsox-fmt-sndio in d/control, stupid copy-
paste mistake of mine.

Here's the updated patch:

--- debian/control
+++ debian/control
@@ -21,6 +21,7 @@
libpulse-dev,
libsamplerate0-dev,
libsndfile1-dev (>= 1.0.12),
+   libsndio-dev,
libtwolame-dev,
libvorbis-dev,
libwavpack-dev
@@ -156,6 +157,18 @@
  .
  PulseAudio: https://www.freedesktop.org/wiki/Software/PulseAudio/
 
+Package: libsox-fmt-sndio
+Architecture: any
+Multi-Arch: same
+Section: libs
+Depends: ${misc:Depends}, ${shlibs:Depends}
+Description: SoX sndio format I/O library
+ SoX is the swiss army knife of sound processing.
+ .
+ This package contains the SoX sndio format I/O library.
+ .
+ sndio: http://www.sndio.org/
+
 Package: libsox-fmt-all
 Architecture: any
 Multi-Arch: same
@@ -166,6 +179,7 @@
  libsox-fmt-mp3 (= ${binary:Version}),
  libsox-fmt-oss (= ${binary:Version}),
  libsox-fmt-pulse (= ${binary:Version}),
+ libsox-fmt-sndio (= ${binary:Version}),
  ${misc:Depends}
 Description: All SoX format libraries
  SoX is the swiss army knife of sound processing.

--- /dev/null
+++ debian/libsox-fmt-sndio.install
@@ -0,0 +1 @@
+usr/lib/*/sox/libsox_fmt_sndio.so*

Bug#1020485: sox: Please add a SoX sndio I/O library

[Job Bautista]

Source: sox
Version: 14.4.2+git20190427-3
Severity: wishlist
Tags: patch
X-Debbugs-Cc: jobbautis...@protonmail.com

Dear Maintainer,

It would be nice to have a libsox-fmt-sndio package like libsox-fmt-alsa and
libsox-fmt-pulse for us sndio users. While libsox-fmt-ao, which uses libao which
also supports sndio is perfectly fine for audio output, it doesn't support audio
input, which means I can't record my microphone's input using sndio.

Upstream already has code for sndio, it is just matter of adding one more build-
time dependency and explicitly installing libsox_fmt_sndio.so to /usr/lib.

Below is a simple patch doing that. Thanks


--- debian/control
+++ debian/control
@@ -21,6 +21,7 @@
libpulse-dev,
libsamplerate0-dev,
libsndfile1-dev (>= 1.0.12),
+   libsndio-dev,
libtwolame-dev,
libvorbis-dev,
libwavpack-dev
@@ -156,6 +157,18 @@
  .
  PulseAudio: https://www.freedesktop.org/wiki/Software/PulseAudio/
 
+Package: libsox-fmt-sndio
+Architecture: any
+Multi-Arch: same
+Section: libs
+Depends: ${misc:Depends}, ${shlibs:Depends}
+Description: SoX alsa format I/O library
+ SoX is the swiss army knife of sound processing.
+ .
+ This package contains the SoX sndio format I/O library.
+ .
+ sndio: http://www.sndio.org/
+
 Package: libsox-fmt-all
 Architecture: any
 Multi-Arch: same
@@ -166,6 +179,7 @@
  libsox-fmt-mp3 (= ${binary:Version}),
  libsox-fmt-oss (= ${binary:Version}),
  libsox-fmt-pulse (= ${binary:Version}),
+ libsox-fmt-sndio (= ${binary:Version}),
  ${misc:Depends}
 Description: All SoX format libraries
  SoX is the swiss army knife of sound processing.

--- /dev/null
+++ debian/libsox-fmt-sndio.install
@@ -0,0 +1 @@
+usr/lib/*/sox/libsox_fmt_sndio.so*


-- System Information:
Debian Release: bookworm/sid
  APT prefers unreleased
  APT policy: (1, 'unreleased'), (1, 'experimental'), (1, 'unstable')
merged-usr: no
Architecture: amd64 (x86_64)
Foreign Architectures: i386, hurd-i386

Kernel: Linux 5.19.0-1-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN, TAINT_FIRMWARE_WORKAROUND, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_PH.UTF-8, LC_CTYPE=en_PH.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_PH:en
Shell: /bin/sh linked to /bin/dash
Init: OpenRC (via /run/openrc), PID 1: init
LSM: AppArmor: enabled

Bug#1020484: Package is uninstallable

[matthias . geiger1024]

Package: rust-value-bag 
 X-Debbugs-Cc: siret...@tauware.de 
 Version: 1.0.0~alpha.9-1 
 Severity: important 
 
 rust-value-bag is not installable as is has unmet dependencies: 
 ``` 
 sudo apt install librust-value-bag-dev -s 
 Reading package lists... Done 
 Building dependency tree... Done 
 Reading state information... Done 
 Some packages could not be installed. This may mean that you have 
 requested an impossible situation or if you are using the unstable 
 distribution that some required packages have not yet been created 
 or been moved out of Incoming. 
 The following information may help to resolve the situation: 
 
 The following packages have unmet dependencies: 
 librust-value-bag-dev : Depends: librust-erased-serde-0.3+alloc-dev but it is 
not installable 
  Depends: librust-serde-fmt-1+default-dev but it is 
not installable 
  Depends: librust-sval-1.0.0+alloc-dev but it is not 
installable 
  Depends: librust-sval-1.0.0+fmt-dev but it is not 
installable 
  Depends: librust-sval-1.0.0+serde1-dev but it is not 
installable 
  Depends: librust-sval-1.0.0+std-dev but it is not 
installable 
 E: Unable to correct problems, you have held broken packages. 
 ``` 
 
 Cheers 
 
 Matthias Geiger (werdahias) 

Bug#1020483: portaudio19: Add support for sndio

[Job Bautista]

Source: portaudio19
Version: 19.6.0-1.2
Severity: wishlist
Tags: patch
X-Debbugs-Cc: jobbautis...@protonmail.com

Dear Maintainer,

I think it would be nice to have sndio support in the PortAudio package. This
allows applications dependent on the library like Audacity to use this sound
server instead of falling back to ALSA (and thus causing conflicts with other
sndio programs). I've attached a patch which should build successfully against
19.6.0, backported from a still-open pull request for 19.7.0.

Thanks


-- System Information:
Debian Release: bookworm/sid
  APT prefers unreleased
  APT policy: (1, 'unreleased'), (1, 'experimental'), (1, 'unstable')
merged-usr: no
Architecture: amd64 (x86_64)
Foreign Architectures: i386, hurd-i386

Kernel: Linux 5.19.0-1-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN, TAINT_FIRMWARE_WORKAROUND, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_PH.UTF-8, LC_CTYPE=en_PH.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_PH:en
Shell: /bin/sh linked to /bin/dash
Init: OpenRC (via /run/openrc), PID 1: init
LSM: AppArmor: enabledFrom: Job Bautista 
Subject: Add support for sndio

Attempt to push sndio support to upstream is currently stalled.

I only did the CMakeLists.txt additions. The rest is copied from lanodan's work.

Author: Alexandre Ratchov 
Author: Haelwenn (lanodan) Monnier 
Author: Job Bautista 
Forwarded: https://github.com/PortAudio/portaudio/pull/647
Last-Update: 2022-09-21

--- portaudio19-19.6.0.orig/CMakeLists.txt
+++ portaudio19-19.6.0/CMakeLists.txt
@@ -314,6 +314,22 @@ ELSE()
   SET(PA_PKGCONFIG_LDFLAGS "${PA_PKGCONFIG_LDFLAGS} -lasound")
 ENDIF()
 
+FIND_PACKAGE(SNDIO)
+IF(SNDIO_FOUND)
+  OPTION(PA_USE_SNDIO "Enable support for sndio" ON)
+ELSE()
+  OPTION(PA_USE_SNDIO "Enable support for sndio" OFF)
+ENDIF()
+IF(PA_USE_SNDIO)
+  SET(PA_PRIVATE_INCLUDE_PATHS ${PA_PRIVATE_INCLUDE_PATHS} ${SNDIO_INCLUDE_DIRS})
+  SET(PA_SNDIO_SOURCES src/hostapi/sndio/pa_sndio.c)
+  SOURCE_GROUP("hostapi\\SNDIO" FILES ${PA_SNDIO_SOURCES})
+  SET(PA_SOURCES ${PA_SOURCES} ${PA_SNDIO_SOURCES})
+  SET(PA_PRIVATE_COMPILE_DEFINITIONS ${PA_PRIVATE_COMPILE_DEFINITIONS} PA_USE_SNDIO)
+  SET(PA_LIBRARY_DEPENDENCIES ${PA_LIBRARY_DEPENDENCIES} ${SNDIO_LIBRARIES})
+  SET(PA_PKGCONFIG_LDFLAGS "${PA_PKGCONFIG_LDFLAGS} -lsndio")
+ENDIF()
+
   ENDIF()
 
   SET(PA_PKGCONFIG_LDFLAGS "${PA_PKGCONFIG_LDFLAGS} -lm -lpthread")
--- portaudio19-19.6.0.orig/Makefile.in
+++ portaudio19-19.6.0/Makefile.in
@@ -146,6 +146,7 @@ SRC_DIRS = \
 	src/hostapi/dsound \
 	src/hostapi/jack \
 	src/hostapi/oss \
+	src/hostapi/sndio \
 	src/hostapi/wasapi \
 	src/hostapi/wdmks \
 	src/hostapi/wmme \
--- portaudio19-19.6.0.orig/README.txt
+++ portaudio19-19.6.0/README.txt
@@ -77,6 +77,7 @@ Host API Implementations:
 src/hostapi/dsound  = Windows Direct Sound
 src/hostapi/jack= JACK Audio Connection Kit
 src/hostapi/oss = Unix Open Sound System (OSS)
+src/hostapi/sndio   = Small audio and MIDI framework (sndio)
 src/hostapi/wasapi  = Windows Vista WASAPI
 src/hostapi/wdmks   = Windows WDM Kernel Streaming
 src/hostapi/wmme= Windows MultiMedia Extensions (MME)
--- portaudio19-19.6.0.orig/configure.in
+++ portaudio19-19.6.0/configure.in
@@ -24,6 +24,10 @@ AC_ARG_WITH(alsa,
 AS_HELP_STRING([--with-alsa], [Enable support for ALSA @<:@autodetect@:>@]),
 [with_alsa=$withval])
 
+AC_ARG_WITH(sndio,
+AS_HELP_STRING([--with-sndio], [Enable support for sndio @<:@autodetect@:>@]),
+[with_sndio=$withval])
+
 AC_ARG_WITH(jack,
 AS_HELP_STRING([--with-jack], [Enable support for JACK @<:@autodetect@:>@]),
 [with_jack=$withval])
@@ -120,6 +124,10 @@ have_alsa=no
 if test "x$with_alsa" != "xno"; then
 AC_CHECK_LIB(asound, snd_pcm_open, have_alsa=yes, have_alsa=no)
 fi
+have_sndio=no
+if test "x$with_sndio" != "xno"; then
+AC_CHECK_LIB(sndio, sio_open, have_sndio=yes, have_sndio=no)
+fi
 have_asihpi=no
 if test "x$with_asihpi" != "xno"; then
 AC_CHECK_LIB(hpi, HPI_SubSysCreate, have_asihpi=yes, have_asihpi=no, -lm)
@@ -406,6 +414,13 @@ case "${host_os}" in
AC_DEFINE(PA_USE_ALSA,1)
 fi
 
+if [[ "$have_sndio" = "yes" -a "$with_sndio" != "no" ]] ; then
+   DLL_LIBS="$DLL_LIBS -lsndio"
+   LIBS="$LIBS -lsndio"
+   OTHER_OBJS="$OTHER_OBJS src/hostapi/sndio/pa_sndio.o"
+   AC_DEFINE(PA_USE_SNDIO,1)
+fi
+
 if [[ "$have_jack" = "yes" ] && [ "$with_jack" != "no" ]] ; then
DLL_LIBS="$DLL_LIBS $JACK_LIBS"
CFLAGS="$CFLAGS $JACK_CFLAGS"
@@ -512,6 +527,7 @@ case "$target_os" in
 	AC_MSG_RESULT([
   OSS . $have_oss
   JACK  $have_jack
+  Sndio ... $have_sndio
 ])
 ;;
 esac
--- portaudio19-19.6.0.orig/include/portaudio.h
+++ 

Bug#1020407: librust-tracing-futures-dev: impossible to install

[matthias . geiger1024]

Thanks for noticing that, I am working on it. Give me some time to resolve this.

Cheers

Matthias Geiger (werdahias)

Bug#1006418: #1006418: Linux stubdomains?

[Elliott Mitchell]

Not a proper In-Reply-To since that message ended up /somewhere/ and I'm
thus going back to the bug DB for this reply.


I guess I'm neutral-ish on Linux versus Mini-OS for doing stub domains
for Debian on Xen.  I suspect development on Xen's Mini-OS isn't all that
active.  On the flip side due to its limited requirements, Mini-OS might
not need much updating.

My major concern is can current Linux kernels be made small enough for
this to be worthwhile?  I've done some small Debian domains and they
really want a minimum of 192MB of memory, which seems a bit large.

Really the big issue seems to be someone simply needs to play with this
a *lot* in order to figure the thing out.  The information which is out
there isn't easy to understand.

I suspect the simplest may be to examine Qubes OS as they have figured
the thing out.


-- 
(\___(\___(\__  --=> 8-) EHM <=--  __/)___/)___/)
 \BS (| ehem+sig...@m5p.com  PGP 87145445 |)   /
  \_CS\   |  _  -O #include  O-   _  |   /  _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445

Bug#1020464: www.debian.org: debian.org cookie logged_out_marketing_header_id

[Paul Wise]

Control: tags -1 + unreproducible

On Thu, 22 Sep 2022 02:28:42 +0200 Thorsten Glaser wrote:

> Why does the website set this cookie, or a cookie at all?
> These are, preferences or logins aside, normally a sign of
> bad behaviour like user tracking, and I’d say frowned upon
> in the project.

I can't reproduce this nor find any sign of this cookie name in the
website code, as far as I can tell the only place on the Debian website
that sets a cookie of any kind is the language override functionality:

https://www.debian.org/intro/cn#override

Perhaps your browser or an extension is adding the cookie?

Searching for the name indicates this is a GitLab/salsa cookie,
but I would expect that would set the cookie on salsa.d.o not d.o.

https://gitlab.com/gitlab-org/gitlab/-/merge_requests/76076

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#1020387: Bugs filed against all Hunspell source packages

[Soren Stoutner]

I filed bugs against each of the Hunspell source packages that produce 
dictionaries making each of the maintainers aware of the discussion happening 
here and inviting them to participate in the discussion.

Once a packaging consensus is reached, these bug reports will also provide a 
useful mechanism for tracking when the packaging of the .bdic dictionaries is 
completed for each package.

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

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

Bug#1020452: kodi: 20 Nexus with upstream/Debian libdvdnav4 6.1.1 does not work - call to undefined functions

[Alban Browaeys]

I found debian kodi README.source. So the best course of action seems
to pile the upstream libdvdnav git patches in debian/patches/libdvdnav.

Kind regards,

Alban

Bug#1020482: libreoffice-dictionaries: Package the Qt WebEngine binary dictionary files from your Hunspell source

[Soren Stoutner]

Source: libreoffice-dictionaries
Version: 1:7.2.0-2
Severity: wishlist

Qt WebEngine has the ability to use Hunspell dictionaries for spell checking, 
but they require that the dictionary files be converted to a special binary 
format (.bdic).  This conversion can be done using qwebengine_convert_dict from 
the qtwebengine5-dev-tools package.  The upstream documentation regarding this 
is found on Qt's website:

https://doc.qt.io/qt-5/qtwebengine-features.html#spellchecker

Once these libraries are available they can be used by any program that 
includes 
Qt WebEngine.

There is desire to package these libraries in Debian, which is fairly easy to 
do 
from your source package with a few minor modifications.  However, it is first 
necessary to determine the best way to handle the binary packages and which 
directory to store the files in.  There is a meta-bug that has been filed 
against dictionaries-common for the purpose of developing a consensus as to the 
best way to do this:

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

If you have any input on this subject it would be appreciated.

Bug#1020481: hunspell-ar: Package the Qt WebEngine binary dictionary files from your Hunspell source

[Soren Stoutner]

Source: hunspell-ar
Version: 3.2-1.2
Severity: wishlist

Qt WebEngine has the ability to use Hunspell dictionaries for spell checking, 
but they require that the dictionary files be converted to a special binary 
format (.bdic).  This conversion can be done using qwebengine_convert_dict from 
the qtwebengine5-dev-tools package.  The upstream documentation regarding this 
is found on Qt's website:

https://doc.qt.io/qt-5/qtwebengine-features.html#spellchecker

Once these libraries are available they can be used by any program that 
includes 
Qt WebEngine.

There is desire to package these libraries in Debian, which is fairly easy to 
do 
from your source package with a few minor modifications.  However, it is first 
necessary to determine the best way to handle the binary packages and which 
directory to store the files in.  There is a meta-bug that has been filed 
against dictionaries-common for the purpose of developing a consensus as to the 
best way to do this:

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

If you have any input on this subject it would be appreciated.

Bug#1020480: hunspell-be: Package the Qt WebEngine binary dictionary files from your Hunspell source

[Soren Stoutner]

Source: hunspell-be
Version: 0.53-3.1
Severity: wishlist

Qt WebEngine has the ability to use Hunspell dictionaries for spell checking, 
but they require that the dictionary files be converted to a special binary 
format (.bdic).  This conversion can be done using qwebengine_convert_dict from 
the qtwebengine5-dev-tools package.  The upstream documentation regarding this 
is found on Qt's website:

https://doc.qt.io/qt-5/qtwebengine-features.html#spellchecker

Once these libraries are available they can be used by any program that 
includes 
Qt WebEngine.

There is desire to package these libraries in Debian, which is fairly easy to 
do 
from your source package with a few minor modifications.  However, it is first 
necessary to determine the best way to handle the binary packages and which 
directory to store the files in.  There is a meta-bug that has been filed 
against dictionaries-common for the purpose of developing a consensus as to the 
best way to do this:

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

If you have any input on this subject it would be appreciated.

Bug#1020479: hunspell-bo: Package the Qt WebEngine binary dictionary files from your Hunspell source

[Soren Stoutner]

Source: hunspell-bo
Version: 0.4.0-1.1
Severity: wishlist

Qt WebEngine has the ability to use Hunspell dictionaries for spell checking, 
but they require that the dictionary files be converted to a special binary 
format (.bdic).  This conversion can be done using qwebengine_convert_dict from 
the qtwebengine5-dev-tools package.  The upstream documentation regarding this 
is found on Qt's website:

https://doc.qt.io/qt-5/qtwebengine-features.html#spellchecker

Once these libraries are available they can be used by any program that 
includes 
Qt WebEngine.

There is desire to package these libraries in Debian, which is fairly easy to 
do 
from your source package with a few minor modifications.  However, it is first 
necessary to determine the best way to handle the binary packages and which 
directory to store the files in.  There is a meta-bug that has been filed 
against dictionaries-common for the purpose of developing a consensus as to the 
best way to do this:

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

If you have any input on this subject it would be appreciated.

Bug#1020478: hunspell-br: Package the Qt WebEngine binary dictionary files from your Hunspell source

[Soren Stoutner]

Source: hunspell-br
Version: 0.12-2.1
Severity: wishlist

Qt WebEngine has the ability to use Hunspell dictionaries for spell checking, 
but they require that the dictionary files be converted to a special binary 
format (.bdic).  This conversion can be done using qwebengine_convert_dict from 
the qtwebengine5-dev-tools package.  The upstream documentation regarding this 
is found on Qt's website:

https://doc.qt.io/qt-5/qtwebengine-features.html#spellchecker

Once these libraries are available they can be used by any program that 
includes 
Qt WebEngine.

There is desire to package these libraries in Debian, which is fairly easy to 
do 
from your source package with a few minor modifications.  However, it is first 
necessary to determine the best way to handle the binary packages and which 
directory to store the files in.  There is a meta-bug that has been filed 
against dictionaries-common for the purpose of developing a consensus as to the 
best way to do this:

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

If you have any input on this subject it would be appreciated.

Bug#1020477: hunspell-ca: Package the Qt WebEngine binary dictionary files from your Hunspell source

[Soren Stoutner]

Source: hunspell-ca
Version: 3.0.7+repack1-1
Severity: wishlist

Qt WebEngine has the ability to use Hunspell dictionaries for spell checking, 
but they require that the dictionary files be converted to a special binary 
format (.bdic).  This conversion can be done using qwebengine_convert_dict from 
the qtwebengine5-dev-tools package.  The upstream documentation regarding this 
is found on Qt's website:

https://doc.qt.io/qt-5/qtwebengine-features.html#spellchecker

Once these libraries are available they can be used by any program that 
includes 
Qt WebEngine.

There is desire to package these libraries in Debian, which is fairly easy to 
do 
from your source package with a few minor modifications.  However, it is first 
necessary to determine the best way to handle the binary packages and which 
directory to store the files in.  There is a meta-bug that has been filed 
against dictionaries-common for the purpose of developing a consensus as to the 
best way to do this:

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

If you have any input on this subject it would be appreciated.

Bug#1020476: igerman98: Package the Qt WebEngine binary dictionary files from your Hunspell source

[Soren Stoutner]

Source: igerman98
Version: 20161207-9
Severity: wishlist

Qt WebEngine has the ability to use Hunspell dictionaries for spell checking, 
but they require that the dictionary files be converted to a special binary 
format (.bdic).  This conversion can be done using qwebengine_convert_dict from 
the qtwebengine5-dev-tools package.  The upstream documentation regarding this 
is found on Qt's website:

https://doc.qt.io/qt-5/qtwebengine-features.html#spellchecker

Once these libraries are available they can be used by any program that 
includes 
Qt WebEngine.

There is desire to package these libraries in Debian, which is fairly easy to 
do 
from your source package with a few minor modifications.  However, it is first 
necessary to determine the best way to handle the binary packages and which 
directory to store the files in.  There is a meta-bug that has been filed 
against dictionaries-common for the purpose of developing a consensus as to the 
best way to do this:

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

If you have any input on this subject it would be appreciated.

Bug#1020474: hunspell-dz: Package the Qt WebEngine binary dictionary files from your Hunspell source

[Soren Stoutner]

Source: hunspell-dz
Version: 0.1.0-1.1
Severity: wishlist

Qt WebEngine has the ability to use Hunspell dictionaries for spell checking, 
but they require that the dictionary files be converted to a special binary 
format (.bdic).  This conversion can be done using qwebengine_convert_dict from 
the qtwebengine5-dev-tools package.  The upstream documentation regarding this 
is found on Qt's website:

https://doc.qt.io/qt-5/qtwebengine-features.html#spellchecker

Once these libraries are available they can be used by any program that 
includes 
Qt WebEngine.

There is desire to package these libraries in Debian, which is fairly easy to 
do 
from your source package with a few minor modifications.  However, it is first 
necessary to determine the best way to handle the binary packages and which 
directory to store the files in.  There is a meta-bug that has been filed 
against dictionaries-common for the purpose of developing a consensus as to the 
best way to do this:

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

If you have any input on this subject it would be appreciated.

Bug#1020475: medicalterms: Package the Qt WebEngine binary dictionary files from your Hunspell source

[Soren Stoutner]

Source: medicalterms
Version: 20220425-1
Severity: wishlist

Qt WebEngine has the ability to use Hunspell dictionaries for spell checking, 
but they require that the dictionary files be converted to a special binary 
format (.bdic).  This conversion can be done using qwebengine_convert_dict from 
the qtwebengine5-dev-tools package.  The upstream documentation regarding this 
is found on Qt's website:

https://doc.qt.io/qt-5/qtwebengine-features.html#spellchecker

Once these libraries are available they can be used by any program that 
includes 
Qt WebEngine.

There is desire to package these libraries in Debian, which is fairly easy to 
do 
from your source package with a few minor modifications.  However, it is first 
necessary to determine the best way to handle the binary packages and which 
directory to store the files in.  There is a meta-bug that has been filed 
against dictionaries-common for the purpose of developing a consensus as to the 
best way to do this:

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

If you have any input on this subject it would be appreciated.

Bug#1020473: hunspell-en-med: Package the Qt WebEngine binary dictionary files from your Hunspell source

[Soren Stoutner]

Source: hunspell-en-med
Version: 0.0.20140410-4
Severity: wishlist

Qt WebEngine has the ability to use Hunspell dictionaries for spell checking, 
but they require that the dictionary files be converted to a special binary 
format (.bdic).  This conversion can be done using qwebengine_convert_dict from 
the qtwebengine5-dev-tools package.  The upstream documentation regarding this 
is found on Qt's website:

https://doc.qt.io/qt-5/qtwebengine-features.html#spellchecker

Once these libraries are available they can be used by any program that 
includes 
Qt WebEngine.

There is desire to package these libraries in Debian, which is fairly easy to 
do 
from your source package with a few minor modifications.  However, it is first 
necessary to determine the best way to handle the binary packages and which 
directory to store the files in.  There is a meta-bug that has been filed 
against dictionaries-common for the purpose of developing a consensus as to the 
best way to do this:

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

If you have any input on this subject it would be appreciated.

Bug#1020472: hunspell-eu: Package the Qt WebEngine binary dictionary files from your Hunspell source

[Soren Stoutner]

Source: hunspell-eu
Version: 5.1-2
Severity: wishlist

Qt WebEngine has the ability to use Hunspell dictionaries for spell checking, 
but they require that the dictionary files be converted to a special binary 
format (.bdic).  This conversion can be done using qwebengine_convert_dict from 
the qtwebengine5-dev-tools package.  The upstream documentation regarding this 
is found on Qt's website:

https://doc.qt.io/qt-5/qtwebengine-features.html#spellchecker

Once these libraries are available they can be used by any program that 
includes 
Qt WebEngine.

There is desire to package these libraries in Debian, which is fairly easy to 
do 
from your source package with a few minor modifications.  However, it is first 
necessary to determine the best way to handle the binary packages and which 
directory to store the files in.  There is a meta-bug that has been filed 
against dictionaries-common for the purpose of developing a consensus as to the 
best way to do this:

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

If you have any input on this subject it would be appreciated.

Bug#1020471: hunspell-fr: Package the Qt WebEngine binary dictionary files from your Hunspell source

[Soren Stoutner]

Source: hunspell-fr
Version: 1:7.0-1
Severity: wishlist

Qt WebEngine has the ability to use Hunspell dictionaries for spell checking, 
but they require that the dictionary files be converted to a special binary 
format (.bdic).  This conversion can be done using qwebengine_convert_dict from 
the qtwebengine5-dev-tools package.  The upstream documentation regarding this 
is found on Qt's website:

https://doc.qt.io/qt-5/qtwebengine-features.html#spellchecker

Once these libraries are available they can be used by any program that 
includes 
Qt WebEngine.

There is desire to package these libraries in Debian, which is fairly easy to 
do 
from your source package with a few minor modifications.  However, it is first 
necessary to determine the best way to handle the binary packages and which 
directory to store the files in.  There is a meta-bug that has been filed 
against dictionaries-common for the purpose of developing a consensus as to the 
best way to do this:

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

If you have any input on this subject it would be appreciated.

Bug#1020470: hunspell-kk: Package the Qt WebEngine binary dictionary files from your Hunspell source

[Soren Stoutner]

Source: hunspell-kk
Version: 1.1-2.1
Severity: wishlist

Qt WebEngine has the ability to use Hunspell dictionaries for spell checking, 
but they require that the dictionary files be converted to a special binary 
format (.bdic).  This conversion can be done using qwebengine_convert_dict from 
the qtwebengine5-dev-tools package.  The upstream documentation regarding this 
is found on Qt's website:

https://doc.qt.io/qt-5/qtwebengine-features.html#spellchecker

Once these libraries are available they can be used by any program that 
includes 
Qt WebEngine.

There is desire to package these libraries in Debian, which is fairly easy to 
do 
from your source package with a few minor modifications.  However, it is first 
necessary to determine the best way to handle the binary packages and which 
directory to store the files in.  There is a meta-bug that has been filed 
against dictionaries-common for the purpose of developing a consensus as to the 
best way to do this:

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

If you have any input on this subject it would be appreciated.

Bug#1020469: hunspell-dict-ko: Package the Qt WebEngine binary dictionary files from your Hunspell source

[Soren Stoutner]

Source: hunspell-dict-ko
Version: 0.7.92-1
Severity: wishlist

Qt WebEngine has the ability to use Hunspell dictionaries for spell checking, 
but they require that the dictionary files be converted to a special binary 
format (.bdic).  This conversion can be done using qwebengine_convert_dict from 
the qtwebengine5-dev-tools package.  The upstream documentation regarding this 
is found on Qt's website:

https://doc.qt.io/qt-5/qtwebengine-features.html#spellchecker

Once these libraries are available they can be used by any program that 
includes 
Qt WebEngine.

There is desire to package these libraries in Debian, which is fairly easy to 
do 
from your source package with a few minor modifications.  However, it is first 
necessary to determine the best way to handle the binary packages and which 
directory to store the files in.  There is a meta-bug that has been filed 
against dictionaries-common for the purpose of developing a consensus as to the 
best way to do this:

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

If you have any input on this subject it would be appreciated.

Bug#1020468: hunspell-lv: Package the Qt WebEngine binary dictionary files from your Hunspell source

[Soren Stoutner]

Source: hunspell-lv
Version: 1.4.0-2
Severity: wishlist

Qt WebEngine has the ability to use Hunspell dictionaries for spell checking, 
but they require that the dictionary files be converted to a special binary 
format (.bdic).  This conversion can be done using qwebengine_convert_dict from 
the qtwebengine5-dev-tools package.  The upstream documentation regarding this 
is found on Qt's website:

https://doc.qt.io/qt-5/qtwebengine-features.html#spellchecker

Once these libraries are available they can be used by any program that 
includes 
Qt WebEngine.

There is desire to package these libraries in Debian, which is fairly easy to 
do 
from your source package with a few minor modifications.  However, it is first 
necessary to determine the best way to handle the binary packages and which 
directory to store the files in.  There is a meta-bug that has been filed 
against dictionaries-common for the purpose of developing a consensus as to the 
best way to do this:

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

If you have any input on this subject it would be appreciated.

Bug#1020467: hunspell-ml: Package the Qt WebEngine binary dictionary files from your Hunspell source

[Soren Stoutner]

Source: hunspell-ml
Version: 0.1-2.1
Severity: wishlist

Qt WebEngine has the ability to use Hunspell dictionaries for spell checking, 
but they require that the dictionary files be converted to a special binary 
format (.bdic).  This conversion can be done using qwebengine_convert_dict from 
the qtwebengine5-dev-tools package.  The upstream documentation regarding this 
is found on Qt's website:

https://doc.qt.io/qt-5/qtwebengine-features.html#spellchecker

Once these libraries are available they can be used by any program that 
includes 
Qt WebEngine.

There is desire to package these libraries in Debian, which is fairly easy to 
do 
from your source package with a few minor modifications.  However, it is first 
necessary to determine the best way to handle the binary packages and which 
directory to store the files in.  There is a meta-bug that has been filed 
against dictionaries-common for the purpose of developing a consensus as to the 
best way to do this:

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

If you have any input on this subject it would be appreciated.

Bug#1020466: dutch: Package the Qt WebEngine binary dictionary files from your Hunspell source

[Soren Stoutner]

Source: dutch
Version: 1:2.20.19-2
Severity: wishlist

Qt WebEngine has the ability to use Hunspell dictionaries for spell checking, 
but they require that the dictionary files be converted to a special binary 
format (.bdic).  This conversion can be done using qwebengine_convert_dict from 
the qtwebengine5-dev-tools package.  The upstream documentation regarding this 
is found on Qt's website:

https://doc.qt.io/qt-5/qtwebengine-features.html#spellchecker

Once these libraries are available they can be used by any program that 
includes 
Qt WebEngine.

There is desire to package these libraries in Debian, which is fairly easy to 
do 
from your source package with a few minor modifications.  However, it is first 
necessary to determine the best way to handle the binary packages and which 
directory to store the files in.  There is a meta-bug that has been filed 
against dictionaries-common for the purpose of developing a consensus as to the 
best way to do this:

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

If you have any input on this subject it would be appreciated.

Bug#1020465: uzbek-wordlist: Package the Qt WebEngine binary dictionary files from your Hunspell source

[Soren Stoutner]

Source: uzbek-wordlist
Version: 0.6-6
Severity: wishlist

Qt WebEngine has the ability to use Hunspell dictionaries for spell checking, 
but they require that the dictionary files be converted to a special binary 
format (.bdic).  This conversion can be done using qwebengine_convert_dict from 
the qtwebengine5-dev-tools package.  The upstream documentation regarding this 
is found on Qt's website:

https://doc.qt.io/qt-5/qtwebengine-features.html#spellchecker

Once these libraries are available they can be used by any program that 
includes 
Qt WebEngine.

There is desire to package these libraries in Debian, which is fairly easy to 
do 
from your source package with a few minor modifications.  However, it is first 
necessary to determine the best way to handle the binary packages and which 
directory to store the files in.  There is a meta-bug that has been filed 
against dictionaries-common for the purpose of developing a consensus as to the 
best way to do this:

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

If you have any input on this subject it would be appreciated.

Bug#1020463: usrmerge: breaks Hurd systems

[Samuel Thibault]

Samuel Thibault, le mer. 21 sept. 2022 23:46:09 +, a ecrit:
> Can't exec "cp": No such file or directory at 
> /usr/lib/usrmerge/convert-usrmerge line 418.
> 
> FATAL ERROR:
> Failed to execute cp --no-dereference --preserve=all --reflink=auto 
> --sparse=always /lib/ld.so.1 /usr/lib/ld.so.1: No such file or directory
> 
> You can try correcting the errors reported and running again
> /usr/lib/usrmerge/convert-usrmerge until it will complete without errors.
> Do not install or update other Debian packages until the program
> has been run successfully.
> 
> E: usrmerge failed.
> 
> 
> Apparently it is trying to move ld.so but fails to do it properly. I
> didn't find which code takes care of doing it properly?

It seems the code is cautious about symlinks, but only at one level of
recursion. The attached patch fixes it by continuing deferring symlinks
whose eventual target still doesn't exist yet.

Samuel
--- /usr/lib/usrmerge//convert-usrmerge 2022-09-18 21:04:17.0 +
+++ convert-usrmerge2022-09-22 00:23:44.0 +
@@ -57,7 +57,11 @@
 
# symlinks must be converted after the rest to avoid races, because
# they may point to binaries which have not been converted yet
-   convert_file($_) foreach @later;
+   while (@later) {
+   my @newlater;
+   convert_file($_, \@newlater) foreach @later;
+   @later = @newlater;
+   }
 
verify_links_only($_) foreach @dirs;
 
@@ -95,9 +99,16 @@
}
 
# is a link and the destination does not exist, but defer the conversion
-   if (-l $n and not -e "/usr$n" and $later) {
-   push(@$later, $n);
-   return;
+   if (-l $n and not -e "/usr$n") {
+   my $l = readlink($n);
+   my ($basedir) = $n =~ m#^(.+)/[^/]+$#;
+   if ($l !~ /^\// and not -e "/usr$basedir/$l") {
+   if (not ($later)) {
+   fatal("Converted link /usr$n would point to 
non-existing /usr$basedir/$l but we are not deferring conversion\n");
+   }
+   push(@$later, $n);
+   return;
+   }
}
 
# is a file or link and the destination does not exist

Bug#1020464: www.debian.org: debian.org cookie logged_out_marketing_header_id

[Thorsten Glaser]

Package: www.debian.org
Severity: normal
X-Debbugs-Cc: t...@mirbsd.de

Why does the website set this cookie, or a cookie at all?
These are, preferences or logins aside, normally a sign of
bad behaviour like user tracking, and I’d say frowned upon
in the project.

Bug#1012196: buglist

[André]

On Thu, 15 Sep 2022 00:27:15 +0200 Bastian Germann  wrote:
> On Tue, 13 Sep 2022 17:09:42 + =?UTF-8?B?QW5kcsOp?= 
 wrote:

> >
> > > No, you have not got it. But maybe this is because of a change in 
the

> > GitHub release page:
> > >
> > > $ uscan --download-current-version
> > > uscan warn: In debian/watch no matching hrefs for version 4.1.2 in
> > watch line
> > > https://github.com/exaile/exaile/releases .*/?(\d\.\d.\d*)\.tar\.gz
> > Works if use the tags page instead of releases.
>
> That would be okay but it also changes the file content.

Got a working version. Seems to be related to 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1019696


> You need to repack. This involves adding a +dfsg suffix to the 
upstream version number.
> You need to change this in d/changelog. For automatic renaming add a 
repacksuffix in d/watch.
> List the files in the d/copyright field Files-Excluded (in the header 
paragraph) for automatic removal.

>

Done.

Bug#975025: flex: reproducible builds: example Makefiles contain build paths

[Vagrant Cascadian]

On 2021-11-30, Vagrant Cascadian wrote:
> On 2021-01-01, Vagrant Cascadian wrote:
>> On 2020-11-17, Vagrant Cascadian wrote:
>>> From 4b9384cc7b73f984507c75f15f293982896135a4 Mon Sep 17 00:00:00 2001
>>> From: Vagrant Cascadian 
>>> Date: Wed, 18 Nov 2020 04:04:02 +
>>> Subject: [PATCH] debian/rules: Remove example autogenerated Makefiles which
>>>  contain build paths.
>>>
>>> ---
>>>  debian/rules | 9 +
>>>  1 file changed, 9 insertions(+)
>>>
>>> diff --git a/debian/rules b/debian/rules
>>> index d0d5597..31a4c72 100755
>>> --- a/debian/rules
>>> +++ b/debian/rules
>>> @@ -91,6 +91,15 @@ ifneq (,$(filter flex-doc, $(shell dh_listpackages)))
>>> debian/flex-doc/usr/share/doc/flex-doc/
>>>  endif
>>>  
>>> +override_dh_installexamples:
>>> +   dh_installexamples
>>> +   # Remove autogenerated Makefiles which contain embedded build
>>> +   # paths in order to ensure reproducible builds.
>>> +   test ! -f debian/flex/usr/share/doc/flex/examples/fastwc/Makefile || \
>>> +   rm -f debian/flex/usr/share/doc/flex/examples/fastwc/Makefile
>>> +   test ! -f debian/flex/usr/share/doc/flex/examples/manual/Makefile || \
>>> +   rm -f debian/flex/usr/share/doc/flex/examples/manual/Makefile
>>> +
>>>  override_dh_auto_build:
>>> dh_auto_build
>>>  ifneq (,$(filter flex-doc, $(shell dh_listpackages)))
>>> -- 
>>> 2.29.2
>>
>> Would very much like to see this land in bullseye... would you consider
>> uploading soon, or be amenable to an NMU?
>
> Still hoping to see this fixed for bookworm!

I have uploaded an NMU fixing this to DELAYED 10, with the following
debdiff:

diff -u flex-2.6.4/debian/changelog flex-2.6.4/debian/changelog
--- flex-2.6.4/debian/changelog
+++ flex-2.6.4/debian/changelog
@@ -1,3 +1,11 @@
+flex (2.6.4-8.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/rules: Remove example autogenerated Makefiles which contain
+build paths. (Closes: #975025)
+
+ -- Vagrant Cascadian   Wed, 21 Sep 2022 
23:35:53 +
+
 flex (2.6.4-8) unstable; urgency=medium

   * The source does not ship with example Makefiles, so no need to massage 
them.
diff -u flex-2.6.4/debian/rules flex-2.6.4/debian/rules
--- flex-2.6.4/debian/rules
+++ flex-2.6.4/debian/rules
@@ -91,6 +91,13 @@
debian/flex-doc/usr/share/doc/flex-doc/
 endif

+override_dh_installexamples:
+   dh_installexamples
+   # Remove autogenerated Makefiles which contain embedded build
+   # paths in order to ensure reproducible builds.
+   rm -f debian/flex/usr/share/doc/flex/examples/fastwc/Makefile
+   rm -f debian/flex/usr/share/doc/flex/examples/manual/Makefile
+
 override_dh_auto_build:
dh_auto_build
 ifneq (,$(filter flex-doc, $(shell dh_listpackages)))


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1020287: vcmi: new vcmi provides files conflicting with existing game-data-packager recipe

[Alexandre Detiste]

I wanted to be 100% sure.

My locally built package (it took forever) does install correctly when
built with this one-line fix:

>  override_dh_auto_install:
> dh_auto_install --destdir=debian/vcmi
> +   rm -vf debian/vcmi/usr/share/vcmi/Mods/vcmi/Maps/VCMI_Tests_2011b.h3m


> upstream confirmed that the file is indeed DFSG-free. Thank you for bringing 
> it up!
One DFSG file in the big core.zip no-one know what it's made of :-)


> Now we need to decide whether vcmi or homm3-en-data should drop the map.
>
> I'd offer to drop it in vcmi just by adding VCMI_Tests_2011b.h3m to
> Files-Excluded in d/copyright. The file is not needed at all to run vcmi, so
> there is no problem with excluding it from the source package.
>
> What do you think?

Please exclude this file in VCMI.

Maybe "Files-Excluded" will break your build, beware.

Greetings

Bug#1020463: usrmerge: breaks Hurd systems

[Samuel Thibault]

Package: usrmerge
Version: 31
Severity: important

Hello,


On usr merge attempt on a hurd-i386 system, things go really bad:


Can't exec "cp": No such file or directory at 
/usr/lib/usrmerge/convert-usrmerge line 418.

FATAL ERROR:
Failed to execute cp --no-dereference --preserve=all --reflink=auto 
--sparse=always /lib/ld.so.1 /usr/lib/ld.so.1: No such file or directory

You can try correcting the errors reported and running again
/usr/lib/usrmerge/convert-usrmerge until it will complete without errors.
Do not install or update other Debian packages until the program
has been run successfully.

E: usrmerge failed.


Apparently it is trying to move ld.so but fails to do it properly. I
didn't find which code takes care of doing it properly?


For reference, this is how links are before usrmerge:

lrwxr-xr-x 1 root root  7 14 sept. 16:59 /lib/ld.so -> ld.so.1
lrwxr-xr-x 1 root root 16 14 sept. 16:59 /lib/ld.so.1 -> i386-gnu/ld.so.1
-rwxr-xr-x 1 root root 224680 14 sept. 16:59 /lib/i386-gnu/ld.so.1

and this is the broken situation we end up with:

lrwxr-xr-x 1 root root 14 21 sept. 23:41 /lib/ld.so -> /usr/lib/ld.so
lrwxr-xr-x 1 root root 16 10 sept. 22:05 /lib/ld.so.1 -> i386-gnu/ld.so.1
lrwxr-xr-x 1 root root 25 21 sept. 23:41 /lib/i386-gnu/ld.so.1 -> 
/usr/lib/i386-gnu/ld.so.1
lrwxr-xr-x 1 root root 7  10 sept. 22:05 /usr/lib/ld.so -> ld.so.1
-rwxr-xr-x 1 root root 224680 10 sept. 22:05 /usr/lib/i386-gnu/ld.so.1

Binaries are looking for /lib/ld.so, which indeed broken here.

Samuel

-- System Information:
Debian Release: bookworm/sid
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'buildd-unstable'), (500, 'unstable'), 
(500, 'stable'), (1, 'buildd-experimental'), (1, 'experimental')
merged-usr: no
Architecture: hurd-i386 (i686-AT386)

Kernel: GNU-Mach 1.8+git20220827-486-dbg/Hurd-0.9
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: sysvinit (via /sbin/init)

Versions of packages usrmerge depends on:
ii  libfile-find-rule-perl  0.34-2
ii  perl5.34.0-3

usrmerge recommends no packages.

usrmerge suggests no packages.

-- no debconf information

Bug#1020290: init-system-helpers depends on usrmerge | usr-is-merged

[Craig Sanders]

On Wed, Sep 21, 2022 at 03:27:04PM +0200, Michael Biebl wrote:
> Unfortunately it is not possible to address the issue you are seeing without
> further information or having a way to reproduce the issue.

Finally, a response that isn't just 1. smug dismissal by quibbling about what
"mandatory" means, 2. posturing by a self-important busybody or 3. just misses
the point.

But it's too late, I've lost interest and I have no more energy to deal with
the hostility and dog-piling.

I'll just leave init-systems-helpers held at 1.64 forever. or until it causes
enough problems that I need to do something about it.  That works for me, and
I no longer care if it's still broken for others.

> Maybe you can provide a minimal reproducer (based on a minimal chroot).

Making a stable VM and then upgrading it to sid should show it.

craig

Bug#1016811: libwebkit2gtk-4.0-37: bullseye backport crashes a lot on arm64

[Dominique MARTINET]

Hi Alberto,

Alberto Garcia wrote on Wed, Sep 21, 2022 at 12:54:22PM +0200:
> On Fri, Sep 16, 2022 at 10:18:32AM +0900, Dominique MARTINET wrote:
> > The traces are slightly different:
> > 
> > /usr/lib/aarch64-linux-gnu/webkit2gtk-4.0/WebKitNetworkProcess
> > (gdb) bt
> > #0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
> > #1  0x7cfdfaa0 in __GI_abort () at abort.c:79
> > #2  0x7fa8ac50 in WTFCrashWithInfo(int, char const*, char const*, 
> > int) () at WTF/Headers/wtf/Assertions.h:741
> > #3  0x80a2d5a8 in captureStackTrace () at 
> > ../Source/WTF/wtf/StackTrace.cpp:79
> > #4  0x80a08ea0 in WTFReleaseLogStackTrace () at 
> > ../Source/WTF/wtf/Assertions.cpp:592
> > #5  0x83c06550 in internalError () at 
> > ../Source/WebCore/platform/network/ResourceErrorBase.cpp:97
> > #6  0x820e8d1c in preconnectTo () at 
> > ../Source/WebKit/NetworkProcess/NetworkConnectionToWebProcess.cpp:735
> 
> do you think you can try this patch?
> 
>
> https://bug-244026-attachments.webkit.org/attachment.cgi?id=462492=diff=raw=1

Thanks!

> If you have problems / are unsure about how to build WebKit I can
> provide packages for you. Just let me know.

I'm definitely unsure about how to build WebKit, but that can be
fixed... I might need to find somewhere with a bit more memory though,
been trying to build the 2.38 release yesterday and build got OOM killed
even with -j1 on a VM with 6GB of ram :/

If you have time to build a package you might be faster than me, so I'd
appreciate it :)

-- 
Dominique

Bug#1020430: usrmerge: cannot handle "open" binary when both kbd and xdg-utils are installed

[Luca Boccassi]

On Wed, 21 Sep 2022 21:46:19 +0200 Giuseppe Sacco 
wrote:
> Il giorno mer, 21/09/2022 alle 18.26 +0200, Ansgar ha scritto:
> > [...]
> > Is /bin/open a symlink to openvt on your system?
> > 
> 
> Yes, it is.

Looks like leftover cruft from kbd < 2.0.4-4 - can you manually delete
/bin/open and then install usrmerge again?

-- 
Kind regards,
Luca Boccassi


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

Bug#1020462: RFS: libbs2b/3.1.0+dfsg-6 [QA] [RC] -- Bauer stereophonic-to-binaural DSP library (binary tools)

[Håvard F . Aasen]

Package: sponsorship-requests
Severity: important

Dear mentors,

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

 * Package name : libbs2b
   Version  : 3.1.0+dfsg-6
   Upstream contact :
 * URL  : http://bs2b.sourceforge.net/
 * License  : FSF-unlimited, GPL-2+, MIT+FSF-public, Expat
 * Vcs  : https://salsa.debian.org/debian/libbs2b
   Section  : libs

The source builds the following binary packages:

  libbs2b-dev - Bauer stereophonic-to-binaural DSP library development files
  libbs2b0 - Bauer stereophonic-to-binaural DSP library
  libbs2b-bin - Bauer stereophonic-to-binaural DSP library (binary tools)

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/libb/libbs2b/libbs2b_3.1.0+dfsg-6.dsc

Changes since the last upload:

 libbs2b (3.1.0+dfsg-6) unstable; urgency=medium
 .
   * QA upload.
   * Add pkg-config as BD. Closes: #1020008

Regards,
Håvard

Bug#1020461: crash uses deprecated apt-key in testsuite

[Steve Langasek]

Source: crash
Version: 8.0.0-1
Severity: minor
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu kinetic

Hi Troy,

A codesearch across Ubuntu shows that crash is using apt-key in its
autopkgtests.

[...]
  elif [ "$(lsb_release -is)" = "Ubuntu" ]; then
  sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 
C8CAB6595FDFF622 2>&1
[...]

The apt-key command is deprecated and will be dropped in future versions of
apt.

  https://blog.jak-linux.org/2021/06/20/migrating-away-apt-key/

Of course, this will have no impact on Debian anyway since this is in an
Ubuntu-specific branch.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature

Bug#1020460: xdaliclock: New version ignores Xresource settings and can't be made transparent

[Stefan Monnier]

Package: xdaliclock
Version: 2.44+debian-2
Severity: normal

The version of xdaliclock in Debian testing seems to be quite different from
the version I've been running for the last ... 20 years(?).  The most obvious
difference is that it disregards my Xresource settings.

But more importantly, I was running it with `XDaliClock.transparent: true`,
but with the new code I can't seem to make it transparent.
I tried to play with the opacity slider in the GUI config, but it has no effect
on my system.  That might be due to my window-manager (ctwm) but the
transparency was the main feature which made me use this program, but this
failure makes it pointless.

I reverted to the xdaliclock in Debian stable for now.  Could there be two
builds of `xdaliclock` available, a bit like the `emacs-lucid` and `emacs-gtk`
alternatives?


Stefan


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

Kernel: Linux 5.19.0-1-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_CH.UTF-8, LC_CTYPE=fr_CH.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 xdaliclock depends on:
ii  libc6 2.34-7
ii  libx11-6  2:1.8.1-2
ii  libxext6  2:1.3.4-1
ii  libxt61:1.2.1-1

xdaliclock recommends no packages.

xdaliclock suggests no packages.

-- no debconf information

Bug#1020293: RM: cruft -- RoQA; conflicts with usrmerge

[Alexandre Detiste]

Hi,

I stumbled on this by luck on https://tracker.debian.org/pkg/cruft ,
was not CC'd. quite a surprise.

It's only the cruft binary half that should/would be removed,
the cruft-common will live on, being used by cruft-ng.

I could also simply copy the files from one repo to the other;
I'll post on debian-devel to see what is best.

So, not so fast please :-)

Greetings,

Alexandre Detiste

Bug#1020459: svox: failing autopkgtest with popt 1.19+dfsg-1~exp1

[Håvard F . Aasen]

Source: svox
Severity: normal

Hi,

svox has a failing autopkgtest with popt 1.19+dfsg-1~exp1 from
experimental, log from autopkgtest is attached.

The binary pico2wave uses memory that is now, correctly, being
freed by popt, this has been a long standing issue with the
library. The binary pico2wave therefore fails when used with
certain command line arguments. An example is the arguments used
in the autopkgtest.
I have attached a patch that solves the issue. It is a one line
fix, which duplicates a string before its freed by popt.


Regards,
Håvardautopkgtest [17:44:12]: starting date: 2022-09-20
autopkgtest [17:44:12]: version 5.25
autopkgtest [17:44:12]: host ci-worker13; command line: /usr/bin/autopkgtest --no-built-binaries '--setup-commands=echo '"'"'svox unstable/amd64'"'"' > /var/tmp/debci.pkg 2>&1 || true' '--setup-commands=echo '"'"'Acquire::Retries "10";'"'"' > /etc/apt/apt.conf.d/75retry 2>&1 || true' --user debci --apt-upgrade --add-apt-release=experimental --pin-packages=experimental=src:popt --output-dir /tmp/debci-worker-26264309-NbheM4Vrtu/autopkgtest-incoming/unstable/amd64/s/svox/26264309 svox -- lxc --sudo --name ci-263-f0ec40b8 autopkgtest-unstable-amd64
autopkgtest [17:44:24]:  test bed setup
Get:1 http://deb.debian.org/debian experimental InRelease [97.5 kB]
Get:2 http://deb.debian.org/debian experimental/non-free Sources [2,512 B]
Get:3 http://deb.debian.org/debian experimental/main Sources [447 kB]
Get:4 http://deb.debian.org/debian experimental/contrib Sources [1,820 B]
Get:5 http://deb.debian.org/debian experimental/main amd64 Packages [402 kB]
Get:6 http://deb.debian.org/debian experimental/contrib amd64 Packages [6,056 B]
Get:7 http://deb.debian.org/debian experimental/non-free amd64 Packages [7,388 B]
Fetched 964 kB in 0s (2,871 kB/s)
Reading package lists...
Get:1 http://deb.debian.org/debian unstable InRelease [158 kB]
Get:2 http://deb.debian.org/debian-debug unstable-debug InRelease [56.7 kB]
Hit:3 http://deb.debian.org/debian experimental InRelease
Get:4 http://deb.debian.org/debian unstable/contrib Sources.diff/Index [63.3 kB]
Get:5 http://deb.debian.org/debian unstable/non-free Sources.diff/Index [63.3 kB]
Get:6 http://deb.debian.org/debian unstable/main Sources.diff/Index [63.6 kB]
Get:7 http://deb.debian.org/debian unstable/main amd64 Packages.diff/Index [63.6 kB]
Get:8 http://deb.debian.org/debian unstable/non-free amd64 Packages.diff/Index [63.3 kB]
Get:9 http://deb.debian.org/debian-debug unstable-debug/contrib Sources.diff/Index [63.3 kB]
Get:10 http://deb.debian.org/debian-debug unstable-debug/non-free Sources.diff/Index [63.3 kB]
Get:11 http://deb.debian.org/debian-debug unstable-debug/main Sources.diff/Index [63.6 kB]
Get:12 http://deb.debian.org/debian-debug unstable-debug/main amd64 Packages.diff/Index [63.6 kB]
Get:13 http://deb.debian.org/debian-debug unstable-debug/non-free amd64 Packages.diff/Index [63.3 kB]
Get:14 http://deb.debian.org/debian unstable/contrib Sources T-2022-09-20-1646.49-F-2022-09-20-1646.49.pdiff [31 B]
Get:15 http://deb.debian.org/debian unstable/non-free Sources T-2022-09-20-1646.49-F-2022-09-20-1646.49.pdiff [31 B]
Get:16 http://deb.debian.org/debian unstable/main Sources T-2022-09-20-1646.49-F-2022-09-20-1106.00.pdiff [22.7 kB]
Get:17 http://deb.debian.org/debian unstable/main amd64 Packages T-2022-09-20-1646.49-F-2022-09-20-1106.00.pdiff [36.2 kB]
Get:14 http://deb.debian.org/debian unstable/contrib Sources T-2022-09-20-1646.49-F-2022-09-20-1646.49.pdiff [31 B]
Get:17 http://deb.debian.org/debian unstable/main amd64 Packages T-2022-09-20-1646.49-F-2022-09-20-1106.00.pdiff [36.2 kB]
Get:16 http://deb.debian.org/debian unstable/main Sources T-2022-09-20-1646.49-F-2022-09-20-1106.00.pdiff [22.7 kB]
Get:15 http://deb.debian.org/debian unstable/non-free Sources T-2022-09-20-1646.49-F-2022-09-20-1646.49.pdiff [31 B]
Get:18 http://deb.debian.org/debian unstable/non-free amd64 Packages T-2022-09-20-1106.00-F-2022-09-20-1106.00.pdiff [5,854 B]
Get:18 http://deb.debian.org/debian unstable/non-free amd64 Packages T-2022-09-20-1106.00-F-2022-09-20-1106.00.pdiff [5,854 B]
Get:19 http://deb.debian.org/debian-debug unstable-debug/contrib Sources T-2022-09-20-1646.49-F-2022-09-20-1646.49.pdiff [31 B]
Get:19 http://deb.debian.org/debian-debug unstable-debug/contrib Sources T-2022-09-20-1646.49-F-2022-09-20-1646.49.pdiff [31 B]
Get:20 http://deb.debian.org/debian-debug unstable-debug/non-free Sources T-2022-09-20-1106.00-F-2022-09-20-1106.00.pdiff [887 B]
Get:21 http://deb.debian.org/debian-debug unstable-debug/main Sources T-2022-09-20-1646.49-F-2022-09-20-1106.00.pdiff [19.2 kB]
Get:22 http://deb.debian.org/debian-debug unstable-debug/main amd64 Packages T-2022-09-20-1646.49-F-2022-09-20-1106.00.pdiff [19.6 kB]
Get:23 http://deb.debian.org/debian-debug unstable-debug/non-free amd64 Packages T-2022-09-20-1106.00-F-2022-09-20-1106.00.pdiff [305 B]
Get:20 http://deb.debian.org/debian-debug unstable-debug/non-free Sources 

Bug#1020441: linux: autopkgtest needs update for new version of gcc-11

[Salvatore Bonaccorso]

Hi,

On Wed, Sep 21, 2022 at 09:23:59PM +0200, Paul Gevers wrote:
> Source: linux
> Version: 5.19.6-1
> Severity: serious
> X-Debbugs-CC: gcc...@packages.debian.org
> Tags: sid bookworm
> User: debian...@lists.debian.org
> Usertags: needs-update
> Control: affects -1 src:gcc-11
> 
> Dear maintainer(s),
> 
> With a recent upload of gcc-11 the autopkgtest of linux fails in testing
> when that autopkgtest is run with the binary packages of gcc-11 from
> unstable. It passes when run with only packages from testing (it also fails
> in testing). In tabular form:
> 
>passfail
> gcc-11 from testing11.3.0-6
> linux  from testing5.19.6-1
> all others from testingfrom testing
> 
> I copied some of the output at the bottom of this report.
> 
> Currently this regression is blocking the migration of gcc-11 to testing
> [1]. Of course, gcc-11 shouldn't just break your autopkgtest (or even worse,
> your package), but it seems to me that the test "only" fails on "Unexpected
> warning" and your package needs to update to the new situation.
> 
> If this is a real problem in your package (and not only in your
> autopkgtest), the right binary package(s) from gcc-11 should really add a
> versioned Breaks on the unfixed version of (one of your) package(s). Note:
> the Breaks is nice even if the issue is only in the autopkgtest as it helps
> the migration software to figure out the right versions to combine in the
> tests.
> 
> More information about this bug and the reason for filing it can be found on
> https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation
> 
> Paul
> 
> [1] https://qa.debian.org/excuses.php?package=gcc-11
> 
> https://ci.debian.net/data/autopkgtest/testing/amd64/l/linux/26272813/log.gz
> 
> I: Found quick flavour cloud-amd64
> I: Build for 5.19.0-1-cloud-amd64
> make: Entering directory '/usr/src/linux-headers-5.19.0-1-cloud-amd64'
> test -e include/generated/autoconf.h -a -e include/config/auto.conf || (  
> \
> echo >&2; \
> echo >&2 "  ERROR: Kernel configuration is invalid."; \
> echo >&2 " include/generated/autoconf.h or include/config/auto.conf
> are missing.";\
> echo >&2 " Run 'make oldconfig && make prepare' on kernel src to fix
> it."; \
> echo >&2 ;\
> /bin/false)
> warning: the compiler differs from the one used to build the kernel
>   The kernel was built by: gcc-11 (Debian 11.3.0-5) 11.3.0
>   You are using:   gcc-11 (Debian 11.3.0-6) 11.3.0
> make -f /usr/src/linux-headers-5.19.0-1-common/scripts/Makefile.build
> obj=/tmp/autopkgtest-lxc.8_h2xh0q/downtmp/autopkgtest_tmp/foo \
> single-build= \
> need-builtin=1 need-modorder=1
>gcc-11
> -Wp,-MMD,/tmp/autopkgtest-lxc.8_h2xh0q/downtmp/autopkgtest_tmp/foo/.foo.o.d
> -nostdinc -I/usr/src/linux-headers-5.19.0-1-common/arch/x86/include
> -I./arch/x86/include/generated
> -I/usr/src/linux-headers-5.19.0-1-common/include -I./include
> -I/usr/src/linux-headers-5.19.0-1-common/arch/x86/include/uapi
> -I./arch/x86/include/generated/uapi
> -I/usr/src/linux-headers-5.19.0-1-common/include/uapi
> -I./include/generated/uapi -include
> /usr/src/linux-headers-5.19.0-1-common/include/linux/compiler-version.h
> -include /usr/src/linux-headers-5.19.0-1-common/include/linux/kconfig.h
> -include
> /usr/src/linux-headers-5.19.0-1-common/include/linux/compiler_types.h
> -D__KERNEL__ -fmacro-prefix-map=/usr/src/linux-headers-5.19.0-1-common/=
> -Wall -Wundef -Werror=strict-prototypes -Wno-trigraphs -fno-strict-aliasing
> -fno-common -fshort-wchar -fno-PIE -Werror=implicit-function-declaration
> -Werror=implicit-int -Werror=return-type -Wno-format-security -std=gnu11
> -mno-sse -mno-mmx -mno-sse2 -mno-3dnow -mno-avx -fcf-protection=none -m64
> -falign-jumps=1 -falign-loops=1 -mno-80387 -mno-fp-ret-in-387
> -mpreferred-stack-boundary=3 -mskip-rax-setup -mtune=generic -mno-red-zone
> -mcmodel=kernel -Wno-sign-compare -fno-asynchronous-unwind-tables
> -mindirect-branch=thunk-extern -mindirect-branch-register
> -mindirect-branch-cs-prefix -mfunction-return=thunk-extern -fno-jump-tables
> -mharden-sls=all -fno-delete-null-pointer-checks -Wno-frame-address
> -Wno-format-truncation -Wno-format-overflow -Wno-address-of-packed-member
> -O2 -fno-allow-store-data-races -Wframe-larger-than=2048
> -fstack-protector-strong -Wimplicit-fallthrough=5 -Wno-main
> -Wno-unused-but-set-variable -Wno-unused-const-variable
> -fno-stack-clash-protection -pg -mrecord-mcount -mfentry -DCC_USING_FENTRY
> -Wdeclaration-after-statement -Wvla -Wno-pointer-sign -Wcast-function-type
> -Wno-stringop-truncation -Wno-stringop-overflow -Wno-restrict
> -Wno-maybe-uninitialized -Wno-alloc-size-larger-than -fno-strict-overflow
> -fno-stack-check -fconserve-stack -Werror=date-time
> -Werror=incompatible-pointer-types -Werror=designated-init
> 

Bug#1020458: gscan2pdf: Test t351_unpaper fails two tests with unpaper 7.0.0

[Martin Weinelt]

Package: gscan2pdf
Version: 2.12.8
Severity: normal
Tags: upstream

Dear Maintainer,

after upgrading unpaper to 7.0.0 on NixOS we are seeing the following
tests fail:

```
t/351_unpaper.t ... 1/7 2022/09/21 20:35:48 [image2 
@ 0x45b800] Encoder did not produce proper pts, making some up.
[image2 @ 0x45b800] The specified filename '/build/w8SASuQfH0/8ZQ3mYsnYB.pnm' 
does not contain an image sequence pattern or a pattern is invalid.
[image2 @ 0x45b800] Use a pattern such as %03d for an image sequence or use the 
-update option (with -frames:v 1 if needed) to write a single image.
t/351_unpaper.t ... 2/7 
#   Failed test 'no warnings'
#   at t/351_unpaper.t line 91.

#   Failed test 'no warnings'
#   at t/351_unpaper.t line 91.
t/351_unpaper.t ... 4/7 # Looks like you planned 7 
tests but ran 9.
# Looks like you failed 2 tests of 9 run.
t/351_unpaper.t ... Dubious, test returned 2 (wstat 
512, 0x200)
Failed 2/7 subtests 
```

System information is obviously unrelated.

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

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

Versions of packages gscan2pdf depends on:
pn  imagemagick
pn  libconfig-general-perl 
pn  libdate-calc-perl  
pn  libfilesys-df-perl 
pn  libgoocanvas2-perl 
pn  libgtk3-imageview-perl 
pn  libgtk3-perl   
pn  libgtk3-simplelist-perl
pn  libhtml-parser-perl
pn  libimage-magick-perl   
pn  libimage-sane-perl 
pn  liblist-moreutils-perl 
pn  liblocale-codes-perl   
ii  liblocale-gettext-perl 1.07-4+b1
pn  liblog-log4perl-perl   
pn  libossp-uuid-perl | libdata-uuid-perl  
pn  libpdf-builder-perl
ii  libproc-processtable-perl  0.59-2+b1
ii  libreadonly-perl   2.050-3
pn  librsvg2-common
pn  libset-intspan-perl
pn  libtiff-tools  
ii  libtry-tiny-perl   0.30-1
pn  sane-utils 

Versions of packages gscan2pdf recommends:
pn  djvulibre-bin 
pn  pdftk 
pn  tesseract-ocr | gocr | cuneiform  
pn  unpaper   
pn  xdg-utils 

gscan2pdf suggests no packages.

Bug#1020457: "check-enhancements -ip" is slow

[Jakub Wilk]

Package: debian-goodies
Version: 0.88.1

"check-enhancements -ip" is very very slow:

$ time check-enhancements -ip
apt => progress-linux-pgp-keys:   Installed: (none)   Candidate: 
20211008-1
...
zsh => zsh-syntax-highlighting:   Installed: (none)   Candidate: 0.7.1-2

real42m28.098s
user40m7.389s
sys 4m44.769s


-- System Information:
Architecture: i386

Versions of packages debian-goodies recommends:
ii  apt2.5.2
ii  curl   7.85.0-1
ii  dctrl-tools2.24-3
ii  elfutils   0.187-2
ii  equivs 2.3.1
ii  libipc-system-simple-perl  1.30-1
ii  libfile-slurper-perl   0.013-1
ii  libfile-which-perl 1.27-1
ii  man-db 2.10.2-3
ii  perl   5.34.0-5
ii  procps 2:3.3.17-7+b1
ii  python33.10.6-1
ii  sensible-utils 0.0.17
ii  dialog 1.3-20211214-1

--
Jakub Wilk

Bug#1020456: cypari2 FTBFS with PARI 2.15.0

[Adrian Bunk]

Source: cypari2
Version: 2.1.2-2
Severity: serious
Tags: ftbfs bookworm sid

https://buildd.debian.org/status/logs.php?pkg=cypari2=2.1.2-2%2Bb3

...
   debian/rules override_dh_auto_test
make[1]: Entering directory '/<>'
python3 tests/rundoctest.py
  ***   user warning: test
/usr/lib/python3.10/doctest.py:1350: RuntimeWarning: cypari2 leaked 197450664 
bytes on the PARI stack
  exec(compile(example.source, filename, "single",
/usr/lib/python3.10/doctest.py:1350: RuntimeWarning: cypari2 leaked 241740752 
bytes on the PARI stack
  exec(compile(example.source, filename, "single",
/usr/lib/python3.10/doctest.py:1350: RuntimeWarning: cypari2 leaked 248010168 
bytes on the PARI stack
  exec(compile(example.source, filename, "single",
/usr/lib/python3.10/doctest.py:1350: RuntimeWarning: cypari2 leaked 252956360 
bytes on the PARI stack
  exec(compile(example.source, filename, "single",
/usr/lib/python3.10/doctest.py:1350: RuntimeWarning: cypari2 leaked 258607552 
bytes on the PARI stack
  exec(compile(example.source, filename, "single",
/usr/lib/python3.10/doctest.py:1350: RuntimeWarning: cypari2 leaked 209447264 
bytes on the PARI stack
  exec(compile(example.source, filename, "single",
/usr/lib/python3.10/doctest.py:1350: RuntimeWarning: cypari2 leaked 215847936 
bytes on the PARI stack
  exec(compile(example.source, filename, "single",
/usr/lib/python3.10/doctest.py:1350: RuntimeWarning: cypari2 leaked 190613912 
bytes on the PARI stack
  exec(compile(example.source, filename, "single",
/usr/lib/python3.10/doctest.py:1350: RuntimeWarning: cypari2 leaked 178484864 
bytes on the PARI stack
  exec(compile(example.source, filename, "single",
/usr/lib/python3.10/doctest.py:1350: RuntimeWarning: cypari2 leaked 180449432 
bytes on the PARI stack
  exec(compile(example.source, filename, "single",

Testing cypari2.closure
**
File 
"/<>/.pybuild/cpython3_3.10_cypari2/build/cypari2/closure.cpython-310-x86_64-linux-gnu.so",
 line ?, in cypari2.closure.__test__.objtoclosure (line 145)
Failed example:
mul([1], [2])
Differences (ndiff with -expected +actual):
  Traceback (most recent call last):
- ...
- PariError: call_python: forbidden multiplication t_VEC (1 elts) * t_VEC 
(1 elts)
+   File "/usr/lib/python3.10/doctest.py", line 1350, in __run
+ exec(compile(example.source, filename, "single",
+   File "", 
line 1, in 
+ mul([1], [2])
+   File "cypari2/gen.pyx", line 4107, in cypari2.gen.Gen.__call__
+ sig_on()
+   File "cypari2/handle_error.pyx", line 213, in 
cypari2.handle_error._pari_err_handle
+ raise PariError(errnum, pari_error_string, clone_gen_noclear(E))
+ PariError: call_python: incorrect type in qfbcomp (t_VEC)
**
File 
"/<>/.pybuild/cpython3_3.10_cypari2/build/cypari2/closure.cpython-310-x86_64-linux-gnu.so",
 line ?, in cypari2.closure.objtoclosure
Failed example:
mul([1], [2])
Differences (ndiff with -expected +actual):
  Traceback (most recent call last):
- ...
- PariError: call_python: forbidden multiplication t_VEC (1 elts) * t_VEC 
(1 elts)
+   File "/usr/lib/python3.10/doctest.py", line 1350, in __run
+ exec(compile(example.source, filename, "single",
+   File "", line 1, in 
+ mul([1], [2])
+   File "cypari2/gen.pyx", line 4107, in cypari2.gen.Gen.__call__
+ sig_on()
+   File "cypari2/handle_error.pyx", line 213, in 
cypari2.handle_error._pari_err_handle
+ raise PariError(errnum, pari_error_string, clone_gen_noclear(E))
+ PariError: call_python: incorrect type in qfbcomp (t_VEC)
**
2 items had failures:
   1 of  19 in cypari2.closure.__test__.objtoclosure (line 145)
   1 of  19 in cypari2.closure.objtoclosure
***Test Failed*** 2 failures.

Testing cypari2.convert

Testing cypari2.gen
**
File 
"/<>/.pybuild/cpython3_3.10_cypari2/build/cypari2/gen.cpython-310-x86_64-linux-gnu.so",
 line ?, in cypari2.gen.Gen.__complex__
Failed example:
complex(g)
Differences (ndiff with -expected +actual):
- (2.2847006554165614+0j)
+ (1.118033988749895+0j)
**
File 
"/<>/.pybuild/cpython3_3.10_cypari2/build/cypari2/gen.cpython-310-x86_64-linux-gnu.so",
 line ?, in cypari2.gen.__test__.Gen.__complex__ (line 2006)
Failed example:
complex(g)
Differences (ndiff with -expected +actual):
- (2.2847006554165614+0j)
+ (1.118033988749895+0j)

Bug#1020455: dpigs should print arch-qualifiers (if needed)

[Jakub Wilk]

Package: debian-goodies
Version: 0.88.1

I've stumbled upon this oddity:

$ dpigs -n 99 | grep -w libllvm14
117011 libllvm14
107495 libllvm14

Huh? OK, I do have two libllvm14 packages installed (thanks to 
multi-arch), but this still looks weird...


In constrast, "dpkg-query -W" adds architecture qualifiers for 
"Multi-Arch: same" and foreign-architecture packages, avoiding such 
ambiguities:


$ dpkg-query -W 'libllvm14:*' | cut -f1
libllvm14:amd64
libllvm14:i386


-- System Information:
Architecture: i386
Foreign Architectures: amd64

Versions of packages debian-goodies recommends:
ii  apt2.5.2
ii  curl   7.85.0-1
ii  dctrl-tools2.24-3
ii  elfutils   0.187-2
ii  equivs 2.3.1
ii  libipc-system-simple-perl  1.30-1
ii  libfile-slurper-perl   0.013-1
ii  libfile-which-perl 1.27-1
ii  man-db 2.10.2-3
ii  perl   5.34.0-5
ii  procps 2:3.3.17-7+b1
ii  python33.10.6-1
ii  sensible-utils 0.0.17
ii  dialog 1.3-20211214-1

--
Jakub Wilk

Bug#1020454: RFP: golang-freecumextremist-themusicgod1-memsize -- computes the size of your object graph

[Jeffrey Cliff]

Package: wnpp
Severity: wishlist
* Package name: golang-freecumextremist-themusicgod1-memsize
  Upstream Author :   Felix Lange
* URL : https://git.freecumextremist.com/themusicgod1/memsize
* License : MIT
  Programming Lang: go
  Description : computes the size of your object graph

For any Go object, it can compute the amount of memory referenced by the
object.  Almost all Go types are supported, except for function pointers.
If your program provides an HTTP server for debugging you can also add an
interactive memsize tool there and use it from a web browser.

Bug#1020453: docker.io: consider backporting to stable

[Libor Klepáč]

Package: docker.io
Followup-For: Bug #908603

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

- -BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hello Maintainers,
could you please consider backporting docker.io version 20.10.17 to stable?

We are hitting problem with graylog docker image.
https://github.com/Graylog2/graylog-docker/issues/217

Solution seems to be using docker at least in version 20.10.10 or running with 
seccomp=unconfirmed.

Unfortunately it's not possible to use package from testing due to libc6 
dependency.

Thanks for answer,
Libor


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

Kernel: Linux 5.18.0-4-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=cs_CZ.UTF-8, LC_CTYPE=cs_CZ.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 docker.io depends on:
ii  adduser3.129
ii  containerd 1.6.8~ds1-1
ii  init-system-helpers1.65.2
ii  iptables   1.8.8-1
ii  libc6  2.34-8
ii  libdevmapper1.02.1 2:1.02.185-1
ii  libsystemd0251.4-3
ii  lsb-base   11.4
ii  runc   1.1.4+ds1-1
ii  sysvinit-utils [lsb-base]  3.05-6
ii  tini   0.19.0-1

Versions of packages docker.io recommends:
ii  apparmor 3.0.7-1
ii  ca-certificates  20211016
pn  cgroupfs-mount   
ii  git  1:2.37.2-1
ii  needrestart  3.6-2
ii  xz-utils 5.2.5-2.1

Versions of packages docker.io suggests:
pn  aufs-tools 
ii  btrfs-progs5.19-1
ii  debootstrap1.0.127
pn  docker-doc 
ii  e2fsprogs  1.46.6~rc1-1
pn  rinse  
pn  rootlesskit
ii  xfsprogs   5.19.0-1
pn  zfs-fuse | zfsutils-linux  

- - -- no debconf information

- -BEGIN PGP SIGNATURE-

iQJJBAEBCAAzFiEEPGZVVU37tFmB0TQv8O+MbsKfR44FAmMrdNcVHGxpYm9yLmts
ZXBhY0BiY29tLmN6AAoJEPDvjG7Cn0eOQlcQAJnjO7FRqOtHOPUDNrW7SYMfsmIt
tnUOCqD7vISHhcRRLVsItUw9eRcLcUk6RPuuYU/3Big5Fn0ADR0WfaNHBxKZsnoD
6RZCetX8NGEIlNP1ZEEMfVoXWl3qePW+TCXRKt2IHMvKOPWuyjykV5gnnTwUyqnO
VfVaVmdda7PT4xhmAzWOuEfAYZu7m1qzeKw4l1vs0BestTVcRCkWDYl+1EPQmZO/
9tE8mHsiDdm1imLlS/X1kawmTBDFZiTreF1Ft19t69Dy5DvQBg2dwpcXVPRiea1E
EjdiHho3I2aPwLFVIv7OFqzpMK+zt1V9nQExUgp245zCmy2GxcLqtoMokWazC2jN
EP//r3MwbukQklzRr7+IN3AtjP7EIUAJzV+CcBYrgjq3HDxEIh1F1KYyC6qNkmGh
XK7FLBHrWIh0epFou47/yrzUYF8TVNlPgVSZENpNSS3A/snNnZPEj1nNbVvHQaXJ
UBddzC0bDAmcxj1ZOmHhfG/IGWxJHMBJQoq6fZbtmNUnY9BHb0EZJtVupFzIppW1
r2527kgnnfS9bHM68hrN8ur3rogZsY5u73a+Rz+UcL+g5r18oP2CoJmJr0I1+As0
L8w8psD95d73jEDryKW4+LrrVpQIOFXfa9E0WC4fbsp5GvNdDdRzVxGa61+55o43
VC4ZEVuFYImmlw+n
=XBaB
- -END PGP SIGNATURE-

-BEGIN PGP SIGNATURE-

iQJJBAEBCAAzFiEEPGZVVU37tFmB0TQv8O+MbsKfR44FAmMrdSIVHGxpYm9yLmts
ZXBhY0BiY29tLmN6AAoJEPDvjG7Cn0eOj1MP/jgmHT8nfNJ7HXJXAgJw/nHwoIh0
QoTiS2u9tC804iZ9HvvNrXF+0CBeFFCOVzWlN+hcabgPnA1xY6byYXvHK1o6477W
MK5RXmqX2uqgmbJG0RAJlpraEty2lElTC0B3EvIIypy2TnSTS8D38bS2fN6021j9
dpYyLhZPcxIpR9QhYI20fTW3Okkp6thSiz5UDWpAw4/yHLt16Boh/vDHhAVa/mms
3SELHScThXsuCCzHYVfPW2p7UoKul61oWLsb6QmUhajeOzEC4hb6og61HrdKv4iN
1iYnRgvqid97CPgC4ZK4b0PleVTcFJlxEKtI75IOzXimaRHU9PHNBRf8udJ+hQTI
TB/1rJwWHdjBOlEx1ChVPSXjHKtmB83GQblsWeHMt8q+OQCjl9u72k4hhY+LK9JC
z7rioIjH338QETppasJBYKnvnOiBDvOlAgJUB4PPwr0lUlLcKcVYRhgymU2KZ2Nk
d1g9c3svt4BCT+wmIZTzeCyhN6eZVHdCk2DKbv7hd5d9+mTIaiiL42wCYmCL/C4J
3WaVkmn8qCzVdgu0wxzmW/k3Ed9py9xZySr095hW9GbR9AroGHoKg4Wr/Z/P04V9
bpnWBlSP/UiLwxR+mApSNNDneb9g4DxgnLKpXpUSI42e372MaExHzFRYlXVyH3ii
qHBdiUOkgxpckqtS
=jnYv
-END PGP SIGNATURE-

Bug#1020452: kodi: 20 Nexus with upstream/Debian libdvdnav4 6.1.1 does not work - call to undefined functions

[Alban Browaeys]

Package: kodi
Version: 2:20.0~alpha2+dfsg1-1+b1
Severity: normal


Dear maintenair,

I tried to play a DVD from kodi 20 (bookworm).
The disk was detected and I clicked the play disk, it failed with:
2022-09-21 21:57:41.791 T:156341 warning : Unable to resolve: 
libdvdnav-x86_64-linux.so dvdnav_get_number_of_streams, reason: 
/usr/lib/x86_64-linux-gnu/kodi/system/players/VideoPlayer/libdvdnav-x86_64-linux.so:
 undefined symbol: dvdnav_get_number_of_streams
2022-09-21 21:57:41.791 T:156341   error : Unable to resolve exports 
from dll special://xbmcbin/system/players/VideoPlayer/libdvdnav-x86_64-linux.so
2022-09-21 21:57:41.801 T:156341info : VideoPlayer::OpenFile: 
/media/prahal/<...>/VIDEO_TS/VIDEO_TS.IFO
2022-09-21 21:57:41.801 T:156570info : Creating InputStream
2022-09-21 21:57:41.905 T:156570 warning : Unable to resolve: 
libdvdnav-x86_64-linux.so dvdnav_get_number_of_streams, reason: 
/usr/lib/x86_64-linux-gnu/kodi/system/players/VideoPlayer/libdvdnav-x86_64-linux.so:
 undefined symbol: dvdnav_get_number_of_streams
2022-09-21 21:57:41.905 T:156570   error : Unable to resolve exports 
from dll special://xbmcbin/system/players/VideoPlayer/libdvdnav-x86_64-linux.so
2022-09-21 21:57:41.905 T:156570   error : 
CVideoPlayer::OpenInputStream - error opening 
[/media/prahal/<...>/VIDEO_TS/VIDEO_TS.IFO]
2022-09-21 21:57:41.905 T:156570info : CVideoPlayer::OnExit()
2022-09-21 21:57:41.907 T:156382info : Deleting settings 
information for files /media/prahal/<...>/VIDEO_TS/VIDEO_TS.IFO
2022-09-21 21:57:41.909 T:156341info : CVideoPlayer::CloseFile()
2022-09-21 21:57:41.909 T:156341info : VideoPlayer: waiting for 
threads to exit
2022-09-21 21:57:41.909 T:156341info : VideoPlayer: finished 
waiting
2022-09-21 21:57:42.007 T:156397info : 
JELLYFIN.jellyfin_kodi.player -> INFO::jellyfin_kodi/player.py:377 --<[ 
playback ]
2022-09-21 21:57:43.049 T:156341 warning : CGUIWindowManager - 
HandleAction - ignoring action 0, because topmost modal dialog closing 
animation is running
2022-09-21 21:57:45.029 T:156397info : 
JELLYFIN.jellyfin_kodi.monitor -> INFO::jellyfin_kodi/monitor.py:85 [ playlist 
] cleared


Turns out those functoins are defined in the kodi shipped version of libdvdnav4 
6.1.1-Next-Nexus-Alpha2 but not in upstream libdvdnav4 6.1.1.
https://github.com/xbmc/libdvdnav/commits/6.1.1-Next-Nexus-Alpha2

Mind that upstream has these functions in its master branch but they are tagged 
for libdvdnav4 7.0.0 a realease.
https://code.videolan.org/videolan/libdvdnav/-/commits/master

I do not know if Debian could ship a libdvdnav4 pre 7.0.0 from master code. 
That would resolve the issue.

Kind regards,

Alban

What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

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


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

Kernel: Linux 5.19.0-1-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/bash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages kodi depends on:
ii  kodi-bin   2:20.0~alpha2+dfsg1-1+b1
ii  kodi-data  2:20.0~alpha2+dfsg1-1

Versions of packages kodi recommends:
ii  kodi-repository-kodi [kodi-repository]  2:19.1+dfsg2-2+deb11u1
pn  kodi-visualization-spectrum 

kodi suggests no packages.

-- no debconf information

Bug#1020451: "deborphan :" ignores architecture

[Jakub Wilk]

Package: deborphan
Version: 1.7.35

My native architecture is i386, but I have also a small number of amd64 
packages installed:


$ dpkg-query -W '*:i386' | wc -l
2489

$ dpkg-query -W '*:amd64' | wc -l
207

I'm getting exactly the same results when asking for libfoo:i386 and 
libfoo:amd64 rev-deps, e.g.:


$ deborphan libc6:amd64 | wc -l
2241

$ deborphan libc6:i386 | wc -l
2241


-- System Information:
Architecture: i386
Foreign Architectures: amd64

Versions of packages deborphan depends on:
ii  libc6  2.34-8

Versions of packages deborphan recommends:
ii  apt   2.5.2
ii  gettext-base  0.21-9

--
Jakub Wilk

Bug#1020450: ITP: golang-github-allan-simon-go-singleinstance -- Run only one instance of a software

[Ben Westover]

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

* Package name: golang-github-allan-simon-go-singleinstance
  Version : 1.0.0-1
  Upstream Author : Allan Simon
* URL : https://github.com/allan-simon/go-singleinstance
* License : Expat
  Programming Lang: Go
  Description : Have only one instance of a software running

 Cross plateform library to have only one instance of a software (based
 on python's tendo
 (https://github.com/pycontribs/tendo/blob/master/tendo/singleton.py)).

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

--
Ben Westover


OpenPGP_signature
Description: PGP signature

Bug#910389: cloudfoundry probably works for geth

[Jeffrey Cliff]

This package was requested as part of the dependency tree for geth but
since that time, golang-github-cloudfoundry-gosigar-dev seems to be the
standard API for this purpose and already in debian.  As such this can be
probably closed, and geth use that instead during packaging efforts

Jeff Cliff
-- 

End the campaign to Cancel Richard Stallman - go to stallmansupport.org !

Bug#1020449: deborphan needlessly adds arch qualifiers

[Jakub Wilk]

Package: deborphan
Version: 1.7.35

deborphan adds architecture qualifiers to all packages, even when 
there's no ambiguity:


$ deborphan
libcroco-tools:i386
libsdl1.2-compat-shim:i386
libuninameslist1:i386
sntp:all
vrms:all

Contrast this with dpkg-query(1), which only adds the qualifiers for
"Multi-Arch: same" or foreign-architecture packages:

$ dpkg-query -W $(deborphan) | cut -f1
libcroco-tools
libsdl1.2-compat-shim:i386
libuninameslist1:i386
sntp
vrms


-- System Information:
Architecture: i386
Foreign Architectures: amd64

Versions of packages deborphan depends on:
ii  libc6  2.34-8

Versions of packages deborphan recommends:
ii  apt   2.5.2
ii  gettext-base  0.21-9

--
Jakub Wilk

Bug#1020430: usrmerge: cannot handle "open" binary when both kbd and xdg-utils are installed

[Giuseppe Sacco]

Il giorno mer, 21/09/2022 alle 18.26 +0200, Ansgar ha scritto:
> [...]
> Is /bin/open a symlink to openvt on your system?
> 

Yes, it is.

Bye,
Giuseppe

Bug#1020448: deborphan: duplicates in rev-dep list

[Jakub Wilk]

Package: deborphan
Version: 1.7.35

$ deborphan dconf-gsettings-backend
dconf-gsettings-backend:i386
  bookworm:i386
  bookworm:i386
  dconf-service:i386
  five-or-more:i386
  five-or-more:i386
  font-manager:i386
  font-manager:i386
  font-viewer:i386
  font-viewer:i386
  gsettings-desktop-schemas:all
  gsettings-desktop-schemas:all
  libgtk-3-common:all
  libgtk-3-common:all
  libgtk-4-common:all
  libgtk-4-common:all
  swell-foop:i386
  swell-foop:i386


Almost every package is listed twice for some reason...


-- System Information:
Architecture: i386
Foreign Architectures: amd64

--
Jakub Wilk

Bug#1005359: xserver-xorg-core: Intel HD Graphics 620: blank screen

[Stefan Monnier]

Jakub Wilk [2022-02-11 23:17:58] wrote:
> After recent upgrades, the X server no longer works for me: I get only 
> blank screen. Worse, the blankness remains even after I zap the server.
> Downgrading xserver-xorg-core to 2:1.20.14-1 fixed it for me.

I'm not sure if I suffer from the same problem, but I'm seeing similar
symptoms here on my Librem mini.

I run Debian testing on this machine and since I had not rebooted it in
a while I don't know which version of Xorg I've been happily running
last, but after an `apt full-upgrade` I did a reboot and as soon as gdm
launched Xorg, the screens (I have two monitors connected) went black.
I couldn't find a way to bring the screens back to life, short of
rebooting: I tried to stop Xorg/gdm, I tried suspend+resume, I tried to
use lightdm.

I downgraded to `xserver-xorg-core/stable` and things are back
to normal.

I attach the Xorg.log from when it got me a black screen.


Stefan
[65.676] _XSERVTransSocketUNIXCreateListener: ...SocketCreateListener() 
failed
[65.676] _XSERVTransMakeAllCOTSServerListeners: server already running
[65.676] (--) Log file renamed from 
"/var/lib/gdm3/.local/share/xorg/Xorg.pid-2189.log" to 
"/var/lib/gdm3/.local/share/xorg/Xorg.1.log"
[65.677] 
X.Org X Server 1.21.1.4
X Protocol Version 11, Revision 0
[65.677] Current Operating System: Linux lechazo 5.16.0-3-amd64 #1 SMP 
PREEMPT Debian 5.16.11-1 (2022-02-25) x86_64
[65.677] Kernel command line: BOOT_IMAGE=/vmlinuz-5.16.0-3-amd64 
root=/dev/mapper/Alfajor-root ro fbcon=rotate:3
[65.677] xorg-server 2:21.1.4-1 (https://www.debian.org/support) 
[65.677] Current version of pixman: 0.40.0
[65.677]Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
[65.677] Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[65.677] (==) Log file: "/var/lib/gdm3/.local/share/xorg/Xorg.1.log", Time: 
Wed Sep 21 15:16:48 2022
[65.677] (==) Using system config directory "/usr/share/X11/xorg.conf.d"
[65.677] (==) No Layout section.  Using the first Screen section.
[65.677] (==) No screen section available. Using defaults.
[65.677] (**) |-->Screen "Default Screen Section" (0)
[65.677] (**) |   |-->Monitor ""
[65.678] (==) No monitor specified for screen "Default Screen Section".
Using a default monitor configuration.
[65.678] (==) Automatically adding devices
[65.678] (==) Automatically enabling devices
[65.678] (==) Automatically adding GPU devices
[65.678] (==) Automatically binding GPU devices
[65.678] (==) Max clients allowed: 256, resource mask: 0x1f
[65.678] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist.
[65.678]Entry deleted from font path.
[65.678] (==) FontPath set to:
/usr/share/fonts/X11/misc,
/usr/share/fonts/X11/100dpi/:unscaled,
/usr/share/fonts/X11/75dpi/:unscaled,
/usr/share/fonts/X11/Type1,
/usr/share/fonts/X11/100dpi,
/usr/share/fonts/X11/75dpi,
built-ins
[65.678] (==) ModulePath set to "/usr/lib/xorg/modules"
[65.678] (II) The server relies on udev to provide the list of input 
devices.
If no devices become available, reconfigure udev or disable 
AutoAddDevices.
[65.678] (II) Loader magic: 0x568a97a0
[65.678] (II) Module ABI versions:
[65.678]X.Org ANSI C Emulation: 0.4
[65.678]X.Org Video Driver: 25.2
[65.678]X.Org XInput driver : 24.4
[65.678]X.Org Server Extension : 10.0
[65.678] (++) using VT number 1

[65.680] (II) systemd-logind: took control of session 
/org/freedesktop/login1/session/c2
[65.681] (II) xfree86: Adding drm device (/dev/dri/card0)
[65.681] (II) Platform probe for 
/sys/devices/pci:00/:00:02.0/drm/card0
[65.681] (II) systemd-logind: got fd for /dev/dri/card0 226:0 fd 13 paused 0
[65.683] (--) PCI:*(0@0:2:0) 8086:3ea0:8086:2212 rev 0, Mem @ 
0xd000/16777216, 0xc000/268435456, I/O @ 0x3000/64, BIOS @ 
0x/131072
[65.683] (II) LoadModule: "glx"
[65.683] (II) Loading /usr/lib/xorg/modules/extensions/libglx.so
[65.684] (II) Module glx: vendor="X.Org Foundation"
[65.684]compiled for 1.21.1.4, module version = 1.0.0
[65.684]ABI class: X.Org Server Extension, version 10.0
[65.684] (==) Matched modesetting as autoconfigured driver 0
[65.684] (==) Matched fbdev as autoconfigured driver 1
[65.684] (==) Matched vesa as autoconfigured driver 2
[65.684] (==) Assigned the driver to the xf86ConfigLayout
[65.684] (II) LoadModule: "modesetting"
[65.684] (II) Loading /usr/lib/xorg/modules/drivers/modesetting_drv.so
[65.684] (II) Module modesetting: vendor="X.Org Foundation"
[65.684]compiled for 1.21.1.4, module version = 

Bug#1020447: src:aircrack-ng: fails to migrate to testing for too long: not build on s390x

[Paul Gevers]

Source: aircrack-ng
Version: 1:1.6+git20210130.91820bc-2
Severity: serious
Control: close -1 1:1.7-3
Tags: sid bookworm
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 60 days as having a Release Critical bug in 
testing [1]. Your package src:aircrack-ng has been trying to migrate for 
69 days [2]. Hence, I am filing this bug. Your package stopped building 
on s390x, because it FTBFS there, but the binaries are still lingering 
around. The s390x situation needs to be resolved somehow.


If a package is out of sync between unstable and testing for a longer 
period, this usually means that bugs in the package in testing cannot be 
fixed via unstable. Additionally, blocked packages can have impact on 
other packages, which makes preparing for the release more difficult. 
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that 
hamper the migration of their package in a timely manner.


This bug will trigger auto-removal when appropriate. As with all new 
bugs, there will be at least 30 days before the package is auto-removed.


I have immediately closed this bug with the version in unstable, so if 
that version or a later version migrates, this bug will no longer affect 
testing. I have also tagged this bug to only affect sid and bookworm, so 
it doesn't affect (old-)stable.


If you believe your package is unable to migrate to testing due to 
issues beyond your control, don't hesitate to contact the Release Team.


Paul

[1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html
[2] https://qa.debian.org/excuses.php?package=aircrack-ng



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1020446: gdisk: FTBFS with popt 1.19+dfsg-1~exp1

[Håvard F . Aasen]

Source: gdisk
Severity: important
Tags: ftbfs

Hi,

gdisk FTBFS and has a failing autopkgtest with popt 1.19+dfsg-1~exp1
from experimental. Build log and log from autopkgtest is attached.

This was reported upstream a while ago [1], and a partial fix was
applied [2]. This was later found insufficient and a new fix has been
proposed [3], as of this mail, the patch has not been merged.
FWIW, Fedora is using this patch [4].

Regards,
Håvard


[1] https://sourceforge.net/p/gptfdisk/mailman/message/37640877/
[2] 
https://sourceforge.net/p/gptfdisk/code/ci/5d5e76d369a412bfb3d2cebb5fc0a7509cef878d/
[3] https://sourceforge.net/p/gptfdisk/code/merge-requests/28/
[4] 
https://src.fedoraproject.org/fork/pmatilai/rpms/gdisk/raw/71100f6fd84dd21f1346917e4fa84a2eccdb70c3/f/gdisk-1.0.9-poptmisuse.patchautopkgtest [17:43:32]: starting date: 2022-09-20
autopkgtest [17:43:32]: version 5.25
autopkgtest [17:43:32]: host ci-worker01; command line: /usr/bin/autopkgtest --no-built-binaries '--setup-commands=echo '"'"'gdisk unstable/amd64'"'"' > /var/tmp/debci.pkg 2>&1 || true' '--setup-commands=echo '"'"'Acquire::Retries "10";'"'"' > /etc/apt/apt.conf.d/75retry 2>&1 || true' --user debci --apt-upgrade --add-apt-release=experimental --pin-packages=experimental=src:popt --output-dir /tmp/debci-worker-26264295-p2XpCgn6gv/autopkgtest-incoming/unstable/amd64/g/gdisk/26264295 gdisk -- lxc --sudo --name ci-263-5ce3cb6a autopkgtest-unstable-amd64
autopkgtest [17:43:36]:  test bed setup
Get:1 http://deb.debian.org/debian experimental InRelease [97.5 kB]
Get:2 http://deb.debian.org/debian experimental/contrib Sources [1,820 B]
Get:3 http://deb.debian.org/debian experimental/non-free Sources [2,512 B]
Get:4 http://deb.debian.org/debian experimental/main Sources [447 kB]
Get:5 http://deb.debian.org/debian experimental/non-free amd64 Packages [7,388 B]
Get:6 http://deb.debian.org/debian experimental/contrib amd64 Packages [6,056 B]
Get:7 http://deb.debian.org/debian experimental/main amd64 Packages [402 kB]
Fetched 964 kB in 1s (1,200 kB/s)
Reading package lists...
Get:1 http://deb.debian.org/debian unstable InRelease [158 kB]
Get:2 http://deb.debian.org/debian-debug unstable-debug InRelease [56.7 kB]
Hit:3 http://deb.debian.org/debian experimental InRelease
Get:4 http://deb.debian.org/debian unstable/main Sources.diff/Index [63.6 kB]
Get:5 http://deb.debian.org/debian unstable/non-free Sources.diff/Index [63.3 kB]
Get:6 http://deb.debian.org/debian unstable/contrib Sources.diff/Index [63.3 kB]
Get:7 http://deb.debian.org/debian unstable/main amd64 Packages.diff/Index [63.6 kB]
Get:8 http://deb.debian.org/debian unstable/non-free amd64 Packages.diff/Index [63.3 kB]
Get:9 http://deb.debian.org/debian-debug unstable-debug/main Sources.diff/Index [63.6 kB]
Get:10 http://deb.debian.org/debian-debug unstable-debug/contrib Sources.diff/Index [63.3 kB]
Get:11 http://deb.debian.org/debian-debug unstable-debug/non-free Sources.diff/Index [63.3 kB]
Get:12 http://deb.debian.org/debian-debug unstable-debug/non-free amd64 Packages.diff/Index [63.3 kB]
Get:13 http://deb.debian.org/debian-debug unstable-debug/main amd64 Packages.diff/Index [63.6 kB]
Get:14 http://deb.debian.org/debian unstable/main Sources T-2022-09-20-1646.49-F-2022-09-20-1106.00.pdiff [22.7 kB]
Get:15 http://deb.debian.org/debian unstable/non-free Sources T-2022-09-20-1646.49-F-2022-09-20-1646.49.pdiff [31 B]
Get:16 http://deb.debian.org/debian unstable/contrib Sources T-2022-09-20-1646.49-F-2022-09-20-1646.49.pdiff [31 B]
Get:17 http://deb.debian.org/debian unstable/main amd64 Packages T-2022-09-20-1646.49-F-2022-09-20-1106.00.pdiff [36.2 kB]
Get:18 http://deb.debian.org/debian unstable/non-free amd64 Packages T-2022-09-20-1106.00-F-2022-09-20-1106.00.pdiff [5,854 B]
Get:14 http://deb.debian.org/debian unstable/main Sources T-2022-09-20-1646.49-F-2022-09-20-1106.00.pdiff [22.7 kB]
Get:16 http://deb.debian.org/debian unstable/contrib Sources T-2022-09-20-1646.49-F-2022-09-20-1646.49.pdiff [31 B]
Get:15 http://deb.debian.org/debian unstable/non-free Sources T-2022-09-20-1646.49-F-2022-09-20-1646.49.pdiff [31 B]
Get:17 http://deb.debian.org/debian unstable/main amd64 Packages T-2022-09-20-1646.49-F-2022-09-20-1106.00.pdiff [36.2 kB]
Get:18 http://deb.debian.org/debian unstable/non-free amd64 Packages T-2022-09-20-1106.00-F-2022-09-20-1106.00.pdiff [5,854 B]
Get:19 http://deb.debian.org/debian-debug unstable-debug/main Sources T-2022-09-20-1646.49-F-2022-09-20-1106.00.pdiff [19.2 kB]
Get:19 http://deb.debian.org/debian-debug unstable-debug/main Sources T-2022-09-20-1646.49-F-2022-09-20-1106.00.pdiff [19.2 kB]
Get:20 http://deb.debian.org/debian-debug unstable-debug/contrib Sources T-2022-09-20-1646.49-F-2022-09-20-1646.49.pdiff [31 B]
Get:21 http://deb.debian.org/debian-debug unstable-debug/non-free Sources T-2022-09-20-1106.00-F-2022-09-20-1106.00.pdiff [887 B]
Get:20 http://deb.debian.org/debian-debug unstable-debug/contrib Sources 

Bug#1017993: reverse dependencies

[Samuel Henrique]

Hello Paul,

On Wed, 21 Sept 2022 at 19:58, Paul Gevers  wrote:
> On 21-09-2022 20:50, Samuel Henrique wrote:
> > Please let me know if there is anything besides aircrack-ng blocked by
> > this, as it increases the priority of fixing this.
>
> Well, I pinged you because I noticed the bug wasn't forwarded to you. I
> looked because aircrack-ng showed up in my out-of-sync script, that I
> use to file RC bugs for packages being out-of-sync between unstable and
> testing. The reason why I didn't file the bug is because you already
> took action to file the RM bug. An RC bug will cause autoremoval in due
> time.

Got it, I don't wanna cause you more work, but feel free to go ahead
with the RC bug, that can serve as a deadline for me to solve the
issue.

> > [0] Since most of the reverse deps will also have to be removed, I
> > think the only one which stays is forensics-all.
>
> For architecture specific problems we have porters. Have you considered
> contacting them?

I haven't considered that, no, I'll reach out to them, thanks for the
suggestion.

Regards,

-- 
Samuel Henrique 

Bug#1020445: numba: autopkgtest regression on ppc64el: inf != 0.625

[Paul Gevers]

Source: numba
Version: 0.52.0-5
Severity: serious
User: debian...@lists.debian.org
Usertags: regression

Dear maintainer(s),

Your package has an autopkgtest, great. However, it recently started
to fail in testing on ppc64el. It also has never passed on armel, armhf 
and s390x. I'm not sure what to make of all the recent migration run 
failures on amd64, arm64 and i386, but the test *appears* to be flaky.


Paul

https://ci.debian.net/data/autopkgtest/testing/ppc64el/n/numba/26229968/log.gz

==
FAIL: test_ldexp (numba.tests.test_mathlib.TestMathLib)
--
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/numba/tests/test_mathlib.py", 
line 648, in test_ldexp

self.assertPreciseEqual(cfunc(*args), pyfunc(*args))
  File "/usr/lib/python3/dist-packages/numba/tests/support.py", line 
378, in assertPreciseEqual
self.fail("when comparing %s and %s: %s" % (first, second, 
failure_msg))

AssertionError: when comparing inf and 0.625: inf != 0.625

==
FAIL: test_ldexp_npm (numba.tests.test_mathlib.TestMathLib)
--
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/numba/tests/test_mathlib.py", 
line 651, in test_ldexp_npm

self.test_ldexp(flags=no_pyobj_flags)
  File "/usr/lib/python3/dist-packages/numba/tests/test_mathlib.py", 
line 648, in test_ldexp

self.assertPreciseEqual(cfunc(*args), pyfunc(*args))
  File "/usr/lib/python3/dist-packages/numba/tests/support.py", line 
378, in assertPreciseEqual
self.fail("when comparing %s and %s: %s" % (first, second, 
failure_msg))

AssertionError: when comparing inf and 0.625: inf != 0.625



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1020444: /usr/bin/sample is too generic

[Jakub Wilk]

Package: barcode
Version: 0.99-6

$ dpkg -L barcode | grep -w sample
/usr/bin/sample

This is way too generic for a program name.
Please either rename it or remove it.


-- System Information:
Architecture: i386

--
Jakub Wilk

Bug#1020443: bullseye-pu: package libbluray/1:1.2.1-4+deb11u2

[Sebastian Ramacher]

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

[ Reason ]
The Oracle Java Update from April 2022 broke libbluray. The
corresponding FTBFS bug is reported as #1011716, but it also causes
runtime issues.

[ Impact ]
BD-J support in libbluray using applications stays broken.

[ Tests ]
The change is available in testing since June without regressions.

[ Risks ]
Given there were no regressions reports so far, the risks should be
pretty low.

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

[ Changes ]
The changes are attached and only apply one upstream patch.

[ Other info ]
I have already uploaded the package to pu.

Cheers
-- 
Sebastian Ramacher
diff --git a/debian/changelog b/debian/changelog
index 40e3021..0e16de4 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+libbluray (1:1.2.1-4+deb11u2) bullseye; urgency=medium
+
+  * debian/patches: Apply upstream fix for Oracle Java CPU from April 2022
+(Closes: #1011716)
+
+ -- Sebastian Ramacher   Wed, 21 Sep 2022 21:25:08 +0200
+
 libbluray (1:1.2.1-4+deb11u1) bullseye; urgency=medium
 
   * debian/gbp.conf: Switch to bullseye branch
diff --git 
a/debian/patches/0002-Fix-build-failure-after-Oracle-Java-CPU-for-April-20.patch
 
b/debian/patches/0002-Fix-build-failure-after-Oracle-Java-CPU-for-April-20.patch
new file mode 100644
index 000..2807977
--- /dev/null
+++ 
b/debian/patches/0002-Fix-build-failure-after-Oracle-Java-CPU-for-April-20.patch
@@ -0,0 +1,30 @@
+From: Fridrich Strba 
+Date: Mon, 25 Apr 2022 14:28:58 +0300
+Subject: Fix build failure after Oracle Java CPU for April 2022
+
+---
+ src/libbluray/bdj/java/java/io/BDFileSystem.java | 11 +++
+ 1 file changed, 11 insertions(+)
+
+diff --git a/src/libbluray/bdj/java/java/io/BDFileSystem.java 
b/src/libbluray/bdj/java/java/io/BDFileSystem.java
+index 03add5d..fabe57b 100644
+--- a/src/libbluray/bdj/java/java/io/BDFileSystem.java
 b/src/libbluray/bdj/java/java/io/BDFileSystem.java
+@@ -227,6 +227,17 @@ public abstract class BDFileSystem extends FileSystem {
+ return fs.isAbsolute(f);
+ }
+ 
++public boolean isInvalid(File f) {
++try {
++Method m = fs.getClass().getDeclaredMethod("isInvalid", new 
Class[] { File.class });
++Object[] args = new Object[] {(Object)f};
++Boolean result = (Boolean)m.invoke(fs, args);
++return result.booleanValue();
++} finally {
++return false;
++}
++}
++
+ public String resolve(File f) {
+ if (!booted)
+ return fs.resolve(f);
diff --git a/debian/patches/series b/debian/patches/series
index 16342b0..83d4e1b 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1,2 +1,3 @@
 0001-Do-not-download-image-from-the-web.patch
+0002-Fix-build-failure-after-Oracle-Java-CPU-for-April-20.patch
 0003-Update-check-for-new-libudfread-pkg-config-file-name.patch

Bug#1020442: heimdal breaks openldap autopkgtest: test smbk5pwd

[Paul Gevers]

Source: heimdal, openldap
Control: found -1 heimdal/7.7.0+dfsg-6
Control: found -1 openldap/2.5.12+dfsg-2
Severity: serious
Tags: sid bookworm
User: debian...@lists.debian.org
Usertags: breaks needs-update

Dear maintainer(s),

With a recent upload of heimdal the autopkgtest of openldap fails in 
testing when that autopkgtest is run with the binary packages of heimdal 
from unstable. It passes when run with only packages from testing (I 
note that the test in  unstable with the new version of openldap is also 
broken with seemingly the same output). In tabular form:


   passfail
heimdalfrom testing7.7.0+dfsg-6
openldap   from testing2.5.12+dfsg-2
all others from testingfrom testing

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

Currently this regression is blocking the migration of heimdal to 
testing [1]. Due to the nature of this issue, I filed this bug report 
against both packages. Can you please investigate the situation and 
reassign the bug to the right package?


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

Paul

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

https://ci.debian.net/data/autopkgtest/testing/amd64/o/openldap/26275057/log.gz

SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
adding new entry "cn=samba,cn=schema,cn=config"

SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
adding new entry "cn=hdb,cn=schema,cn=config"

SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
ldap_add: Other (e.g., implementation specific) error (80)
additional info:  handler exited with 1
modifying entry "cn=module{0},cn=config"

adding new entry "olcOverlay=smbk5pwd,olcDatabase={1}mdb,cn=config"

autopkgtest [00:24:46]: test smbk5pwd



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1018277: gnome-shell-extension-sound-device-chooser: needs update for GNOME Shell 43

[Jeremy Bicha]

Control: forwarded -1
https://github.com/kgshank/gse-sound-output-device-chooser/issues/258

Upstream added a poll to get feedback about whether to continue
development of the extension.

Thank you,
Jeremy Bicha

Bug#1020441: linux: autopkgtest needs update for new version of gcc-11

[Paul Gevers]

Source: linux
Version: 5.19.6-1
Severity: serious
X-Debbugs-CC: gcc...@packages.debian.org
Tags: sid bookworm
User: debian...@lists.debian.org
Usertags: needs-update
Control: affects -1 src:gcc-11

Dear maintainer(s),

With a recent upload of gcc-11 the autopkgtest of linux fails in testing 
when that autopkgtest is run with the binary packages of gcc-11 from 
unstable. It passes when run with only packages from testing (it also 
fails in testing). In tabular form:


   passfail
gcc-11 from testing11.3.0-6
linux  from testing5.19.6-1
all others from testingfrom testing

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

Currently this regression is blocking the migration of gcc-11 to testing 
[1]. Of course, gcc-11 shouldn't just break your autopkgtest (or even 
worse, your package), but it seems to me that the test "only" fails on 
"Unexpected warning" and your package needs to update to the new situation.


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


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

Paul

[1] https://qa.debian.org/excuses.php?package=gcc-11

https://ci.debian.net/data/autopkgtest/testing/amd64/l/linux/26272813/log.gz

I: Found quick flavour cloud-amd64
I: Build for 5.19.0-1-cloud-amd64
make: Entering directory '/usr/src/linux-headers-5.19.0-1-cloud-amd64'
test -e include/generated/autoconf.h -a -e include/config/auto.conf || (
\
echo >&2;\
echo >&2 "  ERROR: Kernel configuration is invalid.";  \
echo >&2 " include/generated/autoconf.h or 
include/config/auto.conf are missing.";\
echo >&2 " Run 'make oldconfig && make prepare' on kernel src to 
fix it.";	\

echo >&2 ;   \
/bin/false)
warning: the compiler differs from the one used to build the kernel
  The kernel was built by: gcc-11 (Debian 11.3.0-5) 11.3.0
  You are using:   gcc-11 (Debian 11.3.0-6) 11.3.0
make -f /usr/src/linux-headers-5.19.0-1-common/scripts/Makefile.build 
obj=/tmp/autopkgtest-lxc.8_h2xh0q/downtmp/autopkgtest_tmp/foo \

single-build= \
need-builtin=1 need-modorder=1
   gcc-11 
-Wp,-MMD,/tmp/autopkgtest-lxc.8_h2xh0q/downtmp/autopkgtest_tmp/foo/.foo.o.d 
-nostdinc -I/usr/src/linux-headers-5.19.0-1-common/arch/x86/include 
-I./arch/x86/include/generated 
-I/usr/src/linux-headers-5.19.0-1-common/include -I./include 
-I/usr/src/linux-headers-5.19.0-1-common/arch/x86/include/uapi 
-I./arch/x86/include/generated/uapi 
-I/usr/src/linux-headers-5.19.0-1-common/include/uapi 
-I./include/generated/uapi -include 
/usr/src/linux-headers-5.19.0-1-common/include/linux/compiler-version.h 
-include /usr/src/linux-headers-5.19.0-1-common/include/linux/kconfig.h 
-include 
/usr/src/linux-headers-5.19.0-1-common/include/linux/compiler_types.h 
-D__KERNEL__ -fmacro-prefix-map=/usr/src/linux-headers-5.19.0-1-common/= 
-Wall -Wundef -Werror=strict-prototypes -Wno-trigraphs 
-fno-strict-aliasing -fno-common -fshort-wchar -fno-PIE 
-Werror=implicit-function-declaration -Werror=implicit-int 
-Werror=return-type -Wno-format-security -std=gnu11 -mno-sse -mno-mmx 
-mno-sse2 -mno-3dnow -mno-avx -fcf-protection=none -m64 -falign-jumps=1 
-falign-loops=1 -mno-80387 -mno-fp-ret-in-387 
-mpreferred-stack-boundary=3 -mskip-rax-setup -mtune=generic 
-mno-red-zone -mcmodel=kernel -Wno-sign-compare 
-fno-asynchronous-unwind-tables -mindirect-branch=thunk-extern 
-mindirect-branch-register -mindirect-branch-cs-prefix 
-mfunction-return=thunk-extern -fno-jump-tables -mharden-sls=all 
-fno-delete-null-pointer-checks -Wno-frame-address 
-Wno-format-truncation -Wno-format-overflow 
-Wno-address-of-packed-member -O2 -fno-allow-store-data-races 
-Wframe-larger-than=2048 -fstack-protector-strong 
-Wimplicit-fallthrough=5 -Wno-main -Wno-unused-but-set-variable 
-Wno-unused-const-variable -fno-stack-clash-protection -pg 
-mrecord-mcount -mfentry -DCC_USING_FENTRY -Wdeclaration-after-statement 
-Wvla -Wno-pointer-sign -Wcast-function-type -Wno-stringop-truncation 
-Wno-stringop-overflow -Wno-restrict -Wno-maybe-uninitialized 
-Wno-alloc-size-larger-than -fno-strict-overflow -fno-stack-check 
-fconserve-stack -Werror=date-time -Werror=incompatible-pointer-types 
-Werror=designated-init -Wno-packed-not-aligned -g  -DMODULE 
-DKBUILD_BASENAME='"foo"' -DKBUILD_MODNAME='"foo"' 
-D__KBUILD_MODNAME=kmod_foo -c -o 
/tmp/autopkgtest-lxc.8_h2xh0q/downtmp/autopkgtest_tmp/foo/foo.o 

Bug#684021: ruby-sinatra: shouldn't break error processing if error logging is failed

[Lucas Kanashiro]

I checked the upstream git repository and the dump_errors! method is
still the same compared to version that was reported this bug. So in
theory, the problem still persists. I also did not find any upstream bug
for this issue, did someone do that? If no, I'd kindly ask to the
affected people to do so.

This bug was filed more than a decade ago and it is still open which
makes me think that this is not so important and we could close it out.
For now, let's keep it open to see if it gets any traction.

-- 
Lucas Kanashiro

Bug#1020432: cutecom: please package a newer version than 0.30.3 (which was released 02/2016)

[Roman Khimov]

Hello, Frank.

В письме от среда, 21 сентября 2022 г. 19:24:08 MSK пользователь Frank 
Dietrich написал:
> Please consider to update CuteCom in the Debian repository to a more
> recent version.

Thank you for reminding me about it. In fact there was an updated package in 
the bug 911378, but IIRC it was some freeze time back then so it wasn't 
accepted. I'll try to check/update it again this weekend.

-- 
 http://roman.khimov.ru
mailto: ro...@khimov.ru
gpg --keyserver hkp://subkeys.pgp.net --recv-keys 0xE5E055C3

Bug#1020404: luakit: aborts at start

[Markus Demleitner]

On Wed, Sep 21, 2022 at 11:36:08AM +0200, Arne Wichmann wrote:
> Bail out! ERROR:common/util.c:67:strip_ansi_escapes: assertion failed (err == 
> NULL): Error while compiling regular expression 
> ?[\u001b\u009b][[()#;?]*(?:[0-9]{1,4}(?:;[0-9]{0,4})*)?[0-9A-ORZcf-nqry=><]? 
> at char 3: unrecognised character following \ (g-regex-error-quark, 103)

Argl.  That's quite certainly the upstream bug
https://github.com/luakit/luakit/issues/1005

I've not commented on this because I was not really sure what
encoding the gchar *in would be -- if it's UCS-2, then the
complicated \u escapes make sense.  If it's UTF-8, a simple \x1b
would do the job.

Even more importantly, looking at where this code is being used (when
formatting tracebacks, and when writing via va_log when things are
going to a file), I'm now convinced that this is a lot less critical
than I first thought.  In particular, javascript console.log is *not*
sanitised at all, let alone by this code; to see that, run

  luakit http://www.tfiu.de/log-escape.html |& cat

(if you still have a running luakit somewhere) -- you'll see that the
colored messages are now b/w, but the escape sequence from javascript
is not filtered (which would feel like a good idea), so you end up
with a terminal writing in reverse video.

I hence felt it's ok to just experiment, and it seems we're talking
about UTF-8 strings here.

Can you build from https://salsa.debian.org/debian/luakit.git and see
whether the thing (a) builds and (b) whether luakit's log messages
are b/w when filtered through cat as above?

Thanks,

   Markus

Bug#1017993: reverse dependencies

[Paul Gevers]

Hi Samuel,

On 21-09-2022 20:50, Samuel Henrique wrote:

Thanks for the ping, I did see Thorsten's replies but I'm still
considering what to do, since removing aircrack-ng from s390x is gonna
take much more effort than what I was willing to spend on the
issue[0], at this stage it might be better to let it stay in s390x
with some of the features working, but I would have to address the
test failures still.

Please let me know if there is anything besides aircrack-ng blocked by
this, as it increases the priority of fixing this.


Well, I pinged you because I noticed the bug wasn't forwarded to you. I 
looked because aircrack-ng showed up in my out-of-sync script, that I 
use to file RC bugs for packages being out-of-sync between unstable and 
testing. The reason why I didn't file the bug is because you already 
took action to file the RM bug. An RC bug will cause autoremoval in due 
time.



[0] Since most of the reverse deps will also have to be removed, I
think the only one which stays is forensics-all.


For architecture specific problems we have porters. Have you considered 
contacting them?


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1017993: reverse dependencies

[Samuel Henrique]

Hey Paul,

On Thu, 15 Sept 2022 at 08:43, Paul Gevers  wrote:
> > there are reverse dependencies that needs to be taken care of:
> >
> >
> > Checking reverse dependencies...
> > # Broken Depends:
> > bully: bully
> > forensics-all: forensics-all
> > mdk3: mdk3
> > mdk4: mdk4
> > wifite: wifite
> >
> > # Broken Build-Depends:
> > wifite: aircrack-ng
> >
> >
> > In case they matter, this needs to be addressed first. Please remove the
> > moreinfo tag once that is done.
>
> You may have missed the question from Thorsten as I don't see you in the
> TO or CC. Can you have a look? aircrack-ng is out-of-sync between
> unstable and testing due to this.

Thanks for the ping, I did see Thorsten's replies but I'm still
considering what to do, since removing aircrack-ng from s390x is gonna
take much more effort than what I was willing to spend on the
issue[0], at this stage it might be better to let it stay in s390x
with some of the features working, but I would have to address the
test failures still.

Please let me know if there is anything besides aircrack-ng blocked by
this, as it increases the priority of fixing this.

Thank you,

[0] Since most of the reverse deps will also have to be removed, I
think the only one which stays is forensics-all.

-- 
Samuel Henrique 

Bug#1020440: src:xmonad-contrib: fails to migrate to testing for too long: part of unfinshed ghc transition?

[Paul Gevers]

Source: xmonad-contrib
Version: 0.16-1
Severity: serious
Control: close -1 0.17.0-1
Tags: sid bookworm
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 60 days as having a Release Critical bug in 
testing [1]. Your package src:xmonad-contrib has been trying to migrate 
for 61 days [2]. Hence, I am filing this bug. Your package is part of 
the unfinished ghc transition.


If a package is out of sync between unstable and testing for a longer 
period, this usually means that bugs in the package in testing cannot be 
fixed via unstable. Additionally, blocked packages can have impact on 
other packages, which makes preparing for the release more difficult. 
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that 
hamper the migration of their package in a timely manner.


This bug will trigger auto-removal when appropriate. As with all new 
bugs, there will be at least 30 days before the package is auto-removed.


I have immediately closed this bug with the version in unstable, so if 
that version or a later version migrates, this bug will no longer affect 
testing. I have also tagged this bug to only affect sid and bookworm, so 
it doesn't affect (old-)stable.


If you believe your package is unable to migrate to testing due to 
issues beyond your control, don't hesitate to contact the Release Team.


Paul

[1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html
[2] https://qa.debian.org/excuses.php?package=xmonad-contrib



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1020439: src:xmonad: fails to migrate to testing for too long: part of unfinshed ghc transition?

[Paul Gevers]

Source: xmonad
Version: 0.15-4
Severity: serious
Control: close -1 0.17.0-2
Tags: sid bookworm
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 60 days as having a Release Critical bug in 
testing [1]. Your package src:xmonad has been trying to migrate for 61 
days [2]. Hence, I am filing this bug. Your package is part of the 
unfinished ghc transition.


If a package is out of sync between unstable and testing for a longer 
period, this usually means that bugs in the package in testing cannot be 
fixed via unstable. Additionally, blocked packages can have impact on 
other packages, which makes preparing for the release more difficult. 
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that 
hamper the migration of their package in a timely manner.


This bug will trigger auto-removal when appropriate. As with all new 
bugs, there will be at least 30 days before the package is auto-removed.


I have immediately closed this bug with the version in unstable, so if 
that version or a later version migrates, this bug will no longer affect 
testing. I have also tagged this bug to only affect sid and bookworm, so 
it doesn't affect (old-)stable.


If you believe your package is unable to migrate to testing due to 
issues beyond your control, don't hesitate to contact the Release Team.


Paul

[1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html
[2] https://qa.debian.org/excuses.php?package=xmonad



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1020413: nmu: bind-dyndb-ldap_11.6-3

[Adam D. Barratt]

Control: tags -1 + bullseye

On Wed, 2022-09-21 at 13:47 +0200, Ondřej Surý wrote:
> nmu bind-dyndb-ldap_11.6-3 . ANY . bullseye . -m "rebuild for
> bind9_9.16.33-1~deb11u1"
> 
> Hi,
> 
> after the bind9_9.16.33-1~deb11u1 is release to bullseye-security,
> the
> bind-dyndb-ldap plugin will require binNMU.
> 

We can do that - once the packages are in p-u, because p-u chroots
don't pull in packages from the security archive - but it will mean
that users won't get the binNMUs until the next point release, which
probably isn't until November now.

Is that OK?

Regards,

Adam

Bug#1020438: ITP: libtwiggy-tls-perl -- Twiggy server with TLS support

[Damyan Ivanov]

Package: wnpp
Owner: Damyan Ivanov 
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org, debian-p...@lists.debian.org

* Package name: libtwiggy-tls-perl
  Version : 0.0020
  Upstream Author : Serhii Zasenko 
* URL : https://metacpan.org/release/Twiggy-TLS
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : Twiggy server with TLS support

Twiggy is a lightweight and fast HTTP iserver that can run PSGI 
applications.

Twiggy::TLS adds TLS support via Twiggy::Server::TLS - a subclass of
Twiggy::Server.

The package will be maintained under the umbrella of the Debian Perl Group.

--
Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.

Bug#1020287: vcmi: new vcmi provides files conflicting with existing game-data-packager recipe

[Johannes Schauer Marin Rodrigues]

Hi,

Quoting Alexandre Detiste (2022-09-19 12:57:29)
> The new vcmi tries to overwrite files previously provided by G-D-P generated
> homm3-en-data local package.  Which should be fixed ?
> 
> Is this VCMI_Tests_2011b.h3m file even free ?
> (then it would remain in G-D-P recipe)

upstream confirmed that the file is indeed DFSG-free. Thank you for bringing it
up!

> There might be other duplicated files.

Thanks for making sure that this is the only file!

Now we need to decide whether vcmi or homm3-en-data should drop the map.

I'd offer to drop it in vcmi just by adding VCMI_Tests_2011b.h3m to
Files-Excluded in d/copyright. The file is not needed at all to run vcmi, so
there is no problem with excluding it from the source package.

What do you think?

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1020437: clisp FTBFS with PARI 2.15.0

[Adrian Bunk]

Source: clisp
Version: 1:2.49.20210628.gitde01f0f-2
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/logs.php?pkg=clisp=1%3A2.49.20210628.gitde01f0f-2%2Bb1

...
make[2]: Entering directory '/<>/debian/build/pari'
/<>/debian/build/clisp -K base  -E UTF-8 -Emisc 1:1 -Epathname 1:1 
-norc -q -c /<>/modules/pari/desc2lisp.lisp -o ./
;; Compiling file /<>/modules/pari/desc2lisp.lisp ...
;; Wrote file /<>/debian/build/pari/desc2lisp.fas
0 errors, 0 warnings
/<>/debian/build/clisp -K base  -E UTF-8 -Emisc 1:1 -Epathname 1:1 
-norc -q -i desc2lisp -c /<>/modules/pari/pari.lisp -o ./ 
/usr/share/pari
;; Loading file /<>/debian/build/pari/desc2lisp.fas ...
;; Loaded file /<>/debian/build/pari/desc2lisp.fas
;; Compiling file /<>/modules/pari/pari.lisp ...
Reading "/usr/share/pari/pari.desc" (1,704,497 bytes)
WARNING: Existing name: "arg" (arg :INTERNAL)
WARNING: Existing name: "arity" (arity :INTERNAL)
WARNING: Existing name: "default" (default :INTERNAL)
WARNING: Existing name: "digits" (digits :INTERNAL)
*** - lines-to-desc: unknown field:
  "\\item $8192 = \\kbd{no_MinMax}$: do not print the boundary numbers (in 
both directions)."
The following functions were used but not defined:
 PARI::%I PARI::%component
0 errors, 4 warnings
make[2]: *** [Makefile:35: pari.c] Error 1

Bug#1019753: py-libzfs: Pushing from Experimental into Sid?

[Boyuan Yang]

Hi,

在 2022-09-21星期三的 13:04 -0300，William Grzybowski写道：
> Hello,
> 
> Unfortunately I have not had more time to maintain it.
> Feel free to take maintainership and do what's necessary.

Thanks for the info. I will make changes accordingly.

Best,
Boyuan Yang


> On Wed, Sep 14, 2022 at 3:18 PM Boyuan Yang  wrote:
> > Source: py-libzfs
> > Version: 0.0+git20220621.a99d1db-1
> > Severity: normal
> > X-Debbugs-CC: will...@grzy.org
> > pkg-zfsonlinux-de...@alioth-lists.debian.net
> > 
> > Dear Debian py-libzfs package maintainer,
> > 
> > I noticed that py-libzfs [1][2] entered Debian experimental in section
> > contrib back in 2019. There hasn't been much activity since then. I am
> > wondering if there is any reason of not releasing this software into
> > Sid, or
> > if we should do so before Debian 12 freeze and release.
> > 
> > Thanks,
> > Boyuan Yang
> > 
> > 
> > [1] https://tracker.debian.org/pkg/py-libzfs
> > [2] https://github.com/truenas/py-libzfs



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

Bug#1020436: giac FTBFS with PARI 2.15.0

[Adrian Bunk]

Source: giac
Version: 1.9.0.19+dfsg2-1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/logs.php?pkg=giac=1.9.0.19%2Bdfsg2-1%2Bb1

...
pari.cc: At global scope:
pari.cc:752:17: error: typedef ‘giac::PFGEN’ is initialized (use ‘decltype’ 
instead)
  752 |   typedef GEN (*PFGEN)(ANYARG);
  | ^
pari.cc:752:24: error: ‘ANYARG’ was not declared in this scope
  752 |   typedef GEN (*PFGEN)(ANYARG);
  |^~
pari.cc: In function ‘giac::gen giac::in_pari(const gen&, const context*)’:
pari.cc:829:26: warning: cast to pointer from integer of different size 
[-Wint-to-pointer-cast]
  829 |   argvec[k]= (GEN) v[j].val;
  |  ^~
pari.cc:847:33: warning: cast to pointer from integer of different size 
[-Wint-to-pointer-cast]
  847 |   argvec[k]=(long int*)(pos -1);
  | ^~~
pari.cc:855:31: warning: cast to pointer from integer of different size 
[-Wint-to-pointer-cast]
  855 | argvec[k]=(long int*) v[j].val;
  |   ^~~~
pari.cc:883:23: error: ‘PFGEN’ was not declared in this scope; did you mean 
‘GEN’?
  883 |   res = ((PFGEN)call)(_ARGS_);
  |   ^
  |   GEN
pari.cc:883:29: error: expected ‘)’ before ‘call’
  883 |   res = ((PFGEN)call)(_ARGS_);
  | ~   ^~~~
  | )
pari.cc:887:27: error: expected primary-expression before ‘int’
  887 |   m = (long)((int (*)(ANYARG))call)(_ARGS_);
  |   ^~~
pari.cc:887:27: error: expected ‘)’ before ‘int’
  887 |   m = (long)((int (*)(ANYARG))call)(_ARGS_);
  |  ~^~~
  |   )
pari.cc:887:56: error: expected ‘)’ before ‘;’ token
  887 |   m = (long)((int (*)(ANYARG))call)(_ARGS_);
  | ~  ^
  |)
pari.cc:891:21: error: expected primary-expression before ‘long’
  891 |   m = ((long (*)(ANYARG))call)(_ARGS_);
  | ^~~~
pari.cc:891:21: error: expected ‘)’ before ‘long’
  891 |   m = ((long (*)(ANYARG))call)(_ARGS_);
  |~^~~~
  | )
pari.cc:891:51: error: expected ‘)’ before ‘;’ token
  891 |   m = ((long (*)(ANYARG))call)(_ARGS_);
  |   ~   ^
  |   )
pari.cc:895:17: error: expected primary-expression before ‘void’
  895 |   ((void (*)(ANYARG))call)(_ARGS_);
  | ^~~~
pari.cc:895:17: error: expected ‘)’ before ‘void’
  895 |   ((void (*)(ANYARG))call)(_ARGS_);
  |~^~~~
  | )
pari.cc:895:47: error: expected ‘)’ before ‘;’ token
  895 |   ((void (*)(ANYARG))call)(_ARGS_);
  |   ~   ^
  |   )
make[3]: *** [Makefile:993: pari.lo] Error 1

Bug#1020287: vcmi: new vcmi provides files conflicting with existing game-data-packager recipe

[Alexandre Detiste]

Hi,

It's seems that it's just this only one file conflicting.

root@antec:~# diff -u <(dpkg -L homm3-en-data) <(dpkg -c
/var/cache/apt/archives/vcmi_1.0.0+dfsg-2_amd64.deb | awk '{print
substr($6,2)}') | grep ^\
 /usr/share/vcmi/Mods/vcmi/Maps/VCMI_Tests_2011b.h3m

The full details are in the recipe file here:
   
https://salsa.debian.org/games-team/game-data-packager/-/blob/master/data/heroes3.yaml

dpkg -L homm3-en-data
/.
/usr
/usr/share
/usr/share/doc
/usr/share/doc/homm3-en-data
/usr/share/doc/homm3-en-data/changelog.gz
/usr/share/doc/homm3-en-data/copyright
/usr/share/lintian
/usr/share/lintian/overrides
/usr/share/lintian/overrides/homm3-en-data
/usr/share/vcmi
/usr/share/vcmi/Data
/usr/share/vcmi/Data/H3ab_ahd.snd
/usr/share/vcmi/Data/H3ab_ahd.vid
/usr/share/vcmi/Data/H3ab_bmp.lod
/usr/share/vcmi/Data/H3ab_spr.lod
/usr/share/vcmi/Data/H3bitmap.lod
/usr/share/vcmi/Data/H3sprite.lod
/usr/share/vcmi/Data/Heroes3.snd
/usr/share/vcmi/Data/VIDEO.VID
/usr/share/vcmi/MP3
/usr/share/vcmi/MP3/AITHEME1.MP3
/usr/share/vcmi/MP3/AITHEME2.MP3
/usr/share/vcmi/MP3/AITheme0.mp3
/usr/share/vcmi/MP3/BladeABCampaign.mp3
/usr/share/vcmi/MP3/BladeDBCampaign.mp3
/usr/share/vcmi/MP3/BladeDSCampaign.mp3
/usr/share/vcmi/MP3/BladeFLCampaign.mp3
/usr/share/vcmi/MP3/BladeFWCampaign.mp3
/usr/share/vcmi/MP3/BladePFCampaign.mp3
/usr/share/vcmi/MP3/COMBAT01.MP3
/usr/share/vcmi/MP3/COMBAT02.MP3
/usr/share/vcmi/MP3/COMBAT03.MP3
/usr/share/vcmi/MP3/COMBAT04.MP3
/usr/share/vcmi/MP3/CampainMusic01.mp3
/usr/share/vcmi/MP3/CampainMusic02.mp3
/usr/share/vcmi/MP3/CampainMusic03.mp3
/usr/share/vcmi/MP3/CampainMusic04.mp3
/usr/share/vcmi/MP3/CampainMusic05.mp3
/usr/share/vcmi/MP3/CampainMusic06.mp3
/usr/share/vcmi/MP3/CampainMusic07.mp3
/usr/share/vcmi/MP3/CampainMusic08.mp3
/usr/share/vcmi/MP3/CampainMusic09.mp3
/usr/share/vcmi/MP3/CampainMusic10.mp3
/usr/share/vcmi/MP3/CampainMusic11.mp3
/usr/share/vcmi/MP3/CstleTown.mp3
/usr/share/vcmi/MP3/DIRT.MP3
/usr/share/vcmi/MP3/DUNGEON.MP3
/usr/share/vcmi/MP3/Defend Castle.mp3
/usr/share/vcmi/MP3/ElemTown.mp3
/usr/share/vcmi/MP3/EvilTheme.mp3
/usr/share/vcmi/MP3/FortressTown.mp3
/usr/share/vcmi/MP3/GRASS.MP3
/usr/share/vcmi/MP3/GoodTheme.mp3
/usr/share/vcmi/MP3/InfernoTown.mp3
/usr/share/vcmi/MP3/LAVA.MP3
/usr/share/vcmi/MP3/LoopLepr.mp3
/usr/share/vcmi/MP3/Lose Campain.mp3
/usr/share/vcmi/MP3/LoseCastle.mp3
/usr/share/vcmi/MP3/LoseCombat.mp3
/usr/share/vcmi/MP3/MAINMENU.MP3
/usr/share/vcmi/MP3/NeutralTheme.mp3
/usr/share/vcmi/MP3/RAMPART.MP3
/usr/share/vcmi/MP3/ROUGH.MP3
/usr/share/vcmi/MP3/Retreat Battle.mp3
/usr/share/vcmi/MP3/SAND.MP3
/usr/share/vcmi/MP3/SNOW.MP3
/usr/share/vcmi/MP3/SWAMP.MP3
/usr/share/vcmi/MP3/SecretTheme.mp3
/usr/share/vcmi/MP3/StrongHold.mp3
/usr/share/vcmi/MP3/Surrender Battle.mp3
/usr/share/vcmi/MP3/TowerTown.mp3
/usr/share/vcmi/MP3/UltimateLose.mp3
/usr/share/vcmi/MP3/Underground.mp3
/usr/share/vcmi/MP3/WATER.MP3
/usr/share/vcmi/MP3/Win Battle.mp3
/usr/share/vcmi/MP3/Win Scenario.mp3
/usr/share/vcmi/MP3/necroTown.mp3
/usr/share/vcmi/Maps
/usr/share/vcmi/Maps/A Viking We Shall Go Allied.h3m
/usr/share/vcmi/Maps/A Viking We Shall Go.h3m
/usr/share/vcmi/Maps/A Warm and Familiar Place.h3m
/usr/share/vcmi/Maps/Adventures of Jared Haret.h3m
/usr/share/vcmi/Maps/All for One.h3m
/usr/share/vcmi/Maps/And One for All.h3m
/usr/share/vcmi/Maps/Arrogance Allied.h3m
/usr/share/vcmi/Maps/Arrogance.h3m
/usr/share/vcmi/Maps/Ascension.h3m
/usr/share/vcmi/Maps/Back For Revenge - Allied.h3m
/usr/share/vcmi/Maps/Back For Revenge.h3m
/usr/share/vcmi/Maps/Barbarian Breakout.h3m
/usr/share/vcmi/Maps/Barbarian BreakoutA.h3m
/usr/share/vcmi/Maps/Battle of the Sexes Allied.h3m
/usr/share/vcmi/Maps/Battle of the Sexes.h3m
/usr/share/vcmi/Maps/Brave New World(Allies).h3m
/usr/share/vcmi/Maps/Brave New World.h3m
/usr/share/vcmi/Maps/Buried Treasure.h3m
/usr/share/vcmi/Maps/Carpe Diem - Allied.h3m
/usr/share/vcmi/Maps/Carpe Diem.h3m
/usr/share/vcmi/Maps/Caught in the Middle.h3m
/usr/share/vcmi/Maps/Chasing a Dream.h3m
/usr/share/vcmi/Maps/Crimson and Clover.h3m
/usr/share/vcmi/Maps/Crimson and CloverA.h3m
/usr/share/vcmi/Maps/Darwin's Prize(Allies).h3m
/usr/share/vcmi/Maps/Darwin's Prize.h3m
/usr/share/vcmi/Maps/Dawn of War.h3m
/usr/share/vcmi/Maps/Dead and Buried.h3m
/usr/share/vcmi/Maps/Deluge.h3m
/usr/share/vcmi/Maps/Divided Loyalties.h3m
/usr/share/vcmi/Maps/Divided LoyaltiesA.h3m
/usr/share/vcmi/Maps/Dragon Orb.h3m
/usr/share/vcmi/Maps/Dragon Pass (Allies).h3m
/usr/share/vcmi/Maps/Dragon Pass.h3m
/usr/share/vcmi/Maps/Dungeon Keeper.h3m
/usr/share/vcmi/Maps/Dwarven Gold.h3m
/usr/share/vcmi/Maps/Dwarven Tunnels(Allies).h3m
/usr/share/vcmi/Maps/Dwarven Tunnels.h3m
/usr/share/vcmi/Maps/Elbow Room(Allies).h3m
/usr/share/vcmi/Maps/Elbow Room.h3m
/usr/share/vcmi/Maps/Emerald Isles.h3m
/usr/share/vcmi/Maps/Emerald IslesA.h3m
/usr/share/vcmi/Maps/For Sale.h3m
/usr/share/vcmi/Maps/Fort Noxis.h3m
/usr/share/vcmi/Maps/Free for All.h3m
/usr/share/vcmi/Maps/Freedom.h3m
/usr/share/vcmi/Maps/Gelea's 

Bug#1020276: Fwd: Bug#1020276: linux-image-5.19.0-1-amd64: NFC device not detected

[Oliver Sander]

Thanks Mark,

I worked my way through these build instruction and got successfully to Step 15:
There, I don't know to do.  What is my target platform?  Is it "custom"?
If so, what are the correct values to set?

I also wonder whether that part is optional.  In 8./9. I make and install
the software.  Then I modify the code (in 15.) and make/install again (16./17.)
That's a bit confusing.

Running the demo after the first make/install also doesn't work:

~/linux_libnfc-nci(master)> sudo nfcDemoApp
nfcDemoApp: error while loading shared libraries: libnfc_nci_linux-1.so.0: 
cannot open shared object file: No such file or directory
~/linux_libnfc-nci(master)> echo $LD_LIBRARY_PATH
/usr/local/lib/
~/linux_libnfc-nci(master)> ls $LD_LIBRARY_PATH
libnfc_nci_linux-1.so.0  libnfc_nci_linux.la  pkgconfig  python3.10  
python3.9
libnfc_nci_linux-1.so.0.0.0  libnfc_nci_linux.so  python2.7  python3.8

That may be me doing something stupid, though.



smime.p7s
Description: S/MIME Cryptographic Signature

Bug#1013465: cdcd: diff for NMU version 0.6.6-13.2

[Boyuan Yang]

Control: tags 1013465 + patch
Control: tags 1013465 + pending

Dear maintainer,

I've prepared an NMU for cdcd (versioned as 0.6.6-13.2) and
uploaded it to DELAYED/10. Please feel free to tell me if I
should delay it longer.

Regards.

diff -Nru cdcd-0.6.6/debian/changelog cdcd-0.6.6/debian/changelog
--- cdcd-0.6.6/debian/changelog 2011-12-01 10:04:16.0 -0500
+++ cdcd-0.6.6/debian/changelog 2022-09-21 13:46:45.0 -0400
@@ -1,3 +1,12 @@
+cdcd (0.6.6-13.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/control:
++ Drop hardcoded dependency on install-info. (Closes: #1013465)
++ Use automatic dbgsym package instead.
+
+ -- Boyuan Yang   Wed, 21 Sep 2022 13:46:45 -0400
+
 cdcd (0.6.6-13.1) unstable; urgency=low
 
   * NMU
diff -Nru cdcd-0.6.6/debian/control cdcd-0.6.6/debian/control
--- cdcd-0.6.6/debian/control   2011-09-04 10:04:37.0 -0400
+++ cdcd-0.6.6/debian/control   2022-09-21 13:46:45.0 -0400
@@ -8,24 +8,10 @@
 
 Package: cdcd
 Architecture: any
-Depends: ${misc:Depends}, ${shlibs:Depends}, dpkg (>= 1.15.4) | install-
info
+Depends: ${misc:Depends}, ${shlibs:Depends}
 Description: command line or console based CD player
  cdcd works in two ways, accepting commands directly off the command line
or in
  a query mode similar to other UNIX programs. To pass a command to cdcd,
simply
  run cdcd with the command as the argument (e.g. cdcd play). This is great
for
  using cron and cdcd together to make a CD alarm clock. Or you can run cdcd
  without arguments and you will be given the cdcd command prompt.
-
-Package: cdcd-dbg
-Section: debug
-Priority: extra
-Architecture: any
-Depends: ${misc:Depends}, cdcd (= ${binary:Version})
-Description: command line or console based CD player (debug)
- cdcd works in two ways, accepting commands directly off the command line
or in
- a query mode similar to other UNIX programs. To pass a command to cdcd,
simply
- run cdcd with the command as the argument (e.g. cdcd play). This is great
for
- using cron and cdcd together to make a CD alarm clock. Or you can run cdcd
- without arguments and you will be given the cdcd command prompt.
- .
- This package contains the debugging symbols.
diff -Nru cdcd-0.6.6/debian/rules cdcd-0.6.6/debian/rules
--- cdcd-0.6.6/debian/rules 2011-09-04 10:17:47.0 -0400
+++ cdcd-0.6.6/debian/rules 2022-09-21 13:46:45.0 -0400
@@ -19,5 +19,4 @@
rm -f debian/cdcd/usr/share/info/dir*
 
 override_dh_strip:
-   dh_strip --dbg-package=cdcd-dbg
-
+   dh_strip --dbgsym-migration='cdcd-dbg (<< 0.6.6-13.2~)'


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

Bug#1020435: ruby-prof: FTBFS on ppc64el

[Sebastian Ramacher]

Source: ruby-prof
Version: 1.4.3-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: sramac...@debian.org

https://buildd.debian.org/status/fetch.php?pkg=ruby-prof=ppc64el=1.4.3-1%2Bb1=1663720013=0

  1) Failure:
PrinterGraphTest#test_graph_results_sorting 
[/<>/test/printer_graph_test.rb:37]:
Array [0.171, 0.171, 0.167, 0.167, 0.166, 0.164, 0.004, 0.004, 0.002, 0.0, 0.0, 
0.0, 0.0, 0.17, 0.17, 0.0, 0.0, 0.169, 0.169, 0.0, 0.0] is not sorted.
--- expected
+++ actual
@@ -1 +1 @@
-[0.171, 0.171, 0.167, 0.167, 0.166, 0.164, 0.004, 0.004, 0.002, 0.0, 0.0, 0.0, 
0.0, 0.17, 0.17, 0.0, 0.0, 0.169, 0.169, 0.0, 0.0]
+[0.171, 0.171, 0.17, 0.17, 0.169, 0.169, 0.167, 0.167, 0.166, 0.164, 0.004, 
0.004, 0.002, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0]


51 runs, 687 assertions, 1 failures, 0 errors, 0 skips
rake aborted!
Command failed with status (1): [ruby -w -I"test" 
/usr/share/rubygems-integration/all/gems/rake-13.0.6/lib/rake/rake_test_loader.rb
 "test/abstract_printer_test.rb" "test/alias_test.rb" "test/basic_test.rb" 
"test/call_tree_visitor_test.rb" "test/call_trees_test.rb" 
"test/duplicate_names_test.rb" "test/enumerable_test.rb" 
"test/exceptions_test.rb" "test/exclude_methods_test.rb" 
"test/exclude_threads_test.rb" "test/fiber_test.rb" "test/gc_test.rb" 
"test/line_number_test.rb" "test/marshal_test.rb" "test/multi_printer_test.rb" 
"test/no_method_class_test.rb" "test/printer_call_stack_test.rb" 
"test/printer_call_tree_test.rb" "test/printer_flat_test.rb" 
"test/printer_graph_html_test.rb" "test/printer_graph_test.rb" 
"test/printing_recursive_graph_test.rb" "test/profile_test.rb" 
"test/rack_test.rb" "test/singleton_test.rb" -v]
/usr/share/rubygems-integration/all/gems/rake-13.0.6/exe/rake:27:in `'
Tasks: TOP => default
(See full trace by running task with --trace)
ERROR: Test "ruby3.0" failed. Exiting.

Cheers
-- 
Sebastian Ramacher

Bug#1020434: ruby-liquid-c: FTBFS on ppc64el

[Sebastian Ramacher]

Source: ruby-liquid-c
Version: 4.1.0-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: sramac...@debian.org

https://buildd.debian.org/status/fetch.php?pkg=ruby-liquid-c=ppc64el=4.1.0-1=1663761020=0

┌──┐
│ Run tests for ruby3.0 from debian/ruby-tests.rb  │
└──┘

RUBYLIB=. 
GEM_PATH=/<>/debian/ruby-liquid-c/usr/lib/powerpc64le-linux-gnu/rubygems-integration/3.0.0:/<>/debian/.debhelper/generated/_source/home/.local/share/gem/ruby/3.0.0:/var/lib/gems/3.0.0:/usr/local/lib/ruby/gems/3.0.0:/usr/lib/ruby/gems/3.0.0:/usr/lib/powerpc64le-linux-gnu/ruby/gems/3.0.0:/usr/share/rubygems-integration/3.0.0:/usr/share/rubygems-integration/all:/usr/lib/powerpc64le-linux-gnu/rubygems-integration/3.0.0
 ruby3.0 debian/ruby-tests.rb
ruby3.0 -w -Itest 
/usr/share/rubygems-integration/all/gems/rake-13.0.6/lib/rake/rake_test_loader.rb
 test/unit/block_test.rb test/unit/context_test.rb test/unit/expression_test.rb 
test/unit/gc_stress_test.rb test/unit/raw_test.rb 
test/unit/resource_limits_test.rb test/unit/tokenizer_test.rb 
test/unit/variable_test.rb -v
/<>/debian/ruby-liquid-c/usr/lib/powerpc64le-linux-gnu/rubygems-integration/3.0.0/gems/liquid-c-4.0.0/lib/liquid/c.rb:87:
 warning: method redefined; discarding old parse_expression
/usr/share/rubygems-integration/all/gems/liquid-5.4.0/lib/liquid/parse_context.rb:30:
 warning: previous definition of parse_expression was here
:231:in `verify_compaction_references': Compaction isn't available 
on this platform (NotImplementedError)
from /<>/test/test_helper.rb:11:in `'
from 
:85:in 
`require'
from 
:85:in 
`require'
from /<>/test/unit/block_test.rb:3:in `'
from 
:85:in 
`require'
from 
:85:in 
`require'
from 
/usr/share/rubygems-integration/all/gems/rake-13.0.6/lib/rake/rake_test_loader.rb:21:in
 `block in '
from 
/usr/share/rubygems-integration/all/gems/rake-13.0.6/lib/rake/rake_test_loader.rb:6:in
 `select'
from 
/usr/share/rubygems-integration/all/gems/rake-13.0.6/lib/rake/rake_test_loader.rb:6:in
 `'
ERROR: Test "ruby3.0" failed. Exiting.
dh_auto_install: error: dh_ruby --install /<>/debian/ruby-liquid-c 
returned exit code 1
make: *** [debian/rules:7: binary-arch] Error 25

Cheers
-- 
Sebastian Ramacher

Bug#1017720: nfs-common: No such file or directory

[Jason Breitman]

I now know that this behavior does exist in Debian Buster 10.8 and more 
specifically in the 4.19.X kernel after running stricter testing on more 
servers.
The 4.19.X kernel resolves itself immediately following the No such file or 
directory error which is different than the 5.X kernel requiring me to clear 
the inode and dentry cache by running echo 2 > /proc/sys/vm/drop_caches.
What further information is required to resolve this issue?

> -Original Message-
> From: Jason Breitman
> Sent: Tuesday, September 13, 2022 4:41 PM
> To: Ben Hutchings ; 1017...@bugs.debian.org
> Subject: RE: Bug#1017720: nfs-common: No such file or directory
> 
> I downgraded the nfs-common package which required the downgrade of
> the libevent packages and am using the 4.19.X kernel.
> I see the issue running the initial test, but then the issue is gone when
> running the test a subsequent time.
> 
> libevent-2.1-6:amd64  2.1.8-stable-4  
>   amd64
> Asynchronous event notification library
> libevent-core-2.1-6:amd64 2.1.8-stable-4
> amd64
> Asynchronous event notification library (core)
> libevent-pthreads-2.1-6:amd64 2.1.8-stable-4amd64
> Asynchronous event notification library (pthreads)
> linux-image-4.19.0-21-amd644.19.249-2  
> amd64Linux
> 4.19 for 64-bit PCs (signed)
> nfs-common  1:1.3.4-2.5+deb10u1   
>  amd64NFS
> support files common to client and server
> 
> What other packages do I need to downgrade in order to get Debian 11.4 to
> behave like Debian 10.8?
> What additional questions can I answer so that we can move forward?
> 
> > -Original Message-
> > From: Jason Breitman
> > Sent: Tuesday, September 6, 2022 5:18 PM
> > To: Ben Hutchings ; 1017...@bugs.debian.org
> > Subject: RE: Bug#1017720: nfs-common: No such file or directory
> >
> > I also see the failure with the kernels below, but the 4.19.X kernel 
> > resolves
> > the issue without dropping caches.
> > linux-image-4.19.0-14-amd64   4.19.171-2 amd64  
> >   Linux 4.19
> for
> > 64-bit PCs (signed)
> > linux-image-4.19.0-21-amd64   4.19.249-2 amd64  
> >   Linux 4.19
> for
> > 64-bit PCs (signed)
> >
> > I see the issue running the initial test, but then the issue is gone when
> > running the test a subsequent time.
> > I ran several tests to verify the behavior differences between the 4.19.X
> and
> > 5.X kernels.
> >
> > -- Test
> > ls -l /mnt/dir/someOtherDir/* | grep '?'
> >
> > -- Error message - the error message is showing files that have been erased
> > via rsync --delete
> > ls: cannot access 'filename': No such file or directory
> > -? ? ???? filename
> >
> > > -Original Message-
> > > From: Jason Breitman
> > > Sent: Friday, September 2, 2022 5:17 PM
> > > To: Ben Hutchings ; 1017...@bugs.debian.org
> > > Subject: RE: Bug#1017720: nfs-common: No such file or directory
> > >
> > > I have tested with the following kernels and see this issue in each case.
> > >
> > > linux-image-5.10.0-16-amd64  5.10.127-1   
> > >amd64
> > Linux
> > > 5.10 for 64-bit PCs (signed)
> > > linux-image-5.15.0-0.bpo.3-amd64 5.15.15-2~bpo11+1  amd64
> > > Linux 5.15 for 64-bit PCs (signed)
> > > linux-image-5.18.0-0.deb11.3-amd64 5.18.14-1~bpo11+1  amd64
> > > Linux 5.18 for 64-bit PCs (signed)
> > >
> > > An interesting note is that when using the 5.18 kernel, I had to run echo 
> > > 3
> >
> > > /proc/sys/vm/drop_caches to resolve the issue.
> > > echo 2 > /proc/sys/vm/drop_caches did not work as it did on the 5.10 and
> > > 5.15 kernels.
> > >
> > > > -Original Message-
> > > > From: Jason Breitman
> > > > Sent: Friday, August 26, 2022 3:36 PM
> > > > To: 'Ben Hutchings' ;
> '1017...@bugs.debian.org'
> > > > <1017...@bugs.debian.org>
> > > > Subject: RE: Bug#1017720: nfs-common: No such file or directory
> > > >
> > > > I was able to identify another workaround today which may help you to
> > > > identify the issue.
> > > > The workaround is to touch the directory where the troubled files live
> on
> > > the
> > > > file server.
> > > > I believe this tells us that updating the modify time attribute is used 
> > > > by
> > the
> > > > cache.
> > > > It should be noted that access time updates are disabled on the file
> > server.
> > > >
> > > > I also wanted to restate that we use rsync to push out these application
> > > > updates and also use rsync to sync data files.
> > > > Our rsync options preserve timestamps, so it is possible that the new
> files
> > > > have an older timestamp than "now".
> > > > It is not the case that the new files have an older timestamp than the
> > prior
> > > > version that is stuck in the cache.
> > > >
> > > > The rsync process that I 

Bug#1020433: ITP: bettercap-caplets -- Bettercap scripts (caplets) and proxy modules

[Francisco Vilmar Cardoso Ruviaro]

Package: wnpp
Severity: wishlist
Owner: Francisco Vilmar Cardoso Ruviaro 
X-Debbugs-Cc: debian-de...@lists.debian.org, vil...@debian.org

* Package name: bettercap-caplets
  Version : 0+git20210429-1~exp1
  Upstream Author : the dev team 
* URL : https://github.com/bettercap/caplets
* License : GPL-3
  Programming Lang: JavaScript
  Description : Bettercap scripts (caplets) and proxy modules

  This package contains Bettercap scripts (caplets) and proxy modules. The
  bettercap's interactive sessions can be scripted with .cap files, or caplets.

Bug#1016925: Re: Bug#1016925: kodi: Video playback not working in latest version of kodi

[Vasyl Gello]

Dear Alban,

> Maybe there is no way out of reverting the commit upstream ?

I got the private message from James on how to fix that issue however Alwin 
have not managed to fix it yet.
I have to change hotels because of situation around Ukraine, thus I have very 
limited time.

I can try building the latest Kodi from Debian in the next few days but I can 
not 100% guarantee I craft the fix
for the issue in question.
-- 
Vasyl Gello
==
Certified SolidWorks Expert

Mob.:+380 (98) 465 66 77

E-Mail: vasek.ge...@gmail.com
==
호랑이는 죽어서 가죽을 남기고 사람은 죽어서 이름을 남긴다

Bug#1020290: init-system-helpers depends on usrmerge | usr-is-merged

[Jakub Wilk]

* Craig Sanders , 2022-09-19 22:53:

# apt-get -d -u install usrmerge
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Package usrmerge is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source

E: Package 'usrmerge' has no installation candidate


This is very odd and it definitely doesn't happen here.

Can you run this command on the affected system

  apt-cache policy usrmerge usr-is-merged

and paste the output? This could shed some light on what's going on.

--
Jakub Wilk

Bug#1020331: protocols: add Linux specific internal ones: RAW and MPTCP

[Matthieu Baerts]

Hi Marco,

Thank you for your reply!

On 21/09/2022 12:25, Marco d'Itri wrote:
> On Sep 20, Matthieu Baerts  wrote:
> 
>> Would it be acceptable to add Linux specific "internal" protocols in
>> /etc/protocols?
> If they never appear on the wire then I am not sure.
> Do tools like ss show them?

For MPTCP, it doesn't appear on the wire but the protocol number is used
when creating a socket:

fd = socket(AF_INET(6), SOCK_STREAM, IPPROTO_MPTCP);

That's what was acceptable to do for Network Linux maintainers.
The protocol number is also used when listing connections.

'ss' is probably not a good example because it has already been patched
to list MPTCP sockets. Also, they use an internal function to convert
the protocol number to a name:

https://git.kernel.org/pub/scm/network/iproute2/iproute2.git/commit/?id=9c3be2c0eee01be7832b7900a8be798a19c659a5

But other tools listing sockets might use getprotobynumber() to display
a name instead of a number (if they don't fail because MPTCP is not
supported by getprotobynumber() on Debian so far).


>> Still, having them in /etc/protocols will help programs using
>> getprotobyname() or getprotobynumber() like Perl and others are doing to
>> support these protocols but also to display the proper info about them.
> Can you point me to real world code?

The one that triggered the opening of this bug report is when we looked
at providing an example of using MPTCP in Perl. For TCP, a socket is
typically created like this (c.f. "man perlipc"):

  socket(my $sock, PF_INET, SOCK_STREAM, getprotobyname("tcp"));

For MPTCP, it is not possible to use...

  getprotobyname("mptcp")

... if /etc/protocols has not been updated. Instead, it is required to
define a tuple which is different from the usual way and a bit "dirty".

Regarding real world code, I'm not a Perl dev but that seems to be quite
common to do that, see:

https://codesearch.debian.net/search?q=getprotobyname%28%22tcp%22%29=1
https://github.com/search?q=getprotobyname%28%22tcp%22%29=code

It looks like a way of coding with Perl because they also do something
similar when trying to find which port to use, e.g.:

  my $port = getservbyname "http", "tcp";


I don't know if there are programs having an option to use a protocol
defined in a config as a string, e.g. "tcp". Maybe some rely on
getprotobyname(), maybe others use hardcoded values.

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

Bug#1020430: usrmerge: cannot handle "open" binary when both kbd and xdg-utils are installed

[Ansgar]

On Wed, 2022-09-21 at 17:40 +0200, Giuseppe Sacco wrote:
> while installing this package on a system that has both kbd and xdg-
> utils packages, it stops with this error message:
> 
> Continuare? [S/n] s
> Lettura dei changelog... Fatto
> Estrazione dei template dai pacchetti: 100%
> Preconfigurazione dei pacchetti in corso
> Configurazione di usrmerge (30)...
> 
> FATAL ERROR:
> Both /bin/open and /usr/bin/open exist.
[...]
> Please note that kbd is version 2.3.0-3 and xdg-utils is 1.1.3-4.1

This is strange. kbd should have stopped shipping /bin/open since kbd
2.0.4-4 (from 2018, cf. https://bugs.debian.org/732796).

Is /bin/open a symlink to openvt on your system?

The current kbd package (kbd_2.3.0-3_amd64.deb) also doesn't ship
/bin/open.

Ansgar

Bug#1019753: py-libzfs: Pushing from Experimental into Sid?

[William Grzybowski]

Hello,

Unfortunately I have not had more time to maintain it.
Feel free to take maintainership and do what's necessary.

On Wed, Sep 14, 2022 at 3:18 PM Boyuan Yang  wrote:

> Source: py-libzfs
> Version: 0.0+git20220621.a99d1db-1
> Severity: normal
> X-Debbugs-CC: will...@grzy.org
> pkg-zfsonlinux-de...@alioth-lists.debian.net
>
> Dear Debian py-libzfs package maintainer,
>
> I noticed that py-libzfs [1][2] entered Debian experimental in section
> contrib back in 2019. There hasn't been much activity since then. I am
> wondering if there is any reason of not releasing this software into Sid,
> or
> if we should do so before Debian 12 freeze and release.
>
> Thanks,
> Boyuan Yang
>
>
> [1] https://tracker.debian.org/pkg/py-libzfs
> [2] https://github.com/truenas/py-libzfs
>

Bug#1004634: openscenegraph: FTBFS with ffmpeg 5.0

[Alberto Luaces]

Hi PaulLi,

this is highly appreciated.  Thanks a lot for your effort!

I have stored the patch in the repo for reference:

https://salsa.debian.org/openscenegraph-team/openscenegraph-3.2/-/commit/d5babb29f1233a9b111be88fd1037aebb5211c54

Regards,

Alberto

On 20/9/22 19:56, Ying-Chun Liu (PaulLiu) wrote:

Hi all,

I've patched the audio part. But not completed. The video part needs 
more changes. But I don't have enough time now.


Just attach the partial patch I made so that when someone has time or I 
have time then we can continue it.


Yours,
Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1020431: libcdio: realpath test failure with glibc 2.36

[Jeremy Bicha]

Source: libcdio
Version: 2.1.0-3
Severity: important
Tags: ftbfs patch bookworm sid

libcdio fails to build with glibc 2.36.

I am submitting a merge proposal to fix this:
https://salsa.debian.org/debian/libcdio/-/merge_requests/4

Thank you,
Jeremy Bicha