date:20211008

On 2021-02-26, Vagrant Cascadian wrote:
> Several packages use fop (which uses xmlgraphics-commons) to generate
> PDF files in Debian packages, but the resulting PDF files have embedding
> timestamps. This was partially fixed in fop:
>
>   https://bugs.debian.org/978499
>
>
> Unfortunately, in some cases the timezone information is still embedded
> due to how xmlgraphics-commons embeds the date and timezone:
...
> The attached patch fixes this by adding setting the timezone to UTC when
> the SOURCE_DATE_EPOCH environment variable is defined.  This patch is
> just a rough draft; would appreciate improvements to it from someone who
> knows their way around java better!
>
>
> This seems to fix the embedded timestamp/timezone issues in several of
> the packages listed in:
>
>   
> https://tests.reproducible-builds.org/debian/issues/unstable/timestamps_in_pdf_generated_by_apache_fop_issue.html

This should fix reproducibility issues in several other packages; is
there anything else I can do to help getting this fix into Debian?


live well,
  vagrant

> From 2146f4a44fbee1e3aef12e56ae3d904e793090cd Mon Sep 17 00:00:00 2001
> From: Vagrant Cascadian 
> Date: Fri, 26 Feb 2021 19:10:10 +
> Subject: [PATCH] XMPSchemaAdapter.java: Use UTC timezone when
>  SOURCE_DATE_EPOCH is set.
>
> SOURCE_DATE_EPOCH specifies the timestamp, but needs to be rendered in
> UTC timezone to ensure reproducible builds.
>
> https://reproducible-builds.org/docs/source-date-epoch/
>
> This is a follow-up to https://bugs.debian.org/978499 in apache fop,
> as there is no way for fop itself to pass the timezone information for
> some values.
> ---
>  .../java/org/apache/xmlgraphics/xmp/XMPSchemaAdapter.java| 5 +
>  1 file changed, 5 insertions(+)
>
> diff --git a/src/main/java/org/apache/xmlgraphics/xmp/XMPSchemaAdapter.java 
> b/src/main/java/org/apache/xmlgraphics/xmp/XMPSchemaAdapter.java
> index 9a41eba..19811a8 100644
> --- a/src/main/java/org/apache/xmlgraphics/xmp/XMPSchemaAdapter.java
> +++ b/src/main/java/org/apache/xmlgraphics/xmp/XMPSchemaAdapter.java
> @@ -157,6 +157,11 @@ public class XMPSchemaAdapter {
>   * @return the formatted date
>   */
>  public static String formatISO8601Date(Date dt) {
> +// https://reproducible-builds.org/docs/source-date-epoch/
> +String source_date_epoch = System.getenv("SOURCE_DATE_EPOCH");
> +if (source_date_epoch != null) {
> +return formatISO8601Date(dt, TimeZone.getTimeZone("Etc/UTC"));
> +}
>  return formatISO8601Date(dt, TimeZone.getDefault());
>  }
>  
> -- 
> 2.20.1


signature.asc
Description: PGP signature

Bug#995781: [Debian-med-packaging] Bug#995781: python-sqlsoup autopkgtest fails with SQLAlchemy 1.4.23+ds1-2

2021-10-08 Thread Étienne Mollier

Control: tag -1 upstream help
Control: forwarded -1 https://github.com/zzzeek/sqlsoup/issues/1

Hi Mike,

I flag the bug so it eventually draws more attention from people
still interested in sqlsoup.  Your program is still in use by at
least one other package: epigrass, so a removal from Debian
would be inconvenient.

Many thanks for your status!

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


signature.asc
Description: PGP signature

Bug#995425: Possible to get fix to 5.10?

2021-10-08 Thread ng

Hello,  I was just wondering if in the near future this fix will be 
available for linux in the stable branch.


Thanks.

Bug#995960: xnee: reproducible builds: embeds time and username in documentation

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

The username and build time is embedded in /usr/share/doc/xnee/xnee.ps.gz.

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

  %DVIPSSource:··TeX·output·2021.10.08:0802
vs.
  %DVIPSSource:··TeX·output·2022.11.11:1638

  %%CreationDate:·Fri·Oct··8·08:02:16·2021
vs.
  %%CreationDate:·Fri·Nov·11·16:37:50·2022
  
  %%For:·pbuilder1
vs.
  %%For:·pbuilder2

The attached patches fix this in debian/rules by setting
FORCE_SOURCE_DATE=1 to fix the DVIPSSource timestamp, and manually
adjusting the CreationDate and For headers in the .ps file directly.

With these patches applied, xnee should be reproducible on
tests.reproducible-builds.org!


Thanks for maintaining xnee!


live well,
  vagrant
From 52f8dc5c3e4986fdb349fd1fca46b786e01f3814 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Fri, 8 Oct 2021 23:41:00 +
Subject: [PATCH 1/2] debian/rules: Fix date im embedded xnee.ps.

Export FORCE_SOURCE_DATE=1 to get texlive to respect
SOURCE_DATE_EPOCH, which fixes the embedded timestamp in DVIPSSource
in xnee.ps.

Adjust the "CreationDate" header in xnee.ps to use the date from
debian/changelog instead of the current time.
---
 debian/rules | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/debian/rules b/debian/rules
index 0a30558..87800cc 100755
--- a/debian/rules
+++ b/debian/rules
@@ -10,8 +10,14 @@ DEB_CONFIGURE_EXTRA_FLAGS := --disable-gui --disable-gnome-applet \
 
 DEB_DH_STRIP_ARGS_libxnee0 = --dbgsym-migration="libxnee-dbg"
 
+# Ensure texlive respects SOURCE_DATE_EPOCH
+export FORCE_SOURCE_DATE=1
+
+CHANGELOG_DATE=$(shell dpkg-parsechangelog -Sdate)
+
 binary-install/xnee-doc::
 	sed -i s+$$(printf "\r")++g debian/xnee-doc/usr/share/info/xnee.info
-
+	# Fix embedded timestamp in .ps document
+	sed -i -e "s/%%CreationDate: .*/%%CreationDate: $(CHANGELOG_DATE)/g" debian/xnee-doc/usr/share/doc/xnee/xnee.ps
 clean::
 	rm -f examples/simple_bash.sh share/xnee.sh
-- 
2.30.2

From 2d3a9ea580a8dad7a7852255627e96aa9ebc6000 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Sat, 9 Oct 2021 00:07:30 +
Subject: [PATCH 2/2] debian/rules: Fix embedded username in xnee.ps

Adjust the "For" header in xnee.ps to specify "debian-build" instead
of the username.
---
 debian/rules | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/debian/rules b/debian/rules
index 87800cc..cd23542 100755
--- a/debian/rules
+++ b/debian/rules
@@ -19,5 +19,8 @@ binary-install/xnee-doc::
 	sed -i s+$$(printf "\r")++g debian/xnee-doc/usr/share/info/xnee.info
 	# Fix embedded timestamp in .ps document
 	sed -i -e "s/%%CreationDate: .*/%%CreationDate: $(CHANGELOG_DATE)/g" debian/xnee-doc/usr/share/doc/xnee/xnee.ps
+	# Fix embedded username in .ps document
+	sed -i -e "s/%%For: .*/%%For: debian-build/g" debian/xnee-doc/usr/share/doc/xnee/xnee.ps
+
 clean::
 	rm -f examples/simple_bash.sh share/xnee.sh
-- 
2.30.2



signature.asc
Description: PGP signature

Bug#995781: [Debian-med-packaging] Bug#995781: python-sqlsoup autopkgtest fails with SQLAlchemy 1.4.23+ds1-2

2021-10-08 Thread Étienne Mollier

Hi Michael,

Sorry to contact you like this, but since the forge disappeared
from bitbucket, we were keeping track of the pypi repository
instead, but it hasn't much moved since 2016 [0], and we don't
know where else to pull upgrades, report issues, etc.  Per
chance, do you still happen to work on sqlsoup on some public
location?

[0]: https://pypi.org/project/sqlsoup/

There is an impending upgrade of SQLAlchemy from version 1.3 to
1.4 in Debian Testing, but there are a couple of issues which
hold the process in Unstable.  One of them is that it introduces
regressions in our current version of sqlsoup, per Thomas' bug
report [1].

[1]: http://bugs.debian.org/995781

Excerpt from the migration test log [2], which basically consist
in running `python3 -c "import sqlsoup; print(sqlsoup)"`:

Testing with python3.9:
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python3/dist-packages/sqlsoup.py", line 11, in 
from sqlalchemy.orm.interfaces import MapperExtension, EXT_CONTINUE
ImportError: cannot import name 'MapperExtension' from 
'sqlalchemy.orm.interfaces' 
(/usr/lib/python3/dist-packages/sqlalchemy/orm/interfaces.py)

[2]: 
https://ci.debian.net/data/autopkgtest/testing/amd64/p/python-sqlsoup/15788076/log.gz

I begun to have a peek at the issue and rapidly found changelogs
for SQLAchemy [3], but once the first symptom is worked around,
I begin pull more hairy issues with relation to functions which
were apparently not documented on sqlalchemy side, while running
the unit test suite:

==
ERROR: test_bad_names (tests.test_sqlsoup.SQLSoupTest)
--
Traceback (most recent call last):
  File 
"/<>/.pybuild/cpython3_3.9_sqlsoup/build/tests/test_sqlsoup.py", 
line 105, in tes
t_bad_names
str(db.bad_names.c.query)
  File 
"/<>/.pybuild/cpython3_3.9_sqlsoup/build/sqlsoup.py", line 463, in 
__getattr__
return self.entity(attr)
  File 
"/<>/.pybuild/cpython3_3.9_sqlsoup/build/sqlsoup.py", line 460, in 
entity
return self.map_to(attr, tablename=attr, schema=schema)
  File 
"/<>/.pybuild/cpython3_3.9_sqlsoup/build/sqlsoup.py", line 366, in 
map_to
mapped_cls = _class_for_table(
  File 
"/<>/.pybuild/cpython3_3.9_sqlsoup/build/sqlsoup.py", line 133, in 
_class_for_table
selectable = expression._clause_element_as_expr(selectable)
AttributeError: module 'sqlalchemy.sql.expression' has no attribute 
'_clause_element_as_expr'

[3]: 
https://docs.sqlalchemy.org/en/14/changelog/changelog_14.html#change-6daf2f59ac2438ef9c8213e9ebeac157

(I wrote a patch, in attachment, to get there, but I am not too
happy about it, feels like just a crude workaround to hide the
first symptom.)

Please let us know if you have time to investigate this,
otherwise the sqlsoup package is at risk of being removed from
Debian Testing to avoid blocking further the SQLAlchemy upgrade.

Kind Regards,
-- 
Étienne Mollier 
Fingerprint:  8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
Sent from /dev/pts/2, please excuse my verbosity.
--- python-sqlsoup.orig/sqlsoup.py
+++ python-sqlsoup/sqlsoup.py
@@ -8,7 +8,8 @@
 from sqlalchemy.orm import scoped_session, sessionmaker, mapper, \
 class_mapper, relationship, session,\
 object_session, attributes
-from sqlalchemy.orm.interfaces import MapperExtension, EXT_CONTINUE
+from sqlalchemy.orm.interfaces import EXT_CONTINUE
+from sqlalchemy.orm.events import MapperEvents
 from sqlalchemy.sql import expression
 import sys
 
@@ -31,7 +32,7 @@
 
 """
 
-class AutoAdd(MapperExtension):
+class AutoAdd(MapperEvents):
 def __init__(self, scoped_session):
 self.scoped_session = scoped_session
 


signature.asc
Description: PGP signature

Bug#995955: ITP: ruby-warning -- Add custom processing for warnings

2021-10-08 Thread Sruthi Chandran

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

* Package name: ruby-warning
  Version : 1.2.1
  Upstream Author : Jeremy Evans
* URL : https://github.com/jeremyevans/ruby-warning
* License : Expat
  Description : Add custom processing for warnings
 ruby-warning adds custom processing for warnings, including the
 ability to ignore specific warning messages, ignore warnings
 in specific files/directories, include backtraces with warnings,
 treat warnings as errors, deduplicate warnings, and add
 custom handling for all warnings in specific files/directories.



signature.asc
Description: OpenPGP digital signature

Bug#995959: python3-pip: set_user_default.patch breaks --root option

2021-10-08 Thread Paul Boddie

Package: python3-pip
Version: 18.1-5
Severity: important

Dear Maintainer,

I spent a bit of time discovering the nature of this problem today.

I have come to rely on the --root option with "pip install" (or equivalent
python invocation) being a generally satisfactory way of installing packages
into an alternate filesystem root, this having been tested on Red Hat's
distribution offerings.

When attempting to use the --root option on Debian, instead of getting a
hierarchy like this...

  root/usr/local/...

...I get something like this:

  root/home/me/.local/...

For example:

  pip3 install --root XXX biopython

This produces...

  XXX/home/me/.local/lib/python3.7/site-packages/

At first, I thought that pip had changed its behaviour, as it often seems to,
with advice strewn across the Internet rapidly becoming obsolete. But it turns
out that the set_user_default.patch is actually responsible.

Obviously, there is a workaround for the behaviour introduced by this patch:
specifying --system or, perhaps, --no-user. But the former option is not
understood by other distributions or vanilla pip, so it is non-standard and
will break scripts. I guess that --no-user is meant to resolve this, although
the online documentation for recent pip versions doesn't seem to mention it,
and since the patch changes the behaviour of --no-user, I start to doubt if I
could rely on that, either.

Clearly, when specifying an installation root explicitly, the user is not
likely to be looking to reproduce their "local" package hierarchy: they want
to produce a genuine filesystem hierarchy, perhaps for populating chroots or
virtual machines, as the option is meant to. This patch breaks this expected
behaviour.

One could argue that the logic featured in the patch, testing for a virtualenv
or for root, is sufficient to detect whether someone is actually populating a
genuine filesystem hierarchy and that one might use fakeroot as an
unprivileged user to trigger the appropriate condition. While this might suit
some users, there is really no reason why an arbitrary user could not populate
usr/local in any given filesystem. Obstructing this makes the patch a vehicle
for some rather prescriptive policy, and it also obstructs other applications
that do not involve some form of virtualisation where the invoking user will
be the owner of the files that are created.

Please consider correcting the patch to make --root behave in a way that is
consistent with other distributions and the upstream software. Working with
Python packaging software is frustrating enough with the constant churn,
parade of tools, and often baroque (but flawed) solutions. Having
distributions (and hosting providers, on occasion) introduce additional,
unexpected complications makes the use of these tools even more stressful and
unpleasant.

I am sorry if this report causes anyone any inconvenience or is generally not
regarded as being helpful.

Paul


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

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

Versions of packages python3-pip depends on:
ii  ca-certificates20200601~deb10u2
ii  python-pip-whl 18.1-5
ii  python33.7.3-1
ii  python3-distutils  3.7.3-1

Versions of packages python3-pip recommends:
ii  build-essential 12.6
ii  python3-dev 3.7.3-1
ii  python3-setuptools  40.8.0-1
ii  python3-wheel   0.32.3-2

python3-pip suggests no packages.

-- no debconf information

Bug#995781: [Debian-med-packaging] Bug#995781: python-sqlsoup autopkgtest fails with SQLAlchemy 1.4.23+ds1-2

2021-10-08 Thread Mike Bayer

you woujld have better luck changing epigrass to use automap instead:   
https://docs.sqlalchemy.org/en/14/orm/extensions/automap.html



On Fri, Oct 8, 2021, at 5:08 PM, Étienne Mollier wrote:
> Control: tag -1 upstream help
> Control: forwarded -1 https://github.com/zzzeek/sqlsoup/issues/1
> 
> Hi Mike,
> 
> I flag the bug so it eventually draws more attention from people
> still interested in sqlsoup.  Your program is still in use by at
> least one other package: epigrass, so a removal from Debian
> would be inconvenient.
> 
> Many thanks for your status!
> 
> Have a nice day,  :)
> -- 
> Étienne Mollier 
> Fingerprint:  8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
> Sent from /dev/pts/2, please excuse my verbosity.
> 
> 
> *Attachments:*
>  * signature.asc

Bug#995738: Acknowledgement (perl: leak fixes for buster (perl 5.28.1))

2021-10-08 Thread Eric Wong

Note: Encode 3.15 contains a better fix which encompasses
encoding, too.  Encode 3.14 was broken (segfaults).
Please consider providing Encode 3.15, thanks.

Bug#995951: metar: update url to icao stations in metar(1) manual page

2021-10-08 Thread Étienne Mollier

Package: metar
Version: 20190227.1-1+b1
Severity: minor

Dear Maintainer,

When reading metar(1) manual, I came up with:

| OPTIONS
|metar requires at least one station identifier to run. A
|full list of ICAO stations is available for download at
|http://weather.noaa.gov/data/nsd_bbsss.txt.

So out of curiosity, I wanted to lookup the file in question,
but the weather.noaa.gov address seems to not be registered any
more:

$ host weather.noaa.gov
Host weather.noaa.gov not found: 3(NXDOMAIN)

I could locate information about my nearest station at the
following url, so I'm tempted to suppose this is the new
location of the file:

https://tgftp.nws.noaa.gov/data/nsd_bbsss.txt

Have a nice day,  :)
Étienne.

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

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

Versions of packages metar depends on:
ii  libc6 2.32-4
ii  libcurl4  7.74.0-1.3+b1

metar recommends no packages.

metar suggests no packages.

-- no debconf information

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


signature.asc
Description: PGP signature

Bug#995949: Missing cache directory

2021-10-08 Thread David Mandelberg


Package: liblemonldap-ng-common-perl
Version: 2.0.11+ds-4

localStorageOptions in /etc/lemonldap-ng/lemonldap-ng.ini points at 
/var/lib/lemonldap-ng/cache, which doesn't exist. In my apache 
error.log, I'm seeing:


Warn: mkdir /var/lib/lemonldap-ng/cache: Permission denied at 
/usr/share/perl5/Cache/FileBackend.pm line 222.


Also, I think upstream moved the default from 
/var/lib/lemonldap-ng/cache to /var/cache/lemonldap-ng in 
. 
But that directory doesn't exist either.


I think the issue is that 
https://salsa.debian.org/perl-team/modules/packages/lemonldap-ng/-/blob/master/debian/liblemonldap-ng-common-perl.dirs 
is missing the cache directory, but 
https://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/-/blob/v2.0/debian/liblemonldap-ng-common-perl.dirs 
has it upstream. (But I'm not very familiar with Debian packaging.)

Bug#995958: ITP: aleksis-core -- Free School Information System (Core)

2021-10-08 Thread Dominik George

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: aleksis-core
  Version : 2.0
  Upstream Author : The AlekSIS Team 
* URL : https://aleksis.org/
* License : EUPL-1.2
  Programming Lang: Python
  Description : Free School Information System (Core)

 AlekSIS is a web-based school information system (SIS) which can be used to
 manage and/or publish organisational subjects of educational institutions.
 .
 AlekSIS is a platform based on Django, that provides central funstions
 and data structures that can be used by apps that are developed and provided
 seperately. The AlekSIS team also maintains a set of official apps which
 make AlekSIS a fully-featured software solutions for the information
 management needs of schools.
 .
 By design, the platform can be used by schools to write their own apps for
 specific needs they face, also in coding classes. Students are empowered to
 create real-world applications that bring direct value to their environment.


The package shall be maintained within the Debian Edu Packaging Team, which
intends to ship it with the Debian Edu Pure Blend as management console.

-BEGIN PGP SIGNATURE-

iMAEARYKAGgWIQSk6zxRYJYchegBkTEK5VTlRg4b3QUCYWDL/DEaaHR0cHM6Ly93
d3cuZG9taW5pay1nZW9yZ2UuZGUvZ3BnLXBvbGljeS50eHQuYXNjGBxuYXR1cmVz
aGFkb3dAZGViaWFuLm9yZwAKCRAK5VTlRg4b3XskAP4m42U+GZlTQI0rN2P/p+5z
2xR38ENk6OOUM6eNSiTpRwD/dKU6WmXb4LCKbOdg4xWne5FoozOeNjUp9ibI1OpO
Ugs=
=ON11
-END PGP SIGNATURE-

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

2021-10-08 Thread Guilhem Moulin

Package: dbconfig-common
Version: 2.0.19
Severity: normal
Tags: patch

Dear Maintainer,

/usr/share/dbconfig-common/internal/* (and also 
/usr/share/dbconfig-common/dpkg/postrm)
call which(1), which is currently deprecated.

$ rgrep -E "^[^#]*which" /usr/share/dbconfig-common
/usr/share/dbconfig-common/internal/sqlite:which sqlite >/dev/null 2>&1
/usr/share/dbconfig-common/internal/sqlite:which sqlite3 >/dev/null 2>&1
/usr/share/dbconfig-common/internal/mysql:which mysqld >/dev/null 2>&1
/usr/share/dbconfig-common/internal/common:if ! which mysql 
>/dev/null; then
/usr/share/dbconfig-common/internal/common:if ! which psql 
>/dev/null 2>&1; then
/usr/share/dbconfig-common/internal/common:if ! which 
sqlite >/dev/null 2>&1; then
/usr/share/dbconfig-common/internal/common:if ! which 
sqlite3 >/dev/null 2>&1; then
/usr/share/dbconfig-common/internal/common:if ! which 
createdb >/dev/null; then
/usr/share/dbconfig-common/internal/common:if ! which 
dropdb >/dev/null; then
/usr/share/dbconfig-common/internal/common:if ! which 
createuser >/dev/null; then
/usr/share/dbconfig-common/internal/common:if ! which 
dropuser >/dev/null; then
/usr/share/dbconfig-common/internal/common:if ! which 
pg_dump >/dev/null; then
/usr/share/dbconfig-common/internal/common:if ! which 
mysqldump >/dev/null; then
/usr/share/dbconfig-common/dpkg/postrm:if which ucf >/dev/null 
2>&1; then

Some calls void the standard error but not all.  In particular, `which mysql 
>/dev/null;`
causes roundcube-core.postinst to spew

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

Here is a trivial patch following the suggested workaround from the
debianutils maintainer.

Thanks
Cheers,
-- 
Guilhem.
commit ea58773e4caa670e01414946e162e8afe65f75e1
Author: Guilhem Moulin 
Date:   Fri Oct 8 23:18:04 2021 +0200

Replace `which` calls with `command -v`.

Per which(1):

DEPRECATION
Since type and command -v were mandated by POSIX, this utility
is no longer useful for maintainer scripts and thus will be
removed from debianutils.

diff --git a/dbconfig-load-include b/dbconfig-load-include
index 9f1c4b8..b6a47de 100755
--- a/dbconfig-load-include
+++ b/dbconfig-load-include
@@ -191,7 +191,7 @@ EOF
 ;;
 
 php)
-	if ! which php > /dev/null; then
+	if ! command -v php >/dev/null; then
 		echo "error: php format but i can't find a php binary!" >&2
 		exit 1
 	fi
diff --git a/debian/dbconfig-common.postrm b/debian/dbconfig-common.postrm
index 512f8ab..0224e0d 100644
--- a/debian/dbconfig-common.postrm
+++ b/debian/dbconfig-common.postrm
@@ -4,7 +4,7 @@ set -e
 
 if [ $1 = "purge" ]; then
 	rm -f /etc/dbconfig-common/config || true
-  if which ucf >/dev/null 2>&1; then
+  if command -v ucf >/dev/null; then
 ucf -p /etc/dbconfig-common/config
 ucfr -p dbconfig-common /etc/dbconfig-common/config
   fi
diff --git a/doc/dbconfig-common.sgml b/doc/dbconfig-common.sgml
index fa309e8..4b477c6 100644
--- a/doc/dbconfig-common.sgml
+++ b/doc/dbconfig-common.sgml
@@ -242,7 +242,7 @@ fi
 
 if [ "$1" = "purge" ]; then
 rm -f yourconfigfile
-if which ucf >/dev/null 2>&1; then
+if command -v ucf >/dev/null; then
 ucf --purge yourconfigfile
 ucfr --purge yourpackage yourconfigfile
 fi
diff --git a/dpkg/postrm b/dpkg/postrm
index 05ebba4..80430e7 100644
--- a/dpkg/postrm
+++ b/dpkg/postrm
@@ -18,7 +18,7 @@ dbc_go(){
 elif [ "$dbc_command" = "purge" ]; then
 # remove the dbc configuration file
 rm -f /etc/dbconfig-common/$dbc_package.conf || true
-if which ucf >/dev/null 2>&1; then
+if command -v ucf >/dev/null; then
 cfg="/etc/dbconfig-common/$dbc_package.conf"
 ucf -p "$cfg" || true
 ucfr -p "$dbc_package" "$cfg"
diff --git a/examples/db-test-mysql-2.0/debian/postrm b/examples/db-test-mysql-2.0/debian/postrm
index 7e0af0d..85f1593 100644
--- a/examples/db-test-mysql-2.0/debian/postrm
+++ b/examples/db-test-mysql-2.0/debian/postrm
@@ -14,7 +14,7 @@ fi
 
 if [ "$1" = "purge" ]; then
 	rm -f /etc/db-test-mysql/debian-db.php
-	if which ucf >/dev/null 2>&1; then
+	if command -v ucf >/dev/null; then
 		ucf --purge /etc/db-test-mysql/debian-db.php
 		ucfr --purge db-test-mysql /etc/db-test-mysql/debian-db.php
 	fi
diff --git a/examples/db-test-mysql-2.1/debian/postrm b/examples/db-test-mysql-2.1/debian/postrm
index 7e0af0d..85f1593 100644
--- a/examples/db-test-mysql-2.1/debian/postrm
+++ b/examples/db-test-mysql-2.1/debian/postrm
@@ -14,7 +14,7 @@ fi
 
 if [ "$1" = "purge" ]; then
 	rm -f /etc/db-test-mysql/debian-db.php
-	if which ucf >/dev/null 2>&1; then
+	if command -v ucf >/dev/null; then
 		ucf --purge

Bug#995614: guile-3.0: Please build with --without-threads on alpha to fix FTBFS

2021-10-08 Thread Michael Cree

On Fri, Oct 08, 2021 at 09:00:22PM +0200, John Paul Adrian Glaubitz wrote:
> On 10/8/21 20:52, Rob Browning wrote:
> > Then, once that's uploaded were you planning to handle the reverse dep
> > rebuilds, and/or what coordination might we need there?
> 
> We can just rebuild all of these reverse dependencies, yes. Adrian Bunk is
> probably happy to take care of that job, he has access to wanna-build, too,
> and has recently done a lot of work in this area.

Just to note I have done a test build of guile-3.0 on a UP alpha system
with an up-to-date chroot.  It failed to build with one failure in the
testsuite, namely:

Running 00-repl-server.test
ERROR: 00-repl-server.test: repl-server: HTTP inter-protocol attack - 
arguments: ((system-error "fport_write" "~A" ("Broken pipe") (32)))

Cheers,
Michael.

Bug#995722: [Pkg-javascript-devel] Bug#995722: Not running tests because tests miss source code is not useful

On 10/8/21 10:20 AM, Yadd wrote:
> Take a look, most of them embed a minified version (jquery* for example)
Yeah ... Everyone upstream thinks it's ok to have 15907152438 copies of
jquery floating around... There's room for improvement for sure! :)

Thomas Goirand (zigo)

Bug#995781: [Debian-med-packaging] Bug#995781: python-sqlsoup autopkgtest fails with SQLAlchemy 1.4.23+ds1-2

2021-10-08 Thread Mike Bayer

Hi Étienne -

SQLSoup's repository is currently at https://github.com/zzzeek/sqlsoup 

However it has not been maintained for many years and would not be expected to 
work with modern versions of SQLAlchemy.   Feel free to remove it from your 
distributions.

- mike



On Fri, Oct 8, 2021, at 4:22 PM, Étienne Mollier wrote:
> Hi Michael,
> 
> Sorry to contact you like this, but since the forge disappeared
> from bitbucket, we were keeping track of the pypi repository
> instead, but it hasn't much moved since 2016 [0], and we don't
> know where else to pull upgrades, report issues, etc.  Per
> chance, do you still happen to work on sqlsoup on some public
> location?
> 
> [0]: https://pypi.org/project/sqlsoup/
> 
> There is an impending upgrade of SQLAlchemy from version 1.3 to
> 1.4 in Debian Testing, but there are a couple of issues which
> hold the process in Unstable.  One of them is that it introduces
> regressions in our current version of sqlsoup, per Thomas' bug
> report [1].
> 
> [1]: http://bugs.debian.org/995781
> 
> Excerpt from the migration test log [2], which basically consist
> in running `python3 -c "import sqlsoup; print(sqlsoup)"`:
> 
> Testing with python3.9:
> Traceback (most recent call last):
>   File "", line 1, in 
>   File "/usr/lib/python3/dist-packages/sqlsoup.py", line 11, in 
> from sqlalchemy.orm.interfaces import MapperExtension, EXT_CONTINUE
> ImportError: cannot import name 'MapperExtension' from 
> 'sqlalchemy.orm.interfaces' 
> (/usr/lib/python3/dist-packages/sqlalchemy/orm/interfaces.py)
> 
> [2]: 
> https://ci.debian.net/data/autopkgtest/testing/amd64/p/python-sqlsoup/15788076/log.gz
> 
> I begun to have a peek at the issue and rapidly found changelogs
> for SQLAchemy [3], but once the first symptom is worked around,
> I begin pull more hairy issues with relation to functions which
> were apparently not documented on sqlalchemy side, while running
> the unit test suite:
> 
> ==
> ERROR: test_bad_names (tests.test_sqlsoup.SQLSoupTest)
> --
> Traceback (most recent call last):
>   File 
> "/<>/.pybuild/cpython3_3.9_sqlsoup/build/tests/test_sqlsoup.py", 
> line 105, in tes
> t_bad_names
> str(db.bad_names.c.query)
>   File "/<>/.pybuild/cpython3_3.9_sqlsoup/build/sqlsoup.py", 
> line 463, in __getattr__
> return self.entity(attr)
>   File "/<>/.pybuild/cpython3_3.9_sqlsoup/build/sqlsoup.py", 
> line 460, in entity
> return self.map_to(attr, tablename=attr, schema=schema)
>   File "/<>/.pybuild/cpython3_3.9_sqlsoup/build/sqlsoup.py", 
> line 366, in map_to
> mapped_cls = _class_for_table(
>   File "/<>/.pybuild/cpython3_3.9_sqlsoup/build/sqlsoup.py", 
> line 133, in _class_for_table
> selectable = expression._clause_element_as_expr(selectable)
> AttributeError: module 'sqlalchemy.sql.expression' has no attribute 
> '_clause_element_as_expr'
> 
> [3]: 
> https://docs.sqlalchemy.org/en/14/changelog/changelog_14.html#change-6daf2f59ac2438ef9c8213e9ebeac157
> 
> (I wrote a patch, in attachment, to get there, but I am not too
> happy about it, feels like just a crude workaround to hide the
> first symptom.)
> 
> Please let us know if you have time to investigate this,
> otherwise the sqlsoup package is at risk of being removed from
> Debian Testing to avoid blocking further the SQLAlchemy upgrade.
> 
> Kind Regards,
> -- 
> Étienne Mollier 
> Fingerprint:  8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
> Sent from /dev/pts/2, please excuse my verbosity.
> 
> 
> *Attachments:*
>  * migrate-to-mapper-events.patch
>  * signature.asc

Bug#995956: ITP: golang-github-dtylman-scp -- A simple go scp client

2021-10-08 Thread Reinhard Tartler

Package: wnpp
Severity: wishlist
Owner: Reinhard Tartler 

* Package name: golang-github-dtylman-scp
  Version : 0.0~git20181017.f3000a3-1
  Upstream Author : Danny
* URL : https://github.com/dtylman/scp
* License : Expat
  Programming Lang: Go
  Description : A simple go scp client

 Simple golang libary to send files using the scp (secure file protocol)

This package is a new dependency of podman 3.4. I plan to maintain it under the
golang team umbrella

Bug#995722: Not running tests because tests miss source code is not useful

On 10/8/21 7:30 PM, Pirate Praveen wrote:
>>>  This is used only during tests. I don't think we are not gaining
>>> anything by removing tests here. Just making it harder for the
>>> package maintainer to run tests.
>>
>> You would not gain anything by removing tests, but you would win by
>> making these tests completely free software.
> 
> I am just saying it increases the work required to run tests

Yes, sure! I'm not contesting this. Just like it increases the work
sometimes to de-vendor minified JS libraries we ship as binaries (which
often we re-minify at build time...).

> and when disabling tests is an option, the incentive is to disable tests.

That's called laziness, and we shall not tolerate this. I've often
packaged some Python libraries *only* to be able to run tests. I very
much think others should at least aim do the same (even if it's not easy).

  If we rely on non-free code for tests, that's really bad too, and that
  must be avoided just like we're avoiding source-less code everywhere
  else in Debian. The policy shall not change, please.

>>>
>>>  The code is not non-free here, just a specific version of a Free
>>> Software code built outside Debian.
>>
>> We build from source...
> 
> We build the binary packages from source. I don't think it is useful to
> extend that to tests without considering the tradeoffs involved.

Hang on, let me consider ... done ! :)

I do not think you'll go as far as saying that running unit (or
functional) tests using blobs is superior to do that using source only
tests (or built from source libraries to run tests). We shall have, as a
goal, to ship *every* source code that's useful to contribute / hack /
modify any given piece of software we ship as binary.

It is my opinion that proposing a GR to tolerate blobs when running
tests is a *very* dangerous path that I would strongly recommend
against. Most likely, you will not like the outcome anyways.

>>>  I think tools required for tests should be considered separately
>>> from tools required to compile. I think it should be treated similar
>>> to test data.
>>
>> I don't agree.
> 
> ok, lets see how the whole project feels via a GR and settle it. I just
> expressed my opinion, you expressed yours and we need to make a decision
> now.

Do you understand that what you're proposing is clearly against all
rules we have in Debian since it's inception? We all signed-up for doing
free software, and free software only, without any "tradeoff".

>>>  What you are proposing would require the package maintainer to adapt
>>> these tests to versions available (many times with different API
>>> versions) in Debian and the easier choice is disabling tests.
>>
>> No. I believe it's ok to have an embedded version of the JS files in the
>> upstream code. This is a *very* different issue, please do not mix them.
>> What I don't like is using a minified version of the JS files. That's
>> *very* easy (hum... trivial?) to add a non-minified version in your
>> Debian folder, and use that for tests. You don't care if running the
>> tests is a little bit slower (because using a source-full version), do
>> you?
> 
> I don't think you really understand the complexities here. Building the
> minified version is not just running the minifier against the non
> minified code. The non minified code itself is generated using many
> other tools (typescript, transpiled using babel, bundled using rollup or
> webpack etc - many times the versions of these tools are very much
> different versions as well).

I very much understand all of this. I never contested that it's
difficult. Though I'm very much contesting that the difficulty for
building the binaries you're wishing to embed is a point of argumentation.

The more building these blobs is hard, the more we need the source code
and the recipe for building these blobs. If you believe these are needed
to guarantee the final artifact's quality, then probably they are also
needed for modifying upstream code too, with a good enough insurance not
to break anything. And I don't agree modifying / contributing to any
free software should be allowed using non-free tools.

>> Best is, if you can, use the library packaged separately, in Debian,
>> both for tests, and runtime. This way, you do ensure that:
>> - patching Debian for security is still a thing
>> - the package can run with the Debian version of the lib
>>
> 
> You are completely missing the reality here as well.

I am *NOT* missing ANYTHING here.
Please read carefully once more: I UNDERSTAND THE PROBLEM.

:)

> The runtime dependencies are already used from the packaged versions.

I get that point, you already mentioned it anyways.

> These vendored
> libraries are used only to create specific test cases or sometimes using
> alternative implementations to test the shipped code.

You also wrote that before.

>> If the lib are just use for tests and nothing else (ie: not for
>> runtime), then back to square one: it's ok to ship

Bug#995935: flatpak: GHSA-67h7-w3jq-vh4q: sandbox escape via recent VFS syscalls

On Fri, 08 Oct 2021 at 12:50:18 +0100, Simon McVittie wrote:
> Flatpak 1.12.0 and 1.10.4 fix a security vulnerability in the portal
> support. Some recently added syscalls were not blocked by the seccomp
> rules which allowed the application to create sub-sandboxes which can
> confuse the sandboxing verification mechanisms of the portal. This has
> been addressed by extending the seccomp rules.

Unfortunately, this has caused regressions, which are fixed in 1.12.1
and 1.10.5, at the cost of weakening the protection against the
vulnerability (it will now "fail open" for syscalls that libseccomp does
not know about).

I'm continuing to look into this upstream, but a full solution is likely
to require a new version of bubblewrap, because bubblewrap can currently
only add one seccomp filter, but I don't think we can achieve the desired
semantics without adding a second seccomp filter. If you can help, please
contact https://github.com/flatpak/flatpak/pull/4462 or
flatpak-secur...@lists.freedesktop.org.

I don't think the upstream solution is sufficiently settled yet to be
issuing stable updates for this.

smcv

Bug#995954: cxref: reproducible builds: builds differently with (obscure) locales

Source: cxref
Severity: minor
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: locale
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Some locales (e.g. potentially obscure locales used by reprotest) may
cause sort order reproducibility issues with the file
/usr/share/cxref/cxref-cpp.defines.

The attached patch fixes this by exporting LC_ALL=C.UTF-8 from
debian/rules.


Thanks for maintaining cxref!


live well,
  vagrant
From cbafe4e3eee67e6a8941d7ef532e41e64883ff66 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Fri, 8 Oct 2021 19:41:31 +
Subject: [PATCH 4/4] debian/rules: Force building in C.UTF-8 locale.

Some obscure locales (e.g. those used by reprotest) trigger
reproducibility issues.
---
 debian/rules | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/debian/rules b/debian/rules
index 55c313d..2921184 100755
--- a/debian/rules
+++ b/debian/rules
@@ -19,6 +19,9 @@ DPKG_EXPORT_BUILDFLAGS=1
 # Ensure texlive respects SOURCE_DATE_EPOCH
 export FORCE_SOURCE_DATE=1
 
+# Force locale to avoid differences when building with obscure locales
+export LC_ALL=C.UTF-8
+
 include /usr/share/dpkg/buildflags.mk
 
 build: build-arch build-indep
-- 
2.33.0



signature.asc
Description: PGP signature

Bug#995891: RFS: zycore-c/1.0.0-1 - libzycore1 rename

2021-10-08 Thread Andrea Pappacoda

After some feedback from upstream in 
https://github.com/zyantific/zycore-c/pull/31#pullrequestreview-774974303 
I had to rename the library package from libzycore1 to libzycore1.0, 
since ABI compatibility is only guaranteed between patch (security) 
releases.

Bug#995953: cxref: reproducible-builds: Build path embedded in documentation

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

Various documentation files embed the build path used during the build.

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

  /usr/share/doc/cxref-doc/README.c.html
  
  
CPP··:·/build/1st/cxref-1.6e/cpp/cxref-cpp·-cxref-cpp-defines·/build/1st/cxref-1.6e/cpp/...
v.
  
CPP··:·/build/2/cxref-1.6e/2nd/cpp/cxref-cpp·-cxref-cpp-defines·/build/2/cxref-1.6e/2nd/cpp/...


The attached patch replaces the build path in the documentation from
debian/rules.

The patch is admittedly a shotgun approach, ideas how to make a more
elegant fix that could ideally be submitted upstream would be
appreciated!

With this patch applied(and the timestamp and usrmerge patches submitted
earlier), cxref should become reproducible on
tests.reproducible-builds.org.


Thanks for maintaining cxref!


live well,
  vagrant
From 7c9224f3c74095e0b63a85a2d53c624e77bb3cdf Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Fri, 8 Oct 2021 17:43:55 +
Subject: [PATCH 3/4] debian/rules: Replace the build paths in the
 documentation.

https://tests.reproducible-builds.org/debian/issues/captures_build_path_issue.html
---
 debian/rules | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/debian/rules b/debian/rules
index d28ac30..55c313d 100755
--- a/debian/rules
+++ b/debian/rules
@@ -64,6 +64,9 @@ install-stamp: build-stamp
 	$(MAKE) install DESTDIR=`pwd`/debian/tmp
 	$(MAKE) docs DESTDIR=`pwd`/debian/tmp
 
+	# Remove build path from documentation
+	find doc/ -type f -exec sed -i -e "s,$(CURDIR),BUILDPATH,g" '{}' \;
+
 	mkdir -p debian/tmp/usr/share/cxref
 	mv debian/tmp/etc/cxref/cxref-cpp.defines debian/tmp/usr/share/cxref
 
-- 
2.33.0



signature.asc
Description: PGP signature

Bug#995782: dask autopkgtest fails with SQLAlchemy 1.4.23+ds1-2

2021-10-08 Thread Diane Trout

On Tue, 2021-10-05 at 17:40 +0200, Thomas Goirand wrote:
> Source: dask
> Version: 2021.08.1+dfsg-3
> Severity: serious
> 
> Hi,
> 
> As per this log:
> https://ci.debian.net/data/autopkgtest/testing/amd64/d/dask/15777502/log.gz
> 
> Please fix this ASAP.

Looks like upstream fixed it and the tests pass with 2021.09.1.

I just need to make sure I can push dask.distributed at the same time
since they're so closely tied together.

Diane

Bug#995952: undertime: Getting TypeError with any timezone

2021-10-08 Thread Gabriel Filion

Package: undertime
Version: 2.6.0
Severity: grave
Justification: renders package unusable

Hello,

I'm currently getting stack traces consistently when using undertime. No matter
the timezone that I request, I get a stack trace with a TypeError exception:

$ undertime pt
Traceback (most recent call last):
  File "/usr/bin/undertime", line 994, in 
main(args)
  File "/usr/bin/undertime", line 733, in main
timezones += filter(None, [guess_zone(z) for z in args.timezones])
TypeError: 'NoneType' object is not iterable

$ undertime PST
WARNING: date provided cannot be parsed: PST
Traceback (most recent call last):
  File "/usr/bin/undertime", line 994, in 
main(args)
  File "/usr/bin/undertime", line 733, in main
timezones += filter(None, [guess_zone(z) for z in args.timezones])
TypeError: 'NoneType' object is not iterable

If I run that last command with pdb,

e.g. python3 -m pdb /usb/bin/undertime PST

and then (r)un the program until the error, I can see that args.timezones is
set to None:

(Pdb) type(args.timezones)



now from there, I tried using "undertime -t PST" and that actually worked. So
there must be something off with the default value to -t


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

Kernel: Linux 5.14.0-1-amd64 (SMP w/4 CPU threads)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.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 undertime depends on:
ii  python3 3.9.2-3
ii  python3-dateparser  1.0.0-1
ii  python3-ephem   4.1-1
ii  python3-tabulate0.8.7-0.1
ii  python3-termcolor   1.1.0-3
ii  python3-tz  2021.3-1
ii  python3-yaml5.3.1-5

undertime recommends no packages.

undertime suggests no packages.

-- no debconf information

Bug#795284: troubles with range requests

2021-10-08 Thread Eduard Bloch

Control: severity 795284 important

On Tue, 25 Aug 2015 15:04:29 +0100 Mark Hindley  wrote:
> package apt-cacher
> reassign 795284 apt
> thanks
>
> I have looked at this some more and I think apt-cacher is following the spec
> correctly. It seems as if apt-get doesn't realise that the 416 response with 
> the
> Content-Range denominator equal to the size it already has indicates the file 
> is
> complete.
>
> So I am going to reassign to apt.
>
> Apt team, if I have got this analysis wrong, sorry, do point out my error and 
> assign
> back.

Dear apt team,

I came recently to erratical behavior of apt with apt-cacher-ng (not
apt-cacher but similar). Checking the wireshark trace, I see strange
things, see below. For me, what apt's http client is doing there DOES
NOT MAKE MUCH SENSE.

The ancient version, like 10 years ago, used a very simple and effective
trick. It specified If-Range but also a Range which started one byte
_before_ the previous body length. So the server could either return
just a byte or start returning a completely new resource body with a 200
response, no extra rounds needed.

What does the current version do?

It requests the file but the with If-Range (which is okay) and Range
which starts AFTER the body. This obviously causes a code 416 even if
the response body hasn't changed.

In response, apt makes another request, with "If-Modified-Since" from a
day ago - so I guess it has another version in cache, which it takes as
replacement now. It also does not specify the Range. So I guess the
issue 795284 is mostly solved but not fully, we got another pointless
behavior now.

So, the current version behaves better than in 2015, but still worse
than ~10 years ago.

Please restore the original algorithm, which refetched the last byte.
This causes less bandwith waste than doing a second request which will
almost always become necessary.

(local trace, input/output interleaved but you see the point).

GET http://ftp.de.debian.org/debian/dists/testing/InRelease HTTP/1.1
Host: ftp.de.debian.org
Cache-Control: max-age=0
Accept: text/*
Range: bytes=128490-
If-Range: Fri, 08 Oct 2021 14:16:00 GMT
User-Agent: Debian APT-HTTP/1.3 (2.3.9)

HTTP/1.1 416 Requested Range Not Satisfiable
Content-Length: 512
Content-Type: text/html
Date: Fri, 08 Oct 2021 18:26:45 GMT
Server: Debian Apt-Cacher NG/3.7.3

...
href="http://www.unix-ag.uni-kl.de/~bloch/acng/;>Apt-Cacher NG 
homepage
GET http://ftp.de.debian.org/debian/dists/testing/InRelease HTTP/1.1
Host: ftp.de.debian.org
Cache-Control: max-age=0
Accept: text/*
If-Modified-Since: Thu, 07 Oct 2021 14:15:24 GMT
User-Agent: Debian APT-HTTP/1.3 (2.3.9)

HTTP/1.1 200 OK
Content-Type: octet/stream
Last-Modified: Fri, 08 Oct 2021 14:16:00 GMT
Content-Length: 128490
X-Original-Source: http://deb.debian.org/debian/dists/testing/InRelease
Date: Fri, 08 Oct 2021 18:26:45 GMT
Server: Debian Apt-Cacher NG/3.7.3

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Origin: Debian
Label: Debian
...

Best regards,
Eduard.

Bug#995225: docker: Docker package should depend or at least recommend cgroupfs-mount

2021-10-08 Thread Tianon Gravi

reassign 995225 docker.io
fixed 995225 0.9.1~dfsg1-1
thanks

On Tue, 28 Sept 2021 at 00:45, Andrius Narbutas  wrote:
> Package: docker
> Version: 1.5-2
> Severity: normal

As seen in my control bits above, you've got the wrong Docker, unfortunately.

I've reassigned the bug appropriately from the wmdocker utility to the
Docker Engine.

> Setup: debian buster upgraded to bullseye using apt dist-upgrade
> In buster i had few docker containers running without issues. Upgraded to 
> bullseye - and docker refuses to start:
>
> dockerd[42547]: Error starting daemon: Devices cgroup isn't mounted
>
> Turns out that i should manually install "cgroupfs-mount" package, then it 
> mounts cgroup and then docker can start.
>
> I think, that docker should suggest this package, if not depend on it (else 
> dockerd won't start and docker will be useless).
> Currently suggested packages by docker:

The docker.io package has included "cgroupfs-mount" in Recommends (or
higher) since version 0.9.1~dfsg1-1 (when I added it, back in 2014
:D).

Frankly though, I'd suggest (hah) that it should be downgraded to
Suggests instead -- on a modern init system (systemd, openrc, etc),
the init system sets up and manages the cgroup hierarchy, which ends
up being a lot more stable/reliable than the "cgroupfs-mount" package
ever was, especially now that we have cgroupsv2 (which that package
doesn't support, and Docker's cgroupsv2 support relies on systemd
anyhow).

I suppose we could use something "clever" like "cgroupfs-mount |
systemd-sysv" but that still seems pretty fragile IMO.

♥,
- Tianon
  4096R / B42F 6819 007F 00F8 8E36  4FD4 036A 9C25 BF35 7DD4

Bug#994354: python-gevent build-depends on removed package : fix for this bug attached

2021-10-08 Thread GCS

Hi Thomas,

On Fri, Oct 8, 2021 at 4:51 PM Thomas Goirand  wrote:
> Please find attached to this message, the fix for this bug.
 Thanks, but as noted it's not enough.

> Note that python-gevent 20.9.0 doesn't build against Sphinx 4, though
> latest upstream release (ie: 21.8.0) is fixed.
 Michael R. Crusoe already fixed it with a backport.

> Would you allow me to NMU the attached debdiff, plus upgrading to
> 21.8.0, or do you wish to do it yourself?
 I hope it will be moved to the Python Team and anyone can commit
changes to this package there.

Cheers,
Laszlo/GCS

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

2021-10-08 Thread GCS

Hi,

On Fri, Oct 8, 2021 at 1:45 PM Michael R. Crusoe  wrote:
> I've prepared an NMU for python-gevent (versioned as 20.9.0-2.1) which fixes
> the serious bug "python-gevent build-depends on removed package" and
> uploaded it to DELAYED/7. Please feel free to tell me if I
> should delay it longer.
 Thanks for the heads-up, much appreciated. To speed things up, I've
uploaded it with another change (crediting you of course).
However I think you should have escaped the dot in the watch file,
\d[\d.]* should be \d[\d\.]* I think. Otherwise dot will mean any
character, making \d useless. But then it will only match numbers
separated by dots, so uversionmangle will never get rc|RC|pre, etc.

> Like Sandro Tosi, I invite you to consider maintaining this package under 
> Debian
> Python Team.
 I can't devote enough time to this package. Feel free any of you
taking this package to the Python Team and maintain it there.

Thanks,
Laszlo/GCS

Bug#995950: mrtg: Typo breaking source code

2021-10-08 Thread Joao Eriberto Mota Filho

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

In bin/cfgmaker (source code), there is a typo. The following patch will fix it.

--- mrtg-2.17.8+dfsg1.orig/bin/cfgmaker
+++ mrtg-2.17.8+dfsg1/bin/cfgmaker
@@ -956,7 +956,7 @@ sub DeviceInfo ($$$) {
 my @variables = snmpwalk(v4onlyifnecessary($router, 
$ipv4only),$v3opt,'1.3.6.1.2.1.1'); # walk system
 if (!(defined $variables[0])) {
 # Do we need to fall back to IPv4?
-my ($commmunity, $host) = ($1, $2) if ($router =~ /^(.*)@([^@]+)$/);
+my ($community, $host) = ($1, $2) if ($router =~ /^(.*)@([^@]+)$/);
 if ( ( ! $ipv4only ) && ( $host !~ /^\[(.*)\]/) ) {
 # Not using IPv4, not an IPv6 address, so a hostname
 debug ('base',"No response using IPv6 for $router, trying again 
using IPv4");

Regards,

Eriberto

Bug#995614: guile-3.0: Please build with --without-threads on alpha to fix FTBFS

On 10/8/21 20:52, Rob Browning wrote:
> Then, once that's uploaded were you planning to handle the reverse dep
> rebuilds, and/or what coordination might we need there?

We can just rebuild all of these reverse dependencies, yes. Adrian Bunk is
probably happy to take care of that job, he has access to wanna-build, too,
and has recently done a lot of work in this area.

Adrian

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

Bug#995049: marked as done (p11-kit: FTBFS on hurd-i386)

2021-10-08 Thread Svante Signell

On Fri, 2021-10-08 at 19:32 +0200, Andreas Metzler wrote:
> # The older patch version included in the upload did not build on
> hurd.
> #
> # I will re-check
> 
> reopen 995049

Hello,

The problem is that p11-kit should build-depend on libbsd-dev, not
libbsd0, as in the latest update to the bug. The inclusion of
bsd/unistd.h fails!

Thanks!

Bug#995614: guile-3.0: Please build with --without-threads on alpha to fix FTBFS

2021-10-08 Thread Rob Browning

John Paul Adrian Glaubitz  writes:

> But again, we're doing this all the time and this affects a non-release
> architecture. I never said this flag should be passed for amd64 or arm64.

Understood.  I was specifically thinking about any existing alpha
deployments and what the constraints might be.

I discussed it a bit on #debian-devel, and it sounded like breaking the
ABI in this case, while not ideal of course, wouldn't be unacceptable.
So if no other options present themselves before I get a chance to work
on it, I'll plan to make this change.

Then, once that's uploaded were you planning to handle the reverse dep
rebuilds, and/or what coordination might we need there?

Thanks
-- 
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4

Bug#995948: lesspipe doesn’t properly quote filenames

2021-10-08 Thread Christoph Anton Mitterer

Package: less
Version: 551-2
Severity: important


Hey.

In most (all?) cases, lesspipe simply uses the filename as
is (i.e. $1) and neither uses anything like "--" (as far
as available) in the commands it calls.

This is prone to fail, as soon as one has filenames that may
be mistaken for command options, e.g. ones that start with
- or --
.


I guess there are two things one can do here (and probably one has do
to actually both):
1) Go through the list of all commands, find out which of them supports
"--" or similar options and just add them

2) For all other cases, a nice trick is to quote any pathnames as
absolute or relative paths (these are typically never mistaken for
options).
Well an absolute path is anyway "quoted" in that sense, a relative
path needs a "./" added.

I have a function for this (see attachment).


What do you think should we do?


Cheers,
Chris.
#!/bin/sh


#***
#*** Escape Pathname For Use As Command Argument ***
#***
# Escapes a pathname for use as a command argument, so that it’s not mistaken
# for a typical option argument (like `-o` or `--option`) and can be used with
# programs that don’t provide a way to stop option argument parsing (like via
# `--`) or improperly parse option arguments with (separate) values (like
# `--option value`, where the value might start with a `-`).
#
# Its output is guaranteed to be one of the following:
# • the empty string
#   (when the input was the empty string)
# • an absolute pathname starting with `/`
#   (when the input was an absolute pathname)
# • a relative pathname starting with `./` respectively just `.`
#   (when the input was a relative pathname respectively the relative pathname
#   of a “dot file”)
#
#
# There are two modes of operation:
# • reading the string literal from standard input
#   (when there are 0 positional parameters)
# • reading the string literal from positional parameter #1
#   (when there are ≧1 positional parameters)
#
#
# Beware:
# • The Shell Command Language’s command substitutions (`$(…)` and (``…``))
#   strip any trailing newlines from the command’s standard output.
#   Therefore, when this function is used in a command substitution the trailing
#   newlines, if any, get lost.
#   
#   If this is a concern, then lost trailing newlines can be recovered like
#   this:
#   TODO:

escape_pathname_as_command_argument()
{
local pathname="${1-}"


if [ $# -eq 0 ]; then
sed '1s|^[^/.]|./&|'
else
if [ -z "${pathname}" ]; then
return 0
elif [ -z "${pathname##[/.]*}" ]; then
printf '%s' "${pathname}"
else
printf './%s' "${pathname}"
fi
fi
}
















#Copyright © 2021 Christoph Anton Mitterer 
#
#
#This program is free software: you can redistribute it and/or modify it under
#the terms of the GNU General Public License as published by the Free Software
#Foundation, either version 3 of the License, or (at your option) any later
#version.
#This program is distributed in the hope that it will be useful, but WITHOUT ANY
#WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A
#PARTICULAR PURPOSE.
#See the GNU General Public License for more details.
#You should have received a copy of the GNU General Public License along with
#this program. If not, see .

Bug#995947: less: miscellaneous improvements

2021-10-08 Thread Christoph Anton Mitterer

Package: less
Version: 551-2
Severity: normal
Tags: patch


Hey.

I've made a number of improvements, but it seems you have disabled
merge requests on salsa?

Please have a look there:
https://salsa.debian.org/calestyo-guest/less/-/tree/misc-improvements

a1f7c55 support rpm2cpio as a fallback when rpm isn’t available
fa602f5 which has been deprecated, use command -v instead
c0b3964 prefer unrar over rar


Cheers,
Chris.

Bug#995946: Please rebuild all Go packages on i386 which are built by golang-1.16 and golang-1.17

2021-10-08 Thread Shengjing Zhu

Package: release.debian.org
Severity: wishlist
X-Debbugs-Cc: z...@debian.org

The golang-1.16 package before 1.16.9-2, golang-1.17 package before 1.17.2-1
enables SSE2 on i386 accidentally. #995708

It has been fixed in golang-1.16/1.16.9-2 and golang-1.17/1.17.2-1.

Please rebuild all the Go packages on i386.

Following packages are affected:

Packages build with golang-1.16 on i386:

apkverifier
badger
balloon
c2go
chasquid
containerd
docker.io
douceur
garagemq
go-exploitdb
go-qrcode
golang-chroma
golang-docker-credential-helpers
golang-golang-x-tools
gopls
hjson-go
hugo
kcptun
libsecsipid-dev
libsecsipid1
minify
ncbi-entrez-direct
nncp
panicparse
podman
podman-docker
secsipidx
seqkit
sshesame
textql
unikmer
vcfanno
webhook

Packages build with golang-1.17 on i386:

gdu

Bug#995722: Not running tests because tests miss source code is not useful

2021-10-08 Thread Pirate Praveen

On വെ, ഒക്ടോ 8 2021 at 10:31:16 രാവിലെ +0200 
+0200, Thomas Goirand  wrote:

On 10/7/21 11:40 AM, Pirate Praveen wrote:

 On 7 October 2021 3:02:55 am IST, Thomas Goirand  
wrote:

 On 10/6/21 6:53 PM, Pirate Praveen wrote:

 [adding -devel]

 On ബു, ഒക്ടോ 6 2021 at 12:16:07 വൈകു +0200 
+0200, Jonas Smedegaard

  wrote:

 Quoting Yadd (2021-10-06 11:43:40)

  On Lu, 04 oct 21, 16:40:48, Bastien Roucari�s wrote:
  > Source: src:node-lodash
  > Version: 4.17.21+dfsg+~cs8.31.173-1
  > Severity: serious
  > Justification: do not compile from source
  >
  > Dear Maintainer,
  >
  > The vendor directory should be emptied
  >
  > The debug version is compiled without source (lintian warn) 
and

 moreover the
  > rest of file are already packaged
  >
  > grep -R vendor * gives only a few hit that could be cured by
 symlinking
  >
  > Bastien
  Hi,

  this files are used for test only, maybe severity could be 
decreased.

 I find the severity accurate: Relying on non-source code is a 
severe
 violation of Debian Policy, not matter the purpose of relying on 
it.

 I think we should change the policy here. Running tests helps 
improve
 the quality of the software we ship. Many times the vendored code 
is
 used to ensure the code does not break in a specific situation. I 
don't

 think reducing test coverage in such situations is really helpful.

 Right, running tests helps improve the quality of software we ship.
 Which is why you probably need to test using what's shipped in 
Debian

 rather than using a vendored source-less code.

 We are not shipping the source less code.

You are: Debian also ships source code.

I meant, not shipping in any binary package. Though as Russ mentioned 
in his reply. I will propose a GR.

 This is used only during tests. I don't think we are not gaining 
anything by removing tests here. Just making it harder for the 
package maintainer to run tests.

You would not gain anything by removing tests, but you would win by
making these tests completely free software.

I am just saying it increases the work required to run tests and when 
disabling tests is an option, the incentive is to disable tests.

 If we rely on non-free code for tests, that's really bad too, and 
that
 must be avoided just like we're avoiding source-less code 
everywhere

 else in Debian. The policy shall not change, please.

 The code is not non-free here, just a specific version of a Free 
Software code built outside Debian.

We build from source...

We build the binary packages from source. I don't think it is useful to 
extend that to tests without considering the tradeoffs involved.

 I think tools required for tests should be considered separately 
from tools required to compile. I think it should be treated similar 
to test data.

I don't agree.

ok, lets see how the whole project feels via a GR and settle it. I just 
expressed my opinion, you expressed yours and we need to make a 
decision now.

 What you are proposing would require the package maintainer to 
adapt these tests to versions available (many times with different 
API versions) in Debian and the easier choice is disabling tests.

No. I believe it's ok to have an embedded version of the JS files in 
the
upstream code. This is a *very* different issue, please do not mix 
them.

What I don't like is using a minified version of the JS files. That's
*very* easy (hum... trivial?) to add a non-minified version in your
Debian folder, and use that for tests. You don't care if running the
tests is a little bit slower (because using a source-full version), 
do you?

I don't think you really understand the complexities here. Building the 
minified version is not just running the minifier against the non 
minified code. The non minified code itself is generated using many 
other tools (typescript, transpiled using babel, bundled using rollup 
or webpack etc - many times the versions of these tools are very much 
different versions as well).

However, there's this:

On 10/7/21 6:17 PM, Richard Laager wrote:
 Running tests against vendored dependencies one isn't going to use 
at

 run-time is of limited usefulness.

Best is, if you can, use the library packaged separately, in Debian,
both for tests, and runtime. This way, you do ensure that:
- patching Debian for security is still a thing
- the package can run with the Debian version of the lib

You are completely missing the reality here as well. The runtime 
dependencies are already used from the packaged versions. These 
vendored libraries are used only to create specific test cases or 
sometimes using alternative implementations to test the shipped code.

I think it's less grave than just saying "oh, we don't care about 
these

binary blobs, there's just for tests...". It's even worse, because by
using a different version for tests and runtime, you're faking 
tests...

See above. All runtime dependencies are packaged and used from packaged 
versions. In many cases the code

Bug#695587:

2021-10-08 Thread Lola Aparició

Como entro tengo la versión de prueba

Bug#995708: docker.io: dockerd dies with Illegal Instruction when run on a pre-SSE2-class x86 system

2021-10-08 Thread Shengjing Zhu

Control: reassign -1 src:golang-1.16 1.16.8-1

On Mon, Oct 4, 2021 at 11:27 PM Jörn Heusipp
 wrote:
>
> I am by no means a Go expert, however given that docker is written in
> Go, and that Go increased the default i386 architecture requirements to
> SSE2 in 1.16 (see ), building the
> docker package with GO386=softfloat on i386 might solve this issue. The
> set of x86 CPUs supporting SSE2 but not also supporting amd64 is quite
> small. Basically, only the Pentium 4. Thus to be useful on 32bit x86
> systems in general, I think wider compatibility, even at a performance
> cost, could be considered.

You're right. We are aware of this, and did a hack in our build script
with GO386=softfloat on i386, but it seems there's a bug in the build
script.

-- 
Shengjing Zhu

Bug#994056: cryptsetup: blkid check fails to take offset option into account

2021-10-08 Thread Thorsten Glaser

Guilhem Moulin dixit:

>first to report it I suppose nobody uses large offset= values.  Don't
>think adding ‘Depends: bc’ is justified here :-P.

Eh, bc’s supposed to be a base tool anyway…

>Also in practice I was able to use offset=2⁵⁹

(buster-i386)tglase@tglase:~ $ echo '2^59' | bc
576460752303423488
(buster-i386)tglase@tglase:~ $ echo $(($(echo '2^59' | bc)*512))
0
(buster-i386)tglase@tglase:~ $ bash
bash$ echo $(($(echo '2^59' | bc)*512))
0

I’d not call this “use”.

> with bash, dash, klibc's sh and busybox's sh

mksh is also a viable /bin/sh (the /bin/lksh binary), and for that
I speak as developer ;)

>I'll just ignore the potential overflow. I'll just make the script
>choke when the arithmetic operation fails.

That’s the problem: the operation does not fail, it “only” overflows.
Overflowing *is* permitted (by C UB rules) to do “rm -rf /” even if
GCC does not (yet) do that… but even if it wraps around, you get the
WRONG values (see above).

(buster-i386)tglase@tglase:~ $ lksh -c 'echo $(($(echo "2^40" | bc)*512))'
0

(This is actually what POSIX requires. So bash, dash, etc. are
actually noncompliant on 32-bit platforms.)

So please, if you’re going to “ignore” this in practice, at least
install the code that checks for offset ≤ 4194303. I can provide
a corresponding patch, if you want.

bye,
//mirabilos
-- 
FWIW, I'm quite impressed with mksh interactively. I thought it was much
*much* more bare bones. But it turns out it beats the living hell out of
ksh93 in that respect. I'd even consider it for my daily use if I hadn't
wasted half my life on my zsh setup. :-) -- Frank Terbeck in #!/bin/mksh

Bug#995945: Allow more key/value pairs than just username/password/hostname

2021-10-08 Thread Trent W. Buck

Package: python3-pypass
Version: 0.2.1-1.1
Severity: wishlist

It seems you ask for a specific key/value field like this:

https://sources.debian.org/src/pypass/0.2.1-2/pypass/command.py/#L193

But there are only three specific fields you can ask for:

https://sources.debian.org/src/pypass/0.2.1-2/pypass/entry_type.py/#L23

I thought "no worries, I'll just make my own subclass of that",
except it's also baked in here:

https://sources.debian.org/src/pypass/0.2.1-2/pypass/passwordstore.py/#L120

My use case is, certain governments require me to input additional passwords,
and I want to use key/value pairs for them, e.g.

$ pass show tax-haven.ai
diminish canopener blooper radiation direction paving
url: https://www.tax-haven.ai/login.asp
login: twb
What was your first pet's maiden name?: directed darkness oxidant reborn 
agreeing cozily
What band were you bassist for when the Americans faked the moon landing?: 
nanny molehill jokingly define lyrics skeleton
What is your favourite California penal code section?: satin linguini 
frayed nervous script ought
What is the problem with kids today?: moonlight uniformed concierge 
flatware flattered unboxed
Ты не забываешь деньги?: Гусары денег не берут!

...and then, I guess, have some way to get those back out without going 
md.
I haven't worked out that part yet.





-- System Information:
Debian Release: 11.0
  APT prefers stable-updates
  APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 
'stable'), (500, 'proposed-updates'), (500, 'unstable'), (500, 'testing'), (1, 
'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-8-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.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 python3-pypass depends on:
ii  python3   3.9.2-3
ii  python3-click 7.1.2-1
ii  python3-colorama  0.4.4-1
ii  python3-pexpect   4.8.0-2

python3-pypass recommends no packages.

python3-pypass suggests no packages.

-- no debconf information

Bug#994056: cryptsetup: blkid check fails to take offset option into account

2021-10-08 Thread Guilhem Moulin

On Fri, 08 Oct 2021 at 15:12:58 +, Thorsten Glaser wrote:
>>, so I completed your patch with 2373709bb461a71a7af46e7e9c59355fce63e52e.
> 
> -blkid="$(/sbin/blkid -o value -s TYPE -p ${offset:+-O "$offset"} -- "$dev")"
> +blkid="$(/sbin/blkid -o value -s TYPE -p ${offset:+-O "$((offset*512))"} -- 
> "$dev")"
> 
> That’s only good for offset ≤ 4194303 though and invokes C “Undefined
> Behaviour” on larger values. (More on LP64 of course.)

Ah right, thanks.  Given #-1 is a 12 years old bug and AFAICT you're the
first to report it I suppose nobody uses large offset= values.  Don't
think adding ‘Depends: bc’ is justified here :-P.

Also in practice I was able to use offset=2⁵⁹ with bash, dash, klibc's
sh and busybox's sh on a stock 32 bytes platform, so I'll just ignore
the potential overflow.  I'll just make the script choke when the
arithmetic operation fails.

-- 
Guilhem.

signature.asc
Description: PGP signature

Bug#995841: RFS: c-blosc/1.21.1+ds1-1 [ITA] -- high performance meta-compressor optimized for binary data

On Wed, 6 Oct 2021 22:10:51 +0200 haavard_aa...@yahoo.no wrote:

Changes since the last upload:

c-blosc (1.21.1+ds1-1) unstable; urgency=medium
.
* New upstream release
* Adopt package. Closes: #945176
* d/watch: Update URL to GitHub.
* d/control:
- Drop version constriction on build-dependency
- Update Standards-Version to 4.6.0
* d/copyright: Update mail address.

Hi Håvard,

Thanks for taking care of this. About the repacking: The Files-Excluded list exludes more
than necessary. I can understand that internal-complibs is excluded so that the
distribution licenses do not have to be copied to copyright. The appveyor files are
non-existing and having blosc/win32 does not really hurt. There are no binaries included,
which is the reason to exclude Windows stuff often. Please do not remove blosc/win32 from
the next upstream version.

Please fix debian/copyright. As your version is an improvement I upload it for now. But
there are several copyright notices missing and files attributed to the wrong license: see
examples dir for a few Expat licensed files. Also, the wildcard for the bitshuffle stuff
matches too many files. blosc/fastcopy.c is based on zlib licensed code, so that license
has to be included by Debian Policy 12.5 as well (even though not necessary legally).

Some files reference a non-existing LICENSE.txt which I cannot find.
tests/gcc-segfault-issue.c claims that it was an MIT license but maybe upstream confuses
MIT/BSD. Please ask upstream which license applies here.

Thanks,
Bastian

Bug#995944: Does not use auto-detect if git is already in use

2021-10-08 Thread Trent W. Buck

Package: qtpass
Version: 1.3.2-3
Severity: serious

I am flagging this as "serious" because it leads to data loss.
Specifically, I already lost the history of my test passwords.
Had I not noticed right away, I could have lost REAL passwords.

I have an existing ~/.password-store.
It has git enabled.
It is read and written to by pass(1).
It is read by applications using python3-pypass.

I installed qtpass, added a test password, and changed it two or three times.
I was very surprised to see that no git commit logs appeared.

It seems that by default, qtpass has

Configuration > Settings
[ ] Use git  (off by default)

Configuration > Programs
(X) Native git/gpg   (on by default)
( ) Use pass (off by default)

If the user has no existing .password-store, this is a reasonable default.
However, if .password-store is ALREADY using git, qtpass SHOULD use git by 
default.


-- System Information:
Debian Release: 11.0
  APT prefers stable-updates
  APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 
'stable'), (500, 'proposed-updates'), (500, 'unstable'), (500, 'testing'), (1, 
'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-8-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.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 qtpass depends on:
ii  gnupg   2.2.27-2
ii  libc6   2.32-4
ii  libgcc-s1   10.2.1-6
ii  libqt5core5a5.15.2+dfsg-9
ii  libqt5gui5  5.15.2+dfsg-9
ii  libqt5network5  5.15.2+dfsg-9
ii  libqt5svg5  5.15.2-3
ii  libqt5widgets5  5.15.2+dfsg-9
ii  libstdc++6  10.2.1-6

Versions of packages qtpass recommends:
ii  pass1.7.3-2
pn  pass-extension-otp  
pn  pwgen   

Versions of packages qtpass suggests:
ii  git  1:2.30.2-1

-- no debconf information

Bug#639740: synaptic

2021-10-08 Thread Jhernandor

Good morning

My problem is that I get this message when I start synaptic:
E: The value "buster" is not valid for APT::Default-Release as that 
distribution is not available in the sources.
E: _cache->open() failed, please report.

I have checked /etc/apt/ and no "buster" appears in any file.
My distribution is bullseye to which I migrated a few days ago.
Regards
Thanks
Pd is an automatic translation

Translated with www.DeepL.com/Translator (free version)

Sent from [ProtonMail](https://protonmail.com), Swiss-based encrypted email.

Sent with [ProtonMail](https://protonmail.com/) Secure Email.

Bug#994056: cryptsetup: blkid check fails to take offset option into account

2021-10-08 Thread Thorsten Glaser

Hi Guilhem,

>(And added unit tests for the use case.)

thanks! I was more interested in getting my system working and did the
fix on the installed system without looking at the source package at
first.

>Thanks for the patch!  FWIW crypttab(5)'s ‘offset=’ passes the value to
>`cryptsetup -o` which is a 512 byte sectors count while `blkid -O` wants
>bytes

*OUCH!* Good catch.

>, so I completed your patch with 2373709bb461a71a7af46e7e9c59355fce63e52e.

-blkid="$(/sbin/blkid -o value -s TYPE -p ${offset:+-O "$offset"} -- "$dev")"
+blkid="$(/sbin/blkid -o value -s TYPE -p ${offset:+-O "$((offset*512))"} -- 
"$dev")"

That’s only good for offset ≤ 4194303 though and invokes C “Undefined
Behaviour” on larger values. (More on LP64 of course.)

Worse, blkid(8) supports multiplicators, but only KiB and more, not
(512-byte) sectors, so to fix this *properly* we’d have to rely on
bc(1) or dc(1), which unfortunately Debian does not install by default
(unlike Unix). I’d say go for it but I’m not sure how majority-capable
my opinion on this is ☻

Other options:

• ignore this, which will cause misdetection for large offsets (bah)

• document that offsets larger than 4194303 are not supported
  (not worth much if the underlying cryptsetup does support it)

  ‣ option: check for that

• check for large offsets and either “defuse” (skip and permit)
  or “refuse” (skip and deny) the blkid and un_blkid checks

Checking for large offsets is also not trivial, as you cannot
do just $((offset < 4194303) for the same reason. In POSIX sh
this would work:

case x$offset in
(x)
deny 'offset is empty'  # or rather just skip the -O option
;;
(x*[!0-9]*)
deny 'offset is negative or contains non-digits'
;;
(*)
if test ${#offset} -gt 7 || test "$offset" -gt 4194303; then
deny 'offset too large'
fi
;;
esac

This code first checks that it’s indeed a positive number,
then its length, and only if that’s within safe bounds,
the actual value.

All of these other than the bc(1)/dc(1) solution, however, impose
32-bit limits on 64-bit platforms. This is, unfortunately, not
avoidable because in POSIX sh it’s impossible to find out whether
the shell has 32-bit or 64-bit arithmetics without triggering UB
on 32-bit. Blaming ISO C is appropriate.

I’m attaching a first cut at my favourite solution. It’s missing
a thing I’m not sure how to achieve: ensure that bc(1) is available
in the initrd. My initramfs-tools “fu” is not very high.

Thanks,
//mirabilos
-- 
“It is inappropriate to require that a time represented as
 seconds since the Epoch precisely represent the number of
 seconds between the referenced time and the Epoch.”
-- IEEE Std 1003.1b-1993 (POSIX) Section B.2.2.2

Bug#994056: cryptsetup: blkid check fails to take offset option into account

2021-10-08 Thread Thorsten Glaser

Dixi quod…

>I’m attaching a first cut at my favourite solution. It’s missing

… this time with attachment…

bye,
//mirabilos
-- 
„Cool, /usr/share/doc/mksh/examples/uhr.gz ist ja ein Grund,
mksh auf jedem System zu installieren.“
-- XTaran auf der OpenRheinRuhr, ganz begeistert
(EN: “[…]uhr.gz is a reason to install mksh on every system.”)diff --git a/debian/checks/blkid b/debian/checks/blkid
index 5332ba35..0be466f1 100644
--- a/debian/checks/blkid
+++ b/debian/checks/blkid
@@ -17,7 +17,23 @@ dev="$1"
 fs="$2"
 offset="$3"
 
-blkid="$(/sbin/blkid -o value -s TYPE -p ${offset:+-O "$((offset*512))"} -- 
"$dev")"
+case x$offset in
+(x)
+   blkid_offset=
+   ;;
+(x*[!0-9]*)
+   echo " - Invalid 'offset' option: $offset"
+   exit 1
+   ;;
+(*)
+   blkid_offset="-O $(bc <= 2:1.6.0),
+ bc,
  dmsetup,
  ${misc:Depends},
  ${shlibs:Depends}

Bug#995943: ITP: r-cran-osqp -- Quadratic Programming Solver using the 'OSQP' Library

2021-10-08 Thread Steffen Moeller

Package: wnpp
Severity: wishlist

Subject: ITP: r-cran-osqp -- Quadratic Programming Solver using the 'OSQP' 
Library
Package: wnpp
Owner: Steffen Moeller 
Severity: wishlist

* Package name: r-cran-osqp
  Version : 0.6.0.3
  Upstream Author : Bartolomeo Stellato
* URL : https://cran.r-project.org/package=osqp
* License : Apache-2.0
  Programming Lang: GNU R
  Description : Quadratic Programming Solver using the 'OSQP' Library
 Provides bindings to the 'OSQP' solver. The 'OSQP' solver is a numerical
 optimization package or solving convex quadratic programs written in 'C'
 and based on the alternating direction method of multipliers. See
  for details.

Remark: This package is maintained by Debian R Packages Maintainers at
   https://salsa.debian.org/r-pkg-team/r-cran-osqp

Bug#988777: Please update epiphany-browser to 3.38.6 in bullseye-updates

2021-10-08 Thread Amr Ibrahim

Hello,

I'm a regular user of epiphany-browser and would really appreciate if
version 3.38.6 could be updated in bullseye-updates.

It contains useful bug-fixes only:

https://gitlab.gnome.org/GNOME/epiphany/-/blob/gnome-3-38/NEWS

3.38.6 - August 12, 2021


 * Fix UI process CPU usage issue (#1560)

3.38.5 - June 4, 2021
=

 * Fix crash when importing bookmarks from Firefox (!949)
 * Fix memory corruption in history dialog (!960)
 * Fix crash when checking for modified forms (!962)

3.38.4 - April 29, 2021
===

 * Allow launching external URLs when triggered by user action (#1385)
 * Fix untranslatable string in security popover (#1478)
 * Remove bad assert added in 3.38.3 (!941)

3.38.3 - March 12, 2021
===

 * Fix crash when signing out of Firefox Sync account (#1342)
 * Fix crash when using broken remove button on history dialog (#1417)
 * Fix particular search queries mistaken as addresses (#1418)
 * Fix loss of session state on window close with unresponsive web
process (#1445)
 * Fix overaggressive popup blocking (#1467)
 * Pre-filled text in search field should be initially selected (!887,
Benjamin Berg)


Thanks a lot
Amr

Bug#994354: python-gevent build-depends on removed package : fix for this bug attached

Hi Laszlo,

Please find attached to this message, the fix for this bug.

Note that python-gevent 20.9.0 doesn't build against Sphinx 4, though
latest upstream release (ie: 21.8.0) is fixed.

Would you allow me to NMU the attached debdiff, plus upgrading to
21.8.0, or do you wish to do it yourself?

Cheers,

Thomas Goirand (zigo)
diff -Nru python-gevent-20.9.0/debian/changelog 
python-gevent-20.9.0/debian/changelog
--- python-gevent-20.9.0/debian/changelog   2021-03-02 06:55:02.0 
+0100
+++ python-gevent-20.9.0/debian/changelog   2021-10-08 16:20:30.0 
+0200
@@ -1,3 +1,12 @@
+python-gevent (20.9.0-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Removed build-depends on -dbg and building the -dbg package.
+(Closes: #994354). This fixes python-gevent build-depends on removed
+python3-cffi-backend-dbg (Closes: #995138).
+
+ -- Thomas Goirand   Fri, 08 Oct 2021 16:20:30 +0200
+
 python-gevent (20.9.0-2) unstable; urgency=medium
 
   * Fix dh_installdocs invocation in arch target (closes: #983825).
diff -Nru python-gevent-20.9.0/debian/control 
python-gevent-20.9.0/debian/control
--- python-gevent-20.9.0/debian/control 2021-01-05 20:03:08.0 +0100
+++ python-gevent-20.9.0/debian/control 2021-10-08 16:20:30.0 +0200
@@ -7,12 +7,12 @@
  python3-greenlet,
  python3-greenlet-dbg,
  python3-setuptools,
- python3-cffi, python3-cffi-backend-dbg,
- python3-all-dev, python3-all-dbg, python3-greenlet (>= 0.4.15),
+ python3-cffi,
+ python3-all-dev, python3-greenlet (>= 0.4.15),
  python3-repoze.sphinx.autointerface,
  python3-sphinx,
  python3-sphinxcontrib.programoutput,
- cython3, cython3-dbg,
+ cython3,
  libev-dev, libc-ares-dev, libuv1-dev
 Standards-Version: 4.5.1
 Section: python
@@ -35,20 +35,7 @@
 Depends: ${shlibs:Depends}, ${misc:Depends}, ${python3:Depends}, 
python3-greenlet
 Provides: ${python3:Provides}
 XB-Python-Version: ${python3:Versions}
-Suggests: python-gevent-doc, python3-gevent-dbg, python3-openssl
+Suggests: python-gevent-doc, python3-openssl
 Description: gevent is a coroutine-based Python networking library
  gevent uses greenlet to provide a high-level synchronous API on top of
  libevent event loop.
-
-Package: python3-gevent-dbg
-Section: debug
-Architecture: any
-Depends: ${misc:Depends}, python3-gevent (= ${binary:Version}), 
${shlibs:Depends}, ${python3:Depends},
- python3-greenlet-dbg
-Provides: ${python3:Provides}
-XB-Python-Version: ${python3:Versions}
-Description: gevent is a coroutine-based Python networking library - debugging 
symbols
- gevent uses greenlet to provide a high-level synchronous API on top of
- libevent event loop.
- .
- This is the debugging symbols for gevent.
diff -Nru python-gevent-20.9.0/debian/rules python-gevent-20.9.0/debian/rules
--- python-gevent-20.9.0/debian/rules   2021-03-02 04:07:52.0 +0100
+++ python-gevent-20.9.0/debian/rules   2021-10-08 16:20:30.0 +0200
@@ -56,20 +56,11 @@
 override_dh_compress:
dh_compress -X.js -X_static/* -X _sources/* -X_sources/*/* -X.inv
 
-override_dh_strip:
-ifeq (,$(filter nostrip,$(DEB_BUILD_OPTIONS)))
-   dh_strip -p python3-gevent --dbg-package=python3-gevent-dbg
-endif
-
 # TODO: check for failures, but disable for now
 override_dh_auto_test:
 #  chmod +x $(CURDIR)/src/greentest/testrunner.py
 #  cd $(CURDIR)/src/greentest && PYTHONPATH=../.. ./testrunner.py
 
-override_dh_installdocs-arch:
-   dh_installdocs -ppython3-gevent-dbg --link-doc=python3-gevent
-   dh_installdocs -a
-
 override_dh_installdocs-indep:
dh_installdocs -i
# remove privacy tracking links

Bug#995942: /usr/bin/ibus-ui-emojier-plasma: does not show any emojis

2021-10-08 Thread Tobias Kölsch

Package: plasma-desktop
Version: 4:5.21.5-2
Severity: normal
File: /usr/bin/ibus-ui-emojier-plasma
X-Debbugs-Cc: t.koel...@badgersystems.de

Dear Maintainer,

I`ve installed sid about a year ago and updated the system about once a month 
or so. After the last update, when starting the emoji selector with 
/usr/bin/ibus-ui-emojier-plasma comes up without any emojis. Apart from the 
missing emojis the GUI looks normal. On the command line the command yields the 
following message:

kf.kirigami: Units.devicePixelRatio is deprecated (since 5.86 ): This returns 1 
when using Qt HiDPI scaling.
qml: There's no page to replace
QQmlComponent: Component is not ready
file:///usr/lib/x86_64-linux-gnu/qt5/qml/org/kde/kirigami.2/PageRow.qml:803: 
Error: Error while loading page: qrc:/ui/CategoryPage.qml:100 Cannot assign to 
property of unknown type "QAbstractItemModel*".

qrc:/ui/CategoryAction.qml:42: ReferenceError: i18nd is not defined
qrc:/ui/CategoryAction.qml:41: TypeError: Cannot read property 'title' of 
undefined
qrc:/ui/CategoryAction.qml:42: ReferenceError: i18nd is not defined
qrc:/ui/CategoryAction.qml:41: TypeError: Cannot read property 'title' of 
undefined
qrc:/ui/CategoryAction.qml:42: ReferenceError: i18nd is not defined
qrc:/ui/CategoryAction.qml:41: TypeError: Cannot read property 'title' of 
undefined
qrc:/ui/CategoryAction.qml:42: ReferenceError: i18nd is not defined
qrc:/ui/CategoryAction.qml:41: TypeError: Cannot read property 'title' of 
undefined
qrc:/ui/CategoryAction.qml:42: ReferenceError: i18nd is not defined
qrc:/ui/CategoryAction.qml:41: TypeError: Cannot read property 'title' of 
undefined
qrc:/ui/CategoryAction.qml:42: ReferenceError: i18nd is not defined
qrc:/ui/CategoryAction.qml:41: TypeError: Cannot read property 'title' of 
undefined
qrc:/ui/CategoryAction.qml:42: ReferenceError: i18nd is not defined
qrc:/ui/CategoryAction.qml:41: TypeError: Cannot read property 'title' of 
undefined
qrc:/ui/CategoryAction.qml:42: ReferenceError: i18nd is not defined
qrc:/ui/CategoryAction.qml:41: TypeError: Cannot read property 'title' of 
undefined
qrc:/ui/CategoryAction.qml:42: ReferenceError: i18nd is not defined
qrc:/ui/CategoryAction.qml:41: TypeError: Cannot read property 'title' of 
undefined
qrc:/ui/CategoryAction.qml:42: ReferenceError: i18nd is not defined
qrc:/ui/CategoryAction.qml:41: TypeError: Cannot read property 'title' of 
undefined
qrc:/ui/emojier.qml:95: ReferenceError: i18n is not defined
qrc:/ui/emojier.qml:65: ReferenceError: i18n is not defined
qrc:/ui/emojier.qml:64: TypeError: Cannot read property 'title' of undefined
qrc:/ui/emojier.qml:76: ReferenceError: i18n is not defined
qrc:/ui/emojier.qml:75: TypeError: Cannot read property 'title' of undefined
qrc:/ui/CategoryAction.qml:41: TypeError: Cannot read property 'title' of 
undefined
qrc:/ui/emojier.qml:87: ReferenceError: i18n is not defined

Kindly,
   Tobias

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

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

Versions of packages plasma-desktop depends on:
ii  accountsservice  0.6.55-3
ii  breeze   4:5.21.5-2
ii  kactivitymanagerd5.21.5-2
ii  kde-cli-tools4:5.21.5-2
ii  kded55.86.0-1
ii  kio  5.86.0-1
ii  kpackagetool55.86.0-1
ii  libaccounts-qt5-11.16-2
ii  libc62.32-4
ii  libcrypt11:4.4.25-2
ii  libglib2.0-0 2.70.0-1+b1
ii  libibus-1.0-51.5.25-2
ii  libkaccounts24:21.08.0-1
ii  libkf5activities55.86.0-1
ii  libkf5activitiesstats1   5.86.0-1
ii  libkf5authcore5  5.86.0-1
ii  libkf5baloo5 5.86.0-1
ii  libkf5codecs55.86.0-1
ii  libkf5completion55.86.0-1
ii  libkf5configcore55.86.0-1
ii  libkf5configgui5 5.86.0-1
ii  libkf5configwidgets5 5.86.0-1
ii  libkf5coreaddons55.86.0-1
ii  libkf5crash5 5.86.0-1
ii  libkf5dbusaddons55.86.0-1
ii  libkf5declarative5   5.86.0-1
ii  libkf5globalaccel-bin5.86.0-1
ii  libkf5globalaccel5   5.86.0-1
ii  libkf5guiaddons5 5.86.0-1
ii  libkf5i18n5

Bug#995906: gitlab: Upgrading buster to bullseye needs some more gitlab-apt-pin-preferences adjustments

2021-10-08 Thread Pirate Praveen




On 8 October 2021 11:23:05 am IST, "Patrick Matthäi"  
wrote:
>Package: gitlab
>Version: 14.1.7+ds1-2~fto11+1
>Severity: important
>
>Hi,
>
>I am just upgrading our buster gitlab (13.12.8+ds1-1~fto10+1) to bullseye 
>(14.1.7+ds1-2~fto11+1)
>along with the whole system.
>On upgrading I get some errors like:
>
>Could not find gem 'bootsnap (~> 1.4)' in any of the gem sources listed in 
>your Gemfile.
>dpkg: Fehler beim Bearbeiten des Paketes gitlab (--configure):
> »installiertes gitlab-Skript des Paketes post-installation«-Unterprozess gab 
> den Fehlerwert 1 zurück
>gitaly (14.1.7+dfsg-1~fto11+1) wird eingerichtet ...
>Could not find gem 'rbtrace' in any of the gem sources listed in your Gemfile.
>
>or:
>
>gitaly (14.1.7+dfsg-1~fto11+1) wird eingerichtet ...
>Resolving dependencies...
>Bundler could not find compatible versions for gem "ffi":
>  In Gemfile:
>rbtrace was resolved to 0.4.11, which depends on
>  ffi (>= 1.0.6) x86_64-linux
>Could not find gem 'ffi (>= 1.0.6)', which is required by gem 'rbtrace', in 
>any of the sources.
>dpkg: Fehler beim Bearbeiten des Paketes gitaly (--configure):
>
>To solve it after the failed dist-upgrade I had to install the following 
>versions:
>
>  apt install ruby-bootsnap=1.4.6-1+b2 ruby-rbtrace=0.4.11-3+b3 
> ruby-ffi=1.12.2+dfsg-2+b3 ruby-character-set/bullseye 
> ruby-concurrent/bullseye ruby-concurrent-ext/bullseye 
> ruby-enumerable-statistics/bullseye ruby-gpgme/bullseye 
> ruby-grape-path-helpers=1.6.3-1~bpo11+1 ruby-hitimes/bullseye 
> ruby-js-regex/bullseye ruby-json/bullseye ruby-murmurhash3/bullseye 
> ruby-pg/bullseye ruby-prof/bullseye ruby-re2/bullseye ruby-redcloth/bullseye 
> ruby-rinku/bullseye ruby-stackprof/bullseye ruby-unf-ext/bullseye 
> ruby-yajl/bullseye unicorn/bullseye
>
>The main problem is, that most packages are not upgraded from the fto10 
>version to
>the bullseye one, because the fto10 version was "higher".

This is documented here
https://wiki.debian.org/gitlab/buster

I don't think pin preferences will work for "downgrades".

>Thanks for your great work :-)

You are welcome :)

>
>
>-- System Information:
>Debian Release: 11.0
>  APT prefers stable-updates
>  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
> 'stable')
>Architecture: amd64 (x86_64)
>
>Kernel: Linux 5.10.0-8-amd64 (SMP w/2 CPU threads)
>Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not 
>set
>Shell: /bin/sh linked to /bin/dash
>Init: systemd (via /run/systemd/system)
>LSM: AppArmor: enabled

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Bug#995941: apt: tries to autoremove currently running kernel

2021-10-08 Thread Felipe Sateler

Package: apt
Version: 2.3.9
Severity: important

Dear Maintainer,


apt is trying to autoremove the currently running kernel:

% uname -r
5.14.0-1-amd64
% sudo apt autoremove --dry-run
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following packages will be REMOVED:
  linux-image-5.14.0-1-amd64
0 upgraded, 0 newly installed, 1 to remove and 0 not upgraded.
Remv linux-image-5.14.0-1-amd64 [5.14.6-3]
% dpkg -l | grep linux-image | grep '^ii'
ii  linux-image-5.14.0-1-amd64 5.14.6-3 
  amd64Linux 5.14 for 64-bit PCs (signed)
ii  linux-image-5.14.0-2-amd64 5.14.9-2 
  amd64Linux 5.14 for 64-bit PCs (signed)
ii  linux-image-amd64  5.14.9-2 
  amd64Linux for 64-bit PCs (meta-package)


According to [1], apt should always keep the currently booted kernel.


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

-- Package-specific info:

-- apt-config dump --

APT "";
APT::Architecture "amd64";
APT::Build-Essential "";
APT::Build-Essential:: "build-essential";
APT::Install-Recommends "1";
APT::Install-Suggests "0";
APT::Sandbox "";
APT::Sandbox::User "_apt";
APT::Authentication "";
APT::Authentication::TrustCDROM "true";
APT::LastInstalledKernel "5.14.0-2-amd64";
APT::NeverAutoRemove "";
APT::NeverAutoRemove:: "^postgresql.*-12";
APT::NeverAutoRemove:: "^postgresql.*-13";
APT::NeverAutoRemove:: "^postgresql.*-14";
APT::Update "";
APT::Update::Post-Invoke-Success "";
APT::Update::Post-Invoke-Success:: "/usr/bin/test -e 
/usr/share/dbus-1/system-services/org.freedesktop.PackageKit.service && 
/usr/bin/test -S /var/run/dbus/system_bus_socket && /usr/bin/gdbus call 
--system --dest org.freedesktop.PackageKit --object-path 
/org/freedesktop/PackageKit --timeout 4 --method 
org.freedesktop.PackageKit.StateHasChanged cache-update > /dev/null; /bin/echo 
> /dev/null";
APT::Update::Post-Invoke-Success:: "if /usr/bin/test -w /var/cache/app-info -a 
-e /usr/bin/appstreamcli; then appstreamcli refresh-cache > /dev/null || true; 
fi";
APT::Architectures "";
APT::Architectures:: "amd64";
APT::Compressor "";
APT::Compressor::. "";
APT::Compressor::.::Name ".";
APT::Compressor::.::Extension "";
APT::Compressor::.::Binary "";
APT::Compressor::.::Cost "0";
APT::Compressor::zstd "";
APT::Compressor::zstd::Name "zstd";
APT::Compressor::zstd::Extension ".zst";
APT::Compressor::zstd::Binary "false";
APT::Compressor::zstd::Cost "60";
APT::Compressor::lz4 "";
APT::Compressor::lz4::Name "lz4";
APT::Compressor::lz4::Extension ".lz4";
APT::Compressor::lz4::Binary "false";
APT::Compressor::lz4::Cost "50";
APT::Compressor::gzip "";
APT::Compressor::gzip::Name "gzip";
APT::Compressor::gzip::Extension ".gz";
APT::Compressor::gzip::Binary "gzip";
APT::Compressor::gzip::Cost "100";
APT::Compressor::gzip::CompressArg "";
APT::Compressor::gzip::CompressArg:: "-6n";
APT::Compressor::gzip::UncompressArg "";
APT::Compressor::gzip::UncompressArg:: "-d";
APT::Compressor::xz "";
APT::Compressor::xz::Name "xz";
APT::Compressor::xz::Extension ".xz";
APT::Compressor::xz::Binary "xz";
APT::Compressor::xz::Cost "200";
APT::Compressor::xz::CompressArg "";
APT::Compressor::xz::CompressArg:: "-6";
APT::Compressor::xz::UncompressArg "";
APT::Compressor::xz::UncompressArg:: "-d";
APT::Compressor::bzip2 "";
APT::Compressor::bzip2::Name "bzip2";
APT::Compressor::bzip2::Extension ".bz2";
APT::Compressor::bzip2::Binary "bzip2";
APT::Compressor::bzip2::Cost "300";
APT::Compressor::bzip2::CompressArg "";
APT::Compressor::bzip2::CompressArg:: "-6";
APT::Compressor::bzip2::UncompressArg "";
APT::Compressor::bzip2::UncompressArg:: "-d";
APT::Compressor::lzma "";
APT::Compressor::lzma::Name "lzma";
APT::Compressor::lzma::Extension ".lzma";
APT::Compressor::lzma::Binary "xz";
APT::Compressor::lzma::Cost "400";
APT::Compressor::lzma::CompressArg "";
APT::Compressor::lzma::CompressArg:: "--format=lzma";
APT::Compressor::lzma::CompressArg:: "-6";
APT::Compressor::lzma::UncompressArg "";
APT::Compressor::lzma::UncompressArg:: "--format=lzma";
APT::Compressor::lzma::UncompressArg:: "-d";
Dir "/";
Dir::State "var/lib/apt";
Dir::State::lists "lists/";
Dir::State::cdroms "cdroms.list";
Dir::State::extended_states "extended_states";
Dir::State::status "/var/lib/dpkg/status";
Dir::Cache "var/cache/apt";
Dir::Cache::archives "archives/";
Dir::Cache::srcpkgcache "srcpkgcache.bin";
Dir::Cache::pkgcache "pkgcache.bin";
Dir::Etc "etc/apt";
Dir::Etc::sourcelist "sources.list";
Dir::Etc::sourceparts "sources.list.d";
Dir::Etc::main "apt.conf";
Dir::Etc::netrc "auth.conf";
Dir::Etc::netrcparts "auth.conf.d";
Dir::Etc::parts "apt.conf.d";
Dir::Etc::preferences "preferences";
Dir::Etc::preferencesparts "preferences.d";
Dir::Etc::trusted "trusted.gpg";
Dir::Etc::trustedparts "trusted.gpg.d";
Dir::Etc::apt-listchanges-main "listchanges.conf";
Dir::Etc::apt-listchanges-parts

Bug#995940: Shim contains a bug that prevents me from installing Debian

2021-10-08 Thread Benedikt Stepanek

Package: shim-signed
Version: 1.38+15.4-7
Severity: important

Hey,

An update that was introduced with Shim 15.3 and that is also present in Shim 
15.4 prevents me and others from installing and running Debian since 10.10 and 
including 11. I can't even boot the installer on my Fujitsu Lifebook with an 
InsydeH20 1.18 UEFI (with and without secure boot enabled). I directly get the 
following error message:

set_second_stage() failed: Invalid Parameter
Something has gone seriously wrong: shim_init() failed: Invalid Parameter

I assume that this behaviour was introduced with this commit 
(https://github.com/rhboot/shim/commit/018b74d2d69ef35b43b79709f2ea60325f12dde2)
 and Steve assumes, that it already has been fixed with commit 
ada7ff69bd8a95614aa63dd618764daf428f235d. This fix should be relatively easy to 
implement and backport.

Best regards

Bug#994715: RM: jmol-applet -- ROM; now unmaintained upstream

2021-10-08 Thread Adrian Bunk

Control: tags -1 moreinfo

On Sun, Sep 19, 2021 at 09:28:59PM +0200, Pierre Gruet wrote:
>...
> Could you please remove the binary package jmol-applet from unstable?
> It is one of the four binary packages built from src:jmol.
>...

The main thing that has to happen is that src:jmol stops building jmol-applet.

Cruft removal of jmol-applet is expected to happen automatically without 
human intervention after such a src:jmol has been uploaded to unstable.

cu
Adrian

Bug#995939: Creating an LXC testbed for Ubuntu fails due to lxc-create trying to use the Debian mirrors for Ubuntu releases

2021-10-08 Thread Daniel Leidert

Package: debci
Version: 3.2
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

I tried to do this:

  debci setup -s focal

and it fails due to

$ sudo debci setup -s focal
[..]
I: Running command: debootstrap --verbose --components=main,universe 
--arch=amd64 --include=eatmydata,language-pack-en focal 
/var/cache/lxc/focal/partial-amd64 http://deb.debian.org/debian
[..]
E: Failed getting release file http://deb.debian.org/debian/dists/focal/Release
lxc-create: autopkgtest-focal-amd64: lxccontainer.c: create_run_template: 1621 
Failed to create container from template
[..]

Please note that deboostrap is called with the Debian archive URL. After
digging into the issue the problem is that
/usr/share/debci/backends/lxc/create-testbed runs
/usr/share/debci/lib/environment.sh and this exports MIRROR to the default
value pointing to Debian. This value never gets overwritten independent of the
actual distribution targetted. lxc-create seems to honor this environment
variable and thus sets the mirror to the Debian repository URL, although it
would use the correct URL otherwise.

Pleaes consider these solutions:

- - set MIRROR to the correct value after determining the mirror URL
- - unset MIRROR for Debian and Ubuntu (I guess lxc-create is able to handle
  them; not sure about Kali Linux though)

Regards, Daniel



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

Kernel: Linux 5.14.0-1-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 debci depends on:
ii  adduser 3.118
ii  amqp-tools  0.10.0-1
ii  curl7.74.0-1.3+b1
ii  dctrl-tools 2.24-3+b1
ii  debian-archive-keyring  2021.1.1
ii  debootstrap 1.0.123
ii  devscripts  2.21.4
ii  distro-info 1.0
ii  fonts-font-awesome  5.0.10+really4.7.0~dfsg-4.1
ii  jq  1.6-2.1
ii  libjs-bootstrap 3.4.1+dfsg-2
ii  libjs-jquery3.5.1+dfsg+~3.5.5-7
ii  libjs-jquery-flot   4.2.1+dfsg-5
ii  moreutils   0.65-1
ii  parallel20210822+ds-2
ii  patchutils  0.4.2-1
ii  retry   1.0.4-3
ii  rsync   3.2.3-8
ii  ruby1:2.7.5
ii  ruby-activerecord   2:6.0.3.7+dfsg-2
ii  ruby-bunny  2.14.4-4
ii  ruby-erubi  1.9.0-1
ii  ruby-kaminari-activerecord  1.2.1-1
ii  ruby-omniauth-gitlab1.0.2-1
ii  ruby-pg 1.2.3-1+b1
ii  ruby-sinatra2.0.8.1-2
ii  ruby-sinatra-contrib2.0.8.1-2
ii  ruby-sqlite31.4.2-3
ii  ruby-thor   1.0.1-1
ii  sudo1.9.5p2-3

Versions of packages debci recommends:
ii  systemd-timesyncd [time-daemon]  247.9-4

Versions of packages debci suggests:
pn  apt-cacher-ng   
ii  auto-apt-proxy  13.4

- -- Configuration Files:
/etc/sudoers.d/debci [Errno 13] Keine Berechtigung: '/etc/sudoers.d/debci'

- -- no debconf information

- -- debsums errors found:
debsums: changed file /usr/share/debci/backends/lxc/create-testbed (from debci 
package)

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEvu1N7VVEpMA+KD3HS80FZ8KW0F0FAmFgTSYACgkQS80FZ8KW
0F2lKxAAilqzF07uioUuNNqHjIzmw1B7Wa3Acbtveu5W6jzRKTEWIpG0z4befZMX
1ZB7hoJs5XctTeDMpSknY5KCQRbmcAYC4rCamuABxML2lsHtKJGaMpWXndv6wPEO
Ec2NOcuJHf7rUCSrMl4SWFqr6uO05JCWI2ypu5WovDZsFE1qpbEdxrHV539m5H0h
TxTl8pw2PudhSIXba+4UlhgPRYlSexOQXf7j9nSkZKFLp9ExNO+3OVK4n1Dqjirp
DkNMXK04OUF3MZ0fMQJqL5EAG1AtNUqphqjc0ZyVhtYZXNGA+YBMFhp5t8yHIFX0
T1dF8hXi5rPxbpFOORONqZ13f9MXEpu2b1AehvNzco/WmCitmlltNausPasLB9is
rwgefPcxe8KZsXn/Ci10FdPePD8t7rdIQO8P51z5KLcyw3z3WM4JUUQ0A3wciLUE
WQ6+YUWds9s04rTvNWafWrY5fkLiv1ni7TNJ0cACq/0giCNfa0XPEUJbMn/g9fdZ
LysypizGTPx/z1Y4FnM/4GL97TvrFMaD7iz+dgUjr0IwxPBl27aE2TlyV6P0rWNJ
b5fzHHxfcBlBWzOeBg0UyYUDCfS4KWNJY8ByT9jcw1hB6qhh+A6hEiPbMw/klke1
89XvdebirTUkpv5/Wq9SbmxP/Y+zxw9Z6C5wPiJ9I/GtlDNRPzI=
=Tfjh
-END PGP SIGNATURE-

Bug#974064: [Pkg-javascript-devel] Bug#974064: node-client-sessions: Remove dependency to (deprecated) node-request

Le 08/10/2021 à 12:09, Andrius Merkys a écrit :
> Hi,
> 
> On 2021-10-08 11:43, Yadd wrote:
>> Take a look at
>> https://github.com/sindresorhus/got/blob/main/documentation/migration-guides/request.md
> 
> Thanks for the link. I recall trying to follow these guidelines, but I
> dropped the ball on it.
> 
> However, the package seems abandoned upstream and is reportedly broken
> [1]. It would be better to find a more up-to-date fork.
> 
> [1] https://github.com/mozilla/node-client-sessions/issues/150

Hi,

open a RC-bug for this

Bug#995938: ITP: r-cran-scs -- Splitting Conic Solver

2021-10-08 Thread Steffen Moeller

Package: wnpp
Severity: wishlist

Subject: ITP: r-cran-scs -- Splitting Conic Solver
Package: wnpp
Owner: Steffen Moeller 
Severity: wishlist

* Package name: r-cran-scs
  Version : 1.3
  Upstream Author : Florian Schwendinger
* URL : https://cran.r-project.org/package=scs
* License : GPL-3
  Programming Lang: GNU R
  Description : Splitting Conic Solver
 Solves convex cone programs via operator splitting. Can solve: linear
 programs ('LPs'), second-order cone programs ('SOCPs'), semidefinite
 programs ('SDPs'), exponential cone programs ('ECPs'), and power cone
 programs ('PCPs'), or problems with any combination of those cones.
 'SCS' uses 'AMD' (a set of routines for permuting sparse matrices prior
 to factorization) and 'LDL' (a sparse 'LDL' factorization and solve
 package) from 'SuiteSparse' ().

Remark: This package is maintained by Debian R Packages Maintainers at
   https://salsa.debian.org/r-pkg-team/r-cran-scs

Bug#995937: Debmirror fails to mirror command-not-found metadata files

2021-10-08 Thread Homulvas

Package: debmirror

Version: 1:2.32

Debmirror fails to mirror certain repositories since support for cnf was
added

/usr/bin/debmirror --verbose --diff=none --rsync-extra=none --arch=amd64
--dist=jessie/updates,stretch/updates,buster/updates,bullseye-security
--section=main,contrib,non-free --host=security.debian.org
--root=/debian-security --method=http /srv/packages/debian-security/
Mirroring to /srv/packages/debian-security/ from
http://security.debian.org/debian-security/
Arches: amd64
Dists: jessie/updates,stretch/updates,buster/updates,bullseye-security
Sections: main,contrib,non-free
Including source.
Pdiff mode: none
Will clean up after mirroring.
Attempting to get lock ...
Getting meta files ...
[  0%] Getting: dists/jessie/updates/Release... ok
[  0%] Getting: dists/jessie/updates/InRelease... ok
[  0%] Getting: dists/jessie/updates/Release.gpg... ok
gpgv: Signature made Sun 05 Jul 2020 06:06:01 PM UTC
gpgv:using RSA key D21169141CECD440F2EB8DDA9D6D8F6BC857C906
gpgv: Good signature from "Debian Security Archive Automatic Signing Key
(8/jessie) "
gpgv: Signature made Sun 05 Jul 2020 06:06:01 PM UTC
gpgv:using RSA key 379483D8B60160B155B372DDAA8E81B4331F7F50
gpgv: Good signature from "Debian Security Archive Automatic Signing Key
(9/stretch) "
gpgv: Signature made Sun 05 Jul 2020 06:06:01 PM UTC
gpgv:using RSA key D21169141CECD440F2EB8DDA9D6D8F6BC857C906
gpgv: Good signature from "Debian Security Archive Automatic Signing Key
(8/jessie) "
gpgv: Signature made Sun 05 Jul 2020 06:06:01 PM UTC
gpgv:using RSA key 379483D8B60160B155B372DDAA8E81B4331F7F50
gpgv: Good signature from "Debian Security Archive Automatic Signing Key
(9/stretch) "
[  0%] Getting: dists/stretch/updates/Release... ok
[  0%] Getting: dists/stretch/updates/InRelease... ok
[  0%] Getting: dists/stretch/updates/Release.gpg... ok
gpgv: Signature made Wed 06 Oct 2021 08:48:03 PM UTC
gpgv:using RSA key 379483D8B60160B155B372DDAA8E81B4331F7F50
gpgv: Good signature from "Debian Security Archive Automatic Signing Key
(9/stretch) "
gpgv: Signature made Wed 06 Oct 2021 08:48:03 PM UTC
gpgv:using RSA key 5237CEEEF212F3D51C74ABE0112695A0E562B32A
gpgv: Good signature from "Debian Security Archive Automatic Signing Key
(10/buster) "
gpgv: Signature made Wed 06 Oct 2021 08:48:03 PM UTC
gpgv:using RSA key 379483D8B60160B155B372DDAA8E81B4331F7F50
gpgv: Good signature from "Debian Security Archive Automatic Signing Key
(9/stretch) "
gpgv: Signature made Wed 06 Oct 2021 08:48:03 PM UTC
gpgv:using RSA key 5237CEEEF212F3D51C74ABE0112695A0E562B32A
gpgv: Good signature from "Debian Security Archive Automatic Signing Key
(10/buster) "
[  0%] Getting: dists/buster/updates/Release... ok
[  0%] Getting: dists/buster/updates/InRelease... ok
[  0%] Getting: dists/buster/updates/Release.gpg... ok
gpgv: Signature made Wed 06 Oct 2021 08:48:03 PM UTC
gpgv:using RSA key 5237CEEEF212F3D51C74ABE0112695A0E562B32A
gpgv: Good signature from "Debian Security Archive Automatic Signing Key
(10/buster) "
gpgv: Signature made Wed 06 Oct 2021 08:48:03 PM UTC
gpgv:using RSA key ED541312A33F1128F10B1C6C54404762BBB6E853
gpgv: Good signature from "Debian Security Archive Automatic Signing Key
(11/bullseye) "
gpgv: Signature made Wed 06 Oct 2021 08:48:03 PM UTC
gpgv:using RSA key 5237CEEEF212F3D51C74ABE0112695A0E562B32A
gpgv: Good signature from "Debian Security Archive Automatic Signing Key
(10/buster) "
gpgv: Signature made Wed 06 Oct 2021 08:48:03 PM UTC
gpgv:using RSA key ED541312A33F1128F10B1C6C54404762BBB6E853
gpgv: Good signature from "Debian Security Archive Automatic Signing Key
(11/bullseye) "
[  0%] Getting: dists/bullseye-security/Release... ok
[  0%] Getting: dists/bullseye-security/InRelease... ok
[  0%] Getting: dists/bullseye-security/Release.gpg... ok
gpgv: Signature made Wed 06 Oct 2021 08:48:02 PM UTC
gpgv:using RSA key 5237CEEEF212F3D51C74ABE0112695A0E562B32A
gpgv: Good signature from "Debian Security Archive Automatic Signing Key
(10/buster) "
gpgv: Signature made Wed 06 Oct 2021 08:48:02 PM UTC
gpgv:using RSA key ED541312A33F1128F10B1C6C54404762BBB6E853
gpgv: Good signature from "Debian Security Archive Automatic Signing Key
(11/bullseye) "
gpgv: Signature made Wed 06 Oct 2021 08:48:02 PM UTC
gpgv:using RSA key 5237CEEEF212F3D51C74ABE0112695A0E562B32A
gpgv: Good signature from "Debian Security Archive Automatic Signing Key
(10/buster) "
gpgv: Signature made Wed 06 Oct 2021 08:48:02 PM UTC
gpgv:using RSA key ED541312A33F1128F10B1C6C54404762BBB6E853
gpgv: Good signature from "Debian Security Archive Automatic Signing Key
(11/bullseye) "
Parsing Packages and Sources files ...
Get Translation files ...
Get DEP-11 metadata files ...
Get command-not-found metadata files ...
Files to download: 554 MiB
[  0%]

Bug#995753: qimgv: Crashes trying to display video

2021-10-08 Thread Vladimir K

Confirming, the cause is partial mesa upgrade. 
Got the full mesa set from unstable today, no longer having this issue.

Bug#792580: Veri

2021-10-08 Thread ANGEL GEOVANNY ALMEIDA OLVERA


Good morning, it was unfair to keep me waiting indefinitely without any 
response.

Bug#995936: dh-elpa doesn't work on package versions with buildN or ubuntuN suffixes

2021-10-08 Thread Matthias Klose

Package: dh-elpa
Version: 2.0.8
Severity: minor

dh-elpa doesn't work on package versions with buildN or ubuntuN suffixes, errors
out with:

Invalid version syntax: ‘0.49build1’


patch at
http://launchpadlibrarian.net/562638722/dh-elpa_2.0.8_2.0.8ubuntu1.diff.gz

however the patch doesn't work yet, packages still ftbfs like
https://launchpadlibrarian.net/562650646/buildlog_ubuntu-impish-amd64.lbdb_0.49build1_BUILDING.txt.gz

any idea what's still missing?

Bug#995921: ITP: zydis -- fast and lightweight x86/x86-64 disassembler library

2021-10-08 Thread Andrea Pappacoda

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

* Package name: zydis
  Version : 3.1.0
  Upstream Author : zyantific 
* URL : https://zydis.re
* License : Expat
  Programming Lang: C
  Description : fast and lightweight x86/x86-64 disassembler library

Zydis is a fast x86/x86-64 disassembler library. It supports all x86 and AMD64
instructions and extensions, doesn't perform dynamic memory allocations, is
thread safe by design and has no third party dependency - not even libc.

This is a dependency of Dynarmic, a dependency of the yuzu emulator -
https://bugs.debian.org/947399


-BEGIN PGP SIGNATURE-

iIoEARYIADIWIQRm3vFSgpkMIZnvqAGooSioqxzuSQUCYWABQBQcYW5kcmVhQHBh
cHBhY29kYS5pdAAKCRCooSioqxzuSa4yAP9zuIB8s4Af/J7eg30H5isW45r4s2Zk
3x10ooxot55BLQEAxyDW1HsL4+5LnTFxtsXaPO0FQ/m7OQtypjt/zUQOiw0=
=39M5
-END PGP SIGNATURE-

Bug#958155: Guake 3.8.0

2021-10-08 Thread Maarten

Any chance that we will get an updated version of Guake uploaded to the
archive?
3.8.0 series is now around the corner, rc3 was released last week, and it
would be great to have the latest bugfixes/features/compatibility from the
latest version in the archive.

kind regards,

Maarten Fonville

Bug#995917: ITP: dynarmic -- ARM dynamic recompiler

2021-10-08 Thread Andrea Pappacoda

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

* Package name: dynarmic
  Version : 5
  Upstream Author : MerryMage 
* URL : https://github.com/merryhime/Dynarmic
* License : 0BSD
  Programming Lang: C++
  Description : ARM dynamic recompiler

Dynarmic is a dynamic recompiler for the ARMv6K, ARMv7A architecture, with
partial ARMv8 support.
.
In the pursuit of speed, some behavior not commonly depended upon is elided.
Therefore this emulator does not match spec.

This is a dependency of the yuzu emulator - https://bugs.debian.org/947399


-BEGIN PGP SIGNATURE-

iIoEARYIADIWIQRm3vFSgpkMIZnvqAGooSioqxzuSQUCYV/69BQcYW5kcmVhQHBh
cHBhY29kYS5pdAAKCRCooSioqxzuSX3DAQCRKKEaB7oTLyPyCrVanUKFklZSxRg2
hmUSgjyVbPJH7AD+NsQiKZw3wJKgcB0oOqgmLwVHn8qHkTOSONrlTq9rkAE=
=yXz0
-END PGP SIGNATURE-

Bug#995935: flatpak: GHSA-67h7-w3jq-vh4q: sandbox escape via recent VFS syscalls

Package: flatpak
Version: 0.5.0-1
Severity: important
Tags: security
Justification: user security hole
X-Debbugs-Cc: Debian Security Team 

https://github.com/flatpak/flatpak/security/advisories/GHSA-67h7-w3jq-vh4q

Flatpak 1.12.0 and 1.10.4 fix a security vulnerability in the portal
support. Some recently added syscalls were not blocked by the seccomp
rules which allowed the application to create sub-sandboxes which can
confuse the sandboxing verification mechanisms of the portal. This has
been addressed by extending the seccomp rules.

Mitigation: this does not affect the standard D-Bus session or system
buses, or the AT-SPI accessibility bus, due to the way Flatpak mediates
access to those sockets with a proxy. It can affect other AF_UNIX-based
protocols, potentially including X11, Wayland, PulseAudio and Pipewire.

Mitigation: this only affects users of relatively recent kernels.

This was unexpectedly unembargoed on my day off work, so I'm preparing
updated packages ASAP but it will take me a little while...

Will the security team want to issue a DSA for this?

smcv

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

2021-10-08 Thread Michael R . Crusoe

Package: python-gevent
Version: 20.9.0-2
Severity: normal
Tags: patch  pending


Dear maintainer,

I've prepared an NMU for python-gevent (versioned as 20.9.0-2.1) which fixes 
the serious bug "python-gevent build-depends on removed package" and
uploaded it to DELAYED/7. Please feel free to tell me if I
should delay it longer.

Like Sandro Tosi, I invite you to consider maintaining this package under Debian
Python Team.

Regards.

diff -Nru python-gevent-20.9.0/debian/changelog 
python-gevent-20.9.0/debian/changelog
--- python-gevent-20.9.0/debian/changelog   2021-03-02 06:55:02.0 
+0100
+++ python-gevent-20.9.0/debian/changelog   2021-10-08 13:32:45.0 
+0200
@@ -1,3 +1,13 @@
+python-gevent (20.9.0-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix upstream GitHub archive links
+  * No longer manually build a -dbg package. Closes: #995138, #994354
+  * debian/patches/drop_mysphinxext: cherry-picked from upstream, fixes a
+FTBFS.
+
+ -- Michael R. Crusoe   Fri, 08 Oct 2021 13:32:45 +0200
+
 python-gevent (20.9.0-2) unstable; urgency=medium
 
   * Fix dh_installdocs invocation in arch target (closes: #983825).
diff -Nru python-gevent-20.9.0/debian/control 
python-gevent-20.9.0/debian/control
--- python-gevent-20.9.0/debian/control 2021-01-05 20:03:08.0 +0100
+++ python-gevent-20.9.0/debian/control 2021-10-08 13:32:45.0 +0200
@@ -5,14 +5,13 @@
  dh-exec,
  libevent-dev (>= 1.4),
  python3-greenlet,
- python3-greenlet-dbg,
  python3-setuptools,
- python3-cffi, python3-cffi-backend-dbg,
- python3-all-dev, python3-all-dbg, python3-greenlet (>= 0.4.15),
+ python3-cffi,
+ python3-all-dev, python3-greenlet (>= 0.4.15),
  python3-repoze.sphinx.autointerface,
  python3-sphinx,
  python3-sphinxcontrib.programoutput,
- cython3, cython3-dbg,
+ cython3,
  libev-dev, libc-ares-dev, libuv1-dev
 Standards-Version: 4.5.1
 Section: python
@@ -35,20 +34,7 @@
 Depends: ${shlibs:Depends}, ${misc:Depends}, ${python3:Depends}, 
python3-greenlet
 Provides: ${python3:Provides}
 XB-Python-Version: ${python3:Versions}
-Suggests: python-gevent-doc, python3-gevent-dbg, python3-openssl
+Suggests: python-gevent-doc, python3-openssl
 Description: gevent is a coroutine-based Python networking library
  gevent uses greenlet to provide a high-level synchronous API on top of
  libevent event loop.
-
-Package: python3-gevent-dbg
-Section: debug
-Architecture: any
-Depends: ${misc:Depends}, python3-gevent (= ${binary:Version}), 
${shlibs:Depends}, ${python3:Depends},
- python3-greenlet-dbg
-Provides: ${python3:Provides}
-XB-Python-Version: ${python3:Versions}
-Description: gevent is a coroutine-based Python networking library - debugging 
symbols
- gevent uses greenlet to provide a high-level synchronous API on top of
- libevent event loop.
- .
- This is the debugging symbols for gevent.
diff -Nru python-gevent-20.9.0/debian/patches/drop_mysphinxext 
python-gevent-20.9.0/debian/patches/drop_mysphinxext
--- python-gevent-20.9.0/debian/patches/drop_mysphinxext1970-01-01 
01:00:00.0 +0100
+++ python-gevent-20.9.0/debian/patches/drop_mysphinxext2021-10-08 
13:32:45.0 +0200
@@ -0,0 +1,107 @@
+From 46b32bc7d34adb0df063eaca579c7a2164a76cc9 Mon Sep 17 00:00:00 2001
+From: Jason Madden 
+Date: Tue, 8 Dec 2020 05:39:11 -0600
+Subject: [PATCH] Remove mysphinxext.py. It seemed unused. (Fixes a FTBFS)
+
+Bumping its 'noisy' value up, while there were plenty of missing-reference
+events it got called for, it never actually printed the line that showed it
+resolved something.
+
+--- python-gevent.orig/docs/conf.py
 python-gevent/docs/conf.py
+@@ -19,8 +19,6 @@
+ # for better documentation extraction and ease of tweaking docs.
+ os.environ['PURE_PYTHON'] = '1'
+ 
+-sys.path.append(os.path.dirname(__file__))  # for mysphinxext
+-
+ # If extensions (or modules to document with autodoc) are in another 
directory,
+ # add these directories to sys.path here. If the directory is relative to the
+ # documentation root, use os.path.abspath to make it absolute, like shown 
here.
+@@ -45,9 +43,6 @@
+ # Third-party
+ 'repoze.sphinx.autointerface',
+ 'sphinxcontrib.programoutput',
+-
+-# Ours
+-'mysphinxext',
+ ]
+ 
+ intersphinx_mapping = {
+--- python-gevent.orig/docs/mysphinxext.py
 /dev/null
+@@ -1,74 +0,0 @@
+-from __future__ import print_function
+-from sphinx.ext.autodoc import cut_lines
+-from sphinx.ext import intersphinx
+-from docutils import nodes
+-
+-noisy = 0
+-message_cache = set()
+-
+-
+-def missing_reference(app, env, node, contnode):
+-"""Search the index for missing references.
+-For example, resolve :class:`Event` to :class:`Event 
`"""
+-# XXX methods and functions resolved by this function miss their ()
+-
+-if intersphinx.missing_reference(app, env, node, contnode) is not None:
+-# is there a better way to give intersphinx a bigger priority?
+-return
+-
+-env = app.builder.env
+-
+-type =

Bug#995933: smart-notifier: crashes: AttributeError: 'gi.repository.Gtk' object has no attribute 'main'

2021-10-08 Thread Paul Wise

Package: smart-notifier
Version: 0.28-7
Severity: serious
Usertags: crash

When smart-notifier starts, it crashes when starting the GUI service.
I assume that this means it will not notify about SMART errors,
please downgrade this bug if that isn't the case.

   $ smart-notifier 
   ...
   Traceback (most recent call last):
 File "/usr/bin/smart-notifier", line 14, in 
   smart_notifier.gui.service()
 File "/usr/share/smart-notifier/smart_notifier/gui.py", line 52, in service
   Gtk.main()
 File "/usr/lib/python3/dist-packages/gi/overrides/__init__.py", line 32, 
in __getattr__
   return getattr(self._introspection_module, name)
 File "/usr/lib/python3/dist-packages/gi/module.py", line 123, in 
__getattr__
   raise AttributeError("%r object has no attribute %r" % (
   AttributeError: 'gi.repository.Gtk' object has no attribute 'main'

-- System Information:
Debian Release: bookworm/sid
  APT prefers testing-debug
  APT policy: (900, 'testing-debug'), (900, 'testing'), (800, 
'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700, 
'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental')
Architecture: amd64 (x86_64)

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

Versions of packages smart-notifier depends on:
ii  dbus1.12.20-2
ii  gir1.2-gtk-3.0  3.24.30-3
ii  python3 3.9.2-3
ii  python3-dbus1.2.18-2
ii  python3-gi  3.42.0-1+b1
ii  smartmontools   7.2-1

smart-notifier recommends no packages.

smart-notifier suggests no packages.

-- no debconf information

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#995931: smart-notifier: gui.py:23: PyGIWarning: Gtk was imported without specifying a version first.

2021-10-08 Thread Paul Wise

Package: smart-notifier
Version: 0.28-7
Severity: normal
Usertags: warnings

When smart-notifier starts, PyGI prints a warning about incorrect Gtk
import style and suggests the right way to do the import:

   $ smart-notifier 
   /usr/share/smart-notifier/smart_notifier/gui.py:23: PyGIWarning: Gtk was 
imported without specifying a version first. Use gi.require_version('Gtk', 
'4.0') before import to ensure that the right version gets loaded.
 from gi.repository import Gtk

-- System Information:
Debian Release: bookworm/sid
  APT prefers testing-debug
  APT policy: (900, 'testing-debug'), (900, 'testing'), (800, 
'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700, 
'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental')
Architecture: amd64 (x86_64)

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

Versions of packages smart-notifier depends on:
ii  dbus1.12.20-2
ii  gir1.2-gtk-3.0  3.24.30-3
ii  python3 3.9.2-3
ii  python3-dbus1.2.18-2
ii  python3-gi  3.42.0-1+b1
ii  smartmontools   7.2-1

smart-notifier recommends no packages.

smart-notifier suggests no packages.

-- no debconf information

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#995916: std::stoi, std::stol, std::stoul, ... broken on sh4

Hi Mattias!

On 10/8/21 11:21, John Paul Adrian Glaubitz wrote:
> I will try to build cmake with gcc-11 and see if that makes any difference.

Building with gcc-11 fixes the problem and cmake builds fine.

Adrian

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

Bug#995930: gjs: FTBFS on armel|mipsel|powerpc: needs more -latomic

Source: gjs
Version: 1.70.0-1
Severity: serious
Tags: upstream ftbfs experimental pending
Justification: fails to build from source (but built successfully in the past)

gjs fails to link on armel, mipsel and powerpc, and maybe mips64el
(not tried yet):

> c++  -o libgjs.so.0.0.0 libgjs.so.0.0.0.p/meson-generated_.._js-resources.c.o 
> libgjs.so.0.0.0.p/libgjs-private_gjs-gdbus-wrapper.c.o 
> libgjs.so.0.0.0.p/libgjs-private_gjs-util.c.o -Wl,--as-needed 
> -Wl,--no-undefined -shared -fPIC -Wl,--start-group -Wl,-soname,libgjs.so.0 
> -Wl,--whole-archive libgjs-internal.a -Wl,--no-whole-archive 
> -Bsymbolic-functions -Wl,-z,relro -Wl,-z,now -Wl,-z,defs -g -O2 
> -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat 
> -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 libgjs-jsapi.a 
> -Wl,--version-script,/<>/libgjs.map 
> /usr/lib/arm-linux-gnueabi/libglib-2.0.so 
> /usr/lib/arm-linux-gnueabi/libgobject-2.0.so 
> /usr/lib/arm-linux-gnueabi/libgthread-2.0.so -pthread 
> /usr/lib/arm-linux-gnueabi/libgio-2.0.so 
> /usr/lib/arm-linux-gnueabi/libgirepository-1.0.so -lffi 
> /usr/lib/arm-linux-gnueabi/libmozjs-78.so -lreadline 
> /usr/lib/arm-linux-gnueabi/libcairo.so 
> /usr/lib/arm-linux-gnueabi/libcairo-gobject.so 
> /usr/lib/arm-linux-gnueabi/libX11.so /usr/lib/arm-linux-gnueabi/libXext.so 
> -lffi -lreadline -lffi -lreadline -Wl,--end-group
> /usr/bin/ld: libgjs-internal.a(gi_boxed.cpp.o): in function 
> `std::__atomic_base::fetch_add(long long, std::memory_order)':
> /usr/include/c++/10/bits/atomic_base.h:548: undefined reference to 
> `__atomic_fetch_add_8'

It needs a conditional dependency on libatomic, similar to what Mesa does.
I'm looking into it.

smcv

Bug#995929: mutter: FTBFS on armel|armhf|arm64: build-time test core+mutter/unit / normal times out

Source: mutter
Version: 41.0-1
Severity: serious
Tags: ftbfs experimental
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: debian-...@lists.debian.org

The new version of mutter in experimental includes a build-time unit test
"core+mutter/unit / normal" which succeeds in about 20 seconds on for example
i386 and ppc64el, but fails with a timeout (after 6 minutes) on all three
ARM-based release architectures: armel, armhf, arm64.

I initially suspected this might be because we are forcing GLES2 rather than
"big GL" on armel and armhf, but arm64 fails in the same way and is not
forcing use of GLES2. Maybe one of our dependencies, like perhaps Mesa or
X11, has a special case for all three ARM-based release architectures?

Any ideas?

smcv

Bug#974064: [Pkg-javascript-devel] Bug#974064: node-client-sessions: Remove dependency to (deprecated) node-request

2021-10-08 Thread Andrius Merkys

Hi,

On 2021-10-08 11:43, Yadd wrote:
> Take a look at
> https://github.com/sindresorhus/got/blob/main/documentation/migration-guides/request.md

Thanks for the link. I recall trying to follow these guidelines, but I
dropped the ball on it.

However, the package seems abandoned upstream and is reportedly broken
[1]. It would be better to find a more up-to-date fork.

[1] https://github.com/mozilla/node-client-sessions/issues/150

Best,
Andrius

Bug#995928: acorn: doc directory shipped by both binaries

2021-10-08 Thread Mattia Rizzolo

Source: acorn
Version: 8.0.5+ds+~cs19.19.27-3
Severity: serious
Control: fixed -1 8.5.0+ds+~cs23.9.6-2

This happens in bullseye:

root@warren:/# apt install node-acorn
...
The following NEW packages will be installed:
  libbrotli1 libc-ares2 libicu67 libnghttp2-14 libnode72 libuv1 node-acorn 
node-debbundle-acorn node-xtend nodejs
...
root@warren:/# apt install --reinstall node-debbundle-acorn
...
(Reading database ... 12963 files and directories currently installed.)
Preparing to unpack .../node-debbundle-acorn_8.0.5+ds+~cs19.19.27-3_all.deb ...
Unpacking node-debbundle-acorn (8.0.5+ds+~cs19.19.27-3) over 
(8.0.5+ds+~cs19.19.27-3) ...
(Noting disappearance of node-acorn, which has been completely replaced.)
Setting up node-debbundle-acorn (8.0.5+ds+~cs19.19.27-3) ...
The following package disappeared from your system as
all files have been overwritten by other packages:
  node-acorn
Note: This is done automatically and on purpose by dpkg.


This is due to node-acorn shipping /usr/share/doc/node-acorn (type:
symlink) which is *also* shipping by node-debbundle-acorn (type:
directory).
dpkg seems to always overwrite the symlink anyway, but it doesn't detect
that it's gone until later when reinstalling it.


To be honest, I'm not sure what was the wanted situation, but I *think*
the symlink is just wrong.  Looking at the content of the
/usr/share/doc/node-acorn/ directory as present in node-debbundle-acorn,
I think that is the appropriate content.  So, probably, the best fix is
to just get rid of the symlink from node-acorn, however that would leave
the package totally empty, which dpkg is not totally thrilled about.
So more likely at least the 2 symlinks of copyright and
changelog.Debian.gz in /usr/share/doc/node-acorn could be moved from
node-debbundle-acorn to node-acorn, so effectively shipping the
directory from both packages.



This is fixed in 8.5.0+ds+~cs23.9.6-2 by moving everything to node-acorn
and turning node-debbundle-acorn into a pure transitional package.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
More about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#995927: linux-image-amd64: since kernel 5.9 module e100 causes system-wide problems after suspend

2021-10-08 Thread hikaru

Package: linux-image-amd64
Version: 5.10.46-5
Severity: normal
Tags: upstream
X-Debbugs-Cc: hikaru.deb...@web.de

Dear Maintainers,

I own an old notebook with the following wired ethernet adapter:

07:08.0 Ethernet controller: Intel Corporation PRO/100 VE Network Connection 
(rev 02)
Subsystem: Fujitsu Technology Solutions PRO/100 VE Network Connection
Flags: bus master, medium devsel, latency 64, IRQ 20
Memory at dc00 (32-bit, non-prefetchable) [size=4K]
I/O ports at 5000 [size=64]
Capabilities: [dc] Power Management version 2
Kernel driver in use: e100
Kernel modules: e100

Under Bullseye (kernel 5.10), after a suspend2RAM/resume cycle, e100 causes
problems which seem to be related to "e100: use generic power management" [1],
which wass introduced with kernel 5.9. In the comment it says:
"Compile-tested only."


The symptoms are not always consistent, but usually they are as follows:

1. After resume, there is no network at all (not only via the wired adapter,
but also via the intel wifi adapter), at least for several (5?) minutes.
Network may or may not return after that time.

2. During that time, certain interactions with the system just stall -
especially those connected to network tasks (e.g. network-manager-gnome, ip).
In case "ip a" is successful it will usually show that there is a
network connection (ip adress obtained via dhcp), but no network activity is
possible (e.g. ping).
(I ruled out network manager as the culprit, by uninstalling it. The problems
remained the same.)

3. When performing a shutdown or reboot after such a suspend/resume cycle, the
operating system and the HDD will shut down, but the computer will not
actually power off/reboot. Instead it will stay on indefinitely while messages
like these remain on the screen:

Okt 06 18:32:19 amilo systemd[1]: Reached target Reboot.
Okt 06 18:32:19 amilo systemd[1]: Shutting down.
Okt 06 18:32:19 amilo systemd[1]: Using hardware watchdog 'iTCO_wdt', version 
0, device /dev/watchdog
Okt 06 18:32:19 amilo systemd[1]: Set hardware watchdog to 10min.
Okt 06 18:32:19 amilo kernel: watchdog: watchdog0: watchdog did not stop!
Okt 06 18:32:19 amilo systemd-shutdown[1]: Syncing filesystems and block 
devices.
Okt 06 18:32:19 amilo systemd-shutdown[1]: Sending SIGTERM to remaining 
processes...
Okt 06 18:32:19 amilo systemd-journald[213]: Journal stopped

4. During that shutdown the kernel may or may not throw exceptions, of
which I have a photo, but no easily accessible log.


Buster (kernel 4.19, up to bpo kernel 5.8) does not exhibit this behavior.
However, it does with bpo kernels 5.9 and 5.10.

The problems disappear (with kernels >= 5.9) when disabling the
ethernet adapter in the BIOS or when blacklisting e100.

For sake of transparency, I opened a thread in the unofficial German
debianforum.de, which led me to file this bug report. [2]


[1] 
https://github.com/torvalds/linux/commit/69a74aef8a18eef20fb0044b5e164af41b84db21
[2] https://debianforum.de/forum/viewtopic.php?f=26=182239

kind regards
hikaru


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

Kernel: Linux 5.10.0-8-amd64 (SMP w/2 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)

Versions of packages linux-image-amd64 depends on:
ii  linux-image-5.10.0-8-amd64  5.10.46-5

linux-image-amd64 recommends no packages.

linux-image-amd64 suggests no packages.

-- no debconf information

Bug#995926: Error validating Let's Encrypt cert chains

2021-10-08 Thread Andre Heider


Source: gnutls28
Version: 3.7.2-2

Apps using gnutls fail to connect to servers using a Let's Encrypt 
certificate which are cross-signed by the now expired DST Root CA X3, 
see [0].


Examples:

$ lftp https://shop.bbc.com
cd: Fatal error: Certificate verification: Not trusted 
(93:3C:6D:DE:E9:5C:9C:41:A4:0F:9F:50:49:3D:82:BE:03:AD:87:BF)


$ audacious https://stream.tonkuhle.de/tonkuhle.mp3
ERROR neon.cc:542 [open_request]: <0x7f68d4025660> Could not open URL: 1 (0)
ERROR neon.cc:545 [open_request]: <0x7f68d4025660> neon error string: 
Server certificate verification failed: bad certificate chain

ERROR neon.cc:756 [fopen]: <0x7f68d4025660> Could not open URL
ERROR util.cc:269 [audgui_simple_message]: Error playing 
https://stream.tonkuhle.de/tonkuhle.mp3:

Server certificate verification failed: bad certificate chain

[0] https://letsencrypt.org/docs/dst-root-ca-x3-expiration-september-2021/

Bug#974736: mupdf: new upstream version

On Mon, 1 Feb 2021 15:54:29 +0100 Bastian Germann wrote:

On Sat, 14 Nov 2020 13:24:21 +0100 Bastian Germann wrote:
> Source: mupdf
> Severity: normal
> 
> Please package the new upstream version 1.18.0.

Patch series enclosed. Please consider importing 1.18.0 soon so that it 
can be released with bullseye.

Version 1.19.0 is out now. Please import it to the archive. If you need any help, I could 
offer some. But as my 1.18.0 patches were not taken, I wait for you to come back to me.

Bug#995925: tpm2-tss: Latest version breaks tpm2-abrmd due to outdated udev rule

2021-10-08 Thread Gábor Gombás

Package: libtss2-sys1
Version: 3.1.0-3
Severity: normal

Hi,

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

Oct 08 06:02:07 twister systemd[1]: Dependency failed for TPM2 Access Broker 
and Resource Management Daemon.
Oct 08 06:02:07 twister systemd[1]: tpm2-abrmd.service: Job 
tpm2-abrmd.service/start failed with result 'dependency'.
Oct 08 09:03:56 twister systemd[1]: Dependency failed for TPM2 Access Broker 
and Resource Management Daemon.
Oct 08 09:03:56 twister systemd[1]: tpm2-abrmd.service: Job 
tpm2-abrmd.service/start failed with result 'dependency'.

Which is caused by:

$ systemctl status dev-tpm0.device 
● dev-tpm0.device - /dev/tpm0
 Loaded: loaded
 Active: inactive (dead)

Oct 08 06:02:07 twister systemd[1]: dev-tpm0.device: Job dev-tpm0.device/start 
timed out.
Oct 08 06:02:07 twister systemd[1]: Timed out waiting for device /dev/tpm0.
Oct 08 06:02:07 twister systemd[1]: dev-tpm0.device: Job dev-tpm0.device/start 
failed with result 'timeout'.
Oct 08 09:03:56 twister systemd[1]: dev-tpm0.device: Job dev-tpm0.device/start 
timed out.
Oct 08 09:03:56 twister systemd[1]: Timed out waiting for device /dev/tpm0.
Oct 08 09:03:56 twister systemd[1]: dev-tpm0.device: Job dev-tpm0.device/start 
failed with result 'timeout'.

... which in turn is caused by libtss2-sys1 depending on tpm-udev, but the UDEV
rule in tpm-udev is outdated:

$ diff -u /lib/udev/rules.d/60-tpm-udev.rules 
/tmp/t/tpm2-tss-3.1.0/dist/tpm-udev.rules 
--- /lib/udev/rules.d/60-tpm-udev.rules 2020-11-30 15:30:36.0 +0100
+++ /tmp/t/tpm2-tss-3.1.0/dist/tpm-udev.rules   2021-05-17 20:42:55.0 
+0200
@@ -1,4 +1,4 @@
 # tpm devices can only be accessed by the tss user but the tss
 # group members can access tpmrm devices
-KERNEL=="tpm[0-9]*", MODE="0660", OWNER="tss"
-KERNEL=="tpmrm[0-9]*", MODE="0660", OWNER="tss", GROUP="tss"
+KERNEL=="tpm[0-9]*", TAG+="systemd", MODE="0660", OWNER="tss"
+KERNEL=="tpmrm[0-9]*", TAG+="systemd", MODE="0660", OWNER="tss", GROUP="tss"

tpm-udev needs to be updated, and libtss2-sys1 needs a versioned dependency on
the fixed version. I wonder if tpm-udev should be built from the tpm2-tss
source package to ensure the udev rule does not get out of date.

Regards,
Gabor

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

Kernel: Linux 5.14.9 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libtss2-sys1 depends on:
ii  libc62.32-4
ii  libtss2-mu0  3.1.0-3
ii  tpm-udev 0.5

libtss2-sys1 recommends no packages.

libtss2-sys1 suggests no packages.

-- no debconf information

Bug#995924: wolfssl: New upstream version


Source: wolfssl
Version: 4.6.0-3

There are newer upstream versions available. v4.8.1 is available for a longer time, so it 
seems to be stable. Please import it to the archive.

Bug#995916: std::stoi, std::stol, std::stoul, ... broken on sh4

Hi Mattias!

On 10/8/21 09:54, Mattias Ellert wrote:
> The std::stoi, std::stol, std::stoul, ... functions should be available
> in two versions. One accepting a std::string and one accepting a
> std::wstring.
> 
> In g++ version 10.3.0-11 on sh4 only the std::wstring version is
> available, so when it tries to compile code that uses the std::string
> version it fails.
> 
> The problem is that for some reason the the file
> 
> /usr/include/sh4-linux-gnu/c++/10/bits/c++config.h
> 
> provided by libstdc++-10-dev_10.3.0-11_sh4.deb contains the line
> 
> /* #undef _GLIBCXX11_USE_C99_STDLIB */
> 
> The corresponding file for other architectures contains
> 
> #define _GLIBCXX11_USE_C99_STDLIB 1
> 
> This is a regression wrt earlier versions, since this used to work
> without problems.

Thanks so much for tracking this down. I have seen this issue before and
didn't understand what the problem was. At least I do now.

I will try to build cmake with gcc-11 and see if that makes any difference.

Adrian

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

Bug#995922: ruby-pgplot: please consider switching to giza

2021-10-08 Thread Youhei SASAKI

Hi,

Thanks to your helpfull information.
I'll try re-build and re-upload ruby-pgplots.

Best Wishes,
Youhei

On Fri, 08 Oct 2021 17:39:16 +0900,
Ole Streicher  wrote:
> 
> Source: ruby-pgplot
> Version: 0.2.0-1
> Severity: wishlist
> 
> Dear maintainer,
> 
> ruby-pgplot is currently in contrib because it depends on the non-free
> "pgplot5" package. There is however a DFSG-free replacement library
> "giza" available that provides a compatibility layer for pgplot. The
> compatibility is almost complete, so this may fulfill your needs. It
> maybe enough to just replace the pgplot5 build dependency with
> "giza-dev".
> 
> Switching to giza would allow to bring ruby-pgplot into Debians "main"
> archive, with the benefit of automated builds etc. Also, pgplot5 is dead
> upstream and maintained with NMUs since almost ten years now.
> 
> I am the maintainer of giza, and I am happy to help out if there are
> problems.
> 
> Best regards
> 
> Ole
>

Bug#995614: guile-3.0: Please build with --without-threads on alpha to fix FTBFS

On 10/8/21 05:08, Michael Cree wrote:
> I am still of the opinion that we should try in the first instance
> to find the real problem in the toolchain and fix it there.  The bug
> affects packages other than guile and only on SMP systems.

I'm not arguing against fixing this bug. But without building guile
with "--without-threads" we will have a large number of BD-Uninstallable
packages until this bug gets fixed.

And a guile interpreter that crashes on any SMP system.

> When I get my hands on Electro I can boot with a generic kernel
> and build guile-3.0 there which hopefully will overcome the memory
> exhaustion and time-out problems seen on the XP1000s.

That doesn't really help here though as the compiled guile package will
still crash on SMP systems and cause packages like gnul28 to FTBFS
on imago.

Adrian

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

Bug#995614: guile-3.0: Please build with --without-threads on alpha to fix FTBFS

On 10/8/21 03:13, Rob Browning wrote:
> And while we can, of course, rebuild all the reverse deps (presumably
> only acceptable for testing/sid), doing so may still break things for
> anyone outside debian who's been relying on our packages (if we'd ever
> had any in testing -- sounds like maybe we haven't for 3.0 for alpha).

But again, we're doing this all the time and this affects a non-release
architecture. I never said this flag should be passed for amd64 or arm64.

A compiled guile-2.2 and guile-3.0 will also crash immediately on any alpha
SMP system, so it never really worked. Only building both guile-2.2 and
guile-3.0 with "--without-threads" makes the package actually usable
on alpha.

So, I'm not sure how any outside user was supposed to be testing a guile
binary that was crashing all the time on SMP machines.

Adrian

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

Bug#982959: ifupdown: regex not workig as expected

2021-10-08 Thread Santiago Ruano Rincón

El 08/10/21 a las 10:32, Martin-Éric Racine escribió:
> ke 6. lokak. 2021 klo 15.19 Santiago Ruano Rincón
> (santiag...@riseup.net) kirjoitti:
> >
> > El 06/10/21 a las 12:28, Martin-Éric Racine escribió:
> > > ke 6. lokak. 2021 klo 12.20 Santiago Ruano Rincón
> > > (santiag...@riseup.net) kirjoitti:
> > > >
> > > > El 06/10/21 a las 09:24, Martin-Éric Racine escribió:
> > > > > la 2. lokak. 2021 klo 11.13 Michael Biebl (bi...@debian.org) 
> > > > > kirjoitti:
> > > > > >
> > > > > > Am 02.10.21 um 09:05 schrieb Martin-Éric Racine:
> > > > > > > pe 1. lokak. 2021 klo 23.39 Santiago Ruano Rincón
> > > > > > > (santiag...@riseup.net) kirjoitti:
> > > > > > >>
> > > > > > >> El 01/10/21 a las 17:05, Martin-Éric Racine escribió:
> > > > > > >>> pe 1. lokak. 2021 klo 16.21 Santiago Ruano Rincón
> > > > > > >>> (santiag...@riseup.net) kirjoitti:
> > > > > >  On Wed, 17 Feb 2021 14:32:24 +0200 Martin-Éric_Racine 
> > > > > >   wrote:
> > > > > > > Package: ifupdown
> > > > > > > Version: 0.8.36
> > > > > > > Severity: normal
> > > > > > >
> > > > > > > -BEGIN PGP SIGNED MESSAGE-
> > > > > > > Hash: SHA256
> > > > > > >
> > > > > > > The regex recipe below does not work as expected. I've tried 
> > > > > > > both
> > > > > > >
> > > > > > > allow-hotplug /en*=en /wl*=wl
> > > > > > >
> > > > > > > and
> > > > > > >
> > > > > > > allow-hotplug /en*/=en /wl*/=wl
> > > > > > >
> > > > > > > but ifup still doesn't raise whatever interface match the 
> > > > > > > regex. Have I misunderstood the examples or am I missing 
> > > > > > > something else?
> > > > > > >
> > > > > > > Thanks!
> > > > > > >
> > > > > > > - -- Package-specific info:
> > > > > > > - --- /etc/network/interfaces:
> > > > > > > allow-hotplug /en*=en /wl*=wl
> > > > > > >
> > > > > > > iface en inet dhcp
> > > > > > > iface en inet6 auto
> > > > > > >  privext 2
> > > > > > >  #dhcp 1
> > > > > > >
> > > > > > > iface wl inet dhcp
> > > > > > >  wpa-ssid AccessPoint
> > > > > > >  wpa-psk mypassword
> > > > > > > iface wl inet6 auto
> > > > > > >  privext 2
> > > > > > >  #dhcp 1
> > > > > > >>>
> > > > > > >>> [...]
> > > > > > >>>
> > > > > >  I get both interfaces configured. Could you please run ifup 
> > > > > >  with -v?
> > > > > > >>>
> > > > > > >>> I just tried. Here's an interesting difference:
> > > > > > >>>
> > > > > > >>> If I use 'sudo ifup -a -v' ifup won't find the mapped 
> > > > > > >>> interfaces.
> > > > > > >>
> > > > > > >> ifup doesn't process them since they are not configured with 
> > > > > > >> `auto`
> > > > > > >
> > > > > > > OK, what processes interfaces with allow-hotplug then, if not 
> > > > > > > ifupdown?
> > > > > > >
> > > > > > >> s/allow-hotplug/auto/ in my /e/n/interfaces makes this work.
> > > > > > >>>
> > > > > > >>> If I use 'sudo ifup --allow hotplug -a -v' ifup correctly finds 
> > > > > > >>> and
> > > > > > >>> maps the wireless interfaces.
> > > > > > >>>
> > > > > > >>
> > > > > > >> I wonder if there is a problem related with udev instead.
> > > > > > >
> > > > > > > Added udev (systemd) maintainers in CC.
> > > > > >
> > > > > > If you are referring to
> > > > > > /lib/udev/ifupdown-hotplug and /lib/udev/rules.d/80-ifupdown.rules,
> > > > > > those files are maintained by the ifupdown package.
> > > > > >
> > > > > > The systemd package is not involved here.
> > > > >
> > > > > Michael, I suspected as much. Thanks for confirming this.
> > > > >
> > > > > Santiago, all evidences point to ifupdown pattern matching only
> > > > > working for auto interfaces, but not hotplug interfaces.
> > > >
> > > > Not exactly, I think. 'sudo ifup --allow hotplug -a -v' works for you.
> > >
> > > I should not have to type that manually to have ifupdown find and
> > > raise the interfaces.
> > >
> > > > > Basically,
> > > > > hotplug works for named interfaces, but not for pattern matched
> > > > > interfaces.
> > > >
> > > > ifupdown-hotplug receives as argument the name of the real
> > > > interface, so it execs ifup --allow=hotplug $INTERFACE
> > > > https://salsa.debian.org/debian/ifupdown/-/blob/master/debian/ifupdown-hotplug#L73
> > > > and it wouldn't find it in your configuration.
> > >
> > > Which is precisely the problem. The mapping fails.
> > >
> > > > Maybe your use case matches better templates and inherits (See INTERFACE
> > > > TEMPLATES) in interfaces(5).
> > >
> > > It doesn't. Templates rely upon explicitly defining interfaces.
> >
> > OK, I see.
> >
> > So the problem is not explicitly related to ifupdown.
> 
> Yes it is. Contrary to what the man page says, pattern matching does
> not work for any "allow" line. It only works for "auto" lines.

Sorry for the confusion, I meant the problem is not explicitly related
to hotplug.
Pattern matching, as in the way how you use it, does

Bug#995923: linux: Regression in 5.14: no more multichannel audio on Rock64

2021-10-08 Thread Diederik de Haas

Source: linux
Version: 5.14-1~exp1
Severity: normal
Tags: upstream

In kernel 5.13 on my Rock64, `pactl list cards` correctly identified my
AVR (SC-1224) and had various multichannel audio profiles I could choose from.
Since kernel 5.14, `paclt list cards` no longer identifies my AVR and I
only have stereo audio profiles.

I've build and tested various kernel versions myself based off commit
e4e2aea3e840406042537c5ef4970d9e8560a103 (Merge branch 'rockchip-spdif'
into 'master') which has all needed audio modules (afaik) enabled for
Rock64.
The 5.13.12-1~exp2 is slightly older and therefor misses the SPDIF card.
I used the same dtb in all the test, which is build from 5.14.6, and I've
kept all other software at the same sofware versions, so it wouldn't affect
the results.
I think that means the only (real) change is the upstream source code.

Output of `uname -a` and `pactl list cards` on the various kernels:

diederik@bagend:~$ ssh soundserver
Linux soundserver 5.13.0-trunk-arm64 #1 SMP Debian 5.13.12-1~exp2 (2021-08-21) 
aarch64

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Thu Oct  7 09:29:48 2021 from 192.168.2.50
Initialising new SSH agent... succeeded
diederik@soundserver:~$ uname -a
Linux soundserver 5.13.0-trunk-arm64 #1 SMP Debian 5.13.12-1~exp2 (2021-08-21) 
aarch64 GNU/Linux
diederik@soundserver:~$ pactl list cards
Card #0
Name: alsa_card.platform-hdmi-sound
Driver: module-alsa-card.c
Owner Module: 4
Properties:
alsa.card = "0"
alsa.card_name = "HDMI"
alsa.long_card_name = "pine64-rock64_rk3328-"
alsa.driver_name = "snd_soc_simple_card"
device.bus_path = "platform-hdmi-sound"
sysfs.path = "/devices/platform/hdmi-sound/sound/card0"
device.form_factor = "internal"
device.string = "0"
device.description = "Built-in Audio"
module-udev-detect.discovered = "1"
device.icon_name = "audio-card"
Profiles:
input:stereo-fallback: Stereo Input (sinks: 0, sources: 1, 
priority: 51, available: yes)
output:hdmi-stereo: Digital Stereo (HDMI) Output (sinks: 1, 
sources: 0, priority: 5900, available: yes)
output:hdmi-surround: Digital Surround 5.1 (HDMI) Output 
(sinks: 1, sources: 0, priority: 800, available: yes)
output:hdmi-surround71: Digital Surround 7.1 (HDMI) Output 
(sinks: 1, sources: 0, priority: 800, available: yes)
off: Off (sinks: 0, sources: 0, priority: 0, available: yes)
Active Profile: output:hdmi-surround71
Ports:
analog-input: Analog Input (type: Analog, priority: 1, 
latency offset: 0 usec, availability unknown)
Part of profile(s): input:stereo-fallback
hdmi-output-0: HDMI / DisplayPort (type: HDMI, priority: 5900, 
latency offset: 0 usec, availability unknown)
Properties:
device.icon_name = "video-display"
device.product.name = "SC-1224"
Part of profile(s): output:hdmi-stereo, 
output:hdmi-surround, output:hdmi-surround71
diederik@soundserver:~$ su -l
Password:
root@soundserver:~# vim /etc/default/grub
root@soundserver:~# update-grub
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-5.14.0-trunk-arm64
Found initrd image: /boot/initrd.img-5.14.0-trunk-arm64
Found linux image: /boot/vmlinuz-5.13.0-1-arm64
Found initrd image: /boot/initrd.img-5.13.0-1-arm64
Found linux image: /boot/vmlinuz-5.13.0-trunk-arm64
Found initrd image: /boot/initrd.img-5.13.0-trunk-arm64
Found linux image: /boot/vmlinuz-5.10.0-8-arm64
Found initrd image: /boot/initrd.img-5.10.0-8-arm64
done
root@soundserver:~# reboot
Connection to soundserver closed by remote host.
Connection to soundserver closed.
diederik@bagend:~$ ssh soundserver
Linux soundserver 5.13.0-1-arm64 #1 SMP Debian 5.13.19-1 (2021-10-03) aarch64

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Thu Oct  7 23:23:06 2021 from 192.168.2.50
Initialising new SSH agent... succeeded
diederik@soundserver:~$ uname -a
Linux soundserver 5.13.0-1-arm64 #1 SMP Debian 5.13.19-1 (2021-10-03) aarch64 
GNU/Linux
diederik@soundserver:~$ pactl list cards
Card #0
Name: alsa_card.platform-hdmi-sound
Driver:

Bug#978051: [Pkg-javascript-devel] Bug#978051: Need it

Le 08/10/2021 à 10:28, Yadd a écrit :
> Le 06/10/2021 à 11:35, Yadd a écrit :
>> Le 06/10/2021 à 11:12, Bastien Roucariès a écrit :
>>> Hi;
>>>
>>> I need it for gulp-wrap that is needed for a chai extension
>>
>> OK, I'm working on it
> 
> Note that node-consolidate is blocked due to node-jade deprecation
> (https://bugs.debian.org/987967)

Fixed in 0.16.0-2 (was just a test dependency)

Bug#974064: node-client-sessions: Remove dependency to (deprecated) node-request

Take a look at
https://github.com/sindresorhus/got/blob/main/documentation/migration-guides/request.md

Bug#934283: RFP: plata-gtk-theme -- A Gtk theme based on Material Design Refresh.

2021-10-08 Thread Willem Mulder

Control: retitle -1 RFP: plata-gtk-theme -- A Gtk theme based on 
Material Design Refresh

Control: owner -1 !

On Fri, 9 Aug 2019 06:14:02 + Lin Zhihang 
 wrote:

> […]
>
> I'm sorry that I'm not going to package it because I'm not
> familiar with packaging.
>

I'd very much like to see this land in Debian as well. For a multi-user 
system I maintain I'm currently using the author's PPA, which isn't 
exactly ideal. Since I have some packaging experience, I'll give it a go.

Willem

Bug#995922: ruby-pgplot: please consider switching to giza

2021-10-08 Thread Ole Streicher


Source: ruby-pgplot
Version: 0.2.0-1
Severity: wishlist

Dear maintainer,

ruby-pgplot is currently in contrib because it depends on the non-free 
"pgplot5" package. There is however a DFSG-free replacement library 
"giza" available that provides a compatibility layer for pgplot. The 
compatibility is almost complete, so this may fulfill your needs. It 
maybe enough to just replace the pgplot5 build dependency with "giza-dev".


Switching to giza would allow to bring ruby-pgplot into Debians "main" 
archive, with the benefit of automated builds etc. Also, pgplot5 is dead 
upstream and maintained with NMUs since almost ten years now.


I am the maintainer of giza, and I am happy to help out if there are 
problems.


Best regards

Ole

Bug#995722: Not running tests because tests miss source code is not useful

On 10/7/21 11:40 AM, Pirate Praveen wrote:
> 
> 
> On 7 October 2021 3:02:55 am IST, Thomas Goirand  wrote:
>> On 10/6/21 6:53 PM, Pirate Praveen wrote:
>>> [adding -devel]
>>>
>>> On ബു, ഒക്ടോ 6 2021 at 12:16:07 വൈകു +0200 +0200, Jonas Smedegaard
>>>  wrote:
 Quoting Yadd (2021-10-06 11:43:40)
>  On Lu, 04 oct 21, 16:40:48, Bastien Roucari�s wrote:
>  > Source: src:node-lodash
>  > Version: 4.17.21+dfsg+~cs8.31.173-1
>  > Severity: serious
>  > Justification: do not compile from source
>  >
>  > Dear Maintainer,
>  >
>  > The vendor directory should be emptied
>  >
>  > The debug version is compiled without source (lintian warn) and
> moreover the
>  > rest of file are already packaged
>  >
>  > grep -R vendor * gives only a few hit that could be cured by
> symlinking
>  >
>  > Bastien
>  Hi,
>
>  this files are used for test only, maybe severity could be decreased.

 I find the severity accurate: Relying on non-source code is a severe
 violation of Debian Policy, not matter the purpose of relying on it.
>>>
>>> I think we should change the policy here. Running tests helps improve
>>> the quality of the software we ship. Many times the vendored code is
>>> used to ensure the code does not break in a specific situation. I don't
>>> think reducing test coverage in such situations is really helpful.
>>
>> Right, running tests helps improve the quality of software we ship.
>> Which is why you probably need to test using what's shipped in Debian
>> rather than using a vendored source-less code.
> 
> We are not shipping the source less code.

You are: Debian also ships source code.

> This is used only during tests. I don't think we are not gaining anything by 
> removing tests here. Just making it harder for the package maintainer to run 
> tests.

You would not gain anything by removing tests, but you would win by
making these tests completely free software.

>> If we rely on non-free code for tests, that's really bad too, and that
>> must be avoided just like we're avoiding source-less code everywhere
>> else in Debian. The policy shall not change, please.
>>
> 
> The code is not non-free here, just a specific version of a Free Software 
> code built outside Debian.

We build from source...

> I think tools required for tests should be considered separately from tools 
> required to compile. I think it should be treated similar to test data.

I don't agree.

> What you are proposing would require the package maintainer to adapt these 
> tests to versions available (many times with different API versions) in 
> Debian and the easier choice is disabling tests.

No. I believe it's ok to have an embedded version of the JS files in the
upstream code. This is a *very* different issue, please do not mix them.
What I don't like is using a minified version of the JS files. That's
*very* easy (hum... trivial?) to add a non-minified version in your
Debian folder, and use that for tests. You don't care if running the
tests is a little bit slower (because using a source-full version), do you?

However, there's this:

On 10/7/21 6:17 PM, Richard Laager wrote:
> Running tests against vendored dependencies one isn't going to use at
> run-time is of limited usefulness.

Best is, if you can, use the library packaged separately, in Debian,
both for tests, and runtime. This way, you do ensure that:
- patching Debian for security is still a thing
- the package can run with the Debian version of the lib

I think it's less grave than just saying "oh, we don't care about these
binary blobs, there's just for tests...". It's even worse, because by
using a different version for tests and runtime, you're faking tests...

If the lib are just use for tests and nothing else (ie: not for
runtime), then back to square one: it's ok to ship the non-minified
version in your debian folder, and use that for running tests. It's also
super easy and fast to implement.

> I think blindly applying a rule without thinking of any consequences is bad 
> too.

I think blindly saying "oh, it's ok, it's only test things..." is a
*very* dangerous path that I would like Debian to avoid.

> Just because it is bad in one situation does not mean it will be bad in every 
> situation. We should evaluate pros and cons of each situation before making a 
> decision. Blind faith is more suitable for religions and not for a project 
> like ours.

Sorry, but using free software from source is *NOT* opened for debate.
If you would like to do that, choose another distribution. We all
signed-up for it, when becoming DDs, this is the foundations of Debian.

> I think a nocheck build profile which excludes these files from build is 
> sufficient to ensure we are not using these to create binary package.

What's the problem with using a non-minified version of the files? It's
not difficult, and it doesn't take too much of your packaging time.

> This way we guarantee only

Bug#978051: [Pkg-javascript-devel] Bug#978051: Need it

Le 06/10/2021 à 11:35, Yadd a écrit :
> Le 06/10/2021 à 11:12, Bastien Roucariès a écrit :
>> Hi;
>>
>> I need it for gulp-wrap that is needed for a chai extension
> 
> OK, I'm working on it

Note that node-consolidate is blocked due to node-jade deprecation
(https://bugs.debian.org/987967)

Bug#995920: lftp: New upstream release available


Package: lftp
Version: 4.8.4-2
Severity: normal

Hi,

Several new upstream releases are available. Please import the latest to 
Debian.


Thanks,
Bastian

Bug#995919: sphinx-tabs 3.2.0-1 needs sphinx 4 ?

2021-10-08 Thread Drew Parsons

Source: sphinx-tabs
Version: 3.2.0-1
Severity: normal

sphinx-tabs 3.2.0-1 is passing tests in unstable, but failing
transition tests in testing.

The failure is trivial, test_other_with_assets.html is
expecting to have
  1
but in testing it gets
  1
  
It looks as if new sphinx 4.2 is generating what sphinx-tabs 3.2.0
expects, while old sphinx 3.5.4 in testing does not.

There might be a number of different ways of fixing (or ignoring) the
failing test, but would the simplest solution be to simply declare a
versioned Build-Depends: sphinx (>=4) ?

Bug#995722: [Pkg-javascript-devel] Bug#995722: Not running tests because tests miss source code is not useful

Le 08/10/2021 à 10:18, Thomas Goirand a écrit :
> On 10/7/21 7:06 AM, Yadd wrote:
>> Le 06/10/2021 à 23:32, Thomas Goirand a écrit :
>>> On 10/6/21 6:53 PM, Pirate Praveen wrote:
 [adding -devel]

 On ബു, ഒക്ടോ 6 2021 at 12:16:07 വൈകു +0200 +0200, Jonas Smedegaard
  wrote:
> Quoting Yadd (2021-10-06 11:43:40)
>>  On Lu, 04 oct 21, 16:40:48, Bastien Roucari�s wrote:
>>  > Source: src:node-lodash
>>  > Version: 4.17.21+dfsg+~cs8.31.173-1
>>  > Severity: serious
>>  > Justification: do not compile from source
>>  >
>>  > Dear Maintainer,
>>  >
>>  > The vendor directory should be emptied
>>  >
>>  > The debug version is compiled without source (lintian warn) and
>> moreover the
>>  > rest of file are already packaged
>>  >
>>  > grep -R vendor * gives only a few hit that could be cured by
>> symlinking
>>  >
>>  > Bastien
>>  Hi,
>>
>>  this files are used for test only, maybe severity could be decreased.
>
> I find the severity accurate: Relying on non-source code is a severe
> violation of Debian Policy, not matter the purpose of relying on it.

 I think we should change the policy here. Running tests helps improve
 the quality of the software we ship. Many times the vendored code is
 used to ensure the code does not break in a specific situation. I don't
 think reducing test coverage in such situations is really helpful.
>>>
>>> Right, running tests helps improve the quality of software we ship.
>>> Which is why you probably need to test using what's shipped in Debian
>>> rather than using a vendored source-less code.
>>>
>>> If we rely on non-free code for tests, that's really bad too, and that
>>> must be avoided just like we're avoiding source-less code everywhere
>>> else in Debian. The policy shall not change, please.
>>
>> We are not talking about really-non-free code, but minified JavaScript
>> code released under a free license.
>>
>> If we want to be strict here, there will be some excluded package: for
>> example most of the softwares listed here will be excluded:
>> https://lintian.debian.org/tags/embedded-javascript-library
>>
>> Is it what you want ?
> 
> I would like these binaries (yes, minified JS is the same as binaries)
> to be replaced by source code. Yes, that's what I want... which is not
> what you're pointing at. You're pointing at packages not using Debian
> version of the libraries, which is different.
> 
> Somehow, I believe it's kind of ok if *docs* are using their own version
> of these files, provided it's not a minified version.
> 
> Cheers,
> 
> Thomas Goirand (zigo)

Take a look, most of them embed a minified version (jquery* for example)

Bug#995722: [Pkg-javascript-devel] Bug#995722: Not running tests because tests miss source code is not useful