Bug#990029: konsole: Application and global menu

[Norbert Preining]

> Today, after sturtup, the "new" konsole has preserved both menus, instead the 
> "restored" has again the error.
> Maybe is it some configuration kept from time ago? I don't remenber how many 
> restore has that konsole.

So does that mean that now it works as expected?

> Tell me if you need some information or close the bug.

I was anyway unable to reproduce anything wrt to global menus (never
ever any global menu showed up in my case ;-) so I tend to close this
bug.

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#637076: ProFTPD file uploads and UserOwner

[TJ Saunders]

I believe that the scenario described here:

  http://bugs.proftpd.org/show_bug.cgi?id=4418#c5

might capture/describe this bug, in which case, it would fall under "working as 
expected".

TJ

Bug#990174: unblock: gdal/3.2.2+dfsg-2

[Bas Couwenberg]

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

Please unblock package gdal per the discussion in #989597.

[ Reason ]
It fixes #986975 and the postgis & libmrpt-dev upgrade issues.

[ Impact ]
Issue during distribution upgrade.

[ Tests ]
Upgrade of postgis and libmrpt-dev have been tested in a chroot, see:

 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=989597#184
 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=989597#189

[ Risks ]
Low, while gdal is a key package, if the version hadn't been used in the
UbuntuGIS PPA the Breaks would never have been added.

[ 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 ]
#989597 can be closed as well.

unblock gdal/3.2.2+dfsg-2

Kind Regards,

Bas
diff -Nru gdal-3.2.2+dfsg/debian/changelog gdal-3.2.2+dfsg/debian/changelog
--- gdal-3.2.2+dfsg/debian/changelog2021-03-10 15:12:55.0 +0100
+++ gdal-3.2.2+dfsg/debian/changelog2021-06-21 21:06:09.0 +0200
@@ -1,3 +1,10 @@
+gdal (3.2.2+dfsg-2) unstable; urgency=medium
+
+  * Drop Breaks from gdal-data to make libgdal20 & libgdal28 co-installable.
+(closes: #986975)
+
+ -- Bas Couwenberg   Mon, 21 Jun 2021 21:06:09 +0200
+
 gdal (3.2.2+dfsg-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru gdal-3.2.2+dfsg/debian/control gdal-3.2.2+dfsg/debian/control
--- gdal-3.2.2+dfsg/debian/control  2021-03-10 15:06:40.0 +0100
+++ gdal-3.2.2+dfsg/debian/control  2021-06-21 21:05:55.0 +0200
@@ -193,7 +193,6 @@
 Architecture: all
 Multi-Arch: foreign
 Depends: ${misc:Depends}
-Breaks: libgdal20 (<< 2.5.0~)
 Description: Geospatial Data Abstraction Library - Data files
  GDAL is a translator library for raster geospatial data formats.
  As a library, it presents a single abstract data model to the

Bug#990173: RFP: activitywatch -- automated and extensible privacy-focused time tracker

[Francois Marier]

Package: wnpp
Severity: wishlist

* Package name: activitywatch
  Version : 0.11.0
  Upstream Author : Erik Bjäreholt  and Johan Bjäreholt 

* URL : https://github.com/ActivityWatch/activitywatch
* License : MPL-2.0
  Programming Lang: Python
  Description : automated and extensible privacy-focused time tracker

ActivityWatch is an app that automatically tracks how you spend time on your
devices.

It is open source, privacy-first, cross-platform, and a great alternative to
services like RescueTime, ManicTime, and WakaTime.

It can be used to keep track of your productivity, time spent on different
projects, bad screen habits, or just to understand how you spend your time.

Features
- Tracking: Tracks active application and window title out of the box, more 
with watchers.
- Categories: Get a better overview of your usage by breaking it down into 
categories.
- Browser extensions: Track the active tab using the extensions for Chrome and 
Firefox.
- Editor plugins: Track how you spend time writing code with editor watchers.
- Privacy: Data is stored locally and doesn't leave your device, we put local 
and privacy first.
- Cross-platform: Runs on Windows, macOS, Linux, and Android.

Bug#990167: gdb: dbgsym package contains no debug information libbfd library

[Bernhard Übelacker]

Package: gdb
Version: 10.1-1.7
Severity: wishlist
X-Debbugs-Cc: bernha...@mailbox.org

Dear Maintainer,
while investigating an issue in the test suite of rr-debugger,
I found that the libbfd part of gdb is not built with debug information,
therefore the dbgsym package also lacks this information.

While rebuilding gdb is doable, maybe it would be nice to have this
debug information in the package available.

Below modification added globally the '-g' flag and built me
a package that contained the debug information for libbfd.
But I am certain there is a more targetted place to add this.

Kind regards,
Bernhard



-- System Information:
Debian Release: 11.0
  APT prefers testing-security
  APT policy: (500, 'testing-security'), (500, 'testing-debug'), (500, 
'proposed-updates-debug'), (500, 'testing')

Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-7-amd64 (SMP w/16 CPU threads)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.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 gdb depends on:
ii  libbabeltrace1  1.5.8-1+b3
ii  libc6   2.31-12
ii  libdebuginfod1  0.183-1
ii  libexpat1   2.2.10-2
ii  libgcc-s1   10.2.1-6
ii  libipt2 2.0.3-1
ii  liblzma55.2.5-2
ii  libmpfr64.1.0-3
ii  libncursesw66.2+20201114-2
ii  libpython3.93.9.2-1
ii  libreadline88.1-1
ii  libsource-highlight4v5  3.1.9-3+b1
ii  libstdc++6  10.2.1-6
ii  libtinfo6   6.2+20201114-2
ii  libxxhash0  0.8.0-2
ii  zlib1g  1:1.2.11.dfsg-2

Versions of packages gdb recommends:
ii  libc6-dbg [libc-dbg]  2.31-12

Versions of packages gdb suggests:
pn  gdb-doc
pn  gdbserver  

-- no debconf information








--- orig/gdb-10.1/debian/rules  2021-01-03 11:54:01.0 +0100
+++ try2/gdb-10.1/debian/rules  2021-06-20 23:09:52.391144630 +0200
@@ -8,6 +8,11 @@ include /usr/share/dpkg/architecture.mk
 SOURCE_DATE_EPOCH ?= $(shell dpkg-parsechangelog -SDate | date -f- +%s)
 deb_version := $(shell dpkg-parsechangelog | awk '/^Version:/ {print 
$$2}')


+# Add -g globally (especially libbfd seems to get compiled without -g)
+CFLAGS += -g
+CPPFLAGS += -g
+LDFLAGS += -g
+
 # The top-level configure script fails to pass these down properly ...
 export CPPFLAGS
 export LDFLAGS

Bug#989831: konsole: Bitmap fonts rendered incorrectly if display scaling is enabled

[Norbert Preining]

Hi Tim,

> So e.g. If an application would normally display a graphical element
> with a font which renders at 10 pixels-tall, then when I have a global
> scale set to 150%, instead it would try and use font which renders at 15
> pixels-tall.

Maybe, I am not sure here. Another interpretation is that you asked for
10pt and you will get 10pt, whatever the scaling is.
But let us leave that for now.

> I'm assuming that konsole would select a larger font in this case
> (perhaps it's trying to, but it can't because of #989834, or perhaps the
> rendering pipeline just doesn't allow this sort of decision to be made).

I don't know either. I actually tried to get pixmap fonts working, but
found out they are all disabled on the fontconfig level, and only the
terminus is available because it hides as open type font.

> The thing that gives me eye strain is anti-aliasing (having spoken to an

Ok, but that can be turned off.

> more of a problem for me before I switched to higher resolution
> displays), there is some mention of it in section 3.3 of this paper:

Interesting, thanks for the pointer.

> Vector fonts don't give me eye fatigue when anti-aliasing is disabled,
> and this is a good second best (since konsole includes an option to
> disable this, presumably because this is a reasonably common request).
> 
> Unfortunately with anti-aliasing disabled, the vector fonts look lower
> quality.  e.g. see attachment which shows terminus vs noto mono (from
> konsole screenshots of both typefaces).  The vector fonts are not
> unusable, they're just not as good when rendered like this.

Hmm, this looks a bit like hinting is turned off. I agree that the pixel
font looks better and clearer, but I would expect that this can be
recreated with proper hinting.

> I've found I can workaround this issue by disabling scaling in konsole

Good to hear.

Seriously, I don't really know what to make with that. I really would
like to help you here, but there are lot of parts invovled: freetype,
fontconfig, Qt, konsole, ... and whatever I have forgotten.

I feel with you, since I have really bad eyesight, too, and always need
to adjust fonts and everything to my comfort, but here I am out of
ideas.

I would suggest to submit a bug/issue directly to the konsole tracker of
upstream, and see what the upstream author thinks about and where one
would have to start hunting down better solutions for this.

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#980472: CubicSDR crashes after launch

[Jay]

I'm getting the same thing in Buster, CubicSDR i0.2.5+dfsd-1 nstalled 
from the repo segfaults and crashes. It works in Stretch (my distro is 
MX Linux and the packagers backported the same version of the package 
from Buster to Stretch.) Here's what I found in my kern.log if it helps:


Jun  7 11:42:53 mx-19 kernel: [   61.073127] CubicSDR[14051]: segfault 
at 0 ip  sp 7ffee8b0d1b8 error 14 in 
CubicSDR[55cfefc37000+5f000]
Jun  7 11:42:53 mx-19 kernel: [   61.073136] Code: Unable to access 
opcode bytes at RIP 0xffd6.
Jun  7 13:30:47 mx-19 kernel: [ 6535.733442] CubicSDR[7011]: segfault at 
0 ip  sp 7fffa7f96d18 error 14 in 
CubicSDR[55ce03801000+5f000]
Jun  7 13:30:47 mx-19 kernel: [ 6535.733448] Code: Unable to access 
opcode bytes at RIP 0xffd6.
Jun  7 13:31:38 mx-19 kernel: [ 6586.598155] CubicSDR[8242]: segfault at 
0 ip  sp 7ffed9e721e8 error 14 in 
CubicSDR[556329225000+5f000]
Jun  7 13:31:38 mx-19 kernel: [ 6586.598163] Code: Unable to access 
opcode bytes at RIP 0xffd6.
Jun  7 13:34:41 mx-19 kernel: [ 6769.205850] CubicSDR[10553]: segfault 
at 0 ip  sp 7ffd49e7f138 error 14 in 
CubicSDR[55586877b000+5f000]
Jun  7 13:34:41 mx-19 kernel: [ 6769.205857] Code: Unable to access 
opcode bytes at RIP 0xffd6.

Bug#990172: Autopkgtest failure with OpenLDAP 2.5.5

[Sergio Durigan Junior]

Source: nsscache
Version: 0.42-1
Severity: medium

Dear maintainer,

We're working towards getting OpenLDAP 2.5.5 (already in experimental)
ready to start the transition process, and I noticed that nsscache's
autopkgtest fails because it uses the now-removed BDB backend.

I am also working on the OpenLDAP 2.5.5 transition for Ubuntu, and here
is the full log with the failures if you're interested:

https://autopkgtest.ubuntu.com/results/autopkgtest-impish/impish/amd64/n/nsscache/20210621_230811_7cc47@/log.gz

I also noticed that nsscache has code to deal with BDB; it may be a good
idea to raise this topic with upstream in case they want to update their
codebase.

Thanks,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
https://sergiodj.net/


signature.asc
Description: PGP signature

Bug#990171: unblock: apparmor-profiles-extra/1.34

[Paul Wise]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-CC: apparmor-profiles-ex...@packages.debian.org

Please unblock package apparmor-profiles-extra

[ Reason ]
The autoremoval will be before the fix for RC bug #989193 migrates.

[ Impact ]
The package will not be available in the bullseye release and so
various apps will not have AppArmor security restrictions.

[ Tests ]
The autopkgtests pass for this package migration.

[ Risks ]
The change is a one character addition of the link permission for a
situation where it being missing breaks another package. 
This is a leaf package. No alternatives available.

[ 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 ]
None.

unblock apparmor-profiles-extra/1.34

-- 
bye,
pabs

https://wiki.debian.org/PaulWise
diff -Nru apparmor-profiles-extra-1.33/debian/changelog apparmor-profiles-extra-1.34/debian/changelog
--- apparmor-profiles-extra-1.33/debian/changelog	2021-04-02 19:40:29.0 +0800
+++ apparmor-profiles-extra-1.34/debian/changelog	2021-06-09 14:23:10.0 +0800
@@ -1,3 +1,10 @@
+apparmor-profiles-extra (1.34) unstable; urgency=medium
+
+  * apt-cacher-ng: allow link operations on the contents of the cache directory
+(Closes: #989193). Thanks to Eduard Bloch  for the patch.
+
+ -- intrigeri   Wed, 09 Jun 2021 06:23:10 +
+
 apparmor-profiles-extra (1.33) unstable; urgency=medium
 
   * autopkgtest: use hint-testsuite-triggers to ensure dummy test is not run
diff -Nru apparmor-profiles-extra-1.33/debian/README.Debian apparmor-profiles-extra-1.34/debian/README.Debian
--- apparmor-profiles-extra-1.33/debian/README.Debian	2021-04-02 19:40:29.0 +0800
+++ apparmor-profiles-extra-1.34/debian/README.Debian	2021-06-09 14:23:10.0 +0800
@@ -2,7 +2,7 @@
 =
 
 - apt-cacher-ng: taken from the apparmor-profiles repository
-  at MR !50.
+  at MR !51.
 - GStreamer abstraction: taken from the apparmor-profiles repository
   at MR !49.
 - irssi: taken from the apparmor-profiles repository
@@ -20,4 +20,4 @@
 
 https://gitlab.com/apparmor/apparmor-profiles
 
- -- intrigeri , Fri,  2 Apr 2021 11:19:19 +0200
+ -- intrigeri , Wed,  9 Jun 2021 08:21:51 +0200
diff -Nru apparmor-profiles-extra-1.33/profiles/usr.sbin.apt-cacher-ng apparmor-profiles-extra-1.34/profiles/usr.sbin.apt-cacher-ng
--- apparmor-profiles-extra-1.33/profiles/usr.sbin.apt-cacher-ng	2021-04-02 19:40:29.0 +0800
+++ apparmor-profiles-extra-1.34/profiles/usr.sbin.apt-cacher-ng	2021-06-09 14:23:10.0 +0800
@@ -18,7 +18,7 @@
   /var/lib/apt-cacher-ng/** r,
   /{,var/}run/apt-cacher-ng/* rw,
   @{APT_CACHER_NG_CACHE_DIR}/ r,
-  @{APT_CACHER_NG_CACHE_DIR}/** rw,
+  @{APT_CACHER_NG_CACHE_DIR}/** rwl,
   /var/log/apt-cacher-ng/ r,
   /var/log/apt-cacher-ng/* rw,
   /{,var/}run/systemd/notify w,


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

Bug#765740: Reference Ubuntu implementation

[Omni Flux]

It looks like Ubuntu added multi ESP support here
https://git.launchpad.net/ubuntu/+source/grub2/commit/?id=05a57249548c247c14231ef15348a4ee27217607

It may be something that could be brought to Debian fairly easily.

Bug#990170: gst123: it doesn't play a stream with AAC codec

[Georgi Naplatanov]

Package: gst123
Version: 0.3.5-2+b1
Severity: normal

Dear Maintainer,

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

   * What led up to the situation?
When I try to listen the following AAC stream with Clementine music player or 
gst123 I get an error.
The stream is 
https://bss.neterra.tv/rtplive/veselinaradio_live.stream/chunklist.m3u8
and I am able to play the stream with mpv video player.
The error is "Error: Your GStreamer installation is missing a plug-in."
I deleted content from ~/.cache/gstreamer-1.0/ but this didn't help.


   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

*** End of the template - remove these template lines ***


-- 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/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=en_US:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages gst123 depends on:
ii  gstreamer1.0-plugins-base   1.18.4-2
ii  gstreamer1.0-plugins-good   1.18.4-2
ii  libc6   2.31-12
ii  libgcc-s1 [libgcc1] 10.2.1-6
ii  libglib2.0-02.66.8-1
ii  libgstreamer-plugins-base1.0-0  1.18.4-2
ii  libgstreamer1.0-0   1.18.4-2
ii  libgtk2.0-0 2.24.33-2
ii  libstdc++6  10.2.1-6
ii  libtinfo6   6.2+20201114-2
ii  libx11-62:1.7.1-1

Versions of packages gst123 recommends:
ii  gstreamer1.0-libav 1.18.4-3
ii  gstreamer1.0-plugins-bad   1.18.4-3
ii  gstreamer1.0-plugins-ugly  1.18.4-2
ii  gstreamer1.0-pulseaudio1.18.4-2
ii  gstreamer1.0-x 1.18.4-2

gst123 suggests no packages.

-- no debconf information

Bug#969376: openafs-client: Openafs cache erros on the logs

[Jose M Calhariz]

Package: openafs-client
Version: 1.8.8pre1-1
Followup-For: Bug #969376

I have tried to package 1.8.8pre1 and compiled for bullseye.


On my first stress test "test_diff" it runs fine until I stopped the
stress test with a ^C.  This is a special machine only to run stress
tests of afs.  So no process are being killed and the errors messages
this time were for the killed stress test.

[Mon Jun 21 21:55:08 2021] afs: failed to write to CacheItems off 12588820 code 
-4/80
[Mon Jun 21 21:55:08 2021] afs: disk cache read error in CacheItems slot 71488 
off 5719060/32500020 code -4/80 pid 3770 (tar)
[Mon Jun 21 21:55:08 2021] afs: Error while alloc'ing cache slot for file 
203:536870928.1326742.311043289; failing with an i/o error
[Mon Jun 21 21:55:08 2021] afs: failed to store file (0/5)

So it was as explained.

Kind regards
Jose M Calhariz



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

Kernel: Linux 5.10.0-7-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_GB.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 openafs-client depends on:
ii  debconf [debconf-2.0]  1.5.75
ii  init-system-helpers1.60
ii  libc6  2.31-12
ii  libcrypt1  1:4.4.18-4
ii  libhcrypto4-heimdal7.7.0+dfsg-2
ii  libkrb5-26-heimdal 7.7.0+dfsg-2
ii  libncurses66.2+20201114-2
ii  libroken18-heimdal 7.7.0+dfsg-2
ii  libtinfo6  6.2+20201114-2
ii  lsb-base   11.1.0

Versions of packages openafs-client recommends:
ii  lsof  4.93.2+dfsg-1.1
ii  openafs-modules-dkms  1.8.8pre1-1

Versions of packages openafs-client suggests:
pn  openafs-doc   
ii  openafs-krb5  1.8.6-5

-- debconf information:
* openafs-client/afsdb: true
* openafs-client/fakestat: true
* openafs-client/thiscell: dev.ist.utl.pt
  openafs-client/cell-info:
* openafs-client/cachesize: 1300
* openafs-client/dynroot: No
* openafs-client/crypt: true
* openafs-client/run-client: true

Bug#989193: fixed in apparmor-profiles-extra 1.34

[Paul Wise]

On Wed, 09 Jun 2021 07:18:32 + intrigeri wrote:

>* apt-cacher-ng: allow link operations on the contents of the cache 
> directory
>  (Closes: #989193). Thanks to Eduard Bloch  for the patch.

Here is a little bump to postpone the autoremoval so the fix gets into testing.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#990129: libqt5core5a: breaks work of some QtWebEngine based programs

[Lisandro Damián Nicanor Pérez Meyer]

Control: tag -1 moreinfo

Hi Boris!

On Mon, 21 Jun 2021 at 10:00, Boris Pek  wrote:
>
> Package: libqt5core5a
> Version: 5.15.2+dfsg-6
> Severity: important
> X-Debbugs-Cc: tehnic...@yandex.ru
>
>
> Hi,
>
> I use Debian 11 (Bullseye) on work PC to develop Qt based projects. All worked
> fine until update of Qt packages last week: one of our QML based application
> stopped showing maps without any errors in stdin/stdout.
>
> Today I spent few hours to find the root of problem. QtWebEngine is used for
> displaying maps and it is quite problematic itself, but I was surprised to 
> find
> what problem was caused by update in QtCore library:
> libqt5core5a:amd64 (5.15.2+dfsg-5, 5.15.2+dfsg-6)
>
> And if I understand correctly here is the problematic patch:
> https://salsa.debian.org/qt-kde-team/qt/qtbase/-/commit/5eaeb73
>
> Could you revert it please?

Not without knowing the root reason of why you are seeing that
behaviour.  The patch comes from upstream, so there are at least two
possibilities:

1) the patch is wrong.
2) the code you run uses the bug fixed in that patch as a feature.

In other words: how can we know the bug is in qtcore or on your app?
Of course if you can find why the patch is wrong I'll be happy to
revert it.

-- 
Lisandro Damián Nicanor Pérez Meyer
https://perezmeyer.com.ar/

Bug#990121: osspd: revert debhelper compat bump to get #986662 fixed in bullseye

[Sébastien Noel]

Hi Simon,
Hi Ralf,

Le lundi 21 juin 2021 à 20:11 +0100, Simon McVittie a écrit :
> On Mon, 21 Jun 2021 at 12:43:43 +0200, Ralf Jung wrote:
> > [...]
> > Those changes were suggested for inclusion by Sébastien (CC'ed). I
> > don't know more about them than what it says in the patch files.
> > They both come from upstream osspd git.
> 
> I'll wait to see what Sébastien says about these, then.

Well, sorry to disappoint you both, but i really have nothing exciting
to say about those :/

GIT-fix-adsp_se.patch seems like it could fix something, but honestly,
even after 20 years of linux gaming (and countless hours of figth with
oss3, alsa, pulseaudio, oss4), i didn't remenber having to deal with
/dev/adsp, so "no", i can't say if it solve a real bug or not :/
(if /dev/adsp is really "alternative DSP/secoundary soundcard", i
really doubt it will be of use in UT99 or another game of that era)

GIT-fix-compiler-warnings.patch is more or less a no-op

Those 2 patches seemed like a good fit for the (very) slow moving
target the osspd package is, but i agree the timing was wrong :/

Best regards,
Sébastien

Bug#990162: power consumption regression

[John]

Package: linux-image-5.10.0-6-amd64
Version: 5.10.28-1

Idle power consumption has increased by 25% from Debian 10.9 to Debian 11.

Possibly a kernel or driver/firmware issue.

Debian 11, updated

# uname -a

Linux mx1 5.10.0-6-amd64 #1 SMP Debian 5.10.28-1 (2021-04-09) x86_64 GNU/Linux

dpkg --list | grep linux-image

ii linux-image-5.10.0-6-amd64 5.10.28-1 amd64 Linux 5.10 for 64-bit PCs (signed)

ii linux-image-amd64 5.10.28-1 amd64 Linux for 64-bit PCs (meta-package)

powertop --auto-tune was executed (tunables at good)

see below for C states output

dpkg --list | grep powertop

ii powertop 2.11-1 amd64 diagnose issues with power consumption and management

processor: Coffee Lake Intel Pentium G5400

One error in dmesg

dmesg: all i915 lines:
[ 2.153980] i915 :00:02.0: [drm] VT-d active for gfx access

[ 2.158236] i915 :00:02.0: vgaarb: deactivate vga console

[ 2.172255] i915 :00:02.0: vgaarb: changed VGA decodes: 
olddecodes=io+mem,decodes=io+mem:owns=io+mem

[ 2.174543] i915 :00:02.0: firmware: failed to load 
i915/kbl_dmc_ver1_04.bin (-2)

[ 2.174551] i915 :00:02.0: Direct firmware load for 
i915/kbl_dmc_ver1_04.bin failed with error -2

[ 2.174553] i915 :00:02.0: [drm] Failed to load DMC firmware 
i915/kbl_dmc_ver1_04.bin. Disabling runtime power management.

[ 2.174554] i915 :00:02.0: [drm] DMC firmware homepage: 
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/i915

[ 2.515706] i915 :00:02.0: [drm] failed to retrieve link info, disabling eDP

[ 2.556098] [drm] Initialized i915 1.6.0 20200917 for :00:02.0 on minor 0

[ 2.558481] snd_hda_intel :00:1f.3: bound :00:02.0 (ops 
i915_audio_component_bind_ops [i915])

[ 2.608536] fbcon: i915drmfb (fb0) is primary device

[ 2.647236] i915 :00:02.0: [drm] fb0: i915drmfb frame buffer device

# lspci | grep -i VGA

00:02.0 VGA compatible controller: Intel Corporation CoffeeLake-S GT1 [UHD 
Graphics 610]

kbl_dmc_ver1_04.bin not found on disk

# find / -name kbl_dmc_ver1_04.bin

# cat /sys/kernel/debug/dri/0/i915_dmc_info

cat /sys/kernel/debug/dri/0/i915_dmc_info

fw loaded: no

path: i915/kbl_dmc_ver1_04.bin

[..]

# cat /sys/kernel/debug/dri/0/i915_params/dmc_firmware_path

cat /sys/kernel/debug/dri/0/i915_params/dmc_firmware_path

(null)

No GUI.

/usr/sbin/powertop

modprobe cpufreq_stats failedLoaded 0 prior measurements

RAPL device for cpu 0

RAPL Using PowerCap Sysfs : Domain Mask f

RAPL device for cpu 0

RAPL Using PowerCap Sysfs : Domain Mask f

Devfreq not enabled

glob returned GLOB_ABORTED

PowerTOP v2.11 Overview Idle stats Frequency stats Device stats Tunables WakeUp

Pkg(HW) | Core(HW) | CPU(OS) 0 CPU(OS) 2

| | C0 active 0.1% 0.1%

| | POLL 0.0% 0.0 ms 0.0% 0.0 ms

| | C1 0.0% 1.6 ms 0.1% 0.7 ms

C2 (pc2) 3.6% | |

C3 (pc3) 0.0% | C3 (cc3) 0.0% | C3 0.0% 0.2 ms 0.0% 0.0 ms

C6 (pc6) 0.0% | C6 (cc6) 0.0% | C6 0.0% 0.8 ms 0.0% 0.1 ms

C7 (pc7) 0.0% | C7 (cc7) 99.4% | C7s 0.0% 0.0 ms 0.0% 0.0 ms

C8 (pc8) 95.2% | | C8 0.3% 2.2 ms 0.3% 1.4 ms

C9 (pc9) 0.0% | | C9 0.0% 3.0 ms 0.1% 4.6 ms

C10 (pc10) 0.0% | |

| | C10 99.3% 129.0 ms 99.3% 122.4 ms

| | C1E 0.2% 3.6 ms 0.1% 1.2 ms

| Core(HW) | CPU(OS) 1 CPU(OS) 3

| | C0 active 0.1% 0.0%

| | POLL 0.0% 0.0 ms 0.0% 0.0 ms

| | C1 0.6% 0.3 ms 0.2% 0.2 ms

| |

| C3 (cc3) 0.0% | C3 0.0% 0.1 ms 0.0% 0.0 ms

| C6 (cc6) 0.0% | C6 0.0% 0.0 ms 0.0% 0.0 ms

| C7 (cc7) 99.3% | C7s 0.0% 0.0 ms 0.0% 0.0 ms

| | C8 0.0% 0.0 ms 0.0% 1.0 ms

| | C9 0.0% 0.0 ms 0.0% 0.0 ms

| |

| | C10 99.3% 159.2 ms 99.7% 220.5 ms

| | C1E 0.0% 0.0 ms 0.0% 0.0 ms

| GPU |

| |

| Powered On 0.0% |

| RC6 100.0% |

| RC6p 0.0% |

| RC6pp 0.0% |

| |

| |

| |

| |

| |

| |

| |

Power est. Usage Device name
0.0% I2C Adapter (i2c-1): i915 gmbus dpb

0.0% I2C Adapter (i2c-4): i915 gmbus dpd

0.0% I2C Adapter (i2c-2): i915 gmbus dpc

0.0% I2C Adapter (i2c-3): i915 gmbus misc

Bug#990158: shim-signed-common: No UEFI boot with error "Could not create MokListXRT"

[Steve McIntyre]

Hi Ayke,

Thanks for your bug report, and apologies for the problem :-/

On Mon, Jun 21, 2021 at 09:00:15PM +0200, Ayke Halder wrote:
>Package: shim-signed-common
>Version: 1.33+15+1533136590.3beb971-7
>Severity: critical
>Justification: breaks the whole system
>
>Dear Maintainer,
>
>## What led up to the situation?
>
>Upgrade:
>
>* shim-signed:amd64 (1.33+15+1533136590.3beb971-7,
>1.36~1+deb10u1+15.4-5~deb10u1)
>* shim-signed-common:amd64 (1.33+15+1533136590.3beb971-7,
>1.36~1+deb10u1+15.4-5~deb10u1)
>
>System: Dell T5600 with BIOS Revision A19
>
>
>## What was the outcome of this action?
>
>System is unbootable on booting via UEFI. System shows error message and then
>powers off immediately:
>
>"Could not create MokListXRT: Out of Resources
>Something has gone seriously wrong: import_mok_state() failed: Out of
>Resources"
>
>
>## What outcome did you expect instead?
>
>A normal booting system loading GRUB.
>
>
>## Also reproducible with Debian Live-Installations-Image
>
>On affected hardware like "Dell T5600" doing a UEFI boot from USB with …
>
>* debian-live-10.10.0-amd64-standard.iso does *not* work.
>* debian-live-10.9.0-amd64-standard.iso works.
>
>
>## Related resources
>
>Might be related to:
>
>* https://bugzilla.suse.com/show_bug.cgi?id=1185261

Yes, it looks like exactly the same problem. :-(

Several of the shim maintainers in various distributions are now
seeing reports like this. It seems that lots of machines are short of
space to store the new MokListXRT variable. Since the buster update
this weekend, yours is the second problem report I've seen.

Ubuntu have a patch to disable the variable mirroring here. I was not
expecting we'd need it, but it looks like I was wrong.

In terms of making your system boot, I'd suggest temporarily one of:

 * switch back to an older shim-signed package
 * disable Secure Boot and remove shim-signed

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"We're the technical experts.  We were hired so that management could
 ignore our recommendations and tell us how to do our jobs."  -- Mike Andrews

Bug#987461: libuima-adapter-soap-java is empty

[tony mancill]

On Tue, Jun 22, 2021 at 07:57:13AM +0900, Hideki Yamane wrote:
> Hi,
> 
> On Mon, 21 Jun 2021 11:52:14 -0700
> tony mancill  wrote:
> > I saw the note in the changelog that Breaks is in fact there to remove
> > the empty package, but it's not happening for me when I try to upgrade
> > locally.  My test case is to install uima-utils (which will install
> > libuima-adapter-soap-java via Recommends) and then try to upgrade the
> > binaries to 2.10.2-4 using dpkg.  
> 
>  Well, it would remove libuima-adapter-soap-java if I've tested it
>  on chroot env as below.
> 
> # apt install /tmp/libuima-core-java_2.10.2-4_all.deb 
> (snip)
> The following packages will be REMOVED:
>   libuima-adapter-soap-java
> The following packages will be upgraded:
>   libuima-core-java
> 1 upgraded, 0 newly installed, 1 to remove and 0 not upgraded.
> Need to get 0 B/1513 kB of archives.
> After this operation, 12.3 kB disk space will be freed.
> 
> 
> > The only way I can make this work is remove libuima-adapter-soap-java
> > manually.  Are you sure that Breaks is necessary?  apt-get autoremove
> > will clean up libuima-adapter-soap-java at some point.
> 
>  Okay, libuima-adapter-soap-java is empty now, just manual autoremove
>  is fine. 

Ah, I should have tested with apt.  I see that it works fine.

> > I took a look at policy to see if Breaks + Replaces should be used in
> > this situation, but I'm not sure it really applies (although I think it
> > would work better than just Breaks).  Still, I'm unsure about the need
> > for Breaks for this empty package clean-up use case.
> 
>  I don't think "Replaces" to be used in this situation since it
>  does not provide any fuctions as same as previous one.

Agreed.

> > Any concerns if I drop the Breaks before the upload?
> 
>  None, please go ahead for bullseye :)

My apologies if using Breaks in this way is a common pattern.  I am
simply not familiar with it.  If you have used the pattern before, I
will upgrade the package as-is, since your way is cleaner.  Otherwise, I
will remove the Breaks.

Thank you for the response.  I will upload once I hear back from you.

Thank you!
tony


signature.asc
Description: PGP signature

Bug#990169: youtube-dl: unable to download video info webpage: 'bool' object has no attribute 'split'

[anvacher]

Package: youtube-dl
Version: 2021.06.06

It does not happen every time. Usually it works just fine but some
videos, this one https://www.youtube.com/watch?v=Pz77_apK7Xs paticularly
causes this error.

I use
/usr/local/bin/youtube-dl/youtube-dl -f 22 --recode-video mp4
--write-info-json --restrict-filenames --write-all-thumbnails
https://www.youtube.com/watch?v=Pz77_apK7Xs > stdout.txt 2> stderr.txt

 stdout.txt contains:
[youtube] Pz77_apK7Xs: Downloading webpage
[youtube] Pz77_apK7Xs: Refetching age-gated info webpage

 stderr.txt contains:
WARNING: unable to download video info webpage: HTTP Error 404: Not Found
Traceback (most recent call last):
  File "/usr/lib/python2.7/runpy.py", line 174, in _run_module_as_main
"__main__", fname, loader, pkg_name)
  File "/usr/lib/python2.7/runpy.py", line 72, in _run_code
exec code in run_globals
  File "/usr/local/bin/youtube-dl/youtube-dl/__main__.py", line 19, in 
  File "/usr/local/bin/youtube-dl/youtube-dl/youtube_dl/__init__.py", line 475, 
in main
  File "/usr/local/bin/youtube-dl/youtube-dl/youtube_dl/__init__.py", line 465, 
in _real_main
  File "/usr/local/bin/youtube-dl/youtube-dl/youtube_dl/YoutubeDL.py", line 
2069, in download
  File "/usr/local/bin/youtube-dl/youtube-dl/youtube_dl/YoutubeDL.py", line 
808, in extract_info
  File "/usr/local/bin/youtube-dl/youtube-dl/youtube_dl/YoutubeDL.py", line 
815, in wrapper
  File "/usr/local/bin/youtube-dl/youtube-dl/youtube_dl/YoutubeDL.py", line 
836, in __extract_info
  File "/usr/local/bin/youtube-dl/youtube-dl/youtube_dl/extractor/common.py", 
line 534, in extract
  File "/usr/local/bin/youtube-dl/youtube-dl/youtube_dl/extractor/youtube.py", 
line 1503, in _real_extract
  File "/usr/local/bin/youtube-dl/youtube-dl/youtube_dl/compat.py", line 2644, 
in compat_parse_qs
  File "/usr/local/bin/youtube-dl/youtube-dl/youtube_dl/compat.py", line 2614, 
in _parse_qsl
AttributeError: 'bool' object has no attribute 'split'

# uname -a
Linux pcname 4.9.0-9-amd64 #1 SMP Debian 4.9.168-1+deb9u3 (2019-06-16) x86_64 
GNU/Linux

# ls -l /lib/*/libc.so.6
lrwxrwxrwx 1 root root 12 Feb  6  2019 /lib/x86_64-linux-gnu/libc.so.6 -> 
libc-2.24.so

# apt show libc6 | grep ^Version
WARNING: apt does not have a stable CLI interface. Use with caution in scripts.
Version: 2.24-11+deb9u4

# reportbug --template -T none -s none -S normal -b --list-cc none -q youtube-dl
Traceback (most recent call last):
  File "/usr/bin/reportbug", line 44, in 
from reportbug import utils
ModuleNotFoundError: No module named 'reportbug'

Bug#942377: /etc/bind/db.root should be removed on upgrades

[Christoph Anton Mitterer]

It's not only the (former) conffile:
 /etc/bind/db.root
that is not properly cleaned up.


Apparently the package also used to contain the conffile:
 /etc/apparmor.d/local/usr.sbin.named
but no longer does so.

Please properly clean them up using dpkg-maintscript-helper(1).
(AFAIU, the version that needs to be specified for that is NOT
the version where the conffile was dropped, but rather "the
latest version of the package whose upgrade should trigger
the operation"

Quoting the manpage:
   For example, for a conffile removed in version 2.0-1 of a package,
   prior-version should be set to 2.0-1~. This will cause the conffile
   to be removed even if the user rebuilt the previous version 1.0-1
   as 1.0-1local1. Or a package switching a path from a symlink
   (shipped in version 1.0-1) to a directory (shipped in version
   2.0-1), but only performing the actual switch in the maintainer
   scripts in version 3.0-1, should set prior-version to 3.0-1~.


Cheers,
Chris.

Bug#990168: ejabberd: legacy conffiles leftover

[Christoph Anton Mitterer]

Package: ejabberd
Version: 21.01-2
Severity: normal


Hi.

Apparently the package used to contain the conffiles:
/etc/default/ejabberd
but no longer does so.

Please properly clean them up using dpkg-maintscript-helper(1).
(AFAIU, the version that needs to be specified for that is NOT
the version where the conffile was dropped, but rather "the
latest version of the package whose upgrade should trigger
the operation"

Quoting the manpage:
   For example, for a conffile removed in version 2.0-1 of a package,
   prior-version should be set to 2.0-1~. This will cause the conffile
   to be removed even if the user rebuilt the previous version 1.0-1
   as 1.0-1local1. Or a package switching a path from a symlink
   (shipped in version 1.0-1) to a directory (shipped in version
   2.0-1), but only performing the actual switch in the maintainer
   scripts in version 3.0-1, should set prior-version to 3.0-1~.


Cheers,
Chris.

Bug#988689: ITP: 7zip -- 7-Zip file archiver

[yokota]

Hello, Dylan.

Thanks for invite me to your 7zip project on salsa.

My changes are held on "experimental" branch. Please marge it.
Or, give me write permission to "master" branch. Because "master"
branch is protected and can only writable by project maintainer.
Check https://salsa.debian.org/help/user/project/protected_branches.md
for this issue.

I am a Debian Maintainer, so I can't upload packages without Debian
Developper's grant.
If you give me grant, check https://wiki.debian.org/DebianMaintainer .

--
YOKOTA Hiroshi

Bug#987461: libuima-adapter-soap-java is empty

[Hideki Yamane]

Hi,

On Mon, 21 Jun 2021 11:52:14 -0700
tony mancill  wrote:
> I saw the note in the changelog that Breaks is in fact there to remove
> the empty package, but it's not happening for me when I try to upgrade
> locally.  My test case is to install uima-utils (which will install
> libuima-adapter-soap-java via Recommends) and then try to upgrade the
> binaries to 2.10.2-4 using dpkg.  

 Well, it would remove libuima-adapter-soap-java if I've tested it
 on chroot env as below.

# apt install /tmp/libuima-core-java_2.10.2-4_all.deb 
(snip)
The following packages will be REMOVED:
  libuima-adapter-soap-java
The following packages will be upgraded:
  libuima-core-java
1 upgraded, 0 newly installed, 1 to remove and 0 not upgraded.
Need to get 0 B/1513 kB of archives.
After this operation, 12.3 kB disk space will be freed.


> The only way I can make this work is remove libuima-adapter-soap-java
> manually.  Are you sure that Breaks is necessary?  apt-get autoremove
> will clean up libuima-adapter-soap-java at some point.

 Okay, libuima-adapter-soap-java is empty now, just manual autoremove
 is fine. 

> I took a look at policy to see if Breaks + Replaces should be used in
> this situation, but I'm not sure it really applies (although I think it
> would work better than just Breaks).  Still, I'm unsure about the need
> for Breaks for this empty package clean-up use case.

 I don't think "Replaces" to be used in this situation since it
 does not provide any fuctions as same as previous one.
 

> Any concerns if I drop the Breaks before the upload?

 None, please go ahead for bullseye :)



-- 
Regards,

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

Bug#986821: freecad: Garbled menu makes freecad unusable

[Michael Jarosch]

Am 20.06.21 um 19:44 schrieb Tobias Frost:

Its a bit of a big hammer, but you could try stracing it, to see which 
files

are accessed in your home directory. Maybe that gives a hint…


Yeah. A lot of output.

Tried to make an strace with both users and diff the output, but it's 
still hard to get behind the fact, that one users working and another 
not. Still LOTS of lines, despite using diff.


Mostly, both logs have the same lines but offset. But there are a few 
lines which I *guess* are only in the log of the not-wirking user:


< poll([{fd=5, events=POLLIN}, {fd=6, events=POLLIN}, {fd=13, 
events=POLLIN}, {fd=15, events=POLLIN}, {fd=20, events=POLLIN}, {fd=21, 
events=POLLIN}], 6, 38) = 0 (Timeout)


f.e., or thousands of lines complaining about missing icons

< 
access("/home/mitsch/.local/share/icons/hicolor/16x16/stock/chart/tree.png", 
F_OK) = -1 ENOENT (Datei oder Verzeichnis nicht gefunden)
< 
access("/home/mitsch/.local/share/icons/hicolor/16x16/stock/chart/tree.svg", 
F_OK) = -1 ENOENT (Datei oder Verzeichnis nicht gefunden)
< 
access("/home/mitsch/.local/share/icons/hicolor/16x16/stock/code/tree.png", 
F_OK) = -1 ENOENT (Datei oder Verzeichnis nicht gefunden)


Don't know. Too much information for me.

Greets!

Mitsch

Bug#990166: strongswan: legacy conffiles leftover

[Christoph Anton Mitterer]

Source: strongswan
Version: 5.9.1-1
Severity: normal

Hi.

Apparently the strongswan packages used to contain the conffiles:
libstrongswan   /etc/logcheck/ignore.d.paranoid/strongswan
libstrongswan   /etc/logcheck/ignore.d.server/strongswan
libstrongswan   /etc/logcheck/ignore.d.workstation/strongswan
libstrongswan   /etc/logcheck/violations.ignore.d/strongswan
strongswan-nm   /etc/dbus-1/system.d/nm-strongswan-service.conf
strongswan-starter  /etc/strongswan.d/tools.conf
strongswan-starter  /etc/strongswan.d/pki.conf
strongswan-starter  /etc/strongswan.d/scepclient.conf
but no longer does so.

Please properly clean them up using dpkg-maintscript-helper(1).
(AFAIU, the version that needs to be specified for that is NOT
the version where the conffile was dropped, but rather "the
latest version of the package whose upgrade should trigger
the operation"

Quoting the manpage:
   For example, for a conffile removed in version 2.0-1 of a package,
   prior-version should be set to 2.0-1~. This will cause the conffile
   to be removed even if the user rebuilt the previous version 1.0-1
   as 1.0-1local1. Or a package switching a path from a symlink
   (shipped in version 1.0-1) to a directory (shipped in version
   2.0-1), but only performing the actual switch in the maintainer
   scripts in version 3.0-1, should set prior-version to 3.0-1~.


Cheers,
Chris.

Bug#990165: perf: allow using other versions than the running kernel

[Steinar H. Gunderson]

Package: linux-base
Version: 4.6
Severity: normal
Tags: patch

Hi,

The perf wrapper script in Debian requires the perf binary of the running
kernel. However, there's not really a good reason for this; perf has a stable
ABI, and even though it's distributed and built with the kernel, you can freely
mix and match versions (I've done so, a lot).

There may still be reasons why people prefer to keep the versions matched,
but perf shouldn't just give up and die if it can't find the right version.
I've made a patch that makes this a bit more flexible; it first tries to
find a matching version, and if it doesn't exist, it simply picks the newest
one it can find. (If that's older than the kernel, it gives a warning,
since there may be new features the user would want to upgrade for, but it
doesn't die.)

Hopefully this should be safe, while being a lot less annoying when running
a newer or self-compiled kernel. :-)

--- linux-base-4.6.orig/bin/perf2018-07-20 03:35:21.0 +0200
+++ linux-base-4.6/bin/perf 2021-06-22 00:15:59.618443368 +0200
@@ -10,9 +10,11 @@
;;
 esac
 shopt -s execfail
-exec "perf_$version" "$@"
+if [ -x "/usr/bin/perf_$version" ]; then
+exec "perf_$version" "$@"
+fi
 
-# Not found? Tell the user which package to install.
+# Not found? Find out which version to install.
 case "$version" in
 3.* | 4.0 | 4.0.*)
package=linux-tools-$version
@@ -21,5 +23,16 @@
package=linux-perf-$version
;;
 esac
+
+# See if we have a usable alternative available.
+perfversion="$( linux-version sort --reverse $( echo /usr/bin/perf_* | sed 
"s,/usr/bin/perf_,,g" ) | head -n 1 )"
+if [ -x "/usr/bin/perf_$perfversion" ]; then
+if linux-version compare "$perfversion" lt "$version"; then
+echo >&2 "W: perf_$perfversion is older than the running kernel, 
consider installing $package."
+fi
+exec "perf_$perfversion" "$@"
+fi
+
+# Still nothing? Tell the user.
 echo >&2 "E: $package is not installed."
 exit 1

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

Kernel: Linux 5.12.8 (SMP w/40 CPU threads)
Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_NO:en_US:en_GB:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages linux-base depends on:
ii  debconf [debconf-2.0]  1.5.75

linux-base recommends no packages.

linux-base suggests no packages.

-- debconf-show failed

Bug#953997: obsolete conffiles after upgrade

[Christoph Anton Mitterer]

Guess the reason might be that the version used with dpkg-maintscript-
helper rm_conffile could be wrong.

(AFAIU, the version that needs to be specified for that is NOT
the version where the conffile was dropped, but rather "the
latest version of the package whose upgrade should trigger
the operation"

Quoting the manpage:
   For example, for a conffile removed in version 2.0-1 of a package,
   prior-version should be set to 2.0-1~. This will cause the conffile
   to be removed even if the user rebuilt the previous version 1.0-1
   as 1.0-1local1. Or a package switching a path from a symlink
   (shipped in version 1.0-1) to a directory (shipped in version
   2.0-1), but only performing the actual switch in the maintainer
   scripts in version 3.0-1, should set prior-version to 3.0-1~.


It seems to rm_conffile was added with d88536d which is 5.6.0-4 while
rm_conffile is invoked with 5.6.0-3\~



Cheers,
Chris.

Bug#990106:

[Davide Beatrici]

Thanks!

I installed linux-image-5.9.0-0.bpo.5-amd64 and instantly reproduced the issue.

For reference: the amplifier is a Denon AVR-X500. I just purchased a Denon 
AVR-X1000 as replacement, I will confirm whether the issue is fixed as soon as 
I receive it.

At this point I'm 99% sure it's the amplifier though.

Bug#989297: unblock: libaec/1.0.4-2

[Andreas Beckmann]

On 21/06/2021 21.55, Sebastian Ramacher wrote:

Let's add some Breaks for smoother upgrades from buster due to the hdf5
library renames.



With hdf5 fixed and libgdal2{0,8} being fixed soon, this should no
longer necessary.


I reverted the Breaks in -3, so there is only some cleanup left 
(spelling, whitespace, redundancies, R³), nothing worth of an unblock on 
its own.



Also, a new upstream release was uploaded on top of
that. 


To experimental.

Andreas

Bug#990123: [buster regression] iptables-netflow-dkms: No more compiles since linux-*-4.19.0-17-*: "implicit declaration of function ‘ref_module’" (Upstream kernel API regression in 4.19.191?)

[Axel Beckert]

Control: reassign -1 iptables-netflow-dkms
Control: found -1 2.3-5
Control: notfound -1 2.5.1-2

Hi Salvatore,

Salvatore Bonaccorso wrote:
> On Mon, Jun 21, 2021 at 01:33:01PM +0200, Axel Beckert wrote:
> > Since kernel packages linux-{image,headers}-4.19.0-17-*, at least with
> > -amd64 and -i686-pae, iptables-netflow-dkms no more compiles its kernel
> > module upon kernel installation:
> > 
> > In file included from /var/lib/dkms/ipt-netflow/2.3/build/ipt_NETFLOW.c:75:
> > /var/lib/dkms/ipt-netflow/2.3/build/ipt_NETFLOW.c: In function 
> > ‘register_ct_events’:
> > /var/lib/dkms/ipt-netflow/2.3/build/compat.h:173:21: error: implicit 
> > declaration of function ‘ref_module’; did you mean ‘use_module’? 
> > [-Werror=implicit-function-declaration]
> >  # define use_module ref_module
> >  ^~
> > /var/lib/dkms/ipt-netflow/2.3/build/ipt_NETFLOW.c:5399:3: note: in 
> > expansion of macro ‘use_module’
> >use_module(THIS_MODULE, netlink_m);
> >^~
> > 
> > Reading the kernel changelog, there are a few very suspicious entries
> > listed under upstream version 4.19.191:
> > 
> > - modules: mark ref_module static
> > - modules: mark find_symbol static
> > - modules: mark each_symbol_section static
> > 
> > One of the commits above (8745aa4e resp. 7ef5264d) states:
> > 
> >   ref_module isn't used anywhere outside of module.c.
> > 
> > Which is only seems true if you ignore any third-party kernel modules
> > out there.
[…]
> 7ef5264de773 ("modules: mark ref_module static") indeed is likely to
> cause the issue, or basically the patchset around that.

Thanks for that confirmation.

> That initially landed in 5.9-rc1,

Right, I saw that the list of tags including that change on Github. I
though wondered why 2.5.1-2 works in Sid/Bullseye but not on Buster —
but probably because the current #ifdefs just don't expect that fix
being needed for any kernel before 5.9.

> There is some background here:
> 
> https://lore.kernel.org/lkml/20200730061027.29472-1-...@lst.de/
> https://lore.kernel.org/stable/ymxnxqzcp0g1f...@kroah.com/

Thanks for that! I didn't really expected license enforcing to be the
background. With that background I do understand that change much
more. :-)

> That said, upstream won't really revert those changes.

Understandable. I'm though surprised that this got backported. But I
guess the pain without it is bigger than this one precise cut.

> So in my biased view, what would be needed for buster indeed would be
> an equivalent approach in buster for iptables-netflow unbreaking this
> regression similar as done in 2.5.1-1 wit the
> 
> cherry-pick-adfc6318-fix-compilation-for-5.9-workaround-ref_module-unexport.patch

Thanks for pointing out that this patch is already in 2.5.1-1.

I actually forgot that I had to solve this already once in the past
(probably because the solution was submitted as pull request upstream
against 2.5.1) and since 2.5.1-2 didn't work on buster either, I
didn't expect it to be more or less fixed already. But in the end it's
hopefully just replacing

#if LINUX_VERSION_CODE < KERNEL_VERSION(5,9,0)

with a bit more complex condition including further constraints.

> I had no time to check if the patch applies and what changes need to
> be done,

No need to worry. That's not your job but mine. :-)

> but basically what was added there fo fix compilation with Linux 5.9
> (which introduced the above changes initially) would need as well
> for the 4.19.y stable series.

Ack.

Thanks again.

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


signature.asc
Description: PGP signature

Bug#990027: pre-approval unblock: opendmarc/1.4.0~beta1+dfsg-6

[Sebastian Ramacher]

Control: tags -1 confirmed moreinfo

On 2021-06-18 10:03:21 +0200, David Bürgin wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: unblock
> 
> Please pre-approve unblock of package opendmarc
> 
> Recently several fixes for CVEs in OpenDMARC have landed in bullseye
> thanks to unblock request #989324 being granted.
> 
> Now reports of crashes have arrived at the upstream bug tracker,
> resulting in new CVE-2021-34555. It appears that the fix for
> CVE-2019-16378 contains code that can segfault, given certain inputs. An
> attacker can crash the current bullseye/sid version at will, so a fix is
> urgently needed.
> 
> I have created a patch and proposed it upstream and would like to apply
> it here as well via sponsorship on debian-mentors, hence this request
> for pre-approval.
> 
> [ Reason ]
> A fix for new CVE-2021-34555 has been proposed upstream.
> 
> [ Impact ]
> Current opendmarc 1.4.0~beta1+dfsg-5 can be trivially crashed by a third
> party leading to denial of service outage.
> 
> [ Tests ]
> Reporter at upstream has confirmed the fix works, I also verified it via
> manual test.
> 
> [ Risks ]
> Upstream is not active, but they might prefer a different fix when they
> come back.
> 
> [ Checklist ]
> [x] all changes are documented in the d/changelog
> [x] I reviewed all changes and I approve them
> [x] attach debdiff against the package in testing
> 
> unblock opendmarc/1.4.0~beta1+dfsg-6

ACK, please remove the moreinfo tag once the new version is available in
usntable.

Cheers

> diff -Nru opendmarc-1.4.0~beta1+dfsg/debian/changelog 
> opendmarc-1.4.0~beta1+dfsg/debian/changelog
> --- opendmarc-1.4.0~beta1+dfsg/debian/changelog   2021-06-02 
> 14:17:33.0 +0200
> +++ opendmarc-1.4.0~beta1+dfsg/debian/changelog   2021-06-18 
> 09:37:57.0 +0200
> @@ -1,3 +1,10 @@
> +opendmarc (1.4.0~beta1+dfsg-6) unstable; urgency=high
> +
> +  * Add patch for CVE-2021-34555 from upstream issue tracker:
> +- Do not dereference NULL in multi-value From headers (Closes: #990001)
> +
> + -- David Bürgin   Fri, 18 Jun 2021 09:37:57 +0200
> +
>  opendmarc (1.4.0~beta1+dfsg-5) unstable; urgency=high
>  
>* Amend cve-2020-12272.patch to keep libopendmarc2 public ABI unchanged
> diff -Nru opendmarc-1.4.0~beta1+dfsg/debian/patches/cve-2021-34555.patch 
> opendmarc-1.4.0~beta1+dfsg/debian/patches/cve-2021-34555.patch
> --- opendmarc-1.4.0~beta1+dfsg/debian/patches/cve-2021-34555.patch
> 1970-01-01 01:00:00.0 +0100
> +++ opendmarc-1.4.0~beta1+dfsg/debian/patches/cve-2021-34555.patch
> 2021-06-15 16:36:43.0 +0200
> @@ -0,0 +1,38 @@
> +Description: CVE-2021-34555: Fix multi-value From rejection logic
> +Author: David Bürgin 
> +Bug: https://github.com/trusteddomainproject/OpenDMARC/pull/178
> +
> +--- a/opendmarc/opendmarc.c
>  b/opendmarc/opendmarc.c
> +@@ -2517,17 +2517,22 @@
> + 
> + for (c = 1; users[c] != NULL; c++)
> + {
> +-if (strcasecmp(domains[0], domains[c]) != 0)
> ++if (domains[0] != NULL
> ++&& domains[c] != NULL
> ++&& strcasecmp(domains[0], domains[c]) != 0)
> + {
> +-syslog(LOG_ERR,
> +-   "%s: multi-valued From field detected",
> +-   dfc->mctx_jobid);
> +-}
> ++if (conf->conf_dolog)
> ++{
> ++syslog(LOG_ERR,
> ++   "%s: multi-valued From field 
> detected",
> ++   dfc->mctx_jobid);
> ++}
> + 
> +-if (conf->conf_reject_multi_from)
> +-return SMFIS_REJECT;
> +-else
> +-return SMFIS_ACCEPT;
> ++if (conf->conf_reject_multi_from)
> ++return SMFIS_REJECT;
> ++else
> ++return SMFIS_ACCEPT;
> ++}
> + }
> + 
> + user = users[0];
> diff -Nru opendmarc-1.4.0~beta1+dfsg/debian/patches/series 
> opendmarc-1.4.0~beta1+dfsg/debian/patches/series
> --- opendmarc-1.4.0~beta1+dfsg/debian/patches/series  2021-06-02 
> 12:14:59.0 +0200
> +++ opendmarc-1.4.0~beta1+dfsg/debian/patches/series  2021-06-15 
> 16:23:10.0 +0200
> @@ -12,3 +12,4 @@
>  cve-2019-16378.patch
>  cve-2020-12272.patch
>  cve-2019-20790.patch
> +cve-2021-34555.patch


-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#985308: CVE-2021-3421 CVE-2021-20271 CVE-2021-20266 CVE-2021-20249 CVE-2021-20248

[Salvatore Bonaccorso]

Hi,

On Mon, Mar 15, 2021 at 07:52:38PM +0100, Moritz Muehlenhoff wrote:
> Package: rpm
> Version: 4.16.1.2+dfsg1-0.4
> Severity: important
> Tags: security
> X-Debbugs-Cc: Debian Security Team 
> 
> CVE-2021-3421:
> https://bugzilla.redhat.com/show_bug.cgi?id=1927747
> 
> CVE-2021-20271:
> https://bugzilla.redhat.com/show_bug.cgi?id=1934125
> 
> CVE-2021-20266:
> https://bugzilla.redhat.com/show_bug.cgi?id=1927741
> 
> CVE-2021-20249;
> https://bugzilla.redhat.com/show_bug.cgi?id=1927742
> 
> CVE-2021-20248:
> https://bugzilla.redhat.com/show_bug.cgi?id=1927740

The last two CVEs were withdranw by the assigning CNA, as further
investigation showed that there is not a security issue.

So retitled the bug accordingly.

Regards,
Salvatore

Bug#990164: RM: libopencv-core4.2 -- ROM; superseeded by libopencv-core4.5

[Jochen Sprickerhof]

Package: ftp.debian.org
Severity: normal


Please remove the old opencv 4.2 packages, I believe this should be:

libopencv4.2-java
libopencv4.2-jni
libopencv-calib3d4.2
libopencv-contrib4.2
libopencv-core4.2
libopencv-dnn4.2
libopencv-features2d4.2
libopencv-flann4.2
libopencv-highgui4.2
libopencv-imgcodecs4.2
libopencv-imgproc4.2
libopencv-ml4.2
libopencv-objdetect4.2
libopencv-photo4.2
libopencv-shape4.2
libopencv-stitching4.2
libopencv-superres4.2
libopencv-video4.2
libopencv-videoio4.2
libopencv-videostab4.2
libopencv-viz4.2

I guess these are not automatically remove due to a circular dependency
between libopencv-superres4.2 and libopencv-contrib4.2 (#963890) fixed
in unstable with #979809.

Thanks!

Jochen

Bug#990123: [buster regression] iptables-netflow-dkms: No more compiles since linux-*-4.19.0-17-*: "implicit declaration of function ‘ref_module’" (Upstream kernel API regression in 4.19.191?)

[Salvatore Bonaccorso]

Control: affects -1 + release.debian.org

Hi Axel,

On Mon, Jun 21, 2021 at 01:33:01PM +0200, Axel Beckert wrote:
> Package: 
> iptables-netflow-dkms,linux-headers-4.19.0-17-amd64,linux-headers-4.19.0-17-i686-pae
> Severity: serious
> Version: iptables-netflow/2.3-5
> Version: iptables-netflow/2.5.1-2
> Version: linux/4.19.194-1
> Tags: buster
> Forwarded: https://github.com/aabc/ipt-netflow/issues/177
> 
> Since kernel packages linux-{image,headers}-4.19.0-17-*, at least with
> -amd64 and -i686-pae, iptables-netflow-dkms no more compiles its kernel
> module upon kernel installation:
> 
> In file included from /var/lib/dkms/ipt-netflow/2.3/build/ipt_NETFLOW.c:75:
> /var/lib/dkms/ipt-netflow/2.3/build/ipt_NETFLOW.c: In function 
> ‘register_ct_events’:
> /var/lib/dkms/ipt-netflow/2.3/build/compat.h:173:21: error: implicit 
> declaration of function ‘ref_module’; did you mean ‘use_module’? 
> [-Werror=implicit-function-declaration]
>  # define use_module ref_module
>  ^~
> /var/lib/dkms/ipt-netflow/2.3/build/ipt_NETFLOW.c:5399:3: note: in expansion 
> of macro ‘use_module’
>use_module(THIS_MODULE, netlink_m);
>^~
> 
> Reading the kernel changelog, there are a few very suspicious entries
> listed under upstream version 4.19.191:
> 
> - modules: mark ref_module static
> - modules: mark find_symbol static
> - modules: mark each_symbol_section static
> 
> One of the commits above (8745aa4e resp. 7ef5264d) states:
> 
>   ref_module isn't used anywhere outside of module.c.
> 
> Which is only seems true if you ignore any third-party kernel modules
> out there.
> 
> So why is the kernel API suddenly removing API-code used by third-party
> modules inmidst a stable update? This looks like a regression to me.  I
> thought that stable updates only change the ABI, but not the API. (Well,
> at least upstream and in Debian. :-)
> 
> I also tried the iptables-netflow-dkms 2.5.1-2 from Bullseye on Buster,
> but it fails to build the kernel module for 4.19.0-17-* when as well.
> 
> 2.5.1-2 though still works fine on Sid/Bullseye, hence marked as found
> in the version in Sid, but tagged buster. In case this causes issues in
> the BTS or the release team scripts, please rather remove 2.5.1-2 from
> the "found" versions instead of removing the buster tag — unless the
> same regression gets introduced into Sid and Bullseye as well.
> 
> Debian kernel maintainers: If this 3rd-party-module-breaking regression
> was really intended and won't be fixed, please reassign the bug to
> iptables-netflow-dkms only.
> 
> I also reported this issue to iptables-netflow upstream at
> https://github.com/aabc/ipt-netflow/issues/177 as I think it at least
> should update the version based ifdef checks in something which looks
> like a similar issue in kernel 5.13, see
> https://github.com/aabc/ipt-netflow/commit/5aae3791922bd3df878605b15e83ea48a4bd096c
> which is part of iptables-netflow upstream's 2.6 release, not yet
> packaged due to the freeze for bullseye.
> 
> I'll try and see if I can get that fix backported to the package in
> buster (and if needed, later to the one in bullseye as well) and will
> see if it actually helps in this case, too.
> 
> JFTR: dkms from buster-backports (as reported below) is only installed
> as I needed it for the iptables-netflow-dkms package from bullseye. It
> happened with dkms from buster before as well.

7ef5264de773 ("modules: mark ref_module static") indeed is likely to
cause the issue, or basically the patchset around that. That initially
landed in 5.9-rc1, and recently got backported upstream to 4.19.191.

There is some background here:

https://lore.kernel.org/lkml/20200730061027.29472-1-...@lst.de/

and

https://lore.kernel.org/stable/ymxnxqzcp0g1f...@kroah.com/

That said, upstream won't really revert those changes. 

So in my biased view, what would be needed for buster indeed would be
an equivalent approach in buster for iptables-netflow unbreaking this
regression similar as done in 2.5.1-1 wit the

cherry-pick-adfc6318-fix-compilation-for-5.9-workaround-ref_module-unexport.patch

patch.

I had no time to check if the patch applies and what changes need to
be done, but basically what was added there fo fix compilation with
Linux 5.9 (which introduced the above changes initially) would need as
well for the 4.19.y stable series.

Regards,
Salvatore

Bug#990163: open-vm-tools 11.3.0

[John Wolfe]

Sincerest apologies, I copied the anticipated RPM packaging changes needed for 
the open-vm-tools 11.3.0 tools.   I meant to include the following suggestions:

Suggested packaging changes needed to the debian/rules file:

1. vmwgfxctrl command- in open-vm-tools-desktop .deb package.

   - requires access to libdrm and libudev to be compiled and will dlopen()
 at runtime.  Will quietly exit if runtime not available on guest VM.

   Build dependencies:   libdrm, libudev

   Add to open-vm-tools-desktop package:

   mv debian/open-vm-tools/usr/bin/vmwgfxctrl 
debian/open-vm-tools-desktop/usr/bin

2. The open-vm-tools source release contains a complete example of a
   tools.conf.  Please package this open-vm-tools/tools.conf file ass
   /etc/vmware-tools/tools.conf.example


New commands,libraries and vmsvc plugins to be a part of the open-vm-tools .deb
package

   usr/bin/vmware-alias-import

   usr/lib/libguestStoreClient.so.0*

   usr/lib/open-vm-tools/plugins/vmsvc/libguestStore.so
   usr/lib/open-vm-tools/plugins/vmsvc/libgdp.so

3. new vmsvc plugins:

   %{_libdir}/libguestStoreClient.so.*
   %{_libdir}/%{name}/plugins/vmsvc/libgdp.so
   %{_libdir}/%{name}/plugins/vmsvc/libguestStore.so

Bug#990163: Open-vm-tools release 11.3.0 has been released

[John Wolfe]

Package: open-vm-tools
Version 2:11.3.0

open-vm-tools 11.3.0 has been released on June 18, 2021 containing:

  - a number of bug and Coverity fixes.
  - command line tool to control various aspects of the vmwgfx Linux
kernel module (open-vmtools-desktop)
  - command line support tool for guest operations authentication configuration.
  - enhancements to support or utilize various vSphere features.

See: https://github.com/vmware/open-vm-tools/releases/tag/stable-11.3.0

Please refer to the release notes at 
https://github.com/vmware/open-vm-tools/blob/stable-11.3.0/ReleaseNotes.md

The granular changes that have gone into the 11.3.0 release are in the 
ChangeLog at 
https://github.com/vmware/open-vm-tools/blob/stable-11.3.0/open-vm-tools/ChangeLog

Anticipated changes needed to the open-vm-tools.spec file

1. vmwgfxctrl command- in open-vm-tools-desktop package.

   - requires access to libdrm and libudev to be compiled and will dlopen()
 at runtime.  Will quietly exit if runtime not available on guest VM.

   Build dependencies:   libdrm, libudev

   Add to open-vm-tools-desktop package:

   %{_bindir}/vmwgfxctrl

2. vmware-alias-import command - in open-vm-tools package

   %{_bindir}/vmware-alias-import

3. new vmsvc plugins:

   %{_libdir}/libguestStoreClient.so.*
   %{_libdir}/%{name}/plugins/vmsvc/libgdp.so
   %{_libdir}/%{name}/plugins/vmsvc/libguestStore.so

Bug#990161: installation-reports: insistat on partman-auto/disk if more than one disk present

[Marc Haber]

Package: installation-reports
Severity: minor
Tags: d-i
X-Debbugs-Cc: mh+debian-b...@zugschlus.de

Boot method: CD
Image version: debian-bullseye-DI-rc2-amd64-netinst.iso
Date: 2021-06-21 20:00 CEST

Machine: KVM VM
Partitions: 
root@debian:~# df -Tl
Filesystem Type 1K-blocksUsed Available Use% Mounted on
udev   devtmpfs483524   0483524   0% /dev
tmpfs  tmpfs99964 580 99384   1% /run
/dev/vda1  ext4  15405420 1140920  13460148   8% /
tmpfs  tmpfs   499804   0499804   0% /dev/shm
tmpfs  tmpfs 5120   0  5120   0% /run/lock
tmpfs  tmpfs99960   0 99960   0% /run/user/1000
root@debian:~# 

Base System Installation Checklist:
[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it

Initial boot:   [O ]
Detect network card:[O ]
Configure network:  [O ]
Detect media:   [O ]
Load installer modules: [O ]
Clock/timezone setup:   [O ]
User/password setup:[O ]
Detect hard drives: [O ]
Partition hard drives:  [E ]
Install base system:[O ]
Install tasks:  [O ]
Install boot loader:[O ]
Overall install:[O ]

Comments/Problems:

This was a preseeded install to demonstrate an issue with preseeding.
The test VM has TWO virtio hard disks and the virtual CD drive the
machine was booted from. The preseed file was manually given on the
installer command line as preseed/url=http://... and did NOT contain a
"d-i partman-auto/disk" setting.

The installation guide for buster says in chapter B.4 "Partitioning":
# Alternatively, you may specify a disk to partition. If the system has only
# one disk the installer will default to using that, but otherwise the device
# name must be given in traditional, non-devfs format (so e.g. /dev/sda
# and not e.g. /dev/discs/disc0/disc).
# For example, to use the first SCSI/SATA hard disk:
#d-i partman-auto/disk string /dev/sda

The buster installer and also the bullseye installer that is the subject
of this report behave as documented and stop at the partitioning stage
and explicitly ask the user for the partitioning method and the disk to
install.

It is necessary to set 
d-i partman-auto/disk string /dev/vda
to get a truly non-interactive install.

Also, removing the second virtio hard disk makes the install go
through non-interactively without d-i partman-auto/disk being set.

This is 100 % as documented.

The issue I would like you to consider is the case when the Installer is
booted from an USB stick (which doesn't work for a VM, hence this bug
report with the second hard disk to demonstrate). The USB stick gets
assigned /dev/sdb and triggers the issue as described here. It is thus
not possible to have a truly non-interactive install booted from an USB
stick wihtout explicitly specifying whether to install to /dev/sda.

This, however, makes it harder to test such installer images in VMs
because in a VM, the disk is /dev/vda and not /dev/sda, causing an
installation abort because the disk is not found.

I think this can possible be solved by expanding the partman-auto/disk
option to take a list of devices, like "/dev/sda /dev/vda", installing
to the first device that is actually found on the system.

Or a new partman-auto preseed option could be invented to blindly
install to the first disk found regardless of whether it's the only disk
or not.

Special-casing the medium from which the system was booted is probably
not a good idea because there are usecases where I actually boot the
installer from the target disk.

I am open for discussions about how to address this. For the time being,
I can live with the nuisance of having two different images for VM and
bare metal installs. If there is an easier way, please tell me.

Greetings
Marc


-- Package-specific info:

==
Installer lsb-release:
==
DISTRIB_ID=Debian
DISTRIB_DESCRIPTION="Debian GNU/Linux installer"
DISTRIB_RELEASE="11 (bullseye) - installer build 20210606"
X_INSTALLATION_MEDIUM=cdrom

==
Installer hardware-summary:
==
uname -a: Linux debian 5.10.0-7-amd64 #1 SMP Debian 5.10.40-1 (2021-05-28) 
x86_64 GNU/Linux
lspci -knn: 00:00.0 Host bridge [0600]: Intel Corporation 82G33/G31/P35/P31 
Express DRAM Controller [8086:29c0]
lspci -knn: Subsystem: Red Hat, Inc. QEMU Virtual Machine [1af4:1100]
lspci -knn: 00:01.0 VGA compatible controller [0300]: Red Hat, Inc. QXL 
paravirtual graphic card [1b36:0100] (rev 05)
lspci -knn: Subsystem: Red Hat, Inc. QEMU Virtual Machine [1af4:1100]
lspci -knn: 00:02.0 PCI bridge [0604]: Red Hat, Inc. QEMU PCIe Root port 
[1b36:000c]
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:02.1 PCI bridge [0604]: Red Hat, Inc. QEMU PCIe Root port 
[1b36:000c]
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:02.2 PCI 

Bug#922981: tagging 922981 (ca-certificates-java: /etc/ca-certificates/update.d/jks-keystore doesn't update /etc/ssl/certs/java/cacerts)

[Paul Gevers]

Hi Julien,

On Tue, 18 May 2021 21:38:46 +0200 Paul Gevers  wrote:
> On 08-04-2021 19:33, Julien Cristau wrote:
> > I've started to look at it, I'm afraid building up context on this
> > stuff to understand what it's doing is going to take a while...
> 
> Just a friendly ping. Did you get anywhere with this yet?

Another month has passed and we now have a *tentative* release date. Is
there any progress on this bug? The patch is tested according to Andreas.

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#946962:

[Mike Fleetwood]

This has been fixed in GParted 1.3.0 released 2021-May-03 [1], by the
merge of [2].

Thanks,
Mike Fleetwood (GParted Developer)


[1] https://gparted.org/news.php?item=238

[2] Support resizing open LUKS2 encryption mappings by supplying the
needed passphrase
https://gitlab.gnome.org/GNOME/gparted/-/merge_requests/80

Bug#990159: RM: libnet-amazon-perl -- ROM; dysfunctional after API change

[gregor herrmann]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: debian-p...@lists.debian.org

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512


Please remove libnet-amazon-perl from the archive.

Cf. https://bugs.debian.org/990042 and the upstream issue at
https://github.com/boumenot/p5-Net-Amazon/issues/9

Summary: After Amazon retired its old API, Net::Amazon simply doesn't
work anymore. Interestingly noone noticed since early 2020 … There
are no plans to fix this upstream (i.e. completely rewrite the
module), and upstream also proposed to remove the module.

No rdeps, low popcon.


Thanks in advance,
gregor


-BEGIN PGP SIGNATURE-

iQKTBAEBCgB9FiEE0eExbpOnYKgQTYX6uzpoAYZJqgYFAmDQ50xfFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEQx
RTEzMTZFOTNBNzYwQTgxMDREODVGQUJCM0E2ODAxODY0OUFBMDYACgkQuzpoAYZJ
qgZcmhAAljnFAZQ5UV8RSB8LeLRP/uPx6zY3P1JwcK8xq53dP8aEQrn7E3ETohGx
ZRinSlDHBKfxXto2giK89dGJ0tOVACXLJpkGey005Hus04TuP1SEHpeeZWp9kY5w
Xf6Kb4bSV8+fwUj5+iYzTejGXkSmnlO4kXZ3qCCkW7gQMhRIZmv5B3HgnBdgehAd
MKcFj8vzm2kwRCOfoyaxn9rqIxjOLRb+yFt2uum2hxe7yaM2xJQalHOxMGa/mVgX
yOX/5/JsJSuc+OpdICcgX1xyt4yMeGKc3Bccxf7Ylcm9K/jmrfMfqO6E9gsYnbIq
1sDK4RZXax8L8UEyfa6FgWu5Pcu7raqxxcVrVRjMWbQ9XuxaIpUShiLdmerxFb0A
j/kXf8FnQ4K8zLxa8VjfdCnd5P2EMk5fn9jFTSSg4NmkDeU5F7J4z5duRBZm7ct0
jDyrWSAZ7o3iduZQ1o/DuZ8vy8knVkEgYcpxd1yWg9YaW68bCDybdS174jqzPNy/
c9ZgqCQSyaPF1y3Cg8ezOZ0mzMUzckUNx5KRqM+Jaj6Obx6DV/BNviYUCSyOV/X/
WRGp6QRmUMyn2ypnme4lNGWBhi5jIW7Ne9hsPj2ttAuQS1ye0SwY/BOo1nBMMCdy
HtApuMhZUfkV41b6VtNj6tiuv9UkCXw3A+c3Klr1o/wRa+YVnws=
=PuLX
-END PGP SIGNATURE-

Bug#924643: RFS: colorzero/2.0-1 [ITP] -- Construct, convert, and manipulate colors in a Pythonic manner.

[Dave Jones]

Hi Emmanuel,

On Mon, Jun 21, 2021 at 01:33:11PM -0300, Emmanuel Arias wrote:

On 6/21/21 11:06 AM, Dave Jones wrote:

On Sat, Jun 19, 2021 at 06:40:58PM -0300, Emmanuel Arias wrote:

Also, you can try to follow DEP-14 (although is mark as candidate)
and add debian/master as default branch.


Ah, this was something that confused me a bit when initially working
on this. I'd read through DEP-14, but then figured a simple way to
start would be to grab my existing packaging for Raspbian and use gbp
import-dsc on it. This set up the repo with a "master" branch rather
than "debian/master" and I then wondered if I'd mis-interpreted
DEP-14's prescription to use "debian/master", and whether it meant one
should use "debian" branch or alternatively a "master" branch.

I think that I don't understand you, sorry :(. But DEP-14 recommend the
use of /* for name the branchs, so for debian the branch should
be debian/*, for ubuntu ubuntu/*, etc.


Ah, sorry -- I'll attempt to elaborate my (rather silly) leap of 
"logic". Having read [PY-GIT] and [DEP-14], and knowing that gbp was 
specifically made for Debian packaging, after using "gbp import-dsc" I 
was slightly surprised to wind up on a "master" branch rather than 
"debian/master". I generally assume that tooling made specifically for a 
purpose (like Debian packaging) probably knows what it's doing better 
than I do, and hence I wondered whether I had missed something and 
whether (yes, it seems silly in hindsight, but still) the recommendation 
to use "debian/master" was to be interpreted as "debian or master" 
rather than a literal "debian/master" string.


Anyway, that's why I initially pushed a "master" branch rather than 
"debian/master" (under the assumption that gbp's defaults are probably a 
better bet than me trying to second guess the interpretation of 
standards :).


[PY-GIT] https://wiki.debian.org/Python/GitPackaging#Git_Branch_Names
[DEP-14] https://dep-team.pages.debian.net/deps/dep14/

In any case, I've fixed up the branches in the repo now and I *think* 
I've got the CI configuration in the right place, though it doesn't seem 
to have triggered a run yet. I've probably missed something in the repo 
config -- will dig into that in a mo.


Thanks for all the advice!

Dave.

Bug#990121: osspd: revert debhelper compat bump to get #986662 fixed in bullseye

[Simon McVittie]

On Mon, 21 Jun 2021 at 12:43:43 +0200, Ralf Jung wrote:
> > If you are happy with this change, please say so, and I can move the upload
> > out of the DELAYED queue and into unstable immediately.
> 
> Thanks a lot! Yes I am happy with the change.

Thanks, I'll move this from DELAYED/7 to DELAYED/0 so it gets into
unstable a bit sooner.

> > I am unsure whether the release team will be willing to unblock with the
> > two commits cherry-picked from upstream git included in the package. If
> > they are not, another upload that additionally reverts one or both of
> > those commits might be necessary. We are less likely to need to revert
> > them if we can justify why they are required.
> > 
> > d/p/GIT-fix-adsp_se.patch looks like it might be fixing a genuine bug. Can
> > you describe the bug that it is fixing and why it should be applied in
> > bullseye?
> > 
> > d/p/GIT-fix-compiler-warnings.patch looks like it is just silencing
> > compiler warnings by removing unreachable code. Do we really need this
> > for bullseye? If it is not strictly necessary then it might be safer to
> > revert it until after bullseye has been released.
> 
> Those changes were suggested for inclusion by Sébastien (CC'ed). I don't
> know more about them than what it says in the patch files. They both come
> from upstream osspd git.

I'll wait to see what Sébastien says about these, then.

> > After bullseye is released and the freeze is over, you can reapply the
> > changes that I've reverted and upload to unstable in the usual way.
> 
> So, the recommended way is that I pull your changes into my git repo, and
> then apply reverts of the reverts?

That's what I'd do in your situation, although not right now (we should
wait for bullseye to be released before making disruptive changes, and
increasing the debhelper compat level counts as a disruptive change).

> Btw, I'm not using osspd any more, and I am not very skilled with Debian
> packaging tools since all I do with them is upload a new osspd release every
> 2 years or so. So help would be welcome. :)

Moving the version control onto salsa.debian.org, either in your personal
namespace if you want tight control over it, in the debian namespace if
you want minimum friction for contributions from Debian Developers, or
in some suitable team's namespace, would probably make it easier to
collaborate. I can help with this.

I wonder whether it'd make sense for the Games Team to absorb it, since
its major use-case in 2021 is probably running ancient binary-only games
like Unreal Tournament? You could still be in Uploaders if you're
interested in it.

smcv

Bug#990158: shim-signed-common: No UEFI boot with error "Could not create MokListXRT"

[Ayke Halder]

Package: shim-signed-common
Version: 1.33+15+1533136590.3beb971-7
Severity: critical
Justification: breaks the whole system

Dear Maintainer,


## What led up to the situation?

Upgrade:

* shim-signed:amd64 (1.33+15+1533136590.3beb971-7,
1.36~1+deb10u1+15.4-5~deb10u1)
* shim-signed-common:amd64 (1.33+15+1533136590.3beb971-7,
1.36~1+deb10u1+15.4-5~deb10u1)

System: Dell T5600 with BIOS Revision A19


## What was the outcome of this action?

System is unbootable on booting via UEFI. System shows error message and then
powers off immediately:

"Could not create MokListXRT: Out of Resources
Something has gone seriously wrong: import_mok_state() failed: Out of
Resources"


## What outcome did you expect instead?

A normal booting system loading GRUB.


## Also reproducible with Debian Live-Installations-Image

On affected hardware like "Dell T5600" doing a UEFI boot from USB with …

* debian-live-10.10.0-amd64-standard.iso does *not* work.
* debian-live-10.9.0-amd64-standard.iso works.


## Related resources

Might be related to:

* https://bugzilla.suse.com/show_bug.cgi?id=1185261



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

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

Versions of packages shim-signed-common depends on:
ii  debconf [debconf-2.0]  1.5.71
ii  mokutil0.3.0+1538710437.fb6250f-1

shim-signed-common recommends no packages.

shim-signed-common suggests no packages.

-- debconf information:
  shim/title/secureboot:
  shim/error/secureboot_key_mismatch:
  shim/secureboot_explanation:
  shim/error/bad_secureboot_key:
  shim/disable_secureboot: true
  shim/enable_secureboot: false

Bug#987461: libuima-adapter-soap-java is empty

[tony mancill]

On Sat, Jun 19, 2021 at 07:46:28AM -0700, tony mancill wrote:
> On Sat, Jun 19, 2021 at 10:29:25PM +0900, Hideki Yamane wrote:
> >  So let's remove its binary package and add Breaks: to it.
> >  MR is here, could someone review it, please?
> >  https://salsa.debian.org/java-team/uimaj/-/merge_requests/1
> 
> Thank you for addressing this.  I will handle the merge and upload.
> 
> Just one quick question...  Why is the Breaks necessary?  Is it there to
> force removal of libuima-adapter-soap-java when libuima-core-java is
> upgraded?

Hi,

I saw the note in the changelog that Breaks is in fact there to remove
the empty package, but it's not happening for me when I try to upgrade
locally.  My test case is to install uima-utils (which will install
libuima-adapter-soap-java via Recommends) and then try to upgrade the
binaries to 2.10.2-4 using dpkg.  

dpkg: regarding libuima-core-java_2.10.2-4_all.deb containing libuima-core-java:
 libuima-core-java breaks libuima-adapter-soap-java (<< 2.10.2-4)
  libuima-adapter-soap-java (version 2.10.2-3) is present and installed.

The only way I can make this work is remove libuima-adapter-soap-java
manually.  Are you sure that Breaks is necessary?  apt-get autoremove
will clean up libuima-adapter-soap-java at some point.

I took a look at policy to see if Breaks + Replaces should be used in
this situation, but I'm not sure it really applies (although I think it
would work better than just Breaks).  Still, I'm unsure about the need
for Breaks for this empty package clean-up use case.

From https://www.debian.org/doc/debian-policy/ch-relationships.html#s-breaks:

> Neither Breaks nor Conflicts should be used unless two packages cannot
> be installed at the same time or installing them both causes one of
> them to be broken or unusable. Having similar functionality or
> performing the same tasks as another package is not sufficient reason
> to declare Breaks or Conflicts with that package.

Any concerns if I drop the Breaks before the upload?

Thanks,
tony


signature.asc
Description: PGP signature

Bug#988188: Ignoring but #987904 for Bullseye: horizon plugin packaging design mistake

[Sebastian Ramacher]

On 2021-05-20 08:51:00 +0200, Thomas Goirand wrote:
> On 5/19/21 9:21 PM, Sebastian Ramacher wrote:
> > Control: tags -1 moreinfo
> > 
> > On 2021-05-07 10:56:51 +0200, Thomas Goirand wrote:
> >> Package: release.debian.org
> >> Severity: normal
> >>
> >> Hi,
> >>
> >> I need to discuss with the release team what to do in order to address
> >> this bug: https://bugs.debian.org/987904
> >>
> >> What happens is that each Horizon plugin is installing a bunch of python
> >> files under /etc/openstack-dashboard/enable.
> >>
> >> When an Horizon plugin is removed, as the enable folder is in /etc, the
> >> enable files of the plugins aren't removed. As a consequence, whenever
> >> Horizon attemps to list its plugins (for example, when it tries to do a
> >> "collect static" operation, which is kind of compiling all the JS files
> >> into a single one, each time a plugin is added/removed or when Horizon
> >> upgrades), it just fails, because the files in the enable folder are
> >> referencing Python modules that do not exist anymore (since the plugin
> >> package has been removed).
> >>
> >> The solution to fix this is strait forward: replace our symlink in
> >> /usr/lib/python3/dist-packages/openstack_dashboard/enable by a folder,
> >> and push the enable files in there instead of /etc. This way, the plugins
> >> removal will also remove the enable files.
> >>
> >> The problem is that there are 20 Horizon plugins in Debian, and at this
> >> point in the release cycle, it doesn't feel like it is a good time to
> >> update 20 packages.
> > 
> > Maybe I am missing some of the context, but it appears to me that in
> > if the case the plugin package was removed but not purged, a
> > ModuleNotFoundError is raised. So, wouldn't it be sufficient for horizon
> > to ignore those plugins that raise a ModuleNotFoundError?
> > 
> > Cheers
> 
> Hi Sebastian,
> 
> Thanks for your answer in this bug, I was desperate for an answer! :)
> 
> I tried to do as Andreas suggested, and then it fails later on, the code
> is harder to understand than just this.
> 
> At this point, I've been able to stage the fix in Experimental, and I am
> confident that I can backport the fixes to unstable. It's just a large
> amount of packages to patch, but I'm confident I can do it.
> 
> Your thoughts?

Sorry for slacking on a reply. If you still feel that you can do that
before the full freeze, please go ahead.

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#989958: libopencv-*-dev: Missing pkg-config file (.pc)

[Jochen Sprickerhof]

* Alejandro Colomar (man-pages)  [2021-06-21 17:35]:
Maybe Debian could write separate pkg-config files, and maybe offer 
them to upstream OpenCV (I offer myself to help write them if you 
decide it's a good idea).


It's easier if you talk to upstream about this directly. Adding them to 
Debian only would be incompatible with other distros and be of limited 
use.


Yes, for linking against the shared libraries, that's all you need: 
link against the module you want.  BUT, if you want to try to link 
against the static library (and now I'm talking from memory (it's been 
a year since I tried to do that, and I don't remember the result, I 
only remember a bunch of errors)), you'll need to know which libraries 
you need, which is the magic of pkg-config.


Static linking should work fine without pkg-config as well, except that 
you would have to list all dependencies, but looking at the opencv4.pc I 
guess they are incomplete anyhow ;).


Cheers Jochen


signature.asc
Description: PGP signature

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

[Sebastian Ramacher]

On 2021-06-18 17:42:44 +0200, Sebastiaan Couwenberg wrote:
> On 6/18/21 5:19 PM, Andreas Beckmann wrote:
> > On 18/06/2021 09.50, Sebastiaan Couwenberg wrote:
> >> I'm increasingly in favor of removing the Breaks from gdal-data, the
> >> attached procedure works for me in buster chroot.
> > 
> >> There is much less need for gdal-data breaking libgdal20 for us than
> >> there is in the UbuntuGIS PPA use case. I'm not aware of any packages
> >> that use gdal in the maintainer scripts that would be using the old gdal
> >> on their removal. So there shouldn't be any actual expected breakage.
> > 
> > Do you have some ideas what could break by installing gdal-data 3.x in
> > buster?
> 
> qgis crssync is a likely candidate, prior to PROJ 6 it relied more more
> heavily on the projection data included in gdal.
> 
> Other than that I don't know. You'd have to grep through the sources to
> find the functions using those files, and then search through reverse
> dependencies for use of those functions.
> 
> > I.e. on a partial upgrade. (Could someone run autopkgtests in
> > buster with the proposed gdal-data?)
> 
> Many of the gdal rdeps don't have autopkgtests, and the most prominents
> ones don't.
> 
> >> This change is minimal, doesn't require NEW packages, nor introduces
> >> divergence from upstream (as when the files would be moved to
> >> u/s/gdal/ in libgdal28), hence it's my preferred solution.
> > 
> > That's a bad upstream decision, but as you described them, they don't
> > care about upgrade paths :-(
> 
> PostGIS upstream are the ones who don't particular care about
> distribution upgrades. GDAL upstream is actually quite good (and
> responsible for the bulk of the work that went into PROJ 6).
> 
> >> If there is no objection, I'll upload gdal (3.2.2+dfsg-2) with the
> >> changes from the debdiff to unstable.
> > 
> > Sounds fine to me.
> 
> If the RMs are onboard as well, then let's not waste any more time on
> alternatives.

It's a step in the right direction. So, yes, please go ahead.

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#989964: unblock (pre-approval): flatpak/1.10.2-2

[Sebastian Ramacher]

Control: tags -1 moreinfo confirmed

On 2021-06-16 22:04:01 +0100, Simon McVittie wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: unblock
> 
> Would you be willing to accept an update to flatpak before full freeze?

Assuming that the upload happens soon, please go ahead and remove the
moreinfo tag once the new version is available in unstable.

Cheers

> 
> [ Reason ]
> Fix regressions for apps that use the "subsandbox" feature, such as
> Chromium.
> 
> [ Impact ]
> Flatpak apps that use the subsandbox interface to run part of themselves
> under tighter restrictions or with a different library stack can cause
> the flatpak-portal service to run out of file descriptors, preventing
> subsequent subsandboxes from starting (#989934, non-RC).
> Subsandboxes might run with unintended environment variables or without
> forwarding an intended file descriptor from the main app, or fail to
> start altogether (#989935, non-RC). I would rate the severity of both
> bugs as important, or maybe normal.
> 
> The backported changes also fix some minor memory leaks, which I backported
> in order to make the subsandbox changes apply cleanly. There's no bug
> report for these, but if there was, I'd rate it as minor severity.
> 
> [ Tests ]
> This is a straightforward backport of changes from upstream git master
> (soon to be released as 1.11.2), where they are covered by new automated
> tests. The tests are somewhat intrusive so I'm not backporting those
> right now, although they might be included in 1.10.3 upstream.
> 
> I've run manual tests for these two bugs on a bullseye system as described
> on .
> 
> There is autopkgtest coverage for Flatpak generally, although not yet for
> this specific feature. It can't be run on ci.debian.net due to not having
> isolation-machine testbeds available (flatpak doesn't work inside lxc),
> but I run the autopkgtests in a qemu VM before each upload.
> 
> [ Risks ]
> The changes are isolated to flatpak-portal (other than a few trivial
> memory-leak fixes elsewhere in the codebase), so the only programs that
> could regress are Flatpak apps that use the subsandbox interface, and
> those are the ones already affected by the bugs that I'm fixing.
> 
> [ 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
>   (preliminary debdiff, not yet released)
> 
> [ Other info ]
> If the SRMs allow it, I would like to follow the Flatpak 1.10.x release
> branch during bullseye until it is discontinued upstream, as I did
> for 0.8.x in stretch and 1.2.x in buster. I am an upstream maintainer
> and will be checking what gets backported into 1.10.x to make sure
> it remains manageable. Like previous stable branches, it will contain
> security fixes, bug fixes, and perhaps targeted feature enhancements
> where they are required for compatibility with apps and runtimes that
> users are likely to install.
> 
> We'll hopefully have a 1.10.3 upstream release reasonably soon, which could
> either go to bullseye before release or be saved for a stable update as part
> of the 11.1 point release, depending on timing and what the release team
> think of the diffstat.
> 
> Thanks,
> smcv

> diff --git a/debian/changelog b/debian/changelog
> index e4bb4964d..d36ce25db 100644
> --- a/debian/changelog
> +++ b/debian/changelog
> @@ -1,3 +1,21 @@
> +flatpak (1.10.2-2) UNRELEASED; urgency=medium
> +
> +  * Backport changes from upstream git to fix regressions when apps invoke
> +flatpak-spawn --env=... to launch a subsandbox.
> +- d/p/Fix-several-memory-leaks.patch:
> +  Fix minor memory leaks so that subsequent backports apply cleanly
> +- d/p/portal-Don-t-leak-fd-used-for-serialized-environment.patch:
> +  Don't leak a file descriptor each time flatpak-spawn --env=... is used
> +  (Closes: #989934)
> +- d/p/portal-Use-a-GArray-to-store-fds.patch,
> +  d/p/portal-Remap-env-fd-into-child-process-s-fd-space.patch:
> +  When an app uses flatpak-spawn --env=... --forward-fd=..., ensure
> +  that the file descriptors do not collide, which could result in the
> +  subsandbox failing to launch or being launched with wrong environment
> +  variables. (Closes: #989935)
> +
> + -- Simon McVittie   Wed, 16 Jun 2021 10:48:08 +0100
> +
>  flatpak (1.10.2-1) unstable; urgency=medium
>  
>* New upstream stable release
> diff --git a/debian/patches/Fix-several-memory-leaks.patch 
> b/debian/patches/Fix-several-memory-leaks.patch
> new file mode 100644
> index 0..2f0b53064
> --- /dev/null
> +++ b/debian/patches/Fix-several-memory-leaks.patch
> @@ -0,0 +1,86 @@
> +From: Phaedrus Leeds 
> +Date: Sun, 2 May 2021 21:53:02 -0500
> +Subject: Fix several memory leaks
> +
> +(cherry picked from commit 404d7c6941baf63d1b3ccbe9ee9d34f3ff12f35f)
> +
> 

Bug#990140: upgrade-reports: lxc-attach does not start with apparmor problem after ugrade to 10.10

[Bernd Breuer]

Hi Paul,

thanks for your immediate response.

Your assumption is right, booting into kernel 4.19.0-16 causes
lxc-attach to behave as expected, no more apparmor related errors.

Cheers Bernd


Am 21.06.21 um 19:06 schrieb Paul Gevers:

Hi Bernd,

Thanks for your report.

On 21-06-2021 18:04, Bernd Breuer wrote:

after the recent upgrade to Buster 10.10 (including a kernel upgrade) the 
command 'lxc-attach' (out of the Linux Container (lxc) set of commands), typed 
in like

"sudo lxc-attach "

stopped working with the error message

"lxc-attach: : lsm/lsm.c: lsm_process_label_set_at: 174 Operation not 
permitted - Failed to set AppArmor label "unconfined"

The conainer itself is starting, but apparmor related config lines like

"lxc.apparmor.profile = unconfined"

produce the above mentioned error, also on another machine after the
same packages upgrade.

I expect lxc-attach to provide me a root shell in the running lxc-container 
like  it was the case before the recent upgrade.

As we didn't upgrade lxc during the point release, this *may* be caused
by the updated Linux kernel. What happens if you reboot using the
previous kernel?

Paul

Bug#990157: privoxy: legacy conffiles leftover

[Christoph Anton Mitterer]

Package: privoxy
Version: 3.0.32-2
Severity: normal


Hi.

Apparently the package used to contain the conffiles:
/etc/privoxy/config
/etc/privoxy/standard.action
/etc/privoxy/global.action
but no longer does so.

Please properly clean them up using dpkg-maintscript-helper(1).
(AFAIU, the version that needs to be specified for that is NOT
the version where the conffile was dropped, but rather "the
latest version of the package whose upgrade should trigger
the operation"

Quoting the manpage:
   For example, for a conffile removed in version 2.0-1 of a package,
   prior-version should be set to 2.0-1~. This will cause the conffile
   to be removed even if the user rebuilt the previous version 1.0-1
   as 1.0-1local1. Or a package switching a path from a symlink
   (shipped in version 1.0-1) to a directory (shipped in version
   2.0-1), but only performing the actual switch in the maintainer
   scripts in version 3.0-1, should set prior-version to 3.0-1~.


Cheers,
Chris.

Bug#990156: mariadb-server-10.3: Service configuration fails package upgrade

[Chris Jackson]

Package: mariadb-server-10.3
Version: 1:10.3.27-0+deb10u1
Severity: important

When upgrading mariadb, the installation fails if the service is not
running or disabled:

> Preparing to unpack .../mariadb-server-10.3_1%3a10.3.29-0+deb10u1_armhf.deb 
> ...
> Failed to stop mariadb.service: Unit mariadb.service not loaded.
> dpkg: warning: old mariadb-server-10.3 package pre-removal script subprocess 
> returned error exit status 5
> dpkg: trying script from the new package instead ...
> Failed to stop mariadb.service: Unit mariadb.service not loaded.
> dpkg: error processing archive 
> /var/cache/apt/archives/mariadb-server-10.3_1%3a10.3.29-0+deb10u1_armhf.deb 
> (--unpack):
> new mariadb-server-10.3 package pre-removal script subprocess returned error 
> exit status 5

Being unable to stop or start the service should not block an upgrade.

-- System Information:
Debian Release: 10.10
  APT prefers stable
  APT policy: (990, 'stable'), (600, 'testing'), (500, 'testing-security'), 
(500, 'stable-updates')
Architecture: armhf (armv7l)

Kernel: Linux 5.10.0-7-armmp (SMP w/4 CPU threads)
Kernel taint flags: TAINT_CRAP, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.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 mariadb-server-10.3 depends on:
ii  adduser   3.118
ii  debconf [debconf-2.0] 1.5.71
ii  galera-3  25.3.25-2
ii  gawk  1:4.2.1+dfsg-1
ii  iproute2  4.20.0-2+deb10u1
ii  libc6 2.31-12
ii  libdbi-perl   1.642-1+deb10u2
ii  libgnutls30   3.7.1-3
ii  libpam0g  1.3.1-5
ii  libstdc++610.2.1-6
ii  lsb-base  10.2019051400
ii  lsof  4.91+dfsg-1
ii  mariadb-client-10.3   1:10.3.29-0+deb10u1
ii  mariadb-common1:10.3.29-0+deb10u1
ii  mariadb-server-core-10.3  1:10.3.29-0+deb10u1
ii  passwd1:4.5-1.1
ii  perl  5.28.1-6+deb10u1
ii  psmisc23.2-1
ii  rsync 3.1.3-6
ii  socat 1.7.3.2-2
ii  zlib1g1:1.2.11.dfsg-1

Versions of packages mariadb-server-10.3 recommends:
ii  libhtml-template-perl  2.97-1

Versions of packages mariadb-server-10.3 suggests:
ii  bsd-mailx [mailx]  8.1.2-0.20180807cvs-1
pn  mariadb-test   
ii  netcat-openbsd 1.195-2
pn  tinyca 

-- debconf information excluded

Bug#990155: scilab-cli: legacy conffiles leftover

[Christoph Anton Mitterer]

Package: scilab-cli
Version: 6.1.0+dfsg1-7
Severity: normal


Hi.

Apparently the package used to contain the conffiles:
/etc/bash_completion.d/scilab
but no longer does so.

Please properly clean them up using dpkg-maintscript-helper(1).
(AFAIU, the version that needs to be specified for that is NOT
the version where the conffile was dropped, but rather "the
latest version of the package whose upgrade should trigger
the operation"

Quoting the manpage:
   For example, for a conffile removed in version 2.0-1 of a package,
   prior-version should be set to 2.0-1~. This will cause the conffile
   to be removed even if the user rebuilt the previous version 1.0-1
   as 1.0-1local1. Or a package switching a path from a symlink
   (shipped in version 1.0-1) to a directory (shipped in version
   2.0-1), but only performing the actual switch in the maintainer
   scripts in version 3.0-1, should set prior-version to 3.0-1~.


Cheers,
Chris.

Bug#914076: Obsolete conffile /etc/bash_completion.d/cowbuilder not removed on upgrades

[Christoph Anton Mitterer]

Hey.

I also have the leftover conffile - and I always had the package
upgraded on unstable.


The reason is that the clean up seems to be done wrong:
it uses version 0.75
but according to the changelog, the cleanup was only added in 0.76.


(AFAIU, the version that needs to be specified for that is NOT
the version where the conffile was dropped, but rather "the
latest version of the package whose upgrade should trigger
the operation"

Quoting the manpage:
   For example, for a conffile removed in version 2.0-1 of a package,
   prior-version should be set to 2.0-1~. This will cause the conffile
   to be removed even if the user rebuilt the previous version 1.0-1
   as 1.0-1local1. Or a package switching a path from a symlink
   (shipped in version 1.0-1) to a directory (shipped in version
   2.0-1), but only performing the actual switch in the maintainer
   scripts in version 3.0-1, should set prior-version to 3.0-1~.


So anyone who had 0.75 installed, will not have it cleaned up.

Please fix the clean up in an upcoming version.


Cheers,
Chris.

Bug#989958: libopencv-*-dev: Missing pkg-config file (.pc)

[Jochen Sprickerhof]

Control: severity -1 wishlist

Hi Alejandro,

* Alejandro Colomar  [2021-06-16 17:31]:

None of them contain the needed pkg-conig files for their use, making
necessary to install 'libopencv', and making useless the separation into
smaller packages.


You don't need to use pkg-config to build against an OpenCV module, just 
running gcc with the flags you need will work. Adjusting severity 
accordingly.



If you can't install that file in every binary package, you may
create a new binary package that only contains the .pc file,
let's say libopencv-pc, and make all packages depend on it.


This sounds overly complicated to me. I think we should move all 
development files into one libopencv-dev if we want to fix this.

But that's choice of the maintainers.

Cheers Jochen


signature.asc
Description: PGP signature

Bug#990154: pcscd: legacy conffiles leftover

[Christoph Anton Mitterer]

Package: pcscd
Version: 1.9.1-1
Severity: normal


Hi.

Apparently the package used to contain the conffiles:
/etc/reader.conf.d/0comments
but no longer does so.

Please properly clean them up using dpkg-maintscript-helper(1).
(AFAIU, the version that needs to be specified for that is NOT
the version where the conffile was dropped, but rather "the
latest version of the package whose upgrade should trigger
the operation"

Quoting the manpage:
   For example, for a conffile removed in version 2.0-1 of a package,
   prior-version should be set to 2.0-1~. This will cause the conffile
   to be removed even if the user rebuilt the previous version 1.0-1
   as 1.0-1local1. Or a package switching a path from a symlink
   (shipped in version 1.0-1) to a directory (shipped in version
   2.0-1), but only performing the actual switch in the maintainer
   scripts in version 3.0-1, should set prior-version to 3.0-1~.



Also, it hadn't "registered" /etc/reader.conf.d/ so that will probably be left
over, too, unless some other package that contains it is installed (like 
libccid).


Cheers,
Chris.

Bug#943343: fwupd: fwupd-refresh.service failed to start Refresh fwupd metadata and update motd.

[Matthew Gabeler-Lee]

Package: fwupd
Version: 1.5.7-2
Followup-For: Bug #943343

This started out as what I thought may be the same essential data as Ross
Vandergrift reported above, but I think I've figured out the problem.

I'm seeing this same issue on a bullseye system.  Interestingly, not on
_all_ of my bullseye systems, even though I thought they were all configured
equivalently as far as this package would be concerned.

On the failing system, if I use `systemctl edit fwupd-refresh.service` to
change `StandardError` from `null` to `inherit`, I see this error when it
fails:

Jun 21 12:15:26 myhostname systemd[1]: Starting Refresh fwupd metadata and 
update motd...
Jun 21 12:15:26 myhostname fwupdmgr[3874480]: Failed to connect to daemon: 
Exhausted all available authentication mechanisms (tried: EXTERNAL) (available: 
EXTERNAL)
Jun 21 12:15:26 myhostname systemd[1]: fwupd-refresh.service: Main process 
exited, code=exited, status=1/FAILURE
Jun 21 12:15:26 myhostname systemd[1]: fwupd-refresh.service: Failed with 
result 'exit-code'.
Jun 21 12:15:26 myhostname systemd[1]: Failed to start Refresh fwupd metadata 
and update motd.

If I apply a fixed version of Ross' "strace" change to the refresh service
(need to clear ExecStart first), I see the "AUTH EXTERNAL" handshake is
_exactly_ the same ...  which I guess isn't the same because the dynamic
user id is chosen from hashing the same username, and so isn't actually all
that "dynamic".

Looking for other differences between the working and non-working systems, I
notice the working system has a
/etc/dbus-1/system.d/org.freedesktop.fwupd.conf file that is an exact copy
of its /usr/share/ counterpart.  But replicating that on the working system
and doing `systemctl reload dbus` doesn't fix things, and removing it on the
working system doesn't break things.

I resorted to rummaging in the dbus code itself to see why `AUTH EXTERNAL`
might fail, and most of it was pretty basic stuff like not providing a user,
or malloc failures or things like that, which I was pretty sure were not the
problem.  About the only thing left was this block of code:
https://github.com/freedesktop/dbus/blob/ef55a3db0d8f17848f8a579092fb05900cc076f5/dbus/dbus-auth.c#L1152

  if (!_dbus_credentials_add_from_user (auth->desired_identity,
>identity,
DBUS_CREDENTIALS_ADD_FLAGS_NONE,
))
{
// ...

  _dbus_verbose ("%s: could not get credentials from uid string: %s\n",
 DBUS_AUTH_NAME (auth), error.message);
  // ...
  return send_rejected (auth);
}
}

And thought "OK, so it wants to look up user info from a uid" and thought
"how the heck does that work with dynamic users?" On a lark I went looking
at /etc/nsswitch.conf on the working vs.  non-working systems, and noticed
that the working system has "systemd" listed under "passwd" and "group", and
has `libnss-systemd` installed. The non-working system has neither!

So I installed that package and did `sudo systemctl restart dbus` and ...

Voila! Broken system now works.

So, libnss-systemd is only a Recommends in various places.  This package
seems to _Depend_ on it being installed & configured for its default
installation to work properly.

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

Kernel: Linux 5.10.0-6-amd64 (SMP w/16 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 /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages fwupd depends on:
ii  libc6  2.31-12
ii  libcurl3-gnutls7.74.0-1.2
ii  libefiboot137-6
ii  libelf10.183-1
ii  libflashrom1   1.2-5
ii  libfwupd2  1.5.7-2
ii  libfwupdplugin11.5.7-2
ii  libglib2.0-0   2.66.8-1
ii  libgnutls303.7.1-5
ii  libgudev-1.0-0 234-1
ii  libgusb2   0.3.5-1
ii  libjcat1   0.1.3-2
ii  libjson-glib-1.0-0 1.6.2-1
ii  libpolkit-gobject-1-0  0.105-31
ii  libsmbios-c2   2.4.3-1
ii  libsqlite3-0   3.34.1-3
ii  libsystemd0247.3-5
ii  libtss2-esys-3.0.2-0   3.0.3-2
ii  libxmlb1   0.1.15-2
ii  shared-mime-info   2.0-1

Versions of packages fwupd recommends:
pn  bolt   
ii  dbus   1.12.20-2
ii  fwupd-amd64-signed [fwupd-signed]  1.5.7+2
ii  python33.9.2-3
pn  secureboot-db  
ii  udisks22.9.2-2

Versions of packages fwupd suggests:
pn  gir1.2-fwupd-2.0  

-- Configuration Files:
/etc/fwupd/uefi_capsule.conf changed [not included]

-- no debconf information

Bug#990153: oggz-tools: legacy conffiles leftover

[Christoph Anton Mitterer]

Package: oggz-tools
Version: 1.1.1-7
Severity: normal


Hi.

Apparently the package used to contain the conffiles:
/etc/bash_completion.d/oggz
but no longer does so.

Please properly clean them up using dpkg-maintscript-helper(1).
(AFAIU, the version that needs to be specified for that is NOT
the version where the conffile was dropped, but rather "the
latest version of the package whose upgrade should trigger
the operation"

Quoting the manpage:
   For example, for a conffile removed in version 2.0-1 of a package,
   prior-version should be set to 2.0-1~. This will cause the conffile
   to be removed even if the user rebuilt the previous version 1.0-1
   as 1.0-1local1. Or a package switching a path from a symlink
   (shipped in version 1.0-1) to a directory (shipped in version
   2.0-1), but only performing the actual switch in the maintainer
   scripts in version 3.0-1, should set prior-version to 3.0-1~.


Cheers,
Chris.

Bug#990152: supysonic: wrong bootstrap css files symlinked

[Louis-Philippe Véronneau]

Package: supysonic
Version: 0.6.2+ds-3
Severity: normal

We're not symlinking the right bootstrap files. Supysonic wants .min.css
files and we're symlinking the non-minimzed files...

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



OpenPGP_signature
Description: OpenPGP digital signature

Bug#990146: tracker-store failure when extracting metadata

[Philip Stewart]

Apologies - my original message appears to have become garbled.

Attaching the log messages instead:

journalctl.log - observed error

I have tried resetting the databases and restarting the tracker daemon, 
but the problem persists.


tracker_extract.log - snipped identified by tracker daemon as relevant 
for bug report


verbose_tracker_extract.log - output of the suggestion in the snippet 
above


Cheers,
Phil


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

Kernel: Linux 5.10.0-7-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en

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

Versions of packages tracker depends on:
ii  dbus-user-session [default-dbus-session-bus]  1.12.20-2
ii  dbus-x11 [dbus-session-bus]   1.12.20-2
ii  dconf-gsettings-backend [gsettings-backend]   0.38.0-2
ii  libc6 2.31-12
ii  libglib2.0-0  2.66.8-1
ii  libglib2.0-bin2.66.8-1
ii  libicu67  67.1-6
ii  libsqlite3-0  3.34.1-3
ii  libstemmer0d  2.1.0-1
ii  libtracker-control-2.0-0  2.3.6-2
ii  libtracker-sparql-2.0-0   2.3.6-2
ii  shared-mime-info  2.0-1

Versions of packages tracker recommends:
ii  tracker-miner-fs  2.3.5-2

tracker suggests no packages.

-- no debconf information

Jun 21 14:47:38 kernel: traps: pool-tracker-st[3258] trap int3 ip:7f8801816ca7 sp:7f87fca43be0 error:0 in libglib-2.0.so.0.6600.8[7f88017da000+88000]
Jun 21 14:47:38 tracker-store[3251]: SQLite error: database disk image is malformed (errno: Success)
Jun 21 14:47:38 tracker-store[3251]: SQLite experienced an error with file:'/home/philip/.cache/tracker/meta.db'. It is either NOT a SQLite database or it is corrupt or there was an IO error accessing the data. This file has now been removed and will be recreated on the next start. Shutting down now.
Jun 21 14:47:38 systemd[1604]: tracker-store.service: Main process exited, code=killed, status=5/TRAP
Jun 21 14:47:38 systemd[1604]: tracker-store.service: Failed with result 'signal'.
Jun 21 14:47:38 systemd[1604]: tracker-store.service: Consumed 1min 43.874s CPU time.
Jun 21 14:47:38 tracker-extract[3479]: There was an error pushing metadata: GDBus.Error:org.freedesktop.DBus.Error.NoReply: Message recipient disconnected from message bus without replying
..
Jun 21 14:53:22 tracker-extract[3479]: Could not insert metadata for item "file:///usr/share/applications/org.gnome.DiskUtility.desktop": Subject `urn:uuid:ca70bdea-6f53-4426-89aa-61d87f5c1179' is not in domain `nie:DataObject' of property `nie:dataSource'
Jun 21 14:53:22 tracker-extract[3479]: If the error above is recurrent for the same item/ID, consider running "tracker-extract" in the terminal with the TRACKER_VERBOSITY=3 environment variable, and filing a bug with the additional information
$ TRACKER_VERBOSITY=3 tracker extract Music/David\ Bowie/The\ Platinum\ Collection/1-17\ -\ Aladdin\ Sane.ogg 
Tracker-Message: 14:58:55.182: Set scheduler policy to SCHED_IDLE
Tracker-Message: 14:58:55.182: Setting priority nice level to 19
Tracker-Message: 14:58:55.192: Starting tracker-extract 2.3.5
(tracker-extract:3990): dconf-DEBUG: 14:58:55.192: watch_established: "/org/freedesktop/tracker/extract/" (establishing: 1)
Tracker-Message: 14:58:55.202: General options:
Tracker-Message: 14:58:55.202:   Verbosity    0
Tracker-Message: 14:58:55.202:   Sched Idle  ...  1
Tracker-Message: 14:58:55.202:   Max bytes (per file)  .  1048576
Tracker-Message: 14:58:55.202: Set scheduler policy to SCHED_IDLE
Tracker-Message: 14:58:55.203: Setting priority nice level to 19
(tracker-extract:3990): GLib-GIO-DEBUG: 14:58:55.206: _g_io_module_get_default: Found default implementation gvfs (GDaemonVfs) for ‘gio-vfs’
Tracker-Message: 14:58:55.206: Loading extractor rules... (/usr/share/tracker-miners/extract-rules)
(tracker-extract:3990): Tracker-DEBUG: 14:58:55.206:   Loaded rule '10-abw.rule'
(tracker-extract:3990): Tracker-DEBUG: 14:58:55.206:   Loaded rule '10-bmp.rule'
(tracker-extract:3990): Tracker-DEBUG: 14:58:55.206:   Loaded rule '10-comics.rule'
(tracker-extract:3990): Tracker-DEBUG: 14:58:55.206:   Loaded rule '10-desktop.rule'
(tracker-extract:3990): Tracker-DEBUG: 14:58:55.206:   Loaded rule '10-dvi.rule'
(tracker-extract:3990): Tracker-DEBUG: 14:58:55.207:   Loaded rule '10-ebooks.rule'
(tracker-extract:3990): Tracker-DEBUG: 14:58:55.207:   Loaded rule '10-epub.rule'
(tracker-extract:3990): Tracker-DEBUG: 

Bug#990151: libifd-cyberjack6: legacy conffiles leftover

[Christoph Anton Mitterer]

Package: libifd-cyberjack6
Version: 3.99.5final.sp14-2
Severity: normal


Hi.

Apparently the package used to contain the conffiles:
/etc/cyberjack/cyberjack.conf
but no longer does so.

Please properly clean them up using dpkg-maintscript-helper(1).
(AFAIU, the version that needs to be specified for that is NOT
the version where the conffile was dropped, but rather "the
latest version of the package whose upgrade should trigger
the operation"

Quoting the manpage:
   For example, for a conffile removed in version 2.0-1 of a package,
   prior-version should be set to 2.0-1~. This will cause the conffile
   to be removed even if the user rebuilt the previous version 1.0-1
   as 1.0-1local1. Or a package switching a path from a symlink
   (shipped in version 1.0-1) to a directory (shipped in version
   2.0-1), but only performing the actual switch in the maintainer
   scripts in version 3.0-1, should set prior-version to 3.0-1~.


Cheers,
Chris.

Bug#990150: supysonic: please add an apache vhost example

[Louis-Philippe Véronneau]

Package: supysonic
Version: 0.6.2+ds-3
Severity: wishlist

The apache configuration to run supysonic is not trivial. It would be a
good idea to provide a working example. I'm currently using this (it
requires setting up a supysonic user though):

-

  ServerName supysonic.fqdn.net
  DocumentRoot /usr/share/supysonic

  ErrorLog ${APACHE_LOG_DIR}/error.log

  WSGIDaemonProcess supysonic user=supysonic group=supysonic threads=3
  WSGIScriptAlias / /usr/share/supysonic/supysonic/supysonic.wsgi

  
WSGIApplicationGroup %{GLOBAL}
WSGIPassAuthorization On
Options FollowSymLinks
Require all granted
  

  SSLEngine on
  SSLCertificateFile  /etc/letsencrypt/live/supysonic.fqdn.net/cert.pem
  SSLCertificateKeyFile   /etc/letsencrypt/supysonic.fqdn.net/privkey.pem
  SSLCertificateChainFile /etc/letsencrypt/supysonic.fqdn.net/chain.pem




# SSL options
SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1
SSLCipherSuite
ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256
SSLHonorCipherOrder on
SSLCompression  off
SSLSessionTickets   off

# OCSP Stapling
SSLUseStapling  on
SSLStaplingResponderTimeout 5
SSLStaplingReturnResponderErrors off
SSLStaplingCacheshmcb:/var/run/ocsp(128000)


  ServerName supysonic.fqdn.net

  Redirect / https://supysonic.fqdn.net/

-

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



OpenPGP_signature
Description: OpenPGP digital signature

Bug#989839: closed by Debian FTP Masters (reply to Carsten Schoenert ) (Bug#990012: fixed in thunderbird 1:78.11.0-2)

[Benjamin Bänziger]

Thank you!

Bug#990149: supysonic: the WSGI file shipped in Debian doesn't work

[Louis-Philippe Véronneau]

Package: supysonic
Version: 0.6.2+ds-3
Severity: normal

The WSGI file we're shipping in Debian doesn't work, because the python
files are outside of the regular PYTHONPATH. This results in a
`supysonic module not found` error.

This one works though:

---
import sys, os

path_to_app = "/usr/share/supysonic"

sys.path.insert(0, path_to_app)

from supysonic.web import create_application
application = create_application()
---

Upstream has stopped shipping those files anyway, so we'll have to
provide one regardless.

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



OpenPGP_signature
Description: OpenPGP digital signature

Bug#985644: libgssapi-krb5-2: properly dispose of /etc/gss/mech.d/README on upgrades

[Christoph Anton Mitterer]

The other bug is 910344, which in turn refers to #868121.

But TBH, I don't quite understand why this should be a wontfix.


- The file seems to be a plain README file with no further
functionality so is there any good reason for leaving over that
obsolete stuff?
New installations don't get it either - and still work just fine.


- As mentioned in #868121 the policy says:
https://www.debian.org/doc/debian-policy/ch-files.html#s10.7.3
"Obsolete configuration files without local changes should be removed
by the package during upgrade."

Benjamin's point that this wouldn't be a conffile
(https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=868121#25) is not
really valid, IMO:

it's registered in dpkg as a conffile => it's a conffile => it's
configuration



I mean you could still leave it in place if it would actually have user
modifications, but even then it should be unregistered as a conffile
with by using dpkg-maintscript-helper(1).

(AFAIU, the version that needs to be specified for that is NOT
the version where the conffile was dropped, but rather "the
latest version of the package whose upgrade should trigger
the operation"

Quoting the manpage:
   For example, for a conffile removed in version 2.0-1 of a package,
   prior-version should be set to 2.0-1~. This will cause the conffile
   to be removed even if the user rebuilt the previous version 1.0-1
   as 1.0-1local1. Or a package switching a path from a symlink
   (shipped in version 1.0-1) to a directory (shipped in version
   2.0-1), but only performing the actual switch in the maintainer
   scripts in version 3.0-1, should set prior-version to 3.0-1~.


Cheers,
Chris.

Bug#990140: upgrade-reports: lxc-attach does not start with apparmor problem after ugrade to 10.10

[Paul Gevers]

Hi Bernd,

Thanks for your report.

On 21-06-2021 18:04, Bernd Breuer wrote:
> after the recent upgrade to Buster 10.10 (including a kernel upgrade) the 
> command 'lxc-attach' (out of the Linux Container (lxc) set of commands), 
> typed in like
> 
> "sudo lxc-attach "
> 
> stopped working with the error message
> 
> "lxc-attach: : lsm/lsm.c: lsm_process_label_set_at: 174 
> Operation not permitted - Failed to set AppArmor label "unconfined"
> 
> The conainer itself is starting, but apparmor related config lines like
> 
> "lxc.apparmor.profile = unconfined"
> 
> produce the above mentioned error, also on another machine after the
> same packages upgrade.
> 
> I expect lxc-attach to provide me a root shell in the running lxc-container 
> like  it was the case before the recent upgrade.

As we didn't upgrade lxc during the point release, this *may* be caused
by the updated Linux kernel. What happens if you reboot using the
previous kernel?

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#990148: supysonic: jquery should be symlinked

[Louis-Philippe Véronneau]

Package: supysonic
Version: 0.6.2+ds-3
Severity: normal

We're currently patching the upstream code to use Debian's version of
jquery [1].

This wasn't done right though. Instead of trying to load the file
directly from /usr/share/javascript, it should be symlinked in the
/static directory, like the other JS libs.

On web servers, this makes it impossible to load jquery.

[1]:
https://salsa.debian.org/python-team/packages/supysonic/-/blob/debian/master/debian/patches/0004_Embedded_JS_Libs.patch#L11

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



OpenPGP_signature
Description: OpenPGP digital signature

Bug#990026: Commonly-in-use characters

[Matthias Urlichs]

So far, we identified "/" and "=" as characters which definitely should 
be restored in order to not break our installations.


--
-- Matthias Urlichs




OpenPGP_signature
Description: OpenPGP digital signature

Bug#990147: ifscheme: legacy conffiles leftover

[Christoph Anton Mitterer]

Package: ifscheme
Version: 1.7-6
Severity: normal


Hi.

Apparently the package used to contain the conffiles:
/etc/bash_completion.d/ifscheme
but no longer does so.

Please properly clean them up using dpkg-maintscript-helper(1).
(AFAIU, the version that needs to be specified for that is NOT
the version where the conffile was dropped, but rather "the
latest version of the package whose upgrade should trigger
the operation"

Quoting the manpage:
   For example, for a conffile removed in version 2.0-1 of a package,
   prior-version should be set to 2.0-1~. This will cause the conffile
   to be removed even if the user rebuilt the previous version 1.0-1
   as 1.0-1local1. Or a package switching a path from a symlink
   (shipped in version 1.0-1) to a directory (shipped in version
   2.0-1), but only performing the actual switch in the maintainer
   scripts in version 3.0-1, should set prior-version to 3.0-1~.


Cheers,
Chris.

Bug#990146: tracker-store failure when extracting metadata

[Philip Stewart]

Package: tracker
Version: 2.3.6-2

Dear Maintainer,

I am encountering an error with tracker failing to store metadata and 
consuming resources as it repeatedly tries and fails to continue.


A consequence of this is that one can no longer benefit from indexed 
data for rapid searching in nautilus.


In the system logs, I observe:

--
Jun 21 14:47:38 kernel: traps: pool-tracker-st[3258] trap int3 
ip:7f8801816ca7 sp:7f87fca43be0 error:0 in 
libglib-2.0.so.0.6600.8[7f88017da000+88000]
Jun 21 14:47:38 tracker-store[3251]: SQLite error: database disk image 
is malformed (errno: Success)
Jun 21 14:47:38 tracker-store[3251]: SQLite experienced an error with 
file:'/home/philip/.cache/tracker/meta.db'. It is either NOT a SQLite 
database or it is corrupt or there was an IO error accessing the data. 
This file has now been removed and will be recreated on the next start. 
Shutting down now.
Jun 21 14:47:38 systemd[1604]: tracker-store.service: Main process 
exited, code=killed, status=5/TRAP
Jun 21 14:47:38 systemd[1604]: tracker-store.service: Failed with 
result 'signal'.
Jun 21 14:47:38 systemd[1604]: tracker-store.service: Consumed 1min 
43.874s CPU time.
Jun 21 14:47:38 tracker-extract[3479]: There was an error pushing 
metadata: GDBus.Error:org.freedesktop.DBus.Error.NoReply: Message 
recipient disconnected from message bus without replying

--

Soon followed by repeated messages, such as:

--
Jun 21 14:53:22 tracker-extract[3479]: Could not insert metadata for 
item "file:///usr/share/applications/org.gnome.DiskUtility.desktop": 
Subject `urn:uuid:ca70bdea-6f53-4426-89aa-61d87f5c1179' is not in 
domain `nie:DataObject' of property `nie:dataSource'

--

I have tried resetting the databases and restarting the tracker daemon, 
but the problem persists.


Increasing the log verbosity on the tracker daemon, it identifies the 
following is relevant for a bug report:


--
Jun 21 14:49:14 tracker-extract[3479]: 
--8<--
Jun 21 14:49:14 tracker-extract[3479]: The information relevant for a 
bug report is between the dotted lines
Jun 21 14:49:15 tracker-extract[3479]: Could not insert metadata for 
item 
"file:///home/philip/Music/David%20Bowie/The%20Platinum%20Collection/1-17%20-%20Aladdin%20Sane.ogg": 
Subject `urn:uuid:1c8c66e4-4895-48fc-ae55-da7bb55a3dc7' is not in 
domain `nie:DataObject' of property `nie:dataSource'
Jun 21 14:49:15 tracker-extract[3479]: If the error above is recurrent 
for the same item/ID, consider running "tracker-extract" in the 
terminal with the TRACKER_VERBOSITY=3 environment variable, and filing 
a bug with the additional information

Jun 21 14:49:15 tracker-extract[3479]: Sparql was:
   DELETE WHERE {
   GRAPH 
 {
 
 nfo:genre ?nfo_genre } 
};

   DELETE WHERE {
   GRAPH 
 {
 
 nmm:trackNumber 
?nmm_trackNumber } };

   DELETE WHERE {
   GRAPH 
 {
 
 nmm:performer 
?nmm_performer } };

   DELETE WHERE {
   GRAPH 
 {
 
 
tracker:hasExternalReference ?tracker_hasExternalReference } };

   DELETE WHERE {
   GRAPH 
 {
 
 nfo:averageBitrate 
?nfo_averageBitrate } };

   DELETE WHERE {
   GRAPH 
 {
 
 nie:title ?nie_title } 
};

   DELETE WHERE {
   GRAPH 
 {
 
 nie:contentCreated 
?nie_contentCreated } };

   DELETE WHERE {
   GRAPH 
 {
 
 nmm:musicAlbum 
?nmm_musicAlbum } };

   DELETE WHERE {
   GRAPH 
 {
 
 nmm:musicAlbumDisc 
?nmm_musicAlbumDisc } };

   DELETE WHERE {
   GRAPH 
 {
 
 nfo:duration 
?nfo_duration } };

   DELETE WHERE {
   GRAPH 
 {
 
 tracker:hasExternalReference 
?tracker_hasExternalReference } };

   DELETE WHERE {

Bug#990145: grub-pc: legacy conffiles leftover

[Christoph Anton Mitterer]

Package: grub-pc
Version: 2.04-19
Severity: normal



Hi.

Apparently the package used to contain the conffiles:
/etc/default/grub
but no longer does so.

Please properly clean them up using dpkg-maintscript-helper(1).
(AFAIU, the version that needs to be specified for that is NOT
the version where the conffile was dropped, but rather "the
latest version of the package whose upgrade should trigger
the operation"

Quoting the manpage:
   For example, for a conffile removed in version 2.0-1 of a package,
   prior-version should be set to 2.0-1~. This will cause the conffile
   to be removed even if the user rebuilt the previous version 1.0-1
   as 1.0-1local1. Or a package switching a path from a symlink
   (shipped in version 1.0-1) to a directory (shipped in version
   2.0-1), but only performing the actual switch in the maintainer
   scripts in version 3.0-1, should set prior-version to 3.0-1~.


Cheers,
Chris.

Bug#989069: nvidia-driver: Crash when displayport is plugged.

[Christian Marillat]

On 25 mai 2021 08:10, Andreas Beckmann  wrote:

[...]

>> Bug already reported upstream here :
>
> Not much we can do here :-( (besides not migrating this version to bullseye)

Seems to be fixed :

https://forums.developer.nvidia.com/t/465-24-02-page-fault/175782/135

Christian

Bug#924643: RFS: colorzero/2.0-1 [ITP] -- Construct, convert, and manipulate colors in a Pythonic manner.

[Emmanuel Arias]

Hi

On 6/21/21 11:06 AM, Dave Jones wrote:
> Hi Emmanuel,
>
> On Sat, Jun 19, 2021 at 06:40:58PM -0300, Emmanuel Arias wrote:
>>
>> On 6/19/21 9:03 AM, Peter Green wrote:
>>> Just done some reviewing/tweaking. I've pushed the following changes
>>> to the git repo, please tell me if you have any objections.
>>>
>>> I added a gpb.conf to make git-buildpackage actually use pristine
>>> tar and hence result in an orig tarball that was consistent with
>>> what is already in Ubuntu.
>>
>> Also, you can try to follow DEP-14 (although is mark as candidate)
>> and add debian/master as default branch.
>
> Ah, this was something that confused me a bit when initially working
> on this. I'd read through DEP-14, but then figured a simple way to
> start would be to grab my existing packaging for Raspbian and use gbp
> import-dsc on it. This set up the repo with a "master" branch rather
> than "debian/master" and I then wondered if I'd mis-interpreted
> DEP-14's prescription to use "debian/master", and whether it meant one
> should use "debian" branch or alternatively a "master" branch.
I think that I don't understand you, sorry :(. But DEP-14 recommend the
use of /* for name the branchs, so for debian the branch should
be debian/*, for ubuntu ubuntu/*, etc.
>
> Anyway, given it should be "debian/master" I'll get that corrected (I
> assume I'm right in thinking that'll need a
> "debian-branch=debian/master" addition to gbp.conf).
>
yes. (and also create it first)
>> What about enable salsa-ci?
>
> Certainly something on the todo list, but not something I'd read up on
> yet. I'll have a look at that this afternoon.
>
I see that you already add the file. Don't forget activate ci in the
repository configuration :)

Cheers,

-- 
Emmanuel Arias
@eamanu
yaerobi.com



OpenPGP_0xFA9DEC5DE11C63F1.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#990144: fail2ban: legacy conffiles leftover

[Christoph Anton Mitterer]

Package: fail2ban
Version: 0.11.2-1
Severity: normal


Hi.

Apparently the package used to contain the conffiles:
/etc/bash_completion.d/fail2ban
/etc/fail2ban/action.d/nftables-common.conf
/etc/fail2ban/filter.d/sshd-ddos.conf
/etc/fail2ban/filter.d/sshd-aggressive.conf
/etc/fail2ban/filter.d/postfix-sasl.conf
/etc/fail2ban/filter.d/postfix-rbl.conf
but no longer does so.

Please properly clean them up using dpkg-maintscript-helper(1).
(AFAIU, the version that needs to be specified for that is NOT
the version where the conffile was dropped, but rather "the
latest version of the package whose upgrade should trigger
the operation"

Quoting the manpage:
   For example, for a conffile removed in version 2.0-1 of a package,
   prior-version should be set to 2.0-1~. This will cause the conffile
   to be removed even if the user rebuilt the previous version 1.0-1
   as 1.0-1local1. Or a package switching a path from a symlink
   (shipped in version 1.0-1) to a directory (shipped in version
   2.0-1), but only performing the actual switch in the maintainer
   scripts in version 3.0-1, should set prior-version to 3.0-1~.


Cheers,
Chris.

Bug#681626: ekeyd: doesn't clean up configfiles

[Christoph Anton Mitterer]

Hey.

Anything new on this?


Please properly clean them up using dpkg-maintscript-helper(1).
(AFAIU, the version that needs to be specified for that is NOT
the version where the conffile was dropped, but rather "the
latest version of the package whose upgrade should trigger
the operation"

Quoting the manpage:
   For example, for a conffile removed in version 2.0-1 of a package,
   prior-version should be set to 2.0-1~. This will cause the conffile
   to be removed even if the user rebuilt the previous version 1.0-1
   as 1.0-1local1. Or a package switching a path from a symlink
   (shipped in version 1.0-1) to a directory (shipped in version
   2.0-1), but only performing the actual switch in the maintainer
   scripts in version 3.0-1, should set prior-version to 3.0-1~.

Cheers,
Chris.

Bug#990142: unblock: debian-edu/2.11.37

[Holger Levsen]

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

Please unblock package debian-edu bringing a rather trival improvement to Debian
Edu, which I'd still consider worthwhile having. The potential (bad) impact is
low and definitly limited to Debian Edu...

The full diff:

$ debdiff debian-edu_2.11.36.dsc debian-edu_2.11.37.dsc
diff -Nru debian-edu-2.11.36/debian/changelog 
debian-edu-2.11.37/debian/changelog
--- debian-edu-2.11.36/debian/changelog 2021-03-28 12:35:03.0 +0200
+++ debian-edu-2.11.37/debian/changelog 2021-06-09 23:14:40.0 +0200
@@ -1,3 +1,11 @@
+debian-edu (2.11.37) unstable; urgency=medium
+
+  [ Wolfgang Schweer ]
+  * tasks/common: Recommend plocate as preferred locate. (Closes: #989518)
+Thanks to Paul Wise for informing us.
+
+ -- Holger Levsen   Wed, 09 Jun 2021 23:14:40 +0200
+
 debian-edu (2.11.36) unstable; urgency=medium
 
   [ Wolfgang Schweer ]
diff -Nru debian-edu-2.11.36/debian/control debian-edu-2.11.37/debian/control
--- debian-edu-2.11.36/debian/control   2021-03-28 12:34:58.0 +0200
+++ debian-edu-2.11.37/debian/control   2021-06-09 23:14:40.0 +0200
@@ -116,7 +116,6 @@
 lsscsi,
 mc,
 memtest86+,
-mlocate,
 mtools,
 mtr-tiny | mtr,
 ncftp,
@@ -124,6 +123,7 @@
 nullidentd | ident-server,
 openbsd-inetd,
 pciutils,
+plocate | mlocate,
 procinfo,
 procmail,
 psmisc,
diff -Nru debian-edu-2.11.36/tasks/common debian-edu-2.11.37/tasks/common
--- debian-edu-2.11.36/tasks/common 2021-02-07 11:47:11.0 +0100
+++ debian-edu-2.11.37/tasks/common 2021-06-09 18:04:22.0 +0200
@@ -35,7 +35,7 @@
  lsscsi,
  sysfsutils,
  etherwake,
- mlocate,
+ plocate | mlocate,
 
 Recommends:
  iputils-arping | arping,


unblock debian-edu/2.11.37

Thanks for your work on bullseye!


-- 
cheers,
Holger

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

Not everything was bad during capitalism.


signature.asc
Description: PGP signature

Bug#990140: upgrade-reports: lxc-attach does not start with apparmor problem after ugrade to 10.10

[Bernd Breuer]

Package: upgrade-reports
Severity: normal

Dear Maintainer,

after the recent upgrade to Buster 10.10 (including a kernel upgrade) the 
command 'lxc-attach' (out of the Linux Container (lxc) set of commands), typed 
in like

"sudo lxc-attach "

stopped working with the error message

"lxc-attach: : lsm/lsm.c: lsm_process_label_set_at: 174 
Operation not permitted - Failed to set AppArmor label "unconfined"

The conainer itself is starting, but apparmor related config lines like

"lxc.apparmor.profile = unconfined"

produce the above mentioned error, also on another machine after the
same packages upgrade.

I expect lxc-attach to provide me a root shell in the running lxc-container 
like  it was the case before the recent upgrade.

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

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

Bug#990139: unblock: debian-edu-config/2.11.56

[Holger Levsen]

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

Please unblock package debian-edu-config 2.11.56 containing three small and 
targeded fixes
for three bugs concerning Debian Edu only, thus with no impact outside Debian 
Edu.

The diff is:

$ debdiff debian-edu-config_2.11.55.dsc debian-edu-config_2.11.56.dsc|diffstat
 cf3/cf.exim   |6 +++
 debian/changelog  |   24 ++
 sbin/debian-edu-ltsp-install  |7 ++--
 share/debian-edu-config/isc-dhcp-server.service   |2 -
 share/debian-edu-config/isc-dhcp-server.service.eth1_only |2 -
 5 files changed, 36 insertions(+), 5 deletions(-)
$ debdiff debian-edu-config_2.11.55.dsc debian-edu-config_2.11.56.dsc
diff -Nru debian-edu-config-2.11.55/debian/changelog 
debian-edu-config-2.11.56/debian/changelog
--- debian-edu-config-2.11.55/debian/changelog  2021-04-29 15:27:17.0 
+0200
+++ debian-edu-config-2.11.56/debian/changelog  2021-06-05 00:06:13.0 
+0200
@@ -1,3 +1,27 @@
+debian-edu-config (2.11.56) unstable; urgency=medium
+
+  [ Wolfgang Schweer ]
+  * Adjust workaround for isc-dhcp-server-ldap bug #971275. (Closes: #989340)
+- share/debian-edu-config/isc-dhcp-server.{service,service.eth1_only}:
+  Use ExecStartPre command inspired by the isc-dhcp-server init script
+  instead of a sleep command.
+  * Adjust Exim configuration on client systems. (Closes: #989338)
+- cf3/cf.exim:
+  Use exim-ldap-client-v4.conf file as exim4.conf on client machines 
instead
+  of preseeded configuration. This way sending system emails to the main
+  server is working again after the exim4 4.94 changes.
+  * Adjust sbin/debian-edu-ltsp-install. (Closes: #989342)
+- Drop line containing the cp command (/var/cache/apt doesn't contain .bin
+  files in all use cases and the benefit is minimal if they exist; also, 
the
+  pkgcache.bin and srcpkgcache.bin files might contain outdated data).
+- Use the BD ISO image to setup X2Go thin client support only if the script
+  is run inside the Debian Installer environment. There are too many ways
+  to install a combined server (with or without Internet connection, with
+  or without adjusting the sources list, with or without running apt 
update)
+  to cover all these cases.
+
+ -- Holger Levsen   Sat, 05 Jun 2021 00:06:13 +0200
+
 debian-edu-config (2.11.55) unstable; urgency=medium
 
   [ Wolfgang Schweer ]
diff -Nru debian-edu-config-2.11.55/cf3/cf.exim 
debian-edu-config-2.11.56/cf3/cf.exim
--- debian-edu-config-2.11.55/cf3/cf.exim   2019-02-15 11:58:02.0 
+0100
+++ debian-edu-config-2.11.56/cf3/cf.exim   2021-06-02 14:00:53.0 
+0200
@@ -10,6 +10,12 @@
   move_obstructions => "true";
 "/etc/default/exim4"
   edit_line => exim_default;
+
+  debian.!server.(workstation|minimal).installation::
+
+"/etc/exim4/exim4.conf"
+  link_from => ln_s("/etc/exim4/exim-ldap-client-v4.conf"),
+  move_obstructions => "true";
 }
 
 bundle edit_line exim_default
diff -Nru debian-edu-config-2.11.55/sbin/debian-edu-ltsp-install 
debian-edu-config-2.11.56/sbin/debian-edu-ltsp-install
--- debian-edu-config-2.11.55/sbin/debian-edu-ltsp-install  2021-04-26 
23:38:21.0 +0200
+++ debian-edu-config-2.11.56/sbin/debian-edu-ltsp-install  2021-06-02 
23:20:03.0 +0200
@@ -341,8 +341,10 @@
 show=false
 EOF
 
-# Specific settings needed if BD ISO image is used for installation.
-if grep -q BD /etc/apt/sources.list ; then
+# Specific settings needed if BD ISO image is used for installation inside d-i.
+# First part of next condition: Looking for file created by base-installer and
+# removed at the end of the d-i run.
+if [ -e /etc/apt/apt.conf.d/00IgnoreTimeConflict ] && grep -q BD 
/etc/apt/sources.list ; then
BD_ISO="true";
device="$(grep media/cdrom /etc/fstab | cut -d' ' -f1)"
mirror="file:///media/cdrom/"
@@ -365,7 +367,6 @@
if [ "true" == "$BD_ISO" ] ; then
mkdir -p /srv/ltsp/thin/"$thin_type"-"$arch"/media/cdrom
mount $device /srv/ltsp/thin/"$thin_type"-"$arch"/media/cdrom
-   cp /var/cache/apt/*.bin 
/srv/ltsp/thin/"$thin_type"-"$arch"/var/cache/apt/
echo "deb [trusted=yes] $mirror $dist main" > 
/srv/ltsp/thin/"$thin_type"-"$arch"/etc/apt/sources.list
fi
chroot /srv/ltsp/thin/"$thin_type"-"$arch"/ apt -y -qq install 
education-thin-client p910nd
diff -Nru 
debian-edu-config-2.11.55/share/debian-edu-config/isc-dhcp-server.service 
debian-edu-config-2.11.56/share/debian-edu-config/isc-dhcp-server.service
--- debian-edu-config-2.11.55/share/debian-edu-config/isc-dhcp-server.service   
2021-01-31 18:38:48.0 +0100
+++ debian-edu-config-2.11.56/share/debian-edu-config/isc-dhcp-server.service   
2021-06-02 

Bug#990133: cinnamon-screensaver: legacy conffiles leftover

[Fabio Fantoni]

Thanks for report, /etc/pam.d/cinnamon-screensaver should be still
present, from a fast look seems a small mistake in
https://salsa.debian.org/cinnamon-team/cinnamon-screensaver/-/commit/f4f26676ca373ea4f109e8e45b5c388310aed569
(missed to add to .install)

Bug#990138: dkms: legacy conffiles leftover

[Christoph Anton Mitterer]

Package: dkms
Version: 2.8.4-4
Severity: normal


Hi.

Apparently the package used to contain the conffiles:
/etc/bash_completion.d/dkms
but no longer does so.

Please properly clean them up using dpkg-maintscript-helper(1).
(AFAIU, the version that needs to be specified for that is NOT
the version where the conffile was dropped, but rather "the
latest version of the package whose upgrade should trigger
the operation"

Quoting the manpage:
   For example, for a conffile removed in version 2.0-1 of a package,
   prior-version should be set to 2.0-1~. This will cause the conffile
   to be removed even if the user rebuilt the previous version 1.0-1
   as 1.0-1local1. Or a package switching a path from a symlink
   (shipped in version 1.0-1) to a directory (shipped in version
   2.0-1), but only performing the actual switch in the maintainer
   scripts in version 3.0-1, should set prior-version to 3.0-1~.


Cheers,
Chris.

Bug#990137: diodon: legacy conffiles leftover

[Christoph Anton Mitterer]

Package: diodon
Version: 1.11.0-1
Severity: normal


Hi.

Apparently the package used to contain the conffiles:
/etc/xdg/autostart/diodon.desktop
but no longer does so.

Please properly clean them up using dpkg-maintscript-helper(1).
(AFAIU, the version that needs to be specified for that is NOT
the version where the conffile was dropped, but rather "the
latest version of the package whose upgrade should trigger
the operation"

Quoting the manpage:
   For example, for a conffile removed in version 2.0-1 of a package,
   prior-version should be set to 2.0-1~. This will cause the conffile
   to be removed even if the user rebuilt the previous version 1.0-1
   as 1.0-1local1. Or a package switching a path from a symlink
   (shipped in version 1.0-1) to a directory (shipped in version
   2.0-1), but only performing the actual switch in the maintainer
   scripts in version 3.0-1, should set prior-version to 3.0-1~.


Cheers,
Chris.

Bug#931471: deborphan: oldconfig: /etc/bash_completion.d/deborphan

[Christoph Anton Mitterer]

Hey.

Anything new on this?


Please properly clean them up using dpkg-maintscript-helper(1).
(AFAIU, the version that needs to be specified for that is NOT
the version where the conffile was dropped, but rather "the
latest version of the package whose upgrade should trigger
the operation"

Quoting the manpage:
   For example, for a conffile removed in version 2.0-1 of a package,
   prior-version should be set to 2.0-1~. This will cause the conffile
   to be removed even if the user rebuilt the previous version 1.0-1
   as 1.0-1local1. Or a package switching a path from a symlink
   (shipped in version 1.0-1) to a directory (shipped in version
   2.0-1), but only performing the actual switch in the maintainer
   scripts in version 3.0-1, should set prior-version to 3.0-1~.

Cheers,
Chris.

Bug#833914: desktop-file-validate conffile not removed on upgrade

[Christoph Anton Mitterer]

Hey.

Anything new on this?


Please properly clean them up using dpkg-maintscript-helper(1).
(AFAIU, the version that needs to be specified for that is NOT
the version where the conffile was dropped, but rather "the
latest version of the package whose upgrade should trigger
the operation"

Quoting the manpage:
   For example, for a conffile removed in version 2.0-1 of a package,
   prior-version should be set to 2.0-1~. This will cause the conffile
   to be removed even if the user rebuilt the previous version 1.0-1
   as 1.0-1local1. Or a package switching a path from a symlink
   (shipped in version 1.0-1) to a directory (shipped in version
   2.0-1), but only performing the actual switch in the maintainer
   scripts in version 3.0-1, should set prior-version to 3.0-1~.

Cheers,
Chris.

Bug#990136: libgit2-27: EACCES can produce error -3 "could not find repository"

[Ian Jackson]

Package: libgit2-27
Version: 0.27.7+dfsg.1-0.2
Severity: important
Tags: upstream

Steps to reproduce:

 * Build the libgit2 rev-parse example:
 * Install libgit2-dev
 * Copy the contents of /usr/share/doc/libgit2-dev/examples
   to a fresh directory and change into it
 * gunzip common.c.gz 
 * gcc -lgit2 rev-list.c common.c
   This will produce a file `./a.out`

 * Make or have a git tree (repository with working tree) which is not
   accessible to some users.  In my configuration:
 drwxrws--- 133 ian ian 77824 Jun 16 18:35 /home/ian/work/xsa.git/

 * As a user who cannot access the repository, run something like
 ./a.out --git-dir=/home/ian/work/xsa.git refs/heads/master

Expected behaviour:

 Could not open repository from '/home/ian/work/xsa.git [-1] - failed to 
resolve path '/home/ian/work/xsa.git/.git': Permission denied

Actual behaviour:

 Could not open repository from '/home/ian/work/xsa.git' [-3] - could not find 
repository from '/home/ian/work/xsa.git'


Note that this rune:
  ./a.out --git-dir=/home/ian/work/xsa.git/.git refs/heads/master
DTRT.


I was tempted by severity "serious" since falsely claiming that a
repository does not exist could result in data loss, in some
situations.

Thanks for your attention.

Ian.

FYI here's the tail of the strace showing it persisting after getting
several EACCES including one on a `.git`, which ought to terminate the
search with an error.


brk(0x557ddd28c000) = 0x557ddd28c000
munmap(0x7fe42d258000, 217088)  = 0
futex(0x7fe42d2419e4, FUTEX_WAKE_PRIVATE, 2147483647) = 0
lstat("/home", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
lstat("/home/ian", {st_mode=S_IFDIR|0755, st_size=20480, ...}) = 0
lstat("/home/ian/work", {st_mode=S_IFDIR|0775, st_size=12288, ...}) = 0
lstat("/home/ian/work/xsa.git", {st_mode=S_IFDIR|S_ISGID|0770, st_size=77824, 
...}) = 0
stat("/home/ian/work/xsa.git/.git", 0x7ffce9c17950) = -1 EACCES (Permission 
denied)
stat("/home/ian/work/xsa.git", {st_mode=S_IFDIR|S_ISGID|0770, st_size=77824, 
...}) = 0
stat("/home/ian/work/xsa.git/commondir", 0x7ffce9c17750) = -1 EACCES 
(Permission denied)
stat("/home/ian/work/xsa.git/HEAD", 0x7ffce9c17750) = -1 EACCES (Permission 
denied)
stat("/home/ian/work/.git", 0x7ffce9c17950) = -1 ENOENT (No such file or 
directory)
stat("/home/ian/work", {st_mode=S_IFDIR|0775, st_size=12288, ...}) = 0
stat("/home/ian/work/commondir", 0x7ffce9c17750) = -1 ENOENT (No such file or 
directory)
stat("/home/ian/work/HEAD", 0x7ffce9c17750) = -1 ENOENT (No such file or 
directory)
stat("/home/ian/.git", 0x7ffce9c17950)  = -1 ENOENT (No such file or directory)
stat("/home/ian", {st_mode=S_IFDIR|0755, st_size=20480, ...}) = 0
stat("/home/ian/commondir", 0x7ffce9c17750) = -1 ENOENT (No such file or 
directory)
stat("/home/ian/HEAD", 0x7ffce9c17750)  = -1 ENOENT (No such file or directory)
stat("/home/.git", 0x7ffce9c17950)  = -1 ENOENT (No such file or directory)
stat("/home", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
stat("/home/commondir", 0x7ffce9c17750) = -1 ENOENT (No such file or directory)
stat("/home/HEAD", 0x7ffce9c17750)  = -1 ENOENT (No such file or directory)
write(2, "Could not open repository from '"..., 119Could not open repository 
from '/home/ian/work/xsa.git' [-3] - could not find repository from 
'/home/ian/work/xsa.git'
) = 119
exit_group(1)   = ?
+++ exited with 1 +++



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

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

Versions of packages libgit2-27 depends on:
ii  libc6  2.28-10
ii  libcom-err21.44.5-1+deb10u3
ii  libgssapi-krb5-2   1.17-3+deb10u1
ii  libhttp-parser2.8  2.8.1-1
ii  libk5crypto3   1.17-3+deb10u1
ii  libkrb5-3  1.17-3+deb10u1
ii  libmbedcrypto3 2.16.0-1
ii  libmbedtls12   2.16.0-1
ii  libmbedx509-0  2.16.0-1
ii  libssh2-1  1.8.0-2.1
ii  zlib1g 1:1.2.11.dfsg-1

libgit2-27 recommends no packages.

libgit2-27 suggests no packages.

-- no debconf information

Bug#990135: dcmtk: leftovers after package purge

[Christoph Anton Mitterer]

Also it seems that the package contains:
/var/lib/dcmtk/db/

but not:
/var/lib/dcmtk/

which causes the later to be abandoned after purge.

Bug#989958: libopencv-*-dev: Missing pkg-config file (.pc)

[Alejandro Colomar (man-pages)]

Hi Jochen,

On 6/21/21 2:33 PM, Jochen Sprickerhof wrote:

Control: severity -1 wishlist

Hi Alejandro,

* Alejandro Colomar  [2021-06-16 17:31]:

None of them contain the needed pkg-conig files for their use, making
necessary to install 'libopencv', and making useless the separation into
smaller packages.


You don't need to use pkg-config to build against an OpenCV module, just 
running gcc with the flags you need will work. Adjusting severity 
accordingly.




I had some thoughts about this after sending the email.
The problem in the first place is that opencv doesn't provide separate 
pkg-config files for every module.


Maybe Debian could write separate pkg-config files, and maybe offer them 
to upstream OpenCV (I offer myself to help write them if you decide it's 
a good idea).


Yes, for linking against the shared libraries, that's all you need: link 
against the module you want.  BUT, if you want to try to link against 
the static library (and now I'm talking from memory (it's been a year 
since I tried to do that, and I don't remember the result, I only 
remember a bunch of errors)), you'll need to know which libraries you 
need, which is the magic of pkg-config.



If you can't install that file in every binary package, you may
create a new binary package that only contains the .pc file,
let's say libopencv-pc, and make all packages depend on it.


This sounds overly complicated to me. I think we should move all 
development files into one libopencv-dev if we want to fix this.

But that's choice of the maintainers.
Moving everything into libopencv-dev would create a very big package 
when developers may not need all of opencv (I for example only depend on 
a few modules to build my programs).  One thing that I love of Debian 
packages is that they tend to be very modular compared to other distros. 
 Please don't put everything in one single pkg :-).


Thanks!

Cheers,

Alex

--
Alejandro Colomar
Linux man-pages comaintainer; https://www.kernel.org/doc/man-pages/
http://www.alejandro-colomar.es/

Bug#983427: libpam-runtime: please add support for DPKG_ROOT

[Sam Hartman]

> "Johannes" == Johannes 'josch' Schauer  writes:


I took a look at the references in the bug.
In particular, https://wiki.debian.org/Teams/Dpkg/Spec/InstallBootstrap

My goal was to try and do homework prior to a call.

Here's where I got:


That page actually seems to talk about a different problem than is
discussed in the bug.
In particular it's talking about complexities around having the order of
dependencies hard-coded in  debootstrap.

The assertion there is that pseudo-essential packages should not have
maintainer scripts in the install case.

Assuming that's the direction we take, the patch proposed in this bug
would not be needed.

However, the dpkg team page is long on assertions, and fairly short on
reasoning behind them.
It's absolutely true that boostrapping information is embedded in
debootstrap and cdebootstrap.
And there are some downsides to that.
But it also appears to be some upsides.
Namely that we can use our existing mechanisms for package maintenance,
and that we stick the boostrapping information all in one place.

The dpkg page points to several "recent examples"  of the problem.
I read through https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=767999


I'll admit that the reasoning in that bug report makes a lot more sense
to me than what's written on the dpkg page.
However, there wasn't really a  consensus in the bug description.
Some parties were arguing that it was desirable to embed the
bootstrapping information in debootstrap.
Some parties were arguing that this was undesirable.
It was generally agreed that base-passwd was buggy for not having its
functionality available by unpack time, although it looks like that got
fixed.

So, I don't think the cited examples support the conclusions drawn from
them, and even if the conclusions are correct, I don't see the dpkg
bootstrapping page as support for this patch.

If this patch is desirable, the motivation needs to come from elsewhere.

I think we're all agreed that the patch does make rootless bootstrapping
more possible.  I think we're all agreed that we don't want that to
extend across the entire archive.  The question in my mind is whether
rootless bootstrapping is desirable at all when all the ttrade offs are
considered, and if so, what scope it should have.
I have a strong desire to respect actual informed consensus where it
exists.
It's harmful if each individual maintainer makes their own call.

And yet, if there isn't an informed consensus, I'm not sure pam is the
right place to start introducing complexity.


signature.asc
Description: PGP signature

Bug#990134: dcmtk: legacy conffiles leftover

[Christoph Anton Mitterer]

Package: dcmtk
Version: 3.6.5-1
Severity: normal


Hi.

Apparently the package used to contain the conffiles:
/etc/init.d/storescp
/etc/init.d/dcmqrscp
/etc/default/storescp
/etc/default/dcmqrscp
but no longer does so.

Please properly clean them up using dpkg-maintscript-helper(1).
(AFAIU, the version that needs to be specified for that is NOT
the version where the conffile was dropped, but rather "the
latest version of the package whose upgrade should trigger
the operation"

Quoting the manpage:
   For example, for a conffile removed in version 2.0-1 of a package,
   prior-version should be set to 2.0-1~. This will cause the conffile
   to be removed even if the user rebuilt the previous version 1.0-1
   as 1.0-1local1. Or a package switching a path from a symlink
   (shipped in version 1.0-1) to a directory (shipped in version
   2.0-1), but only performing the actual switch in the maintainer
   scripts in version 3.0-1, should set prior-version to 3.0-1~.


Cheers,
Chris.

Bug#990135: dcmtk: leftovers after package purge

[Christoph Anton Mitterer]

Package: dcmtk
Version: 3.6.5-1
Severity: normal


Hey.

When the package is purge some files are left over:
Purging configuration files for dcmtk (3.6.5-1) ...
dpkg: warning: while removing dcmtk, directory '/var/lib/dcmtk/db' not empty so 
not removed

# l /var/lib/dcmtk/db/
total 0
drwxr-xr-x 1 dcmtk dcmtk 16 Feb 20  2014 .
drwxr-xr-x 1 root  root   4 Feb 20  2014 ..
drwxr-xr-x 1 dcmtk dcmtk  0 Feb 20  2014 STORESCP
# l /var/lib/dcmtk/db/STORESCP/
total 0
drwxr-xr-x 1 dcmtk dcmtk  0 Feb 20  2014 .
drwxr-xr-x 1 dcmtk dcmtk 16 Feb 20  2014 ..


Cheers,
Chris.

Bug#990133: cinnamon-screensaver: legacy conffiles leftover

[Christoph Anton Mitterer]

Package: cinnamon-screensaver
Version: 4.8.1-2
Severity: normal


Hi.

Apparently the package used to contain the conffiles:
/etc/pam.d/cinnamon-screensaver
but no longer does so.

Please properly clean them up using dpkg-maintscript-helper(1).
(AFAIU, the version that needs to be specified for that is NOT
the version where the conffile was dropped, but rather "the
latest version of the package whose upgrade should trigger
the operation"

Quoting the manpage:
   For example, for a conffile removed in version 2.0-1 of a package,
   prior-version should be set to 2.0-1~. This will cause the conffile
   to be removed even if the user rebuilt the previous version 1.0-1
   as 1.0-1local1. Or a package switching a path from a symlink
   (shipped in version 1.0-1) to a directory (shipped in version
   2.0-1), but only performing the actual switch in the maintainer
   scripts in version 3.0-1, should set prior-version to 3.0-1~.


Cheers,
Chris.

Bug#990132: cinnamon-control-center-data: legacy conffiles leftover

[Christoph Anton Mitterer]

Package: cinnamon-control-center-data
Version: 4.8.2-1
Severity: normal


Hi.

Apparently the package used to contain the conffiles:
/etc/xdg/menus/cinnamoncc.menu
but no longer does so.

Please properly clean them up using dpkg-maintscript-helper(1).
(AFAIU, the version that needs to be specified for that is NOT
the version where the conffile was dropped, but rather "the
latest version of the package whose upgrade should trigger
the operation"

Quoting the manpage:
   For example, for a conffile removed in version 2.0-1 of a package,
   prior-version should be set to 2.0-1~. This will cause the conffile
   to be removed even if the user rebuilt the previous version 1.0-1
   as 1.0-1local1. Or a package switching a path from a symlink
   (shipped in version 1.0-1) to a directory (shipped in version
   2.0-1), but only performing the actual switch in the maintainer
   scripts in version 3.0-1, should set prior-version to 3.0-1~.


Cheers,
Chris.

Bug#909518: webext-noscript: ships file under /etc/iceweasel

[Christoph Anton Mitterer]

Anything new on that?


The conffile should be properly cleaned up via dpkg-maintscript-
helper(1).

Cheers,
Chris.

Bug#897707: Should this package be removed from Debian?

[Timo Röhling]

Control: user debian...@lists.debian.org
Control: usertag -1 + proposed-removal

Given that this RC bug and #892288 have been unresolved for several
years and the last upload dates back to 2016 with multiple upstream
releases since, I believe this package should be considered for QA
removal.

Cheers
Timo

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


signature.asc
Description: PGP signature

Bug#989831: konsole: Bitmap fonts rendered incorrectly if display scaling is enabled

[Tim Small]

Package: konsole
Version: 4:20.12.3-1
Followup-For: Bug #989831
X-Debbugs-Cc: t...@seoss.co.uk

On 16/06/2021 05:07, Norbert Preining wrote:
> On Mon, 14 Jun 2021, Tim Small wrote:
>> instead each character is rendered with large amounts
>> of surrounding space.
>>
>> T h e   e f f e c t   i s   a   b i t   l i k e   t h i s ,  a n d   i s
>>
>> n o t   u s a b l e .
>>
>> I'm not sure if this is a konsole thing, or a qt/kde thing.
> But isn't that what you are asking for by setting a global scale to != 100
> ???

I think what the user expecting when a global scale is set, is "When the
application says that graphical elements should be size 'x' on screen,
then display it at size 'global scale * x' instead".

So e.g. If an application would normally display a graphical element
with a font which renders at 10 pixels-tall, then when I have a global
scale set to 150%, instead it would try and use font which renders at 15
pixels-tall.

I'm assuming that konsole would select a larger font in this case
(perhaps it's trying to, but it can't because of #989834, or perhaps the
rendering pipeline just doesn't allow this sort of decision to be made).

>> p.s. I've tagged this as a11y because I use bitmap fonts AND high dpi
>> displays to avoid chronic eye strain (without which I am limited to
> I understand hidpi, but why bitmap fonts? vector fonts are also
> converted to bitmaps and mostly at better quality, so they should
> provide better readability and less strain.

The thing that gives me eye strain is anti-aliasing (having spoken to an
optometrist about this, they think my visual system perceives the fuzzy
edges of anti-aliased fonts as being out-of focus, and then continuously
tries to make micro adjustments to my eyes' focal distance to bring it
into focus, and this causes muscle fatigue).

I know that this is quite a niche problem (especially since high dpi
displays are now fine for the vast majority of users), and it was much
more of a problem for me before I switched to higher resolution
displays), there is some mention of it in section 3.3 of this paper:

https://jsonj.co.uk/resources/science/papers/plateau2015-jacques.pdf

The optometrist thought I was experiencing this because I have high
visual acuity (when I was younger - it was "20/10", and I could read the
whole of the bottom row of the optometrists' sight chart).

Vector fonts don't give me eye fatigue when anti-aliasing is disabled,
and this is a good second best (since konsole includes an option to
disable this, presumably because this is a reasonably common request).

Unfortunately with anti-aliasing disabled, the vector fonts look lower
quality.  e.g. see attachment which shows terminus vs noto mono (from
konsole screenshots of both typefaces).  The vector fonts are not
unusable, they're just not as good when rendered like this.

After trying various things to try and reduce eye fatigue, my working
environment uses two 4k displays - the internal 4k 15" laptop display is
OK for anti-aliased fonts (as long as use an external keyboard so that
it is about 1 meter away from my eyes - I use display scaling to ensure
text isn't too small at this distance), and another 27" 4k display (at
the same distance, but I restrict this to working without anti-aliased
fonts except for short time periods).

I assume a 27" 8k display would be great for me with anti-aliased vector
fonts, but these are much more expensive (about 10x more than a 4k
display last time I looked).

I've found I can workaround this issue by disabling scaling in konsole
by launching it with this wrapper:

#!/bin/sh
export SAVE_QT_SCREEN_SCALE_FACTORS="$QT_SCREEN_SCALE_FACTORS"
export SAVE_QT_SCALE_FACTOR="$QT_SCALE_FACTOR"
unset QT_SCREEN_SCALE_FACTORS
export QT_SCALE_FACTOR=1
exec /usr/bin/konsole

...and then restoring the SAVE variables in the shell rc so that they
are not inherited by commands which are launched from within konsole.

Tim.

Bug#990131: xserver-xorg-video-intel: legacy conffiles leftover

[Christoph Anton Mitterer]

Package: xserver-xorg-video-intel
Version: 2:2.99.917+git20200714-1+b1
Severity: normal


Hi.

Despite #713340 there are still leftover:
# dpkg-query --showformat='${Package}\n${Conffiles}\n' --show  |  awk '/^[^ 
]/{pkg=$1}/ obsolete$/{print pkg,$0}' | cut -d ' ' -f 1-3 | column -t
...
xserver-xorg-video-intel  /etc/modprobe.d/i915-kms.conf


Guess the reason is that the version that was used in the maintainer
script seems wrong.

>From dpkg-maintscript-helper(1):
   prior-version
   Defines the latest version of the package whose upgrade should
   trigger the operation. It is important to calculate prior-version
   correctly so that the operations are correctly performed even if
   the user rebuilt the package with a local version.
...
   For example, for a conffile removed in version 2.0-1 of a package,
   prior-version should be set to 2.0-1~. This will cause the conffile
   to be removed even if the user rebuilt the previous version 1.0-1
   as 1.0-1local1. Or a package switching a path from a symlink
   (shipped in version 1.0-1) to a directory (shipped in version
   2.0-1), but only performing the actual switch in the maintainer
   scripts in version 3.0-1, should set prior-version to 3.0-1~.


In postrm you use: 2:2.21.9-1\~
however, according to the changelog, this was only added in 2:2.99.916-1~exp1
so anyone who had upgraded already beyond 2:2.21.9-1\~ is still left with legacy
cruft.


Cheers,
Chris.

Bug#988406: notifying users on EOL of a debian release

[Osamu Aoki]

Hi,

On Mon, 2021-06-21 at 07:20 +, Holger Levsen wrote:
> On Mon, Jun 21, 2021 at 03:56:13PM +0900, Osamu Aoki wrote:
> > This may not address very old releases but for the future releases, your 
> > concern may
> > be addressed for END USER by adding few features to unattended-upgrades 
> > which seems
> > to be default for stable default install.
> 
> right. (though I disagree with 'very old releases' and rather say 'previous
> releases' but that's maybe because I'm very old :)

Not as old as I am :-) Seriously, I meant any thing older than oldstable is 
very old.

> 
> > As for more GUI type environment, currently GNOME Package program generates 
> > pop up
> > via GNOME notification service (?)when packages are ready to be installed.  
> > The same
> > code may be modified to pop up message for failed fetching of apt HTTP 
> > connection
> > while network is active.
> 
> this should also work for other desktop environments, no?

I have not checked how exactly things are connected, TBH.  

I think code in apt package which is called by unattended-upgrades is the one
suffering 404 error.

> > What do you think of reassigning this bug to unattended-upgrades ?
> 
> maybe. maybe *cloning* the bug and reassigning would be more proper...

Probably yes.  At least, they may point us to right people.

Osamu

Bug#989547: detect docker

[Thomas Lange]

Here's the info I got about detecting if FAI is run inside a docker
container:

Googling around, there are a few ways.
It looks like this could be the most consistent:

grep -E ":/docker/.+$" /proc/1/cgroup

..which is looking for cgroups under a docker cgroup
It may be refined to:

grep -E ":/docker/[0-9a-f]+$" /proc/1/cgroup

..but I can't say that for sure.

What do you think, does that sound reasonable ?

-- 
viele Grüße Thomas

Bug#924643: RFS: colorzero/2.0-1 [ITP] -- Construct, convert, and manipulate colors in a Pythonic manner.

[Dave Jones]

Hi Emmanuel,

On Sat, Jun 19, 2021 at 06:40:58PM -0300, Emmanuel Arias wrote:


On 6/19/21 9:03 AM, Peter Green wrote:
Just done some reviewing/tweaking. I've pushed the following changes 
to the git repo, please tell me if you have any objections.


I added a gpb.conf to make git-buildpackage actually use pristine tar 
and hence result in an orig tarball that was consistent with what is 
already in Ubuntu.


Also, you can try to follow DEP-14 (although is mark as candidate) and 
add debian/master as default branch.


Ah, this was something that confused me a bit when initially working on 
this. I'd read through DEP-14, but then figured a simple way to start 
would be to grab my existing packaging for Raspbian and use gbp 
import-dsc on it. This set up the repo with a "master" branch rather 
than "debian/master" and I then wondered if I'd mis-interpreted DEP-14's 
prescription to use "debian/master", and whether it meant one should use 
"debian" branch or alternatively a "master" branch.


Anyway, given it should be "debian/master" I'll get that corrected (I 
assume I'm right in thinking that'll need a 
"debian-branch=debian/master" addition to gbp.conf).



What about enable salsa-ci?


Certainly something on the todo list, but not something I'd read up on 
yet. I'll have a look at that this afternoon.


Thanks,

Dave.

Bug#990130: Problems when mounting ZFS datasets in wrong order

[Juan Cespedes]

Package: zfsutils-linux
Version: 2.0.3-8
Severity: important

First of all, I am not really sure if this bug belongs to zfs-dkms or to
zfsutils-linux.

When mounting a parent and a child dataset in the wrong order (first
child, then parent), it is not possible to unmount any of them with
"zfs unmount" anymore:

root@cespedes:~# zfs list
NAME   USED  AVAIL REFER  MOUNTPOINT
tank   104K   832M   24K  /tank
root@cespedes:~# zfs create -p tank/foo/bar
root@cespedes:~# zfs list
NAME   USED  AVAIL REFER  MOUNTPOINT
tank   177K   832M   24K  /tank
tank/foo48K   832M   24K  /tank/foo
tank/foo/bar24K   832M   24K  /tank/foo/bar
root@cespedes:~# zfs mount
tank/tank
tank/foo/tank/foo
tank/foo/bar/tank/foo/bar
root@cespedes:~# zfs unmount tank/foo
root@cespedes:~# zfs mount tank/foo/bar
root@cespedes:~# zfs mount tank/foo
root@cespedes:~# zfs mount
tank/tank
tank/foo/bar/tank/foo/bar
tank/foo/tank/foo
root@cespedes:~# zfs unmount tank/foo/bar
cannot unmount '/tank/foo/bar': unmount failed
root@cespedes:~# zfs unmount tank/foo
cannot unmount '/tank/foo/bar': unmount failed


Best,

Juan Cespedes

Bug#990115: Kmail message display hangs after letting Akonadi idling for several hours

[Julien AUBIN]

Looks like it happens when the IMAP connection to Yahoo mail is stuck - which 
is quite often. Connection status is set to "established connection" only for 
Yahoo Mail, for the other accounts (Protonmail, GMail) no issue.

Basically we should not be blocked this way.

Bug#990129: libqt5core5a: breaks work of some QtWebEngine based programs

[Boris Pek]

Package: libqt5core5a
Version: 5.15.2+dfsg-6
Severity: important
X-Debbugs-Cc: tehnic...@yandex.ru


Hi,

I use Debian 11 (Bullseye) on work PC to develop Qt based projects. All worked
fine until update of Qt packages last week: one of our QML based application
stopped showing maps without any errors in stdin/stdout.

Today I spent few hours to find the root of problem. QtWebEngine is used for
displaying maps and it is quite problematic itself, but I was surprised to find
what problem was caused by update in QtCore library:
libqt5core5a:amd64 (5.15.2+dfsg-5, 5.15.2+dfsg-6)

And if I understand correctly here is the problematic patch:
https://salsa.debian.org/qt-kde-team/qt/qtbase/-/commit/5eaeb73

Could you revert it please?

Best regards,
Boris


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

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

Versions of packages libqt5core5a depends on:
ii  libc6  2.31-12
ii  libdouble-conversion3  3.1.5-6.1
ii  libgcc-s1  10.2.1-6
ii  libglib2.0-0   2.66.8-1
ii  libicu67   67.1-6
ii  libpcre2-16-0  10.36-2
ii  libstdc++6 10.2.1-6
ii  libzstd1   1.4.8+dfsg-2.1
ii  shared-mime-info   2.0-1
ii  zlib1g 1:1.2.11.dfsg-2

Versions of packages libqt5core5a recommends:
ii  qttranslations5-l10n  5.15.2-2

Versions of packages libqt5core5a suggests:
ii  libthai0  0.1.28-3