Bug#997045: saga: missing build dependency on pkg-config

[Sebastiaan Couwenberg]

Control: tags -1 pending

This was fixed in git a little while ago, the upload to unstable will
follow soon.

Kind Regards,

Bas

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

Bug#992463: shite appears in wbritish

[Don Armstrong]

Control: fixed -1 2020.12.07-1
Control: found -1 2019.10.06-1

On Fri, 22 Oct 2021, mooff wrote:
> Not that I can see:

Ah; it's in the version I haven't uploaded yet. I'll get that rolled out
shortly.

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

I've had so much good luck recently I was getting sated with it. It's
like sugar, good luck. At first it's very sweet, but after a while you
start to think: any more of this and I shall be sick.
 -- Adam Roberts _Yellow Blue Tibia_ p301

Bug#996969: drop 'close' command --- deprecated since at least February 2002

[Don Armstrong]

Control: tag -1 wontfix

On Thu, 21 Oct 2021, Adrian Bunk wrote:
> On Thu, Oct 21, 2021 at 12:17:25PM -0400, Ryan Kavanagh wrote:
> > Package: bugs.debian.org
> > Severity: wishlist
> > X-Debbugs-Cc: r...@debian.org
> > 
> > The 'close' command has been deprecated since at least February 2002 [0],
> > and its use is strongly discouraged by §5.8.2 of the developers
> > reference:
> > 
> > You should never close bugs via the bug server close command sent to
> > cont...@bugs.debian.org. If you do so, the original submitter will
> > not receive any information about why the bug was closed. [1]
> > 
> > After almost 20 years of deprecation, maybe it's time to finally drop
> > it?
> >...
> 
> If this gets implemented, how are housekeeping actions like [1] supposed 
> to be done?
> 
> How do you suggest to close bugs like #993125 on submission?

Heh; this is actually the first real use for close I've seen.

I'm personally not planning on removing it, but it should continue to be
deprecated in favor of -done for any use when you actually know the bug
number. [I know people have use the fact that the submitter isn't
notified on close as a "feature"...]

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

Live and learn
or die and teach by example
 -- a softer world #625
http://www.asofterworld.com/index.php?id=625

Bug#995198: wsjtx: No transmit audio

[tony mancill]

On Mon, Oct 18, 2021 at 10:41:07AM +0200, Christoph Berg wrote:
> Re: tony mancill
> > That's a good idea.  The diffoscope results in 100MB of diff, almost all
> > of it in the resulting binaries,
> 
> Uh, I guess that was to be expected... sorry for the naive suggestion.

I didn't think it was naive at all.  I merely wanted to point out that
the differences are only in the build environments, and that I'm not
sure how to determine from the binary diffs whether they might
contribute to the change in behavior.

> > environments for now.  There are a number of differences, most of which
> > appear to be benign.  The only significant ones are the GCC-10 -> GCC-11
> > transition and hamlib 4.1 -> 4.3
> 
> wsjtx runs fine here with hamlib 4.3 when still compiled against 4.1;
> I have not tested rebuilding yet.

I went ahead and performed another source upload and will test against
with the resulting binary from the archive.

> > The fact that the "Tune" button couldn't even key my radio, despite the
> > fact that I'm using CAT, makes me suspect that I might have found a issue
> > with running a binary compiled against hamlib 4.1 against a system with
> > 4.3 installed.  That upload was on 2021-10-12, which would explain why I
> > didn't see it a week ago; I updated my system on 2021-10-16.
> 
> Iirc there is some known issue with Tune interfering with audio
> generation if you use the "wrong" button to abort the tune operation;
> wsjtx wouldn't generate audio in the next cycle, but recover in the
> 2nd next cycle. I haven't observed that here lately, but maybe I just
> haven't hit the Tune button enough. (There are probably reports of
> that on wsjt-devel.)
>
> The issue discussed here seems to be something else, but possibly they
> are connected.

I wasn't able to reproduce that issue, and so I assume it is distinct
from the "no audio" issue with both Tune and a normal TX.

Cheers,
tony


signature.asc
Description: PGP signature

Bug#996593: vim: CVE-2021-3875

[James McCoy]

Control: notfound -1 2:8.2.2434-3
Control: notfound -1 2:8.1.0875-5

On Fri, Oct 15, 2021 at 10:23:43PM +0200, Salvatore Bonaccorso wrote:
> The following vulnerability was published for vim.
> 
> CVE-2021-3875[0]:
> | vim is vulnerable to Heap-based Buffer Overflow
> 
> 
> If you fix the vulnerability please also make sure to include the
> CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

It will be part of the next unstable upload.

Note that the buggy feature was introduced in 8.2.3110, so I've removed
the earlier "found" annotations.

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

Bug#926896: sysvinit-utils: pidof is unreliable

[Thorsten Glaser]

On Fri, 22 Oct 2021, Jesse Smith wrote:

> Hurd systems because there is explicitly a check for that and, if it's
> not defined, PATH_MAX is declared in the code. So this code is GNU Hurd
> safe.

To what value? (Spoiler: 1024 is wrong. All other values are also wrong.)

PATH_MAX does not exist on the Hurd because it has no limits.

You should do things like check for get_current_dir_name(3) in libc
and use it if it is present, and dynamically allocate all pathname
storage instead of hardcoding the maximum length.

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


/⁀\ The UTF-8 Ribbon
╲ ╱ Campaign against  Mit dem tarent-Newsletter nichts mehr verpassen:
 ╳  HTML eMail! Also, https://www.tarent.de/newsletter
╱ ╲ header encryption!

Bug#996969: drop 'close' command --- deprecated since at least February 2002

[Paul Wise]

On Fri, 2021-10-22 at 19:05 +0200, Julien Cristau wrote:

> Maybe it should be called "strongly discouraged" everywhere instead of
> deprecated, but there are uses for this command, I don't think we
> should drop it.

I suggest a new design for bug closing:

Make `bts done` and `bts close` both be able to do notified closings
and silent closings.

Add command-line options --notify and --silent to `bts done/close`,
make --notify the default for `bts done` and --silent for `bts close`.

Add config file options for each of `bts close/done` to let people
customise them independently as desired.

Change the template for notified closings to mail -done instead of
control@ and place a Version pseudo-header into the template even when
a version isn't specified.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#981030: RFS: sctk/2.4.10-20151007-1312Z+dfsg2-4 -- speech recognition scoring toolkit

[Bastian Germann]

Control: tags -1 moreinfo

Why don't you package the version 2.4.11 from 
https://github.com/usnistgov/SCTK? It is from Nov 2018.


Usually, you keep the changelog entry for NMUs if you acknowlege (keep 
the patch) them. You did not for -3.1.


Build tests on i386 fail with:
test17: Vietnamese case conversion

Executions complete: Comparing output
   Removing DIFF tests
   Removing SLM tests

 !  TESTS HAVE FAILED  !

Bug#926896: sysvinit-utils: pidof is unreliable

[Jesse Smith]

On 2021-10-22 6:52 p.m., Svante Signell wrote:
> Hi Jesse,
>
> On Thu, 2021-10-21 at 14:51 -0300, Jesse Smith wrote:
>> Please give the attached patch a try and confirm it's working.  It's
>> working here for normal and zombie processes and it seems to be okay
>> for uninterruptable sleep processes too, but I'd like to have someone
>> else confirm everything looks right before I push this upstream.
> Please don't use PATH_MAX in your code, that will eventually cause
> problems. Especially using PATH_MAX will make builds for GNU/Hurd to
> FTBFS.

I inherited it that way. Though in this case it doesn't break for GNU
Hurd systems because there is explicitly a check for that and, if it's
not defined, PATH_MAX is declared in the code. So this code is GNU Hurd
safe.

Jesse

Bug#997049: mapnik silently drops PROJ support with PROJ 8.1.1

[Adrian Bunk]

Source: mapnik
Version: 3.1.0+ds-1
Severity: important
Forwarded: https://github.com/mapnik/mapnik/pull/4202

https://buildd.debian.org/status/fetch.php?pkg=mapnik=amd64=3.1.0%2Bds-1%2Bb2=1634940413=0

...
Checking for C library proj... no
Could not find optional header or shared library for proj
Checking for C library png... yes
Checking for C library webp... yes
Checking for C library tiff... yes
Checking for PROJ_LIB directory...Failed to detect (mapnik-config will have 
null value)
...
Note: will build without these OPTIONAL dependencies:
   - proj (Proj.4 C Projections library | configure with PROJ_LIBS & 
PROJ_INCLUDES | more info: http://trac.osgeo.org/proj/)
...

Bug#994388: tech-ctte: More specific advice regarding merged-/usr and implications of #978636

[David Bremner]

Simon McVittie  writes:

> I'm calling for votes on the following resolution as formal advice from
> the Technical Committee (Constitution §6.1.5). There are no non-accepted
> amendments, so the options to vote on are "yes" or "further discussion".
>
>  begin text to be voted on 
>
> Summary
> ===
>
> There are currently Debian 11 installations with both the merged-/usr and
> non-merged-/usr filesystem layouts. All of these installations should
> successfully upgrade via normal upgrade paths to a merged-/usr Debian 12.
> Only after the release of Debian 12 can packages assume that all
> installations will be merged-/usr.
>
> Main points:
>
> - We have recommended merged-/usr for Debian 12.
> - Moving individual files is not merged-/usr.
> - "Symlink farms" are not merged-/usr.
> - Upgrading a non-merged-/usr system to Debian 12 needs to work.
> - Upgrading a merged-/usr system to Debian 12 needs to work.
> - Packages cannot assume all systems are merged-/usr until the Debian 13
>   development cycle begins.
> - Upgrading via apt in the usual way should work.
> - Testing and QA systems should be able to avoid this transition, but if
>   they do, they cannot be upgraded beyond Debian 12.
> - A package building incorrectly on a non-merged-/usr system is a bug.
> - A package building incorrectly on a merged-/usr system is a bug.
> - Please stop moving individual packages' files from the root filesystem
>   into /usr, at least for now.
>
> Definitions and current status
> ==
>
> libQUAL refers to the directories described in FHS 3.0 section 3.10 [1],
> such as lib64 on the amd64 architecture.
>
> Merged /usr is the filesystem layout in which /bin, /sbin, /lib and each
> /libQUAL that exists are symbolic links to the corresponding directories
> below /usr. This results in aliasing between /bin and /usr/bin, and
> so on.
>
> In the merged-/usr layout, files whose canonical logical location is
> in one of the affected directories on the root filesystem, such as
> /bin/bash, /sbin/fsck and /lib/ld-linux.so.2, are physically located at
> the corresponding path below /usr, such as /usr/bin/bash. Each file in
> one of the affected directories is accessible via two paths: its canonical
> logical location (such as /bin/bash or /usr/bin/env), and the other path
> implied by the aliasing (such as /usr/bin/bash or /bin/env).
>
> There are two supported categories of Debian 11 installation, which are
> currently considered equally-supported:
>
> - Merged-/usr installations. These were installed with debian-installer
>   from Debian 10 or later, or installed with debootstrap --merged-usr,
>   or converted from the non-merged-/usr layout by installing the usrmerge
>   package, or installed or converted by any similar procedure. They have
>   the merged-/usr layout.
>
> - Non-merged-/usr installations. These were installed with debian-installer
>   from Debian 9 or earlier and subsequently upgraded without converting
>   to merged-/usr, or installed with debootstrap --no-merged-usr, or
>   converted from the merged-/usr layout with dpkg's "dpkg-fsys-usrunmess"
>   utility or any similar procedure. They have the traditional,
>   non-merged-/usr layout in which /bin/bash and /usr/bin/env have exactly
>   those physical paths, and /usr/bin/bash and /bin/env do not exist.
>
> Merged-/usr is not the only filesystem layout that has been proposed for
> unifying the root filesystem with /usr. For avoidance of doubt, we do not
> consider other filesystem layouts to be implementations of merged-/usr.
> In particular, we do not consider these to be implementations of merged-/usr:
>
> - all affected files physically located in /bin, /sbin, /lib and /libQUAL,
>   with /usr/bin as a symlink to /bin, etc. (this is the reverse of
>   merged-/usr, and was historically used in the hurd-i386 port)
>
> - a "symlink farm" in each of /bin, /sbin, /lib, /libQUAL with individual
>   symbolic links such as /bin/bash -> /usr/bin/bash for only those files that
>   historically had their canonical logical location on the root filesystem
>
> - a "symlink farm" in each of /bin, /sbin, /lib, /libQUAL with individual
>   symbolic links such as /bin/env -> /usr/bin/env for all files in the
>   affected directories, regardless of whether they historically had
>   their canonical logical location on the root filesystem
>
> [1]: 
> https://www.debian.org/doc/packaging-manuals/fhs/fhs-3.0.html#libltqualgtAlternateFormatEssential
>
> Upgrade path from Debian 11 to Debian 12
> 
>
> The technical committee resolved in #978636 [2] that Debian 12 'bookworm'
> should only support the merged-/usr layout. This resolution describes
> the implications of that decision in more detail.
>
> Debian installations have traditionally had a straightforward upgrade
> path between consecutive releases, and the technical committee expects
> maintainers to continue this. In the case of #978636, the 

Bug#997011: llvm-toolchain-13: FTBFS on mipsel: undefined reference to lldb_private::process_linux::NativeRegisterContextLinux::CreateHostNativeRegisterContextLinux in lldb-server

[John Paul Adrian Glaubitz]

Hi Simon!

The issue occurs on MIPS and 32-bit PowerPC when LLVM is built with LLDB
enabled, see [1]. It can be worked around by disabling LLDB on the affected
targets.

Adrian

> [1] https://reviews.llvm.org/D102872

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#997048: raku-tap-harness: Deprecated code warning: "Method status"

[Wolfgang Weisselberg]

Package: raku-tap-harness
Version: 0.1.0-2
Severity: normal
File: /usr/share/perl6/debian-sources/raku-tap-harness/lib/TAP.pm

Dear Maintainer,

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?

Running "prove6 ." on the "hello-world" exercise of the raku-track of
exercism.org on my local machine. (Not that that depends on
prove6 or what code prove6 tests.)

   * What was the outcome of this action?

___

$ prove6 .
hello-world.rakutest .. ok 
All tests successful.
Files=1, Tests=1,  0 wallclock secs
Result: PASS
Saw 1 occurrence of deprecated code.

Method status (from Proc) seen at:
  /usr/lib/perl6/vendor/sources/6FEC28FA0762AC132736C81C67CCDB823E5E83FA (TAP), 
lines 104,111
Please use exitcode and/or signal methods (status is to be removed in 2022.06) 
instead.

Please contact the author to have these occurrences of deprecated code
adapted, so that this message will disappear!

$ cmp /usr/lib/perl6/vendor/sources/6FEC28FA0762AC132736C81C67CCDB823E5E83FA \
  /usr/share/perl6/debian-sources/raku-tap-harness/lib/TAP.pm && echo Identical
Identical
$
___

   * What outcome did you expect instead?

No deprecation warning.



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

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

Versions of packages raku-tap-harness depends on:
ii  rakudo  2021.09-1

raku-tap-harness recommends no packages.

raku-tap-harness suggests no packages.

-- no debconf information

Bug#992841: Solved the problem

[Frank Ehmsen]

Hi,

so stupid. Microsoft Teams is only able to handle video resolutions
smaller than 1280x720.
Switch the output resolution to 1280x720 and it works. 
Please close the Bug as this is not a problen in Debian, V4L2 or obs-
studio.

Bye,

Frank


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

Bug#997046: aravis: watch file: no udates gnome anymore

[Chiara Marmo]

Thanks Ben,
I'm waiting to have my development environment back to fix it. :(

Best
Chiara

On Fri, Oct 22, 2021 at 12:00 PM Ben Tris  wrote:

> Source: aravis
> Severity: important
>
> Dear Maintainer,
>
> It seems the gnome download location is not used anymore, probably has to
> be
> changed to GitHub.
> https://github.com/AravisProject/aravis
>
>
>
> Maybe handy.
> https://www.gezapig.nl/Free.html
>
>
>
> -- System Information:
> Debian Release: 10.11
>   APT prefers oldstable-updates
>   APT policy: (500, 'oldstable-updates'), (500,
> 'oldstable-proposed-updates'), (500, 'oldstable')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 4.19.0-18-amd64 (SMP w/4 CPU cores)
> Locale: LANG=nl_NL.UTF-8, LC_CTYPE=nl_NL.UTF-8 (charmap=UTF-8),
> LANGUAGE=nl_NL.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
>

Bug#997047: RFS: rednotebook/2.22+ds-2~bpo11+1 -- Modern desktop diary and personal journaling tool

[Philip Wyett]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "rednotebook":

 * Package name: rednotebook
   Version : 2.22+ds-2~bpo11+1
   Upstream Author : Jendrik Seipp 
 * URL : https://rednotebook.app
 * License : GPL-3+, GPL-2+, CC0-1.0, PSF-2, LGPL-3+
 * Vcs : https://github.com/jendrikseipp/rednotebook
   Section : text

It builds those binary packages:

  rednotebook - Modern desktop diary and personal journaling tool

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

  https://mentors.debian.net/package/rednotebook/

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

  dget -x 
https://mentors.debian.net/debian/pool/main/r/rednotebook/rednotebook_2.22+ds-2~bpo11+1.dsc

Changes since the last upload:

 rednotebook (2.22+ds-2~bpo11+1) bullseye-backports; urgency=medium
 .
   * Rebuild for bullseye-backports.

Regards

Phil

-- 
*** Playing the game for the games own sake. ***

WWW: https://kathenas.org

Twitter: @kathenasorg

IRC: kathenas

GPG: 724AA9B52F024C8B


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

Bug#997046: aravis: watch file: no udates gnome anymore

[Ben Tris]

Source: aravis
Severity: important

Dear Maintainer,

It seems the gnome download location is not used anymore, probably has to be
changed to GitHub.
https://github.com/AravisProject/aravis



Maybe handy.
https://www.gezapig.nl/Free.html



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

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

Bug#926896: sysvinit-utils: pidof is unreliable

[Svante Signell]

Hi Jesse,

On Thu, 2021-10-21 at 14:51 -0300, Jesse Smith wrote:
> Please give the attached patch a try and confirm it's working.  It's
> working here for normal and zombie processes and it seems to be okay
> for uninterruptable sleep processes too, but I'd like to have someone
> else confirm everything looks right before I push this upstream.

Please don't use PATH_MAX in your code, that will eventually cause
problems. Especially using PATH_MAX will make builds for GNU/Hurd to
FTBFS.

Thanks!

Bug#997045: saga: missing build dependency on pkg-config

[Adrian Bunk]

Source: saga
Version: 7.3.0+dfsg-5
Severity: serious
Tags: ftbfs

https://tests.reproducible-builds.org/debian/rb-pkg/bookworm/amd64/saga.html
https://buildd.debian.org/status/logs.php?pkg=saga=7.3.0%2Bdfsg-5%2Bb2

...
checking for omp_get_num_threads in -lgomp... yes
checking for libsvm/svm.h... yes
checking for svm_get_svm_type in -lsvm... yes
./configure: line 17489: syntax error near unexpected token `DXFLIB,'
./configure: line 17489: `PKG_CHECK_MODULES(DXFLIB, dxflib, 
LIBDXFFOUND=1,LIBDXFFOUND=0)'

Bug#997044: ITP: markdown-it-py -- a Python port of markdown-it and some its associated plugins

[Emmanuel Arias]

Package: wnpp
Severity: wishlist
Owner: Emmanuel Arias 
X-Debbugs-Cc: debian-pyt...@lists.debian.org

* Package name: markdown-it-py
  Version : 1.1.0
  Upstream Author : Chris Sewell 
* URL : https://github.com/executablebooks/markdown-it-py
* License : Expat
  Programming Lang: Python
  Description : a Python port of markdown-it and some its associated
plugins
.
markdown-it-py is a Python port of markdown-it and its associated plugins.
The
design philosophy of the port has been to change as little of the
fundamental code
structure (file names, function name, etc) as possible. just sprinkling in
a little Python
syntactic sugar.
.
I plan to maintain it under the DPT umbrella.


Chers,
Emmanuel

Bug#997043: ITP: python-pytest-toolbox -- useful plugins for pytest

[Michael Fladischer]

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: python-pytest-toolbox
  Version : 0.4
  Upstream Author : Samuel Colvin 
* URL : https://github.com/samuelcolvin/pytest-toolbox
* License : Expat
  Programming Lang: Python
  Description : useful plugins for pytest

Numerous useful plugins for pytest like fixtures, methods and comparison
objects.

I intend to maintain this package as part of the DPT.

-BEGIN PGP SIGNATURE-

iQFFBAEBCgAvFiEEqVSlRXW87UkkCnJc/9PIi5l90WoFAmFzKTYRHGZsYWRpQGRl
Ymlhbi5vcmcACgkQ/9PIi5l90Wq6SAgAvz2X/aId04AcsBpC4aQdVB0BwY6HPghA
2f0Zk7bdx9MA8vB9AtHWpHcrNjOIZJBhCv91zTfbZ3VVwbB9eormXw6yl+YPPB8h
SXOOcXJDVt1iz6Dy/HOFKEEd2dROWw9XtlJ4j1ttIR+bvJlULNxmUDgNCbdAZcsE
gdOH3fYtcGxJ/Uxkphoicd6gGHDw68t8y3tY6UJ7RtqUy9KmfP+vt+n3+aqFDIGZ
uLy14sQ6ZteSXlPHNjEuPvQvujDeaWjNgXOl6UPFxAg3YLMKs/Dve8qAq3OPwaWz
r1YdiiwYml2V30cXKoMvhrmBkmlEwU2z8PQHV2rfulqPVKSof6bW4A==
=hPTV
-END PGP SIGNATURE-

Bug#997016: RFS: swtpm/0.7.0-rc2-1 [ITA] -- Libtpms-based TPM emulator

[Bastian Germann]

On Fri, 22 Oct 2021 20:33:38 +0900 Seunghun Han  wrote:

 swtpm (0.7.0-rc2-1) unstable; urgency=medium
 .
   * New maintainer (Closes: #941199)
   * Changed Standard-Version to 4.5.1 in debian/control
   * Updated debhelper version to 13 in debian/control
   * Added Rules-Requires-Root to debian/control
   * Added Vcs-Browser and Vcs-Git to debian/control
   * Converted debian/copyright to dep5-copyright format
   * Added debian/watch file
   * Fixed typos in source code and man pages


Why all these when you are closing an ITP? The entry which closes the ITP should be 
rephrased and the other entries dropped.

Bug#997042: bino: watch file: wrong address

[Ben Tris]

Package: bino
Severity: important

Dear Maintainer,

The developer has changed the download address.
For more info see.
https://bino3d.org/download.html



maybe handy.
https://www.gezapig.nl/Free.html



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

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

Versions of packages bino depends on:
ii  libass9  1:0.14.0-2
ii  libavcodec58 7:4.1.8-0+deb10u1
ii  libavdevice587:4.1.8-0+deb10u1
ii  libavformat587:4.1.8-0+deb10u1
ii  libavutil56  7:4.1.8-0+deb10u1
ii  libc62.28-10
ii  libgcc1  1:8.3.0-6
ii  libgl1   1.1.0-1
ii  libglew2.1   2.1.0-4
ii  liblirc-client0  0.10.1-6.3~deb10u1
ii  libopenal1   1:1.19.1-1
ii  libqt5core5a 5.11.3+dfsg1-1+deb10u4
ii  libqt5gui5   5.11.3+dfsg1-1+deb10u4
ii  libqt5opengl55.11.3+dfsg1-1+deb10u4
ii  libqt5widgets5   5.11.3+dfsg1-1+deb10u4
ii  libstdc++6   8.3.0-6
ii  libswscale5  7:4.1.8-0+deb10u1

bino recommends no packages.

bino suggests no packages.

Bug#994564: RFS: sosreport/4.2-1 -- Set of tools to gather troubleshooting data from a system

[Bastian Germann]

Hi Eric,

I would take a look and maybe sponsor sosreport if you bring the git into sync with the 
currently released 4.0-2. Adding your 4.2-1 changes on top would also be nice, especially 
if it is not a bulk commit.


Thanks,
Bastian

Bug#997041: redisearch: New repo and upstream releases available

[Michael Fladischer]

Package: redisearch
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear Maintainer,

upstream development has moved to a new repository at:

https://github.com/RediSearch/RediSearch

There have been quite a few releases too since the move took place. Would you
consider switching to the new repo and packaging the newer releases?

Thanks,
Michael


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

Kernel: Linux 5.10.63-rockchip64 (SMP w/6 CPU threads; PREEMPT)
Kernel taint flags: TAINT_CRAP
Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_DK.UTF-8), LANGUAGE=en_DK.UTF-8
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

-BEGIN PGP SIGNATURE-

iQFFBAEBCgAvFiEEqVSlRXW87UkkCnJc/9PIi5l90WoFAmFzH3ARHGZsYWRpQGRl
Ymlhbi5vcmcACgkQ/9PIi5l90WqurQf6AjTL1lMqUUKOlVyk05w8haw6bmGEaY9a
eCwoYzvqwy2Ok1dfIgQfoJtpqtVC1zgmvU4odSjtm1LE4NjMNuyoLohzdV1Awi6B
QiL64om5C1K/dOUMTxlpwZdNlYvty7MOSwvVykR+KHQnZJboz0Pb3wxaLrAq93/J
Qwt7ZVGquvxSQy1zPyN72Y/FOmPQDWzV2mY3yEtOuqW4s1gartgyKaLCKLabsNDi
ts9+sgdKQqBRZLmaIfwngxfJ7par/8uN5nh1duPgVxu8Gcx2w6RusO1yModgw07s
715inQsGqnrfV2Nj/cXOcesC5gP9cxA5yIppY/dcREJqDVl19I4Ocg==
=oAzA
-END PGP SIGNATURE-

Bug#984342: source-highlight: diff for NMU version 3.1.9-4.1

[Boyuan Yang]

Control: tags 984342 + patch
Control: tags 984342 + pending

Dear maintainer,

I've prepared an NMU for source-highlight (versioned as 3.1.9-4.1) and
uploaded it to DELAYED/5. Please feel free to tell me if I
should delay it longer.

Regards.

diff -Nru source-highlight-3.1.9/debian/changelog source-highlight-
3.1.9/debian/changelog
--- source-highlight-3.1.9/debian/changelog 2020-08-02 16:01:04.0
-0400
+++ source-highlight-3.1.9/debian/changelog 2021-10-22 16:25:06.0
-0400
@@ -1,3 +1,14 @@
+source-highlight (3.1.9-4.1) unstable; urgency=high
+
+  * Non-maintainer upload.
+  * Apply patch from Ubuntu:
+
+  [ Graham Inggs ]
+  * Remove "throw" specifications to fix build with GCC 11
+(Closes: #984342)
+
+ -- Boyuan Yang   Fri, 22 Oct 2021 16:25:06 -0400
+
 source-highlight (3.1.9-3) unstable; urgency=medium
 
   * Added VCS and will be maintained at salsa
diff -Nru source-highlight-3.1.9/debian/gitlab-ci.yml source-highlight-
3.1.9/debian/gitlab-ci.yml
--- source-highlight-3.1.9/debian/gitlab-ci.yml 1969-12-31 19:00:00.0
-0500
+++ source-highlight-3.1.9/debian/gitlab-ci.yml 2021-10-22 16:23:56.0
-0400
@@ -0,0 +1,10 @@
+image: registry.salsa.debian.org/salsa-ci-team/ci-image-git-
buildpackage:latest
+
+build:
+  artifacts:
+paths:
+- "*.deb"
+expire_in: 1 day
+  script:
+- gitlab-ci-git-buildpackage-all
+
diff -Nru source-highlight-3.1.9/debian/patches/gcc11.patch source-highlight-
3.1.9/debian/patches/gcc11.patch
--- source-highlight-3.1.9/debian/patches/gcc11.patch   1969-12-31
19:00:00.0 -0500
+++ source-highlight-3.1.9/debian/patches/gcc11.patch   2021-10-22
16:24:26.0 -0400
@@ -0,0 +1,30 @@
+Description: Remove "throw" specifications
+ C++ throw specifications were deprecated in C++11.
+ This patch removes them from the library.
+Bug-Debian: https://bugs.debian.org/984342
+Origin: upstream,
https://git.savannah.gnu.org/cgit/src-highlite.git/commit/?id=904949c9026cb772dc93fbe0947a252ef47127f4
+Author: Tom Tromey 
+Last-Update: 2020-06-10
+
+--- a/lib/srchilite/fileutil.cc
 b/lib/srchilite/fileutil.cc
+@@ -48,7 +48,7 @@
+ // FIXME avoid using a global variable
+ std::string start_path;
+ 
+-string readFile(const string ) throw (IOException) {
++string readFile(const string ) {
+ ifstream file(fileName.c_str());
+ 
+ if (!file.is_open()) {
+--- a/lib/srchilite/fileutil.h
 b/lib/srchilite/fileutil.h
+@@ -27,7 +27,7 @@
+  * @return the contents of the file
+  * @throw IOException
+  */
+-string readFile(const string ) throw (IOException);
++string readFile(const string );
+ 
+ //char *read_file(const string );
+ 
diff -Nru source-highlight-3.1.9/debian/patches/series source-highlight-
3.1.9/debian/patches/series
--- source-highlight-3.1.9/debian/patches/series2020-08-02
16:01:04.0 -0400
+++ source-highlight-3.1.9/debian/patches/series2021-10-22
16:24:26.0 -0400
@@ -1 +1,2 @@
 fix-national-encoding.patch
+gcc11.patch


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

Bug#984036: disulfinder: ftbfs with GCC-11

[Nilesh Patra]

On 10/22/21 9:23 PM, Étienne Mollier wrote:

Hi Nilesh,

Nilesh Patra, on 2021-10-22:

looks like C++17 has removed the provision to specify custom
exceptions, and there are a lot of errors like the one above.
In this case, does it makes sense to force C++14 standard
(with chnages in d/rules or with patches) in such cases and
ask upstream to clean these up? Or do I miss a relatively easy
solutions?


It depends.  If I read correctly the porting guide to Gcc 11 [1]
and if the number of occurrence of the issue is reasonable, then
you can just patch the throw(BadOptionSetting) occurrences to
replace them by noexcept(false).  If the number of occurrences
is too high to make a patch viable, then similarly to mothur,
the advice from Aaron M. Ucko applies: informing upstream and
temporarily getting back to C++14 is probably the saner course
of action.


Maketh sense, thanks for explaining.
I guess the main problem here will be with dead upstreams, which have a number 
of these occurances,
looks like we need to propagate hacks (probably for a very long time) for these 
cases.

For disulfinder, the patch does not look as simple as changing 3 lines, so I'm 
admittedly tempted to
force c++14 here :-P

Nilesh




OpenPGP_signature
Description: OpenPGP digital signature

Bug#997039: lighttpd segfaults every few minutes

[Glenn Strauss]

"lighttpd.conf" is not the whole lighttpd configuration.
Print the config with: lighttpd -f /etc/lighttpd/lighttpd.conf -p

Your probable error is well-documented as user misconfiguration:
$SERVER["socket"] must not be nested in other lighttpd config conditions

https://wiki.lighttpd.net/Docs_SSL#Configuration
https://wiki.lighttpd.net/Docs_Configuration#Conditional-Configuration

Bug#992876: RFS: dune-pdelab/2.8~20213108-1 -- toolbox for solving PDEs -- discretization module (documentation)

[Bastian Germann]

On Tue, 24 Aug 2021 16:46:00 +0200 Lisa Julia Nebel wrote:

dune-pdelab (2.8~20213108-1) experimental; urgency=medium
.
* New upstream snapshot.
* d/rules: Explicitly set buildsystem to CMake.
* Update patches.


Where have you got a v2.8 snapshot from? Latest git commit still has 2.7.
There is no point in sponsoring this if it does not fix #976499. Please check in the 
changelog or by building on arm64 if it is fixed.

Bug#984036: disulfinder: ftbfs with GCC-11

[Étienne Mollier]

Hi Nilesh,

Nilesh Patra, on 2021-10-22:
> looks like C++17 has removed the provision to specify custom
> exceptions, and there are a lot of errors like the one above.
> In this case, does it makes sense to force C++14 standard
> (with chnages in d/rules or with patches) in such cases and
> ask upstream to clean these up? Or do I miss a relatively easy
> solutions?

It depends.  If I read correctly the porting guide to Gcc 11 [1]
and if the number of occurrence of the issue is reasonable, then
you can just patch the throw(BadOptionSetting) occurrences to
replace them by noexcept(false).  If the number of occurrences
is too high to make a patch viable, then similarly to mothur,
the advice from Aaron M. Ucko applies: informing upstream and
temporarily getting back to C++14 is probably the saner course
of action.

[1]: https://gcc.gnu.org/gcc-11/porting_to.html

In hope this helps,
Have a nice day,  :)
-- 
Étienne Mollier 
Fingerprint:  8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
Sent from /dev/pts/2, please excuse my verbosity.


signature.asc
Description: PGP signature

Bug#994388: tech-ctte: More specific advice regarding merged-/usr and implications of #978636

[Elana Hashman]

On Wed, Oct 13, 2021 at 08:13:08PM +0100, Simon McVittie wrote:
> I'm calling for votes on the following resolution as formal advice from
> the Technical Committee (Constitution §6.1.5). There are no non-accepted
> amendments, so the options to vote on are "yes" or "further discussion".

I vote (belatedly, for the record):

yes > FD

- e

> 
>  begin text to be voted on 
> 
> Summary
> ===
> 
> There are currently Debian 11 installations with both the merged-/usr and
> non-merged-/usr filesystem layouts. All of these installations should
> successfully upgrade via normal upgrade paths to a merged-/usr Debian 12.
> Only after the release of Debian 12 can packages assume that all
> installations will be merged-/usr.
> 
> Main points:
> 
> - We have recommended merged-/usr for Debian 12.
> - Moving individual files is not merged-/usr.
> - "Symlink farms" are not merged-/usr.
> - Upgrading a non-merged-/usr system to Debian 12 needs to work.
> - Upgrading a merged-/usr system to Debian 12 needs to work.
> - Packages cannot assume all systems are merged-/usr until the Debian 13
>   development cycle begins.
> - Upgrading via apt in the usual way should work.
> - Testing and QA systems should be able to avoid this transition, but if
>   they do, they cannot be upgraded beyond Debian 12.
> - A package building incorrectly on a non-merged-/usr system is a bug.
> - A package building incorrectly on a merged-/usr system is a bug.
> - Please stop moving individual packages' files from the root filesystem
>   into /usr, at least for now.
> 
> Definitions and current status
> ==
> 
> libQUAL refers to the directories described in FHS 3.0 section 3.10 [1],
> such as lib64 on the amd64 architecture.
> 
> Merged /usr is the filesystem layout in which /bin, /sbin, /lib and each
> /libQUAL that exists are symbolic links to the corresponding directories
> below /usr. This results in aliasing between /bin and /usr/bin, and
> so on.
> 
> In the merged-/usr layout, files whose canonical logical location is
> in one of the affected directories on the root filesystem, such as
> /bin/bash, /sbin/fsck and /lib/ld-linux.so.2, are physically located at
> the corresponding path below /usr, such as /usr/bin/bash. Each file in
> one of the affected directories is accessible via two paths: its canonical
> logical location (such as /bin/bash or /usr/bin/env), and the other path
> implied by the aliasing (such as /usr/bin/bash or /bin/env).
> 
> There are two supported categories of Debian 11 installation, which are
> currently considered equally-supported:
> 
> - Merged-/usr installations. These were installed with debian-installer
>   from Debian 10 or later, or installed with debootstrap --merged-usr,
>   or converted from the non-merged-/usr layout by installing the usrmerge
>   package, or installed or converted by any similar procedure. They have
>   the merged-/usr layout.
> 
> - Non-merged-/usr installations. These were installed with debian-installer
>   from Debian 9 or earlier and subsequently upgraded without converting
>   to merged-/usr, or installed with debootstrap --no-merged-usr, or
>   converted from the merged-/usr layout with dpkg's "dpkg-fsys-usrunmess"
>   utility or any similar procedure. They have the traditional,
>   non-merged-/usr layout in which /bin/bash and /usr/bin/env have exactly
>   those physical paths, and /usr/bin/bash and /bin/env do not exist.
> 
> Merged-/usr is not the only filesystem layout that has been proposed for
> unifying the root filesystem with /usr. For avoidance of doubt, we do not
> consider other filesystem layouts to be implementations of merged-/usr.
> In particular, we do not consider these to be implementations of merged-/usr:
> 
> - all affected files physically located in /bin, /sbin, /lib and /libQUAL,
>   with /usr/bin as a symlink to /bin, etc. (this is the reverse of
>   merged-/usr, and was historically used in the hurd-i386 port)
> 
> - a "symlink farm" in each of /bin, /sbin, /lib, /libQUAL with individual
>   symbolic links such as /bin/bash -> /usr/bin/bash for only those files that
>   historically had their canonical logical location on the root filesystem
> 
> - a "symlink farm" in each of /bin, /sbin, /lib, /libQUAL with individual
>   symbolic links such as /bin/env -> /usr/bin/env for all files in the
>   affected directories, regardless of whether they historically had
>   their canonical logical location on the root filesystem
> 
> [1]: 
> https://www.debian.org/doc/packaging-manuals/fhs/fhs-3.0.html#libltqualgtAlternateFormatEssential
> 
> Upgrade path from Debian 11 to Debian 12
> 
> 
> The technical committee resolved in #978636 [2] that Debian 12 'bookworm'
> should only support the merged-/usr layout. This resolution describes
> the implications of that decision in more detail.
> 
> Debian installations have traditionally had a straightforward upgrade
> path between 

Bug#994275: Call for votes on "Reverting breaking changes in debianutils"

[Elana Hashman]

On Wed, Oct 20, 2021 at 12:30:54PM -0700, Sean Whitton wrote:
> Hello,
> 
> I hereby call for votes on the following ballot to resolve #994275.  The
> voting period starts immediately and lasts for up to one week, or until
> the outcome is no longer in doubt (Constitution 6.3.1).
> 
> === Resolution A ===
> 
> The Technical Committee resolves:
> 
> 1. The debianutils package must continue to provide the which(1) program
>until a compatible utility is available in a package that is at least
>transitively essential in Debian 12.
> 
>For the Debian 12 release, we expect which(1) to be in either an
>Essential package or a transitively Essential package (that is, a
>package that is depended on by an Essential package).
> 
> 2. The which(1) program must not print any deprecation warnings.
> 
> 3. We decline to overrule the maintainer of debianutils regarding the
>use of alternatives.  If another package takes over responsibility
>for which(1), then the debianutils maintainers and the other
>package's maintainers should coordinate to choose a suitable
>mechanism, which might be either versioned Depends/Breaks/Replaces,
>dpkg-divert, alternatives or something else.
> 
> 4. The debianutils package must continue to provide the tempfile(1)
>program until a compatible utility is available in a package that is
>at least transitively essential in Debian 12.
> 
>For the Debian 12 release, we expect tempfile(1) to be in either an
>Essential package or a transitively Essential package.
> 
> 5. Programs in debianutils must not be moved to /usr until we have a
>project-wide consensus on going ahead with such a move, and any
>programs that have already been moved must be moved back.  In
>particular, this means debianutils must contain /bin/run-parts and
>/sbin/installkernel for the time being.
> 
> === Resolution B ===
> 
> As Resolution A, except strike point (2) and renumber succeeding items.
> 
> === End Resolutions ===
> 
> A: Issue Resolution A
> B: Issue Resolution B
> F: Further Discussion


I vote:

B > A > F

- e


signature.asc
Description: PGP signature

Bug#997039: lighttpd segfaults every few minutes

[M . ‘quintus’ Gülker]

Package: lighttpd
Version: 1.4.59-1
Severity: normal
X-Debbugs-Cc: post+debb...@guelker.eu

Dear Maintainer,

lighttpd crashes every few minutes with a segmentation fault. Systemd will
restart it, but this is obviously not the way it should be. Here is
an excerpt from journalctl -u lighttpd.service:

Okt 22 18:04:37 zugspitze systemd[1]: Started Lighttpd Daemon.
Okt 22 19:46:56 zugspitze systemd[1]: lighttpd.service: Main process 
exited, code=killed, status=11/SEGV
Okt 22 19:46:56 zugspitze systemd[1]: lighttpd.service: Failed with result 
'signal'.
Okt 22 19:46:56 zugspitze systemd[1]: lighttpd.service: Consumed 4.581s CPU 
time.
Okt 22 19:46:56 zugspitze systemd[1]: lighttpd.service: Scheduled restart 
job, restart counter is at 28.
Okt 22 19:46:56 zugspitze systemd[1]: Stopped Lighttpd Daemon.
Okt 22 19:46:56 zugspitze systemd[1]: lighttpd.service: Consumed 4.581s CPU 
time.
Okt 22 19:46:56 zugspitze systemd[1]: Starting Lighttpd Daemon...
Okt 22 19:46:57 zugspitze systemd[1]: Started Lighttpd Daemon.
Okt 22 19:57:05 zugspitze systemd[1]: lighttpd.service: Main process 
exited, code=killed, status=11/SEGV
Okt 22 19:57:05 zugspitze systemd[1]: lighttpd.service: Failed with result 
'signal'.
Okt 22 19:57:05 zugspitze systemd[1]: lighttpd.service: Consumed 2.718s CPU 
time.
Okt 22 19:57:05 zugspitze systemd[1]: lighttpd.service: Scheduled restart 
job, restart counter is at 29.
Okt 22 19:57:05 zugspitze systemd[1]: Stopped Lighttpd Daemon.
Okt 22 19:57:05 zugspitze systemd[1]: lighttpd.service: Consumed 2.718s CPU 
time.
Okt 22 19:57:05 zugspitze systemd[1]: Starting Lighttpd Daemon...
Okt 22 19:57:06 zugspitze systemd[1]: Started Lighttpd Daemon.
Okt 22 19:57:08 zugspitze systemd[1]: lighttpd.service: Main process 
exited, code=killed, status=11/SEGV
Okt 22 19:57:08 zugspitze systemd[1]: lighttpd.service: Failed with result 
'signal'.
Okt 22 19:57:08 zugspitze systemd[1]: lighttpd.service: Consumed 2.474s CPU 
time.
Okt 22 19:57:09 zugspitze systemd[1]: lighttpd.service: Scheduled restart 
job, restart counter is at 30.
Okt 22 19:57:09 zugspitze systemd[1]: Stopped Lighttpd Daemon.
Okt 22 19:57:09 zugspitze systemd[1]: lighttpd.service: Consumed 2.474s CPU 
time.
Okt 22 19:57:09 zugspitze systemd[1]: Starting Lighttpd Daemon...
Okt 22 19:57:10 zugspitze systemd[1]: Started Lighttpd Daemon.
Okt 22 19:57:14 zugspitze systemd[1]: lighttpd.service: Main process 
exited, code=killed, status=11/SEGV
Okt 22 19:57:14 zugspitze systemd[1]: lighttpd.service: Failed with result 
'signal'.
Okt 22 19:57:14 zugspitze systemd[1]: lighttpd.service: Consumed 2.473s CPU 
time.
Okt 22 19:57:14 zugspitze systemd[1]: lighttpd.service: Scheduled restart 
job, restart counter is at 31.
Okt 22 19:57:14 zugspitze systemd[1]: Stopped Lighttpd Daemon.
Okt 22 19:57:14 zugspitze systemd[1]: lighttpd.service: Consumed 2.473s CPU 
time.
Okt 22 19:57:14 zugspitze systemd[1]: Starting Lighttpd Daemon...
Okt 22 19:57:15 zugspitze systemd[1]: Started Lighttpd Daemon.
Okt 22 20:13:58 zugspitze systemd[1]: lighttpd.service: Main process 
exited, code=killed, status=11/SEGV
Okt 22 20:13:58 zugspitze systemd[1]: lighttpd.service: Failed with result 
'signal'.
Okt 22 20:13:58 zugspitze systemd[1]: lighttpd.service: Consumed 2.797s CPU 
time.
Okt 22 20:13:59 zugspitze systemd[1]: lighttpd.service: Scheduled restart 
job, restart counter is at 32.
Okt 22 20:13:59 zugspitze systemd[1]: Stopped Lighttpd Daemon.
Okt 22 20:13:59 zugspitze systemd[1]: lighttpd.service: Consumed 2.797s CPU 
time.
Okt 22 20:13:59 zugspitze systemd[1]: Starting Lighttpd Daemon...
Okt 22 20:14:00 zugspitze systemd[1]: Started Lighttpd Daemon.
Okt 22 20:26:19 zugspitze systemd[1]: lighttpd.service: Main process 
exited, code=killed, status=11/SEGV
Okt 22 20:26:19 zugspitze systemd[1]: lighttpd.service: Failed with result 
'signal'.
Okt 22 20:26:19 zugspitze systemd[1]: lighttpd.service: Consumed 2.642s CPU 
time.
Okt 22 20:26:20 zugspitze systemd[1]: lighttpd.service: Scheduled restart 
job, restart counter is at 33.
Okt 22 20:26:20 zugspitze systemd[1]: Stopped Lighttpd Daemon.
Okt 22 20:26:20 zugspitze systemd[1]: lighttpd.service: Consumed 2.642s CPU 
time.
Okt 22 20:26:20 zugspitze systemd[1]: Starting Lighttpd Daemon...
Okt 22 20:26:21 zugspitze systemd[1]: Started Lighttpd Daemon.
Okt 22 20:26:24 zugspitze systemd[1]: lighttpd.service: Main process 
exited, code=killed, status=11/SEGV
Okt 22 20:26:24 zugspitze systemd[1]: lighttpd.service: Failed with result 
'signal'.
Okt 22 20:26:24 zugspitze systemd[1]: lighttpd.service: Consumed 2.474s CPU 
time.
Okt 22 20:26:25 zugspitze systemd[1]: lighttpd.service: Scheduled restart 
job, restart counter is at 34.
Okt 22 20:26:25 zugspitze systemd[1]: Stopped Lighttpd Daemon.
Okt 22 20:26:25 zugspitze 

Bug#995900: abr2gbr: diff for NMU version 1:1.0.2-3

[Boyuan Yang]

Control: tags 995900 + patch
Control: tags 995900 + pending

Dear maintainer,

I've prepared an NMU for abr2gbr (versioned as 1:1.0.2-3) and
uploaded it to DELAYED/13. Please feel free to tell me if I
should delay it longer.

Regards.

diff -Nru abr2gbr-1.0.2/debian/changelog abr2gbr-1.0.2/debian/changelog
--- abr2gbr-1.0.2/debian/changelog  2020-02-17 16:29:46.0 -0500
+++ abr2gbr-1.0.2/debian/changelog  2021-10-22 15:30:49.0 -0400
@@ -1,3 +1,9 @@
+abr2gbr (1:1.0.2-3) unstable; urgency=medium
+
+  * Take over package maintenance via ITS process. (Closes: #995900)
+
+ -- Boyuan Yang   Fri, 22 Oct 2021 15:30:49 -0400
+
 abr2gbr (1:1.0.2-2.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru abr2gbr-1.0.2/debian/control abr2gbr-1.0.2/debian/control
--- abr2gbr-1.0.2/debian/control2010-08-27 15:13:41.0 -0400
+++ abr2gbr-1.0.2/debian/control2021-10-22 15:30:49.0 -0400
@@ -1,7 +1,7 @@
 Source: abr2gbr
 Section: x11
 Priority: extra
-Maintainer: alice ferrazzi (aliceinwire) 
+Maintainer: Boyuan Yang 
 Build-Depends: debhelper (>= 7.0.50~), libglib2.0-dev
 Standards-Version: 3.9.1
 Homepage: http://www.sunnyspot.org/gimp/tools.html


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

Bug#997038: evince: Print preview of PS file get blank page and en error "fatal internal error -100"

[Davide Prina]

Package: evince
Version: 41.2-1
Severity: normal
X-Debbugs-Cc: davide.pr...@gmail.com

Dear Mainteiner,

when I try to do a print preview I have a blank page, the same if I try to 
print it.
PS file is obtained with pdftops program (I used it to print faster PDF files 
on ps printers) and some time ago (probably about 2 year ago, befoure covid) I 
used it a lot.

I can reproduce the bug with any ps generated file, for example:

$ pdftops /usr/share/debian-reference/debian-reference.en.pdf ref.ps

$ evince ref.ps 

and when I try to see the print preview I get blank page.

I see that there are same bug reports on similar issues, but I see that they 
are old (so not my case) and I see that there was a bug #977754 on evince now 
closed and I think that the problem is the same solved with PDF file.

When I try to print or print preview a ps file obtained by pdftops i get:

$ evince a.ps
GPL Ghostscript 9.54.0: Unrecoverable error, exit code 1
(libspectre) ghostscript reports: fatal internal error -100

I have try to use valgrind, but I get only "blocks 
definitely/indirectly/possibly lost"

Looking at libspectre1 package I can see that:

I found that this error is generate calling in the spectre_gs_run function the 
instruction:
gsapi_init_with_args (gs->ghostscript_instance, n_args, args);

the three values are:

gs->ghostscript_instance: 0x5583febe7ed0 (so it is not null)
n_args: 10
 arg[0]=libspectre
 arg[1]=-dMaxBitmap=1000
 arg[2]=-dBATCH
 arg[3]=-dNOPAUSE
 arg[4]=-dSAFER
 arg[5]=-P-
 arg[6]=-sDEVICE=pdfwrite
 arg[7]=-sOutputFile=/tmp/user/1000/evince_print.pdf.AVDQB1
 arg[8]=-c
 arg[9]=.setpdfwrite

Ciao
Davide


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

Kernel: Linux 5.14.9-dp-20211009 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=it_IT.utf8, LC_CTYPE=it_IT.utf8 (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 evince depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.40.0-2
ii  evince-common41.2-1
ii  gsettings-desktop-schemas41.0-1
ii  libatk1.0-0  2.36.0-2
ii  libc62.32-4
ii  libcairo-gobject21.16.0-5
ii  libcairo21.16.0-5
ii  libevdocument3-4 41.2-1
ii  libevview3-3 41.2-1
ii  libgdk-pixbuf-2.0-0  2.42.6+dfsg-2
ii  libglib2.0-0 2.70.0-1+b1
ii  libgnome-desktop-3-1941.0-1
ii  libgtk-3-0   3.24.30-3
ii  libhandy-1-0 1.4.0-1
ii  libnautilus-extension1a  41.0-1
ii  libpango-1.0-0   1.48.10+ds1-1
ii  libpangocairo-1.0-0  1.48.10+ds1-1
ii  libsecret-1-00.20.4-2
ii  shared-mime-info 2.0-1

Versions of packages evince recommends:
ii  dbus-user-session [default-dbus-session-bus]  1.12.20-2
ii  dbus-x11 [dbus-session-bus]   1.12.20-2

Versions of packages evince suggests:
ii  gvfs 1.48.1-2
ii  nautilus-sendto  3.8.6-3.1
ii  poppler-data 0.4.11-1
ii  unrar1:6.0.7-5

-- no debconf information

Bug#996668: additional information

[Matt Yates]

I ran 'journalctl -b -1' and this is the part where the shutdown hang
happens:

Oct 22 14:41:06 db11 systemd[1]: session-2.scope: Killing process 5663
(cinnamon-launch) with signal SIGKILL.
Oct 22 14:41:06 db11 systemd[1]: session-2.scope: Killing process 5721
(n/a) with signal SIGKILL.
Oct 22 14:41:06 db11 systemd[1]: session-2.scope: Killing process 5723
(cinnamon-launch) with signal SIGKILL.
Oct 22 14:41:06 db11 systemd[1]: session-2.scope: Failed with result
'timeout'.

I ran 'ps aux | grep cinnamon' and found the PID for cinnamon-launcher.  I
killed it and it respawned.  I killed it a second time and it did not
respawn.  After that, I shutdown using the cinnamon menu with no hang.

I'm not sure what 'cinnamon-launcher' does, but I guess this problem does
not have to do with cinnamon-settings-daemon as I originally thought.

Bug#997037: kvirc: reproducible builds: embeds username in .html documentation

[Vagrant Cascadian]

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

The username is embedded in various .html documentation files:

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

  ./usr/share/kvirc/5.0/help/en/class_button.html

  
KVIrc·5.0.0·Documentation·-·generated·by·pbuilder1·on·Sat·Jul·10·07:26:08·2021
vs.
  
KVIrc·5.0.0·Documentation·-·generated·by·pbuilder2·on·Sat·Jul·10·07:26:08·2021

The attached patch fixes this by removing the username from gendoc.pl
which generates the documentation.

The patch also removes the timestamp, which appears to respect
SOURCE_DATE_EPOCH and is reproducible, but does not really convey useful
information for the documentation.


With these patches applied, kvirc should become reproducible on
tests.reproducible-builds.org when the patched version lands in
bookworm/testing (there are build path variations tested for
experimental/unstable that are unresolved).


Thanks for maintaining kvirc!


live well,
  vagrant
From 49843daa21cd2df04694340eca7ff2059dcab372 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Fri, 22 Oct 2021 17:57:50 +
Subject: [PATCH 2/2] admin/gendoc.pl: Remove user and timestamp from generated
 documentation.

---
 admin/gendoc.pl | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/admin/gendoc.pl b/admin/gendoc.pl
index 6ee0959..2576da1 100755
--- a/admin/gendoc.pl
+++ b/admin/gendoc.pl
@@ -203,7 +203,7 @@ sub print_header
 
 sub print_footer
 {
-	print $g_filehandle "KVIrc $g_version Documentation - generated by $g_currentuser on $g_currenttime\n";
+	print $g_filehandle "KVIrc $g_version Documentation\n";
 	print $g_filehandle "\n";
 	print $g_filehandle "\n";
 }
-- 
2.33.0



signature.asc
Description: PGP signature

Bug#994275: Call for votes on "Reverting breaking changes in debianutils"

[Christoph Berg]

> === Resolution A ===
> 
> The Technical Committee resolves:
> 
> 1. The debianutils package must continue to provide the which(1) program
>until a compatible utility is available in a package that is at least
>transitively essential in Debian 12.
> 
>For the Debian 12 release, we expect which(1) to be in either an
>Essential package or a transitively Essential package (that is, a
>package that is depended on by an Essential package).
> 
> 2. The which(1) program must not print any deprecation warnings.
> 
> 3. We decline to overrule the maintainer of debianutils regarding the
>use of alternatives.  If another package takes over responsibility
>for which(1), then the debianutils maintainers and the other
>package's maintainers should coordinate to choose a suitable
>mechanism, which might be either versioned Depends/Breaks/Replaces,
>dpkg-divert, alternatives or something else.
> 
> 4. The debianutils package must continue to provide the tempfile(1)
>program until a compatible utility is available in a package that is
>at least transitively essential in Debian 12.
> 
>For the Debian 12 release, we expect tempfile(1) to be in either an
>Essential package or a transitively Essential package.
> 
> 5. Programs in debianutils must not be moved to /usr until we have a
>project-wide consensus on going ahead with such a move, and any
>programs that have already been moved must be moved back.  In
>particular, this means debianutils must contain /bin/run-parts and
>/sbin/installkernel for the time being.
> 
> === Resolution B ===
> 
> As Resolution A, except strike point (2) and renumber succeeding items.
> 
> === End Resolutions ===
> 
> A: Issue Resolution A
> B: Issue Resolution B
> F: Further Discussion

I vote A > B > F.

Christoph


signature.asc
Description: PGP signature

Bug#996852: "Error: failed to load BTF from ./fat: Invalid argument"

[Salvatore Bonaccorso]

Control: tags -1 + upstream

Hi Philipp,

On Tue, Oct 19, 2021 at 05:59:41PM +0200, Philipp Marek wrote:
> Package: bpftool
> Version: 5.14.12-1
> Severity: minor
> X-Debbugs-Cc: phil...@marek.priv.at
> 
> Using an absolute path, I get output:
> 
> [/sys/kernel/btf]$ bpftool btf dump file $PWD/fat | head -2
> [85705] STRUCT 'fat_mount_options' size=48 vlen=27
> 'fs_uid' type_id=506 bits_offset=0
> [/sys/kernel/btf]$ bpftool btf dump file $PWD/fat | wc
> 6852274   25834
> 
> Using a relative path, "bpftool btf dump" doesn't work:
> 
> [/sys/kernel/btf]$ bpftool btf dump file ./fat
> Error: failed to load BTF from ./fat: Invalid argument
> 
> 
> "strace" shows that with a full path "bpftool" reads
> "/sys/kernel/btf/vmlinux", but doesn't even try to find that in the
> second case.
> 
> Dumping "vmlinux" works with a relative path,
> I guess because it's self-contained.
> 
> 
> Copying "fat" and "vmlinux" to /tmp/ and using a relative or absolute
> path works for "vmlinux", but not "fat".
> 
> I think it would be great if a relative path would just be translated
> to absolute when needed, or that required files would be searched via
> some path list (configurable via environment, like $PATH or
> $LD_LIBRARY_PATH etc.?).

Can you please report this directly to upstream
(scripts/get_maintainer.pl can help to get who to contact) and once
the upstream report is done, reference it here please?

Regards,
Salvatore

Bug#902413: systemd-tmpfiles migration warning

[Peter Nowee]

> This is fixed in 0.11.2-2 (bullseye aka stable).

Note that this was only fixed for the systemd unit file, not for the
init script `/etc/init.d/fail2ban` (which is `files/debian-initd` in
the fail2ban source). That file still has 5 occurrences of `/var/run`:

https://salsa.debian.org/python-team/packages/fail2ban/-/blob/debian/0.11.2-2/files/debian-initd

Upstream as well:

https://github.com/fail2ban/fail2ban/blob/0.11.2/files/debian-initd

See the full patch by Gabriel Filion in message 17:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=902413#17

Best regards,
Peter Nowee

Bug#996479: httpie: Version 2.6.0 available

[bartosz]

The difference is quite obvious *build*-dependencies are needed just to
build package while runtime dependencies are needed only to run
particular program. 


Most common scenario is building documentation or running tests which
usually requires dependencies not really needed once it's done. 


But thanks a lot for clarification which packages are needed for which
stuff. 

Anyway. We're blocked by lack of charset-normalizer in Debian. 


The good news is that it was already uploaded:
https://ftp-master.debian.org/new/python-charset-normalizer_2.0.6-1.html


The bad news is that NEW queue is quite overloaded and it's hard to
estimate when it will hit archive. 

https://ftp-master.debian.org/new.html 


regards
Bartosz Fenski

On 2021-10-22 12:14, Mickaël Schoentgen wrote:

Hey Bartosz, 

Thanks for having a look. 

They are all runtime dependencies. 

- charset-normalizer is a new requirement since HTTPie 2.6.0, always needed as you saw it. 

- defusedxml is needed when treating XML responses. The import error would be encountered only at that time. 

- requests-toolbelt is always required, but the missing charset-normalizer error is simply shadowing its requirement. 

Trice are build and runtime dependencies (I guess, I am not sure about the difference: without them, HTTPie will not work properly, or not work at all). 


Regards,

On 10/22/21 9:45 AM, bart...@fenski.pl wrote: 

So one more thing which is most probably blocker for now. 

Does new httpie depend on python-charset-normalizer? I mean for runtime. 

(fenio@debian) ➜  httpie http 
Traceback (most recent call last): 
File "/usr/bin/http", line 33, in  
sys.exit(load_entry_point('httpie==2.6.0', 'console_scripts', 'http')()) 
File "/usr/lib/python3/dist-packages/httpie/__main__.py", line 8, in main 
from httpie.core import main 
File "/usr/lib/python3/dist-packages/httpie/core.py", line 13, in  
from .client import collect_messages 
File "/usr/lib/python3/dist-packages/httpie/client.py", line 15, in  
from .encoding import UTF8 
File "/usr/lib/python3/dist-packages/httpie/encoding.py", line 3, in  
from charset_normalizer import from_bytes 
ModuleNotFoundError: No module named 'charset_normalizer'


If that's the case then this package is not yet available in Debian. It sits in NEW queue[1][2]. 

Also I was able to build package without python3-defusedxml, python3-socks and python3-requests-toolbelt. 

Are these really build dependencies? Or maybe they are also runtime dependencies but I didn't hit issues with them since charset normalizer is being called prior to them? 


regards
Bartosz Fenski

On 2021-10-14 16:50, Mickaël Schoentgen wrote: 


Package: httpie
Severity: normal

Hello dear maintainers,

I've just released HTTPie 2.6.0, it brings interesting changes and bug fixes:

- Added support for formatting & coloring of JSON bodies preceded by non-JSON 
data (e.g., an XXSI prefix).
- Added charset auto-detection when Content-Type doesn't include it.
- Added --response-charset to allow overriding the response encoding for 
terminal display purposes.
- Added --response-mime to allow overriding the response mime type for coloring 
and formatting for the terminal.
- Added the ability to silence warnings through using -q or --quiet twice (e.g. 
-qq).
- Added installed plugin list to --debug output.
- Fixed duplicate keys preservation in JSON data.

I guess the bug report about upgrading HTTPie 2.5.0 should be closed then 
(#993937)?

Thanks in advance.

Note: I changed the severity from wishlist to normal as HTTPie is obsolete on 
every Debian-derived distributions (mostly because it is too on Debian itself).
I kindly hope to improve the situation, maybe is there another way to make the 
process smoother, and painless, for everyone?

--
Mickaël Schoentgen
https://www.tiger-222.fr


--
Mickaël SCHOENTGEN
https://www.tiger-222.fr

Bug#880576: targetcli-fb: Cannot create PSCSI backend for SCSI tape drive

[Christian Scheffczyk]

Hello Maintainers,

was this problem fixed ever?
I'm running exactly into the same problem while trying to configure
a changer and some tape drives as targets!
I don't like the manual hack in a production environment.
The problem was reported 4 years ago!
Any news on that?

Thanks and kind regards, Christian



smime.p7s
Description: S/MIME Cryptographic Signature

Bug#996794: ncbi-acc-download: autopkgtest failure with python-biopython 1.79+dfsg-1~0exp0 in experimental

[Étienne Mollier]

Control tags -1 fixed-upstream pending

Aaron M. Ucko, on 2021-10-20:
> Étienne Mollier  writes:
> 
> > The issue turned out to be related, and I came up with some
> > hackery to smoothen the transition to python-biopython 1.79.
> > The corresponding patch is in attachment.  I welcome remarks,
> > since I'm only half happy with the result, although I tried hard
> > to make sure it is functionally equivalent.
> 
> Great, thanks!  I suppose it might be slightly cleaner to factor out a
> helper predicate function.

Good point, replacing the isinstance call by a helper such as a
hypothetical isunknownseq would have preserved the existing
logic.  Upstream followed an approach not too far from it, and
kept things simple by bumping dependency to Biopython 1.79 in
ncbi-acc-download 0.2.8.  Let's move to unstable.

Have a nice day,  :)
-- 
Étienne Mollier 
Fingerprint:  8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
Sent from /dev/pts/2, please excuse my verbosity.


signature.asc
Description: PGP signature

Bug#675748: Where is the show command?

[Kyle Lyon]

Where is the show command located? The dumpavail function is inside of
apt-main/cmdline/aptcache.cc, so where is the show command?

Bug#997036: kvirc: reproducible-builds: Build path in RPATH

[Vagrant Cascadian]

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

The RPATH contains the build path resulting in different builds.

The attached patch to debian/rules pesses
-DCMAKE_BUILD_RPATH_USE_ORIGIN=ON to configure, which should result in
relative paths for RPATH.

This patch does not resolve all reproducibility issues, but
significantly reduces the diff between builds.


Thanks for maintaining kvirc!


live well,
  vagrant
From 20535d92844e0ca653c8a1b381cb5d200dc666f3 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Fri, 22 Oct 2021 17:55:16 +
Subject: [PATCH 1/2] debian/rules: Remove buildpath from rpath to improve
 reproducibility.

Pass -DCMAKE_BUILD_RPATH_USE_ORIGIN=ON to configure.

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

diff --git a/debian/rules b/debian/rules
index a8d8ac8..284c92a 100755
--- a/debian/rules
+++ b/debian/rules
@@ -22,6 +22,7 @@ override_dh_auto_configure:
 			-DWANT_COEXISTENCE=OFF \
 			-DWANT_ESD=OFF -DWANT_OSS=OFF \
 			-DWANT_STRIP=OFF \
+			-DCMAKE_BUILD_RPATH_USE_ORIGIN=ON \
 			-DLIB_SUFFIX="/$(DEB_HOST_MULTIARCH)"
 
 override_dh_install:
-- 
2.33.0



signature.asc
Description: PGP signature

Bug#996897: Should not suggest postgresql-12-plr

[Christoph Berg]

Re: Andreas Tille
> > please don't reference specific PostgreSQL versions in your
> > dependencies as the number changes each year, and it is already wrong
> > as 13 is current, and we are moving to 14:
> 
> I understand the issue but postgresql-plr is only a virtual package
> and I need to specify a real package as first alternative.  Do you
> see any chance to have a real postgresql-plr package depending from
> the versioned one?

I don't think you need the real package there - postgresql-12-plr has
been removed a year ago, and the dependency is even wrong in the
released bullseye package. I'd just drop it and go with
postgresql-plr.

Afaict the "real package first" requirement is only there for
build-dependencies.

So far we have refrained from adding empty dependency packages to each
of the PG extension packages because there's already enough
micro-packages, and these extra packages don't even solve the problem
completely.

Christoph

Bug#996995: dh-python: Unable to parse debian/control

[stefanor]

Hi Chris (2021.10.22_08:24:04_+)

Thanks for the bug and the patch. I'm going to take a slightly different
approach (and add test coverage).

I thought it was too good to be true when my parsing rewrite passed all
the tests on the first attempt :P

SR

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

Bug#982298: dh-python: deprecated test command 'python3.9 setup.py test'

[Stefano Rivera]

Hi Piotr (2021.02.09_03:26:04_-0800)
> > > actually… pybuild should invoke something like this:
> > > `{interpreter} -m unittest discover -v {args}`
> > > so I don't know where "setup.py test" came from. Can you point me to
> 
> pybuild *does* that for distutils plugin. I will not change it in this
> release cycle as I don't know how many packages depend on that

It's the next cycle, so let's do this.

I'm doing some testing to see what effect this will have. There are
about 500 affected packages, as far as I can tell.

SR

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

Bug#997023: sakura: Incorrect usage of PRIMARY and CLIPBOARD selections

[Fabio Cobianchi]

Package: sakura
Version: 3.7.1-2
Severity: normal
X-Debbugs-Cc: c...@mailbox.org

Dear Maintainer,

* What exactly did you do (or not do) that was effective (or ineffective)?
- launch a sakura terminal;
- type 'ls /';
- select the word 'bin';
- press the right mouse button and select 'copy' from the dropdown menu (copy 
to CLIPBOARD);
- select the word 'home' (copy to PRIMARY);

- now press the right mouse button and select 'paste' (paste from CLIPBOARD);
- now press the middle mouse button (paste from PRIMARY);

* What was the outcome of this action?
- on the prompt I get 'homehome';

* What outcome did you expect instead?
- on the prompt I should get 'binhome';

This happens also if you switch the order:
- if you select some text, it gets copied in both PRIMARY and CLIPBOARD;
- if you use menu->copy, it gets copied in both PRIMARY and CLIPBOARD;

I'm currently using 'sakura_3.7.1-2_amd64.deb', the last version that does not 
have this bug;
I also tried the version 3.8.4-1 in unstable and is still bugged;

I  have found this commits in the source code that chenge the clipboard 
behaviour after
version 3.7.1, but I do not really understand what they do:

* Solve problem with duplicates when pasting with middle button 

* Make copy on select to clipboard the default and only behavior 

add config support for button behavior 


Probably related bugs?
Pasting using the middle button pasts the selection and clipboard together 

Pasting using the middle button pasts from the clipboard and not selection 


Thank You.

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

Kernel: Linux 5.14.0-2-amd64 (SMP w/8 CPU threads)
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.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 sakura depends on:
ii  libc6   2.32-4
ii  libglib2.0-02.70.0-1+b1
ii  libgtk-3-0  3.24.30-3
ii  libpango-1.0-0  1.48.10+ds1-1
ii  libvte-2.91-0   0.64.2-3

sakura recommends no packages.

sakura suggests no packages.

-- no debconf information

Bug#990885: ITP: intel-acm: Authenticated code modules for Intel CPUs

[kretcheu]

owner 990885 timo.lindf...@iki.fi

Bug#996997: buster-pu: Cleaning up the http-parser ABI breakage in Debian 10 ("buster")

[Christoph Biedl]

Thanks for your swift and kind response.

Adam D. Barratt wrote...

> On Fri, 2021-10-22 at 09:18 +0200, Christoph Biedl wrote:

> > ## Rework the patch
> > 
> > Revert the ABI break by reworking the patch to restore the previous
> > struct layout - while maintaining the purpose of the change: Storing
> > a ninth status bit. Hilko Bengen did a great job implementing this,
> > and also reported success with several tests.
> > 
> This seems like the best option if we can, although I realise it does
> break from our usual desire to use a patch as-implemented in later
> versions.
> 
> Do you already have a proposed new upload / debdiff?

Find a debdiff attached, there is a lengthy explanation in the patch.

Still open on my side is a *huge* round of tests, preferably all
archtectures supported in buster, especially big-endian. This may take
major parts of the weekend.

> > PS: Related, do you check autopkgtest (...)
> 
> We did discuss this on IRC briefly, but for the record - there's a
> britney instance that produces "excuses" for p-u and o-p-u, including
> scheduling autopkgtests via ci.d.n. The results show up on our tracking
> pages and we (mainly Paul; thanks!) investigate any failures raised to
> determine if they resulted from the proposed update and, if so, what to
> do about that.

Follow-up question, I might have asked that before or it has already
been answered: In case a package gets an update via a stable point
release ... I think it makes sense to take this as a chance to add an
autopkgtest if not present yet?

Rationale: The tang package I maintain as well was updated via a stable
point release in January. If I had included a backported autopkgtest, we
would have learned about the current issue in http-parser in time.

Christoph
diff -Nru http-parser-2.8.1/debian/changelog http-parser-2.8.1/debian/changelog
--- http-parser-2.8.1/debian/changelog  2021-06-04 20:59:56.0 +0200
+++ http-parser-2.8.1/debian/changelog  2021-10-22 19:02:29.0 +0200
@@ -1,3 +1,11 @@
+http-parser (2.8.1-1+deb10u2) NOT-FOR-RELEASE; urgency=medium
+
+  + NOT FOR RELEASE: This is only for review and testing.
+  * Fix ABI breakage introduced by accident in 2.8.1-1+deb10u1.
+Closes: #996460, #996939, #996997
+
+ -- Christoph Biedl   Fri, 22 Oct 2021 
19:02:29 +0200
+
 http-parser (2.8.1-1+deb10u1) buster; urgency=medium
 
   * Cherry-pick "Support multi-coding Transfer-Encoding".
diff -Nru http-parser-2.8.1/debian/patches/fix-ABI-breakage.patch 
http-parser-2.8.1/debian/patches/fix-ABI-breakage.patch
--- http-parser-2.8.1/debian/patches/fix-ABI-breakage.patch 1970-01-01 
01:00:00.0 +0100
+++ http-parser-2.8.1/debian/patches/fix-ABI-breakage.patch 2021-10-22 
19:02:29.0 +0200
@@ -0,0 +1,191 @@
+Subject: Fix ABI breakage introduced by accident in 2.8.1-1+deb10u1
+Author: Hilko Bengen 
+Date: 2021-10-22
+Bug-Debian:
+https://bugs.debian.org/996460
+https://bugs.debian.org/996939
+https://bugs.debian.org/996997
+Comment: (by the http-parser maintainer)
+   The fix for CVE-2019-15605 introduced an ABI break by changing the
+   layout of struct http_parser - a change that was needed to store a
+   ninth bit in the "flags" field. However, this affected offsets of
+   fields declared as public, causing applications to break.
+
+   To restore the previous layout while stil implementing the fix: Steal
+   one bit from the content_length element (the remaining 63 are more
+   than enough) to store the newly introduced F_TRANSFER_ENCODING flag.
+   Also rename the constant to F_TRANSFER_ENCODING2 as a safeguard
+   against applications that try to manipulate information that is by
+   definition private.
+
+   Thanks a lot to Hilko Bengen for the idea, implementation, a first
+   round of tests and many suggestions. -CB
+
+--- a/http_parser.c
 b/http_parser.c
+@@ -25,9 +25,7 @@
+ #include 
+ #include 
+ 
+-#ifndef ULLONG_MAX
+-# define ULLONG_MAX ((uint64_t) -1) /* 2^64-1 */
+-#endif
++#define CONTENT_LENGTH_MAX (((uint64_t)-1) >> 1)
+ 
+ #ifndef MIN
+ # define MIN(a,b) ((a) < (b) ? (a) : (b))
+@@ -724,7 +722,8 @@
+ if (ch == CR || ch == LF)
+   break;
+ parser->flags = 0;
+-parser->content_length = ULLONG_MAX;
++parser->flags2 = 0;
++parser->content_length = CONTENT_LENGTH_MAX;
+ 
+ if (ch == 'H') {
+   UPDATE_STATE(s_res_or_resp_H);
+@@ -759,7 +758,8 @@
+   case s_start_res:
+   {
+ parser->flags = 0;
+-parser->content_length = ULLONG_MAX;
++parser->flags2 = 0;
++parser->content_length = CONTENT_LENGTH_MAX;
+ 
+ switch (ch) {
+   case 'H':
+@@ -923,7 +923,8 @@
+ if (ch == CR || ch == LF)
+   break;
+ parser->flags = 0;
+-parser->content_length = ULLONG_MAX;
++parser->flags2 = 0;
++parser->content_length = CONTENT_LENGTH_MAX;
+ 
+ if (UNLIKELY(!IS_ALPHA(ch))) {
+   

Bug#997035: openssh: Please build-depend on libsystemd-dev | libelogind-dev

[Svante Signell]

Source: openssh
Version: 8.4p1-6
Severity: important
Tags: patch
Usertags: linux

Hi,

Currently openssh FTBFS on GNU/Linux due to a build dependency on
libsystemd-dev.

The attached patch, debian_control.diff fixes this problem by build-
depending on libsystemd-dev | libelogind-dev for linux-any.

This patch has been used to successfully build openssh on GNU/Linux
with libelogind-dev (and libelogind0) installed (on a Debian box not
using systemd)

Thanks!




--- a/debian/control	2021-08-19 12:04:01.0 +0200
+++ b/debian/control	2021-10-22 19:08:32.214710620 +0200
@@ -17,7 +17,7 @@
libpam0g-dev | libpam-dev,
libselinux1-dev [linux-any],
libssl-dev (>= 1.1.0g),
-   libsystemd-dev [linux-any],
+   libsystemd-dev | libelogind-dev [linux-any],
libwrap0-dev | libwrap-dev,
pkg-config,
zlib1g-dev (>= 1:1.2.3),

Bug#997034: exim4-daemon-heavy: enable redis lookup

[Slavko]

Package: exim4-daemon-heavy
Version: 4.95-2
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Please, enable redis lookup in heavy daemon package, to allow easy sharing
information between multiple exim instances.

thanks

-BEGIN PGP SIGNATURE-

iQFFBAEBCAAvFiEEwhNakIB2F5/fdXmSAQVZxpJoYkcFAmFy8scRHGxpbnV4QHNs
YXZpbm8uc2sACgkQAQVZxpJoYkdBQgf+KDpbcNP7c0wHB+vvzd9QtDgJk/jKJJE6
QsvZzmQyNRKSzhn1RJv+DiRyHecvuGAY+vIZ/Wbc2wyDU38sN9YiD5yGvy4EYjF+
w9TRZsuGg2bh4yjDDXpCphUcewIBbisMq9JpKRC/KolbnadrfrtNi2GUJUUKW2RP
gBr2Ihm/xRu31XkuWX0MXmn7jfRg4JaFCl7p2NCLRr3m7Uf3la+AtAZ3ORHZRIMv
CxKwM+/yQ6C4QnrLqV7NotiWpv4DTFoS7i7mPZOuHSCp4HoNy1XUfgMdUBa1vGLw
qux6PebxP7fN6YZw2x+/1wLfzHoDKQzfoeBa0Tty0Gw11cn/CZRhwA==
=j1EI
-END PGP SIGNATURE-

Bug#995366: xfce4-pulseaudio-plugin: repeatedly polls D-Bus names, should watch NameOwnerChanged instead

[Yves-Alexis Perez]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

control: forwarded -1 
https://gitlab.xfce.org/panel-plugins/xfce4-pulseaudio-plugin/-/issues/65
On Thu, 2021-09-30 at 11:39 +0100, Simon McVittie wrote:
> I tried to report this upstream, but so far I have been unable to set
> up an account on XFCE's Gitlab (presumably the email confirmation has
> been greylisted).

Hi Simon,
I've reported the bug upstream:
https://gitlab.xfce.org/panel-plugins/xfce4-pulseaudio-plugin/-/issues/65

I'll let you know if something happens there.

Regards,
- -- 
Yves-Alexis
-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAmFy70UACgkQ3rYcyPpX
RFsbmggAiW5YoBQRNOSjzwqS7XH4ieBOloNNCLViYNAQ7fmT3wTjKUmmak0oVY+K
B6pNlmKoYUMiBUJNWNKXxuGn/r+qMoVbRb0zLMpzlgfhDlRb49iWH+EFSNwXtb7K
wD+Tb+39xrXVTyghOzcfrXdAMswRpvYaIznNmhgLmDXyixeE/5tMVBbVfQq2nLa3
Mztx0IfbRkASP760hEcs1wtN9SQ6e3kgtE4TcMY7ZiRJiI34qiUprUbNwRs247G+
jPT+VnwPHnqxs+tybRjkVnkL33mIlsOlknBsGsm7GJgj65Egj2tPqzxsHM/aJKO/
3jWGXaAIeJkWlqG/gacv/OGlUwvf3w==
=05jG
-END PGP SIGNATURE-

Bug#993903: Acknowledgement (xfce4-session: After resuming from suspend, the synaptic touchpad was no longer working)

[Yves-Alexis Perez]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Sat, 2021-09-25 at 12:29 -0400, Wirawan Purwanto wrote:
> So this should be filed as a bug with the XFCE4 settings daemon, I
> think (xfce4-settings). The bugfix should be fairly easy, I suppose,
> but it will require a hook that is invoked when the computer going to
> sleep: when the touchpad is supposed to be disabled only temporarily,
> it should be re-enabled upon resumption from sleep.

Hi Wirawan,

could you check with a recent xfce4-settings then? Stable has 4.16.2 now.

Regards,
- -- 
Yves-Alexis
-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAmFy768ACgkQ3rYcyPpX
RFuF5Qf9FVJpW6WYBEbFScLhpSjHybW8AIvOLBO7L+EAWyZDA44ZzIJIk7yueWwA
oCg/MqXVIdK+7T/p5fWaPZdn/W33NtcehJ0Rikjwmwt3WZpuprjDHZx0WUSvQp4K
MppLvkqNIrXCPMNj3S0LpLE0johLjVarc39CTt2mn6BwCJTw/wL/Titpb2R+7Cig
iiSP6A2fp6j627JUfbsTyFP/9GEKxVY9f4vxEmJEuZm3TwSZdjqD3LNT1bvP+y9A
h0kXNh2/lCvpXtcGE/gf3P2AsXJthcNrCZDs+dQKt88b7Xn9am5LEzTsnB0kqz10
BcUDD/kY51cE0lYp4V6K7m4FKXGRRQ==
=d7MM
-END PGP SIGNATURE-

Bug#997033: sfxr-qt: FTBFS on s390x

[Bastian Germann]

Package: sfxr-qt
Severity: important
Version: 1.3.0+git20210422-1

The build fails on s390x because of test fails:

test cases:  2 |  0 passed | 2 failed
assertions: 33 | 25 passed | 8 failed

https://buildd.debian.org/status/fetch.php?pkg=sfxr-qt=s390x=1.3.0%2Bgit20210422-1=1634207353

Same results on powerpc and ppc64, so I guess it is a big-endian issue.

Bug#997032: xserver-xorg: Lax the dependency on xserver-xorg-video-all | xorg-driver-video

[Michael Krylov]

Package: xserver-xorg
Version: 1:7.7+22
Severity: wishlist

Dear Maintainer,

Nowadays with the ubiquitous usage of modesetting driver,
xserver-xorg-video-* drivers are not required to run X server. I'd like
to suggest X server maintainers to change the dependency of xserver-xorg
package on xserver-xorg-video-all | xorg-driver-video to recommendation
or maybe even a suggestion.

I think it will not hurt most of the users, but those who use just the
modesetting driver will be able to remove those packages.

-- Package-specific info:
X server symlink status:

lrwxrwxrwx 1 root root 13 Jul 16  2015 /etc/X11/X -> /usr/bin/Xorg
-rwxr-xr-x 1 root root 274 Apr 13  2021 /usr/bin/Xorg

The lspci command was not found; not including PCI data.

Xorg X server configuration file status:

-rw-r--r-- 1 root root 2148 Oct 19 00:17 /etc/X11/xorg.conf

Contents of /etc/X11/xorg.conf:
---
Section "ServerLayout"
Identifier "X.org Configured"
Screen  0  "Main" 0 0
InputDevice"Thinkpad Mouse" "CorePointer"
InputDevice"Thinkpad Keyboard" "CoreKeyboard"
EndSection

Section "ServerFlags"
Option "DontZap" "false"
EndSection

Section "Files"
ModulePath   "/usr/lib/xorg/modules"
FontPath "/usr/share/fonts/X11/misc"
FontPath "/usr/share/fonts/X11/cyrillic"
FontPath "/usr/share/fonts/X11/100dpi/:unscaled"
FontPath "/usr/share/fonts/X11/75dpi/:unscaled"
FontPath "/usr/share/fonts/X11/Type1"
FontPath "/usr/share/fonts/X11/100dpi"
FontPath "/usr/share/fonts/X11/75dpi"
FontPath "built-ins"
EndSection

Section "Module"
Load  "glx"
EndSection

Section "InputDevice"
Identifier  "Thinkpad Keyboard"
Driver  "libinput"
EndSection

Section "InputClass"
Identifier  "Keyboard Defaults"
MatchIsKeyboard "yes"
# Those are set in /etc/default/keyboard
#   Option  "XkbLayout" "us,ru"
#   Option  "XkbVariant"","
#   Option  "XkbOptions"
"terminate:ctrl_alt_bksp,grp:caps_toggle,compose:ralt"
EndSection

Section "InputDevice"
Identifier  "Thinkpad Mouse"
Driver  "libinput"
EndSection

Section "InputClass"
Identifier  "Touchpad Defaults"
MatchIsTouchpad "yes"
Option  "HorizontalScrolling"   "no"
Option  "Tapping"   "yes"
EndSection

Section "InputClass"
Identifier  "Trackpoint Defaults"
MatchIsPointer  "yes"
Option  "AccelSpeed""-1"
EndSection

Section "Device"
Identifier  "Intel(R) HD Graphics 3000"
Driver  "intel"
VendorName  "Intel Corporation"
BoardName   "N10 Family Integrated Graphics Controller"
BusID   "PCI:0:2:0"
Option  "TearFree"  "yes"
EndSection

Section "Screen"
Identifier "Main"
Device "Intel(R) HD Graphics 3000"
Monitor"LVDS1"
SubSection "Display"
Viewport   0 0
Depth 24
EndSubSection
EndSection

Section "Monitor"
Identifier"LVDS1"
DisplaySize   280 155
EndSection

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

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

Kernel version (/proc/version):
---
Linux version 5.10.0-9-686 (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)

Xorg X server log files on system:
--
-rw-r--r-- 1 root root 29739 Feb  8  2016 /var/log/Xorg.2.log
-rw-r--r-- 1 root root 27438 May 19  2020 /var/log/Xorg.0.log
-rw-r--r-- 1 root root  7301 Aug  7  2020 /var/log/Xorg.1.log
-rw-r--r-- 1 root root  7301 Aug  7  2020 /var/log/Xorg.3.log
-rw-r--r-- 1 sqrt sqrt  6219 Oct 18 23:01 
/home/sqrt/.local/share/xorg/Xorg.1.log
-rw-r--r-- 1 sqrt sqrt  6700 Oct 21 20:21 
/home/sqrt/.local/share/xorg/Xorg.2.log
-rw-r--r-- 1 sqrt sqrt 25075 Oct 21 20:22 
/home/sqrt/.local/share/xorg/Xorg.0.log

Contents of most recent Xorg X server log file 
(/home/sqrt/.local/share/xorg/Xorg.0.log):
-
[279828.657] 
X.Org X Server 1.20.11
X Protocol Version 11, Revision 0
[279828.662] Build Operating System: linux Debian
[279828.663] Current Operating System: Linux laptop 5.10.0-9-686 #1 SMP Debian 
5.10.70-1 (2021-09-30) i686
[279828.663] Kernel command line: BOOT_IMAGE=/vmlinuz quiet initrd=/initrd.img 
resume=/dev/sda2 root=/dev/sda1
[279828.667] Build Date: 13 April 2021  04:07:31PM
[279828.668] xorg-server 2:1.20.11-1 (https://www.debian.org/support) 
[279828.670] Current version of pixman: 0.40.0
[279828.673]Before reporting problems, check http://wiki.x.org
to make sure that 

Bug#997031: nvidia-cuda-gdb: buster-backports /usr/bin/cuda-gdb 'Segmentation fault' at startup

[Tim Trant]

Package: nvidia-cuda-gdb
Version: 11.2.152~11.2.2-2~bpo10+1
Severity: grave
Justification: renders package unusable



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

Kernel: Linux 4.19.0-18-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_CA.UTF8, LC_CTYPE=en_CA.UTF8 (charmap=UTF-8), 
LANGUAGE=en_CA.UTF8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/bash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages nvidia-cuda-gdb depends on:
ii  libbabeltrace1  1.5.6-2+deb10u1
ii  libc6   2.28-10
ii  libexpat1   2.2.6-2+deb10u1
ii  libgcc1 1:8.3.0-6
ii  libipt2 2.0-2
ii  liblzma55.2.4-1
ii  libncursesw66.1+20181013-2+deb10u2
ii  libpython3.73.7.3-2+deb10u3
ii  libreadline77.0-5
ii  libstdc++6  8.3.0-6
ii  libtinfo6   6.1+20181013-2+deb10u2
ii  zlib1g  1:1.2.11.dfsg-1

Versions of packages nvidia-cuda-gdb recommends:
ii  nvidia-cuda-toolkit-doc  11.2.2-2~bpo10+1

nvidia-cuda-gdb suggests no packages.

-- no debconf information

(Upgrade from Buster unfortunately isn't possible until next summer, after the
end of the academic Spring Term.)

"gdb /usr/bin/cuda-gdb" and "strings /usr/bin/cuda-gdb" suggest that there's a 
hidden
use of libpython2.7.so.1 which is failing.

Bug#675748: Working on it.

[Kyle Lyon]

I am working on it at home. Wondering how I can submit it once I have a
fix, though.

Bug#996969: drop 'close' command --- deprecated since at least February 2002

[Julien Cristau]

On Thu, Oct 21, 2021 at 12:17:25PM -0400, Ryan Kavanagh wrote:
> The 'close' command has been deprecated since at least February 2002 [0],
> and its use is strongly discouraged by §5.8.2 of the developers
> reference:
> 
> You should never close bugs via the bug server close command sent to
> cont...@bugs.debian.org. If you do so, the original submitter will
> not receive any information about why the bug was closed. [1]
> 
> After almost 20 years of deprecation, maybe it's time to finally drop
> it?
> 
Maybe it should be called "strongly discouraged" everywhere instead of
deprecated, but there are uses for this command, I don't think we should
drop it.

Cheers,
Julien

Bug#997030: openssh: FTBFS on hurd-i386

[Svante Signell]

Source: openssh
Version: 8.4p1-6
Severity: important
Tags: patch
User: debian-h...@lists.debian.org
Usertags: hurd

Hi,

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.

These patches have been used to successfully build openssh on GNU/Hurd
and GNU/Linux.

Thanks!



Index: openssh-8.4p1/defines.h
===
--- openssh-8.4p1.orig/defines.h
+++ openssh-8.4p1/defines.h
@@ -134,6 +134,12 @@ enum
 # endif
 #endif /* HOST_NAME_MAX */
 
+#ifndef MAXHOSTNAMELEN
+# if defined(_POSIX_HOST_NAME_MAX)
+#  define MAXHOSTNAMELEN _POSIX_HOST_NAME_MAX
+#endif
+#endif /* MAXHOSTNAMELEN */
+
 #if defined(HAVE_DECL_MAXSYMLINKS) && HAVE_DECL_MAXSYMLINKS == 0
 # define MAXSYMLINKS 5
 #endif
--- a/gss-serv.c	2021-10-22 13:44:48.0 +0200
+++ b/gss-serv.c	2021-10-22 13:49:07.0 +0200
@@ -48,6 +48,7 @@
 
 #include "ssh-gss.h"
 #include "monitor_wrap.h"
+#include "defines.h"
 
 extern ServerOptions options;
 

Bug#997000: [Debian-med-packaging] Bug#997000: snakemake: please make the build reproducible

[Nilesh Patra]

On 10/22/21 1:56 PM, Chris Lamb wrote:

Source: snakemake
Version: 6.9.1+dfsg1-3
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: randomness
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

Whilst working on the Reproducible Builds effort [0] we noticed that
snakemake could not be built reproducibly.

This is because it generates and ships a Graphviz .dot file during the
tests and this file has a non-deterministic ordering. Also, the PDF
file generated from this very .dot file contains a created date in its
headers.

Patch attached that fixes the non-determinism in the .dot file
generation and prevents the Debian packaging from shipping the
non-deterministic PDF version.


Thanks, I will upload with this patch in the next couple of days (by sunday 
night)

Nilesh



OpenPGP_signature
Description: OpenPGP digital signature

Bug#997029: pysph: FTBFS in testing and unstable

[Graham Inggs]

Source: pysph
Version: 1.0~b0~20191115.gite3d5e10-5
Severity: serious
Tags: ftbfs

Hi Maintainer

As can be seen in reproducible builds [1], pysph sometimes FTBS in
both testing and unstable.  I've copied what I hope is the relevant
part of the log below.

Regards
Graham


[1] https://tests.reproducible-builds.org/debian/rb-pkg/pysph.html


=== FAILURES ===
_ MPIReduceArrayTestCase.test_parallel_reduce __

self = 

@mark.parallel
def test_parallel_reduce(self):
args = ['--directory=%s' % self.root]
>   run_parallel_script.run(
filename='simple_reduction.py', args=args, nprocs=nprocs, path=path
)

pysph/parallel/tests/test_parallel.py:101:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

filename = 'simple_reduction.py', args = ['--directory=/tmp/tmpr8h_5ft1']
nprocs = 2, timeout = 30.0
path = 
'/build/1st/pysph-1.0~b0~20191115.gite3d5e10/.pybuild/cpython3_3.9/build/pysph/parallel/tests'

def run(filename, args=None, nprocs=2, timeout=30.0, path=None):
"""Run a python script with MPI or in serial (if nprocs=1).
Kill process
if it takes longer than the specified timeout.

Parameters:
---
filename - filename of python script to run under mpi.
args - List of arguments to pass to script.
nprocs - number of processes to run (1 => serial non-mpi run).
timeout - time in seconds to wait for the script to finish running,
else raise a RuntimeError exception.
path - the path under which the script is located
Defaults to the location of this file (__file__), not curdir.

"""
if args is None:
args = []
file_path = abspath(join(path, filename))
cmd = [sys.executable, file_path] + args
if nprocs > 1:
cmd = ['mpiexec', '-n', str(nprocs)] + cmd

print('running test:', cmd)

process = Popen(cmd, stdout=PIPE, stderr=PIPE)
timer = Timer(timeout, kill_process, [process])
timer.start()
out, err = process.communicate()
timer.cancel()
retcode = process.returncode
if retcode:
msg = 'test ' + filename + ' failed with returncode ' + str(retcode)
print(out.decode('utf-8'))
print(err.decode('utf-8'))
print('#'*80)
print(msg)
print('#'*80)
>   raise RuntimeError(msg)
E   RuntimeError: test simple_reduction.py failed with returncode -9

pysph/tools/run_parallel_script.py:54: RuntimeError

Bug#997028: python-gsd: FTBFS with sphinx 4.2.0

[Graham Inggs]

Source: python-gsd
Version: 2.4.2-1
Severity: serious
Tags: ftbfs

Hi Maintainer

As can be seen in reproducible builds, python-gsd FTBFS since sphinx
4.2.0 was uploaded.  I've copied what I hope is the relevant part of
the log below.

Regards
Graham


[1] https://tests.reproducible-builds.org/debian/rb-pkg/python-gsd.html


   dh_installdocs -O--buildsystem=pybuild
dh_installdocs: warning: Cannot auto-detect main package for
python-gsd-doc.  If the default is wrong, please use
--doc-main-package
   debian/rules override_dh_sphinxdoc-indep
make[1]: Entering directory '/build/1st/python-gsd-2.4.2'
dh_sphinxdoc -i
grep "https://cdnjs.cloudflare.com/ajax/libs/mathjax/.*/latest.js;
debian/python-gsd-doc/usr/share/doc/python-gsd-doc/* -r
--files-with-matches | xargs sed
"s|src=\"https://cdnjs.cloudflare.com/ajax/libs/mathjax/.*/latest.js|src=\"file:///usr/share/javascript/mathjax/unpacked/latest.js|g"
-i
sed: no input files
make[1]: *** [debian/rules:23: override_dh_sphinxdoc-indep] Error 123

Bug#997027: python-vispy: FTBFS with sphinx 4.2.0

[Graham Inggs]

Source: python-vispy
Version: 0.6.6-1
Severity: serious
Tags: ftbfs patch

Hi Maintainer

python-vispy FTBFS with sphinx 4.2.0 since add_stylesheet was
deprecated.  It can be fixed by the simple patch below.

Regards
Graham


--- a/doc/conf.py
+++ b/doc/conf.py
@@ -349,9 +349,9 @@

 def setup(app):
 # Add custom CSS
-app.add_stylesheet('css/font-mfizz.css')
-app.add_stylesheet('css/font-awesome.css')
-app.add_stylesheet('style.css')
+app.add_css_file('css/font-mfizz.css')
+app.add_css_file('css/font-awesome.css')
+app.add_css_file('style.css')

 # -
 # Source code links

Bug#997026: libgpuarray: FTBFS with sphinx 4.2.0

[Graham Inggs]

Source: libgpuarray
Version: 0.7.6-6
Severity: serious
Tags: ftbfs patch

Hi Maintainer

libgpuarray FTBFS with sphinx 4.2.0 since add_stylesheet was
deprecated.  It can be fixed by the simple patch below.

Regards
Graham


--- a/doc/conf.py
+++ b/doc/conf.py
@@ -116,7 +116,7 @@
 html_theme = 'sphinx_rtd_theme'

 def setup(app):
-app.add_stylesheet('fix_rtd.css')
+app.add_css_file('fix_rtd.css')

 # Theme options are theme-specific and customize the look and feel of a theme
 # further.  For a list of options available for each theme, see the

Bug#996802: llvm-toolchain-12: FTBFS on s390x since 1:12.0.1-10: Cannot find builtins library for the target architecture

[Sylvestre Ledru]

Le 22/10/2021 à 12:03, Simon McVittie a écrit :

Control: retitle -1 llvm-toolchain-12: FTBFS on s390x since 1:12.0.1-10: Cannot 
find builtins library for the target architecture
Control: found -1 1:12.0.1-13

On Thu, 21 Oct 2021 at 10:19:01 +0100, Simon McVittie wrote:

1:12.0.1-11 has a similar issue on armhf, presumably exposed by fixing
#996828.


This appears to be fixed in 1:12.0.1-13 on armhf, but s390x still has
the same issue.

After llvm-toolchain-12 in unstable gets back to a state where all release
architectures are built successfully, I think it would be better to use
experimental to try different ways of building, and only upload to unstable
when all release architectures work - otherwise it's disruptive to packages
like Mesa (and, indirectly, many GUI programs).

Indeed, I regret uploading in unstable directly :(

I was hoping that it would be smoother...

Sylvestre

Bug#996712: libcache-memcached-fast-perl: autopkgtest failure on armhf: Fetched all keys / Match results

[gregor herrmann]

On Wed, 20 Oct 2021 21:34:50 +0200, gregor herrmann wrote:

> I don't know what exacatly is going on, but I note that it now also
> fails on amd64.

And all other architectures …
 
> I was a bit surprised that the same tests pass during build but the
> explanation is simple: They are skipped as no memcached is running …

If I start memcached before running the tests during builds, we get
the same failures.

And: They also appear upstream in the Github actions:
https://github.com/JRaspass/Cache-Memcached-Fast/actions/runs/1369481886
 

Cheers,
gregor

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


signature.asc
Description: Digital Signature

Bug#993680: transition: proj

[Sebastiaan Couwenberg]

On 10/22/21 5:51 PM, Sebastiaan Couwenberg wrote:
> On 10/22/21 1:49 PM, Sebastiaan Couwenberg wrote:
>> On 10/22/21 11:19 AM, Sebastiaan Couwenberg wrote:
>>> On 10/21/21 11:17 PM, Sebastian Ramacher wrote:
 On 2021-09-04 19:49:39 +0200, Bas Couwenberg wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> X-Debbugs-Cc: pkg-grass-de...@lists.alioth.debian.org
> Control: forwarded -1 
> https://release.debian.org/transitions/html/auto-proj.html
> Control: block -1 by 983222 983224 983229 983230 983253 983254 983299 
> 983345
>
> For the Debian GIS team I'd like to transition to PROJ 8.

 Please go ahead. Please also raise  the remaining FTBFS bugs to serious.
>>>
>>> proj (8.1.1-1) and python-cartopy (0.20.1+dfsg-1) have been uploaded to
>>> unstable. And the severity of the bugreports has been raised to serious.
>>>
>>> Thanks for already scheduling the dependency level 2 NMUs, these are
>>> almost done except for mips64el where they had to wait for proj to be
>>> installed which it is now.
>>
>> libgeotiff & spatialite are built & installed on all release
>> architectures, dependency level 3 can be NMUed now.
> 
> magics++ is built and installed on all release architectures, cdo can be
> NMUed now.

gdal is now also built & installed on all release architectures, the
rest of dependency level 4 can be NMUed now too.

Kind Regards,

Bas

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

Bug#997025: RM: node-request-promise-core -- ROP; Obsolete and now useless

[Yadd]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: pkg-javascript-de...@lists.alioth.debian.net

Hi,

the last reverse dependency of this oldlib has been removed
(node-jsdom). It can now be removed safely.

Cheers,
Yadd

Bug#996104: dkms: Fail to remove modules

[Damir Islamov]

Tags 996104 patch fixed-upstream

 https://github.com/dell/dkms/commit/
64a882a32fdf126ef20e6b6403b5cb158dad21f4[1]


Sincerely yours,
*Damir Islamov*



[1] https://github.com/dell/dkms/commit/
64a882a32fdf126ef20e6b6403b5cb158dad21f4


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

Bug#996270: false positive custom-library-search-path

[Felix Lechner]

Hi,

On Fri, Oct 22, 2021 at 8:20 AM Yves-Alexis Perez  wrote:
>
> That page doesn't apparently mention the term 'plugin', which I think is one
> good reason to set the runpath on a binary, though :)

Maybe you could add it to the Wiki page, if you have time. Thanks!

Kind regards,
Felix Lechner

Bug#993680: transition: proj

[Sebastiaan Couwenberg]

On 10/22/21 1:49 PM, Sebastiaan Couwenberg wrote:
> On 10/22/21 11:19 AM, Sebastiaan Couwenberg wrote:
>> On 10/21/21 11:17 PM, Sebastian Ramacher wrote:
>>> On 2021-09-04 19:49:39 +0200, Bas Couwenberg wrote:
 Package: release.debian.org
 Severity: normal
 User: release.debian@packages.debian.org
 Usertags: transition
 X-Debbugs-Cc: pkg-grass-de...@lists.alioth.debian.org
 Control: forwarded -1 
 https://release.debian.org/transitions/html/auto-proj.html
 Control: block -1 by 983222 983224 983229 983230 983253 983254 983299 
 983345

 For the Debian GIS team I'd like to transition to PROJ 8.
>>>
>>> Please go ahead. Please also raise  the remaining FTBFS bugs to serious.
>>
>> proj (8.1.1-1) and python-cartopy (0.20.1+dfsg-1) have been uploaded to
>> unstable. And the severity of the bugreports has been raised to serious.
>>
>> Thanks for already scheduling the dependency level 2 NMUs, these are
>> almost done except for mips64el where they had to wait for proj to be
>> installed which it is now.
> 
> libgeotiff & spatialite are built & installed on all release
> architectures, dependency level 3 can be NMUed now.

magics++ is built and installed on all release architectures, cdo can be
NMUed now.

> The rebuild of octave-octproj is blocked by sundials not having been
> rebuilt with the new petsc yet.

Kind Regards,

Bas

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

Bug#997024: (no subject)

[Peter Mueller]

… and I've just ping'ed the maintainers of cleveref, babel, and greek.ldf. 
(Just in case the bug is also present upstream.)

Bug#996204: transition: numerical library stack

[Anton Gladky]

Great, thanks! Will do it very shortly.

Anton

Sebastian Ramacher  schrieb am Fr., 22. Okt. 2021,
14:35:

> Hi Anton
>
> On 2021-10-12 13:09:02, Drew Parsons wrote:
> > Package: release.debian.org
> > Severity: normal
> > User: release.debian@packages.debian.org
> > Usertags: transition
> > X-Debbugs-Cc: debian-scie...@lists.debian.org, Anton Gladky <
> gl...@debian.org>
> >
> > I'd like to proceed with a transition of the numerical library stack.
> > This involves
> >
> > superlu   5.2.2+dfsg1 -> 5.3.0+dfsg1  (both libsuperlu5 so not
> really a transition)
> > superlu-dist  libsuperlu-dist6 -> libsuperlu-dist7
> > hypre 2.18.2 -> 2.22.1 (internal within libhypre-dev)
> > mumps libmumps-5.3 -> libmumps-5.4
> > scotch6.1.0 -> 6.1.1 (both libscotch-6.1 so not a transition)
> > petsc libpetsc-.*3.14 -> libpetsc-.*3.15
> > slepc libslepc-.*3.14 -> libslepc-.*3.15
> > (together with petsc4py, slepc4py)
> >
> > Header packages libxtensor-dev, libxtensor-blas-dev will also be
> > upgraded (xtl-dev 0.7.2 already got uploaded to unstable).
> >
> > fenics-dolfinx will upgrade
> >   libdolfinx-.*2019.2 -> libdolfinx-.*0.3
> > (along with other fenics components). There is currently some problem
> > with fenics-dolfinx 1:0.3.0-4 on 32-bit arches i386, armel, armhf.
> > I'll skip the demo_poisson_mpi tests for them if necessary.
> >
> > sundials 5.7.0 is incompatible with hypre 2.22, Anton Gladky (cc:d) will
> > upgrade to sundials 5.8.0.
>
> I think we are ready for the sundials upload.
>
> Cheers
>
> >
> > openmpi/mpi4py/h5py have recently migrated to testing so shouldn't give
> > any particular trouble (apart from the known 32-bit dolfinx problem)
> >
> > auto transitions are already in place:
> >
> > https://release.debian.org/transitions/html/auto-superlu-dist.html
> > https://release.debian.org/transitions/html/auto-mumps.html
> > https://release.debian.org/transitions/html/auto-petsc.html
> > https://release.debian.org/transitions/html/auto-slepc.html
> >
> >
> > Ben file:
> >
> > title = "numerical library stack";
> > is_affected = .depends ~ "libpetsc-.*3.14" | .depends ~
> "libpetsc-.*3.15";
> > is_good = .depends ~ "libpetsc-.*3.15";
> > is_bad = .depends ~ "libpetsc-.*3.14";
> >
>
> --
> Sebastian Ramacher
>

Bug#793549: cmake-data: Can't find fluid with FLTK 1.3.3

[Aaron M. Ucko]

Timo Röhling  writes:

> AFAICT upstream has modified their FLTKConfig.cmake to set
> FLTK_FLUID_EXECUTABLE without UseFLTK.cmake; albeit still to "fluid"
> without absolute path.

Ah, yeah, I see in retrospect that *only* 1.3.3 played poorly with
FindFLTK.cmake.

> Is this sufficient for you to consider this bug done?

Sure, thanks.

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

Bug#996028: [debian-mysql] Bug#996028: #996028 InnoDB: corrupted TRX_NO after upgrading to 10.3.31

[Yves-Alexis Perez]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Fri, 2021-10-22 at 15:22 +0200, Ondrej Zary wrote:
> With 10.3.29 running, I've dumped all databases (mysqldump --all-databases -
> p >mysql.dump), then dropped all databases, stopped mariadb and deleted
> /var/lib/mysql/ib*.
> Then restarted mariadb, restored databases (source mysql.dump) and finally
> upgraded to 10.3.31.

Thanks, I did the same, and it seemed to work.


Regards,
- -- 
Yves-Alexis
-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAmFy2ToACgkQ3rYcyPpX
RFsnKggA7XFwEwfLwE/paI4ThRlsP6GbXSUT193ivkC//qVQCMdHc6HJPFkuMFEa
7DhLkyE+QfNhzPQad2XRhEoQklpp98392q1QztWt+z5lgopuw8PgHQXeyXLB4in0
dfUcbCCylIWf/HV0qzt5lMOn8aIgZ0pQrEDjC4hYolkl2lyhq8N8zyu5DnXAlSXL
L90/VZUmuM48YOMZ40W5OTs/LYNB7O+dmMAhM6J4gM3xyQ+//Nn33f89v86BFemD
DtqGtsCr+7ZIOHeZmf/OAHLudZ8z0wvVGeO80OCxc95K8Vo503L+CmZI4h/QGA6J
KRm6Pv1tpwHIe4tuE+327DHAo1Z3YQ==
=+ZaT
-END PGP SIGNATURE-

Bug#996270: false positive custom-library-search-path

[Yves-Alexis Perez]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Fri, 2021-10-22 at 05:36 -0700, Felix Lechner wrote:
> > I think it'd be nice to have a way to
> > express that there's a generic/accepted RPATH for a package
> 
> I am not sure Debian's position is particularly accommodating [1] but
> I am happy to entertain any proposal.

That page doesn't apparently mention the term 'plugin', which I think is one
good reason to set the runpath on a binary, though :)

Regards,
- -- 
Yves-Alexis
-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAmFy1sYACgkQ3rYcyPpX
RFtkOQgAtnvLk+iZ0YXfN4LzV4LIL7vzSK3I9sS8nagYwBgmceUJS4ce8SPV3cQP
6fVl+UqTUlgdyY3woZK8SvULtKyUg0+1OnlZMZx4G+raE/ts8U/hm+W5xesN2GiM
4MN14YsrxmcGNPJiMt3GeV9wWkrtnxagiyOLIBRfbt02F9wlaBya/HrM01TJUMqc
6GPp6/LQ0j2FFTSmfBCHrYz8XOh8mhRPt7SPb6M3nJgk6b/HMaquxfIpAgInfhyu
2cIE4dVjSRSwB1CvEw88OTjYawYQrr4CEyh6RfTAAdQBATsimbn9Un5Jhi0+369o
aEE47M9UnByQGV7tjpyHn02wOb6oqQ==
=7jyt
-END PGP SIGNATURE-

Bug#984036: disulfinder: ftbfs with GCC-11

[Nilesh Patra]

On Wed, 03 Mar 2021 16:11:37 + Matthias Klose  wrote:

BRNN/RNNs/Options.h:69:5: error: ISO C++17 does not allow dynamic exception 
specifications
  69 | throw(BadOptionSetting);
 | ^
BRNN/RNNs/Options.h:143:5: error: ISO C++17 does not allow dynamic exception 
specifications
143 | throw(BadOptionSetting);
 | ^
BRNN/RNNs/Options.h:180:5: error: ISO C++17 does not allow dynamic exception 
specifications
 180 | throw(BadOptionSetting);
 | ^


Hi all,

looks like C++17 has removed the provision to specify custom exceptions, and 
there are a lot of errors
like the one above.
In this case, does it makes sense to force C++14 standard (with chnages in 
d/rules or with patches) in such cases and ask upstream to
clean these up? Or do I miss a relatively easy solutions?

Let me know

Nilesh

Bug#641768: New upstream repo (fork)

[Sven Mäder]

Dear Maintainer

The https://github.com/Antergos/web-greeter repo was archived due to:
https://fossbytes.com/antergos-linux-dead-alternatives/

A fork exists on https://github.com/JezerM/web-greeter where v3.x.x was
released recently.

Kind regards
Sven

-- 
Sven Mäder 
Support: https://m.ethz.ch/#/#helpdesk:phys.ethz.ch
Chat: https://m.ethz.ch/#/@rda:phys.ethz.ch
Voice: not available
IT Services Group, HPT H 6
Physics Department, ETH Zurich
CH-8093 Zurich, Switzerland

Bug#986027: firefox: WebExtensions process sometimes consumes 100% CPU indefinitely on Firefox 87

[Paul Wise]

On Sun, 28 Mar 2021 15:41:29 +0900 Yuya Nishihara wrote:

> After upgrading to Firefox 87, I've sometimes seen one of the firefox
> contentproc consumes 100% CPU usage indefinitely after start. Killing that
> process appears to terminate all of the extensions, and firefox goes back
> to normal by reenabling them in "Add-ons Manager" page.

FYI I found a faster way to disable/enable addons:

First in about:config set devtools.chrome.enabled to true.

Then when you want to apply the workaround pres Ctrl+Shift+j, run this:

Components.utils.import("resource://gre/modules/AddonManager.jsm");
AddonManager.getAllAddons().then(addons => addons.forEach(addon => 
{addon.disable() ; addon.enable()}))

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#993948: kernel/amd64: system hang on HPE ProLiant BL460c Gen9

[YunQiang Su]

Claudio Kuenzler  于2021年10月22日周五 下午2:03写道：
>
> The fact that a later Kernel versions work fine _could_ be because of a hpwdt 
> commit after 5.10: 
> https://github.com/torvalds/linux/commit/acc195bd2cc48445ea35d00036d8c0afcc4fcc9c#diff-994ee4b010b5c6222ad7a20e160f733401f46894b36fa3e1fb6ffbb48bedb817
> I have not tested sid or a newer Kernel on our HP machines though.
> If you've compiled your own Kernel and this one works (did your do a multiple 
> reboot test?), maybe there's a difference in the Kernel "config"?
>
> What happens if you disable the hpwdt module as mentioned in the other bug 
> reports? Does Bullseye with 5.10 and experimental with 5.14 work in this case?

I test upstream linux and debian-linux with the same config.
All of the upstream config works fine, while debian-linux has this problem.
I guess it is due to one patch by Debian.

-- 
YunQiang Su

Bug#997024: [greek]babel + cleveref + pagenumbering + label = ☇

[Peter Mueller]

Package: texlive-latex-extra
Version: 2021.20210921-1
Reproduce:
1) Put
\documentclass{article} \usepackage[greek]{babel}%%% greek should not 
necessarily be the main language; e.g., [greek, ngerman] would also expose the 
bug \usepackage{cleveref} \begin{document} \pagenumbering{Roman} 
\label{someLabel} \end{document}
into mwe.tex
2) Run pdflatex mwe
3) Observe the error message
! Incomplete \iffalse; all text was ignored after line 6.  \fi 
<*> mwe? X
Since cleveref has not been updated since 2018, I wildly guess that it is 
cleveref that has to be updated to match the current development of latex and 
babel.  At the same time, I'm unsure who is the real culprit (perhaps, none, 
but the interface is broken) and leave the investigation concerning bugs in 
packaging or upstream development to the Debian maintainers.
Thanks in advance
Peter

Bug#992715: freecad: Cannot find icon: Surface_Extend

[Tobias Frost]

Control: tags -1 fixed-upstream

upstream has merged the PR.

Bug#997022: kwin-x11: Black screen after attempting to enable compositing

[Ben Morris]

Package: kwin-x11
Version: 4:5.23.0-2
Severity: important

When starting compositing in kwin (either by starting kwin with compositing
enabled, or by pressing Ctrl-Alt-F12 while kwin is running), the whole screen
goes black apart from the mouse cursor.

When this happens, kwin prints `kwin_core: Failed to initialize compositing,
compositing disable`. Further attempts to enable compositing via the keyboard
shortcut produce two lines: `kwin_core: Failed to initialize compositing,
compositing disable` and `kwin_core: XCB error: 10 (BadAccess), sequence: 2497,
resource id: 1730, major code: 142 (Composite), minor code: 2
(RedirectSubwindows)`.


Attempting to disable or enable compositing has no visible effect. The screen
simply remains black until kwin is killed.


-- 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-3-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_CRAP, 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_US
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages kwin-x11 depends on:
ii  kwin-common   4:5.23.0-2
ii  libc6 2.32-4
ii  libepoxy0 1.5.9-2
ii  libgcc-s1 11.2.0-10
ii  libkf5configcore5 5.86.0-1
ii  libkf5coreaddons5 5.86.0-1
ii  libkf5crash5  5.86.0-1
ii  libkf5i18n5   5.86.0-1
ii  libkf5quickaddons55.86.0-1
ii  libkf5windowsystem5   5.86.0-1
ii  libkwaylandserver5 [libkwaylandserver5-5.23]  5.23.0-1
ii  libkwineffects13  4:5.23.0-2
ii  libkwinglutils13  4:5.23.0-2
ii  libkwinxrenderutils13 4:5.23.0-2
ii  libqt5core5a  5.15.2+dfsg-12
ii  libqt5dbus5   5.15.2+dfsg-12
ii  libqt5gui55.15.2+dfsg-12
ii  libqt5widgets55.15.2+dfsg-12
ii  libqt5x11extras5  5.15.2-2
ii  libstdc++611.2.0-10
ii  libx11-6  2:1.7.2-2+b1
ii  libxcb-composite0 1.14-3
ii  libxcb-keysyms1   0.4.0-1+b2
ii  libxcb-randr0 1.14-3
ii  libxcb-render01.14-3
ii  libxcb-shape0 1.14-3
ii  libxcb-xfixes01.14-3
ii  libxcb1   1.14-3
ii  libxi62:1.8-1

kwin-x11 recommends no packages.

kwin-x11 suggests no packages.

-- no debconf information

Bug#996977: kbd-chooser: can't chose keyboard variant keymap

[Holger Wansing]

Hi,

Am 22. Oktober 2021 10:24:43 MESZ schrieb Xavier Brochard 
:
>Le 21.10.2021 23:15, Samuel Thibault a écrit :
>> Yes, we do not want to clutter the menu with various variant choices for
>> each and every language.
>
>May be I don't remember, but I think it was possible to chose a variant on the 
>ncurse UI in "advanced" mode (at the lower priority options).

As I wrote in another mail:
this was possible until Debian 6 (2012).

Holger

-- 
Sent from /e/ OS on Fairphone3

Bug#997021: RFS: igtf-policy-bundle/1.113-1~bpo11+1 -- IGTF experimental Certificate Authorities

[Dennis van Dok]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "igtf-policy-bundle".

The package is already in stable and buster-backerports. It is NEW
for bullseye backports and I would like to maintain updating it there.

The package has regular (~monthly) updates of the trust anchors which is why it 
makes
sense to also keep backporting it.


 * Package name: igtf-policy-bundle
   Version : 1.113-1~bpo11+1
   Upstream Author : IGTF 
 * URL : http://www.igtf.net/
 * License : CC-BY-3.0, MPL-1.1
 * Vcs : https://github.com/dvandok/igtf-policy-bundle
   Section : misc

It builds those binary packages:

  igtf-policy-classic - IGTF classic profile for Certificate Authorities
  igtf-policy-mics - IGTF MICS profile for Certificate Authorities
  igtf-policy-slcs - IGTF SLCS profile for Certificate Authorities
  igtf-policy-iota - IGTF IOTA profile for Certificate Authorities
  igtf-policy-unaccredited - IGTF unaccredited Certificate Authorities
  igtf-policy-experimental - IGTF experimental Certificate Authorities

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

  https://mentors.debian.net/package/igtf-policy-bundle/

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

  dget -x 
https://mentors.debian.net/debian/pool/main/i/igtf-policy-bundle/igtf-policy-bundle_1.113-1~bpo11+1.dsc

Changes since the last upload:

 igtf-policy-bundle (1.113-1~bpo11+1) bullseye-backports; urgency=medium
 .
   * Rebuild for bullseye-backports.
 .
 igtf-policy-bundle (1.113-1) unstable; urgency=medium
 .
   * New upstream release:
   * [Changes from 1.112 to 1.113 (4 October 2021)]
   * Suspended MD-GRID CA due to network resolution issues (MD)
   * [Changes from 1.111 to 1.112 (16 August 2021)]
   * Updated ANSPGrid CA with extended validity date (BR)
   * [Changes from 1.110 to 1.111 (24 May 2021)]
   * Removed discontinued NERSC-SLCS CA (US)
   * Removed discontinued MYIFAM CA (MY)
   * [Changes from 1.109 to 1.110 (22 March 2021)]
   * Removed INFN-CA-2015 that has disappeared operationally (IT)

Regards,
-- 
  Dennis van Dok

Bug#997020: RFP: fnott -- keyboard driven and lightweight Wayland notification daemon

[Piotr Ożarowski]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: team+swa...@tracker.debian.org

* Package name: fnott
  Version : 1.1.2
  Upstream Author : Daniel Eklöf 
* URL : https://codeberg.org/dnkl/fnott
* License : MIT
  Programming Lang: C
  Description : keyboard driven and lightweight Wayland notification daemon

Fnott is a keyboard driven and lightweight notification daemon for
wlroots-based Wayland compositors. It implements (parts of) the Desktop
Notification Specification.

Supported features
• Summary
• Body
• Actions (requires a dmenu-like utility to display and let user select action)
• Urgency
• Icons
  - PNGs (using libpng)
  - SVGs (using bundled nanosvg)
• Markup
• Timeout


We already have mako-notifier in Debian but fnott better suits my needs.
F.e. it adjusts notification popup size as needed (instead of hardcoding
width/height of the popup)

Sway and related packages team added to X-Debbugs-Cc.

I can create an initial package and/or sponsor potential maintainer.


signature.asc
Description: PGP signature

Bug#793549: cmake-data: Can't find fluid with FLTK 1.3.3

[Timo Röhling]

Hi Aaron,

On Fri, 24 Jul 2015 19:46:57 -0400 "Aaron M. Ucko"  wrote:

Prior to 1.3.3, this worked fine, because /usr/lib/fltk/FLTKConfig.cmake
defined FLTK_FLUID_EXECUTABLE, and to an absolute path at that.
However, 1.3.3 yields a very different setup: the definition appears
only in UseFLTK.cmake, which FLTKConfig.cmake doesn't include, just
points FLTK_USE_FILE to.  Moreover, the definition is simply "fluid",
with no path specified.

AFAICT upstream has modified their FLTKConfig.cmake to set
FLTK_FLUID_EXECUTABLE without UseFLTK.cmake; albeit still to "fluid"
without absolute path.

Is this sufficient for you to consider this bug done?

Cheers
Timo


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


signature.asc
Description: PGP signature

Bug#997019: mailman3: Mailman itself seems to be refusing LMTP connections from Exim4

[Colin Turner]

Package: mailman3
Version: 3.3.3-1
Severity: normal

Dear Maintainer,

Thank you for all your work on the mailman3 package. I have just started to try 
to install this and migrating a mailman2 residual configuration.

I have been unable to get mailman to receive mail from Exim4. While exim4 is 
selecting the correct router and transport I am getting:

2021-10-21 22:29:38 1mdfd3-005vLS-T4 == rolep...@lists.piglets.com 
R=mailman3_router T=mailman3_transport defer (111): Connection refused

on all emails I am trying to send as tests to the lists.

- Exim Config -

My exim4 transport is as follows:

# /etc/exim4/conf.d/transport/55_mm3_transport
mailman3_transport:
  driver = smtp
  protocol = lmtp
  allow_localhost
  hosts = localhost
  port = MM3_LMTP_PORT
  rcpt_include_affixes = true

and the MM3_LMTP_PORT is defined here:

# /etc/exim4/conf.d/main/25_mm3_macros
# The colon-separated list of domains served by Mailman.
domainlist mm_domains=lists.piglets.com

MM3_LMTP_PORT=8024

# MM3_HOME must be set to mailman's var directory, wherever it is
# according to your installation.
MM3_HOME=/var/lib/mailman3
MM3_UID=list
MM3_GID=list


# The configuration below is boilerplate:
# you should not need to change it.

# The path to the list receipt (used as the required file when
# matching list addresses)
MM3_LISTCHK=MM3_HOME/lists/${local_part}.${domain}

- mta in mailman.cfg -

The [mta] stanza of my mailman.cfg files is as below

[mta]
# The class defining the interface to the incoming mail transport agent.
incoming: mailman.mta.exim4.LMTP
#incoming: mailman.mta.postfix.LMTP

# The callable implementing delivery to the outgoing mail transport agent.
# This must accept three arguments, the mailing list, the message, and the
# message metadata dictionary.
outgoing: mailman.mta.deliver.deliver

# How to connect to the outgoing MTA.  If smtp_user and smtp_pass is given,
# then Mailman will attempt to log into the MTA when making a new connection.
smtp_host: 127.0.0.1
smtp_port: 25
smtp_user:
smtp_pass:

# Where the LMTP server listens for connections.  Use 127.0.0.1 instead of
# localhost for Postfix integration, because Postfix only consults DNS
# (e.g. not /etc/hosts).
lmtp_host: localhost
lmtp_port: 8024

# Where can we find the mail server specific configuration file?  The path can
# be either a file system path or a Python import path.  If the value starts
# with python: then it is a Python import path, otherwise it is a file system
# path.  File system paths must be absolute since no guarantees are made about
# the current working directory.  Python paths should not include the trailing
# .cfg, which the file must end with.
configuration: python:mailman.config.exim4
#configuration: python:mailman.config.postfix

-

I have tried restarting all the relevant services. Telnet shows the runner to 
be listening

root@gondolin:~# telnet localhost 8024
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
220 gondolin.piglets.org GNU Mailman LMTP runner 2.0

But for some reason all email inbound is being rejected as connection refused. 
I have probably made an elementary error, but I'm not sure where if so, so 
apologies in advance.

Kind regards,

CT.

PS. I also ran into the issue #996560 of broken web links and fixed it with the 
same workaround

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

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

Versions of packages mailman3 depends on:
ii  dbconfig-sqlite3 2.0.20
ii  debconf [debconf-2.0]1.5.77
ii  init-system-helpers  1.60
ii  logrotate3.18.1-2
ii  lsb-base 11.1.0
ii  python3  3.9.2-3
ii  python3-aiosmtpd 1.4.2-1
ii  python3-alembic  1.7.1-3
ii  python3-authheaders  0.13.0-1
ii  python3-authres  1.2.0-2
ii  python3-click7.1.2-1
ii  python3-dateutil 2.8.1-6
ii  python3-dnspython2.0.0-1
ii  python3-falcon   3.0.1-2
ii  python3-flufl.bounce 3.0.1-1
ii  python3-flufl.i18n   3.0.1-1
ii  python3-flufl.lock   5.0.1-1
ii  python3-gunicorn 20.1.0-1
ii  python3-importlib-resources  5.1.2-1
ii  python3-lazr.config  2.2.3-1
ii  python3-passlib  1.7.4-1
ii  python3-psycopg2 2.8.6-2
ii  python3-public   0.5-1.1
ii  python3-pymysql  1.0.2-2
ii  python3-requests 2.25.1+dfsg-2
ii  python3-sqlalchemy   1.3.22+ds1-1
ii  python3-zope.component   4.3.0-3
ii  python3-zope.configuration   

Bug#923345: evince cannot start default browser due to AppArmor

[Michael Deegan]

Package: evince
Version: 3.38.2-1
Followup-For: Bug #923345

This bug still exists in bullseye, despite the partial fix in #954013.

   Oct 22 15:15:03 joyola kernel: [193012.379454] audit: type=1400 
audit(1634886903.112:32): apparmor="DENIED" operation="exec" 
profile="/usr/bin/evince" name="/usr/bin/xfce4-mime-helper" pid=1348354 
comm="exo-open" requested_mask="x" denied_mask="x" fsuid=1000 ouid=0

(Why yes, I *am* running XFCE here!)

-- System Information:
Debian Release: 11.1
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-debug'), (500, 
'oldstable-updates'), (500, 'oldstable-proposed-updates-debug'), (500, 
'oldstable-debug'), (500, 'oldoldstable'), (500, 'stable'), (500, 'oldstable'), 
(470, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages evince depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.38.0-2
ii  evince-common3.38.2-1
ii  gsettings-desktop-schemas3.38.0-2
ii  libatk1.0-0  2.36.0-2
ii  libc62.31-13+deb11u2
ii  libcairo-gobject21.16.0-5
ii  libcairo21.16.0-5
ii  libevdocument3-4 3.38.2-1
ii  libevview3-3 3.38.2-1
ii  libgdk-pixbuf-2.0-0  2.42.2+dfsg-1
ii  libglib2.0-0 2.66.8-1
ii  libgnome-desktop-3-193.38.5-3
ii  libgtk-3-0   3.24.24-4
ii  libnautilus-extension1a  3.38.2-1+deb11u1
ii  libpango-1.0-0   1.46.2-3
ii  libpangocairo-1.0-0  1.46.2-3
ii  libsecret-1-00.20.4-2
ii  shared-mime-info 2.0-1

Versions of packages evince recommends:
ii  dbus-x11 [dbus-session-bus]  1.12.20-2

Versions of packages evince suggests:
ii  gvfs 1.46.2-1
pn  nautilus-sendto  
ii  poppler-data 0.4.10-1
ii  unrar1:6.0.3-1

-- no debconf information

-MD

-- 
-
Michael Deegan   Hugaholic  https://www.deegan.id.au/
  Jung, zr jbeel?  --

Bug#997003: php: CVE-2021-21703

[Christian Göttsche]

Source: php7.4
Version: 7.4.21-1+deb11u1
Severity: serious
Tags: security fixed-upstream

A privilege escalation vulnerability has been discovered in php
(CVE-2021-21703).
This has been fixed in upstream version 7.4.25.

Bug#996028: [debian-mysql] Bug#996028: #996028 InnoDB: corrupted TRX_NO after upgrading to 10.3.31

[Ondrej Zary]

On Friday 22 October 2021, Yves-Alexis Perez wrote:
> On Thu, 2021-10-14 at 19:38 +0200, Ondrej Zary wrote:
> >     MDEV-15912: Remove traces of insert_undo
> >
> >     Let us simply refuse an upgrade from earlier versions if the
> >     upgrade procedure was not followed. This simplifies the purge,
> >     commit, and rollback of transactions.
> >
> >     Before upgrading to MariaDB 10.3 or later, a clean shutdown
> >     of the server (with innodb_fast_shutdown=1 or 0) is necessary,
> >     to ensure that any incomplete transactions are rolled back.
> >     The undo log format was changed in MDEV-12288. There is only
> >     one persistent undo log for each transaction.
> 
> 
> Hi Ondrej,
> it might be worth trying with that patch reverted, but I'm a bit confused at
> the commit message. That seems to imply my server didn't have a clean shutdown
> before upgrading to 10.3, which is possible but that upgrade is quite old by
> now (afaict it's between Stretch and Buster), so I'm unsure what to do now.
> 
> innodb_fast_shutdown=0 doesn't terminate on 10.3.25, and I'm not sure if there
> are other ways to ensure a “clean shutdown”.
> 
> Regards,

With 10.3.29 running, I've dumped all databases (mysqldump --all-databases -p 
>mysql.dump), then dropped all databases, stopped mariadb and deleted 
/var/lib/mysql/ib*.
Then restarted mariadb, restored databases (source mysql.dump) and finally 
upgraded to 10.3.31.

So my problem is solved. I've also found the patch that's causing the problem. 
I'm not going to waste any more time on this.

During many years of running mysql, upgrade just worked all the time. Looks 
like there are some quality problems with the developement process now.

-- 
Ondrej Zary

Bug#996995: dh-python: Unable to parse debian/control

[Christian Marillat]

On 22 oct. 2021 09:24, "Chris Lamb"  wrote:

> tags 996995 + patch
> severity 996995 serious
> thanks
>
> Patch attached.

This patch fix this issue.

Christian

Bug#997018: RM: rust-elfx86exts [armhf i386 mips64el mipsel ppc64el s390x] -- ROM; Only {amd,arm}64 for now

[Michael R. Crusoe]

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

Thanks!

Bug#996204: transition: numerical library stack

[Sebastian Ramacher]

Hi Anton

On 2021-10-12 13:09:02, Drew Parsons wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> X-Debbugs-Cc: debian-scie...@lists.debian.org, Anton Gladky 
> 
> I'd like to proceed with a transition of the numerical library stack.
> This involves
> 
> superlu   5.2.2+dfsg1 -> 5.3.0+dfsg1  (both libsuperlu5 so not really a 
> transition)
> superlu-dist  libsuperlu-dist6 -> libsuperlu-dist7
> hypre 2.18.2 -> 2.22.1 (internal within libhypre-dev)
> mumps libmumps-5.3 -> libmumps-5.4
> scotch6.1.0 -> 6.1.1 (both libscotch-6.1 so not a transition)
> petsc libpetsc-.*3.14 -> libpetsc-.*3.15
> slepc libslepc-.*3.14 -> libslepc-.*3.15
> (together with petsc4py, slepc4py)
> 
> Header packages libxtensor-dev, libxtensor-blas-dev will also be
> upgraded (xtl-dev 0.7.2 already got uploaded to unstable).
> 
> fenics-dolfinx will upgrade
>   libdolfinx-.*2019.2 -> libdolfinx-.*0.3
> (along with other fenics components). There is currently some problem
> with fenics-dolfinx 1:0.3.0-4 on 32-bit arches i386, armel, armhf.
> I'll skip the demo_poisson_mpi tests for them if necessary.
> 
> sundials 5.7.0 is incompatible with hypre 2.22, Anton Gladky (cc:d) will
> upgrade to sundials 5.8.0.

I think we are ready for the sundials upload.

Cheers

> 
> openmpi/mpi4py/h5py have recently migrated to testing so shouldn't give
> any particular trouble (apart from the known 32-bit dolfinx problem)
> 
> auto transitions are already in place:
> 
> https://release.debian.org/transitions/html/auto-superlu-dist.html
> https://release.debian.org/transitions/html/auto-mumps.html
> https://release.debian.org/transitions/html/auto-petsc.html
> https://release.debian.org/transitions/html/auto-slepc.html
> 
> 
> Ben file:
> 
> title = "numerical library stack";
> is_affected = .depends ~ "libpetsc-.*3.14" | .depends ~ "libpetsc-.*3.15";
> is_good = .depends ~ "libpetsc-.*3.15";
> is_bad = .depends ~ "libpetsc-.*3.14";
> 

-- 
Sebastian Ramacher

Bug#996730: Certain menus don't work right when chrome is in the Normal Layer

[積丹尼 Dan Jacobson]

> "EB" == Eduard Bloch  writes:
EB> I have no idea what you mean and this is definitively not "grave". Tried

I was thinking because it caused other packages to not work properly...

EB> to reproduce with different settings and chromium 93.0.4577.82-1 and it
EB> just works.

EB> Maybe some issue with other software on your system which is
EB> manipulating properties?

Well I turned off picom and it didn't help.

EB> Maybe gijsbers finds something.

I don't know. I think he is saying this bug is not possible:
https://github.com/ice-wm/icewm/issues/62#issuecomment-933694736

Does it work if you downgrade icewm (and
EB> icewm-common) to the Testing version?

They are the same:
# apt-cache policy icewm icewm-common
icewm:
  Installed: 2.8.0-1
  Candidate: 2.8.0-1
  Version table:
 *** 2.8.0-1 990
990 http://opensource.nchc.org.tw/debian unstable/main amd64 Packages
500 http://opensource.nchc.org.tw/debian testing/main amd64 Packages
100 /var/lib/dpkg/status
icewm-common:
  Installed: 2.8.0-1
  Candidate: 2.8.0-1
  Version table:
 *** 2.8.0-1 990
990 http://opensource.nchc.org.tw/debian unstable/main amd64 Packages
500 http://opensource.nchc.org.tw/debian testing/main amd64 Packages
100 /var/lib/dpkg/status

Should I go further back?

Bug#994443: [R-pkg-team] Bug#994443: marked as done (r-bioc-deseq2: autopkgtest regression)

[Michael R. Crusoe]

On Thu, 21 Oct 2021 15:15:52 +0200 Graham Inggs  wrote:
> Control: reopen -1
>
> r-bioc-deseq2's autopkgtests started to again pass in testing on
> 2021-09-29, once r-bioc-tximportdata migrated.
> However, the autopkgtests in stable continue to fail [1].

Correct, because the package r-bioc-tximportdata does not exist in stable.

--
Michael R. Crusoe

Bug#997017: RM: rust-capstone [armel armhf i386 mips64el mipsel ppc64el s390x] -- ROM; Only {amd,arm}64 for now

[Michael R. Crusoe]

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

When we update to newer versions later I'll restore the other archs.

Bug#997014: Acknowledgement (desktop-profiles: /etc/csh/login.d/desktop-profiles.csh uses tempfile, which is deprecated)

[Alexandre DENIS]

I didn't notice the package had been removed from sid. Thus the bug is
non applicable.

We can close.

Tanks.


pgpWOlzpHYkZS.pgp
Description: OpenPGP digital signature