Bug#991159: ITP: golang-github-google-cel-go -- go library for evaluation of Common Expression Language

[Peymaneh Nejad]

Package: wnpp
Severity: wishlist
Owner: Peymaneh Nejad 

* Package name: golang-github-google-cel-go
  Version : 0.7.3-1
  Upstream Author : Google
* URL : https://github.com/google/cel-go
* License : Apache-2.0
  Programming Lang: Go
  Description : go library for evaluation of Common Expression Language
 The Common Expression Language (CEL) is a non-Turing complete language
 designed for simplicity, speed, safety, and portability.

This is a dependency of caddy caddy (#810890)

Bug#991052: golang-google-grpc-dev: Outdated package

[Peymaneh Nejad]

Am 13.07.21 um 14:42 schrieb Peymaneh Nejad:

Dear Maintainer,

Could you please update the package?


Oh, I forgot to mention: If you like, I'd be happy update the package myself
Please let me know

kind regards,

Peymaneh





OpenPGP_signature
Description: OpenPGP digital signature

Bug#980472: cubicsdr: CubicSDR crashes after lauch! (same effect on 2 clean bullseye OS)

[tony mancill]

On Tue, Jun 01, 2021 at 02:06:33AM +0300, Adrian Bunk wrote:
> Control: reassign -1 libhamlib4 4.0-6
> Control: fixed -1 4.1-1
> Control: affects -1 cubicsdr
> Control: forwarded -1 
> https://sourceforge.net/p/hamlib/code/ci/31dedcf4f79d8fc5fcf287360e5d017842c8e4c0/
> 
> The oneline fix for hamlib above matches your analysis exactly.

And indeed it does!  Thank you for the pointer Adrian.

I was able to reproduce the crash with cubicsdr locally using a basic
RTL2832U dongle.  Then I built and tested with the reference patch and
cubicsdr is working for me.  I also did a very quick check of wsjtx.

Any concerns with an upload to unstable, hopefully in time a last-second
unblock request for bullseye?  (debdiff attached)

Cheers,
tony
diff -Nru hamlib-4.0/debian/changelog hamlib-4.0/debian/changelog
--- hamlib-4.0/debian/changelog 2021-05-11 10:03:12.0 -0700
+++ hamlib-4.0/debian/changelog 2021-07-15 21:31:14.0 -0700
@@ -1,3 +1,11 @@
+hamlib (4.0-7) unstable; urgency=medium
+
+  * Team upload.
+  * Allow rig_load_all_backends to be called more than once.
+(Closes: #980472)
+
+ -- tony mancill   Thu, 15 Jul 2021 21:31:14 -0700
+
 hamlib (4.0-6) unstable; urgency=medium
 
   * Paper over a minor precision difference in dec2dms on i386.
diff -Nru hamlib-4.0/debian/patches/31dedcf4f79d8fc5fcf287360e5d017842c8e4c0 
hamlib-4.0/debian/patches/31dedcf4f79d8fc5fcf287360e5d017842c8e4c0
--- hamlib-4.0/debian/patches/31dedcf4f79d8fc5fcf287360e5d017842c8e4c0  
1969-12-31 16:00:00.0 -0800
+++ hamlib-4.0/debian/patches/31dedcf4f79d8fc5fcf287360e5d017842c8e4c0  
2021-07-15 21:31:14.0 -0700
@@ -0,0 +1,17 @@
+Comment: Allow rig_load_all_backends to be called more than once
+Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=980472
+Forwarded: not-needed
+Source: 
https://sourceforge.net/p/hamlib/code/ci/31dedcf4f79d8fc5fcf287360e5d017842c8e4c0/
+Author: Michael Black W9MDB
+
+--- a/src/register.c
 b/src/register.c
+@@ -454,6 +454,8 @@
+ {
+ int i;
+ 
++memset(rig_hash_table, 0 , sizeof(rig_hash_table));
++
+ for (i = 0; i < RIG_BACKEND_MAX && rig_backend_list[i].be_name; i++)
+ {
+ rig_load_backend(rig_backend_list[i].be_name);
diff -Nru hamlib-4.0/debian/patches/series hamlib-4.0/debian/patches/series
--- hamlib-4.0/debian/patches/series2021-05-11 10:03:12.0 -0700
+++ hamlib-4.0/debian/patches/series2021-07-15 21:31:14.0 -0700
@@ -7,3 +7,4 @@
 cf858bfa3c8a36eda749c5078ef6f53a119fb285
 0089964af7fa1f43757083b7bc7db195ba382fe0
 1d74711a00dfa416a171cec87c841db315c5d9f7
+31dedcf4f79d8fc5fcf287360e5d017842c8e4c0


signature.asc
Description: PGP signature

Bug#990345: zookeeper: various security issues

[Christoph Anton Mitterer]

On Thu, 2021-07-15 at 21:18 -0700, tony mancill wrote:
> The Debian package disables building against Netty via this patch: 
> https://salsa.debian.org/java-team/zookeeper/-/blob/master/debian/patches/13-disable-netty-connection-factory.patch

Ah I see.


> This is certainly a valid point.  There is not time to change the
> situation for bullseye aside from filing an RM bug to prevent the
> package from shipping with the release.  That would impact transitive
> dependencies of which I believe activemq is the most significant.

Would it be possible to provide a more current version via backports...
I mean if it's not possible to get it in via some st
able-update or so?


> As an aside, I took a quick look at the latest upstream activemq
> source
> release (https://activemq.apache.org/activemq-5016002-release) and it
> specifies zookeeper 3.4.14 in its pom.xml (which makes me feel a
> little
> better).

Isn’t that just telling the minimum version that works with it - not
what they'd consider a safe use from a security PoV?


> We can work on addressing the situation in bookworm.  (One idea I
> would
> propose is paring down the package to build just libzookeeper-java,
> because I imagine that many people use the Debian package to run
> their
> ZooKeeper ensembles, although maybe that's not true.) 

Well I for example use the daemon, too, but the software from which I
use it would anyway already require some newer version and doesn't work
with 3.4 anymore.
So for me that wouldn't matter much.


Thanks,
Chris.

Bug#702190: Friendship Request Email

[Lisa Berg]

Hi

With this letter I would like to seek for your attention. I know 
is an unconventional way of reaching out to someone I've never 
meet or heard of. I also hope you don't find this letter 
provocative or intruding. I write to seek your attention as 
friends.

My name is Lisa Berg. I am from Sweden. I hope you won't view my 
contacting you strange as I'm using a means as cold as this 
platform to reach you. This is the best I can do for now. My 
purpose of writing you is to seek your friendship. I hope it 
seats well with you, and you can write me back so we can 
communicate further and learn about each other.

I look forward to hearing from you

Yours Lisa.

Bug#990345: zookeeper: various security issues

[tony mancill]

On Sun, Jun 27, 2021 at 03:12:35PM +0200, Christoph Anton Mitterer wrote:
> On Sun, 2021-06-27 at 14:46 +0200, Salvatore Bonaccorso wrote:
> > To me this looks like CVEs in other products, but which zookeeper
> > uses
> > as dependency? Is this correct?
> 
> Indeed, but I couldn't find that the zookeeper package depends on these
> while it does contain:
> zookeeper-3.4.13/src$ find . -iname "*nett*"
> ./java/main/org/apache/zookeeper/server/NettyServerCnxnFactory.java
> ./java/main/org/apache/zookeeper/server/NettyServerCnxn.java
> ./java/test/org/apache/zookeeper/server/NettyServerCnxnTest.java
> ./java/test/org/apache/zookeeper/test/NioNettySuiteTest.java
> ./java/test/org/apache/zookeeper/test/NioNettySuiteHammerTest.java
> ./java/test/org/apache/zookeeper/test/NioNettySuiteBase.java
> 
> 
> ... so I figured these might still be affected?

The Debian package disables building against Netty via this patch:

https://salsa.debian.org/java-team/zookeeper/-/blob/master/debian/patches/13-disable-netty-connection-factory.patch

> And apart from that... if they apparently don't support older versions
> anymore, we'd like not even notice should these contain any security
> issues.

This is certainly a valid point.  There is not time to change the
situation for bullseye aside from filing an RM bug to prevent the
package from shipping with the release.  That would impact transitive
dependencies of which I believe activemq is the most significant.

As an aside, I took a quick look at the latest upstream activemq source
release (https://activemq.apache.org/activemq-5016002-release) and it
specifies zookeeper 3.4.14 in its pom.xml (which makes me feel a little
better).

We can work on addressing the situation in bookworm.  (One idea I would
propose is paring down the package to build just libzookeeper-java,
because I imagine that many people use the Debian package to run their
ZooKeeper ensembles, although maybe that's not true.) 

Help is always appreciated.  

Cheers,
tony


signature.asc
Description: PGP signature

Bug#991157: lxqt-policykit authorization fails with more than one sudoer

[Bryan Cebuliak]

see the  other  Ubuntu  report  here:
https://bugs.launchpad.net/ubuntu/+source/lxqt-policykit/+bug/1875774

On Fri, 16 Jul 2021 at 13:09, Bryan Cebuliak 
wrote:

> Package: lxqt-policykit
> Version: 0.16.0-1
> Severity: important
> Tags: a11y upstream
> X-Debbugs-Cc: bryan.cebul...@gmail.com
>
> Dear Maintainer,
> lxqt-policykit authorisation fails with more than one sudoer in the sudo
> group
> I confirm this previously reported bug description:
> https://bugs.launchpad.net/ubuntu/+source/lubuntu-meta/+bug/1828663
> In summary, an application launch from the lxqt menu requiring pkexec such
> as Synaptic or Gparted causes a failure message if more than one sudoer
> exists. Launching programs requiring root authorisation from the terminal
> with sudo works as expected with 2 sudoers on the system.
> The behaviour persists on Debian Bullseye and Ubuntu 20.04LTS with default
> standard newly installed configurations. Note that sudo rather than root
> authorisation is the default with Debian and Ubuntu. Some users such as me
> may require more than one sudoer on a system.
> The lxqt behaviour is not consistent with other GUI authorisation agents
> such as lxpolkit or the Gnome shell agent, which do allow 2 sudoers to be
> present to work properly.
> Altering the /etc/xdg/autostart/lxqt-policykit-agent.desktop to use
> lxpolkit instead of the lxqt-policykit agent thusly results in the expected
> proper behaviour on the lxqt desktop:
> "
> [Desktop Entry]
> Type=Application
> Name=LXPolkit
> TryExec=lxpolkit
> Exec=lxpolkit
> OnlyShowIn=LXQt;
> X-LXQt-Module=true
> ...
> "
> Best regards,
> Your bleeding user
>
>
> -- System Information:
> Debian Release: 11.0
>   APT prefers testing-security
>   APT policy: (500, 'testing-security'), (500, 'testing')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 5.10.0-7-amd64 (SMP w/2 CPU threads)
> Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), LANGUAGE
> not set
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> Versions of packages lxqt-policykit depends on:
> ii  libc6  2.31-12
> ii  liblxqt0   0.16.0-1
> ii  libpolkit-qt5-1-1  0.113.0-1
> ii  libqt5core5a   5.15.2+dfsg-9
> ii  libqt5gui5 5.15.2+dfsg-9
> ii  libqt5widgets5 5.15.2+dfsg-9
> ii  libstdc++6 10.2.1-6
> ii  lxqt-session   0.16.0-1
>
> Versions of packages lxqt-policykit recommends:
> ii  lxqt-policykit-l10n  0.16.0-1
>
> Versions of packages lxqt-policykit suggests:
> ii  lxqt   30
> ii  lxqt-core  30
>
> -- Configuration Files:
> /etc/xdg/autostart/lxqt-policykit-agent.desktop changed:
> [Desktop Entry]
> Type=Application
> Name=LXPolkit
> TryExec=lxpolkit
> Exec=lxpolkit
> OnlyShowIn=LXQt;
> X-LXQt-Module=true
> Name[ar]=معالج وحدة السِّياسة بوليسي كيت
> Name[cs]=Zacházení s politikami
> Name[da]=PolicyKit-håndtering
> Name[de]=PolicyKit-Steuerung
> Comment[de]=Authentifizierungsagent für PolicyKit
> Name[el]=Διαχειριστής PolicyKit
> Name[eo]=Traktilo de PolicyKit
> Name[es]=Manipulador de PolicyKit
> Name[es_VE]=Encargado del Kit de politicas
> Name[eu]=PolicyKit maneiatzailea
> Name[fi]=PolicyKit-käsittelijä
> Name[fr]=Gestionnaire de PolicyKit
> Name[gl]=Manexador do PolicyKit
> Name[hr]=PolicyKit agent
> Name[hu]=PolicyKit-kezelő
> Name[it_IT]=Gestore di PolicyKit
> Name[ja]=PolicyKitハンドラ
> Name[lt]=PolicyKit doroklė
> Name[nl]=PolicyKit Handler
> Name[pl_PL]=PolicyKit Handler
> Name[pt]=Gestor de políticas
> Name[pt_BR]=Manipulador PolicyKit
> Name[ru]= политики комплект Обработчик
> Name[ru_RU]=Обработчик PolicyKit
> Name[sl]=Upravljalnik PolicyKit
> Name[th_TH]=ตัวจัดการ PolicyKit
> Name[tr]=PolicyKit İşleyici
> Name[uk]=Маніпулятор PolicyKit
> Name[zh_CN]=PolicyKit 处理器
> Name[zh_TW]=PolicyKit處理器
>
>
> -- no debconf information
>

Bug#991158: media-types: use image/x-xcf rather than application/x-xcf to match gimp.desktop

[Charles Plessy]

Le Fri, Jul 16, 2021 at 01:20:40PM +1000, Joel Hockey a écrit :
> 
> GIMP uses the xcf file extension by default, and registers to handle
> mime type image/x-xcf in its gimp.desktop file.

Thanks Joel for the report,

Debian is in deep freeze but I can make changes later based on the
recommendation of the GIMP developers.

May I ask you to also suggest them to register their media type to the
IANA ?  I can provide assistance if needed.

https://www.iana.org/form/media-types

Have a nice day,

Charles

-- 
Charles Plessy Nagahama, Yomitan, Okinawa, Japan
Tooting from work,   https://mastodon.technology/@charles_plessy
Tooting from home, https://framapiaf.org/@charles_plessy

Bug#991158: media-types: use image/x-xcf rather than application/x-xcf to match gimp.desktop

[Joel Hockey]

Package: media-types
Version: ?
Severity: normal

Dear Maintainer,

Would it be possible to change the xcf file association in
/etc/mime.types from application/x-xcf to image/x-xcf?

GIMP uses the xcf file extension by default, and registers to handle
mime type image/x-xcf in its gimp.desktop file.

https://github.com/GNOME/gimp/blob/512fc2469422bb651515fb56a250439a1cc5c4ad/configure.ac#L1451

XDG shared-mime-info also uses image/x-xcf to associate *.xcf files.

https://gitlab.freedesktop.org/xdg/shared-mime-info/-/blob/47ca1dc530d356336ffe1b7a45dc5dc8f0e528ca/data/freedesktop.org.xml.in#L5568

I'm not sure the history of why these 2 are not in sync, so I'm not sure
if this would cause any issues to change it in media-types. I have
emailed gimp-developer-l...@gnome.org to ask their opinion about this
requested change. I will follow up when I hear from them.

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

Kernel: Linux 5.4.128-15728-g686e2baf4c9b (SMP w/8 CPU cores; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#991157: lxqt-policykit authorization fails with more than one sudoer

[Bryan Cebuliak]

Package: lxqt-policykit
Version: 0.16.0-1
Severity: important
Tags: a11y upstream
X-Debbugs-Cc: bryan.cebul...@gmail.com

Dear Maintainer,
lxqt-policykit authorisation fails with more than one sudoer in the sudo group
I confirm this previously reported bug description:
https://bugs.launchpad.net/ubuntu/+source/lubuntu-meta/+bug/1828663
In summary, an application launch from the lxqt menu requiring pkexec such as 
Synaptic or Gparted causes a failure message if more than one sudoer exists. 
Launching programs requiring root authorisation from the terminal with sudo 
works as expected with 2 sudoers on the system.
The behaviour persists on Debian Bullseye and Ubuntu 20.04LTS with default 
standard newly installed configurations. Note that sudo rather than root 
authorisation is the default with Debian and Ubuntu. Some users such as me may 
require more than one sudoer on a system.
The lxqt behaviour is not consistent with other GUI authorisation agents such 
as lxpolkit or the Gnome shell agent, which do allow 2 sudoers to be present to 
work properly.
Altering the /etc/xdg/autostart/lxqt-policykit-agent.desktop to use lxpolkit 
instead of the lxqt-policykit agent thusly results in the expected proper 
behaviour on the lxqt desktop:
"
[Desktop Entry]
Type=Application
Name=LXPolkit
TryExec=lxpolkit
Exec=lxpolkit
OnlyShowIn=LXQt;
X-LXQt-Module=true
...
"
Best regards,
Your bleeding user


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

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

Versions of packages lxqt-policykit depends on:
ii  libc6  2.31-12
ii  liblxqt0   0.16.0-1
ii  libpolkit-qt5-1-1  0.113.0-1
ii  libqt5core5a   5.15.2+dfsg-9
ii  libqt5gui5 5.15.2+dfsg-9
ii  libqt5widgets5 5.15.2+dfsg-9
ii  libstdc++6 10.2.1-6
ii  lxqt-session   0.16.0-1

Versions of packages lxqt-policykit recommends:
ii  lxqt-policykit-l10n  0.16.0-1

Versions of packages lxqt-policykit suggests:
ii  lxqt   30
ii  lxqt-core  30

-- Configuration Files:
/etc/xdg/autostart/lxqt-policykit-agent.desktop changed:
[Desktop Entry]
Type=Application
Name=LXPolkit
TryExec=lxpolkit
Exec=lxpolkit
OnlyShowIn=LXQt;
X-LXQt-Module=true
Name[ar]=معالج وحدة السِّياسة بوليسي كيت
Name[cs]=Zacházení s politikami
Name[da]=PolicyKit-håndtering
Name[de]=PolicyKit-Steuerung
Comment[de]=Authentifizierungsagent für PolicyKit
Name[el]=Διαχειριστής PolicyKit
Name[eo]=Traktilo de PolicyKit
Name[es]=Manipulador de PolicyKit
Name[es_VE]=Encargado del Kit de politicas
Name[eu]=PolicyKit maneiatzailea
Name[fi]=PolicyKit-käsittelijä
Name[fr]=Gestionnaire de PolicyKit
Name[gl]=Manexador do PolicyKit
Name[hr]=PolicyKit agent
Name[hu]=PolicyKit-kezelő
Name[it_IT]=Gestore di PolicyKit
Name[ja]=PolicyKitハンドラ
Name[lt]=PolicyKit doroklė
Name[nl]=PolicyKit Handler
Name[pl_PL]=PolicyKit Handler
Name[pt]=Gestor de políticas
Name[pt_BR]=Manipulador PolicyKit
Name[ru]= политики комплект Обработчик
Name[ru_RU]=Обработчик PolicyKit
Name[sl]=Upravljalnik PolicyKit
Name[th_TH]=ตัวจัดการ PolicyKit
Name[tr]=PolicyKit İşleyici
Name[uk]=Маніпулятор PolicyKit
Name[zh_CN]=PolicyKit 处理器
Name[zh_TW]=PolicyKit處理器


-- no debconf information

Bug#991156: unblock: config-package-dev/5.6 [pre-approval]

[Geoffrey Thomas]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: config-package-...@mit.edu

Hi release team,

This is a pre-approval request to get a sense of your willingness to 
unblock config-package-dev to handle usrmerge/dpkg issues.


[ Reason ]

config-package-dev is a Debhelper (and CDBS) add-on for writing packages 
that use dpkg-divert to customize other packages' behavior. (The target 
audience is people customizing Debian for a university/company/etc. or 
preparing derivatives. Notable public users include Debathena and Whonix. 
That is, config-package-dev is a leaf package in the Debian archive, with 
no build-rdeps.)


As noted on https://wiki.debian.org/Teams/Dpkg/MergedUsr , "dpkg-divert is 
currently broken by" the current implementation of usrmerge. What this 
seems to mean, specifically, is that if you divert a binary by the wrong 
name - e.g., dpkg-divert /bin/less instead of /usr/bin/less - the 
diversion is useless, and the underlying package can overwrite a file that 
was supposed to be diverted.


I think config-package-dev ought to address this, somehow. Some options 
are listed in my email to our mailing list, where I also demonstrate what 
can go wrong: 
http://mailman.mit.edu/pipermail/config-package-dev/2021-July/66.html


Options range from just documenting the issue to actually trying to 
address it in some fashion. I don't yet have a change ready for any of 
these options; I'm trying to gauge what you think is acceptable vs. too 
risky at this point in freeze.


[ Impact ]

A user on a usrmerged system could easily notice a file in (e.g.) /usr/bin 
and try to build a config-package of it without realizing the file 
actually lives in (e.g.) /bin. Things would even appear to work after 
installing the config-package, because the file would get renamed on disk; 
they would break after the underlying package (the target of the 
diversion) gets upgraded or reinstalled.


[ Tests ]

The examples directory contains a handful of sample source packages using 
most of config-package-dev's features. autopkgtests cover building but not 
installing those packages, so testing would be manual. Also, the tests 
only cover the positive case, using the correct paths, as opposed to the 
negative case, but manual testing of that would be easy (see the linked 
email above for essentially a currently-failing test case).


[ Risks ]

As noted, this is a leaf package within the Debian archive, so the risk to 
Debian itself from getting the change wrong would be low.


The major alternative here would be fixing dpkg to handle diversions (and 
perhaps many other things) correctly on a usrmerged system. From the tone 
of the discussion, I would guess that this certainly isn't going to happen 
before Bullseye release, but if you're aware of work along those lines, I 
would be happy to wait for that / contribute to it / test it.


[ Checklist ]
  [ ] all changes are documented in the d/changelog
  [ ] I reviewed all changes and I approve them
  [ ] attach debdiff against the package in testing

[ Other info ]

I'm open to whatever level of change you think is fine. I would prefer 
fixing it (somehow) to merely documenting it; if you think I should try to 
fix it and come back with a debdiff, I'm happy to do that.


unblock config-package-dev/5.6

Thanks,
--
Geoffrey Thomas
https://ldpreload.com
geo...@ldpreload.com

Bug#991151: corekeeper: postrm: invoke-rc.d: initscript procps, action "reload" failed.

[Paul Wise]

On Fri, 2021-07-16 at 12:41 +1000, Craig Small wrote:

> I can add an alias easily enough. Using reload is very wrong so
> corekeeper do the right thing but it's a one line change for procps.

Can you elaborate on what you mean by "Using reload is very wrong"?

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#974175: Exempt dh_elpa-related packages from executable-in-usr-lib

[Felix Lechner]

Hi

On Tue, Nov 10, 2020 at 5:51 PM Felix Lechner
 wrote:
>
> 04:21 < bremner> hmm. so I think executable-in-usr-lib is a false
> positive for everything in usr/lib/emacsen-common/packages

The masks applied to this family of tags are now available on the
Lintian website. Please check under "Screens" or click here:

https://lintian.debian.org/screens/emacs/elpa/scripts

Kind regards
Felix Lechner

Bug#991151: corekeeper: postrm: invoke-rc.d: initscript procps, action "reload" failed.

[Craig Small]

I can add an alias easily enough. Using reload is very wrong so corekeeper
do the right thing but it's a one line change for procps.

 - Craig


On Fri, 16 Jul 2021, 12:31 Paul Wise,  wrote:

> On Fri, 2021-07-16 at 02:25 +, Thorsten Glaser wrote:
>
> > … this isn’t right. This is an RC bug in corekeeper but nōn-RC
> > in procps because of Policy §9.3.2:
>
> I still think it is RC as it is a feature regression breaking install
> of reverse dependencies in supported configurations (sysvinit).
>
> > So I think it’d be better to clone the bugreport, asking procps nicely
> > to implement “reload” while fixing corekeeper for bullseye first.
>
> If the procps maintainer doesn't plan to fix this in bullseye and
> buster, then I guess I will have to workaround it in corekeeper.
>
> --
> bye,
> pabs
>
> https://wiki.debian.org/PaulWise
>

Bug#986400: lintian: false positive about permissions for read-only GNAT .ali files

[Felix Lechner]

Hi,

On Wed, Apr 7, 2021 at 9:40 AM Russ Allbery  wrote:
>
> it was unlikely that GNAT was going to change such long-standing behavior

The masks applied to this family of tags are now available on the
Lintian website. Please check under "Screens" or click here:

https://lintian.debian.org/screens/toolchain/gnat/ali-read-only

Kind regards
Felix Lechner

Bug#991151: corekeeper: postrm: invoke-rc.d: initscript procps, action "reload" failed.

[Paul Wise]

On Fri, 2021-07-16 at 02:25 +, Thorsten Glaser wrote:

> … this isn’t right. This is an RC bug in corekeeper but nōn-RC
> in procps because of Policy §9.3.2:

I still think it is RC as it is a feature regression breaking install
of reverse dependencies in supported configurations (sysvinit).

> So I think it’d be better to clone the bugreport, asking procps nicely
> to implement “reload” while fixing corekeeper for bullseye first.

If the procps maintainer doesn't plan to fix this in bullseye and
buster, then I guess I will have to workaround it in corekeeper.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#991151: corekeeper: postrm: invoke-rc.d: initscript procps, action "reload" failed.

[Thorsten Glaser]

Paul Wise dixit:

>> Yes, the procps init script does not have the action reload.
>
>Looks like this is a regression in procps in buster and later.

Hrm. OK, but…

>I've bounced the thread to the procps maintainer and reassigned.

… this isn’t right. This is an RC bug in corekeeper but nōn-RC
in procps because of Policy §9.3.2:

| The "start", "stop", "restart", and "force-reload" options should be
| supported by all init scripts. Supporting "status" is encouraged. The
| "reload" and "try-restart" options are optional.

So I think it’d be better to clone the bugreport, asking procps nicely
to implement “reload” while fixing corekeeper for bullseye first.

bye,
//mirabilos
PS: I was unclear in the previous mail… I found the bug while
crossgrading but was actually installing corekeeper on my
systems recently; apt insisted on remove+install which is
what triggered this.
-- 
 you introduced a merge commit│ % g rebase -i HEAD^^
 sorry, no idea and rebasing just fscked │ Segmentation
 should have cloned into a clean repo  │  fault (core dumped)
 if I rebase that now, it's really ugh │ wuahh

Bug#991151: corekeeper: postrm: invoke-rc.d: initscript procps, action "reload" failed.

[Paul Wise]

Control: reassign -1 procps 3.3.15-2
Control: retitle -1 procps: dropped the reload option from the init script, 
breaking corekeeper
Control: affects -1 corekeeper

On Fri, 2021-07-16 at 01:15 +, Thorsten Glaser wrote:

> Yes, the procps init script does not have the action reload.

Looks like this is a regression in procps in buster and later.
I've bounced the thread to the procps maintainer and reassigned.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#991151: corekeeper: postrm: invoke-rc.d: initscript procps, action "reload" failed.

[Thorsten Glaser]

Paul Wise dixit:

>On Thu, 2021-07-15 at 21:34 +0200, Thorsten Glaser wrote:
>
>> invoke-rc.d: initscript procps, action "reload" failed.
>
>I don't have this problem on amd64 with systemd,
>can you reproduce it on amd64 with sysvinit?

Yes, the procps init script does not have the action reload.

| Usage: /etc/init.d/procps {start|stop|status|restart|try-restart|force-reload}

>I'm thinking of switching to systemd-coredump,
>are you interested in adopting corekeeper?

I’m trying to not increase the amount of time I sink into
Debian at this moment, sorry; corekeeper i̲s̲ useful though;
it just works as-is.

bye,
//mirabilos
-- 
Gestern Nacht ist mein IRC-Netzwerk explodiert. Ich hatte nicht damit
gerechnet, darum bin ich blutverschmiert… wer konnte ahnen, daß SIE so
reagier’n… gestern Nacht ist mein IRC-Netzwerk explodiert~~~
(as of 2021-06-15 The MirOS Project temporarily reconvenes on OFTC)

Bug#991151: corekeeper: postrm: invoke-rc.d: initscript procps, action "reload" failed.

[Paul Wise]

On Thu, 2021-07-15 at 21:34 +0200, Thorsten Glaser wrote:

> invoke-rc.d: initscript procps, action "reload" failed.

I don't have this problem on amd64 with systemd,
can you reproduce it on amd64 with sysvinit?

I'm thinking of switching to systemd-coredump,
are you interested in adopting corekeeper?

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#991152: linux-image-5.10.0-7-amd64: After waking up kernel returns warning message to journal saying 'done.'

[Tia]

Package: src:linux
Version: 5.10.40-1
Severity: minor
X-Debbugs-Cc: tia3...@protonmail.com

Dear Maintainer,

>From time to time when waking up device from sleep kernel would give warning 
>to journal saying 'done'.

Looking in snipet from journalctl -k

srp 15 15:45:47 HP2000 kernel: [drm] ib test on ring 5 succeeded
srp 15 15:45:47 HP2000 kernel: acpi LNXPOWER:01: Turning OFF
srp 15 15:45:47 HP2000 kernel: OOM killer enabled.
srp 15 15:45:47 HP2000 kernel: Restarting tasks ... 
srp 15 15:45:47 HP2000 kernel: usb 1-1.1: USB disconnect, device number 11
srp 15 15:45:47 HP2000 kernel: done.
srp 15 15:45:47 HP2000 kernel: PM: suspend exit
srp 15 15:45:47 HP2000 kernel: usb 1-1.1: new full-speed USB device number 12 
using ehci-pci
srp 15 15:45:47 HP2000 kernel: usb 1-1.1: New USB device found, idVendor=0cf3, 
idProduct=3121, bcdDevice= 0.01
srp 15 15:45:47 HP2000 kernel: usb 1-1.1: New USB device strings: Mfr=0, 
Product=0, SerialNumber=0
srp 15 15:45:47 HP2000 kernel: usb 1-1.1: firmware: direct-loading firmware 
ar3k/AthrBT_0x3101.dfu
srp 15 15:45:47 HP2000 kernel: usb 1-1.1: firmware: direct-loading firmware 
ar3k/ramps_0x3101_40.dfu
srp 15 15:45:47 HP2000 kernel: usb 1-1.1: USB disconnect, device number 12
srp 15 15:45:47 HP2000 kernel: usb 1-1.1: new full-speed USB device number 13 
using ehci-pci
srp 15 15:45:49 HP2000 kernel: ata3: SATA link up 3.0 Gbps (SStatus 123 
SControl 300)
srp 15 15:45:49 HP2000 kernel: ata3.00: configured for UDMA/133

Where that done message is visible in journalctl under warning priority

srp 15 15:45:47 kernel: done.

Before on kernel 4.19 it would before that say how cpu core 0,1 and 2 shouldn't 
be sleeping. But that is no longer the case.

It seems to be only cosmetic issue, as I can't see what it is refering to when 
stating 'done.'
If it is cosmetic, could message priority be lowered?

Best regards,
Tia

-- Package-specific info:
** Version:
Linux version 5.10.0-7-amd64 (debian-ker...@lists.debian.org) (gcc-10 (Debian 
10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2) #1 SMP 
Debian 5.10.40-1 (2021-05-28)

** Command line:
BOOT_IMAGE=/vmlinuz-5.10.0-7-amd64 root=/dev/mapper/HP2000--vg-root ro quiet 
splash

** Not tainted

** Kernel log:
[15056.693436] ath: regdomain 0x80bf dynamically updated by country element
[15057.157713] IPv6: ADDRCONF(NETDEV_CHANGE): wlo1: link becomes ready
[15058.977720] usb 1-1.1: New USB device found, idVendor=0cf3, idProduct=3121, 
bcdDevice= 0.02
[15058.977727] usb 1-1.1: New USB device strings: Mfr=0, Product=0, 
SerialNumber=0
[23775.993160] Lockdown: systemd-logind: hibernation is restricted; see man 
kernel_lockdown.7
[23775.999676] Lockdown: systemd-logind: hibernation is restricted; see man 
kernel_lockdown.7
[23776.048959] wlo1: deauthenticating from 30:b5:c2:aa:a2:88 by local choice 
(Reason: 3=DEAUTH_LEAVING)
[23776.442661] Lockdown: systemd-logind: hibernation is restricted; see man 
kernel_lockdown.7
[23776.448519] Lockdown: systemd-logind: hibernation is restricted; see man 
kernel_lockdown.7
[23776.449122] Lockdown: systemd-logind: hibernation is restricted; see man 
kernel_lockdown.7
[23776.551727] PM: suspend entry (deep)
[23776.568683] Filesystems sync: 0.016 seconds
[23776.568979] (NULL device *): firmware: direct-loading firmware 
regulatory.db.p7s
[23776.568980] (NULL device *): firmware: direct-loading firmware regulatory.db
[23776.638937] Freezing user space processes ... (elapsed 0.001 seconds) done.
[23776.640610] OOM killer disabled.
[23776.640611] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) 
done.
[23776.641912] printk: Suspending console(s) (use no_console_suspend to debug)
[23776.659099] sd 2:0:0:0: [sdb] Synchronizing SCSI cache
[23776.659147] sd 0:0:0:0: [sda] Synchronizing SCSI cache
[23776.659206] sd 0:0:0:0: [sda] Stopping disk
[23776.660219] sd 2:0:0:0: [sdb] Stopping disk
[23777.727412] ACPI: EC: interrupt blocked
[23777.747468] ACPI: Preparing to enter system sleep state S3
[23777.748459] ACPI: EC: event blocked
[23777.748460] ACPI: EC: EC stopped
[23777.748461] PM: Saving platform NVS memory
[23777.748473] Disabling non-boot CPUs ...
[23777.749774] smpboot: CPU 1 is now offline
[23777.751969] smpboot: CPU 2 is now offline
[23777.754204] smpboot: CPU 3 is now offline
[23777.755563] ACPI: Low-level resume complete
[23777.755618] ACPI: EC: EC started
[23777.755619] PM: Restoring platform NVS memory
[23777.756965] Enabling non-boot CPUs ...
[23777.757016] x86: Booting SMP configuration:
[23777.757017] smpboot: Booting Node 0 Processor 1 APIC 0x1
[23777.763384] CPU1 is up
[23777.763417] smpboot: Booting Node 0 Processor 2 APIC 0x2
[23777.766647] CPU2 is up
[23777.766676] smpboot: Booting Node 0 Processor 3 APIC 0x3
[23777.769271] CPU3 is up
[23777.770470] ACPI: Waking up from system sleep state S3
[23777.784081] ACPI: EC: interrupt unblocked
[23777.824336] ACPI: EC: event unblocked
[23777.824679] ath: phy0: ASPM enabled: 0x43
[23777.833370] [drm] enabling PCIE 

Bug#991135: WiFi start is delayed by 5 minutes and networking-routes.service/start deleted to break ordering cycle

[Peter Mueller]

found 991135 ifupdown-extra/0.32
thanks
Dear Michael,
Thanks for the reassignment! Let's see what the ifupdown-extra-maintainer can 
say. By the way:
$ sudo aptitude show ifupdown| grep Version Version: 0.8.36
Best regards,
Peter
15.07.2021, 13:06, Michael Biebl < mailto:bi...@debian.org bi...@debian.org >
Control: reassign -1 ifupdown-extra Am 15.07.21 um 12:46 schrieb Peter Mueller: 
> Package: systemd > Version: 247.3-5 > > Reproduce: > 1) Boot the computer. > 
2) Have no WiFi approximately 5 minutes long. > 3) Have WiFi after 5 minutes. > 
> It doesn't matter whether WiFi is tested from gnome or from tty.  My > 
network is configured via interfaces (not via NetworkManager). > I have a 
PCE-AX3000 card and use an up-to-date Debian 11 “Bullseye” with > 
firmware-iwlwifi. The bug has existed since the fresh installation in > January 
2021 with all the current kernels so far. > > $ cat /etc/network/interfaces > # 
This file describes the network interfaces available on your system > # and how 
to activate them. For more information, see interfaces(5). > source 
/etc/network/interfaces.d/* > # The loopback network interface > auto lo > 
iface lo inet loopback > ## The primary network interface > allow-hotplug 
wlp179s0 > iface wlp179s0 inet dhcp > ## This is an autoconfigured IPv6 
interface > iface wlp179s0 inet6 auto > wpa-ssid o2-WLAN00 > wpa-psk 
AnonymizedPassword > ## detect wired interfaces when they become available > 
allow-hotplug enp6s0 enp7s0 > # raise the wireless interface as primary > auto 
wlp179s0 > $ sudo journalctl -b | grep -B 4 "ordering cycle" > Jul 15 11:39:39 
DtPC systemd[1]: systemd 247.3-5 running in system mode. > (+PAM +AUDIT 
+SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP > +LIBCRYPTSETUP +GCRYPT +GNUTLS 
+ACL +XZ +LZ4 +ZSTD +SECCOMP +BLKID > +ELFUTILS +KMOD +IDN2 -IDN +PCRE2 
default-hierarchy=unified) > Jul 15 11:39:39 DtPC systemd[1]: Detected 
architecture x86-64. > Jul 15 11:39:39 DtPC systemd[1]: Set hostname to 
. > Jul 15 11:39:39 DtPC kernel: usb 1-11.4.3: new 
high-speed USB device > number 9 using xhci_hcd > Jul 15 11:39:39 DtPC 
systemd[1]: network.target: Found ordering cycle on > 
networking-routes.service/start > Jul 15 11:39:39 DtPC systemd[1]: 
network.target: Found dependency on > network.target/start > Jul 15 11:39:39 
DtPC systemd[1]: network.target: Job > networking-routes.service/start deleted 
to break ordering cycle starting > with network.target/start > $ cat 
/etc/network/interfaces.d/* > auto lo > iface lo inet loopback > # auto eth0 > 
# iface eth0 inet dhcp > > How to debug this further? (I don't wish to clutter 
this bug report with > tons of potentially unrelated logs; please advise.) I 
don't see a bug in systemd here. What I see are two (maybe related) issues a/ 
networking-routes.service (from ifupdown-extra) causing a dependency loop (=> 
looks like a bug in ifupdown-extra to me) b/ an issue with your network 
configuration (which is managed by ifupdown). If b/ is caused by a/, I dunno. 
Let's reassign this to ifupdown-extra. Its maintainer will be in a better 
position to advise you with any ifupdown related issues. Regards, Michael

Bug#914128: perl: usrmerge issues

[Vagrant Cascadian]

On 2021-07-15, Vagrant Cascadian wrote:
> On 2018-11-19, Niko Tyni wrote:
>> Diffoscoping a perl built on a usrmerged [1] system with
>> one built on a non-usrmerged system reveals the configure
>> process hardcoding some paths in the build results,
>>
>> [1] https://wiki.debian.org/UsrMerge
>>
>> Snippets from config.h, Config.pm, Config_heavy.pl, config.sh.debug.gz
>> and so forth include things below.
...
>> -libpth => '/usr/local/lib /usr/lib/gcc/x86_64-linux-gnu/8/include-fixed 
>> /usr/include/x86_64-linux-gnu /usr/lib /lib/x86_64-linux-gnu /lib/../lib 
>> /usr/lib/x86_64-linux-gnu /usr/lib/../lib /lib',
>> +libpth => '/usr/local/lib /usr/lib/gcc/x86_64-linux-gnu/8/include-fixed 
>> /usr/include/x86_64-linux-gnu /usr/lib /lib/x86_64-linux-gnu /lib/../lib 
>> /usr/lib/x86_64-linux-gnu /usr/lib/../lib /lib /lib64 /usr/lib64',
...
>> -libspath=' /usr/local/lib /usr/lib/gcc/x86_64-linux-gnu/8/include-fixed 
>> /usr/include/x86_64-linux-gnu /usr/lib /lib/x86_64-linux-gnu /lib/../lib 
>> /usr/lib/x86_64-linux-gnu /usr/lib/../lib /lib'
>> +libspath=' /usr/local/lib /usr/lib/gcc/x86_64-linux-gnu/8/include-fixed 
>> /usr/include/x86_64-linux-gnu /usr/lib /lib/x86_64-linux-gnu /lib/../lib 
>> /usr/lib/x86_64-linux-gnu /usr/lib/../lib /lib /lib64 /usr/lib64'

Attached patch also fixes these issues, by adjusting libpth and libspath
in debian/config.over ... it feels a little hackish ... but ...

With all three patches applied, perl builds reproducibly!


live well,
  vagrant
From c7d24b8965eecbdfcebbf21900c744ee7b5842a4 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Thu, 15 Jul 2021 23:28:41 +
Subject: [PATCH 3/3] debian/config.over: Adjust libpth and libspath to build
 consistently when built on usrmerge or non-usrmerge system.

---
 debian/config.over | 21 +
 1 file changed, 21 insertions(+)

diff --git a/debian/config.over b/debian/config.over
index f793f48c8..29de4814c 100644
--- a/debian/config.over
+++ b/debian/config.over
@@ -45,6 +45,27 @@ if ! echo $libpth | grep -q "$multiarch_dir"
 then
 libpth="$libpth $multiarch_dir"
 fi
+if ! echo $libspath | grep -q "$multiarch_dir"
+then
+libspath="$libspath $multiarch_dir"
+fi
+multiarch_lib_dir=/lib/`dpkg-architecture -qDEB_HOST_MULTIARCH`
+if ! echo $libpth | grep -q " $multiarch_lib_dir"
+then
+libpth="$libpth $multiarch_lib_dir"
+fi
+if ! echo $libspath | grep -q " $multiarch_lib_dir"
+then
+libspath="$libspath $multiarch_lib_dir"
+fi
+if ! echo $libpth | grep -q ' /lib$'
+then
+libpth="$libpth /lib"
+fi
+if ! echo $libspath | grep -q ' /lib$'
+then
+libspath="$libspath /lib"
+fi
 
 # set configuration time to latest debian/changelog entry
 cf_time=$(LC_ALL=C date --utc -d "$(cd .. && dpkg-parsechangelog | sed -n -e 's/^Date: //p')")
-- 
2.32.0



signature.asc
Description: PGP signature

Bug#991155: neovim: new upstream version

[brian m. carlson]

Package: neovim
Version: 0.4.4-1
Severity: wishlist

neovim 0.5 has come out with some nice new features.  It would be great
if it could be packaged, if not in unstable due to the freeze, at least
in experimental.


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

Kernel: Linux 5.10.0-8-amd64 (SMP w/8 CPU threads)
Locale: LANG=fr_FR.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 neovim depends on:
ii  libc62.31-13
ii  libluajit-5.1-2  2.1.0~beta3+dfsg-6
ii  libmsgpackc2 3.3.0-4
ii  libtermkey1  0.22-1
ii  libunibilium42.1.0-1
ii  libuv1   1.40.0-2
ii  libvterm00.1.4-1
ii  lua-luv  1.36.0-0-1
ii  neovim-runtime   0.4.4-1

Versions of packages neovim recommends:
ii  python3-neovim   0.4.2-1
ii  python3-pynvim [python3-neovim]  0.4.2-1
ii  xclip0.13-2
ii  xxd  2:8.2.2434-3

Versions of packages neovim suggests:
pn  ctags
pn  vim-scripts  

-- no debconf information

-- 
brian m. carlson (he/him or they/them)
Toronto, Ontario, CA


signature.asc
Description: PGP signature

Bug#985105: kexec-tools: CVE-2021-20269

[Khalid Aziz]

On 3/12/21 1:40 PM, Salvatore Bonaccorso wrote:
> Source: kexec-tools
> Version: 1:2.0.20-2.1
> Severity: important
> Tags: security upstream
> X-Debbugs-Cc: car...@debian.org, Debian Security Team 
> 
> 
> Hi,
> 
> The following vulnerability was published for kexec-tools.
> 
> CVE-2021-20269[0]:
> | incorrect permissions on kdump dmesg file
> 
> Could you check the details here? [2] is slight short on information
> if "known upstream" etc.
> 
> 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-20269
> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-20269
> [1] https://www.openwall.com/lists/oss-security/2021/03/11/2
> 
> Please adjust the affected versions in the BTS as needed.
> 

On Debian systems, dmesg file is created by makedumpfile in makedumpfile
package which is called by /usr/sbin/kdump-config from kdump-tols
package. makedumpfile sets the permission on dmesg file and from looking
at the git history for makedumpfile.c, it has used permission
"S_IRUSR|S_IWUSR" since 2006 at least. Redhat/Fedora on the other hand
use a script kdump-lib-initramfs.sh to create the dmesg file with
"journalctl -ab >> $KDUMP_LOG_FILE" and this vulnerability was fixed in
that script by adding "chmod 600 $KDUMP_LOG_FILE"

dmesg file on Debian has the format dmesg., for example:

$ ls -l /var/crash/202107151351/
total 119404
-rw--- 1 root root 67840 Jul 15 13:53 dmesg.202107151351
-rw-r--r-- 1 root root 122195470 Jul 15 13:52 dump.202107151351

As seen in example above, this file is created with read-write
permission for root only.

Above crash files were generated on a Debian system using following
versions of tools:

ii  kdump-tools  1:1.6.8.3amd64
ii  makedumpfile 1:1.6.8-4amd64
ii  kexec-tools  1:2.0.22-1   amd64

Does this address the CVE?

Thanks,
Khalid

Bug#991067: x4d-icons FTBFS with imagemagick with the #987504 change

[Dennis Filder]

Control: tag -1 patch

The attached patch should fix this by loading a more permissive policy.

Regards,
Dennis Filder.
Description: Override overly strict ImageMagick coder policy (#987504)
 This creates a more permissive version of
 /etc/ImageMagick-6/policy.xml and ensures it gets loaded after the
 one from /etc.
 .
 It is done by means of a patch to make use of the debhelper-provided
 $HOME visible by dh_auto_*.
 .
 The relevant code is at:
 https://sources.debian.org/src/imagemagick/8:6.9.11.60+dfsg-1.3/magick/configure.c/#L860
Author: Dennis Filder 
Last-Updated: 2021-07-15
--- a/generate.sh
+++ b/generate.sh
@@ -33,6 +33,29 @@
 generate XML '1.0' xml10
 generate XML '1.1' xml11
 
+# this relies on debhelper providing a $HOME directory for us to write
+# to
+polfile="/etc/$(convert -version|sed -n '/^Version: /s@Version: ImageMagick \([[:digit:]]\+\)\..*@ImageMagick-\1@p')"/policy.xml
+if [ ! -f "$polfile" ]; then
+echo "Error: generate.sh: Policy file not found: $polfile" >&2;
+exit 1
+fi
+if [ -e "$HOME"/.magick ]; then
+rm -Rf "$HOME"/.magick
+fi;
+if [ -e "$HOME"/.magick ]; then
+echo "Error: generate.sh: Failed to remove $HOME/.magick -- remove manually and try again." >&2;
+exit 1
+fi
+mkdir "$HOME"/.magick
+if [ ! -d "$HOME"/.magick ]; then
+echo "Error: generate.sh: Failed to create $HOME/.magick -- investigate, fix manually, then try again." >&2;
+exit 1;
+fi
+
+sed -e '//s@"none"@"read|write"@' "$polfile" \
+> "$HOME"/.magick/policy.xml
+
 /bin/ls Icons/*.svg | sed 's/-v\.svg//' | xargs -I{} convert -background none {}-v.svg {}.png
 /bin/ls Icons/*.svg | sed 's/-v\.svg//' | xargs -I{} convert -background none {}-v.svg {}.gif
 /bin/ls Icons/*.svg | sed 's/-v\.svg//' | xargs -I{} convert -background none {}-v.svg {}-v.eps

Bug#990754: unblock: wpewebkit/2.32.1-1

[Alberto Garcia]

On Thu, Jul 15, 2021 at 09:32:42PM +0200, Sebastian Ramacher wrote:
> > We synced up with this before; wpewebkit is closely related to
> > webkit and Alberto will keep both updated in stable.
> 
> Is this also the plan for cog, wpebackend-fdo and libwpe?

I don't think those _require_ stable updates. If there is a situation
in which a new wpewebkit requires a newer wpebackend-fdo or libwpe
then we would need to handle that in a case-by-case basis (as far as
I'm aware that only happened once in the history of the WPE WebKit
project).

Then again all those packages are part of the same project and
developed by the same team upstream, so keeping them up-to-date is
probably not a bad idea, but that we can handle in point releases if
we think it's a good idea.

For bullseye and since we just unblocked wpewebkit it would be nice
to start with the most recent versions of the other three packages,
but I realize we're very close to the release date so I'm not going to
insist very strongly :-)

Berto

Bug#984809: php8.0: please make the build (mostly) reproducible

[Vagrant Cascadian]

Control: clone 984809 -1
Control: reassign -1 php7.4
Control: retitle -1 php7.4: please make the build (mostly) reproducible

On 2021-07-12, Vagrant Cascadian wrote:
> On 2021-03-08, Chris Lamb wrote:
>> Whilst working on the Reproducible Builds effort [0] we noticed that
>> php8.0 could not be built reproducibly.
>>
>> Patch attached to make the build-defs.h, /usr/bin/php-config8.0 and
>> test-results.txt.gz reproducible.
...
> FWIW, it looks like PHP 7.4 has the same issues, although I haven't
> checked if the patch applies without modification.

Patch applies and is effective; cloning into new bug...


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#984809: php8.0: please make the build (mostly) reproducible

[Vagrant Cascadian]

On 2021-07-12, Vagrant Cascadian wrote:
> On 2021-03-08, Chris Lamb wrote:
>> Whilst working on the Reproducible Builds effort [0] we noticed that
>> php8.0 could not be built reproducibly.
>>
>> Patch attached to make the build-defs.h, /usr/bin/php-config8.0 and
>> test-results.txt.gz reproducible.
>
> The test-results.txt.gz also embeds the hostname, kernel version, build
> time, etc. ...
>
>   
> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/php8.0.html
>
> Some of these things may be sanitized usefully (although perhaps a bit
> of a whack-a-mole game over time), but if any sort of timing information
> is desired, sanitizing that data would defeat the purpose of the log.
>
> We had a similar discussion for binutils which does something similar:
>
>   https://bugs.debian.org/950585
>
>
> If the test suite output is not too huge, I think it might be better to
> not ship test-results.txt in the package, but to output the contents to
> the build log (so you could access the necessary test-results from
> buildd.debian.org).

Apparently php8.0 already outputs the test-results.txt to the build log.
An updated patch that simply doesn't install test-restults.txt is
attached.


live well,
  vagrant
diff --git a/debian/rules b/debian/rules
index 8aa4d27..8696a51 100755
--- a/debian/rules
+++ b/debian/rules
@@ -519,9 +519,14 @@ override_dh_install-arch: remove-files-stamp prepare-fpm-pools
 
 ifeq (yes,$(RUN_TESTS))
 	mkdir -p debian/$(PHP_COMMON)/usr/share/doc/$(PHP_COMMON)/
-	cp test-results.txt debian/$(PHP_COMMON)/usr/share/doc/$(PHP_COMMON)/
 endif
 
+	$(SED) -i -e's@-ffile-prefix-map=[^ ]*[ ]*@@g' \
+		-e's@-fdebug-prefix-map=[^ ]*[ ]*@@g' \
+		-e's@$(CURDIR)@/tmp/buildd/nonexistent@g' \
+		debian/$(PHP_DEV)/usr/include/php/*/main/build-defs.h \
+		debian/$(PHP_DEV)/usr/bin/php-config$(PHP_NAME_VERSION)
+
 override_dh_installinit:
 	dh_installinit --restart-after-upgrade
 


signature.asc
Description: PGP signature

Bug#991153: icewm: switching windows in taskbar order is broken

[Jiri Bohac]

Package: icewm
Version: 2.1.2-1
Severity: normal
Tags: patch

Dear Maintainer,

A patch in upstream icewm 2.1.0 broke the behaviour of switching windows in the
order they appear on the taskbar.  This can be done by scrolling the mouse
wheel over the taskbar or with configuring special shortcuts.
At first this works but as soon as buttons are moved (e.g. by dragging) the
order becomes chaotic.

The Debian testing/unstable version of icewm 2.1.2 includes this problem.
That's a regression since current stable.
I reported the problem upstream: https://github.com/bbidulock/icewm/issues/602
It has now been fixed upstream by commit c16c44e936856bcebf11c8fd36028119c021e0
The patch applies nicely to 2.1.2

Could you please include this patch in the Debian package?

Thank you!


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

Kernel: Linux 4.19.0-16-amd64 (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
commit c16c44e936856bcebf11c8fd36028119c021e0cc
Author: Bert Gijsbers 
Date:   Thu Jul 15 21:36:20 2021 +0200

Rewrite task successor and task predecessor to properly take into account 
the
separation of TaskBarApp and TaskButton as well as task grouping.
Resolves #602, resolves #604.

[rediffed against 2.1.2 by Jiri Bohac]

diff --git a/src/atasks.cc b/src/atasks.cc
index fe5405e9..b47fe05a 100644
--- a/src/atasks.cc
+++ b/src/atasks.cc
@@ -125,6 +125,38 @@ void TaskButton::remove(TaskBarApp* tapp) {
 }
 }
 
+TaskBarApp* TaskButton::getNextShown(TaskBarApp* tapp) const {
+if (grouping()) {
+int k = tapp ? find(fGroup, tapp) : -1;
+if (k >= 0 || tapp == nullptr) {
+while (++k < fGroup.getCount()) {
+if (fGroup[k]->getShown()) {
+return fGroup[k];
+}
+}
+}
+} else if (tapp == nullptr) {
+return fActive;
+}
+return nullptr;
+}
+
+TaskBarApp* TaskButton::getPrevShown(TaskBarApp* tapp) const {
+if (grouping()) {
+int k = tapp ? find(fGroup, tapp) : fGroup.getCount();
+if (k > 0) {
+while (--k >= 0) {
+if (fGroup[k]->getShown()) {
+return fGroup[k];
+}
+}
+}
+} else if (tapp == nullptr) {
+return fActive;
+}
+return nullptr;
+}
+
 void TaskButton::setShown(TaskBarApp* tapp, bool ashow) {
 if (tapp == fActive) {
 if (ashow != visible())
@@ -562,28 +594,46 @@ void TaskPane::insert(TaskBarApp* tapp) {
 }
 
 TaskBarApp* TaskPane::predecessor(TaskBarApp* tapp) {
-const int count = fApps.getCount();
-const int found = find(fApps, tapp);
-if (found >= 0) {
-for (int i = count - 1; 1 <= i; --i) {
-int k = (found + i) % count;
-if (fApps[k]->getShown()) {
-return fApps[k];
-}
+TaskButton* button = tapp->button();
+TaskBarApp* prev = button->getPrevShown(tapp);
+if (prev && button->getShown()) {
+return prev;
+} else {
+int k = find(fTasks, button);
+if (k >= 0) {
+int i = k;
+do {
+i = (i - 1 + fTasks.getCount()) % fTasks.getCount();
+if (fTasks[i]->getShown()) {
+prev = fTasks[i]->getPrevShown(nullptr);
+if (prev && prev != tapp) {
+return prev;
+}
+}
+} while (i != k);
 }
 }
 return nullptr;
 }
 
 TaskBarApp* TaskPane::successor(TaskBarApp* tapp) {
-const int count = fApps.getCount();
-const int found = find(fApps, tapp);
-if (found >= 0) {
-for (int i = 1; i < count; ++i) {
-int k = (found + i) % count;
-if (fApps[k]->getShown()) {
-return fApps[k];
-}
+TaskButton* button = tapp->button();
+TaskBarApp* next = button->getNextShown(tapp);
+if (next && button->getShown()) {
+return next;
+} else {
+int k = find(fTasks, button);
+if (k >= 0) {
+int i = k;
+do {
+i = (i + 1) % fTasks.getCount();
+if (fTasks[i]->getShown()) {
+next = fTasks[i]->getNextShown(nullptr);
+if (next && next != tapp) {
+return next;
+}
+}
+} while (i != k);
 }
 }
 return nullptr;
diff --git a/src/atasks.h b/src/atasks.h
index 14553e7b..769d2f1d 100644
--- a/src/atasks.h
+++ b/src/atasks.h
@@ -61,6 +61,8 @@ public:
 int getOrder() const;
 int getCount() const;
 
+TaskBarApp* getNextShown(TaskBarApp* tapp) const;
+TaskBarApp* 

Bug#991134: firefox: connection failures when opening links in a new tab

[Mike Hommey]

On Thu, Jul 15, 2021 at 12:35:17PM +0200, Vincent Lefevre wrote:
> Package: firefox
> Version: 88.0.1-1
> Severity: normal
> 
> When opening a link in a new tab, connections sometimes fail, either
> for the HTML page, in which case Firefox displays an error message,
> or for the CSS, in which case the page is displayed without the CSS.
> This is always immediate, i.e. this is *not* some kind of timeout.
> I need to reload the page.
> 
> This seems to occur only when opening links in a new tab (and perhaps
> in a new window), not in the current tab, so that I suspect a bug in
> Firefox. This issue is quite recent (a few weeks?).
> 
> Note: This time, I was using an automatic proxy configuration URL, but
> I don't always use it. Anyway, this has also occurred for localhost,
> which is never proxied.
> 
> Firefox 90 should be available in unstable to see if this issue still
> occurs with it...

It's in experimental. It's not in unstable because a necessary build
dependency is not available in unstable because of the freeze.

(and I don't reproduce)

Bug#914128: perl: usrmerge issues

[Vagrant Cascadian]

Control: tags 914128 patch

On 2018-11-19, Niko Tyni wrote:
> Diffoscoping a perl built on a usrmerged [1] system with
> one built on a non-usrmerged system reveals the configure
> process hardcoding some paths in the build results,
>
> [1] https://wiki.debian.org/UsrMerge
>
> Snippets from config.h, Config.pm, Config_heavy.pl, config.sh.debug.gz
> and so forth include things below.
>
> The /bin vs. /usr/bin command paths can probably be fixed/worked around
> by passing the full /bin paths (which should work on both systems)
> directly to Configure. The /lib64 thing in libpth / glibpth looks like
> a bug to me. I don't know what to do about libsdirs and libsfound.
>
> There's potential breakage if perl is built on a usrmerged system but
> run on a non-usrmerged one. I suspect the breakage would not be very bad
> and that most of this is cosmetic and not widely used.

Attached are two patches which *partially* address the issues, fixing
binary paths and glibpth.


> -libpth => '/usr/local/lib /usr/lib/gcc/x86_64-linux-gnu/8/include-fixed 
> /usr/include/x86_64-linux-gnu /usr/lib /lib/x86_64-linux-gnu /lib/../lib 
> /usr/lib/x86_64-linux-gnu /usr/lib/../lib /lib',
> +libpth => '/usr/local/lib /usr/lib/gcc/x86_64-linux-gnu/8/include-fixed 
> /usr/include/x86_64-linux-gnu /usr/lib /lib/x86_64-linux-gnu /lib/../lib 
> /usr/lib/x86_64-linux-gnu /usr/lib/../lib /lib /lib64 /usr/lib64',

Still an issue. I tried patching Configure (and the relevent
regen-configure files) to not de-duplicate directories, but without
success. How to patch Configure sure is "fun". :)


> -lns='/bin/ln -s'
> +lns='/usr/bin/ln -s'
>
> -rm_try='/bin/rm -f try try a.out .out try.[cho] try..o core core.try* 
> try.core*'
> +rm_try='/usr/bin/rm -f try try a.out .out try.[cho] try..o core core.try* 
> try.core*'

Fixed by attached patch, *mostly* using unspecified binary paths.
full_sed is intended to actually contain a full path, so I specified
/bin/sed explicitly (since it works on both usrmerge/non-usrmerge
systems).


> -glibpth='/usr/shlib  /lib /usr/lib /usr/lib/386 /lib/386 /usr/ccs/lib 
> /usr/ucblib /usr/local/lib '
> +glibpth='/usr/shlib  /lib /usr/lib /usr/lib/386 /lib/386 /usr/ccs/lib 
> /usr/ucblib /usr/local/lib /lib64 /usr/lib64 /usr/local/lib64 '

Fixed by attached patch. Debian mostly uses multiarch rather than
bi-arch, and the bi-arch directories were only added when /usr/lib64
exists anyways...


> -libsdirs=' /usr/lib/x86_64-linux-gnu'
> +libsdirs=' /lib/x86_64-linux-gnu'
...
> -libsfound=' /usr/lib/x86_64-linux-gnu/libgdbm.so 
> /usr/lib/x86_64-linux-gnu/libgdbm_compat.so 
> /usr/lib/x86_64-linux-gnu/libdb.so /usr/lib/x86_64-linux-gnu/libdl.so 
> /usr/lib/x86_64-linux-gnu/libm.so /usr/lib/x86_64-linux-gnu/libpthread.so 
> /usr/lib/x86_64-linux-gnu/libc.so /usr/lib/x86_64-linux-gnu/libcrypt.so'

No longer issues... ?


> -libspath=' /usr/local/lib /usr/lib/gcc/x86_64-linux-gnu/8/include-fixed 
> /usr/include/x86_64-linux-gnu /usr/lib /lib/x86_64-linux-gnu /lib/../lib 
> /usr/lib/x86_64-linux-gnu /usr/lib/../lib /lib'
> +libspath=' /usr/local/lib /usr/lib/gcc/x86_64-linux-gnu/8/include-fixed 
> /usr/include/x86_64-linux-gnu /usr/lib /lib/x86_64-linux-gnu /lib/../lib 
> /usr/lib/x86_64-linux-gnu /usr/lib/../lib /lib /lib64 /usr/lib64'

Still an issue. Probably inherited from libpth...


live well,
  vagrant
From 1a0d653ef6fdbaa136625e1251493a3d918e78f3 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Thu, 15 Jul 2021 20:20:07 +
Subject: [PATCH 1/2] Configure / libpth.U: Do not adjust glibpth when
 /usr/lib64 is present.

This results in differing values when built on a usrmerge system.
---
 Configure   | 1 -
 regen-configure/U/modified/libpth.U | 1 -
 2 files changed, 2 deletions(-)

diff --git a/Configure b/Configure
index 952d09990..ade58f915 100755
--- a/Configure
+++ b/Configure
@@ -1462,7 +1462,6 @@ glibpth="/lib /usr/lib $xlibpth"
 glibpth="$glibpth /usr/ccs/lib /usr/ucblib /usr/local/lib"
 test -f /usr/shlib/libc.so && glibpth="/usr/shlib $glibpth"
 test -f /shlib/libc.so && glibpth="/shlib $glibpth"
-test -d /usr/lib64 && glibpth="$glibpth /lib64 /usr/lib64 /usr/local/lib64"
 
 : Private path used by Configure to find libraries.  Its value
 : is prepended to libpth. This variable takes care of special
diff --git a/regen-configure/U/modified/libpth.U b/regen-configure/U/modified/libpth.U
index ba7126df4..d42928078 100644
--- a/regen-configure/U/modified/libpth.U
+++ b/regen-configure/U/modified/libpth.U
@@ -83,7 +83,6 @@
 ?X:	/usr/shlib is for OSF/1 systems.
 ?INIT:test -f /usr/shlib/libc.so && glibpth="/usr/shlib $glibpth"
 ?INIT:test -f /shlib/libc.so && glibpth="/shlib $glibpth"
-?INIT:test -d /usr/lib64 && glibpth="$glibpth /lib64 /usr/lib64 /usr/local/lib64"
 ?INIT:
 ?INIT:: Private path used by Configure to find libraries.  Its value
 ?INIT:: is prepended to libpth. This variable takes care of special
-- 
2.32.0

From 

Bug#990816: python3-nosehtmloutput: nosetests3 --with-html fails with RuntimeWarning

[Jochen Sprickerhof]

Control: tags -1 patch

Hi,

this was fixed upstream in:

https://opendev.org/openstack/nose-html-output/commit/71d12999b06908bbb019f69c89361bd44bec316c

Which is basically the only change in version 0.7. I would propose to 
upload that and ask for an unblock. @Thomas: can you take care or should 
I do a NMU?


Cheers Jochen

* Enrique  [2021-07-08 11:27]:

Package: python3-nosehtmloutput
Version: 0.0.5-2
Severity: grave
Justification: renders package unusable
X-Debbugs-Cc: cqu...@arcor.de

Dear Maintainer,

I have installed python3-nosehtmloutput package but it seems as if the plugin
has a problem and it is not possible to use the --with-html option of
nosetests3  that would activate the plugin:

$ nosetests3 --with-html
/usr/lib/python3/dist-packages/nose/plugins/manager.py:394: RuntimeWarning:
Unable to load plugin html-output = htmloutput.htmloutput:HtmlOutput: No module
named 'version'
 warn("Unable to load plugin %s: %s" % (ep, e),
Usage: nosetests3 [options]

nosetests3: error: no such option: --with-html

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

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

Versions of packages python3-nosehtmloutput depends on:
ii  python3   3.9.2-3
ii  python3-nose  1.3.7-7

python3-nosehtmloutput recommends no packages.

python3-nosehtmloutput suggests no packages.


signature.asc
Description: PGP signature

Bug#990303: trafficserver: diff for NMU version 8.1.1+ds-1.1

[Salvatore Bonaccorso]

Control: tags 990303 + patch

Hi Jean Baptiste,

I've prepared an NMU for trafficserver (versioned as 8.1.1+ds-1.1). The diff
is attached to this message. Given the timeframe for the full freeze I
went ahead with no delay, as Moritz would like to see as well a
buster-security update. I hope this was fine with you to go straight
with the NMU version to unstable, including a cherry-pick of the
commit Moritz referenced before.

Regards,
Salvatore
diff -Nru trafficserver-8.1.1+ds/debian/changelog trafficserver-8.1.1+ds/debian/changelog
--- trafficserver-8.1.1+ds/debian/changelog	2020-12-06 16:26:39.0 +0100
+++ trafficserver-8.1.1+ds/debian/changelog	2021-07-15 21:48:17.0 +0200
@@ -1,3 +1,20 @@
+trafficserver (8.1.1+ds-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Address CVE-2021-27577, CVE-2021-32565, CVE-2021-32566, CVE-2021-32567 and
+CVE-2021-35474.
+- CVE-2021-27577: Incorrect handling of url fragment leads to cache
+  poisoning
+- CVE-2021-32565: HTTP Request Smuggling, content length with invalid
+  charters
+- CVE-2021-32566: Specific sequence of HTTP/2 frames can cause ATS to
+  crash
+- CVE-2021-32567: Reading HTTP/2 frames too many times
+- CVE-2021-35474: Dynamic stack buffer overflow in cachekey plugin
+(Closes: #990303)
+
+ -- Salvatore Bonaccorso   Thu, 15 Jul 2021 21:48:17 +0200
+
 trafficserver (8.1.1+ds-1) unstable; urgency=medium
 
   * New upstream version 8.1.0+ds
diff -Nru trafficserver-8.1.1+ds/debian/patches/0018-Fixes-7971.patch trafficserver-8.1.1+ds/debian/patches/0018-Fixes-7971.patch
--- trafficserver-8.1.1+ds/debian/patches/0018-Fixes-7971.patch	1970-01-01 01:00:00.0 +0100
+++ trafficserver-8.1.1+ds/debian/patches/0018-Fixes-7971.patch	2021-07-15 21:45:16.0 +0200
@@ -0,0 +1,153 @@
+From: Evan Zelkowitz 
+Date: Tue, 22 Jun 2021 14:32:55 -0700
+Subject: Fixes (#7971)
+Origin: https://github.com/apache/trafficserver/commit/b82a3d192f995fb9d78e1c44d51d9acca4783277
+Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2021-27577
+Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2021-32565
+Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2021-32566
+Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2021-32567
+Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2021-35474
+Bug-Debian: https://bugs.debian.org/990303
+
+* String the url fragment for outgoing requests (#7966)
+
+Co-authored-by: Susan Hinrichs 
+(cherry picked from commit 2b13eb33794574e62249997b4ba654d943a10f2d)
+
+* Ensure that the content-length value is only digits (#7964)
+
+Co-authored-by: Susan Hinrichs 
+(cherry picked from commit 668d0f8668fec1cd350b0ceba3f7f8e4020ae3ca)
+
+* Schedule H2 reenable event only if it's necessary
+
+Co-authored-by: Katsutoshi Ikenoya 
+
+* Fix dynamic-stack-buffer-overflow of cachekey plugin (#7945)
+
+* Fix dynamic-stack-buffer-overflow of cachekey plugin
+
+* Check dst_size include null termination
+
+(cherry picked from commit 5a9339d7bc65e1c2d8d2a0fc80bb051daf3cdb0b)
+
+Co-authored-by: Bryan Call 
+Co-authored-by: Masakazu Kitajo 
+Co-authored-by: Katsutoshi Ikenoya 
+Co-authored-by: Masaori Koshiba 
+---
+ plugins/cachekey/cachekey.cc  |  2 +-
+ proxy/hdrs/HTTP.cc| 11 +++
+ proxy/http/HttpTransact.cc|  5 -
+ proxy/http2/Http2ClientSession.cc | 14 +++---
+ proxy/logging/LogUtils.cc |  2 +-
+ 5 files changed, 24 insertions(+), 10 deletions(-)
+
+diff --git a/plugins/cachekey/cachekey.cc b/plugins/cachekey/cachekey.cc
+index 5f128894bfa8..44925b3db280 100644
+--- a/plugins/cachekey/cachekey.cc
 b/plugins/cachekey/cachekey.cc
+@@ -41,7 +41,7 @@ appendEncoded(String , const char *s, size_t len)
+ return;
+   }
+ 
+-  char tmp[len * 2];
++  char tmp[len * 3 + 1];
+   size_t written;
+ 
+   /* The default table does not encode the comma, so we need to use our own table here. */
+diff --git a/proxy/hdrs/HTTP.cc b/proxy/hdrs/HTTP.cc
+index 6a2ecc41d3ad..48032dd9ddf4 100644
+--- a/proxy/hdrs/HTTP.cc
 b/proxy/hdrs/HTTP.cc
+@@ -1202,6 +1202,17 @@ validate_hdr_content_length(HdrHeap *heap, HTTPHdrImpl *hh)
+ int content_length_len = 0;
+ const char *content_length_val = content_length_field->value_get(_length_len);
+ 
++// RFC 7230 section 3.3.2
++// Content-Length = 1*DIGIT
++//
++// If the content-length value contains a non-numeric value, the header is invalid
++for (int i = 0; i < content_length_len; i++) {
++  if (!isdigit(content_length_val[i])) {
++Debug("http", "Content-Length value contains non-digit, returning parse error");
++return PARSE_RESULT_ERROR;
++  }
++}
++
+ while (content_length_field->has_dups()) {
+   int content_length_len_2 = 0;
+   const char *content_length_val_2 = content_length_field->m_next_dup->value_get(_length_len_2);
+diff --git 

Bug#990439: postsrsd: CVE-2021-35525

[Salvatore Bonaccorso]

Hi,

On Wed, Jul 14, 2021 at 10:07:23PM +0200, Oxan van Leeuwen wrote:
> Hi Salvatore,
> 
> Sorry for the delay in getting back to you.

No worries!

> On 05-07-2021 21:47, Salvatore Bonaccorso wrote:
> > I think we can do the following action plan, let me know if you agree:
> > The release btw is not yet fully missed, so I would suggest: upload a
> > very targetted fix aimed for bullseye to unstable, ask the release
> > team for unblocking and aging the package, so we make sure the fix
> > lands in bullseye before the release.
> > 
> > For buster, it looks to me that the issue is low severity enough that
> > we can have an update via an upcoming point release.
> 
> Sounds like a plan. I've prepared the updated packages with a backport from
> upstream, asked my sponsor to upload them and filed unblock bugs
> (#991119 for bullseye and #991120 for buster).

Thank you!

Regards,
Salvatore

Bug#991151: corekeeper: postrm: invoke-rc.d: initscript procps, action "reload" failed.

[Thorsten Glaser]

Package: corekeeper
Version: 1.7
Severity: serious
Justification: does not uninstall
X-Debbugs-Cc: t...@mirbsd.de

Removing corekeeper:x32 (1.7) ...
Usage: /etc/init.d/procps {start|stop|status|restart|try-restart|force-reload}
invoke-rc.d: initscript procps, action "reload" failed.
dpkg: error processing package corekeeper:x32 (--remove):
 installed corekeeper:x32 package post-removal script subprocess returned error 
exit status 3
dpkg: too many errors, stopping
Errors were encountered while processing:
 corekeeper:x32



-- System Information:
Debian Release: 11.0
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'buildd-unstable'), (500, 'unstable'), 
(100, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: x32, i386

Kernel: Linux 5.10.0-6-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

Versions of packages corekeeper depends on:
ii  procps  2:3.3.17-5

corekeeper recommends no packages.

corekeeper suggests no packages.

-- no debconf information

Bug#990754: unblock: wpewebkit/2.32.1-1

[Sebastian Ramacher]

On 2021-07-07 11:53:16 +0200, Moritz Muehlenhoff wrote:
> On Tue, Jul 06, 2021 at 10:11:36PM +0200, Sebastian Ramacher wrote:
> > Control: tags -1 moreinfo
> > 
> > On 2021-07-06 11:20:10 +0200, Alberto Garcia wrote:
> > > Package: release.debian.org
> > > Severity: normal
> > > User: release.debian@packages.debian.org
> > > Usertags: unblock
> > > 
> > > Please unblock package wpewebkit
> > > 
> > > webkit2gtk was unblocked last month, testing has the most recent
> > > stable version and we will provide security updates during the
> > > lifetime of bullseye, as we already did during buster.
> > > 
> > > wpewebkit is another official port of webkit. It's maintained by the
> > > same team, follows a very similar release schedule and numbering
> > > system, shares most of the code and almost all CVEs fixes apply to
> > > both ports.
> > > 
> > > Because of this it won't take me too much effort to prepare security
> > > updates for wpewebkit so the Debian security team is proposing that we
> > > also provide them.
> > > 
> > > If we do this we should unblock the package and put the latest stable
> > > version in testing. At the moment the only user of wpewebkit in Debian
> > > is cog, which is a simple, single-window web browser, developed and
> > > released by the same team. So we should also unblock cog and the two
> > > other libraries that are part of the wpewebkit releases: libwpe and
> > > wpebackend-fdo (I don't know if you need separate bugs to unblock
> > > those).
> > > 
> > > If we don't do this then it's probably a good idea to mention in the
> > > release notes that wpewebkit is not covered by security updates.
> > 
> > What's the security team's take on this? Will browsers other than firefox,
> > chromium and webkit2gtk itself be security supported throughout bullseye's
> > lifetime?
> 
> We synced up with this before; wpewebkit is closely related to webkit and
> Alberto will keep both updated in stable.

Is this also the plan for cog, wpebackend-fdo and libwpe?

Cheers

> 
> > The concern also extends to web rendering engines not explicitly
> > mentioned here, with the exception of  > role="source">webkit2gtk.
> 
> Good point wrt the releases notes part. I guess we should simply
> make this "with the exception of webkit2gtk/wpewebkit". Alberto, could
> you file a bug against the release notes?
> 
> Cheers,
> Moritz
> 

-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#991149: ITP: icinga-php-thirdparty -- Icinga PHP Thirdparty libraries for Icinga Web 2

[Bas Couwenberg]

Package: wnpp
Severity: wishlist
Owner: Bas Couwenberg 
X-Debbugs-Cc: debian-de...@lists.debian.org, 
pkg-nagios-de...@lists.alioth.debian.org

* Package name: icinga-php-thirdparty
  Version : 0.10.0
  Upstream Author : Icinga GmbH
* URL : https://icinga.com
* License : MIT
  Programming Lang: PHP
  Description : Icinga PHP Thirdparty libraries for Icinga Web 2

 Icinga Web 2 is a very modular, fast and simple web interface for your Icinga
 monitoring environment.
 .
 The software will give you a web frontend for your monitoring solution, and
 can run additional modules, extending monitoring data, or even supplying
 something new to the webinterface.
 .
 This package provides the Icinga PHP thirdparty libraries.

The package is required for icingaweb2 (>= 2.9.0) and will be maintained within 
the Nagios team.

Bug#991148: ITP: icinga-php-library -- Icinga PHP Library for Icinga Web 2

[Bas Couwenberg]

Package: wnpp
Severity: wishlist
Owner: Bas Couwenberg 
X-Debbugs-Cc: debian-de...@lists.debian.org, 
pkg-nagios-de...@lists.alioth.debian.org

* Package name: icinga-php-library
  Version : 0.6.0
  Upstream Author : Icinga GmbH
* URL : https://icinga.com
* License : MIT
  Programming Lang: PHP
  Description : Icinga PHP Library for Icinga Web 2

 Icinga Web 2 is a very modular, fast and simple web interface for your Icinga
 monitoring environment.
 .
 The software will give you a web frontend for your monitoring solution, and
 can run additional modules, extending monitoring data, or even supplying
 something new to the webinterface.
 .
 This package provides the Icinga PHP libraries.

The package is required for icingaweb2 (>= 2.9.0) and will be maintained within 
the Nagios team.

Bug#990923: minetest: diff for NMU version 5.3.0+repack-2.1

[Martin Quinson]

> --  Le 15 Juil 21, à 18:59, Adrian Bunk b...@debian.org a écrit :
> Dear maintainer,
> 
> I've prepared an NMU for minetest (versioned as 5.3.0+repack-2.1) and
> uploaded it to DELAYED/1. Please feel free to tell me if I should cancel it.

Dear Adrian,

I'm only co-maintainer, and not very active on this package since years (I 
should probably remove myself from the uploader list), but I would like to 
thank you for your time.

Thanks again,
Mt

Bug#904677: Maybe also with german layout

[chno]

Hi I just added info to the bug #908287 (about keybindings not working). 
Right after I searched for further information and came across that 
maybe the language destroys the keybindings.


Most custom keybindings on my Debian Setup (english, but german keyboard 
layout) do not work.

Bug#990923: minetest: diff for NMU version 5.3.0+repack-2.1

[Adrian Bunk]

Control: tags 990923 + patch
Control: tags 990923 + pending

Dear maintainer,

I've prepared an NMU for minetest (versioned as 5.3.0+repack-2.1) and 
uploaded it to DELAYED/1. Please feel free to tell me if I should cancel it.

cu
Adrian
diff -Nru minetest-5.3.0+repack/debian/changelog minetest-5.3.0+repack/debian/changelog
--- minetest-5.3.0+repack/debian/changelog	2021-01-31 15:41:26.0 +0200
+++ minetest-5.3.0+repack/debian/changelog	2021-07-15 18:55:57.0 +0300
@@ -1,3 +1,11 @@
+minetest (5.3.0+repack-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Add upstream fix for errors caused by missing param2
+in falling.lua, thanks to Craig Small. (Closes: #990923)
+
+ -- Adrian Bunk   Thu, 15 Jul 2021 18:55:57 +0300
+
 minetest (5.3.0+repack-2) unstable; urgency=medium
 
   * Team upload.
diff -Nru minetest-5.3.0+repack/debian/patches/0001-Falling-Fix-error-caused-by-missing-param2.patch minetest-5.3.0+repack/debian/patches/0001-Falling-Fix-error-caused-by-missing-param2.patch
--- minetest-5.3.0+repack/debian/patches/0001-Falling-Fix-error-caused-by-missing-param2.patch	1970-01-01 02:00:00.0 +0200
+++ minetest-5.3.0+repack/debian/patches/0001-Falling-Fix-error-caused-by-missing-param2.patch	2021-07-15 18:55:34.0 +0300
@@ -0,0 +1,26 @@
+From aba8c3753162320c7cc8a66913ad82f4f1fd0d8b Mon Sep 17 00:00:00 2001
+From: SmallJoker 
+Date: Thu, 30 Jul 2020 19:03:48 +0200
+Subject: Falling: Fix error caused by missing param2
+
+Falling nodes that were spawned prior the recent falling node changes did not require param2.
+Default to param2 = 0 when none is found in the node data.
+---
+ builtin/game/falling.lua | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/builtin/game/falling.lua b/builtin/game/falling.lua
+index 714506a5f..4bfcca9e7 100644
+--- a/builtin/game/falling.lua
 b/builtin/game/falling.lua
+@@ -52,6 +52,7 @@ core.register_entity(":__builtin:falling_node", {
+ 	floats = false,
+ 
+ 	set_node = function(self, node, meta)
++		node.param2 = node.param2 or 0
+ 		self.node = node
+ 		meta = meta or {}
+ 		if type(meta.to_table) == "function" then
+-- 
+2.20.1
+
diff -Nru minetest-5.3.0+repack/debian/patches/series minetest-5.3.0+repack/debian/patches/series
--- minetest-5.3.0+repack/debian/patches/series	2021-01-31 11:43:36.0 +0200
+++ minetest-5.3.0+repack/debian/patches/series	2021-07-15 18:55:53.0 +0300
@@ -2,3 +2,4 @@
 shared_mods.patch
 rawlua.patch
 postgresql.patch
+0001-Falling-Fix-error-caused-by-missing-param2.patch

Bug#991147: www.debian.org: typo in News/2021/20210619.wml (DMs instead of DDs)

[Rafa]

Package: www.debian.org
Severity: minor

Dear Maintainers,

Page News/2021/20210619.wml, as of commit
2cb38f6ccb556cd943a6b281b6667e07cc0dcbb1, states in line 73:

"[...] make dcut dm work for non-uploading DMs; [...]"

I think that, instead of "DMs", it should read "DDs", according to
https://tracker.debian.org/news/1237374/accepted-dput-ng-125deb10u2-source-into-proposed-updates-stable-new-proposed-updates/:

"[ nicoo ]
 * Make `dcut dm` also accept non-uploading DDs, since they are nowadays
   treated the same as DMs when concerning upload permissions.
   Closes: #985618; MR: !16"

Regards,

Rafa.



signature.asc
Description: PGP signature

Bug#989080: cifs-utils: Fix for CVE-2021-20208 breaks cifs.upcall

[Samuel Zarn]

Is there anything a random outside user (like myself) can do to further
this merge request along? I rely on KRB5 auth for CIFS mounts and
having this still be broken is a bit frustrating. It looks like the
merge request is still open and sitting there. I'm willing to help
however I can.


-- 
Sam Zarn
Systems & Network Administrator

Bug#991146: python3-libxml2: ambiguous package name 'python3-libxml2' with more than one installed instance

[Thorsten Glaser]

reassign 991146 dh-python
thanks

Thorsten Glaser dixit:

>Setting up python3-libxml2:amd64 (2.9.10+dfsg-6.7) ...
>dpkg-query: error: --listfiles needs a valid package name but 
>'python3-libxml2' is not: ambiguous package name 'python3-libxml2' with more 
>than one installed instance
>
>Use --help for help about querying packages.
>Traceback (most recent call last):
>  File "/usr/bin/py3compile", line 319, in 
>main()
>  File "/usr/bin/py3compile", line 298, in main
>compile(files, versions,
>  File "/usr/bin/py3compile", line 183, in compile
>for fn, versions_to_compile in filter_files(files, e_patterns, versions):
>  File "/usr/bin/py3compile", line 128, in filter_files
>for fpath in files:
>  File "/usr/share/python3/debpython/files.py", line 71, in filter_public
>for fn in files:
>  File "/usr/share/python3/debpython/files.py", line 53, in from_package
>raise Exception("cannot get content of %s" % package_name)
>Exception: cannot get content of python3-libxml2
>dpkg: error processing package python3-libxml2:amd64 (--configure):
> installed python3-libxml2:amd64 package post-installation script subprocess 
> returned error exit status 1

This affects python3-pil, python3-cairo, … as well. Going from…

-BEGIN cutting here may damage your screen surface-
root@tglase:~ # cat /var/lib/dpkg/info/python3-cairo\:amd64.postinst
#!/bin/sh
set -e

# Automatically added by dh_python3
if which py3compile >/dev/null 2>&1; then
py3compile -p python3-cairo
fi
if which pypy3compile >/dev/null 2>&1; then
pypy3compile -p python3-cairo  || true
fi

# End automatically added section
-END cutting here may damage your screen surface-

… this is a bug in dh_python3 because changing to…

py3compile -p python3-cairo:amd64

… makes this succeed.

bye,
//mirabilos
-- 
Gestern Nacht ist mein IRC-Netzwerk explodiert. Ich hatte nicht damit
gerechnet, darum bin ich blutverschmiert… wer konnte ahnen, daß SIE so
reagier’n… gestern Nacht ist mein IRC-Netzwerk explodiert~~~
(as of 2021-06-15 The MirOS Project temporarily reconvenes on OFTC)

Bug#991059: diffoscope: subprocess.CalledProcessError: Command unsquashfs... returned non-zero exit status 1

[Mattia Rizzolo]

On Wed, Jul 14, 2021 at 08:31:48PM +0200, Roland Clobus wrote:
> I'm planning to change the Jenkins job, such that the files that cause
> diffoscope to crash will be published. Each file is 2.6GB.

In this case, please have a look at reproducible_build.sh that already
does something similar.  you might want to consider moving the relevant
function to _common.sh and call it wherever else you need it.

> The difference between these two files is located inside a squashfs
> file, which is inside the iso file.
> During the invocation of diffoscope, diffoscope needs lots of memory
> (>32GB) and free space on /tmp (>32GB but <48GB).

Sigh, that's huge. :(

> In the mean time, the timeout of 30 minutes in Jenkins has been raised
> to 120 minutes, but that still does not fix the crash.
…
> I've attempted to reproduce the ISO files (using an older snapshot) on
> my own comupter, but there diffoscope was able to run until the end,
> even though it needed 105 minutes wall time...

105 in an idle system probably means that it would need 3/4 hours on
jenkins.  120 totally won't fit.


(BTW, this doesn't change that diffoscope shouldn't crash, just the
timeout wrapper exiting.)

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#908287: Same problem MC

[chno]

Hi I have the same problem like Helen.

I've encountered the error also for e.g. "Menu" and "View". If I set 
custom binding they will not work.


I am getting the error on Debian Buster and on a fresh Debian Bullseye 
(minimal, only systemtools) Installation.

Bug#991146: python3-libxml2: ambiguous package name 'python3-libxml2' with more than one installed instance

[Thorsten Glaser]

Package: python3-libxml2
Version: 2.9.10+dfsg-6.7
Severity: serious
Justification: fails to install
X-Debbugs-Cc: t...@mirbsd.de

During crossgrading or when installing multiple versions of python3-libxml2
they fail to configure because of a bug in the postinst script:

Setting up python3-libxml2:amd64 (2.9.10+dfsg-6.7) ...
dpkg-query: error: --listfiles needs a valid package name but 'python3-libxml2' 
is not: ambiguous package name 'python3-libxml2' with more than one installed 
instance

Use --help for help about querying packages.
Traceback (most recent call last):
  File "/usr/bin/py3compile", line 319, in 
main()
  File "/usr/bin/py3compile", line 298, in main
compile(files, versions,
  File "/usr/bin/py3compile", line 183, in compile
for fn, versions_to_compile in filter_files(files, e_patterns, versions):
  File "/usr/bin/py3compile", line 128, in filter_files
for fpath in files:
  File "/usr/share/python3/debpython/files.py", line 71, in filter_public
for fn in files:
  File "/usr/share/python3/debpython/files.py", line 53, in from_package
raise Exception("cannot get content of %s" % package_name)
Exception: cannot get content of python3-libxml2
dpkg: error processing package python3-libxml2:amd64 (--configure):
 installed python3-libxml2:amd64 package post-installation script subprocess 
returned error exit status 1



-- System Information:
Debian Release: 11.0
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'buildd-unstable'), (500, 'unstable'), 
(100, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: x32, i386

Kernel: Linux 5.10.0-6-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

Versions of packages python3-libxml2 depends on:
ii  libc62.31-13
ii  libxml2  2.9.10+dfsg-6.7
ii  python3  3.9.2-3

python3-libxml2 recommends no packages.

python3-libxml2 suggests no packages.

-- no debconf information

Bug#990184: krita: inavlid mime type in desktop file

[Erwan David]

Le 23/06/2021 à 18:44, Erwan David a écrit :
> Le 23/06/2021 à 18:06, Lisandro Damián Nicanor Pérez Meyer a écrit :
>> Control: tag -1 moreinfo unreproducible
>>
>> On Tue, 22 Jun 2021 at 06:09, Erwan David  wrote:
>>> Package: krita
>>> Version: 1:4.4.2+dfsg-1
>>> Severity: normal
>>>
>>> Each time menus are upgraded I get message :
>>> Error in file "/usr/share/applications/krita_jpeg.desktop": "jpeg/jfif" is 
>>> an invalid MIME type ("jpeg" is an unregistered media type)
>>>
>>> And indeed this file contains
>>> MimeType=image/jpeg;jpeg/jfif
>> I have just installed krita and I did not see any warning while
>> installing it. How do you "upgrade the menus"?
>>
>>
>> Regards, Lisandro.
>>
> It happens each time another package with a .desktop file is upgraded, I
> do not know what is exactly called at that time.
>
Hi, I got the error tod    ay when upgrading, thus I knew the package
and got a look at the portinst script.

The command which leads to the error message is :

update-desktop-database /usr/share/applications

Bug#991145: unblock: syncthing/1.12.1~ds1-3

[Alexandre Viau]

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

Please unblock package syncthing.

[ Reason ]

It contains various fixes, all of them provided by upstream sending
patches for our specific version of syncthing.

Notably, it fixes CVE-2021-21404.

[ Impact ]

Less bugs, less CVES, better upstream cooperation!


--
Alexandre Viau
av...@debian.org


syncthing.debdiff
Description: Binary data

Bug#990832: Additional information

[William Haller]

Still see some dropped header information - drastically less, but not 0. 
So I'd say there still might be a race condition or error handling that 
isn't right.


I tried to move the outputbuffer handling into ::output, moving any 
existing outputbuffer contents to a temporary buffer, killing the 
outputbuffer, and dumping that temp buffer first once connected was set, 
but I was still getting unparseable relays. Then I pulled the connection 
attempt for each line completely letting everything be buffered and just 
did the connection attempt after the _eoh was buffered to the 
outputbuffer (turning on connected before the Connect call as it was 
before - just done after everything was buffered). This also gave 
unparseable relays, but in both of these cases at least all received 
headers were examined by spamd.


So I'm thinking that the dropped lines are one problem - and either of 
the above solutions might help with that - I don't know - but that there 
is also a received header formation problem that spamd doesn't like the 
result of.



A sample header in the text e-mail might be

Received: from mail02.connect.hpe.com (mail02.connect.hpe.com 
[204.92.22.193])

    (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
    (No client certificate requested)
    by postoffice-2.autoelect.com (Postfix) with ESMTPS id 9278E9FFB5
    for ; Thu, 15 Jul 2021 09:53:19 -0600 (MDT)

and I see

Received header for spamc: Received: from mail02.connect.hpe.com 
(unknown)#015#012#011by postoffice-2.autoelect.com (8.13.0/8.13.0) with 
SMTP id unknown#015#012#011Thu, 15 Jul 2021 09:53:19 
-0600#015#012#011(envelope-from );#015


output "Received: from mail02.connect.hpe.com (unknown)#015#012#011by 
postoffice-2.autoelect.com (8.13.0/8.13.0) with SMTP id 
unknown#015#012#011Thu, 15 Jul 2021 09:53:19 
-0600#015#012#011(envelope-from );#015#012"


output "Received: from P01SNJ404 (10.32.120.245) by 
mail02.connect.hpe.com id hu1cus2q38k7 for ; 
Thu, 15 Jul 2021 11:53:18 -0400 (envelope-from 
)#015#012"


from spamass-milter logging and


received-header: unparseable: from mail02.connect.hpe.com (unknown) by 
postoffice-2.autoelect.com (8.13.0/8.13.0) with SMTP id unknown Thu, 15 
Jul 2021 09:53:19 -0600 (envelope-from );


received-header: parsed as [ ip=10.32.120.245 rdns=P01SNJ404 
helo=P01SNJ404 by=mail02.connect.hpe.com ident= 
envfrom=bounceb...@connect.hpe.com intl=0 id=hu1cus2q38k7 auth= msa=0 ]


received-header: relay 10.32.120.245 trusted? yes internal? yes msa? no

from spamd's logging


Thanks, Bill

Bug#991144: unblock: libaperture-0/0.1.0+git20200908-2

[Henry-Nicolas Tourneur]

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

Please unblock package libaperture-0

The source package libaperture-0 is missing --with gir when calling
debhelper in debian/rules. This results in ${gir:Depends} not being
expanded properly and therefore gir1.2-aperture-0 is missing
dependencies.

[ Reason ]
Closes RC bug #991078 - missing gir dependencies on binary package.

[ Impact ]
The binary package gir1.2-aperture-0 is missing dependencies.

[ Tests ]
No specific tests added, the change only affect the debian packaging,
not the upstream code.

[ Risks ]
Change is trivial and this is not a key package (it is a leaf package).
Therefore I consider the risk as very low.

[ Checklist ]
  [x] all changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in testing

[ Other info ]
n/a

unblock libaperture-0/0.1.0+git20200908-2
diff -Nru libaperture-0-0.1.0+git20200908/debian/changelog 
libaperture-0-0.1.0+git20200908/debian/changelog
--- libaperture-0-0.1.0+git20200908/debian/changelog2020-07-06 
09:53:19.0 +
+++ libaperture-0-0.1.0+git20200908/debian/changelog2021-07-15 
15:53:35.0 +
@@ -1,3 +1,9 @@
+libaperture-0 (0.1.0+git20200908-2) unstable; urgency=medium
+
+  * d/rules: ensure dh uses --with gir (Closes: #991078)
+
+ -- Henry-Nicolas Tourneur   Thu, 15 Jul 2021 15:53:35 +
+
 libaperture-0 (0.1.0+git20200908-1) unstable; urgency=medium
 
   * Initial Debian release (Closes: #969745)
diff -Nru libaperture-0-0.1.0+git20200908/debian/rules 
libaperture-0-0.1.0+git20200908/debian/rules
--- libaperture-0-0.1.0+git20200908/debian/rules2020-07-06 
09:53:19.0 +
+++ libaperture-0-0.1.0+git20200908/debian/rules2021-07-15 
15:52:50.0 +
@@ -3,7 +3,7 @@
 export DEB_BUILD_MAINT_OPTIONS = hardening=+all
 
 %:
-   dh $@ --builddirectory=_build
+   dh $@ --builddirectory=_build --with gir
 
 override_dh_auto_test:
 ifeq ($(filter nocheck,$(DEB_BUILD_OPTIONS)),)

Bug#990882: openssh-server: With ipv6 ssh-client fail as well as scp getting expecting SSH2_MSG_KEX_ECDH_REPLY

[Daniel]

Hallo TImo

Le 11/07/2021 à 22:04, Timo Weingärtner a écrit :

Hallo Daniel,

10.07.21 14:14 Daniel:

ssh and scp connecting smoothly. With the above MACs trick, scp connect
but then hangs on copy like

Authenticated to myserver ([2001:db8:dead:beef::1]:22).
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessi...@openssh.com
debug1: Entering interactive session.
debug1: pledge: network
debug1: client_input_global_request: rtype hostkeys...@openssh.com
want_reply 0
debug1: Remote: /root/.ssh/authorized_keys:2: key options:
agent-forwarding port-forwarding pty user-rc x11-forwarding
debug1: Remote: /root/.ssh/authorized_keys:2: key options:
agent-forwarding port-forwarding pty user-rc x11-forwarding
debug1: Sending environment.
debug1: Sending env LANG = fr_FR.UTF-8
debug1: Sending command: scp -v -t /etc/bind/VarCacheBind/
Sending file modes: C0644 3079 file.txt
Sink: C0644 3079 file.txt
file.txt 0% 0 0.0KB/s --:-- ETA

So actually the connection setup (small packets) works and the connection
starts hanging when packets get big.


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

Adding MACs=hmacs-sha2-256 to .ssh/config solved the problem for ssh
client (Debian 9/10 & Ubuntu 18/20) but not for scp (Debian 9/10 &
Ubuntu 18/20)

A quick test with wireshark shows: ssh client with default/no config sends a
"Client: Key Exchange Init" with over 1500 Bytes. With that config change you
likely dropped that below your PMTU.

What is the network between client and server like? Does PMTUD work? Maybe
there are non-conforming IPv6-implementations and/or misconfigured firewalls
on the way?


This server has few interfaces, each having his own ipv6 address. The 
one I have a problem with is a tun interface from openvpn, other ipv6 
addresses connected to ethx interfaces doesn't present this problem. I 
tried with mtu 1492 (1500 is default), 1450 and 1440, no changes


The setup of this server is the same since long time and it worked 
perfectly till the system update of end june/early july.


I stopped the fw (nftables), no changes. Servers are located in DC 
(Hetzner).


How can I check if PMTUd is working ?

Thanks for your support


If we do the copy in ipv4 -by adding -4 in front of command- it copy
smoothly.

Well, in IPv4 routers usually do fragmentation (lowering throughput/
efficiency) instead of relying on PMTUD.

Bug#990950: Question about packaging a Lisp image

[Torrance, Douglas]

On Wed 14 Jul 2021 01:10:36 PM EDT, Sébastien Villemot  
wrote:

[Sorry, resending with proper quoting; my email client somehow messed things up]

Hi Douglas,

Le dimanche 11 juillet 2021 à 17:08 +, Torrance, Douglas a écrit :


I would like to package bergman [1], a Common Lisp program for computations in
noncommutative algebra.



Upstream's build script creates an executable by generating an image with
SAVEINITMEM.  However, in order for some of the features of bergman to work
properly, the source files must be present, and in the same location as they
were during build time, at runtime.  So generating the image while building the
binary package won't work, as then at runtime we'd be looking for some
non-existent directory from the buildd machines.  (Not to mention the
reproducibility issues from having these paths hardcoded in the image!)



One solution that I've come up with is to just have the Debian package install
the necessary source files, and then have the postinst script run the upstream
build script and generate the image right there on the user's system as part of
the installation process.



I'm very new to Common Lisp, so I'm not sure if this is the best strategy.  Is
there another method that would be recommended instead?


First, note that Common Lisp is a standard, which has different
implementations. In Debian, we have 5 of them, the most important ones
being SBCL, ECL and CLISP.¹

My understanding is that Bergman uses CLISP as its reference
implementation. This is a rather slow Common Lisp implementation, but
it is well-supported in Debian. SBCL is a much faster implementation,
but I don’t know if Bergman works with it (at the very least you would
have to modify the build system).

Applications programmed in Common Lisp typically ship the lisp image in
the binary package. See for example xindy², which also uses CLISP. See
also pgloader³, that uses SBCL (and relies on buildapp⁴ for creating
the executable from the lisp image).

So the ideal solution would still be to patch Bergman in a way that
allows it to work with sources under a standard location (typically
/usr/share/common-lisp/source/bergman/).

If that’s not possible, then you could do as you suggest: only ship the
sources in the binary package (under the location mentioned above), and
build the lisp image in the postinst script.

Note that most Common Lisp library packages only ship sources as well
(under /usr/share/common-lisp/source/), but they don’t provide any lisp
image. These libraries are supposed to be loaded from implementations,
typically via ASDF, into the running lisp image.

I hope this clarifies a bit. Don’t hesitate to ask for further advice,
since the Common Lisp way of doings things can be disturbing at first
sight. In particular, I suggest that you go through the introductory
wiki page linked below.

Best,

¹ For more details on Common Lisp and Debian, see 
https://wiki.debian.org/CommonLisp
² https://tracker.debian.org/pkg/xindy
³ https://tracker.debian.org/pkg/pgloader
⁴ https://tracker.debian.org/pkg/buildapp


Thank you so much for all of this information!  I'll do some more work and see 
if it's possible to patch things and ship the lisp image in the package, but 
it's good to hear that the postinst option would work as well.

Thanks again!
Doug


signature.asc
Description: PGP signature

Bug#991143: RFP: pythran -- an ahead of time compiler for Python

[Drew Parsons]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: debian-pyt...@lists.debian.org, debian-scie...@lists.debian.org

* Package name: pythran
  Version : 0.9.12
  Upstream Author : Serge Guelton 
* URL : https://github.com/serge-sans-paille/pythran
* License : BSD
  Programming Lang: Python/C++
  Description : an ahead of time compiler for Python

Pythran is an ahead of time compiler for a subset of the Python
language, with a focus on scientific computing. It takes a Python
module annotated with a few interface descriptions and turns it into a
native Python module with the same interface, but (hopefully) faster.

It is meant to efficiently compile scientific programs, and takes
advantage of multi-cores and SIMD instruction units.

Pythran is starting to get used upstream in some of our numerical
packages, including dolfinx.

Pythran is a general tool for accelerating the execution of python
modules, so more suited for team management by the debian-python team.
But the use-case is mainly in scientific programming so the
debian-science team may like to take it on.

It may require some dependencies to be packaged:
  gast
  beniget

Bug#990807: thunderbird incapable to run only with ~/.thunderbird that was migrated from icedove

[Tomas Pospisek]

Thanks a lot for the explanation Carsten!
*t

On Thu, 15 Jul 2021, Carsten Schoenert wrote:


Hello Tomas,

Am 12.07.21 um 11:07 schrieb Tomas Pospisek:


If I'd like to get rid of ~/.icedove and only have a standard
~/.thunderbird directory - which I am assuming is possible - then what
would the correct way to do that be?


the main mess is you will need to go to your profile and replace all
occurrences of ".icdeove" with ".thunderbird" within the files. Doing
this for .js|.json|.xml and so on files will be mostly easy, but it's
possible that there is also something in the encrypted files and also in
the .sqlite files.

It's all doable, and I wanted to start something that is doing that
trick, but it's in the end a more cleaner way to export the profile and
later re import it again. But exporting a profile by TB directly isn't
still full featured.

As long as nobody is digging into this we will need to live with the
symlinked folder.

--
Regards
Carsten

Bug#991142: f_debug side effects

[Matus UHLAR - fantomas]

Package: syslog-ng-core
Version: 3.19.1-5

Hello,
the standard syslog-ng.conf contains (among others) these lines:

filter f_dbg { level(debug); };

filter f_debug { level(debug) and not facility(auth, authpriv, news, mail); };

filter f_auth { facility(auth, authpriv) and not filter(f_debug); };

filter f_mail { facility(mail) and not filter(f_debug); };
filter f_news { facility(news) and not filter(f_debug); };

log { source(s_src); filter(f_auth); destination(d_auth); };

log { source(s_src); filter(f_mail); destination(d_mail); };

log { source(s_src); filter(f_debug); destination(d_debug); };


...the f_debug includes debug level and excludes facilities auth,
authpriv, news and mail, which is good for d_debug destination, BUT,
because of excluding those facilities, the "not filter(f_debug)" does NOT 
exclude debug
priority for any of them:

mail.debug:
filter(f_debug) = false
not filter(f_debug) = true

Thus, debug priority is not excluded in d_auth and d_mail destinations,
while it was apparently intended to be filtered out.

we can test it by running:

# logger  -p mail.debug mail debug
# logger  -p auth.debug auth debug

# grep debug auth.log mail.log
auth.log:Jul 15 16:22:51 mail root[29022]: auth debug
mail.log:Jul 15 16:07:25 mail root[26770]: mail debug


I believe that it can be fixed by either:

a) removing "not filter(f_debug);" from f_auth, f_mail and f_news definitions

b) using "not filter(f_dbg)" instead of "not filter(f_debug)" in log
  definitions

c) moving "not facility(auth, authpriv, news, mail)" to definicion of f_dbg
 and using f_dbg for d_debug


with variant a) the functionality would stay the same but less misleading

I personally would prefer variant c) as I find it cleanest and easiest to
understand and debug.


--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Linux is like a teepee: no Windows, no Gates and an apache inside...

Bug#991140: memory leak in krb5_gss_inquire_cred()

[Sergio Gelato]

Package: libgssapi-krb5-2
Version: 1.17-3+deb10u1
Severity: normal
Tags: patch upstream

I have recently stumbled upon a resource leak in this library. Here is my
one-line patch for it. As far as I can tell the problem was introduced ten
years ago and is still present in the latest upstream version. I have tested
this patch and it does seem to plug the leak I found.
Author: Sergio Gelato 
Date: Wed Jul 14 20:21:29 UTC 2021
Subject: Plug leak in krb5_gss_inquire_cred

Commit 1cd2821c19b2b95e39d5fc2f451a035585a40fa5 added an assignment to
cred_handle but didn't update the cleanup code accordingly. This results
in a leak on every call with GSS_C_NO_CREDENTIAL.

We solve this by analogy with the changes to krb5_gss_init_sec_context_ext()
and to the error cleanup block of krb5_gss_inquire_cred() by the same commit.
Index: krb5-1.17/src/lib/gssapi/krb5/inq_cred.c
===
--- krb5-1.17.orig/src/lib/gssapi/krb5/inq_cred.c	2019-01-08 17:02:37.0 +0100
+++ krb5-1.17/src/lib/gssapi/krb5/inq_cred.c	2021-07-14 22:19:40.022773499 +0200
@@ -197,8 +197,7 @@
 mechs = GSS_C_NO_OID_SET;
 }
 
-if (cred_handle == GSS_C_NO_CREDENTIAL)
-krb5_gss_release_cred(minor_status, (gss_cred_id_t *));
+krb5_gss_release_cred(minor_status, );
 
 krb5_free_context(context);
 *minor_status = 0;

Bug#991141: debian-cd: arm64 device trees not included in ESP

[Michael Walle]

Package: debian-cd
Severity: normal

It is useful to have the device trees available on the ESP. If we have these,
(vanilla) u-boot should be able to boot any board which has a dtb in the kernel
out-of-the box using EFI.

The (arm64) mini.iso already includes the DTBs in /dtb (which is the path
u-boot searches for).

Unfortunatly, these files are missing from ESP in the debian netinst.iso.
Please include them there, too.



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

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

Versions of packages debian-cd depends on:
ii  apt1.8.2.3
ii  bc 1.07.1-2+b1
ii  bzip2  1.0.6-9.2~deb10u1
ii  cpp4:8.3.0-1
ii  curl   7.64.0-4+deb10u2
ii  dpkg-dev   1.19.7
ii  genisoimage9:1.1.11-3+b2
pn  grep-dctrl 
pn  libcompress-zlib-perl  
pn  libdigest-md5-perl 
ii  libdpkg-perl   1.19.7
pn  lynx   
ii  make   4.2.1-1.2
ii  perl [libdigest-sha-perl]  5.28.1-6+deb10u1
pn  tofrodos   
ii  wget   1.20.1-1.1

Versions of packages debian-cd recommends:
ii  dosfstools   4.1-2
pn  hfsutils 
pn  isolinux 
pn  mtools   
ii  netpbm   2:10.0-15.3+b2
pn  syslinux-common  
pn  syslinux-utils   

debian-cd suggests no packages.

Bug#966059: ffmpeg: Please enable zscale filter

[r087r70]

I also would like to use zscale which does not require manual passing of 
colorspace options such as
|-pix_fmt|, |-color_range|, |-colorspace|, |-color_primaries|, and 
|-color_trc|


Default scaling does not account for the above flags, producing in some 
cases washed out colors, see e.g.:

https://video.stackexchange.com/questions/28889/ffmpeg-does-not-preserve-colors-after-resizing/
https://video.stackexchange.com/questions/32383/ffmpeg-vf-scale-shifts-colors-to-washed-out

Presently libzimg2 is packaged in debian repositories, so it can be linked.

Bug#990580: apache2: [regression] daily cron mails from logrotate: Reloading Apache httpd web server: apache2.

[Daniel Lewart]

Debian Apache Maintainers,

DSL> Which init system are you using?

The answer was in TG's original bug report:
Init: sysvinit (via /sbin/init)

I believe that this regression only occurs for non-systemd init systems
(i.e. sysvinit).

Popcon says sysvinit-core is installed on 0.88% of reporting systems:
https://qa.debian.org/popcon.php?package=sysvinit
Some of those may be pre-Jessie, so the percentage could be even lower.

On Tue, 6 Jul 2021 13:56:21 +0200, Adam Borowski wrote:

> + if pgrep -f ^/usr/sbin/apache2 > /dev/null; then
> +invoke-rc.d apache2 reload
> + fi
> ...
> Changing querying status to pgrep is also bogus: it will detect any apache2
> process rather than just ours. ...

How could there be a /usr/sbin/apache2 process that is not ours?

Any suggestions for improving this (after bullseye release, of course)?

Thank you,
Dan
Urbana, Illinois

Bug#990676: dlib: diff for NMU version 19.10-3.1

[Adrian Bunk]

Control: tags 990676 + pending

Dear maintainer,

I've prepared an NMU for dlib (versioned as 19.10-3.1) and uploaded
it to DELAYED/1. Please feel free to tell me if I should cancel it.

cu
Adrian
diff -Nru dlib-19.10/debian/changelog dlib-19.10/debian/changelog
--- dlib-19.10/debian/changelog	2019-01-17 09:17:25.0 +0200
+++ dlib-19.10/debian/changelog	2021-07-15 17:19:19.0 +0300
@@ -1,3 +1,11 @@
+dlib (19.10-3.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Backport upstream fix for using cv_image.h with OpenCV 4,
+thanks to Alexandr Podgorniy. (Closes: #990676)
+
+ -- Adrian Bunk   Thu, 15 Jul 2021 17:19:19 +0300
+
 dlib (19.10-3) unstable; urgency=medium
 
   * Team upload.
diff -Nru dlib-19.10/debian/patches/0001-Fix-opencv-version-check-to-work-on-all-opencv-versi.patch dlib-19.10/debian/patches/0001-Fix-opencv-version-check-to-work-on-all-opencv-versi.patch
--- dlib-19.10/debian/patches/0001-Fix-opencv-version-check-to-work-on-all-opencv-versi.patch	1970-01-01 02:00:00.0 +0200
+++ dlib-19.10/debian/patches/0001-Fix-opencv-version-check-to-work-on-all-opencv-versi.patch	2021-07-15 17:02:19.0 +0300
@@ -0,0 +1,33 @@
+From eea91537ac73498153266984da28c202965b75de Mon Sep 17 00:00:00 2001
+From: Davis King 
+Date: Sun, 22 Dec 2019 07:52:08 -0500
+Subject: Fix opencv version check to work on all opencv versions
+
+---
+ dlib/opencv/cv_image.h | 9 +
+ 1 file changed, 9 insertions(+)
+
+diff --git a/dlib/opencv/cv_image.h b/dlib/opencv/cv_image.h
+index 5f224d00..05af0551 100644
+--- a/dlib/opencv/cv_image.h
 b/dlib/opencv/cv_image.h
+@@ -34,7 +34,16 @@ namespace dlib
+  << "\n\t img.channels(): " << img.channels() 
+  << "\n\t img.pixel_traits::num: " << pixel_traits::num 
+  );
++// Note, do NOT use CV_VERSION_MAJOR because in OpenCV 2 CV_VERSION_MAJOR actually held
++// CV_VERSION_MINOR and instead they used CV_VERSION_EPOCH.  So for example, in OpenCV
++// 2.4.9.1 CV_VERSION_MAJOR==4 and CV_VERSION_EPOCH==2.  However, CV_MAJOR_VERSION has always
++// (seemingly) held the actual major version number, so we use that to test for the OpenCV major
++// version.
++#if CV_MAJOR_VERSION > 3
++IplImage temp = cvIplImage(img);
++#else
+ IplImage temp = img;
++#endif
+ init();
+ }
+ 
+-- 
+2.20.1
+
diff -Nru dlib-19.10/debian/patches/series dlib-19.10/debian/patches/series
--- dlib-19.10/debian/patches/series	2019-01-17 08:43:25.0 +0200
+++ dlib-19.10/debian/patches/series	2021-07-15 17:19:17.0 +0300
@@ -1 +1,2 @@
 fix-soname.patch
+0001-Fix-opencv-version-check-to-work-on-all-opencv-versi.patch

Bug#991129: systemd: FIDO2 tokens not supported on this build.

[Guy Rutenberg]

> src:systemd is built without libfido support, so what you see is expected.

I guessed someone made a decision to build it without libfido support.
I mainly wonder why, as it breaks some new functionality (like
enrolling FIDO keys to unlock LUKS drives at startup).

Thanks,
Guy

Bug#990807: thunderbird incapable to run only with ~/.thunderbird that was migrated from icedove

[Carsten Schoenert]

Hello Tomas,

Am 12.07.21 um 11:07 schrieb Tomas Pospisek:

> If I'd like to get rid of ~/.icedove and only have a standard 
> ~/.thunderbird directory - which I am assuming is possible - then what 
> would the correct way to do that be?

the main mess is you will need to go to your profile and replace all
occurrences of ".icdeove" with ".thunderbird" within the files. Doing
this for .js|.json|.xml and so on files will be mostly easy, but it's
possible that there is also something in the encrypted files and also in
the .sqlite files.

It's all doable, and I wanted to start something that is doing that
trick, but it's in the end a more cleaner way to export the profile and
later re import it again. But exporting a profile by TB directly isn't
still full featured.

As long as nobody is digging into this we will need to live with the
symlinked folder.

-- 
Regards
Carsten

Bug#976808: Solved in qemu 6.0

[Christian Ehrhardt]

Tags: fixed-in-experimental

Hi,
this was fixed by [1] which is available in experimental
qemu   | 1:6.0+dfsg-1~exp0| experimental   | source,
amd64, arm64, armel, armhf, i386, mips64el, mipsel, ppc64el, s390x

It is thereby fixed, although to fully be available you'll need to
wait for a backport or the next Debian release.

[1]: https://git.qemu.org/?p=qemu.git;a=commit;h=8eb13bbbac08aa077e

-- 
Christian Ehrhardt
Staff Engineer, Ubuntu Server
Canonical Ltd

Bug#991139: sgt-puzzles: status bar missing in Debian build

[alex]

Package: sgt-puzzles
Version: 20170606.272beef-1
Severity: normal

Dear Ben Hutchings,

I enjoyed playing Simon Tatham's puzzles when I still was running Windows as my 
daily driver but since then I transitioned to Debian/LMDE.
What I noticed right away but until now never really cared for is that the 
Windows build features a status bar at the bottom (and ports like the Android 
port have this bar, too, somewhat), but the Debian package does not.
This status bar shows information like (where applicable) the elapsed time or 
counters of some sort.
For example for the game Mines it shows the elapsed time, the number of mines 
left to be marked, and the number of deaths. For Net it shows the number of 
connected cells.
Now, while this information isn't necessary to solve most of the games included 
in the puzzle collection, they still help a lot when it comes to convenience.
It's rather inconvenient to count the number of marked mines in a game with 170 
mines in order to make informed decisions about cells that you haven't 
uncovered nor flagged yet.
Futhermore, I will never know how often I died/misclicked or how long one level 
took unless I use external tools like a stopwatch.
Other games like Flip (now that I think about it, Mines is in this category, 
too, just like many more) not only don't show the number of moves made but have 
absolutely no lasting visual feedback whether the puzzle was solved.
The moment you solve a Flip puzzle, all the tiles show this "flash animation" 
but if you blinked in this exact moment or looked away, you will never be able 
to tell that the game is/was solved.
The short animation is the only feedback you get. The status bar would read 
"SOLVED!" which would stay there even if you continued playing an already 
solved level.
And as far as I can tell, this is a general problem with all the puzzle games 
in this collection. I haven't seen a single game WITH a status bar of some 
sorts but I also haven't checked them all.

I've looked for a menu/config option to enable but there was none. Hence, I 
assume that there just plain isn't a status bar in the Debian build.
But given that several other builds have a (identical in terms of content) 
status bar, the information will probably be available in some form.
It just isn't shown, which is sad. Because the puzzles are a really nice waste 
of time (in a completely positive way). ;)

Might this problem be caused by different graphical frameworks (Qt vs Gtk) and 
problems in their interoperability?
I know that dark system-level menu themes can look really ugly if the DE and 
specific applications don't use the same technology (black text on dark grey 
background).
If so, is there a package that one can install to improve/fix this situation?

I would love to be able to enjoy the puzzles in all their glory. As I said, 
they are really nice, (almost) all feature unique and logically derivable 
solutions (in contrast to the Windows Minesweeper for example).
But the missing status bar really is a bummer, given that I used to play them 
with such a status bar.

Thanks in advance.
Alex

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

Kernel: Linux 5.12.0-17.1-liquorix-amd64 (SMP w/12 CPU cores; PREEMPT)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages sgt-puzzles depends on:
ii  libatk1.0-0  2.30.0-2
ii  libc62.28-10
ii  libcairo-gobject21.16.0-4+deb10u1
ii  libcairo21.16.0-4+deb10u1
ii  libgdk-pixbuf2.0-0   2.38.1+dfsg-1
ii  libglib2.0-0 2.58.3-2+deb10u3
ii  libgtk-3-0   3.24.5-1
ii  libpango-1.0-0   1.42.4-8~deb10u1
ii  libpangocairo-1.0-0  1.42.4-8~deb10u1

Versions of packages sgt-puzzles recommends:
ii  falkon [www-browser]3.0.0-3
ii  firefox [www-browser]   78.12.0esr~linuxmint1+debbie
ii  palemoon [www-browser]  28.17.0-1
ii  yelp3.31.90-1

sgt-puzzles suggests no packages.

-- no debconf information

Bug#975441: x264: diff for NMU version 2:0.160.3011+gitcde9a93-2.1

[Adrian Bunk]

Control: tags 975441 + pending

Dear maintainer,

I've prepared an NMU for x264 (versioned as 2:0.160.3011+gitcde9a93-2.1) 
and uploaded it to DELAYED/1. Please feel free to tell me if I should 
cancel it.

This fixes a regression from buster by restoring MP4 output in the x264 
binary, the library is unchanged.

cu
Adrian
diff -Nru x264-0.160.3011+gitcde9a93/debian/changelog x264-0.160.3011+gitcde9a93/debian/changelog
--- x264-0.160.3011+gitcde9a93/debian/changelog	2020-07-26 17:52:56.0 +0300
+++ x264-0.160.3011+gitcde9a93/debian/changelog	2021-07-15 15:06:22.0 +0300
@@ -1,3 +1,10 @@
+x264 (2:0.160.3011+gitcde9a93-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Backport upstream fix to support GPAC >= 0.8.0. (Closes: #975441)
+
+ -- Adrian Bunk   Thu, 15 Jul 2021 15:06:22 +0300
+
 x264 (2:0.160.3011+gitcde9a93-2) unstable; urgency=medium
 
   * Team upload
diff -Nru x264-0.160.3011+gitcde9a93/debian/patches/0001-mp4-Update-GPAC-support-to-v0.8.0-or-later.patch x264-0.160.3011+gitcde9a93/debian/patches/0001-mp4-Update-GPAC-support-to-v0.8.0-or-later.patch
--- x264-0.160.3011+gitcde9a93/debian/patches/0001-mp4-Update-GPAC-support-to-v0.8.0-or-later.patch	1970-01-01 02:00:00.0 +0200
+++ x264-0.160.3011+gitcde9a93/debian/patches/0001-mp4-Update-GPAC-support-to-v0.8.0-or-later.patch	2021-07-15 15:06:22.0 +0300
@@ -0,0 +1,58 @@
+From 7c2004b58c26da661618262c9c06b73ad3a9ff6c Mon Sep 17 00:00:00 2001
+From: "A. David" 
+Date: Thu, 2 Jul 2020 19:45:50 +0200
+Subject: mp4: Update GPAC support to v0.8.0 or later
+
+---
+ configure| 5 +++--
+ output/mp4.c | 6 +-
+ 2 files changed, 8 insertions(+), 3 deletions(-)
+
+Index: x264-0.160.3011+gitcde9a93/configure
+===
+--- x264-0.160.3011+gitcde9a93.orig/configure
 x264-0.160.3011+gitcde9a93/configure
+@@ -1240,15 +1240,16 @@ if [ "$gpac" = "auto" -a "$lsmash" != "y
+ gpac="no"
+ GPAC_LIBS="-lgpac"
+ cc_check "" -lz && GPAC_LIBS="$GPAC_LIBS -lz"
++cc_check "" -ldl && GPAC_LIBS="$GPAC_LIBS -ldl"
+ if [ "$SYS" = "WINDOWS" ] ; then
+ cc_check "" -lws2_32 && GPAC_LIBS="$GPAC_LIBS -lws2_32"
+ cc_check "" -lwinmm && GPAC_LIBS="$GPAC_LIBS -lwinmm"
+ fi
+ if cc_check gpac/isomedia.h "$GPAC_LIBS" "gf_isom_close(0);" ; then
+-if cc_check gpac/isomedia.h "$GPAC_LIBS" "gf_isom_set_pixel_aspect_ratio(0,0,0,0,0);" ; then
++if cc_check gpac/isomedia.h "$GPAC_LIBS" "gf_isom_set_pixel_aspect_ratio(0,0,0,0,0,0);" ; then
+ gpac="yes"
+ else
+-echo "Warning: gpac is too old, update to 2007-06-21 UTC or later"
++echo "Warning: gpac is too old, update to v0.8.0 or later"
+ fi
+ fi
+ fi
+Index: x264-0.160.3011+gitcde9a93/output/mp4.c
+===
+--- x264-0.160.3011+gitcde9a93.orig/output/mp4.c
 x264-0.160.3011+gitcde9a93/output/mp4.c
+@@ -147,7 +147,11 @@ static int close_file( hnd_t handle, int
+ {
+ uint32_t mvhd_timescale = gf_isom_get_timescale( p_mp4->p_file );
+ uint64_t tkhd_duration = (uint64_t)( mdhd_duration * ( (double)mvhd_timescale / p_mp4->i_time_res ) );
++#if GPAC_VERSION_MAJOR > 8
++gf_isom_append_edit( p_mp4->p_file, p_mp4->i_track, tkhd_duration, sample->CTS_Offset, GF_ISOM_EDIT_NORMAL );
++#else
+ gf_isom_append_edit_segment( p_mp4->p_file, p_mp4->i_track, tkhd_duration, sample->CTS_Offset, GF_ISOM_EDIT_NORMAL );
++#endif
+ }
+ gf_isom_sample_del(  );
+ 
+@@ -233,7 +237,7 @@ static int set_param( hnd_t handle, x264
+ dw *= sar;
+ else
+ dh /= sar;
+-gf_isom_set_pixel_aspect_ratio( p_mp4->p_file, p_mp4->i_track, p_mp4->i_descidx, p_param->vui.i_sar_width, p_param->vui.i_sar_height );
++gf_isom_set_pixel_aspect_ratio( p_mp4->p_file, p_mp4->i_track, p_mp4->i_descidx, p_param->vui.i_sar_width, p_param->vui.i_sar_height, 0 );
+ gf_isom_set_track_layout_info( p_mp4->p_file, p_mp4->i_track, dw, dh, 0, 0, 0 );
+ }
+ 
diff -Nru x264-0.160.3011+gitcde9a93/debian/patches/series x264-0.160.3011+gitcde9a93/debian/patches/series
--- x264-0.160.3011+gitcde9a93/debian/patches/series	2020-06-21 12:40:55.0 +0300
+++ x264-0.160.3011+gitcde9a93/debian/patches/series	2021-07-15 15:06:22.0 +0300
@@ -1,2 +1,3 @@
 link_gpac_dynamically.patch
 properly_detect_x32.patch
+0001-mp4-Update-GPAC-support-to-v0.8.0-or-later.patch

Bug#991138: unblock: davmail/5.5.1.3299-5

[Alexandre Rossi]

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

Please unblock package davmail.

The updated version fixes RC bug #987601.
It also fixes the init.d script (when systemd is not used).
It also cleanups a Suggests: of a package no longer in the archive.

This is a leaf package with no rdeps.
Changes are in the Suggests: and in the init.d script when systemd is not
in use: risks of regressions are very low.

unblock davmail/5.5.1.3299-5

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

Kernel: Linux 4.19.0-16-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8), 
LANGUAGE=fr_FR.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru davmail-5.5.1.3299/debian/changelog 
davmail-5.5.1.3299/debian/changelog
--- davmail-5.5.1.3299/debian/changelog 2020-10-13 11:09:08.0 +0200
+++ davmail-5.5.1.3299/debian/changelog 2021-07-07 14:39:48.0 +0200
@@ -1,3 +1,14 @@
+davmail (5.5.1.3299-5) unstable; urgency=medium
+
+  [ Alexandre Rossi ]
+  * drop Suggests of libswt-gtk2-4-jni which is gone from the archive
+  * add default-jre as a Suggests (Closes: #987601)
+
+  [ Meeuwissen Olaf ]
+  * fix conf ignored when starting via init.d script (Closes: #989817)
+
+ -- Alexandre Rossi   Wed, 07 Jul 2021 14:39:48 
+0200
+
 davmail (5.5.1.3299-4) unstable; urgency=medium
 
   * fix service start when not using keystoreFile (Closes: #972136)
diff -Nru davmail-5.5.1.3299/debian/control davmail-5.5.1.3299/debian/control
--- davmail-5.5.1.3299/debian/control   2020-05-03 16:54:47.0 +0200
+++ davmail-5.5.1.3299/debian/control   2021-07-07 14:29:00.0 +0200
@@ -39,7 +39,7 @@
  ${shlibs:Depends},
  ${misc:Depends},
  ${java:Depends}
-Suggests: libswt-gtk2-4-jni,
+Suggests: default-jre,
   libswt-cairo-gtk-4-jni,
   libopenjfx-java,
 Description: POP/IMAP/SMTP/CalDav/LDAP to Microsoft Exchange gateway
diff -Nru davmail-5.5.1.3299/debian/init davmail-5.5.1.3299/debian/init
--- davmail-5.5.1.3299/debian/init  2018-12-27 17:54:26.0 +0100
+++ davmail-5.5.1.3299/debian/init  2021-07-07 14:39:39.0 +0200
@@ -19,23 +19,23 @@
 DESC="Davmail Exchange gateway"
 NAME=davmail
 DAEMON=/usr/bin/$NAME
-DAEMON_USER=$NAME
+DAEMON_USER=_$NAME
 HOME=/var/lib/$DAEMON_USER
 PIDFILE=/var/run/$NAME.pid
-LOGFILE=/var/log/$NAME.log
+LOGFILE=/var/log/$NAME/$NAME.log
 SCRIPTNAME=/etc/init.d/$NAME
 
 
 # Exit if the package is not installed
 [ -x "$DAEMON" ] || exit 0
 
-DAEMON_ARGS="/etc/davmail.properties"
+DAEMON_ARGS="-server /etc/davmail/davmail.properties"
 
 # Create logfiles if they do not exist
 if [ ! -r "$LOGFILE" ]
 then
 touch $LOGFILE
-chown $NAME:adm $LOGFILE
+chown $DAEMON_USER:adm $LOGFILE
 fi
 
 # Load the VERBOSE setting and other rcS variables

Bug#991137: ITP: slurm-tools -- tools for the slurm HPC workload manager

[Gürkan Myczko]

Package: wnpp
Severity: wishlist
Owner: Gürkan Myczko 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: slurm-tools
  Version : 0+git20210715
  Upstream Authors: Ole Holm Nielsen
* URL : https://github.com/OleHolmNielsen/Slurm_tools
* License : GPL-3-or-later
  Description : tools for the slurm HPC workload manager
 This is a collection of these tools:
  - pestat Print Slurm nodes status with 1 line per node including job 
info.

  - more tools to manage accounting, user jobs and more.

Bug#804018: options to avoid service startup on package installation

[Moritz Mühlenhoff]

Am Fri, Jul 27, 2018 at 04:13:52PM +0800 schrieb Sean Whitton:
> AFAICT the work to be done here is to expand a spec which already lives
> in init-system-helpers, and improve some tooling which will live in
> init-system-helpers.  So this bug should be reassigned to
> init-system-helpers.
> 
> Thanks Ian for unsticking this bug.

JFTR, this feature already exists natively in systemd in combination
with init-system-helpers. It's working fine in Bullseye, but doesn't in
Buster (not sure if there was an explicit bug fix which made it work):

Adding a /etc/systemd/system-preset/apache2.preset file with the content
"disable apache2.service" will correctly prevent the service from starting
upon installation. This works both for services with a native systemd unit
(like apache2), but also for services which ship a sysvinit script which
gets auto-translated to a systemd unit (e.g. nginx).

Cheers,
 Moritz

Bug#991136: fetch-crl: Install fails on update-rc.d

[Carl-Fredrik Enell]

Package: fetch-crl
Version: 3.0.19-2
Severity: important

Dear Maintainer,


   * I tried to uninstall and reinstall fetch-crl because of error
   * messages regarding a non-existing certificate.

   * Packet configuration fails on update-rc.d: No default runlevel.
   This is expected on a systemd based release as far as I can
   understand.
   init-system-helpers is installed.

   * I would expect fetch-crl to run from cron or a systemd timer, not
   * to install anything in rcN.d.

Best regards,
Carl-Fredrik Enell


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

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

Versions of packages fetch-crl depends on:
ii  init-system-helpers  1.56+nmu1
ii  libwww-perl  6.36-2
ii  lsb-base 10.2019051400
ii  openssl  1.1.1d-0+deb10u6
ii  perl 5.28.1-6+deb10u1

fetch-crl recommends no packages.

fetch-crl suggests no packages.

-- no debconf information

Bug#991134: firefox: connection failures when opening links in a new tab

[Vincent Lefevre]

On 2021-07-15 12:56:24 +0200, Vincent Lefevre wrote:
> This has just happened when doing "Back": the HTML page
> https://www.vinc17.net/ was displayed, but without the CSS, which
> should have been in the cache (as being loaded a few minutes earlier).
> After doing a reload, I got a connection error (still immediate).

I'm wondering whether they are separate issues.

Concerning the "Back" issue, here are logs from my web server for the
HTML page (/) and the CSS (/screen.css):

86.75.119.128 - - [15/Jul/2021:12:27:02 +0200] "GET / HTTP/1.1" 304 269 
"http://localhost/; "Mozilla/5.0 (X11; Linux x86_64; rv:88.0) Gecko/20100101 
Firefox/88.0"

86.75.119.128 - - [15/Jul/2021:12:38:34 +0200] "GET /screen.css HTTP/1.1" 200 
1050 "https://www.vinc17.net/cv.en.html; "Mozilla/5.0 (X11; Linux x86_64; 
rv:88.0) Gecko/20100101 Firefox/88.0"

These were the latest occurrences for these two files before I clicked
on the "Back" arrow. I don't know whether Firefox attempted to download
/screen.css and failed; this CSS file just wasn't used after the "Back"
(while it was used when the page was initially loaded, probably at
12:27).

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

Bug#978544: python-dbussy: diff for NMU version 1.3-1.1

[Adrian Bunk]

Control: tags 978544 + pending

Dear maintainer,

I've prepared an NMU for python-dbussy (versioned as 1.3-1.1) and 
uploaded it to DELAYED/1. Please feel free to tell me if I should
cancel it.

cu
Adrian
diff -Nru python-dbussy-1.3/debian/changelog python-dbussy-1.3/debian/changelog
--- python-dbussy-1.3/debian/changelog	2020-12-19 23:53:12.0 +0200
+++ python-dbussy-1.3/debian/changelog	2021-07-15 14:20:57.0 +0300
@@ -1,3 +1,11 @@
+python-dbussy (1.3-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Backport upstream fix to ensure that Type objects always have
+a code field. (Closes: #978544)
+
+ -- Adrian Bunk   Thu, 15 Jul 2021 14:20:57 +0300
+
 python-dbussy (1.3-1) unstable; urgency=medium
 
   * New upstream version.
diff -Nru python-dbussy-1.3/debian/patches/0001-Ensure-that-Type-objects-always-have-a-code-field.patch python-dbussy-1.3/debian/patches/0001-Ensure-that-Type-objects-always-have-a-code-field.patch
--- python-dbussy-1.3/debian/patches/0001-Ensure-that-Type-objects-always-have-a-code-field.patch	1970-01-01 02:00:00.0 +0200
+++ python-dbussy-1.3/debian/patches/0001-Ensure-that-Type-objects-always-have-a-code-field.patch	2021-07-15 14:19:38.0 +0300
@@ -0,0 +1,75 @@
+From e131d819ea832bec7cfc9e27e27af9c71f701a5a Mon Sep 17 00:00:00 2001
+From: Lawrence D'Oliveiro 
+Date: Thu, 28 May 2020 00:18:05 +
+Subject: Ensure that Type objects always have a code field.
+
+---
+ dbussy.py | 19 +--
+ 1 file changed, 17 insertions(+), 2 deletions(-)
+
+diff --git a/dbussy.py b/dbussy.py
+index 0576695..4c8dc04 100644
+--- a/dbussy.py
 b/dbussy.py
+@@ -637,6 +637,15 @@ class Type :
+ "base class for all Types. The “signature” property returns the fully-encoded" \
+ " signature string for the entire Type."
+ 
++__slots__ = ("code",)
++
++def __init__(self, code) :
++if not isinstance(code, TYPE) :
++raise TypeError("only TYPE.xxx values allowed")
++#end if
++self.code = code
++#end __init__
++
+ @property
+ def signature(self) :
+ raise NotImplementedError("subclass forgot to override signature property")
+@@ -662,13 +671,13 @@ class Type :
+ class BasicType(Type) :
+ "a basic (non-container) type."
+ 
+-__slots__ = ("code",)
++__slots__ = ()
+ 
+ def __init__(self, code) :
+ if not isinstance(code, TYPE) or not code.is_basic :
+ raise TypeError("only basic TYPE.xxx values allowed")
+ #end if
+-self.code = code
++super().__init__(code)
+ #end __init__
+ 
+ def __repr__(self) :
+@@ -712,6 +721,10 @@ class BasicType(Type) :
+ class VariantType(Type) :
+ "the variant type--a single element of a type determined at run-time."
+ 
++def __init__(self) :
++super().__init__(TYPE.VARIANT)
++#end __init__
++
+ @property
+ def signature(self) :
+ return \
+@@ -752,6 +765,7 @@ class StructType(Type) :
+ if not all(isinstance(t, Type) for t in types) :
+ raise TypeError("struct elements must be Types")
+ #end if
++super().__init__(TYPE.STRUCT)
+ self.elttypes = tuple(types)
+ #end __init__
+ 
+@@ -799,6 +813,7 @@ class ArrayType(Type) :
+ if not isinstance(elttype, Type) :
+ raise TypeError("invalid array element type")
+ #end if
++super().__init__(TYPE.ARRAY)
+ self.elttype = elttype
+ #end __init__
+ 
+-- 
+2.20.1
+
diff -Nru python-dbussy-1.3/debian/patches/series python-dbussy-1.3/debian/patches/series
--- python-dbussy-1.3/debian/patches/series	1970-01-01 02:00:00.0 +0200
+++ python-dbussy-1.3/debian/patches/series	2021-07-15 14:20:52.0 +0300
@@ -0,0 +1 @@
+0001-Ensure-that-Type-objects-always-have-a-code-field.patch

Bug#991135: WiFi start is delayed by 5 minutes and networking-routes.service/start deleted to break ordering cycle

[Michael Biebl]

Control: reassign -1 ifupdown-extra

Am 15.07.21 um 12:46 schrieb Peter Mueller:

Package: systemd
Version: 247.3-5

Reproduce:
1) Boot the computer.
2) Have no WiFi approximately 5 minutes long.
3) Have WiFi after 5 minutes.

It doesn't matter whether WiFi is tested from gnome or from tty.  My 
network is configured via interfaces (not via NetworkManager).
I have a PCE-AX3000 card and use an up-to-date Debian 11 “Bullseye” with 
firmware-iwlwifi. The bugs has existed since the fresh installation in 
January 2021 with all the current kernels so far.


$ cat /etc/network/interfaces
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).
source /etc/network/interfaces.d/*
# The loopback network interface
auto lo
iface lo inet loopback
## The primary network interface
allow-hotplug wlp179s0
iface wlp179s0 inet dhcp
## This is an autoconfigured IPv6 interface
iface wlp179s0 inet6 auto
wpa-ssid o2-WLAN00
wpa-psk AnonymizedPassword
## detect wired interfaces when they become available
allow-hotplug enp6s0 enp7s0
# raise the wireless interface as primary
auto wlp179s0
$ sudo journalctl -b | grep -B 4 "ordering cycle"
Jul 15 11:39:39 DtPC systemd[1]: systemd 247.3-5 running in system mode. 
(+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP 
+LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +ZSTD +SECCOMP +BLKID 
+ELFUTILS +KMOD +IDN2 -IDN +PCRE2 default-hierarchy=unified)

Jul 15 11:39:39 DtPC systemd[1]: Detected architecture x86-64.
Jul 15 11:39:39 DtPC systemd[1]: Set hostname to .
Jul 15 11:39:39 DtPC kernel: usb 1-11.4.3: new high-speed USB device 
number 9 using xhci_hcd
Jul 15 11:39:39 DtPC systemd[1]: network.target: Found ordering cycle on 
networking-routes.service/start
Jul 15 11:39:39 DtPC systemd[1]: network.target: Found dependency on 
network.target/start
Jul 15 11:39:39 DtPC systemd[1]: network.target: Job 
networking-routes.service/start deleted to break ordering cycle starting 
with network.target/start

$ cat /etc/network/interfaces.d/*
auto lo
iface lo inet loopback
# auto eth0
# iface eth0 inet dhcp

How to debug this further? (I don't wish to clutter this bug report with 
tons of potentially unrelated logs; please advise.)


I don't see a bug in systemd here. What I see are two (maybe related) issues

a/ networking-routes.service (from ifupdown-extra) causing a dependency 
loop (=> looks like a bug in ifupdown-extra to me)
b/ an issue with your network configuration (which is managed by 
ifupdown). If b/ is caused by a/, I dunno.


Let's reassign this to ifupdown-extra. Its maintainer will be in a 
better position to advise you with any ifupdown related issues.


Regards,
Michael



OpenPGP_signature
Description: OpenPGP digital signature

Bug#991129: systemd: FIDO2 tokens not supported on this build.

[Michael Biebl]

Am 15.07.21 um 07:35 schrieb Guy Rutenberg:

Package: systemd
Version: 249-1
Severity: normal
X-Debbugs-Cc: guyrutenb...@gmail.com

Dear Maintainer,

I'm trying to test out the new FIDO2 support for LUKS via systemd-cryptenroll.
However, when trying to use the --fido2-device switch, for example in the
following command
```
systemd-cryptenroll --fido2-device list
```
The command fails and reports

```
FIDO2 tokens not supported on this build.
```

Additional information:
I have the `libfido2-1` package installed. I don't know if that should be
required or not.


src:systemd is built without libfido support, so what you see is expected.




OpenPGP_signature
Description: OpenPGP digital signature

Bug#966059: ffmpeg: Please enable zscale filter

[Sebastian Ramacher]

On 2021-07-15 12:48:53, guerra...@alice.it wrote:
> I also would like to use zscale which does not require manual passing of
> colorspace options such as
> |-pix_fmt|, |-color_range|, |-colorspace|, |-color_primaries|, and
> |-color_trc|
> 
> Default scaling does not account for the above flags, producing in some
> cases washed out colors, see e.g.:
> https://video.stackexchange.com/questions/28889/ffmpeg-does-not-preserve-colors-after-resizing/
> https://video.stackexchange.com/questions/32383/ffmpeg-vf-scale-shifts-colors-to-washed-out
> 
> Presently libzimg2 is packaged in debian repositories, so it can be linked.

The ffmpeg version currently available in experimental has zimg enabled.

Cheers
-- 
Sebastian Ramacher

Bug#991134: firefox: connection failures when opening links in a new tab

[Vincent Lefevre]

Control: retitle -1 random connection failures

This has just happened when doing "Back": the HTML page
https://www.vinc17.net/ was displayed, but without the CSS, which
should have been in the cache (as being loaded a few minutes earlier).
After doing a reload, I got a connection error (still immediate).
A second reload worked.

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

Bug#966059: ffmpeg: Please enable zscale filter

[guerrarob]

I also would like to use zscale which does not require manual passing of 
colorspace options such as
|-pix_fmt|, |-color_range|, |-colorspace|, |-color_primaries|, and 
|-color_trc|


Default scaling does not account for the above flags, producing in some 
cases washed out colors, see e.g.:

https://video.stackexchange.com/questions/28889/ffmpeg-does-not-preserve-colors-after-resizing/
https://video.stackexchange.com/questions/32383/ffmpeg-vf-scale-shifts-colors-to-washed-out

Presently libzimg2 is packaged in debian repositories, so it can be linked.

Bug#991135: WiFi start is delayed by 5 minutes and networking-routes.service/start deleted to break ordering cycle

[Peter Mueller]

Package: systemd
Version: 247.3-5
Reproduce:
1) Boot the computer.
2) Have no WiFi approximately 5 minutes long.
3) Have WiFi after 5 minutes.
It doesn't matter whether WiFi is tested from gnome or from tty.  My network is 
configured via interfaces (not via NetworkManager).
I have a PCE-AX3000 card and use an up-to-date Debian 11 “Bullseye” with 
firmware-iwlwifi. The bugs has existed since the fresh installation in January 
2021 with all the current kernels so far.
$ cat /etc/network/interfaces # This file describes the network interfaces 
available on your system # and how to activate them. For more information, see 
interfaces(5).
source /etc/network/interfaces.d/*
# The loopback network interface auto lo iface lo inet loopback
## The primary network interface allow-hotplug wlp179s0 iface wlp179s0 inet 
dhcp ## This is an autoconfigured IPv6 interface iface wlp179s0 inet6 auto 
wpa-ssid o2-WLAN00 wpa-psk AnonymizedPassword
## detect wired interfaces when they become available allow-hotplug enp6s0 
enp7s0
# raise the wireless interface as primary auto wlp179s0
$ sudo journalctl -b | grep -B 4 "ordering cycle" Jul 15 11:39:39 DtPC 
systemd[1]: systemd 247.3-5 running in system mode. (+PAM +AUDIT +SELINUX +IMA 
+APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 
+ZSTD +SECCOMP +BLKID +ELFUTILS +KMOD +IDN2 -IDN +PCRE2 
default-hierarchy=unified) Jul 15 11:39:39 DtPC systemd[1]: Detected 
architecture x86-64. Jul 15 11:39:39 DtPC systemd[1]: Set hostname to 
. Jul 15 11:39:39 DtPC kernel: usb 1-11.4.3: new high-speed 
USB device number 9 using xhci_hcd Jul 15 11:39:39 DtPC systemd[1]: 
network.target: Found ordering cycle on networking-routes.service/start Jul 15 
11:39:39 DtPC systemd[1]: network.target: Found dependency on 
network.target/start Jul 15 11:39:39 DtPC systemd[1]: network.target: Job 
networking-routes.service/start deleted to break ordering cycle starting with 
network.target/start
$ cat /etc/network/interfaces.d/* auto lo iface lo inet loopback
# auto eth0 # iface eth0 inet dhcp
How to debug this further? (I don't wish to clutter this bug report with tons 
of potentially unrelated logs; please advise.)

Bug#991130: Manpage: CASignatureAlgorithms mentions a wrong default

[Heiko Schlittermann (HS12-RIPE)]

Package: openssh-server
Version: 1:7.9p1-10+deb10u2
Severity: normal

Dear Maintainer,

on a current unreleased Debian bullseye (openssh-server 1:8.4p1-5)
the sshd_config(5) mentions the CASignatureAlgorithms 
with a wrong default: 

|CASignatureAlgorithms
|Specifies which algorithms are allowed for signing of certifi-
|cates by certificate authorities (CAs).  The default is:
|
|  ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,
|  ssh-ed25519,rsa-sha2-512,rsa-sha2-256,ssh-rsa
| 
|Certificates signed using other algorithms will not be accepted
|for public key or host-based authentication.


The ssh-rsa algorithm is not in the default set of algorithms, as it
seems (tested with the above server version, after setting the
CASignatureAlgorithms options to the (mistakenly documented default),
SSH certificates with RSA signatures worked again.

This should be clearly stated in this section.

Bug#990560: Error message "Value too large for defined data type"

[Bernhard]

Hello James

Attached there is the log.

Best regards
Bernhard


Am Donnerstag, dem 15.07.2021 um 00:17 -0400 schrieb James McCoy:
> On Tue, Jul 13, 2021 at 01:54:20PM +, Bernhard wrote:
> > Hello James
> > 
> > Thanks for working at this topic.
> > Attached, there is the Log file.
> 
> Guess that was too limiting.  Can you run again without "-e trace=file"?
> 
> > Interesting is:
> > At x86 (x86_64 and i386), there are no such problems.
> > This problem is only at armhf architecture.
> 
> Thanks for the clarification on the arch.  That is likely relevant.
> 
> Cheers,

execve("/usr/bin/svnadmin", ["svnadmin", "lstxns", "/storage/subversion/svn"], 0xbed9a780 /* 14 vars */) = 0
brk(NULL)   = 0x218e000
mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb6f6c000
access("/etc/ld.so.preload", R_OK)  = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=17600, ...}) = 0
mmap2(NULL, 17600, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb6f67000
close(3)= 0
openat(AT_FDCWD, "/lib/arm-linux-gnueabihf/libsvn_repos-1.so.1", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0\360\204\0\0004\0\0\0"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0644, st_size=169416, ...}) = 0
mmap2(NULL, 233500, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb6f0b000
mprotect(0xb6f34000, 61440, PROT_NONE)  = 0
mmap2(0xb6f43000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x28000) = 0xb6f43000
close(3)= 0
openat(AT_FDCWD, "/lib/arm-linux-gnueabihf/libsvn_fs-1.so.1", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0,6\0\0004\0\0\0"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0644, st_size=34308, ...}) = 0
mmap2(NULL, 98392, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb6ef2000
mprotect(0xb6efa000, 61440, PROT_NONE)  = 0
mmap2(0xb6f09000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x7000) = 0xb6f09000
close(3)= 0
openat(AT_FDCWD, "/lib/arm-linux-gnueabihf/libsvn_delta-1.so.1", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0hH\0\0004\0\0\0"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0644, st_size=75268, ...}) = 0
mmap2(NULL, 139340, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb6ecf000
mprotect(0xb6ee, 65536, PROT_NONE)  = 0
mmap2(0xb6ef, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x11000) = 0xb6ef
close(3)= 0
openat(AT_FDCWD, "/lib/arm-linux-gnueabihf/libsvn_subr-1.so.1", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0\200e\1\0004\0\0\0"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0644, st_size=387152, ...}) = 0
mmap2(NULL, 451284, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb6e6
mprotect(0xb6ebc000, 61440, PROT_NONE)  = 0
mmap2(0xb6ecb000, 16384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x5b000) = 0xb6ecb000
close(3)= 0
openat(AT_FDCWD, "/lib/arm-linux-gnueabihf/libapr-1.so.0", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0\320\251\0\0004\0\0\0"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0644, st_size=142532, ...}) = 0
mmap2(NULL, 206908, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb6e2d000
mprotect(0xb6e4f000, 61440, PROT_NONE)  = 0
mmap2(0xb6e5e000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x21000) = 0xb6e5e000
close(3)= 0
openat(AT_FDCWD, "/lib/arm-linux-gnueabihf/libpthread.so.0", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0\5[\0\0004\0\0\0"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=113596, ...}) = 0
mmap2(NULL, 152152, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb6e07000
mprotect(0xb6e1a000, 61440, PROT_NONE)  = 0
mmap2(0xb6e29000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x12000) = 0xb6e29000
mmap2(0xb6e2b000, 4696, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb6e2b000
close(3)= 0
openat(AT_FDCWD, "/lib/arm-linux-gnueabihf/libc.so.6", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
read(3, "\177ELF\1\1\1\3\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0Y\253\1\0004\0\0\0"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=973416, ...}) = 0
mmap2(NULL, 1042632, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb6d08000
mprotect(0xb6df2000, 61440, PROT_NONE)  = 0
mmap2(0xb6e01000, 16384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xe9000) = 0xb6e01000
mmap2(0xb6e05000, 6344, PROT_READ|PROT_WRITE, 

Bug#991134: firefox: connection failures when opening links in a new tab

[Vincent Lefevre]

Package: firefox
Version: 88.0.1-1
Severity: normal

When opening a link in a new tab, connections sometimes fail, either
for the HTML page, in which case Firefox displays an error message,
or for the CSS, in which case the page is displayed without the CSS.
This is always immediate, i.e. this is *not* some kind of timeout.
I need to reload the page.

This seems to occur only when opening links in a new tab (and perhaps
in a new window), not in the current tab, so that I suspect a bug in
Firefox. This issue is quite recent (a few weeks?).

Note: This time, I was using an automatic proxy configuration URL, but
I don't always use it. Anyway, this has also occurred for localhost,
which is never proxied.

Firefox 90 should be available in unstable to see if this issue still
occurs with it...

-- Package-specific info:


-- Addons package information

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

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

Versions of packages firefox depends on:
ii  debianutils  4.11.2
ii  fontconfig   2.13.1-4.2
ii  libatk1.0-0  2.36.0-2
ii  libc62.31-13
ii  libcairo-gobject21.16.0-5
ii  libcairo21.16.0-5
ii  libdbus-1-3  1.12.20-2
ii  libdbus-glib-1-2 0.110-6
ii  libevent-2.1-7   2.1.12-stable-1
ii  libffi7  3.3-6
ii  libfontconfig1   2.13.1-4.2
ii  libfreetype6 2.10.4+dfsg-1
ii  libgcc-s110.2.1-6
ii  libgdk-pixbuf-2.0-0  2.42.2+dfsg-1
ii  libglib2.0-0 2.66.8-1
ii  libgtk-3-0   3.24.24-4
ii  libnspr4 2:4.29-1
ii  libnss3  2:3.67-2
ii  libpango-1.0-0   1.46.2-3
ii  libstdc++6   10.2.1-6
ii  libvpx6  1.9.0-1
ii  libx11-6 2:1.7.1-1
ii  libx11-xcb1  2:1.7.1-1
ii  libxcb-shm0  1.14-3
ii  libxcb1  1.14-3
ii  libxcomposite1   1:0.4.5-1
ii  libxdamage1  1:1.1.5-2
ii  libxext6 2:1.3.3-1.1
ii  libxfixes3   1:5.0.3-2
ii  libxrender1  1:0.9.10-1
ii  procps   2:3.3.17-5
ii  zlib1g   1:1.2.11.dfsg-2

Versions of packages firefox recommends:
ii  libavcodec57  7:3.4.3-1
ii  libavcodec58  7:4.3.2-0+deb11u2

Versions of packages firefox suggests:
ii  fonts-lmodern  2.004.5-6.1
ii  fonts-stix [otf-stix]  1.1.1-4.1
ii  libcanberra0   0.30-7
ii  libgssapi-krb5-2   1.18.3-5
ii  libgtk2.0-02.24.33-2
ii  pulseaudio 14.2-2

-- no debconf information

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

Bug#990990: unblock: libcgroup/2.0

[Paul Gevers]

Hi,

On 12-07-2021 18:45, Michael Biebl wrote:
> This was already discussed in
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=959022
> 
> My takeaway from that discussion was, that rdeps of cgroup-tools, would
> itself have to be made cgroupv2 aware, especially OpenStack and its
> components.

That resembles my understanding of that discussion too.

> Have those rdeps been tested successfully with libcgroup/cgroup-tools
> from experimental?

I'm not in favor of doing this transition now.

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#990065: unblock: squid-deb-proxy/0.8.15+nmu1

[Paul Gevers]

Hi Hideki, Sebastian,

On 20-06-2021 16:02, Sebastian Ramacher wrote:
>> --- squid-deb-proxy-0.8.15/debian/squid-deb-proxy.install2020-01-10 
>> 19:02:40.0 +0900
>> +++ squid-deb-proxy-0.8.15+nmu1/debian/squid-deb-proxy.install   
>> 2021-06-14 23:40:21.0 +0900
>> @@ -1,3 +1,4 @@
>>  ../update-libc.d etc/resolvconf/
>>  etc/squid-deb-proxy
>>  init-common.sh usr/share/squid-deb-proxy/
>> +../apparmor-profiles/* etc/apparmor.d/abstractions/squid-deb-proxy/
> 
> I'm not an apparmor expert, but is this enough? Shouldn't there also be
> a profile for the binary that uses this abstraction?

@Hideki, can you please respond, this is a concern that you fix is not
enough.

@Sebastian, Hideki claims it fixes the issue:
"""
[ Tests ]
 Tested on KVM bullseye environment, it does not work well without
 this changes as the bug report says, and patched system works fine.
"""
so, even without a reply from Hideki, don't we expect bullseye to be
better with this change? Or is there a worry you have that I don't see?

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#991133: bible-kjv: Search no longer works after upgrading to Bullseye

[Regis Smith]

Package: bible-kjv
Version: 4.32
Severity: normal

Dear Maintainer,

   * What led up to the situation?

I upgraded from Buster to Bullseye

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

I tried a search in bible-kjv using "??"

   * What was the outcome of this action?

It reported no results:

bible(KJV) [Gen1:1]> ??hath
  Searching for 'hath'... not found.

Searching for any term shows "not found".

   * What outcome did you expect instead?

The same behavior in the Buster package.  When doing the search in
Buster I get 1840 refs:

bible(KJV) [Gen1:1]> ??hath
  Searching for 'hath'... [1840 refs]


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

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

Versions of packages bible-kjv depends on:
ii  bible-kjv-text  4.32
ii  libc6   2.31-12
ii  libreadline88.1-1

bible-kjv recommends no packages.

Versions of packages bible-kjv suggests:
pn  verse  

-- no debconf information

Bug#991132: no applets in gnome-applets

[mirnix]

Package: gnome-applets
Version: 3.38.0-1

i tried to install gnome-applets in a recent sid installation, but no 
extensions appear in gnome-tweaks. a file-list of gnome-applets shows 
that there are no /usr/lib/gnome-applets/ files in the package.



dpkg -c /var/cache/apt/archives/gnome-applets_3.38.0-1_amd64.deb
drwxr-xr-x root/root 0 2020-10-15 14:51 ./
drwxr-xr-x root/root 0 2020-10-15 14:51 ./usr/
drwxr-xr-x root/root 0 2020-10-15 14:51 ./usr/bin/
-rwxr-xr-x root/root 39144 2020-10-15 14:51 ./usr/bin/cpufreq selector
drwxr-xr-x root/root 0 2020-10-15 14:51 ./usr/lib/
drwxr-xr-x root/root 0 2020-10-15 14:51 ./usr/lib/x86_64-linux-gnu/
drwxr-xr-x root/root 0 2020-10-15 14:51 
./usr/lib/x86_64-linux-gnu/gnome-panel/
drwxr-xr-x root/root 0 2020-10-15 14:51 
./usr/lib/x86_64-linux-gnu/gnome-panel/modules/
-rw-r--r-- root/root709504 2020-10-15 14:51 
./usr/lib/x86_64-linux-gnu/gnome-panel/modules/org.gnome.gnome-applets.so

drwxr-xr-x root/root 0 2020-10-15 14:51 ./usr/share/
drwxr-xr-x root/root 0 2020-10-15 14:51 ./usr/share/doc/
drwxr-xr-x root/root 0 2020-10-15 14:51 
./usr/share/doc/gnome-applets/
-rw-r--r-- root/root  2275 2020-10-15 00:45 
./usr/share/doc/gnome-applets/AUTHORS
-rw-r--r-- root/root 35692 2020-10-15 00:46 
./usr/share/doc/gnome-applets/NEWS.gz
-rw-r--r-- root/root 20825 2020-10-15 14:51 
./usr/share/doc/gnome-applets/changelog.Debian.gz
-rw-r--r-- root/root  5073 2020-10-15 14:51 
./usr/share/doc/gnome-applets/copyright

drwxr-xr-x root/root 0 2020-10-15 14:51 ./usr/share/man/
drwxr-xr-x root/root 0 2020-10-15 14:51 ./usr/share/man/man1/
-rw-r--r-- root/root   825 2020-10-15 14:51 
./usr/share/man/man1/cpufreq-selector.1.gz


Debian Version 11.0
Linux 5.12.14-surface #1 SMP Fri Jul 2 17:30:46 UTC 2021 x86_64 GNU/Linux

Bug#967933: ant-optional: Missing ant-junitlauncher.jar

[Stefan Tauner]

Ok, got it. I missed some additional build requirements for Ant on
Junit5 if one wants to build junitlauncher completely and the whole
confined stuff threw me off.

Interestingly, junit5 is then not needed at runtime anymore - at least
not for how josm uses it. I have not tested other applications though.

I have made some additional useful changes but I do not intend to do a
NMU (yet) - it would be my first and I am not really confident that
this does not break anything - unless instructed to do so.
Feel free to copy any of it:
https://salsa.debian.org/stefanct/ant/-/commits/master

-- 
Kind regards/Mit freundlichen Grüßen, Stefan Tauner

Bug#991131: the exporter should run as group varnish

[Marco d'Itri]

Package: prometheus-varnish-exporter
Version: 1.6-1+b4
Severity: important

/etc/systemd/system/prometheus-varnish-exporter.service.d/local.conf:
[Service]
Group=varnish

Without this drop-in prometheus-varnish-exporter cannot actually run 
varnishstat.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#990344: Additional information

[sawbona]

On 15 Jul 2021 at 8:40, Marc Haber wrote:

> This has nothing to do with exim. If you intended to file a new
> bug for the backintime package, please use the reportbug tool.

Yes.
It was a typo.
I immediately sent notice to ow...@bugs.debian.org.

---
Good afternoon:

Please delete/disregard the last entry (Message #50) received at 
990...@bugs.debian.org due to an rather unfortunate typo on my 
behalf.

It obviously was intended to reach 990...@bugs.debian.org.
---

Sorry for the inconvenience caused.

Best,

Bug#990344: Additional information

[Marc Haber]

On Wed, Jul 14, 2021 at 05:11:27PM -0300, sawb...@xsmail.com wrote:
> I have received yet another notification in my system mail related to
> an unhandled exception in a backintime Python script.

This has nothing to do with exim. If you intended to file a new bug for
the backintime package, please use the reportbug tool.

Greetings
Marc

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

Bug#990741: [nore...@release.debian.org: ncbi-entrez-direct is marked for autoremoval from testing]

[Andreas Tille]

Thanks a lot, Andreas.

On Thu, Jul 15, 2021 at 12:39:06AM -0400, Aaron M. Ucko wrote:
> Yes, 990743, already granted. It doesn't appear to have reduced the delay 
> below what the autopkgtest already gave, though.
> 
> -- Aaron
> 
> On July 15, 2021 12:08:17 AM EDT, Andreas Tille  wrote:
> >Hi Aaron,
> >
> >did you filed an unblock request to release.debian.org bug report?
> >
> >Kind regards
> >Andreas.
> >
> >- Forwarded message from Debian testing autoremoval watch
> > -
> >
> >Date: Wed, 14 Jul 2021 04:39:03 +
> >From: Debian testing autoremoval watch 
> >To: ncbi-entrez-dir...@packages.debian.org
> >Subject: ncbi-entrez-direct is marked for autoremoval from testing
> >
> >ncbi-entrez-direct 14.6.20210224+dfsg-3 is marked for autoremoval from
> >testing on 2021-07-29
> >
> >It is affected by these RC bugs:
> >990741: ncbi-entrez-direct: efetch and einfo wrappers warn about some
> >supported options
> > https://bugs.debian.org/990741
> >
> >
> >
> >This mail is generated by:
> >https://salsa.debian.org/release-team/release-tools/-/blob/master/mailer/mail_autoremovals.pl
> >
> >Autoremoval data is generated by:
> >https://salsa.debian.org/qa/udd/-/blob/master/udd/testing_autoremovals_gatherer.pl
> >
> >___
> >Debian-med-packaging mailing list
> >debian-med-packag...@alioth-lists.debian.net
> >https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-packaging
> >
> >
> >- End forwarded message -
> >
> >-- 
> >http://fam-tille.de
> 
> -- 
> Sent from my Android device with K-9 Mail. Please excuse my brevity.

> ___
> Debian-med-packaging mailing list
> debian-med-packag...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-packaging


-- 
http://fam-tille.de

Bug#981372: keepassxc: new upstream version 2.6.6

[Andre Naujoks]

Am 14.07.21 um 18:02 schrieb Julian Andres Klode:

On Wed, Jul 14, 2021 at 04:46:30PM +0200, Andre Naujoks wrote:

Hi.

While ignoring the last rather rude comment, I'd like to ask, if there is
anything that needs to be done to update this to the current version.

I just tried to build the Debian package by just importing the new 2.6.6
version into the git repository and bumping the version accordingly on my
machine and it "just works".

Is there anything else in the way of getting a current version into
unstable? An update would "fix" #894964 as well.


We are still frozen.



Hi.

Well .. next time, I'll read up on that before. I wasn't aware of the 
effect of the freeze on unstable.


Sorry for the noise then :-)

Regards
  Andre