Bug#996093: lintian: detect variant of Lenna image

[Andrius Merkys]

Package: lintian
Version: 2.108.0

Hello,

I have located a variant Lenna image undetected by lintian in
python-docx upstream source [1] at
features/steps/test_files/lena_std.jpg. As requested by
license-problem-non-free-img-lenna tag, I am attaching md5sum, sha1sum,
and sha256 of this file:

$ md5sum features/steps/test_files/lena_std.jpg
dc0f99bbc6d31e7ce4000cc7c1117dbb  features/steps/test_files/lena_std.jpg
$ sha1sum features/steps/test_files/lena_std.jpg
3712585117d7f181f76a67cbbdca9c558cb39110
features/steps/test_files/lena_std.jpg
$ sha256sum features/steps/test_files/lena_std.jpg
8640b22549789d5aeabebb487b0b6cda05119c3bff8f67699850a0f8177532d7
features/steps/test_files/lena_std.jpg

[1] https://github.com/python-openxml/python-docx

Andrius

Bug#995274: needrestart: false positive: rabbitmq-server

[Thomas Liske]

tags 995274 upstream fixed-upstream
thanks


Hi,

thanks for the verbose output. This is due to anonymous file mapping
/memfd (see also #988461). Has been already fixed upstream in
needrestart 3.6+ [1].

[1]
https://github.com/liske/needrestart/commit/6c87772bdc38091e9efbf4c59217fa502365dcf2#diff-5e347a5df78db1304c1f2f21e27bb9122a186cf9c772a32ccaa23b424aac21a3


Regards,
Thomas

On Sun, 2021-10-10 at 19:25 -0300, Antonio Terceiro wrote:
> [main] eval /etc/needrestart/needrestart.conf

Bug#996088: RFS: r-cran-mpoly

[Andreas Tille]

Hi again,

Am Mon, Oct 11, 2021 at 12:59:56AM + schrieb Torrance, Douglas:
> I've just finished packaging r-cran-mpoly, which implements multivariate
> polynomials in R.  Since it would be headed for the NEW queue and I'm a DM,
> I'm unable to upload it.  Would anyone be able to review/sponsor?

Looking at the repository layout I realise that it has debian/master
instead of master.  That's fine in principle but its a sign that you
did not used

prepare_missing_cran_package

I keep on recommending to use this to save a lot of time.

Kind regards

 Andreas.

-- 
http://fam-tille.de

Bug#996088: RFS: r-cran-mpoly

[Andreas Tille]

Uploaded to new.  Thank you for the preparation, Andreas.

Am Mon, Oct 11, 2021 at 12:59:56AM + schrieb Torrance, Douglas:
> Control: tags -1 pending
> 
> I've just finished packaging r-cran-mpoly, which implements multivariate
> polynomials in R.  Since it would be headed for the NEW queue and I'm a DM,
> I'm unable to upload it.  Would anyone be able to review/sponsor?
> 
> https://salsa.debian.org/r-pkg-team/r-cran-mpoly
> 
> Thanks!
> Doug



-- 
http://fam-tille.de

Bug#996092: superficial autopkgtests not marked as superficial

[John Scott]

Source: gpgme1.0
Version: 1.16.0-1.1
Severity: important

In my opinion, this smells like a Policy violation, but I'm setting the
severity at non-RC since it's not my judgment that matters, but that of
the CI team.

Because DEP-8 tests (autopkgtests) speed up migration and have other
consequences on the release process, any tests that do not exercise a
significant amount of functionality must be marked with
Restrictions: superficial. I was wondering whether GPGME had any
autopkgtests because I was interested in writing one.

The Python test only checks that the gpg module can be imported and a
context obtained, but doesn't do anything with it. Only checking if a
module can be imported is the go-to example of a superficial test.

The checky2106 test likewise doesn't actually exercise any actual
functionality from GPGME, or even include the appropriate header.

If you'd like a significant autopkgtest, I'd be glad to write one, but
I'd like to bring to your attention that these existing tests really
ought to be marked superficial.

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

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



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

Bug#996091: pulsemixer: goes crazy high cpu and freezes completly after a little pulsehickup

[Mr. T]

Package: pulsemixer
Version: 1.5.1-1
Severity: important
X-Debbugs-Cc: tre...@treaki.tk

hi,

today it worked fine, got it running in my pull-down terminal tilda, but
then somehow, maybe cause i used some other apps with it and
disconnected an usb headset (usb input output) pulseaudio got a little
hickup, it was fine for all my other apps running actively right now
(firefox and mpv) but the pulsemixer python process generated 100% cpu
as far as it could and was not reacting to input in its terminal tab, i
tried to sigterm (15) it but i had to sigkill (9) it to get rid of it 
and then

could restart it. there was not particularity much hint about it only
this crumbled up with the other output




L M  Built-in Audio Analog Stereo: All Exception ignored on calling 
ctypes callback function: <__main__.Pulse object at 0x7f6cd8739460>>

Traceback (most recent call last):
  File "/usr/bin/pulsemixer", line 696, in server_cb
self.data = PulseServer(server_info[0])
ValueError: NULL pointer access




regards



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

Kernel: Linux 5.10.0-6-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en

Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages pulsemixer depends on:
ii libpulse0 14.2-2
ii python3 3.9.2-3

pulsemixer recommends no packages.

pulsemixer suggests no packages.

-- no debconf information

Bug#901307: sphinx-gallery: please make the build mostly reproducible

[Sandro Tosi]

> Friendly ping on this?

this was supposed to be fixed when i uploaded that version. Anyhow,
i've just uploaded 0.10.0 to unstable, can you  check that version
out? if it's still FTBR maybe give a ping upstream about it?

Thanks,
-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Bug#996090: mrtg: Spelling error in a variable name

[Joao Eriberto Mota Filho]

Package: mrtg
Version: 2.17.7-3
Severity: important
Tags: upstream patch

Control: forwarded -1 https://github.com/oetiker/mrtg/pull/50

The following patch will fix a mistake in source code:



--- a/src/lib/mrtg2/MRTG_lib.pm
+++ b/src/lib/mrtg2/MRTG_lib.pm
@@ -1823,7 +1823,7 @@ sub populateconfcache ($) {
  push @{$$confcache{___updated}}, $hostkey;
 
 $SNMP_Session::suppress_warnings = $snmp_errlevel;
-$Net_SNMP_util::supress_warnings = $net_snmp_errlevel;
+$Net_SNMP_util::suppress_warnings = $net_snmp_errlevel;
 }
 
 sub log2rrd ($$$) {



Regards,

Eriberto

Bug#981446: RFA: logcheck -- mails anomalies in the system logfiles to the administrator

[Charles]

Hi

On 10/10/2021 22:09, Hannes von Haugwitz wrote:


@Jose Do you still plan to adopt logcheck? You might want to collaborate
with Richard and Charles to maintain the package all together.


Is there an email list to enable collaboration and discussion?


You can use the #logcheck channel on the OFTC IRC network to collaborate
and discuss logcheck with some users and previous maintainers.

Best regards

Hannes


I am happy to collaborate with Jose and Richard as logcheck maintainers 
and to discuss logcheck in the #logcheck channel on the OFTC IRC network

Bug#996089: lintian: False positive for missing-build-dependency-for-dh-addon (either Build-Depends-Indep or B-D's Provides seem ignored)

[Axel Beckert]

Package: lintian
Version: 2.108.0
Severity: normal

While working on the dhcpy6d package, I noticed the following
error-level tag that lintian emitted:

  E: dhcpy6d source: missing-build-dependency-for-dh-addon python3 => 
python3:any | python3-all:any | python3-dev:any | python3-all-dev:any | 
dh-sequence-python3

But the package does have such a build-dependency:

  Build-Depends-Indep: dh-python

And the dh-python package provides one of the listed dependencies deemed
missing:

  Package: dh-python
  Version: 4.20201102+nmu1
  […]
  Provides: dh-sequence-pypy, dh-sequence-python2, dh-sequence-python3

Not sure if the fact that Build-Depends-Indep is used or the fact that
the build-dependency uses Provides is overseen by lintian.

IIRC, when I uploaded 1.0.5-1 on 15th of August 2021 this tag wasn't
emitted and the package also built fine in pbuilder as well as on the
buildds. No related changes in debian/control since then.

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

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

Versions of packages lintian depends on:
ii  binutils2.37-7
ii  bzip2   1.0.8-4
ii  clzip   1.12-3
ii  diffstat1.64-1
ii  dpkg1.20.9
ii  dpkg-dev1.20.9
ii  file1:5.39-3
ii  gettext 0.21-4
ii  gpg 2.2.27-2
ii  intltool-debian 0.35.0+20060710.5
ii  libapt-pkg-perl 0.1.40
ii  libarchive-zip-perl 1.68-1
ii  libcapture-tiny-perl0.48-1
ii  libclass-xsaccessor-perl1.19-3+b7
ii  libclone-perl   0.45-1+b1
ii  libconfig-tiny-perl 2.27-1
ii  libconst-fast-perl  0.014-1.1
ii  libcpanel-json-xs-perl  4.26-1
ii  libdata-dpath-perl  0.58-1
ii  libdata-validate-domain-perl0.10-1.1
ii  libdevel-size-perl  0.83-1+b2
ii  libdigest-sha-perl  6.02-1+b3
ii  libdpkg-perl1.20.9
ii  libemail-address-xs-perl1.04-1+b3
ii  libencode-perl  3.12-1
ii  libfile-basedir-perl0.09-1
ii  libfile-find-rule-perl  0.34-1
ii  libfont-ttf-perl1.06-1.1
ii  libhtml-html5-entities-perl 0.004-1.1
ii  libio-interactive-perl  1.023-1
ii  libio-prompt-tiny-perl  0.003-1
ii  libipc-run3-perl0.048-2
ii  libjson-maybexs-perl1.004003-1
ii  liblist-compare-perl0.55-1
ii  liblist-someutils-perl  0.58-1
ii  liblist-utilsby-perl0.11-1
ii  libmoo-perl 2.005004-2
ii  libmoox-aliases-perl0.001006-1.1
ii  libnamespace-clean-perl 0.27-1
ii  libpath-tiny-perl   0.118-1
ii  libperlio-gzip-perl 0.19-1+b7
ii  libperlio-utf8-strict-perl  0.008-1+b1
ii  libproc-processtable-perl   0.611-1
ii  libsereal-decoder-perl  4.018+ds-1+b1
ii  libsereal-encoder-perl  4.018+ds-1+b1
ii  libsort-versions-perl   1.62-1
ii  libterm-readkey-perl2.38-1+b2
ii  libtext-glob-perl   0.11-1
ii  libtext-levenshteinxs-perl  0.03-4+b8
ii  libtext-markdown-discount-perl  0.13-1
ii  libtext-xslate-perl 3.5.8-1+b1
ii  libtime-duration-perl   1.21-1
ii  libtime-moment-perl 0.44-1+b3
ii  libtimedate-perl2.3300-2
ii  libtry-tiny-perl0.30-1
ii  libtype-tiny-perl   1.012004-1
ii  libunicode-utf8-perl0.62-1+b2
ii  liburi-perl 5.08-1
ii  libxml-libxml-perl  2.0134+dfsg-2+b1
ii  libyaml-libyaml-perl0.83+ds-1
ii  lzip1.22-4
ii  lzop1.04-2
ii  man-db  2.9.4-2
ii  patchutils  0.4.2-1
ii  perl [libencode-perl]   5.32.1-6
ii  t1utils 1.41-4
ii  unzip   6.0-26
ii  xz-utils5.2.5-2

lintian recommends no packages.

Versions of packages lintian suggests:
ii  binutils-multiarch 2.37-7
ii  libtext-template-perl  1.60-1

-- no debconf information

Bug#996088: RFS: r-cran-mpoly

[Torrance, Douglas]

Control: tags -1 pending

I've just finished packaging r-cran-mpoly, which implements multivariate
polynomials in R.  Since it would be headed for the NEW queue and I'm a DM,
I'm unable to upload it.  Would anyone be able to review/sponsor?

https://salsa.debian.org/r-pkg-team/r-cran-mpoly

Thanks!
Doug


signature.asc
Description: PGP signature

Bug#996088: ITP: r-cran-mpoly -- symbolic computing with multivariate polynomials in R

[Torrance, Douglas]

Package: wnpp
Severity: wishlist
Owner: Doug Torrance 
X-Debbugs-Cc: debian-de...@lists.debian.org, dtorra...@piedmont.edu,

* Package name: r-cran-mpoly
 Version : 1.1.1
 Upstream Author : David Kahle 
* URL : https://github.com/dkahle/mpoly
* License : GPL
 Programming Lang: R
 Description : symbolic computing with multivariate polynomials in R

mpoly is a simple collection of tools to help deal with multivariate
polynomials symbolically and functionally in R.  Features include term
ordering, creating vectors of polynomials, extracting pieces of polynomials,
arithmetic, derivatives, evaluation, homogenization and dehomogenization, and
many special polynomials.

I intend to maintain this package under the umbrella of the Debian R team.


signature.asc
Description: PGP signature

Bug#994275: Reverting breaking changes in debianutils

[Simon McVittie]

On Wed, 15 Sep 2021 at 01:36:26 +0300, Adrian Bunk wrote:
> The release team has so far protected users of testing from the
> problem by blocking testing migration, but this is not a long-term
> solution.

Adrian asked in #994275 for changes in several topics to be reverted:

- which(1) deprecation
  - deprecation warnings on stderr
  - management via alternatives
  - possible future removal
- tempfile(1) removal
- installkernel(8) moving from /sbin to /usr/sbin
- run-parts(8) moving from /bin to /usr/bin

Which of those topics were your reason for adding a "block debianutils"
hint? Are there any of those topics whose resolution you would consider
to be a prerequisite for letting debianutils migrate to testing again?

The hint references #992399, which is related to tempfile(1), but
#992399 has been closed (via a merge with #992396, which was resolved by
debianutils adding a versioned Breaks on x11-common versions that needed
tempfile). Do the release team consider #992399 to have been adequately
resolved, or do you consider debianutils to still have a RC bug?

If debianutils reinstated tempfile(1) in bookworm, and removed it in
testing/unstable after the release of bookworm, would the release team
consider that to be an adequate transitional period?

Thanks,
smcv

Bug#521449: Non-working scripts....

[Eriberto Mota]

Control: tags -1 wontfix

Dear Adam,

Considering these scripts are examples from several people, is very
hard to the upstream keep them updated. Please, think in these files
as ideas to write new scripts.

Regards,

Eriberto

Bug#994275: Reverting breaking changes in debianutils

[Simon McVittie]

On Wed, 15 Sep 2021 at 01:36:26 +0300, Adrian Bunk wrote:
> More specifically, I am asking the Technical Committee to decide that:

I think this is really 5 separate (but related) requests, each of which
we could either uphold or decline, separately. Do you agree?

> 1. The "which" program must be provided by an essential package.

Constitutionally, I think this would have to be the TC formally offering
advice (under 6.1.5 in the Debian constitution), because the maintainers
of debianutils haven't attempted to remove "which", so there is not
yet any maintainer action that you want us to overrule.

For example, that advice could take the form of saying that if which(1)
is removed from debianutils in future, then we would expect that to be
accompanied by a suitable versioned dependency on a transitively-Essential
package that provides which(1) (either for bookworm, or indefinitely).

Does that sound right to you?

Or are you asking us to go further than that, and say that which(1)
can only be removed from debianutils if it is picked up by a different
Essential package?

> 2. The "which" program must not print any deprecation warnings.

I think that's a request to overrule the maintainer of debianutils
(under 6.1.4). I assume that was your intention?

> 3. The "which" program must not be provided through alternatives.

Also 6.1.4, I think.

> 4. The debianutils package must continue to provide the "tempfile" program.

Also 6.1.4.

Would you be equally happy with a TC resolution that keeps tempfile(1) in
the transitively-Essential set, but not necessarily via debianutils? For
example, we could consider saying that debianutils must either reinstate
tempfile(1), or add a dependency on some other (transitively Essential)
package that provides tempfile(1).

> 5. Programs in debianutils must not be moved to /usr unless there is
>project-wide consensus on packages doing such a move, and premature
>moving must be reverted.

Also 6.1.4.

smcv

Bug#995850: lintian: more context is not always a good thing

[Felix Lechner]

Hi,

On Sun, Oct 10, 2021 at 3:33 PM Thorsten Glaser  wrote:
>
> I’ve not yet tested ...
> whether the asterisk indeed allows anything to come after,
> i.e. “line * ot to” isn’t equivalent to “line *”…

I am not sure it's a good feature, but it should work. [1][2]

Kind regards
Felix Lechner

[1] 
https://salsa.debian.org/lintian/lintian/-/blob/master/lib/Lintian/Processable/Overrides.pm#L278
[2] 
https://salsa.debian.org/lintian/lintian/-/blob/master/lib/Lintian/Group.pm#L374

Bug#995392: ghostscript: ps2pdf trashes some characters

[Norbert Preining]

severity 995392 normal
tags 995392 + moreinfo
thanks

Hi all,

first of all, it seems this message didn't make it either to the list or
my computer, just found it by randomly checking transitioning.

Then, this is by far not a grave bug in TL. pdflatex is **not**
affected, since it generated pdf files without using ghostscript.

What might have some problems - and I haven't reproduced this till now
nor tested - is dvi -> ps -> pdf route.

>   * chartest3.tex:  Test: « don't ».
>   * chartest4[ab].tex:  Test: « don't finite float ».
>   * chartest5[ab].tex:  Test: « don't finite float offer affine ».
> where the 4b and 5b versions contain \pdfglyphtounicode commands for
> the ligatures (from glyphtounicode.tex), though the tests below show
> that they do not have any influence here.

Vincent, thanks for the tests, but without explanation or make files or
some hints on **what** you did run, this is not reproducible and
testable.

What I want to see is
* input file
* commands run
* log files of each program run
* what is the problematic output

Thanks

> \documentclass[12pt]{article}
> \usepackage[utf8]{inputenc}
> \usepackage[T1]{fontenc}
> \usepackage{lmodern}
> \begin{document}
> \thispagestyle{empty}
> Test: « don't ».
> \end{document}

This document and copy and paste of its content does work fine for me
with
* current sid
* latex/dvips/ps2pdf
* pdflatex

Generated pdf file can be copy/pasted.

I really don't see what is going on, thanks for any explanations.

Best

Norbert

--
PREINING Norbert  https://www.preining.info
Fujitsu Research  +  IFMGA Guide  +  TU Wien  +  TeX Live  + Debian Dev
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Bug#996087: ITP: typeshed -- collection of library stubs for Python, with static types

[Antonio Terceiro]

Package: wnpp
Severity: wishlist
Owner: Antonio Terceiro 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-pyt...@lists.debian.org

* Package name: typeshed
  Version : n/a
  Upstream Author : Several authors
* URL : https://github.com/python/typeshed
* License : Apache 2.0
  Programming Lang: Python
  Description : collection of library stubs for Python, with static types

 Typeshed contains external type annotations for the Python standard library
 and Python builtins, as well as third party packages as contributed by people
 external to those projects.

 This data can e.g. be used for static analysis, type checking or type
 inference.

 typeshed has been extracted from mypy, and is necessary in order to
 have type checking work for libraries that still don't provide their
 own type anotations. Users are encouraged to install individual types-*
 wheels, but this package will provide all the typing information in a
 single binary package.

 Preliminary packaging available at
 https://salsa.debian.org/terceiro/typeshed and will be moved into the
 Python team soon™.


signature.asc
Description: PGP signature

Bug#996086: RM: pangox-compat/0.0.2-5.1

[Simon McVittie]

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

pangox-compat is dead upstream and should be removed from testing, or
removed from Debian altogether (#947649), but it has been kept in testing
by its high popcon score (the legacy libpango1.0-0 package depended on it,
resulting in lots of installations).

It can't be removed from unstable until drbd-doc stops depending on it or
is removed (#993661), and then gtkmathview stops depending on it or is
removed (#702011); but it can at least be removed from testing.

smcv

Bug#995850: lintian: more context is not always a good thing

[Thorsten Glaser]

Felix Lechner dixit:

>By the way, you should also be able to use the wildcards * and ? in
>lieu of the line numbers right now. Please let me know if that works.

So indeed:

-mksh source: debian-watch-uses-insecure-uri 
http://www.mirbsd.org/MirOS/dist/mir/mksh/
+mksh source: debian-watch-uses-insecure-uri 
http://www.mirbsd.org/MirOS/dist/mir/mksh/ (line *)

-mksh: typo-in-manual-page usr/share/man/man1/mksh.1.gz ot to
+mksh: typo-in-manual-page usr/share/man/man1/mksh.1.gz line * ot to

These changes correctly override the issues.

I’ve not yet tested (e.g. by inserting an actual misspelling into the
manpage) whether the asterisk indeed allows anything to come after,
i.e. “line * ot to” isn’t equivalent to “line *”…

bye,
//mirabilos
-- 
[16:04:33] bkix: "veni vidi violini"
[16:04:45] bkix: "ich kam, sah und vergeigte"...

Bug#996085: mrtg: Wrong manpage level: mrtglib.1

[Joao Eriberto Mota Filho]

Package: mrtg
Version: 2.17.7-3
Severity: normal
Tags: upstream

Control: forwarded https://github.com/oetiker/mrtg/pull/48

Considering that mrtglib is a Perl Module, the right level for this
manpage is 3.

Eriberto

Bug#996084: vte2.91: wrong argument list in spawn_async documentation

[Simon McVittie]

On Sun, 10 Oct 2021 at 23:07:35 +0200, Nis Martensen wrote:
> According to
> https://lazka.github.io/pgi-docs/Vte-2.91/classes/Terminal.html#Vte.Terminal.spawn_async
> and
> https://lazka.github.io/pgi-docs/#Vte-2.91/classes/Pty.html#Vte.Pty.spawn_async
> the order of arguments includes:
> ..., spawn_flags, child_setup, timeout, ...
> 
> However, the code does not work when trying to use that argument order,
> the result is: TypeError: Argument 9 does not allow None as a value
> 
> It would be great if the code and its documentation would match.

Debian does not maintain that documentation, and the representation of
C functions in PyGI is really a question for PyGI rather than the specific
C library whose API has been wrapped.

The signature of these functions in C is:

void vte_terminal_spawn_async(VteTerminal *terminal,
  VtePtyFlags pty_flags,
  const char *working_directory,
  char **argv,
  char **envv,
  GSpawnFlags spawn_flags,
  GSpawnChildSetupFunc child_setup,
  gpointer child_setup_data,
  GDestroyNotify child_setup_data_destroy,
  int timeout,
  GCancellable *cancellable,
  VteTerminalSpawnAsyncCallback callback,
  gpointer user_data) _VTE_CXX_NOEXCEPT 
_VTE_GNUC_NONNULL(1) _VTE_GNUC_NONNULL(4);
void vte_pty_spawn_async(VtePty *pty,
 const char *working_directory,
 char **argv,
 char **envv,
 GSpawnFlags spawn_flags,
 GSpawnChildSetupFunc child_setup,
 gpointer child_setup_data,
 GDestroyNotify child_setup_data_destroy,
 int timeout,
 GCancellable *cancellable,
 GAsyncReadyCallback callback,
 gpointer user_data) _VTE_CXX_NOEXCEPT 
_VTE_GNUC_NONNULL(1) _VTE_GNUC_NONNULL(3);

and you can find the GObject-Introspection representation of them in
/usr/share/gir-1.0/Vte-2.91.gir.

It looks as though whatever software generated
https://lazka.github.io/pgi-docs/Vte-2.91 is assuming that the
(child_setup, child_setup_data, child_setup_data_destroy) group
will come out in PyGI as a single argument, child_setup.

However, from the stackoverflow question, it looks like child_setup
and child_setup_data turn into separate arguments in Python, with
only child_setup_data_destroy disappearing.

This seems like a bug in the documentation-generating tool.

smcv

Bug#995274: needrestart: false positive: rabbitmq-server

[Antonio Terceiro]

On Sun, Oct 10, 2021 at 10:51:13PM +0200, Thomas Liske wrote:
> Hi,
> 
> could you please provide the output of `needrestart -lv`?

Sure:

8<8<8<-
$ sudo needrestart -lv
[main] eval /etc/needrestart/needrestart.conf
[main] needrestart v3.5
[main] running in root mode
[Core] Using UI 'NeedRestart::UI::stdio'...
[main] systemd detected
[main] #968 uses deleted /memfd:vmem
[main] #968 is not a child
[Core] #2617 is a NeedRestart::Interp::Python
[Python] #2617: source=/home/terceiro/src/localslackirc/irc.py
[Core] #65382 is a NeedRestart::Interp::Python
[Python] #65382: source=/usr/bin/terminator
[Core] #90184 is a NeedRestart::Interp::Python
[Python] #90184: 
source=/usr/lib/python3/dist-packages/gbp/scripts/supercommand.py
[Core] #90219 is a NeedRestart::Interp::Perl
[Perl] #90219: source=/usr/bin/dpkg-buildpackage
[Core] #90247 is a NeedRestart::Interp::Perl
[Perl] #90247: source=/usr/bin/dh
[Core] #90274 is a NeedRestart::Interp::Python
[Python] #90274: 
source=/home/terceiro/src/debian/python/build-area/typeshed-0.0~git20211009.0142ea8.obsolete.1633904505.3296812/debian/install_stubs.py
[Core] #92031 is a NeedRestart::Interp::Python
[Python] #92031: source file not found, skipping
[Python] #92031:  reduced ARGV: install --system 
--target=debian/python3-typeshed/usr/lib/python3/dist-packages 
/tmp/tmpwowqtmgb/dist/types_httplib2-0.19.1-py3-none-any.whl
[main] #968 exe => /usr/lib/erlang/erts-12.0.4/bin/beam.smp
[main] trying systemctl status
[main] #968 is rabbitmq-server.service

Restarting services...
Services to be restarted:
Restart «rabbitmq-server.service»? [Ynas?] n
Service restarts being deferred:
 systemctl restart rabbitmq-server.service

No containers need to be restarted.

No user sessions are running outdated binaries.
8<8<8<-



signature.asc
Description: PGP signature

Bug#925358: qemu-user-static: mis-emulates something to do with process/signal handling

[Thorsten Glaser]

Version: 1:5.2+dfsg-11+deb11u1

On Fri, 25 Oct 2019, Thorsten Glaser wrote:

> This now happens with qemu-s390x-static for me as well, which has

Reconfirmed on bullseye, using usr/lib/klibc/bin/mksh from sid’s
mksh_59c-11_s390x.deb binary package. (I’m about to upload -12,
but I assume it’ll not differ.)

I’ve rechecked because I did things in both klibc and mksh in the
meantime to fix things, but this issue is still present.

Using usr/lib/diet/bin/mksh, usr/lib/s390x-linux-musl/bin/mksh
from the binary package work, so it must be something klibc does.

bye,
//mirabilos
-- 
15:41⎜ Somebody write a testsuite for helloworld :-)

Bug#988027: klibc: sigsetjmp ignores second argument, siglongjmp always restores signals

[Thorsten Glaser]

close 988027
thanks

I guess it works as documented for klibc, even though this is a porting
hindrance so no need to keep this bugreport open. Deliberately closing
per control instead of done as the underlying issue is still present.

Bug#996082: vte2.91: vte.terminal.spawn_async emits useless warning by default

[Simon McVittie]

Control: tags -1 + moreinfo

On Sun, 10 Oct 2021 at 22:51:10 +0200, Nis Martensen wrote:
> (reportbug:22755): VTE-WARNING **: 21:37:42.462:
> (../src/vtepty.cc:811):void vte_pty_spawn_with_fds_async(VtePty*, const
> char*, const char* const*, const char* const*, const int*, int, const
> int*, int, GSpawnFlags, GSpawnChildSetupFunc, gpointer, GDestroyNotify,
> int, GCancellable*, GAsyncReadyCallback, gpointer): runtime check
> failed: ((spawn_flags & ignored_spawn_flags()) == 0)

What exact function are you calling and what flags are you passing to it?

This warning should not appear unless spawn_flags contains one of the
flags that either are not available here, or have their behaviour
enabled by default anyway and therefore are unnecessary (namely
G_SPAWN_CLOEXEC_PIPES and/or G_SPAWN_DO_NOT_REAP_CHILD).

smcv

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

[Otto Kekäläinen]

> The problem is in the ibdata1 file (about 450MB). Deleted other database 
> directories and it still crashes, deleted ibdata1 and it runs.
>
> How to bisect mariadb from git? Tried:
> $ git bisect good mariadb-10.3.29
> $ git bisect bad mariadb-10.3.31
> the build process showed version 10.2 so I aborted it.
>
> Checked out mariadb-10.3.30 but dpkg-buildpackage failed with:
> dh_install: mariadb-plugin-cassandra missing files: 
> etc/mysql/conf.d/cassandra.cnf

Some dependency was missing and Cassandra was not built. Note that the
upstream repository is not identical to the one in Debian regarding
the contents of debian/ directory. MariaDB builds without a cache take
30 mins each and there are all kinds of things going on. Doing bisect
(fully correctly) on MariaDB is hard even for experienced developers.
Your time is probably better spent doing some other kind of debugging.

I recommend that you file a bug about this upstream, and try to attach
relevant info from the error log, maybe a strace output etc. Upstream
devs will guide you on what to debug next.

One thing you could also try is to start the server with 10.3.29 and
ensure that you have a clean shutdown (SET GLOBAL
innodb_fast_shutdown=0; SHUTDOWN) and only after that start with the
new 10.3.31 binary.

Ref
- https://mariadb.com/kb/en/shutdown/#see-also
- https://www.percona.com/blog/2020/05/07/prepare-mysql-for-a-safe-shutdown/

Bug#986507: use grep -a instead of strings(1) (fix check-support-status)

[Thomas Liske]

tags 986507 upstream fixed-upstream
thanks


Hi,

thanks for the hint. I've applied a slitly modified patch upstream to
replace binutils's strings by grep in needrestart 3.6+.

Replacing the bintuils dependency by GNU grep lowers the total
installation size by an order of magnitude.


Regards,
Thomas

On Fri, 2021-10-08 at 15:56 +1100, Trent W. Buck wrote:
> Trent W. Buck wrote:
> > I want check-support-status to be happy, but I need needrestart:
> > 
> >     bash5$ check-support-status
> >     ⋮
> >     * Source:binutils
> >   Details: Only suitable for trusted content; see
> > https://lists.debian.org/msgid-search/87lfqsomtg@mid.deneb.enyo.de
> >     ⋮
> > 
> >     bash5$ aptitude why binutils
> >     i   needrestart Depends binutils
> 
> This annoyed me again today.
> I noticed an even simple patch is to use "grep -ao".
> This is working for me.
> 
> You are already using "grep -a" elsewhere in the script, so
> this is only assuming grep supports -o.
> GNU grep supports both; busybox grep supports neither.

Bug#364913: still valid?

[Thomas Lange]

Is this bug still valid or can we close this bug?
-- 
regards Thomas

Bug#222334: link to test page

[Thomas Lange]

We may add this link which shows your browser language settings

https://manytools.org/http-html-text/browser-language/

-- 
viele Grüße Thomas

Bug#984138: fs-uae: ftbfs with GCC-11

[John Paul Adrian Glaubitz]

Control: tags -1 +patch

Hi!

On 3/3/21 17:12, Matthias Klose wrote:
> The package fails to build in a test rebuild on at least amd64 with
> gcc-11/g++-11, but succeeds to build with gcc-10/g++-10. The
> severity of this report will be raised before the bookworm release,
> so nothing has to be done for the bullseye release.

FWIW, upstream has fixed the issue on the stable branch already [1], see
attached patch. I'm just waiting for the upcoming stable version to be
released.

I'll then uploaded the fixed version immediately.

Adrian

> [1] 
> https://github.com/FrodeSolheim/fs-uae/commit/bf81e7d2a60b2c8646663889e4a4431b988ae972

-- 
 .''`.  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
From bf81e7d2a60b2c8646663889e4a4431b988ae972 Mon Sep 17 00:00:00 2001
From: Frode Solheim 
Date: Fri, 8 Oct 2021 11:39:16 +0200
Subject: [PATCH] Work around an incompatibility with C++17

---
 src/dosbox/setup.h | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/src/dosbox/setup.h b/src/dosbox/setup.h
index db75ada8..e0a3a75d 100644
--- a/src/dosbox/setup.h
+++ b/src/dosbox/setup.h
@@ -54,6 +54,12 @@ public:

 };
 
+#ifdef FSUAE
+// Work around an incompatibility with C++17. It does not seem like these
+// functions are used anyway.
+#define throw(...) throw()
+#endif
+
 class Value {
 /* 
  * Multitype storage container that is aware of the currently stored type in it.
@@ -113,6 +119,11 @@ private:
 	void set_double(std::string const& in);
 };
 
+#ifdef FSUAE
+#undef throw
+#endif
+
+
 class Property {
 public:
 	struct Changeable { enum Value {Always, WhenIdle,OnlyAtStart};};
-- 
2.33.0

Bug#994407: Binaries with same name

[Thomas Liske]

Hi,

@Patrick

this looks like a regression of #752114, doesn't it?


Regards,
Thomas


On Wed, 2021-09-15 at 18:22 +0200, ThePPK wrote:
> Package: needrestart
> Version: 3.5-4
> 
> Needrestart while run once of scripts on 
> /etc/needrestart/hook.d/30-pacman, execute pacman binary (which is
> Arch 
> Linux package manager). In Debian we have a game with this same 
> executable file name, 'pacman' and needrestart create process of
> pacman 
> what run game window.
> It's possible to force change name of pacman game or block running 
> script while pacman (package manager) isn't installed in /sbin/,
> /bin/, 
> /usr/bin/ or /usr/sbin/?
> 

Bug#972674: ITP: toolbox -- Unprivileged container development environment

[Andrej Shadura]

Hi,

On Wed, 10 Feb 2021 15:28:29 -0300 Andre Moreira Magalhaes
 wrote:
> Hi,
> 
> I ended up using this packaging as base for Endless OS and pushed
> the updated packaging to
> https://salsa.debian.org/andrunko-guest/toolbox/ (incl. update to
> 0.0.99).
> 
> The packaging still needs some work, specially regarding the two extra
> modules not yet packaged in Debian (see "debian/gocode"), but it works
> fine as is.
> 
> I also checked about using dh-golang but I don't think we should do it
> here tbh, unless upstream changes their build system from meson to go
> (the current repo dir structure doesn't play well with dh-golang).
> 
> I don't plan to work on this anymore atm but thought I'd share our
> changes in case anyone find them useful.

I took your packaging, dropped one of the vendored packages having
updated it in Debian, and uploaded it to NEW.

The Git repository is now located here:
https://salsa.debian.org/debian/podman-toolbox

-- 
Cheers,
  Andrej

Bug#996059: [Pkg-rust-maintainers] Bug#996059: exa: missing man page and shell completion scripts

[Sylvestre Ledru]

Le 10/10/2021 à 22:21, Mélanie (ariasuni) a écrit :
> Package: exa
> Version: 0.10.1-1
>
> Upstream bug: https://github.com/ogham/exa/issues/966
>
> Packages contain only the following files:
> /usr/bin/exa
> /usr/share/doc/exa/changelog.Debian.gz
> /usr/share/doc/exa/copyright
> /usr/share/man/man1/exa.1.gz
>
> It lacks the man page exa_colors.5, and the completions for fish, zsh
> and Bash.
>
> Also see:
> – Where the man pages are generated by just in the Justfile:
> https://github.com/ogham/exa/blob/0cebf3ad1c1f051096733f8c3a2d83aa73b5a659/Justfile#L98
> – How it’s done with cargo-deb:
> https://github.com/ogham/exa/blob/0cebf3ad1c1f051096733f8c3a2d83aa73b5a659/Cargo.toml#L65
>
> ___

Thanks for the bug report, I (almost) fixed them in the repo, I will
upload it demain! ;)

Cheers

S

Bug#988461: needrestart: False positive for sddm

[Thomas Liske]

tags 988461 upstream fixed-upstream
thanks


Hi,

thanks for reporting. I've updated the default configuration upstream
to ignore the all memfd mappings. The bugfix will be part of
needrestart 3.6+.


Regards,
Thomas


On Thu, 2021-05-13 at 14:44 +0200, Michail Bachmann wrote:
> Package: needrestart
> Version: 3.5-4
> Severity: normal
> 
> Dear Maintainer,
> 
> when running needrestart it always suggest that sddm needs to be
> restarted,
> even when sddm ist fresly (re-)started and no update has taken place.
> 
> Running needrestart -v gives the following explanation:
> 
> ...
> [main] #1244357 uses deleted /memfd:JITCode:QtQml
> [main] #1244357 is a child of #1244355
> [main] #1244355 exe => /usr/lib/x86_64-linux-gnu/sddm/sddm-helper
> ...
> 
> It looks like the JIT compiled Qt code erroneously triggers the
> detection.
> Adding "qr(^/memfd:JITCode:QtQml)," to the blacklist_mappings
> silences this
> warning. Would you consider to add this exception to the needrestart
> package?
> 
> Regards
> 
> Michail Bachmann
> 
> 
> -- Package-specific info:
> needrestart output:
> 
> checkrestart output:
> 
> 
> -- System Information:
> Debian Release: 11.0
>   APT prefers unstable
>   APT policy: (500, 'unstable')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 5.10.0-6-amd64 (SMP w/8 CPU threads)
> Locale: LANG=C.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE
> not set
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> Versions of packages needrestart depends on:
> ii  binutils   2.35.2-2
> ii  dpkg   1.20.9
> ii  gettext-base   0.21-4
> ii  libintl-perl   1.26-3
> ii  libmodule-find-perl    0.15-1
> ii  libmodule-scandeps-perl    1.30-1
> ii  libproc-processtable-perl  0.59-2+b1
> ii  libsort-naturally-perl 1.03-2
> ii  libterm-readkey-perl   2.38-1+b2
> ii  perl   5.32.1-4
> ii  xz-utils   5.2.5-2
> 
> Versions of packages needrestart recommends:
> ii  libpam-systemd  247.3-5
> 
> Versions of packages needrestart suggests:
> ii  iucode-tool  2.3.1-1
> pn  needrestart-session | libnotify-bin  
> 
> -- no debconf information
> 

Bug#996084: vte2.91: wrong argument list in spawn_async documentation

[Nis Martensen]

Source: vte2.91
Version: 0.62.3-1
Severity: normal
Tags: upstream
X-Debbugs-Cc: nis.marten...@web.de

According to
https://lazka.github.io/pgi-docs/Vte-2.91/classes/Terminal.html#Vte.Terminal.spawn_async
and
https://lazka.github.io/pgi-docs/#Vte-2.91/classes/Pty.html#Vte.Pty.spawn_async
the order of arguments includes:
..., spawn_flags, child_setup, timeout, ...

However, the code does not work when trying to use that argument order,
the result is: TypeError: Argument 9 does not allow None as a value

It would be great if the code and its documentation would match.

An example illustrating that there must be in fact two arguments
between the spawn_flags and the timeout can be found here:
https://stackoverflow.com/questions/55105447/virtual-python-shell-with-vte-pty-spawn-async

What is the correct list of arguments that the function takes?

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

[Ondrej Zary]

On Sunday 10 October 2021 16:55:45 Otto Kekäläinen wrote:
> Hello!
> 
> Thanks for reporting. Could you please check if this has been reported
> upstream at jira.mariadb.org?
> 
> There isn't much we can do about InnoDB internals in Debian packaging.
> 

The problem is in the ibdata1 file (about 450MB). Deleted other database 
directories and it still crashes, deleted ibdata1 and it runs.

How to bisect mariadb from git? Tried:
$ git bisect good mariadb-10.3.29
$ git bisect bad mariadb-10.3.31
the build process showed version 10.2 so I aborted it.

Checked out mariadb-10.3.30 but dpkg-buildpackage failed with:
dh_install: mariadb-plugin-cassandra missing files: 
etc/mysql/conf.d/cassandra.cnf

-- 
Ondrej Zary

Bug#934372: snapd: does not work under cgroup v2 at all

[Stefano Rivera]

Control: forwarded -1 https://bugs.launchpad.net/snapd/+bug/1926283
Control: severity -1 important

Bumping the severity back up, because this breaks unrelated software
(#996036), also re-pointing at the current upstream issue.

SR

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

Bug#996083: filezilla FTBFS with libfilezilla19

[Adrian Bunk]

Source: filezilla
Version: 3.52.2-3
Severity: serious
Tags: ftbfs bookworm sid
Control: close -1 3.55.1-1

https://buildd.debian.org/status/logs.php?pkg=filezilla=3.52.2-3%2Bb1

...
writer.cpp: In member function ‘aio_result file_writer::open(uint64_t, bool, 
aio_base::shm_flag)’:
writer.cpp:309:56: error: cannot convert ‘bool’ to ‘fz::mkdir_permissions’
  309 |   fz::mkdir(fz::to_native(local_path.GetPath()), true, false, 
_created);
  |^
  ||
  |bool
In file included from writer.cpp:3:
/usr/include/libfilezilla/local_filesys.hpp:182:99: note:   initializing 
argument 3 of ‘fz::result fz::mkdir(const native_string&, bool, 
fz::mkdir_permissions, fz::native_string*)’
  182 | result FZ_PUBLIC_SYMBOL mkdir(native_string const& absolute_path, bool 
recurse, mkdir_permissions permissions = mkdir_permissions::normal, 
native_string * last_created = nullptr);
  | 
~~^~~
/bin/bash ../../libtool  --tag=CXX   --mode=compile g++ -std=c++17 
-DHAVE_CONFIG_H   -I../../config -I/usr/include/p11-kit-1 -DBUILDING_FILEZILLA 
-Wdate-time -D_FORTIFY_SOURCE=2 -fvisibility=hidden -g -O2 
-ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wall -c -o ftp/libfzclient_private_la-delete.lo `test 
-f 'ftp/delete.cpp' || echo './'`ftp/delete.cpp
make[4]: *** [Makefile:1351: libfzclient_private_la-writer.lo] Error 1



This is already fixed in the version at mentors.debian.net (#994495).

Bug#996082: vte2.91: vte.terminal.spawn_async emits useless warning by default

[Nis Martensen]

Source: vte2.91
Version: 0.62.3-1
Severity: minor
Tags: upstream
X-Debbugs-Cc: nis.marten...@web.de

According to
https://lazka.github.io/pgi-docs/Vte-2.91/classes/Terminal.html#Vte.Terminal.spawn_sync
spawn_sync is deprecated and one should use spawn_async instead.

After trying to switch reportbug to calling spawn_async, I get this
warning:

(reportbug:22755): VTE-WARNING **: 21:37:42.462:
(../src/vtepty.cc:811):void vte_pty_spawn_with_fds_async(VtePty*, const
char*, const char* const*, const char* const*, const int*, int, const
int*, int, GSpawnFlags, GSpawnChildSetupFunc, gpointer, GDestroyNotify,
int, GCancellable*, GAsyncReadyCallback, gpointer): runtime check
failed: ((spawn_flags & ignored_spawn_flags()) == 0)

Is it necessary to emit this warning even if no special SpawnFlags are
needed for the application?

Bug#996036: LXD: snap lxd cgroup noise causes VirtSubproc to fail

[Stefano Rivera]

Hi Paul (2021.10.10_11:59:12_-0700)
> Shouldn't that bug be raised in severity, considering the request you
> are now asking from autopkgtest? I'm not really enthusiastic to add this
> kind of "work around" code for a bug that's already known for 2 years.
> Maybe there should be a warning in snapd to silence that warning?

Yeah, I'm with you on that. It's an annoying message.

Also, found another place I had to hack (my local hacks all got blown
away by the recent autopkgtest upload, so it was a good time to forward
them...)

SR

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  +1 415 683 3272
From 084996eb89aa99f2907ed24b5d4c83f5f7480610 Mon Sep 17 00:00:00 2001
From: Stefano Rivera 
Date: Sun, 10 Oct 2021 10:58:37 -0700
Subject: [PATCH] Ignore innoccuous warnings from snapped lxd

They don't mean that the command has failed
---
 lib/VirtSubproc.py | 4 
 lib/adt_testbed.py | 5 +
 2 files changed, 9 insertions(+)

diff --git a/lib/VirtSubproc.py b/lib/VirtSubproc.py
index bf948e6..01acdaa 100644
--- a/lib/VirtSubproc.py
+++ b/lib/VirtSubproc.py
@@ -186,6 +186,10 @@ def check_exec(argv, downp=False, outp=False, timeout=0, fail_on_stderr=True):
 if status:
 bomb("%s%s failed (exit status %d, stderr %r)" %
  ((downp and "(down) " or ""), argv, status, err))
+# Ignore innoccuous warnings from snapped lxd
+if (err == 'WARNING: cgroup v2 is not fully supported yet, proceeding with '
+   'partial confinement\n'):
+err = ''
 if fail_on_stderr and err:
 bomb("%s unexpectedly produced stderr output `%s'" %
  (argv, err))
diff --git a/lib/adt_testbed.py b/lib/adt_testbed.py
index 9965e5d..909213c 100644
--- a/lib/adt_testbed.py
+++ b/lib/adt_testbed.py
@@ -554,6 +554,11 @@ class Testbed:
 self.command('auxverb_debug_fail')
 self.bomb('testbed auxverb failed with exit code %i' % proc.returncode)
 
+# Ignore innoccuous warnings from snapped lxd
+if (err == 'WARNING: cgroup v2 is not fully supported yet, proceeding '
+   'with partial confinement\n'):
+err = ''
+
 return (proc.returncode, out, err)
 
 def check_exec(self, argv, stdout=False, kind='short'):
-- 
2.33.0



signature.asc
Description: PGP signature

Bug#931345: nvchecker: autopkgtest regression in June 2019

[Afif Elghraoui]

Hello,

On 11/12/20 2:11 AM, Paul Gevers wrote:
> severity 931345 serious
> user debian...@lists.debian.org
> usertag 931345 timeout
> thanks
> 
> please upload a fixed package.
> 
> The test if timing out nowadays too, so I'll block it from being tested
> to avoid stress on our infrastructure until this bug is fixed.
> 

This bug has been fixed for about a week now but nvchecker still appears
to be blocked from debci. Does that need to be manually changed? I
expected it to be removed automatically once the bug was closed.

thanks and regards
Afif

-- 
Afif Elghraoui | عفيف الغراوي
https://afif.ghraoui.name

Bug#996081: exa: description on packages.debian.org has last three words formatted as monospace

[ariasuni]

Package: exa
Version: 0.10.1-1

On packages.debian.org, e.g. https://packages.debian.org/sid/exa, exa’s 
description appears like that (in HTML):



exa is an improved file lister with more features and better defaults.
It uses colours to distinguish file types and metadata. It knows about
symlinks, extended attributes, and Git. And it’s small, fast, and just
 one single binary.


The three last words shouldn’t be formatted in any particular way and 
should be displayed with the rest of the sentence.

Bug#995274: needrestart: false positive: rabbitmq-server

[Thomas Liske]

Hi,

could you please provide the output of `needrestart -lv`?


TIA,
Thomas


On Tue, 2021-09-28 at 20:34 -0300, Antonio Terceiro wrote:
> Package: needrestart
> Version: 3.5-4
> Severity: normal
> 
> Dear Maintainer,
> 
> Recently every time I install something, needrestart seems to think
> that
> rabbitmq-server needs to be restart, even when there were norelated
> upgrades. I tried calling needrestart right after booting, and even
> then
> it reported rabbitmq-server as needing a restart.
> 
> This can easily be reproduced in a clean testin VM:
> 
> 8<8<8<---
> --
> root@host:~# apt update -q=2
> 20 packages can be upgraded. Run 'apt list --upgradable' to see them.
> root@host:~# apt install -q=2 -y needrestart
> [...]
> root@host:~# apt install -q=2 -y rabbitmq-server
> [...]
> Package configuration
> 
> 
> 
> 
> 
>     ┌┤ Daemons using outdated libraries ├─┐
>     │ │
>     │ │
>     │ Which services should be restarted? │
>     │ │
>     │    [*] rabbitmq-server.service  │
>     │ │
>     │ │
>     │     │
>     │ │
>     └─┘
> 
> 
> 
> 
> 
> 
>  systemctl restart rabbitmq-server.service
> 
> No containers need to be restarted.
> 
> No user sessions are running outdated binaries.
> 8<8<8<---
> --
> 
> -- System Information:
> Debian Release: bookworm/sid
>   APT prefers testing-debug
>   APT policy: (900, 'testing-debug'), (900, 'testing'), (500,
> 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1,
> 'experimental')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 5.14.0-1-amd64 (SMP w/4 CPU threads)
> Locale: LANG=pt_BR.UTF-8, LC_CTYPE=pt_BR.UTF-8 (charmap=UTF-8),
> LANGUAGE=pt_BR:pt:en
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> Versions of packages needrestart depends on:
> ii  binutils   2.37-7
> ii  dpkg   1.20.9
> ii  gettext-base   0.21-4
> ii  libintl-perl   1.26-3
> ii  libmodule-find-perl    0.15-1
> ii  libmodule-scandeps-perl    1.31-1
> ii  libproc-processtable-perl  0.611-1
> ii  libsort-naturally-perl 1.03-2
> ii  libterm-readkey-perl   2.38-1+b2
> ii  perl   5.32.1-6
> ii  xz-utils   5.2.5-2
> 
> Versions of packages needrestart recommends:
> ii  libpam-systemd  247.9-1
> 
> Versions of packages needrestart suggests:
> ii  iucode-tool    2.3.1-1
> ii  libnotify-bin  0.7.9-3
> 
> -- no debconf information

Bug#996079: gnome-shell-timer: does not declare compatibility with GNOME Shell 41

[Simon McVittie]

Package: gnome-shell-timer
Version: 3.38.0-1
Severity: normal
Tags: bookworm sid
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: gnome-shell-41

The metadata.json for this extension doesn't declare compatibility with
GNOME 41. I don't know whether the actual code will need changes or not:
the conservative assumption is that it probably will (so please test).
gnome-shell 41 should be available in experimental soon.

In versions of GNOME Shell up to 3.38, metadata.json didn't matter much,
because validation of extensions' metadata against the installed Shell
version was disabled by default; but since GNOME 40 the default has changed
back to enabling the version check by default, in an effort to avoid
issues caused by outdated extensions remaining enabled. As a result,
GNOME Shell extensions in bookworm should probably have a dependency like:

Depends: gnome-shell (>= x), gnome-shell (<< y~)

where x and y are set according to metadata.json.
gnome-shell-extension-caffeine is a good example of this technique.

When we do the GNOME Shell 41 transition, hopefully soon, we will have
to either update this extension or remove it from testing. It would be
useful to get a fixed version into experimental.

Thanks,
smcv

Bug#996080: transition: pcl

[Jochen Sprickerhof]

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

Hi release team,

I would like to transition pcl. The autogenerated ben file looks fine
and ros-perception-pcl builds against the new version. For python-pcl I
will upload a fixed version myself.

Cheers Jochen

Bug#996078: gnome-shell-pomodoro: does not declare compatibility with GNOME Shell 41

[Simon McVittie]

Package: gnome-shell-pomodoro
Version: 0.18.0-0.1
Severity: normal
Tags: bookworm sid
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: gnome-shell-41

The metadata.json for this extension doesn't declare compatibility with
GNOME 41. I don't know whether the actual code will need changes or not:
the conservative assumption is that it probably will (so please test).
gnome-shell 41 should be available in experimental soon.

In versions of GNOME Shell up to 3.38, metadata.json didn't matter much,
because validation of extensions' metadata against the installed Shell
version was disabled by default; but since GNOME 40 the default has changed
back to enabling the version check by default, in an effort to avoid
issues caused by outdated extensions remaining enabled. As a result,
GNOME Shell extensions in bookworm should probably have a dependency like:

Depends: gnome-shell (>= x), gnome-shell (<< y~)

where x and y are set according to metadata.json.
gnome-shell-extension-caffeine is a good example of this technique.

When we do the GNOME Shell 41 transition, hopefully soon, we will have
to either update this extension or remove it from testing. It would be
useful to get a fixed version into experimental.

Thanks,
smcv

Bug#996077: gnome-shell-mailnag: does not declare compatibility with GNOME Shell 41

[Simon McVittie]

Package: gnome-shell-mailnag
Version: 40.0-1
Severity: normal
Tags: bookworm sid
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: gnome-shell-41

The metadata.json for this extension doesn't declare compatibility with
GNOME 41. I don't know whether the actual code will need changes or not:
the conservative assumption is that it probably will (so please test).
gnome-shell 41 should be available in experimental soon.

In versions of GNOME Shell up to 3.38, metadata.json didn't matter much,
because validation of extensions' metadata against the installed Shell
version was disabled by default; but since GNOME 40 the default has changed
back to enabling the version check by default, in an effort to avoid
issues caused by outdated extensions remaining enabled. As a result,
GNOME Shell extensions in bookworm should probably have a dependency like:

Depends: gnome-shell (>= x), gnome-shell (<< y~)

where x and y are set according to metadata.json.
gnome-shell-extension-caffeine is a good example of this technique.

When we do the GNOME Shell 41 transition, hopefully soon, we will have
to either update this extension or remove it from testing. It would be
useful to get a fixed version into experimental.

Thanks,
smcv

Bug#996076: gnome-shell-extension-weather: does not declare compatibility with GNOME Shell 41

[Simon McVittie]

Package: gnome-shell-extension-weather
Version: 0.0~git20210509.d714eb1-1
Severity: normal
Tags: bookworm sid
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: gnome-shell-41

The metadata.json for this extension doesn't declare compatibility with
GNOME 41. I don't know whether the actual code will need changes or not:
the conservative assumption is that it probably will (so please test).
gnome-shell 41 should be available in experimental soon.

In versions of GNOME Shell up to 3.38, metadata.json didn't matter much,
because validation of extensions' metadata against the installed Shell
version was disabled by default; but since GNOME 40 the default has changed
back to enabling the version check by default, in an effort to avoid
issues caused by outdated extensions remaining enabled. As a result,
GNOME Shell extensions in bookworm should probably have a dependency like:

Depends: gnome-shell (>= x), gnome-shell (<< y~)

where x and y are set according to metadata.json.
gnome-shell-extension-caffeine is a good example of this technique.

When we do the GNOME Shell 41 transition, hopefully soon, we will have
to either update this extension or remove it from testing. It would be
useful to get a fixed version into experimental.

Thanks,
smcv

Bug#996075: gnome-shell-extension-volume-mixer: does not declare compatibility with GNOME Shell 41

[Simon McVittie]

Package: gnome-shell-extension-volume-mixer
Version: 40.0+dfsg-2
Severity: normal
Tags: bookworm sid
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: gnome-shell-41

The metadata.json for this extension doesn't declare compatibility with
GNOME 41. I don't know whether the actual code will need changes or not:
the conservative assumption is that it probably will (so please test).
gnome-shell 41 should be available in experimental soon.

When we do the GNOME Shell 41 transition, hopefully soon, we will have
to either update this extension or remove it from testing. It would be
useful to get a fixed version into experimental.

Thanks,
smcv

Bug#996053: New Url to package with close of bug in changelog

[Erik A. Brandstadmoen]

I created a new version of the package, which closes this bug in the changelog:

https://github.com/erikbra/grate/releases/download/0.9.4/grate_0.9.4-2_amd64.deb

Regards, Erik B.

Bug#996074: gnome-shell-extension-trash: does not declare compatibility with GNOME Shell 41

[Simon McVittie]

Package: gnome-shell-extension-trash
Version: 0.2.0-git20200326.3425fcf1-1
Severity: normal
Tags: bookworm sid
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: gnome-shell-41

The metadata.json for this extension doesn't declare compatibility with
GNOME 41. I don't know whether the actual code will need changes or not:
the conservative assumption is that it probably will (so please test).
gnome-shell 41 should be available in experimental soon.

In versions of GNOME Shell up to 3.38, metadata.json didn't matter much,
because validation of extensions' metadata against the installed Shell
version was disabled by default; but since GNOME 40 the default has changed
back to enabling the version check by default, in an effort to avoid
issues caused by outdated extensions remaining enabled. As a result,
GNOME Shell extensions in bookworm should probably have a dependency like:

Depends: gnome-shell (>= x), gnome-shell (<< y~)

where x and y are set according to metadata.json.
gnome-shell-extension-caffeine is a good example of this technique.

When we do the GNOME Shell 41 transition, hopefully soon, we will have
to either update this extension or remove it from testing. It would be
useful to get a fixed version into experimental.

Thanks,
smcv

Bug#996073: gnome-shell-extension-top-icons-plus: does not declare compatibility with GNOME Shell 41

[Simon McVittie]

Package: gnome-shell-extension-top-icons-plus
Version: 27-4
Severity: normal
Tags: bookworm sid
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: gnome-shell-41

The metadata.json for this extension doesn't declare compatibility with
GNOME 41. I don't know whether the actual code will need changes or not:
the conservative assumption is that it probably will (so please test).
gnome-shell 41 should be available in experimental soon.

In versions of GNOME Shell up to 3.38, metadata.json didn't matter much,
because validation of extensions' metadata against the installed Shell
version was disabled by default; but since GNOME 40 the default has changed
back to enabling the version check by default, in an effort to avoid
issues caused by outdated extensions remaining enabled. As a result,
GNOME Shell extensions in bookworm should probably have a dependency like:

Depends: gnome-shell (>= x), gnome-shell (<< y~)

where x and y are set according to metadata.json.
gnome-shell-extension-caffeine is a good example of this technique.

When we do the GNOME Shell 41 transition, hopefully soon, we will have
to either update this extension or remove it from testing. It would be
useful to get a fixed version into experimental.

Thanks,
smcv

Bug#996072: gnome-shell-extension-tilix-dropdown: does not declare compatibility with GNOME Shell 41

[Simon McVittie]

Package: gnome-shell-extension-tilix-dropdown
Version: 7-1
Severity: normal
Tags: bookworm sid
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: gnome-shell-41

The metadata.json for this extension doesn't declare compatibility with
GNOME 41. I don't know whether the actual code will need changes or not:
the conservative assumption is that it probably will (so please test).
gnome-shell 41 should be available in experimental soon.

In versions of GNOME Shell up to 3.38, metadata.json didn't matter much,
because validation of extensions' metadata against the installed Shell
version was disabled by default; but since GNOME 40 the default has changed
back to enabling the version check by default, in an effort to avoid
issues caused by outdated extensions remaining enabled. As a result,
GNOME Shell extensions in bookworm should probably have a dependency like:

Depends: gnome-shell (>= x), gnome-shell (<< y~)

where x and y are set according to metadata.json.
gnome-shell-extension-caffeine is a good example of this technique.

When we do the GNOME Shell 41 transition, hopefully soon, we will have
to either update this extension or remove it from testing. It would be
useful to get a fixed version into experimental.

Thanks,
smcv

Bug#996071: gnome-shell-extension-system-monitor: does not declare compatibility with GNOME Shell 41

[Simon McVittie]

Package: gnome-shell-extension-system-monitor
Version: 40-1
Severity: normal
Tags: bookworm sid
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: gnome-shell-41

The metadata.json for this extension doesn't declare compatibility with
GNOME 41. I don't know whether the actual code will need changes or not:
the conservative assumption is that it probably will (so please test).
gnome-shell 41 should be available in experimental soon.

In versions of GNOME Shell up to 3.38, metadata.json didn't matter much,
because validation of extensions' metadata against the installed Shell
version was disabled by default; but since GNOME 40 the default has changed
back to enabling the version check by default, in an effort to avoid
issues caused by outdated extensions remaining enabled. As a result,
GNOME Shell extensions in bookworm should probably have a dependency like:

Depends: gnome-shell (>= x), gnome-shell (<< y~)

where x and y are set according to metadata.json.
gnome-shell-extension-caffeine is a good example of this technique.

When we do the GNOME Shell 41 transition, hopefully soon, we will have
to either update this extension or remove it from testing. It would be
useful to get a fixed version into experimental.

Thanks,
smcv

Bug#996070: gnome-shell-extension-sound-device-chooser: does not declare compatibility with GNOME Shell 41

[Simon McVittie]

Package: gnome-shell-extension-sound-device-chooser
Version: 38-2
Severity: normal
Tags: bookworm sid
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: gnome-shell-41

The metadata.json for this extension doesn't declare compatibility with
GNOME 41. I don't know whether the actual code will need changes or not:
the conservative assumption is that it probably will (so please test).
gnome-shell 41 should be available in experimental soon.

In versions of GNOME Shell up to 3.38, metadata.json didn't matter much,
because validation of extensions' metadata against the installed Shell
version was disabled by default; but since GNOME 40 the default has changed
back to enabling the version check by default, in an effort to avoid
issues caused by outdated extensions remaining enabled. As a result,
GNOME Shell extensions in bookworm should probably have a dependency like:

Depends: gnome-shell (>= x), gnome-shell (<< y~)

where x and y are set according to metadata.json.
gnome-shell-extension-caffeine is a good example of this technique.

When we do the GNOME Shell 41 transition, hopefully soon, we will have
to either update this extension or remove it from testing. It would be
useful to get a fixed version into experimental.

Thanks,
smcv

Bug#996069: gnome-shell-extension-pixelsaver: does not declare compatibility with GNOME Shell 41

[Simon McVittie]

Package: gnome-shell-extension-pixelsaver
Version: 1.24-2
Severity: normal
Tags: bookworm sid
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: gnome-shell-41

The metadata.json for this extension doesn't declare compatibility with
GNOME 41. I don't know whether the actual code will need changes or not:
the conservative assumption is that it probably will (so please test).
gnome-shell 41 should be available in experimental soon.

In versions of GNOME Shell up to 3.38, metadata.json didn't matter much,
because validation of extensions' metadata against the installed Shell
version was disabled by default; but since GNOME 40 the default has changed
back to enabling the version check by default, in an effort to avoid
issues caused by outdated extensions remaining enabled. As a result,
GNOME Shell extensions in bookworm should probably have a dependency like:

Depends: gnome-shell (>= x), gnome-shell (<< y~)

where x and y are set according to metadata.json.
gnome-shell-extension-caffeine is a good example of this technique.

When we do the GNOME Shell 41 transition, hopefully soon, we will have
to either update this extension or remove it from testing. It would be
useful to get a fixed version into experimental.

Thanks,
smcv

Bug#996068: gnome-shell-extension-panel-osd: does not declare compatibility with GNOME Shell 41

[Simon McVittie]

Package: gnome-shell-extension-panel-osd
Version: 1.0.50.gc032923-1
Severity: normal
Tags: bookworm sid
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: gnome-shell-41

The metadata.json for this extension doesn't declare compatibility with
GNOME 41. I don't know whether the actual code will need changes or not:
the conservative assumption is that it probably will (so please test).
gnome-shell 41 should be available in experimental soon.

In versions of GNOME Shell up to 3.38, metadata.json didn't matter much,
because validation of extensions' metadata against the installed Shell
version was disabled by default; but since GNOME 40 the default has changed
back to enabling the version check by default, in an effort to avoid
issues caused by outdated extensions remaining enabled. As a result,
GNOME Shell extensions in bookworm should probably have a dependency like:

Depends: gnome-shell (>= x), gnome-shell (<< y~)

where x and y are set according to metadata.json.
gnome-shell-extension-caffeine is a good example of this technique.

When we do the GNOME Shell 41 transition, hopefully soon, we will have
to either update this extension or remove it from testing. It would be
useful to get a fixed version into experimental.

Thanks,
smcv

Bug#996067: gnome-shell-extension-no-annoyance: does not declare compatibility with GNOME Shell 41

[Simon McVittie]

Package: gnome-shell-extension-no-annoyance
Version: 0+20210717-12dc667-1
Severity: normal
Tags: bookworm sid
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: gnome-shell-41

The metadata.json for this extension doesn't declare compatibility with
GNOME 41. I don't know whether the actual code will need changes or not:
the conservative assumption is that it probably will (so please test).
gnome-shell 41 should be available in experimental soon.

In versions of GNOME Shell up to 3.38, metadata.json didn't matter much,
because validation of extensions' metadata against the installed Shell
version was disabled by default; but since GNOME 40 the default has changed
back to enabling the version check by default, in an effort to avoid
issues caused by outdated extensions remaining enabled. As a result,
GNOME Shell extensions in bookworm should probably have a dependency like:

Depends: gnome-shell (>= x), gnome-shell (<< y~)

where x and y are set according to metadata.json.
gnome-shell-extension-caffeine is a good example of this technique.

When we do the GNOME Shell 41 transition, hopefully soon, we will have
to either update this extension or remove it from testing. It would be
useful to get a fixed version into experimental.

Thanks,
smcv

Bug#996066: gnome-shell-extension-multi-monitors: does not declare compatibility with GNOME Shell 41

[Simon McVittie]

Package: gnome-shell-extension-multi-monitors
Version: 23-1
Severity: normal
Tags: bookworm sid
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: gnome-shell-41

The metadata.json for this extension doesn't declare compatibility with
GNOME 41. I don't know whether the actual code will need changes or not:
the conservative assumption is that it probably will (so please test).
gnome-shell 41 should be available in experimental soon.

In versions of GNOME Shell up to 3.38, metadata.json didn't matter much,
because validation of extensions' metadata against the installed Shell
version was disabled by default; but since GNOME 40 the default has changed
back to enabling the version check by default, in an effort to avoid
issues caused by outdated extensions remaining enabled. As a result,
GNOME Shell extensions in bookworm should probably have a dependency like:

Depends: gnome-shell (>= x), gnome-shell (<< y~)

where x and y are set according to metadata.json.
gnome-shell-extension-caffeine is a good example of this technique.

When we do the GNOME Shell 41 transition, hopefully soon, we will have
to either update this extension or remove it from testing. It would be
useful to get a fixed version into experimental.

Thanks,
smcv

Bug#996064: gnome-shell-extension-impatience: does not declare compatibility with GNOME Shell 41

[Simon McVittie]

Package: gnome-shell-extension-impatience
Version: 0.4.5+git20210412-e8e132f-1
Severity: normal
Tags: bookworm sid
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: gnome-shell-41

The metadata.json for this extension doesn't declare compatibility with
GNOME 41. I don't know whether the actual code will need changes or not:
the conservative assumption is that it probably will (so please test).
gnome-shell 41 should be available in experimental soon.

In versions of GNOME Shell up to 3.38, metadata.json didn't matter much,
because validation of extensions' metadata against the installed Shell
version was disabled by default; but since GNOME 40 the default has changed
back to enabling the version check by default, in an effort to avoid
issues caused by outdated extensions remaining enabled. As a result,
GNOME Shell extensions in bookworm should probably have a dependency like:

Depends: gnome-shell (>= x), gnome-shell (<< y~)

where x and y are set according to metadata.json.
gnome-shell-extension-caffeine is a good example of this technique.

When we do the GNOME Shell 41 transition, hopefully soon, we will have
to either update this extension or remove it from testing. It would be
useful to get a fixed version into experimental.

Thanks,
smcv

Bug#996065: gnome-shell-extension-move-clock: does not declare compatibility with GNOME Shell 41

[Simon McVittie]

Package: gnome-shell-extension-move-clock
Version: 1.01-2
Severity: normal
Tags: bookworm sid
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: gnome-shell-41

The metadata.json for this extension doesn't declare compatibility with
GNOME 41. I don't know whether the actual code will need changes or not:
the conservative assumption is that it probably will (so please test).
gnome-shell 41 should be available in experimental soon.

In versions of GNOME Shell up to 3.38, metadata.json didn't matter much,
because validation of extensions' metadata against the installed Shell
version was disabled by default; but since GNOME 40 the default has changed
back to enabling the version check by default, in an effort to avoid
issues caused by outdated extensions remaining enabled. As a result,
GNOME Shell extensions in bookworm should probably have a dependency like:

Depends: gnome-shell (>= x), gnome-shell (<< y~)

where x and y are set according to metadata.json.
gnome-shell-extension-caffeine is a good example of this technique.

When we do the GNOME Shell 41 transition, hopefully soon, we will have
to either update this extension or remove it from testing. It would be
useful to get a fixed version into experimental.

Thanks,
smcv

Bug#996063: gnome-shell-extension-hijra: does not declare compatibility with GNOME Shell 41

[Simon McVittie]

Package: gnome-shell-extension-hijra
Version: 1.0-1
Severity: normal
Tags: bookworm sid
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: gnome-shell-41

The metadata.json for this extension doesn't declare compatibility with
GNOME 41. I don't know whether the actual code will need changes or not:
the conservative assumption is that it probably will (so please test).
gnome-shell 41 should be available in experimental soon.

In versions of GNOME Shell up to 3.38, metadata.json didn't matter much,
because validation of extensions' metadata against the installed Shell
version was disabled by default; but since GNOME 40 the default has changed
back to enabling the version check by default, in an effort to avoid
issues caused by outdated extensions remaining enabled. As a result,
GNOME Shell extensions in bookworm should probably have a dependency like:

Depends: gnome-shell (>= x), gnome-shell (<< y~)

where x and y are set according to metadata.json.
gnome-shell-extension-caffeine is a good example of this technique.

When we do the GNOME Shell 41 transition, hopefully soon, we will have
to either update this extension or remove it from testing. It would be
useful to get a fixed version into experimental.

Thanks,
smcv

Bug#996062: gnome-shell-extension-hide-veth: does not declare compatibility with GNOME Shell 41

[Simon McVittie]

Package: gnome-shell-extension-hide-veth
Version: 1.0.2-1.1
Severity: normal
Tags: bookworm sid
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: gnome-shell-41

The metadata.json for this extension doesn't declare compatibility with
GNOME 41. I don't know whether the actual code will need changes or not:
the conservative assumption is that it probably will (so please test).
gnome-shell 41 should be available in experimental soon.

In versions of GNOME Shell up to 3.38, metadata.json didn't matter much,
because validation of extensions' metadata against the installed Shell
version was disabled by default; but since GNOME 40 the default has changed
back to enabling the version check by default, in an effort to avoid
issues caused by outdated extensions remaining enabled. As a result,
GNOME Shell extensions in bookworm should probably have a dependency like:

Depends: gnome-shell (>= x), gnome-shell (<< y~)

where x and y are set according to metadata.json.
gnome-shell-extension-caffeine is a good example of this technique.

When we do the GNOME Shell 41 transition, hopefully soon, we will have
to either update this extension or remove it from testing. It would be
useful to get a fixed version into experimental.

Thanks,
smcv

Bug#996061: gnome-shell-extension-hide-activities: does not declare compatibility with GNOME Shell 41

[Simon McVittie]

Package: gnome-shell-extension-hide-activities
Version: 0.00~git20131024.1.6574986-2
Severity: normal
Tags: bookworm sid
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: gnome-shell-41

The metadata.json for this extension doesn't declare compatibility with
GNOME 41. I don't know whether the actual code will need changes or not:
the conservative assumption is that it probably will (so please test).
gnome-shell 41 should be available in experimental soon.

In versions of GNOME Shell up to 3.38, metadata.json didn't matter much,
because validation of extensions' metadata against the installed Shell
version was disabled by default; but since GNOME 40 the default has changed
back to enabling the version check by default, in an effort to avoid
issues caused by outdated extensions remaining enabled. As a result,
GNOME Shell extensions in bookworm should probably have a dependency like:

Depends: gnome-shell (>= x), gnome-shell (<< y~)

where x and y are set according to metadata.json.
gnome-shell-extension-caffeine is a good example of this technique.

When we do the GNOME Shell 41 transition, hopefully soon, we will have
to either update this extension or remove it from testing. It would be
useful to get a fixed version into experimental.

Thanks,
smcv

Bug#996060: gnome-shell-extension-hamster: does not declare compatibility with GNOME Shell 41

[Simon McVittie]

Package: gnome-shell-extension-hamster
Version: 0.10.0+git20210628-1
Severity: normal
Tags: bookworm sid
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: gnome-shell-41

The metadata.json for this extension doesn't declare compatibility with
GNOME 41. I don't know whether the actual code will need changes or not:
the conservative assumption is that it probably will (so please test).
gnome-shell 41 should be available in experimental soon.

In versions of GNOME Shell up to 3.38, metadata.json didn't matter much,
because validation of extensions' metadata against the installed Shell
version was disabled by default; but since GNOME 40 the default has changed
back to enabling the version check by default, in an effort to avoid
issues caused by outdated extensions remaining enabled. As a result,
GNOME Shell extensions in bookworm should probably have a dependency like:

Depends: gnome-shell (>= x), gnome-shell (<< y~)

where x and y are set according to metadata.json.
gnome-shell-extension-caffeine is a good example of this technique.

When we do the GNOME Shell 41 transition, hopefully soon, we will have
to either update this extension or remove it from testing. It would be
useful to get a fixed version into experimental.

Thanks,
smcv

Bug#996059: exa: missing man page and shell completion scripts

[ariasuni]

Package: exa
Version: 0.10.1-1

Upstream bug: https://github.com/ogham/exa/issues/966

Packages contain only the following files:
/usr/bin/exa
/usr/share/doc/exa/changelog.Debian.gz
/usr/share/doc/exa/copyright
/usr/share/man/man1/exa.1.gz

It lacks the man page exa_colors.5, and the completions for fish, zsh 
and Bash.


Also see:
– Where the man pages are generated by just in the Justfile: 
https://github.com/ogham/exa/blob/0cebf3ad1c1f051096733f8c3a2d83aa73b5a659/Justfile#L98
– How it’s done with cargo-deb: 
https://github.com/ogham/exa/blob/0cebf3ad1c1f051096733f8c3a2d83aa73b5a659/Cargo.toml#L65

Bug#996058: gnome-shell-extension-gpaste: does not declare compatibility with GNOME Shell 41

[Simon McVittie]

Package: gnome-shell-extension-gpaste
Version: 3.40.2-1
Severity: normal
Tags: bookworm sid
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: gnome-shell-41

The metadata.json for this extension doesn't declare compatibility with
GNOME 41. I don't know whether the actual code will need changes or not:
the conservative assumption is that it probably will (so please test).
gnome-shell 41 should be available in experimental soon.

In versions of GNOME Shell up to 3.38, metadata.json didn't matter much,
because validation of extensions' metadata against the installed Shell
version was disabled by default; but since GNOME 40 the default has changed
back to enabling the version check by default, in an effort to avoid
issues caused by outdated extensions remaining enabled. As a result,
GNOME Shell extensions in bookworm should probably have a dependency like:

Depends: gnome-shell (>= x), gnome-shell (<< y~)

where x and y are set according to metadata.json.
gnome-shell-extension-caffeine is a good example of this technique.

When we do the GNOME Shell 41 transition, hopefully soon, we will have
to either update this extension or remove it from testing. It would be
useful to get a fixed version into experimental.

Thanks,
smcv

Bug#996056: gnome-shell-extension-freon: does not declare compatibility with GNOME Shell 41

[Simon McVittie]

Package: gnome-shell-extension-freon
Version: 44+dfsg-3
Severity: normal
Tags: bookworm sid
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: gnome-shell-41

The metadata.json for this extension doesn't declare compatibility with
GNOME 41. I don't know whether the actual code will need changes or not:
the conservative assumption is that it probably will (so please test).
gnome-shell 41 should be available in experimental soon.

In versions of GNOME Shell up to 3.38, metadata.json didn't matter much,
because validation of extensions' metadata against the installed Shell
version was disabled by default; but since GNOME 40 the default has changed
back to enabling the version check by default, in an effort to avoid
issues caused by outdated extensions remaining enabled. As a result,
GNOME Shell extensions in bookworm should probably have a dependency like:

Depends: gnome-shell (>= x), gnome-shell (<< y~)

where x and y are set according to metadata.json.
gnome-shell-extension-caffeine is a good example of this technique.

When we do the GNOME Shell 41 transition, hopefully soon, we will have
to either update this extension or remove it from testing. It would be
useful to get a fixed version into experimental.

Thanks,
smcv

Bug#996057: gnome-shell-extension-gamemode: does not declare compatibility with GNOME Shell 41

[Simon McVittie]

Package: gnome-shell-extension-gamemode
Version: 5-2
Severity: normal
Tags: bookworm sid
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: gnome-shell-41

The metadata.json for this extension doesn't declare compatibility with
GNOME 41. I don't know whether the actual code will need changes or not:
the conservative assumption is that it probably will (so please test).
gnome-shell 41 should be available in experimental soon.

In versions of GNOME Shell up to 3.38, metadata.json didn't matter much,
because validation of extensions' metadata against the installed Shell
version was disabled by default; but since GNOME 40 the default has changed
back to enabling the version check by default, in an effort to avoid
issues caused by outdated extensions remaining enabled. As a result,
GNOME Shell extensions in bookworm should probably have a dependency like:

Depends: gnome-shell (>= x), gnome-shell (<< y~)

where x and y are set according to metadata.json.
gnome-shell-extension-caffeine is a good example of this technique.

When we do the GNOME Shell 41 transition, hopefully soon, we will have
to either update this extension or remove it from testing. It would be
useful to get a fixed version into experimental.

Thanks,
smcv

Bug#996055: gnome-shell-extension-easyscreencast: does not declare compatibility with GNOME Shell 41

[Simon McVittie]

Package: gnome-shell-extension-easyscreencast
Version: 1.1.0+git20210116.3252312-1
Severity: normal
Tags: bookworm sid
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: gnome-shell-41

The metadata.json for this extension doesn't declare compatibility with
GNOME 41. I don't know whether the actual code will need changes or not:
the conservative assumption is that it probably will (so please test).
gnome-shell 41 should be available in experimental soon.

In versions of GNOME Shell up to 3.38, metadata.json didn't matter much,
because validation of extensions' metadata against the installed Shell
version was disabled by default; but since GNOME 40 the default has changed
back to enabling the version check by default, in an effort to avoid
issues caused by outdated extensions remaining enabled. As a result,
GNOME Shell extensions in bookworm should probably have a dependency like:

Depends: gnome-shell (>= x), gnome-shell (<< y~)

where x and y are set according to metadata.json.
gnome-shell-extension-caffeine is a good example of this technique.

When we do the GNOME Shell 41 transition, hopefully soon, we will have
to either update this extension or remove it from testing. It would be
useful to get a fixed version into experimental.

Thanks,
smcv

Bug#996054: gnome-shell-extension-draw-on-your-screen: does not declare compatibility with GNOME Shell 41

[Simon McVittie]

Package: gnome-shell-extension-draw-on-your-screen
Version: 11-1
Severity: normal
Tags: bookworm sid
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: gnome-shell-41

The metadata.json for this extension doesn't declare compatibility with
GNOME 41. I don't know whether the actual code will need changes or not:
the conservative assumption is that it probably will (so please test).
gnome-shell 41 should be available in experimental soon.

In versions of GNOME Shell up to 3.38, metadata.json didn't matter much,
because validation of extensions' metadata against the installed Shell
version was disabled by default; but since GNOME 40 the default has changed
back to enabling the version check by default, in an effort to avoid
issues caused by outdated extensions remaining enabled. As a result,
GNOME Shell extensions in bookworm should probably have a dependency like:

Depends: gnome-shell (>= x), gnome-shell (<< y~)

where x and y are set according to metadata.json.
gnome-shell-extension-caffeine is a good example of this technique.

When we do the GNOME Shell 41 transition, hopefully soon, we will have
to either update this extension or remove it from testing. It would be
useful to get a fixed version into experimental.

Thanks,
smcv

Bug#996053: ITP: grate -- SQL scripts migration runner

[Erik A. Brandstadmoen]

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

Introducing grate
=

I have created a database migration tool, named grate. It is in active
development, and written in .NET 6.
It is compiled as a static binary, independent of any installation of
.NET framework on the host system. This is done to be able to
keep the size of the runtime image low. I am the creator and
maintainer of both the original source, and the Debian package.

grate is inspired by, and meant to be (mostly) compatible with good
old RoundhousE (https://github.com/chucknorris/roundhouse),
which I have been maintaining for the last 3 years. However, it is
written from the ground up using modern .NET,
to make maintenance easier, and encourage more developers to
contribute, as the old project was getting less and less traction.

The tool is a no-nonsense SQL migrator, based on pure SQL scripts, and
aims to be a low-complexity alternative to more complex database
migration tools from enterprise vendors. At the time of writing, it
supports MariaDM/MySQL, PostgreSQL and Microsoft SQL server.
More databases are planned.

Motivation


I aim to support as many platforms as possible, in a friction-less
way, and native installers are a good incetiment to wide adoption. I'd
really appreciate
if the package could be distributed in the official Debian dpkg distribution.

Sources
===

The homepage of the tool can be found here: https://erikbra.github.io/grate/
It is open source, with an MIT license, and hosted on github, here:
https://github.com/erikbra/grate

Package downloads


The tool can be downloaded from the github releases pages, at the time
of writing, the latest version is 0.9.4:
https://github.com/erikbra/grate/releases/tag/0.9.4
A direct link to the .deb package can be found here:
https://github.com/erikbra/grate/releases/download/0.9.4/grate_0.9.4-1_amd64.deb


Regards,

Erik A.Brandstadmoen
e...@brandstadmoen.net

Bug#996052: gnome-shell-extension-disconnect-wifi: does not declare compatibility with GNOME Shell 41

[Simon McVittie]

Package: gnome-shell-extension-disconnect-wifi
Version: 28-1
Severity: normal
Tags: bookworm sid
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: gnome-shell-41

The metadata.json for this extension doesn't declare compatibility with
GNOME 41. I don't know whether the actual code will need changes or not:
the conservative assumption is that it probably will (so please test).
gnome-shell 41 should be available in experimental soon.

In versions of GNOME Shell up to 3.38, metadata.json didn't matter much,
because validation of extensions' metadata against the installed Shell
version was disabled by default; but since GNOME 40 the default has changed
back to enabling the version check by default, in an effort to avoid
issues caused by outdated extensions remaining enabled. As a result,
GNOME Shell extensions in bookworm should probably have a dependency like:

Depends: gnome-shell (>= x), gnome-shell (<< y~)

where x and y are set according to metadata.json.
gnome-shell-extension-caffeine is a good example of this technique.

When we do the GNOME Shell 41 transition, hopefully soon, we will have
to either update this extension or remove it from testing. It would be
useful to get a fixed version into experimental.

Thanks,
smcv

Bug#996051: gnome-shell-extension-desktop-icons: does not declare compatibility with GNOME Shell 41

[Simon McVittie]

Package: gnome-shell-extension-desktop-icons
Version: 20.04.0+git20200908-8
Severity: normal
Tags: bookworm sid
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: gnome-shell-41

The metadata.json for this extension doesn't declare compatibility with
GNOME 41. I don't know whether the actual code will need changes or not:
the conservative assumption is that it probably will (so please test).
gnome-shell 41 should be available in experimental soon.

In versions of GNOME Shell up to 3.38, metadata.json didn't matter much,
because validation of extensions' metadata against the installed Shell
version was disabled by default; but since GNOME 40 the default has changed
back to enabling the version check by default, in an effort to avoid
issues caused by outdated extensions remaining enabled. As a result,
GNOME Shell extensions in bookworm should probably have a dependency like:

Depends: gnome-shell (>= x), gnome-shell (<< y~)

where x and y are set according to metadata.json.
gnome-shell-extension-caffeine is a good example of this technique.

When we do the GNOME Shell 41 transition, hopefully soon, we will have
to either update this extension or remove it from testing. It would be
useful to get a fixed version into experimental.

Thanks,
smcv

Bug#996050: gnome-shell-extension-dashtodock: does not declare compatibility with GNOME Shell 41

[Simon McVittie]

Package: gnome-shell-extension-dashtodock
Version: 69-1
Severity: normal
Tags: bookworm sid
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: gnome-shell-41

The metadata.json for this extension doesn't declare compatibility with
GNOME 41. I don't know whether the actual code will need changes or not:
the conservative assumption is that it probably will (so please test).
gnome-shell 41 should be available in experimental soon.

In versions of GNOME Shell up to 3.38, metadata.json didn't matter much,
because validation of extensions' metadata against the installed Shell
version was disabled by default; but since GNOME 40 the default has changed
back to enabling the version check by default, in an effort to avoid
issues caused by outdated extensions remaining enabled. As a result,
GNOME Shell extensions in bookworm should probably have a dependency like:

Depends: gnome-shell (>= x), gnome-shell (<< y~)

where x and y are set according to metadata.json.
gnome-shell-extension-caffeine is a good example of this technique.

When we do the GNOME Shell 41 transition, hopefully soon, we will have
to either update this extension or remove it from testing. It would be
useful to get a fixed version into experimental.

Thanks,
smcv

Bug#996049: gnome-shell-extension-dash-to-panel: does not declare compatibility with GNOME Shell 41

[Simon McVittie]

Package: gnome-shell-extension-dash-to-panel
Version: 43-2
Severity: normal
Tags: bookworm sid
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: gnome-shell-41

The metadata.json for this extension doesn't declare compatibility with
GNOME 41. I don't know whether the actual code will need changes or not:
the conservative assumption is that it probably will (so please test).
gnome-shell 41 should be available in experimental soon.

In versions of GNOME Shell up to 3.38, metadata.json didn't matter much,
because validation of extensions' metadata against the installed Shell
version was disabled by default; but since GNOME 40 the default has changed
back to enabling the version check by default, in an effort to avoid
issues caused by outdated extensions remaining enabled. As a result,
GNOME Shell extensions in bookworm should probably have a dependency like:

Depends: gnome-shell (>= x), gnome-shell (<< y~)

where x and y are set according to metadata.json.
gnome-shell-extension-caffeine is a good example of this technique.

When we do the GNOME Shell 41 transition, hopefully soon, we will have
to either update this extension or remove it from testing. It would be
useful to get a fixed version into experimental.

Thanks,
smcv

Bug#996048: postfix-mta-sts-resolver: autopkgtest doesn't handle new version of ca-certificates nicely: rehash: warning: skipping ca-certificates.crt,it does not contain exactly one certificate or CRL

[Paul Gevers]

Source: postfix-mta-sts-resolver
Version: 1.0.0-4
Severity: serious
Tags: sid bookworm
User: debian...@lists.debian.org
Usertags: needs-update
Control: affects -1 src:ca-certificates

[X-Debbugs-CC: debian...@lists.debian.org,
ca-certifica...@packages.debian.org]

Dear maintainer(s),

With a recent upload of ca-certificates the autopkgtest of
postfix-mta-sts-resolver fails in testing when that autopkgtest is run
with the binary packages of ca-certificates from unstable. It passes
when run with only packages from testing. In tabular form:

 passfail
ca-certificates  from testing20211004
postfix-mta-sts-resolver from testing1.0.0-4
all others   from testingfrom testing

I copied some of the output at the bottom of this report. The *warning*
seems to be innocent, but causes the test to fail because by default
autopkgtest considers output on stderr as fatal (without the
allow-stderr restriction).

Currently this regression is blocking the migration of ca-certificates
to testing [1]. Of course, ca-certificates shouldn't just break your
autopkgtest (or even worse, your package), but it seems to me that the
change in ca-certificates was intended and your package needs to update
to the new situation.

If this is a real problem in your package (and not only in your
autopkgtest), the right binary package(s) from ca-certificates should
really add a versioned Breaks on the unfixed version of (one of your)
package(s). Note: the Breaks is nice even if the issue is only in the
autopkgtest as it helps the migration software to figure out the right
versions to combine in the tests.

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

Paul

[1] https://qa.debian.org/excuses.php?package=ca-certificates

https://ci.debian.net/data/autopkgtest/testing/amd64/p/postfix-mta-sts-resolver/15856707/log.gz

autopkgtest [19:39:52]: test run: [---
Updating certificates in /etc/ssl/certs...
rehash: warning: skipping ca-certificates.crt,it does not contain
exactly one certificate or CRL
1 added, 0 removed; done.
Running hooks in /etc/ca-certificates/update.d...
done.
autopkgtest [19:40:04]: test run: ---]
autopkgtest [19:40:04]: test run:  - - - - - - - - - - results - - - - -
- - - - -
run  FAIL stderr: rehash: warning: skipping
ca-certificates.crt,it does not contain exactly one certificate or CRL



OpenPGP_signature
Description: OpenPGP digital signature

Bug#996047: gnome-shell-extension-bluetooth-quick-connect: does not declare compatibility with GNOME Shell 41

[Simon McVittie]

Package: gnome-shell-extension-bluetooth-quick-connect
Version: 23-1
Severity: normal
Tags: bookworm sid
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: gnome-shell-41

The metadata.json for this extension doesn't declare compatibility with
GNOME 41. I don't know whether the actual code will need changes or not:
the conservative assumption is that it probably will (so please test).
gnome-shell 41 should be available in experimental soon.

When we do the GNOME Shell 41 transition, hopefully soon, we will have
to either update this extension or remove it from testing. It would be
useful to get a fixed version into experimental.

Thanks,
smcv

Bug#996046: gnome-shell-extension-autohidetopbar: does not declare compatibility with GNOME Shell 41

[Simon McVittie]

Package: gnome-shell-extension-autohidetopbar
Version: 20210525-2
Severity: normal
Tags: bookworm sid
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: gnome-shell-41

The metadata.json for this extension doesn't declare compatibility with
GNOME 41. I don't know whether the actual code will need changes or not:
the conservative assumption is that it probably will (so please test).
gnome-shell 41 should be available in experimental soon.

In versions of GNOME Shell up to 3.38, metadata.json didn't matter much,
because validation of extensions' metadata against the installed Shell
version was disabled by default; but since GNOME 40 the default has changed
back to enabling the version check by default, in an effort to avoid
issues caused by outdated extensions remaining enabled. As a result,
GNOME Shell extensions in bookworm should probably have a dependency like:

Depends: gnome-shell (>= x), gnome-shell (<< y~)

where x and y are set according to metadata.json.
gnome-shell-extension-caffeine is a good example of this technique.

When we do the GNOME Shell 41 transition, hopefully soon, we will have
to either update this extension or remove it from testing. It would be
useful to get a fixed version into experimental.

Thanks,
smcv

Bug#996045: gnome-shell-extension-arc-menu: does not declare compatibility with GNOME Shell 41

[Simon McVittie]

Package: gnome-shell-extension-arc-menu
Version: 49-1
Severity: normal
Tags: bookworm sid
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: gnome-shell-41

The metadata.json for this extension doesn't declare compatibility with
GNOME 41. I don't know whether the actual code will need changes or not:
the conservative assumption is that it probably will (so please test).
gnome-shell 41 should be available in experimental soon.

In versions of GNOME Shell up to 3.38, metadata.json didn't matter much,
because validation of extensions' metadata against the installed Shell
version was disabled by default; but since GNOME 40 the default has changed
back to enabling the version check by default, in an effort to avoid
issues caused by outdated extensions remaining enabled. As a result,
GNOME Shell extensions in bookworm should probably have a dependency like:

Depends: gnome-shell (>= x), gnome-shell (<< y~)

where x and y are set according to metadata.json.
gnome-shell-extension-caffeine is a good example of this technique.

When we do the GNOME Shell 41 transition, hopefully soon, we will have
to either update this extension or remove it from testing. It would be
useful to get a fixed version into experimental.

Thanks,
smcv

Bug#995934: python-gevent: diff for NMU version 20.9.0-2.1

[Sandro Tosi]

On Sun, Oct 10, 2021 at 7:26 AM László Böszörményi (GCS)  
wrote:
>
> On Sat, Oct 9, 2021 at 7:25 AM Sandro Tosi  wrote:
> > On Fri, Oct 8, 2021 at 3:12 PM László Böszörményi (GCS)  
> > wrote:
> > >  I can't devote enough time to this package. Feel free any of you
> > > taking this package to the Python Team and maintain it there.
> >
> > I can help maintain this package, just because I maintain one of its
> > rdeps. Do you have a git repo you're using to package python-gevent?
> > if so, we can migrate that under
> > https://salsa.debian.org/python-team/packages (if not, we're going to
> > create it from the source packages).
>  Long story short, I don't have one.

no worries, i've created a git repo from the debian snapshot history
at https://salsa.debian.org/python-team/packages/python-gevent and
will make and upload momentarily to fix the metadata and such

> > Do you still want to be in the Uploaders list?
>  It's up to your decision. I can't devote time to the package. You can
> put me there, but don't expect much work.

Sounds good, I think it's nice to maintain continuity; if in the long
run it's more noisy on your DDPO page or similar we can revisit

> > since we're talking about this, did you give it a thought if you want
> > to start maintaining your other python packages under the DPT
> > umbrella?
>  Will think about it and let you know soon, sending separate emails about 
> those.

Thanks even just for considering it

-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Bug#982823: #982823 debian-faq: [INTL:pt] Partial Portuguese translation

[Holger Wansing]

Control: tags -1 + pending

Pushed into git, tagging bug as pending


-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#982823: #982823 debian-faq: [INTL:pt] Partial Portuguese translation

[Holger Wansing]

Américo Monteiro  wrote (Date: Sun, 14 Feb 2021 22:12:02 
UTC):
> I was working on this translation when it was removed from po4a translation 
> requests... 
> 
> I don't know were this translation was moved to, but as I got half work done 
> here, you might want 
> to merge my strings (half work) into the package and somebody else can finish 
> it...
> 
> or you can put the package back in po4a so I can finish my work
> 
> Feel free to use this file.

There has been a conversion to split the different chapters into separate
po files, but po format is still the used translation format.

I have merged the file you provided into the numerous po files for Portuguese;
maybe you want to continue translation work this way?

https://salsa.debian.org/ddp-team/debian-faq/-/commit/bcf2d20623428390ee31b74b1ab3629e27aa7e6c


Holger



-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#996044: dpkg: Print message about possible cause of local changes detected (changelog bump required)

[Samuel Henrique]

Package: dpkg
X-Debbugs-Cc: samuel...@debian.org
Severity: wishlist
Tags: patch

Multiple times I had to help newcomers when they were working with gbp
and importing a new upstream release, they would usually hit the
error:
"
dpkg-source: info: local changes detected, the modified files are:
...
dpkg-source: info: you can integrate the local changes with dpkg-source --commit
dpkg-source: error: aborting due to unexpected upstream changes, see /tmp/...
E: Failed to package source directory ...
"

This happened due to them forgetting to update the version in
d/changelog after importing the new release.

It would be nice if among the errors there was a message suggesting
that the issue could have been caused by that, I believe this would
help many newcomers working with gbp.

The current message already states which version dpkg is trying to
build, so one ~could~ understand what's the issue when noticing that
the previous release is there, in reality I've seen so many people
miss that (myself included) that I think having this extra info
message will be worthy.

Path attached.

Thank you

--
Samuel Henrique 
From 4427ecc3cea40e2c3a407dbcb8a42dbe45a49d73 Mon Sep 17 00:00:00 2001
From: Samuel Henrique 
Date: Sun, 10 Oct 2021 20:43:18 +0100
Subject: [PATCH] Add info message about possible cause of local changes
 detected

 When working with gbp, this issue is usually caused by
 a new upstream release being imported while missing to
 bump the version in d/changelog.
---
 scripts/Dpkg/Source/Package/V2.pm | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/scripts/Dpkg/Source/Package/V2.pm b/scripts/Dpkg/Source/Package/V2.pm
index 05dd3ba64..18f4a9d1c 100644
--- a/scripts/Dpkg/Source/Package/V2.pm
+++ b/scripts/Dpkg/Source/Package/V2.pm
@@ -559,6 +559,8 @@ sub do_build {
 unless (-z $tmpdiff or $self->{options}{auto_commit}) {
 info(g_('you can integrate the local changes with %s'),
  'dpkg-source --commit');
+info(g_('this could also have been caused by importing a new upstream ' .
+'release while forgetting to bump the version in d/changelog'));
 error(g_('aborting due to unexpected upstream changes, see %s'),
   $tmpdiff);
 }
-- 
2.33.0

Bug#992668: ricochet-im: does not start

[Sebastian Ramacher]

Control: reopen -1

On 2021-09-21 13:08:16 +0800, Paul Wise wrote:
> Control: fixed -1 + 1.1.4-3+b5
> 
> On Sat, 18 Sep 2021 13:06:25 +0800 Paul Wise wrote:
> 
> > I'll request the release team to rebuild it in bullseye/bookworm.
> 
> The rebuild has now happened for unstable/testing.

While I initially scheduled these binNMUs, I no longer think that this
was the correct "fix" for this bug. There is at least the issue that
ricochet-im links with ubsan which is potentially a security issue. See
https://www.openwall.com/lists/oss-security/2016/02/17/9 (thanks to
aurel32 for the link)

And then the question remains if libubsan broke its ABI or broken code
was generated before GCC 10 or …

Cheers

> 
> -- 
> bye,
> pabs
> 
> https://wiki.debian.org/PaulWise



-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#996042: Missing sources for the html part

[Shengjing Zhu]

Package: ttyd
Version: 1.6.3+20210924-1
Severity: serious
X-Debbugs-Cc: z...@debian.org

+ src/html.h is not the preferred source format, it's generated by the source
  in html/ dir.

+ source in html/ dir is not completed, all devDependencies and dependencies
  listed in html/package.json is not provided.

Bug#994416: transition: urdfdom

[Sebastian Ramacher]

Control: tags -1 = confirmed

On 2021-10-05 00:27:53 +0200, Jose Luis Rivero wrote:
> On Sun, Sep 19, 2021 at 6:10 PM Sebastian Ramacher 
> wrote:
> 
> > The automatically generated tracker at
> > https://release.debian.org/transitions/html/auto-console-bridge.html
> > detects more reverse dependencies. Do those also build fine with the new
> > version of console-bridge?
> >
> 
> Thanks Sebastian for pointing that out. I've fixed ceres-solver in the
> testing server and now it builds many more packages, I think all the ones
> in the auto transition slot are ready:
> 
> 2021/10/04 22:25:04 Build results:
> 2021/10/04 22:25:04 PASSED: ros-rviz
> 2021/10/04 22:25:04 PASSED: ros-geometric-shapes
> 2021/10/04 22:25:04 PASSED: ros-opencv-apps
> 2021/10/04 22:25:04 PASSED: urdfdom
> 2021/10/04 22:25:04 PASSED: ros-resource-retriever
> 2021/10/04 22:25:04 PASSED: ros-navigation-msgs
> 2021/10/04 22:25:04 PASSED: ros-image-pipeline
> 2021/10/04 22:25:04 PASSED: ros-geometry
> 2021/10/04 22:25:04 PASSED: ros-common-msgs
> 2021/10/04 22:25:04 PASSED: ros-vision-opencv
> 2021/10/04 22:25:04 PASSED: ros-urdf
> 2021/10/04 22:25:04 PASSED: ros-roscpp-core
> 2021/10/04 22:25:04 PASSED: ros-image-common
> 2021/10/04 22:25:04 PASSED: ros-actionlib
> 2021/10/04 22:25:04 PASSED: ros-class-loader
> 2021/10/04 22:25:04 PASSED: ros-bond-core
> 2021/10/04 22:25:04 PASSED: ros-rosconsole-bridge
> 2021/10/04 22:25:04 PASSED: ros-pluginlib
> 2021/10/04 22:25:04 PASSED: ros-diagnostics
> 2021/10/04 22:25:04 PASSED: ros-interactive-markers
> 2021/10/04 22:25:04 PASSED: ros-perception-pcl
> 2021/10/04 22:25:04 PASSED: ros-rosconsole
> 2021/10/04 22:25:04 PASSED: mrpt
> 2021/10/04 22:25:04 PASSED: ros-pcl-msgs
> 2021/10/04 22:25:04 PASSED: ros-robot-state-publisher
> 2021/10/04 22:25:04 PASSED: ros-ros-comm
> 2021/10/04 22:25:04 PASSED: ros-laser-geometry
> 2021/10/04 22:25:04 PASSED: ros-dynamic-reconfigure
> 2021/10/04 22:25:04 PASSED: sdformat
> 2021/10/04 22:25:04 PASSED: ros-ros-comm-msgs
> 2021/10/04 22:25:04 PASSED: ros-nodelet-core
> 2021/10/04 22:25:04 PASSED: ros-geometry2
> 2021/10/04 22:25:04 PASSED: ros-collada-urdf
> 2021/10/04 22:25:04 PASSED: ros-kdl-parser
> 
> https://build.osrfoundation.org/job/debian-ratt-builder/110/console
> 
> Let me know if you see other problems.

Please go ahead

Cheers

> 
> 
> 
> >
> > Cheers
> >
> > >
> > > Ben file:
> > >
> > > title = "urdfdom";
> > > is_affected = .depends ~ "libconsole-bridge0.4" | .depends ~
> > "libconsole-bridge1.0";
> > > is_good = .depends ~ "libconsole-bridge1.0";
> > > is_bad = .depends ~ "libconsole-bridge0.4";
> > >
> > > Thanks!
> > >
> >
> > --
> > Sebastian Ramacher
> >

-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#994391: Acknowledgement (vdirsyncer is unusable)

[gregor herrmann]

On Wed, 06 Oct 2021 20:17:35 +0200, Vincent-Xavier JUMEL wrote:

> I've upgraded click-threading to 0.5.0 and vdirsyncer works again.
> Should I fill a bugreport against python3-click-threading ?

I got the same error [0] today, after upgrading python3-click from
7.1.2-1 to 8.0.2-1 in unstable.

Reverting to the older version in testing helps.

(python3-click-threading is at 0.4.4-2 since forever.)

Cheers,
gregor

 
[0]
% /usr/bin/vdirsyncer -vdebug sync 
debug: Using 1 maximal workers.
error: Unknown error occurred: unmatched ')' (, line 1)
error: Use `-vdebug` to see the full traceback.
debug:   File "/usr/lib/python3/dist-packages/vdirsyncer/cli/__init__.py", line 
30, in inner
debug: f(*a, **kw)
debug:   File "/usr/lib/python3/dist-packages/vdirsyncer/cli/__init__.py", line 
145, in sync
debug: with wq.join():
debug:   File "/usr/lib/python3.9/contextlib.py", line 119, in __enter__
debug: return next(self.gen)
debug:   File "/usr/lib/python3/dist-packages/vdirsyncer/cli/utils.py", line 
364, in join
debug: with ui_worker.patch_click():
debug:   File "/usr/lib/python3.9/contextlib.py", line 119, in __enter__
debug: return next(self.gen)
debug:   File "/usr/lib/python3/dist-packages/click_threading/__init__.py", 
line 144, in patch_click
debug: with patch_ui_functions(wrapper):
debug:   File "/usr/lib/python3.9/contextlib.py", line 119, in __enter__
debug: return next(self.gen)
debug:   File "/usr/lib/python3/dist-packages/click_threading/monkey.py", line 
50, in patch_ui_functions
debug: stub_f = eval('lambda {s}: {n}._real_click_fn({a})'

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


signature.asc
Description: Digital Signature

Bug#996014: transition: orocos-kdl

[Sebastian Ramacher]

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

On 2021-10-10 10:36:09 +0200, Jochen Sprickerhof wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> 
> Hi release team,
> 
> I would like to transition orocos-kdl. The auto generated ben file looks
> fine and I've rebuild all reverse dependencies successfully.

Please go ahead

Cheers

> 
> Cheers Jochen
> 

-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#992675: resynthesizer missing in bullseye

[Udo Richter]

Even more, the current 20200927 version claims in the changelog that
resynthesizer was ported to python3, but its missing entirely.

Bug#996041: metview: FTBFS in bookworm: unresolved symbols

[Sebastian Ramacher]

Source: metview
Version: 5.10.2-1
Severity: serious
Tags: ftbfs sid bookworm
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: sramac...@debian.org

metview fails to build in bookworm:
| /usr/bin/c++ -g -O2 -ffile-prefix-map=/<>=. 
-fstack-protector-strong -std=gnu++14  -Wdate-time -D_FORTIFY_SOURCE=2 -pipe 
-fpermissive -Wno-write-strings -Wno-deprecated -Werror=return-type -O3 
-DNDEBUG -Wl,-z,relro -Wl,-z,now-Wl,--disable-new-dtags 
CMakeFiles/Eccharts.dir/Eccharts.cc.o -o ../../../bin/Eccharts  
-Wl,-rpath,/<>/debian/build/lib:/usr/lib/x86_64-linux-gnu/openmpi/lib:
 ../../../lib/libMetview.so.0.0.0 ../../../lib/libMvFTimeUtil.so.0.0.0 
../../../lib/libmarsclient.so.0.0.0 /usr/lib/x86_64-linux-gnu/libeccodes.so.0 
../../../lib/libmir.so.0.0.0 /usr/lib/x86_64-linux-gnu/libatlas_ecmwf.so.0.26 
/usr/lib/x86_64-linux-gnu/libeckit_mpi.so.0d 
/usr/lib/x86_64-linux-gnu/openmpi/lib/libmpi.so 
/usr/lib/gcc/x86_64-linux-gnu/10/libgomp.so 
/usr/lib/x86_64-linux-gnu/libpthread.so 
/usr/lib/x86_64-linux-gnu/libeckit_linalg.so.0d 
/usr/lib/x86_64-linux-gnu/libeckit_geometry.so.0d 
/usr/lib/x86_64-linux-gnu/libeckit_option.so.0d 
/usr/lib/x86_64-linux-gnu/libeckit.so.0d 
/usr/lib/x86_64-linux-gnu/libeccodes.so.0 
/usr/lib/x86_64-linux-gnu/libemosR64.so 
/usr/lib/x86_64-linux-gnu/libeccodes.so.0 /usr/lib/x86_64-linux-gnu/libfftw3.so 
/usr/lib/x86_64-linux-gnu/libcurl.so -lterralib -lemosR64 -leccodes -leckit 
-leckit_option /usr/lib/x86_64-linux-gnu/libnetcdf.so 
/usr/lib/x86_64-linux-gnu/libodccore.so.0d 
/usr/lib/x86_64-linux-gnu/libeckit_sql.so.0d 
/usr/lib/x86_64-linux-gnu/libeckit.so.0d -lm /usr/lib/x86_64-linux-gnu/librt.so 
-lpthread -ldl 
| /usr/bin/ld: CMakeFiles/Eccharts.dir/Eccharts.cc.o: in function 
`MvMacroCallerService::registerCallbacks()':
| ./debian/build/metview/src/Eccharts/./metview/src/Eccharts/Eccharts.cc:50: 
undefined reference to `add_progress_callback'
| /usr/bin/ld: 
./debian/build/metview/src/Eccharts/./metview/src/Eccharts/Eccharts.cc:50: 
undefined reference to `add_progress_callback'
| /usr/bin/ld: 
./debian/build/metview/src/Eccharts/./metview/src/Eccharts/Eccharts.cc:53: 
undefined reference to `add_reply_callback'
| /usr/bin/ld: CMakeFiles/Eccharts.dir/Eccharts.cc.o: in function 
`Eccharts::generateData(MvRequest const&, MvRequest&, 
std::__cxx11::basic_string, std::allocator > 
const&, std::__cxx11::basic_string, 
std::allocator > const&, bool)':
| ./debian/build/metview/src/Eccharts/./metview/src/Eccharts/Eccharts.cc:364: 
undefined reference to `svc_connect'
| /usr/bin/ld: 
./debian/build/metview/src/Eccharts/./metview/src/Eccharts/Eccharts.cc:365: 
undefined reference to `process_service'
| /usr/bin/ld: CMakeFiles/Eccharts.dir/Eccharts.cc.o: in function 
`MvMacroCallerService::registerCallbacks()':
| ./debian/build/metview/src/Eccharts/./metview/src/Eccharts/Eccharts.cc:53: 
undefined reference to `add_reply_callback'
| /usr/bin/ld: ../../../lib/libMetview.so.0.0.0: undefined reference to 
`get_svc_msg'
| /usr/bin/ld: ../../../lib/libMetview.so.0.0.0: undefined reference to 
`create_service'
| /usr/bin/ld: ../../../lib/libMetview.so.0.0.0: undefined reference to 
`exit_timeout'
| /usr/bin/ld: ../../../lib/libMetview.so.0.0.0: undefined reference to 
`record_function'
| /usr/bin/ld: ../../../lib/libMetview.so.0.0.0: undefined reference to 
`set_svc_err'
| /usr/bin/ld: ../../../lib/libMetview.so.0.0.0: undefined reference to 
`wait_service'
| /usr/bin/ld: ../../../lib/libMetview.so.0.0.0: undefined reference to 
`pool_fetch'
| /usr/bin/ld: ../../../lib/libMetview.so.0.0.0: undefined reference to 
`recording'
| /usr/bin/ld: ../../../lib/libMetview.so.0.0.0: undefined reference to 
`call_function'
| /usr/bin/ld: ../../../lib/libMetview.so.0.0.0: undefined reference to 
`get_svc_err'
| /usr/bin/ld: ../../../lib/libMetview.so.0.0.0: undefined reference to 
`send_progress'
| /usr/bin/ld: ../../../lib/libMetview.so.0.0.0: undefined reference to 
`pool_link_objects'
| /usr/bin/ld: ../../../lib/libMetview.so.0.0.0: undefined reference to 
`set_maximum'
| /usr/bin/ld: ../../../lib/libMetview.so.0.0.0: undefined reference to 
`send_later'
| /usr/bin/ld: ../../../lib/libMetview.so.0.0.0: undefined reference to 
`destroy_service'
| /usr/bin/ld: ../../../lib/libMetview.so.0.0.0: undefined reference to 
`pool_link'
| /usr/bin/ld: ../../../lib/libMetview.so.0.0.0: undefined reference to 
`get_svc_ref'
| /usr/bin/ld: ../../../lib/libMetview.so.0.0.0: undefined reference to 
`pool_store'
| /usr/bin/ld: ../../../lib/libMetview.so.0.0.0: undefined reference to 
`send_message'
| /usr/bin/ld: ../../../lib/libMetview.so.0.0.0: undefined reference to 
`call_service'
| /usr/bin/ld: ../../../lib/libMetview.so.0.0.0: undefined reference to 
`add_service_callback'
| /usr/bin/ld: ../../../lib/libMetview.so.0.0.0: undefined reference to 
`keep_alive'
| /usr/bin/ld: ../../../lib/libMetview.so.0.0.0: undefined reference to 
`re_dispatch'
| /usr/bin/ld: 

Bug#996028: InnoDB: corrupted TRX_NO after upgrading to 10.3.31

[Yves-Alexis Perez]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

control: subscribe -1

On Sun, 10 Oct 2021 16:13:29 +0200 Ondrej Zary  wrote:
> Package: mariadb-server
> Version: 1:10.3.31-0+deb10u1
> Severity: grave
> Justification: causes non-serious data loss
> 
> Dear Maintainer,
> upgrading mariadb-server from 1:10.3.29-0+deb10u1 to 1:10.3.31-0+deb10u1
failed
> because mariadb failed to start. /var/log/mysql/error.log:
> 
> 2021-10-10 15:12:49 0 [ERROR] InnoDB: corrupted TRX_NO 10002001c6986c3
> 2021-10-10 15:12:49 0 [ERROR] InnoDB: Plugin initialization aborted with
error Data structure corruption
> 2021-10-10 15:12:50 0 [ERROR] Plugin 'InnoDB' init function returned error.
> 2021-10-10 15:12:50 0 [ERROR] Plugin 'InnoDB' registration as a STORAGE
ENGINE failed.
> 2021-10-10 15:12:50 0 [ERROR] Unknown/unsupported storage engine: InnoDB
> 2021-10-10 15:12:50 0 [ERROR] Aborting
> 
> Fortunately, it works after downgrading back to 10.3.29.
> Data does not seem to be corrupted.
> 

For what's it's worth I'm experiencing the same issue on my installation. I
took me some time to find that bug (and I started to dig how to repair innodb
stuff. Good to know downgrading should help, thanks.

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

iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAmFjNSIACgkQ3rYcyPpX
RFsxlQgAo0eUU9T8XaIsYIw/jx4dmbRf9DO8/IxPvFuMw0zkn7JO2LxL61IRIcAa
SDljx7UjnJpTpJ6Nc6XXQ8sU3EIb4qUen1dRME383jcUEAN0Yh3F2cvBmNkjV7bN
rDdRf74leH76uYo9sPIgWnZwy2U2I9HVKhlD3uo2MF53ksem1yVJh3Jvll5w0ZsM
SsMCO2wTjq3RFbc38bqKASSh/+UvXAxxY/6R6bxc+YIWqsim9z8XQ9TKZXdnjPS+
aOcJblZarGOjdC2AwbeT9GVaBoaCx9V9RlQDn3WoMvVhHvjfI32j+tEG1uWnicC/
q1tnUp/9oBnvt8eYDbRY3ny3oC6ylA==
=oOyd
-END PGP SIGNATURE-

Bug#996016: libreoffice: fails to send email

[Rene Engelhard]

[ please always keep the Bug in CC so that discussions about it get
recorded.

Readding. ]


Hi.

Am 10.10.21 um 20:44 schrieb Alex:
> And what is in LO settings?
> LO Settings point to /usr/lib/thunderbird

OK, as I guessed. Then anything can be in KDEs session doesn't matter.

> What if you set your mailer as xdg-email?
>
>
> That works as expected. Thanks.
>
As expected. And xdg-email knows what you want thunderbird :-)

> I just tried it: LOs default has sensible-lomua set. That one opened
>> Thunderbird in my  GNOME and happily set mail.
>>
Although best is to keep it as sensible-lomua which then runs xdg-open
>> case `basename "$MAILER"` in
>>  sensible-lomua)
>>  if [ -x /usr/bin/xdg-email ] ; then
>>  MAILER=/usr/bin/xdg-email

[...]


And as said sensible-lomua (which is the default setting in LO) is more
or less a redirection also defaulting to actually calling xdg-email anyway.


Can we close this as "user configuration error"? :)


Regards,


Rene

Bug#995957: dbconfig-common: Spews "/usr/bin/which: this version of `which' is deprecated; use `command -v' in scripts instead."

[Guilhem Moulin]

Hi elbrus!

On Sun, 10 Oct 2021 at 20:52:51 +0200, Paul Gevers wrote:
> Thanks for the report. I had committed nearly the same change locally.
> Can you elaborate why you removed some "2>&1" strings on top of that?

AFAIK with some `which` implementations one wants to silence the
standard error to avoid “foobar is not found” error messages, but per
current POSIX specs 
that's not needed for `command -v`:

  -v
Write a string to standard output that indicates the pathname or
command that will be used by the shell, in the current shell
execution environment (see Shell Execution Environment), to invoke
command_name, but do not invoke command_name.
[…]
Otherwise, no output shall be written and the exit status shall
reflect that the name was not found.

AFAICT the debianutils maintainer also suggest to use `command -v foobar
>/dev/null` as replacement for `which foobar >/dev/null [2>&1]`.  Its
5.3-1 NEWS entry reads:

  * The 'which' utility will be removed in the future.  Shell scripts
often use it to check whether a command is available.  A more
standard way to do this is with 'command -v'; for example:
  if command -v update-icon-caches >/dev/null; then
update-icon-caches /usr/share/icons/...
  fi
'2>/dev/null' is unnecessary when using 'command': POSIX says "no
output shall be written" if the command isn't found.  It's also
unnecessary for the debianutils version of 'which', and hides the
deprecation warning.

Cheers
-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#953529: Networking support in Keepassxc

[tony mancill]

On Tue, Oct 27, 2020 at 07:20:38PM -0500, Andreas Kloeckner wrote:
> So I would prefer that networking support is retained in KeepassXC, or
> if it were to be disabled, I would prefer if it were done in a separate
> package, e.g. keepassxc-nonetwork or some such.

A separate binary package would be nice, although I would prefer that
the default binary have networking disabled and users could opt-in by
installing keepassxc-netenabled (or whatever you decide to name it).

Of course, that's just my opinion.  For my systems, I always recompile
the source package with -DWITH_XC_NETWORKING=OFF.

In any event, thank you for maintaining KeePassXC.
tony


signature.asc
Description: PGP signature

Bug#841744: fail2ban: jail.conf refers to wrong man section

[Mike Gerber]

notfound 841744 0.11.2-2

fixed 841744 0.11.2-2

thanks


This is fixed in 0.11.2-2 (bullseye aka stable) - the man page is now in 
section 5.

Bug#996036: LXD: snap lxd cgroup noise causes VirtSubproc to fail

[Paul Gevers]

Hi,

On 10-10-2021 20:51, stefa...@debian.org wrote:
> The issue is that snap is warning that it doesn't completely support
> cgroup v2, yet. But it does work.
> 
> See #934372 etc.

Shouldn't that bug be raised in severity, considering the request you
are now asking from autopkgtest? I'm not really enthusiastic to add this
kind of "work around" code for a bug that's already known for 2 years.
Maybe there should be a warning in snapd to silence that warning?

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#970880: [Pkg-freeipa-devel] Bug#970880: Bug#970880: Bug#970880: Bug#970880: freeipa-server: FreeIPA server installation fails with Certificate issuance failed (CA_REJECTED)

[Timo Aaltonen]

On 10.10.2021 20.04, Spencer Olson wrote:



On Sun, Oct 10, 2021, 10:38 Timo Aaltonen > wrote:


On 10.10.2021 18.41, Spencer Olson wrote:
 > Did some more investigation.  I downloaded the packages that are
being
 > used on centos stream 8.  First I tried my test code with their
version
 > of libssl3.so preloaded:  it failed in the same way as all the
others
 > failed--not surprisingly since its version is much later than the
3.39
 > version where this changed.
 >
 > Then, I downloaded and took a look at "dogtag-submit" from the
CentOS
 > Stream 8 (RedHat) certmonger package.  As far as I can tell, their
 > version of "dogtag-submit" is *not* linked against libcurl-nss.so
at all
 > like the version on debian sid.  Instead, all their certmonger
helper
 > programs are linked against the OpenSSL version (libcurl.so.4).
 >
 > So, I think that we should just link these against the openssl
version,
 > as the RedHat packages do and get things to work again.

Hmm, thanks.. indeed certmonger is still built against
libcurl4-nss-dev,
I've changed it to openssl now and see how it goes against gitlab CI..


Maybe the CI will finish before I can get back to my testing.


And it did, this error is fixed now :)

But it fails later on, so there's some work still to catch up with the 
current distro, but at least this particular annoyance is resolved, so 
many thanks for figuring it out! I was sure the reason was something 
silly and related to the SSL stack (or maybe ciphers) but was blind to 
see it.



--
t

Bug#996036: LXD: snap lxd cgroup noise causes VirtSubproc to fail

[stefanor]

Hi Paul (2021.10.10_18:38:03_+)
> > Unfortunately executing any confined snapped binaries outputs a line on
> > stderr:
> >> WARNING: cgroup v2 is not fully supported yet, proceeding with partial 
> >> confinement
> 
> Does this happen on all suites? I thought bullseye defaults to cgroup
> v2, so it would surprise me a bit if it would be an error there.

Yes, this was happening pre-bullseye, too. (And, in fact, there were
several other issues with lxd images in bullseye that have since been
resolved, I don't know what the state is in the release.)

The issue is that snap is warning that it doesn't completely support
cgroup v2, yet. But it does work.

See #934372 etc.

SR

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