Bug#985632: firmware-brcm80211 1:20210315-3+rpt3

[Arnold Schiller]

I also tried brcmfmac43455-sdio.clm_blob with a version from raspberry,
but with the firmware-brcm802111:20210315-3+rpt3 the Rasperry P4b debian
bullseye stopped working. I then went back to the version
http://raspbian.raspberrypi.org/raspbian 20210315-3 and with that the
wifi works again. It was not to be brought with 20210315-3+rpt3 to the run.

Whatever has been changed

Bug#998674: kaidan: Settings menu is unusable due to overlapping entries

[Axel Beckert]

Package: kaidan
Version: 0.7.0-1
Severity: normal
Control: found -1 0.8.0-1

Hi,

the Settings menu of Kaidan 0.7.0 (Bullseye + Unstable) and 0.8.0
(Experimental) are unusable for me because the menu entries are heavily
overlapping, see screenshot.


Might be an upstream issue, but I'm not sure.

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

Kernel: Linux 5.14.0-2-amd64 (SMP w/4 CPU threads)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages kaidan depends on:
ii  libc62.32-4
ii  libgcc-s111.2.0-10
ii  libkf5notifications5 5.86.0-1
ii  libqt5core5a 5.15.2+dfsg-12
ii  libqt5gui5   5.15.2+dfsg-12
ii  libqt5multimedia55.15.2-3
ii  libqt5network5   5.15.2+dfsg-12
ii  libqt5positioning5   5.15.2+dfsg-2
ii  libqt5qml5   5.15.2+dfsg-8
ii  libqt5quick5 5.15.2+dfsg-8
ii  libqt5quickcontrols2-5   5.15.2+dfsg-4
ii  libqt5sql5   5.15.2+dfsg-12
ii  libqt5widgets5   5.15.2+dfsg-12
ii  libqt5xml5   5.15.2+dfsg-12
ii  libqxmpp31.4.0-2
ii  libstdc++6   11.2.0-10
ii  libzxingcore11.2.0-1
ii  qml-module-org-kde-kirigami2 5.86.0-1
ii  qml-module-org-kde-qqc2desktopstyle  5.86.0-1
ii  qml-module-qtgraphicaleffects5.15.2-2
ii  qml-module-qtlocation5.15.2+dfsg-2
ii  qml-module-qtmultimedia  5.15.2-3
ii  qml-module-qtpositioning 5.15.2+dfsg-2
ii  qml-module-qtqml 5.15.2+dfsg-8
ii  qml-module-qtquick-controls2 5.15.2+dfsg-4
ii  qml-module-qtquick-dialogs   5.15.2-2
ii  qml-module-qtquick-layouts   5.15.2+dfsg-8
ii  qml-module-qtquick2  5.15.2+dfsg-8

kaidan recommends no packages.

kaidan suggests no packages.

-- no debconf information

Bug#998108: Acknowledgement (firefox freezes shortly after start)

[Christoph Anton Mitterer]

> I was also experiencing this problem and was monitoring this bug
> report for potential solutions, but the problem seems to have
> recently disappeared. 

I cannot confirm this.

I've just upgraded to 94.0-1 (with everything else on my system
upgraded to the current state of unstable, well everything except stuff
that is 100% unrelated),... and after a few minutes the previously
described problems re-appeared.


Cheers,
Chris.

Bug#998673: ITP: golang-github-digitalocean-go-smbios -- Detection and access to SMBIOS and DMI data and structures

[Mathias Gibbens]

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

* Package name: golang-github-digitalocean-go-smbios
  Version : 0.0~git20180907.390a4f4-1
  Upstream Author : DigitalOcean
* URL : https://github.com/digitalocean/go-smbios
* License : Apache-2.0
  Programming Lang: Go
  Description : Detection and access to SMBIOS and DMI data and structures

 Provides detection and access to System Management BIOS (SMBIOS) and
 Desktop Management Interface (DMI) data and structures. SMBIOS is a
 standard mechanism for fetching BIOS and hardware information from
 within an operating system. It shares some similarities with the
 older DMI standard, and the two are often confused.
 .
 This package is based on the SMBIOS 3.1.1 specification, but should
 work with SMBIOS 2.0 and above.
 .
 In general, it's up to hardware manufacturers to properly populate
 SMBIOS data, and many structures may not be populated correctly or at
 all; especially on consumer hardware.

This package is a dependency for packaging LXD (ITP #768073).

This package will be team-maintained within the Debian Go Packaging
Team.


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

Bug#998672: packages.debian.org: all arch:all packages have empty filelist

[Sandro Tosi]

Package: www.debian.org
Severity: important
X-Debbugs-Cc: mo...@debian.org

Hello,
i think this problem has been going on for quite a while (months): all arch:all
packages have empty filelist, f.e.

https://packages.debian.org/sid/all/python3-poetry-core/filelist


please have a look as that piece of data is really useful.

Thanks,
Sandro

Bug#998108: having same issue here

[Gennady Kupava]

Since I recently dist-upgraded sid.

Tried to:
1) run with empty profile
2) do apt-get dist-upgrade just now, restart - doesn't help

it seems to be freezing during rendering of the websites, seems like
eventually running out of some resource and java-script heavy sites
freeze it very soon.

For example, if i open https://lichess.org/eTyPxe44EoQs (chess game
analysis on lichess) first it opens fine, but hitting refresh certainly
hungs whole firefox and only way to is kill it.

Bug#971939: cln FTCBFS: missing #include for intptr_t

[Richard B. Kreckel]

Hi Helmut,

On 05.11.21 23:28, Helmut Grohne wrote:
> I created a fresh unstable chroot containing only essential and then ran
> the following commands inside:
> 
> # dpkg --add-architecture ppc64el
> # apt-get update
> # apt-get install g++-powerpc64le-linux-gnu make file libgmp-dev:ppc64el
> $ apt-get source cln
> $ cd cln-*
> $ ./configure --host=powerpc64le-linux-gnu --disable-shared
> 
> It hangs. The last line of output is:
> 
> creating include/cln/intparam.h
> 
> I deliberately used precisely your configure invocation here. As you can
> see, I cannot reproduce your success. Can you reproduce my failure this
> way?
Yes, I can. There seems to be a misunderstanding.

This hang creating intparam.h is the known issue you reported and that
should be fixed upstream.

Sorry, the Debian package version 1.3.6-4 is not fixed yet.

Could you, please, try checking out cln from
https://www.ginac.de/CLN/cln.git/ and run
$ ./autogen.sh
$ ./configure --host=powerpc64le-linux-gnu --disable-shared

The question I am trying to get an answer for is if this really still
hangs in CL_FLOATPARAM_CROSS.

  -richy.
-- 
Richard B. Kreckel

Bug#998670: ITP: golang-gopkg-juju-environschema.v1 -- schema descriptions for Juju environment configurations

[Mathias Gibbens]

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

* Package name: golang-gopkg-juju-environschema.v1
  Version : 1.0.0-1
  Upstream Author : Canonical Ltd
* URL : https://github.com/juju/environschema
* License : LGPL-3.0-with-exception
  Programming Lang: Go
  Description : schema descriptions for Juju environment configurations

 This package allows the specification of Juju environment
 config schema.

This ITP reintroduces the golang-gopkg-juju-environschema.v1 package to
the archive. It was previously RM'ed in #913973 as no packages depended
on it.

This package is a dependency for packaging LXD (ITP #768073).

This package will be team-maintained within the Debian Go Packaging
Team.


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

Bug#998669: ITP: golang-github-juju-schema -- coerce dynamically typed data structures into known forms

[Mathias Gibbens]

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

* Package name: golang-github-juju-schema
  Version : 1.0.0-1
  Upstream Author : Canonical Ltd
* URL : https://github.com/juju/schema
* License : LGPL-3.0-with-exception
  Programming Lang: Go
  Description : coerce dynamically typed data structures into known forms

 This package provides helpers for coercing dynamically typed
 data structures into known forms.

This ITP reintroduces the golang-github-juju-schema package to the
archive. It was previously RM'ed in #911002 as no packages depended on
it.

This package is a dependency for packaging LXD (ITP #768073).

This package will be team-maintained within the Debian Go Packaging
Team.


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

Bug#998668: anna: Make it possible to install with a mismatched kernel

[Vagrant Cascadian]

Package: anna
Severity: wishlist
X-Debbugs-Cc: vagr...@debian.org

I was recently made aware of:

  
https://salsa.debian.org/installer-team/anna/-/commit/f6d5052a00df58c8f9d27d74c8ab585cc4d341e2

  commit f6d5052a00df58c8f9d27d74c8ab585cc4d341e2
  Author: Holger Wansing 
  Date:   Wed Nov 6 00:04:45 2019 +0100

  Change template, to give a senseful message to the user, when no
  kernel modules can be found. Also, turn that from a question into an
  error message, since continuing isn't possible without kernel modules
  anyway.

While I understand the motivation for making this a hard error in the
default case, there are valid use-cases for testing with a mismatched
kernel.

I used to rely on being able to skip this step when testing new arm*
platforms or platforms that depend on a newer kernel version or features
using a custom kernel, or where there is a mismatch in the kernel
version due to a recent ABI bump where debian-installer hasn't yet
caught up with the archive...

Maybe an explicit debconf question with low priority could be used to
skip this step instead of issuing a hard error? That way expert installs
or debconf preseeding could be used with the default images in the less
typical use cases...


Don't have the time to write a patch right now, but somedaymaybe. :)


Thanks!


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#998282: Please make Section a required field for the source paragraph in d/control

[Felix Lechner]

Hi David,

On Thu, Nov 4, 2021 at 7:14 AM David Bremner  wrote:
>
> do you have some numbers

According to Lintian [1] all sources among the 33,721 sources in
unstable and experimental—except perhaps the ones listed below—have a
Section field in the source stanza of d/control. [2]

You can see for yourself by querying our JSON interface [3] with this command:

wget -O no-source-section.hints
'https://lintian.debian.net/query/contexts?tag=no-source-section'

It returns an empty array: []

The following sources were not checked (for resource reasons):

- firefox
- firefox-esr
- linux
- llvm-toolchain-9
- llvm-toolchain-10
- llvm-toolchain-11
- llvm-toolchain-snapshot
- nvidia-cuda-toolkit
- thunderbird

I believe the tag functions properly because there is a unit test for
it. [4] [5]

Kind regards
Felix Lechner

[1] 
https://salsa.debian.org/lintian/lintian/-/blob/master/lib/Lintian/Check/Debian/Control/Field/Section.pm
[2] https://lintian.debian.org/tags/no-source-section
[3] https://lintian.debian.org/query
[4] 
https://salsa.debian.org/lintian/lintian/-/blob/master/t/recipes/checks/debian/control/field/section/no-section-in-source-stanza/build-spec/debian/control.in
[5] 
https://salsa.debian.org/lintian/lintian/-/blob/master/t/recipes/checks/debian/control/field/section/no-section-in-source-stanza/eval/hints

Bug#984063:

[Jose Luis Rivero]

Hello! Gazebo maintainer here, affected by this RC bug. Looking into
upstream repository there is a potential commit that can be used to patch
this problem until new versions land in Debian:

https://github.com/InsightSoftwareConsortium/ITK/commit/840f22feb351739359a8fdb55304124823a3a8c9

Let me know if you need more help or assistance.
Thanks!

Bug#984276:

[Jose Luis Rivero]

Hello! Gazebo maintainer here, affected by this RC bug on opencolorio. I've
looked in the problem and seems something easy to fix:

diff --git a/src/core/ImageDesc.cpp b/src/core/ImageDesc.cpp
index 63156c8..e96e758 100644
--- a/src/core/ImageDesc.cpp
+++ b/src/core/ImageDesc.cpp
@@ -57,8 +57,8 @@ OCIO_NAMESPACE_ENTER
 os << "gData=" << planarImg->getGData() << ", ";
 os << "bData=" << planarImg->getBData() << ", ";
 os << "aData=" << planarImg->getAData() << ", ";
-os << "width=" << packedImg->getWidth() << ", ";
-os << "height=" << packedImg->getHeight() << ", ";
+os << "width=" << planarImg->getWidth() << ", ";
+os << "height=" << planarImg->getHeight() << ", ";
 os << "yStrideBytes=" << planarImg->getYStrideBytes() << "";
 os << ">";
 }

The repo in salsa seems to be a work in progress to get 2.x series into
Debian, although not finished yet. We could apply this patch on top of the
current version to fix this bug while the 2.x transition is being done.

Let me know if you need more help.
Thanks!

Bug#998663: installation-reports: Installation of the Bullseye Kernel on BeagleBone Black is Hanging

[Vagrant Cascadian]

.

Same with the daily images, boots but no ethernet card:

https://d-i.debian.org/daily-images/armhf/20211105-04:46/netboot/SD-card-images/

Current buster images also hang completely, never starting the
installer... arg.



Apparently this commit upstream (which has been backported to earlier
series) caused some of the above issues:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/usb/musb/musb_dsps.c?id=7c75bde329d7e2a93cf86a5c15c61f96f1446cdc

Might be fixed in 5.10.75...

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/usb/musb/musb_dsps.c?id=c2115b2b16421d93d4993f3fe4c520e91d6fe801


Hope to be able to look into this further at some point...


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#998667: git-quick-stats: default _GIT_SINCE (epoch time) is incorrect

[Vincent Lefevre]

Package: git-quick-stats
Version: 2.3.0-1
Severity: normal

_GIT_SINCE defaults to 2005-04-07, which is surprising
(for instance, GNU MPFR started in 1999).

Indeed, in the source:

# Beginning git log date. Respects all git datetime formats
# If $_GIT_SINCE is never set, choose epoch time as that is
# as far back as git will allow you to go
_since=${_GIT_SINCE:-}
if [[ -n "${_since}" ]]; then
_since="--since=$_since"
else
_since="--since=2005-04-07"
fi

But the epoch time is 1970-01-01, not 2005-04-07. It would be
better not to have a default limit, but I doubt that there are
git repositories with dates before 1970...

-- 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.14.0-4-amd64 (SMP w/8 CPU threads)
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 git-quick-stats depends on:
ii  bsdextrautils  2.37.2-4
ii  git1:2.33.1-1

git-quick-stats recommends no packages.

git-quick-stats suggests no packages.

-- no debconf information

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

Bug#998666: "git-quick-stats -h" fails if not run from a git repository

[Vincent Lefevre]

Package: git-quick-stats
Version: 2.3.0-1
Severity: minor

I get the following error:

zira:~> git-quick-stats -h
fatal: not a git repository (or any of the parent directories): .git

while the -h option is just there to get the help, not to access
a git repository.

-- 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.14.0-4-amd64 (SMP w/8 CPU threads)
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 git-quick-stats depends on:
ii  bsdextrautils  2.37.2-4
ii  git1:2.33.1-1

git-quick-stats recommends no packages.

git-quick-stats suggests no packages.

-- no debconf information

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

Bug#997030: openssh: FTBFS on hurd-i386

[Colin Watson]

On Fri, Oct 22, 2021 at 06:55:17PM +0200, Svante Signell wrote:
> Currently openssh FTBFS on GNU/Hurd due to a missing definition of
> MAXHOSTNAMELEN. The attached patches, defines.h.diff and gss-
> serv.c.diff fixes these problems.

The second patch isn't necessary; gss-serv.c already unconditionally
includes includes.h, which in turn unconditionally includes defines.h.
defines.h appears to conventionally not be included by individual .c
files in OpenSSH.

I've applied the first of these two patches for my next upload; thanks.

-- 
Colin Watson (he/him)  [cjwat...@debian.org]

Bug#998665: The SYNOPSIS only randomly mentions one of the programs

[積丹尼 Dan Jacobson]

Package: imagemagick-6.q16
Version: 8:6.9.11.60+dfsg-1.3
Severity: minor
File: /usr/share/man/man1/ImageMagick-im6.q16.1.gz

The SYNOPSIS only randomly mentions one of the programs.

Bug#799864: RFH: cyrus-sasl2

[Bastian Germann]

On Wed, 23 Sep 2015 14:40:58 +0200 ond...@debian.org wrote:


cyrus-sasl2 needs you!  The most (all) of the members of packaging
team are dormant, and the cyrus-sasl2 feels neglected, we need a new
blood who will love and care about cyrus-sasl2.

There are not much upstream releases in past and the package is also
in semi-good shape, so it's mostly about looking at the user reported
bugs, reporting the upstream bugs to upstream bugzilla, and pulling
the patches back.  The usual drill...  If you apply remember that this
is the SASL package that's the core of many authentication protocols,
so you should be sure about every change to the package you do.


Hi Ondrej,

I have started working at the package and just uploaded a new version as NMU
with 3 days delay. Please tell me if you are okay with the changes and then I
will add myself in the uploaders list and continue working on the package,
closing the RFH.

I have already worked with Roberto at the Crosswire Team.

Thanks,
Bastian

Bug#996391: openssh: New upstream version available

[Colin Watson]

For now I'm going to go ahead with packaging 8.7p1 (cherry-picking the
security fix from 8.8p1) to at least catch us up a bit, and I'll leave
this bug open.

-- 
Colin Watson (he/him)  [cjwat...@debian.org]

Bug#998664: libntl43: undefined reference to `NTL::sub(NTL::ZZ&, NTL::ZZ const&, long)

[David George Henderson III]

Package: libntl43
Version: 11.4.3-1+b1
Severity: normal
X-Debbugs-Cc: d...@its.caltech.edu

Dear Maintainer,

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

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

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


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

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

Versions of packages libntl43 depends on:
ii  libc62.31-13+deb11u2
ii  libgcc-s1 [libgcc1]  10.2.1-6
ii  libgf2x3 1.3.0-1+b1
ii  libgmp10 2:6.2.1+dfsg-1
ii  libstdc++6   10.2.1-6

libntl43 recommends no packages.

libntl43 suggests no packages.

-- no debconf information

Here is the program that reproduces the problem when compiled:

#include 
#include 
#include 

int bugdemo(NTL::ZZ & result, const NTL::ZZ , long right) {
result = left - right;
return 0;
}
int main(int argc, char* argv[]) {

NTL::ZZ u,v;
long w;
v = 4;
w = 4;
bugdemo(u,v,w);
}

Bug#998109: python3-numpy: numpy.typing is missing

[Drew Parsons]

On 2021-11-05 06:10, Sandro Tosi wrote:
On Wed, Nov 3, 2021 at 7:16 PM Drew Parsons  
wrote:

...

Just add
   usr/lib/python3*/*-packages/numpy/typing/
to debian/python3-numpy.install.


i've uploaded this to experimental



Thanks Sandro, works well.  I've uploaded npx to NEW now.



The bigger question here is why are the subdirs listed separately?
Is it in order to handle the dbg libraries (python3-numpy-dbg.install) 
?
Since python3-dbg is now deprecated (Bug#994316), do we want to 
simplify

the package by replacing all the subdirs in python3-numpy.install with
just
   usr/lib/python3*/*-packages/numpy/

That would keep this bug from happening again with other new features 
in

the future.


that's a fair point, and i cant recall why it's setup that way. I'll
keep a note to review when we're ready to drop the -dbg package (there
are still a handful of rdeps)


Sounds good!

Bug#971939: cln FTCBFS: missing #include for intptr_t

[Helmut Grohne]

Hi Richard,

On Fri, Nov 05, 2021 at 11:00:17PM +0100, Richard B. Kreckel wrote:
> So I uninstalled it. It still compiles and I can still run the tests.

That makes things interesting. Let us pin down as much as we can to
figure out the difference.

I created a fresh unstable chroot containing only essential and then ran
the following commands inside:

# dpkg --add-architecture ppc64el
# apt-get update
# apt-get install g++-powerpc64le-linux-gnu make file libgmp-dev:ppc64el
$ apt-get source cln
$ cd cln-*
$ ./configure --host=powerpc64le-linux-gnu --disable-shared

It hangs. The last line of output is:

creating include/cln/intparam.h

I deliberately used precisely your configure invocation here. As you can
see, I cannot reproduce your success. Can you reproduce my failure this
way?

If not, can you maybe try building the cln source package from unstable
for ppc64el using sbuild or pbuilder?

> > The last attempt for ppc64el is a bit dated already:
> > http://crossqa.debian.net/build/cln_1.3.6-4_ppc64el_20210324230722.log
> > I scheduled a new attempt now.

That failed as expected:
http://crossqa.debian.net/build/cln_1.3.6-4_ppc64el_20211105143826.log

> > For all other architectures, we see a new issue:
> > 
> > ../include/cln/intparam.h:26:2: error: #error "Type char * does not fit 
> > into an intptr_t!!"
> >26 | #error "Type char * does not fit into an intptr_t!!"
> >   |  ^
> > 
> > That even happens for combinations of 64bit architectures. I see that
> > stdint.h is now included, so I don't understand why it fails like that.
> 
> I don't understand either. That check should really work.
> 
> Obviously, I cannot reproduce that either.
> 
> Since when do we get this?

You can easily tell from looking at http://crossqa.debian.net/src/cln:
Since the 1.3.6-1 upload.

Helmut

Bug#995423: libyaml-cpp-dev: Incorrect include PATH in CMake configuration script.

[Tomasz Wolak]

Hello Gianfranco,

On 10/27/21 10:13 AM, Gianfranco Costamagna wrote:

Hello Tomasz

On Wed, 20 Oct 2021 19:58:47 +0200 Tomasz Wolak  wrote:

[...]
I have tried to build the source package 0.7.0
(https://packages.debian.org/experimental/libyaml-cpp-dev) for my Debian
(bullseye), but unfortunately building the package fails with:



https://buildd.debian.org/status/package.php?p=yaml-cpp=experimental

0.7.0+dfsg-5 should be buildable correctly, the package was broken due to 
missing
symbols

please give it another shot if possible :)

Gianfranco




Yes, the version 0.7.0+dfsg-5 builds on Bullseye and both pkg-config and 
CMake's find_package() return "" (an empty string) as include directory 
for yaml-cpp. The library's header files are under system's generic 
/usr/include ( /usr/include/yaml-cpp/ in this case) - so it seems 
correct to me as it is fine for compilation (as long as source files are 
using the relative path ).


I was a bit confused though, as the software that I was building 
(RStudio, www.rstudio.com, the latest released version 
rstudio-2021.09.0-351) was still failing - because its CMake script 
checks if the include directory (provided in YAML_CPP_INCLUDE_DIR) 
exists... This seems to me a bad practice considering the above (no 
additional include paths may be needed for correct compilation).
However, this varies also between different libraries - for some, the 
tools returns an absolute path to their subdirectory, eg. for uuid, 
pkg-config returns -I/usr/include/uuid; for SDL2 both pkg-config and 
CMake points to /usr/include/SDL2 etc.). In such case, RStudio 
developers' approach would be correct...


Is there a (at least recommended) standard for this or each library goes 
its own way? (I suppose Debian does not enforce this, just follows the 
original).


Anyway - 0.7.0 seems OK. (backported to Bullseye will fix the problem 
with CMake).


Thank you.

Tomasz

Bug#998663: Debug Output Generated During Failed Boot Attemp

[David Kaiser]

I have attached  a copy of the boot debug output in file BootHang.txt.  I have 
also copied the text of that file here:


U-Boot SPL 2021.01+dfsg-5 (May 23 2021 - 04:32:45 +)
Trying to boot from MMC1


U-Boot 2021.01+dfsg-5 (May 23 2021 - 04:32:45 +)

CPU  : AM335X-GP rev 2.1
Model: TI AM335x BeagleBone Black
DRAM:  512 MiB
WDT:   Started with servicing (60s timeout)
NAND:  0 MiB
MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1
Loading Environment from FAT... *** Warning - bad CRC, using default environment

 not set. Validating first E-fuse MAC
Net:   eth2: ethernet@4a10, eth3: usb_ether
Hit any key to stop autoboot:  0
switch to partitions #0, OK
mmc0 is current device
SD/MMC found on device 0
1575 bytes read in 2 ms (768.6 KiB/s)
Running bootscript from mmc0 ...
## Executing script at 8200
Mainline u-boot / new-style environment detected.
This installer medium does not contain a suitable device-tree file for
this system (am335x-boneblack.dtb). Aborting boot process.
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
Found U-Boot script /boot.scr
1575 bytes read in 2 ms (768.6 KiB/s)
## Executing script at 8000
Mainline u-boot / new-style environment detected.
4956672 bytes read in 322 ms (14.7 MiB/s)
62852 bytes read in 70 ms (876 KiB/s)
15339358 bytes read in 995 ms (14.7 MiB/s)
Booting the Debian installer...

## Flattened Device Tree blob at 8800
   Booting using the fdt blob at 0x8800
   Loading Ramdisk to 8f15f000, end 8f5e ... OK
   Loading Device Tree to 8f14c000, end 8f15e583 ... OK

Starting kernel ...

[0.00] Booting Linux on physical CPU 0x0
[0.00] Linux version 5.10.0-9-armmp 
(debian-ker...@lists.debian.org) (gcc-10 
(Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2) #1 
SMP Debian 5.10.70-1 (2021-09-30)
[0.00] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c5387d
[0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing 
instruction cache
[0.00] OF: fdt: Machine model: TI AM335x BeagleBone Black
[0.00] Memory policy: Data cache writeback
[0.00] efi: UEFI not found.
[0.00] cma: Reserved 16 MiB at 0x9e80
[0.00] Zone ranges:
[0.00]   DMA  [mem 0x8000-0x9fdf]
[0.00]   Normal   empty
[0.00]   HighMem  empty
[0.00] Movable zone start for each node
[0.00] Early memory node ranges
[0.00]   node   0: [mem 0x8000-0x9fdf]
[0.00] Initmem setup node 0 [mem 0x8000-0x9fdf]
[0.00] CPU: All CPU(s) started in SVC mode.
[0.00] AM335X ES2.1 (sgx neon)
[0.00] percpu: Embedded 21 pages/cpu s54604 r8192 d23220 u86016
[0.00] Built 1 zonelists, mobility grouping on.  Total pages: 129412
[0.00] Kernel command line:  console=ttyO0,115200n8
[0.00] Dentry cache hash table entries: 65536 (order: 6, 262144 bytes, 
linear)
[0.00] Inode-cache hash table entries: 32768 (order: 5, 131072 bytes, 
linear)
[0.00] mem auto-init: stack:off, heap alloc:on, heap free:off
[0.00] Memory: 466092K/522240K available (11264K kernel code, 1667K 
rwdata, 3188K rodata, 2048K init, 333K bss, 39764K reserved, 16384K 
cma-reserved, 0K highmem)
[0.00] random: get_random_u32 called from 
__kmem_cache_create+0x30/0x42c with crng_init=0
[0.00] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
[0.00] ftrace: allocating 37383 entries in 110 pages
[0.00] ftrace: allocated 110 pages with 5 groups
[0.00] rcu: Hierarchical RCU implementation.
[0.00] rcu: RCU restricting CPUs from NR_CPUS=8 to nr_cpu_ids=1.
[0.00]  Rude variant of Tasks RCU enabled.
[0.00]  Tracing variant of Tasks RCU enabled.
[0.00] rcu: RCU calculated value of scheduler-enlistment delay is 25 
jiffies.
[0.00] rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=1
[0.00] NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16
[0.00] IRQ: Found an INTC at 0x(ptrval) (revision 5.0) with 128 
interrupts
[0.00] TI gptimer clocksource: always-on 
/ocp/interconnect@44c0/segment@20/target-module@31000
[0.12] sched_clock: 32 bits at 24MHz, resolution 41ns, wraps every 
89478484971ns
[0.32] clocksource: dmtimer: mask: 0x max_cycles: 0x, 
max_idle_ns: 79635851949 ns
[0.000883] TI gptimer clockevent: 2400 Hz at 
/ocp/interconnect@4800/segment@0/target-module@4
[0.004366] Console: colour dummy device 80x30
[0.004452] Calibrating delay loop... 995.32 BogoMIPS (lpj=1990656)
[0.048940] pid_max: default: 32768 minimum: 301
[0.049279] LSM: Security Framework initializing
[0.049389] Yama: disabled by default; enable with sysctl kernel.yama.*
[0.049649] AppArmor: AppArmor initialized
[0.049668] TOMOYO Linux 

Bug#998108: firefox freezes shortly after start

[Adon Shapiro]

Hi,

I was also experiencing this problem and was monitoring this bug report for
potential solutions, but the problem seems to have recently disappeared. I
haven't experienced it since yesterday (2021-11-05) even on sites that I
knew to trigger it previously. Like everyone else, the problem started for me
with 93.0-1+b1 and persisted with 94.0-1. I am currently still using 94.0-1
with no problems. Perhaps a recent lib update resolved this?

Adon

Bug#998663: installation-reports: Installation of the Bullseye Kernel on BeagleBone Black is Hanging

[David Kaiser]

Package: installation-reports
Severity: normal
X-Debbugs-Cc: dwkai...@hotmail.com, vagr...@debian.org

(Please provide enough information to help the Debian
maintainers evaluate the report efficiently - e.g., by filling
in the sections below.)

Boot method: SD Card
Image version: 
https://deb.debian.org/debian/dists/bullseye/main/installer-armhf/current/images/hd-media/SD-card-images/firmware.BeagleBoneBlack.img.gz
 and partition.img.gz
Date: November 5, 2021

Machine: BeagleBone Black Rev C
Partitions: /dev/sde1 vfat 131544 47509 84036 37% /media/david/2024-75AE


Base System Installation Checklist:
[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it

Initial boot:   [E]
Detect network card:[ ]
Configure network:  [ ]
Detect media:   [ ]
Load installer modules: [ ]
Clock/timezone setup:   [ ]
User/password setup:[ ]
Detect hard drives: [ ]
Partition hard drives:  [ ]
Install base system:[ ]
Install tasks:  [ ]
Install boot loader:[ ]
Overall install:[ ]

Comments/Problems:

U-Boot 2021.01+dfsg-5 (May 23 2021 - 04:32:45 +)  successfully loads and 
starts up.
U-Boot attempts to run bootscript from mmc0:
  This installer medium does not contain a suitable device-tree file for this 
system (am335x-boneblack.dtb)...
  Scanning mmc 0:1...
  #3 Executing script at 800...
  Starting kernel ...
  Main lines, eventual hang.

Please make sure that any installation logs that you think would
be useful are attached to this report. Please compress large
files using gzip.


-- Package-specific info:

I removed the following auto-generated information as it was relevant to my 
development machine, not the target BeagleBone Black.

Bug#971939: cln FTCBFS: missing #include for intptr_t

[Richard B. Kreckel]

Hi Helmut,

On 05.11.21 15:41, Helmut Grohne wrote:
> On Fri, Nov 05, 2021 at 10:32:59AM +0100, Richard B. Kreckel wrote:
> I vaguely suspect that you do have qemu-user-binfmt installed and that
> it enables running foreign binaries and changes the way configure
> behaves. Does that match reality?

Indeed, qemu-user-binfmt was installed.

So I uninstalled it. It still compiles and I can still run the tests.

> The last attempt for ppc64el is a bit dated already:
> http://crossqa.debian.net/build/cln_1.3.6-4_ppc64el_20210324230722.log
> I scheduled a new attempt now.
> 
> For all other architectures, we see a new issue:
> 
> ../include/cln/intparam.h:26:2: error: #error "Type char * does not fit into 
> an intptr_t!!"
>26 | #error "Type char * does not fit into an intptr_t!!"
>   |  ^
> 
> That even happens for combinations of 64bit architectures. I see that
> stdint.h is now included, so I don't understand why it fails like that.

I don't understand either. That check should really work.

Obviously, I cannot reproduce that either.

Since when do we get this?

> Does that help you with reproducing the failures I see?

Unfortunately, no.

  -richy.
-- 
Richard B. Kreckel

Bug#998662: picocli: Please update to newer upstream version >= 4.6.1

[Jonathan Dowland]

Source: picocli
Version: 3.9.6-3
Severity: normal

I'd like to package some software that depends upon the picocli
API from 4.x onwards (specifically the latest upstream version
4.6.1, I haven't experimented to see whether I could get away
with earlier 4.x versions). 3.9.6 is too old for this software.
Please consider updating the Debian package.


-- System Information:
Debian Release: 11.1
  APT prefers stable-security
  APT policy: (999, 'stable-security'), (990, 'stable'), (500, 
'stable-updates'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Bug#998661: installation-reports: Successful install on Acer Switch V 10 (SW5-017P)

[Rudolf Polzer]

Package: installation-reports
Severity: normal
X-Debbugs-Cc: divver...@gmail.com

Boot method: USB
Image version: firmware-testing-amd64-netinst.iso
Date: 2021-10-10

Machine: Acer Switch V 10 (SW5-017P)
Partitions:
Number  Start   End SizeFile system  Name   Flags
 1  1049kB  538MB   537MB   fat32   boot, esp
 2  538MB   1050MB  512MB   ext2 boot
 3  1050MB  62.5GB  61.5GB   crypt


Base System Installation Checklist:
[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it

Initial boot:   [X]
Detect network card:[X] (needed firmware-iwlwifi)
Configure network:  [X]
Detect media:   [X]
Load installer modules: [X]
Clock/timezone setup:   [X]
User/password setup:[X]
Detect hard drives: [X]
Partition hard drives:  [X]
Install base system:[X]
Install tasks:  [X]
Install boot loader:[E]
Overall install:[X]

Comments/Problems:

Primary problem was that the installed system did not boot. This is a known
problem of some Acer UEFI firmwares, which have hardcoded the path where
Windows puts its boot loader and instead ignore the EFI variables.

To fix this, I had to move all .efi and .CSV files from
/target/boot/efi/EFI/debian to /target/boot/efi/EFI/Microsoft/Boot and
rename shimx64.efi to bootmgfw.efi.

This can be done in the final stage of the installer right before the
reboot.

See https://hansdegoede.livejournal.com/24132.html

Bug#971939: cln FTCBFS: missing #include for intptr_t

[Helmut Grohne]

Hi Richard,

On Fri, Nov 05, 2021 at 10:32:59AM +0100, Richard B. Kreckel wrote:
> How can I reproduce this?

Thank you for looking into the issue.

> On my bullseye setup, this works:
> $ ./configure --host=powerpc64le-linux-gnu --disable-shared
> $ make
> $ qemu-ppc64le -L /usr/powerpc64le-linux-gnu ./tests/exam
> Tests passed.

I do wonder how I can reproduce this. :)

> It surely produces the expected floatparam.h file, with
> long_double_mant_bits set to 106.

You can find complete cross build logs at
http://crossqa.debian.net/src/cln. There you can find complete configure
invocations and the precise packages that were used for performing the
build.

I vaguely suspect that you do have qemu-user-binfmt installed and that
it enables running foreign binaries and changes the way configure
behaves. Does that match reality?

The last attempt for ppc64el is a bit dated already:
http://crossqa.debian.net/build/cln_1.3.6-4_ppc64el_20210324230722.log
I scheduled a new attempt now.

For all other architectures, we see a new issue:

../include/cln/intparam.h:26:2: error: #error "Type char * does not fit into an 
intptr_t!!"
   26 | #error "Type char * does not fit into an intptr_t!!"
  |  ^

That even happens for combinations of 64bit architectures. I see that
stdint.h is now included, so I don't understand why it fails like that.

Does that help you with reproducing the failures I see?

Helmut

Bug#997314: python-hbmqtt: FTBFS: dh_auto_test: error: pybuild --test -i python{version} -p 3.9 returned exit code 13

[Helmut Grohne]

Control: tags -1 + patch

On Sat, Oct 23, 2021 at 09:40:41PM +0200, Lucas Nussbaum wrote:
> During a rebuild of all packages in sid, your package failed to build
> on amd64.

Please find a fix attached.

Helmut
--- python-hbmqtt-0.9.6.orig/hbmqtt/adapters.py
+++ python-hbmqtt-0.9.6/hbmqtt/adapters.py
@@ -3,7 +3,7 @@
 # See the file license.txt for copying permission.
 import asyncio
 import io
-from websockets.protocol import WebSocketCommonProtocol
+from websockets.legacy.protocol import WebSocketCommonProtocol
 from websockets.exceptions import ConnectionClosed
 from asyncio import StreamReader, StreamWriter
 import logging

Bug#998660: RFA: purple-matrix

[Alberto Garcia]

Package: wnpp
Severity: normal
Control: affects -1 src:purple-matrix

I would like to stop maintaining the purple-matrix package. This
software has had very little development over the years and it's been
a long time since I last used it myself.

(interestingly upstream just created the v0.1.0 tag but the activity
is still almost zero).

If no one is interested in taking over the maintenance I suggest we
remove it from the archive.

Regards,

Berto

Bug#996324: ruby-netcdf: FTBFS with ruby3.0: ERROR: Test "ruby3.0" failed: Segmentation fault at 0x0000000000000034

[Sergio Durigan Junior]

On Friday, November 05 2021, Sebastiaan Couwenberg wrote:

> On 11/5/21 20:58, Sergio Durigan Junior wrote:
>> - The netcdf upstream project seems to be inactive, to say the least.
>>The last release happened in 2015, and I could not find a git
>>repository for it.
>
> Upstream development is not healthy, but not entirely dead:
>
>  https://lists.debian.org/debian-gis/2021/10/msg3.html

Ah, thanks for the pointer, I wasn't aware that the package is being
maintained.

>> Having said all that, I am inclined to say that this package
>> could/should be removed from Debian if it causes delays in the Ruby 3.0
>> transition.
>
> It does not cause delays, ruby3.0 is in testing since October 20th and
> ruby-defaults (1:2.7.6) migrated yesterday.
>
> ruby-netcdf has no rdeps and low popcon, it's insignificant in the
> greater ruby3.0 transition.
>
> The package will be removed from Debian if it doesn't get fixed in
> time for the bookworm release.
>
> Its maintainer and upstream developer said he'd work on fixing it, and
> there is still plenty of time for that.

ACK.

Thanks,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
https://sergiodj.net/


signature.asc
Description: PGP signature

Bug#998415: [Pkg-rust-maintainers] Bug#998415: With a recent upload of rust-serde the autopkgtest of rust-debcargo, fails in testing when that autopkgtest is run with the binary packages, of rust-serd

[Ximin Luo]

In other words, I don't see what value these bug reports are adding.

As long as the package is not in Debian Testing, there are very excellent 
status pages developed by the Debian Release team to make us aware of the 
problem. Additional bug reports informing us of what we already know 
(uninstallable, bd-uninstallable, blah blah blah) do not add extra value, in 
fact they reduce value by forcing us to close bug reports.

Best,
Ximin

Ximin Luo:
> Due to the nature of the Rust upstream ecosystem, bugs like this are expected 
> from time to time as we update dependent crates.
> 
> A reversion in terms of downgrading the version using +really-like schemes is 
> not feasible at the current time, see 
> https://salsa.debian.org/rust-team/debcargo/-/issues/31.
> 
> rust-cargo is blocked on various crates in NEW. rust-debcargo is likewise 
> blocked on rust-cargo.
> 
> In the meantime I am happy for these packages to be kept out of Debian 
> Testing as per britney's automated process; I performed the uploads of the 
> dependency packages well aware that this sort of breakage would result. It is 
> not against Debian Policy to have broken packages in Debian Unstable, that is 
> exactly what it is for.
> 
> Paul Gevers:
>> Control: reassign 998415 rust-cargo
>> Control: close 998415 0.57.0-1
>> Control: affects 998415 src:rust-serde src:rust-debcargo
>>
>> Hi Peter,
>>
>> On 04-11-2021 01:19, Peter Green wrote:
>>> Reassign 998415 rust-cargo
>>> Close 998415 0.57.0-1
>>> Thanks
>>
>> ^ Fixing this, the message wasn't sent to control@b.d.o
>>
>>> I can prepare a TPU upload if you would like. Or we can just wait it out
>>> and see what
>>> happens after the Packages pass new and Debcargo is updated.
>>
>> Depends on how long that's going to take and how the TPU would look
>> like. If this is taking long (the RC limit is 60 days), then please
>> contact the Release Team via an unblock request to discuss the potential
>> upload before uploading. An alternative (better from my RT perspective)
>> is to revert the new upstream version of rust-cargo, fix the issue in
>> unstable, have that migrate and then reupload the new upstream version
>> to unstable. That way the RT doesn't need to be further involved.
>>
>> Paul
>>
>>
>> ___
>> Pkg-rust-maintainers mailing list
>> pkg-rust-maintain...@alioth-lists.debian.net
>> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-rust-maintainers
>>
> 
> 


-- 
GPG: ed25519/56034877E1F87C35
https://github.com/infinity0/pubkeys.git

Bug#996324: ruby-netcdf: FTBFS with ruby3.0: ERROR: Test "ruby3.0" failed: Segmentation fault at 0x0000000000000034

[Sebastiaan Couwenberg]

On 11/5/21 20:58, Sergio Durigan Junior wrote:

- The netcdf upstream project seems to be inactive, to say the least.
   The last release happened in 2015, and I could not find a git
   repository for it.


Upstream development is not healthy, but not entirely dead:

 https://lists.debian.org/debian-gis/2021/10/msg3.html


Having said all that, I am inclined to say that this package
could/should be removed from Debian if it causes delays in the Ruby 3.0
transition.


It does not cause delays, ruby3.0 is in testing since October 20th and 
ruby-defaults (1:2.7.6) migrated yesterday.


ruby-netcdf has no rdeps and low popcon, it's insignificant in the 
greater ruby3.0 transition.


The package will be removed from Debian if it doesn't get fixed in time 
for the bookworm release.


Its maintainer and upstream developer said he'd work on fixing it, and 
there is still plenty of time for that.


Kind Regards,

Bas

--
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Bug#994795: w3-dtd-mathml: invalid redeclaration of predefined entities amp and lt yields failures with libxml2 2.9.12

[Adrian Bunk]

On Tue, Sep 21, 2021 at 03:31:17AM +0200, Vincent Lefevre wrote:
> Alternatively, I wonder whether w3c-sgml-lib (which appears to be
> correct) could replace w3-dtd-mathml,
>...

--- /usr/share/xml/schema/w3c/mathml/dtd/mathml2.dtd2001-06-20 
17:45:45.0 +
+++ /usr/share/xml/w3c-sgml-lib/schema/dtd/XX-MathML2-20031104/mathml2.dtd  
2011-03-14 19:54:46.0 +
...
-Revision:   $Id: mathml2.dtd,v 1.20 2000/12/06 19:03:13 davidc Exp $
+Revision:   $Id: mathml2.dtd,v 1.12 2003/11/04 13:14:35 davidc Exp $
...


IOW, it seems to be fixed in the 2003 version of MathML2 but 
w3-dtd-mathml ships the older 2000 version.

BTW: python3-biopython also ships a copy of the 2000 version.

cu
Adrian

Bug#998415: With a recent upload of rust-serde the autopkgtest of rust-debcargo,fails in testing when that autopkgtest is run with the binary packages,of rust-serde from unstable. It passes when run w

[Ximin Luo]

Due to the nature of the Rust upstream ecosystem, bugs like this are expected 
from time to time as we update dependent crates.

A reversion in terms of downgrading the version using +really-like schemes is 
not feasible at the current time, see 
https://salsa.debian.org/rust-team/debcargo/-/issues/31.

rust-cargo is blocked on various crates in NEW. rust-debcargo is likewise 
blocked on rust-cargo.

In the meantime I am happy for these packages to be kept out of Debian Testing 
as per britney's automated process; I performed the uploads of the dependency 
packages well aware that this sort of breakage would result. It is not against 
Debian Policy to have broken packages in Debian Unstable, that is exactly what 
it is for.

Paul Gevers:
> Control: reassign 998415 rust-cargo
> Control: close 998415 0.57.0-1
> Control: affects 998415 src:rust-serde src:rust-debcargo
> 
> Hi Peter,
> 
> On 04-11-2021 01:19, Peter Green wrote:
>> Reassign 998415 rust-cargo
>> Close 998415 0.57.0-1
>> Thanks
> 
> ^ Fixing this, the message wasn't sent to control@b.d.o
> 
>> I can prepare a TPU upload if you would like. Or we can just wait it out
>> and see what
>> happens after the Packages pass new and Debcargo is updated.
> 
> Depends on how long that's going to take and how the TPU would look
> like. If this is taking long (the RC limit is 60 days), then please
> contact the Release Team via an unblock request to discuss the potential
> upload before uploading. An alternative (better from my RT perspective)
> is to revert the new upstream version of rust-cargo, fix the issue in
> unstable, have that migrate and then reupload the new upstream version
> to unstable. That way the RT doesn't need to be further involved.
> 
> Paul
> 
> 
> ___
> Pkg-rust-maintainers mailing list
> pkg-rust-maintain...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-rust-maintainers
> 


-- 
GPG: ed25519/56034877E1F87C35
https://github.com/infinity0/pubkeys.git

Bug#997736: marked as pending in moment-timezone.js

[Julien Cristau]

Control: tag -1 - pending

On Wed, Oct 27, 2021 at 09:13:11AM +, Yadd wrote:
> Control: tag -1 pending
> 
> Hello,
> 
> Bug #997736 in moment-timezone.js reported by you has been fixed in the
> Git repository and is awaiting an upload. You can see the commit
> message below and you can check the diff of the fix at:
> 
> https://salsa.debian.org/js-team/moment-timezone.js/-/commit/a0d3e6761a48f8cccbbb4c46ac3d99315b36e2b3
> 
> 
> Require tz-data = 2021e
> 
> Closes: #997736
> 
> 
I'm afraid that commit is not an acceptable fix.

Cheers,
Julien

Bug#996866: cyrus-sasl2: Reconsider package license

[Ondřej Surý]

Sure, consider anything from me to be public domain. I don’t even recall the 
license change.

Ondřej Surý

> On 5. 11. 2021, at 20:51, Bastian Germann  wrote:
> 
> Would you be so kind to relicense this via deleting it from debian/copyright?

Bug#981229: dub: autopkgtest regression

[Adrian Bunk]

On Thu, Jan 28, 2021 at 01:01:15AM +0100, Matthias Klumpp wrote:
> Am Do., 28. Jan. 2021 um 00:33 Uhr schrieb Sebastian Ramacher
> :
> >
> > Source: dub
> > Version: 1.24.0-1
> > Severity: serious
> > X-Debbugs-Cc: sramac...@debian.org
> >
> > | autopkgtest [03:11:10]: test run: [---
> > | Package dub not found for registry at https://code.dlang.org/ (fallbacks 
> > registry at https://codemirror.dlang.org/, registry at 
> > https://dub.bytecraft.nl/, registry at https://code-mirror.dlang.io/): 
> > Failed to download 
> > https://code.dlang.org/api/packages/infos?packages=%5B%22dub%22%5D_dependencies=true=true
> > | Getting a release version failed: No package dub was found matching the 
> > dependency >=0.0.0
> > | Retry with ~master...
> > | Package dub not found for registry at https://code.dlang.org/ (fallbacks 
> > registry at https://codemirror.dlang.org/, registry at 
> > https://dub.bytecraft.nl/, registry at https://code-mirror.dlang.io/): 
> > Failed to download 
> > https://code.dlang.org/api/packages/infos?packages=%5B%22dub%22%5D_dependencies=true=true
> > | No package dub was found matching the dependency ~master
> > | autopkgtest [03:11:10]: test run: ---]
> > | autopkgtest [03:11:11]: test run:  - - - - - - - - - - results - - - - - 
> > - - - - -
> > | run  FAIL non-zero exit status 2
> >
> > See
> > https://ci.debian.net/data/autopkgtest/testing/amd64/d/dub/10040021/log.gz
> 
> Weird, I just tested this locally and it worked fine... Hopefully it's
> not another GDC issue...

Both bugs appear to be fixed with an update to 1.27.0.

> Regards,
> Matthias

cu
Adrian

Bug#996324: ruby-netcdf: FTBFS with ruby3.0: ERROR: Test "ruby3.0" failed: Segmentation fault at 0x0000000000000034

[Sergio Durigan Junior]

On Tuesday, October 12 2021, Antonio Terceiro wrote:

> We are about to enable building against ruby3.0 on unstable. During a test
> rebuild, ruby-netcdf was found to fail to build in that situation.
>
> To reproduce this locally, you need to install ruby-all-dev from experimental
> on an unstable system or build chroot.
>
> Relevant part (hopefully):
>> /usr/bin/ruby3.0 /usr/bin/gem2deb-test-runner
>> 
>> ┌──┐
>> │ Run tests for ruby3.0 from debian/ruby-test-files.yaml 
>>   │
>> └──┘
>> 
>> RUBYLIB=/<>/debian/ruby-netcdf/usr/lib/x86_64-linux-gnu/ruby/vendor_ruby/3.0.0:/<>/debian/ruby-netcdf/usr/lib/ruby/vendor_ruby:.
>>  
>> GEM_PATH=/<>/debian/ruby-netcdf/usr/share/rubygems-integration/3.0.0:/var/lib/gems/3.0.0:/usr/local/lib/ruby/gems/3.0.0:/usr/lib/ruby/gems/3.0.0:/usr/lib/x86_64-linux-gnu/ruby/gems/3.0.0:/usr/share/rubygems-integration/3.0.0:/usr/share/rubygems-integration/all:/usr/lib/x86_64-linux-gnu/rubygems-integration/3.0.0
>>  ruby3.0 -ryaml -e YAML.load_file\(\"debian/ruby-test-files.yaml\"\).each\ 
>> \{\ \|f\|\ require\ f\ \}
>> Loaded suite -e
>> Started
>> 
>> Finished in 0.028058613 seconds.
>> ---
>> 20 tests, 127 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 
>> notifications
>> 100% passed
>> ---
>> 712.79 tests/s, 4526.24 assertions/s-e: [BUG] Segmentation fault at 
>> 0x0034
>> ruby 3.0.2p107 (2021-07-07 revision 0db68f0233) [x86_64-linux-gnu]
>> 
>> -- Control frame information ---
>> c:0001 p: s:0003 E:001f10 (none) [FINISH]
>> 
>> 
>> -- Machine register context 
>>  RIP: 0x0034 RBP: 0x5644105564a0 RSP: 0x7ffc66891258
>>  RAX: 0x0034 RBX: 0x564410569488 RCX: 0x0001
>>  RDX: 0x564410569b18 RDI: 0x0034 RSI: 0x7ffc66891278
>>   R8: 0x564410569780  R9: 0x0001 R10: 0x7ffc668911e0
>>  R11: 0x0246 R12: 0x564410568000 R13: 0x564410564a30
>>  R14: 0x564410569488 R15: 0x56440ff00760 EFL: 0x00010202
>> 
>> -- C level backtrace information ---
>> ERROR: Test "ruby3.0" failed.

I spent some time investigating this one, here are my findings.

- The exact test that triggers this problem is test/clone.rb.

- It seems that this bug is at least somewhat related to the following
  Ruby upstream PR:

https://github.com/ruby/ruby/pull/5012

- Unfortunately, even after building a new version of Ruby using the
  patches available in the PR above I still managed to reproduce the
  bug.

- I found myself getting deeper and deeper into the rabbit hole here,
  debugging the Ruby interpreted with GDB and trying to understand its
  internals, when I decided it was time to stop because I had other
  things on my TODO list.

- The netcdf upstream project seems to be inactive, to say the least.
  The last release happened in 2015, and I could not find a git
  repository for it.


Having said all that, I am inclined to say that this package
could/should be removed from Debian if it causes delays in the Ruby 3.0
transition.  As a side note, I think it would also be interesting to
leave a comment on the Ruby upstream PR mentioned above saying that this
specific test causes Ruby to segfault even with the patches applied.  I
will see about doing that later.

Thanks,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
https://sergiodj.net/


signature.asc
Description: PGP signature

Bug#994910: tripwire segfaults while reading files in /etc

[Adrian Bunk]

Control: severity -1 important

On Wed, Sep 22, 2021 at 08:06:31PM -0400, Ron Murray wrote:
> Package: tripwire
> Version: 2.4.3.7-3+b3
> Severity: grave
> Justification: renders package unusable
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> Dear Maintainer,
> 
> I've been using tripwire for several years now, and never had troubles
> with it until this morning (perhaps [not] coincidentally with the
> updated glibc6).
> 
> Now it segfaults a short time after starting. An strace of it comes
> out something like this at the end:
> 
>   openat(AT_FDCWD, "/etc/nsswitch.conf", O_RDONLY|O_CLOEXEC) = 3
>...

For glibc 2.32 this has already been workarounded with the 2.4.3.7-3+b4 
binNMU, but should be properly sorted out for bookworm.

cu
Adrian

Bug#990789: LERC compression in TIFF

[GCS]

Hi Antonio,

On Fri, Nov 5, 2021 at 8:33 AM Antonio Valentino
 wrote:
> On Fri, 15 Oct 2021 21:43:13 +0200
> =?UTF-8?B?TMOhc3psw7MgQsO2c3rDtnJtw6lueWkgKEdDUyk=?=  wrote:
> >  I would be very impressed if you can do it with a patch only.
>
> OK, now the package for liblerc is in the new queue.
> I suspect it will take some time to be accepted because the queue is
> quite long in this moment.
 I think two or three weeks, but probably not more.

> Do you see any other issue?
 You upload it to experimental and not Sid. You will need another
upload. But then, I think it will be fine.

Regards,
Laszlo/GCS

Bug#984372: tripwire: diff for NMU version 2.4.3.7-3.1

[Adrian Bunk]

Control: tags 984372 + patch
Control: tags 984372 + pending

Dear maintainer,

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

cu
Adrian
diff -Nru tripwire-2.4.3.7/debian/changelog tripwire-2.4.3.7/debian/changelog
--- tripwire-2.4.3.7/debian/changelog	2020-04-24 11:05:17.0 +0300
+++ tripwire-2.4.3.7/debian/changelog	2021-11-05 21:18:03.0 +0200
@@ -1,3 +1,11 @@
+tripwire (2.4.3.7-3.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Build with -std=gnu++14 to workaround FTBFS with gcc 11.
+(Closes: #984372)
+
+ -- Adrian Bunk   Fri, 05 Nov 2021 21:18:03 +0200
+
 tripwire (2.4.3.7-3) unstable; urgency=medium
 
   * debian/rules: Change libgcc1 to libgcc-s1 in Build-Using.
diff -Nru tripwire-2.4.3.7/debian/rules tripwire-2.4.3.7/debian/rules
--- tripwire-2.4.3.7/debian/rules	2020-04-24 11:05:05.0 +0300
+++ tripwire-2.4.3.7/debian/rules	2021-11-05 21:18:03.0 +0200
@@ -19,6 +19,8 @@
 	INSTALL_PROGRAM += -s
 endif
 
+export DEB_CXXFLAGS_MAINT_APPEND += -std=gnu++14
+
 config.status: $(QUILT_STAMPFN)
 	dh_testdir
 	dh_update_autotools_config

Bug#996866: cyrus-sasl2: Reconsider package license

[Bastian Germann]

On Tue, 19 Oct 2021 23:41:52 +0200 Bastian Germann wrote:
Please reconsider the package license, at least for the patches. Currently you have 
debian/* licensed under GPL-3+, which means that all the debian/patches/* files are 
GPL-3+. This has two problems:


1) cyrus-sasl2 is a basic package that is used by many packages that might not expect to 
have GPL-3+ in their dependency trees. Especially GPL-2-only licensed packages are not 
compatible with GPL-3+.


2) Supposedly, GPL (any version) itself is incompatible with the advertisement clause in 
BSD-4-clause. While the University of California has issued an official statement that 
this clause can be ignored for their software, I do not know of any such statement from 
Carnegie Mellon University. So it should be fairly controversial if Debian's patched 
cyrus-sasl2 binaries are legally distributable.


Hi Ondřej,

From the git history I can see that you introduced a license change from "GPL-2+ or 
BSD-2-clause"
to GPL-3+, which causes this problem. I have looked at every patch provenance 
and most of the
patches were already contained at the time of the change. The ones that were 
not there are mostly
upstream patches except two of them. One could be eliminated. This leaves us 
with BSD-2-clause
licensed patches with the exception of 
0017-Just-completely-remove-libobj-from-autotools-files.patch
by you. Would you be so kind to relicense this via deleting it from 
debian/copyright?

Thanks,
Bastian

Bug#998223: RFH: mailman3 packages -- Mailing list management system

[Amir Sarabadani]

Hi,
I'm co-maintaining the mailman3 install with Kunal in Wikimedia. I
would be more than happy to help with future packaging too.

Best

Bug#998625: python-spinners: diff for NMU version 0.0~git20200220.a73d561-1.1

[Stefano Rivera]

Control: tags 998625 + pending

Dear maintainer,

I've prepared an NMU for python-spinners (versioned as 
0.0~git20200220.a73d561-1.1) and
uploaded it to DELAYED/10. Please feel free to tell me if I
should delay it longer.

Regards.

SR
diff -Nru python-spinners-0.0~git20200220.a73d561/debian/changelog python-spinners-0.0~git20200220.a73d561/debian/changelog
--- python-spinners-0.0~git20200220.a73d561/debian/changelog	2021-08-23 21:18:47.0 -0700
+++ python-spinners-0.0~git20200220.a73d561/debian/changelog	2021-11-05 12:13:21.0 -0700
@@ -1,3 +1,12 @@
+python-spinners (0.0~git20200220.a73d561-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop tox Build-Dep, we're doing build-time tests without it, fixes FTBFS
+with dh-python >= 5.20211105. (Closes: #998625)
+  * Add missing Build-Depends on python3-setuptools.
+
+ -- Stefano Rivera   Fri, 05 Nov 2021 12:13:21 -0700
+
 python-spinners (0.0~git20200220.a73d561-1) unstable; urgency=low
 
   * Initial release. (Closes: #992992)
diff -Nru python-spinners-0.0~git20200220.a73d561/debian/control python-spinners-0.0~git20200220.a73d561/debian/control
--- python-spinners-0.0~git20200220.a73d561/debian/control	2021-08-23 21:18:47.0 -0700
+++ python-spinners-0.0~git20200220.a73d561/debian/control	2021-11-05 01:10:31.0 -0700
@@ -7,7 +7,7 @@
 	python3-all,
 	python3-coverage,
 	python3-nose,
-	tox
+	python3-setuptools,
 Standards-Version: 4.5.1
 Rules-Requires-Root: no
 Homepage: https://github.com/manrajgrover/py-spinners

Bug#998623: pysha3: diff for NMU version 1.0.2-4.2

[Stefano Rivera]

Control: tags 998623 + pending

Dear maintainer,

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

Regards.

SR
diff -Nru pysha3-1.0.2/debian/changelog pysha3-1.0.2/debian/changelog
--- pysha3-1.0.2/debian/changelog	2020-03-28 13:18:51.0 -0700
+++ pysha3-1.0.2/debian/changelog	2021-11-05 12:14:01.0 -0700
@@ -1,3 +1,11 @@
+pysha3 (1.0.2-4.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop tox Build-Dep, we're doing build-time tests without it, fixes FTBFS
+with dh-python >= 5.20211105 (Closes: #998623).
+
+ -- Stefano Rivera   Fri, 05 Nov 2021 12:14:01 -0700
+
 pysha3 (1.0.2-4.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru pysha3-1.0.2/debian/control pysha3-1.0.2/debian/control
--- pysha3-1.0.2/debian/control	2020-01-19 01:43:49.0 -0800
+++ pysha3-1.0.2/debian/control	2021-11-05 00:54:52.0 -0700
@@ -3,7 +3,6 @@
 Section: python
 Priority: optional
 Build-Depends:
-tox,
 python3-flake8,
 python3-setuptools,
 dh-python,

Bug#998659: RM: residualvm -- ROM; Obsolete, merged into src:scummvm

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: only...@debian.org

Please remove residualvm. It got merged into ScummVM 2.5.0, which
is now in unstable: https://www.scummvm.org/news/20211009/

Removal also acked by Dmitry (CCed)

Cheers,
Moritz

Bug#998658: janus: Remove hard-coded Recommends: on obsolete runtime library

[Steve Langasek]

Package: janus
Version: 0.11.2-1
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu jammy ubuntu-patch

Dear maintainers,

The janus package has a hard-coded versioned Recommends: on libusrsctp1. 
This binary package is now obsolete, however, having been replaced by
libusrsctp2.  As a result, janus now has a Depends: on libusrsctp2 and a
Recommends: on libusrsctp1, which will keep an obsolete package on users'
systems after upgrade.

Please drop this obsolete recommends, as in the attached patch.

Thanks,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru janus-0.11.2/debian/control janus-0.11.2/debian/control
--- janus-0.11.2/debian/control 2021-04-22 06:03:08.0 -0700
+++ janus-0.11.2/debian/control 2021-11-05 11:34:09.0 -0700
@@ -56,7 +56,6 @@
  ${shlibs:Depends},
 Recommends:
  libnice10 (>= 0.1.16),
- libusrsctp1 (>= 0.9.3.0+20200406),
  lua-ansicolors,
  lua-json,
  ssl-cert,

Bug#998657: tpm2-abrmd: tpm daemon do not run and often breaks at startup

[alain]

Package: tpm2-abrmd
Version: 2.4.0-1
Severity: normal
Tags: upstream
X-Debbugs-Cc: compte.perso.de-al...@bbox.fr

Dear Maintainer,

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

   * What led up to the situation?
installation of tpm2-abrmd
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
tpm2-abrmd installed .

alain@sid:~$ apt policy tpm2-abrmd
tpm2-abrmd:
  Installé : 2.4.0-1
  Candidat : 2.4.0-1
 Table de version :
 *** 2.4.0-1 500
100 https://deb.debian.org/debian testing/main amd64 Packages
500 https://deb.debian.org/debian unstable/main amd64 Packages
100 /var/lib/dpkg/status
 2.3.3-1+b2 100
100 http://deb.debian.org/debian stable/main amd64 Packages

systemctl enable tpm2-abrmd

Synchronizing state of tpm2-abrmd.service with SysV service script with
/lib/systemd/systemd-sysv-install.
Executing: /lib/systemd/systemd-sysv-install enable tpm2-abrmd

reboot

   * What was the outcome of this action?

at startup :

sudo systemctl status tpm2-abrmd

○ tpm2-abrmd.service - TPM2 Access Broker and Resource Management Daemon
 Loaded: loaded (/lib/systemd/system/tpm2-abrmd.service; disabled; vendor
preset: enabled)
 Active: inactive (dead)

nov. 04 11:17:44 sid systemd[1]: Dependency failed for TPM2 Access Broker and
Resource Management Daemon.
nov. 04 11:17:44 sid systemd[1]: tpm2-abrmd.service: Job
tpm2-abrmd.service/start failed with result 'dependency'.

   * What outcome did you expect instead?

I was hoping that the TPM2 daemon would work and not make any error.
But this is not the case.
it slows down, even prevents my startup.

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


So, as it is not ready and causes me trouble, I remove it.

alain@sid:~$ apt policy tpm2-abrmd
tpm2-abrmd:
  Installé : (aucun)
  Candidat : 2.4.0-1
 Table de version :
 2.4.0-1 500
100 https://deb.debian.org/debian testing/main amd64 Packages
500 https://deb.debian.org/debian unstable/main amd64 Packages
 2.3.3-1+b2 100
100 http://deb.debian.org/debian stable/main amd64 Packages




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

Kernel: Linux 5.14.0-4-amd64 (SMP w/24 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 /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages tpm2-abrmd depends on:
ii  init-system-helpers  1.60
ii  libc62.32-4
ii  libglib2.0-0 2.70.0-3
ii  libtss2-mu0  3.1.0-3
ii  libtss2-rc0  3.1.0-3
ii  libtss2-sys1 3.1.0-3
ii  libtss2-tctildr0 3.1.0-3

tpm2-abrmd recommends no packages.

tpm2-abrmd suggests no packages.

-- debconf-show failed

Bug#998567: qgis: FTBFS: sip: /usr/lib/python3/dist-packages/PyQt5/bindings/QtCore/QtCoremod.sip:23: syntax error

[Sebastiaan Couwenberg]

Control: tags -1 upstream

On 11/4/21 20:49, Lucas Nussbaum wrote:

sip: /usr/lib/python3/dist-packages/PyQt5/bindings/QtCore/QtCoremod.sip:23: 
syntax error


This seems to be caused by the recent switch to sip6 in pyqt5.

Upstream recently added support for sip6 in their non-LTR, but those 
changes aren't enough for build 3.16.x successfully with sip6:


 Querying qmake about your Qt installation...
 These bindings will be built: analysis.
 Generating the analysis bindings...
 sip-build: Unable to find file "QtCore/QtCoremod.sip"

 ...

 Querying qmake about your Qt installation...
 These bindings will be built: 3d.
 Generating the 3d bindings...
 sip-build: Unable to find file "QtXml/QtXmlmod.sip"

These files are provided by pyqt5-dev under
/usr/lib/python3/dist-packages/PyQt5/bindings/ but not found for some 
reason.


We may have to wait for the QGIS 3.22.4 LTR in February to be able to 
build successfully with sip6.


Dmitry, do you have any suggestion how to fix the sip6 support in qgis?

Kind Regards,

Bas

--
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Bug#950174: gvfs-daemons: I am seeing this bug in gvfs 1.46.2-1

[James R Phillips]

Package: gvfs-daemons
Version: 1.46.2-1
Followup-For: Bug #950174
X-Debbugs-Cc: phill...@adi.com

Dear Maintainer,

   * What led up to the situation?

I experience 30 second startup delays for file browsing in Thunar. This occurs 
the first time a file-browsing dialog box is opened in most applications. 
Thereafter it does not re-occur, unless the application is terminated and 
restarted.

The problem is traced via ~/.xsession-errors to a timeout of 
org.gtk.vfs.UDisks2VolumeMonitor.

$ systemctl --user status gvfs-udisks2-volume-monitor.service

shows in part

Nov 05 13:25:47 escolar1 systemd[1200]: Starting Virtual filesystem service - 
disk device monitor...
Nov 05 13:25:47 escolar1 gvfs-udisks2-vo[4978]: No GSettings schemas are 
installed on the system
Nov 05 13:25:47 escolar1 systemd[1200]: gvfs-udisks2-volume-monitor.service: 
Main process exited, code=killed


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

Renaming the compiled schemas and reinstalling gsettings-desktop-schemas 
recreates the compiled schemas exactly, but does not resolve the bug.

Uninstalling all gvfs-related packages does remove the thunar startup delay, 
but removes desired functionality as well. Reinstalling the packages restores 
functionality but the startup-delays recur.


-- System Information:
Debian Release: 11.1
  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-9-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages gvfs-daemons depends on:
ii  gvfs-common 1.46.2-1
ii  gvfs-libs   1.46.2-1
ii  libbluray2  1:1.2.1-4+deb11u1
ii  libc6   2.31-13+deb11u2
ii  libglib2.0-02.66.8-1
ii  libgudev-1.0-0  234-1
ii  libsecret-1-0   0.20.4-2
ii  libsystemd0 247.3-6
ii  libudisks2-02.9.2-2
ii  lsof4.93.2+dfsg-1.1
ii  udisks2 2.9.2-2

Versions of packages gvfs-daemons recommends:
ii  dbus  1.12.20-2
ii  gvfs  1.46.2-1

Versions of packages gvfs-daemons suggests:
ii  gvfs-backends  1.46.2-1

-- no debconf information

Bug#994064: python3-dnspython and eventlet incompatibility

[Thomas Goirand]

On 11/5/21 2:02 PM, Arnaud Morin wrote:
> Hey team,
> I am working on installing openstack neutron from openstack victoria
> extrepo.
> 
> In my neutron config, I am setting transport-url with a fqdn, e.g.:
> transport_url = rabbit://user:p...@rabbit.arnaudmorin.fr:5672
> 
> But, this is not working, due to a bug between eventlet (which seems to
> be used by neutron) and dnspython (see [1] and [2])
> 
> I have two possible workarounds:
> * using an IP instead of FQDN
> * downgrading dnspython to <2.0.0 (1.16.0)
> 
> I also tested the latest eventlet, but it seems too new for neutron
> victoria.
> 
> I havn't tested xena, but if it's relying on the same python
> dependencies, it will also fail.
> 
> What is the recommendation from the community about this?
> Should I report this as a bug? (If so, I dont remember where, so I'd
> appreciate a hint :))
> 
> Cheers, Arnaud.
> 
> [1] https://github.com/eventlet/eventlet/issues/629
> [2] https://github.com/eventlet/eventlet/issues/619

Hi Arnaud,

It is well known that there is an issue with Eventlet as in Bullseye,
and dnspython 2.0. However, we have a patch for it. I opened a release
team bug in the hope they accept the package, but so far, they haven't
replied to me. Please read this bug report:

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

I am hereby CC-ing the bug, so that the release team sees it really
affects Debian users.

In advance of the release team acceptance, I have just dropped (a few
minutes ago) the patched package as it will be uploaded when the stable
release team accepts it:

http://bullseye-victoria.debian.net/debian/pool/bullseye-victoria-backports-nochange/main/p/python-eventlet/

Pleaese try it, and let me know if it solves your troubles.

If it doesn't, there's still a workaround: write in /etc/hosts all of
the entries you need, like the entry for rabbit.arnaudmorin.fr as per
your transport_url directive. This way, Neutron will not use the
Eventlet greendns function (or at least, it will not use dnspython to
resolve).

Please really let me know (and the Debian bug) if the patched Eventlet
fixes your trouble first though, as I didn't have the issue (because my
setup always write all the cluster nodes in /etc/hosts), and I need to
know if that fixes it.

Cheers,

Thomas Goirand (zigo)

Bug#998654: libtpms: Add a simple autopkgtest

[Steve Langasek]

Package: libtpms
Version: 0.8.2-1
Severity: wishlist
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu jammy ubuntu-patch

Hi Seunghun,

We are including libtpms in Ubuntu main (for TPM support in VMs), and as
part of that promotion process we try to cover as many packages as possible
with autopkgtests.

Attached is an implementation of a simple autopkgtest, that provides some
assurance of ongoing functionality of libtpms.  Unfortunately due to the
general structure of automake-driven testing this test rebuilds the library
and runs tests against the new binaries, not against the .debs from the
archive; but this is arguably better than nothing.

Thanks for considering,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru libtpms-0.9.0/debian/tests/control libtpms-0.9.0/debian/tests/control
--- libtpms-0.9.0/debian/tests/control  1969-12-31 16:00:00.0 -0800
+++ libtpms-0.9.0/debian/tests/control  2021-11-05 09:10:26.0 -0700
@@ -0,0 +1,2 @@
+Tests: run-tests
+Depends: @, @builddeps@
diff -Nru libtpms-0.9.0/debian/tests/run-tests 
libtpms-0.9.0/debian/tests/run-tests
--- libtpms-0.9.0/debian/tests/run-tests1969-12-31 16:00:00.0 
-0800
+++ libtpms-0.9.0/debian/tests/run-tests2021-11-05 09:10:09.0 
-0700
@@ -0,0 +1,8 @@
+#!/bin/sh
+
+set -e
+
+dh_autoreconf 2>/dev/null
+./debian/rules override_dh_auto_configure
+
+make check VERBOSE=1

Bug#994257: django-ldapdb: diff for NMU version 1.5.1-2.1

[Adrian Bunk]

Control: tags 994257 + patch
Control: tags 994257 + pending

Dear maintainer,

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

cu
Adrian
diff -Nru django-ldapdb-1.5.1/debian/changelog django-ldapdb-1.5.1/debian/changelog
--- django-ldapdb-1.5.1/debian/changelog	2020-10-25 21:43:12.0 +0200
+++ django-ldapdb-1.5.1/debian/changelog	2021-11-05 18:59:37.0 +0200
@@ -1,3 +1,10 @@
+django-ldapdb (1.5.1-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Add upstream patches for Django 3.2 support. (Closes: #994257)
+
+ -- Adrian Bunk   Fri, 05 Nov 2021 18:59:37 +0200
+
 django-ldapdb (1.5.1-2) unstable; urgency=medium
 
   * Run manage_dev.py for CI tests (Closes: #972874).
diff -Nru django-ldapdb-1.5.1/debian/patches/0001-Use-get_attname-instead-of-attname-attribute.patch django-ldapdb-1.5.1/debian/patches/0001-Use-get_attname-instead-of-attname-attribute.patch
--- django-ldapdb-1.5.1/debian/patches/0001-Use-get_attname-instead-of-attname-attribute.patch	1970-01-01 02:00:00.0 +0200
+++ django-ldapdb-1.5.1/debian/patches/0001-Use-get_attname-instead-of-attname-attribute.patch	2021-11-05 18:56:58.0 +0200
@@ -0,0 +1,48 @@
+From 88366f356e4569a0cb9a768ccec1b544ef0d66ee Mon Sep 17 00:00:00 2001
+From: dzen 
+Date: Tue, 13 Apr 2021 16:46:32 +0200
+Subject: Use get_attname instead of attname attribute
+
+---
+ ldapdb/backends/ldap/compiler.py | 4 ++--
+ ldapdb/models/base.py| 2 +-
+ 2 files changed, 3 insertions(+), 3 deletions(-)
+
+diff --git a/ldapdb/backends/ldap/compiler.py b/ldapdb/backends/ldap/compiler.py
+index 4ce9f94..1d9e771 100644
+--- a/ldapdb/backends/ldap/compiler.py
 b/ldapdb/backends/ldap/compiler.py
+@@ -231,7 +231,7 @@ class SQLCompiler(compiler.SQLCompiler):
+ if isinstance(e[0], aggregates.Count):
+ value = 0
+ input_field = e[0].get_source_expressions()[0].field
+-if input_field.attname == 'dn':
++if input_field.get_attname() == 'dn':
+ value = 1
+ elif hasattr(input_field, 'from_ldap'):
+ result = input_field.from_ldap(
+@@ -243,7 +243,7 @@ class SQLCompiler(compiler.SQLCompiler):
+ value = len(result)
+ row.append(value)
+ else:
+-if e[0].field.attname == 'dn':
++if e[0].field.get_attname() == 'dn':
+ row.append(dn)
+ elif hasattr(e[0].field, 'from_ldap'):
+ row.append(e[0].field.from_ldap(
+diff --git a/ldapdb/models/base.py b/ldapdb/models/base.py
+index e4d9e15..18d3d1e 100644
+--- a/ldapdb/models/base.py
 b/ldapdb/models/base.py
+@@ -83,7 +83,7 @@ class Model(django.db.models.base.Model):
+ ]
+ 
+ def get_field_value(field, instance):
+-python_value = getattr(instance, field.attname)
++python_value = getattr(instance, field.get_attname())
+ return field.get_db_prep_save(python_value, connection=connection)
+ 
+ if create:
+-- 
+2.20.1
+
diff -Nru django-ldapdb-1.5.1/debian/patches/0002-tests-add-missing-contribute_to_class-to-fully-insta.patch django-ldapdb-1.5.1/debian/patches/0002-tests-add-missing-contribute_to_class-to-fully-insta.patch
--- django-ldapdb-1.5.1/debian/patches/0002-tests-add-missing-contribute_to_class-to-fully-insta.patch	1970-01-01 02:00:00.0 +0200
+++ django-ldapdb-1.5.1/debian/patches/0002-tests-add-missing-contribute_to_class-to-fully-insta.patch	2021-11-05 18:56:58.0 +0200
@@ -0,0 +1,24 @@
+From 17d807ef5259838ea0b1b2db0382963a94296bee Mon Sep 17 00:00:00 2001
+From: dzen 
+Date: Tue, 13 Apr 2021 16:47:00 +0200
+Subject: tests: add missing contribute_to_class to fully instanciate the field
+
+---
+ ldapdb/tests.py | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/ldapdb/tests.py b/ldapdb/tests.py
+index f2da2d4..2aca0a0 100644
+--- a/ldapdb/tests.py
 b/ldapdb/tests.py
+@@ -82,6 +82,7 @@ class WhereTestCase(TestCase):
+ def _build_lookup(self, field_name, lookup, value, field=fields.CharField):
+ fake_field = field()
+ fake_field.set_attributes_from_name(field_name)
++fake_field.contribute_to_class(FakeModel, "fake")
+ lhs = expressions.Col('faketable', fake_field, fake_field)
+ lookup = lhs.get_lookup(lookup)
+ return lookup(lhs, value)
+-- 
+2.20.1
+
diff -Nru django-ldapdb-1.5.1/debian/patches/0003-Update-regex-to-be-compatible-with-django-2-to-Djang.patch django-ldapdb-1.5.1/debian/patches/0003-Update-regex-to-be-compatible-with-django-2-to-Djang.patch
--- django-ldapdb-1.5.1/debian/patches/0003-Update-regex-to-be-compatible-with-django-2-to-Djang.patch	1970-01-01 02:00:00.0 +0200
+++ 

Bug#998653: linux: Please enable ZERO_CALL_USED_REGS to reduce ROP probability

[Christoffer Jerkeby]

Source: linux
Version: 5.15-1~exp1
Severity: wishlist

Hi, the option ZERO_CALL_USED_REGS will improve kernel security by
reducing the amount of available ROP gadgets by 20% on average in
the Linux kernel. Currently the option is not enabled in Debians
experimental kernel config. Please enable it if you consider build
size to be reasonable on all architectures.

The option requires building with GCC11 or a compiler that support
-fzero-call-user-regs.

Here is a comparison between the amount of unique ROP gadgets found
compared between a kernel build without CALL_USED_REGS in two 
different ROP gadget scanning tools.

rp++ is a popular ROP scanning tool due to its ability to find many
different gadgets.

$ wc -l vmlinux-5.15-zero-regs-rp++-rop
249527 vmlinux-5.15-zero-regs-rp++-rop

$ wc -l vmlinux-5.15-skip-rp++-rop
326214 vmlinux-5.15-skip-rp++-rop

The tool ROPgadget is popular due to its ability to automatically 
build ROP chains for a statically linked target.

vmlinux-5.15-zero-regs:
Unique gadgets found: 136014
No automatic chain building possible.

vmlinux-5.15-skip:
Unique gadgets found: 214104
Automatich chain building of gadgets possible.

Thank you!

Best regards Christoffer Kugg Jerkeby

Bug#998223: RFH: mailman3 packages -- Mailing list management system

[Kunal Mehta]

Hi,

On Mon, 01 Nov 2021 10:41:54 +0100 Jonas Meurer  
wrote:



So we're looking for you if you:

* happen to run mailman3 instances and have some spare cycles
* want to give your share to keep mailman3 packages in Debian
* are keen to get your hands dirty in python packages which touch a lot
   of different packaging aspects


I co-maintain Wikimedia's Mailman3 install and have also done a bit of 
work upstream. Please let me know how I can help.


-- Kunal

Bug#998235: firefox: can not use microphone

[Tiit Pikma]

Hi

I have the same experience on firefox 94.0-1. Audio playback works fine 
before. Attempting to use the microphone fails and after that audio 
playback breaks with the browser hanging after a short while. I have 
tested on multiple computers and with multiple microphones (2 webcams 
and a headset).


Checking pulseaudio logs (attached) when creating a Google Meet meeting, 
Firefox only registers a playback stream named "AudioCallbackDriver" and 
no recording streams.


Regards
Tiit(  30.284|  24.102) I: [pulseaudio] client.c: Created 2 "Native client (UNIX 
socket client)"
(  30.284|   0.000) D: [pulseaudio] protocol-native.c: Protocol version: remote 
35, local 35
(  30.284|   0.000) I: [pulseaudio] protocol-native.c: Got credentials: 
uid=1000 gid=1000 success=1
(  30.284|   0.000) D: [pulseaudio] protocol-native.c: SHM possible: yes
(  30.284|   0.000) D: [pulseaudio] protocol-native.c: Negotiated SHM: yes
(  30.284|   0.000) D: [pulseaudio] protocol-native.c: Memfd possible: yes
(  30.284|   0.000) D: [pulseaudio] protocol-native.c: Negotiated SHM type: 
shared memfd
(  30.284|   0.000) D: [pulseaudio] memblock.c: Using shared memfd memory pool 
with 1024 slots of size 64.0 KiB each, total size is 64.0 MiB, maximum usable 
slot size is 65472
(  30.284|   0.000) D: [pulseaudio] srbchannel.c: SHM block is 65472 bytes, 
ringbuffer capacity is 2 * 32712 bytes
(  30.284|   0.000) D: [pulseaudio] protocol-native.c: Enabling srbchannel...
(  30.284|   0.000) D: [pulseaudio] module-augment-properties.c: Looking for 
.desktop file for firefox
(  30.284|   0.000) D: [pulseaudio] module-augment-properties.c: Found 
/usr/share//applications/firefox.desktop.
(  30.284|   0.000) D: [pulseaudio] conf-parser.c: Parsing configuration file 
'/usr/share//applications/firefox.desktop'
(  30.285|   0.000) D: [pulseaudio] protocol-native.c: Client enabled 
srbchannel.
(  37.076|   6.790) D: [pulseaudio] module-intended-roles.c: Not setting device 
for stream AudioCallbackDriver, because it lacks role.
(  37.076|   0.000) D: [pulseaudio] sink-input.c: Negotiated format: pcm, 
format.sample_format = "\"float32le\""  format.rate = "44100"  format.channels 
= "2"  format.channel_map = "\"front-left,front-right\""
(  37.076|   0.000) I: [pulseaudio] sink-input.c: Trying to change sample spec
(  37.076|   0.000) I: [pulseaudio] module-stream-restore.c: Restoring volume 
for sink input sink-input-by-application-name:Firefox.
(  37.076|   0.000) D: [pulseaudio] module-suspend-on-idle.c: Sink 
alsa_output.usb-SteelSeries_SteelSeries_Arctis_7-00.stereo-game becomes busy, 
resuming.
(  37.076|   0.000) I: [alsa-sink-USB Audio] alsa-sink.c: Trying resume...
(  37.076|   0.000) I: [alsa-sink-USB Audio] alsa-util.c: Cannot disable ALSA 
period wakeups
(  37.076|   0.000) D: [alsa-sink-USB Audio] alsa-util.c: Maximum hw buffer 
size is 5944 ms
(  37.084|   0.007) D: [alsa-sink-USB Audio] alsa-util.c: Set buffer size first 
(to 88200 samples), period size second (to 44100 samples).
(  37.084|   0.000) I: [alsa-sink-USB Audio] alsa-util.c: ALSA period wakeups 
were not disabled
(  37.084|   0.000) D: [alsa-sink-USB Audio] alsa-sink.c: hwbuf_unused=0
(  37.084|   0.000) D: [alsa-sink-USB Audio] alsa-sink.c: setting 
avail_min=87319
(  37.084|   0.000) I: [alsa-sink-USB Audio] alsa-sink.c: Time scheduling 
watermark is 20.00ms
(  37.084|   0.000) I: [alsa-sink-USB Audio] alsa-sink.c: Resumed 
successfully...
(  37.084|   0.000) D: [pulseaudio] sink.c: 
alsa_output.usb-SteelSeries_SteelSeries_Arctis_7-00.stereo-game: suspend_cause: 
IDLE -> (none)
(  37.084|   0.000) D: [pulseaudio] sink.c: 
alsa_output.usb-SteelSeries_SteelSeries_Arctis_7-00.stereo-game: state: 
SUSPENDED -> IDLE
(  37.084|   0.000) D: [pulseaudio] module-suspend-on-idle.c: Sink 
alsa_output.usb-SteelSeries_SteelSeries_Arctis_7-00.stereo-game becomes idle, 
timeout in 5 seconds.
(  37.084|   0.000) I: [alsa-sink-USB Audio] alsa-sink.c: Starting playback.
(  37.084|   0.000) D: [alsa-sink-USB Audio] ratelimit.c: 1136 events suppressed
(  37.084|   0.000) D: [alsa-sink-USB Audio] alsa-sink.c: Cutting sleep time 
for the initial iterations by half.
(  37.084|   0.000) D: [alsa-sink-USB Audio] alsa-sink.c: Cutting sleep time 
for the initial iterations by half.
(  37.084|   0.000) D: [pulseaudio] source.c: 
alsa_output.usb-SteelSeries_SteelSeries_Arctis_7-00.stereo-game.monitor: 
suspend_cause: IDLE -> (none)
(  37.084|   0.000) D: [pulseaudio] source.c: 
alsa_output.usb-SteelSeries_SteelSeries_Arctis_7-00.stereo-game.monitor: state: 
SUSPENDED -> IDLE
(  37.084|   0.000) D: [pulseaudio] module-suspend-on-idle.c: Sink 
alsa_output.usb-SteelSeries_SteelSeries_Arctis_7-00.stereo-game becomes idle, 
timeout in 5 seconds.
(  37.084|   0.000) I: [pulseaudio] resampler.c: Forcing resampler 'copy', 
because of fixed, identical sample rates.
(  37.084|   0.000) D: [pulseaudio] resampler.c: Resampler:
(  37.084|   0.000) D: [pulseaudio] resampler.c:   rate 44100 -> 44100 (method 

Bug#996668: cinnamon-settings-daemon: cinnamon shutdown hang

[Alex Andreotti]

On Sun, Oct 31, 2021 at 12:28:03PM +0100, Fabio Fantoni wrote:
> Il 31/10/2021 10:02, Alex Andreotti ha scritto:

> Sorry if I don't replied before, I'm unable to reproduce the issue on my Sid
> environment, unfortunately recently I am also very busy and I am used the
> little time to the tests instead on the big muffin rebase they are doing
> upstream for cinnamon 5.2.
> 
> As soon as I have time in these days I will try to prepare the new build
> with latest upstream bugfixes to upload and doing more tests.
> 
> About your environments you had some applet,extension, desklet added (not
> installed by default) and enabled? if yes can you try to disable them, and
> after reboot the shutdown still have the same issue? without being able to
> reproduce the problem unfortunately I can not try to debug to try to see
> what it cause freeze/hang the cinnamon process on shutdown.
> 

Sorry for the late reply too, my gmail occasionally flags Debian
emails as spam ... I just happened to see it today.

I don't have custom applets, I just added a couple of auto starts, I
tried to disable them but nothing changes.

It's not a big deal, I don't reboot often, it's just a little annoying
because when I do it's because I need it.

It would be useful to have a more precise message, I can try to take a
look, if you have suggestions where to look are welcome.

Thanks for the work you do.

Bug#994419: fixed in googletest 1.11.0-2

[Timo Röhling]

Hi Steve,

On Sun, 19 Sep 2021 19:20:43 + Debian FTP Masters 
 wrote:

 googletest (1.11.0-2) unstable; urgency=medium
 .
   [ Timo Röhling ]
   * [d803038] Separate GTest and GMock targets in CMake (Closes: #994419)
 .

Shouldn't we also fix this in Bullseye via stable-updates?

Cheers
Timo

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


signature.asc
Description: PGP signature

Bug#998652: ITP: golang-github-juju-collections -- Deque and set implementations

[Mathias Gibbens]

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

* Package name: golang-github-juju-collections
  Version : 0.0~git20200605.0d0ec82-1
  Upstream Author : Canonical Ltd
* URL : https://github.com/juju/collections
* License : LGPL-3.0-with-exception
  Programming Lang: Go
  Description : Deque and set implementations

 Set and deque implementations for Go.

This ITP reintroduces the golang-github-juju-collections package to the
archive. It was previously RM'ed in #951790 as no packages depended on
it.

This package is a dependency for updating golang-github-juju-utils as
part of the process of packaging LXD (ITP #768073).

This package will be team-maintained within the Debian Go Packaging
Team.


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

Bug#998433: Acknowledgement ([INTL:sv] Swedish strings for mrtg debconf)

[Eriberto]

Em sex., 5 de nov. de 2021 às 05:42, Martin Bagge / brother
 escreveu:
>
> On 2021-11-04 09:06, Debian Bug Tracking System wrote:
> > Thank you for filing a new Bug report with Debian.
>
> Found a spelling mistake in the last chunk. Attaching an updated version.
>
> Thnx Anders.
>
> --
> brother

Hi Martin,

This bug was already closed. Could you open a new bug in BTS to send
this new translation?

Thanks.

Eriberto

Bug#998651: ITP: node-oauth-1.0a -- OAuth 1.0a request authorization

[Andrius Merkys]

Package: wnpp
Owner: Andrius Merkys 
Severity: wishlist
Control: block 998392 by -1

* Package name: node-oauth-1.0a
  Version : 2.2.6
  Upstream Author : Ddo
* URL : https://github.com/ddo/oauth-1.0a#readme
* License : Expat
  Programming Lang: JavaScript
  Description : OAuth 1.0a request authorization

OAuth 1.0a request authorization for Node and browser. Encapsulates
OAuth request sending with an HTTP client (request, jQuery.ajax and so on).

node-oauth-1.0a is required by node-wikibase-edit.

Remark: This package is to be maintained with Debian Javascript
Maintainers at
   https://salsa.debian.org/js-team/node-oauth-1.0a

Bug#996670: Enable compositor on startup switched off

[Oliver Sander]

>> But I guess you had, or some cosmic radiation induced bit switch did it
>> for you on your hard disk ;-) The default for all installations is being
>> on.

> yeah, then lets say "maybe" or "probably" I did that, nevertheless, at least 
it was a couple of years ago and I cannot remeber ;-)

This sounds familiar.  Wasn't "Enable compositor..." being disabled also
the cause of this week's #998216 ?

And I checked: On my system the setting is also disabled, with me not
remembering ever having disabled it.  My original installation happened
many years ago.  Did the default maybe change afterwards?

Best,
Oliver



smime.p7s
Description: S/MIME Cryptographic Signature

Bug#998650: ddclient: extra quotes in init.d script

[Alexander Galanin]

Package: ddclient
Version: 3.9.1-7
Severity: important
Tags: patch
X-Debbugs-Cc: a...@galanin.nnov.ru

Extra quotes in init.d script causes error on start on sysvinit systems.

Obvious fix:

diff -r 228a6baafddc init.d/ddclient
--- a/init.d/ddclient   Fri Nov 05 18:03:46 2021 +0300
+++ b/init.d/ddclient   Fri Nov 05 18:07:33 2021 +0300
@@ -53,7 +53,7 @@

   start-stop-daemon --start \
 --pidfile "$PIDFILE" --exec "$PERL" --startas "$DAEMON" \
--- "$OPTIONS" \
+-- $OPTIONS \
 || return 2
 }

-- System Information:
Debian Release: 11.1
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'stable-updates')
Architecture: armhf (armv7l)

Kernel: Linux 5.10.0-9-armmp (SMP w/2 CPU threads)
Kernel taint flags: TAINT_UNSIGNED_MODULE
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages ddclient depends on:
ii  debconf [debconf-2.0] 1.5.77
ii  init-system-helpers   1.60
ii  libdata-validate-ip-perl  0.30-1
ii  lsb-base  11.1.0
ii  perl  5.32.1-4+deb11u2

Versions of packages ddclient recommends:
pn  libdigest-sha-perl   
pn  libio-socket-inet6-perl  
ii  libio-socket-ssl-perl2.069-1
ii  perl [libjson-pp-perl]   5.32.1-4+deb11u2

ddclient suggests no packages.

-- Configuration Files:
/etc/init.d/ddclient changed [not included]

-- debconf information excluded

Bug#998515: arpwatch generates malformed emails.

[Lukas Schwaighofer]

Thanks for providing the details!  Unfortunately I still don't have a
good idea of what could be causing the broken/truncated mails you're
seeing.  I have a very similar setup and things are working fine here.


The way arpwatch creates and sends reports is roughly as follows:

* Create a temporary file in /tmp, immediately unlink it (but keep the
  file descriptor open).
* Write the report to that file descriptor.  The report has all the
  headers first, followed by two newlines and finally the body.
* Once finished writing the report, seek the file descriptor back to
  position 0, launch sendmail and pass the file descriptor to it as
  standard input.


Looking at the broken e-mails you attached, it appears that sendmail
doesn't receive the complete content of the report but it starts at
some offset (not always exactly the same).  I'm not yet sure how that
can happen.

Can you check that your filesystem in /tmp isn't (almost) full?  Also
make sure no other filesystem is (almost) full (I believe postfix
spools e-mails to somewhere in /var).


If that doesn't help, my best ideas are:

1. Launch arpwatch by hand using the `-d` flag but with otherwise same
   parameters. That should print the reports to standard error so we
   can see if those are truncated as well.

2. Write a dummy sendmail replacement that just copies the reports
   somewhere, then direct arpwatch to use that instead. Then check if
   those reports are truncated as well.

I'm happy to help with (2) if we're still uncertain after all the other
steps.

Thanks & regards
Lukas

Bug#998649: wsjtx: new upstream version 2.5.2

[tony mancill]

Package: wsjtx
Version: 2.5.1+repack-1
Severity: wishlist

WSJT-X 2.5.2 is now available.

Debian package creation is in process.  This is simply a tracking bug to
prevent duplicated effort.

Bug#996781: luarocks: Installation fails with dpkg error

[Chris MacNaughton]

Package: luarocks
Version: 3.7.0+dfsg1-1
Followup-For: Bug #996781
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu jammy ubuntu-patch
Control: tags -1 patch

Dear Maintainer,

In Ubuntu, the attached patch was applied to achieve the following:

The luarocks postinst sript was updated to have the manifest creation
go into an existing directory, and update that directory to match
luarocks' expectations:

  * d/luarocks.postinst: Add global flag to fix installation.
  * d/tests: Add basic autopkgtests.


Thanks for considering the patch.


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

Kernel: Linux 5.13.0-19-generic (SMP w/8 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru luarocks-3.7.0+dfsg1/debian/luarocks.postinst 
luarocks-3.7.0+dfsg1/debian/luarocks.postinst
--- luarocks-3.7.0+dfsg1/debian/luarocks.postinst   2021-09-28 
10:53:39.0 +
+++ luarocks-3.7.0+dfsg1/debian/luarocks.postinst   2021-11-05 
09:22:18.0 +
@@ -1,9 +1,9 @@
 #!/bin/sh
 set -e 
 
-if [ ! -e /usr/local/lib/luarocks/rocks/manifest ]; then
-   mkdir -p /usr/local/lib/luarocks/rocks/
-   luarocks-admin make_manifest --local-tree
+if [ ! -e /usr/local/lib/luarocks/rocks-5.1/manifest ]; then
+   mkdir -p /usr/local/lib/luarocks/rocks-5.1
+   luarocks-admin make_manifest --local-tree --global --tree /usr/local
 fi
 
 #DEBHELPER#
diff -Nru luarocks-3.7.0+dfsg1/debian/tests/clients 
luarocks-3.7.0+dfsg1/debian/tests/clients
--- luarocks-3.7.0+dfsg1/debian/tests/clients   1970-01-01 00:00:00.0 
+
+++ luarocks-3.7.0+dfsg1/debian/tests/clients   2021-11-05 09:22:18.0 
+
@@ -0,0 +1,11 @@
+#!/bin/bash
+
+set -e
+
+CLIENTS=('luarocks-admin')
+
+for client in "${CLIENTS[@]}"; do
+echo -n "Testing client $client: "
+$client --version 2>&1 > /dev/null
+echo "OK"
+done
diff -Nru luarocks-3.7.0+dfsg1/debian/tests/control 
luarocks-3.7.0+dfsg1/debian/tests/control
--- luarocks-3.7.0+dfsg1/debian/tests/control   1970-01-01 00:00:00.0 
+
+++ luarocks-3.7.0+dfsg1/debian/tests/control   2021-11-05 09:22:18.0 
+
@@ -0,0 +1,4 @@
+Tests: clients
+Depends:
+  luarocks
+Restrictions: needs-root

Bug#996726: Some other questions

[Bob Wong]

  Probably the best way is to do the rolling release. Another solution is
to make each package synced downstream at the same time, but it's too hard
to achieve.

Jérôme Pouiller  于2021年11月5日周五 下午6:11写道：

> On Friday 5 November 2021 03:02:13 CET Norbert Preining wrote:
> > >   After 2 weeks, the bug has finally been fixed. But I wonder why the
> bug
> > > wasn't tested out in the unstable branch and was pushed into the
> testing
> >
> > Because on unstable everything worked. The bug happens only due to
> > different transition times from unstable to testing. This cannot be
> > tested in unstable before.
>
> Is there a way to avoid this problem happen in the future?
>
> --
> Jérôme Pouiller
>
>
>

Bug#998648: should exercise testsuite in autopkgtest

[Sébastien Villemot]

Source: cl-metabang-bind
Version: 20200101.git9ab6e64-1
Severity: wishlist

Currently, the autopkgtest only tries to load the main cl-metabang-bind system
(and is therefore marked as superficial).

It should be expanded to exercise the testsuite. This first requires
“lift” to be packaged.

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

Bug#998575: [Pkg-freeipa-devel] Bug#998575: bind-dyndb-ldap: FTBFS: build-dependency not installable: bind9-libs (= 1:9.16.21-1)

[peter green]

On 05/11/2021 07:21, Timo Aaltonen wrote:

I'd have assumed that reverse build-depends are checked before migration to 
testing?


They aren't :(

Bug#998642: Valgrind output with debug symbols available (+patch to fix problem)

[John Hughes]

I built cssc from source to get the debug symbols and valgrind shows:

valgrind cssc-1.4.1/src/get  s._x-xx
==319086== Memcheck, a memory error detector
==319086== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==319086== Using Valgrind-3.16.1 and LibVEX; rerun with -h for copyright info
==319086== Command: cssc-1.4.1/src/get s._x-xx
==319086==
==319086== Invalid read of size 1
==319086==at 0x483BC82: strlen (vg_replace_strmem.c:459)
==319086==by 0x4AC5F34: fputs (iofputs.c:33)
==319086==by 0x111B59: sccs_file::write_subst(char const*, 
sccs_file::subst_parms*, delta const&, bool) const (writesubst.cc:113)
==319086==by 0x111CED: sccs_file::write_subst(char const*, 
sccs_file::subst_parms*, delta const&, bool) const (writesubst.cc:245)
==319086==by 0x110BFD: sccs_file::get(std::__cxx11::basic_string, 
std::allocator > const&, seq_state&, sccs_file::subst_parms&, bool, int, int, int, 
bool, bool) (sf-get.cc:416)
==319086==by 0x10FAAA: sccs_file::get(_IO_FILE*, std::__cxx11::basic_string, std::allocator > const&, _IO_FILE*, sid, sccs_date, 
range_list, range_list, int, char const*, int, int, int, bool) (sf-get2.cc:519)
==319086==by 0x10C88B: main (get.cc:463)
==319086==  Address 0x4d75c80 is 0 bytes inside a block of size 18 free'd
==319086==at 0x483A08B: operator delete(void*, unsigned long) 
(vg_replace_malloc.c:593)
==319086==by 0x111B4B: deallocate (new_allocator.h:133)
==319086==by 0x111B4B: deallocate (alloc_traits.h:492)
==319086==by 0x111B4B: _M_destroy (basic_string.h:237)
==319086==by 0x111B4B: _M_dispose (basic_string.h:232)
==319086==by 0x111B4B: ~basic_string (basic_string.h:658)
==319086==by 0x111B4B: sccs_file::write_subst(char const*, 
sccs_file::subst_parms*, delta const&, bool) const (writesubst.cc:112)
==319086==by 0x111CED: sccs_file::write_subst(char const*, 
sccs_file::subst_parms*, delta const&, bool) const (writesubst.cc:245)
==319086==by 0x110BFD: sccs_file::get(std::__cxx11::basic_string, 
std::allocator > const&, seq_state&, sccs_file::subst_parms&, bool, int, int, int, 
bool, bool) (sf-get.cc:416)
==319086==by 0x10FAAA: sccs_file::get(_IO_FILE*, std::__cxx11::basic_string, std::allocator > const&, _IO_FILE*, sid, sccs_date, 
range_list, range_list, int, char const*, int, int, int, bool) (sf-get2.cc:519)
==319086==by 0x10C88B: main (get.cc:463)
==319086==  Block was alloc'd at
==319086==at 0x4838DEF: operator new(unsigned long) 
(vg_replace_malloc.c:342)
==319086==by 0x11297C: void std::__cxx11::basic_string, 
std::allocator >::_M_construct(char*, char*, std::forward_iterator_tag) 
[clone .isra.0] (basic_string.tcc:219)
==319086==by 0x113301: _M_construct_aux (basic_string.h:247)
==319086==by 0x113301: _M_construct (basic_string.h:266)
==319086==by 0x113301: basic_string (basic_string.h:451)
==319086==by 0x113301: gfile (sccsname.h:87)
==319086==by 0x113301: sccs_file::get_module_name[abi:cxx11]() const 
(sccsfile.cc:694)
==319086==by 0x111B2B: sccs_file::write_subst(char const*, 
sccs_file::subst_parms*, delta const&, bool) const (writesubst.cc:112)
==319086==by 0x111CED: sccs_file::write_subst(char const*, 
sccs_file::subst_parms*, delta const&, bool) const (writesubst.cc:245)
==319086==by 0x110BFD: sccs_file::get(std::__cxx11::basic_string, 
std::allocator > const&, seq_state&, sccs_file::subst_parms&, bool, int, int, int, 
bool, bool) (sf-get.cc:416)
==319086==by 0x10FAAA: sccs_file::get(_IO_FILE*, std::__cxx11::basic_string, std::allocator > const&, _IO_FILE*, sid, sccs_date, 
range_list, range_list, int, char const*, int, int, int, bool) (sf-get2.cc:519)
==319086==by 0x10C88B: main (get.cc:463)
==319086==

So this patch fixes the problem:

--- src/writesubst.cc.orig  2019-05-07 13:40:13.0 +0200
+++ src/writesubst.cc   2021-11-05 14:26:23.229149292 +0100
@@ -109,8 +109,8 @@
 
 case 'M':

   {
-const char *mod = get_module_name().c_str();
-err = fputs_failed(fputs(mod, out));
+string mod = get_module_name();
+err = fputs_failed(fputs(mod.c_str(), out));
   }
 break;
 

Bug#992405: buster->bullseye: octave left unconfigured due to naming of shared lib libopenblas

[Sébastien Villemot]

Le vendredi 05 novembre 2021 à 09:23 +0100, reuss andras a écrit :
> Thanks for the hint.
> I removed the symlink with the following result (success):
> 
> /usr/lib/x86_64-linux-gnu$ sudo dpkg-reconfigure libopenblas0-pthread
> update-alternatives: warning: forcing reinstallation of alternative 
> /usr/lib/x86_64-linux-gnu/openblas-pthread/libopenblas.so.0 because link 
> group libopenblas.so.0-x86
> _64-linux-gnu is broken
> 
> /usr/lib/x86_64-linux-gnu$ ls -l |grep libopenblas  
> lrwxrwxrwx   1 root root    53 Nov  5 09:19 libopenblas64.so.0 -> 
> /etc/alternatives/libopenblas64.so.0-x86_64-linux-gnu
> lrwxrwxrwx   1 root root    48 Aug 17 21:30 libopenblas.a -> 
> /etc/alternatives/libopenblas.a-x86_64-linux-gnu
> lrwxrwxrwx   1 root root    49 Aug 17 21:30 libopenblas.so -> 
> /etc/alternatives/libopenblas.so-x86_64-linux-gnu
> lrwxrwxrwx   1 root root    51 Nov  5 09:20 libopenblas.so.0 -> 
> /etc/alternatives/libopenblas.so.0-x86_64-linux-gnu
> 
> I am wondering why this package has been broken. The issue came when I 
> upgraded to bullseye...

Good to know that your system is now fixed.

I have no idea what broke your system. You are the first one to report
such a problem. We can either close this bug, or continue to
investigate. If you want to do the latter, I would first like to see
the full dpkg.log and term.log (and not just the result of “grep
openblas” applied on those). Please let me know what you want to do.

Best,

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



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

Bug#995450: buster->bullseye: octave segfaulting during configure (seems unrelated to #992405)

[Diego Zuccato]

Hello Sébastien.

I think it's quite important to have it fixed in stable since it's quite 
tricky to debug and results in an error while installing or upgrading 
octave. Does that qualify as a major impact? :)


Tks.

Il 05/11/2021 14:35, Sébastien Villemot ha scritto:

Control: retitle -1 segfault when running out of memory
Control: tags -1 = upstream fixed-upstream

Dear Diego,

Le vendredi 05 novembre 2021 à 06:34 +0100, Diego Zuccato a écrit :

Il 04/11/2021 12:27, Sébastien Villemot ha scritto:


I happen to have access to a machine with exactly the same CPU (and
Debian Bullseye). I fail to replicate your problem there. I can start
octave with libopenblas0-pthread and there is no segfault.
So there must be another factor at play.Uhm...


I use pam-limits and cgroups to limit the memory available to users.


I confirm that I can replicate the segfault with:

$ ulimit -d 1024000
$ octave

The crash occurs in function blas_memory_alloc(), as in your backtrace.

Thanks to your analysis, upstream has fixed the issue. I will therefore
fix it in Debian unstable (either with the next upstream release, or
possibly even earlier with a targeted patch).

Are you interested in having this bug fixed in Debian stable
(bullseye)? In theory this possibility is only open for bugs of
severity “important” or higher, while the bug is currently marked with
severity “normal”. A bug of severity important is defined as having “a
major effect on the usability of a package, without rendering it
completely unusable to everyone”. What do you think?

Best,



--
Diego Zuccato
DIFA - Dip. di Fisica e Astronomia
Servizi Informatici
Alma Mater Studiorum - Università di Bologna
V.le Berti-Pichat 6/2 - 40127 Bologna - Italy
tel.: +39 051 20 95786

Bug#997504: terminator: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p 3.9 returned exit code 13

[Timo Röhling]

Control: reassign 997504 python3-gi 3.42.0-1
Control: affects 997504 src:terminator

Hi,

On Sat, 23 Oct 2021 22:41:30 +0200 Lucas Nussbaum  wrote:

> collecting ... Trace/breakpoint trap
> E: pybuild pybuild:354: test: plugin distutils failed with: exit code=133: cd 
/<>/.pybuild/cpython3_3.9/build; python3.9 -m pytest --doctest-modules
> dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p 3.9 
returned exit code 13

I investigated this failure a bit and found that there seems to be a
segfault on instantiating terminal.Terminal(), which looks like it
is caused by the bindings in python3-gi.

I assume so because I found that the error also occurs with older
terminator versions in unstable, but not with the latest terminator
version in a bullseye chroot.

For reference, the error in unstable can be reproduced in an interactive
Python session (I ran "gdb /usr/bin/python3" to get a stacktrace):

  >>> from terminatorlib import terminal
  /build/terminator-2.1.0/terminatorlib/terminal.py:9: PyGIWarning: Pango was 
imported without specifying a version first. Use gi.require_version('Pango', 
'1.0') before import to ensure that the right version gets loaded.
from gi.repository import GLib, GObject, Pango, Gtk, Gdk, GdkPixbuf
  /build/terminator-2.1.0/terminatorlib/terminal.py:9: PyGIWarning: Gtk was 
imported without specifying a version first. Use gi.require_version('Gtk', 
'3.0') before import to ensure that the right version gets loaded.
from gi.repository import GLib, GObject, Pango, Gtk, Gdk, GdkPixbuf
  >>> t = terminal.Terminal()
  
  (.:106187): Gtk-CRITICAL **: 13:00:40.235: _gtk_style_provider_private_get_settings: assertion 'GTK_IS_STYLE_PROVIDER_PRIVATE (provider)' failed
  
  (.:106187): Gtk-CRITICAL **: 13:00:40.235: _gtk_style_provider_private_get_settings: assertion 'GTK_IS_STYLE_PROVIDER_PRIVATE (provider)' failed
  
  (.:106187): Gtk-CRITICAL **: 13:00:40.235: _gtk_style_provider_private_get_settings: assertion 'GTK_IS_STYLE_PROVIDER_PRIVATE (provider)' failed
  
  Program received signal SIGSEGV, Segmentation fault.

  0x75a98a80 in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
  (gdb) bt
  #0  0x75a98a80 in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
  #1  0x75938e84 in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
  #2  0x7595a658 in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
  #3  0x75944dca in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
  #4  0x7595a528 in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
  #5  0x75945712 in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
  #6  0x776ceae3 in g_type_create_instance () from 
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
  #7  0x776b4cbd in ?? () from 
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
  #8  0x776b61fd in g_object_new_with_properties () from 
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
  #9  0x776b6bb1 in g_object_new () from 
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
  #10 0x7596300b in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
  #11 0x75b4cdd9 in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
  #12 0x776ceae3 in g_type_create_instance () from 
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
  #13 0x776b4cbd in ?? () from 
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
  #14 0x776b61fd in g_object_new_with_properties () from 
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
  #15 0x7783de64 in ?? () from 
/usr/lib/python3/dist-packages/gi/_gi.cpython-39-x86_64-linux-gnu.so
  #16 0x7785be2f in ?? () from 
/usr/lib/python3/dist-packages/gi/_gi.cpython-39-x86_64-linux-gnu.so
  #17 0x005915e8 in ?? ()
  #18 0x005b84d8 in ?? ()
  #19 0x0051df8b in _PyObject_MakeTpCall ()
  #20 0x00517b45 in _PyEval_EvalFrameDefault ()
  #21 0x005291c3 in _PyFunction_Vectorcall ()
  #22 0x005380b8 in ?? ()
  #23 0x0051dde5 in _PyObject_MakeTpCall ()
  #24 0x00517b45 in _PyEval_EvalFrameDefault ()
  #25 0x00510d5d in ?? ()
  #26 0x00510b07 in _PyEval_EvalCodeWithName ()
  #27 0x005f38b3 in PyEval_EvalCode ()
  #28 0x00618eb7 in ?? ()
  #29 0x00614090 in ?? ()
  #30 0x0045981b in ?? ()
  #31 0x00459481 in PyRun_InteractiveLoopFlags ()
  #32 0x00617a95 in PyRun_AnyFileExFlags ()
  #33 0x0044bd4d in ?? ()
  #34 0x005e8209 in Py_BytesMain ()
  #35 0x77c58e4a in __libc_start_main () from 
/lib/x86_64-linux-gnu/libc.so.6
  #36 0x005e810a in _start ()


Cheers
Timo

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


signature.asc
Description: PGP signature

Bug#995450: buster->bullseye: octave segfaulting during configure (seems unrelated to #992405)

[Sébastien Villemot]

Control: severity -1 important

Le vendredi 05 novembre 2021 à 15:00 +0100, Diego Zuccato a écrit :
> I think it's quite important to have it fixed in stable since it's quite 
> tricky to debug and results in an error while installing or upgrading 
> octave. Does that qualify as a major impact? :)

Ok, let’s try that. Per the stable update rules, I first have to fix it
in unstable, and then I will request a fix in stable (the final
decision regarding inclusion in stable will be made by the Release
Team).

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



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

Bug#990533: f2fs-tools: suggestions for the packaging

[Nicolas Boulenguez]

Source: f2fs-tools
Followup-For: Bug #990533

The attached new versions improve some details and will hopefully
spare you some time.
>From 0b2b0708553fa335333c1811c7adccafddb6114e Mon Sep 17 00:00:00 2001
From: Nicolas Boulenguez 
Date: Thu, 1 Jul 2021 11:09:38 +0200
Subject: [PATCH 1/6] debian: remove get-orig-source target from debian/rules

Uscan is preferred when possible.
---
 debian/rules | 7 ---
 1 file changed, 7 deletions(-)

diff --git a/debian/rules b/debian/rules
index 298b739..d494e69 100755
--- a/debian/rules
+++ b/debian/rules
@@ -24,13 +24,6 @@ override_dh_install:
 override_dh_strip:
 	dh_strip --dbgsym-migration='f2fs-tools-dbg (<< 1.12.0-1~)'
 
-get-orig-source:
-	wget http://git.kernel.org/cgit/linux/kernel/git/jaegeuk/f2fs-tools.git/snapshot/f2fs-tools-$(DEB_VERSION_UPSTREAM).tar.gz
-	gunzip < f2fs-tools-$(DEB_VERSION_UPSTREAM).tar.gz | \
-		xz > f2fs-tools-$(DEB_VERSION_UPSTREAM).tar.xz
-	rm f2fs-tools-$(DEB_VERSION_UPSTREAM).tar.gz
-	mv f2fs-tools-$(DEB_VERSION_UPSTREAM).tar.xz f2fs-tools_$(DEB_VERSION_UPSTREAM).orig.tar.xz
-
 # dh_dwz when run on f2fs-tools-udeb ends up installing the
 # /usr/lib/debug/.dwz files into the udeb.  I think that's a bug,
 # but for now, override it by just saying... just don't.
-- 
2.30.2

>From 22c3cb1eae9e28a25c2eb0953096c0b94ba61244 Mon Sep 17 00:00:00 2001
From: Nicolas Boulenguez 
Date: Thu, 1 Jul 2021 11:12:22 +0200
Subject: [PATCH 2/6] debian: remove redundant libdir option from
 dh_auto_configure override

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

diff --git a/debian/rules b/debian/rules
index d494e69..9dd7659 100755
--- a/debian/rules
+++ b/debian/rules
@@ -12,7 +12,6 @@ include /usr/share/dpkg/default.mk
 
 override_dh_auto_configure:
 	dh_auto_configure -- --sbindir=/sbin --disable-shared \
-		--libdir=/usr/lib/$(DEB_HOST_MULTIARCH) \
 		--with-root-libdir=/lib/$(DEB_HOST_MULTIARCH)
 
 override_dh_install:
-- 
2.30.2

>From 7d6744f42f02d6408cfc3cd8b4ec85c4a821e080 Mon Sep 17 00:00:00 2001
From: Nicolas Boulenguez 
Date: Thu, 1 Jul 2021 11:14:00 +0200
Subject: [PATCH 3/6] debian: stop exporting build flags from debian/rules

Dh_auto_* tools already export the build flags, whether debian/rules
knowns about them or not.

In this case, debian/rules does not need to interfer.

The test_printenv target seems to have been introduced in order to
check the removed export.
---
 debian/rules | 6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/debian/rules b/debian/rules
index 9dd7659..9bc4df8 100755
--- a/debian/rules
+++ b/debian/rules
@@ -4,8 +4,7 @@
 
 export DEB_BUILD_MAINT_OPTIONS ?= hardening=+all
 
-DPKG_EXPORT_BUILDFLAGS = 1
-include /usr/share/dpkg/default.mk
+include /usr/share/dpkg/architecture.mk
 
 %:
 	dh $@
@@ -28,6 +27,3 @@ override_dh_strip:
 # but for now, override it by just saying... just don't.
 override_dh_dwz:
 	dh_dwz -N f2fs-tools-udeb
-
-test_printenv:
-	printenv | sort
-- 
2.30.2

>From 9ff31a9269d863cedd3b226b25542c1110197481 Mon Sep 17 00:00:00 2001
From: Nicolas Boulenguez 
Date: Fri, 5 Nov 2021 14:19:03 +0100
Subject: [PATCH 4/6] debian: prevent installation of sg_write_buffer from
 debian/not-installed

This declarative style is more readable than removal commands.
---
 debian/f2fs-tools-udeb.install | 3 ++-
 debian/f2fs-tools.install  | 4 +++-
 debian/not-installed   | 5 +
 debian/rules   | 5 +
 4 files changed, 11 insertions(+), 6 deletions(-)
 create mode 100644 debian/not-installed

diff --git a/debian/f2fs-tools-udeb.install b/debian/f2fs-tools-udeb.install
index d48cf30..5779210 100644
--- a/debian/f2fs-tools-udeb.install
+++ b/debian/f2fs-tools-udeb.install
@@ -1 +1,2 @@
-/sbin
+# All but sbin/sg_write_buffer
+sbin/*f2fs*
diff --git a/debian/f2fs-tools.install b/debian/f2fs-tools.install
index c5dbdb2..1b7999a 100644
--- a/debian/f2fs-tools.install
+++ b/debian/f2fs-tools.install
@@ -1,2 +1,4 @@
-sbin/*
+# All but sbin/sg_write_buffer
+sbin/*f2fs*
+
 usr/share/man/man8/*.8
diff --git a/debian/not-installed b/debian/not-installed
new file mode 100644
index 000..5cb77ca
--- /dev/null
+++ b/debian/not-installed
@@ -0,0 +1,5 @@
+# Policy recommends not to install libtool .la files
+usr/lib/*/libf2fs*.la
+
+# See f2fs-tools.install and f2fs-tools-udeb.install
+sbin/sg_write_buffer
diff --git a/debian/rules b/debian/rules
index 9bc4df8..792b787 100755
--- a/debian/rules
+++ b/debian/rules
@@ -13,10 +13,7 @@ override_dh_auto_configure:
 	dh_auto_configure -- --sbindir=/sbin --disable-shared \
 		--with-root-libdir=/lib/$(DEB_HOST_MULTIARCH)
 
-override_dh_install:
-	find $(CURDIR) -name "*.la" -delete
-	rm $(CURDIR)/debian/tmp/sbin/sg_write_buffer
-	dh_install
+override_dh_missing:
 	dh_missing --fail-missing
 
 override_dh_strip:
-- 
2.30.2

>From c45e55569ef076240e5a3334d4b6a46c749663d3 Mon Sep 17 00:00:00 2001
From: Nicolas Boulenguez 
Date: Fri, 5 Nov 2021 14:24:49 +0100
Subject: [PATCH 5/6] debian: update to debhelper 13

Dh_missing now 

Bug#998646: RFP: rtpmidid -- RTP MIDI (AppleMIDI) daemon for Linux

[David Moreno Montero]

Package: wnpp
Severity: wishlist

Source code at: https://github.com/davidmoreno/rtpmidid
License is LGPL 2.1 (library) and GPL3+.
Has preliminary deb packaging using `dpkb-buildpackage`.
If there is something that I could do to help to package this program,
please contact me (dmor...@coralbits.com), or add a bug report at github.

Some description:

rtpmidid allows you to share ALSA sequencer devices on the network using
RTP MIDI, and import other network shared RTP MIDI devices.
rtpmidid is an user daemon, and when a RTP MIDI device is announced using
mDNS (also known as Zeroconf, Avahi, and multicast DNS) it exposes this
ALSA sequencer port.

Bug#995450: buster->bullseye: octave segfaulting during configure (seems unrelated to #992405)

[Sébastien Villemot]

Control: retitle -1 segfault when running out of memory
Control: tags -1 = upstream fixed-upstream

Dear Diego,

Le vendredi 05 novembre 2021 à 06:34 +0100, Diego Zuccato a écrit :
> Il 04/11/2021 12:27, Sébastien Villemot ha scritto:
> 
> > I happen to have access to a machine with exactly the same CPU (and
> > Debian Bullseye). I fail to replicate your problem there. I can start
> > octave with libopenblas0-pthread and there is no segfault.
> > So there must be another factor at play.Uhm...
> 
> I use pam-limits and cgroups to limit the memory available to users.

I confirm that I can replicate the segfault with:

$ ulimit -d 1024000
$ octave

The crash occurs in function blas_memory_alloc(), as in your backtrace.

Thanks to your analysis, upstream has fixed the issue. I will therefore
fix it in Debian unstable (either with the next upstream release, or
possibly even earlier with a targeted patch).

Are you interested in having this bug fixed in Debian stable
(bullseye)? In theory this possibility is only open for bugs of
severity “important” or higher, while the bug is currently marked with
severity “normal”. A bug of severity important is defined as having “a
major effect on the usability of a package, without rendering it
completely unusable to everyone”. What do you think?

Best,

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



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

Bug#998643: acpitool: Coredumps under certain situations

[Michael Prokop]

* Michael Prokop [Fri Nov 05, 2021 at 02:21:17PM +0100]:

> running acpitool coredumps on my system:
> 
> | % acpitool
> | acpitool: battery.cpp:816: int Count_Batteries_SysFS(): Assertion `findex < 
> 4' failed.
> | [1]1295360 abort (core dumped)  acpitool
[...]

I noticed the comment in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=885623#10 only
after reporting this one, sorry. If the package maintainer feels
like #885623 and #998643 are the same origin/problem, feel free to
(force-)merge the bugs.

regards
-mika-


signature.asc
Description: PGP signature

Bug#998645: git-buildpackage.zsh-completion: duplicated functions, leading to bogus completion

[Romain Porte]

Package: git-buildpackage
Version: 0.9.23
Severity: normal
X-Debbugs-Cc: deb...@microjoe.org

Dear Maintainer,

The debian/git-buildpackage.zsh-completion is full of duplicated
function implementations:

$ cat debian/git-buildpackage.zsh-completion| grep -E '.*() {' | sort | uniq -c
  2 _gbp() {
  2 __gbp_branch_options() {
  2 _gbp-buildpackage() {
  2 _gbp-clone() {
  2 __gbp_common_options() {
  1 _gbp-config() {
  2 _gbp-create-remote-repo() {
  2 _gbp-dch () {
  1 _gbp-export-orig() {
  2 _gbp-import-dsc() {
  2 _gbp-import-dscs() {
  2 _gbp-import-orig() {
  1 _gbp-import-ref() {
  2 _gbp-pq() {
  1 _gbp-pristine-tar() {
  2 _gbp-pull() {
  1 _gbp-push() {
  1 _gbp-tag() {
  2 __gbp_tag_format_options() {
  2 __gbp_tag_sign_options() {

In particular, the _gbp() function that is defined twice does define the
`tag` subcommand in one of the implementations, but not in the other.

This is leading to the following bogus completion behavior:

* start a new zsh instance
* type `gbp`
* press  to complete
* the `tag` option is displayed
* press  again to select one of the options
* the `tag` option dissapears and will never be suggested during the zsh
  session

I feel that the duplication of the functions is not intentional and that
it is the root cause of this behavior. The solution could be to remove
the duplicate implementations, by keeping the most complete ones, in
order to fix this issue.

BRs,

-- 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.14.0-4-amd64 (SMP w/4 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 /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages git-buildpackage depends on:
ii  devscripts 2.21.4
ii  git1:2.33.1-1
ii  man-db 2.9.4-2
ii  python33.9.7-1
ii  python3-dateutil   2.8.1-6
ii  python3-pkg-resources  58.2.0-1
ii  sensible-utils 0.0.17

Versions of packages git-buildpackage recommends:
ii  pristine-tar  1.49
ii  python3-requests  2.25.1+dfsg-2
ii  sbuild0.81.2

Versions of packages git-buildpackage suggests:
pn  python3-notify2  
ii  sudo 1.9.5p2-3
ii  unzip6.0-26

-- no debconf information

Bug#998644: git-buildpackage: cannot clone upstream git repository over HTTPS

[Romain Porte]

Package: git-buildpackage
Version: 0.9.22
Severity: normal
Tags: upstream
X-Debbugs-Cc: deb...@microjoe.org

Dear Maintainer,

When trying to clone the upstream repository, the followng error occurs
on my machine:

$ LANG=en_US.utf-8 git clone https://git.sigxcpu.org/cgit/git-buildpackage/
Cloning into 'git-buildpackage'...
fatal: unable to access 'https://git.sigxcpu.org/cgit/git-buildpackage/': 
server certificate verification failed. CAfile: none CRLfile: none

However, I can access the URL using Firefox. After some investigation
with other Debian folks on IRC, it seems that this error is occuring
because git is using GNUTLS, while Firefox is using OpenSSL.

There is probably something wrong with the TLS certificate.

This is preventing me (and probably others) from cloning the repository
in order to investigate issues and propose patches to fix them. Using
`apt source` is less practical because of the loss of history on the
file changes.

Bests,

-- 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.14.0-4-amd64 (SMP w/4 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 /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages git-buildpackage depends on:
ii  devscripts 2.21.4
ii  git1:2.33.1-1
ii  man-db 2.9.4-2
ii  python33.9.7-1
ii  python3-dateutil   2.8.1-6
ii  python3-pkg-resources  58.2.0-1
ii  sensible-utils 0.0.17

Versions of packages git-buildpackage recommends:
ii  pristine-tar  1.49
ii  python3-requests  2.25.1+dfsg-2
ii  sbuild0.81.2

Versions of packages git-buildpackage suggests:
pn  python3-notify2  
ii  sudo 1.9.5p2-3
ii  unzip6.0-26

-- no debconf information

Bug#885623: Assertion triggered

[Michael Prokop]

Hi,

* Philipp Marek [Wed Sep 08, 2021 at 10:05:12AM +0200]:

> acpitool breaks with a Lenovo L480 and Linux version 5.10.0-8-amd64:
> 
> # acpitool
> acpitool: battery.cpp:816: int Count_Batteries_SysFS(): Assertion
> `findex < 4' failed.
> Abgebrochen
[...]

> The problem is (135 entries total) - though I believe that the
> kernel-side could use a better representation:
> 
> # ls /sys/class/power_supply/
> AC/ucsi-source-psy-USBC000:00121/
> BAT0/  ucsi-source-psy-USBC000:00122/
> ucsi-source-psy-USBC000:001/   ucsi-source-psy-USBC000:00123/
> ucsi-source-psy-USBC000:0010/  ucsi-source-psy-USBC000:00124/
> ucsi-source-psy-USBC000:00100/ ucsi-source-psy-USBC000:00125/
> ucsi-source-psy-USBC000:00101/ ucsi-source-psy-USBC000:00126/
[...]

I can confirm this behavior also for a ThinkPad X280 with latest
bullseye kernel 5.10.0-9-amd64, exactly the same behavior.

The `acpi` tool (not acpitool) at least doesn't segfault:

| % acpi
| Battery 0: Unknown, 96%
| Battery 1: Discharging, 0%, rate information unavailable

FTR:

| % ls -la /proc/acpi/
| total 0
| dr-xr-xr-x   6 root root 0 Nov  5 13:58 .
| dr-xr-xr-x 414 root root 0 Oct 21 15:43 ..
| dr-xr-xr-x   3 root root 0 Nov  5 14:00 button
| -rw-rw   1 root root 0 Nov  5 14:00 call
| dr-xr-xr-x  15 root root 0 Nov  5 14:00 ibm
| -rw-r--r--   1 root root 0 Nov  5 14:00 wakeup
| % ls -la /sys/class/power_supply
| total 0
| drwxr-xr-x  2 root root 0 Nov  5 12:31 .
| drwxr-xr-x 66 root root 0 Nov  5 12:31 ..
| lrwxrwxrwx  1 root root 0 Nov  5 13:26 AC -> 
../../devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:19/PNP0C09:00/ACPI0003:00/power_supply/AC
| lrwxrwxrwx  1 root root 0 Nov  5 13:30 BAT0 -> 
../../devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:19/PNP0C09:00/PNP0C0A:00/power_supply/BAT0
| lrwxrwxrwx  1 root root 0 Nov  5 13:26 hidpp_battery_3 -> 
../../devices/pci:00/:00:1c.0/:02:00.0/:03:02.0/:3a:00.0/usb3/3-1/3-1.2/3-1.2.2/3-1.2.2:1.2/0003:046D:C52B.0036/0003:046D:4069.0037/power_supply/hidpp_battery_3
| lrwxrwxrwx  1 root root 0 Nov  5 13:26 ucsi-source-psy-USBC000:001 -> 
../../devices/platform/USBC000:00/power_supply/ucsi-source-psy-USBC000:001
| lrwxrwxrwx  1 root root 0 Nov  5 13:26 ucsi-source-psy-USBC000:002 -> 
../../devices/platform/USBC000:00/power_supply/ucsi-source-psy-USBC000:002

regards
-mika-


signature.asc
Description: PGP signature

Bug#998643: acpitool: Coredumps under certain situations

[Michael Prokop]

Package: acpitool
Version: 0.5.1-6
Severity: normal

Hi,

running acpitool coredumps on my system:

| % acpitool
| acpitool: battery.cpp:816: int Count_Batteries_SysFS(): Assertion `findex < 
4' failed.
| [1]1295360 abort (core dumped)  acpitool

strace-ing acpitool shows, that it seems to have troubles with
working with my /proc/acpi/battery/ and /sys/class/power_supply/:

| openat(AT_FDCWD, "/proc/acpi/battery/", 
O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = -1 ENOENT (No such file or 
directory)
| openat(AT_FDCWD, "/sys/class/power_supply/", 
O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = 3
| fstat(3, {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
| openat(AT_FDCWD, "/sys/class/power_supply/", 
O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = 4
| fstat(4, {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
| brk(0x55fbf790c000) = 0x55fbf790c000
| getdents64(4, 0x55fbf78e3100 /* 7 entries */, 32768) = 232
| getdents64(4, 0x55fbf78e3100 /* 0 entries */, 32768) = 0
| close(4)= 0
| write(2, "acpitool: battery.cpp:816: int C"..., 87acpitool: battery.cpp:816: 
int Count_Batteries_SysFS(): Assertion `findex < 4' failed.
| ) = 87

My laptop's battery indeed seems to behave strange (it's currently
running on power), but `acpi` doesn't fail hard on it:

| % acpi
| Battery 0: Unknown, 96%
| Battery 1: Discharging, 0%, rate information unavailable

acpitool shouldn't coredump, but either properly handle this
situation, or at least report an error message otherwise.

FTR:

| % ls -la /proc/acpi/
| total 0
| dr-xr-xr-x   6 root root 0 Nov  5 13:58 .
| dr-xr-xr-x 414 root root 0 Oct 21 15:43 ..
| dr-xr-xr-x   3 root root 0 Nov  5 14:00 button
| -rw-rw   1 root root 0 Nov  5 14:00 call
| dr-xr-xr-x  15 root root 0 Nov  5 14:00 ibm
| -rw-r--r--   1 root root 0 Nov  5 14:00 wakeup
| % ls -la /sys/class/power_supply
| total 0
| drwxr-xr-x  2 root root 0 Nov  5 12:31 .
| drwxr-xr-x 66 root root 0 Nov  5 12:31 ..
| lrwxrwxrwx  1 root root 0 Nov  5 13:26 AC -> 
../../devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:19/PNP0C09:00/ACPI0003:00/power_supply/AC
| lrwxrwxrwx  1 root root 0 Nov  5 13:30 BAT0 -> 
../../devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:19/PNP0C09:00/PNP0C0A:00/power_supply/BAT0
| lrwxrwxrwx  1 root root 0 Nov  5 13:26 hidpp_battery_3 -> 
../../devices/pci:00/:00:1c.0/:02:00.0/:03:02.0/:3a:00.0/usb3/3-1/3-1.2/3-1.2.2/3-1.2.2:1.2/0003:046D:C52B.0036/0003:046D:4069.0037/power_supply/hidpp_battery_3
| lrwxrwxrwx  1 root root 0 Nov  5 13:26 ucsi-source-psy-USBC000:001 -> 
../../devices/platform/USBC000:00/power_supply/ucsi-source-psy-USBC000:001
| lrwxrwxrwx  1 root root 0 Nov  5 13:26 ucsi-source-psy-USBC000:002 -> 
../../devices/platform/USBC000:00/power_supply/ucsi-source-psy-USBC000:002

Debugging info:

| [New LWP 1294019]
| Core was generated by `acpitool'.
| Program terminated with signal SIGABRT, Aborted.
| #0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
| 50  ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
| (gdb) bt
| #0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
| #1  0x7f8432467537 in __GI_abort () at abort.c:79
| #2  0x7f843246740f in __assert_fail_base (fmt=0x7f84325d0128 "%s%s%s:%u: 
%s%sAssertion `%s' failed.\n%n", assertion=0x55636450a294 "findex < 4", 
file=0x55636450a288 "battery.cpp", line=816, function=) at 
assert.c:92
| #3  0x7f8432476662 in __GI___assert_fail (assertion=0x55636450a294 
"findex < 4", file=0x55636450a288 "battery.cpp", line=816, 
function=0x55636450a26c "int Count_Batteries_SysFS()") at assert.c:101
| #4  0x556364503b17 in ?? ()
| #5  0x55636450622d in ?? ()
| #6  0x5563644f9f3f in ?? ()
| #7  0x5563644f574c in ?? ()
| #8  0x7f8432468d0a in __libc_start_main (main=0x5563644f5330, argc=1, 
argv=0x7ffc502fa608, init=, fini=, 
rtld_fini=, stack_end=0x7ffc502fa5f8) at ../csu/libc-start.c:308
| #9  0x5563644f5a5a in ?? ()

regards
-mika-

Bug#998343: Black upstream fork

[Andreas Beckmann]

Control: severity -1 serious
Control: block 998588 with -1
Control: affects -1 + src:pyopencl

On Tue, 2 Nov 2021 18:16:39 + Neil Williams  wrote:

This fork may at least help reproduce the failure.


This error also manifests in pyopencl 2021.2.9-1:

dh_sphinxdoc: error: 
debian/python-pyopencl-doc/usr/share/doc/python-pyopencl-doc/html/_static/clipboard.min.js 
is missing


* successfully built on the buildds on Oct 20
* FTBFS in an achive wide rebuild on Nov 4, #998588


Andreas

Bug#998642: cssc: The "get" command fails to interpolate the "module name" for long filenames

[John Hughes]

Package: cssc
Version: 1.4.1-1
Severity: normal

Dear Maintainer,

   * What led up to the situation?

We found that the %M% SCCS keyword in some of our files was not being correctly
interpolated.

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

Did a "get" on a file called s._x-xx

   * What was the outcome of this action?

In the created file _x-xx the %M% keyword was replaced by an
empty string instead of the module name _x-xx

   * What outcome did you expect instead?

That %M% be replaced by _x-xx

This used to work with older versions of cssc.

I have tried running "get" under valgrind and was surprised to see "Invalid
read" errors:

$ valgrind /usr/lib/x86_64-linux-gnu/cssc/get -t "SCCS/s._x-xx"
==24638== Memcheck, a memory error detector
==24638== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==24638== Using Valgrind-3.14.0 and LibVEX; rerun with -h for copyright info
==24638== Command: /usr/lib/x86_64-linux-gnu/cssc/get -t 
SCCS/s._x-xx
==24638== 
==24638== Invalid read of size 1
==24638==at 0x4838CC2: __strlen_sse2 (in 
/usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==24638==by 0x4BF84A4: fputs (iofputs.c:33)
==24638==by 0x111F27: ??? (in /usr/lib/x86_64-linux-gnu/cssc/get)
==24638==by 0x112057: ??? (in /usr/lib/x86_64-linux-gnu/cssc/get)
==24638==by 0x110EF0: ??? (in /usr/lib/x86_64-linux-gnu/cssc/get)
==24638==by 0x10FBD0: ??? (in /usr/lib/x86_64-linux-gnu/cssc/get)
==24638==by 0x10CBAA: ??? (in /usr/lib/x86_64-linux-gnu/cssc/get)
==24638==by 0x4BAC09A: (below main) (libc-start.c:308)
==24638==  Address 0x4d685a0 is 0 bytes inside a block of size 18 free'd
==24638==at 0x4836EAB: operator delete(void*) (in 
/usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==24638==by 0x111F1C: ??? (in /usr/lib/x86_64-linux-gnu/cssc/get)
==24638==by 0x112057: ??? (in /usr/lib/x86_64-linux-gnu/cssc/get)
==24638==by 0x110EF0: ??? (in /usr/lib/x86_64-linux-gnu/cssc/get)
==24638==by 0x10FBD0: ??? (in /usr/lib/x86_64-linux-gnu/cssc/get)
==24638==by 0x10CBAA: ??? (in /usr/lib/x86_64-linux-gnu/cssc/get)
==24638==by 0x4BAC09A: (below main) (libc-start.c:308)
==24638==  Block was alloc'd at
==24638==at 0x4835DEF: operator new(unsigned long) (in 
/usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==24638==by 0x10E56C: void std::__cxx11::basic_string, std::allocator >::_M_construct(char*, 
char*, std::forward_iterator_tag) (in /usr/lib/x86_64-linux-gnu/cssc/get)
==24638==by 0x114165: ??? (in /usr/lib/x86_64-linux-gnu/cssc/get)
==24638==by 0x111F05: ??? (in /usr/lib/x86_64-linux-gnu/cssc/get)
==24638==by 0x112057: ??? (in /usr/lib/x86_64-linux-gnu/cssc/get)
==24638==by 0x110EF0: ??? (in /usr/lib/x86_64-linux-gnu/cssc/get)
==24638==by 0x10FBD0: ??? (in /usr/lib/x86_64-linux-gnu/cssc/get)
==24638==by 0x10CBAA: ??? (in /usr/lib/x86_64-linux-gnu/cssc/get)
==24638==by 0x4BAC09A: (below main) (libc-start.c:308)
==24638== 



-- System Information:
Debian Release: 11.1
  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/4 CPU threads)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages cssc depends on:
ii  libc62.31-13+deb11u2
ii  libgcc-s1 [libgcc1]  10.2.1-6
ii  libstdc++6   10.2.1-6

cssc recommends no packages.

Versions of packages cssc suggests:
pn  groff  

-- no debconf information

Bug#998641: python-yubico-tools: yubikey-totp broken with Python 3.9 (Debian bullseye)

[Marc Donges]

Package: python-yubico-tools
Version: 1.3.3-0.3
Severity: important
X-Debbugs-Cc: p...@hungry.com

yubikey-totp is broken with the version of Python (3.9) that is current in 
Debian bullseye. Petter Reinholdtsen discovered this in a discussion of bug 
#965059 [1] and provided a patch there [2]. With the patch it works fine for me.

Output from yubikey-totp:

->8
% yubikey-totp
Traceback (most recent call last):
  File "/usr/bin/yubikey-totp", line 132, in 
sys.exit(main())
  File "/usr/bin/yubikey-totp", line 120, in main
otp = make_totp(args)
  File "/usr/bin/yubikey-totp", line 106, in make_totp
secret = struct.pack("> Q", args.time / args.step).ljust(64, chr(0x0))
struct.error: required argument is not an integer
%
->8

Expected output (output after patch):

->8
% yubikey-totp
->8

Here it waits for a keypress on the hardware token.

I set the severity to important because yubikey-totp is unusable.

Kind regards
Marc

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

[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=965059#20


-- System Information:
Debian Release: 11.1
  APT prefers stable-updates
  APT policy: (600, 'stable-updates'), (600, 'stable-security'), (600, 
'stable'), (400, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages python-yubico-tools depends on:
ii  python3-yubico  1.3.3-0.3

python-yubico-tools recommends no packages.

python-yubico-tools suggests no packages.

-- no debconf information

Bug#887834: [Pkg-mpd-maintainers] Bug#887834: Bug#887834: mpd installation fails, cannot open /var/lib/mpd/tag_cache, /run/mpd/pid

[Ryan Kavanagh]

Hi Florian,

On Fri, Nov 05, 2021 at 05:55:52AM +0100, Florian Schlichting wrote:
> please, for now, delete or comment out the pid_file line

Right, I saw in some other bug report that it was no longer needed or
was a legacy configuration item. In that case, it should be dropped from
the default /etc/mpd.conf shipped in the package:

rak@zeta:/tmp$ ar p mpd_0.23.3-1_amd64.deb data.tar.xz | tar JOx ./etc/mpd.conf 
| grep pid_file
pid_file"/run/mpd/pid"

> The tag_cache exception is non-fatal. The problem here is the Assertion
> failure, which is #998310 and fixed in mpd 0.23.3-2

I can confirm that 0.23.3-2 fixes this bug and that I can run mpd with
the minimal mpd.conf, assuming that I delete the pid_file line. (With
the pid_file line, it runs into the issue you described in the rest of
your email:

Nov 05 08:45:25 zeta mpd[510628]: sndfile: libsndfile-1.0.31
Nov 05 08:45:25 zeta mpd[510628]: hybrid_dsd: The Hybrid DSD decoder is 
disabled because it was not explicitly enabled
Nov 05 08:45:25 zeta mpd[510628]: adplug: adplug 2.3.3
Nov 05 08:45:25 zeta mpd[510628]: exception: Failed to open 
'/var/lib/mpd/tag_cache': No such file or directory
Nov 05 08:45:25 zeta mpd[510628]: curl: version 7.74.0
Nov 05 08:45:25 zeta mpd[510628]: curl: with GnuTLS/3.7.2
Nov 05 08:45:25 zeta mpd[510628]: exception: Failed to create pid file 
"/run/mpd/pid": Permission denied
Nov 05 08:45:25 zeta systemd[1]: mpd.service: Main process exited, code=exited, 
status=1/FAILURE
Nov 05 08:45:25 zeta systemd[1]: mpd.service: Failed with result 'exit-code'.
Nov 05 08:45:25 zeta systemd[1]: Failed to start Music Player Daemon.

Best,
Ryan

-- 
|)|/  Ryan Kavanagh  | 4E46 9519 ED67 7734 268F
|\|\  https://rak.ac | BD95 8F7B F8FC 4A11 C97A


signature.asc
Description: PGP signature

Bug#995017: gpyfft: autopkgtest regression on armhf: Aborted

[Andreas Beckmann]

  File "/usr/lib/python3/dist-packages/pytest/__main__.py", line 7 in

  File "/usr/lib/python3.9/runpy.py", line 87 in _run_code
  File "/usr/lib/python3.9/runpy.py", line 197 in _run_module_as_main
bash: line 1:  2952 Aborted $py -m pytest --pyargs
gpyfft.test


This is likely related to #997908 filed against pocl
"pocl: Assertion `td->printf_buffer != NULL' failed on armel/armhf"
which seems to be pocl failing due to being out of memory. Probably 
python or some other user of pocl has already eaten all memory before 
calling into pocl.
I don't know how memory constrained the autopkgtest environment is ... 
is there swap available?
Maybe running 'clinfo', 'free', ... before the actual test could provide 
some insights.


So far I haven't been able to reproduce this on a porter box.

Andreas

PS: the printf buffer is a 16 MB allocation (per OpenCL compute unit)

Bug#998640: RM: fastp [i386,s90x] -- ROM; Build-Dep isal does not build on i386,s90x

[Nilesh Patra]

Package: ftp.debian.org
Severity: normal

Hi,

Please remove fastp for i386 and s390x, since in later releases
it has started to depend on isal which does not build on these.

Nobody uses fastp on these archs, and removal should be okay.

Nilesh

Bug#993100: bullseye-pu: package udisks2/2.9.2-2+deb11u1

[Michael Biebl]

On 03.11.21 15:32, Michael Biebl wrote:

On Fri, 27 Aug 2021 13:58:19 +0200 Michael Biebl  wrote:

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: pkg-utopia-maintain...@lists.alioth.debian.org


Hi,

I'd like to make a stable upload for udisks2, fixing #992152:
"udisks2: please update Recommends on exfat-utils to exfatprogs for Linux

kernel 5"


This issue has already been fixed in unstable/testing and the relevant
changes for bullseye are an upstream cherry-pick and a packaging
cherry-pick.

The changes themselves are trivial. Full debdiff is attached.




Any news here?



I've updated the debdiff to include the fix for CVE-2021-3802
https://security-tracker.debian.org/tracker/CVE-2021-3802

Regards,
Michael
diff --git a/debian/changelog b/debian/changelog
index 51c3b887..0cd4c0d7 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,13 @@
+udisks2 (2.9.2-2+deb11u1) bullseye; urgency=medium
+
+  * Switch debian-branch to debian/bullseye
+  * Use the mkfs command to format exfat partitions
+  * Recommend exfatprogs instead of exfat-utils (Closes: #992152)
+  * mount options: Always use errors=remount-ro for ext filesystems
+(CVE-2021-3802)
+
+ -- Michael Biebl   Fri, 05 Nov 2021 13:15:50 +0100
+
 udisks2 (2.9.2-2) unstable; urgency=medium
 
   * udisksclient: Make get_block_for_drive deterministic.
diff --git a/debian/gbp.conf b/debian/gbp.conf
index 05e704d0..a64b3aab 100644
--- a/debian/gbp.conf
+++ b/debian/gbp.conf
@@ -1,5 +1,5 @@
 [DEFAULT]
 pristine-tar = True
 patch-numbers = False
-debian-branch = debian/master
+debian-branch = debian/bullseye
 upstream-branch = upstream/latest
diff --git 
a/debian/patches/Use-the-mkfs-command-to-format-exfat-partitions.patch 
b/debian/patches/Use-the-mkfs-command-to-format-exfat-partitions.patch
new file mode 100644
index ..8ae84c05
--- /dev/null
+++ b/debian/patches/Use-the-mkfs-command-to-format-exfat-partitions.patch
@@ -0,0 +1,26 @@
+From: Sebastien Bacher 
+Date: Wed, 21 Apr 2021 13:48:36 +0200
+Subject: Use the mkfs command to format exfat partitions
+
+The currently used mkexfatfs is only available in exfat-utils and not in
+the new exfatprogs.
+
+https://github.com/storaged-project/udisks/issues/882
+(cherry picked from commit 1c13dc64213554f979b24788b40398fee7a5039f)
+---
+ src/udiskslinuxfsinfo.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/src/udiskslinuxfsinfo.c b/src/udiskslinuxfsinfo.c
+index 15af26c..8f08242 100644
+--- a/src/udiskslinuxfsinfo.c
 b/src/udiskslinuxfsinfo.c
+@@ -121,7 +121,7 @@ const FSInfo _fs_info[] =
+   NULL,
+   FALSE, /* supports_online_label_rename */
+   FALSE, /* supports_owners */
+-  "mkexfatfs -n $LABEL $DEVICE",
++  "mkfs.exfat -n $LABEL $DEVICE",
+   NULL,
+   NULL, /* option_no_discard */
+ },
diff --git 
a/debian/patches/mount-options-Always-use-errors-remount-ro-for-ext-filesy.patch
 
b/debian/patches/mount-options-Always-use-errors-remount-ro-for-ext-filesy.patch
new file mode 100644
index ..627b5668
--- /dev/null
+++ 
b/debian/patches/mount-options-Always-use-errors-remount-ro-for-ext-filesy.patch
@@ -0,0 +1,55 @@
+From: Tomas Bzatek 
+Date: Wed, 15 Sep 2021 14:34:49 +0200
+Subject: mount options: Always use errors=remount-ro for ext filesystems
+
+Default mount options are focused primarily on data safety, mounting
+damaged ext2/3/4 filesystem as readonly would indicate something's wrong.
+
+(cherry picked from commit 2d5d2b7570b0f44c14b34b5dc831f174205c10f2)
+(cherry picked from commit 38d90a433bda0fc0f2a409f6baa12c3958893571)
+---
+ data/builtin_mount_options.conf| 9 +
+ src/tests/dbus-tests/test_80_filesystem.py | 6 ++
+ 2 files changed, 15 insertions(+)
+
+diff --git a/data/builtin_mount_options.conf b/data/builtin_mount_options.conf
+index 6e50927..962c469 100644
+--- a/data/builtin_mount_options.conf
 b/data/builtin_mount_options.conf
+@@ -27,3 +27,12 @@ 
f2fs_allow=discard,nodiscard,compress_algorithm,compress_log_size,compress_exten
+ xfs_allow=discard,nodiscard,inode32,largeio,wsync
+ 
+ reiserfs_allow=hashed_relocation,no_unhashed_relocation,noborder,notail
++
++ext2_defaults=errors=remount-ro
++ext2_allow=errors=remount-ro
++
++ext3_defaults=errors=remount-ro
++ext3_allow=errors=remount-ro
++
++ext4_defaults=errors=remount-ro
++ext4_allow=errors=remount-ro
+diff --git a/src/tests/dbus-tests/test_80_filesystem.py 
b/src/tests/dbus-tests/test_80_filesystem.py
+index c8bb9f0..c16d32c 100644
+--- a/src/tests/dbus-tests/test_80_filesystem.py
 b/src/tests/dbus-tests/test_80_filesystem.py
+@@ -315,6 +315,8 @@ class UdisksFSTestCase(udiskstestcase.UdisksTestCase):
+ _ret, out = self.run_command('mount | grep %s' % block_fs_dev)
+ self.assertIn(mnt_path, out)
+ self.assertIn('ro', out)
++if self._fs_name.startswith('ext'):
++self.assertIn('errors=remount-ro', 

Bug#998639: RM: sofa-framework -- ROM; unmaintained, low-popcon, RC-buggy for years

[Nilesh Patra]

Package: ftp.debian.org
Severity: normal

Hi,

sofa-framework is unmaintained for years, and has a RC bug (#875184) since 2017.
The popcon is low as well, and the maintainer (Andreas Tille) agrees with the 
removal.

Quoting him,
|Yes. There is no point in keeping this version. I was always tempted to ask 
for removal
|and hesitated for the only reason to keep some "reminder" that we could do 
some effort to package
|this from scratch. This did not happened for >3 years so will probably also 
not happen in the next 3 years thus removal is fine.

Hence, please remove this package from the archive.

Thanks,
Nilesh

Bug#998515: arpwatch generates malformed emails.

[Sergio Alejandro Naranjo Reus]

"ps -U arpwatch -F" output
UID  PIDPPID  CSZ   RSS PSR STIME TTY  TIME
CMD
arpwatch   10821   1  0  3044  6124   1 Nov04 ?00:00:01
/usr/sbin/arpwatch -u arpwatch -i eth0 -f eth0.dat -N -p -F

"dpkg -S /usr/lib/sendmail" output
postfix: /usr/lib/sendmail

Bug#998618: bind9.17.19: crashes with INSIST assertion fail resp->disp->active.tail or .head == or != resp

[Andy Dorman]

Thank you Ondrej,

This is Andy. Michael set up the server many years ago and has left us, 
and I never got around to changing the user address.


I have set up the system to produce a core dump on the next crash and 
restarted named.


I will submit the core dump as soon as I have it.

Again, thank you

--
Andy Dorman
Ironic Design, Inc.
AnteSpam.com

On Fri, 5 Nov 2021 07:13:18 +0100  wrote:

Michael,

do you have full coredump available?

Ondřej 

Bug#834328: fpart does not handle large files on 32-bit machines

[Ganael Laplanche]

On Sun, 14 Aug 2016 15:56:23 +0100 David Banks  wrote:

Hello David,

> At a glance it looks like this is due to breakage in the fts.h API
> which may be automatically fixed with glibc 2.23 in stretch.

FYI it was indeed related to Glibc's fts(3) but it also needed a modification 
in fpart itself, which has now been committed, see:

https://github.com/martymac/fpart/commit/60709098525445ebaa7f0149987a11804fdaeaa5

That change will be integrated in next package updates.

Best regards,

-- 
Ganael Laplanche 
Unix Systems Engineer @CentraleSupelec Rennes

Bug#998638: ruby-localhost: spec/localhost/protocol_spec.rb fails on ci.debian.net and salsa

[Antonio Terceiro]

Source: ruby-localhost
Version: 1.1.8-2
Severity: serious
Tags: bookworm sid ftbfs
User: debian-r...@lists.debian.org
Usertags: ruby3.0

I was looking at the testing migration excuses for puma, which brought
me to ruby-localhost. spec/localhost/protocol_spec.rb very often, but
not always, fails. This is currently blocking testing migration.

Example of failed logs:

on ci.debian.net:
https://ci.debian.net/data/autopkgtest/testing/amd64/r/ruby-localhost/16388045/log.gz

on salsa:
https://salsa.debian.org/ruby-team/ruby-localhost/-/jobs/2150375 (i386 build)
https://salsa.debian.org/ruby-team/ruby-localhost/-/jobs/2150382 (autopkgtest)

I even tried a new upstream version 1.1.9 that is available to see if it
made things better, but it doesn't:
https://salsa.debian.org/ruby-team/ruby-localhost/-/commits/test
https://salsa.debian.org/ruby-team/ruby-localhost/-/pipelines/310716

One option is skipping this test, at least for now, with a patch like
this:

8<8<8<-
diff --git a/debian/ruby-tests.rake b/debian/ruby-tests.rake
index cf1591e..6010dd7 100644
--- a/debian/ruby-tests.rake
+++ b/debian/ruby-tests.rake
@@ -2,4 +2,5 @@ require 'gem2deb/rake/spectask'

 Gem2Deb::Rake::RSpecTask.new do |spec|
   spec.pattern = './spec/**/*_spec.rb'
+  spec.exclude_pattern = './spec/localhost/protocol_spec.rb'
 end
8<8<8<-

But ideally we would want to fix it.

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

Kernel: Linux 5.14.0-2-amd64 (SMP w/4 CPU threads)
Locale: LANG=pt_BR.UTF-8, LC_CTYPE=pt_BR.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


signature.asc
Description: PGP signature

Bug#987996: #987996 RFS: hipercontracer [ITP]

[Bastian Germann]

On Wed, 02 Jun 2021 18:07:09 +0200 Tobias Frost  wrote:

- On a new package, the _only_ changelog entry is that one that closes the ITP.
(in your case delete the new upstream version line and *all* older entries.


You still have two changelog entries in 1.6.3~test1-1


- There are lots of versioned Build-Depends which are already fulfilled in
oldstable. drop those.
  - There is no cmake3 package in Debian, drop that alternative to cmake.
  - It should be sufficient for the boost B-D to just specify the version
agnostic one. Or do I miss the point what you want to archive here?
(beside, oldstable has already 1.62, so no need to say >1.58)


First subtask is fixed, 2nd is still open.


- The examples should be installed using dh_installexamples (not using
*.install)


Also, manpages should not be installed via *.install but via *.manpages.


- I think the user/group handling in postinst is wrong in several ways.
  - hardcoded id of 888. 
  - names should be "invalid names" so that it cannot cause collisions.

  - setting the hoemdirectory to /tmp/ is certainly a bad idea and I
guess insecure. Especially when setting /bin/bash as shell…
  - IOW, Read the Debian Policy on this topic.


Package needs work; therefore tagging moreinfo. Please remove for the next
iteration. I did not do a copyright review.


Also, drop the empty d/tests/control and d/changelog.dist files.

Bug#998513: Update on using "resolution WxH" instead of "resolution=WxH"

[Konstantin Khomoutov]

It turned out I was trying to specify the resolution in a wrong way -
using "resolution=WxH" instead of "resolution WxH".

Still, an attempt to start ROTT the correct way -

 $ rott-commercial window resolution 800x600

(with any supported width and height) fails in exactly the same manner,
as indicated in the original report.