Bug#1009907: cloning it back to smbclient for people to see

2022-04-24 Thread Michael Tokarev

Control: clone -1 -2
Control: reassing -2 smbclient 2:4.16.0+dfsg-1
Control: tag -2 - upstream patch
Control: block -2 by -1

Since this is something people see in samba and are trying to look up in between
samba bugs, let's clone it properly.

It would be really nice to have this patch backported to bullseye. I have really
large amount of requests asking to backport samba 4.16 to bulleye (which is 
trivial)
but it will give us this issue in gvfs.  Well, at least the server part should 
work
fine.

Thanks,

/mjt



Bug#1010118: qtwebkit-opensource-src FTBFS with ICU 71.1

2022-04-24 Thread GCS
Control: tags -1 +patch

On Sun, Apr 24, 2022 at 10:18 PM Adrian Bunk  wrote:
> Source: qtwebkit-opensource-src
> Version: 5.212.0~alpha4-14
> Severity: serious
> Tags: ftbfs
>
> In file included from 
> /<>/Source/WebCore/platform/text/TextAllInOne.cpp:31:
> /<>/Source/WebCore/platform/text/TextCodecICU.cpp: In member 
> function ‘void WebCore::TextCodecICU::createICUConverter() const’:
> /<>/Source/WebCore/platform/text/TextCodecICU.cpp:311:42: error: 
> ‘TRUE’ was not declared in this scope
>   311 | ucnv_setFallback(m_converterICU, TRUE);
>   |  ^~~~
> ...
 My bad, submitting the required patch only now.

Regards,
Laszalo/GCS
Description: replace old ICU TRUE / FALSE constants
 For some time ICU (since 68.1+ for sure) no longer specify nonstandard
 TRUE / FALSE constants. Use UBool(1) and UBool(0) instead.
Author: Laszlo Boszormenyi (GCS) 
Bug-Debian: https://bugs.debian.org/1010118
Forwarded: no
Last-Update: 2022-04-24

---

--- qtwebkit-opensource-src-5.212.0~alpha4.orig/Source/WebCore/platform/text/TextCodecICU.cpp
+++ qtwebkit-opensource-src-5.212.0~alpha4/Source/WebCore/platform/text/TextCodecICU.cpp
@@ -308,7 +308,7 @@ void TextCodecICU::createICUConverter()
 m_converterICU = ucnv_open(m_canonicalConverterName, );
 ASSERT(U_SUCCESS(err));
 if (m_converterICU)
-ucnv_setFallback(m_converterICU, TRUE);
+ucnv_setFallback(m_converterICU, UBool(1));
 }
 
 int TextCodecICU::decodeToBuffer(UChar* target, UChar* targetLimit, const char*& source, const char* sourceLimit, int32_t* offsets, bool flush, UErrorCode& err)
--- qtwebkit-opensource-src-5.212.0~alpha4.orig/Source/WebCore/platform/text/icu/UTextProvider.h
+++ qtwebkit-opensource-src-5.212.0~alpha4/Source/WebCore/platform/text/icu/UTextProvider.h
@@ -80,12 +80,12 @@ inline bool uTextAccessInChunkOrOutOfRan
 // Ensure chunk offset is well formed if computed offset exceeds int32_t range.
 ASSERT(offset < std::numeric_limits::max());
 text->chunkOffset = offset < std::numeric_limits::max() ? static_cast(offset) : 0;
-isAccessible = TRUE;
+isAccessible = UBool(1);
 return true;
 }
 if (nativeIndex >= nativeLength && text->chunkNativeLimit == nativeLength) {
 text->chunkOffset = text->chunkLength;
-isAccessible = FALSE;
+isAccessible = UBool(0);
 return true;
 }
 } else {
@@ -94,12 +94,12 @@ inline bool uTextAccessInChunkOrOutOfRan
 // Ensure chunk offset is well formed if computed offset exceeds int32_t range.
 ASSERT(offset < std::numeric_limits::max());
 text->chunkOffset = offset < std::numeric_limits::max() ? static_cast(offset) : 0;
-isAccessible = TRUE;
+isAccessible = UBool(1);
 return true;
 }
 if (nativeIndex <= 0 && !text->chunkNativeStart) {
 text->chunkOffset = 0;
-isAccessible = FALSE;
+isAccessible = UBool(0);
 return true;
 }
 }
--- qtwebkit-opensource-src-5.212.0~alpha4.orig/Source/WebCore/platform/text/icu/UTextProviderLatin1.cpp
+++ qtwebkit-opensource-src-5.212.0~alpha4/Source/WebCore/platform/text/icu/UTextProviderLatin1.cpp
@@ -100,23 +100,23 @@ static UBool uTextLatin1Access(UText* uT
 if (index < uText->chunkNativeLimit && index >= uText->chunkNativeStart) {
 // Already inside the buffer. Set the new offset.
 uText->chunkOffset = static_cast(index - uText->chunkNativeStart);
-return TRUE;
+return UBool(1);
 }
 if (index >= length && uText->chunkNativeLimit == length) {
 // Off the end of the buffer, but we can't get it.
 uText->chunkOffset = static_cast(index - uText->chunkNativeStart);
-return FALSE;
+return UBool(0);
 }
 } else {
 if (index <= uText->chunkNativeLimit && index > uText->chunkNativeStart) {
 // Already inside the buffer. Set the new offset.
 uText->chunkOffset = static_cast(index - uText->chunkNativeStart);
-return TRUE;
+return UBool(1);
 }
 if (!index && !uText->chunkNativeStart) {
 // Already at the beginning; can't go any farther.
 uText->chunkOffset = 0;
-return FALSE;
+return UBool(0);
 }
 }
 
@@ -144,7 +144,7 @@ static UBool uTextLatin1Access(UText* uT
 
 uText->nativeIndexingLimit = uText->chunkLength;
 
-return TRUE;
+return UBool(1);
 }
 
 static int32_t uTextLatin1Extract(UText* uText, int64_t start, int64_t limit, UChar* dest, int32_t destCapacity, UErrorCode* status)
@@ -336,7 +336,7 @@ static int64_t uTextLatin1ContextAwareNa
 static UBool uTextLatin1ContextAwareAccess(UText* text, int64_t nativeIndex, UBool forward)
 {
 if (!text->context)
-

Bug#1010138: RFA: gandi-cli

2022-04-24 Thread Ben Finney
Package: wnpp
Severity: normal
Control: affects -1 src:gandi-cli

The ‘gandi-cli’ Debian package needs attention and maintenance from
someone who makes real use of the Gandi.net service provider and can
benefit from this command-line utility.

-- 
 \ “I call him Governor Bush because that's the only political |
  `\  office he's ever held legally.” —George Carlin, 2008 |
_o__)  |
Ben Finney 

signature.asc
Description: PGP signature


Bug#1010137: RFP: libmail-dmarc-perl -- Perl implementation of DMARC

2022-04-24 Thread Noah Meyerhans
Package: wnpp
Severity: wishlist

* Package name: libmail-dmarc-perl
  Version : 1.20211209
  Upstream Author : Marc Bradshaw 
* URL : https://metacpan.org/pod/Mail::DMARC
* License : GPL-1+ or Artistic
  Programming Lang: Perl
  Description : Perl implementation of DMARC

Mail::DMARC is a set of Perl modules for implementing DMARC clients.

DMARC, which stands for “Domain-based Message Authentication, Reporting &
Conformance”, is an email authentication, policy, and reporting protocol. It
builds on the widely deployed SPF and DKIM protocols, adding linkage to the
author (“From:”) domain name, published policies for recipient handling of
authentication failures, and reporting from receivers to senders, to improve
and monitor protection of the domain from fraudulent email.

SpamAssassin 4.0 (currently in experimental) makes use of this module to
provide its DMARC support.  I don't mind (co-)maintaining this package, but
ideally it will be done with the help of the pkg-perl group.


Bug#1010136: dsctl shells out to rpm

2022-04-24 Thread Paul R. Tagliamonte
Package: python3-lib389
Version: 2.0.15-1
thanks

```
# dsctl ds cockpit enable
/bin/sh: 1: rpm: not found
Error: The 'cockpit' package is not installed on this system
```

-- 
:wq



Bug#1009858: linux: please consider building the modules necessary for the MNT Reform laptop

2022-04-24 Thread Vagrant Cascadian
Control: tags 1009858 pending

On 2022-04-24, Vagrant Cascadian wrote:
> On 2022-04-19, Johannes Schauer Marin Rodrigues wrote:
>> currently, we add the following to the arm64 kernel config provided by
>> the Debian kernel packaging to build a kernel that powers the MNT Reform
>> 2 open source laptop:
>
> Thanks!
>
> Merged most of the changes so far except...

https://salsa.debian.org/kernel-team/linux/-/commit/aa9f2cfbd99e598ad02043d9238bf7886fc21d1a


live well,
  vagrant



Bug#287371: [xml/sgml-pkgs] Bug#287371: xsltproc: Probable memory leak (when using document()?)

2022-04-24 Thread Vincent Lefevre
On 2022-02-19 18:28:00 +0100, Vincent Lefevre wrote:
> I'll test again (I've been using a fake DTD for the past 15 years).

This has just happened. The consequence is that several unrelated
processes were killed by the OOM killer, including daemons!

[...]
Apr 25 02:44:53 zira systemd[6589]: dconf.service: A process of this unit has 
been killed by the OOM killer.
Apr 25 02:44:53 zira bluetoothd[241267]: Endpoint unregistered: sender=:1.100 
path=/MediaEndpoint/A2DPSource/ldac_hq
Apr 25 02:44:53 zira systemd[1]: user@1000.service: A process of this unit has 
been killed by the OOM killer.
Apr 25 02:44:53 zira bluetoothd[241267]: Endpoint unregistered: sender=:1.100 
path=/MediaEndpoint/A2DPSource/ldac_sq
Apr 25 02:44:53 zira systemd[6589]: pipewire.service: A process of this unit 
has been killed by the OOM killer.
Apr 25 02:44:53 zira bluetoothd[241267]: Endpoint unregistered: sender=:1.100 
path=/MediaEndpoint/A2DPSource/ldac_mq
Apr 25 02:44:53 zira systemd[6589]: pipewire-media-session.service: A process 
of this unit has been killed by the OOM killer.
Apr 25 02:44:53 zira bluetoothd[241267]: Endpoint unregistered: sender=:1.100 
path=/MediaEndpoint/A2DPSink/aptx_hd
Apr 25 02:44:53 zira systemd[6589]: pulseaudio.service: A process of this unit 
has been killed by the OOM killer.
Apr 25 02:44:53 zira bluetoothd[241267]: Endpoint unregistered: sender=:1.100 
path=/MediaEndpoint/A2DPSource/aptx_hd
Apr 25 02:44:53 zira systemd[6589]: pipewire.service: Main process exited, 
code=killed, status=9/KILL
Apr 25 02:44:53 zira bluetoothd[241267]: Endpoint unregistered: sender=:1.100 
path=/MediaEndpoint/A2DPSink/aptx
Apr 25 02:44:53 zira systemd[6589]: pipewire.service: Failed with result 
'oom-kill'.
Apr 25 02:44:53 zira bluetoothd[241267]: Endpoint unregistered: sender=:1.100 
path=/MediaEndpoint/A2DPSource/aptx
Apr 25 02:44:55 zira systemd[1]: user@1000.service: A process of this unit has 
been killed by the OOM killer.
Apr 25 02:44:53 zira bluetoothd[241267]: Endpoint unregistered: sender=:1.100 
path=/MediaEndpoint/A2DPSink/sbc
Apr 25 02:44:55 zira systemd[1]: session-204.scope: A process of this unit has 
been killed by the OOM killer.
Apr 25 02:44:53 zira bluetoothd[241267]: Endpoint unregistered: sender=:1.100 
path=/MediaEndpoint/A2DPSource/sbc
Apr 25 02:44:55 zira systemd[6589]: Requested transaction contradicts existing 
jobs: Resource deadlock avoided
Apr 25 02:44:53 zira acpid[792]: input device has been disconnected, fd 23
Apr 25 02:44:55 zira systemd[6589]: gpg-agent.service: A process of this unit 
has been killed by the OOM killer.
Apr 25 02:44:55 zira bluetoothd[241267]: Endpoint unregistered: sender=:1.100 
path=/MediaEndpoint/A2DPSink/sbc_xq_453
Apr 25 02:44:55 zira systemd[6589]: dbus.service: A process of this unit has 
been killed by the OOM killer.
Apr 25 02:44:55 zira bluetoothd[241267]: Endpoint unregistered: sender=:1.100 
path=/MediaEndpoint/A2DPSource/sbc_xq_453
Apr 25 02:44:55 zira systemd[6589]: at-spi-dbus-bus.service: A process of this 
unit has been killed by the OOM killer.
Apr 25 02:44:55 zira bluetoothd[241267]: Endpoint unregistered: sender=:1.100 
path=/MediaEndpoint/A2DPSink/sbc_xq_512
Apr 25 02:44:55 zira systemd[6589]: gvfs-daemon.service: A process of this unit 
has been killed by the OOM killer.
Apr 25 02:44:55 zira bluetoothd[241267]: Endpoint unregistered: sender=:1.100 
path=/MediaEndpoint/A2DPSource/sbc_xq_512
Apr 25 02:44:55 zira systemd[6589]: pipewire-media-session.service: Main 
process exited, code=killed, status=9/KILL
Apr 25 02:44:55 zira bluetoothd[241267]: Endpoint unregistered: sender=:1.100 
path=/MediaEndpoint/A2DPSink/sbc_xq_552
Apr 25 02:44:55 zira systemd[6589]: pipewire-media-session.service: Failed with 
result 'oom-kill'.
Apr 25 02:44:55 zira bluetoothd[241267]: Endpoint unregistered: sender=:1.100 
path=/MediaEndpoint/A2DPSource/sbc_xq_552
Apr 25 02:44:55 zira systemd[6589]: Stopped PipeWire Media Session Manager.
Apr 25 02:44:56 zira rtkit-daemon[826]: Successfully made thread 289323 of 
process 289323 owned by '1000' high priority at nice level -11.
Apr 25 02:44:55 zira systemd[6589]: pipewire-media-session.service: Consumed 
3.038s CPU time.
Apr 25 02:44:56 zira rtkit-daemon[826]: Supervising 1 threads of 1 processes of 
1 users.
Apr 25 02:44:55 zira systemd[6589]: dbus.service: Main process exited, 
code=killed, status=9/KILL
Apr 25 02:44:56 zira rtkit-daemon[826]: Supervising 1 threads of 1 processes of 
1 users.
Apr 25 02:44:55 zira systemd[6589]: dbus.service: Failed with result 'oom-kill'.
Apr 25 02:44:56 zira rtkit-daemon[826]: Supervising 1 threads of 1 processes of 
1 users.
Apr 25 02:44:55 zira systemd[6589]: gvfs-daemon.service: Main process exited, 
code=killed, status=9/KILL
Apr 25 02:44:56 zira rtkit-daemon[826]: Supervising 1 threads of 1 processes of 
1 users.
Apr 25 02:44:55 zira systemd[6589]: gvfs-daemon.service: Failed with result 
'oom-kill'.
Apr 25 02:44:56 zira rtkit-daemon[826]: Successfully made thread 289329 of 
process 

Bug#1010135: scrcpy 1.17 (debian stable) doesn't work with Android 12, update package

2022-04-24 Thread Pedro Demarco
Package: scrcpy
Version: 1.17
Severity: normal
X-Debbugs-Cc: demarco.ofic...@gmail.com

Dear Maintainer,

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

   * What led up to the situation? "I was using Debian Stable, and Scrcpy 
version that comes with Stable is 1.17, but version 1.17 doesn't work with 
phones that 
have already upgraded to Android 12, take a look at this bug report: 
https://github.com/Genymobile/scrcpy/issues/2129. " 
  
 * What exactly did you do (or not do) that was effective (or
 ineffective)?: I changed my system to Debian Unstable/Sid, and got a 
modern package.

   * What was the outcome of this action?: It worked out no problem.

Hope you have a good week mate!


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

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

Versions of packages scrcpy depends on:
ii  libavcodec58   7:4.4.2-1
ii  libavdevice58  7:4.4.2-1
ii  libavformat58  7:4.4.2-1
ii  libavutil567:4.4.2-1
ii  libc6  2.33-7
ii  libsdl2-2.0-0  2.0.20+dfsg-2
ii  libusb-1.0-0   2:1.0.26-1
ii  scrcpy-server  1.23-1

Versions of packages scrcpy recommends:
ii  adb  1:29.0.6-9

scrcpy suggests no packages.

-- no debconf information



Bug#1003933: w3c-sgml-lib: catalogs for MathML 2.0 are incomplete

2022-04-24 Thread Vincent Lefevre
On 2022-04-23 11:52:23 +0200, Étienne Mollier wrote:
> Since this bug is causing python-biopython removal in testing, I
> have been scratching my head on this issue, and came up with the
> patch in attachment, which complements the catalog to reference
> most MathML 2.0 entities, which are missing.  This seems to fix
> the issue described in the bug description for me, as I don't
> see I/O errors anymore, and have a long listing of the actual
> entities instead.

Thanks for the patch. I've rebuilt the w3c-sgml-lib package with it,
and this seems to work.

The only issue is that when reinstalling the package, I get the
following non-fatal errors:

update-xmlcatalog: error: entity not registered
update-xmlcatalog: error: entity not registered
update-xmlcatalog: error: entity not registered
update-xmlcatalog: error: entity not registered

I don't know whether there can be unwanted side effects or they can
be ignored. The fact that the error message doesn't say which entity
is not registered doesn't help; I've just reported
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1010134
about this lack of details.

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



Bug#1010134: xml-core: please improve message "error: entity not registered" with details

2022-04-24 Thread Vincent Lefevre
Package: xml-core
Version: 0.18+nmu1
Severity: wishlist

When testing the patch for bug 1003933, I get the following error
messages:

update-xmlcatalog: error: entity not registered
update-xmlcatalog: error: entity not registered
update-xmlcatalog: error: entity not registered
update-xmlcatalog: error: entity not registered

They should be more detailed, e.g. telling which entity is not
registered.

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

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

Versions of packages xml-core depends on:
ii  sed4.8-1
ii  sgml-base  1.30

xml-core recommends no packages.

Versions of packages xml-core suggests:
ii  debhelper  13.7.1

-- no debconf information

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



Bug#1009858: linux: please consider building the modules necessary for the MNT Reform laptop

2022-04-24 Thread Vagrant Cascadian
On 2022-04-19, Johannes Schauer Marin Rodrigues wrote:
> currently, we add the following to the arm64 kernel config provided by
> the Debian kernel packaging to build a kernel that powers the MNT Reform
> 2 open source laptop:

Thanks!

Merged most of the changes so far except...


> CONFIG_DRM_CDNS_HDMI_CEC=m
> CONFIG_DRM_IMX_CDNS_MHDP=m

These are not yet in upstream 5.17.x, so I left them out.


> CONFIG_NO_HZ_IDLE=y

It seems that the default defined in debian/config/config is
NO_HZ_FULL=y should default to the same behavior as NO_HZ_IDLE unless a
boot parameter is passed, according to kernel/time/Kconfig.


live well,
  vagrant


signature.asc
Description: PGP signature


Bug#1010096: macaulay2: FTBFS on ppc64el

2022-04-24 Thread Torrance, Douglas

Control: forwarded -1 https://github.com/Macaulay2/M2/issues/2119

On Sun 24 Apr 2022 06:26:35 AM EDT, Sebastian Ramacher  
wrote:

macaulay2 FTBFS on ppc64el:

 ulimit -c unlimited; ulimit -t 700; ulimit -m 85; ulimit -s 8192; ulimit -n 512;  cd /tmp/M2-2532003-0/31-rundir/; GC_MAXIMUM_HEAP_SIZE=400M 
"/<>/M2/usr-dist/powerpc64le-Linux-Debian-buildd-unstable/bin/M2-binary" -q --int --no-randomize --no-readline --silent --stop --print-width 
77 -e 'needsPackage("AssociativeAlgebras",Reload=>true,FileName=>"/<>/M2/Macaulay2/packages/AssociativeAlgebras.m2")' 
<"/tmp/M2-2532003-0/30.m2" >>"/tmp/M2-2532003-0/30.tmp" 2>&1
/tmp/M2-2532003-0/30.tmp:0:1: (output file) error: Macaulay2 killed by signal 9
/tmp/M2-2532003-0/30.m2:0:1: (input file)
M2: *** Error 9
 -- 6.50792 seconds elapsed
 -- running   check(26, "AssociativeAlgebras")   -- 
6.69457 seconds elapsed
 -- running   check(27, "AssociativeAlgebras")   -- 
7.99133 seconds elapsed
 -- running   check(28, "AssociativeAlgebras")   -- 
6.99254 seconds elapsed
 -- capturing check(29, "AssociativeAlgebras")   -- 
8.69268 seconds elapsed
 -- skipping  check(30, "AssociativeAlgebras")   -- 
0.000117095 seconds elapsed
 -- running   check(31, "AssociativeAlgebras")   -- 
7.8834 seconds elapsed
 -- running   check(32, "AssociativeAlgebras")   -- 
8.43175 seconds elapsed
 -- running   check(33, "AssociativeAlgebras")   -- 
6.76101 seconds elapsed
AssociativeAlgebras/tests.m2:729:1-752:1: error:
 -- -- -*- M2-comint -*- hash: 1928805808
 -- Killed
 -- 
../m2/debugging.m2:23:6:(1):[9]: error: test(s) #25 of package AssociativeAlgebras failed.

../m2/testing.m2:135:9:(1):[8]: --back trace--
../m2/methods.m2:154:80:(1):[7]: --back trace--
../m2/option.m2:17:8:(1):[6]: --back trace--
../m2/testing.m2:108:33:(1):[5]: --back trace--
../m2/methods.m2:154:80:(1):[4]: --back trace--
../m2/option.m2:17:8:(1):[3]: --back trace--
currentString:1:82:(3):[2]: --back trace--
Macaulay2/Core/startup.m2.in:561:33:(0):[1]: --back trace--
Macaulay2/Core/startup.m2.in:661:6:(0): --back trace--
make[4]: *** [Makefile:41: check-AssociativeAlgebras] Error 1

See
https://buildd.debian.org/status/fetch.php?pkg=macaulay2=ppc64el=1.19.1%2Bds-6%2Bb2=1650754325=0


Thanks for the report!

The tests for the AssociativeAlgebras package have a history of being flaky.
I'll set it to skip this test (and #31, which failed on another build [1]) on
ppc64el in the next upload.

[1] 
https://buildd.debian.org/status/fetch.php?pkg=macaulay2=ppc64el=1.19.1%2Bds-6%2Bb2=1650804921=0


signature.asc
Description: PGP signature


Bug#1010132: ITP: podman-compose -- Run docker-compose.yml using podman

2022-04-24 Thread Athos Ribeiro
Package: wnpp
Severity: wishlist
Owner: Athos Ribeiro 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: podman-compose
  Version : 1.0.3
  Upstream Author : Muayyad alsadi 
* URL : https://github.com/containers/podman-compose
* License : GPL-2
  Programming Lang: Python
  Description : Run docker-compose.yml using podman

An implementation of docker-compose with podman backend.
The main objective of this project is to be able to run docker-compose.yml
unmodified and rootless.

I'm planning to maintain this package in the Python Team.



Bug#940672: Please add support for HP x2 210 PMIC and sound card

2022-04-24 Thread Diederik de Haas
Control: tag -1 pending

On Wed, 18 Sep 2019 21:46:38 +0200 Benoît Laniel  wrote:
> Package: linux-image-5.3.0-rc5-amd64
> Version: 5.3~rc5-1~exp2
> Severity: wishlist
> Tags: patch
> 
> HP x2 210 has an AXP288 PMIC. Battery driver is already enabled but not
> the charger one. Moreover, the ADC driver is needed to make them work.

I created https://salsa.debian.org/kernel-team/linux/-/merge_requests/465 and 
that has now been merged into the 'sid' branch.
Only those 2 modules needed to be enabled, the rest was already present.

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


Bug#1010130: libfreecad-python3-0.19: Dependency on libboost-regex1.74.0-icu67 no longer available in sid

2022-04-24 Thread Daniel Peter Chokola
Package: libfreecad-python3-0.19
Version: 0.19.4+dfsg1-1
Severity: normal
X-Debbugs-Cc: dan.chok...@gmail.com

Dear Maintainer,

libfreecad-python3-0.19 depends on the virtual package, 
libboost-regex1.74.0-icu67, which is no longer available as libboost-regex1.74 
is built against libicu71. This makes FreeCAD uninstallable.


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

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

Versions of packages libfreecad-python3-0.19 depends on:
ii  libboost-filesystem1.74.01.74.0-14+b1
ii  libboost-program-options1.74.0   1.74.0-14+b1
pn  libboost-regex1.74.0-icu67   
ii  libboost-thread1.74.01.74.0-14+b1
ii  libc62.34-0experimental4
pn  libcoin80c   
ii  libfreetype6 2.11.1+dfsg-1
ii  libgcc-s112-20220319-1
ii  libgl1   1.4.0-1
ii  libglu1-mesa [libglu1]   9.0.2-1
pn  libmedc11
ii  libocct-data-exchange-7.57.5.1+dfsg1-2
ii  libocct-foundation-7.5   7.5.1+dfsg1-2
ii  libocct-modeling-algorithms-7.5  7.5.1+dfsg1-2
ii  libocct-modeling-data-7.57.5.1+dfsg1-2
ii  libocct-ocaf-7.5 7.5.1+dfsg1-2
ii  libocct-visualization-7.57.5.1+dfsg1-2
ii  libopengl0   1.4.0-1
ii  libpyside2-py3-5.15  5.15.2-2+b2
ii  libpython3.103.10.4-3
ii  libqt5concurrent55.15.2+dfsg-16
ii  libqt5core5a 5.15.2+dfsg-16
ii  libqt5gui5   5.15.2+dfsg-16
ii  libqt5network5   5.15.2+dfsg-16
ii  libqt5opengl55.15.2+dfsg-16
ii  libqt5printsupport5  5.15.2+dfsg-16
ii  libqt5svg5   5.15.2-4
ii  libqt5webkit55.212.0~alpha4-14+b1
ii  libqt5widgets5   5.15.2+dfsg-16
ii  libqt5xml5   5.15.2+dfsg-16
pn  libqt5xmlpatterns5   
ii  libshiboken2-py3-5.155.15.2-2+b2
ii  libspnav00.2.3-1+b2
ii  libstdc++6   12-20220319-1
pn  libvtk9.1
ii  libxerces-c3.2   3.2.3+debian-3
pn  libzipios++0v5   
ii  zlib1g   1:1.2.11.dfsg-4

libfreecad-python3-0.19 recommends no packages.

libfreecad-python3-0.19 suggests no packages.



Bug#1010128: linux-image-5.17.0-1-amd64: DKMS Module Rebuild for Broadcom Wireless Chip BCM4352 Fails to Build

2022-04-24 Thread Kurt Meyer
Package: src:linux
Version: 5.17.3-1
Severity: important

Dear Maintainer,

I received the following errors when linux-image-5.17.0-1-amd64 was installed. 
Error also occurred with the linux-headers-5.17.0-1-amd64 package. Result is I 
have no wireless connectivity when booting with kernel version 5.17.0-1. I have 
to boot with the kernel version 5.16.0-6 to have wireless connectivity.

---ERROR START---

Setting up linux-image-5.17.0-1-amd64 (5.17.3-1) ...
I: /vmlinuz is now a symlink to boot/vmlinuz-5.17.0-1-amd64
I: /initrd.img is now a symlink to boot/initrd.img-5.17.0-1-amd64
/etc/kernel/postinst.d/dkms:
dkms: running auto installation service for kernel 5.17.0-1-amd64:Deprecated 
feature
: REMAKE_INITRD
Deprecated feature: Deprecated feature: REMAKE_INITRD
REMAKE_INITRD
Deprecated feature: REMAKE_INITRD
Deprecated feature: REMAKE_INITRD
Deprecated feature: REMAKE_INITRD
Deprecated feature: REMAKE_INITRD
Deprecated feature: REMAKE_INITRD
Deprecated feature: REMAKE_INITRD
Deprecated feature: REMAKE_INITRD
Deprecated feature: REMAKE_INITRD
Deprecated feature: REMAKE_INITRD
Deprecated feature: REMAKE_INITRD
Deprecated feature: REMAKE_INITRD
Deprecated feature: REMAKE_INITRD

Building module:
cleaning build area...
make -j4 KERNELRELEASE=5.17.0-1-amd64 KVER=5.17.0-1-amd64...(bad exit status: 2)
Error! Bad return status for module build on kernel: 5.17.0-1-amd64 (x86_64)
Consult /var/lib/dkms/broadcom-sta/6.30.223.271/build/make.log for more 
information.

---ERROR END---

Contents of make.log:

https://pastebin.com/XUJbXbbn


** Model information
sys_vendor: ASUSTeK Computer INC.
product_name: ET2321I
product_version: 0801
chassis_vendor: To Be Filled By O.E.M.
chassis_version: To Be Filled By O.E.M.
bios_vendor: American Megatrends Inc.
bios_version: 0801
board_vendor: ASUSTeK COMPUTER INC.
board_name: ET2321I
board_version: Rev 1.xx

** PCI devices:

03:00.0 Network controller [0280]: Broadcom Inc. and subsidiaries BCM4352 
802.11ac Wireless Network Adapter [14e4:43b1] (rev 03)
Subsystem: AzureWave BCM4352 802.11ac Wireless Network Adapter [1a3b:2123]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- 
SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: wl
Kernel modules: bcma, wl

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

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

Versions of packages linux-image-5.17.0-1-amd64 depends on:
ii  initramfs-tools [linux-initramfs-tool]  0.141
ii  kmod29-1
ii  linux-base  4.8

Versions of packages linux-image-5.17.0-1-amd64 recommends:
ii  apparmor 3.0.4-2
ii  firmware-linux-free  20200122-1

Versions of packages linux-image-5.17.0-1-amd64 suggests:
pn  debian-kernel-handbook  
ii  grub-pc 2.06-2
pn  linux-doc-5.17  

Versions of packages linux-image-5.17.0-1-amd64 is related to:
ii  firmware-amd-graphics 20210818-1
pn  firmware-atheros  
pn  firmware-bnx2 
pn  firmware-bnx2x
pn  firmware-brcm80211
pn  firmware-cavium   
pn  firmware-intel-sound  
pn  firmware-intelwimax   
pn  firmware-ipw2x00  
pn  firmware-ivtv 
pn  firmware-iwlwifi  
pn  firmware-libertas 
ii  firmware-linux-nonfree20210818-1
ii  firmware-misc-nonfree 20210818-1
pn  firmware-myricom  
pn  firmware-netxen   
pn  firmware-qlogic   
pn  firmware-realtek  
pn  firmware-samsung  
pn  firmware-siano
pn  firmware-ti-connectivity  
pn  xen-hypervisor

-- no debconf information


Bug#1010129: golang-gonum-v1-gonum: FTBFS: Several tests fail due to "signal SIGSEGV: segmentation violation"

2022-04-24 Thread Mathias Gibbens
Source: golang-gonum-v1-gonum
Version: 0.9.0-1

Hi,

  While rebuilding the reverse dependencies of another package I was
updating, I saw that your package failed to build in my sid sbuild
environment. Due to the size of the test suite output, I have included
it as a gzipped attachment.


test-errors.gz
Description: application/gzip


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


Bug#1010127: golang-github-viant-toolbox: Inconsistent test failures

2022-04-24 Thread Mathias Gibbens
Source: golang-github-viant-toolbox
Version: 0.33.2-3

Hi,

  While rebuilding the reverse dependencies of another package I was
updating, I saw that your package failed to build in my sid sbuild
environment. Specifically, there are occasional test failures that seem
like they may be more easily seen on a heavily-loaded build host. From
two different builds:

> === RUN   TestNewFileSetInfoInfo
> panic: unexpected call to os.Exit(0) during test
> 
> goroutine 56 [running]:
> os.Exit(0x0)
>   /usr/lib/go-1.18/src/os/proc.go:68 +0x55
> github.com/viant/toolbox.(*LogStream).manageWritesInBatch(0xc000232240)
>   
> /<>/obj-x86_64-linux-gnu/src/github.com/viant/toolbox/file_logger.go:152
>  +0x165
> github.com/viant/toolbox.(*FileLogger).NewLogStream.func1()
>   
> /<>/obj-x86_64-linux-gnu/src/github.com/viant/toolbox/file_logger.go:219
>  +0x1d
> created by github.com/viant/toolbox.(*FileLogger).NewLogStream
>   
> /<>/obj-x86_64-linux-gnu/src/github.com/viant/toolbox/file_logger.go:218
>  +0x170
> FAIL  github.com/viant/toolbox2.994s

and

> === RUN   TestLogger
> --- PASS: TestLogger (2.46s)
> panic: unexpected call to os.Exit(0) during test
> 
> goroutine 163 [running]:
> os.Exit(0x0)
>   /usr/lib/go-1.18/src/os/proc.go:68 +0x55
> github.com/viant/toolbox.(*LogStream).manageWritesInBatch(0xc0003220c0)
>   
> /<>/obj-x86_64-linux-gnu/src/github.com/viant/toolbox/file_logger.go:152
>  +0x165
> github.com/viant/toolbox.(*FileLogger).NewLogStream.func1()
>   
> /<>/obj-x86_64-linux-gnu/src/github.com/viant/toolbox/file_logger.go:219
>  +0x1d
> created by github.com/viant/toolbox.(*FileLogger).NewLogStream
>   
> /<>/obj-x86_64-linux-gnu/src/github.com/viant/toolbox/file_logger.go:218
>  +0x170
> FAIL  github.com/viant/toolbox2.781s


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


Bug#1009861: intel-microcode: Laptop DELL Studio 1555 freeze after update of intel-microcode

2022-04-24 Thread Henrique de Moraes Holschuh
On Tue, 19 Apr 2022, ilexa wrote:
> I have started updating the system via apt-get update and upgrade. New 
> version of intel-microcode was buster/non-free: 3.20220207.1~deb10u1
> 
> System booted normally but started to crash/freeze with garbadge screen and 
> did not response to any keyboard combination after starting Firefox browser 
> and let say watching YouTube video.
> 
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
> 
> I revert back to old package 3.20210608.2~deb10u1 and this bring back the 
> stable state of system. No more crashes or garbadge screen.

I will need more data about your system, and what happened to it.  As
far as I can tell from online datasheets, the possible processor types
that the Dell Studio 1555 can accept had no microcode changes.

This means it was likely the fact that your initramfs changed that
caused issues, not the intel-microcode *contents*.

First, I need the output of these commands, please run them as root.
They will not modify your system.  They will tell me the microcode
contents of your initramfs, your processor type, as well as the way
intel-microcode is supposed to update the initramfs.


du -sh /boot

iucode_tool -Sv

iucode-tool -tr -Lv /boot/initrd.img*

cat /etc/default/intel-microcode

dpkg -s initramfs-tools dracut


Thank you...
 
-- 
  Henrique Holschuh



Bug#1008424: audiofile: FTBFS: dh_auto_test: error: make -j8 check VERBOSE=1 returned exit code 2

2022-04-24 Thread Alberto Garcia
reassign 1008424 src:flac 1.3.4-1
affects 1008424 src:audiofile
retitle 1008424 flac 1.3.4 makes audiofile FTBFS
forwarded 1008424 https://github.com/xiph/flac/issues/327
tags 1008424 patch
thanks

On Sat, Apr 23, 2022 at 01:48:17AM +0200, Alberto Garcia wrote:
> I submitted a bug report upstream: https://github.com/xiph/flac/issues/327

So it seems that the problem is in flac after all, I'm reassigning the
bug to that package.

Berto



Bug#1010121: libx11: FTCBFS: cannot run test program while cross compiling

2022-04-24 Thread Helmut Grohne
Control: tags -1 + moreinfo

Hi Daniel,

On Sun, Apr 24, 2022 at 02:48:12PM -0700, Daniel Schepler wrote:
> While doing a test bootstrap of i386 from amd64, I ran into an error
> trying to cross build libx11:
> 
> ...
> checking for xproto >= 7.0.25 xextproto xtrans xcb >= 1.11.1 kbproto
> inputproto... yes
> checking whether malloc(0) returns NULL... configure: error: in
> `/home/tmpbuilder/cross-i386/libx11/libx11-1.7.5/build':
> configure: error: cannot run test program while cross compiling
> See `config.log' for more details
> ...

Supposedly, this has been addressed in cross-config, which supplies the
relevant cache variable xorg_cv_malloc0_returns_null. sbuild
automatically enables this cache. Accordingly, libx11 cross builds
successfully in QA: https://crossqa.debian.net/src/libx11.

Do you see any actionable aspect in this bug or can we close it? Adding
the cache variable to each and every X11 library does not seem like an
effective solution to me.

I note that the cache is wrong on musl-any-any.

Helmut



Bug#1010125: golang-github-xanzy-go-gitlab: FTBFS: dh_auto_test: error: cd obj-x86_64-linux-gnu && go test -vet=off -v -p 16 github.com/xanzy/go-gitlab returned exit code 1

2022-04-24 Thread Mathias Gibbens
Source: golang-github-xanzy-go-gitlab
Version: 0.22.2-1

Hi,

  While rebuilding the reverse dependencies of another package I was
updating, I saw that your package failed to build in my sid sbuild
environment:

>dh_auto_test -O--buildsystem=golang
>   cd obj-x86_64-linux-gnu && go test -vet=off -v -p 16 
> github.com/xanzy/go-gitlab
> === RUN   TestListProjectAccessRequests
> --- PASS: TestListProjectAccessRequests (0.00s)
> === RUN   TestListGroupAccessRequests
> --- PASS: TestListGroupAccessRequests (0.00s)
> === RUN   TestRequestProjectAccess
> --- PASS: TestRequestProjectAccess (0.00s)
> === RUN   TestRequestGroupAccess
> --- PASS: TestRequestGroupAccess (0.00s)
> === RUN   TestApproveProjectAccessRequest
> --- PASS: TestApproveProjectAccessRequest (0.00s)
> === RUN   TestApproveGroupAccessRequest
> --- PASS: TestApproveGroupAccessRequest (0.00s)
> === RUN   TestDenyProjectAccessRequest
> --- PASS: TestDenyProjectAccessRequest (0.00s)
> === RUN   TestDenyGroupAccessRequest
> --- PASS: TestDenyGroupAccessRequest (0.00s)
> === RUN   TestListBroadcastMessages
> --- PASS: TestListBroadcastMessages (0.00s)
> === RUN   TestGetBroadcastMessages
> --- PASS: TestGetBroadcastMessages (0.00s)
> === RUN   TestCreateBroadcastMessages
> --- PASS: TestCreateBroadcastMessages (0.00s)
> === RUN   TestUpdateBroadcastMessages
> --- PASS: TestUpdateBroadcastMessages (0.00s)
> === RUN   TestDeleteBroadcastMessages
> --- PASS: TestDeleteBroadcastMessages (0.00s)
> === RUN   TestGetCommit
> --- PASS: TestGetCommit (0.00s)
> === RUN   TestGetCommitStatuses
> --- PASS: TestGetCommitStatuses (0.00s)
> === RUN   TestSetCommitStatus
> --- PASS: TestSetCommitStatus (0.00s)
> === RUN   TestRevertCommit_NoOptions
> --- PASS: TestRevertCommit_NoOptions (0.00s)
> === RUN   TestRevertCommit_WithOptions
> --- PASS: TestRevertCommit_WithOptions (0.00s)
> === RUN   TestGetGPGSignature
> --- PASS: TestGetGPGSignature (0.00s)
> === RUN   TestListCustomUserAttributes
> --- PASS: TestListCustomUserAttributes (0.00s)
> === RUN   TestListCustomGroupAttributes
> --- PASS: TestListCustomGroupAttributes (0.00s)
> === RUN   TestListCustomProjectAttributes
> --- PASS: TestListCustomProjectAttributes (0.00s)
> === RUN   TestGetCustomUserAttribute
> --- PASS: TestGetCustomUserAttribute (0.00s)
> === RUN   TestGetCustomGropupAttribute
> --- PASS: TestGetCustomGropupAttribute (0.00s)
> === RUN   TestGetCustomProjectAttribute
> --- PASS: TestGetCustomProjectAttribute (0.00s)
> === RUN   TestSetCustomUserAttribute
> --- PASS: TestSetCustomUserAttribute (0.00s)
> === RUN   TestSetCustomGroupAttribute
> --- PASS: TestSetCustomGroupAttribute (0.00s)
> === RUN   TestDeleteCustomUserAttribute
> --- PASS: TestDeleteCustomUserAttribute (0.00s)
> === RUN   TestDeleteCustomGroupAttribute
> --- PASS: TestDeleteCustomGroupAttribute (0.00s)
> === RUN   TestDeleteCustomProjectAttribute
> --- PASS: TestDeleteCustomProjectAttribute (0.00s)
> === RUN   TestListEnvironments
> --- PASS: TestListEnvironments (0.00s)
> === RUN   TestGetEnvironment
> --- PASS: TestGetEnvironment (0.00s)
> === RUN   TestCreateEnvironment
> --- PASS: TestCreateEnvironment (0.00s)
> === RUN   TestEditEnvironment
> --- PASS: TestEditEnvironment (0.00s)
> === RUN   TestDeleteEnvironment
> --- PASS: TestDeleteEnvironment (0.00s)
> === RUN   TestStopEnvironment
> --- PASS: TestStopEnvironment (0.00s)
> === RUN   TestUnmarshal
> --- PASS: TestUnmarshal (0.00s)
> === RUN   TestGetEpic
> --- PASS: TestGetEpic (0.00s)
> === RUN   TestDeleteEpic
> --- PASS: TestDeleteEpic (0.00s)
> === RUN   TestListGroupEpics
> --- PASS: TestListGroupEpics (0.00s)
> === RUN   TestCreateEpic
> --- PASS: TestCreateEpic (0.00s)
> === RUN   TestUpdateEpic
> --- PASS: TestUpdateEpic (0.00s)
> === RUN   TestWebhookEventType
> --- PASS: TestWebhookEventType (0.00s)
> === RUN   TestParsePushHook
> --- PASS: TestParsePushHook (0.00s)
> === RUN   TestParseTagHook
> --- PASS: TestParseTagHook (0.00s)
> === RUN   TestParseIssueHook
> --- PASS: TestParseIssueHook (0.00s)
> === RUN   TestParseCommitCommentHook
> --- PASS: TestParseCommitCommentHook (0.00s)
> === RUN   TestParseMergeRequestCommentHook
> --- PASS: TestParseMergeRequestCommentHook (0.00s)
> === RUN   TestParseIssueCommentHook
> --- PASS: TestParseIssueCommentHook (0.00s)
> === RUN   TestParseSnippetCommentHook
> --- PASS: TestParseSnippetCommentHook (0.00s)
> === RUN   TestParseMergeRequestHook
> --- PASS: TestParseMergeRequestHook (0.00s)
> === RUN   TestParseWikiPageHook
> --- PASS: TestParseWikiPageHook (0.00s)
> === RUN   TestParsePipelineHook
> --- PASS: TestParsePipelineHook (0.00s)
> === RUN   TestParseBuildHook
> --- PASS: TestParseBuildHook (0.00s)
> === RUN   TestPushEventUnmarshal
> --- PASS: TestPushEventUnmarshal (0.00s)
> === RUN   TestMergeEventUnmarshal
> --- PASS: TestMergeEventUnmarshal (0.00s)
> === RUN   TestPipelineEventUnmarshal
> --- PASS: TestPipelineEventUnmarshal (0.00s)
> === RUN   TestBuildEventUnmarshal
> --- PASS: 

Bug#1010124: gitlab-ci-multi-runner: FTBFS: TestConfigParse failure

2022-04-24 Thread Mathias Gibbens
Source: gitlab-ci-multi-runner
Version: 13.3.1+dfsg-4

Hi,

  While rebuilding the reverse dependencies of another package I was
updating, I saw that your package failed to build in my sid sbuild
environment:

> === RUN   TestConfigParse
> === RUN   TestConfigParse/parse_Service_as_table_with_only_alias
> === RUN   TestConfigParse/parse_Service_as_table
> === RUN   
> TestConfigParse/parse_Service_runners.docker_and_runners.docker.services
> === RUN   TestConfigParse/parse_Service_as_table_int_value_name
> config_test.go:207: 
>   Error Trace:config_test.go:207
>   Error:  Error message not equal:
>   expected: "toml: cannot load TOML value of type 
> int64 into a Go string"
>   actual  : "toml: incompatible types: TOML key 
> \"runners.docker.services.name\" has type int64; destination has type string"
>   Test:   
> TestConfigParse/parse_Service_as_table_int_value_name
> === RUN   TestConfigParse/parse_Service_as_table_int_value_alias
> config_test.go:207: 
>   Error Trace:config_test.go:207
>   Error:  Error message not equal:
>   expected: "toml: cannot load TOML value of type 
> int64 into a Go string"
>   actual  : "toml: incompatible types: TOML key 
> \"runners.docker.services.alias\" has type int64; destination has type string"
>   Test:   
> TestConfigParse/parse_Service_as_table_int_value_alias
> === RUN   TestConfigParse/parse_Service_as_table_with_only_name
> --- FAIL: TestConfigParse (0.00s)
> --- PASS: TestConfigParse/parse_Service_as_table_with_only_alias (0.00s)
> --- PASS: TestConfigParse/parse_Service_as_table (0.00s)
> --- PASS: 
> TestConfigParse/parse_Service_runners.docker_and_runners.docker.services 
> (0.00s)
> --- FAIL: TestConfigParse/parse_Service_as_table_int_value_name (0.00s)
> --- FAIL: TestConfigParse/parse_Service_as_table_int_value_alias (0.00s)
> --- PASS: TestConfigParse/parse_Service_as_table_with_only_name (0.00s)


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


Bug#1010123: network-manager: Wifi randomly stops after upgrade and do not auto connect

2022-04-24 Thread Marcelo Laia
Package: network-manager
Version: 1.36.4-2
Severity: normal

Dear Maintainer,

After upgrade, I got wifi randomly disconnected. I need to turn off and on
it in order to get it back on or I need to restart NM by

# systemctl restart NetworkManager.service

 logs -
after wifi disconnected/stopped

# journalctl -f
abr 24 12:01:03 marcelo dbus-daemon[712]: [system] Successfully activated
service 'org.freedesktop.nm_dispatcher'
abr 24 12:01:03 marcelo systemd[1]: Started Network Manager Script Dispatcher
Service.
abr 24 12:01:04 marcelo NetworkManager[780]:   [1650812464.3696] dhcp4
(wlp2s0): state changed new lease, address=192.168.1.175
abr 24 12:01:04 marcelo soffice.bin[9591]: g_object_weak_unref: couldn't find
weak ref 0x7fa6e7a07d10(0x7fa6c8009360)
abr 24 12:01:14 marcelo systemd[1]: NetworkManager-dispatcher.service:
Deactivated successfully.
abr 24 12:01:15 marcelo wpa_supplicant[781]: wlp2s0: CTRL-EVENT-SIGNAL-CHANGE
above=1 signal=-37 noise=-93 txrate=72200
abr 24 12:03:01 marcelo wpa_supplicant[781]: wlp2s0: CTRL-EVENT-SIGNAL-CHANGE
above=1 signal=-32 noise=-93 txrate=72200
abr 24 12:03:07 marcelo wpa_supplicant[781]: wlp2s0: CTRL-EVENT-SIGNAL-CHANGE
above=1 signal=-21 noise=-95 txrate=72200
abr 24 12:03:09 marcelo wpa_supplicant[781]: wlp2s0: CTRL-EVENT-SIGNAL-CHANGE
above=1 signal=-21 noise=-95 txrate=72200
abr 24 12:03:23 marcelo wpa_supplicant[781]: wlp2s0: CTRL-EVENT-SIGNAL-CHANGE
above=1 signal=-13 noise=-95 txrate=72200

after turn off and turn on wifi (I turn off and turn on it by Networking-
manager dropdown menu in right side up corner) or after run

# systemctl restart NetworkManager.service

# journalctl -f
abr 24 12:07:48 marcelo PackageKit[1377]: uid 1000 obtained auth for
org.freedesktop.packagekit.system-sources-refresh
abr 24 12:07:48 marcelo PackageKit[1377]: uid 1000 obtained auth for
org.freedesktop.packagekit.system-sources-refresh
abr 24 12:07:49 marcelo goa-daemon[3378]: secret_password_lookup_sync()
returned NULL
abr 24 12:07:49 marcelo PackageKit[1377]: uid 1000 is trying to obtain
org.freedesktop.packagekit.system-sources-refresh auth (only_trusted:0)
abr 24 12:07:49 marcelo PackageKit[1377]: uid 1000 is trying to obtain
org.freedesktop.packagekit.system-sources-refresh auth (only_trusted:0)
abr 24 12:07:49 marcelo PackageKit[1377]: uid 1000 obtained auth for
org.freedesktop.packagekit.system-sources-refresh
abr 24 12:07:49 marcelo PackageKit[1377]: uid 1000 obtained auth for
org.freedesktop.packagekit.system-sources-refresh
abr 24 12:07:50 marcelo PackageKit[1377]: get-details transaction
/17151_bebcddce from uid 1000 finished with success after 5070ms
abr 24 12:07:50 marcelo goa-daemon[3378]: secret_password_lookup_sync()
returned NULL
abr 24 12:07:56 marcelo systemd[1]: NetworkManager-dispatcher.service:
Deactivated successfully.
abr 24 12:08:26 marcelo PackageKit[1377]: refresh-cache transaction
/17148_acddadad from uid 1000 finished with success after 36393ms
abr 24 12:08:26 marcelo gnome-software[3560]: failed to refresh the cache:
Failed to download ‘https://odrs.gnome.org/1.0/reviews/api/ratings’: Cannot
resolve hostname: Erro ao resolver “odrs.gnome.org”: Nome ou serviço
desconhecido
abr 24 12:08:30 marcelo PackageKit[1377]: refresh-cache transaction
/17149_aeddeabb from uid 1000 finished with cancelled-priority after 3887ms
abr 24 12:08:30 marcelo packagekitd[1377]: Falhou o download de alguns
ficheiros de índice. Foram ignorados ou os antigos foram usados em seu lugar.
abr 24 12:08:30 marcelo gnome-software[3560]: failed to refresh the cache:
Failed to download ‘https://odrs.gnome.org/1.0/reviews/api/ratings’: Cannot
resolve hostname: Erro ao resolver “odrs.gnome.org”: Nome ou serviço
desconhecido
abr 24 12:08:34 marcelo PackageKit[1377]: get-updates transaction
/17167_edccedea from uid 1000 finished with success after 3655ms
abr 24 12:08:36 marcelo PackageKit[1377]: refresh-cache transaction
/17152_ccdebacd from uid 1000 finished with cancelled-priority after 2014ms
abr 24 12:08:36 marcelo packagekitd[1377]: Falhou o download de alguns
ficheiros de índice. Foram ignorados ou os antigos foram usados em seu lugar.
abr 24 12:08:36 marcelo gnome-software[3560]: failed to refresh the cache:
failed to download file: Could not resolve host: cdn.fwupd.org
abr 24 12:08:39 marcelo PackageKit[1377]: get-details transaction
/17168_addbccbb from uid 1000 finished with success after 2892ms
abr 24 12:08:39 marcelo PackageKit[1377]: refresh-cache transaction
/17153_ccdbcddb from uid 1000 finished with cancelled-priority after 899ms
abr 24 12:08:39 marcelo packagekitd[1377]: Falhou o download de alguns
ficheiros de índice. Foram ignorados ou os antigos foram usados em seu lugar.
abr 24 12:08:40 marcelo gnome-software[3560]: failed to refresh the cache:
failed to download file: Could not resolve host: cdn.fwupd.org
abr 24 12:08:41 marcelo goa-daemon[3378]: secret_password_lookup_sync()
returned NULL
abr 24 12:08:43 marcelo PackageKit[1377]: get-updates transaction

Bug#1010122: scamper FTBFS on !amd64

2022-04-24 Thread Adrian Bunk
Source: scamper
Version: 20211212-1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/package.php?p=scamper=sid

...
rm debian/tmp/usr/bin/sc_wartsfix
rm debian/tmp/usr/bin/sc_warts2csv
rm debian/tmp/usr/share/man/man1/sc_wartsfix.1
rm debian/tmp/usr/share/man/man1/sc_warts2csv.1
rm debian/tmp/usr/lib/x86_64-linux-gnu/libscamperfile.la
rm: cannot remove 'debian/tmp/usr/lib/x86_64-linux-gnu/libscamperfile.la': No 
such file or directory
make[1]: *** [debian/rules:27: override_dh_auto_install] Error 1



Bug#1004912: Acknowledgement (rarcrack dead upstream?)

2022-04-24 Thread Bastian Germann

Am 24.04.22 um 18:09 schrieb Pierre Rudloff:

What improvements does this fork bring (apart from the macOS compatibility)?


The maintainer does still respond and would take patches even if they are not 
actively working on the project.



Bug#1010121: libx11: FTCBFS: cannot run test program while cross compiling

2022-04-24 Thread Daniel Schepler
Source: libx11
Version: 2:1.7.5-1
Severity: wishlist

While doing a test bootstrap of i386 from amd64, I ran into an error
trying to cross build libx11:

...
checking for xproto >= 7.0.25 xextproto xtrans xcb >= 1.11.1 kbproto
inputproto... yes
checking whether malloc(0) returns NULL... configure: error: in
`/home/tmpbuilder/cross-i386/libx11/libx11-1.7.5/build':
configure: error: cannot run test program while cross compiling
See `config.log' for more details
...

(This came up as a Build-Depends of groff, while trying to
cross-compile enough packages to make debhelper installable.)
-- 
Daniel Schepler



Bug#1010120: thrift: FTBFS: dh_auto_test: error: make -j1 check "TESTSUITEFLAGS=-j1 --verbose" VERBOSE=1 returned exit code 2

2022-04-24 Thread Mathias Gibbens
Source: thrift
Version: 0.16.0-3

Hi,

  While rebuilding the reverse dependencies of another package I was
updating, I saw that your package failed to build in my sid sbuild
environment:

> Making check in test
> make[5]: Entering directory '/<>/lib/cpp/test'
> make  check-am
> make[6]: Entering directory '/<>/lib/cpp/test'
> make  UnitTests TFDTransportTest TPipedTransportTest DebugProtoTest 
> JSONProtoTest OptionalRequiredTest RecursiveTest SpecializationTest 
> AllProtocolsTest TransportTest TInterruptTest TServerIntegrationTest ZlibTest 
> TFileTransportTest link_test OpenSSLManualInitTest EnumTest 
> RenderedDoubleConstantsTest AnnotationTest TNonblockingServerTest 
> TNonblockingSSLServerTest
> make[7]: Entering directory '/<>/lib/cpp/test'
> g++ -std=c++11 -DHAVE_CONFIG_H   -I/usr/include -I../../../lib/cpp/src 
> -I../../../lib/cpp/src/thrift -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS 
> -I. -Wdate-time -D_FORTIFY_SOURCE=2 -Wall -Wextra -pedantic -g -O2 
> -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat 
> -Werror=format-security -c -o UnitTestMain.o UnitTestMain.cpp
> g++ -std=c++11 -DHAVE_CONFIG_H   -I/usr/include -I../../../lib/cpp/src 
> -I../../../lib/cpp/src/thrift -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS 
> -I. -Wdate-time -D_FORTIFY_SOURCE=2 -Wall -Wextra -pedantic -g -O2 
> -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat 
> -Werror=format-security -c -o OneWayHTTPTest.o OneWayHTTPTest.cpp
> g++ -std=c++11 -DHAVE_CONFIG_H   -I/usr/include -I../../../lib/cpp/src 
> -I../../../lib/cpp/src/thrift -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS 
> -I. -Wdate-time -D_FORTIFY_SOURCE=2 -Wall -Wextra -pedantic -g -O2 
> -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat 
> -Werror=format-security -c -o TMemoryBufferTest.o TMemoryBufferTest.cpp
> g++ -std=c++11 -DHAVE_CONFIG_H   -I/usr/include -I../../../lib/cpp/src 
> -I../../../lib/cpp/src/thrift -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS 
> -I. -Wdate-time -D_FORTIFY_SOURCE=2 -Wall -Wextra -pedantic -g -O2 
> -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat 
> -Werror=format-security -c -o TBufferBaseTest.o TBufferBaseTest.cpp
> g++ -std=c++11 -DHAVE_CONFIG_H   -I/usr/include -I../../../lib/cpp/src 
> -I../../../lib/cpp/src/thrift -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS 
> -I. -Wdate-time -D_FORTIFY_SOURCE=2 -Wall -Wextra -pedantic -g -O2 
> -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat 
> -Werror=format-security -c -o Base64Test.o Base64Test.cpp
> g++ -std=c++11 -DHAVE_CONFIG_H   -I/usr/include -I../../../lib/cpp/src 
> -I../../../lib/cpp/src/thrift -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS 
> -I. -Wdate-time -D_FORTIFY_SOURCE=2 -Wall -Wextra -pedantic -g -O2 
> -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat 
> -Werror=format-security -c -o ToStringTest.o ToStringTest.cpp
> g++ -std=c++11 -DHAVE_CONFIG_H   -I/usr/include -I../../../lib/cpp/src 
> -I../../../lib/cpp/src/thrift -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS 
> -I. -Wdate-time -D_FORTIFY_SOURCE=2 -Wall -Wextra -pedantic -g -O2 
> -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat 
> -Werror=format-security -c -o TypedefTest.o TypedefTest.cpp
> g++ -std=c++11 -DHAVE_CONFIG_H   -I/usr/include -I../../../lib/cpp/src 
> -I../../../lib/cpp/src/thrift -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS 
> -I. -Wdate-time -D_FORTIFY_SOURCE=2 -Wall -Wextra -pedantic -g -O2 
> -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat 
> -Werror=format-security -c -o TServerSocketTest.o TServerSocketTest.cpp
> g++ -std=c++11 -DHAVE_CONFIG_H   -I/usr/include -I../../../lib/cpp/src 
> -I../../../lib/cpp/src/thrift -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS 
> -I. -Wdate-time -D_FORTIFY_SOURCE=2 -Wall -Wextra -pedantic -g -O2 
> -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat 
> -Werror=format-security -c -o TServerTransportTest.o TServerTransportTest.cpp
> g++ -std=c++11 -DHAVE_CONFIG_H   -I/usr/include -I../../../lib/cpp/src 
> -I../../../lib/cpp/src/thrift -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS 
> -I. -Wdate-time -D_FORTIFY_SOURCE=2 -Wall -Wextra -pedantic -g -O2 
> -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat 
> -Werror=format-security -c -o ThrifttReadCheckTests.o 
> ThrifttReadCheckTests.cpp
> In file included from /usr/include/boost/config/header_deprecated.hpp:18,
>  from /usr/include/boost/test/auto_unit_test.hpp:16,
>  from ThrifttReadCheckTests.cpp:22:
> /usr/include/boost/test/auto_unit_test.hpp:17:1: note: ‘#pragma message: This 
> header is deprecated. Use  instead.’
>17 | BOOST_HEADER_DEPRECATED( "" )
>   | ^~~
> /bin/bash ../../../libtool  --tag=CXX   --mode=link g++ -std=c++11 -Wall 
> -Wextra -pedantic -g -O2 -ffile-prefix-map=/<>=. 
> -fstack-protector-strong -Wformat -Werror=format-security 
> -L/usr/lib/x86_64-linux-gnu -Wl,-z,relro -o UnitTests UnitTestMain.o 
> OneWayHTTPTest.o TMemoryBufferTest.o 

Bug#1010098: xorriso: please allow -cut-out directly from block devices

2022-04-24 Thread Ivan Shmakov
> On 2022-04-24, Thomas Schmitt wrote:
> Ivan Shmakov wrote:

 >> I’m filing this bug against versions from oldstable and stable,
 >> for that’s so far the only Debian packages’ versions I’ve tested
 >> for this issue.

 > As it is about an upstream wish:

 > The newest easily compilable and then usable version would be
 >   http://www.gnu.org/software/xorriso/xorriso-1.5.5.tar.gz

Not under http://ftp.gnu.org/gnu/xorriso/ , though?

 > It can be compiled without much dependencies and then used without
 > installation. See "Compilation, First Glimpse, Installation" in
 >   https://www.gnu.org/software/xorriso/README_xorriso_devel

 > Said that, and now with my upstream hat on, i expect no difference
 > to versions 1.5.0 or 1.5.4 in respect to command -cut_out.

It’d seem that I’ve missed an important detail or two in my
original message.  The patch suggested was against the following
Git revisions of the libisofs and libisoburn:

commit da00291519ad22c5bfa79c93ffeb04219bab0d7e
Author: Thomas Schmitt 
AuthorDate: 2022-04-23 09:32:44 +0200
Commit: Thomas Schmitt 
CommitDate: 2022-04-23 09:32:44 +0200

Let the original isohybrid GPT obey system_area() option bit 17:
GPT writable

commit 0ef65a783765dbde79242ac41d5b9f2a495de1ec
Author: Thomas Schmitt 
AuthorDate: 2022-04-23 14:09:30 +0200
Commit: Thomas Schmitt 
CommitDate: 2022-04-23 14:09:30 +0200

Updated change log and web page

I’d frankly be surprised to learn that a proper release,
such as 1.5.5, has features which a recent revision from
Git master branch lacks.

 > So there is no need to get xorriso-1.5.5.tar.gz unless you want
 > to test a patch proposed by me.

I’ll be checking the master branch from time to time, and hope
to test the patch and report the results once it lands there.

TIA.

 > I downloaded your 114.xorriso-1.diff and will study it for the
 > goal of enabling -cut_out for more file types.

 > I already see that it makes changes about fsrc_open(), which is a
 > central facility of libisofs.  This means it will last several days
 > of study and pondering until i would be convinced of any change.

The patch was intended, first and foremost, as a proof of
concept; I hope I’ve identified /where/ the code needs to be
changed, but I’m not going to claim familiarity with all the
code paths involved, and as such cannot readily suggest
/what/ changes are needed.  As it is, I fully expect for the
things to break.

 > Also i need to check whether your diff interferes with the
 > ability to backup a block device file as itself and not as bearer
 > of its content:

 >   rm test.iso
 >   xorriso -outdev test.iso -map /dev/sr0 /sr0 -commit -lsdl /sr0 --

 > should produce even with a loaded BD_RE medium of 23 GiB a small ISO and
 > report a block device file in it

 >   brw-rw1 024   11,0 Apr 24 14:15 '/sr0'

FWIW, as a user, I’d expect an additional -follow option for
this feature, such as:

  *seekable*  If enabled, any non-regular seekable file (such as a
block device) would be stored on image as a regular one with the
contents taken from the original.  The default is to store special
files as-is.  (See also the -cut_out option.)

In the implementation, I’d rather see it not testing the
file type specifically, aside of S_ISREG, S_ISDIR and S_ISLNK,
but rather whether lseek (, 0, SEEK_END) gives a sane result,
thus allowing for transparent support of novel or non-standard
(platform-specific) file types.

-- 
FSF associate member #7257  http://am-1.org/~ivan/



Bug#1010119: python3-gitlab 1:3.3.0-1 makes gitlabracadabra FTBFS

2022-04-24 Thread Adrian Bunk
Package: python3-gitlab
Version: 1:3.3.0-1
Severity: serious
Tags: ftbfs
Control: affects -1 src:gitlabracadabra

https://buildd.debian.org/status/fetch.php?pkg=gitlabracadabra=all=1.5.0=1649863207=0

...
==
ERROR: test_get_connection_both 
(gitlabracadabra.tests.unit.test_gitlab_connections.TestGitlabConnections)
Get several Gitlab connections.
--
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/gitlab/config.py", line 57, in 
_get_config_files
resolved = _resolve_file(config_file)
  File "/usr/lib/python3/dist-packages/gitlab/config.py", line 39, in 
_resolve_file
resolved = Path(filepath).resolve(strict=True)
  File "/usr/lib/python3.10/pathlib.py", line 1075, in resolve
s = self._accessor.realpath(self, strict=strict)
  File "/usr/lib/python3.10/posixpath.py", line 395, in realpath
path, ok = _joinrealpath(filename[:0], filename, strict, {})
  File "/usr/lib/python3.10/posixpath.py", line 430, in _joinrealpath
st = os.lstat(newpath)
FileNotFoundError: [Errno 2] No such file or directory: '/path'
...



Bug#1010074: RFS: show-in-file-manager/1.1.4-1 [RFP] -- Open the system file manager and optionally select files in it

2022-04-24 Thread Tino Mettler
Am 24.04.2022 um 22:04 schrieb Antoine Beaupré :
> 
> You have actually configured it in the package, so it would be better if
> it actually works. :) Try just running `autopkgtest` in the source
> directory..
> 
> https://wiki.debian.org/ContinuousIntegration/autopkgtest

Hi,

I was not aware that the package defines any test specific bits. Can you point 
me to the relevant part? I had the impression that a package needs to define 
the tests in debian/tests/, and the showinfilemanager package does not have a 
debian/tests directory.

Regards,
Tino



Bug#1008325: python-omemo-backend-signal: FTBFS: dh_auto_test: error: pybuild --test -i python{version} -p "3.10 3.9" returned exit code 13

2022-04-24 Thread Adrian Bunk
Control: reassign -1 python-x3dh 0.5.8-1
Control: reassign -1 python-x3dh: Missing dependency on python3-nacl
Control: affects -1 src:python-omemo-backend-signal

On Sat, Mar 26, 2022 at 09:36:41PM +0100, Lucas Nussbaum wrote:
> Source: python-omemo-backend-signal
> Version: 0.3.0~beta-1
> Severity: serious
> Justification: FTBFS
> Tags: bookworm sid ftbfs
> User: lu...@debian.org
> Usertags: ftbfs-20220326 ftbfs-bookworm
> 
> Hi,
> 
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
>...
> > ==
> > ERROR: omemo_backend_signal (unittest.loader._FailedTest)
> > --
> > ImportError: Failed to import test module: omemo_backend_signal
> > Traceback (most recent call last):
> >   File "/usr/lib/python3.10/unittest/loader.py", line 470, in 
> > _find_test_path
> > package = self._get_module_from_name(name)
> >   File "/usr/lib/python3.10/unittest/loader.py", line 377, in 
> > _get_module_from_name
> > __import__(name)
> >   File 
> > "/<>/.pybuild/cpython3_3.10_omemo_backend_signal/build/omemo_backend_signal/__init__.py",
> >  line 6, in 
> > from .backend import BACKEND as BACKEND
> >   File 
> > "/<>/.pybuild/cpython3_3.10_omemo_backend_signal/build/omemo_backend_signal/backend.py",
> >  line 1, in 
> > from omemo.backends import Backend
> >   File "/usr/lib/python3/dist-packages/omemo/__init__.py", line 3, in 
> > 
> > from . import backends
> >   File "/usr/lib/python3/dist-packages/omemo/backends/__init__.py", line 3, 
> > in 
> > from .x3dhpkencoder import X3DHPKEncoder
> >   File "/usr/lib/python3/dist-packages/omemo/backends/x3dhpkencoder.py", 
> > line 1, in 
> > import x3dh
> >   File "/usr/lib/python3/dist-packages/x3dh/__init__.py", line 6, in 
> > 
> > from . import implementations
> >   File "/usr/lib/python3/dist-packages/x3dh/implementations/__init__.py", 
> > line 3, in 
> > from .keypaircurve25519 import KeyPairCurve25519
> >   File 
> > "/usr/lib/python3/dist-packages/x3dh/implementations/keypaircurve25519.py", 
> > line 8, in 
> > from nacl.bindings import crypto_box_NONCEBYTES
> > ModuleNotFoundError: No module named 'nacl'
>...

This is a missing dependency in python3-x3dh:

$ python3
Python 3.10.4 (main, Apr  2 2022, 09:04:19) [GCC 11.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import x3dh
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python3/dist-packages/x3dh/__init__.py", line 6, in 
from . import implementations
  File "/usr/lib/python3/dist-packages/x3dh/implementations/__init__.py", line 
3, in 
from .keypaircurve25519 import KeyPairCurve25519
  File 
"/usr/lib/python3/dist-packages/x3dh/implementations/keypaircurve25519.py", 
line 8, in 
from nacl.bindings import crypto_box_NONCEBYTES
ModuleNotFoundError: No module named 'nacl'
>>> 

cu
Adrian



Bug#1010118: qtwebkit-opensource-src FTBFS with ICU 71.1

2022-04-24 Thread Adrian Bunk
On Sun, Apr 24, 2022 at 11:14:18PM +0300, Adrian Bunk wrote:
>...
> In file included from 
> /<>/Source/WebCore/platform/text/TextAllInOne.cpp:31:
> /<>/Source/WebCore/platform/text/TextCodecICU.cpp: In member 
> function ‘void WebCore::TextCodecICU::createICUConverter() const’:
> /<>/Source/WebCore/platform/text/TextCodecICU.cpp:311:42: error: 
> ‘TRUE’ was not declared in this scope
>   311 | ucnv_setFallback(m_converterICU, TRUE);
>...

The Ubuntu diff seems to contain a fix (untested).

cu
Adrian



Bug#1008653: backintime-qt broken in sid after python upgrade

2022-04-24 Thread Fabio Fantoni
I missed to reply here, one week ago I prepared and tested an MR with 
the latest upstream version: 
https://salsa.debian.org/jmw/pkg-backintime/-/merge_requests/2


I also prepared an NMU upload on mentors and open RFS: 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1009834




OpenPGP_signature
Description: OpenPGP digital signature


Bug#1010118: qtwebkit-opensource-src FTBFS with ICU 71.1

2022-04-24 Thread Adrian Bunk
Source: qtwebkit-opensource-src
Version: 5.212.0~alpha4-14
Severity: serious
Tags: ftbfs
X-Debbugs-Cc: Laszlo Boszormenyi (GCS) 

https://buildd.debian.org/status/logs.php?pkg=qtwebkit-opensource-src=5.212.0%7Ealpha4-14%2Bb2

...
In file included from 
/<>/Source/WebCore/platform/text/TextAllInOne.cpp:31:
/<>/Source/WebCore/platform/text/TextCodecICU.cpp: In member 
function ‘void WebCore::TextCodecICU::createICUConverter() const’:
/<>/Source/WebCore/platform/text/TextCodecICU.cpp:311:42: error: 
‘TRUE’ was not declared in this scope
  311 | ucnv_setFallback(m_converterICU, TRUE);
  |  ^~~~
...
In file included from 
/<>/Source/WebCore/platform/text/icu/UTextProvider.cpp:27,
 from 
/<>/Source/WebCore/platform/text/TextAllInOne.cpp:40:
/<>/Source/WebCore/platform/text/icu/UTextProvider.h: In function 
‘bool WebCore::uTextAccessInChunkOrOutOfRange(UText*, int64_t, int64_t, UBool, 
UBool&)’:
/<>/Source/WebCore/platform/text/icu/UTextProvider.h:83:28: error: 
‘TRUE’ was not declared in this scope
   83 | isAccessible = TRUE;
  |^~~~
/<>/Source/WebCore/platform/text/icu/UTextProvider.h:88:28: error: 
‘FALSE’ was not declared in this scope
   88 | isAccessible = FALSE;
  |^
/<>/Source/WebCore/platform/text/icu/UTextProvider.h:97:28: error: 
‘TRUE’ was not declared in this scope
   97 | isAccessible = TRUE;
  |^~~~
/<>/Source/WebCore/platform/text/icu/UTextProvider.h:102:28: 
error: ‘FALSE’ was not declared in this scope
  102 | isAccessible = FALSE;
  |^
In file included from 
/<>/Source/WebCore/platform/text/TextAllInOne.cpp:41:
/<>/Source/WebCore/platform/text/icu/UTextProviderLatin1.cpp: In 
function ‘UBool WebCore::uTextLatin1Access(UText*, int64_t, UBool)’:
/<>/Source/WebCore/platform/text/icu/UTextProviderLatin1.cpp:103:20:
 error: ‘TRUE’ was not declared in this scope
  103 | return TRUE;
  |^~~~
/<>/Source/WebCore/platform/text/icu/UTextProviderLatin1.cpp:108:20:
 error: ‘FALSE’ was not declared in this scope
  108 | return FALSE;
  |^
/<>/Source/WebCore/platform/text/icu/UTextProviderLatin1.cpp:114:20:
 error: ‘TRUE’ was not declared in this scope
  114 | return TRUE;
  |^~~~
/<>/Source/WebCore/platform/text/icu/UTextProviderLatin1.cpp:119:20:
 error: ‘FALSE’ was not declared in this scope
  119 | return FALSE;
  |^
In file included from 
/<>/Source/WebCore/platform/text/TextAllInOne.cpp:41:
/<>/Source/WebCore/platform/text/icu/UTextProviderLatin1.cpp:147:12:
 error: ‘TRUE’ was not declared in this scope
  147 | return TRUE;
  |^~~~
/<>/Source/WebCore/platform/text/icu/UTextProviderLatin1.cpp: In 
function ‘UBool WebCore::uTextLatin1ContextAwareAccess(UText*, int64_t, UBool)’:
/<>/Source/WebCore/platform/text/icu/UTextProviderLatin1.cpp:339:16:
 error: ‘FALSE’ was not declared in this scope
  339 | return FALSE;
  |^
/<>/Source/WebCore/platform/text/icu/UTextProviderLatin1.cpp:359:12:
 error: ‘TRUE’ was not declared in this scope
  359 | return TRUE;
  |^~~~
In file included from 
/<>/Source/WebCore/platform/text/TextAllInOne.cpp:42:
/<>/Source/WebCore/platform/text/icu/UTextProviderUTF16.cpp: In 
function ‘UBool WebCore::uTextUTF16ContextAwareAccess(UText*, int64_t, UBool)’:
/<>/Source/WebCore/platform/text/icu/UTextProviderUTF16.cpp:128:16:
 error: ‘FALSE’ was not declared in this scope
  128 | return FALSE;
  |^
/<>/Source/WebCore/platform/text/icu/UTextProviderUTF16.cpp:148:12:
 error: ‘TRUE’ was not declared in this scope
  148 | return TRUE;
  |^~~~
...


Bug#1010110: ncbi-blast+: terminate called after throwing an instance of 'ncbi::CIO_Exception'

2022-04-24 Thread Aaron M. Ucko
Patrice DUROUX  writes:

> Using the same command line with different versions of the package,

Can you please give an example of a command line that reproduces the error?

Thanks!

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



Bug#1010074: RFS: show-in-file-manager/1.1.4-1 [RFP] -- Open the system file manager and optionally select files in it

2022-04-24 Thread Tino Mettler


Am 24.04.2022 um 21:41 schrieb Antoine Beaupré :
> 
> Hi!
> 
> I tested the package and it generally looks good, but tests fail in
> autopkgtest:
> 
> autopkgtest [15:28:00]: test autodep8-python3: set -e ; for py in 
> $(py3versions -r 2>/dev/null) ; do cd "$AUTOPKGTEST_TMP" ; echo "Testing with 
> $py:" ; $py -c "import showinfilemanager; print(showinfilemanager)" ; done
> autopkgtest [15:28:00]: test autodep8-python3: [---
> Testing with python3.9:
> Traceback (most recent call last):
>  File "", line 1, in 
> ModuleNotFoundError: No module named 'showinfilemanager'
> autopkgtest [15:28:01]: test autodep8-python3: ---]
> autopkgtest [15:28:02]: test autodep8-python3:  - - - - - - - - - - results - 
> - - - - - - - - -
> autodep8-python3 FAIL non-zero exit status 1
> autopkgtest [15:28:03]:  summary
> autodep8-python3 FAIL non-zero exit status 1
> qemu-system-x86_64: terminating on signal 15 from pid 136604 
> (/usr/bin/python3)
> 
> 
> I'm doing this in a new qemu-based setup so it's possible this is due to
> my setup, can you reproduce?

Hi,

I've never worked with autopkgtest. My last upload was a few years ago when the 
autotestpkg stuff was quite new. What do I need to do in order to reproduce 
this? In my pbuilder log, I just see this:

   dh_auto_test -O--buildsystem=pybuild
I: pybuild base:239: cd 
/build/show-in-file-manager-1.1.4/.pybuild/cpython3_3.9/build; python3.9 -m 
unittest discover -v 

--
Ran 0 tests in 0.000s

OK
I: pybuild base:239: cd 
/build/show-in-file-manager-1.1.4/.pybuild/cpython3_3.10/build; python3.10 -m 
unittest discover -v 

--
Ran 0 tests in 0.000s

OK

Regards,
Tino



Bug#1010074: RFS: show-in-file-manager/1.1.4-1 [RFP] -- Open the system file manager and optionally select files in it

2022-04-24 Thread Antoine Beaupré
On 2022-04-24 21:57:09, Tino Mettler wrote:
> Am 24.04.2022 um 21:41 schrieb Antoine Beaupré :
>> 
>> Hi!
>> 
>> I tested the package and it generally looks good, but tests fail in
>> autopkgtest:
>> 
>> autopkgtest [15:28:00]: test autodep8-python3: set -e ; for py in 
>> $(py3versions -r 2>/dev/null) ; do cd "$AUTOPKGTEST_TMP" ; echo "Testing 
>> with $py:" ; $py -c "import showinfilemanager; print(showinfilemanager)" ; 
>> done
>> autopkgtest [15:28:00]: test autodep8-python3: [---
>> Testing with python3.9:
>> Traceback (most recent call last):
>>  File "", line 1, in 
>> ModuleNotFoundError: No module named 'showinfilemanager'
>> autopkgtest [15:28:01]: test autodep8-python3: ---]
>> autopkgtest [15:28:02]: test autodep8-python3:  - - - - - - - - - - results 
>> - - - - - - - - - -
>> autodep8-python3 FAIL non-zero exit status 1
>> autopkgtest [15:28:03]:  summary
>> autodep8-python3 FAIL non-zero exit status 1
>> qemu-system-x86_64: terminating on signal 15 from pid 136604 
>> (/usr/bin/python3)
>> 
>> 
>> I'm doing this in a new qemu-based setup so it's possible this is due to
>> my setup, can you reproduce?
>
> Hi,
>
> I've never worked with autopkgtest. My last upload was a few years ago when 
> the autotestpkg stuff was quite new. What do I need to do in order to 
> reproduce this? In my pbuilder log, I just see this:
>
>dh_auto_test -O--buildsystem=pybuild
> I: pybuild base:239: cd 
> /build/show-in-file-manager-1.1.4/.pybuild/cpython3_3.9/build; python3.9 -m 
> unittest discover -v 
>
> --
> Ran 0 tests in 0.000s
>
> OK
> I: pybuild base:239: cd 
> /build/show-in-file-manager-1.1.4/.pybuild/cpython3_3.10/build; python3.10 -m 
> unittest discover -v 
>
> --
> Ran 0 tests in 0.000s
>
> OK

Yeah, so that is the test suite running (or failing to be detected, to
be more accurate) at *build* time. Autopkgtest runs the test suite
*after* the package is build, with the built package.

You have actually configured it in the package, so it would be better if
it actually works. :) Try just running `autopkgtest` in the source
directory..

https://wiki.debian.org/ContinuousIntegration/autopkgtest

A.
-- 
How inappropriate to call this planet 'Earth' when it is quite clearly
'Ocean'.
- Arthur C. Clarke



Bug#1009320: FW issue

2022-04-24 Thread Salvatore Bonaccorso
On Sun, Apr 24, 2022 at 11:37:04AM +0200, Salvatore Bonaccorso wrote:
> Hi,
> 
> On Sun, Apr 24, 2022 at 11:27:25AM +0200, Salvatore Bonaccorso wrote:
> > Control: tags -1 + moreinfo
> > 
> > Hi,
> > 
> > On Wed, Apr 13, 2022 at 09:58:10PM +0200, mh wrote:
> > > It seems 5.17.x has problems with the respective FW (no problems with
> > > prior kernels)
> > > 
> > > dmesg output after trying to load list of broadcasters
> > > *
> > > [ 6801.250773] si2168 2-0064: downloading firmware from file
> > > 'dvb-demod-si2168-b40-01.fw' [ 6801.634181] si2168 2-0064: firmware
> > > version: B 4.0.11 [ 6801.643054] si2157 5-0060: found a 'Silicon Labs
> > > Si2157-A30 ROM 0x50' [ 6801.643117] si2157 5-0060: Can't continue
> > > without a firmware.
> > > **
> > 
> > Can you please verify it again with the current version in unstable
> > (5.17.3-1).
> 
> Actually, can you please try the attached patch?
> 
> See
> https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html#s4.2.2
> for instructions.

amd64 builds with that patch applied (but note not signed!) can be
found at:

https://people.debian.org/~carnil/tmp/linux/5.17.3-1a~test/

if this can help testing. Offlist I got a reply that 5.17.4 seem to
address the issue, so that would confirm possibly further the issue.

Regards,
Salvatore



Bug#1010117: librostlab: binary-all FTBFS

2022-04-24 Thread Adrian Bunk
Source: librostlab
Version: 1.0.20-11
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/fetch.php?pkg=librostlab=all=1.0.20-11=1642778070=0

...
   dh_missing -i
dh_missing: warning: usr/include/rostlab/aux_functions.h exists in debian/tmp 
but is not installed to anywhere 
dh_missing: warning: usr/include/rostlab/blosum62.h exists in debian/tmp but is 
not installed to anywhere 
dh_missing: warning: usr/include/rostlab/cwd_resource.h exists in debian/tmp 
but is not installed to anywhere 
dh_missing: warning: usr/include/rostlab/cxxgrp.h exists in debian/tmp but is 
not installed to anywhere 
dh_missing: warning: usr/include/rostlab/cxxpwd.h exists in debian/tmp but is 
not installed to anywhere 
dh_missing: warning: usr/include/rostlab/euid_egid_resource.h exists in 
debian/tmp but is not installed to anywhere 
dh_missing: warning: usr/include/rostlab/file_lock_resource.h exists in 
debian/tmp but is not installed to anywhere 
dh_missing: warning: usr/include/rostlab/mapAA2int.h exists in debian/tmp but 
is not installed to anywhere 
dh_missing: warning: usr/include/rostlab/readFasta.h exists in debian/tmp but 
is not installed to anywhere 
dh_missing: warning: usr/include/rostlab/rostlab_stdexcept.h exists in 
debian/tmp but is not installed to anywhere 
dh_missing: warning: usr/include/rostlab/rostlab_stdio.h exists in debian/tmp 
but is not installed to anywhere 
dh_missing: warning: usr/include/rostlab/rostlab_stdlib.h exists in debian/tmp 
but is not installed to anywhere 
dh_missing: warning: usr/include/rostlab/umask_resource.h exists in debian/tmp 
but is not installed to anywhere 
dh_missing: warning: usr/lib/x86_64-linux-gnu/librostlab.a exists in debian/tmp 
but is not installed to anywhere 
dh_missing: warning: usr/lib/x86_64-linux-gnu/librostlab.la exists in 
debian/tmp but is not installed to anywhere 
dh_missing: warning: usr/lib/x86_64-linux-gnu/librostlab.so exists in 
debian/tmp but is not installed to anywhere 
dh_missing: warning: usr/lib/x86_64-linux-gnu/librostlab.so.3 exists in 
debian/tmp but is not installed to anywhere 
dh_missing: warning: usr/lib/x86_64-linux-gnu/librostlab.so.3.0.0 exists in 
debian/tmp but is not installed to anywhere 
dh_missing: error: missing files, aborting
The following debhelper tools have reported what they installed (with 
files per package)
 * dh_installdocs: librostlab-doc (3), librostlab3 (0), librostlab3-dev 
(2)
 * dh_installexamples: librostlab-doc (0), librostlab3 (0), 
librostlab3-dev (1)
If the missing files are installed by another tool, please file a bug 
against it.
When filing the report, if the tool is not part of debhelper itself, 
please reference the
"Logging helpers and dh_missing" section from the "PROGRAMMING" guide 
for debhelper (10.6.3+).
  (in the debhelper package: /usr/share/doc/debhelper/PROGRAMMING.gz)
Be sure to test with dpkg-buildpackage -A/-B as the results may vary 
when only a subset is built
If the omission is intentional or no other helper can take care of this 
consider adding the
paths to debian/not-installed.

Remember to be careful with paths containing "x86_64-linux-gnu", where 
you might need to
use a wildcard or (assuming compat 13+) e.g. ${DEB_HOST_MULTIARCH} in 
debian/not-installed
to ensure it works on all architectures (see #961104).
make: *** [debian/rules:8: binary-indep] Error 25



Bug#1009671: (ITP: python-parsimonious -- fastest pure-Python PEG parser)

2022-04-24 Thread Nilson Silva
Hi,
In order to meet Debian guidelines (Python Team) this package is renamed 
and first paragraph of the long description:

from : python3-parsimonious to: python-parsimonious

from: visa ser o analisador de lookahead arbitrário mais rápido escrito
   em Python puro - e o mais utilizável.

to: aims to be the fastest arbitrary lookahead parser written
in pure Python - and the most usable.

thanks!

___
Package: wnpp
Severity: wishlist
Owner: Josenilson Ferreira da Silva 
X-Debbugs-Cc: debian-de...@lists.debian.org, nilsonfsi...@hotmail.com

* Package name    : python-parsimonious
  Version         : 0.9.0
  Upstream Author : Name  Erik Rose 
* URL             : https://github.com/erikrose/parsimonious
* License         : MIT/X
  Programming Lang: Python
  Description     : fastest pure-Python PEG parser


aims to be the fastest arbitrary lookahead parser written
in pure Python - and the most usable.
.
based on parsing expression grammars (PEGs), which means it is fed
with a simplified type of EBNF notation.
.
was designed to undergird a MediaWiki parser that wouldn't take 5
seconds or a GB of RAM to do one page, but it's applicable to all
sorts of languages.

Nilson Silva 
 



Bug#1010074: RFS: show-in-file-manager/1.1.4-1 [RFP] -- Open the system file manager and optionally select files in it

2022-04-24 Thread Antoine Beaupré
Hi!

I tested the package and it generally looks good, but tests fail in
autopkgtest:

autopkgtest [15:28:00]: test autodep8-python3: set -e ; for py in $(py3versions 
-r 2>/dev/null) ; do cd "$AUTOPKGTEST_TMP" ; echo "Testing with $py:" ; $py -c 
"import showinfilemanager; print(showinfilemanager)" ; done
autopkgtest [15:28:00]: test autodep8-python3: [---
Testing with python3.9:
Traceback (most recent call last):
  File "", line 1, in 
ModuleNotFoundError: No module named 'showinfilemanager'
autopkgtest [15:28:01]: test autodep8-python3: ---]
autopkgtest [15:28:02]: test autodep8-python3:  - - - - - - - - - - results - - 
- - - - - - - -
autodep8-python3 FAIL non-zero exit status 1
autopkgtest [15:28:03]:  summary
autodep8-python3 FAIL non-zero exit status 1
qemu-system-x86_64: terminating on signal 15 from pid 136604 (/usr/bin/python3)


I'm doing this in a new qemu-based setup so it's possible this is due to
my setup, can you reproduce?

a.

-- 
For every complex problem, there is an answer that is clear, simple -
and wrong.
- H.L. Mencken



Bug#1010116: utidylib: Not compatible with tidy-html5 5.8 yet

2022-04-24 Thread Boyuan Yang
Source: utidylib
Version: 0.5-3
Severity: important
Tags: sid  bookworm
X-Debbugs-CC: ni...@debian.org
User: tidy-ht...@packages.debian.org
Usertags: tidy5.8

Dear Debian utidylib package miantainer,

Currently utidylib is not compatible with tidy-html5 5.8 in experimental. It
hardcodes old library names (libtidy5deb1, libtidy5) in build-dep and dep
list. Besides, the source code itself may also be incompatible with tidy-html5
5.8 due to API and format changes between tidy 5.6.0 and 5.8.0.

Please consider working with upstream to make the package compatible with new
tidy-html5 release for a smooth tidy library transition in Debian. Thanks!

Regards,
Boyuan Yang


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


Bug#1010115: libhtml-tidy5-perl: FTBFS with tidy-html5 5.8

2022-04-24 Thread Boyuan Yang
Source: libhtml-tidy5-perl
Version: 1.06-1
Severity: important
Tags: sid  bookworm
X-Debbugs-CC: gre...@debian.org
User: tidy-ht...@packages.debian.org
Usertags: tidy5.8

Dear Debian libhtml-tidy5-perl package maintainer,

Your package FTBFS with tidy-html5 5.8.0 currently in experimental. This is
likely due to API and format changes between tidy 5.6.0 and 5.8.0. The
relavant error messages are attached below.

Please consider making the package compatible with new tidy-html5 release for
a smooth tidy library transition in Debian. Thanks!

Regards,
Boyuan Yang

==

dh_auto_test
make -j8 test TEST_VERBOSE=1
make[1]: Entering directory '/<>'
"/usr/bin/perl" -MExtUtils::Command::MM -e 'cp_nonempty' -- Tidy5.bs
blib/arch/auto/HTML/Tidy5/Tidy5.bs 644
PERL_DL_NONLAZY=1 "/usr/bin/perl" "-MExtUtils::Command::MM" "-MTest::Harness"
"-e" "undef *Test::Harness::Switches; test_harness(1, 'blib/lib',
'blib/arch')" t/*.t
# Testing HTML::Tidy5 1.06, tidy library version 5.8.0, Perl 5.034000,
/usr/bin/perl
t/00-load.t  
1..2
ok 1 - HTML::Tidy5 requires version 5.6.0 or higher of the tidy-html5 library
ok 2 - HTML::Tidy5 and Test::HTML::Tidy5 versions must match
ok
t/cfg-for-parse.t .. 
1..3
ok 1 - An object of class 'HTML::Tidy5' isa 'HTML::Tidy5'
ok 2 - Parsed OK
ok 3 - Matching errors
ok
t/clean-crash.t  
1..2
ok 1 - An object of class 'HTML::Tidy5' isa 'HTML::Tidy5'
ok 2 - Messages match
ok
t/clean.t .. 
1..3
ok 1 - An object of class 'HTML::Tidy5' isa 'HTML::Tidy5'
ok 2 - clean() croaks when not given a string or list of strings
ok 3 - $tidy->clean("") returns empty HTML document
ok

#   Failed test at t/drop-empty-elements.t line 34.
# Structures begin differing at:
#  $got->[0] = 'test (4:9) Warning: blank 'title' element'
# $expected->[0] = 'test (7:9) Warning: trimming empty '
# Looks like you failed 1 test of 2.

#   Failed test 'default constructor warns about empty spans'
#   at t/drop-empty-elements.t line 37.

#   Failed test at t/drop-empty-elements.t line 46.
# Structures begin differing at:
#  $got->[0] = 'test (4:9) Warning: blank 'title' element'
# $expected->[0] = 'test (7:9) Warning: trimming empty '
# Looks like you failed 1 test of 2.

#   Failed test 'drop_empty_elements => 1 gives message'
#   at t/drop-empty-elements.t line 49.

#   Failed test at t/drop-empty-elements.t line 58.
# Structures begin differing at:
#  $got->[0] = 'test (4:9) Warning: blank 'title' element'
# $expected->[0] = Does not exist
# Looks like you failed 1 test of 2.

#   Failed test 'drop_empty_elements => 0 gives no messages'
#   at t/drop-empty-elements.t line 59.
# Looks like you failed 3 tests of 3.
t/drop-empty-elements.t  
1..3
# Subtest: default constructor warns about empty spans
1..2
ok 1 - An object of class 'HTML::Tidy5' isa 'HTML::Tidy5'
not ok 2
not ok 1 - default constructor warns about empty spans
# Subtest: drop_empty_elements => 1 gives message
1..2
ok 1 - An object of class 'HTML::Tidy5' isa 'HTML::Tidy5'
not ok 2
not ok 2 - drop_empty_elements => 1 gives message
# Subtest: drop_empty_elements => 0 gives no messages
1..2
ok 1 - An object of class 'HTML::Tidy5' isa 'HTML::Tidy5'
not ok 2
not ok 3 - drop_empty_elements => 0 gives no messages
Dubious, test returned 3 (wstat 768, 0x300)
Failed 3/3 subtests 
t/extra-quote.t  
1..4
ok 1 - An object of class 'HTML::Tidy5' isa 'HTML::Tidy5'
ok 2 - Parsed OK
ok 3 - Should have exactly three messages
ok 4 - Matching warnings
ok

#   Failed test 'html_fragment_tidy_ok can handle it'
#   at t/html_fragment_tidy_ok.t line 49.
# STDOUT is:
# > not ok 1 - html_fragment_tidy_ok can handle it
# not:
# > ok 1 - html_fragment_tidy_ok can handle it
# as expected
# STDERR is:
# > #   Failed test 'html_fragment_tidy_ok can handle it'
# > #   at t/html_fragment_tidy_ok.t line 48.
# > # Errors: html_fragment_tidy_ok can handle it
# > # (-2:9) Warning: blank 'title' element
# > # 1 message on the page
# not:
# > 
# > 
# > 
# > 
# > 
# as expected
# Looks like you failed 1 test of 2.

#   Failed test 'html_tidy_ok fails on a fragment, but html_fragment_tidy_ok
is OK'
#   at t/html_fragment_tidy_ok.t line 50.

#   Failed test 'html_fragment_tidy_ok on sloppy doc'
#   at t/html_fragment_tidy_ok.t line 85.
# STDERR is:
# > #   Failed test 'html_fragment_tidy_ok on sloppy doc'
# > #   at t/html_fragment_tidy_ok.t line 84.
# > # Errors: html_fragment_tidy_ok on sloppy doc
# > # (2:59) Warning: discarding unexpected 
# > # (-2:9) Warning: blank 'title' element
# > # (3:5) Warning:  lacks "alt" attribute
# > # 3 messages on the page
# not:
# > /\ \ 

Bug#1010114: libhtml-tidy-perl: FTBFS with tidy-html5 5.8

2022-04-24 Thread Boyuan Yang
Source: libhtml-tidy-perl
Version: 1.60-4
Severity: important
X-Debbugs-CC: f...@debian.org gre...@debian.org
User: tidy-ht...@packages.debian.org
Usertags: tidy5.8

Dear Debian libhtml-tidy-perl package maintainer,

Your package FTBFS with tidy-html5 5.8.0 currently in experimental. This is
likely due to API and format changes between tidy 5.6.0 and 5.8.0. The
relavant error messages are attached below.

Please consider making the package compatible with new tidy-html5 release for
a smooth tidy library transition in Debian. Thanks!

Regards,
Boyuan Yang


make[1]: Leaving directory '/<>'
   dh_auto_test
make -j8 test TEST_VERBOSE=1
make[1]: Entering directory '/<>'
"/usr/bin/perl" -MExtUtils::Command::MM -e 'cp_nonempty' -- Tidy.bs
blib/arch/auto/HTML/Tidy/Tidy.bs 644
PERL_DL_NONLAZY=1 "/usr/bin/perl" "-MExtUtils::Command::MM" "-MTest::Harness"
"-e" "undef *Test::Harness::Switches; test_harness(1, 'blib/lib',
'blib/arch')" t/*.t
# Testing HTML::Tidy 1.60, tidyp 5.008000, Perl 5.034000, /usr/bin/perl
t/00-load.t .. 
1..1
ok 1 - Modules loaded
ok
t/cfg-for-parse.t  
1..3
ok 1 - An object of class 'HTML::Tidy' isa 'HTML::Tidy'
ok 2 - Parsed OK
ok 3 - Matching errors
ok
t/clean-crash.t .. 
1..2
ok 1 - An object of class 'HTML::Tidy' isa 'HTML::Tidy'
ok 2 - Ended OK
ok
t/clean.t  
1..3
ok 1 - An object of class 'HTML::Tidy' isa 'HTML::Tidy'
ok 2 - clean() croaks when not given a string or list of strings
ok 3 - $tidy->clean("") returns empty HTML document
ok
t/extra-quote.t .. 
1..4
ok 1 - An object of class 'HTML::Tidy' isa 'HTML::Tidy'
ok 2 - Parsed OK
ok 3 - Should have exactly four messages
ok 4 - Matching warnings
ok
t/ignore-text.t .. 
1..3
ok 1 - An object of class 'HTML::Tidy' isa 'HTML::Tidy'
ok 2 - Parsed OK
ok 3 - Matching warnings
ok
t/ignore.t ... 
1..9
ok 1 - An object of class 'HTML::Tidy' isa 'HTML::Tidy'
ok 2 - Parsed OK
ok 3 - Matching warnings
ok 4 - An object of class 'HTML::Tidy' isa 'HTML::Tidy'
ok 5 - Parsed OK
ok 6 - Matching errors
ok 7 - An object of class 'HTML::Tidy' isa 'HTML::Tidy'
ok 8 - eval should fail
ok 9 - Throws an error
ok
t/illegal-options.t .. 
ok 1 - option force-output is not supported
ok 2 - option gnu-emacs-file is not supported
ok 3 - option gnu-emacs is not supported
ok 4 - option keep-time is not supported
ok 5 - option quiet is not supported
ok 6 - option slide-style is not supported
ok 7 - option write-back is not supported
1..7
ok
t/levels.t ... 
1..3
ok 1 - An object of class 'HTML::Tidy' isa 'HTML::Tidy'
ok 2 - Parsed OK
ok 3 - Matching messages
ok
t/message.t .. 
1..4
ok 1 - An object of class 'HTML::Tidy::Message' isa 'HTML::Tidy::Message'
# Subtest: _matchup( With line numbers )
1..6
ok 1 - as_string matches
ok 2 - column matches
ok 3 - file matches
ok 4 - line matches
ok 5 - text matches
ok 6 - type matches
ok 2 - _matchup( With line numbers )
ok 3 - An object of class 'HTML::Tidy::Message' isa 'HTML::Tidy::Message'
# Subtest: _matchup( Without line numbers )
1..6
ok 1 - as_string matches
ok 2 - column matches
ok 3 - file matches
ok 4 - line matches
ok 5 - text matches
ok 6 - type matches
ok 4 - _matchup( Without line numbers )
ok
t/opt-00.t ... 
1..1
ok 1 - Cleaned stuff looks like what we expected
ok
HTML::Tidy: Unknown error type: FAKE_ERROR_TYPE at t/parse-errors.t line 18.
t/parse-errors.t . 
1..2
ok 1 - encountered 1 parsing error
ok 2 - got 7 messages when parsing errors
ok
t/parse.t  
1..2
ok 1 - An object of class 'HTML::Tidy' isa 'HTML::Tidy'
ok 2 - parse() dies when not given a string or array of strings to parse
ok
t/perfect.t .. 
1..3
ok 1 - An object of class 'HTML::Tidy' isa 'HTML::Tidy'
ok 2 - Parsed OK
ok 3 - Should have no messages
ok
t/pod-coverage.t . 
1..2
ok 1 - Pod coverage on HTML::Tidy
ok 2 - Pod coverage on HTML::Tidy::Message
ok
t/pod.t .. 
1..3
ok 1 - POD test for blib/lib/HTML/Tidy.pm
ok 2 - POD test for blib/lib/HTML/Tidy/Message.pm
ok 3 - POD test for blib/script/webtidy (no pod)
ok

#   Failed test 'The cleaned stuff shouldn't have any errors'
#   at t/roundtrip.t line 26.
# Structures begin differing at:
#  $got->[0] =  (5:1) Warning: blank 'title' element
# $expected->[0] = Does not exist
# Looks like you failed 1 test of 3.
t/roundtrip.t  
1..3
ok 1 - An object of class 'HTML::Tidy' isa 'HTML::Tidy'
not ok 2 - The cleaned stuff shouldn't have any errors
ok 3 - Cleaned up properly
Dubious, test returned 1 (wstat 256, 0x100)
Failed 1/3 subtests 
t/segfault-form.t  
1..3
ok 1 - An object of class 'HTML::Tidy' isa 'HTML::Tidy'
ok 2 - An object of class 'HTML::Tidy' isa 'HTML::Tidy'
ok 3 - Cleaned OK
ok
t/simple.t ... 
1..4
ok 1 - An object of class 'HTML::Tidy' isa 'HTML::Tidy'
ok 2 - Parsed OK
ok 3 - Right number of initial messages
ok 4 - Cleared the messages
ok

#   Failed test 

Bug#1009367: Confirm fix

2022-04-24 Thread Stephan Verbücheln
The last update fixed the bug for my existing users. I can also confirm
that the bug is fixed for newly created users.

Regards



Bug#1008997: cups: impossible to print on hp envy 5536 from sid

2022-04-24 Thread Brian Potkin
On Fri 08 Apr 2022 at 18:23:42 +0100, Brian Potkin wrote:

> On Thu 07 Apr 2022 at 20:36:45 +0200, alain wrote:
> 
> > i've just gone to this thread :
> > 
> >   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=983349
> > 
> > i saw interesting things but , apparently , nothing that applies to my
> > actual case .
> > 
> > alain@sid:~$ sudo systemctl list-units "ipp-usb*" | grep service
> > [sudo] Mot de passe de alain :
> >   ipp-usb.service loaded active running Daemon for IPP over USB printer
> > support
> > 
> > 
> > alain@sid:~$ scanimage -L
> > device `hpaio:/usb/ENVY_5530_series?serial=CN595530XD06BX' is a
> > Hewlett-Packard ENVY_5530_series all-in-one
> 
> Your scanner is not found. Also, ippfind (which is used by driverless)
> and avahi-browse find the bbox but not the ENVY.

With the unstable version of ipp-usb, please do this:

1. Disconnect the device from USB.

2. The logs for ipp-usb are in /var/log/ipp-usb/. We want the first one,
   named like SOMETHING.log.

3. As root, empty SOMETHING.log with

 >/var/log/ipp-usb/SOMETHING.log

4. Resconnect the device to USB.

5. Copy SOMETHING.log to somewhere as connect.txt and compress it with

 gzip connect.txt

6. Send connect.txt.gz here.

Cheers,

Brian.



Bug#1010113: ITP: dxr -- Code Search and Cross-Reference Tool

2022-04-24 Thread Josenilson Ferreira da Silva
Package: wnpp
Severity: wishlist
Owner: Josenilson Ferreira da Silva 
X-Debbugs-Cc: debian-de...@lists.debian.org, nilsonfsi...@hotmail.com

* Package name: dxr
  Version : 0.0.+git20140331.eda5168
  Upstream Author : Erik Rose 
* URL : https://github.com/erikrose/dxr
* License : MIT/X
  Programming Lang: Python
  Description : Code Search and Cross-Reference Tool

Ssource code browser and search engine, building on the work of
LXR and MXR.It supports full-text and regex searches as well as
 structural queries like "Find all the callers of this function.
 " Behind the scenes, it uses trigram indices, the re2 library,
 and static analysis data collected by instrumented compilers.
 DXR runs only on Linux for the moment



Bug#1009671: Acknowledgement (ITP: python3-parsimonious -- fastest pure-Python PEG parser)

2022-04-24 Thread Nilson Silva
Hi
just complementing

This library is a dependency for a package I'm packaging.
as per the link below:

Project:
https://github.com/erikrose/dxr

Dependencies:
https://github.com/erikrose/dxr/blob/master/requirements.txt

o



Bug#1010112: virtualbox: 6.1.34-dfsg-2 broken, guest VM display window stays black with blinking cursor

2022-04-24 Thread nbi
Package: virtualbox
Version: 6.1.34-dfsg-2
Severity: serious

This version is completely unusable as the guest OS never starts - the VM
display stays black with a blinking cursor. It is not guest OS dependent as
this is 100% reproducible with any guest OS. The VM log does not show any
errors. Last working version was 6.1.32.


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

Kernel: Linux 5.15.5 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_FIRMWARE_WORKAROUND, 
TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages virtualbox depends on:
ii  adduser   3.121
ii  iproute2  5.17.0-1
ii  libc6 2.33-7
ii  libcurl3-gnutls   7.82.0-2
ii  libdevmapper1.02.12:1.02.175-2.1
ii  libgcc-s1 12-20220319-1
ii  libgl11.4.0-1
ii  libgsoap-2.8.117  2.8.117-2
ii  liblzf1   3.6-3
ii  libopus0  1.3.1-0.1
ii  libpng16-16   1.6.37-3
ii  libsdl1.2debian   1.2.15+dfsg2-6
ii  libssl1.1 1.1.1n-1
ii  libstdc++612-20220319-1
ii  libvncserver1 0.9.13+dfsg-3
ii  libvpx7   1.11.0-2
ii  libx11-6  2:1.7.5-1
ii  libxcursor1   1:1.2.0-2
ii  libxml2   2.9.13+dfsg-1
ii  libxt61:1.2.1-1
ii  procps2:3.3.17-7+b1
ii  python3   3.10.4-1
ii  python3.103.10.4-1
ii  virtualbox-dkms [virtualbox-modules]  6.1.34-dfsg-2
ii  virtualbox-source 6.1.34-dfsg-2
ii  zlib1g1:1.2.11.dfsg-4

Versions of packages virtualbox recommends:
ii  libqt5core5a5.15.2+dfsg-16
ii  libqt5gui5  5.15.2+dfsg-16
ii  libqt5opengl5   5.15.2+dfsg-16
ii  libqt5widgets5  5.15.2+dfsg-16
ii  libxcb1 1.14-3
ii  libxext62:1.3.4-1
ii  virtualbox-qt   6.1.34-dfsg-2

Versions of packages virtualbox suggests:
pn  vde2
ii  virtualbox-guest-additions-iso  6.1.34-1

-- no debconf information



Bug#1010111: RM: manpages-fr-extra -- RoQA; transitional package, has been part of a stable release

2022-04-24 Thread Dr. Tobias Quathamer

Package: ftp.debian.org
Severity: normal

Hi FTP team,

please remove the transitional package manpages-fr-extra, it has been 
released with bullseye and is no longer needed.


Regards,
Tobias


OpenPGP_signature
Description: OpenPGP digital signature


Bug#1010110: ncbi-blast+: terminate called after throwing an instance of 'ncbi::CIO_Exception'

2022-04-24 Thread Patrice DUROUX
Package: ncbi-blast+
Version: 2.11.0+ds-1
Severity: normal

Dear Maintainer,

Using the same command line with different versions of the package,
here are the results:

2.10.1+ds-1 (using snapshot.d.o) ok

2.11.0+ds-1 (Bullseye) ko (exitcode=134)
terminate called after throwing an instance of 'ncbi::CIO_Exception'
  what():  NCBI C++ Exception:
T3 "c++/include/corelib/ncbidiag.hpp", line 445: Error: 
(CIO_Exception::eIO_InvalidArg) ncbi::s_HttpConnectorBuilder() - 
CConn_HttpStream::CConn_HttpStream():  Bad URL

Aborted

2.12.0+ds-3+b1 (Sid) ok

Moreover, I also tried a local installation of the new upstream 2.13.0+ [1,2]
and it is ok.

Regards,
Patrice

[1] https://www.ncbi.nlm.nih.gov/books/NBK131777/
[2] https://ftp.ncbi.nlm.nih.gov/blast/executables/blast+/LATEST/


-- 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-13-amd64 (SMP w/32 CPU threads)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages ncbi-blast+ depends on:
ii  libbz2-1.0  1.0.8-4
ii  libc6   2.31-13+deb11u3
ii  libgcc-s1   10.2.1-6
ii  libgomp110.2.1-6
ii  liblmdb00.9.24-1
ii  libmbedcrypto3  2.16.9-0.1
ii  libmbedtls122.16.9-0.1
ii  libpcre32:8.39-13
ii  libstdc++6  10.2.1-6
ii  ncbi-data   6.1.20170106+dfsg1-9
ii  perl5.32.1-4+deb11u2
ii  python3 3.9.2-3
ii  zlib1g  1:1.2.11.dfsg-2+deb11u1

ncbi-blast+ recommends no packages.

ncbi-blast+ suggests no packages.

-- no debconf information



Bug#1010109: RM: higan -- ROM; superseded by ares

2022-04-24 Thread Tobias Hansen
Package: ftp.debian.org
Severity: normal

Please remove higan from unstable. It is superseded by ares, which I packaged 
to replace higan. higan still exists as a slightly different version of the 
same program, but ares is more user friendly and more actively maintained.

Thanks,
Tobias



Bug#1009661: phosh: gnome-control-center 42 is in unstable

2022-04-24 Thread Guido Günther
Version: phosh/0.17.0-2

On Wed, Apr 13, 2022 at 03:36:20PM -0400, Jeremy Bicha wrote:
> Source: phish
> Version: 0.17.0-1
> X-Debbugs-CC: a...@sigxcpu.org
> 
> gnome-control-center 42 was just uploaded to unstable.
> You can revert 
> https://salsa.debian.org/DebianOnMobile-team/phosh/-/commit/b5e2f983d

Fixed now. Thanks!
 -- Guido



Bug#1010108: recutils 1.9 has been released, Debian packages are outdated

2022-04-24 Thread Christian Grothoff
Package: recutils
Version: 1.8-1
Severity: normal
X-Debbugs-Cc: groth...@gmail.com

Dear Maintainer,

GNU Recutils 1.9 is available, fixing security vulnerabilities.
Please make an updated package available.


-- 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-13-amd64 (SMP w/16 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages recutils depends on:
ii  libc6 2.31-13+deb11u3
ii  libgcrypt20   1.8.7-6
ii  libreadline8  8.1-1
ii  librec1   1.8-1

recutils recommends no packages.

recutils suggests no packages.

-- no debconf information



Bug#1010107: ITP: python-wilderness -- light wrapper around argparse

2022-04-24 Thread Louis-Philippe Véronneau
Package: wnpp
Severity: wishlist
Owner: Louis-Philippe Véronneau 

Package name: python-wilderness
Version : 0.1.5
URL : https://github.com/GjjvdBurg/wilderness
License : Expat
Programming Lang: Python
Description : a light wrapper around argparse for creating command
line applications with multiple subcommands

Wilderness is a light wrapper around argparse for creating command line
applications with multiple subcommands, in the style of Git. Wilderness
also makes it easy to generate man pages for your application.

Wilderness is heavily inspired by Cleo and argparse-manpage, but aims to
stick as closely as possible to argparse to avoid users having to learn
a new API.

I'm planning to maintain this package in the Python Team.

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



Bug#1004912: Acknowledgement (rarcrack dead upstream?)

2022-04-24 Thread Pierre Rudloff




Le 21/04/2022 à 23:27, Bastian Germann a écrit :
On Thu, 3 Feb 2022 15:40:45 +0100 Mathieu Malaterre  
wrote:

Should we switch to:

https://github.com/jaredsburrows/rarcrack

?


I second that. But you should think of a NMU or ITS to change the upstream.
The package maintainer is apparently inactive for years.


What improvements does this fork bring (apart from the macOS compatibility)?



Bug#1009998: The error occurs with smbclient 2:4.16.0+dfsg-6

2022-04-24 Thread Dramon Conte
The error occurs with smbclient 2:4.16.0+dfsg-6, downgrading to
2:4.13.13+dfsg-1~deb11u3
fixes the issue.
See:
https://bbs.archlinux.org/viewtopic.php?id=275179
https://forums.debian.net/viewtopic.php?t=126176
Att.
Dramon Conte


Bug#1010106: macchanger does not change macaddress at boot

2022-04-24 Thread Hans-J. Ullrich
Package: macchanger
Version: 1.7.0-5.4
Severity: wishlist

Dear Maintainer,

it looks that macchanger does not change macaddress at boot, which is offered 
by the installer. However, I looked around and found, that macchanger should be 
adapted to systemd.

So it will be nice, if you could change the package of the next version and 
adapt it to systemd, as suggested.

Here is an example from Ubuntu, maybe it is easy to implement:

https://www.linuxuprising.com/2018/05/how-to-permanently-change-mac-address.html

I hope, this will help and ease the work.

Thanks for your work! 

Best regards

Hans


 

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

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

Versions of packages macchanger depends on:
ii  debconf [debconf-2.0]  1.5.77
ii  dpkg   1.20.9
ii  install-info   6.7.0.dfsg.2-6
ii  libc6  2.32-4

macchanger recommends no packages.

macchanger suggests no packages.

-- Configuration Files:
/etc/default/macchanger changed:
ENABLE_ON_POST_UP_DOWN=true


-- debconf-show failed



Bug#451485: acre not longer based on survey foot

2022-04-24 Thread Adrian Mariano
close this bug



Bug#956249: Not adding this

2022-04-24 Thread Adrian Mariano
Close this bug.



Bug#956016: Add Flight Levels

2022-04-24 Thread Adrian Mariano
This was implemented in 2.20.  Please close the bug.



Bug#946574: --comformable implemented, close bug

2022-04-24 Thread Adrian Mariano
The --conformable option was added in 2.20 and the example script
added to the manual.  Close the bug.



Bug#1010105: ITP: python-lrcalc -- Python interface to lrcalc

2022-04-24 Thread Tobias Hansen
Package: wnpp
X-Debbugs-Cc: debian-de...@lists.debian.org
Owner: Tobias Hansen 
Severity: wishlist

* Package name: python-lrcalc
  Version : 2.1
  Upstream Author : Anders S. Buch 
* URL : http://www.math.rutgers.edu/~asbuch/lrcalc/
* License : GPL-3+
  Programming Lang: Python
  Description : Python interface to lrcalc

This is a Cython interface to the C library lrcalc.

It is a dependency of sagemath >= 9.6. I am planning to maintain it within the
Debian Math Team.



Bug#1010104: cqrlog: missing AppStream metadata

2022-04-24 Thread asciiwolf
Package: cqrlog
Version: 2.5.2-1

The cqrlog package has no AppStream metadata file although this file is already 
present in upstream[1]. Please, consider adding this file.

[1] https://github.com/ok2cqr/cqrlog/blob/master/tools/cqrlog.appdata.xml



Bug#1010083: Fwd: librust-addr2line-dev: please upgrade to newer release

2022-04-24 Thread Jonas Smedegaard
Quoting Peter Michael Green (2022-04-24 02:35:05)
> > Please upgrade addr2line to a newer release - preferably v0.17.0 but 
> > possibly v0.13.0 (in experimental since more than 5 months) is 
> > adequate.
> 
> Unfortunately it seems addr2line, gimli, object and some other 
> packages are fairly closely tied together. I don't think updating them 
> individually is feasible and updating the whole lot including object 
> would break dwarf2sources.
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=998306
> 
> Now maybe the time has come that dwarf2sources should be broken, the 
> maintainer has had nearly 6 months warning to fix their package but 
> i'm a little reluctant to break a package that is in Debian now for 
> the sake of a package that may be in Debian at some time in the 
> future.

Given the Debian package salvaging suggests 6 months of total silence a 
reasonable threshold, I would find a *shorter* threshold sensible here.

...but that's just a suggestion - I sure don't speak for the Rust team.


> > error[E0277]: the trait bound `Rc<[u8]>: CloneStableDeref` is not satisfied
> > --> 
> > /usr/share/cargo/registry/safe-network-0.58.13/debian/cargo_registry/addr2line-0.10.0/src/lib.rs:92:20
> >  |
> > 92  | pub struct Context>
> >  |^ the trait `CloneStableDeref` is not implemented 
> > for `Rc<[u8]>`
> >  |
> > note: required by a bound in `EndianReader`
> >
> > error[E0277]: the trait bound `Rc<[u8]>: CloneStableDeref` is not satisfied
> > --> 
> > /usr/share/cargo/registry/safe-network-0.58.13/debian/cargo_registry/addr2line-0.10.0/src/lib.rs:101:14
> >  |
> > 101 | impl Context> {
> >  |  ^^ the trait 
> > `CloneStableDeref` is not implemented for `Rc<[u8]>`
> >  |
> > note: required by a bound in `EndianReader`
> >
> > For more information about this error, try `rustc --explain E0277`.
> > error: could not compile `addr2line` due to 2 previous errors
> With the version of addr2line currently in Debian you need to enable 
> the "std" feature, it won't build with no features at all enabled. You 
> can instead enable the alloc feature but that only works if the 
> compiler is running in nightly mode.

Thanks, that was very helpful.

(unfortunately I then later in the build ran into another related issue, 
as reported in https://bugs.debian.org/1010099


 - 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#1008779: 1.37-1 has been uploaded to DELAYED/7

2022-04-24 Thread Antonio Radici
On Fri, Apr 22, 2022 at 09:18:23AM +0200, Jordi Mallach wrote:
> Hi,
> 
> This is to state that after 21 days, I've uploaded postgrey to
> DELAYED/7, as documented in the salvaging procedure.

Hi Jordi,
thanks for that. I was wondering if you are interested in taking it over?
Otherwise I will likely orphan the package because I'm not using postgrey
anymore.

Thanks for your upload!



Bug#956403: sasl2-bin: Log file missing string do_auth

2022-04-24 Thread Jason Naughton
Hi Bastian,

I wouldn’t worry about it any more.   I migrated to another solution a while 
back.  You can close this as it may have only effected me at the time.  To be 
honest I can’t even remember posting this bug as it was over 2 years ago.   

Cheers

Jason Naughton,  P.Eng, M.E.Sc,
Professional Contractor,
JMN Planning,  Pickering, Ontario,
Office: (647)-693-4880

> On Apr 24, 2022, at 09:24, Bastian Germann  wrote:
> 
> On Fri, 10 Apr 2020 13:54:46 -0400 Jason Naughton  wrote:
>> So it looks like in debian the package does not define HAVE_FUNC which leads 
>> to L_FUNC being set to " ".
>> I downloaded the source from the master and it seems that gcc implements 
>> this.  Compiling on my desktop I get:
>> checking whether gcc implements __func__... yes
>> Any chance this package can be compiled with this feature?
>> -- System Information:
>> Debian Release: 10.3
>>  APT prefers stable-updates
>>  APT policy: (500, 'stable-updates'), (500, 'stable')
>> Architecture: amd64 (x86_64)
>> Kernel: Linux 4.19.0-8-amd64 (SMP w/2 CPU cores)
>> Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), 
>> LANGUAGE=en_CA:en (charmap=UTF-8)
>> Shell: /bin/sh linked to /usr/bin/dash
>> Init: systemd (via /run/systemd/system)
>> Versions of packages sasl2-bin depends on:
>> ii  db-util5.3.1+nmu1
> 
> Hi Jason,
> 
> Does the bug also exist in bullseye or bookworm? If this is just a buster 
> issue, I will not fix it.
> 
> Thanks,
> Bastian


Bug#956403: sasl2-bin: Log file missing string do_auth

2022-04-24 Thread Bastian Germann

On Fri, 10 Apr 2020 13:54:46 -0400 Jason Naughton  wrote:

So it looks like in debian the package does not define HAVE_FUNC which leads to L_FUNC 
being set to " ".

I downloaded the source from the master and it seems that gcc implements this.  
Compiling on my desktop I get:

checking whether gcc implements __func__... yes

Any chance this package can be compiled with this feature?

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

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

Versions of packages sasl2-bin depends on:
ii  db-util5.3.1+nmu1


Hi Jason,

Does the bug also exist in bullseye or bookworm? If this is just a buster 
issue, I will not fix it.

Thanks,
Bastian



Bug#905737: reportbug: fails retrieving only some bugnumbers

2022-04-24 Thread yg2709
Package: python-debianbts
Followup-For: Bug #905737
X-Debbugs-Cc: yg2...@hotmail.com

Dear Maintainer,

First, my apologies for leaving this bug unattended, which no longer gives me 
problems several versions ago, by switching to python3-debianbts (currently 
3.2.0).

I think it can be marked as resolved.

Thank you very much.


-- System Information:
Debian Release: bookworm/sid
Architecture: amd64 (x86_64)

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



Bug#1008355: python-ldap: _slaptest.py fails with "slapd exited before opening port", breaking other package builds

2022-04-24 Thread Michael Banck
Hi,

On Sun, Apr 24, 2022 at 02:49:41PM +0200, Michael Banck wrote:
> If I apply the mentioned (and attached patch), slapd starts up fine:
> 
> |>>> import slapdtest
> |>>> server = slapdtest.SlapdObject()
> |>>> server.start()
> |starting slapd: %r /usr/sbin/slapd -f 
> /build/django-auth-ldap-3.0.0/python-ldap-test-49837/slapd.conf -F 
> /build/django-auth-ldap-3.0.0/python-ldap-test-49837/slapd.d -h 
> ldap://127.0.0.1:49837/ 
> ldapi://%2Fbuild%2Fdjango-auth-ldap-3.0.0%2Fpython-ldap-test-49837%2Fldapi -d > 0
> |>>> 
> 
> and django-auth-ldap's tests pass:
> 
> |I: pybuild base:239: PYTHONPATH=. python3.9 /usr/bin/django-admin test 
> --settings tests.settings
> |Creating test database for alias 'default'...
> |System check identified no issues (0 silenced).
> |starting slapd: %r /usr/sbin/slapd -f 
> /build/django-auth-ldap-3.0.0/python-ldap-test-33057/slapd.conf -F 
> /build/django-auth-ldap-3.0.0/python-ldap-test-33057/slapd.d -h 
> ldap://127.0.0.1:33057/ 
> ldapi://%2Fbuild%2Fdjango-auth-ldap-3.0.0%2Fpython-ldap-test-33057%2Fldapi -d > 0
> |
> |--
> |Ran 88 tests in 3.494s
> |
> |OK

However, python-ldap still doesn't get through its test suite (which
really should be run during package build or as autopkgtest) with that
patch, but with the attached updated patch it passes fine:

|Ran 235 tests in 42.709s
|
|OK (skipped=38, expected failures=5)


Michael
--- ./Lib/slapdtest/_slapdtest.py.orig	2022-04-24 12:55:37.979187400 +
+++ ./Lib/slapdtest/_slapdtest.py	2022-04-24 12:55:59.327002871 +
@@ -402,7 +402,6 @@
 slapd_args = [
 self.PATH_SLAPD,
 '-f', self._slapd_conf,
-'-F', self.testrundir,
 '-h', ' '.join(urls),
 ]
 if self._log.isEnabledFor(logging.DEBUG):



Bug#1010099: librust-backtrace-dev: fails to build

2022-04-24 Thread Jonas Smedegaard
Quoting Jonas Smedegaard (2022-04-24 13:29:24)
> In my attempt to use system-packaged crates when packaging 
> safe-network, I experience failure to compile crate backtrace:

For the record, the draft safe-network package succeeds building with 
newer backtrace and addr2line from experimental.  Concretely, the 
failure occurs when applying the following patch: 
https://salsa.debian.org/debian/safe-network/-/commit/1c26cac40693f3a2117484a4cbce2f89e7542430


Kind regards,

 - 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#1008355: django-auth-ldap: FTBFS: dh_auto_test: error: pybuild --test -i python{version} -p "3.10 3.9" --system=custom "--test-args=PYTHONPATH=. {interpreter} /usr/bin/django-admin test --settings

2022-04-24 Thread Michael Banck
forwarded 1008355 https://github.com/python-ldap/python-ldap/issues/422
tags +patch
thanks

Hi,

On Sun, Apr 24, 2022 at 01:21:33PM +0200, Michael Banck wrote:
> This error comes from python3-ldap's slaptest:
> 
> |$  python3
> |Python 3.10.4 (main, Apr  2 2022, 09:04:19) [GCC 11.2.0] on linux
> |Type "help", "copyright", "credits" or "license" for more information.
> |>>> import slapdtest
> |>>> server = slapdtest.SlapdObject()
> |>>> server.start()
> |Traceback (most recent call last):
> |  File "", line 1, in 
> |  File "/usr/lib/python3/dist-packages/slapdtest/_slapdtest.py", line 445, 
> in start
> |self._start_slapd()
> |  File "/usr/lib/python3/dist-packages/slapdtest/_slapdtest.py", line 420, 
> in _start_slapd
> |raise RuntimeError("slapd exited before opening port")
> |RuntimeError: slapd exited before opening port
> |>>> 
> 
> Not sure what the actual problem is,

When I add debugging (using "slapd_args.extend(['-d', '-1'])"
unconditionally around line 409), I get

|>>> import slapdtest
|>>> server = slapdtest.SlapdObject()
|>>> server.start()
|starting slapd: %r /usr/sbin/slapd -f 
/build/django-auth-ldap-3.0.0/python-ldap-test-45785/slapd.conf -F 
/build/django-auth-ldap-3.0.0/python-ldap-test-45785 -h ldap://127.0.0.1:45785/ 
ldapi://%2Fbuild%2Fdjango-auth-ldap-3.0.0%2Fpython-ldap-test-45785%2Fldapi -d -1
|62654543.29b9109c 0x7f121ed57980 @(#) $OpenLDAP: slapd 2.5.11+dfsg-1 (Mar 12 
2022 03:38:02) $
|   Debian OpenLDAP Maintainers 
|62654544.008b742b 0x7f121ed57980 daemon_init: ldap://127.0.0.1:45785/ 
ldapi://%2Fbuild%2Fdjango-auth-ldap-3.0.0%2Fpython-ldap-test-45785%2Fldapi
|62654544.008cb95c 0x7f121ed57980 daemon_init: listen on ldap://127.0.0.1:45785/
|62654544.008ccf75 0x7f121ed57980 daemon_init: listen on 
ldapi://%2Fbuild%2Fdjango-auth-ldap-3.0.0%2Fpython-ldap-test-45785%2Fldapi
|62654544.008ce019 0x7f121ed57980 daemon_init: 2 listeners to open...
|62654544.008cf2ec 0x7f121ed57980 ldap_url_parse_ext(ldap://127.0.0.1:45785/)
|62654544.008d759a 0x7f121ed57980 daemon: listener initialized 
ldap://127.0.0.1:45785/
|62654544.008d8a56 0x7f121ed57980 
ldap_url_parse_ext(ldapi://%2Fbuild%2Fdjango-auth-ldap-3.0.0%2Fpython-ldap-test-45785%2Fldapi)
|62654544.008e74f4 0x7f121ed57980 daemon: listener initialized 
ldapi://%2Fbuild%2Fdjango-auth-ldap-3.0.0%2Fpython-ldap-test-45785%2Fldapi
|62654544.008e85df 0x7f121ed57980 daemon_init: 2 listeners opened
|62654544.0099667a 0x7f121ed57980 slapd init: initiated server.
|62654544.009b64a3 0x7f121ed57980 slap_sasl_init: initialized!
|62654544.00b255c4 0x7f121ed57980 backend_startup_one: starting "cn=config"
|62654544.00b36ec4 0x7f121ed57980 config_setup_ldif: expected directory 
/build/django-auth-ldap-3.0.0/python-ldap-test-45785 to be empty!
|62654544.00b440d5 0x7f121ed57980 slapd destroy: freeing system resources.
|62654544.00b6056e 0x7f121ed57980 slapd stopped.
|62654544.00b6821b 0x7f121ed57980 connections_destroy: nothing to destroy.
|Traceback (most recent call last):
|  File "", line 1, in 
|  File "/usr/lib/python3/dist-packages/slapdtest/_slapdtest.py", line 447, in 
start
|self._start_slapd()
|  File "/usr/lib/python3/dist-packages/slapdtest/_slapdtest.py", line 422, in 
_start_slapd
|raise RuntimeError("slapd exited before opening port")
|RuntimeError: slapd exited before opening port

The error seems to be 
|config_setup_ldif: expected directory 
/build/django-auth-ldap-3.0.0/python-ldap-test-45785 to be empty!
which is open upstream item at 
https://github.com/python-ldap/python-ldap/issues/422
If I apply the mentioned (and attached patch), slapd starts up fine:

|>>> import slapdtest
|>>> server = slapdtest.SlapdObject()
|>>> server.start()
|starting slapd: %r /usr/sbin/slapd -f 
/build/django-auth-ldap-3.0.0/python-ldap-test-49837/slapd.conf -F 
/build/django-auth-ldap-3.0.0/python-ldap-test-49837/slapd.d -h 
ldap://127.0.0.1:49837/ 
ldapi://%2Fbuild%2Fdjango-auth-ldap-3.0.0%2Fpython-ldap-test-49837%2Fldapi -d 0
|>>> 

and django-auth-ldap's tests pass:

|I: pybuild base:239: PYTHONPATH=. python3.9 /usr/bin/django-admin test 
--settings tests.settings
|Creating test database for alias 'default'...
|System check identified no issues (0 silenced).
|starting slapd: %r /usr/sbin/slapd -f 
/build/django-auth-ldap-3.0.0/python-ldap-test-33057/slapd.conf -F 
/build/django-auth-ldap-3.0.0/python-ldap-test-33057/slapd.d -h 
ldap://127.0.0.1:33057/ 
ldapi://%2Fbuild%2Fdjango-auth-ldap-3.0.0%2Fpython-ldap-test-33057%2Fldapi -d 0
|
|--
|Ran 88 tests in 3.494s
|
|OK


Michael
diff --git a/Lib/slapdtest/_slapdtest.py b/Lib/slapdtest/_slapdtest.py
index afd5304..a7a5c63 100644
--- a/Lib/slapdtest/_slapdtest.py
+++ b/Lib/slapdtest/_slapdtest.py
@@ -190,6 +190,7 @@ class SlapdObject(object):
 local_host = LOCALHOST
 testrunsubdirs = (
 'schema',
+'slapd.d',
   

Bug#1010071: wireguard-tools: the wg tool outputs color on monochrome terminals

2022-04-24 Thread Axel Scheepers
Hi again,

This patch avoids out of bounds access.

--- terminal.c.orig 2022-04-24 13:57:34.231668500 +0200
+++ terminal.c  2022-04-24 14:34:35.798847083 +0200
@@ -24,8 +24,10 @@
mode = true;
else if (var && !strcmp(var, "never"))
mode = false;
-   else
-   mode = isatty(fileno(stdout));
+   else {
+   var = getenv("TERM");
+   mode = var && isatty(fileno(stdout)) && strstr(var, "color");
+   }
return mode;
 }

Kind regards,
Axel
--- terminal.c.orig	2022-04-24 13:57:34.231668500 +0200
+++ terminal.c	2022-04-24 14:34:35.798847083 +0200
@@ -24,8 +24,10 @@
 		mode = true;
 	else if (var && !strcmp(var, "never"))
 		mode = false;
-	else
-		mode = isatty(fileno(stdout));
+	else {
+		var = getenv("TERM");
+		mode = var && isatty(fileno(stdout)) && strstr(var, "color");
+	}
 	return mode;
 }
 


Bug#1008832: freeradius: diff for NMU version 3.0.25+dfsg-1.1

2022-04-24 Thread Andreas Metzler
On 2022-04-23 Andreas Metzler  wrote:
> Control: tags 1008832 + pending

> Dear maintainer,

> I've prepared an NMU for freeradius (versioned as 3.0.25+dfsg-1.1) and
> uploaded it to DELAYED/5. Please feel free to tell me if I
> should delay it longer.

> Kind regards
> Andreas

Hello,

this would be the alternative version to make dh_autoreconf regenerate
all configure scripts.

I do not think can be polished more, the codebase currently does not
have a (working) way of regenerating the scripts. aclocal is kind of
necessary but cannot be used without modifying the code.

cu Andreas
>From 5ca6ad8c6c9d5fb17d034fe11a8dd9b747ab4eba Mon Sep 17 00:00:00 2001
From: Andreas Metzler 
Date: Sun, 24 Apr 2022 14:19:33 +0200
Subject: [PATCH] regenerate all configure scripts

---
 debian/autoreconfme | 29 +
 debian/rules|  4 
 2 files changed, 33 insertions(+)
 create mode 100755 debian/autoreconfme

diff --git a/debian/autoreconfme b/debian/autoreconfme
new file mode 100755
index 000..3aedfea
--- /dev/null
+++ b/debian/autoreconfme
@@ -0,0 +1,29 @@
+#!/bin/sh
+
+set -e
+
+base=`pwd`
+
+mkdir build-aclocal
+cd build-aclocal
+find "${base}" -mindepth 2 -path "${base}/build-aclocal" -prune \
+	-o \( -name configure.ac -printf '%h\n' \) |\
+	while read i ; do
+		cd ${base}/build-aclocal
+		echo processing $i
+		test -e ${i}/m4 || mkdir ${i}/m4
+		grep -v '^AC_INCLUDE(aclocal.m4)' \
+			${base}/acinclude.m4 > ${i}/m4/acinclude.m4
+		grep -v '^[[:space:]]*m4_include(' $i/configure.ac \
+			> configure.ac
+		aclocal --force --install -I $i/m4\
+			--output=$i/aclocal.m4
+		rm -f ${base}/build-aclocal/configure.ac
+		cd $i
+		autoconf --force --include=m4
+	done
+
+cd ${base}
+aclocal --force --install -I m4
+autoconf --force --include=m4
+rm -rf build-aclocal
diff --git a/debian/rules b/debian/rules
index f1d6ddb..0ab5d22 100755
--- a/debian/rules
+++ b/debian/rules
@@ -9,6 +9,10 @@ ifneq (,$(filter parallel=%,$(DEB_BUILD_OPTIONS)))
MAKEFLAGS += -j$(NUMJOBS)
 endif
 
+override_dh_autoreconf:
+	chmod +x debian/autoreconfme
+	dh_autoreconf --verbose debian/autoreconfme
+
 override_dh_auto_clean:
 	[ ! -f Make.inc ] || dh_auto_clean
 
-- 
2.35.1



Bug#1010098: xorriso: please allow -cut-out directly from block devices

2022-04-24 Thread Thomas Schmitt
Hi,

Ivan Shmakov wrote:
> I’m filing this bug against versions from oldstable and
> stable, for that’s so far the only Debian packages’ versions
> I’ve tested for this issue.

As it is about an upstream wish:
The newest easily compilable and then usable version would be
  http://www.gnu.org/software/xorriso/xorriso-1.5.5.tar.gz
It can be compiled without much dependencies and then used without
installation. See "Compilation, First Glimpse, Installation" in
  https://www.gnu.org/software/xorriso/README_xorriso_devel


Said that, and now with my upstream hat on, i expect no difference to
versions 1.5.0 or 1.5.4 in respect to command -cut_out.
So there is no need to get xorriso-1.5.5.tar.gz unless you want to
test a patch proposed by me.

I downloaded your 114.xorriso-1.diff and will study it for the goal of
enabling -cut_out for more file types.
I already see that it makes changes about fsrc_open(), which is a central
facility of libisofs. This means it will last several days of study and
pondering until i would be convinced of any change.

Also i need to check whether your diff interferes with the ability to backup
a block device file as itself and not as bearer of its content:

  rm test.iso
  xorriso -outdev test.iso -map /dev/sr0 /sr0 -commit -lsdl /sr0 --

should produce even with a loaded BD_RE medium of 23 GiB a small ISO and
report a block device file in it

  brw-rw1 024   11,0 Apr 24 14:15 '/sr0'

So i guess that other changes are necessary to keep this capability while
enabling -cut_out for block devices.

I will report my findings.


Have a nice day :)

Thomas



Bug#1010102: debian-edu-config: Please replace mime-support with media-types or mailcap in Depends

2022-04-24 Thread Charles Plessy
Package: debian-edu-config
Severity: normal
X-Debbugs-Cc: ple...@debian.org

Dear Debian Edu maintainers,

In the previous release cycle, I have split the `mime-support` package
into two: `media-types` supplies /etc/mime.types and `mailcap` supplies
the mailcap system.  `mime-support` is now a transitional package that
I would like to remove from Debian.

May I ask you to replace mime-support with media-types of mailcap in
debian-edu-config's Depends ?

Have a nice day,

Charles

--
Charles Plessy Nagahama, Yomitan, Okinawa, Japan
Tooting from work,   https://mastodon.technology/@charles_plessy
Tooting from home, https://framapiaf.org/@charles_plessy



Bug#1010101: mit-scheme: Please replace mime-support with media-types in Recommends

2022-04-24 Thread Charles Plessy
Package: mit-scheme
Severity: normal
X-Debbugs-Cc: ple...@debian.org

Dear Barak,

In the previous release cycle, I have split the `mime-support` package
into two: `media-types` supplies /etc/mime.types and `mailcap` supplies
the mailcap system.  `mime-support` is now a transitional package that
I would like to remove from Debian.

May I ask you to replace mime-support with media-types in mit-scheme's
Recommmends ?

Have a nice day,

Charles

--
Charles Plessy Nagahama, Yomitan, Okinawa, Japan
Tooting from work,   https://mastodon.technology/@charles_plessy
Tooting from home, https://framapiaf.org/@charles_plessy



Bug#1010100: samba: ldb-tools versioning does not work for binNMUs

2022-04-24 Thread Adrian Bunk
Source: samba
Version: 2:4.16.0+dfsg-6
Severity: serious
Tags: ftbfs

bunk@coccia:~$ cat 
/srv/ftp-master.debian.org/queue/reject/samba_4.16.0+dfsg-6+b1_amd64-buildd.changes.reason

Version check failed:
Your upload included the binary package ldb-tools, version 
2:2.5.0+smb-6+b1+samba4.16.0+dfsg, for amd64,
however testing already has version 2:2.5.0+smb-6+samba4.16.0+dfsg.
Uploads to unstable must have a higher version than present in 
testing.bunk@coccia:~$



Bug#1010071: patch

2022-04-24 Thread Axel Scheepers
Hi,

Complaining doesn't help. I've created the following patch which fixes
the issue.

--- terminal.c.orig 2022-04-24 13:57:34.231668500 +0200
+++ terminal.c  2022-04-24 13:57:38.519643229 +0200
@@ -24,8 +24,11 @@
mode = true;
else if (var && !strcmp(var, "never"))
mode = false;
-   else
-   mode = isatty(fileno(stdout));
+   else {
+   var = getenv("TERM");
+   mode = var && isatty(fileno(stdout)) &&
+   strcmp(var + strlen(var) - 5, "color") == 0;
+   }
return mode;
 }

It's also attached as a patch file.

Kind regards,
Axel
--- terminal.c.orig	2022-04-24 13:57:34.231668500 +0200
+++ terminal.c	2022-04-24 13:57:38.519643229 +0200
@@ -24,8 +24,11 @@
 		mode = true;
 	else if (var && !strcmp(var, "never"))
 		mode = false;
-	else
-		mode = isatty(fileno(stdout));
+	else {
+		var = getenv("TERM");
+		mode = var && isatty(fileno(stdout)) &&
+		strcmp(var + strlen(var) - 5, "color") == 0;
+	}
 	return mode;
 }
 


Bug#1010041:

2022-04-24 Thread Zawtunoozawm M
mzawtunooza...@gmail.com


Bug#989343: ifupdown: Journal warning if there are no files in /etc/network/interfaces.d/*

2022-04-24 Thread yg2709
Package: ifupdown
Followup-For: Bug #989343
X-Debbugs-Cc: yg2...@hotmail.com

Dear Maintainer,

No warnings with the latest version 0.8.37 and no files in 
/etc/network/interfaces.d/:

 NetworkManager[829]:   [1650793569.4283] monitoring ifupdown state file 
'/run/network/ifstate'.
 NetworkManager[829]:   [1650793573.6997] settings: Loaded settings 
plugin: ifupdown 
("/usr/lib/x86_64-linux-gnu/NetworkManager/1.36.4/libnm-settings-plugin-ifupdown.so")
 NetworkManager[829]:   [1650793573.6998] ifupdown: management mode: 
unmanaged
 NetworkManager[829]:   [1650793573.6998] ifupdown:   
interface-parser: parsing file /etc/network/interfaces
 NetworkManager[829]:   [1650793573.6998] ifupdown:   
interface-parser: source line includes interfaces file(s) 
/etc/network/interfaces.d/*
 NetworkManager[829]:   [1650793573.6999] ifupdown: interfaces file 
/etc/network/interfaces.d/* doesn't exist
 NetworkManager[829]:   [1650793573.6999] ifupdown:   
interface-parser: finished parsing file /etc/network/interfaces

I think it could be marked as resolved.

Thank you very much.


-- Package-specific info:
--- /etc/network/interfaces:
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback

--- /etc/network/interfaces.d/*:
cat: '/etc/network/interfaces.d/*': No such file or directory

--- up and down scripts installed:
/etc/network/if-down.d:
total 4
-rwxr-xr-x 1 root root 1677 2019-03-30 15:32:49 clamav-freshclam-ifupdown
lrwxrwxrwx 1 root root   32 2022-04-09 09:28:35 wpasupplicant -> 
../../wpa_supplicant/ifupdown.sh

/etc/network/if-post-down.d:
total 0
lrwxrwxrwx 1 root root 28 2018-06-17 11:28:32 macchanger -> 
../../macchanger/ifupdown.sh
lrwxrwxrwx 1 root root 32 2022-04-09 09:28:35 wpasupplicant -> 
../../wpa_supplicant/ifupdown.sh

/etc/network/if-pre-up.d:
total 4
-rwxr-xr-x 1 root root 344 2016-06-30 16:53:02 ethtool
lrwxrwxrwx 1 root root  28 2018-06-17 11:28:32 macchanger -> 
../../macchanger/ifupdown.sh
lrwxrwxrwx 1 root root  32 2022-04-09 09:28:35 wpasupplicant -> 
../../wpa_supplicant/ifupdown.sh

/etc/network/if-up.d:
total 8
-rwxr-xr-x 1 root root 1677 2019-03-30 15:32:49 clamav-freshclam-ifupdown
-rwxr-xr-x 1 root root 1685 2016-06-30 16:53:02 ethtool
lrwxrwxrwx 1 root root   32 2022-04-09 09:28:35 wpasupplicant -> 
../../wpa_supplicant/ifupdown.sh


-- System Information:
Debian Release: bookworm/sid
Architecture: amd64 (x86_64)

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

Versions of packages ifupdown depends on:
ii  adduser   3.121
ii  iproute2  5.17.0-2
ii  libc6 2.33-7
ii  lsb-base  11.1.0

Versions of packages ifupdown recommends:
ii  isc-dhcp-client [dhcp-client]  4.4.2-P1-1+b1

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

-- debconf-show failed



Bug#848708: atop: cronjob to rotate file should be smarter

2022-04-24 Thread Marc Haber
Control: tags -1 upstream moreinfo
thanks

Hi,

On Wed, Jan 18, 2017 at 08:10:29PM +0100, Marc Haber wrote:
> tags #848708 upstream
> forwarded #848708 atoptool.nl
> thanks
> 
> I have forwarded this upstream.

in the mean time, atop has migrated to using a systemd timer, and
upstream commented recently:

| I guess this issue is already solved by earlier modifications, using a
| systems timer instead of cron.  The atop-rotate.timer takes care that
| atop-rotate.service is started at midnight (OnCalendar=daily) for
| systems that run 24/7. The atop-rotate.service restarts the
| atop.service, terminating the current atop running in the background and
| starting a new atop creating a new daily file with the actual date.  For
| system that are not running 24/7 atop.service is activated during boot.
| Also in that case atop creates a new daily file with the actual date.

Additionally, atop has become smarter with opening its log file.

Can you please check whether current atop addresses your issue, and
report back here or to https://github.com/Atoptool/atop/issues/12

I will close this bug report by the end of July 2022 if you don't say
that the issue that bothers you is still present.

Greetings
Marc



Bug#1010099: librust-backtrace-dev: fails to build

2022-04-24 Thread Jonas Smedegaard
Package: librust-backtrace-dev
Version: 0.3.44-6
Severity: important

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

In my attempt to use system-packaged crates when packaging safe-network,
I experience failure to compile crate backtrace:

   Compiling backtrace v0.3.44
 Running `rustc --crate-name backtrace --edition=2018 
/build/safe-network-0.58.13+20220423/debian/cargo_registry/backtrace-0.3.44/src/lib.rs
 --error-format=json --json=diagnostic-rendered-ansi,artifacts --crate-type lib 
--emit=dep-info,metadata,link -C opt-level=3 -C embed-bitcode=no --cfg 
'feature="addr2line"' --cfg 'feature="backtrace-sys"' --cfg 'feature="dbghelp"' 
--cfg 'feature="default"' --cfg 'feature="dladdr"' --cfg 'feature="findshlibs"' 
--cfg 'feature="gimli-symbolize"' --cfg 'feature="goblin"' --cfg 
'feature="libbacktrace"' --cfg 'feature="libunwind"' --cfg 'feature="memmap"' 
--cfg 'feature="std"' -C metadata=cdcc589c8fe5746c -C 
extra-filename=-cdcc589c8fe5746c --out-dir 
/build/safe-network-0.58.13+20220423/target/release/deps -L 
dependency=/build/safe-network-0.58.13+20220423/target/release/deps --extern 
addr2line=/build/safe-network-0.58.13+20220423/target/release/deps/libaddr2line-693c26ec6a4962ad.rmeta
 --extern 
backtrace_sys=/build/safe-network-0.58.13+20220423/target/release/deps/libbacktrace_sys-870f3d633c7004b8.rmeta
 --extern 
cfg_if=/build/safe-network-0.58.13+20220423/target/release/deps/libcfg_if-80fc42613a00e3ac.rmeta
 --extern 
findshlibs=/build/safe-network-0.58.13+20220423/target/release/deps/libfindshlibs-d117b27769824c61.rmeta
 --extern 
goblin=/build/safe-network-0.58.13+20220423/target/release/deps/libgoblin-ec7e315f6a834e77.rmeta
 --extern 
libc=/build/safe-network-0.58.13+20220423/target/release/deps/liblibc-fd75fe5a643abc43.rmeta
 --extern 
memmap=/build/safe-network-0.58.13+20220423/target/release/deps/libmemmap-5569dbec7f432de2.rmeta
 --extern 
rustc_demangle=/build/safe-network-0.58.13+20220423/target/release/deps/librustc_demangle-8f3c6d95b01930de.rmeta
 --cap-lints allow -C debuginfo=2 --cap-lints warn -C 
linker=x86_64-linux-gnu-gcc -C link-arg=-Wl,-z,relro --remap-path-prefix 
/build/safe-network-0.58.13+20220423=/usr/share/cargo/registry/safe-network-0.58.13+20220423
 -L native=/usr/lib/gcc/x86_64-linux-gnu/11/`
error[E0107]: this struct takes 0 lifetime arguments but 1 lifetime argument 
was supplied
   --> 
/usr/share/cargo/registry/safe-network-0.58.13+20220423/debian/cargo_registry/backtrace-0.3.44/src/symbolize/gimli.rs:605:37
|
605 | location: Option>,
|  help: remove these 
generics
| |
| expected 0 lifetime arguments

For more information about this error, try `rustc --explain E0107`.
error: could not compile `backtrace` due to previous error

Raising severity as this seems a general issue with the package.


 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmJlNJEACgkQLHwxRsGg
ASHIGw/8D5Yx11Jb0d6P5nn5Kf8H4TEYvbya/0V3c23qKX3pdYllEv+sv58OQGzg
j31QduGNR+it4tlN5zkRVFOHg2mk9OlrgKEBE3Hvu9NjMInJ1fkzAOQN9UFpEsl+
D69mkB8KJD7iqaN0kvJM0cWzHcF7EXuw/TUJWnYRG4BcvSkgL9lNrw4tgZCytlOo
DL+FI+YgUZ9bvwtrSZxeRzRpVYN92r6JD1tVAEOHuaGm1281GKJPqQO4DEeZgb6Y
ws0ixKm3UN9a1sCV4p7q7Bc/LU9INQJxo2B3okHceGIjXX3c9wH5GQIpzLHzDkgz
ilWkWLiEjdGODy1f7Tx5W0m2h9Neopwv+m4qSou6H0Q6ez0RbZeYpa5KrHdpyzfA
lo7AjIQte1nU7OesVda8JftDACwumojcDZZcQHnTCXhK+YFz5l8O961Tt/WdN39w
HnecsKqFsUSmbgb7vvGFYmxTX4XBklMeGqy9lVbjY9XhvYkt8Y6Gox/I8YuvTtAI
qRToyltr2tCJVDXrsDexpbgA6ZMZlVs7W4HuE6fNl/pXtpMHPSNm63xkaXuu0dW8
/fljdZGcCIQBCV5Y3vdeRKJkEzNTLlZjZV0s5Q2epXudkdf84dreOmOvgJ9+CSzc
O3jWyvCp9OU1MgLEKLojlRYotm7d3ZPjohKyyj4RrfYJ3aLj9jQ=
=bDoQ
-END PGP SIGNATURE-



Bug#1008355: django-auth-ldap: FTBFS: dh_auto_test: error: pybuild --test -i python{version} -p "3.10 3.9" --system=custom "--test-args=PYTHONPATH=. {interpreter} /usr/bin/django-admin test --settings

2022-04-24 Thread Michael Banck
reassign 1008355 python-ldap
retitle 1008355 python-ldap: _slaptest.py fails with "slapd exited before 
opening port", breaking other package builds
notfound 3.0.0-1
found 1008355 3.2.0-4
thanks

Hi,

On Sat, Mar 26, 2022 at 09:35:43PM +0100, Lucas Nussbaum wrote:
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
> 
> Relevant part (hopefully):
> > make[1]: Entering directory '/<>'
> > dh_auto_test -- --system=custom --test-args="PYTHONPATH=. {interpreter} 
> > /usr/bin/django-admin test --settings tests.settings"
> > I: pybuild pybuild:298: cp -r /<>/tests 
> > /<>/.pybuild/cpython3_3.10_django-auth-ldap/build
> > I: pybuild base:237: PYTHONPATH=. python3.10 /usr/bin/django-admin test 
> > --settings tests.settings
> > Creating test database for alias 'default'...
> > System check identified no issues (0 silenced).
> > E
> > ==
> > ERROR: setUpClass (tests.tests.LDAPTest)
> > --
> > Traceback (most recent call last):
> >   File "/<>/tests/tests.py", line 140, in setUpClass
> > cls.server.start()
> >   File "/usr/lib/python3/dist-packages/slapdtest/_slapdtest.py", line 445, 
> > in start
> > self._start_slapd()
> >   File "/usr/lib/python3/dist-packages/slapdtest/_slapdtest.py", line 420, 
> > in _start_slapd
> > raise RuntimeError("slapd exited before opening port")
> > RuntimeError: slapd exited before opening port
> > 
> > --
> > Ran 0 tests in 1.517s

This error comes from python3-ldap's slaptest:

|$  python3
|Python 3.10.4 (main, Apr  2 2022, 09:04:19) [GCC 11.2.0] on linux
|Type "help", "copyright", "credits" or "license" for more information.
|>>> import slapdtest
|>>> server = slapdtest.SlapdObject()
|>>> server.start()
|Traceback (most recent call last):
|  File "", line 1, in 
|  File "/usr/lib/python3/dist-packages/slapdtest/_slapdtest.py", line 445, in 
start
|self._start_slapd()
|  File "/usr/lib/python3/dist-packages/slapdtest/_slapdtest.py", line 420, in 
_start_slapd
|raise RuntimeError("slapd exited before opening port")
|RuntimeError: slapd exited before opening port
|>>> 

Not sure what the actual problem is, but one problem is that
python3-ldap is not exercising the upstream test suite; if I install
slapd and ldap-utils and run "pybuild --test" in python-ldap-3.2.0's
source directory, I also end up with erorrs like:

|==
|ERROR: setUpClass (Tests.t_ldap_sasl.TestSasl)
|--
|Traceback (most recent call last):
|  File "/build/python-ldap-3.2.0/Tests/t_ldap_sasl.py", line 50, in setUpClass
|super(TestSasl, cls).setUpClass()
|  File "/build/python-ldap-3.2.0/Lib/slapdtest/_slapdtest.py", line 594, in 
setUpClass
|cls.server.start()
|  File "/build/python-ldap-3.2.0/Lib/slapdtest/_slapdtest.py", line 445, in 
start
|self._start_slapd()
|  File "/build/python-ldap-3.2.0/Lib/slapdtest/_slapdtest.py", line 420, in 
_start_slapd
|raise RuntimeError("slapd exited before opening port")
|RuntimeError: slapd exited before opening port
|
|--
|Ran 104 tests in 22.132s
|
|FAILED (errors=11, skipped=6, expected failures=3)
|Test failed: 
|error: Test failed: 
|E: pybuild pybuild:369: test: plugin distutils failed with: exit code=1: 
python3.10 setup.py test 



Michael



Bug#1008997: [OpenPrinting/ipp-usb] ipp-usb is not ready for this device (Issue #48)

2022-04-24 Thread alain

hi , Till Kampeter

my case is only with the 0.9.20-1 ipp-usb version for testing / sid  only .

the stable version i put instead works perfectly .

waiting for your advices and your debugging .

(if you want)

thanks ,

friendly ,

respectfully,

alain.



Le 24/04/2022 à 10:51, Till Kamppeter a écrit :


@BELLECalain  do all versions of 
ipp-usb not work with kernel 5.17? Or is it only the new 0.9.20 version?


Thanks, @tangyanli  USB printing (7/1/x) 
has currently 4 different protocols: x = 1 is mon-directional 
streaming, x = 2 is bi-directional streaming, x = 3 is IEEE-1284 
packaet format (AFAIK only used by HPLIP currently), x = 4 is 
IPP-over-USB.


IPP-over-USB devices (7/1/4) ALWAYS print and scan driverless. For 
printing this means at least one of AirPrint, IPP Everywhere, Mopria, 
or Wi-Fi Direct Print is supported (or at least IPP 2.0 plus 
understanding at least one page description language of PDF, Apple 
Raster/URF, PWG Raster, PCLm), for scanning this means to understand 
at least one of eSCL and WSD/WS Scan.


—
Reply to this email directly, view it on GitHub 
, 
or unsubscribe 
.
You are receiving this because you were mentioned.Message ID: 



Bug#1009726: [Pkg-samba-maint] broken build of samba_4.13.13+dfsg-1~deb11u3 on i386

2022-04-24 Thread Mathieu Parent
On Sat, Apr 23, 2022 at 9:55 AM Michael Tokarev  wrote:
>
> Hello!

Hello,

> Now since the prob is quite serious, maybe we can fix this some
> faster way?

Yes. A regression update thru -security would be good. But better to
wait for the -security team ack.

Again, thanks for bringing samba back in shape !

Cheers
-- 
Mathieu Parent



Bug#1010098: xorriso: please allow -cut-out directly from block devices

2022-04-24 Thread Ivan Shmakov
Package: xorriso
Version: 1.5.0-1
Severity: wishlist
Control: found -1 1.5.2-1

[Please do not Cc: me, for I’m “on the list,” so to say, and
I try to reserve my inbox for private communication only.
I’d have set up Mail-Followup-To:, but there doesn’t seem to
be a way to make it point to the report being filed.]

I’m filing this bug against versions from oldstable and
stable, for that’s so far the only Debian packages’ versions
I’ve tested for this issue.  Regardless, given that the
behavior is the same for a recent Git revision, and that
there doesn’t seem to be any relevant Debian-specific
patches under [1], it stands to reason that the requested
feature is not available in Debian testing and Sid, either.

[1] http://sources.debian.org/src/libisoburn/1.5.4-2/debian/patches/

It would be handy to be able to use xorriso(1) to backup
(portions) of block devices to optical media; yet it doesn’t
seem to be supported.  E. g., on Buster:

bash$ xorriso -dev stdio:/tmp/cd"$RANDOM".image -follow link \
  -cut-out /dev/vgjubca-bk-i/lvepeci-x626512db 37M 13M lvxxx_37m+13m \
  -find / -exec lsdl -- -commit 
xorriso 1.5.0 : RockRidge filesystem manipulator, libburnia project.

Drive current: -dev 'stdio:/tmp/cd4973.image'
Media current: stdio file, overwriteable
Media status : is blank
Media summary: 0 sessions, 0 data blocks, 0 data,  XXXm free
xorriso : FAILURE : -cut_out: Unsupported file type (block_device) with 
'/dev/vgjubca-bk-i/lvepeci-x626512db' : No such file or directory
xorriso : aborting : -abort_on 'FAILURE' encountered 'FAILURE'
bash$ 

On Bullseye:

bash$ xorriso -dev stdio:/tmp/cd"$RANDOM".image -follow link \
  -cut-out /dev/vgjubca-bk-i/lvepeci-x626512db 37M 13M lvxxx_37m+13m \
  -find / -exec lsdl -- -commit 
xorriso 1.5.2 : RockRidge filesystem manipulator, libburnia project.

Drive current: -dev 'stdio:/tmp/cd1415.image'
Media current: stdio file, overwriteable
Media status : is blank
Media summary: 0 sessions, 0 data blocks, 0 data,  XXXm free
xorriso : FAILURE : -cut_out: Unsupported file type (block_device) with 
'/dev/vgjubca-bk-i/lvepeci-x626512db' : No such file or directory
xorriso : aborting : -abort_on 'FAILURE' encountered 'FAILURE'
bash$ 

The problem is due to /both/ libisoburn (to a lesser degree)
and libisofs relying on struct stat .st_size field (and the
respective S_ISREG check.)

I’ve made a very crude patch (MIMEd) that replaces the
st_size checks for non-regular files with checks against the
size reported by lseek (, 0, SEEK_END), if available; and in
some cases forgoes the check for non-regular files altogether.

Consider, e. g.:

bash$ xorriso -dev stdio:/tmp/cd"$RANDOM".image -follow link \
  -cut-out /dev/vgjubca-bk-i/lvepeci-x626512db 37M 13M lvxxx_37m+13m 
-find / -exec lsdl -- -commit 
xorriso 1.5.5 : RockRidge filesystem manipulator, libburnia project.

Drive current: -dev 'stdio:/tmp/cd14597.image'
Media current: stdio file, overwriteable
Media status : is blank
Media summary: 0 sessions, 0 data blocks, 0 data,  XXXm free
drwxr-xr-x1 00   0 Apr 24 10:16 '/'
-rw-rw1 0613631488 Apr 10 10:58 '/lvxxx_37m+13m'
xorriso : UPDATE : Writing:   3985s   58.2%   fifo   0%  buf  50%
ISO image produced: 6679 sectors
Written to medium : 6848 sectors at LBA 32
Writing to 'stdio:/tmp/cd14597.image' completed successfully.

xorriso : NOTE : Re-assessing -outdev 'stdio:/tmp/cd14597.image'
xorriso : NOTE : Loading ISO image tree from LBA 0
xorriso : UPDATE :   1 nodes read in 1 seconds
Drive current: -dev 'stdio:/tmp/cd14597.image'
Media current: stdio file, overwriteable
Media status : is written , is appendable
Media summary: 1 session, 6679 data blocks, 13.0m data,  XXXm free
Volume id: 'ISOIMAGE'
bash$ 

Checking if the intended data was indeed written to the image
with icat(1):

bash$ /usr/bin/time -- cmp -n 13M -i 37M:0 -- \
  /dev/vgjubca-bk-i/lvepeci-x626512db \
  <(icat /tmp/cd14597.image 1) 
0.01user 0.04system 0:00.18elapsed 29%CPU (0avgtext+0avgdata 1088maxresident)k
27112inputs+0outputs (0major+95minor)pagefaults 0swaps
bash$ 

-- 
FSF associate member #7257  http://am-1.org/~ivan/
--- ./libisofs-da002915/libisofs/stream.c.~1~	2022-04-23 07:32:44 +
+++ ./libisofs-da002915/libisofs/stream.c	2022-04-24 08:39:06.352583604 +
@@ -34,11 +34,27 @@
 ino_t cut_out_serial_id = (ino_t)1;
 
 static
+off_t fsrc_lseek_end_off(IsoFileSource *src)
+{
+/** For non-regular files, we check seekability
+and obtain SEEK_END position to use as size */
+off_t end, old, reset;
+old = iso_file_source_lseek (src, 0, 1);
+if (old < 0) { return -1; }
+end = iso_file_source_lseek (src, 0, 2);
+if (end < 0) { return -1; }
+reset = 

Bug#1010097: monero: FTBFS on mipsel

2022-04-24 Thread Sebastian Ramacher
Source: monero
Version: 0.17.2.0+~0+20200826-1
Severity: serious
Tags: ftbfs sid bookworm
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: sramac...@debian.org

monero FTBFS on mipsel:

cd "/<>/obj-mipsel-linux-gnu/contrib/epee/src" && /usr/bin/c++ 
-DAUTO_INITIALIZE_EASYLOGGINGPP -DBLOCKCHAIN_DB=DB_LMDB 
-DDEFAULT_DB_TYPE=\"lmdb\" -DHAVE_EXPLICIT_BZERO -DHAVE_HIDAPI -DHAVE_READLINE 
-DHAVE_STRPTIME -DPER_BLOCK_CHECKPOINT 
-I"/<>/external/rapidjson/include" 
-I"/<>/external/easylogging++" -I"/<>/src" 
-I"/<>/contrib/epee/include" -I"/<>/external" 
-I"/<>/external/supercop/include" 
-I"/<>/obj-mipsel-linux-gnu/generated_include" 
-I"/<>/obj-mipsel-linux-gnu/translations" 
-I"/<>/external/db_drivers/liblmdb" -I/usr/include/hidapi -g -O2 
-ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -g1 -Wdate-time -D_FORTIFY_SOURCE=2 -pthread -DNO_AES  
-fno-strict-aliasing -std=c++11 -D_GNU_SOURCE   -Wall -Wextra -Wpointer-arith 
-Wundef -Wvla -Wwrite-strings -Wno-error=extra 
-Wno-error=deprecated-declarations -Wno-unused-parameter -Wno-unused-variable 
-Wno-error=unused-variable -Wno-error=undef -Wno-error=uninitialized 
-Wlogical-op -Wno-error=maybe-uninitialized -Wno-error=cpp -Wno-reorder 
-Wno-missing-field-initializers  -fPIC  -Wformat -Wformat-security 
-fstack-protector -fstack-protector-strong -fstack-clash-protection 
-fno-strict-aliasing -ftemplate-depth=900 -MD -MT 
contrib/epee/src/CMakeFiles/epee.dir/connection_basic.cpp.o -MF 
CMakeFiles/epee.dir/connection_basic.cpp.o.d -o 
CMakeFiles/epee.dir/connection_basic.cpp.o -c 
"/<>/contrib/epee/src/connection_basic.cpp"
[ 42%] Building CXX object 
contrib/epee/src/CMakeFiles/epee.dir/network_throttle.cpp.o
cd "/<>/obj-mipsel-linux-gnu/contrib/epee/src" && /usr/bin/c++ 
-DAUTO_INITIALIZE_EASYLOGGINGPP -DBLOCKCHAIN_DB=DB_LMDB 
-DDEFAULT_DB_TYPE=\"lmdb\" -DHAVE_EXPLICIT_BZERO -DHAVE_HIDAPI -DHAVE_READLINE 
-DHAVE_STRPTIME -DPER_BLOCK_CHECKPOINT 
-I"/<>/external/rapidjson/include" 
-I"/<>/external/easylogging++" -I"/<>/src" 
-I"/<>/contrib/epee/include" -I"/<>/external" 
-I"/<>/external/supercop/include" 
-I"/<>/obj-mipsel-linux-gnu/generated_include" 
-I"/<>/obj-mipsel-linux-gnu/translations" 
-I"/<>/external/db_drivers/liblmdb" -I/usr/include/hidapi -g -O2 
-ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -g1 -Wdate-time -D_FORTIFY_SOURCE=2 -pthread -DNO_AES  
-fno-strict-aliasing -std=c++11 -D_GNU_SOURCE   -Wall -Wextra -Wpointer-arith 
-Wundef -Wvla -Wwrite-strings -Wno-error=extra 
-Wno-error=deprecated-declarations -Wno-unused-parameter -Wno-unused-variable 
-Wno-error=unused-variable -Wno-error=undef -Wno-error=uninitialized 
-Wlogical-op -Wno-error=maybe-uninitialized -Wno-error=cpp -Wno-reorder 
-Wno-missing-field-initializers  -fPIC  -Wformat -Wformat-security 
-fstack-protector -fstack-protector-strong -fstack-clash-protection 
-fno-strict-aliasing -ftemplate-depth=900 -MD -MT 
contrib/epee/src/CMakeFiles/epee.dir/network_throttle.cpp.o -MF 
CMakeFiles/epee.dir/network_throttle.cpp.o.d -o 
CMakeFiles/epee.dir/network_throttle.cpp.o -c 
"/<>/contrib/epee/src/network_throttle.cpp"

cc1plus: out of memory allocating 33554372 bytes after a total of 57638912 bytes
make[3]: *** [src/wallet/CMakeFiles/obj_wallet.dir/build.make:79: 
src/wallet/CMakeFiles/obj_wallet.dir/wallet2.cpp.o] Error 1
make[3]: *** Waiting for unfinished jobs


See
https://buildd.debian.org/status/fetch.php?pkg=monero=mipsel=0.17.2.0%2B%7E0%2B20200826-1%2Bb1=1650785169=0

Cheers
-- 
Sebastian Ramacher



Bug#1010096: macaulay2: FTBFS on ppc64el

2022-04-24 Thread Sebastian Ramacher
Source: macaulay2
Version: 1.19.1+ds-6
Severity: serious
Tags: ftbfs sid bookworm
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: sramac...@debian.org

macaulay2 FTBFS on ppc64el:

 ulimit -c unlimited; ulimit -t 700; ulimit -m 85; ulimit -s 8192; ulimit 
-n 512;  cd /tmp/M2-2532003-0/31-rundir/; GC_MAXIMUM_HEAP_SIZE=400M 
"/<>/M2/usr-dist/powerpc64le-Linux-Debian-buildd-unstable/bin/M2-binary"
 -q --int --no-randomize --no-readline --silent --stop --print-width 77 -e 
'needsPackage("AssociativeAlgebras",Reload=>true,FileName=>"/<>/M2/Macaulay2/packages/AssociativeAlgebras.m2")'
 <"/tmp/M2-2532003-0/30.m2" >>"/tmp/M2-2532003-0/30.tmp" 2>&1
/tmp/M2-2532003-0/30.tmp:0:1: (output file) error: Macaulay2 killed by signal 9
/tmp/M2-2532003-0/30.m2:0:1: (input file)
M2: *** Error 9
 -- 6.50792 seconds elapsed
 -- running   check(26, "AssociativeAlgebras")   -- 
6.69457 seconds elapsed
 -- running   check(27, "AssociativeAlgebras")   -- 
7.99133 seconds elapsed
 -- running   check(28, "AssociativeAlgebras")   -- 
6.99254 seconds elapsed
 -- capturing check(29, "AssociativeAlgebras")   -- 
8.69268 seconds elapsed
 -- skipping  check(30, "AssociativeAlgebras")   -- 
0.000117095 seconds elapsed
 -- running   check(31, "AssociativeAlgebras")   -- 
7.8834 seconds elapsed
 -- running   check(32, "AssociativeAlgebras")   -- 
8.43175 seconds elapsed
 -- running   check(33, "AssociativeAlgebras")   -- 
6.76101 seconds elapsed
AssociativeAlgebras/tests.m2:729:1-752:1: error:
 -- -- -*- M2-comint -*- hash: 1928805808
 -- Killed
 -- 
../m2/debugging.m2:23:6:(1):[9]: error: test(s) #25 of package 
AssociativeAlgebras failed.
../m2/testing.m2:135:9:(1):[8]: --back trace--
../m2/methods.m2:154:80:(1):[7]: --back trace--
../m2/option.m2:17:8:(1):[6]: --back trace--
../m2/testing.m2:108:33:(1):[5]: --back trace--
../m2/methods.m2:154:80:(1):[4]: --back trace--
../m2/option.m2:17:8:(1):[3]: --back trace--
currentString:1:82:(3):[2]: --back trace--
Macaulay2/Core/startup.m2.in:561:33:(0):[1]: --back trace--
Macaulay2/Core/startup.m2.in:661:6:(0): --back trace--
make[4]: *** [Makefile:41: check-AssociativeAlgebras] Error 1

See
https://buildd.debian.org/status/fetch.php?pkg=macaulay2=ppc64el=1.19.1%2Bds-6%2Bb2=1650754325=0

Cheers
-- 
Sebastian Ramacher



Bug#1010095: performous: FTBFS on ppc64el

2022-04-24 Thread Sebastian Ramacher
Source: performous
Version: 1.1+git20181118-5
Severity: serious
Tags: ftbfs sid bookworm
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: sramac...@debian.org

performous FTBFS on ppc64el:

cd /<>/obj-powerpc64le-linux-gnu && /usr/bin/cmake -E 
cmake_depends "Unix Makefiles" /<> /<>/docs/man 
/<>/obj-powerpc64le-linux-gnu 
/<>/obj-powerpc64le-linux-gnu/docs/man 
/<>/obj-powerpc64le-linux-gnu/docs/man/CMakeFiles/gh_fsb_decrypt.1.dir/DependInfo.cmake
 --color=
In file included from /usr/include/c++/11/bits/stl_algobase.h:63,
 from /usr/include/c++/11/memory:63,
 from 
/<>/ced/compact_enc_det/compact_enc_det.cc:24:
/usr/include/c++/11/ext/numeric_traits.h:222:38: error: ‘__ieee128’ was not 
declared in this scope; did you mean ‘__int128’?
  222 | struct __numeric_traits_floating<__ieee128>
  |  ^
  |  __int128
154 translated messages, 20 fuzzy translations, 138 untranslated messages.
/usr/include/c++/11/ext/numeric_traits.h:222:47: error: template argument 1 is 
invalid
  222 | struct __numeric_traits_floating<__ieee128>
  |   ^
make[3]: Leaving directory '/<>/obj-powerpc64le-linux-gnu'
/usr/include/c++/11/ext/numeric_traits.h:230:29: error: ‘__ieee128’ was not 
declared in this scope; did you mean ‘__int128’?
  230 | struct __numeric_traits<__ieee128>
  | ^
  | __int128
/usr/include/c++/11/ext/numeric_traits.h:230:38: error: template argument 1 is 
invalid
  230 | struct __numeric_traits<__ieee128>
  |  ^
make[3]: Leaving directory '/<>/obj-powerpc64le-linux-gnu'
make  -f docs/man/CMakeFiles/ss_chc_decode.1.dir/build.make 
docs/man/CMakeFiles/ss_chc_decode.1.dir/build
make[3]: Entering directory '/<>/obj-powerpc64le-linux-gnu'
/usr/include/c++/11/ext/numeric_traits.h:231:40: error: ‘__ieee128’ was not 
declared in this scope; did you mean ‘__int128’?
  231 | : public __numeric_traits_floating<__ieee128>
  |^
  |__int128
/usr/include/c++/11/ext/numeric_traits.h:231:49: error: template argument 1 is 
invalid
  231 | : public __numeric_traits_floating<__ieee128>
  | ^
make[3]: Leaving directory '/<>/obj-powerpc64le-linux-gnu'

See
https://buildd.debian.org/status/fetch.php?pkg=performous=ppc64el=1.1%2Bgit20181118-5%2Bb1=1650784603=0

Cheers
-- 
Sebastian Ramacher



Bug#1009913: dpkg: when the user reverts to the package maintainer's version of a conffile, the execute bit is not propagated

2022-04-24 Thread Vincent Lefevre
Hi Guillem,

On 2022-04-23 19:22:37 +0200, Guillem Jover wrote:
> On Wed, 2022-04-20 at 17:17:16 +0200, Vincent Lefevre wrote:
> > In an upgrade, the user may get a prompt like that and answer yes
> > to install the package maintainer's version of a conffile, thus
> > reverting all changes done he had done:
> > 
> > Configuration file '/etc/resolvconf/update.d/unbound'
> >  ==> Modified (by you or by a script) since installation.
> >  ==> Package distributor has shipped an updated version.
> >What would you like to do about it ?  Your options are:
> > Y or I  : install the package maintainer's version
> > N or O  : keep your currently-installed version
> >   D : show the differences between the versions
> >   Z : start a shell to examine the situation
> >  The default action is to keep your current version.
> > *** unbound (Y/I/N/O/D/Z) [default=N] ? Y
> > Installing new version of config file /etc/resolvconf/update.d/unbound ...
> > [...]
> > 
> > However, if the user had changed the execute permission, e.g. to
> > enable the script after modifying it, the execute permission is
> > not restored to the default one.
> > 
> > The execute permission is part of the file, thus should be propagated
> > like the contents.
> 
> Right, ideally yes.
> 
> > The current behavior is an issue since a script may be disabled
> > by default because it could be incorrect until the user has
> > adapted it for his own usage. And the message like
> > 
> >   Installing new version of config file /etc/resolvconf/update.d/unbound ...
> > 
> > (letting the user think that the conffile is reverted to the default,
> > without informing him that the execute bit is not copied) is
> > misleading.
> > 
> > An alternative solution would be a 5th option, splitting the
> > 
> > Y or I  : install the package maintainer's version
> > 
> > choice, when there is a difference for the execute permission.
> 
> There are currently three main problems that make substantial immediate
> improvements to this rather impractical. :/
> 
>   - There is no tracking (yet) of fsys metadata, so dpkg does not know
> what were the original old conffile perms, and thus cannot take
> them into account as part of a "modified" check, otherwise we would
> end up prompting unnecessarily when the perms are different between
> the installed old and stock new conffiles.

Tracking would be fine in some cases; however, note that in the
context of my bug report, this would be unnecessary: there is
already a change in the contents, i.e. dpkg already prompts.

The idea is: since the user wants to revert his changes on the
contents, then it also makes sense to revert his change on the
permissions too.

>   - The statoverrides are applied on unpack, so right now we even lose
> the minimal tracking we could have over the new conffile shipped in
> the .deb.
>   - The perms are unconditionally copied from the current to the new
> conffile, and given the current constraints, stopping doing that
> could have either small (perms) data loss consequences, or could
> have security implications (even for the install-new-conffile case,
> as a common way people resolve new changes might be to spawn a shell
> during the prompt and incorporate the old modifications into the new
> file).

Do you mean that when dpkg unpacks the package, it copies the perms
from the user's current conffile to the distributed version, and
they look if there is any difference? This is rather complicated
and is even a lie if the user chooses to keep his version (the
.dpkg-dist file would have the user's perms instead of the perms
from the package).

> Changing the current behavior, without fsys metadata tracking
> assistance, seems challenging, to say the least.

But no tracking is necessary: the context is that one gets the prompt
due to the changes in the contents; then it is the user's decision to
replace his current conffile by the distributed one, and this should
be done entirely, i.e. including the perms.

> I think right now what I could do, that I think is safe and meaningful
> would be to:
> 
>  - document that currently (but that would change) statoverrides for
>conffiles does not have a practical effect.
>  - show the permission differences during the prompt (current, new,
>whether there is any ineffective override in place).

If it can show a difference during the prompt, then the permissions
could be propagated. So I'm confused.

> Ideally in the future once we have fsys metadata tracking:
> 
>  - stop unconditionally copying the old perms into the new conffiles.
>  - take permissions into account as part of the "modified" check,
>and show and apply any meaningful permission change there, taking
>statoverrides into account.

While taking permissions into account as part of the "modified" check
would be fine, this is not what I'm asking here.

-- 
Vincent Lefèvre  - Web: 
100% 

Bug#1010094: liblttoolbox3 must be linked with libicu

2022-04-24 Thread Adrian Bunk
Package: liblttoolbox3-3.6-1
Severity: serious
Tags: ftbfs patch
Forwarded: https://github.com/apertium/lttoolbox/pull/141

https://buildd.debian.org/status/fetch.php?pkg=lttoolbox=amd64=3.6.1-2%2Bb2=1650723091=0

...
   dh_shlibdeps -a
dpkg-shlibdeps: warning: symbol u_strCaseCompare_71 used by 
debian/liblttoolbox3-3.6-1/usr/lib/x86_64-linux-gnu/liblttoolbox3-3.6.so.1.0.0 
found in none of the libraries
dpkg-shlibdeps: warning: symbol u_tolower_71 used by 
debian/liblttoolbox3-3.6-1/usr/lib/x86_64-linux-gnu/liblttoolbox3-3.6.so.1.0.0 
found in none of the libraries
dpkg-shlibdeps: warning: symbol u_isdigit_71 used by 
debian/liblttoolbox3-3.6-1/usr/lib/x86_64-linux-gnu/liblttoolbox3-3.6.so.1.0.0 
found in none of the libraries
dpkg-shlibdeps: warning: symbol u_errorName_71 used by 
debian/liblttoolbox3-3.6-1/usr/lib/x86_64-linux-gnu/liblttoolbox3-3.6.so.1.0.0 
found in none of the libraries
dpkg-shlibdeps: warning: symbol u_sscanf_71 used by 
debian/liblttoolbox3-3.6-1/usr/lib/x86_64-linux-gnu/liblttoolbox3-3.6.so.1.0.0 
found in none of the libraries
dpkg-shlibdeps: warning: symbol u_strHasMoreChar32Than_71 used by 
debian/liblttoolbox3-3.6-1/usr/lib/x86_64-linux-gnu/liblttoolbox3-3.6.so.1.0.0 
found in none of the libraries
dpkg-shlibdeps: warning: symbol u_fclose_71 used by 
debian/liblttoolbox3-3.6-1/usr/lib/x86_64-linux-gnu/liblttoolbox3-3.6.so.1.0.0 
found in none of the libraries
dpkg-shlibdeps: warning: symbol uloc_setDefault_71 used by 
debian/liblttoolbox3-3.6-1/usr/lib/x86_64-linux-gnu/liblttoolbox3-3.6.so.1.0.0 
found in none of the libraries
dpkg-shlibdeps: warning: symbol _ZN6icu_7122UCharCharacterIterator7hasNextEv 
used by 
debian/liblttoolbox3-3.6-1/usr/lib/x86_64-linux-gnu/liblttoolbox3-3.6.so.1.0.0 
found in none of the libraries
dpkg-shlibdeps: warning: symbol u_isspace_71 used by 
debian/liblttoolbox3-3.6-1/usr/lib/x86_64-linux-gnu/liblttoolbox3-3.6.so.1.0.0 
found in none of the libraries
dpkg-shlibdeps: warning: 20 other similar warnings have been skipped (use -v to 
see them all)
...


It works when all users also happen to link with (the right version of)
libicu, if they don't linking or running code using liblttoolbox3 fails like:

https://buildd.debian.org/status/fetch.php?pkg=apertium=ppc64=3.8.1-2%2Bb2=1650794468=0

...
/usr/bin/ld: 
/usr/lib/gcc/powerpc64-linux-gnu/11/../../../powerpc64-linux-gnu/liblttoolbox3.so:
 undefined reference to `u_isalnum_67'
/usr/bin/ld: 
/usr/lib/gcc/powerpc64-linux-gnu/11/../../../powerpc64-linux-gnu/liblttoolbox3.so:
 undefined reference to `u_strHasMoreChar32Than_67'
/usr/bin/ld: 
/usr/lib/gcc/powerpc64-linux-gnu/11/../../../powerpc64-linux-gnu/liblttoolbox3.so:
 undefined reference to `u_isspace_67'
/usr/bin/ld: 
/usr/lib/gcc/powerpc64-linux-gnu/11/../../../powerpc64-linux-gnu/liblttoolbox3.so:
 undefined reference to `u_feof_67'
/usr/bin/ld: 
/usr/lib/gcc/powerpc64-linux-gnu/11/../../../powerpc64-linux-gnu/liblttoolbox3.so:
 undefined reference to `u_finit_67'
/usr/bin/ld: 
/usr/lib/gcc/powerpc64-linux-gnu/11/../../../powerpc64-linux-gnu/liblttoolbox3.so:
 undefined reference to `u_toupper_67'
/usr/bin/ld: 
/usr/lib/gcc/powerpc64-linux-gnu/11/../../../powerpc64-linux-gnu/liblttoolbox3.so:
 undefined reference to 
`icu_67::UCharCharacterIterator::UCharCharacterIterator(icu_67::ConstChar16Ptr, 
int)'
/usr/bin/ld: 
/usr/lib/gcc/powerpc64-linux-gnu/11/../../../powerpc64-linux-gnu/liblttoolbox3.so:
 undefined reference to `u_errorName_67'
/usr/bin/ld: 
/usr/lib/gcc/powerpc64-linux-gnu/11/../../../powerpc64-linux-gnu/liblttoolbox3.so:
 undefined reference to `u_fopen_67'
/usr/bin/ld: 
/usr/lib/gcc/powerpc64-linux-gnu/11/../../../powerpc64-linux-gnu/liblttoolbox3.so:
 undefined reference to `u_sprintf_67'
/usr/bin/ld: 
/usr/lib/gcc/powerpc64-linux-gnu/11/../../../powerpc64-linux-gnu/liblttoolbox3.so:
 undefined reference to `icu_67::UCharCharacterIterator::hasNext()'
/usr/bin/ld: 
/usr/lib/gcc/powerpc64-linux-gnu/11/../../../powerpc64-linux-gnu/liblttoolbox3.so:
 undefined reference to `u_fflush_67'
/usr/bin/ld: 
/usr/lib/gcc/powerpc64-linux-gnu/11/../../../powerpc64-linux-gnu/liblttoolbox3.so:
 undefined reference to `icu_67::UCharCharacterIterator::next32PostInc()'
/usr/bin/ld: 
/usr/lib/gcc/powerpc64-linux-gnu/11/../../../powerpc64-linux-gnu/liblttoolbox3.so:
 undefined reference to `u_fgetc_67'
/usr/bin/ld: 
/usr/lib/gcc/powerpc64-linux-gnu/11/../../../powerpc64-linux-gnu/liblttoolbox3.so:
 undefined reference to `u_fputc_67'
/usr/bin/ld: 
/usr/lib/gcc/powerpc64-linux-gnu/11/../../../powerpc64-linux-gnu/liblttoolbox3.so:
 undefined reference to `u_snprintf_67'
/usr/bin/ld: 
/usr/lib/gcc/powerpc64-linux-gnu/11/../../../powerpc64-linux-gnu/liblttoolbox3.so:
 undefined reference to `u_isupper_67'
/usr/bin/ld: 
/usr/lib/gcc/powerpc64-linux-gnu/11/../../../powerpc64-linux-gnu/liblttoolbox3.so:
 undefined reference to `u_strToUpper_67'
/usr/bin/ld: 
/usr/lib/gcc/powerpc64-linux-gnu/11/../../../powerpc64-linux-gnu/liblttoolbox3.so:
 undefined 

Bug#1010093: node-postcss-loader: $requires webpack >= 5

2022-04-24 Thread Jérémy Lal
Package: node-postcss-loader
Version: 6.2.1+~cs7.0.11-2
Severity: normal

Hi,

from the changelog:

5.0.0 (2021-02-02)
warning BREAKING CHANGES
minimum supported webpack version is 5

Breaking change is:
https://github.com/webpack-contrib/postcss-loader/commit/1d4878171c9b94c9fea61b1b75340674e00be7a4

(webpack 5 is in experimental right now)

Jérémy

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

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


Bug#1004511: luajit breaks knot-resolver autopkgtest on ppc64el: Segmentation fault

2022-04-24 Thread Paul Gevers

Control: reassign -1 src:luajit 2.1.0~beta3+git20210112+dfsg-2
Control: retitle -1 luajit SEGFAULTs on ppc64el

On Sat, 29 Jan 2022 19:32:53 +0100 Paul Gevers  wrote:
With a recent upload of luajit the autopkgtest of knot-resolver fails in 
testing when that autopkgtest is run with the binary packages of luajit 
from unstable. It passes when run with only packages from testing. In 
tabular form:


knot-resolver has been removed from testing due to this bug report, but 
can't migrate back because a newer version fails to build on ppc64el. 
Also other reverse dependencies of luajit show SEGFAULT in their 
autopkgtest on ppc64el, so this seems a problem in luajit. Unfortunately 
(Release Team member opinion) luajit is a key package so can't be 
trivially removed. Can you (maintainer and ppc64el porters) please have 
a look?


Paul


OpenPGP_signature
Description: OpenPGP digital signature


Bug#1006736: python-pytest-asyncio breaks pytest-mock autopkgtest: nomatch: '* 1 passed in *'

2022-04-24 Thread Paul Gevers

Control: reassign -1 src:pytest-mock 3.6.1-1
Control: affects -1 src:python-pytest-asyncio

Hi,

On Thu, 3 Mar 2022 21:46:57 +0100 Paul Gevers  wrote:
With a recent upload of python-pytest-asyncio the autopkgtest of 
pytest-mock fails in testing when that autopkgtest is run with the 
binary packages of python-pytest-asyncio from unstable. It passes when 
run with only packages from testing. In tabular form:


As both python-pytest-asyncio and pytest-mock are key packages, this bug 
isn't fixing anything with autoremoval, so action is needed to resolve 
this. I had a brief look (tried to create a patch). At least the 
"nomatch" part looks like just upgrading pytest-mock to not be sensitive 
to a deprecation warning, hence reassigning.


The "nomatch" problem could easily be fixed (e.g. by taking the test 
related changes from upstream commit 
0b869db2e019c23421d74af719766d6e2fc79f6a) but by now pytest-mock is also 
picking up failures due to python3.10 being the default now in 
combination with the new python-pytest-asyncio. I wasn't (quickly) able 
to isolate a patch, but upstream pytest-mock has a newer release so 
maybe the newer release with the Python3.10+new-asyncio-support patch 
would solve the issue.


Paul


OpenPGP_signature
Description: OpenPGP digital signature


Bug#1009320: FW issue

2022-04-24 Thread Salvatore Bonaccorso
Hi,

On Sun, Apr 24, 2022 at 11:27:25AM +0200, Salvatore Bonaccorso wrote:
> Control: tags -1 + moreinfo
> 
> Hi,
> 
> On Wed, Apr 13, 2022 at 09:58:10PM +0200, mh wrote:
> > It seems 5.17.x has problems with the respective FW (no problems with
> > prior kernels)
> > 
> > dmesg output after trying to load list of broadcasters
> > *
> > [ 6801.250773] si2168 2-0064: downloading firmware from file
> > 'dvb-demod-si2168-b40-01.fw' [ 6801.634181] si2168 2-0064: firmware
> > version: B 4.0.11 [ 6801.643054] si2157 5-0060: found a 'Silicon Labs
> > Si2157-A30 ROM 0x50' [ 6801.643117] si2157 5-0060: Can't continue
> > without a firmware.
> > **
> 
> Can you please verify it again with the current version in unstable
> (5.17.3-1).

Actually, can you please try the attached patch?

See
https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html#s4.2.2
for instructions.

Regards,
Salvatore
>From 8c0dbed07b388e7d97cecc184099caf80067a7bc Mon Sep 17 00:00:00 2001
From: Piotr Chmura 
Date: Thu, 31 Mar 2022 17:55:50 +0200
Subject: [PATCH] media: si2157: unknown chip version Si2147-A30 ROM 0x50

commit 3ae87d2f25c0e998da2721ce332e2b80d3d53c39 upstream.

Fix firmware file names assignment in si2157 tuner, allow for running
devices without firmware files needed.

modprobe gives error: unknown chip version Si2147-A30 ROM 0x50
Device initialization is interrupted.

Caused by:
1. table si2157_tuners has swapped fields rom_id and required vs struct
   si2157_tuner_info.
2. both firmware file names can be null for devices with
   required == false - device uses build-in firmware in this case

Tested on this device:
	m07ca:1871 AVerMedia Technologies, Inc. TD310 DVB-T/T2/C dongle

[mchehab: fix mangled patch]
Link: https://bugzilla.kernel.org/show_bug.cgi?id=215726
Link: https://lore.kernel.org/lkml/5f660108-8812-383c-83e4-29ee0558d...@leemhuis.info/
Link: https://lore.kernel.org/linux-media/c4bcaff8-fbad-969e-ad47-e2c487ac0...@gmail.com
Fixes: 1c35ba3bf972 ("media: si2157: use a different namespace for firmware")
Cc: sta...@vger.kernel.org # 5.17.x
Signed-off-by: Piotr Chmura 
Tested-by: Robert Schlabbach 
Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/media/tuners/si2157.c | 22 +++---
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/drivers/media/tuners/si2157.c b/drivers/media/tuners/si2157.c
index 47029746b89e..0de587b412d4 100644
--- a/drivers/media/tuners/si2157.c
+++ b/drivers/media/tuners/si2157.c
@@ -77,16 +77,16 @@ static int si2157_cmd_execute(struct i2c_client *client, struct si2157_cmd *cmd)
 }
 
 static const struct si2157_tuner_info si2157_tuners[] = {
-	{ SI2141, false, 0x60, SI2141_60_FIRMWARE, SI2141_A10_FIRMWARE },
-	{ SI2141, false, 0x61, SI2141_61_FIRMWARE, SI2141_A10_FIRMWARE },
-	{ SI2146, false, 0x11, SI2146_11_FIRMWARE, NULL },
-	{ SI2147, false, 0x50, SI2147_50_FIRMWARE, NULL },
-	{ SI2148, true,  0x32, SI2148_32_FIRMWARE, SI2158_A20_FIRMWARE },
-	{ SI2148, true,  0x33, SI2148_33_FIRMWARE, SI2158_A20_FIRMWARE },
-	{ SI2157, false, 0x50, SI2157_50_FIRMWARE, SI2157_A30_FIRMWARE },
-	{ SI2158, false, 0x50, SI2158_50_FIRMWARE, SI2158_A20_FIRMWARE },
-	{ SI2158, false, 0x51, SI2158_51_FIRMWARE, SI2158_A20_FIRMWARE },
-	{ SI2177, false, 0x50, SI2177_50_FIRMWARE, SI2157_A30_FIRMWARE },
+	{ SI2141, 0x60, false, SI2141_60_FIRMWARE, SI2141_A10_FIRMWARE },
+	{ SI2141, 0x61, false, SI2141_61_FIRMWARE, SI2141_A10_FIRMWARE },
+	{ SI2146, 0x11, false, SI2146_11_FIRMWARE, NULL },
+	{ SI2147, 0x50, false, SI2147_50_FIRMWARE, NULL },
+	{ SI2148, 0x32, true,  SI2148_32_FIRMWARE, SI2158_A20_FIRMWARE },
+	{ SI2148, 0x33, true,  SI2148_33_FIRMWARE, SI2158_A20_FIRMWARE },
+	{ SI2157, 0x50, false, SI2157_50_FIRMWARE, SI2157_A30_FIRMWARE },
+	{ SI2158, 0x50, false, SI2158_50_FIRMWARE, SI2158_A20_FIRMWARE },
+	{ SI2158, 0x51, false, SI2158_51_FIRMWARE, SI2158_A20_FIRMWARE },
+	{ SI2177, 0x50, false, SI2177_50_FIRMWARE, SI2157_A30_FIRMWARE },
 };
 
 static int si2157_load_firmware(struct dvb_frontend *fe,
@@ -178,7 +178,7 @@ static int si2157_find_and_load_firmware(struct dvb_frontend *fe)
 		}
 	}
 
-	if (!fw_name && !fw_alt_name) {
+	if (required && !fw_name && !fw_alt_name) {
 		dev_err(>dev,
 			"unknown chip version Si21%d-%c%c%c ROM 0x%02x\n",
 			part_id, cmd.args[1], cmd.args[3], cmd.args[4], rom_id);
-- 
2.36.0



Bug#1010092: src:appstream-generator: fails to migrate to testing for too long: blocked by non-migrating dependency

2022-04-24 Thread Paul Gevers

Source: appstream-generator
Version: 0.8.6-2
Severity: serious
Control: close -1 0.8.8-1
Tags: sid bookworm
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: block -1 by 1006949

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 60 days as having a Release Critical bug in 
testing [1]. Your package src:appstream-generator has been trying to 
migrate for 61 days [2]. Hence, I am filing this bug. This package is 
(at this moment) blocked by multiple dependencies that are not yet 
migrating on their own. One of them already more than 60 days too.


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


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


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


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


Paul

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


OpenPGP_signature
Description: OpenPGP digital signature


Bug#1009320: FW issue

2022-04-24 Thread Salvatore Bonaccorso
Control: tags -1 + moreinfo

Hi,

On Wed, Apr 13, 2022 at 09:58:10PM +0200, mh wrote:
> It seems 5.17.x has problems with the respective FW (no problems with
> prior kernels)
> 
> dmesg output after trying to load list of broadcasters
> *
> [ 6801.250773] si2168 2-0064: downloading firmware from file
> 'dvb-demod-si2168-b40-01.fw' [ 6801.634181] si2168 2-0064: firmware
> version: B 4.0.11 [ 6801.643054] si2157 5-0060: found a 'Silicon Labs
> Si2157-A30 ROM 0x50' [ 6801.643117] si2157 5-0060: Can't continue
> without a firmware.
> **

Can you please verify it again with the current version in unstable
(5.17.3-1).

Regards,
Salvatore



Bug#1008585: linux-image-5.10.0-13-amd64: "clocksource:" log spam after 5.10.103-1 update

2022-04-24 Thread Salvatore Bonaccorso
Control: tags -1 + moreinfo

On Tue, Apr 12, 2022 at 08:49:38PM +0300, Vincas Dargis wrote:
> It seems that this might be fixed in ~5.17, based on this [0] message in
> thread that speaks about problem seemingly similar to mine:
> 
> > Yes, I expect to submit it into the next merge window (not the current
> > v5.16 merge window, but v5.17).  However, if your situation is urgent, and
> > if it works for you, I could submit it as a fix for an earlier regression.
> 
> Although all that thread is beyond me to understand...
> 
> [0] 
> https://lore.kernel.org/all/2021000414.GH641268@paulmck-ThinkPad-P17-Gen-1/

Would you be able to test the current kernel from unstable so we can
confirm it's fixed in 5.17.3-1?

Regards,
Salvatore



  1   2   >