Bug#1019300: mp3guessenc: autopkgtests failure with grep 3.8: fgrep is deprecated

[Pino Toscano]

Source: mp3guessenc
Version: 0.27.5+dfsg.1-1
Severity: serious
Tags: patch
Justification: breaks autopkgtests

Hi,

GNU grep 3.8 officially deprecates egrep and fgrep, and those two
commands now issue a deprecation message on stderr [1].

The autopkgtests of mp3guessenc use fgrep, and while they still work
fine, the extra messages on stderr are considered by default a failure,
and thus the tests are marked as such. While autopkgtest has a
"allow-stderr" restriction to not consider stderr output as failure in
case it is expected, I think the better solution here is simply to
switch away from fgrep to grep -F. This works fine with grep 3.8 and
any older version.

Patch attached for this.

[1] https://lists.gnu.org/archive/html/info-gnu/2022-09/msg1.html

Thanks,
-- 
Pino
diff -Nru mp3guessenc-0.27.5+dfsg.1/debian/changelog 
mp3guessenc-0.27.5+dfsg.1/debian/changelog
--- mp3guessenc-0.27.5+dfsg.1/debian/changelog  2020-09-20 21:50:00.0 
+0200
+++ mp3guessenc-0.27.5+dfsg.1/debian/changelog  2022-09-07 08:12:34.0 
+0200
@@ -1,3 +1,12 @@
+mp3guessenc (0.27.5+dfsg.1-2) UNRELEASED; urgency=medium
+
+  [ Pino Toscano ]
+  * Switch from "fgrep" to "grep -F" in autopkgtests, as the former is
+officially deprecated since grep 3.8, writing a deprecation message on
+stderr that is considered as autopkgtest failure.
+
+ -- Peter Blackman   Wed, 07 Sep 2022 08:12:34 +0200
+
 mp3guessenc (0.27.5+dfsg.1-1) unstable; urgency=medium
 
   * New upstream version
diff -Nru mp3guessenc-0.27.5+dfsg.1/debian/tests/a 
mp3guessenc-0.27.5+dfsg.1/debian/tests/a
--- mp3guessenc-0.27.5+dfsg.1/debian/tests/a2020-07-16 10:49:55.0 
+0200
+++ mp3guessenc-0.27.5+dfsg.1/debian/tests/a2022-09-07 08:12:13.0 
+0200
@@ -6,7 +6,7 @@
 mp3guessenc -a debian/flush.mp3 > a.tmp
 set -e
 #
-fgrep 291 a.tmp
+grep -F 291 a.tmp
 #
 rm a.tmp
 
diff -Nru mp3guessenc-0.27.5+dfsg.1/debian/tests/f 
mp3guessenc-0.27.5+dfsg.1/debian/tests/f
--- mp3guessenc-0.27.5+dfsg.1/debian/tests/f2020-07-16 10:43:15.0 
+0200
+++ mp3guessenc-0.27.5+dfsg.1/debian/tests/f2022-09-07 08:12:13.0 
+0200
@@ -6,8 +6,8 @@
 mp3guessenc -f debian/flush.mp3 > f.tmp
 set -e
 #
-fgrep "48 kbps" f.tmp
-fgrep 550 f.tmp
+grep -F "48 kbps" f.tmp
+grep -F 550 f.tmp
 #
 rm f.tmp
 
diff -Nru mp3guessenc-0.27.5+dfsg.1/debian/tests/i 
mp3guessenc-0.27.5+dfsg.1/debian/tests/i
--- mp3guessenc-0.27.5+dfsg.1/debian/tests/i2020-07-16 10:48:58.0 
+0200
+++ mp3guessenc-0.27.5+dfsg.1/debian/tests/i2022-09-07 08:12:13.0 
+0200
@@ -6,8 +6,8 @@
 mp3guessenc -i debian/flush.mp3 > i.tmp
 set -e
 #
-fgrep 2020 i.tmp
-fgrep Ambient i.tmp
+grep -F 2020 i.tmp
+grep -F Ambient i.tmp
 #
 rm i.tmp
 
diff -Nru mp3guessenc-0.27.5+dfsg.1/debian/tests/m 
mp3guessenc-0.27.5+dfsg.1/debian/tests/m
--- mp3guessenc-0.27.5+dfsg.1/debian/tests/m2020-07-16 10:44:39.0 
+0200
+++ mp3guessenc-0.27.5+dfsg.1/debian/tests/m2022-09-07 08:12:13.0 
+0200
@@ -6,8 +6,8 @@
 mp3guessenc -f debian/flush.mp3 > f.tmp
 set -e
 #
-fgrep "48 kbps" f.tmp
-fgrep 550 f.tmp
+grep -F "48 kbps" f.tmp
+grep -F 550 f.tmp
 #
 rm f.tmp
 
diff -Nru mp3guessenc-0.27.5+dfsg.1/debian/tests/n 
mp3guessenc-0.27.5+dfsg.1/debian/tests/n
--- mp3guessenc-0.27.5+dfsg.1/debian/tests/n2020-07-16 11:08:27.0 
+0200
+++ mp3guessenc-0.27.5+dfsg.1/debian/tests/n2022-09-07 08:12:13.0 
+0200
@@ -11,7 +11,7 @@
 fi
 set -e
 #
-fgrep FhG n.tmp
+grep -F FhG n.tmp
 #
 rm n.tmp
 
diff -Nru mp3guessenc-0.27.5+dfsg.1/debian/tests/s 
mp3guessenc-0.27.5+dfsg.1/debian/tests/s
--- mp3guessenc-0.27.5+dfsg.1/debian/tests/s2020-07-16 10:51:16.0 
+0200
+++ mp3guessenc-0.27.5+dfsg.1/debian/tests/s2022-09-07 08:12:13.0 
+0200
@@ -6,7 +6,7 @@
 mp3guessenc -s debian/flush.mp3 > s.tmp
 set -e
 #
-fgrep FhG s.tmp
+grep -F FhG s.tmp
 #
 rm s.tmp
 

Bug#1019299: libapache2-mod-python: SEGFAULTS at random times with python3.9 and 3.10

[Peter Chubb]

Package: libapache2-mod-python
Version: 3.5.0+git20211031.e6458ec
Severity: normal
Tags: patch

Dear Maintainer,

(gdb) bt
#0  raise (sig=) at ../sysdeps/unix/sysv/linux/raise.c:50
#1  
#2  __new_sem_post (sem=0x21) at sem_post.c:36
#3  0x7f38785080f9 in PyThread_release_lock ()
   from /lib/x86_64-linux-gnu/libpython3.9.so.1.0
#4  0x7f3878570be9 in ?? () from /lib/x86_64-linux-gnu/libpython3.9.so.1.0
#5  0x7f38788d4a2a in release_interpreter (idata=0x55da959531c0)
at mod_python.c:306
#6  python_handler (req=0x7f387450d0a0, phase=)
at mod_python.c:1573
#7  0x55da949c4bb0 in ap_run_handler ()
#8  0x55da949c51a6 in ap_invoke_handler ()
#9  0x55da949ddabb in ap_process_async_request ()
#10 0x55da949ddcfe in ap_process_request ()
#11 0x55da949d9bad in ?? ()
#12 0x55da949ce860 in ap_run_process_connection ()
#13 0x7f3878960133 in ?? () from /usr/lib/apache2/modules/mod_mpm_worker.so
#14 0x7f3878c5eea7 in start_thread (arg=)
at pthread_create.c:477
#15 0x7f3878b8edef in clone ()
at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Running with more debugging shows the problem to be an attempt 
to release the currently running thread.

This is reported upstream as https://github.com/grisha/mod_python/issues/100


--- a/src/mod_python.c
+++ b/src/mod_python.c
@@ -303,7 +303,7 @@ static void release_interpreter(interpre
 {
 PyThreadState *tstate = PyThreadState_Get();
 #ifdef WITH_THREAD
-PyThreadState_Clear(tstate);
+//PyThreadState_Clear(tstate);
 if (idata)
 APR_ARRAY_PUSH(idata->tstates, PyThreadState *) = tstate;
 else

--


System Information:
Debian Release: 11.4
  APT prefers stable
  APT policy: (1002, 'stable'), (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-13-amd64 (SMP w/32 CPU threads)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_AU:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libapache2-mod-python depends on:
ii  apache2-bin [apache2-api-20120211]  2.4.54-1~deb11u1
ii  libc6   2.31-13+deb11u3
ii  libpython3.93.9.2-1
ii  python3 3.9.2-3

libapache2-mod-python recommends no packages.

Versions of packages libapache2-mod-python suggests:
pn  libapache2-mod-python-doc  

-- no debconf information

Bug#95165: cvs: cvs complains about EPIPE

[Thorsten Glaser]

close 95165
thanks

herb...@gondor.apana.org.au dixit:

>CVS is too strict on errors writing to stdout, e.g., if I do a cvs log
>piped to less, and then quit before reading the complete result, cvs says:
>
>cvs [log aborted]: received broken pipe signal
>Write failed flushing stdout buffer.
>
>and exits with an error.

I can verify that.

>This is unnecessary because if there were a genuine error, then the
>other side of the pipe would've returned an error code so it is not
>necessary for CVS to do so. In fact, this makes it hard to detect real
>errors in the cvs command.

I can understand that motivation.

>So please exit normally if cvs receives SIGPIPE as a result of writing
>to stdio.

There recently was a *huge* discussion on the Austin mailing list
(basically POSIX) about precisely this, for pwd(1). The problem is
not just getting the SIGPIPE but being unable to write to stdout.

After much discussion, it was decided that that is an error condition,
with the reasoning that it’s the called utility’s job to display data
on stdout, and if it can’t finish that successfully, it’s a “real error”
(to use your formulation from above).

Given the current behaviour is pretty much standard for Unix utilities
and has been in effect for decades, I’d like to keep things as-is and
close this debbugs issue due to it merely ending up a spam trap. Please
indicate disagreement with the latter within 30(?) days.

bye,
//mirabilos
-- 
“It is inappropriate to require that a time represented as
 seconds since the Epoch precisely represent the number of
 seconds between the referenced time and the Epoch.”
-- IEEE Std 1003.1b-1993 (POSIX) Section B.2.2.2

Bug#67895: cvs: cvs update on existing checkout sets mtime to new for all changed files

[Thorsten Glaser]

close 67895
thanks

I’d very much prefer to close this debbugs item, since it’s not a bug,
works both as designed and documented, with the submitter having been
quiet for well over a decade, and it just sitting here attracting spam;
archival will take care of the latter, for new spam anyway.

Herbert, this gives you a (30-day, IIRC?) chance to disagree.

bye,
//mirabilos
-- 
13:22⎜«neurodamage» mira, what's up man? I have a CVS question for you in #cvs
13:22⎜«neurodamage» since you're so good w. it │ «neurodamage:#cvs» i love you
13:28⎜«neurodamage:#cvs» you're a handy guy to have around for systems stuff ☺
16:06⎜ Thank god I found you =)   20:03│«bioe007:#cvs» mira2k: ty
17:14⎜ Thanks big help you are :-)mira|nwt: ty again
18:35⎜«alturiak:#cvs» mirabilos: aw, nice. thanks :o
18:36⎜«ThunderChicken:#cvs» mirabilos FTW!  23:03⎜«mithraic:#cvs» aaah. thanks
18:41⎜«alturiak:#cvs» phew. thanks a bunch, guys. you just made my weekend :-)
18:10⎜«sumit:#cvs» mirabilos: oh ok.. thanks for that
21:57⎜ yeah, I really appreciate help
18:50⎜«grndlvl:#cvs» thankyou18:50⎜«grndlvl:#cvs» worked perfectly
20:50⎜ i see. mirabilos, thnks for your support
00:36⎜«halirutan:#cvs» ok, the obvious way:-) thx
18:44⎜«arcfide:#cvs» mirabilos, I am running OpenBSD. 18:59⎜«arcfide:#cvs»
Hrm, yes, I see what you mean. 19:01⎜«arcfide:#cvs» Yeah, thanks for the help.
21:33⎜«CardinalFang:#cvs» Ugh.  Okay.  Sorry for the dumb question.  Thank you
21:34⎜ mirabilos: whoa that's sweet
21:52⎜«garrett__:#cvs» much appreciated  «garrett__:#cvs» thanks for your time
23:39⎜ this worked, thank you very much 16:26⎜ ok
thx, i'll try that 20:00⎜«stableable:#cvs» Thank you.20:50⎜«s833:#cvs»
mirabilos: thanks a lot.19:34⎜ Thanks for confirming :)
20:08⎜ ...works like a charm.. thanks mirabilos

Bug#1019298: spacenavd: FTBFS on all platforms

[Eric Long]

Source: spacenavd
Version: 1.0-1
Severity: serious
Tags: ftbfs patch
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: i...@hack3r.moe

Dear maintainers,

spacenavd v1.0-1 failed to build on all platforms:

```
/usr/bin/make cleandep
make[2]: Entering directory '/<>'
make[2]: *** No rule to make target 'cleandep'.  Stop.
make[2]: Leaving directory '/<>'
make[1]: *** [debian/rules:15: override_dh_auto_clean] Error 2
```

Full buildd log: 
https://buildd.debian.org/status/logs.php?pkg=spacenavd&ver=1.0-1&suite=sid

I've submitted an MR [1] that removes unnecessary `override_dh_auto_clean` and
fixes FTBFS. Please let me know if I missed anything.

Best regards,
Eric

[1]: https://salsa.debian.org/science-team/spacenavd/-/merge_requests/1

Bug#1018948: chromium: Main context menu opens in left upper corner of the window

[Nathan A. Stine]

On Fri, 02 Sep 2022 11:45:12 -0400 Andres Salomon 
wrote:
> On Fri, 2 Sep 2022 11:20:31 + Krassy Boykinov 
>  wrote:
>  > Package: chromium
>  > Version: 105.0.5195.52-1
>  > Severity: important
>  >
>  >
>  > Hitting the three dotted context-menu results in rendering it in
the 
> top
>  > left corner of the application,
>  > even above the window decorations.
>  >
>  > I use chromium in wayland mode (with --ozone-platform-hint=wayland
> flag)
>  >
>  >
> 
> Can you please provide a screenshot?  Also, which desktop environment
> are you using?
> 
> 
> 
> 

I can confirm this bug when using --ozone-platform=wayland. I can't
when using --ozone-platform=x11. The bug is not only the 3 dot menu,
but also any sort of menu or tooltip. For instance if you have folders
in your bookmark bar, clicking on them will show the contents at the
top left as shown in Krassy's screenshot.

Nathan A. Stine

Bug#1017271: zynaddsubfx: FTBFS: make[3]: *** No rule to make target 'src/UI/fluid', needed by 'src/UI/VirKeyboard.h'. Stop.

[Aaron M. Ucko]

Adrian Bunk  writes:

> Makes sense.

Thanks.

> It would also be useful if fltk1.3 would FTBFS when an input file was 
> not found.

Don't worry, I'm already planning to put in such a safeguard at this
point.  Sorry for missing this possible failure mode earlier.

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

Bug#1017271: zynaddsubfx: FTBFS: make[3]: *** No rule to make target 'src/UI/fluid', needed by 'src/UI/VirKeyboard.h'. Stop.

[Adrian Bunk]

On Tue, Sep 06, 2022 at 10:17:17PM -0400, Aaron M. Ucko wrote:
> Adrian Bunk  writes:
> 
> > Paths of the input files changed:
> 
> Ah, yeah, that would do it.  Thanks for all your analysis!
> 
> > The following in debian/rules work for me with current cmake:
> > CMakeTmp/CMakeFiles/Export/*/FLTK-Targets.cmake \
> > CMakeTmp/CMakeFiles/Export/*/FLTK-Targets-none.cmake \
> 
> Got it, thanks, though I'm inclined to use find(1) so I'm not
> specifically tied to new cmake.

Makes sense.

It would also be useful if fltk1.3 would FTBFS when an input file was 
not found.

cu
Adrian

Bug#1017271: zynaddsubfx: FTBFS: make[3]: *** No rule to make target 'src/UI/fluid', needed by 'src/UI/VirKeyboard.h'. Stop.

[Aaron M. Ucko]

Adrian Bunk  writes:

> Paths of the input files changed:

Ah, yeah, that would do it.  Thanks for all your analysis!

> The following in debian/rules work for me with current cmake:
> CMakeTmp/CMakeFiles/Export/*/FLTK-Targets.cmake \
> CMakeTmp/CMakeFiles/Export/*/FLTK-Targets-none.cmake \

Got it, thanks, though I'm inclined to use find(1) so I'm not
specifically tied to new cmake.

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

Bug#1017271: zynaddsubfx: FTBFS: make[3]: *** No rule to make target 'src/UI/fluid', needed by 'src/UI/VirKeyboard.h'. Stop.

[Adrian Bunk]

On Tue, Sep 06, 2022 at 06:09:04PM -0400, Aaron M. Ucko wrote:
> Adrian Bunk  writes:
> 
> > This makes it appear more likely that the root cause is a bug in FLTK or 
> > a regression in CMake.
> 
> Ah, yeah, FLTK's packaging post-processes some CMake output; it sounds
> like the relevant logic needs to be updated to work with current CMake.
> (Another option might have been to patch CMake's input, but I want to
> make some across-the-board tweaks that are best centralized modulo this
> sort of wrinkle.)  I'll take a look when I get a chance.

The build log of fltk1.3 says:
...
debian/fix-fltk-targets \
debian/FLTK-Targets-head.cmake \
CMakeTmp/CMakeFiles/Export/share/fltk/FLTK-Targets.cmake \
> CMakeTmp/etc/FLTK-Targets.cmake
Can't open CMakeTmp/CMakeFiles/Export/share/fltk/FLTK-Targets.cmake: No such 
file or directory at debian/fix-fltk-targets line 25, <> line 4.
debian/fix-fltk-targets \
CMakeTmp/CMakeFiles/Export/share/fltk/FLTK-Targets-none.cmake \
debian/FLTK-Targets-none-tail.cmake \
> CMakeTmp/etc/FLTK-Targets-none.cmake
Can't open CMakeTmp/CMakeFiles/Export/share/fltk/FLTK-Targets-none.cmake: No 
such file or directory at debian/fix-fltk-targets line 5.
...

Paths of the input files changed:
./CMakeTmp/CMakeFiles/Export/d834f99d2561e0cf606204aa52b7071e/FLTK-Targets.cmake
./CMakeTmp/CMakeFiles/Export/d834f99d2561e0cf606204aa52b7071e/FLTK-Targets-none.cmake

The following in debian/rules work for me with current cmake:
CMakeTmp/CMakeFiles/Export/*/FLTK-Targets.cmake \
CMakeTmp/CMakeFiles/Export/*/FLTK-Targets-none.cmake \

cu
Adrian

Bug#749603: ITP: libjs-dygraphs -- fast and flexible JavaScript charting library

[Thorsten Glaser]

retitle 749603 ITP: libjs-dygraphs -- fast and flexible JavaScript charting 
library
owner 749603 t.gla...@tarent.de
thanks

Against, probably, better knowledge, I’ll try to package this.
I have an experiment for a customer in which I can probably use
it, and might even fix minor bugs.

The software’s last release is 2.1.0 in 2017, and since then
there were 11 commits, last in 2021. They all look okay-ish.
This doesn’t sound well-maintained, and upstream acknowledges
this, but there hasn’t been a new active maintainer so far.

The repo is in interesting shape and will need quite some
cleanup of minified js blobs (not all of which are even used)
and embedded code copies, e.g. jsdoc-toolkit (which is packaged).
I *might* bring my fork into shape and cut an inofficial release
2.1.0.1 from that (instead of trying to delete+patch upstream’s
last release to death) which will make it easier to feed these
changes back, should they wish. Licence audit will certainly
need some time :/

There have been possibly incompatible changes since 1.x which
the other prospective users need to adapt for.

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

Bug#1019296: tt-rss - build-dependencies unsatisfiable

[Peter Michael Green]

Package: tt-rss
Version: 21~git20210204.b4cbc79+dfsg-1
Serverity: serious
Tags: bookworm, sid

tt-rss build-depends on libjs-prototype (= 1.7.1-3.1) but 
testing/unstable has version 1.7.3-1

Bug#1019295: schroot: Displays a lot of "egrep: warning: egrep is obsolescent; using grep -E"

[Sven-Haegar Koch]

Package: schroot
Version: 1.6.13-1
Severity: normal

Dear Maintainer,

Since update of grep to 3.8-1 using schroot outputs a lot of egrep
warnings:

Examples:

E: 20copyfiles: egrep: warning: egrep is obsolescent; using grep -E
E: 20copyfiles: egrep: warning: egrep is obsolescent; using grep -E
E: 20copyfiles: egrep: warning: egrep is obsolescent; using grep -E
E: 20copyfiles: egrep: warning: egrep is obsolescent; using grep -E
E: 20nssdatabases: egrep: warning: egrep is obsolescent; using grep -E
E: 20nssdatabases: egrep: warning: egrep is obsolescent; using grep -E
E: 20nssdatabases: egrep: warning: egrep is obsolescent; using grep -E
E: 20nssdatabases: egrep: warning: egrep is obsolescent; using grep -E
E: 20nssdatabases: egrep: warning: egrep is obsolescent; using grep -E
E: 20nssdatabases: egrep: warning: egrep is obsolescent; using grep -E
E: 20nssdatabases: egrep: warning: egrep is obsolescent; using grep -E
E: 20nssdatabases: egrep: warning: egrep is obsolescent; using grep -E
E: 20nssdatabases: egrep: warning: egrep is obsolescent; using grep -E
E: 20nssdatabases: egrep: warning: egrep is obsolescent; using grep -E
E: 20nssdatabases: egrep: warning: egrep is obsolescent; using grep -E

Greetings,
Haegar

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

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

Versions of packages schroot depends on:
ii  debconf [debconf-2.0]   1.5.79
ii  libboost-filesystem1.74.0   1.74.0-17
ii  libboost-iostreams1.74.01.74.0-17
ii  libboost-program-options1.74.0  1.74.0-17
ii  libc6   2.34-7
ii  libgcc-s1   12.2.0-1
ii  libpam0g1.5.2-2
ii  libstdc++6  12.2.0-1
ii  libuuid12.38.1-1
ii  lsb-base11.2
ii  schroot-common  1.6.13-1

schroot recommends no packages.

Versions of packages schroot suggests:
pn  aufs-tools | unionfs-fuse  
ii  btrfs-progs5.19-1
ii  bzip2  1.0.8-5
ii  debootstrap1.0.127
ii  lvm2   2.03.16-1
pn  qemu-user-static   
ii  xz-utils   5.2.5-2.1
pn  zfsutils-linux 
ii  zstd   1.5.2+dfsg-1

-- Configuration Files:
/etc/default/schroot changed:
STOP_ACTION="end"
START_ACTION="end"

/etc/schroot/default/fstab changed:
/proc   /proc   nonerw,bind 0   0
/sys/sysnonerw,bind 0   0
/dev/devnonerw,bind 0   0
/home   /home   nonerw,bind 0   0
/tmp/tmpnonerw,bind 0   0

/etc/schroot/schroot.conf changed:
...

-- debconf-show failed

Bug#1019294: rkhunter: egrep is deprecated

[Christoph Anton Mitterer]

Package: rkhunter
Version: 1.4.6-10
Severity: normal
Tags: upstream


Hey.

With grep 3.8-1 egrep has been deprecated and now prints a warning:
[ Rootkit Hunter version 1.4.6 ]
egrep: warning: egrep is obsolescent; using grep -E
egrep: warning: egrep is obsolescent; using grep -E
egrep: warning: egrep is obsolescent; using grep -E
...
egrep: warning: egrep is obsolescent; using grep -E
egrep: warning: egrep is obsolescent; using grep -E


Cheers,
Chris.

Bug#1019293: python3-pip: installs setup_requires into /tmp/.../overlay/local/bin but then adds /tmp/.../overlay/bin to PATH

[Simon McVittie]

Package: python3-pip
Version: 22.2+dfsg-1
Severity: important
X-Debbugs-Cc: pyth...@packages.debian.org

This might be the same issue as https://bugs.debian.org/1008783, but I'm
reporting it here in case it isn't. If the bug is reassigned to python3
or python3.10, please set it as affecting python3-pip.

To reproduce:

$ podman run -it --rm debian:sid-slim
# apt update
# apt install python3-pip
# pip install -vv --user dbus-python==1.3.2

Expected result:

pip downloads some setup_requires (meson, ninja, patchelf, etc.),
installs them into /tmp/pip-build-env-/overlay, and uses them to
try to build dbus-python. In this small reproducer the build will fail,
because dbus-python needs libdbus-1-dev and libglib2.0-dev installed on
the host system, but the thing I'm interested in here is that it should
get as far as successfully running meson from pip's overlay. In this
case I'm intentionally using Meson as packaged on PyPI, not Meson as
packaged by Debian.

Actual result:

pip installs the dependencies into /tmp/pip-build-env-/overlay,
with the Python code in
/tmp/pip-build-env-/overlay/local/lib/python3.10/dist-packages
and the executables in /tmp/pip-build-env-/overlay/local/bin/:

>  Installing collected packages: patchelf, ninja, wheel, tomli, setuptools, 
> pyparsing, meson, packaging, pyproject-metadata, meson-python
>changing mode of /tmp/pip-build-env-5u2k8uno/overlay/local/bin/ninja to 755
>changing mode of /tmp/pip-build-env-5u2k8uno/overlay/local/bin/wheel to 755
>changing mode of /tmp/pip-build-env-5u2k8uno/overlay/local/bin/meson to 755
>  Successfully installed meson-0.63.2 meson-python-0.8.1 ninja-1.10.2.3 
> packaging-21.3 patchelf-0.15.0.0 pyparsing-3.0.9 pyproject-metadata-0.6.1 
> setuptools-65.3.0 tomli-2.0.1 wheel-0.37.1

Then it runs the actual build system, which successfully invokes mesonpy,
aka meson-python, which is one of the setup_requires, and is a PEP 517
hook to build Python packages with Meson. It gets as far as trying to
run this command:

>  Running command Getting requirements to build wheel
>  + meson setup 
> --native-file=/tmp/pip-install-t6dj_vtk/dbus-python_b0dad2d1d4204e928c3741e1194fdaf0/.mesonpy-native-file.ini
>  -Ddebug=false -Doptimization=2 --prefix=/usr 
> /tmp/pip-install-t6dj_vtk/dbus-python_b0dad2d1d4204e928c3741e1194fdaf0 
> /tmp/pip-install-t6dj_vtk/dbus-python_b0dad2d1d4204e928c3741e1194fdaf0/.mesonpy-v6ryteth/build

But that fails:

>File 
> "/tmp/pip-build-env-5u2k8uno/overlay/local/lib/python3.10/dist-packages/mesonpy/__init__.py",
>  line 477, in _meson
>  return self._proc('meson', *args)
>File 
> "/tmp/pip-build-env-5u2k8uno/overlay/local/lib/python3.10/dist-packages/mesonpy/__init__.py",
>  line 472, in _proc
>  subprocess.check_call(list(args))
...
>  FileNotFoundError: [Errno 2] No such file or directory: 'meson'

I tried hacking some extra debugging into python3-pip, and it looks like
it's adding /tmp/pip-build-env-/overlay/bin/ to the PATH. You'll
notice that isn't the same directory
/tmp/pip-build-env-/overlay/local/bin/ where pip actually installed
the executables. The difference is the presence or absence of /local.

I suspect this is a side-effect of
debian/patches/distutils-install-layout.diff in python3.10, which has
special cases for when VIRTUAL_ENV is set, but apparently doesn't detect
pip's temporary pseudo-virtualenv as being equivalent.

Either python3.10 should not be applying the Debian-specific unix_local
installation scheme when installing into non-/usr, non-/usr/local
locations, or python3-pip should have a corresponding Debian patch
to force a suitable installation scheme in its temporary overlay, or
python3-pip should have a Debian to patch compensate for the unix_local
installation scheme and set its PATH accordingly.

Workaround for my reproducer:

# apt install meson ninja-build patchelf
# pip install -vv --user dbus-python==1.3.2

which gets as far as successfully running Meson (Debian's Meson rather
than PyPI's Meson). It errors out with

>  ../../subprojects/dbus-gmain/meson.build:107:0: ERROR: Pkg-config binary for 
> machine 1 not found. Giving up.

but that's fine (not a python3-pip bug, having pkg-config available is
out-of-scope for pip).

smcv

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

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

Versions of packages python3-pip depends on:
ii  ca-certificates 20211016
ii  python3 3.10.6-1
ii  python3-distutils   3.10.6-1
ii  python3-setuptools  59.6.0-1.2
ii  python3-wheel   0.37.1-2

Versions of packages python3-pip recommends:
ii  build-essential  12.9

Bug#1017271: zynaddsubfx: FTBFS: make[3]: *** No rule to make target 'src/UI/fluid', needed by 'src/UI/VirKeyboard.h'. Stop.

[Aaron M. Ucko]

Adrian Bunk  writes:

> This makes it appear more likely that the root cause is a bug in FLTK or 
> a regression in CMake.

Ah, yeah, FLTK's packaging post-processes some CMake output; it sounds
like the relevant logic needs to be updated to work with current CMake.
(Another option might have been to patch CMake's input, but I want to
make some across-the-board tweaks that are best centralized modulo this
sort of wrinkle.)  I'll take a look when I get a chance.

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

Bug#1019292: gnome-calls FTBFS on IPV6-only buildds

[Adrian Bunk]

Source: gnome-calls
Version: 0.3.3-1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/logs.php?pkg=gnome-calls&arch=amd64
https://buildd.debian.org/status/logs.php?pkg=gnome-calls&arch=all

...
=== 14/16 
test: sip
start time:   20:46:52
duration: 0.53s
result:   killed by signal 5 SIGTRAP
command:  MALLOC_CHECK_=2 
G_TEST_BUILDDIR='/<>/_build/plugins/provider/tests' 
GSETTINGS_SCHEMA_DIR='/<>/_build/data' GSETTINGS_BACKEND=memory 
CALLS_AUDIOSRC=audiotestsrc 
G_TEST_SRCDIR='/<>/plugins/provider/tests' 
G_DEBUG=gc-friendly,fatal-warnings NO_AT_BRIDGE=1 CALLS_AUDIOSINK=fakesink 
MALLOC_PERTURB_=243 CALLS_SIP_TEST=1 PYTHONDONTWRITEBYTECODE=yes 
'/<>/_build/plugins/provider/tests/sip'
--- stdout ---
# random seed: R02Sad24a1244a453042551428c9a905d7e2
1..5
# Start of Calls tests
# Start of SIP tests
ok 1 /Calls/SIP/provider_object
ok 2 /Calls/SIP/provider_origins
# CallsSipOrigin-DEBUG: Direct connection case. Using user and hostname
# CallsSipOrigin-DEBUG: Account changed:
# user: alice
# host: x86-conova-01
# CallsSipMediaManager-DEBUG: Creating CallsSipMediaManager
# GLib-GIO-DEBUG: _g_io_module_get_default: Found default implementation memory 
(GMemorySettingsBackend) for ?gsettings-backend?
# CallsSettings-DEBUG: Setting country code to 
# CallsSettings-DEBUG: Enabling the use of default origins
# CallsGstRfc3551-DEBUG: Gstreamer plugin for PCMA is available
# CallsGstRfc3551-DEBUG: Adding PCMA to the codec candidates
# CallsGstRfc3551-DEBUG: Gstreamer plugin for PCMU is available
# CallsGstRfc3551-DEBUG: Adding PCMU to the codec candidates
# CallsGstRfc3551-DEBUG: Gstreamer plugin for GSM is available
# CallsGstRfc3551-DEBUG: Adding GSM to the codec candidates
# CallsGstRfc3551-DEBUG: Gstreamer plugin for G723 is not available
# CallsSipMediaManager-DEBUG: Did not find audio codec G722
# CallsGstRfc3551-DEBUG: Gstreamer plugin for PCMA is available
# CallsGstRfc3551-DEBUG: Gstreamer plugin for PCMU is available
# CallsGstRfc3551-DEBUG: Gstreamer plugin for GSM is available
# CallsSipOrigin-DEBUG: Direct connection case. Using user and hostname
# CallsSipOrigin-DEBUG: Account changed:
# user: bob
# host: x86-conova-01
# CallsSipOrigin-DEBUG: Clearing any handles
# CallsSipOrigin-DEBUG: Requesting nua_shutdown ()
# CallsSipMediaPipeline-DEBUG: Element rtp-udp-src has changed state from NULL 
to READY
# CallsSipOrigin-DEBUG: response to nua_shutdown: 200 Shutdown successful
# CallsSipMediaPipeline-DEBUG: Element rtcp-udp-src has changed state from NULL 
to READY
# CallsSipOrigin-DEBUG: nua_shutdown() complete. Destroying nua handle
# CallsSipOrigin-DEBUG: Clearing any handles
# CallsSipOrigin-DEBUG: Requesting nua_shutdown ()
# CallsSipOrigin-DEBUG: response to nua_shutdown: 200 Shutdown successful
# CallsSipOrigin-DEBUG: nua_shutdown() complete. Destroying nua handle
# CallsSipOrigin-DEBUG: Clearing any handles
# CallsSipOrigin-DEBUG: Requesting nua_shutdown ()
# CallsSipOrigin-DEBUG: response to nua_shutdown: 200 Shutdown successful
# CallsSipOrigin-DEBUG: nua_shutdown() complete. Destroying nua handle
ok 3 /Calls/SIP/origin_objects
# CallsSipOrigin-DEBUG: Direct connection case. Using user and hostname
# CallsSipOrigin-DEBUG: Account changed:
# user: alice
# host: x86-conova-01
# CallsSipOrigin-DEBUG: Direct connection case. Using user and hostname
# CallsSipOrigin-DEBUG: Account changed:
# user: bob
# host: x86-conova-01
# CallsSipOrigin-DEBUG: Clearing any handles
# CallsSipOrigin-DEBUG: Requesting nua_shutdown ()
# CallsSipOrigin-DEBUG: response to nua_shutdown: 200 Shutdown successful
# CallsSipOrigin-DEBUG: nua_shutdown() complete. Destroying nua handle
# CallsSipOrigin-DEBUG: Clearing any handles
# CallsSipOrigin-DEBUG: Requesting nua_shutdown ()
# CallsSipOrigin-DEBUG: response to nua_shutdown: 200 Shutdown successful
# CallsSipOrigin-DEBUG: nua_shutdown() complete. Destroying nua handle
# CallsSipOrigin-DEBUG: Clearing any handles
# CallsSipOrigin-DEBUG: Requesting nua_shutdown ()
# CallsSipOrigin-DEBUG: response to nua_shutdown: 200 Shutdown successful
# CallsSipOrigin-DEBUG: nua_shutdown() complete. Destroying nua handle
ok 4 /Calls/SIP/origin_call_lists
# CallsSipOrigin-DEBUG: Direct connection case. Using user and hostname
# CallsSipOrigin-DEBUG: Account changed:
# user: alice
# host: x86-conova-01
# CallsSipOrigin-DEBUG: Direct connection case. Using user and hostname
# CallsSipOrigin-DEBUG: Account changed:
# user: bob
# host: x86-conova-01
# DEBUG: Call test: Stage 1
# CallsSipOrigin-DEBUG: Calling `sip:alice@127.0.0.1:5060' from origin 'bob'
# CallsSipOrigin-DEBUG: Setting local SDP for outgoing call to 
sip:alice@127.0.0.1:5060:
# v=0

# m=audio 53611 RTP/AVP 8 0 3

# a=rtpmap:8 PCMA/8000

# a=rtpmap:0 PCMU/8000

# a=rtpmap:3 GSM/8000

# a=rtcp:52537

# 

# 
# CallsSipMediaPipeline-DEBUG: Element rtp-udp-src has changed sta

Bug#1012196: buglist

[André]

Control: tags -1 -moreinfo

> You have NOT tested the file with the given command. Please remove 
the orig tarball to test it.
> Hint: You are currently requesting a *-*.tar.gz file which worked for 
the beta but does not for the regular release.

Now I got it. Thanks for the hint.

>
> > One question:
> > How should I use lintian locally?
> > If I run it with the .changes-file or with the .deb it just outputs
> > nothing. I'm running it on Debian unstable.
> Maybe you do not have warnings/errors anymore? Just build the package 
and from the source dir run lintian -IE --pedantic

> to see come more messages.
So I get the same messages as on m.d.n.
Should I handle the pedantic messages?

Bug#1019291: yarnpkg: depends on incompatible version of commander

[Kristof Csillag]

Package: yarnpkg
Version: 1.22.19+~cs24.27.18-1
Severity: normal
X-Debbugs-Cc: csillag.kris...@gmail.com

The current version of node-commander in Debian testing an unstable in 9.4.0.
However, this version is not fully compatible
with the current version of yarn.

For some packages, you will get something like this:

yarn run v1.22.19
TypeError: _commander(...).default.optionFor is not a function
at /usr/share/nodejs/yarn/lib/cli/index.js:511:88
at Array.findIndex ()
at _callee$ (/usr/share/nodejs/yarn/lib/cli/index.js:507:38)
at tryCatch
(/usr/share/nodejs/@babel/runtime/helpers/regeneratorRuntime.js:86:17)
at Generator._invoke
(/usr/share/nodejs/@babel/runtime/helpers/regeneratorRuntime.js:66:24)
at Generator.next
(/usr/share/nodejs/@babel/runtime/helpers/regeneratorRuntime.js:117:21)
at asyncGeneratorStep
(/usr/share/nodejs/@babel/runtime/helpers/asyncToGenerator.js:3:24)
at _next
(/usr/share/nodejs/@babel/runtime/helpers/asyncToGenerator.js:25:9)
at /usr/share/nodejs/@babel/runtime/helpers/asyncToGenerator.js:32:7
at new Promise ()

The short summary is that yarn tries to use the "optionFor" feature of
commnder,
but as far as I can tell, the last version of commander that still had
optionFor was version 4.1.1;
it has been removed by the time 5.0.0 has been released.

The upstream yarn package depends on "^2.9.0", so the currently packaged 9.4.0
definitely doesn't satisfy it.

I suggest shipping an older version commander to satisfy this dependency.

-- System Information:
Distributor ID: Devuan
Description:Devuan GNU/Linux 4 (chimaera)
Release:4
Codename:   chimaera
Architecture: x86_64

Kernel: Linux 5.19.0-1-amd64 (SMP w/24 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=hu_HU.UTF-8, LC_CTYPE=hu_HU.UTF-8 (charmap=UTF-8), LANGUAGE not
set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages yarnpkg depends on:
ii  ca-certificates20210119
ii  node-asap  2.0.6+~2.0.0-1
ii  node-babel7-runtime7.18.13+~cs214.250.184-2
ii  node-bytes 3.1.2-1
ii  node-camelcase 7.0.0-2
ii  node-chalk 5.0.1-2
ii  node-chownr1.1.3-5
ii  node-ci-info   3.3.2+~cs4.2.0-1
ii  node-cli-table 0.3.11+~cs0.13.4-1
ii  node-commander 9.4.0-1
ii  node-death 1.1.0-2
ii  node-debug 4.3.4+~cs4.1.7-1
ii  node-deep-equal2.0.5+~cs32.12.77-1
ii  node-detect-indent 6.1.0-1
ii  node-duplexify 4.1.2-1
ii  node-emoji 1.10.0+~1.8.1-1
ii  node-fast-levenshtein  2.0.6+ds-3
ii  node-glob  7.1.6+~7.1.3-1
ii  node-imports-loader0.8.0-5
ii  node-ini   3.0.1-1
ii  node-inquirer  8.2.3+~cs26.8.8-1
ii  node-invariant 2.2.4-2
ii  node-is-builtin-module 3.2.0-1
ii  node-js-yaml   4.1.0+dfsg+~4.0.5-6
ii  node-loud-rejection2.2.0-2
ii  node-micromatch4.0.5+~4.0.2-1
ii  node-minimatch 3.0.4+~3.0.3-1
ii  node-mkdirp1.0.4+~1.0.1-1
ii  node-object-path   0.11.8+~0.11.1-1
ii  node-path-root 0.1.1-2
ii  node-prepend-http  3.0.1-2
ii  node-proper-lockfile   4.1.2-2
ii  node-puka  1.0.1+dfsg-2
ii  node-pump  3.0.0-5
ii  node-pumpify   2.0.1-2
ii  node-read  1.0.7-4
ii  node-request   2.88.1-5
ii  node-request-capture-har   1.2.2-2
ii  node-resolve   1.22.1+~cs5.31.10-1
ii  node-rimraf3.0.2-1
ii  node-semver7.3.4-1
ii  node-sort-keys 4.0.0-1
ii  node-ssri  9.0.1-1
ii  node-strict-uri-encode 2.0.0+~2.0.0-1
ii  node-strip-ansi6.0.1-1
ii  node-strip-bom 4.0.0-2
ii  node-tar-stream2.2.0+~cs3.2.2-1
ii  node-through2  4.0.2-2
ii  node-uuid  8.3.2+~8.3.3-2
ii  node-validate-npm-package-license  3.0.4-2
ii  node-yn4.0.0-2
ii  nodejs 18.7.0+dfsg-5

yarnpkg recommends no packages.

yarnpkg suggests no packages.

Bug#1017271: zynaddsubfx: FTBFS: make[3]: *** No rule to make target 'src/UI/fluid', needed by 'src/UI/VirKeyboard.h'. Stop.

[Adrian Bunk]

Control: reassign -1 libfltk1.3-dev 1.3.8-4
Control: affects -1 src:zynaddsubfx cmake
Control: retitle -1 FLTK-Targets{,-none}.cmake lost contents during the latest 
binNMU
Control: block 1014422 by -1

On Sun, Aug 14, 2022 at 09:54:51AM +0200, Lucas Nussbaum wrote:
> Source: zynaddsubfx
> Version: 3.0.6-1
> Severity: serious
> Justification: FTBFS
> Tags: bookworm sid ftbfs
> User: lu...@debian.org
> Usertags: ftbfs-20220813 ftbfs-bookworm
> 
> Hi,
> 
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
> 
> 
> Relevant part (hopefully):
> > make[3]: Entering directory '/<>/obj-x86_64-linux-gnu'
> > cd /<>/obj-x86_64-linux-gnu && /usr/bin/cmake -E cmake_depends 
> > "Unix Makefiles" /<> /<>/src/Plugin/ZynAddSubFX 
> > /<>/obj-x86_64-linux-gnu 
> > /<>/obj-x86_64-linux-gnu/src/Plugin/ZynAddSubFX 
> > /<>/obj-x86_64-linux-gnu/src/Plugin/ZynAddSubFX/CMakeFiles/ZynAddSubFX_lv2_ui.dir/DependInfo.cmake
> >  --color=
> > make[3]: Entering directory '/<>/obj-x86_64-linux-gnu'
> > make[3]: *** No rule to make target 'src/UI/fluid', needed by 
> > 'src/UI/VirKeyboard.h'.  Stop.
> > make[3]: Leaving directory '/<>/obj-x86_64-linux-gnu'
> > make[2]: *** [CMakeFiles/Makefile2:2301: 
> > src/UI/CMakeFiles/zynaddsubfx_gui.dir/all] Error 2
>...

The problem is that after the latest binNMU of fltk1.3 two files under 
/usr/lib/fltk/ lost contents (complete diff attached):
 FLTK-Targets-none.cmake |  183 
 FLTK-Targets.cmake  |  155 
 2 files changed, 338 deletions(-)

This makes it appear more likely that the root cause is a bug in FLTK or 
a regression in CMake.

cu
Adrian
diff -ur fltk.old/FLTK-Targets.cmake fltk.rebuilt/FLTK-Targets.cmake
--- fltk.old/FLTK-Targets.cmake 2022-01-26 00:00:00.0 +0200
+++ fltk.rebuilt/FLTK-Targets.cmake 2022-09-07 00:40:28.070237583 +0300
@@ -2,158 +2,3 @@
   OUTPUT_VARIABLE DEB_HOST_MULTIARCH)
 string(STRIP "${DEB_HOST_MULTIARCH}" DEB_HOST_MULTIARCH)
 
-# Generated by CMake
-
-if("${CMAKE_MAJOR_VERSION}.${CMAKE_MINOR_VERSION}" LESS 2.6)
-   message(FATAL_ERROR "CMake >= 2.6.0 required")
-endif()
-cmake_policy(PUSH)
-cmake_policy(VERSION 2.6...3.20)
-#
-# Generated CMake target import file.
-#
-
-# Commands may need to know the format version.
-set(CMAKE_IMPORT_FILE_VERSION 1)
-
-# Protect against multiple inclusion, which would fail when already imported 
targets are added once more.
-set(_targetsDefined)
-set(_targetsNotDefined)
-set(_expectedTargets)
-foreach(_expectedTarget fltk_cairo_STATIC fltk_cairo_SHARED fluid fltk_STATIC 
fltk_forms fltk_images_STATIC fltk_gl fltk_SHARED fltk_forms_SHARED 
fltk_images_SHARED fltk_gl_SHARED)
-  list(APPEND _expectedTargets ${_expectedTarget})
-  if(NOT TARGET ${_expectedTarget})
-list(APPEND _targetsNotDefined ${_expectedTarget})
-  endif()
-  if(TARGET ${_expectedTarget})
-list(APPEND _targetsDefined ${_expectedTarget})
-  endif()
-endforeach()
-if("${_targetsDefined}" STREQUAL "${_expectedTargets}")
-  unset(_targetsDefined)
-  unset(_targetsNotDefined)
-  unset(_expectedTargets)
-  set(CMAKE_IMPORT_FILE_VERSION)
-  cmake_policy(POP)
-  return()
-endif()
-if(NOT "${_targetsDefined}" STREQUAL "")
-  message(FATAL_ERROR "Some (but not all) targets in this export set were 
already defined.\nTargets Defined: ${_targetsDefined}\nTargets not yet defined: 
${_targetsNotDefined}\n")
-endif()
-unset(_targetsDefined)
-unset(_targetsNotDefined)
-unset(_expectedTargets)
-
-
-# Compute the installation prefix relative to this file.
-get_filename_component(_IMPORT_PREFIX "${CMAKE_CURRENT_LIST_FILE}" PATH)
-get_filename_component(_IMPORT_PREFIX "${_IMPORT_PREFIX}" PATH)
-get_filename_component(_IMPORT_PREFIX "${_IMPORT_PREFIX}" PATH)
-if(_IMPORT_PREFIX STREQUAL "/")
-  set(_IMPORT_PREFIX "")
-endif()
-
-# Create imported target fltk_cairo_STATIC
-add_library(fltk_cairo_STATIC STATIC IMPORTED)
-
-# Create imported target fltk_cairo_SHARED
-add_library(fltk_cairo_SHARED SHARED IMPORTED)
-
-# Create imported target fluid
-add_executable(fluid IMPORTED)
-
-# Create imported target fltk_STATIC
-add_library(fltk_STATIC STATIC IMPORTED)
-
-set_target_properties(fltk_STATIC PROPERTIES
-  INTERFACE_LINK_LIBRARIES 
"/usr/lib/${DEB_HOST_MULTIARCH}/libdl.so;-lpthread;/usr/lib/${DEB_HOST_MULTIARCH}/libSM.so;/usr/lib/${DEB_HOST_MULTIARCH}/libICE.so;/usr/lib/${DEB_HOST_MULTIARCH}/libX11.so;/usr/lib/${DEB_HOST_MULTIARCH}/libXext.so;fltk_cairo_STATIC;cairo;/usr/lib/${DEB_HOST_MULTIARCH}/libXinerama.so;/usr/lib/${DEB_HOST_MULTIARCH}/libXfixes.so;/usr/lib/${DEB_HOST_MULTIARCH}/libXcursor.so;/usr/lib/${DEB_HOST_MULTIARCH}/libXrender.so;/usr/lib/${DEB_HOST_MULTIARCH}/libXft.so;/usr/lib/${DEB_HOST_MULTIARCH}/libfontconfig.so"
-)
-
-# Create imported target fltk_forms_STATIC
-add_library(fltk_forms_STATIC STATIC IMPOR

Bug#1016938: konclude: autopkgtest regression on armhf, flaky test on s390x (with timeout)

[Adrian Bunk]

On Wed, Aug 10, 2022 at 08:14:36AM +0200, Paul Gevers wrote:
> Source: konclude
> Version: 0.7.0+1137~dfsg-1
> Severity: serious
> X-Debbugs-CC: debian...@lists.debian.org
> User: debian...@lists.debian.org
> Usertags: timeout regression flaky
> 
> Dear maintainer(s),
> 
> I looked at the results of the autopkgtest of your package because it was
> showing up on our page for long running tests on s390x. I noticed that the
> test regularly fails on s390x with an autopkgtest timeout. Additionally I
> noticed that your package regressed on armhf around August 2021.
> 
> Because the unstable-to-testing migration software now blocks on
> regressions in testing, flaky tests, i.e. tests that flip between
> passing and failing without changes to the list of installed packages,
> are causing people unrelated to your package to spend time on these
> tests. Tests that time out and fail while normally running quickly are a
> serious burden on our infrastructure, please try to prevent the apparent
> hang.
> 
> Regressions in testing on release architectures are considered RC by the
> release team [1].
> 
> Don't hesitate to reach out if you need help and some more information
> from our infrastructure.

Looking at the armhf regression, has there been any change in the 
autopkgtest infrastructure when it regressed?

The autopkgtest passes for me on amdahl.

The tests are also run as part of the package build, and in reproducible 
they have been reliably passing on armhf:
https://tests.reproducible-builds.org/debian/history/armhf/konclude.html

> Paul
> 
> https://ci.debian.net/packages/k/konclude/
>...

cu
Adrian

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

[Jason Breitman]

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   
>amd64Linux
> 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 describe has not changed and has been in use for
> > many years.
> >
> > > -Original Message-
> > > From: Jason Breitman
> > > Sent: Thursday, August 25, 2022 11:54 AM
> > > To: Ben Hutchings ; 1017...@bugs.debian.org
> > > Subject: RE: Bug#1017720: nfs-common: No such file or directory
> > >
> > > I have the same issue after adding actimeo=30 to /etc/fstab, rebooting
> and
> > > testing.
> > > I also confirmed that those settings applied via /proc/mounts which
> shows
> > > the below snippet for each mountpoint.
> > > nfs4
> > >
> >
> rw,relatime,vers=4.1,rsize=131072,wsize=131072,namlen=255,acregmin=30,a
> > >
> >
> cregmax=30,acdirmax=30,hard,noresvport,proto=tcp,timeo=600,retrans=2,s
> > >
> >
> ec=krb5,clientaddr=X.X.X.X,lookupcache=pos,local_lock=none,addr=Y.Y.Y.Y 0
> > > 0
> > >
> > > > -Original Message-
> > > > From: Jason Breitman
> > > > Sent: Tuesday, August 23, 2022 2:42 PM
> > > > To: Ben Hutchings ; 1017...@bugs.debian.org
> > > > Subject: RE: Bug#1017720: nfs-common: No such file or directory
> > > >
> > > > What additional information can I provide for us to move forward with
> > this
> > > > process?
> > > >
> > > > To summarize and include further details, rsync is used to sync
> > applications
> > > to
> > > > a file server which behaves like a repository.
> > > > We do preserve timestamps from the build server and also use --
> delete.
> > > We
> > > > do not run the applications from the file server.  All servers use NTP.
> > > >
> > > > The application has a sub-directory that contain files with version
> > numbers.
> > > > These are libraries.
> > > > When a new build is complete, a developer pushes their updates via
> > rsync
> > > to
> > > > the file server / repository.
> > > >
> > > > I believe that the dentry cache thinks the "old" files exist and 
> > > > generates
> a
> > > No
> > > > such file or directory error showing question marks for that files
> > attributes.
> > > > Dropping the dentry cache via echo 2 > /proc/sys/vm/drop_caches
> > > resolves
> > > > the issue.
> > > >
> > > > This behavior is not observed in Debian 10.8 with that distributions
> > > associated
> > > > kernel and packages.
> > > >
> > > > > -Original Message-
> > > > > From: Jason Breitman
> > > > > Se

Bug#1019290: ITP: parolottero-languages -- Project that holds the language packs for parolottero

[Salvo 'LtWorf' Tomaselli]

Package: wnpp
Severity: wishlist
Owner: Salvo 'LtWorf' Tomaselli 
X-Debbugs-Cc: debian-de...@lists.debian.org, tipos...@tiscali.it

* Package name: parolottero-languages
  Version : 0.3
  Upstream Author : Salvo 'LtWorf' Tomaselli 
* URL : https://github.com/ltworf/parolottero-languages/
* License : Various licenses: MIT, GPL, AGPL
  Programming Lang: Python, but it's mostly data
  Description : Project that holds the language packs for parolottero

Language packs for parolottero

I've split the parolottero project into the game itself and a separate project
for the language packs.

This is that project.

In this way they can be released separately. Game fixes and language fixes
are not necessarily related.

The languages itself come from firefox spellchecker or similar projects. The 
Makefile
converts them into a format that is good for parolottero.

The languages can have fixes which users of parolottero can report.

Bug#1019289: less: copyright file lacks several distribution licenses

[Bastian Germann]

Source: less
Severity: serious
Tags: patch
Version: 590-1

There are some distribution licenses in less that are not represented in the 
debian/copyright file,
which is a Policy violation. I have pushed a fix to git at
https://salsa.debian.org/debian/less/-/commit/23ae6836cfb367f836f6cb6a62b87f82249c219d.
Please upload a version that contains that change or at least adds the missing 
licenses to the file.

Bug#1019288: sed: copyright file lacks several distribution licenses

[Bastian Germann]

Source: sed
Severity: serious
Tags: patch
Version: 4.8-1

There are some distribution licenses in sed that are not represented in the 
debian/copyright file,
which is a Policy violation. I have pushed a fix to git at
https://salsa.debian.org/debian/sed/-/commit/cb92853072195ce7218f54c483192f9ff8b435d7.
Please upload a version that contains that change or at least adds the missing 
licenses to the file.

Bug#1019263: chromium: Audio capture (e.g., in MS Teams) doesn't work

[Andres Salomon]

Hi,

Did this just start happening with chromium 105?

Thanks,
Andres

On Tue, Sep 6, 2022 at 15:07, Sam Morris  wrote:

Package: chromium
Version: 105.0.5195.102-1
Severity: normal
X-Debbugs-Cc: s...@robots.org.uk

When I try to join a Teams meeting, I get the mesasge

Are you sure you don't want audio or video? If you change your 
mind,
select the camera icon by your address bar and then _Always 
allow_.


This appears to happen because Teams can't see the existance of my
microphone. When I click the camera icon in the address bar, I see:

Camera and Microphone Blocked

This page has been blocked from accessing your camera and 
micrphone.


( ) Always allow https://teams.microsoft.com to access your 
camera and

microphone

(x) Continue blocking camera and microphone access


Microphone: Default

Camera: TOSHIBA Web Cam...

[Manage] [Done]

Now the funny things about this popup are:

 * Selecting 'always allow' and pressing Done doesn't work. If I click
   the camera icon again, the popup comes back and 'always allow' is
   selected, but Teams behaves as if I didn't change the option and
   continued to block it.

 * If I reload the page and join another meeting, 'Continue blocking' 
is

   set, so chromium doesn't remember my selection between page loads.

 * When I try to change the devices listed in the popup, by clicking 
on

   what I assume is supposed to be a dropdown menu, nothing happens;
   it's as if the widget is disabled, though there is no visual
   indication of such

 * If I press Manage, it takes me to
which has an entry 
right
   at the top of 'recent activity' saying: teams.microsoft.com: 
Allowed

   camera, microphone

 * If I click on this entry it takes me to
   


   which under 'permissions' has Microphone set to Block. If I click
   this I get a dropdown menu with the entries Block (default), Allow
   and Block. If I choose Allow in this dropdown menu, the choice is
   instantly reset back to Block.

Trying to debug this at another site,
,
when I press 'Start' I get the same popup as with Teams (although this
one doesn't mention the camera being blocked). This one has the same
behaviour: 'Continue blocking' is selected by default, if I change it 
to

'allow' and press 'Done', nothing happens. If I reload the page, next
time I click the camera icon to get the popup, 'Continue blocking' is
still set.

In the console, these messages are logged when I press 'Start'.

Requesting local stream
main.js:56 navigator.MediaDevices.getUserMedia error:  Permission 
denied NotAllowedError


-- System Information:
Debian Release: 11.4
  APT prefers stable-updates
  APT policy: (570, 'stable-updates'), (570, 'stable-security'), 
(570, 'stable-debug'), (570, 'stable'), (550, 'testing-debug'), (550, 
'testing'), (530, 'unstable-debug'), (530, 'unstable'), (1, 
'experimental-debug'), (1, 'experimental')

Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.18.0-3-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_USER, TAINT_DIE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en

Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Permissive - Policy name: default

Versions of packages chromium depends on:
ii  chromium-common 
105.0.5195.102-1

ii  libasound2  1.2.7.2-1
ii  libatk-bridge2.0-0  2.38.0-1
ii  libatk1.0-0 2.36.0-2
ii  libatomic1  12.2.0-1
ii  libatspi2.0-0   2.38.0-4
ii  libbrotli1  1.0.9-2+b2
ii  libc6   2.34-4
ii  libcairo2   1.16.0-5
ii  libcups22.4.2-1+b1
ii  libdbus-1-3 1.12.20-2
ii  libdouble-conversion3   3.1.5-6.1
ii  libdrm2 2.4.104-1
ii  libevent-2.1-7  
2.1.12-stable-1
ii  libexpat1   
2.2.10-2+deb11u3
ii  libflac8
1.3.3-2+deb11u1

ii  libfontconfig1  2.13.1-4.2
ii  libfreetype62.12.1+dfsg-3
ii  libgbm1 20.3.5-1
ii  libgcc-s1   12.2.0-1
ii  libglib2.0-02.72.3-1+b1
ii  libgtk-3-0  3.24.34-3
ii  libjpeg62-turbo 1:2.0.6-4
ii  libjsoncpp25   

Bug#1019287: libsuperlu-dist-dev: installed libsuperlu-dist-dev:amd64 package post-removal script subprocess returned error exit status 1

[Sebastian Ramacher]

Package: libsuperlu-dist-dev
Version: 8.1.0+dfsg1-2
Severity: serious

>From piuparts:

(Reading database ... 10034 files and directories currently installed.)
Removing libsuperlu-dist-dev:amd64 (8.1.0+dfsg1-2) ...
rmdir: failed to remove '/usr/lib/x86_64-linux-gnu/fortran/gfortran': No such 
file or directory
dpkg: error processing package libsuperlu-dist-dev:amd64 (--remove):
 installed libsuperlu-dist-dev:amd64 package post-removal script subprocess 
returned error exit status 1
dpkg: too many errors, stopping
Errors were encountered while processing:
 libsuperlu-dist-dev:amd64
Processing was halted because there were too many errors.
E: Sub-process /usr/bin/dpkg returned an error code (1)

https://piuparts.debian.org/sid/fail/libsuperlu-dist-dev_8.1.0+dfsg1-2.log

Cheers
-- 
Sebastian Ramacher

Bug#1019286: tftp: make transitional package to tftp-hpa

[Bastian Germann]

Package: tftp
Severity: wishlist

Please make tftp a transitional package that depends on tftp-hpa, which is fully cli-compatible and still has the 
upstream source available. atftp would also be a candidate but does not share a common (BSD) history and might behave 
differently for some commands.


If you cannot afford the time, I would happily implement it and upload as NMU 
if you agree.

Bug#1019285: please package documentation

[Sébastien Villemot]

Source: wireplumber
Version: 0.4.11-3
Severity: wishlist

Dear maintainers,

It would be nice to package wireplumber’s documentation.

As a reminder, packaged documentation provides at least two advantages: it is
accessible offline, and it matches the version installed on the system
(contrary to online documentation which can be more recent).

Thanks for your work,

--
⢀⣴⠾⠻⢶⣦⠀  Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁  Debian Developer
⢿⡄⠘⠷⠚⠋⠀  https://sebastien.villemot.name
⠈⠳⣄  https://www.debian.org

Bug#1019275: libreoffice-writer: ldd -r /usr/lib/libreoffice/program/libmergedlo.so -> undefined symbol: hb_graphite2_face_get_gr_face

[Rene Engelhard]

Hi,


Am 06.09.22 um 21:38 schrieb Rene Engelhard:

Hi again,

Dou you have some locally-installed harfbuzz lingering around 
somewhere in the library search path?


(i.e. /usr/local)

This sounds like a locally-installed harfbuzz without graphite2 support.


And if that is the case this is no bug. The packages can't only know 
what is in the official harfbuzz packages


can, of course :-)

(Or "can't know whatever else library installed from somewhere has")


Regards,


Rene

Bug#1019284: transition: linphone-stack

[Bernhard Schmidt]

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

Dear release team,

I'm asking for permission for a small mostly self-contained transition
of the whole linphone stack. It has been staged in experimental.

Most of these libraries don't change SONAME, but upstream only supports staying
within the same minor version. So there is a (>= | < ) dependency generated
with shlibs and the stack will have to migrate in one go.

bctoolbox 4.4.13-4 -> 5.0.37-2
belr 4.4.13-2 -> 5.0.37-1
bzrtp 4.4.13-2 -> 5.0.37-1
lime NEW in unstable
bcmatroska2 NEW in unstable
ortp 1:4.4.13-2 -> 1:5.0.37-1
belcard 4.4.13-2 -> 5.0.37-1
belle-sip 4.4.21+dfsg-2 -> 5.0.37+dfsg-2
mediastreamer2 1:4.4.21 -> 1:5.0.37+dfsg-3
linphone 4.4.21-2 -> 5.0.37-4
linphone-desktop 4.2.5-3 -> 4.3.2-1

only ortp has reverse dependencies outside of the linphone stack that will need
a binNMU. They have been successfully built against the version in experimental.

bcg729
trx
libosmo-abis
libosmo-netif
osmo-bts

Bernhard

Bug#1019283: jargon-text: no Homepage field

[Jakub Wilk]

Source: jargon-text
Version: 4.4.7-4.1
Severity: wishlist

Please add

  Homepage: http://www.catb.org/~esr/jargon/

to debian/control.

--
Jakub Wilk

Bug#1019282: ignition-common: missing header include, causes build failures of software using this lib

[Steve Langasek]

Package: ignition-common
Version: 4.5.1+ds-1
Severity: serious
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu kinetic ubuntu-patch

Hi José Luis,

In Ubuntu, ignition-launch is failing to build from source because of an
error in an ignition-common header, Image.hh, which references memcpy() but
does not include string.h which declares it.

The attached patch to ignition-common fixes the build failure of
ignition-launch (not yet in Debian) and may help the buildability of other
software using ignition-common.

Thanks for considering,
-- 
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
diff -Nru ignition-common-4.5.1+ds/debian/control 
ignition-common-4.5.1+ds/debian/control
--- ignition-common-4.5.1+ds/debian/control 2022-07-19 05:53:51.0 
-0700
+++ ignition-common-4.5.1+ds/debian/control 2022-09-06 12:26:16.0 
-0700
@@ -1,6 +1,5 @@
 Source: ignition-common
-Maintainer: Ubuntu Developers 
-XSBC-Original-Maintainer: Debian Science Maintainers 

+Maintainer: Debian Science Maintainers 

 Uploaders: Jose Luis Rivero 
 Section: science
 Priority: optional
diff -Nru ignition-common-4.5.1+ds/debian/patches/missing-include.patch 
ignition-common-4.5.1+ds/debian/patches/missing-include.patch
--- ignition-common-4.5.1+ds/debian/patches/missing-include.patch   
1969-12-31 16:00:00.0 -0800
+++ ignition-common-4.5.1+ds/debian/patches/missing-include.patch   
2022-09-06 12:26:10.0 -0700
@@ -0,0 +1,18 @@
+Description: add missing include to header
+ Image.hh references memcpy() but doesn't include string.h which declares it.
+Author: Steve Langasek 
+Last-Update: 2022-09-06
+Forwarded: no
+
+Index: ignition-common-4.5.1+ds/graphics/include/ignition/common/Image.hh
+===
+--- ignition-common-4.5.1+ds.orig/graphics/include/ignition/common/Image.hh
 ignition-common-4.5.1+ds/graphics/include/ignition/common/Image.hh
+@@ -21,6 +21,7 @@
+ #include 
+ #include 
+ #include 
++#include 
+ #include 
+ #include 
+ 
diff -Nru ignition-common-4.5.1+ds/debian/patches/series 
ignition-common-4.5.1+ds/debian/patches/series
--- ignition-common-4.5.1+ds/debian/patches/series  2022-06-27 
15:41:21.0 -0700
+++ ignition-common-4.5.1+ds/debian/patches/series  2022-09-06 
12:24:35.0 -0700
@@ -3,3 +3,4 @@
 0004-Disable-failing-tests-due-to-copyrighted-files.patch
 0005-Use-system-tinyobjloader.patch
 0003-Disable-performance-test.patch
+missing-include.patch

Bug#1015995: gpgme1.0 FTBFS with 3.10 as only supported Python3 version

[Paul Gevers]

Control: tags -1 pending

Hi,

On Mon, 25 Jul 2022 10:03:04 +0200 Gianfranco Costamagna 
 wrote:

Hello, looks like Ubuntu already has a patch for this:
http://launchpadlibrarian.net/594282639/gpgme1.0_1.16.0-1.2ubuntu3_1.16.0-1.2ubuntu4.diff.gz


I will upload the attached NMU to DELAYED/5 shortly. The same content is 
available in MR6 on Salsa [1].


Paul

[1] https://salsa.debian.org/debian/gpgme/-/merge_requests/6
diff -Nru gpgme1.0-1.17.1/debian/changelog gpgme1.0-1.17.1/debian/changelog
--- gpgme1.0-1.17.1/debian/changelog2022-06-15 19:02:47.0 +0200
+++ gpgme1.0-1.17.1/debian/changelog2022-09-06 20:59:56.0 +0200
@@ -1,3 +1,11 @@
+gpgme1.0 (1.17.1-4.1) unstable; urgency=medium
+
+  * Non-maintainer upload
+  * fix FTBFS caused by missing PYTHON (Closes: #1015995)
+(Original patch by Alexandre Ghiti)
+
+ -- Paul Gevers   Tue, 06 Sep 2022 20:59:56 +0200
+
 gpgme1.0 (1.17.1-4) unstable; urgency=medium
 
   * release to unstable
diff -Nru 
gpgme1.0-1.17.1/debian/patches/0007-lang-python-tests-Fix-FTBFS-caused-by-missing-PYTHON.patch
 
gpgme1.0-1.17.1/debian/patches/0007-lang-python-tests-Fix-FTBFS-caused-by-missing-PYTHON.patch
--- 
gpgme1.0-1.17.1/debian/patches/0007-lang-python-tests-Fix-FTBFS-caused-by-missing-PYTHON.patch
  1970-01-01 01:00:00.0 +0100
+++ 
gpgme1.0-1.17.1/debian/patches/0007-lang-python-tests-Fix-FTBFS-caused-by-missing-PYTHON.patch
  2022-09-06 20:59:56.0 +0200
@@ -0,0 +1,28 @@
+From b400fce0d3a8db7ed1038ca0645d513d28b88683 Mon Sep 17 00:00:00 2001
+From: Alexandre Ghiti 
+Date: Thu, 31 Mar 2022 14:09:55 +0200
+Subject: [PATCH] lang: python: tests: Fix FTBFS caused by missing PYTHON
+
+Updated by Paul Gevers 
+---
+ lang/python/tests/Makefile.am | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+Index: gpgme1.0/lang/python/tests/Makefile.am
+===
+--- gpgme1.0.orig/lang/python/tests/Makefile.am
 gpgme1.0/lang/python/tests/Makefile.am
+@@ -70,9 +70,11 @@ check: xcheck
+ .PHONY: xcheck
+ 
+ xcheck:   all
+-  $(TESTS_ENVIRONMENT) $(PYTHON) $(srcdir)/run-tests.py \
++  for PYTHON in $(PYTHONS); do \
++  $(TESTS_ENVIRONMENT) $$PYTHON $(srcdir)/run-tests.py \
+ --interpreters="$(PYTHONS)" --srcdir=$(srcdir) $(TESTFLAGS) \
+-$(XTESTS)
++$(XTESTS) ; \
++  done
+ 
+ CLEANFILES = secring.gpg pubring.gpg pubring.kbx trustdb.gpg dirmngr.conf \
+   gpg-agent.conf pubring.kbx~ gpg.conf pubring.gpg~ \
diff -Nru gpgme1.0-1.17.1/debian/patches/series 
gpgme1.0-1.17.1/debian/patches/series
--- gpgme1.0-1.17.1/debian/patches/series   2022-05-21 08:02:25.0 
+0200
+++ gpgme1.0-1.17.1/debian/patches/series   2022-09-06 20:55:08.0 
+0200
@@ -3,3 +3,4 @@
 0003-Ship-python-examples-with-python3-in-shebang-line.patch
 0004-Avoid-the-hardcoded-list-of-Python-versions.patch
 0005-qt-Add-missing-include-of-config.h.patch
+0007-lang-python-tests-Fix-FTBFS-caused-by-missing-PYTHON.patch


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1019275: libreoffice-writer: ldd -r /usr/lib/libreoffice/program/libmergedlo.so -> undefined symbol: hb_graphite2_face_get_gr_face

[Rene Engelhard]

Hi again,

Dou you have some locally-installed harfbuzz lingering around somewhere 
in the library search path?


(i.e. /usr/local)

This sounds like a locally-installed harfbuzz without graphite2 support.


And if that is the case this is no bug. The packages can't only know 
what is in the official harfbuzz packages


ii  libgraphite2-3  1.3.14-1
[...]
ii  libharfbuzz-icu02.7.4-1
ii  libharfbuzz0b   2.7.4-1

And those DO have that as they ARE built with graphite2 support.

Regards,

Rene

Bug#1018966: Information needed about your bug against widelands

[waxhead]

The directory /usr/share/games/widelands/data/i18n/fonts/Culmus/ is 
empty so the file you want to ls is not available.


Martin Quinson wrote:

Hello waxhead,

could you please tell us what is the result of the following command on your
machine?

ls -la 
/usr/share/games/widelands/data/i18n/fonts/Culmus/TaameyFrankCLM-Medium.ttf

This file is included in the widelands-data package, that seem installed on your
machine, so I fail to understand how things could go wrong.

Thanks in advance,
Mt

Bug#1019281: libnet-dns-perl: please adapt dependencies

[Thomas Uhle]

Package: libnet-dns-perl
Version: 1.29-1
Severity: normal
Control: found -1 1.34-1

Dear maintainers,

libnet-dns-perl has an unnecessary dependency on libnet-ip-perl because 
the module Net::IP is nowhere used nor is it referenced in META.json or 
META.yml (cf. https://metacpan.org/dist/Net-DNS) as far as I can see. 
And Test::More from libtest-simple-perl is just a build-time dependency. 
So this dependency could also be removed although it does not 
necessarily install another Debian package since it is also provided by 
package perl.


Net::DNS has support for and prefers Net::LibIDN2 since version 1.13 
which means for already some years.  But libnet-dns-perl still only 
recommends libnet-libidn-perl.  I know libnet-libidn2-perl has not yet 
been packaged (cf. RFP #1019279).  Even though could you please replace 
libnet-libidn-perl by 'libnet-libidn2-perl | libnet-libidn-perl'.


All this is also still true for the currently packaged version 1.34-1 in 
bookworm and sid.


Thank you in advance!

Thomas Uhle


-- System Information:
Debian Release: 11.5
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: arm64 (aarch64)
Foreign Architectures: armhf

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

Versions of packages libnet-dns-perl depends on:
ii  libdigest-hmac-perl1.03+dfsg-2.1
ii  libdigest-sha-perl 6.02-1+b3
ii  libnet-ip-perl 1.26-2
ii  perl [libencode-perl]  5.32.1-4+deb11u2
ii  perl [libtest-simple-perl] 5.32.1-4+deb11u2
ii  perl-base [libio-socket-ip-perl]   5.32.1-4+deb11u2
ii  perl-base [libscalar-list-utils-perl]  5.32.1-4+deb11u2

Versions of packages libnet-dns-perl recommends:
ii  libdigest-bubblebabble-perl  0.02-2.1
ii  libnet-dns-sec-perl  1.18-1+b1
ii  libnet-libidn-perl   0.12.ds-3+b3
pn  libperl4-corelibs-perl   

libnet-dns-perl suggests no packages.

Bug#1019279: RFP: libnet-libidn2-perl -- Perl bindings for GNU libidn2

[Thomas Uhle]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: Debian Perl Group 

* Package name: libnet-libidn2-perl
  Version : 1.01
  Upstream Author : Thomas Jacob
* URL or Web page : https://metacpan.org/release/Net-LibIDN2
* License : Artistic or GPL-1+
  Description : Perl bindings for GNU libidn2

Net::LibIDN2 provides Perl bindings for GNU libidn2, a C library for 
handling internationalized domain names according to IDNA 2008, Punycode 
and Unicode TR46. It closely follows the original C API of that library.



Dear developers,

there are Perl modules in Debian packages that already support 
Net::LibIDN2 (libnet-dns-perl for instance).  As libidn2 implements the 
revised algorithm for internationalized domain names in contrast to its 
predecessor libidn, it would make sense to also have libnet-libidn2-perl 
as a Debian package next to libnet-libidn-perl.


Thank you in advance!

Best regards,

Thomas Uhle

Bug#1019280: gnome-sushi: Broken after webkit2gtk 4.1 switch

[Boyuan Yang]

Package: gnome-sushi
Severity: grave
Version: 42.0-2
X-Debbugs-CC: jbi...@ubuntu.com

Hi,

Package gnome-sushi is completely broken with 42.0-2 upload. After
installation, it will spam syslog every second:

dbus-daemon[4055]: [session uid=1000 pid=4055] Activating service
name='org.gnome.NautilusPreviewer' requested by ':1.111' (uid=1000 pid=4782
comm="gjs /usr/share/gnome-shell/extensions/ding@rasters")
9月 06 15:30:15 gaolab004 org.gnome.NautilusPreviewer[23117]: Unsatisfied
dependency: WebKit2
dbus-daemon[4055]: [session uid=1000 pid=4055] Activated service
'org.gnome.NautilusPreviewer' failed: Process org.gnome.NautilusPreviewer
exited with status 1

The log also indicates that the package is not functional at all.

Thanks,
Boyuan Yang


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

Bug#1019278: dulwich: Is (build-)dependency on python3-dbg necessary?

[Boyuan Yang]

Source: dulwich
Version: 0.2.44-1
Severity: wishlist
X-Debbugs-CC: jel...@debian.org

Dear Debian dulwich package maintainer,

I noticed that installing python3-dulwich will result in installation of the
following packages: libpython3-dbg libpython3.10-dbg python3-dbg python3.10-
dbg , which is unexpected.

Looking at https://packages.debian.org/sid/amd64/python3-dulwich/filelist ,
looks like dulwich still builds .so for python3's debug interpreter. I am
not sure whether this is still reasonable after the switch documented at
https://lists.debian.org/debian-python/2021/09/msg4.html .

Please revisit the current packaging condition and, if feasible, drop
(build-)dependency on python3*-dbg.

Thanks,
Boyuan Yang


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

Bug#1019275: libreoffice-writer: ldd -r /usr/lib/libreoffice/program/libmergedlo.so -> undefined symbol: hb_graphite2_face_get_gr_face

[Rene Engelhard]

reassign 1019275 libreoffice-core

found 1019275 1:7.0.4-4+deb11u1

tag 1019275 + moreinfo

tag 1019275 + unreproducible

thanks


Hi,


Am 06.09.22 um 20:33 schrieb user1:

Package: libreoffice-writer

Erm, no, libmerged belongs into -core.

Version: 1:7.0.4-4+deb11u1
Severity: important

Dear Maintainer,

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

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


Yes, do that. Only putting the actual info in the mail subject is bad.


Your subject says:


"ldd -r /usr/lib/libreoffice/program/libmergedlo.so -> undefined symbol: 
hb_graphite2_face_get_gr_face"



Just did:

$ ldd -r /usr/lib/libreoffice/program/libmergedlo.so
    linux-vdso.so.1 (0x7ffe89138000)
    libepoxy.so.0 => /lib/x86_64-linux-gnu/libepoxy.so.0 
(0x7f858622d000)
    libgpgmepp.so.6 => /lib/x86_64-linux-gnu/libgpgmepp.so.6 
(0x7f85861c9000)
    libicuuc.so.67 => /lib/x86_64-linux-gnu/libicuuc.so.67 
(0x7f8585fe)

    libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x7f8585fc3000)
    libnss3.so => /lib/x86_64-linux-gnu/libnss3.so (0x7f8585e6c000)
    libsmime3.so => /lib/x86_64-linux-gnu/libsmime3.so (0x7f8585e3d000)
    libplc4.so => /lib/x86_64-linux-gnu/libplc4.so (0x7f8585e34000)
    libnspr4.so => /lib/x86_64-linux-gnu/libnspr4.so (0x7f8585df3000)
    libdconf.so.1 => /lib/x86_64-linux-gnu/libdconf.so.1 
(0x7f8585de2000)
    libgio-2.0.so.0 => /lib/x86_64-linux-gnu/libgio-2.0.so.0 
(0x7f8585c04000)
    libgobject-2.0.so.0 => /lib/x86_64-linux-gnu/libgobject-2.0.so.0 
(0x7f8585baa000)
    libglib-2.0.so.0 => /lib/x86_64-linux-gnu/libglib-2.0.so.0 
(0x7f8585a7b000)

    libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7f8585a73000)
    libdbus-1.so.3 => /lib/x86_64-linux-gnu/libdbus-1.so.3 
(0x7f8585a1e000)
    libicui18n.so.67 => /lib/x86_64-linux-gnu/libicui18n.so.67 
(0x7f8585718000)
    libcurl-gnutls.so.4 => /lib/x86_64-linux-gnu/libcurl-gnutls.so.4 
(0x7f858567e000)

    libX11.so.6 => /lib/x86_64-linux-gnu/libX11.so.6 (0x7f858553b000)
    libxml2.so.2 => /lib/x86_64-linux-gnu/libxml2.so.2 (0x7f858538d000)
    libexpat.so.1 => /lib/x86_64-linux-gnu/libexpat.so.1 
(0x7f858535c000)

    libxslt.so.1 => /lib/x86_64-linux-gnu/libxslt.so.1 (0x7f8585319000)
    libclucene-core.so.1 => /lib/x86_64-linux-gnu/libclucene-core.so.1 
(0x7f858517)
    libclucene-contribs-lib.so.1 => 
/lib/x86_64-linux-gnu/libclucene-contribs-lib.so.1 (0x7f858510d000)
    libexttextcat-2.0.so.0 => 
/lib/x86_64-linux-gnu/libexttextcat-2.0.so.0 (0x7f8584f08000)
    libhunspell-1.7.so.0 => /lib/x86_64-linux-gnu/libhunspell-1.7.so.0 
(0x7f8584e9a000)
    libhyphen.so.0 => /lib/x86_64-linux-gnu/libhyphen.so.0 
(0x7f8584e91000)
    libmythes-1.2.so.0 => /lib/x86_64-linux-gnu/libmythes-1.2.so.0 
(0x7f8584e8c000)
    libnumbertext-1.0.so.0 => 
/lib/x86_64-linux-gnu/libnumbertext-1.0.so.0 (0x7f8584e34000)
    liborcus-0.16.so.0 => /lib/x86_64-linux-gnu/liborcus-0.16.so.0 
(0x7f8584cf1000)
    liborcus-parser-0.16.so.0 => 
/lib/x86_64-linux-gnu/liborcus-parser-0.16.so.0 (0x7f8584ca3000)
    libboost_locale.so.1.74.0 => 
/lib/x86_64-linux-gnu/libboost_locale.so.1.74.0 (0x7f8584bbe000)

    librdf.so.0 => /lib/x86_64-linux-gnu/librdf.so.0 (0x7f8584b8)
    libraptor2.so.0 => /lib/x86_64-linux-gnu/libraptor2.so.0 
(0x7f8584b1b000)
    libjpeg.so.62 => /lib/x86_64-linux-gnu/libjpeg.so.62 
(0x7f8584a97000)

    libeot.so.0 => /lib/x86_64-linux-gnu/libeot.so.0 (0x7f8584a87000)
    libpng16.so.16 => /lib/x86_64-linux-gnu/libpng16.so.16 
(0x7f8584a4d000)
    libgraphite2.so.3 => /lib/x86_64-linux-gnu/libgraphite2.so.3 
(0x7f8584a21000)
    libharfbuzz-icu.so.0 => /lib/x86_64-linux-gnu/libharfbuzz-icu.so.0 
(0x7f8584a1a000)
    libharfbuzz.so.0 => /lib/x86_64-linux-gnu/libharfbuzz.so.0 
(0x7f8584932000)
    liblcms2.so.2 => /lib/x86_64-linux-gnu/liblcms2.so.2 
(0x7f85848cf000)
    libcairo.so.2 => /lib/x86_64-linux-gnu/libcairo.so.2 
(0x7f85847aa000)

    libcups.so.2 => /lib/x86_64-linux-gnu/libcups.so.2 (0x7f858470e000)
    libfontconfig.so.1 => /lib/x86_64-linux-gnu/libfontconfig.so.1 
(0x7f85846c8000)
    libfreetype.so.6 => /lib/x86_64-linux-gnu/libfreetype.so.6 
(0x7f8584603000)

    libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7f85844bf000)
    libXext.so.6 => /lib/x86_64-linux-gnu/libXext.so.6 (0x7f85844aa000)
    libuno_cppu.so.3 => /usr/lib/libreoffice/program/libuno_cppu.so.3 
(0x7f8584478000)
    libuno_cppuhelpergcc3.so.3 => 
/usr/lib/libreoffice/program/libuno_cppuhelpergcc3.so.3 (0x7f8584378000)
    libi18nlangtag.so => /usr/lib/libreoffice/program/libi18nlangtag.so 
(0x7f8584356000)
    libjvmaccesslo.so => /usr/lib/libreoffic

Bug#1019277: ITP: slidge -- general purpose XMPP gateway framework

[Martin]

Package: wnpp
Severity: wishlist
Owner: Martin 
X-Debbugs-Cc: pkg-xmpp-de...@alioth-lists.debian.net

* Package name: slidge
  Version : 0.1.0
  Upstream Author : Nicolas Cedilnik 
* URL : https://sr.ht/~nicoco/slidge
* License : AGPL3+
  Programming Lang: Python
  Description : general purpose XMPP gateway framework

Slidge is a general purpose XMPP (puppeteer) gateway framework in
Python. It should make writing gateways to other chat networks (plugins)
as frictionless as possible.

It comes with a few plugins included, implementing at least basic direct
messaging and often more "advanced" instant messaging features.

Bug#1015995: gpgme1.0 FTBFS with 3.10 as only supported Python3 version

[Paul Gevers]

Hi Alexandre,

On Mon, 25 Jul 2022 10:03:04 +0200 Gianfranco Costamagna 
 wrote:

Hello, looks like Ubuntu already has a patch for this:
http://launchpadlibrarian.net/594282639/gpgme1.0_1.16.0-1.2ubuntu3_1.16.0-1.2ubuntu4.diff.gz


I was about to upload an NMU gpgme with your patch applied, but it looks 
wrong to me. If I understand the patch correctly (make isn't my 
strongest point), it will just run the test with the last PYTHON in 
PYTHONS. Why was the test not put inside the do-done block?


--- a/lang/python/tests/Makefile.am
+++ b/lang/python/tests/Makefile.am
@@ -70,7 +70,8 @@ check: xcheck
 .PHONY: xcheck

 xcheck:all
-   $(TESTS_ENVIRONMENT) $(PYTHON) $(srcdir)/run-tests.py \
+   for PYTHON in $(PYTHONS); do true; done; \
+   $(TESTS_ENVIRONMENT) $$PYTHON $(srcdir)/run-tests.py \
  --interpreters="$(PYTHONS)" --srcdir=$(srcdir) $(TESTFLAGS) \
  $(XTESTS)

Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1019276: ITP: nvda2speechd -- A bridge between Windows applications and Speech dispatcher

[Samuel Thibault]

Package: wnpp
Severity: wishlist
Owner: Samuel Thibault 
X-Debbugs-Cc: debian-de...@lists.debian.org, 
debian-accessibil...@lists.debian.org

* Package name: nvda2speechd
  Version : 0.1
  Upstream Author : Rastislav Kish
* URL : https://github.com/RastislavKish/nvda2speechd
* License : GPL
  Programming Lang: Rust
  Description : A bridge between Windows applications and Speech dispatcher

It is already possible to use SAPI in Wine for quite a some time,
however, the default Microsoft voices are not particularly responsive
or diverse in terms of supported languages, and installing others and
configuring them can be challenging without sighted assistance.

nvda2speechd is a bridge, which can link applications capable of
speaking through NVDA right into Speech dispatcher installed on the
user's computer.


I plan to maintain it within the a11y team. The compilation involves
building windows binaries from rust source, which is not supported
in Debian, so I'll build using upstream rust resources and upload to
contrib.

Bug#1019275: libreoffice-writer: ldd -r /usr/lib/libreoffice/program/libmergedlo.so -> undefined symbol: hb_graphite2_face_get_gr_face

[user1]

Package: libreoffice-writer
Version: 1:7.0.4-4+deb11u1
Severity: important

Dear Maintainer,

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

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

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


-- Package-specific info:

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

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

Versions of packages libreoffice-writer depends on:
ii  libabw-0.1-1 0.1.3-1
ii  libc62.31-13+deb11u3
ii  libe-book-0.1-1  0.1.3-2
ii  libepubgen-0.1-1 0.1.1-1
ii  libetonyek-0.1-1 0.1.9-4
ii  libgcc-s110.2.1-6
ii  libicu67 67.1-7
ii  libmwaw-0.3-30.3.17-1
ii  libodfgen-0.1-1  0.1.8-2
ii  libreoffice-base-core1:7.0.4-4+deb11u1
ii  libreoffice-common   1:7.0.4-4+deb11u1
ii  libreoffice-core 1:7.0.4-4+deb11u1
ii  librevenge-0.0-0 0.0.4-6+b1
ii  libstaroffice-0.0-0  0.0.7-1
ii  libstdc++6   10.2.1-6
ii  libuno-cppu3 1:7.0.4-4+deb11u1
ii  libuno-cppuhelpergcc3-3  1:7.0.4-4+deb11u1
ii  libuno-sal3  1:7.0.4-4+deb11u1
ii  libuno-salhelpergcc3-3   1:7.0.4-4+deb11u1
ii  libwpd-0.10-10   0.10.3-1
ii  libwpg-0.3-3 0.3.3-1
ii  libwps-0.4-4 0.4.12-1
ii  libxml2  2.9.10+dfsg-6.7+deb11u2
ii  ucf  3.0043
ii  uno-libs-private 1:7.0.4-4+deb11u1
ii  zlib1g   1:1.2.11.dfsg-2+deb11u2

Versions of packages libreoffice-writer recommends:
ii  libreoffice-math  1:7.0.4-4+deb11u1

Versions of packages libreoffice-writer suggests:
ii  fonts-crosextra-caladea 20130214-2.1
ii  fonts-crosextra-carlito 20130920-1.1
ii  libreoffice-base1:7.0.4-4+deb11u1
ii  libreoffice-java-common 1:7.0.4-4+deb11u1
ii  openjdk-17-jre [java8-runtime]  17.0.4+8-1~deb11u1

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

Bug#1019243: libayatana-appindicator 0.5.5-2+deb11u2 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 1019243 = bullseye pending
thanks

Hi,

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

Thanks for your contribution!

Upload details
==

Package: libayatana-appindicator
Version: 0.5.5-2+deb11u2

Explanation: fix dependency versions

Bug#1019274: src:php8.1: fails to migrate to testing for too long: unresolved RC bug

[Paul Gevers]

Source: php8.1
Version: 8.1.5-1
Severity: serious
Control: close -1 8.1.7-1
Tags: sid bookworm
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: block -1 by 1015188

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:php8.1 has been trying to migrate for 61 
days [2]. Hence, I am filing this bug. Your package has an unresolved RC 
bug: #1015188.


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=php8.1



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1019273: apt: Missing licenses and copyright statements in debian/copyright

[Bastian Germann]

Source: apt
Severity: serious
Version: 2.5.2
Tags: patch

The debian/copyright (COPYING) file is missing at least two licenses (Expat, 
BSD-3-clause)
and some copyright statements. A machine-readable version of COPYING is 
attached that fixes
these.Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
Upstream-Name: apt
Upstream-Contact: APT Development Team 
Source: https://salsa.debian.org/apt-team/apt

Files: *
Copyright: 1997-1999 Jason Gunthorpe and others
License: GPL-2+

Files: apt-pkg/cachefilter-patterns.*
   apt-private/private-json-hooks.*
   test/libapt/pattern_test.cc
Copyright: 2018, 2019 Canonical Ltd
License: GPL-2+

Files: po/lt.po
Copyright: 2006 Canonical Ltd, and Rosetta Contributors 2006
License: GPL-2+

Files: apt-pkg/contrib/weakptr.h
   apt-pkg/contrib/string_view.h
   CMakeLists.txt
Copyright: 2009, 2010, 2015, 2016 Julian Andres Klode 
License: GPL-2+

Files: debian/apt.postrm
Copyright: 1998, Ben Gertzfield 
License: GPL-2+

Files: doc/po/pt.po
   po/bg.po
   po/it.po
   po/sv.po
   po/th.po
Copyright: 2002-2019 Free Software Foundation, Inc.
License: GPL-2+

Files: doc/po/es.po
   po/tl.po
Copyright: 2003, 2004, 2005, 2009, 2010, 2012 Software in the Public Interest
License: GPL-2+

Files: po/nb.po
Copyright: 2002-2003 Lars Bahner 
   2003-2004 Axel Bojer 
   2004 Klaus Ade Johnstad 
   2004 Bjorn Steensrud 
   2003, 2005-2010 Hans Fredrik Nordhaug 
   2016, 2018 Petter Reinholdtsen 
License: GPL-2

Files: po/tr.po
Copyright: 2009 Rosetta Contributors and Canonical Ltd 2009
   2013 Debian L10n Turkish 2013
   2013-2018 Mert Dirik 
License: GPL-2+

Files: doc/po/pl.po
Copyright: 2004 Krzysztof Fiertek 
   2000-2004, 2010, 2012  Robert Luberda 
License: GPL-2+

Files: doc/po/it.po
Copyright: 2000-2017 Debian Italian l10n team 

License: GPL-2+

Files: doc/po/ja.po
Copyright: 2003-2017 Debian Japanese List 
License: GPL-2+

Files: doc/po/fr.po
Copyright: 2000-2018 Debian French l10n team 

License: GPL-2+

Files: doc/design.dbk
Copyright: 1997 Manoj Srivastava
License: GPL-2+

Files: doc/dpkg-tech.dbk
Copyright: 1997 Tom Lees
License: GPL-2+

Files: methods/rred.cc
Copyright: 2014 Anthony Towns
License: GPL-2+

Files: methods/rsh.cc
Copyright: 2000 Ben Collins 
License: GPL-2

Files: CMake/FindBerkeley.cmake
Copyright: 2006, Alexander Dymo, 
   2016, Julian Andres Klode 
License: BSD-3-clause
 Redistribution and use in source and binary forms, with or without
 modification, are permitted provided that the following conditions
 are met:
 .
 1. Redistributions of source code must retain the copyright
notice, this list of conditions and the following disclaimer.
 2. Redistributions in binary form must reproduce the copyright
notice, this list of conditions and the following disclaimer in the
documentation and/or other materials provided with the distribution.
 3. The name of the author may not be used to endorse or promote products
derived from this software without specific prior written permission.
 .
 THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR
 IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
 OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
 IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT,
 INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
 NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
 DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
 THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
 (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
 THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

Files: CMake/Documentation.cmake
   CMake/FindLFS.cmake
Copyright: 2016 Julian Andres Klode 
License: Expat
 Permission is hereby granted, free of charge, to any person
 obtaining a copy of this software and associated documentation files
 (the "Software"), to deal in the Software without restriction,
 including without limitation the rights to use, copy, modify, merge,
 publish, distribute, sublicense, and/or sell copies of the Software,
 and to permit persons to whom the Software is furnished to do so,
 subject to the following conditions:
 .
 The above copyright notice and this permission notice shall be
 included in all copies or substantial portions of the Software.
 .
 THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
 MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
 NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
 BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
 ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
 CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
 SOFTWARE.

Li

Bug#1007842: quilt: Please fail gracefully on 'quilt series' when less(1) is not installed

[Akbarkhon Variskhanov]

It seems that this the intended behavior and it's already documented
on the man page:

> QUILT_PAGER
>   The pager quilt shall use for commands which produce paginated 
> output.
>   If  unset, the values of GIT_PAGER or PAGER is used.  If none of 
> these
>   variables is set, "less -R" is used.  An empty value indicates that 
> no
>   pager should be used.

`export QUILT_PATCHES=debian/patches; QUILT_PAGER=more quilt series`
works. As does:
`QUILT_PAGER="" quilt series # no pager`

This is the default behavior. You need to either set up a quiltrc
inside the chroot or set and export whatever environment variables
you're going to need for the session. The fallback `less -R` is needed
because `quilt series` has the option to print output in colors, and
the -R flag enables that. I don't think changing the fallback value
for such corner cases is warranted. However, a bit more informative
message is perhaps necessary.

Bug#1016939: : flaky autopkgtest: padthv1_jack: no process found

[Adrian Bunk]

On Wed, Aug 10, 2022 at 08:50:00AM +0200, Paul Gevers wrote:
> Source: padthv1
> Version: 0.9.17-1
> Severity: serious
> User: debian...@lists.debian.org
> Usertags: flaky
>...
> autopkgtest [18:54:41]: test simpletest: [---
> Simple test success!
> We kill padthv1_jack because it doesn’t close itself in the testbed
> padthv1_jack: no process found
> autopkgtest [18:54:42]: test simpletest: ---]

Since this is anyway just a superficial test whether the program starts,
I'd suggest doing "padthv1_jack -g --version" instead of the start+kill.

cu
Adrian

Bug#1017740: transition: draco

[Paul Gevers]

Hi,

On 06-09-2022 17:34, Timo Röhling wrote:

Given that assimp was specifically binNMU-rebuilt for the new draco
version,


Sorry, I missed this part.

Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1019271: trinity: Upgrade to 1.9+git20220309 or newer

[Eric Long]

Source: trinity
Version: 1.9+git20200331.4d2343bd18c7b-2
Severity: wishlist
Tags: upstream
X-Debbugs-Cc: i...@hack3r.moe

Dear maintainer,

I am currently porting packages to riscv64 platform. Current version of trinity
does not build on riscv64 due to missing SYSCALLS:

```
tables.c: In function ‘select_syscall_tables’:
tables.c:520:39: error: ‘SYSCALLS’ undeclared (first use in this function)
  520 | syscalls = copy_syscall_table(SYSCALLS, ARRAY_SIZE(SYSCALLS));
  |   ^~~~
tables.c:520:39: note: each undeclared identifier is reported only once for 
each function it appears in
make[2]: *** [Makefile:119: tables.o] Error 1
make[2]: *** Waiting for unfinished jobs
```

Versions after 20220309 includes support for riscv64 [1], as well as other new
features described in openSUSE's trinity changelog [2]. Can you please upgrade
its Debian package as well?

Best regards,
Eric

[1]: 
https://github.com/kernelslacker/trinity/commit/80fb6169505cf7a81d4621d7f586d5c2525266f4
[2]: 
https://build.opensuse.org/package/view_file/openSUSE:Factory:RISCV/trinity/trinity.changes?expand=1

Bug#1019270: cups-browsed: Query to /proc/sys/net/ipv6/conf/all/disable_ipv6 blocked by AppArmor, spamming syslog

[Boyuan Yang]

Package: cups-browsed
Version: 1.28.16-1
Severity: normal

Dear Debian cups-filters packagers,

On my current Debian/Sid system (as of Sep 2022), the syslog keeps printing
the following messages:

kernel: audit: type=1400 audit(1662483939.030:193): apparmor="DENIED"
operation="open" profile="/usr/sbin/cups-browsed"
name="/proc/sys/net/ipv6/conf/all/disable_ipv6" pid=3336 comm="cups-browsed"
requested_mask="r" denied_mask="r" fsuid=0 ouid=0

kernel: audit: type=1400 audit(1662483939.030:194): apparmor="DENIED"
operation="open" profile="/usr/sbin/cups-browsed"
name="/proc/sys/net/ipv6/conf/all/disable_ipv6" pid=3336 comm="cups-browsed"
requested_mask="r" denied_mask="r" fsuid=0 ouid=0

audit[3336]: AVC apparmor="DENIED" operation="open" profile="/usr/sbin/cups-
browsed" name="/proc/sys/net/ipv6/conf/all/disable_ipv6" pid=3336
comm="cups-browsed" requested_mask="r" denied_mask="r" fsuid=0 ouid=0

audit[3336]: AVC apparmor="DENIED" operation="open" profile="/usr/sbin/cups-
browsed" name="/proc/sys/net/ipv6/conf/all/disable_ipv6" pid=3336
comm="cups-browsed" requested_mask="r" denied_mask="r" fsuid=0 ouid=0



These logs keeps spam my syslog. Please consider looking into it and adjust
AppArmor profile or cups-browsed program accordingly.

Thanks,
Boyuan Yang



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

Bug#1019158: graphicsmagick breaks gnudatalanguage autopkgtest: undefined symbol: _ZN6Magick5Image12colorMapSizeEv

[GCS]

On Tue, Sep 6, 2022 at 2:06 AM Bob Friesenhahn
 wrote:
> Mercurial changeset 16739:a152f76afeab restores non-const
> Image::colorMapSize() while still providing the new const version.
 Confirmed, this fixes the current ABI breakage.

> I think that this should solve the problem.  Please let me know if it
> doesn't or there is some new problem.
 I'm going to upload this Mercurial snapshot and will see how it
builds and works.

Thanks,
Laszlo/GCS

Bug#1013007: oomd: diff for NMU version 0.5.0-1.2

[Adrian Bunk]

Control: tags 1013007 + patch
Control: tags 1013007 + pending

Dear maintainer,

I've prepared an NMU for oomd (versioned as 0.5.0-1.2) and uploaded it 
to DELAYED/14. Please feel free to tell me if I should cancel it.

cu
Adrian
diff -Nru oomd-0.5.0/debian/changelog oomd-0.5.0/debian/changelog
--- oomd-0.5.0/debian/changelog	2022-01-31 21:05:10.0 +0200
+++ oomd-0.5.0/debian/changelog	2022-09-06 19:43:35.0 +0300
@@ -1,3 +1,10 @@
+oomd (0.5.0-1.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Add upstream fix for FTBFS with gcc 12. (Closes: #1013007)
+
+ -- Adrian Bunk   Tue, 06 Sep 2022 19:43:35 +0300
+
 oomd (0.5.0-1.1) unstable; urgency=high
 
   * Non-maintainer upload.
diff -Nru oomd-0.5.0/debian/patches/0001-Resolved-a-compiler-error-due-to-lacking-include-162.patch oomd-0.5.0/debian/patches/0001-Resolved-a-compiler-error-due-to-lacking-include-162.patch
--- oomd-0.5.0/debian/patches/0001-Resolved-a-compiler-error-due-to-lacking-include-162.patch	1970-01-01 02:00:00.0 +0200
+++ oomd-0.5.0/debian/patches/0001-Resolved-a-compiler-error-due-to-lacking-include-162.patch	2022-09-06 19:43:09.0 +0300
@@ -0,0 +1,44 @@
+From 83a6742f08349fbc93f459228dcc3d1f56eac411 Mon Sep 17 00:00:00 2001
+From: ycitgez 
+Date: Tue, 12 Jul 2022 13:20:32 -0700
+Subject: Resolved a compiler error due to lacking include (#162)
+
+Summary:
+Fixed an issue where a missing include causing compiler errors
+
+Also applied clang-format.sh
+
+Issue occured with following compiler and linker:
+```
+C++ compiler for the host machine: ccache c++ (gcc 12.1.1 "c++ (GCC) 12.1.1 20220507 (Red Hat 12.1.1-1)")
+C++ linker for the host machine: c++ ld.bfd 2.37-27
+```
+
+Pull Request resolved: https://github.com/facebookincubator/oomd/pull/162
+
+Reviewed By: brianc118
+
+Differential Revision: D37790605
+
+Pulled By: lnyng
+
+fbshipit-source-id: d42776978b4bc8f7e2f584fde109e6cc3f5bc7d6
+---
+ src/oomd/Log.h | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/src/oomd/Log.h b/src/oomd/Log.h
+index 3d2d6ea..0ed5f73 100644
+--- a/src/oomd/Log.h
 b/src/oomd/Log.h
+@@ -18,6 +18,7 @@
+ #pragma once
+ 
+ #include 
++#include 
+ #include 
+ #include 
+ #include 
+-- 
+2.30.2
+
diff -Nru oomd-0.5.0/debian/patches/series oomd-0.5.0/debian/patches/series
--- oomd-0.5.0/debian/patches/series	2022-01-31 21:02:45.0 +0200
+++ oomd-0.5.0/debian/patches/series	2022-09-06 19:43:34.0 +0300
@@ -1 +1,2 @@
 0001-Do-not-install-example-systemd-service.patch
+0001-Resolved-a-compiler-error-due-to-lacking-include-162.patch

Bug#1006863: tevent: reproducible-builds: build path embedded in various libraries

[Vagrant Cascadian]

Control: fixed 1006863 0.12.0-1

> On Sun, 06 Mar 2022 16:43:09 -0800 Vagrant Cascadian 
>  wrote:
>> The build path and resulting Build ID for various libraries is embedded:
>> 
>>   
>> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/tevent.html
>> 
>>   /usr/lib/x86_64-linux-gnu/libtevent.so.0.11.0
>> 
>>   /build/1st/tevent-0.11.0/bin/default/../../tevent.c:303
>>   vs.
>>   /build/2/tevent-0.11.0/2nd/bin/default/../../tevent.c:303
>> 
>> The attached patch to debian/rules fixes this by passing
>> -ffile-prefix-map via CFLAGS in the dh_auto_configure override.
>> 
>> Alternately, updating to use the CFLAGS passed via dh/debhelper would
>> also likely fix this.
>
> It looks like current debian build environment already enables 
> -ffile-prefix-map=$(CURDIR)=.
> option, so nothing is needed to be done on the tevent/talloc/etc side.
> Closing this bugreport now.  Please reopen it if you think this is incorrect.

Yeah, appears to have been fixed:

  https://tests.reproducible-builds.org/debian/history/tevent.html

tevent (0.12.0-1) unstable; urgency=medium
...
- use buildflags.mk instead of our own CFLAGS

That is probably what did it.

Thanks!


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1018828: innoextract: Upstream build 1.9 is available

[Alexandre Detiste]

Maybe this could be team-maintained by Games Teams...
(as games are the n°1 user)

Greetings

Le dim. 4 sept. 2022 à 17:31, Antoine Le Gonidec
 a écrit :
>
> Package: innoextract
> Version: 1.8-1.2+b1
> Severity: wishlist
>
> Hi,
>
> innoextract 1.9 has been available for a little while, and is required
> to extract the content of archives built with Inno Setup 6.1.0. Until
> recently I had not found such archives, but a couple ones are now
> distributed through the games store Zoom.
>
> Could you please update the Debian packages to provide the latest
> innoextract 1.9?
>

Bug#1019269: gnome-books: Adapt to libgepub 0.7

[Jeremy Bicha]

Source: gnome-books
Version: 40.0-3
Severity: serious
Tags: bookworm sid ftbfs

gnome-books needs to be updated to build against libgepub 0.7. This is
probably a fairly simple change except that
https://bugs.debian.org/1015138 is a bit awkward to deal with.

GNOME doesn't support GNOME Books any more. The recommended
replacement app is Foliate.

Thank you,
Jeremy Bicha

Bug#1019268: tumbler-plugins-extra: Update for libgepub 0.7

[Jeremy Bicha]

Package: tumbler-plugins-extra
Version: 4.16.0-1
Severity: serious
Tags: ftbfs bookworm sid patch

There's a new version of libgepub in Unstable which makes tumbler fail
to build from source until it's updated to handle the new version.

I'll submit a merge proposal on Salsa for you now.

Thank you,
Jeremy Bicha

Bug#1019267: lprint: wrong path in lprint.service definition

[Bjoern Buerger]

Package: lprint
Version: 1.1.0-1
Severity: normal

Dear Maintainers,

the systemd service file for lprint.service refers
to /usr/local/bin/lprint instead of /usr/bin/lprint
which leads to a non working service state.

Error Message:

 Failed to locate executable /usr/local/bin/lprint: No such file or directory
 Failed at step EXEC spawning /usr/local/bin/lprint: No such file or directory

Affected file:

 /etc/systemd/system/lprint.service

Additional comment:

 The default service file should not be placed in /etc/systemd/system,
 but rather in /usr/lib/systemd/system

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

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

Versions of packages lprint depends on:
ii  libc6  2.34-7
ii  libcups2   2.4.2-1+b1
ii  libpappl1  1.2.1-1

lprint recommends no packages.

lprint suggests no packages.

-- no debconf information

Bug#1019266: gnome-settings-daemon: Fails to load my ICC profile (the display is ignored in the settings)

[Jeremy Bicha]

On Tue, Sep 6, 2022 at 11:21 AM Jean-Luc Coulon (f5ibh)
 wrote:
> I've installed 43-rc-1 from sid.
> It failed to load my ICC profile.
> In "Settings -> Color", it fails to "see" my display.
> I've reverted to 42~beta-1+b1, then everything went fine.

I believe this will be fixed with mutter 43~rc. We may upload
gnome-shell and mutter 43 to Unstable as soon as next week. However,
many packaged GNOME Shell extensions will need to be updated or
removed. See https://bugs.debian.org/1018118 for more details.

You won't be able to stay on 42~beta-1+b1 because of the ongoing
evolution-data-server/libsoup3 transition. Sorry for the
inconvenience.

Thank you,
Jeremy Bicha

Bug#1011954: CVE-2022-1586 CVE-2022-1587

[Matthew Vernon]

Hi,

On 06/09/2022 15:56, Cyril Jouve wrote:


are the binary packages going to be published to bullseye ?


I think they'll be in the next point release of bullseye.

Regards,

Matthew

Bug#1017740: transition: draco

[Timo Röhling]

Hi Paul,

* Paul Gevers  [2022-09-05 21:31]:
Do I understand correctly that you think this is a test-only issue? In 
other words, they can migrate together without breaking tests, but if 
somebody would do a partial upgrade (either one of the two), there is 
no issue? In even other words, there is no *versioned* relation 
(Depends/Breaks) missing?

Given that assimp was specifically binNMU-rebuilt for the new draco
version, I would assume they should migrate together. Do you have a
scenario in mind where this would not work?


Cheers
Timo



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


signature.asc
Description: PGP signature

Bug#891453: wrap-and-sort: Remove trailing whitespace from d/changelog too

[Akbarkhon Variskhanov]

On Tue, 6 Sep 2022 19:10:11 +0500 Akbarkhon Variskhanov
 wrote:
> I suggest a much simpler solution involving the following AWK one-liner:
> > awk 'NF' debian/control

Nevermind, this destroys the structure of paragraphs. Abort.

Still, if it's only trailing newlines that you're concerned about `cat
-s debian/control` should do the job.

The following does get rid of both trailing blank lines (filled with
tabs, spaces, mixed, or just empty) and trailing whitespace at the end
of lines.
awk '{ sub(/[ \t]+$/, ""); line[NR] = $0 }; NF { l = 1; r = NR }; NF
== 0 { l = 0 }; END { if (!l) for (i=1;i<=r;i++) print line[i] }'

But that's looking like another script altogether, which is not what's
requested.

Bug#1018948: chromium: Main context menu opens in left upper corner of the window

[Krassy Boykinov]

Hello Andreas,

i use gnome-shell (wayland mode). I have attached a screenshot of the 
problem.


Best regards

Bug#1019265: flex: use of RESET results in inconsistent indention warnings with clang

[Bill Currie]

Package: flex
Version: 2.6.4-8
Severity: normal

Dear Maintainer,

Using the RESET macro in a lex file causes code with inconsistent
indentation to be added to the output .c file:

clang -DHAVE_CONFIG_H -I. -I.. -I./include  -I../include -D_REENTRANT 
-D_DEFAULT_SOURCE -D_XOPEN_SOURCE=600 -I/usr/include/freetype2 
-I/usr/include/libpng16 -I/usr/include/harfbuzz -I/usr/include/glib-2.0 
-I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/freetype2 
-I/usr/include/libpng16   -g3 -Wall -Werror -Wwrite-strings -Wstrict-prototypes 
-Wmissing-prototypes -Wmissing-declarations -fno-common -mavx2 -O2  -g3 -Wall 
-Werror -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes 
-Wmissing-declarations -fno-common -mavx2 -fno-fast-math -funroll-loops 
-fomit-frame-pointer -fstrict-aliasing -pipe -Wsign-compare -Wtype-limits 
-Wformat-nonliteral -MT tools/qfcc/source/qc-lex.o -MD -MP -MF $depbase.Tpo -c 
-o tools/qfcc/source/qc-lex.o tools/qfcc/source/qc-lex.c &&\
mv -f $depbase.Tpo $depbase.Po
tools/qfcc/source/qc-lex.c:1542:13: error: misleading indentation; statement is 
not part of the previous 'if' [-Werror,-Wmisleading-indentation]
if ( ! (yy_state_buf) )
^
tools/qfcc/source/qc-lex.c:1540:9: note: previous statement is here
if ( ! (yy_state_buf) )
^
tools/qfcc/source/qc-lex.c:2344:3: error: misleading indentation; statement is 
not part of the previous 'if' [-Werror,-Wmisleading-indentation]
return yy_is_jam ? 0 : yy_current_state;
^
tools/qfcc/source/qc-lex.c:2341:2: note: previous statement is here
if ( ! yy_is_jam )
^
2 errors generated

QuakeForge is available from https://github.com/quakeforge/quakeforge

In addition, flex's generated file is inconsistent with its use of
spaces vs tabs (ignoring the tabs used in QF's qc-lex.l: such is
understandable).

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

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

Versions of packages flex depends on:
ii  debconf [debconf-2.0]  1.5.79
ii  libc6  2.34-6
ii  m4 1.4.19-1

Versions of packages flex recommends:
ii  clang-11 [c-compiler]   1:11.1.0-6+b2
ii  clang-13 [c-compiler]   1:13.0.1-7
ii  clang-14 [c-compiler]   1:14.0.6-2
ii  clang-6.0 [c-compiler]  1:6.0.1-14.1
ii  clang-7 [c-compiler]1:7.0.1-12
ii  clang-9 [c-compiler]1:9.0.1-20+b1
ii  gcc [c-compiler]4:12.1.0-3
ii  gcc-10 [c-compiler] 10.4.0-4
ii  gcc-11 [c-compiler] 11.3.0-5
ii  gcc-12 [c-compiler] 12.2.0-1
ii  gcc-6 [c-compiler]  6.5.0-2
ii  gcc-8 [c-compiler]  8.4.0-7
ii  gcc-9 [c-compiler]  9.5.0-2
ii  libfl-dev   2.6.4-8

Versions of packages flex suggests:
ii  bison2:3.8.2+dfsg-1
ii  build-essential  12.9
pn  flex-doc 

-- no debconf information

Bug#1018906: dwarves: FTBFS with libbpf 1.0.0

[Sudip Mukherjee]

On Tue, Sep 6, 2022 at 3:16 PM Domenico Andreoli  wrote:
>
> On Tue, Sep 06, 2022 at 10:47:44AM +0100, Sudip Mukherjee wrote:
> > Hi Dom,
> >
> > On Sun, Sep 4, 2022 at 5:54 PM Domenico Andreoli  wrote:
> > >
> > > On Thu, Sep 01, 2022 at 08:57:21PM +0100, Sudip Mukherjee wrote:
> > > >
> > > > Dear Maintainer,
> > >
> > > Hi Sudip,
> > >
> > > >
> > > > dwarves FTBFS with libbpf 1.0.0 (available in experimental).
> > > > Hopefully this is the error from the build log:
> > > >



> > It does look like libbpf has now added a hard dependency on v6.0+
> > kernel even though they said it will have "transparent handling of
> > older kernels".
> > I have mentioned it in
> > https://github.com/libbpf/libbpf/issues/562#issuecomment-1237299951.
> > So, we either need to wait for some fix from libbpf upstream or wait
> > for the Debian kernel team to update to v6.0 after its released next
> > month.
>
> This already happened in the past, I solved it by adding linux-libc-dev
> to dwarves' build depends.
>
> It's not obvious why this is visible only when building dwarves and
> not libbpf itself. I nevertheless think it should be libbpf to depend
> on the right linux-libc-dev, not the packages using it.
>
> What do you think?

yes, if libbpf upstream can not fix it then I will need to update
libbpf with a dependency like
linux-libc-dev (>= 6.0)


-- 
Regards
Sudip

Bug#1011954: CVE-2022-1586 CVE-2022-1587

[Cyril Jouve]

Hi,

are the binary packages going to be published to bullseye ?

Regards,
Cyril

Bug#1017944: grub-xen-host: 2.06-3 crashes PV guests in early boot

[Valentin Kleibel]

found 1017944 grub2/2.06-3~deb11u1
severity 1017944 serious
tags 1017944 patch

Dear Maintainers,

We can confirm that this bug affects all pv and pvh domUs that use pvgrub.
The commit responsible is 20239c28 "Bump debhelper from old 10 to 13." [1]
The relevant change in debhelper came with version v11: "The dh_strip 
and dh_shlibdeps tools no longer uses filename patterns to determine 
which files to process. Instead, they open the file and look for an ELF 
header to determine if a given file is an shared object or an ELF 
executable."

By choosing debhelper 13, this led to pv grub getting stripped.
A simple override to dh_strip mitigates the issue.

We assume that testing and unstable are affected as well but we do not 
have systems to test this.


Cheers,
Valentin

[1] 
https://salsa.debian.org/grub-team/grub/-/commit/20239c28e1e9ca3eba993e7702f5cb4da81dcf95--- a/debian/rules	2022-09-06 15:44:06.183081104 +0200
+++ b/debian/rules	2022-09-06 15:44:12.878341465 +0200
@@ -544,7 +544,7 @@
 	dh_bugfiles $(patsubst %,-N%,$(filter grub-efi-%-signed-template,$(BUILD_PACKAGES))) -A
 
 override_dh_strip:
-	dh_strip -X/usr/bin/grub-emu
+	dh_strip -X/usr/bin/grub-emu -X/usr/lib/grub-xen/grub-x86_64-xen.bin -X/usr/lib/grub-xen/grub-i386-xen_pvh.bin -X/usr/lib/grub-xen/grub-i386-xen.bin
 
 override_dh_shlibdeps:
 	dh_shlibdeps -X.module

Bug#1018906: dwarves: FTBFS with libbpf 1.0.0

[Domenico Andreoli]

On Tue, Sep 06, 2022 at 10:47:44AM +0100, Sudip Mukherjee wrote:
> Hi Dom,
> 
> On Sun, Sep 4, 2022 at 5:54 PM Domenico Andreoli  wrote:
> >
> > On Thu, Sep 01, 2022 at 08:57:21PM +0100, Sudip Mukherjee wrote:
> > >
> > > Dear Maintainer,
> >
> > Hi Sudip,
> >
> > >
> > > dwarves FTBFS with libbpf 1.0.0 (available in experimental).
> > > Hopefully this is the error from the build log:
> > >
> > > In file included from /home/sudip/test/dwarves-1.23/btf_encoder.c:18:
> > > /usr/include/bpf/btf.h: In function 'btf_enum64_value':
> > > /usr/include/bpf/btf.h:496:25: error: invalid use of undefined type 
> > > 'const struct btf_enum64'
> > >   496 | return ((__u64)e->val_hi32 << 32) | e->val_lo32;
> > >   | ^~
> > > /usr/include/bpf/btf.h:496:46: error: invalid use of undefined type 
> > > 'const struct btf_enum64'
> > >   496 | return ((__u64)e->val_hi32 << 32) | e->val_lo32;
> > >   |  ^~
> >
> > Which version of linux-libc-dev are you using? I see that struct
> > btf_enum64 is introduced only in kernel 6.0, not yet packaged.
> 
> It does look like libbpf has now added a hard dependency on v6.0+
> kernel even though they said it will have "transparent handling of
> older kernels".
> I have mentioned it in
> https://github.com/libbpf/libbpf/issues/562#issuecomment-1237299951.
> So, we either need to wait for some fix from libbpf upstream or wait
> for the Debian kernel team to update to v6.0 after its released next
> month.

This already happened in the past, I solved it by adding linux-libc-dev
to dwarves' build depends.

It's not obvious why this is visible only when building dwarves and
not libbpf itself. I nevertheless think it should be libbpf to depend
on the right linux-libc-dev, not the packages using it.

What do you think?

-- 
rsa4096: 3B10 0CA1 8674 ACBA B4FE  FCD2 CE5B CF17 9960 DE13
ed25519: FFB4 0CC3 7F2E 091D F7DA  356E CC79 2832 ED38 CB05


signature.asc
Description: PGP signature

Bug#1018949: netkit-telnet: Drop in favour of netkit-telnet-ssl

[Bastian Germann]

Am 03.09.22 um 15:17 schrieb Simon Josefsson:

Bastian Germann  writes:


Thanks for preparing the transition from netkit-telnet to the inetutils version.
We can get rid of this source package by recommending the netkit-telnet-ssl 
packages on inetutils instead.
Why have the same non-maintained upstream source twice?


Hi.  That's a great observation, thanks for sharing it.  I didn't look
too close at the netkit-telnet-ssl package, and merely assumed it was
widely different compared to netkit-telnet thus saving it for another
rainy day.

They at least share the same orig.tar.gz:

jas@latte:~/n$ sha1sum netkit-telnet_0.17.orig.tar.gz 
netkit-telnet-ssl_0.17.41+0.2.orig.tar.gz
41213dedaf242126b54a3ac51b905a351eb22b15  netkit-telnet_0.17.orig.tar.gz
41213dedaf242126b54a3ac51b905a351eb22b15  
netkit-telnet-ssl_0.17.41+0.2.orig.tar.gz
jas@latte:~/n$

So all changes between the packages are derived from the debian/
differences, which reduces the comparison surface, but digesting the
diff wasn't that simple.  I started focusing on debian/patches and even
that was non-trivial:

Only in netkit-telnet/patches/: 110-markup_errors.diff


markup_errors is not included in -ssl.


Only in netkit-telnet/patches/: 124-support_uservar.diff


included in -ssl as 610-support_uservar.diff


Only in netkit-telnet/patches/: 140-telnetlogin_name_check.diff


Included in -ssl within 514-mixed_up_to_24_7_1.diff


Only in netkit-telnet/patches/: 142-numeric_hosts.diff


included in -ssl as 512-numeric_hosts.diff.


Only in netkit-telnet-ssl/patches/: 500-implement_ssl.diff
Only in netkit-telnet-ssl/patches/: 510-can_2004_0640_and_0998.diff
Only in netkit-telnet-ssl/patches/: 512-numeric_hosts.diff
Only in netkit-telnet-ssl/patches/: 514-mixed_up_to_24_7_1.diff
Only in netkit-telnet-ssl/patches/: 516-telnet_up_to_24_7_1.diff
Only in netkit-telnet-ssl/patches/: 518-telnetd_up_to_24_7_1.diff
Only in netkit-telnet-ssl/patches/: 520-from_7_1_to_14.diff
Only in netkit-telnet-ssl/patches/: 530-from_14_to_21.diff
Only in netkit-telnet-ssl/patches/: 540-buffer_overflow.diff
Only in netkit-telnet-ssl/patches/: 545-track_scm.diff
Only in netkit-telnet-ssl/patches/: 600-better_diagnostic.diff
Only in netkit-telnet-ssl/patches/: 610-support_uservar.diff
Only in netkit-telnet-ssl/patches/: 630-recent_libssl.diff
Only in netkit-telnet-ssl/patches/: 650-improve_abilities.diff
diff -ur netkit-telnet/patches/series netkit-telnet-ssl/patches/series
Only in netkit-telnet/patches/: telnet-netwritebuf-fix.diff


telnet-netwritebuf-fix is not included in -ssl.


diff -ur netkit-telnet/patches/use-cmake-as-buildsystem-debian-extras.patch 
netkit-telnet-ssl/patches/use-cmake-as-buildsystem-debian-extras.patch
diff -ur netkit-telnet/patches/use-cmake-as-buildsystem.patch 
netkit-telnet-ssl/patches/use-cmake-as-buildsystem.patch

Reaching confidence that netkit-telnet-ssl and netkit-telnet are
sufficiently similar so that there is no use-case where one of the
packages fail to work but the other does seems difficult.  Is anyone
interested in doing that analysis?


I have just uploaded a -ssl QA upload that should include all work done in your 
package
and be good enough to continue work there.


Another option is that we let time and bug reports perform the
confidence analysis for us, so we could ship netkit-telnet and
netkit-telnet-ssl with bookworm, since that will be the first time
inetutils becomes the "default" telnet/telnetd, and people may want to
go back with netkit-telnet for some reason.  The release notes could say
that we want to drop netkit-telnet* and people should report any
compatibility problem they encounter with GNU InetUtils so we can plan
accordingly.


I think that we should not ship both source packages with bookworm.
When people see issues with one of them, there should only be one place to fix 
them.
telnet-netwritebuf-fix is an example that was just fixed for the non-ssl 
version.


Alternatively, work on netkit-telnet and netkit-telnet-ssl to sync them.
I'm happy to do that in netkit-telnet but cannot speak for the
maintainers of netkit-telnet-ssl.  Then if we incrementally make them
closer to each other it will become clear if netkit-telnet provides
anything that netkit-telnet-ssl cannot.


There are no maintainers for netkit-telnet-ssl. It is orphaned.
I suggest you adopt that package, recommend the -ssl version on inetutils,
and file a RM bug for the non-ssl package.


I don't have a strong opinion on any solution, but I think we should be
conservative in what we do -- it may years for people to realize
civilization depends on a particular behaviour of netkit-telnet...


Yes, but they still have that behaviour with netkit-telnet-ssl.

Bug#1019264: RM: libphobos2-ldc-sharedXX -- RoQA; NBS

[Jochen Sprickerhof]

Package: ftp.debian.org
Severity: normal


Hi,

please remove some of the libphobos2-ldc-sharedXX packages that are no
longer build from the ldc source package and have no reverse
dependencies:

RM: libphobos2-ldc-shared86 -- RoQA; NBS
RM: libphobos2-ldc-shared87 -- RoQA; NBS
RM: libphobos2-ldc-shared88 -- RoQA; NBS
RM: libphobos2-ldc-shared90 -- RoQA; NBS
RM: libphobos2-ldc-shared91 -- RoQA; NBS

Cheers Jochen

Bug#1006818: eye: (autopkgtest) failure on non-amd64

[Jonas Smedegaard]

Quoting Lev Lamberov (2022-09-06 14:00:55)
> Hi Jonas,
> 
> Сб 03 сен 2022 @ 21:19 Jonas Smedegaard :
> 
> >> The autopkgtest caught that the package is not functional on !amd64:
> >> 
> >> (buster_arm64-dchroot)bunk@amdahl:/tmp$ eye.pvm 
> >> /usr/bin/eye.pvm: 3: exec: /usr/lib/swi-prolog/bin/x86_64-linux/swipl: not 
> >> found
> >> (buster_arm64-dchroot)bunk@amdahl:/tmp$ 
> >> 
> >> Changing Architecture: from "all" to "any" might be a reasonable option.
> >
> > In my understanding, this is a bug in SWI Prolog, in that when
> > generating a so-called "intermediate code file" it embeds an
> > arch-specific path to the interpreter instead of the arch-independent
> > symlink in PATH: /usr/bin/swipl
> >
> > @Lev: What do you think?  Is it possible to patch SWI Prolog to embed an
> > architecture-agnostic path for executing intermediary files?
> 
> SWI-Prolog supports three different pre-compiled formats: qlf, boot.prc,
> and user created states. The first two do not include paths to the
> interpreter. Looks like eye relies on the third one. I've asked upstream
> about the possibility to embed an arch-independent path to such user
> created states and got the answer that sometimes it is not a good idea,
> because these states may differ due to conditional compilation. I've
> looked into eye and looks like it does not (at least curretly, or I was
> not able to spot it) use conditional compilation on various
> architectures. So, I think it is probably save to embed arch-independent
> path to the interpreter. SWI-Prolog upstream pushed a commit to support
> this feature, but one should enable it explicitely with a command-line
> option when running swipl to generate pre-compiled file of this kind
> (like, swipl -o myexe --emulator=/usr/bin/swipl -c mycode.pl). I will
> add this patch to the swi-prolog in Debian in the near future (probably,
> I will have some time for it on the coming weekend, also I plan to
> finish packaging a new upstream stable release, 8.4.3, where Debian is
> at 8.4.2 at this point). I'll let you know when you can experiment with
> eye concerning this change.

Cool!  Thanks a lot!


 - Jonas

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

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

signature.asc
Description: signature

Bug#1018672: fixed in gnome-control-center 1:43~rc-2

[Daniel Serpell]

Hi!

The bug number was mixed up in the changelog, so the wrong bug got closed.

Regards,
   Daniel.

On Mon, 05 Sep 2022 21:39:39 + Debian FTP Masters
 wrote:
> Source: gnome-control-center
> Source-Version: 1:43~rc-2
> Done: Jeremy Bicha 
>
> We believe that the bug you reported is fixed in the latest version of
> gnome-control-center, which is due to be installed in the Debian FTP archive.
>
> A summary of the changes between this version and the previous one is
> attached.
>
> Thank you for reporting the bug, which will now be closed.  If you
> have further comments please address them to 1018...@bugs.debian.org,
> and the maintainer will reopen the bug report if appropriate.
>
> Debian distribution maintenance software
> pp.
> Jeremy Bicha  (supplier of updated gnome-control-center 
> package)
>
> (This message was generated automatically at their request; if you
> believe that there is a problem with it please contact the archive
> administrators by mailing ftpmas...@ftp-master.debian.org)
>
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> Format: 1.8
> Date: Mon, 05 Sep 2022 16:57:51 -0400
> Source: gnome-control-center
> Built-For-Profiles: noudeb
> Architecture: source
> Version: 1:43~rc-2
> Distribution: unstable
> Urgency: medium
> Maintainer: Debian GNOME Maintainers 
> 
> Changed-By: Jeremy Bicha 
> Closes: 1018672
> Launchpad-Bugs-Fixed: 1988087
> Changes:
>  gnome-control-center (1:43~rc-2) unstable; urgency=medium
>  .
>* New upstream release
>  - Fixes Screen Blank control (Closes: #1018672, LP: #1988087)
>* debian/control.in: Bump minimum meson to 0.57.0
>* Build against libsoup3 libraries
>* Drop sound patch: applied in new release
> Checksums-Sha1:
>  c9978230494cead95d8dbbbd85a0606b7d813618 3621 
> gnome-control-center_43~rc-2.dsc
>  52da8b5357778ac7f3f5ad563841d83eaaff06bd 5673392 
> gnome-control-center_43~rc.orig.tar.xz
>  25dc1b4643c14c2512b15588b8c5947cea85f09d 38032 
> gnome-control-center_43~rc-2.debian.tar.xz
>  5c11e0c65fb885dae72e0245f234f291355df659 21693 
> gnome-control-center_43~rc-2_source.buildinfo
> Checksums-Sha256:
>  8cd19bd2b222821a977bb6bbc0467f53efc96cb0cc3e8a9d97a4845acda8d457 3621 
> gnome-control-center_43~rc-2.dsc
>  da152e068e70a3643abd5a2a08cb033420b94c8538938e0376fb1fe6e29cbe7c 5673392 
> gnome-control-center_43~rc.orig.tar.xz
>  3aa28f22321bec77eb3e6fbb7d745dd5fc98e03c40c40004dad0dbfc1207d923 38032 
> gnome-control-center_43~rc-2.debian.tar.xz
>  7880b2255d51b6605ef1c2c90af92cb09c43355c038fba34c5e6d77bfe8ae632 21693 
> gnome-control-center_43~rc-2_source.buildinfo
> Files:
>  e3d05296f409054b301742ed9980f051 3621 gnome optional 
> gnome-control-center_43~rc-2.dsc
>  ae4c52d06768dd6f909c50fc5905b6e3 5673392 gnome optional 
> gnome-control-center_43~rc.orig.tar.xz
>  c180661bbb921d8aa4a6b5fa57832480 38032 gnome optional 
> gnome-control-center_43~rc-2.debian.tar.xz

Bug#891453: wrap-and-sort: Remove trailing whitespace from d/changelog too

[Akbarkhon Variskhanov]

I suggest a much simpler solution involving the following AWK one-liner:
> awk 'NF' debian/control

Bug#1019263: chromium: Audio capture (e.g., in MS Teams) doesn't work

[Sam Morris]

Package: chromium
Version: 105.0.5195.102-1
Severity: normal
X-Debbugs-Cc: s...@robots.org.uk

When I try to join a Teams meeting, I get the mesasge

Are you sure you don't want audio or video? If you change your mind,
select the camera icon by your address bar and then _Always allow_.

This appears to happen because Teams can't see the existance of my
microphone. When I click the camera icon in the address bar, I see:

Camera and Microphone Blocked

This page has been blocked from accessing your camera and micrphone.

( ) Always allow https://teams.microsoft.com to access your camera and
microphone

(x) Continue blocking camera and microphone access


Microphone: Default

Camera: TOSHIBA Web Cam...

[Manage] [Done]

Now the funny things about this popup are:

 * Selecting 'always allow' and pressing Done doesn't work. If I click
   the camera icon again, the popup comes back and 'always allow' is
   selected, but Teams behaves as if I didn't change the option and
   continued to block it.

 * If I reload the page and join another meeting, 'Continue blocking' is
   set, so chromium doesn't remember my selection between page loads.

 * When I try to change the devices listed in the popup, by clicking on
   what I assume is supposed to be a dropdown menu, nothing happens;
   it's as if the widget is disabled, though there is no visual
   indication of such

 * If I press Manage, it takes me to
which has an entry right
   at the top of 'recent activity' saying: teams.microsoft.com: Allowed
   camera, microphone

 * If I click on this entry it takes me to
   

   which under 'permissions' has Microphone set to Block. If I click
   this I get a dropdown menu with the entries Block (default), Allow
   and Block. If I choose Allow in this dropdown menu, the choice is
   instantly reset back to Block.

Trying to debug this at another site,
,
when I press 'Start' I get the same popup as with Teams (although this
one doesn't mention the camera being blocked). This one has the same
behaviour: 'Continue blocking' is selected by default, if I change it to
'allow' and press 'Done', nothing happens. If I reload the page, next
time I click the camera icon to get the popup, 'Continue blocking' is
still set.

In the console, these messages are logged when I press 'Start'.

Requesting local stream
main.js:56 navigator.MediaDevices.getUserMedia error:  Permission denied 
NotAllowedError

-- System Information:
Debian Release: 11.4
  APT prefers stable-updates
  APT policy: (570, 'stable-updates'), (570, 'stable-security'), (570, 
'stable-debug'), (570, 'stable'), (550, 'testing-debug'), (550, 'testing'), 
(530, 'unstable-debug'), (530, 'unstable'), (1, 'experimental-debug'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.18.0-3-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_USER, TAINT_DIE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Permissive - Policy name: default

Versions of packages chromium depends on:
ii  chromium-common 105.0.5195.102-1
ii  libasound2  1.2.7.2-1
ii  libatk-bridge2.0-0  2.38.0-1
ii  libatk1.0-0 2.36.0-2
ii  libatomic1  12.2.0-1
ii  libatspi2.0-0   2.38.0-4
ii  libbrotli1  1.0.9-2+b2
ii  libc6   2.34-4
ii  libcairo2   1.16.0-5
ii  libcups22.4.2-1+b1
ii  libdbus-1-3 1.12.20-2
ii  libdouble-conversion3   3.1.5-6.1
ii  libdrm2 2.4.104-1
ii  libevent-2.1-7  2.1.12-stable-1
ii  libexpat1   2.2.10-2+deb11u3
ii  libflac81.3.3-2+deb11u1
ii  libfontconfig1  2.13.1-4.2
ii  libfreetype62.12.1+dfsg-3
ii  libgbm1 20.3.5-1
ii  libgcc-s1   12.2.0-1
ii  libglib2.0-02.72.3-1+b1
ii  libgtk-3-0  3.24.34-3
ii  libjpeg62-turbo 1:2.0.6-4
ii  libjsoncpp251.9.5-4
ii  liblcms2-2  2.12~rc1-2
ii  libminizip1 

Bug#993527: [debian-mysql] Bug#993527: Bug#993527: mariadb-server: At full-upgrade from buster to bullseye mariadb-server (and also client) are removed.

[Faustin Lammler]

tags -1 moreinfo


signature.asc
Description: PGP signature

Bug#1010846: Fwd: Re: [debian-mysql] Bug#1010846: mariadb-common: Removes directory /etc/mysql/mariadb.conf.d during uninstall preventing mysql server from starting

[Faustin Lammler]

tags -1 moreinfo


signature.asc
Description: PGP signature

Bug#1001843: [debian-mysql] Bug#1001843: libmariadb-dev: mariadb_config reports incorrect plugin directory

[Faustin Lammler]

tags -1 moreinfo


signature.asc
Description: PGP signature

Bug#1014175: warning: cannot run debian/readme check on package binary:postgresql-15_15~beta2-2+salsaci_amd64

[Christoph Berg]

Re: To Debian Bug Tracking System
> Warning in processable 
> /builds/postgresql/postgresql/debian/output/postgresql-15_15~beta2-2+salsaci_amd64.deb:
>  Cannot open 
> /tmp/lintian-pool-WqVHVEiN6s/postgresql-15/postgresql-15_15~beta2-2+salsaci_amd64_binary/unpacked/usr/share/doc/postgresql-15/README.Debian.gz
>  at /usr/share/lintian/lib/Lintian/Check/Debian/Readme.pm line 109.

README.Debian.gz is a symlink to a package that isn't built from
postgresql-15, I guess that might be a problem:

lrwxrwxrwx 1 root root 37 10. Aug 14:33 
/usr/share/doc/postgresql-15/README.Debian.gz -> 
../postgresql-common/README.Debian.gz

Re: Lucas Nussbaum
> /usr/share/doc/exim4-daemon-heavy/README.Debian.gz is a symlink to
> ../exim4-base/README.Debian.gz.

... these are from the same source package, though.

Christoph

Bug#1019259: devscripts: The command uscan with the option 'dehs' doesn't always generate valid XML ouput

[Yadd]

Control: tags -1 + moreinfo

Hi,

uscan generates a valid XML on STDOUT and displays messages on STDERR. 
Use `uscan --dehs 2>/dev/null`

Bug#1018063: [debian-mysql] Bug#1018063: Regression: mariadb client default charset changed breaks compatibility

[Faustin Lammler]

Hi Tim!
Thanks for your report.

I have cc. Georg since he helped a lot on
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=933063.

@Georg, can I kindly ask you to take a look at this bug report
(https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1018063)? I am happy
to fix it with some guidance from you (whether it's upstream or here in
Debian packaging).

Regards,

-- 
Faustin


signature.asc
Description: PGP signature

Bug#993219: [debian-mysql] Bug#993219: Bug#993219: mariadb-server-core: Akonadi database - mysql_upgrade fails always with "FATAL ERROR: Can't execute 'mysqlcheck'"

[Faustin Lammler]

Hi Ulrich!

Since this seems not a MariaDB bug, can I kindly ask you to close it?

Otto did a "batch re-opening" because we did not want to loose any bug
report when 10.5 was replaced by 10.6 in Sid.

Regards,

-- 
Faustin


signature.asc
Description: PGP signature

Bug#1018899: gcr-prompter dumps secrets in syslog/journald

[Antoine Beaupré]

On 2022-09-04 21:50:51, Simon McVittie wrote:
> On Thu, 01 Sep 2022 at 14:22:45 -0400, Antoine Beaupre wrote:
>> The bits marked [REDACTED] actually contains what looks like some sort
>> of secret key.
>
> As discussed on IRC, I *think* it's the public part of an asymmetric
> keypair, which would reduce the severity of this bug, but it still seems
> like a valid bug (gcr-prompter shouldn't be writing g_debug()-level logging
> to syslog).

Thanks for the clarification! Certainly reassuring...

>> I'm using a weird desktop here: i3wm started from systemd, with *some*
>> GNOME bits (e.g. network-manager and nm-applet, for example).
>
> This bug is probably only applicable in desktop environments that don't
> provide an integrated libsecret prompt (not GNOME, and possibly also not
> other major desktop environments like Plasma).

Right, that makes sense. For me, the workaround was to switch to
pinentry-qt which doesn't exhibit that behavior, with the alternatives
system:

 update-alternatives --set pinentry-x11 /usr/bin/pinentry-qt

Thanks!

-- 
Conformity-the natural instinct to passively yield to that vague something
recognized as authority.
- Mark Twain

Bug#1010049: qt6-base-dev: should provide a QT_HOST_PATH directory for cross building

[Fab Stz]

Hello.

I have a similar problem.

In addition to:
-DQT_HOST_PATH=/usr/lib/qt6

You must also set:
-DQT_HOST_PATH_CMAKE_DIR=/usr/lib/${DEB_HOST_MULTIARCH}/cmake

But then it still fails with this error now:

Configuring submodule 'qtbase'
-- Could NOT find Qt6CoreTools (missing: Qt6CoreTools_DIR)
CMake Error at qtbase/cmake/QtToolHelpers.cmake:184 (message):
  Failed to find the host tool "Qt6::moc".  It is part of the Qt6CoreTools
  package, but the package could not be found.  Make sure you have built and
  installed the host Core module, which will ensure the creation of the
  Qt6CoreTools package.
Call Stack (most recent call first):
  qtbase/src/tools/moc/CMakeLists.txt:8 (qt_internal_add_tool)



Any idea how to make it find the Qt core tools like moc?
The qt6-base-dev package is installed, as well as qt6-base-dev-tools

Regards


On Sat, 23 Apr 2022 15:14:55 +0200 Helmut Grohne  wrote:
> Hi,
> 
> On Sat, Apr 23, 2022 at 09:38:54AM +0200, Helmut Grohne wrote:
> > I expect that QT_HOST_PATH also needs to point to architecture-dependent
> > files (e.g. libraries). Qt5 has faced as similar problem and thus added
> 
> Dmitry noted that none of Qt6's executables (possibly except for qmake)
> are architecture-dependent and encouraged me to try
> -DQT_HOST_PATH=/usr/lib/qt6. When you

Bug#1010407: sse3 check issue

[Mathieu Malaterre]

Control: found -1 105.0.5195.52-1~deb11u1

On Tue, Sep 6, 2022 at 3:38 PM Mathieu Malaterre  wrote:
>
> On Tue, Sep 6, 2022 at 3:33 PM François J. | RosarioSIS
>  wrote:
> >
> > Hello,
> >
> >
> > I have issues since upgrading to Chrome 105 (bullseye-security).
> >
> > I have the sse3 check popping up:
> >
> > The hardware on this system lacks support for the sse3 instruction set.
> > The upstream chromium project no longer supports this configuration.
> > For more information, please read and possibly provide input to their
> > bug tracking system at http://crbug.com/1123353
> >
> >
> > But according to this test
> > https://unix.stackexchange.com/questions/131954/check-sse3-support-from-bash
> > my CPU (64bit by the way) does support sse3 (via pni).
> >
> > Could you please update the check to include pni?
>
> I can see it:
>
> https://salsa.debian.org/chromium-team/chromium/-/blob/debian/105.0.5195.102-1_deb11u1/debian/scripts/chromium#L34-42

Nevermind. I misread the version information.

Bug#1001843: [debian-mysql] Bug#1001843: libmariadb-dev: mariadb_config reports incorrect plugin directory

[Faustin Lammler]

Without more information from reporter we will have to close this bug
report.

Regards,

-- 
Faustin


signature.asc
Description: PGP signature

Bug#1010407: sse3 check issue

[Mathieu Malaterre]

On Tue, Sep 6, 2022 at 3:33 PM François J. | RosarioSIS
 wrote:
>
> Hello,
>
>
> I have issues since upgrading to Chrome 105 (bullseye-security).
>
> I have the sse3 check popping up:
>
> The hardware on this system lacks support for the sse3 instruction set.
> The upstream chromium project no longer supports this configuration.
> For more information, please read and possibly provide input to their
> bug tracking system at http://crbug.com/1123353
>
>
> But according to this test
> https://unix.stackexchange.com/questions/131954/check-sse3-support-from-bash
> my CPU (64bit by the way) does support sse3 (via pni).
>
> Could you please update the check to include pni?

I can see it:

https://salsa.debian.org/chromium-team/chromium/-/blob/debian/105.0.5195.102-1_deb11u1/debian/scripts/chromium#L34-42

Bug#1019262: libxmlb2: Under some circumstances, depending on the data, memory blocks can be double-freed.

[Sergio Costas Rodriguez]

Package: libxmlb2
Version: 0.3.6-2build1
Severity: normal
Tags: patch
X-Debbugs-Cc: sergio.cos...@canonical.com

Recently, several users complaint that snap-store (which is derived from gnome-
software) was crashing on start up with a segmentation fault. We found that the
bug was in libxmlb, where, under some circumstances, some memory blocks could
be double-freed when the library performed a prune of the binary tree.

This bug has been there since, at least, version 0.1.8, so it probably affects
Debian Stable and old-Stable too.

A patch was sent to upstream and was merged immediately
(https://github.com/hughsie/libxmlb/pull/127).

Also, a patch adapted for version 0.3.8 (the one currently in Debian SID) has
been sent to the SALSA repository: https://salsa.debian.org/efi-
team/libxmlb/-/merge_requests/6


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

Kernel: Linux 5.15.0-47-generic (SMP w/16 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8), LANGUAGE=es:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libxmlb2 depends on:
ii  libc6 2.35-0ubuntu3.1
ii  libglib2.0-0  2.72.1-1
ii  liblzma5  5.2.5-2ubuntu1

libxmlb2 recommends no packages.

libxmlb2 suggests no packages.

-- no debconf information

Bug#1019115: open3d: Switch libmsgpack-dev to libmsgpack-cxx-dev

[Timo Röhling]

Hi James,

* james...@debian.org  [2022-09-03 23:21]:

libmsgpack-dev's C++ bindings were split out to a separate binary
package -- libmsgpack-cxx-dev -- in 4.1.1-1 to follow upstream's
separation of the project. open3d (Build-)Depends on libmsgpack-dev
and uses the C++ library, so it needs to switch to
libmsgpack-cxx-dev.

I'm waiting for the draco transition to complete, then I'll upload
a fixed version.


Cheers
Timo

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


signature.asc
Description: PGP signature

Bug#1017983: reprepro: upgrade from 5.3.0-1.2 to 5.4.1-1 loses data

[Bastian Germann]

Am 06.09.22 um 15:24 schrieb L.P.H. van Belle:

*( why do we need reprepro 5.4.1-1 )


It is experimental because it has a major feature that needs the db upgrade:
multiple versions of one package in the same repo.

It is your choice to install experimental packages. You decide whether you need 
them.

Bug#1010846: Fwd: Re: [debian-mysql] Bug#1010846: mariadb-common: Removes directory /etc/mysql/mariadb.conf.d during uninstall preventing mysql server from starting

[Faustin Lammler]

I am still not able to reproduce this on:
- debian 11, mariadb 10.5
- debian sid, mariadb 10.6

Unless the reporter gives more info on how to reproduce this we will
have to close this bug report.

Regards,

-- 
Faustin


signature.asc
Description: PGP signature

Bug#1017983: reprepro: upgrade from 5.3.0-1.2 to 5.4.1-1 loses data

[L.P.H. van Belle]

I can confirm this also. 

I tested stretch reprepro upgrades upto testing.. 
All my reprepro databases corrupted, im now rebuilding it all again. 
*( why do we need reprepro 5.4.1-1 ) 

I compile for Debian and Ubuntu, I needed the latest version to get the Ubuntu 
packages in. 


Greetz, 

Louis

Bug#1019035: systemd-cron: prerm fails in unbooted systems

[Alexandre Detiste]

> Thank you in advance for your consideration. I hope you will agree this
> is a bug and apply the (trivial) patch, not send me away with an
> admonishment that this is user error. :)

I actually do the same kind of "not booted filesystem manipulation in
an chrooted overlayfs"
for the Debian-derived distro I'm building at work.
It's horrible, but it has to work.

Thanks for comparing with what the debhelper snippet is doing,
I should have done this aniway.

Thanks

Bug#1008708: Regarding pysolfc embedding a python module

[Athos Ribeiro]

Hi,

First of all, IANAL.

As I commented in a similar bug in Ubuntu [1], while the fix for this
issue is available upstream and seems technically straightforward, it
injects a deprecated python module in its code base and re-licenses it
as CC0. The PSF license suggests "that PSF's License Agreement and PSF's
notice of copyright [...] are retained in Python alone or in any
derivative version" and that "in the event Licensee prepares a
derivative work that is based on or incorporates Python or any part
thereof [...], then Licensee hereby agrees to include in any such work a
brief summary of the changes made to Python."

[1] https://bugs.launchpad.net/ubuntu/+source/pysolfc/+bug/1967793/comments/8


--
Athos Ribeiro

Bug#993527: [debian-mysql] Bug#993527: Bug#993527: mariadb-server: At full-upgrade from buster to bullseye mariadb-server (and also client) are removed.

[Faustin Lammler]

Hi!

As said in my previous message, I am not able to reproduce this so
unless reporter gives more information I will close this bug report
since it seems to be fixed.

In the mean time and to be sure that we do not hit this problem again, I
have implemented a full-upgrade test step in Salsa CI:
https://salsa.debian.org/mariadb-team/mariadb-server/-/merge_requests/19

Cheers!

---
Faustin


signature.asc
Description: PGP signature

Bug#1019260: libssh: Import new upstream version

[Bastian Germann]

Source: libssh
Version: 0.9.6-2
Severity: wishlist

Please update libssh to the latest 0.10.x version.
This has many added features including official OpenSSL 3 support.

Bug#1019259: devscripts: The command uscan with the option 'dehs' doesn't always generate valid XML ouput

[Daniel Ruiz de Alegria]

Package: devscripts
Version: 2.22.2
Severity: normal
X-Debbugs-Cc: danir...@offensive-security.com

Dear Maintainer,

I found an issue with the uscan command. The option '--dehs' is meant to 
generate only XML valid output but after the '' tag it adds some plain 
text lines that aren't escaped. For example, if the package URL contains the 
character '&' (which should be escaped as '&'), when parsing the XML output 
it will result in an error.

Here is an example using the Kali repository for burpsuite package:
https://gitlab.com/kalilinux/packages/burpsuite/-/blob/kali/master/debian/watch
```
$ uscan --watchfile burpsuite/debian/watch --package burpsuite 
--upstream-version 2022.1 --dehs

uscan: Newest version of burpsuite on remote site is 2022.8.4, local version is 
2022.1
uscan:  => Newer package available from:
=> 
https://portswigger.net/burp/releases/startdownload?product=community&version=2022.8.4&type=jar
burpsuite
2022.1
2022.1
2022.8.4
https://portswigger.net/burp/releases/startdownload?product=community&version=2022.8.4&type=jar
newer package available

```

You can see that the string inside the tag upstream-url is properly escaped, 
but the one in the third line isn't

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

Kernel: Linux 5.10.0-10-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 /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#789401: pbuilder: chroot's /tmp accessible to users when bootstrapping

[Akbarkhon Variskhanov]

Is this really an issue considering that /tmp and a bunch of other
directories are usually world-writable?

Coupled with the fact that .deb packages are just .ar archives, which
preserve permissions of their members. After `debootstrap` begins its
execution, APT unpacks packages in the chroot, with permissions and
layout of the directories preserved.

Bug#1006818: eye: (autopkgtest) failure on non-amd64

[Lev Lamberov]

Hi Jonas,

Сб 03 сен 2022 @ 21:19 Jonas Smedegaard :

>> The autopkgtest caught that the package is not functional on !amd64:
>> 
>> (buster_arm64-dchroot)bunk@amdahl:/tmp$ eye.pvm 
>> /usr/bin/eye.pvm: 3: exec: /usr/lib/swi-prolog/bin/x86_64-linux/swipl: not 
>> found
>> (buster_arm64-dchroot)bunk@amdahl:/tmp$ 
>> 
>> Changing Architecture: from "all" to "any" might be a reasonable option.
>
> In my understanding, this is a bug in SWI Prolog, in that when
> generating a so-called "intermediate code file" it embeds an
> arch-specific path to the interpreter instead of the arch-independent
> symlink in PATH: /usr/bin/swipl
>
> @Lev: What do you think?  Is it possible to patch SWI Prolog to embed an
> architecture-agnostic path for executing intermediary files?

SWI-Prolog supports three different pre-compiled formats: qlf, boot.prc,
and user created states. The first two do not include paths to the
interpreter. Looks like eye relies on the third one. I've asked upstream
about the possibility to embed an arch-independent path to such user
created states and got the answer that sometimes it is not a good idea,
because these states may differ due to conditional compilation. I've
looked into eye and looks like it does not (at least curretly, or I was
not able to spot it) use conditional compilation on various
architectures. So, I think it is probably save to embed arch-independent
path to the interpreter. SWI-Prolog upstream pushed a commit to support
this feature, but one should enable it explicitely with a command-line
option when running swipl to generate pre-compiled file of this kind
(like, swipl -o myexe --emulator=/usr/bin/swipl -c mycode.pl). I will
add this patch to the swi-prolog in Debian in the near future (probably,
I will have some time for it on the coming weekend, also I plan to
finish packaging a new upstream stable release, 8.4.3, where Debian is
at 8.4.2 at this point). I'll let you know when you can experiment with
eye concerning this change.

Cheers!
Lev