Bug#976811: [pkg-php-pear] Bug#976811: transition: php8.1

[Kunal Mehta]

Hi,

On 1/8/22 13:38, Paul Gevers wrote:

php-wmerrors [7], owfs [8].


These two need upstream update.


I see no activity and no bug reports. Can somebody please update these 
packages or file appropriate bugs?


Filed #1003432 for php-wmerrors, and am working on it upstream since 
it's more involved than I initially expected. I assume it's fine if it 
drops out of testing for a bit.


-- Kunal

Bug#1002666: [Pkg-privacy-maintainers] Bug#1002666: torbrowser-launcher: Package in Bullseye outdated and downloading Tbb fails because of bad certificate

[Roger Shimizu]

control: severity -1 important
control: tags -1 +moreinfo +unreproducible

On Mon, Dec 27, 2021 at 7:45 AM Richard Z  wrote:
>
> Package: torbrowser-launcher
> Version: 0.3.3-6
> Severity: grave
> Justification: renders package unusable
> X-Debbugs-Cc: r...@linux-m68k.org
>
> Dear Maintainer,
>
>
> the version in Bullseye seems to old, it never succeeds
> downloading the Tor Browser. I see there are newer packages
> in testing/unstable, could those be backported?

Thanks for your report!

I tried 0.3.3-6 locally, and can download latest 11.0.3 TBB without issue.
Of course I can upload a backports version, but I guess it will be the
same on your side.

Maybe you can clean up ~/.local/share/torbrowser/ folder and try again.

Cheers,
-- 
Roger Shimizu, GMT +9 Tokyo
PGP/GPG: 4096R/6C6ACD6417B3ACB1

Bug#1003439: junit5: unable to handle @CsvFileSource

[Andrius Merkys]

Package: junit5
Version: 5.3.2-4

Hello,

A package I am working on, opsin v2.6.0, has some junit5 test cases
using @CsvFileSource construction, and these fail with the following
exception:

java.lang.NoClassDefFoundError: com/univocity/parsers/csv/CsvParser
Caused by: java.lang.ClassNotFoundException:
com.univocity.parsers.csv.CsvParser

AFAIU, @CsvFileSource construction is used to parameterize tests using
CSV files [1]. The failure seems to be caused by missing CSV parser.
Installing libunivocity-parsers-java manually does not solve the issue.
My guess is that the JAR of this package is not placed in the CLASSPATH
during the execution of tests. I believe adding it to POM of
junit-jupiter-params artifact might work, but I did not try this.

It would be great if someone with more knowledge of the matter could
give it a look. To debug one may use opsin source from salsa, git commit
5c96c9fb827113ab8c526f6a52c5cff5d29543f5 from master, having
remove-tests-with-CsvParser.patch removed.

[1]
https://junit.org/junit5/docs/current/user-guide/#writing-tests-parameterized-tests-sources-CsvFileSource

Andrius

Bug#1003438: RM: why3 [alpha armel hppa ia64 m68k mipsel64el mipsel sh4 sparc64 x32] -- broken by missing coq

[Julien Puydt]

Package: ftp.debian.org
Usertags: rm
X-Debbugs-Cc: debian-ocaml-ma...@lists.debian.org

Since coq upstream abandoned some architecture, coq isn't available
anymore on those architectures, and lingering binary packages prevent
testing migration.

Apparently the coq binary packages can't be removed until reverse
dependencies have been too.

Cheers,

J.Puydt

Bug#1003437: RM: coq-float [alpha armel hppa ia64 m68k mipsel64el mipsel sh4 sparc64 x32] -- broken by missing coq

[Julien Puydt]

Package: ftp.debian.org
Usertags: rm
X-Debbugs-Cc: debian-ocaml-ma...@lists.debian.org

Since coq upstream abandoned some architecture, coq isn't available
anymore on those architectures, and lingering binary packages prevent
testing migration.

Apparently the coq binary packages can't be removed until reverse
dependencies have been too.

Cheers,

J.Puydt

Bug#1003435: RM: ssreflect [alpha armel hppa ia64 m68k mipsel64el mipsel sh4 sparc64 x32] -- broken by missing coq

[Julien Puydt]

Package: ftp.debian.org
Usertags: rm
X-Debbugs-Cc: debian-ocaml-ma...@lists.debian.org

Since coq upstream abandoned some architecture, coq isn't available
anymore on those architectures, and lingering binary packages prevent
testing migration.

Apparently the coq binary packages can't be removed until reverse
dependencies have been too.

Cheers,

J.Puydt

Bug#1003436: RM: aac-tactics [alpha armel hppa ia64 m68k mipsel64el mipsel sh4 sparc64 x32] -- broken by missing coq

[Julien Puydt]

Package: ftp.debian.org
Usertags: rm
X-Debbugs-Cc: debian-ocaml-ma...@lists.debian.org

Since coq upstream abandoned some architecture, coq isn't available
anymore on those architectures, and lingering binary packages prevent
testing migration.

Apparently the coq binary packages can't be removed until reverse
dependencies have been too.

Cheers,

J.Puydt

Bug#1003433: julia: Outdated LTS version 1.5.x, current one is 1.6.5.

[Mateusz Kaduk]

Package: julia
Version: julia
Severity: wishlist
X-Debbugs-Cc: mateusz.ka...@gmail.com

Dear Maintainer,

Current long term support version is 1.6.5, update would be nice.

Regards,
Mateusz

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

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

Versions of packages julia depends on:
pn  julia-common  
ii  libc6 2.33-2
ii  libcurl3-gnutls   7.81.0-1
pn  libdsfmt-19937-1  
ii  libgcc-s1 11.2.0-13
ii  libgfortran5  11.2.0-13
ii  libgit2-1.1   1.1.0+dfsg.1-4.1
ii  libgmp10  2:6.2.1+dfsg-3
pn  libjulia1 
pn  libllvm9  
ii  libmbedcrypto32.16.11-0.3
ii  libmbedtls12  2.16.11-0.3
ii  libmbedx509-0 2.16.11-0.3
ii  libmpfr6  4.1.0-3
pn  libopenlibm3  
ii  libpcre2-8-0  10.39-3
ii  libquadmath0  11.2.0-13
ii  libssh2-1 1.10.0-2
ii  libunwind81.3.2-2
ii  libutf8proc2  2.7.0-3

Versions of packages julia recommends:
ii  git  1:2.34.1-1
ii  openssl  1.1.1m-1

Versions of packages julia suggests:
pn  ess
pn  julia-doc  
ii  vim-julia  0.0~git20201014.a4bc8a2-1

Bug#1003434: RM: prooftree [alpha armel hppa ia64 m68k mipsel64el mipsel sh4 sparc64 x32] -- broken by missing coq

[Julien Puydt]

Package: ftp.debian.org
Usertags: rm
X-Debbugs-Cc: debian-ocaml-ma...@lists.debian.org

Since coq upstream abandoned some architecture, coq isn't available
anymore on those architectures, and lingering binary packages prevent
testing migration.

Apparently the coq binary packages can't be removed until reverse
dependencies have been too.

Cheers,

J.Puydt

Bug#1003401: RFP: libconvert-uu-perl -- Perl module for uuencode and uudecode

[Sebastiaan Couwenberg]

The modules doesn't do much more than pack() and unpack(), packaging 
such a small module may not be a good idea.


Upstream PDL issue about this dependency:

 https://github.com/PDLPorters/pdl/issues/367

Kind Regards,

Bas

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

Bug#1003432: php-wmerrors: Incompatible with PHP 8.1

[Kunal Mehta]

Package: php-wmerrors
Version: 2.0.0~git20190628.183ef7d-3
Severity: serious
Tags: ftbfs upstream
Justification: ftbfs
X-Debbugs-Cc: lego...@debian.org

wmerrors is currently incompatible with PHP 8.1.

https://phabricator.wikimedia.org/T298421 tracks this upstream and I'm
working on a patch there.


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

Kernel: Linux 5.4.156-1.fc25.qubes.x86_64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages php-wmerrors depends on:
ii  libc62.31-13+deb11u2
pn  php | php-cli
ii  php-common   2:76
ii  php7.4-cli [phpapi-20190902] 7.4.25-1+deb11u1
ii  php7.4-phpdbg [phpapi-20190902]  7.4.25-1+deb11u1

php-wmerrors recommends no packages.

php-wmerrors suggests no packages.

Bug#1003218: Processed: your mail

[Mathieu Malaterre]

Control: found -1 0.15.0-4

See:

* 
https://buildd.debian.org/status/fetch.php?pkg=highway=armhf=0.15.0-4=1641752465=0

Bug#1002681: transition: ocaml

[Stéphane Glondu]

Control: tags -1 - moreinfo

Le 09/01/2022 à 17:49, Sebastian Ramacher a écrit :
> Please remove the moreinfo tag once ocaml-odoc-parser has been accepted.

It has been yesterday.

I think this transition is ready to be started.

As usual, I will take care of binNMUs.


Cheers,

-- 
Stéphane

Bug#997440: python-libzim: FTBFS: dpkg-buildpackage: error: dpkg-source -b . subprocess returned exit status 2

[Kunal Mehta]

Hi,

Sorry, it took me a while to figure this one out.

On 10/23/21 13:27, Lucas Nussbaum wrote:


dh clean --with python3 --buildsystem=pybuild
dh_auto_clean -O--buildsystem=pybuild
I: pybuild base:232: python3.9 setup.py clean
[!] Warning: Couldn't find zim/*.h in ./include!
 Hint: You can install them from source from 
https://github.com/openzim/libzim
   or download a prebuilt release's headers into ./include/zim/*.h
   (or set CFLAGS='-I/include')
Compiling libzim/wrapper.pyx because it depends on 
/usr/lib/python3/dist-packages/Cython/Includes/libcpp/string.pxd.
[1/1] Cythonizing libzim/wrapper.pyx


This seems to be the issue, it is running Cython during the clean step, 
which dirties source tree, ironic. I codesearched and found that other 
packages modify setup.py to skip cythonize during clean and other steps, 
e.g. https://github.com/Unidata/cftime/issues/91. Will work on a patch 
for this and upstream it.


-- Kunal

Bug#1003431: ITP: go-rpmdb -- RPM DB bindings for go

[Nobuhiro Iwamatsu]

Package: wnpp
Severity: wishlist
Owner: Nobuhiro Iwamatsu 

* Package name: go-rpmdb
  Version : 0.0~git20210911.73bd0ce
  Upstream Author : Teppei Fukuda
* URL : https://github.com/knqyf263/go-rpmdb
* License : Expat
  Programming Lang: Go
  Description : RPM DB bindings for go

 go-rpmdb Library for enumerating packages in an RPM DB Packages file

Bug#768972: filezilla: wxDisplay() error

[Philip Wyett]

On Mon, 10 Nov 2014 14:47:50 +0100 rollopack  wrote:
> Package: filezilla
> Version: 3.9.0.5-1
> Severity: normal
> 
> Hi, when trying to upload/download a file and overwrite one already existing
> the following error pops up:
> 
> .../src/common/dpycmn.cpp(119): assert "n < GetCount()" failed in wxDisplay():
> An invalid index was passed to wxDisplay
> 
> 
> 
> -- System Information:
> Debian Release: jessie/sid
>   APT prefers testing
>   APT policy: (501, 'testing'), (50, 'unstable'), (1, 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 3.16-3-amd64 (SMP w/4 CPU cores)
> Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> 
> Versions of packages filezilla depends on:
> ii  filezilla-common 3.9.0.5-1
> ii  libatk1.0-0  2.14.0-1
> ii  libc62.19-12
> ii  libcairo21.14.0-2.1
> ii  libdbus-1-3  1.8.8-2
> ii  libfontconfig1   2.11.0-6.1
> ii  libfreetype6 2.5.2-2
> ii  libgcc1  1:4.9.1-19
> ii  libgdk-pixbuf2.0-0   2.31.1-2+b1
> ii  libglib2.0-0 2.42.0-2
> ii  libgnutls-deb0-283.3.8-3
> ii  libgtk2.0-0  2.24.25-1
> ii  libidn11 1.29-1
> ii  libpango-1.0-0   1.36.8-2
> ii  libpangocairo-1.0-0  1.36.8-2
> ii  libpangoft2-1.0-01.36.8-2
> ii  libsqlite3-0 3.8.7-1
> ii  libstdc++6   4.9.1-19
> ii  libtinyxml2.6.2  2.6.2-2
> ii  libwxbase3.0-0   3.0.2-1+b1
> ii  libwxgtk3.0-03.0.2-1+b1
> 
> Versions of packages filezilla recommends:
> ii  xdg-utils  1.1.0~rc1+git20111210-7.1
> 
> filezilla suggests no packages.
> 
> -- no debconf information
> 
> 

Hi,

After recently taking over as the maintainer of filezilla, I am now working 
through historic bugs.

This issue was fixed via:

https://trac.filezilla-project.org/ticket/10099 some 7 years ago.

Regards

Phil

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

WWW: https://kathenas.org

Twitter: @kathenasorg

IRC: kathenas

GPG: 724AA9B52F024C8B


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

Bug#768972: Error when lunch

[Philip Wyett]

On Wed, 7 Feb 2018 16:25:25 +0100 brambil  wrote:
> Still have the problem ...
> 
> ASSERT INFO:
> ../src/gtk/toplevel.cpp(988): assert "m_widget" failed in Show():
> invalid frame
> 
> BACKTRACE:
> [1] wxTopLevelWindowGTK::Show(bool)
> [2] wxTopLevelWindowBase::Destroy()
> [3] wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase const&,
> wxEvtHandler*, wxEvent&)
> [4] wxEventHashTable::HandleEvent(wxEvent&, wxEvtHandler*)
> [5] wxEvtHandler::TryHereOnly(wxEvent&)
> [6] wxEvtHandler::ProcessEventLocally(wxEvent&)
> [7] wxEvtHandler::ProcessEvent(wxEvent&)
> [8] wxEvtHandler::SafelyProcessEvent(wxEvent&)
> [9] wxTimerImpl::SendEvent()
> [10] g_main_context_dispatch
> [11] g_main_loop_run
> [12] gtk_main
> [13] wxGUIEventLoop::DoRun()
> [14] wxEventLoopBase::Run()
> [15] wxAppConsoleBase::MainLoop()
> [16] wxEntry(int&, wchar_t**)
> [17] __libc_start_main
> 
> Linux nicola-debian 4.14.0-3-amd64 #1
>  SMP Debian 4.14.13-1
> (2018-01-14) x86_64 GNU/Linux
> 
> 
> FileZilla Client
> 
> Version: 3.28.0
> 
> Build information:
> Compiled for: x86_64-pc-linux-gnu
> Compiled on: x86_64-pc-linux-gnu
> Build date: 2017-10-29
> Compiled with: gcc (Debian 7.2.0-12) 7.2.1 20171025
> Compiler flags: -g -O2
> -fdebug-prefix-map=/build/filezilla-uBfTzd/filezilla-3.28.0=.
> -fstack-protector-strong -Wformat -Werror=format-security -Wall
> 
> Linked against:
> wxWidgets: 3.0.3
> SQLite: 3.22.0
> GnuTLS: 3.5.17
> 
> Operating system:
> Name: Linux 4.14.0-3-amd64 x86_64
> Version: 4.14
> CPU features: sse sse2 sse3
> Settings dir: /home/nicola/.filezilla/
> 
> 
> 
> P
> Please consider the enviroment before printing.
> Pensa all'ambiente prima di stampare.

Hi,

This is not the same as the reported bug and should have been on a separate bug 
report.

However, this issue was fixed via (see upstream wxWidgets bug referred):

https://trac.filezilla-project.org/ticket/11436

Regards

Phil

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

WWW: https://kathenas.org

Twitter: @kathenasorg

IRC: kathenas

GPG: 724AA9B52F024C8B


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

Bug#995212: chromium: Update to version 94.0.4606.61 (security-fixes)

[Andres Salomon]

On 1/9/22 19:06, Andres Salomon wrote:


On 1/9/22 02:27, Andres Salomon wrote:

On 1/9/22 00:56, Andres Salomon wrote:


On 1/8/22 15:57, Mattia Rizzolo wrote:

On Thu, Jan 06, 2022 at 02:55:20AM -0500, Andres Salomon wrote:
If you want to try with chromium 97; it now builds as an official 
build, so

those DCHECKs shouldn't even be compiled in. It also supports wayland
automatically, in case that's related to your slowdowns.

https://salsa.debian.org/dilinger/chromium/-/tree/v97

I wanted to do this, but could it be that this version is for some
reason taking much more space than the previous one?  Here I have 
~40 GB

free, and v96 built just fine (though I wasn't looking when it was
running), but now this failed already twice due to ENSPC.

I'll try looking for someplace more spacy but it's odd :)



Yeah, I think it's the debugging info; it's also breaking lld. It's 
a result of enabling official build, I'm working on it.



In debian/rules, along with is_official_build=true, you can set 
symbol_level=#. With is_official_build=false (which is the way it 
used to build), it used level 0. The default for 
is_official_build=true is level 2, which results in a lot more space 
(it used 50gb on my last build) and also means I run out of ram 
linking the final chrome binary on my 8gb build machine.


I'm not sure what we should use, as I'm not sure if 0 will break any 
of the dbgsym packaging yet. I'm currently trying a build with 
symbol_level=1.


Fedora doesn't set it, and instead manually patches BUILD.gn to -g0. 
Ungoogled-chromium sets it to 1. Arch sets it to 0 if strip is set. 
Mint sets it to 0.




Here's (sid) binaries with symbol_level=0, if anyone would like to 
test them out: https://people.debian.org/~dilinger/chromium/.


Btw, https://salsa.debian.org/dilinger/chromium/-/tree/stable is my 
branch with cleaned-up commits. That's what I'll use for the NMU, which 
I'm preparing now.

Bug#934926: [Pkg-zsh-devel] Bug#934926: update (overridding of default fpath causes uncessary complexity and pain for software providing zsh completions)

[Daniel Shahaf]

Axel Beckert wrote on Sun, Jan 09, 2022 at 08:52:04 +0100:
> Daniel Shahaf wrote:
> > […], or /etc/zsh/zshrc.d/ could be added (there's a separate ticket
> > for that but my quick grep didn't find it),
> 
> You probably had https://bugs.debian.org/776663 in mind which has been
> filed against zsh-common, not zsh (but src:zsh), so I suspect you
> haven't it found because of that.
> 

Indeed.  Thanks.  (I didn't pass «--source» to querybts(1).)

> I'd though would like to see a consensus inside the Debian Zsh team on
> how (and where) to go forward. I'd especially would be happy to hear
> about Frank's (Cc'ed) opinion as he and Daniel are those who are most
> clued about upstream things and especially upstream conventions. (And
> because I know that Frank has a quite clear opinion on #776663 — where
> I actually do have an opinion, too, albeit a different one than Frank.)

Well, if I were designing things from scratch, I'd probably go for
having packages in Debian install to /usr/share/zsh/foo whatever their
upstreams install by default to /usr/local/share/zsh/foo.  That'd be
exactly analogous to Debian's semantics of /usr/bin v. /usr/local/bin
("owned by packages" v. "owned by the local sysadmin") and would result
in short, readable package build scripts (basically just the equivalent
of «./configure --prefix=/usr»).

However, /usr/share/zsh/vendor-* exist, and I see no reason to break
working code.  I suppose we could deprecate these two dirs but not
actually drop support for them before zsh 6.0.  In lintian terms,
I suppose that means a ≤info lintian check for zsh 5.x and a ≥warning
lintian check for zsh 6.x.

And for upstreams… well, that's a discussion I'd rather have upstream.

Cheers,

Daniel

Bug#1003430: gkrellm-leds: reproducible-builds: /bin/sh dependent behavior in Makefile

[Vagrant Cascadian]

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

The path that gkrellm-leds installs plugins into differs depending on
weather /bin/sh points to bash or dash:

  
https://tests.reproducible-builds.org/debian/rb-pkg/bookworm/amd64/gkrellm-leds.html

In the md5sums file you have two different files included in the package:

  usr/lib/gkrellm2/plugins/gkleds.so
vs.
  
build/gkrellm-leds-0.8.0/debian/.debhelper/generated/_source/home/.gkrellm2/plugins/gkleds.so


The attached patch fixes this by removing the UID check in the Makefile,
which only behaves "correctly" when run under bash (when run under dash
$UID is unset).

Since the .deb package should always install into
/usr/lib/gkrellm2/plugins, regardless of the running UID, removing the
check seems appropriate, especially as "Rules-Requires-Root: no" is set
in debian/control.


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


Thanks for maintaining gkrellm-leds!


live well,
  vagrant
From 6c248d3351d4b2707b3022a4af3010910a77fb50 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Mon, 10 Jan 2022 03:44:11 +
Subject: [PATCH] Makefile: Disable broken UID check.

The UID check works when /bin/sh is bash, but not when /bin/sh is
dash.

This results in broken builds when /bin/sh is bash and built as
non-root, as gkleds.so and other files are installed to
BUILDPATH/debian/.debhelper/generated/_source/home/.gkrellm2/plugins/
instead of /usr/lib/gkrellm2/plugins/.

Ensure the package consistently installs into
/usr/lib/gkrellm2/plugins regardless of the operating UID or which
shell is configured as /bin/sh.
---
 Makefile | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/Makefile b/Makefile
index f988986..fd09b5e 100644
--- a/Makefile
+++ b/Makefile
@@ -46,9 +46,7 @@ clean:
 	rm -rf src/*~ src/\#*
 
 install : gkleds.so
-	@ if [ "$$UID" -ne 0 ]; \
-		then PLUGIN_DIR=$$HOME/.gkrellm2/plugins; \
-	elif [ -e /usr/bin/gkrellm ]; \
+	@ if [ -e /usr/bin/gkrellm ]; \
 		then PLUGIN_DIR=/usr/lib/gkrellm2/plugins; \
 	else \
 		PLUGIN_DIR=/usr/local/lib/gkrellm2/plugins; \
-- 
2.30.2



signature.asc
Description: PGP signature

Bug#1002936: lintian: False positive missing-pkg-php-tools-addon when using dh-sequence-phpcomposer

[Felix Lechner]

Hi Robin,

On Sat, Jan 1, 2022 at 7:39 AM Robin Gustafsson  wrote:
>
> Using it

Which package are you working on, please? It's probably one of the 56
sources that trigger the tag:

https://lintian.debian.org/tags/missing-pkg-php-tools-addon

We cannot investigate your report without that information. Thank you!

Kind regards
Felix Lechner

Bug#1003429: ruby-build: Package out of date

[Perry Naseck]

Package: ruby-build
Version: 20200401-1
Severity: important

Dear Maintainer,

The currently provided version of ruby-build is 20200401, but the latest 
upstream is 20211227. The versions since bring support for some key updates 
including:

 - Newer OpenSSL patches (for 1.0.2, 1.1.0, and 1.1.1)
 - Ruby 2.5.9
 - Ruby 2.6.7, 2.6.8, 2.6.9
 - Ruby 2.7.2, 2.7.3, 2.7.4, 2.7.5
 - Ruby 3.0.0, 3.0.1, 3.0.2, 3.0.3
 - Ruby 3.1.0

Please consider updating the package soon.

Thanks!

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

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

Versions of packages ruby-build depends on:
pn  build-essential   
ii  curl  7.74.0-1.3+deb11u1
pn  libreadline6-dev  
pn  zlib1g-dev

Versions of packages ruby-build recommends:
pn  libsqlite3-dev  
pn  libssl-dev  
pn  libxml2-dev 
pn  libxslt-dev 
pn  rbenv   

Versions of packages ruby-build suggests:
pn  autoconf
pn  automake
pn  bison   
ii  git [git-core]  1:2.30.2-1
pn  libtool 

Bug#1003405: misses dependency on python3-pmw

[Stuart Prescott]

Control: severity -1 wishlist
Control: retitle -1 consider devendoring pmw module

The bkchem package is functional without a separate python3-pmw package as it 
is carrying its own vendored version of pmw:

$ dpkg -L bkchem|grep -i pmw 
/usr/share/bkchem/bkchem/Pmw.py 
/usr/share/bkchem/bkchem/PmwBlt.py 
/usr/share/bkchem/bkchem/PmwColor.py

Bundling pmw into the application is one of the intended modes of use of this 
module, with the pmw sources including a "bundlepmw.py" script that generates 
the files included in bkchem.

For bkchem we can then either:

1. carefully check through the quite large divergence between pmw upstream and
 bkchem's vendored version of pmw (some 41 commits in bkchem git)
2. package python3-pmw
3. wait for it to go through NEW
4. devendor pmw (note that is not just a matter of deleting the files)
5. depend on the python3-pmw package instead

or

1. do nothing to bkchem. (that doesn't preclude updating python3-pmw for 
#886617 anyway, just that bkchem wouldn't use it)


There is one other potential user of a python3-pmw package in Debian and that 
is the auto-07p package. Like bkchem, the auto-07p git history shows  
modification of the bundled pmw making devendoring hard.

regards
Stuart

-- 
Stuart Prescotthttp://www.nanonanonano.net/   stu...@nanonanonano.net
Debian Developer   http://www.debian.org/ stu...@debian.org
GPG fingerprint90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7

Bug#1003427: COMPRESS=zstd and COMPRESS=lz4 hard-coded to bad COMPRESSLEVELs

[Ben Hutchings]

On Mon, 2022-01-10 at 11:04 +1100, Trent W. Buck wrote:
> Package: initramfs-tools
> Version: 0.140
> Severity: wishlist
> 
> This is a vote for 
> https://salsa.debian.org/kernel-team/initramfs-tools/-/merge_requests/52
> I did this investigation 2 months ago, but AFAICT I forgot to push it to 
> bugs.debian.org.
> https://github.com/cyberitsolutions/bootstrap2020/blob/main/doc/N-ramdisk-compression.rst
> 
> Are pigz and xz *REALLY* the best choices for rd compression?
> Surely lz4 and zstd are better tradeoffs?
[...]

You'll be pleased to hear that in master, zstd with compression level 9
is now the default.  The -T0 option is still unconditional though...

I have no idea whether the lz4 options should be changed.  I'm not sure
it's actually a good choice for anyone.

Ben.

-- 
Ben Hutchings
I say we take off; nuke the site from orbit.
It's the only way to be sure.


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

Bug#1003427: COMPRESS=zstd and COMPRESS=lz4 hard-coded to bad COMPRESSLEVELs

[Trent W. Buck]

Ben Hutchings wrote:
> On Mon, 2022-01-10 at 11:04 +1100, Trent W. Buck wrote:
> > Package: initramfs-tools
> > Version: 0.140
> > Severity: wishlist
> > 
> > This is a vote for 
> > https://salsa.debian.org/kernel-team/initramfs-tools/-/merge_requests/52
> > I did this investigation 2 months ago, but AFAICT I forgot to push it to 
> > bugs.debian.org.
> > https://github.com/cyberitsolutions/bootstrap2020/blob/main/doc/N-ramdisk-compression.rst
> > 
> > Are pigz and xz *REALLY* the best choices for rd compression?
> > Surely lz4 and zstd are better tradeoffs?
> [...]
> 
> You'll be pleased to hear that in master, zstd with compression level 9
> is now the default.  The -T0 option is still unconditional though...
> 
> I have no idea whether the lz4 options should be changed.  I'm not sure
> it's actually a good choice for anyone.

FTR my two use cases are:

  1. Build a test Debian Live image and run qemu on it, just once.
 Build should be quick and ideally not make my laptop heat up.
 Output size doesn't matter at all.

  2. Build a prod Debian Live image and then upload it to a server
 where 1000 desktops will netboot it daily.

I'm using tar2squashfs --comp=lz4 for case #1, so
using lz4 at other layers was intuitive.

Based on the actual measurements, however, I think pigz is a better
bet than lz4 unless/until lz4 gets a -T0 option. ;-)

Bug#886617: Please package version 2.1

[Greg McFarlane]

Hi Daniel,

As the original maintainer of Pmw (over 20 years ago!) I would be very
happy if you updated Pmw to version 2.1.

Regards,

Greg (old email: gr...@iname.com)

On Mon, Jan 10, 2022 at 4:09 AM Daniel Leidert  wrote:

> unblock 886617 by 936212
> block  936212 by 886617
> block 1003405 by 886617
> retitle 886617 python-pmw: Please package version 2.1 and include Python 3
> support
> thanks
>
> Hi,
>
> there is finally a bkchem version ported to python 3 and it has already
> been
> packaged. However, it requires the update pf pmw to version 2.1
> (https://pypi.org/project/Pmw-py3/).
>
> This would close a lot of open bug reports, and maybe even allow the final
> removal of python2.
>
> Should we prepare an NMU?
>
> Regards, Daniel
> --
> Regards,
> Daniel Leidert  | https://www.wgdd.de/
> GPG-Key RSA4096 / BEED4DED5544A4C03E283DC74BCD0567C296D05D
> GPG-Key ED25519 / BD3C132D8B3805D1808123AB7ACE00941E338C78
>
> https://www.fiverr.com/dleidert
> https://www.patreon.com/join/dleidert
>

Bug#1003427: Acknowledgement (COMPRESS=zstd and COMPRESS=lz4 hard-coded to bad COMPRESSLEVELs)

[Trent W. Buck]

PS: my previous email speculated: does zstd -T0 break SOURCE_DATE_EPOCH?
I think this test shows that zstd -T0 is safe even when SOURCE_DATE_EPOCH=1.
i.e. it does not need the equivalent of mkinitramfs's workaround for xz and 
gzip.

bash5$ ls -hl
total 1.1G
-rw-r--r-- 1 twb twb 1.1G 2022-01-10 11:06 linux_5.15.5.orig.tar

bash5$ zstd --keep --fast --verbose --threads=0 linux_5.15.5.orig.tar
*** zstd command line interface 64-bits v1.4.8, by Yann Collet ***
Note: 4 physical core(s) detected
linux_5.15.5.orig.tar : 21.38%   (1136691200 => 243006203 bytes, 
linux_5.15.5.orig.tar.zst)

bash5$ ls
linux_5.15.5.orig.tar  linux_5.15.5.orig.tar.zst

bash5$ mv linux_5.15.5.orig.tar.zst linux_5.15.5.orig.tar.zst.~1~

bash5$ zstd --keep --fast --verbose --threads=0 linux_5.15.5.orig.tar
*** zstd command line interface 64-bits v1.4.8, by Yann Collet ***
Note: 4 physical core(s) detected
linux_5.15.5.orig.tar : 21.38%   (1136691200 => 243006203 bytes, 
linux_5.15.5.orig.tar.zst)

bash5$ mv linux_5.15.5.orig.tar.zst linux_5.15.5.orig.tar.zst.~2~

bash5$ b2sum *~

570c5509c9c95dabb655be223f70d48182ee547da3df43696139f00969e3eeb51b4f0a5bab9ca3e905ba3e52fbebb6892ee643e246522198b764143228e81437
  linux_5.15.5.orig.tar.zst.~1~

570c5509c9c95dabb655be223f70d48182ee547da3df43696139f00969e3eeb51b4f0a5bab9ca3e905ba3e52fbebb6892ee643e246522198b764143228e81437
  linux_5.15.5.orig.tar.zst.~2~

bash5$ SOURCE_DATE_EPOCH=1 zstd --keep --verbose --threads=0 
linux_5.15.5.orig.tar
*** zstd command line interface 64-bits v1.4.8, by Yann Collet ***
Note: 4 physical core(s) detected
linux_5.15.5.orig.tar : 16.29%   (1136691200 => 185188738 bytes, 
linux_5.15.5.orig.tar.zst)

bash5$ ls -lh
total 1.7G
-rw-r--r-- 1 twb twb 1.1G 2022-01-10 11:06 linux_5.15.5.orig.tar
-rw-r--r-- 1 twb twb 177M 2022-01-10 11:06 linux_5.15.5.orig.tar.zst
-rw-r--r-- 1 twb twb 232M 2022-01-10 11:06 linux_5.15.5.orig.tar.zst.~1~
-rw-r--r-- 1 twb twb 232M 2022-01-10 11:06 linux_5.15.5.orig.tar.zst.~2~

bash5$ mv linux_5.15.5.orig.tar.zst linux_5.15.5.orig.tar.zst.~1~

bash5$ SOURCE_DATE_EPOCH=1 zstd --keep --verbose --threads=0 
linux_5.15.5.orig.tar
*** zstd command line interface 64-bits v1.4.8, by Yann Collet ***
Note: 4 physical core(s) detected
linux_5.15.5.orig.tar : 16.29%   (1136691200 => 185188738 bytes, 
linux_5.15.5.orig.tar.zst)

bash5$ mv linux_5.15.5.orig.tar.zst linux_5.15.5.orig.tar.zst.~2~

bash5$ b2sum *~

7edc85faf5c53c62d2a7b13f58100f2795aee109092bbf728c763d1945c84797cb71a4ae32f1cfd53fdaea959120dbbe6eea47fcdb4ee67a5e71faea7e1a122a
  linux_5.15.5.orig.tar.zst.~1~

7edc85faf5c53c62d2a7b13f58100f2795aee109092bbf728c763d1945c84797cb71a4ae32f1cfd53fdaea959120dbbe6eea47fcdb4ee67a5e71faea7e1a122a
  linux_5.15.5.orig.tar.zst.~2~

Bug#995212: chromium: Update to version 94.0.4606.61 (security-fixes)

[Andres Salomon]

On 1/9/22 02:27, Andres Salomon wrote:

On 1/9/22 00:56, Andres Salomon wrote:


On 1/8/22 15:57, Mattia Rizzolo wrote:

On Thu, Jan 06, 2022 at 02:55:20AM -0500, Andres Salomon wrote:
If you want to try with chromium 97; it now builds as an official 
build, so

those DCHECKs shouldn't even be compiled in. It also supports wayland
automatically, in case that's related to your slowdowns.

https://salsa.debian.org/dilinger/chromium/-/tree/v97

I wanted to do this, but could it be that this version is for some
reason taking much more space than the previous one?  Here I have 
~40 GB

free, and v96 built just fine (though I wasn't looking when it was
running), but now this failed already twice due to ENSPC.

I'll try looking for someplace more spacy but it's odd :)



Yeah, I think it's the debugging info; it's also breaking lld. It's a 
result of enabling official build, I'm working on it.



In debian/rules, along with is_official_build=true, you can set 
symbol_level=#. With is_official_build=false (which is the way it used 
to build), it used level 0. The default for is_official_build=true is 
level 2, which results in a lot more space (it used 50gb on my last 
build) and also means I run out of ram linking the final chrome binary 
on my 8gb build machine.


I'm not sure what we should use, as I'm not sure if 0 will break any 
of the dbgsym packaging yet. I'm currently trying a build with 
symbol_level=1.


Fedora doesn't set it, and instead manually patches BUILD.gn to -g0. 
Ungoogled-chromium sets it to 1. Arch sets it to 0 if strip is set. 
Mint sets it to 0.




Here's (sid) binaries with symbol_level=0, if anyone would like to test 
them out: https://people.debian.org/~dilinger/chromium/.

Bug#1003427: COMPRESS=zstd and COMPRESS=lz4 hard-coded to bad COMPRESSLEVELs

[Trent W. Buck]

Package: initramfs-tools
Version: 0.140
Severity: wishlist

This is a vote for 
https://salsa.debian.org/kernel-team/initramfs-tools/-/merge_requests/52
I did this investigation 2 months ago, but AFAICT I forgot to push it to 
bugs.debian.org.
https://github.com/cyberitsolutions/bootstrap2020/blob/main/doc/N-ramdisk-compression.rst

Are pigz and xz *REALLY* the best choices for rd compression?
Surely lz4 and zstd are better tradeoffs?

Looking at [a Debian Live chroot]::

# apt install pixz pigz zstd lz4 xz-utils firmware-misc-nonfree
# for i in lz4 gzip xz zstd;
  do
  echo === $i === &&
  echo COMPRESS=$i >/etc/initramfs-tools/conf.d/test &&
  time update-initramfs -u -k all &&
  ls -hl /boot/initrd.img-5.14.0-0.bpo.2-amd64;
  done

COMPRESSrealusersys size
lz4 0m10.125s   0m9.263s0m1.242s55M
gzip0m5.724s0m11.860s   0m1.123s47M(really 
pigz)
xz  0m18.556s   1m15.392s   0m1.307s32M
zstd0m25.993s   1m20.542s   0m1.237s35M

So:

•   pigz greatly beats lz4 for wall-clock time.
pigz beats lz4 for size.
lz4 slightly beats pigz for CPU time (meh).

pigz is the best choice for --optimize=speed.

•   xz slightly beats zstd for size.
xz beats zstd for wall-clock time.
xz slightly beats zstd for CPU time (meh).

xz is the best choice for --optimize=size.

BUT /usr/sbin/mkinitramfs makes these UNFAIR COMPARISONS.
It uses the HIGHEST compression level for lz4 and zstd, but
the DEFAULT (best tradeoff) compression for gzip and xz. ::

case "${compress}" in
gzip)   # If we're doing a reproducible build, use gzip -n
if [ -n "${SOURCE_DATE_EPOCH}" ]; then
compress="gzip -n"
# Otherwise, substitute pigz if it's available
elif command -v pigz >/dev/null; then
compress=pigz
fi
;;
lz4)compress="lz4 -9 -l" ;;
zstd)   compress="zstd -q -19 -T0" ;;
xz) compress="xz --check=crc32"
# If we're not doing a reproducible build, enable multithreading
test -z "${SOURCE_DATE_EPOCH}" && compress="$compress --threads=0"
;;
bzip2|lzma|lzop)
# no parameters needed
;;
*)  echo "W: Unknown compression command ${compress}" >&2 ;;
esac

Just for my peace of mind, let's re-test this with the -9 and -19 removed::

# sed -rsi /usr/sbin/mkinitramfs -e 's/ -19 / /' -e 's/ -9 / /'
# apt install pixz pigz zstd lz4 xz-utils firmware-misc-nonfree
# for i in lz4 gzip xz zstd;
  do
  echo === $i === &&
  echo COMPRESS=$i >/etc/initramfs-tools/conf.d/test &&
  time update-initramfs -u -k all &&
  ls -hl /boot/initrd.img-5.14.0-0.bpo.2-amd64;
  done


COMPRESSrealusersys size
lz4 0m5.070s0m4.207s0m1.209s67M
gzip0m5.572s0m11.308s   0m1.197s47M(really 
pigz)
xz  0m18.646s   1m14.563s   0m1.204s32M
zstd0m5.159s0m5.334s0m1.137s43M

So:

•   When lz4 isn't forced into a bad time/size tradeoff,
it's as fast as pigz, but much bigger.  Fail.

•   When zstd isn't forced into a bad time/size tradeoff,
it's a little smaller than pigz,
it's as fast as pigz, and
it's MUCH faster than xz.

Clear win.

It seems to me that the following changes should be made:

•   Don't pass -19 to zstd.
•   Don't pass -T0 to zstd when [ -n $SOURCE_DATE_EPOCH ] (same as other -T0 
cases).
•   Encourage people to switch to zstd? ;-)




-- Package-specific info:
-- initramfs sizes
-rw-r--r-- 1 root root 53M 2021-11-19 09:17 
/boot/initrd.img-5.14.0-0.bpo.2-amd64
-- /proc/cmdline
root=ZFS=hera/hera quiet splash noresume initrd=\initrd.img-5.14.0-0.bpo.2-amd64

-- /proc/filesystems
fuseblk
ext3
ext2
ext4
vfat

-- lsmod
Module  Size  Used by
ccm20480  6
rfcomm 90112  0
cmac   16384  7
algif_hash 16384  3
algif_skcipher 16384  3
af_alg 32768  14 algif_hash,algif_skcipher
bnep   28672  2
binfmt_misc24576  1
intel_pmc_core_pltdrv16384  0
intel_pmc_core 45056  0
snd_sof_pci_intel_cnl16384  0
snd_sof_intel_hda_common   106496  1 snd_sof_pci_intel_cnl
x86_pkg_temp_thermal20480  0
soundwire_intel45056  1 snd_sof_intel_hda_common
intel_powerclamp   20480  0
coretemp   20480  0
soundwire_generic_allocation16384  1 soundwire_intel
soundwire_cadence  36864  1 soundwire_intel
snd_sof_intel_hda  20480  1 snd_sof_intel_hda_common
kvm_intel 323584  0
snd_sof_pci20480  2 

Bug#1003426: glances: Provide this package in bullseye-backports?

[Boyuan Yang]

Source: glances
Version: 3.2.4.2+dfsg-1
Severity: normal
X-Debbugs-CC: epsi...@debian.org sba...@debian.org

Dear Debian glances package maintainers,

According to https://tracker.debian.org/pkg/glances , package glances is
currently missing in Debian 11 (bullseye). I have personally received some
user requests to backport this package onto bullseye-backports. Just took a
quick glance, and it seems that backporting is doable.

Now I am wondering if there are any important factors that would block backage
backporting. Otherwise I can make a backports upload and reflect related
changes on https://salsa.debian.org/debian/glances . Please let me know if
there are any issues.

Thanks!
Boyuan Yang


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

Bug#1003425: ITP: golang-k8s-sigs-json -- Golang JSON decoder library for kubernetes sig-api-machinery

[Nobuhiro Iwamatsu]

Package: wnpp
Severity: wishlist
Owner: Nobuhiro Iwamatsu 

* Package name: golang-k8s-sigs-json
  Version : 0.0~git20211208.9f7c6b3-1
  Upstream Author : Kubernetes SIGs
* URL : https://github.com/kubernetes-sigs/json
* License : Apache-2.0, Go
  Programming Lang: Go
  Description : Golang JSON decoder library for kubernetes sig-api-machinery
 
 This library is a subproject of sig-api-machinery
 (https://github.com/kubernetes/community/tree/master/sig-api-
 machinery#json). This provides case-sensitive, integer-preserving JSON
 unmarshaling functions based on encoding/json Unmarshal().

Bug#1002372: marked as done (nbconvert: FTBFS: AttributeError: module 'mistune' has no attribute 'BlockGrammar')

[Sandro Tosi]

> I _think_ the closed bugs (#1001283 was merged with 6 others) only cover
> the cases where the FTBFS tracebacks showed nbconvert (rather than
> direct import of mistune).

you're right, i've mis-read them -- thanks for checking!

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

Bug#1003424: halide13-api-doc: missing Breaks+Replaces: libhalide13-doc (<< 13.0.3)

[Andreas Beckmann]

Package: halide13-api-doc
Version: 13.0.3-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'testing'.
It installed fine in 'testing', then the upgrade to 'sid' fails
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.

See policy 7.6 at
https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces

>From the attached log (scroll to the bottom...):

  Preparing to unpack .../halide13-api-doc_13.0.3-1_all.deb ...
  Unpacking halide13-api-doc (13.0.3-1) ...
  dpkg: error processing archive 
/var/cache/apt/archives/halide13-api-doc_13.0.3-1_all.deb (--unpack):
   trying to overwrite '/usr/share/doc/halide13/html/_a_s_log_8h.html', which 
is also in package libhalide13-doc 13.0.2-2
  dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
  Errors were encountered while processing:
   /var/cache/apt/archives/halide13-api-doc_13.0.3-1_all.deb


cheers,

Andreas


libhalide13-doc=13.0.2-2_halide13-api-doc=13.0.3-1.log.gz
Description: application/gzip

Bug#1003342: libc6: NIS client not working after update to libc6:amd64 2.33-1

[Aurelien Jarno]

Hi,

On 2022-01-08 17:15, Nuno Oliveira wrote:
> Package: libc6
> Version: 2.33-1
> Severity: normal
> 
> Hi,
> 
> After the update of libc6 2.32-5 -> 2.33-1, NIS users are not recognized 
> by the system anymore. The NIS setup was working OK before this upgrade, 
> which just included (according to aptitude):
> 
> REMOVE (PURGE)] libjson-c4:amd64 0.13.1+dfsg-9
> [UPGRADE] glibc-doc:amd64 2.32-5 -> 2.33-1
> [UPGRADE] glibc-doc-reference:amd64 2.32-1 -> 2.33-1
> [UPGRADE] libc-bin:amd64 2.32-5 -> 2.33-1
> [UPGRADE] libc-dev-bin:amd64 2.32-5 -> 2.33-1
> [UPGRADE] libc-l10n:amd64 2.32-5 -> 2.33-1
> [UPGRADE] libc6:amd64 2.32-5 -> 2.33-1
> [UPGRADE] libc6-dbg:amd64 2.32-5 -> 2.33-1
> [UPGRADE] libc6-dev:amd64 2.32-5 -> 2.33-1
> [UPGRADE] libc6-dev-i386:amd64 2.32-5 -> 2.33-1
> [UPGRADE] libc6-dev-x32:amd64 2.32-5 -> 2.33-1
> [UPGRADE] libc6-i386:amd64 2.32-5 -> 2.33-1
> [UPGRADE] libc6-x32:amd64 2.32-5 -> 2.33-1
> [UPGRADE] locales:amd64 2.32-5 -> 2.33-1
> [UPGRADE] nscd:amd64 2.32-5 -> 2.33-1
> ==
> 
> "ypcat passwd" works fine, as before. "finger username" does not work. 
> The system has libnss-nis and libnss-nisplus previously installed. The 
> usual usual instructions in /usr/share/doc/nis/nis.debian.howto.gz were 
> verified and they are still implemented as suggested (no changes). This 
> happens on multiple client systems, where the behavior seems to be 
> reproducible. "ypwhich" works normally.
> 
> Doing a "strace finger username" and checking the differences between a 
> working system (still libc6 2.32-5) and a nonworking system (with libc6 
> 2.33-1):
> 
> In the old system, after
> 
>   openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libnss_compat.so.2", 
> O_RDONLY|O_CLOEXEC) = 3
>   ...
>   close(3)
> 
> there is a call to
> 
>   openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
>   ...
>   close(3)= 0
>   openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libnss_nis.so.2", 
> O_RDONLY|O_CLOEXEC) = 3
>   ...
>   close(3)
> 
> In the updated system (libc6 2.32-5), after the call to 

I guess you mean 2.33-1 here.

> libnss_compat.so.2, there is no following call to libnss_nis.so.2 or 
> /etc/ld.so.cache, although /lib/x86_64-linux-gnu/libnss_nis.so.2 exists, 
> and points to libnss_nis.so.2.0.0.

Thanks for the detail analysis. I can confirm the same issue. It has
been fixed by this upstream commit:

https://sourceware.org/git/?p=glibc.git;a=commit;h=9b456c5da968ee832ea4b2b73a18a5bf6d2118a6

Unfortunately, due to symbols changes, it is not backportable to glibc
2.33 easily without potentially breaking other NSS modules during
upgrade.

On the other hand, the problem is already fixed in glibc 2.34 (currently
in experimental), so the easiest fix might be to get glibc 2.34 ready to
be uploaded to unstable.

Regards,
Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net

Bug#976811: [pkg-php-pear] Bug#976811: Bug#976811: transition: php8.1

[David Prévot]

Hi,

Le 09/01/2022 à 14:37, Paul Gevers a écrit :
[…]

On 08-01-2022 23:09, David Prévot wrote:

[…]

PHPUnit requires the "dom" extension.
"""
where should that get fixed?


There are several php7.4-* packages pulled in those logs, so it’s not 
really a surprise that doesn’t end well (php-xml 2:7.4+76 is probably 
not the expected version either).


Normally this points to an issue with the right versioned Depends or 
versioned Breaks.


I was actually trying to point an issue in the test environment (but let 
me try in verbose mode).


This is important because some of these packages are 
currently allowed to migrate to testing without php-defaults (were it 
not for the autopgktest failure), and would break functionality in 
testing. We need to find out how to fix that.


I assume you pointed to logs in testing where php-defaults is pulled 
from unstable. Actually, php-defaults (source package, version 91, from 
unstable) builds php-xml (binary package, version 2:8.1+91) that 
correctly depends on php8.1-xml. According to the log (and that’s not a 
surprise given the error message you pointed out), the php-xml version 
actually installed in the autopkgtest environment is 2:7.4+76 (i.e. the 
version from testing, built from php-defaults 76). My question is: how 
is that possible? If the autopkgtest environment is supposed to pull 
(the binary packages built by) php-defaults, it looks like this failed.


Regards

David


OpenPGP_signature
Description: OpenPGP digital signature

Bug#969264: Warning message still present in Bullseye 11.2

[Frode Severin Hatlevik]

I just updated my Debian amd64 system from Buster to Bullseye as per
https://www.debian.org/releases/bullseye/amd64/release-notes/ch-upgrading.en.html
I have to admit I cut some corners and enabled backports and Fast Track and
did the update in one go.

All went well, short of the error discussed in this bug appearing at the
boot console
[   20.208399] iwlwifi :02:00.0: firmware: failed to load
iwl-debug-yoyo.bin (-2)
[   20.208429] firmware_class: See https://wiki.debian.org/Firmware for
information about missing firmware

This is problematic in three ways
1. The debug firmware is not supplied nor needed for daily usage
2. The Wiki page referenced (https://wiki.debian.org/Firmware) does not
provide any pointers to useful information
3. The section about intel-microcode in Chapter 5
https://www.debian.org/releases/bullseye/amd64/release-notes/ch-information.en.html#intel-microcode
mentions possible problems with firmware-iwlwifi for Bullseye

Blacklisting the module has been suggested earlier in this bugreport, but
it has not been reached my system as of yet.

Unexperienced Linux users can easily be putt off by such errormesages.
Is there a fix for this planned soon?

;)Frode

-- 
Da sa Gud: "Det bli lys!"
Og det ble lys.
  1. Mosebok 1.3

And God said, "Let there be light,"
and there was light.
  Genesis 1:3, NIV

Bug#1002997: podman: Please provide a default /etc/containers/storage.conf

[Reinhard Tartler]

Control: reassign -1 storage-common
Control: affects -1 podman

Hi Philip,

Thank you for your bug report.

The Debian equivalent to Fedora's package 'containers-common' has the same
name in debian, and does ship a 'storage.conf' file in
/usr/share/containers/storage.conf. This is so that the local administrator
can copy it to /etc/containers/storage.conf and do local modifications. The
Debian package copies the storage.conf from the upstream source verbatim.
As you can see at
https://github.com/containers/storage/blob/375f77c66685b14fc580daad2dc6df607fb86dee/storage.conf#L95,
the mount option 'metacopy=on' is missing even upstream.

I am not sure why the Fedora package decided to patch the configuration
file -- I couldn't find a comment in the .src.rpm that you linked. Also,
looking at the kernel documentation you provided, it seems your concerns
re: security are justified, and the option seems to have significant
security implications:

Do not use metacopy=on with untrusted upper/lower directories. Otherwise it
> is possible that an attacker can create a handcrafted file with appropriate
> REDIRECT and METACOPY xattrs, and gain access to file on lower pointed by
> REDIRECT. This should not be possible on local system as setting “trusted.”
> xattrs will require CAP_SYS_ADMIN. But it should be possible for untrusted
> layers like from a pen drive.


I'm not sure whether enabling it by default is a good idea. I need to think
more about this.

I'd also appreciate hearing additional opinions on this, and have copied
some friends from podman upstream. Do you happen to know what's the
background / thinking in Fedora with enabling the option metacopy=on?

Happy New Year!

-rt


On Sun, Jan 2, 2022 at 9:51 AM Philip  wrote:

> Package: podman
> Version: 3.0.1+dfsg1-3+b2
> Severity: wishlist
>
> Dear Maintainer,
>
> I had some problems running the dockerized version of the Unifi controller
> jacobalberty/unifi-docker
> with podman on Debian.
> On a Fedora system, starting the container only takes a few seconds.
> On a Debian system, it can take about 5 minutes.
>
> The reason is that on the Fedora system the mount-option metacopy=on
> (see  [1] for this mount option) is set for the container overlayfs via a
> default /etc/containers/storage.conf.
> That makes quite the difference for this specific image because it does a
> `chown unifi:unifi /usr/lib/unifi` during startup.
> chown-ing these 6k files is fast with metacopy=on (on Fedora).
> Without the option (on Debian), I think the files will be copied instead
> of only their metadata, making it rather slow.
>
> So the solution for me was to copy /etc/containers/storage.conf from a
> Fedora system. If anyone has a similar problem, the file can be extracted
> from the
> src rpm of the containers-common package which can be downloaded at [2].
>
> IMO it would be useful if Debian would also include a default
> /etc/containers/storage.conf.
> Thanks for considering this!
> However I'm not sure if metacopy=on is a good idea from a security
> perspective.
>
> Best
> Philip
>
> -- System Information:
> Debian Release: 11.2
>   APT prefers stable-updates
>   APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500,
> 'stable')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 5.10.0-10-amd64 (SMP w/2 CPU threads)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
> LANGUAGE=en_US:en
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> Versions of packages podman depends on:
> ii  conmon   2.0.25+ds1-1.1
> ii  containernetworking-plugins  0.9.0-1+b6
> ii  crun 0.17+dfsg-1
> ii  golang-github-containers-common  0.33.4+ds1-1
> ii  init-system-helpers  1.60
> ii  iptables 1.8.7-1
> ii  libc62.31-13+deb11u2
> ii  libdevmapper1.02.1   2:1.02.175-2.1
> ii  libgpgme11   1.14.0-1+b2
> ii  libseccomp2  2.5.1-1+deb11u1
>
> Versions of packages podman recommends:
> ii  buildah   1.19.6+dfsg1-1+b6
> ii  catatonit 0.1.5-2
> ii  fuse-overlayfs1.4.0-1
> ii  golang-github-containernetworking-plugin-dnsname  1.1.1+ds1-4+b7
> ii  slirp4netns   1.0.1-2
> ii  uidmap1:4.8.1-1
>
> Versions of packages podman suggests:
> pn  containers-storage  
> pn  docker-compose  
>
> -- no debconf information
>
>
> [1]:
> https://www.kernel.org/doc/html/latest/filesystems/overlayfs.html#metadata-only-copy-up
> [2]:
> https://kojipkgs.fedoraproject.org//packages/containers-common/1/32.fc35/src/containers-common-1-32.fc35.src.rpm
>
>

-- 
regards,
Reinhard

Bug#1003419: ITP: primecount -- fast prime number counter C/C++ library

[Jerome Benoit]

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

* Package name: primecount
  Version : 7.2
  Upstream Author : Kim Walisch 
* URL : https://github.com/kimwalisch/primecount
* License : BSD-2-clause
  Programming Lang: C/C++
  Description : fast prime number counter C/C++ library

primecount is a command-line program and C/C++ library that counts
the primes below an integer x <= 10**31 using highly optimized
implementations of the combinatorial prime counting algorithms.

primecount includes implementations of all important combinatorial
prime counting algorithms known up to this date all of which have
been parallelized using OpenMP. primecount contains the first ever
open source implementations of the Deleglise-Rivat algorithm and
Xavier Gourdon's algorithm (that works). primecount also features
a novel load balancer that is shared amongst all implementations
and that scales up to hundreds of CPU cores. primecount has already
been used to compute several prime counting function world records.

primecount will be part of sagemath.

I am planning to maintain primecount in behalf of the
Debian Math Team. Notice that I am actually maintaining
a related package by the same author, primesieve.

Bug#999610: firefox-esr: Protocol handlers from desktop files are not recognized without additional package desktop-file-utils

[Marten van Kerkwijk]

Hi Bernard,

Thanks for raising this issue - it certainly helped me! This after quite
a number of hours trying to understand why zoom would not launch
properly.

I agree with your suggestion that this should be a recommended
dependency for firefox-esr.

Although it would also make sense as a dependency for some of the KDE
packages - I noticed that desktop-file-utils is listed as a dependency
for gnome, mate, and cinnamon, but not for anything from KDE.

Thanks again,

Marten

Bug#1002372: marked as done (nbconvert: FTBFS: AttributeError: module 'mistune' has no attribute 'BlockGrammar')

[Gordon Ball]

On Sun, Jan 09, 2022 at 11:47:47AM -0500, Sandro Tosi wrote:
> Gordon,
> 
> >[ Gordon Ball ]
> >* Vendor mistune 0.8.4 due to incompatibility with mistune 2
> >  (Closes: #1001283, #1002372)
> 
> i think you closed *all* the mistune bugs by doing this. can you
> reopen the ones not affecting nbconvert so that we dont lose track of
> them?

Hi Sandro

I _think_ the closed bugs (#1001283 was merged with 6 others) only cover
the cases where the FTBFS tracebacks showed nbconvert (rather than
direct import of mistune). I haven't admittedly tried rebuilding them
all, but given the failure mode, I think the bug was correctly merged
and they're likely to be fixed.

* #1002371 python-fluids
* #1002373 python-fabio
* #1002374 silx
* #1002375 mdtraj
* #1002383 pyswarms
* #1002790 statsmodels

The main tracking bug for mistune (#1001591) should still be open, along
with related bugs for packages which imported mistune directly (#1002163
python-m2r, #1002254 lookatme, #1002380 python-matrix-nio).

Am I missing anything else which was wrongly closed?

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

Bug#980316: about corepack and yarnpkg

[Paolo Greppi]

I stumbled upon this thread related to packaging corepack for gentoo: 
https://github.com/nodejs/corepack/issues/76


We now have node 16 in experimental, but our package does not bundle 
corepack (as upstream does):

https://packages.debian.org/experimental/amd64/nodejs/filelist

I propose that we create a RFP/ITP for corepack separate from nodejs, 
with Conflicts: yarnpkg


The corepack binary would install /usr/bin/yarnpkg pointing to the 
corepack shims; this would allow Debian users who "use different package 
manager versions across multiple projects" to happily install random 
binaries downloaded from the internet if they wish.


If we agree that we (as a distribution) need specific versions of 
yarnpkg (for building other stuff, we need to keep one or more yarnpkg 
packages in Debian, all with Conflicts: corepack + each other.


If we really want yarnpkg 1, according to my tests, the corepack route 
is useless:


docker pull node:16
docker run -it --rm node:16 bash
yarn -v # 1.22.15
# this downloads https://registry.npmjs.org/yarn/-/yarn-1.22.17.tgz
# based on the versions / 1.22.17 / dist / tarball value in:
# https://registry.yarnpkg.com/yarn/
corepack prepare yarn@1.22.17 --activate
yarn -v # 1.22.15
corepack yarn -v # 1.22.17
ls -l /root/.node/corepack

total 2
-rw-r--r-- 1 root root 63 Jan  9 18:33 lastKnownGood.json
drwxr-xr-x 1 root root 14 Jan  9 18:13 yarn

To "build" it quick and dirty we can download once and for all the same 
pre-built binary that corepack would download, extract it and symlink it 
to /usr/bin/yarnpkg (without shims); this package should go to contrib 
since it downloads stuff from the internet during the build, but would 
fix the issue of yarnpkg blocking the migration to webpack5 and removal 
of node-request.
Or else keep alive the current version in main by just bundling into it 
webpack4 and node-request.


If we really want a new yarnpkg3 package, corepack is also useless as it 
merely installs yarnpkg 1.
The upstream recommended way of installing yarnpkg 3 (get yarn 1 with 
corepack then yarn init -2 (sic!)) just downloads the current pre-built 
binary (ATM 
https://repo.yarnpkg.com/3.1.1/packages/yarnpkg-cli/bin/yarn.js, 2199165 
bytes) to .yarn/releases/yarn-3.1.1.cjs.
AFAICT this does not integrate with the shared package manager versions 
stored in ~/.node/corepack.


One way to "build" yarnpkg3 quick and dirty is to download once and for 
all the same pre-built binary that yarn init -2 would download, and 
symlink it to /usr/bin/yarnpkg (without shims).
Or if we want it in main we should replicate the way upstream builds 
this yarn.js binary.


Sorry for the long message, this is a mess!

Paolo

Bug#934926: [Pkg-zsh-devel] Bug#934926: update (overridding of default fpath causes uncessary complexity and pain for software providing zsh completions)

[Frank Terbeck]

Axel Beckert wrote:
[…]
>> With that, we could add the prefix based site-functions directory,
>> but deprecate its use.
>
> Ack, that thought came to me also after having read your mail
> half-through. It though has the danger that some so far not active
> plugins will suddenly start to work. So we add least need to
> debian/zsh.bug-script.
>
> Currenty it only checks for packages that ship files in
> /usr/share/zsh/vendor-completions/ and
> /usr/share/zsh/vendor-functions/.

True. Although "normal" function don't get activated automatically. Only
files that match ‘_*’ in $fpath get activated automatically by compinit,
if the user calls that function in their configuration files.


>> That way, packages that disrespect the zsh package's policy still
>> work, while keeping the possibility of a clean system, in case all
>> package adhere to the policy. We could file a bunch of bugs for the
>> packages that are currently using /usr/share/zsh/site-functions
>> right now.
>
> Debian prefers lintian warnings over mass bug filing. Mass bug filing
> needs to be discussed on the debian-devel mailing list first.

That is fair.


> What I now still wonder to (hopefully) address Joey's issue:
>
> Is there a way to build the Debian zsh (respectively probably the
> zsh-dev) package in a way so that locally installed Zsh extensions get
> cleanly installed into /usr/local/ while Debian packages still install
> stuff to /usr/ (preferably these vendor-* directories)?

Well, I  am not sure what  "plugins" do in terms  of installation proce-
dures. The  only such package that  I have written¹ ships  a script that
asks you for a directory that it should use for deployment.

If I were to do some sort of automatic site-local installation, I'd pro-
bably install to this: zsh -c '${fpath[1]}'


> I wonder if something like a dh_zsh helper could help here (i.e. for
> the vendor-* directory part) as well.

I suppose we could make it do this:

Install files from the source  directory, that are not generally instal-
led by  the upstream installation  process. I  think that this  is still
more often than not the case:

  dh_zsh -c -s examples/_foobar contrib/_quux
  dh_zsh -f -s examples/some-function


Similarly, move functions from the in the packaging root directory, in
case things get installed by the upstream installation procedure:

  dh_zsh -c -p /usr/local/share/zsh/site-functions/_foobar
  dh_zsh -f -p /usr/share/zsh/site-functions/some-function

The mnemonics here are:

  -c → Completion system function; put into vendor-completions
  -f → General, auto-loadable function file.
  -s → From Source directory
  -p → From package root directory.

I suppose we could also add a ‘-r’ option to make the process recursive.


In addition, we  could add an automatic mode for  stuff in the packaging
root directory, if called without  arguments, which should fix naïve in-
stallation procedures automatically, due to zsh's convention about names
for completion functions:

  - Scan these directories:
- /usr/local/share/zsh/site-functions
- /usr/share/zsh/site-functions
  - Move files matching ‘_*’ to vendor-completions
  - Move the other files to vendor-functions.
  - Remove those two directories (they should be empty now)


I think that should support most installation schemes.


WDYT?


Regards, Frank

Bug#1003277: RFS: memtest86+/5.31b-1 [QA] -- thorough real-mode memory tester

[Fabio Fantoni]

Il 08/01/2022 13:15, Bastian Germann ha scritto:
On Fri, 7 Jan 2022 21:47:49 +0100 Fabio Fantoni 
 wrote:

Il 07/01/2022 21:24, Bastian Germann ha scritto:
> On 07.01.22 21:10, Fabio Fantoni wrote:
>> I did wrong to do a QA upload?
>
> No, a QA upload is fine. But the maintainer should be kept "Debian 
QA > Group" to be formally correct.


Ah... sry, I saw only now the mistake of not merging debian/control 
change, fixed and did another upload to mentors




a.out should be excluded. Please do not forget to add a +dfsg suffix 
to the upstream version.
first time I do a repack in many years (if I remember correctly), seems 
ok from a fast look but if you want check is right probably is better, 
after I'll push also to the Debian/memtest86plus: 
https://salsa.debian.org/fantu-guest/memtest86plus/-/commits/debian/experimental


Missing copyright info in the following files:
bootsect.S
dmi.c
head.S
multiboot.[ch]
serial.h
smp.h


tried to do: 
https://salsa.debian.org/fantu-guest/memtest86plus/-/commit/1d24dd88c9f53110d20cc70769f6e0c7b63ef04d


but smp.h have only "partial" header, license I suppose can be one of 
the BSD but I'm not sure what to put exactly in d/copyright


can you tell me what I should do with smp.h entry and if there are other 
changes to do about other entries or are ok please?




OpenPGP_signature
Description: OpenPGP digital signature

Bug#1002575: iwd: Doesn't create global config file or its directory (/etc/iwd/)

[Diederik de Haas]

On Sunday, 9 January 2022 21:24:50 CET Jonas Smedegaard wrote:
> > Got a reply on that list [1] that the following commit was added:
> > https://git.kernel.org/pub/scm/network/wireless/iwd.git/commit/?id=04fccea
> > 63bd42b0b72587df9edee72d677b6ca7d
> > 
> > And then the following question which you should determine:
> > "Let us know if this is what the Debian package maintainer had in mind."
> 
> Looks good to me.  Thanks!

Excellent :)
I was just writing a response that I forwarded your response and to mention 
that the commit is contained in the new 1.21 release ... and then I got a mail 
that the new release is already packaged and thus this bug closed.

Thanks!

Diederik

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

Bug#1002850: udev fails to create a symlink for a SDHC card connected

[Michael Biebl]

On 09.01.22 20:07, pe...@easthope.ca wrote:


I commented in the last line of /etc/udev/rules.d/10-local.rules .
Otherwise the 10-local.rules is the same as attached to Message #102.

Then turned on debug logging and plugged the USB adapter with the
SD card.  The udevInfo file is attached.

The KingstonUSB SYMLINK is created but the log has no mention of the
/etc/udev/rules.d/10-local.rules file.  So the first rule in 10-local.rules
has effect but the 2nd does not.


If you have a properly written udev rules file, like

# cat /etc/udev/rules.d/10-local.rules
KERNEL=="sd?1", ATTR{size}=="122538372", SYMLINK="foo"

you'll get
# udevadm control --log-priority=debug
# journalctl -f | grep etc

Jan 09 21:55:14 pluto systemd-udevd[168692]: sdc1: 
/etc/udev/rules.d/10-local.rules:1 LINK 'foo'
Jan 09 21:55:14 pluto systemd-udevd[168692]: sdc1: 
/etc/udev/rules.d/10-local.rules:1 LINK 'foo'


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1003416: RFS: uriparser/0.9.6+dfsg-1 -- uriparser

[Jörg Frings-Fürst]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

   Package name: uriparser
   Version : 0.9.6+dfsg-1
   Upstream Author : [fill in name and email of upstream]
   URL : http://uriparser.sourceforge.net
   License : BSD-3-clause, LGPL-2.1+
   Vcs : https://jff.email/cgit/uriparser.git
   Section : libs

It builds those binary packages:

  liburiparser1 - URI parsing library compliant with RFC 3986
  liburiparser-dev - development files for uriparser
  liburiparser-doc - documentation files for uriparser

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

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

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

 dget -x 
https://mentors.debian.net/debian/pool/main/u/uriparser/uriparser_0.9.6+dfsg-1.dsc

or from 

 git https://jff.email/cgit/uriparser.git/?h=release%2Fdebian%2F0.9.6%2Bdfsg-1



Changes since the last upload:

 uriparser (0.9.6+dfsg-1) unstable; urgency=medium
 .
   * New upstream release.
 - Fix for CVE-2021-46141 and CVE-2021-46142.
   * Fix debian/not-installed.
   * debian/copyright:
 - Add year 2022 to myself.
   * Declare compliance with Debian Policy 4.6.0.1 (No changes needed).



CU
Jörg


-- 
New:
GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB  30EE 09F8 9F3C 8CA1 D25D
GPG key (long) : 09F89F3C8CA1D25D
GPG Key: 8CA1D25D


Jörg Frings-Fürst
D-54470 Lieser

git:  https://jff.email/cgit/


Threema: SYR8SJXB
Skype: joergpenguin
Telegram: @joergfringsfuerst


My wish list: 
 - Please send me a picture from the nature at your home.



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

Bug#1003417: scipy: build ignores test failures

[Christian Kastner]

Source: scipy
Version: 1.7.3-1
Severity: important

First of all - thanks for uploading 1.7.3, I'm debugging an issue with
one of its dependents (scikit-learn) on ppc64el that I could trace back
to scipy, so perhaps this version helps!

However, looking at the build logs for 1.7.3-1, I noticed that test
errors are not being recognized.

All Python 3.10 seem to be skipped because of a DeprecationWarning:

> === Testing: python3.10 scipy ===
> = test session starts 
> ==
> platform linux -- Python 3.10.1, pytest-6.2.5, py-1.10.0, pluggy-0.13.0 -- 
> /usr/bin/python3.10
> cachedir: .pytest_cache
> rootdir: /<>, configfile: pytest.ini
> collecting ... collected 0 items / 1 error
> 
>  ERRORS 
> 
>  ERROR collecting test session 
> _
...
> === short test summary info 
> 
> ERROR ../.. - DeprecationWarning: The distutils package is deprecated and 
> sla...
>  Interrupted: 1 error during collection 
> 
> === 1 error in 0.20s 
> ===
> #errors: 0

The Python 3.9 tests run, but 3 fail and these failures aren't discovered:

> === short test summary info 
> 
> FAILED 
> ../../debian/python3-scipy/usr/lib/python3.9/dist-packages/scipy/linalg/tests/test_decomp.py::TestSchur::test_sort
> FAILED 
> ../../debian/python3-scipy/usr/lib/python3.9/dist-packages/scipy/linalg/tests/test_lapack.py::test_sygst
> FAILED 
> ../../debian/python3-scipy/usr/lib/python3.9/dist-packages/scipy/stats/tests/test_continuous_basic.py::test_cont_basic[500-200-ncf-arg74]
> = 3 failed, 32544 passed, 2107 skipped, 11134 deselected, 104 xfailed, 11 
> xpassed in 533.27s (0:08:53) =

Bug#1003086: foot: please include subdir themes as examples

[Jonas Smedegaard]

Quoting Birger Schacht (2022-01-09 21:17:36)
> Hi,
> 
> On 1/9/22 20:59, Jonas Smedegaard wrote:
>  > Package: foot-themes
>  > Version: 1.10.3-1
>  > Followup-For: Bug #1003086
>  >
> > Control: retitle -1 foot-themes: please document how to use (or merge as 
> > examples)
> > 
> > It seems there is no way to actually _use_ the foot-themes package,
> > other than manually copy the contents of a theme file into a foot.conf
> > file.
> 
> You can use the `include` directive in the `[main]` section of the 
> configuration file to include a theme file, i.e.:
>  > [main]
>  > include=/usr/share/foot/themes/solarized-dark
> 
> > 
> > Please include documentation on how to enable a theme.
> 
> The manpage states:
>  >   include
>  >   Absolute path to configuration file to import.
>  >
>  >   The import file has its own section scope. I.e. the
>  > including configuration is still in the default section after the
>  > include, regardless of which section the included file ends in.
>  >
>  >
>  >   •   The path must be an absolute path, or start with ~/.
>  >   •   Multiple include directives are allowed, but only
>  > one path per directive.
>  >   •   Nested imports are allowed.
> 
> Do you think the documentation should be more explicit?

Strictly speaking, you are right: Documentation covers it, even if 
arguably only "between the lines".

But really, I failed at figuring it out, so I guess others might too.

I suggest to add a README.Debian file with a concrete example of how to 
enable a theme.


 - Jonas

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

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

signature.asc
Description: signature

Bug#1003086: foot: please include subdir themes as examples

[Birger Schacht]

Hi,

On 1/9/22 20:59, Jonas Smedegaard wrote:
> Package: foot-themes
> Version: 1.10.3-1
> Followup-For: Bug #1003086
>

Control: retitle -1 foot-themes: please document how to use (or merge as 
examples)

It seems there is no way to actually _use_ the foot-themes package,
other than manually copy the contents of a theme file into a foot.conf
file.


You can use the `include` directive in the `[main]` section of the 
configuration file to include a theme file, i.e.:

> [main]
> include=/usr/share/foot/themes/solarized-dark



Please include documentation on how to enable a theme.


The manpage states:
>   include
>   Absolute path to configuration file to import.
>
>   The import file has its own section scope. I.e. the
> including configuration is still in the default section after the
> include, regardless of which section the included file ends in.
>
>
>   •   The path must be an absolute path, or start with ~/.
>   •   Multiple include directives are allowed, but only
> one path per directive.
>   •   Nested imports are allowed.

Do you think the documentation should be more explicit?

cheers,
Birger


OpenPGP_0xCB06EA7B78DBE151.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1002575: iwd: Doesn't create global config file or its directory (/etc/iwd/)

[Jonas Smedegaard]

Quoting Diederik de Haas (2022-01-03 23:26:50)
> On Monday, 27 December 2021 19:27:29 CET Diederik de Haas wrote:
> > Control: forwarded -1
> > https://lists.01.org/hyperkitty/list/i...@lists.01.org/thread/ZP5J2JEPF4YPOM
> > H6XG6VUV2GYNAHCPXF/
> > On Friday, 24 December 2021 16:48:57 CET Jonas Smedegaard wrote:
> > > I agree that it would be helpful if the iwd package included a
> > > system-wide default config file, even if containing only commented out
> > > sample entries.
> > > 
> > > Do you want to suggest it to upstream?
> > 
> > Done at the forwarded address/URL.
> 
> Got a reply on that list [1] that the following commit was added:
> https://git.kernel.org/pub/scm/network/wireless/iwd.git/commit/?id=04fccea63bd42b0b72587df9edee72d677b6ca7d
> 
> And then the following question which you should determine:
> "Let us know if this is what the Debian package maintainer had in mind."

Looks good to me.  Thanks!

 - Jonas

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

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

signature.asc
Description: signature

Bug#912836: closed by Debian FTP Masters (reply to Christoph Biedl ) (Bug#912836: fixed in gkrellm-leds 0.8.0-2)

[Helmut Grohne]

Control: reopen -1

On Tue, Jan 04, 2022 at 08:51:08AM +, Debian Bug Tracking System wrote:
> #912836: gkrellm-leds FTCBFS: compiles for the wrong architecture
> 
> It has been closed by Debian FTP Masters  
> (reply to Christoph Biedl ).

Not quite. Please also apply the other half of the patch:

> diff -u gkrellm-leds-0.8.0/Makefile gkrellm-leds-0.8.0/Makefile
> --- gkrellm-leds-0.8.0/Makefile
> +++ gkrellm-leds-0.8.0/Makefile
> @@ -1,8 +1,9 @@
>  SHELL = /bin/sh
>  VPATH = src:src/pixmaps
>  
> -GTK_INCLUDE = `pkg-config gtk+-2.0 --cflags`
> -GTK_LIB = `pkg-config gtk+-2.0 --libs`
> +PKG_CONFIG ?= pkg-config
> +GTK_INCLUDE = `$(PKG_CONFIG) gtk+-2.0 --cflags`
> +GTK_LIB = `$(PKG_CONFIG) gtk+-2.0 --libs`
>  
>  X11_LIB = -L/usr/X11R6/lib -lX11 -lXtst
>  

Helmut

Bug#1003414: discover FTCBFS: unsatisfiable cross Build-Depends: libtool-bin

[Helmut Grohne]

Source: discover
Version: 2.1.2-10
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: cross-satisfiability

discover cannot be cross built from source, because its dependency on
libtool-bin is unsatisfiable. It turns out that discover no longer
actually needs the libtool-bin relict. It now properly libtoolizes and
can deal with plain libtool. Please consider applying the attached
patch.

Helmut
diff --minimal -Nru discover-2.1.2/debian/changelog 
discover-2.1.2/debian/changelog
--- discover-2.1.2/debian/changelog 2022-01-09 08:48:08.0 +0100
+++ discover-2.1.2/debian/changelog 2022-01-09 20:49:56.0 +0100
@@ -1,3 +1,10 @@
+discover (2.1.2-10.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Demote libtool-bin Build-Depends to libtool. (Closes: #-1)
+
+ -- Helmut Grohne   Sun, 09 Jan 2022 20:49:56 +0100
+
 discover (2.1.2-10) unstable; urgency=medium
 
   * Modernize packaging a little:
diff --minimal -Nru discover-2.1.2/debian/control discover-2.1.2/debian/control
--- discover-2.1.2/debian/control   2022-01-09 08:30:59.0 +0100
+++ discover-2.1.2/debian/control   2022-01-09 20:49:35.0 +0100
@@ -3,7 +3,7 @@
 Priority: optional
 Maintainer: Debian Install System Team 
 Uploaders: David Nusinow , Petter Reinholdtsen 

-Build-Depends: debhelper-compat (= 13), libexpat1-dev, po-debconf, 
libusb-1.0-0-dev, autotools-dev, libtool-bin
+Build-Depends: debhelper-compat (= 13), libexpat1-dev, po-debconf, 
libusb-1.0-0-dev, autotools-dev, libtool
 Standards-Version: 3.8.0
 Vcs-Git: https://salsa.debian.org/installer-team/discover.git
 Vcs-Browser: https://salsa.debian.org/installer-team/discover

Bug#1003413: vdr-plugin-xineliboutput hides compiler invocations by default

[Helmut Grohne]

Source: vdr-plugin-xineliboutput
Version: 2.2.0+git20211212-1
Tags: patch

When building vdr-plugin-xineliboutput, compiler invocations are hidden
by default. In order to diagnose build issues, we usually want them
included in the log - unless adding "terse" to DEB_BUILD_OPTIONS. Please
consider applying the attached patch to build verbosely by default.

Helmut
diff --minimal -Nru vdr-plugin-xineliboutput-2.2.0+git20211212/debian/changelog 
vdr-plugin-xineliboutput-2.2.0+git20211212/debian/changelog
--- vdr-plugin-xineliboutput-2.2.0+git20211212/debian/changelog 2021-12-12 
19:27:25.0 +0100
+++ vdr-plugin-xineliboutput-2.2.0+git20211212/debian/changelog 2022-01-09 
20:36:44.0 +0100
@@ -1,3 +1,10 @@
+vdr-plugin-xineliboutput (2.2.0+git20211212-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Build verbosely by default. (Closes: #-1)
+
+ -- Helmut Grohne   Sun, 09 Jan 2022 20:36:44 +0100
+
 vdr-plugin-xineliboutput (2.2.0+git20211212-1) unstable; urgency=medium
 
   * New Upstream Snapshot (commit f4df32) (Closes: #951921)
diff --minimal -Nru vdr-plugin-xineliboutput-2.2.0+git20211212/debian/rules 
vdr-plugin-xineliboutput-2.2.0+git20211212/debian/rules
--- vdr-plugin-xineliboutput-2.2.0+git20211212/debian/rules 2021-12-12 
19:27:25.0 +0100
+++ vdr-plugin-xineliboutput-2.2.0+git20211212/debian/rules 2022-01-09 
20:36:43.0 +0100
@@ -3,6 +3,10 @@
 # Uncomment this to turn on verbose mode.
 #export DH_VERBOSE=1
 
+ifeq (,$(filter terse,$(DEB_BUILD_OPTIONS)))
+MAKE_OPTIONS += VERBOSE=1
+endif
+
 %:
dh $@ --with vdrplugin
 

Bug#1003412: 9base build system always strips

[Helmut Grohne]

Source: 9base
Version: 1:6-11
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

The 9base build system strips binaries unconditionally. This has
multiple consequences:
 * There is no -dbgsym package.
 * DEB_BUILD_OPTIONS=nostrip produces stripped binaries.
 * It fails using the build architecture strip during cross builds.

The solution to all of these is not letting the upstream build system
strip and rely on dh_strip. Please consider applying the attached patch.

Helmut
diff --minimal -Nru 9base-6/debian/changelog 9base-6/debian/changelog
--- 9base-6/debian/changelog2021-02-28 09:30:20.0 +0100
+++ 9base-6/debian/changelog2022-01-09 18:05:44.0 +0100
@@ -1,3 +1,9 @@
+9base (1:6-12) UNRELEASED; urgency=medium
+
+  * Don't let the build system strip. (Closes: #-1)
+
+ -- Helmut Grohne   Sun, 09 Jan 2022 18:05:44 +0100
+
 9base (1:6-11) unstable; urgency=medium
 
   * QA upload.
diff --minimal -Nru 9base-6/debian/patches/nostrip.patch 
9base-6/debian/patches/nostrip.patch
--- 9base-6/debian/patches/nostrip.patch1970-01-01 01:00:00.0 
+0100
+++ 9base-6/debian/patches/nostrip.patch2022-01-09 18:05:32.0 
+0100
@@ -0,0 +1,40 @@
+--- 9base-6.orig/config.mk
 9base-6/config.mk
+@@ -22,3 +22,4 @@
+ AR  = ar rc
+ CC  = cc
+ YACC= ../yacc/9yacc
++STRIP   = strip
+--- 9base-6.orig/diff/Makefile
 9base-6/diff/Makefile
+@@ -8,7 +8,7 @@
+ include ../config.mk
+ 
+ all: ${TARG}
+-  @strip ${TARG}
++  @$(STRIP) ${TARG}
+   @echo built ${TARG}
+ 
+ install: ${TARG}
+--- 9base-6.orig/sam/Makefile
 9base-6/sam/Makefile
+@@ -10,7 +10,7 @@
+ include ../config.mk
+ 
+ all: ${TARG}
+-  @strip ${TARG}
++  @$(STRIP) ${TARG}
+   @echo built ${TARG}
+ 
+ install: ${TARG}
+--- 9base-6.orig/std.mk
 9base-6/std.mk
+@@ -6,7 +6,7 @@
+ include ../config.mk
+ 
+ all: ${TARG}
+-  @strip ${TARG}
++  @$(STRIP) ${TARG}
+   @echo built ${TARG}
+ 
+ install: install-default post-install
diff --minimal -Nru 9base-6/debian/patches/series 9base-6/debian/patches/series
--- 9base-6/debian/patches/series   2021-02-28 09:15:00.0 +0100
+++ 9base-6/debian/patches/series   2022-01-09 18:04:19.0 +0100
@@ -8,3 +8,4 @@
 0008-rc-Default-to-a-traditional-prompt.patch
 0009-fix-non-verbose-build.patch
 0010-applied-Alexander-Clouter-s-9base-sha1sum-patch.patch
+nostrip.patch
diff --minimal -Nru 9base-6/debian/rules 9base-6/debian/rules
--- 9base-6/debian/rules2021-02-28 08:38:39.0 +0100
+++ 9base-6/debian/rules2022-01-09 18:05:42.0 +0100
@@ -28,7 +28,7 @@
 override_dh_auto_build:
dh_auto_build -- \
CFLAGS='$(CFLAGS) $(CPPFLAGS)' LDFLAGS='$(LDFLAGS)' \
-   PREFIX=$(PREFIX) MANPREFIX=$(MANDIR)
+   PREFIX=$(PREFIX) MANPREFIX=$(MANDIR) STRIP=true
 
 override_dh_auto_install:
dh_auto_install -- \

Bug#1003411: microbiomeutil FTCBFS: hard codes the build architecture compiler

[Helmut Grohne]

Source: microbiomeutil
Version: 20101212+dfsg1-4
Tags: patch upstream
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

microbiomeutil fails to cross build from source, because it hard codes
the build architecture compiler. After making it substitutable, it cross
builds just fine. Please consider applying the attached patch.

Helmut
--- microbiomeutil-20101212+dfsg1.orig/NAST-iEr/Makefile
+++ microbiomeutil-20101212+dfsg1/NAST-iEr/Makefile
@@ -3,7 +3,7 @@
 all: NAST-iEr
 
 NAST-iEr: NAST-iEr.c
-	gcc $(CPPFLAGS) $(CFLAGS) $(LDFLAGS) NAST-iEr.c -o NAST-iEr
+	$(CC) $(CPPFLAGS) $(CFLAGS) $(LDFLAGS) NAST-iEr.c -o NAST-iEr
 
 
 clean:

Bug#996785: Also happens for spaces

[Niels Thykier]

Jelmer Vernooij:
> FWIW this happens with tabs as well as spaces.
> 
> Any news on a fix for this ? It's currently a blocker for the janitor since a
> lot of packages seem to have leading whitespace in control fields, and this
> triggers spurious changes.
> 

Hi Jelmer,

I thought it was fixed already (in git, not sure there was a release
since then).  Can you provide a reproducer and I will look into it?

~Niels

Bug#1003408: ITS: manpages-hu by transferring it to manpages-l10n

[GCS]

Hi Helge,

On Sun, Jan 9, 2022 at 7:30 PM Helge Kreutzmann  wrote:
> As I'm not a DD (but a DM), the exact timing depends on those of my
> sponsor(s). But I will ensure that at least 21 days have passed since
> this bug was filled.
 Indeed, manpages-hu package is a thing of the distant past. Would it
help if I immediately file for its removal or what would be the best
action to help your efforts?

Regards,
Laszlo/GCS

Bug#1003410: RM: flexbackup -- RoQA; unmaintained, dead upstream, RC-buggy

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Please remove flexbackup. It's dead upstream (last release from 2003),
unmaintained (last maintainer upload in 2008, orphaned without an adopter
since 2012) and currently RC-buggy. Plenty of alternatives exist.

Cheers,
Moritz

Bug#1003086: foot: please include subdir themes as examples

[Jonas Smedegaard]

Package: foot-themes
Version: 1.10.3-1
Followup-For: Bug #1003086

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Control: retitle -1 foot-themes: please document how to use (or merge as 
examples)

It seems there is no way to actually _use_ the foot-themes package,
other than manually copy the contents of a theme file into a foot.conf
file.

Please include documentation on how to enable a theme.

Or alternatively, if the contained files really are just example files,
then I see no point in a separate package for them, and recommend to
instead include them as example files with the main foot package (as
originally proposed in this bugreport).

Thanks for your work on packaging foot!

 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmHbPq8ACgkQLHwxRsGg
ASEjERAAhgr9lgOE5ws8WTXAwhaa6zJjQsykJixNKx2qZW4KCx1LQLBzi8y05ipB
J7jBxpBFZRuYAeAr6HGtbQ9Tv7E+lep0clojHMD/t7g1CYAa2IE6bGvHgUUom7pE
4ALNIPGIZvcocrLZtB9KyWB8mI1j4fqooANYlwJk6SOLyTYqUTlWswTMnNuA6sOC
FftWZf+t8BSRHn41iK9o/U3D1KfqTB6zOsic5h4PYLDkLnD99v2d3Miz3hCTUyh4
xB+SXrKu2vKFpsSN/MoTVTY56/GKsQzjLQFU/QHvebgApSSVwuYA/gqf09sjy5vS
m1KjbqO/MoTisSFRvhlen9e0uoPOZzzh6SkyQ77GDhWa6SCZIK2BEwxhGgsiyZbY
QCjZc0+N897txyXsaqNwqCC8DccP0vt0HGBnS1ZThQvHO0aPnMfKXzfqCMfP9UkC
HUy6Jf7xkSmWpQM6gdouuq1kD51cgDyyXIOkqvlYQgQzodtoPOWZMUOiha8CT8Bt
xYMykGtq2aHYr1hW89gQ+QW7UeMwF8NpSWi91UGBcsK0tdXgrEWQupMva9rqHa6s
Eyn23zBRn90xXgz74O7B7CIfkiKg0bZ12LDTBb/eCy83OP/ITkS9IMgfny+bObVy
1iSta9102ZuHMNHJC/EtAlP6HTfdmdwStz/fLGTZd4XJsh3GGM8=
=qra8
-END PGP SIGNATURE-

Bug#1003409: RM: xxgdb -- RoQA; dead upstream, unmaintained, alternatives exist

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Please remove xxgdb. It's dead upstream, unmaintained (last upload in 2010
and orphaned without an adopter since 2019) and alternatives like ddd exist.

Cheers,
Moritz

Bug#998897: python3-sip: Thread 1 "python" received signal SIGSEGV, Segmentation fault.

[Dmitry Shachnev]

Try subscribing to the mailing list before sending your email.

For use-after-free bugs, I find valgrind tool handy, which detects such issues 
even when the program wouldn't crash.


On January 9, 2022 10:18:08 PM GMT+03:00, artem rus  
wrote:
> Hi Dmitry.
> 
> I checked the code in sip5 and sip6 and found the same lines as in
> sip4, which raise the segmentation fault in sip4. So, there is a high
> probability all sip versions have the same bug.  This is "using after
> free" bug, so it's hard to reproduce. Normally the probability of
> segmentation fault is very low.  I reported the bug to
> p...@riverbankcomputing.com same time as to bugs.debian.org, but
> nothing happens :( Maybe my mail was filtered ? So I have no idea what
> to do next. What do you think?

--
Dmitry Shachnev

Bug#995995: RFS: nemo-compare/5.0.1-1 [ITP] -- Context menu comparison extension for Nemo file manager

[Bastian Germann]

Forwarded from #992214:

On 09.01.22 17:00, Fabio Fantoni wrote:

Il 25/12/2021 19:36, Fabio Fantoni ha scritto:

Hi, here I don't understand why title refer to nemo-compare but RFS was opened 
about nemo-audio-tab

In any cases some useful infos:

upstream have all nemo extensions in one repository: 
https://github.com/linuxmint/nemo-extensions

major of bugfix versions are specific to one or few extensions near always so the correct check for a new version of 
specific extension is check if its package is released on mint repository, looking nemo-compare:



version=4
http://packages.linuxmint.com/pool/backport/n/nemo-compare/ \
nemo-compare_([\d.]+)%2b[\w\d]+\.tar\.gz


is correct

about nemo extensions upload and maintain all them in debian not worth it, for the 2 only maintainer actually active 
in it (joshua and me), and more with actual upload difficulties that make waste time :(


nemo-compare seems to me one of the few that worth upload and keeping

major of commits are only version bump so also less upload needed in future: 
https://github.com/linuxmint/nemo-extensions/commits/master/nemo-compare but before first upload of it I think is 
better update to 5.2.1 as it add one small fix, @Joshua can you do it please?


I did a fast change to d/watch 
(https://salsa.debian.org/cinnamon-team/nemo-compare/-/commit/43230d19fcc9faf27c387d660ad9f2e35397460d) for check github 
tags and search both "x.y.z" (new version for all extensions) and "nemo-compare-x.y.z" (specific bugfix version only for 
it) and from some fast tests seems ok, @Bastian: is it good now?

Bug#998897: Fwd: Bug#998897: python3-sip: Thread 1 "python" received signal SIGSEGV, Segmentation fault.

[artem rus]

Hi Dmitry.

I checked the code in sip5 and sip6 and found the same lines as in
sip4, which raise the segmentation fault in sip4. So, there is a high
probability all sip versions have the same bug.  This is "using after
free" bug, so it's hard to reproduce. Normally the probability of
segmentation fault is very low.  I reported the bug to
p...@riverbankcomputing.com same time as to bugs.debian.org, but
nothing happens :( Maybe my mail was filtered ? So I have no idea what
to do next. What do you think?

--
Artem Rusanov

вс, 9 янв. 2022 г. в 20:34, Dmitry Shachnev :
>
> Hi Artem, and sorry for delayed reply.
>
> On Tue, Nov 09, 2021 at 07:57:17PM +0300, Artem Rusanov wrote:
> > Dear Maintainer,
> >
> > Sometimes during startup (depend on python code, comment line can affect
> > this) my software crashes with segmentation fault in python-sip.
>
> sip4 is no longer developed.
>
> Please try with sip6 (which is available in Debian testing/unstable) or sip5
> (which is available in bullseye/stable).
>
> If the issue still happens with one of these versions, I suggest you to
> report a bug to upstream mailing list (better with a minimal example):
>
> https://www.riverbankcomputing.com/mailman/listinfo/pyqt
>
> --
> Dmitry Shachnev

Bug#1002850: udev fails to create a symlink for a SDHC card connected

[peter]

I commented in the last line of /etc/udev/rules.d/10-local.rules .
Otherwise the 10-local.rules is the same as attached to Message #102.

Then turned on debug logging and plugged the USB adapter with the 
SD card.  The udevInfo file is attached.

The KingstonUSB SYMLINK is created but the log has no mention of the 
/etc/udev/rules.d/10-local.rules file.  So the first rule in 10-local.rules
has effect but the 2nd does not.

With the Japanese keyboard, I wonder whether the file has an odd  
hidden character somewhere.  The character interrupts processing of rules?
I can hunt for an odd character.

Thx,   ... P.



udevInfo
Description: Binary data

Bug#976811: [pkg-php-pear] Bug#976811: Bug#976811: transition: php8.1

[Ondřej Surý]

Hmm, this might need same treatment as src:php-defaults. I will need to export 
the version-to-break somehow from the src:php-defaults. I’ll have to think 
about it for a while, but if you have another smart idea, please share it.

--
Ondřej Surý  (He/Him)

> On 9. 1. 2022, at 19:38, Paul Gevers  wrote:
> 
> Hi David,
> 
> On 08-01-2022 23:09, David Prévot wrote:
>>> I also see some autopkgtest regressions which have this (eg. [1, 2]):
>>> """
>>> PHPUnit requires the "dom" extension.
>>> """
>>> where should that get fixed?
>> There are several php7.4-* packages pulled in those logs, so it’s not really 
>> a surprise that doesn’t end well (php-xml 2:7.4+76 is probably not the 
>> expected version either).
> 
> Normally this points to an issue with the right versioned Depends or 
> versioned Breaks. This is important because some of these packages are 
> currently allowed to migrate to testing without php-defaults (were it not for 
> the autopgktest failure), and would break functionality in testing. We need 
> to find out how to fix that.
> 
> Paul

Bug#976811: [pkg-php-pear] Bug#976811: Bug#976811: transition: php8.1

[Paul Gevers]

Hi David,

On 08-01-2022 23:09, David Prévot wrote:

I also see some autopkgtest regressions which have this (eg. [1, 2]):
"""
PHPUnit requires the "dom" extension.
"""
where should that get fixed?


There are several php7.4-* packages pulled in those logs, so it’s not 
really a surprise that doesn’t end well (php-xml 2:7.4+76 is probably 
not the expected version either).


Normally this points to an issue with the right versioned Depends or 
versioned Breaks. This is important because some of these packages are 
currently allowed to migrate to testing without php-defaults (were it 
not for the autopgktest failure), and would break functionality in 
testing. We need to find out how to fix that.


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1003240: mlton: mlton_20210117+dfsg-3 cannot rebuild itself on hppa

[Matthew Fluet]

On Fri, Jan 7, 2022 at 3:51 PM Ryan Kavanagh  wrote:

> Control: tags -1 + confirmed
> Control: retitle -1 mlton cannot rebuild itself on hppa or i386
>
> On Thu, Jan 06, 2022 at 07:55:00PM +, John David Anglin wrote:
> > It fails with a reproducible segmentation fault.
>
> I can reproduce this even with the latest upstream HEAD on the hppa
> porterbox, using
>
> make BOOTSTRAP_STYLE=3
>
> which makes it this far:
>
> -8<-
> make compiler SELF_COMPILE=true  CHECK_FIXPOINT=true   # tools2 + mlton2
> -> mlton3; mlton3 == mlton2
> [...]
> chmod -w front-end/mlb.grm.*
> sed \
> -e "s/MLTON_NAME/MLton/" \
> -e "s/MLTON_VERSION//" \
> < control/version_sml.src \
> > control/version.sml
> (cat control/version_sml.src; echo 'MLton' ''; cat
> control/version.sml) | sha1sum | sed 's/.*\([a-z0-9]\{40\}\).*/\1/' >
> control/version_sml.chk
> Compiling mlton
> "/home/rak/mlton/build/bin/mlton" \
> @MLton ram-slop 0.7  gc-summary -- \
> -default-ann 'sequenceNonUnit warn' -default-ann 'warnUnused true'
> -verbose 2   \
> -target self -output mlton-compile  \
> mlton.mlb
> MLton  starting
>Compile SML starting
>   frontend starting
>  parseAndElaborate starting
> Segmentation fault
> make[2]: *** [Makefile:72: mlton-compile] Error 139
> make[2]: Leaving directory '/home/rak/mlton/mlton'
> make[1]: *** [Makefile:75: compiler] Error 2
> make[1]: Leaving directory '/home/rak/mlton'
> make: *** [Makefile:29: all] Error 2
> -8<-
>

This looks like the "old" MLton successfully compiled the "new" mlton
(mlton1), which then went on to successfully compile the tools (mllex,
mlyacc, ...) and a second round of self-compilation (mlton2), which itself
went on to successfully compile the tools, but failed when trying to
perform a third round of self-compile (mlton3).  That's pretty surprising.

To get some debugging information, I would suggest compiling with
`MLTON_COMPILE_ARGS="-keep g -debug true"`.  The "-keep g" instructs MLton
to keep the generated .c files and the "-debug true" instructs MLton to
compile the generated .c files with "-g" and to link to a version of the
runtime system itself compiled with "-g".

On HPPA, MLton doesn't have a native codegen, so the default is `-codegen
c`.


> On Thu, Jan 06, 2022 at 06:04:18PM -0600, Henry Cejtin wrote:
> > ssume that it isn't reproducible on AMD, right?
> > Or better, x86 (32 bit)?
>
> Not reproducible on amd64, but it is reproducible on i386, even with
> codegen c:
>
> make BOOTSTRAP_STYLE=3 MLTON_COMPILE_ARGS='-codegen c'
>
> segfaults at
>
> -8<-
> make compiler CHECK_FIXPOINT=false # tools0 + mlton0
> -> mlton1
> make[1]: Entering directory '/home/rak/i386/mlton-20210117+dfsg'
> make -C "/home/rak/i386/mlton-20210117+dfsg/mlton"
> make[2]: Entering directory '/home/rak/i386/mlton-20210117+dfsg/mlton'
> Compiling mlton
> "mlton" \
> @MLton ram-slop 0.7  gc-summary -- \
>  -verbose 2 \
> -target self -output mlton-compile  \
> mlton-stubs.mlb
> MLton 20210117+dfsg-3 starting
>Compile SML starting
>   frontend starting
>  parseAndElaborate starting
> Segmentation fault
> -8<-
>

This looks like the "old" MLton didn't get very far compiling the "new"
MLton.  The `MLTON_COMPILE_ARGS="-codegen c"` doesn't  have any effect,
because those are only used when the "new" MLton is performing a second or
third round of self-compiling.  (You could use `OLD_MLTON_COMPILE_ARGS` to
influence the "old" MLton compiling the "new" MLton; this isn't even
getting to the point where the choice of codegen would have any effect.)

Of course, my understanding is that with Ryan's work, the "old" MLton isn't
even really that old --- it's just a binary package of the current sources,
considered "old" enough to be used as a prereq for building the sources.

Is there any chance that the issue is due to a (potential) mismatch
> between flags involving pic/pie we pass in via -cc-opt $(CFLAGS), and
> the default target-determined default? mlton has the flags -pi-style and
> -native-pic thanks to https://github.com/MLton/mlton/pull/365 that may
> need setting. (I haven't yet investigated this.) Debian used to carry a
> patch that forced PIC to fix a FTBFS on amd64, and I dropped it this
> most recent release because I thought it was no longer required (mlton
> built fine without it).
>

By default (i.e., without explicitly setting the `-pi-style` flag), MLton
should simply follow the behavior of the C compiler (and will not pass any
special flags to the C compiler).  Typically, a mismatch involving pic/pie
manifests as a linking error, because one object file isn't using a symbol
in a way compatible with the defining object file.

Bug#1003367: upgrade-reports: samba seriously broken after upgrade - major config changes

[Paul Gevers]

Control: reassign -1 src:samba

Hi Karl,

As you report an issue with Samba, I reassign this bug to the samba package.

Paul

On 09-01-2022 00:21, Karl Schmidt wrote:

Package: upgrade-reports
Severity: important

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

My previous release is: buster
I am upgrading to: bullseye
Upgrade date: Jan 06 2021
uname -a after upgrade: Linux malaysia 5.10.0-10-amd64 #1 SMP Debian 5.10.84-1 
(2021-12-08) x86_64 GNU/Linux

Method: comand line - $ wajig distupgrade

Contents of /etc/apt/sources.list:
eb http://mirrors.edge.kernel.org/debian bullseye main contrib non-free
deb http://deb.debian.org/debian-security/ bullseye-security main contrib 
non-free
deb http://deb.debian.org/debian bullseye-updates main contrib non-free

#security
deb http://security.debian.org/ buster/updates main contrib non-free
deb http://security.debian.org/debian-security buster/updates main contrib 
non-free

#deb http://ftp.us.debian.org/debian/ wheezy main
#Seamonkey
#deb http://downloads.sourceforge.net/project/ubuntuzilla/mozilla/apt all main

#backports
#deb http://ftp.debian.org/debian/ buster-backports main non-free contrib
deb http://files.freeswitch.org/repo/deb/debian-release bullseye  main


- Were there any non-Debian packages installed before the upgrade?  If
   so, what were they?
   
   Just freeswitch - not an issue


- Did any packages fail to upgrade?

Only rkhunter.. had a problem

- Were there any problems with the system after upgrading?

Yes

Further Comments/Problems:

- samba broke - looks like support for a simple workgroup share is now gone - 
wish there had been some warning.



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1003408: ITS: manpages-hu by transferring it to manpages-l10n

[Helge Kreutzmann]

Package: manpages-hu
Version: 20010119-7
Severity: important
Tags: upstream
X-Debbugs-Cc: Laszlo Boszormenyi (GCS) 

I intend to salvage manpages-hu as per developer reference 5.12.
Rationale:

1. The package content is severily outdated. The last update related
   to content was Sun, 19 Feb 2006 (nearly 16 years ago).

2. There are two open bugs without maintainer response:
   #988584 (important, was serious) - According to DD in response this
   can be resolved by updating the translation base (see 1.)
   #856007 (normal) - Easy to fix, requested by a DD Fri, 24 Feb 2017
   (almost 5 years ago)

3. manpages-l10n (see below) contains a constantly updated base for
   translations (in sync with both Debian Unstable and Debian Stable),
   ensuring that only current translated text is shown. If paragraphs
   are updated (but not the translation), then those paragraphs are in
   english rather than outdated. If too many paragraphs are outdated,
   then the translation is not delivered to end users (but can be of
   course updated by translators and later shipped to end users).

4. The last upload was almost a year ago.

5. The source for manpages-hu is no longer available.

6. manpages-l10n (upstream) carefully integrated all known hungarian
   translations and constantly maintains them at Debian Salsa (see
   also 3.)

Background on manpages-l10n:
manpages-l10n upstream integrates more and more languages using the
po4a framework (see 3. for a short explanation). In the past, old and
outdated manpage packages were changed over to manpages-l10n, e.g.
French, Italian, Spanish. manpages-l10n regularly (3 months) updates
its base, ensuring that the (translated) man pages closely sync to
those of the english version. Additional releases are done when the
Debian freeze occurs, so that stable is accurately represented.
Finally, backports are provided, so new translations flow into even
stable.

Intended salvage procedure:
The next (upstream) release of manpages-l10n is slated for February. I
will first upload another version *without* hungarian and then request
removal of this source package (and its associated binary packages).
Once this has been done, I'll upload *with* hungarian (and with an
appropriate version number), so that the binary package manpages-hu is
then shipped from manpages-l10n.

As I'm not a DD (but a DM), the exact timing depends on those of my
sponsor(s). But I will ensure that at least 21 days have passed since
this bug was filled.

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

Kernel taint flags: TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to de_DE.UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

manpages-hu depends on no packages.

manpages-hu recommends no packages.

Versions of packages manpages-hu suggests:
ii  man-db [man]  2.9.4-2

-- 
  Dr. Helge Kreutzmann deb...@helgefjell.de
   Dipl.-Phys.   http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
   Help keep free software "libre": http://www.ffii.de/


signature.asc
Description: PGP signature

Bug#1003401: ITP: libconvert-uu-perl -- Perl module for uuencode and uudecode

[Christophe Maudoux]

retitle 1003401 ITP: libconvert-uu-perl -- Perl module for uuencode and 
uudecode


owner 1003401 !

thanks



Hi,

I will take care of this package.

Cheers

--
Christophe Maudoux
Doctorant en cybersécurité
Ingénieur systèmes & réseaux
Mainteneur WebSSO LemonLDAP::NG 

Bug#1003249: libqt5webenginecore5: i386 baseline violation

[Dmitry Shachnev]

Hi!

On Fri, Jan 07, 2022 at 12:58:50AM +0100, NoSSE2 wrote:
> Dear Maintainer,
>
> I tried to start Konqueror on a fresh install of Debian by typing konqueror
> into LXTerminal, it doesn't start, just crashes all the time.
>
> It violates the i386 baseline by using SSE2 unconditionally, even if the host
> CPU doesn't support it (tested on a downclocked Athlon XP).
>
> I suggest that https://wiki.debian.org/SIMDEverywhere might be helpful in
> developing a patch, if it isn't just a compiler flag fix.
>
> If this issue/bug is unfixable, the package should depend on package
> sse2-support (i386 only).

Yes, it is unfixable.

Qt WebEngine is based on Chromium which requires SSE2 since 2014 [1] and
SSE3 since version 89 (2020) [2][3].

Qt WebEngine 5.15 is based on Chromium 87 so it does not require SSE3 yet,
but definitely requires SSE2. I will add a dependency on sse2-support.

[1]: https://codereview.chromium.org/197403004
[2]: https://bugs.chromium.org/p/chromium/issues/detail?id=1123353
[3]: 
https://docs.google.com/document/d/1QUzL4MGNqX4wiLvukUwBf6FdCL35kCDoEJTm2wMkahw/edit?usp=sharing

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#1003240: mlton: mlton_20210117+dfsg-3 cannot rebuild itself on hppa

[Matthew Fluet]

Although MLton does understand about running out of memory (when an `mmap`
request fails), on recent versions of Linux, I've observed that the OOM
killer will sometimes step in before a failing `mmap` request.  But, I
wouldn't think that that would manifest itself as a seg fault.  In any
case, I would think that 3G would be enough for a self compile; recent
builds on amd64-linux show a max live of 887K.


On Thu, Jan 6, 2022 at 3:33 PM Henry Cejtin  wrote:

> MLton understands about running out of memory, so it shouldn't just
> segfault.
> If it isn't too hard, could you try it with Linux overcommit turned off?
>
> On Thu, Jan 6, 2022 at 1:57 PM John David Anglin 
> wrote:
> >
> > Source: mlton
> > Version: 20130715-3
> > Severity: normal
> >
> > Dear Maintainer,
> >
> > Because of dependency problems mlton_20210117+dfsg-3 had to built
> > manually on hppa.  However, it seems mlton_20210117+dfsg-3 cannot
> > rebuild itself on hppa.
> >
> > See log:
> >
> https://buildd.debian.org/status/fetch.php?pkg=mlton=hppa=20210117%2Bdfsg-3=1641492022=0
> >
> > It fails with a reproducible segmentation fault.  I noticed the compiler
> > had allocated more than 2G at this point, so there was probably a memory
> > allocation issue.  hppa is a 32-bit architecture.
> >
> > Regards,
> > Dave Anglin
> >
> > -- System Information:
> > Debian Release: bookworm/sid
> >   APT prefers buildd-unstable
> >   APT policy: (500, 'buildd-unstable'), (500, 'unstable')
> > Architecture: hppa (parisc64)
> >
> > Kernel: Linux 5.16.0-rc8+ (SMP w/4 CPU threads)
> > Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
> > Shell: /bin/sh linked to /bin/dash
> > Init: systemd (via /run/systemd/system)
> >
>
>

Bug#1003213: locales-all: introduce locales-utf8 package?

[Simon McVittie]

On Sun, 09 Jan 2022 at 13:48:06 +0100, Aurelien Jarno wrote:
> On 2022-01-06 11:21, Simon McVittie wrote:
> > * install locales-all (this costs > 200M but ensures that all locales are
> >   available)
> > 
> > For "reasonably large" desktop and server systems, I wonder whether it
> > might be better to generate a subset of locales-all with just the UTF-8
> > locales that we recommend for general use, and install that by default?
> 
> Defining general use is something quite difficult. All languages and
> countries should be considered equally, so we could differentiate
> UTF-8 from non UTF-8 locales, but we should not make further selection.

Right, what I meant was: AIUI we recommend that all speakers of xx_YY
use the xx_YY.utf8 locale, as opposed to a legacy national encoding, so
we could (make it straightforward to) install all the UTF-8 locales
like en_GB.utf8 and none of the legacy national encodings like
en_GB.ISO-8859-15.

> That way of doing it would be fine from the desktop point of view (100M
> is not that much compared to a desktop environment). However we can't
> force the installation of locales-all-utf8 in d-i

I thought task-*-desktop could maybe pull it in?

> From the various discussion on IRC, we more or less concluded that the
> way to go is to have one locale package per language, like it's done in
> most other distributions. From there we could have task-$language
> depends on locales-$language, also simplifying the d-i side.
> 
> Would that work for your use case?

That would mean that UIs like gnome-control-center would still not be able
to offer to add (for example) a French locale on a system that had been
installed in German, unless either the user knows that they need to install
the French language pack first, or the UI grows distro-specific code to:

- know which languages would be candidates for being enabled if the
  appropriate language pack was installed
- ask PackageKit to install the necessary language pack when one of those
  locales was chosen

However, it's consistent with how e.g. Flatpak handles locales (there's one
locale extension per language code, so for example fr_FR and fr_CH go
together).

This would also allow avoiding a long-standing issue with Steam: some
Steam games assume that en_US.UTF-8 is always available (they're wrong,
and should be using C.UTF-8, but that's not portable), so the steam package
could gain a Recommends: locales-en to work around that.

> > locales-utf8 would probably also be enough for many locale-sensitive
> > packages' test suites.
> 
> Not sure about that. Test suites are the main reason why we had to
> revert the removal of non UTF-8 locales.

I suspect this might be a bit circular: the reason that upstreams want
to test support for legacy encodings, and the reason that we want to run
those tests instead of skipping them, is because distros like us still
(claim to) support those encodings, even though we no longer recommend
them.

smcv

Bug#1003399: After distribution upgrade many mails are "tainted" and not delivered

[Marc Haber]

On Sun, Jan 09, 2022 at 06:14:36PM +0100, karsten wrote:
> Am 09.01.22 um 18:07 schrieb Marc Haber:
> > Most information one finds on a search engine is outdated and maybe even
> > wrong. And the current information regading brand new software is often
> > not indexed yet.
> > 
> > >.ifdef _OPT_MAIN_ALLOW_INSECURE_TAINTED_DATA
> > > allow_insecure_tainted_data = yes
> > >.endif
> > 
> > This will only work as a temporary measure and will be removed in the
> > future. You should work on getting your configuration to work with the
> > tightened security features newer exims come.
> 
> Yes - the other possibility is to prevent upgrades of this package.

That is a decidedly bad idea. Exim is a huge suid binary (a design one
out never choose today, the concept was valid 25 years ago) and you need
security updates for that.

> But there are additional other problems like spamassasin does not work any 
> more,
> so the configuration must be updated in many kinds.

Spamassassin in YOUR configuration doesn't work any more. My systems
using spamassassin via exiscan-ACL have not even ridden a bump during
the upgrade.

> > If that are issues with Debian's default configuration please file bugs
> > so that we can fix them, if it's issues with your local configuration
> > you're on your own with that.
> 
> Is there a default configuration for a private virtual mail server on dynamic 
> IP's ?

Not that I am aware of. But if you roll yourself, you need to be able to
take care of it. I think there might be solutions that might be better
suited to your needs than Exim.

btw, this triggers me, as "virtual mail" does not have a definition, it
leaves like ten way to interpret the task at hand.

Greetings
Marc

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421

Bug#1003407: bitlbee-mastodon: new upstream release

[Reiner Herrmann]

Source: bitlbee-mastodon
Version: 1.4.4-1
Severity: wishlist

Dear maintainer,

a new upstream version of bitlbee-mastodon is available (1.4.5).

It was not detected by uscan because of new paths used by github.
This watch file fixes upstream version detection:

> version=4
> https://github.com/kensanata/bitlbee-mastodon/tags 
> .*/v?@ANY_VERSION@@ARCHIVE_EXT@

Kind regards,
  Reiner


signature.asc
Description: PGP signature

Bug#802212: Patch

[Jerome BENOIT]

Dear Chad, thanks for your report and your patches.
The issue will be fixed in package 2.3+ds-5.
Thanks for your patience, Jerome

On Sun, 27 Dec 2015 12:23:14 -0800 Chad Wallace  
wrote:


Here's another version of that patch...  with a free(dotdir) after
we're done with it.


--

C. Chad Wallace, B.Sc.
The Lodging Company
http://www.lodgingcompany.com/
OpenPGP Public Key ID: 0x262208A0



--
Jerome BENOIT | calculus+at-rezozer^dot*net
https://qa.debian.org/developer.php?login=calcu...@rezozer.net
AE28 AE15 710D FF1D 87E5  A762 3F92 19A6 7F36 C68B



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1000980: kubernetes: Please upgrade to golang-1.17

[Shengjing Zhu]

On Thu, Dec 2, 2021 at 12:33 PM Shengjing Zhu  wrote:
>
> Source: kubernetes
> Version: 1.20.5+really1.20.2-1
> Severity: important
> X-Debbugs-Cc: z...@debian.org
> Control: block 998747 by -1
>
> Dear Maintainer,
>
> As part of the effort to limit the number of Go compiler in the
> archive, please upgrade to golang-1.17.

Ping? kubernetes is the only one that still build-depends golang-1.15.

-- 
Shengjing Zhu

Bug#1003406: RFS: simple-scan/40.7-1 -- Simple Scanning Utility

[Jörg Frings-Fürst]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "simple-scan":

   Package name: simple-scan
   Version : 40.7-1
   Upstream Author : Robert Ancell 
   URL : https://gitlab.gnome.org/GNOME/simple-scan
   License : GPL-3+
   Vcs : https://jff.email/cgit/simple-scan.git
   Section : gnome

It builds those binary packages:

  simple-scan - Simple Scanning Utility

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

  https://mentors.debian.net/package/simple-scan/

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

  dget -x 
https://mentors.debian.net/debian/pool/main/s/simple-scan/simple-scan_40.7-1.dsc

or from

 git https://jff.email/cgit/simple-scan.git?h=release%2Fdebian%2F40.7-1



Changes since the last upload:

 simple-scan (40.7-1) unstable; urgency=medium
 .
   * New upstream release.
   * debian/copyright:
 - Add year 2022 to myself.
   * Declare compliance with Debian Policy 4.6.0.1 (No changes needed).
   * New .gitignore.



CU 
Jörg

-- 
New:
GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB  30EE 09F8 9F3C 8CA1 D25D
GPG key (long) : 09F89F3C8CA1D25D
GPG Key: 8CA1D25D


Jörg Frings-Fürst
D-54470 Lieser

git:  https://jff.email/cgit/


Threema: SYR8SJXB
Skype: joergpenguin
Telegram: @joergfringsfuerst


My wish list: 
 - Please send me a picture from the nature at your home.



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

Bug#1001555: openconnect: can't connect to server that use SSO SAML with protocol "anyconnect"

[Antonio]

I did the test indicated on the Gnome interface, I noticed that once you 
install the debug packages and updated the version of 
OpenConnect/Libopenconnect5 to 8.10-5 the VPN works and remain active.


For try, I removed debug packages and downgraded the others to version 
8.10-4, to return to the problem, but strangely it continued to work 
(while before, with the same OpenConnect version installed, it didn't work).


As for Plasma/KDE, the desktop that I use, I opened a bug on Bugzilla 
https://bugs.kde.org/show_bug.cgi?id=448153



Il 05/01/22 17:54, Luca Boccassi ha scritto:

On Mon, 2022-01-03 at 20:08 +0100, Antonio wrote:

Dear maintainer,
I tried the updated version of OpenConnect.

---

  From GNOME interface:

- When the VPN is active, the form for the insertion of username and
password appears.
- Provide access credentials I receive notification from Microsoft
Authenticator
- confirmed identity via authenticator, the "remain connected" form
appears and I reply "yes"

The page is then shown:

"Cisco AnyConnect Secure Mobility Client"
"You have successfully authenticated. You may now close this browser
tab"

Now the VPN should be active but if I try from terminal or browser I
can't access the VPN network, despite successfully executed all the
steps.

If I close the browser page, as indicated, the network menu indicates
that the VPN is off.

Or rather, I think it's never started.

Journal reports: "Final Secrets Request Failed to Provide Sufficient
Secrets"

Strange - but not unexpected, these VPNs are terrible. I have reports
of users with AnyConnect and other SAML providers working fine with the
latest version.
There also was an unfixed issue with some newer AnyConnect servers that
was fixed with yesterday's upload, try and have a look if that makes a
difference.

If it doesn't, it sounds like you need to debug it to figure out where
it's going wrong - you can run the auth dialog in gdb and walkthrough
the code as such:

- install network-manager-openconnect-dbgsym network-manager-
openconnect-gnome-dbgsym openconnect-dbgsym libopenconnect5
-dbgsym
- create a local script somewhere with something like:

#!/bin/bash
gdbserver localhost:12345 /usr/lib/NetworkManager/nm-openconnect-auth-dialog $@

- edit temporarily /usr/lib/NetworkManager/VPN/nm-openconnect-
service.name and change auth-dialog to point to the script above

Then you'll be able to connect with gdb and debug as usual after
activating the VPN via the Gnome GUI.


---

  From KDE interface:

- same configuration

- I can now select correct AUTHGROUP

However, when I click on the "Access" button, the form does not
appear
to insert the credentials.

Unlike the GNOME interface, the log log continues to report the
message
"No SSO Handler".

Thank you,
Antonio

As the message implies, KDE is not supported, nobody has done the work
to make it happen.


Il 31/12/21 01:34, Luca Boccassi ha scritto:

Control: tag -1 pending

Hello,

Bug #1001555 in openconnect reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/debian/openconnect/-/commit/145c237a574d06f348d0147390f33b5993e5b52d

---
-
Update SAML patch

Correctly detect termination on Anyconnect + Google SAML.
Also restore backward compatibility for legacy CLI based workflow.

Closes: #1001555

Gbp-Dch: full
---
-

(this message was generated automatically)

Bug#970129: xplanet: diff for NMU version 1.3.0-5.2

[Steve McIntyre]

On Sun, Jan 09, 2022 at 12:43:23PM +0100, p...@debian.org wrote:
>Control: tags 970129 + pending
>
>
>Dear maintainer,
>
>I've prepared an NMU for xplanet (versioned as 1.3.0-5.2) and
>uploaded it to DELAYED/15. Please feel free to tell me if I
>should delay it longer.

No, that's fine- thanks for helping to improve Debian here!

I've not been able to spend much time on xplanet lately, so I'd be
happy to pass it over to you for maintenance if you like?

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"Yes, of course duct tape works in a near-vacuum. Duct tape works
 anywhere. Duct tape is magic and should be worshipped."
   -― Andy Weir, "The Martian"

Bug#998897: python3-sip: Thread 1 "python" received signal SIGSEGV, Segmentation fault.

[Dmitry Shachnev]

Hi Artem, and sorry for delayed reply.

On Tue, Nov 09, 2021 at 07:57:17PM +0300, Artem Rusanov wrote:
> Dear Maintainer,
>
> Sometimes during startup (depend on python code, comment line can affect
> this) my software crashes with segmentation fault in python-sip.

sip4 is no longer developed.

Please try with sip6 (which is available in Debian testing/unstable) or sip5
(which is available in bullseye/stable).

If the issue still happens with one of these versions, I suggest you to
report a bug to upstream mailing list (better with a minimal example):

https://www.riverbankcomputing.com/mailman/listinfo/pyqt

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#1003340: qa.debian.org: Please agree with salsa on the lintian version to use

[Felix Lechner]

Hi,

On Sun, Jan 9, 2022 at 8:51 AM Samuel Thibault  wrote:
>
> But what is "latest version"?

The latest version is the most recent commit on the 'master' branch in
our public repository. [1] We found it is the fastest way to bring bug
fixes to the community.

Bug fixes can often be verified on our website within days. [2] Our
use of the SemVer patch digit [3] is explained on each tag page. [4]
You can also have a look at this message. [5]

The name of the 'master' branch is subject to change. We already use
the more neutral 'history' in most of our other repos. [6][7][8]

Kind regards
Felix Lechner

[1] https://salsa.debian.org/lintian/lintian
[2] https://lintian.debian.org/
[3] https://semver.org/
[4] for example, https://lintian.debian.org/tags/bad-whatis-entry
[5] https://lists.debian.org/debian-lint-maint/2021/09/msg00148.html
[6] https://salsa.debian.org/lintian/detagtive
[7] https://salsa.debian.org/lintian/kickoff
[8] https://salsa.debian.org/lintian/emacs-lintian

Bug#850418: Lack of documentation (manpage, offline doc)

[Yadd]

Control: fixed -1 1.4.3+~3.0.1-1

manpage provided since 1.4.3+~3.0.1-1

Bug#1003399: After distribution upgrade many mails are "tainted" and not delivered

[karsten]

Hello Marc,

Am 09.01.22 um 18:07 schrieb Marc Haber:

No - sorry - why should someone search and find important informations in other 
package News?


The same information is also in
/usr/share/doc/exim4-daemon-heavy/NEWS.Debian.gz, both binaries are
built from the same source. Most Debian systems are configured to show
this information prominently on package upgrade, and it is also a good
idea to look in the package docs and the BTS before asking a search
engine.


you are right - this is a good idea.


Most information one finds on a search engine is outdated and maybe even
wrong. And the current information regading brand new software is often
not indexed yet.


   .ifdef _OPT_MAIN_ALLOW_INSECURE_TAINTED_DATA
allow_insecure_tainted_data = yes
   .endif


This will only work as a temporary measure and will be removed in the
future. You should work on getting your configuration to work with the
tightened security features newer exims come.


Yes - the other possibility is to prevent upgrades of this package.
But there are additional other problems like spamassasin does not work any more,
so the configuration must be updated in many kinds.


If that are issues with Debian's default configuration please file bugs
so that we can fix them, if it's issues with your local configuration
you're on your own with that.


Is there a default configuration for a private virtual mail server on dynamic 
IP's ?

Cheers
karsten

Bug#1002647: marble-qt: marble does not show legend of maps any more

[Klaumi Klingsporn]

Am / On Sun, 26 Dec 2021 17:18:49 +0100
schrieb / wrote Klaumi Klingsporn :

> in the new version marble as well as marble-qt doesn't
> show anything in the legend tab although there are
> legend-symbols in the maps-subdirectories for the maps
> and descriptions in the dgml-files.

Only to let you know.
I think the problem is that marble has to be compiled
against qtwebengine5-dev to make the legend-function work.

At least when I built the latest version of marble (21.12.1)
today using the control file from the Ubuntu packages which
includes qtwebengine5-dev as Build-Depends all went well
and die legends work again in marble.

If anybody has need for them, you find my packages at:
apt.klaumikli.de/testing

Thanks for maintaining marble for Debian!

Klaumi

---
Klaus-Michael Klingsporn
mail: klaumi...@gmx.de
web: www.klaumikli.de

Bug#886617: Please package version 2.1

[Daniel Leidert]

unblock 886617 by 936212
block  936212 by 886617
block 1003405 by 886617
retitle 886617 python-pmw: Please package version 2.1 and include Python 3 
support
thanks

Hi,

there is finally a bkchem version ported to python 3 and it has already been
packaged. However, it requires the update pf pmw to version 2.1
(https://pypi.org/project/Pmw-py3/).

This would close a lot of open bug reports, and maybe even allow the final
removal of python2.

Should we prepare an NMU?

Regards, Daniel
-- 
Regards,
Daniel Leidert  | https://www.wgdd.de/
GPG-Key RSA4096 / BEED4DED5544A4C03E283DC74BCD0567C296D05D
GPG-Key ED25519 / BD3C132D8B3805D1808123AB7ACE00941E338C78

https://www.fiverr.com/dleidert
https://www.patreon.com/join/dleidert


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

Bug#1003399: After distribution upgrade many mails are "tainted" and not delivered

[Marc Haber]

On Sun, Jan 09, 2022 at 05:40:17PM +0100, karsten wrote:
> Am 09.01.22 um 17:15 schrieb Marc Haber:
> 
> > > The research of this error message leads to a big discussion without an 
> > > solution here:
> > 
> > Did the research not lead you to the documentation in the package, such
> > as /usr/share/doc/exim4-base/NEWS.Debian.gz, which explains the issue?
> 
> No - sorry - why should someone search and find important informations in 
> other package News?

The same information is also in
/usr/share/doc/exim4-daemon-heavy/NEWS.Debian.gz, both binaries are
built from the same source. Most Debian systems are configured to show
this information prominently on package upgrade, and it is also a good
idea to look in the package docs and the BTS before asking a search
engine.

Most information one finds on a search engine is outdated and maybe even
wrong. And the current information regading brand new software is often
not indexed yet.

>   .ifdef _OPT_MAIN_ALLOW_INSECURE_TAINTED_DATA
>allow_insecure_tainted_data = yes
>   .endif

This will only work as a temporary measure and will be removed in the
future. You should work on getting your configuration to work with the
tightened security features newer exims come.

If that are issues with Debian's default configuration please file bugs
so that we can fix them, if it's issues with your local configuration
you're on your own with that.

Greetings
Marc

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421

Bug#1003399: After distribution upgrade many mails are "tainted" and not delivered

[karsten]

Hello Marc,

Am 09.01.22 um 17:15 schrieb Marc Haber:


The research of this error message leads to a big discussion without an 
solution here:


Did the research not lead you to the documentation in the package, such
as /usr/share/doc/exim4-base/NEWS.Debian.gz, which explains the issue?


No - sorry - why should someone search and find important informations in other 
package News?


Please feel free to re-open this bug if reading NEWS.Debian doesn't
help.


The 'trick' with $local_part_data did not help and only leads to more other 
problems ...

But your hint rescues the day - thank you very much!

For other desperate exim users - add to the exim4.conf configuration:

  .ifdef _OPT_MAIN_ALLOW_INSECURE_TAINTED_DATA
   allow_insecure_tainted_data = yes
  .endif


When there is the time the other hints will be used for a correction to the new 
configuration challenge.
You already closed the bug that is only "new features" - thanks

Best regards
karsten

Bug#1003405: misses dependency on python3-pmw

[Daniel Leidert]

Source: bkchem
Version: 0.14.0~pre4+git20211228-1
Severity: grave

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

bkchem requires the pmw module. But it ships neither a dependency on
python3-pmw, nor has python3-pmw been uploaded to the archive yet.

There is a working module though:
https://pypi.org/project/Pmw-py3/

Regards, Daniel

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

Kernel: Linux 5.15.0-2-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.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

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEvu1N7VVEpMA+KD3HS80FZ8KW0F0FAmHbFIQACgkQS80FZ8KW
0F2tNA/9Fzmqc73T5VYN11Nt6Le+DG/+XH6JiH6q5oKNiw6NglO3ZI2h47NcfKVn
c7R6LwINax/Dzb721IQJAeK6yQpnsMA+twAu0WCKbTsM7R1AgqP5qjE+8CBBwpby
zCRo/RhA0nJZO+nbzdCVF/we2+X318oR3j9BA9zjavWCFBwyz6WTySPvRCjm4KPX
vzhWJigbak32CF3D2eKFUUlLph/UcuIFLKMJtKrC3jWC/PpJX6hV/rUqRZzLjV3q
Zz5jPqidtHovGoq/UGq3bKoxVkuj+dfnsbjT0pLUb2zDn7ct8sGWnBJqyPnU53Cb
GD8mN1UWS2cLiiFzuySWns4O/z+bt44RJpakTd7vr1JZMKbzNP9WOE9AwsYMk3Aa
8YEzMwQ7736hINQnXBRdTHAUxR00SxOvzBLrXPeOVo7h99IZdZ7bmPD9A3bcXVoN
Ub9hu47LiUIODjyeu5zbmhR1asVA3BMGbE3KYcasFwTlVapRjGscyau1XEUuDGN9
D5wGT+EdHvoB8eGZJ8mDA6TaHz+VlRjFBuyG772oboCiYIYsFmucwPIe6CdR8rfn
2cR/gtvhDvxTdMrC+7AuOMRgSvHwg5yxct6Eh2OS3fVPIoUdgTL3hPHkXp+PCTnG
7m1hq/ciZPMm/7uPFe7puqgImVz5zPB0kNHgNoM3rx57s0gtmIE=
=qWAi
-END PGP SIGNATURE-

Bug#1002692: need permanent tracker for rakudo

[Sebastian Ramacher]

On 2021-12-27 15:53:09 +0100, Dominique Dumont wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> 
> Hi
> 
> I'm currently changing the way Raku (aka Perl6) modules are built.
> 
> The build process involves creating pre-compiled files (a bit like pyc
> files for Python). These files used to be created at installation time.
> 
> I'm experimenting with package perl6-readline to perform the
> pre-compilation at build time.
> 
> The main drawback is that pre-compiled files depend on the version of
> rakudo that did the compilation. All Raku modules must be rebuilt when
> a new verions of rakudo is built.
> 
> Like Perl, Rakudo now provides a virtual package with an api version.
> For instance:
> 
>Provides: raku-api-2021.09
> 
> And perl6-readline depends on raku-api-2021.09
> 
> To trigger the rebuild of Raku modules, I'd like you to set up a
> permanent tracker with the following Ben file:
> 
> title = "Rakudo";
> is_affected = .depends ~ /^raku-api-/;
> is_good = !.edos-debcheck ~ /uninstallable/;
> is_bad = .edos-debcheck ~ /uninstallable/;
> 
> 
> Is it possible ?

The tracker is now available at
https://release.debian.org/transitions/html/rakudo.html

Cheers

> 
> All the best
> 
> Dod
> 

-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#1003340: qa.debian.org: Please agree with salsa on the lintian version to use

[Samuel Thibault]

Felix Lechner, le dim. 09 janv. 2022 08:15:27 -0800, a ecrit:
> On Sun, Jan 9, 2022 at 7:36 AM Samuel Thibault  wrote:
> >
> > we cannot
> > write lintian overrides files that avoid red flags on both platforms.
> 
> Lintian's latest version will always be authoritative.

But what is "latest version"? The version showing up on links of

https://qa.debian.org/developer.php?email=sthibault%40debian.org

is 2.114.123, which is not even released!

> In addition, please note that the format for override files is changing. [1]

Yes, that's the problem at stake: if I teach my packages about the new
format, the QA page is happy, but then salsa's CI is not. And conversely
if I don't.

Samuel

Bug#1002372: marked as done (nbconvert: FTBFS: AttributeError: module 'mistune' has no attribute 'BlockGrammar')

[Sandro Tosi]

Gordon,

>[ Gordon Ball ]
>* Vendor mistune 0.8.4 due to incompatibility with mistune 2
>  (Closes: #1001283, #1002372)

i think you closed *all* the mistune bugs by doing this. can you
reopen the ones not affecting nbconvert so that we dont lose track of
them?

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

Bug#1002681: transition: ocaml

[Sebastian Ramacher]

Control: forwarded -1 
https://release.debian.org/transitions/html/ocaml-4.13.1.html
Control: tags -1 moreinfo

On 2021-12-27 09:35:59 +0100, Stéphane Glondu wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> X-Debbugs-Cc: debian-ocaml-ma...@lists.debian.org
> 
> Dear Release Team,
> 
> I've updated ocaml to 4.13.1 (released on 2021-10-01) and uploaded to
> experimental. It builds on all release architectures, and most of
> ports as well.
> 
> Version currently in unstable is 4.11.1 (released on 2020-09-01).
> 
> I've tried to rebuild all related packages with the new version, and
> the breakage is minimal:
> 
>   https://ocaml.debian.net/transitions/ocaml-4.13.1/
> 
> A new version of ocaml-odoc is required, and it depends on a package
> (ocaml-odoc-parser) which is in the NEW queue. When it is accepted, I
> think we can proceed to updating OCaml in unstable.

Please remove the moreinfo tag once ocaml-odoc-parser has been accepted.

Cheers

> 
> 
> Ben file:
> 
> title = "ocaml";
> is_affected = .depends ~ "ocaml.*4\.11\.1" | .depends ~ "ocaml.*4\.13\.1";
> is_good = .depends ~ "ocaml.*4\.13\.1";
> is_bad = .depends ~ "ocaml.*4\.11\.1";
> 
> 
> Cheers,
> 
> -- 
> Stéphane

-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#1003404: debian-i18n: Dead keys functionality associated to some keyboards is not working

[Ramiro Arias-Amaya]

Package: debian-i18n
Severity: important
Tags: l10n
X-Debbugs-Cc: ramiroar...@usa.com

Dear Maintainer,

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

   * What led up to the situation?
I have four computers, as follows:
PC 1. Debian 11 32-bit. US keyboard. Setup as English (US, intl., with dead
keys)
PC 2. Debian 11 32-bit. Spanish keyboard. Setup as Spanish (dead tilde)
PC 3. Debian 11 64-bit. Spanish keyboard. Setup as Spanish (dead tilde)
PC 4. MX-21 Linux 32-bit (based on Debian). Spanish keyboard. Setup as Spanish
(dead tilde)

   * What was the outcome of this action?
Of the four computers described above only PC 3 with Debian 11 64-bit works as
expected.

   * What outcome did you expect instead?
What I expect is dead tilde works as it did from several years ago.

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

Bug#1003403: maven: Warning running mvn about which beeing deprecated

[Alberto Fernández Martínez]

Package: maven
Version: 3.6.3-5
Severity: normal
X-Debbugs-Cc: inf...@gmail.com

Dear Maintainer,

When running mvn command, a warning message shows:

/usr/bin/which: this version of `which' is deprecated; use `command -v' in 
scripts instead.


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

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

Versions of packages maven depends on:
ii  default-jre-headless [java7-runtime-headless] 2:1.11-72
ii  libjansi-java 1.18-1
ii  libmaven3-core-java   3.6.3-5
ii  libwagon-file-java3.3.4-1
ii  libwagon-http-shaded-java 3.3.4-1
ii  openjdk-10-jre-headless [java7-runtime-headless]  10.0.2+13-2
ii  openjdk-11-jre-headless [java7-runtime-headless]  11.0.13+8-1
ii  openjdk-17-jre-headless [java7-runtime-headless]  17.0.1+12-1
ii  openjdk-7-jre-headless [java7-runtime-headless]   7u101-2.6.6-1
ii  openjdk-8-jre-headless [java7-runtime-headless]   8u312-b07-1
ii  openjdk-9-jre-headless [java7-runtime-headless]   9.0.4+12-4
ii  oracle-java8-jdk [java7-runtime-headless] 8u151

maven recommends no packages.

maven suggests no packages.

-- no debconf information

Bug#1003340: qa.debian.org: Please agree with salsa on the lintian version to use

[Felix Lechner]

Hi,

On Sun, Jan 9, 2022 at 7:36 AM Samuel Thibault  wrote:
>
> we cannot
> write lintian overrides files that avoid red flags on both platforms.

Lintian's latest version will always be authoritative.

In addition, please note that the format for override files is changing. [1]

Please remember, however, that Lintian is not your boss. Credit for
that critical insight goes to D. Bremner—thank you!

On a side note, Salsa has more serious issues when running Lintian
jobs. [2][3][4]

Thank you for using Lintian!

Kind regards
Felix Lechner

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1003272#10
[2] https://bugs.debian.org/973313
[3] https://salsa.debian.org/salsa/support/-/issues/277
[4] https://salsa.debian.org/lintian/lintian/-/merge_requests/367#note_281411

Bug#1003402: friendly-recovery: Friendly-recovery dont start, Screan hangs.

[Andy]

Package: friendly-recovery
Version: 0.2.42
Severity: important
X-Debbugs-Cc: online-...@web.de

Dear Maintainer,

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

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

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


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

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

Versions of packages friendly-recovery depends on:
ii  systemd-sysv  247.3-6
ii  whiptail  0.52.21-4+b3

Versions of packages friendly-recovery recommends:
ii  gettext-base  0.21-4

friendly-recovery suggests no packages.
friendly-recovery: Friendly-recovery dont start, Screan hangs.

Bug#992214: RFS: nemo-compare/5.0.1-1 [ITP] -- Context menu comparison extension for Nemo file manager

[Fabio Fantoni]

Il 25/12/2021 19:36, Fabio Fantoni ha scritto:
Hi, here I don't understand why title refer to nemo-compare but RFS 
was opened about nemo-audio-tab


In any cases some useful infos:

upstream have all nemo extensions in one repository: 
https://github.com/linuxmint/nemo-extensions


major of bugfix versions are specific to one or few extensions near 
always so the correct check for a new version of specific extension is 
check if its package is released on mint repository, looking 
nemo-compare:



version=4
http://packages.linuxmint.com/pool/backport/n/nemo-compare/ \
nemo-compare_([\d.]+)%2b[\w\d]+\.tar\.gz


is correct

about nemo extensions upload and maintain all them in debian not worth 
it, for the 2 only maintainer actually active in it (joshua and me), 
and more with actual upload difficulties that make waste time :(


nemo-compare seems to me one of the few that worth upload and keeping

major of commits are only version bump so also less upload needed in 
future: 
https://github.com/linuxmint/nemo-extensions/commits/master/nemo-compare 
but before first upload of it I think is better update to 5.2.1 as it 
add one small fix, @Joshua can you do it please?


I did a fast change to d/watch 
(https://salsa.debian.org/cinnamon-team/nemo-compare/-/commit/43230d19fcc9faf27c387d660ad9f2e35397460d) 
for check github tags and search both "x.y.z" (new version for all 
extensions) and "nemo-compare-x.y.z" (specific bugfix version only for 
it) and from some fast tests seems ok, @Bastian: is it good now?




OpenPGP_signature
Description: OpenPGP digital signature

Bug#1003401: RFP: libconvert-uu-perl -- Perl module for uuencode and uudecode

[Bas Couwenberg]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: debian-p...@lists.debian.org

* Package name: libconvert-uu-perl
  Version : 0.5201
  Upstream Author : Andreas Koenig 
* URL : https://metacpan.org/release/Convert-UU
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : Perl module for uuencode and uudecode

Convert::UU exports uuencode & uudecode functions.

uuencode() takes as the first argument a string that is to be
uuencoded. Note, that it is the string that is encoded, not a
filename. Alternatively a filehandle may be passed that must be
opened for reading. It returns the uuencoded string including
"begin" and "end". Second and third argument are optional and
specify filename and mode. If unspecified these default to
"uuencode.uu" and 644.
 
uudecode() takes a string as argument which will be uudecoded. If
the argument is a filehandle this handle will be read instead. If it
is a reference to an ARRAY, the elements are treated like lines that
form a string. Leading and trailing garbage will be ignored. The
function returns the uudecoded string for the first begin/end pair.
In array context it returns an array whose first element is the
uudecoded string, the second is the filename and the third is the
mode.


This package is required for pdl and should be maintained within the Perl team.

Bug#934926: [Pkg-zsh-devel] Bug#934926: update (overridding of default fpath causes uncessary complexity and pain for software providing zsh completions)

[Axel Beckert]

Hi Frank,

thanks a lot for trying to wrap the history of all these directories!
I wasn't aware of this non-obvious timeline with Debian having added
vendor-* directories before upstream last updated their search paths.

> The reason  this doesn't  get added  on Debian right  now is  that we're
> still  setting ‘--enable-site-fndir=/usr/local/share/zsh/site-functions’
> explicitly. Dropping this setting would change this.

I see.

> Since  Debian's ‘vendor-*’  directory handling  predates this  by years,
> changing this,  effectively adding  a second path  for the  same purpose
> seems inelegant, since it adds redundancy where none is needed.

I agree here.

> This however, sucks:
> 
> % apt-file search usr/share/zsh/site-functions/ | wc -l
> 30
> 
> Because that is thirty functions that will not work.

Ack.

> When we  added the ‘vendor-*’ stuff,  we filed bug reports  for packages
> that  tried this,  because  even  back then,  it  wouldn't have  worked,
> because site-functions always was in /usr/local with Debian's zsh.
> 
> That resulted in this:
> 
> % apt-file search vendor-completions | wc -l
> 166

This is clearly the majority. (IMHO) Good.

> I am  not sure if  there's an elegant way  to resolve this,  because the
> ‘vendor-*’ directories  are the documented  way for zsh packages  to add
> functions for more than a decade. I  don't think dropping them is a good
> idea, because it would break backward compatibility. And as I said, just
> adding the second  --prefix based site-functions entry  would litter the
> system by added multiple destinations for the same purpose.
> 
> Maybe there's a way to add a  lintian check for the installation path of
> zsh function files in Debian packages.

Good idea! I can work on this.

> With that, we could add the prefix based site-functions directory,
> but deprecate its use.

Ack, that thought came to me also after having read your mail
half-through. It though has the danger that some so far not active
plugins will suddenly start to work. So we add least need to
debian/zsh.bug-script.

Currenty it only checks for packages that ship files in
/usr/share/zsh/vendor-completions/ and
/usr/share/zsh/vendor-functions/.

> That way, packages that disrespect the zsh package's policy still
> work, while keeping the possibility of a clean system, in case all
> package adhere to the policy. We could file a bunch of bugs for the
> packages that are currently using /usr/share/zsh/site-functions
> right now.

Debian prefers lintian warnings over mass bug filing. Mass bug filing
needs to be discussed on the debian-devel mailing list first.

What I now still wonder to (hopefully) address Joey's issue:

Is there a way to build the Debian zsh (respectively probably the
zsh-dev) package in a way so that locally installed Zsh extensions get
cleanly installed into /usr/local/ while Debian packages still install
stuff to /usr/ (preferably these vendor-* directories)?

I wonder if something like a dh_zsh helper could help here (i.e. for
the vendor-* directory part) as well.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE