Bug#820708: [Pkg-pascal-devel] Bug#820708: marked as done (autopkgtest if cge works with current libpng version)

[Paul Gevers]

Hi Abou,

On 18-12-2021 00:21, Debian Bug Tracking System wrote:
This is an old bug and CGE is known to work with libpng16 since 5.2-3 
thanks to Michalis patch.


But if you look at the title, we wanted to add an autopkgtest to catch 
the situation in the *future* that this would become a bug again. So 
yes, the original bug is closed, but I reused the bug number to add the 
autopkgtest [1].


I let it up to you to change your mind about closure of this bug.

Paul

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=820708;msg=50


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1001714: update 2

[detlev schmidtke]

After numerous installation attempts with a lot of trial and error, I
got it bootable, but unfortunately cannot say, what in particular let
the error message disappear 

Bug#992737: ITP: libtools-build-clojure -- a library for building artifacts

[Louis-Philippe Véronneau]

I've taken the liberty of packaging this lib and pushing to NEW:

https://salsa.debian.org/clojure-team/tools-build-clojure

-- 
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
  ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
  ⠈⠳⣄


OpenPGP_signature
Description: OpenPGP digital signature

Bug#984232: status

[Anton Gladky]

This bug is fixed. I followed the advice from Adrian and now the package
builds fine.

Regards

Anton

Am Sa., 18. Dez. 2021 um 01:39 Uhr schrieb Ryan Pavlik :
>
> The updated package just needs the copyright file updated and reviewed. If 
> you'd like a fix uploaded before I get a chance to do that (which is somewhat 
> intimidating, they swapped some bundled dependencies since the last packaged 
> version), please feel free to nmu. Alternately I'd happily accept an mr to 
> make the copyright file complete again.
>
> Ryan
>
> On Wed, Dec 15, 2021, 5:24 AM Adrian Bunk  wrote:
>>
>> On Mon, Nov 15, 2021 at 02:53:40PM -0600, Ryan Pavlik wrote:
>> > Upstream has fixed this, and I have a package with the latest upstream
>> > sources in progress, happy to accept help to put it over the edge.
>>
>> Any progress on this?
>>
>> If necessary, I could NMU with the minimal fix of adding
>>   export DEB_CXXFLAGS_MAINT_APPEND += -std=gnu++14
>> to debian/rules.
>>
>> > Ryan
>>
>> cu
>> Adrian
>>
> --
> debian-science-maintainers mailing list
> debian-science-maintain...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#1001876: ITP: mpv-mpris -- MPRIS plugin for mpv

[Paul Wise]

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

* Package name: mpv-mpris
  Version : 0.6
  Upstream Author : Ho-Yon Mak
* URL : https://github.com/hoyon/mpv-mpris
* License : MIT
  Programming Lang: C
  Description : MPRIS plugin for mpv

mpv lacks support for being controlled by keyboard multimedia buttons,
which GNOME/KDE etc usually transform into the MPRIS DBus protocol.
This plugin adds support for MPRIS to mpv.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#1001875: gammy: Adapt Gammy so that a user can control color temperature, control brightness, and avoid eye damage.

[Randal South]

Package: gammy
Version: v0.9.64
Severity: normal

Dear Maintainer,

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

   * What led up to the situation? Eye irritation
   * What exactly did you do (or not do) that was effective (or
 ineffective)? Tried Redshift, but it didn't work well, and couldn't
 control color temperature in fine degrees.  It was unusable.
   * What was the outcome of this action?  Way too red
   * What outcome did you expect instead?  I expected a method of
   * controlling the color temperature and brightness in fine degrees.




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

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

Bug#1000233: php-remctl lost its phpapi-20190902 dependency

[Russ Allbery]

Control: reassign -1 dh-php
Control: severity -1 important
Control: affects -1 + php-remctl
Control: affects -1 + kopanocore
Control: affects -1 + libguestfs
Control: affects -1 + libvirt-php
Control: affects -1 + mapserver
Control: affects -1 + php-excimer
Control: affects -1 + php-facedetect
Control: affects -1 + php-horde-lz4
Control: affects -1 + php-luasandbox
Control: affects -1 + php-wmerrors
Control: affects -1 + php-sass
Control: affects -1 + php-tideways
Control: affects -1 + php-wikidiff2
Control: affects -1 + php-zeroc-ice

Replaying the control commands from the below message because it looks
like they didn't take for some reason (maybe because there was a Control:
line with no command at the start of the message).

Ondřej Surý  writes:

> Hi Russ,

> I am reassigning this bug to dh-php as I need to figure out what to
> do with non-PECL extensions in the long run. The dh-php might
> need some compatibility layer to support packages that bundle PHP
> with something else.

> I rewrote dh-php >= 4 to generate phpX.Y- out of the template
> and there are couple more loose ends that needs either fix in the
> package or in the dh-php.

> The whole perl + shell + makefile has also lot of duct tape included.
> I’ll either fix this directly in dh-php or provide the affected packages
> with a patch.

> 1. I don’t think missing dependency on PHP is a serious bug, it doesn’t
> prevent usage of the extension, it just doesn’t pull the interpreter in.

-- 
Russ Allbery (r...@debian.org)  

Bug#1001874: ITP: rime-stroke -- Rime Input Method Engine schema data - Stroke

[Boyuan Yang]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name: rime-stroke
  Version : 0.0~git20191221.ea8576d-1
  Upstream Author : Gong Chen 
* URL : https://github.com/rime/rime-stroke
* License : LGPL-3.0
  Programming Lang: N/A
  Description : Rime Input Method Engine schema data - Stroke

 RIME is the acronym of Rime Input Method Engine.
 .
 RIME is a lightweight, extensible input method engine supporting various
input
 schemas including glyph-based input methods, romanization-based input methods
 as well as those for Chinese dialects. It has the ability to compose phrases
 and sentences intelligently and provide very accurate traditional Chinese
 output. RIME's cross-platform core library is written in C++, and can work
 consistently on different platforms with OS-specific wrappers.
 .
 This package provides the stroke schema data of RIME.

This package will be part of the effort to migrate from
https://tracker.debian.org/pkg/brise to https://github.com/rime/plum by
splitting individual data packages and maintaining them individually. The new
binary package rime-data-stroke will replace old librime-data-stroke provided
by src:brise.

I plan to maintain this package under Debian Input Method Team:
https://salsa.debian.org/input-method-team/rime-stroke .

Thanks,
Boyuan Yang


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

Bug#1001873: editorconfig-core: reproducible-builds: BuildId differences triggered by RPATH

[Vagrant Cascadian]

Source: editorconfig-core
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: buildpath
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

The RPATH contains the build path resulting in different buildid:

  
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/editorconfig-core.html

The attached patch to debian/rules passes
-DCMAKE_BUILD_RPATH_USE_ORIGIN=ON via a dh_auto_configure override,
which should use a relative path for RPATH.

With this patch applied, editorconfig-core should build reproducibly on
tests.reproducible-builds.org!

Thanks for maintaining editorconfig-core!

live well,
  vagrant
From 45881cf6fc60ce321c15c5c15f9c6a57b3c443c1 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Sat, 18 Dec 2021 01:42:39 +
Subject: [PATCH] debian/rules: Pass -DCMAKE_BUILD_RPATH_USE_ORIGIN=ON via
 dh_auto_configure override.

This avoids embedding the full path in RPATH, which triggers BuildId
differences.

https://tests.reproducible-builds.org/debian/issues/unstable/cmake_rpath_contains_build_path_issue.html
---
 debian/rules | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/rules b/debian/rules
index bd993c5..9c80c50 100755
--- a/debian/rules
+++ b/debian/rules
@@ -12,7 +12,7 @@ export DPKG_GENSYMBOLS_CHECK_LEVEL=$(if $(EXP_RELEASE),0,1)
 	dh $@ --buildsystem=cmake --builddir=build --with pkgkde_symbolshelper
 
 override_dh_auto_configure:
-	dh_auto_configure -- -DINSTALL_HTML_DOC=ON
+	dh_auto_configure -- -DINSTALL_HTML_DOC=ON -DCMAKE_BUILD_RPATH_USE_ORIGIN=ON
 
 execute_after_dh_shlibdeps:
 	d-devlibdeps \
-- 
2.34.1



signature.asc
Description: PGP signature

Bug#1001869: libpodofo: reproducible-builds: BuildId differences triggered by RPATH

[Vagrant Cascadian]

On 2021-12-18, Mattia Rizzolo wrote:
> Thank you for the patch, that I can surely apply, but I wonder if you had a
> chance to have a look at the mass archive rebuild we had that applied this
> flag to everything.

That was a related but different flag, CMAKE_SKIP_RPATH=ON, and the
rebuild tests just tested weather they FTBFS, not the reproducibility
status.

  http://qa-logs.debian.net/2021/10/25/dcsr/
  http://qa-logs.debian.net/2021/10/25/res.dcsr.txt

That shows ~1k failures ... which is neither small nor huge.

In my limited experience, either can be used to make a package
reproducible, though I have a vague memory that possibly
CMAKE_BUILD_RPATH_USE_ORIGIN=ON might be less likely to cause FTBFS,
though I can't recall the details...


> Just so to avoid spreading more boilerplate around...

Yeah, I happen to have hit numerous packages today which become fully
reproducible with CMAKE_BUILD_RPATH_USE_ORIGIN=ON passed to
configure... just the luck of the packages I saw today!

To avoid boilerplate, switching to debhelper 14 would fix them (which
passes both CMAKE_SKIP_RPATH=ON and CMAKE_BUILD_RPATH_USE_ORIGIN=ON)
... but debhelper 14 is currently experiemental which involves a
different set of hoops to jump through to enable it.


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1001849: Acknowledgement (bullseye-pu: package glewlwyd/2.5.2-2+deb11u1)

[Nicolas Mora]

See attached debdiff
diff -Nru glewlwyd-2.5.2/debian/changelog glewlwyd-2.5.2/debian/changelog
--- glewlwyd-2.5.2/debian/changelog 2021-09-22 08:42:59.0 -0400
+++ glewlwyd-2.5.2/debian/changelog 2021-12-17 07:51:46.0 -0500
@@ -1,3 +1,9 @@
+glewlwyd (2.5.2-2+deb11u2) bullseye; urgency=medium
+
+  * d/patches: Fix possible privilege escalation (Closes: #1001849)
+
+ -- Nicolas Mora   Fri, 17 Dec 2021 07:51:46 -0500
+
 glewlwyd (2.5.2-2+deb11u1) bullseye; urgency=medium
 
   * d/patches: Fix CVE-2021-40818
diff -Nru glewlwyd-2.5.2/debian/patches/auth.patch 
glewlwyd-2.5.2/debian/patches/auth.patch
--- glewlwyd-2.5.2/debian/patches/auth.patch1969-12-31 19:00:00.0 
-0500
+++ glewlwyd-2.5.2/debian/patches/auth.patch2021-12-17 07:51:46.0 
-0500
@@ -0,0 +1,16 @@
+Description: Fix escalation privilege
+Author: Nicolas Mora 
+Forwarded: not-needed
+--- a/src/webservice.c
 b/src/webservice.c
+@@ -259,10 +259,6 @@
+ if (check_result_value(j_result, G_ERROR_UNAUTHORIZED)) {
+   y_log_message(Y_LOG_LEVEL_WARNING, "Security - Authorization 
invalid for username %s at IP Address %s", 
json_string_value(json_object_get(j_param, "username")), ip_source);
+ }
+-if ((session_uid = get_session_id(config, request)) != NULL && 
user_session_update(config, session_uid, u_map_get_case(request->map_header, 
"user-agent"), issued_for, json_string_value(json_object_get(j_param, 
"username")), NULL, 1) != G_OK) {
+-  y_log_message(Y_LOG_LEVEL_ERROR, "callback_glewlwyd_user_auth - 
Error user_session_update (2)");
+-}
+-o_free(session_uid);
+ response->status = 401;
+   }
+   json_decref(j_result);
diff -Nru glewlwyd-2.5.2/debian/patches/series 
glewlwyd-2.5.2/debian/patches/series
--- glewlwyd-2.5.2/debian/patches/series2021-09-22 08:42:59.0 
-0400
+++ glewlwyd-2.5.2/debian/patches/series2021-12-17 07:51:46.0 
-0500
@@ -1,2 +1,3 @@
 #webpack.patch
 webauthn.patch
+auth.patch

Bug#1001871: celluloid frequently fails to start

[Ryan Armstrong]

Package: celluloid
Version: 0.20-2
Severity: important

Dear Maintainer,

I have noticed that Celluloid frequently fails to start on my machine.
Some days the program works cleanly, other days it crashes every time 
I open it. Today is the latter. Here is the output:


(io.github.celluloid_player.Celluloid:5760): GLib-CRITICAL **: 18:27:42.715: 
g_variant_new_object_path: assertion 'g_variant_is_object_path (object_path)' 
failed

(io.github.celluloid_player.Celluloid:5760): GLib-CRITICAL **: 18:27:42.715: 
g_variant_new_variant: assertion 'value != NULL' failed

(io.github.celluloid_player.Celluloid:5760): GLib-CRITICAL **: 18:27:42.715: 
g_variant_get_type: assertion 'value != NULL' failed

(io.github.celluloid_player.Celluloid:5760): GLib-CRITICAL **: 18:27:42.715: 
g_variant_type_is_subtype_of: assertion 'g_variant_type_check (type)' failed

(io.github.celluloid_player.Celluloid:5760): GLib-CRITICAL **: 18:27:42.715: 
g_variant_builder_add_value: assertion '!GVSB(builder)->expected_type || 
g_variant_is_of_type (value, GVSB(builder)->expected_type)' failed

(io.github.celluloid_player.Celluloid:5760): GLib-CRITICAL **: 18:27:42.715: 
g_variant_builder_end: assertion 'GVSB(builder)->offset >= 
GVSB(builder)->min_items' failed

(io.github.celluloid_player.Celluloid:5760): GLib-CRITICAL **: 18:27:42.715: 
g_variant_get_type: assertion 'value != NULL' failed

(io.github.celluloid_player.Celluloid:5760): GLib-CRITICAL **: 18:27:42.715: 
g_variant_type_is_subtype_of: assertion 'g_variant_type_check (type)' failed

(io.github.celluloid_player.Celluloid:5760): GLib-CRITICAL **: 18:27:42.715: 
g_variant_builder_add_value: assertion '!GVSB(builder)->expected_type || 
g_variant_is_of_type (value, GVSB(builder)->expected_type)' failed
**
GLib-GIO:ERROR:../../../gio/gdbusconnection.c:4300:invoke_get_property_in_idle_cb:
 assertion failed: (error != NULL)
Bail out! 
GLib-GIO:ERROR:../../../gio/gdbusconnection.c:4300:invoke_get_property_in_idle_cb:
 assertion failed: (error != NULL)


I have looked at bug #970484, but the reported errors seem completely
different from that bug.

Here's the backtrace after I rebuilt to get a bunch of debug symbols:

(gdb) bt
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:49
#1  0x76aee536 in __GI_abort () at abort.c:79
#2  0x7716eddc in g_assertion_message (domain=, 
file=, line=, func=, 
message=) at ../../../glib/gtestutils.c:3223
#3  0x771ce0bb in g_assertion_message_expr
(domain=domain@entry=0x77431b78 "GLib-GIO", 
file=file@entry=0x77458fb8 "../../../gio/gdbusconnection.c", 
line=line@entry=4300, func=func@entry=0x7745b010 <__func__.54> 
"invoke_get_property_in_idle_cb", expr=expr@entry=0x7745ea96 "error != 
NULL") at ../../../glib/gtestutils.c:3249
#4  0x773ef926 in invoke_get_property_in_idle_cb (_data=0x7fffbc01def0) 
at ../../../gio/gdbusconnection.c:4300
#5  0x771a4be4 in g_main_dispatch (context=0x55610240) at 
../../../glib/gmain.c:3381
#6  g_main_context_dispatch (context=0x55610240) at 
../../../glib/gmain.c:4099
#7  0x771a4f88 in g_main_context_iterate 
(context=context@entry=0x55610240, block=block@entry=1, 
dispatch=dispatch@entry=1, self=) at ../../../glib/gmain.c:4175
#8  0x771a503f in g_main_context_iteration 
(context=context@entry=0x55610240, may_block=may_block@entry=1) at 
../../../glib/gmain.c:4240
#9  0x773c306d in g_application_run (application=0x5560b1b0 
[CelluloidApplication], argc=argc@entry=1, argv=argv@entry=0x7fffdd68) at 
../../../gio/gapplication.c:2569
#10 0x55566bfd in main (argc=1, argv=0x7fffdd68) at 
./src/celluloid-main.c:36

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

Kernel: Linux 5.15.0-2-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_CRAP
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en_US
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages celluloid depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.40.0-2
ii  libc62.32-5
ii  libcairo21.16.0-5
ii  libepoxy01.5.9-2
ii  libglib2.0-0 2.70.2-1
ii  libgtk-3-0   3.24.30-4
ii  libmpv1  0.34.0-2
ii  libpango-1.0-0   1.48.10+ds1-1
ii  libpangocairo-1.0-0  1.48.10+ds1-1

Versions of packages celluloid recommends:
ii  youtube-dl  2021.06.06-1

celluloid suggests no packages.

-- no debconf information

Bug#1001872: eiskaltdcpp: reproducible-builds: BuildId differences triggered by RPATH

[Vagrant Cascadian]

Source: eiskaltdcpp
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: buildpath
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

The RPATH contains the build path resulting in different buildid:

  
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/eiskaltdcpp.html

The attached patch to debian/rules passes
-DCMAKE_BUILD_RPATH_USE_ORIGIN=ON via the CMAKEOPTS variable.  used in
the dh_auto_configure override, which should use a relative path for
RPATH.

With this patch applied, eiskaltdcpp should build reproducibly on
tests.reproducible-builds.org!

Thanks for maintaining eiskaltdcpp!

live well,
  vagrant
From 0f23fcf76636824aae2490c29699e64f711a60b7 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Sat, 18 Dec 2021 01:00:06 +
Subject: [PATCH] debian/rules: Pass -DCMAKE_BUILD_RPATH_USE_ORIGIN=ON via
 CMAKEOPTS variable.

This avoids embedding the full path in RPATH, which triggers BuildId
differences.

https://tests.reproducible-builds.org/debian/issues/unstable/cmake_rpath_contains_build_path_issue.html
---
 debian/rules | 1 +
 1 file changed, 1 insertion(+)

diff --git a/debian/rules b/debian/rules
index 0f24cd4..23dfd4b 100755
--- a/debian/rules
+++ b/debian/rules
@@ -30,6 +30,7 @@ CMAKEOPTS = -DUSE_ASPELL=ON \
 -DXMLRPC_DAEMON=OFF \
 -DJSONRPC_DAEMON=ON \
 -DCHECK_GTK_DEPRECATED=OFF \
+-DCMAKE_BUILD_RPATH_USE_ORIGIN=ON \
 -DREPLACE_VERSION="$(DEB_VERSION_UPSTREAM)"
 
 EXCLUDE_FILES = usr/share/eiskaltdcpp/emoticons/*/READ_ME.txt \
-- 
2.34.1



signature.asc
Description: PGP signature

Bug#984232: status

[Ryan Pavlik]

The updated package just needs the copyright file updated and reviewed. If
you'd like a fix uploaded before I get a chance to do that (which is
somewhat intimidating, they swapped some bundled dependencies since the
last packaged version), please feel free to nmu. Alternately I'd happily
accept an mr to make the copyright file complete again.

Ryan

On Wed, Dec 15, 2021, 5:24 AM Adrian Bunk  wrote:

> On Mon, Nov 15, 2021 at 02:53:40PM -0600, Ryan Pavlik wrote:
> > Upstream has fixed this, and I have a package with the latest upstream
> > sources in progress, happy to accept help to put it over the edge.
>
> Any progress on this?
>
> If necessary, I could NMU with the minimal fix of adding
>   export DEB_CXXFLAGS_MAINT_APPEND += -std=gnu++14
> to debian/rules.
>
> > Ryan
>
> cu
> Adrian
>
>

Bug#999061: libimage-metadata-jpeg-perl: diff for NMU version 0.153-1.2

[gregor herrmann]

Control: tags 999061 + patch
Control: tags 999061 + pending


Dear maintainer,

I've prepared an NMU for libimage-metadata-jpeg-perl (versioned as 0.153-1.2) 
and
uploaded it to DELAYED/5. Please feel free to tell me if I
should delay it longer.

Regards.


-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   NP: Flying Pickets: Wonderful World
diff -u libimage-metadata-jpeg-perl-0.153/debian/changelog libimage-metadata-jpeg-perl-0.153/debian/changelog
--- libimage-metadata-jpeg-perl-0.153/debian/changelog
+++ libimage-metadata-jpeg-perl-0.153/debian/changelog
@@ -1,3 +1,12 @@
+libimage-metadata-jpeg-perl (0.153-1.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix "missing required debian/rules targets build-arch and/or build-
+indep": add missing targets to debian/rules.
+(Closes: #999061)
+
+ -- gregor herrmann   Sat, 18 Dec 2021 01:27:53 +0100
+
 libimage-metadata-jpeg-perl (0.153-1.1) unstable; urgency=medium
 
   * Non maintainer upload by the Reproducible Builds team.
diff -u libimage-metadata-jpeg-perl-0.153/debian/rules libimage-metadata-jpeg-perl-0.153/debian/rules
--- libimage-metadata-jpeg-perl-0.153/debian/rules
+++ libimage-metadata-jpeg-perl-0.153/debian/rules
@@ -28,7 +28,7 @@
 	touch configure-stamp
 
 
-build: build-stamp
+build-indep: build-stamp
 
 build-stamp: configure-stamp 
 	dh_testdir
@@ -46,6 +46,11 @@
 
 	touch $@
 
+# Nothing to do
+build-arch:
+
+build: build-indep
+
 clean:
 	dh_testdir
 	dh_testroot
@@ -109,4 +114,4 @@
 # We have nothing to do by default.
 
 binary: binary-indep binary-arch
-.PHONY: build clean binary-indep binary-arch binary install configure
+.PHONY: build-indep build-arch build clean binary-indep binary-arch binary install configure


signature.asc
Description: Digital Signature

Bug#1001870: meshlab: reproducible-builds: BuildId differences triggered by RPATH

[Ryan Pavlik]

Oh wow, thanks! I was trying to figure out why it wasn't reproducible even
though it "should have" been. I'll apply this soon.

On Fri, Dec 17, 2021, 6:09 PM Vagrant Cascadian <
vagr...@reproducible-builds.org> wrote:

> Source: meshlab
> Severity: normal
> Tags: patch
> User: reproducible-bui...@lists.alioth.debian.org
> Usertags: buildpath
> X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org
>
> The RPATH contains the build path resulting in different buildid:
>
>
> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/meshlab.html
>
> The attached patch to debian/rules passes
> -DCMAKE_BUILD_RPATH_USE_ORIGIN=ON via a dh_auto_configure override,
> which should use a relative path for RPATH.
>
> With this patch applied, meshlab should build reproducibly on
> tests.reproducible-builds.org!
>
> Thanks for maintaining meshlab!
>
> live well,
>   vagrant
>

Bug#932594: Handle /usr/bin/egrep etc

[Richard Lewis]

On Wed, 15 Dec 2021 21:29:35 +1300 Andrew Ruthven  wrote:

> I have just spent a little bit of time digging into this, as I want
> rkhunter to work (almost) turnkey, without needing users to have to
> customise any configuration files.

I'm just a fellow user here - when i started using this package a some
years ago i thought a turnkey approach would be good, but over time i
have come to take a different view.

Scanning packages like rkhunter (and chkrootkit, checksecurity, tiger,
etc, etc) cant realistically cope with every possible debian system,
and i dont think they should try.

I think there is more benefit from being told that things have changed
from some baseline (expected position), even if the baseline itself
needs adjusting. And that  it should not be debian's goal, in my
opinion, to eliminate warnings caused by debian packages (other than
those from essential:yes packages) as long as the warnings can be
silenced - rkhunter does pretty well here.

if grep moves from /usr/bin to /bin or the other way, i want to be
told, not have the scanner adjust itself.  If a new lwp-release script
appears i want to be told - even if the explanation is "because that
package got installed" (this does assume there is a reason to check if
lwp-release is a script - im not actually sure this is true given the
automatic updates are now disabled, but that's another story)

(i appreciate that it is entirely reasonable to disagree with this, I
just wanted to share my view)

(personally, i would leave usrmerge the default and close this bug as
you can already edit the rkhunter.conf to say where grep is located)

Bug#1001708: segfault when attempting SEPA transfer (works in debian 11, but broken in unstable)

[Martin Preuss]

Hi,

only tarballs of AqBanking6.4.0 are affected, previous and next versions are 
not.


Regards
Martin


Am 17.12.21 um 11:01 schrieb Micha Lenk:
> Control: fixed -1 libaqbanking/6.4.1-1
> 
> Am 16.12.21 um 22:40 schrieb Harald Welte:
>> On Thu, Dec 16, 2021 at 01:48:11PM +0100, Micha Lenk wrote:
>>> Would you mind to give these versions another try, once they become
>>> available?
>>
>> confirmed fixed in current packages on 'unstable', thanks.
> 
> Thanks for the confirmation.
> 
> For whether 'stable' is affected as well (thanks to the hint of the relevant 
> commit) I'll leave this bug open and have a look later.
> 
> Regards,
> Micha
> 


-- 
"Things are only impossible until they're not."

Bug#1001870: meshlab: reproducible-builds: BuildId differences triggered by RPATH

[Vagrant Cascadian]

Source: meshlab
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: buildpath
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

The RPATH contains the build path resulting in different buildid:

  
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/meshlab.html

The attached patch to debian/rules passes
-DCMAKE_BUILD_RPATH_USE_ORIGIN=ON via a dh_auto_configure override,
which should use a relative path for RPATH.

With this patch applied, meshlab should build reproducibly on
tests.reproducible-builds.org!

Thanks for maintaining meshlab!

live well,
  vagrant
From e6d836f045f54a4626cbcd3691c2eeb6f7254fec Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Fri, 17 Dec 2021 23:59:39 +
Subject: [PATCH] debian/rules: Pass -DCMAKE_BUILD_RPATH_USE_ORIGIN=ON via
 dh_auto_configure override.

This avoids embedding the full path in RPATH, which triggers BuildId
differences.

https://tests.reproducible-builds.org/debian/issues/unstable/cmake_rpath_contains_build_path_issue.html
---
 debian/rules | 1 +
 1 file changed, 1 insertion(+)

diff --git a/debian/rules b/debian/rules
index 8a7e79be..280884de 100755
--- a/debian/rules
+++ b/debian/rules
@@ -33,6 +33,7 @@ override_dh_auto_configure:
 	 -DALLOW_BUNDLED_OPENCTM=OFF \
 	 -DALLOW_BUNDLED_QHULL=OFF \
 	 -DALLOW_BUNDLED_XERCES=OFF \
+	 -DCMAKE_BUILD_RPATH_USE_ORIGIN=ON \
 
 # Make plugins only "recommends"
 override_dh_shlibdeps:
-- 
2.34.1



signature.asc
Description: PGP signature

Bug#1001869: libpodofo: reproducible-builds: BuildId differences triggered by RPATH

[Mattia Rizzolo]

Hi Vagrant,

Thank you for the patch, that I can surely apply, but I wonder if you had a
chance to have a look at the mass archive rebuild we had that applied this
flag to everything.

Just so to avoid spreading more boilerplate around...

On Sat, 18 Dec 2021, 12:48 am Vagrant Cascadian, <
vagr...@reproducible-builds.org> wrote:

> Source: libpodofo
> Severity: normal
> Tags: patch
> User: reproducible-bui...@lists.alioth.debian.org
> Usertags: buildpath
> X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org
>
> The RPATH contains the build path resulting in different buildid:
>
>
> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/libpodofo.html
>
> The attached patch to debian/rules passes
> -DCMAKE_BUILD_RPATH_USE_ORIGIN=ON via a dh_auto_configure override,
> which should use a relative path for RPATH.
>
> With this patch applied, libpodofo should build reproducibly on
> tests.reproducible-builds.org!
>
> Thanks for maintaining libpodofo!
>
> live well,
>   vagrant
>

Bug#1001869: libpodofo: reproducible-builds: BuildId differences triggered by RPATH

[Vagrant Cascadian]

Source: libpodofo
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: buildpath
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

The RPATH contains the build path resulting in different buildid:

  
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/libpodofo.html

The attached patch to debian/rules passes
-DCMAKE_BUILD_RPATH_USE_ORIGIN=ON via a dh_auto_configure override,
which should use a relative path for RPATH.

With this patch applied, libpodofo should build reproducibly on
tests.reproducible-builds.org!

Thanks for maintaining libpodofo!

live well,
  vagrant
From d0e8d3c6ba6214395035453eb799e30bba77a9c7 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Fri, 17 Dec 2021 23:42:10 +
Subject: [PATCH] debian/rules: Pass -DCMAKE_BUILD_RPATH_USE_ORIGIN=ON via
 dh_auto_configure override.

This avoids embedding the full path in RPATH, which triggers BuildId
differences.

https://tests.reproducible-builds.org/debian/issues/unstable/cmake_rpath_contains_build_path_issue.html
---
 debian/rules | 1 +
 1 file changed, 1 insertion(+)

diff --git a/debian/rules b/debian/rules
index edb1e68..8b0a437 100755
--- a/debian/rules
+++ b/debian/rules
@@ -13,6 +13,7 @@ override_dh_auto_configure:
 	-DPODOFO_BUILD_SHARED:BOOL=TRUE \
 	-DPODOFO_BUILD_STATIC:BOOL=FALSE \
 	-DPODOFO_USE_VISIBILITY:BOOL=TRUE \
+	-DCMAKE_BUILD_RPATH_USE_ORIGIN=ON \
 
 override_dh_compress:
 	dh_compress -X .pdf -X .plan
-- 
2.34.1



signature.asc
Description: PGP signature

Bug#1001868: fcitx: reproducible-builds: BuildId differences triggered by RPATH

[Vagrant Cascadian]

Source: fcitx
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: buildpath
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

The RPATH contains the build path resulting in different buildid:

  https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/fcitx.html

The attached patch to debian/rules passes
-DCMAKE_BUILD_RPATH_USE_ORIGIN=ON via a dh_auto_configure override,
which should use a relative path for RPATH.

With this patch applied, fcitx should build reproducibly on
tests.reproducible-builds.org!

Thanks for maintaining fcitx!

live well,
  vagrant
From b7515c1dc81e62af1c27d2f220dd314d441d25cc Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Fri, 17 Dec 2021 23:38:36 +
Subject: [PATCH] debian/rules: Pass -DCMAKE_BUILD_RPATH_USE_ORIGIN=ON via
 dh_auto_configure override.

This avoids embedding the full path in RPATH, which triggers BuildId
differences.

https://tests.reproducible-builds.org/debian/issues/unstable/cmake_rpath_contains_build_path_issue.html
---
 debian/rules | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/debian/rules b/debian/rules
index 3bb24a7..0a4866c 100755
--- a/debian/rules
+++ b/debian/rules
@@ -36,7 +36,8 @@ override_dh_auto_configure: gen_control
 	-DENABLE_ICU=ON \
 	-DENABLE_BACKTRACE=ON \
 	-DENABLE_XDGAUTOSTART=ON \
-	-DENABLE_GETTEXT=ON
+	-DENABLE_GETTEXT=ON \
+	-DCMAKE_BUILD_RPATH_USE_ORIGIN=ON
 
 override_dh_makeshlibs:
 	dh_makeshlibs -plibfcitx-core0
-- 
2.34.1



signature.asc
Description: PGP signature

Bug#1001865: transition: draco

[Sebastian Ramacher]

Control: tags -1 confirmed
Control: forwarded -1 
https://release.debian.org/transitions/html/auto-draco.html

On 2021-12-17 23:53:07 +0100, Timo Röhling wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> 
> Dear Release Team,
> 
> I would like to transition draco 1.5.0, which has a proper upstream SONAME
> again. I verified that the reverse dependencies, pdal and assimp, build
> successfully on amd64.

Please go ahead

Cheers

> 
> The autogenerated Ben tracker looks good:
> https://release.debian.org/transitions/html/auto-draco.html
> 
> Cheers
> Timo
> 
> 
> 

-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#1001867: fcitx5-gtk: reproducible-builds: BuildId differences triggered by RPATH

[Vagrant Cascadian]

Source: fcitx5-gtk
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: buildpath
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

The RPATH contains the build path resulting in different buildid:

  
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/fcitx5-gtk.html

The attached patch to debian/rules passes
-DCMAKE_BUILD_RPATH_USE_ORIGIN=ON via a dh_auto_configure override,
which should use a relative path for RPATH.

With this patch applied, fcitx5-gtk should build reproducibly on
tests.reproducible-builds.org!

Thanks for maintaining fcitx5-gtk!

live well,
  vagrant
From b0412e90df4332d991a4113ad1e7294558784276 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Fri, 17 Dec 2021 23:12:50 +
Subject: [PATCH] debian/rules: Pass -DCMAKE_BUILD_RPATH_USE_ORIGIN=ON via
 dh_auto_configure override.

This avoids embedding the full path in RPATH, which triggers BuildId
differences.

https://tests.reproducible-builds.org/debian/issues/unstable/cmake_rpath_contains_build_path_issue.html
---
 debian/rules | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/debian/rules b/debian/rules
index 3028422..29a7e2d 100755
--- a/debian/rules
+++ b/debian/rules
@@ -4,3 +4,6 @@ export DEB_BUILD_MAINT_OPTIONS = hardening=+all
 
 %:
 	dh $@ --with gir
+
+override_dh_auto_configure:
+	dh_auto_configure -- -DCMAKE_BUILD_RPATH_USE_ORIGIN=ON
-- 
2.34.1



signature.asc
Description: PGP signature

Bug#1001785: texlive-extra affected by log4j CVEs

[Hilmar Preuße]

Am 16.12.2021 um 09:38 teilte Sven Mueller mit:

Hi,


texlive-extra-utils contains arara (https://github.com/islandoftex/arara)
which was updated two days ago via TeX Live (https://www.tug.org/texlive/)
which was updated slightly after that. Please update to the newest TeX Live
ASAP, as arara in unstable and testing (also stable?) currently bundles a
vulnerable apache-log4j2 version.

For unstable / testing I'll simply push a new CTAN snapshot to the 
archive. Should not be that hard.


I did not check stable yet, but I'm pretty sure it is affected too. I'd 
put the jar file in question on the blacklist and hence remove it from 
the package. Would this be OK?


Did you check oldstable yet?

Hilmar
--
sigfault



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1001866: libime: reproducible-builds: BuildId differences triggered by RPATH

[Vagrant Cascadian]

Source: libime
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: buildpath
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

The RPATH contains the build path resulting in different buildid:

  https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/libime.html

The attached patch to debian/rules passes
-DCMAKE_BUILD_RPATH_USE_ORIGIN=ON via a dh_auto_configure override,
which should use a relative path for RPATH.

With this patch applied, libime should build reproducibly on
tests.reproducible-builds.org!

Thanks for maintaining libime!

live well,
  vagrant
From edceee6388dec62cca657e4082fc038a6734b54f Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Fri, 17 Dec 2021 22:50:16 +
Subject: [PATCH] debian/rules: Pass -DCMAKE_BUILD_RPATH_USE_ORIGIN=ON via
 dh_auto_configure override.

This avoids embedding the full path in RPATH, which triggers BuildId
differences.

https://tests.reproducible-builds.org/debian/issues/unstable/cmake_rpath_contains_build_path_issue.html
---
 debian/rules | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/debian/rules b/debian/rules
index 388559a..d2a50f3 100755
--- a/debian/rules
+++ b/debian/rules
@@ -10,6 +10,9 @@ execute_before_dh_auto_configure:
 	rmdir src/libime/core/kenlm
 	ln -sf $(CURDIR)/kenlm $(CURDIR)/src/libime/core/kenlm
 
+override_dh_auto_configure:
+	dh_auto_configure -- -DCMAKE_BUILD_RPATH_USE_ORIGIN=ON
+
 ifneq (,$(filter $(DEB_HOST_ARCH), mips64el mipsel))
 override_dh_auto_test:
 	dh_auto_test -- ARGS+='--exclude-regex \(testtrie\)'
-- 
2.30.2



signature.asc
Description: PGP signature

Bug#1001865: transition: draco

[Timo Röhling]

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear Release Team,

I would like to transition draco 1.5.0, which has a proper upstream SONAME
again. I verified that the reverse dependencies, pdal and assimp, build
successfully on amd64.

The autogenerated Ben tracker looks good:
https://release.debian.org/transitions/html/auto-draco.html

Cheers
Timo


-BEGIN PGP SIGNATURE-

iQGzBAEBCgAdFiEEJvtDgpxjkjCIVtam+C8H+466LVkFAmG9FM8ACgkQ+C8H+466
LVlWxwwA8W/NOK4OI+pIvsAkAzTq1WtxJfIQ5bzP+Ixaf5gXMzRvivWzoJVr8Tsk
xbKVFok1zF+7pjcj2iQZSnjhJaLc8zK5cObCMfp7FeKqDdM4QWXc37JZF8QM8Iky
sylhVg2uSFpxnpBijnJ1qHqi11P2iWqg2Gqx7iwmetQUSm5tylGM5/KtP5vPXY9P
gST6LzsA+kdVFqpZLqmqQJ8cG+FGKTGT1joxNSe1QMcThUXa3IU5DFu7LMtA5NTA
BNpzDJ+PiEn7e6S6FsXTRo5Rv7qzJX6/8DTq2nIHlfbAM1/YXUagHlVPaKBOTGK+
c3HiAgES+LVSMFsn7cF+mKB6KkxT+v/K25gCA9S3ubUzMwmtWIwCFwzrCi9NyOzV
5gpAGd3uHa+vL2KoOq0O572VMxWO8jyy8NC6QhVQ6GK0WIE2J63HwGK2eTcw09xr
NCM05PRYzdG6hf95AWumQ5qjF+TdcvYrF02xzGo00VACm9uy0DLQVUDhrmf0/CaK
CxyVTf4s
=sxgs
-END PGP SIGNATURE-

Bug#1001858: sudo.prerm will not allow replacement with sudo-ldap if no root password

[Marc Haber]

On Fri, Dec 17, 2021 at 11:17:28PM +0100, Dennis Filder wrote:
> On Fri, Dec 17, 2021 at 09:49:01PM +0100, Marc Haber wrote:
> > sudo.prerm will error out unconditionally if there is no root password
> > set. This breaks the replacement of sudo with sudo-ldap in autopkgtest
> > environments and makes ugly workarounds necessary. How would we make
> > this better?
> 
> I don't see the issue here.  That was put in there for a very good
> reason: to not bork the system if something goes wrong during the
> replacement.  A system without a root password set is a very
> unorthodox use case.

If you run the Debian installer with default settings, you get a system
without root password. I guess the majority of desktop installations run
that way.

> Running autopkgtest with --env=SUDO_FORCE_REMOVE=yes should make this
> work.

As far as I know, you generally cannot control the environment in all
autopkgtest instances.

> Of course, it would be nicer if the format for d/tests/control
> offered something like Extra-Environment: to specify (a file with
> definitions of) additional environment variables for a set of tests.

Yes.

Greetings
Marc

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

Bug#718883: Both IndexErrors still occur in 1.71-8

[Jens Rottmann]

Tested with 1.71-8: latest package still affected by _both_ IndexError 
instances.

Bug#1001810: dbconfig-pgsql: add support for LC_COLLATE and LC_CTYPE

[Jörg Steffens]

On 17.12.21 at 21:21 wrote Paul Gevers:
> Control: tags -1 moreinfo pending
> 
> Hi Jörg,
> 
> Thanks.
> 
> On 16-12-2021 19:27, Jörg Steffens wrote:
>>
>> PostgreSQL "CREATE DATABASE" support parameter.
>> While setting the ENCODING is already implemented with dbconfig, setting
>> LC_COLLATE and LC_CTYPE is not.
> 
> Are there other parameters possible? Should they not be supported?

New versions of potgresql may add parameter, but for postgresql-10 they are:

CREATE DATABASE name
[ [ WITH ] [ OWNER [=] user_name ]
   [ TEMPLATE [=] template ]
   [ ENCODING [=] encoding ]
   [ LC_COLLATE [=] lc_collate ]
   [ LC_CTYPE [=] lc_ctype ]
   [ TABLESPACE [=] tablespace_name ]
   [ ALLOW_CONNECTIONS [=] allowconn ]
   [ CONNECTION LIMIT [=] connlimit ]
   [ IS_TEMPLATE [=] istemplate ] ]

See: https://www.postgresql.org/docs/10/sql-createdatabase.html

I'm not an expert on this. The Bareos project just uses the 2 additional
parameter LC_COLLATE and LC_CTYPE.

ENCODING can already be given as parameter
and "template0" is used as template. To specify encoding, "template0"
must be used, see
https://www.postgresql.org/docs/10/manage-ag-templatedbs.html, so that
is fine.

While these parameter must be given when creating the database,
the remaining parameter can be changed afterwards with ALTER DATABASE,
see https://www.postgresql.org/docs/10/sql-alterdatabase.html

So from my point of view, adding this 2 parameter is fine.
I considered having a parameter like dbc_pgsql_createdb_extraparamter.
But then the package maintainer using dbconfig must know what version of
Postgresql is installed, is this is dangerous.


> I have locally committed your patch but like to see an answer to the
> question above.

I hope, this answers your questions.

Regards,
Jörg

-- 
 Jörg Steffens   joerg.steff...@bareos.com
 Bareos GmbH & Co. KGPhone: +49 221 630693-91
 http://www.bareos.com   Fax:   +49 221 630693-10

 Sitz der Gesellschaft: Köln | Amtsgericht Köln: HRA 29646
 Komplementär: Bareos Verwaltungs-GmbH
 Geschäftsführer:
 S. Dühr, M. Außendorf, Jörg Steffens, P. Storz



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1001824: xml2rfc: Incompatible with current weaseyprint

[Scott Kitterman]

On Thu, 16 Dec 2021 23:28:26 -0500 Scott Kitterman  
wrote:
> Package: xml2rfc
> Version: 3.12.0-1
> Severity: serious
> Tags: ftbfs upstream patch
> Justification: fails to build from source
> 
> Note: Using ftbfs because that's the closest thing we have to an
> autopkgtest failure.
> 
> The new version of weasyprint no longer uses the same PDF generation
> libraries and as a result, xml2rfc's detection mechanism for if it is
> capable of making a PDF is not working (see attached patch).
> 
> Once the detection mechanism is patched, PDF generation works fine,
> which leads me to believe the test failure is bogus:
> 
> ==
> FAIL: test_text_content (__main__.PdfWriterTests)
> --
> Traceback (most recent call last):
>   File "/home/xml2rfc-3.12.0/test.py", line 510, in test_text_content
> self.assertIn(t, text)
> AssertionError: 'RFC' not found in 'l- WN –&,ÛžÆ TNDQ&·sX l-%Zñ¢<³ WN P½RÔ
> n®>Ø %˜oh l† .µ ¬( .µ=N'
> 
> --
> 
> If things were really that garbled, I don't see how it could make a PDF.
> 
> Reported upstream:
> 
> https://trac.ietf.org/trac/xml2rfc/ticket/696
> 
> In the interim, I think it might make sense to apply the attached patch
> and get rid of the failing test.  If we go down this path, then this
> will also need fixing (get rid of HAVE_CAIRO and HAVE_PANGO):
> 
> xml2rfc-3.12.0/test.py", line 513, in test_included_fonts
> 
> if xml2rfc.HAVE_WEASYPRINT and xml2rfc.HAVE_PYCAIRO and
> xml2rfc.HAVE_CAIRO and xml2rfc.HAVE_PANGO:

dkg,

Unless you want to object, I think we should go ahead and make this change.  I 
don't get the impression that since the IETF LLC booted Henrik there's much 
upstream going on, so I don't see much point in waiting for them.

Scott K

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

Bug#1001858: sudo.prerm will not allow replacement with sudo-ldap if no root password

[Dennis Filder]

On Fri, Dec 17, 2021 at 09:49:01PM +0100, Marc Haber wrote:
> sudo.prerm will error out unconditionally if there is no root password
> set. This breaks the replacement of sudo with sudo-ldap in autopkgtest
> environments and makes ugly workarounds necessary. How would we make
> this better?

I don't see the issue here.  That was put in there for a very good
reason: to not bork the system if something goes wrong during the
replacement.  A system without a root password set is a very
unorthodox use case.

Running autopkgtest with --env=SUDO_FORCE_REMOVE=yes should make this
work.  Of course, it would be nicer if the format for d/tests/control
offered something like Extra-Environment: to specify (a file with
definitions of) additional environment variables for a set of tests.

Since there is apparently no good way either to safely determine with
authority if you're running under an autopkgtest I think this is not
sudo's problem to solve, but that of autopkgtest.

Regards.

Bug#1001710: multipath-tools: booting with lvm over multipath it does not setup devices for lvm

[BARROS FERNANDEZ, Carlos]

Hello Ritesh.

Thanks for your answer.

Tried serveral things to make it work, but only a filter in lvm.conf did work. 
(the pv's were created under multipath, and also did several vgcfgbackup, the 
pv's did not have any /dev/sd?? written in their sectors)
The filter that I put is:

filter = [ "a|/dev/mapper/|", "r|/block/|", "r|/disk/|", "r|/sd[b-z].*|", 
"a|.*|" ]

I had to put sd[b-z].* because the system in installed in lvm too, so I had to 
exclude that device. Maybe there is a better filter, but I do not know how to 
write it.

The server uses a RAID controller for internal disks and hba for the external 
disks

Right now, it seems stable between reboots, I hope that the raid controller 
will always setup before the hba, otherwise the filter won't work.

I think that this info can be of help to other users, could you put a 
README.debian including this filter? (or modify the lvm.conf to add the note)
Like:
To setup LVM over multipath, and allow other LVM over a non multpathed device, 
if you encounter that the pv-devices are not under
multipath control, try this filter line in lvm.conf, update-initrd and reboot. 
to check it that it works ok.


 filter = [ "a|/dev/mapper/|", "r|/block/|", "r|/disk/|", 
"r|/sd[b-z].*|", "a|.*|" ]

  sd[b-z].* makes all /dev/sd* be skipped but /dev/sda.
Adjust for your hardware configuration.

With this info the bug can be closed.

Regards.

--

Carlos Barros.

On mié, 2021-12-15 at 20:00 +0530, Ritesh Raj Sarraf wrote:
Hello Carlos,

On Tue, 2021-12-14 at 19:04 +0100, Carlos Barros wrote:
A server was setup with some disks configured in multipath.
The root filesystem is on LVM on internal disk, not configured for
multipath.

Then build another lvm configuration on those devices
(/dev/mapper/...)

Now, every time it starts, lvm takes the /dev/sd.. before multipath
sets /dev/mapper/...  up.


This combination of the setup, where you have Multipath + LVM, is a
known working config.

There are some special tweaks needed though. I don't recollect the
exact specifics but basically there might be 2 things.

1. You need to ensure that you run pvcreate on top of the multipathed
devices and NOT on the bare SCSI devices.

2. THere's also a filter in /etc/lvm/ where you define the list of SCSI
devices that should be blacklisted from LVM.

Also, the booting proccess delays for 2+  minutes, mostly because of
systemd-udev-settle.service:
root@panblando:~# systemd-analyze blame
 2min 22ms systemd-udev-settle.service
1min 105ms NetworkManager-wait-online.service
9.983s smartmontools.service
4.415s dev-mapper-dl380g8\x2d\x2dvg\x2droot.device

But this service is called from multipath:
[Unit]
Description=Device-Mapper Multipath Device Controller
Wants=systemd-udev-trigger.service systemd-udev-
settle.service
Before=iscsi.service iscsid.service lvm2-activation-
early.service
Before=local-fs-pre.target blk-availability.service
After=multipathd.socket systemd-udev-trigger.service systemd-
udev-settle.service
DefaultDependencies=no
Conflicts=shutdown.target
ConditionKernelCommandLine=!nompath
ConditionKernelCommandLine=!multipath=off

According to systemd-udev-settle.service(8) it is not recommended, as
that service can fail (in fact,
in the server it fails as systemd says)


I don't recollect the specifics but iirc that service is required for a
reason. Remember that, typically, multipath-tools is used in
combination with SAN devices which are remote.

I think that the problem is related to multipath, because it did not
setup the devices before lvm,
and maybe the problem is inside the initrd.


Please explore the suggestions I mentioned above. I am fairly sure that
it may just be a case of proper blacklisting.

Then I did install multipath-tools-boot but the problem is the same.
The only way is to avoid mounting the filesystems in the LVM (or
umounting them) vgchange -an VG
and do the multipath and mount it, all by hand

Yes. THis is expected behavior. mutliapth can only acquire the device
when it is free.




INFORMACIÓN BÁSICA SOBRE PROTECCIÓN DE DATOS CONFORME EL NUEVO REGLAMENTO 
EUROPEO (RGPD)

RESPONSABLE: Grupo Econocom en España (Econocom SA, Econocom Servicios S.A., 
Econocom Products & Solutions S.A.U.) sitas en Cardenal Marcelo Spínola, 4, 
28016 Madrid
FINALIDAD PRINCIPAL: Mantener relaciones profesionales y/o comerciales con la 
empresa en la que usted trabaja o de la que es representante.
LEGITIMACIÓN: Consentimiento del interesado.
DESTINATARIOS: No se cederán datos a terceros, salvo autorización expresa u 
obligación legal.
DERECHOS: Acceder, rectificar y suprimir los datos, portabilidad de los datos, 
limitación u oposición a su tratamiento, transparencia y derecho a no ser 
objeto de decisiones automatizadas.
INFORMACIÓN ADICIONAL: Puede consultar la información adicional y detallada 
sobre nuestra política de 

Bug#1001863: adduser: EXCLUDE_FSTYPES not respected with --remove-all-files

[Adam Dinwoodie]

Package: adduser
Version: 3.118
Severity: normal

Dear Maintainer,

When deleting a user with `--remove-all-files`, I have seen the script
take an inordinately long time, and investigating with `lsof` I found it
was descending into rclone mounts, despite having disable this in the
deluser.conf file, because I had expected traversing those mounts to be
both pointless and slow.

Looking at the perl script, it looks like the set of mounts to descend
or not descend into is built as `@mountpoints`, and a bit of
print-debugging indicated that these mounts weren't being added to the
array, as expected.  However, it looks like `@mountpoints` is only
actually referenced in the block for `sub home_match`; it's not used in
`sub find_match`, which is the one that's invoked when removing all
files rather than just home directories.

At least by my reading of deluser.conf, this isn't expected, and the
`EXCLUDE_FSTYPES` configuration should affect both runs with
`--remove-home` and `--remove-all-files`.

-- System Information:
Distributor ID: Raspbian
Description:Raspbian GNU/Linux 11 (bullseye)
Release:11
Codename:   bullseye
Architecture: armv7l

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

Versions of packages adduser depends on:
ii  debconf [debconf-2.0]  1.5.77
ii  passwd 1:4.8.1-1

adduser recommends no packages.

Versions of packages adduser suggests:
ii  liblocale-gettext-perl  1.07-4+b1
ii  perl5.32.1-4+deb11u2

-- Configuration Files:
/etc/deluser.conf changed:
REMOVE_HOME = 0
REMOVE_ALL_FILES = 0
BACKUP = 0
BACKUP_TO = "."
ONLY_IF_EMPTY = 0
EXCLUDE_FSTYPES = "(proc|sysfs|usbfs|devpts|tmpfs|afs|fuse.rclone)"


-- debconf information:
* adduser/homedir-permission: true
  adduser/title:

Bug#1001804: Image preview not available in wordpress

[Craig Small]

On Fri, 17 Dec 2021 at 18:59, Katharina Drexel 
wrote:

> I have configured the WP_CONTENT_DIR variable, in wp-config.php as well as
> in
> config-.php. Nevertheless I can reproduce the problem:
> Deleting symlink: no image preview
> Adding symlink: image preview working

That sounds like something else is the problem, possibly a plugin. Some
plugins are badly written and don't use the functions to get the correct
directory but assume a directory layout.

I run an AppArmor profile over WordPress which doesn't allow it to write to
anything under /usr. I'm not getting any hits on that so it's not even
trying.

The trick now is to work out why it's fine here, but not elsewhere. When
you say preview, what exactly is that?  Is it all the small images you see
in the media library? Are the images uploaded into the /var directory but
just not visible? That would point to an apache configuration problem.

 - Craig

Bug#881571: gnumeric doesn't scale row-height correctly on imported spreadsheets

[Wookey]

Source: gnumeric
Version: 1.12.48-1+b2
Followup-For: Bug #881571

I'm seeing the 'wrong row-height' issue on all my spreadsheets, not
just ones imported from calc and excel.

In a newly-created sheet the font-size is about twice the row-height,
just as in the badly-displayed sheets.  If I type something into a
cell the characters overhang the next row and then when one hits enter
the row is resized to fit the just-entered font-size.

Clearly the issue wth the 'characters too big for the rows' is related
- the default font-szie is much begger than the default
row-size. (looks like about twice as big)

This may well be related to the fact that I have a HiDPI display here
(3840x2160) so various things have had to be tweaked to make charcters
and screen elements be sensible sizes. 

I tried changing GDK_SCALE=1 instead of 2, but that just produce
exactly the same effect (fonts twice as tall as rows) with the overall
window 1/4 the area.

Not sure what to fiddle with next.

But this is a serious problem making gnumeric kind of useless for
exaisting sheets unless one wants to resize the fonts in every cell

--
Wookey

Bug#1001862: mbedtls: Enable MBEDTLS_SSL_DTLS_SRTP

[Dennis Filder]

Source: mbedtls
Severity: wishlist

mbedtls 2.28 came out today and is the new LTS release.  Of its new
features I need support for DTLS SRTP (option MBEDTLS_SSL_DTLS_SRTP)
for Linphone, so please ensure to enable it.

Thanks in advance.

P.S.: libmbedtls-doc contains Doxygen .map files, so please adjust
override_dh_installdocs to exclude them, too.

Bug#1001788: neovim: undoing changes results in a mix of old and new text

[James McCoy]

On Thu, Dec 16, 2021 at 10:28:18AM +0100, Nicolas Évrard wrote:
> I am sorry for this bug report because it occurs on some rare occurence and I
> don't have a scenario to reproduce it. Yet it's annoying enough to deserve a
> bug report. Feel free to close it as unreproduceable ;).
> 
> With the arrival of LSP I switched my configuration from ALE to the builtin 
> LSP
> for linting and so on. I made this switch some days after the release of 
> neovim
> 0.5.0 ; since that time I have remarked that sometimes (I'd say 2 or 3 times a
> month), when I undo my changes (not just one press of 'u' multiple presses), 
> it
> results in a mix of old and new changes.

There were a number of fixes in the LSP stuff for 0.6.0, so can you let
me know if you see this again after upgrading to that?

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

Bug#1001861: golang-github-evanw-esbuild: Please build node-esbuild

[Yadd]

Source: golang-github-evanw-esbuild
Version: 0.13.12-1
Severity: wishlist
Tags: patch
Forwarded: 
https://salsa.debian.org/go-team/packages/golang-github-evanw-esbuild/-/merge_requests/1

Hi,

I prepared an MR to build also nodejs files. I tested it with next
ts-jest, it works like a charm ;-).

Cheers,
Yadd

Bug#1001860: xeus-python: reproducible-builds: BuildId differences triggered by RPATH

[Vagrant Cascadian]

Source: xeus-python
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: buildpath
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

The RPATH contains the build path resulting in different buildid:

  
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/xeus-python.html

The attached patch to debian/rules passes
-DCMAKE_BUILD_RPATH_USE_ORIGIN=ON via a dh_auto_configure override,
which should use a relative path for RPATH.

With this patch applied, xeus-python should build reproducibly on
tests.reproducible-builds.org!

Thanks for maintaining xeus-python!

live well,
  vagrant
From 6337525afe21b35a771952eb55ad95a69b82bd27 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Fri, 17 Dec 2021 21:08:39 +
Subject: [PATCH] debian/rules: Pass -DCMAKE_BUILD_RPATH_USE_ORIGIN=ON via
 dh_auto_configure override.

This avoids embedding the full path in RPATH, which triggers BuildId
differences.

https://tests.reproducible-builds.org/debian/issues/unstable/build_id_differences_only_issue.html
---
 debian/rules | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/rules b/debian/rules
index ad51db3..ebc2952 100755
--- a/debian/rules
+++ b/debian/rules
@@ -6,4 +6,4 @@ include /usr/share/dpkg/architecture.mk
 	dh $@
 
 override_dh_auto_configure:
-	dh_auto_configure -- -DPYTHON_EXECUTABLE=/usr/bin/python3 -DXPYT_DISABLE_ARCH_NATIVE=1 -DXPYT_DISABLE_TUNE_GENERIC=1
+	dh_auto_configure -- -DPYTHON_EXECUTABLE=/usr/bin/python3 -DXPYT_DISABLE_ARCH_NATIVE=1 -DXPYT_DISABLE_TUNE_GENERIC=1 -DCMAKE_BUILD_RPATH_USE_ORIGIN=ON
-- 
2.30.2



signature.asc
Description: PGP signature

Bug#1001859: kjs: reproducible-builds: BuildId differences triggered by RPATH

[Vagrant Cascadian]

Source: kjs
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: buildpath
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

The RPATH contains the build path resulting in different buildid:

  https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/kjs.html

The attached patch to debian/rules passes
-DCMAKE_BUILD_RPATH_USE_ORIGIN=ON via a dh_auto_configure override,
which should use a relative path for RPATH.

With this patch applied, kjs should build reproducibly on
tests.reproducible-builds.org!

Thanks for maintaining kjs!

live well,
  vagrant
From 86b7e4850e032f4340aa6ed1d750888ecb6f4a87 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Fri, 17 Dec 2021 20:47:11 +
Subject: [PATCH] debian/rules: Pass -DCMAKE_BUILD_RPATH_USE_ORIGIN=ON via
 dh_auto_configure override.

This avoids embedding the full path in RPATH, which triggers BuildId
differences.

https://tests.reproducible-builds.org/debian/issues/unstable/build_id_differences_only_issue.html
---
 debian/rules | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/debian/rules b/debian/rules
index b808d0e..be94f40 100755
--- a/debian/rules
+++ b/debian/rules
@@ -9,3 +9,6 @@ export DEB_BUILD_MAINT_OPTIONS = hardening=+all
 override_dh_fixperms:
 	chmod +x debian/libkf5kjs-dev/usr/share/kf5/kjs/create_hash_table
 	dh_fixperms
+
+override_dh_auto_configure:
+	dh_auto_configure -- -DCMAKE_BUILD_RPATH_USE_ORIGIN=ON
-- 
2.34.1



signature.asc
Description: PGP signature

Bug#978949: dh-python: pybuild build system detection not consistent

[stefanor]

Hi Gianfranco (2021.01.01_11:10:53_+)
> I think, when certainity is around 50% the package should just error
> out and the user should manually specify the needed build system, this
> might fix all this uncertainity.

I wouldn't trust the certainty numbers enough to do that, I think it
would cause many packages to suddenly FTBFS.

What could make sense is to fail unless one plugin's certainty is
significantly more than all the others. But again, that'd need some
testing.

What I've done for now is to just make the detection consistent.

SR

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  +1 415 683 3272

Bug#1001858: sudo.prerm will not allow replacement with sudo-ldap if no root password

[Marc Haber]

Package: sudo
Version: 1.9.8p2-1~exp1
Severity: minor

Hi,

sudo.prerm will error out unconditionally if there is no root password
set. This breaks the replacement of sudo with sudo-ldap in autopkgtest
environments and makes ugly workarounds necessary. How would we make
this better?

Greetings
Marc

Bug#1001857: autopkgtest: running autopkgtest-build-lxc while testing may fail the test

[Paul Gevers]

Package: autopkgtest
Version: 5.19
Severity: normal

Hi,

I was just running a test during which I noticed my container was
old. So I started to recreate it with autopkgtest-build-lxc in
parallel (like we do on our infrastructure). I was surprised to
noticed that this seems to fail my running test:

autopkgtest [21:28:22]: test check-all-pages-with-mariadb: preparing testbed
: failure: lxc-copy with exit status 124
autopkgtest [21:33:42]: ERROR: testbed failure: cannot send to testbed: [Errno 
32] Broken pipe

Paul

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

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

Versions of packages autopkgtest depends on:
ii  apt-utils   2.3.13
ii  libdpkg-perl1.21.1
ii  procps  2:3.3.17-5
ii  python3 3.9.7-1
ii  python3-debian  0.1.42

Versions of packages autopkgtest recommends:
ii  autodep8  0.25

Versions of packages autopkgtest suggests:
pn  fakemachine   
ii  lxc   1:4.0.10-1
pn  lxd   
ii  ovmf  2021.11-1
pn  ovmf-ia32 
pn  qemu-efi-aarch64  
pn  qemu-efi-arm  
pn  qemu-system   
ii  qemu-utils1:6.1+dfsg-8+b2
pn  schroot   
ii  vmdb2 0.24-1

-- no debconf information

Bug#1001856: gr-satellites: reproducible-builds: BuildId differences triggered by RPATH

[Vagrant Cascadian]

Source: gr-satellites
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: buildpath
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

The RPATH contains the build path resulting in different buildid:

  
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/gr-satellites.html

The attached patch to debian/rules passes
-DCMAKE_BUILD_RPATH_USE_ORIGIN=ON via a dh_auto_configure override,
which should use a relative path for RPATH.

With this patch applied, gr-satellites should build reproducibly on
tests.reproducible-builds.org!

Thanks for maintaining gr-satellites!

live well,
  vagrant
From 086234ad24c56999829454f441fca85b97fd5904 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Fri, 17 Dec 2021 20:35:10 +
Subject: [PATCH] debian/rules: Pass -DCMAKE_BUILD_RPATH_USE_ORIGIN=ON via
 dh_auto_configure override.

This avoids embedding the full path in RPATH, which triggers BuildId
differences.

https://tests.reproducible-builds.org/debian/issues/unstable/build_id_differences_only_issue.html
---
 debian/rules | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/debian/rules b/debian/rules
index 5b4abec..d382b3d 100755
--- a/debian/rules
+++ b/debian/rules
@@ -2,3 +2,6 @@
 
 %:
 	dh $@ --with python3 --with numpy3
+
+override_dh_auto_configure:
+	dh_auto_configure -- -DCMAKE_BUILD_RPATH_USE_ORIGIN=ON
-- 
2.34.1



signature.asc
Description: PGP signature

Bug#1001855: eslint breaks node-domino autopkgtest: Cannot find module 'js-yaml'

[Paul Gevers]

Source: eslint, node-domino
Control: found -1 eslint/5.16.0~dfsg+~4.16.8-9
Control: found -1 node-domino/2.1.6~ds-1
Severity: serious
Tags: sid bookworm
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: breaks needs-update

Dear maintainer(s),

With a recent upload of eslint the autopkgtest of node-domino fails in 
testing when that autopkgtest is run with the binary packages of eslint 
from unstable. It passes when run with only packages from testing. In 
tabular form:


   passfail
eslint from testing5.16.0~dfsg+~4.16.8-9
node-dominofrom testing2.1.6~ds-1
all others from testingfrom testing

I copied some of the output at the bottom of this report. Is this 
pointing at a missing (test) dependency somewhere?


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


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

Paul

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

https://ci.debian.net/data/autopkgtest/testing/amd64/n/node-domino/17644607/log.gz

There was a problem loading formatter: ./formatters/tap
Error: Cannot find module 'js-yaml'
Require stack:
- /usr/share/nodejs/eslint/lib/formatters/tap.js
- /usr/share/nodejs/eslint/lib/cli-engine.js
- /usr/share/nodejs/eslint/lib/cli.js
- /usr/share/nodejs/eslint/bin/eslint.js
autopkgtest [12:10:53]: test command2



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1001810: dbconfig-pgsql: add support for LC_COLLATE and LC_CTYPE

[Paul Gevers]

Control: tags -1 moreinfo pending

Hi Jörg,

Thanks.

On 16-12-2021 19:27, Jörg Steffens wrote:


PostgreSQL "CREATE DATABASE" support parameter.
While setting the ENCODING is already implemented with dbconfig, setting
LC_COLLATE and LC_CTYPE is not.


Are there other parameters possible? Should they not be supported?

I have locally committed your patch but like to see an answer to the 
question above.


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1001854: freediameter: reproducible-builds: BuildId differences triggered by RPATH

[Vagrant Cascadian]

Source: freediameter
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: buildpath
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

The RPATH contains the build path resulting in different buildid:

  
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/freediameter.html

The attached patch to debian/rules passes
-DCMAKE_BUILD_RPATH_USE_ORIGIN=ON via a dh_auto_configure override,
which should use a relative path for RPATH.

With this patch applied, freediameter should build reproducibly on
tests.reproducible-builds.org!

Thanks for maintaining freediameter!

live well,
  vagrant
From dfee701c99223408da7779ea71a066b1139e0f7a Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Fri, 17 Dec 2021 20:18:46 +
Subject: [PATCH] debian/rules: Pass -DCMAKE_BUILD_RPATH_USE_ORIGIN=ON via
 dh_auto_configure override.

This avoids embedding the full path in RPATH, which triggers BuildId
differences.

https://tests.reproducible-builds.org/debian/issues/unstable/build_id_differences_only_issue.html
---
 debian/rules | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/rules b/debian/rules
index 541f9fc..d036869 100755
--- a/debian/rules
+++ b/debian/rules
@@ -19,7 +19,7 @@ arch = $(shell dpkg-architecture -qDEB_BUILD_ARCH)
 	dh $@
 
 override_dh_auto_configure:
-	dh_auto_configure -- -DLIB_INSTALL_DIR=lib/$(DEB_HOST_MULTIARCH)
+	dh_auto_configure -- -DLIB_INSTALL_DIR=lib/$(DEB_HOST_MULTIARCH) -DCMAKE_BUILD_RPATH_USE_ORIGIN=ON
 
 override_dh_strip:
 	dh_strip
-- 
2.30.2



signature.asc
Description: PGP signature

Bug#999777: marked as done (6.3-1 breaks scrolling in neovim on gnome-terminal with vertical splits)

[Sven Joachim]

Control: reopen -1

On 2021-12-17 19:06 +, Debian Bug Tracking System wrote:

>  neovim (0.6.0-1) unstable; urgency=medium
>  .
>* New upstream release
>  - Ignore sgmrp/sgmlp terminfo attributes for non-xterm compatible
>terminals which advertise TERM=xterm  (Closes: #999777)

I am afraid you closed the wrong bug here, as #999777 is still assigned
to ncurses-base, while the clone #999871 belongs to neovim.

Therefore I am reopening this bug, will close #999871 in a minute.

Cheers,
   Sven

Bug#1001850: Re: userbindmount: reproducible-builds: BuildId differences triggered by RPATH

[Vagrant Cascadian]

On 2021-12-17, Vagrant Cascadian wrote:
> The RPATH contains the build path resulting in different buildid:
>
>   
> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/userbindmount.html
>
> The attached patch to debian/rules passes -DCMAKE_SKIP_RPATH=ON via a
> dh_auto_configure override, which should remove the RPATH.

Actually, I think this patch is a little better, rather than stripping
the RPATH entirely, it uses a relative path value for RPATH by passing
CMAKE_BUILD_RPATH_USE_ORIGIN instead of CMAKE_SKIP_RPATH.

Either patch should work for reproducible builds, though.

Thanks!

live well,
  vagrant
From 0f6ae01660591007bcd9ca199aca23c2b3cad2c1 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Fri, 17 Dec 2021 19:59:47 +
Subject: [PATCH] debian/rules: Pass -DCMAKE_BUILD_RPATH_USE_ORIGIN=ON via
 dh_auto_configure override.

This avoids embedding the full path in RPATH, which triggers BuildId
differences.

https://tests.reproducible-builds.org/debian/issues/unstable/build_id_differences_only_issue.html
---
 debian/rules | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/debian/rules b/debian/rules
index a856ca4..f0974c6 100755
--- a/debian/rules
+++ b/debian/rules
@@ -3,3 +3,6 @@
 export DEB_BUILD_MAINT_OPTIONS = hardening=+all
 %:
 	dh $@ --buildsystem=cmake
+
+override_dh_auto_configure:
+	dh_auto_configure -- -DCMAKE_BUILD_RPATH_USE_ORIGIN=ON
-- 
2.34.1



signature.asc
Description: PGP signature

Bug#1001853: nanomsg: reproducible-builds: BuildId differences triggered by RPATH

[Vagrant Cascadian]

Source: nanomsg
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: buildpath
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

The RPATH contains the build path resulting in different buildid:

  
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/nanomsg.html

The attached patch to debian/rules passes
-DCMAKE_BUILD_RPATH_USE_ORIGIN=ON via a dh_auto_configure override,
which should use a relative path for RPATH.

With this patch applied, nanomsg should build reproducibly on
tests.reproducible-builds.org!


Thanks for maintaining nanomsg!


live well,
  vagrant
From 0f6ae01660591007bcd9ca199aca23c2b3cad2c1 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Fri, 17 Dec 2021 19:59:47 +
Subject: [PATCH] debian/rules: Pass -DCMAKE_BUILD_RPATH_USE_ORIGIN=ON via
 dh_auto_configure override.

This avoids embedding the full path in RPATH, which triggers BuildId
differences.

https://tests.reproducible-builds.org/debian/issues/unstable/build_id_differences_only_issue.html
---
 debian/rules | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/debian/rules b/debian/rules
index a856ca4..f0974c6 100755
--- a/debian/rules
+++ b/debian/rules
@@ -3,3 +3,6 @@
 export DEB_BUILD_MAINT_OPTIONS = hardening=+all
 %:
 	dh $@ --buildsystem=cmake
+
+override_dh_auto_configure:
+	dh_auto_configure -- -DCMAKE_BUILD_RPATH_USE_ORIGIN=ON
-- 
2.34.1



signature.asc
Description: PGP signature

Bug#718883: Another way to trigger IndexError on LEVEL.map[][], same file, different code line

[Jens Rottmann]

A very similar bug, resulting in a crash, can be triggered by Nyx firing her 
crossbow. Even in the very first level, if unlucky, no additional equipment 
neccessary. Here it's line 5325, but in the same file and same mode of failure: I 
assume arrow.y becomes negative, which the code fails to check for => likewise 
IndexError trying to access LEVEL.map[][].

Fri Dec 17 19:25:21 2021| Playlevel called: Castle Centre
Traceback (most recent call last):
  File "/usr/share/games/ardentryst/ardentryst.py", line 4722, in 
main()
  File "/usr/share/games/ardentryst/ardentryst.py", line 4423, in main
handle_game(Game, True)
  File "/usr/share/games/ardentryst/ardentryst.py", line 3083, in handle_game
Result = playlevel(player, level, [levelscript, npcscript], screen, Data, 
Fonts, soundbox, Game,
  File "/usr/share/games/ardentryst/play_level.py", line 2886, in playlevel
PLAYER.arrow_tick()
  File "/usr/share/games/ardentryst/play_level.py", line 5325, in arrow_tick
lm = LEVEL.map[int(arrow.x/40)][int(arrow.y/40)]
IndexError: list index out of range

Bug#1001851: sudo-ldap doesnt work if configured before ldap.conf exists

[Marc Haber]

Package: sudo-ldap
Version: 1.8.27-1
Severity: minor

Hi,

this applies to all sudo versions that I can get ahold of, and was
observed when creating autopkgtests. Sadly, I do not have a good idea
how to fix this at the moment.

Steps to reproduce:
- install sudo-ldap, slapd and ldap-utils in the same apt run
- configure ldap and sudo-ldap, fill directory with (test) data
- try using sudo
- see it failing
- dpkg-reconfigure sudo-ldap
- see sudo working

The issue is that sudo-ldap's postinst tries to symlink
/etc/ldap/ldap.conf to /etc/sudo-ldap.conf if /etc/ldap/ldap.conf
exists. If the LDAP software has just been installed,
/etc/ldap/ldap.conf doesn't exist yet, hence the symlink is not created,
hence non-working sudo. The reconfiguration finds /etc/ldap/ldap.conf,
creates the symlink, and everything is fine.

My only short-term idea is to create the symlink even if it is dangling
in the beginning. Without /etc/ldap/ldap.conf, sudo-ldap isn't working
either way. I don't particularly like that idea though.

Greetings
Marc

Bug#1001850: userbindmount: reproducible-builds: BuildId differences triggered by RPATH

[Vagrant Cascadian]

Source: userbindmount
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: buildpath
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

The RPATH contains the build path resulting in different buildid:

  
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/userbindmount.html

The attached patch to debian/rules passes -DCMAKE_SKIP_RPATH=ON via a
dh_auto_configure override, which should remove the RPATH.


With this patch applied, userbindmount should build reproducibly on
tests.reproducible-builds.org!


Thanks for maintaining userbindmount!


live well,
  vagrant
From 86ffe8d9c56f6f56c3b9036fac4c3ef74d100221 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Fri, 17 Dec 2021 19:28:52 +
Subject: [PATCH] debian/rules: Pass CMAKE_SKIP_RPATH=ON via dh_auto_configure
 override.

Without this, the build path triggers differences in the BuildId.

https://tests.reproducible-builds.org/debian/issues/unstable/build_id_differences_only_issue.html
---
 debian/rules | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/debian/rules b/debian/rules
index 0c696bd..5db920f 100755
--- a/debian/rules
+++ b/debian/rules
@@ -16,5 +16,8 @@ export DEB_LDFLAGS_MAINT_APPEND = -Wl,--as-needed
 %:
 	dh $@
 
+override_dh_auto_configure:
+	dh_auto_configure -- -DCMAKE_SKIP_RPATH=ON
+
 override_dh_auto_install:
 	dh_auto_install --destdir debian/tmp
-- 
2.34.1



signature.asc
Description: PGP signature

Bug#1001849: bullseye-pu: package glewlwyd/2.5.2-2+deb11u1

[Nicolas Mora]

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

[ Reason ]
A bug has been fixed in Glewlwyd 2.6.1 to avoid possible possible privilege
escalation

[ Impact ]
Users accounts might be compromised

[ Changes ]
Remove a misplaced session update in the source code

CVE request has been filed, await for response

Bug#905231: dh-python: generate dependency on python{,3}-pkg-resources ?

[Stefano Rivera]

Hi Andreas (2018.08.01_12:39:56_-0400)
> should dh_python{,3} generate a dependency on python{,3}-pkg-resources
> if needed?
> 
> There are a lot of packages in the archive using a construct like
> 
> $ cat /usr/bin/thonny
> #!/usr/bin/python3
> # EASY-INSTALL-ENTRY-SCRIPT: 'thonny==2.1.17','gui_scripts','thonny'
> __requires__ = 'thonny==2.1.17'
> import re
> import sys
> from pkg_resources import load_entry_point
> 
> if __name__ == '__main__':
> sys.argv[0] = re.sub(r'(-script\.pyw?|\.exe)?$', '', sys.argv[0])
> sys.exit(
> load_entry_point('thonny==2.1.17', 'gui_scripts', 'thonny')()
> )

Technically, packages using that should have specified setuptools as a
requirement, which we'd translate to pkg-resources, through our pydist
file. I agree, these were very common missing requirements.

However, these days setuptools uses importlib.metadata in entry points
(since setuptools 47.2, with Python 3.8), so maybe this is less of an
issue these days?  I'm leaning towards wontfix, given that.

SR

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  +1 415 683 3272

Bug#1001848: glewlwyd: Possible privilege escalation

[Nicolas Mora]

Package: glewlwyd
Version: 2.5.2-2+deb11u1
Severity: important
Tags: patch




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

Kernel: Linux 5.10.0-10-amd64 (SMP w/4 CPU threads)
Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.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 glewlwyd depends on:
ii  dbconfig-pgsql 2.0.19
ii  debconf [debconf-2.0]  1.5.77
pn  glewlwyd-common
ii  init-system-helpers1.60
ii  libc6  2.31-13+deb11u2
ii  libcbor0   0.5.0+dfsg-2
ii  libconfig9 1.5-0.4
ii  libcrypt1  1:4.4.18-4
ii  libgnutls303.7.1-5
pn  libhoel1.4 
pn  libiddawc0.9   
ii  libjansson42.13.1-1.1
ii  libldap-2.4-2  2.4.57+dfsg-3
ii  libnettle8 3.7.3-1
ii  liboath0   2.6.6-3
pn  liborcania2.1  
pn  librhonabwy0.9 
pn  libulfius2.7   
pn  libyder2.0 
ii  lsb-base   11.1.0
ii  sqlite33.34.1-3
ii  ucf3.0043
ii  zlib1g 1:1.2.11.dfsg-2

glewlwyd recommends no packages.

Versions of packages glewlwyd suggests:
Description: Fix escalation privilege
Author: Nicolas Mora 
Forwarded: not-needed
--- a/src/webservice.c
+++ b/src/webservice.c
@@ -259,10 +259,6 @@
 if (check_result_value(j_result, G_ERROR_UNAUTHORIZED)) {
   y_log_message(Y_LOG_LEVEL_WARNING, "Security - Authorization 
invalid for username %s at IP Address %s", 
json_string_value(json_object_get(j_param, "username")), ip_source);
 }
-if ((session_uid = get_session_id(config, request)) != NULL && 
user_session_update(config, session_uid, u_map_get_case(request->map_header, 
"user-agent"), issued_for, json_string_value(json_object_get(j_param, 
"username")), NULL, 1) != G_OK) {
-  y_log_message(Y_LOG_LEVEL_ERROR, "callback_glewlwyd_user_auth - 
Error user_session_update (2)");
-}
-o_free(session_uid);
 response->status = 401;
   }
   json_decref(j_result);

Bug#901095: patch

[GCS]

Hi Yuriy,

On Sun, Jul 22, 2018 at 9:33 PM Yuriy M. Kaminskiy  wrote:
> Attached debdiff should implement it (in a bit hackish way, but I much
> prefer to ship tcl script as tcl script over exactly same tcl script,
> but embedded in ELF executable).
 Thanks for your contribution. I'm going to split out all sqlite3
tools into a separate package.
I don't think sqlite3_analyzer would be good on its own. I'm not
entirely sure why it would be better as an unofficial Tcl script,
especially for the average user. Can you give me some pointers?

Thanks,
Laszlo/GCS

Bug#1001847: ITP: golang-github-charmbracelet-bubbletea -- powerful little TUI framework for Go

[Anthony Fok]

Package: wnpp
Severity: wishlist
Owner: Anthony Fok 

* Package name: golang-github-charmbracelet-bubbletea
  Version : 0.19.1-1
  Upstream Author : Charmbracelet, Inc.
* URL : https://github.com/charmbracelet/bubbletea
* License : Expat
  Programming Lang: Go
  Description : powerful little TUI framework for Go 

 Bubble Tea is the fun, functional and stateful way to build terminal apps.
 A Go framework based on The Elm Architecture.
 Bubble Tea is well-suited for simple and complex terminal applications,
 either inline, full-window, or a mix of both.
 .
 Bubble Tea is in use in production and includes a number of features and
 performance optimizations we’ve added along the way.  Among those is a
 standard framerate-based renderer, a renderer for high-performance
 scrollable regions which works alongside the main renderer, and mouse
 support.


Reason for packaging:
 Prerequisite for Glow @ github.com/charmbracelet/glow, etc.
TODO: perhaps reasoning

Bug#1000480: jtharness 6.0-b15-1~deb10u1 flagged for acceptance

[Adam D Barratt]

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

Hi,

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

Thanks for your contribution!

Upload details
==

Package: jtharness
Version: 6.0-b15-1~deb10u1

Explanation: new upstream version to support builds of newer OpenJDK-11 versions

Bug#1001845: Update

[in . cognito35]

There is actually a much simpler repro case:

Format volume, create large file, fsck volume, boink:

farblos@sappc2:~$ sudo mkfs.vfat -n MCBACKUP /dev/sdc1
mkfs.fat 4.2 (2021-01-31)
farblos@sappc2:~$ sudo mount /dev/sdc1 /mnt
farblos@sappc2:~$ sudo truncate -s 4294967295 /mnt/bigfile
farblos@sappc2:~$ sudo umount /mnt
farblos@sappc2:~$ sudo fsck.vfat /dev/sdc1
fsck.fat 4.2 (2021-01-31)
/bigfile
  File size is 4294967295 bytes, cluster chain length is 0 bytes.
  Truncating file to 0 bytes.

*** Filesystem was changed ***
The changes have not yet been written, you can still choose to leave the
filesystem unmodified:
1) Write changes
2) Leave filesystem unchanged
[12?q]? 2
/dev/sdc1: 2 files, 1048577/1961982 clusters

Bug#996165: firmware-sof-signed: sound/mic also does not work on Dell Precision 5760

[Vincent Bernat]

 ❦ 17 December 2021 17:55 +01, Dirk Kostrewa:

> I have also tried before the 5.14 kernel from the Bullseye backports
> repository (with firmware-sof-signed 1.7.1), which also didn't work. I 
> would be grateful for any other suggestion!

No idea. You should try to ask upstream: https://github.com/thesofproject/sof
-- 
Make input easy to prepare and output self-explanatory.
- The Elements of Programming Style (Kernighan & Plauger)

Bug#999279: swish-e: diff for NMU version 2.4.7-6.1

[Damyan Ivanov]

-=| Ludovic Drolez, 17.12.2021 16:20:53 +0100 |=-
> On Thu, Dec 16, 2021 at 07:56:50AM +, Damyan Ivanov wrote:
> > I've prepared an NMU for swish-e (versioned as 2.4.7-6.1) and
> > uploaded it to DELAYED/7. Please feel free to tell me if I
> > should delay it longer.
> > 
> 
> That's perfect, thanks for your help!

Glad to be of service. Upload rescheduled to DELAYED/0 and should 
enter the archive within a day.

Cheers!
dam

Bug#1001845: dosfstools: After a dirty unplug, fsck.vfat truncates 4GiB files to zero

[farblos]

Package: dosfstools
Version: 4.2-1
Severity: important
X-Debbugs-Cc: in.cognit...@arcor.de

Dear Maintainer,

   * What led up to the situation?

Had some troubles with an USB hub, during which a USB flash drive was
powered off without being unmounted cleanly.  During my following
fsck run, fsck.vfat "offered" to truncate files of size (4GiB - 1) to
zero bytes.  And does so, if let to.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

After hitting the issue twice with a "production" flash drive, I tried
to reproduce the issue on a different flash drive with the following steps:

  # Ensure Gnome's (or whatever) auto-mounting is off to have
  # better control over mount operations.

  farblos@sappc2:~$ sudo mkfs.vfat -n "MCBACKUP" /dev/sda1
  mkfs.fat 4.2 (2021-01-31)
  farblos@sappc2:~$ udisksctl mount --block-device /dev/sda1
  Mounted /dev/sda1 at /media/farblos/MCBACKUP

  # Populate the flash drive with small files, just to have some
  # contents (optional).  Finally, create the one big file:

  farblos@sappc2:~$ mkdir /media/farblos/MCBACKUP/documents
  farblos@sappc2:~$ truncate -s 4294967295 
/media/farblos/MCBACKUP/documents/data00.vol
  farblos@sappc2:~$ ls -al /media/farblos/MCBACKUP/documents/data00.vol
  -rw-r--r-- 1 farblos farblos 4294967295 Dec 17 17:28 
/media/farblos/MCBACKUP/documents/data00.vol

  farblos@sappc2:~$ udisksctl umount --block-device /dev/sda1
  Unmounted /dev/sda1.
  farblos@sappc2:~$ udisksctl mount --block-device /dev/sda1
  Mounted /dev/sda1 at /media/farblos/MCBACKUP

  # Unplug flash drive without further accessing the volume and
  # without unmounting, plug it again.  Start fsck on the volume.

   * What was the outcome of this action?

fsck.vfat insists on not only fixing the dirty bit, but also the large file,
which I have neither read nor written after mounting the flash drive the
second time.  Confirmed by hitting this issue at least three times with
different flash drives.  Here is the output of the fsck run:

  farblos@sappc2:~$ sudo fsck /dev/disk/by-label/MCBACKUP 
  [sudo] password for farblos: 
  fsck from util-linux 2.36.1
  fsck.fat 4.2 (2021-01-31)
  There are differences between boot sector and its backup.
  This is mostly harmless. Differences: (offset:original/backup)
65:01/00
  1) Copy original to backup
  2) Copy backup to original
  3) No action
  [123?q]? 2
  /documents/data00.vol
File size is 4294967295 bytes, cluster chain length is 0 bytes.
Truncating file to 0 bytes.

  *** Filesystem was changed ***
  The changes have not yet been written, you can still choose to leave the
  filesystem unmodified:
  1) Write changes
  2) Leave filesystem unchanged
  [12?q]? 2
  /dev/sda1: 19 files, 1053288/1961982 clusters

   * What outcome did you expect instead?

fsck.vfat should fix only the dirty bit and leave any large files alone.

No current issues found, not in upstream Github repo, either.  Google
seems to find some similar issues, but they are all older than 10 years.

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

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

Versions of packages dosfstools depends on:
ii  libc6  2.31-13+deb11u2

dosfstools recommends no packages.

dosfstools suggests no packages.

-- no debconf information

Bug#1001823: Re-send patch, bugtracker messed up spaces

[Jens Rottmann]

Turns out bugtracker messes up whitespace in text/patch attachments. :(
Re-attaching same patch, but gziped, hoping it's left intact now.


python3fix.patch.gz
Description: application/gzip

Bug#994794: booth: intermittent autopkgtest failures

[Simon Chopin]

Package: booth
Followup-For: Bug #994794
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu jammy ubuntu-patch
X-Debbugs-Cc: simon.cho...@canonical.com
Control: tags -1 patch

In Ubuntu, the attached patch was applied on top of the fix, as the
online node doesn't necessarily contain the 'node1' string in the name.
I'm guessing it depends on the configuration of the autopkgtest runners.

For instance, here is the output of the crm status command in my
LXC-based local runner.

```
Cluster Summary:
  * Stack: corosync
  * Current DC: autopkgtest-lxc-fisgca (version 2.0.5-ba59be7122) - partition 
with quorum
  * Last updated: Fri Dec 17 16:56:18 2021
  * Last change:  Fri Dec 17 16:55:54 2021 by hacluster via crmd on 
autopkgtest-lxc-fisgca
  * 1 node configured
  * 0 resource instances configured

Node List:
  * Online: [ autopkgtest-lxc-fisgca ]

Full List of Resources:
  * No resources
```

Cheers,
Simon Chopin
diff -Nru booth-1.0-237-gdd88847/debian/tests/pacemaker 
booth-1.0-237-gdd88847/debian/tests/pacemaker
--- booth-1.0-237-gdd88847/debian/tests/pacemaker   2021-09-22 
22:33:36.0 +0200
+++ booth-1.0-237-gdd88847/debian/tests/pacemaker   2021-12-17 
17:49:22.0 +0100
@@ -28,7 +28,7 @@
 start_service corosync
 start_service pacemaker
 n=0
-while ! crm status | grep 'Online:.*node1'; do
+while ! crm status | grep "\\* Online: "; do
   test "$n" -lt 120
   sleep 1
   n=$((n+1))

Bug#1001838: AttributeError: 'NoneType' object has no attribute 'group'

[stefanor]

Hi Christoph (2021.12.17_13:45:19_+)
> I have no idea if this is a bug in dh-python or elsewhere, but it's
> showing up here.

It's a dh-python bug, from the environment marker parsing in 5.20211213.
Thanks!

SR

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  +1 415 683 3272

Bug#1001823: Improved patch

[Jens Rottmann]

My fix removes the only occurrence of cmp() in magic.py, so we should drop the 
line importing past.builtins.cmp. Updated patch accordingly, also improved 
commit message.

Attached patch v2, hoping bugtracker can handle attachments.
Python 3 port introduced at least five severe bugs.

* Customizing action keys via Options, Control prints 2 deprecation warnings
  and no longer works, changed keys aren't saved. Not being able to remap
  keys makes it hard for users of non-English keyboards. (controls.py)
* Playing as Nyx and casting Ice ([D][S]) or Implosion ([D][W]) instantly
  crashes the game due to 3 exceptions. (magic.py)
* Playing as Pyralis and using Spin-slash ([C][S]) hangs gameplay, you have
  to abort the current level to be able to move again. (play_level.py)

Bug-Debian: https://bugs.debian.org/1001823
Signed-off-by: Jens Rottmann

--- ardentryst/controls.py
+++ python3fix/controls.py
@@ -35,7 +35,7 @@
 class SET2:
 def __init__(self, keycodes, x, y, set):
 self.set = set
-self.keys = [Key(keycodes[c], x + ((8-c)%3) * 32, y + (c/3)*30, "B-" + str(((11-c)/3)*3 - (11-c)%3), set) for c in range(9)]
+self.keys = [Key(keycodes[c], x + ((8-c)%3) * 32, y + (c//3)*30, "B-" + str(((11-c)//3)*3 - (11-c)%3), set) for c in range(9)]

 class Key:
 def __init__(self, keycode, x, y, binding, set):
--- ardentryst/magic.py
+++ python3fix/magic.py
@@ -21,7 +21,6 @@

 import pygame, math, random
 from pygame.locals import *
-from past.builtins import cmp

 def ground_at(LEVEL, x, f=False):
 "Finds the y co-ordinate of the ground at position x."
@@ -236,7 +235,7 @@ class Ice_1(Spell):
 def s_init(self):
 global DATA
 self.affected = []
-self.cant = self.caster.mp < 4
+self.cant = self.caster.mp[0] < 4
 def s_blit(self, surf, ALT_X, ALT_Y):
 global DATA
 if not self.affected:
@@ -441,7 +440,7 @@ class Implosion_1(Spell):
 def s_init(self):
 global DATA
 self.affected = []
-self.cant = self.caster.mp < 15
+self.cant = self.caster.mp[0] < 15
 def s_blit(self, surf, ALT_X, ALT_Y):
 global DATA
 pic = DATA.mag_images["bubble.png"][0]
@@ -472,7 +471,7 @@ class Implosion_1(Spell):
 if self.caster.mp[0] >= 15:
 self.affected.append(monster)

-self.affected.sort(lambda x, y: cmp(y.maxhp, x.maxhp))
+self.affected.sort(key=lambda x: -x.maxhp)

 if len(self.affected):
 self.affected = self.affected[:1]
--- ardentryst/play_level.py
+++ python3fix/play_level.py
@@ -4727,7 +4727,7 @@ class Character:
 self.mycombotime -= 1
 if self.chainmove[1] and self.chainmove[1] > 0:
 self.chainmove[1] -= 1
-if self.chainmove[1] and self.chainmove[1] == 0:
+if self.chainmove[1] == 0:
 cm = self.chainmove[:]
 self.chainmove = [None, None]
 getattr(self, cm[0])()
--

Bug#1001770: libgmsh4.8: needs Breaks+Replaces: libgmsh4 (>= 4.8)

[Andreas Beckmann]

Followup-For: Bug #1001770
Control: reassign -1 libgmsh4.8 4.8.4+ds1-1
Control: retitle -1 libgmsh4.8: needs Breaks+Replaces: libgmsh4 (>= 4.8)

libgmsh4.8 is the new package and co-installable with libgmsh4 4.7.* in
stable, thus the a bit unusual (>= 4.8) relation to only break the bad
version in sid.

Andreas

Bug#1001833: guix pull throws "match-error"

[Vagrant Cascadian]

On 2021-12-17, alexander barakin wrote:
> i have installed package guix (1.2.0-4).
> and try to run guix pull:
>
> [code]
> Updating channel 'guix' from Git repository at 
> 'https://git.savannah.gnu.org/git/guix.git'...
> Building from this channel:
>   guix  https://git.savannah.gnu.org/git/guix.git   b329c21
> Backtrace:
>6 (apply-smob/1 #)
> In ice-9/boot-9.scm:
> 705:2  5 (call-with-prompt _ _ #)
> In ice-9/eval.scm:
> 619:8  4 (_ #(#(#)))
> In guix/ui.scm:
>   2117:12  3 (run-guix-command _ . _)
> In ice-9/boot-9.scm:
> 829:9  2 (catch _ _ # …)
> 829:9  1 (catch _ _ # …)
> 829:9  0 (catch _ _ # …)
>
> ice-9/boot-9.scm:829:9: In procedure catch:
> Throw to key `match-error' with args `("match" "no matching pattern" (
> #:re-export-and-replace (delete)
> #:replace ((define-public* . define-public))
> #:export (content-hash content-hash? content-hash-algorithm content-hash-value
> origin origin? this-origin origin-uri origin-method origin-hash origin-sha256
...
> bag-transitive-target-inputs package-development-inputs package-closure
> default-guile default-guile-derivation set-guile-for-build package-file
> package->derivation package->cross-derivation origin->derivation)))'.
> [/code]
>
> i was able to work around this error:
> [code]
> $ guix pull --branch=version-1.3.0
> [/code]

try with the commit from v1.3.0 (ideally from a fresh install, or maybe
using --allow-downgrades):

  guix pull --commit=a0178d34f582b50e9bdbb0403943129ae5b560ff

and then:

  guix pull

Though it might get you roughly the same issues.

Massive changes were recently merged into guix master, so it wouldn't be
terribly surprising if something incompatible crept in...

I'll try to reproduce the issue, though not sure exactly when I'll get
the chance.


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1001844: sdformat9-doc: ships /usr/share/doc/sdformat-doc/html/jquery.js

[Andreas Beckmann]

Package: sdformat9-doc
Version: 9.6.1+ds1-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package failed to install
because it tries to overwrite other packages files.

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

  Preparing to unpack .../sdformat9-doc_9.6.1+ds1-1_all.deb ...
  Unpacking sdformat9-doc (9.6.1+ds1-1) ...
  dpkg: error processing archive 
/var/cache/apt/archives/sdformat9-doc_9.6.1+ds1-1_all.deb (--unpack):
   trying to overwrite '/usr/share/doc/sdformat-doc/html/jquery.js', which is 
also in package sdformat-doc 12.0.0+ds-1
  Errors were encountered while processing:
   /var/cache/apt/archives/sdformat9-doc_9.6.1+ds1-1_all.deb

/usr/share/doc/sdformat-doc/html/jquery.js should rather be in 
.../sdformat*9*-doc/...


cheers,

Andreas


sdformat-doc=12.0.0+ds-1_sdformat9-doc=9.6.1+ds1-1.log.gz
Description: application/gzip

Bug#1001843: libmariadb-dev: mariadb_config reports incorrect plugin directory

[Akira Miyakoda]

Package: libmariadb-dev
Version: 1:10.5.12-1+b1
Severity: normal
X-Debbugs-Cc: akira.miyak...@gmail.com

Dear Maintainer,

Since Debian 11 or Ubuntu 21.10, the command 'mariadb_config --plugin' returns 
'/usr/lib/arm-linux-gnueabihf/libmariadb3/plugin' which doesn't work. MariaDB 
server doesn't load the plugins installed in the directory. I
think it should be '/usr/lib/mysql/plugin/'.
The same issue occurs on x86_64 systems too.

It returned the correct directory on Debian 10 or Ubuntu 20.04 as far as I 
tried.

Thanks, Akira.

-- System Information:
Distributor ID: Raspbian
Description:Raspbian GNU/Linux 11 (bullseye)
Release:11
Codename:   bullseye
Architecture: armv7l

Kernel: Linux 5.10.63-v7l+ (SMP w/4 CPU threads)
Kernel taint flags: TAINT_CRAP
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=locale: Cannot set 
LC_ALL to default locale: No such file or directory
UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libmariadb-dev depends on:
ii  libc62.31-13+rpt2+rpi1
ii  libmariadb3  1:10.5.12-1+b1
ii  libssl-dev   1.1.1k-1+deb11u1
ii  zlib1g-dev   1:1.2.11.dfsg-2

libmariadb-dev recommends no packages.

libmariadb-dev suggests no packages.

-- debconf information:
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = (unset),
LC_ALL = (unset),
LC_TIME = "en_AU.UTF-8",
LC_MONETARY = "en_AU.UTF-8",
LC_ADDRESS = "en_AU.UTF-8",
LC_TELEPHONE = "en_AU.UTF-8",
LC_NAME = "en_AU.UTF-8",
LC_MEASUREMENT = "en_AU.UTF-8",
LC_IDENTIFICATION = "en_AU.UTF-8",
LC_NUMERIC = "en_AU.UTF-8",
LC_PAPER = "en_AU.UTF-8",
LANG = "en_GB.UTF-8"
are supported and installed on your system.
perl: warning: Falling back to a fallback locale ("en_GB.UTF-8").
locale: Cannot set LC_ALL to default locale: No such file or directory

Bug#1001828: eglQueryDevicesEXT doesn't update as new devices are added

[Guido Günther]

Hi,
On Fri, Dec 17, 2021 at 09:15:34AM +0100, Guido Günther wrote:
> and I also asked for a new release to make this simpler for
> distributions to ship
> 
> https://gitlab.freedesktop.org/glvnd/libglvnd/-/issues/226

There's a 1.4.0 upstream version now having all the patches:

https://gitlab.freedesktop.org/glvnd/libglvnd/-/tags/v1.4.0

Cheers,
 -- Guido

Bug#1001842: qalc performs wrong unit conversion without warning when asked to do so

[mister01x]

Package: qalc
Version: 3.20.1-3
Severity: normal

Dear Maintainer,

* What led up to the situation?

 I tried to perform an unit conversion using qalc.

* What exactly did you do (or not do) that was effective (or
 ineffective)?

 I did the following calculation in qalc

3m/(A*T) -> Pa

* What was the outcome of this action?

(3 × meter) / (ampere × tesla) ≈ 0,33 Pa


* What outcome did you expect instead?

 A warning that this conversion is not possible or alternatively a
correct result including this unit, e.g.:

(3 × meter) / (ampere × tesla) = 3 Pa^−1

For clarification: The result of the conversion is wrong because
the following physical equation (written in LaTeX) is true:

\[\mathrm{1 \frac{m}{A \cdot T} = 1 \frac{m \cdot A s^2}{A \cdot kg} =
1 \frac{m \cdot s^2}{kg} = 1 \frac{1}{Pa}}\]


Thanks for maintaining qalc!

Marcel


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

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

Versions of packages qalc depends on:
ii  libc6   2.33-1
ii  libgcc-s1   11.2.0-12
ii  libqalculate22  3.20.1-3
ii  libreadline88.1-2
ii  libstdc++6  11.2.0-12

Versions of packages qalc recommends:
ii  wget  1.21.2-2+b1

qalc suggests no packages.

-- no debconf information

Bug#994575: dipy: autopkgtest idea

[Andreas Tille]

Am Thu, Dec 16, 2021 at 09:10:45PM +0100 schrieb Andreas Tille:
> Hi Étienne,
> 
> Am Fri, Sep 17, 2021 at 11:11:03PM +0200 schrieb Étienne Mollier:
> > While working on #983840, I needed to do some testing of the
> > package, and notice examples in doc/examples/.  Maybe they could
> > be a source of inspiration for building an autopkgtest test
> > suite?
> 
> I think the idea itself is good but the realisation has some flaws.
> I've commited some code implementing the idea to Git but it seems we
> need to exclude lots of those examples as you can see for instance here
> in the Salsa CI
> 
>https://salsa.debian.org/med-team/dipy/-/jobs/2285615
> 
> May be running the build-time nosetest is the easier approach to an
> autopkgtest.

Thanks for porting to pytest.  I've added the pytest test to autopkgtest
but all tests are failing:

https://salsa.debian.org/med-team/dipy/-/pipelines/328590

Any idea what might be wrong here?

Kind regards

  Andreas.
 

-- 
http://fam-tille.de

Bug#1000967: spdlog: Please package (and test) new version v1.9.x

[Shengjing Zhu]

Hi,

fmtlib 8 transition[1] has started, please help uploading spdlog 1.9
to unstable.

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

Thanks.

--
Shengjing Zhu

Bug#999279: swish-e: diff for NMU version 2.4.7-6.1

[Ludovic Drolez]

On Thu, Dec 16, 2021 at 07:56:50AM +, Damyan Ivanov wrote:
> Control: tags 999279 + patch
> Control: tags 999279 + pending
> 
> Dear maintainer,
> 
> I've prepared an NMU for swish-e (versioned as 2.4.7-6.1) and
> uploaded it to DELAYED/7. Please feel free to tell me if I
> should delay it longer.
> 

Hi!

That's perfect, thanks for your help!

-- 
Ludovic

https://isabelleantoine.be   - Coaching Gestion du Stress

Bug#993379: libyami-utils FTBFS: error: ‘void av_init_packet(AVPacket*)’ is deprecated [-Werror=deprecated-declarations]

[Simon Chopin]

Package: libyami-utils
Version: 1.3.0-3
Followup-For: Bug #993379
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu jammy ubuntu-patch
X-Debbugs-Cc: simon.cho...@canonical.com
Control: tags -1 patch

Hi,

In Ubuntu, the attached patch was applied to fix the aforementioned
FTBFS:

Thanks for considering the patch.

Cheers,
Simon
diff -Nru 
libyami-utils-1.3.0/debian/patches/0004-tests-decodeinputavformat-use-heap-allocated-m_packe.patch
 
libyami-utils-1.3.0/debian/patches/0004-tests-decodeinputavformat-use-heap-allocated-m_packe.patch
--- 
libyami-utils-1.3.0/debian/patches/0004-tests-decodeinputavformat-use-heap-allocated-m_packe.patch
  1970-01-01 01:00:00.0 +0100
+++ 
libyami-utils-1.3.0/debian/patches/0004-tests-decodeinputavformat-use-heap-allocated-m_packe.patch
  2021-12-17 15:50:51.0 +0100
@@ -0,0 +1,85 @@
+From dbd0c5508d0084a9b069cafd583e6004a12f562a Mon Sep 17 00:00:00 2001
+From: Simon Chopin 
+Date: Fri, 17 Dec 2021 16:03:10 +0100
+Subject: [PATCH] tests/decodeinputavformat: use heap-allocated m_packet
+Forwarded: https://github.com/intel/libyami-utils/pull/138
+
+This allows us to migrate away from av_init_packet() which has been
+deprecated in recent FFMpeg, making the build fail.
+
+This implementation is somewhat rough, there's probably a way to avoid
+reallocating the packet each iteration, but it does the job.
+---
+ tests/decodeinputavformat.cpp | 23 +--
+ tests/decodeinputavformat.h   |  2 +-
+ 2 files changed, 10 insertions(+), 15 deletions(-)
+
+--- a/tests/decodeinputavformat.cpp
 b/tests/decodeinputavformat.cpp
+@@ -22,18 +22,12 @@
+ #include "common/log.h"
+ #include 
+ 
+-#if LIBAVCODEC_VERSION_INT < AV_VERSION_INT(55, 39, 100)
+-#define av_packet_unref av_free_packet
+-#endif
+-
+ DecodeInputAvFormat::DecodeInputAvFormat()
+-:m_format(NULL),m_videoId(-1), m_codecId(AV_CODEC_ID_NONE), m_isEos(true)
++:m_format(NULL),m_videoId(-1), m_codecId(AV_CODEC_ID_NONE), 
m_packet(av_packet_alloc()), m_isEos(true)
+ {
+ #if LIBAVFORMAT_VERSION_INT < AV_VERSION_INT(58, 9, 100)
+ av_register_all();
+ #endif
+-
+-av_init_packet(_packet);
+ }
+ 
+ bool DecodeInputAvFormat::initInput(const char* fileName)
+@@ -132,18 +126,19 @@
+ int ret;
+ while (1) {
+ //free old packet
+-av_packet_unref(_packet);
++av_packet_free(_packet);
++m_packet = av_packet_alloc();
+ 
+-ret = av_read_frame(m_format, _packet);
++ret = av_read_frame(m_format, m_packet);
+ if (ret) {
+ m_isEos = true;
+ return false;
+ }
+-if (m_packet.stream_index == m_videoId) {
++if (m_packet->stream_index == m_videoId) {
+ memset(, 0, sizeof(inputBuffer));
+-inputBuffer.data = m_packet.data;
+-inputBuffer.size = m_packet.size;
+-inputBuffer.timeStamp = m_packet.dts;
++inputBuffer.data = m_packet->data;
++inputBuffer.size = m_packet->size;
++inputBuffer.timeStamp = m_packet->dts;
+ return true;
+ }
+ }
+@@ -158,8 +153,8 @@
+ DecodeInputAvFormat::~DecodeInputAvFormat()
+ {
+ if (m_format) {
+-av_packet_unref(_packet);
+ avformat_close_input(_format);
+ }
++av_packet_free(_packet);
+ 
+ }
+--- a/tests/decodeinputavformat.h
 b/tests/decodeinputavformat.h
+@@ -47,7 +47,7 @@
+ AVFormatContext* m_format;
+ int m_videoId;
+ AVCodecID m_codecId;
+-AVPacket m_packet;
++AVPacket* m_packet;
+ bool m_isEos;
+ string m_codecData;
+ };
diff -Nru libyami-utils-1.3.0/debian/patches/av_packet_init-deprecated.patch 
libyami-utils-1.3.0/debian/patches/av_packet_init-deprecated.patch
--- libyami-utils-1.3.0/debian/patches/av_packet_init-deprecated.patch  
1970-01-01 01:00:00.0 +0100
+++ libyami-utils-1.3.0/debian/patches/av_packet_init-deprecated.patch  
2021-12-17 15:48:08.0 +0100
@@ -0,0 +1,61 @@
+Description: Migrate away from the deprecated av_packet_init API
+Author: Simon Chopin 
+
+--- a/tests/decodeinputavformat.cpp
 b/tests/decodeinputavformat.cpp
+@@ -33,7 +33,7 @@
+ av_register_all();
+ #endif
+ 
+-av_init_packet(_packet);
++m_packet = av_packet_alloc();
+ }
+ 
+ bool DecodeInputAvFormat::initInput(const char* fileName)
+@@ -132,18 +132,19 @@
+ int ret;
+ while (1) {
+ //free old packet
+-av_packet_unref(_packet);
++av_packet_free(_packet);
++m_packet = av_packet_alloc();
+ 
+-ret = av_read_frame(m_format, _packet);
++ret = av_read_frame(m_format, m_packet);
+ if (ret) {
+ m_isEos = true;
+ return false;
+ }
+-if (m_packet.stream_index == m_videoId) {
++if (m_packet->stream_index == m_videoId) {
+ memset(, 0, sizeof(inputBuffer));
+-inputBuffer.data = m_packet.data;
+-inputBuffer.size = m_packet.size;
+-inputBuffer.timeStamp 

Bug#1001527: FTBFS with fmtlib 8

[Shengjing Zhu]

Control: severity -1 serious

Hi,

On Sat, Dec 11, 2021 at 11:15 PM Shengjing Zhu  wrote:
> I have uploaded fmtlib/8 to experimental, and plan to start this transition.
>
> You package FTBFS with fmtlib/8, it has been fixed in version 2021.08.26.
> Please package the new version or backport the relevant commits.
>

fmtlib 8 transition[1] has started, thus I'm raising the severity.

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

Thanks.

--
Shengjing Zhu

Bug#1001841: liblouisutdml autopkgtest failing with the new liblouis

[Sebastien Bacher]

Package: liblouis
Version: 3.20.0-1

The liblouisutdml autopkgtests are failing since the liblouis 3.20.0-1 
update

https://ci.debian.net/packages/libl/liblouisutdml/testing/amd64/

one example of error from the log

'pagenum.cti:27: error: The uplow opcode is deprecated.
1 errors found.
nabcc.dis,whitespace.cti,identity.cti,pagenum.cti,hyph.dic could not be 
compiled
liblouisutdml.ini:29: Table 
'nabcc.dis,whitespace.cti,identity.cti,pagenum.cti,hyph.dic' cannot be 
found.

liblouisutdml.ini:29: invalid literaryTextTable
'

Cheers,

Bug#1001840: New upstream version 2.4.109

[Guido Günther]

Source: libdrm
Version: 2.4.108-1
Severity: wishlist

Hi,
It would be great to have libdrm2 2.4.109 in sid or
experimental. wlroots 0.15.0 (just released) depends on it for dmabuf
feedback support.

Cheers and thanks a lot for keeping libdrm in shape all the time!
 -- Guido



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

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

Bug#1001453: security-tracker: extend support for bug reporting to update the CVE list with the bug number

[Neil Williams]

On Fri, 10 Dec 2021 10:56:25 + Neil Williams 
wrote:
> A tool to automate a syntactically correct change to a specific CVE
> would be a useful extension of this support, not just to add the bug
> number once the email is received from the BTS but to also make other
> standard changes:
> 
> - mark a given released suite (stable/oldstable/LTS) as 

For this operation, should  clear only specific kinds for
the specified suite?

e.g. if kind==fixed, then version would need to be unset for the CVE to
show as not-affected & any bug number might also have to be cleared if
the suite was specified as sid?

Should annotations like "Minor issue" be retained or removed?

Or should the script refuse to change kind==fixed & possibly others &
maybe only make changes if kind is None?


-- 
Neil Williams
=
https://linux.codehelp.co.uk/


pgprEqhfRMQBm.pgp
Description: OpenPGP digital signature

Bug#1001759: RFS: qt6/6.2.2+ds-1 -- Qt for Android (x86_64)

[Lisandro Damián Nicanor Pérez Meyer]

On Wed, 15 Dec 2021 16:46:55 +0100 Fab Stz  wrote:
> Hello,
>
> Le mercredi 15 décembre 2021, 16:22:41 CET Andrey Rahmatullin a écrit :
> > Having a source package named "qt6" build Android-specific packages sounds
> > wrong to me.
>
> I understand. I gave it that name to be at least distinct from the other qt6
> packages. This can be changed to anything more suitable like qt6-android or
> whatever.

Yes please.

> > Is this intended to contain the normal Qt source code and so
> > be a duplicate of normal Qt packages?
>
> It can't be duplicate to DFSG Qt source code as shipped by Debian because
> these sources have been stripped down and some files/libraries that are needed
> for the qt for android "variant" are missing. That's the case for 'sqlite' as
> well as for 'freetype' and 'libpng' if I remember well. These libraries used
> by Qt for Android are not shipped in Android NDK, so we have to build with
> their source shipped in the qt sources. Hence the need of a distinct source
> file.

Is this a situation we can accommodate within the archive?

> You can follow a beginning of discussion on qt for android in [1]. Having a
> distinct source archive seemed to be the favored option.
>
> [1] https://alioth-lists.debian.net/pipermail/pkg-kde-talk/2021-September/
> thread.html

debian/copyright is already 11k+ lines long. I doubt anyone would like
to review such a beast.

My point of view is that, in this form, this does not belongs into the archive.

Bug#1001839: New upstream version 1.20.0

[Guido Günther]

Source: wayland
Version: 1.19.0-2
Severity: wishlist

Hi,

it would be great to have wayland 1.20.0¹ (only released a week ago) in
sid or experimental since wlroots 0.15.0 depends on it.

Cheers,
 -- Guido


1) https://gitlab.freedesktop.org/wayland/wayland/-/tags/1.20.0

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

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

Bug#1001838: AttributeError: 'NoneType' object has no attribute 'group'

[Christoph Berg]

Package: dh-python
Version: 5.20211216
Severity: normal
Affects: jenkins-job-builder

I have no idea if this is a bug in dh-python or elsewhere, but it's
showing up here.


jenkins-job-builder has this requirement.txt:

# The order of packages is significant, because pip processes them in the order
# of appearance. Changing the order has an impact on the overall integration
# process, which may cause wedges in the gate later.
six>=1.9.0 # MIT
PyYAML>=3.10.0,<6 # MIT
pbr>=1.8 # Apache-2.0
stevedore>=1.17.1,<2; python_version < '3.0'  # Apache-2.0
stevedore>=1.17.1; python_version >= '3.0'  # Apache-2.0
python-jenkins>=0.4.15
fasteners
Jinja2


The < '3.0' line shows up like this in the built package:

$ cat 
debian/python3-jenkins-job-builder/usr/lib/python3/dist-packages/jenkins_job_builder-3.11.0.egg-info/requires.txt
Jinja2
PyYAML<6,>=3.10.0
fasteners
pbr>=1.8
python-jenkins>=0.4.15
six>=1.9.0
stevedore>=1.17.1

[:(python_version < '3.0')]
stevedore<2,>=1.17.1


This in turn leads to this dh_python3 output (with one debugging line
"Looking at" added):

$ dh_python3 -i -O--buildsystem=pybuild
W: dh_python3 fs:134: Paths differ: 
debian/python3-jenkins-job-builder/usr/lib/python3.10/dist-packages/jenkins_job_builder-3.11.0.egg-info/PKG-INFO
 and 
debian/python3-jenkins-job-builder/usr/lib/python3/dist-packages/jenkins_job_builder-3.11.0.egg-info/PKG-INFO
Looking at 
debian/python3-jenkins-job-builder/usr/lib/python3/dist-packages/jenkins_job_builder-3.11.0.egg-info/requires.txt
 [:(python_version < '3.0')]
Traceback (most recent call last):
  File "/usr/bin/dh_python3", line 280, in 
main()
  File "/usr/bin/dh_python3", line 201, in main
dependencies.parse(stats, options)
  File "/usr/share/dh-python/dhpython/depends.py", line 242, in parse
deps = parse_pydep(self.impl, fn, bdep=self.bdep, **section_options)
  File "/usr/share/dh-python/dhpython/pydist.py", line 474, in parse_pydep
section = m.group('section')
AttributeError: 'NoneType' object has no attribute 'group'



Christoph

Bug#1001451: Candidate script

[Salvatore Bonaccorso]

Hi neil,

On Fri, Dec 17, 2021 at 01:14:52PM +, Neil Williams wrote:
> On Fri, 17 Dec 2021 13:40:04 +0100 Salvatore Bonaccorso  
> wrote:
> > Hi Neil,
> > 
> > On Fri, Dec 17, 2021 at 01:22:32PM +0100, Salvatore Bonaccorso wrote:
> > > Hi,
> > > 
> > > > Online - query either the distro-tracker or debian-devel-changes mail 
> > > > archive:
> > > >   --email EMAIL  URL of debian-devel-changes announcement in the 
> > > > list archive
> > > >   --tracker TRACKER  URL of tracker.debian.org 'Accepted NEWS' page for 
> > > > unstable
> > > > 
> > > 
> > > Nice! I will need (or want) to try to experiment with it a bit on
> > > apparing real cases.
> > 
> > Just doing a quick test, while beeing entusiastic about your proposed
> > script: I think it will not work correctly yet wit bin/merge-cve-list.
> > On either side it will need adaption.
> 
> OK. I will add that to my tests on next versions of the script.
>  
> > Taking the example with freerdp2, assuming there won't be the fixed
> > version yet in the data/CVE/list it will produce the following
> > freerdp2.list:
> > 
> > CVE-2021-41160 (FreeRDP is a free implementation of the Remote Desktop 
> > Protocol (RDP), ...)
> > - freerdp2 2.4.1+dfsg1-1 (bug #1001062)
> > [bullseye] - freerdp2  (Minor issue)
> > [buster] - freerdp2  (Minor issue)
> > - freerdp 
> 
> > $ ./bin/merge-cve-list data/CVE/list ./freerdp2.list
> > [...]
> > NotImplementedError: unsupported annotation of type NOTE (line 7)
> > 
> > So maybe it's just merge-cve-list which should be better and allow for
> > such situation and handle as well the NOTEs.
> 
> I'll work on adding that support - it will be useful for the
> changes for #1001453 which wants to explicitly add a NOTE entry.

Yes agreed, unter this aspect it makes more sense to fix and expand
merge-cve-list script.

> > This just what i noticed while wanting to try it out.
> > 
> > Usually we read the debian-changes mails in a MUA, so I wonder if we
> > can make the script accept as well not only things passed by --tracker
> > or --email, but rather piped trough when reading the changes mail in
> > e.g. mutt. What woud you think about it?
> 
> I wondered if stdin type input would be required. I'll work on that
> next week, probably Monday.

Thank you! :)

Salvatore

Bug#1001837: RM: ansible-base -- ROM; deprecated; package superseded by ansible-core

[Lee Garrett]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: deb...@rocketjump.eu

ansible-base was renamed to ansible-core by upstream. This is already packaged
and has been uploaded to unstable. As such, please remove ansible-base from
testing/unstable. Thanks!

Bug#1001451: Candidate script

[Neil Williams]

On Fri, 17 Dec 2021 13:40:04 +0100 Salvatore Bonaccorso  
wrote:
> Hi Neil,
> 
> On Fri, Dec 17, 2021 at 01:22:32PM +0100, Salvatore Bonaccorso wrote:
> > Hi,
> > 
> > > Online - query either the distro-tracker or debian-devel-changes mail 
> > > archive:
> > >   --email EMAIL  URL of debian-devel-changes announcement in the list 
> > > archive
> > >   --tracker TRACKER  URL of tracker.debian.org 'Accepted NEWS' page for 
> > > unstable
> > > 
> > 
> > Nice! I will need (or want) to try to experiment with it a bit on
> > apparing real cases.
> 
> Just doing a quick test, while beeing entusiastic about your proposed
> script: I think it will not work correctly yet wit bin/merge-cve-list.
> On either side it will need adaption.

OK. I will add that to my tests on next versions of the script.
 
> Taking the example with freerdp2, assuming there won't be the fixed
> version yet in the data/CVE/list it will produce the following
> freerdp2.list:
> 
> CVE-2021-41160 (FreeRDP is a free implementation of the Remote Desktop 
> Protocol (RDP), ...)
> - freerdp2 2.4.1+dfsg1-1 (bug #1001062)
> [bullseye] - freerdp2  (Minor issue)
> [buster] - freerdp2  (Minor issue)
> - freerdp 

> $ ./bin/merge-cve-list data/CVE/list ./freerdp2.list
> [...]
> NotImplementedError: unsupported annotation of type NOTE (line 7)
> 
> So maybe it's just merge-cve-list which should be better and allow for
> such situation and handle as well the NOTEs.

I'll work on adding that support - it will be useful for the
changes for #1001453 which wants to explicitly add a NOTE entry.
 
> This just what i noticed while wanting to try it out.
> 
> Usually we read the debian-changes mails in a MUA, so I wonder if we
> can make the script accept as well not only things passed by --tracker
> or --email, but rather piped trough when reading the changes mail in
> e.g. mutt. What woud you think about it?

I wondered if stdin type input would be required. I'll work on that
next week, probably Monday.

-- 


Neil Williams
=
http://www.linux.codehelp.co.uk/



pgpnI8O4j0674.pgp
Description: OpenPGP digital signature

Bug#1001836: Update

[in . cognito35]

Not sure whether and under which conditions you backport bugs known to be fixed in newer releases to stable releases. Anyway, probably it helps somebody searching BTS for this particular bug ...

Bug#1001451: Candidate script

[Salvatore Bonaccorso]

Hi Neil,

On Fri, Dec 17, 2021 at 01:22:32PM +0100, Salvatore Bonaccorso wrote:
> Hi,
> 
> On Fri, Dec 17, 2021 at 11:57:34AM +, Neil Williams wrote:
> > https://salsa.debian.org/codehelp/security-tracker/-/commit/2df53b5421cde0c7b1b2dd3343d71aebde2d55b7
> > 
> > https://salsa.debian.org/codehelp/security-tracker/-/raw/grabcvefix/bin/grab-cve-in-fix
> > 
> > Dependencies: python3-debian
> > 
> > Usage: Download from the raw link as bin/grab-cve-in-fix and make it 
> > executable.
> > 
> > ./bin/grab-cve-in-fix --help
> > 
> > usage: grab-cve-in-fix [-h] [[--email EMAIL] | [--tracker TRACKER]] | 
> > [[--src SRC] & [--cves [CVES ...]]]
> > 
> > Grab CVE data from a package upload for manual review
> > 
> > optional arguments:
> >   -h, --help show this help message and exit
> > 
> > Online - query either the distro-tracker or debian-devel-changes mail 
> > archive:
> >   --email EMAIL  URL of debian-devel-changes announcement in the list 
> > archive
> >   --tracker TRACKER  URL of tracker.debian.org 'Accepted NEWS' page for 
> > unstable
> > 
> > Offline - run 'make update-packages' first & specify source package and CVE 
> > list:
> >   --src SRC  Source package name to look up version in local 
> > packages files
> >   --cves [CVES ...]  CVE ID tag with version from local packages files
> > 
> > Data is written to a new .list file which can be used with 
> > './bin/merge-cve-files'
> > 
> > 
> > Examples:
> > 
> > ./bin/grab-cve-in-fix --src freerdp2 --cve CVE-2021-41160
> > 
> > ./bin/grab-cve-in-fix --tracker 
> > https://tracker.debian.org/news/1285227/accepted-freerdp2-241dfsg1-1-source-into-unstable/
> > 
> > ./bin/grab-cve-in-fix --email 
> > https://lists.debian.org/debian-devel-changes/2021/12/msg01280.html
> > 
> > (For these specific examples, data/CVE/list for CVE-2021-41160 would need 
> > to be altered, say to , locally.)
> 
> Nice! I will need (or want) to try to experiment with it a bit on
> apparing real cases.

Just doing a quick test, while beeing entusiastic about your proposed
script: I think it will not work correctly yet wit bin/merge-cve-list.
On either side it will need adaption.

Taking the example with freerdp2, assuming there won't be the fixed
version yet in the data/CVE/list it will produce the following
freerdp2.list:

CVE-2021-41160 (FreeRDP is a free implementation of the Remote Desktop Protocol 
(RDP), ...)
- freerdp2 2.4.1+dfsg1-1 (bug #1001062)
[bullseye] - freerdp2  (Minor issue)
[buster] - freerdp2  (Minor issue)
- freerdp 
[stretch] - freerdp  (Minor issue)
NOTE: 
https://github.com/FreeRDP/FreeRDP/security/advisories/GHSA-7c9r-6r2q-93qg
NOTE: https://github.com/FreeRDP/FreeRDP/pull/7349
NOTE: 
https://github.com/FreeRDP/FreeRDP/commit/217e0caa181fc1690cf84dd6a3ba1a4f90c02692
CVE-2021-41159 (FreeRDP is a free implementation of the Remote Desktop Protocol 
(RDP), ...)
- freerdp2 2.4.1+dfsg1-1 (bug #1001061)
[bullseye] - freerdp2  (Minor issue)
[buster] - freerdp2  (Minor issue)
- freerdp 
[stretch] - freerdp  (Minor issue)
NOTE: 
https://github.com/FreeRDP/FreeRDP/security/advisories/GHSA-vh34-m9h7-95xq
NOTE: 
https://github.com/FreeRDP/FreeRDP/commit/d39a7ba5c38e3ba3b99b1558dc2ab0970cbfb0c5
 (Stable 2.0 backports)
NOTE: 
https://github.com/FreeRDP/FreeRDP/commit/f0b44da67c09488178000725ff9f2729ccfdf9fe

which one would then manually review first. But ideally the NOTE's are
not handled by the merge-cve-list script. So either your proposed
script can strip the NOTEs, or one does it manually, or
bin/merge-cve-lists can deal with that situation.

$ ./bin/merge-cve-list data/CVE/list ./freerdp2.list
[...]
NotImplementedError: unsupported annotation of type NOTE (line 7)

So maybe it's just merge-cve-list which should be better and allow for
such situation and handle as well the NOTEs.

This just what i noticed while wanting to try it out.

Usually we read the debian-changes mails in a MUA, so I wonder if we
can make the script accept as well not only things passed by --tracker
or --email, but rather piped trough when reading the changes mail in
e.g. mutt. What woud you think about it?

Regards,
Salvatore

Bug#1001451: Candidate script

[Salvatore Bonaccorso]

Hi,

On Fri, Dec 17, 2021 at 11:57:34AM +, Neil Williams wrote:
> https://salsa.debian.org/codehelp/security-tracker/-/commit/2df53b5421cde0c7b1b2dd3343d71aebde2d55b7
> 
> https://salsa.debian.org/codehelp/security-tracker/-/raw/grabcvefix/bin/grab-cve-in-fix
> 
> Dependencies: python3-debian
> 
> Usage: Download from the raw link as bin/grab-cve-in-fix and make it 
> executable.
> 
> ./bin/grab-cve-in-fix --help
> 
> usage: grab-cve-in-fix [-h] [[--email EMAIL] | [--tracker TRACKER]] | [[--src 
> SRC] & [--cves [CVES ...]]]
> 
> Grab CVE data from a package upload for manual review
> 
> optional arguments:
>   -h, --help show this help message and exit
> 
> Online - query either the distro-tracker or debian-devel-changes mail archive:
>   --email EMAIL  URL of debian-devel-changes announcement in the list 
> archive
>   --tracker TRACKER  URL of tracker.debian.org 'Accepted NEWS' page for 
> unstable
> 
> Offline - run 'make update-packages' first & specify source package and CVE 
> list:
>   --src SRC  Source package name to look up version in local packages 
> files
>   --cves [CVES ...]  CVE ID tag with version from local packages files
> 
> Data is written to a new .list file which can be used with 
> './bin/merge-cve-files'
> 
> 
> Examples:
> 
> ./bin/grab-cve-in-fix --src freerdp2 --cve CVE-2021-41160
> 
> ./bin/grab-cve-in-fix --tracker 
> https://tracker.debian.org/news/1285227/accepted-freerdp2-241dfsg1-1-source-into-unstable/
> 
> ./bin/grab-cve-in-fix --email 
> https://lists.debian.org/debian-devel-changes/2021/12/msg01280.html
> 
> (For these specific examples, data/CVE/list for CVE-2021-41160 would need to 
> be altered, say to , locally.)

Nice! I will need (or want) to try to experiment with it a bit on
apparing real cases.

Regards,
Salvatore

Bug#1001451: Candidate script

[Neil Williams]

https://salsa.debian.org/codehelp/security-tracker/-/commit/2df53b5421cde0c7b1b2dd3343d71aebde2d55b7

https://salsa.debian.org/codehelp/security-tracker/-/raw/grabcvefix/bin/grab-cve-in-fix

Dependencies: python3-debian

Usage: Download from the raw link as bin/grab-cve-in-fix and make it executable.

./bin/grab-cve-in-fix --help

usage: grab-cve-in-fix [-h] [[--email EMAIL] | [--tracker TRACKER]] | [[--src 
SRC] & [--cves [CVES ...]]]

Grab CVE data from a package upload for manual review

optional arguments:
  -h, --help show this help message and exit

Online - query either the distro-tracker or debian-devel-changes mail archive:
  --email EMAIL  URL of debian-devel-changes announcement in the list 
archive
  --tracker TRACKER  URL of tracker.debian.org 'Accepted NEWS' page for unstable

Offline - run 'make update-packages' first & specify source package and CVE 
list:
  --src SRC  Source package name to look up version in local packages 
files
  --cves [CVES ...]  CVE ID tag with version from local packages files

Data is written to a new .list file which can be used with 
'./bin/merge-cve-files'


Examples:

./bin/grab-cve-in-fix --src freerdp2 --cve CVE-2021-41160

./bin/grab-cve-in-fix --tracker 
https://tracker.debian.org/news/1285227/accepted-freerdp2-241dfsg1-1-source-into-unstable/

./bin/grab-cve-in-fix --email 
https://lists.debian.org/debian-devel-changes/2021/12/msg01280.html

(For these specific examples, data/CVE/list for CVE-2021-41160 would need to be 
altered, say to , locally.)



-- 
Neil Williams
=
https://linux.codehelp.co.uk/


pgpgLR2q2oFge.pgp
Description: OpenPGP digital signature

Bug#927899: ITP: cage -- A Wayland kiosk

[Birger Schacht]

Hi,

On 12/16/21 11:49, Johannes Schauer Marin Rodrigues wrote:

are you still interested in this package? Did you start with packaging it? I
saw the empty repo at https://salsa.debian.org/birger/cage and wanted to ask if
you already have an existing packaging somewhere and maybe just need somebody
to upload it to NEW?


Sorry for the delay, and thanks for nudging me, cage 0.1.4 is now in NEW ;)

cheers,
Birger


OpenPGP_0xCB06EA7B78DBE151.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#679905: 2021.8+ds2-1 - Pending

[Andrius Merkys]

Hi Neil,

On 2021-12-16 11:19, Neil Williams wrote:
> README.source:
> 
> cctbx for Debian
> 
> 
> CCTBX upstream does not manage SONAME versions, so a version is added
> in the Debian patches. This means that new upstream releases of cctbx
> should update the patch to cause a SONAME bump for all >100 cctbx
> libraries and a transition in the archive.

I see you have switched from having all libraries in cctbx/ subdirectory
[1] to public libs and libdevel locations. Personally I do think Debian
as a downstream should be setting SONAMEs. This does not seem to be
forbidden by the policy, but in case the upstream introduces SONAMEs,
clashes may occur. Moreover, caring for ABI compatibility is a lot of work.

On a separate thread, I managed to package reduce [2] locally. However,
as you have also noted it, the name of source, binary and executable is
problematic. Maybe it is worth trying to talk to upstream about renaming
it to avoid clashes.

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=679905#98
[2] https://github.com/rlabduke/reduce

Best,
Andrius

Bug#1001833: guix pull throws "match-error"

[alexander barakin (aka sash-kan)]

Package: guix
Version: 1.2.0-4
Severity: normal

Dear Maintainer,

i have installed package guix (1.2.0-4).
and try to run guix pull:

[code]
Updating channel 'guix' from Git repository at 
'https://git.savannah.gnu.org/git/guix.git'...
Building from this channel:
  guix  https://git.savannah.gnu.org/git/guix.git   b329c21
Backtrace:
   6 (apply-smob/1 #)
In ice-9/boot-9.scm:
705:2  5 (call-with-prompt _ _ #)
In ice-9/eval.scm:
619:8  4 (_ #(#(#)))
In guix/ui.scm:
  2117:12  3 (run-guix-command _ . _)
In ice-9/boot-9.scm:
829:9  2 (catch _ _ # …)
829:9  1 (catch _ _ # …)
829:9  0 (catch _ _ # …)

ice-9/boot-9.scm:829:9: In procedure catch:
Throw to key `match-error' with args `("match" "no matching pattern" (
#:re-export-and-replace (delete)
#:replace ((define-public* . define-public))
#:export (content-hash content-hash? content-hash-algorithm content-hash-value
origin origin? this-origin origin-uri origin-method origin-hash origin-sha256
origin-file-name origin-actual-file-name origin-patches origin-patch-flags
origin-patch-inputs origin-patch-guile origin-snippet origin-modules
base32 base64 package package? this-package package-name package-upstream-name
package-version package-full-name package-source package-build-system
package-arguments package-inputs package-native-inputs package-propagated-inputs
package-outputs package-native-search-paths package-search-paths 
package-replacement
package-synopsis package-description package-license package-home-page
package-supported-systems package-properties package-location
package-definition-location hidden-package hidden-package? package-superseded
deprecated-package package-field-location this-package-input 
this-package-native-input
lookup-package-input lookup-package-native-input lookup-package-propagated-input
lookup-package-direct-input prepend replace modify-inputs package-direct-sources
package-transitive-sources package-direct-inputs package-transitive-inputs
package-transitive-target-inputs package-transitive-native-inputs
package-transitive-propagated-inputs package-transitive-native-search-paths
package-transitive-supported-systems package-mapping package-input-rewriting
package-input-rewriting/spec package-source-derivation package-derivation
package-cross-derivation package-output package-grafts 
package-patched-vulnerabilities
package-with-patches package-with-extra-patches package-with-c-toolchain
package/inherit transitive-input-references %supported-systems %hurd-systems
%cuirass-supported-systems supported-package?  package-error?
package-error-package  package-input-error?
package-error-invalid-input 
package-cross-build-system-error? package->bag bag->derivation bag-direct-inputs
bag-transitive-inputs bag-transitive-host-inputs bag-transitive-build-inputs
bag-transitive-target-inputs package-development-inputs package-closure
default-guile default-guile-derivation set-guile-for-build package-file
package->derivation package->cross-derivation origin->derivation)))'.
[/code]

i was able to work around this error:
[code]
$ guix pull --branch=version-1.3.0
[/code]

but even after that I couldn't get updates from master:
[code]
$ guix pull
Updating channel 'guix' from Git repository at 
'https://git.savannah.gnu.org/git/guix.git'...
guix pull: error: aborting update of channel 'guix' to commit 
a9abb75dc87c0fe532905746912a39250d97293f, which is not a descendant of 
aa34d4d28dfe25ba47d5800d05000fb7221788c0
hint: This could indicate that the channel has been tampered with and is trying 
to force a roll-back,
preventing you from getting the latest updates.  If you think this is not the 
case, explicitly
allow non-forward updates.
[/code]

and this command generates exactly the same error as described at the beginning:
$ guix pull --allow-downgrades

as far as i understand, in order for "guix pull" to work,
it is necessary to update the guix and guile* packages.


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

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

Versions of packages guix depends on:
ii  guile-2.2   2.2.7+1-6
ii  guile-2.2-libs  2.2.7+1-6
ii  guile-gcrypt0.3.0-3
ii  guile-git   0.4.0-3
ii  guile-gnutls3.7.1-5
ii  guile-json  4.3.2-2
ii  guile-lzlib 0.0.2-2
ii  guile-sqlite3   0.1.3-2
ii  guile-ssh   0.13.1-4
ii  guile-zlib  0.0.1-3
ii  libbz2-1.0  1.0.8-4
ii  libc6   2.31-13+deb11u2
ii  libgcc-s1   10.2.1-6
ii  libgcrypt20 1.8.7-6
ii  libsqlite3-03.34.1-3
ii  libssh-dev  0.9.5-1+deb11u1
ii  libstdc++6  10.2.1-6
ii  zlib1g  1:1.2.11.dfsg-2

Versions of 

Bug#1001819: apt: how to set option lang to an empty list in sources.list?

[Julian Andres Klode]

On Thu, Dec 16, 2021 at 11:22:59PM +0100, Andreas Beckmann wrote:
> Source: apt
> Version: 2.3.13
> Severity: normal
> 
> Hi,
> 
> I'd like to disable downloading translations for a single package
> repository (which doesn't have them and therefore produces a lot of
> noise). Adding option '[ lang= ]' to the corresponding sources.list
> line seems the natural solution, but I cannot find any syntax that
> achieves my goal "do not download any translations for this repository"
> apt-get always errors out with some kind of "missing value".

If you lookup the Acquire::Languages mentioned in sources.list(5) in
apt.conf(5), you'll find that the correct answer is `lang=none`.

As always, empty means default, so not being able to set it is
irrelevant.
-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer  i speak de, en

Bug#1001832: mk-sbuild create error due to bullseye security move

[Nicholas Brown]

Package: ubuntu-dev-tools
Version: 0.183

Probably very similar to LP:1916633 reported and fixed in pbuilder-dist.
While using `mk-sbuild --name foobar bullseye`

```
E: The repository 'http://security.debian.org bullseye/updates Release'
does not have a Release file.
```

Bullseye changed the format of security suite:
https://www.debian.org/releases/bullseye/amd64/release-notes/ch-information.en.html#security-archive
and should look like:

```
deb https://deb.debian.org/debian-security bullseye-security main contrib
```

while mk-sbuild is still generating the older format as found in buster and
earlier:

```
deb http://security.debian.org/ bullseye/updates main non-free contrib
```
at this bit of the code:
https://git.launchpad.net/ubuntu/+source/ubuntu-dev-tools/tree/mk-sbuild#n661

Bug#1001453: limit scope as 1001451 will provide some parts

[Neil Williams]

Just to update the scope of this new support for the security-tracker,
this part is to be covered by 1001451

- mark CVE  as fixed in unstable in version 

e.g. ./bin/grab-cve-in-fix --src freerdp2 --cve CVE-2021-41159

(I'm just finalising a script for that bug.)

The grab-cve-in-fix support has parsers for different kinds of line
sources for the list of CVEs fixed in unstable by a particular upload.

I'll work on this bug to provide a helper along these lines:

- mark not-affected
- add bug number
- add a NOTE

Something like:

./bin/update-vuln --cve CVE-2021-41159 [--not-affected | --bug | --note]

Like grab-cve-in-fix, this would write out a file suitable for manual
review and merge using ./bin/merge-cve-files

-- 
Neil Williams
=
https://linux.codehelp.co.uk/


pgp4G2tbWMmn1.pgp
Description: OpenPGP digital signature

Bug#1001831: debhelper: RFC: Parse 'Rules-Requires-Root: no' in debian/control

[David (Plasma) Paul]

Package: debhelper
Version: 13.5.2
Severity: wishlist

Request For Comments


For the specific, special case where "Rules-Requires-Root: no" is
explicitly declared in debian/control of a source package which uses
debhelper and no overriding DEB_RULES_REQUIRES_ROOT environment variable
is set, dh_testroot ought to return successfully. In other words, for
such a source package, when all build dependencies are met, manually
executing
```
$ debian/rules binary
```
as a non-root user and without a DEB_RULES_REQUIRES_ROOT environment
variable set should result in a successful build of the associated
binary packages.

Debhelper already parses the "Build-Depends:" header in debian/control
for what compatibility level to use, so it should be trivial to
additionally parse the "Rules-Requires-Root:" header to check for this
special case. If, however, a DEB_RULES_REQUIRES_ROOT environment
variable is present (such as for testing purposes), its value should
take precedence, of course.

This proposed change would require a minor amendment to Debian Policy §
5.6.31, in particular a modification of the final sentence.

I believe that this change would be entirely backwards-compatible with
older build environment such as backports. I will no doubt be corrected
by you, dear reader, if this is not the case.

Links:

dh_testroot(1)
https://manpages.debian.org/bookworm/debhelper/dh_testroot.1

debhelper(7) § COMPATIBILITY LEVELS
https://manpages.debian.org/bookworm/debhelper/debhelper.7#COMPATIBILITY_LEVELS

RFC: Support for selective usage of (fake)root during package build (R³)
https://lists.debian.org/debian-devel/2017/10/msg00520.html

Debian Policy § 4.9.2  debian/rules and Rules-Requires-Root
https://www.debian.org/doc/debian-policy/ch-source.html#debian-rules-and-rules-requires-root

Debian Policy § 5.6.31  Rules-Requires-Root
https://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-rules-requires-root

-- 
Plasma

Bug#1001830: transition: libtorrent-rasterbar

[Christian Marillat]

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

Hi,

libtorrent-rasterbar 2.0.5 has been uploaded to unstable.

All reverse dependencies build fine.

btfs
deluge
nbdkit
qbittorrent
vlc-plugin-bittorrent


Ben file:

title = "libtorrent-rasterbar";
is_affected = .depends ~ "1.2.14-1.1" | .depends ~ "2.0.5-1";
is_good = .depends ~ "2.0.5-1";
is_bad = .depends ~ "1.2.14-1.1";