Bug#989882: fonts-dejavu-extra: Wrong glyph for 25EF LARGE CIRCLE in DejaVu Math TeXGyre

[G. Milde]

Package: fonts-dejavu-extra
Version: 2.37-1
Severity: normal

Dear Maintainer,


The glyph for Character '◯' (9711, 0x25EF) LARGE CIRCLE in the
DejaVu Math TeXGyre otf font shows a large *black* circle.

From the sample glyph and comparing with other fonts, I expect a *white*
circle (black large circle is 0x25CB).


As a result, the following page displays two large *black* circles in
Firefox with the default font setting (DejaVu):


http://www.w3.org/1999/xhtml"; xml:lang="en" lang="en">






http://www.w3.org/1998/Math/MathML"; display="block">
  ◯  ◯






A wrong symbol for the "circle operator" is a nontrivial problem for the use
of MathML with Firefox.


I checked with the latest version of the font on CTAN
(https://www.ctan.org/pkg/tex-gyre-math-dejavu) and still found the wrong
glyph.

Sincerely
Günter Milde

Bug#641138: Really old bug, Garmin hardware not mentioned.

[Robert Lipe]

The OP doesn't mention what hardware they have, which makes this hard to
say much about, but it looks like it's mixing two different use cases.

For "real" USB Garmins, as opposed to serial Garmins attached via a
USB/Serial adapters, there are basically two different models for using
Garmins with GPSBabel on Linux.

1) There is a Linux kernel module that grabs the USB interface, does "USB
Garmin stuff", and then presents the device as /dev/ttyUSBwhatever to any
apps that spoke the Garmin serial protocol.  This was neat for
compatibility, but this driver never actually worked very well. (Sorry.)
To use this, you'd load the kernel module and then use serial driver name
in the -f argument.
2) Let GPSBabel (almost) speak directly with the USB hardware. GPSBabel
communicates via libusb directly to the hardware and is cognizant of all
the (many, many) Garmin USB quirks and models. To use this, we'd use the
name "usb" instead of a /dev node.   usb:-1 would list device names and
usb:0 or usb:1 or whatever would handle the extremely uncommon case (unless
you were me) of having multiple USB Garmins.

The problem with #1 is that it didn't actually work very well and didn't
benefit from the wide exposure to Garmin hardware that GPSBabel natively
did. In particular, it had problems with tracks and routes, IIRC. It also
"hogged" the device and made it impossible for our libusb layer (the "-f
usb:" stuff) to actually speak the device. This problem was so common that
for a long time, we special cased the error message:

fatal("usb_set_configuration failed, probably because kernel driver '%s'\n
is blocking our access to the USB device.\n"
"For more information see https://www.gpsbabel.org/os/Linux_Hotplug.html\n";,
drvnm);

The code still peeks through at
https://github.com/GPSBabel/gpsbabel/blob/master/jeeps/gpslibusb.cc

Suggestion: mark this as closed. the error message was improved and the
fixes were deliver a long, long time ago. No devices using Garmin comm
protocol (current ones mount as mass storage devices and you basically copy
GPX files to/from them) since about 2008 or so. The libusb path is so
inconsequential it's being strongly considered for removal upstream because
of disuse and churn at the libusb api level.

Please close this issue.

Bug#907541: [openjdk-8] Bind to a multicast address fails

[Andre Naujoks]

Am 15.06.21 um 00:54 schrieb Thorsten Glaser:

tags 907541 + confirmed upstream
found 907541 openjdk-8/8u292-b10-1
found 907541 openjdk-11/11.0.12+4-1
thanks

On Wed, 29 Aug 2018, Andre Naujoks wrote:


This bugs affects all currently available Java versions in Debian (7, 8, 10 and 
11).
I don't know how to mark this here.


Normally, cloning the bug against all affected packages,
but I’m Cc’ing Doko on this hoping he’ll DTRT ☺


The contents of the patch should
be usable for all versions with very little change.

[…]

The attached patch fixes/adds this in the jvm.


This is another of these things where it’d be preferable to
fix this upstream first then apply the patch in Debian packages.
However it’s small and easily applied ahead of time. It’d be no
good if I’d fix this in openjdk-8 but 11 (and 17, possibly) are
unfixed; Doko?

Andre, can you report this upstream?


Hi Thorsten.

This was supposed to be fixed upstream in Java 12: 
https://bugs.openjdk.java.net/browse/JDK-8210493


However it was taken back again (see last comment in that issue) and is 
now supposedly fixed in java 13:

https://bugs.openjdk.java.net/browse/JDK-8215294
https://bugs.openjdk.java.net/browse/JDK-8216417

As far as I am aware, it works with current Java versions in Debian (>= 13).

I am not sure if Debian actually wants to carry this for the versions 
<13, as the patch somehow introduced other issues (see the upstream 
bug-reports).


It would be nice to have, but I'd understand if you'd decided against 
taking the patch after the back and forth that happened upstream.


Regards
  Andre



Thanks,
//mirabilos

Bug#989597: release.debian.org: upgrade issue: non-coinstallability of libgdal20 and libgdal28

[Andreas Beckmann]

On 15/06/2021 06.05, Sebastiaan Couwenberg wrote:

 From the many other packages I haven't seen other issues other than the
partial upgrade with monteverdi which is fixed with Breaks/Replaces.

I really need more concrete cases to justify changes to gdal that I
don't like but will have to maintain.


What about libmrpt-dev ? (log posted here yesterday)

Andreas

Bug#987181: RFS: cpufetch/0.97-1 -- Simple yet fancy CPU architecture fetching tool

[clay stan]

Tobias Frost  于2021年6月9日周三 上午2:03写道：
>
> On Tue, Jun 08, 2021 at 02:50:47PM +0800, clay stan wrote:
> > Tobias Frost  于2021年6月3日周四 上午1:33写道：
> > >
> > > Control: tags -1 moreinfo
> > >
> > > Hi Clay,
> > >
> > > here's a review:
> > > - The patch: The dep3 header, the field Bug-Debian is wrong, the ITP is 
> > > not
> > >   related to the patch
> >
> > Thanks, I've updated.
> >
> > > - The patch looks strange to me: Why do you patch the Makefile? What do 
> > > you
> > >   want to archieve? Parts of the patching seems ok (like avoiding 
> > > stomping over
> > > CFLAGS, but other parts seems excessive, removing sane parts to me…
> >
> > The original compilation parameters will also cause Lintian to report 
> > errors,
> > hardening no bind now, hardening no mandatory functions.
> > I'll try to solve them in debian/rules by
> > https://wiki.debian.org/Hardening, but it doesn't work
> >
> >and the sane parts, you mean?
>
> You've basically completly rewritten a (mostly) working Makefile
> With your comment I assume that you just wanted to have hardening,
> so _just_ those parts should have been patched.
> And that would be:
>
> --- a/Makefile
> +++ b/Makefile
> @@ -1,6 +1,6 @@
>  CC ?= gcc
>
> -CFLAGS+=-Wall -Wextra -pedantic -fstack-protector-all -pedantic -std=c99
> +CFLAGS:=-Wall -Wextra -pedantic -fstack-protector-all -pedantic -std=c99 
> ${CFLAGS} ${CPPFLAGS} ${LDFLAGS}
>  SANITY_FLAGS=-Wfloat-equal -Wshadow -Wpointer-arith
>
>  PREFIX ?= /usr
>
> (+ adding export DEB_BUILD_MAINT_OPTIONS = hardening=+all to d/rules)
>
> So, see it as recommendation: I'd keep patches really minimal. Or they
> will create you a lot of work…
>
> It is a burden to carry such an intrusive patch, especially if upstream
> explictly expressed that he does not generally welcome patches
> if they target the Makefile.
>
> Just one example where I think the upstream part is better:
> -PREFIX ?= /usr
> +PREFIX = /usr
>
> Some other stuff could be done with debhelper overrides, so
> that the patch can get smaller…

Take your advice, now patch only changed one line.

>
> But you do you… I just strongly recommend to revisit the topic.
> On top, non-upstreamable patches are bad…
>
> > >   - Upstream seems to support arm, you patch that out?
> >
> > Upstream support arm means the mobile arm chips, like Snapdragon, MediaTek,
> > not arm PC, They are not supported by Debian.
>
> This is not a strong reason to disable arm support entirely…
> (A quick internet search suggests that there is some support for Debian on e.g
> Snapdragon. And there seems to be derivates; even if not, maybe someone wants
> to enhance cpufetch on the basis of the Debian package.)

Add arm64 now.

>
> > >   - There is no LDCFLAGS -> did you mean LDFLAGS?
> >
> > Yeah, I've updated. Thanks again.
> >
> > >
> > > - (not a blocker) Please send the manpage upstream for inclusion.
>
> Regarding the manpage: I've diffed the manpage (cpufetch.1 and
> debian/cpufetch.1). They are almost identical. With just small fixes done by
> you. However, you claim (sole) copyright on it. That is not appropiate.

Previously, because there has a problem with the upstream manpage,
So I used help2man to regenerate a manpage then modify it,
so I  claim copyright on it.

But now I have contacted the upstream to repaired his manpage and
remove my manpage.

And I rebuild the package with a new version and upload to mentors:
https://mentors.debian.net/package/cpufetch
You can download the package with dget using this command:

  dget -x 
https://mentors.debian.net/debian/pool/main/c/cpufetch/cpufetch_0.98-1.dsc

Thanks again.


>
> I would patch the manpage, if it needs fixing: The header of the upstream ones
> says that upstream builds it using help2man (but hav not integrated that into
> their Makefile), so possibly this is another route to go: Rebuild at build
> time.
>
> --
> tobi

Bug#989179: aeskeyfind calculates wrong results on kernel 5.10.0.6 and glibc 2.31-11

[Jan Gru]

Hello Adrian, hello Samuel,


My reading of the code is that it was intended to be
-t = set_byte(t, (j-1)%4, sbox[get_byte(k,j)]);
+t = set_byte(t, (j-1+4)%4, sbox[get_byte(k,j)]);

It's looking good, I have uploaded 1:1.0-10 to unstable, hopefully
this was the only issue still affecting other archs.


glad, you found this value range issue to make aeskeyfind work on the 
other architectures!


Thanks a lot for working on this!

Best regards
    Jan

Bug#987149: xscreensaver: allows starting external programs with cap_net_raw

[Salvatore Bonaccorso]

Hi Tormod,

On Mon, Jun 14, 2021 at 11:43:44PM +0200, Tormod Volden wrote:
> This issue is marked as affecting 5.42+dfsg1-1 in buster (and even
> stretch) in our CVE tracker, however the set_cap action was first
> added in 5.44+dfsg1-1.
> 
> https://security-tracker.debian.org/tracker/CVE-2021-31523

Thanks!

Regards,
Salvatore

Bug#989508: xscreensaver: Disconnecting a video output can cause XScreenSaver to crash and unlock

[Salvatore Bonaccorso]

Hi Tormod,

On Mon, Jun 14, 2021 at 11:38:34PM +0200, Tormod Volden wrote:
> This issue is marked as affecting 5.42+dfsg1-1 in buster (and even
> stretch) in our CVE tracker, however the openwall report says:
> 
> "The issue affects only XScreenSaver version 5.45. Versions 5.44 and
> older, as well as 6.00, are not affected."

Correct, see as well my initial bugreport. Though on checking the code
it was not immediately clear (to me) what makes earlier version not
affected. Thus the general rule for us is, to err on the wrong side
and have something marked as affected which is not, rather the other
way around. SuSE seem to have similar issue, cf.
https://bugzilla.suse.com/show_bug.cgi?id=1186918#c1

Do you have any more insights here?

Regards,
Salvatore

Bug#989872: thunderbird-dbgsym: uninstallable cruft package in buster

[Andrei POPESCU]

Control: reassign -1 src:thunderbird

On Ma, 15 iun 21, 01:41:12, Andreas Beckmann wrote:
> Package: thunderbird-dbgsym
> Version: 1:60.9.0-1~deb10u1
> Severity: serious
> User: debian...@lists.debian.org
> Usertags: piuparts
> 
> thunderbird-dbgsym is a cruft package still sitting in buster-debug
> while thunderbird is already at version 1:78.6.0-1~deb10u1 (without a
> corresponding -dbgsym package).

Apparently the BTS doesn't know about -debug, which means this bug is 
currently assigned against an "inexistent" package. Reassigning to 
src:thunderbird instead.

Kind regards,
Andrei
-- 
Looking after bugs assigned to unknown or inexistent packages


signature.asc
Description: PGP signature

Bug#989785: devscripts: wrap-and-sort ignores --trailing-comma on non-sorted fields/Uploaders

[Norbert Preining]

Hi Mattia,

> Can you describe with an example or something more specific what you are
> observing?

Ah, it only happens with *one* Uploader:
$ head -6 debian/control
Source: layer-shell-qt
Section: kde
Priority: optional
Maintainer: Debian Qt/KDE Maintainers 
Uploaders: Norbert Preining ,
Build-Depends: cmake (>= 3.16~),

$ wrap-and-sort -t

$ head -6 debian/control
Source: layer-shell-qt
Section: kde
Priority: optional
Maintainer: Debian Qt/KDE Maintainers 
Uploaders: Norbert Preining 
Build-Depends: cmake (>= 3.16~),

The final comma after uploaders is gone.

Not that important, but when automatizing tasks with a few hundred
packages of KDE, I would like to see less changes in the actual git
commits.

Best

Norbert

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

Bug#989350: Processed: your mail

[Andrei POPESCU]

On Lu, 14 iun 21, 21:51:03, Debian Bug Tracking System wrote:
> Processing commands for cont...@bugs.debian.org:
> 
> > reassign 989350 elementary-theme
> Bug #989350 [wnpp] ITP: elementary-theme -- GTK stylesheet from elementary OS

Any particular reason to do this?

ITPs should always be assigned to 'wnpp' and closed on first upload with 
a 'Closes:' entry in the changelog.

Kind regards,
Andrei
-- 
Looking after bugs assigned to unknown or inexistent packages


signature.asc
Description: PGP signature

Bug#989597: release.debian.org: upgrade issue: non-coinstallability of libgdal20 and libgdal28

[Sebastiaan Couwenberg]

On 6/14/21 9:55 PM, Sebastian Ramacher wrote:
> On 2021-06-14 13:49:47 +0200, Sebastiaan Couwenberg wrote:
>> On 6/14/21 1:30 PM, Andreas Beckmann wrote:
>>> On 14/06/2021 10.06, Sebastiaan Couwenberg wrote:
 What actual problems do are solved by making them co-installable?

 So far the only actualy problem that has been identified is the need for
 `apt full-upgrade` twice when the Breaks/Replaces on libgdal20 is not
 present.
>>>
>>> apt currently fails to find an upgrade path for libmrpt-dev (logfile
>>> attached, no bug filed, yet). The only solution I could find so far was
>>> the big hammer: adding a Breaks against libopencv-core3.2 (or similar)
>>> to gcc-10-base.
>>> With a co-installable libgdal20/libgdal28 this is gone because the huge
>>> dependency trees no longer conflict with each other.
>>>
>>> Co-installable libgdal20/28 solves a lot of buster->bullseye upgrade
>>> issues. So I can concentrate on fixing the remaining incomplete
>>> (unversioned) python (2) removal bits. ;-)
>>
>> If co-installable libgdal is a must, then I'd rather drop gdal-data and
>> move its content back to libgdal28 with an override for the
>> big-usr-share lintian issue. That's how it was a long time ago:
>>
>>  
>> https://salsa.debian.org/debian-gis-team/gdal/-/commit/140ab452687b2a6d92f3b760379fbbd81f80794a
>>
>> I'm not in favor of either option, though.
> 
> Not having libgdal20 and libgdal28 co-installable makes it unneccessarly
> hard to upgrade all of libgdal's reverse dependencies that also bumped
> SONAMEs.  That set of packages includes at least opencv, pdal, qgis,
> vtk7, otb, mapnik, openscenegraph and gazebo. And then there are
> probably even more that are reverse dependencies of those packages which
> bumped SONAME.  So this issues affects many many packages and is not
> only related to postgis.

Again, postgis database upgrades have never been supported. You're
wasting your time on that.

>From the many other packages I haven't seen other issues other than the
partial upgrade with monteverdi which is fixed with Breaks/Replaces.

I really need more concrete cases to justify changes to gdal that I
don't like but will have to maintain.

> In any case, all these options seem rather unsatisfying and fragile.
> Manually building specific postgis versions against specific postgresql
> versions seems like a recipe for desaster. If one screws up any of the
> steps, one can only hope for a backup and needs to start over. libgdal's
> co-installablity issue makes that even more brittle then necessary if
> not impossible.

As said before, upgrade support of postgis is shit. Upstream does not
take that use case very seriously, although some of the postgis
developers are as unhappy with that as we are.

I don't have the time, energy, nor knowledge required to fix this
upstream. So I've just been recreating my postgis databases in the new
cluster after every distribution upgrade.

> To be honest, from a package in Debian I would expect more. This is a
> frustrating upgrade experience. And even if we cannot fix postgis
> upgrades in time, having libgdal20 and libgdal28 not co-installable,
> makes it only more painful for our users. So I'd say, yes, libgdal20 and
> libgdal28 co-installablity is a must.
> 
>> We can also drop the Breaks from gdal-data, and have libgdal20 be broken
>> for the bits that use it. It will help with the dependency resolution.
> 
> If a non-function libgdal20 would mean that even if if installed, it's
> completely useless for the cases above, then no, that's not an option.

The scope of how broken libgdal20 is without all of the data files it
expects is difficult to determine. The data files are considered a hard
dependency, hence the Breaks on libgdal20 due to the changes for PROJ 6.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Bug#968897: src:pylint should provide a pylint3 transitional package

[Sandro Tosi]

On Mon, Jun 14, 2021 at 10:39 AM Hideki Yamane  wrote:
>
> control: tags -1 +patch
>
>
> On Tue, 1 Jun 2021 22:49:18 +0300 Adrian Bunk  wrote:
> > Provides is good for fulfilling dependencies, but won't for an upgrade
> > to the renamed package.
>
>  Okay, then add transitional dummy package for it as below.

thanks, i've applied and uploaded your change as-is; next time, please
open an MR on salsa

Regards,
-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Bug#988649: rdate: UDP connection enforced by '-n', no possible to use SNTP over TCP

[Thiago Andrade]

Thanks Artur and Eriberto.

I will update the package as soon as possible after full freeze time.

Regards,
Thiago Andrade

Em seg., 14 de jun. de 2021 às 18:09, Eriberto 
escreveu:

> Control: fixed 988649 upstream/1.10.1
>
> Em seg., 17 de mai. de 2021 às 08:24, artur128  escreveu:
> >
> [...]
> > "-u Use UDP instead of TCP as transport."
> > ...
> >
> > but if you use the "-n" you also forced to use UDP-packets.
> >
> > it would be nice if the manpage would mention that.
>
> Hi artur128,
>
> Thanks a lot for your contribution. The manpage was already improved
> on the upstream side (options -n, -o and -u)[1]. I think Thiago (rdate
> maintainer in Debian) will update the package after the current freeze
> time.
>
> [1]
> https://github.com/resurrecting-open-source-projects/openrdate/blob/master/docs/rdate.txt
>
> Cheers,
>
> Eriberto
>

Bug#989880: cpl-plugin-muse-calib: muse-kit-2.6*.tar.gz no longer downloadable

[Andreas Beckmann]

Package: cpl-plugin-muse-calib
Version: 2.6+dfsg-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package failed to install. As
per definition of the release team this makes the package too buggy for
a release, thus the severity.

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

  Setting up cpl-plugin-muse-calib (2.6+dfsg-1) ...
  --2021-06-14 22:38:06--  
ftp://ftp.eso.org/pub/dfs/pipelines/muse/muse-kit-2.6.tar.gz
 => '-'
  Resolving ftp.eso.org (ftp.eso.org)... 134.171.42.53, 134.171.42.54
  Connecting to ftp.eso.org (ftp.eso.org)|134.171.42.53|:21... connected.
  Logging in as anonymous ... Logged in!
  ==> SYST ... done.==> PWD ... done.
  ==> TYPE I ... done.  ==> CWD (1) /pub/dfs/pipelines/muse ... done.
  ==> SIZE muse-kit-2.6.tar.gz ... done.
  
  ==> PASV ... done.==> RETR muse-kit-2.6.tar.gz ... 
  No such file 'muse-kit-2.6.tar.gz'.
  
  
  gzip: stdin: unexpected end of file
  tar: Child returned status 1
  tar: Error is not recoverable: exiting now
  
  gzip: stdin: unexpected end of file
  tar: Child returned status 1
  tar: Error is not recoverable: exiting now
  --2021-06-14 22:38:06--  
ftp://ftp.eso.org/pub/dfs/pipelines/muse/muse-kit-2.6-1.tar.gz
 => '-'
  Resolving ftp.eso.org (ftp.eso.org)... 134.171.42.54, 134.171.42.53
  Connecting to ftp.eso.org (ftp.eso.org)|134.171.42.54|:21... connected.
  Logging in as anonymous ... Logged in!
  ==> SYST ... done.==> PWD ... done.
  ==> TYPE I ... done.  ==> CWD (1) /pub/dfs/pipelines/muse ... done.
  ==> SIZE muse-kit-2.6-1.tar.gz ... done.
  
  ==> PASV ... done.==> RETR muse-kit-2.6-1.tar.gz ... 
  No such file 'muse-kit-2.6-1.tar.gz'.
  
  
  gzip: stdin: unexpected end of file
  tar: Child returned status 1
  tar: Error is not recoverable: exiting now
  
  gzip: stdin: unexpected end of file
  tar: Child returned status 1
  tar: Error is not recoverable: exiting now
[...]

cheers,

Andreas


cpl-plugin-muse-calib_2.6+dfsg-1.log.gz
Description: application/gzip

Bug#989879: sane-utils: fails to purge: post-removal script subprocess returned error exit status 1

[Andreas Beckmann]

Package: sane-utils
Version: 1.0.32-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package failed to purge.
According to policy 7.2 you cannot rely on the depends being available
during purge, only the essential packages are available for sure.

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

  Purging configuration files for sane-utils (1.0.32-1) ...
  dpkg: error processing package sane-utils (--purge):
   installed sane-utils package post-removal script subprocess returned error 
exit status 1
  Errors were encountered while processing:
   sane-utils

After injecting 'set -x' into the postrm script:

  Purging configuration files for sane-utils (1.0.32-1) ...
  + set -e
  + [ purge = purge ]
  + pathfind update-inetd
  + OLDIFS=

  + IFS=:
  + [ -x /usr/local/sbin/update-inetd ]
  + [ -x /usr/local/bin/update-inetd ]
  + [ -x /usr/sbin/update-inetd ]
  + [ -x /usr/bin/update-inetd ]
  + [ -x /sbin/update-inetd ]
  + [ -x /bin/update-inetd ]
  + IFS=

  + return 1
  dpkg: error processing package sane-utils (--purge):
   installed sane-utils package post-removal script subprocess returned error 
exit status 1
  Errors were encountered while processing:
   sane-utils


cheers,

Andreas


sane-utils_1.0.32-1.log.gz
Description: application/gzip

Bug#989878: openstack-dashboard: fails to remove: rm: cannot remove '/usr/lib/python3/dist-packages/openstack_dashboard/local/enabled': Is a directory

[Andreas Beckmann]

Package: openstack-dashboard
Version: 3:19.2.0-3
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to remove.

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

  Removing openstack-dashboard (3:19.2.0-3) ...
  rm: cannot remove 
'/usr/lib/python3/dist-packages/openstack_dashboard/local/enabled': Is a 
directory
  dpkg: error processing package openstack-dashboard (--remove):
   installed openstack-dashboard package pre-removal script subprocess returned 
error exit status 1
  dpkg: too many errors, stopping
  Errors were encountered while processing:
   openstack-dashboard
  Processing was halted because there were too many errors.

This was observed after an upgrade from sid to experimental.


cheers,

Andreas


openstack-dashboard_3:19.2.0-3.log.gz
Description: application/gzip

Bug#989877: ITP: golang-github-jpillora-go-tld -- Top Level Domain (TLD) Parser

[Francisco Vilmar Cardoso Ruviaro]

Package: wnpp
Severity: wishlist
Owner: Francisco Vilmar Cardoso Ruviaro 
X-Debbugs-Cc: debian-de...@lists.debian.org, francisco.ruvi...@riseup.net

* Package name: golang-github-jpillora-go-tld
  Version : 1.1.1
  Upstream Author : Jaime Pillora 
* URL : https://github.com/jpillora/go-tld
* License : Expat
  Programming Lang: Go
  Description : Top Level Domain (TLD) Parser

  Top Level Domain (TLD) Parser has the same API as net/url
  except tld.URL contains extra fields: Subdomain, Domain, TLD and Port.

  golang-github-jpillora-go-tld-dev is a Build-Dependency for bettercap.

Bug#989876: syncplay-common,syncplay-server: missing Breaks+Replaces: syncplay (<< 1.6.7+repack1-7)

[Andreas Beckmann]

Package: syncplay-common,syncplay-server
Version: 1.6.8+repack1-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts
Control: affects -1 + syncplay

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'sid' to 'experimental'.
It installed fine in 'sid', then the upgrade to 'experimental' fails
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.

See policy 7.6 at
https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces

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

  Selecting previously unselected package syncplay-common.
  (Reading database ... 
(Reading database ... 13126 files and directories currently installed.)
  Preparing to unpack .../syncplay-common_1.6.8+repack1-1_all.deb ...
  Unpacking syncplay-common (1.6.8+repack1-1) ...
  dpkg: error processing archive 
/var/cache/apt/archives/syncplay-common_1.6.8+repack1-1_all.deb (--unpack):
   trying to overwrite '/usr/lib/python3/dist-packages/syncplay/__init__.py', 
which is also in package syncplay 1.6.7+repack1-5
  dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
  Preparing to unpack .../syncplay_1.6.8+repack1-1_all.deb ...
  Unpacking syncplay (1.6.8+repack1-1) over (1.6.7+repack1-5) ...
  Errors were encountered while processing:
   /var/cache/apt/archives/syncplay-common_1.6.8+repack1-1_all.deb

The existing
  Breaks+Replaces: syncplay (<= 1.6.7)
are incorrectly versioned since the package split happened in 1.6.7+repack1-7


cheers,

Andreas


syncplay_1.6.8+repack1-1.log.gz
Description: application/gzip

Bug#989875: pulseaudio-utils: missing Breaks+Replaces: pulseaudio (<< 14.99)

[Andreas Beckmann]

Package: pulseaudio-utils
Version: 14.99.1+dfsg1-2
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts
Control: affects -1 + pulseaudio

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'sid' to 'experimental'.
It installed fine in 'sid', then the upgrade to 'experimental' fails
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.

See policy 7.6 at
https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces

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

  Preparing to unpack .../libpulsedsp_14.99.1+dfsg1-2_amd64.deb ...
  Unpacking libpulsedsp:amd64 (14.99.1+dfsg1-2) over (14.2-2) ...
  Preparing to unpack .../pulseaudio-utils_14.99.1+dfsg1-2_amd64.deb ...
  Unpacking pulseaudio-utils (14.99.1+dfsg1-2) over (14.2-2) ...
  dpkg: error processing archive 
/var/cache/apt/archives/pulseaudio-utils_14.99.1+dfsg1-2_amd64.deb (--unpack):
   trying to overwrite '/usr/share/bash-completion/completions/pulseaudio', 
which is also in package pulseaudio 14.2-2
  Preparing to unpack .../pulseaudio_14.99.1+dfsg1-2_amd64.deb ...
  Unpacking pulseaudio (14.99.1+dfsg1-2) over (14.2-2) ...
  Preparing to unpack .../libpulse0_14.99.1+dfsg1-2_amd64.deb ...
  Unpacking libpulse0:amd64 (14.99.1+dfsg1-2) over (14.2-2) ...
  Errors were encountered while processing:
   /var/cache/apt/archives/pulseaudio-utils_14.99.1+dfsg1-2_amd64.deb


cheers,

Andreas


pulseaudio_14.99.1+dfsg1-2.log.gz
Description: application/gzip

Bug#989874: kolourpaint: i installed kolorpaint without any other kde app and the icons are missing

[Mr. T]

Package: kolourpaint
Version: 4:20.12.0-1
Severity: important
X-Debbugs-Cc: t...@treaki.tk

hi,

have a look at the screenshot,

its kolourpaint, my favorite mspaint replacement, but on the left you
see that a lot of space is wasted cause of missing icons, i don't even
know which package i have to install for those, but imho it should be in
recommended when not even in dependency of the kolourpaint package.

thanks a lot and keep up the good work

T


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

Kernel: Linux 5.10.0-6-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en

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

Versions of packages kolourpaint depends on:
ii kio 5.78.0-4
ii libc6 2.31-12
ii libkf5configcore5 5.78.0-4
ii libkf5configgui5 5.78.0-4
ii libkf5configwidgets5 5.78.0-2
ii libkf5coreaddons5 5.78.0-4
ii libkf5guiaddons5 5.78.0-3
ii libkf5i18n5 5.78.0-2
ii libkf5jobwidgets5 5.78.0-2
ii libkf5kiocore5 5.78.0-4
ii libkf5kiofilewidgets5 5.78.0-4
ii libkf5sane5 20.12.0-1
ii libkf5service-bin 5.78.0-2
ii libkf5service5 5.78.0-2
ii libkf5textwidgets5 5.78.0-2
ii libkf5widgetsaddons5 5.78.0-2
ii libkf5xmlgui5 5.78.0-2
ii libqt5core5a 5.15.2+dfsg-5
ii libqt5gui5 5.15.2+dfsg-5
ii libqt5printsupport5 5.15.2+dfsg-5
ii libqt5widgets5 5.15.2+dfsg-5
ii libstdc++6 10.2.1-6

kolourpaint recommends no packages.

kolourpaint suggests no packages.

-- no debconf information

Bug#989873: pcp: FTBFS: pcp-export-pcp2xlsx is missing files

[Andreas Beckmann]

Source: pcp
Version: 5.3.0-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

pcp FTBFS everywhere:

https://buildd.debian.org/status/package.php?p=pcp&suite=unstable

dh_install -a --sourcedir=debian/pcp
dh_install: warning: Cannot find (any matches for) "usr/bin/pcp2xlsx" (tried in 
debian/pcp, debian/tmp)

dh_install: warning: pcp-export-pcp2xlsx missing files: usr/bin/pcp2xlsx
dh_install: warning: Cannot find (any matches for) 
"usr/share/bash-completion/completions/pcp2xlsx" (tried in debian/pcp, 
debian/tmp)

dh_install: warning: pcp-export-pcp2xlsx missing files: 
usr/share/bash-completion/completions/pcp2xlsx
dh_install: warning: Cannot find (any matches for) 
"usr/share/man/man1/pcp2xlsx.1.gz" (tried in debian/pcp, debian/tmp)

dh_install: warning: pcp-export-pcp2xlsx missing files: 
usr/share/man/man1/pcp2xlsx.1.gz
dh_install: error: missing files, aborting


Andreas

Bug#989872: thunderbird-dbgsym: uninstallable cruft package in buster

[Andreas Beckmann]

Package: thunderbird-dbgsym
Version: 1:60.9.0-1~deb10u1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

thunderbird-dbgsym is a cruft package still sitting in buster-debug
while thunderbird is already at version 1:78.6.0-1~deb10u1 (without a
corresponding -dbgsym package).

Andreas

Bug#989871: trousers: diff for NMU version 0.3.14+fixed1-1.2

[Laurent Bigonville]

Package: trousers
Version: 0.3.14+fixed1-1.1
Severity: normal
Tags: patch  pending


Dear maintainer,

I've prepared an NMU for trousers (versioned as 0.3.14+fixed1-1.2). The diff
is attached to this message.

Regards.

diff -Nru trousers-0.3.14+fixed1/debian/changelog 
trousers-0.3.14+fixed1/debian/changelog
--- trousers-0.3.14+fixed1/debian/changelog 2020-08-17 07:36:43.0 
+0200
+++ trousers-0.3.14+fixed1/debian/changelog 2021-06-15 00:29:18.0 
+0200
@@ -1,3 +1,12 @@
+trousers (0.3.14+fixed1-1.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Migrate to tpm-udev package, do not ship the udev rule file, create the
+user or /var/lib/tpm directory anymore (Closes: #787244, #889491, #944751)
+  * debian/trousers.prerm: Remove migration code path that predates Jessie
+
+ -- Laurent Bigonville   Tue, 15 Jun 2021 00:29:18 +0200
+
 trousers (0.3.14+fixed1-1.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru trousers-0.3.14+fixed1/debian/control 
trousers-0.3.14+fixed1/debian/control
--- trousers-0.3.14+fixed1/debian/control   2016-11-20 16:10:31.0 
+0100
+++ trousers-0.3.14+fixed1/debian/control   2021-06-14 23:19:13.0 
+0200
@@ -13,7 +13,7 @@
 
 Package: trousers
 Architecture: any
-Depends: ${misc:Depends}, ${shlibs:Depends}, adduser, lsb-base (>= 3.0-6)
+Depends: ${misc:Depends}, ${shlibs:Depends}, lsb-base (>= 3.0-6), tpm-udev
 Breaks: udev (<< 136-1)
 Description: open-source TCG Software Stack (daemon)
  TrouSerS is an implementation of the Trusted Computing Group's Software Stack
diff -Nru trousers-0.3.14+fixed1/debian/rules 
trousers-0.3.14+fixed1/debian/rules
--- trousers-0.3.14+fixed1/debian/rules 2016-11-20 16:10:31.0 +0100
+++ trousers-0.3.14+fixed1/debian/rules 2021-06-14 23:15:06.0 +0200
@@ -16,6 +16,3 @@
 
 override_dh_strip:
dh_strip --dbg-package=trousers-dbg
-
-override_dh_installudev:
-   dh_installudev -n --priority=45
diff -Nru trousers-0.3.14+fixed1/debian/trousers.install 
trousers-0.3.14+fixed1/debian/trousers.install
--- trousers-0.3.14+fixed1/debian/trousers.install  2016-11-20 
16:10:31.0 +0100
+++ trousers-0.3.14+fixed1/debian/trousers.install  2021-06-15 
00:06:23.0 +0200
@@ -2,4 +2,3 @@
 /usr/sbin
 /usr/share/man/man8
 /usr/share/man/man5
-/var/lib/tpm
diff -Nru trousers-0.3.14+fixed1/debian/trousers.postinst 
trousers-0.3.14+fixed1/debian/trousers.postinst
--- trousers-0.3.14+fixed1/debian/trousers.postinst 2016-11-20 
16:10:31.0 +0100
+++ trousers-0.3.14+fixed1/debian/trousers.postinst 2021-06-14 
23:25:54.0 +0200
@@ -4,22 +4,11 @@
 
 case "${1}" in
configure)
-   # Adding tss system user
-   adduser --system --quiet --home /var/lib/tpm --shell /bin/false 
--no-create-home --group tss
-
# Setting owner
-   chown tss:tss /var/lib/tpm -R
chown tss:tss /etc/tcsd.conf
 
# Setting permissions
chmod 0600 /etc/tcsd.conf
-   chmod 0700 /var/lib/tpm
-
-   # ask udev to check for new udev rules (and fix device 
permissions)
-   if [ -e /dev/tpm0 ] && udevadm --version > /dev/null; then
-   udevadm control --reload-rules ||:
-   udevadm trigger --sysname-match="tpm[0-9]*" ||:
-   fi
;;
 
abort-upgrade|abort-remove|abort-deconfigure)
diff -Nru trousers-0.3.14+fixed1/debian/trousers.postrm 
trousers-0.3.14+fixed1/debian/trousers.postrm
--- trousers-0.3.14+fixed1/debian/trousers.postrm   2016-11-20 
16:10:31.0 +0100
+++ trousers-0.3.14+fixed1/debian/trousers.postrm   1970-01-01 
01:00:00.0 +0100
@@ -1,26 +0,0 @@
-#!/bin/sh
-
-set -e
-
-case "${1}" in
-   remove)
-   if [ -x /usr/sbin/deluser ]
-   then
-   deluser --system --remove-home tss || true
-   deluser --group --only-if-empty tss || true
-   fi
-   ;;
-
-   purge|upgrade|failed-upgrade|abort-install|abort-upgrade|disappear)
-
-   ;;
-
-   *)
-   echo "postrm called with unknown argument \`${1}'" >&2
-   exit 1
-   ;;
-esac
-
-#DEBHELPER#
-
-exit 0
diff -Nru trousers-0.3.14+fixed1/debian/trousers.preinst 
trousers-0.3.14+fixed1/debian/trousers.preinst
--- trousers-0.3.14+fixed1/debian/trousers.preinst  2016-11-20 
16:10:31.0 +0100
+++ trousers-0.3.14+fixed1/debian/trousers.preinst  1970-01-01 
01:00:00.0 +0100
@@ -1,15 +0,0 @@
-#!/bin/sh
-
-set -e
-
-if [ "$1" = install ] || [ "$1" = upgrade ]; then
-if [ -e "/etc/udev/rules.d/45-trousers.rules" ]; then
-if [ "`md5sum \"/etc/udev/rules.d/45-trousers.rules\" | sed -e 
\"s/ .*//\"`" = \
- "`dpkg-query -W -f='${Conffiles}' trousers | sed -n -e 
\"' /etc/udev/rules.d/45-trousers.ru

Bug#900806: Greetings;

[Engr. Gordon Hirschy]

Greetings;

I sent you an email a couple of days ago and haven't heard from you.

Please confirm if you received my email?

Yours Sincerely,
Engr. Gordon Hirschy
email; eng...@engrgordon.com

Bug#989870: libwine-development,libwine-development-dev: both ship usr/lib/x86_64-linux-gnu/wine-development/libwine.so

[Andreas Beckmann]

Package: libwine-development,libwine-development-dev
Version: 5.22+repack-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package failed to install
because it tries to overwrite other packages files.

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

  Selecting previously unselected package libwine-development:amd64.
  Preparing to unpack .../98-libwine-development_5.22+repack-1_amd64.deb ...
  Unpacking libwine-development:amd64 (5.22+repack-1) ...
  Selecting previously unselected package libwine-development-dev.
  Preparing to unpack .../99-libwine-development-dev_5.22+repack-1_amd64.deb ...
  Unpacking libwine-development-dev (5.22+repack-1) ...
  dpkg: error processing archive 
/tmp/apt-dpkg-install-5EjfOJ/99-libwine-development-dev_5.22+repack-1_amd64.deb 
(--unpack):
   trying to overwrite '/usr/lib/x86_64-linux-gnu/wine-development/libwine.so', 
which is also in package libwine-development:amd64 5.22+repack-1
  Errors were encountered while processing:
   
/tmp/apt-dpkg-install-5EjfOJ/99-libwine-development-dev_5.22+repack-1_amd64.deb


cheers,

Andreas


libwine-development-dev_5.22+repack-1.log.gz
Description: application/gzip

Bug#989869: unblock: trousers/0.3.14+fixed1-1.2

[Laurent Bigonville]

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

Please unblock package trousers

[ Reason ]
The current package manages the /var/lib/tpm and tss user, but other
packages in debian, namely the tpm-udev package, is also doing so. Same
for the udev rules that shipped in both the trousers package and the
tpm-udev one.

The goal was to migrate the management of the tss user and its home
directory and the needed udev rules to a central package so the
different implementaitons of the tpm stack could co-exist.

[ Impact ]
Multiple udev rules will be evaluated for the same device.

Also, if the trousers package is purged, the tss user will be removed
and the udev rules shipped by the tpm-udev package will not work
anymore.

[ Tests ]
I tried to purge the tpm-udev and trousers package an tried to
reinstall them. Trousers daemon starts properly

The permissions on the /dev/tpm devices are ok, even after reboot.

[ Risks ]
if the tss user or /var/lib/tpm is not properly created, the daemon will
more than probably fail to start.

The way of creating the tss user is the same between the tpm-udev and
former trousers package so that shouldn't be a problem

tpm-udev:

  adduser --system --ingroup tss --shell /bin/false --home /var/lib/tpm 
--no-create-home --gecos "TPM software stack" tss

trousers:

  adduser --system --quiet --home /var/lib/tpm --shell /bin/false 
--no-create-home --group tss


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

[ Other info ]
The trousers package is not shipping the /var/lib/tpm directory anymore,
I decided to give full ownership of that directory to the tpm-udev
package, not sure if that was the best solution

Also note bug #989867

unblock trousers/0.3.14+fixed1-1.2
diff -Nru trousers-0.3.14+fixed1/debian/changelog 
trousers-0.3.14+fixed1/debian/changelog
--- trousers-0.3.14+fixed1/debian/changelog 2020-08-17 07:36:43.0 
+0200
+++ trousers-0.3.14+fixed1/debian/changelog 2021-06-15 00:29:18.0 
+0200
@@ -1,3 +1,12 @@
+trousers (0.3.14+fixed1-1.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Migrate to tpm-udev package, do not ship the udev rule file, create the
+user or /var/lib/tpm directory anymore (Closes: #787244, #889491, #944751)
+  * debian/trousers.prerm: Remove migration code path that predates Jessie
+
+ -- Laurent Bigonville   Tue, 15 Jun 2021 00:29:18 +0200
+
 trousers (0.3.14+fixed1-1.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru trousers-0.3.14+fixed1/debian/control 
trousers-0.3.14+fixed1/debian/control
--- trousers-0.3.14+fixed1/debian/control   2016-11-20 16:10:31.0 
+0100
+++ trousers-0.3.14+fixed1/debian/control   2021-06-14 23:19:13.0 
+0200
@@ -13,7 +13,7 @@
 
 Package: trousers
 Architecture: any
-Depends: ${misc:Depends}, ${shlibs:Depends}, adduser, lsb-base (>= 3.0-6)
+Depends: ${misc:Depends}, ${shlibs:Depends}, lsb-base (>= 3.0-6), tpm-udev
 Breaks: udev (<< 136-1)
 Description: open-source TCG Software Stack (daemon)
  TrouSerS is an implementation of the Trusted Computing Group's Software Stack
diff -Nru trousers-0.3.14+fixed1/debian/rules 
trousers-0.3.14+fixed1/debian/rules
--- trousers-0.3.14+fixed1/debian/rules 2016-11-20 16:10:31.0 +0100
+++ trousers-0.3.14+fixed1/debian/rules 2021-06-14 23:15:06.0 +0200
@@ -16,6 +16,3 @@
 
 override_dh_strip:
dh_strip --dbg-package=trousers-dbg
-
-override_dh_installudev:
-   dh_installudev -n --priority=45
diff -Nru trousers-0.3.14+fixed1/debian/trousers.install 
trousers-0.3.14+fixed1/debian/trousers.install
--- trousers-0.3.14+fixed1/debian/trousers.install  2016-11-20 
16:10:31.0 +0100
+++ trousers-0.3.14+fixed1/debian/trousers.install  2021-06-15 
00:06:23.0 +0200
@@ -2,4 +2,3 @@
 /usr/sbin
 /usr/share/man/man8
 /usr/share/man/man5
-/var/lib/tpm
diff -Nru trousers-0.3.14+fixed1/debian/trousers.postinst 
trousers-0.3.14+fixed1/debian/trousers.postinst
--- trousers-0.3.14+fixed1/debian/trousers.postinst 2016-11-20 
16:10:31.0 +0100
+++ trousers-0.3.14+fixed1/debian/trousers.postinst 2021-06-14 
23:25:54.0 +0200
@@ -4,22 +4,11 @@
 
 case "${1}" in
configure)
-   # Adding tss system user
-   adduser --system --quiet --home /var/lib/tpm --shell /bin/false 
--no-create-home --group tss
-
# Setting owner
-   chown tss:tss /var/lib/tpm -R
chown tss:tss /etc/tcsd.conf
 
# Setting permissions
chmod 0600 /etc/tcsd.conf
-   chmod 0700 /var/lib/tpm
-
-   # ask udev to check for new udev rules (and fix device 
permissions)
-   if [ -e /dev/tpm0 ] && udevadm --version > /dev/null; then
-   udevadm control --reload-rules ||:
- 

Bug#859138: java.lang.UnsupportedOperationException: The BROWSE action is not supported on the current platform!

[Thorsten Glaser]

found 859138 11.0.12+4-1
thanks

On Thu, 30 Mar 2017, Thorsten Glaser wrote:

> tglase@tglase-nb:~ $ cat >testcase.java <<\EOF
> import java.awt.Desktop;
> import java.net.URI;
>
> public class testcase {
> public static void main(String[] args) {
> try {
> Desktop.getDesktop().browse(new 
> URI("http://www.mirbsd.org/";));
> } catch (Exception e) {
> System.out.println(e);
> }
> }
> }
> EOF
> tglase@tglase-nb:~ $ javac testcase.java
$ java testcase
> java.lang.UnsupportedOperationException: The BROWSE action is not supported 
> on the current platform!

This still fails on 11.

bye,
//mirabilos
-- 
[16:04:33] bkix: "veni vidi violini"
[16:04:45] bkix: "ich kam, sah und vergeigte"...

Bug#989865: unblock: debian-installer-netboot-images/20210606+fixed1

[Holger Levsen]

On Tue, Jun 15, 2021 at 12:16:03AM +0200, Holger Levsen wrote:
> A full diff is attached.

a classic, now!


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

We are done with ‘world leaders’. Countries are on fire. Cities are drowning.
People are dying. This is what scientists and activists have been warning the
world and politicians about. It’s here. We ARE facing the impacts of the
climate crisis. Forget about the future, it’s now.
fridays for future - https://nitter.net/fff_digital/status/1304520941012242432
diff -Nru debian-installer-netboot-images-20210415/debian/changelog debian-installer-netboot-images-20210606+fixed1/debian/changelog
--- debian-installer-netboot-images-20210415/debian/changelog	2021-04-15 13:23:35.0 +0200
+++ debian-installer-netboot-images-20210606+fixed1/debian/changelog	2021-06-10 06:50:59.0 +0200
@@ -1,3 +1,23 @@
+debian-installer-netboot-images (20210606+fixed1) unstable; urgency=medium
+
+  * Fix regression introduced while fixing error reporting in the previous
+upload (oh, the irony), fixing the FTBFS.
+  * Strip +fixed.* suffix when setting VERSION in debian/rules, to cope
+with this follow-up upload for the same D-I version (20210606).
+
+ -- Cyril Brulebois   Thu, 10 Jun 2021 06:50:59 +0200
+
+debian-installer-netboot-images (20210606) unstable; urgency=medium
+
+  * Update for D-I Bullseye RC 2.
+  * Fix error reporting when no fallback suite is defined: exit
+immediately instead of building empty packages.
+  * Drop unused shared-lib-without-dependency-information lintian
+overrides.
+  * Add myself to Uploaders.
+
+ -- Cyril Brulebois   Mon, 07 Jun 2021 17:47:04 +0200
+
 debian-installer-netboot-images (20210415) unstable; urgency=medium
 
   * Team upload.
diff -Nru debian-installer-netboot-images-20210415/debian/control debian-installer-netboot-images-20210606+fixed1/debian/control
--- debian-installer-netboot-images-20210415/debian/control	2021-04-15 13:22:35.0 +0200
+++ debian-installer-netboot-images-20210606+fixed1/debian/control	2021-06-07 17:46:51.0 +0200
@@ -8,7 +8,7 @@
 Section: misc
 Priority: optional
 Maintainer: Debian Install System Team 
-Uploaders: Didier Raboud 
+Uploaders: Didier Raboud , Cyril Brulebois 
 Build-Depends: debhelper-compat (= 13),
  wget,
  debian-archive-keyring,
diff -Nru debian-installer-netboot-images-20210415/debian/control.in debian-installer-netboot-images-20210606+fixed1/debian/control.in
--- debian-installer-netboot-images-20210415/debian/control.in	2021-04-15 13:22:35.0 +0200
+++ debian-installer-netboot-images-20210606+fixed1/debian/control.in	2021-06-07 17:45:11.0 +0200
@@ -2,7 +2,7 @@
 Section: misc
 Priority: optional
 Maintainer: Debian Install System Team 
-Uploaders: Didier Raboud 
+Uploaders: Didier Raboud , Cyril Brulebois 
 Build-Depends: debhelper-compat (= 13),
  wget,
  debian-archive-keyring,
diff -Nru debian-installer-netboot-images-20210415/debian/lintian-overrides.in debian-installer-netboot-images-20210606+fixed1/debian/lintian-overrides.in
--- debian-installer-netboot-images-20210415/debian/lintian-overrides.in	2021-02-15 18:47:48.0 +0100
+++ debian-installer-netboot-images-20210606+fixed1/debian/lintian-overrides.in	2021-06-07 17:31:06.0 +0200
@@ -3,7 +3,6 @@
 debian-installer-##IDENTIFIER##: statically-linked-binary
 debian-installer-##IDENTIFIER##: unstripped-binary-or-object
 debian-installer-##IDENTIFIER##: embedded-library
-debian-installer-##IDENTIFIER##: shared-lib-without-dependency-information
 debian-installer-##IDENTIFIER##: library-not-linked-against-libc
 debian-installer-##IDENTIFIER##: shlib-with-executable-stack
 debian-installer-##IDENTIFIER##: missing-depends-line
diff -Nru debian-installer-netboot-images-20210415/debian/rules debian-installer-netboot-images-20210606+fixed1/debian/rules
--- debian-installer-netboot-images-20210415/debian/rules	2021-02-15 18:59:29.0 +0100
+++ debian-installer-netboot-images-20210606+fixed1/debian/rules	2021-06-10 06:50:56.0 +0200
@@ -4,7 +4,7 @@
 export DISTRIBUTION_FALLBACK?=
 export KFREEBSD_KERNEL_MAJOR?=11
 
-export VERSION?=$(shell dpkg-parsechangelog | sed -n 's/^Version: //p')
+export VERSION?=$(shell dpkg-parsechangelog | sed -n 's/^Version: //p' | sed 's/+fixed.*//')
 
 # Don't forget to recreate debian/control after editing these lines: $ debian/rules debian/control
 export MAJOR_VERSION=11
@@ -17,12 +17,17 @@
 override_dh_auto_install: $(SUPPORTED_ARCHITECTURES:%=get-images-%)
 
 get-images-%:
-	if ! ./get-images.sh $* && [ -n "$(DISTRIBUTION_FALLBACK)" ]; then\
-		echo; echo; echo; \
-		echo "Version not found in $(DISTRIBUTION), falling back to $(DISTRIBUTION_FALLBACK)"; \
-		echo; echo; echo; \
-		sleep 5; \
-		DISTRIBUTION=$(DISTRIBUTION_FALLBACK) ./get-images.sh $*; \
+	if ! ./get-images.sh $*; then \
+		if [ -n "$(DISTRIBUTION_FAL

Bug#907541: [openjdk-8] Bind to a multicast address fails

[Thorsten Glaser]

tags 907541 + confirmed upstream
found 907541 openjdk-8/8u292-b10-1
found 907541 openjdk-11/11.0.12+4-1
thanks

On Wed, 29 Aug 2018, Andre Naujoks wrote:

> This bugs affects all currently available Java versions in Debian (7, 8, 10 
> and 11).
> I don't know how to mark this here.

Normally, cloning the bug against all affected packages,
but I’m Cc’ing Doko on this hoping he’ll DTRT ☺

> The contents of the patch should
> be usable for all versions with very little change.
[…]
> The attached patch fixes/adds this in the jvm.

This is another of these things where it’d be preferable to
fix this upstream first then apply the patch in Debian packages.
However it’s small and easily applied ahead of time. It’d be no
good if I’d fix this in openjdk-8 but 11 (and 17, possibly) are
unfixed; Doko?

Andre, can you report this upstream?

Thanks,
//mirabilos
-- 
15:41⎜ Somebody write a testsuite for helloworld :-)

Bug#989868: ITP: illustrate -- cartoonish representations of large biological molecules

[Steffen Moeller]

Package: wnpp
Severity: wishlist

Subject: ITP: illustrate -- cartoonish representations of large biological 
molecules
Package: wnpp
Owner: Steffen Moeller 
Severity: wishlist

* Package name: illustrate
  Version : 0.0+git20200923.217db48
  Upstream Author : David S Goodsell
* URL : https://github.com/ccsb-scripps/Illustrate
* License : Apache-2.0
  Programming Lang: (C, C++, C#, Perl, Python, etc.)
  Description : cartoonish representations of large biological molecules
 This package provides a binary to transform PDF-formatted proteins into
 simplified but instructive graphics. The software has been used for
 the Protein-of-the-month's biomolecular illustrations for the past 20
 years.

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

Bug#989111: libopenmpi-dev: broken symlinks: /usr/lib/i386-linux-gnu/openmpi/lib/libmca_common_{ofi,ompio}.so

[Andreas Beckmann]

On 26/05/2021 15.49, Alastair McKinstry wrote:
This appears to be limited to i386/ 32-bit systems. They're shipped 
elsewhere.


No, same on 64-bit:

0m50.1s ERROR: FAIL: Broken symlinks:
  /usr/lib/x86_64-linux-gnu/openmpi/lib/libmca_common_ofi.so -> 
libmca_common_ofi.so.10.0.1 (libopenmpi-dev:amd64)
  /usr/lib/x86_64-linux-gnu/openmpi/lib/libmca_common_ompio.so -> 
libmca_common_ompio.so.41.29.1 (libopenmpi-dev:amd64)


Andreas

Bug#896907: openjdk-8-jre-headless: Headless JRE package should not configure assistive technologies

[Thorsten Glaser]

On Wed, 25 Apr 2018, Mark Waite wrote:

> Java assistive
> technologies should be disabled in the *-headless package so that
> components do not mistakenly believe assistive technologies might work.

I’m not sure this is technically possible; this is a conffile,
so we cannot, from a packaging PoV, have different configurations
depending on which packages are installed.

> The openjdk-8-jre-headless package intentionally excludes user interface
> related components, but the package mistakenly enables Java assistive
> technologies which require user interface components.

On the other hand, these components probably fall under “need the
nōn-headless JRE” anyway. Here, “headless” does not mean “doesn’t
have a display attached locally” but “omits stuff for graphics”.
If your library uses graphics, chances are it needs the full JRE,
including its dependencies.

That being said, openjdk-11 currently doesn’t enable assistive
technologies at all (because they don’t work — not because of
things like this; expect them to be enabled once they work).

> The Docker
> image description says:
>
>   openjdk:slim
>
>   This image installs the -headless package of OpenJDK and so is missing
>   many of the UI-related Java libraries and some common packages contained

There you have it. You’ll need to add the full JRE.

> While using Jenkins based on the jenkins/jenkins:slim image, charts and
> graphs are not drawn because JFreeChart fails to initialize.  JFreeChart
> fails to initialize because Java assistive technologies are enabled,
> but not installed.

This sounds like something fixable in JFreeChart. Is this the same
I see packaged as libjfreechart-java in Debian? Do you have some
small reproducer for the “JFreeChart fails to initialise” problem
I can run to test this?

Thanks in advance,
//mirabilos
-- 
Sometimes they [people] care too much: pretty printers [and syntax highligh-
ting, d.A.] mechanically produce pretty output that accentuates irrelevant
detail in the program, which is as sensible as putting all the prepositions
in English text in bold font.   -- Rob Pike in "Notes on Programming in C"

Bug#980466: cervisia: missing dependency on kinit package

[Norbert Preining]

Dear Hideki,

>  I'd prepare tiny patch for this issue as below.

Thanks a lot for the NMU, much appreciated!

All the best

Norbert

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

Bug#834053: openjdk-8: java.awt.Font#deriveFont(int style) corrupts font size

[Thorsten Glaser]

tags 834053 + confirmed upstream
found 834053 openjdk-8/8u292-b10-1
found 834053 openjdk-11/11.0.12+4-1
thanks

On Mon, 18 Feb 2019, Nobuhiro Ban wrote:

> Or, should I send this report to upstream?

This would be appreciated. While we can fix that in the
Debian copies of openjdk-8, and probably Doko can fix it
in 11 and 17 as well, there’d still be differing behaviour.

Once fixed upstream applying it to all versions is easier.

@Doko: or what do you think? The diff is a one-liner

bye,
//mirabilos
-- 
>> Why don't you use JavaScript? I also don't like enabling JavaScript in
> Because I use lynx as browser.
+1
-- Octavio Alvarez, me and ⡍⠁⠗⠊⠕ (Mario Lang) on debian-devel

Bug#989867: tpm-udev: Tighten permissions of /var/lib/tpm

[Laurent Bigonville]

Package: tpm-udev
Version: 0.5
Severity: normal

Hello,

It looks like trousers daemon is checking the permissions of
/var/lib/tpm on startup.

If the permission is not correct, the daemon will try to correct them,
the logs show:

TrouSerS resetting mode of /var/lib/tpm from 40755 to: 700

Maybe the tpm-udev package should chown /var/lib/tpm to 700 out of the
box instead of letting the daemon do it?

Not sure what are the other users of that directory expecting

Kind regards,
Laurent Bigonville


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

Kernel: Linux 5.10.0-7-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Permissive - Policy name: refpolicy

Versions of packages tpm-udev depends on:
ii  adduser  3.118
ii  udev 247.3-5

tpm-udev recommends no packages.

tpm-udev suggests no packages.

-- no debconf information

Bug#819785: openjdk-8-jre-headless: Debug information missing in JRE jars

[Thorsten Glaser]

found 819785 8u292-b10-1
tags 819785 + upstream
thanks


On Sat, 2 Apr 2016, Christian Haul wrote:

> I have just discovered that stepping into JRE classes with a debugger does not
> allow inspecting variable states, the debugger complains that classes are 
> built
> without "-g" option.

They are built without any -g option. Some (jaxp, for example) use -g
but not all. Looking at jdk/make/Setup.gmk, from jdk.tar.xz, the calls
of the SetupJavaCompiler macro are all missing -g from FLAGS. The CORBA
stuff is also built without it.

There’s no single variable used by all of them where we could just add
-g so this… is going to be tricky. Ideally, you’d ask upstream to change
this for the next 8u? Is this possible?

Thanks,
//mirabilos
-- 
«MyISAM tables -will- get corrupted eventually. This is a fact of life. »
“mysql is about as much database as ms access” – “MSSQL at least descends
from a database” “it's a rebranded SyBase” “MySQL however was born from a
flatfile and went downhill from there” – “at least jetDB doesn’t claim to
be a database”  ‣‣‣ Please, http://deb.li/mysql and MariaDB, finally die!

Bug#989866: ITP: illustrate -- cartoonish representations of large biological molecules

[Steffen Möller]

Package: wnpp
Owner: Steffen Moeller 
Severity: wishlist

* Package name    : illustrate
  Version : 0.0+git20200923.217db48
  Upstream Author : David S Goodsell
* URL : https://github.com/ccsb-scripps/Illustrate
* License : Apache-2.0
  Programming Lang:  Fortran
  Description : cartoonish representations of large biological
molecules
 This package provides a binary to transform PDF-formatted proteins into
 simplified but instructive graphics. The software has been used for
 the Protein-of-the-month's biomolecular illustrations for the past 20
 years.

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

Bug#989865: unblock: debian-installer-netboot-images/20210606+fixed1

[Holger Levsen]

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

Please unblock package debian-installer-netboot-images, it includes the images
to netboot bullseye d-i RC2, it's used by the education-main-server package at
least ;)

 I'm not planning on unblocking my own upload, so reportbug is likely the 
safest bet.

debian-installer-netboot-images (20210606+fixed1) unstable; urgency=medium

  * Fix regression introduced while fixing error reporting in the previous
upload (oh, the irony), fixing the FTBFS.
  * Strip +fixed.* suffix when setting VERSION in debian/rules, to cope
with this follow-up upload for the same D-I version (20210606).

 -- Cyril Brulebois   Thu, 10 Jun 2021 06:50:59 +0200

debian-installer-netboot-images (20210606) unstable; urgency=medium

  * Update for D-I Bullseye RC 2.
  * Fix error reporting when no fallback suite is defined: exit
immediately instead of building empty packages.
  * Drop unused shared-lib-without-dependency-information lintian
overrides.
  * Add myself to Uploaders.

 -- Cyril Brulebois   Mon, 07 Jun 2021 17:47:04 +0200

$ debdiff debian-installer-netboot-images_20210415.dsc 
debian-installer-netboot-images_20210606+fixed1.dsc|diffstat
 changelog|   20 
 control  |2 +-
 control.in   |2 +-
 lintian-overrides.in |1 -
 rules|   19 ---
 5 files changed, 34 insertions(+), 10 deletions(-)

A full diff is attached.

unblock debian-installer-netboot-images/20210606+fixed1

Thanks for your work on releasing bullseye!


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

In Europe there are people prosecuted by courts because they saved other people
from drowning in the  Mediterranean Sea.  That is almost as absurd  as if there
were people being prosecuted because they save humans from drowning in the sea.


signature.asc
Description: PGP signature

Bug#989843: thunderbird: Problem loading page: NS_ERROR_NET_INADEQUATE_SECURITY

[Todor Tsankov]

Package: thunderbird
Version: 1:78.11.0-1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

Since the update to 78.11.0 Thunderbird cannot load various webpages. To
reproduce the error, try to do a search in the Add-ons Manager (type
something in the search box and press Enter).

The error message is

"The website tried to negotiate an inadequate level of security.
...
Error code: NS_ERROR_NET_INADEQUATE_SECURITY"

There is perhaps a more useful error message in the error console:

addons.thunderbird.net : server does not support RFC 5746, see CVE-2009-3555

The problem also appears when trying to load other pages or using
certain add-ons (for example, calendar-google-provider).

The problem goes away if one sets network.http.spdy.enforce-tls-profile
to false in the preferences. This makes me think that there is an issue
with the TLS library.

Cheers,
Todor



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

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

Versions of packages thunderbird depends on:
ii  debianutils  4.11.2
ii  fontconfig   2.13.1-4.2
ii  libatk1.0-0  2.36.0-2
ii  libbotan-2-172.17.3+dfsg-2
ii  libbz2-1.0   1.0.8-4
ii  libc62.31-12
ii  libcairo-gobject21.16.0-5
ii  libcairo21.16.0-5
ii  libdbus-1-3  1.12.20-2
ii  libdbus-glib-1-2 0.110-6
ii  libevent-2.1-7   2.1.12-stable-1
ii  libffi7  3.3-6
ii  libfontconfig1   2.13.1-4.2
ii  libfreetype6 2.10.4+dfsg-1
ii  libgcc-s110.2.1-6
ii  libgdk-pixbuf-2.0-0  2.42.2+dfsg-1
ii  libglib2.0-0 2.66.8-1
ii  libgtk-3-0   3.24.24-4
ii  libicu67 67.1-6
ii  libjson-c5   0.15-2
ii  libnspr4 2:4.29-1
ii  libnss3  2:3.61-1
ii  libpango-1.0-0   1.46.2-3
ii  libstdc++6   10.2.1-6
ii  libvpx6  1.9.0-1
ii  libx11-6 2:1.7.1-1
ii  libx11-xcb1  2:1.7.1-1
ii  libxcb-shm0  1.14-3
ii  libxcb1  1.14-3
ii  libxext6 2:1.3.3-1.1
ii  libxrender1  1:0.9.10-1
ii  psmisc   23.4-2
ii  x11-utils7.7+5
ii  zlib1g   1:1.2.11.dfsg-2

Versions of packages thunderbird recommends:
ii  hunspell-bg [hunspell-dictionary]1:7.1.0~rc3-3
ii  hunspell-en-gb [hunspell-dictionary] 1:7.1.0~rc3-3
ii  hunspell-en-us [hunspell-dictionary] 1:2019.10.06-1
ii  hunspell-fr-classical [hunspell-dictionary]  1:7.0-1

Versions of packages thunderbird suggests:
ii  apparmor  2.13.6-10
ii  fonts-lyx 2.3.6-1
ii  libgssapi-krb5-2  1.18.3-5
ii  libgtk2.0-0   2.24.33-2

Bug#989864: unblock: distro-info-data/0.48

[Stefano Rivera]

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

Please unblock package distro-info-data

distro-info-data (0.48) unstable; urgency=medium

  * Correct typo in changelog.
  * Set a release date for Debian bullseye (and bookworm creation), based on
the release team's tentative estimate.

[ Reason ]
We've got a tentative release date, let's roll with it.
If we slip, we can do a follow-up upload.

[ Impact ]
Bullseye will ship with distro-info that doesn't know the current
development release.

[ Tests ]
Data package. With some sanity-check tests.

[ Risks ]
Just a data package.

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

unblock distro-info-data/0.48
diff -Nru distro-info-data-0.47/debian/changelog 
distro-info-data-0.48/debian/changelog
--- distro-info-data-0.47/debian/changelog  2021-04-22 10:30:18.0 
-0400
+++ distro-info-data-0.48/debian/changelog  2021-06-14 17:47:09.0 
-0400
@@ -1,6 +1,14 @@
+distro-info-data (0.48) unstable; urgency=medium
+
+  * Correct typo in changelog.
+  * Set a release date for Debian bullseye (and bookworm creation), based on
+the release team's tentative estimate.
+
+ -- Stefano Rivera   Mon, 14 Jun 2021 17:47:09 -0400
+
 distro-info-data (0.47) unstable; urgency=medium
 
-  * Add Ubuntu 21.04, Impish Indri.
+  * Add Ubuntu 21.10, Impish Indri.
 
  -- Stefano Rivera   Thu, 22 Apr 2021 10:30:18 -0400
 
diff -Nru distro-info-data-0.47/debian.csv distro-info-data-0.48/debian.csv
--- distro-info-data-0.47/debian.csv2021-04-22 10:30:18.0 -0400
+++ distro-info-data-0.48/debian.csv2021-06-14 17:47:09.0 -0400
@@ -14,8 +14,8 @@
 8,Jessie,jessie,2013-05-04,2015-04-25,2018-06-17,2020-06-30,2022-06-30
 9,Stretch,stretch,2015-04-25,2017-06-17,2020-07-06,2022-06-30
 10,Buster,buster,2017-06-17,2019-07-06,2022-07-06,2024-06-30
-11,Bullseye,bullseye,2019-07-06
-12,Bookworm,bookworm,2021-08-01
+11,Bullseye,bullseye,2019-07-06,2021-07-31,2024-07-31
+12,Bookworm,bookworm,2021-07-31
 13,Trixie,trixie,2023-08-01
 ,Sid,sid,1993-08-16
 ,Experimental,experimental,1993-08-16

Bug#987149: xscreensaver: allows starting external programs with cap_net_raw

[Tormod Volden]

This issue is marked as affecting 5.42+dfsg1-1 in buster (and even
stretch) in our CVE tracker, however the set_cap action was first
added in 5.44+dfsg1-1.

https://security-tracker.debian.org/tracker/CVE-2021-31523

Tormod

Bug#989508: xscreensaver: Disconnecting a video output can cause XScreenSaver to crash and unlock

[Tormod Volden]

This issue is marked as affecting 5.42+dfsg1-1 in buster (and even
stretch) in our CVE tracker, however the openwall report says:

"The issue affects only XScreenSaver version 5.45. Versions 5.44 and
older, as well as 6.00, are not affected."

Tormod

Bug#989365: Acknowledgement (RFS: recastnavigation)

[bret curtis]

tags 989365 - moreinfo


On Sun, Jun 13, 2021 at 10:29 AM Tobias Frost  wrote:

> On Sun, Jun 13, 2021 at 12:03:26AM +0200, bret curtis wrote:
> > > New packages (ITPs) can go to unstable; (they don't interfere with the
> freeze)
> >
> > https://mentors.debian.net/package/recastnavigation/
>
> - the watch file seems not to work; (take a look at uscan(1) and
>   https://wiki.debian.org/debian/watch#GitHub)
>   You can also do some commit-based watch-file with uscan, uscan(1) says
> how to
>   (I doing something like that in dhewm3 and rbdoom3bfg)


I updated this, but I couldn't test it directly because I was on a Ubuntu
laptop and the uscan failed on version=4
Can you validate this please?

- d/control:
>   - cmake (>= 3) | cmake3
> - there is no cmake3 package; drop that alternative.
> - the versioned dependency is not needed; even oldstable has cmake > 3
>   - shouln't the library package also be named librecastnavigation?
> (it should match the -dev package's name
>   - you)
>
>
Took care of all of this as well.


> - d/copyright:
>   - Can you add a debian/* section with your name to d/copyright?
>   - I saw at least one file where the copyright years where 2010 and one
> file
> under PD not mentioned at all. There is also a font without source.
> (in the Demo)
> Please review every file and check your copyright file to make sure
> that it
> is complete.
>   - (nitpick: Trailing whitespaces in d/copyright; plz remove…
> as you likely know wrap-and-sort(1) can do that for you.
>

Nit picked. Everything is taken care of as well. We have a mix of: BSL-1,
Apache, MIT and GPL-3 :)


> (for the todo list -- not needed for this upload -- embedded code library:
> fastlz)
>   This library is intended to be copied in the source;
>   - that copy  seems to be rather old. Maybe ask upstream to update
> to some more recent version?
>   - Possibly fastlz should be pacakged… A file search seems to
> indicate that there would be other pacakges benefiting from this as
> well.
>   - Check for more details: https://wiki.debian.org/EmbeddedCopies
>   - It seems only be used in the demo; if you dont use the demo in any way,
> you could Files-Exclude the demo and be done. This would also fix the
> font
> issue.
>
>
fastlz is just for the demo and we do not currently ship the demo, so I'm
not worried about this. Upstream is aware of this and they rather embed
than use submodules, though I did push them to use cmake, so perhaps I can
convince them to use cmake's fetch content instead? They are
primarly focused on premake though. The Demo is not made here, so nothing
to Exclude. :)


> (can be done later too; no blocker for this upload:)
> I see a tests folder… Would it make sense to run them in autopkgtsts?
>

This one I didn't do, but I can add this later. Is that okay?


> please review your package and remove the moreinfo tag when ready.
>

Cool, thanks! :)

Cheers,
Bret

Bug#989821: RFS: elementary-terminal/5.5.2-1~exp1 [ITP] -- Modern terminal from elementary project

[Francisco M Neto]

Hello again!

This is just a follow-up. I decided to give it a try and succeeded in
changing the final executable from io.elementary.terminal to
elementary-terminal.

Cheers
Francisco

On 2021-06-14 13:25, Francisco M Neto wrote:
> Hello!
>
> On 2021-06-14 14:45, Adam Borowski wrote:
> > Is there a reason you left the executable named "io.elementary.terminal"?
> > The website — nor its reverse — is not relevant to a user; people instead
> > expect the principal executable to be named same as the package — and also,
> > our convention is to name terminals "${FOO}-terminal".
>
>   I went the other way, actually. At first I noticed the weird
> executable name and wondered if I should rename it; but that would imply
> making changes to the source (with possible unforseen consequences).
> After asking in #debian-mentors I decided it was not worth the troulble.
>
> > (On the other hand, if you strongly insist on keeping that Javaesque name,
> > this is not a blocker, I'll just whine and upload.)
>
>   I'm not married to that solution. If you think it's better to follow
> the convention I'm okay with it. I'll make the necessary changes :)
>
> > Most of translation .po files are empty — is there any reason to ship them?
> > (But this can be considered an upstream bug.)
>
>   That's pretty much what I figured. I didn't want to change the
> upstream source so i just left those there. As for the "mo" locale, I've
> notified them about it - it seems to be a generalized problem so I
> wasn't sure where to file a bug report.
>
>   I haven't received an answer from them, though, so I'm thinking I
> might just file a bug report on each package and move on.
>
> > Package description: "originalle" should be translated to English.  (Such
> > pointless mixing of languages would postpone world domination of English
> > ad calendas graecas ☺.)
>
>   That wasn't actually a translation; it was a typo... :P
>
>   But thanks for pointing it out, I've corrected it.
>
> > --
> > ⢀⣴⠾⠻⢶⣦⠀ What Would Jesus Do, MUD/MMORPG edition:
> > ⣾⠁⢠⠒⠀⣿⡁ • multiplay with an admin char to benefit own mortal [Mt3:16-17]
> > ⢿⡄⠘⠷⠚⠋⠀ • abuse item cloning bugs [Mt14:17-20, Mt15:34-37]
> > ⠈⠳⣄ • use glitches to walk on water [Mt14:25-26]
> >
>
> I loved that swirl! I've been looking for one for some time. Mind if I
> "steal" it from you?
>
> --
> []'s
> |
> Francisco M Neto|
>  | 3E58 1655 9A3D 5D78 9F90
> | CFF1 D30B 1694 D692 FBF0



--
[]'s
|
Francisco M Neto|
 | 3E58 1655 9A3D 5D78 9F90
| CFF1 D30B 1694 D692 FBF0


signature.asc
Description: PGP signature

Bug#989843: thunderbird: Problem loading page: NS_ERROR_NET_INADEQUATE_SECURITY

[Reiner]

Dear Maintainer,


I can confirm this behavior too, with an gmail account since today.

In the morning before the update, gmail was working. Now it isn't.


This error message in german language is shown:

Die Website versuchte, eine unpassende Sicherheitsstufe auszuhandeln.  
live.thunderbird.net verwendet Sicherheitstechnologie, welche veraltet 
und verwundbar ist. Ein Angreifer könnte leicht Informationen 
entschlüsseln, welche Sie für sicher hielten. Der Website-Administrator 
muss dieses Problem auf dem Server beheben, bevor Sie die Seite aufrufen 
können. Fehlercode: NS_ERROR_NET_INADEQUATE_SECURITY



regards

Reiner


On Mon, 14 Jun 2021 19:31:37 +0200 Todor Tsankov  wrote:

> Package: thunderbird
> Version: 1:78.11.0-1
> Severity: grave
> Justification: renders package unusable
>
> Dear Maintainer,
>
> Since the update to 78.11.0 Thunderbird cannot load various webpages. To
> reproduce the error, try to do a search in the Add-ons Manager (type
> something in the search box and press Enter).
>
> The error message is
>
> "The website tried to negotiate an inadequate level of security.
> ...
> Error code: NS_ERROR_NET_INADEQUATE_SECURITY"
>
> There is perhaps a more useful error message in the error console:
>
> addons.thunderbird.net : server does not support RFC 5746, see 
CVE-2009-3555

>
> The problem also appears when trying to load other pages or using
> certain add-ons (for example, calendar-google-provider).
>
> The problem goes away if one sets network.http.spdy.enforce-tls-profile
> to false in the preferences. This makes me think that there is an issue
> with the TLS library.
>
> Cheers,
> Todor
>
>
>
> -- System Information:
> Debian Release: 11.0
> APT prefers testing
> APT policy: (500, 'testing')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 5.10.0-7-amd64 (SMP w/4 CPU threads)
> Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE
> not set
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> Versions of packages thunderbird depends on:
> ii debianutils 4.11.2
> ii fontconfig 2.13.1-4.2
> ii libatk1.0-0 2.36.0-2
> ii libbotan-2-17 2.17.3+dfsg-2
> ii libbz2-1.0 1.0.8-4
> ii libc6 2.31-12
> ii libcairo-gobject2 1.16.0-5
> ii libcairo2 1.16.0-5
> ii libdbus-1-3 1.12.20-2
> ii libdbus-glib-1-2 0.110-6
> ii libevent-2.1-7 2.1.12-stable-1
> ii libffi7 3.3-6

Bug#989773: unblock: xscreensaver/5.45+dfsg1-2

[Tormod Volden]

On Mon, Jun 14, 2021 at 9:45 AM Sebastian Ramacher wrote:
>
> xscreensaver already migrated.

Thanks for taking care of the migration!

> > Question:
> > The trivial addition of a missing " || true" in debian/rules* would fix
> > building on kfreebsd/hurd. Could that be considered?
>
> I would prefer changes not relevant for bullseye to be deferred for
> bookworm. This makes it easier to review unblock requests.
>
> In any case, the change would be wrong. It would hide legitimate build
> failures on other architectures. If this part of the build is not
> supposed to run on kfreebsd-*, do not run it on kfreebsd.

It is not that bad: We only pull in the systemd-dev dependency on
Linux, through debian/control. The upstream build only generates the
systemd tool if the dev library was pulled in. The || true in question
is only closing the "if a built systemd tool exists, install it"
clause. A build failure on any architecture would fail in the build
proper, before this install step.

If we should add an arch-specific clause in debian/rules, it would be
two places to maintain. But in case, what is the recommended way to do
it? dpkg-architecture matching?

Regards,
Tormod

Bug#989777: Re: Severity: High / Debian 10 &amp; 11 with Kernel 5.10.x-amd64 =&gt; Intel AX210 Wifi &amp; Bluetooth not work

[pham...@bluewin.ch]

The boot is difficult, I have a recurring error message that turns in a loop.

journalctl -k | grep -Ei "iwl|bluetooth :


root@portable-1:~# journalctl -k | grep -Ei "iwl|bluetooth"
jun 14 22:48:11 portable-1 kernel: iwlwifi :3b:00.0: enabling device ( 
-> 0002)
jun 14 22:48:11 portable-1 kernel: iwlwifi :3b:00.0: firmware: 
direct-loading firmware iwlwifi-ty-a0-gf-a0-59.ucode
jun 14 22:48:11 portable-1 kernel: iwlwifi :3b:00.0: api flags index 2 
larger than supported by driver
jun 14 22:48:11 portable-1 kernel: iwlwifi :3b:00.0: TLV_FW_FSEQ_VERSION: 
FSEQ Version: 93.8.63.28
jun 14 22:48:11 portable-1 kernel: iwlwifi :3b:00.0: loaded firmware 
version 59.601f3a66.0 ty-a0-gf-a0-59.ucode op_mode iwlmvm
jun 14 22:48:11 portable-1 kernel: iwlwifi :3b:00.0: firmware: failed to 
load iwl-debug-yoyo.bin (-2)
jun 14 22:48:12 portable-1 kernel: iwlwifi :3b:00.0: Detected Intel(R) 
Wi-Fi 6 AX210 160MHz, REV=0x420
jun 14 22:48:12 portable-1 kernel: Bluetooth: Core ver 2.22
jun 14 22:48:12 portable-1 kernel: Bluetooth: HCI device and connection manager 
initialized
jun 14 22:48:12 portable-1 kernel: Bluetooth: HCI socket layer initialized
jun 14 22:48:12 portable-1 kernel: Bluetooth: L2CAP socket layer initialized
jun 14 22:48:12 portable-1 kernel: Bluetooth: SCO socket layer initialized
jun 14 22:48:12 portable-1 kernel: iwlwifi :3b:00.0: firmware: failed to 
load iwlwifi-ty-a0-gf-a0.pnvm (-2)
jun 14 22:48:12 portable-1 kernel: iwlwifi :3b:00.0: base HW address: 
54:14:f3:52:7b:e1
jun 14 22:48:12 portable-1 kernel: Bluetooth: hci0: Reading Intel version 
information failed (-22)
jun 14 22:48:12 portable-1 kernel: Bluetooth: hci0: Intel Read version failed 
(-22)
jun 14 22:48:12 portable-1 kernel: Bluetooth: hci0: Intel reset sent to retry 
FW download
jun 14 22:48:12 portable-1 kernel: iwlwifi :3b:00.0 wlp59s0: renamed from 
wlan0
jun 14 22:48:12 portable-1 kernel: Bluetooth: BNEP (Ethernet Emulation) ver 1.3
jun 14 22:48:12 portable-1 kernel: Bluetooth: BNEP filters: protocol multicast
jun 14 22:48:12 portable-1 kernel: Bluetooth: BNEP socket layer initialized
jun 14 22:48:12 portable-1 kernel: Bluetooth: hci0: Reading Intel version 
information failed (-22)
jun 14 22:48:12 portable-1 kernel: Bluetooth: hci0: Intel Read version failed 
(-22)
jun 14 22:48:12 portable-1 kernel: Bluetooth: hci0: Intel reset sent to retry 
FW download
jun 14 22:48:13 portable-1 kernel: Bluetooth: hci0: Reading Intel version 
information failed (-22)
jun 14 22:48:13 portable-1 kernel: Bluetooth: hci0: Intel Read version failed 
(-22)
jun 14 22:48:13 portable-1 kernel: Bluetooth: hci0: Intel reset sent to retry 
FW download


systemctl status bluetooth.service :


root@portable-1:~# systemctl status bluetooth.service
● bluetooth.service - Bluetooth service
 Loaded: loaded (/lib/systemd/system/bluetooth.service; enabled; vendor 
preset: enabled)
 Active: active (running) since Mon 2021-06-14 22:48:12 CEST; 10min ago
   Docs: man:bluetoothd(8)
   Main PID: 649 (bluetoothd)
 Status: "Running"
  Tasks: 1 (limit: 38030)
 Memory: 2.6M
CPU: 266ms
 CGroup: /system.slice/bluetooth.service
 └─649 /usr/libexec/bluetooth/bluetoothd

jun 14 22:48:12 portable-1 bluetoothd[649]: 
src/main.c:parse_controller_config() Key file does not have key 
“LEScanIntervalConnect” in >
jun 14 22:48:12 portable-1 bluetoothd[649]: 
src/main.c:parse_controller_config() Key file does not have key 
“LEScanWindowConnect” in gr>
jun 14 22:48:12 portable-1 bluetoothd[649]: 
src/main.c:parse_controller_config() Key file does not have key 
“LEMinConnectionInterval” i>
jun 14 22:48:12 portable-1 bluetoothd[649]: 
src/main.c:parse_controller_config() Key file does not have key 
“LEMaxConnectionInterval” i>
jun 14 22:48:12 portable-1 bluetoothd[649]: 
src/main.c:parse_controller_config() Key file does not have key 
“LEConnectionLatency” in gr>
jun 14 22:48:12 portable-1 bluetoothd[649]: 
src/main.c:parse_controller_config() Key file does not have key 
“LEConnectionSupervisionTim>
jun 14 22:48:12 portable-1 bluetoothd[649]: 
src/main.c:parse_controller_config() Key file does not have key 
“LEAutoconnecttimeout” in g>
jun 14 22:48:12 portable-1 systemd[1]: Started Bluetooth service.
jun 14 22:48:12 portable-1 bluetoothd[649]: Starting SDP server
jun 14 22:48:12 portable-1 bluetoothd[649]: Bluetooth management interface 1.18 
initialized
lines 1-22/22 (END)


If I can be useful for make a test on my system, do not hesitate to ask me it.

Meilleures salutations.

Philippe



Message d'origine
De : vincent.deb...@free.fr
Date : 14/06/2021 - 22:38 (E)
À : pham...@bluewin.ch
Cc : li...@packages.debian.org, 989...@bugs.debian.org, andreimpope...@gmail.com
Objet : Re: Severity: High / Debian 10 & 11 with Kernel 5.10.x-amd64 
=> Intel AX210 Wifi & Bluetooth not work

Le 2021-06-14 22:19, pham...@bluewin.ch a écrit :
> Salut Vincent,
> 
> I have rebooted my Laptop after downgrad

Bug#988649: rdate: UDP connection enforced by '-n', no possible to use SNTP over TCP

[Eriberto]

Control: fixed 988649 upstream/1.10.1

Em seg., 17 de mai. de 2021 às 08:24, artur128  escreveu:
>
[...]
> "-u Use UDP instead of TCP as transport."
> ...
>
> but if you use the "-n" you also forced to use UDP-packets.
>
> it would be nice if the manpage would mention that.

Hi artur128,

Thanks a lot for your contribution. The manpage was already improved
on the upstream side (options -n, -o and -u)[1]. I think Thiago (rdate
maintainer in Debian) will update the package after the current freeze
time.

[1] 
https://github.com/resurrecting-open-source-projects/openrdate/blob/master/docs/rdate.txt

Cheers,

Eriberto

Bug#989863: debian-installer: Firmware problems in bullseye

[Cyril Brulebois]

Package: debian-installer
Severity: important

Hi,

This is an umbrella bug report that I intend to use to track at least
two separate issues (that are really the two sides of the same coin):

 - Official installation images (main-only) might lead to a successful
   installation but result in a black screen upon rebooting the
   installed system. Some of these issues are due to free drivers
   wanting or even requiring some firmware to work properly, on a
   per-device basis.

 - Unofficial installation images (shipping firmware from non-free)
   might also lead to a successful installation but result in the same
   kind of issue due to the way firmware detection is happening.


Please don't turn this bug report into a “firmware packages should have
their own section”, or “firmware packages should be in the installation
images”, etc. If you'd like to change the project's consensus on this,
please follow the appropriate process (see previous firmware GRs). I'm
not speaking for the installer team as a whole, but I would personally
be happy if we could make the life or our users easier in the current
times where escaping non-free is *very* hard. But again, I don't think
we're entitled to making this kind of decision, and that kind of thing
should be discussed with the Debian project as a whole, not here.


This bug report and follow-ups (one bug report for each of those two
issues, which will block this one) are about trying to implement
practical (even if imperfect) solutions for Debian 11.

People wanting to learn about this can refer to Lucas's tentative
summary of earlier threads on mailing lists, and to my reply:
 - https://lists.debian.org/debian-release/2021/04/msg00646.html
 - https://lists.debian.org/debian-release/2021/04/msg00711.html


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

Bug#989814: kodi: Kodi UI breaks with tr_TR.UTF-8 charset.

[Vasyl Gello]

Source: kodi
Followup-For: Bug #989814

Control: forwarded -1 https://github.com/xbmc/xbmc/issues/19883

Hi Hakan!

I was able to reproduce the issue and forwarded it upstream.

It looks the problem manifests itself if the following conditions are met:

  * Turkish locale is generated on the system
  * It is also activated by means of Kodi's Turkish language addon,
or externally by means of LC_CTYPE, LANG or LC_ALL environment variables
pointing to `tr_TR.UTF-8`.

For me it is still unclear if it is XBT decompressor's fault or XML parser.
We will try to dig this problem away :)

Regards,
Vasyl

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

Kernel: Linux 5.10.0-7-amd64 (SMP w/6 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=C, LC_CTYPE=C (charmap=UTF-8) (ignored: LC_ALL set to 
en_US.UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Bug#989862: gcc-mingw-w64: coverage is completely broken

[Stephen Kitt]

Package: gcc-mingw-w64
Version: 22~exp1
Severity: important

Dear Maintainer,

Ever since gcc-mingw-w64 was updated to use GCC 8, gcov has been
broken:

$ x86_64-w64-mingw32-gcc -fprofile-generate -x c - <<<'void main(){}'
/usr/bin/x86_64-w64-mingw32-ld: /tmp/user/1000/ccBN30sM.o::(.text+0x29): 
undefined reference to `__gcov_indirect_call_profiler_v4'
/usr/bin/x86_64-w64-mingw32-ld: /tmp/user/1000/ccBN30sM.o::(.data+0x98): 
undefined reference to `__gcov_merge_time_profile'
/usr/bin/x86_64-w64-mingw32-ld: 
/tmp/user/1000/ccBN30sM.o::(.rdata$.refptr.__gcov_time_profiler_counter[.refptr.__gcov_time_profiler_counter]+0x0):
 undefined reference to `__gcov_time_profiler_counter'
/usr/bin/x86_64-w64-mingw32-ld: 
/tmp/user/1000/ccBN30sM.o::(.rdata$.refptr.__gcov_indirect_call[.refptr.__gcov_indirect_call]+0x0):
 undefined reference to `__gcov_indirect_call'
collect2: error: ld returned 1 exit status

This also renders PGO unusable.

See
https://bugs.launchpad.net/ubuntu/+source/gcc-mingw-w64/+bug/1883933
and
https://bugs.launchpad.net/ubuntu/+source/gcc-mingw-w64/+bug/1920988
for related issues.

Regards,

Stephen


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

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

Versions of packages gcc-mingw-w64 depends on:
ii  gcc-mingw-w64-i68610-20200402-1+23~exp1
ii  gcc-mingw-w64-x86-64  10-20200402-1+23~exp1

gcc-mingw-w64 recommends no packages.

gcc-mingw-w64 suggests no packages.

-- no debconf information

Bug#989777: Severity: High / Debian 10 & 11 with Kernel 5.10.x-amd64 => Intel AX210 Wifi & Bluetooth not work

[Vincent Blut]

Le 2021-06-14 22:19, pham...@bluewin.ch a écrit :
> Salut Vincent,
> 
> I have rebooted my Laptop after downgrading the firmware, this must have 
> restarted the iwlmvm and iwlwifi services, which allowed me to launch an 
> internet connection by Wifi.

OK, that's good to hear.

> But nothing to do for Bluetooth, it refuses to work.

Could you please attach the output of the following commands:
$ sudo journalctl -k | grep -Ei "iwl|bluetooth"
$ sudo systemctl status bluetooth.service


signature.asc
Description: PGP signature

Bug#989781: docker.io: Docker fails to run containers because it unsuccessfully tries to load an AppArmor profile

[Tianon Gravi]

On Sat, 12 Jun 2021 at 15:33, Lars Veldscholte  wrote:
> I am not sure of the proper way to deal with this issue. Should I
> install the AppArmor userspace utilities, even though I do not need them
> myself? Or should I disable AppArmor completely by explicity setting a
> kernel parameter (which the Debian wiki does not recommend)?

If you don't completely disable AppArmor but also do not install the
userspace utilities, you will always be in this halfway state where
AppArmor *is* enabled, but most programs won't be able to use/deal
with it effectively.

If you really want to avoid AppArmor completely, I would suggest
actually disabling it, although just installing the userspace
utilities will allow your containers to benefit from AppArmor-based
protections -- it's another layer of protection (and my experience
using the Debian implementation of AppArmor on both desktop and server
systems is that it stays out of the way pretty well).

> In the former case, docker.io should probably depend on the apparmor
> package (it is currently a recommendation), since Docker is not usable
> (as far as I understand) without it.

Looking at [1], Recommends: is definitely appropriate here:

| This declares a strong, but not absolute, dependency.
|
| The Recommends field should list packages that would be found
together with this one in all but unusual installations.

[1]: 
https://www.debian.org/doc/debian-policy/ch-relationships.html#binary-dependencies-depends-recommends-suggests-enhances-pre-depends

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

Bug#989777: Severity: High / Debian 10 & 11 with Kernel 5.10.x-amd64 => Intel AX210 Wifi & Bluetooth not work

[pham...@bluewin.ch]

Salut Vincent,

I have rebooted my Laptop after downgrading the firmware, this must have 
restarted the iwlmvm and iwlwifi services, which allowed me to launch an 
internet connection by Wifi.

But nothing to do for Bluetooth, it refuses to work.

Regards.

Philippe



Message d'origine
De : vincent.deb...@free.fr
Date : 14/06/2021 - 21:59 (E)
À : pham...@bluewin.ch
Cc : andreimpope...@gmail.com, 989...@bugs.debian.org, li...@packages.debian.org
Objet : Re: Severity: High / Debian 10 & 11 with Kernel 5.10.x-amd64 => 
Intel AX210 Wifi & Bluetooth not work

Salut Philippe,

Le 2021-06-14 21:48, pham...@bluewin.ch a écrit :
> Hello Andrei,
> I must have "my head in the moon" as we say in French :) I did not see the 
> download link...
> After uninstall of the new "firmware-iwlwifi_20210315-2_all.deb" and 
> installation of the old "firmware-iwlwifi_20210208-4_all.deb" the Wifi work 
> fine, but the Bluetooth not work, I dont have access to my Bluetooth devices 
> ;-(

Did you reload the iwlmvm and iwlwifi modules after downgrading the firmware?

> Best regards.
> Philippe

Cheers,
Vincent

Bug#989861: undertow: CVE-2021-3597

[Salvatore Bonaccorso]

Source: undertow
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for undertow, though it is
hard to tell if our version is affected, [1] lacks details.

CVE-2021-3597[0]:
No description was found (try on a search engine)

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2021-3597
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-3597
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1970930

Regards,
Salvatore

Bug#989860: unblock: ieee-data/20210605.1

[Samuel Henrique]

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

Please unblock package ieee-data

[ Reason ]
The package ieee-data provides the mapping between MAC address
prefixes and vendors and a script to update its data. We should always
try to provide the most up-to-date data out-of-the-box to our users.

I have prepared a new release for buster, with the updated data,
adding myself as an Uploader and fixing an error in d/copyright:
d/changelog:
* Update all txt and cvs files with data from Jun 05
* Add myself as an uploader
* d/copyright: Remove duplicate globbing patterns

[ Impact ]
We will ship outdated data in the package and the users will have to
manually update it, thus defeating half of the purpose of the package
(the "other half" purpose is to ship a script to update this data).
The data being updated in this upload should be kept up-to-date even
after bullseye gets released, so it's very likely that I'll send
bullseye-pu at some point in the future as well.

The data shipped by ieee-data is also used by other packages, and
lintian tries to enforce that[0].

[ Tests ]
The files were downloaded with the script shipped in the package and I
didn't spot any corruption of data.

[ Risks ]
Risk 1) To have corrupted data in the files. Easy to revert. Could
also be triggered by the package's own script to update its files.

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

[ Other info ]
The diff is too big to be attached here.
Here is the list of commits by order of importance:
https://salsa.debian.org/debian/ieee-data/-/commit/585a84f746390c3d10a8d26165df9290e095ea01
https://salsa.debian.org/debian/ieee-data/-/commit/71c6bc5648bcbbdc78c05b6154d4bc77d533554f
https://salsa.debian.org/debian/ieee-data/-/commit/ad6729aa8334d2eca48d463c85a144aaaea5e15d
https://salsa.debian.org/debian/ieee-data/-/commit/151e027733524eafaa7e42bc69a80d54c178ec7a

* I just realized there's a typo on "cvs", it should be "csv", but
it's too late now.

unblock ieee-data/20210605.1

[0] https://lintian.debian.org/tags/package-installs-ieee-data

--
Samuel Henrique 

Bug#989777: Severity: High / Debian 10 & 11 with Kernel 5.10.x-amd64 => Intel AX210 Wifi & Bluetooth not work

[Vincent Blut]

Salut Philippe,

Le 2021-06-14 21:48, pham...@bluewin.ch a écrit :
> Hello Andrei,
> I must have "my head in the moon" as we say in French :) I did not see the 
> download link...
> After uninstall of the new "firmware-iwlwifi_20210315-2_all.deb" and 
> installation of the old "firmware-iwlwifi_20210208-4_all.deb" the Wifi work 
> fine, but the Bluetooth not work, I dont have access to my Bluetooth devices 
> ;-(

Did you reload the iwlmvm and iwlwifi modules after downgrading the firmware?

> Best regards.
> Philippe

Cheers,
Vincent


signature.asc
Description: PGP signature

Bug#989597: release.debian.org: upgrade issue: non-coinstallability of libgdal20 and libgdal28

[Sebastian Ramacher]

On 2021-06-14 13:49:47 +0200, Sebastiaan Couwenberg wrote:
> On 6/14/21 1:30 PM, Andreas Beckmann wrote:
> > On 14/06/2021 10.06, Sebastiaan Couwenberg wrote:
> >> What actual problems do are solved by making them co-installable?
> >>
> >> So far the only actualy problem that has been identified is the need for
> >> `apt full-upgrade` twice when the Breaks/Replaces on libgdal20 is not
> >> present.
> > 
> > apt currently fails to find an upgrade path for libmrpt-dev (logfile
> > attached, no bug filed, yet). The only solution I could find so far was
> > the big hammer: adding a Breaks against libopencv-core3.2 (or similar)
> > to gcc-10-base.
> > With a co-installable libgdal20/libgdal28 this is gone because the huge
> > dependency trees no longer conflict with each other.
> > 
> > Co-installable libgdal20/28 solves a lot of buster->bullseye upgrade
> > issues. So I can concentrate on fixing the remaining incomplete
> > (unversioned) python (2) removal bits. ;-)
> 
> If co-installable libgdal is a must, then I'd rather drop gdal-data and
> move its content back to libgdal28 with an override for the
> big-usr-share lintian issue. That's how it was a long time ago:
> 
>  
> https://salsa.debian.org/debian-gis-team/gdal/-/commit/140ab452687b2a6d92f3b760379fbbd81f80794a
> 
> I'm not in favor of either option, though.

Not having libgdal20 and libgdal28 co-installable makes it unneccessarly
hard to upgrade all of libgdal's reverse dependencies that also bumped
SONAMEs.  That set of packages includes at least opencv, pdal, qgis,
vtk7, otb, mapnik, openscenegraph and gazebo. And then there are
probably even more that are reverse dependencies of those packages which
bumped SONAME.  So this issues affects many many packages and is not
only related to postgis.

But let's come back to postgis. I tried to look into upgrades and what
users are expected to do here. Upstream's documentation on this topic
can be found at
https://postgis.net/workshops/postgis-intro/upgrades.html. So, what I
gather from that is that one possible way to upgrade is:

* Mark postgresql-11-postgis-2.5 as hold to ensure it's not removed.
* Upgrade enough packages so that one gets the postgresql 13 development
  packages and postgresql-13 installed.
* Manually build postgis 2.5.x against postgresql 13 and install it.
* pg_upgradecluster
* Finish the buster -> bullseye upgrade
* Once postgresql-13-postgis-3 is installed, upgrade the postgis
  extension.

I tried that starting from a minimal chroot only having postgis and
postgresql installed, but was unable to end up with a set of packages which
allows me to build postgis 2.5 against postgresql 13 without getting
postgresql-11-postgis-2.5 removed first. And even if it worked, one
would have to rebuild postgis 2.5.x at some point against libgdal28 to
finish the upgrade.

Next option:

* pg_dumpall
* Upgrade to bullseye
* Build postgis 2.5.x against postgresql 13 and install the extensions.
* pg_restore
* Upgrade the postgis extension.

This could work, I guess. But I didn't try it.

Or, alternatively, first manually build postgis 3.1.x in buster:

* Build postgis 3.1.x against postgresql 11 and install the extension
* Upgrade the postgis extension.
* Upgrade buster to bullseye
* pg_upgradecluster

Before running pg_upgradecluster one would probably need to rebuild postgis
3.1.x against postgresql 11 again because of libgdal28.

Are there any other options?

In any case, all these options seem rather unsatisfying and fragile.
Manually building specific postgis versions against specific postgresql
versions seems like a recipe for desaster. If one screws up any of the
steps, one can only hope for a backup and needs to start over. libgdal's
co-installablity issue makes that even more brittle then necessary if
not impossible.

To be honest, from a package in Debian I would expect more. This is a
frustrating upgrade experience. And even if we cannot fix postgis
upgrades in time, having libgdal20 and libgdal28 not co-installable,
makes it only more painful for our users. So I'd say, yes, libgdal20 and
libgdal28 co-installablity is a must.

> We can also drop the Breaks from gdal-data, and have libgdal20 be broken
> for the bits that use it. It will help with the dependency resolution.

If a non-function libgdal20 would mean that even if if installed, it's
completely useless for the cases above, then no, that's not an option.

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#989179: aeskeyfind calculates wrong results on kernel 5.10.0.6 and glibc 2.31-11

[Samuel Henrique]

Hello,

> My reading of the code is that it was intended to be
> -t = set_byte(t, (j-1)%4, sbox[get_byte(k,j)]);
> +t = set_byte(t, (j-1+4)%4, sbox[get_byte(k,j)]);

It's looking good, I have uploaded 1:1.0-10 to unstable, hopefully
this was the only issue still affecting other archs.

Thanks!

-- 
Samuel Henrique 

Bug#989735: minicom: stack smashing when searching in history buffer

[Adam Lackorzynski]

On Mon Jun 14, 2021 at 10:19:13 +0100, Mike Crowe wrote:
> Hi Adam,
> 
> On Monday 14 June 2021 at 09:16:51 +0200, Adam Lackorzynski wrote:
> > Ok, thanks. Meantime I changed all of this static memory handling to be
> > more dynamic, also addressing this case I believe. The 'magic' constant
> > is gone, so hopefully any of those cases.
> 
> Thanks for the extremely quick fixes. The current state of master
> (b7727586547b4a24939bef4176b8a0d5ad91d62d) seems to work perfectly for me.
> 
> Since this didn't turn out to be a regression, is it safe to assume that
> there's little chance of the fix ending up in Bullseye?

Let's see. I've put all on the v2.8.x branch, being corruption fixes.
Maybe it still works out if an upload is being done timely. ;)


Adam

Bug#989777: Severity: High / Debian 10 & 11 with Kernel 5.10.x-amd64 => Intel AX210 Wifi & Bluetooth not work

[pham...@bluewin.ch]

Hello Andrei,
I must have "my head in the moon" as we say in French :) I did not see the 
download link...
After uninstall of the new "firmware-iwlwifi_20210315-2_all.deb" and 
installation of the old "firmware-iwlwifi_20210208-4_all.deb" the Wifi work 
fine, but the Bluetooth not work, I dont have access to my Bluetooth devices ;-(
Best regards.
Philippe

Bug#989859: ITP: golang-github-weppos-publicsuffix-go -- Domain name parser for Go based on the Public Suffix List.

[Peymaneh Nejad]

Package: wnpp
Severity: wishlist
Owner: Peymaneh Nejad 

* Package name: golang-github-weppos-publicsuffix-go
  Version : 0.15.0-1
  Upstream Author : Simone Carletti
* URL : https://github.com/weppos/publicsuffix-go
* License : Expat
  Programming Lang: Go
  Description : Domain name parser for Go based on the Public Suffix List.

This package is a dependency of github.com/smallstep/zcrypto, which is
a dependency of github.com/smallstep/cli, which is a dependency of the caddy 
webserver

Bug#989858: ITP: golang-github-smallstep-zcrypto -- Liberal Go TLS + X.509 Library for Research

[Peymaneh Nejad]

Package: wnpp
Severity: wishlist
Owner: Peymaneh Nejad 

* Package name: golang-github-smallstep-zcrypto
  Version : 0.0~git20200203.fbc32cf-1
  Upstream Author : Smallstep
* URL : https://github.com/smallstep/zcrypto
* License : ISC and Apache 2.0
  Programming Lang: Go
  Description : Liberal Go TLS + X.509 Library

This package is a dependency of github.com/smallstep/cli, which is a dependency 
of the caddy webserver.

Bug#989857: ITP: step-cli -- toolkit for working with public key infrastructure

[Peymaneh Nejad]

Package: wnpp
Severity: wishlist
Owner: Peymaneh Nejad 

* Package name: step-cli
  Version : 0.15.16 
  Upstream Author : Smallstep
* URL : https://github.com/smallstep/cli
* License : Apache 2.0
  Programming Lang: Go
  Description : toolkit for working with public key infrastructure
  A zero trust swiss army knife for working with X509, OAuth, JWT, OATH OTP, 
etc. 

This package is a dependency of the caddy webserver.

Bug#989855: ntcard FTBFS on 32bit: error: comparison is always true due to limited range of data type

[Adrian Bunk]

Source: ntcard
Version: 1.2.2+dfsg-1
Severity: important
Tags: ftbfs

https://buildd.debian.org/status/package.php?p=ntcard&suite=sid

...
ntcard.cpp: In function ‘int main(int, char**)’:
ntcard.cpp:430:16: error: comparison is always true due to limited range of 
data type [-Werror=type-limits]
  430 |  if (totalSize < 500)
  |  ~~^
...

Bug#989854: unblock: manpages-l10n/4.10.0-1

[Helge Kreutzmann]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: "Dr. Tobias Quathamer" 

Please unblock package manpages-l10n

[ Reason ]
manpages-l10n contains (translated) man pages for > 100 source
packages. Upstream prepared a new version which contained many
updated and improved man page translations. In case a string is
not translated, the current english text is shown (due to po4a).

This package does not contain any binary/programme.

[ Impact ]
Some translations had errors (which have been fixed) and many strings
and man pages are now translated, giving non native users a better
experience when reading (localized) man pages. For example, many more
openssh pages are now available in German.

[ Tests ]
Upstream (I'm part of upstream) runs nightly builds of all man pages
in all languages, checking for (build) errors. Furthermore upstream
regularly reviews (where possible) incoming translations. Also more
users started reporting typos in the recent months (at least for
German).

[ Risks ]
This is a leaf and documentation package, servicing our users speaking
languages different from English.

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

Attached:
debdiff --exclude "upstreambug" --exclude "upstream" --exclude "templates" 
--exclude "po" --exclude copyright --exclude create-authors-file.sh --exclude 
README.md manpages-l10n_4.9.3-4.dsc manpages-l10n_4.10.0-1.dsc

[ Other info ]
Today a problem with the upgrade path for users using buster backports
was discovered (see #989799). We are currently working on the proper
fix. At the moment it looks like the fix will require another upload to
debian backports. If possible, I would like to use 4.10.0-1 to
backport (once accepted in stable) and deploying the fix there,
instead of basing the fix on 4.9.3-3.

Also I did not enable Czech and Danish, since we are in a deep freeze.
Both would introduce new (binary) packages. (Both are new in upstream
in this release).

unblock manpages-l10n/4.10.0-1

-- 
  Dr. Helge Kreutzmann deb...@helgefjell.de
   Dipl.-Phys.   http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
   Help keep free software "libre": http://www.ffii.de/
diff -Nru --exclude upstreambug --exclude upstream --exclude templates 
--exclude po --exclude copyright --exclude create-authors-file.sh --exclude 
README.md manpages-l10n-4.9.3/AUTHORS.md manpages-l10n-4.10.0/AUTHORS.md
--- manpages-l10n-4.9.3/AUTHORS.md  2021-03-09 20:24:24.0 +0100
+++ manpages-l10n-4.10.0/AUTHORS.md 2021-06-13 18:54:49.0 +0200
@@ -7,7 +7,6 @@
 ## Brazilian Portuguese:
 
 * Ademar de Souza Reis Jr. 
-* André L. Fassone Canova 
 * André Luiz Fassone 
 * Antonio Belloni 
 * Carlos Augusto Horylka 
@@ -157,7 +156,6 @@
 * Thierry Vignaud 
 * Thomas Blein 
 * Thomas Huriaux 
-* Thomas Vincent 
 * Thomas Vincent 
 * Valéry Perrin 
 * Yves Rütschlé 
@@ -174,7 +172,6 @@
 * Daniel Kobras 
 * David Thamm 
 * Dennis Stampfer 
-* Dr. Helge Kreutzmann 
 * Dr. Tobias Quathamer 
 * Eduard Bloch 
 * Elmar Jansen 
@@ -231,10 +228,40 @@
 * Wolfgang Jung 
 
 
+## Hungarian:
+
+* Ámon Tamás 
+* Böszörményi Zoltán 
+* Csehi András 
+* Daczi László 
+* Dyekiss Emil 
+* Farkas Zsolt 
+* Fehér -Aries- János 
+* Fejős Tamás 
+* Füley István 
+* Gombai Sándor 
+* Hermann Benedek 
+* Horváth András 
+* Kovács Emese 
+* Kővári Péter 
+* Magyari Miklós 
+* Mező Tamás 
+* Molnár Attila 
+* Nagy Ernő 
+* Nagy Viktor 
+* Németh Péter 
+* Szabó Zsolt 
+* Szalay Attila 
+* Tenkes Csaba 
+* Tevesz Tamás 
+* Tímár András 
+* Váraljai Nándor 
+* Zelena Endre 
+
+
 ## Italian:
 
 * Alessandro Rubini 
-* Antonio Colombo 
 * Antonio Giovanni Colombo 
 * Augusto Lenardi 
 * Beatrice Torracca 
diff -Nru --exclude upstreambug --exclude upstream --exclude templates 
--exclude po --exclude copyright --exclude create-authors-file.sh --exclude 
README.md manpages-l10n-4.9.3/CHANGES.md manpages-l10n-4.10.0/CHANGES.md
--- manpages-l10n-4.9.3/CHANGES.md  2021-03-09 20:24:24.0 +0100
+++ manpages-l10n-4.10.0/CHANGES.md 2021-06-13 18:54:49.0 +0200
@@ -1,5 +1,12 @@
 # Changelog for manpages-l10n
 
+## Version 4.10.0
+*Mon Jun 13 18:49:01 CET 2021*
+
+* Enable Czech and Danish translations
+* Hungarian is still disabled; still not completely imported
+* Updated and added many translations
+
 ## Version 4.9.3
 *Tue Mar  09 20:22:17 CET 2021*
 
diff -Nru --exclude upstreambug --exclude upstream --exclude templates 
--exclude po --exclude copyright --exclude create-authors-file.sh --exclude 
README.md manpages-l10n-4.9.3/configure manpages-l10n-4.10.0/configure
--- manpages-l10n-4.9.3/configure   2021-03-09 20:24:24.0 +0100
+++ manpages-l10n-4.10.0/configure  2021-06-13 18:54:49.0 

Bug#989847: CVE-2021-22212

[Richard Laager]

On 6/14/21 1:59 PM, Moritz Muehlenhoff wrote:

Package: ntpsec
Severity: important
Tags: security
X-Debbugs-Cc: Debian Security Team 

This was assigned CVE-2021-22212:
https://gitlab.com/NTPsec/ntpsec/-/issues/699

Patch:
https://gitlab.com/NTPsec/ntpsec/-/commit/b09be47d650280cc7ebdcd45dfa07eca4b9a52f8

Can you please upload a targeted fix to unstable and ask the release team for an
unblock?


Yes, I will prepare one very soon (tonight or tomorrow).

--
Richard

Bug#989851: pre-approval unblock: uwsgi/2.0.19.1-8

[Thomas Goirand]

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

Dear release team,

The Glance and the Swift packages both use, in some cases, the HTTP
transfer mode:
Transfer-Encoding: chunked

In this mode, no Content-Lenght: header is set, and the client is sending
the data using chunked.

As a result, both Swift and Glance are only partially working. For swift,
the issue happens mostly when someone sends large documents. Upload is
interrupted and breaks. For Glance, it happens when doing a command like
this one:

openstack server image create --name my-name 

Unfortunately, the Uwsgi version 2.0.19, as in Bullseye and Sid, does not
have the feature. The patch was written 4 years ago, but upstream didn't
release a new upstream release containing the patch.

Therefore, I have backported the patch to the version 2.0.19.1 as in
Bullseye (it applied cleanly with only a few fuzz hunks). Please find the
attached debdiff containing the patch I'd like to add.

As this only adds the specific feature, and that it must be activated
using the directive:

wsgi-manage-chunked-input = true

(or with --wsgi-manage-chunked-input on the command line), then I don't
think there's any regression risk for Bullseye. However, this repairs
Glance and Swift, as soon as we add the directive, which Glance and
Swift already have (there will be no need to re-upload Glance or Swift).

Note that I already tested all of this in production, and in fact, I
just would like to apply what I've done in production to what's in Debian
official (rather than having to provide a modified uwsgi in an unofficial
repository).

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

Please allow me to unblock uwsgi/2.0.19.1-8 with the attached patch,
targetting Bullseye,

Cheers,

Thomas Goirand (zigo)
>From 722db2ea22eb454ed678bd6ff8b1c2f287df4802 Mon Sep 17 00:00:00 2001
From: Thomas Goirand 
Date: Fri, 11 Jun 2021 11:09:19 +0200
Subject: [PATCH]   * Add upstream patch to support Transfer-Encoding:
 chuncked, necessary for OpenStack Glance and Swift over uwsgi.

---
 debian/changelog  |   9 +
 .../Add_support_for_chunked_encoding.patch| 241 ++
 debian/patches/series |   1 +
 3 files changed, 251 insertions(+)
 create mode 100644 debian/patches/Add_support_for_chunked_encoding.patch

diff --git a/debian/changelog b/debian/changelog
index 70389417..b0372124 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,12 @@
+uwsgi (2.0.19.1-7.1) UNRELEASED; urgency=medium
+
+  [ Thomas Goirand ]
+  * Non-maintainer upload.
+  * Add upstream patch to support Transfer-Encoding: chuncked, necessary for
+OpenStack Glance and Swift over uwsgi.
+
+ -- Thomas Goirand   Fri, 11 Jun 2021 11:08:33 +0200
+
 uwsgi (2.0.19.1-7) unstable; urgency=medium
 
   * add patch cherry-picked upstream
diff --git a/debian/patches/Add_support_for_chunked_encoding.patch 
b/debian/patches/Add_support_for_chunked_encoding.patch
new file mode 100644
index ..496a1e75
--- /dev/null
+++ b/debian/patches/Add_support_for_chunked_encoding.patch
@@ -0,0 +1,241 @@
+Subject: preliminary implementation of #1428
+ This implements support for transfer-encoding: chuncked
+Author: Unbit 
+Date: Thu, 9 Nov 2017 16:40:44 +0100
+Last-Update: 2021-06-11
+
+Index: uwsgi/core/chunked.c
+===
+--- uwsgi.orig/core/chunked.c
 uwsgi/core/chunked.c
+@@ -83,6 +83,83 @@ static ssize_t uwsgi_chunked_readline(st
+ 
+ */
+ 
++struct uwsgi_buffer *uwsgi_chunked_read_smart(struct wsgi_request *wsgi_req, 
size_t len, int timeout) {
++  // check for buffer
++  if (!wsgi_req->body_chunked_buf)
++  wsgi_req->body_chunked_buf = uwsgi_buffer_new(uwsgi.page_size);
++  // first case: asking for all
++  if (!len) {
++  for(;;) {
++  size_t chunked_len = 0;
++  char *buf = uwsgi_chunked_read(wsgi_req, &chunked_len, 
timeout, 0);
++  if (chunked_len == 0) {
++  struct uwsgi_buffer *ret = 
uwsgi_buffer_new(wsgi_req->body_chunked_buf->pos);
++  if (uwsgi_buffer_append(ret, 
wsgi_req->body_chunked_buf->buf, wsgi_req->body_chunked_buf->pos)) {
++  uwsgi_buffer_destroy(ret);
++  return NULL;
++  }
++  
uwsgi_buffer_decapitate(wsgi_req->body_chunked_buf, 
wsgi_req->body_chunked_buf->pos);
++  return ret;
++  }
++  if (uwsgi_buffer_append(wsgi_req->body_chunked_buf, 
buf, chunked_len)) {
++  return NULL;
++  }
++  }

Bug#989850: ITP: python-flask-talisman -- HTTP security headers for Flask

[Shayan Doust]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: he...@shayandoust.me

Subject: ITP: python-flask-talisman -- HTTP security headers for Flask
Package: wnpp
Owner: Shayan Doust 
Severity: wishlist

* Package name: python-flask-talisman
  Version : 0.7.0
  Upstream Author : Google Inc.
* URL : https://github.com/GoogleCloudPlatform/flask-talisman
* License : Apache-2.0
  Programming Lang: Python
  Description : HTTP security headers for Flask
 Talisman is a small Flask extension that handles setting HTTP
 headers that can help protect against a few common web application
 security measures.

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

Bug#989848: python-urllib3: CVE-2021-33503

[Salvatore Bonaccorso]

Source: python-urllib3
Version: 1.26.4-1
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for python-urllib3.

CVE-2021-33503[0]:
| Catastrophic backtracking in URL authority parser when passed URL
| containing many @ characters

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2021-33503
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-33503
[1] https://github.com/advisories/GHSA-q2q7-5pp4-w6pg
[2] 
https://github.com/urllib3/urllib3/commit/2d4a3fee6de2fa45eb82169361918f759269b4ec

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#989847: CVE-2021-22212

[Moritz Muehlenhoff]

Package: ntpsec
Severity: important
Tags: security
X-Debbugs-Cc: Debian Security Team 

This was assigned CVE-2021-22212:
https://gitlab.com/NTPsec/ntpsec/-/issues/699

Patch:
https://gitlab.com/NTPsec/ntpsec/-/commit/b09be47d650280cc7ebdcd45dfa07eca4b9a52f8

Can you please upload a targeted fix to unstable and ask the release team for an
unblock?

Cheers,
 Moritz

Bug#932996: linux-image-4.19.0-5-amd64: e1000e driver crashes under high TX load; `ethtool -K eno1 tso off` resolves issue.

[Salvatore Bonaccorso]

Source: linux
Source-Version: 5.10.40-1

Hi

On Mon, Jun 14, 2021 at 10:55:08AM -0700, John wrote:
> Hi,
> 
> I've turned TSO back on to test, and I'm currently on 5.10.0-7-amd64 ($
> uname -a -> Linux myrkul 5.10.0-7-amd64 #1 SMP Debian 5.10.40-1
> (2021-05-28) x86_64 GNU/Linux).
> 
> I could not readily reproduce it using a netcat tunnel to push higher load
> from VM to host, or from VM to external networks, so it looks likely that
> something in the last two years cleaned this up. Feel free to close, and I
> can reopen with more details if it comes back.

Thank you for coming back, much appreciated. So I'm closing as per
above with 5.10.41-1 but feel free to reopen if you despite will be
able to reproduce/trigger the issue again.

Regards,
Salvatore

Bug#989846: CVE-2021-22895

[Moritz Muehlenhoff]

Package: nextcloud-desktop
Severity: important
Tags: security
X-Debbugs-Cc: Debian Security Team 

See 
https://github.com/nextcloud/security-advisories/security/advisories/GHSA-qpgp-vf4p-wcw5

Patch:
https://github.com/nextcloud/desktop/commit/b1ddd0e491b2af0ed040e658d8bcde2a7a61c9fc

Can you please upload a targeted fix and ask for an unblock with the release 
team?

Cheers,
 Moritz

Bug#989845: pulseaudio: Needless Depends: on libasound2-plugins should be turned back into Recommends:

[Dennis Filder]

Package: pulseaudio
Version: 14.2-2
Severity: normal
Control: found -1 0.99.1-1
X-Debbugs-CC: d.fil...@web.de

While investigating #963582 I took a closer look at the dependencies
of pulseaudio, and I noticed something odd: As part of the changes for
0.99.1-1 the Recommends: on libasound2-plugins hard-coded in
debian/control was turned into a Depends:.  The commit message in
question[0] just reads: "tweak depends slightly" which is very quaint
considering that the transitive Depends: closure of libasound2-plugins
includes (among others) libavcodec58 and weighs in at a grand total of
200 MB.  The context of the changelog suggests that this was done to
make the package more similar to how Ubuntu packages pulseaudio, and
the maintainer just didn't realize the ramifications.

Considering that this was probably just a mistake and the inordinate
amount of additional disk space usage incurred by it I think this
change should be undone.

Regards,
Dennis Filder

0: 
https://salsa.debian.org/pulseaudio-team/pulseaudio/-/commit/89438173a5e1ad86b28763e28924baceb26b88a6

Bug#988722: postgresql-common: Upgrading cluster with postgis does not migrate tables using postgis

[Gilles Filippini]

Hi Andreas,

Andreas Beckmann a écrit le 14/06/2021 à 10:18 :

On 08/06/2021 13.05, Sebastian Ramacher wrote:

Here it is. Now testing upgrades ...
There were some new symbols ... but they appeared independently of my
changes (I built in bullseye, not sid, in case it does matter).


Tests have not shown any problems. And in combination with patched gdal 
and friends we have achieved co-installability ;-)


This is good news. Thanks for this work.


Thanks Andreas! Once that tests are done and the packages was uploaded,
please let me know so that I can add the appropriate hints on the
release team side.

FWIW, the symbol is a template instantiation of a function from the
standard library and should be marked as optional.


Attached is a new version of the patch. Some wording was tweaked and 
'optional' added.


The new packages are still available as cruft in sid, so we should be 
able to avoid NEW.


Gilles, do you want to do the upload or shall I NMU it?


I'll try to upload this evening.

I'll now reupload libaec with the recently added Breaks dropped, since 
they are no longer needed ;-)


Thanks again!

_g.

Bug#989844: Cross-compilation support (please package more libstd-rust-dev-*)

[Matt Corallo]

Package: src:rustc
Version: 1.48.0+dfsg1-2

It would be nice to support cross-compilation in the Debian rustc builds, both across-platforms targeting linux and for 
additional targets in the host platform (eg apple-darwin, assuming its possible to build std without the proprietary 
apple sysroot), or freebsd/android/etc. I assume the biggest requirement there is just packaging the libstd.

Bug#979665: Please package libstd-rust-dev-emscripten

[Matt Corallo]

This is no longer the case. As of https://github.com/rust-lang/rust/pull/79998 (rustc 1.51) you can now link C and rust 
code with the wasm32-wasi target.


On 1/9/21 16:16, Matt Corallo wrote:

Package: src:rustc
Version: 1.48.0+dfsg1-2

Due to issues with the way rustc interacts with LLVM-wasm [1], building rust packages with 
--target=wasm-unknown-{wasi,unknown} is not practical if any C code is to be used in the same binary (which is common). 
Instead, wasm-unknown-emscripten is the only option, however not librust-std is packaged for emscripten. rustup's 
emscripten is broken on debian testing due to them shipping their own LLVM, so that is also not a practical solution for 
most users wishing to link C and rust code in any context, let alone WASM.



[1] https://github.com/rustwasm/team/issues/291

Bug#989842: RFA: alttab -- task switcher for minimalistic WMs or standalone X session

[Alexander Kulak]

Package: wnpp
Severity: normal
Control: affects -1 src:alttab

Please adopt the alttab package, which I have difficulties to maintain.
The program is trivial to build and has a test suite.
I'm the upstream author.
Currently it's marked AUTORM, and bug-fixing release is packaged:
https://mentors.debian.net/package/alttab/

Bug#989840: patch

[dann frazier]

tags 989840 + patch
thx
diff -Nru nvme-cli-1.12/debian/changelog nvme-cli-1.12/debian/changelog
--- nvme-cli-1.12/debian/changelog  2020-09-22 19:37:51.0 +
+++ nvme-cli-1.12/debian/changelog  2021-06-14 17:50:30.0 +
@@ -1,3 +1,10 @@
+nvme-cli (1.12-5+deb11u1) UNRELEASED; urgency=medium
+
+  * Fix issue where 'showregs' can cause certain Samsung devices
+to go offline. (Closes: #989840)
+
+ -- dann frazier   Mon, 14 Jun 2021 11:50:30 -0600
+
 nvme-cli (1.12-5) unstable; urgency=medium
 
   * Add uuid-runtime as dependency. (Closes: #970637)
diff -Nru 
nvme-cli-1.12/debian/patches/Prevent-compiler-from-optimizing-mmio_read64-to-sing.patch
 
nvme-cli-1.12/debian/patches/Prevent-compiler-from-optimizing-mmio_read64-to-sing.patch
--- 
nvme-cli-1.12/debian/patches/Prevent-compiler-from-optimizing-mmio_read64-to-sing.patch
 1970-01-01 00:00:00.0 +
+++ 
nvme-cli-1.12/debian/patches/Prevent-compiler-from-optimizing-mmio_read64-to-sing.patch
 2021-06-14 16:51:31.0 +
@@ -0,0 +1,34 @@
+From 33e60ff64a043b189d2661543b417b21b6f3667b Mon Sep 17 00:00:00 2001
+From: Adam Judge 
+Date: Tue, 9 Jun 2020 15:58:49 -0400
+Subject: [PATCH] Prevent compiler from optimizing mmio_read64 to single 64b
+ read
+
+Bug-Debian: https://bugs.debian.org/989840
+Bug-Ubuntu: https://bugs.launchpad.net/bugs/1931886
+Origin: 
https://github.com/linux-nvme/nvme-cli/commit/33e60ff64a043b189d2661543b417b21b6f3667b
+Last-Updated: 2021-06-14
+
+diff --git a/nvme-print.c b/nvme-print.c
+index fc8f99d..c0de928 100644
+--- a/nvme-print.c
 b/nvme-print.c
+@@ -1311,9 +1311,13 @@ static inline uint32_t mmio_read32(void *addr)
+ /* Access 64-bit registers as 2 32-bit; Some devices fail 64-bit MMIO. */
+ static inline __u64 mmio_read64(void *addr)
+ {
+-  __le32 *p = addr;
++  const volatile __u32 *p = addr;
++  __u32 low, high;
++
++  low = le32_to_cpu(*p);
++  high = le32_to_cpu(*(p + 1));
+ 
+-  return le32_to_cpu(*p) | ((uint64_t)le32_to_cpu(*(p + 1)) << 32);
++  return ((__u64) high << 32) | low;
+ }
+ 
+ static void json_ctrl_registers(void *bar)
+-- 
+2.32.0
+
diff -Nru 
nvme-cli-1.12/debian/patches/nvme-print-split-pmrmsc-into-pmrmscl-and-pmrmscu.patch
 
nvme-cli-1.12/debian/patches/nvme-print-split-pmrmsc-into-pmrmscl-and-pmrmscu.patch
--- 
nvme-cli-1.12/debian/patches/nvme-print-split-pmrmsc-into-pmrmscl-and-pmrmscu.patch
 1970-01-01 00:00:00.0 +
+++ 
nvme-cli-1.12/debian/patches/nvme-print-split-pmrmsc-into-pmrmscl-and-pmrmscu.patch
 2021-06-14 16:52:09.0 +
@@ -0,0 +1,139 @@
+From d43d545a68cc6cea5ac78fda4edeedf3b5198847 Mon Sep 17 00:00:00 2001
+From: Gollu Appalanaidu 
+Date: Sat, 27 Feb 2021 01:23:44 +0530
+Subject: [PATCH] nvme-print: split pmrmsc into pmrmscl and pmrmscu
+
+Split the PMR Memory Space Control register 64 bits into
+PMR Memory Space Control Lower and Upper 32 bits each as
+per NVM Express Spec. 1.4b changes.
+
+Signed-off-by: Gollu Appalanaidu 
+[dannf: Backported to 1.12]
+
+Bug-Debian: https://bugs.debian.org/989840
+Bug-Ubuntu: https://bugs.launchpad.net/bugs/1931886
+Origin: 
https://github.com/linux-nvme/nvme-cli/commit/d43d545a68cc6cea5ac78fda4edeedf3b5198847
+Last-Updated: 2021-06-14
+
+Index: nvme-cli-1.12/linux/nvme.h
+===
+--- nvme-cli-1.12.orig/linux/nvme.h
 nvme-cli-1.12/linux/nvme.h
+@@ -172,7 +172,8 @@ enum {
+   NVME_REG_PMRSTS = 0x0e08,   /* Persistent Memory Region Status */
+   NVME_REG_PMREBS = 0x0e0c,   /* Persistent Memory Region Elasticity 
Buffer Size */
+   NVME_REG_PMRSWTP= 0x0e10,   /* Persistent Memory Region Sustained 
Write Throughput */
+-  NVME_REG_PMRMSC = 0x0e14,   /* Persistent Memory Region Controller 
Memory Space Control */
++  NVME_REG_PMRMSCL= 0x0e14,   /* Persistent Memory Region Controller 
Memory Space Control Lower */
++  NVME_REG_PMRMSCU= 0x0e18,   /* Persistent Memory Region Controller 
Memory Space Control Upper*/
+   NVME_REG_DBS= 0x1000,   /* SQ 0 Tail Doorbell */
+ };
+ 
+Index: nvme-cli-1.12/nvme-print.c
+===
+--- nvme-cli-1.12.orig/nvme-print.c
 nvme-cli-1.12/nvme-print.c
+@@ -1293,12 +1293,18 @@ static void nvme_show_registers_pmrswtp(
+   nvme_register_pmr_pmrszu_to_string(pmrswtp & 0x000f));
+ }
+ 
+-static void nvme_show_registers_pmrmsc(uint64_t pmrmsc)
++static void nvme_show_registers_pmrmscl(uint32_t pmrmscl)
+ {
+-  printf("\tController Base Address (CBA) : %" PRIx64 "\n",
+-  (pmrmsc & 0xf000) >> 12);
+-  printf("\tController Memory Space Enable (CMSE) : %" PRIx64 "\n\n",
+-  (pmrmsc & 0x0002) >> 1);
++  printf("\tController Base Address (CBA): %#x\n",
++  (pmrmscl & 0xf000) >> 12);
++  printf("\tController Memory Space Enable (CMSE): %#x\n\n

Bug#932996: linux-image-4.19.0-5-amd64: e1000e driver crashes under high TX load; `ethtool -K eno1 tso off` resolves issue.

[John]

Hi,

I've turned TSO back on to test, and I'm currently on 5.10.0-7-amd64 ($
uname -a -> Linux myrkul 5.10.0-7-amd64 #1 SMP Debian 5.10.40-1
(2021-05-28) x86_64 GNU/Linux).

I could not readily reproduce it using a netcat tunnel to push higher load
from VM to host, or from VM to external networks, so it looks likely that
something in the last two years cleaned this up. Feel free to close, and I
can reopen with more details if it comes back.

Thanks!
- John

On Sun, Jun 13, 2021 at 12:11 PM Salvatore Bonaccorso 
wrote:

> Control: tags -1 + moreinfo
>
> On Thu, Jul 25, 2019 at 09:58:33AM -0700, John wrote:
> > Package: src:linux
> > Version: 4.19.37-6
> > Severity: normal
> >
> > Dear Maintainer,
> >
> > Observed flaky network interface under high TX load with guest OS
> > bridging across eno1 interface. Issue only manifested under load, and
> > exhibited flapping in dmesg, e.g.:
> > e1000e :00:1f.6 eno1: Reset adapter unexpectedly
> > br0: port 1(eno1) entered disabled state).
> >
> > Issue appears to be resolved by disabling TSO with:
> > `ethtool -K eno1 tso off`
> >
> > Googling around suggests this may be a common problem with this driver
> > -- possibly should default to tso off? See possibly related links:
> > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1766377
> >
> https://serverfault.com/questions/616485/e1000e-reset-adapter-unexpectedly-detected-hardware-unit-hang
>
> Is this issue still triggerable for you with a recent kernel from
> either unstable, buster-backports or even mainline without needing to
> set tso off?
>
> Regards,
> Salvatore
>

Bug#989777: Severity: High / Debian 10 & 11 with Kernel 5.10.x-amd64 => Intel AX210 Wifi & Bluetooth not work

[Andrei POPESCU]

On Lu, 14 iun 21, 17:51:35, pham...@bluewin.ch wrote:
> Hello Vincent,
> And thank you for your message.
> I just tested the two new live images:
> - debian-live-blsy-DI-rc2-amd64-cinnamon+nonfree.iso  2021-06-11 
> 18:133.2G
> - debian-live-testing-amd64-cinnamon+nonfree.iso  2021-06-14 
> 07:553.2G
> Both work with firmware iwlwifi_20210315-2 so they don't work on my system.
> I don't know where to find a version of Debian 11 live including the old 
> firmware_iwlwifi 20210208-4 you are telling me about.
> I would like to do a test for you if you provide me with a download URL of a 
> live version of Debian 11 equipped with this firmware_iwlwifi 20210208-4. 
> Also note that I can't seem to find a download link for 
> firmware_iwlwifi_20210208-4.deb alone.
> Meilleures salutations / Best regards.
> Philippe

Hello Philippe,

(not the maintainer, but maybe I can still assist)

The link to the .deb package was provided in Vincent's message, I'll 
include it again here:

https://snapshot.debian.org/archive/debian/20210313T203823Z/pool/non-free/f/firmware-nonfree/firmware-iwlwifi_20210208-4_all.deb

This is a direct download link, your browser should offer to save the 
file. Copy it to a USB stick and insert it during the installation.

In case the installer doesn't ask at all (because it already found a 
firmware) it is possible to install it manually via the console, or just 
use a regular image (without firmware included).

If you need any help with this feel free to contact one of Debian's 
support channels:

https://www.debian.org/support

Hope this helps,
Andrei
-- 
Looking after bugs assigned to unknown or inexistent packages


signature.asc
Description: PGP signature

Bug#976796: Sporadically fails to create virtualenv with Python 3.9

[Daniel Roschka]

On Mon, 14 Jun 2021 09:35:16 -0400 Stefano Rivera  wrote:
> I wish I was able to reproduce this. Is there any chance you can
> reproduce it in a VM or controlled environment that I can try to
> recreate?
> 
> It shouldn't matter, but what filesystem is this on?

I'm running this on btrfs.

I tried reproducing this issue in a VM as suggested. While I had no success 
reproducing it there at first, I noted a directory ~/.local/share/virtualenv 
mentioned in the output of a succeeding command which got me curious. After 
digging through the contents of this folder on my local machine I figured out 
the condition which triggers this bug. Turns out there is a file ~/.local/
share/virtualenv/wheel/3.9/embed/1/setuptools.json with the following content:

{
  "completed": "2021-05-17T17:34:03.491147Z",
  "periodic": true,
  "started": "2021-05-17T17:33:59.488436Z",
  "versions": [
{
  "filename": "setuptools-56.2.0-py3-none-any.whl",
  "found_date": "2021-05-17T17:33:59.597757Z",
  "release_date": "2021-05-09T17:40:49.00Z"
},
{
  "filename": "setuptools-56.1.0-py3-none-any.whl",
  "found_date": "2021-05-17T17:34:01.067885Z",
  "release_date": "2021-05-04T21:35:13.00Z"
},
{
  "filename": "setuptools-56.0.0-py3-none-any.whl",
  "found_date": "2021-05-17T17:34:02.299115Z",
  "release_date": "2021-04-09T00:24:04.00Z"
}
  ]
}

Removing this file causes this problem to go away!

This also works the other way around: Copying this file to the same location on 
the VM and also copying the setuptools-*.whl files mentioned in there to 
~/.local/share/virtualenv/wheel/house/ makes the problem reproducible on the 
VM as well. It's way less frequent there and happens in way less than 10% of 
the times, but with a little while loop it's easily reproducible this way as 
well.

I hope this helps. If you need any more information, please just drop me a 
note.

Daniel

Bug#986117: take ownership and mark as pending

[Pirate Praveen]

On Tue, 1 Jun 2021 16:41:51 +0200 Paolo Greppi  
wrote:

> owner 986117 Paolo Greppi 
> tag 986117 pending

Hi Paolo,

Can you upload it?

Thanks
Praveen

Bug#989839: thunderbird: Gmail imap authentication error

[Kevin Locke]

On Mon, 2021-06-14 at 17:40 +0200, Benjamin Bänziger wrote:
> Package: thunderbird
> Version: 1:78.11.0-1
> Severity: important
> 
> Dear Maintainer,
> 
> Since todays update, thunderbird doesn't connect with gmail imap server
> anymore;
> "Authenticcation failure while connecting to server imap.gmail.com"
> 
> Also creating a new account for gmail doesn't work:
> "Thunderbird failed to find the settings for your email account"

I encountered the same error after upgrading from 1:78.10.0-1 to
1:78.11.0-1 for every account using IMAP with TLS.  It also manifests as
"Failed to connect to server ${SERVER}" with network.trr.mode=3.  I
believe something is wrong with TLS in 1:78.11.0-1.  An easy way to
reproduce (optionally in a new profile with no accounts configured):

1. Click "Add-ons" from the menu.
2. Click the "Find More Addons" button at the bottom of the
   "Recommendations" tab.
3. Observe https://addons.thunderbird.net/en-US/thunderbird/ is opened
   in a new tab with Error code: NS_ERROR_NET_INADEQUATE_SECURITY.

These steps correctly show the Thunderbird Add-ons page with thunderbird
78.10.2-1 and below.  The "Authentication failure" messages also do not
occur for me after downgrading thunderbird to 78.10.2-1.

Thanks,
Kevin

Bug#989822: desktop-base: Debian 10 images still in 11 package

[Aurélien COUDERC]

control: severity -1 normal

Hi,

Le 14 juin 2021 16:03:27 GMT+02:00, Cyril Brulebois  a écrit :
>Philip Wyett  (2021-06-14):
>> Package: desktop-base
>> Version: 11.0.3
>> Severity: important
>> 
>> moonlight-theme still contains Debian 10 specific images.

>
>It contains much more than that, it even contains spacefun files! I'm
>not sure that's a bug though. If the default files were not to point to
>the Debian 11 theme, that'd be another story.

The bug is that the images still contains the « Debian 10 » text and not Debian 
11.

I can/will fix that but a MR would be welcome too, it's SVG so it should be a 
one liner per sgv file doable with a simple text editor. :-)


Cheers,
--
Aurélien

Bug#989322: Patch

[Eric Dorland]

FYI https://salsa.debian.org/debian/borgmatic/-/merge_requests/3

-- 
Eric Dorland 
43CF 1228 F726 FD5B 474C  E962 C256 FBD5 0022 1E93

Bug#969907: inkscape, etc. crashing with mismatched libpoppler102 and libpoppler-glib8

[Mattia Rizzolo]

On Sun, Jun 13, 2021 at 05:14:31PM +0200, Francesco Poli wrote:
> Hello,
> is there any progress on this [bug]?

I kinda lost track of it after I handled it in inkscape (since it's not
effectively out of my concerns).

Are there any other affected packages?  If so, they probably ought to
tighten their dependencies.

(though I still think poppler should do something to fix this issue, but
as Ivo said, it's too late for bullseye).

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#988512: CAcert class 3 validates

[Timo Röhling]

Hi,
just adding my two cents here: the new class3.crt does verify
against the already packaged Class 1 Root. To wit:

$ openssl verify -show_chain -CAfile /usr/share/ca-certificates/CAcert/root_X0F.crt class3.crt 
class3.crt: OK

Chain:
depth=0: O = CAcert Inc., OU = http://www.CAcert.org, CN = CAcert Class 3 Root 
(untrusted)
depth=1: O = Root CA, OU = http://www.cacert.org, CN = CA Cert Signing 
Authority, emailAddress = supp...@cacert.org


Is there any other reason why the intermediate certificate should not be
replaced immediately?

Cheers
Timo

--
⢀⣴⠾⠻⢶⣦⠀   ╭╮
⣾⠁⢠⠒⠀⣿⡁   │ Timo Röhling   │
⢿⡄⠘⠷⠚⠋⠀   │ 9B03 EBB9 8300 DF97 C2B1  23BF CC8C 6BDD 1403 F4CA │
⠈⠳⣄   ╰╯


signature.asc
Description: PGP signature

Bug#989800: [Pkg-utopia-maintainers] Bug#989800: pipewire-pulse: is /var/run/pulse/native gone?

[Patrice Duroux]

Sure you are right!
As sound is working with some the apps (probably the ones using gstreamer) but
not the sound preference of GNOME control center, I was focused on any
hypothetical change in the PulseAudio server of PipeWire.
But then it may probably due to the upgrade of GNOME control center to 1:40.0-1
that happened the same day on my system.
I'm gonna try some downshift. 
:-/

Bug#989821: RFS: elementary-terminal/5.5.2-1~exp1 [ITP] -- Modern terminal from elementary project

[Francisco M Neto]

Hello!

On 2021-06-14 14:45, Adam Borowski wrote:
> Is there a reason you left the executable named "io.elementary.terminal"?
> The website — nor its reverse — is not relevant to a user; people instead
> expect the principal executable to be named same as the package — and also,
> our convention is to name terminals "${FOO}-terminal".

I went the other way, actually. At first I noticed the weird
executable name and wondered if I should rename it; but that would imply
making changes to the source (with possible unforseen consequences).
After asking in #debian-mentors I decided it was not worth the troulble.

> (On the other hand, if you strongly insist on keeping that Javaesque name,
> this is not a blocker, I'll just whine and upload.)

I'm not married to that solution. If you think it's better to follow
the convention I'm okay with it. I'll make the necessary changes :)

> Most of translation .po files are empty — is there any reason to ship them?
> (But this can be considered an upstream bug.)

That's pretty much what I figured. I didn't want to change the
upstream source so i just left those there. As for the "mo" locale, I've
notified them about it - it seems to be a generalized problem so I
wasn't sure where to file a bug report.

I haven't received an answer from them, though, so I'm thinking I
might just file a bug report on each package and move on.

> Package description: "originalle" should be translated to English.  (Such
> pointless mixing of languages would postpone world domination of English
> ad calendas graecas ☺.)

That wasn't actually a translation; it was a typo... :P

But thanks for pointing it out, I've corrected it.

> --
> ⢀⣴⠾⠻⢶⣦⠀ What Would Jesus Do, MUD/MMORPG edition:
> ⣾⠁⢠⠒⠀⣿⡁ • multiplay with an admin char to benefit own mortal [Mt3:16-17]
> ⢿⡄⠘⠷⠚⠋⠀ • abuse item cloning bugs [Mt14:17-20, Mt15:34-37]
> ⠈⠳⣄ • use glitches to walk on water [Mt14:25-26]
>

I loved that swirl! I've been looking for one for some time. Mind if I
"steal" it from you?

--
[]'s
|
Francisco M Neto|
 | 3E58 1655 9A3D 5D78 9F90
| CFF1 D30B 1694 D692 FBF0


signature.asc
Description: PGP signature

Bug#980466: cervisia: missing dependency on kinit package

[Hideki Yamane]

control: tags -1 +confirmed +patch

Hi,

 I'd prepare tiny patch for this issue as below.



diff --git a/debian/changelog b/debian/changelog
index cbd284c..7fde2e5 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+cervisia (4:20.12.0-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix dependency to exec without whole KDE environment (Closes: #980466)
+
+ -- Hideki Yamane   Tue, 15 Jun 2021 01:08:14 +0900
+
 cervisia (4:20.12.0-1) unstable; urgency=medium
 
   * Team upload.
diff --git a/debian/control b/debian/control
index 44c6731..9da63c4 100644
--- a/debian/control
+++ b/debian/control
@@ -29,7 +29,8 @@ Rules-Requires-Root: no
 Package: cervisia
 Architecture: any
 Section: devel
-Depends: cvsservice (= ${binary:Version}), ${misc:Depends}, ${shlibs:Depends}
+Depends: cvsservice (= ${binary:Version}), ${misc:Depends}, ${shlibs:Depends},
+ kinit,
 Suggests: khelpcenter
 Description: graphical CVS client
  Cervisia is a front-end for the CVS version control system client.

Bug#989799: psmisc: Undeclared file conflict with manpages-de from buster-backports

[Helge Kreutzmann]

Hello Axel,
hello Craig,
On Mon, Jun 14, 2021 at 12:19:17PM +0200, Axel Beckert wrote:
> Craig Small wrote:
> > reassign -1 manpages-de
> 
> Might be the right place indeed, but maybe not in the way you'd
> expect. See below.

Ack. And thank you very much for your analysis and suggestions.

> > > JFTR: What came to me after sending that mail and what I didn't check
> > > so far, is if 4.9.3-4 is fine, but 4.9.3-4~bpo10+1 has those files.
> > >
> > > Actually in that case, I have no idea how the Breaks/Replaces headers
> > > and the maintainer scripts need to look like.
> > 
> > $ debdiff manpages-de_4.9.3-4_all.deb manpages-de_4.9.3-4_bpo10+1_all.deb |
> > head
> > [The following lists of changes regard files as different if they have
> > different names, permissions or owners.]
> > 
> > Files in second .deb but not in first
> > -
> > -rw-r--r--  root/root   /usr/share/man/de/man1/fuser.1.gz
> > -rw-r--r--  root/root   /usr/share/man/de/man1/killall.1.gz
> > -rw-r--r--  root/root   /usr/share/man/de/man1/lzmainfo.1.gz
> > -rw-r--r--  root/root   /usr/share/man/de/man1/peekfd.1.gz
> > -rw-r--r--  root/root   /usr/share/man/de/man1/prtstat.1.gz
> > 
> > There's about 20 "new" files and 20 removed files.
> > 
> > For some reason, the backport version included files that clash with the
> > procps and psmisc packages. The sid version on 4.9.3-4 doesn't have those
> > conflicting files.
> 
> This actually makes sense, because the backports version is targetted
> for buster with psmisc/procps package versions which don't/still have
> them. So the exclude/include list the buster-backports package is more
> similar to the buster package than the bullseye package — just the
> contents of the manpages is as up to date as the bullseye package.
> 
> From that point of view, this is _not_ a bug in the manpages-de
> package in buster-backports. (But it still might be the best option to
> fix it in there.)
> 
> Then again, dist-upgrades from buster with to bullseye should work
> smoothly like without backports and it seems to be that the main
> burden to make this sure lays in the backports-packages.
> 
> I though still think that this is a serious (sic!) issue and it should
> be fixed.
> 
> Here's my analysis of the potential solutions I see:
> 
> 1) If that Breaks/Replaces headers in psmisc (and probably procps)
>would be bumped to "<< 4.9.3-4" it would also match the manpages-de
>backports package, but then again, this would also match other
>non-backports manpages-de package versions inbetween which don't
>have these files. And I fear this would have any unwanted (and
>potentially also RC-level) side effects. :-/

I see. But if we decide on the final version for unstable and
backports, this should work, shouldn't it?

> 2) So I wonder if the buster-backports package of manpages-de could
>conflict with the psmisc and procps package in bullseye(*)? This
>should probably take care that it is upgraded before procps and
>psmisc are upgraded and hopefully solves the issue without too many
>side-effects.
> 
>(I'm not sure if Breaks/Replaces with ">>" or ">=" really work as
>expected. I've never seen that in use anywhere before. Taking
>Guillem into Cc so maybe he can tell something about if Conflicts
>or Breaks/Replaces are the better choice here.)
> 
>I only see these hopefully only minor disadvantages of that latter
>solution:
> 
>* Users need to have uptodate buster-backports package, i.e.
>  4.9.3-4~bpo10+2. If they don't upgrade to 4.9.3-4~bpo10+2 before
>  dist-upgrading and then upgrade with 4.9.3-4~bpo10+1 still being
>  installed, they will run into this issue again. Might be
>  something for the Release Notes.

I always remember that your system has to be up-to-date before the
dist-upgrade and extra care was necessary for users of backports.
Hence I would think this is reasonable.

>* I'm not sure if apt gets confused while trying to find a good
>  order for dist-upgrading if the Conflicts/Breaks/Replaces is in
>  the old package and not the to-be-upgraded-to one. I hopefully
>  think that this is no issue, but I'm Cc'ing the APT team for
>  input on that to be on the safe side.

If (and relly if) this works, then from a maintainers POV this would
be the nicest solution. 

> 3) Only ship manpages in manpages-de in buster-backports which are in
>psmisc/procps neither in buster nor in bullseye. I assume this is
>the solution, Craig had in mind when reassigning the bug report.
> 
>IMHO this is also a viable solution if variant 2) has too many side
>effects as it IMHO only has a minor impact on the usability of the
>manpages-de package in buster-backports. 

But this would partially defeat the purpose of the backport, to
provide localized man pages where upstream did not.

So from a maintainer POV I would prefer either solution 1) or 2). And
as this situation will c

Bug#989799: psmisc: Undeclared file conflict with manpages-de from buster-backports

[Helge Kreutzmann]

Hello Craig,
On Mon, Jun 14, 2021 at 06:35:19PM +1000, Craig Small wrote:
> On Mon, 14 Jun 2021 at 18:04, Axel Beckert  wrote:
> 
> > JFTR: What came to me after sending that mail and what I didn't check
> > so far, is if 4.9.3-4 is fine, but 4.9.3-4~bpo10+1 has those files.
> >
> > Actually in that case, I have no idea how the Breaks/Replaces headers
> > and the maintainer scripts need to look like.
> >
> 
> $ debdiff manpages-de_4.9.3-4_all.deb manpages-de_4.9.3-4_bpo10+1_all.deb |
> head
> [The following lists of changes regard files as different if they have
> different names, permissions or owners.]
> 
> Files in second .deb but not in first
> -
> -rw-r--r--  root/root   /usr/share/man/de/man1/fuser.1.gz
> -rw-r--r--  root/root   /usr/share/man/de/man1/killall.1.gz
> -rw-r--r--  root/root   /usr/share/man/de/man1/lzmainfo.1.gz
> -rw-r--r--  root/root   /usr/share/man/de/man1/peekfd.1.gz
> -rw-r--r--  root/root   /usr/share/man/de/man1/prtstat.1.gz
> 
> There's about 20 "new" files and 20 removed files.
> 
> For some reason, the backport version included files that clash with the
> procps and psmisc packages. The sid version on 4.9.3-4 doesn't have those
> conflicting files.

That is on purpose. manpages-l10n has various flavours, one is
tracking unstable, another one is tracking Buster (currently).
Additionally, when translations are moving upstream, they get
(manually, if needed be) removed from the version for unstable.

So two cases may occur:
1. The translation status is different for unstable and buster. Then
the localized man page may appear only in either unstable or buster.

2. Due to the moving of translations to upstream package, the
translation may be contained in buster (where upstream did not contain
the translation) and not in unstable (where upstream contains the
translation and so its no longer present in manpages-l10n).

Greetings

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


signature.asc
Description: PGP signature

Bug#989819: RFS: elementary-theme/5.4.2-1~exp1 [ITP] -- GTK stylesheet from elementary OS and Pantheon

[Francisco M Neto]

Hello!

On 2021-06-14 15:09, Adam Borowski wrote:
> There's a license mix-up:
>   1  *No copyright* GNU General Public License
>  54  *No copyright* UNKNOWN
>   3  GNU General Public License v2.0 or later
>   9  GNU General Public License v3.0 or later
>   1  GNU Lesser General Public License v2.1 or later
>   7  UNKNOWN
>
> Even though all of these resolve to GPL3+ for the package as a whole,
> our ftpmammals¹ demand every license to be listed in the copyright file.

I can relate to that :)

> The affected files are:
> * GPL2+: elementary/gtk-3.0/{apps,granite-widgets.dark,granite-widgets}.css
> * LGPL2.1+: elementary/gtk-2.0/gtkrc

Okay these are dealt with. What about those files that nave "No
Copyright" or are listed as "UNKNOWN"?
I couldn't find anything on the Policy or on the Dev Reference that
could give me a solution for that :(

Cheers!
--
[]'s
|
Francisco M Neto|
 | 3E58 1655 9A3D 5D78 9F90
| CFF1 D30B 1694 D692 FBF0


signature.asc
Description: PGP signature

Bug#989799: psmisc: Undeclared file conflict with manpages-de from buster-backports

[Helge Kreutzmann]

Hello Craig,
On Mon, Jun 14, 2021 at 11:41:56AM +1000, Craig Small wrote:
> On Mon, 14 Jun 2021 at 00:03, Axel Beckert  wrote:
> 
> > So the Breaks and Replaces headers (c.f. #982059) should likely be
> > against "<< 4.9.3-4", not just against "<< 4.9.1-1".
> >
> 
> It looks like both the psmisc and procps manpages came back from the dead.
> They were removed in manpages-de 4.9.1-1 and all was good but then they
> came back in 4.9.3
> Helge, the package maintainer for manpages-l10n, then removed them at
> 4.9.3-4.

Yes, I did a packaging error back then, which was fixed in -4.

> 
> Is that how you see it Helge? I can re-release procps and psmisc with the
> updated breaks/replaces but just making sure I hit the right version.
> I agree with Axel, it looks like 4.9.3-4 is the right one to aim for now.
> I assume that the just imported 4.10.0 won't have these files (again).

Correct. The only change is the updated set of translations (at least
in de). The "removal" is unchanged.

Best greetings

 Helge

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


signature.asc
Description: PGP signature

Bug#989785: devscripts: wrap-and-sort ignores --trailing-comma on non-sorted fields/Uploaders

[Mattia Rizzolo]

Control: tag -1 moreinfo unreproducible

On Sun, Jun 13, 2021 at 09:44:07AM +0900, Norbert Preining wrote:
> wrap-and-sort behaves strangly with some fields like Uploaders, where it
> does not honor
>   --trailing-comma
> I guess it comes from the fact that the --trailing-comma applies only to
> "sorted fields" and uploaders seems not to fall into that category.
> 
> This is counter-intuitive, and I suggest adding uploaders into the
> sorted category, or at least honor --trailing-comma there, too.

I'm confued, as here it seems to work just fine.
Using a rendom package:

mattia@warren ..enkins-job-builder/jenkins-job-builder (git)-[debian/unstable] 
% head -n 5 debian/control
Source: jenkins-job-builder
Section: python
Priority: optional
Maintainer: Debian OpenStack 
Uploaders: Thomas Goirand , Mattia Rizzolo 
, Paul Belanger 
mattia@warren ..enkins-job-builder/jenkins-job-builder (git)-[debian/unstable] 
% \wrap-and-sort -t
mattia@warren ..enkins-job-builder/jenkins-job-builder (git)-[debian/unstable] 
% head debian/control
Source: jenkins-job-builder
Section: python
Priority: optional
Maintainer: Debian OpenStack 
Uploaders: Thomas Goirand ,
   Mattia Rizzolo ,
   Paul Belanger ,
Build-Depends: debhelper (>= 12.8~),
   debhelper-compat (= 13),
   dh-python,
mattia@warren ..enkins-job-builder/jenkins-job-builder (git)-[debian/unstable] 
% \wrap-and-sort -st
mattia@warren ..enkins-job-builder/jenkins-job-builder (git)-[debian/unstable] 
% head debian/control
Source: jenkins-job-builder
Section: python
Priority: optional
Maintainer: Debian OpenStack 
Uploaders:
 Thomas Goirand ,
 Mattia Rizzolo ,
 Paul Belanger ,
Build-Depends:
 debhelper (>= 12.8~),
mattia@warren ..enkins-job-builder/jenkins-job-builder (git)-[debian/unstable] %



Can you describe with an example or something more specific what you are
observing?

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#989777: Severity: High / Debian 10 & 11 with Kernel 5.10.x-amd64 => Intel AX210 Wifi & Bluetooth not work

[pham...@bluewin.ch]

Hello Vincent,
And thank you for your message.
I just tested the two new live images:
- debian-live-blsy-DI-rc2-amd64-cinnamon+nonfree.iso2021-06-11 
18:133.2G
- debian-live-testing-amd64-cinnamon+nonfree.iso2021-06-14 
07:553.2G
Both work with firmware iwlwifi_20210315-2 so they don't work on my system.
I don't know where to find a version of Debian 11 live including the old 
firmware_iwlwifi 20210208-4 you are telling me about.
I would like to do a test for you if you provide me with a download URL of a 
live version of Debian 11 equipped with this firmware_iwlwifi 20210208-4. 
Also note that I can't seem to find a download link for 
firmware_iwlwifi_20210208-4.deb alone.
Meilleures salutations / Best regards.
Philippe

Bug#989829: pgadmin4-desktop: missing starting binary

[Peter Gervai]

Package: pgadmin4-desktop
Version: 5.3
Severity: wishlist

Th desktop version does not have a startable binary in /usr/bin/, only a 
desktop file.
There should be at least a symlink to make it startabe from console.

Bug#932501: problem still present in 0.8.15

[Hideki Yamane]

On Tue, 13 Apr 2021 20:13:59 +0200 =?UTF-8?B?SsOpcsOpbXkgVmnDqHM=?= 
 wrote:
> Just to confirm the issue is still present in bullseye current release.
> I had to add the following lines to apparmor configuration to make it work.
> 
>   /etc/squid-deb-proxy/** r,
>   /var/log/squid-deb-proxy/* rw,
>   /run/squid-deb-proxy.pid rwk,
>   /var/cache/squid-deb-proxy/** rw,

 Thank you, put it to debdiff now.


diff -Nru squid-deb-proxy-0.8.15/debian/apparmor-profiles/squid-deb-proxy 
squid-deb-proxy-0.8.15+nmu1/debian/apparmor-profiles/squid-deb-proxy
--- squid-deb-proxy-0.8.15/debian/apparmor-profiles/squid-deb-proxy 
1970-01-01 09:00:00.0 +0900
+++ squid-deb-proxy-0.8.15+nmu1/debian/apparmor-profiles/squid-deb-proxy
2021-06-14 23:38:09.0 +0900
@@ -0,0 +1,6 @@
+# vim:syntax=apparmor
+
+/etc/squid-deb-proxy/** r,
+/var/log/squid-deb-proxy/* rw,
+/run/squid-deb-proxy.pid rwk,
+/var/cache/squid-deb-proxy/** rw,
diff -Nru squid-deb-proxy-0.8.15/debian/changelog 
squid-deb-proxy-0.8.15+nmu1/debian/changelog
--- squid-deb-proxy-0.8.15/debian/changelog 2020-01-19 03:00:55.0 
+0900
+++ squid-deb-proxy-0.8.15+nmu1/debian/changelog2021-06-14 
23:41:11.0 +0900
@@ -1,3 +1,10 @@
+squid-deb-proxy (0.8.15+nmu1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Add apparmor profiles to work (Closes: #932501)
+
+ -- Hideki Yamane   Mon, 14 Jun 2021 23:41:11 +0900
+
 squid-deb-proxy (0.8.15) unstable; urgency=medium
 
   [ Graham Cantin ]
diff -Nru squid-deb-proxy-0.8.15/debian/squid-deb-proxy.dirs 
squid-deb-proxy-0.8.15+nmu1/debian/squid-deb-proxy.dirs
--- squid-deb-proxy-0.8.15/debian/squid-deb-proxy.dirs  2020-01-10 
19:02:40.0 +0900
+++ squid-deb-proxy-0.8.15+nmu1/debian/squid-deb-proxy.dirs 2021-06-14 
23:40:40.0 +0900
@@ -1,2 +1,3 @@
 etc/resolvconf/update-libc.d
+etc/apparmor.d/abstractions/squid-deb-proxy
 var/log/squid-deb-proxy
diff -Nru squid-deb-proxy-0.8.15/debian/squid-deb-proxy.install 
squid-deb-proxy-0.8.15+nmu1/debian/squid-deb-proxy.install
--- squid-deb-proxy-0.8.15/debian/squid-deb-proxy.install   2020-01-10 
19:02:40.0 +0900
+++ squid-deb-proxy-0.8.15+nmu1/debian/squid-deb-proxy.install  2021-06-14 
23:40:21.0 +0900
@@ -1,3 +1,4 @@
 ../update-libc.d etc/resolvconf/
 etc/squid-deb-proxy
 init-common.sh usr/share/squid-deb-proxy/
+../apparmor-profiles/* etc/apparmor.d/abstractions/squid-deb-proxy/