Bug#991969: D-I: news for Bullseye: help with firmware installation

[Paul Gevers]

Hi,

On 06-08-2021 21:52, Holger Wansing wrote:
> I would like to add a paragraph to the release-notes, describing a bit the 
> new "install-firmware" mechanism via modalias, with a link to the new doc 
> in the installation-guide, for those who experience problems.
> 
> Please find a patch attached.
> (Additionally, I updated some links to D-I alpha and RC releases for Bullseye,
> just for completeness. Better than keeping the old ones for Buster in this 
> file.)
> 
> 
> @debian-boot: 
> since there was no more comment, I'm turning this into a bugreport now. 
> We are already late before release date, and translators need time too...
> 
> @release:
> sorry for being late

I've reordered it a bit, as the template was for a list of changes. As
we now only have one section, let's call it a section.

I have further fixed two wrongly ordered tags, used bullseye in the
links and fixed a weird sentence in the next section.

Before pushing, I hope to see comments from Justin.

Paul
From 4c744fe5e3206521ceb3174eb34b5d6ea69c2eab Mon Sep 17 00:00:00 2001
From: Holger Wansing 
Date: Sat, 7 Aug 2021 07:31:28 +0200
Subject: [PATCH] installing.dbk: add d-i firmware note

Closes: #991969
---
 en/installing.dbk | 43 ++-
 1 file changed, 34 insertions(+), 9 deletions(-)

diff --git a/en/installing.dbk b/en/installing.dbk
index 7a7e0674..10396c60 100644
--- a/en/installing.dbk
+++ b/en/installing.dbk
@@ -44,21 +44,46 @@ for the  beta and RC releases available from the Debian
 Installer's news history.
 
 
-
 
+
+Help with installation of firmware
+
+  More and more, peripheral devices require firmware to be loaded as
+  part of the hardware initialization. To help deal with this problem,
+  the installer has been improved. Based on a hardware ID to firmware
+  file mapping, if some of the installed hardware requires firmware
+  files to be installed, the code installs them automatically.
+
+
+  Please note, that this new functionality is restricted to the
+  unofficial installer images with firmware included (see #firmware_nonfree).
+  The firmware is usually not DFSG compliant, so it is not possible to
+  distribute it in Debian's main repository.
+
+
+  If you experience problems related to (missing) firmware, you might
+  want to read https://www.debian.org/releases/bullseye/amd64/ch06s04.en.html#completing-installed-system;>the
+  dedicated chapter of the installation-guide.
+
+
 
-https://www.debian.org/devel/debian-installer/
 
-Sources (for buster):
+Sources (for bullseye):
 
-https://www.debian.org/devel/debian-installer/News/2017/20170903
-https://www.debian.org/devel/debian-installer/News/2017/20171206
-https://www.debian.org/devel/debian-installer/News/2018/20180619
-https://www.debian.org/devel/debian-installer/News/2018/20181215
-https://www.debian.org/devel/debian-installer/News/2019/20190202
+https://www.debian.org/devel/debian-installer/News/2019/20191205
+https://www.debian.org/devel/debian-installer/News/2020/20200316
+https://www.debian.org/devel/debian-installer/News/2020/20201206
+https://www.debian.org/devel/debian-installer/News/2021/20210423
+https://www.debian.org/devel/debian-installer/News/2021/20210614
+https://www.debian.org/devel/debian-installer/News/2021/20210802
 - ->
 
 
 Automated installation
 
-Some changes mentioned in the previous section also imply changes in
+Some changes also imply changes in
 the support in the installer for automated installation using preconfiguration
 files.  This means that if you have existing preconfiguration files that worked
 with the  installer, you cannot expect these to work with the new
-- 
2.30.2



OpenPGP_signature
Description: OpenPGP digital signature

Bug#991975: unblock: node-setimmediate/1.0.5-6

[Yadd]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: 969...@bugs.debian.org

Please unblock package node-setimmediate

[ Reason ]
node-setimmediate is RC-buggy (#969611):
 * broken symlinks in node-setimmediate documentation
 * unexistent suggested dependencies

[ Impact ]
Missing JS in HTML doc files

[ Tests ]
No changes

[ Risks ]
No risk, this just fixes links and dependencies

[ 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

Cheers,
Yadd

unblock node-setimmediate/1.0.5-6
diff --git a/debian/changelog b/debian/changelog
index a7a5a3c..20055db 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,12 @@
+node-setimmediate (1.0.5-6) unstable; urgency=medium
+
+  * Team upload
+  * Fix GitHub tags regex
+  * Replace libjs-mocha by mocha in suggested dependencies and fix related doc
+links (Closes: #969611)
+
+ -- Yadd   Sat, 07 Aug 2021 07:28:56 +0200
+
 node-setimmediate (1.0.5-5) unstable; urgency=medium
 
   * Team upload
diff --git a/debian/control b/debian/control
index c4531de..5f56b26 100644
--- a/debian/control
+++ b/debian/control
@@ -18,8 +18,8 @@ Package: node-setimmediate
 Architecture: all
 Depends: ${misc:Depends},
  nodejs
-Suggests: libjs-mocha (>= 3),
-  libjs-chai
+Suggests: mocha (>= 3),
+  chai
 Description: shim for the setImmediate efficient script yielding API
  setImmediate.js is a highly cross-browser implementation of the
  setImmediate and clearImmediate APIs, proposed by Microsoft to
diff --git a/debian/rules b/debian/rules
index e1a396c..4e0335f 100755
--- a/debian/rules
+++ b/debian/rules
@@ -10,10 +10,10 @@
 override_dh_auto_build:
 ifeq (,$(filter nodoc,$(DEB_BUILD_OPTIONS) $(DEB_BUILD_PROFILES)))
# add compat link
-   ln -s /usr/share/javascript/mocha/mocha.css test/browserOnly/mocha.css
-   ln -s /usr/share/javascript/mocha/mocha.js test/browserOnly/mocha.js
-   ln -s /usr/share/javascript/chai/chai.js test/browserOnly/chai.js
-   ln -s ../../setImmediate.js test/browserOnly/setImmediate.js
+   ln -s /usr/share/nodejs/mocha/mocha.css test/browserOnly/mocha.css
+   ln -s /usr/share/nodejs/mocha/lib/mocha.js test/browserOnly/mocha.js
+   ln -s /usr/share/nodejs/chai/lib/chai.js test/browserOnly/chai.js
+   ln -s /usr/share/nodejs/setimmediate/setImmediate.js 
test/browserOnly/setImmediate.js
 else
@echo '**'
@echo 'Skip building doc '
diff --git a/debian/watch b/debian/watch
index 5aba20b..0cd85da 100644
--- a/debian/watch
+++ b/debian/watch
@@ -2,5 +2,5 @@ version=3
 opts=\
 dversionmangle=s/\+(debian|dfsg|ds|deb)(\.\d+)?$//,\
 filenamemangle=s/.*\/v?([\d\.-]+)\.tar\.gz/node-setimmediate-$1.tar.gz/ \
- https://github.com/YuzuJS/setImmediate/tags .*/archive/v?([\d\.]+).tar.gz
+ https://github.com/YuzuJS/setImmediate/tags .*/archive/.*/v?([\d\.]+).tar.gz
 

Bug#991974: unblock: twitter-bootstrap4/4.5.2+dfsg1-8

[Yadd]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: 991...@bugs.debian.org

Please unblock package twitter-bootstrap4

[ Reason ]
4.5.2+dfsg1-7 changes missed some .map files (scss-to-css). This version
reinstall them (RC bug #991939).

[ Impact ]
Nothing

[ Tests ]
No changes

[ Risks ]
No risks

[ 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

Cheers,
Yadd

unblock twitter-bootstrap4/4.5.2+dfsg1-8
diff --git a/debian/changelog b/debian/changelog
index a563bd262..679b41db1 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+twitter-bootstrap4 (4.5.2+dfsg1-8) unstable; urgency=medium
+
+  * Add missing .map files (Closes: #991939)
+
+ -- Yadd   Sat, 07 Aug 2021 07:07:47 +0200
+
 twitter-bootstrap4 (4.5.2+dfsg1-7) unstable; urgency=medium
 
   [ Pirate Praveen ]
diff --git a/debian/rules b/debian/rules
index 7cdd8537a..287468842 100755
--- a/debian/rules
+++ b/debian/rules
@@ -12,6 +12,7 @@ override_dh_auto_build:
sassc --sourcemap=auto scss/bootstrap-reboot.scss 
dist/tmp/bootstrap-reboot.css
node debian/postcss.js
cp -v dist/tmp/*.css dist/css/
+   cp -v dist/tmp/*.css.map dist/css/
sassc --sourcemap=auto --style compressed dist/tmp/bootstrap.css 
dist/css/bootstrap.min.css
sassc --sourcemap=auto --style compressed dist/tmp/bootstrap-grid.css 
dist/css/bootstrap-grid.min.css
sassc --sourcemap=auto --style compressed dist/tmp/bootstrap-reboot.css 
dist/css/bootstrap-reboot.min.css

Bug#991971: SNI is a security vulnerability all by itself (was Re: [Lynx-dev] bug in Lynx' SSL certificate validation -> leaks password in clear text via SNI (under some circumstances))

[Thorsten Glaser]

>Axel Beckert dixit:

>>IMHO this nevertheless needs a CVE-ID.

I wonder… perhaps the use of SNI, both in the TLSv1.3 standard
and in some TLSv1.2 implementations, should receive CVEs as well?

It certainly ought to be disabled by default. Perhaps add some
environment variable to enable SNI in the SSL library, and if
it’s not present or explicitly set to 0, disable SNI (which also
would disable TLSv1.3 as it requires SNI). Hmm, yes, this sounds
completely like a good idea.

(Considering SNI also leaks the vhost addressed by the end user,
which is otherwise hidden with wildcard certificates or grouped
with tone others in multi-subjectAltName certificates, it ought
to have been anyway.)

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

Bug#991971: [Lynx-dev] bug in Lynx' SSL certificate validation -> leaks password in clear text via SNI (under some circumstances)

[Thorsten Glaser]

Axel Beckert dixit:

>This is more severe than it initially looked like: Due to TLS Server
>Name Indication (SNI) the hostname as parsed by Lynx (i.e with
>"user:pass@" included) is sent in _clear_ text over the wire even

I *ALWAYS* SAID SNI IS A SHIT THING ONLY USED AS BAD EXCUSE FOR NAT
BY PEOPLE WHO ARE TOO STUPID TO CONFIGURE THEIR SERVERS RIGHT AND AS
BAD EXCUSE FOR LACKING IPv6 SUPPORT, AND THEN THE FUCKING IDIOTS WENT
AND MADE SNI *MANDATORY* FOR TLSv1.3, AND I FEEL *SO* VINDICATED RIGHT
NOW! IDIOTS IN CHARGE OF SECURITY, FUCKING IDIOTS…

>But given that the symptoms Thorsten discovered stayed unreported for
>quite some years, I assume that this use case is a rather seldom one.

Nah, SNI is a rather recent thing. But…

>IMHO this nevertheless needs a CVE-ID.

… it probably does. Other browsers also need checking.

Thanks for the detective work,
//mirabilos
-- 
 Beware of ritual lest you forget the meaning behind it.
 yeah but it means if you really care about something, don't
ritualise it, or you will lose it. don't fetishise it, don't
obsess. or you'll forget why you love it in the first place.

Bug#991971: [Lynx-dev] bug in Lynx' SSL certificate validation -> leaks password in clear text via SNI (under some circumstances)

[Axel Beckert]

Hi,

On Fri, Aug 06, 2021 at 05:14:32PM +, Thorsten Glaser
 wrote in
https://lists.nongnu.org/archive/html/lynx-dev/2021-08/msg0.html:
> this affects both OpenSSL and Debian’s nonGNUtls builds:
> 
> lynx https://user:pass@host/
> 
> … will lead to…
> 
> SSL 
> error:host(user:pass@host)!=cert(CN:SAN:SAN
> 
> … for OpenSSL lynx and…
> 
> SSL error:host(user:pass@host)!=cert(CN)-Continue? (n)
> 
> … for nonGNUtls lynx.
> 
> Obviously, user:pass@ need to be stripped before comparing.

This is more severe than it initially looked like: Due to TLS Server
Name Indication (SNI) the hostname as parsed by Lynx (i.e with
"user:pass@" included) is sent in _clear_ text over the wire even
_before_ I can even said "n" for "no, don't continue to talk with this
server" in Lynx's prompt as shown above.

I was able to capture the password given on the commandline in traffic
of an TLS handshake using tcpdump and analysing it with Wireshark:

From Wiresharks TLS dissector:

Server Name Indication extension
Server Name list length: 28
Server Name Type: host_name (0)
Server Name length: 25
Server Name: user:p...@www.example.org
 ^^

From Wiresharks "Follow TCP stream":

...a
jV.. /...D.&R.+.,.  .
.../.0...z.{./.5.A...
.|.}.3.9.E.2.8.D...p$."...user:p...@www.example.org..#...
...
.
..

(PCAPs available on request. Actually did the test with a local server
of mine. But it should be easy to reproduce, be it with any Linux
distribution.)

I did this test with Lynx from Debian Experimental (which has the
current Lynx upstream release 2.9.0dev.8) as well as with Lynx from
Debian 8 Jessie ELTS (which has Lynx 2.8.9dev.1) and both leak the
password via SNI. I though assume that older releases of Lynx are
probably also affected as well, at least if they or the according
crypto libraries support SNI.

But given that the symptoms Thorsten discovered stayed unreported for
quite some years, I assume that this use case is a rather seldom one.
Nevertheless only trying to use Lynx that way (and seeing it fail)
already leaks the used password.

IMHO this nevertheless needs a CVE-ID.

Cc'ing Debian Security Team as well as the OSS Security mailing list
for making them aware of this issue. I also updated the subject of
this thread to make it less ambigous on other mailing lists.

And I'm also Cc'ing the according Debian bug report which I created
for tracking this issue in Debian: https://bugs.debian.org/991971

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


signature.asc
Description: PGP signature

Bug#951902: python3

[Thorsten Alteholz]

Just for the record, there is an upstream issue #1794 [1] related to 
this.



[1] https://github.com/svaarala/duktape/issues/1794
[2] https://github.com/svaarala/duktape/pull/2375

Bug#991969: D-I: news for Bullseye: help with firmware installation

[Holger Wansing]

Package: release-notes


I would like to add a paragraph to the release-notes, describing a bit the 
new "install-firmware" mechanism via modalias, with a link to the new doc 
in the installation-guide, for those who experience problems.

Please find a patch attached.
(Additionally, I updated some links to D-I alpha and RC releases for Bullseye,
just for completeness. Better than keeping the old ones for Buster in this 
file.)


@debian-boot: 
since there was no more comment, I'm turning this into a bugreport now. 
We are already late before release date, and translators need time too...

@release:
sorry for being late



Holger


-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076
diff --git a/en/installing.dbk b/en/installing.dbk
index 7a7e0674..9d645d61 100644
--- a/en/installing.dbk
+++ b/en/installing.dbk
@@ -44,41 +44,56 @@ for the  beta and RC releases available from the Debian
 Installer's news history.
 
 
-
 
 
 
-
-
 
-
+Help with installation of firmware
 
 
-
+More and more, peripheral devices require firmware to be loaded as part of the
+hardware initialization. To help deal with this problem, the installer has been
+improved.
+Based on a hardware ID to firmware file mapping, if some of the installed
+hardware requires firmware files to be installed, the code installs them
+automatically.
+
+Please note, that this new functionality is restricted to the unofficial
+installer images with firmware included (see https://www.debian.org/releases/stable/debian-installer/#firmware_nonfree;>https://www.debian.org/releases/stable/debian-installer/#firmware_nonfree).
+The firmware is usually not DFSG compliant, so it is not possible to
+distribute it in Debian's main repository.
+
+If you experience problems related to (missing) firmware, you might want
+to read https://www.debian.org/releases/stable/amd64/ch06s04.en.html#completing-installed-system;>the
+dedicated chapter of the installation-guide.
 
 
 
 
+
 
 
 
--->
 
 
 Automated installation

Bug#991973: dbconfig-common: missing Breaks: pdns-backend-sqlite

[Andreas Beckmann]

Package: dbconfig-common
Version: 2.0.19
Severity: important
User: debian...@lists.debian.org
Usertags: piuparts
Control: affects -1 + pdns-backend-sqlite

Hi,

during a test with piuparts I noticed your package causes
pdns-backend-sqlite (which may still be around from wheezy which was the
last release shipping it) to fail to remove since the sqlite scripts are
gone. So please add Breaks: pdns-backend-sqlite to ensure that obsolete
package gets removed before dbconfig-common drops the scripts. The fix
needs to get into bullseye to be effective.
This seems to be the only package in the archive affected by such a bug.

>From the attached log (scroll to the bottom...):

  Removing pdns-backend-sqlite (3.1-4.1+deb7u3) ...
  /var/lib/dpkg/info/pdns-backend-sqlite.prerm: 9: .: cannot open 
/usr/share/dbconfig-common/dpkg/prerm.sqlite: No such file
  dpkg: error processing package pdns-backend-sqlite (--remove):
   installed pdns-backend-sqlite package pre-removal script subprocess returned 
error exit status 2
  dpkg: too many errors, stopping
  /var/lib/dpkg/info/pdns-backend-sqlite.postinst: 9: .: cannot open 
/usr/share/dbconfig-common/dpkg/postinst.sqlite: No such file
  dpkg: error while cleaning up:
   installed pdns-backend-sqlite package post-installation script subprocess 
returned error exit status 2
  Errors were encountered while processing:
   pdns-backend-sqlite


cheers,

Andreas


pdns-backend-sqlite_None.log.gz
Description: application/gzip

Bug#991972: backports.org invalid certificate

[Xan Charbonnet]

Package: www.debian.org

Some muscle memory from a long time ago kicked in, and I browsed to 
backports.org instead of to backports.debian.org.


backports.org now seems to serve the Debian homepage, and in the process 
triggers the browser's invalid certificate error, because the 
certificate is for www.debian.org.


It seems to me that backports.org should redirect to 
backports.debian.org.  I'm not sure why the Debian homepage would greet 
somebody visiting backports.org, but if that's desired, it should 
redirect to www.debian.org rather than simply serve its content.  In 
either case backports.org should have its own proper certificate.


Or backports.org could go away.

Bug#954093: desktop-base: Integration with KDE plasma on debian testing no longer works

[Laura Arjona Reina]

Hello again
I formerly said that my desktop was all Homeworld-themed except the 
wallpaper, but I just found out that the lockscreen also had the 
"Shells" background instead of the proposed Homeworld image for 
lockscreen.


I'm not sure if Plymouth is also well integrated or not because this 
computer never shows the Plymouth animations.


OTOH I see that there's another customizable image, the "Welcome 
screen", that in this system shows the Breeze welcome screen (I don't 
know if we provide a Homeworld welcome screen or not).


Kind regards,
--
Laura Arjona Reina
https://wiki.debian.org/LauraArjona

Bug#991971: lynx: SSL certificate validation fails with URLs containing user name or user name and password, i.e. https://user:password@host/ and https://user@host/

[Axel Beckert]

Package: lynx
Version: 2.9.0dev.8-1
Severity: important
Tags: upstream, confirmed
Control: forwarded -1 
https://lists.nongnu.org/archive/html/lynx-dev/2021-08/msg0.html
Control: found -1 2.8.9dev1-2+deb8u1
Control: found -1 2.8.9dev11-1
Control: found -1 2.8.9rel.1-3
Control: found -1 2.9.0dev.6-2

Thorsten Glaser reported the following on the upstream dev mailing list
at https://lists.nongnu.org/archive/html/lynx-dev/2021-08/msg0.html
(citing the parts that affect Debian, i.e. those when compiled against
GnuTLS and not OpenSSL):

> this affects both OpenSSL and Debian’s nonGNUtls builds:
> 
> lynx https://user:pass@host/
>
> … will lead to…
[…]
> SSL error:host(user:pass@host)!=cert(CN)-Continue? (n)
>
> … for nonGNUtls lynx.
> 
> Obviously, user:pass@ need to be stripped before comparing. The
> nonGNUtls version could also be changed to display the
> subjectAltName''s the certificate has like the OpenSSL one does (after
> my patch from ages ago; […]

https://user@host/ is affected as well.

I was able to reproduce this issue in Lynx in all currently (in some
way) supported releases of Debian back to Debian 8 Jessie with ELTS
support and also in the most recent version in Debian Experimental.

P.S. to Thorsten: Feel free to set yourself as submitter of this bug
report. ☺

-- System Information:
Debian Release: 11.0
  APT prefers unstable
  APT policy: (990, 'unstable'), (600, 'testing'), (500, 'unstable-debug'), 
(500, 'testing-security'), (500, 'buildd-unstable'), (110, 'experimental'), (1, 
'experimental-debug'), (1, 'buildd-experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages lynx depends on:
ii  libbsd0   0.11.3-1
ii  libbz2-1.01.0.8-4
ii  libc6 2.31-13
ii  libgnutls30   3.7.1-5
ii  libidn2-0 2.3.0-5
ii  libncursesw6  6.2+20201114-2
ii  libtinfo6 6.2+20201114-2
ii  lynx-common   2.9.0dev.6-2
ii  zlib1g1:1.2.11.dfsg-2

Versions of packages lynx recommends:
ii  mime-support  3.66

lynx suggests no packages.

-- no debconf information

Bug#991668: A learn-emacs-in-moments doc

[Nicholas D Steeves]

Hi Karl,

"Karl O. Pinc"  writes:
>
> As long a your messing about with the documentation
> attached is a 1 page (or 2 if you want to keep reading)
> doc on getting started with emacs.  If you feel it would
> be helpful to include (somewhere), please do.
>
> I'll license it in the public domain, or gplv3, or whatever
> you think might get it into the most visible place/package.
>
> I'd be happy to redo in RST (or docbook v5) to support
> multiple formats.
>
> Feedback on content is also welcome.
>

Thank you for your enthusiasm and desire to make Emacs more
approachable!  For the documentation you've proposed to be relevant to
this bug, it would need to be part of upstream Emacs documentation, so
that's one option.  A notable barrier to this avenue is the Developer
Certificate of Origin, and the potential issue of attributing copyright
to the FSF, but that said, it's a good option.  At this point I'd use
whatever source format you're most comfortable with; later, if you
wanted to upstream your work, you'd contact upstream, ask where they
think it would "fit" into the existing upstream docs, convert it to the
format used by the rest of upstream Emacs documentation, and submit a
patch.

I was able to find two web pages with good "First Steps in Emacs" type
documentation, so I agree that there's a need, and that there are also
other people who are interested in solving this problem.  It might be
worth collaborating to share data on pitfalls that new users experience,
and the "many eyes" approach helps to defend against "paradox of
knowledge" type assumptions made while writing documentation.  To take
this path, host a git repository of your project, write a README with
clear objectives, of course share what you have, and reach out to forums
and people who seem like they might be interested.  If your intent is to
eventually upstream the Quick Start Guide, please include this fact in
your README, along with links to what is required.  eg: all significant
contributors would need to be willing to attribute copyright to the FSF
and comply with their DCO checks.

Ideally it would also be nice to see footnotes and/or links to existing
documentation to provide direction for further growth for a new user who
has succeeded in their first steps.  It's also a challenge to find the
balance between not enough info, and too much info, but I agree that a
simple guide is a good idea, because it provides fast positive feedback
that encourages further learning.

I also think that the "Emacs Tutorial" could use some edits, to
communicate the value of its approach.  Eg: The "why", and for example I
remember feeling that the cursor movement section was neat, but
anachronistic, and I didn't see why it was worth learning until many
years later.  I sometimes wonder if Emacs' existing documentation is a
form of gating, if it's purposefully designed as a "quest", or of the
"paradox of knowledge" principle is in effect.  It's high quality
documentation, but yes, I agree, whatever the cause may be, it could be
more approachable and discoverable.

In addition to the Debian Emacsen Team mailing list, here are links to
other forums where you may be able to find collaborators and/or people
who are willing to provide feedback:
  https://www.emacswiki.org/emacs/EmacsForums

Of course, it's also completely acceptable to work on it alone!
Personally I prefer team work, because it encourages me to continue
working during times when I lack motivation ;-)

I hope this email finds you well, and encourages you!
Best,
Nicholas


signature.asc
Description: PGP signature

Bug#991908: popcon-upload: fails with https SUBMITURLS: Unable to parse url (unable to submit report)

[Bill Allombert]

On Thu, Aug 05, 2021 at 01:42:03AM +0200, Thorsten Glaser wrote:
> Package: popularity-contest
> Version: 1.71
> Severity: normal
> X-Debbugs-Cc: t...@mirbsd.de
> 
> When SUBMITURLS has an https URL (or one not with http:// anyway,
> see /usr/share/popularity-contest/popcon-upload line 38 for why,
> submission fails; syslog has…
> 
> Aug  5 01:37:53 DESKTOP-PN6OO9E popularity-contest: unable to submit report 
> to https://popcon.ubuntu.com/popcon-submit.cgi.
> 
> (this is on a standard WSL system, but the bug is present in stock
> Debian popcon-upload) and using popcon-upload’s -d option:
> 
> + setsid /usr/share/popularity-contest/popcon-upload -d -u 
> https://popcon.ubuntu.com/popcon-submit.cgi -f 
> /var/log/popularity-contest.new -C
> Unable to parse url
> 
> This is probably more relevant to certain derivatives, but it will
> impact #989082 negatively as well.
> 
> For completeness in case derivatives’ users stumble upon this:
> 
> tglase@DESKTOP-PN6OO9E:~ $ tail -1 /etc/popularity-contest.conf
> SUBMITURLS=http://popcon.ubuntu.com/popcon-submit.cgi
> 
> This makes it succeed as that submit host seems to accept http.

Hello Thorsten,
For reasons explained in #989082, submitting via https is not supported.
PGP encryption is safer and more robust on popcon time scale.

Also, Ubuntu has stopped reporting to popcon.ubuntu.com.

Cheers,
Bill.

Bug#991970: piuparts: ftbfs with golang-1.16

[Brian Murray]

I also tested building the patch with golang-1.15 and it also succeeded.

--
Brian Murray

Bug#991961: golang-1.15: CVE-2021-36221

[Paul Gevers]

Hi Shengjing,

On 06-08-2021 22:01, Shengjing Zhu wrote:
> Should we fix it before the bullseye release?

No, at least not in 11.0.

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#991951: debian-installer: Text installer sporadically hangs when using 512 - 1024 MB of memory.

[Samuel Thibault]

Control: Tags -1 + unreproducible

Hello,

Witold Baryluk, le ven. 06 août 2021 16:29:50 +0200, a ecrit:
> https://www.debian.org/releases/bullseye//amd64/ch03s04.en.html says this 
> should be supported.

Yes, that should be working, and does work in my tests.

> Using multi-arch image for testing.
> 
> wget 
> https://cdimage.debian.org/cdimage/daily-builds/daily/arch-latest/multi-arch/iso-cd/debian-testing-amd64-i386-netinst.iso
> 
> (image from 2021-08-06 11:00)
> 
> qemu-system-x86_64 --enable-kvm -cdrom debian-testing-amd64-i386-netinst.iso 
> -m 1024

Which version of qemu is this? I guess no other option than this?

> Select "Install" (text installer, not graphical one).

I.e. the second boot option? (the 64bit variant)

> Select defaults (or other) for language, location and keyboard.

So just pressing enter to select everything by default? (except the
"Install" boot option)

> Let it load installer components.
> 
> It will sometimes load, but more often than not, if you start again from
> scratch, it will hang somewhere forever.

So you mean while loading installer components?

I'm not getting such a problem (and 1024M is really plently to just load
components, it's partman that needs quite more, notably with crypto
enabled).

At worse, note from
https://www.debian.org/releases/bullseye//amd64/ch02s05.en.html
that you can force higher lowmem options, but 1024M should really be way
enough.

Samuel

Bug#991460: vcmi: aborts when hovering over campaign selection figures

[Johannes Schauer Marin Rodrigues]

Control: tag -1 + patch

Hi,

Quoting fulvio ciriaco (2021-07-24 17:24:37)
> steps to reproduce:
> 1. select new  -> campaign
> 2. move the mouse to select the campaign
> vcmi aborts immediately with the following message:
> 
> Initializing VCMI_Lib: 313 ms
> Screen handler: 8 ms
> Main graphics: 103 ms
> Message handler: 1 ms
> Initialization of VCMI (together): 1126 ms
> corrupted double-linked list
> 
> it happens on different computers, motherboards and graphic cards.
> as a workaround, it is possible to select a campaign opening vcmi in valgrind 
> (very
> slow), saving the first day and reopening normally.

thank you for your bugreport! I can reproduce the problem and the attached
patch fixes it.

Thanks!

cheers, joschdiff -Nru vcmi-0.99+dfsg+git20190113.f06c8a87/debian/changelog vcmi-0.99+dfsg+git20190113.f06c8a87/debian/changelog
--- vcmi-0.99+dfsg+git20190113.f06c8a87/debian/changelog	2021-08-06 19:58:17.0 +0200
+++ vcmi-0.99+dfsg+git20190113.f06c8a87/debian/changelog	2020-06-03 12:44:51.0 +0200
@@ -1,10 +1,3 @@
-vcmi (0.99+dfsg+git20190113.f06c8a87-2.1) UNRELEASED; urgency=medium
-
-  * Non-maintainer upload.
-  * 
-
- -- Johannes Schauer Marin Rodrigues   Fri, 06 Aug 2021 19:58:17 +0200
-
 vcmi (0.99+dfsg+git20190113.f06c8a87-2) unstable; urgency=medium
 
   * Add patch "Fix build with Boost version >= 1.70"
diff -Nru vcmi-0.99+dfsg+git20190113.f06c8a87/debian/control vcmi-0.99+dfsg+git20190113.f06c8a87/debian/control
--- vcmi-0.99+dfsg+git20190113.f06c8a87/debian/control	2021-08-06 19:58:17.0 +0200
+++ vcmi-0.99+dfsg+git20190113.f06c8a87/debian/control	2020-06-03 12:44:51.0 +0200
@@ -26,8 +26,7 @@
  help2man,
  tex4ht,
  texlive-latex-base,
- texlive-latex-extra,
- libtbb-dev
+ texlive-latex-extra
 Standards-Version: 4.1.4
 Vcs-Browser: https://salsa.debian.org/games-team/vcmi
 Vcs-Git: https://salsa.debian.org/games-team/vcmi.git
diff -Nru vcmi-0.99+dfsg+git20190113.f06c8a87/debian/patches/link_with_tbb vcmi-0.99+dfsg+git20190113.f06c8a87/debian/patches/link_with_tbb
--- vcmi-0.99+dfsg+git20190113.f06c8a87/debian/patches/link_with_tbb	2021-08-06 19:58:06.0 +0200
+++ vcmi-0.99+dfsg+git20190113.f06c8a87/debian/patches/link_with_tbb	1970-01-01 01:00:00.0 +0100
@@ -1,558 +0,0 @@
 a/CMakeLists.txt
-+++ b/CMakeLists.txt
-@@ -223,6 +223,7 @@ find_package(SDL2 REQUIRED)
- find_package(SDL2_image REQUIRED)
- find_package(SDL2_mixer REQUIRED)
- find_package(SDL2_ttf REQUIRED)
-+find_package(TBB REQUIRED)
- 
- if(ENABLE_LAUNCHER)
- 	# Widgets finds its own dependencies (QtGui and QtCore).
 a/client/CMakeLists.txt
-+++ b/client/CMakeLists.txt
-@@ -176,6 +176,7 @@ endif()
- target_link_libraries(vcmiclient vcmi ${Boost_LIBRARIES}
- 	${SDL2_LIBRARY} ${SDL2_IMAGE_LIBRARY} ${SDL2_MIXER_LIBRARY} ${SDL2_TTF_LIBRARY}
- 	${ZLIB_LIBRARIES} ${FFMPEG_LIBRARIES} ${FFMPEG_EXTRA_LINKING_OPTIONS} ${SYSTEM_LIBS}
-+	${TBB_LIBRARIES}
- )
- 
- target_include_directories(vcmi
 /dev/null
-+++ b/cmake_modules/FindTBB.cmake
-@@ -0,0 +1,534 @@
-+#.rst:
-+# FindTBB
-+# ---
-+#
-+# Find Intel's Threading Building Blocks (TBB) include path and libraries.
-+#
-+# This module reads hints about search locations from variables:
-+#
-+# ::
-+#
-+#TBB_ROOT - Root directory of pre-built TBB package.
-+#   Can be an environment variable instead. It is
-+#   derived from the found TBB_INCLUDE_DIR if unset.
-+#TBB_ARCH_PLATFORM- Environment variable which can be used to specify
-+#   architecture and platform specific library path
-+#   suffix (excluding "/lib/" suffix or prefix).
-+#   For MSVC, the appropriate link library path of the
-+#   official pre-built download package from the TBB
-+#   web site is chosen by this module. The path suffix
-+#   derived from this variable takes precedence.
-+#
-+# This module considers the following CMake variables set by find_package:
-+#
-+# ::
-+#
-+#TBB_FIND_COMPONENTS  - Case-insensitive names of requested libraries:
-+#   tbb, [tbb]malloc, [tbb]malloc_proxy
-+#TBB_FIND_REQUIRED_- Whether TBB library component  is required.
-+#   TBB is considered to be not found when at least
-+#   one required library or its include path is missing.
-+#   When no TBB_FIND_COMPONENTS are specified, only the
-+#   threading library "tbb" is required.
-+#TBB_FIND_REQUIRED- Raise FATAL_ERROR when required components not found.
-+#TBB_FIND_QUIETLY - Suppress all other 

Bug#991970: piuparts: ftbfs with golang-1.16

[Brian Murray]

Package: piuparts
Version: 1.1.4
Severity: important
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu impish

Dear Maintainer,

The attached patch will fix a FTBFS with golang-1.16.

This bug report was also filed in Ubuntu and can be found at
http://launchpad.net/bugs/1939171

The description, from Brian Murray, follows:

In 
https://launchpadlibrarian.net/551476957/buildlog_ubuntu-impish-amd64.piuparts_1.1.4_BUILDING.txt.gz
 we can see the following:

touch build-stamp
(cd helpers/debiman-piuparts-distill && go build)
go: go.mod file not found in current directory or any parent directory; see 'go 
help modules'
make[2]: *** [Makefile:61: build-master-stamp] Error 1
make[2]: Leaving directory '/<>'
make[1]: *** [debian/rules:12: override_dh_auto_build] Error 2
make[1]: Leaving directory '/<>'
make: *** [debian/rules:9: binary] Error 2
dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2

This happens with piuparts version 1.1.4 and a test rebuild of 1.12 using 
golang-go (which depends on golang-1.16-go) also failed.

-- System Information:
Debian Release: 11.0
  APT prefers impish
  APT policy: (500, 'impish')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
>From 63a6d460c8578ec9b5e2c400d7d9ec5b22f14f81 Mon Sep 17 00:00:00 2001
From: Brian Murray 
Date: Fri, 6 Aug 2021 12:49:18 -0700
Subject: [PATCH] Fix FTBFS w/ golang-1.16

---
 CONTRIBUTING | 1 +
 Makefile | 2 +-
 debian/changelog | 7 +++
 3 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/CONTRIBUTING b/CONTRIBUTING
index 932bee56..5d1f732d 100644
--- a/CONTRIBUTING
+++ b/CONTRIBUTING
@@ -16,6 +16,7 @@ or to the tracking bug: @bugs.debian.org.
 
 One possible workflow:
   git clone https://salsa.debian.org/debian/piuparts.git
+  cd piuparts
   git checkout origin/develop -b 
   
   git commit -a
diff --git a/Makefile b/Makefile
index df373eb5..ff7b7ca0 100644
--- a/Makefile
+++ b/Makefile
@@ -58,7 +58,7 @@ build-stamp: $(SCRIPTS_GENERATED) $(DOCS_GENERATED) Makefile
touch $@
 
 build-master-stamp:
-   (cd helpers/debiman-piuparts-distill && go build)
+   (go mod init helpers/debiman-piuparts-distill && cd 
helpers/debiman-piuparts-distill && go build)
touch $@
 
 build-doc: $(DOCS_GENERATED)
diff --git a/debian/changelog b/debian/changelog
index 251b90ee..6ec38e22 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+piuparts (1.1.5) UNRELEASED; urgency=medium
+
+  * Makefile: Execute go mod init before running go build, fixes FTBFS with
+golang-1.16. (LP: #1939171)
+
+ -- Brian Murray   Fri, 06 Aug 2021 12:47:14 -0700
+
 piuparts (1.1.3) unstable; urgency=medium
 
   [ Michael Prokop ]
-- 
2.31.1

Bug#991961: golang-1.15: CVE-2021-36221

[Shengjing Zhu]

Hi,

On Sat, Aug 7, 2021 at 1:51 AM Salvatore Bonaccorso  wrote:
>
> Source: golang-1.15
> Version: 1.15.9-6
> Severity: important
> Tags: security upstream
> Forwarded: https://github.com/golang/go/issues/46866
> X-Debbugs-Cc: car...@debian.org, Debian Security Team 
> 
>
> Hi,
>
> The following vulnerability was published for golang-1.15.
>
> CVE-2021-36221[0]:
> | net/http: panic due to racy read of persistConn after handler panic
>

The issue looks minor(upstream disclose it without pre-announce).
Should we fix it before the bullseye release?
Fixing issues in the compiler's std library needs to rebuild the whole
world, see #990825

Or we just postpone later, or just fix the compiler package along?

-- 
Shengjing Zhu

Bug#991730: libapache2-mod-auth-mellon: CVE-2021-3639: open redirect vulnerability

[Thijs Kinkhorst]

Hi Salvatore,

> CVE-2021-3639[0]:
> | Prevent redirect to URLs that begin with '///'

I have a fixed package prepared and tested for sid but can only upload
this next week when I return from holiday.

I consider this (open redirect in general) a minor issue so I don't think
it's needed to expediate this.


Kind regards,
Thijs

Bug#991968: firmware-brcm80211: security updates for wifi FragAttacks

[Andres Salomon]

Package: firmware-brcm80211
Version: 20210315-3
Severity: important
Tags: security
X-Debbugs-Cc: Debian Security Team 


A whole bunch of wifi (protocol-level) security flaws were published
here: https://www.fragattacks.com/

Cypress (AKA Infineon), who maintains some of the broadcom firmware
blobs, published this in response:
https://community.cypress.com/t5/Security-Bulletin/Potential-Fragmentation-Vulnerabilities-for-Wi-Fi-Devices/ba-p/276441

You can see from that that CVE-2020-24587, CVE-2020-24588,
CVE-2020-26145, and CVE-2020-26146 DEFINITELY impact their
wifi chipsets, while CVE-2020-26142 and CVE-2020-26144 MAY impact their
devices.

They have since released updated firmwares to mitigate those security
issues. They appear to already be upstream:
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/log/cypress

https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/commit/cypress?id=f97e316775237ca5d46a4bc0614a3073ebec5a9e

Please provided updated packages for sid and bullseye, if possible (I
understand that non-free doesn't necessarily get security updates). I
don't know if they changed anything else, but I'm happy to test out a
security update package on my Pi 4b (which uses the 43455-sdio blob) if
it's helpful for a bullseye update.

Bug#991967: linux-src 4.19.194-3 breaks Xen Dom0 powerdown and reboot

[Elliott Mitchell]

Package: src:linux
Version: 4.19.194-3
Control: affects -1 src:xen

SSIA.  Previous versions of 4.19 had no issues (4.19.181-1 according to
notes), but this cropped up with 4.19.194-3 (-1 and -2 weren't tested).

When a Xen domain 0 tries to reboot or powerdown the computer, it hangs
with the display off, but the power supply is active.

I'm rebuilding from source, so I imagine this also effects
linux-image-4.19.0-17-amd64.

Seems .194 caused multiple problems for Xen given 990642.


-- 
(\___(\___(\__  --=> 8-) EHM <=--  __/)___/)___/)
 \BS (| ehem+sig...@m5p.com  PGP 87145445 |)   /
  \_CS\   |  _  -O #include  O-   _  |   /  _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445

Bug#991966: hunspell-an: Change upstream to libreoffice-dictionaries

[Dimitrij Mijoski]

Package: hunspell-an
Version: 0.2-4
Severity: normal

The current package shows a Firefox extension as Homepage (and probably
upstream). This is not a very good upstream. The Aragonese dictionary is
unmaintained (no updates since 2011) and it has no real upstream. It would be
best to use https://cgit.freedesktop.org/libreoffice/dictionaries/ as
upstream and https://packages.debian.org/source/sid/libreoffice-dictionaries as
source package.

Why this should be done? Because there are certain bugs with the dictionary and
the libreoffice repository is the only place where the bug can be fixed. I
certanly can not fix it in the Firefox extension [1] or the Libreoffice
extension [2].

[1]: https://addons.mozilla.org/mk/firefox/addon/corrector-ortografico-
aragones/
[2]: https://extensions.libreoffice.org/en/extensions/show/corrector-
ortografico-aragones

The LibreOffice extension, the Firefox extension and  the Libreoffice
collection all provide exactly the same files, no information will be lost with
this transition.

Bug#991959: /bin/bash: Built-in default path contains cwd

[Salvatore Bonaccorso]

Control: forcemerge 781367 991959

Hi Ian,

On Fri, Aug 06, 2021 at 06:39:21PM +0100, Ian Jackson wrote:
> Package: bash
> Version: 5.1-3
> Severity: important
> File: /bin/bash
> Tags: security
> 
> Observed behaviour:
> 
> $ env - bash -c 'echo $PATH'
> /usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/bin:/sbin:.
> $ 
> 
> Expected behaviour:
> 
> $ env - bash -c 'echo $PATH'
> /usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/bin:/sbin
> $ 
> 
> dash gets this right.  Tagging this "important" because having . on
> the path is a security hazard which we mostly got rid of everywhere.
> 
> Having . come back in unusual situations where bash makes up the PATH
> is quite unexpected and surely not desirable.

I guess we can merge this one with #781367, doing so now.

Regards,
Salvatore

Bug#991965: gpac: CVE-2021-36584

[Salvatore Bonaccorso]

Source: gpac
Version: 1.0.1+dfsg1-4
Severity: important
Tags: security upstream
Forwarded: https://github.com/gpac/gpac/issues/1842
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for gpac.

CVE-2021-36584[0]:
| An issue was discovered in GPAC 1.0.1. There is a heap-based buffer
| overflow in the function gp_rtp_builder_do_tx3g function in
| ietf/rtp_pck_3gpp.c, as demonstrated by MP4Box. This can cause a
| denial of service (DOS).


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-36584
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-36584
[1] https://github.com/gpac/gpac/issues/1842

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#991964: libgtk-4-1: the cause of apt-file search /usr/share/doc/@SHARED_PKG@

[Patrice Duroux]

Package: libgtk-4-1
Version: 4.3.1+ds-2
Severity: minor

Dear Maintainer,

I do not know if it is a consequence to solve #985418, but with this update I
got the following on my system:

$ apt-file search /usr/share/doc/@SHARED_PKG@
libgtk-4-1: /usr/share/doc/@SHARED_PKG@/@NEWS@
libgtk-4-1: /usr/share/doc/@SHARED_PKG@/@README.md@

$ apt-file search /usr/share/doc/@BIN_PKG@
libgtk-4-bin: /usr/share/doc/@BIN_PKG@/@NEWS@
libgtk-4-bin: /usr/share/doc/@BIN_PKG@/@README.md@

Thanks,
Patrice


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

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

Versions of packages libgtk-4-1 depends on:
ii  adwaita-icon-theme40.1.1-1
ii  hicolor-icon-theme0.17-2
ii  libc6 2.31-13
ii  libcairo-gobject2 1.16.0-5
ii  libcairo-script-interpreter2  1.16.0-5
ii  libcairo2 1.16.0-5
ii  libcolord21.4.5-3
ii  libcups2  2.3.3op2-3+deb11u1
ii  libepoxy0 1.5.5-1
ii  libfontconfig12.13.1-4.2
ii  libfribidi0   1.0.8-2
ii  libgdk-pixbuf-2.0-0   2.42.6+dfsg-1
ii  libglib2.0-0  2.68.3-1
ii  libgraphene-1.0-0 1.10.4+dfsg1-1
ii  libgtk-4-common   4.3.1+ds-2
ii  libharfbuzz0b 2.7.4-1
ii  libjson-glib-1.0-01.6.2-1
ii  libpango-1.0-01.48.7+ds1-2
ii  libpangocairo-1.0-0   1.48.7+ds1-2
ii  libpangoft2-1.0-0 1.48.7+ds1-2
ii  librest-0.7-0 0.8.1-1.1
ii  libvulkan11.2.162.0-1
ii  libwayland-client01.19.0-2
ii  libwayland-egl1   1.19.0-2
ii  libx11-6  2:1.7.2-1
ii  libxcomposite11:0.4.5-1
ii  libxcursor1   1:1.2.0-2
ii  libxdamage1   1:1.1.5-2
ii  libxext6  2:1.3.3-1.1
ii  libxfixes31:5.0.3-2
ii  libxi62:1.7.10-1
ii  libxinerama1  2:1.1.4-2
ii  libxkbcommon0 1.0.3-2
ii  libxrandr22:1.5.1-1
ii  shared-mime-info  2.1-1

Versions of packages libgtk-4-1 recommends:
ii  iso-codes4.6.0-1
ii  libgtk-4-bin 4.3.1+ds-2
ii  librsvg2-common  2.50.7+dfsg-1

Versions of packages libgtk-4-1 suggests:
ii  gvfs  1.47.91-1
pn  libgtk-4-media-gstreamer | libgtk-4-media-ffmpeg  

Bug#991963: pinentry-gnome3: hitting ENTER not equal to clicking "OK" icon

[Per Gunnarsson]

Package: pinentry-gnome3
Version: 1.1.0-4
Severity: wishlist
Tags: newcomer

Dear Maintainer,

Hitting ENTER not with equal result as clicking "OK" icon when using for 
example gpg may cause unnecessary (?) paranoia

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

Kernel: Linux 5.10.0-7-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=sv_SE.UTF-8, LC_CTYPE=sv_SE.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 pinentry-gnome3 depends on:
ii  gcr  3.38.1-2
ii  libassuan0   2.5.3-7.1
ii  libc62.31-13
ii  libgcr-base-3-1  3.38.1-2
ii  libglib2.0-0 2.66.8-1
ii  libgpg-error01.38-2
ii  libncursesw6 6.2+20201114-2
ii  libsecret-1-00.20.4-2
ii  libtinfo66.2+20201114-2

Versions of packages pinentry-gnome3 recommends:
ii  dbus-user-session  1.12.20-2

Versions of packages pinentry-gnome3 suggests:
pn  pinentry-doc  

-- no debconf information

Bug#991962: src: prefix should work also with experimental source only

[Patrice Duroux]

Package: reportbug
Version: 7.10.3
Severity: wishlist

Dear Maintainer,

   * What led up to the situation?

$ reportbug src:gtk4

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

I would like to report a «bug» that affect both libgtk-4-bin and libgtk-4-1
(4.3.1+ds-2):

$ apt-file search /usr/share/doc/@BIN_PKG@
libgtk-4-bin: /usr/share/doc/@BIN_PKG@/@NEWS@
libgtk-4-bin: /usr/share/doc/@BIN_PKG@/@README.md@
$ apt-file search /usr/share/doc/@SHARED_PKG@
libgtk-4-1: /usr/share/doc/@SHARED_PKG@/@NEWS@
libgtk-4-1: /usr/share/doc/@SHARED_PKG@/@README.md@


   * What was the outcome of this action?

W: Unable to locate package gtk4

   * What outcome did you expect instead?

The same as reportbug src:gtk+3.0 for instance.


Thanks,
Patrice


-- Package-specific info:
** Environment settings:
INTERFACE="gtk"

** /home/patrice/.reportbugrc:
email "patrice.dur...@gmail.com"
realname "Patrice Duroux"
ui gtk
smtphost smtp.orange.fr

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

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

Versions of packages reportbug depends on:
ii  apt2.2.4
ii  python33.9.2-3
ii  python3-reportbug  7.10.3
ii  sensible-utils 0.0.14

reportbug recommends no packages.

Versions of packages reportbug suggests:
pn  claws-mail 
pn  debconf-utils  
pn  debsums
pn  dlocate
pn  emacs-bin-common   
ii  exim4-daemon-light [mail-transport-agent]  4.94.2-7
ii  file   1:5.39-3
ii  gnupg  2.2.27-2
pn  python3-urwid  
pn  reportbug-gtk  
ii  xdg-utils  1.1.3-4.1

Versions of packages python3-reportbug depends on:
ii  apt2.2.4
ii  file   1:5.39-3
ii  python33.9.2-3
ii  python3-apt2.2.1
ii  python3-debian 0.1.39
ii  python3-debianbts  3.1.0
ii  python3-requests   2.25.1+dfsg-2
ii  sensible-utils 0.0.14

python3-reportbug suggests no packages.

-- no debconf information

Bug#991958: /usr/bin/linux.uml: consoles do not work if they are read for reading at startup

[Ian Jackson]

Control: found -1 5.10um3

I repro'd this on sid, but I ran reportbug in my buster environment.
I forgot to change the version in the report.

-- 
Ian JacksonThese opinions are my own.  

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

Bug#987277: closing 991705

[Salvatore Bonaccorso]

Control: reopen 991705
Control: retitle 991705 exiv2: CVE-2021-29457
Control: found 991705 0.27.3-3
Control: found 991705 0.25-4
Control: forwarded 991705 https://github.com/Exiv2/exiv2/issues/1529
Control: retitle 987277 CVE-2021-29458
Control: forwarded 987277 https://github.com/Exiv2/exiv2/issues/1530

On Fri, Aug 06, 2021 at 07:53:07PM +0200, Salvatore Bonaccorso wrote:
> close 991705 
> thanks
> 
> This is a duplicate of CVE-2021-29457 and already covered in #987277.

actually given the bugnumber will be used in an exiv2 update already
pending let's just associate it with CVE-2021-29457.

Regards,
Salvatore

Bug#991958: /usr/bin/linux.uml: consoles do not work if they are read for reading at startup

[Ian Jackson]

Control: title -1 /usr/bin/linux.uml: consoles do not work if they are ready 
for reading at startup

-- 
Ian JacksonThese opinions are my own.  

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

Bug#991961: golang-1.15: CVE-2021-36221

[Salvatore Bonaccorso]

Source: golang-1.15
Version: 1.15.9-6
Severity: important
Tags: security upstream
Forwarded: https://github.com/golang/go/issues/46866
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for golang-1.15.

CVE-2021-36221[0]:
| net/http: panic due to racy read of persistConn after handler panic

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-36221
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-36221
[1] https://github.com/golang/go/issues/46866

Regards,
Salvatore

Bug#991960: /usr/bin/psusan: psusan example ends up with . on PATH due to #991959

[Ian Jackson]

Package: putty-tools
Version: 0.75-3
Severity: normal
File: /usr/bin/psusan

psusan(1) suggests this:

   And the setup script uml-psusan.sh might look like this:

   #!/bin/bash
   # Set up vital pseudo-filesystems
   mount -t proc none /proc
   mount -t devpts none /dev/pts
   # Redirect I/O to the serial port, but stderr to the console
   exec 0<>/dev/ttyS0 1>&0 2>/dev/console
   # Set the serial port into raw mode, to run a binary protocol
   stty raw -echo
   # Choose what shell you want to run inside psusan
   export SHELL=/bin/bash
   # And now run psusan over the serial port
   exec /home/simon/src/putty/misc/psusan

This sets SHELL.  It does not set PATH.  Due to #991959, the PATH
ends up set to
  /usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/bin:/sbin:.
ie with cwd at the end.  This is quite undesirable.

I think it would be best to change the example to explicitly set PATH
to avoid this bug.  CCing upstream since even when bash is fixed in
Debian sid, the upstream manpage probably wants to have this
workaround indefinitely.

(I am using psusan from a .deb I built myself from the sid sources, so
the version number in this bug report ought really to refer to
src:putty but that seems more confusing than helpful.)

Thanks,
Ian.

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

Kernel: Linux 5.6.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages putty-tools depends on:
ii  libc6  2.28-10

putty-tools recommends no packages.

Versions of packages putty-tools suggests:
ii  putty-doc  0.75-3

-- no debconf information

Bug#991959: /bin/bash: Built-in default path contains cwd

[Ian Jackson]

Package: bash
Version: 5.1-3
Severity: important
File: /bin/bash
Tags: security

Observed behaviour:

$ env - bash -c 'echo $PATH'
/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/bin:/sbin:.
$ 

Expected behaviour:

$ env - bash -c 'echo $PATH'
/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/bin:/sbin
$ 

dash gets this right.  Tagging this "important" because having . on
the path is a security hazard which we mostly got rid of everywhere.

Having . come back in unusual situations where bash makes up the PATH
is quite unexpected and surely not desirable.


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

Kernel: Linux 5.6.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages bash depends on:
ii  base-files   10.3+deb10u10
ii  debianutils  4.8.6.1
ii  libc62.28-10
ii  libtinfo66.1+20181013-2+deb10u2

Versions of packages bash recommends:
pn  bash-completion  

Versions of packages bash suggests:
pn  bash-doc  

-- no debconf information

Bug#991958: /usr/bin/linux.uml: consoles do not work if they are read for reading at startup

[Ian Jackson]

Package: user-mode-linux
Version: 4.19-1um-1+deb10u1+b1
Severity: normal
File: /usr/bin/linux.uml
Tags: upstream


CCing putty@p.d.o because this makes the user-mode-linux example in
the psusan manpage not work.


Steps to reproduce:

Put the attached scripts "psusan-uml" and "psusan-uml-inside" in
a directory and make them executable.

Run ./psusan-uml in a terminal.

Wait for the inital "read(0, " (from strace cat) to appear.
Type something.


Observed behaviour:

Nothing happens.  The input is not read.  Pressing ^D will terminate
the session, but the inner cat never sees the input.


Expected behaviour:

cat reads what you type and you see it appear in strace, and be
echoed.


Workaround:

Arrange not to write anything into linux.uml until some output has
appeared.  That seems to work OK for me, leading me to think it's not
a general lossage bug, but only happens if there is input to be read
when linux.uml starts up its consoles.


Notes:

Commenting out "echo initial" makes it work, showing that this is a
race.

The |cat at the end is because linux.uml sets the fds it is using for
a console to nonblocking.  cat objects to that.  So we pipe the stdout
too, so that linux.uml does not set the actual tty to nonblocking.



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

Kernel: Linux 5.6.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages user-mode-linux depends on:
ii  libc6  2.28-10

Versions of packages user-mode-linux recommends:
ii  uml-utilities  20070815.2-1

Versions of packages user-mode-linux suggests:
ii  pterm [x-terminal-emulator]   0.75-3
pn  rootstrap 
pn  slirp 
pn  user-mode-linux-doc   
pn  vde2  
ii  xfce4-terminal [x-terminal-emulator]  0.8.7.4-2
ii  xterm [x-terminal-emulator]   344-1+deb10u1

-- no debconf information
#!/bin/bash

stty=`stty -g`
trap 'stty "$stty"' 0

(
 echo initial
 cat
) | \
 bwrap --dev-bind / / --tmpfs /dev/shm \
 linux.uml rootfstype=hostfs rootflags=/ rw \
 con=fd:0,fd:1 \
 init=$PWD/psusan-uml-inside 2>&1 \
| cat
#!/bin/bash
# Set up vital pseudo-filesystems
set -x
mount -t proc none /proc
exec 3<>/dev/tty1
stty raw -echo <&3
echo $PATH
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
export PATH
stty -a >&2
strace cat

Bug#991957: /usr/bin/linux.uml: Checking PROT_EXEC mmap in /dev/shm...Operation not permitted

[Ian Jackson]

Package: user-mode-linux
Version: 5.10um3
Severity: normal
File: /usr/bin/linux.uml

Observed behaviour:

$ linux.uml 
Core dump limits :
soft - 0
hard - NONE
Checking that ptrace can change system call numbers...OK
Checking syscall emulation patch for ptrace...OK
Checking advanced syscall emulation patch for ptrace...OK
Checking environment variables for a tempdir...none found
Checking if /dev/shm is on tmpfs...OK
Checking PROT_EXEC mmap in /dev/shm...Operation not permitted
/dev/shm must be not mounted noexec
$ 

Expected behaviour: it works, without me having to reconfigure
/dev/shm to a less-secure configuration.

Workaround:

bwrap --dev-bind / / --tmpfs /dev/shm linux.uml ...

FYI I first encountered this with uml from buster,
  4.19-1um-1+deb10u1+b1
but the bug is in sid too.


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

Kernel: Linux 5.6.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages user-mode-linux depends on:
ii  libc6  2.28-10

Versions of packages user-mode-linux recommends:
ii  uml-utilities  20070815.2-1

Versions of packages user-mode-linux suggests:
ii  pterm [x-terminal-emulator]   0.75-3
pn  rootstrap 
pn  slirp 
pn  user-mode-linux-doc   
pn  vde2  
ii  xfce4-terminal [x-terminal-emulator]  0.8.7.4-2
ii  xterm [x-terminal-emulator]   344-1+deb10u1

-- no debconf information

Bug#991956: /usr/bin/linux.uml: Interactive use leaves invoking host terminal messed up

[Ian Jackson]

Package: user-mode-linux
Version: 5.10um3
Severity: minor
File: /usr/bin/linux.uml


Observed behaviour:

(build)root@zealot:/home/ian# stty -a; bwrap --dev-bind / / --tmpfs /dev/shm 
linux.uml init=/bin/date; stty -a
speed 38400 baud; rows 90; columns 127; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = 
; swtch = ; start = ^Q; stop = ^S;
susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; discard = ^O; min = 1; time = 0;
-parenb -parodd -cmspar cs8 -hupcl -cstopb cread -clocal -crtscts
-ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon -ixoff 
-iuclc -ixany -imaxbel iutf8
opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt 
echoctl echoke -flusho -extproc
Core dump limits :
soft - 0
hard - NONE
Checking that ptrace can change system call numbers...OK
Checking syscall emulation patch for ptrace...OK
Checking advanced syscall emulation patch for ptrace...OK
Checking environment variables for a tempdir...none found
Checking if /dev/shm is on tmpfs...OK
Checking PROT_EXEC mmap in /dev/shm...OK
Adding 27656192 bytes to physical memory to account for exec-shield gap
Linux version 5.10.40 (buildd@x86-csail-01) (gcc (Debian 10.2.1-6) 10.2.1 
20210110, GNU ld (GNU Binutils for Debian) 2.35.2) #1 Fri Jun 11 12:02:58 UTC 
2021
...
Please append a correct "root=" boot option; here are the available partitions:
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(98,0)
...
speed 38400 baud; rows 90; columns 127; line = 0;
 intr = ^C; quit = ^\; erase = 
^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start 
= ^Q; stop = ^S;
   susp = ^Z; rprnt = ^R; werase = 
^W; lnext = ^V; discard = ^O; min = 1; time = 0;

  -parenb -parodd -cmspar cs8 
-hupcl -cstopb cread -clocal -crtscts
-ignbrk -brkint 
-ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany 
-imaxbel iutf8
  -opost -olcuc -ocrnl onlcr -onocr 
-onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0

  -isig -icanon -iexten -echo echoe 
echok -echonl -noflsh -xcase -tostop -echoprt echoctl echoke -flusho -extproc

  (build)root@zealo(build)root@zealot:/home/ian# 


Expected behaviour:

Unless the process dies of a signal, it should restore the tty
settings.


Workaround:

"stty sane" afterwards, or make a wrapper that saves and restores the
settings eg with stty -g.


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

Kernel: Linux 5.6.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages user-mode-linux depends on:
ii  libc6  2.28-10

Versions of packages user-mode-linux recommends:
ii  uml-utilities  20070815.2-1

Versions of packages user-mode-linux suggests:
ii  pterm [x-terminal-emulator]   0.75-3
pn  rootstrap 
pn  slirp 
pn  user-mode-linux-doc   
pn  vde2  
ii  xfce4-terminal [x-terminal-emulator]  0.8.7.4-2
ii  xterm [x-terminal-emulator]   344-1+deb10u1

-- no debconf information

Bug#991955: lintian: Check for incorrect Maintainer/Uploader fields for known packaging teams

[Louis-Philippe Véronneau]

Package: lintian
Version: 2.104.0
Severity: wishlist

Dear maintainers,

There is currently code in lib/Lintian/Check/Fields/Maintainer/Team.pm
to check if a team-maintained package ends up in the wrong team.

It would be nice if it were possible to issue another tag when a
team-maintained package uses the wrong email contact, or has the right
email contact but the wrong name.

For example, mathlibtools was recently uploaded to NEW [1] as part of
the Python Team, but used the wrong email contact
( instead of the correct
).

I'm sure that kind of mistake happens all the time and it would be nice
to be able to lint for it.

If code is added for this new tag, I'd be happy to scour the archive and
provide you with a list of the many teams in Debian.

Cheers,

[1]: https://ftp-master.debian.org/new/mathlibtools_1.0.0-1.html

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

Bug#991954: /usr/bin/openstack: no man page. Please add python-openstackclient-doc as a Recommends to python3-openstackclient

[Louis-Philippe Véronneau]

Package: python3-openstackclient
Version: 5.4.0-4
Severity: normal

Dear maintainers,

When installing python3-openstackclient, the python-openstackclient-doc
package is not installed. This results in /usr/bin/openstack not having
a man page by default and isn't great UX.

Would it be possible to add an explicit Recommends on
python-openstackclient-doc for python3-openstackclient? That way most
people would also get a man page when they install the openstack client.

Cheers,

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

Bug#991953: golang-github-google-martian-dev: Package github.com/google/martian/v3

[Peymaneh Nejad]

Package: golang-github-google-martian-dev
Version: 2.1.0+git20181219.d0b5ad3-3
Severity: normal

Hi,

I need to update another package[1] that requires github.com/google/martian/v3

I'll prepare a release on debian/experimental branch on salsa for a team
upload to experimental so I can go on with the other package, let me know when
there is issues with that.

kind regards,

peymaneh

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

Bug#991950: postfix.postinst fails if /e/resolv.conf contains `search .`

[Paride Legovini]

Control: tags -1 + patch

I submitted this MP with a fix:

https://salsa.debian.org/postfix-team/postfix-dev/-/merge_requests/12

Cheers!

Paride

Bug#991952: Acknowledgement (chardet test suite has problematic license)

[Gernot Hillier]

I also filed an upstream bug on this: 
https://github.com/chardet/chardet/issues/231

Bug#991945: refind: debian netinst (bullseye): refind fails to install

[Marc Leeman]

Great catch!  Shouldn't the script also take care of unmounting these
> if it's the one who mounted them, though?  (It makes the logic a bit
> more complex, but seems like the "right" solution to me.)
>
> I've also added Rod explicitly to CC here, since this is really an
> upstream rEFInd bug (and his opinion on it might differ from mine!).
> :)
>
>
The new refind also needs the '/' to point to ESP files (this was not the
case for the buster variant).

On your question of unmounting; it depends on your point of view. Normally
these partitions are already mounted so a I assumed they always need to be
mounted. That's why there is an || after an attempt to mount.

You could also unmount them again after using the refind-install; but then
other scripts that might delete entries with efibootmgr need to mount this
themselves.



-- 
g. Marc

Bug#991950: postfix.postinst fails if /e/resolv.conf contains `search .`

[Paride Legovini]

Source: postfix
Version: postinst fails if /e/resolv.conf search domain starts with a "."
Severity: normal
X-Debbugs-Cc: par...@debian.org

Dear Postfix maintainers,

When the /etc/resolv.conf search domain considered by postfix.postinst
to configure postfix as an "Internet site" (the default debconf option),
e.g.:

  search .example.com

the installation fails with:


Running newaliases
newaliases: warning: valid_hostname: misplaced delimiter: 
debian-sid..example.com
newaliases: fatal: file /etc/postfix/main.cf: parameter myhostname: bad 
parameter value: debian-sid..example.com
dpkg: error processing package postfix (--configure):
 installed postfix package post-installation script subprocess returned error 
exit status 75
Processing triggers for man-db (2.9.4-2) ...
Errors were encountered while processing:
 postfix
E: Sub-process /usr/bin/dpkg returned an error code (1)


Note the double dot in "debian-sid..example.com". Having domain start
with a dot is not explicitly mentioned by resolv.conf(5), but the syntax
is accepted by the glibc resolver, see:

https://sourceware.org/git/?p=glibc.git;a=blob;f=resolv/res_query.c;h=ebbe5a6a4ed86abe3fccd4a134bfcf6f613c9bbb;hb=HEAD#l385

(thanks sergiodj@d.o for digging this up).

The postfix.postinst file should tolerate those domains and strip off
leading dots, as the glibc resolver does:

https://sourceware.org/git/?p=glibc.git;a=blob;f=resolv/res_query.c;h=ebbe5a6a4ed86abe3fccd4a134bfcf6f613c9bbb;hb=HEAD#l411

The above was verified on an up-to-date Sid system with postfix 3.5.6-1+b1.

Paride

Bug#991952: chardet test suite has problematic license

[Gernot Hillier]

Source: chardet
Version: 4.0.0-1

During licensing checks of the "chardet" sources, we identified 
problematic files in tests/. In general, tests/README.txt states:


[...]
These test feeds were downloaded from random sites while I was
developing the Universal Encoding Detector. Each feed is copyright its
respective publisher.
[...]

It doesn't seem these files are included in the `python3-chardet` Debian 
binary package, but they are still distributed by Debian as part of 
http://deb.debian.org/debian/pool/main/c/chardet/chardet_4.0.0.orig.tar.gz.

Bug#991951: debian-installer: Text installer sporadically hangs when using 512 - 1024 MB of memory.

[Witold Baryluk]

Package: debian-installer
Severity: important

https://www.debian.org/releases/bullseye//amd64/ch03s04.en.html says this 
should be supported.

But when using 512 MB of memory in text mode (which triggers low memory mode),
or even 1024 MB of memory, makes it be stuck.

Using multi-arch image for testing.

wget 
https://cdimage.debian.org/cdimage/daily-builds/daily/arch-latest/multi-arch/iso-cd/debian-testing-amd64-i386-netinst.iso

(image from 2021-08-06 11:00)

qemu-system-x86_64 --enable-kvm -cdrom debian-testing-amd64-i386-netinst.iso -m 
1024

Select "Install" (text installer, not graphical one).

Select defaults (or other) for language, location and keyboard.

Let it load installer components.

It will sometimes load, but more often than not, if you start again from
scratch, it will hang somewhere forever. For my the failure ratio is
about 90%.

PS. Curiously, Graphical installer works just fine with 1024 MB of memory.

Regards,
Witold

Bug#991945: refind: debian netinst (bullseye): refind fails to install

[Tianon Gravi]

On Fri, 6 Aug 2021 at 06:42, Marc Leeman  wrote:
> I am using refind with an netinst installer. Since bullseye this seems
> broken because sysfs/efivarfs is no longer mounted by default in the
> target and efibootmgr fails
>
> I've tested this patch on my side (simply trying to mount sys/efivarfs
> before efibootmgr and this seems to work.
>
> For completeness, I added such a mount in the postinst, but that one
> was not enough to fix the installation.
>
> https://salsa.debian.org/den_erpel-guest/refind/-/blob/debian/televic/bullseye/unstable/debian/patches/bullseye-efivarfs.patch
>
>
> https://salsa.debian.org/den_erpel-guest/refind/-/tree/debian/televic/bullseye/unstable
>
> If you want a clean MR, just let me know

Great catch!  Shouldn't the script also take care of unmounting these
if it's the one who mounted them, though?  (It makes the logic a bit
more complex, but seems like the "right" solution to me.)

I've also added Rod explicitly to CC here, since this is really an
upstream rEFInd bug (and his opinion on it might differ from mine!).
:)

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

Bug#991949: xuxen-eu-spell: New upstream version 5.1

[Dimitrij Mijoski]

Source: xuxen-eu-spell
Version: 0.5.20151110-5
Severity: normal

Dear Maintainer,

New uptream version is avaliable, see here http://xuxen.eus/eu/deskargatu .
Direct link: http://xuxen.eus/static/hunspell/xuxen_5.1_hunspell.zip

Bug#991948: RFP: virtualbox-completion -- Bash completion support for VirtualBox management utility

[Eugene Kilachkoff]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: ekilachk...@gmail.com

* Package name: virtualbox-completion
  Version : 6.1.22
  Upstream Author : Roman Dobosz 
* URL : https://github.com/gryf/vboxmanage-bash-completion
* License : BSD-3-Clause
  Programming Lang: bash
  Description : Bash completion support for VirtualBox management utility

Bash completion support for VirtualBox's VBoxManage CLI.

Would be nice if this could be suggested by virtualbox packages.
VBoxManage is a ton of switches and commands (some of them are
not even in GUI) that are difficult to remember, so this is
indispensable for advanced usage.

Technically this tool supports only VBoxManage. I'm proposing
a virtualbox-completion name so it is easier to find.

Bug#991921: linux: Please enable CPUFREQ options for RPi 0/0w/1

[Diederik de Haas]

Hi,

On vrijdag 6 augustus 2021 15:14:26 CEST Uwe Kleine-König wrote:
> On Thu, Aug 05, 2021 at 05:26:09PM +, Diederik de Haas wrote:
> > https://salsa.debian.org/raspi-team/image-specs/-/issues/7#note_206349
> > 
> > So I build my own kernel with the following patch:
> > +CONFIG_CLK_RASPBERRYPI=y
> 
> Would CONFIG_CLK_RASPBERRYPI=m be enough?

Maybe. I haven't tried that. I 'copied' what was done for arm64 and armhf in
https://salsa.debian.org/kernel-team/linux/-/commit/7dc3d9453272836a9571c30b9776a85a5e41c657
https://salsa.debian.org/kernel-team/linux/-/commit/c4ab143979cc30c395251a48ba6b5b8969973b70

If I grep on CLK on configs on my amd64 machine and various RPi's, 
then they all have '=y' on them, so it appears to be the standard/norm.

> > +CONFIG_CPUFREQ_DT=m
> > +CONFIG_CPUFREQ_DT_PLATDEV=y
> > +CONFIG_ARM_RASPBERRYPI_CPUFREQ=m
> 
> These look reasonable.
> 
> > -CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE=y
> > +# CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE is not set
> > -# CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND is not set
> > +CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND=y
> > -CONFIG_CPU_FREQ_GOV_ONDEMAND=m
> > +CONFIG_CPU_FREQ_GOV_ONDEMAND=y
> 
> Hmm, CONFIG_CPU_FREQ_GOV_ONDEMAND=m is already there, so you should be
> able to switch to that if you prefer it?!

Yes, afaik it isn't needed.
I did notice that there are 2 schedulers which are often used as default,
namely 'performance' and 'schedutil' and those are also builtin.
That's the reason I made 'ondemand' builtin as well, but it's entirely 
possible that correlation != causation and I inferred 
an incorrect 'conclusion'.

Trying to find why 'performance' and 'schedutil' were builtin, resulted in
https://salsa.debian.org/kernel-team/linux/-/commit/e5b976c268e44d452bc5ae23b765eab26c4409ae
which suggest the (sole) reason that it got builtin is that it couldn't be
modular in 4.9. That can very well have changed since.
It could be that 'performance' and 'schedutil' can now also be done as
modules, but that's outside the scope of this bug report.
And I don't think I'm qualified to make an informed choice/change on this.

Cheers,
  Diederik

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

Bug#984928: Acknowledgement (slurmctld: fails to start on reboot)

[David Bremner]

David Bremner  writes:

> As a workaround, I noticed that setting the main ethernet interface to
> "auto" instead of "allow-hotplug" seems to fix the problem. By way of
> confirmation, on a different (virtual) machine changing the "auto" to
> "allow-hotplog" on the main ethernet interface causes the same problem
> to manifest.
>
> This is still a bit mysterious, since the messages complain about
> 127.0.0.1 which is of course the loopback interace, already marked
> "auto", and presumably up pretty early.

I think (one) underlying problem is that the systemd unit file for
slurmctld is incorrect. The details are in [1], but it seems like
network.target is not correct (I think it very rarely is a useful
target).  I added the following

# /etc/systemd/system/slurmctld.service.d/override.conf
[Unit]
After=network-online.target munge.service
Wants=network-online.target

And it seems to help. I didn't check if the second mention of
munge.service is really needed.

I've switched to systemd-networkd on the hosts in question, so I can't
easily test how this works with ifupdown, but I notice ifupdown provides

/lib/systemd/system/ifupdown-wait-online.service

which (guessing based on the name) should provide similar functionality
to those documented in [1] for NetworkManager and systemd-networkd.

[1]: https://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/

Bug#991947: apt-setup: Consider adding $codename-updates configuration to /etc/apt/sources.list (if available even if yet $codename is testing)

[Salvatore Bonaccorso]

Source: apt-setup
Version: 1:0.166
Severity: wishlist
Tags: d-i
X-Debbugs-Cc: car...@debian.org

Dear Debian Install System Team,

When installing bullseye with the current RC3 I noticed that while the
debconf menu suggests (and has selected) to add release updates suites
($codename-updates) to the sources.list in case when bullseye is yet
testing, they are not added via generators/92updates because
generators/90services-select in case of the suite not beeng stable or
odstable, does not select it:

updates=y
if [ "$suite" != stable ] && [ "$suite" != oldstable ]; then
disable_service updates || true
updates=n
fi

I wonder if this could be handled in times before a stable release is
planned, and the suite is already present on the mirrors (this is at
some time before a stable release prepartion when release team starts to
interact with infrastructure teams I think to setup what is needed for
the next stable release)

The reason I ask this, is that the coverage would be bigger for people
having it in the sources.list if they install it in time shortly before
a stable release is released, and we strongly rely on updates to be
possible to push via the stable-updates mechanism, see for instance
https://lists.debian.org/debian-stable-announce/2021/06/msg1.html ?

Cyril mentioned two ideas how this can be done. Either having a flag
which can be enabled one we switch from an Alpha  to some RC Release for
d-i once the installer matured enough and infrastructure is set up in
perspective of a future stable release.

One other alternative would be to do an online test if the suite is
already present and only add it in that case.

What do you think of this idea? If you think it's nonsense, feel free to
mark it straight as wontfix and close it.

Regards,
Salvatore

Bug#991946: cython: Much newer version available

[Stephen Quinney]

Source: cython
Severity: wishlist
X-Debbugs-Cc: step...@jadevine.org.uk

Dear Maintainer,

The current packaged version of Cython is 0.29.14 which was released
in November 2019. Since then there have been 10 bug fix releases with
the latest being 0.29.24 which came out in July 2021. I would so much
appreciate it if you could find the time to update your Debian package.

Thanks so much for your packaging efforts,

Stephen Quinney

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

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

Bug#991945: refind: debian netinst (bullseye): refind fails to install

[Marc Leeman]

Package: refind
Version: 0.12.0-2~televic11+3
Severity: normal

Dear Maintainer,

I am using refind with an netinst installer. Since bullseye this seems
broken because sysfs/efivarfs is no longer mounted by default in the
target and efibootmgr fails

I've tested this patch on my side (simply trying to mount sys/efivarfs
before efibootmgr and this seems to work.

For completeness, I added such a mount in the postinst, but that one
was not enough to fix the installation.

https://salsa.debian.org/den_erpel-guest/refind/-/blob/debian/televic/bullseye/unstable/debian/patches/bullseye-efivarfs.patch


https://salsa.debian.org/den_erpel-guest/refind/-/tree/debian/televic/bullseye/unstable

If you want a clean MR, just let me know


-- System Information:
Debian Release: bullseye/sid
  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-4-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 refind depends on:
ii  debconf [debconf-2.0]  1.5.75
ii  efibootmgr 17-1
ii  gdisk  1.0.6-1.1
ii  openssl1.1.1k-1

Versions of packages refind recommends:
ii  python3 3.9.2-2
ii  sbsigntool  0.9.2-2

refind suggests no packages.

-- debconf information:
* refind/install_to_esp: true


-- 
g. Marc

Bug#991921: linux: Please enable CPUFREQ options for RPi 0/0w/1

[Uwe Kleine-König]

Hello,

On Thu, Aug 05, 2021 at 05:26:09PM +, Diederik de Haas wrote:
> At
> https://salsa.debian.org/raspi-team/image-specs/-/issues/7#note_206349
> it was reported that CPU frequency scaling was enabled for armhf and
> arm64, but not for armel. I (and others) have been able to confirm that.
> 
> So I build my own kernel with the following patch:
> +CONFIG_CLK_RASPBERRYPI=y

Would CONFIG_CLK_RASPBERRYPI=m be enough?

> +CONFIG_CPUFREQ_DT=m
> +CONFIG_CPUFREQ_DT_PLATDEV=y
> +CONFIG_ARM_RASPBERRYPI_CPUFREQ=m

These look reasonable.

> -CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE=y
> +# CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE is not set
> -# CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND is not set
> +CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND=y
> -CONFIG_CPU_FREQ_GOV_ONDEMAND=m
> +CONFIG_CPU_FREQ_GOV_ONDEMAND=y

Hmm, CONFIG_CPU_FREQ_GOV_ONDEMAND=m is already there, so you should be
able to switch to that if you prefer it?!

Best regards
Uwe

-- 
Pengutronix e.K.   | Uwe Kleine-König|
Industrial Linux Solutions | https://www.pengutronix.de/ |


signature.asc
Description: PGP signature

Bug#954093: desktop-base: Integration with KDE Plasma on Debian 11 no longer works

[Cyril Brulebois]

Hi,

Laura Arjona Reina  (2021-08-06):
> Package: desktop-base
> Version: 11.0.3
> Followup-For: Bug #954093
> 
> Dear Maintainer,
> 
> I've just installed a PC with KDE Plasma desktop task using the Debian
> 11 installer RC3 and this bug is still present.
> 
> My computer is all HomeWorld-themed except the desktop wallpaper (I
> got the "Shells" one).
> 
> I could change it to HomeWorld successfully with right click,
> "Configure Desktop and Wallpaper", and choosing the "Homeworld"
> wallpaper.
> 
> But I was expecting that the Debian theme wallpaper was shown directly
> after install.
> 
> I have checked the .js script and looks the same as the first reporter
> informed, and also checked if there's a debian-theme as suggested but
> it isn't.

loop += debian-kde@ in case they can offer some help regarding this
issue which affects their desktop environment.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#991944: texlive-binaries: man pages: typo in etex, pdftex, aleph and mf pages

[Antanas Vaitkus]

Package: texlive-binaries
Version: 2018.20181218.49446-1
Severity: minor

Dear Maintainer,

Description of the '--output-directory' option in the man pages
of etex, pdftex, aleph and mf contains:

<...> in directory first, the along the normal <...>

instead of

<...> in directory first, then along the normal <...>



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

Kernel: Linux 4.19.0-16-amd64 (SMP w/1 CPU core)
Kernel taint flags: TAINT_CRAP
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages texlive-binaries depends on:
ii  dpkg  1.19.7
ii  libbrotli11.0.7-2+deb10u1
ii  libc6 2.28-10
ii  libcairo2 1.16.0-4+deb10u1
ii  libfontconfig12.13.1-2
ii  libfreetype6  2.9.1-3+deb10u2
ii  libgcc1   1:8.3.0-6
ii  libgmp10  2:6.1.2+dfsg-4
ii  libgraphite2-31.3.13-7
ii  libgs99.27~dfsg-2+deb10u4
ii  libharfbuzz-icu0  2.3.1-1
ii  libharfbuzz0b 2.3.1-1
ii  libice6   2:1.0.9-2
ii  libicu63  63.1-6+deb10u1
ii  libkpathsea6  2018.20181218.49446-1
ii  libmpfr6  4.0.2-1
ii  libpaper1 1.1.28
ii  libpixman-1-0 0.36.0-1
ii  libpng16-16   1.6.36-6
ii  libpotrace0   1.15-1
ii  libptexenc1   2018.20181218.49446-1
ii  libsm62:1.2.3-1
ii  libstdc++68.3.0-6
ii  libsynctex2   2018.20181218.49446-1
ii  libteckit02.5.8+ds2-5
ii  libtexlua52   2018.20181218.49446-1
ii  libtexlua53   2018.20181218.49446-1
ii  libtexluajit2 2018.20181218.49446-1
ii  libwoff1  1.0.2-1
ii  libx11-6  2:1.6.7-1+deb10u2
ii  libxaw7   2:1.0.13-1+b2
ii  libxext6  2:1.3.3-1+b2
ii  libxi62:1.7.9-1
ii  libxmu6   2:1.1.2-2+b3
ii  libxpm4   1:3.5.12-1
ii  libxt61:1.1.5-1+b3
ii  libxxhash00.6.5-2
ii  libzzip-0-13  0.13.62-3.2
ii  perl  5.28.1-6+deb10u1
ii  t1utils   1.41-3
ii  tex-common6.11
ii  zlib1g1:1.2.11.dfsg-1

Versions of packages texlive-binaries recommends:
ii  texlive-base  2018.20190227-2

texlive-binaries suggests no packages.

-- no debconf information

Bug#991941: attaching dmesg and lspci output

[Laura Arjona Reina]

I'm attaching the dmesg and lspci output for the case they are useful.
Kind regards
-- 
Laura Arjona Reina
https://wiki.debian.org/LauraArjona
Sent with K-9 mail[0.00] Linux version 5.10.0-8-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.46-3 (2021-07-28)
[0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-5.10.0-8-amd64 
root=UUID=02117186-1520-493e-b434-e6e4c856a515 ro quiet
[0.00] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point 
registers'
[0.00] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
[0.00] x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers'
[0.00] x86/fpu: xstate_offset[2]:  576, xstate_sizes[2]:  256
[0.00] x86/fpu: Enabled xstate features 0x7, context size is 832 bytes, 
using 'standard' format.
[0.00] BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x0009d7ff] usable
[0.00] BIOS-e820: [mem 0x0009d800-0x0009] reserved
[0.00] BIOS-e820: [mem 0x000e-0x000f] reserved
[0.00] BIOS-e820: [mem 0x0010-0xb9aa1fff] usable
[0.00] BIOS-e820: [mem 0xb9aa2000-0xb9aa8fff] ACPI NVS
[0.00] BIOS-e820: [mem 0xb9aa9000-0xba2d7fff] usable
[0.00] BIOS-e820: [mem 0xba2d8000-0xba4f3fff] reserved
[0.00] BIOS-e820: [mem 0xba4f4000-0xca8befff] usable
[0.00] BIOS-e820: [mem 0xca8bf000-0xca956fff] reserved
[0.00] BIOS-e820: [mem 0xca957000-0xca993fff] usable
[0.00] BIOS-e820: [mem 0xca994000-0xcaa56fff] ACPI NVS
[0.00] BIOS-e820: [mem 0xcaa57000-0xcaffefff] reserved
[0.00] BIOS-e820: [mem 0xcafff000-0xcaff] usable
[0.00] BIOS-e820: [mem 0xcb80-0xcf9f] reserved
[0.00] BIOS-e820: [mem 0xf800-0xfbff] reserved
[0.00] BIOS-e820: [mem 0xfec0-0xfec00fff] reserved
[0.00] BIOS-e820: [mem 0xfed0-0xfed03fff] reserved
[0.00] BIOS-e820: [mem 0xfed1c000-0xfed1] reserved
[0.00] BIOS-e820: [mem 0xfee0-0xfee00fff] reserved
[0.00] BIOS-e820: [mem 0xff00-0x] reserved
[0.00] BIOS-e820: [mem 0x0001-0x00012f5f] usable
[0.00] NX (Execute Disable) protection: active
[0.00] SMBIOS 2.7 present.
[0.00] DMI: Gigabyte Technology Co., Ltd. H81M-S1/H81M-S1, BIOS FH 
08/10/2015
[0.00] tsc: Fast TSC calibration using PIT
[0.00] tsc: Detected 3392.039 MHz processor
[0.000461] e820: update [mem 0x-0x0fff] usable ==> reserved
[0.000464] e820: remove [mem 0x000a-0x000f] usable
[0.000469] last_pfn = 0x12f600 max_arch_pfn = 0x4
[0.000472] MTRR default type: uncachable
[0.000473] MTRR fixed ranges enabled:
[0.000474]   0-9 write-back
[0.000475]   A-B uncachable
[0.000475]   C-C write-protect
[0.000476]   D-E7FFF uncachable
[0.000477]   E8000-F write-protect
[0.000477] MTRR variable ranges enabled:
[0.000478]   0 base 00 mask 7F write-back
[0.000479]   1 base 01 mask 7FE000 write-back
[0.000480]   2 base 012000 mask 7FF000 write-back
[0.000481]   3 base 00E000 mask 7FE000 uncachable
[0.000481]   4 base 00D000 mask 7FF000 uncachable
[0.000482]   5 base 00CC00 mask 7FFC00 uncachable
[0.000483]   6 base 00CB80 mask 7FFF80 uncachable
[0.000483]   7 base 012F80 mask 7FFF80 uncachable
[0.000484]   8 base 012F60 mask 7FFFE0 uncachable
[0.000485]   9 disabled
[0.000746] x86/PAT: Configuration [0-7]: WB  WC  UC- UC  WB  WP  UC- WT  
[0.000947] e820: update [mem 0xcb80-0x] usable ==> reserved
[0.000952] last_pfn = 0xcb000 max_arch_pfn = 0x4
[0.006871] found SMP MP-table at [mem 0x000fd6c0-0x000fd6cf]
[0.013870] Using GB pages for direct mapping
[0.014409] RAMDISK: [mem 0x33041000-0x35817fff]
[0.014411] ACPI: Early table checksum verification disabled
[0.014414] ACPI: RSDP 0x000F0490 24 (v02 ALASKA)
[0.014417] ACPI: XSDT 0xCAA24078 6C (v01 ALASKA A M I
01072009 AMI  00010013)
[0.014421] ACPI: FACP 0xCAA30620 00010C (v05 ALASKA A M I
01072009 AMI  00010013)
[0.014425] ACPI: DSDT 0xCAA24178 00C4A7 (v02 ALASKA A M I
0088 INTL 20091112)
[0.014427] ACPI: FACS 0xCAA55080 40
[0.014429] ACPI: APIC 0xCAA30730 72 (v03 ALASKA A M I
01072009 AMI  00010013)
[0.014431] ACPI: FPDT 0xCAA307A8 44 

Bug#991943: klibc: please consider including machine-readable copyright file

[Andrej Shadura]

Source: klibc
Severity: wishlist
Tags: patch

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

Please consider including the attached machine-readable copyright file.
I tried to make it as precise as I can based on the information in the
source and accompanying text files; improve it as you see fit.

- -- 
Cheers,
  Andrej

-BEGIN PGP SIGNATURE-

iHUEARYIAB0WIQSD3NF/RLIsyDZW7aHoRGtKyMdyYQUCYQ0rmAAKCRDoRGtKyMdy
Yd2xAQCZTyRxfp7cdJim3/22RJHoJ+46/cTXvSdu0Gz6fCYCuwEA4BD4bqtdsxmg
6ntMSp862Lq54br/b/0JAS7mRBk5Jws=
=0MaS
-END PGP SIGNATURE-
Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/

Files: *
Copyright: 2004-2021, H. Peter Anvin and klibc contributors
License: BSD-3-clause and/or GPL-2 and/or Expat

Files: klcc/*
License: Expat

Files: contrib/klibc.m4
Copyright: 1995-2003, Free Software Foundation, Inc.
License: GPL-2-with-Autoconf-exception

Files: scripts/basic/fixdep.c
Copyright: 2002, Kai Germaschewski 
License: GPL-2

Files: usr/dash/*
Copyright:
 1989-1994, The Regents of the University of California
 1997, Christos Zoulas
 1997-2012, Herbert Xu 
Comment:
 This code is derived from software contributed to Berkeley by Kenneth Almquist.
License: BSD-3-Clause

Files: usr/dash/TOUR
Copyright: 1989, Kenneth Almquist.
License: BSD-3-Clause

Files: usr/dash/src/bltin/test.c
Copyright: Erik Baalbergen, Eric Gisin, Arnold Robbins, J.T. Conklin
License: public-domain

Files: usr/gzip/*
Copyright:
 1992-1993 Jean-loup Gailly
License: GPL-2+

Files: usr/gzip/inflate.c
Copyright: 1992, Mark Adler
License: public-domain

Files: usr/include/arch/*
Copyright: 2004-2006, H. Peter Anvin
License: Expat

Files: usr/include/arch/sparc/*
Copyright: 1992, 1993, The Regents of the University of California.
License: BSD-3-clause

Files: usr/include/arch/sparc/machine/asm.h
Copyright:
 1994, Allen Briggs
 1993, Adam Glass
 1988, University of Utah.
 1982, 1990 The Regents of the University of California.
License: BSD-3-clause

Files: usr/include/sys/md.h
Copyright: 2006, H. Peter Anvin
License: GPL-2+

Files:
 usr/include/zconf.h
 usr/include/zlib.h
 usr/klibc/zlib/*
Copyright: 1995-2005, Jean-loup Gailly and Mark Adler
License: Zlib

Files: usr/kinit/capabilities.*
Copyright: 2011, Google Inc.
License: BSD-3-clause and/or GPL-2 and/or Expat

Files: usr/kinit/fstype/jfs_superblock.h
Copyright: 2000-2003, International Business Machines Corp.
License: GPL-2+

Files: usr/kinit/run-init/*
Copyright: 2004-2006, H. Peter Anvin
License: Expat

Files: usr/klibc/arch/*
Copyright: 1992, 1993, The Regents of the University of California.
License: BSD-3-clause

Files: usr/klibc/arch/ia64/klibc.ld
Copyright: 2014-2018, Free Software Foundation, Inc.
License: FSFULLR

Files: usr/utils/cpio.c
Copyright: 1990-1992, 2001-2004, Free Software Foundation, Inc.
License: GPL-2+

Files: usr/utils/minips.c
Copyright: 1998, Albert Cahalan
License: LGPL-2+

Files: usr/utils/nuke.c
Copyright: 2004-2006, H. Peter Anvin
License: Expat

License: GPL-2-with-Autoconf-exception
 This file is free software, distributed under the terms of the GNU
 General Public License.  As a special exception to the GNU General
 Public License, this file may be distributed as part of a program
 that contains a configuration script generated by Autoconf, under
 the same distribution terms as the rest of that program.

License: Expat
 Permission is hereby granted, free of charge, to any person
 obtaining a copy of this software and associated documentation
 files (the "Software"), to deal in the Software without
 restriction, including without limitation the rights to use,
 copy, modify, merge, publish, distribute, sublicense, and/or
 sell copies of the Software, and to permit persons to whom
 the Software is furnished to do so, subject to the following
 conditions:
 .
 The above copyright notice and this permission notice shall
 be included in all copies or substantial portions of the Software.
 .
 THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
 OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
 NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
 HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
 WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
 FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
 OTHER DEALINGS IN THE SOFTWARE.

License: BSD-3-clause
 Redistribution and use in source and binary forms, with or without
 modification, are permitted provided that the following conditions
 are met:
 1. Redistributions of source code must retain the above copyright
notice, this list of conditions and the following disclaimer.
 2. Redistributions in binary form must reproduce the above copyright
notice, this list of conditions and the following disclaimer in the
documentation and/or other materials provided with the distribution.
 3. Neither the name of the University nor the names of its 

Bug#991831: unblock: mat2/0.12.1-3

[Georg Faerber]

Hi Paul,

On 21-08-06 14:07:00, Paul Gevers wrote:
> That's part of the equation, yes.

Thanks for clarifying.

> I won't speak for SRM, but I would expect so.

Thanks!

> Tip: reportbug from bullseye has a better template for unblock and p-u
> bugs than buster. Please be verbose on impact, tests and risks if/when
> you file a p-u bug so that SRM can properly assess the gain vs risks.

ACK, will do so in the future.

Have a good release time!

Thanks for your work,
cheers,
Georg

Bug#991831: unblock: mat2/0.12.1-3

[Paul Gevers]

Hi Georg,

On 06-08-2021 11:07, Georg Faerber wrote:
> 
> On 21-08-06 08:32:20, Paul Gevers wrote:
>> It's too late for changes like this one.
> 
> Is this due to mat2 being a key package?

That's part of the equation, yes.

> Besides, would this potentially accepted in 11.1?

I won't speak for SRM, but I would expect so.

Tip: reportbug from bullseye has a better template for unblock and p-u
bugs than buster. Please be verbose on impact, tests and risks if/when
you file a p-u bug so that SRM can properly assess the gain vs risks.

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#991917: python3-wikitrans: Wiki 2 html conversion errors

[Sergey Poznyakoff]

Hi Erich,

Thanks for your report.

> 1. This upstream patch should be included in the package:
> 
> https://git.gnu.org.ua/wikitrans.git/commit/?id=c785e3ad767b12a13ae75a3513ec88a4d1144210

Sure.  It will be included when new version is released.

> 2. A wrong variable name is used here:
> File "/usr/lib/python3/dist-packages/wikitrans/wikimarkup.py", line 662, in
> parse_ref
> list.append(self.parse_tag(tok))
> TypeError: descriptor 'append' for 'list' objects doesn't apply to a
> 'HtmlTagNode' object

That's definitely a copy-paste error.  I've pushed the following patch
https://git.gnu.org.ua/wikitrans.git/commit/?id=90a9ed7108e45fa8c2d0300e1308a99171240255

> 3. WikiDelimNodes (generated by wikimarkup: ''Example'') cause raw
> JSON to be
> inserted in the HTML:

Can you give more detail, please?

Regards,
Sergey

Bug#991942: golang-google-cloud-dev: Outdated package

[Peymaneh Nejad]

Package: golang-google-cloud-dev
Version: 0.56.0-1
Severity: normal

Hi,

I am working on packaging github.com/smallstep/certificates which
depends on v0.86 of this package.

I would prepare an updated version for team upload to experimental so that I 
can go on with packaging. 

Please let me know if there is issues with that procedure

kind regards,
Peymaneh

Bug#688716: cron: optionally inherit PATH from parent process

[Graham Inggs]

Hi Maintainer

This change was recently adopted in Ubuntu, along with the attached
patch to update crontab(5) manpage to match the new behaviour.

Regards
Graham
Description: Update crontab(5) manpage to match new behaviour
Bug-Debian: https://bugs.debian.org/688716
Bug-Ubuntu: https://bugs.launchpad.net/ubuntu/+source/cron/+bug/1938924
Author: Graham Inggs 
Last-Update: 2021-08-06

--- a/crontab.5
+++ b/crontab.5
@@ -91,7 +91,7 @@
 .IR cron (8)
 daemon.
 SHELL is set to /bin/sh, and LOGNAME and HOME are set from the /etc/passwd
-line of the crontab's owner.  PATH is set to "/usr/bin:/bin".
+line of the crontab's owner.  PATH is inherited from the environment.
 HOME, SHELL, and PATH may be overridden by settings in the crontab;
 LOGNAME is the user that the job is running from, and may not be changed.
 .PP
@@ -123,8 +123,7 @@
 .B NOT
 override the settings described above nor any settings in the
 .I crontab
-file itself.  Note in particular that if you want a PATH other than
-"/usr/bin:/bin", you will need to set it in the crontab file.
+file itself.
 .PP
 By default, cron will send mail using the mail "Content-Type:" header of
 "text/plain" with the "charset=" parameter set to the charmap / codeset of the
@@ -305,7 +304,8 @@
 # that none of the other crontabs do.
 
 SHELL=/bin/sh
-PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
+# You can also override PATH, but by default, newer versions inherit it from the environment
+#PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
 
 # Example of job definition:
 # . minute (0 - 59)

Bug#991920: Acknowledgement (please demote pkg-config to Recommends)

[Thomas Lange]

> On Fri, 6 Aug 2021 12:34:13 +0200, Dominik George 
>  said:

> If Thomas consents, I would make the change in experimental as well
> and we will see how it works out. I do not see any reason not to
> demote pkg-config.

Go for it.

-- 
viele Grüße Thomas

Bug#969611: node-setimmediate: broken symlinks in /usr/share/doc/node-setimmediate/mocha.{css,js}

[Andreas Beckmann]

Followup-For: Bug #969611

node-setimmediate has Suggests: libjs-mocha (>= 3), but that package no
longer exists after stretch.

A possible replacement is the virtual, versioned node-mocha (= 8.2.1)
provided by mocha (8.2.1+ds1+~cs29.4.27-3) which ships
  /usr/share/nodejs/mocha/lib/mocha.js
  /usr/share/nodejs/mocha/mocha.css

Andreas

Bug#991920: Acknowledgement (please demote pkg-config to Recommends)

[Dominik George]

On Thu, Aug 05, 2021 at 10:21:30PM +0200, Michael Banck wrote:
> I've run "dracut --no-kernel" in a minimal lxc container, once with
> pkg-config and once without and then diffoscope'd the two generated
> initrds. Most of what diffoscope complains about are timestamp
> differences in directories and symlinks which I don't know how to get
> rid of, but there's some changes in etc/conf.d/systemd.conf that I have
> attached. Not sure whether those are problematic?

Given that /usr/lib is the canonical path for these directories, and
/lib happens to be a symlink there, this should not be a problem.

If Thomas consents, I would make the change in experimental as well
and we will see how it works out. I do not see any reason not to
demote pkg-config.

Cheers,
Nik

-- 
Dominik George
Berater PostgreSQL / Datenbanken

Telefon:  +49 2166 9901-192
Telefax:  +49 2166 9901-100

E-Mail: dominik.geo...@credativ.de
PGP-Fingerprint: 3C9D 54A4 7575 C026 FB17  FD26 B79A 3C16 A0C4 F296
https://www.credativ.de/

credativ GmbH, HRB Mönchengladbach 12080
USt-ID-Nummer: DE204566209
Trompeterallee 108, 41189 Mönchengladbach
Geschäftsführung: Dr. Michael Meskes, Sascha Heuer, Geoff Richardson, Peter 
Lilley

Unser Umgang mit personenbezogenen Daten unterliegt
folgenden Bestimmungen: https://www.credativ.de/datenschutz

Bug#954093: desktop-base: Integration with KDE Plasma on Debian 11 no longer works

[Laura Arjona Reina]

Package: desktop-base
Version: 11.0.3
Followup-For: Bug #954093

Dear Maintainer,

I've just installed a PC with KDE Plasma desktop task using the Debian 11 
installer RC3 and this bug is still present.
My computer is all HomeWorld-themed except the desktop wallpaper (I got the 
"Shells" one).
I could change it to HomeWorld successfully with right click, "Configure 
Desktop and Wallpaper", and choosing the "Homeworld" wallpaper.
But I was expecting that the Debian theme wallpaper was shown directly after 
install.

I have checked the .js script and looks the same as the first reporter 
informed, and also checked if there's a debian-theme as suggested but it isn't.

Kind regards,
Laura Arjona Reina
https://wiki.debian.org/LauraArjona


-- 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-8-amd64 (SMP w/4 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages desktop-base depends on:
ii  fonts-quicksand  0.2016-2.1
ii  librsvg2-common  2.50.3+dfsg-1

Versions of packages desktop-base recommends:
ii  plymouth-label  0.9.5-3

Versions of packages desktop-base suggests:
ii  kde-standard  5:111

-- no debconf information

Bug#924912: pristine-tar: Failed to reproduce original tarball python-django_1.11.20.orig.tar.gz

[Roger Shimizu]

should be caused by:
- https://bugs.debian.org/897653

if you upgrade tar to buster version 1.30+dfsg-6 or later, it should
be resolved.
-- 
Roger Shimizu, GMT +9 Tokyo
PGP/GPG: 4096R/6C6ACD6417B3ACB1

Bug#960304: snapshot.debian.org: Snapshot repo repeatedly cutting off connection, returning partial content

[Julien Cristau]

On Fri, Aug 06, 2021 at 05:08:40PM +0900, Mike Hommey wrote:
> Package: snapshot.debian.org
> Followup-For: Bug #960304
> 
> Dear Maintainer,
> 
> We're hitting this problem regularly on Mozilla CI (from using dget),
> and what is probably a variant of this bug with apt, which fails with,
> for example:
> 
> [task 2021-08-05T21:27:09.094Z] Err:187 
> http://snapshot.debian.org/archive/debian/20210208T213147Z jessie/main amd64 
> adwaita-icon-theme all 3.14.0-2
> [task 2021-08-05T21:27:09.094Z]   Undetermined Error [IP: 193.62.202.27 80]
> (...)
> [task 2021-08-05T21:27:23.590Z] Err:202 
> http://snapshot.debian.org/archive/debian/20210208T213147Z jessie/main amd64 
> libicu52 amd64 52.1-8+deb8u7
> [task 2021-08-05T21:27:23.591Z]   Undetermined Error [IP: 193.62.202.27 80]
> (...)
> [task 2021-08-05T21:28:41.210Z] E: Failed to fetch 
> http://snapshot.debian.org/archive/debian/20210208T213147Z/pool/main/a/adwaita-icon-theme/adwaita-icon-theme_3.14.0-2_all.deb
>   Undetermined Error [IP: 193.62.202.27 80]
> [task 2021-08-05T21:28:41.210Z] E: Failed to fetch 
> http://snapshot.debian.org/archive/debian/20210208T213147Z/pool/main/i/icu/libicu52_52.1-8+deb8u7_amd64.deb
>   Undetermined Error [IP: 193.62.202.27 80]
> 
> Corresponding server-side log for the same url:
> 54.162.202.139 - - [05/Aug/2021:21:27:08 +] "GET 
> http://snapshot.debian.org/archive/debian/20210208T213147Z/pool/main/a/adwaita-icon-theme/adwaita-icon-theme_3.14.0-2_all.deb
>  HTTP/1.1" 200 3518464 "-" "Debian APT-HTTP/1.3 (1.8.2.2)"
> 54.202.218.195 - - [05/Aug/2021:21:39:12 +] "GET 
> http://snapshot.debian.org/archive/debian/20210208T213147Z/pool/main/a/adwaita-icon-theme/adwaita-icon-theme_3.14.0-2_all.deb
>  HTTP/1.1" 200 9978092 "-" "Debian APT-HTTP/1.3 (1.8.2.2)"
> 
Hi,

it looks like yesterday's config change wasn't enough, and we still hit
"LRU reached nuke_limit" / "Could not get storage" errors in varnish
(except now only with files that are smaller than 10MB, since we no
longer cache larger ones).  Will need to figure out the right tradeoffs.

Thanks,
Julien

Bug#991941: linux: Don't use nouveau with Nvidia GeForce 8500 GT or alert in dmesg that firmware is needed

[Laura Arjona Reina]

Source: linux
Severity: normal

Dear Maintainer,

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


   * What led up to the situation?

I have installed Debian 11 (debian installer RC3) on a PC having a 
Nvidia GeForce 8500 GT as main graphics card.
The graphicall install process went well. After finishing the 
installation and reboot, I got a blank screen and "Input not supported" 
on my monitor.
I changed to tty2 and logged in, and saved the dmesg output (attached), 
I noticed that "nouveau" driver was loaded but there was no info about 
my card not supported or needing additional firmware.


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


I have rebooted and edited the "linux" line during Grub menu, to add 
"nomodeset" and then I could have a fallback graphics mode.
I have installed the isenkram-cli package and ran 
isenkram-autoinstall-firmware as suggested in the release notes and it 
installed firmware for my realtek card (unrelated) and 
firmware-misc-nonfree, but rebooting makes Linux pick the nouveau driver 
again.


I have installed manually the nvidia-detect package and then I learned 
that this card needs the nvidia-legacy-340xx package, which is not 
present in bullseye.


I tried to install manually the nvidia-legacy-340xx-driver package from 
sid and got the system showing a graphical environment without the need 
of adding "nomodeset" to the grub linux line.


However later I read https://wiki.debian.org/NvidiaGraphicsDrivers and 
found:

"Version 340.108 (legacy GPUs) (supported devices)
Older legacy driver, for GeForce 8 series through GeForce 300 
series. No Vulkan support, supports up to OpenGL 3.3 depending on your 
card.


Use of the 340-series driver is strongly discouraged. It is not 
included in stable releases of Debian anymore, has serious unfixable 
security vulnerabilities, and may not be updated for new kernels in a 
timely manner. You are highly recommended to use the built-in Nouveau 
driver if security is a priority. "


So I uninstalled the package.

   * What was the outcome of this action?

I'm not sure which is the best way to get this system working, but 
anyway I think the average user would get puzzled about dmesg not 
alerting anything wrong but the system not showing graphics unless 
"nomodeset".


   * What outcome did you expect instead?

I think that dmesg should alert the user that the card is not well 
supported by nouveau and/or would need to install additional firmware or 
be used in fallback mode.


Kind regards,
--
Laura Arjona Reina
https://wiki.debian.org/LauraArjona


-- 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-8-amd64 (SMP w/4 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en

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

Bug#991940: unblock: munge/0.5.14-6

[Gennaro Oliva]

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

Please unblock package munge

[ Reason ]
* Cherry-pick upstream patch to allow to upgrade from buster to bullseye

[ Impact ]
Remove some minor tests to fix kfreebsd builds and a useless check for
the daemon when starting

[ Tests ]
All tests passed

[ Risks ]
It's low risk because:
the change only avoid a useless check that the libgcrypt shared object
linked at runtime is the same the daemon was compiled against [1] and
some minor tests (removed upstream) to fix kfreebsd builds.

[ 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

diffstat for munge-0.5.14 munge-0.5.14

 changelog |   14 +
 patches/0005-Sharness-Remove-tests-to-from-invalid-files.patch|   93 
+
 patches/0006-Sharness-Set-IFNAME-prereq-if-network-ifname-found.patch |  102 
++
 patches/0007-Remove-GCRYPT_VERSION-from-gcry_check_version.patch  |   36 
+++
 patches/series|3 
 5 files changed, 248 insertions(+)

debdiff attached

unblock munge/0.5.14-6

[1] https://github.com/dun/munge/commit/0c37cc03b649d8861c2d9e8d172bff736bfd9ea4
-- 
Gennaro Oliva
diff -Nru munge-0.5.14/debian/changelog munge-0.5.14/debian/changelog
--- munge-0.5.14/debian/changelog   2021-02-25 17:08:19.0 +0100
+++ munge-0.5.14/debian/changelog   2021-08-06 09:40:42.0 +0200
@@ -1,3 +1,17 @@
+munge (0.5.14-6) unstable; urgency=medium
+
+  [Chris Dunlap]
+  * Remove GCRYPT_VERSION from gcry_check_version (Closes: #991875)
+
+ -- Gennaro Oliva   Fri, 06 Aug 2021 09:40:42 +0200
+
+munge (0.5.14-5) unstable; urgency=medium
+
+  [Chris Dunlap]
+  * Fix kfreebsd builds
+
+ -- Gennaro Oliva   Mon, 22 Mar 2021 02:00:52 +0100
+
 munge (0.5.14-4) unstable; urgency=medium
 
   [Chris Dunlap]
diff -Nru 
munge-0.5.14/debian/patches/0005-Sharness-Remove-tests-to-from-invalid-files.patch
 
munge-0.5.14/debian/patches/0005-Sharness-Remove-tests-to-from-invalid-files.patch
--- 
munge-0.5.14/debian/patches/0005-Sharness-Remove-tests-to-from-invalid-files.patch
  1970-01-01 01:00:00.0 +0100
+++ 
munge-0.5.14/debian/patches/0005-Sharness-Remove-tests-to-from-invalid-files.patch
  2021-08-05 23:56:30.0 +0200
@@ -0,0 +1,93 @@
+Description: Sharness: Remove tests to/from invalid files
+ On FreeBSD (12.1, 11.4, 11.3) and NetBSD (9.0, 8.1, 7.2), the following
+ test fails when run with "root=/tmp/munge-test-$$":
+ 0012-munge-cmdline.t 24 - munge --input from invalid file
+ This test attempts to read data for a credential payload from the file
+ "." -- i.e., a directory, and not a regular file.  It is expected
+ to fail, and on most platforms it does.  However, it unexpectedly
+ succeeds if the input file is on a FreeBSD ufs or NetBSD ffs filesystem
+ (where it uses the directory file contents as the payload data),
+ but fails if the input file is on an nfs or tmpfs filesystem on
+ those platforms.  Note that this test fails as expected on OpenBSD
+ ffs and nfs filesystems.
+ This passed testing for 0.5.14 because the test suite ran in an
+ nfs directory.  But recent testing with "root=/tmp/munge-test-$$"
+ uncovered the failure since the "root" variable moved the input file
+ to a different filesystem.
+ Since the munge and unmunge client executables do not explicitly
+ check whether the input or output files are regular files, remove the
+ sharness checks that test for an expected failure when specifying an
+ invalid input, metadata, or output file.
+Author: Chris Dunlap 
+Origin: upstream, 
https://github.com/dun/munge/commit/cfbb14558ceda9dd42b23a2e4c166a07b73a3223
+Last-Update: 2020-10-14
+Forwarded: not-needed
+
+--- a/t/0012-munge-cmdline.t
 b/t/0012-munge-cmdline.t
+@@ -109,10 +109,6 @@ test_expect_success 'munge --input from /dev/null' '
+ test ! -s out.$$
+ '
+ 
+-test_expect_success 'munge --input from invalid file' '
+-test_must_fail "${MUNGE}" --socket="${MUNGE_SOCKET}" --input=.
+-'
+-
+ test_expect_success 'munge --input from missing file' '
+ test_must_fail "${MUNGE}" --socket="${MUNGE_SOCKET}" \
+ --input=missing.file.$$
+@@ -141,10 +137,6 @@ test_expect_success 'munge --output to /dev/null' '
+ test ! -s out.$$
+ '
+ 
+-test_expect_success 'munge --output to invalid file' '
+-test_must_fail "${MUNGE}" --socket="${MUNGE_SOCKET}" --no-input --output=.
+-'
+-
+ for OPT_LIST_CIPHERS in '-C' '--list-ciphers'; do
+ test_expect_success "munge ${OPT_LIST_CIPHERS}" '
+ "${MUNGE}" "${OPT_LIST_CIPHERS}" |
+diff --git a/t/0013-unmunge-cmdline.t b/t/0013-unmunge-cmdline.t
+index c034109..07ce8eb 100755
+--- a/t/0013-unmunge-cmdline.t
 b/t/0013-unmunge-cmdline.t
+@@ -80,10 +80,6 @@ test_expect_success 'unmunge --input from /dev/null' '
+   

Bug#991939: libjs-bootstrap4: broken symlinks: /usr/share/javascript/bootstrap4/css/bootstrap*.css.map -> ../../../nodejs/bootstrap/dist/css/bootstrap*.css.map

[Andreas Beckmann]

Package: libjs-bootstrap4
Version: 4.5.2+dfsg1-7
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package ships (or creates)
a broken symlink.

>From the attached log (scroll to the bottom...):

0m13.9s ERROR: FAIL: Broken symlinks:
  /usr/share/javascript/bootstrap4/css/bootstrap-grid.css.map -> 
../../../nodejs/bootstrap/dist/css/bootstrap-grid.css.map (libjs-bootstrap4)
  /usr/share/javascript/bootstrap4/css/bootstrap-reboot.css.map -> 
../../../nodejs/bootstrap/dist/css/bootstrap-reboot.css.map (libjs-bootstrap4)
  /usr/share/javascript/bootstrap4/css/bootstrap.css.map -> 
../../../nodejs/bootstrap/dist/css/bootstrap.css.map (libjs-bootstrap4)

The target files existed in earlier versions of the package.


cheers,

Andreas


libjs-bootstrap4_4.5.2+dfsg1-7.log.gz
Description: application/gzip

Bug#991811: unblock: libapache2-mod-auth-openidc/2.4.9-1

[Christoph Martin]

Hi Paul,
hi Salvatore,

Am 06.08.21 um 09:32 schrieb Salvatore Bonaccorso:
>>
>> It's *very* late in the freeze so I need an answer *real soon*. You
>> didn't tell us how you tested the package, how upstream tested the
>> changes and how you *judge* the changes between bullseye and sid. I
>> can't estimate the risk by myself.
> 
> From security team perspective, we could tend to confirm to be good
> option to actually go to 2.4.9 based version, if Christoph can confirm
> the above questions on testing. Was it tested in production
> environment as well?
> 

I have tested it in a production environment.
The package installs correctly on a bullseye system.
Upgrade of the package also works.
Login via our idp ist working as expected.
All expected env variables in phpinfo have the expected values.

Regards

Christoph



OpenPGP_signature
Description: OpenPGP digital signature

Bug#991938: libopenobex:

[Chris Lamb]

Source: libopenobex
Version: 1.7.2-1
Severity: minor
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

It looks like libopenobex is missing an *optional* dependency on
graphviz to generate a documentation, leading to a large number of
errors such as this:

  sh: 1: dot: not found
  sh: 1: dot: not found
  error: Problems running dot: exit code=127, command='dot', 
arguments='"/build/1st/libopenobex-1.7.2/debian/build/doc/html/api_8c__incl.dot"
 -Tpng -o "/build/1st/libopenobex-1.7.2/debian/build/doc/html/api_8c__incl.png"'
  sh: 1: dot: not found
  error: Problems running dot: exit code=127, command='dot', 
arguments='"/build/1st/libopenobex-1.7.2/debian/build/doc/html/obex_8h__incl.dot"
 -Tpng -o 
"/build/1st/libopenobex-1.7.2/debian/build/doc/html/obex_8h__incl.png"'
  sh: 1: sh: 1: dot: not found
  dot: not found
  sh: 1: dot: not found

It likely results in a lack of pretty graphs in the documentation,
hence the "minor" severity (over "wishlist"). Was discovered via
reproducibility testing.

Patch attached (which happens to use the !nodoc profile).


Regards,

--
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
diff --git a/debian/control b/debian/control
index 422a704..230d46c 100644
--- a/debian/control
+++ b/debian/control
@@ -5,7 +5,7 @@ Maintainer: Nobuhiro Iwamatsu 
 Build-Depends: debhelper (>= 7.0.0), cmake (>= 2.6.3),
libbluetooth-dev [linux-any], libusb-1.0-0-dev,
pkg-config, doxygen, docbook-xml, docbook-xsl,
-   xsltproc, libxml2-utils
+   xsltproc, libxml2-utils, graphviz 
 Standards-Version: 3.9.8
 Homepage: http://sourceforge.net/projects/openobex/
 Vcs-Git: https://anonscm.debian.org/git/collab-maint/libopenobex.git

Bug#991937: python3-pdfminer: Recommends python3-crypto, which is no longer in Debian

[Simon McVittie]

Package: python3-pdfminer
Version: 20200726-1
Severity: normal

python3-crypto was removed from bullseye in January 2021, and from unstable
in July 2021. The removal bug https://bugs.debian.org/979318 says it is
no longer maintained upstream and has been superseded by pycryptodome.

Note that pycryptodome is not a drop-in replacement (its top-level package
name is Cryptodome rather than Crypto, and there are some API changes) so
some porting will likely be required. Please see
 for more
details.

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

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

Versions of packages python3-pdfminer depends on:
ii  python3   3.9.2-3
ii  python3-chardet   4.0.0-1
ii  python3-cryptography  3.3.2-1
ii  python3-sortedcontainers  2.1.0-2

Versions of packages python3-pdfminer recommends:
ii  python3-crypto  2.6.1-13.1+b3

Versions of packages python3-pdfminer suggests:
pn  pdfminer-data  

-- no debconf information

Bug#991936: openssh-server: seccomp filter defaults to SIGSYS, could break any libc or kernel upgrade

[Julian Andres Klode]

Package: openssh-server
Version: 1:8.4p1-5ubuntu2
Severity: serious
X-Debbugs-Cc: j...@debian.org

seccomp filters are currently setup to kill the process

#define SECCOMP_FILTER_FAIL SECCOMP_RET_KILL

/* Default deny */
BPF_STMT(BPF_RET+BPF_K, SECCOMP_FILTER_FAIL),

this means every new libc or kernel release can cause openssh
to break, requiring breaks from them on openssh, which does not
scale, and is currently breaking SSH during upgrades.

This also means openssh might fail to work inside containers
because the host kernel is newer.

The default policy needs to be changed to return ENOSYS instead,
such that libc can fallback to other syscalls for its wrappers.
With the caveat that umask is a bit broken, if you don't want to
allow it, block it explicitly with RET_KILL:

https://bugzilla.mozilla.org/show_bug.cgi?id=1724098

This should be fixed for bullseye+1, and fixed in a point release
IMO, it might be a tad too late right now for the release itself.

-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer  i speak de, en

Bug#991935: 4.4.1-2.3 not in Salsa git repo. upstream/4.4.1 tag also missing

[Nicholas Brown]

Package: isc-dhcp
Version: 4.4.1-2.3
Severity: normal

Report that 4.4.1-2.3 is missing from git:
https://qa.debian.org/cgi-bin/vcswatch?package=isc-dhcp

upstream/4.4.1 tag missing
https://salsa.debian.org/dhcp-team/isc-dhcp/-/tags so gbp build will report
an error trying to build master.

Bug#991831: unblock: mat2/0.12.1-3

[Georg Faerber]

Hi Paul,

Thanks for your reply.

On 21-08-06 08:32:20, Paul Gevers wrote:
> It's too late for changes like this one.

Is this due to mat2 being a key package?

Besides, would this potentially accepted in 11.1?

Cheers,
Georg

Bug#991934: ITP: rust-liboverdrop -- A simple Rust library to handle configuration fragments

[clay stan]

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

* Package name: rust-liboverdrop
  Version : 0.0.2
  Upstream Author : overdrop
* URL : https://github.com/overdrop/liboverdrop-rs
  License : MIT or Apache-2.0

Bug#991897: removal of the any/local-rtlddir-cross.diff patch broke cross builds

[Aurelien Jarno]

control: reassign -1 cross-toolchain-base-ports-46
control: tag -1 + patch
control: tag -1 - moreinfo
control: tag -1 - unreproducible

On 2021-08-05 18:59, Aurelien Jarno wrote:
> control: tag -1 + moreinfo
> control: tag -1 + unreproducible
> 
> On 2021-08-04 19:03, Matthias Klose wrote:
> > Package: src:glibc
> > Version: 2.31-13
> > Severity: serious
> > Tags: sid bullseye
> > 
> > when cross-building glibc in the c-t-b packages, the libc.so linker file for
> > some non-default multilib builds like the sparc build for sparc64 is broken,
> > leading to build failures for at least all gcc-N cross multilib packages at 
> > least.
> > 
> > $ cat usr/lib32/libc.so
> > /* GNU ld script
> >Use the shared library, but some functions are only in
> >the static library, so try that secondarily.  */
> > OUTPUT_FORMAT(elf32-sparc)
> > GROUP ( /lib32/libc.so.6 /usr/lib32/libc_nonshared.a  AS_NEEDED (
> > /lib/ld-linux.so.2 ) )
> 
> Can you point me where you got that file? It doesn't make sense from the
> path and the content point of view. Also it's not what I get in the
> libc6-sparc-sparc64-cross package generated by building
> cross-toolchain-base-ports in a bullseye chroot. I get instead:
> 
> | cat /usr/sparc64-linux-gnu/lib32/libc.so  
> | /* GNU ld script
> |    Use the shared library, but some functions are only in
> |the static library, so try that secondarily.  */
> | OUTPUT_FORMAT(elf32-sparc)
> | GROUP ( /usr/sparc64-linux-gnu/lib32/libc.so.6 
> /usr/sparc64-linux-gnu/lib32/libc_nonshared.a  AS_NEEDED ( 
> /usr/sparc64-linux-gnu/lib/ld-linux.so.2 ) )
> 
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=985617#62 says that the
> > maintainer is investigating, but apparently this never happened.
> 
> I *did* investigate, and checked that the changes in the linker files
> are correct. I have just done that again for both cross-toolchain-base
> and cross-toolchain-base-ports. Here are the differences I observed on
> the linker scripts:

I have ran a build of gcc-10-cross and gcc-10-cross-ports over the
night. gcc-10-cross just built fine, but gcc-10-cross-ports indeed
failed to build the sparc64 cross compiler as you reported.

It appears that the embedded copy of dpkg-cross decided to map the
multiarch path to /usr/$triplet/lib, leaving lib32, lib64 or libx32 to
the other multilib builds. This causes an issue for the dynamic linker
symlink, which usually follows the upstream way of putting a 64-bit
library in /lib64. At the end, it means the 32-bit dynamic linker
ends-up in the /usr/triplet/lib directory containing the 64 bit
libraries. This is not a big deal for most architectures, except when
the 32- and 64-bit dynamic linkers have the same name like on sparc64.

The problem seems to have been identified, as one of the two is just
removed in the debian/rules file, with this associated comment:

# FIXME: don't remove these here, but find out why these are left in the glibc 
build

The problem is that the removed one is the most useful one, breaking the
assumption that /usr/$triplet/$rtld.so exists. The following patches
fixes the issue for sparc64:


diff -Nru cross-toolchain-base-ports-45/debian/rules 
cross-toolchain-base-ports-46/debian/rules
--- cross-toolchain-base-ports-45/debian/rules  2021-03-03 15:22:03.0 
+0100
+++ cross-toolchain-base-ports-46/debian/rules  2021-08-06 10:31:22.0 
+0200
@@ -831,7 +831,7 @@
case "$$pkgname" in \
  libc6-mips32-mips64-cross|libc6-mips32-mips64el-cross) \
rm -f $$tmp/usr/*/lib/ld.so.1;; \
- libc6-sparc-sparc64-cross) \
+ libc6-sparc64-cross) \
rm -f $$tmp/usr/*/lib/ld-linux.so.2;; \
esac; \
if [ 'lib$(libgcc_base)1-dbg-$${cross_arch}-cross' = $$pkgname ]; then \

I guess the same fix is needed for gcc-10-cross-mipsen, but I haven't
been able to build it yet.

Regards,
Aurelien

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

Bug#991933: mokutil: RISC-V build missing

[Heinrich Schuchardt]

Package: mokutil
Version: 0.4.0-1
Severity: normal
Tags: patch
Usertags: origin-ubuntu impish ubuntu-patch

Dear maintainer,

building mokutil for RISC-V only requires debian/control to be adjusted.
See Ubuntu package mokutil 0.4.0-1ubuntu1.

U-Boot already supports booting via UEFI on RISC-V including secure 
boot. With mokutil we can display the relevant information. As 
SetVariable() is not implemented we cannot update anything.


EDK II should allow setting variables. Currently the HiFive Unleashed is 
the only supported RISC-V board.


Best regards

Heinrich

Bug#990183: libopenscap8: libopenscap.so.8 is missing from libopenscap8 and is expected by scap-workbench

[Hideki Yamane]

Hi,

 I've restructured openscap pacakge to fix Bug#990183 and make it
 better, upload to https://salsa.debian.org/henrich/openscap

 I'll upload it to experimental with delay-10, if you want to cancel
 it, don't hestitate.


-- 
Regards,

 Hideki Yamane henrich @ debian.org/iijmio-mail.jp

Bug#983108: Closing power-profiles-daemon ITP?

[intrigeri]

Hi,

I see that power-profiles-daemon has been in experimental for a while?

Is there any particular reason why we should not close this ITP?

Thanks a lot for packaging this piece of software, can't wait to try
it once GNOME 41 lands in sid with the corresponding GNOME Shell UI
bits :)

Bug#960304: snapshot.debian.org: Snapshot repo repeatedly cutting off connection, returning partial content

[Mike Hommey]

Package: snapshot.debian.org
Followup-For: Bug #960304

Dear Maintainer,

We're hitting this problem regularly on Mozilla CI (from using dget),
and what is probably a variant of this bug with apt, which fails with,
for example:

[task 2021-08-05T21:27:09.094Z] Err:187 
http://snapshot.debian.org/archive/debian/20210208T213147Z jessie/main amd64 
adwaita-icon-theme all 3.14.0-2
[task 2021-08-05T21:27:09.094Z]   Undetermined Error [IP: 193.62.202.27 80]
(...)
[task 2021-08-05T21:27:23.590Z] Err:202 
http://snapshot.debian.org/archive/debian/20210208T213147Z jessie/main amd64 
libicu52 amd64 52.1-8+deb8u7
[task 2021-08-05T21:27:23.591Z]   Undetermined Error [IP: 193.62.202.27 80]
(...)
[task 2021-08-05T21:28:41.210Z] E: Failed to fetch 
http://snapshot.debian.org/archive/debian/20210208T213147Z/pool/main/a/adwaita-icon-theme/adwaita-icon-theme_3.14.0-2_all.deb
  Undetermined Error [IP: 193.62.202.27 80]
[task 2021-08-05T21:28:41.210Z] E: Failed to fetch 
http://snapshot.debian.org/archive/debian/20210208T213147Z/pool/main/i/icu/libicu52_52.1-8+deb8u7_amd64.deb
  Undetermined Error [IP: 193.62.202.27 80]

Corresponding server-side log for the same url:
54.162.202.139 - - [05/Aug/2021:21:27:08 +] "GET 
http://snapshot.debian.org/archive/debian/20210208T213147Z/pool/main/a/adwaita-icon-theme/adwaita-icon-theme_3.14.0-2_all.deb
 HTTP/1.1" 200 3518464 "-" "Debian APT-HTTP/1.3 (1.8.2.2)"
54.202.218.195 - - [05/Aug/2021:21:39:12 +] "GET 
http://snapshot.debian.org/archive/debian/20210208T213147Z/pool/main/a/adwaita-icon-theme/adwaita-icon-theme_3.14.0-2_all.deb
 HTTP/1.1" 200 9978092 "-" "Debian APT-HTTP/1.3 (1.8.2.2)"

Mike

Bug#991629: cloud.debian.org: Bullseye AWS AMI: cloud-init creates duplicate #includedir in /etc/sudoers

[Chris Boot]

On 06/08/2021 02:47, Ross Vandegrift wrote:

Hi Chris,

On Thu, Jul 29, 2021 at 10:24:22AM +0100, Chris Boot wrote:

In the sudoers file there is a duplicate includedir
statement; at the end of the file you will find the following contents:

"""
# See sudoers(5) for more information on "@include" directives:

@includedir /etc/sudoers.d

# Added by cloud-init v. 20.4.1 on Wed, 28 Jul 2021 20:40:05 +
#includedir /etc/sudoers.d

   ^

Is this a copy/paste mistake?  It looks commented out.


It's isn't a copy/paste mistake, nor is it commented out. This was the 
syntax used up to Buster, but from Bullseye the new @includedir syntax 
is preferred (but sudo accepts both). That's presumably why it was 
changed in sudo.


The result is that both lines include the files in the /etc/sudoers.d 
directory, hence the "duplicated" definitions and syntax errors.


Cheers,
Chris

--
Chris Boot
bo...@debian.org

Bug#991932: Please upgrade to new upstream

[Petr Cech]

Package: python3-icecream
Version: 2.0.0-1
Severity: wishlist

Hi,
please package the newer upstream release 2.1.1.

Thanks,
Petr


-- System Information:
Debian Release: 11.0
  APT prefers stable-updates
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Versions of packages python3-icecream depends on:
ii  python33.9.4-1
ii  python3-asttokens  2.0.4-1
ii  python3-colorama   0.4.4-1
ii  python3-executing  0.5.3-1
ii  python3-pygments   2.7.1+dfsg-2.1

python3-icecream recommends no packages.

python3-icecream suggests no packages.

-- no debconf information

Bug#991931: CVE-2021-32686 / AST-2021-009: pjproject/pjsip: crash when SSL socket destroyed during handshake

[Bernhard Schmidt]

Package: src:asterisk
Severity: serious
Tags: security upstream patch

https://downloads.asterisk.org/pub/security/AST-2021-009.html

Summary:pjproject/pjsip: crash when SSL socket destroyed during 
handshake
Nature of Advisory: Denial of service
Susceptibility: Remote unauthenticated sessions
Severity:   Major
Exploits Known: Yes

Description
| Depending on the timing, it’s possible for Asterisk to crash when using a TLS
| connection if the underlying socket parent/listener gets destroyed during the
| handshake.

Bug#991811: unblock: libapache2-mod-auth-openidc/2.4.9-1

[Salvatore Bonaccorso]

HI Paul,

On Fri, Aug 06, 2021 at 08:40:24AM +0200, Paul Gevers wrote:
> Hi Christopher,
> 
> On 02-08-2021 13:33, Christoph Martin wrote:
> > Please unblock package libapache2-mod-auth-openidc
> > 
> > currently the version 2.4.4.1-2 of libapache2-mod-auth-openidc is in
> > testing/bullseye . Some days ago four CVE security bugs were published
> > which are fixed in version 2.4.9 .
> > 
> > The fix to CVE-2021-32791 looks quite big, so that I think it is not
> > safe to backport it to 2.4.4.1 like the others could be.
> > 
> > I uploaded the latest upstream (2.4.9) rather than try to
> > backport the fixes to 2.4.4.
> 
> It's *very* late in the freeze so I need an answer *real soon*. You
> didn't tell us how you tested the package, how upstream tested the
> changes and how you *judge* the changes between bullseye and sid. I
> can't estimate the risk by myself.

>From security team perspective, we could tend to confirm to be good
option to actually go to 2.4.9 based version, if Christoph can confirm
the above questions on testing. Was it tested in production
environment as well?

Regards,
Salvatore

Bug#991930: ifenslave: ifstate command does not exists

[debian-bug-ifenslave]

Package: ifenslave 
Version: 2.12

Problem while trying to bring up bond0 or any bonding interface.

ifup[933]: No iface stanza found for master bond0

The root cause is ifenslave shipped with a script, referring to ifstate command 
which is not present.

Script:/etc/network/if-pre-up.d/ifenslave 

...
setup_slave_device() {

    # Require the bond master to have an iface stanza
    if ! ifstate -l "$IF_BOND_MASTER" 2>/dev/null ; then
        echo "No iface stanza found for master $IF_BOND_MASTER" >&2
        exit 1
    fi
...

To fix switched to ip command that achieve the same goal

...
setup_slave_device() {
    # Require the bond master to have an iface stanza
    if ! ip link show dev "$IF_BOND_MASTER" 2>/dev/null; then
        echo "No iface stanza found for master $IF_BOND_MASTER" >&2
        exit 1
    fi
...

Debian 11.0 (5.10.0-8-amd64 #1 SMP Debian 5.10.46-3 (2021-07-28) x86_64 
GNU/Linux)

Reference:

https://blog.rtsp.us/debian-11-bullseye-bonding-problem-9d8d8866117e

Bug#991593: fixed in otrs2 6.0.32-6

[Salvatore Bonaccorso]

Hi,

On Fri, Aug 06, 2021 at 09:11:12AM +0200, Moritz Muehlenhoff wrote:
> On Fri, Aug 06, 2021 at 08:08:45AM +0200, Salvatore Bonaccorso wrote:
> > Hi,
> > 
> > On Thu, Aug 05, 2021 at 11:49:41AM +0200, Moritz Mühlenhoff wrote:
> > > Am Thu, Aug 05, 2021 at 09:19:14AM + schrieb Debian FTP Masters:
> > > > Source: otrs2
> > > > Source-Version: 6.0.32-6
> > > > Done: Patrick Matthäi 
> > > > 
> > > > We believe that the bug you reported is fixed in the latest version of
> > > > otrs2, which is due to be installed in the Debian FTP archive.
> > > > 
> > > > A summary of the changes between this version and the previous one is
> > > > attached.
> > > > 
> > > > Thank you for reporting the bug, which will now be closed.  If you
> > > > have further comments please address them to 991...@bugs.debian.org,
> > > > and the maintainer will reopen the bug report if appropriate.
> > > > 
> > > > Debian distribution maintenance software
> > > > pp.
> > > > Patrick Matthäi  (supplier of updated otrs2 
> > > > package)
> > > > 
> > > > (This message was generated automatically at their request; if you
> > > > believe that there is a problem with it please contact the archive
> > > > administrators by mailing ftpmas...@ftp-master.debian.org)
> > > > 
> > > > 
> > > > -BEGIN PGP SIGNED MESSAGE-
> > > > Hash: SHA256
> > > > 
> > > > Format: 1.8
> > > > Date: Thu, 05 Aug 2021 10:37:30 +0200
> > > > Source: otrs2
> > > > Architecture: source
> > > > Version: 6.0.32-6
> > > > Distribution: unstable
> > > > Urgency: high
> > > > Maintainer: Patrick Matthäi 
> > > > Changed-By: Patrick Matthäi 
> > > > Closes: 991593
> > > > Changes:
> > > >  otrs2 (6.0.32-6) unstable; urgency=high
> > > >  .
> > > >* Add upstream patches to fix CVE-2021-36091, CVE-2021-21440 and
> > > >  CVE-2021-21443.
> > > >  Closes: #991593
> > > 
> > > Hi Patrick,
> > > what about CVE-2021-36092, does that need to be split off to a separate
> > > bug or is znuny as packaged in Debian not affected?
> > 
> > Probably sensible to split up the bug. Comments from upstream on it:
> > https://github.com/znuny/Znuny/issues/105#issuecomment-894013730
> 
> Let's track it as , Znuny upstream did their due diligence
> to the extent possible allowed by OTRS controlling the information, and
> without concrete details (and given that they could not reproduce), there's
> no need to track this as vulnerability affecting Znuny.

Okay fine as well then. Let's track it this way then and add reference
to upstream issue, so if they resolve we can downstream update the
tracking.

Regards,
Salvatore

Bug#991593: fixed in otrs2 6.0.32-6

[Moritz Muehlenhoff]

On Fri, Aug 06, 2021 at 08:08:45AM +0200, Salvatore Bonaccorso wrote:
> Hi,
> 
> On Thu, Aug 05, 2021 at 11:49:41AM +0200, Moritz Mühlenhoff wrote:
> > Am Thu, Aug 05, 2021 at 09:19:14AM + schrieb Debian FTP Masters:
> > > Source: otrs2
> > > Source-Version: 6.0.32-6
> > > Done: Patrick Matthäi 
> > > 
> > > We believe that the bug you reported is fixed in the latest version of
> > > otrs2, which is due to be installed in the Debian FTP archive.
> > > 
> > > A summary of the changes between this version and the previous one is
> > > attached.
> > > 
> > > Thank you for reporting the bug, which will now be closed.  If you
> > > have further comments please address them to 991...@bugs.debian.org,
> > > and the maintainer will reopen the bug report if appropriate.
> > > 
> > > Debian distribution maintenance software
> > > pp.
> > > Patrick Matthäi  (supplier of updated otrs2 package)
> > > 
> > > (This message was generated automatically at their request; if you
> > > believe that there is a problem with it please contact the archive
> > > administrators by mailing ftpmas...@ftp-master.debian.org)
> > > 
> > > 
> > > -BEGIN PGP SIGNED MESSAGE-
> > > Hash: SHA256
> > > 
> > > Format: 1.8
> > > Date: Thu, 05 Aug 2021 10:37:30 +0200
> > > Source: otrs2
> > > Architecture: source
> > > Version: 6.0.32-6
> > > Distribution: unstable
> > > Urgency: high
> > > Maintainer: Patrick Matthäi 
> > > Changed-By: Patrick Matthäi 
> > > Closes: 991593
> > > Changes:
> > >  otrs2 (6.0.32-6) unstable; urgency=high
> > >  .
> > >* Add upstream patches to fix CVE-2021-36091, CVE-2021-21440 and
> > >  CVE-2021-21443.
> > >  Closes: #991593
> > 
> > Hi Patrick,
> > what about CVE-2021-36092, does that need to be split off to a separate
> > bug or is znuny as packaged in Debian not affected?
> 
> Probably sensible to split up the bug. Comments from upstream on it:
> https://github.com/znuny/Znuny/issues/105#issuecomment-894013730

Let's track it as , Znuny upstream did their due diligence
to the extent possible allowed by OTRS controlling the information, and
without concrete details (and given that they could not reproduce), there's
no need to track this as vulnerability affecting Znuny.

Cheers,
Moritz

Bug#991811: unblock: libapache2-mod-auth-openidc/2.4.9-1

[Paul Gevers]

Hi Christopher,

On 02-08-2021 13:33, Christoph Martin wrote:
> Please unblock package libapache2-mod-auth-openidc
> 
> currently the version 2.4.4.1-2 of libapache2-mod-auth-openidc is in
> testing/bullseye . Some days ago four CVE security bugs were published
> which are fixed in version 2.4.9 .
> 
> The fix to CVE-2021-32791 looks quite big, so that I think it is not
> safe to backport it to 2.4.4.1 like the others could be.
> 
> I uploaded the latest upstream (2.4.9) rather than try to
> backport the fixes to 2.4.4.

It's *very* late in the freeze so I need an answer *real soon*. You
didn't tell us how you tested the package, how upstream tested the
changes and how you *judge* the changes between bullseye and sid. I
can't estimate the risk by myself.

Paul




OpenPGP_signature
Description: OpenPGP digital signature

Bug#991729: With glibc 2.34, it seems more is broken

[Shachar Shemesh]

On 05/08/2021 22:47, Daniel Schepler wrote:

On Mon, Aug 2, 2021 at 10:45 PM Shachar Shemesh  wrote:

Can you run fakeroot-ng with "-l" and attach the generated log file?

Here's the log from the run where make fails.


The expected happened:

3331985: Unknown syscall 435(NONE)
3331985: Unknown syscall 435(RETURN)


Syscall 435 is "clone3", and was added to the kernel about a year ago. I 
don't know when glibc started using it instead of one of the other clone 
clones, but as fakeroot-ng doesn't handle it, it unsurprisingly broke.


I'll have a look at adding "clone3" to the list of supported system 
calls, but I'm also considering having fakeroot-ng repot any system call 
above the system calls it was aware of when it was written as 
unimplemented. This should avoid such breakages in the future.

Bug#991593: fixed in otrs2 6.0.32-6

[Salvatore Bonaccorso]

Hi,

On Thu, Aug 05, 2021 at 11:49:41AM +0200, Moritz Mühlenhoff wrote:
> Am Thu, Aug 05, 2021 at 09:19:14AM + schrieb Debian FTP Masters:
> > Source: otrs2
> > Source-Version: 6.0.32-6
> > Done: Patrick Matthäi 
> > 
> > We believe that the bug you reported is fixed in the latest version of
> > otrs2, which is due to be installed in the Debian FTP archive.
> > 
> > A summary of the changes between this version and the previous one is
> > attached.
> > 
> > Thank you for reporting the bug, which will now be closed.  If you
> > have further comments please address them to 991...@bugs.debian.org,
> > and the maintainer will reopen the bug report if appropriate.
> > 
> > Debian distribution maintenance software
> > pp.
> > Patrick Matthäi  (supplier of updated otrs2 package)
> > 
> > (This message was generated automatically at their request; if you
> > believe that there is a problem with it please contact the archive
> > administrators by mailing ftpmas...@ftp-master.debian.org)
> > 
> > 
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA256
> > 
> > Format: 1.8
> > Date: Thu, 05 Aug 2021 10:37:30 +0200
> > Source: otrs2
> > Architecture: source
> > Version: 6.0.32-6
> > Distribution: unstable
> > Urgency: high
> > Maintainer: Patrick Matthäi 
> > Changed-By: Patrick Matthäi 
> > Closes: 991593
> > Changes:
> >  otrs2 (6.0.32-6) unstable; urgency=high
> >  .
> >* Add upstream patches to fix CVE-2021-36091, CVE-2021-21440 and
> >  CVE-2021-21443.
> >  Closes: #991593
> 
> Hi Patrick,
> what about CVE-2021-36092, does that need to be split off to a separate
> bug or is znuny as packaged in Debian not affected?

Probably sensible to split up the bug. Comments from upstream on it:
https://github.com/znuny/Znuny/issues/105#issuecomment-894013730

Regards,
Salvatore