Bug#1002597: curl: temporarily revert adding libssh-dev to Build-Depends

[Helmut Grohne]

Hi,

On Sat, Dec 25, 2021 at 07:41:02PM -0500, Sergio Durigan Junior wrote:
> FTR, I'm also fine with waiting until the libssh conundrum is sorted
> out.

Martin already uploaded libssh and I was able to integrate it into the
bootstrap sequence. That went far quicker than expected. You can revert
the revert now.

Helmut

Bug#1002630: pipewire: enable roc module

[Nick Black (Public gmail account)]

Package: pipewire
Version: 0.3.42-1
Severity: wishlist
X-Debbugs-Cc: dankamong...@gmail.com

Dear Maintainer,

I see in the changelog "disble roc module, at least for now", but I was
hoping to use this module for synchronized audio.

Ahh, I see libroc isn't yet packaged in Debian. Were I to package it,
would you have any interest in Sponsoring the upload (I'm only a DM
at the moment, not yet a DD)? I built it from source, and was able
to build pipewire 0.3 with ROC support.

Kernel: Linux 5.15.9nlb (SMP w/64 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages pipewire depends on:
ii  init-system-helpers  1.61
ii  libpipewire-0.3-modules  0.3.42-1
ii  pipewire-bin 0.3.42-1

pipewire recommends no packages.

pipewire suggests no packages.

-- no debconf information

Bug#1002579: libfltk1.3-dev: libfltk1.3-dev is not Multi-Arch:same

[Aaron M. Ucko]

Dima Kogan  writes:

> I forgot to mention: dpkg-dev is in build-essential and it's
> Architecture:all, so there's no reason to add the dependency. It's
> guaranteed to be installed.

Only in the context of package builds; in other contexts (ad-hoc builds
against system FLTK), it's currently entirely possible to have only
libfltk1.3-dev installed.  I could perhaps downgrade the dependency to a
recommendation, but I don't think it would be unreasonable to leave it
as a full dependency.

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

Bug#1002626: debian-policy: building packages should not require to be root

[Russ Allbery]

Guillem Jover  writes:

> But, the builder in this context is the program driving debian/rules and
> not any external wrappers, in this case dpkg-buildpackage, which has
> honored the field since it got implemented in 1.19.0. We drafted it as
> "the builder" to allow for other potential drivers, because we are still
> considering debian/rules the canonical entry point (even though I still
> think we should ideally stop supporting calling it directly, and instead
> should make dpkg-buildpackage the only supported interface).

Oh, my apologies, I missed that detail.

>> […] It looks like that's not the case, so I think this was just a
>> bog-standard FTBFS, only a bit surprising because it was triggered by
>> honoring Rules-Requires-Root, which I'm not sure the buildds do (yet).

> The buildds have "honored" R³ since dpkg-buildpackage does.

I had remembered (probably from some distant past) buildds always running
builds as root, and just confused myself and probably other people.  Sorry
about that!

I'm therefore confused why postfix didn't FTBFS on the buildds by failing
to remove that read-only file.  Clearly there must be some difference in
the build environment for Daniel and Vincent or postfix would have always
refused to build, but I'm not sure what that is.

(In any case, I'm fairly convinced this isn't a Policy bug, although it
sounds like the wording for R³ in Policy could be improved somewhat.)

-- 
Russ Allbery (r...@debian.org)  

Bug#1002579: libfltk1.3-dev: libfltk1.3-dev is not Multi-Arch:same

[Dima Kogan]

> I reckon I'll also need to throw in a runtime dependency on
> dpkg-dev:any, but that should be straightforward and uncontroversial.

I forgot to mention: dpkg-dev is in build-essential and it's
Architecture:all, so there's no reason to add the dependency. It's
guaranteed to be installed.

Bug#1002579: libfltk1.3-dev: libfltk1.3-dev is not Multi-Arch:same

[Aaron M. Ucko]

Dima Kogan  writes:

> Here's a patch to handle fltk-config.

Got it, thanks!

> I don't use cmake, so would like to not touch FLTK-Targets-none.cmake.
> Can you do that?

Sure, I'll look into it.  I reckon I'll also need to throw in a runtime
dependency on dpkg-dev:any, but that should be straightforward and
uncontroversial.

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

Bug#1002626: debian-policy: building packages should not require to be root

[Guillem Jover]

On Sat, 2021-12-25 at 18:45:08 -0800, Russ Allbery wrote:
> Vincent Lefevre  writes:
> > On 2021-12-25 14:48:33 -0800, Russ Allbery wrote:
> >> Vincent Lefevre  writes:
> >>> Here, the build via "debuild" is failing even when fakeroot is
> >>> available (installed on the machine). Note that Rules-Requires-Root
> >>> has been set to "no". IMHO, the policy should say that when
> >>> Rules-Requires-Root is set to "no", being root or using fakeroot
> >>> should not be required.
> 
> >> It does already.
> 
> >> no: Declares that neither root nor fakeroot is required. Package
> >> builders (e.g. dpkg-buildpackage) may choose to invoke any target in
> >> debian/rules with an unprivileged user.
> 
> >> Am I missing something?
> 
> > According to Sean, this is just advisory (and Scott Kitterman seemed
> > to assume that a build failure as non-root[*] was not a RC bug).
> 
> I don't understand what "advisory" means here.  This field controls the
> behavior of the package building software.  If the package says that root
> isn't required, the package will be built without root.  If root turns out
> to be required, the package will FTBFS.  There's nothing "advisory" about
> having inaccurate package metadata that causes FTBFS, surely?

I did not understand Sean reply either TBH. Also rereading the policy
description of this, seems to me has somewhat lost some of the nuance
from the spec in dpkg (/usr/share/doc/dpkg/rootless-builds.txt.gz).

Neither I understood the comment about that being related to the field
being new.

> Presumably the question is about the severity of the bug, but I don't
> think the severity question has anything to do with the Policy wording or
> would change if we worded Policy differently.  The package says that you
> don't have to run it as root, so an autobuilder that knows about
> Rules-Requires-Root won't run the build as root, the build will fail, and
> that's a FTBFS bug, regardless of what Policy says.  Presumably Lucas
> would report it as such if his builder supports Rules-Requires-Root.

But, the builder in this context is the program driving debian/rules
and not any external wrappers, in this case dpkg-buildpackage, which
has honored the field since it got implemented in 1.19.0. We drafted
it as "the builder" to allow for other potential drivers, because we
are still considering debian/rules the canonical entry point (even
though I still think we should ideally stop supporting calling it
directly, and instead should make dpkg-buildpackage the only supported
interface).

> […] It looks like that's not the case, so I think this was
> just a bog-standard FTBFS, only a bit surprising because it was triggered
> by honoring Rules-Requires-Root, which I'm not sure the buildds do (yet).

The buildds have "honored" R³ since dpkg-buildpackage does.

Thanks,
Guillem

Bug#1002626: debian-policy: building packages should not require to be root

[Russ Allbery]

Vincent Lefevre  writes:
> On 2021-12-25 14:48:33 -0800, Russ Allbery wrote:
>> Vincent Lefevre  writes:

>>> Here, the build via "debuild" is failing even when fakeroot is
>>> available (installed on the machine). Note that Rules-Requires-Root
>>> has been set to "no". IMHO, the policy should say that when
>>> Rules-Requires-Root is set to "no", being root or using fakeroot
>>> should not be required.

>> It does already.

>> no: Declares that neither root nor fakeroot is required. Package
>> builders (e.g. dpkg-buildpackage) may choose to invoke any target in
>> debian/rules with an unprivileged user.

>> Am I missing something?

> According to Sean, this is just advisory (and Scott Kitterman seemed
> to assume that a build failure as non-root[*] was not a RC bug).

I don't understand what "advisory" means here.  This field controls the
behavior of the package building software.  If the package says that root
isn't required, the package will be built without root.  If root turns out
to be required, the package will FTBFS.  There's nothing "advisory" about
having inaccurate package metadata that causes FTBFS, surely?

Presumably the question is about the severity of the bug, but I don't
think the severity question has anything to do with the Policy wording or
would change if we worded Policy differently.  The package says that you
don't have to run it as root, so an autobuilder that knows about
Rules-Requires-Root won't run the build as root, the build will fail, and
that's a FTBFS bug, regardless of what Policy says.  Presumably Lucas
would report it as such if his builder supports Rules-Requires-Root.

Reading the bug log, I'm not sure there's even any disagreement about
that.  What I see instead is that Scott was surprised that the file being
removed was not writable and thought that was something that you had done
in the local build system and that therefore wouldn't happen with other
rebuild efforts.  It looks like that's not the case, so I think this was
just a bog-standard FTBFS, only a bit surprising because it was triggered
by honoring Rules-Requires-Root, which I'm not sure the buildds do (yet).

-- 
Russ Allbery (r...@debian.org)  

Bug#1002579: libfltk1.3-dev: libfltk1.3-dev is not Multi-Arch:same

[Dima Kogan]

Hi.

Here's a patch to handle fltk-config.

I don't use cmake, so would like to not touch FLTK-Targets-none.cmake.
Can you do that?

Thanks

>From b6c84bc2864913c48eb4db54bf4f75d62759770c Mon Sep 17 00:00:00 2001
From: Dima Kogan 
Date: Fri, 24 Dec 2021 14:38:48 -0800
Subject: [PATCH] "fltk-config" no longer has arch-specific data in it

The arch-specific stuff is in "ARCH-fltk-config", with "fltk-config" calling the
appropriate one. This is a step on the way towards making libfltk1.3-dev
Multi-Arch:same
---
 debian/fltk-config|  2 ++
 debian/libfltk1.3-dev.install |  3 ++-
 debian/rules  | 14 --
 3 files changed, 12 insertions(+), 7 deletions(-)
 create mode 100755 debian/fltk-config

diff --git a/debian/fltk-config b/debian/fltk-config
new file mode 100755
index 000..4990298
--- /dev/null
+++ b/debian/fltk-config
@@ -0,0 +1,2 @@
+#!/bin/sh
+`dpkg-architecture -q DEB_HOST_GNU_TYPE`-fltk-config
diff --git a/debian/libfltk1.3-dev.install b/debian/libfltk1.3-dev.install
index cf160d9..78cbc47 100644
--- a/debian/libfltk1.3-dev.install
+++ b/debian/libfltk1.3-dev.install
@@ -1,4 +1,5 @@
-usr/bin/fltk-config
+usr/bin/*-fltk-config
+debian/fltk-config /usr/bin
 usr/include/FL/*.H
 usr/include/FL/abi-version.h
 usr/include/FL/dirent.h
diff --git a/debian/rules b/debian/rules
index e842252..a5f702e 100755
--- a/debian/rules
+++ b/debian/rules
@@ -96,9 +96,10 @@ override_dh_auto_install-arch:
 ## libfltk1.3-dev
 	cp debian/CMakeCache.txt CMakeTmp/etc/*.cmake \
 	CMake/FLTK-Functions.cmake debian/tmp/usr/lib/fltk
-	sed -e 's/ -f[a-z]*-prefix-map=[^ ]*//' fltk-config \
-	> debian/tmp/usr/bin/fltk-config
-	chmod +x debian/tmp/usr/bin/fltk-config
+	sed -e 's/ -f[a-z]*-prefix-map=[^ ]*//' debian/tmp/usr/bin/fltk-config \
+	> debian/tmp/usr/bin/$(DEB_HOST_GNU_TYPE)-fltk-config
+	chmod 755 debian/tmp/usr/bin/$(DEB_HOST_GNU_TYPE)-fltk-config
+	rm debian/tmp/usr/bin/fltk-config
 
 ifeq "" "$(filter nodoc,$(DEB_BUILD_OPTIONS))"
   override_dh_auto_install-indep:
@@ -107,9 +108,10 @@ endif
 
 override_dh_install-arch:
 ## libfltk1.3-dev
-	sed -e 's/ -f[a-z]*-prefix-map=[^ ]*//' fltk-config \
-	> debian/tmp/usr/bin/fltk-config
-	chmod +x debian/tmp/usr/bin/fltk-config
+	sed -e 's/ -f[a-z]*-prefix-map=[^ ]*//' debian/tmp/usr/bin/fltk-config \
+	> debian/tmp/usr/bin/$(DEB_HOST_GNU_TYPE)-fltk-config
+	chmod 755 debian/tmp/usr/bin/$(DEB_HOST_GNU_TYPE)-fltk-config
+	rm debian/tmp/usr/bin/fltk-config
 	dh_install
 
 override_dh_installdocs:
-- 
2.30.1

Bug#1002626: debian-policy: building packages should not require to be root

[Vincent Lefevre]

On 2021-12-25 14:48:33 -0800, Russ Allbery wrote:
> Vincent Lefevre  writes:
> 
> > Here, the build via "debuild" is failing even when fakeroot is available
> > (installed on the machine). Note that Rules-Requires-Root has been set
> > to "no". IMHO, the policy should say that when Rules-Requires-Root is
> > set to "no", being root or using fakeroot should not be required.
> 
> It does already.
> 
> no: Declares that neither root nor fakeroot is required. Package
> builders (e.g. dpkg-buildpackage) may choose to invoke any target in
> debian/rules with an unprivileged user.
> 
> Am I missing something?

According to Sean, this is just advisory (and Scott Kitterman seemed
to assume that a build failure as non-root[*] was not a RC bug).

[*] here, just because of "Rules-Requires-Root: no".

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

Bug#965448: checksecurity: diff for NMU version 2.0.16+nmu3

[gregor herrmann]

Control: tags 965448 + patch
Control: tags 965448 + pending
Control: tags 999082 + patch
Control: tags 999082 + pending


Dear maintainer,

I've prepared an NMU for checksecurity (versioned as 2.0.16+nmu3) and
uploaded it to DELAYED/7. Please feel free to tell me if I
should delay it longer.

Regards.


-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   NP: Alan Jackson: Chattahoochee
diff -Nru checksecurity-2.0.16+nmu2/debian/changelog checksecurity-2.0.16+nmu3/debian/changelog
--- checksecurity-2.0.16+nmu2/debian/changelog	2021-01-01 19:17:53.0 +0100
+++ checksecurity-2.0.16+nmu3/debian/changelog	2021-12-26 01:56:10.0 +0100
@@ -1,3 +1,19 @@
+checksecurity (2.0.16+nmu3) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix "missing required debian/rules targets build-arch and/or build-
+indep": Add targets to debian/rules.
+(Closes: #999082)
+  * Fix "Removal of obsolete debhelper compat 5 and 6 in bookworm":
+Bump to 7 in debian/{compat,control}.
+(Closes: #965448)
+  * Fix some grave packaging errors:
+- move debhelper from Build-Depends-Indep to Build-Depends
+- remove temporary files debian/postrm.debhelper and debian/substvars from
+  source package
+
+ -- gregor herrmann   Sun, 26 Dec 2021 01:56:10 +0100
+
 checksecurity (2.0.16+nmu2) unstable; urgency=medium
 
   * Non maintainer upload by the Reproducible Builds team.
diff -Nru checksecurity-2.0.16+nmu2/debian/compat checksecurity-2.0.16+nmu3/debian/compat
--- checksecurity-2.0.16+nmu2/debian/compat	2010-10-27 23:50:11.0 +0200
+++ checksecurity-2.0.16+nmu3/debian/compat	2021-12-26 01:49:32.0 +0100
@@ -1 +1 @@
-5
+7
diff -Nru checksecurity-2.0.16+nmu2/debian/control checksecurity-2.0.16+nmu3/debian/control
--- checksecurity-2.0.16+nmu2/debian/control	2015-02-21 16:01:42.0 +0100
+++ checksecurity-2.0.16+nmu3/debian/control	2021-12-26 01:54:44.0 +0100
@@ -3,7 +3,7 @@
 Priority: optional
 Maintainer: Javier Fernández-Sanguino Peña 
 Standards-Version: 3.6.1
-Build-Depends-Indep: debhelper (>= 4.1.16)
+Build-Depends: debhelper (>= 7)
 
 Package: checksecurity
 Architecture: all
diff -Nru checksecurity-2.0.16+nmu2/debian/postrm.debhelper checksecurity-2.0.16+nmu3/debian/postrm.debhelper
--- checksecurity-2.0.16+nmu2/debian/postrm.debhelper	2005-09-21 00:49:30.0 +0200
+++ checksecurity-2.0.16+nmu3/debian/postrm.debhelper	1970-01-01 01:00:00.0 +0100
@@ -1,6 +0,0 @@
-# Automatically added by dh_installdebconf
-if [ "$1" = purge ] && [ -e /usr/share/debconf/confmodule ]; then
-	. /usr/share/debconf/confmodule
-	db_purge
-fi
-# End automatically added section
diff -Nru checksecurity-2.0.16+nmu2/debian/rules checksecurity-2.0.16+nmu3/debian/rules
--- checksecurity-2.0.16+nmu2/debian/rules	2010-10-27 23:51:14.0 +0200
+++ checksecurity-2.0.16+nmu3/debian/rules	2021-12-26 01:51:18.0 +0100
@@ -6,7 +6,9 @@
 # Uncomment this to turn on verbose mode.
 #export DH_VERBOSE=1
 
-build: build-stamp
+build: build-arch build-indep
+build-arch: build-stamp
+build-indep: build-stamp
 build-stamp:
 	dh_testdir
 	touch build-stamp
@@ -46,4 +48,4 @@
 	@echo >&2 'source and diff are obsolete - use dpkg-source -b'; false
 
 binary: binary-indep binary-arch
-.PHONY: build clean binary-indep binary-arch binary
+.PHONY: build-inddep build-arch build clean binary-indep binary-arch binary
diff -Nru checksecurity-2.0.16+nmu2/debian/substvars checksecurity-2.0.16+nmu3/debian/substvars
--- checksecurity-2.0.16+nmu2/debian/substvars	2005-09-21 00:49:30.0 +0200
+++ checksecurity-2.0.16+nmu3/debian/substvars	1970-01-01 01:00:00.0 +0100
@@ -1 +0,0 @@
-misc:Depends=debconf (>= 0.5) | debconf-2.0


signature.asc
Description: Digital Signature

Bug#1002626: debian-policy: building packages should not require to be root

[Vincent Lefevre]

Hi Sean,

On 2021-12-25 15:55:32 -0700, Sean Whitton wrote:
> Okay, I've attempted to retitle this bug in accordance with your
> suggestion.  The relevant change would not be in ch. 4, but under ch. 5.
> What you suggest is to add to the meaning of "Rules-Requires-Root: no"
> that packages which declare this must not fail to build as non-root.
> 
> This would be quite a significant change, as currently
> Rules-Requires-Root is pretty much just advisory to dpkg-buildpackage.

I'm wondering what is the point to set "Rules-Requires-Root: no" if
the consequence is that this makes the build fail as a non-root user.

> Do we have a project consensus that it ought to be more than advisory?
> I'm not sure -- the field is fairly new.

If this is new, I would have assumed that when a maintainer adds this
field, he should check that the build really succeeds as non-root.

> In addition to that, we would also need to be confident that making this
> change in Policy would not render more than a few packages buggy.

Couldn't there be a build bot to check that?

FYI, over the past few years, I've built dozens of packages as a
non-root user (I never build packages as root), and with the new
postfix bug (now closed as fixed), this was the first time I saw
a failure for this reason.

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

Bug#994521: Acknowledgement (ledmon: libsgutils2-2 1.46 update breaks ledmon)

[Chris Putnam]

It has now been 3 months since this package has been broken in testing.

Is it safe to assume this package is abandoned?

On Fri, Sep 17, 2021 at 12:48 AM Debian Bug Tracking System <
ow...@bugs.debian.org> wrote:

> Thank you for filing a new Bug report with Debian.
>
> You can follow progress on this Bug here: 994521:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=994521.
>
> This is an automatically generated reply to let you know your message
> has been received.
>
> Your message is being forwarded to the package maintainers and other
> interested parties for their attention; they will reply in due course.
>
> Your message has been sent to the package maintainer(s):
>  Hsieh-Tseng Shen 
>
> If you wish to submit further information on this problem, please
> send it to 994...@bugs.debian.org.
>
> Please do not send mail to ow...@bugs.debian.org unless you wish
> to report a problem with the Bug-tracking system.
>
> --
> 994521: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=994521
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>

Bug#777483: jargon: diff for NMU version 4.0.0-5.3

[gregor herrmann]

Control: tags 777483 + pending
Control: tags 999307 + patch
Control: tags 999307 + pending


Dear maintainer,

I've prepared an NMU for jargon (versioned as 4.0.0-5.3) and
uploaded it to DELAYED/7. Please feel free to tell me if I
should delay it longer.

Regards.


-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   NP: Alan Jackson: Chattahoochee
diff -u jargon-4.0.0/debian/changelog jargon-4.0.0/debian/changelog
--- jargon-4.0.0/debian/changelog
+++ jargon-4.0.0/debian/changelog
@@ -1,3 +1,15 @@
+jargon (4.0.0-5.3) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix "please make the build reproducible":
+Apply patch to debian/rules from Chris Lamb.
+(Closes: #777483)
+  * Fix "missing required debian/rules targets build-arch and/or build-
+indep": Add targets to debian/rules.
+(Closes: #999307)
+
+ -- gregor herrmann   Sun, 26 Dec 2021 01:44:00 +0100
+
 jargon (4.0.0-5.2) unstable; urgency=medium
 
   * Non maintainer upload by the Reproducible Builds team.
diff -u jargon-4.0.0/debian/rules jargon-4.0.0/debian/rules
--- jargon-4.0.0/debian/rules
+++ jargon-4.0.0/debian/rules
@@ -11,14 +11,17 @@
 MANDIR=$(DESTDIR)/usr/share/man
 INFODIR=$(DESTDIR)/usr/share/info
 
-build:
+build: build-arch build-indep
+build-arch: build-stamp
+build-indep: build-stamp
+build-stamp:
 	$(checkdir)
-	touch build
+	touch build-stamp
 
 clean:
 	$(checkdir)
 	-rm -f jargon.info
-	-rm -f build
+	-rm -f build-stamp
 	-rm -f `find . -name "*~"`
 	-rm -rf debian/tmp debian/files* core debian/substvars
 
@@ -29,13 +32,13 @@
 	# The actual info file
 	install -d $(INSTALLOPT) -m 755 $(INFODIR)
 	install $(INSTALLOPT) -m 644 jarg400.info $(INFODIR)/jargon.info
-	gzip -9 $(INFODIR)/jargon.info
+	gzip -9n $(INFODIR)/jargon.info
 	# Lookup script
 	install -d $(INSTALLOPT) -m 755  $(DESTDIR)/usr/bin
 	install $(INSTALLOPT) -m 755  debian/jargon $(DESTDIR)/usr/bin/jargon
 	install -d $(INSTALLOPT) -m 755 $(MANDIR)/man1
 	install $(INSTALLOPT) -m 644 debian/jargon.1 $(MANDIR)/man1/jargon.1
-	gzip -9 $(MANDIR)/man1/jargon.1
+	gzip -9n $(MANDIR)/man1/jargon.1
 	# Docs
 	install -d $(INSTALLOPT) -m 755 $(DOCDIR)
 	install $(INSTALLOPT) -m 644 debian/jargon.html \
@@ -44,7 +47,7 @@
 	install $(INSTALLOPT) -m 644 debian/changelog $(DOCDIR)/changelog.Debian
 	install $(INSTALLOPT) -m 644 debian/README.Debian $(DOCDIR)/README.Debian
 	install $(INSTALLOPT) -m 644 jargon-README $(DOCDIR)/README
-	gzip -9 $(DOCDIR)/changelog.Debian $(DOCDIR)/README
+	gzip -9n $(DOCDIR)/changelog.Debian $(DOCDIR)/README
 
 	# Control files
 	install -d $(INSTALLOPTS) -m 755 $(DESTDIR)/DEBIAN
@@ -70,4 +73,4 @@
 	$(checkdir)
 	test root = "`whoami`"
 
-.PHONY: binary binary-arch binary-indep clean checkroot
+.PHONY: build build-arch build-indep binary binary-arch binary-indep clean checkroot


signature.asc
Description: Digital Signature

Bug#1002597: curl: temporarily revert adding libssh-dev to Build-Depends

[Sergio Durigan Junior]

On Saturday, December 25 2021, Samuel Henrique wrote:

> Hello Helmut,
>
> I've uploaded 7.80.0-2 with a revert for this.
>
>> So this looks mostly harmless, but involves non-trivial work and I
>> didn't check build order yet. Given that curl comes relatively late, I
>> don't expect much problems there.
>> So can you give me a month?
>
> Surely, please feel free to take your time, since we are not in a rush.
>
> For reference, this issue has also been discussed at #1002598
> (https://bugs.debian.org/1002598).

Thank you, Helmut and Samuel.

FTR, I'm also fine with waiting until the libssh conundrum is sorted
out.

Cheers,

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

Bug#1001996: ITP: 1oom -- Master of Orion engine

[Alexandre Detiste]

Hi,

I've added support for "Master of Orion" dataset to game-data-packager.

By default assets get installed to /usr/share/games/master-of-orion/

drwxr-xr-x root/root 0 2021-12-26 01:35
./usr/share/games/master-of-orion/
-rw-r--r-- root/root326083 1996-12-24 23:32
./usr/share/games/master-of-orion/backgrnd.lbx
-rw-r--r-- root/root175728 1996-12-24 23:32
./usr/share/games/master-of-orion/colonies.lbx
-rw-r--r-- root/root278398 1996-12-24 23:32
./usr/share/games/master-of-orion/council.lbx
-rw-r--r-- root/root 48830 1996-12-24 23:32
./usr/share/games/master-of-orion/design.lbx

game-data-packager is meant as a general mechanism to make it easier
to use free engines
that requires non-free data, download automatically from steam or gog.com ...

https://salsa.debian.org/games-team/game-data-packager/-/commit/14e47626c0244785b594386e54970f42846ece2c

Maybe the 1oom engine needs a patch to look at the right location.

nothing is set in the stone, merge requests to g-d-p are welcome


Greetings,

Alexandre Detiste

Bug#1001908: manpages-de: manpage of "shutdown" not up-to-date

[Jesse Smith]

On 2021-12-25 3:35 p.m., Mario Blättermann wrote:
> OK, it is in my favor to both keep existing man page translations
> alive (acknowledging the work of the previous translators) and
> integrate Po4a-based translations into upstream projects, instead of
> maintaining them in an external translation project. Give me some days
> to prepare a Po4a framework and migrate the existing .po files. I've
> already checked out the Git repo at savannah.nongnu.org. I would
> create the changes in one single (and quite big) Git diff, is this OK
> for you? Or is there even a mirror at Github or Gitlab or wherever
> else where I could create a pull request?
>

Hi Mario. I'm the upstream maintainer for sysvinit. You can e-mail me
the git patch if you like and I'll test & apply it upstream. One big
text file produced from "git diff" works fine for me. At this time there
isn't a mirror for sysvinit. I've been thinking about it, or even
migrating to a more popular platform as the Savannah infrastructure has
some drawbacks.

For now though the easiest way to send changes upstream is to e-mail
them to me, or open a bug report on Savannah.

Best regards,
Jesse

Bug#901451: nrg2iso: diff for NMU version 0.4-4.1

[gregor herrmann]

Control: tags 901451 + pending
Control: tags 999224 + patch
Control: tags 999224 + pending


Dear maintainer,

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

Regards.


-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   NP: Alan Jackson: Chattahoochee
diff -u nrg2iso-0.4/debian/changelog nrg2iso-0.4/debian/changelog
--- nrg2iso-0.4/debian/changelog
+++ nrg2iso-0.4/debian/changelog
@@ -1,3 +1,17 @@
+nrg2iso (0.4-4.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+
+  [ Helmut Grohne ]
+  * Fix FTCBFS: Inline a fixed upstream Makefile. (Closes: #901451)
+
+  [ gregor herrmann ]
+  * Fix "missing required debian/rules targets build-arch and/or build-
+indep": Add targets to debian/rules.
+(Closes: #999224)
+
+ -- gregor herrmann   Sun, 26 Dec 2021 01:30:45 +0100
+
 nrg2iso (0.4-4) unstable; urgency=low
 
   * Update maintainer address to the debian.org one.
diff -u nrg2iso-0.4/debian/rules nrg2iso-0.4/debian/rules
--- nrg2iso-0.4/debian/rules
+++ nrg2iso-0.4/debian/rules
@@ -6,6 +6,7 @@
 
 # source quilt for patch management
 include /usr/share/quilt/quilt.make
+-include /usr/share/dpkg/buildtools.mk
 
 CFLAGS = -Wall -g
 
@@ -22,12 +23,14 @@
 configure-stamp:
 	dh_testdir
 
-build: build-stamp
+build: build-arch build-indep
+build-arch: build-stamp
+build-indep: build-stamp
 
 build-stamp: configure-stamp $(QUILT_STAMPFN)
 	dh_testdir
 
-	$(MAKE) CFLAGS="$(CFLAGS)"
+	$(CC) $(CFLAGS) nrg2iso.c -o nrg2iso
 	touch build-stamp
 
 clean: unpatch


signature.asc
Description: Digital Signature

Bug#901211: pcaputils: diff for NMU version 0.8-1.1

[gregor herrmann]

Control: tags 901211 + pending
Control: tags 965769 + patch
Control: tags 965769 + pending
Control: tags 999325 + patch
Control: tags 999325 + pending


Dear maintainer,

I've prepared an NMU for pcaputils (versioned as 0.8-1.1) and
uploaded it to DELAYED/7. Please feel free to tell me if I
should delay it longer.

Regards.


-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   NP: Alan Jackson: Chattahoochee
diff -u pcaputils-0.8/debian/compat pcaputils-0.8/debian/compat
--- pcaputils-0.8/debian/compat
+++ pcaputils-0.8/debian/compat
@@ -1 +1 @@
-5
+7
diff -u pcaputils-0.8/debian/rules pcaputils-0.8/debian/rules
--- pcaputils-0.8/debian/rules
+++ pcaputils-0.8/debian/rules
@@ -7,11 +7,13 @@
 	CFLAGS += -O2
 endif
 
-build: build-stamp
+build: build-arch build-indep
+build-arch: build-stamp
+build-indep: build-stamp
 
 build-stamp:
 	dh_testdir
-	$(MAKE) CFLAGS="$(CFLAGS)"
+	dh_auto_build -- CFLAGS="$(CFLAGS)"
 	$(MAKE) -C doc
 	touch $@
 
@@ -49,4 +51,4 @@
 	dh_builddeb
 
 binary: binary-indep binary-arch
-.PHONY: build clean binary-indep binary-arch binary install
+.PHONY: build-indep build-arch build clean binary-indep binary-arch binary install
diff -u pcaputils-0.8/debian/changelog pcaputils-0.8/debian/changelog
--- pcaputils-0.8/debian/changelog
+++ pcaputils-0.8/debian/changelog
@@ -1,3 +1,20 @@
+pcaputils (0.8-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+
+  [ gregor herrmann ]
+  * Fix "Removal of obsolete debhelper compat 5 and 6 in bookworm":
+Bump to 7 in debian/{compat,control}.
+(Closes: #965769)
+  * Fix "missing required debian/rules targets build-arch and/or build-
+indep": Add missing targets in debian/rules.
+(Closes: #999325)
+
+  [ Helmut Grohne ]
+  * Fix FTCBFS: Let dh_auto_build pass cross tools to make. (Closes: #901211)
+
+ -- gregor herrmann   Sun, 26 Dec 2021 01:22:56 +0100
+
 pcaputils (0.8-1) unstable; urgency=low
 
   * New upstream release.
diff -u pcaputils-0.8/debian/control pcaputils-0.8/debian/control
--- pcaputils-0.8/debian/control
+++ pcaputils-0.8/debian/control
@@ -2,7 +2,7 @@
 Section: net
 Priority: extra
 Maintainer: Robert S. Edmonds 
-Build-Depends: debhelper (>= 5), libpcap0.8-dev, libjudy-dev, docbook2x, docbook-xml
+Build-Depends: debhelper (>= 7), libpcap0.8-dev, libjudy-dev, docbook2x, docbook-xml
 Standards-Version: 3.8.1
 
 Package: pcaputils


signature.asc
Description: Digital Signature

Bug#1001591: python3-mistune: latest upgrade breaks matrix-mirage package

[Michael R. Crusoe]

Maybe mistune 2.x should have its own package? Or keep python3-mistune at
2.x and introduce a python3-mistune1 package?


I'm upstream for schema-salad, we don't know how to upgrade to 2.x because
so much has been broken and there is no upgrading guide.

https://github.com/lepture/mistune/issues/290

Bug#1002629: kicad: Please enable the build on powerpc and ppc64

[John Paul Adrian Glaubitz]

Source: kicad
Severity: normal
User: debian-powe...@lists.debian.org
Usertags: powerpc ppc64
X-Debbugs-Cc: debian-powe...@lists.debian.org

Hi!

The portability of kicad is limited to the architectures supported
by the embedded version of libcontext. It turns out that powerpc
and ppc64 are actually supported [1] and I have verified that kicad
builds fine on both targets.

Thus, could you please whitelist powerpc and ppc64 in the Architecture
field in debian/control?

Thanks,
Adrian

> [1] 
> https://salsa.debian.org/electronics-team/KiCad/kicad/-/blob/debian/sid/include/system/libcontext.h#L45

--
 .''`.  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#1002326: python-schema-salad: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p "3.10 3.9" returned exit code 13

[Michael R. Crusoe]

On Wed, 22 Dec 2021 08:57:03 +0100 Lucas Nussbaum  wrote:
> Source: python-schema-salad
> Version: 8.2.20211104054942-1
> Severity: serious
> Justification: FTBFS
> Tags: bookworm sid ftbfs
> User: lu...@debian.org
> Usertags: ftbfs-20211220 ftbfs-bookworm
>
> Hi,
>
> During a rebuild of all packages in sid, your package failed to build
> on amd64.


Hello Lucas. Can you try again with the latest mypy package?

Bug#992286: Can I do anything to speed up the migration to exfatprogs?

[Hilko Bengen]

control: tag -1 pending

Sven,

sorry for taking so long to answer.

Since I just realized that exfatprogs is a drop-in replacement (as long
as the kernel supports exfat) and that there's no exfat-fuse specific
code in libguestfs, I'm going to do an upload of 1:146.2-2.
Unfortunately we'll have to wait for that to clear NEW, but htat should
not take more than a few days.

Cheers,
-Hilko

Bug#1001661: Info received (Bug#1001661: notcurses: flaky autopkgtests on armhf)

[nick black]

well, we don't yet know whether this "took", since 3.0.2 shows
regressions across the board in autopkgtests.

i've set up the upstream bug to track this, and am on it:

 https://github.com/dankamongmen/notcurses/issues/2505

thus far i've been able to run down that it's the "box" demo
that's failing in the "demo" autopkgtest. i expect to have it
resolved tonight. i'll either cut a new debian package with the
necessary patch, or cut a 3.0.3, we'll see.

Bug#1002626: debian-policy: building packages should not require to be root

[Sean Whitton]

control: retitle -1 When Rules-Require-Root: no, packages should not fail to 
build as non-root

Hello Vincent,

On Sat 25 Dec 2021 at 11:37PM +01, Vincent Lefevre wrote:

> When a package is built as a normal user, Rules-Requires-Root assumes
> that using fakeroot would be fine.
>
> Here, the build via "debuild" is failing even when fakeroot is
> available (installed on the machine). Note that Rules-Requires-Root
> has been set to "no". IMHO, the policy should say that when
> Rules-Requires-Root is set to "no", being root or using fakeroot
> should not be required.

Okay, I've attempted to retitle this bug in accordance with your
suggestion.  The relevant change would not be in ch. 4, but under ch. 5.
What you suggest is to add to the meaning of "Rules-Requires-Root: no"
that packages which declare this must not fail to build as non-root.

This would be quite a significant change, as currently
Rules-Requires-Root is pretty much just advisory to dpkg-buildpackage.
Do we have a project consensus that it ought to be more than advisory?
I'm not sure -- the field is fairly new.

In addition to that, we would also need to be confident that making this
change in Policy would not render more than a few packages buggy.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1002626: debian-policy: building packages should not require to be root

[Russ Allbery]

Vincent Lefevre  writes:

> Here, the build via "debuild" is failing even when fakeroot is available
> (installed on the machine). Note that Rules-Requires-Root has been set
> to "no". IMHO, the policy should say that when Rules-Requires-Root is
> set to "no", being root or using fakeroot should not be required.

It does already.

no: Declares that neither root nor fakeroot is required. Package
builders (e.g. dpkg-buildpackage) may choose to invoke any target in
debian/rules with an unprivileged user.

Am I missing something?

-- 
Russ Allbery (r...@debian.org)  

Bug#1002626: debian-policy: building packages should not require to be root

[Vincent Lefevre]

Hello Bill,

On 2021-12-25 22:58:25 +0100, Bill Allombert wrote:
> On Sat, Dec 25, 2021 at 10:38:47PM +0100, Vincent Lefevre wrote:
> > Building packages should not require to be root.
> 
> Hello Vincent!
> 
> Currently, packages are allowed to require root to build.
> See Rules-Requires-Root for more detail.

No, this is not what the Rules-Requires-Root documentation says.

https://www.debian.org/doc/debian-policy/ch-source.html#debian-rules-and-rules-requires-root
says:

  Depending on the value of the Rules-Requires-Root field, the package
  builder (e.g. dpkg-buildpackage) may run the debian/rules target as
  an unprivileged user and provide a gain root command. This command
  allows the debian/rules target to run particular subcommands under
  (fake)root.

When a package is built as a normal user, Rules-Requires-Root assumes
that using fakeroot would be fine.

Here, the build via "debuild" is failing even when fakeroot is
available (installed on the machine). Note that Rules-Requires-Root
has been set to "no". IMHO, the policy should say that when
Rules-Requires-Root is set to "no", being root or using fakeroot
should not be required.

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

Bug#1000599: Don't require xdg-desktop-portal on Ubuntu i386

[Alberto Garcia]

On Tue, Dec 21, 2021 at 02:40:12PM +, Simon McVittie wrote:

> > The Ubuntu i386 archive is a partial one aimed at multiarch
> > purpose and doesn't include desktop services as the xdg
> > portal. The attached patch which is stacked on top of the recently
> > submitted one to disable lto removes the recommends on the portal
> > on that distribution and architecture
> 
> I don't think this change was correct. xdg-desktop-portal and its
> backends are Multi-Arch: foreign, which means that an amd64 x-d-p
> and x-d-p-gtk can satisfy the Recommends from an i386 Webkit, which
> can (and does!) make D-Bus calls to an amd64 xdg-desktop-portal
> (and, via that, to xdg-desktop-portal-gtk).

If you think I should revert this change please file a new bug,
thanks!

Berto

Bug#1002010: find-completion: don't look for -exec etc command if completing before it

[наб]

Hi!

Ran into this just now, too.

The referenced upstream commit cleanly drops in as a patch to 1:2.11-5,
and does indeed fix the issue.

Best,
наб


signature.asc
Description: PGP signature

Bug#992782: closed by Hilko Bengen (Fixed in 1.42.0-3)

[Simon McVittie]

Control: fixed -1 1.42.0-3

On Sat, 25 Dec 2021 at 21:51:06 +, Debian Bug Tracking System forwarded:
> control: fixed -1 1.42.0-3
> 
> I had applied this fix but never closed the bug.

Thanks!

Mail to the -done address doesn't read Control: pseudo-headers, so this
wasn't marked as fixed in 1.42.0-3, only as fixed in an unspecified version.
This mail should resolve that.

FYI, the way to mark a bug as fixed in a particular version without using
d/changelog is to use the Version: pseudo-header in preference to Control:

To: nn-done@

Version: 1.42.0-3

explanation here

Season's greetings,
smcv

Bug#1002626: debian-policy: building packages should not require to be root

[Vincent Lefevre]

Control: reopen -1

On 2021-12-25 14:55:37 -0700, Sean Whitton wrote:
> Hello,
> 
> On Sat 25 Dec 2021 at 10:38PM +01, Vincent Lefevre wrote:
> 
> > Package: debian-policy
> > Version: 4.6.0.1
> > Severity: important
> >
> > Building packages should not require to be root.
> >
> > I don't know what's going on, but see
> >
> >   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1002497#31
> 
> It looks like the issue has been fixed over there.

Not currently available, but anyway this doesn't answer the issue with
other possible packages where this would not be fixed. This was mainly
about the bug severity.

IMHO, a failure to build a package as a normal user should be regarded
as a RC bug (Scott Kitterman said "Certainly not a serious bug. [...]
Don't upgrade the severity again. If you think this is such a big
deal, go get something in Debian policy.").

In particular, all packages in stable should be buildable as a normal
user (in particular to lower the risk of breaking the system in case
of a bug somewhere in the build system).

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

Bug#993009: RFP: cimfomfa -- tingea library for mcl

[Joost van Baal-Ilić]

Hi,

Minor update.

On Mon, Nov 01, 2021 at 08:01:16PM +0100, Joost van Baal-Ilić wrote:
> On Mon, Sep 06, 2021 at 02:05:33PM +0200, Joost van Baal-Ilić wrote:
> > On Thu, Aug 26, 2021 at 11:26:55AM +0200, Joost van Baal-Ilić wrote:
> > >
> > > * Package name: cimfomfa
> > >   Upstream Author : Stijn van Dongen 
>
> URL : https://github.com/micans/cimfomfa
>
> > > * License : GPL-3+
> > >   Programming Lang: C
>
> Description : C utility library libtingea for MCL and zoem
>
> Long description:
>
> cimfomfa is used by both MCL, a cluster algorithm for graphs, and zoem,
> a macro/DSL language. It supplies abstractions for memory management, I/O,
> associative arrays, strings, heaps, and a few other things.
> The tingea library comes with some testing programs.


https://github.com/micans/cimfomfa/archive/refs/tags/21-341.tar.gz was released
dec 10, 2021.


> > > The upcoming mcl tarball will need cimfomfa to build, a git snapshot
> > > prerelease of upcoming mcl is available from
> > > http://micans.org/phloobaz/mcl-21-100.tar.gz .  (We ship the mcl
> > > package.)
> 
> BTW, the mcl code is maintained at public repository
> https://github.com/micans/mcl .


> > > It would be cool if the Debian Med Packaging Team at
> > > https://salsa.debian.org/med-team could take up maintainership of this
> > > library.
> 

> Or maybe zoem (debian-science), mcl (debian-med) and cimfomfa could all be
> maintained by https://salsa.debian.org/math-team .  Since these packages will
> now share dependencies, maybe that would work best.  Or would it be better to
> move zoem from debian-science to debian-med?  Andreas Tille, Shayan Doust:
> any opinions?

I'll very likely maintain cimfomfa at https://salsa.debian.org/science-team .

cimfomfa 21-341.tar.gz lacks a configure.ac, and therefore is not trivial to
build; I've just reported that upstream.

A preliminary http://mdcc.cx/tmp/cimfomfa/cimfomfa_21-341-1.dsc is available.

Bye,

Joost

Bug#1002628: Using build command fails in Debian WSL

[Leon Heess]

Package: live-build
Version: 1:20190311
Severity: important

Dear Maintainer,

I was following your [tutorials on customizing the live debian 
installation](https://live-team.pages.debian.net/live-manual/html/live-manual/examples.en.html#using-the-examples).
 
The last command in every tutorial is `lb build 2>&1 | tee build.log`. But 
every time I use it on my Debian WSL2
machine I run into this:

```
...
P: If the following stage fails, the most likely cause of the problem is with 
your mirror configuration or a caching proxy.
P: Running debootstrap...
mknod: /mnt/c/deb-live-tutorial/chroot/test-dev-null: Operation not supported
E: Cannot install into target '/mnt/c/deb-live-tutorial/chroot' mounted with 
noexec or nodev
P: Begin unmounting filesystems...
P: Saving caches...
chroot: failed to run command ‘/usr/bin/env’: No such file or directory
```

Could it be that live-build is not wokring properly inside WSL2?

-- Package-specific info:

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

Kernel: Linux 4.19.104-microsoft-standard (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Versions of packages live-build depends on:
ii  debootstrap  1.0.114

Versions of packages live-build recommends:
ii  apt-utils   1.8.2.3
ii  bzip2   1.0.6-9.2~deb10u1
ii  cpio2.12+dfsg-9
ii  file1:5.35-4+deb10u2
ii  live-boot-doc   1:20190614
ii  live-config-doc 5.20190519
ii  live-manual-html [live-manual]  2:20151217.1
ii  wget1.20.1-1.1
ii  xz-utils5.2.4-1

Versions of packages live-build suggests:
ii  e2fsprogs  1.44.5-1+deb10u3
pn  mtd-utils  
pn  parted 

-- no debconf information

Bug#1002626: debian-policy: building packages should not require to be root

[Bill Allombert]

On Sat, Dec 25, 2021 at 10:38:47PM +0100, Vincent Lefevre wrote:
> Package: debian-policy
> Version: 4.6.0.1
> Severity: important
> 
> Building packages should not require to be root.

Hello Vincent!

Currently, packages are allowed to require root to build.
See Rules-Requires-Root for more detail.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#1002627: transition: alglib

[Anton Gladky]

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512


Dear release team,

please provide a slot for the transition of alglib.
All reverse-dependencies are checked and not FTBFS are detected.
So the tranition should be short and easy.

Thanks,

Anton


Ben file:

title = "alglib";
is_affected = .depends ~ "libalglib3.17" | .depends ~ "libalglib3.18";
is_good = .depends ~ "libalglib3.18";
is_bad = .depends ~ "libalglib3.17";

-BEGIN PGP SIGNATURE-

iQJFBAEBCgAvFiEEu71F6oGKuG/2fnKF0+Fzg8+n/wYFAmHHknARHGdsYWRrQGRl
Ymlhbi5vcmcACgkQ0+Fzg8+n/wb+Eg//VXgqo+MEfluKITlUQyu3bjJ0WP8rbRDb
Bf/0/cHAxjvhowRUI4h9KlyVfhkfDrXQ1+a7p4+M37XFj6uMxpvKrRBUJbfpjwge
D3ydsaS636bjcxhPL6Bf2UXLtAidQ4jWJgNjzgGevxyoTUeKvQX8CqrbYBi7HcxS
zr8JmfaJwwClRXgzhO34mWt5MxdhxlthjNMI17jrrkVxN8SbKYv7eablO3Nre4Mi
SDv16/Gd0T8ldOn41EfNz9F0Sm66XxNlNj7kCRP7c0EDtR/IBJ28NoaBh6jaoU/1
vGvhfsqXaO2XFXcgB4OW/wu3+ioL/Xv6rz88Ec44nEm5Tlbfv2gGfaKD7P2QBa0K
K5WdJOPrZTRfgimr02SS+tXdCZb/d+ucH44tvTgWxWiRFFIrKy+WRQsidYHZpfdP
F0CpRmDcydtr7fxxxz/yQFoUmDaB4wNF/wGOc1nhyH0PupaLEgDekbNuwzqlMu7K
TA/fj+6D5ws4FBxwauVEpWV2Qb8gwJByFXTaDt7vzEhlsDIwgjHP+TVdERyPhYE2
nhs/Hs+RUsYACEjqOk7HXGE+uIrsG05iD8yxFsgGsRdCssESWov5TBJwwm2Vlqq2
JOa/0Vv8iagsarO+neTiKhtRWW1LHqkmVye5uo9wTevj1Ws80aHETAWJqODOSfzU
BBTMi+957/A=
=yKYi
-END PGP SIGNATURE-

Bug#997273: virt-v2v: FTBFS: (.text+0x12a): undefined reference to `rpl_free'

[Hilko Bengen]

control: reassign -1 libguestfs
control: fixed -1 libguestfs/1:1.46.2-1

The root cause seems to lie in the libguestfs-ocaml library and it can
no longer be reproduced with 1:1.46.2-1 which I have just uploaded.

Cheers,
-Hilko

Bug#1002497: FTBFS Arch-All with interactive rm

[Scott Kitterman]

On Saturday, December 25, 2021 4:39:21 PM EST Vincent Lefevre wrote:
> On 2021-12-25 16:25:11 -0500, Scott Kitterman wrote:
> > > So the -f option is needed *everywhere*.
> > 
> > Certainly not a serious bug.  I don't think building the package after
> > write protecting the contents is a particularly supported configuration.
> I am *not* write protecting the contents. I suppose that's debuild,
> or some other build tool.
> 
> > P.S. Don't upgrade the severity again. If you think this is such a
> > big deal, go get something in Debian policy.
> 
> The changelog says:
> 
>   * Do not require postfix to be build by root.
> 
> So one should expect that postfix does not require to be root.

OK.  In that context I think it's fair, but I didn't get that from your 
original comment.  There's only one more spot that needs a -f, so I'll add 
that for the next upload.

Scott K

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

Bug#1002497: FTBFS Arch-All with interactive rm

[Vincent Lefevre]

On 2021-12-25 16:25:11 -0500, Scott Kitterman wrote:
> > So the -f option is needed *everywhere*.
> 
> Certainly not a serious bug.  I don't think building the package after write 
> protecting the contents is a particularly supported configuration.

I am *not* write protecting the contents. I suppose that's debuild,
or some other build tool.

> P.S. Don't upgrade the severity again. If you think this is such a
> big deal, go get something in Debian policy.

The changelog says:

  * Do not require postfix to be build by root.

So one should expect that postfix does not require to be root.

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

Bug#1002626: debian-policy: building packages should not require to be root

[Vincent Lefevre]

Package: debian-policy
Version: 4.6.0.1
Severity: important

Building packages should not require to be root.

I don't know what's going on, but see

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1002497#31

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

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

debian-policy depends on no packages.

Versions of packages debian-policy recommends:
ii  libjs-sphinxdoc  4.3.2-1

Versions of packages debian-policy suggests:
ii  doc-base  0.11.1

-- no debconf information

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

Bug#1002593: imdbpy: please package new upstream release

[Ana Guerrero Lopez]

On Sat, Dec 25, 2021 at 04:16:08PM -0500, Sandro Tosi wrote:
> > Feel free to update it if you need a new version.
> 
> the git repo is under your namespace, so i cannot push updates to it:

Repository access is not limited by namespace, you can change it in
salsa.

> would you be interested in moving it under DPT
> https://salsa.debian.org/python-team/packages/ ?

No need to move it. Everyone in the Debian group should have access to:
https://salsa.debian.org/ana/imdbpy/


Ana

Bug#1002625: wlr-randr autopkgtest failure with phoc 0.11

[Peter Green]

Package: wlr-randr
Version: 0.2.0-1
Severity: serious

The wlr-randr autopkgtest is failing with the new version of phoc

https://ci.debian.net/data/autopkgtest/testing/amd64/w/wlr-randr/17846958/log.gz


autopkgtest [22:48:44]: test command1: WLR_BACKENDS=headless WLR_LIBINPUT_NO_DEVICES=1 
phoc --exec "wlr-randr --output HEADLESS-1 --transform 90"
autopkgtest [22:48:44]: test command1: [---

(phoc:3977): phoc-wlroots-CRITICAL **: 22:48:44.782: 
[backend/headless/backend.c:156] drmGetDevices2 failed: No such file or 
directory

(phoc:3977): phoc-wlroots-CRITICAL **: 22:48:44.782: 
[backend/headless/backend.c:210] Failed to open DRM render node

(phoc:3977): phoc-wlroots-CRITICAL **: 22:48:44.784: [xwayland/server.c:452] Cannot find 
Xwayland binary "/usr/bin/Xwayland"
bash: line 1:  3977 Segmentation fault  bash -ec 'WLR_BACKENDS=headless WLR_LIBINPUT_NO_DEVICES=1 phoc 
--exec "wlr-randr --output HEADLESS-1 --transform 90"' 2> >(tee -a 
/tmp/autopkgtest-lxc.5ig9izv7/downtmp/command1-stderr >&2) > >(tee -a 
/tmp/autopkgtest-lxc.5ig9izv7/downtmp/command1-stdout)
autopkgtest [22:48:45]: test command1: ---]
autopkgtest [22:48:45]: test command1:  - - - - - - - - - - results - - - - - - 
- - - -
command1 FAIL non-zero exit status 139


This is blocking the fix for bug 1001821 from reaching testing.

Bug#1002525: r-cran-tmb: autopkgtest needs update for new version of rmatrix: Package version inconsistency detected.

[Dirk Eddelbuettel]

Hi Nilesh,

On 26 December 2021 at 00:20, Nilesh Patra wrote:
| control: reassign -1 r-cran-tmb/1.7.22-1
| 
| Hi Dirk,
| 
| On Thu, 23 Dec 2021 14:30:10 -0600 Dirk Eddelbuettel  wrote:
| > passfail
| > | rmatrixfrom testing1.4-0-1
| > | r-cran-tmb from testing1.7.22-1
| > | all others from testingfrom testing
| > | 
| > | I copied some of the output at the bottom of this report. It seems the 
| > | binary embeds the version of rmatrix it's build against without 
| > | declaring proper versioned Dependencies to reflect that.
| > 
| > Yes. Apparently a design decision of the (R package) TMB package imposed
| > after the slight accidents that append with the (R package) Matrix (aka
| > rmatrix for us) during its last ABI/API change (at version 1.3.0 and after).
| > Not a lot we can do, other than to patch it out in TMB.
| 
| Interesting. OK, I did the needful and uploaded. rmatrix should migrate 
soonish.
| 
| > Nothing I can do (as maintainer of r-cran-matrix built of source package
| > rmatrix aka CRAN package Matrix.
| 
| What you can do is inform people about it, by sending an email to the mailing 
list.
| Someone would take that up soonish.
| As per your words, and as per the autopkgtest problem, it needs a 
re-compilation, with
| every new rmatrix, and that does not happen by default with buildd machines, 
right.

It's a fairly rare case. I had it myself with Rcpp (version 1.0.7) too.

What we might need _within the R ecosystem_ is the ability to push binary
rebuilds through. 

| > | Currently this regression is blocking the migration of rmatrix to 
| > | testing [1]. Of course, rmatrix shouldn't just break your autopkgtest 
| > | (or even worse, your package), but it seems to me that the change in 
| > | rmatrix was intended and your package needs to update to the new 
situation.
| > 
| > None of that, AFAIK, comes from R package Matrix. It is just TMB.
| 
| Yep.
| 
| > Coupled with what happens around here with our ability to not keep packages
| > aligned with their CRAN versions.
| 
| For this particular bug, tmb is already at the latest version, so it has got 
nothing to
| do with this bug report.

Yes. I guess it is the forced rebuild we need.

I wonder if the TMB maintainer should have resorted to  Matrix (>= 1.4.0)  ?

| If I talk about it otherwise then, I am usually (personally) trying to keep 
everything to CRAN-latest
| and Andreas helps with that. There are some blockers in the process for 
instance introduction of new cran
| dependencies that are un-packaged. So we quickly package that and upload to 
NEW, but then,
| there is nothing we can do in those cases except waiting action for accept 
from the FTP-team.
| Despite this, the number of cran-'non'-latest had been well below 20 (IIRC it 
was max 10) for past
| several months.
| 
| It has now unfortunately increased a little (but manageable) because we have 
less time.
| At the end of the day, we are all 'volunteers'
| 
| > | If this is a real problem in your package (and not only in your 
| > | autopkgtest), the right binary package(s) from rmatrix should really add 
| > | a versioned Breaks on the unfixed version of (one of your) package(s). 
| > 
| > I don't think I agree. Matrix does nothing here. You appear to be shooting a
| > messenger.
| 
| Actually, that's sort of a templated reply that you see above which is 
reasonable since there are so many similar bugs,
| if you see other bugs that break autopkgtests, you will find the wording to 
be awfully similar. For example:
| 
| https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=996279
| 
| Hence, we need to re-assign and check accordingly.

As I mentioned before, I cannot not help but think these autopkgtests _for
CRAN packages_ add nothing (as CRAN does for all tests for us already), but
create extra work (when we slip away from CRAN pairings and create our own
bugs).

But we're all adults and as you all feel it adds value, you keep doing
it. Such is life. We're volunteers and if that is what you all do then I am
still thankful for all the other work ;-)

| Lastly, Merry Christmas! :)

Thanks!  Same to you.

Dirk
 
| Kind Regards,
| Nilesh
| x[DELETED ATTACHMENT signature.asc, application/pgp-signature]

-- 
https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Bug#1002497: FTBFS Arch-All with interactive rm

[Scott Kitterman]

On Saturday, December 25, 2021 3:43:24 PM EST Vincent Lefevre wrote:
> Control: severity -1 serious
> Control: tags -1 ftbfs
> Control: retitle -1 postfix: FTBFS Arch-All as rm on a write-protected file
> is interactive
> On 2021-12-23 11:12:40 +0100, Daniel Baumann wrote:
> > there seems to be 'rm' missing the '-f', which makes the package fail to
> > build from source if the building system has rm aliased to 'rm -i'.
> 
> Even without such an alias:
> 
> vinc17 33260   27638  0 21:34 pts/13   00:00:00 rm
> debian/postfix-doc/usr/share/doc/postfix/html/Makefile.in
> 
> This is the default behavior of rm on a write-protected file, such as
> 
> -r--r--r-- 1 vinc17 vinc17 12526 2021-12-25 21:34:15
> debian/postfix-doc/usr/share/doc/postfix/html/Makefile.in
> 
> So the -f option is needed *everywhere*.

Certainly not a serious bug.  I don't think building the package after write 
protecting the contents is a particularly supported configuration.

Scott K

P.S.  Don't upgrade the severity again.  If you think this is such a big deal, 
go get something in Debian policy.

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

Bug#1002497: FTBFS Arch-All with interactive rm

[Vincent Lefevre]

On 2021-12-23 08:35:44 -0500, Scott Kitterman wrote:
> Thanks.  Fix staged in git for the next upload.  It seems slightly odd to me 
> that this comes up now as it's been that way since at least 2012.

Not really. Compared to postfix 3.6.3-1, "Rules-Requires-Root: no"
has been added to debian/control (and removing it solves the issue).
I suppose that fakeroot is involved here.

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

Bug#1002593: imdbpy: please package new upstream release

[Sandro Tosi]

> Feel free to update it if you need a new version.

the git repo is under your namespace, so i cannot push updates to it:
would you be interested in moving it under DPT
https://salsa.debian.org/python-team/packages/ ?

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

Bug#1002593: imdbpy: please package new upstream release

[Ana Guerrero Lopez]

Hi,

On Fri, Dec 24, 2021 at 05:45:18PM -0500, Sandro Tosi wrote:
> Source: imdbpy
> Severity: normal
> X-Debbugs-Cc: mo...@debian.org
> 
> Hello,
> upstream released a new version several months ago: 2021.04.18
> 
> Please update the debian package.

Feel free to update it if you need a new version.

Cheers,
Ana

Bug#1002497: FTBFS Arch-All with interactive rm

[Vincent Lefevre]

Control: severity -1 serious
Control: tags -1 ftbfs
Control: retitle -1 postfix: FTBFS Arch-All as rm on a write-protected file is 
interactive

On 2021-12-23 11:12:40 +0100, Daniel Baumann wrote:
> there seems to be 'rm' missing the '-f', which makes the package fail to
> build from source if the building system has rm aliased to 'rm -i'.

Even without such an alias:

vinc17 33260   27638  0 21:34 pts/13   00:00:00 rm 
debian/postfix-doc/usr/share/doc/postfix/html/Makefile.in

This is the default behavior of rm on a write-protected file, such as

-r--r--r-- 1 vinc17 vinc17 12526 2021-12-25 21:34:15 
debian/postfix-doc/usr/share/doc/postfix/html/Makefile.in

So the -f option is needed *everywhere*.

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

Bug#1002624: Screenshot attached

[qazwsxedc]

Bug#915379: anacron.service: should probably use KillMode=process

[Tomas Janousek]

Hi,

On Fri, Feb 26, 2021 at 09:08:18AM +0100, Marc Haber wrote:

Worse. If the receiving side does post-DATA checking of the message, and
systemd sends SIGKILL to the exim process on the sending side, the
receiving side might continue delivery without the sending side noticing
the confirmation (it's already dead by then). During the next exim queue
run, the message will be delivered a second time.

In this case, 5 seconds of extra wait would probably not be enough.


This entry in the systemd 250 NEWS gives me hope this might be fixed in 
a nice way eventually:


* A new service unit file setting ExitType= has been added that
  specifies when to assume a service has exited. By default systemd
  only watches the main process of a service. By setting
  ExitType=cgroup it can be told to wait for the last process in a
  cgroup instead.

I'll probably experiment with it once systemd 250 lands in testing, 
unless someone beats me to it.


--
Tomáš "liskin" ("Pivník") Janoušek, https://lisk.in/

Bug#1002624: mate-power-manager: In British English config, mate-power-statistics labels charging "state" as "county"

[Qaz]

Package: mate-power-manager
Version: 1.24.2-1
Severity: normal
X-Debbugs-Cc: qazwsx...@gmx.net

Dear Maintainer,

This bug made me smile. It's clearly a translation error, confusing the term
"state" (meaning condition) with "state" (meaning political subunit of a 
country)
and then translating it into the British English equivalent. 

   * What led up to the situation?
Invoking mate-power-statistics from the battery icon in the system tray
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
Invoking mate-power-statistics from the battery icon in the system tray
   * What was the outcome of this action?
The charging state attribute on the details tab of the battery properties is 
labelled "County"
   * What outcome did you expect instead?
That the charging state attribute is labelled "State", even in British English.

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

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

Versions of packages mate-power-manager depends on:
ii  dbus-user-session [default-dbus-session-bus]1.12.20-2
ii  dbus-x11 [dbus-session-bus] 1.12.20-2
ii  libc6   2.31-9
ii  libcairo2   1.16.0-5
ii  libcanberra-gtk3-0  0.30-7
ii  libcanberra00.30-7
ii  libdbus-1-3 1.12.20-2
ii  libdbus-glib-1-20.110-6
ii  libgdk-pixbuf2.0-0  2.40.2-2
ii  libglib2.0-02.66.7-1
ii  libgtk-3-0  3.24.24-1
ii  libmate-panel-applet-4-11.24.1-1
ii  libnotify4  0.7.9-3
ii  libpango-1.0-0  1.46.2-3
ii  libpangocairo-1.0-0 1.46.2-3
ii  libupower-glib3 0.99.11-2
ii  libx11-62:1.7.0-2
ii  libxext62:1.3.3-1.1
ii  libxrandr2  2:1.5.1-1
ii  mate-notification-daemon [notification-daemon]  1.24.1-1
ii  mate-power-manager-common   1.24.2-1
ii  notification-daemon 3.20.0-4
ii  policykit-1 0.105-30
ii  systemd 247.3-1
ii  upower  0.99.11-2

mate-power-manager recommends no packages.

Versions of packages mate-power-manager suggests:
ii  mate-polkit  1.24.0-2

-- no debconf information

Bug#1001914: debhelper: dh_missing does not recognise pyinstall files

[Stefano Rivera]

Hi Drew (2021.12.18_15:24:36_-0400)
> dh_missing appears to be ignoring the *pyinstall files and reports the
> python files as "missing", which from debhelper 13 causes the build to
> fail.

I started trying to implement this properly, but soon came to the
conclusion that this isn't really the right thing to do.

The intent of pyinstall files is not as a dh_install clone, for pulling
files from debian/tmp, but rather as a simple mechanism for installing
Python modules when the upstream doesn't provide an installer.

> getfem++ has debian/python3-getfem++.pyinstall containing
>   debian/tmp/usr/lib/python*/*-packages/getfem/*.py getfem
>   interface/src/python/*.so getfem

I think the second line in your pyinstall makes sense, installing
something from the source tree that upstream didn't install for you.
But for the first one, pulling something from debian/tmp, dh_install is
probably the better tool.

The only argument I can see for handling dh_missing properly with
pyinstall files is so that these two tasks can go in one place.

SR

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

Bug#1002623: nltk: CVE-2021-43854

[Salvatore Bonaccorso]

Source: nltk
Version: 3.6.5-1
Severity: important
Tags: security upstream
Forwarded: https://github.com/nltk/nltk/issues/2866
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for nltk.

CVE-2021-43854[0]:
| NLTK (Natural Language Toolkit) is a suite of open source Python
| modules, data sets, and tutorials supporting research and development
| in Natural Language Processing. Versions prior to 3.6.5 are vulnerable
| to regular expression denial of service (ReDoS) attacks. The
| vulnerability is present in PunktSentenceTokenizer, sent_tokenize and
| word_tokenize. Any users of this class, or these two functions, are
| vulnerable to the ReDoS attack. In short, a specifically crafted long
| input to any of these vulnerable functions will cause them to take a
| significant amount of execution time. If your program relies on any of
| the vulnerable functions for tokenizing unpredictable user input, then
| we would strongly recommend upgrading to a version of NLTK without the
| vulnerability. For users unable to upgrade the execution time can be
| bounded by limiting the maximum length of an input to any of the
| vulnerable functions. Our recommendation is to implement such a limit.


If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2021-43854
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-43854
[1] https://github.com/nltk/nltk/issues/2866
[2] https://github.com/nltk/nltk/security/advisories/GHSA-f8m6-h2c7-8h9x

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1002622: schleuder: ActiveRecord >= 6.0 changes boolean serialization, makes existing mailing lists fail

[Georg Faerber]

Package: schleuder
Version: 3.6.0-3
Severity: grave
Justification: renders package unusable
Forwarded: https://0xacab.org/schleuder/schleuder/-/issues/505
Tags: fixed-upstream

Since ActiveRecord >= 6.0, the SQLite3 connection adapter relies on
boolean serialization to use 1 and 0, but does not natively recognize
't' and 'f' as booleans were previously serialized. This change made
existing mailing lists fail, after people upgraded buster to bullseye,
due to the involved ActiveRecord version bump, as Schleuder isn't able
anymore to fetch correct values from the database.

Unfortunately, we missed this breaking change when bumping ActiveRecord
to >= 6.0 recently. This caused quite some work upstream, but also in
downstream environments and, last but not least, at the side of users.

We should extend our CI to explicitly test, and ensure things work as
expected, if running a Schleuder setup in real world. As of now, we
don't ensure data provided by a user in Schleuder version x still works
after upgrading to version y.

Bug#1001908: manpages-de: manpage of "shutdown" not up-to-date

[Mario Blättermann]

Hello all,

Am Fr., 24. Dez. 2021 um 10:27 Uhr schrieb Helge Kreutzmann
:
>
> Hello Mark,
> On Fri, Dec 24, 2021 at 08:13:56AM +, Mark Hindley wrote:
> > [Adding CC debian-init-divers...@chiark.greenend.org.uk]
>
> And adding Mario, manpages-l10n upstream maintainer as well.
>
> > Thanks for this.
>
> You are welcome, and thanks for considering.
>
> > On Thu, Dec 23, 2021 at 05:39:20PM +0100, Helge Kreutzmann wrote:
> > > In Debian we have the situation that some man pages are shipped by
> > > several packages. This is fine for the english versions, as there the
> > > alternatives mechanism takes care of this.
> > >
> > > For translated man pages this is not possible (at least currently), so
> > > as manpages-l10n we have to decide which upstream to follow.
> > >
> > > Until now we chose System-V over Systemd. However, this bug report
> > > showed that this causes confusion and I will ask manpage-l10n upstream
> > > to switch Debian to Systemd as well.
> >
> > I see that manpage-l10n upstream switching to the default init makes sense 
> > for
> > the majority.
> >
> > > Since all other distributions we support already use the Systemd
> > > version, this means the translations we currently have we vanish for
> > > Sysv-Init users if nothing else happens. (#3 below)
> > >
> > > I can propose three courses of action, in the order of my preference:
> > >
> > > 1. Sysv core adopts po4a and includes the translation framework as
> > >well as the translations (see below for the overview). I will
> > >provide you help on this (in January), probably Mario (the upstream
> > >maintainer of manpage-l10n) might give you some help as well. Then
> > >the man pages will keep up to date (see rationale in 2) and more
> > >translators / languages can be easily integrated, if translators
> > >pop up.
> >
> > Indeed, to me, this seems the cleanest solution in the long run. Thanks for 
> > the
> > offer of help.
>
> Yes, this offer stands. I'll can support you in January 2022 on doing
> this, meanwhile Mario, who is helped other projects adopting po4a,
> might give some advice as well.
>
OK, it is in my favor to both keep existing man page translations
alive (acknowledging the work of the previous translators) and
integrate Po4a-based translations into upstream projects, instead of
maintaining them in an external translation project. Give me some days
to prepare a Po4a framework and migrate the existing .po files. I've
already checked out the Git repo at savannah.nongnu.org. I would
create the changes in one single (and quite big) Git diff, is this OK
for you? Or is there even a mirror at Github or Gitlab or wherever
else where I could create a pull request?

Best Regards,
Mario

Bug#1002620: bullseye-pu: package pypy3/7.3.5+dfsg-2+deb11u1

[Stefano Rivera]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu

[ Reason ]
An extraneous #endif in import.h makes using it impossible.

This was fixed upstream, in unstable & testing.

[ Impact ]
C extension modules that include import.h can't be built.

[ Tests ]
Autopkgtests pass, but they do not exercise import.h.

Manually confirmed the issue in the existing binary package, and
verified that the new version resolves the issue.

[ Risks ]
Trivial change in a rarely-touched file, upstream.

[ Checklist ]
  [x] *all* changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in (old)stable
  [x] the issue is verified as fixed in unstable

[ Changes ]
Remove the extra #endif.
diff -Nru pypy3-7.3.5+dfsg/debian/changelog pypy3-7.3.5+dfsg/debian/changelog
--- pypy3-7.3.5+dfsg/debian/changelog   2021-06-03 15:59:21.0 -0400
+++ pypy3-7.3.5+dfsg/debian/changelog   2021-12-25 11:54:46.0 -0400
@@ -1,3 +1,9 @@
+pypy3 (7.3.5+dfsg-2+deb11u1) bullseye; urgency=medium
+
+  * Patch: Remove extraneous #endif from import.h (Closes: #1001519)
+
+ -- Stefano Rivera   Sat, 25 Dec 2021 11:54:46 -0400
+
 pypy3 (7.3.5+dfsg-2) unstable; urgency=medium
 
   * Upload to unstable.
diff -Nru pypy3-7.3.5+dfsg/debian/patches/import-h-endif 
pypy3-7.3.5+dfsg/debian/patches/import-h-endif
--- pypy3-7.3.5+dfsg/debian/patches/import-h-endif  1969-12-31 
20:00:00.0 -0400
+++ pypy3-7.3.5+dfsg/debian/patches/import-h-endif  2021-12-25 
11:54:46.0 -0400
@@ -0,0 +1,23 @@
+From: Matti Picus 
+Date: Sat, 25 Dec 2021 11:50:49 -0400
+Subject: cpyext: typo in import.h
+
+Bug-Debian: https://bugs.debian.org/1001519
+Origin: upstream, 
https://foss.heptapod.net/pypy/pypy/-/commit/f8d0f6ad0832af43ef0cd0feabad9f0f408b0110
+---
+ pypy/module/cpyext/include/import.h | 2 --
+ 1 file changed, 2 deletions(-)
+
+diff --git a/pypy/module/cpyext/include/import.h 
b/pypy/module/cpyext/include/import.h
+index f03457b..7460c0a 100644
+--- a/pypy/module/cpyext/include/import.h
 b/pypy/module/cpyext/include/import.h
+@@ -18,8 +18,6 @@ PyAPI_FUNC(PyObject *) PyImport_ImportModuleLevel(
+ #define PyImport_ImportModuleEx(n, g, l, f) \
+ PyImport_ImportModuleLevel(n, g, l, f, 0)
+ 
+-#endif
+-
+ #ifdef __cplusplus
+ }
+ #endif
diff -Nru pypy3-7.3.5+dfsg/debian/patches/series 
pypy3-7.3.5+dfsg/debian/patches/series
--- pypy3-7.3.5+dfsg/debian/patches/series  2021-06-03 15:59:21.0 
-0400
+++ pypy3-7.3.5+dfsg/debian/patches/series  2021-12-25 11:54:46.0 
-0400
@@ -21,3 +21,4 @@
 tkinter-import
 noise
 python3-sphinx
+import-h-endif

Bug#1002619: bullseye-pu: package gnuplot/gnuplot_5.4.1+dfsg1-1+deb11u1

[Anton Gladky]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear release team,

[ Reason ]
gnuplot_5.4.1+dfsg1-1+deb11u1 is fixing security issue CVE-2021-44917.
Please include it into the bullseye.

[ Impact ]
Security issue

[ Tests ]
Done on CI and locally.

[ Risks ]
No risks awaited

[ Checklist ]
  [x] *all* changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in (old)stable
  [x] the issue is verified as fixed in unstable

[ Changes ]
Patch imported from upstream.

Thanks

Anton

-BEGIN PGP SIGNATURE-

iQJFBAEBCgAvFiEEu71F6oGKuG/2fnKF0+Fzg8+n/wYFAmHHZV4RHGdsYWRrQGRl
Ymlhbi5vcmcACgkQ0+Fzg8+n/waXwg/+N32dARCRDysGWA2f1KWiP/9slcH00cYQ
Vyja1+nYut1S4HuWv8oWX7dvC9anSj8+I123M3Q7k2kG1iRN0FyydXnxwQT7xU8p
ewS0NJvgO8QLPAS1kAzn72zT6KMnBlIbYoLGuVjnWRpQiCO8P0GJ8pgK7mr1tNN2
2/t+TfD7gvGgpN1ZIxnrpa5wwSBvG/txJqO7sazC6O7NZwRRxzHP5GG1Gn6I6yJP
MparDEkNpSDeZTIo6o6D6g8dnMVIG6ukpWp0aJIHzKpy6a/P3agzglwTyl2V20+L
m06EP4/zureXmAQz8mCA7rvTMo/N6LCRPKVOssNXwnja98kD612icYFhFg+P7tOY
xlhbHVh+E8mEAbbovfaQp0MvlkvrkOwB0KtB8vcSaC0//HU3OsBS4f0g8Gb+fFa6
9OMTuCZ3XUEiNXHOr8P6LyCwK6R+blU1O0nAF8DuC14nR00Wjbi/h6SwuHNvNHEq
WuGwLp2fWDKBd4ViQCMRwI5IcEhi9usW+q3e/X08VuI2t/tb2Nv+5fPbqTzQ6q1w
TD4vQOT8YrTP4i+MKDOUkXoVePidmVNVHmChEgANqCMQfQ85gcHT6ldq1l+GADJ9
pVLZi6qjA3T/ePS70Dox/TAy/saKXO7hQhtlj4V4vKm2EGh0hvZzdS6wkvMHORuq
z6abtXAa96M=
=tBfC
-END PGP SIGNATURE-
diff -Nru gnuplot-5.4.1+dfsg1/debian/changelog 
gnuplot-5.4.1+dfsg1/debian/changelog
--- gnuplot-5.4.1+dfsg1/debian/changelog2020-12-03 22:27:21.0 
+0100
+++ gnuplot-5.4.1+dfsg1/debian/changelog2021-12-25 19:15:06.0 
+0100
@@ -1,3 +1,9 @@
+gnuplot (5.4.1+dfsg1-1+deb11u1) bullseye; urgency=medium
+
+  * Fix divide by zero vulnerability. CVE-2021-44917.  (Closes: #1002539)
+
+ -- Anton Gladky   Sat, 25 Dec 2021 19:15:06 +0100
+
 gnuplot (5.4.1+dfsg1-1) unstable; urgency=medium
 
   * [945257b] New upstream version 5.4.1+dfsg1
diff -Nru gnuplot-5.4.1+dfsg1/debian/.gitlab-ci.yml 
gnuplot-5.4.1+dfsg1/debian/.gitlab-ci.yml
--- gnuplot-5.4.1+dfsg1/debian/.gitlab-ci.yml   2020-09-24 23:46:23.0 
+0200
+++ gnuplot-5.4.1+dfsg1/debian/.gitlab-ci.yml   2021-12-25 19:15:06.0 
+0100
@@ -1,3 +1,4 @@
 include:
- - https://salsa.debian.org/salsa-ci-team/pipeline/raw/master/salsa-ci.yml
- - https://salsa.debian.org/salsa-ci-team/pipeline/raw/master/pipeline-jobs.yml
+ - 
https://salsa.debian.org/salsa-ci-team/pipeline/raw/master/recipes/debian.yml
+variables:
+  RELEASE: 'bullseye'
diff -Nru gnuplot-5.4.1+dfsg1/debian/patches/CVE-2021-44917.patch 
gnuplot-5.4.1+dfsg1/debian/patches/CVE-2021-44917.patch
--- gnuplot-5.4.1+dfsg1/debian/patches/CVE-2021-44917.patch 1970-01-01 
01:00:00.0 +0100
+++ gnuplot-5.4.1+dfsg1/debian/patches/CVE-2021-44917.patch 2021-12-25 
19:15:06.0 +0100
@@ -0,0 +1,114 @@
+Description: 
+ TODO: Put a short summary on the line above and replace this paragraph
+ with a longer explanation of this change. Complete the meta-information
+ with other relevant fields (see below for details). To make it easier, the
+ information below has been extracted from the changelog. Adjust it or drop
+ it.
+ .
+ gnuplot (5.4.2+dfsg2-1) unstable; urgency=medium
+ .
+   * [4370a18] Update d/watch
+   * [7d7c5c0] New upstream version 5.4.2+dfsg1.orig
+   * [97d5d83] Refresh patches
+   * [9d8bbae] Update gitlab.ci
+   * [e168129] Use secure URI in debian/watch.
+   * [08324bf] Bump debhelper from old 12 to 13.
+   * [3a47530] Update standards version to 4.5.1, no changes needed.
+   * [ba4a50d] Avoid explicitly specifying -Wl,--as-needed linker flag.
+   * [9ce752b] Set Standards-Version: 4.6.0
+   * [917e564] Use execute-syntax for some commands in d/rules
+Author: Anton Gladky 
+
+---
+The information above should follow the Patch Tagging Guidelines, please
+checkout http://dep.debian.net/deps/dep3/ to learn about the format. Here
+are templates for supplementary fields that you might want to add:
+
+Origin: , 
+Bug: 
+Bug-Debian: https://bugs.debian.org/
+Bug-Ubuntu: https://launchpad.net/bugs/
+Forwarded: 
+Reviewed-By: 
+Last-Update: 2021-12-25
+
+Index: gnuplot-5.4.1+dfsg1/src/set.c
+===
+--- gnuplot-5.4.1+dfsg1.orig/src/set.c
 gnuplot-5.4.1+dfsg1/src/set.c
+@@ -5058,18 +5058,6 @@ set_terminal()
+   fprintf(stderr,"Options are '%s'\n",term_options);
+ if ((term->flags & TERM_MONOCHROME))
+   init_monochrome();
+-
+-/* Sanity check:
+- * The most common failure mode found by fuzzing is a divide-by-zero
+- * caused by initializing the basic unit of the current terminal character
+- * size to zero.  I keep patching the individual terminals, but a generic
+- * sanity check may at least prevent a crash due to mistyping.
+- */
+-if 

Bug#1002525: r-cran-tmb: autopkgtest needs update for new version of rmatrix: Package version inconsistency detected.

[Nilesh Patra]

control: reassign -1 r-cran-tmb/1.7.22-1

Hi Dirk,

On Thu, 23 Dec 2021 14:30:10 -0600 Dirk Eddelbuettel  wrote:
> passfail
> | rmatrixfrom testing1.4-0-1
> | r-cran-tmb from testing1.7.22-1
> | all others from testingfrom testing
> | 
> | I copied some of the output at the bottom of this report. It seems the 
> | binary embeds the version of rmatrix it's build against without 
> | declaring proper versioned Dependencies to reflect that.
> 
> Yes. Apparently a design decision of the (R package) TMB package imposed
> after the slight accidents that append with the (R package) Matrix (aka
> rmatrix for us) during its last ABI/API change (at version 1.3.0 and after).
> Not a lot we can do, other than to patch it out in TMB.

Interesting. OK, I did the needful and uploaded. rmatrix should migrate soonish.

> Nothing I can do (as maintainer of r-cran-matrix built of source package
> rmatrix aka CRAN package Matrix.

What you can do is inform people about it, by sending an email to the mailing 
list.
Someone would take that up soonish.
As per your words, and as per the autopkgtest problem, it needs a 
re-compilation, with
every new rmatrix, and that does not happen by default with buildd machines, 
right.

> | Currently this regression is blocking the migration of rmatrix to 
> | testing [1]. Of course, rmatrix shouldn't just break your autopkgtest 
> | (or even worse, your package), but it seems to me that the change in 
> | rmatrix was intended and your package needs to update to the new situation.
> 
> None of that, AFAIK, comes from R package Matrix. It is just TMB.

Yep.

> Coupled with what happens around here with our ability to not keep packages
> aligned with their CRAN versions.

For this particular bug, tmb is already at the latest version, so it has got 
nothing to
do with this bug report.

If I talk about it otherwise then, I am usually (personally) trying to keep 
everything to CRAN-latest
and Andreas helps with that. There are some blockers in the process for 
instance introduction of new cran
dependencies that are un-packaged. So we quickly package that and upload to 
NEW, but then,
there is nothing we can do in those cases except waiting action for accept from 
the FTP-team.
Despite this, the number of cran-'non'-latest had been well below 20 (IIRC it 
was max 10) for past
several months.

It has now unfortunately increased a little (but manageable) because we have 
less time.
At the end of the day, we are all 'volunteers'

> | If this is a real problem in your package (and not only in your 
> | autopkgtest), the right binary package(s) from rmatrix should really add 
> | a versioned Breaks on the unfixed version of (one of your) package(s). 
> 
> I don't think I agree. Matrix does nothing here. You appear to be shooting a
> messenger.

Actually, that's sort of a templated reply that you see above which is 
reasonable since there are so many similar bugs,
if you see other bugs that break autopkgtests, you will find the wording to be 
awfully similar. For example:

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

Hence, we need to re-assign and check accordingly.

Lastly, Merry Christmas! :)

Kind Regards,
Nilesh


signature.asc
Description: PGP signature

Bug#1002618: ITP: pass-audit -- pass extension for auditing your password repository

[Thomas Perret]

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

* Package name: pass-audit
  Version : 1.1
  Upstream Author : Alexandre Pujol 
* URL : https://github.com/roddhjav/pass-audit
* License : GPL-3+
  Programming Lang: Bash, Python
  Description : pass extension for auditing your password repository

pass audit is a password-store extension for auditing your password repository.
Passwords will be checked against the Python implementation of Dropbox' zxcvbn
algorithm and Troy Hunt's Have I Been Pwned Service.
It supports safe breached password detection from haveibeenpwned.com using a
K-anonymity method. Using this method, you do not need to (fully) trust the
server that stores the breached password.
You should read the security consideration section for more information.

I plan to maintain it in the global salsa namespace. As I'm a Debian 
MaintainerI will need a sponsor for the first upload.

Thomas

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

[Fabio Fantoni]

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


In any cases some useful infos:

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


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



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


is correct

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


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

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




OpenPGP_signature
Description: OpenPGP digital signature

Bug#1002617: RFS: carl9170fw/1.9.9-399-gcd480b9-1 [ITP] -- firmware for AR9170 USB wireless adapters

[John Scott]

Package: sponsorship-requests
Severity: wishlist
X-Debbugs-CC: debian-ker...@lists.debian.org

Dear mentors and Kernel Team,

I'm looking for a sponsor for my package "carl9170fw":

 * Package name    : carl9170fw
   Version : 1.9.9-399-gcd480b9-1
   Upstream Author : linux-wirel...@vger.kernel.org
 * URL :  
  https://wireless.wiki.kernel.org/en/users/Drivers/carl9170
 * License : many; the binary is effectively GPL 2.0 only
 * Vcs : https://salsa.debian.org/kernel-team/carl9170fw
   Section : kernel

It builds those binary packages:

  firmware-carl9170 - firmware for AR9170 USB wireless adapters
  firmware-carl9170-di - firmware for AR9170 USB wireless adapters -
udeb

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

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

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

  dget -x
https://mentors.debian.net/debian/pool/main/c/carl9170fw/carl9170fw_1.9.9-399-gcd480b9-1.dsc

This is the initial upload of the carl9170 libre wireless firmware.
Although it's already shipped in firmware-linux-free, this package will
build it from source using the already-packaged SuperH cross-compiler.

The package will not yet be installable unless one manually deletes the
carl9170fw binary on their system. The goal of this upload is just to
get the package through NEW. After it clears NEW, we'll be able to do
the handover of the firmware by (in order, hopefully within the span of
a day or so):
 * having firmware-carl9170 add Breaks+Replaces on firmware-linux-free
and uploading to unstable
 * taking the firmware out of firmware-linux-free
 * having firmware-linux-free add Recommends: firmware-carl9170
 * and then uploading firmware-linux-free to unstable

I don't expect that the udeb will be used by the Debian Installer
anytime soon because I still have to learn how to make that happen, but
based on previous discussions I know it will be necessary.

It's not strictly necessary (they can be done in either order), but a
sponsor who wants to help could also upload gcc-sh-elf v2 for me. That
RFS is #1002582.

I own the hardware and can affirm that this package works with it.


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

Bug#965882: xbindkeys-config: diff for NMU version 0.1.3-2.3

[gregor herrmann]

Control: tags 965882 + patch
Control: tags 965882 + pending
Control: tags 999054 + patch
Control: tags 999054 + pending


Dear maintainer,

I've prepared an NMU for xbindkeys-config (versioned as 0.1.3-2.3) and
uploaded it to DELAYED/7. Please feel free to tell me if I
should delay it longer.

Regards.


-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   NP: Alan Jackson: Chattahoochee
diff -u xbindkeys-config-0.1.3/debian/changelog xbindkeys-config-0.1.3/debian/changelog
--- xbindkeys-config-0.1.3/debian/changelog
+++ xbindkeys-config-0.1.3/debian/changelog
@@ -1,3 +1,15 @@
+xbindkeys-config (0.1.3-2.3) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix "Removal of obsolete debhelper compat 5 and 6 in bookworm":
+Bump to 7 in debian/{compat,control}.
+(Closes: #965882)
+  * Fix "missing required debian/rules targets build-arch and/or build-
+indep": Add targets in debian/rules.
+(Closes: #999054)
+
+ -- gregor herrmann   Sat, 25 Dec 2021 18:36:40 +0100
+
 xbindkeys-config (0.1.3-2.2) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -u xbindkeys-config-0.1.3/debian/compat xbindkeys-config-0.1.3/debian/compat
--- xbindkeys-config-0.1.3/debian/compat
+++ xbindkeys-config-0.1.3/debian/compat
@@ -1 +1 @@
-5
+7
diff -u xbindkeys-config-0.1.3/debian/control xbindkeys-config-0.1.3/debian/control
--- xbindkeys-config-0.1.3/debian/control
+++ xbindkeys-config-0.1.3/debian/control
@@ -2,7 +2,7 @@
 Section: x11
 Priority: optional
 Maintainer: Joerg Jaspert 
-Build-Depends: debhelper (>> 5.0.0), libgtk2.0-dev
+Build-Depends: debhelper (>> 7.0.0), libgtk2.0-dev
 Standards-Version: 3.8.0
 
 Package: xbindkeys-config
diff -u xbindkeys-config-0.1.3/debian/rules xbindkeys-config-0.1.3/debian/rules
--- xbindkeys-config-0.1.3/debian/rules
+++ xbindkeys-config-0.1.3/debian/rules
@@ -16,7 +16,9 @@
 CFLAGS += -O2
 endif
 
-build: build-stamp
+build: build-arch build-indep
+build-arch: build-stamp
+build-indep: build-stamp
 
 build-stamp:
 	dh_testdir
@@ -64,4 +66,4 @@
 	dh_builddeb
 
 binary: binary-indep binary-arch
-.PHONY: build clean binary-indep binary-arch binary install configure
+.PHONY: build-indep build-arch build clean binary-indep binary-arch binary install configure


signature.asc
Description: Digital Signature

Bug#861345: libcompface: diff for NMU version 1:1.5.2-5.1

[gregor herrmann]

Control: tags 861345 + pending
Control: tags 965632 + patch
Control: tags 965632 + pending
Control: tags 999263 + patch
Control: tags 999263 + pending


Dear maintainer,

I've prepared an NMU for libcompface (versioned as 1:1.5.2-5.1) and
uploaded it to DELAYED/7. Please feel free to tell me if I
should delay it longer.

Regards.


-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   NP: Alan Jackson: Chattahoochee
diff -u libcompface-1.5.2/debian/control libcompface-1.5.2/debian/control
--- libcompface-1.5.2/debian/control
+++ libcompface-1.5.2/debian/control
@@ -3,7 +3,7 @@
 Priority: optional
 Maintainer: Hakan Ardo 
 Standards-Version: 3.2.1.0
-Build-Depends: debhelper (>=5)
+Build-Depends: debhelper (>=7)
 
 Package: libcompfaceg1-dev
 Section: devel
diff -u libcompface-1.5.2/debian/compat libcompface-1.5.2/debian/compat
--- libcompface-1.5.2/debian/compat
+++ libcompface-1.5.2/debian/compat
@@ -1 +1 @@
-5
+7
diff -u libcompface-1.5.2/debian/control.common libcompface-1.5.2/debian/control.common
--- libcompface-1.5.2/debian/control.common
+++ libcompface-1.5.2/debian/control.common
@@ -3,7 +3,7 @@
 Priority: optional
 Maintainer: Hakan Ardo 
 Standards-Version: 3.2.1.0
-Build-Depends: debhelper (>=5)
+Build-Depends: debhelper (>=7)
 
 Package: libcompfaceg1-dev
 Section: devel
diff -u libcompface-1.5.2/debian/changelog libcompface-1.5.2/debian/changelog
--- libcompface-1.5.2/debian/changelog
+++ libcompface-1.5.2/debian/changelog
@@ -1,3 +1,22 @@
+libcompface (1:1.5.2-5.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+
+  [ Helmut Grohne ]
+  * Fix FTCBFS: Pass triplet-prefixed CC to make (closes: #861345)
+
+  [ gregor herrmann ]
+  * Fix "Removal of obsolete debhelper compat 5 and 6 in bookworm":
+Bump to 7 in debian/compat and debian/control{,.common}.
+Remove manual handling of debian/{copyright,changelog} from debian/rules,
+handled by dh_install{docs,changelogs}.
+(Closes: #965632)
+  * Fix "missing required debian/rules targets build-arch and/or build-
+indep": Add targets to debian/rules.
+(Closes: #999263)
+
+ -- gregor herrmann   Sat, 25 Dec 2021 18:12:05 +0100
+
 libcompface (1:1.5.2-5) unstable; urgency=high
 
   * Fixed bufferoverflow when reading xbm files (closes: #534973)
diff -u libcompface-1.5.2/debian/rules libcompface-1.5.2/debian/rules
--- libcompface-1.5.2/debian/rules
+++ libcompface-1.5.2/debian/rules
@@ -4,6 +4,11 @@
 
 SHELL = /bin/bash
 
+include /usr/share/dpkg/architecture.mk
+ifeq ($(origin CC),default)
+CC := $(DEB_HOST_GNU_TYPE)-gcc
+endif
+
 package=libcompface
 
 version=1.0.0 #$(shell expr `pwd` : '.*-\([0-9.]*\)')
@@ -12,10 +17,13 @@
 LD_LIBRARY_PATH=shared:$(old_libpath)
 
 
+build-arch:	build
+build-indep:	build
+
 build:		build-libc6
 	$(checkdir)
 	@echo '### Building binaries...'
-	$(MAKE) LDFLAGS="-s -L$(CURDIR)/shared"
+	$(MAKE) LDFLAGS="-s -L$(CURDIR)/shared" 'CC=$(CC)'
 	touch build
 
 build-libc6:
@@ -30,6 +38,7 @@
 	cd shared && \
 	$(MAKE) -f ../Makefile VPATH=".." srcdir=".." \
 		LDFLAGS="-lc"\
+		'CC=$(CC)' \
 	CFLAGS="-O2 -fPIC -pipe -D_BSD_SOURCE -D_REENTRANT" shared && \
 		ln -sf $(package).so $(package).so.$(version_major) &&  \
 		ln -sf $(package).so.$(version) $(package).so #&& \
@@ -41,6 +50,7 @@
 #
 	cd static && \
 	 $(MAKE) -f ../Makefile VPATH=".." srcdir=".." \
+		  'CC=$(CC)' \
 	  CFLAGS="-O2 -pipe -D_BSD_SOURCE" LDFLAGS="-s" static #&& \
 #		  strip --strip-debug $(package).a
 
@@ -105,10 +115,7 @@
 	mv debian/tmp/usr/man debian/tmp/usr/share/
 	mv debian/tmp/usr/doc/compface debian/tmp/usr/share/doc/
 	mv debian/tmp/usr/doc/libcompfaceg1 debian/tmp/usr/share/doc/
-	cp debian/copyright debian/tmp/usr/share/doc/libcompfaceg1
 	cp debian/README.debian debian/tmp/usr/share/doc/libcompfaceg1
-	cp debian/changelog debian/tmp/usr/share/doc/libcompfaceg1/changelog.Debian
-	gzip -9 debian/tmp/usr/share/doc/libcompfaceg1/changelog.Debian
 	mv debian/tmp/usr/doc/libcompfaceg1-dev debian/tmp/usr/share/doc/
 	#gzip -9 debian/tmp/usr/share/man/man1/compface.1
 	rm debian/tmp/usr/share/man/man1/uncompface.1 
@@ -166,9 +173,6 @@
 
 	install -m644 compface.3 debian/tmp/usr/man/man3/
 	install -m644 README debian/tmp/usr/doc/compface
-	install -m644 debian/copyright debian/tmp/usr/doc/compface
-	install -m644 debian/changelog debian/tmp/usr/doc/compface/changelog.Debian
-	gzip -9 debian/tmp/usr/doc/compface/changelog.Debian
 
 	install -m644 compface.1 debian/tmp/usr/man/man1/
 	ln -s compface.1 debian/tmp/usr/man/man1/uncompface.1
@@ -211,9 +215,6 @@
 	chmod 644 debian/tmp/usr/lib/libc5-compat/$(package).so.$(version)
 
 	-mkdir debian/tmp/usr/doc/libcompface1
-	install -m644 debian/copyright debian/tmp/usr/doc/libcompface1
-	install -m644 debian/changelog 

Bug#1002528: iscan 2.30.4-2 in bookworm not displaying "Save Options" dialog

[Andrei POPESCU]

On Sb, 25 dec 21, 02:07:46, nbi wrote:
> See attachment. It most definitely exists in bookworm. Obviously someone
> packaged it for Debian.

It does exist on your system (otherwise `reportbug` wouldn't have 
included some information about it), but that still doesn't mean it is 
available from Debian:

https://packages.debian.org/search?keywords=iscan

Kind regards,
Andrei
-- 
Looking after bugs assigned to unknown or inexistent packages


signature.asc
Description: PGP signature

Bug#427623: vtwm dies on C-z

[Ian Jackson]

Control: found -1 + 5.4.7-6
Control: tags -1 + confirmed

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.

Bug#994992: libpam-ssh: pam-ssh picks the from agent socket after login with ssh -A

[Jerome BENOIT]

Hello Stephan, thanks for your report.

I guess that your issue is related to issue #995452 . I haved just merged them.


Attached patch fixes the problem by omiting `session optional pam_ssh.so`
from /etc/pam.d/sshd.


Thanks for the patch. However note that it is not applicable because 
/etc/pam.d/sshd
is actually distributed along the package `openssh-server` (you can check this 
wit apt-file(1)).

For a working (but hopefully temporary) workaround you can have a look to the 
aforementionned
bugreport.

Cheers,
Jerome


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



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1002605: `apt-get source calendar' downloads the wrong package

[Johannes Schauer Marin Rodrigues]

Quoting Stéphane Glondu (2021-12-25 13:36:48)
> `apt-get source calendar' downloads the bsdmainutils source package
> instead of calendar. I suspect this is because bsdmainutils is the
> source package of the calendar binary package.
> 
> I think `apt-get source $FOO' should try to download $FOO if $FOO
> exists as a source package, and only after fallback to downloading the
> source package of $FOO if it exists only as a binary package.

I agree and I cannot remember a single time when (in scripts or when running
apt manually) I wanted 'apt-get source' or 'apt-cache showsrc' to interpret the
package name as a binary package and not a source package. Because of that I
have

APT::Get::Only-Source "true";

in my system-wide apt config. I've never looked back.

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#828739: ssh-agent lost on nested ssh sessions

[Jerome BENOIT]

On Mon, 13 Feb 2017 13:24:28 +0100 Harald Dunkel  
wrote:
Hello Harri, sorry for my late reply.

I have just got a fresh look with bugreport #995452
< https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995452 >
in mind.

I can indeed reproduce your issue.
However I cannot see the point to nested connection.
Can you give me a practical usage ?
 


Hi Jerome,
Any news on this problem? Apparently it is still unresolved for
Stretch, even though this report was filed in time :-(.

This problem is *highly* painful if you have to work a lot on
remote sites. Currently I get less problems if I keep libpam-ssh
uninstalled, which is surely not the idea behind this package.

Would you mind to increase the severity and forward this report
to upstream?


Upstream is actually dormant.

Cheers,
Jerome




Thanx very much
Harri





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



OpenPGP_signature
Description: OpenPGP digital signature

Bug#427623: vtwm dies on C-z

[Ian Jackson]

Control: found + 5.4.7-6
Control: tags + confirmed

FTR, I have repro'd this with the latest version.  I don't intend to
investigate myself any time soon, but (as with any vtwm bug) patches
are welcome.

Thanks,
Ian.

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.

Bug#1002616: ITP: ocaml-odoc-parser -- parser for OCaml documentation comments

[Stéphane Glondu]

Package: wnpp
Severity: wishlist
Owner: Stéphane Glondu 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-ocaml-ma...@lists.debian.org

* Package name: ocaml-odoc-parser
  Version : 1.0.0
  Upstream Author : the odoc-parser programmers
* URL : https://github.com/ocaml-doc/odoc-parser
* License : ISC
  Programming Lang: OCaml
  Description : parser for OCaml documentation comments

 Odoc_parser is a library for parsing the contents of OCaml
 documentation comments, formatted using 'odoc' syntax, an extension
 of the language understood by ocamldoc.

This package is a new dependency of ocaml-odoc. It will be maintained
in the OCaml team.

Bug#995748: buster-pu: package vim/2:8.1.0875-5+deb10u1

[James McCoy]

On Sat, Dec 25, 2021 at 11:41:29AM +, Adam D. Barratt wrote:
> On Sat, 2021-12-04 at 17:36 +, Adam D. Barratt wrote:
> > Control: tags -1 + confirmed
> > 
> > On Mon, 2021-10-04 at 22:22 -0400, James McCoy wrote:
> > > Various "non DSA" CVEs have accumulated in Vim, and it seemed like
> > > a
> > > good idea to get a new upload addressing those.
> > > 
> > > [ Impact ]
> > > * CVE-2019-20807 - Shell commands can be executed from rvim
> > > (restricted
> > >   vim) via the bindings to other programming languages
> > > * CVE-2021-3770 / #994076 - Invalid memory access when a very large
> > >   number is given to :retab command
> > > * CVE-2021-3778 / #994498 - Reading beyond end of line when invalid
> > >   utf-8 character is encountered
> > > * CVE-2021-3796 / #994497 - Using freed memory in replace mode
> > > 
> > 
> > Please go ahead, thanks.
> 
> Unfortunately the builds failed everywhere with a test suite issue:

My apologies.  I uploaded with an additional patch for another issue
(#996593), which ended up not being relevant to the Buster version of
Vim.  This wasn't part of the originally proposed changes, but I had the
source packge still present locally.  I should have double checked the
changes before uploading.

Attached is a debdiff reverting that additional patch, back to what I
had originally prepared.

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

 changelog  |   
11 +
 patches/series |   
 1 
 patches/upstream/patch-8.2.3489-ml_get-error-after-search-with-range.patch |   
62 --
 3 files changed, 8 insertions(+), 66 deletions(-)

diff -Nru vim-8.1.0875/debian/changelog vim-8.1.0875/debian/changelog
--- vim-8.1.0875/debian/changelog   2021-10-19 21:56:40.0 -0400
+++ vim-8.1.0875/debian/changelog   2021-12-25 10:48:51.0 -0500
@@ -1,3 +1,10 @@
+vim (2:8.1.0875-5+deb10u2) buster; urgency=medium
+
+  * Revert unintentional inclusion of v8.2.3489, which is only relevant to Vim
+8.2.3110 and later.
+
+ -- James McCoy   Sat, 25 Dec 2021 10:48:51 -0500
+
 vim (2:8.1.0875-5+deb10u1) buster; urgency=medium
 
   * Change gbp.conf and salsa config to use buster
@@ -13,10 +20,8 @@
 + 8.2.3409: reading beyond end of line with invalid utf-8 character
   * Backport v8.2.3428 to fix CVE-2021-3796 (Closes: #994497)
 + 8.2.3428: using freed memory when replacing
-  * Backport v8.2.3489 to fix CVE-2021-3875 (Closes: #996593)
-+ 8.2.3489: ml_get error after search with range
 
- -- James McCoy   Tue, 19 Oct 2021 21:56:40 -0400
+ -- James McCoy   Sun, 26 Sep 2021 09:29:21 -0400
 
 vim (2:8.1.0875-5) unstable; urgency=medium
 
diff -Nru vim-8.1.0875/debian/patches/series vim-8.1.0875/debian/patches/series
--- vim-8.1.0875/debian/patches/series  2021-10-19 21:56:40.0 -0400
+++ vim-8.1.0875/debian/patches/series  2021-12-25 10:48:51.0 -0500
@@ -21,4 +21,3 @@
 upstream/patch-8.2.3403-memory-leak-for-retab-with-invalid-argumen.patch
 upstream/patch-8.2.3409-reading-beyond-end-of-line-with-invalid-ut.patch
 upstream/patch-8.2.3428-using-freed-memory-when-replacing.patch
-upstream/patch-8.2.3489-ml_get-error-after-search-with-range.patch
diff -Nru 
vim-8.1.0875/debian/patches/upstream/patch-8.2.3489-ml_get-error-after-search-with-range.patch
 
vim-8.1.0875/debian/patches/upstream/patch-8.2.3489-ml_get-error-after-search-with-range.patch
--- 
vim-8.1.0875/debian/patches/upstream/patch-8.2.3489-ml_get-error-after-search-with-range.patch
  2021-10-19 21:56:40.0 -0400
+++ 
vim-8.1.0875/debian/patches/upstream/patch-8.2.3489-ml_get-error-after-search-with-range.patch
  1969-12-31 19:00:00.0 -0500
@@ -1,62 +0,0 @@
-From: Bram Moolenaar 
-Date: Sat, 9 Oct 2021 13:58:55 +0100
-Subject: patch 8.2.3489: ml_get error after search with range
-
-Problem:ml_get error after search with range.
-Solution:   Limit the line number to the buffer line count.
-(cherry picked from commit 35a319b77f897744eec1155b736e9372c9c5575f)

- src/ex_docmd.c  |  6 --
- src/testdir/test_search.vim | 12 
- src/version.c   |  1 +
- 3 files changed, 17 insertions(+), 2 deletions(-)
-
-diff --git a/src/ex_docmd.c b/src/ex_docmd.c
-index ccca2f9..b550af6 100644
 a/src/ex_docmd.c
-+++ b/src/ex_docmd.c
-@@ -4589,8 +4589,10 @@ get_address(
- 
-   // When '/' or '?' follows another address, start from
-   // there.
--  if (lnum != MAXLNUM)
--  curwin->w_cursor.lnum = lnum;
-+  if (lnum > 0 && lnum != MAXLNUM)
-+  curwin->w_cursor.lnum =
-+  lnum > curbuf->b_ml.ml_line_count
-+ ? curbuf->b_ml.ml_line_count : lnum;
- 
-   // Start a forward 

Bug#1002615: toilet: diff for NMU version 0.3-1.4

[Stefano Rivera]

Package: toilet
Version: 0.3-1.3
Severity: normal
Tags: patch  pending

Dear maintainer,

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

Regards,

SR
diff -Nru toilet-0.3/debian/changelog toilet-0.3/debian/changelog
--- toilet-0.3/debian/changelog	2021-01-01 10:35:07.0 -0400
+++ toilet-0.3/debian/changelog	2021-12-25 10:30:38.0 -0400
@@ -1,3 +1,19 @@
+toilet (0.3-1.4) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Bump debhelper compat level to 13 (Closes: #965845)
+- Use minimal dh debian/rules.
+- Enables autoreconf by default (Closes: #876126)
+- Drop autotools-dev Build-Depends, no longer explicitly needed.
+  * Patch: AM_INIT_AUTOMAKE([foreign]), required to autoreconf.
+  * Declare Rules-Requires-Root: no.
+  * Remove legacy Alioth Vcs fields.
+  * Bump Standards-Version to 4.6.0, no changes needed.
+  * Remove ancient figlet conflicts, no longer needed.
+  * Add a smoketest autopkgtest.
+
+ -- Stefano Rivera   Sat, 25 Dec 2021 10:30:38 -0400
+
 toilet (0.3-1.3) unstable; urgency=medium
 
   * Non maintainer upload by the Reproducible Builds team.
@@ -9,7 +25,7 @@
 
   * Non-maintainer upload.
   * use dh_autotools-dev to update config.sub.
-  
+
   [ Helmut Grohne]
   * sets PKG_CONFIG_LIBDIR correct for cross building (Closes: #876126)
 
@@ -21,7 +37,7 @@
   * Fix FTBFS when building only architeture-independent packages
 (closes: #805961). Thanks to Santiago Vila for the bug report and the
 patch.
- 
+
  -- Jakub Wilk   Mon, 22 Aug 2016 21:05:36 +0200
 
 toilet (0.3-1) unstable; urgency=low
@@ -57,4 +73,3 @@
   * Initial release (Closes: #390037).
 
  -- Sam Hocevar (Debian packages)   Thu, 16 Nov 2006 03:32:10 +0100
-
diff -Nru toilet-0.3/debian/compat toilet-0.3/debian/compat
--- toilet-0.3/debian/compat	2010-02-08 21:34:52.0 -0400
+++ toilet-0.3/debian/compat	1969-12-31 20:00:00.0 -0400
@@ -1 +0,0 @@
-5
diff -Nru toilet-0.3/debian/control toilet-0.3/debian/control
--- toilet-0.3/debian/control	2018-03-14 00:44:09.0 -0400
+++ toilet-0.3/debian/control	2021-12-25 10:30:38.0 -0400
@@ -2,17 +2,15 @@
 Section: libs
 Priority: optional
 Maintainer: Sam Hocevar 
-Build-Depends: debhelper (>= 5.0), pkg-config, libcaca-dev (>= 0.99.beta18), zlib1g-dev, autotools-dev
-Standards-Version: 3.9.3
-XS-Vcs-Svn: svn://svn.debian.org/sam-hocevar/pkg-misc/unstable/toilet
-XS-Vcs-Browser: http://svn.debian.org/wsvn/sam-hocevar/pkg-misc/unstable/toilet/
+Build-Depends: debhelper-compat (= 13), pkg-config, libcaca-dev (>= 0.99.beta18), zlib1g-dev
+Standards-Version: 4.6.0
+Rules-Requires-Root: no
 
 Package: toilet
 Section: text
 Architecture: any
 Depends: ${shlibs:Depends}, ${misc:Depends}, toilet-fonts
 Suggests: figlet
-Conflicts: figlet (<= 2.2.1-4)
 Replaces: caca-utils
 Description: display large colourful characters in text mode
  TOIlet prints text using large characters made of smaller characters.
diff -Nru toilet-0.3/debian/patches/automake-foreign.patch toilet-0.3/debian/patches/automake-foreign.patch
--- toilet-0.3/debian/patches/automake-foreign.patch	1969-12-31 20:00:00.0 -0400
+++ toilet-0.3/debian/patches/automake-foreign.patch	2021-12-25 10:30:38.0 -0400
@@ -0,0 +1,17 @@
+Author: Stefano Rivera 
+Description: Set foreign flag for automake
+ We don't have an AUTHORS file, don't expect one.
+ Removed package name and version from AM_INIT_AUTOMAKE call, this is
+ deprecated in favour of AC_INIT.
+
+--- a/configure.ac
 b/configure.ac
+@@ -6,7 +6,7 @@
+ AC_CONFIG_AUX_DIR(.auto)
+ AC_CANONICAL_SYSTEM
+ 
+-AM_INIT_AUTOMAKE(toilet, 0.3)
++AM_INIT_AUTOMAKE([foreign])
+ AM_CONFIG_HEADER(config.h)
+ 
+ AM_PROG_CC_C_O
diff -Nru toilet-0.3/debian/patches/series toilet-0.3/debian/patches/series
--- toilet-0.3/debian/patches/series	2018-03-14 00:44:09.0 -0400
+++ toilet-0.3/debian/patches/series	2021-12-25 10:30:38.0 -0400
@@ -1 +1,2 @@
 no-set-pkg-config-libdir-to-null.patch
+automake-foreign.patch
diff -Nru toilet-0.3/debian/rules toilet-0.3/debian/rules
--- toilet-0.3/debian/rules	2018-03-14 00:32:57.0 -0400
+++ toilet-0.3/debian/rules	2021-12-25 10:30:38.0 -0400
@@ -1,91 +1,9 @@
 #!/usr/bin/make -f
 
 #export DH_VERBOSE=1
-export DEB_HOST_GNU_TYPE  ?= $(shell dpkg-architecture -qDEB_HOST_GNU_TYPE)
-export DEB_BUILD_GNU_TYPE ?= $(shell dpkg-architecture -qDEB_BUILD_GNU_TYPE)
 
-# FOR AUTOCONF 2.52 AND NEWER ONLY
-ifeq ($(DEB_BUILD_GNU_TYPE), $(DEB_HOST_GNU_TYPE))
-  confflags += --build $(DEB_HOST_GNU_TYPE)
-else
-  confflags += --build $(DEB_BUILD_GNU_TYPE) --host $(DEB_HOST_GNU_TYPE)
-endif
+%:
+	dh $@
 
-confflags += --mandir=\$${prefix}/share/man --infodir=\$${prefix}/share/info
-
-configure: configure-stamp
-configure-stamp:
-	dh_testdir
-	dh_autotools-dev_updateconfig
-	./configure $(confflags) --prefix=/usr
-	touch configure-stamp
-
-build: build-arch build-indep
-

Bug#1002614: no longer report source-is-missing for binary file in source

[Shengjing Zhu]

Package: lintian
Version: 2.111.0
Severity: important
X-Debbugs-Cc: z...@debian.org

When I packaging kata-containers, which has a binary file in orig tarball.
The I got rejected by ftp-master since they found lintian emitted
"source-is-missing" error.

However when I run lintian on testing, I didn't get such error. So this seems
a regression?

I have put the package in https://people.debian.org/~zhsj/temp/lintian-bug/
The binary file is at 
src/runtime/virtcontainers/pkg/firecracker/swagger_linux_amd64.

Bug#1002613: krita crash when loading a jpg

[Andy Valencia]

Package: krita
Version: 1:4.4.8+dfsg-1+b1
Severity: important
X-Debbugs-Cc: deb-b...@vsta.org

Dear Maintainer,

krita aborts when trying to load/display pretty much any jpg I've tried.
It starts up and displays its own menu/splash/etc but then bombs at about
the point where the actual graphic image should come up.

Have talked w. Krita devs over at KDE, and they note:

> Could you please try Krita 5.0 with this file? It looks like the problem is
> related to the openGL support on your ARM64 device.
>
> More specifically, the problem is related with how Qt is compiled. For some
> reason Qt is compiled with desktop OpenGL, not with openGLES. So Krita
> asserts about it.

(Because of deep library dependencies, I have no ability to try the
Krita version over in experimental.)


Stack backtrace:
[KCrash Handler]
#4  0xb65a4b5c in raise () from /lib/aarch64-linux-gnu/libc.so.6
#5  0xb65917cc in abort () from /lib/aarch64-linux-gnu/libc.so.6
#6  0xb69c8c84 in QMessageLogger::fatal(char const*, ...) const ()
from /lib/aarch64-linux-gnu/libQt5Core.so.5
#7  0xb7c883d4 in ?? () from
/lib/aarch64-linux-gnu/libkritaglobal.so.20
#8  0xb7c88958 in kis_assert_x_exception(char const*, char const*,
char const*, char const*, int) () from
/lib/aarch64-linux-gnu/libkritaglobal.so.20
#9  0xb907f40c in KisOpenGLImageTextures::updateTextureFormat() ()
from /lib/aarch64-linux-gnu/libkritaui.so.20
#10 0xb9081490 in KisOpenGLImageTextures::recreateImageTextureTiles()
() from /lib/aarch64-linux-gnu/libkritaui.so.20
#11 0xb9081dbc in KisOpenGLImageTextures::initGL(QOpenGLFunctions*)
() from /lib/aarch64-linux-gnu/libkritaui.so.20
#12 0xb907b3ec in KisOpenGLCanvas2::initializeGL() () from
/lib/aarch64-linux-gnu/libkritaui.so.20
#13 0xb77107fc in QOpenGLWidget::resizeEvent(QResizeEvent*) () from
/lib/aarch64-linux-gnu/libQt5Widgets.so.5
#14 0xb76f1958 in QWidget::event(QEvent*) () from
/lib/aarch64-linux-gnu/libQt5Widgets.so.5
#15 0xb76acf00 in QApplicationPrivate::notify_helper(QObject*,
QEvent*) () from /lib/aarch64-linux-gnu/libQt5Widgets.so.5
#16 0xb9213070 in KisApplication::notify(QObject*, QEvent*) () from
/lib/aarch64-linux-gnu/libkritaui.so.20
#17 0xb6bd7f40 in QCoreApplication::notifyInternal2(QObject*,
QEvent*) () from /lib/aarch64-linux-gnu/libQt5Core.so.5
#18 0xb76e9768 in
QWidgetPrivate::sendPendingMoveAndResizeEvents(bool, bool) () from
/lib/aarch64-linux-gnu/libQt5Widgets.so.5
#19 0xb76ede58 in QWidgetPrivate::show_helper() () from
/lib/aarch64-linux-gnu/libQt5Widgets.so.5
#20 0xb76eddf0 in QWidgetPrivate::showChildren(bool) () from
/lib/aarch64-linux-gnu/libQt5Widgets.so.5
#21 0xb76ede74 in QWidgetPrivate::show_helper() () from
/lib/aarch64-linux-gnu/libQt5Widgets.so.5
#22 0xb76f1150 in QWidgetPrivate::setVisible(bool) () from
/lib/aarch64-linux-gnu/libQt5Widgets.so.5
#23 0xb76edde0 in QWidgetPrivate::showChildren(bool) () from
/lib/aarch64-linux-gnu/libQt5Widgets.so.5
#24 0xb76ede74 in QWidgetPrivate::show_helper() () from
/lib/aarch64-linux-gnu/libQt5Widgets.so.5
#25 0xb76f1150 in QWidgetPrivate::setVisible(bool) () from
/lib/aarch64-linux-gnu/libQt5Widgets.so.5
#26 0xb76edde0 in QWidgetPrivate::showChildren(bool) () from
/lib/aarch64-linux-gnu/libQt5Widgets.so.5
#27 0xb76ede74 in QWidgetPrivate::show_helper() () from
/lib/aarch64-linux-gnu/libQt5Widgets.so.5
#28 0xb76f1150 in QWidgetPrivate::setVisible(bool) () from
/lib/aarch64-linux-gnu/libQt5Widgets.so.5
#29 0xb76edde0 in QWidgetPrivate::showChildren(bool) () from
/lib/aarch64-linux-gnu/libQt5Widgets.so.5
#30 0xb76ede74 in QWidgetPrivate::show_helper() () from
/lib/aarch64-linux-gnu/libQt5Widgets.so.5
#31 0xb76f1150 in QWidgetPrivate::setVisible(bool) () from
/lib/aarch64-linux-gnu/libQt5Widgets.so.5
#32 0xb7827b20 in QMdiSubWindow::changeEvent(QEvent*) () from
/lib/aarch64-linux-gnu/libQt5Widgets.so.5
#33 0xb76f1618 in QWidget::event(QEvent*) () from
/lib/aarch64-linux-gnu/libQt5Widgets.so.5
#34 0xb76acf00 in QApplicationPrivate::notify_helper(QObject*,
QEvent*) () from /lib/aarch64-linux-gnu/libQt5Widgets.so.5
#35 0xb9213070 in KisApplication::notify(QObject*, QEvent*) () from
/lib/aarch64-linux-gnu/libkritaui.so.20
#36 0xb6bd7f40 in QCoreApplication::notifyInternal2(QObject*,
QEvent*) () from /lib/aarch64-linux-gnu/libQt5Core.so.5
#37 0xb76ed524 in QWidget::setWindowState(QFlags) ()
from /lib/aarch64-linux-gnu/libQt5Widgets.so.5
#38 0xb76edb64 in QWidget::showMaximized() () from
/lib/aarch64-linux-gnu/libQt5Widgets.so.5
#39 0xb7827314 in QMdiSubWindow::eventFilter(QObject*, QEvent*) ()
from /lib/aarch64-linux-gnu/libQt5Widgets.so.5
#40 0xb6bd7c7c in
QCoreApplicationPrivate::sendThroughObjectEventFilters(QObject*, QEvent*) ()
from /lib/aarch64-linux-gnu/libQt5Core.so.5

Bug#1002564: [pkg-lxc-devel] Bug#1002564: lxc: packaging adjustments for LXD

[Evgeni Golov]

On December 25, 2021 12:35:45 PM UTC, Antonio Terceiro  
wrote:
>On Fri, Dec 24, 2021 at 06:04:04AM +, Mathias Gibbens wrote:
>> Source: lxc
>> Version: 1:4.0.10-1
>> Severity: normal
>> 
>>   Work on packaging LXD for Debian (ITP #768073) is getting pretty
>> close to completion. I've recently started testing the LXD package that
>> I am able to build locally, making sure everything is working properly
>> before it's uploaded to NEW once the few remaining dependencies make it
>> through NEW themselves.
>> 
>>   LXD depends on the liblxc1 package, but not on the lxc package
>> itself. However, there are a few files currently shipped in the lxc
>> package that LXD needs to properly start. Specifically, the apparmor
>> profiles (all of /etc/apparmor.d/, except /etc/apparmor.d/usr.bin.lxc-
>> start) and the /usr/lib/-linux-gnu/lxc/rootfs/ directory.
>> 
>>   I'm hoping we can figure out a nice way to make these dependencies of
>> LXD available without having to pull in lxc itself (plus its own
>> dependencies). The easiest way might be to just move them to liblxc1,
>> which both lxc and LXD packages will depend on. Or, there might be some
>> other solution that could work.
>
>They probably would need to be provided by a (NEW) lxc-common package.
>If we ever need to transition to liblxc2, we don't want both liblxc*
>packages providing those files.

On Ubuntu, this package us called liblxc-common, which we probably should also 
use, to make life of other consumers easier?

Bug#1002597: curl: temporarily revert adding libssh-dev to Build-Depends

[Samuel Henrique]

Hello Helmut,

I've uploaded 7.80.0-2 with a revert for this.

> So this looks mostly harmless, but involves non-trivial work and I
> didn't check build order yet. Given that curl comes relatively late, I
> don't expect much problems there.
> So can you give me a month?

Surely, please feel free to take your time, since we are not in a rush.

For reference, this issue has also been discussed at #1002598
(https://bugs.debian.org/1002598).

Thank you

-- 
Samuel Henrique 

Bug#1001935: calamaris: Calamaris stopped to recognise squid logs

[Cord Beermann]

Hallo! Du (Cord Beermann) hast geschrieben:

>will do. Currently Regressiontests are in progress.

you can get it here: https://cord.de/files/calamaris/calamaris-2.99.4.7.tar.gz

Cord

Bug#1001752: cargo-mozilla 0.47.0-3~deb10u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 1001752 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: cargo-mozilla
Version: 0.47.0-3~deb10u1

Explanation: new package, backported from Debian 11, to help build new rust 
versions

Bug#1002612: RM: es-module-loader-0.17.js -- ROM; Fixed version while upstream updates to 2.3.0

[Yadd]

Package: ftp.debian.org
Severity: normal

Hi,

this module is a fixed version of es-module-loader. Upstream version is
now 2.3.0. Its name should be es-module-loader.js, not
es-module-loader-0.17.js.
As it has no reverse dependencies, this module should be removed from
Debian archive.

Bug#1002611: ITP: r8125 -- dkms source for the r8125 network driver

[Hideki Yamane]

Package: wnpp
Severity: wishlist
Owner: Hideki Yamane 
X-Debbugs-Cc: debian-de...@lists.debian.org, henr...@debian.org, a...@debian.org

* Package name: r8125
  Version : 9.007.01
  Upstream Author : Realtek NIC software team 
* URL : 
https://www.realtek.com/en/component/zoo/category/network-interface-controllers-10-100-1000m-gigabit-ethernet-pci-express-software
* License : GPL-2 (but goes into non-free, see below)
  Programming Lang: C
  Description : dkms source for the r8125 network driver

 r8125 is the Linux 2.5G Ethernet device driver released by RealTek for their
 network controller.
 .
 This package provides the dkms source code for the r8125 kernel modules.
 Kernel source or headers are required to compile these modules.


 As same as r8168-dkms, it overwrites firmware running in microcontrollers
 on the network controllers, then goes into non-free.
 See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=777257

Bug#1002610: freeimage: Please add patch to fix FTBFS on some big-endian targets

[John Paul Adrian Glaubitz]

Control: tags +upstream

Hello!

On 12/25/21 14:05, John Paul Adrian Glaubitz wrote:
> I have created the attached patch which fixes the problem for me.

FWIW, upstream has its own version of the patch, too [1].

I would therefore suggest applying their version of the patch.

Adrian

> [1] https://sourceforge.net/p/freeimage/svn/1809/

-- 
 .''`.  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
Index: Source/FreeImage/PluginBMP.cpp
===
--- Source/FreeImage/PluginBMP.cpp	(revision 1808)
+++ Source/FreeImage/PluginBMP.cpp	(revision 1809)
@@ -518,7 +518,7 @@
 io->read_proc(FreeImage_GetPalette(dib), used_colors * sizeof(RGBQUAD), 1, handle);
 #if FREEIMAGE_COLORORDER == FREEIMAGE_COLORORDER_RGB
 RGBQUAD *pal = FreeImage_GetPalette(dib);
-for(int i = 0; i < used_colors; i++) {
+for(unsigned i = 0; i < used_colors; i++) {
 	INPLACESWAP(pal[i].rgbRed, pal[i].rgbBlue);
 }
 #endif
@@ -1419,7 +1419,7 @@
 
 			free(buffer);
 #ifdef FREEIMAGE_BIGENDIAN
-		} else if (bpp == 16) {
+		} else if (dst_bpp == 16) {
 			int padding = dst_pitch - dst_width * sizeof(WORD);
 			WORD pad = 0;
 			WORD pixel;
@@ -1440,7 +1440,7 @@
 			}
 #endif
 #if FREEIMAGE_COLORORDER == FREEIMAGE_COLORORDER_RGB
-		} else if (bpp == 24) {
+		} else if (dst_bpp == 24) {
 			int padding = dst_pitch - dst_width * sizeof(FILE_BGR);
 			DWORD pad = 0;
 			FILE_BGR bgr;
@@ -1461,7 +1461,7 @@
 	}
 }
 			}
-		} else if (bpp == 32) {
+		} else if (dst_bpp == 32) {
 			FILE_BGRA bgra;
 			for(unsigned y = 0; y < dst_height; y++) {
 BYTE *line = FreeImage_GetScanLine(dib, y);
Index: Source/FreeImage/PluginDDS.cpp
===
--- Source/FreeImage/PluginDDS.cpp	(revision 1808)
+++ Source/FreeImage/PluginDDS.cpp	(revision 1809)
@@ -356,14 +356,6 @@
 	for(int i=0; i<11; i++) {
 		SwapLong(>surfaceDesc.dwReserved1[i]);
 	}
-	SwapLong(>surfaceDesc.ddpfPixelFormat.dwSize);
-	SwapLong(>surfaceDesc.ddpfPixelFormat.dwFlags);
-	SwapLong(>surfaceDesc.ddpfPixelFormat.dwFourCC);
-	SwapLong(>surfaceDesc.ddpfPixelFormat.dwRGBBitCount);
-	SwapLong(>surfaceDesc.ddpfPixelFormat.dwRBitMask);
-	SwapLong(>surfaceDesc.ddpfPixelFormat.dwGBitMask);
-	SwapLong(>surfaceDesc.ddpfPixelFormat.dwBBitMask);
-	SwapLong(>surfaceDesc.ddpfPixelFormat.dwRGBAlphaBitMask);
 	SwapLong(>surfaceDesc.ddsCaps.dwCaps1);
 	SwapLong(>surfaceDesc.ddsCaps.dwCaps2);
 	SwapLong(>surfaceDesc.ddsCaps.dwReserved[0]);

Bug#1002598: libssh: reduce Build-Depends

[Helmut Grohne]

Hi Samuel,

On Sat, Dec 25, 2021 at 08:17:01AM -0300, Samuel Henrique wrote:
> I'm not familiar with how frequent people are doing architecture
> bootstraps on Debian, so would you like me to revert that specific
> change?

jenkins.debian.net bootstraps Debian around 10 times a day.

I asked you to (temporarily) revert the change via #1002597.

> I can surely do it with no problem, I'm asking because you already
> have a debdiff and now you might say it's ok to wait for an NMU
> (again, I don't know how grave it would be to block bootstraping in
> the meanwhile).

The libssh upload certainly is insufficient for fixing architecture
bootstrap. It is preparing libssh for being added to the bootstrap, but
that addition is a separate step. It hasn't been tested thus far, but I
don't expect much problems there.

The issue with keeping architecture bootstrap in a broken state is that
we become blind to other breakage. With some recurrence, architecture
has been broken while it was broken by something else. Figuring out the
cause of the breakage is much easier when it was in a working state
before. So the main downside of keeping it broken is me spending way
more time when something else also breaks bootstrap.

> I also don't wanna give you more work than you already have, so if you
> don't reply soon (+/-18h), I will go ahead with the revert (since this
> is the safest approach).

I'm unsure here. Martin already commited my libssh patch to git (thank
you!) and intends to upload soon. It seems to me that the long term goal
still is to switch to libssh for curl. If both is true, I prefer adding
libssh to the bootstrap sooner rather than later, because we will then
see libssh regressions wrt bootstrap (if any) via jenkins.

Helmut

Bug#1000803: dh-python: add pybuild-autopkgtest, a test runner

[Antonio Terceiro]

Control: reassign -1 dh-python
Control: retitle -1 dh-python: add pybuild-autopkgtest, a test runner
Control: severity -1 wishlist
Control: tag -1 + patch
Control: forwarded -1 
https://salsa.debian.org/python-team/tools/dh-python/-/merge_requests/27

On Mon, Dec 20, 2021 at 04:03:17PM -0300, Antonio Terceiro wrote:
> On Wed, Dec 01, 2021 at 08:19:20PM -0300, Antonio Terceiro wrote:
> > Hi,
> > 
> > Adding debian-python@l.d.o
> > 
> > The context is #1000803 where Sandro asked about reducing duplication
> > when running upstream test suites both during the build and under
> > autopkgtest.
> > 
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1000803
> > 
> > On Tue, Nov 30, 2021 at 12:47:42AM -0500, Sandro Tosi wrote:
> > > > This is usually solved outside of autopkgtest itself.
> > > >
> > > > For example Ruby packages have a single place where tests are specified
> > > > (debian/ruby-tests.*{rb,rake,yaml}, and the appropriate
> > > > debian/tests/control file is autogenerated by autodep8. I would say 99%
> > > > of Ruby packages require no duplication, or even explicitly specifying
> > > > commands to run tests at all.
> > > >
> > > > In general, this is most efficiently solved by package type (e.g.
> > > > programming language), because the way the tests are run at build-time
> > > > usually is tied to the build system. You then usually need some test
> > > > runner, probably extracted from, or provided by, the build system, to
> > > > also provide the same funcionality in an autopkgtest-compatible way.
> > > >
> > > > All the package types that are well supported in autodep8 have their
> > > > specialized test runner tools that avoid this type of duplication.
> > > 
> > > I'm mostly interested in the python ecosystem, and the provided
> > > autodep8 test are extremely superficial (essentially only importing
> > > the main python module packaged), which is better than nothing but not
> > > the same level as what's in d/rules.
> > > 
> > > Are you aware of any effort to expand the Python autodep8 tests to
> > > uniform them into a comprehensive, and unique place to run tests at
> > > build-time and via autopkgtest?
> > 
> > I'm not.
> > 
> > > If no such effort currently exists, what would one have to do to start
> > > developing it? Not necessarily volunteering, just gathering
> > > information.
> > 
> > In general terms, I see this being implemented like this:
> > 
> > 0) modify pybuild so one can call e.g. `pybuild --autopkgtest`. That
> > should work almost the same as `pybuild --test`, but would copy the test
> > files under ${AUTOPKGTEST_TMP} and run the tests from there, instead of
> > assuming a previously built tree and trying to chdir into
> > .pybuild/*/build.
> > 
> > 1) add a way of being able to specify pybuild parameters outside of
> > debian/rules that can be used both during the build and under
> > autopkgtest
> > 
> >For Ruby, gem2deb-test-runner is driven by debian/ruby-tests.*, both
> >during the build, and under autopkgtest.
> > 
> >In pybuild, some aspects of the test run can already be done this
> >way, e.g. debian/pybuild.testfiles. Maybe we could have
> >debian/pybuild.env to read options in the same way as they are set in
> >debian/rules today (with environment variables).
> > 
> > 2) update autodep8 to generate the appropriate control file to call
> >`pybuild --autopkgtest`. This needs to be "smart" enough to not
> >automatically add this call to packages that are not ready for it. At
> >the moment, almost 1000 source packages have
> >`Testsuite: autopkgtest-pkg-python`. We would probably need a new
> >value, or (probably better) to additionally check for something else
> >in the source tree.
> > 
> > Each item has quite some details to be figured out, but this is the
> > general idea.
> 
> I have written a prototype implementation of this, and published it as
> https://salsa.debian.org/python-team/tools/dh-python/-/merge_requests/27

This is now ready to be seriously considered, please take a look.


signature.asc
Description: PGP signature

Bug#1002610: freeimage: Please add patch to fix FTBFS on some big-endian targets

[John Paul Adrian Glaubitz]

Source: freeimage
Severity: normal
Tags: patch
User: debian-powe...@lists.debian.org
Usertags: powerpc ppc64
X-Debbugs-Cc: debian-powe...@lists.debian.org

Hi!

freeimage FTBFS on big-endian PowerPC systems [1][2].

I have created the attached patch which fixes the problem for me.

Could you include it in the next upload?

Thanks,
Adrian

> [1] 
> https://buildd.debian.org/status/fetch.php?pkg=freeimage=powerpc=3.18.0%2Bds2-6=1640435634=0
> [2] 
> https://buildd.debian.org/status/fetch.php?pkg=freeimage=ppc64=3.18.0%2Bds2-6=1640435569=0

--
 .''`.  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
Description: Fix FTBFS on big-endian targets
Origin: -
Author: John Paul Adrian Glaubitz 
Bug-Debian: -
Last-update: 2021-12-25
--- freeimage-3.18.0+ds2.orig/Source/FreeImage/PluginBMP.cpp
+++ freeimage-3.18.0+ds2/Source/FreeImage/PluginBMP.cpp
@@ -1419,7 +1419,7 @@ Save(FreeImageIO *io, FIBITMAP *dib, fi_
 
free(buffer);
 #ifdef FREEIMAGE_BIGENDIAN
-   } else if (bpp == 16) {
+   } else if (dst_bpp == 16) {
int padding = dst_pitch - dst_width * sizeof(WORD);
WORD pad = 0;
WORD pixel;
@@ -1440,7 +1440,7 @@ Save(FreeImageIO *io, FIBITMAP *dib, fi_
}
 #endif
 #if FREEIMAGE_COLORORDER == FREEIMAGE_COLORORDER_RGB
-   } else if (bpp == 24) {
+   } else if (dst_bpp == 24) {
int padding = dst_pitch - dst_width * sizeof(FILE_BGR);
DWORD pad = 0;
FILE_BGR bgr;
@@ -1461,7 +1461,7 @@ Save(FreeImageIO *io, FIBITMAP *dib, fi_
}
}
}
-   } else if (bpp == 32) {
+   } else if (dst_bpp == 32) {
FILE_BGRA bgra;
for(unsigned y = 0; y < dst_height; y++) {
BYTE *line = FreeImage_GetScanLine(dib, y);
--- freeimage-3.18.0+ds2.orig/Source/FreeImage/PluginDDS.cpp
+++ freeimage-3.18.0+ds2/Source/FreeImage/PluginDDS.cpp
@@ -356,14 +356,14 @@ SwapHeader(DDSHEADER *header) {
for(int i=0; i<11; i++) {
SwapLong(>surfaceDesc.dwReserved1[i]);
}
-   SwapLong(>surfaceDesc.ddpfPixelFormat.dwSize);
-   SwapLong(>surfaceDesc.ddpfPixelFormat.dwFlags);
-   SwapLong(>surfaceDesc.ddpfPixelFormat.dwFourCC);
-   SwapLong(>surfaceDesc.ddpfPixelFormat.dwRGBBitCount);
-   SwapLong(>surfaceDesc.ddpfPixelFormat.dwRBitMask);
-   SwapLong(>surfaceDesc.ddpfPixelFormat.dwGBitMask);
-   SwapLong(>surfaceDesc.ddpfPixelFormat.dwBBitMask);
-   SwapLong(>surfaceDesc.ddpfPixelFormat.dwRGBAlphaBitMask);
+   SwapLong(>surfaceDesc.ddspf.dwSize);
+   SwapLong(>surfaceDesc.ddspf.dwFlags);
+   SwapLong(>surfaceDesc.ddspf.dwFourCC);
+   SwapLong(>surfaceDesc.ddspf.dwRGBBitCount);
+   SwapLong(>surfaceDesc.ddspf.dwRBitMask);
+   SwapLong(>surfaceDesc.ddspf.dwGBitMask);
+   SwapLong(>surfaceDesc.ddspf.dwBBitMask);
+   SwapLong(>surfaceDesc.ddspf.dwRGBAlphaBitMask);
SwapLong(>surfaceDesc.ddsCaps.dwCaps1);
SwapLong(>surfaceDesc.ddsCaps.dwCaps2);
SwapLong(>surfaceDesc.ddsCaps.dwReserved[0]);

Bug#1002607: Build-Conflicts with ocaml

[Stéphane Glondu]

clone 1002607 -1 -2
reassign -1 src:llvm-toolchain-12 1:12.0.1-17
reassign -2 src:llvm-toolchain-13 1:13.0.0-9
thanks

Le 25/12/2021 à 13:49, Stéphane Glondu a écrit :
> I don't understand with llvm-toolchain-11 build-conflicts with ocaml.
> 
> With ocaml 4.13.1 (in experimental), the *-nox binary packages are
> becoming transitional, and their contents moved to
> ocaml{,-base}. Hence, llvm-toolchain-11 cannot be built in the
> universe rebuit with the new ocaml.
> 
> The build-conflicts should be dropped.

The same applies to llvm-toolchain-{12,13}.


Cheers,

-- 
Stéphane

Bug#1002607: Build-Conflicts with ocaml

[Stéphane Glondu]

Source: llvm-toolchain-11
Version: 1:11.1.0-4
Severity: important
X-Debbugs-Cc: debian-ocaml-ma...@lists.debian.org

Dear Maintainer,

I don't understand with llvm-toolchain-11 build-conflicts with ocaml.

With ocaml 4.13.1 (in experimental), the *-nox binary packages are
becoming transitional, and their contents moved to
ocaml{,-base}. Hence, llvm-toolchain-11 cannot be built in the
universe rebuit with the new ocaml.

The build-conflicts should be dropped.


Cheers,

-- 
Stéphane


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

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

Bug#1002564: lxc: packaging adjustments for LXD

[Antonio Terceiro]

On Fri, Dec 24, 2021 at 06:04:04AM +, Mathias Gibbens wrote:
> Source: lxc
> Version: 1:4.0.10-1
> Severity: normal
> 
>   Work on packaging LXD for Debian (ITP #768073) is getting pretty
> close to completion. I've recently started testing the LXD package that
> I am able to build locally, making sure everything is working properly
> before it's uploaded to NEW once the few remaining dependencies make it
> through NEW themselves.
> 
>   LXD depends on the liblxc1 package, but not on the lxc package
> itself. However, there are a few files currently shipped in the lxc
> package that LXD needs to properly start. Specifically, the apparmor
> profiles (all of /etc/apparmor.d/, except /etc/apparmor.d/usr.bin.lxc-
> start) and the /usr/lib/-linux-gnu/lxc/rootfs/ directory.
> 
>   I'm hoping we can figure out a nice way to make these dependencies of
> LXD available without having to pull in lxc itself (plus its own
> dependencies). The easiest way might be to just move them to liblxc1,
> which both lxc and LXD packages will depend on. Or, there might be some
> other solution that could work.

They probably would need to be provided by a (NEW) lxc-common package.
If we ever need to transition to liblxc2, we don't want both liblxc*
packages providing those files.


signature.asc
Description: PGP signature

Bug#1002605: `apt-get source calendar' downloads the wrong package

[Stéphane Glondu]

Package: apt
Version: 2.3.13
Severity: important

Dear Maintainer,

`apt-get source calendar' downloads the bsdmainutils source package
instead of calendar. I suspect this is because bsdmainutils is the
source package of the calendar binary package.

I think `apt-get source $FOO' should try to download $FOO if $FOO
exists as a source package, and only after fallback to downloading the
source package of $FOO if it exists only as a binary package.


Cheers,

-- 
Stéphane


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

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

Versions of packages apt depends on:
ii  adduser 3.118
ii  debian-archive-keyring  2021.1.1
ii  gpgv2.2.27-2
ii  libapt-pkg6.0   2.3.13
ii  libc6   2.33-1
ii  libgcc-s1   11.2.0-12
ii  libgnutls30 3.7.2-2
ii  libseccomp2 2.5.3-2
ii  libstdc++6  11.2.0-12
ii  libsystemd0 249.7-1

Versions of packages apt recommends:
ii  ca-certificates  20210119

Versions of packages apt suggests:
pn  apt-doc 
ii  aptitude0.8.13-3
ii  dpkg-dev1.21.1
ii  gnupg   2.2.27-2
ii  gnupg2  2.2.27-2
ii  powermgmt-base  1.36
ii  synaptic0.90.2+b1

-- no debconf information

Bug#1000200: reportbug-gtk: cannot close reportbug (on fluxbox)

[Nis Martensen]

control: reassign -1 python3.9
control: affects -1 reportbug-gtk


> Michael Hatzold hat am 19.11.2021 geschrieben:
>> When using reportbug-gtk I now cannot close it (the window) anymore, not even
>> after sending the email.  I can minimize it, but not close. I have to open a 
>> VT
>> and pkill or ctrl-C it (when opened in a VT)
>>
>> It used to work, and klicking the "x" in the title bar should close it.

Tracked this down to the commit below in python 3.9. Reverting it fixes
the problem.


94d19f606fa18a1c4d2faca1caf2f470a8ce6d46 is the first bad commit
commit 94d19f606fa18a1c4d2faca1caf2f470a8ce6d46
Author: Victor Stinner 
Date:   Mon Sep 27 23:40:22 2021 +0200

bpo-1596321: Fix threading._shutdown() for the main thread
(GH-28549) (GH-28589)

Fix the threading._shutdown() function when the threading module was
imported first from a thread different than the main thread: no
longer log an error at Python exit.

(cherry picked from commit 95d31370829b7d729667588e0a9943217401ea5b)

Bug#995748: buster-pu: package vim/2:8.1.0875-5+deb10u1

[Adam D. Barratt]

On Sat, 2021-12-04 at 17:36 +, Adam D. Barratt wrote:
> Control: tags -1 + confirmed
> 
> On Mon, 2021-10-04 at 22:22 -0400, James McCoy wrote:
> > Various "non DSA" CVEs have accumulated in Vim, and it seemed like
> > a
> > good idea to get a new upload addressing those.
> > 
> > [ Impact ]
> > * CVE-2019-20807 - Shell commands can be executed from rvim
> > (restricted
> >   vim) via the bindings to other programming languages
> > * CVE-2021-3770 / #994076 - Invalid memory access when a very large
> >   number is given to :retab command
> > * CVE-2021-3778 / #994498 - Reading beyond end of line when invalid
> >   utf-8 character is encountered
> > * CVE-2021-3796 / #994497 - Using freed memory in replace mode
> > 
> 
> Please go ahead, thanks.

Unfortunately the builds failed everywhere with a test suite issue:

>From test_search.vim:
Found errors in Test_search_with_invalid_range():
Caught exception in Test_search_with_invalid_range(): Vim:E867: (NFA) Unknown 
operator '\%.' @ /<>/src/vim-basic/testdir/Xrangesearch, line 1
TEST FAILURE

Regards,

Adam

Bug#1002537: linux-image-5.15.0-2-rt-amd64: RT kernel does not support touchpad/trackpoint on Thinkpad L15

[Michael Below]

Hi,

Am Donnerstag, dem 23.12.2021 um 22:38 +0100 schrieb Salvatore
Bonaccorso:
> Hichael, it would be great if you can test this to verify the issue
> is
> fixed:

I have tested the patch, with help from Salvatore, and the dmesg output
looks better, but the touchpad still does not work. I am attaching the
dmesg output.

Cheers
Michael



[0.00] microcode: microcode updated early to revision 0xea, date = 
2021-01-05
[0.00] Linux version 5.15.0-2-rt-amd64 (debian-ker...@lists.debian.org) 
(gcc-11 (Debian 11.2.0-13) 11.2.0, GNU ld (GNU Binutils for Debian) 2.37) #1 
SMP PREEMPT_RT Debian 5.15.5-1a~test (2021-12-24)
[0.00] Command line: BOOT_IMAGE=/vmlinuz-5.15.0-2-rt-amd64 
root=/dev/mapper/vg-root ro quiet splash
[0.00] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point 
registers'
[0.00] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
[0.00] x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers'
[0.00] x86/fpu: Supporting XSAVE feature 0x008: 'MPX bounds registers'
[0.00] x86/fpu: Supporting XSAVE feature 0x010: 'MPX CSR'
[0.00] x86/fpu: xstate_offset[2]:  576, xstate_sizes[2]:  256
[0.00] x86/fpu: xstate_offset[3]:  832, xstate_sizes[3]:   64
[0.00] x86/fpu: xstate_offset[4]:  896, xstate_sizes[4]:   64
[0.00] x86/fpu: Enabled xstate features 0x1f, context size is 960 
bytes, using 'compacted' format.
[0.00] signal: max sigframe size: 2032
[0.00] BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x0009efff] usable
[0.00] BIOS-e820: [mem 0x0009f000-0x000f] reserved
[0.00] BIOS-e820: [mem 0x0010-0x48597fff] usable
[0.00] BIOS-e820: [mem 0x48598000-0x4864] type 20
[0.00] BIOS-e820: [mem 0x4865-0x4e794fff] reserved
[0.00] BIOS-e820: [mem 0x4e795000-0x4fb1efff] ACPI NVS
[0.00] BIOS-e820: [mem 0x4fb1f000-0x4fc4efff] ACPI data
[0.00] BIOS-e820: [mem 0x4fc4f000-0x4fc4] usable
[0.00] BIOS-e820: [mem 0x4fc5-0x57ff] reserved
[0.00] BIOS-e820: [mem 0x5800-0x58df] usable
[0.00] BIOS-e820: [mem 0x58e0-0x5f7f] reserved
[0.00] BIOS-e820: [mem 0x0001-0x00049e7f] usable
[0.00] NX (Execute Disable) protection: active
[0.00] efi: EFI v2.70 by Lenovo
[0.00] efi: TPMFinalLog=0x4fb17000 SMBIOS=0x4bb9e000 SMBIOS 
3.0=0x4bb91000 ACPI=0x4fc4e000 ACPI 2.0=0x4fc4e014 MEMATTR=0x4595f018 
ESRT=0x4922e000 MOKvar=0x4595c000 
[0.00] secureboot: Secure boot could not be determined (mode 0)
[0.00] SMBIOS 3.2.0 present.
[0.00] DMI: LENOVO 20R3CTO1WW/20R3CTO1WW, BIOS R15ET50W (1.31 ) 
06/17/2021
[0.00] tsc: Detected 2300.000 MHz processor
[0.00] tsc: Detected 2299.968 MHz TSC
[0.12] e820: update [mem 0x-0x0fff] usable ==> reserved
[0.15] e820: remove [mem 0x000a-0x000f] usable
[0.23] last_pfn = 0x49e800 max_arch_pfn = 0x4
[0.000211] x86/PAT: Configuration [0-7]: WB  WC  UC- UC  WB  WP  UC- WT  
[0.001104] last_pfn = 0x58e00 max_arch_pfn = 0x4
[0.013621] Using GB pages for direct mapping
[0.014136] RAMDISK: [mem 0x30879000-0x34433fff]
[0.014143] ACPI: Early table checksum verification disabled
[0.014146] ACPI: RSDP 0x4FC4E014 24 (v02 LENOVO)
[0.014152] ACPI: XSDT 0x4FC4C188 00010C (v01 LENOVO TP-R15   
1310 PTEC 0002)
[0.014159] ACPI: FACP 0x4BA4B000 000114 (v06 LENOVO TP-R15   
1310 PTEC 0002)
[0.014165] ACPI: DSDT 0x4BA1F000 027DF4 (v02 LENOVO CML  
20170001 INTL 20160422)
[0.014169] ACPI: FACS 0x4F982000 40
[0.014172] ACPI: SSDT 0x4BAA2000 002016 (v02 LENOVO CpuSsdt  
3000 INTL 20160527)
[0.014176] ACPI: SSDT 0x4BAA1000 0005A1 (v02 LENOVO CtdpB
1000 INTL 20160527)
[0.014180] ACPI: SSDT 0x4BA66000 003969 (v02 LENOVO DptfTabl 
1000 INTL 20160527)
[0.014183] ACPI: SSDT 0x4BA5 00331E (v02 LENOVO SaSsdt   
3000 INTL 20160527)
[0.014187] ACPI: SSDT 0x4BA4F000 00060E (v02 LENOVO Tpm2Tabl 
1000 INTL 20160527)
[0.014190] ACPI: TPM2 0x4BA4E000 34 (v04 LENOVO TP-R15   
1310 PTEC 0002)
[0.014194] ACPI: SSDT 0x4BA4C000 0005D8 (v02 LENOVO PerfTune 
1000 INTL 20160527)
[0.014197] ACPI: HPET 0x4BA4A000 38 (v01 LENOVO TP-R15   
1310 PTEC 0002)
[0.014201] ACPI: APIC 0x4BA49000 000164 (v03 LENOVO TP-R15   
1310 PTEC 0002)
[0.014204] ACPI: MCFG 0x4BA48000 3C (v01 LENOVO TP-R15   
1310 PTEC 0002)
[0.014208] ACPI: ECDT 0x4BA47000 55 (v01 LENOVO 

Bug#1002598: libssh: reduce Build-Depends

[Martin Pitt]

Control: tag -1 pending

Hello Helmut,

Helmut Grohne [2021-12-25  9:31 +0100]:
> +  * Reduce Build-Depends for architecture bootstrap. (Closes: #-1)

Thank you, much appreciated! I pushed the changes [1], as two separate
commits. I'll still do some maintenance updates (lintian looks pretty sad), and
do an upload ASAP.

Happy holidays,

Pitti

[1] https://salsa.debian.org/debian/libssh/-/commits/debian

Bug#1002604: RFS: tapecalc/20211222-2 [ITA] [RC] -- full-screen tape editor that lets the user edit a calculation

[Victor Westerhuis]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: tapecalc
   Version : 20211222-2
   Upstream Author : Thomas E. Dickey 
 * URL : https://invisible-island.net/add/add.html
 * License : dickey
 * Vcs : https://salsa.debian.org/viccie30/tapecalc
   Section : math

It builds those binary packages:

  tapecalc - full-screen tape editor that lets the user edit a calculation

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/t/tapecalc/tapecalc_20211222-2.dsc

Changes since the last upload:

 tapecalc (20211222-2) unstable; urgency=medium
 .
   * Actually set myself as maintainer

There is already an open ITA bug at #747967 in which Thomas Dickey, the
upstream maintainer also declared his intent to adopt this package.
I have had private e-mail contact with Thomas Dickey and he does not mind
if I maintain this package in Debian.

This upload would fix all 3 of src:tapecalc's open bugs, one of which is
RC.

Regards,


Victor Westerhuis


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1002603: /usr/bin/gitdiff: missing man pages for gitdiff and gitdiffview

[David Bremner]

Package: patchutils
Version: 0.4.2-1
Severity: normal
File: /usr/bin/gitdiff

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Per subject, gitdiff and gitdiffview should have man pages.


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

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

Versions of packages patchutils depends on:
ii  libc6   2.33-1
ii  patch   2.7.6-7
ii  perl5.32.1-6
ii  sensible-utils  0.0.17

patchutils recommends no packages.

patchutils suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEkiyHYXwaY0SiY6fqA0U5G1WqFSEFAmHHAHUACgkQA0U5G1Wq
FSGkVRAAkAGzdXZtiO+H/ndcC27CVR7uoE49yQ+8OU/uj45Jkw2/Z5TZr7gFI8Bb
ypvAIoVkVelG5la3ulTSrC3HqOKWlRS8R+THGCOw6AnB8i3kUVglPGObEzK4lF3G
oRtrgBdL2NprdsFjlJ4nwlEej24FoyMND+ACRTQr248c2CwPC00RATJHoLO5njs7
te2iCxLbcofPipjrS2RwWMuIsvUq0KYFaP0puBRx6RAFbJpOfYnqAEJJkxJKCupO
c/7G+zljJktFH7kSauIBOXhmZDqA7rkPq2ZABtoH+Hp2sG62RrT2thZHo74I1oLa
zLXx72j7HlvxvIvUSIT8R5p0s1dCX1yVkxOrue3GZqHWEy4SN1D1tuzdY/0/qs2o
LDzaLnwM7Q5eaDy8yDVfaEwJ2ByG6flTN/zoaMaGFpiXozh0ewJBpZl/UL9zGM5W
+DympIbaQmykqDGW1oDmKYhmKsb85DTuGy6jB5+0s+yTEDvCpenEOJflUkGDYFoi
gVfYsKEoahL3ZE9oNaDw8Hg+0NBXsCwy9tYbuGhAA+EewSpT5vhgo5xG/KASVz4o
BQ1oZRgVC4xklTMqkNz0tL9GT1Nr5usUxaimCfuSno3PVlzutDxeRE0XXK93dyx3
l1qif+kOS9P57V7xQHKKvr9C6FfYc7jSKcEbXMBs+MUSFOlIi00=
=av2H
-END PGP SIGNATURE-

Bug#1002598: libssh: reduce Build-Depends

[Samuel Henrique]

Hello Helmut,

> curl is transitioning from libssh2 to libssh.
> Since curl is required for
> architecture bootstrap, so will be libssh. That's significant, because
> you must be careful about your Build-Depends and avoid introducing
> cycles.

Ouch, that wasn't intended at all. There are currently no plans of
migrating to libssh.

We recently merged a commit[0] that would allow Ubuntu to remove its
delta due to the fact that they migrated to libssh already,

The changes don't affect Debian's curl binaries, since libssh is not
used in Debian's build. Though I didn't realise having it in
Build-Depends would pose a problem to bootstrap (which makes sense).

> Speaking of Build-Depends, libssh has some that are
> inappropriate for architecture bootstrap and needs to be updated. There
> are two aspects. For one thing, Build-Depends of packages involved in
> architecture bootstrap must be real. No virtual packages are allowed,
> because provides are computed at build-time and we have no way of
> figuring out which source package is going to build a binary package
> that provides a particular virtual package. This affects the libz-dev
> dependency. I suggest updating it to zlib1g-dev | libz-dev (i.e. telling
> the preferred provider). This leaves the full flexibility and avoids the
> issue with virtual packages. The other is excessive dependencies for
> testing. I figured that all of libcmocka-dev, openssh-client,
> openssh-server and python3:any are only required for running tests. As
> such, they can all be annotated . Any dependency thus
> annotated becomes fully irrelevant to architecture bootstrap. In other
> words, you don't have to keep this bootstrap stuff in mind when you add
> test dependencies annotated with . I'm attaching a patch for
> your convenience and hope it is going to be fine.

All of these changes sound like something we should do at some point
in time anyway, but we can surely revert the curl changes to allow
people to enjoy their holidays/end of the year.

> Given that the curl
> maintainers already added the libssh-dev dependency without consulting
> it first, there is urgency. Architecture bootstrap is presently broken
> for all architectures due to that change. Please upload the change
> quickly. If you lack the time to do it, I can NMU it.

I'm sorry you had to do this, Helmut, and I appreciate your descriptiveness.
I'm not familiar with how frequent people are doing architecture
bootstraps on Debian, so would you like me to revert that specific
change?
I can surely do it with no problem, I'm asking because you already
have a debdiff and now you might say it's ok to wait for an NMU
(again, I don't know how grave it would be to block bootstraping in
the meanwhile).

I also don't wanna give you more work than you already have, so if you
don't reply soon (+/-18h), I will go ahead with the revert (since this
is the safest approach).

[0] https://salsa.debian.org/debian/curl/-/merge_requests/12

Thank you,


--
Samuel Henrique 

Bug#1002602: gdb: Dwarf Error: wrong unit_type in compilation unit header (is DW_UT_split_compile (0x05), should be DW_UT_type (0x02))

[Nicholas Guriev]

Package: gdb
Version: 10.1-2
Tags: patch
Forwarded: https://sourceware.org/bugzilla/show_bug.cgi?id=27354

Dear Maintainer,

GDB 10.1 is unable to debug binaries produced by GCC 11.2.0 with the
-gsplit-dwarf switch. GCC 11, which is now in Debian sid, uses DWARFv5
debugging format by default. With -gdwarf-4 the error does not appear.


builder@barberry:/tmp/tmp.qHMJOXsPej$ cat hello.c 
#include 

int main()
{
  puts("Hello everybody!");
  return 0;
}
builder@barberry:/tmp/tmp.qHMJOXsPej$ gcc -g -gsplit-dwarf -c hello.c
builder@barberry:/tmp/tmp.qHMJOXsPej$ gcc hello.o -o hello
builder@barberry:/tmp/tmp.qHMJOXsPej$ gdb -silent hello
Reading symbols from hello...
Dwarf Error: wrong unit_type in compilation unit header (is DW_UT_split_compile 
(0x05), should be DW_UT_type (0x02)) [in module /tmp/tmp.qHMJOXsPej/hello.dwo]
(No debugging symbols found in hello)
(gdb) q


The attached patch against GDB in unstable seems to be fixing the issue.

diffstat for gdb-10.1 gdb-10.1

 changelog |6 ++
 patches/Fix-wrong-unit_type-Dwarf-Error.patch |   11 +++
 patches/series|1 +
 3 files changed, 18 insertions(+)

diff -Nru gdb-10.1/debian/changelog gdb-10.1/debian/changelog
--- gdb-10.1/debian/changelog   2021-03-04 21:37:19.0 +0300
+++ gdb-10.1/debian/changelog   2021-12-25 10:45:33.0 +0300
@@ -1,3 +1,9 @@
+gdb (10.1-2local1) unstable; urgency=medium
+
+  * Build for internal use.
+
+ -- Nicholas Guriev   Sat, 25 Dec 2021 10:45:33 +0300
+
 gdb (10.1-2) unstable; urgency=high
 
   * Acknowledge past contributions from Matthias and Samuel.
diff -Nru gdb-10.1/debian/patches/Fix-wrong-unit_type-Dwarf-Error.patch 
gdb-10.1/debian/patches/Fix-wrong-unit_type-Dwarf-Error.patch
--- gdb-10.1/debian/patches/Fix-wrong-unit_type-Dwarf-Error.patch   
1970-01-01 03:00:00.0 +0300
+++ gdb-10.1/debian/patches/Fix-wrong-unit_type-Dwarf-Error.patch   
2021-12-25 10:42:54.0 +0300
@@ -0,0 +1,11 @@
+--- a/gdb/dwarf2/read.c
 b/gdb/dwarf2/read.c
+@@ -12943,7 +12943,7 @@ open_and_init_dwo_file (dwarf2_cu *cu, c
+ {
+   create_debug_type_hash_table (per_objfile, dwo_file.get (),
+   _file->sections.info, dwo_file->tus,
+-  rcuh_kind::TYPE);
++  rcuh_kind::COMPILE);
+ }
+ 
+   if (dwarf_read_debug)
diff -Nru gdb-10.1/debian/patches/series gdb-10.1/debian/patches/series
--- gdb-10.1/debian/patches/series  2021-03-04 21:21:03.0 +0300
+++ gdb-10.1/debian/patches/series  2021-12-25 10:40:05.0 +0300
@@ -11,3 +11,4 @@
 2bf3b79d05bf85e41cbdcb020bd1cc424f59dd9a.diff
 fork-inferior-fix
 vm_min_max_address
+Fix-wrong-unit_type-Dwarf-Error.patch


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

Bug#998827: openorienteering-mapper: diff for NMU version 0.9.5-2.1

[dg0yt]

With regard to the changelog, I would like to point out that the test failure 
is probably not related to missing test data (or GDAL), but to a behavioral 
change in PROJ 8.2.0. References:
https://github.com/OpenOrienteering/mapper/issues/2008
https://github.com/OSGeo/PROJ/commit/85f496b26702bf6566296072795e821d70156c09
In this regard, the now-disabled test fulfilled its purpose of catching changed 
behavior in the environment.

Kai

> Adrian Bunk  hat am 25.12.2021 10:46 geschrieben:
> 
>  
> Control: tags 998827 + patch
> Control: tags 998827 + pending
> 
> Dear maintainer,
> 
> I've prepared an NMU for openorienteering-mapper (versioned as 0.9.5-2.1)
> and uploaded it to DELAYED/14. Please feel free to tell me if I should cancel 
> it.
> 
> cu
> Adrian

Bug#998827: openorienteering-mapper: diff for NMU version 0.9.5-2.1

[Adrian Bunk]

Control: tags 998827 + patch
Control: tags 998827 + pending

Dear maintainer,

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

cu
Adrian
diff -Nru openorienteering-mapper-0.9.5/debian/changelog openorienteering-mapper-0.9.5/debian/changelog
--- openorienteering-mapper-0.9.5/debian/changelog	2021-10-24 11:00:58.0 +0300
+++ openorienteering-mapper-0.9.5/debian/changelog	2021-12-25 11:15:31.0 +0200
@@ -1,3 +1,11 @@
+openorienteering-mapper (0.9.5-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Disable the template_t tests due to data not being in Debian.
+(Closes: #998827)
+
+ -- Adrian Bunk   Sat, 25 Dec 2021 11:15:31 +0200
+
 openorienteering-mapper (0.9.5-2) unstable; urgency=medium
 
   [ Bas Couwenberg ]
diff -Nru openorienteering-mapper-0.9.5/debian/patches/no-template_t.patch openorienteering-mapper-0.9.5/debian/patches/no-template_t.patch
--- openorienteering-mapper-0.9.5/debian/patches/no-template_t.patch	1970-01-01 02:00:00.0 +0200
+++ openorienteering-mapper-0.9.5/debian/patches/no-template_t.patch	2021-12-25 11:15:31.0 +0200
@@ -0,0 +1,15 @@
+Description: Disable the template_t tests due to data not being in Debian
+Author: Adrian Bunk 
+Bug-Debian: https://bugs.debian.org/998827
+
+--- openorienteering-mapper-0.9.5.orig/test/CMakeLists.txt
 openorienteering-mapper-0.9.5/test/CMakeLists.txt
+@@ -199,7 +199,7 @@ add_system_test(style_t)
+ target_link_libraries(style_t  PRIVATE scaling-icon-engine)
+ add_system_test(symbol_set_t)
+ add_system_test(symbol_t)
+-add_system_test(template_t)
++#add_system_test(template_t)
+ add_system_test(tools_t)
+ add_system_test(track_t)  # Could be unit test, but needs Georeferencing
+ add_system_test(transform_t)
diff -Nru openorienteering-mapper-0.9.5/debian/patches/series openorienteering-mapper-0.9.5/debian/patches/series
--- openorienteering-mapper-0.9.5/debian/patches/series	2021-10-24 10:26:33.0 +0300
+++ openorienteering-mapper-0.9.5/debian/patches/series	2021-12-25 11:15:31.0 +0200
@@ -1,2 +1,3 @@
 fix-help-data-dir.patch
 proj8.patch
+no-template_t.patch

Bug#1002600: firefox-esr: 91.4.1 unable to open any web (SSE2 again)

[Ondrej Zary]

Package: firefox-esr
Version: 91.4.1esr-1~deb11u1
Severity: important
File: /usr/bin/firefox
X-Debbugs-Cc: t...@security.debian.org

Dear Maintainer,
after upgrading firefox-esr from 78.15.0esr-1 to 91.4.1esr-1, it can't open
any web page. The tab crashes immediately, with errors like this in dmesg:
traps: Web Content[2691] trap invalid opcode ip:ad209c0d sp:bf87369c error:0 in 
libxul.so[ac17e000+5844000]

This is a P3 CPU so I guess that SSE2 instructions sneaked in again and this
CPU cannot handle them:
$ cat /proc/cpuinfo
processor   : 0
vendor_id   : GenuineIntel
cpu family  : 6
model   : 11
model name  : Intel(R) Celeron(TM) CPU1100MHz
stepping: 1
microcode   : 0x1c
cpu MHz : 1364.963
cache size  : 256 KB
physical id : 0
siblings: 1
core id : 0
cpu cores   : 1
apicid  : 0
initial apicid  : 0
fdiv_bug: no
f00f_bug: no
coma_bug: no
fpu : yes
fpu_exception   : yes
cpuid level : 2
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov 
pse36 mmx fxsr sse cpuid
bugs: cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds 
swapgs itlb_multihit
bogomips: 2729.92
clflush size: 32
cache_alignment : 32
address sizes   : 36 bits physical, 32 bits virtual
power management:

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

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

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


-- Package-specific info:

-- Extensions information
Name: Amazon.com
Location: /usr/lib/firefox-esr/browser/omni.ja
Package: firefox-esr
Status: enabled

Name: Bing
Location: /usr/lib/firefox-esr/browser/omni.ja
Package: firefox-esr
Status: enabled

Name: Dark theme
Location: /usr/lib/firefox-esr/browser/omni.ja
Package: firefox-esr
Status: user-disabled

Name: DoH Roll-Out
Location: /usr/lib/firefox-esr/browser/features/doh-roll...@mozilla.org.xpi
Package: firefox-esr
Status: enabled

Name: DuckDuckGo
Location: /usr/lib/firefox-esr/browser/omni.ja
Package: firefox-esr
Status: enabled

Name: Firefox Alpenglow theme
Location: /usr/lib/firefox-esr/browser/omni.ja
Package: firefox-esr
Status: user-disabled

Name: Firefox Screenshots
Location: /usr/lib/firefox-esr/browser/features/screensh...@mozilla.org.xpi
Package: firefox-esr
Status: enabled

Name: Form Autofill
Location: /usr/lib/firefox-esr/browser/features/formautof...@mozilla.org.xpi
Package: firefox-esr
Status: enabled

Name: Google
Location: /usr/lib/firefox-esr/browser/omni.ja
Package: firefox-esr
Status: enabled

Name: Light theme
Location: /usr/lib/firefox-esr/browser/omni.ja
Package: firefox-esr
Status: user-disabled

Name: Picture-In-Picture
Location: /usr/lib/firefox-esr/browser/features/pictureinpict...@mozilla.org.xpi
Package: firefox-esr
Status: enabled

Name: Proxy Failover
Location: 
/home/rainbow/.mozilla/firefox/7e8psv5p.default/features/{037a4322-a290-423b-8727-7d7e3091e40c}/proxy-failo...@mozilla.com.xpi
Status: enabled

Name: System theme theme
Location: /usr/lib/firefox-esr/omni.ja
Package: firefox-esr
Status: enabled

Name: Web Compatibility Interventions
Location: /usr/lib/firefox-esr/browser/features/webcom...@mozilla.org.xpi
Package: firefox-esr
Status: enabled

Name: WebCompat Reporter
Location: 
/usr/lib/firefox-esr/browser/features/webcompat-repor...@mozilla.org.xpi
Package: firefox-esr
Status: user-disabled

Name: Wikipedia (en)
Location: /usr/lib/firefox-esr/browser/omni.ja
Package: firefox-esr
Status: enabled


-- Addons package information
ii  firefox-esr91.4.1esr-1~deb11u1 i386 Mozilla Firefox web browser 
- Extended Support Release (ESR)

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

Kernel: Linux 5.10.0-10-686 (SMP w/1 CPU thread)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages firefox-esr depends on:
ii  debianutils  4.11.2
ii  fontconfig   2.13.1-4.2
ii  libatk1.0-0  2.36.0-2
ii  libc62.31-13+deb11u2
ii  libcairo-gobject21.16.0-5
ii  libcairo21.16.0-5
ii  libdbus-1-3  1.12.20-2
ii  libdbus-glib-1-2 0.110-6
ii  libevent-2.1-7   2.1.12-stable-1
ii  libffi7  3.3-6
ii  libfontconfig1   2.13.1-4.2
ii  libfreetype6 2.10.4+dfsg-1
ii  libgcc-s110.2.1-6
ii  libgdk-pixbuf-2.0-0  2.42.2+dfsg-1
ii  libglib2.0-0 2.66.8-1
ii  libgtk-3-0   3.24.24-4
ii  libpango-1.0-0   1.46.2-3
ii  libstdc++6 

Bug#1002599: ITP: binlex -- a genetic binary trait lexer

[Jan Gru]

Package: wnpp
Severity: wishlist
Owner: Jan Gru 
X-Debbugs-Cc: debian-de...@lists.debian.org, 
debian-security-to...@lists.debian.org

* Package name: binlex
  Version : 1.1.0
  Upstream Author : @c3rb3ru5d3d53c
* URL : https://github.com/c3rb3ru5d3d53c/binlex
* License : The Unlicense
  Programming Lang: C++
  Description : a genetic binary trait lexer utility

Extract basic blocks and functions as traits from binaries for malware
research, hunting and detection. Use cases range from (automated)
YARA signature generation, identification of code reuse, creation of
a good- or malware trait corpus, genetic programming and ML-based
malware detection.

* Relevance of the package
Creating detection signatures or finding code reuse and code
similarity are important steps for understanding malware threats and
defending networks. Binlex helps to simplify and automate these tasks
by providing a C++-library and a utility program to extract binary
traits from binaries.

* Maintenance Plan
I suggest to maintain binlex inside the pkg-security-team's
repository on salsa, since most of the packages related to
security and forensics live there. I am looking for a sponsor
for this package -- ideally a member of the pkg-security-team.

Bug#1000739: [Pkg-javascript-devel] Bug#1000739: Missing parts of upstream

[Yadd]

On 25/12/2021 09:00, Yadd wrote:

On 24/12/2021 22:48, Julien Puydt wrote:

Hi,

Le vendredi 24 décembre 2021 à 19:00 +0100, Yadd a écrit :


you were wrong in your fix: you wanted
mdn-browser-compat-data/html/global_attributes.json which is provided
by mdn-browser-compat-data module (not packaged).

The new @mdn/browser-compat-data provides just one data.json. I think
we should revert your change and you should patch your package to use
@mdn/browser-compat-data/data.json#global_attribute instead of
mdn-browser-compat-data/html/global_attributes.json


Why are you claiming this module isn't packaged... in a bug report
about its packaging?


Try `npm i @mdn/browser-compat-data`, you'll see that I'm right


Its debian/install file didn't list much, so I completed it, and it
gave the other package I worked on what it wanted, just like it wanted,
no patch necessary -- so I fail to see what's wrong here.


This files are source files, build produces the npm package in built/ 
directory



I just had a look, and uscan says there's a new 4.1.2 version out,
where I see html/global_attributes.json is still there.


Yes, it's a source file, upstream does not integrate it in published 
package because it's a duplication.


Here is the patch to apply to old packages:

< foo = require("mdn-browser-compat-data/html/global_attributes.json")
 > foo = require("@mdn/browser-compat-data/data.json").global_attributes


Fix:

  < foo = require("mdn-browser-compat-data/html/global_attributes.json")
  > foo = require("@mdn/browser-compat-data/data.json")
  >   .html.global_attributes


Are we looking at the same thing? I have:

$ git remote -v
origin  https://salsa.debian.org/js-team/node-mdn-browser-compat-data
(fetch)
origin  https://salsa.debian.org/js-team/node-mdn-browser-compat-data
(push)


Like @rollup/plugin-xxx. "@" and "/" are not allowed in Debian package 
name. So we have to drop them. Look at package.json#name. This package 
is @mdn/browser-compat-data, not mdn-browser-compat-data


Cheers,
Yadd