Bug#993561: nmu: libsyntax-keyword-try-perl_0.24-1

[Andrius Merkys]

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

Hello,

I accidentally uploaded *_amd64.changes instead of *_source.changes.
Thus I need a binNMU on amd64 to unblock migration.

  nmu libsyntax-keyword-try-perl_0.24-1 . amd64 . unstable . -m "Rebuild
on buildd"

Thanks,
Andrius

Bug#989816: Duplicate

[Per Lundberg]

For reference: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=934372
#934372 - snapd WARNING: cgroup v2 is not fully supported yet, proceeding with 
partial confinement - Debian Bug report 
logs
Package: snapd Version: 2.42.1-1 Followup-For: Bug #934372 Control: block 
943981 by -1 Control: severity -1 minor Control: user 
pkg-systemd-maintain...@lists.alioth.debian.org Control: usertag -1 + cgroupv2 
Dear Maintainer, The situation improved in version 2.42.1, now we have $ snap 
run hello-world WARNING: cgroup v2 is not fully supported yet, proceeding with 
partial confinement Hello World!
bugs.debian.org


(Unsure about how to mark this as a duplicate with the Debian BTS, someone who 
knows how to do it is welcome to do it.)

From: Per Lundberg 
Sent: Thursday, September 2, 2021 14:15
To: 989...@bugs.debian.org <989...@bugs.debian.org>
Subject: Duplicate

This seems like a duplicate of #934372 to me.

Bug#993542: JuK starts muted every new session

[David Cortes]

By the way, this and bug 993543 go away if I downgrade JuK to 20.12
from stable while the rest of the KDE gears apps stay at 21.08.
On Fri, 2021-09-03 at 09:00 +0900, Norbert Preining wrote:
> Hi
> 
> > Every time I start JuK in a new plasma session, it now starts
> > muted,
> > despite having previously adjusted the volume. Editing
> > ~/.config/jukrc
> 
> I cannot reproduce this. Every time I start juk it is not muted.
> Maybe
> you have some special audio setup. I have manually muted it and
> restarted, to no avail, it always comes up unmuted.
> 
> Best
> 
> Norbert
> 
> --
> PREINING Norbert 
> https://www.preining.info
> Fujitsu Research  +  IFMGA Guide  +  TU Wien  +  TeX Live  + Debian
> Dev
> GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C
> DC13

Bug#993545: Kwin glitches when launched with compositing enabled

[David Cortes]

And this problem by the way goes away if I downgrade kwin to 5.20.5
from stable, so I doubt it's a mesa issue.
On Fri, 2021-09-03 at 09:03 +0900, Norbert Preining wrote:
> On Thu, 02 Sep 2021, David Cortes wrote:
> > Every time I start a new plasma session and kwin launches, it will
> > have
> > a series of graphical glitches which make the session unusable,
> 
> Sounds like a broken mesa stack or broken GPU. Reading the upstream
> bug
> also makes me wonder. I myself am running on amdgpu without any
> hitches.
> 
> Best
> 
> Norbert
> 
> --
> PREINING Norbert 
> https://www.preining.info
> Fujitsu Research  +  IFMGA Guide  +  TU Wien  +  TeX Live  + Debian
> Dev
> GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C
> DC13

Bug#993542: JuK starts muted every new session

[David Cortes]

The only special setup that I have is a USB sound card which I use as
the default output device. If I remove this sound card (leaving only
the default laptop speakers) the problem still persists however.
On Fri, 2021-09-03 at 09:00 +0900, Norbert Preining wrote:
> Hi
> 
> > Every time I start JuK in a new plasma session, it now starts
> > muted,
> > despite having previously adjusted the volume. Editing
> > ~/.config/jukrc
> 
> I cannot reproduce this. Every time I start juk it is not muted.
> Maybe
> you have some special audio setup. I have manually muted it and
> restarted, to no avail, it always comes up unmuted.
> 
> Best
> 
> Norbert
> 
> --
> PREINING Norbert 
> https://www.preining.info
> Fujitsu Research  +  IFMGA Guide  +  TU Wien  +  TeX Live  + Debian
> Dev
> GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C
> DC13

Bug#993545: Kwin glitches when launched with compositing enabled

[David Cortes]

Tried downgrading all the mesa packages to the ones in stable (as of
now that is mesa 20.3.5-1), with which kwin (from stable, version
5.20.5) was previously working correctly in this same setup, but the
problem persists.

The GPU still works as expected with a live CD image of some other
distro such as opensuse.
On Fri, 2021-09-03 at 09:03 +0900, Norbert Preining wrote:
> On Thu, 02 Sep 2021, David Cortes wrote:
> > Every time I start a new plasma session and kwin launches, it will
> > have
> > a series of graphical glitches which make the session unusable,
> 
> Sounds like a broken mesa stack or broken GPU. Reading the upstream
> bug
> also makes me wonder. I myself am running on amdgpu without any
> hitches.
> 
> Best
> 
> Norbert
> 
> --
> PREINING Norbert 
> https://www.preining.info
> Fujitsu Research  +  IFMGA Guide  +  TU Wien  +  TeX Live  + Debian
> Dev
> GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C
> DC13

Bug#993560: FTBFS on arch-any

[Daniel Baumann]

Package: linux
Version: 5.14-1~exp1
Severity: serious

Hi,

unfortunately the 5.14-1~exp1 upload failed to build on all 
architectures (except for 'all').


Regards,
Daniel

---snip---
make[5]: Leaving directory '/<>/tools/perf'
make[4]: Leaving directory '/<>/tools/perf'
rm -f /<>/debian/linux-perf-5.14/usr/bin/trace_5.14
mkdir -p /<>/debian/linux-perf-5.14/usr/share/bash-completion/
mv /<>/debian/linux-perf-5.14/etc/bash_completion.d \

/<>/debian/linux-perf-5.14/usr/share/bash-completion/completions
rmdir --ignore-fail-on-non-empty /<>/debian/linux-perf-5.14/etc
cd /<>/debian/linux-perf-5.14 && ! find \! -type d \! -path 
'*[_-]5.14*' | grep .

./usr/include/perf/perf_dlfilter.h
make[3]: *** [/<>/debian/rules.d/tools/perf/Makefile:57: 
install] Error 1
make[3]: Leaving directory 
'/<>/debian/build/build-tools/tools/perf'

make[2]: *** [debian/rules.real:730: install-perf] Error 2
make[2]: Leaving directory '/<>'
make[1]: *** [debian/rules.gen:34: binary-arch_amd64_real] Error 2
make[1]: Leaving directory '/<>'
make: *** [debian/rules:43: binary-arch] Error 2
dpkg-buildpackage: error: debian/rules binary-arch subprocess returned 
exit status 2

---snap---

Bug#993559: ganeti-3.0 unable to remove a dpkg-divert during postrm when 2.16 is still there

[Gabriel Filion]

Package: ganeti-3.0
Version: 3.0.1-2
Severity: normal

Hello,

I've just performed an upgrade of a ganeti cluster from buster+2.16 to
bullseye+3.0 and hit a problem during the upgrade.

The procedure that I used was to:

 1. install ganeti 3.0 from buster-backports and upgrade the cluster
 2. run OS upgrade from buster to bullseye (I had not removed ganeti 2.16)

During the upgrade to bullseye, ganeti was upgraded from the 3.0 backports
package to the same one from bullseye. At that point, dpkg stopped with an
error. Running "apt -f install" to fix the situation did not clear things up.
Running "apt purge ganeti-2.16 ganeti-haskell-2.16 ganeti-htools-2.16" was
jammed on a conflict of configuration files with 3.0:

# apt -f install
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following packages were automatically installed and are no longer required:
  at-spi2-core bsdmainutils libapt-inst2.0 libevent-core-2.1-6
  libevent-pthreads-2.1-6 libhogweed4 libnftables0 libprocps7 libreadline5
  python3-asn1crypto python3.7 python3.7-minimal
Use 'apt autoremove' to remove them.
The following additional packages will be installed:
  ganeti-3.0
The following packages will be upgraded:
  ganeti-3.0
1 upgraded, 0 newly installed, 0 to remove and 497 not upgraded.
323 not fully installed or removed.
Need to get 0 B/876 kB of archives.
After this operation, 0 B of additional disk space will be used.
Do you want to continue? [Y/n]
Reading changelogs... Done
Preconfiguring packages ...
(Reading database ... 64433 files and directories currently installed.)
Preparing to unpack .../ganeti-3.0_3.0.1-2_all.deb ...
Unpacking ganeti-3.0 (3.0.1-2) over (3.0.1-1~bpo10+1) ...
Removing 'diversion of /usr/share/ganeti/2.16/ganeti/utils/version.py to 
/usr/share/ganeti/2.16/ganeti/utils/version.py.orig by ganeti-3.0'
dpkg-divert: error: rename involves overwriting 
'/usr/share/ganeti/2.16/ganeti/utils/version.py' with
  different file '/usr/share/ganeti/2.16/ganeti/utils/version.py.orig', not 
allowed
dpkg: warning: old ganeti-3.0 package post-removal script subprocess returned 
error
exit status 2
dpkg: trying script from the new package instead ...
Removing 'diversion of /usr/share/ganeti/2.16/ganeti/utils/version.py to 
/usr/share/ganeti/2.16/ganeti/utils/version.py.orig by ganeti-3.0'
dpkg-divert: error: rename involves overwriting 
'/usr/share/ganeti/2.16/ganeti/utils/version.py' with
  different file '/usr/share/ganeti/2.16/ganeti/utils/version.py.orig', not 
allowed
dpkg: error processing archive 
/var/cache/apt/archives/ganeti-3.0_3.0.1-2_all.deb (--unpack):
 new ganeti-3.0 package post-removal script subprocess returned error exit 
status 2
Removing 'diversion of /usr/share/ganeti/2.16/ganeti/utils/version.py to 
/usr/share/ganeti/2.16/ganeti/utils/version.py.orig by ganeti-3.0'
dpkg-divert: error: rename involves overwriting 
'/usr/share/ganeti/2.16/ganeti/utils/version.py' with
  different file '/usr/share/ganeti/2.16/ganeti/utils/version.py.orig', not 
allowed
dpkg: error while cleaning up:
 new ganeti-3.0 package post-removal script subprocess returned error exit 
status 2
Errors were encountered while processing:
 /var/cache/apt/archives/ganeti-3.0_3.0.1-2_all.deb
needrestart is being skipped since dpkg has failed
E: Sub-process /usr/bin/dpkg returned an error code (1)


In order to get out of that situation, we had to modify the postrm script in
/var/lib/dpkg/info/ganeti-3.0.postrm to comment out the dpkg-diver --remove
command. That permitted the package to finish upgrading and the os upgrade to
complete. Once the upgrade was completed, I was able to purge ganeti 2.16 (and
I had to manually remove the diversion that was left behind)

I'm guessing this happened because the ganeti 2.16 packages were still in
place. But it was a situation quite difficult to work around of. I'm wondering
if something can be done to avoid this situation.

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

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

Versions of packages ganeti-3.0 depends on:
ii  adduser3.118
pn  bridge-utils   
ii  debconf [debconf-2.0]  1.5.77
pn  fping  
ii  iproute2   5.13.0-2
pn  iputils-arping 
ii  libcap2-bin1:2.44-1
ii  lvm2   2.03.11-2.1
ii  openssh-client 1:8.4p1-6
ii  openssh-server 1:8.4p1-6
ii  openssl1.1.1l-1
ii  python33.9.2-3
pn  python3-bitarray   
pn  python3-openssl
ii  python3-paramiko   2.7.2-1
ii  python3-psutil 5.8.0-1
ii  python3-pycurl 

Bug#993558: RFA: nomad -- distributed, highly available, datacenter-aware scheduler

[Dmitry Smirnov]

Package: wnpp
Severity: normal
X-Debbugs-CC: team+pkg...@tracker.debian.org
Control: affects -1 nomad-driver-podman nomad-driver-lxc

Nomad needs new maintainer.

I'm disengaging from Nomad ecosystem and reducing my dependency on
this technology. Nomad is a (somewhat) lightweight alternative to
Kubernetes and Nomad is especially cool due to its integration with
Consul for services auto-discovery. Nomad deserves more care that
I can currently provide.

Maintaining this package requires time and skills. Please only adopt this
package if you will have enough time and attention to work on it.

If you want to be the new maintainer, please see [1] for detailed 
instructions how to adopt a package properly.

[1]: https://www.debian.org/devel/wnpp/index.html#howto-o

-- 
Regards,
 Dmitry Smirnov
 GPG key : 4096R/52B6BBD953968D1B

---

A patriot must always be ready to defend his country against his government.
 -- Edward Abbey

---

https://stopMedicalDiscrimination.org/


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

Bug#907051: Finding rough consensus on level of vendoring for large upstreams

[Paul Wise]

On Thu, Sep 2, 2021 at 10:39 PM Phil Morrell wrote:

> Over this last year there seems to have been a noticeable divergence of
> maintainer opinion, on what has become known as vendoring

Embedded copies of code/etc have downsides ...

https://wiki.debian.org/EmbeddedCopies

> It is my reading of the situation that not only has this practice become
> more prevalent across multiple ecosystems since 2008

... but there are many many copies in Debian and they are not going
away upstream.

> [security-tracker]: 
> https://salsa.debian.org/security-tracker-team/security-tracker/-/blob/master/data/embedded-code-copies

Side note: This file is very much outdated, new copies are introduced
all the time and old copies get removed. This has always been the case
and it always will be.

So we need to cope with the consequences of this change toward
embedding in the upstream FLOSS ecosystems.

Personally, my recommendations are that:

Debian package maintainers could investigate upstream tarballs for
embedded copies before each upload containing a new/changed upstream
tarball.

Debian package maintainers could talk to upstream about removing
embedded copies and replacing them with dependencies.

Debian package maintainers could talk to upstream about upstreaming
changes in modified embedded copies, removing the embedded copies and
replacing them with dependencies.

Debian package maintainers could use Files-Excluded or `rm -r` in
debian/rules to ensure that embedded copies are not used by the build.

Debian package maintainers could add hints to the source package about
which embedded copies are definitely used.

Debian security tracker could remove the perpetually outdated list of
embedded copies.

Debian security issue investigators could search the archive for
similar or duplicate code (using the tools listed on the above wiki
page), investigate the build logs for each package found and determine
which packages are affected. This is a lot of work, but given the
level of embedding we already have, it is already necessary.

Also, the issue of static linking is similar; it is here, it isn't
going away and so now we have to cope with it and the problems it
causes are similar to embedded copies.

https://wiki.debian.org/StaticLinking

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Bug#993557: ITP: gnome-shell-extension-pop-shell -- keyboard-driven layer for GNOME with tiling window management

[Dan Bungert]

Package: wnpp
Severity: wishlist
Owner: Dan Bungert 
X-Debbugs-Cc: debian-de...@lists.debian.org, danielbung...@gmail.com

* Package name: gnome-shell-extension-pop-shell
  Version : 1.2.0
  Upstream Author : System76 
* URL : https://github.com/pop-os/shell
* License : GPLv3
  Programming Lang: JavaScript, Rust
  Description : keyboard-driven layer for GNOME with tiling window 
management

Pop Shell is a keyboard-driven layer for GNOME Shell which allows for quick
and sensible navigation and management of windows. The core feature of Pop
Shell is the addition of advanced tiling window management.

Bug#993556: O: nomad-driver-lxc -- Nomad LXC driver plugin

[Dmitry Smirnov]

Package: wnpp
Severity: normal
X-Debbugs-CC: team+pkg...@tracker.debian.org
Control: affects -1 src:nomad

"nomad-driver-lxc" needs new maintainer.
I'm disengaging from Nomad ecosystem and therefore giving away
Nomad-related packages. Please take care of Nomad LXC integration
if it is important to you.

If you want to be the new maintainer, please see [1] for detailed 
instructions how to adopt a package properly.

[1]: https://www.debian.org/devel/wnpp/index.html#howto-o

-- 
Regards,
 Dmitry Smirnov
 GPG key : 4096R/52B6BBD953968D1B

---

Freedom is the freedom to say that two plus two make four. If that is
granted, all else follows.
 -- George Orwell

---

"Increased Risk of Noninfluenza Respiratory Virus Infections Associated
With Receipt of Inactivated Influenza Vaccine".
 -- https://pubmed.ncbi.nlm.nih.gov/22423139/


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

Bug#993555: O: nomad-driver-podman -- Nomad taskdriver for Podman containers

[Dmitry Smirnov]

Package: wnpp
Severity: normal
X-Debbugs-CC: team+pkg...@tracker.debian.org
Control: affects -1 nomad

"nomad-driver-podman" needs new maintainer. I'm no longer trying to
run Podman containers under Nomad and I hope someone else will have
a better luck with it. The groundwork has been done and perhaps only
maintenance and maturing of this plugin upstream can help in the long
term.

Maintaining this package requires time and skills. Please only adopt this
package if you will have enough time and attention to work on it.

If you want to be the new maintainer, please see [1] for detailed 
instructions how to adopt a package properly.

[1]: https://www.debian.org/devel/wnpp/index.html#howto-o

-- 
Regards,
 Dmitry Smirnov
 GPG key : 4096R/52B6BBD953968D1B

---

Scientific education for the masses will do little good, and probably a lot
of harm, if it simply boils down to more physics, more chemistry, more
biology, etc to the detriment of literature and history. Its probable
effect on the average human being would be to narrow the range of his
thoughts and make him more than ever contemptuous of such knowledge as he
did not possess.
 -- George Orwell

---

Since April 2020, Influenza is no longer reported in Australia and world-wide:
  https://apps.who.int/flumart/Default?ReportNo=10
  https://www.immunisationcoalition.org.au/news-data/influenza-statistics/


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

Bug#993554: O: cakephp -- rapid application development framework for PHP

[Dmitry Smirnov]

Package: wnpp
Severity: normal
X-Debbugs-CC: pkg-php-p...@lists.alioth.debian.org, b...@l8r.net, x...@rxsoft.eu

Package "cakephp" needs new maintainer.

Although obsolete v2 is still supported upstream, it is currently
two major releases behind.

If you want to be the new maintainer, please see [1] for detailed 
instructions how to adopt a package properly.

[1]: https://www.debian.org/devel/wnpp/index.html#howto-o

-- 
Regards,
 Dmitry Smirnov
 GPG key : 4096R/52B6BBD953968D1B

---

Freedom is the freedom to say that two plus two make four. If that is
granted, all else follows.
 -- George Orwell

---

Corman-Drosten review report: understanding PCR testing fraud.
 -- https://cormandrostenreview.com/


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

Bug#993550: gtk4: gsk repeat, repeat-negative-coords tests fail with ngl renderer on mips*el

[YunQiang Su]

Simon McVittie  于2021年9月3日周五 上午7:21写道：
>
> Source: gtk4
> Version: 4.4.0+ds1-3
> Severity: normal
> Tags: upstream
> X-Debbugs-Cc: debian-m...@lists.debian.org
> Forwarded: https://gitlab.gnome.org/GNOME/gtk/-/issues/4228
>
> GTK 4 has a new scene-graph-based rendering model, "GSK", with an OpenGL
> preferred implementation and a Cairo fallback. Its regression tests draw
> various combinations of "render nodes" and check the results against
> reference PNG images.
>
> When using the "new" OpenGL renderer, "ngl", there's a weird rendering
> glitch on mips*el on two tests involving repeating a pattern: the top
> left pixel in each 2x2 block is darker than the other three.
> For more details and comparison images:
> https://gitlab.gnome.org/GNOME/gtk/-/issues/4228
>
> Is there anything unusual about the OpenGL implementation on mips*el
> that would cause this sort of thing? It seems to be using Mesa swrast_dri.so
> (which I think is llvmpipe?), the same as any other machine without a GPU.
>
> The "old" OpenGL renderer, "gl", does not seem to suffer from this - but
> it is no longer the default, has been deleted in newer upstream versions,
> and crashes in two (unrelated) tests on mipsel, so I'm going to disable
> testing for "gl" in the next upload to avoid wasting machine resources and
> developer time on it.
>
> I'm going to skip these two tests on mips*el. I don't know what practical
> effect this will have on GTK applications; I would recommend that people
> who are interested in GUIs on mips*el should try the gtk-4-examples package
> when mips*el builds become available, and find out.
>

Thank you. We will dig it.
We (CIP United) are taking care about MIPS ecosystem, and feel free to contact
use for any MIPS problems.

> smcv
>


-- 
YunQiang Su

Bug#993539: [Pkg-zsh-devel] Bug#993539: "functions/Misc.zwc" isn't compiled from the bundled source files

[Axel Beckert]

Control: retitle -1 zsh: Modifying HELPDIR comes too late, doesn't catch .zwc 
files
Control: tag -1 + confirmed

Hi Leo,

Leo Gama wrote:
> Subject: "functions/Misc.zwc" isn't compiled from the bundled source files

Sorry, but that's clearly not true: Since zsh_5.8.orig.tar.xz does not
contain any .zwc file, all .zwc files in the binary packages can't be
anything else than compiled from the bundled source at package build
time.

> If I try to call "run-help" at a ZSH prompt, it reports:
> > $ run-help
> > There is no list of special help topics available at this time.

Can confirm that, though.

> And trying to use it to see the help text for any built-in command just
> opens a man page for zsh...
> 
> Turns out that the default HISTDIR (which is wrong) in the file that
> contains the bytecode compiled version of "run-help" is different from the
> default in the source code "run-help" file:
> > $ grep 'HELPDIR:-/' /usr/share/zsh/functions/Misc/run-help
> > local HELPDIR=${HELPDIR:-/usr/share/zsh/help}
> > $ strings /usr/share/zsh/functions/Misc.zwc | grep 'HELPDIR:-/'
> > HELPDIR:-/usr/share/zsh/5.8/help
> > HELPDIR:-/usr/share/zsh/5.8/help

Hrm, yes, but this is caused by this sed call in debian/rules:

  # Doesn't this need to go before we zcompile stuff into .zwc files? -- Axel
sed -i -e 's,^local HELPDIR=.*,local 
HELPDIR=$${HELPDIR:-/usr/share/zsh/help},; s,:-more,:-/usr/bin/pager,;' \
debian/zsh-common/usr/share/zsh/functions/Misc/run-help
sed -i -e '1!b;s:^#!.*[ /]zsh:#!/bin/zsh:;s#/usr/local/bin#/usr/bin#;' \
`find debian/zsh-common/usr/share/zsh/functions -type f`

Actually your issue is already mentioned in form of the question in
the comment in front of that rule. Or in other words: Your bug report
just answered that question with "yes". :-)

Retitling the bug report accordingly.

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

Bug#907051: Finding rough consensus on level of vendoring for large upstreams

[Jonas Smedegaard]

Quoting Phil Morrell (2021-09-03 03:30:04)
> On Fri, Sep 03, 2021 at 02:46:20AM +0200, Jonas Smedegaard wrote:
> > First of all, thanks for compiling the list of reasonings.
> 
> Thanks for taking the time to read through it, I was hoping it would 
> be a useful observation.
> 
> > I get the impression that you are framing current state of embedding 
> > as a generally good thing to do, and if I understand that correctly 
> > then I disagree with it.
> 
> ish? I mostly tried to document current practice rather than have an 
> opinion on it being good. I do think that the evidence of multiple 
> independent maintainer teams coming to similar conclusions on the 
> basis of lack of user benefit and drag on new version velocity 
> indicates the positive side.
> 
> I believe, based on only a day's investigation, that you are in the 
> minority here. I don't mean that as a bad thing - 1/3 of DDs 
> disagree(d) with offering non-free alongside main - but I'd like to 
> hear why you think the maintainers I gave as examples should use their 
> Debian time to unvendor everything?

I do not think that those maintainers you gave as example should do 
differently.

My point is that those you gave as example are *exceptions* to a general 
practice in Debian of _avoiding_ embedding.


> > I suspect that it helps if separating reasons for _encouraging_ 
> > embedding (tiny upstream projects and deeply integrated sets of 
> > upstreams, I guess) from reasons for _discouraging_ embdding (all 
> > other cases, I guess).
> 
> I think the expanded points I gave empower maintainers to make the 
> best decision for their own packages. By laying out the permitted 
> reasons clearly, it's implied other reasons are not valid, but there's 
> probably something I haven't thought of.
> 
> However #907051 also wanted more background on _why_ one might choose 
> one way or the other, so please do elaborate on this if you can.

I am very worried about how complex node-* packages in Debian have 
become since ftpmasters explicitly stated a not-too-small rule and we 
began more aggressively embedding.  E.g. version of each embedded 
project is hidden by default, and those packages manually adding virtual 
packages has no mechanism to ensure that versions don't jump backwards 
or disappear due to a typos.


 - 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#992692: general: Use https for {deb,security}.debian.org by default

[Paul Wise]

On Thu, Sep 2, 2021 at 9:06 PM Ansgar wrote:

> Accessing www.debian.org will also not work on such systems (and unlike
> deb.d.o that does not even offer non-https). It's not Debian's problem.

The Tor onion services offer alternatives to the https PKI:

https://onion.debian.org/

> Is replacing deb.d.o by a non-CDN feasible?

security.d.o mirrors were getting overwhelmed after Linux kernel
updates, which is why that switched to the Fastly CDN, so probably
not. Also, the entire point of the deb.d.o domain is that it be backed
by a CDN.

httpredir.d.o was an alternative CDN-like thing that was based on HTTP
redirects to the mirror network. It had lots of problems, but now that
we have a mirror checker and zzz-dists, perhaps it could work better.
The mirror:// method in apt has probably improved since then too.
Maybe http redirects to local mirrors could be feasible again, but it
would take a lot of work.

https://mirror-master.debian.org/status/mirror-hierarchy.html

> As far as I know there is also at least https://cdn-aws.deb.debian.org/
> if you don't like Fastly.

And there are other CDNs that could potentially be used.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Bug#991341: guake: apt progress bar distorted on Guake after hide/unhide

[Awtul]

Package: guake
Version: 3.6.3-2
Followup-For: Bug #991341



Well, it seems like the 'apt' progress bar and the 'needrestart' advise being 
dostorted is a bug
of 'apt' not of 'guake' because I had the same problems on 'tilda'.

Bug#993343: OpenLDAP 2.5 FTBFS on GNU/Hurd: MAXPATHLEN undeclared

[Ryan Tandy]

Control: tag -1 fixed-upstream

https://bugs.openldap.org/show_bug.cgi?id=9659 has also been fixed. Now 
upstream git master builds fine on hurd-i386, as does a 2.5 package with 
the relevant fixes applied.


back-mdb even passes the first few tests, but still fails on 
test008-concurrency...

Bug#993553: ITP: myst-parser -- rich and extensible flavor of Markdown meant for technical documentation and publishing

[Emmanuel Arias]

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

* Package name: myst-parser
  Version : 0.15.2
  Upstream Author : Executable Book Project 
* URL : https://github.com/executablebooks/MyST-Parser

* License : Expat
  Programming Lang: Python
  Description : rich and extensible flavor of Markdown meant for
technical documentation
and publishing
.
MyST is a flavor of markdown that is designed for simplicity, flexibility,
and extensibility. It contains
an extended CommonMark-compliant parser using markdown-it-py, as well as a
Sphinx extension
that allows you to write MyST Markdown in Sphinx.
.
I plan to maintain it under the DPT umbrella.

Chers,
Emmanuel

Bug#993552: correction of upstream author

[BenTheTechGuy]

Correction: Upstream Author should be Avery Murray ,
instead of Ben Westover , who is the maintainer.

Bug#993552: RFS: proton-caller/2.3.2-1 [ITP] -- Run any Windows program through Proton

[Ben Westover]

Package: sponsorship-requests
Severity: wishlist
X-Debbugs-Cc: kwestover...@gmail.com

Dear mentors,

I am looking for a sponsor for my package "proton-caller":

* Package name: proton-caller
  Version : 2.3.2
  Upstream Author : Ben Westover 
* URL : https://github.com/caverym/proton-caller/
* License : GPL-3+
  Programming Lang: Rust
  Description : Run any Windows program through Proton

It builds those binary packages:

  proton-caller - Run any Windows program through Proton

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

  https://mentors.debian.net/package/proton-caller/

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

  dget -x 
https://mentors.debian.net/debian/pool/main/p/proton-caller/proton-caller_2.3.2-1.dsc

Regards,
-- 
  Ben Westover

Bug#981446: Possible adoption of logcheck

[Hannes von Haugwitz]

Hi Jose,

On Mon, Aug 30, 2021 at 07:58:21PM +0100, Jose M Calhariz wrote:
> I am a user of logckeck as I use on all my machines that I sysadmin
> and I maintain some packages on Debian like for example at and amanda.
> 
> As now I would like to offer my help to package and fix logcheck as a
> learning experience for a possibility in the future to be the
> maintainer of logcheck.

This is great news!

The logcheck VCS repo is in the `debian` group on salsa.debina.org[0];
so (as DD) you can just start to work on the package.

Please let me know if you have any questions or want some review.

Best regards

Hannes

[0] https://salsa.debian.org/debian/logcheck/

Bug#993549: Duplicate of 947689

[Scott Ward (e2e8e2)]

Please close this bug.   Was attempting to issue this as a followup to bug 
947689, and somehow a new incident got created.

Bug#907051: Finding rough consensus on level of vendoring for large upstreams

[Jonas Smedegaard]

Hi Phil,

First of all, thanks for compiling the list of reasonings.

I get the impression that you are framing current state of embedding as 
a generally good thing to do, and if I understand that correctly then I 
disagree with it.

I suspect that it helps if separating reasons for _encouraging_ 
embedding (tiny upstream projects and deeply integrated sets of 
upstreams, I guess) from reasons for _discouraging_ embdding (all other 
cases, I guess).


Quoting Phil Morrell (2021-09-03 00:38:35)
> 5. Where only a small number of unrelated projects are bundled, they
>SHOULD be uploaded as separate source packages.

Concretely I think not I but ftpmaster objects to the above: Node.js 
packages embed unrelated packages to meet ftpmaster requirement of a 
minimum size source package.


 - 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#993551: Acknowledgement (ITP: proton-caller -- Run any Windows program through Proton)

[BenTheTechGuy]

Correction: Upstream Author should be Avery Murray ,
instead of Ben Westover , who is the maintainer.

Bug#993551: ITP: proton-caller -- Run any Windows program through Proton

[Ben Westover]

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

* Package name: proton-caller
  Version : 2.3.2
  Upstream Author : Ben Westover 
* URL : https://github.com/caverym/proton-caller/
* License : GPL-3+
  Programming Lang: Rust
  Description : Run any Windows program through Proton

I've been maintaining this package and uploading it onto the program's GitHub 
releases page since version 2.2.2.
I'm interested in getting this package into Debian so that it can just be 
installed via apt instead of needing to download a stray deb file.
The only thing this package depends on is Steam, which is outside the Debian 
distribution, so this package should go into contrib.

Bug#993545: Kwin glitches when launched with compositing enabled

[Norbert Preining]

On Thu, 02 Sep 2021, David Cortes wrote:
> Every time I start a new plasma session and kwin launches, it will have
> a series of graphical glitches which make the session unusable,

Sounds like a broken mesa stack or broken GPU. Reading the upstream bug
also makes me wonder. I myself am running on amdgpu without any hitches.

Best

Norbert

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

Bug#993543: JuK replays beginning of each track

[Norbert Preining]

Hi David,

On Thu, 02 Sep 2021, David Cortes wrote:
> Every time JuK plays a new track (e.g. a music file), it will play the
> beginning (first half second or so) twice - that is, it plays the first

I cannot reproduce this. Again, maybe you have some peculiar sound
setup.

Best

Norbert

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

Bug#993542: JuK starts muted every new session

[Norbert Preining]

Hi

> Every time I start JuK in a new plasma session, it now starts muted,
> despite having previously adjusted the volume. Editing ~/.config/jukrc

I cannot reproduce this. Every time I start juk it is not muted. Maybe
you have some special audio setup. I have manually muted it and
restarted, to no avail, it always comes up unmuted.

Best

Norbert

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

Bug#964284: guile-gnutls: update to use guile 3.0

[Rob Browning]

Andreas Metzler  writes:

> I just made a test-upload to experimental.

I just found out I may have been wrong about 3.0.7's defaults, and so
this problem might not be fixed yet.  I'll investigate soon, and likely
have another upload by this weekend, if we do end up needing one.

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

Bug#993550: gtk4: gsk repeat, repeat-negative-coords tests fail with ngl renderer on mips*el

[Simon McVittie]

Source: gtk4
Version: 4.4.0+ds1-3
Severity: normal
Tags: upstream
X-Debbugs-Cc: debian-m...@lists.debian.org
Forwarded: https://gitlab.gnome.org/GNOME/gtk/-/issues/4228

GTK 4 has a new scene-graph-based rendering model, "GSK", with an OpenGL
preferred implementation and a Cairo fallback. Its regression tests draw
various combinations of "render nodes" and check the results against
reference PNG images.

When using the "new" OpenGL renderer, "ngl", there's a weird rendering
glitch on mips*el on two tests involving repeating a pattern: the top
left pixel in each 2x2 block is darker than the other three.
For more details and comparison images:
https://gitlab.gnome.org/GNOME/gtk/-/issues/4228

Is there anything unusual about the OpenGL implementation on mips*el
that would cause this sort of thing? It seems to be using Mesa swrast_dri.so
(which I think is llvmpipe?), the same as any other machine without a GPU.

The "old" OpenGL renderer, "gl", does not seem to suffer from this - but
it is no longer the default, has been deleted in newer upstream versions,
and crashes in two (unrelated) tests on mipsel, so I'm going to disable
testing for "gl" in the next upload to avoid wasting machine resources and
developer time on it.

I'm going to skip these two tests on mips*el. I don't know what practical
effect this will have on GTK applications; I would recommend that people
who are interested in GUIs on mips*el should try the gtk-4-examples package
when mips*el builds become available, and find out.

smcv

Bug#993549: iptables: -Z also fails to clear all counters when invoked without a chain name

[Scott Ward]

Package: iptables
Version: 1.8.7-1
Followup-For: Bug #947689

Dear Maintainer,

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

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

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


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

Kernel: Linux 5.10.0-8-amd64 (SMP w/1 CPU thread)
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 iptables depends on:
ii  libc62.31-13
ii  libip4tc21.8.7-1
ii  libip6tc21.8.7-1
ii  libmnl0  1.0.4-3
ii  libnetfilter-conntrack3  1.0.8-3
ii  libnfnetlink01.0.1-3+b1
ii  libnftnl11   1.1.9-1
ii  libxtables12 1.8.7-1
ii  netbase  6.3

Versions of packages iptables recommends:
ii  nftables  0.9.8-3.1

Versions of packages iptables suggests:
pn  firewalld  
ii  kmod   28-1

-- no debconf information


== added information ==

iptables -Z also failes to clear the counters in an entire table even if no 
chain name is given, for example:
 
iptables -t nat -Z

does not clear any counters in the nat table.

Bug#993548: Please update tree-styletab to 3.8.12 from upstream for firefox 91-esr

[shirish शिरीष]

Package: xul-ext-treestyletab
Version: 3.5.20-1
Severity: wishlist

Dear Maintainer,
We need the latest version of TST to work with Firefox 91. So if
possible, put it on the experimental archive so those of us who want
to see how it works can use the same and provide feedback, both here
as well as upstream. The upstream release can be found out at -

https://github.com/piroor/treestyletab

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

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

Versions of packages xul-ext-treestyletab depends on:
ii  webext-treestyletab  3.5.20-1

xul-ext-treestyletab recommends no packages.

xul-ext-treestyletab suggests no packages.

-- no debconf information





-- 
  Regards,
  Shirish Agarwal  शिरीष अग्रवाल
  My quotes in this email licensed under CC 3.0
http://creativecommons.org/licenses/by-nc/3.0/
http://flossexperiences.wordpress.com

E493 D466 6D67 59F5 1FD0 930F 870E 9A5B 5869 609C

Bug#907051: Finding rough consensus on level of vendoring for large upstreams

[Jérémy Lal]

Le ven. 3 sept. 2021 à 00:39, Phil Morrell  a écrit :

> Over this last year there seems to have been a noticeable divergence of
> maintainer opinion, on what has become known as vendoring, from a strict
> reading of [policy 4.13]. I think it's notable that the heading is
> [Embedded] copies and was [Convenience] copies since its inception,
> thankfully I found a request to expand this section using [vendoring].
>
> [policy 4.13]:
> https://www.debian.org/doc/debian-policy/ch-source.html#embedded-code-copies
> [Embedded]: https://bugs.debian.org/955036
> [Convenience]: https://bugs.debian.org/392362
> [vendoring]: https://bugs.debian.org/907051
>
> It is my reading of the situation that not only has this practice become
> more prevalent across multiple ecosystems since 2008, but that it can be
> a good thing when upstreams use it to better modularise their code. As a
> consequence, and in particular for large upstream projects, it is not a
> good use of maintainer time to package every single vendored library as
> a separate source package. See e.g. [kubernetes], [python BoF @25mins],
> [android-platform-tools], and even [uscan] grouping used by nodejs.
>
> [kubernetes]: https://bugs.debian.org/971515#172
> [python BoF @25mins]:
> https://meetings-archive.debian.net/pub/debian-meetings/2021/DebConf21/debconf21-97-python-team-bof.webm
> [android-platform-tools
> ]:
> https://salsa.debian.org/android-tools-team/admin/-/issues/40
> [uscan]: https://manpages.debian.org/uscan#grouped_package
>
> Is there any objection to the following summary?
>

> 1. If the reused code is small and intended to be embedded into a
>package, then this MUST be documented in the [security-tracker].
> 2. If the included project has already been packaged, then the Debian
>version SHOULD be used instead.
> 3. If modifications have been made, then those changes SHOULD be
>forwarded and/or the package ported to the official version.
> 4. When 2 or 3 are too onerous to maintain, the package MAY use the
>convenience copy but MUST document why in README.source and SHOULD be
>included in the [security-tracker].
> 5. Where only a small number of unrelated projects are bundled, they
>SHOULD be uploaded as separate source packages.
> 6. If the upstream authors are largely the same, then vendored
>sub-projects MAY simply be built together as the same source.
> 7. A large number of vendored dependencies used only together for a
>single Debian package MAY be grouped into a single source upload.
> 8. If 6 or 7 are used initially but a new package has some overlap, then
>the new package MUST NOT duplicate the vendoring. The duplication
>SHOULD be packaged separately, then the original package SHOULD be
>updated to use the Debian version instead.
> 9. When upstream has a proven track record of promptly handling security
>vulnerabilities inside their vendored dependencies, then maintainers
>SHOULD follow the same practice, updating versions in lockstep.
>

a couple naive questions:
- should a package debian/control list bundled dependencies to make
sure to avoid duplications ?
- when a bundled package dependency is already available in debian,
and is the same (unpatched), should the upstream source tarball be
repacked without that dependency, or kept inside the source tarball ?

Jérémy

Bug#907051: Finding rough consensus on level of vendoring for large upstreams

[Phil Morrell]

Over this last year there seems to have been a noticeable divergence of
maintainer opinion, on what has become known as vendoring, from a strict
reading of [policy 4.13]. I think it's notable that the heading is
[Embedded] copies and was [Convenience] copies since its inception,
thankfully I found a request to expand this section using [vendoring].

[policy 4.13]: 
https://www.debian.org/doc/debian-policy/ch-source.html#embedded-code-copies
[Embedded]: https://bugs.debian.org/955036
[Convenience]: https://bugs.debian.org/392362
[vendoring]: https://bugs.debian.org/907051

It is my reading of the situation that not only has this practice become
more prevalent across multiple ecosystems since 2008, but that it can be
a good thing when upstreams use it to better modularise their code. As a
consequence, and in particular for large upstream projects, it is not a
good use of maintainer time to package every single vendored library as
a separate source package. See e.g. [kubernetes], [python BoF @25mins],
[android-platform-tools], and even [uscan] grouping used by nodejs.

[kubernetes]: https://bugs.debian.org/971515#172
[python BoF @25mins]: 
https://meetings-archive.debian.net/pub/debian-meetings/2021/DebConf21/debconf21-97-python-team-bof.webm
[android-platform-tools]: 
https://salsa.debian.org/android-tools-team/admin/-/issues/40
[uscan]: https://manpages.debian.org/uscan#grouped_package

Is there any objection to the following summary?

1. If the reused code is small and intended to be embedded into a
   package, then this MUST be documented in the [security-tracker].
2. If the included project has already been packaged, then the Debian
   version SHOULD be used instead.
3. If modifications have been made, then those changes SHOULD be
   forwarded and/or the package ported to the official version.
4. When 2 or 3 are too onerous to maintain, the package MAY use the
   convenience copy but MUST document why in README.source and SHOULD be
   included in the [security-tracker].
5. Where only a small number of unrelated projects are bundled, they
   SHOULD be uploaded as separate source packages.
6. If the upstream authors are largely the same, then vendored
   sub-projects MAY simply be built together as the same source.
7. A large number of vendored dependencies used only together for a
   single Debian package MAY be grouped into a single source upload.
8. If 6 or 7 are used initially but a new package has some overlap, then
   the new package MUST NOT duplicate the vendoring. The duplication
   SHOULD be packaged separately, then the original package SHOULD be
   updated to use the Debian version instead.
9. When upstream has a proven track record of promptly handling security
   vulnerabilities inside their vendored dependencies, then maintainers
   SHOULD follow the same practice, updating versions in lockstep.

I might be misusing the MUST/SHOULD/MAY, so those can be dropped as
needed, but I tried to capture the accepted practice and deliberately
used all the different historical terms. For comparison, there's also
[Fedora] policy, but apart from not having an in-band "bundled", I also
think that the line has ended up being drawn marginally differently.

[security-tracker]: 
https://salsa.debian.org/security-tracker-team/security-tracker/-/blob/master/data/embedded-code-copies
[Fedora] https://docs.fedoraproject.org/en-US/packaging-guidelines/#bundling


signature.asc
Description: PGP signature

Bug#987378: yara breaks golang-github-hillu-go-yara autopkgtest + ftbfs

[Hilko Bengen]

* Paul Gevers:

> On Thu, 2 Sep 2021 10:17:22 +0200 Sascha Steinbiss  wrote:
>> I think this is done now. With YARA 4.1.2 and 
>> golang-github-hillu-go-yara 4.1.0 now in unstable, the build works again 
>> as the build-time tests complete fine.
>> 
>> @Hilko any other comments?
>
> If there are incompatible API changes, the soname needs to be bumped.

The soname was bumped, from 4 to 8.

Cheers,
-Hilko

Bug#990016: Debian installer images missing ASpeed video driver

[Timothy Pearson]

We just got hit with this again, in a customer-facing issue this time.  The 
ASpeed video driver is going to be useful for nearly any non-x86 platform; i.e. 
any platform that is not likely to have a standard video BIOS / character mode 
display fallback but still have a display attached.  That means ppc64el, arm64, 
riscv, sparc64 in practice.

- Original Message -
> From: "Jochen Sprickerhof" 
> To: "Timothy Pearson" , 990...@bugs.debian.org
> Sent: Saturday, July 10, 2021 1:09:14 PM
> Subject: Re: Bug#990016: Debian installer images missing ASpeed video driver

> Control: reassign -1 src:linux
> 
> Hi Timothy,
> 
> * Timothy Pearson  [2021-06-17 15:46]:
>>The current Bullseye installer images don't include the "ast" video driver,
>>making it impossible to install Debian on systems that don't have a fallback
>>VGA BIOS (anything non-x86, e.g. ARM/OpenPOWER).
>>
>>Ubuntu fixed this issue almost 5 years ago:
>>https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1514711
>>
>>Please include the "ast" kernel module, which does not require any proprietary
>>firmware to function, in the Debian installer CD images.
> 
> The module is part of the fb-modules-5.10.0-7-arm64-di:
> 
> https://salsa.debian.org/kernel-team/linux/-/blob/master/debian/installer/modules/arm64/fb-modules#L3
> 
> and fb-modules-5.10.0-7-loongson-3-di:
> 
> https://salsa.debian.org/kernel-team/linux/-/blob/master/debian/installer/modules/mipsel-loongson-3/fb-modules#L5
> 
> Additionally CONFIG_DRM_AST is enabled for ppc64:
> 
> https://salsa.debian.org/kernel-team/linux/-/blob/master/debian/config/kernelarch-powerpc/config-arch-64#L94
> 
> and x86:
> 
> https://salsa.debian.org/kernel-team/linux/-/blob/master/debian/config/kernelarch-x86/config#L519
> 
> So I assume it should be easy to add the module to the corresponding
> udebs. Reassigning to the linux package, accordingly.
> 
> I guess it would help if you could be more specific on which
> architectures it would be useful.
> 
> Cheers Jochen

Bug#993224: buster-pu: package ublock-origin/1.37.0+dfsg-1~deb10u1

[Markus Koschany]

Hi,

Am Donnerstag, dem 02.09.2021 um 22:29 +0100 schrieb Adam D. Barratt:
> On Sat, 2021-08-28 at 22:52 +0200, Markus Koschany wrote:
> > Fixing CVE-2021-36773 in Buster and updating various filter lists.
> > 
> 
> The changelog appears to include a conflict marker:
> 
> +ublock-origin (1.32.0+dfsg-1) unstable; urgency=medium
> +
> +  * New upstream version 1.32.0+dfsg.
> +  * Declare compliance with Debian Policy 4.5.1.
> +
> + -- Markus Koschany   Sat, 26 Dec 2020 20:48:03 +0100
> +>>> master
> 
> It's up to you if you'd prefer that I reject the current upload so you
> can clean up and re-upload, or fix it in a presumed future upload.

Let's fix that in a future upload. Thanks for spotting it. I have removed the
marker in Git already.

Regards,

Markus



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

Bug#993277: krb5 1.17-3+deb10u3 flagged for acceptance

[Adam D Barratt]

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

Hi,

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

Thanks for your contribution!

Upload details
==

Package: krb5
Version: 1.17-3+deb10u3

Explanation: fix KDC null dereference crash on FAST request with no server 
field [CVE-2021-37750]; fix memory leak in krb5_gss_inquire_cred

Bug#993134: shiro 1.3.2-4+deb10u1 flagged for acceptance

[Adam D Barratt]

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

Hi,

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

Thanks for your contribution!

Upload details
==

Package: shiro
Version: 1.3.2-4+deb10u1

Explanation: fix authentication bypass issues [CVE-2020-1957 CVE-2020-11989 
CVE-2020-13933 CVE-2020-17510]; update Spring Framework compatibility patch; 
support Guice 4

Bug#992599: commons-io 2.6-2+deb10u1 flagged for acceptance

[Adam D Barratt]

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

Hi,

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

Thanks for your contribution!

Upload details
==

Package: commons-io
Version: 2.6-2+deb10u1

Explanation: fix path traversal issue [CVE-2021-29425]

Bug#993546: kmail: KMail sees different signing key on same mail when enabling debian-keyring

[Diederik de Haas]

On donderdag 2 september 2021 23:15:47 CEST Diederik de Haas wrote:
> KMail reports (after I signed it)

The signing part is irrelevant for reproducing the bug.
I experienced the exact same problem before I signed it.

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

Bug#993224: buster-pu: package ublock-origin/1.37.0+dfsg-1~deb10u1

[Adam D. Barratt]

On Sat, 2021-08-28 at 22:52 +0200, Markus Koschany wrote:
> Fixing CVE-2021-36773 in Buster and updating various filter lists.
> 

The changelog appears to include a conflict marker:

+ublock-origin (1.32.0+dfsg-1) unstable; urgency=medium
+
+  * New upstream version 1.32.0+dfsg.
+  * Declare compliance with Debian Policy 4.5.1.
+
+ -- Markus Koschany   Sat, 26 Dec 2020 20:48:03 +0100
+>>> master

It's up to you if you'd prefer that I reject the current upload so you
can clean up and re-upload, or fix it in a presumed future upload.

Regards,

Adam

Bug#993547: saods9: Error in startup script

[Alexandre Beelen]

Package: saods9
Version: 8.3~b1+repack-1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

Launching ds9 from the command line, result in an output error :

Error in startup script: cannot find symbol "Signal_Init": 
/usr/lib/tcltk/x86_64-linux-gnu/Signal1.4.4.1/libSignal1.4.4.1.so: 
undefined symbol: _Signal_Init

while executing
"load /usr/lib/tcltk/x86_64-linux-gnu/Signal1.4.4.1/libSignal1.4.4.1.so 
Signal"

("package ifneeded Signal 1.4.4.1" script)
invoked from within
"package require Signal"
(file "/usr/share/saods9/library/ds9.tcl" line 229)

instead of launching the program

a.

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

Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-8-amd64 (SMP w/4 CPU threads)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE 
not set

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

Versions of packages saods9 depends on:
ii  libtk-img  1:1.4.13+dfsg-1
ii  tcl-awthemes   10.4.0-1
ii  tcl-signal 1.4.4.1-1
ii  tcl-tls1.7.22-2
ii  tcl-ttkthemes  3.2.2-1
ii  tcl-xpa2.1.20-1
ii  tclfitsy   8.2+repack-2
ii  tcliis 8.2+repack-2
ii  tcllib 1.20+dfsg-1
ii  tclxml 1:3.2.7-5
ii  tk 8.6.11+1
ii  tk-html1   1.04-2
ii  tk-mpeg1.0.9-1
ii  tk-table   2.10.7-1
ii  tkblt  3.2.23-1
ii  tkcon  2:2.7.10-2
ii  tksao  8.2+repack-2

Versions of packages saods9 recommends:
ii  saods9-doc  8.2+repack-2

Versions of packages saods9 suggests:
pn  python3-pyds9  
pn  xpa-tools  

-- no debconf information

Bug#992971: grilo: diff for NMU version 0.3.13-1.1

[Salvatore Bonaccorso]

Control: tags 992971 + patch
Control: tags 992971 + pending

Hi Alberto,

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

It is basically just a rebuild of your upload for bullseye-security to
have the fix as well in unstable/testing.

Regards,
Salvatore
diff -Nru grilo-0.3.13/debian/changelog grilo-0.3.13/debian/changelog
--- grilo-0.3.13/debian/changelog	2020-09-06 12:51:05.0 +0200
+++ grilo-0.3.13/debian/changelog	2021-09-02 23:05:13.0 +0200
@@ -1,3 +1,14 @@
+grilo (0.3.13-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+
+  [ Alberto Garcia ]
+  * fix-tls-cert-validation.patch:
+- Fix TLS cert validation not being done for any network call
+  (Closes: #992971, CVE-2021-39365).
+
+ -- Salvatore Bonaccorso   Thu, 02 Sep 2021 23:05:13 +0200
+
 grilo (0.3.13-1) unstable; urgency=medium
 
   [ Alberto Garcia ]
diff -Nru grilo-0.3.13/debian/patches/fix-tls-cert-validation.patch grilo-0.3.13/debian/patches/fix-tls-cert-validation.patch
--- grilo-0.3.13/debian/patches/fix-tls-cert-validation.patch	1970-01-01 01:00:00.0 +0100
+++ grilo-0.3.13/debian/patches/fix-tls-cert-validation.patch	2021-08-26 23:10:58.0 +0200
@@ -0,0 +1,17 @@
+From: Bastien Nocera 
+Subject: Fix TLS cert validation not being done for any network call (CVE-2021-39365)
+Bug: https://gitlab.gnome.org/GNOME/grilo/-/issues/146
+Bug-Debian: https://bugs.debian.org/992971
+Origin: https://gitlab.gnome.org/GNOME/grilo/-/commit/cd2472e506dafb1bb8ae510e34ad4797f63e263e
+Index: grilo/libs/net/grl-net-wc.c
+===
+--- grilo.orig/libs/net/grl-net-wc.c
 grilo/libs/net/grl-net-wc.c
+@@ -314,6 +314,7 @@ grl_net_wc_init (GrlNetWc *wc)
+   wc->priv = grl_net_wc_get_instance_private (wc);
+ 
+   wc->priv->session = soup_session_async_new ();
++  g_object_set (G_OBJECT (wc->priv->session), "ssl-use-system-ca-file", TRUE, NULL);
+   wc->priv->pending = g_queue_new ();
+ 
+   set_thread_context (wc);
diff -Nru grilo-0.3.13/debian/patches/series grilo-0.3.13/debian/patches/series
--- grilo-0.3.13/debian/patches/series	1970-01-01 01:00:00.0 +0100
+++ grilo-0.3.13/debian/patches/series	2021-08-26 23:10:58.0 +0200
@@ -0,0 +1 @@
+fix-tls-cert-validation.patch

Bug#993546: kmail: KMail sees different signing key on same mail when enabling debian-keyring

[Diederik de Haas]

Package: kmail
Version: 4:21.08.0-2
Severity: normal

Recently I received a signed email from Debian Developer joostvb@d.o.
I imported his public key to my keyring as follows:
gpg --keyserver keyring.debian.org --recv-keys 
0xB8FAC2E250475B8CE940A91957930DAB0B86B067

When selecting that mail, KMail reports (after I signed it):
Message was signed by joos...@mdcc.cx (Key ID: 0x57930DAB0B86B067).
The signature is valid and the key is fully trusted.

Excellent, exactly as I expected.
Joost's key is also part of the debian-keyring with the (exact) same
fingerprint. I figured it would be useful to have DD's key in gpg's
keyring, so I added the following to ~/.gnupg/gpg.conf:
keyring /usr/share/keyrings/debian-keyring.gpg

But when I then first select an(y) other email and then select Joost's
email again, KMail reports the following:
Message was signed on  with unknown key 
0x92AAD901B21B4BC79A47A03054F1A66317486713.
The validity of the signature cannot be verified.
Status: Good signature

When doing "gpg --list-keys 0x57930DAB0B86B067" (or long key ID) 
(with "list-options show-keyring=yes" in my gpg.conf) I see the same key
present in my keyring (pubring.kbx) and in Debian's debian-keyring.gpg.

If I then disable the "keyring ... debian-keyring.gpg" line again, all
is well again and enabling brings the problem back.
I've also started with a completely new ~/.gnupg and could still
reproduce the problem.

I have no clue how this can happen or be explained,
but it sounds like a bug to me.

Cheers,
  Diederik

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

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

Versions of packages kmail depends on:
ii  akonadi-server   4:21.08.0-1
ii  kdepim-runtime   4:21.08.0-1
ii  kio  5.85.0-2
ii  libc62.31-17
ii  libgcc-s111.2.0-3
ii  libgpgmepp6  1.16.0-1
ii  libkf5akonadiagentbase5 [libkf5akonadiagentbase5-21.08]  4:21.08.0-1
ii  libkf5akonadicontact5 [libkf5akonadicontact5-21.08]  4:21.08.0-1
ii  libkf5akonadicore5abi2 [libkf5akonadicore5-21.08]4:21.08.0-1
ii  libkf5akonadimime5 [libkf5akonadimime5-21.08]4:21.08.0-1
ii  libkf5akonadisearch-bin  4:21.08.0-1
ii  libkf5akonadisearch-plugins  4:21.08.0-1
ii  libkf5akonadisearchdebug5 [libkf5akonadisearchdebug5-21.08]  4:21.08.0-1
ii  libkf5akonadisearchpim5 [libkf5akonadisearchpim5-21.08]  4:21.08.0-1
ii  libkf5akonadiwidgets5abi1 [libkf5akonadiwidgets5-21.08]  4:21.08.0-1
ii  libkf5bookmarks5 5.85.0-2
ii  libkf5calendarcore5abi2  5:5.85.0-2
ii  libkf5calendarutils5 [libkf5calendarutils5-21.08]4:21.08.0-1
ii  libkf5codecs55.85.0-2
ii  libkf5completion55.85.0-2
ii  libkf5configcore55.85.0-2
ii  libkf5configgui5 5.85.0-2
ii  libkf5configwidgets5 5.85.0-2
ii  libkf5contacts5  5:5.85.0-2
ii  libkf5coreaddons55.85.0-2
ii  libkf5crash5 5.85.0-2
ii  libkf5dbusaddons55.85.0-2
ii  libkf5grantleetheme-plugins  21.08.0-1
ii  libkf5gravatar5abi2 [libkf5gravatar5-21.08]  4:21.08.0-1
ii  libkf5guiaddons5 5.85.0-2
ii  libkf5i18n5  5.85.0-2
ii  libkf5iconthemes55.85.0-2
ii  libkf5identitymanagement5 [libkf5identitymanagement5-21.08]  21.08.0-1
ii  libkf5itemmodels55.85.0-2
ii  libkf5itemviews5 5.85.0-2
ii  libkf5jobwidgets55.85.0-2
ii  libkf5kcmutils5  5.85.0-2
ii  libkf5kiocore5   5.85.0-2
ii  libkf5kiofilewidgets5

Bug#992692: general: Use https for {deb,security}.debian.org by default

[Ansgar]

On Thu, 2021-09-02 at 21:26 +0200, Simon Richter wrote:
> As it is now, I can install a Debian system where no X.509
> certificate authorities are trusted.

That doesn't change with the proposal?

>   - If I deselect all CAs in the configuration dialog of the 
> ca-certificates package, what mechanism will allow apt to work?

If people intentionally detrust them, they have to deal with the
fallout. People can also detrust Debian's OpenPGP signing keys; it's
not much different.

Accessing www.debian.org will also not work on such systems (and unlike
deb.d.o that does not even offer non-https). It's not Debian's problem.

>   - Do we want to pin the certificate provider for Debian mirrors, in
> the knowledge that we want to be bound to this provider for several 
> years, do we want any "root" CA to be able to provide a trust anchor?

Probably not?

>   - Is there a revocation mechanism by which we can mark "root" CAs
> as 
> untrustworthy?

If we don't have one, shouldn't we worry more about that given the
widespread use of TLS?

Do we have a revocation mechanism by which we can mark OpenPGP signing
keys as untrustworthy (say for apt)?

>   - What does the UI look like if OSCP verification fails?
>   - How do mirror operators get a signed certificate?

Not all mirror operators have a TLS certificate. I don't think that was
proposed to be changed (see subject of the mail).

> I think we're adding a lot of complexity and external dependencies to
> the system here, which adds a lot of burden to mirror operators that 
> aren't large CDNs.

See above.

>   - do we have a contingency plan if deb.debian.org hosting on Fastly
> is no longer feasible?

Is replacing deb.d.o by a non-CDN feasible? If no, what does use of
https change?

As far as I know there is also at least https://cdn-aws.deb.debian.org/
if you don't like Fastly.

Ansgar

Bug#993545: Kwin glitches when launched with compositing enabled

[David Cortes]

Package: kwin-x11
Version: 4:5.21.5-2

Every time I start a new plasma session and kwin launches, it will have
a series of graphical glitches which make the session unusable,
including:
- Not displaying the system taskbar.
- Not displaying any part of an application window which reaches the
bottom half of a screen.
- Having issues with graphical effects such as drawing rounded window
borders.
- Getting half of the screen in black for a while after issuing a
restart command.
(Among others)

When this happens and I restart the computer (a simple plasma session
restart does not suffice), next time it usually starts with compositing
disabled, which allows for kwin to start correctly, and compositing
will work fine once I reenable it in that same session, but then the
problem will happen again in the next restart.

The file ~/.xsession-errors will afterwards show many instances of this
line:
[2594:2594:0901/114421.740314:ERROR:shared_context_state.cc(73)] Skia
shader compilation error

(See also https://bugs.kde.org/show_bug.cgi?id=441871 for more details
and for the full xsession-errors)

I suspect there might be some issue between the current kwin version
and the video drivers (this is on an AMD Vega 56 card using the mesa
drivers, currently libglx-mesa0==21.2.1-2).

The issue is present whether the compositing is set to OpenGL 2.0,
OpenGL 3.1, or XRender.

Bug#993544: Latte doesn't mark grouped applications

[David Cortes]

Package: latte-dock
Version: 0.10.1-1

After updating to latte 0.10.1-1, I am experiencing an issue in which
icons of an application with multiple opened windows will not display
the "plus" sign that marks a grouped application.

The issue goes away for the rest of a given session if I manually
right-click the latte dock, select "Edit Dock", and leave without
changes.

The problem does not seem to lie with the upstream code:
https://bugs.kde.org/show_bug.cgi?id=441839

(See the link above for a GIF showcasing the problem)

This is with all the KDE software at the current sid versions (plasma
5.21.5, frameworks 5.85.0, gears 21.08).

Was working correctly in 0.9.11-1.

Bug#993543: JuK replays beginning of each track

[David Cortes]

Package: juk
Version: 4:21.08.0-1

Every time JuK plays a new track (e.g. a music file), it will play the
beginning (first half second or so) twice - that is, it plays the first
second or so of the file, then restarts from the beginning, and keeps
playing until the end. Once the current track finishes, the same thing
will happen when it starts playing the next track and with every sub-
sequent track.

This behavior is a regression over version 20.08.

Bug#993542: JuK starts muted every new session

[David Cortes]

Package: juk
Version: 4:21.08.0-1

Every time I start JuK in a new plasma session, it now starts muted,
despite having previously adjusted the volume. Editing ~/.config/jukrc
before launching it has no effect either. Further runs within the same
plasma session work fine though. This behavior is a regression over
version 20.08.

If launched with valgrind (command "valgrind juk"), it keeps showing
lots of error messages about "Conditional jump or move depends on
uninitialised value(s)", plus some "Invalid read"s at the beginning.

This is with all the KDE packages (plasma/frameworks/gears) from
current debian sid, right now at versions 5.21.5, 5.85.0, and 21.08.

Bug#993225: ublock-origin 1.37.0+dfsg-1~deb11u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 993225 = bullseye pending
thanks

Hi,

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

Thanks for your contribution!

Upload details
==

Package: ublock-origin
Version: 1.37.0+dfsg-1~deb11u1

Explanation: new upstream stable release; fix denial of service issue 
[CVE-2021-36773]

Bug#993541: libbpp-core FTBFS: symbol differences

[Helmut Grohne]

Source: libbpp-core
Version: 2.4.1-5
Severity: serious
Tags: ftbfs

libbpp-core fails to build from source on amd64 in unstable due to
symbol differences:


|dh_makeshlibs -a
| dpkg-gensymbols: warning: some new symbols appeared in the symbols file: see 
diff output below
| dpkg-gensymbols: error: some symbols or patterns disappeared in the symbols 
file: see diff output below
| dpkg-gensymbols: warning: debian/libbpp-core4/DEBIAN/symbols doesn't match 
completely debian/libbpp-core4.symbols.amd64
| --- debian/libbpp-core4.symbols.amd64 (libbpp-core4_2.4.1-5_amd64)
| +++ dpkg-gensymbolsrnSTfQ 2021-09-02 11:05:37.839656815 +
| @@ -2086,66 +2086,79 @@
|   
_ZNSt15_Sp_counted_ptrIPN3bpp12MathOperatorELN9__gnu_cxx12_Lock_policyE2EE14_M_get_deleterERKSt9type_info@Base
 2.4.1
|   
_ZNSt15_Sp_counted_ptrIPN3bpp12MathOperatorELN9__gnu_cxx12_Lock_policyE2EED0Ev@Base
 2.4.1
|   
_ZNSt15_Sp_counted_ptrIPN3bpp12MathOperatorELN9__gnu_cxx12_Lock_policyE2EED1Ev@Base
 2.4.1
| + 
_ZNSt15_Sp_counted_ptrIPN3bpp12MathOperatorELN9__gnu_cxx12_Lock_policyE2EED2Ev@Base
 2.4.1-5
|   
_ZNSt15_Sp_counted_ptrIPN3bpp13TreeGraphImplINS0_11GlobalGraphEEELN9__gnu_cxx12_Lock_policyE2EE10_M_destroyEv@Base
 2.4.1
|   
_ZNSt15_Sp_counted_ptrIPN3bpp13TreeGraphImplINS0_11GlobalGraphEEELN9__gnu_cxx12_Lock_policyE2EE10_M_disposeEv@Base
 2.4.1
|   
_ZNSt15_Sp_counted_ptrIPN3bpp13TreeGraphImplINS0_11GlobalGraphEEELN9__gnu_cxx12_Lock_policyE2EE14_M_get_deleterERKSt9type_info@Base
 2.4.1
|   
_ZNSt15_Sp_counted_ptrIPN3bpp13TreeGraphImplINS0_11GlobalGraphEEELN9__gnu_cxx12_Lock_policyE2EED0Ev@Base
 2.4.1
|   
_ZNSt15_Sp_counted_ptrIPN3bpp13TreeGraphImplINS0_11GlobalGraphEEELN9__gnu_cxx12_Lock_policyE2EED1Ev@Base
 2.4.1
| + 
_ZNSt15_Sp_counted_ptrIPN3bpp13TreeGraphImplINS0_11GlobalGraphEEELN9__gnu_cxx12_Lock_policyE2EED2Ev@Base
 2.4.1-5
|   
_ZNSt15_Sp_counted_ptrIPN3bpp14BinaryOperatorELN9__gnu_cxx12_Lock_policyE2EE10_M_destroyEv@Base
 2.4.1
|   
_ZNSt15_Sp_counted_ptrIPN3bpp14BinaryOperatorELN9__gnu_cxx12_Lock_policyE2EE10_M_disposeEv@Base
 2.4.1
|   
_ZNSt15_Sp_counted_ptrIPN3bpp14BinaryOperatorELN9__gnu_cxx12_Lock_policyE2EE14_M_get_deleterERKSt9type_info@Base
 2.4.1
|   
_ZNSt15_Sp_counted_ptrIPN3bpp14BinaryOperatorELN9__gnu_cxx12_Lock_policyE2EED0Ev@Base
 2.4.1
|   
_ZNSt15_Sp_counted_ptrIPN3bpp14BinaryOperatorELN9__gnu_cxx12_Lock_policyE2EED1Ev@Base
 2.4.1
| + 
_ZNSt15_Sp_counted_ptrIPN3bpp14BinaryOperatorELN9__gnu_cxx12_Lock_policyE2EED2Ev@Base
 2.4.1-5
|   
_ZNSt15_Sp_counted_ptrIPN3bpp16ConstantOperatorELN9__gnu_cxx12_Lock_policyE2EE10_M_destroyEv@Base
 2.4.1
|   
_ZNSt15_Sp_counted_ptrIPN3bpp16ConstantOperatorELN9__gnu_cxx12_Lock_policyE2EE10_M_disposeEv@Base
 2.4.1
|   
_ZNSt15_Sp_counted_ptrIPN3bpp16ConstantOperatorELN9__gnu_cxx12_Lock_policyE2EE14_M_get_deleterERKSt9type_info@Base
 2.4.1
|   
_ZNSt15_Sp_counted_ptrIPN3bpp16ConstantOperatorELN9__gnu_cxx12_Lock_policyE2EED0Ev@Base
 2.4.1
|   
_ZNSt15_Sp_counted_ptrIPN3bpp16ConstantOperatorELN9__gnu_cxx12_Lock_policyE2EED1Ev@Base
 2.4.1
| + 
_ZNSt15_Sp_counted_ptrIPN3bpp16ConstantOperatorELN9__gnu_cxx12_Lock_policyE2EED2Ev@Base
 2.4.1-5
|   
_ZNSt15_Sp_counted_ptrIPN3bpp16FunctionOperatorINS0_19DerivableFirstOrderEEELN9__gnu_cxx12_Lock_policyE2EE10_M_destroyEv@Base
 2.4.1
|   
_ZNSt15_Sp_counted_ptrIPN3bpp16FunctionOperatorINS0_19DerivableFirstOrderEEELN9__gnu_cxx12_Lock_policyE2EE10_M_disposeEv@Base
 2.4.1
|   
_ZNSt15_Sp_counted_ptrIPN3bpp16FunctionOperatorINS0_19DerivableFirstOrderEEELN9__gnu_cxx12_Lock_policyE2EE14_M_get_deleterERKSt9type_info@Base
 2.4.1
|   
_ZNSt15_Sp_counted_ptrIPN3bpp16FunctionOperatorINS0_19DerivableFirstOrderEEELN9__gnu_cxx12_Lock_policyE2EED0Ev@Base
 2.4.1
|   
_ZNSt15_Sp_counted_ptrIPN3bpp16FunctionOperatorINS0_19DerivableFirstOrderEEELN9__gnu_cxx12_Lock_policyE2EED1Ev@Base
 2.4.1
| + 
_ZNSt15_Sp_counted_ptrIPN3bpp16FunctionOperatorINS0_19DerivableFirstOrderEEELN9__gnu_cxx12_Lock_policyE2EED2Ev@Base
 2.4.1-5
|   
_ZNSt15_Sp_counted_ptrIPN3bpp16FunctionOperatorINS0_20DerivableSecondOrderEEELN9__gnu_cxx12_Lock_policyE2EE10_M_destroyEv@Base
 2.4.1
|   
_ZNSt15_Sp_counted_ptrIPN3bpp16FunctionOperatorINS0_20DerivableSecondOrderEEELN9__gnu_cxx12_Lock_policyE2EE10_M_disposeEv@Base
 2.4.1
|   
_ZNSt15_Sp_counted_ptrIPN3bpp16FunctionOperatorINS0_20DerivableSecondOrderEEELN9__gnu_cxx12_Lock_policyE2EE14_M_get_deleterERKSt9type_info@Base
 2.4.1
|   
_ZNSt15_Sp_counted_ptrIPN3bpp16FunctionOperatorINS0_20DerivableSecondOrderEEELN9__gnu_cxx12_Lock_policyE2EED0Ev@Base
 2.4.1
|   
_ZNSt15_Sp_counted_ptrIPN3bpp16FunctionOperatorINS0_20DerivableSecondOrderEEELN9__gnu_cxx12_Lock_policyE2EED1Ev@Base
 2.4.1
| + 
_ZNSt15_Sp_counted_ptrIPN3bpp16FunctionOperatorINS0_20DerivableSecondOrderEEELN9__gnu_cxx12_Lock_policyE2EED2Ev@Base
 2.4.1-5
|   
_ZNSt15_Sp_counted_ptrIPN3bpp16FunctionOperatorINS0_8FunctionEEELN9__gnu_cxx12_Lock_policyE2EE10_M_destroyEv@Base
 2.4.1
|   

Bug#993540: libglvnd FTBFS with the nocheck build profile

[Helmut Grohne]

Source: libglvnd
Version: 1.3.4-1
Tags: ftbfs patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

libglvnd fails to build from source when enabling the nocheck build
profile and option. Its override_dh_auto_test is unconditionally run
(since the compatibility level is too low for debhelper to automatically
skip it) and runs xvfb-run, while xvfb is annotated . Please
consider applying the attached patch to make it perform nocheck builds
(and cross builds) successfully.

Helmut
diff --minimal -Nru libglvnd-1.3.4/debian/changelog 
libglvnd-1.3.4/debian/changelog
--- libglvnd-1.3.4/debian/changelog 2021-09-01 15:20:13.0 +0200
+++ libglvnd-1.3.4/debian/changelog 2021-09-02 21:00:44.0 +0200
@@ -1,3 +1,10 @@
+libglvnd (1.3.4-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix nocheck FTBFS. (Closes: #-1)
+
+ -- Helmut Grohne   Thu, 02 Sep 2021 21:00:44 +0200
+
 libglvnd (1.3.4-1) unstable; urgency=medium
 
   * New upstream release.
diff --minimal -Nru libglvnd-1.3.4/debian/rules libglvnd-1.3.4/debian/rules
--- libglvnd-1.3.4/debian/rules 2021-09-01 15:15:23.0 +0200
+++ libglvnd-1.3.4/debian/rules 2021-09-02 21:00:42.0 +0200
@@ -13,7 +13,9 @@
dh_missing --fail-missing
 
 override_dh_auto_test:
+ifeq ($(filter nocheck,$(DEB_BUILD_OPTIONS)),)
xvfb-run -a ninja -C build test
+endif
 
 override_dh_makeshlibs:
dh_makeshlibs -a -- -c4

Bug#993539: "functions/Misc.zwc" isn't compiled from the bundled source files

[Leo Gama]

Package: zsh-common
Version: 5.8-7

Files affected (at least):
/usr/share/zsh/functions/Misc.zwc
/usr/share/zsh/functions/Misc/run-help

If I try to call "run-help" at a ZSH prompt, it reports:
> $ run-help
> There is no list of special help topics available at this time.

And trying to use it to see the help text for any built-in command just
opens a man page for zsh...

Turns out that the default HISTDIR (which is wrong) in the file that
contains the bytecode compiled version of "run-help" is different from the
default in the source code "run-help" file:
> $ grep 'HELPDIR:-/' /usr/share/zsh/functions/Misc/run-help
> local HELPDIR=${HELPDIR:-/usr/share/zsh/help}
> $ strings /usr/share/zsh/functions/Misc.zwc | grep 'HELPDIR:-/'
> HELPDIR:-/usr/share/zsh/5.8/help
> HELPDIR:-/usr/share/zsh/5.8/help

Setting HELPDIR fixes it, as expected.

It seems something went wrong in a modified building process for this
package --all sourced and compiled files for functions have identical
modification times, so at least they were "touched". I couldn't find a way,
inspecting the build script (debian/rules) and the source for "run-help",
it would end with this result.


Best,

Leonardo Gama
[image: https://]about.me/leogama

Bug#993527: [debian-mysql] Bug#993527: mariadb-server: At full-upgrade from buster to bullseye mariadb-server (and also client) are removed.

[s...@hardwarepunk.de]

On Thu, 2 Sep 2021 10:50:29 -0700
Otto Kekäläinen  wrote:

> Please test with the version in Debian testing.
> 
> An identical version is about to enter Bullseye in next stable update.

I do not think, that it has to do with the mariadb-server Version, I paste 
the output of /var/log/apt/history.log here. 
The mariadb-server was upgraded, and after upgrade removed. 
I removed anything, that has not mariadb in its name from the log:

Start-Date: 2021-09-02  18:00:08
Commandline: apt full-upgrade
Install: ., mariadb-client-10.5:amd64 (1:10.5.11-1, automatic), ., 
mariadb-client-core-10.5:amd64 (1:10.5.11-1, automatic), .
Upgrade: , mariadb-client:amd64 (1:10.3.29-0+deb10u1, 1:10.5.11-1), 
Remove: , mariadb-server:amd64 (1:10.3.29-0+deb10u1),.., 
mariadb-server-core-10.3:amd64 (1:10.3.29-0+deb10u1), ., 
mariadb-client-10.3:amd64 (1:10.3.29-0+deb10u1), .., 
mariadb-server-10.3:amd64 (1:10.3.29-0+deb10u1), , 
mariadb-client-core-10.3:amd64 (1:10.3.29-0+deb10u1), 
End-Date: 2021-09-02  18:02:04

Bug#992693: bullseye-pu: package glibc/2.31-13+deb11u1

[Aurelien Jarno]

On 2021-08-22 14:58, Aurelien Jarno wrote:
> Package: release.debian.org
> Severity: normal
> Tags: bullseye
> User: release.debian@packages.debian.org
> Usertags: pu
> X-Debbugs-Cc: debian-gl...@lists.debian.org
> 
> [ Reason ]
> During the upgrade from Buster to Bullseye, the SSH server is not
> restarted following the libc6 upgrade, causing new SSH connections to
> get rejected until the SSH server is restarted later in the upgrade.
> 
> It could be considered as a regression as it didn't happen during the
> upgrade from Stretch to Buster.
> 
> [ Impact ]
> Upgrade might fail or get stuck for remote upgrade using SSH if for some
> reason the SSH connection breaks. Using screen or tmux doesn't help here
> as it is not possible to connect again using SSH.
> 
> [ Tests ]
> This is not covered by any automated test. This has been tested using a
> VM with a fresh Buster installation. This code is in unstable for a few
> days, and no issue has been reported so far.

Please note that the code is now in testing.

Regards,
Aurelien

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

Bug#993394: transition: glibc 2.32

[Aurelien Jarno]

On 2021-08-31 20:54, Aurelien Jarno wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> X-Debbugs-Cc: debian-gl...@lists.debian.org
> 
> Dear release team,
> 
> I would like to get a transition slot for glibc 2.32. It has been built
> successfully on all release architectures except mips*el, however I have
> successfully built them manually on eller.d.o. It also builds fine on most
> ports architectures.

It has been finally built on mipsel and mips64el, successfully.

Regards,
Aurelien

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

Bug#993538: libzapojit: CVE-2021-39360

[Salvatore Bonaccorso]

Source: libzapojit
Version: 0.0.3-5
Severity: important
Tags: security upstream
Forwarded: https://gitlab.gnome.org/GNOME/libzapojit/-/issues/4
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for libzapojit.

CVE-2021-39360[0]:
| In GNOME libzapojit through 0.0.3, zpj-skydrive.c does not enable TLS
| certificate verification on the SoupSessionSync objects it creates,
| leaving users vulnerable to network MITM attacks. NOTE: this is
| similar to CVE-2016-20011.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2021-39360
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-39360
[1] https://gitlab.gnome.org/GNOME/libzapojit/-/issues/4

Regards,
Salvatore

Bug#993133: shiro 1.3.2-4+deb11u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 993133 = bullseye pending
thanks

Hi,

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

Thanks for your contribution!

Upload details
==

Package: shiro
Version: 1.3.2-4+deb11u1

Explanation: fix authentication bypass issues [CVE-2020-1957 CVE-2020-11989 
CVE-2020-13933 CVE-2020-17510]; update Spring Framework compatibility patch; 
support Guice 4

Bug#992978: mbrola 3.3+dfsg-4+deb11u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 992978 = bullseye pending
thanks

Hi,

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

Thanks for your contribution!

Upload details
==

Package: mbrola
Version: 3.3+dfsg-4+deb11u1

Explanation: fix end of file detection

Bug#993537: gfbgraph: CVE-2021-39358

[Salvatore Bonaccorso]

Source: gfbgraph
Version: 0.2.4-1
Severity: important
Tags: security upstream
Forwarded: https://gitlab.gnome.org/GNOME/libgfbgraph/-/issues/17
X-Debbugs-Cc: car...@debian.org, Debian Security Team 
Control: found -1 0.2.3-3

Hi,

The following vulnerability was published for gfbgraph.

CVE-2021-39358[0]:
| In GNOME libgfbgraph through 0.2.4, gfbgraph-photo.c does not enable
| TLS certificate verification on the SoupSessionSync objects it
| creates, leaving users vulnerable to network MITM attacks. NOTE: this
| is similar to CVE-2016-20011.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2021-39358
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-39358
[1] https://gitlab.gnome.org/GNOME/libgfbgraph/-/issues/17

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#993535: linux: Enable CONFIG_EVM

[Petr Vorel]

> I'd also consider to enable non-default CONFIG_EVM_ATTR_FSUUID.

Actually CONFIG_EVM_ATTR_FSUUID is enabled by default. But I'd consider
enabling
also CONFIG_ENCRYPTED_KEYS as it's enabled for Ubuntu [1]

Thanks!

Kind regards,
Petr

[1]
https://patchwork.ozlabs.org/project/ubuntu-kernel/patch/1403911081-32056-6-git-send-email-tyhi...@canonical.com/

Bug#993277: krb5 1.18.3-6+deb11u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 993277 = bullseye pending
thanks

Hi,

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

Thanks for your contribution!

Upload details
==

Package: krb5
Version: 1.18.3-6+deb11u1

Explanation: fix KDC null dereference crash on FAST request with no server 
field [CVE-2021-37750]; fix memory leak in krb5_gss_inquire_cred

Bug#992078: libbluray 1.2.1-4+deb11u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 992078 = bullseye pending
thanks

Hi,

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

Thanks for your contribution!

Upload details
==

Package: libbluray
Version: 1.2.1-4+deb11u1

Explanation: switch to embedded libasm. The version from libasm-java is too new

Bug#992435: devscripts 2.21.3+deb11u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 992435 = bullseye pending
thanks

Hi,

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

Thanks for your contribution!

Upload details
==

Package: devscripts
Version: 2.21.3+deb11u1

Explanation: make --bpo target bullseye-backports

Bug#993049: rpki-trust-anchors 20210817-1~deb11u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 993049 = bullseye pending
thanks

Hi,

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

Thanks for your contribution!

Upload details
==

Package: rpki-trust-anchors
Version: 20210817-1~deb11u1

Explanation: add https URL to the LACNIC TAL

Bug#993536: xfce4-panel: Wrong copyright year for 4.16.3

[Brendon]

Package: xfce4-panel
Version: 4.16.3-1
Severity: minor
X-Debbugs-Cc: ed7-aspire4...@hotmail.com

Issue: The version in question isn't released in 2018.

Remedy: Pull `panel/panel-dialogs.c` from upstream which has the new copyright 
year of 2021.


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

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

Versions of packages xfce4-panel depends on:
ii  exo-utils4.16.2-1
ii  libatk1.0-0  2.36.0-2
ii  libc62.31-17
ii  libcairo21.16.0-5
ii  libdbusmenu-gtk3-4   18.10.20180917~bzr492+repack1-2+b1
ii  libexo-2-0   4.16.2-1
ii  libgarcon-1-04.16.1-1
ii  libgarcon-gtk3-1-0   4.16.1-1
ii  libgdk-pixbuf-2.0-0  2.42.6+dfsg-2
ii  libglib2.0-0 2.68.4-1
ii  libgtk-3-0   3.24.30-2
ii  libpango-1.0-0   1.48.9+ds1-2
ii  libpangocairo-1.0-0  1.48.9+ds1-2
ii  libwnck-3-0  3.36.0-1+b1
ii  libx11-6 2:1.7.2-1
ii  libxext6 2:1.3.3-1.1
ii  libxfce4panel-2.0-4  4.16.3-1
ii  libxfce4ui-2-0   4.16.0-1+b1
ii  libxfce4util74.16.0-1
ii  libxfconf-0-34.16.0-2

xfce4-panel recommends no packages.

xfce4-panel suggests no packages.

-- no debconf information

Bug#992692: general: Use https for {deb,security}.debian.org by default

[Simon Richter]

Hi,

On 02.09.21 03:22, Hideki Yamane wrote:


  Providing "default secure setting" is good message to users.


The TLS layer is not part of the security model, so we'd be teaching 
users to look for the wrong thing, kind of like the "encrypted with SSL" 
badges on web pages in the 90ies.


We have our own PKI that is decoupled from the X.509 certificate 
infrastructure, and neither ascribes any trust in them nor depends on 
the availability of an external service.


As it is now, I can install a Debian system where no X.509 certificate 
authorities are trusted.


 - If I deselect all CAs in the configuration dialog of the 
ca-certificates package, what mechanism will allow apt to work?
 - Do we want to pin the certificate provider for Debian mirrors, in 
the knowledge that we want to be bound to this provider for several 
years, do we want any "root" CA to be able to provide a trust anchor?
 - Is there a revocation mechanism by which we can mark "root" CAs as 
untrustworthy?

 - What does the UI look like if OSCP verification fails?
 - How do mirror operators get a signed certificate?

I think we're adding a lot of complexity and external dependencies to 
the system here, which adds a lot of burden to mirror operators that 
aren't large CDNs. That may be acceptable for an entity like Ubuntu, who 
aren't dependent on donations, but we would be tied to the goodwill of 
CDN operators here, so:


 - do we wish to communicate that the existing mirrors outside 
deb.debian.org are somehow less "secure"?
 - do we have a contingency plan if deb.debian.org hosting on Fastly is 
no longer feasible?


   Simon

Bug#579790:

[Olivia Wood]

Bitte kontaktieren Sie Herrn Alvin Walker für weitere Informationen zu
Ihrem Geldtransfer unter alvinwalker...@gmail.com

Bug#993391: [pkg-lxc-devel] Bug#993391: Bug#993391: lxc: Unprivileged lxc example from README.Debian.gz gives AppArmor error "Failed to mount proc"

[Pierre-Elliott Bécue]

pk  writes:

> Can you post your complete config for autopkgtest-lxc-xwkkud,
> autopkgtest-unstable or other working unpriv container? Your output
> reads "unprivileged true".

Because they are unprivileged which is the topic of the current
discussion.

--
PEB


signature.asc
Description: PGP signature

Bug#993535: linux: Enable CONFIG_EVM

[Petr Vorel]

Source: linux
Version: linux-support-5.13.0-trunk
Severity: wishlist

Dear Maintainer,

#972459 reenabled CONFIG_IMA for linux/5.13.9-1~exp1 (thanks!). Could you please
enable also CONFIG_EVM, as EVM is commonly used with IMA?

I'd also consider to enable non-default CONFIG_EVM_ATTR_FSUUID.

If you have additional questions about the setup, feel free to ask on
linux-integrity ML or directly Mimi Zohar (IMA/EVM maintainer).

Thanks!

Kind regards,
Petr

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

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

Bug#993391: [pkg-lxc-devel] Bug#993391: lxc: Unprivileged lxc example from README.Debian.gz gives AppArmor error "Failed to mount proc"

[Pierre-Elliott Bécue]

Hi,

pk  writes:

> Hello,
>
> I copy-pasted configuration and commands from
> /usr/share/doc/lxc/README.Debian.gz under "Unprivileged containers".
> Are you talking about another file?
> https://salsa.debian.org/lxc-team/lxc/-/blob/7d692c266c63fced9417042ae904cc2a280b96d8/debian/README.Debian

The configuration in that file is 

  lxc.include = /etc/lxc/default.conf
  lxc.idmap = u 0 10 65536
  lxc.idmap = g 0 10 65536
  lxc.mount.auto = proc:mixed sys:ro cgroup:mixed
  lxc.apparmor.profile = unconfined

and goes to ~/.config/lxc/default.conf

You removed at least the lxc.include statement, and actually tried
something of your own, in particular not creating a default config for
your user and a container afterwards.

> lxc.rootfs defaults to the system root / per lxc.container.conf(5).

Which is not acceptable for an *unprivileged* container, which is the
case you brought here. The reason why Apparmor intervenes instead of
letting either init crash upon startup (because not being able to
manipulate the filesystem) or things explode is because
lxc.apparmor.profile doesn't apply to lxc-start call, but to only to the
lxc child process.

> Creation is unnecessary, it is just a convenience to avoid -f and does
> not affect the container runtime. My (still privileged) lxc setup
> works perfectly with -f without ever creating any containers.

Creation is necessary as you need a valid rootfs to work, and a valid
rootfs for an unprivileged container has to fit the usernamespace which
will be created upon startup of the container. "/" is not a valid rootfs
for an unprivileged container as the uid mappings are totally out of
line. You therefore need to at least create one container using
lxc-create or manually create a rootfs using mmdebstrap or whatever fits
best.

> I pasted full logs above.

You pasted truncated logs, and actually did not follow the README.

> Please try to be respectful and helpful, do not reproduce on a
> configured machine, and leave bug triaging to the lxc experts.

Being one of the LXC maintainers, I'm totally entitled to triage your
bug report, especially since what you claim being a bug does not look
like one. I won't reply to your assumption about my expertise.

Please follow the README properly and if that fails please come back
with full logs.

With best regards,
--
PEB


signature.asc
Description: PGP signature

Bug#993534: 389-ds-base breaks dogtag-pki autopkgtest: CA spawn failed

[Paul Gevers]

Source: 389-ds-base, dogtag-pki
Control: found -1 389-ds-base/1.4.4.16-1
Control: found -1 dogtag-pki/10.10.2-3
Severity: serious
Tags: sid bookworm
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: breaks needs-update

Dear maintainer(s),

With a recent upload of 389-ds-base the autopkgtest of dogtag-pki fails
in testing when that autopkgtest is run with the binary packages of
389-ds-base from unstable. It passes when run with only packages from
testing. In tabular form:

   passfail
389-ds-basefrom testing1.4.4.16-1
dogtag-pki from testing10.10.2-3
all others from testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration of 389-ds-base to
testing [1]. Due to the nature of this issue, I filed this bug report
against both packages. Can you please investigate the situation and
reassign the bug to the right package?

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

Paul

[1] https://qa.debian.org/excuses.php?package=389-ds-base

https://ci.debian.net/data/autopkgtest/testing/amd64/d/dogtag-pki/14986372/log.gz

autopkgtest [09:10:45]: test pkispawn: [---
 IP address is 192.168.122.100
 Hostname was:
 /etc/hosts now has:
127.0.0.1   localhost
::1 localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters

192.168.122.100 autopkgtest.debci autopkgtest
Starting installation...
Completed installation for pki-tomcat
Notice: Trust flag u is set automatically if the private key is present.
/usr/lib/python3/dist-packages/urllib3/connection.py:455:
SubjectAltNameWarning: Certificate for autopkgtest.debci has no
`subjectAltName`, falling back to check for a `commonName` for now. This
feature is being removed by major browsers and deprecated by RFC 2818.
(See https://github.com/urllib3/urllib3/issues/497 for details.)
  warnings.warn(
Loading deployment configuration from debian/tests/deploy.cfg.
Installation log: /var/log/pki/pki-ca-spawn.20210902091106.log
Installing CA into /var/lib/pki/pki-tomcat.

Installation failed:
HTTP Status 404 – Not
Foundbody
{font-family:Tahoma,Arial,sans-serif;} h1, h2, h3, b
{color:white;background-color:#525D76;} h1 {font-size:22px;} h2
{font-size:16px;} h3 {font-size:14px;} p {font-size:12px;} a
{color:black;} .line
{height:1px;background-color:#525D76;border:none;}HTTP
Status 404 – Not FoundType Status
ReportMessage The requested resource
[caadmincagetStatus] is not
availableDescription The origin server did not find a
current representation for the target resource or is not willing to
disclose that one exists.Apache Tomcat/9.0.43
(Debian)

Please check the CA logs in /var/log/pki/pki-tomcat/ca.
 CA spawn failed:
autopkgtest [09:12:24]: test pkispawn: ---]



OpenPGP_signature
Description: OpenPGP digital signature

Bug#993533: netgen: please mark autopkgtest as superficial

[Paul Gevers]

Source: netgen
Version: 6.2.2006+really6.2.1905+dfsg-2.1
Severity: important
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: issue

Hi Maintainer,

Your package has an autopkgtest, great. However, I noticed that the test
coverage is very limited. Because of the way the results of autopkgtests
are used in Debian to influence migration, the Release Team demands [1]
such tests to be marked as superficial.

Paul

[1] https://release.debian.org/testing/rc_policy.txt 6(a)





OpenPGP_signature
Description: OpenPGP digital signature

Bug#993507: libgnutls30: fails to negotiate X25519 where NSS & OpenSSL succeed, success with X448

[Lionel Élie Mamane]

tags 993507 +upstream
forwarded 993507 https://gitlab.com/gnutls/gnutls/-/issues/1249
retitle 993507 libgnutls30: client 'illegal parameter' error when both X25519 
and X448 are enabled and the server picks one of those
thanks

On Thu, Sep 02, 2021 at 12:04:02PM +0200, Lionel Elie Mamane wrote:
> $ gnutls-cli --priority 
> 'NORMAL:-GROUP-SECP256R1:-GROUP-SECP384R1:-GROUP-SECP521R1' fxtop.com
> *** Fatal error: An illegal parameter has been received.

> $ gnutls-cli --priority 
> 'NORMAL:-GROUP-SECP256R1:-GROUP-SECP384R1:-GROUP-SECP521R1:-GROUP-X25519' 
> fxtop.com
> - Description: (TLS1.3)-(ECDHE-X448)-(RSA-PSS-RSAE-SHA256)-(AES-256-GCM)

$ gnutls-cli --priority 'NORMAL:-GROUP-ALL:+GROUP-X25519' fxtop.com
succeeds, too, in line with the upstream bug description,

It is not immediately obvious to me in what released version that
upstream bug is fixed.

-- 
Lionel

Bug#993526: thunderbird: Movemail support removed in Thunderbird v91

[Mikhail Morfikov]

On 02/09/2021 19.41, Carsten Schoenert wrote:
> You need to keep the BTS within the mail loop so others can follow
> the conversion too!

I know, I just miss-clicked the wrong button -- I think they should 
work on this instead of removing the useful features. :]

> 
> Am 02.09.21 um 19:34 schrieb Mikhail Morfikov:
>> At least to notify people about this change with upgrade to v91
>> because I was really surprised when one of my accounts disappeared
>> without any info.
> 
> Did you have read the official release notes?
> 
> https://www.thunderbird.net/en-US/thunderbird/91.0/releasenotes/
> 
> It's listed under changes. I see no gain to duplicate this
> information somewhere in Debian.

Most people don't read the official release notes if they don't have 
to. So if there's no one who would speak about some important change 
at the Debian lvl, no one will even bother with the official release 
notes, and it's not just for TB, but it's a general rule. That's why 
the Debian news/changelogs files are so important.

> 
>> Maybe if more people will complain about the feature removal, the 
>> upstream will bring it back.
> 
> Maybe, but I expect no return of this feature.
> 

It's sad that people think in this way. But if TB wants to have 
less and less user base, I think it's on the right way. And we all 
know where it ends.

Bug#993393: sensible-utils: [INTL:de] updated German man page translation

[Helge Kreutzmann]

Hello Bastien,
On Wed, Sep 01, 2021 at 08:04:00PM +, Bastien Roucariès wrote:
> This is not a patch how can I apply ?

This is the updated file. Just place it in man/po4a. As it has been
done (by you) several times in the past already. (And happens in any
other case as well).

Greetings

  Helge


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


signature.asc
Description: PGP signature

Bug#993169: fixed in eckit 1.17.1-2

[Paul Gevers]

Dear Alastair,

On Sun, 29 Aug 2021 12:03:45 + Debian FTP Masters
 wrote:

>* Drop support for 32-bit archs. Closes: #993169

Don't forget to ask ftp-master to remove the existing binaries on those
architectures where it built in the past.

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#993532: libpod: autopkgtest regression between 29 Aug 2021 and 2 Sep 2021

[Paul Gevers]

Source: libpod
Version: 3.0.1+dfsg1-3
Severity: serious
User: debian...@lists.debian.org
Usertags: regression
X-Debbugs-CC: debian...@lists.debian.org

Dear maintainer(s),

Your package has an autopkgtest, great! However, somewhere between four
days ago and today it started to fail [1]. Unfortunately our migration
setup didn't catch this because it's either caused by something external
to the archive, or the package that caused it is in not a direct (build)
dependency of your packages. Looking at the error, I have no clue why.
Can you fix the situation?

Paul

[1] https://ci.debian.net/packages/libp/libpod/

https://ci.debian.net/data/autopkgtest/testing/amd64/libp/libpod/14990105/log.gz

dh_auto_build: error: cd _output && go install -trimpath -v -p 2 -tags
apparmor,ostree,seccomp,selinux,systemd -ldflags "-X
main.buildInfo=3.0.1+dfsg1-3" github.com/containers/podman/cmd/podman
github.com/containers/podman/cmd/podman/common
github.com/containers/podman/cmd/podman/completion
github.com/containers/podman/cmd/podman/containers
github.com/containers/podman/cmd/podman/generate
github.com/containers/podman/cmd/podman/healthcheck
github.com/containers/podman/cmd/podman/images
github.com/containers/podman/cmd/podman/inspect
github.com/containers/podman/cmd/podman/manifest
github.com/containers/podman/cmd/podman/networks
github.com/containers/podman/cmd/podman/parse
github.com/containers/podman/cmd/podman/play
github.com/containers/podman/cmd/podman/pods
github.com/containers/podman/cmd/podman/registry
github.com/containers/podman/cmd/podman/system
github.com/containers/podman/cmd/podman/system/connection
github.com/containers/podman/cmd/podman/utils
github.com/containers/podman/cmd/podman/validate
github.com/containers/podman/cmd/podman/volumes
github.com/containers/podman/libpod
github.com/containers/podman/libpod/common
github.com/containers/podman/libpod/define
github.com/containers/podman/libpod/driver
github.com/containers/podman/libpod/events
github.com/containers/podman/libpod/image
github.com/containers/podman/libpod/layers
github.com/containers/podman/libpod/linkmode
github.com/containers/podman/libpod/lock
github.com/containers/podman/libpod/lock/file
github.com/containers/podman/libpod/lock/shm
github.com/containers/podman/libpod/logs
github.com/containers/podman/libpod/logs/reversereader
github.com/containers/podman/libpod/network
github.com/containers/podman/libpod/plugin
github.com/containers/podman/libpod/shutdown
github.com/containers/podman/pkg/annotations
github.com/containers/podman/pkg/api/handlers
github.com/containers/podman/pkg/api/handlers/compat
github.com/containers/podman/pkg/api/handlers/libpod
github.com/containers/podman/pkg/api/handlers/swagger
github.com/containers/podman/pkg/api/handlers/utils
github.com/containers/podman/pkg/api/server
github.com/containers/podman/pkg/api/server/idle
github.com/containers/podman/pkg/api/types
github.com/containers/podman/pkg/auth
github.com/containers/podman/pkg/autoupdate
github.com/containers/podman/pkg/bindings
github.com/containers/podman/pkg/bindings/containers
github.com/containers/podman/pkg/bindings/generate
github.com/containers/podman/pkg/bindings/generator
github.com/containers/podman/pkg/bindings/images
github.com/containers/podman/pkg/bindings/manifests
github.com/containers/podman/pkg/bindings/network
github.com/containers/podman/pkg/bindings/play
github.com/containers/podman/pkg/bindings/pods
github.com/containers/podman/pkg/bindings/system
github.com/containers/podman/pkg/bindings/util
github.com/containers/podman/pkg/bindings/volumes
github.com/containers/podman/pkg/cgroups
github.com/containers/podman/pkg/channel
github.com/containers/podman/pkg/checkpoint
github.com/containers/podman/pkg/copy
github.com/containers/podman/pkg/criu
github.com/containers/podman/pkg/ctime
github.com/containers/podman/pkg/domain/entities
github.com/containers/podman/pkg/domain/entities/reports
github.com/containers/podman/pkg/domain/filters
github.com/containers/podman/pkg/domain/infra
github.com/containers/podman/pkg/domain/infra/abi
github.com/containers/podman/pkg/domain/infra/abi/parse
github.com/containers/podman/pkg/domain/infra/abi/terminal
github.com/containers/podman/pkg/domain/infra/tunnel
github.com/containers/podman/pkg/domain/utils
github.com/containers/podman/pkg/env
github.com/containers/podman/pkg/errorhandling
github.com/containers/podman/pkg/hooks
github.com/containers/podman/pkg/hooks/0.1.0
github.com/containers/podman/pkg/hooks/1.0.0
github.com/containers/podman/pkg/hooks/exec
github.com/containers/podman/pkg/inspect
github.com/containers/podman/pkg/kubeutils
github.com/containers/podman/pkg/lookup
github.com/containers/podman/pkg/namespaces
github.com/containers/podman/pkg/netns
github.com/containers/podman/pkg/parallel
github.com/containers/podman/pkg/parallel/ctr
github.com/containers/podman/pkg/ps
github.com/containers/podman/pkg/ps/define
github.com/containers/podman/pkg/registrar
github.com/containers/podman/pkg/registries

Bug#993531: lintian: doesn't know about conffile remove-on-upgrade tag

[Baptiste Beauplat]

Package: lintian
Version: 2.104.0
Severity: normal

Dear Maintainer,

I was building my package (chkboot 1.3-8) when lintian reported the
following tags:

```
E: chkboot: conffile-is-not-in-package remove-on-upgrade 
/etc/kernel/postinst.d/zzz-chkboot
E: chkboot: conffile-is-not-in-package remove-on-upgrade 
/etc/kernel/postrm.d/zzz-chkboot
E: chkboot: non-etc-file-marked-as-conffile remove-on-upgrade 
/etc/kernel/postinst.d/zzz-chkboot
E: chkboot: non-etc-file-marked-as-conffile remove-on-upgrade 
/etc/kernel/postrm.d/zzz-chkboot
E: chkboot: relative-conffile remove-on-upgrade 
/etc/kernel/postinst.d/zzz-chkboot
E: chkboot: relative-conffile remove-on-upgrade /etc/kernel/postrm.d/zzz-chkboot
```

Based on the following conffile generated by dpkg 1.20.9 and debhelper
13.5.1:

```
remove-on-upgrade /etc/kernel/postinst.d/zzz-chkboot
remove-on-upgrade /etc/kernel/postrm.d/zzz-chkboot
/etc/apt/apt.conf.d/05chkboot
/etc/default/chkboot
/etc/init.d/chkboot
/etc/profile.d/chkboot-profilealert.sh
```

The remove-on-upgrade tag is a new feature from dpkg 1.20.6 as stated in
deb-conffiles(5):

```
There is currently only one flag supported, remove-on-upgrade, to mark
that a conffile needs to be removed on the next upgrade (since dpkg
1.20.6).  These files must not exist in the binary package, as both
dpkg(1) and dpkg-deb(1) will not accept building nor processing such
binary packages.
```

Lintian should skip the tag if present while checking for the given
tags.

Best,

-- 
Baptiste Beauplat - lyknode


signature.asc
Description: PGP signature

Bug#993527: [debian-mysql] Bug#993527: mariadb-server: At full-upgrade from buster to bullseye mariadb-server (and also client) are removed.

[Otto Kekäläinen]

Please test with the version in Debian testing.

An identical version is about to enter Bullseye in next stable update.

Bug#993526: thunderbird: Movemail support removed in Thunderbird v91

[Carsten Schoenert]

You need to keep the BTS within the mail loop so others can follow the 
conversion too!


Am 02.09.21 um 19:34 schrieb Mikhail Morfikov:

At least to notify people about this change with upgrade to v91 because
I was really surprised when one of my accounts disappeared without any
info.


Did you have read the official release notes?

https://www.thunderbird.net/en-US/thunderbird/91.0/releasenotes/

It's listed under changes. I see no gain to duplicate this information 
somewhere in Debian.



Maybe if more people will complain about the feature removal, the
upstream will bring it back.


Maybe, but I expect no return of this feature.

--
Regards
Carsten

Bug#993526: thunderbird: Movemail support removed in Thunderbird v91

[Carsten Schoenert]

Hello Mikhail,

Am 02.09.21 um 18:05 schrieb Mikhail Morfikov:


It looks like that with the version of 91, Thunderbird removed support for
Movemail accounts. There's no way to setup such account anymore with this
version, and all already present account are removed without any info or
warning. At least the mail stayed intact. I had to install the previous version
(1:78.13.0-1) to revert the unpleasant change.


and what do you expect as further action?
If you want to complain about the removal you need to address this to 
MZLNA. Debian is packaging what upstream is providing, some things might 
need some adjustment to be in compliance with the Debian project rules. 
But at least for Thunderbird and similar packages we do not re-add and 
maintain features we can't keep up to date in the long run.


Following the bug report you pointed it's obvious that the user base is 
simply to small that it will come back in the near future.


I see no work I or Debian needs to do here and will close this report by 
this email.


--
Regards
Carsten

Bug#993530: ddcutil version bump

[Ross Vandegrift]

Package: enlightenment
Version: 0.24.2-8

- Forwarded message from Sanford Rockowitz  -

Date: Thu, 2 Sep 2021 01:11:11 -0400
From: Sanford Rockowitz 
To: pkg-e-de...@lists.alioth.debian.org
Cc: Andrey Rahmatullin 
Subject: Fwd: ddcutil version bump
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.23)
 Gecko/20090812 Thunderbird/2.0.0.23 Mnenhy/0.7.6.666

And, I neglected to mention, update Recommends: libddcutil3 to Recommends:
libddcutil4



 Forwarded Message 
Subject:ddcutil version bump
Date:   Wed, 1 Sep 2021 23:45:37 -0400
From:   Sanford Rockowitz 
Organization:   Minaret Software
To: pkg-e-de...@lists.alioth.debian.org
CC: Andrey Rahmatullin 



The latest ddcutil release (1.1.0) that's about to go into sid increments the
shared library to libddcutil.so.4.  I've reviewed the code in file
e_system_ddc.c.  There are no changes that affect your use of the API.  All
you need to do is check for libddcutil.so.4 before libddcutil.so.3 and
libddcutil.so.2.

Regards,
Sanford Rockowitz
ddcutil developer

-- 
Pkg-e-devel mailing list
pkg-e-de...@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-e-devel


- End forwarded message -

Bug#984849: dpkg-divert: too sensitive to order of command-line args

[Ross Vandegrift]

Hello,

On Thu, Sep 02, 2021 at 04:16:36AM +0200, Guillem Jover wrote:
> On Mon, 2021-03-08 at 22:35:49 -0800, Ross Vandegrift wrote:
> > dpkg-divert is too sensitive to the order of the command line parameters.
> > Since I only use it rarely, I almost always run into:
> > 
> >   # dpkg-divert --add /wooo --divert /yeah --rename
> >   dpkg-divert: warning: please specify --no-rename explicitly, the default 
> > will change to --rename in 1.20.x
> >   dpkg-divert: error: --add needs a single argument
> >   
> >   Use --help for help about diverting files.
> > 
> > The fix is to move --add last.  But neither the error nor the manpage makes
> > that clear.
> 
> Both the man page and the --help output mention that the usage is:
> 
>   dpkg-divert [...] 
> 
> And then go to list the commands and options on their respective
> sections. While I guess I could add a hint or similar on the error
> message (because modifying the way this is parsed would be a pain),
> that seems it would be too specific for such a generic message. So
> I'm inclined to leave it as is, TBH. If you have an alternative
> suggestion I'm happy to consider, otherwise I'm afraid I'll just
> going to close the report.

I don't have any good suggestions - I think usage would be more obvious
if the commands weren't prefixed with dashes, but that would cause much
worse breakage.  If the parsing is too hard to change, then leaving it
as-is is sounds reasonable.

Thanks for thinking about it, feel free to close.

Ross

Bug#992692: general: Use https for {deb,security}.debian.org by default

[Jeremy Stanley]

On 2021-09-02 12:27:34 -0400 (-0400), Roberto C. Sánchez wrote:
[...]
> In this context, it might make sense to describe using HTTPS as
> the transport for APT operations is providing "default
> confidentiality".

Which, as similarly discussed, it really doesn't do either (because
of deterministic blob sizes for publicly served files, current SNI
implementations leaking hostnames, general state of the CA and CDN
industries...), so suggesting that may also give users a false
impression. If they really do need confidentiality of their package
installation, they're probably better off doing updates over Tor or
a some VPN which does batching/interleaving of bulk transfers with
some cover traffic, or keeping a private local package mirror.

But to a great extent the degree of confidentiality they can expect
really depends on who they're trying to hide their traffic from. If
their concern is that a company headquartered in the USA might be
tracking the packages they're downloading from deb.debian.org, then
that's already a possibility even with HTTPS: the site is currently
fronted by the Fastly CDN service which terminates TLS encryption
for those HTTPS requests in order to be able to cache them globally.
Of course, without a CDN, mirror site operators can track what
packages you're downloading from them over HTTPS as well.

More generally, what I'm saying is don't try to paint this change as
actually implementing any significant amount of new security or
privacy for Debian users, that would be disingenuous. Just say the
default is switching to HTTPS because that's what users, by and
large, expect today.
-- 
Jeremy Stanley


signature.asc
Description: PGP signature

Bug#983591: iproute2: running 'ip -6 -r route' results in printing an unitialized buffer for the hostname on 'dev' routes

[Axel Scheepers]

Hello Luca,

On Thu, Sep 02, 2021 at 11:44:09AM +0100, Luca Boccassi wrote:
> This is fixed for me with 5.13, which is now in testing - can you
> confirm?

Yes indeed it works on testing for me too, thanks!

Kind regards,

Axel Scheepers

Bug#993529: mlocate: cruft left behind on purge

[Sven Joachim]

Package: mlocate
Version: 1.1.10-2
Severity: normal

I have noticed that some cruft remained on the system after purging the
mlocate package, namely

- a dangling symlink
  /etc/systemd/system/timers.target.wants/mlocate.timer

- a statoverride for /usr/bin/mlocate in the dpkg database

The postrm script in mlocate version 0.26-5 cleaned these up on purge,
for the transitional package it might make more sense to do it in the
postinst.

See the attached log file which reproduces the problems in a throwaway
chroot (install mlocate 0.26-5, upgrade to 1.1.10-2 and purge the
package).


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

Kernel: Linux 5.10.61-nouveau (SMP w/2 CPU threads)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

# find / -name "mlocate*"
/var/cache/apt/archives/mlocate_0.26-5_amd64.deb
# dpkg -i $(find / -name "mlocate*")
Selecting previously unselected package mlocate.
(Reading database ... 12635 files and directories currently installed.)
Preparing to unpack .../mlocate_0.26-5_amd64.deb ...
Unpacking mlocate (0.26-5) ...
Setting up mlocate (0.26-5) ...
update-alternatives: using /usr/bin/mlocate to provide /usr/bin/locate (locate) 
in auto mode
Adding group `mlocate' (GID 102) ...
Done.
# apt upgrade
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Calculating upgrade... Done
The following NEW packages will be installed:
  liburing1 plocate
The following packages will be upgraded:
  mlocate
1 upgraded, 2 newly installed, 0 to remove and 0 not upgraded.
Need to get 4544 B/133 kB of archives.
After this operation, 57.3 kB of additional disk space will be used.
Do you want to continue? [Y/n]
Get:1 http://ftp.de.debian.org/debian sid/main amd64 mlocate all 1.1.10-2 [4544 
B]
Fetched 4544 B in 0s (9658 B/s)
debconf: delaying package configuration, since apt-utils is not installed
Selecting previously unselected package liburing1:amd64.
(Reading database ... 12698 files and directories currently installed.)
Preparing to unpack .../liburing1_0.7-3_amd64.deb ...
Unpacking liburing1:amd64 (0.7-3) ...
Preparing to unpack .../mlocate_1.1.10-2_all.deb ...
Unpacking mlocate (1.1.10-2) over (0.26-5) ...
Selecting previously unselected package plocate.
Preparing to unpack .../plocate_1.1.10-2_amd64.deb ...
Unpacking plocate (1.1.10-2) ...
Setting up liburing1:amd64 (0.7-3) ...
Setting up plocate (1.1.10-2) ...
Installing new version of config file /etc/updatedb.conf ...
update-alternatives: warning: alternative /usr/bin/mlocate (part of link group 
locate) doesn't exist; removing from list of alternatives
update-alternatives: warning: /etc/alternatives/locate is dangling; it will be 
updated with best choice
update-alternatives: using /usr/bin/plocate to provide /usr/bin/locate (locate) 
in auto mode
Adding group `plocate' (GID 103) ...
Done.
Setting up mlocate (1.1.10-2) ...
Removing obsolete conffile /etc/cron.daily/mlocate ...
Processing triggers for libc-bin (2.31-17) ...
# apt purge mlocate
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following packages were automatically installed and are no longer required:
  liburing1 plocate
Use 'sudo apt autoremove' to remove them.
The following packages will be REMOVED:
  mlocate*
0 upgraded, 0 newly installed, 1 to remove and 0 not upgraded.
After this operation, 14.3 kB disk space will be freed.
Do you want to continue? [Y/n]
(Reading database ... 12659 files and directories currently installed.)
Removing mlocate (1.1.10-2) ...
(Reading database ... 12656 files and directories currently installed.)
Purging configuration files for mlocate (1.1.10-2) ...
# find / -name "mlocate*"
/etc/systemd/system/timers.target.wants/mlocate.timer
/var/cache/apt/archives/mlocate_0.26-5_amd64.deb
/var/lib/systemd/deb-systemd-helper-enabled/timers.target.wants/mlocate.timer
/var/lib/systemd/deb-systemd-helper-enabled/mlocate.timer.dsh-also
# dpkg-statoverride --list | grep mlocate
root mlocate 2755 /usr/bin/mlocate

Bug#992692: general: Use https for {deb,security}.debian.org by default

[Jeremy Stanley]

On 2021-09-02 10:22:15 +0900 (+0900), Hideki Yamane wrote:
[...]
>  Providing "default secure setting" is good message to users.
[...]

As previously covered, I'd suggest steering clear of referring to
this as adding "default security." That implies APT wasn't already
effectively secure over plain HTTP, and may give a false impression
that HTTPS is addressing gaps in the existing apt-secure design.

This change is more about recognizing HTTPS as the primary transport
protocol for the modern Web, not sending mixed signals regarding the
general security risks posed by plain HTTP when used for unrelated
purposes, and no longer needing to repeatedly explain to users that
Debian has gone to great lengths to implement package distribution
security which doesn't really depend at all on transport layer
encryption.
-- 
Jeremy Stanley


signature.asc
Description: PGP signature

Bug#993528: lintian-brush: debhelper-but-no-misc-depends.py does not consider Pre-Depends

[Sven Joachim]

Package: lintian-brush
Version: 0.109
Severity: normal

I have received a merge request from the Debian Janitor for ncurses
which looks incorrect to me, see my comment at [1].

It seems that the script fixers/debhelper-but-no-misc-depends.py does
not look at ${misc:Depends} in Pre-Depends, but should do so.


1. https://salsa.debian.org/debian/ncurses/-/merge_requests/5

Bug#898259: RFP: vscode -- Microsoft Visual Studio Code

[Jonathan Rubenstein]

On Thu, 7 Jan 2021 14:55:47 +0200 Anya Annetova 
 wrote:

Any progress on this?



See #842420, the blocker for this and many many other programs.

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


Jonathan Rubenstein
jrub...@gmail.com

Bug#992692: general: Use https for {deb,security}.debian.org by default

[Roberto C . Sánchez]

On Thu, Sep 02, 2021 at 04:08:37PM +, Jeremy Stanley wrote:
> On 2021-09-02 10:22:15 +0900 (+0900), Hideki Yamane wrote:
> [...]
> >  Providing "default secure setting" is good message to users.
> [...]
> 
> As previously covered, I'd suggest steering clear of referring to
> this as adding "default security." That implies APT wasn't already
> effectively secure over plain HTTP, and may give a false impression
> that HTTPS is addressing gaps in the existing apt-secure design.
> 
> This change is more about recognizing HTTPS as the primary transport
> protocol for the modern Web, not sending mixed signals regarding the
> general security risks posed by plain HTTP when used for unrelated
> purposes, and no longer needing to repeatedly explain to users that
> Debian has gone to great lengths to implement package distribution
> security which doesn't really depend at all on transport layer
> encryption.

In this context, it might make sense to describe using HTTPS as the
transport for APT operations is providing "default confidentiality".

Regards,

-Roberto

-- 
Roberto C. Sánchez

Bug#993527: mariadb-server: At full-upgrade from buster to bullseye mariadb-server (and also client) are removed.

[Sven Wagner]

Package: mariadb-server
Version: 1:10.5.11-1
Severity: normal
Tags: a11y

Dear Maintainer,
 
I upgraded my Webserver from Buster to Bullseye. During the upgrade 
mariadb-server and mariadb-client was removed from the server.
A apt install mariadb-server mariadb-client and everything was working
fine again, no loose of databases or other information. Only official
Debian sources in apt.sorces.list. 
A friend of mine told me that this happens yesterday night, so I tried 
today to report as bug if I can confirm.

Greetings and Thanks for your work on Debian

Sven

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

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

Versions of packages mariadb-server depends on:
ii  mariadb-server-10.5  1:10.5.11-1

mariadb-server recommends no packages.

mariadb-server suggests no packages.

-- no debconf information

Bug#954998: libconfig-model-dpkg-perl: cme edit dpkg does not start

[Dominique Dumont]

Hi

Sorry for the late reply. I had a freelance mission from April to August that 
did not leave me much free time (or energy).

On Thu, 26 Mar 2020 10:38:38 -0500 Ryan Pavlik  wrote:
> Recently, I have had cme edit dpkg stop working on my Buster system, which 
is mostly clean,
> with some use of buster-backports. This seemed to occur in conjunction with 
an update in which 
> lintian was upgraded - lintian (2.59.0~bpo10+1) over (2.55.0~bpo10+1). 
However, downgrading
> (to 2.57~bpo10+1 at least) did not resolve it, so perhaps it was something 
unrelated.

Lintian 2.57 brought a change to an API that broke cme.

Long story short, libconfig-model-dpkg-perl >= 2.132 depends on lintian >= 2.57

And libconfig-model-dpkg-perl < 2.132 must use lintian < 2.57

Please get back to me if this is too inconvenient to backport cme and I'll 
suggest a patch to cope with this breakage in lintian API.

HTH

Dod

Bug#993501: Merge request on Salsa

[Mattias Ellert]

Hi.

I have created a merge request on salsa for this fix.

https://salsa.debian.org/debian/openssl/-/merge_requests/6

Mattias



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

Bug#993526: thunderbird: Movemail support removed in Thunderbird v91

[Mikhail Morfikov]

Package: thunderbird
Version: 1:91.0~b5-1
Severity: important

Dear Maintainer,

It looks like that with the version of 91, Thunderbird removed support for
Movemail accounts. There's no way to setup such account anymore with this
version, and all already present account are removed without any info or
warning. At least the mail stayed intact. I had to install the previous version
(1:78.13.0-1) to revert the unpleasant change.

More info at:

https://developer.thunderbird.net/planning/roadmap
https://bugzilla.mozilla.org/show_bug.cgi?id=1625741

Bug#989051: mrc: FTBFS on hppa - obj/mrc_rsrc.o created with wrong OS/ABI

[Maarten L. Hekkelman]

Dear Dave,

Thanks for reporting, and apologies for not responding earlier.

I found the underlying problem, apparently the ABI field of the ELF 
header should contain a flag indicating it is a Linux executable. In 
order to set this flag properly, I need to find out various things and 
perhaps it is easiest to try to figure out these myself. Is it possible 
to get access to a HPPA machine running Debian? I am a Debian 
maintainer, if that makes any difference.


Otherwise, could you provide me the output of `cpp -dM /dev/null` and 
perhaps also how to detect PA-RISC/Debian in a cmake file. That last 
question is perhaps a bit too much to ask for, but any hint is appreciated.


regards, -maarten


Op 24-05-2021 om 20:09 schreef John David Anglin:

Source: mrc
Version: 1.2.3-2
Severity: normal

Dear Maintainer,

The build fails with the following error:

make[1]: Entering directory '/<>'

mrc.cpp
dummy.cpp

g++ -std=c++17 -o mrc-bootstrap obj/mrc.o obj/dummy.o -L/usr/lib/hppa-linux-gnu 
-lboost_program_options
./mrc-bootstrap -o obj/mrc_rsrc.o mrsrc.h
g++ -std=c++17 -o mrc obj/mrc.o obj/mrc_rsrc.o -L/usr/lib/hppa-linux-gnu 
-lboost_program_options
/usr/bin/ld: unknown architecture of input file `obj/mrc_rsrc.o' is 
incompatible with hppa1.1 output
collect2: error: ld returned 1 exit status
make[1]: *** [GNUmakefile:87: mrc] Error 1

As far as I can tell, this occurs because obj/mrc_rsrc.o is created with the
wrong OS/ABI:

dave@mx3210:~/debian/mrc/mrc-1.2.3$ file obj/mrc_rsrc.o
obj/mrc_rsrc.o: ELF 32-bit MSB relocatable, PA-RISC, 1.1 version 1 (SYSV), not 
stripped

SYSV should be GNU/Linux:

dave@mx3210:~/debian/mrc/mrc-1.2.3$ file obj/mrc.o
obj/mrc.o: ELF 32-bit MSB relocatable, PA-RISC, 1.1 version 1 (GNU/Linux), with 
debug_info, not stripped

Not sure why this happens.

Regards,
Dave Anglin

-- System Information:
Debian Release: 11.0
   APT prefers buildd-unstable
   APT policy: (500, 'buildd-unstable'), (500, 'unstable')
Architecture: hppa (parisc64)

Kernel: Linux 5.10.39+ (SMP w/4 CPU threads)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)




--
Maarten L. Hekkelman
http://www.hekkelman.com/