Bug#976631: closed by Sebastian Ramacher (Re: Bug#976631: handbrake-cli: doesn't work with libdvdnav4 6.1.0-1 or older)

[Brian Sammon]

> This was an ABI break in libdvdnav which was fixed.

I see.

I filed this bug to ask you to update the dependencies to prevent people from 
installing handbrake-cli alongside an incompatible version of libdvdnav4.

Don't you think that would be a good idea?

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

[Ross Vandegrift]

On Fri, Aug 06, 2021 at 09:07:02AM +0100, Chris Boot wrote:
> On 06/08/2021 02:47, Ross Vandegrift wrote:
> > 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.

, thanks.

This is fixed upstream in 21.1, though many other changes are included.  I
didn't look through the list carefully.  The fix for this particular bug is
trivial, I staged it here:
 https://salsa.debian.org/rvandegrift/cloud-init/-/tree/debian/bullseye

Either a targeted fix or a new upstream release will need to wait for a stable
update at this point.

Ross

Bug#991993: scanssh: New upstream release

[Thiago Andrade Marques]

Package: scanssh
Severity: wishlist

Dear Maintainer,

Please update the package to new upstream version 2.1.2. [1]

Regards,
Thiago Andrade

[1] https://github.com/ofalk/scanssh/tags

Bug#991971: [pkg-lynx-maint] Bug#991971: [CVE-2021-38165] lynx: bug in SSL certificate validation -> leaks password in clear text via SNI (under some circumstances)

[Axel Beckert]

Hi Andreas,

Andreas Metzler wrote:
> > > tags 991971 fixed-upstream
> > Bug #991971 [lynx] 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/; leaks password in clear 
> > text via SNI
> > Added tag(s) fixed-upstream.
> 
> Hello,
> 
> I have just uploaded .9 to experimental.

Thanks a lot! Went to bed in the morning last night, so I was really
happy to see at least Experimental already being fixed when I woke up
again.

> The deadline for bulleye unblock requests has passed, so we will
> need to fix this by security/point release.

Hrm, right, thanks for the reminder.

I nevertheless will update Unstable with a fix. It might be helpful
for the Security Team (Cc'ed) or us to prepare a stable-update for
Bullseye.

Security Team: Do you think the fix for CVE-2021-38165 should get a
DSA? Or do you think it's not important enough and we should target a
minor stable update for it?

> @Fellow lynx-maintainers: Do you have a preferred branch name for
> bullseye? I would go for "11_bullseye".

I'd just have said "bullseye" to keep things simple. But "11_bullseye"
isn't really bad either. At least the stable fix branches then would
be properly ordered. (I don't see much other gain from the "11_" in
front, though.)

The other option which came to my mind was "debian/bullseye" which I
thought would be according to DEP14, but then I noticed that it would
have to be "debian/bullseye-security" or "debian/bullseye-updates"
*sigh* according to DEP14.

But I must admit that I'm anything but a fan of DEP14. So I'll use
"11_bullseye".

Then again, this opens the question if I should put that upload to
Unstable into the 11_bullseye branch despite the later stable or
security update will not be a direct successor of that upload, at
least not in the debian/changelog. Meh. But then again, nothing speaks
against making it a predecessor in git only, i.e. just rewriting the
debian/changelog entry with the entry for the stable or security
update as the remainder will be the same anyways. And in the worst
case we can always rename branches or rewrite history in git. :-P

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#802370: ITA: docbook-xsl

[Brian Thompson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

retitle -1 ITA: docbook-xsl -- stylesheets for processing DocBook XML
- -- 
Best regards,

Brian T.
-BEGIN PGP SIGNATURE-

iQJHBAEBCgAxFiEE9fpVo96/flopdKOfgw2Ncu3Nhn0FAmEPClETHGJyaWFuQGhh
c2h2YXVsdC5pbwAKCRCDDY1y7c2Gfd7RD/9qIBu3K1iq1mjZ5YibRc85HonHrOJb
UlHlQ7dRHPlFjYvbXsYKVZpdzQTtz3LkZvgFvldFC0LxYtWBNQzxn4X3SgGbNNRB
b/P0cMRCgHCV0EG6B6q0NhM05+t0sPyscnu4VbjwlHlEFNrr3OP0uJJh/MbSjuST
1MG1k10Ihu+B6dOFK4Mq5Fl6LqNgUoSqXcKOib72W8vgXxkwKWmoBvbc0qRGMgGn
vYcMnwaISsHLIfwmFNQaQ+0HVhX3sTrvI1273K5fdi9hAjd/nA5i74UigQwpvb1l
gvzOjfFykK7E0aKtsEGdC3NHLd9lm17JP50iJYAZZz+JH79sj+M0TCORo8SG/lOv
6p3gRrzgX5RAZPDWXDBdJwE8rNDZQCeYIBSnsui9SpyRsjH/7dasSU1aoSigOB+U
oJcof1Q4hbXA4Viam0DHvm1EzIF97R5ZBFgGPQFnD9qpRk4pckMGD0/tnBDHcCAZ
u9oSNQCmCZ02gLSW4CiYbQ+LiGWWw6LEUoPRjhK188KqjTm6A1sPs7cK1Ibe9r/z
giT6tCVa3LTyFG0hO/FMiq73owLVzOJ9UwWzq7+NRceCQIENkZkNmQ9g2Lf6Fol2
Ul2jQDjJ755MrhspW9zO1crLsjs14meKWAAExleYmmOnpSK2cB6wSjS/VTrwdZAO
KgX+FOqMhwK9FA==
=lfHp
-END PGP SIGNATURE-

Bug#802368: ITA: docbook-xml

[Brian Thompson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

retitle -1 ITA: docbook-xml -- standard XML documentation system

- -- 
Best regards,

Brian T.
-BEGIN PGP SIGNATURE-

iQJHBAEBCgAxFiEE9fpVo96/flopdKOfgw2Ncu3Nhn0FAmEPCekTHGJyaWFuQGhh
c2h2YXVsdC5pbwAKCRCDDY1y7c2Gfe8VEACrpLu2smZo7oiQs2uhRyDAzj+iaScg
9C3kmOcnit9VVhuPD+VXi8+nkL5lsRvmgHuLuI9aKfHXRVgie/yswrpZIQsUA/v/
kLLcEcCUCnEfQs15fru56TT3zby2Yyzrcpy7f16aVo8urZcu6izwgJDyawzrEz/L
CpX1oFa2dIJVO1kJX72z1QGCLnQkXuy+MyvmM3wvRfNcH5DSU3PYKOqGAKT5zStz
fyuinvS8akOiTrm8AhXQmDGp1shet3jP5N5IOPqHcoUu/wNmUs2BYDY91NtIXNFq
b8sYNTM5zEBDlf2MwgcyCyIzF1Zcf/GRUW0JgxMqrUsOjgaVVvGamgzyhil6hOL3
Fd4PAa2u4NhVlq/lRumCSGA9fW7O2iRZ/rj4vO1c8YaiGKD3wqaXJWeLFILvngQk
F3nvxi4qaz0oMXlYW5Jjy4lX3q/WgVUBLpXayS7DuV7o7JDhC6Y8NHrTuruR8ckn
F4Lrvj7lBJNlaTI/2uWy7o7RPuOOE7zGJWQyAeyYKQh9KlTwAy1H9d/QRh5sLv3g
/1uVu/ZNzm1Rtt3xYcHEDfkgVuvuZCmiH0WNsxbyA46quyjGDmEP15MkThrzESFv
VPWem7Lrp/I2MRb6Drwr8c3nlkPerRkbVyZS8bFDe64n/3+F+Orp2YD7WnseKd04
9ui1uOttuJXhFQ==
=CjbS
-END PGP SIGNATURE-

Bug#991718: u-boot-sifive: only 8GB RAM visible on Sifive Unmatched

[Tianon Gravi]

On Sat, 7 Aug 2021 at 08:03, Adam Borowski  wrote:
> On Thu, Aug 05, 2021 at 12:26:57PM -0700, Tianon Gravi wrote:
> > > On 2021-07-30, Adam Borowski wrote:
> > > > The Unmatched has 16GB memory -- which works fine with the vendor u-boot
> > > > it shipped with.  Alas, with Debian u-boot from experimental, only 8GB 
> > > > is
> > > > visible (at 0x8000-0x00027fff).
>
> > I think it must be related to the combination of newer
> > u-boot and new (upstream) kernel?
>
> In -next there's:
> commit d09560435cb712c9ec1e62b8a43a79b0af69fe77
> Author: Qiu Wenbo 
> Date:   Sun Jul 4 16:34:41 2021 +0800
>
> riscv: dts: fix memory size for the SiFive HiFive Unmatched
>
> The production version of HiFive Unmatched have 16GB memory.
>
> Signed-off-by: Qiu Wenbo 
> Signed-off-by: Palmer Dabbelt 
>
> --- a/arch/riscv/boot/dts/sifive/hifive-unmatched-a00.dts
> +++ b/arch/riscv/boot/dts/sifive/hifive-unmatched-a00.dts
> @@ -24,7 +24,7 @@ cpus {
>
> memory@8000 {
> device_type = "memory";
> -   reg = <0x0 0x8000 0x2 0x>;
> +   reg = <0x0 0x8000 0x4 0x>;
> };
>
> soc {
>
> Applying that gives me the full memory back.

Confirmed, applying that works for me too -- I'm closing this bug
accordingly. :)

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

Bug#914315: libwebp-dev: New versions fix disclosed heap use-after-free

[Jeff Breidenbach]

Maintainer is "less active" but still in good contact with upstream.  I was
going to package the latest version several months ago, but there was a
soname bump and transitions were not allowed due to Debian's release cycle.
Happy to work with anyone on updating webp.

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

[Diederik de Haas]

On vrijdag 6 augustus 2021 16:07:18 CEST Diederik de Haas wrote:
> > > -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/e5b976c268e44d452bc5ae23
> b765eab26c4409ae 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.

If you do 'make menuconfig' and change the default governor, it automatically 
makes the matching CPU_FREQ_GOV_* parameter builtin. And you can't change 
that. And apparently you can't make CPU_FREQ_GOV_PERFORMANCE a module. At all.
So menuconfig is telling me that the default governor must use a builtin 
module.



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

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

[Ariadne Conill]

Hi,

On Sat, 7 Aug 2021, Axel Beckert wrote:


Hi Salvatore, Dear Ariadne,

Salvatore Bonaccorso wrote:

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.

[…]

IMHO this nevertheless needs a CVE-ID.


MITRE did assign CVE-2021-38165.


Thanks Salvatore. I updated the debian/changelog entry for the next
upload as well as the title of the Debian bug report.


+1, thanks for getting a CVE for this.


MITRE raised the question: Does 2.9.0dev.9 (mentioned on the
https://lynx.invisible-island.net/current/CHANGES.html page) fix the
entire problem?


At this point a huge thanks to Thomas Dickey (Lynx upstream) for
providing a fixed version so quickly!


I think 2.9.0dev.9 fixes the problem, even if the fix is, well, not the 
way I would do it.





https://www.openwall.com/lists/oss-security/2021/08/07/7 claims that
credentials appear in the HTTP Host header to an http:// (i.e.,
non-SSL) website.


Indeed and a good point.

Citing from Ariadne's mail:

The issue itself is far more severe: HTParse() does not understand
the authn part of the URI at all.

[…]

But it will also leak in the Host: header on unencrypted
connections, and also probably SSL ones too.


But that looks to me as if Ariadne just refers to the code and hasn't
actually checked it by trying it. Nevertheless thanks to Ariadne for
having had a look and proposing a patch!


Yes, this was my guess since HTParse() doesn't understand the authn part. 
But this seems like a rather unfortunate design: parse the URI wrong, and 
then "fix" it later?  Why not just parse the URI right, to begin with?


So strange...

Ariadne

Bug#991989: libclang-13-dev: dead symlink to shared library

[Christian Göttsche]

Package: libclang-13-dev
Version: 1:13.0.0~+rc1-1~exp1
Severity: important

The shared library symlink at '/usr/lib/llvm-13/lib/libclang-13.so' is
a dead symlink to '../../x86_64-linux-gnu/libclang-13.so.1'.
The existing targets are
  - /usr/lib/x86_64-linux-gnu/libclang-13.so
  - /usr/lib/x86_64-linux-gnu/libclang-13.so.13
  - /usr/lib/x86_64-linux-gnu/libclang-13.so.13.0.0

This causes for example 'Include What You Use' to fail to build:


CMake Error at /usr/lib/llvm-13/lib/cmake/clang/ClangTargets.cmake:706
(message):
 The imported target "libclang" references the file

"/usr/lib/llvm-13/lib/libclang-13.so.13.0.0"

 but this file does not exist.  Possible reasons include:

 * The file was deleted, renamed, or moved to another location.

 * An install or uninstall procedure did not complete successfully.

 * The installation package was faulty and contained

"/usr/lib/llvm-13/lib/cmake/clang/ClangTargets.cmake"

 but not all the files it references.

Call Stack (most recent call first):
 /usr/lib/cmake/clang-13/ClangConfig.cmake:20 (include)
 CMakeLists.txt:20 (find_package)


-- Configuring incomplete, errors occurred!

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

[Axel Beckert]

Hi Salvatore, Dear Ariadne,

Salvatore Bonaccorso wrote:
> > 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.
[…]
> > IMHO this nevertheless needs a CVE-ID.
>
> MITRE did assign CVE-2021-38165.

Thanks Salvatore. I updated the debian/changelog entry for the next
upload as well as the title of the Debian bug report.

> MITRE raised the question: Does 2.9.0dev.9 (mentioned on the
> https://lynx.invisible-island.net/current/CHANGES.html page) fix the
> entire problem?

At this point a huge thanks to Thomas Dickey (Lynx upstream) for
providing a fixed version so quickly!

> https://www.openwall.com/lists/oss-security/2021/08/07/7 claims that
> credentials appear in the HTTP Host header to an http:// (i.e.,
> non-SSL) website. 

Indeed and a good point.

Citing from Ariadne's mail:
> The issue itself is far more severe: HTParse() does not understand
> the authn part of the URI at all.
[…]
> But it will also leak in the Host: header on unencrypted
> connections, and also probably SSL ones too.

But that looks to me as if Ariadne just refers to the code and hasn't
actually checked it by trying it. Nevertheless thanks to Ariadne for
having had a look and proposing a patch!

To be on the safe side I tested Lynx 2.9.0dev.6-2 as in Debian
Unstable/Testing (yet unpatched for CVE-2021-38165) and the (claimed
to be fixed) Lynx 2.9.0dev.9-1 as uploaded to Debian Experimental by
Andreas Metzler very recently (still only on incoming.debian.org,
fetched it from there). And I also tested Lynx 2.8.9dev1 from Debian 8
Jessie ELTS, the oldest compiled version of Lynx I could easily get my
hands on.

Neither of them leaked the user name or password in Host header of a
plain HTTP request. (So I assume that the versions inbetween don't do
that either.)

I also kinda would have expected that if this would have been the case
in the plain HTTP Host header, it would have been noticed way earlier
than with the TLS SNI extension, namely before the HTTPS era. Then
again, the much more obvious facet of this issue which Thorsten
initially found was reported way later than I'd expected, so maybe my
gut feeling is wrong here, too. :-)

So I also looked in the code (of the unpatched 2.9.0dev.8). The patch
for 2.9.0dev.9 added a function StripUserAuthents and added it only
into the HTTPS code path. So I looked for "strip" and "Strip" in the
HTTP code path and found this code in WWW/Library/Implementation/HTTP.c
(which also has the HTTPS code btw.):

   1353 if ((host = HTParse(anAnchor->address, "", PARSE_HOST)) != 
NULL) {
-> 1354 strip_userid(host, TRUE);
-> 1355 HTBprintf(, "Host: %s%c%c", host, CR, LF);
   1356 FREE(host);
   1357 }

So from my point of view, this also invalidates that claim that the
HTTP Host header contains username or password. HTParse (as mentioned
by Ariadne occurs quite often in the code and its exact workings are
unclear to me from just looking at how it is called as it seems very
variable in what it parses and it appears before and after the above
mentioned code snippet for printing the Host header.

$ fgrep -n 'HTParse(' WWW/Library/Implementation/HTTP.c
891:connect_host = HTParse(connect_url, "https", PARSE_HOST);
900:connect_host = HTParse(connect_url, "snews", PARSE_HOST);
977:ssl_host = HTParse(url, "", PARSE_HOST);
1319:   char *p1 = (HTParse(url, "", PARSE_PATH | PARSE_PUNCTUATION));
1371:   if ((host = HTParse(anAnchor->address, "", PARSE_HOST)) != NULL) {
1564:   abspath = HTParse(arg, "", PARSE_PATH | PARSE_PUNCTUATION);
1565:   docname = HTParse(arg, "", PARSE_PATH);
1566:   hostname = HTParse(arg, "", PARSE_HOST);
1590:   host2 = HTParse(docname, "", PARSE_HOST);
1591:   path2 = HTParse(docname, "", PARSE_PATH | PARSE_PUNCTUATION);
2370:   !HTAA_HaveUserinfo(HTParse(arg, "", PARSE_HOST)) &&

So from my point of view the user and password are stripped only once
(in 2.9.0dev8), namely directly before printing the Host header (in
both HTTP and HTTPS code paths). Which also seems the reason why it
got forgotten for SNI and why Thomas added a new, way less complex
function for stripping them of the SNI header. Calling strip_userid
again would extract the credentials again which likely isn't wanted.
(The same IMHO applies to the often called HTParse function.)

I assume that Ariadne just oversaw that call to strip_userid just
before printing the HTTP Host header when looking at the code. (And I
clearly had the advantage of having looked at the code _after_ the
official upstream patch has been published, so I clearly had an
advantage when looking at the code, too.)

I though didn't check the strip_userid function in 

Bug#982598: incomplete logs for autopkg tests

[Paul Gevers]

Control: reassign -1 debci
Control: retitle -1 trunkate huge logs at the start instead of the end

Hi,

On Fri, 12 Feb 2021 20:35:11 +0100 Paul Gevers  wrote:
> reassign -1 debci

Oops.

> Hi Matthias,
> 
> On 12-02-2021 10:54, Matthias Klose wrote:
> > Package: release.debian.org
> 
> It's not the release team that runs ci.debian.net. Reassigning
> appropriately.
> 
> > As seen with glibc autopkg tests [1], the Debian CI infrastructure doesn't 
> > store
> > complete build logs, cutting these to 20MB (uncompressed), resulting in 
> > ~450k
> > compressed logs.  This might not be important for successful tests, but it
> > doesn't provide any information for failed tests, as the summary at the end 
> > is
> > always cut.  Looking at the Ubuntu CI testers, you see that the glibc log 
> > for a
> > successful test can reach 150MB, compressed 3.5GB [2].  With a glibc patch 
> > to
> > not stop on test failures with the first pass [3], logs for failed tests can
> > also reach that size.
> > 
> > The outcome of tests is used by the release team to make decisions about the
> > upcoming release [4].  Pointing out to a failed log which doesn't provide 
> > useful
> > information is not helpful, and does cost volunteer time to analyze.  In 
> > this
> > case it turned out to be the flaky test infrastructure, and retries 
> > resulted in
> > a successful test.  Good luck with that for a real regression ...
> > 
> > As pointed out in another context, "machine time is cheap, volunteer time is
> > not" [5], as well as machine storage is cheap compared to volunteer time, so
> > please stop cutting the autopkg test logs.
> 
> Unfortunately, we're hitting infrastructure issues if we don't cap the
> logs [1]. However, I think we should save the last part (and not the
> first part) if we have to cap, because normally the failure happens in
> the end.
> 
> Paul
> 
> [1]
> https://salsa.debian.org/ci-team/debci/-/commit/9240d93a3e8a017c303d4d1604808fbc1d0f
> 



OpenPGP_signature
Description: OpenPGP digital signature

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

[Thomas Dickey]

On Sat, Aug 07, 2021 at 08:17:31PM +0200, Salvatore Bonaccorso wrote:
> Hi Axel,
...
> MITRE did assign CVE-2021-38165. MITRE raised the question: Does
> 2.9.0dev.9 (mentioned on the
> https://lynx.invisible-island.net/current/CHANGES.html page) fix the
> entire problem?
> https://www.openwall.com/lists/oss-security/2021/08/07/7 claims that
> credentials appear in the HTTP Host header to an http:// (i.e.,
> non-SSL) website. 

I considered that possibility, but (using Axel's hint on how he tested)
found nothing in the data shown in "Follow TCP Stream" for this case.

Perhaps you could explain how you've tested this case, and how to repeat
the results.

(the suggested patch by the way is unsuitable because it breaks the
known-to-be-insecure use of user credentials in a non-HTTPS URL)

-- 
Thomas E. Dickey 
https://invisible-island.net
ftp://ftp.invisible-island.net


signature.asc
Description: PGP signature

Bug#970675: [Openjdk] Bug#970606: src:openjdk-*: autopkgtest times out on Debian/Ubuntu infrastructure

[Paul Gevers]

Control: retitle -1 enable per-package timeout exceptions
Control: severity -1 wishlist
Control: tags -1 =

Hi debci co-maintainers,

On Mon, 21 Sep 2020 11:43:06 +0200 Matthias Klose  wrote:
> On 9/19/20 9:16 PM, Paul Gevers wrote:
> > Source: openjdk-15
> > Version: 15+36-1
> > Severity: serious
> > Tags: sid bullseye
> > X-Debbugs-CC: debian...@lists.debian.org
> > User: debian...@lists.debian.org
> > Usertags: timeout
> > 
> > Dear maintainers, Matthias,
> > 
> > For a long time, the autopkgtests of openjdk-* have been failing on the
> > ci.debian.net infrastructure and they are currently blacklisted because
> > they time out and thus fail. As can be seen on the Ubuntu autopkgtest
> > framework, this is no different for openjdk-15 [1] and some recent try
> > outs [2,3] show it's still the case on the Debian infrastructure as
> > well. Due to the failure/blacklist, openjdk-15 is not migrating to
> > testing. Can you please fix the autopkgtest to not time out on our
> > infrastructure?
> > 
> > If you need help investigating the situation on our infrastructure,
> > don't hesitate to contact us on debian...@lists.debian.org or on #debci.
> 
> I don't think that referring to the Ubuntu autopkg testers is helping here.  I
> couldn't find any documentation on the timeout settings for the Debian
> infrastructure, for both amd64 and arm64.  I think it would help to document
> these constraints (and yes, Ubuntu doesn't document those either).  Apparently
> the very same tests don't time out on the buildds.
> 
> Unsure if you want to track that under the release.d.o meta issue.

There was more follow-up in the original bug, but it boils down to: it
would be nice if we could have some exceptions for packages where the
tests structurally take longer and the effort to fix/split that is too big.

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#934916: libss7: FTBFS on x32 (time_t sprintf format mismatch)

[John Scott]

Another (untested) way to fix this issue is to craft the format string
using _Generic:

 strcpy(p, mtp3_timer2str(x));
 p += strlen(p);
-sprintf(p, "(%lis)%c", 
ss7->ss7_sched[ss7->links[i]->mtp3_timer[x]].when.tv_sec - time(NULL),
+#define FORMAT _Generic((time_t){0}, long int: "(%lis)%c", long long int: 
"(%llis)%c")
+sprintf(p, FORMAT, ss7->ss7_sched[ss7->links[i]->mtp3_timer[x]].when.tv_sec - 
time(NULL),
ss7->ss7_sched[ss7->links[i]->mtp3_timer[x]].callback ? ' ' : '!');

Bug#991992: ITP: q2-diversity -- QIIME2 plugin for core diversity analysis

[Steffen Moeller]

Package: wnpp
Severity: wishlist

Subject: ITP: q2-diversity -- QIIME2 plugin for core diversity analysis
Package: wnpp
Owner: Steffen Moeller 
Severity: wishlist

* Package name: q2-diversity
  Version : 2020.11.1
  Upstream Author : QIIME 2 development team
* URL : https://qiime2.org/
* License : BSD-3-clause
  Programming Lang: Python
  Description : QIIME2 plugin for core diversity analysis
 QIIME 2 is a powerful, extensible, and decentralized microbiome analysis
 package with a focus on data and analysis transparency. QIIME 2 enables
 researchers to start an analysis with raw DNA sequence data and finish with
 publication-quality figures and statistical results.
 Key features:
  * Integrated and automatic tracking of data provenance
  * Semantic type system
  * Plugin system for extending microbiome analysis functionality
  * Support for multiple types of user interfaces (e.g. API, command line,
 graphical)
 .
 QIIME 2 is a complete redesign and rewrite of the QIIME 1 microbiome analysis
 pipeline. QIIME 2 will address many of the limitations of QIIME 1, while
 retaining the features that makes QIIME 1 a powerful and widely-used analysis
 pipeline.
 .
 QIIME 2 currently supports an initial end-to-end microbiome analysis pipeline.
 New functionality will regularly become available through QIIME 2 plugins. You
 can view a list of plugins that are currently available on the QIIME 2 plugin
 availability page. The future plugins page lists plugins that are being
 developed.

Remark: This package is maintained by Debian Med Packaging Team at
   https://salsa.debian.org/med-team/q2-diversity

Bug#991991: libbluray-bdj contains patches that break it

[Shaya Potter]

Package: libbluray-bdj
Version: 1:1.2.1-4

Debian/Ubuntu's libbluray includes patches to use system java
libraries instead of the libraries that libbluray ships within it and
this breaks bluray playback

https://code.videolan.org/videolan/libbluray/-/issues/31

I just tried to play a bluray and I get

Exception in thread "main"
PrintStream.java:java.io.PrintStream.println:823:
java.lang.NoClassDefFoundError:
org/objectweb/asm/commons/SimpleRemapper
PrintStream.java:java.io.PrintStream.println:823: at
org.videolan.BDJClassFileTransformer.rename(BDJClassFileTransformer.java:58)
PrintStream.java:java.io.PrintStream.println:823: at
org.videolan.mmbd.Adapter.(Adapter.java:83)
PrintStream.java:java.io.PrintStream.println:823: at
sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
PrintStream.java:java.io.PrintStream.println:823: at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
PrintStream.java:java.io.PrintStream.println:823: at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
PrintStream.java:java.io.PrintStream.println:823: at
java.lang.reflect.Constructor.newInstance(Constructor.java:423)
PrintStream.java:java.io.PrintStream.println:823: at
java.lang.Class.newInstance(Class.java:442)
PrintStream.java:java.io.PrintStream.println:823: at
org.videolan.Libbluray.loadAdapter(Libbluray.java:99)
PrintStream.java:java.io.PrintStream.println:823: at
org.videolan.Libbluray.init(Libbluray.java:354)

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

[Thorsten Glaser]

Ariadne Conill dixit:

> It turns out SNI is only marginally related to this issue.  The issue
> itself is far more severe: HTParse() does not understand the authn
> part of the URI at all.

Yes, of course. But without SNI, nothing would have been sent *in
plaintext* at all. The certificate validation fails¹, the connection
stops and the user is asked whether to continue.

① Tested on an OS without SNI in its libssl.

> As a workaround, I taught HTParse() how to parse the authn part of URIs, but
> Lynx itself needs to actually properly support the authn part really.
>
> I have attached the patch Alpine is using to work around this infoleak.

Thanks!

I recall having to work manually to strip the port from the hostname
for SSL certificate validation, ages ago, but I had not tested with
HTTP Auth sites back then.

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

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

[Salvatore Bonaccorso]

Hi Axel,

On Sat, Aug 07, 2021 at 03:51:07AM +0200, Axel Beckert wrote:
> 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.

MITRE did assign CVE-2021-38165. MITRE raised the question: Does
2.9.0dev.9 (mentioned on the
https://lynx.invisible-island.net/current/CHANGES.html page) fix the
entire problem?
https://www.openwall.com/lists/oss-security/2021/08/07/7 claims that
credentials appear in the HTTP Host header to an http:// (i.e.,
non-SSL) website. 

Regards,
Salvatore

Bug#991909: python-uflash 1.2.4+dfsg-1+deb10u1 flagged for acceptance

[Adam D Barratt]

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

Hi,

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

Thanks for your contribution!

Upload details
==

Package: python-uflash
Version: 1.2.4+dfsg-1+deb10u1

Explanation: update firmware URL

Bug#986898: yubikey-manager 2.1.0-1+deb10u1 flagged for acceptance

[Adam D Barratt]

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

Hi,

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

Thanks for your contribution!

Upload details
==

Package: yubikey-manager
Version: 2.1.0-1+deb10u1

Explanation: add missing dependency on python3-pkg-resources to yubikey-manager

Bug#991881: xmlgraphics-commons 2.3-1+deb10u1 flagged for acceptance

[Adam D Barratt]

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

Hi,

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

Thanks for your contribution!

Upload details
==

Package: xmlgraphics-commons
Version: 2.3-1+deb10u1

Explanation: fix Server-Side Request Forgery issue [CVE-2020-11988]

Bug#991886: libpam-tacplus 1.3.8-2+deb10u1 flagged for acceptance

[Adam D Barratt]

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

Hi,

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

Thanks for your contribution!

Upload details
==

Package: libpam-tacplus
Version: 1.3.8-2+deb10u1

Explanation: prevent shared secrets from being added in plaintext to the system 
log [CVE-2020-13881]

Bug#991641: irssi 1.2.0-2+deb10u1 flagged for acceptance

[Adam D Barratt]

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

Hi,

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

Thanks for your contribution!

Upload details
==

Package: irssi
Version: 1.2.0-2+deb10u1

Explanation: fix use after free issue when sending SASL login to the server 
[CVE-2019-13045]

Bug#990315: gcc-mingw-w64 21.3~deb10u2 flagged for acceptance

[Adam D Barratt]

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

Hi,

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

Thanks for your contribution!

Upload details
==

Package: gcc-mingw-w64
Version: 21.3~deb10u2

Explanation: fix gcov handling

Bug#986669: htslib 1.9-12~deb10u1 flagged for acceptance

[Adam D Barratt]

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

Hi,

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

Thanks for your contribution!

Upload details
==

Package: htslib
Version: 1.9-12~deb10u1

Explanation: fix autopkgtest on i386

Bug#990182: hg-git 0.8.12-1+deb10u1 flagged for acceptance

[Adam D Barratt]

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

Hi,

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

Thanks for your contribution!

Upload details
==

Package: hg-git
Version: 0.8.12-1+deb10u1

Explanation: fix test failures with recent git versions

Bug#986216: dwarf-fortress 0.44.12+dfsg1-0+deb10u1 flagged for acceptance

[Adam D Barratt]

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

Hi,

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

Thanks for your contribution!

Upload details
==

Package: dwarf-fortress
Version: 0.44.12+dfsg1-0+deb10u1

Explanation: remove undistributable prebuilt shared libraries from the source 
tarball

Bug#979609: swt4-gtk segfaults on ppc64el

[Sudip Mukherjee]

Hi Frédéric,

On Thu, Apr 29, 2021 at 05:24:16PM +0200, Frédéric Bonnard wrote:
> Hi there,
> 
> I tried to bisect between 4.17.0 and 4.18.0 (4.19.0
> didn't work either) and found the first offending commit
> 64ceb09e3297259b58a78b5d6486b1724070a4c9 that makes tracecompass fail
> and playing with -DNO_gtk_1check_1button_1set_1inconsistent makes it
> work. Soon after f2006cbb02568177a6bfaf074f4e787b3dafdc75 : same kind of
> changes and same kind of trick seemed to help.
> All those implying GTK port changes and JNI. Also I saw tons of cc
> warnings of implicit casts in os.c which is generated by JNIGenerator ..
> 
> All in all, I tried with latest git tree as it has other GTK/JNI
> improvements and as of v4944r22, it built cleanly and worked well with
> tracecompass, syndie and steganosuite.

Thanks for testing with the latest tree. I tested with the latest 4.20.0
and the issue is fixed with tracecompass, syndie and steganosuite.
I will update 'swt4-gtk' to 4.20.0 and that should close this bug.

Thanks again for testing.

--
Regards
Sudip

Bug#986360: RFS: awf-gtk/2.5.0-1 [ITP] -- A widget factory is a theme preview application for GTK

[Tobias Frost]

On Tue, 13 Jul 2021 10:23:57 +0200 Fabrice Creuzot  wrote:
> Hi tobi,
> 
> Sorry, I haven't see your reply before today.
> 
> You are right, awf-gtk(2|3|4) are using the same source.
> Yes, multiple major GTK versions can be coinstalled.
> 
> I have created three packages because if I create only one source 
> package that depends on libgtk-2|3|4-dev, I think I will get the 
> following error: Missing build dependencies: libgtk-4-dev.

libgtk-2.0-dev and libgtk-3-dev are coninstallable, no problem here.
libgtk-4-dev is currently only in experimental, but it is also co-installable
on my machine's pbuilder after adding experimental. So technically it should be
possible.

> So I prefered to create three independant packages. This has been 
> accepted on Fedora and openSUSE (my Ubuntu PPA says also ok).

Fedora, openSuse and Ubuntu are not Debian.
So lets avoid having duplicated source packages without technical reason.

> Thanks
> 
> 

Bug#533904: /usr/bin/xtightvncviewer: allow resizing the window to match server resolution

[Sven Geuer]

Control: tags -1 = wontfix

Hello Michal,

On Sun, 21 Jun 2009 15:31:03 +0200 Michal Suchanek  wrote:
[...]
> 
> When the vnc server changes to smaller resolution vncviewer just
> displays it in top left corener of the previous larger window.
> 
> When the server changes to a larger resolution vncviewer exits.
> 
> What's so difficult about resizing the window?
> 
> This would probably apply to the case when scrollbars make the client
> area smaller but the window is not resized accordingly.
> 
[...]

Thightvnc is old software. Upstream does not maintain Thightvnc on
Linux any more. Thus, resizing the window will not become available in
the viewer.

Sven

-- 
GPG Fingerprint
3DF5 E8AA 43FC 9FDF D086 F195 ADF5 0EDA F8AD D585


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

Bug#429842: xtightvncviewer: Support for IPv6

[Sven Geuer]

Control: tags -1 = wontfix

Hello Thomas,

On Wed, 20 Jun 2007 17:29:00 +0200 Thomas Creutz  wrote:
[...]
> 
> I testing with my new IPv6 network and see, that ipv6 support is not 
> available.
> 
> I found on the webside a project that ported the new protocol for tightvnc:
> 
> http://www.tightvnc.com/related.html (on the bottem)
> 
> Can some integrated this?

Unfortunately, the link you provided does not work any more.

Besides of this Thightvnc is old software. Upstream does not maintain
Thightvnc on Linux any more. Thus, do not expect IPv6 support
to show up in Tightvnc.

Sven

-- 
GPG Fingerprint
3DF5 E8AA 43FC 9FDF D086 F195 ADF5 0EDA F8AD D585


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

Bug#991990: ITP: q2-emperor -- QIIME2 plugin for display of ordination plots

[Steffen Moeller]

Package: wnpp
Severity: wishlist

Subject: ITP: q2-emperor -- QIIME2 plugin for display of ordination plots
Package: wnpp
Owner: Steffen Moeller 
Severity: wishlist

* Package name: q2-emperor
  Version : 2020.11.1
  Upstream Author : QIIME 2 development team
* URL : https://qiime2.org/
* License : BSD-3-clause
  Programming Lang: Python
  Description : QIIME2 plugin for display of ordination plots
 QIIME 2 is a powerful, extensible, and decentralized microbiome analysis
 package with a focus on data and analysis transparency. QIIME 2 enables
 researchers to start an analysis with raw DNA sequence data and finish with
 publication-quality figures and statistical results.
 Key features:
  * Integrated and automatic tracking of data provenance
  * Semantic type system
  * Plugin system for extending microbiome analysis functionality
  * Support for multiple types of user interfaces (e.g. API, command line,
 graphical)
 .
 QIIME 2 is a complete redesign and rewrite of the QIIME 1 microbiome analysis
 pipeline. QIIME 2 will address many of the limitations of QIIME 1, while
 retaining the features that makes QIIME 1 a powerful and widely-used analysis
 pipeline.
 .
 QIIME 2 currently supports an initial end-to-end microbiome analysis pipeline.
 New functionality will regularly become available through QIIME 2 plugins. You
 can view a list of plugins that are currently available on the QIIME 2 plugin
 availability page. The future plugins page lists plugins that are being
 developed.

Remark: This package is maintained by Debian Med Packaging Team at
   https://salsa.debian.org/med-team/q2-emperor

Bug#991971: [oss-security] 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))

[Jeffrey Walton]

On Sat, Aug 7, 2021 at 8:29 AM Thorsten Glaser  wrote:
>
> >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?

As far as I know, the only problem associated with SNI is leaking the
server name to a passive adversary in TLS 1.2 and below. TLS 1.3 and
above provide for encrypted server names.

> 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.

If you disable SNI, then you won't be able to setup an encrypted
channel. SNI is needed to setup the encrypted channel. During the
client_hello, the server needs to know which server/virtual host to
route the client_hello to.

The user:password@ is for the application layer or HTTP/HTTPS. It
should not be present in the transport layer. It is a bug in the
application layer, not the transport layer.

The transport layer does have a password based authentication scheme,
but it is going to be either Thomas Wu's Secure Remote Password (SRP)
or Preshared Key (PSK). SRP is based on Diffie-Hellman (something like
a^password), while PSK uses a symmetric cipher (something like
enc_k(password)).

> (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.)

Yes, the client will learn the server's IP address. That is not
related to SNI. That's just how TLS works under the IETF's threat
model.

Maybe you are thinking of (or need) something like a Tor hidden
service. Transport Layer Security does not provide a guarantee like a
hidden service.

Wildcards are garbage. You should be wary of an operator that uses
them nowadays. A wildcard certificate could be used by an attacker to
have you connect to the receptionist's machine in the lobby running a
fake site rather than the organization's web server.

Jeff

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

[Andreas Metzler]

On 2021-08-07 Debian Bug Tracking System  wrote:
> Processing commands for cont...@bugs.debian.org:

> > tags 991971 fixed-upstream
> Bug #991971 [lynx] 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/; leaks password in clear 
> text via SNI
> Added tag(s) fixed-upstream.

Hello,

I have just uploaded .9 to experimental. The deadline for bulleye
unblock requests has passed, so we will need to fix this by
security/point release.

@Fellow lynx-maintainers: Do you have a preferred branch name for
bullseye? I would go for "11_bullseye".

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'


signature.asc
Description: PGP signature

Bug#990800: ITA: btcheck/2.1-5 -- downloaded data checker and a torrent file content viewer

[Tobias Frost]

Control: tags -1 moreinfo

Hi Lin Qigang,

On Wed, 07 Jul 2021 18:24:46 + Lin Qigang  wrote:

> Changes since the last upload:
> 
>  btcheck (2.1-5) experimental; urgency=medium
>  .
>    * debian/upstream/metadata: Added upstream metadata
> 

The title says "ITA", so likely you've forgotten to close the ITA bug in
d/changelog…

Did you see
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=969805 ?

You do have undocumented changes (not mentioned in d/changelog).
Please document every single change.

-- 
tobi

Bug#991988: cool-retro-term: repacks due to dfsg, but does not have +dfsg suffix

[Tobias Frost]

Source: cool-retro-term
Severity: important

(Found in review #990722)

- I see in "README.source": 

> repackaged to include qmltermwidget
> 
> dropped these fonts
> app/qml/fonts/modern-monaco: not distributable (Apple)
> (...)


--
tobi

Bug#991987: cool-retro-term: Embeds third party library which should be packaged separatly.

[Tobias Frost]

Source: cool-retro-term
Severity: wishlist

(found in review #990722)

Note: The libary upstream is.
https://github.com/Swordfish90/qmltermwidget
(Same upstream author as cool-retro-term, seems to be used also for
ubuntu-terminal-app (not in Debian))

Note that the library is not included in the (cool-retro-term) upstream tarball,
so at least it should have its own orig.tar.

-- 
tobi

Bug#991986: cool-retro-term: [cool-retro-term] Watchfile does not work

[Tobias Frost]

Source: cool-retro-term
Version: 1.1.1+git20200723-1
Severity: minor

Found as part of review on #990722.

The watch-file does not work:
tobi@isildor:~/workspace/deb/mentors/GürkanMyczko/cool-retro-term/new/cool-retro-term-1.1.1+git20210605$
 uscan --verbose --download-current-version

uscan info: uscan (version 2.21.3) See uscan(1) for help
uscan info: Scan watch files in .
uscan info: Check debian/watch and debian/changelog in ./packaging
uscan info: package="cool-retro-term" version="0.9-1" (as seen in 
debian/changelog)
uscan warn: The directory name packaging doesn't match the requirement of
   --check-dirname-level=1 --check-dirname-regex=cool\-retro\-term(-.+)? .
   Set --check-dirname-level=0 to disable this sanity check feature., skipping
uscan info: Check debian/watch and debian/changelog in .
uscan info: package="cool-retro-term" version="1.1.1+git20210605-1" (as seen in 
debian/changelog)
uscan info: package="cool-retro-term" version="1.1.1+git20210605" (no 
epoch/revision)
uscan info: ./debian/changelog sets package="cool-retro-term" 
version="1.1.1+git20210605"
uscan info: Process watch file at: debian/watch
package = cool-retro-term
version = 1.1.1+git20210605
pkg_dir = .
uscan info: opts: filenamemangle=s%(?:.*?)?v?(\d[\d.]*)\.tar\.gz%$1.tar.gz%
uscan info: line: https://github.com/Swordfish90/cool-retro-term/tags 
(?:.*?/)?v?(\d[\d.]*)\.tar\.gz debian uupdate
uscan info: Parsing filenamemangle=s%(?:.*?)?v?(\d[\d.]*)\.tar\.gz%$1.tar.gz%
uscan info: line: https://github.com/Swordfish90/cool-retro-term/tags 
(?:.*?/)?v?(\d[\d.]*)\.tar\.gz debian uupdate
uscan info: Last orig.tar.* tarball version (from debian/changelog): 
1.1.1+git20210605
uscan info: Download the --download-current-version specified version: 
1.1.1+git20210605
uscan info: Requesting URL:
   https://github.com/Swordfish90/cool-retro-term/tags
uscan info: Matching pattern:
   
(?:(?:https://github.com)?\/Swordfish90\/cool\-retro\-term\/)?(?:.*?/)?v?(\d[\d.]*)\.tar\.gz
uscan info: Found the following matching hrefs on the web page (newest first):
   
https://github.com/Swordfish90/cool-retro-term/archive/refs/tags/1.1.1.tar.gz 
(1.1.1) index=1.1.1-1 
   
https://github.com/Swordfish90/cool-retro-term/archive/refs/tags/1.1.1.tar.gz 
(1.1.1) index=1.1.1-1 
   
https://github.com/Swordfish90/cool-retro-term/archive/refs/tags/1.1.0.tar.gz 
(1.1.0) index=1.1.0-1 
   
https://github.com/Swordfish90/cool-retro-term/archive/refs/tags/1.1.0.tar.gz 
(1.1.0) index=1.1.0-1 
   
https://github.com/Swordfish90/cool-retro-term/archive/refs/tags/1.0.1.tar.gz 
(1.0.1) index=1.0.1-1 
   
https://github.com/Swordfish90/cool-retro-term/archive/refs/tags/1.0.1.tar.gz 
(1.0.1) index=1.0.1-1 
   
https://github.com/Swordfish90/cool-retro-term/archive/refs/tags/v1.0.0.tar.gz 
(1.0.0) index=1.0.0-1 
   
https://github.com/Swordfish90/cool-retro-term/archive/refs/tags/v1.0.0.tar.gz 
(1.0.0) index=1.0.0-1 
uscan warn: In debian/watch no matching hrefs for version 1.1.1+git20210605 in 
watch line
  https://github.com/Swordfish90/cool-retro-term/tags 
(?:.*?/)?v?(\d[\d.]*)\.tar\.gz debian uupdate
uscan info: Scan finished

Bug#991985: cool-retro-term: [cool-retro-term] d/copyright is incomplete

[Tobias Frost]

Source: cool-retro-term
Version: 
Severity: serious
Justification: §4.5

(found as part of review for #990722)

qmltermwidget seems to be partly GPL-2+ and LPGL-2+; both not documented. There
is at least one cmake files that seems to be BSD

--
tobi

Bug#991689: Possible CVE-2014-5461 in moarvm-dev

[Dominique Dumont]

Hi

On vendredi 30 juillet 2021 12:22:59 CEST you wrote:
> moarvm-dev uses the obsolete version of minilua
> (single-file port of Lua) which has CVE-2014-5461

Exploiting this CVE requires feeding arbitrary lua code to moarvm. I don't 
think this is possible. So I won't patch directly moarvm.

Nevertheless, I'll forward this bug upstream.

All the best

Bug#990722: RFS: cool-retro-term/1.1.1+git20210605-1 -- terminal emulator which mimics old screens

[Tobias Frost]

Control: tags -1 moreinfo

Hi Gürkan,

Regarding cool-retro-term:

- I see in "README.source": 

> repackaged to include qmltermwidget
> 
> dropped these fonts
> app/qml/fonts/modern-monaco: not distributable (Apple)
> (...)

But I do not see a +dfsg nor a Files-Excluded in d/copyright to automatically
repack.  (this bug is already present in past uploads; will file a bug)

- It is not the proper to include qmltermwidget. it should be packaged
separately.  (this bug is already present in past uploads; will file a bug)

- d/copyright is buggy.  (this bug is already present in past uploads; will file
a RC bug)
- qmltermwidget seems to be partly GPL-2+ and LPGL-2+; both not
documented. There is at least one cmake files that seems to be BSD

- the patches only have boilerplate dep3 headers and therefore their intentions
is nor really obvious.

- Watch file is not working. If you package git snapshots, it needs also
be able to pick those up.  (this bug is already present in past uploads; will
file a bug)

- I could not match the upstream version to the version being sponsored.
The version string in d/changelog indicates it is git version from
June 05th, 2021 however, there is no commit on that date upstream; the
last one before that date is March 25th [1]. However, the downloaded
zip content does not match this debian source package.

This is a show stopper.

[1]
https://github.com/Swordfish90/cool-retro-term/tree/39181f42cf859952b1d880879791ef5a9b7adad0
>  

- Is this upload suppose to fix #988502? (as you point to the RFS in that bug)


- Lintian (I'm not sure whether they have merit, though; /me not an font
expert.)

W: cool-retro-term source: absolute-symbolic-link-target-in-source
app/qml/fonts/1971-ibm-3278/3270-Regular.ttf ->
/usr/share/fonts/opentype/3270/3270-Regular.otf
W: cool-retro-term source: absolute-symbolic-link-target-in-source
app/qml/fonts/1979-atari-400-800/AtariClassic-Regular.ttf ->
/usr/share/fonts/truetype/fonts-atarismall/AtariSmall.ttf
W: cool-retro-term source: absolute-symbolic-link-target-in-source
app/qml/fonts/1981-ibm-pc/PxPlus_IBM_BIOS.ttf ->
/usr/share/fonts/pc/Px_IBM_BIOS.ttf
W: cool-retro-term source: absolute-symbolic-link-target-in-source
app/qml/fonts/1985-ibm-pc-vga/PxPlus_IBM_VGA8.ttf ->
/usr/share/fonts/pc/Px_IBM_VGA8.ttf
W: cool-retro-term source: absolute-symbolic-link-target-in-source
app/qml/fonts/modern-inconsolata/Inconsolata.otf ->
/usr/share/fonts/truetype/inconsolata/Inconsolata.otf

(I did not find those symlinks in the upstream repo)

W: cool-retro-term source: inconsistent-appstream-metadata-license
packaging/appdata/cool-retro-term.appdata.xml (mit != gpl-3)
W: fonts-hermit: opentype-font-prohibits-installable-embedding [edit only]
usr/share/fonts/truetype/hermit/Hermit-bold.otf
W: fonts-hermit: opentype-font-prohibits-installable-embedding [edit only]
usr/share/fonts/truetype/hermit/Hermit-light.otf
W: fonts-hermit: opentype-font-prohibits-installable-embedding [edit only]
usr/share/fonts/truetype/hermit/Hermit-medium.otf
I: qml-module-qmltermwidget: package-contains-documentation-outside-usr-share-
doc usr/lib/x86_64-linux-gnu/qt5/qml/QMLTermWidget/kb-layouts/README
I: cool-retro-term source: patch-not-forwarded-upstream debian/patches/drop-non-
free-fonts
I: cool-retro-term source: quilt-patch-using-template-description drop-non-free-
fonts
I: cool-retro-term source: quilt-patch-using-template-description strip-non-
free-fonts
I: cool-retro-term: spelling-error-in-binary usr/bin/cool-retro-term NAm Name
X: cool-retro-term source: debian-watch-does-not-check-gpg-signature
P: cool-retro-term source: maintainer-manual-page debian/cool-retro-term.1



On Mon, 05 Jul 2021 17:45:35 +0200 =?UTF-8?Q?G=C3=BCrkan_Myczko?=
 wrote:
> Package: sponsorship-requests
> Severity: normal
> 
> Dear mentors,
> 
> I am looking for a sponsor for my package "cool-retro-term":
> 
>   * Package name    : cool-retro-term
> Version : 1.1.1+git20210605-1
> Upstream Author : Filippo Scognamiglio 
>   * URL : https://github.com/Swordfish90/cool-retro-term
>   * License : OFL-1.1, dfsg-compliant-text, BSD-3-clause, MIT, 
> GPL-3
>   * Vcs : 
> https://salsa.debian.org/myczko-guest/cool-retro-term
> Section : x11
> 
> It builds those binary packages:
> 
>    fonts-proggy - Monospaced bitmap programming font
>    fonts-terminus - Terminus monospace font
>    fonts-hermit - Monospace Hermit Font for programming
>    qml-module-qmltermwidget - QML port of qtermwidget
>    cool-retro-term - terminal emulator which mimics old screens
> 
> To access further information about this package, please visit the 
> following URL:
> 
>    https://mentors.debian.net/package/cool-retro-term/
> 
> Alternatively, one can download the package with dget using this 
> command:
> 
>    dget -x 
>
https://mentors.debian.net/debian/pool/main/c/cool-retro-term/cool-retro-term_1.1.1+git20210605-1.dsc
> 
> Changes since the last upload:
> 
>   

Bug#987675: sensible-utils: select-editor misbehaves on missing HOME variable

[Bastien Roucariès]

Package: sensible-utils
Version: 0.0.14
Followup-For: Bug #987675
Control: block -1 by 991984

This bug is really hard to fix.

Even your proposition to use getent will fail because under env -i $USER is not
set.

So for now, sensible-utils will check if $HOME is set, and if not set use
fallback to EDITOR, SELECTED_EDITOR, and editor

Note that nano should also be fixed see #991984

Bastien

Bug#991718: u-boot-sifive: only 8GB RAM visible on Sifive Unmatched

[Adam Borowski]

On Thu, Aug 05, 2021 at 12:26:57PM -0700, Tianon Gravi wrote:
> > On 2021-07-30, Adam Borowski wrote:
> > > The Unmatched has 16GB memory -- which works fine with the vendor u-boot
> > > it shipped with.  Alas, with Debian u-boot from experimental, only 8GB is
> > > visible (at 0x8000-0x00027fff).

> I think it must be related to the combination of newer
> u-boot and new (upstream) kernel?

In -next there's:
commit d09560435cb712c9ec1e62b8a43a79b0af69fe77
Author: Qiu Wenbo 
Date:   Sun Jul 4 16:34:41 2021 +0800

riscv: dts: fix memory size for the SiFive HiFive Unmatched

The production version of HiFive Unmatched have 16GB memory.

Signed-off-by: Qiu Wenbo 
Signed-off-by: Palmer Dabbelt 

--- a/arch/riscv/boot/dts/sifive/hifive-unmatched-a00.dts
+++ b/arch/riscv/boot/dts/sifive/hifive-unmatched-a00.dts
@@ -24,7 +24,7 @@ cpus {

memory@8000 {
device_type = "memory";
-   reg = <0x0 0x8000 0x2 0x>;
+   reg = <0x0 0x8000 0x4 0x>;
};

soc {

Applying that gives me the full memory back.

> davidlt sent the following note on IRC, which I think is related:
> 
> |  tianon, the current DT was written for a different
> revision board (A00) pre-production
> |  tianon, I hope to send out a new DT for 3A0 and 3B0 boards

Somehow, that kernel patch applies to -a00.dts, without distinguishing
board revisions.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ How to exploit the Bible for weight loss:
⢿⡄⠘⠷⠚⠋⠀ Pr28:25: he that putteth his trust in the ʟᴏʀᴅ shall be made fat.
⠈⠳⣄

Bug#991984: Please document minimal environment variable needed for sensible-utils

[Bastien Roucariès]

Package: debian-policy
Version: 4.5.1.0
Severity: important
Control: block 991982 by -1
Control: block 987675 by -1


Dear Maintainer,

For now $env -i sensible-utils, fail due to $HOME and $TERM not set.

I am for now working around HOME not set in sensible-utils core, but posix [1]
documentation does not document really the value that should be set for a
correct behavior of program.

Nevertheless:
- we should expect that PATH is set to a sensible value (note that it depends
of the shell), but nevertheless not setting PATH is not really safe
- HOME may not be set. If set the value may be incorrect (su -)
- TERM may not be set. If set the value may not be correct
- USER may not be set. If set the value may be incorrect (su -)

So I will like to have a footnote saying that sensible-pager/sensible-editor
etc, should test if they work under env -i, and if they do not work fallback to
return 126 (according to shell documentation Command invoked cannot execute),
thus allowing sensible-utils to fallback to vi that is safe and tested under
env -i

Bastien




[1] https://pubs.opengroup.org/onlinepubs/9699919799/

Bug#991983: ITP: q2-gneiss -- QIIME2 plugin for Compositional Data Analysis and Visualization

[Steffen Moeller]

Package: wnpp
Severity: wishlist

Subject: ITP: q2-gneiss -- QIIME2 plugin for Compositional Data Analysis and 
Visualization
Package: wnpp
Owner: Steffen Moeller 
Severity: wishlist

* Package name: q2-gneiss
  Version : 2020.11.1
  Upstream Author : QIIME 2 development team
* URL : https://qiime2.org/
* License : BSD-3-clause
  Programming Lang: Python
  Description : QIIME2 plugin for Compositional Data Analysis and 
Visualization
 QIIME 2 is a powerful, extensible, and decentralized microbiome analysis
 package with a focus on data and analysis transparency. QIIME 2 enables
 researchers to start an analysis with raw DNA sequence data and finish with
 publication-quality figures and statistical results.
 Key features:
  * Integrated and automatic tracking of data provenance
  * Semantic type system
  * Plugin system for extending microbiome analysis functionality
  * Support for multiple types of user interfaces (e.g. API, command line,
 graphical)
 .
 QIIME 2 is a complete redesign and rewrite of the QIIME 1 microbiome analysis
 pipeline. QIIME 2 will address many of the limitations of QIIME 1, while
 retaining the features that makes QIIME 1 a powerful and widely-used analysis
 pipeline.
 .
 QIIME 2 currently supports an initial end-to-end microbiome analysis pipeline.
 New functionality will regularly become available through QIIME 2 plugins. You
 can view a list of plugins that are currently available on the QIIME 2 plugin
 availability page. The future plugins page lists plugins that are being
 developed.

Remark: This package is maintained by Debian Med Packaging Team at
   https://salsa.debian.org/med-team/q2-quality-filter

Bug#991982: nano does not work with TERM unsetted

[Bastien Roucariès]

Package: nano
Version: 5.4-2
Severity: grave
Tags: upstream buster-ignore bullseye-ignore
Justification: Policy 11.4
Control: affects -1 sensible-utils

Dear Maintainer,

Feel free to downgrade to important, but this bug affects sensible utils in
case of disaster recovery so mark as grave (nano is the default system editor)

$env -i nano
command fail because TERM is unset

nano should warn in this case and do like vi fallback to some dumb terminal
setting

For now I will work around in sensible utils, but ping me back when solved

Bastien

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

[Ariadne Conill]

Hi,

On Sat, 7 Aug 2021, Thorsten Glaser wrote:


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…


It turns out SNI is only marginally related to this issue.  The issue 
itself is far more severe: HTParse() does not understand the authn part of 
the URI at all.  And so, when you call:


  HTParse("https://foo:b...@example.com;, "", PARSE_HOST)

It returns:

  foo:b...@example.com

Which is then handed directly to SSL_set_tlsext_host_name() or 
gnutls_server_name_set().  But it will also leak in the Host: header on 
unencrypted connections, and also probably SSL ones too.


As a workaround, I taught HTParse() how to parse the authn part of URIs, 
but Lynx itself needs to actually properly support the authn part really.


I have attached the patch Alpine is using to work around this infoleak.

Ariadne--- lynx2.8.9rel.1.orig/WWW/Library/Implementation/HTParse.c
+++ lynx2.8.9rel.1/WWW/Library/Implementation/HTParse.c
@@ -31,6 +31,7 @@
 
 struct struct_parts {
 char *access;
+char *auth;
 char *host;
 char *absolute;
 char *relative;
@@ -121,6 +122,18 @@
 }
 
 /*
+ * Scan left-to-right for an authentication username/password combination 
(auth).
+ */
+for (p = after_access; *p; p++) {
+   if (*p == '@') {
+   parts->auth = after_access;
+   *p = '\0';
+   after_access = (p + 1); /* advance base pointer forward */
+   break;
+   }
+}
+
+/*
  * Scan left-to-right for a fragment (anchor).
  */
 for (p = after_access; *p; p++) {
@@ -135,10 +148,14 @@
  * Scan left-to-right for a host or absolute path.
  */
 p = after_access;
-if (*p == '/') {
-   if (p[1] == '/') {
-   parts->host = (p + 2);  /* host has been specified*/
-   *p = '\0';  /* Terminate access   */
+if (*p == '/' || parts->auth) {
+   if (p[1] == '/' || parts->auth) {
+if (!parts->auth) {
+parts->host = (p + 2); /* host has been specified*/
+*p = '\0'; /* Terminate access   */
+} else {
+parts->host = p;
+}
p = StrChr(parts->host, '/');   /* look for end of host name if 
any */
if (p != NULL) {
*p = '\0';  /* Terminate host */

Bug#836324: tightvncserver: Typing gives wrong keys in some apps

[Sven Geuer]

Control: tags -1 = unreproducible,moreinfo

Hi Matthew,

On Thu, 01 Sep 2016 12:43:16 -0400 Matthew Gabeler-Lee
 wrote:
> Package: tightvncserver
> Version: 1.3.9-8
> Severity: important
> 
> tightvncserver was working fine for me for a long time until I
> restarted my VNC server session recently.  Now I find that in most
> apps I can type fine, but certain apps get the keys all wrong. 
> Nearly the entire un-shifted US keyboard (letters and numbers) are 
> coming out wrong.
[...]

I tried to reproduce your observation using tightvncserver 1:1.3.10-3
but didn't encounter any key mapping issues.

Can you provide me with instuctions how to verify this bugs still
persists?

Sven

-- 
GPG Fingerprint
3DF5 E8AA 43FC 9FDF D086 F195 ADF5 0EDA F8AD D585


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

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

[Witold Baryluk]

Package: debian-installer
Followup-For: Bug #991951

Hi Samuel.

> 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.

Thanks for testing.

>> 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?

This is qemu from Fedora 34. The Fedora is running kernel 
5.12.15-300.fc34.x86_64.
The system is a VM running on top of Proxmox 6.4-13 with Debian buster,
on top of AMD EPYC 7502P, and kernel Linux 5.4.124-1-pve #1 SMP PVE 5.4.124-2 
(Tue, 20 Jul 2021 21:43:44 +0200).

$ qemu-system-x86_64 --version
QEMU emulator version 5.2.0 (qemu-5.2.0-8.fc34)
Copyright (c) 2003-2020 Fabrice Bellard and the QEMU Project developers
$

No other qemu options.

I belive now this is a bug in the kvm and nested virtualisation. With no
--enable-kvm (using software emulation), the installation proceed fine
with 512 and 1024 MB.

I also now tested it on non-virtualized Debian testing, and it works
fine with kvm and 512MB.

It even works okish with 360 MB (no network cards detected tho then for
some reasons).

>> Select "Install" (text installer, not graphical one).
> I.e. the second boot option? (the 64bit variant)

Correct. Second boot option, the 64-bit variant.

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

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

Correct.

>> 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?

Correct. But, now I was able to trigger the hang even ealier, just after
kernel boot. As I said above, I belive the issue is qemu kvm and nested
virtualisation actually, not debian installer.

> 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.

Ack.

Please close.

(Network card detection failure when running with 360MB should be
addressed separately. It looks like
/lib/modules/5.10.0-8-amd64/kernel/drivers/net/ethernet has only one
driver present - cnci.ko , not sure how to load others).


Regards,
Witold

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

[Holger Wansing]

Hi,

Am 7. August 2021 09:01:56 MESZ schrieb "McIntyre, Vincent (S, Marsfield)" 
:
>On Sat, Aug 07, 2021 at 07:40:52AM +0200, Paul Gevers wrote:
>>+
>>+  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.
>>+
>
>How about
>
>+  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 a new feature. If some of the installed hardware
>+  requires firmware files to be installed, the installer will try
>+  to add them to the system, based on a mapping from hardware ID
>+  to firmware file names.

I would second the last sentence of Vincents proposal ("If some of 
your...") since it's easier understandable.
(I was already unhappy with the original wording, which has been 
proposed by Charles on debian-boot.)

Holger



-- 
Sent from /e/ OS on Fairphone3

Bug#991981: python3-skbio: package installs .../dist-packages/benchmarks/..

[Steffen Moeller]

Package: python3-skbio
Version: 0.5.6-4
Severity: normal

Dear Maintainer,

Unpacking python3-skbio (0.5.6-4) ...
dpkg: error processing archive 
/var/cache/apt/archives/python3-skbio_0.5.6-4_amd64.deb (--unpack):
 trying to overwrite '/usr/lib/python3/dist-packages/benchmarks/__init__.py', 
which is also in package cutesv 1.0.11-1
dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
Errors were encountered while processing:
 /var/cache/apt/archives/python3-skbio_0.5.6-4_amd64.deb

I just fixed cutesv, leaving this as a reminder to also fix skbio.

Cheers,
Steffen

Bug#613856: tightvncserver: drag and drop doesn't work

[Sven Geuer]

Control: tags -1 = unreproducible,moreinfo

Hello Fritz,

On Thu, 17 Feb 2011 20:24:50 +0100 dl 
wrote:
> Package: tightvncserver
> Version: 1.3.9-6.1+b1
> Severity: important
> 
> I can't use drag'n drop using the mouse from my client machine, for 
> example to move a file from one folder to another, when connected to 
> the tightvncserver in the gnome desktop environment. I am running 
> squeeze AMD64.
> 
> I guess it's the same bug described here for Ubuntu:
> http://ubuntuforums.org/showthread.php?t=1497635
> 

Modern Gnome is not supported by Tightvnc. Drag & drop works for me on
tightvncserver 1:1.3.10-3 running a mate desktop.

Do you still see this issue in a recent desktop environment? If so,
please provide me the details how to reproduce it.

Sven

-- 
GPG Fingerprint
3DF5 E8AA 43FC 9FDF D086 F195 ADF5 0EDA F8AD D585


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

Bug#991980: libjsap-java: does not incorporate /usr/share/java/xstream.jar in the jar manifest

[Pierre Gruet]

Package: libjsap-java
Version: 2.1-3.1
Severity: normal

Dear Maintainer,

libjsap-java depends on libxstream-java and indeed needs its jar
/usr/share/java/xstream.jar, however the latter is not correctly referenced in
the MANIFEST file of /usr/share/java/jsap.jar.

As a consequence, I get
Exception in thread "main" java.lang.NoClassDefFoundError: 
com/thoughtworks/xstream/XStream
in some code using /usr/share/java/jsap.jar.

As the package is team-maintained, I intend to fix this myself in a few days,
right after the bullseye release.

Best regards,

Pierre Gruet

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

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

Versions of packages libjsap-java depends on:
ii  libxstream-java  1.4.15-3

libjsap-java recommends no packages.

Versions of packages libjsap-java suggests:
pn  libjsap-java-doc  

-- no debconf information

Bug#795797: git-buildpackage: please ignore .pc folders

[Sébastien Villemot]

Le mercredi 19 août 2015 à 17:07 +0200, Guido Günther a écrit :
> 
> On Wed, Aug 19, 2015 at 10:34:56AM +0200, Bernd Zeimetz wrote:
> > 
> > > I get .pc/ but lots of other modifications in the source tree as well
> > > (as it's the point of applying patches). If I then unapply:
> > > 
> > > quilt pop -a
> > > 
> > > .pc/ is being removed as well. I remember that not being always the case
> > > though in the (long gone) past.
> > 
> > Thats interesting, i think it never happened to me that the .pc folder
> > was gone. Do you have any other quilt options being set? Or some
> > non-default options in /etc/quilt.quiltrc?
> 
> No configuration on my end. This is quilt 0.63 as in
> stable/testing/unstable.
> 
> Is there any content left in .pc ?
> 
> It would actually be nicer to fix this on the quilt side than adding a
> workaround to gbp. 

I’m also affected by this issue.

But is quilt really supposed to remove the .pc directory?

The quilt(1) manpage says:

 Files in the .pc directory are automatically removed when they are
 no longer needed, so there is no need to clean up manually.

Note that this mentions only files, and not the directory itself.

Moreover, there is bug #496630 opened against quilt that asks for a new
command that would precisely delete the .pc folder (and someone
suggests to rather add this behaviour to the “pop” command, implying
that it is not implemented).

Finally, I looked at the source code for the “quilt pop” command and I
saw nothing related to removing the .pc directory.

So, unless I’m missing something, this issue is not a bug in quilt, and
it should thus be fixed in git-buildpackage (unless someone convinces
the quilt upstream authors to implement a change in behaviour).

-- 
⢀⣴⠾⠻⢶⣦⠀  Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁  Debian Developer
⢿⡄⠘⠷⠚⠋⠀  https://sebastien.villemot.name
⠈⠳⣄  https://www.debian.org



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

Bug#774624: xtightvncviewer: Crash (stack smashing) of listening vncviewer

[Sven Geuer]

Control: tags -1 = wontfix

On Mon, 05 Jan 2015 14:47:25 +0100 Stefan Weil  wrote:
> Package: tightvnc
> Severity: important
> 
> TightVNC includes the same bug which was reported for ssvnc
> (see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=774622).
> 
> As the related source code is also identical, the fix given
> in that bug report also applies to package tightvnc.
> 

Note in bug 774622:

On Tue, 06 Jan 2015 12:56:28 +0100 Stefan Weil  wrote:
> The crash is triggered by the IPv6 connection used in our test
> scenario: 
> struct sockaddr_in is only sufficient for IPv4, but IPv6 needs struct
> sockaddr_in6.
> 
[...]

Thightvnc is old software not supporting IPv6 at all. Upstream does not
maintain Thightvnc on Linux any more. Thus, do not expect IPv6 support
to show up in Tightvnc.

Sven

-- 
GPG Fingerprint
3DF5 E8AA 43FC 9FDF D086 F195 ADF5 0EDA F8AD D585


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

Bug#991853: reassign to ftp.debian.org

[Tomas Pospisek]

reassign 991853 ftp.debian.org
thanks

the archive.debian.org certificate problem seems to rather concern the 
ftp.debian.org pseudo package & DDs, thus I'm reassigning to it.

Bug#968415: A year later…

[Joseph Carter]

I think we may have lost David? He doesn't seem to be responding to bug reports 
based upon his maintainer page on the BTS. Open bugs going back to 2013 (not 
unusual) but the five of the same bug from that date remain unmerged.

Anyone heard from him by chance? Hope he's all right.

Joseph

Bug#991979: python3: SSL errors trigger asyncio loop exceptions

[Maximilian Stein]

Package: python3
Version: 3.7.3-1
Severity: normal

Dear Maintainer,

I noticed an issue using aiohttp with Python 3.7.3 in Debian Buster.
When a request fails due to SSL certificate problems there are
asyncio loop exceptions triggered — although my code is wrapped in a
try-except-block, mwe:

import aiohttp
import asyncio

URI = 'https://www.debian.org/'

async def main():
print(">>BEGIN")
try:
async with aiohttp.request('GET', URI) as resp:
data = await resp.text()
except BaseException as e:
print(f"ERROR: {e!r}")
print(">>DONE")

if __name__ == '__main__':
asyncio.run(main())

Running this code with failing SSL, e.g. as `faketime 2025-01-01
python3 ./testssl.py` triggers loop exceptions that completely bypass
my exception handler:

>>BEGIN
SSL handshake failed on verifying the certificate
protocol: 
transport: <_SelectorSocketTransport fd=8 read=polling write=>
Traceback (most recent call last):
  File "/usr/lib/python3.7/asyncio/sslproto.py", line 625, in 
_on_handshake_complete
raise handshake_exc
  File "/usr/lib/python3.7/asyncio/sslproto.py", line 189, in feed_ssldata
self._sslobj.do_handshake()
  File "/usr/lib/python3.7/ssl.py", line 763, in do_handshake
self._sslobj.do_handshake()
ssl.SSLCertVerificationError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate 
verify failed:
certificate has expired (_ssl.c:1056)
SSL error in data received
...
ERROR: ClientConnectorCertificateError()
>>DONE
Unclosed client session
client_session: 

Moreover, the stack traces are not related to my code at all and the
"Unclosed client session" message indicates that the cleanup code in
the `async with` statement did not run either.

Using Python 3.9.2 with aiohttp 3.7.4-1 works like intended in this
case: There is only the message from my exception handler:

>>BEGIN
ERROR: ClientConnectorCertificateError(ConnectionKey(host='www.debian.org', 
port=443,
is_ssl=True, ssl=None, proxy=None, proxy_auth=None, 
proxy_headers_hash=None),
SSLCertVerificationError(1, '[SSL: CERTIFICATE_VERIFY_FAILED] 
certificate verify
failed: certificate has expired (_ssl.c:1123)'))
>>DONE

Since the code in the stack trace from the loop's handler above
indicates an issue in Python itself, I reported against python3,
however, I am not entirely sure if this is a problem in Python or in
aiohttp.

Best,
Maximilian

Bug#991978: zram-tools: running zramswap with kernel 5.10.52 #1441 result in cpu warning

[UN-pi]

Package: zram-tools
Version: 0.3.2.1-1
Severity: normal
Tags: a11y

Dear Maintainer,

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

   * What led up to the situation?
zramswap was running before #1441 without problems
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
after installting kernel update #1441 the system was running for ca. 2 days.
   * What was the outcome of this action?
Aug  7 07:30:01 nextcloudpi kernel: [120894.788674] [ cut here 
]
Aug  7 07:30:01 nextcloudpi kernel: [120894.788712] WARNING: CPU: 3 PID: 14802 
at kernel/rcu/tree_plugin.h:297 rcu_note_context_switch+0x64/0x428
Aug  7 07:30:01 nextcloudpi kernel: [120894.788715] Modules linked in: 
binfmt_misc zram zsmalloc md4 md5 nls_utf8 cifs libarc4 nft_ct tun cfg80211 
rfkill 8021q garp stp llc sg vc4 cec v3d bcm283
Aug  7 07:30:01 nextcloudpi kernel: [120894.788906]  sha256_generic 
aes_neon_blk crypto_simd cryptd ip_tables x_tables ipv6 [last unloaded: 
zsmalloc]
Aug  7 07:30:01 nextcloudpi kernel: [120894.788931] CPU: 3 PID: 14802 Comm: 
cron Tainted: G C5.10.52-v8+ #1441
Aug  7 07:30:01 nextcloudpi kernel: [120894.788934] Hardware name: Raspberry Pi 
4 Model B Rev 1.2 (DT)
Aug  7 07:30:01 nextcloudpi kernel: [120894.788940] pstate: 2085 (nzCv daIf 
-PAN -UAO -TCO BTYPE=--)
Aug  7 07:30:01 nextcloudpi kernel: [120894.788945] pc : 
rcu_note_context_switch+0x64/0x428
Aug  7 07:30:01 nextcloudpi kernel: [120894.788949] lr : 
rcu_note_context_switch+0x54/0x428
Aug  7 07:30:01 nextcloudpi kernel: [120894.788951] sp : ffc013bd3ac0
Aug  7 07:30:01 nextcloudpi kernel: [120894.788954] x29: ffc013bd3ac0 x28: 
ff806b771e40.
Aug  7 07:30:01 nextcloudpi kernel: [120894.788961] x27:  x26: 
ffc011476000.
Aug  7 07:30:01 nextcloudpi kernel: [120894.788968] x25:  x24: 
ff807fbbf240.
Aug  7 07:30:01 nextcloudpi kernel: [120894.788973] x23:  x22: 
ff806b771e40.
Aug  7 07:30:01 nextcloudpi kernel: [120894.788979] x21: ffc011462328 x20: 
ffc011298948.
Aug  7 07:30:01 nextcloudpi kernel: [120894.788986] x19: ff807fbbfec0 x18: 
.
Aug  7 07:30:01 nextcloudpi kernel: [120894.788991] x17:  x16: 
.
Aug  7 07:30:01 nextcloudpi kernel: [120894.788997] x15:  x14: 
.
Aug  7 07:30:01 nextcloudpi kernel: [120894.789003] x13:  x12: 
.
Aug  7 07:30:01 nextcloudpi kernel: [120894.789009] x11:  x10: 
.
Aug  7 07:30:01 nextcloudpi kernel: [120894.789015] x9 : ffc010acffb8 x8 : 
.
Aug  7 07:30:01 nextcloudpi kernel: [120894.789021] x7 :  x6 : 
ffc013bd3ab0.
Aug  7 07:30:01 nextcloudpi kernel: [120894.789026] x5 : 0001 x4 : 
ffc06ebe3000.
Aug  7 07:30:01 nextcloudpi kernel: [120894.789033] x3 : 0001 x2 : 
ffc010fc7000.
Aug  7 07:30:01 nextcloudpi kernel: [120894.789039] x1 : ffc06ebe3000 x0 : 
0001.
Aug  7 07:30:01 nextcloudpi kernel: [120894.789046] Call trace:
Aug  7 07:30:01 nextcloudpi kernel: [120894.789051]  
rcu_note_context_switch+0x64/0x428
Aug  7 07:30:01 nextcloudpi kernel: [120894.789060]  __schedule+0xc8/0x818
Aug  7 07:30:01 nextcloudpi kernel: [120894.789063]  schedule+0x48/0x100
Aug  7 07:30:01 nextcloudpi kernel: [120894.789066]  io_schedule+0x24/0xb0
Aug  7 07:30:01 nextcloudpi kernel: [120894.789072]  
__lock_page_or_retry+0x1cc/0x498
Aug  7 07:30:01 nextcloudpi kernel: [120894.789077]  do_swap_page+0x1f4/0x700
Aug  7 07:30:01 nextcloudpi kernel: [120894.789081]  handle_mm_fault+0x4a8/0xcb8
Aug  7 07:30:01 nextcloudpi kernel: [120894.789085]  do_page_fault+0x148/0x3e8
Aug  7 07:30:01 nextcloudpi kernel: [120894.789089]  
do_translation_fault+0x58/0x70
Aug  7 07:30:01 nextcloudpi kernel: [120894.789095]  do_mem_abort+0x48/0xa8
Aug  7 07:30:01 nextcloudpi kernel: [120894.789099]  el0_da+0x40/0x58
Aug  7 07:30:01 nextcloudpi kernel: [120894.789104]  el0_sync_handler+0x68/0xb8
Aug  7 07:30:01 nextcloudpi kernel: [120894.789108]  el0_sync+0x180/0x1c0
Aug  7 07:30:01 nextcloudpi kernel: [120894.789112] ---[ end trace 
586c9eec844f90cf ]---

   * What outcome did you expect instead?
normal operation
*** End of the template - remove these template lines ***


-- System Information:
Debian Release: 10.10
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'proposed-updates'), (500, 
'stable')
Architecture: arm64 (aarch64)
Foreign Architectures: armhf

Kernel: Linux 5.10.52-v8+ (SMP w/4 CPU cores; PREEMPT)
Kernel taint flags: TAINT_WARN, TAINT_CRAP
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to de_DE.UTF-8), LANGUAGE=de_DE.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set 
to de_DE.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages 

Bug#991976: libclamav-dev: remove unnecessary dependency on libidn11-dev

[Simon Josefsson]

Package: libclamav-dev
Tags: patch

Hi!  I'm doing a shared library transition of libidn, and noticed a
strange dependency on libidn11-dev in the libclamav-dev package, and it
has been there since the beginning of (salsa git) times.  As far as I
can tell, nothing in clamav depends on libidn, so the dependency is
useless.  Can you confirm that?  If so, please drop the dependency.

/Simon

diff --git a/debian/control b/debian/control
index a20898d4..59f5f4f3 100644
--- a/debian/control
+++ b/debian/control
@@ -109,7 +109,6 @@ Architecture: any
 Depends: libbz2-dev,
  libc6-dev | libc-dev,
  libclamav9 (= ${binary:Version}),
- libidn11-dev,
  libssl-dev,
  libtommath-dev,
  zlib1g-dev,


signature.asc
Description: PGP signature

Bug#991604: freeipmi: symlink_to_dir conversion does not work for upgrade paths starting in wheezy

[Andreas Beckmann]

On 07/08/2021 10.49, Fabio Fantoni wrote:

Il 28/07/2021 21:47, Andreas Beckmann ha scritto:


Once the fix is uploaded my piuparts instance will run the long 
upgrade path test on all packages, and I'll tell you if something is 
still not right ;-)
Hi, can you run your piuparts test on the long upgrade for check that 
there are no other unexpected events please?


The tests already ran on Aug 2 after the package migrated and have not 
found any further issues ;-)



Andreas

Bug#991604: freeipmi: symlink_to_dir conversion does not work for upgrade paths starting in wheezy

[Fabio Fantoni]

Il 28/07/2021 21:47, Andreas Beckmann ha scritto:


Once the fix is uploaded my piuparts instance will run the long 
upgrade path test on all packages, and I'll tell you if something is 
still not right ;-)
Hi, can you run your piuparts test on the long upgrade for check that 
there are no other unexpected events please?






OpenPGP_signature
Description: OpenPGP digital signature

Bug#991977: snort: Snort sends no report

[Richard Lucassen]

Package: snort
Version: 2.9.15.1-5
Severity: normal

Dear Maintainer,

On my Bullseye SysV system, snort runs the daily report from 
/etc/cron.daily/snort-common. But as the /etc/cron.daily/ dir is run in an 
alphabetic order, "logrotate" is run before "snort-common" which reduces the 
snort log file to size zero or almost zero, ending up in no report or a 1 
second report.

Solution: rename /etc/cron.daily/snort-common to /etc/cron.daily/00snort-common.

Now /etc/cron.daily/snort-common is executed before logrotate.

R.

-- 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: sysvinit (via /sbin/init)

Versions of packages snort depends on:
ii  adduser  3.118
ii  debconf [debconf-2.0]1.5.77
ii  init-system-helpers  1.60
ii  libc62.31-13
pn  libdaq2  
pn  libdumbnet1  
ii  liblzma5 5.2.5-2
pn  libnetfilter-queue1  
ii  libnghttp2-141.43.0-1
ii  libpcap0.8   1.10.0-2
ii  libpcre3 2:8.39-13
ii  libssl1.11.1.1k-1
ii  logrotate3.18.0-2
ii  lsb-base 11.1.0
ii  net-tools1.60+git20181103.0eebece-1
pn  rsyslog | system-log-daemon  
pn  snort-common 
pn  snort-common-libraries   
pn  snort-rules-default  
ii  zlib1g   1:1.2.11.dfsg-2

Versions of packages snort recommends:
ii  iproute2  5.10.0-4

Versions of packages snort suggests:
pn  snort-doc  

Bug#991551: xcompmgr: Awful video tearing when xcompmgr is installed

[Pascal]

Package: xcompmgr
Version: 1.1.8-1
Followup-For: Bug #991551
X-Debbugs-Cc: pascal.mart...@gmx.fr

Dear Maintainer,

I generally never do that, but as installing xcompmgr calls absolutely no
dependencies (at least in my case), I just tried to install (via dpkg) version
1.1.7-1 instead of 1.1.8-1 (via apt).

It doesn't change anything, I get exactly the same video tearing with v1.1.7-1.

Conclusion : my bug report is not so relevant. So please remove it or keep it
as information and search of what is wrong elsewhere, in the dependencies which
may also have other dependencies.

With all my deepest apologies,

Cordially,
Pascal.

-- 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/2 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not
set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages xcompmgr depends on:
ii  libc6   2.31-13
ii  libx11-62:1.7.2-1
ii  libxcomposite1  1:0.4.5-1
ii  libxdamage1 1:1.1.5-2
ii  libxext62:1.3.3-1.1
ii  libxfixes3  1:5.0.3-2
ii  libxrender1 1:0.9.10-1

xcompmgr recommends no packages.

xcompmgr suggests no packages.

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

[Cyril Brulebois]

Justin B Rye  (2021-08-07):
> (I'm surprised that we can't link to ch06s04.html without the .en and
> have it automatically handle translations.  Anyone know a way of doing
> that?)

I'm quite confident this works:
  
https://www.debian.org/releases/bullseye/amd64/ch06s04#completing-installed-system

I'm seeing the French translation from my browser that ranks fr before
en, and the German one with the one that ranks de before en. That's why
I've used such links on dda@ plus the announce on the website:
  https://www.debian.org/devel/debian-installer/News/2021/20210802


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


signature.asc
Description: PGP signature

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

[Justin B Rye]

Paul Gevers wrote:
> Before pushing, I hope to see comments from Justin.
> 
> Paul

> +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

Only one minor comment: I'd drop the comma in "note, that".

> +  unofficial installer images with firmware included (see  +  
> url="#firmware_nonfree">#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  +  
> url="https://www.debian.org/releases/bullseye/amd64/ch06s04.en.html#completing-installed-system;>the
> +  dedicated chapter of the installation-guide.
> +
> +

(I'm surprised that we can't link to ch06s04.html without the .en and
have it automatically handle translations.  Anyone know a way of doing
that?)
-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package

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

[McIntyre, Vincent (S, Marsfield)]

On Sat, Aug 07, 2021 at 07:40:52AM +0200, Paul Gevers wrote:
>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.

I'll have a lash... I'm sure Justin can take it further though


>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.
>+

How about

+  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 a new feature. If some of the installed hardware
+  requires firmware files to be installed, the installer will try
+  to add them to the system, based on a mapping from hardware ID
+  to firmware file names.

>+
>+
>+  Please note, that this new functionality is restricted to the

I don't think the comma is needed. In fact why not just

+  This new functionality is restricted to the

>+  unofficial installer images with firmware included (see +  
>url="#firmware_nonfree">#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 +  
>url="https://www.debian.org/releases/bullseye/amd64/ch06s04.en.html#completing-installed-system;>the
>+  dedicated chapter of the installation-guide.
>+
>+
>
>-+2.30.2
>





-- 

Bug#991221: Acknowledgement (buster-pu: package mariadb-10.3 10.3.30-0+deb10u1)

[Otto Kekäläinen]

Control: retitle -1 buster-pu: package mariadb-10.3 10.3.31-0+deb10u1

New MariaDB 10.3.31 is out and it is also a security update. I'll take
this with the sec team since stable updates are not on the horizon
according to release.debian.org.

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

[Salvatore Bonaccorso]

Control: tags -1 + moreinfo

Hi,

On Fri, Aug 06, 2021 at 11:50:54AM -0700, Elliott Mitchell wrote:
> 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.

Can you please try to bisect which commit introduced the issue? Does
it affect as well current upstream 4.19.201?

Regards,
Salvatore