Bug#977629: Processed: Clone to libbpfcc

[Vincent Bernat]

 ❦ 18 décembre 2020 22:38 +0530, Ritesh Raj Sarraf:

> Thank you Vincent for the fix. It is committed to the repository and
> will be uploaded soon.

Thanks, it fixes the issue with bpftrace!
-- 
Whenever you find that you are on the side of the majority, it is time
to reform.
-- Mark Twain

Bug#716927: grub-efi-amd64: grub-efi doesn't support HFS+ EFI partitions

[Dara Poon]

This has been fixed upstream since commit b8765fa0 (2013-12-17)
https://git.savannah.gnu.org/cgit/grub.git/commit/?id=b8765fa0824aab891a28b728f9b7309cbe5c6ba2

Excerpt from util/grub-install.c:

  efidir_is_mac = 0;

  if (grub_strcmp (fs->name, "hfs") == 0
  || grub_strcmp (fs->name, "hfsplus") == 0)
efidir_is_mac = 1;

  if (!efidir_is_mac && grub_strcmp (fs->name, "fat") != 0)
grub_util_error (_("%s doesn't look like an EFI partition"), efidir);

(Prior to that, in commit cd46aa6c (2013-11-16), the grub-install shell script 
was reimplemented altogether in C.)

Bug#887060: testing migration happened despite FTBFS on arch:all buildd

[Paul Gevers]

Hi all,

On Thu, 15 Nov 2018 20:49:43 +0100 Paul Gevers  wrote:
> I think I have found the cause for this issue. Apparently some arch:all
> binary packages are not listed in both the binary-/Packages.* and
> binary-all/Packages.* file groups, but ONLY in the binary-all/Packages.*
> files (at least on unstable). The britney log tells me that the
> binary-all files are not read in yet.
> 
> Currently the source package bzr is in this position (and I noticed
> because autopkgtest fails on non-installability of the arch:all
> packages), which enabled me to figure this out.

Today (noted on IRC), pcb-rnd was in the same position. Luckily the
migration didn't happen because the second phase blocked the migration
(pcb-rnd (the binary) depends on pcb-rnd-doc).

pcb-rnd-doc is in binary-all/Packages.* but not in binary-/Packages.*.

The situation will be gone soon, pcb-rnd build on arch:all several
minutes ago.

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#976427: closed by Debian FTP Masters (reply to se...@debian.org (Steinar H. Gunderson)) (Bug#976427: fixed in plocate 1.1.3-1)

[GSR]

Hi,
ow...@bugs.debian.org (2020-12-19 at 0051.03 +):
>* Make debian/cron.daily/plocate executable. (Closes: #976427)

A freshly installed package will have it executable. If previously
installed from any of the buggy versions, the non-executable mode is
kept. No idea if that needs extra actions (eg, force executable if
upgrading from those versions) or not. Maybe worth consulting with
other packagers, or something already covered in the packaging
policies.

Cheers,
GSR
 

Bug#968626: gitlab: Error 500 during CI artifacts upload from gitlab-runner

[devel]

Hello Maximilian,

many, many thanks for debugging this issue further and for sharing your
workaround!
It works for me, too.


On Sat, 19 Dec 2020 19:04:40 +0100 Maximilian Stein  wrote:
> So, right now, I do have a workaround, although I don't where the
> problem is exactly (i.e., in gitlab or in etag) nor how it should be
> fixed.

Yes, it seems to be unclear, whether the problem originates in gitlab or in
rake.
I just opened an issue for rake, asking this question:
 https://github.com/rack/rack/issues/1725

Cheers,
Lars

Bug#977747: nis: reproducible builds: Embeds BASH value in /usr/lib/yp/pwupdate

[Vagrant Cascadian]

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

The shell used for the #! in /usr/lib/yp/pwupdate depends upon the
running user's shell.

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

  #!/bin/bash
  vs.
  #!/bin/sh


The attached patch fixes this by passing BASH=/bin/bash to the
appropriate configure script.


live well,
  vagrant
From eaf81058ec8a715b4b162f115c13315118ad970d Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Sun, 20 Dec 2020 03:55:40 +
Subject: [PATCH 2/2] debian/rules: Pass BASH=/bin/bash to the ypserv configure
 script.

In ypserv-2.19/configure, the BASH variable gets set to /bin/sh if
unset. This leads to reproducibility issues in the
/usr/lib/yp/pwupdate command which uses the value of BASH for the #!
line.
---
 debian/rules | 1 +
 1 file changed, 1 insertion(+)

diff --git a/debian/rules b/debian/rules
index 4c74d96..59dd4d4 100755
--- a/debian/rules
+++ b/debian/rules
@@ -53,6 +53,7 @@ build:
 	rm -f $(YPSERV)/sedscript
 	-(cd $(YPSERV) && [ ! -f config.status ] && \
 		AWK=/usr/bin/awk CFLAGS=$(CFLAGS) ./configure \
+		BASH=/bin/bash \
 		--prefix=/usr --mandir=/usr/share/man \
 		--sysconfdir=/etc \
 		--libexecdir=/usr/lib/yp --enable-checkroot \
-- 
2.20.1



signature.asc
Description: PGP signature

Bug#882584: openboard 1.5.4+dfsg1-1 on Debian 10.7 build success

[肖盛文]

I tested that the newest git version 1.5.4+dfsg1-1 also build success on
Debian 10.7 and work normal.

But has one minor bug:

The desktop icon don't display in the menu.

Is that need to add the following line to
debian/openboard-common.install or debian/openboard.install?


usr/share/icons/


Thanks!

在 2020/12/18 下午11:15, Mike Gabriel 写道:
> Hi,
>
> I am close to pushing many updates to Salsa for OpenBoard, targetting
> Debian 11. The to-be-pushed changes will likely break building
> OpenBoard 1.5.4 (not 1.5.3, as we have there now) on Debian buster.
>
> I'll try to make a backport happen once the official upload of
> OpenBoard has landed in Debian testing (upcoming 11).
>
> Mike

-- 
肖盛文 xiao sheng wen Faris Xiao 
微信(wechat)：atzlinux
《铜豌豆 Linux》 
基于 Debian 的 Linux 中文桌面操作系统：https://www.atzlinux.com
Debian QA page: https://qa.debian.org/developer.php?login=atzlinux%40sina.com
GnuPG Public Key: 0x339240CB




OpenPGP_signature
Description: OpenPGP digital signature

Bug#977743: packages.debian.org: "list of files" fails on sid/testing arch:all packages - not processing Contents-all.gz ?

[Rebecca N. Palmer]

Package: www.debian.org

On the packages.d.o pages of arch:all packages from sid, bullseye or 
experimental, the "list of files" link gives the error message "No such 
package in this suite on this architecture."


This does not affect arch:any packages, or packages from stable.

e.g.
fails - https://packages.debian.org/sid/all/python3-pandas/filelist
OK - https://packages.debian.org/buster/all/python3-pandas/filelist
OK - https://packages.debian.org/sid/amd64/python3-pandas-lib/filelist

Possible cause: these suites have a separate Contents-all.gz file, but 
https://salsa.debian.org/webmaster-team/packages/-/blob/master/bin/parse-contents#L178 
appears to assume there isn't and try to use 
Contents-${last_arch_checked}.gz.

Bug#776938: sendfile: please make the build reproducible

[Vagrant Cascadian]

On 2020-09-12, Chris Lamb wrote:
> Chris Lamb wrote:
>
>> [..]
>
> Friendly ping on this?

I think sendfile is now under the QA team, so anyone could do an upload
to fix the issue. I'd be happy to do so, unless you would rather upload
your own patch?


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#977473: Would you mind updating insighttoolkit4

[Steven Robbins]

On Tuesday, December 15, 2020 11:10:32 A.M. CST Andreas Tille wrote:
> Hi again,
> 
> sorry, I intended to respond to bug #977473 as well which really should
> be dealt with,

I had a look and can reproduce the build error.  
(in fact my local build had more than just the one failure)

But this is a failure in in a test of the python wrapping of GDCM that passed 
the previous build -- with unmodified ITK sources/  I lack the time and 
motivation to debug this kind of issue.

Sorry, but I will pass on this.
-Steve


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

Bug#977717: podman: Images can't be run with non-root USER after upgrade to 2.1.1 due to wrong permissions of / inside the container

[adamo]

Hi Reinhard,


I was intending to open a bug report after contacting you earlier but someone 
appears to have beaten me to it!


I'm still able to reproduce this on my end with the following.

---
root@podman:~# podman run docker.io/alpine /bin/echo "Hello"
Hello
root@podman:~# adduser --uid 1010 bugtest --gecos "" --no-create-home 
--disabled-login --disabled-password
Adding user `bugtest' ...
Adding new group `bugtest' (1010) ...
Adding new user `bugtest' (1010) with group `bugtest' ...
Not creating home directory `/home/bugtest'.
root@podman:~# podman run --user 1010 docker.io/alpine /bin/echo "Hello"
Error: container_linux.go:370: starting container process caused: apply caps: 
operation not permitted: OCI runtime permission denied error
---

This is a fresh image I've pulled and still occurs when running as the user 
'nobody' as per your example.

I've also tried the steps taken in your example (with an additional step to run 
the container) and managed to reproduce the error.

-
root@podman:~# cat Dockerfile
FROM docker.io/debian
USER nobody
RUN id
root@podman:~# podman rm -a
root@podman:~# podman build -f Dockerfile
STEP 1: FROM docker.io/debian
Getting image source signatures
Copying blob 6c33745f49b4 done
Copying config 6d6b00c222 done
Writing manifest to image destination
Storing signatures
STEP 2: USER nobody
--> de292136a39
STEP 3: RUN id
uid=65534(nobody) gid=65534(nogroup) groups=65534(nogroup)
STEP 4: COMMIT
--> b08e47fc955
b08e47fc955ccfe7a3c164e9fbd2068758ee145e39ffcc1a5c95d4a53ad4144d
root@podman:~# podman run 
b08e47fc955ccfe7a3c164e9fbd2068758ee145e39ffcc1a5c95d4a53ad4144d /bin/echo 
"Hello"
Error: container_linux.go:370: starting container process caused: apply caps: 
operation not permitted: OCI runtime permission denied error
-

While I don't think it's relevant, I've had this issue with both a VM on Linode 
(which I've upgraded from Debian 10 to bullseye) and on a local VM which was 
created directly from a "testing" iso.

--
root@podman:~# cat /etc/os-release
PRETTY_NAME="Debian GNU/Linux bullseye/sid"
NAME="Debian GNU/Linux"
ID=debian
HOME_URL="https://www.debian.org/;
SUPPORT_URL="https://www.debian.org/support;
BUG_REPORT_URL="https://bugs.debian.org/;
--

As mentioned, this appears to have been discussed in the issue 
https://github.com/containers/podman/issues/7747 on Github.

If you need any more information from my end, please let me know.

Thanks for your help with this.

Regards,
Adam.

Bug#976738: libintl.jar is not installed in /usr/share/maven-repo

[Santiago Vila]

On Sat, Dec 19, 2020 at 06:51:38PM -0500, Louis-Philippe Véronneau wrote:
> Here is an updated patch, using maven-repo-helper to do all the heavy
> lifting, as typically done for java libraries :)

Thanks a lot, I will take a look.

> Please note that to build with the package you pointed me to, in a clean
> schroot, I had to add "groff" to the Build-Depends.
> 
> Maybe that was fixed before you uploaded to Debian? Otherwise I fear you
> might get a FTBFS from the buildd.

Yes, I know. Sorry, forgot to tell. I've fixed that in 0.21-2.

Unfortunately I got another FTBFS on all powerpc flavours, including
ppc64el which is a release architecture, so I'm going to study your
patch in the meantime while the help arrives.

(I already asked for help to Bruno Haible, the current upstream
maintainer, but maybe I have to ask the Debian porters as well)

Thanks.

Bug#976738: libintl.jar is not installed in /usr/share/maven-repo

[Louis-Philippe Véronneau]

Here is an updated patch, using maven-repo-helper to do all the heavy
lifting, as typically done for java libraries :)

Please note that to build with the package you pointed me to, in a clean
schroot, I had to add "groff" to the Build-Depends.

Maybe that was fixed before you uploaded to Debian? Otherwise I fear you
might get a FTBFS from the buildd.

On 2020-12-19 17 h 32, Santiago Vila wrote:
>> Would it be possible to also install it in /usr/share/maven-repo? The
>> jar not being present there makes it very hard for me to use gettex in
>> Clojure packages that build using leiningen, as it only looks at
>> /usr/share/maven-repo.
> 
> This is a little bit strange. I guess the file is in /usr/share/java
> because Debian Policy says so. Has Policy changed lately?
> 
> Why would it need to be somewhere else?
> Alternatively: Why would we need to have it in two places at the same time?
> 
> Could it be that some package (not gettext) is not following policy?>
> I have read the maven url that you provided, but still do not
> fully understand this.
> 
>> I know other tools like Gradle also expect artifacts to be installed there.
> 
> Same question for those.
It's not really a question of policy, more of tooling. The Java world
uses a lot of different tools, and some of them only look at files in
/usr/share/maven-repo.

Leiningen, the build tool for Clojure packages, while not strictly
speaking a Java tool (Clojure runs on the JVM, but isn't Java), does
that too. I cannot tell leiningen "here are some jar files, please build
using those", as it requires them to be in a maven repository that
respects the proper hierarchy.

For example, since the complete namespace for libintl.jar is
org.gnu.gettext.libintl, it will look for the jar file in
$MAVEN_REPO/org/gnu/gettext/libintl/$VERSION/libintl-$VERSION.jar.

If you look at libraries in the Java Team [1][2][3][4][5], most of them
will publish jars both in /usr/share/java/ and in /usr/share/maven-repo,
to accommodate the needs of the various tools in the ecosystem.

> Could we have those questions answered before writing any patches,
> please? Before applying a patch, I'd like to be sure that it's the
> right thing to do, which in this case I'm not sure yet.
> 
> In either case, I prefer that the files are symlinks to the real files,
> (not copies) and also prefer that it's not versioned, since we are
> never going to provide more than one version at a time. If you absolutely
> need the version, we can parse debian/changelog for that or use some
> debhelper variable if it does exist (I bet this will not be the first
> package needing to know its own version number).

The version thing is needed, as that's part of the maven repository
specification. Often upstream specifies a precise version to use during
build, as typically jars are just fetched online at mvnrepository.com
during build.

Since that's not the way we do thing in Debian, most packages also
provide a generic version that symlinks to the right one, in this case
the "debian" version. This means we don't have to change anything when a
new version of a dependency is uploaded, as the "debian" version always
points to the right one.

In the case of the patch I made, that's all taken care of by
maven-repo-helper, which reads debian/gettext-base.poms to know what to do.

The "--java-lib" option in there tells it to also install the jar in
/usr/share/java/, so it's not needed in the debian/gettext-base.install
file anymore. I did it this way, since it prevents the jar from being
installed twice (everything is symlinked instead).

Sadly, I had to write the debian/libintl.pom.xml file by hand. I think
this often happens in Java (I'm not part of the Java Team), but in
Clojure we have a tool that takes care of generating them for us
dynamically.

Maybe you could ask upstream to publish a pom file? That way we could
reuse it instead and not have to update the version number manually for
new versions. I guess I could write some glue in d/rules to fetch the
current version and replace it in debian/libintl.pom.xml using sed, but
that feels icky.

Happy to answer more questions if needed.

[1]: libbcpkix-java
[2]: libini4j-java
[3]: libicu4j-java
[4]: libjackson2-core-java
[5]: libhttpcore-java

-- 
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
  ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
  ⠈⠳⣄
diff --git a/debian/control b/debian/control
index a940de9..ed29ec6 100644
--- a/debian/control
+++ b/debian/control
@@ -3,7 +3,7 @@ Section: devel
 Priority: optional
 Maintainer: Santiago Vila 
 Standards-Version: 4.5.0
-Build-Depends: debhelper-compat (= 13), dh-exec (>= 0.13), dh-elpa, g++ (>= 4:7), bison, file, help2man, xz-utils, default-jdk , fastjar , libglib2.0-dev, libncurses5-dev, libunistring-dev, libxml2-dev
+Build-Depends: debhelper-compat (= 13), dh-exec (>= 0.13), dh-elpa, g++ (>= 4:7), bison, file, help2man, xz-utils, default-jdk , maven-repo-helper , fastjar , libglib2.0-dev, libncurses5-dev, libunistring-dev, 

Bug#977746: mirror submission for mirrors.nju.edu.cn

[Ge Yao]

Package: mirrors
Severity: wishlist
User: mirr...@packages.debian.org
Usertags: mirror-submission

Submission-Type: new
Site: mirrors.nju.edu.cn
Type: leaf
Archive-architecture: ALL amd64 arm64 armel armhf hurd-i386 i386 kfreebsd-amd64 
kfreebsd-i386 mips mips64el mipsel powerpc ppc64el s390x
Archive-http: /debian/
Archive-rsync: debian/
Maintainer: Ge Yao 
Country: CN China
Location: Nanjing
Sponsor: eScience Center https://sci.nju.edu.cn




Trace Url: http://mirrors.nju.edu.cn/debian/project/trace/
Trace Url: http://mirrors.nju.edu.cn/debian/project/trace/ftp-master.debian.org
Trace Url: http://mirrors.nju.edu.cn/debian/project/trace/mirrors.nju.edu.cn

Bug#977745: pkg-js-tools: documentation talks about dh_auto_configuration (should be dh_auto_configure)

[Jonas Smedegaard]

Package: pkg-js-tools
Version: 0.9.58
Severity: minor

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

README.md says there is a hook for dh_auto_configuration.
The correct name for that build target is dh_auto_configure.

 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAl/eiSEACgkQLHwxRsGg
ASGDkA//UjCrkpUGRuRsLyQLEWtbQtVDAhEWP6pWX5CgcUoFDhQ2BWAvjATKd4hD
gWr2JAPnmCJStyzeZLOBt98urx9l9/7IzQfr9f0PY6nmtNfnloLJlHDNw6fmgARQ
FjLo6YhjpSHWQhiffWLqWC4l1XibwtexJxV7BxUvSqA+6sUFj8maaJlw9UcNoze9
Te5X+U/5XkkPfOJexRbMthv9sfaqLwybJsGJh+gbPP6WIf9arqpGYAugzdtKfZDl
agcHoLsgxRUB5yfnxUv4tHJgAvml/aAbE9a0tmw7S5ly5Opx8qHA3WcNZyHcF9FN
YPYIRn4Clqm3GwEKpoNXXqTIBtTxXrnLkmGxa4bpBOTHOVsS59nozsW9tiUWQEUQ
xlzpdvi+Zwwe5ClYGjBWuXNGraoesSgNMKNl+SV/8+GhthTntrXeiMjsMznpb3fr
vv1u5oVQ/v0083otzeYXN4QhPPTet2+HADciPQXWxRt/Y6/pGLnfXpfV9a4lzu95
OxSwbTunhGvqafBv+31XTJHRQDxF0w69LoQCMEgFMSofISvHh4pjy49qlte65rK1
MihOfz4dbisKy/+nOG+9LO/4I74UyFZXp24PNHW6gmoNiXGWfa/gkBmhJKh4WIFY
t3QmbxMHyYBqordRJYSqU32Yzwj7evUNBNvZTRDU+f0/ooshX9w=
=CnI0
-END PGP SIGNATURE-

Bug#977744: pkg-js-tools: debian/nodejs/extlinks parsing should be strict

[Jonas Smedegaard]

Package: pkg-js-tools
Version: 0.9.58
Severity: important

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

pkg-js-tools documents that debian/nodejs/extlinks "lists installed node
modules that should be linked into `node_modules` directory.

But apparently it silently skips entries not installed.

That is problematic, because it might lead to silently building
differently than intended, or lead to build failures difficult to debug.

I cannot see a good reason for parsing of debian/nodejs/extlinks to be
relaxed - seems to me that it should be strict - i.e. fail if it fails
to locate an entry at either /usr/share or /usr/lib (in that order).

On a related note, I think documentation should explicitly mention that
it will link from either /usr/share or /usr/lib in that order - because
that is what it does, right?  I am just blindly assuming that, which is
bad...


 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAl/ehSUACgkQLHwxRsGg
ASFeTg//b8tfvE1l6BljPK0dUXrrdGHUcH0K0XSR6WikstyTpliZ2NupenufuOmM
0rSok22PZb1WN2TfJaHdISCUQGB/g6z9Kqsdj0/yaDGc9QTQiHykNyPv4CwSO3Gu
IhLGxn50fX3JewV32qZkXxRSCbjjWaewUMRK3bKVh+flkrEuzaosIjQbsrTTTvVg
sABDKAznWvK3LJApkB0GUtp5KqggRU29i5BKD+wMiqSoZpaGY4crnqJarjPc9sUy
ZFQs47eQqJQid+cIqU8tvbXMYVQ3RiKVucNodn9MXjQT4VpKQeQ7yyNlJBCcMZRA
b9ep1AAo1Dvy6fi7lQk2aZRg99C2ZQI4e8Nz6FHTFTGe7p7JMSzFt64OWgWdBrEr
JzTo5i20ogyN1CKo5C5NVRS2vlZZ9YxLWGOhJar1993tvg+VRWG+OVJbHrYNuCl9
lexPpK5VrzxGs26QeC05Eolr65sLbZBbiu3pCRRlThZ2E4jVXGgbAxDKTXuATfvC
WNealbwzEz7JtWW0f+Ua5TsRvSEO5+Vw3niXDsdk2rsNLd5J3RyYDZULpRTHj107
Ck6RS0DzbrBkFFFu+VVkERu+UcuHZm5NuwJQPDEknqEDBsibyL5o0T3rf+arQUpw
9xedYPQ5gXONNDmcPAJ0IrFNFdkYN7N3Rsr0Xweupa6Ytj/aS+o=
=LJzw
-END PGP SIGNATURE-

Bug#976738: libintl.jar is not installed in /usr/share/maven-repo

[Santiago Vila]

On Mon, 7 Dec 2020, Louis-Philippe Véronneau wrote:

> Package: src:gettex
> Version:
> Severity: normal
> 
> Dear maintainer,
> 
> At the moment, gettex produces libintl.jar and installs it in
> /usr/share/java.
> 
> Would it be possible to also install it in /usr/share/maven-repo? The
> jar not being present there makes it very hard for me to use gettex in
> Clojure packages that build using leiningen, as it only looks at
> /usr/share/maven-repo.

This is a little bit strange. I guess the file is in /usr/share/java
because Debian Policy says so. Has Policy changed lately?

Why would it need to be somewhere else?
Alternatively: Why would we need to have it in two places at the same time?

Could it be that some package (not gettext) is not following policy?

I have read the maven url that you provided, but still do not
fully understand this.

> I know other tools like Gradle also expect artifacts to be installed there.

Same question for those.

Could we have those questions answered before writing any patches,
please? Before applying a patch, I'd like to be sure that it's the
right thing to do, which in this case I'm not sure yet.

In either case, I prefer that the files are symlinks to the real files,
(not copies) and also prefer that it's not versioned, since we are
never going to provide more than one version at a time. If you absolutely
need the version, we can parse debian/changelog for that or use some
debhelper variable if it does exist (I bet this will not be the first
package needing to know its own version number).

Thanks.

Bug#971216: doxygen build error

[Sven Mueller]

Control: tags -1 patch

Hi once more.

@Paolo: There is a question for you:
Could you imagine (no pun intended) to include the change in the
imagemagick version of the dh_doxygen script into the version in the
doxygen package, possibly behind an option? It replaces known (currently
only jquery) .js files by a symlink to the relevant known location of the
(here:) jquery file and creates a substvar with the required
dependency/dependencies.
This would eventually eliminate the need to keep a script in the
imagemagick sources in sync with the doxygen package.
The replacement is desirable from a security standpoint, as it reduces the
places that need patching if another jquery vulnerability surfaces.

I attached two things to this email: The full updated dh_doxygen script as
it would need to be in the imagemagick package (compatible with both older
and newer doxygen versions) and the patch to the one currently in the
imagemagick package.

Below are my findings from my investigation:

So: Looking at the imagemagick-6-doc package, replacing the full
debian/scripts/dh_doxygen call (including all parameters) with _just_
"/usr/bin/dh_doxygen" (without any parameters) causes the following
differences in the imagemagick-6-doc package:

(+ from the contents for the newly built package, - for the original
package currently in the Debian archive):

--rw-r--r-- root/root 2020-07-27 03:13
./usr/share/doc/imagemagick-6-common/html/www/api/MagickCore/doxygen.png
+-rw-r--r-- root/root 2020-07-27 03:13
./usr/share/doc/imagemagick-6-common/html/www/api/MagickCore/doxygen.svg
The above seems correct.

-lrwxrwxrwx root/root 2020-07-27 03:13
./usr/share/doc/imagemagick-6-common/html/www/api/MagickCore/jquery.js ->
../../../../../../javascript/jquery/jquery.js
+-rw-r--r-- root/root 2020-07-27 03:13
./usr/share/doc/imagemagick-6-common/html/www/api/MagickCore/jquery.js
-lrwxrwxrwx root/root 2020-07-27 03:13
./usr/share/doc/imagemagick-6-common/html/www/api/MagickWand/doxygen.png ->
../MagickCore/doxygen.png
+lrwxrwxrwx root/root 2020-07-27 03:13
./usr/share/doc/imagemagick-6-common/html/www/api/MagickWand/doxygen.svg ->
../MagickCore/doxygen.svg
-lrwxrwxrwx root/root 2020-07-27 03:13
./usr/share/doc/imagemagick-6-common/html/www/api/MagickWand/jquery.js ->
../../../../../../javascript/jquery/jquery.js
+lrwxrwxrwx root/root 2020-07-27 03:13
./usr/share/doc/imagemagick-6-common/html/www/api/MagickWand/jquery.js ->
../MagickCore/jquery.js

There is a problem though: The original dh_doxygen script in the
imagemagick source replaces .js files with appropriate symlinks and
generates some substvars. Maybe this is functionality that should get added
to the original dh_doxygen script? CC'ing Paolo for this, see intro.

Cheers,
Sven

Attached is a patch to the included dh_doxygen
Description: Remove custom dh_doxygen (broken with newer doxygen)
 Once upon a time, the custom script was useful, but this is not the time.
Author: Sven Mueller https://bugs.debian.org/971216
Last-Update: 2020-12-19
---
This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
Index: imagemagick-6.9.11.24+dfsg/debian/scripts/dh_doxygen
===
--- imagemagick-6.9.11.24+dfsg.orig/debian/scripts/dh_doxygen
+++ imagemagick-6.9.11.24+dfsg/debian/scripts/dh_doxygen
@@ -90,7 +90,7 @@ sub looks_like_doxygen_doc($)
 {
 my ($path) = @_;
 return 0 unless -f "$path/doxygen.css";
-return 0 unless -f "$path/doxygen.png";
+return 0 unless ( -f "$path/doxygen.png" || -f "$path/doxygen.svg" );
 return 0 unless -f "$path/index.html";
 return 1;
 }


dh_doxygen
Description: Binary data

Bug#927971: tomcat9: split policy files and libexec scripts so that pki-server can use them

[Timo Aaltonen]

On 16.12.2020 17.21, Emmanuel Bourg wrote:

Le 16/12/2020 à 15:26, Timo Aaltonen a écrit :


Ping, any objection to moving policy files and the update script to
-common? I can do that either directly or via a merge request.


I wonder if this is really necessary. The policy files are used to limit
the privileges of the web applications hosted by Tomcat when the
security manager is enabled. This is convenient when the applications
aren't fully trusted. But in the pki-server case there is no trust issue
and the security manager could be disabled. The sandboxing could be
implemented at the systemd level if necessary.

Emmanuel Bourg



Hmm, it's possible I don't have the full picture of using the security 
manager with dogtag (which Redhat does). I'll fix that after the holidays :)



--
t

Bug#977742: Build-Depends-Indep: dh-sequence-nodejs is unsupported

[Jonas Smedegaard]

Package: pkg-js-tools
Version: 0.9.58
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

debhelper supports limiting a sequence to arch-independent packages, but
when trying to do that with dh-sequence leads to this error message:

dh: warning: The add-on nodejs relies on a feature (add_command_options) 
(possibly indirectly), which is not supported for conditional debhelper 
sequence add-ons.
dh: warning: Hint: You may have to move the build-dependency for 
dh-sequence-nodejs to Build-Depends to avoid this error assuming it is possible 
to use the sequence unconditionally.
dh: error: unable to load addon nodejs: dh: error: add_command_options is not 
supported for conditional dh sequence add-ons.

 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAl/efS4ACgkQLHwxRsGg
ASHhPxAAoCbzQTx1XAbP1BMJWjvYsWPMXbg3LqsOtuy92z7vKNhToVI3kFfCB+1l
0i14mPII0qB8ydeKepcfzAx5dT7+/1eF97+evvQHuROSsA4e5jRRKkr2T5JVSyA7
TTRNfVdStehJ45LMPYQ0mGXwt7lfPOH03Cefrx4h6b/V6cwrOOzWf9RBVwfGDmNl
MjoKusyPwBm1hJnFXa4sVee7YfPH+DT8l4vC+mIceQnDXunYP8uqSz8jBiD/q93D
Dgmr8wgZnQrE06QkqQ8M/sYYifyKHnD7FYVfDiYfqhnH7NWWjwvZ9AgHbW9OqCSR
vhdKNFwR43c4+zjF1kyWwenJ6A89EbYSPTwCV7NN8dZ0hrmB4wZ52Aiy+3f+2Tsj
Nhk0x3S0OM/dIJQmaJMZuVnbxELhXnMIMV4HxI0Bn0za1TFxkexV71R5sUa2Rprl
SZ/hWLhMJwudK677U3RAYCqvhywyVl5nJq8aTlershpXIps4+XVy9OymhLUKbm6n
R+NY5syx7gQfZ9W4j/ihTWOCcJtNjs7VImhMTdBUjNVGmr6RXgidqhX+y+y8Rtfv
tYJH/ZTLFK8P8fIsPYacqAfayHh4IdNy9hnwVgGNW0LjnuXE5AxFa/OcEBc5jVvu
sZYrA/gBWKUKygxs3XHJXqPPZJTpso/jtcUIVyK6uu/wPI3Rtm4=
=WSqn
-END PGP SIGNATURE-

Bug#977741: ITP: pastel -- bring colors to your terminal

[Emmanuel Arias]

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

* Package name: pastel
  Version : 0.2.1
  Upstream Author : Sébastien Eustace 
* URL : https://github.com/sdispater/pastel
* License : MIT
  Programming Lang: Python
  Description :  bring colors to your terminal

Pastel is a simple library to help you colorize strings in your terminal.
.
This is a dependency of clickit.
.
This package is needed for poetry packaging.
.
This package will be maintained as part of the Debian Python modules team.

Cheers,
Emmanuel

Bug#977527: freedombox FTBFS: test_homepage_mapping_skip_ci failure

[Sunil Mohan Adapa]

tag 977527 + pending
thanks



OpenPGP_signature
Description: OpenPGP digital signature

Bug#976738: libintl.jar is not installed in /usr/share/maven-repo

[Louis-Philippe Véronneau]

On 2020-12-19 16 h 25, Santiago Vila wrote:
> Dear Louis-Philippe:
> 
> Sorry for the late reply and thanks a lot for the patch.
> 
> I have just uploaded gettext 0.21 which I had almost-ready, based on
> the work by Zack Weinberg. You can get the packages from this URL:
> 
> https://people.debian.org/~sanvila/gettext/
> 
> Would be possible for you to rebase the patches you sent for this bug
> for version 0.21? That would make everything a lot easier.
> 
> I would then upload it as version 0.21-2 (maybe with no changes at all).
> 
> Thanks.
> 

Oh wow, dh sequencing! That'll make it much easier to fix this bug :)

I'll send a new patch very soon.

-- 
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
  ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
  ⠈⠳⣄



OpenPGP_signature
Description: OpenPGP digital signature

Bug#971216: doxygen build error

[Sven Mueller]

Hi there.

I believe this error is solely caused by embedding dh_doxygen into the
imagemagick source package instead of using the dh_doxygen helper from the
doxygen package.

I tried a build with the debian/scripts/dh_doxygen call in debian/rules
replaced by /usr/bin/dh_doxygen and it succeeded.

Cheers,
Sven

Bug#977727: initramfs-tools: Panic mode does not support manual mounting

[Matthias Urlichs]

Package: initramfs-tools
Version: 0.139
Severity: important

Consider this sequence:

* I boot with root=LABEL=foo1 or root=UUID=[long]
* However I mistyped the UUID, or misapplied the label, or the root disk
  had to be replaced, or the rotofs is broken and I need to boot the
  rescue root
* I get dropped into the initramfs panic shell
* I mount the rootfs to /root manually

However, the current boot loop insists on finding the volume that   
  
corresponds to the original root= argument. There appears to be no way to  
override that.

What should happen: when /root is a mountpoint and /root/$INIT exists
(please check using "chroot test -e …" as /root/sbin/init might be an   
absolute symlink), assume success.

Yes it should be possible to modify the kernel command line and reboot
instead, but sometimes it is not.

Bug#976738: libintl.jar is not installed in /usr/share/maven-repo

[Santiago Vila]

Dear Louis-Philippe:

Sorry for the late reply and thanks a lot for the patch.

I have just uploaded gettext 0.21 which I had almost-ready, based on
the work by Zack Weinberg. You can get the packages from this URL:

https://people.debian.org/~sanvila/gettext/

Would be possible for you to rebase the patches you sent for this bug
for version 0.21? That would make everything a lot easier.

I would then upload it as version 0.21-2 (maybe with no changes at all).

Thanks.

Bug#977740: ITP: paho.mqtt.cpp -- Eclipse Paho MQTT C++ client library

[Matthias Klein]

Package: wnpp
Severity: wishlist
Owner: Matthias Klein 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: paho.mqtt.cpp
  Version : 1.2
  Upstream Author : Eclipse Paho Development Team 
* URL : https://github.com/eclipse/paho.mqtt.cpp
* License : EPL-1.0 Programming
  Programming Lang: C++
  Description : Eclipse Paho MQTT C++ client library

  This library enables C++11 applications to connect to an MQTT
  broker, publish messages to the broker, and to subscribe to topics
  and receive published messages.

  This library requires the Paho C library which is already packaged
  in debian: https://packages.debian.org/sid/libpaho-mqtt1.3

-BEGIN PGP SIGNATURE-

iQJNBAEBCgA3FiEEjC6qGcnd04OdZq2u/7AEG+75lvAFAl/eb70ZHG1hdHRoaWFz
LmtsZWluQGxpbnV4LmNvbQAKCRD/sAQb7vmW8Mz9D/wLhKKwevWHv8J927+xjqiE
9KbcoxoChjSTF6A3kjaypm/ZsnU9VlLJsamc44o4ZVupsJALocHoGu6vyY0YbNox
bqH5nK20zBCxQNQ0FMhjG8EJjg2Dbrdwfn2QHAaMx6UmykBo+Ue2E4qNFY5RDMoy
BSB3sA3EmzDA6JnAt0g0W9A29Lv075manybVEc87Lt7DTNQYPFuxAdyr4ocnATrX
o5eVyDtjx+8kgnBOd4bB+XrnaYHAGwMkj2HJsdmt1+VLSPfcOujL0nWIpQitPsNw
NO72OyT3ptUyx5AbPuhONmcMjSaSN2UuFptHdOyjI8KprqN1mdbK8AsfGeog2PGb
Xtjrdaj4WLIcD8/tdqfGdAuw8i9lsLo+UUGOizjHeb3mxg4hM1rFcP7d2GIJTv1u
lGR6VMwyHOcTevwc3iuHYmPz51DDZMM52HBS2g7D2zAdkkU4+lrpVizFtNRV5g6G
SzX0bzLCtxts6vqmrPtfaia9b12Iq4ly6SPZG/ICZJj8nQwzaXV2KPJU8Ua/rUWQ
yvb0pBu5kHySv8a3+gpxdlrccSpPlP1CQvEf9pmPFe2MbZkyB546ELgA9NvUDD81
+BYDy4nNiUbP8Kdsg5XHGjpJvNew3+QtINP6eKLT8M+xj2aUJAIDGUG320VP4BEP
vc5wkGJWHQL4CqjLuBCbaw==
=Y7lK
-END PGP SIGNATURE-

Bug#977739: ITP: golang-github-texttheater-golang-levenshtein -- An implementation of the Levenshtein algorithm in Go. Provides edit distances and edit scripts.

[Richard Lough]

Package: wnpp
Severity: wishlist
Owner: Richard Lough 

* Package name: golang-github-texttheater-golang-levenshtein
  Version : 1.0.1-1
  Upstream Author : Kilian Evang
* URL : https://github.com/texttheater/golang-levenshtein
* License : Expat
  Programming Lang: Go
  Description : An implementation of the Levenshtein algorithm in Go. 
Provides edit distances and edit scripts.

 golang-levenshtein An implementation of the Levenshtein
 algorithm in Go. Provides edit distances, edit scripts and
 ratios for strings (slices of runes).  Installation$ go
 get github.com/texttheater/golang-levenshtein/levenshtein
 Documentation The documentation can be viewed online here:
 https://godoc.org/github.com/texttheater/golang-levenshtein/levenshtein
 See also For a package that is similar but more generic and
 provides more control, check out Daniël de Kok’s editdistance
 (https://github.com/danieldk/editdistance).

TODO: perhaps reasoning

Bug#906161: python-debianbts: get_bugs doesn't marshal usertags properly

[Bastian Venthur]

Hi Julien,

thanks for the reply. Regarding your original bugreport, the usertags 
parameter seems not to be documented in the wiki: 
https://wiki.debian.org/DebbugsSoapInterface


Since it seems to work anyways for you, do you mind closing the 
bugreport now? I was closing it, because I didn't receive an answer from 
you for two years.



Cheers,

Bastian




Am 19.12.20 um 11:57 schrieb Julien Cristau:

I think it must have been something like this:

ut = debianbts.get_usertag('release.debian@packages.debian.org')
debianbts.get_bugs(package='release.debian.org', tag=['pu', 'buster'],
usertags=ut)

https://salsa.debian.org/debbugs-team/debbugs/-/blob/master/lib/Debbugs/Bugs.pm#L117
describes the usertags param for get_bugs.

I get:

SoapFault: soap:Client: Application failed during request deserialization:
not well-formed (invalid token) at line 5, column 304, byte 544 at 
/usr/lib/x86_64-linux-gnu/perl5/5.28/XML/Parser/Expat.pm line 487.
XML::Parser::Expat::parse(XML::Parser::Expat=HASH(0x55d36e3b48e8), "
Hi Julien,

can you please provide a call to reproduce the error? According to the
docs, the get_bugs has no `usertags` parameter:

   https://wiki.debian.org/DebbugsSoapInterface


Cheers,

Bastian


On Wed, 15 Aug 2018 09:57:42 +0200 Julien Cristau 
wrote:

Package: python-debianbts
Version: 2.7.2
Severity: normal
Tags: patch

Hi,

marshaling for get_bugs' "usertags" param doesn't seem to work properly.
There's some special casing with _build_int_array_el for lists and
tuples but not for dicts.  The below seems to make it work.

Cheers,
Julien

diff --git a/debianbts/debianbts.py b/debianbts/debianbts.py
index d638e26..8816b7a 100644
--- a/debianbts/debianbts.py
+++ b/debianbts/debianbts.py
@@ -405,6 +405,13 @@ def get_bugs(*key_value):
  arg_name = 'arg' + str(arg_n)
  if isinstance(kv, (list, tuple)):
  _build_int_array_el(arg_name, method_el, kv)
+elif isinstance(kv, dict):
+el = method_el.add_child(arg_name)
+for k, v in kv.items():
+if isinstance(v, (list, tuple)):
+_build_int_array_el(k, el, v)
+else:
+el.marshall(k, v)
  else:
  method_el.marshall(arg_name, kv)
  





--
Dr. Bastian Venthur  http://venthur.de
Debian Developer venthur at debian org




--
Dr. Bastian Venthur https://venthur.de
Debian Developer venthur at debian org

Bug#957037: biboumi: ftbfs with GCC-10

[Michel Le Bihan]

Hello,

I updated the sources the same way you did and made a new release.
Could you please check if everything is fine and sponsor my NMU?
https://salsa.debian.org/mimi8/biboumi

Michel Le Bihan

On Thu, 17 Dec 2020 15:18:46 +0100 Jonas Smedegaard  wrote:
> Quoting Michel Le Bihan (2020-12-17 14:37:38)
> > > @Michel: If you are interested in joining the VoIP team generally, 
> > > then please join the mailinglist and request membership to the Salsa 
> > > group - links are at https://wiki.debian.org/Teams/VoIP
> > 
> > Sorry, but I'm not really interested in VoIP software nor have much 
> > experience with it. I'm interested in XMPP. Actually, I don't really 
> > understand why this package is managed by the VoIP team and not by the 
> > XMPP team.
> 
> Sorry, I expressed that badly: What I meant to say is that if you care 
> for *this* package more generally (i.e. not only this once) then I 
> encourage you to join as package maintainer to help look after it.  The 
> VoIP team provides infrastructure - you need not care for other packages 
> in the VoIP team.
> 
> Reason Biboumi is maintained in the VoIP team is that Vasudev wanted my 
> help maintaining it, and I - just like you, if I understand correctly - 
> wanted to limit the amount of teams to attend to.  I have an interest in 
> XMPP but am already involved with 20 other teams.
> 
> I am open to having you and Vasudev move the package to the XMPP team, 
> but would hate to see the package become badly maintained: Vasudev has 
> not had a lot of time for packaging lately, and I don't know the level 
> of your devotion - that's why I suggest to start maintain it at its 
> current home where I can help keep an eye on it, and then maybe move it 
> later if you still prefer that after tending to it for some time.
> 
> ...but if you are eager to help and joining the VoIP team is what holds 
> you back, then maybe it is best to simply hand over the package to you.  
> Please do share your thoughts on this.
> 
> 
> Kind regards,
> 
>  - Jonas
> 
> -- 
>  * Jonas Smedegaard - idealist & Internet-arkitekt
>  * Tlf.: +45 40843136  Website: http://dr.jones.dk/
> 
>  [x] quote me freely  [ ] ask before reusing  [ ] keep private

Bug#977639: bible-kjv: Possible GPL compliance problems

[Bastian Germann]

Am 19.12.20 um 20:28 schrieb Matthew Vernon:

On 19/12/2020 13:28, Bastian Germann wrote:
On Fri, 18 Dec 2020 00:01:10 +0100 Bastian Germann 
 wrote:> bible-kjv package claims to be 
GPLv2 licensed. One file has an "or
later" clause but some files seem to GPLv2-only. However, with the 
switch to readline6 (#553733), it uses a GPLv3 library. GPLv3 and 
GPLv2-only are known to be incompatible licenses, so please build 
with libedit instead. A patch is enclosed.


Instead of applying this patch, you can also build-depend on 
libeditreadline-dev, which allows to build with libedit while keeping 
the readline interface.


I could also, presumably, adjust the licence to be GPL2+? The only bit 
of the code that is GPL2 and isn't my copyright is randverse, which 
isn't linked against readline.


Regards,

Matthew


Sure. That is another solution.

Bug#939527: vcdimager contains one file with different license

[Baptiste Beauplat]

Control: owner -1 !

On Thu, 05 Sep 2019 21:42:27 + bendik...@vfemail.net wrote:
> https://metadata.ftp-master.debian.org/changelogs//main/v/vcdimager/vcdimager_2.0.1+dfsg-3_copyright
> 
> The file changed on 17-03-2011 from gpl 2 or later to gpl 2
> https://cvs.savannah.gnu.org/viewvc/vcdimager/vcdimager/lib/sector.c?view=markup
> 
> Already send a message to (not visible at the moment)
> https://lists.gnu.org/mailman/listinfo/bug-vcdimager/
> also
> https://directory.fsf.org/wiki/User_talk:Rockyb
> more info
> https://directory.fsf.org/wiki/vcdimager

I asked upstream and apparently the change was requested by one of its
author. They don't seems to want to change it back.

See https://github.com/rocky/vcdimager/issues/5

For Debian, we just need to fix the copyright listing. I'll get on it.

-- 
Baptiste Beauplat - lyknode



OpenPGP_signature
Description: OpenPGP digital signature

Bug#976738: libintl.jar is not installed in /usr/share/maven-repo

[Santiago Vila]

On Sat, Dec 19, 2020 at 03:22:06PM -0500, Louis-Philippe Véronneau wrote:
> Dear maintainer,
> 
> Investigating more, it seems this bug breaks translations on multiple
> clojure packages that have libpuppetlabs-i18n-clojure as a dependency.
> 
> As the freeze is looming, I would like this to be fixed in stable,
> especially if I am to get puppetserver in the archive by then.
> 
> I am thus planning of NMUing this patch on Monday December 21st. I shall
> upload to DELAYED/10 to give you ample time to react if you think
> something is wrong with my patch.

No, please DON'T.

I have to integrate your patches with the new gettext. You will find
it in another bug.

Thanks.

Bug#977717: podman: Images can't be run with non-root USER after upgrade to 2.1.1 due to wrong permissions of / inside the container

[Reinhard Tartler]

Control: fixed -1 2.2.0+dfsg1-1
Control: forwarded -1 https://github.com/containers/podman/issues/7747

Thanks for the clarification. With this, I was able to reproduce the issue
in unstable, and confirm its absence with the podma 2.2 package in
experimental. I've found a patch on the github issue that resolves the
issue in 2.1.

thanks again for your help!
-rt

On Sat, Dec 19, 2020 at 3:09 PM adamo  wrote:

> Hi Reinhard,
>
>
> I was intending to open a bug report after contacting you earlier but
> someone appears to have beaten me to it!
>
>
> I'm still able to reproduce this on my end with the following.
>
> ---
> root@podman:~# podman run docker.io/alpine /bin/echo "Hello"
> Hello
> root@podman:~# adduser --uid 1010 bugtest --gecos "" --no-create-home
> --disabled-login --disabled-password
> Adding user `bugtest' ...
> Adding new group `bugtest' (1010) ...
> Adding new user `bugtest' (1010) with group `bugtest' ...
> Not creating home directory `/home/bugtest'.
> root@podman:~# podman run --user 1010 docker.io/alpine /bin/echo "Hello"
> Error: container_linux.go:370: starting container process caused: apply
> caps: operation not permitted: OCI runtime permission denied error
> ---
>
> This is a fresh image I've pulled and still occurs when running as the
> user 'nobody' as per your example.
>
> I've also tried the steps taken in your example (with an additional step
> to run the container) and managed to reproduce the error.
>
> -
> root@podman:~# cat Dockerfile
> FROM docker.io/debian
> USER nobody
> RUN id
> root@podman:~# podman rm -a
> root@podman:~# podman build -f Dockerfile
> STEP 1: FROM docker.io/debian
> Getting image source signatures
> Copying blob 6c33745f49b4 done
> Copying config 6d6b00c222 done
> Writing manifest to image destination
> Storing signatures
> STEP 2: USER nobody
> --> de292136a39
> STEP 3: RUN id
> uid=65534(nobody) gid=65534(nogroup) groups=65534(nogroup)
> STEP 4: COMMIT
> --> b08e47fc955
> b08e47fc955ccfe7a3c164e9fbd2068758ee145e39ffcc1a5c95d4a53ad4144d
> root@podman:~# podman run
> b08e47fc955ccfe7a3c164e9fbd2068758ee145e39ffcc1a5c95d4a53ad4144d /bin/echo
> "Hello"
> Error: container_linux.go:370: starting container process caused: apply
> caps: operation not permitted: OCI runtime permission denied error
> -
>
> While I don't think it's relevant, I've had this issue with both a VM on
> Linode (which I've upgraded from Debian 10 to bullseye) and on a local VM
> which was created directly from a "testing" iso.
>
> --
> root@podman:~# cat /etc/os-release
> PRETTY_NAME="Debian GNU/Linux bullseye/sid"
> NAME="Debian GNU/Linux"
> ID=debian
> HOME_URL="https://www.debian.org/;
> SUPPORT_URL="https://www.debian.org/support;
> BUG_REPORT_URL="https://bugs.debian.org/;
> --
>
> As mentioned, this appears to have been discussed in the issue
> https://github.com/containers/podman/issues/7747 on Github.
>
> If you need any more information from my end, please let me know.
>
> Thanks for your help with this.
>
> Regards,
> Adam.
>
>

-- 
regards,
Reinhard

Bug#976738: libintl.jar is not installed in /usr/share/maven-repo

[Louis-Philippe Véronneau]

Dear maintainer,

Investigating more, it seems this bug breaks translations on multiple
clojure packages that have libpuppetlabs-i18n-clojure as a dependency.

As the freeze is looming, I would like this to be fixed in stable,
especially if I am to get puppetserver in the archive by then.

I am thus planning of NMUing this patch on Monday December 21st. I shall
upload to DELAYED/10 to give you ample time to react if you think
something is wrong with my patch.

Thanks for your work on gettext.

-- 
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
  ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
  ⠈⠳⣄



OpenPGP_signature
Description: OpenPGP digital signature

Bug#977738: rofi: New upstream release 1.6.1

[Ayose]

Package: rofi
Version: 1.5.4-1+b1
Severity: wishlist
X-Debbugs-Cc: ayo...@gmail.com

Dear Maintainer,

A new version was published:

https://github.com/davatorium/rofi/releases/tag/1.6.1

Version 1.6.0 is very interesting because it adds a new [1]script mode
that allows more powerful selectors.

I tried to build the package using the current [2]debian directory for
the package in Sid and it seems to work with no changes.

1. https://github.com/davatorium/rofi/blob/next/doc/rofi-script.5.markdown
2. https://deb.debian.org/debian/pool/main/r/rofi/rofi_1.5.4-1.debian.tar.xz


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

Kernel: Linux 5.8.0-0.bpo.2-amd64 (SMP w/16 CPU threads)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Versions of packages rofi depends on:
ii  libc6 2.31-4
ii  libcairo2 1.16.0-4
ii  libglib2.0-0  2.66.4-1
ii  libpango-1.0-01.46.2-3
ii  libpangocairo-1.0-0   1.46.2-3
ii  librsvg2-22.50.2+dfsg-1
ii  libstartup-notification0  0.12-6+b1
ii  libxcb-ewmh2  0.4.1-1.1
ii  libxcb-icccm4 0.4.1-1.1
ii  libxcb-randr0 1.14-2
ii  libxcb-util1  0.4.0-1+b1
ii  libxcb-xinerama0  1.14-2
ii  libxcb-xkb1   1.14-2
ii  libxcb-xrm0   1.0-3+b1
ii  libxcb1   1.14-2
ii  libxkbcommon-x11-01.0.3-2
ii  libxkbcommon0 1.0.3-2

rofi recommends no packages.

rofi suggests no packages.

-- no debconf information

Bug#977737: alt-ergo suggests why, which isn't provided by any package

[John Scott]

Package: alt-ergo
Version: 2.0.0-7+b4
Severity: minor

I'd send a merge request but I don't know what the proper fix is here. The
alt-ergo package Suggests: why, but it seems like why is provided by the why3
package. Either the Suggests should be fixed, or why3 should provide the why
virtual package.

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

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

Versions of packages alt-ergo depends on:
ii  libc6   2.31-5
ii  libgmp102:6.2.1+dfsg-1
ii  libnum-ocaml [libnum-ocaml-80ki3]   1.4-1
ii  ocaml-base-nox [ocaml-base-nox-4.11.1]  4.11.1-4
ii  zlib1g  1:1.2.11.dfsg-2

alt-ergo recommends no packages.

Versions of packages alt-ergo suggests:
pn  why  

-- no debconf information


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

Bug#977736: iotjs: CVE-2020-29657

[Salvatore Bonaccorso]

Source: iotjs
Version: 1.0+715-1
Severity: important
Tags: security upstream
Forwarded: https://github.com/jerryscript-project/jerryscript/issues/4244
X-Debbugs-Cc: car...@debian.org, Debian Security Team 
Control: found -1 1.0-1

Hi,

The following vulnerability was published for iotjs. Actually for
embedded jerryscript, which seem still affected in up to the version
included in 1.0+715-1.

CVE-2020-29657[0]:
| In JerryScript 2.3.0, there is an out-of-bounds read in
| main_print_unhandled_exception in the main-utils.c file.


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-2020-29657
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-29657
[1] https://github.com/jerryscript-project/jerryscript/issues/4244

Regards,
Salvatore

Bug#977735: buster-pu: package node-ini/1.3.5-1+deb10u1

[Xavier Guimard]

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

[ Reason ]
node-ini is vulnearable to CVE-2020-7788: if an attacker submits a malicious
INI file to an application that parses it with ini.parse, they will pollute
the prototype on the application. This can be exploited further depending
on the context. (#977718)

[ Impact ]
Little vulnerability

[ Tests ]
Patch includes a test

[ Risks ]
Change just adds 2 checks, No risk.

[ 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 ]
2 checks to avoid prototype pollution
diff --git a/debian/changelog b/debian/changelog
index 4d4fc30..a153918 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+node-ini (1.3.5-1+deb10u1) buster; urgency=medium
+
+  * Team upload
+  * Do not allow invalid hazardous string as section name
+(Closes: #977718, CVE-2020-7788)
+
+ -- Xavier Guimard   Sat, 19 Dec 2020 20:48:36 +0100
+
 node-ini (1.3.5-1) unstable; urgency=medium
 
   * Team Upload
diff --git a/debian/patches/CVE-2020-7788.patch 
b/debian/patches/CVE-2020-7788.patch
new file mode 100644
index 000..54f5bbe
--- /dev/null
+++ b/debian/patches/CVE-2020-7788.patch
@@ -0,0 +1,87 @@
+Description: do not allow invalid hazardous string as section name
+Author: isaacs 
+Bug: https://snyk.io/vuln/SNYK-JS-INI-1048974
+Bug-Debian: https://bugs.debian.org/977718
+Forwarded: not-needed
+Reviewed-By: Xavier Guimard 
+Last-Update: 2020-12-19
+
+--- a/ini.js
 b/ini.js
+@@ -80,6 +80,12 @@
+ if (!match) return
+ if (match[1] !== undefined) {
+   section = unsafe(match[1])
++  if (section === '__proto__') {
++// not allowed
++// keep parsing the section, but don't attach it.
++p = {}
++return
++  }
+   p = out[section] = out[section] || {}
+   return
+ }
+@@ -94,6 +100,7 @@
+ // Convert keys with '[]' suffix to an array
+ if (key.length > 2 && key.slice(-2) === '[]') {
+   key = key.substring(0, key.length - 2)
++  if (key === '__proto__') return
+   if (!p[key]) {
+ p[key] = []
+   } else if (!Array.isArray(p[key])) {
+@@ -125,6 +132,7 @@
+ var l = parts.pop()
+ var nl = l.replace(/\\\./g, '.')
+ parts.forEach(function (part, _, __) {
++  if (part === '__proto__') return
+   if (!p[part] || typeof p[part] !== 'object') p[part] = {}
+   p = p[part]
+ })
+--- /dev/null
 b/test/proto.js
+@@ -0,0 +1,45 @@
++var ini = require('../')
++var t = require('tap')
++
++var data = `
++__proto__ = quux
++foo = baz
++[__proto__]
++foo = bar
++[other]
++foo = asdf
++[kid.__proto__.foo]
++foo = kid
++[arrproto]
++hello = snyk
++__proto__[] = you did a good job
++__proto__[] = so you deserve arrays
++thanks = true
++`
++var res = ini.parse(data)
++t.deepEqual(res, {
++  foo: 'baz',
++  other: {
++foo: 'asdf',
++  },
++  kid: {
++foo: {
++  foo: 'kid',
++},
++  },
++  arrproto: {
++hello: 'snyk',
++thanks: true,
++  },
++})
++t.equal(res.__proto__, Object.prototype)
++t.equal(res.kid.__proto__, Object.prototype)
++t.equal(res.kid.foo.__proto__, Object.prototype)
++t.equal(res.arrproto.__proto__, Object.prototype)
++t.equal(Object.prototype.foo, undefined)
++t.equal(Object.prototype[0], undefined)
++t.equal(Object.prototype['0'], undefined)
++t.equal(Object.prototype[1], undefined)
++t.equal(Object.prototype['1'], undefined)
++t.equal(Array.prototype[0], undefined)
++t.equal(Array.prototype[1], undefined)
diff --git a/debian/patches/series b/debian/patches/series
new file mode 100644
index 000..c281569
--- /dev/null
+++ b/debian/patches/series
@@ -0,0 +1 @@
+CVE-2020-7788.patch

Bug#977639: bible-kjv: Possible GPL compliance problems

[Matthew Vernon]

On 19/12/2020 13:28, Bastian Germann wrote:
On Fri, 18 Dec 2020 00:01:10 +0100 Bastian Germann 
 wrote:> bible-kjv package claims to be 
GPLv2 licensed. One file has an "or
later" clause but some files seem to GPLv2-only. However, with the 
switch to readline6 (#553733), it uses a GPLv3 library. GPLv3 and 
GPLv2-only are known to be incompatible licenses, so please build with 
libedit instead. A patch is enclosed.


Instead of applying this patch, you can also build-depend on 
libeditreadline-dev, which allows to build with libedit while keeping 
the readline interface.


I could also, presumably, adjust the licence to be GPL2+? The only bit 
of the code that is GPL2 and isn't my copyright is randverse, which 
isn't linked against readline.


Regards,

Matthew

Bug#977734: ITP: mediasoup -- general purpose WebRTC gateway

[Jonas Smedegaard]

Package: wnpp
Severity: wishlist
Owner: Jonas Smedegaard 
X-Debbugs-Cc: debian-de...@lists.debian.org, Debian VoIP Team 


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: mediasoup
  Version : 3.6.27
  Upstream Author : Iñaki Baz Castillo 
* URL : https://mediasoup.org/
* License : ISC
  Programming Lang: C, JavaScript, TypeScript
  Description : general purpose WebRTC gateway

 mediasoup is a general purpose WebRTC Gateway with a minimal footprint.
 .
 As such, it provides no functionality per se other than implementing
 the means to set up a WebRTC media communication with a browser,
 exchanging JSON messages with it, and relaying RTP/RTCP and messages
 between browsers and the server-side application logic they are
 attached to. Any specific feature/application are implemented in server
 side plugins, that browsers contact via the gateway to take advantage
 of the functionality they provide.
 .
 Example uses for mediasoup are applications involving echo tests,
 conference bridges, media recorders, and SIP gateways.

This package will be maintained in the VoIP team.

 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAl/eWD0ACgkQLHwxRsGg
ASFSaw//aDnYz3yP9LwKg1eqaR6E6i43bE/U18hWJMPYtsnwbmf5SpSaf/QY7aPi
9Ga9n3d9a9K74PPUDqYcLfm0JS8vYtFzuQOImOjCZmSC4OYj9ZCWpI26dso8LTK6
szdCBOm0WwBAo+beRpNzaiTrdb9JuOvfTwMOpl8PUDoxz0Eku4eqSxRfCVCgNtgV
ddnlEwhfROrhzl1ZybJROI1RgmrG6TPXOkPCEwUExHeRlb0Q92Btqz0dQUAzX6dE
59xd49Y/rR0tzbw0BIi1HaOlCB37mpqFgti69wkdIdc9cJt8PZta47XpxeajDSxB
yzxfWzlhQNUKucJxB5x4J8e0O/Q5hPr49CWJCajendrgfC6gVijv1HUMWLCEQ3h0
TrOBhyrSA1QSz25Nr2HKUDpy9c4DTZImPM6BO2NKT2GtPybKajeDain0NT6So5Bf
CJ+KrTjJ3GyPkUZXx+z/CWe4E+PSaOgHsq8BT1RLIP1FMTYArJwJdT31gZ/xU9NC
6PANihdirNupZG4H8uafKq04+NkPzq3iYjQaQlq6xKQYLS6X4BB/FSPLimTtjOR5
Sx/rwqZdG63yniXj/ekE+LIs4swuNb9tXc6hx2OU+BAOd2iPo/cY1urczrYVdxzR
qOhF3/wCVLvJDuEQBodyz4TiDjEZr2xAvfXxw5O1G2QAkIfAwaM=
=mpRM
-END PGP SIGNATURE-

Bug#977733: www.debian.org: inconsistent info in repo regarding file english/News/2019/20190216.wml

[Rafa]

Package: www.debian.org
Severity: normal

Dear Maintainers,

It seems that there is something odd in the webmaster-team/webwml.git
repository at salsa regarding file english/News/2019/20190216.wml.

We get inconsistent results when we issue the git log command using
different arguments.

Commit with hash 9bd5a55d72acee622d9e25eecb70e1beb93d0ea4 was made in
December 2019, and it corresponds to a modification of file
english/News/2019/20190216.wml according to the output of the "git log
... commit-hash" command:

  $ git log -n1 --format=fuller --name-only 
9bd5a55d72acee622d9e25eecb70e1beb93d0ea4

  commit 9bd5a55d72acee622d9e25eecb70e1beb93d0ea4
  Author: Laura Arjona Reina 
  AuthorDate: Fri Dec 13 20:13:29 2019 +0100
  Commit: Laura Arjona Reina 
  CommitDate: Fri Dec 13 20:13:29 2019 +0100

  remove the tag for frontpage

  english/News/2019/20190216.wml


On the other hand, if we ask for the commits that represent
modifications of the very same file via the "git log
-- path/filename" command, we get the following:

  $ git log --format=fuller --name-only -- english/News/2019/20190216.wml
  commit ea6a13e28f99e15f67ccfd6b74b4cc4bb185fdbd
  Author: Laura Arjona Reina 
  AuthorDate: Tue Apr 2 08:28:56 2019 +0200
  Commit: Laura Arjona Reina 
  CommitDate: Tue Apr 2 08:35:59 2019 +0200

  https://security.debian.org -> https://www.debian.org/security

  english/News/2019/20190216.wml

  commit fdc485a3cb59ae0b5ef29c7ff90f411b2444ed09
  Author: Donald Norwood 
  AuthorDate: Sat Feb 16 10:38:53 2019 -0500
  Commit: Donald Norwood 
  CommitDate: Sat Feb 16 10:38:53 2019 -0500

  Debian 9.8 release announcement

  english/News/2019/20190216.wml

As you can see, the output of the second command does not include the
commit with hash 9bd5a55d72acee622d9e25eecb70e1beb93d0ea4, Dec. 2019.
The first (most recent) commit shown was made in April 2019.

Note: we have found a similar behaviour regarding file
english/CD/faq/index.wml. If you think that it is better to submit a
separate bug report for it, please, let me know.

Regards,

Rafa.



signature.asc
Description: PGP signature

Bug#977732: python3.9: Build with libedit rather than readline

[Bastian Germann]

Package: python3.9
Version: 3.9.1-1
Severity: normal

Please consider replacing the GPL-3 licensed build dependency
libreadline-dev with libedit-dev, which is also supported by Python. The
GPL-3 is incompatible with some licenses such as GPL-2-only. Therefore,
a foundational package such as Python should choose the more
liberally licensed dependency to allow as much software in the archive
as possible without license headaches.

Most probably, there is already a GPL-2-only Python software in the
archive that uses the readline module but I did not check.

Bug#977717: podman: Images can't be run with non-root USER after upgrade to 2.1.1 due to wrong permissions of / inside the container

[Reinhard Tartler]

Control: tag -1 moreinfo unreproducible


On Sat, Dec 19, 2020 at 9:15 AM Andreas Maus <
023a305472eca90cd389e9dd4a9f30f71a6cf...@ypbind.de> wrote:

> After the upgrade of podman to 2.1.1 container images
> can't be run if the Dockerfile specify a non-root USER.
>

I'm sorry, but I can't reproduce this (anymore):

siretart@x1:/tmp/d$ *podman rmi -a*
8ac063dba0c0659a071a74e67d3661495215ab740724e416d62f264d73a398ce
Untagged: docker.io/library/debian:latest
Deleted: db2b7591a39e6b509f93038f6855f95bb783efdc83aa3a20c347453320b6d345
Deleted: 6d6b00c22231693c9b87e79986d562874446bf10182206e4621e23ca8dfa8e1c
siretart@x1:/tmp/d$ *podman rm -a*
siretart@x1:/tmp/d$ *cat Dockerfile *
*FROM docker.io/debian *
*USER nobody*
*RUN id*
siretart@x1:/tmp/d$ *podman build -f Dockerfile *
STEP 1: FROM docker.io/debian
Getting image source signatures
Copying blob 6c33745f49b4 done
Copying config 6d6b00c222 done
Writing manifest to image destination
Storing signatures
STEP 2: USER nobody
--> 609dac75d3a
STEP 3: RUN id
uid=65534(nobody) gid=65534(nogroup) groups=65534(nogroup)
STEP 4: COMMIT
--> 037e1690447
037e1690447f0dd7d90d99cf7bc3cf1206f35f81225f2119445b147d5b6aa3a9

I was able to reproduce this error with an cached image that I had, but
deleting the local one
and getting a fresh one from the docker library allowed me to pass that
test.

I was not able to pull your exact image, and to be frank, I'd prefer if you
could describe the
steps to reproduce this with images that are publicly accessible and simple
to reproduce.

Can you please try again with fresh images and the example that I showed
above?

-- 
regards,
Reinhard

Bug#788666: Bug#841255: [bts-link] source package liferea

[Paul Gevers]

Hi Lars,

On 19-12-2020 16:49, Lars Windolf wrote:
> @Paul Gevers: if it helps your workflow, feel free to re-open the
> tickets upstream.

If you're not going to look at it, it doesn't help to keep them open.

> The thing about crash ticket is that they are sometimes caused by used
> libraries
> and are race-prone and hard to reproduce and just get stale and clog up
> the ticket
> tracker. As a Debian maintainer you know it probably well :-)

I know, I know. It's not always easy to handle bugs the right way.
Especially for these kind of bugs, either one should check quickly, or
motivation to check if the crash can still happen is dwindling. Having
the ticket tracker in a usable state is important too.

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#977693: gtk+3.0: Wayland primary selection interoperability with GTK clients on Plasma Desktop

[Sandro Knauß]

Hey,

> > Upstream GTK developer Emmanuele Bassi said that there are no more gtk3
> > dot releases planned (at least not before GTK 4.0 is released).
> 
> That seems to be outdated information: GTK 4.0.0 has been released now
> (I uploaded it to experimental NEW since it has a new SONAME and needs
> a newer version of Pango), and a 3.24.24 point release also happened.

great.

> > Emmanuale recommends cherry-picking this patch from the gtk-3-24 stable
> > branch to distro packages:
> > 
> > https://gitlab.gnome.org/GNOME/gtk/-/commit/9a693c7228a88b76a007aed41b101d
> > 89d084cf9b
> That's included in 3.24.24, in testing since 2020-12-14.

Thanks for this info.

> 
> > To verify that the patch works:
> > 1. Log into a Plasma Wayland session
> 
> I'll try to test this at some point, but it's very likely to be quicker
> for a Plasma user to upgrade their GTK 3 version than it is for me to
> install Plasma.

I tested it on my machine (Debian unstable with libgtk-3-common 3.24.24-1) and 
still I cannot copy text from Firefox to other clients.

I'll forward your text to the distributions mailinglist, as I'm not an 
upstream developer of Plasma. And the primary mail with the request for 
backport came from the plasma team.

regards,

hefee




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

Bug#977731: lintian-brush: Default committer identity doesn't always match `git config user.email`

[Guilhem Moulin]

Package: lintian-brush
Version: 0.89
Severity: wishlist

Dear Maintainer,

I use git-config(1)'s ‘include.path’ and ‘includeIf.*.path’ settings to
set user.email to my @debian.org email address gobally for all my Debian
repositories while keeping my private email address as general default:

$XDG_CONFIG_HOME/git/config:
[user]
email = guil...@example.net
[includeIf "gitdir:/path/to/debian/**/.git"]
path = debian.config

$XDG_CONFIG_HOME/git/debian.config:
[user]
email = guil...@debian.org
[merge "dpkg-mergechangelogs"]
name = debian/changelog merge driver
driver = dpkg-mergechangelogs -m %O %A %B %A

This works just fine as far as the git binary is concerned: `git config
user.email` returns ‘guil...@debian.org’ in repositories under
‘/path/to/debian’, and ‘guil...@example.net’ everywhere else.  (Unless
overwritten in the repo config, of course.)

However lintian-brush doesn't seem to understand includeIf.*.path (nor
include.path):

/path/to/debian/pkg $ lintian-brush --identity
Committer identity: Guilhem Moulin 
Changelog identity: Guilhem Moulin 

If I understand the source correctly, this is because the gitconfig
library it's using doesn't understand these settings.  It might be a
wishlist bug for the library, however lintian-brush could maybe call
`git config user.email` instead and let the git binary take care of the
parsing and fallback logic?

Alternatively, I see it honors the GIT_COMMITTER_EMAIL environment
variable.  I don't want to set this variable globally though; devscripts
use DEBEMAIL and I have DEBEMAIL=guil...@debian.org.  Since
lintian-brush is Debian-specific, wouldn't it make sense to honor
DEBEMAIL resp. DEBFULLNAME before GIT_COMMITTER_EMAIL resp.
GIT_COMMITTER_NAME?

If you don't like the above, how about new options username/email in
lintian-brush.conf? :-)

Thanks for maintaining lintian-brush!
Cheers,
-- 
Guilhem.

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

Kernel: Linux 5.9.0-3-amd64 (SMP w/8 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages lintian-brush depends on:
ii  devscripts   2.20.5
ii  python3  3.9.0-4
ii  python3-breezy   3.1.0-8
ii  python3-debian   0.1.39
ii  python3-debmutate0.16
ii  python3-distro-info  0.24
ii  python3-dulwich  0.20.8-1+b1
ii  python3-iniparse 0.4-3
ii  python3-ruamel.yaml  0.16.12-2

Versions of packages lintian-brush recommends:
pn  decopy   
ii  dos2unix 7.4.1-1
ii  gpg  2.2.20-1
ii  libdebhelper-perl13.3
ii  lintian  2.104.0
pn  python3-asyncpg  
pn  python3-bs4  
pn  python3-levenshtein  
pn  python3-pyinotify
pn  python3-toml 

Versions of packages lintian-brush suggests:
pn  breezy-debian  
pn  gnome-pkg-tools
ii  po-debconf 1.0.21
pn  postgresql-common  

-- no debconf information


signature.asc
Description: PGP signature

Bug#977730: torbrowser-launcher: Signature verification failed, key expired

[Jean-Michel Vourgère]

Package: torbrowser-launcher
Version: 0.3.3-3
Severity: important

Dear Maintainer,

When installing on a fresh bullseye, torbrowser is downloaded, then this
message is printed:

> SIGNATURE VERIFICATION FAILED
> 
> Error Code: 110775B5(...)FF07E2: Key expired
>
> You might be under attack, there might be a network problem, or you
> might be missing a recently added Tor Browser verification key.
>
> A copy of Tor (...)

I expected the download to succeed, obviously.

Thanks

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

Kernel: Linux 5.9.0-4-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (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 torbrowser-launcher depends on:
ii  ca-certificates20200601
ii  gnupg  2.2.20-1
ii  libdbus-glib-1-2   0.110-5
ii  python33.9.0-4
ii  python3-gpg1.14.0-1+b2
ii  python3-packaging  20.4-1
ii  python3-pyqt5  5.15.2+dfsg-1+b1
ii  python3-requests   2.24.0+dfsg-1
ii  python3-socks  1.7.1+dfsg-1

Versions of packages torbrowser-launcher recommends:
ii  tor  0.4.4.6-1

Versions of packages torbrowser-launcher suggests:
ii  apparmor  2.13.5-1+b2

-- no debconf information

Bug#968626: gitlab: Error 500 during CI artifacts upload from gitlab-runner

[Maximilian Stein]

Hi folks,

I just found a workaround for that issue. Apparently, the issue is a
missing type check/type confusion in "etag" (or in the invocation of
this lib). With the patch attached to this mail, artifacts can be
uploaded again.

To debug the issue, I added a begin/resuce block around the failing call
to @app.call in lib/gitlab/middleware/read_only/controller.rb:51 and
dumped the entire stack trace:

  begin
    @app.call(@env)
  rescue NoMethodError => e
    Gitlab::AppLogger.error("Here we are")
    Gitlab::AppLogger.error(e.message)
    e.backtrace.each { |line| Gitlab::AppLogger.error(line) }
  end

The result was dumped into the "application.log" and clearly showed the
origin of the exception:

2020-12-19T15:54:30.166Z: Here we are
2020-12-19T15:54:30.168Z: undefined method `empty?' for 201:Integer
2020-12-19T15:54:30.169Z: /usr/lib/ruby/vendor_ruby/rack/etag.rb:70:in
`block in digest_body'
2020-12-19T15:54:30.169Z:
/usr/lib/ruby/vendor_ruby/rack/body_proxy.rb:34:in `block in each'
2020-12-19T15:54:30.169Z:
/usr/lib/ruby/vendor_ruby/rack/body_proxy.rb:34:in `each'
2020-12-19T15:54:30.170Z:
/usr/lib/ruby/vendor_ruby/rack/body_proxy.rb:34:in `each'
2020-12-19T15:54:30.170Z: /usr/lib/ruby/vendor_ruby/rack/etag.rb:68:in
`digest_body'
2020-12-19T15:54:30.170Z: /usr/lib/ruby/vendor_ruby/rack/etag.rb:31:in
`call'
2020-12-19T15:54:30.170Z:
/usr/lib/ruby/vendor_ruby/rack/conditional_get.rb:40:in `call'
2020-12-19T15:54:30.170Z: /usr/lib/ruby/vendor_ruby/rack/head.rb:14:in
`call'
2020-12-19T15:54:30.171Z:
/usr/share/rubygems-integration/all/gems/actionpack-6.0.3.1/lib/action_dispatch/http/content_security_policy.rb:18:in
`call'
2020-12-19T15:54:30.171Z:
/usr/share/gitlab/lib/gitlab/middleware/read_only/controller.rb:52:in `call'

So, right now, I do have a workaround, although I don't where the
problem is exactly (i.e., in gitlab or in etag) nor how it should be
fixed. I hope this helps debugging the issue further!

Best,
Maximilian

--- /usr/lib/ruby/vendor_ruby/rack/etag.rb.old  2020-12-19 18:54:53.266122418 +0100
+++ /usr/lib/ruby/vendor_ruby/rack/etag.rb.new  2020-12-19 18:54:04.169502266 +0100
@@ -67,7 +67,7 @@

 body.each do |part|
   parts << part
-  (digest ||= Digest::SHA256.new) << part unless part.empty?
+  (digest ||= Digest::SHA256.new) << part if part.is_a?(String) && !part.empty?
 end

 [digest && digest.hexdigest.byteslice(0, 32), parts]


OpenPGP_signature
Description: OpenPGP digital signature

Bug#977688: node-css-loader: please embed additional postcss extensions

[Pirate Praveen]

On Fri, 18 Dec 2020 23:10:30 +0100 Jonas Smedegaard  wrote:
> Package: node-css-loader
> Version: 3.2.1+~cs21.3.8.1-2
> Severity: wishlist
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> I need these postcss-related modules not yet in Debian:
>
>  postcss-loader
>  postcss-preset-env
>  postcss-strip-inline-comments
>
> They all have seemingly similar dependencies and build-dependencies -
> notably they build-depend on babel same as node-css-loader.
>
> Please consider embdding these postcss modules with node-css-loader.

I'd like to update css-loader to latest upstream release/postcss 8 
transition before I work on this.

Bug#977729: reportbug: werasdfj

[Nis Martensen]

Package: reportbug
Version: 7.8.1
Severity: normal
X-Debbugs-Cc: nis.marten...@web.de

eins zwei drei
vier fünf sechs
sieben acht neun

-- Package-specific info:
** Environment settings:
EDITOR="vi"
DEBEMAIL="nis.marten...@web.de"
DEBFULLNAME="Nis Martensen"
INTERFACE="text"

** /home/nis/.reportbugrc:
reportbug_version "3.48"
mode novice
ui text
email "nis.marten...@web.de"
no-cc
list-cc-me
smtphost reportbug.debian.org

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

Kernel: Linux 4.19.0-13-amd64 (SMP w/4 CPU threads)
Locale: LANG=da_DK.UTF-8, LC_CTYPE=da_DK.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 reportbug depends on:
ii  apt1.8.2.2
ii  python33.7.3-1
ii  python3-reportbug  7.8.1
ii  sensible-utils 0.0.12

reportbug recommends no packages.

Versions of packages reportbug suggests:
ii  claws-mail 3.17.3-2
pn  debconf-utils  
ii  debsums2.2.3
ii  dlocate1.07+nmu1
ii  emacs-bin-common   1:26.1+1-3.2+deb10u1
ii  exim4-daemon-light [mail-transport-agent]  4.92-8+deb10u4
ii  file   1:5.35-4+deb10u1
ii  gnupg  2.2.12-1+deb10u1
ii  python3-urwid  2.0.1-2+b1
ii  reportbug-gtk  7.8.1
ii  xdg-utils  1.1.3-1+deb10u1

Versions of packages python3-reportbug depends on:
ii  apt1.8.2.2
ii  file   1:5.35-4+deb10u1
ii  python33.7.3-1
ii  python3-apt1.8.4.2
ii  python3-debian 0.1.35
ii  python3-debianbts  3.0.2~bpo10+1
ii  python3-requests   2.21.0-1
ii  sensible-utils 0.0.12

python3-reportbug suggests no packages.

-- no debconf information

Bug#977728: /usr/bin/virsh: Please pass XDG_* environment variables to the SSH binary

[Guilhem Moulin]

Package: libvirt-clients
Version: 6.9.0-1+b2
Severity: wishlist
File: /usr/bin/virsh
Tags: patch upstream

Dear Maintainer,

Since version 8.4 OpenSSH supports environment variables in several
configuration values [0], thereby allowing using $XDG_RUNTIME_DIR as
ControlPath directory without having to hardcode its value in
~/.ssh/config:

ControlPath ${XDG_RUNTIME_DIR}/ssh-%C

However the above snippet causes the command to fail as virsh runs it in
a sanitized environment:

error: failed to connect to the hypervisor
error: Cannot recv data: vdollar_percent_expand: env var ${XDG_RUNTIME_DIR} 
has no value
invalid environment variable expansion: Connection reset by peer

This patch preserves environment variables of the XDG Base Directory
Specification [1] when calling the SSH binary.  (Other XDG_* environment
variables are arguably useful as well for ProxyCommand.)

Alternatively, maybe a configuration option to run the SSH binary in the
stock environment would do?  After all OpenSSH has its own environment
sanitation logic.

Thanks,
cheers,
-- 
Guilhem.

[0] https://www.openssh.com/txt/release-8.4 
https://bugzilla.mindrot.org/show_bug.cgi?id=3140
[1] 
https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html#variables

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

Kernel: Linux 5.9.0-3-amd64 (SMP w/8 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libvirt-clients depends on:
ii  libc6   2.31-6
ii  libgcc-s1   10.2.1-1
ii  libglib2.0-02.66.4-1
ii  libreadline88.1-1
ii  libvirt06.9.0-1+b2
ii  libxml2 2.9.10+dfsg-6.3+b1
ii  sensible-utils  0.0.12+nmu1

libvirt-clients recommends no packages.

Versions of packages libvirt-clients suggests:
ii  libvirt-daemon  6.9.0-1+b2

-- no debconf information
From: Guilhem Moulin 
Date: Sat, 19 Dec 2020 18:31:01 +0100
Subject: Pass XDG_* environment variables to the SSH binary

Since version 8.4 OpenSSH supports environment variables in several
configuration values, thereby allowing the using $XDG_RUNTIME_DIR as
ControlPath directory without having to hardcode its value in
~/.ssh/config:

ControlPath ${XDG_RUNTIME_DIR}/ssh-%C

However the above snippet causes the command to fail as virsh runs it in
a sanitized environment:

error: failed to connect to the hypervisor
error: Cannot recv data: vdollar_percent_expand: env var ${XDG_RUNTIME_DIR} has no value
invalid environment variable expansion: Connection reset by peer

This patch preserves environment variables of the XDG Base Directory
Specification when calling the SSH binary.  (Other XDG_* environment
variables are arguably useful as well for ProxyCommand.)
---
 src/rpc/virnetsocket.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/src/rpc/virnetsocket.c b/src/rpc/virnetsocket.c
index eb5a4b2..32ac4b1 100644
--- a/src/rpc/virnetsocket.c
+++ b/src/rpc/virnetsocket.c
@@ -882,6 +882,13 @@ int virNetSocketNewConnectSSH(const char *nodename,
 virCommandAddEnvPass(cmd, "TERM");
 virCommandAddEnvPass(cmd, "DISPLAY");
 virCommandAddEnvPass(cmd, "XAUTHORITY");
+/* https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html#variables */
+virCommandAddEnvPass(cmd, "XDG_DATA_HOME");
+virCommandAddEnvPass(cmd, "XDG_CONFIG_HOME");
+virCommandAddEnvPass(cmd, "XDG_DATA_DIRS");
+virCommandAddEnvPass(cmd, "XDG_CONFIG_DIRS");
+virCommandAddEnvPass(cmd, "XDG_CACHE_HOME");
+virCommandAddEnvPass(cmd, "XDG_RUNTIME_DIR");
 virCommandClearCaps(cmd);
 
 if (service)


signature.asc
Description: PGP signature

Bug#845554: reportbug: Not prompted for password or necessary information when setting up reportbug

[Nis Martensen]

On 24 Nov 2016 Nancy Anthracite wrote:


   * What led up to the situation? I configured report bug to use my email
saying that it required TLS, gave it the email but I was not asked for a port
or a password and when I tried to submit the report, it did not ask me for a
password and it timed out.


reportbug does ask for a port - in the question about the smtphost:

|  Please enter the name of your SMTP host.  Usually it's called
|  something like "mail.example.org" or "smtp.example.org".
|  If you need to use a different port than default, use the
|  ': alternative format.

I think having it integrated in this question is a good idea, because 
most people do not need a non-default port and non-technical users would 
get more confused if we added an extra question about the port.


Therefore I believe this issue is more a user support issue than a bug 
in reportbug. Closing this bug accordingly.

Bug#977726: debbugs: Decode non-ascii "Done:" field in HTML output

[Rafael Laboissière]

Package: debbugs
Version: 2.6.0
Severity: normal

Dear Maintainer,

The header "Done:" in the web pages for the individual bugs are 
wrongly displayed when the name of the person who closed the bug 
contains non-ASCII characters.  This is the case of my name, as we can 
see in Bug#976382 [1]:

Reported by: Sébastien Villemot 
Date: Fri, 4 Dec 2020 12:06:02 UTC
Severity: serious
Tags: fixed-in-experimental, ftbfs
Found in version plplot/5.15.0+dfsg-16
Fixed in versions plplot/5.15.0+dfsg-16+gnat10, plplot/5.15.0+dfsg-17
Done: =?utf-8?q?Rafael_Laboissi=C3=A8re?= 

Notice that the name of the bug reporter also contains a non-ASCII 
character and is correctly displayed.

Best regards,

Rafael Laboissière

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

Bug#977725: RFS: urlwatch/2.22-1 -- monitors webpages for you

[Maxime Werlen]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: urlwatch
   Version : 2.22-1
   Upstream Author : Thomas Perl 
 * URL : https://thp.io/2008/urlwatch/
 * License : BSD-3-clause
 * Vcs : https://salsa.debian.org/mwerlen/urlwatch
   Section : web

It builds those binary packages:

  urlwatch - monitors webpages for you

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/u/urlwatch/urlwatch_2.22-1.dsc

Changes since the last upload:

 urlwatch (2.22-1) unstable; urgency=medium
 .
   * New upstream release
   * Update patches
   * Drop support for Python 3.5
   * Updated Standards-Version to 4.5.1

Regards,
-- 
  Maxime Werlen

Bug#977724: libruby2.7: Build with libedit rather than readline

[Bastian Germann]

Package: libruby2.7
Version: 2.7.2-3
Severity: normal

Please consider replacing the GPL-3 licensed build dependency 
libreadline6-dev with libedit-dev, which is also supported by Ruby. The 
GPL-3 is incompatible with some licenses such as GPL-2-only. Therefore, 
a foundational package such as libruby2.7 should choose the more 
liberally licensed dependency to allow as much software in the archive 
as possible without license headaches.


Most probably, there is already a GPL-2-only ruby software in the 
archive that uses the readline module but I did not check.

Bug#976431: llvm-defaults: diff for NMU version 0.51+nmu1

[Jonas Smedegaard]

Quoting Sylvestre Ledru (2020-12-19 17:51:44)
> Excellent, thanks
> 
> I was going to do it but thanks for doing it :)

Happy that's your take on it - I realized just after releasing it that 
when it could hang there for weeks it could just as well spend a few 
more days in a queue...

 - Jonas

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

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

signature.asc
Description: signature

Bug#976431: llvm-defaults: diff for NMU version 0.51+nmu1

[Sylvestre Ledru]

Excellent, thanks

I was going to do it but thanks for doing it :)


Le 19/12/2020 à 17:22, Jonas Smedegaard a écrit :

Control: tags 976431 + patch


Dear maintainer,

I've prepared an NMU for llvm-defaults (versioned as 0.51+nmu1). The diff
is attached to this message.

I took the liberty of uploading without delay, since the change should
be rather self-contained (famous last words...), and although not an RC
bug for this package, it has caused emscripten to fail to build for some
weeks now.

Regards.

  - Jonas

diff -Nru llvm-defaults-0.51/debian/changelog 
llvm-defaults-0.51+nmu1/debian/changelog
--- llvm-defaults-0.51/debian/changelog 2020-12-04 23:43:26.0 +0100
+++ llvm-defaults-0.51+nmu1/debian/changelog2020-12-19 17:10:28.0 
+0100
@@ -1,3 +1,12 @@
+llvm-defaults (0.51+nmu1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+
+  * Provide unversioned wasm-ld in llvm;
+closes: bug#976431
+
+ -- Jonas Smedegaard   Sat, 19 Dec 2020 17:10:28 +0100
+
  llvm-defaults (0.51) unstable; urgency=medium
  
* Upload to unstable

diff -Nru llvm-defaults-0.51/debian/rules llvm-defaults-0.51+nmu1/debian/rules
--- llvm-defaults-0.51/debian/rules 2020-12-04 21:05:15.0 +0100
+++ llvm-defaults-0.51+nmu1/debian/rules2020-12-19 17:04:48.0 
+0100
@@ -178,7 +178,7 @@
llvm-dwp llvm-exegesis llvm-lib llvm-lto llvm-lto2 llvm-mca 
llvm-modextract \
llvm-mt llvm-objcopy llvm-opt-report llvm-pdbutil llvm-rc 
llvm-readelf \
llvm-readobj llvm-split llvm-stress llvm-strings llvm-strip 
llvm-undname \
-   llvm-xray sanstats opt \
+   llvm-xray sanstats opt wasm-ld \
; do \
dh_link -pllvm \
/usr/lib/llvm-$(PV_LLVM)/bin/$$bin \

Bug#977673: pan: Frequent freeze-ups when using SSL connections

[Dominique Dumont]

On vendredi 18 décembre 2020 16:30:11 CET you wrote:
> I am using pan to connect to the news servers of
> news*.open-news-network.org. Some of them are using NTTPS.  I have started
> pan with the options "--debug --debug --debug-ssl". After some time,
> pan doesn't respond anymore. The output shows a continues stream of the
> following debug output. It looks like it is in some loop.

Does pan resume after a while ?

On my side, I use pan with ssl without problem. I thought it was stalled, but 
it had popped another windows asking whether the server's certificate should be 
trusted.

HTH

Bug#976431: llvm-defaults: diff for NMU version 0.51+nmu1

[Jonas Smedegaard]

Control: tags 976431 + patch


Dear maintainer,

I've prepared an NMU for llvm-defaults (versioned as 0.51+nmu1). The diff
is attached to this message.

I took the liberty of uploading without delay, since the change should
be rather self-contained (famous last words...), and although not an RC
bug for this package, it has caused emscripten to fail to build for some
weeks now.

Regards.

 - Jonas

diff -Nru llvm-defaults-0.51/debian/changelog 
llvm-defaults-0.51+nmu1/debian/changelog
--- llvm-defaults-0.51/debian/changelog 2020-12-04 23:43:26.0 +0100
+++ llvm-defaults-0.51+nmu1/debian/changelog2020-12-19 17:10:28.0 
+0100
@@ -1,3 +1,12 @@
+llvm-defaults (0.51+nmu1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+
+  * Provide unversioned wasm-ld in llvm;
+closes: bug#976431
+
+ -- Jonas Smedegaard   Sat, 19 Dec 2020 17:10:28 +0100
+
 llvm-defaults (0.51) unstable; urgency=medium
 
   * Upload to unstable
diff -Nru llvm-defaults-0.51/debian/rules llvm-defaults-0.51+nmu1/debian/rules
--- llvm-defaults-0.51/debian/rules 2020-12-04 21:05:15.0 +0100
+++ llvm-defaults-0.51+nmu1/debian/rules2020-12-19 17:04:48.0 
+0100
@@ -178,7 +178,7 @@
llvm-dwp llvm-exegesis llvm-lib llvm-lto llvm-lto2 llvm-mca 
llvm-modextract \
llvm-mt llvm-objcopy llvm-opt-report llvm-pdbutil llvm-rc 
llvm-readelf \
llvm-readobj llvm-split llvm-stress llvm-strings llvm-strip 
llvm-undname \
-   llvm-xray sanstats opt \
+   llvm-xray sanstats opt wasm-ld \
; do \
dh_link -pllvm \
/usr/lib/llvm-$(PV_LLVM)/bin/$$bin \

Bug#970398: xfwm4: Since 4.14.5-1 I get a garbled desktop

[Elimar Riesebieter]

Control: fixed -1 4.14.6-1

Thanks
Elimar

-- 
  Never make anything simple and efficient when a way
  can be found to make it complex and wonderful ;-)

Bug#966152: lvm2: Build with libedit instead of readline5

[Bastian Germann]

On Tue, 29 Sep 2020 15:10:37 +0200 Bastian Germann 
 wrote:> > lvm2 depends on readline5 which 
is orphaned (#737301). The current

> readline is not license-compatible.
> 
> The enclosed patches make the package build with libedit instead which

> is a drop-in replacement for readline.

The next lvm version will have a --enable-editline option. Please change
the d/rules file to use it once you imported it. The
0002-d-control-build-depend-on-libedit-dev.patch will still be needed
with that change.


Alternatively, you can build-depend on the new libeditreadline-dev, 
which provides the readline programming interface but links with libedit2.

Bug#977562: systemd: Incorrect order of agetty arguments in serial-getty@ttyS0.service definition file

[Andreas Henriksson]

Control: tags -1 + moreinfo

On Wed, Dec 16, 2020 at 11:39:06PM +0100, Michael Biebl wrote:
> Am 16.12.20 um 20:49 schrieb MK:
> > Package: systemd
> > Version: 241-7~deb10u5
> > Severity: normal
[...]
> > Incorrect order of arguments to agetty in the serial-getty@ttyS0.service
> > unit file.
> > 
> > It is:
> > 
> > ExecStart=/sbin/agetty --autologin root -8 --keep-baud 115200,38400,9600 
> > ttyS0 xterm-256color
> > 
> > 
> > While it should be like:
> > 
> > ExecStart=/sbin/agetty --autologin root -8 --keep-baud ttyS0 115200 
> > xterm-256color
[...]
> According to the examples in man agetty, both should work.
> 
> Andreas, can you comment here?
> If what MK is saying, should the "EXAMPLE" section in man agetty be updated?
> 

I don't really have much prior knowledge about *getty, but in my past
experience with other util-linux tools it is often the case that
(likely for historical reasons/compatibility) the arguments that
doesn't come in a dash-form is attempted to be accepted in either
order based on guessing which one was specified. In my past experience
something that was guessable in the past might in later years become
sometimes impossible to correctly guess right, so sticking with
what synopsis describes is usually the safest as far as I'm concerned.

In the agetty case, the guessing is done here:
https://sources.debian.org/src/util-linux/2.36.1-2/term-utils/agetty.c/#L897

is_speed basically checks if the current argument only consists of
either 0-9 or ','.

It is not obvious to me how it could go wrong in the example originally
described in this bug report.

Please also note that for example sysvinit's inittab also uses getty
with arguments in both orders.

Simply it should work either way.

Please also note that the argument order is not the only thing changed.
It was also changed from specifying 3 speeds to only 1.

Maybe the real issue here is that line speed detection isn't working?
I'd appreciate if the bug reporter could dive a bit deeper into the
problem.

Regards,
Andreas Henriksson

Bug#973865: RFS: dhcpdump/1.8-3 [ITA] -- Capture dhcp-packets and show for easier checking and debugging

[Baptiste Beauplat]

Hi Peter,

On 12/15/20 8:54 AM, Peter Ji wrote:
> Thank you very much for such a careful review. The information you mentioned
>  was very helpful to new comer like me. Especially the list in the end.
> Thanks!

Glad to hear :)

> I tried to repacking dhcpdump as suggested, such as detailed changelog
> and modified other  d/* files in the latest upload.
> Although it may still have errors, I will continue to work on.

Alright, let's do another pass then.

d/changelog:
  - The update_befor_adoption patch has a spelling mistake
  - d/control Multi-arch field is not documented
  - On the block "Update the description of dhcpdump", why is there a
sub item? Shouldn't it be in the same sentence?
  - In the same block, you are missing a space before the bug info

d/control: looks good to me

d/copyright:
  - The first block does not need to enumerate all files. The wildcard
'*' can be use instead. All following entries will override that.
  - The license regarding the first block and `debian/*` is incorrect.
Only strsep.c uses the BSD-4-clause-UC.

d/rules:
  - You should use DEB_CFLAGS_MAINT_APPEND and DEB_LDFLAGS_MAINT_APPEND
instead of re-defining the flag yourself. See `man dpkg-buildflags`
and `man debhelper` for more info.
  - Most of the flag you use are already set by debhelper. You can play
with those by adding a _temporary_ echo $(CFLAGS) in the
debian/rules.
In your case, you should need only the -DHAVE_STRSEP (the rest is
either already defined or unecessary).
  - You have an extra space after DEB_CFLAGS_MAINT_APPEND
  - In debian/rules and in the Makefile, make and $(CC) are used. Since
there are no ./configure script, cross building the package will
fail trying to use make and cc instead of the correct targeted arch
tool. To workaround that, you should:
- Include /usr/share/dpkg/buildtools.mk at the begining of d/rules.
  That will correctly define MAKE and CC variables
- Replace make by $(MAKE) and add the CC variable on the make
  command line.

patches/000...:
  - The patch description does not describe precisely the changeset.
  - The patch description has a spelling mistake
  - Remove the <> char from the description. Those are used only in the
email address.

patches/001...:
  - You skip the install rule in debian/rules. Therefor, this patch is
not needed. Don't forget to remove the entry from d/changelog as
well.

patches/002...:
  - You have a extra space at the end of the line 37.
  - Remove the <> char from the description


> I know Debian's Gitlab But not familiar.  I will try to apply for access when 
> necessary.

Just so you know, it's open for anyone to register. You just need to
create an account and that it.

-- 
Baptiste Beauplat - lyknode



OpenPGP_signature
Description: OpenPGP digital signature

Bug#841255: [bts-link] source package liferea

[Lars Windolf]

On 18.12.20 05:37, Paul Wise wrote:

On Thu, 2020-12-17 at 21:18 +0100, Paul Gevers wrote:


Sub-optimal, but upstream decided to close the Debian bugs that I
forwarded. I don't think it makes sense to keep them open in the BTS
any longer.

Fair enough, I'll file new issues upstream if I see crashes again.



@Paul Gevers: if it helps your workflow, feel free to re-open the
tickets upstream.
The thing about crash ticket is that they are sometimes caused by used
libraries
and are race-prone and hard to reproduce and just get stale and clog up
the ticket
tracker. As a Debian maintainer you know it probably well :-)

Happy holidays!


Cheers,
Lars

Bug#977723: nss: please package recent version 3.60

[Carsten Schoenert]

Source: nss
Severity: wishlist

Hello Mike,

current beta version (85.0b1) of Thunderbird requires libnss3-dev at
version 3.60.
Please consider to update src:nss to the current version 3.60. Thanks!

Regards
Carsten

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

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

Bug#977701: gitlab: Missing assets, breaking some functionalities

[Pirate Praveen]

On Sat, Dec 19, 2020 at 8:08 pm, Pirate Praveen 
 wrote:
I think the issue is likely caused by incompatible version of 
postcss. I'm trying if updating postcss fixes the issue.


Some dependencies of node-css-loader need node-postcss 8 where as 
node-css-loader itself need an update to use node-postcss 8. So it will 
take a while to untangle this mess.


On the brighter side, we have jest packaged so in future we can detect 
such problems before they are uploaded (we did not have tests enabled 
in these pckages because jest was not packaged).

Bug#977722: polymake: man page mentions outdated file argument

[Joachim Zobel]

Package: polymake
Version: 4.1-4.1
Severity: minor

Dear Maintainer,

According to
https://polymake.org/doku.php/user_guide/tutorials/release/4.1/legacy
"In the version 4.0, the support for old command line mode has been dropped
completely."

man polymake:
-
   file PROPERTY | METHOD [ ... ]

  the  compatibility  mode with polymake <= 2.3: read the object
from the data file, print the
  properties or run the user methods
-

This is therefore outdated.

Sincerely,
Joachim



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

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

Versions of packages polymake depends on:
ii  libbliss2   0.73-4
ii  libc6   2.31-5
ii  libcdd0d094j-2
ii  libeantic0  0.1.8+ds-0.1
ii  libflint-2.6.3  2.6.3-3
ii  libgcc-s1   10.2.0-19
ii  libgmp102:6.2.1+dfsg-1
ii  libgomp110.2.0-19
ii  libmpfr64.1.0-3
ii  libnormaliz33.8.9+ds-0.1
ii  libpolymake-dev-common  4.1-4.1
ii  libppl141:1.2-8.1
ii  libstdc++6  10.2.0-19
ii  ninja-build 1.10.1-1
ii  polymake-common 4.1-4.1

Versions of packages polymake recommends:
ii  chromium   83.0.4103.116-3.1+b1
ii  gfan   0.6.2-2
ii  graphviz   2.42.2-4+b1
ii  xdg-utils  1.1.3-2

Versions of packages polymake suggests:
pn  povray   
ii  texlive-latex-extra  2020.20201129-1
ii  texlive-pictures 2020.20200925-1

-- no debconf information

Bug#977721: Opening a block device as a file using the 'file' driver is deprecated

[Michael Tokarev]

Control: tag -1 + moreinfo

19.12.2020 18:00, Michael Tokarev wrote:

19.12.2020 17:55, Marc Haber wrote:



   
   
 

This VM won't start any more with qemu 5.2, saying "Opening a block
device as a file using the file drive is deprecated". It unfortunately


Note also this is just a warning, qemu is definitely not giving up, it
just says this way to open a device WILL not work in some future, but it
does work now. And indeed it continues to work fine.  So it looks like
you missed something, some real reason for the domain to not start.

/mjt

Bug#977721: Opening a block device as a file using the 'file' driver is deprecated

[Michael Tokarev]

19.12.2020 17:55, Marc Haber пишет:

Package: qemu-system-x86
Version: 1:5.2+dfsg-2
Severity: important

I have my VM images on individually encrypted LVs so that I can
individually lock and unlock VMs. This is what my block device looks
like:
[1/5386]mh@drop:~ $ ls -al /dev/mapper/centos
lrwxrwxrwx 1 root root 8 Dez 19 15:47 /dev/mapper/centos -> ../dm-13
[2/5387]mh@drop:~ $ ls -al /dev/dm-13
brw-rw 1 root root 254, 13 Dez 19 15:47 /dev/dm-13
[3/5388]mh@drop:~ $

When I create a storage device in virt-manager, this results in the
following XML:
 
   
   
   
   
   
   
 

This VM won't start any more with qemu 5.2, saying "Opening a block
device as a file using the file drive is deprecated". It unfortunately
doesn't give a hint how block devices are to be opened, and it looks
like libvirt/virt-manager don't know either.

I don't know whether this is a libvirt, a virt-manager or a qemu issue,
but it should be properly reassigned and fixed (and conflicts added (and
conflicts added). In the man time, going back to qemu 5.1 has fixed the
issue for me.


Marc, what do you want we to do?

Should we revert qemu 5.2 to qemu 5.1 and stay there?

/mjt

Bug#977720: transition: http-parser

[Christoph Biedl]

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

Hello,

the http-parser library should see an update from 2.9.2 (unstable) and
2.9.3 (experimental) to 2.9.4. Now I am unsure whether this requires a
transition - at least the 2.9.3 upload did not lead to an auto- entry in
the transition page.

So please advise. If I may upload to unstable right away, just let me
know and close this bug. Else I'd follow-up with all the details needed.

In case the following sheds some light on the: The name of the binary
package ("libhttp-parser2.9") does not change.

Aside, I am aware 2.9.4-1 FTB in i386, fix ist already in the queue.

Kind regards,

Christoph


signature.asc
Description: PGP signature

Bug#977721: Opening a block device as a file using the 'file' driver is deprecated

[Marc Haber]

Package: qemu-system-x86
Version: 1:5.2+dfsg-2
Severity: important

I have my VM images on individually encrypted LVs so that I can
individually lock and unlock VMs. This is what my block device looks
like:
[1/5386]mh@drop:~ $ ls -al /dev/mapper/centos 
lrwxrwxrwx 1 root root 8 Dez 19 15:47 /dev/mapper/centos -> ../dm-13
[2/5387]mh@drop:~ $ ls -al /dev/dm-13 
brw-rw 1 root root 254, 13 Dez 19 15:47 /dev/dm-13
[3/5388]mh@drop:~ $ 

When I create a storage device in virt-manager, this results in the
following XML:

  
  
  
  
  
  


This VM won't start any more with qemu 5.2, saying "Opening a block
device as a file using the file drive is deprecated". It unfortunately
doesn't give a hint how block devices are to be opened, and it looks
like libvirt/virt-manager don't know either.

I don't know whether this is a libvirt, a virt-manager or a qemu issue,
but it should be properly reassigned and fixed (and conflicts added (and
conflicts added). In the man time, going back to qemu 5.1 has fixed the
issue for me.

Greetings
Marc


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

Kernel: Linux 5.10.1-zgws1 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), LANGUAGE=en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages qemu-system-x86 depends on:
ii  ipxe-qemu 1.0.0+git-20190125.36a4c85-5
ii  libaio1   0.3.112-8
ii  libc6 2.31-6
ii  libcapstone4  4.0.2-3
ii  libfdt1   1.6.0-1
ii  libgcc-s1 10.2.1-1
ii  libglib2.0-0  2.66.4-1
ii  libgnutls30   3.7.0-3
ii  libibverbs1   32.0-1+b1
ii  libjpeg62-turbo   1:2.0.5-1.1
ii  libnettle83.6-2
ii  libnuma1  2.0.12-1+b1
ii  libpixman-1-0 0.40.0-1
ii  libpmem1  1.10-1
ii  libpng16-16   1.6.37-3
ii  librdmacm132.0-1+b1
ii  libsasl2-22.1.27+dfsg-2
ii  libseccomp2   2.5.0-3+b1
ii  libslirp0 4.3.1-1
ii  libudev1  247.1-4
ii  liburing1 0.7-2
ii  libusb-1.0-0  2:1.0.24-2
ii  libvdeplug2   4.0.1-2
ii  libxendevicemodel14.14.0+88-g1d1d1f5391-2
ii  libxenevtchn1 4.14.0+88-g1d1d1f5391-2
ii  libxenforeignmemory1  4.14.0+88-g1d1d1f5391-2
ii  libxengnttab1 4.14.0+88-g1d1d1f5391-2
ii  libxenmisc4.144.14.0+88-g1d1d1f5391-2
ii  libxenstore3.04.14.0+88-g1d1d1f5391-2
ii  libxentoolcore1   4.14.0+88-g1d1d1f5391-2
ii  qemu-system-common1:5.2+dfsg-2
ii  qemu-system-data  1:5.2+dfsg-2
ii  seabios   1.14.0-2
ii  zlib1g1:1.2.11.dfsg-2

Versions of packages qemu-system-x86 recommends:
ii  ovmf 2020.11-2
pn  qemu-system-gui  
ii  qemu-utils   1:5.2+dfsg-2

Versions of packages qemu-system-x86 suggests:
ii  qemu-block-extra1:5.2+dfsg-2
ii  qemu-system-data [sgabios]  1:5.2+dfsg-2
pn  samba   
pn  vde2

-- no debconf information

Bug#977719: spotweb: CVE-2020-35545

[Salvatore Bonaccorso]

Source: spotweb
Version: 20130826+dfsg3-4
Severity: important
Tags: security upstream
Forwarded: https://github.com/spotweb/spotweb/issues/629
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for spotweb.

CVE-2020-35545[0]:
| Time-based SQL injection exists in Spotweb 1.4.9 via the query string.


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-2020-35545
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-35545
[1] https://github.com/spotweb/spotweb/issues/629

Regards,
Salvatore

Bug#973789: src:parsinsert: fails to migrate to testing for too long: FTBFS on armel, armhf, mips64el and ppc64el

[Adrian Bunk]

On Thu, Dec 03, 2020 at 08:45:15PM +0100, Andreas Tille wrote:
>...
> as you can see in the Debian bug the Build logs for mips64el[1] and
> others[2] the build time tests for parsinsert are failing.  From my
> naive perspective its basically a matter of rounding errors that might
> became visible with gcc-10 but it would be great if this could be fixed.

https://bugs.debian.org/964082 seems to be a variant of this problem,
different optimization options appear to have broken the tests already
with older gcc versions.

> Kind regards
> 
>  Andreas.

cu
Adrian

Bug#977701: gitlab: Missing assets, breaking some functionalities

[Pirate Praveen]

On Sat, Dec 19, 2020 at 7:39 pm, Pirate Praveen 
 wrote:



On Sat, Dec 19, 2020 at 5:32 pm, Pirate Praveen 
 wrote:
On Sat, 19 Dec 2020 07:03:18 +0100 Antoine Le Gonidec 
 wrote:
> I suspect this is related to a 404 error I get when trying to 
fetch /assets/webpack/components/app.vue

> There is indeed no such file generated in /usr/share/gitlab/public
>
> Reverting the gitlab package to 13.4.7-1~fto10+1 did not fix the 
issue.


We have started using the following native packages in this update. 
katex and mermaid change could be the reason, others seem simple.


I can also confirm reverting to 13.4.7-1~fto10+1 did not fix the 
issue.


I think the issue is likely caused by incompatible version of postcss. 
I'm trying if updating postcss fixes the issue.

Bug#977701: gitlab: Missing assets, breaking some functionalities

[Maximilian Stein]

I tried to revert the webpack.config.js and the package.json to the
version from 13.4.7-1 and re-ran postinst, but with no success either.



OpenPGP_signature
Description: OpenPGP digital signature

Bug#977718: node-ini: CVE-2020-7788

[Salvatore Bonaccorso]

Source: node-ini
Version: 1.3.5-1
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for node-ini.

CVE-2020-7788[0]:
| This affects the package ini before 1.3.6. If an attacker submits a
| malicious INI file to an application that parses it with ini.parse,
| they will pollute the prototype on the application. This can be
| exploited further depending on the context.


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-2020-7788
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-7788
[1] https://snyk.io/vuln/SNYK-JS-INI-1048974
[2] https://github.com/npm/ini/commit/56d2805e07ccd94e2ba0984ac9240ff02d44b6f1

Regards,
Salvatore

Bug#977717: podman: Images can't be run with non-root USER after upgrade to 2.1.1 due to wrong permissions of / inside the container

[Andreas Maus]

Package: podman
Version: 2.1.1+dfsg1-2
Severity: important
X-Debbugs-Cc: 023a305472eca90cd389e9dd4a9f30f71a6cf...@ypbind.de

Hello ^.*$

After the upgrade of podman to 2.1.1 container images
can't be run if the Dockerfile specify a non-root USER.

For instance:

maus@build:~$ podman --version
podman version 2.1.1

maus@build:~$ cat Dockerfile
FROM debian10:latest
USER maus
RUN id

maus@build:~$ podman pull 
docker://cthulhu.badphish.ypbind.de:5000/debian10:latest
Trying to pull docker://cthulhu.badphish.ypbind.de:5000/debian10:latest...
Getting image source signatures
Copying blob 3fa1b7b37d85 skipped: already exists
Copying blob c4d430d70570 skipped: already exists
Copying blob dd25a18fa133 skipped: already exists
Copying blob 8411b8221e04 skipped: already exists
Copying config 33eef1a794 done
Writing manifest to image destination
Storing signatures
33eef1a79457312c91e450012b1d24b775452ad43128a529ebf3930e30f71271

maus@build:~$ podman build -f Dockerfile
STEP 1: FROM debian10:latest
STEP 2: USER maus
--> Using cache cae2cdba5e97dbbc666e7f65b77e9f322a4a534d0b15faf60a2360b022afebc2
--> cae2cdba5e9
STEP 3: RUN id
ERRO[] container_linux.go:370: starting container process caused: exec: 
"/bin/sh": stat /bin/sh: permission denied
error running container: error creating container for [/bin/sh -c id]: : exit 
status 1
Error: error building at STEP "RUN id": error while running runtime: exit 
status 1

This is caused by the permissions of / after the image start:

maus@build:~$ podman run -t -i debian10:latest ls -ld /
drwx-- 22 root root 4096 Dec 19 14:30 /

This prevents access to every file or directory below / for non-root
users.

The previous version of podman - 2.0.6 - didn't show this behavior:

maus@debian11:~$ podman --version
podman version 2.0.6

maus@debian11:~$ podman pull 
docker://cthulhu.badphish.ypbind.de:5000/debian10:latest
Trying to pull docker://cthulhu.badphish.ypbind.de:5000/debian10:latest...
Getting image source signatures
Copying blob 8411b8221e04 skipped: already exists
Copying blob 3c5de6b97e3d skipped: already exists
Copying blob 3fa1b7b37d85 skipped: already exists
Copying blob c4d430d70570 skipped: already exists
Copying config 33eef1a794 done
Writing manifest to image destination
Storing signatures
33eef1a79457312c91e450012b1d24b775452ad43128a529ebf3930e30f71271

maus@debian11:~$ podman build -f Dockerfile
STEP 1: FROM debian10:latest
STEP 2: USER maus
--> Using cache 84e95d910544795f623c5ddc697244283945c271c14c352117dfff5d0cc4dc70
STEP 3: RUN id
uid=1000(maus) gid=1000(maus) 
groups=1000(maus),5(tty),24(cdrom),25(floppy),29(audio),30(dip),44(video),46(plugdev),108(netdev),114(nagios)
STEP 4: COMMIT

Because the containers starts with the correct permissions for /

maus@debian11:~$ podman run -t -i debian10:latest ls -ld /
drwxr-xr-x 22 root root 4096 Dec 19 14:38 /

The content of /etc/containers/containers.conf was not changed and it contains:

maus@build:~$ cat /etc/containers/containers.conf 
[containers]

[network]

[engine]
runtime = "crun"
runtime_supports_json = ["crun", "runc", "kata"]

[engine.runtimes]

There is no user specific configuration in $HOME/.config/containers/

I've looked at the changelog for 2.1 but didn't found any clue.

Sincerely yours,

Andreas Maus.

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

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

Versions of packages podman depends on:
ii  conmon   2.0.20-1
ii  containernetworking-plugins  0.8.7-1
ii  crun 0.15.1+dfsg-1
ii  golang-github-containers-common  0.26.3+ds1-2
ii  init-system-helpers  1.59
ii  libc62.31-5
ii  libdevmapper1.02.1   2:1.02.173-1
ii  libgpgme11   1.14.0-1+b2
ii  libseccomp2  2.5.0-3+b1
ii  runc 1.0.0~rc92+dfsg1-5

Versions of packages podman recommends:
ii  buildah 1.16.6+dfsg1-1
ii  fuse-overlayfs  1.2.0-1
ii  slirp4netns 1.0.1-1
ii  tini0.19.0-1
ii  uidmap  1:4.8.1-1

Versions of packages podman suggests:
pn  containers-storage  

-- no debconf information

Bug#977701: gitlab: Missing assets, breaking some functionalities

[Pirate Praveen]

On Sat, Dec 19, 2020 at 5:32 pm, Pirate Praveen 
 wrote:
On Sat, 19 Dec 2020 07:03:18 +0100 Antoine Le Gonidec 
 wrote:
> I suspect this is related to a 404 error I get when trying to fetch 
/assets/webpack/components/app.vue

> There is indeed no such file generated in /usr/share/gitlab/public
>
> Reverting the gitlab package to 13.4.7-1~fto10+1 did not fix the 
issue.


We have started using the following native packages in this update. 
katex and mermaid change could be the reason, others seem simple.


I can also confirm reverting to 13.4.7-1~fto10+1 did not fix the issue.

Bug#977701: gitlab: Missing assets, breaking some functionalities

[Antoine Le Gonidec]

On Sat, 19 Dec 2020 07:03:18 +0100 Antoine Le Gonidec 
 wrote:

Reverting the gitlab package to 13.4.7-1~fto10+1 did not fix the issue. I have 
yet to try a full update of the update I did that included this package, here 
are the details according to APT history:

Start-Date: 2020-12-18  22:00:20
Commandline: apt install gitlab node-autosize/buster-backports fonts-font-awesome/buster-backports node-uuid/buster-backports node-request/buster-backports   
Install: fonts-katex:amd64 (0.10.2+dfsg-4~bpo10+1, automatic), node-match-at:amd64 (0.1.1-1, automatic), katex:amd64 (0.10.2+dfsg-4~bpo10+1, automatic), libjs-katex:amd64 (0.10.2+dfsg-4~bpo10+1, automatic), node-mermaid:amd64 (8.7.0+ds+~cs27.17.17-2~bpo10+1, automatic)
Upgrade: fonts-font-awesome:amd64 (5.0.10+really4.7.0~dfsg-1, 5.0.10+really4.7.0~dfsg-4~bpo10+1), node-autosize:amd64 (4.0.2~dfsg1-3, 4.0.2~dfsg1-5~bpo10+1), node-request:amd64 (2.88.1-2, 2.88.1-5~bpo10+1), gitlab:amd64 (13.4.7-1~fto10+1, 13.4.7-2~fto10+1), node-uuid:amd64 (3.3.2-2, 8.3.2+~8.3.0-1~bpo10+1)  
Error: Sub-process /usr/bin/dpkg returned an error code (1)

End-Date: 2020-12-18  22:21:04


Reverting this update did not fix the issue, I ended up restoring a server 
backup prior to it.

This update is the only difference I can see between the restored backup and 
the situation triggering the JavaScript-related issues, so I guess it applies 
some change than is not reverted by going back to the previous package versions.



OpenPGP_signature
Description: OpenPGP digital signature

Bug#971583: New /var/log/tomcat9 permissions break logrotate

[Chris Hofstaedtler]

Control: tags -1 + confirmed
Control: severity -1 important
Control: found -1 tomcat9/9.0.41-1

Hi,

I've noticed the same problem on bulleye:

* Stefan Bühler  [201219 13:52]:
> logrotate fails with:
> 
> logrotate[5006]: error: skipping "/var/log/tomcat9/catalina.out" because 
> parent directory has insecure permissions (It's world writable or writable by 
> group which is not "root") Set "su" directive in config file to tell 
> logrotate which user/group should be used for rotation.

Raising severity to important as this causes the logrotate.service
unit to remain in failed state.

Best,
Chris

Bug#977467: CVE-2019-15605

[Salvatore Bonaccorso]

Hi,

On Sat, Dec 19, 2020 at 10:46:16AM +0100, Christoph Biedl wrote:
> Control: tags 977467 pending
> 
> Moritz Muehlenhoff wrote...
> 
> > https://nodejs.org/en/blog/vulnerability/february-2020-security-releases/
> > is for nodejs, but the underlying issue is in http-parser, which Debian's
> > nodejs uses. This is already fixed in experimental, if this can't be used
> > there's also an isolated patch at 
> > https://github.com/nodejs/http-parser/commit/7d5c99d09f6743b055d53fc3f642746d9801479b
> 
> Greetings,
> 
> to me, it seemed better to go forward. So I'll upload 2.9.4-1 to
> experimental in a few moments and trigger the transition then. Let me
> know if you prefer a different approach.

No sounds good if this will be possible.

> About stable (10/buster), according to security tracker it's affected as
> well. Shall I go the stable point release approach? I haven't checked
> anything there yet, though.

Indeed, as marked already as no-dsa (unless you object), so point
release update sounds good.

Regards,
Salvatore

Bug#965025: Acknowledgement (gpsshogi-data: data does not seem to be provided in the preferred format for modification)

[ydirson]

close 965025
thanks

upstream clarification from Daigo:

> We (as the upstream) created an opening book file and
> evaluation files in a statistical / machine learning
> way from a large amount of data with lots of machine
> power and tuning parameters. It was not our priority
> to develop an out-of-box environment of tools and data
> for exactly mirroring what we produced. However, it
> would be capable of power programmers to customize the
> binary files by reading and using APIs defined in OSL.
> Say, they could put more weight on Bishop or ban some
> moves in an opening position.

Bug#977639: bible-kjv: Possible GPL compliance problems

[Bastian Germann]

On Fri, 18 Dec 2020 00:01:10 +0100 Bastian Germann 
 wrote:> bible-kjv package claims to be 
GPLv2 licensed. One file has an "or
later" clause but some files seem to GPLv2-only. However, with the 
switch to readline6 (#553733), it uses a GPLv3 library. GPLv3 and 
GPLv2-only are known to be incompatible licenses, so please build with 
libedit instead. A patch is enclosed.


Instead of applying this patch, you can also build-depend on 
libeditreadline-dev, which allows to build with libedit while keeping 
the readline interface.

Bug#976901: nvidia-tesla-450-kernel-dkms: Fails to build DKMS kernel module on ppc64le 450.80.02

[Andreas Beckmann]

Control: severity -1 important

This bug should not cause nvidia-cuda-toolkit to be removed from testing...

Did you ever have a working kernel/driver/toolkit combination?

On 12/10/20 5:05 PM, Konstantinos Margaritis wrote:
> I just installed 5.8 from buster-backports along with tesla-440 driver
> and it seems to give slightly better results,the modules build and load,
> but similar errors in kernel:

You could try the kernel from Debian stable ...

IIRC you had two GPUs in that machine, could you try with only one
installed?

I seem to remember reading that Ubuntu on ppc64el is in cuda 11.x no
longer a combination supported by nvidia. That makes it a bit more
difficult to find a setup that is supposed to work. But if it actually
works in some RHEL/CentOS environment, why shouldn't we get it runnning
on Debian as well?

I only found this footnote in
https://docs.nvidia.com/cuda/archive/11.1.1/cuda-installation-guide-linux/index.html
  (4) Only Tesla V100 and T4 GPUs are supported for CUDA 11.2 on Arm64
(aarch64) POWER9 (ppc64le)

Andreas

Bug#977716: RFP: llhttp -- parser for HTTP messages

[Christoph Biedl]

Package: wnpp
Severity: wishlist

* Package name: llhttp
  Version : 3.0.0
  Upstream Author : Fedor Indutny 
* URL : https://github.com/nodejs/llhttp
* License : MIT
  Programming Lang: TypeScript, C
  Description : parser for HTTP messages

The http-parser library has declared unmaintained by upstream[1],
and this one here suggested as a solution to migrate to. Although
probably not a simple drop-in replacement, Debian should abandon
http-parser in favour of that one here in the long run.

However, I do not wish to do the maintainership on my own. There's a lot
of node.js involved, an area I don't feel competent do deal with.

Regards,

Christoph, maintainer of http-parser

[1] https://github.com/nodejs/http-parser/issues/522


signature.asc
Description: PGP signature

Bug#977715: dwarves - pahole fails to handle vmlinux on all 32bit arches

[Bastian Blank]

Package: dwarves
Version: 1.17-1
Severity: important

Linux can use pahole to generate BTF debugging info for embedding.  This
fails on what looks like all 32bit arches with segmentation fault:

| + printf   %-7s %s\n BTF .btf.vmlinux.bin.o
|   BTF .btf.vmlinux.bin.o
| + LLVM_OBJCOPY=objcopy pahole -J .tmp_vmlinux.btf
| Segmentation fault

See the complete build logs:

https://buildd.debian.org/status/fetch.php?pkg=linux=armel=5.10.1-1%7Eexp1=1608230767=0
https://buildd.debian.org/status/fetch.php?pkg=linux=i386=5.10.1-1%7Eexp1=1608216012=0

I haven't looked deeper what the linux build actually does.

Bastian

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

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

Versions of packages dwarves depends on:
ii  libc62.31-5
ii  libdw1   0.182-1
ii  libelf1  0.182-1
ii  zlib1g   1:1.2.11.dfsg-2

dwarves recommends no packages.

dwarves suggests no packages.

Bug#921187: Getting rid of rdepends on libxenmisc4.X so we can do backports

[Diederik de Haas]

On Tue, 5 Feb 2019 20:41:17 +0100 Hans van Kranenburg  wrote:
> ...led me here...
> 
> https://salsa.debian.org/qemu-team/qemu/commit/a6a863e912bf03bb321dead3a98c755951665ced

That commit added the do-not-link-everything-with-xen.patch 

That patch got removed in a commit named 'update for v4.1'.
https://salsa.debian.org/qemu-team/qemu/-/commit/9137f667a7ccbcf7441d878a9443fab142cfd907

But even today, 2020-12-19, there is still something in qemu which links 
to libxenmisc.
I don't know how, but I guess it should be possible to determine which 
part/function it is linking against and then see if that can be split off into 
a version independent package.

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

Bug#977656: [Pkg-zfsonlinux-devel] Bug#977656: zfs-dkms: Fail to build with 5.10 kernel with "error: ‘struct percpu_ref’ has no member named ‘count’"

[Christian Marillat]

On 19 déc. 2020 13:59, Aron Xu  wrote:

> Hi Christian,

Hi Aron,


[...]

> At the moment, we are working on an initial upload of 2.x release to
> experimental, I think all of these stuff will be able to land next
> week.

Thanks for the reply.

Christian

Bug#976318: u-boot: Style changes for the packaging

[Nicolas Boulenguez]

Source: u-boot
Followup-For: Bug #976318

Hello.
Please replace the previous commit list with the attached archive.
I have tested several configurations as described in the last commit
log, on current head (88022988) with all suggestions from bugs 976315
976316 976317 976318 applied.
dpkg-buildpackage, lintian and debdiff do not seem to complain.


u-boot-976318.tar.gz
Description: application/gzip

Bug#977693: gtk+3.0: Wayland primary selection interoperability with GTK clients on Plasma Desktop

[Simon McVittie]

Control: found -1 3.24.23-3
Control: notfound -1 3.24.24-1
Control: tags -1 + moreinfo

On Sat, 19 Dec 2020 at 02:06:49 +0100, Sandro Knauß wrote:
> currently it is impossible to use middle click pasting between Wayland 
> clients and GTK clients running on XWayland, like for example Chromium 
> and Firefox on Plasma Desktop.

Are you sure this isn't already present in testing and unstable's
libgtk-3-0? The primary-selection-unstable-v1 protocol was mentioned in
the upstream NEWS file for 3.24.24.

> Upstream GTK developer Emmanuele Bassi said that there are no more gtk3 
> dot releases planned (at least not before GTK 4.0 is released). 

That seems to be outdated information: GTK 4.0.0 has been released now
(I uploaded it to experimental NEW since it has a new SONAME and needs
a newer version of Pango), and a 3.24.24 point release also happened.

> Emmanuale recommends cherry-picking this patch from the gtk-3-24 stable 
> branch to distro packages:
> 
> https://gitlab.gnome.org/GNOME/gtk/-/commit/9a693c7228a88b76a007aed41b101d89d084cf9b

That's included in 3.24.24, in testing since 2020-12-14.

> To verify that the patch works:
> 1. Log into a Plasma Wayland session

I'll try to test this at some point, but it's very likely to be quicker
for a Plasma user to upgrade their GTK 3 version than it is for me to
install Plasma.

This is not a fully interoperable protocol until it's declared stable
by the Wayland developers, and the stable version is implemented by GTK,
Plasma, GNOME Shell, and any other relevant toolkits such as Qt. However,
it seems to be very similar to the older GTK-specific primary selection
interface (perhaps identical except for changing the names), so hopefully
having the GTK version, the standardized unstable version and a future
standardized stable version all exist in parallel for a few months/years
won't be a significant maintenance burden for the various projects
involved.

It would probably be pragmatic for Plasma to implement the GTK-specific
interface too, at least for a while, if they're as similar as they seem
to be from the GTK change - that would make sure it interoperates with
older GTK versions, for instance in Flatpak/Snap apps that are stuck on
an older runtime, apps from a Debian 10 chroot, or the Debian-10-based
Steam Runtime.

smcv

Bug#977701: gitlab: Missing assets, breaking some functionalities

[Pirate Praveen]

On Sat, 19 Dec 2020 07:03:18 +0100 Antoine Le Gonidec 
 wrote:
> I suspect this is related to a 404 error I get when trying to fetch 
/assets/webpack/components/app.vue

> There is indeed no such file generated in /usr/share/gitlab/public
>
> Reverting the gitlab package to 13.4.7-1~fto10+1 did not fix the 
issue.


We have started using the following native packages in this update. 
katex and mermaid change could be the reason, others seem simple.


diff --git a/debian/control b/debian/control
index 3c4b7f7a6..2aefd4a1f 100644
--- a/debian/control
+++ b/debian/control
@@ -357,7 +357,7 @@ Depends: ${shlibs:Depends}, ${misc:Depends},
 ruby-yajl (>= 1.4.1~),
 ruby-webauthn (>= 2.3~),
# packaged node modules - all node packages are not packaged yet
- node-autosize (>= 4.0~),
+ node-autosize (>= 4.0.2~dfsg1-5~),
 node-axios (>= 0.17.1~),
 node-babel7,
 node-babel-loader (>= 8.0~),
@@ -380,6 +380,7 @@ Depends: ${shlibs:Depends}, ${misc:Depends},
 node-exports-loader (>= 0.7~),
 node-imports-loader (>= 0.8~),
 node-file-loader (>= 5.0~),
+ node-font-awesome,
 node-fuzzaldrin-plus (>= 0.5~),
 node-glob (>= 7.1.6~),
 node-jed,
@@ -388,10 +389,14 @@ Depends: ${shlibs:Depends}, ${misc:Depends},
# Broken
# node-jquery.waitforimages,
 node-js-cookie,
+ node-js-yaml (>= 3.13.1~),
 node-jszip,
 node-jszip-utils,
+ node-katex,
 node-lodash (>= 4.17.15~),
 node-marked (>= 0.3~),
+ node-mermaid,
+ node-minimatch,
 node-mousetrap,
 node-pdfjs-dist,
# Include node-pikaday only after @gitlab/ui is accepted
@@ -408,6 +413,7 @@ Depends: ${shlibs:Depends}, ${misc:Depends},
 node-timeago.js (>= 4.0~),
 node-underscore (>= 1.9~),
 node-url-loader (>= 3.0~),
+ node-uuid (>= 8.1~),
 node-vue (>= 2.6.10~),
 node-vue-resource (>= 1.5.1~),
# Blocked by #927254

Bug#977714: icingaweb2-module-boxydash: Undefined variable: host

[Slavko]

Package: icingaweb2-module-boxydash
Version: 0.0.1+20160321-2
Severity: normal

After i install this package inside my LXC VM, the menu entry for Box Dashboard 
is created, but it
contains only error message:

Undefined variable: host

#0 
/usr/share/icingaweb2/modules/boxydash/application/views/scripts/index/index.phtml(52):
 Icinga\Application\ApplicationBootstrap->Icinga\Application\{closure}()
#1 /usr/share/php/Icinga/Web/View.php(248): include(String)
#2 /usr/share/icingaweb2/library/vendor/Zend/View/Abstract.php(877): 
Icinga\Web\View->_run()
#3 
/usr/share/icingaweb2/library/vendor/Zend/Controller/Action/Helper/ViewRenderer.php(904):
 Zend_View_Abstract->render()
#4 
/usr/share/icingaweb2/library/vendor/Zend/Controller/Action/Helper/ViewRenderer.php(925):
 Zend_Controller_Action_Helper_ViewRenderer->renderScript()
#5 
/usr/share/icingaweb2/library/vendor/Zend/Controller/Action/Helper/ViewRenderer.php(964):
 Zend_Controller_Action_Helper_ViewRenderer->render()
#6 
/usr/share/icingaweb2/library/vendor/Zend/Controller/Action/HelperBroker.php(272):
 Zend_Controller_Action_Helper_ViewRenderer->postDispatch()
#7 /usr/share/icingaweb2/library/vendor/Zend/Controller/Action.php(518): 
Zend_Controller_Action_HelperBroker->notifyPostDispatch()
#8 
/usr/share/icingaweb2/library/vendor/Zend/Controller/Dispatcher/Standard.php(303):
 Zend_Controller_Action->dispatch()
#9 /usr/share/php/Icinga/Web/Controller/Dispatcher.php(56): 
Zend_Controller_Dispatcher_Standard->dispatch()
#10 /usr/share/icingaweb2/library/vendor/Zend/Controller/Front.php(937): 
Icinga\Web\Controller\Dispatcher->dispatch()
#11 /usr/share/php/Icinga/Application/Web.php(300): 
Zend_Controller_Front->dispatch()
#12 /usr/share/php/Icinga/Application/webrouter.php(99): 
Icinga\Application\Web->dispatch()
#13 /usr/share/icingaweb2/public/index.php(4): require_once(String)
#14 {main}

I found simmilar looking error at 
https://github.com/morgajel/icingaweb2-module-boxydash/issues/1
but i lost in this issue...

Bug#977713: scid: Circular package dependency tk8.5 vs tk8.6 prevents scid from running

[fmeyer]

Package: scid
Version: 1:4.7.0+dfsg1-2
Severity: important

Dear Maintainer,

scid fails running with following message :

circular package dependency: attempt to provide Tk Ϻ£ü requires Tk 8.5
while executing
"package require Tk  8.5"
(file "/usr/games/scid" line 37)

(weird characters M£ü do appear in the error message).

   * What led up to the situation?

dist upgrade, might be linked to tk8.5 disappearing from sid.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

   tried to change requirements from 8.5 to 8.6 in /usr/games/scid, to
   no avail

   tried to build scid from source, introducing tips from
   https://sourceforge.net/p/scid/wiki/MacOSCatalina/ section 5.
   Package built successfully but that did not solve the circular dependency 
issue,
   and scid still does not launch.

   * What was the outcome of this action?
   * What outcome did you expect instead?

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


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

Kernel: Linux 5.9.0-4-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
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 scid depends on:
ii  libc6   2.31-5
ii  libstdc++6  10.2.0-23
ii  libtcl8.6   8.6.10+dfsg-1
ii  python3 3.9.0-4
ii  scid-data   1:4.7.0+dfsg1-2
ii  tcl 8.6.9+1+b1
ii  tk  8.6.9+1+b1
ii  zlib1g  1:1.2.11.dfsg-2

Versions of packages scid recommends:
ii  libtk-img  1:1.4.11+dfsg-1
ii  tcl-snack [libsnack2]  2.2.10.20090623-dfsg-10
ii  tcllib 1.20+dfsg-1
ii  tdom   0.9.1-1+b1
ii  texlive-games  2020.20201129-2

Versions of packages scid suggests:
pn  crafty  
pn  glaurung
pn  phalanx 
pn  scid-spell-data | scid-rating-data  
ii  stockfish   11-1+b1
pn  toga2   

-- no debconf information

Bug#977712: RM: node-jsv -- ROM; Unmaintained and orphaned

[Xavier Guimard]

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

node-jsv isn't maintained upstream for 8 years, useless and unmaintained
in Debian. It has no reverse dependencies and could be safely removed.

Bug#977648: Purging package noninteractively loops on 'No PAM profiles have been selected.'

[Josh Triplett]

On Sat, 19 Dec 2020 03:02:47 -0800 Josh Triplett  wrote:
> On Fri, 18 Dec 2020 08:54:42 -0500 Sam Hartman  wrote:
> > > "Josh" == Josh Triplett  writes:
> > Josh> I realize that this is an essential package, but it does have
> > Josh> a prerm and postrm script, and on a system with absolutely no
> > Josh> usage of PAM it should be posible to remove without
> > Josh> encountering an infinite loop like this.
> > 
> > I agree you shouldn't get the infinite loop.
> > I'm not at all convinced that you should be able to remove the package.
> > I think having the pam library installed without at least pam configs
> > that are guaranteed to fail is more of a security risk than I'm
> > comfortable with.
> > You would not be the first person who was sure they were not using PAM
> > only to discover that something under the covers was.
> > You may well be correct in your instance.
> > I've seen way too many people get this wrong over the years.
> 
> Perhaps the PAM packages, when removed, could ensure that a minimal
> "always deny everything" PAM configuration is in place, then?
> 
> (As an aside, it seems surprising that libpam fails open rather than
> failing closed. Would there be any way to fix that, without causing
> backwards compatibility issues?)

Actually, I just tested this in a new chroot, and it looks like current
PAM does correctly fail closed, with either no configuration or an empty
configuration. With no /etc/pam.conf or /etc/pam.d, login will fail with
"login: PAM Failure, aborting: Critical error - immediate abort". With
an empty /etc/pam.conf and no /etc/pam.d, login will just always say
"Login incorrect".

Is there still a fail-open scenario here?

Bug#976820: gitaly: use golang-gopkg-libgit2-git2go.v30

[Pirate Praveen]

Control: forwarded -1 https://gitlab.com/gitlab-org/gitaly/-/issues/2856

On Tue, 8 Dec 2020 10:55:52 +0100 Sebastian Ramacher 
 wrote:
> golang-gopkg-libgit2-git2go.v28 will be removed as part of the 
libgit2

> transition. So please switch to golang-gopkg-libgit2-git2go.v30-dev.

This updated got entangled in another update (licensee gem) which now 
included a new dependency that gitlab does not want to use as per 
https://gitlab.com/gitlab-org/gitaly/-/issues/2856#note_438114315 
though I can't see any new dependency in licensee. I have asked 
upstream for clarification.

Bug#977711: mate-screensaver ignores /etc/security/time.conf

[Armin Fuerst]

Package: mate-screensaver
Version: 1.20.3-3
Severity: normal

When having configured time restricted access for some users for all services
and the time restriction is working properly with login (testes with: lightdm,
su, console login), the user can still unlock the screen being locked with
mate-screensaver out of his allowed times. The configuration used for testing
this issue in /etc/security/time.conf is:

*;*;;Al0900-0901

pam_time is enabled through "common-auth" using:

account requiredpam_time.so



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

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

Versions of packages mate-screensaver depends on:
ii  dbus-x11  1.12.20-0+deb10u1
ii  libatk1.0-0   2.30.0-2
ii  libc6 2.28-10
ii  libcairo-gobject2 1.16.0-4
ii  libcairo2 1.16.0-4
ii  libdbus-1-3   1.12.20-0+deb10u1
ii  libdbus-glib-1-2  0.110-4
ii  libgdk-pixbuf2.0-02.38.1+dfsg-1
ii  libgl11.1.0-1
ii  libglib2.0-0  2.58.3-2+deb10u2
ii  libgtk-3-03.24.5-1
ii  libice6   2:1.0.9-2
ii  libmate-desktop-2-17  1.20.4-2
ii  libmate-menu2 1.20.2-1
ii  libmatekbd4   1.20.2-1
ii  libnotify40.7.7-4
ii  libpam0g  1.3.1-5
ii  libpango-1.0-01.42.4-8~deb10u1
ii  libpangocairo-1.0-0   1.42.4-8~deb10u1
ii  librda0   0.0.5-1
ii  libsm62:1.2.3-1
ii  libstartup-notification0  0.12-6
ii  libsystemd0   241-7~deb10u5
ii  libx11-6  2:1.6.7-1+deb10u1
ii  libxext6  2:1.3.3-1+b2
ii  libxklavier16 5.4-4
ii  libxss1   1:1.2.3-1
ii  libxxf86vm1   1:1.1.4-1+b2
ii  mate-desktop-common   1.20.4-2
ii  mate-screensaver-common   1.20.3-3
ii  mate-session-manager  1.20.2-1

Versions of packages mate-screensaver recommends:
ii  mate-power-manager  1.20.3-2

Versions of packages mate-screensaver suggests:
pn  rss-glx
pn  xscreensaver-data  

-- no debconf information

Bug#977648: Purging package noninteractively loops on 'No PAM profiles have been selected.'

[Josh Triplett]

On Fri, 18 Dec 2020 08:54:42 -0500 Sam Hartman  wrote:
> > "Josh" == Josh Triplett  writes:
> Josh> I realize that this is an essential package, but it does have
> Josh> a prerm and postrm script, and on a system with absolutely no
> Josh> usage of PAM it should be posible to remove without
> Josh> encountering an infinite loop like this.
> 
> I agree you shouldn't get the infinite loop.
> I'm not at all convinced that you should be able to remove the package.
> I think having the pam library installed without at least pam configs
> that are guaranteed to fail is more of a security risk than I'm
> comfortable with.
> You would not be the first person who was sure they were not using PAM
> only to discover that something under the covers was.
> You may well be correct in your instance.
> I've seen way too many people get this wrong over the years.

Perhaps the PAM packages, when removed, could ensure that a minimal
"always deny everything" PAM configuration is in place, then?

(As an aside, it seems surprising that libpam fails open rather than
failing closed. Would there be any way to fix that, without causing
backwards compatibility issues?)

Bug#906161: python-debianbts: get_bugs doesn't marshal usertags properly

[Julien Cristau]

I think it must have been something like this:

ut = debianbts.get_usertag('release.debian@packages.debian.org')
debianbts.get_bugs(package='release.debian.org', tag=['pu', 'buster'],
   usertags=ut)

https://salsa.debian.org/debbugs-team/debbugs/-/blob/master/lib/Debbugs/Bugs.pm#L117
describes the usertags param for get_bugs.

I get:

SoapFault: soap:Client: Application failed during request deserialization: 
not well-formed (invalid token) at line 5, column 304, byte 544 at 
/usr/lib/x86_64-linux-gnu/perl5/5.28/XML/Parser/Expat.pm line 487.
XML::Parser::Expat::parse(XML::Parser::Expat=HASH(0x55d36e3b48e8), 
" Hi Julien,
> 
> can you please provide a call to reproduce the error? According to the
> docs, the get_bugs has no `usertags` parameter:
> 
>   https://wiki.debian.org/DebbugsSoapInterface
> 
> 
> Cheers,
> 
> Bastian
> 
> 
> On Wed, 15 Aug 2018 09:57:42 +0200 Julien Cristau 
> wrote:
> > Package: python-debianbts
> > Version: 2.7.2
> > Severity: normal
> > Tags: patch
> > 
> > Hi,
> > 
> > marshaling for get_bugs' "usertags" param doesn't seem to work properly.
> > There's some special casing with _build_int_array_el for lists and
> > tuples but not for dicts.  The below seems to make it work.
> > 
> > Cheers,
> > Julien
> > 
> > diff --git a/debianbts/debianbts.py b/debianbts/debianbts.py
> > index d638e26..8816b7a 100644
> > --- a/debianbts/debianbts.py
> > +++ b/debianbts/debianbts.py
> > @@ -405,6 +405,13 @@ def get_bugs(*key_value):
> >  arg_name = 'arg' + str(arg_n)
> >  if isinstance(kv, (list, tuple)):
> >  _build_int_array_el(arg_name, method_el, kv)
> > +elif isinstance(kv, dict):
> > +el = method_el.add_child(arg_name)
> > +for k, v in kv.items():
> > +if isinstance(v, (list, tuple)):
> > +_build_int_array_el(k, el, v)
> > +else:
> > +el.marshall(k, v)
> >  else:
> >  method_el.marshall(arg_name, kv)
> >  
> > 
> > 
> 
> -- 
> Dr. Bastian Venthur  http://venthur.de
> Debian Developer venthur at debian org