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

[Andrei POPESCU]

Reassign -1 src:linux 5.10.40-1

On Sb, 12 iun 21, 21:11:02, pham...@bluewin.ch wrote:
> Package: kernel 
> Version: 5.10.x-amd64
> Bug Description: My Intel AX210 Wifi and Bluetooth card not work
> Intel indicates on its website that this AX210 card is compatible from kernel 
> 5.10 !?!
> https://www.intel.com/content/www/us/en/support/articles/05511/wireless.html

Please try installing using an image from here:


https://cdimage.debian.org/images/unofficial/non-free/images-including-firmware/

> My laptop does not have an RJ-45 port, I do not have access to the internet, 
> nor to my Bluetooth devices such as my mouse, my keyboard, my headphones ;-(
> Best regards.
> Philippe

Reassigning to correct package.

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


signature.asc
Description: PGP signature

Bug#989801: RFS: libcddb/1.3.2-7 [ITA] -- library to access CDDB data - runtime files

[Tobias Frost]

On Mon, Jun 14, 2021 at 11:23:05AM +0800, Nick Gasson wrote:

> Perhaps it's best to just leave it until after the freeze?

Fine with me!
Or, if you want: target experimental in the meantime.

(Either case, ping me again when ready and remove the morinfo tag)

 --
> Thanks,
> Nick
> 

Bug#243676: any reason not to add --debug flag?

[Tomas Pospisek]

Hello Clint!

On Sun, 13 Jun 2021, Clint Adams wrote:


On Sun, Jun 13, 2021 at 11:46:31AM +0200, Tomas Pospisek wrote:

thanks for maintaining debianutils. Is there any reason Christoph Biedl's
patch to add a --debug flag doesn't get applied? It does look like being
useful?


I have no memory of ever seeing this before, but I have pushed it and
the newline fix to master.


Thanks a lot!


A man page update would be good; maybe I
will remember to do that when I have time.


Here's the manpage update:

$ git diff run-parts.8
diff --git run-parts.8 run-parts.8
index bb8c2a1..cadbe58 100644
--- run-parts.8
+++ run-parts.8
@@ -11,7 +11,7 @@ run\-parts \- run scripts or programs in a directory
 .SH SYNOPSIS
 .PP
 .B run\-parts
-[\-\-test] [\-\-verbose] [\-\-report] [\-\-lsbsysinit] [\-\-regex=RE]
+[\-\-test] [\-\-verbose] [\-\-debug] [\-\-report] [\-\-lsbsysinit] 
[\-\-regex=RE]
 [\-\-umask=umask] [\-\-arg=argument] [\-\-exit\-on\-error] [\-\-help]
 [\-\-version] [\-\-list] [\-\-reverse] [\-\-] DIRECTORY
 .PP
@@ -58,6 +58,9 @@ This option cannot be used with \-\-test.
 .B \-v, \-\-verbose
 print the name of each script to stderr before running.
 .TP
+.B \-d, \-\-debug
+print to stderr which scripts get selected for running and which don't.
+.TP
 .B \-\-report
 similar to
 .BR \-\-verbose ,

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

[Daniel Roschka]

I just ran into the exact same bug. For me it happens around 50% of the times 
I try to create a virtualenv.

The version of python3-virtualenv installed is 20.4.0+ds-1.

Daniel

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

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

Versions of packages python3-virtualenv depends on:
ii  python-pip-whl  20.3.4-2
ii  python3 3.9.2-3
ii  python3-appdirs 1.4.4-1
ii  python3-distlib 0.3.1-1
ii  python3-distutils   3.9.2-1
ii  python3-filelock3.0.12-2
ii  python3-importlib-metadata  1.6.0-2
ii  python3-pip 20.3.4-2
ii  python3-pkg-resources   52.0.0-3
ii  python3-six 1.16.0-1

python3-virtualenv recommends no packages.

python3-virtualenv suggests no packages.

-- no debconf information

Bug#989010: linux-image-5.10.0-7-amd64: No display (post, grub, boot messages and desktop) after the upgrade to 5.10.38

[jim_p]

Source: linux
Followup-For: Bug #989010
X-Debbugs-Cc: pitsior...@gmail.com

Finally, a sane reply that does not blame nvidia's driver.

I have written above that something must have changed, at least regarding intel
hw, because I was missing the coretemp readings on my conky. However, from the
page you mention, only 2 commits refer to intel and I think both of them are
not related to my hardware.

If it is a kernel issue, which means I will come accross it on any distro I
choose, I should report it on kernel's github page... if it had issue reports.
Besides that, I think I am not smart enough to do it. I reported an similar
issue on openssh (bug 912087) some years ago, but I just could not follow the
conversation until it was resolved, because it was way too technical for me.
Shouldn't a maintainer do that for me like they did for openssh? Now they have
all the logs they need.

The other solution, hopefully, is to wait for the freeze to end, debian to move
to 5.12 or newer and me praying it won't have the same issue.

Bug#989795: unblock: ogdi-dfsg/4.1.0+ds-4 (pre-approval)

[Sebastiaan Couwenberg]

Control: retitle -1 unblock: ogdi-dfsg/4.1.0+ds-5

On 6/13/21 10:40 PM, Sebastian Ramacher wrote:
> On 2021-06-13 16:47:58 +0200, Sebastiaan Couwenberg wrote:
>> On 6/13/21 3:13 PM, Sebastian Ramacher wrote:
>>> On 2021-06-13 15:03:18 +0200, Bas Couwenberg wrote:
 Package: release.debian.org
 Severity: normal
 User: release.debian@packages.debian.org
 Usertags: unblock

 Please unblock package ogdi-dfsg

 [ Reason ]
 It fixes #989790 which should help with upgrades from 3.2.

 [ Impact ]
 More troublesome distribution upgrade.

 [ Tests ]
 N/A

 [ Risks ]
 Dependency of key package (gdal).

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

 [ Other info ]
 N/A

 unblock ogdi-dfsg/4.1.0+ds-4
>>>
>>> Thanks, please go ahead and remove the moreinfo tag once the package is
>>> available in unstable.
>>
>> ogdi-dfsg (4.1.0+ds-4) has been uploaded to unstable and is built &
>> installed on all release architectures.
> 
> Sorry, I need to ask for another upload. Could you please remove
> Breaks+Replaces from libogdi4.1. They are now no longer necessary.

Done, see attached debdiff.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1
diff -Nru ogdi-dfsg-4.1.0+ds/debian/changelog 
ogdi-dfsg-4.1.0+ds/debian/changelog
--- ogdi-dfsg-4.1.0+ds/debian/changelog 2021-06-13 14:55:48.0 +0200
+++ ogdi-dfsg-4.1.0+ds/debian/changelog 2021-06-14 05:48:16.0 +0200
@@ -1,3 +1,10 @@
+ogdi-dfsg (4.1.0+ds-5) unstable; urgency=medium
+
+  * Team upload.
+  * Drop obsolete Breaks/Replaces on libogdi3.2. See: #989795.
+
+ -- Bas Couwenberg   Mon, 14 Jun 2021 05:48:16 +0200
+
 ogdi-dfsg (4.1.0+ds-4) unstable; urgency=medium
 
   * Team upload.
diff -Nru ogdi-dfsg-4.1.0+ds/debian/control ogdi-dfsg-4.1.0+ds/debian/control
--- ogdi-dfsg-4.1.0+ds/debian/control   2021-06-13 14:12:02.0 +0200
+++ ogdi-dfsg-4.1.0+ds/debian/control   2021-06-14 05:46:51.0 +0200
@@ -38,8 +38,6 @@
 Depends: ${shlibs:Depends},
  ${misc:Depends}
 Suggests: ogdi-bin
-Breaks: libogdi3.2 (<< 4.0.0)
-Replaces: libogdi3.2 (<< 4.0.0)
 Description: Open Geographic Datastore Interface Library -- library
  OGDI is the Open Geographic Datastore Interface. OGDI is an application
  programming interface (API) that uses  a standardized access methods to

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

[Philip Wyett]

Package: desktop-base
Version: 11.0.3
Severity: important

moonlight-theme still contains Debian 10 specific images.

https://salsa.debian.org/debian-desktop-team/desktop-base/-/tree/master/moonlight-theme

Example:

https://salsa.debian.org/debian-desktop-team/desktop-base/-/tree/master/moonlight-theme/lockscreen/contents/images

and

https://salsa.debian.org/debian-desktop-team/desktop-base/-/tree/master/moonlight-theme/login

Regards

Phil

-- 
*** Playing the game for the games own sake. ***

WWW: https://kathenas.org

Twitter: @kathenasorg

Instagram: @kathenasorg

IRC: kathenas

GPG: 724AA9B52F024C8B


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

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

[Francisco M Neto]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "elementary-terminal":

 * Package name: elementary-terminal
   Version : 5.5.2-1~exp1
   Upstream Author : elementary, Inc 
 * URL : https://elementary.io
 * License : GPL-3+
 * Vcs : [fill in URL of packaging vcs]
   Section : x11

It builds those binary packages:

  elementary-terminal - Modern terminal from elementary project

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

  https://mentors.debian.net/package/elementary-terminal/

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

  dget -x 
https://mentors.debian.net/debian/pool/main/e/elementary-terminal/elementary-terminal_5.5.2-1~exp1.dsc

Changes for the initial release:

 elementary-terminal (5.5.2-1~exp1) experimental; urgency=medium
 .
   * Initial release (Closes: #989489)

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

Bug#989801: RFS: libcddb/1.3.2-7 [ITA] -- library to access CDDB data - runtime files

[Nick Gasson]

Hi Tobias,

On 14/06/21 00:33 am, Tobias Frost wrote:
>
> as you know, we are currently in the freeze; that means such a big changeset 
> is
> not appropiate at this time to be uploaded to unstable.

OK, sure.

>
> Said, that, it looks like that #952689 _might_ be a good reason to cherry-pick
> the fix for that bug and do an targetet upload; if I understood correctly,
> without this patch the package is quite useless in its default configuration…
> Possibly the bugs severity should be raised because of that…
>

It is useless if a program uses the library defaults directly and
doesn't give the user a way to configure the server manually.  However I
think most programs have some kind of config dialog allowing the server
to be changed, or even override the default server to gnudb.org directly
(Asunder does this).  So it's perhaps not that serious.

The VLC crash seems worse as there's no way to work around that.  But
that bug isn't new (it was fixed 9 years ago in the vendored copy in
upstream VLC).

> If you agree, would you mind to prepare a minimal-changes packages to target
> this bug and file an unblock request with the release team?

Perhaps it's best to just leave it until after the freeze?

--
Thanks,
Nick

Bug#989820: RFS: elementary-code/3.4.1-1~exp1 [ITP] -- Essential code editor with tab support

[Francisco M Neto]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "elementary-code":

 * Package name: elementary-code
   Version : 3.4.1-1~exp1
   Upstream Author : [fill in name and email of upstream]
 * URL : https://elementary.io
 * License : GPL-3+, LGPL-3
 * Vcs : [fill in URL of packaging vcs]
   Section : editors

It builds those binary packages:

  libcodecore-dev - Essential code editor with tab support (development files)
  libcodecore0 - Essential code editor with tab support (shared library)
  elementary-code - Essential code editor with tab support

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

  https://mentors.debian.net/package/elementary-code/

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

  dget -x 
https://mentors.debian.net/debian/pool/main/e/elementary-code/elementary-code_3.4.1-1~exp1.dsc

Changes for the initial release:

 elementary-code (3.4.1-1~exp1) experimental; urgency=medium
 .
   * Initial release (Closes: #989629)

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

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

[Francisco M Neto]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "elementary-theme":

 * Package name: elementary-theme
   Version : 5.4.2-1~exp1
   Upstream Author : Daniel Foré 
 * URL : https://elementary.io
 * License : GPL-3+
 * Vcs : https://salsa.debian.org/fmneto-guest/elementary-stylesheet
   Section : x11

It builds the binary package:

  elementary-theme - GTK stylesheet from elementary OS and Pantheon

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

  https://mentors.debian.net/package/elementary-theme/

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

  dget -x 
https://mentors.debian.net/debian/pool/main/e/elementary-theme/elementary-theme_5.4.2-1~exp1.dsc

Changes since the last upload:

 elementary-theme (5.4.2-1~exp1) experimental; urgency=medium
 .
   * Initial release (Closes: #989350)

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

Bug#989818: RFS: elementary-icons/5.3.1-1~exp1 [ITP] -- Set of vector icons originally designed for elementary OS

[Francisco M Neto]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "elementary-icons":

 * Package name: elementary-icons
   Version : 5.3.1-1~exp1
   Upstream Author : Daniel Foré 
 * URL : https://elementary.io
 * License : GPL-3+
 * Vcs : https://salsa.debian.org/fmneto-guest/elementary-icons
   Section : x11

It builds the binary package:

  elementary-icon-theme - Set of vector icons originally designed for 
elementary OS

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

  https://mentors.debian.net/package/elementary-icons/

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

  dget -x 
https://mentors.debian.net/debian/pool/main/e/elementary-icons/elementary-icons_5.3.1-1~exp1.dsc

Changes for the initial release:

 elementary-icons (5.3.1-1~exp1) experimental; urgency=medium
 .
   * Initial release (Closes: #989349)

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

Bug#989817: davmail: [PATCH] Configuration ignored when starting via init.d script

[Meeuwissen Olaf]

Package: davmail
Version: 5.5.1.3299-4
Severity: normal
X-Debbugs-Cc: none, Olaf Meeuwissen 

Dear Maintainer,

I have been using Davmail on Devuan (Debian sans systemd) without any
trouble until this morning when I wanted to check the login procedure
in the logs.  Making the relevant changes in the configuration file,
/etc/davmail/davmail.properties, and restarting the service with

  sudo /etc/init.d/davmail restart

I did not see any debug log messages in either of the logfiles that
might be in use, /var/log/davmail.log according to the init.d script
and /var/log/davmail/davmail.log in the configuration file.

Some digging around revealed that the init.d script hasn't really been
kept in sync with some of the changes made to service startup.  The
attached patch fixed things for me.  The only thing to watch out for is
keeping the logfile location in sync with the configuration file.

# I made the change to DAEMON_USER earlier to get things to work after
# the initial installation.

BTW, I don't use a keystore file so didn't bother to add
/usr/share/davmail/service-prepare to the start action.  Perhaps that is
needed as well.  Or was that handled by ENABLE_DAEMON in the past?  This
variable no longer expands to anything as far as I could see.

Hope this helps,

-- System Information:
Distributor ID: Devuan
Description:Devuan GNU/Linux 4 (chimaera)
Release:4
Codename:   n/a
Architecture: x86_64

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

Versions of packages davmail depends on:
ii  adduser   3.118
ii  default-jre-headless [java9-runtime-headless] 2:1.11-72
ii  init-system-helpers   1.60+devuan1
ii  jarwrapper0.78
ii  libcommons-codec-java 1.15-1
ii  libcommons-httpclient-java3.1-16
ii  libcommons-logging-java   1.2-2
ii  libhtmlcleaner-java   2.24-1
ii  libhttpclient-java4.5.13-2
ii  libjackrabbit-java2.18.0+r2.14.6-1
ii  libjcifs-java 1.3.19-2
ii  libjettison-java  1.4.1-1
ii  liblog4j1.2-java  1.2.17-10
ii  libmail-java  1.6.5-1
ii  libservlet-api-java   4.0.1-2
ii  libslf4j-java 1.7.30-1
ii  libstax2-api-java 4.1-1
ii  libwoodstox-java  1:6.2.1-1
ii  logrotate 3.18.0-2
ii  lsb-base  11.1.0
ii  openjdk-11-jre-headless [java9-runtime-headless]  11.0.11+9-1

davmail recommends no packages.

Versions of packages davmail suggests:
pn  libopenjfx-java 
pn  libswt-cairo-gtk-4-jni  
pn  libswt-gtk2-4-jni   

-- Configuration Files:
/etc/davmail/davmail.properties changed:
davmail.server=true
davmail.mode=EWS
davmail.url=https://outlook.office365.com/EWS/Exchange.asmx
davmail.caldavPort=1080
davmail.imapPort=1143
davmail.ldapPort=1389
davmail.popPort=1110
davmail.smtpPort=1025
davmail.enableProxy=false
davmail.useSystemProxies=false
davmail.proxyHost=
davmail.proxyPort=
davmail.proxyUser=
davmail.proxyPassword=
davmail.noProxyFor=
davmail.allowRemote=true
davmail.bindAddress=
davmail.clientSoTimeout=
davmail.server.certificate.hash=
davmail.ssl.nosecurecaldav=false
davmail.ssl.nosecureimap=false
davmail.ssl.nosecureldap=false
davmail.ssl.nosecurepop=false
davmail.ssl.nosecuresmtp=false
davmail.disableUpdateCheck=true
davmail.enableKeepAlive=true
davmail.folderSizeLimit=0
davmail.defaultDomain=
davmail.caldavAlarmSound=
davmail.caldavPastDelay=90
davmail.caldavAutoSchedule=true
davmail.forceActiveSyncUpdate=false
davmail.imapAutoExpunge=true
davmail.imapIdleDelay=
davmail.imapAlwaysApproxMsgSize=
davmail.keepDelay=30
davmail.sentKeepDelay=90
davmail.popMarkReadOnRetr=false
davmail.smtpSaveInSent=true
davmail.logFilePath=/var/log/davmail/davmail.log
davmail.logFileSize=1MB
log4j.logger.davmail=INFO
log4j.logger.httpclient.wire=INFO
log4j.logger.org.apache.commons.httpclient=INFO
log4j.rootLogger=INFO

/etc/init.d/davmail changed:
PATH=/sbin:/usr/sbin:/bin:/usr/bin
DESC="Davmail Exchange gateway"
NAME=davmail
DAEMON=/usr/bin/$NAME
DAEMON_USER=_$NAME
HOME=/var/lib/$DAEMON_USER
PIDFILE=/var/run/$NAME.pid
LOGFILE=/var/log/$NAME/$NAME.log
SCRIPTNAME=/etc/init.d/$NAME
[ -x "$DAEMON" ] || exit 0
DAEMON_ARGS="-server /etc/davmail/davmail.properties"
if [ ! -r "$LOGFILE" ]
then
touch $LOGFILE
chown 

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

[Craig Small]

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.

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

 - Craig

Bug#989344: ogre-1.12: diff for NMU version 1.12.10+dfsg2-1.1

[Olek Wojnar]

Hi smcv,

On Sun, Jun 13, 2021 at 6:43 PM Simon McVittie  wrote:

>
> On Sun, 13 Jun 2021 at 22:18:42 +0200, Jochen Sprickerhof wrote:
> > * Olek Wojnar  [2021-06-13 15:15]:
>
> some API designs make it
> really hard to keep backwards compatibility, because a lot of internal
> decisions get exposed as API/ABI. This is particularly likely to happen
> if the way the upstream developer expects their library to be used and the
> way we expect libraries to be used don't match, which is somewhat common
> in games particularly


True, good point. And those are a very common user of OGRE.


> The shared-library parts
> of Policy (section 8) are there for good reasons, and I would recommend
> checking that you understand those sections if you're maintaining or
> sponsoring a shared library package. Others on the debian-devel-games
> mailing list can help if you are unsure.
>

Before this, I would have said that I'm quite comfortable with packaging
libraries. I guess we're all always learning. And I'm clearly due for a
re-read of that section. ;)


> After bullseye is released, next time upstream bumps the SONAME
> (presumably 1.12.12?), I think it would be good to seriously consider
> packaging the libraries as libogremain1.12.12, libogreoverlay1.12.12
> and so on.
>

My perspective on that is if the libraries are all meant to be used
together then it makes little sense to split them into separate packages.
That being said, I'm not 100% that this is the case with OGRE. If not, your
suggestion would certainly make the packaging cleaner, if more lengthy. My
other concern is that I don't want to force dependent packages to declare
20 dependencies. Either way though, I appreciate the suggestion! It's a
very good point and worth investigating. I'll definitely have that
conversation with Simon (Schmeisser) when we discuss that packaging for
1.12.12.


> If that isn't an option (for example if the ftp team reject that version
> from NEW saying that the binary packages are too numerous / too small),
> then I would recommend having some automatic checks in the packaging
> that will make sure the package fails to build if the SONAME is not what
> we expect, for example by running an implementation of this pseudocode
>

Thanks for the pseudocode, and for the suggestion! Yes, that definitely
sounds like a very smart idea if we end up not splitting the packages.


> Better to catch this sort of thing *before* upload, after all!
>

+100


> Again, that seems like something that would be good to fix post-bullseye.
> The upstream SONAME bump will need to go through NEW *anyway*, so it's a
> good time to add a libogre-data package.
>

Good point. Simon and I have been working on cleaning up quite a few issues
in the package and, thus far, the focus has been on the most critical (i.e.
Lintian Errors and Warning). Organizing the package contents to not waste
archive space is definitely a good thing to add to the list of things to
address next.

(If the non-library resource files were in /usr/share/OGRE-1.12.12 then
> it would be OK for them to stay with the library.)
>

I think your first suggestion is the better solution. And if something
needs to be changed, I very much believe in changing it the right way from
the start! :)

-Olek

Bug#894350: staying alive

[Richard Hector]

I can see that keeping a copy around could be useful, if:

1. You need to start it again soon

2. You're _able_ to start it again.

Given that without disabling this feature I can't restart it without 
killing the old one first, I can't see that it's useful.


In addition, I don't use it often - only for sites that for whatever 
reason don't work in my usual browser, or to test a site without 
whatever my usual browser has cached. But I imagine that's atypical of a 
konqueror user.


Richard

Bug#989004: imagemagick-6.q16: Display terminates after ~ 3 seconds

[Bernhard Übelacker]

Hello Helge,
I just tried to collect some information for the Maintainer.

Might this be the expected behaviour?


This image seems to have a stored Delay and Duration value:

$ identify -verbose 2006_08262.gif
Image:
  Filename: 2006_08262.gif
...
  Delay: 20x100
  Duration: 20
...



These 20 get get read here:
(rr) bt
#0  0x7fcdf0974404 in ReadGIFImage (image_info=, 
exception=) at ../../coders/gif.c:1098
#1  0x7fcdf0717c20 in ReadImage 
(image_info=image_info@entry=0x558dfa3c9680, 
exception=exception@entry=0x558dfa3c4c10) at ../../magick/constitute.c:563
#2  0x7fcdf05ce223 in DisplayImageCommand (image_info=0x558dfa3c9680, 
image_info@entry=0x558dfa3c54e0, argc=, argc@entry=2, 
argv=, argv@entry=0x7fff189926b8, 
wand_unused_metadata=wand_unused_metadata@entry=0x0, 
exception=exception@entry=0x558dfa3c4c10) at ../../wand/display.c:492
#3  0x7fcdf0616f80 in MagickCommandGenesis 
(image_info=image_info@entry=0x558dfa3c54e0, command=0x7fcdf05cd5b0 
, argc=argc@entry=2, argv=argv@entry=0x7fff189926b8, 
metadata=metadata@entry=0x0, exception=exception@entry=0x558dfa3c4c10) at 
../../wand/mogrify.c:173
#4  0x558df995d0fa in DisplayMain (argv=0x7fff189926b8, argc=2) at 
../../utilities/display.c:89
#5  main (argc=2, argv=0x7fff189926b8) at ../../utilities/display.c:100



And get interpreted here, resulting in a delay of 0:

14934 
delay=display_image->delay/MagickMax(display_image->ticks_per_second,1L);
(rr) bt
#0  XDisplayImage (display=display@entry=0x558dfa3c17f0, 
resource_info=resource_info@entry=0x7fff18991270, argv=0x558dfa3c15b0, argc=2, 
image=image@entry=0x7fff18990a50, state=state@entry=0x7fff18990a48) at 
../../magick/display.c:14935
#1  0x7fcdf05cfaa7 in DisplayImageCommand (image_info=0x558dfa3c9680, 
image_info@entry=0x558dfa3c54e0, argc=, argc@entry=2, 
argv=, argv@entry=0x7fff189926b8, 
wand_unused_metadata=wand_unused_metadata@entry=0x0, 
exception=exception@entry=0x558dfa3c4c10) at ../../wand/display.c:538
#2  0x7fcdf0616f80 in MagickCommandGenesis 
(image_info=image_info@entry=0x558dfa3c54e0, command=0x7fcdf05cd5b0 
, argc=argc@entry=2, argv=argv@entry=0x7fff189926b8, 
metadata=metadata@entry=0x0, exception=exception@entry=0x558dfa3c4c10) at 
../../wand/mogrify.c:173
#3  0x558df995d0fa in DisplayMain (argv=0x7fff189926b8, argc=2) at 
../../utilities/display.c:89
#4  main (argc=2, argv=0x7fff189926b8) at ../../utilities/display.c:100
(rr) print display_image->ticks_per_second
$11 = 100
(rr) print display_image->delay
$12 = 20
(rr) next
14935 timer=GetMagickTime()+(delay == 0 ? 1 : delay)+1;
(rr) print delay
$13 = 0

https://sources.debian.org/src/imagemagick/8:6.9.11.60+dfsg-1.3/magick/display.c/#L14934



One could modify the delay to e.g. 1000 centiseconds == 10 seconds:

time display-im6.q16 -delay 1000 2006_08262.gif



I am not sure how this "Delay" and "Duration" is expected
to be interpreted (or ignored?) for a GIF with just one picture.


Kind regards,
Bernhard

Bug#989809: Loading chess.sty cause Babel error

[Norbert Preining]

Hi

On Mon, 14 Jun 2021, Bill Allombert wrote:
> scid generates files similar to the ones I sent you.

Interesting ... they really should update their file generation routine.

> Now, I can easily fix chess.sty. On the other hand, contacting someone

Please feel free to fix it and upload it to CTAN. If you need a hand with
that, I can help! I am confident that CTAN allows an upload of a fixed
package that hasn't seen maintainance in that many years (they normally
require confirmation by the author).

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#812512: [Pkg-utopia-maintainers] Bug#812512: pkexec tty hijacking via TIOCSTI ioctl

[argv minus one]

On Sun, Jun 13, 2021, 6:14 AM Michael Biebl  wrote:

> Hm, I'm not seeing a patch there. Do you maybe have link to this kernel
> patch?
>

No, sorry. The existence of such a patch is implied by [1], and there was
an unsuccessful attempt to merge such a patch into upstream Linux [2], but
that's all I know about it.

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1299955#c1
[2] https://lore.kernel.org/patchwork/patch/793178/

>

Bug#989816: "WARNING: cgroup v2 is not fully supported yet, proceeding with partial confinement"

[FPacifica]

Package: snapd
Version: 2.49-1+b4
Severity: normal

Dear Maintainer,

When running a snap command, for example I installed the snap package
'hugo', it always gives the warning message "WARNING: cgroup v2 is not
fully supported yet, proceeding with partial confinement":

---
$ /snap/bin/hugo version
WARNING: cgroup v2 is not fully supported yet, proceeding with partial 
confinement
hugo v0.83.1 linux/amd64 BuildDate=2021-05-02T17:25:51Z


A similar issue is mentioned in bug #934372 which was initially filed
under a different problem.




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

Versions of packages snapd depends on:
ii  adduser  3.118
ii  apparmor 2.13.6-10
ii  ca-certificates  20210119
ii  gnupg2.2.27-2
ii  libapparmor1 2.13.6-10
ii  libc62.31-12
ii  libcap2  1:2.44-1
ii  libseccomp2  2.5.1-1
ii  libudev1 247.3-5
ii  openssh-client   1:8.4p1-5
ii  squashfs-tools   1:4.4-2
ii  systemd  247.3-5
ii  udev 247.3-5

Versions of packages snapd recommends:
ii  gnupg  2.2.27-2

Versions of packages snapd suggests:
ii  kdialog  4:20.12.0-1

-- no debconf information

Bug#243676: any reason not to add --debug flag?

[Clint Adams]

On Sun, Jun 13, 2021 at 11:46:31AM +0200, Tomas Pospisek wrote:
> thanks for maintaining debianutils. Is there any reason Christoph Biedl's
> patch to add a --debug flag doesn't get applied? It does look like being
> useful?

I have no memory of ever seeing this before, but I have pushed it and
the newline fix to master.  A man page update would be good; maybe I
will remember to do that when I have time.

Bug#989815: buster-pu: package ring/20190215.1.f152c98~ds1-1

[Thorsten Alteholz]

Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu

Probably a bit late, but Salvatore just suggested to handle this via PU 
instead of security upload.


The attached debdiff for ring fixes CVE-2021-21375 in Buster.

The fix has been already uploaded to Stretch some time ago and nobody 
complained up to now.


  Thorsten

PS. In order to avoid delays, I already uploaded the package ...diff -Nru ring-20190215.1.f152c98~ds1/debian/changelog 
ring-20190215.1.f152c98~ds1/debian/changelog
--- ring-20190215.1.f152c98~ds1/debian/changelog2019-02-19 
04:46:25.0 +0100
+++ ring-20190215.1.f152c98~ds1/debian/changelog2021-04-22 
19:03:02.0 +0200
@@ -1,3 +1,14 @@
+ring (20190215.1.f152c98~ds1-1+deb10u1) buster; urgency=high
+
+  * Non-maintainer upload by the LTS Team.
+  * CVE-2021-21375 (Closes: #986815)
+The embedded copy of pjproject is affected by this CVE.
+Due to bad handling of two consecutive crafted answers to an INVITE,
+the attacker is able to crash the server resulting in a denial of
+service.
+
+ -- Thorsten Alteholz   Thu, 22 Apr 2021 19:03:02 +0200
+
 ring (20190215.1.f152c98~ds1-1) unstable; urgency=medium
 
   * New upstream version.
diff -Nru ring-20190215.1.f152c98~ds1/debian/patches/CVE-2021-21375.patch 
ring-20190215.1.f152c98~ds1/debian/patches/CVE-2021-21375.patch
--- ring-20190215.1.f152c98~ds1/debian/patches/CVE-2021-21375.patch 
1970-01-01 01:00:00.0 +0100
+++ ring-20190215.1.f152c98~ds1/debian/patches/CVE-2021-21375.patch 
2021-04-22 19:03:02.0 +0200
@@ -0,0 +1,33 @@
+Index: 
ring-20190215.1.f152c98~ds1/daemon/contrib/tarballs-unpacked/pjproject-2.8.tar.gz/pjproject-2.8/pjmedia/src/pjmedia/sdp_neg.c
+===
+--- 
ring-20190215.1.f152c98~ds1.orig/daemon/contrib/tarballs-unpacked/pjproject-2.8.tar.gz/pjproject-2.8/pjmedia/src/pjmedia/sdp_neg.c
 2021-04-25 18:03:13.057447325 +0200
 
ring-20190215.1.f152c98~ds1/daemon/contrib/tarballs-unpacked/pjproject-2.8.tar.gz/pjproject-2.8/pjmedia/src/pjmedia/sdp_neg.c
  2021-04-25 18:03:13.037446913 +0200
+@@ -304,7 +304,6 @@
+ {
+ pjmedia_sdp_session *new_offer;
+ pjmedia_sdp_session *old_offer;
+-char media_used[PJMEDIA_MAX_SDP_MEDIA];
+ unsigned oi; /* old offer media index */
+ pj_status_t status;
+ 
+@@ -323,8 +322,19 @@
+ /* Change state to STATE_LOCAL_OFFER */
+ neg->state = PJMEDIA_SDP_NEG_STATE_LOCAL_OFFER;
+ 
++/* When there is no active local SDP in state PJMEDIA_SDP_NEG_STATE_DONE,
++ * it means that the previous initial SDP nego must have been failed,
++ * so we'll just set the local SDP offer here.
++ */
++if (!neg->active_local_sdp) {
++  neg->initial_sdp_tmp = NULL;
++  neg->initial_sdp = pjmedia_sdp_session_clone(pool, local);
++  neg->neg_local_sdp = pjmedia_sdp_session_clone(pool, local);
++
++  return PJ_SUCCESS;
++}
++
+ /* Init vars */
+-pj_bzero(media_used, sizeof(media_used));
+ old_offer = neg->active_local_sdp;
+ new_offer = pjmedia_sdp_session_clone(pool, local);
+ 
diff -Nru ring-20190215.1.f152c98~ds1/debian/patches/series 
ring-20190215.1.f152c98~ds1/debian/patches/series
--- ring-20190215.1.f152c98~ds1/debian/patches/series   2019-02-19 
04:46:25.0 +0100
+++ ring-20190215.1.f152c98~ds1/debian/patches/series   2021-04-22 
19:03:02.0 +0200
@@ -1,3 +1,5 @@
 dont-build-gnutls.patch
 namedirectory-old-restbed.patch
 jsoncpp-rename.patch
+
+CVE-2021-21375.patch

Bug#989809: Loading chess.sty cause Babel error

[Bill Allombert]

On Mon, Jun 14, 2021 at 07:47:11AM +0900, Norbert Preining wrote:
> > Why then including it in TexLive and Debian if it is not usable ?
> 
> I don't know the reasons, but some ideas I can give:
> - because it works in plain tex
> - because nobody looked into fixing it
> - because nobody asked for removing it
> 
> Why are you fixed onto chess.sty when there are many others?

scid generates files similar to the ones I sent you.

Now, I can easily fix chess.sty. On the other hand, contacting someone
not seen for 30 years is a tall order.

Cheers,
Bill.

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

[Hakan Bayindir]

Package: kodi
Version: 2:19.1+dfsg2-1
Severity: important
Tags: l10n

Dear Maintainer,

When running kodi with a particular set of locale settings, kodi UI breaks
severely. The initial screen has no problems but Settings, Movies, TV Shows,
Power menu and many places shows no text, thumbnails or icons. In short,
Kodi becomes unusable.

Moreover there are no visible logs on the console informing about something
being wrong.

Steps to reproduce:
---
1) Set your locale as follows:

   LANG=tr_TR.UTF-8
   LANGUAGE=en_US
   LC_CTYPE="tr_TR.UTF-8"
   LC_NUMERIC="tr_TR.UTF-8"
   LC_TIME="tr_TR.UTF-8"
   LC_COLLATE="tr_TR.UTF-8"
   LC_MONETARY="tr_TR.UTF-8"
   LC_MESSAGES="tr_TR.UTF-8"
   LC_PAPER="tr_TR.UTF-8"
   LC_NAME="tr_TR.UTF-8"
   LC_ADDRESS="tr_TR.UTF-8"
   LC_TELEPHONE="tr_TR.UTF-8"
   LC_MEASUREMENT="tr_TR.UTF-8"
   LC_IDENTIFICATION="tr_TR.UTF-8"
   LC_ALL=

2) Start Kodi. Will start normally.
3) Select Movies from left menu. Press enter to select.
4) No thumbnails, no text, nothing is usable.


Expected Behavior:
--
1) Set your locale as follows:

   LANG=tr_TR.UTF-8
   LANGUAGE=en_US
   LC_CTYPE="tr_TR.UTF-8"
   LC_NUMERIC="tr_TR.UTF-8"
   LC_TIME="tr_TR.UTF-8"
   LC_COLLATE="tr_TR.UTF-8"
   LC_MONETARY="tr_TR.UTF-8"
   LC_MESSAGES="tr_TR.UTF-8"
   LC_PAPER="tr_TR.UTF-8"
   LC_NAME="tr_TR.UTF-8"
   LC_ADDRESS="tr_TR.UTF-8"
   LC_TELEPHONE="tr_TR.UTF-8"
   LC_MEASUREMENT="tr_TR.UTF-8"
   LC_IDENTIFICATION="tr_TR.UTF-8"
   LC_ALL=

2) Start Kodi. Will start normally.
3) Select Movies from left menu. Press enter to select.
4) Movies appears as normal, with relevant text. Kodi is usable.

Short Term Workaround
-
If the user sets all Locale variables to en_US.UTF-8, Kodi works as expected.
Systems locale settings are result of KDE's settings, so it's not impossible to
obtain with normal setting up of a system. 



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

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

Versions of packages kodi depends on:
ii  kodi-bin   2:19.1+dfsg2-1
ii  kodi-data  2:19.1+dfsg2-1

Versions of packages kodi recommends:
ii  kodi-repository-kodi [kodi-repository]  2:19.1+dfsg2-1
ii  kodi-visualization-spectrum 3.4.0+ds1-2

kodi suggests no packages.

-- no debconf information

Bug#989809: Loading chess.sty cause Babel error

[Norbert Preining]

> Why then including it in TexLive and Debian if it is not usable ?

I don't know the reasons, but some ideas I can give:
- because it works in plain tex
- because nobody looked into fixing it
- because nobody asked for removing it

Why are you fixed onto chess.sty when there are many others?
https://bfy.tw/R6TC top hit e.g. helps.

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#989344: ogre-1.12: diff for NMU version 1.12.10+dfsg2-1.1

[Simon McVittie]

(This is all for post-bullseye: the NMU seems like a good minimal change
to resolve this for bullseye.)

On Sun, 13 Jun 2021 at 22:18:42 +0200, Jochen Sprickerhof wrote:
> * Olek Wojnar  [2021-06-13 15:15]:
> > As Simon's sponsor, I'd like to point out that his packaging was rather
> > reasonable for a typical library. It is *extremely unusual* for a package
> > to lose backwards-compatibility across _bugfix versions_!

It's unusual, but not unheard of, unfortunately - some API designs make it
really hard to keep backwards compatibility, because a lot of internal
decisions get exposed as API/ABI. This is particularly likely to happen
if the way the upstream developer expects their library to be used and the
way we expect libraries to be used don't match, which is somewhat common
in games particularly: game developers often expect to bundle or statically
link a matching version of their game engine with each game, and are
surprised by distributions wanting to install a single copy system-wide and
use it for multiple games.

> I agree that library that change the Soname with every release don't sound
> like the best idea.

If upstream break the ABI then they are absolutely correct to bump
the SONAME. If upstream do not break the ABI, then ideally they should not
bump the SONAME; but needing transitions more often is a less painful
failure mode than having programs crash, so if the majority of their
upstream releases do break ABI, then I can understand why they would want
to bump the SONAME every time.

If upstream change the SONAME with every release, then the way we package
the library in Debian needs to reflect that. The shared-library parts
of Policy (section 8) are there for good reasons, and I would recommend
checking that you understand those sections if you're maintaining or
sponsoring a shared library package. Others on the debian-devel-games
mailing list can help if you are unsure.

> Normally lintian should warn you if library and package
> name don't match, but that's disabled for ogre-1.12. Maybe it makes sense to
> add some documentation to d/Readme.source or tests in d/rules so you don't
> forget next time.

I see the Ogre package overrides the package-name-doesnt-match-sonames
lintian tag because it is really a bundle of multiple shared libraries
libOgreMain.so.1.12.10, libOgreOverlay.so.1.12.10 and so on, which were
presumably considered to be too small to package separately.

The GNOME team has historically packaged a few libraries like this (GTK,
Pango, GLib, gdk-pixbuf) based on the idea that there was no point in
splitting them, and it has caused annoying library transitions for at
least Pango and gdk-pixbuf when we found that in fact, there *was*
a need to split them. Based on that experience, if the ftp team do
not tell you not to, I would usually recommend packaging each shared
library as a separate binary package, with the name mechanically
generated from the SONAME as recommended in Policy, and not needing to
override package-name-doesnt-match-sonames.

After bullseye is released, next time upstream bumps the SONAME
(presumably 1.12.12?), I think it would be good to seriously consider
packaging the libraries as libogremain1.12.12, libogreoverlay1.12.12
and so on.

If that isn't an option (for example if the ftp team reject that version
from NEW saying that the binary packages are too numerous / too small),
then I would recommend having some automatic checks in the packaging
that will make sure the package fails to build if the SONAME is not what
we expect, for example by running an implementation of this pseudocode
after dh_install:

ABI_VERSION=1.12.12
LIBRARIES=Bites Main MeshLodGenerator Overlay ...

foreach library in LIBRARIES:
assert that 
debian/libogre$(ABI_VERSION)/usr/lib/$(DEB_HOST_MULTIARCH)/libOgre${library}.so.$(ABI_VERSION)
 exists
get the SONAME from 
debian/libogre$(ABI_VERSION)/usr/lib/$(DEB_HOST_MULTIARCH)/libOgre${library}.so.$(ABI_VERSION)
(perhaps use eu-readelf -d or objdump -p)
assert that the SONAME is as expected

Better to catch this sort of thing *before* upload, after all!

Looking at the file list of libogre1.12, I also notice that it contains
non-library files like /usr/share/OGRE/Media/packs/SdkTrays.zip. Policy
§8.2 says /usr/share/OGRE should be in a separate package, perhaps
libogre-data or libogre-common, with appropriate versioned Depends and
Breaks to make sure the libraries and data match closely enough:

8.2. Shared library support files
If your package contains files whose names do not change with each
change in the library shared object version, you must not put them
in the shared library package.

Again, that seems like something that would be good to fix post-bullseye.
The upstream SONAME bump will need to go through NEW *anyway*, so it's a
good time to add a libogre-data package.

(If the non-library resource files were in /usr/share/OGRE-1.12.12 then
it would be OK for them 

Bug#989803: podman 3.0.1 rootless network issues: Connection reset by peer

[Reinhard Tartler]

Hi Alexander, thank you for reporting this issue.

I've prepared a fix for this that adds the referenced commit as a distro
patch. Can you please try to build
https://salsa.debian.org/debian/libpod/-/merge_requests/4 and let me know
if that fixes the issue?

Thanks!

On Sun, Jun 13, 2021 at 12:27 PM Alexander Reichle-Schmehl <
alexan...@alphamar.org> wrote:

> Hi!
>
> Found a minimal example at
>
> https://stackoverflow.com/questions/67049585/how-to-publish-ports-in-user-defined-network-in-rootless-podman
>
> To reproduce:
>
> $ podman network create samplenet
> $ podman network ls
> NAME   VERSION  PLUGINS
> samplenet  0.4.0bridge,portmap,firewall,tuning,dnsname
> $ podman run -dt --name test --network=samplenet --rm --publish 8080:80
> nginx
> $ podman port -l
> 80/tcp -> 0.0.0.0:8080
> $ curl localhost:8080
> curl: (56) Recv failure: Connection reset by peer
>
>
> Best regards,
>Alexander
>
>
> Am 2021-06-13 18:01, schrieb Alexander Reichle-Schmehl:
> > Package: podman
> > Version: 3.0.1+dfsg1-2+b2
> > Severity: important
> > Tags: patch upstream
> > X-Debbugs-Cc: alexan...@alphamar.org
> >
> > Running podman containers rootless seems I was unable to access any
> > network services in a container.
> > The apps work inside the container, but not from the host system.
> >
> > Searching around I found
> > https://github.com/containers/podman/issues/9532 which seems to be the
> > isse I run into.
> > The bug log also mentiones a missing patch in 3.0.1.
> >
> >
> > -- System Information:
> > Debian Release: 11.0
> >   APT prefers testing-security
> >   APT policy: (500, 'testing-security'), (500, 'testing')
> > Architecture: amd64 (x86_64)
> >
> > Kernel: Linux 5.10.0-7-amd64 (SMP w/4 CPU threads)
> > Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
> > LANGUAGE=en_US:en
> > Shell: /bin/sh linked to /usr/bin/dash
> > Init: systemd (via /run/systemd/system)
> > LSM: AppArmor: enabled
> >
> > Versions of packages podman depends on:
> > ii  conmon   2.0.25+ds1-1
> > ii  containernetworking-plugins  0.9.0-1+b5
> > ii  crun 0.17+dfsg-1
> > ii  golang-github-containers-common  0.33.4+ds1-1
> > ii  init-system-helpers  1.60
> > ii  iptables 1.8.7-1
> > ii  libc62.31-12
> > ii  libdevmapper1.02.1   2:1.02.175-2.1
> > ii  libgpgme11   1.14.0-1+b2
> > ii  libseccomp2  2.5.1-1
> >
> > Versions of packages podman recommends:
> > ii  buildah   1.19.6+dfsg1-1+b4
> > ii  catatonit 0.1.5-2
> > ii  fuse-overlayfs1.4.0-1
> > ii  golang-github-containernetworking-plugin-dnsname  1.1.1+ds1-4+b6
> > ii  slirp4netns   1.0.1-2
> > ii  uidmap1:4.8.1-1
> >
> > Versions of packages podman suggests:
> > pn  containers-storage  
> > pn  docker-compose  
> >
> > -- no debconf information
>
>

-- 
regards,
Reinhard

Bug#989812: apt: Lack of documentation considering options and details for apt

[Tia]

Package: apt
Version: 2.2.3
Severity: wishlist
X-Debbugs-Cc: tia3...@protonmail.com

Dear Maintainer,

Apt documentation is lacking in options and abilities that apt is capable of. 
Looking in source it does mention what tools are included, but not what options 
could be used with apt.

For example rdepends, it isn't mention in manual for apt. But that is ok, 
problem arises when there is difficulty finding about that option elsewhere. I 
have checked in "The Debian GNU/Linux FAQ" and "The Debian Administrator's 
Handbook" and it wasn't mentioned there. Found one line in "Debian Reference" 
how apt can be used instead of apt-get.

After that I was wondering what other options if there are syntax differences 
such as dist-upgrade (apt-get) and full-upgrade (apt) might be for other 
options form included tools. But I was unable to find anything.

So I am asking if such documentation if at least a list could be made. And if 
it does exists to be added to apt-doc.

-- Package-specific info:

-- System Information:
Debian Release: 11.0
  APT prefers testing-security
  APT policy: (500, 'testing-security'), (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.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 apt depends on:
ii  adduser 3.118
ii  debian-archive-keyring  2021.1.1
ii  gpgv2.2.27-2
ii  libapt-pkg6.0   2.2.3
ii  libc6   2.31-12
ii  libgcc-s1   10.2.1-6
ii  libgnutls30 3.7.1-3
ii  libseccomp2 2.5.1-1
ii  libstdc++6  10.2.1-6
ii  libsystemd0 247.3-5

Versions of packages apt recommends:
ii  ca-certificates  20210119

Versions of packages apt suggests:
pn  apt-doc  
pn  aptitude | synaptic | wajig  
pn  dpkg-dev 
ii  gnupg2.2.27-2
ii  powermgmt-base   1.36

-- no debconf information

Bug#989809: Loading chess.sty cause Babel error

[Bill Allombert]

On Mon, Jun 14, 2021 at 03:56:28AM +0900, Norbert Preining wrote:
> Hi
> 
> > Processing a document that uses chess.sty fails, for example
> 
> Well, chess.sty is from 1992 or so 
> 
> I recommend chessboard (or skak).
> 
> Also, according to our policy, I am closing this report since it is a
> problem of up-upstream (not TeX Live itself). If you want it fixed in
> the original package, please don't contact TeX Live but the original
> author of chess.sty.

Why then including it in TexLive and Debian if it is not usable ?

Cheers,
Bill.

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

[Sebastian Ramacher]

On 2021-06-13 23:35:40 +0200, Andreas Beckmann wrote:
> On 13/06/2021 22.44, Sebastian Ramacher wrote:
> > My goal is to make libgdal20 and libgdal28 co-installable. Adding those
> > Breaks is not enough and is step into the wrong direction.
> 
> Thanks for making that clear. I'll think again about libogdi ...

libogdi4.1 was partially fixed. It only needs the Breaks+Replaces
removed. See 989795

Cheers

> @Seb: could you upload the gdal3-data patch to experimental to get it
> through NEW?
> 
> Andreas
> 

-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#988507: [Pkg-javascript-devel] Bug#988507: Bug#988507: Bug#988507: update node-terser to alteast version 4.8

[Jonas Smedegaard]

Hi Sunny,

Quoting Sonnie Nkwuda (2021-06-13 20:17:18)
> Hi there.
> I realized a step in the build was executing the terser mangle and compress 
> commands against the build output ( bundle.min.js ) . I considered we don't 
> need this step as we don't have to be executing the library against itself, 
> so I made a change in debian/rules that seems to fix #988507. With this fix, 
> the build works fine as it should and all the necessary binaries generated. 
> Please find it at:  
> https://salsa.debian.org/sonnie/node-terser/-/commit/e380c31cf6c323807860d4caf439b8c954cb1d72Kindly
>  review this fix so I can proceed with fix for #988508 which we need for 
> #980316 . 

Yes! Thanks a lot - that was indeed the problem.

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

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

[Andreas Beckmann]

On 13/06/2021 22.44, Sebastian Ramacher wrote:

My goal is to make libgdal20 and libgdal28 co-installable. Adding those
Breaks is not enough and is step into the wrong direction.


Thanks for making that clear. I'll think again about libogdi ...

@Seb: could you upload the gdal3-data patch to experimental to get it 
through NEW?


Andreas

Bug#989307: DSA-4923-1: upgrading libwebkit2gtk-4.0-37 on buster pulls in xdg-desktop-portal

[Alberto Garcia]

On Sun, Jun 13, 2021 at 10:52:18AM +0900, Olaf Meeuwissen wrote:
> > Using xdg-desktop-portal-gtk is actually a consequence of the
> > webkit processes now running inside a sandbox for security
> > reasons, so there is a trade-off between not using the sandbox at
> > all or using the sandbox but recommending (not depending on) the
> > portals. I chose the latter.
> 
> I see. Perhaps that could have been communicated in NEWS.Debian.
> Then at least I might have seen it explained during the upgrade.

I think you're right about this. I will do that next time if I ever
have to make similar changes to the package.

Thanks!

Berto

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

[Sebastian Ramacher]

On 2021-06-13 17:57:46 +0200, Sebastiaan Couwenberg wrote:
> On 6/13/21 11:32 AM, Sebastian Ramacher wrote:
> > On 2021-06-13 11:14:45 +0200, Sebastiaan Couwenberg wrote:
> >> On 6/13/21 10:58 AM, Andreas Beckmann wrote:
> >>> On 13/06/2021 06.45, Sebastiaan Couwenberg wrote:
>  On 6/12/21 10:23 PM, Sebastian Ramacher wrote:
> > I have unblocked gdal.
> 
>  Thanks, libgdal (3.2.2-1) will need to be unblocked as well, it goes
> >>>
> >>> libgdal-grass ?
> >>
> >> Obviously, yes.
> >>
>  hand in hand with gdal (3.2.2+dfsg-1). libgdal needs the same upstream
>  version of gdal to build successfully.
> 
> > Please go ahead with an upload adding a gdal3-data binary package.
> 
>  That's much more invasive as suggested in #986975 as it will need to
>  pass NEW in addition to an unblock.
> >>>
> >>> And it does not really help, since it just uncovers that there are more
> >>> dependencies on not co-installable libraries: libogdi3.2/libogdi4.1 due
> >>> to plugins in unversioned paths. Theoretically fixable as well by moving
> >>> the plugins to a versioned path. Not sure what would show up next.
> >>>
>  #986975 just adds Breaks: libgdal20 to libgdal28 for smoother upgrades
>  from buster, that seems like a reasonable change.
> >>>
> >>> See attached patch. Especially for its very verbose changelog entry ;-)
> >>
> >> A build with the Breaks is running as we speak, if that resolves the
> >> montiverdi case I'll upload it to unstable, unless you expect more changes.
> > 
> > Please rename the binary package and follow the spirit of Policy 8.2 also 
> > with
> > the data files of gdal.
> 
> I don't want to go that route. Adding the Breaks removed the need for
> full-upgrade twice, so that's better than we had before. I don't see the
> need for renaming gdal-data.

My goal is to make libgdal20 and libgdal28 co-installable. Adding those
Breaks is not enough and is step into the wrong direction.

Cheers

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

-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#989795: unblock: ogdi-dfsg/4.1.0+ds-4 (pre-approval)

[Sebastian Ramacher]

Control: reopen -1

On 2021-06-13 16:47:58 +0200, Sebastiaan Couwenberg wrote:
> Control: tags -1 - moreinfo
> 
> On 6/13/21 3:13 PM, Sebastian Ramacher wrote:
> > On 2021-06-13 15:03:18 +0200, Bas Couwenberg wrote:
> >> Package: release.debian.org
> >> Severity: normal
> >> User: release.debian@packages.debian.org
> >> Usertags: unblock
> >>
> >> Please unblock package ogdi-dfsg
> >>
> >> [ Reason ]
> >> It fixes #989790 which should help with upgrades from 3.2.
> >>
> >> [ Impact ]
> >> More troublesome distribution upgrade.
> >>
> >> [ Tests ]
> >> N/A
> >>
> >> [ Risks ]
> >> Dependency of key package (gdal).
> >>
> >> [ Checklist ]
> >>   [x] all changes are documented in the d/changelog
> >>   [x] I reviewed all changes and I approve them
> >>   [x] attach debdiff against the package in testing
> >>
> >> [ Other info ]
> >> N/A
> >>
> >> unblock ogdi-dfsg/4.1.0+ds-4
> > 
> > Thanks, please go ahead and remove the moreinfo tag once the package is
> > available in unstable.
> 
> ogdi-dfsg (4.1.0+ds-4) has been uploaded to unstable and is built &
> installed on all release architectures.

Sorry, I need to ask for another upload. Could you please remove
Breaks+Replaces from libogdi4.1. They are now no longer necessary.

Cheers

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

-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#989666: [pre-approval] unblock: firmware-sof/1.7-1

[Vincent Bernat]

Control: tags -1 - moreinfo

 ❦ 11 June 2021 21:05 +02, Sebastian Ramacher:

>> > Could you also provide us with a binary debdiff to be sure that these
>> > changes in d/rules have the desired effect?
>> 
>> Hello Sebastian,
>> 
>> Here it is:
>> 
>> [The following lists of changes regard files as different if they have
>> different names, permissions or owners.]
>
> Thanks, that looks sane (switch from v1.6.1 to v1.7). Please remove the
> moreinfo tags once the new version is available in unstable.

Done. Thanks!
-- 
Make it clear before you make it faster.
- The Elements of Programming Style (Kernighan & Plauger)

Bug#989540: unblock: git/1:2.32.0-1

[Paul Gevers]

Control: tags -1 moreinfo

Hi Jonathan,

On Sun, 6 Jun 2021 15:56:50 -0700 Jonathan Nieder 
wrote:
>   [x] I reviewed all changes and I approve them

I hope for you you didn't go over all changes line-by-line:
 1089 files changed, 151811 insertions(+), 82910 deletions(-)

You're debdiff was so large, that your request didn't reach our lists.
At the very least, could you please filter out stuff like Documentation,
translations and tests? And verify yourself that that looks sane. Please
read our FAQ [1] and see if you can answer the questions we raise there
about new upstream releases.

> I can make an upload for testing-proposed-updates that only makes
> those three changes if you prefer.

We prefer to *not* use testing-proposed-updates and in all cases where
we won't accept the new upstream release we ask maintainers to rather
revert the new upstream release such that we can get the changes via
unstable. testing-proposed-updates is nearly exclusively used for
no-change uploads where versioned dependencies are picked up that can't
migrate to testing.

Paul

[1] https://release.debian.org/bullseye/FAQ.html



OpenPGP_signature
Description: OpenPGP digital signature

Bug#989004: imagemagick-6.q16: Display terminates after ~ 3 seconds

[Helge Kreutzmann]

Hello Bernd,
On Sun, Jun 13, 2021 at 10:23:51PM +0200, Bernhard Übelacker wrote:
> Hello Helge,
> I just tried to collect some information for the Maintainer.
> 
> Might this be the expected behaviour?
> 
> 
> This image seems to have a stored Delay and Duration value:
> 
> $ identify -verbose 2006_08262.gif
> Image:
>   Filename: 2006_08262.gif
> ...
>   Delay: 20x100
>   Duration: 20
> ...

I was not aware of it.

> I am not sure how this "Delay" and "Duration" is expected
> to be interpreted (or ignored?) for a GIF with just one picture.

At least is is surprising.

If this is the intended behaviour, then please close the bug.

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#989805: collectd-core: nut plugin missing

[Michał Mirosław]

Package: collectd-core
Version: 5.12.0-6
Severity: normal
X-Debbugs-Cc: mirq-debo...@rere.qmqm.pl

The nut plugin was disabled in version 5.9.2-3 with a comment "Nut
has too many rc bugs to enter testing soon.", though since NUT packages
(nut-server / nut-client) are currently in bullseye, I believe this is
no longer correct.


-- System Information:
Debian Release: 11.0
  APT prefers testing
  APT policy: (900, 'testing'), (800, 'stable-debug'), (800, 
'proposed-updates'), (800, 'stable'), (700, 'unstable'), (600, 'experimental'), 
(540, 'oldstable'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 
'proposed-updates-debug'), (1, 'experimental-debug')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.12.10+ (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE
Locale: LANG=pl_PL.UTF-8, LC_CTYPE=pl_PL.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages collectd-core depends on:
ii  debconf [debconf-2.0]  1.5.75
ii  libc6  2.31-12
ii  libcap21:2.44-1
ii  lsb-base   11.1.0

Versions of packages collectd-core recommends:
ii  perl 5.32.1-4
ii  rrdtool  1.7.2-3+b7

Versions of packages collectd-core suggests:
ii  apache2 [httpd-cgi] 2.4.46-4
pn  apcupsd 
pn  bind9   
pn  ceph
ii  chrony [time-daemon]4.0-8
pn  collectd-dev
ii  default-jre-headless2:1.11-72
pn  default-mysql-server
ii  gnome-flashback [notification-daemon]   3.38.0-2
pn  gpsd
ii  hddtemp 0.3-beta15-54
pn  intel-cmt-cat   
ii  iptables1.8.7-1
pn  ipvsadm 
ii  libatasmart40.19-5
pn  libbson-1.0-0   
ii  libc6   2.31-12
ii  libconfig-general-perl  2.63-1
ii  libcurl3-gnutls 7.74.0-1.2
ii  libdbi1 0.9.0-6
ii  libesmtp6   1.0.6-4.3
ii  libgcc-s1   10.2.1-6
ii  libgcrypt20 1.8.7-3
ii  libglib2.0-02.66.8-1
ii  libgps283.22-3
pn  libgrpc++1  
ii  libgrpc10   1.30.2-3
ii  libhiredis0.14  0.14.1-1
ii  libhtml-parser-perl 3.75-1+b1
ii  libi2c0 4.2-1+b1
ii  libip4tc2   1.8.7-1
ii  libip6tc2   1.8.7-1
ii  libjansson4 2.13.1-1.1
ii  libldap-2.4-2   2.4.57+dfsg-3
ii  liblua5.3-0 5.3.3-1.1+b1
ii  libmariadb3 1:10.5.10-2
ii  libmemcached11  1.0.18-4.2
pn  libmicrohttpd12 
ii  libmnl0 1.0.4-3
pn  libmodbus5  
pn  libmongoc-1.0-0 
ii  libmosquitto1   2.0.10-6
ii  libnotify4  0.7.9-3
ii  libopenipmi02.0.29-0.1+b1
ii  liboping0   1.10.0-4+b1
ii  libowcapi-3.2-4 3.2p4+dfsg1-4+b1
ii  libpcap0.8  1.10.0-2
ii  libperl5.32 5.32.1-4
ii  libpq5  13.2-1
ii  libprotobuf-c1  1.3.3-1+b2
ii  libprotobuf23   3.12.4-1
ii  libpython3.93.9.2-1
ii  libqpid-proton110.22.0-5.1
ii  librabbitmq40.10.0-1
pn  librdkafka1 
ii  libregexp-common-perl   2017060201-1
pn  libriemann-client0  
ii  librrd8 1.7.2-3+b7
ii  librrds-perl1.7.2-3+b7
ii  librte-eal2120.11-7
ii  librte-ethdev21 20.11-7
ii  libsensors5 1:3.6.0-7
ii  libsnmp40   5.9+dfsg-3+b1
ii  libssl1.1   1.1.1k-1
ii  libstdc++6  10.2.1-6
ii  libudev1247.3-5
ii  liburi-perl 5.08-1
pn  libvarnishapi2  
ii  libvirt07.0.0-3
ii  libxenmisc4.14  4.14.1+11-gb0b734a8b3-1
ii  libxml2 

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

[Mike Crowe]

Hi Adam,

Thanks for the speedy response.

On Sunday 13 June 2021 at 17:25:20 +0200, Adam Lackorzynski wrote:
> Hi,
> 
> thanks for the report. The issue has always been there and had to do
> with the width of minicom's window (over 256 columns). I have addressed
> this.

Aha. I switched font at a similar time to upgrading to Bullseye and hadn't
realised that this meant that my window was no so wide!

> Martin, I have pushed this on the 2.8.x branch (8deebed). Please
> pick both changes there for the next upload.

I tried compiling master (f118eb9efe89672e5c2a75b34960813db493b2ed) with
your fix and -fsanitize=address. It looks like the original problem no
longer occurs, but now when I follow the original steps I get:

=
==56567==ERROR: AddressSanitizer: global-buffer-overflow on address 
0x557fff340c20 at pc 0x557fff2f550b bp 0x7ffe7d9321e0 sp 0x7ffe7d9321d8
READ of size 4 at 0x557fff340c20 thread T0
#0 0x557fff2f550a in mc_wdrawelm_var ../../src/window.c:1059
#1 0x557fff2d45dc in find_next ../../src/minicom.c:338
#2 0x557fff2d04c1 in scrollback ../../src/minicom.c:540
#3 0x557fff2d04c1 in main ../../src/minicom.c:1707
#4 0x7f88fb12cd09 in __libc_start_main ../csu/libc-start.c:308
#5 0x557fff2d3059 in _start 
(/overflow/mac/nobackup/git/minicom/build/src/minicom+0x25059)

0x557fff340c20 is located 32 bytes to the left of global variable 
'iconv_enabled' defined in '../../src/minicom.c:937:12' (0x557fff340c40) of 
size 4
0x557fff340c20 is located 0 bytes to the right of global variable 'outofrange' 
defined in '../../src/minicom.c:177:14' (0x557fff340420) of size 2048
SUMMARY: AddressSanitizer: global-buffer-overflow ../../src/window.c:1059 in 
mc_wdrawelm_var
Shadow bytes around the buggy address:
  0x0ab07fe60130: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0ab07fe60140: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0ab07fe60150: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0ab07fe60160: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0ab07fe60170: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x0ab07fe60180: 00 00 00 00[f9]f9 f9 f9 04 f9 f9 f9 f9 f9 f9 f9
  0x0ab07fe60190: 00 f9 f9 f9 f9 f9 f9 f9 04 f9 f9 f9 f9 f9 f9 f9
  0x0ab07fe601a0: 04 f9 f9 f9 f9 f9 f9 f9 04 f9 f9 f9 f9 f9 f9 f9
  0x0ab07fe601b0: 04 f9 f9 f9 f9 f9 f9 f9 04 f9 f9 f9 f9 f9 f9 f9
  0x0ab07fe601c0: 04 f9 f9 f9 f9 f9 f9 f9 04 f9 f9 f9 f9 f9 f9 f9
  0x0ab07fe601d0: 04 f9 f9 f9 f9 f9 f9 f9 04 f9 f9 f9 f9 f9 f9 f9
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:   00
  Partially addressable: 01 02 03 04 05 06 07
  Heap left redzone:   fa
  Freed heap region:   fd
  Stack left redzone:  f1
  Stack mid redzone:   f2
  Stack right redzone: f3
  Stack after return:  f5
  Stack use after scope:   f8
  Global redzone:  f9
  Global init order:   f6
  Poisoned by user:f7
  Container overflow:  fc
  Array cookie:ac
  Intra object redzone:bb
  ASan internal:   fe
  Left alloca redzone: ca
  Right alloca redzone:cb
  Shadow gap:  cc
==56567==ABORTING

I hope this is meaningful to you. If not, I'll see if I can work out
anything more.

Thanks.

Mike.

Bug#989344: ogre-1.12: diff for NMU version 1.12.10+dfsg2-1.1

[Jochen Sprickerhof]

Hi Olek,

* Olek Wojnar  [2021-06-13 15:15]:

Are you also planning to file an unblock bug or would you like Simon (or
me) to take care of that?


I'm happy to take care of it.


On Sat, Jun 12, 2021 at 3:27 PM  wrote:


I'm sorry for messing this up, this is my first official debian package.
Your patch looks good. Could you please also open a MR on salsa for it? Or
commit it right away if you have the permissions.
I'm currently on vacation but can do further cleanup if required and an
update to 1.12.12 starting 25.06. when I'm back home


Hi Simon, I guess your mail got blocked by SPF, sorry I should really 
look into that at some point..


No worries with your package, I remember asking the release team for 
last minute changes in my first packages as well. I will open a MR with 
the change. Enjoy your vacation!


Just to be sure, note that Ogre 1.12.12 has a new Soversion so you need 
to change the package name and do a library transition (once bullseye is 
released). Please upload new versions only to experimental for now.



As Simon's sponsor, I'd like to point out that his packaging was rather
reasonable for a typical library. It is *extremely unusual* for a package
to lose backwards-compatibility across _bugfix versions_! As I recall,
upstream notified us of their rather unusual backwards-compatibility policy
quite recently and I believe I recommended to Simon to not make a major
versioning change like that this close to release. I was also not aware at
the time that another package depended on the 1.12.x series of OGRE. So,
for the record, I certainly bear a good part of the responsibility for this
being an issue so close to release.


I agree that library that change the Soname with every release don't 
sound like the best idea. Normally lintian should warn you if library 
and package name don't match, but that's disabled for ogre-1.12. Maybe 
it makes sense to add some documentation to d/Readme.source or tests in 
d/rules so you don't forget next time.


Cheers Jochen


signature.asc
Description: PGP signature

Bug#988166: (no subject)

[Jelmer Vernooij]

severity 988166 normal
tags 988166 +upstream
thanks

I've moved Dulwich from Recommends to Depends for the moment. This will
at least work around the issue. 

Ideally we'd keep dulwich as a recommends, but that will require some
investigation and fixes upstream.

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

[Adam Lackorzynski]

Hi Mike,

thanks again. I wonder why it did not reproduce for me earlier.
Could you try attached patch and report back?


Thanks, Adam

On Sun Jun 13, 2021 at 17:16:36 +0100, Mike Crowe wrote:
> Hi Adam,
> 
> Thanks for the speedy response.
> 
> On Sunday 13 June 2021 at 17:25:20 +0200, Adam Lackorzynski wrote:
> > Hi,
> > 
> > thanks for the report. The issue has always been there and had to do
> > with the width of minicom's window (over 256 columns). I have addressed
> > this.
> 
> Aha. I switched font at a similar time to upgrading to Bullseye and hadn't
> realised that this meant that my window was no so wide!
> 
> > Martin, I have pushed this on the 2.8.x branch (8deebed). Please
> > pick both changes there for the next upload.
> 
> I tried compiling master (f118eb9efe89672e5c2a75b34960813db493b2ed) with
> your fix and -fsanitize=address. It looks like the original problem no
> longer occurs, but now when I follow the original steps I get:
> 
> =
> ==56567==ERROR: AddressSanitizer: global-buffer-overflow on address 
> 0x557fff340c20 at pc 0x557fff2f550b bp 0x7ffe7d9321e0 sp 0x7ffe7d9321d8
> READ of size 4 at 0x557fff340c20 thread T0
> #0 0x557fff2f550a in mc_wdrawelm_var ../../src/window.c:1059
> #1 0x557fff2d45dc in find_next ../../src/minicom.c:338
> #2 0x557fff2d04c1 in scrollback ../../src/minicom.c:540
> #3 0x557fff2d04c1 in main ../../src/minicom.c:1707
> #4 0x7f88fb12cd09 in __libc_start_main ../csu/libc-start.c:308
> #5 0x557fff2d3059 in _start 
> (/overflow/mac/nobackup/git/minicom/build/src/minicom+0x25059)
> 
> 0x557fff340c20 is located 32 bytes to the left of global variable 
> 'iconv_enabled' defined in '../../src/minicom.c:937:12' (0x557fff340c40) of 
> size 4
> 0x557fff340c20 is located 0 bytes to the right of global variable 
> 'outofrange' defined in '../../src/minicom.c:177:14' (0x557fff340420) of size 
> 2048
> SUMMARY: AddressSanitizer: global-buffer-overflow ../../src/window.c:1059 in 
> mc_wdrawelm_var
> Shadow bytes around the buggy address:
>   0x0ab07fe60130: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>   0x0ab07fe60140: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>   0x0ab07fe60150: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>   0x0ab07fe60160: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>   0x0ab07fe60170: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> =>0x0ab07fe60180: 00 00 00 00[f9]f9 f9 f9 04 f9 f9 f9 f9 f9 f9 f9
>   0x0ab07fe60190: 00 f9 f9 f9 f9 f9 f9 f9 04 f9 f9 f9 f9 f9 f9 f9
>   0x0ab07fe601a0: 04 f9 f9 f9 f9 f9 f9 f9 04 f9 f9 f9 f9 f9 f9 f9
>   0x0ab07fe601b0: 04 f9 f9 f9 f9 f9 f9 f9 04 f9 f9 f9 f9 f9 f9 f9
>   0x0ab07fe601c0: 04 f9 f9 f9 f9 f9 f9 f9 04 f9 f9 f9 f9 f9 f9 f9
>   0x0ab07fe601d0: 04 f9 f9 f9 f9 f9 f9 f9 04 f9 f9 f9 f9 f9 f9 f9
> Shadow byte legend (one shadow byte represents 8 application bytes):
>   Addressable:   00
>   Partially addressable: 01 02 03 04 05 06 07
>   Heap left redzone:   fa
>   Freed heap region:   fd
>   Stack left redzone:  f1
>   Stack mid redzone:   f2
>   Stack right redzone: f3
>   Stack after return:  f5
>   Stack use after scope:   f8
>   Global redzone:  f9
>   Global init order:   f6
>   Poisoned by user:f7
>   Container overflow:  fc
>   Array cookie:ac
>   Intra object redzone:bb
>   ASan internal:   fe
>   Left alloca redzone: ca
>   Right alloca redzone:cb
>   Shadow gap:  cc
> ==56567==ABORTING
> 
> I hope this is meaningful to you. If not, I'll see if I can work out
> anything more.
> 
> Thanks.
> 
> Mike.

Adam
-- 
Adam a...@os.inf.tu-dresden.de
  Lackorzynski http://os.inf.tu-dresden.de/~adam/
From b6043854f1e762801347ed4bf4d368b49ad99217 Mon Sep 17 00:00:00 2001
From: Adam Lackorzynski 
Date: Sun, 13 Jun 2021 21:10:59 +0200
Subject: [PATCH] Make mc_getline immune to MAXCOLS

---
 src/minicom.c | 20 +---
 1 file changed, 13 insertions(+), 7 deletions(-)

diff --git a/src/minicom.c b/src/minicom.c
index 2719f8c..06dd7be 100644
--- a/src/minicom.c
+++ b/src/minicom.c
@@ -174,7 +174,6 @@ static void shjump(int sig)
 static ELM *mc_getline(WIN *w, int no)
 {
   int i;
-  static ELM outofrange[MAXCOLS] = {{0,0,0}};
 
   if (no < us->histlines) {
 /* Get a line from the history buffer. */
@@ -189,13 +188,20 @@ static ELM *mc_getline(WIN *w, int no)
   /* Get a line from the "us" window. */
   no -= us->histlines;
   if (no >= w->ys) {
-if (outofrange[0].value == 0) {
-  for (i = 0; i < MAXCOLS; i++) {
-outofrange[i].value = ' ';
-outofrange[i].color = us->color;
-outofrange[i].attr  = us->attr;
+static int alloced_columns;
+static ELM *outofrange;
+int cols = w->x2 + 1;
+if (cols > alloced_columns) {
+  free(outofrange);
+  outofrange = malloc(sizeof(*outofrange) * cols);
+  assert(outofrange);
+  

Bug#989344: ogre-1.12: diff for NMU version 1.12.10+dfsg2-1.1

[Olek Wojnar]

Hi Jochen,

First of all, thank you very much for taking the time to fix those issues!
And an extra thank you for speaking with the release team already! I always
get very nervous with significant package changes this close to a release.
Are you also planning to file an unblock bug or would you like Simon (or
me) to take care of that?

On Sat, Jun 12, 2021 at 3:27 PM  wrote:

> I'm sorry for messing this up, this is my first official debian package.
> Your patch looks good. Could you please also open a MR on salsa for it? Or
> commit it right away if you have the permissions.
> I'm currently on vacation but can do further cleanup if required and an
> update to 1.12.12 starting 25.06. when I'm back home
>

As Simon's sponsor, I'd like to point out that his packaging was rather
reasonable for a typical library. It is *extremely unusual* for a package
to lose backwards-compatibility across _bugfix versions_! As I recall,
upstream notified us of their rather unusual backwards-compatibility policy
quite recently and I believe I recommended to Simon to not make a major
versioning change like that this close to release. I was also not aware at
the time that another package depended on the 1.12.x series of OGRE. So,
for the record, I certainly bear a good part of the responsibility for this
being an issue so close to release.

Thanks again for the assistance and apologies for the issues this caused in
rviz!

-Olek

Bug#989813: RFP: peepdf -- tool to analyze PDF documents

[Francois Marier]

Package: wnpp
Severity: wishlist

* Package name: peepdf
  Version : 0.3
  Upstream Author : Jose Miguel Esparza 
* URL : https://eternal-todo.com/tools/peepdf-pdf-analysis-tool
* License : GPL-3.0
  Programming Lang: Python
  Description : tool to analyze PDF documents

peepdf is a Python tool to explore PDF files in order to find out if the
file can be harmful or not. The aim of this tool is to provide all the
necessary components that a security researcher could need in a PDF analysis
without using 3 or 4 tools to make all the tasks. With peepdf it's possible
to see all the objects in the document showing the suspicious elements,
supports the most used filters and encodings, it can parse different
versions of a file, object streams and encrypted files. With the
installation of PyV8 and Pylibemu it provides Javascript and shellcode
analysis wrappers too. Apart of this it is able to create new PDF files,
modify existent ones and obfuscate them.

Bug#989808: fonts-linuxlibertine: Newer Libertine fonts available from CTAN

[Norbert Preining]

Hi Zack,

thanks for your report.

On Sun, 13 Jun 2021, Zack Weinberg wrote:
> taken over maintenance; the version of these fonts on CTAN
> (https://www.ctan.org/pkg/libertine/) is still labeled “5.3.0” but has
> received significant changes relative to what’s in Debian right now.
[...]
> is, however, ineffective on Debian because the font files in
> /usr/share/texlive/texmf-dist/fonts/opentype/public/libertine are just
> symlinks to the files provided by the fonts-linuxlibertine package.

I think I will go back to shipping *our* version of the LL fonts - I
wasn't aware that the Libertine fonts project is so much dead.

Let us hear what the ll maintainers here suggest.

(But this will only happen after release of bullseye, since everything
is in deep freeze now).

Thanks

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#981997: Conflicting monodoc-gudev-manual binary built also by Package: gudev-sharp-3.0

[Logan Rosen]

control: severity -1 serious

Per packaging policy section 3.1, "[e]very package must have a name
that’s unique within the Debian archive." Bumping the severity to
serious accordingly.

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]

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#989208: atril: Segfault

[Bernhard Übelacker]

Hello Jerome,
could you please add a few more details for the Maintainer?

What shows the "bt full" command in gdb, when the crash is reached?

Is the package dconf-service installed and
when you login a process dconf-service running?

Kind regards,
Bernhard

Bug#973368: Bluetooth mouse can not be connected with kernel linux-image-5.9.0-1-amd64

[Salvatore Bonaccorso]

On Fri, Nov 20, 2020 at 03:16:48PM +0100, Salvatore Bonaccorso wrote:
> Control: tags -1 + moreinfo
> 
> Hi,
> 
> On Thu, Oct 29, 2020 at 10:47:51PM +0800, gulfstream wrote:
> > Package: src:linux
> > Version: 5.9.1-1
> > Severity: important
> > 
> > 
> > After the kernel was upgraded to linux-image-5.9.0-1-amd64 few days
> > ago, the bluetooth mouse can not be connected which can be use with
> > linux-image-5.8.0-3-amd64. If back to linux-image-5.8.0-3-amd64, the
> > blue tooth mouse is also fine.
> 
> The mentioned version is the first one which includes fixes for the
> "BleedingTooth" issues.
> 
> Can you check if applying the changes discussed in
> https://lore.kernel.org/linux-bluetooth/20201024002251.1389267-1-luiz.de...@gmail.com/
> address the issue for you?

Hi, can you confirm: is the issue still reproducible for you with a
recent kernel, the one from Debian testing in meanwhile to 5.10.40-1?

If yes, are you able to test current mainline?

If yes, are the above changes discussed resolving the issue for you?

Regards,
Salvatore

Bug#989010: linux-image-5.10.0-7-amd64: No display (post, grub, boot messages and desktop) after the upgrade to 5.10.38

[Bernhard Übelacker]

Hello Jim,
I am not involved in packaging, but came to this report by chance.



The attached file contains all the changes you devs have made in the kernel
configs from 5.10.28 (-6 package) to 5.10.38/.40 (-7 package). It was made with
meld.
~10 kernel parameters have changed and led to this mess, so I assume it would
be trivial for you to find the faulty one.


These parameters are not all that changed - there are around 1400 patches
added upstream to the kernel between v5.10.28 and v5.10.38.

https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/log/?h=v5.10.38


Kind regards,
Bernhard

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

[Michael Biebl]

Am 13.06.2021 um 16:11 schrieb Patrice Duroux:

$ more /usr/lib/systemd/user/pipewire-pulse.socket


...


[Socket]
Priority=6
ListenStream=%t/pulse/native


Quoting the systemd.unit man page:

"%t"	Runtime directory root	This is either /run/ (for the system 
manager) or the path "$XDG_RUNTIME_DIR" resolves to (for user managers).


Since you run this as user, the socket path should be something like 
this /run/user/1000/pulse/native (assuming 1000 is your uid).

Bug#989811: ITP: python-funcy -- Collection of fancy functional tools focused on practicality

[Carsten Schoenert]

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

* Package name: python-funcy
  Version : 1.16
  Upstream Author : Alexander Schepanovski 
* URL : https://github.com/Suor/funcy
* License : BSD-3-clause, MIT
  Programming Lang: Python
  Description : Collection of fancy functional tools focused on practicality

 Funcy is designed to be a layer of functional tools over Python.
 It provides some possible often wanted functionality like:
  * Merge collections of same type (works for dicts, sets, lists, tuples,
iterators and even strings).
  * Walk through collection, creating its transform (like map but preserves
type).
  * Select a part of collection.
  * Manipulate sequences.
  * And functions.
  * CreAbstract control flowate decorators easily.
  * Abstract control flow.
  * Ease debugging.

This package is a (build) dependency for django-cachops which hasn't a ITP
yet. django-cacheops itself is a dependency for netbox I consider to
package.

The package will get maintained within the Debian Python Team.

Bug#989810: debian 11 rc1 boot sequence fails attempting to run secure boot code on a system that does not support secure boot

[David George Henderson III]

Package: grub-efi-amd64


Summary: The defect occurs on a bullseye.rc1 install ;

    install went normally using  bullseye rc1; booting the installed 
system fails


    the UEFI boot sequence on a system that doesn't support secure boot 
fails trying to access owner MOK




Hello Debian bullseye boot sequence team,

I dont have a screen grab and the message only stayed up a few seconds.

The system is a Dell Precision T1200 E3, 16GB of memory, SSD, installing 
off CDROM to an encrypted LVM with dedicated /boot and encrypted LVM 
partitions.


The bullseye system was installed using the bullseye rc1 system for an 
amd64 target.


Installation went normally; the difficulty lies when attempting to boot 
the installed system off the ssd.


Again, the boot time error message that briefly showed on the screen is 
that the MOK machine owner key could not be accessed.


I found a workaround using a previously installed Buster 10.9 system 
with a similar configuration:


    a) boot Buster 10.9 dvd in recovery mode

    b) rewrite the SSD bootstrap so the Buster 10.9 system boots

    c) reboot into Buster 10.9

        to diagnose what was going on I ran : mokutil --disable-validation

  the error message returned was 'this system does not support 
secure boot'


    d) update buster  /etc/grub.d/40_custom so it has the bullseye rc1 
boot stanza


    e) update grub

    f) shutdown the system

    g) boot the buster grub and select the bullseye 11 rc1 boot stanza 
present in 40_custom


bullseye rc1 now runs

Bug#986822: BUG#986822 Broadwell SST CATPT Sound module

[Vincent Blut]

Hi,

Le 2021-06-05 08:31, Dekks Herton a écrit :
> Hi
> 
> Additional alsa-info script output

From a quick look, alsa-info reports that you're running both PipeWire and
PulseAudio sound servers. While it may not be the root cause of your issue,
if you want to stick with the former, please disable the latter:
$ sudo systemctl --user disable --now pulseaudio.service pulseaudio.socket

Note though that using PipeWire as a substitute to PulseAudio/JACK/ALSA in
Debian 11 is considered experimental.

Cheers,
Vincent


signature.asc
Description: PGP signature

Bug#989220: solvespace: crashes when starting on Debian stable.

[Bernhard Übelacker]

Hello Juan,
the last lines of your backtrace end in nouveau_dri.so.
Therefore this might not be a fault in solvespace.

Maybe you could install the package libgl1-mesa-dri-dbgsym where
the file nouveau_dri.so originates from, and provide
another backtrace from such a crash.
I would expect that the currently uninformative lines in nouveau_dri.so
would look similar to below.

With the following environment set, before running solvespace in gdb,
you might get a backtrace more related to the
real memory operation causing the error.

  MALLOC_CHECK_=2 gdb --args solvespace


Another source of information might be to run solvespace within valgrind:

  valgrind solvespace


But I guess this issue is likeley to be caused by the graphics driver,
maybe limited to the NV50 hardware class, which your GPU seems to be.
This makes it hard to impossible to reproduce
without having such graphics hardware.

Kind regards,
Bernhard


...
#6  0xb6c70c34 in calloc () from libc.so.6
#7  0xb312b867 in nv50_rasterizer_state_create at 
../src/gallium/drivers/nouveau/nv50/nv50_state.c:230 from nouveau_dri.so
#8  0xb2ec0ea9 in cso_set_rasterizer at 
../src/gallium/auxiliary/cso_cache/cso_context.c:604 from nouveau_dri.so
#9  0xb3445465 in st_update_rasterizer at 
../src/mesa/state_tracker/st_atom_rasterizer.c:317 from nouveau_dri.so
#10 0xb3442e0f in st_validate_state at ../src/util/bitscan.h:103 from 
nouveau_dri.so
#11 0xb339fea7 in prepare_draw at ../src/mesa/state_tracker/st_draw.c:123 from 
nouveau_dri.so
#12 0xb329843e in vbo_exec_vtx_flush at ../src/mesa/vbo/vbo_exec_draw.c:393 
from nouveau_dri.so
#13 0xb3297e57 in vbo_exec_FlushVertices_internal at 
../src/mesa/vbo/vbo_exec_api.c:1255 from nouveau_dri.so
#14 0xb334477f in line_width at ../src/mesa/main/lines.c:70 from nouveau_dri.so
#15 0x004df59f in SolveSpace::ssglLineWidth (width=) at 
./src/glhelper.cpp:97
...

Bug#989062: pillow: diff for NMU version 8.1.2+dfsg-0.2

[Moritz Mühlenhoff]

debdiff for my NMU.
diff -Nru pillow-8.1.2+dfsg/debian/changelog pillow-8.1.2+dfsg/debian/changelog
--- pillow-8.1.2+dfsg/debian/changelog	2021-04-24 15:51:24.0 +0200
+++ pillow-8.1.2+dfsg/debian/changelog	2021-06-13 18:11:04.0 +0200
@@ -1,3 +1,12 @@
+pillow (8.1.2+dfsg-0.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Cherrypick security fixes from 8.2:
+- CVE-2021-25287 / CVE-2021-25288 / CVE-2021-28675 / CVE-2021-28676
+  CVE-2021-28677 / CVE-2021-28678 (Closes: #989062)
+
+ -- Moritz Muehlenhoff   Sun, 13 Jun 2021 18:11:04 +0200
+
 pillow (8.1.2+dfsg-0.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru pillow-8.1.2+dfsg/debian/patches/CVE-2021-25287_CVE-2021-25288.patch pillow-8.1.2+dfsg/debian/patches/CVE-2021-25287_CVE-2021-25288.patch
--- pillow-8.1.2+dfsg/debian/patches/CVE-2021-25287_CVE-2021-25288.patch	1970-01-01 01:00:00.0 +0100
+++ pillow-8.1.2+dfsg/debian/patches/CVE-2021-25287_CVE-2021-25288.patch	2021-06-13 18:08:32.0 +0200
@@ -0,0 +1,69 @@
+From 3bf5eddb89afdf690eceaa52bc4d3546ba9a5f87 Mon Sep 17 00:00:00 2001
+From: Eric Soroos 
+Date: Sun, 7 Mar 2021 12:32:12 +0100
+Subject: [PATCH] Fix OOB Read in Jpeg2KDecode CVE-2021-25287,CVE-2021-25288
+
+* For J2k images with multiple bands, it's legal in to have different
+  widths for each band, e.g. 1 byte for L, 4 bytes for A
+* This dates to Pillow 2.4.0
+
+--- pillow-8.1.2+dfsg.orig/src/libImaging/Jpeg2KDecode.c
 pillow-8.1.2+dfsg/src/libImaging/Jpeg2KDecode.c
+@@ -589,7 +589,7 @@ j2k_decode_entry(Imaging im, ImagingCode
+ j2k_unpacker_t unpack = NULL;
+ size_t buffer_size = 0, tile_bytes = 0;
+ unsigned n, tile_height, tile_width;
+-int components;
++int total_component_width = 0;
+ 
+ 
+ stream = opj_stream_create(BUFFER_SIZE, OPJ_TRUE);
+@@ -753,23 +753,40 @@ j2k_decode_entry(Imaging im, ImagingCode
+ goto quick_exit;
+ }
+ 
++if (tile_info.nb_comps != image->numcomps) {
++state->errcode = IMAGING_CODEC_BROKEN;
++state->state = J2K_STATE_FAILED;
++goto quick_exit;
++}
++	
+ /* Sometimes the tile_info.datasize we get back from openjpeg
+-   is less than numcomps*w*h, and we overflow in the
++   is less than sum(comp_bytes)*w*h, and we overflow in the
+shuffle stage */
+ 
+ tile_width = tile_info.x1 - tile_info.x0;
+ tile_height = tile_info.y1 - tile_info.y0;
+-components = tile_info.nb_comps == 3 ? 4 : tile_info.nb_comps;
+-if (( tile_width > UINT_MAX / components ) ||
+-( tile_height > UINT_MAX / components ) ||
+-( tile_width > UINT_MAX / (tile_height * components )) ||
+-( tile_height > UINT_MAX / (tile_width * components ))) {
++
++/* Total component width = sum (component_width) e.g, it's
++ legal for an la file to have a 1 byte width for l, and 4 for
++ a. and then a malicious file could have a smaller tile_bytes
++*/
++
++for (n=0; n < tile_info.nb_comps; n++) {
++// see csize /acsize calcs
++int csize = (image->comps[n].prec + 7) >> 3;
++csize = (csize == 3) ? 4 : csize;
++total_component_width += csize;
++}
++if ((tile_width > UINT_MAX / total_component_width) ||
++(tile_height > UINT_MAX / total_component_width) ||
++(tile_width > UINT_MAX / (tile_height * total_component_width)) ||
++(tile_height > UINT_MAX / (tile_width * total_component_width))) {
+ state->errcode = IMAGING_CODEC_BROKEN;
+ state->state = J2K_STATE_FAILED;
+ goto quick_exit;
+ }
+-
+-tile_bytes = tile_width * tile_height * components;
++	
++tile_bytes = tile_width * tile_height * total_component_width;
+ 
+ if (tile_bytes > tile_info.data_size) {
+ tile_info.data_size = tile_bytes;
diff -Nru pillow-8.1.2+dfsg/debian/patches/CVE-2021-28675.patch pillow-8.1.2+dfsg/debian/patches/CVE-2021-28675.patch
--- pillow-8.1.2+dfsg/debian/patches/CVE-2021-28675.patch	1970-01-01 01:00:00.0 +0100
+++ pillow-8.1.2+dfsg/debian/patches/CVE-2021-28675.patch	2021-06-13 18:09:24.0 +0200
@@ -0,0 +1,132 @@
+From 22e9bee4ef225c0edbb9323f94c26cee0c623497 Mon Sep 17 00:00:00 2001
+From: Eric Soroos 
+Date: Sun, 7 Mar 2021 19:04:25 +0100
+Subject: [PATCH] Fix DOS in PSDImagePlugin -- CVE-2021-28675
+
+* PSDImagePlugin did not sanity check the number of input layers and
+  vs the size of the data block, this could lead to a DOS on
+  Image.open prior to Image.load.
+* This issue dates to the PIL fork
+
+--- pillow-8.1.2+dfsg.orig/src/PIL/ImageFile.py
 pillow-8.1.2+dfsg/src/PIL/ImageFile.py
+@@ -555,12 +555,18 @@ def _safe_read(fp, size):
+ 
+ :param fp: File handle.  Must implement a read method.
+ :param size: Number of bytes to read.
+-:returns: A string containing up 

Bug#989809: Loading chess.sty cause Babel error

[Bill Allombert]

Package: texlive-games
Version: 2018.20190227-2
Severity: normal
File: /usr/share/texlive/texmf-dist/tex/latex/chess/chess.sty

Dear Debian TeX maintainers,

Processing a document that uses chess.sty fails, for example

\documentclass{article}
\usepackage{chess}
\begin{document}
\end{document}

fails:

$ pdflatex test.tex
This is pdfTeX, Version 3.14159265-2.6-1.40.19 (TeX Live
2019/dev/Debian) (preloaded format=pdflatex)
 restricted \write18 enabled.
entering extended mode
(./test.tex
LaTeX2e <2018-12-01>
(/usr/share/texlive/texmf-dist/tex/latex/base/article.cls
Document Class: article 2018/09/03 v1.4i Standard LaTeX document class
(/usr/share/texlive/texmf-dist/tex/latex/base/size10.clo))
(/usr/share/texlive/texmf-dist/tex/latex/chess/chess.sty
(/usr/share/texlive/texmf-dist/tex/generic/babel/english.sty

! Package babel Error: You are loading directly a language style.
(babel)This syntax is deprecated and you must use
(babel)\usepackage[language]{babel}.

See the babel package documentation for explanation.
Type  H   for immediate help.
 ...

l.42 \bblstyerror

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 
\documentclass{article}
\usepackage{chess}
\begin{document}
\end{document}

Bug#989593: installation report Raspberry Pi 4 UEFI

[Marc Haber]

Hi Cyril,

thanks for the analysis.

On Thu, Jun 10, 2021 at 05:16:31PM +0200, Cyril Brulebois wrote:
> May 25 11:15:32 localechooser: info: System locale 
> (debian-installer/locale) = 'en_US.UTF-8'
> May 25 11:15:32 localechooser: info: Set debian-installer/language = 
> 'en_US:en'
> May 25 11:15:32 debconf: Setting debconf/language to en_US:en
> May 25 11:15:32 main-menu[261]: INFO: Falling back to the package 
> description for brltty-udeb
> May 25 11:15:32 main-menu[261]: INFO: Falling back to the package 
> description for brltty-udeb
> May 25 11:15:34 main-menu[261]: INFO: Falling back to the package 
> description for brltty-udeb
> May 25 11:15:34 main-menu[261]: INFO: Menu item 'console-setup-udeb' 
> selected
> May 25 11:15:37 main-menu[261]: (process:1290): setupcon: gzip is not 
> accessible. Will not save cached keyboard map.
> May 25 11:15:37 main-menu[261]: (process:1290): setupcon: gzip is not 
> accessible. Will not save cached keyboard map.
> May 25 11:15:37 main-menu[261]: (process:1290): ckbcomp-mini: 
> /usr/share/console-setup/pc105.ekmap.gz does not exist
> May 25 11:15:37 main-menu[261]: (process:1290): setupcon: gzip is not 
> accessible. Will not save cached keyboard map.
> May 25 11:15:37 main-menu[261]: (process:1290): setupcon: gzip is not 
> accessible. Will not save cached keyboard map.
> May 25 11:15:37 main-menu[261]: (process:1290): /bin/setupcon: line 722: 
> can't create /etc/console-setup/cached_setup_keyboard.sh: nonexistent 
> directory
> May 25 11:15:37 main-menu[261]: (process:1290): /bin/setupcon: line 730: 
> can't create /etc/console-setup/cached_setup_font.sh: nonexistent directory
> May 25 11:15:37 main-menu[261]: (process:1290): /bin/setupcon: line 748: 
> can't create /etc/console-setup/cached_setup_terminal.sh: nonexistent 
> directory
> May 25 11:15:37 main-menu[261]: (process:1290): chmod: 
> /etc/console-setup/cached_setup_keyboard.sh: No such file or directory
> May 25 11:15:37 main-menu[261]: (process:1290): chmod: 
> /etc/console-setup/cached_setup_font.sh: No such file or directory
> May 25 11:15:37 main-menu[261]: (process:1290): chmod: 
> /etc/console-setup/cached_setup_terminal.sh: No such file or directory
> May 25 11:15:37 main-menu[261]: (process:1290): ckbcomp-mini: 
> /usr/share/console-setup/pc105.ekmap.gz does not exist
> 
> and might explain why your keyboard settings don't work right after
> selecting the layout.

Where would the Installer look for gzip? I can check at this stage
whether gzip is there.

> This seems also strange (even if I must confess I've never grepped for
> s-s-d lines before):
> 
> Jun  9 16:20:40 base-installer: Using CD-ROM mount point /media/cdrom/
> Jun  9 16:20:40 base-installer: Identifying...
> Jun  9 16:20:40 base-installer: [27dc08d5c910ea7df2dee6e03e127e52-2]
> Jun  9 16:20:40 base-installer: Scanning disc for index files...
> Jun  9 16:20:41 base-installer: Found 1 package indexes, 0 source 
> indexes, 1 translation indexes and 0 signatures
> Jun  9 16:20:41 base-installer: Found label 'Debian GNU/Linux testing 
> _Bullseye_ - Official Snapshot arm64 NETINST 20210607-08:56'
> Jun  9 16:20:41 base-installer: This disc is called:
> Jun  9 16:20:41 base-installer: 'Debian GNU/Linux testing _Bullseye_ - 
> Official Snapshot arm64 NETINST 20210607-08:56'
> Jun  9 16:20:41 base-installer: Copying package lists...
> Jun  9 16:20:41 base-installer: ^MReading Package Indexes... 0%^M
> Jun  9 16:20:41 base-installer: ^MReading Package Indexes... 0%^M
> Jun  9 16:20:41 base-installer: ^MReading Package Indexes... Done^M
> Jun  9 16:20:41 base-installer: ^MReading Translation Indexes... 0%^M
> Jun  9 16:20:41 base-installer: ^MReading Translation Indexes... Done^M
> Jun  9 16:20:41 base-installer: Writing new source list
> Jun  9 16:20:41 base-installer: Source list entries for this disc are:
> Jun  9 16:20:41 base-installer: deb cdrom:[Debian GNU/Linux testing 
> _Bullseye_ - Official Snapshot arm64 NETINST 20210607-08:56]/ bullseye main
> Jun  9 16:20:41 base-installer: Repeat this process for the rest of the 
> CDs in your set.
> Jun  9 16:20:41 base-installer: Ign:1 cdrom://[Debian GNU/Linux testing 
> _Bullseye_ - Official Snapshot arm64 NETINST 20210607-08:56] bullseye 
> InRelease
> Jun  9 16:20:41 base-installer: Err:2 cdrom://[Debian GNU/Linux testing 
> _Bullseye_ - Official Snapshot arm64 NETINST 20210607-08:56] bullseye Release
> Jun  9 16:20:41 base-installer:   Please use apt-cdrom to make this 
> CD-ROM recognized by APT. apt-get update cannot be used to add new CD-ROMs
> Jun  9 16:20:41 base-installer: Reading package lists...
> Jun  9 16:20:41 base-installer:
> Jun  9 16:20:41 base-installer: E: The repository 'cdrom://[Debian 
> GNU/Linux testing _Bullseye_ - Official Snapshot arm64 NETINST 
> 20210607-08:56] bullseye Release' does 

Bug#989808: fonts-linuxlibertine: Newer Libertine fonts available from CTAN

[Zack Weinberg]

Package: fonts-linuxlibertine
Version: 5.3.0-6
Severity: important
X-Debbugs-Cc: za...@panix.com, debian-tex-ma...@lists.debian.org

The Libertine font project ceased to make new releases circa 2012
(you will probably already have noticed that the debian/watch file is
pinging a location that no longer exists).  The TeX Live people have
taken over maintenance; the version of these fonts on CTAN
(https://www.ctan.org/pkg/libertine/) is still labeled “5.3.0” but has
received significant changes relative to what’s in Debian right now.
These changes are particularly important for use in LuaLaTeX
documents; without them, every document that uses these fonts,
rendered with LuaLaTex, will spew warnings (listed below).  I _think_
these warnings are harmless unless you want to use certain fancy
typographic features, but I’m not sure, and the problems are
apparently significant enough that libertine.sty contains special code
to force use of TeX Live’s version of the fonts.  That special code
is, however, ineffective on Debian because the font files in
/usr/share/texlive/texmf-dist/fonts/opentype/public/libertine are just
symlinks to the files provided by the fonts-linuxlibertine package.
(This is why I’ve marked the bug as severity important.  I’m also
cc:ing the TeX maintainers.)

Please update the fonts in this package to the versions found on CTAN.
It would be reasonable to consider https://www.ctan.org/pkg/libertine
the new upstream, IMHO.

-- Reproduce warnings by running lualatex on this file:
\documentclass{article}
\usepackage{libertine}
\begin{document}
x
\end{document}

-- Warnings:
Package fontspec Warning: OpenType feature 'Numbers=Uppercase' (lnum) not
(fontspec)available for font 'LinBiolinum_RB' with script
(fontspec)'CustomDefault' and language 'Default'.
Package fontspec Warning: OpenType feature 'Numbers=Uppercase' (lnum) not
(fontspec)available for font 'LinBiolinum_RB' with script
(fontspec)'CustomDefault' and language 'Default'.
Package fontspec Warning: OpenType feature 'Numbers= Monospaced, Lining'
(fontspec)(tnum) not available for font 'LinLibertine_RZI'
(fontspec)with script 'CustomDefault' and language 'Default'.
Package fontspec Warning: OpenType feature 'Numbers= Monospaced, Lining'
(fontspec)(tnum) not available for font 'LinLibertine_RZI'
(fontspec)with script 'CustomDefault' and language 'Default'.
Package fontspec Warning: OpenType feature 'Numbers=Uppercase' (lnum) not
(fontspec)available for font 'LinBiolinum_RB' with script
(fontspec)'CustomDefault' and language 'Default'.
Package fontspec Warning: OpenType feature 'Numbers=Uppercase' (lnum) not
(fontspec)available for font 'LinBiolinum_RB' with script
(fontspec)'CustomDefault' and language 'Default'.

-- Package-specific info:
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name   Version   Architecture Description
+++-==-=--=
ii  fontconfig 2.13.1-4.2amd64generic font configuration 
library - support binaries
ii  libfreetype6:amd64 2.10.4+dfsg-1 amd64FreeType 2 font engine, 
shared library files
ii  libxft2:amd64  2.3.2-2   amd64FreeType-based font drawing 
library for X

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

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

-- no debconf information

Bug#989807: qapt-deb-installer: Does not show a dialog with a checkbox to accept the license.

[Radek Raczkowski]

Package: qapt-deb-installer
Version: 3.0.5-1ubuntu1
Severity: important
X-Debbugs-Cc: rdkr...@gmail.com

Dear Maintainer,

Installation fails if the package requires a license agreement - displaying it
is not supported by QApt.

The same bug exists in the Eddy package installer and was reported here -
https://github.com/donadigo/eddy/issues/107.

Attached screenshots show how it works in terminal via APT and in Gdebi package
installer.


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

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

Versions of packages qapt-deb-installer depends on:
ii  kio   5.80.1-0ubuntu3
ii  libapt-pkg6.0 2.2.3
ii  libc6 2.33-0ubuntu5
ii  libdebconf-kde1   1.0.3-4
ii  libgcc-s1 11.1.0-1ubuntu1~21.04
ii  libkf5coreaddons5 5.80.0-0ubuntu1
ii  libkf5i18n5   5.80.0-0ubuntu1
ii  libkf5kiocore55.80.1-0ubuntu3
ii  libkf5textwidgets55.80.0-0ubuntu1
ii  libkf5widgetsaddons5  5.80.0-0ubuntu1
ii  libqapt3  3.0.5-1ubuntu1
ii  libqapt3-runtime  3.0.5-1ubuntu1
ii  libqt5core5a  5.15.2+dfsg-5
ii  libqt5gui55.15.2+dfsg-5
ii  libqt5widgets55.15.2+dfsg-5
ii  libstdc++611.1.0-1ubuntu1~21.04

qapt-deb-installer recommends no packages.

qapt-deb-installer suggests no packages.

Bug#989806: installation-reports

[Peter Ehlert]

Package: installation-reports

Boot method: USB stick
Image version: 
https://cdimage.debian.org/cdimage/bullseye_di_rc1/amd64/iso-cd/debian-bullseye-DI-rc1-amd64-netinst.iso 


Date: Sunday, June 13 2021 08:58

Machine: HP Z620 Workstation
Processor: 2x 8-Core model: Intel Xeon E5-2660
Memory: 62.83 GiB
Partitions:
df: /run/user/1000/doc: Operation not permitted
Filesystem Type 1K-blocks    Used Available Use% Mounted on
udev   devtmpfs  32916008   0  32916008   0% /dev
tmpfs  tmpfs  6587784    1844   6585940   1% /run
/dev/sdc8  ext4  19046484 4240672  13812944  24% /
tmpfs  tmpfs 32938908   62188  32876720   1% /dev/shm
tmpfs  tmpfs 5120   4  5116   1% /run/lock
/dev/sdc10 ext4  38137396   56116  36111772   1% /home
tmpfs  tmpfs  6587780  84   6587696   1% /run/user/1000

Output of lspci -knn:

00:00.0 Host bridge [0600]: Intel Corporation Xeon E5/Core i7 DMI2 
[8086:3c00] (rev 07)

    Subsystem: Hewlett-Packard Company Xeon E5/Core i7 DMI2 [103c:158a]
00:01.0 PCI bridge [0604]: Intel Corporation Xeon E5/Core i7 IIO PCI 
Express Root Port 1a [8086:3c02] (rev 07)

    Kernel driver in use: pcieport
00:02.0 PCI bridge [0604]: Intel Corporation Xeon E5/Core i7 IIO PCI 
Express Root Port 2a [8086:3c04] (rev 07)

    Kernel driver in use: pcieport
00:03.0 PCI bridge [0604]: Intel Corporation Xeon E5/Core i7 IIO PCI 
Express Root Port 3a in PCI Express Mode [8086:3c08] (rev 07)

    Kernel driver in use: pcieport
00:05.0 System peripheral [0880]: Intel Corporation Xeon E5/Core i7 
Address Map, VTd_Misc, System Management [8086:3c28] (rev 07)
    Subsystem: Hewlett-Packard Company Xeon E5/Core i7 Address Map, 
VTd_Misc, System Management [103c:158a]
00:05.2 System peripheral [0880]: Intel Corporation Xeon E5/Core i7 
Control Status and Global Errors [8086:3c2a] (rev 07)
    Subsystem: Hewlett-Packard Company Xeon E5/Core i7 Control Status 
and Global Errors [103c:158a]
00:05.4 PIC [0800]: Intel Corporation Xeon E5/Core i7 I/O APIC 
[8086:3c2c] (rev 07)

    Subsystem: Intel Corporation Xeon E5/Core i7 I/O APIC [8086:3c2c]
00:11.0 PCI bridge [0604]: Intel Corporation C600/X79 series chipset PCI 
Express Virtual Root Port [8086:1d3e] (rev 05)

    Kernel driver in use: pcieport
00:16.0 Communication controller [0780]: Intel Corporation C600/X79 
series chipset MEI Controller #1 [8086:1d3a] (rev 05)
    Subsystem: Hewlett-Packard Company C600/X79 series chipset MEI 
Controller [103c:158a]

    Kernel driver in use: mei_me
    Kernel modules: mei_me
00:16.2 IDE interface [0101]: Intel Corporation C600/X79 series chipset 
IDE-r Controller [8086:1d3c] (rev 05)
    Subsystem: Hewlett-Packard Company C600/X79 series chipset IDE-r 
Controller [103c:158a]

    Kernel driver in use: ata_generic
    Kernel modules: ata_generic
00:16.3 Serial controller [0700]: Intel Corporation C600/X79 series 
chipset KT Controller [8086:1d3d] (rev 05)
    Subsystem: Hewlett-Packard Company C600/X79 series chipset KT 
Controller [103c:158a]

    Kernel driver in use: serial
00:19.0 Ethernet controller [0200]: Intel Corporation 82579LM Gigabit 
Network Connection (Lewisville) [8086:1502] (rev 05)

    DeviceName: Onboard LAN
    Subsystem: Hewlett-Packard Company 82579LM Gigabit Network 
Connection (Lewisville) [103c:158a]

    Kernel driver in use: e1000e
    Kernel modules: e1000e
00:1a.0 USB controller [0c03]: Intel Corporation C600/X79 series chipset 
USB2 Enhanced Host Controller #2 [8086:1d2d] (rev 05)
    Subsystem: Hewlett-Packard Company C600/X79 series chipset USB2 
Enhanced Host Controller [103c:158a]

    Kernel driver in use: ehci-pci
    Kernel modules: ehci_pci
00:1b.0 Audio device [0403]: Intel Corporation C600/X79 series chipset 
High Definition Audio Controller [8086:1d20] (rev 05)
    Subsystem: Hewlett-Packard Company C600/X79 series chipset High 
Definition Audio Controller [103c:158a]

    Kernel driver in use: snd_hda_intel
    Kernel modules: snd_hda_intel
00:1c.0 PCI bridge [0604]: Intel Corporation C600/X79 series chipset PCI 
Express Root Port 2 [8086:1d12] (rev b5)

    Kernel driver in use: pcieport
00:1c.5 PCI bridge [0604]: Intel Corporation C600/X79 series chipset PCI 
Express Root Port 5 [8086:1d18] (rev b5)

    Kernel driver in use: pcieport
00:1c.6 PCI bridge [0604]: Intel Corporation C600/X79 series chipset PCI 
Express Root Port 3 [8086:1d14] (rev b5)

    Kernel driver in use: pcieport
00:1c.7 PCI bridge [0604]: Intel Corporation C600/X79 series chipset PCI 
Express Root Port 4 [8086:1d16] (rev b5)

    Kernel driver in use: pcieport
00:1d.0 USB controller [0c03]: Intel Corporation C600/X79 series chipset 
USB2 Enhanced Host Controller #1 [8086:1d26] (rev 05)
    Subsystem: Hewlett-Packard Company C600/X79 series chipset USB2 
Enhanced Host Controller [103c:158a]

    Kernel driver in use: ehci-pci
    Kernel modules: ehci_pci
00:1e.0 PCI bridge [0604]: Intel Corporation 82801 PCI Bridge 

Bug#989801: RFS: libcddb/1.3.2-7 [ITA] -- library to access CDDB data - runtime files

[Tobias Frost]

Control: tags -1 moreinfo

Hi Nick,

On Sun, Jun 13, 2021 at 10:59:25PM +0800, Nick Gasson wrote:

> Changes since the last upload:
> 
>  libcddb (1.3.2-7) unstable; urgency=medium
>  .
>* debian/control:
>  - New maintainer. (Closes: #980305)
>  - Add Vcs fields.
>  - Update debhelper compatibility level to 13.
>  - Remove Build-Depends: dh-autoreconf.
>  - Update standards version to 4.5.1, no changes needed.
>* debian/patches:
>  - Change the default server from freedb.org to gnudb.gnudb.org as the
>former is no longer available. (Closes: #952689)
>  - Disable use of SIGALRM for DNS lookup as this is not thread-safe.
>Patch adapted from upstream VLC. (Closes: #928176)
>  - Change encoding of THANKS to UTF-8 to fix lintian warning.
>* debian/compat:
>  - Removed, using Build-Depends: debhelper-compat instead.
>* debian/not-installed:
>  - Ignore .la files for dh_missing.
>  - Ignore cddb_query utility not currently packaged.
>* debian/salsa-ci.yml:
>  - Enable CI.
>* debian/libcddb2-dev.examples:
>  - Removed useless makefiles from /usr/share/doc as they are generated by
>automake and so only work within the libcddb build tree. They also
>contain the full path to the build directory which makes the package
>unreproducible. The example program is trivial to compile anyway.
>* debian/libcddb2-dev.README.Debian:
>  - Add a note on how to compile the example program.
>* debian/tests:
>  - Add a simple autopkgtest that uses the cddb_query example program to
>query the default CDDB server.
>* debian/copyright:
>  - Convert to machine readable format.
> 

as you know, we are currently in the freeze; that means such a big changeset is
not appropiate at this time to be uploaded to unstable.

Said, that, it looks like that #952689 _might_ be a good reason to cherry-pick
the fix for that bug and do an targetet upload; if I understood correctly,
without this patch the package is quite useless in its default configuration…
Possibly the bugs severity should be raised because of that…

If you agree, would you mind to prepare a minimal-changes packages to target
this bug and file an unblock request with the release team?

-- 
Cheers,
tobi

Bug#989803: podman 3.0.1 rootless network issues: Connection reset by peer

[Alexander Reichle-Schmehl]

Hi!

Found a minimal example at 
https://stackoverflow.com/questions/67049585/how-to-publish-ports-in-user-defined-network-in-rootless-podman


To reproduce:

$ podman network create samplenet
$ podman network ls
NAME   VERSION  PLUGINS
samplenet  0.4.0bridge,portmap,firewall,tuning,dnsname
$ podman run -dt --name test --network=samplenet --rm --publish 8080:80 
nginx

$ podman port -l
80/tcp -> 0.0.0.0:8080
$ curl localhost:8080
curl: (56) Recv failure: Connection reset by peer


Best regards,
  Alexander


Am 2021-06-13 18:01, schrieb Alexander Reichle-Schmehl:

Package: podman
Version: 3.0.1+dfsg1-2+b2
Severity: important
Tags: patch upstream
X-Debbugs-Cc: alexan...@alphamar.org

Running podman containers rootless seems I was unable to access any
network services in a container.
The apps work inside the container, but not from the host system.

Searching around I found
https://github.com/containers/podman/issues/9532 which seems to be the
isse I run into.
The bug log also mentiones a missing patch in 3.0.1.


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

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

Versions of packages podman depends on:
ii  conmon   2.0.25+ds1-1
ii  containernetworking-plugins  0.9.0-1+b5
ii  crun 0.17+dfsg-1
ii  golang-github-containers-common  0.33.4+ds1-1
ii  init-system-helpers  1.60
ii  iptables 1.8.7-1
ii  libc62.31-12
ii  libdevmapper1.02.1   2:1.02.175-2.1
ii  libgpgme11   1.14.0-1+b2
ii  libseccomp2  2.5.1-1

Versions of packages podman recommends:
ii  buildah   1.19.6+dfsg1-1+b4
ii  catatonit 0.1.5-2
ii  fuse-overlayfs1.4.0-1
ii  golang-github-containernetworking-plugin-dnsname  1.1.1+ds1-4+b6
ii  slirp4netns   1.0.1-2
ii  uidmap1:4.8.1-1

Versions of packages podman suggests:
pn  containers-storage  
pn  docker-compose  

-- no debconf information

Bug#989804: jamnntpd FTCBFS -- uses the build architecture compiler

[Nilesh Patra]

Package: jamnntpd
Version: 1.3-1
Severity: normal
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs
X-Debbugs-Cc: nil...@debian.org, debian-cr...@lists.debian.org

Dear Maintainer,

jamnntpd fails to cross build because it uses build compiler rather than
host compiler.
Simply adjusting d/rules to use dh_auto_build instead of $(MAKE) fixes
it.
Please consider to apply the patch

Nilesh

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

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

Versions of packages jamnntpd depends on:
ii  libc6 2.31-3
ii  lsb-base  11.1.0

Versions of packages jamnntpd recommends:
pn  crashmail  

jamnntpd suggests no packages.
--- a/debian/rules
+++ b/debian/rules
@@ -6,13 +6,13 @@ DPKG_EXPORT_BUILDFLAGS = 1
 include /usr/share/dpkg/buildflags.mk
 
 %:
-   dh $@
+   dh $@ --buildsystem=makefile
 
 override_dh_auto_clean:
$(MAKE) -C src cleanlinux
 
 override_dh_auto_build:
-   $(MAKE) -C src linux
+   dh_auto_build --sourcedirectory=src -- linux
 
 override_dh_auto_install:
dh_auto_install --destdir=debian/jamnntpd

Bug#989803: podman 3.0.1 rootless network issues: Connection reset by peer

[Alexander Reichle-Schmehl]

Package: podman
Version: 3.0.1+dfsg1-2+b2
Severity: important
Tags: patch upstream
X-Debbugs-Cc: alexan...@alphamar.org

Running podman containers rootless seems I was unable to access any network 
services in a container.
The apps work inside the container, but not from the host system.

Searching around I found https://github.com/containers/podman/issues/9532 which 
seems to be the isse I run into.
The bug log also mentiones a missing patch in 3.0.1.


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

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

Versions of packages podman depends on:
ii  conmon   2.0.25+ds1-1
ii  containernetworking-plugins  0.9.0-1+b5
ii  crun 0.17+dfsg-1
ii  golang-github-containers-common  0.33.4+ds1-1
ii  init-system-helpers  1.60
ii  iptables 1.8.7-1
ii  libc62.31-12
ii  libdevmapper1.02.1   2:1.02.175-2.1
ii  libgpgme11   1.14.0-1+b2
ii  libseccomp2  2.5.1-1

Versions of packages podman recommends:
ii  buildah   1.19.6+dfsg1-1+b4
ii  catatonit 0.1.5-2
ii  fuse-overlayfs1.4.0-1
ii  golang-github-containernetworking-plugin-dnsname  1.1.1+ds1-4+b6
ii  slirp4netns   1.0.1-2
ii  uidmap1:4.8.1-1

Versions of packages podman suggests:
pn  containers-storage  
pn  docker-compose  

-- no debconf information

Bug#989802: ITP: crustula -- antique Roman goodies, to teach Latin language

[Georges Khaznadar]

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

* Package name: crustula
  Version : 0.3.0.20210613
  Upstream Author : Yves Ouvrard 
* URL : https://github.com/ycollatin/Crustula
* License : GPL-3+
  Programming Lang: PHP
  Description : antique Roman goodies, to teach Latin language


 Crustula is a set of three web applications to enjoy Latin. Install it and
 point you web browser to http://my.web.server/crustula
 .
 This web applications have been enjoyed by many pupils of Yves Ouvrard,
 the author of the Latin lemmatizer known as "Collatinus"

Other considerations:
-
The packages collatinus and felix-latin are already part of Debian, crustula is
lightweight package which improves the experience of "Latin lovers" in Debian
environments.

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

[Sebastiaan Couwenberg]

On 6/13/21 11:32 AM, Sebastian Ramacher wrote:
> On 2021-06-13 11:14:45 +0200, Sebastiaan Couwenberg wrote:
>> On 6/13/21 10:58 AM, Andreas Beckmann wrote:
>>> On 13/06/2021 06.45, Sebastiaan Couwenberg wrote:
 On 6/12/21 10:23 PM, Sebastian Ramacher wrote:
> I have unblocked gdal.

 Thanks, libgdal (3.2.2-1) will need to be unblocked as well, it goes
>>>
>>> libgdal-grass ?
>>
>> Obviously, yes.
>>
 hand in hand with gdal (3.2.2+dfsg-1). libgdal needs the same upstream
 version of gdal to build successfully.

> Please go ahead with an upload adding a gdal3-data binary package.

 That's much more invasive as suggested in #986975 as it will need to
 pass NEW in addition to an unblock.
>>>
>>> And it does not really help, since it just uncovers that there are more
>>> dependencies on not co-installable libraries: libogdi3.2/libogdi4.1 due
>>> to plugins in unversioned paths. Theoretically fixable as well by moving
>>> the plugins to a versioned path. Not sure what would show up next.
>>>
 #986975 just adds Breaks: libgdal20 to libgdal28 for smoother upgrades
 from buster, that seems like a reasonable change.
>>>
>>> See attached patch. Especially for its very verbose changelog entry ;-)
>>
>> A build with the Breaks is running as we speak, if that resolves the
>> montiverdi case I'll upload it to unstable, unless you expect more changes.
> 
> Please rename the binary package and follow the spirit of Policy 8.2 also with
> the data files of gdal.

I don't want to go that route. Adding the Breaks removed the need for
full-upgrade twice, so that's better than we had before. I don't see the
need for renaming gdal-data.

Kind Regards,

Bas

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

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

[Adam Lackorzynski]

Hi,

thanks for the report. The issue has always been there and had to do
with the width of minicom's window (over 256 columns). I have addressed
this.

Martin, I have pushed this on the 2.8.x branch (8deebed). Please
pick both changes there for the next upload.


Thanks, Adam

On Fri Jun 11, 2021 at 15:29:55 +0100, Mike Crowe wrote:
> Package: minicom
> Version: 2.8-1
> Severity: important
> 
> Steps to reproduce:
> 
> 1. Start Minicom connected to a serial port with MINICOM="-m -c on -8"
> (although I was also able to reproduce the problem with MINICOM="" if the
> keystrokes below are changed appropriately.)
> 
> 2. Cause whatever is connected to emit more than a screenful of text.
>(Without this, Minicom won't let you enter history mode.)
> 
> 3. Press Alt-B to enter history mode. Press / to search, type something
>short that doesn't exist in the history and press Enter.
> 
> Expected result:
> 
> Minicom searches for the specified text in the buffer as it always did
> successfully in the Buster version of Minicom.
> 
> Actual result:
> 
>  *** stack smashing detected ***: terminated
> 
> and Minicom exits.
> 
> I tried compiling Minicom from the Debian package source with CC="gcc
> -fsanitize=address" and got:
> 
> =
> ==3332560==ERROR: AddressSanitizer: stack-buffer-overflow on address 
> 0x7ffc81d544e0 at pc 0x556347a102d8 bp 0x7ffc81d54080 sp 0x7ffc81d54078
> WRITE of size 4 at 0x7ffc81d544e0 thread T0
> #0 0x556347a102d7 in mc_wdrawelm_var ../../src/window.c:1055
> #1 0x5563479efb65 in find_next ../../src/minicom.c:336
> #2 0x5563479ec687 in scrollback ../../src/minicom.c:533
> #3 0x5563479ec687 in main ../../src/minicom.c:1646
> #4 0x7f0b62d83d09 in __libc_start_main ../csu/libc-start.c:308
> #5 0x5563479ee6c9 in _start 
> (/overflow/mac/Debian/minicom-2.8/build/src/minicom+0x236c9)
> 
> Address 0x7ffc81d544e0 is located in stack of thread T0 at offset 1056 in 
> frame
> #0 0x5563479efa0f in find_next ../../src/minicom.c:309
> 
>   This frame has 1 object(s):
> [32, 1056) 'tmp_line' (line 312) <== Memory access at offset 1056 
> overflows this variable
> HINT: this may be a false positive if your program uses some custom stack 
> unwind mechanism, swapcontext or vfork
>   (longjmp and C++ exceptions *are* supported)
> SUMMARY: AddressSanitizer: stack-buffer-overflow ../../src/window.c:1055 in 
> mc_wdrawelm_var
> Shadow bytes around the buggy address:
>   0x1000103a2840: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>   0x1000103a2850: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>   0x1000103a2860: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>   0x1000103a2870: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>   0x1000103a2880: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> =>0x1000103a2890: 00 00 00 00 00 00 00 00 00 00 00 00[f3]f3 f3 f3
>   0x1000103a28a0: f3 f3 f3 f3 f3 f3 f3 f3 f3 f3 f3 f3 00 00 00 00
>   0x1000103a28b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>   0x1000103a28c0: 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1 00 00
>   0x1000103a28d0: 00 f2 00 00 00 f2 f2 f2 00 00 f2 f2 f8 f8 f8 f2
>   0x1000103a28e0: f2 f2 f2 f2 f8 f8 f8 f8 f8 f8 f8 f2 f2 f2 f2 f2
> Shadow byte legend (one shadow byte represents 8 application bytes):
>   Addressable:   00
>   Partially addressable: 01 02 03 04 05 06 07
>   Heap left redzone:   fa
>   Freed heap region:   fd
>   Stack left redzone:  f1
>   Stack mid redzone:   f2
>   Stack right redzone: f3
>   Stack after return:  f5
>   Stack use after scope:   f8
>   Global redzone:  f9
>   Global init order:   f6
>   Poisoned by user:f7
>   Container overflow:  fc
>   Array cookie:ac
>   Intra object redzone:bb
>   ASan internal:   fe
>   Left alloca redzone: ca
>   Right alloca redzone:cb
>   Shadow gap:  cc
> ==3332560==ABORTING
> 
> find_next has:
>  wchar_t tmp_line[MAXCOLS];
> 
> According to gdb inside mc_wdrawelm_var:
> 
> (gdb) p w->x1
> $5 = 0
> (gdb) p w->x2
> $6 = 263
> 
> (other useful stuff like "c" was optimised out.)
> 
> If I add:
> 
> if (c >= MAXCOLS)
>   abort();
> 
> inside the loop in mc_wdrawelm_var then the process aborts as would be
> expected rather than the sanitizer complaining.
> 
> -- System Information:
> Debian Release: 11.0
>   APT prefers testing-security
>   APT policy: (500, 'testing-security'), (500, 'testing-debug'), (500, 
> 'testing')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 5.10.0-6-amd64 (SMP w/32 CPU threads)
> Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
> LANGUAGE=en_GB:en
> Shell: /bin/sh linked to /bin/bash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> Versions of packages minicom depends on:
> ii  libc6  2.31-12
> ii  libtinfo6  6.2+20201114-2
> 
> Versions of packages minicom recommends:
> ii  

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

[Francesco Poli]

Hello,
is there any progress on this [bug]?

I've just re-read all the bug log, and I acknowledge that the issue is
not easy to deal with.
But, whatever the decision, I think that the bug should be somehow
fixed, in the poppler packages, or in the other packages depending on
the library.

Please let me know, thanks for your time!


[bug]: 

-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpfHDDVOsk47.pgp
Description: PGP signature

Bug#989801: RFS: libcddb/1.3.2-7 [ITA] -- library to access CDDB data - runtime files

[Nick Gasson]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "libcddb":

 * Package name: libcddb
   Version : 1.3.2-7
   Upstream Author : Kris Verbeeck 
 * URL : http://libcddb.sourceforge.net
 * License : LGPL-2+
 * Vcs : https://salsa.debian.org/nickg/libcddb
   Section : devel

It builds those binary packages:

  libcddb2 - library to access CDDB data - runtime files
  libcddb2-dev - library to access CDDB data - development files

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

  https://mentors.debian.net/package/libcddb/

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

  dget -x 
https://mentors.debian.net/debian/pool/main/libc/libcddb/libcddb_1.3.2-7.dsc

Changes since the last upload:

 libcddb (1.3.2-7) unstable; urgency=medium
 .
   * debian/control:
 - New maintainer. (Closes: #980305)
 - Add Vcs fields.
 - Update debhelper compatibility level to 13.
 - Remove Build-Depends: dh-autoreconf.
 - Update standards version to 4.5.1, no changes needed.
   * debian/patches:
 - Change the default server from freedb.org to gnudb.gnudb.org as the
   former is no longer available. (Closes: #952689)
 - Disable use of SIGALRM for DNS lookup as this is not thread-safe.
   Patch adapted from upstream VLC. (Closes: #928176)
 - Change encoding of THANKS to UTF-8 to fix lintian warning.
   * debian/compat:
 - Removed, using Build-Depends: debhelper-compat instead.
   * debian/not-installed:
 - Ignore .la files for dh_missing.
 - Ignore cddb_query utility not currently packaged.
   * debian/salsa-ci.yml:
 - Enable CI.
   * debian/libcddb2-dev.examples:
 - Removed useless makefiles from /usr/share/doc as they are generated by
   automake and so only work within the libcddb build tree. They also
   contain the full path to the build directory which makes the package
   unreproducible. The example program is trivial to compile anyway.
   * debian/libcddb2-dev.README.Debian:
 - Add a note on how to compile the example program.
   * debian/tests:
 - Add a simple autopkgtest that uses the cddb_query example program to
   query the default CDDB server.
   * debian/copyright:
 - Convert to machine readable format.

Regards,
-- 
  Nick Gasson

Bug#989795: unblock: ogdi-dfsg/4.1.0+ds-4 (pre-approval)

[Sebastiaan Couwenberg]

Control: tags -1 - moreinfo

On 6/13/21 3:13 PM, Sebastian Ramacher wrote:
> On 2021-06-13 15:03:18 +0200, Bas Couwenberg wrote:
>> Package: release.debian.org
>> Severity: normal
>> User: release.debian@packages.debian.org
>> Usertags: unblock
>>
>> Please unblock package ogdi-dfsg
>>
>> [ Reason ]
>> It fixes #989790 which should help with upgrades from 3.2.
>>
>> [ Impact ]
>> More troublesome distribution upgrade.
>>
>> [ Tests ]
>> N/A
>>
>> [ Risks ]
>> Dependency of key package (gdal).
>>
>> [ Checklist ]
>>   [x] all changes are documented in the d/changelog
>>   [x] I reviewed all changes and I approve them
>>   [x] attach debdiff against the package in testing
>>
>> [ Other info ]
>> N/A
>>
>> unblock ogdi-dfsg/4.1.0+ds-4
> 
> Thanks, please go ahead and remove the moreinfo tag once the package is
> available in unstable.

ogdi-dfsg (4.1.0+ds-4) has been uploaded to unstable and is built &
installed on all release architectures.

Kind Regards,

Bas

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

Bug#988477: Acknowledgement (xen-hypervisor-4.14-amd64: xen dmesg shows (XEN) AMD-Vi: IO_PAGE_FAULT on sata pci device)

[Imre Szőllősi]

i tested on 4th hw

4. asus m4n78 pro, phenom ii x4 905e, md raid1, 2x samsung 1TB 860evo, 
lvm: problem does not appear


as i see, not all mb/chipset/sata pcie device affected

Thanks!

Bug#989798: gpodder: Creates visible settings directory directly under user's home directory

[tony mancill]

On Sun, Jun 13, 2021 at 04:15:35PM +0300, Harri Suutari wrote:
> Package: gpodder
> Version: 3.10.7-2
> Severity: minor
> 
> Gpodder creates its config dir as gPodder directly under $HOME. This is non-
> standard and created unnecessary visible content to user's home directory.
> 
> Should be a hidden ".gPodder" or under the ~/.config/

Hi Harri,

Thank you for reporting this.  I will forward it upstream.  I expect
that it might take a bit to get resolved.  Currently there isn't a
mechanism in the UI to set a preference for the gPodder/Downloads
directory, which I believe we want to be visible to the user and not
buried under .config/.

Cheers,
tony


signature.asc
Description: PGP signature

Bug#989791: gitlab: Some views broken by Rails 6.0.3.7 upgrade

[Antoine Le Gonidec]

On Sun, 13 Jun 2021 11:49:12 +0200 Antoine Le Gonidec 
 wrote:

I am going to answer to this report with a suggested patch.


See the attached gzipped diff for a minimal diff that seems to be enough to 
avoid the internal errors I got since the Rails upgrade to 6.3.0.7.


id-upgrade-rails-to-6.0.3.7.diff.gz
Description: application/gzip


OpenPGP_signature
Description: OpenPGP digital signature

Bug#989800: pipewire-pulse: is /var/run/pulse/native gone?

[Patrice Duroux]

Package: pipewire-pulse
Version: 0.3.28-1
Severity: normal

Dear Maintainer,

After upgrading it breaks GNOME control center sound output test (extracts from
journalctl -xe):
juin 13 15:52:07 kos-moceratops gnome-control-c[5976]: Failed to play sound: No
such driver
juin 13 15:52:08 kos-moceratops gnome-control-c[5976]: Failed to play sound: No
such driver

Then I checked:

$ systemctl status --user pipewire.socket
● pipewire.socket - Multimedia System
 Loaded: loaded (/usr/lib/systemd/user/pipewire.socket; enabled; vendor
preset: enabled)
 Active: active (running) since Sun 2021-06-13 15:49:56 CEST; 18min ago
   Triggers: ● pipewire.service
 Listen: /run/user/1001/pipewire-0 (Stream)
 CGroup:
/user.slice/user-1001.slice/user@1001.service/app.slice/pipewire.socket

juin 13 15:49:56 kos-moceratops systemd[1992]: Listening on Multimedia System.


And also:

$ more /usr/lib/systemd/user/pipewire-pulse.socket
[Unit]
Description=PipeWire PulseAudio
ConditionUser=!root
Conflicts=pulseaudio.socket

[Socket]
Priority=6
ListenStream=%t/pulse/native

[Install]
WantedBy=sockets.target


But the file /var/run/pulse/native is not there anymore on my system.
Is this expected?

Thanks,
Patrice

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

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

Versions of packages pipewire-pulse depends on:
ii  init-system-helpers  1.60
ii  libc62.31-12
ii  libpipewire-0.3-00.3.28-1
ii  pipewire 0.3.28-1

pipewire-pulse recommends no packages.

pipewire-pulse suggests no packages.

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

[Axel Beckert]

Package: psmisc
Version: 23.4-2
Severity: serious

A non-english speaking friend did a dist-upgrade of a laptop from buster
+ buster-backports to bullseye and it failed at psmisc as follows
(German locale):

dpkg: Fehler beim Bearbeiten des Archivs 
/tmp/apt-dpkg-install-AvDBUc/0-psmisc_23.4-2_amd64.deb (--unpack):
 Versuch, »/usr/share/man/de/man1/fuser.1.gz« zu überschreiben, welches auch in 
Paket manpages-de 4.9.3-4~bpo10+1 ist

So the Breaks and Replaces headers (c.f. #982059) should likely be
against "<< 4.9.3-4", not just against "<< 4.9.1-1".

-- System Information:
Debian Release: 11.0
  APT prefers bullseye
Architecture: amd64 (x86_64)

Bug#989791: gitlab: Some views broken by Rails 6.0.3.7 upgrade

[Antoine Le Gonidec]

Package: gitlab
Version: 13.11.5+ds1-1~fto10+1
Severity: important

Since Rails 6.0.3.6 → Rails 6.0.3.7 upgrade, some views fail to load
with internal errors similar to this one:

ActionView::Template::Error (Please use symbols for polymorphic route 
arguments.):  
18:   %span.issuable-number= issuable.to_reference  
  
19: 
  
20: - labels.each do |label|
  
21:   = render_label(label.present(issuable_subject: project), link: 
polymorphic_path(issuable_type_args, { milestone_title: @milestone.title, 
label_na
me: label.title, state: 'all' }), small: true)  
  
22: 
  
23: %span.assignee-icon 
  
24:   - assignees.each do |assignee|
  

This is due to the following upstream change to polymorphic routes:
https://github.com/rails/rails/commit/c4c21a9f8d7c9c8ca6570bdb82d64e2dc860e62c

GitLab has been patched 2 weeks ago, but I think it would be worth to
backport this fix.

I am going to answer to this report with a suggested patch.

-- System Information:
Debian Release: 10.9
  APT prefers stable
  APT policy: (500, 'stable'), (100, 'buster-fasttrack'), (100, 
'buster-backports')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-7-amd64 (SMP w/8 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 
(charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages gitlab depends on:
ii  asciidoctor 2.0.10-2~bpo10+1
ii  bc  1.07.1-2+b1
ii  bundler 1.17.3-3+deb10u1
ii  bzip2   1.0.6-9.2~deb10u1
ii  dbconfig-pgsql  2.0.11+deb10u1
ii  debconf [debconf-2.0]   1.5.71
ii  fonts-font-awesome [node-font-  5.0.10+really4.7.0~dfsg-4~bpo10+1
ii  gitlab-common   13.11.2+dfsg-2~fto10+1
ii  gitlab-workhorse13.11.5+ds1-1~fto10+1
ii  katex [node-katex]  0.10.2+dfsg-8~bpo10+1
ii  libjs-bootstrap4 [node-bootstr  4.3.1+dfsg2-1
ii  libjs-codemirror [node-codemir  5.54.0-2~bpo10+1
ii  libjs-pdf [node-pdfjs-dist] 2.6.347+dfsg-3~bpo10+1
ii  libjs-popper.js [node-popper.j  1.16.1+ds-2~bpo10+1
ii  libruby2.7 [ruby-rexml] 2.7.3-2~fto10+1
ii  lsb-base10.2019051400
ii  nginx   1.14.2-2+deb10u4
ii  nginx-full [nginx]  1.14.2-2+deb10u4
ii  node-autosize   4.0.2~dfsg1-5~bpo10+1
ii  node-axios  0.17.1+dfsg-2
ii  node-babel-loader   8.2.2-1~bpo10+1
ii  node-babel-plugin-lodash3.3.4+~cs2.0.1-3~bpo10+1
ii  node-babel7 7.12.12+~cs150.141.84-2~bpo10+1
ii  node-brace-expansion1.1.8-1
ii  node-cache-loader   4.1.0-6~bpo10+1
ii  node-chart.js   2.7.3+dfsg-5
ii  node-clipboard  2.0.6+ds-1~bpo10+1
ii  node-compression-webpack-plugi  3.0.1-4~bpo10+1
ii  node-copy-webpack-plugin5.1.2+~cs9.0.2-4~bpo10+1
ii  node-core-js3.6.1-2~bpo10+2
ii  node-css-loader 5.0.1+~cs14.0.5-1~bpo10+1
ii  node-d3 5.16.0-1~bpo10+1
ii  node-d3-scale   2.2.2-2~bpo10+1
ii  node-d3-selection   1.4.0-3~bpo10+1
ii  node-dateformat 3.0.0-1
ii  node-exports-loader 0.7.0-2~bpo10+1
ii  node-file-loader6.2.0-2~bpo10+1
ii  node-fuzzaldrin-plus0.5.0+dfsg-1
ii  node-glob   7.1.6-1~bpo10+1
ii  node-imports-loader 0.8.0-2~bpo10+1
ii  node-jed1.1.1-2~bpo10+1
ii  node-jquery 3.5.1+dfsg-4~bpo10+1
ii  node-jquery-ujs 1.2.2-2
ii  node-js-cookie  2.2.0-2
ii  node-js-yaml3.13.1+dfsg-2~bpo10+1
ii  node-jszip  3.2.2+dfsg-1~bpo10+1
ii  node-jszip-utils0.0.2+dfsg-2~bpo10+1
ii  node-lodash 4.17.21+dfsg+~cs8.31.189.20210220-1~bpo10+1
ii  node-marked 0.5.1+dfsg-1
ii  node-mermaid

Bug#989798: gpodder: Creates visible settings directory directly under user's home directory

[Harri Suutari]

Package: gpodder
Version: 3.10.7-2
Severity: minor

Gpodder creates its config dir as gPodder directly under $HOME. This is non-
standard and created unnecessary visible content to user's home directory.

Should be a hidden ".gPodder" or under the ~/.config/



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

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

Versions of packages gpodder depends on:
ii  dbus-x11 [dbus-session-bus]  1.12.20-0+deb10u1
ii  gir1.2-gtk-3.0   3.24.5-1
ii  python3  3.7.3-1
ii  python3-cairo1.16.2-1+b1
ii  python3-dbus 1.2.8-3
ii  python3-gi   3.30.4-1
ii  python3-gi-cairo 3.30.4-1
ii  python3-mygpoclient  1.8-2
ii  python3-podcastparser0.6.3-1

Versions of packages gpodder recommends:
pn  gir1.2-ayatanaappindicator3-0.1  
pn  python3-eyed3
ii  python3-html5lib 1.0.1-1
ii  python3-simplejson   3.16.0-1

Versions of packages gpodder suggests:
pn  gnome-bluetooth | bluez-gnome  
pn  mplayer

-- no debconf information

Bug#812512: [Pkg-utopia-maintainers] Bug#812512: pkexec tty hijacking via TIOCSTI ioctl

[Michael Biebl]

Am 13.06.2021 um 04:24 schrieb argv minus one:
Upstream has decided not to fix this vulnerability [1]. Apparently 
they're using a Linux kernel patch that makes TIOCSTI require 
CAP_SYS_ADMIN [2]


[2] https://bugzilla.redhat.com/show_bug.cgi?id=1299955#c1 



Hm, I'm not seeing a patch there. Do you maybe have link to this kernel 
patch?


Regards,
Michael

Bug#989795: unblock: ogdi-dfsg/4.1.0+ds-4 (pre-approval)

[Sebastian Ramacher]

Control: tags -1 confirmed moreinfo

On 2021-06-13 15:03:18 +0200, Bas Couwenberg wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: unblock
> 
> Please unblock package ogdi-dfsg
> 
> [ Reason ]
> It fixes #989790 which should help with upgrades from 3.2.
> 
> [ Impact ]
> More troublesome distribution upgrade.
> 
> [ Tests ]
> N/A
> 
> [ Risks ]
> Dependency of key package (gdal).
> 
> [ Checklist ]
>   [x] all changes are documented in the d/changelog
>   [x] I reviewed all changes and I approve them
>   [x] attach debdiff against the package in testing
> 
> [ Other info ]
> N/A
> 
> unblock ogdi-dfsg/4.1.0+ds-4

Thanks, please go ahead and remove the moreinfo tag once the package is
available in unstable.

Cheers

> 
> 
> Kind Regards,
> 
> Bas

> diff -Nru ogdi-dfsg-4.1.0+ds/debian/changelog 
> ogdi-dfsg-4.1.0+ds/debian/changelog
> --- ogdi-dfsg-4.1.0+ds/debian/changelog   2020-11-12 06:04:54.0 
> +0100
> +++ ogdi-dfsg-4.1.0+ds/debian/changelog   2021-06-13 14:55:48.0 
> +0200
> @@ -1,3 +1,14 @@
> +ogdi-dfsg (4.1.0+ds-4) unstable; urgency=medium
> +
> +  * Team upload.
> +  * Bump Standards-Version to 4.5.1, no changes.
> +  * Mark patches as Applied-Upstream.
> +  * Update watch file for GitHub URL changes.
> +  * Use version specific modules path.
> +(closes: #989790)
> +
> + -- Bas Couwenberg   Sun, 13 Jun 2021 14:55:48 +0200
> +
>  ogdi-dfsg (4.1.0+ds-3) unstable; urgency=medium
>  
>* Team upload.
> diff -Nru ogdi-dfsg-4.1.0+ds/debian/control ogdi-dfsg-4.1.0+ds/debian/control
> --- ogdi-dfsg-4.1.0+ds/debian/control 2020-11-12 06:04:54.0 +0100
> +++ ogdi-dfsg-4.1.0+ds/debian/control 2021-06-13 14:12:02.0 +0200
> @@ -8,7 +8,7 @@
> pkg-config,
> tcl-dev (>= 8.4),
> zlib1g-dev
> -Standards-Version: 4.5.0
> +Standards-Version: 4.5.1
>  Vcs-Browser: https://salsa.debian.org/debian-gis-team/ogdi-dfsg
>  Vcs-Git: https://salsa.debian.org/debian-gis-team/ogdi-dfsg.git
>  Homepage: http://ogdi.sourceforge.net/
> diff -Nru ogdi-dfsg-4.1.0+ds/debian/libogdi4.1.dirs 
> ogdi-dfsg-4.1.0+ds/debian/libogdi4.1.dirs
> --- ogdi-dfsg-4.1.0+ds/debian/libogdi4.1.dirs 2020-11-12 06:04:54.0 
> +0100
> +++ ogdi-dfsg-4.1.0+ds/debian/libogdi4.1.dirs 2021-06-13 14:17:54.0 
> +0200
> @@ -1 +1 @@
> -usr/lib
> +usr/lib/ogdi/4.1
> diff -Nru ogdi-dfsg-4.1.0+ds/debian/libogdi4.1.install 
> ogdi-dfsg-4.1.0+ds/debian/libogdi4.1.install
> --- ogdi-dfsg-4.1.0+ds/debian/libogdi4.1.install  2020-11-12 
> 06:04:54.0 +0100
> +++ ogdi-dfsg-4.1.0+ds/debian/libogdi4.1.install  2021-06-13 
> 14:12:37.0 +0200
> @@ -1,3 +1,3 @@
>  usr/lib/libogdi.so.*
>  usr/lib/libvpf.so.*
> -usr/lib/ogdi/*.sousr/lib/ogdi
> +usr/lib/ogdi/*.sousr/lib/ogdi/4.1
> diff -Nru ogdi-dfsg-4.1.0+ds/debian/libogdi4.1.lintian-overrides 
> ogdi-dfsg-4.1.0+ds/debian/libogdi4.1.lintian-overrides
> --- ogdi-dfsg-4.1.0+ds/debian/libogdi4.1.lintian-overrides2020-11-12 
> 06:04:54.0 +0100
> +++ ogdi-dfsg-4.1.0+ds/debian/libogdi4.1.lintian-overrides2021-06-13 
> 14:24:33.0 +0200
> @@ -1,3 +1,3 @@
>  # False positive, string not included in the source.
> -spelling-error-in-binary usr/lib/ogdi/libvrf.so "allow to" "allow one to"
> +spelling-error-in-binary usr/lib/ogdi/*/libvrf.so "allow to" "allow one to"
>  
> diff -Nru ogdi-dfsg-4.1.0+ds/debian/patches/hardening 
> ogdi-dfsg-4.1.0+ds/debian/patches/hardening
> --- ogdi-dfsg-4.1.0+ds/debian/patches/hardening   2020-11-12 
> 06:04:54.0 +0100
> +++ ogdi-dfsg-4.1.0+ds/debian/patches/hardening   2020-11-12 
> 11:50:24.0 +0100
> @@ -1,6 +1,7 @@
>  Description: Include hardening buidflags from the environment.
>  Author: Bas Couwenberg 
>  Forwarded: https://github.com/libogdi/ogdi/pull/18
> +Applied-Upstream: 
> https://github.com/libogdi/ogdi/commit/408d7fb49de714aa0f5833ed4bb40404bee3e6bd
>  
>  --- a/config/unix.mak
>  +++ b/config/unix.mak
> diff -Nru ogdi-dfsg-4.1.0+ds/debian/patches/hurd 
> ogdi-dfsg-4.1.0+ds/debian/patches/hurd
> --- ogdi-dfsg-4.1.0+ds/debian/patches/hurd2020-11-12 06:04:54.0 
> +0100
> +++ ogdi-dfsg-4.1.0+ds/debian/patches/hurd2020-11-12 11:49:24.0 
> +0100
> @@ -1,6 +1,7 @@
>  Description: Support the GNU Hurd too.
>  Author: Francesco Paolo Lovergine 
>  Forwarded: https://github.com/libogdi/ogdi/pull/17
> +Applied-Upstream: 
> https://github.com/libogdi/ogdi/commit/99b78f9738523d23142b36e114d2187d21255eec
>  
>  --- /dev/null
>  +++ b/config/GNU.mak
> diff -Nru ogdi-dfsg-4.1.0+ds/debian/patches/modules_path.patch 
> ogdi-dfsg-4.1.0+ds/debian/patches/modules_path.patch
> --- ogdi-dfsg-4.1.0+ds/debian/patches/modules_path.patch  2020-11-12 
> 06:04:54.0 +0100
> +++ ogdi-dfsg-4.1.0+ds/debian/patches/modules_path.patch  2021-06-13 
> 14:14:04.0 +0200
> @@ -9,7 +9,7 @@
>   $(EXPAT_INCLUDE)
>   
>  

Bug#989789: RM: sogo-connector/68.0.1-2

[Sebastian Ramacher]

Control: clone -1 -2
Control: retitle -2 RM: sogo-connector/68.0.1-2~deb10u1
Control: tags -2 buster

On 2021-06-13 09:10:48 +0200, Carsten Schoenert wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: rm
> 
> Hi,
> please remove the sogo-connector package from testing and stable.
> The current version of sogo-connector isn't usable with any recent
> version of thunderbird in both releases.
> 
> I was hoping upstream would release an updated new version compatible to
> the newer plugin API but until today this didn't happen. So it makes no
> sense to ship a version of sogo-connector that is not working with
> thunderbird.
> 
> I requested the removal from unstable by filing #989788.

I'm cloning the bug to track its status for buster separately.

Cheers

> 
> Regards
> Carsten
> 

-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#989796: RM: sogo-connector/68.0.1-2~deb10u1

[Sebastian Ramacher]

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

(explain the reason for the removal here)

-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#989795: unblock: ogdi-dfsg/4.1.0+ds-4 (pre-approval)

[Bas Couwenberg]

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

Please unblock package ogdi-dfsg

[ Reason ]
It fixes #989790 which should help with upgrades from 3.2.

[ Impact ]
More troublesome distribution upgrade.

[ Tests ]
N/A

[ Risks ]
Dependency of key package (gdal).

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

[ Other info ]
N/A

unblock ogdi-dfsg/4.1.0+ds-4


Kind Regards,

Bas
diff -Nru ogdi-dfsg-4.1.0+ds/debian/changelog 
ogdi-dfsg-4.1.0+ds/debian/changelog
--- ogdi-dfsg-4.1.0+ds/debian/changelog 2020-11-12 06:04:54.0 +0100
+++ ogdi-dfsg-4.1.0+ds/debian/changelog 2021-06-13 14:55:48.0 +0200
@@ -1,3 +1,14 @@
+ogdi-dfsg (4.1.0+ds-4) unstable; urgency=medium
+
+  * Team upload.
+  * Bump Standards-Version to 4.5.1, no changes.
+  * Mark patches as Applied-Upstream.
+  * Update watch file for GitHub URL changes.
+  * Use version specific modules path.
+(closes: #989790)
+
+ -- Bas Couwenberg   Sun, 13 Jun 2021 14:55:48 +0200
+
 ogdi-dfsg (4.1.0+ds-3) unstable; urgency=medium
 
   * Team upload.
diff -Nru ogdi-dfsg-4.1.0+ds/debian/control ogdi-dfsg-4.1.0+ds/debian/control
--- ogdi-dfsg-4.1.0+ds/debian/control   2020-11-12 06:04:54.0 +0100
+++ ogdi-dfsg-4.1.0+ds/debian/control   2021-06-13 14:12:02.0 +0200
@@ -8,7 +8,7 @@
pkg-config,
tcl-dev (>= 8.4),
zlib1g-dev
-Standards-Version: 4.5.0
+Standards-Version: 4.5.1
 Vcs-Browser: https://salsa.debian.org/debian-gis-team/ogdi-dfsg
 Vcs-Git: https://salsa.debian.org/debian-gis-team/ogdi-dfsg.git
 Homepage: http://ogdi.sourceforge.net/
diff -Nru ogdi-dfsg-4.1.0+ds/debian/libogdi4.1.dirs 
ogdi-dfsg-4.1.0+ds/debian/libogdi4.1.dirs
--- ogdi-dfsg-4.1.0+ds/debian/libogdi4.1.dirs   2020-11-12 06:04:54.0 
+0100
+++ ogdi-dfsg-4.1.0+ds/debian/libogdi4.1.dirs   2021-06-13 14:17:54.0 
+0200
@@ -1 +1 @@
-usr/lib
+usr/lib/ogdi/4.1
diff -Nru ogdi-dfsg-4.1.0+ds/debian/libogdi4.1.install 
ogdi-dfsg-4.1.0+ds/debian/libogdi4.1.install
--- ogdi-dfsg-4.1.0+ds/debian/libogdi4.1.install2020-11-12 
06:04:54.0 +0100
+++ ogdi-dfsg-4.1.0+ds/debian/libogdi4.1.install2021-06-13 
14:12:37.0 +0200
@@ -1,3 +1,3 @@
 usr/lib/libogdi.so.*
 usr/lib/libvpf.so.*
-usr/lib/ogdi/*.so  usr/lib/ogdi
+usr/lib/ogdi/*.so  usr/lib/ogdi/4.1
diff -Nru ogdi-dfsg-4.1.0+ds/debian/libogdi4.1.lintian-overrides 
ogdi-dfsg-4.1.0+ds/debian/libogdi4.1.lintian-overrides
--- ogdi-dfsg-4.1.0+ds/debian/libogdi4.1.lintian-overrides  2020-11-12 
06:04:54.0 +0100
+++ ogdi-dfsg-4.1.0+ds/debian/libogdi4.1.lintian-overrides  2021-06-13 
14:24:33.0 +0200
@@ -1,3 +1,3 @@
 # False positive, string not included in the source.
-spelling-error-in-binary usr/lib/ogdi/libvrf.so "allow to" "allow one to"
+spelling-error-in-binary usr/lib/ogdi/*/libvrf.so "allow to" "allow one to"
 
diff -Nru ogdi-dfsg-4.1.0+ds/debian/patches/hardening 
ogdi-dfsg-4.1.0+ds/debian/patches/hardening
--- ogdi-dfsg-4.1.0+ds/debian/patches/hardening 2020-11-12 06:04:54.0 
+0100
+++ ogdi-dfsg-4.1.0+ds/debian/patches/hardening 2020-11-12 11:50:24.0 
+0100
@@ -1,6 +1,7 @@
 Description: Include hardening buidflags from the environment.
 Author: Bas Couwenberg 
 Forwarded: https://github.com/libogdi/ogdi/pull/18
+Applied-Upstream: 
https://github.com/libogdi/ogdi/commit/408d7fb49de714aa0f5833ed4bb40404bee3e6bd
 
 --- a/config/unix.mak
 +++ b/config/unix.mak
diff -Nru ogdi-dfsg-4.1.0+ds/debian/patches/hurd 
ogdi-dfsg-4.1.0+ds/debian/patches/hurd
--- ogdi-dfsg-4.1.0+ds/debian/patches/hurd  2020-11-12 06:04:54.0 
+0100
+++ ogdi-dfsg-4.1.0+ds/debian/patches/hurd  2020-11-12 11:49:24.0 
+0100
@@ -1,6 +1,7 @@
 Description: Support the GNU Hurd too.
 Author: Francesco Paolo Lovergine 
 Forwarded: https://github.com/libogdi/ogdi/pull/17
+Applied-Upstream: 
https://github.com/libogdi/ogdi/commit/99b78f9738523d23142b36e114d2187d21255eec
 
 --- /dev/null
 +++ b/config/GNU.mak
diff -Nru ogdi-dfsg-4.1.0+ds/debian/patches/modules_path.patch 
ogdi-dfsg-4.1.0+ds/debian/patches/modules_path.patch
--- ogdi-dfsg-4.1.0+ds/debian/patches/modules_path.patch2020-11-12 
06:04:54.0 +0100
+++ ogdi-dfsg-4.1.0+ds/debian/patches/modules_path.patch2021-06-13 
14:14:04.0 +0200
@@ -9,7 +9,7 @@
$(EXPAT_INCLUDE)
  
 -CFLAGS= $(INCLUDES) $(COMMON_CFLAGS) 
-DMODULES_PATH="\"$(INST_LIB)/ogdi/\""
-+CFLAGS= $(INCLUDES) $(COMMON_CFLAGS) 
-DMODULES_PATH="\"/usr/lib/ogdi/\""
++CFLAGS= $(INCLUDES) $(COMMON_CFLAGS) 
-DMODULES_PATH="\"/usr/lib/ogdi/4.1/\""
  
  LINK_LIBS= $(RPC_LINKLIB) $(ZLIB_LINKLIB) $(EXPAT_LINKLIB) $(WIN_LINKLIB) \
$(MATH_LINKLIB)
diff -Nru ogdi-dfsg-4.1.0+ds/debian/patches/spelling-errors 

Bug#989790: libogdi4.1: rename plugin files to include the SOVERSION

[Sebastian Ramacher]

On 2021-06-13 14:08:21 +0200, Sebastiaan Couwenberg wrote:
> On 6/13/21 12:02 PM, Sebastian Ramacher wrote:
> > On 2021-06-13 11:53:00 +0200, Sebastiaan Couwenberg wrote:
> >> On 6/13/21 11:36 AM, Sebastian Ramacher wrote:
> >>> "If your package contains files whose names do not change with each
> >>> change in the library shared object version, you must not put them in
> >>> the shared library package."
> >>
> >> The files should no included in libogdi4.1:
> >>
> >>  "you must not put them in the shared library package"
> > 
> > It's fine if the paths are versioned in the same way.
> 
> There is no versioning of the path.
> 
> >> The plugins should move to the libogdi-plugins package.
> >> One question: are the plugins required for libogdi4.1 to be useful?
> 
> I think so. I don't really use ogdi, I only maintain the package because
> its a dependency of gdal.
> 
> > If
> > so, that would require a Depends from libogdi4.1 on libogdi-plugins and
> > breaking coinstallability once again. In that case, the libogdi-plugins
> > package also needs to be versioned and the paths will need to be
> > versioned again.
> 
> Since the path of the modules are unversioned, the package name
> shouldn't be either.

I'd argue that's the bug. The path of the modules should be have been
versioned in the first place. With what you describe below, they are
tightly coupbled to libogdi.

> Having Breaks/Replace should suffice:
> 
>  Package: libogdi4.1
>  Architecture: any
>  Depends: libogdi-modules (= ${binary:Version}),
>   ${shlibs:Depends},
>   ${misc:Depends}
>  Suggests: ogdi-bin
>  Breaks: libogdi3.2 (<< 4.0.0)
>  Replaces: libogdi3.2 (<< 4.0.0)
>  [...]
> 
>  Package: libogdi-modules
>  Architecture: any
>  Depends: ${shlibs:Depends},
>   ${misc:Depends}
>  Breaks: libogdi3.2 (<< 4.0.0),
>  libogdi4.0 (<< 4.1.0),
>  libogdi4.1 (<< 4.1.0+ds-4~)
>  Replaces: libogdi3.2 (<< 4.0.0),
>libogdi4.0 (<< 4.1.0),
>libogdi4.1 (<< 4.1.0+ds-4~)
>  [...]

No, please no. The goal is to have libogdi3.2 and libogdi4.1
co-installable.

> 
> I don't want to diverge further from upstream, the buildsystem is hacked
> enough as it is. The packaging per the above should be policy compliant.

It might follow the letter, but not the spirit. The goal of this section
is to have shared library packages co-installable to make upgrades
easier. The above doesn't achieve that.

> 
> But is seems that the modules require libogdi, the dependency gets set
> via shlib:Depends which introduces a circular dependency:
> 
>  intra-source-package-circular-dependency libogdi-modules libogdi4.1
> 
> Splitting the modules out into a separate package may not be such a good
> idea after all.

ACK

> The module path is built into libogdi via
> 
>  -DMODULES_PATH="\"$(INST_LIB)/ogdi/\""
> 
> And is used by ecs_OpenDynamicLib() to dlopen() the modules.
> 
> I guess we'll have to patch the makefile to use:
> 
>  -DMODULES_PATH="\"$(INST_LIB)/ogdi/4.1/\""

Let's do that instead, please.

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#744941: Processed: reassigning to debian-i18n

[Helge Kreutzmann]

Moin,

arbeitet hier noch jemand beim DDTP mit? Falls ja, wäre ich für die
Übernahme der Korrektur sehr dankbar.

On Sun, Feb 28, 2021 at 09:39:54AM +0100, Helge Kreutzmann wrote:
> Hello,
> forwarding to debian-l10n-german, the rest is in German.
> 
> On Sun, Feb 28, 2021 at 08:06:03AM +, Debian Bug Tracking System wrote:
> > > reassign 744941 debian-i18n
> > Bug #744941 [gnunet] peer-to-peer ain't "gleichberechtigte Netze"
> > Bug reassigned from package 'gnunet' to 'debian-i18n'.
> > Ignoring request to alter found versions of bug #744941 to the same values 
> > previously set
> > Ignoring request to alter fixed versions of bug #744941 to the same values 
> > previously set
> > > retitle 744941 DDTP gnunet: improve German translation
> > Bug #744941 [debian-i18n] peer-to-peer ain't "gleichberechtigte Netze"
> > Changed Bug title to 'DDTP gnunet: improve German translation' from 
> > 'peer-to-peer ain't "gleichberechtigte Netze"'.
> > > thanks
> > Stopping processing here.
> 
> Kann sich einer der beim DDTP aktiven Übersetzer die Übersetzung der
> Paketbeschreibung von „gnunet“ mal vornehmen und
> überarbeiten/korrigieren?
> 
> Gerne kann die Übersetzung auch zum Korrekturlesen auf
> debian-l10n-german@l.d.o verteilt werden.
> 
> Wenn das erledigt ist, bitte Debian-Fehler #744941 in der
> Fehlerdatenbank durch eine E-Mail an 744941-d...@bugs.debian.org
> schließen.

Mir mit auf Testing wird die Beschreibung derzeit auf Englisch
dargestellt.

Viele Grüße

 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#989790: libogdi4.1: rename plugin files to include the SOVERSION

[Sebastiaan Couwenberg]

On 6/13/21 12:02 PM, Sebastian Ramacher wrote:
> On 2021-06-13 11:53:00 +0200, Sebastiaan Couwenberg wrote:
>> On 6/13/21 11:36 AM, Sebastian Ramacher wrote:
>>> "If your package contains files whose names do not change with each
>>> change in the library shared object version, you must not put them in
>>> the shared library package."
>>
>> The files should no included in libogdi4.1:
>>
>>  "you must not put them in the shared library package"
> 
> It's fine if the paths are versioned in the same way.

There is no versioning of the path.

>> The plugins should move to the libogdi-plugins package.
>> One question: are the plugins required for libogdi4.1 to be useful?

I think so. I don't really use ogdi, I only maintain the package because
its a dependency of gdal.

> If
> so, that would require a Depends from libogdi4.1 on libogdi-plugins and
> breaking coinstallability once again. In that case, the libogdi-plugins
> package also needs to be versioned and the paths will need to be
> versioned again.

Since the path of the modules are unversioned, the package name
shouldn't be either. Having Breaks/Replace should suffice:

 Package: libogdi4.1
 Architecture: any
 Depends: libogdi-modules (= ${binary:Version}),
  ${shlibs:Depends},
  ${misc:Depends}
 Suggests: ogdi-bin
 Breaks: libogdi3.2 (<< 4.0.0)
 Replaces: libogdi3.2 (<< 4.0.0)
 [...]

 Package: libogdi-modules
 Architecture: any
 Depends: ${shlibs:Depends},
  ${misc:Depends}
 Breaks: libogdi3.2 (<< 4.0.0),
 libogdi4.0 (<< 4.1.0),
 libogdi4.1 (<< 4.1.0+ds-4~)
 Replaces: libogdi3.2 (<< 4.0.0),
   libogdi4.0 (<< 4.1.0),
   libogdi4.1 (<< 4.1.0+ds-4~)
 [...]

I don't want to diverge further from upstream, the buildsystem is hacked
enough as it is. The packaging per the above should be policy compliant.

But is seems that the modules require libogdi, the dependency gets set
via shlib:Depends which introduces a circular dependency:

 intra-source-package-circular-dependency libogdi-modules libogdi4.1

Splitting the modules out into a separate package may not be such a good
idea after all. The module path is built into libogdi via

 -DMODULES_PATH="\"$(INST_LIB)/ogdi/\""

And is used by ecs_OpenDynamicLib() to dlopen() the modules.

I guess we'll have to patch the makefile to use:

 -DMODULES_PATH="\"$(INST_LIB)/ogdi/4.1/\""

And move the files there.

Kind Regards,

Bas

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

Bug#893912:

[vladikcomper]

Hello,

I have RTL8821AE, and according to my tests, the device functions
perfectly without "rtl_bt/rtl8821a_config.bin" firmware. So I believe
trying to symlink different firmware to this file for the sake of just
bypassing the error message alone can be unnecessary and harmful.

It appears that this specific firmware isn't provided by the
manufacturer and is missing in the latest Linux kernel at the time of
writing (please check:
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/rtl_bt).


For anyone getting other missing firmware errors regarding the
RTL8821AE device, like "rtl_bt/rtl8821a_fw.bin", please install the
"firmware-realtek" package (make sure to add "non-free" component to
your sources list to make this available).


Some Debian desktop installations seem to misconfigure PulseAudio,
which may result in failing to negotiate connection with Bluetooth
speakers/headphones even when your Bluetooth adapter is fully
functional. The symptom of this problem is usually a "Connection
Failed: Protocol not available" message.
To work around this problem, make sure "pulseaudio-module-bluetooth"
is installed, then run the following:

pactl load-module module-bluetooth-discover


Best regards,
Vladislav

Bug#987874: [pre-approval] unblock: osspd/1.3.2-12

[Ralf Jung]

Hi Simon,


On Thu, 10 Jun 2021 at 17:27:48 +0200, Paul Gevers wrote:

If you really think another upload is too much hassle, you could
convince us to unblock regardless if you build twice and show with
diffoscope that the compat bump doesn't impact the (binary) packages at all.


I'm not the maintainer, but I'd like to see osspd get into bullseye:
it's good to have around for the benefit of old binary-only games,
some of which are supported by game-data-packager.

Unfortunately the compat bump from 9 to 13 does make a difference to the
built binaries (mostly due to the addition of dh_dwz and the switch from
dh_installinit to dh_systemd for systemd units, I think).

Ralf, would you accept an NMU with the compat level bump reverted?


Sure. I don't know what the process is for this, but if you want to fix osspd in
bullseye, feel free to do whatever is necessary, and then please let me know 
what I have to do to get the compat-level-13 version back into unstable after 
the bullseye release. :)


Kind regards,
Ralf

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

[Sebastian Ramacher]

On 2021-06-13 11:30:47 +0200, Sebastiaan Couwenberg wrote:
> On 6/13/21 11:12 AM, Sebastian Ramacher wrote:
> > On 2021-06-13 10:58:19 +0200, Andreas Beckmann wrote:
> >> On 13/06/2021 06.45, Sebastiaan Couwenberg wrote:
> >>> On 6/12/21 10:23 PM, Sebastian Ramacher wrote:
>  I have unblocked gdal.
> >>>
> >>> Thanks, libgdal (3.2.2-1) will need to be unblocked as well, it goes
> >>
> >> libgdal-grass ?
> >>
> >>> hand in hand with gdal (3.2.2+dfsg-1). libgdal needs the same upstream
> >>> version of gdal to build successfully.
> >>>
>  Please go ahead with an upload adding a gdal3-data binary package.
> >>>
> >>> That's much more invasive as suggested in #986975 as it will need to
> >>> pass NEW in addition to an unblock.
> >>
> >> And it does not really help, since it just uncovers that there are more
> >> dependencies on not co-installable libraries: libogdi3.2/libogdi4.1 due to
> >> plugins in unversioned paths. Theoretically fixable as well by moving the
> >> plugins to a versioned path. Not sure what would show up next.
> > 
> > libogdi4.1 also needs an RC bug filed. It fails to meet a MUST
> > requirement from 8.2 of the policy. Sorry, but I'm not interessted in
> > papering over issuse that those packages introduce themselves by
> > breaking co-installability and violating policy.
> 
> The ogdi build system is quite shit (it doesn't support DESTDIR for
> example), changing the plugin pth is probably not a good idea. Moving
> them to a separate package seems like the only right thing to do based
> on the policy wording. But the package will have to pass NEW again,
> which is also quite shit at this stage of the release.

Well, that does not speak for the quality of ogdi-dfsg. If the build
system is already that bad, is the C code of the same quality? In any
case, a bug in an upstream build system does not excempt the package
from following the policy for shared libraries.

Cheers

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

-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#989794: please mention that run-parts executes files sequentially

[Tomas Pospisek]

Package: debianutils
Version: 4.11.2
Severity: wishlist
Tags: patch

See attached patch

Thanks for maintaining debuanutils!
*t

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

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

Versions of packages debianutils depends on:
ii  libc6  2.28-10

debianutils recommends no packages.

debianutils suggests no packages.

-- no debconf information
--- run-parts.8 2021-06-13 11:53:21.513440149 +0200
+++ run-parts.8 2020-08-19 15:11:17.0 +0200
@@ -39,10 +39,10 @@
 If the \-\-regex option is given, the names must match the custom
 extended regular expression specified as that option's argument.
 
-Files are run sequentially, one after the other, in the lexical sort
-order (according to the C/POSIX locale character collation rules) of
-their names unless the \-\-reverse option is given, in which case
-they are run in the opposite order.
+Files are run in the lexical sort order (according to the C/POSIX
+locale character collation rules) of their names unless the
+\-\-reverse option is given, in which case they are run in the
+opposite order.
 
 .SH OPTIONS
 .TP

Bug#506033: libscotchmetis-dev: Please add METIS_PartMesh* functions

[Drew Parsons]

Package: libscotchmetis-dev
Followup-For: Bug #506033

Checking the status of this bug, METIS_PartMesh* is still absent from
SCOTCH_Metis.

As far as METIS_WPartGraphKway and METIS_mCPartGraphKway go, 
these functions do not exist in metis 5.1.0. There is only
METIS_PartGraphKway and METIS_PartGraphRecursive, which are already
supported in SCOTCH.

I can see METIS_WPartGraphKway in old metis 3.0.6 source,
and I can see METIS_mCPartGraphKway in metis 4.0.3, but neither are
present in metis 5.1.0.

It is my intention after the bullseye release to start configuring
SCOTCH with SCOTCH_METIS_VERSION=5 (Bug#989783), to better match our
version of libmetis-dev.

Bug#989793: please mention that run-parts executes files sequentially

[Tomas Pospisek]

Package: debianutils
Version: 4.11.2
Severity: wishlist
Tags: patch



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

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

Versions of packages debianutils depends on:
ii  libc6  2.28-10

debianutils recommends no packages.

debianutils suggests no packages.

-- no debconf information
--- run-parts.8.new 2021-06-13 11:53:21.513440149 +0200
+++ run-parts.8 2020-08-19 15:11:17.0 +0200
@@ -39,10 +39,10 @@
 If the \-\-regex option is given, the names must match the custom
 extended regular expression specified as that option's argument.
 
-Files are run sequentially, one after the other, in the lexical sort
-order (according to the C/POSIX locale character collation rules) of
-their names unless the \-\-reverse option is given, in which case
-they are run in the opposite order.
+Files are run in the lexical sort order (according to the C/POSIX
+locale character collation rules) of their names unless the
+\-\-reverse option is given, in which case they are run in the
+opposite order.
 
 .SH OPTIONS
 .TP

Bug#989792: dqlite assumes a kernel configured with 4kB page size

[Adrian Bunk]

Source: dqlite
Version: 1.6.0-2
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/logs.php?pkg=dqlite=mips64el

...
lib_buffer/init/n_pages [ ERROR ]
Error: test/unit/lib/test_buffer.c:73: assertion failed: f->buffer.page_size == 
4096 (16384 == 4096)
Error: child killed by signal 6 (Aborted)
...
gateway/query/large [ ERROR ]
Error: test/unit/test_gateway.c:1023: assertion failed: f->response.eof == 
0x (1 == 17216961135462248174)
Error: child killed by signal 6 (Aborted)
gateway/query/params[ OK] [ 
0.00119151 / 0.00119169 CPU ]
gateway/query/interrupt [ ERROR ]
Error: test/unit/test_gateway.c:1113: assertion failed: f->response.eof == 
0x (1 == 17216961135462248174)
Error: child killed by signal 6 (Aborted)
...


4kB page size is not supported in the kernel for the hardware used by
mipsel-manda-0{4,5}, these kernels provided by src:linux also for our
users have 16 kB page size.

ppd64el buildd has a kernel with 64 kB page size.

Since Canonical is upstream, I'll mention that such assumptions are
also a problem with the 64k page size kernel images they provide as
an alternative for arm64.

src/lib/buffer.c does sysconf(_SC_PAGESIZE) so this might be a test-only
problem. In this case please ignore test failures since they are currently
failing on some architectures depending on which buildd builds it
(and mipsel-manda-0{4,5} are the first new ones for mips*el that should
 at some point replace all older ones).

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

[Adrian Bunk]

On Sat, Jun 12, 2021 at 04:07:15PM +0100, Samuel Henrique wrote:
> Hello all,
> 
> > The bug is trivial to fix, that's actually less work than all the
> > workarounds.
> 
> I can't see how that's trivial so I would appreciate it if you could
> send a patch or describe what you're thinking of. I had tried a few
> approaches but none of them worked out.

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)]);

> Cheers,

cu
Adrian

Bug#243676: any reason not to add --debug flag?

[Tomas Pospisek]

Hi,

thanks for maintaining debianutils. Is there any reason Christoph Biedl's 
patch to add a --debug flag doesn't get applied? It does look like being 
useful?


?

Greetings & thanks,
*t

Bug#989790: libogdi4.1: rename plugin files to include the SOVERSION

[Sebastian Ramacher]

On 2021-06-13 11:53:00 +0200, Sebastiaan Couwenberg wrote:
> On 6/13/21 11:36 AM, Sebastian Ramacher wrote:
> > "If your package contains files whose names do not change with each
> > change in the library shared object version, you must not put them in
> > the shared library package."
> 
> The files should no included in libogdi4.1:
> 
>  "you must not put them in the shared library package"

It's fine if they paths are versioned in the same way.

> The plugins should move to the libogdi-plugins package.

One question: are the plugins required for libogdi4.1 to be useful? If
so, that would require a Depends from libogdi4.1 on libogdi-plugins and
breaking coinstallability once again. In that case, the libogdi-plugins
package also needs to be versioned and the paths will need to be
versioned again.

Cheers

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

-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#989790: libogdi4.1: rename plugin files to include the SOVERSION

[Sebastiaan Couwenberg]

On 6/13/21 11:36 AM, Sebastian Ramacher wrote:
> "If your package contains files whose names do not change with each
> change in the library shared object version, you must not put them in
> the shared library package."

The files should no included in libogdi4.1:

 "you must not put them in the shared library package"

The plugins should move to the libogdi-plugins package.

Kind Regards,

Bas

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

Bug#989790: libogdi4.1: rename plugin files to include the SOVERSION

[Sebastian Ramacher]

Package: libogdi4.1
Version: 4.1.0+ds-3
Severity: serious
X-Debbugs-Cc: sramac...@debian.org
Justification: Debian Policy 8.2

First sentence of 8.2:

"If your package contains files whose names do not change with each
change in the library shared object version, you must not put them in
the shared library package."

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

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

[Sebastian Ramacher]

On 2021-06-13 11:14:45 +0200, Sebastiaan Couwenberg wrote:
> On 6/13/21 10:58 AM, Andreas Beckmann wrote:
> > On 13/06/2021 06.45, Sebastiaan Couwenberg wrote:
> >> On 6/12/21 10:23 PM, Sebastian Ramacher wrote:
> >>> I have unblocked gdal.
> >>
> >> Thanks, libgdal (3.2.2-1) will need to be unblocked as well, it goes
> > 
> > libgdal-grass ?
> 
> Obviously, yes.
> 
> >> hand in hand with gdal (3.2.2+dfsg-1). libgdal needs the same upstream
> >> version of gdal to build successfully.
> >>
> >>> Please go ahead with an upload adding a gdal3-data binary package.
> >>
> >> That's much more invasive as suggested in #986975 as it will need to
> >> pass NEW in addition to an unblock.
> > 
> > And it does not really help, since it just uncovers that there are more
> > dependencies on not co-installable libraries: libogdi3.2/libogdi4.1 due
> > to plugins in unversioned paths. Theoretically fixable as well by moving
> > the plugins to a versioned path. Not sure what would show up next.
> > 
> >> #986975 just adds Breaks: libgdal20 to libgdal28 for smoother upgrades
> >> from buster, that seems like a reasonable change.
> > 
> > See attached patch. Especially for its very verbose changelog entry ;-)
> 
> A build with the Breaks is running as we speak, if that resolves the
> montiverdi case I'll upload it to unstable, unless you expect more changes.

Please rename the binary package and follow the spirit of Policy 8.2 also with
the data files of gdal.

Cheers

> 
> > We may need to add this Breaks in some more packages since in rare cases
> > old libgdal20 scores higher than libgdal28. But most cases are already
> > covered with libgdal28.
> 
> Kind Regards,
> 
> Bas
> 
> -- 
>  GPG Key ID: 4096R/6750F10AE88D4AF1
> Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1
> 

-- 
Sebastian Ramacher


signature.asc
Description: PGP signature