Bug#1000158: Samba panic and architecture

[Michael Tokarev]

Control: tag -1 + confirmed pending
Control: merge -1 1006935

24.05.2022 09:15, Jan Korbel wrote:

Hello.

We have many of samba panic/segfaults after upgrade to Deb11 -
standalone servers or domain members too. One of the biggest (hundreds
of users) with ~50 panic actions per day.


This is a well-known issue. Underlying prob is the random order of .o files in
the link command line, which, just bus a chance, resulted in i386 bullseye build
being broken. All it needs is a rebuild. I prepared a new bullseye release of
samba back in Apr (#1009726), it is waiting for the release team review.

For now you have a few options:

1. crossgrade to a 64bit system (you already know this one) - I highly
   suggest this anyway, unrelated to samba
2. install the bpo version of samba (4.16)
3. rebuild the bullseye version - just a rebuild, with a high probability,
   will get you a working samba

/mjt

Bug#1011508: needrestart-session : opens unwanted window

[Erwan David]

Package: needrestart-session
Version: 0.3-9
Severity: normal

needrestart-session used to work in text in the terminal where I started apt. 
Now it always open a new
window usually on another screen, and needs to be used with mouse instead of 
keyboard. It makes its
use particularly cumbersome when using a text mode package tools like apt. We 
need an option to get
former behavious in that case



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

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

Versions of packages needrestart-session depends on:
ii  adduser3.121
ii  libnet-dbus-perl   1.2.0-1+b2
ii  libproc-processtable-perl  0.634-1+b1
ii  libwx-perl 1:0.9932-6+b1
ii  needrestart3.6-1
ii  perl   5.34.0-4
ii  policykit-10.105-33
ii  wmctrl 1.07-7+b1

needrestart-session recommends no packages.

needrestart-session suggests no packages.

-- no debconf information

Bug#1011507: ITP: python-freesasa -- Python bindings for FreeSASA

[Andrius Merkys]

Package: wnpp
Owner: Andrius Merkys 
Severity: wishlist

* Package name: python-freesasa
  Version : 2.1.0
  Upstream Author : Simon Mitternacht
* URL : https://freesasa.github.io/python/
* License : Expat
  Programming Lang: Python
  Description : Python bindings for FreeSASA

The module provides Python bindings for the FreeSASA library. FreeSASA
calculates Solvent Accessible Surface Area (SASA) of biomolecules. By
default, Lee & Richards' algorithm is used, but Shrake & Rupley's is
also available. Both can be parameterized to arbitrary precision, and
for high resolution versions of the algorithms, the calculations give
identical results.

Remark: This package is to be maintained with Debian Python Team at
   https://salsa.debian.org/python-team/packages/python-freesasa

Bug#1011506: libpmemobj-cpp: FTBFS with onetbb/2021.5.0-9 in experimental

[Andrius Merkys]

Source: libpmemobj-cpp
Version: 1.13.0-3
Severity: normal
Tags: ftbfs

Hello,

tbb/onetbb transition (#1007222) is currently in the planning. During
test rebuild of libtbb-dev reverse dependencies with onetbb/2021.5.0-9
in experimental, current source failed to build with the following:

[ 14%] Building CXX object
tests/CMakeFiles/concurrent_hash_map_tbb_insert_lookup.dir/concurrent_hash_map/concurrent_hash_map_tbb_insert_lookup.cpp.o
cd /home/merkys/libpmemobj-cpp-1.13.0/obj-x86_64-linux-gnu/tests &&
/usr/bin/c++  -I/usr/include/valgrind
-I/home/merkys/libpmemobj-cpp-1.13.0/include
-I/home/merkys/libpmemobj-cpp-1.13.0/tests/common
-I/home/merkys/libpmemobj-cpp-1.13.0/tests/..
-I/home/merkys/libpmemobj-cpp-1.13.0/tests/. -g -O2
-ffile-prefix-map=/home/merkys/libpmemobj-cpp-1.13.0=.
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time
-D_FORTIFY_SOURCE=2 -DLIBPMEMOBJ_CPP_VG_MEMCHECK_ENABLED=1
-DLIBPMEMOBJ_CPP_VG_DRD_ENABLED=1 -DLIBPMEMOBJ_CPP_VG_HELGRIND_ENABLED=1
-Wall -Wpointer-arith -Wunused-macros -Wsign-conversion -Wsign-compare
-fno-common -Wno-maybe-uninitialized -std=gnu++14 -MD -MT
tests/CMakeFiles/concurrent_hash_map_tbb_insert_lookup.dir/concurrent_hash_map/concurrent_hash_map_tbb_insert_lookup.cpp.o
-MF
CMakeFiles/concurrent_hash_map_tbb_insert_lookup.dir/concurrent_hash_map/concurrent_hash_map_tbb_insert_lookup.cpp.o.d
-o
CMakeFiles/concurrent_hash_map_tbb_insert_lookup.dir/concurrent_hash_map/concurrent_hash_map_tbb_insert_lookup.cpp.o
-c
/home/merkys/libpmemobj-cpp-1.13.0/tests/concurrent_hash_map/concurrent_hash_map_tbb_insert_lookup.cpp
In file included from
/home/merkys/libpmemobj-cpp-1.13.0/tests/concurrent_hash_map/../concurrent_hash_map/concurrent_hash_map_test.hpp:26,
 from
/home/merkys/libpmemobj-cpp-1.13.0/tests/concurrent_hash_map/concurrent_hash_map_insert_lookup.cpp:9,
 from
/home/merkys/libpmemobj-cpp-1.13.0/tests/concurrent_hash_map/concurrent_hash_map_tbb_insert_lookup.cpp:11:
/home/merkys/libpmemobj-cpp-1.13.0/include/libpmemobj++/container/concurrent_hash_map.hpp:
In instantiation of 'bool pmem::obj::concurrent_hash_map::bucket_accessor::is_writer() const
[with Key = pmem::obj::p; T = pmem::obj::p; Hash =
std::hash >; KeyEqual =
std::equal_to >; MutexType =
pmem::obj::experimental::v;
ScopedLockType =
tbb::detail::d1::rw_scoped_lock]':
/home/merkys/libpmemobj-cpp-1.13.0/include/libpmemobj++/container/concurrent_hash_map.hpp:3235:25:
  required from 'bool pmem::obj::concurrent_hash_map::internal_erase(const K&) [with K =
pmem::obj::p; Key = pmem::obj::p; T = pmem::obj::p; Hash
= std::hash >; KeyEqual =
std::equal_to >; MutexType =
pmem::obj::experimental::v;
ScopedLockType =
tbb::detail::d1::rw_scoped_lock]'
/home/merkys/libpmemobj-cpp-1.13.0/include/libpmemobj++/container/concurrent_hash_map.hpp:2816:24:
  required from 'bool pmem::obj::concurrent_hash_map::erase(const Key&) [with Key =
pmem::obj::p; T = pmem::obj::p; Hash =
std::hash >; KeyEqual =
std::equal_to >; MutexType =
pmem::obj::experimental::v;
ScopedLockType =
tbb::detail::d1::rw_scoped_lock]'
/home/merkys/libpmemobj-cpp-1.13.0/tests/concurrent_hash_map/../concurrent_hash_map/concurrent_hash_map_test.hpp:363:26:
  required from here
/home/merkys/libpmemobj-cpp-1.13.0/include/libpmemobj++/container/concurrent_hash_map.hpp:1782:50:
error: cannot convert
'tbb::detail::d1::rw_scoped_lock::is_writer'
from type 'bool
(tbb::detail::d1::rw_scoped_lock::)()
const' to type 'bool'
 1782 | return bucket_lock_type::is_writer;
  |  ^
/home/merkys/libpmemobj-cpp-1.13.0/include/libpmemobj++/container/concurrent_hash_map.hpp:
In instantiation of 'pmem::obj::concurrent_hash_map::bucket_accessor::bucket_accessor(pmem::obj::concurrent_hash_map::bucket_accessor&&) [with
Key = pmem::obj::p; T = pmem::obj::p; Hash =
std::hash >; KeyEqual =
std::equal_to >; MutexType =
pmem::obj::experimental::v;
ScopedLockType =
tbb::detail::d1::rw_scoped_lock]':
/usr/include/c++/11/bits/stl_construct.h:119:7:   required from 'void
std::_Construct(_Tp*, _Args&& ...) [with _Tp =
pmem::obj::concurrent_hash_map, pmem::obj::p,
std::hash >, std::equal_to >,
pmem::obj::experimental::v,
tbb::detail::d1::rw_scoped_lock
>::bucket_accessor; _Args =
{pmem::obj::concurrent_hash_map, pmem::obj::p,
std::hash >, std::equal_to >,
pmem::obj::experimental::v,
tbb::detail::d1::rw_scoped_lock
>::bucket_accessor}]'
/usr/include/c++/11/bits/stl_uninitialized.h:92:18:   required from
'static _ForwardIterator
std::__uninitialized_copy<_TrivialValueTypes>::__uninit_copy(_InputIterator,
_InputIterator, _ForwardIterator) [with _InputIterator =
std::move_iterator,
pmem::obj::p, std::hash >,
std::equal_to >,
pmem::obj::experimental::v,
tbb::detail::d1::rw_scoped_lock
>::bucket_accessor*>; _ForwardIterator =
pmem::obj::concurrent_hash_map, pmem::obj::p,
std::hash >, std::equal_to >,
pmem::obj::experimental::v,
tbb::detail::d1::rw_scoped_lock
>::bucket_a

Bug#808419: MariaDB Feedback Plugin

[Otto Kekäläinen]

Hi!

Resurrecting this again and filed as
https://salsa.debian.org/mariadb-team/mariadb-server/-/merge_requests/16
with plan to merge it on 10.6 and upload to Debian soon.

Bug#1006457:

[Joey Pongallo]

I’m having the same issue. Firefox-esr runs with no issue, but no luck with chromium. I am using an orange pi zero 2 board with 3.0.0 Bullseye  on Linux 5.16.17-sun50iw9 Sent from Mail for Windows 

Bug#1011505: transition: gpgme1.0

[Daniel Kahn Gillmor]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
X-Debbugs-Cc: d...@fifthhorseman.net, delta...@debian.org

The only packages that need to be rebuilt against this soname bump are
part of KDE, specifically these binary packages:

 accountwizard
 kdepim-addons
 kget
 kleopatra
 kmail
 libkf5libkleo5
 libkf5mailcommon5abi2
 libkf5messagecomposer5abi1
 libkf5messagecore5abi1
 libkf5messageviewer5abi1
 libkf5mimetreeparser5abi1

These come from the following sources:

 kdepim-addons
 kf5-messagelib
 kget
 kleopatra
 kmail
 kmail-account-wizard
 libkf5libkleo
 libkf5mailcommon

Patrick Franz (in Cc) from the KDE team tested them and reported that
they build cleanly with an NMU (see attached message).

Release team, please ACK so i can proceed with the upload to unstable.

Regards,

--dkg


Ben file:

title = "gpgme1.0";
is_affected = .depends ~ "libqgpgme7" | .depends ~ "libqgpgme15";
is_good = .depends ~ "libqgpgme15";
is_bad = .depends ~ "libqgpgme7";
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20210112;
h=x-gm-message-state:from:to:subject:date:message-id:in-reply-to
 :references:mime-version:content-transfer-encoding;
bh=oeVrgfF5zWr7ctjic7dVLveRG26Sy0vaKyFu8vQ1Xpo=;
b=g4a5KhJl1Z86Zo5WyqUkuDiZzLvD2ag98UswCzkP/nG8i0tFIglylY0HD1SVg7N+2y
 r+vYb3xuRohGxwSPPZTBWEERpIzMXVwg0qVHdwjvpHWLV21T2OmEwB1r3iLcYHURIOZX
 0aIcaZwSFn7fXBhjYdXRllAi4UzBT87wgo5aTNbrgveYkmuETd2fWnlWt+rdXUnLZtWb
 yNFjOePrrp+2yAQl5vVLno5ljNwvoK3wkJNtPNqX3opWRJRvTKMod2tHXNa1lCVZ86rn
 LXGtxd7EWsVYfTPfJEHFac2ApJpF8PDR1qII9qxXVsKzMrUG0g1RmfCg+D4fCPWgSPlU
 VTuw==
X-Gm-Message-State: AOAM5316WPFtNxI4QQZw4IxqiNBw7n9VbWHLp6yREKH7KwRzmsmJgmWp
gJPDL3BGOlXPpHuJIBOiJQc=
X-Google-Smtp-Source: 
ABdhPJxtTiLSLkyyEU6xbiBlvNXUhN9FH1qGtHs3aTU30OPqODvCX44FW7qW+5V2/w40TEvQxue0Tw==
X-Received: by 2002:a2e:a5ca:0:b0:253:c604:647c with SMTP id 
n10-20020a2ea5ca00b00253c604647cmr11071204ljp.403.1653237143884;
Sun, 22 May 2022 09:32:23 -0700 (PDT)
Received: from delta-one.localnet (217-210-33-15-no2104.tbcn.telia.com. 
[217.210.33.15])
by smtp.gmail.com with ESMTPSA id 
bi23-20020a05651c231700b00253dfbe2522sm1080181ljb.100.2022.05.22.09.32.22
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
Sun, 22 May 2022 09:32:23 -0700 (PDT)
From: Patrick Franz 
To: debian-qt-...@lists.debian.org, Daniel Kahn Gillmor 
Subject: Re: rebuilding against libqgpgme-dev (soname bump from libqgpgme7 to 
libqgpgme15)
Date: Sun, 22 May 2022 18:32:21 +0200
Message-ID: <1831765.tdWV9SEqCh@delta-one>
In-Reply-To: <87zgjbficl@fifthhorseman.net>
References: <87zgjbficl@fifthhorseman.net>
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"
Received-SPF: pass (srs.pair.com ... _spfmailwash.pair.com: 209.68.5.116 is 
authorized to use 'SRS0=GHde=V6=gmail.com=deltaone.deb...@srs.pair.com' in 
'mfrom' identity (mechanism 'ip4:209.68.0.0/18' matched)) 
receiver=mailwash52.pair.com; identity=mailfrom; 
envelope-from="SRS0=GHde=V6=gmail.com=deltaone.deb...@srs.pair.com"; 
helo=itihasa.pair.com; client-ip=209.68.5.116
X-Virus-Check-By: mailwash52.pair.com
X-Scanned-By: mailmunge 3.07 on 66.39.2.52
Delivered-To: d...@fifthhorseman.net
X-Scanned-By: mailmunge 3.07 on 66.39.2.52
Delivered-To: daniel_gill...@fifthhorseman.net
X-Envelope-To: daniel_gill...@fifthhorseman.net

Hi Daniel,

Am Samstag, 21. Mai 2022, 09:35:54 CEST schrieb Daniel Kahn Gillmor:
> I think the following 8 source packages will need a rebuild:
>=20
> kdepim-addons
> kf5-messagelib
> kget
> kleopatra
> kmail
> kmail-account-wizard
> libkf5libkleo
> libkf5mailcommon
>=20
> Let me know what you think is a good plan here,

I rebuilt those packages against gpgme 1.17 in experimental and all of=20
them built successfully without the need of adjusting anything.

So I'd suggest you simply request a transition and state that all these=20
packages build against gpgme 1.17 and only need NMUs.


=2D-=20
Med v=C3=A4nliga h=C3=A4lsningar

Patrick Franz

Bug#1011504: Subject: ITP: deepin-image-editor -- Image editor is a public library for deepin-image-viewer and deepin-album developed by Deepin Technology.

[Aiguo Ma]

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

* Package name: deepin-image-editor
  Version : 1.0.13
  Upstream Author : Deepin Technology Co., Ltd.
* URL : https://github.com/linuxdeepin/image-editor
* License : GPLv3.
  Programming Lang: C++
  Description : Image editor is a public library for
deepin-image-viewer and deepin-album developed by Deepin Technology.

I intend to co-maintain this package inside pkg-deepin team.

Bug#1011503: libapache2-mod-auth-plain: reproducible-builds: embedded build paths in mod_auth_plain.so

[Vagrant Cascadian]

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

The build path is embedded in
/usr/lib/apache2/modules/mod_auth_plain.so:

  
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/libapache2-mod-auth-plain.html

  /build/1st/libapache2-mod-auth-plain-2.0.52/mod_auth_plain.c:300
  vs.
  /build/2/libapache2-mod-auth-plain-2.0.52/2nd/mod_auth_plain.c:300

The attached patch fixes this by adjusting the Makefile to pass
-ffile-prefix-map to apxs, which avoids embedding the build path in
compiled files.


With this patch applied, libapache2-mod-auth-plain should build
reproducibly on tests.reproducible-builds.org!


live well,
  vagrant
From 0bbea871a8c744f1355c759482efbc4eb9f927b5 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Tue, 24 May 2022 01:58:43 +
Subject: [PATCH] Makefile: Pass -ffile-prefix-map to apxs.

This avoids embedding the build path in the binaries.

https://reproducible-builds.org/docs/build-path/
---
 Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Makefile b/Makefile
index a05afd4..343b1bb 100644
--- a/Makefile
+++ b/Makefile
@@ -11,7 +11,7 @@ all: $(TARGETS)
 
 # general rule to build
 %.la: %.c
-	$(APXS) -c $< $(LIBS)
+	$(APXS) -Wc,-ffile-prefix-map=$(CURDIR)=. -c $< $(LIBS)
 
 install: $(TARGETS)
 	$(APXS) -i $(TARGETS)
-- 
2.36.1



signature.asc
Description: PGP signature

Bug#1011502: codeblocks: ftbfs on riscv64 arch (error: #error "Unknown CPU architecture")

[Bo YU]

Source: codeblocks
Version: 20.03-3.1
Severity: normal
Tags: ftbfs, patch
User: debian-ri...@lists.debian.org
Usertags: riscv64
X-Debbugs-Cc: debian-ri...@lists.debian.org

Dear Maintainer,

The codeblocks package has a ftbfs issue on riscv64 arch:

```
libtool: compile:  g++ -DHAVE_CONFIG_H -I. -I../../src/include 
-I/usr/lib/riscv64-linux-gnu/wx/include/gtk3-unicode-3.0 -I/usr/include/wx-3.0 -D_FILE_OFFSET_BITS=64 
-DWXUSINGDLL -D__WXGTK__ -pthread -I/usr/include/glib-2.0 -I/usr/lib/riscv64-linux-gnu/glib-2.0/include 
-I../../src/include/scripting/include -I../../src/include -I../../src/sdk/wxscintilla/include 
-I../../src/include/scripting/bindings -I../../src/include/scripting/sqplus -I../../src/include/mozilla_chardet 
-I../../src/include/mozilla_chardet/mfbt -I../../src/include/mozilla_chardet/nsprpub/pr/include 
-I../../src/include/mozilla_chardet/xpcom -I../../src/include/mozilla_chardet/xpcom/base 
-I../../src/include/mozilla_chardet/xpcom/glue -DCB_AUTOCONF -Wdate-time -D_FORTIFY_SOURCE=2 -DNDEBUG 
-DBUILD_DATE=\"2021-11-08\" -DBUILD_TIME=\"13:51:13\" -DCB_PRECOMP -DPIC -g -O2 
-ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security 
-std=gnu++14 -Winvalid-pch -fPIC -fexceptions -c mozilla_chardet/src/nsCharSetProber.cpp  -fPIC -DPIC -o 
mozilla_chardet/src/.libs/nsCharSetProber.o
In file included from 
../../src/include/mozilla_chardet/nsprpub/pr/include/prcpucfg.h:40,
from 
../../src/include/mozilla_chardet/nsprpub/pr/include/prtypes.h:26,
from 
../../src/include/mozilla_chardet/nsprpub/pr/include/prmem.h:14,
from mozilla_chardet/src/nsCharSetProber.cpp:7:
../../src/include/mozilla_chardet/nsprpub/pr/include/prcpucfg_linux.h:919:2: error: 
#error "Unknown CPU architecture"
 919 | #error "Unknown CPU architecture"
 |  ^
In file included from 
../../src/include/mozilla_chardet/nsprpub/pr/include/prmem.h:14,
from mozilla_chardet/src/nsCharSetProber.cpp:7:
../../src/include/mozilla_chardet/nsprpub/pr/include/prtypes.h:263:2: error: 
#error No suitable type for PRInt8/PRUint8
...
```
The full buildd log is here:
https://buildd.debian.org/status/fetch.php?pkg=codeblocks&arch=riscv64&ver=20.03-3.1&stamp=1636403405&raw=0

The patch attached is to fix the issue and it is ok to build on riscv64:

```
Build Architecture: riscv64
Build Type: binary
Build-Space: 4754304
Build-Time: 10228
Distribution: unstable
Host Architecture: riscv64
Install-Time: 198
Job: /home/vimer/05/30_codeblocks/codeblocks_20.03-3.1.dsc
Lintian: warn
Machine Architecture: riscv64
Package: codeblocks
Package-Time: 10545
Source-Version: 20.03-3.1
Space: 4754304
Status: successful
Version: 20.03-3.1
```
Please consider to apply it in next upload, thank you~

BTW, I am fail to register account for codeblacks on 
https://forums.codeblocks.org/index.php/board,7.0.html
to forward the patch for them. Please to let them know 
if it is convenient for you. thanks again~


Bo

--
Best Regards,

fix ftbfs on riscv64 arch.

refer to:

https://openbsdmailbox.blogspot.com/2022/04/let-codeblocks-build-on-riscv64.html
--- a/src/include/mozilla_chardet/nsprpub/pr/include/prcpucfg_linux.h
+++ b/src/include/mozilla_chardet/nsprpub/pr/include/prcpucfg_linux.h
@@ -643,6 +643,52 @@
 #define PR_BYTES_PER_WORD_LOG2  3
 #define PR_BYTES_PER_DWORD_LOG2 3
 
+#elif defined(__riscv) && __riscv_xlen == 64
+
+#define IS_LITTLE_ENDIAN 1
+#undef IS_BIG_ENDIAN
+#define IS_64
+
+#define PR_BYTES_PER_BYTE 1
+#define PR_BYTES_PER_SHORT 2
+#define PR_BYTES_PER_INT 4
+#define PR_BYTES_PER_INT64 8
+#define PR_BYTES_PER_LONG 8
+#define PR_BYTES_PER_FLOAT 4
+#define PR_BYTES_PER_DOUBLE 8
+#define PR_BYTES_PER_WORD 8
+#define PR_BYTES_PER_DWORD 8
+
+#define PR_BITS_PER_BYTE 8
+#define PR_BITS_PER_SHORT 16
+#define PR_BITS_PER_INT 32
+#define PR_BITS_PER_INT64 64
+#define PR_BITS_PER_LONG 64
+#define PR_BITS_PER_FLOAT 32
+#define PR_BITS_PER_DOUBLE 64
+#define PR_BITS_PER_WORD 64
+
+#define PR_BITS_PER_BYTE_LOG2 3
+#define PR_BITS_PER_SHORT_LOG2 4
+#define PR_BITS_PER_INT_LOG2 5
+#define PR_BITS_PER_INT64_LOG2 6
+#define PR_BITS_PER_LONG_LOG2 6
+#define PR_BITS_PER_FLOAT_LOG2 5
+#define PR_BITS_PER_DOUBLE_LOG2 6
+#define PR_BITS_PER_WORD_LOG2 6
+
+#define PR_ALIGN_OF_SHORT 2
+#define PR_ALIGN_OF_INT 4
+#define PR_ALIGN_OF_LONG 8
+#define PR_ALIGN_OF_INT64 8
+#define PR_ALIGN_OF_FLOAT 4
+#define PR_ALIGN_OF_DOUBLE 8
+#define PR_ALIGN_OF_POINTER 8
+#define PR_ALIGN_OF_WORD 8
+
+#define PR_BYTES_PER_WORD_LOG2 3
+#define PR_BYTES_PER_DWORD_LOG2 3
+
 #elif defined(__hppa__)
 
 #undef  IS_LITTLE_ENDIAN


signature.asc
Description: PGP signature

Bug#993308: firefox-esr: You might need to add a libpci3 dependency to ESR 91

[Thorsten Glaser]

Package: firefox-esr
Version: 91.9.1esr-1~deb11u1
Followup-For: Bug #993308
X-Debbugs-Cc: t...@mirbsd.de

This seems to indeed be required now, but not caught by
dpkg-shlibdeps as (web searches indicate at least) it’s
dlopened.


-- Package-specific info:

-- Extensions information
Name: Amazon.co.uk
Location: /usr/lib/firefox-esr/browser/omni.ja
Package: firefox-esr
Status: enabled

Name: Bing
Location: /usr/lib/firefox-esr/browser/omni.ja
Package: firefox-esr
Status: enabled

Name: Dark theme
Location: /usr/lib/firefox-esr/browser/omni.ja
Package: firefox-esr
Status: user-disabled

Name: DoH Roll-Out
Location: /usr/lib/firefox-esr/browser/features/doh-roll...@mozilla.org.xpi
Package: firefox-esr
Status: enabled

Name: DuckDuckGo
Location: /usr/lib/firefox-esr/browser/omni.ja
Package: firefox-esr
Status: enabled

Name: Firefox Alpenglow theme
Location: /usr/lib/firefox-esr/browser/omni.ja
Package: firefox-esr
Status: user-disabled

Name: Firefox Screenshots
Location: /usr/lib/firefox-esr/browser/features/screensh...@mozilla.org.xpi
Package: firefox-esr
Status: enabled

Name: Form Autofill
Location: /usr/lib/firefox-esr/browser/features/formautof...@mozilla.org.xpi
Package: firefox-esr
Status: enabled

Name: Google
Location: /usr/lib/firefox-esr/browser/omni.ja
Package: firefox-esr
Status: enabled

Name: Light theme
Location: /usr/lib/firefox-esr/browser/omni.ja
Package: firefox-esr
Status: user-disabled

Name: Picture-In-Picture
Location: /usr/lib/firefox-esr/browser/features/pictureinpict...@mozilla.org.xpi
Package: firefox-esr
Status: enabled

Name: Proxy Failover
Location: /usr/lib/firefox-esr/browser/features/proxy-failo...@mozilla.com.xpi
Package: firefox-esr
Status: enabled

Name: System theme theme
Location: /usr/lib/firefox-esr/omni.ja
Package: firefox-esr
Status: enabled

Name: Web Compatibility Interventions
Location: /usr/lib/firefox-esr/browser/features/webcom...@mozilla.org.xpi
Package: firefox-esr
Status: enabled

Name: WebCompat Reporter
Location: 
/usr/lib/firefox-esr/browser/features/webcompat-repor...@mozilla.org.xpi
Package: firefox-esr
Status: user-disabled

Name: Wikipedia (en)
Location: /usr/lib/firefox-esr/browser/omni.ja
Package: firefox-esr
Status: enabled


-- Addons package information
ii  firefox-esr91.9.1esr-1~deb11u1 amd64Mozilla Firefox web browser 
- Extended Support Release (ESR)

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

Kernel: Linux 5.10.0-14-amd64 (SMP w/2 CPU threads)
Locale: LANG=C, LC_CTYPE=C (charmap=UTF-8) (ignored: LC_ALL set to C.UTF-8), 
LANGUAGE not set
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

Versions of packages firefox-esr depends on:
ii  debianutils  4.11.2
ii  fontconfig   2.13.1-4.2
ii  libatk1.0-0  2.36.0-2
ii  libc62.31-13+deb11u3
ii  libcairo-gobject21.16.0-5
ii  libcairo21.16.0-5
ii  libdbus-1-3  1.12.20-2
ii  libdbus-glib-1-2 0.110-6
ii  libevent-2.1-7   2.1.12-stable-1
ii  libffi7  3.3-6
ii  libfontconfig1   2.13.1-4.2
ii  libfreetype6 2.10.4+dfsg-1
ii  libgcc-s110.2.1-6
ii  libgdk-pixbuf-2.0-0  2.42.2+dfsg-1
ii  libglib2.0-0 2.66.8-1
ii  libgtk-3-0   3.24.24-4+deb11u2
ii  libpango-1.0-0   1.46.2-3
ii  libstdc++6   10.2.1-6
ii  libvpx6  1.9.0-1
ii  libx11-6 2:1.7.2-1
ii  libx11-xcb1  2:1.7.2-1
ii  libxcb-shm0  1.14-3
ii  libxcb1  1.14-3
ii  libxcomposite1   1:0.4.5-1
ii  libxdamage1  1:1.1.5-2
ii  libxext6 2:1.3.3-1.1
ii  libxfixes3   1:5.0.3-2
ii  libxrender1  1:0.9.10-1
ii  procps   2:3.3.17-5
ii  zlib1g   1:1.2.11.dfsg-2+deb11u1

Versions of packages firefox-esr recommends:
ii  libavcodec58  7:4.3.4-0+deb11u1

Versions of packages firefox-esr suggests:
pn  fonts-lmodern  
pn  fonts-stix | otf-stix  
pn  libcanberra0   
ii  libgssapi-krb5-2   1.18.3-6+deb11u1
pn  pulseaudio 

-- no debconf information

Bug#1011501: libapache2-mod-authn-yubikey: reproducible-builds: embedded build paths in mod_authn_yubikey.so

[Vagrant Cascadian]

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

The build path is embedded in
/usr/lib/apache2/modules/mod_authn_yubikey.so:

  
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/libapache2-mod-authn-yubikey.html

  /build/1st/libapache2-mod-authn-yubikey-1.0/libykclient.c:181
  vs.
  /build/2/libapache2-mod-authn-yubikey-1.0/2nd/libykclient.c:181

The attached patch fixes this by passing -ffile-prefix-map to axps2 in
debian/rules, which avoids embedding the build path in compiled files.


With this patch applied, libapache2-mod-authn-yubikey should build
reproducibly on tests.reproducible-builds.org!


live well,
  vagrant
From a8ba18601d147f1b4e374e2b483561f95373b561 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Tue, 24 May 2022 00:55:12 +
Subject: [PATCH] debian/rules: Pass -ffile-prefix-map to apxs2.

---
 debian/rules | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/rules b/debian/rules
index 1e96143..cab1069 100755
--- a/debian/rules
+++ b/debian/rules
@@ -4,6 +4,6 @@
 
 override_dh_auto_build:
 	apxs2 -DYK_PACKAGE=\\\"libapache2_mod_authn_yubikey\\\" \
-		-DYK_PACKAGE_VERSION=\\\"0.1\\\" -I. -Wc -c -lcurl \
+		-DYK_PACKAGE_VERSION=\\\"0.1\\\" -I. -Wc,-ffile-prefix-map=$(CURDIR)=. -Wc -c -lcurl \
 		mod_authn_yubikey.c libykclient.c libykclient.slo mod_authn_yubikey.slo
 
-- 
2.36.1



signature.asc
Description: PGP signature

Bug#1011500: tuxcmd-modules: reproducible-builds: embedded build paths in various binaries

[Vagrant Cascadian]

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

The build path is embedded in various binaries in /usr/lib:

  
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/tuxcmd-modules.html

  /usr/lib/tuxcmd/libarchive_plugin.so

  /build/1st/tuxcmd-modules-0.6.70+ds/libarchive/strutils.c:27
  vs.
  /build/2/tuxcmd-modules-0.6.70+ds/2nd/libarchive/strutils.c:27

The attached patch fixes this by adjusting various Makefiles to set
-ffile-prefix-map in CFLAGS, which avoids embedding the build path in
the compiled binaries.


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


live well,
  vagrant
From 0bd222e5cf0c9710c97c217fce4d0435cee989bc Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Tue, 24 May 2022 00:39:56 +
Subject: [PATCH] Support passing -ffile-prefix-map in various Makefiles.

This avoids embedding the build path in the resulting binaries.

https://reproducible-builds.org/docs/build-path/
---
 Makefile| 2 ++
 gvfs/Makefile   | 2 ++
 libarchive/Makefile | 3 +++
 zip/Makefile| 2 ++
 zip/Makefile.ziparch| 3 +++
 zip/ZipArchive/Makefile | 3 +++
 6 files changed, 15 insertions(+)

diff --git a/Makefile b/Makefile
index 61dade4..2d78375 100644
--- a/Makefile
+++ b/Makefile
@@ -1,5 +1,7 @@
 SUBDIRS = zip libarchive gvfs
 
+export BUILDPATH = $(CURDIR)
+
 all install clean shared static::
 	target=`echo $@ | sed s/-recursive//`; \
 	list='$(SUBDIRS)'; for subdir in $$list; do \
diff --git a/gvfs/Makefile b/gvfs/Makefile
index 9c5d759..8bd0c08 100644
--- a/gvfs/Makefile
+++ b/gvfs/Makefile
@@ -9,6 +9,8 @@ CFLAGS =-I. -I/usr/include \
 	-Wall -fPIC -O2 -g \
 	-DG_DISABLE_DEPRECATED -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_GNU_SOURCE
 
+# Avoid embedding build path
+CFLAGS += -ffile-prefix-map=$(BUILDPATH)=.
 
 # VFS_COMMON_OBJECTS=strutils.o treepathutils.o treepath_vfs.o vfsutils.o
 VFS_COMMON_OBJECTS=
diff --git a/libarchive/Makefile b/libarchive/Makefile
index 8514968..db3c1b5 100644
--- a/libarchive/Makefile
+++ b/libarchive/Makefile
@@ -13,6 +13,9 @@ CFLAGS =-I. -I/usr/include -I$(DIR_COMMON) \
 	-DG_DISABLE_DEPRECATED -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_GNU_SOURCE \
 	-D__VERBOSE_DEBUGx
 
+# Avoid embedding build path
+CFLAGS += -ffile-prefix-map=$(BUILDPATH)=.
+
 VFS_COMMON_OBJECTS=strutils.o treepathutils.o treepath_vfs.o vfsutils.o
 
 VFS_OBJECTS=libarchive.o
diff --git a/zip/Makefile b/zip/Makefile
index 1299323..5d32373 100644
--- a/zip/Makefile
+++ b/zip/Makefile
@@ -12,6 +12,8 @@ CFLAGS =-I. -I$(DIR_ZIPARCHIVE) -I/usr/include \
 	-DG_DISABLE_DEPRECATED -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_GNU_SOURCE \
 	-D__VERBOSE_DEBUGx
 
+# Avoid embedding build path
+CFLAGS += -ffile-prefix-map=$(BUILDPATH)=.
 
 VFS_COMMON_OBJECTS=strutils.o treepathutils.o treepath_vfs.o vfsutils.o
 
diff --git a/zip/Makefile.ziparch b/zip/Makefile.ziparch
index 2a66b94..ab8db23 100644
--- a/zip/Makefile.ziparch
+++ b/zip/Makefile.ziparch
@@ -19,6 +19,9 @@ CCC=cc
 CFLAGS = -D ZIP_ARCHIVE_LNX -fPIC -g -O2
 #CFLAGS =
 
+# Avoid embedding build path
+CFLAGS += -ffile-prefix-map=$(BUILDPATH)=.
+
 ifdef INTERNAL_BZIP2
 CFLAGS += -D ZIP_ARCHIVE_BZIP2_INTERNAL 
 endif
diff --git a/zip/ZipArchive/Makefile b/zip/ZipArchive/Makefile
index a426b6d..627b036 100644
--- a/zip/ZipArchive/Makefile
+++ b/zip/ZipArchive/Makefile
@@ -23,6 +23,9 @@ ifdef INTERNAL_BZIP2
 CFLAGS += -D ZIP_ARCHIVE_BZIP2_INTERNAL
 endif
 
+# Avoid embedding build path
+CFLAGS += -ffile-prefix-map=$(BUILDPATH)=.
+
 ZIPARCHLIB = libziparch.a
 
 ZIPPIELOCATION = ../Zippie/
-- 
2.36.1



signature.asc
Description: PGP signature

Bug#1011499: imagination: reproducible-builds: embedded build paths in various binaries

[Vagrant Cascadian]

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

The build path is embedded in various binaries:

  
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/imagination.html

  /usr/bin/imagination

  /build/1st/imagination-3.6/src/imgcellrendereranim.c:63
  vs.
  /build/2/imagination-3.6/2nd/src/imgcellrendereranim.c:63

The attached patch fixes this by explicitly passing CFLAGS to a
dh_auto_build override in debian/rules, which includes the
-ffile-prefix-map argument used to avoid embedding build paths.


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


live well,
  vagrant
From 01273015daccd5f14d9cf37b06909702f83da0a1 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Tue, 24 May 2022 00:17:51 +
Subject: [PATCH] debian/rules: Explicitly pass CFLAGS via dh_auto_build
 override.

---
 debian/rules | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/debian/rules b/debian/rules
index e2eadfe..e6cdda4 100755
--- a/debian/rules
+++ b/debian/rules
@@ -14,3 +14,6 @@ export DEB_BUILD_MAINT_OPTIONS = hardening=+all
 override_dh_gencontrol:
 	dh_gencontrol -pimagination -- $(SUBSTVARS)
 	dh_gencontrol -pimagination-common
+
+override_dh_auto_build:
+	dh_auto_build -- CFLAGS="$(CFLAGS)"
-- 
2.36.1



signature.asc
Description: PGP signature

Bug#1011467: perltidy: Newer upstream release available

[Don Armstrong]

On Mon, 23 May 2022, gregor herrmann wrote:
> Could you upgrade the package to 20220217 and/or shall we move it to
> the Debian Perl Group?

I'm happy with either. It's pretty trivial to package new releases
(though I probably won't get to this one until tomorrow).


-- 
Don Armstrong  https://www.donarmstrong.com

Love is... a complex sequence of neurochemical reactions that makes
people behave like idiots. It's similar to intoxication, but the
hangover's even worse.
 -- J. Jacques _Questionable Content_ #1039
http://www.questionablecontent.net/view.php?comic=1039

Bug#1011498: parprouted: reproducible-builds: embedded build paths in /usr/sbin/parprouted

[Vagrant Cascadian]

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

The build path is embedded in /usr/sbin/parprouted:

  
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/parprouted.html

  /build/1st/parprouted-0.70/parprouted.c:388
  vs.
  /build/2/parprouted-0.70/2nd/parprouted.c:388

The attached patch fixes this by passing CFLAGS via EXTRA_CFLAGS in a
dh_auto_build override in debian/rules.  This allows passing the default
build flags including -ffile-prefix-map, which avoids embedding the
absolute path in compiled files.


With these patches applied, parprouted should build reproducibly on
tests.reproducible-builds.org!


live well,
  vagrant
From 8f89bcf5ceb969296c3e80ca5dd5ed094557b2ae Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Mon, 23 May 2022 23:36:01 +
Subject: [PATCH] debian/rules: Pass CFLAGS via EXTRA_CFLAGS in dh_auto_build
 override.

---
 debian/rules | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/debian/rules b/debian/rules
index bf7a709..2173a20 100755
--- a/debian/rules
+++ b/debian/rules
@@ -21,3 +21,6 @@ include /usr/share/dpkg/buildflags.mk
 
 %:
 	dh $@ 
+
+override_dh_auto_build:
+	dh_auto_build -- EXTRA_CFLAGS="$(CFLAGS)"
-- 
2.36.1



signature.asc
Description: PGP signature

Bug#1011497: xserver-xorg: Segfault in OsLookupColor when drawing lines in Inkscape

[Mateusz Latusek]

Package: xserver-xorg
Version: 1:7.7+22
Severity: important
X-Debbugs-Cc: mat...@matlibhax.com

Dear Maintainer,

Server crashes when drawing a line in Inkscape. It's 100% replicable: it
happens every time on first click.

It used to work some weeks ago.

-- Package-specific info:
/etc/X11/X does not exist.
/etc/X11/X is not a symlink.
/etc/X11/X is not executable.

VGA-compatible devices on PCI bus:
--
00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile 
GM965/GL960 Integrated Graphics Controller (primary) [8086:2a02] (rev 0c)


/etc/X11/xorg.conf does not exist.

Contents of /etc/X11/xorg.conf.d:
-
total 0

/etc/modprobe.d contains no KMS configuration files.

Kernel version (/proc/version):
---
Linux version 5.10.0-14-amd64 (debian-ker...@lists.debian.org) (gcc-10 
(Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 
2.35.2) #1 SMP Debian 5.10.113-1 (2022-04-29)


Xorg X server log files on system:
--
-rw-r--r-- 1 root root 45159 May 23 22:49 /var/log/Xorg.0.log

Contents of most recent Xorg X server log file (/var/log/Xorg.0.log):
-
[19.706] X.Org X Server 1.20.11
X Protocol Version 11, Revision 0
[19.706] Build Operating System: linux Debian
[19.706] Current Operating System: Linux notek 5.10.0-14-amd64 #1 
SMP Debian 5.10.113-1 (2022-04-29) x86_64
[19.706] Kernel command line: auto BOOT_IMAGE=Linux ro 
root=/dev/mapper/notek-root net.ifnames=0

[19.706] Build Date: 16 December 2021  05:08:23PM
[19.706] xorg-server 2:1.20.11-1+deb11u1 
(https://www.debian.org/support) [19.706] Current version of pixman: 
0.40.0

[19.706]Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
[19.706] Markers: (--) probed, (**) from config file, (==) default 
setting,

(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[19.706] (==) Log file: "/var/log/Xorg.0.log", Time: Mon May 23 
22:48:53 2022

[19.711] (==) Using system config directory "/usr/share/X11/xorg.conf.d"
[19.713] (==) No Layout section.  Using the first Screen section.
[19.713] (==) No screen section available. Using defaults.
[19.713] (**) |-->Screen "Default Screen Section" (0)
[19.713] (**) |   |-->Monitor ""
[19.715] (==) No monitor specified for screen "Default Screen Section".
Using a default monitor configuration.
[19.715] (==) Automatically adding devices
[19.715] (==) Automatically enabling devices
[19.715] (==) Automatically adding GPU devices
[19.715] (==) Max clients allowed: 256, resource mask: 0x1f
[19.719] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not 
exist.

[19.719]Entry deleted from font path.
[19.724] (==) FontPath set to:
/usr/share/fonts/X11/misc,
/usr/share/fonts/X11/100dpi/:unscaled,
/usr/share/fonts/X11/75dpi/:unscaled,
/usr/share/fonts/X11/Type1,
/usr/share/fonts/X11/100dpi,
/usr/share/fonts/X11/75dpi,
built-ins
[19.724] (==) ModulePath set to "/usr/lib/xorg/modules"
[19.724] (II) The server relies on udev to provide the list of input 
devices.

If no devices become available, reconfigure udev or disable 
AutoAddDevices.
[19.724] (II) Loader magic: 0x560e2e820e40
[19.724] (II) Module ABI versions:
[19.724]X.Org ANSI C Emulation: 0.4
[19.724]X.Org Video Driver: 24.1
[19.724]X.Org XInput driver : 24.1
[19.724]X.Org Server Extension : 10.0
[19.725] (EE) dbus-core: error connecting to system bus: 
org.freedesktop.DBus.Error.FileNotFound (Failed to connect to socket 
/run/dbus/system_bus_socket: No such file or directory)

[19.725] (++) using VT number 7

[19.725] (II) systemd-logind: logind integration requires -keeptty 
and -keeptty was not provided, disabling logind integration

[19.725] (II) xfree86: Adding drm device (/dev/dri/card0)
[19.736] (--) PCI:*(0@0:2:0) 8086:2a02:17aa:20b5 rev 12, Mem @ 
0xf810/1048576, 0xe000/268435456, I/O @ 0x1800/8, BIOS @ 
0x/131072
[19.736] (--) PCI: (0@0:2:1) 8086:2a03:17aa:20b5 rev 12, Mem @ 
0xf820/1048576

[19.737] (II) LoadModule: "glx"
[19.740] (II) Loading /usr/lib/xorg/modules/extensions/libglx.so
[19.790] (II) Module glx: vendor="X.Org Foundation"
[19.790]compiled for 1.20.11, module version = 1.0.0
[19.790]ABI class: X.Org Server Extension, version 10.0
[19.791] (==) Matched modesetting as autoconfigured driver 0
[19.791] (==) Matched fbdev as autoconfigured driver 1
[19.791] (==) Matched vesa as autoconfigured driver 2
[19.791] (==) Assigned the driver to the xf86ConfigLayout
[19.791] (II) LoadModule: "mod

Bug#988540: im-config: breaks the keyboard configuration

[Osamu Aoki]

Hi,

> -Original Message-
> From: Osamu Aoki 

...

> Users may no longer be able to use xterm **reliably for some non-ASCII 
> inputs**
> when
> ibus is **activated**.
> 

I thought about this issue over combination of pure-X GUI and ibus for 
non-terminal
programs.  gitk (TK based) and emacs-lucid (X, lucid based) may be popular 
program in
this category.  I updated contents on them:
  https://wiki.debian.org/Keyboard#Input_method_and_XIM

FYI: Next upload of debian-reference will list ibus-keyman

Regards,

Osamu

Bug#1011496: nwall: reproducible-builds: embedded build paths in /usr/bin/nwall

[Vagrant Cascadian]

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

The build path is embedded in /usr/bin/nwall:

  
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/nwall.html

  /build/1st/nwall-1.32+debian/src/nwall.c:65
  vs.
  /build/2/nwall-1.32+debian/2nd/src/nwall.c:65

The attached patch fixes this by adding -ffile-prefix-map to CFLAGS in
debian/rules, which avoids embedding the absolute build path.

Alternately, switching to use a newer debhelper compat level and the dh
build system would likely also fix this, as it includes -ffile-prefix-map
by default.


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


live well,
  vagrant
From c5fa3d56c8c43cebc37ec635f05cf62a810c573f Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Mon, 23 May 2022 23:00:09 +
Subject: [PATCH] debian/rules: Add -ffile-prefix-map to CFLAGS.

---
 debian/rules | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/debian/rules b/debian/rules
index c88d7b5..69e5a1d 100755
--- a/debian/rules
+++ b/debian/rules
@@ -16,6 +16,9 @@ else
   CFLAGS += -O2
 endif
 
+# Avoid embedding the build path
+CFLAGS += -ffile-prefix-map=$(CURDIR)=.
+
 config.status: configure
 	dh_testdir
 	cp -f /usr/share/misc/config.sub config.sub
-- 
2.36.1



signature.asc
Description: PGP signature

Bug#1011495: modglue: reproducible-builds: Embedded build path in example Makefile

[Vagrant Cascadian]

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

The build path is embedded in /usr/share/doc/libmodglue1-dev/examples/Makefile:

  
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/modglue.html

  
g++·-g·-O2·-ffile-prefix-map=/build/1st/modglue-1.17=.·-fstack-protector-strong 
...
  vs.
  
g++·-g·-O2·-ffile-prefix-map=/build/2/modglue-1.17/2nd=.·-fstack-protector-strong
 ...

The attached patch fixes this by replacing the build path with a
placeholder string in debian/rules.

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

Thanks for maintaining modglue!

live well,
  vagrant
From 90abd06e800aa89e41a213373950ccda809858f9 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Mon, 23 May 2022 22:52:57 +
Subject: [PATCH] debian/rules: Replace build path in example Makefile with
 "BUILDPATH".

---
 debian/rules | 5 +
 1 file changed, 5 insertions(+)

diff --git a/debian/rules b/debian/rules
index e1ec72b..cfd744c 100755
--- a/debian/rules
+++ b/debian/rules
@@ -10,3 +10,8 @@ override_dh_autoreconf:
 override_dh_auto_install:
 	$(MAKE) install DESTDIR=$(CURDIR)/debian/libmodglue1v5 DEVDESTDIR=$(CURDIR)/debian/libmodglue1-dev
 	rm `find $(CURDIR)/debian -name '*.la'`
+
+override_dh_installexamples:
+	# Replace build path with placeholder string
+	sed -i -e "s,$(CURDIR),BUILDPATH,g" examples/Makefile
+	dh_installexamples
-- 
2.36.1



signature.asc
Description: PGP signature

Bug#1011494: FTBFS: compat level 6 unsupported

[Adam Borowski]

Source: atitvout
Version: 0.4-13.1
Severity: serious
Tags: ftbfs
Justification: fails to build from source

dh_clean: error: Compatibility levels before 7 are no longer supported (level 6 
requested)

That's pretty self-explaining...

Bug#1011493: freecdb: reproducible-builds: embedded build paths in various binaries

[Vagrant Cascadian]

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

The build path is embedded in various binaries in /usr/bin:

  
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/freecdb.html

  /usr/bin/cdbdump

  /build/1st/freecdb-0.76/cdbdump.c:45
  vs.
  /build/2/freecdb-0.76/2nd/cdbdump.c:45

The attached patch fixes this by explicitly passing CFLAGS to a
dh_auto_build override in debian/rules, which includes the
-ffile-prefix-map argument used to avoid embedding build paths.


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


live well,
  vagrant
From 614861c71f34eea174ed917d3a03b23f771008f3 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Mon, 23 May 2022 22:28:57 +
Subject: [PATCH] debian/rules: Explicitly pass CFLAGS to dh_auto_build.

---
 debian/rules | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/debian/rules b/debian/rules
index 2d33f6a..ae015cc 100755
--- a/debian/rules
+++ b/debian/rules
@@ -2,3 +2,6 @@
 
 %:
 	dh $@
+
+override_dh_auto_build:
+	dh_auto_build -- CFLAGS="$(CFLAGS)"
-- 
2.36.1



signature.asc
Description: PGP signature

Bug#1011492: tika: FTBFS cannot find symbols

[Markus Koschany]

Source: tika
Version: 1.22-2
Severity: serious
X-Debbugs-Cc: a...@debian.org


I just stumbled upon this FTBFS while rebuilding some packages for a new
jsoup release. There are some missing symbols but it is not related to
jsoup. I am just filing this bug report for further investigation
later.

Markus

Bug#900874: ITA: schroot -- Execute commands in a chroot

[Guilherme de Paula Xavier Segundo]

Hello Christoph Biedl,

I have new information regarding Schroot. In contacting the package upstream I 
was informed that they are no longer interested in updating the package and 
that further
efforts should be made to find a replacement for schroot, so I am no longer 
interested in maintaining the package.

Do you want me to return the bug to your property or orphan it?

Thank you for your attention.

Bug#1011491: getstream: reproducible-builds: embedded build paths in /usr/bin/getstream

[Vagrant Cascadian]

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

The build path is embedded in /usr/bin/getstream:

  
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/getstream.html

  /build/1st/getstream-20100616/getstream.c:30
  vs.
  /build/2/getstream-20100616/2nd/getstream.c:30

The attached patches fix this by passing CFLAGS via EXTRA_CFLAGS in a
dh_auto_build override in debian/rules, and adjusting the upstream
Makefile to append EXTRA_CFLAGS to CFLAGS. This allows passing the
default build flags including -ffile-prefix-map, which avoids embedding
the absolute path in compiled files.


With these patches applied, getstream should build reproducibly on
tests.reproducible-builds.org!


live well,
  vagrant
From c0b0fc68cec2a532dcdfe134271623fceb3813c3 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Mon, 23 May 2022 22:16:24 +
Subject: [PATCH 1/2] Makefile: Append EXTRA_CFLAGS to CFLAGS.

---
 Makefile | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Makefile b/Makefile
index 501467f..53b05c0 100644
--- a/Makefile
+++ b/Makefile
@@ -7,6 +7,8 @@ else
 CFLAGS+=-O0 -g
 endif
 
+CFLAGS += $(EXTRA_CFLAGS)
+
 LDFLAGS=-lpthread
 
 MDEFS := $(shell sh Makefile.defs.sh >Makefile.defs)
-- 
2.36.1

From 20a63cf51a2cea9a9086fe4a3222a7e2f90aef37 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Mon, 23 May 2022 22:16:46 +
Subject: [PATCH 2/2] debian/rules: Pass CFLAGS via EXTRA_CFLAGS in
 dh_auto_build override.

---
 debian/rules | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/debian/rules b/debian/rules
index bf3f0e8..5883c49 100755
--- a/debian/rules
+++ b/debian/rules
@@ -9,3 +9,6 @@ include /usr/share/dpkg/buildtools.mk
 
 %:
 	dh $@
+
+override_dh_auto_build:
+	dh_auto_build -- EXTRA_CFLAGS="$(CFLAGS)"
-- 
2.36.1



signature.asc
Description: PGP signature

Bug#1011490: gdigi: reproducible-builds: embedded build paths in /usr/bin/gdigi

[Vagrant Cascadian]

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

The build path is embedded in /usr/bin/gdigi:

  
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/gdigi.html

  /build/1st/gdigi-0.4.0+git20200615+1c2c89f/gdigi.c:43
  vs.
  /build/2/gdigi-0.4.0+git20200615+1c2c89f/2nd/gdigi.c:43

The attached patch fixes this by passing CFLAGS via EXTRA_CFLAGS in a
dh_auto_build override in debian/rules. This allows passing the default
build flags including -ffile-prefix-map, which avoids embedding the
absolute path in compiled files.


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


live well,
  vagrant
From 41aa07e65328c9f522183e0e036c9143317cba34 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Mon, 23 May 2022 22:05:11 +
Subject: [PATCH] debian/rules: Pass CFLAGS as EXTRA_CFLAGS in dh_auto_build
 override.

---
 debian/rules | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/debian/rules b/debian/rules
index cbe925d..ae7a96f 100755
--- a/debian/rules
+++ b/debian/rules
@@ -1,3 +1,6 @@
 #!/usr/bin/make -f
 %:
 	dh $@
+
+override_dh_auto_build:
+	dh_auto_build -- EXTRA_CFLAGS="$(CFLAGS)"
-- 
2.36.1



signature.asc
Description: PGP signature

Bug#1011489: wiipdf: reproducible-builds: embedded build paths in /usr/bin/wiipdf

[Vagrant Cascadian]

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

The build path is embedded in /usr/bin/wiipdf:

  
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/wiipdf.html

  /build/1st/wiipdf-1.4/wiipdf.c:114
  vs.
  /build/2/wiipdf-1.4/2nd/wiipdf.c:114

The attached patch fixes this by calling dh_auto_build instead of
$(MAKE) from debian/rules, which passes the default build flags
including -ffile-prefix-map, which avoids embedding the absolute path in
compiled files.

Alternately, updating to dh and a newer debhelper-compat level would
likely fix this as well, as it includes -ffile-prefix-map by default.


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


live well,
  vagrant
From b5bb2fee67f79baaf5d2d949aa97b8e28dc1b45e Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Mon, 23 May 2022 21:53:21 +
Subject: [PATCH] debian/rules: Use dh_auto_build instead of $(MAKE).

---
 debian/rules | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/rules b/debian/rules
index d4b3d3f..6955032 100755
--- a/debian/rules
+++ b/debian/rules
@@ -21,7 +21,7 @@ build-stamp:
 	dh_testdir
 
 	# Add here commands to compile the package.
-	$(MAKE)
+	dh_auto_build
 
 	touch $@
 
-- 
2.36.1



signature.asc
Description: PGP signature

Bug#999493: ITP: pika-backup -- simple backups based on borg

[Nicholas D Steeves]

Control: noowner -1
Control: retitle -1 RFP: pika-backup -- simple backups based on borg

I'm converting this ITP to an RFP because six months have passed without
an update.  Please feel free to revert to an ITP if The Debian Borg
Collective is still working on this package.  Reply follows inline:

On Thu, 11 Nov 2021 22:27:02 UTC, The Debian Borg Collective wrote:

> Package: wnpp
> Severity: wishlist
> Owner: Debian Borg Collective 
> X-Debbugs-Cc: debian-de...@lists.debian.org
>
> * Package name: pika-backup
>   Version : 0.3.5

Now at v0.4.0

>   Upstream Author : Sophie Herold
> * URL : https://apps.gnome.org/app/org.gnome.World.PikaBackup/
> https://wiki.gnome.org/Apps/PikaBackup
> https://gitlab.gnome.org/World/pika-backup
> * License : GPL-3
>   Programming Lang: Rust
>   Description : simple backups based on borg
>
> Doing backups the easy way. Plugin your USB drive and let the Pika do the 
> rest for you.
>

It might also be worth noting that remote backups are supported in the
short description (I haven't verified this functionality).

> Features
>
>  * Setup new backup repositories or uses existing ones
>  * Create backups locally and remote
>  * Save time and disk space because Pika Backup does not need to copy known 
> data again
>  * Encrypt your backups
>  * List created archives and browse through their contents
>  * Recover files or folders via your file browser
>
> Pika Backup is powered by the well-tested borg-backup software.
>
> Limitations
>
> Currently, scheduled backups are not supported.

Scheduled backups are now supported :)

> Excluding files from a backup via regular expressions and alike is not
> implemented yet.

This functionality also appears to now be supported:

  
https://gitlab.gnome.org/World/pika-backup/uploads/1e287bea9923d89213442658e152cc6c/pika-backup-1.png

> Pika Backup is designed to save your personal data and does not
> support complete system recovery.

Unfortunately Vorta (which I maintain) cannot yet do this either.  An
additional limitation of Pika, as far as I can tell, is that it doesn't
support a mechanism to either a) make LVM or btrfs snapshots.  b) call a
pre & post script to do so.  This is something Vorta is working towards
supporting, while it's unclear whether it will be an eventual feature of
Pika.  I believe the absence of this support may pose an issue for
consistent backups of unquiesced user databases (eg: Akonadi), but maybe
this isn't an issue on GNOME?

From what I can tell, Relax-and-Recover looks like it may be the most
promising solution for full system recovery.  Its distinguishing
features are generation of bootable recovery media and incredible
flexibility.  Relax-and-Recover can also integrate with Borg, but it
does not have a user friendly GUI.

  http://relax-and-recover.org

I'm the maintainer of Vorta (Qt-based), and I support a handful of happy
(GNOME) users, but Pika Backup looks easier to set up and has what
appears to be a GNOME HIG interface, and development towards (possibly
already ready) GTK4 support.  In other words, it looks like Pika may be
a better fit for users who use Debian's default desktop (GNOME).  As a
KDE Plasma user, I won't be packaging Pika.

Regards,
Nicholas


signature.asc
Description: PGP signature

Bug#1006255: ITP: blender-doc -- Offline copy of the Blender Manual available at https://docs.blender.org/manual/

[Jonathan Rubenstein]

Control: retitle -1 ITP: blender-doc -- Offline copy of the Blender 
Manual available at https://docs.blender.org/manual/


I have finished creating a Debian package for Blender's Manual, and have 
it up on Debian Salsa: https://salsa.debian.org/JJRcop/blender-doc


I am changing this RFP into an ITP.


Best,
Jonathan Rubenstein

Bug#1011488: stymulator: reproducible-builds: embedded build paths in various binaries

[Vagrant Cascadian]

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

The build path is embedded in /usr/bin/ym2wav and /usr/bin/ymplayer:

  
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/stymulator.html

  
/build/1st/stymulator-0.21a~dfsg/src/stsoundlib/YmUserInterface.cpp:40·(discriminator·1)
  vs.
  
/build/2/stymulator-0.21a~dfsg/2nd/src/stsoundlib/YmUserInterface.cpp:40·(discriminator·1)

The attached patch fixes this by setting -ffile-prefix-map in CXXFLAGS
in debian/rules, which avoids embedding the absolute path in compiled
files.

Alternately, switching to use the default CXXFLAGS from dpkg-buildflags
(possibly through using a newer debhelper compat version) also would
include -ffile-prefix-map by default.


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


live well,
  vagrant
From f84eea4a324d31d3c3b6a16847e412984361d067 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Mon, 23 May 2022 21:25:59 +
Subject: [PATCH] debian/rules: Add -ffile-prefix-map to CXXFLAGS.

---
 debian/rules | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/debian/rules b/debian/rules
index 06c429f..0702ecd 100755
--- a/debian/rules
+++ b/debian/rules
@@ -11,6 +11,9 @@ else
 	CXXFLAGS += -O2
 endif
 
+# Avoid embedding the build path
+CXXFLAGS += -ffile-prefix-map=$(CURDIR)=.
+
 build: build-stamp
 build-stamp:
 	dh_testdir
-- 
2.36.1



signature.asc
Description: PGP signature

Bug#1011487: lxlauncher: diff for NMU version 0.2.5-1.1

[Boyuan Yang]

Package: lxlauncher
Version: 0.2.5-1
Severity: normal
Tags: patch  pending

Dear maintainer,

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

Regards.

diff -Nru lxlauncher-0.2.5/debian/changelog lxlauncher-
0.2.5/debian/changelog
--- lxlauncher-0.2.5/debian/changelog   2016-02-21 08:43:40.0 -0500
+++ lxlauncher-0.2.5/debian/changelog   2022-05-23 17:14:27.0 -0400
@@ -1,3 +1,10 @@
+lxlauncher (0.2.5-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop -dbg package in favor of automatic -dbgsym debug package.
+
+ -- Boyuan Yang   Mon, 23 May 2022 17:14:27 -0400
+
 lxlauncher (0.2.5-1) unstable; urgency=low
 
   * Merging upstream version 0.2.5.
@@ -38,7 +45,7 @@
   * Removing Daniel Baumann from uploaders (Closes: #704341).
   * Adding --disable-silent-rules to fix buildlog checker warning.
   * Bump Standards-Version to 3.9.5.
-  * Updating watch file to support XZ tarball format and non-numeric 
+  * Updating watch file to support XZ tarball format and non-numeric
 versions.
 
  -- Andrew Lee (李健秋)   Thu, 26 Dec 2013 02:11:03 +0800
diff -Nru lxlauncher-0.2.5/debian/control lxlauncher-0.2.5/debian/control
--- lxlauncher-0.2.5/debian/control 2016-02-21 08:37:48.0 -0500
+++ lxlauncher-0.2.5/debian/control 2022-05-23 17:13:49.0 -0400
@@ -25,14 +25,3 @@
  It's standard-compliant and desktop-independent. It follows
freedesktop.org
  specs, so newly added applications will automatically show up in the
launcher,
  and vice versa for the removed ones.
-
-Package: lxlauncher-dbg
-Section: debug
-Priority: extra
-Architecture: any
-Depends: ${misc:Depends}, lxlauncher (= ${binary:Version})
-Description: LXDE launcher for netbooks (debug)
- LXLauncher is a GUI application for the Lightweight X11 Desktop
Environment
- (LXDE).
- .
- This package contains the debugging symbols.
diff -Nru lxlauncher-0.2.5/debian/rules lxlauncher-0.2.5/debian/rules
--- lxlauncher-0.2.5/debian/rules   2016-02-21 08:43:03.0 -0500
+++ lxlauncher-0.2.5/debian/rules   2022-05-23 17:14:15.0 -0400
@@ -12,4 +12,4 @@
dh_auto_install -- DESTDIR=$(CURDIR)/debian/lxlauncher
 
 override_dh_strip:
-   dh_strip --dbg-package=lxlauncher-dbg
+   dh_strip --dbgsym-migration='lxlauncher-dbg (<< 0.2.5-1.1~)'


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

Bug#1011486: tdfsb: reproducible-builds: embedded build paths in /usr/games/tdfsb

[Vagrant Cascadian]

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

The build path is embedded in /usr/games/tdfsb:

  
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/tdfsb.html

  /build/1st/tdfsb-0.0.10/tdfsb.c:2909
  vs.
  /build/2/tdfsb-0.0.10/2nd/tdfsb.c:2909


The attached patch fixes this by adjusting compile.sh to include
-ffile-prefix-map in CFLAGS to avoid embedding the absolute path in
compiled files.

Alternately, updating to a newer version of debhelper-compat and dh, and
adjusting debian/patches/set_cflags.diff to only allow setting CFLAGS
would allow using the default CFLAGS from dpkg-buildflags.


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


live well,
  vagrant
From cbb0273f0e3bc4264610158b4894d7418a6d1674 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Mon, 23 May 2022 20:46:06 +
Subject: [PATCH 1/4] compile.sh: Add -ffile-prefix-map to CFLAGS.

This avoids embedding the build path in the resulting binaries.

https://reproducible-builds.org/docs/build-path/
---
 compile.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/compile.sh b/compile.sh
index f957eb2..740b227 100755
--- a/compile.sh
+++ b/compile.sh
@@ -11,7 +11,7 @@ execfind ()
 done;
 }
 
-CFLAGS="-O2 -Wall -g"
+CFLAGS="-O2 -Wall -g -ffile-prefix-map=$(pwd)=."
 SDL_CONFIG=$(execfind sdl-config sdl11-config sdl10-config sdl12-config \/boot\/develop\/tools/gnupro\/bin\/sdl-config);
 
 if ! "$SDL_CONFIG" --version > /dev/null; then
-- 
2.36.1



signature.asc
Description: PGP signature

Bug#1011485: RFS: proftpd-mod-kafka/0.1-1 [ITP] -- ProFTPD module mod_kafka

[Hilmar Preusse]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "proftpd-mod-kafka":

 * Package name: proftpd-mod-kafka
   Version : 0.1-1
   Upstream Author : TJ Saunders
 * URL : https://github.com/Castaglia/proftpd-mod_kafka/releases
 * License : GPL-2+
 * Vcs : 
https://salsa.debian.org/debian-proftpd-team/proftpd-mod-kafka
   Section : net

The source builds the following binary packages:

  proftpd-mod-kafka - ProFTPD module mod_kafka

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

  https://mentors.debian.net/package/proftpd-mod-kafka/

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

  dget -x 
https://mentors.debian.net/debian/pool/main/p/proftpd-mod-kafka/proftpd-mod-kafka_0.1-1.dsc

Changes for the initial release:

 proftpd-mod-kafka (0.1-1) unstable; urgency=medium
 .
   * Initial Release. (Closes: #1009887)

Regards,
-- 
  Hilmar Preusse


signature.asc
Description: PGP signature

Bug#1011483: reportbug: open-iscsi-udeb - iscsiadm InitiatorName not set: /etc/iscsi/initiatorname.iscsi does not exist

[Eugene]

Package: open-iscsi
Version: 2.1.3-5
Severity: normal
Tags: d-i
X-Debbugs-Cc: eugene.losowskigallag...@googlemail.com

Dear Maintainer,

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

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

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


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

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

Versions of packages open-iscsi depends on:
ii  debconf [debconf-2.0]  1.5.77
ii  libc6  2.31-13+deb11u3
ii  libisns0   0.100-3
ii  libkmod2   28-1
ii  libmount1  2.36.1-8+deb11u1
ii  libopeniscsiusr2.1.3-5
ii  libssl1.1  1.1.1n-0+deb11u2
ii  libsystemd0247.3-7
ii  udev   247.3-7

open-iscsi recommends no packages.

open-iscsi suggests no packages.

-- debconf information excluded
>From e9617133456f23cff32a00ee1e1668be38167b6c Mon Sep 17 00:00:00 2001
From: Eugene Losowski-Gallagher 
Date: Mon, 23 May 2022 21:51:43 +0100
Subject: [PATCH] iSCSI started in installer environment - Disks detected for
 installation

---
 debian/rules | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/debian/rules b/debian/rules
index 22ccf63..3c96ee4 100755
--- a/debian/rules
+++ b/debian/rules
@@ -84,7 +84,9 @@ ifneq ($(UDEB),)
dh_install -p open-iscsi-udeb utils/iscsi_discovery sbin/
dh_install -p open-iscsi-udeb utils/iscsi-iname sbin/
dh_install -p open-iscsi-udeb etc/iscsid.conf etc/iscsi/
-   dh_install -p open-iscsi-udeb debian/open-iscsi-udeb.start 
sbin/iscsi-start
+   # Debian package cannot rename file so will create a symbolic link 
instead
+   dh_install -p open-iscsi-udeb debian/open-iscsi-udeb.start sbin/
+   ln -sf /sbin/open-iscsi-udeb.start 
debian/open-iscsi-udeb/sbin/iscsi-start
dh_install -p open-iscsi-udeb debian/open-iscsi-udeb.finish-install 
usr/lib/finish-install.d/10open-iscsi
 
# Ship shared libraries along with the executable in a single udeb
-- 
2.20.1

Bug#1011484: firefox: FF saves files even when selecting to just opening them

[Christoph Anton Mitterer]

Package: firefox
Version: 100.0.2-1
Severity: normal


Hey.

Apparently since quite a while already, when having set:
  Files and Applications / Downloads
  [*] Always ask you where to save files
and then clicking some link that leads to the dialogue where
one can choose between opening and saving...

... even when one selects open, it still stores the file
additionally in the folder configured for the disabled:
  [ ] Save files to 
in the preferences.


I remember that it always used to save such opened files
in some temp dir.
That no longer seems to work.


Cheers,
Chris.

Bug#1011482: cgit: Package cgit-pink as a more up-to-date alternative for cgit

[Alejandro Colomar]

Package: cgit
Severity: wishlist
X-Debbugs-Cc: alx.manpa...@gmail.com

Dear maintainer,

Could you please package cgit-pink as an alternative to cgit that
is well maintained?  cgit development has been stopped for a year
now.

cgit-pink: 

Cheers,

Alex

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

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

Versions of packages cgit depends on:
ii  libc62.33-7
pn  liblua5.1-0  
ii  zlib1g   1:1.2.11.dfsg-4

Versions of packages cgit recommends:
pn  apache2 | httpd  

Versions of packages cgit suggests:
ii  python3   3.10.4-1+b1
pn  python3-docutils  
pn  python3-markdown  
ii  python3-pygments  2.11.2+dfsg-2

Bug#713905: mention that there is nothing wrong with one's system upon warning

[Michael Biebl]

On Fri, 11 Jan 2019 16:04:40 -0400 Jesse Smith  
wrote:


> Jesse, could you please take a look at this. This message is generated
> by insserv. Probably we could use more gentle tone, like
> 
> 	'info: default start runlevel arguments (2 3 4 5) differs from default (S). Proceeding as requested'.
> 


I looked at this and I do not see anywhere in the insserv code where
this message could be generated.  However, it does appear to match line
415-416 of the update-rc.d script. I think this message would have to be
changed there.

- Jesse




Jesse, as sysvinit/insserv maintainer, should those warning messages in
https://salsa.debian.org/debian/init-system-helpers/-/blob/master/script/update-rc.d#L425
be dropped?

If so, please submit a patch or a MR.

Regards,
Michael



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1011481: tamil-gtk2im: reproducible-builds: embedded build paths

[Vagrant Cascadian]

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

The build path is embedded in various binaries:

  
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/tamil-gtk2im.html

  /usr/lib/x86_64-linux-gnu/gtk-2.0/2.10.0/immodules/anjal-uni.so

  /build/1st/tamil-gtk2im-2.2/anjal-uni.c:112
  vs.
  /build/2/tamil-gtk2im-2.2/2nd/anjal-uni.c:112


The attached patch fixes this by passing -ffile-prefix-map to gcc in
compile-gtk2im.sh, which avoids embedding the absolute build path.


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


live well,
  vagrant
From 1003f565988783e16a7f84e66d0e719dff956bba Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Mon, 23 May 2022 20:35:37 +
Subject: [PATCH] compile-gtk2im.sh: Pass -ffile-prefix-map to compiler.

This avoids embedding the build path in the binaries.

https://reproducible-builds.org/docs/build-path/
---
 compile-gtk2im.sh | 20 ++--
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/compile-gtk2im.sh b/compile-gtk2im.sh
index 77900a2..13de96a 100755
--- a/compile-gtk2im.sh
+++ b/compile-gtk2im.sh
@@ -1,51 +1,51 @@
 #!/bin/sh
 
-libtool --mode=compile gcc -DHAVE_CONFIG_H \
+libtool --mode=compile gcc -ffile-prefix-map=$(pwd)=. -DHAVE_CONFIG_H \
 	`pkg-config --cflags gtk+-2.0` \
 	-g -O2 -Wall -D_GNU_SOURCE -c \
 	-o tamil99-tsc.lo tamil99-tsc.c
 
-libtool --mode=link gcc  -g -O2 -Wall -D_GNU_SOURCE \
+libtool --mode=link gcc -ffile-prefix-map=$(pwd)=. -g -O2 -Wall -D_GNU_SOURCE \
 	-o tamil99-tsc.la -rpath ~/.gtk-2.0/immodules \
 	-rpath ~/.gtk-2.0/immodules -avoid-version -module \
 	tamil99-tsc.lo `pkg-config --libs gtk+-2.0`
 
-libtool --mode=compile gcc -DHAVE_CONFIG_H \
+libtool --mode=compile gcc -ffile-prefix-map=$(pwd)=. -DHAVE_CONFIG_H \
 	`pkg-config --cflags gtk+-2.0` \
 	-g -O2 -Wall -D_GNU_SOURCE -c \
 	-o tamil99-uni.lo tamil99-uni.c
 
-libtool --mode=link gcc  -g -O2 -Wall -D_GNU_SOURCE \
+libtool --mode=link gcc -ffile-prefix-map=$(pwd)=. -g -O2 -Wall -D_GNU_SOURCE \
 	-o tamil99-uni.la -rpath ~/.gtk-2.0/immodules \
 	-rpath ~/.gtk-2.0/immodules -avoid-version -module \
 	tamil99-uni.lo `pkg-config --libs gtk+-2.0`
 
-libtool --mode=compile gcc -DHAVE_CONFIG_H \
+libtool --mode=compile gcc -ffile-prefix-map=$(pwd)=. -DHAVE_CONFIG_H \
 	`pkg-config --cflags gtk+-2.0` \
 	-g -O2 -Wall -D_GNU_SOURCE -c \
 	-o tavpim-tsc.lo tavpim-tsc.c
 
-libtool --mode=link gcc  -g -O2 -Wall -D_GNU_SOURCE \
+libtool --mode=link gcc -ffile-prefix-map=$(pwd)=. -g -O2 -Wall -D_GNU_SOURCE \
 	-o tavpim-tsc.la -rpath ~/.gtk-2.0/immodules \
 	-rpath ~/.gtk-2.0/immodules -avoid-version -module \
 	tavpim-tsc.lo `pkg-config --libs gtk+-2.0`
 
-libtool --mode=compile gcc -DHAVE_CONFIG_H \
+libtool --mode=compile gcc -ffile-prefix-map=$(pwd)=. -DHAVE_CONFIG_H \
 	`pkg-config --cflags gtk+-2.0` \
 	-g -O2 -Wall -D_GNU_SOURCE -c \
 	-o tavpim-uni.lo tavpim-uni.c
 
-libtool --mode=link gcc  -g -O2 -Wall -D_GNU_SOURCE \
+libtool --mode=link gcc -ffile-prefix-map=$(pwd)=. -g -O2 -Wall -D_GNU_SOURCE \
 	-o tavpim-uni.la -rpath ~/.gtk-2.0/immodules \
 	-rpath ~/.gtk-2.0/immodules -avoid-version -module \
 	tavpim-uni.lo `pkg-config --libs gtk+-2.0`	
 
-libtool --mode=compile gcc -DHAVE_CONFIG_H \
+libtool --mode=compile gcc -ffile-prefix-map=$(pwd)=. -DHAVE_CONFIG_H \
 	`pkg-config --cflags gtk+-2.0` \
 	-g -O2 -Wall -D_GNU_SOURCE -c \
 	-o anjal-uni.lo anjal-uni.c
 
-libtool --mode=link gcc  -g -O2 -Wall -D_GNU_SOURCE \
+libtool --mode=link gcc -ffile-prefix-map=$(pwd)=. -g -O2 -Wall -D_GNU_SOURCE \
 	-o anjal-uni.la -rpath ~/.gtk-2.0/immodules \
 	-rpath ~/.gtk-2.0/immodules -avoid-version -module \
 	anjal-uni.lo `pkg-config --libs gtk+-2.0`	
-- 
2.36.1



signature.asc
Description: PGP signature

Bug#584082: -f is actually enabled by default

[Michael Biebl]

On Wed, 14 Nov 2018 21:21:25 -0300 Felipe Sateler  
wrote:

On Wed, Nov 14, 2018 at 7:15 PM Michael Biebl  wrote:

> [CCing debian-init-diversity which is planning to adopt insserv ttbomk]
>
> On Tue, 01 Jun 2010 11:15:17 +0800 jida...@jidanni.org wrote:
> > Package: sysv-rc
> > Version: 2.88dsf-7
> > Severity: wishlist
> > File: /usr/share/man/man8/update-rc.d.8.gz
> >
> > We read
> >-f Force removal of symlinks even if /etc/init.d/name still
> exists.
> >
> > However we find that indeed you might as well change that to
> >
> >-f [no-op, retained for backwards compatibility]
> >
> > or
> >-f Force removal of symlinks even if /etc/init.d/name still
> >exists [enabled by default]
> >
> > Proof:
> >
> > # sysv-rc-conf  --list cron
> > cron 0:off  1:off   2:on3:on4:on5:on6:off
> > # update-rc.d cron remove
> > update-rc.d: using dependency based boot sequencing
> > # sysv-rc-conf  --list cron #GONE:
> > cron
> > # update-rc.d cron defaults
> > update-rc.d: using dependency based boot sequencing
> > update-rc.d: warning: cron stop runlevel arguments (0 1 6) do not match
> LSB Default-Stop values (1)
>
> The -f parameter is mostly just passed along to insserv and causes it to
> ignore any potential dependency errors afair.
>
> If you could remove cron without issues, then this means no other
> service had a hard dependency on it.
>
> At least that's how I understand the meaning of -f.
> Felipe, is this correct?
>

Right. It is only passed on to insserv. Therefore it only has meaning when
initscripts is installed.


> If so, I guess the correct fix would be to update the documentation of
> the -f flag accordingly.
>

Agreed.

--

Saludos,
Felipe Sateler


Jesse, as maintainer of sysvinit/insserv, do you want to submit a MR for 
this?


Michael


OpenPGP_signature
Description: OpenPGP digital signature

Bug#556893: say which 'defaults' are which better

[Michael Biebl]

On Wed, 18 Nov 2009 11:59:14 +0800 jida...@jidanni.org wrote:

Package: sysv-rc
Version: 2.87dsf-8
Severity: wishlist

Say, perhaps these messages should differentiate better the two origins
of the definition of 'defaults':

# update-rc.d  network-manager defaults
update-rc.d: using dependency based boot sequencing
insserv: warning: current start runlevel(s) (empty) of script `network-manager' 
overwrites defaults (2 3 4 5).
insserv: warning: current stop runlevel(s) (0 1 2 3 4 5 6) of script 
`network-manager' overwrites defaults (0 1 6).

Or else the user will think "but I did say defaults".


Let's close this.

init-system-helpers no longer by default uses insserv.
And if insserv is used, I don't think we should supress any warning 
messages.
And if there are warning messages by insserv that should not be shown or 
improved, it's something that needs to be addressed in insserv.


Regards,
Michael


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1011480: libxsettings-client: reproducible-builds: embedded build paths

[Vagrant Cascadian]

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

The build path is embedded in /usr/lib/libXsettings-client.so.0.0.0:

  
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/libxsettings-client.html

  /build/1st/libxsettings-client-0.17/xsettings-client.c:340
  vs.
  /build/2/libxsettings-client-0.17/2nd/xsettings-client.c:340

The attached patch fixes this by setting -ffile-prefix-map in CFLAGS in
debian/rules, which avoids embedding the absolute build path.

Alternately, switching to use a newer debhelper compat level and the dh
build system would likely also fix this, as it includes -ffile-prefix-map
by default.


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


live well,
  vagrant
From d6c7a37cac9771a19cb4131d92970f5812e1cdce Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Mon, 23 May 2022 20:18:03 +
Subject: [PATCH] debian/rules: Pass -ffile-prefix-map via CFLAGS.

---
 debian/rules | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/debian/rules b/debian/rules
index 69c4f21..2ae7593 100755
--- a/debian/rules
+++ b/debian/rules
@@ -22,6 +22,9 @@ else
 	CFLAGS += -O2
 endif
 
+# Avoid embedding build path
+CFLAGS += -ffile-prefix-map=$(CURDIR)=.
+
 # shared library versions, option 1
 version=1.0.0
 major=1
-- 
2.36.1



signature.asc
Description: PGP signature

Bug#964383: Issues in init-system-helpers man pages

[Michael Biebl]

On Mon, 6 Jul 2020 16:26:58 +0200 Helge Kreutzmann 
 wrote:

Hello Michael,
On Mon, Jul 06, 2020 at 04:18:22PM +0200, Michael Biebl wrote:
> Am 06.07.20 um 15:41 schrieb Helge Kreutzmann:
> > I'm now reporting the errors for your project. If future reports
> > should use another channel, please let me know.
> 
> Ideally such a change request is submitted via salsa as merge request.


As stated in my introduction, this is not (easily) possible, sorry. 


> This makes it much easier to comment on the individual changes.

I can send each change individually, some other projects (like
man-pages itself) request this. Do you want this in future reports (if
any)?

> https://salsa.debian.org/debian/init-system-helpers/
> 
> > Man page: deb-systemd-invoke.1p

> > Issue: Groff code broken?
> > 
> > "\\&B start|stop|restart IÂ\\ ..."
> 
> Can't really comment on that one. The resulting man page looks fine to me?

> That man pages is generated via pod2man, could this be a toolchain issue?

Probably.

> > --
> > Man page: deb-systemd-invoke.1p
> > Issue: 206 → 2006?
> > 
> > "Jan 206"
> 
> 
> I can't find any reference to "Jan 206" in the deb-systemd-invoke man

> page. Can you point the source location?
> Did you by chance confuse that with the service(8) man page which was
> fixed just recently:
> 
https://salsa.debian.org/debian/init-system-helpers/-/commit/f1b835dcb2d6198addfab045676351d70d2930e9

Yes, my fault, it was service(8). 


> > --
> > Man page: deb-systemd-invoke.1p
> > Issue: s/it to/to/
> > 
> > "The I

Bug#995402: libclass-dbi-sweet-perl: FTBFS: test failure

[Damyan Ivanov]

Just a recording of a failed attempt to figure out what is wrong.

The problem seems to be with an internal SQL::Abstract method that is 
used by Class::DBI::Sweet (_recurse_where), which is reworked in the 
2.0 release, so a two-level join isn't handled.

It is not clear to me whether SQL:A is to blame or C:DBI:S. Should be 
the later, since SQL:A can't actually know which class/table 
corresponds to the joined alias or how to construct the join 
expression.

Anyway, If I had to decide today what happens with the package, I'd 
consider two options: removal of the package, and removal of the 
two-level join from documentation/tests.


-- Damyan

Bug#1011343: WISHLIST: Offical ALL-IN-ONE images?

[Thomas Schmitt]

Hi,

i uploaded the first version of my merger script as
  
https://dev.lovelyhq.com/libburnia/libisoburn/raw/branch/master/test/merge_2_debian_isos

Please download and give x-permission. The need for sudo can be avoided
by already mounting the two ISOs at the chosen mount points before running
the script.
Review and test reports are appreciated.

As motivation for tests by Debian installation experts:

If this works, then Debian could replace the DLBD sized ISOs by the
BD sized ISOs and instructions how to merge them to DLBD ISOs or a
QLBD/All-in-one ISO. (In that case the script should move into the hands
of debian-cd, i guess.)

===
$ ./merge_2_debian_isos
usage: merge_2_debian_isos \
   boot_iso boot_mount add_iso add_mount result_iso [for_dist]

Mounts by sudo the boot_iso at directory boot_mount and add_iso at
add_mount, if not already mounted that way. Then both Debian pools
and package lists get merged and a new ISO 9660 image result_iso
is produced, which must not yet exist.
If boot_iso is bootable then the new image will be bootable by the
same means.
This script creates the following temporary tree and files which
must not yet exist in the current working directory:
  ./merged_dists , ./merged_md5sum.txt , ./merged_REAMDE.txt
  ./temp_file
The optional sixth argument for_dist should only be given if
this script refuses to work and proposes to give this argument.
Exported non-empty variable MERGE_DATE enforces a particular
date string in the text which gets prepended to /README.txt .
Exported non-empty variable XORRISO overrides command xorriso,
which may be needed if installed xorriso is older than 1.4.2.
Example using GNU xorriso-1.5.4 instead of /usr/bin/xorriso:
  export XORRISO=$HOME/xorriso-1.5.4/xorriso/xorriso
  merge_2_debian_isos debian-11.2.0-amd64-DVD-1.iso /mnt/iso1 \
  debian-11.2.0-amd64-DVD-2.iso /mnt/iso2 merged.iso
===

The /README.txt of the result ISO gets a prefix text:
===
Result of a run of merge_2_debian_isos at 20220523-20:09
Package pools and Packages lists were merged.
The other files stem from the first input ISO.

Input ISO: debian-11.2.0-amd64-DVD-1.iso
  Debian GNU/Linux 11.2.0 "Bullseye" - Official amd64 DVD Binary-1
   20211218-11:13

Input ISO: debian-11.2.0-amd64-DVD-2.iso
  Debian GNU/Linux 11.2.0 "Bullseye" - Official amd64 DVD Binary-2
   20211218-11:13

 --
 [... text of boot_iso's README.txt ...]

===

The result of merging debian-11.2.0-amd64-DVD-[12].iso boots with
  qemu-system-x86_64 -enable-kvm -m 512 -hda merged.iso
to a boot loader menu with Debian logo.

I did not go further with installation yet, mainly because i still lack
ideas and experience how i would verify that the ISO's main repo knows
6788 *.deb files instead of 4753 in DVD-1 and 2035 in DVD-2.

To ease usage and to avoid quadratic behavior (actually triangular), i plan
to beef up the script so that it can merge more than 2 ISOs in one run.
E.g. for downloading all 19 11.3.0 amd64 DVDs and merging them.
(19 /dev/loop* should be no problem, i hope.)


Zhang Boyang wrote:
> I came up with a idea. Maybe you can use 'debian-cd' to create a DLBD set,
> say disc A1 and A2, then create another ALL-IN-ONE set, say disc B. Then
> compare if A1+A2==B. There might be small differences, like the package
> order in Packages.gz, but I think if the overall format is OK, then it will
> be OK.

I fear that several of the tasks in debian-cd are beyond my talents.
(I am about the third worst sysadmin which i know of.)

In the end it is about whether the merged ISO works fully or not.


Have a nice day :)

Thomas

Bug#1011479: fstrcmp: reproducible-builds: embedded build paths

[Vagrant Cascadian]

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

The build path is embedded in debug symbols:

  
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/fstrcmp.html

  ./usr/lib/debug/usr/bin/fstrcmp

  0»  (line_strp)»   (offset:·0x0):·/build/1st/fstrcmp-0.7.D001
  vs.
  0»  (line_strp)»   (offset:·0xf):·/build/2/fstrcmp-0.7.D001/2nd

The attached patch fixes this by setting -ffile-prefix-map in CFLAGS in
debian/rules, which avoids embedding the absolute build path.


Alternately, switching to use a newer debhelper compat level and the dh
build system would likely also fix this, as it includes -ffile-prefix-map
by default.


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


live well,
  vagrant
From 2427b3099e9ab739f9a9e6e1395fb978fd394e62 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Mon, 23 May 2022 19:36:47 +
Subject: [PATCH] debian/rules: Pass -ffile-prefix-map via CFLAGS.

---
 debian/rules | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/debian/rules b/debian/rules
index 9c76c56..9ffe622 100755
--- a/debian/rules
+++ b/debian/rules
@@ -10,6 +10,9 @@ else
 CFLAGS += -O2
 endif
 
+# Avoid embedding the build path
+CFLAGS += -ffile-prefix-map=$(CURDIR)=.
+
 config.status: configure
 	dh_testdir
 	dh_autotools-dev_updateconfig
-- 
2.36.1



signature.asc
Description: PGP signature

Bug#1011476: beancounter: Please drop alternative dependency on libdbd-sqlite2-perl

[gregor herrmann]

On Mon, 23 May 2022 14:33:10 -0500, Dirk Eddelbuettel wrote:

> | Please remove it from the list of alternative DBD::* package in
> | Depends.
> Absolutely. The code is a little stale, and I should really get on rewriting
> it in R.  Might be time to remove the package. And/or one last update. I will
> try to take care of it either way.

Excellent, thanks!

Cheers,
gregor

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


signature.asc
Description: Digital Signature

Bug#1011476: beancounter: Please drop alternative dependency on libdbd-sqlite2-perl

[Dirk Eddelbuettel]

Hi Gregor,

On 23 May 2022 at 21:05, gregor herrmann wrote:
| Package: beancounter
| Severity: minor
| X-Debbugs-Cc: 998...@bugs.debian.org
| 
| beancounter has "libdbd-pg-perl | libdbd-mysql-perl |
| libdbd-odbc-perl | libdbd-sqlite3-perl | libdbd-sqlite2-perl" in
| Depends, as it apparantly works with all kinds of different database
| backends.
| 
| We'd like to remove libdbd-sqlite2-perl from the archive, cf.
| #998351, and I guess that hardly any beancounter (or other) users
| would still use it nowadays.
| 
| Please remove it from the list of alternative DBD::* package in
| Depends.

Absolutely. The code is a little stale, and I should really get on rewriting
it in R.  Might be time to remove the package. And/or one last update. I will
try to take care of it either way.

Dirk

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

Bug#1011478: scsitools: reproducible-builds: embedded build paths in various binaries

[Vagrant Cascadian]

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

The build path is embedded in various binaries:

  
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/scsitools.html

  /sbin/scsi-spin

  /build/1st/scsitools-0.12/debian/scsi-spin.c:290
  vs.
  /build/2/scsitools-0.12/2nd/debian/scsi-spin.c:290

The attached patch fixes this by setting -ffile-prefix-map in CFLAGS,
and explicitly passing CFLAGS to make in debian/rules. The
-ffile-prefix-map compiler flag is used to avoid embedding the absolute
path in compiled files.

Alternately, switching to use the default CFLAGS from dpkg-buildflags
(possibly through using a newer debhelper compat version) also would
include -ffile-prefix-map by default.


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


live well,
  vagrant
From 271eb71f9c87d7bab1080b5db52f3468f7acec52 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Mon, 23 May 2022 19:19:28 +
Subject: [PATCH] debian/rules: Pass -ffile-prefix-map via CFLAGS.

---
 debian/rules | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/debian/rules b/debian/rules
index 2adc025..32ba7b7 100755
--- a/debian/rules
+++ b/debian/rules
@@ -2,7 +2,7 @@
 # Derived from debhelper/dh_make example, and Cristoph Lameter's file. -joy
 
 #export DH_VERBOSE=1
-CFLAGS = -g -O2 -Wall -fsigned-char
+CFLAGS = -g -O2 -Wall -fsigned-char -ffile-prefix-map=$(CURDIR)=.
 
 #architecture := $(shell dpkg-architecture -qDEB_HOST_ARCH)
 p = scsitools
@@ -11,7 +11,7 @@ p = scsitools
 	dh $@
 
 override_dh_auto_build:
-	cd scsiinfo && $(MAKE) KERNEL_INCLUDES="-fsigned-char" LDFLAGS=
+	cd scsiinfo && $(MAKE) KERNEL_INCLUDES="-fsigned-char" LDFLAGS= CFLAGS="$(CFLAGS)"
 	cd scsidev && CFLAGS="$(CFLAGS)" ./configure --prefix=/usr \
   --mandir='${prefix}'/share/man && $(MAKE)
 	cd sraw && gcc $(CFLAGS) -o sraw srawread.c
-- 
2.36.1



signature.asc
Description: PGP signature

Bug#1011477: ITP: node-babel-polyfills -- set of Babel plugins that enable injecting different polyfills

[Yadd]

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

* Package name: node-babel-polyfills
  Version : 0.6.1
  Upstream Author : Nicolò Ribaudo 
* URL : https://github.com/babel/babel-polyfills
* License : Expat
  Programming Lang: JavaScript
  Description : set of Babel plugins that enable injecting different 
polyfills

node-babel-polyfills will provide a set of node-babel7 plugins that
enable injecting different polyfills with different strategies in
the compiled code:
 * @babel/helper-define-polyfill-provider
 * babel-plugin-polyfill-corejs2
 * babel-plugin-polyfill-corejs3
 * babel-plugin-polyfill-es-shims
 * babel-plugin-polyfill-regenerator

Currently these modules are embedded into node-babel7 but should be
packaged separately.

This package will be maintained under JS Team umbrella

Bug#1000861: eggdrop: diff for NMU version 1.8.4+repack1-0.1

[Boyuan Yang]

Control: tags 1000861 + patch
Control: tags 1000861 + pending
X-Debbugs-CC: c...@winkie.fr

Dear maintainer,

I've prepared an NMU for eggdrop (versioned as 1.8.4+repack1-0.1) and
uploaded it to DELAYED/3. Please feel free to tell me if I
should delay it longer.

Regards.

diff -Nru eggdrop-1.8.4/debian/changelog eggdrop-
1.8.4+repack1/debian/changelog
--- eggdrop-1.8.4/debian/changelog  2020-04-09 07:08:10.0 -0400
+++ eggdrop-1.8.4+repack1/debian/changelog  2022-05-23
15:04:58.0 -0400
@@ -1,3 +1,12 @@
+eggdrop (1.8.4+repack1-0.1) unstable; urgency=high
+
+  * Non-maintainer upload.
+  * Repack upstream tarball with no file change. This solves the
+broken upstream tarball signature that causes FTBFS.
+(Closes: #1000861)
+
+ -- Boyuan Yang   Mon, 23 May 2022 15:04:58 -0400
+
 eggdrop (1.8.4-1) unstable; urgency=low
 
   * New upstream version 1.8.4


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

Bug#1011476: beancounter: Please drop alternative dependency on libdbd-sqlite2-perl

[gregor herrmann]

Package: beancounter
Severity: minor
X-Debbugs-Cc: 998...@bugs.debian.org

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

beancounter has "libdbd-pg-perl | libdbd-mysql-perl |
libdbd-odbc-perl | libdbd-sqlite3-perl | libdbd-sqlite2-perl" in
Depends, as it apparantly works with all kinds of different database
backends.

We'd like to remove libdbd-sqlite2-perl from the archive, cf.
#998351, and I guess that hardly any beancounter (or other) users
would still use it nowadays.

Please remove it from the list of alternative DBD::* package in
Depends.


Cheers,
gregor


-BEGIN PGP SIGNATURE-

iQKTBAEBCgB9FiEE0eExbpOnYKgQTYX6uzpoAYZJqgYFAmKL2wxfFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEQx
RTEzMTZFOTNBNzYwQTgxMDREODVGQUJCM0E2ODAxODY0OUFBMDYACgkQuzpoAYZJ
qgaxqRAAkRe7Kwc/YtwpCPnHi54T/oJA6lv6xjrSFVeVAq/8zyeD5/OjTQtDDScW
nxP2KCqe6eDMn99l/Qz2aGERLCGw9FBxgHjNR+t3sUSAECewK8QMIb6mIBUF3lVR
dYhaoRxKM4nq9clqdFxoO0yUeDiujB9116JUoubU4NSujt2WTChNKeyDRQsth+wL
6qUvhbDi/UbF8QBGOxQMrMElMshPpuqJoPS9NNzatxYgxgsoUD9GCc/2d7VYTE8L
e/b4MZ+mYiCP+bgLkQgzqJmtQNeQ2FD816tqUUkUy5o+5ou+unrpG7vv+CE2ned6
Z7ShJWxrjV3alEkfCqbyB/wUeelZ8WJI8bLudOkWkFgol7HhuXXZBiJj9ZXkKlVa
h5WxJhewPlC/xn/negikiL5acwb3FrS2YBvICZNGW4fRfqx0MqfIXC/kSEs5iQMe
woXwVlTVfFNGtJj4ccO55Feb/7YSOYIdjprbIliMqXL/QkaGR+gnwnkes28ChHpB
A0vF23ajTzAq3ryAo2IPBgGhs3OazY67QQs3ZoPZocHkGWibMYfE/d9wK/R+pMNF
CWAU8mPTD3Rr47LpJ8zdHGSQzND+FL6JHpMlfekNkprskvOfDDE3mpjVR6XNMK/1
semnJENLegx6rrt2tY5GK3kyEH9pF148sYnJaYkrk7gFgpE6mMI=
=6J50
-END PGP SIGNATURE-

Bug#1011474: libhrash0: Cannot load libcrypto.so.3

[Daniel Schepler]

Package: libhrash0
Version: 1.4.2-1
Severity: normal

I notice that even if I recompile rhash against the latest libssl-dev,
the Recommends is still on libssl1.1.  And it appears that this is
because the source code does a dlopen trying a hard-coded list of
library names, and libcrypto.so.3 is not in that list.

I also notice that libcrypto.so is at the front of the list, which
means that the behavior might be different if libssl-dev version 3.*
is installed, versus if it's not installed but it happens that the
obsolete package libssl1.1 is installed.  Normally, I would recommend
that code not do a dlopen on a development .so link and instead it
should dlopen based on the library's SONAME.  (So, I would suggest
removing the "libcrypto.so" entry from the head of the libNames list.)
-- 
Daniel Schepler

Bug#1008016: ITP: safe-network -- network routing and service daemon for the Safe Network

[Jonas Smedegaard]

0.59.0 draft 1, needs embedding 184 crates (123 missing, 1 pending, 1 broken, 
38 outdated, 21 ahead); Builds in ~60 minutes; Runs but help needed to properly 
test functionality

Thanks for the continued interest and encouragements at the Safenet forum 
https://safenetforum.org/t/will-maidsafe-be-in-debian-repositories -
that is much appreciated.

Main task continues to be to keep package up-to-date with upstream 
releases and try relace more embedded crates with packaged ones.

You can help by testing this draft package (either build it yourself or 
tell if you want access to binary packages I've built) and provide 
feedback on how well it works for you.

You can also help by joining the Rust team in Debian and contribute to 
unbreaking/upgrading/adding needed crate packages, as listed here: 
https://salsa.debian.org/debian/safe-network/-/blob/debian/latest/debian/TODO


 - Jonas

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

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

signature.asc
Description: signature

Bug#1011473: 2.5 clients cannot connect to a 2.6 server

[Wolfgang Walter]

Package: openvpn
Version: 2.6.0~git20220518+dco-1
Severity: important

openvpn 2.5.6 with openssl 1.1 seem unable to establish a connection to 
a sid openvpn-server upgraded to 2.6.0~git20220518+dco-1.


I checked the configs. They work if both sides are 2.5.6 or both sides 
are 2.6 with openssl 3.


I also see the following warning message in this case:

"WARNING: tun-mtu is used inconsistently, local='tun-mtu 1500', 
remote='tun-mtu 1532'"


Also in peer-mode 2.5.6 and 2.6 (both debian sid) do not work together.

Maybe this very new patch fixes the issue:

https://github.com/OpenVPN/openvpn/commit/88342ed8277c579704c0e67feb4278aeaa544027

I did not tested this hypothesis yet, though.

Regards,
--
Wolfgang Walter
Studentenwerk München
Anstalt des öffentlichen Rechts

Bug#1011446: q2-demux, q2-taxa: replace node-uglifyjs-webpack-plugin with node-terser-webpack-plugin

[Andreas Tille]

Dear Pirate,

Am Mon, May 23, 2022 at 11:25:54PM +0530 schrieb Pirate Praveen:
> >Hmmm, I tried to push a fix quickly but the new package does not seem to
> >be a plugin replacment as you can see in Salsa CI:
> >
> >  https://salsa.debian.org/med-team/q2-demux/-/jobs/2798791
> >
> >Any idea how this can be fixed?
> 
> https://salsa.debian.org/med-team/q2-demux/-/blob/master/q2_demux/_summarize/assets/webpack.config.js#L19
> 
> This will need to be changed as well.

Sorry for beeing so absolutely uneducated but could you be so
kind to mention to what exactly this needs to be changed?

Sorry for my ignorance about JS

 Andreas.

-- 
http://fam-tille.de

Bug#1011472: ITP: libfile-xdg-perl -- module implementing the XDG base directory specification

[gregor herrmann]

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

* Package name: libfile-xdg-perl
  Version : 1.02
  Upstream Author : Graham Ollis 
* URL : https://metacpan.org/release/File-XDG
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : module implementing the XDG base directory specification

File::XDG provides a basic implementation of the XDG base directory
specification as exists by the Free Desktop Organization (FDO). It supports
all XDG directories except for the runtime directories, which require session
management support in order to function.

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

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


signature.asc
Description: Digital Signature

Bug#995573: Any hope to see a fix coming ?

[Daniel Scharon]

Hi everyone,

> Hi William,
> 
> On  So 22 Mai 2022 22:15:17 CEST, Gacquer William wrote:
> 
> > Hello
> > 
> > A few months later, the bug persists.
> > Sadly I can't contribute but I pray every minute for the bug to be
> > fixed :)
> > 
> > Best regards
> > William Gacquer
> 
> I assume that xRDP's Xserver cannot handle GNOME sessions properly?
> 
> If so, you could try X2Go with X2Go Kdrive as graphical backend.
> This  
> is still bleeding edge not part of any official X2Go release, but
> you  
> can ping me on IRC #x2go (libera.chat) and ask for details there (at 
> the earliest Wednesday, due to travel plans).


an easier workaround (besides having a backport or a fixed version in
stable) is downloading xrdp 0.9.15-1 and xorgxrdp 1:0.2.15-1 via
https://snapshot.debian.org/
and install them with apt install /path/to/thepackage.deb

Those package versions were still compatible with libc6 from bullseye.

Kind regards,
Dan



smime.p7s
Description: S/MIME cryptographic signature

Bug#1011440: libsnmp-perl: behaviour fixed in do_not_callback_for_failed_reports.diff reintroduced in bullseye

[Ole Peder Brandtzæg]

On Mon, May 23, 2022 at 11:00:55PM +1000, Craig Small wrote:
>   It looks like that offending code wasn't removed, it was just
> relocated further along [1].

Ah, my bad! All the indentation differences in the original patch made
it unclear to me what it actually did…

> Looking at what they have done for net-snmp 5.9.2 snmplib/snmp_api.c
> isn't changed between 5.9 and 5.9.2 so I'll apply it as the problem
> isn't going away.

Wonderful, thanks a bunch. I presume this won't land in stable anytime
soon though, right, but maybe in backports?

> Your bug report was fine BTW. If there was an easy proof of concept
> that is even better but this looks like its a timing issue with
> delayed responses. The information helped get a resolution for me
> pretty quickly.

That's good to hear. Duly noted re: the PoC!

All the best,
Ole

-- 
Ole Peder Brandtzæg | Assistant Manager, ITK
I can see you now, as through a screen
A smile on your face, your fingers dripping kerosene

Bug#1006962: nvidia-cuda-toolkit: nvcc chokes on g++ 11.2's bits/std_function.h

[Andreas Beckmann]

Control: severity -1 important

On Fri, 29 Apr 2022 01:56:49 +0200 Andreas Beckmann  wrote:

I'll probaby go back to gcc 10 for now ...


Did that in sid.

Andreas

Bug#1011471: mgdiff: reproducible-builds: embedded build paths in /usr/bin/mgdiff

[Vagrant Cascadian]

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

The build path is embedded in /usr/bin/mgdiff:

  
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/mgdiff.html

  /build/1st/mgdiff-1.0/mgdiff.c:1057
  vs.
  /build/2/mgdiff-1.0/2nd/mgdiff.c:1057

The attached patch fixes this by explicitly passing CFLAGS to
make in debian/rules, which includes the -ffile-prefix-map
argument to avoid embedding the absolute path in compiled files.


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


live well,
  vagrant
From 4aa0b48b924de1a73b5cbe541b4adfafe832e013 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Mon, 23 May 2022 17:06:51 +
Subject: [PATCH] debian/rules: Explicitly pass CFLAGS to make.

---
 debian/rules | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/rules b/debian/rules
index 1df2c00..152626e 100755
--- a/debian/rules
+++ b/debian/rules
@@ -9,7 +9,7 @@ build-arch:
 	dh_testdir
 	xmkmf
 	make depend XMULIBONLY=""
-	make XMULIBONLY=""
+	make XMULIBONLY="" CFLAGS="$(CFLAGS)"
 	touch build
 
 clean:
-- 
2.36.1



signature.asc
Description: PGP signature

Bug#1011470: libapache2-mod-authz-unixgroup: reproducible-builds: embedded build paths in mod_authz_unixgroup.so

[Vagrant Cascadian]

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

The build path is embedded in
/usr/lib/apache2/modules/mod_authz_unixgroup.so:

  
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/libapache2-mod-authz-unixgroup.html

  /build/1st/libapache2-mod-authz-unixgroup-1.1.0/mod_authz_unixgroup.c:174
  vs.
  /build/2/libapache2-mod-authz-unixgroup-1.1.0/2nd/mod_authz_unixgroup.c:174


The attached patch fixes this by passing -ffile-prefix-map to axps2 in
debian/rules, which avoids embedding the build path in compiled files.


With this patch applied, libapache2-mod-authz-unixgroup should build
reproducibly on tests.reproducible-builds.org!


live well,
  vagrant
From 62a59b080b5a4cd133e1c712630de73bdbb695eb Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Mon, 23 May 2022 16:47:14 +
Subject: [PATCH] debian/rules: Pass -ffile-prefix-map to apxs2.

---
 debian/rules | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/rules b/debian/rules
index 2871a43..10368c9 100755
--- a/debian/rules
+++ b/debian/rules
@@ -1,7 +1,7 @@
 #!/usr/bin/make -f
 
 override_dh_auto_build:
-	apxs2 -c -Wc,-fno-strict-aliasing mod_authz_unixgroup.c
+	apxs2 -c -Wc,-fno-strict-aliasing -Wc,-ffile-prefix-map=$(CURDIR)=. mod_authz_unixgroup.c
 
 %:
 	dh $@ --with=apache2
-- 
2.36.1



signature.asc
Description: PGP signature

Bug#1010242: RFS: opengnb/1.2.8.7-1 [ITP] -- via P2P to setup de-centralized layer3 network VPN

[Bastian Germann]

Hi Xiao,

On Wed, 27 Apr 2022 08:14:51 +0800  wrote:

Changes for the initial release:

opengnb (1.2.8.7-1) unstable; urgency=low
.
[ xiao sheng wen(肖盛文) ]
* Initial release (Closes: #1003101)


I have had a first look at d/copyright. There are some problems:

* license shortname has to be GPL-3+ as the "or later" clause is used
* missing tap-windows.h license (has to be included even if not compiled)
  => It is GPL-3+ incompatible GPL-2 licensed but okay as it is not compiled.
* missing murmurhash license (might be public domain but has to be documented)
* missing ed25519 license
* missing miniupnpc license. The license has to be included even though its deb 
pkg is used.

Where does libs/protocol/network_protocol.h come from? It looks like a 
third-party file.
This might be a copyright violation.

d/control: Please have a look at the package description's grammar again, especially simple present singular-s is 
missing at some places.


Thanks,
Bastian

Bug#963727: dh-make-{elpa,perl}: move duplicate code to a library

[Lev Lamberov]

Hi gregor,

Mon 23 May 2022 @ 16:54 gregor herrmann :

> On Fri, 26 Jun 2020 11:38:48 +0500, Lev Lamberov wrote:
>
>> Hi,
>
> Sorry for replying so late, somehow this bug fell throught the
> cracks.
>  
>> dh-make-elpa is heavily based on dh-make-perl (thanks to all who
>> were/are involved into whis nice tool). Both share the same
>> object-oriented structure and some code. Recently, dh-make-elpa was
>> untied from dh-make-perl, so now the former doesn't depend on the
>> latter. But this was done by copying some code from dh-make-perl without
>> changes. The better option would be to move duplicate code to a library.
>
> Makes sense.
>
>> It would be nice to identify those methods which may be useful for
>> various (possible) implementations of dh-make- and are
>> unlikely to change significantly in the future. Those methods could be
>> moved to, say, DhMake::Packaging.
>
> Agreed.
>  
>> I would like to implement changes for both dh-make{elpa,perl}, but first
>> we should discuss what should be done and in which way. So, CCing Debian
>> Perl Group mailing list, but I think that it's better to keep the
>> discussion in one place, that is, in this bug report.
>
> From a dh-make-perl perspective I think we are happy with everything
> which "only" moves functionality around without breaking anything.
> So if you are still planning to work on this task, please go ahead
> and send patches/merge requests.

Thanks for the update. Hope, I will have some time during the coming
summer.

Cheers!
Lev

Bug#988540: im-config: breaks the keyboard configuration

[Osamu Aoki]

Hi,

> But this is very unclear (and perhaps wrong for other users).

I thought that some flexible table based fully custom input may be available 
using
either ibus-table or ibus-m18n with some user data. (This is my vague idea 
without
proof.)

Then looking at Debian repository, I found ibus-keyman package which supports 
over
2000 data from https://keyman.com/ (SIL) using  and keyman package.

This looks interesting for Greek/German like combination.  (Not for "Full 
Japanese
input with Kanji"  ... just hiragana-only)

Osamu

Bug#921537: gnome-terminal: mouse wheel scrolling sends 6 key up / key down escape sequences (kcuu1 / kcud1) in alternate screen

[Vincent Lefevre]

Control: reassign -1 libvte-2.91-0 0.68.0-1
Control: retitle -1 libvte-2.91-0: mouse wheel scrolling setting 
XTERM_ALTBUF_SCROLL is not preserved by a screen reset

Summary of the issue: VTE took the mouse wheel scrolling feature in
alternate screen from xterm. So one expects it to behave like xterm
(possibly except for the default behavior). With xterm, a terminal
reset (e.g. with the "reset" command) preserves this setting (just
like a reset will preserve the terminal size and other UI settings,
as opposed to content-related settings). But with VTE-based terminals
like GNOME Terminal and xfce4-terminal, the mouse wheel behavior is
reset to the hardcoded default. This can be tested with:

  printf '\e[?1007h' ; reset ; less some_file
  printf '\e[?1007l' ; reset ; less some_file

in the chosen terminal.

One consequence is that with GNU Screen, it is impossible to choose
the mouse wheel behavior when the real terminal is based on VTE
(see below), while the generated key up / key down events may be
destructive in some applications.

On 2019-04-03 14:03:51 +0200, Vincent Lefevre wrote:
> On 2019-04-03 13:42:50 +0200, Vincent Lefevre wrote:
> > On 2019-02-07 13:43:20 +0100, Egmont Koblinger wrote:
> > > You can disable this behavior with:
> > > 
> > >   printf '\e[?1007l'
> > 
> > This has no effect when using GNU Screen. For instance:
> > 
> > $ printf '\e[?1007l' ; screen sleep 20
> > 
> > then when using the mouse wheel:
> > 
> > ^[[B^[[B^[[B^[[B^[[B^[[B^[[B^[[B^[[B^[[B^[[B^[[B^[[B^[[B^[[B^[[B^[[B^[[B^[[B^[[B^[[B^[[B^[[B^[[B^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A^[[A
> > 
> > There isn't such an issue with xterm. It is not Screen that enables
> > Alternate Scroll Mode, otherwise one would get the same behavior in
> > xterm.
> > 
> > I suspect that GNOME Terminal "forgets" this setting under some
> > conditions.
> 
> I think that the cause is that Screen does a reset (since it starts
> a virtual terminal), as I can reproduce the same issue after a
> "tput reset". Thus "printf '\e[?1007l'" is not sufficient. Actually,
> a reset should not have an effect on the Alternate Scroll Mode, as
> in xterm, it doesn't as shown by:
> 
> $ printf '\e[?1007l'
> $ screen sleep 20
> $ printf '\e[?1007h'
> $ screen sleep 20
> 
> and using the mouse wheel in Screen for both instances (after the
> printf '\e[?1007h', the Alternate Scroll Mode remains enabled while
> the default is disabled in xterm).
> 
> Note: Executing "printf '\e[?1007l'" inside screen as a workaround is
> incorrect as there is no way to know whether the parent terminal will
> accept this sequence or will behave in a strange manner. Moreover,
> this is not possible when "screen" is followed by a command.

In fact, \e[?1007l and \e[?1007h inside a GNU Screen window are
ignored. So
  * With xterm, GNU Screen uses the current setting of xterm.
For instance, one can choose it in a limited way with
  printf '\e[?1007h' ; screen -r
  printf '\e[?1007l' ; screen -r
  * But with VTE-based terminals, this is reset to the default,
i.e. mouse wheel events always send key up / key down escape
sequences, and there doesn't seem to be anyway to change it.

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

Bug#1011469: transcalc: reproducible-builds: embedded build paths in /usr/bin/transcalc

[Vagrant Cascadian]

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

The build path is embedded in /usr/bin/transcalc:

  
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/transcalc.html

  /build/1st/transcalc-0.14/src/transcalc.c:214
  vs.
  /build/2/transcalc-0.14/2nd/src/transcalc.c:214

The attached patch fixes this by explicitly passing CFLAGS to
dh_auto_build in debian/rules, which includes the -ffile-prefix-map
argument to avoid embedding the absolute path in compiled files.


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


live well,
  vagrant
From e1037e5dba192180108fc12d38563118febaef48 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Mon, 23 May 2022 16:33:58 +
Subject: [PATCH] debian/rules: Explicitly pass CFLAGS to dh_auto_build.

---
 debian/rules | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/rules b/debian/rules
index 1cfd3a6..39dd180 100755
--- a/debian/rules
+++ b/debian/rules
@@ -8,7 +8,7 @@ export DEB_BUILD_MAINT_OPTIONS = hardening=+all
 	dh $@
 
 override_dh_auto_build:
-	dh_auto_build
+	dh_auto_build -- CFLAGS="$(CFLAGS)"
 	[ -e docs/transcalc.1.d-r-orig ] || cp -p docs/transcalc.1 docs/transcalc.1.d-r-orig
 	docbook-to-man docs/transcalc.sgml > docs/transcalc.1
 
-- 
2.36.1



signature.asc
Description: PGP signature

Bug#1011463: libgirepository-1.0-1: 1.72.0-1+b1 breaks python-gi (<< 3.42.0-1+b1)

[Simon McVittie]

On Mon, 23 May 2022 at 18:57:08 +0300, Горбешко Богдан wrote:
> But it still breaks ruby-gobject-introspection.

Yes, that's part of the same transition as the Breaks on older
python(3)-gi versions, and was added for the same reason. We wouldn't
have added those Breaks if they weren't necessary.

> Sid has a newer version

In fact there is no version of ruby-gobject-introspection in bookworm at
all: it was removed from testing as a result of unrelated release-critical
bug .

> which depends on some non-existent libgirepository-1.0-1-with-libffi8

That's a virtual package provided by libgirepository-1.0-1 (>= 1.70.0-2)
to indicate that it has the ABI that uses libffi8, so that it won't be
necessary to add similar Breaks for the next libffi transition.
The current version of libgirepository-1.0-1 in bookworm will satisfy
that dependency.

smcv

Bug#1011468: FTBFS with OpenJDK 17 due to com.sun.javadoc removal

[Pierre Gruet]

Source: barclay
Version: 2.1.0-3.1
Severity: important
Tags: ftbfs bookworm sid
User: debian-j...@lists.debian.org
Usertags: default-java17

barclay fails to build with Java 17 because it uses classes from the
com.sun.javadoc package which was removed:

/<>/src/main/java/org/broadinstitute/barclay/help/DocWorkUnit.java:3:
 error: package com.sun.javadoc does not exist
import com.sun.javadoc.ClassDoc;
  ^
/<>/src/main/java/org/broadinstitute/barclay/help/DocWorkUnit.java:25:
 error: cannot find symbol
private final ClassDoc classDoc;// javadoc 
documentation for clazz
  ^
  symbol:   class ClassDoc
  location: class DocWorkUnit
/<>/src/main/java/org/broadinstitute/barclay/help/DocWorkUnit.java:50:
 error: cannot find symbol
final ClassDoc classDoc,
  ^
  symbol:   class ClassDoc
  location: class DocWorkUnit
/<>/src/main/java/org/broadinstitute/barclay/help/DocWorkUnit.java:112:
 error: cannot find symbol
public ClassDoc getClassDoc() { return classDoc; }
   ^
  symbol:   class ClassDoc
  location: class DocWorkUnit
/<>/src/main/java/org/broadinstitute/barclay/help/HelpDoclet.java:5:
 error: package com.sun.javadoc does not exist
import com.sun.javadoc.ClassDoc;
  ^
/<>/src/main/java/org/broadinstitute/barclay/help/HelpDoclet.java:6:
 error: package com.sun.javadoc does not exist
import com.sun.javadoc.RootDoc;
  ^
/<>/src/main/java/org/broadinstitute/barclay/help/HelpDoclet.java:94:
 error: cannot find symbol
private RootDoc rootDoc;// The javadoc root doc
^
  symbol:   class RootDoc
  location: class HelpDoclet
/<>/src/main/java/org/broadinstitute/barclay/help/HelpDoclet.java:105:
 error: cannot find symbol
 public static boolean start(final RootDoc rootDoc) throws IOException {
   ^
  symbol:   class RootDoc
  location: class HelpDoclet
/<>/src/main/java/org/broadinstitute/barclay/help/HelpDoclet.java:139:
 error: cannot find symbol
protected boolean startProcessDocs(final RootDoc rootDoc) throws 
IOException {
 ^
  symbol:   class RootDoc
  location: class HelpDoclet
/<>/src/main/java/org/broadinstitute/barclay/help/HelpDoclet.java:256:
 error: cannot find symbol
private void processDocs(final RootDoc rootDoc) {
   ^
  symbol:   class RootDoc
  location: class HelpDoclet
/<>/src/main/java/org/broadinstitute/barclay/help/HelpDoclet.java:316:
 error: cannot find symbol
public RootDoc getRootDoc() { return rootDoc; }
   ^
  symbol:   class RootDoc
  location: class HelpDoclet
/<>/src/main/java/org/broadinstitute/barclay/help/HelpDoclet.java:361:
 error: cannot find symbol
public boolean includeInDocs(final DocumentedFeature documentedFeature, 
final ClassDoc classDoc, final Class clazz) {

  ^
  symbol:   class ClassDoc
  location: class HelpDoclet
/<>/src/main/java/org/broadinstitute/barclay/help/HelpDoclet.java:412:
 error: cannot find symbol
final ClassDoc classDoc,
  ^
  symbol:   class ClassDoc
  location: class HelpDoclet
/<>/src/main/java/org/broadinstitute/barclay/help/HelpDoclet.java:443:
 error: cannot find symbol
private Class getClassForClassDoc(final ClassDoc doc) {
  ^
  symbol:   class ClassDoc
  location: class HelpDoclet
/<>/src/main/java/org/broadinstitute/barclay/help/HelpDoclet.java:570:
 error: cannot find symbol
public ClassDoc getClassDocForClass(final Class clazz) {
   ^
  symbol:   class ClassDoc
  location: class HelpDoclet
/<>/src/main/java/org/broadinstitute/barclay/help/WDLDoclet.java:3:
 error: package com.sun.javadoc does not exist
import com.sun.javadoc.ClassDoc;
  ^
/<>/src/main/java/org/broadinstitute/barclay/help/WDLDoclet.java:24:
 error: package com.sun.javadoc does not exist
public static boolean start(final com.sun.javadoc.RootDoc rootDoc) throws 
IOException {
 ^
/<>/src/main/java/org/broadinstitute/barclay/help/WDLDoclet.java:29:
 error: cannot find symbol
public boolean includeInDocs(final DocumentedFeature documentedFeature, 
final ClassDoc classDoc, final Class clazz) {

  ^
  symbol:   class ClassDoc
  location: class WDLDoclet
/<>/src/main/java/org/broadinstitute/barclay/help/WDLDoclet.java:57:
 error: package com.sun.javadoc does not exist
final com.sun.javadoc.ClassDoc classDoc,
 ^
/<>/src/main/java/org/broadinstitute/barclay/help/DefaultDocWorkUnitHandler.java:3:
 error: package com.sun.javadoc does not exist
import com.sun.javadoc.ClassDoc;
  ^
/<>/sr

Bug#1011463: libgirepository-1.0-1: 1.72.0-1+b1 breaks python-gi (<< 3.42.0-1+b1)

[Горбешко Богдан]

Okay, I sacrificed decibel-audio-player and volti (wasn't using them 
long ago anyway).


But it still breaks ruby-gobject-introspection. Sid has a newer version, 
which depends on some non-existent libgirepository-1.0-1-with-libffi8 
though. So it's probably better to wait until the dependencies settle down.


On 23.05.2022 18:00, Simon McVittie wrote:

On Mon, 23 May 2022 at 16:59:55 +0300, Bohdan Horbeshko wrote:

libgirepository-1.0-1: 1.72.0-1+b1 breaks python-gi (<< 3.42.0-1+b1)

Yes, that is a true statement. If python-gi still existed in Debian,
then you would not be able to use new versions of libgirepository-1.0-1
together with old versions of python-gi, because old versions of
python(3)-gi were compiled against libffi7 (or older), but the new
libgirepository-1.0-1 exposes libffi8 in its ABI. The changes to struct
sizes between libffi7 and libffi8 would cause python-gi to crash on at
least some CPU architectures.

Breaks: python-gi (with no version constraint) would have the same
practical effect, except that if someone somehow brings back Python 2
support in pygobject, a non-versioned Breaks would require more
coordination.

If you have legacy code that requires python-gi, I would recommend
using it via a container or chroot (perhaps a Docker, Toolbx or schroot
environment with Debian 11 or older, or perhaps Flatpak or similar),
rather than on a host system that needs to run an up-to-date version
of Debian.

 smcv

Bug#1006658: libobject-pad-perl breaks libtickit-widget-scrollbox-perl autopkgtest: malloc_consolidate(): unaligned fastbin chunk detected

[Damyan Ivanov]

Control: notfound 1006658 libtickit-widget-scrollbox-perl/0.11-1
Control: fixed 1006658 0.65-1

> With a recent upload of libobject-pad-perl the autopkgtest of
> libtickit-widget-scrollbox-perl fails in testing when that autopkgtest is
> run with the binary packages of libobject-pad-perl from unstable. It passes
> when run with only packages from testing. In tabular form:
> 
>passfail
> libobject-pad-perl from testing0.61-1
> libtickit-widget-scrollbox-perl from testing0.11-1
> all others from testingfrom testing

This seems to have fixed by itself at some point. The same version of 
libtickit-widget-scrollbox-perl now builds/tests fine with object-pad 
0.65, so marking the bug as fixed in that version.


-- Damyan

Bug#1011343: WISHLIST: Offical ALL-IN-ONE images?

[sp...@caiway.net]

On Tue, 24 May 2022 00:51:35 +1200
Mike Hosken  wrote:

> Hi Arne,
> 
> Just fyi, archive.debian.org or a mirror site has a copy of the distros you 
> have lost a long with the rest of the official Debian releases. 
> 
> Mike Hosken 
> Sent via my iPhone 

Thanks alot Mike!

Looks good!

Soon I will try to rebuild my lost mirrors.


Thanks again,

Arne

Bug#1004118: E1187: Failed to source defaults.vim

[Dagfinn Ilmari Mannsåker]

James McCoy wrote:
> On Tue, Feb 01, 2022 at 06:19:43PM +0100, Diederik de Haas wrote:
>> $ vim.tiny .ssh/authorized_keys
>> E1187: Failed to source defaults.vim
>> Press ENTER or type command to continue
>
> The binary vim.tiny is an implementation detail.  I tried to move
> them under /usr/libexec, but that caused the alternatives to reset their
> priorities for existing installs, so it had to be reverted.
>
> The intended use is to invoke the binary through the named alternatives
> (vi, view, ex, editor).
>
> When invoked as vi it doesn't, because that triggers Debian's patch to
> only use the tiny config.

Given that `vim.tiny` registers itself for the `view` and `editor`
alternatives, it really should not throw any errors or warnings when
invoked via them (I noticed this because `sudoedit` falls back to
`editor` if the `$EDITOR` and `$VISUAL` environment variables aren't
set).

- ilmari

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

[Faustin Lammler]

Hi Nick!

I can't reproduce this. Can you confirm the steps:
1/ install mailutils;
2/ install mariadb-server (or mysql-server);
3/ remove mailutils (which command did you use);
4/ autoremove

Thanks!

--
Faustin


signature.asc
Description: PGP signature

Bug#1005016: libobject-pad-slotattr-final-perl: Object::Pad::SlotAttr::Final is replaced by Object::Pad::FieldAttr::Final

[gregor herrmann]

On Mon, 23 May 2022 10:37:23 +, Damyan Ivanov wrote:

> > > libobject-pad-slotattr-final-perl - declare Object::Pad slots readonly 
> > > after construction
> > > libobject-pad-slotattr-isa-perl - apply class type constraints to 
> > > Object::Pad slots
> > > libobject-pad-slotattr-lazyinit-perl - lazily initialise Object::Pad 
> > > slots at first read
> > > libobject-pad-slotattr-trigger-perl - invoke an instance method after a 
> > > :writer accessor

> I have just uploaded libobject-pad-fieldattr-final-perl to NEW. The 
> others will follow.

\o/
 
> I guess the deprecated packages should go the RM route? 

Agreed.

> Perhaps after 
> the new ones are accepted?
> Not sure whether the waiting for the replacements to enter unstable is 
> strictly necessary. To me it just feels polite to possible users

s/users/user/ # →

% for p in libobject-pad-slotattr-final-perl libobject-pad-slotattr-isa-perl 
libobject-pad-slotattr-lazyinit-perl libobject-pad-slotattr-trigger-perl; 
popcon $p
libobject-pad-slotattr-final-perl
{'libobject-pad-slotattr-final-perl': 1}
libobject-pad-slotattr-isa-perl
{'libobject-pad-slotattr-isa-perl': 1}
libobject-pad-slotattr-lazyinit-perl
{'libobject-pad-slotattr-lazyinit-perl': 1}
libobject-pad-slotattr-trigger-perl
{'libobject-pad-slotattr-trigger-perl': 1}


Cheers,
gregor

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


signature.asc
Description: Digital Signature

Bug#1001554: node-mocha: FTBFS with webpack5: Error: wrong webpack5 options configuration

[Yadd]

On 23/05/2022 12:05, Pirate Praveen wrote:

Control: tags -1 patch

On Mon, 23 May 2022 14:34:29 +0530 Pirate Praveen 
 wrote:

 >
 >
 > On തി, മേയ് 23 2022 at 02:04:56 വൈകു +05:30:00
 > +05:30:00, Pirate Praveen  wrote:
 > > Control: severity -1 serious
 > >
 > >
 > > Since webpack 5 is in unstable, bumping severity.
 > >
 >
 > After dropping the patch for webpack 4 compatibility, the build now
 > fails with this error.
 >
 > It is not very clear from the log what is missing though.
 >
 > [08:40:30] Webpack errors:
 > [object Object]

Running webpack directly gave the following error,

(debian-sid)pravi@mahishi:~/forge/js-team/node-mocha/workerpool$ webpack 
--entry ./src/index.js -o /tmp/bundle.js --target es5
[webpack-cli] Error: For the selected environment is no default script 
chunk format available:
JSONP Array push can be chosen when 'document' or 'importScripts' is 
available.
CommonJs exports can be chosen when 'require' or node builtins are 
available.
Select an appropriate 'target' to allow selecting one by default, or 
specify the 'output.chunkFormat' directly.

    at /usr/share/nodejs/webpack/lib/config/defaults.js:735:11
    at F (/usr/share/nodejs/webpack/lib/config/defaults.js:72:15)
    at applyOutputDefaults 
(/usr/share/nodejs/webpack/lib/config/defaults.js:716:2)
    at applyWebpackOptionsDefaults 
(/usr/share/nodejs/webpack/lib/config/defaults.js:190:2)

    at createCompiler (/usr/share/nodejs/webpack/lib/webpack.js:77:2)
    at create (/usr/share/nodejs/webpack/lib/webpack.js:134:16)
    at webpack (/usr/share/nodejs/webpack/lib/webpack.js:142:47)
    at WebpackCLI.f [as webpack] 
(/usr/share/nodejs/webpack/lib/index.js:58:16)
    at WebpackCLI.createCompiler 
(/usr/share/nodejs/webpack-cli/lib/webpack-cli.js:2200:23)
    at async WebpackCLI.runWebpack 
(/usr/share/nodejs/webpack-cli/lib/webpack-cli.js:2330:16)


This merge request drops es5 from target and build passes 
https://salsa.debian.org/js-team/node-mocha/-/merge_requests/1 Can 
someone review this and see if it is okay to drop es5 target here?
No, you're wrong here. This is just a missing build dependency to 
node-babel-loader.


Cheers,
Yadd

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

[Faustin Lammler]

Hi Tobias!

Tobias Frost ,
22/04/2022 – 21:41:19 (+0200):

> Unfortunatly it's not fixed...
> 
> Today I came around to upgrade one of my servers from buster to bullseye, and
> after upgrade I've found mariadb-server was uninstalled and I had to manually
> install it afterwards.
> 
> Attached var/log/apt/history.log of the apt dist-upgrade step, including the
> manual fixing.

I can't reproduce this in a full-upgrade from buster (10.3.34-0+deb10u1)
to bullseye (10.5.15-0+deb11u1).

Here are my steps:

| $ podman run -it debian:10 bash
| root@33d890bad500:/# apt update && apt upgrade && apt install mariadb-server

Edit sources.list

| root@33d890bad500:/# apt full-upgrade
| Reading package lists... Done
| Building dependency tree
| Reading state information... Done
| Calculating upgrade... Done
| The following packages were automatically installed and are no longer 
required:
|   libapt-pkg5.0 libffi6 libhogweed4 libidn11 libip4tc0 libjson-c3 libnettle6 
libperl5.28 libreadline5
|   libreadline7 perl-modules-5.28
| Use 'apt autoremove' to remove them.
| The following packages will be REMOVED:
|   galera-3 mariadb-client-10.3 mariadb-client-core-10.3 mariadb-server-10.3 
mariadb-server-core-10.3
| The following NEW packages will be installed:
|   bsdextrautils dbus galera-4 gcc-10-base krb5-locales libapt-pkg6.0 libbpf0 
libbsd0 libclone-perl
|   libcrypt1 libdbus-1-3 libedit2 libexpat1 libfcgi-bin libfcgi0ldbl libffi7 
libgcc-s1 libgssapi-krb5-2
|   libhogweed6 libip4tc2 libjson-c5 libk5crypto3 libkeyutils1 libkrb5-3 
libkrb5support0 libmd0
|   libnettle8 libnsl2 libnss-nis libnss-nisplus libpam-systemd libpcre2-8-0 
libperl5.32 libprocps8
|   libreadline8 libtirpc-common libtirpc3 libxxhash0 logsave 
mariadb-client-10.5
|   mariadb-client-core-10.5 mariadb-server-10.5 mariadb-server-core-10.5 
perl-modules-5.32 procps
|   systemd-timesyncd
| The following packages will be upgraded:
|   apt base-files base-passwd bash bsdutils coreutils dash debconf 
debian-archive-keyring debianutils
|   diffutils dmsetup dpkg e2fsprogs fdisk findutils gawk gpgv grep gzip 
hostname init-system-helpers
|   iproute2 libacl1 libaio1 libapparmor1 libatm1 libattr1 libaudit-common 
libaudit1 libblkid1 libbz2-1.0
|   libc-bin libc6 libcap-ng0 libcap2 libcap2-bin libcgi-fast-perl 
libcgi-pm-perl libcom-err2
|   libconfig-inifiles-perl libcryptsetup12 libdb5.3 libdbd-mysql-perl 
libdbi-perl libdebconfclient0
|   libdevmapper1.02.1 libelf1 libencode-locale-perl libext2fs2 libfcgi-perl 
libfdisk1 libgcrypt20
|   libgdbm-compat4 libgdbm6 libgmp10 libgnutls30 libgpg-error0 libgpm2 
libhtml-parser-perl
|   libhtml-tagset-perl libhtml-template-perl libhttp-date-perl 
libhttp-message-perl libidn11 libidn2-0
|   libio-html-perl libkmod2 liblwp-mediatypes-perl liblz4-1 liblzma5 
libmariadb3 libmnl0 libmount1
|   libmpfr6 libncurses6 libncursesw6 libp11-kit0 libpam-cap libpam-modules 
libpam-modules-bin
|   libpam-runtime libpam0g libpcre3 libpopt0 libseccomp2 libselinux1 
libsemanage-common libsemanage1
|   libsepol1 libsigsegv2 libsmartcols1 libsnappy1v5 libss2 libssl1.1 
libstdc++6 libsystemd0 libtasn1-6
|   libterm-readkey-perl libtimedate-perl libtinfo6 libudev1 libunistring2 
liburi-perl libuuid1 libwrap0
|   libxtables12 libzstd1 login lsb-base lsof mariadb-common mariadb-server 
mawk mount mysql-common
|   ncurses-base ncurses-bin netbase passwd perl perl-base psmisc 
readline-common rsync socat systemd
|   systemd-sysv sysvinit-utils tar tzdata util-linux vim vim-common 
vim-runtime xxd zlib1g
| 137 upgraded, 46 newly installed, 5 to remove and 0 not upgraded.
| Need to get 81.3 MB of archives.
| After this operation, 62.4 MB of additional disk space will be used.
| Do you want to continue? [Y/n]

Can you give me a bit more information on you setup (how could I
re-create your package environment to maybe spot the dependency
problem?).

Cheers!

-- 
Faustin


signature.asc
Description: PGP signature

Bug#1011467: perltidy: Newer upstream release available

[gregor herrmann]

Package: perltidy
Version: 20210717-1
Severity: wishlist
X-Debbugs-Cc: debian-p...@lists.debian.org

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi Don,

I was looking into packaging App::perlimports and found that it wants
a newer Pler::Tidy than what we currently have in Debian:

dh-make-perl output:

Perl::Tidy is available locally as perltidy (= 20210717-1), but does not 
satisfy 20220217
+ Perl::Tidy >= 20220217 found in perltidy (>= 20220217)

Could you upgrade the package to 20220217 and/or shall we move it to
the Debian Perl Group?


Cheers,
gregor


-BEGIN PGP SIGNATURE-

iQKTBAEBCgB9FiEE0eExbpOnYKgQTYX6uzpoAYZJqgYFAmKLouFfFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEQx
RTEzMTZFOTNBNzYwQTgxMDREODVGQUJCM0E2ODAxODY0OUFBMDYACgkQuzpoAYZJ
qgZaaA//aWYrUY6ik4ioQEdxGa3x2UuAUunc4LTb0JMTkpoDKj5UQ5lnX9xOKPb/
iCf7DdPquVkxFjjqmWYcqQh8sW+JqrQ3YZTBtgTeYlCpJ93i08eqjBSlTHTadOTe
/DgmvlFNhoZMP7BeJxfWEF4DGJ/QpQTNzQ5Yuti34fAct/kCh1s4X1vRZBeNJVcl
z00pwcFDO866ihyX2jHDTripp0m4R/rqCTxWHRjhF/OAHtTbcuAbXmNAMnLCD6s/
AJua029IaSqBbP8JigNb5G6GYC4UVDeUsrJAxDOdUUfsQX/6IfctaVlu3Tdxrv4Q
ID5NtB4E8Qm0vyZk1ue+BrMqe9LzkGxWlOsO8277IbE7YJufGWolKQDjsnQxUEr+
skZSm26tXUl4/xWfKHBdJVR1hzkqKnhW+HkjEVYNweRVWZ9w3Kmz92DBBHkB3F9o
2dIwODCqb3Idi8Blr0whTJaBY5/YxWR4JhR1ghK+Es3IcYvNn9JLcnTz7iQzCFCg
OHx4pANFqHH18zI/q0Le4iVq6yEnGhnKzTx8VD5xBwqazz+yB2YK5XSwn7Gnygeu
rm816hGYZHCRnPPcAjN9tJxgor6/2Vqo//Q23Qmiu317MVqmVFChyQ8VrN3KZyA2
udl0UuvyImevX1giLLC9l5DNQKrEP1XpP6hM5q/1/5SbT0Z1Wec=
=62Sj
-END PGP SIGNATURE-

Bug#1011463: libgirepository-1.0-1: 1.72.0-1+b1 breaks python-gi (<< 3.42.0-1+b1)

[Simon McVittie]

On Mon, 23 May 2022 at 16:59:55 +0300, Bohdan Horbeshko wrote:
> libgirepository-1.0-1: 1.72.0-1+b1 breaks python-gi (<< 3.42.0-1+b1)

Yes, that is a true statement. If python-gi still existed in Debian,
then you would not be able to use new versions of libgirepository-1.0-1
together with old versions of python-gi, because old versions of
python(3)-gi were compiled against libffi7 (or older), but the new
libgirepository-1.0-1 exposes libffi8 in its ABI. The changes to struct
sizes between libffi7 and libffi8 would cause python-gi to crash on at
least some CPU architectures.

Breaks: python-gi (with no version constraint) would have the same
practical effect, except that if someone somehow brings back Python 2
support in pygobject, a non-versioned Breaks would require more
coordination.

If you have legacy code that requires python-gi, I would recommend
using it via a container or chroot (perhaps a Docker, Toolbx or schroot
environment with Debian 11 or older, or perhaps Flatpak or similar),
rather than on a host system that needs to run an up-to-date version
of Debian.

smcv

Bug#1006111: [debian-mysql] Bug#1006111: Bug#1006111: mariadb-server: wrong groupby result in newly filled myISAM table

[Faustin Lammler]

Hi Cameron!

On Fri, May 20, 2022 at 10:19 PM Cameron Davidson  wrote:
> the issue I reported has been fixed for me  in the recent update.

Can I kindly ask you to close this bug report if you think that it is
resolved?

--
Faustin


signature.asc
Description: PGP signature

Bug#1009290: [debian-mysql] Bug#1009290: mariadb-server-10.6: Fails to start on live system

[Denys Nykula]

> > sudo rm -rf /var/lib/mysql/*
> > sudo -u mysql mariadb-install-db

Thanks Faustin, something was fixed between 10.6.7-3 and 10.6.8-1 that
made mariadb-install-db succeed for me since today morning.

With the March packages it kept failing every time during or after the
InnoDB initialization (as I mentioned, I started clean every time,
removing the mysql directories in /etc and /var).

Bug#963727: dh-make-{elpa,perl}: move duplicate code to a library

[gregor herrmann]

On Fri, 26 Jun 2020 11:38:48 +0500, Lev Lamberov wrote:

> Hi,

Sorry for replying so late, somehow this bug fell throught the
cracks.
 
> dh-make-elpa is heavily based on dh-make-perl (thanks to all who
> were/are involved into whis nice tool). Both share the same
> object-oriented structure and some code. Recently, dh-make-elpa was
> untied from dh-make-perl, so now the former doesn't depend on the
> latter. But this was done by copying some code from dh-make-perl without
> changes. The better option would be to move duplicate code to a library.

Makes sense.

> It would be nice to identify those methods which may be useful for
> various (possible) implementations of dh-make- and are
> unlikely to change significantly in the future. Those methods could be
> moved to, say, DhMake::Packaging.

Agreed.
 
> I would like to implement changes for both dh-make{elpa,perl}, but first
> we should discuss what should be done and in which way. So, CCing Debian
> Perl Group mailing list, but I think that it's better to keep the
> discussion in one place, that is, in this bug report.

From a dh-make-perl perspective I think we are happy with everything
which "only" moves functionality around without breaking anything.
So if you are still planning to work on this task, please go ahead
and send patches/merge requests.


Cheers,
gregor

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


signature.asc
Description: Digital Signature

Bug#1011466: ITP: libobject-pad-fieldattr-trigger-perl -- invoke an instance method after a :writer accessor

[Damyan Ivanov]

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

* Package name: libobject-pad-fieldattr-trigger-perl
  Version : 0.06
  Upstream Author : Paul Evans 
* URL : https://metacpan.org/release/Object-Pad-FieldAttr-Trigger
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : invoke an instance method after a :writer accessor

Object::Pad::FieldAttr::Trigger provides a third-party field attribute for
Object::Pad-based classes, which declares that a named instance method shall
be invoked after a generated :writer accessor method is called.

WARNING The ability for Object::Pad to take third-party field attributes is
still new and highly experimental, and subject to much API change in future.
As a result, this module should be considered equally experimental.

This package is a replacement for libobject-pad-slotattr-trigger-perl following
the renaming and deprecation of Object::Pad::SlotAttr::Trigger upstream.

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

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

Bug#1006388: [debian-mysql] Bug#1006388: Bug#1006388: Bug#1006388: libmariadb-dev-compat: multi-arch is not present or not working. I am unable to install multiple architectures into Docker "debian:st

[Faustin Lammler]

Hi Dick!
Can I kindly ask you to close this bug report if you believe that it is
fixed?

Thanks!

Dick Hollenbeck ,
22/05/2022 – 23:24:00 (-0500):

> My docker image is building without error, and this is a new behaviour.
> Something got fixed, and I have no reason to think anything I am using is 
> still broken.
> My docker image is softplc/toolkit
> at docker hub.
> So thank you.

-- 
Faustin



signature.asc
Description: PGP signature

Bug#1009290: [debian-mysql] Bug#1009290: mariadb-server-10.6: Fails to start on live system

[Faustin Lammler]

Hi Denys,
I am not sure that the problem is the same, in your case it seems that
the datadir does not exist or need to be recreated.

If you are sure that nothing can be lost (or that you have backups), you
should try the following:
| sudo systemctl stop mariadb
| sudo rm -rf /var/lib/mysql/*
| sudo -u mysql mariadb-install-db
| Installing MariaDB/MySQL system tables in '/var/lib/mysql' ...
| 2022-05-23 14:18:53 0 [Warning] mariadbd: io_uring_queue_init() failed with 
errno 1
| 2022-05-23 14:18:53 0 [Warning] InnoDB: liburing disabled: falling back to 
innodb_use_native_aio=OFF
| 2022-05-23 14:18:53 0 [Warning] You need to use --log-bin to make 
--expire-logs-days or --binlog-expire-logs-seconds work.
| OK
| ...
| sudo systemctl start mariadb

Regards,

Denys Nykula ,
18/05/2022 – 17:16:00 (+0300):

> Hello. The apt install of mariadb-server-10.6 fails for me too,
> with the same line "Could not execute systemctl" but different
> journal messages. I removed the existing setup in /etc and /var,
> purged dependencies, but install still fails. How do I debug?
> 
> systemd[1]: Starting MariaDB 10.6.7 database server...
> [Note] /usr/sbin/mariadbd (server 10.6.7-MariaDB-3+b1) starting as process 
> 98614 ...
> [Note] InnoDB: The first data file './ibdata1' did not exist. A new 
> tablespace will be created!
> [Note] InnoDB: Compressed tables use zlib 1.2.11
> [Note] InnoDB: Number of pools: 1
> [Note] InnoDB: Using crc32 + pclmulqdq instructions
> [Note] InnoDB: Using liburing
> [Note] InnoDB: Initializing buffer pool, total size = 134217728, chunk size = 
> 134217728
> [Note] InnoDB: Completed initialization of buffer pool
> [Note] InnoDB: Setting file './ibdata1' size to 12 MB. Physically writing the 
> file full; Please wait ... 
> [Note] InnoDB: File './ibdata1' size is now 12 MB.
> [Note] InnoDB: Setting log file ./ib_logfile101 size to 100663296 bytes
> [Note] InnoDB: Renaming log file ./ib_logfile101 to ./ib_logfile0
> [Note] InnoDB: New log file created, LSN=10329
> [Note] InnoDB: Doublewrite buffer not found: creating new
> [Note] InnoDB: Doublewrite buffer created
> [Note] InnoDB: 128 rollback segments are active.
> [Note] InnoDB: Creating shared tablespace for temporary tables 
> [Note] InnoDB: Setting file './ibtmp1' size to 12 MB. Physically writing the 
> file full; Please wait ... 
> [Note] InnoDB: File './ibtmp1' size is now 12 MB.
> [Note] InnoDB: 10.6.7 started; log sequence number 0; transaction id 3
> [Note] Plugin 'FEEDBACK' is disabled.
> [ERROR] Could not open mysql.plugin table: "Table 'mysql.plugin' doesn't 
> exist". Some plugins may be not loaded 
> [Warning] You need to use --log-bin to make --expire-logs-days or 
> --binlog-expire-logs-seconds work.
> [ERROR] Can't open and lock privilege tables: Table 'mysql.servers' doesn't 
> exist
> [Note] Server socket created on IP: '127.0.0.1'.
> [ERROR] Fatal error: Can't open and lock privilege tables: Table 'mysql.db' 
> doesn't exist 
> [ERROR] Aborting 
> Warning: Memory not freed: 280
> systemd[1]: mariadb.service: Main process exited, code=exited, 
> status=1/FAILURE
> systemd[1]: mariadb.service: Failed with result 'exit-code'.
> systemd[1]: Failed to start MariaDB 10.6.7 database server.
> 
> ___
> pkg-mysql-maint mailing list
> pkg-mysql-ma...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-mysql-maint

-- 
Faustin


signature.asc
Description: PGP signature

Bug#1009290: [debian-mysql] Bug#1009290: mariadb-server-10.6: Fails to start on live system

[Faustin Lammler]

Hi Daniel!
Thanks for your detailed report.

I am not able to reproduce this with the latest
mariadb-server-10.6-dbgsym version (10.6.8).

Can you try with the latest version and tell me?

Also, can you describe a bit better your setup?  If this is a filesystem
related issue, I would like to try to reproduce it myself.

I have tested with a systemd container that I have created for these
kind of testing, here are the commands (using podman):

| podman run --name sys-test --rm -d fauust/docker-systemd:debian-sid
| podman exec -it sys-test bash -c "echo \"deb 
http://deb.debian.org/debian-debug/ sid-debug main\" >> /etc/apt/sources.list 
&& apt update && apt install -y mariadb-server-10.6-dbgsym"

Cheers!

Daniel Lewart ,
11/04/2022 – 00:20:00 (-0500):

> Package: mariadb-server-10.6
> Version: 1:10.6.7-3
> Severity: important
> 
> Debian MariaDB Maintainers,
> 
> Live Build (--distribution testing) image from April 2022.
> 8 GB RAM, so should be plenty of disk space available.
> 
> $ sudo apt install mariadb-server-10.6-dbgsym
> ...
> Setting up mariadb-server-10.6 (1:10.6.7-3) ...
> Created symlink /etc/systemd/system/multi-user.target.wants/mariadb.service → 
> /lib/systemd/system/mariadb.service.
> Could not execute systemctl:  at /usr/bin/deb-systemd-invoke line 142.
> ...
> 
> $ sudo journalctl | grep -i mariadb | cut -c58-
> [See below]
> 
> Perhaps this is similar to:
>   #983002 - plocate: does not work with /var on overlayfs
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=983002
> 
> Please let me know any additional information that you could use.
> 
> Thank you!
> Daniel Lewart
> Urbana, Illinois
> ---
> 2022-04-10 22:53:02 0 [Warning] InnoDB: Retry attempts for writing partial 
> data failed.
> 2022-04-10 22:53:02 0 [ERROR] InnoDB: Write to file ./ibdata1 failed at 
> offset 0, 1048576 bytes should have been written, only 0 were written. 
> Operating system error number 22. Check that your OS and file system support 
> files of this size. Check also that the disk is not full or a disk quota 
> exceeded.
> 2022-04-10 22:53:02 0 [ERROR] InnoDB: Error number 22 means 'Invalid argument'
> 2022-04-10 22:53:02 0 [ERROR] InnoDB: Could not set the file size of 
> './ibdata1'. Probably out of disk space
> 2022-04-10 22:53:02 0 [ERROR] InnoDB: Database creation was aborted with 
> error Generic error. You may need to delete the ibdata1 file before trying to 
> start up again.
> 2022-04-10 22:53:02 0 [ERROR] InnoDB: Operating system error number 22 in a 
> file operation.
> 2022-04-10 22:53:02 0 [ERROR] InnoDB: Error number 22 means 'Invalid argument'
> 2022-04-10 22:53:02 0 [ERROR] InnoDB: File (unknown): 'close' returned OS 
> error 222. Cannot continue operation
> 220410 22:53:02 [ERROR] mysqld got signal 6 ;
> This could be because you hit a bug. It is also possible that this binary
> or one of the libraries it was linked against is corrupt, improperly built,
> or misconfigured. This error can also be caused by malfunctioning hardware.
> 
> To report this bug, see https://mariadb.com/kb/en/reporting-bugs
> 
> We will try our best to scrape up some info that will hopefully help
> diagnose the problem, but since we have already crashed,
> something is definitely wrong and this may fail.
> 
> Server version: 10.6.7-MariaDB-3
> key_buffer_size=134217728
> read_buffer_size=131072
> max_used_connections=0
> max_threads=153
> thread_count=0
> It is possible that mysqld could use up to
> key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 467957 
> K  bytes of memory
> Hope that's ok; if not, decrease some variables in the equation.
> 
> Thread pointer: 0x0
> Attempting backtrace. You can use the following information to find out
> where mysqld died. If you see no messages after this, something went
> terribly wrong...
> stack_bottom = 0x0 thread_stack 0x49000
> 2022-04-10 22:53:02 0 [ERROR] InnoDB: Operating system error number 9 in a 
> file operation.
> 2022-04-10 22:53:02 0 [ERROR] InnoDB: Error number 9 means 'Bad file 
> descriptor'
> 2022-04-10 22:53:02 0 [ERROR] InnoDB: File (unknown): 'close' returned OS 
> error 209. Cannot continue operation
> Printing to addr2line failed
> /usr/sbin/mariadbd(my_print_stacktrace+0x2e)[0x555d0aa77f0e]
> /usr/sbin/mariadbd(handle_fatal_signal+0x478)[0x555d0a5c5268]
> 2022-04-10 22:53:02 0 [ERROR] InnoDB: Operating system error number 9 in a 
> file operation.
> 2022-04-10 22:53:02 0 [ERROR] InnoDB: Error number 9 means 'Bad file 
> descriptor'
> 2022-04-10 22:53:02 0 [ERROR] InnoDB: File (unknown): 'close' returned OS 
> error 209. Cannot continue operation
> /lib/x86_64-linux-gnu/libpthread.so.0(+0x12200)[0x7f606ba96200]
> 2022-04-10 22:53:02 0 [ERROR] InnoDB: Operating system error number 9 in a 
> file operation.
> 2022-04-10 22:53:02 0 [ERROR] InnoDB: Error number 9 means 'Bad file 
> descriptor'
> 2022-04-10 22:53:02 0 [ERROR] InnoDB: File (unknown): 'close' returned OS 
> error 209. Cannot continue operation
> /lib/x86_64-linux-gnu/libc

Bug#1011465: ITP: libobject-pad-fieldattr-lazyinit-perl -- lazily initialise Object::Pad fields at first read

[Damyan Ivanov]

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

* Package name: libobject-pad-fieldattr-lazyinit-perl
  Version : 0.05
  Upstream Author : Paul Evans 
* URL : https://metacpan.org/release/Object-Pad-FieldAttr-LazyInit
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : lazily initialise Object::Pad fields at first read

Object::Pad::FieldAttr::LazyInit provides a third-party field attribute for
Object::Pad-based classes, which declares that the field it is attached to
has a lazy initialisation method, which will be called the first time the
field's value is read from.

WARNING The ability for Object::Pad to take third-party field attributes is
still new and highly experimental, and subject to much API change in future.
As a result, this module should be considered equally experimental.

This package is a replacement for libobject-pad-slotattr-lazyinit-perl
following the renaming and deprecation of Object::Pad::SlotAttr::LazyInit
upstream.

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

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

Bug#1011449: Acknowledgement (pidgin cannot resume interrupted XMPP connection if no srv_rec available.)

[Mad Horse]

There is already a fix ( 
https://keep.imfreedom.org/pidgin/pidgin/rev/ea52fcc50e50 ) on pidgin's 
repository, although the approach is different.

Bug#1011135: netty: FTBFS with OpenJDK 17 due to removed constants in sun.security.x509.AlgorithmId

[tony mancill]

On Tue, May 17, 2022 at 02:04:18PM +0200, Emmanuel Bourg wrote:
> Source: netty
> Version: 1:4.1.48-4
> 
> netty fails to build with Java 17, it uses a constant from an internal class 
> that was removed:
> 
>   [INFO] -
>   [ERROR] COMPILATION ERROR :
>   [INFO] -
>   [ERROR] 
> /<>/handler/src/main/java/io/netty/handler/ssl/util/OpenJdkSelfSignedCertGenerator.java:[69,70]
>  error: cannot find symbol
> symbol:   variable sha256WithRSAEncryption_oid
> location: class AlgorithmId
>   [INFO] 1 error
>   [INFO] -

This use was removed from the upstream sources in release 4.1.52 and
later, so this can be resolved with an upstream version update.

https://github.com/netty/netty/commit/bb184794341255cf02f9b7156c5ad828b172fdab

Bug#1011463: libgirepository-1.0-1: 1.72.0-1+b1 breaks python-gi (<< 3.42.0-1+b1)

[Bohdan Horbeshko]

Package: libgirepository-1.0-1
Version: 1.68.0-2
Severity: normal

Dear Maintainer,

the fact it breaks only older versions rather than python-gi completely
suggests that a newer version exists, but where? AFAIK, publishing .debs
stopped on 3.30.4-1, and I couldn't find newer versions in other
distributions as well. Did some persons build the package themselves, or
maybe converted .rpm's?

Or maybe this version limit was just copied from python3-gi with an
assumption that python-gi is an alias for python3-gi already rather than
a Python 2 version?


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

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

Versions of packages libgirepository-1.0-1 depends on:
ii  libc6 2.33-2
ii  libffi7   3.3-6
ii  libglib2.0-0  2.70.2-1

libgirepository-1.0-1 recommends no packages.

libgirepository-1.0-1 suggests no packages.

-- no debconf information

Bug#1011462: ITP: libobject-pad-fieldattr-isa-perl -- apply class type constraints to Object::Pad fields

[Damyan Ivanov]

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

* Package name: libobject-pad-fieldattr-isa-perl
  Version : 0.03
  Upstream Author : Paul Evans 
* URL : https://metacpan.org/release/Object-Pad-FieldAttr-Isa
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : apply class type constraints to Object::Pad fields

Object::Pad::FieldAttr::Isa provides a third-party field attribute for
Object::Pad-based classes, which declares that values assigned to the field
must conform to a given object type.

WARNING The ability for Object::Pad to take third-party field attributes is
still new and highly experimental, and subject to much API change in future.
As a result, this module should be considered equally experimental.

This package is a replacement for libobject-pad-slotattr-isa following
the renaming and deprecation of Object::Pad::SlotAttr::Isa upstream.

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

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

Bug#1011440: libsnmp-perl: behaviour fixed in do_not_callback_for_failed_reports.diff reintroduced in bullseye

[Craig Small]

Hi Ole,
  It looks like that offending code wasn't removed, it was just
relocated further along [1].
Looking at what they have done for net-snmp 5.9.2 snmplib/snmp_api.c
isn't changed between 5.9 and 5.9.2 so I'll apply it as the problem
isn't going away.

Your bug report was fine BTW. If there was an easy proof of concept
that is even better but this looks like its a timing issue with
delayed responses. The information helped get a resolution for me
pretty quickly.

 - Craig

1: 
https://github.com/net-snmp/net-snmp/blob/V5-9-patches/snmplib/snmp_api.c#L5772

Bug#162917: Превышена квота электронной почты

[support]

-- 
Размер вашего почтового ящика достиг предела квоты, что составляет более
90% вашей почтовой квоты. Вы не сможете отправлять и получать письма и
свою электронную почту.
Пожалуйста, нажмите на ссылку ниже, чтобы подтвердить свою учетную
запись, чтобы избежать превышения квоты.

>Нажмите здесь [1]

Последнее предупреждение: если вы не увеличите размер почтового ящика
прямо сейчас, это обязательно приведет к постоянной невозможности войти
в ваш почтовый ящик. 

Links:
--
[1] http://iandeconstructionllc.com/wp-content/plugins/vify.php

Bug#1011343: WISHLIST: Offical ALL-IN-ONE images?

[Mike Hosken]

Hi Arne,

Just fyi, archive.debian.org or a mirror site has a copy of the distros you 
have lost a long with the rest of the official Debian releases. 

Mike Hosken 
Sent via my iPhone 

> On 24/05/2022, at 00:09, sp...@caiway.net wrote:
> 
> On Sat, 21 May 2022 13:33:02 +0800
> Zhang Boyang  wrote:
> 
>> Hi,
>> 
>> Indeed, I admit super-big-iso is a crazy idea, and a local mirror is 
>> more useful in most cases. I think there is a few special cases that a 
>> super-big-iso might be more useful.
>> 
>> 1) Computers / Virtual Machines isolated from public internet or have no 
>> network at all. It is convenient to have such an ISO to install software 
>> on demand. A single file is much more convenient than setting up a local 
>> mirror. It's also easy to manage or verify integrity, if frequent 
>> updates are not needed.
>> 
>> 2) Archival purposes. If someone (in future, for example, in 2042) want 
>> to install a very old debian system, he/she may grab the big ISO and all 
>> he/she need is that single file. Although it's not easy to grab the file 
>> in far future, but I guess there is always someone crazy enough to 
>> archive all files, isn't it? :P
>> 
> 
> Hi Zhang!
> 
> A very good idea!
> 
> I have local repositories mirrorred with debmirror, all versions.
> Suddenly I found my archives of the old distributions were (almost) empty.
> 
> bo is lost
> potato is lost
> sarge is lost
> etch is lost
> lenny is lost
> 
> Upstream was deleted and debmirror, well, just mirrored them.
> 
> I spend several hours to find intact repositories for them globally, did not 
> succeed.
> 
> So having another way of keeping debian history for future generations is a 
> very good idea in my opinion!
> 
> Arne
> 
> 

Bug#1011461: Instructions on how to install wine32 gets armhf rather than i386 packages

[Niels Möller]

Package: wine
Version: 5.0.3-3

Hi, I was trying to run a 32-bit windows executable using wine (which
via /etc/alternatives is set to be wine-stable). This is what it looked
like:

  $ file aes-test.exe 
  aes-test.exe: PE32 executable (console) Intel 80386, for MS Windows
 
  $ wine aes-test.exe 
  it looks like wine32 is missing, you should install it.
  multiarch needs to be enabled first.  as root, please
  execute "dpkg --add-architecture i386 && apt-get update &&
  apt-get install wine32"

So error message is rather clear; wine32 is missing and I have to install
it. However, when following the above instructions, apt-get wants to
install armhf packages. This is what I get from the install command:

  # apt-get install wine32
  Reading package lists... Done
  Building dependency tree... Done
  Reading state information... Done
  The following additional packages will be installed:
glib-networking:armhf gstreamer1.0-plugins-base:armhf 
gstreamer1.0-plugins-good:armhf
gstreamer1.0-x:armhf libaa1:armhf libaom0:armhf libasound2:armhf 
libasound2-plugins:armhf
libasyncns0:armhf libavahi-client3:armhf libavahi-common-data:armhf 
libavahi-common3:armhf
libavc1394-0:armhf libavcodec58:armhf libavresample4:armhf libavutil56:armhf
libblkid1:armhf libbrotli1:armhf libbsd0:armhf libbz2-1.0:armhf 
libcaca0:armhf
libcairo-gobject2:armhf libcairo2:armhf libcap2:armhf libcapi20-3:armhf
...

That doesn't seem right. My foreign architectures are

  # dpkg --print-foreign-architectures
  armhf
  arm64
  ppc64el
  s390x
  i386

If I instead use

  # apt-get install wine32:i386

then I do get i386 packages, as I expected, including a working wine32.

Not clear to me if apt-get is doing something unexpected, or when the
existing wine32:armhf package is useful. But anyway, when wine fails to
run a 32-bit (i386) windows executable, due to missing wine32, I'd
suggest that the instructions it displays should be updated to say
"apt-get install wine32:i386".

Regards,
/Niels Möller

-- 
Niels Möller. PGP key CB4962D070D77D7FCB8BA36271D8F1FF368C6677.
Internet email is subject to wholesale government surveillance.

Bug#1011460: ITP: gnome-shell-extension-flypie -- an innovative marking menu written as a GNOME Shell extension

[M. Zhou]

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

* Package name: gnome-shell-extension-flypie
  Upstream Author : Simon Schneegans
* URL : https://github.com/Schneegans/Fly-Pie
* License : MIT/X
  Programming Lang: Javascript
  Description : an innovative marking menu written as a GNOME Shell 
extension

Generally I don't like packaging fancy stuff for Debian. But this
literally surprised me, and brings me a very familiar feeling for
game menus designed for quick operation. If you are a gamer who
like recent action games a lot, I think you may like this extension as well.

Basically the marking menu is to pop up a circle-shaped menu,
where selection is made by the mouse position relative to
the circle center upon key release.

And it has got an achievement system like games... LOL

Bug#1011343: WISHLIST: Offical ALL-IN-ONE images?

[sp...@caiway.net]

On Sat, 21 May 2022 13:33:02 +0800
Zhang Boyang  wrote:

> Hi,
> 
> Indeed, I admit super-big-iso is a crazy idea, and a local mirror is 
> more useful in most cases. I think there is a few special cases that a 
> super-big-iso might be more useful.
> 
> 1) Computers / Virtual Machines isolated from public internet or have no 
> network at all. It is convenient to have such an ISO to install software 
> on demand. A single file is much more convenient than setting up a local 
> mirror. It's also easy to manage or verify integrity, if frequent 
> updates are not needed.
> 
> 2) Archival purposes. If someone (in future, for example, in 2042) want 
> to install a very old debian system, he/she may grab the big ISO and all 
> he/she need is that single file. Although it's not easy to grab the file 
> in far future, but I guess there is always someone crazy enough to 
> archive all files, isn't it? :P
> 

Hi Zhang!

A very good idea!

I have local repositories mirrorred with debmirror, all versions.
Suddenly I found my archives of the old distributions were (almost) empty.

bo is lost
potato is lost
sarge is lost
etch is lost
lenny is lost

Upstream was deleted and debmirror, well, just mirrored them.

I spend several hours to find intact repositories for them globally, did not 
succeed.

So having another way of keeping debian history for future generations is a 
very good idea in my opinion!

Arne
  

Bug#1011446: q2-demux, q2-taxa: replace node-uglifyjs-webpack-plugin with node-terser-webpack-plugin

[Andreas Tille]

Hi,

Am Mon, May 23, 2022 at 10:12:23AM +0530 schrieb Pirate Praveen:
> Package: q2-demux,q2-taxa
> severity: serious
> Control: block 977311 by -1
> 
> node-uglifyjs-webpack-plugin is dead upstream and we want to remove it from
> debian, please switch to using node-terser-webpack-plugin.

Hmmm, I tried to push a fix quickly but the new package does not seem to
be a plugin replacment as you can see in Salsa CI:

  https://salsa.debian.org/med-team/q2-demux/-/jobs/2798791

Any idea how this can be fixed?

Kind regards

   Andreas.

-- 
http://fam-tille.de

Bug#1011458: snowflake: CVE-2022-29222 - fails to reject untrustworthy client certificates due to missing checks on private key

[Neil Williams]

Source: snowflake
Version: 1.1.0-2
Severity: grave
Tags: security
Justification: user security hole
X-Debbugs-Cc: codeh...@debian.org, Debian Security Team 


Hi,

The following vulnerability was published for snowflake.

CVE-2022-29222[0]:
| Pion DTLS is a Go implementation of Datagram Transport Layer Security.
| Prior to version 2.1.5, a DTLS Client could provide a Certificate that
| it doesn't posses the private key for and Pion DTLS wouldn't reject
| it. This issue affects users that are using Client certificates only.
| The connection itself is still secure. The Certificate provided by
| clients can't be trusted when using a Pion DTLS server prior to
| version 2.1.5. Users should upgrade to version 2.1.5 to receive a
| patch. There are currently no known workarounds.


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

For further information see:

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

Please adjust the affected versions in the BTS as needed.


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

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

Bug#980542: [Pkg-freeipa-devel] Bug#980542: cockpit : 389ds tab is empty and does not appear in installed applications

[Timo Aaltonen]

Andreas Bock kirjoitti 20.5.2022 klo 16.06:
I can confirm this bug for Ubuntu Jammy and kinetic. All files are 
missing in '/usr/share/cockpit/389-console'.


Already posted this in Ubuntu Launchpad as 
https://bugs.launchpad.net/ubuntu/+source/389-ds-base/+bug/1974329:


What happend:
After installing the server and afterwards the '389-ds' package 
including all dependencies, Cockpit lacks the plugins entry "389 
Directory Server" in the Web-GUI.


How to reproduce:
I installed Ubuntu server 22.04 multiple times from scratch. Either as 
minimal but althought as default installation does not help. After lots 
of testing and reinstalling the server I found that all files from 
'/usr/share/cockpit/389-console' are missing for the jammy and kinetic 
package 'cockpit-389-ds'. If one compares the package content to focal 
one will see the difference.


What I have done to resolve the issue:
$ wget 
https://github.com/389ds/389-ds-base/archive/389-ds-base-2.0.15.tar.gz

$ tar xzf 389-ds-base-2.0.15.tar.gz
$ cd ~/389-ds-base-2.0.15/src/cockpit/389-console
$ sh ./buildAndRun.sh # Stop the script after downloading and compling 
with ^C
$ sudo cp ~/389-ds-base-2.0.15/src/cockpit/389-console/dist/* 
/usr/share/cockpit/389-console




If you have any further questions feel free to contact me.

Regards, Andreas


Thanks for the hint, the tarballs stopped having prebuilt files for 
cockpit when 389 migrated to github. This is now being tracked at:


https://github.com/389ds/389-ds-base/issues/5302



--
t

Bug#1005016: libobject-pad-slotattr-final-perl: Object::Pad::SlotAttr::Final is replaced by Object::Pad::FieldAttr::Final

[Damyan Ivanov]

-=| gregor herrmann, 09.02.2022 21:18:13 +0100 |=-
> > % apt-cache --names-only search libobject-pad-slot | grep -v 
> > dbgsym
> > libobject-pad-slotattr-final-perl - declare Object::Pad slots readonly 
> > after construction
> > libobject-pad-slotattr-isa-perl - apply class type constraints to 
> > Object::Pad slots
> > libobject-pad-slotattr-lazyinit-perl - lazily initialise Object::Pad slots 
> > at first read
> > libobject-pad-slotattr-trigger-perl - invoke an instance method after a 
> > :writer accessor
> 
> Alright, making this a bit more formal:
> - cloning the bug for the 3 other affected packages
> - marking them as serious as they currently block the perl 5.34
>   transition (by way of blocking the rebuilt arch:any libobject-pad-perl
>   as it breaks the 4 autopkgtests); this could be ignored, but the
>   4 packages are doomed anyway, so an RC bug makes removal from
>   testing more transparent.

I have just uploaded libobject-pad-fieldattr-final-perl to NEW. The 
others will follow.

I guess the deprecated packages should go the RM route? Perhaps after 
the new ones are accepted?

Not sure whether the waiting for the replacements to enter unstable is 
strictly necessary. To me it just feels polite to possible users

-- Damyan