Bug#974640: Spatialite GUI /CLI and shp

[jedei]

Package: spatialite-gui
Version: 2.1.0~beta1-1
Severity: normal

Hi,

Importing or linking a shapefile in spatialite (spatialite_gui, sqlite3 with 
mod_spatialite) fails if the extension is in uppercase (.SHP).

This problem does not exist with csv / txt, xls, GeoJson, or dbf, or zip files 
(ZipFile archive for shapefile). However if the extension of these files is in 
uppercase they do not appear in the search window and the type must be set to 
"All files" to make them appear and select them.

I am using Linux debian 5.6.0-2-amd64 #1 SMP Debian 5.6.14-2 (2020-06-09) 
x86_64 GNU/Linux (Bullseye testing 20200622 with partial update (sqlite3, 
spatialite) 20201003). My desktop environment is MATE 1.24.

Best regards

Michel‌

Bug#974641: lintian: classification tag for test suite

[Lucas Nussbaum]

Package: lintian
Version: 2.101.0
Severity: normal

Hi,

Until this change:
https://salsa.debian.org/lintian/lintian/-/commit/c81fb3dbc4425c4322c67f0f3eeb2c208e337736
it was possible to rely on 'testsuite-autopkgtest-missing' to determine
whether a package has a test suite.

That tag was marked as renamed to 'missing-tests-control' in
https://salsa.debian.org/lintian/lintian/-/commit/dfe74fead551c3e44e884aea6275a8f4e3725693,
but this is not really the case: the 'missing-tests-control' tag is
emmited in a specific error case.

Could you please reintroduce a classification tag that makes it possible
to say whether a package has a test suite? I'd like to graph this again
on https://trends.debian.net/

Thanks

Lucas

Bug#974639: rust-zoxide: wrong section in debian/control

[Aurelien Jarno]

Source: rust-zoxide
Version: 0.4.3-1
Severity: serious

rust-zoxide contains an invalid Section for the Source package:

| Source: rust-zoxide
| Section: FIXME-(source.section)
| Priority: optional
| Build-Depends: debhelper (>= 11),
|  dh-cargo (>= 18),
|  cargo:native,
|  rustc:native,
|  libstd-rust-dev,
|  librust-anyhow-1+default-dev (>= 1.0.28-~~),
|  librust-bincode-1+default-dev (>= 1.3.1-~~),

This causes many issues with the debian tools (buildds, etc.)

Bug#974538: libkscreenlocker5: kwin cannot start due to missing libkscreenunlocker5 symbols

[Aurélien COUDERC]

Le 13 novembre 2020 00:26:16 GMT+01:00, Norbert Preining 
 a écrit :
>Hi Scarlett, hi all,

Hi !

>> However, it seems that because of the ABI break in libkscreenlocker5
>> there may need to be more specific dependency requirements (like
>
>I suggest the following change in kscreenlocker debian/control, Scarlett, wdyt?
>diff --git a/debian/control b/debian/control
>index b961e0d..b2ba44d 100644
>--- a/debian/control
>+++ b/debian/control
>@@ -86,6 +86,7 @@ Package: libkscreenlocker5
> Architecture: any
> Pre-Depends: psmisc
> Depends: ${misc:Depends}, ${shlibs:Depends}
>+Breaks: kwin-common (<< 4:5.19), kwin-common (>> 4:5.19.90~)
> Recommends: kde-config-screenlocker
> Multi-Arch: same
> Description: Secure lock screen architecture

Could I suggest using (>> 4:5.19.70~)
I know we generally don't package these but upstream does publish prereleases 
starting at .70 AFAICR.


Happy hacking !
--
Aurélien

Bug#974637: biosig4c++_1.9.5-1+b2_mipsel-buildd.changes REJECTED

[Aurelien Jarno]

Source: biosig4c++
Version: 1.9.5-1
Severity: serious

- Forwarded message from Debian FTP Masters 
 -

From: Debian FTP Masters 
To: mipsel Build Daemon 
Date: Fri, 13 Nov 2020 07:18:34 +
Subject: biosig4c++_1.9.5-1+b2_mipsel-buildd.changes REJECTED
Message-Id: 

Version check failed:
Your upload included the binary package biosig-tools, version 1.9.5-1+b2, for 
mipsel,
however testing already has version 2.0.6-1+b1.
Uploads to unstable must have a higher version than present in testing.

Mapping sid to unstable.

===

Please feel free to respond to this email if you don't understand why
your files were rejected, or if you upload new files which address our
concerns.




- End forwarded message -

Bug#974638: ITP: awthemes -- Dark and light themes for Tk, loosely based on the adwaita themes

[Ole Streicher]

Package: wnpp
Severity: wishlist
Owner: Ole Streicher 
X-Debbugs-Cc: debian-de...@lists.debian.org, 
pkg-tcltk-de...@lists.alioth.debian.org

* Package name: awthemes
  Version : 9.5.1
  Upstream Author : Brad Lanam
* URL : https://sourceforge.net/projects/tcl-awthemes/
* License : zlib
  Programming Lang: Tcl
  Description : Dark and light themes for Tk

This is a new requirement of saods9. It will be maintained
within the TclTk team. A salsa dir is created at 

https://salsa.debian.org/tcltk-team/awthemes

Best regards

Ole

Bug#974636: ITP: tkagif -- TK Animated GIF encoder

[Ole Streicher]

Package: wnpp
Severity: wishlist
Owner: Ole Streicher 
X-Debbugs-Cc: debian-de...@lists.debian.org, 
pkg-tcltk-de...@lists.alioth.debian.org

* Package name: ttkthemes
  Version : 1.0.3
  Upstream Author : RedFantom
* URL : https://github.com/TkinterEP/ttkthemes
* License : GPL-v3
  Programming Lang: Tcl, Python
  Description : A group of themes for the ttk extenstions for Tkinter

This is a new requirement of saods9. It will be maintained
within the TclTk team. A salsa dir is created at 

https://salsa.debian.org/tcltk-team/ttkthemes

Best regards

Ole

Bug#974635: aragorn FTCBFS: debian/rules uses the build architecture compiler as a make default

[Helmut Grohne]

Source: aragorn
Version: 1.2.38-3
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

aragorn fails to cross build from source, because it uses the build
architecture compiler in debian/rules as a make default. The simplest
way of fixing this is letting dpkg's buildtools.mk initialize CC. Please
consider applying the attached patch.

Do note that you can also simplify the initialization of CPPFLAGS and
friends using dpkg's buildflags.mk.

Helmut
diff --minimal -Nru aragorn-1.2.38/debian/changelog 
aragorn-1.2.38/debian/changelog
--- aragorn-1.2.38/debian/changelog 2020-11-06 14:25:25.0 +0100
+++ aragorn-1.2.38/debian/changelog 2020-11-13 08:13:53.0 +0100
@@ -1,3 +1,10 @@
+aragorn (1.2.38-3.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Seed CC from dpkg's buildtools.mk. (Closes: #-1)
+
+ -- Helmut Grohne   Fri, 13 Nov 2020 08:13:53 +0100
+
 aragorn (1.2.38-3) unstable; urgency=medium
 
   [ Jelmer Vernooij ]
diff --minimal -Nru aragorn-1.2.38/debian/rules aragorn-1.2.38/debian/rules
--- aragorn-1.2.38/debian/rules 2020-11-06 14:25:25.0 +0100
+++ aragorn-1.2.38/debian/rules 2020-11-13 08:13:50.0 +0100
@@ -5,6 +5,7 @@
 export DH_ALWAYS_EXCLUDE=.gitignore
 export DEB_BUILD_MAINT_OPTIONS = hardening=+all
 
+-include /usr/share/dpkg/buildtools.mk
 CPPFLAGS:=$(shell dpkg-buildflags --get CPPFLAGS)
 CFLAGS:=$(shell dpkg-buildflags --get CFLAGS)
 CXXFLAGS:=$(shell dpkg-buildflags --get CXXFLAGS)

Bug#973435: biosig build-depends on python3-all-dev, but only builds for the default python3 version

[Andreas Tille]

On Thu, Nov 12, 2020 at 11:46:43PM +0100, Alois Schlögl wrote:
> 
> Thanks for the hint on py3versions, this helped solving the issue for v2.1.0.

You are welcome.
 
> I believe bug #972684, #973435 are fixed now.

Hmmm, regarding bug #972684: In d/rukes you use

override_dh_auto_build:
... py3versions -d ...

(so you build against default Python3 version) and

override_dh_auto_install:
...
$(cd biosig4c++/python && foreach py,$(shell py3versions -s), (${py} 
setup.py install --prefix=debian/${py}-biosig) )

an install for more than one version - specifically install to
non-existing packages (python3.8-biosig and python3.9-biosig but
we have only python3-biosig!)

Without trying to build this - it looks not like a proper solution
and I need to admit I can not spent any more time on this package
which I absolutely not use myself.  Please ask Yaroslav for sponsering.

> Debian packages of biosig 2.1.0-1 are now availab
> https://pub.ist.ac.at/~schloegl/biosig/debian/unstable/?C=M;O=D

I do not think it is a good idea to provide Debian packages on
other places than official Debian mirrors.

Kind regards

   Andreas.

> 
> On 11/10/20 11:28 AM, Andreas Tille wrote:
> > Hi again,
> > 
> > On Tue, Nov 10, 2020 at 10:10:21AM +0100, Alois Schlögl wrote:
> > > Ok, I see. Biosig can be build with any python version (it is just using 
> > > the
> > > general API for  module extension which is not)
> > > 
> > > That means, building it for any python version will work like this
> > > 
> > > (cd biosig4c++/python && python3 setup.py sdist )
> > > 
> > > (cd biosig4c++/python && python2.7 setup.py install )
> > This is not needed since python2.7 will be removed.
> > 
> > > (cd biosig4c++/python && python3.8 setup.py install )
> > > (cd biosig4c++/python && python3.9 setup.py install )
> > This would be
> > 
> >  for py in $(py3versions -s) ; do
> >  (cd biosig4c++/python && $py setup.py install )
> > > The question is: when packaging this in debian, how to tell which python
> > > versions are available, and how to trigger the build for that version ?
> > See above.
> > > Will there be a python3.8-biosig and python3.9-biosig package, and how 
> > > does
> > > this affect debian/control ?
> > It does not affect debian/control but debian/rules.  OK, if you want
> > the *easy* solutition just use
> > 
> >  s/python3-all-dev/python3-dev/
> > in d/control, which solves the issue since only the default python3
> > will be used (py3versions -d).  This is the *quick* fix for the bug.
> > It simply depends what you *want* from your users.  I hope Michael
> > or Yaroslav could comment on this.  I'm out at this point since I'm
> > not a user of this package.
> > 
> > > I've reverted the change, and partially fixed the build. Some issues 
> > > remain
> > > unsolved - as described before.
> > Hope this helps.  Other hints might be given by 
> > debian-pyt...@lists.debian.org.
> > 
> > Kind regards
> > 
> >  Andreas.
> > 
> 

-- 
http://fam-tille.de

Bug#971001: Please support caching packages outside the chroot

[Josh Triplett]

On Thu, Nov 12, 2020 at 11:45:07PM +0100, Johannes Schauer wrote:
> Hi,
> 
> Quoting Johannes Schauer (2020-09-29 08:22:18)
> > > >   $ sudo mmdebstrap --variant=apt --include='systemd-sysv udev' \
> > > >   > --setup-hook='mkdir -p ./cache.ess "$1"/var/cache/apt/archives' \
> > > >   > --setup-hook='sync-in ./cache.ess /var/cache/apt/archives' \
> > > >   > --extract-hook="sync-out /var/cache/apt/archives ./cache.ess" \
> > > >   > --essential-hook='mkdir -p ./cache.rest 
> > > > "$1"/var/cache/apt/archives' \
> > > >   > --essential-hook='sync-in ./cache.rest /var/cache/apt/archives' \
> > > >   > --customize-hook='sync-out /var/cache/apt/archives ./cache.rest' \
> > > >   > unstable debian-unstable
> > > 
> > > This is definitely at the level of complexity where it'd be *really
> > > nice* to just be able to pass `--cache-debs cachedir`, without depending
> > > deeply on the specific nuance of mmdebstrap's essential/non-essential
> > > handling (and potential future changes to that).
> > 
> > This is what the --hook-directory option is for. You put a directory 
> > somewhere,
> > place scripts in it according to each hook and their order and then run
> > mmdebstrap like with `--hook-dir cachedir` which is just as short as your
> > example. :)
> 
> thanks to an idea by David Kalnischkies, it's actually much easier. Instead of
> copying the *.deb archives to /var/cache/apt/archives, they can be copied into
> /var/cache/apt/archives/partial and then we don't need to keep track of two
> individual caches:
> 
> $ sudo mmdebstrap --variant=apt --skip=essential/unlink \
> > --setup-hook='mkdir -p ./cache "$1"/var/cache/apt/archives/partial' \
> > --setup-hook='sync-in ./cache /var/cache/apt/archives/partial' \
> > --customize-hook='rm -r "$1"/var/cache/apt/archives/partial' \
> > --customize-hook='sync-out /var/cache/apt/archives ./cache' \
> > unstable debian-unstable
> 
> This needs --skip=essential/unlink which will be part of the next mmdebstrap
> release. Is there something missing to close this bug with the next release?

--skip=essential/unlink definitely helps, thank you.

Would you consider shipping this exact example in the documentation,
perhaps as an example motivating --skip=essential/unlink ?

Bug#930997: Unintentional i386 compiles

[Olek Wojnar]

Hi reprotest maintainers,

I'd like to point out that an additional impact of this bug is that it
results in failures for packages that are designed to build on amd64 but
not on i386. For example, bazel-bootstrap supports 64-bit processors but
(currently) does not support 32-bit processors. This line [1] causes the
second build to *almost* always fail because it tries to build a package on
i386 even though that is not a supported architecture.

For reference, on my amd64 machine running "setarch --list" returns:
uname26
linux32
linux64
i386
i486
i586
i686
athlon
x86_64

Eliminating x86_64, as line [1] does, gives a very high probability of the
resulting architecture being incompatible with 64-bit-only packages.

If this is not easy to fix, is there a recommended workaround to
prevent false-positive failures? Thanks!

-Olek

[1] https://salsa.debian.org/bazel-team/bazel-bootstrap/-/jobs/1155093#L4289

Bug#839278: oathtool: has no secure way to provide a key

[Simon Josefsson]

Ian Jackson  writes:

> This causes KEY and OTP to be read from files.  You can specify the
> same filename twice in which case it takes a line from each.  "-"
> means stdin.

Thank you for the patch -- this makes sense.  I'm not fond of the name
'args-from-files' though.  How about this behaviour: if the supplied
strings for KEY and/or OTP contain '/' or '\' the strings are treated as
names of files to be read, instead of data strings?  And if the string
is '-' stdin is used.

The oathtool CLI was mostly intended as a debugging tool.  There were
discussions in the past about a higher-level tool that would store
secrets, keep track of HOTP counters, generate/validate OTPs, and
support PSKC files.  I'm not sure extending oathtool a lot further is
appropriate.  We'd might just be duplicating external efforts, such as:

https://github.com/tadfisher/pass-otp
https://github.com/matalo33/py_oathtool

/Simon


signature.asc
Description: PGP signature

Bug#971441: Package not built from source: gengetopt

[Simon Josefsson]

Hi Ian and thanks for the report.  I rewrote the packaging using dh
instead of cdbs, and rebuilding gengetopt generated files is fixed here:

https://salsa.debian.org/debian/oath-toolkit/-/commit/ba62deb912e78febc772138c771ab12ebe4d08e1

/Simon


signature.asc
Description: PGP signature

Bug#974619: FTBFS on mips*el: ../src/basic/macro.h:415:9: error: static assertion failed: "__NR_close_range == systemd_NR_close_range"

[Michael Biebl]

Source: systemd
Version: 247~rc2-1
Severity: serious
User: debian-m...@lists.debian.org
Usertags: mipsel
X-Debbugs-Cc: debian-m...@lists.debian.org

Hi mips porters,

systemd in experimental FTBFS on mipsel and mips64el
https://buildd.debian.org/status/fetch.php?pkg=systemd=mips64el=247%7Erc2-1=1605223087=0
https://buildd.debian.org/status/fetch.php?pkg=systemd=mipsel=247%7Erc2-1=1605222663=0

[56/2002] cc -Isrc/basic/libbasic.a.p -Isrc/basic -I../src/basic -Isrc/boot 
-I../src/boot -Isrc/core -I../src/core -Isrc/home -I../src/home -Isrc/journal 
-I../src/journal -Isrc/journal-remote -I../src/journal-remote 
-Isrc/libsystemd-network -I../src/libsystemd-network -I../src/libsystemd/sd-bus 
-I../src/libsystemd/sd-device -I../src/libsystemd/sd-event 
-I../src/libsystemd/sd-hwdb -I../src/libsystemd/sd-id128 
-I../src/libsystemd/sd-netlink -I../src/libsystemd/sd-network 
-I../src/libsystemd/sd-resolve -Isrc/libudev -I../src/libudev -Isrc/login 
-I../src/login -Isrc/nspawn -I../src/nspawn -Isrc/resolve -I../src/resolve 
-Isrc/shared -I../src/shared -Isrc/shutdown -I../src/shutdown -Isrc/systemd 
-I../src/systemd -I../src/time-wait-sync -Isrc/timesync -I../src/timesync 
-Isrc/udev -I../src/udev -I../src/xdg-autostart-generator -I. -I.. -flto 
-fdiagnostics-color=always -pipe -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch 
-Wextra -std=gnu99 -Wno-unused-parameter -Wno-missing-field-initializers 
-Wno-unused-result -Wno-format-signedness -Werror=undef -Wlogical-op 
-Wmissing-include-dirs -Wold-style-definition -Wpointer-arith -Winit-self 
-Wfloat-equal -Wsuggest-attribute=noreturn -Werror=missing-prototypes 
-Werror=implicit-function-declaration -Werror=missing-declarations 
-Werror=return-type -Werror=incompatible-pointer-types -Werror=format=2 
-Wstrict-prototypes -Wredundant-decls -Wmissing-noreturn 
-Wimplicit-fallthrough=5 -Wshadow -Wendif-labels -Wstrict-aliasing=2 
-Wwrite-strings -Werror=overflow -Werror=shift-count-overflow 
-Werror=shift-overflow=2 -Wdate-time -Wnested-externs -Wno-maybe-uninitialized 
-ffast-math -fno-common -fdiagnostics-show-option -fno-strict-aliasing 
-fvisibility=hidden -fstack-protector -fstack-protector-strong 
--param=ssp-buffer-size=4 -ffunction-sections -fdata-sections -Werror=shadow 
-include config.h -g -O2 '-fdebug-prefix-map=/<>=.' 
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
-D_FORTIFY_SOURCE=2 -fPIC -pthread -fvisibility=default -MD -MQ 
src/basic/libbasic.a.p/fd-util.c.o -MF src/basic/libbasic.a.p/fd-util.c.o.d -o 
src/basic/libbasic.a.p/fd-util.c.o -c ../src/basic/fd-util.c
FAILED: src/basic/libbasic.a.p/fd-util.c.o
cc -Isrc/basic/libbasic.a.p -Isrc/basic -I../src/basic -Isrc/boot -I../src/boot 
-Isrc/core -I../src/core -Isrc/home -I../src/home -Isrc/journal 
-I../src/journal -Isrc/journal-remote -I../src/journal-remote 
-Isrc/libsystemd-network -I../src/libsystemd-network -I../src/libsystemd/sd-bus 
-I../src/libsystemd/sd-device -I../src/libsystemd/sd-event 
-I../src/libsystemd/sd-hwdb -I../src/libsystemd/sd-id128 
-I../src/libsystemd/sd-netlink -I../src/libsystemd/sd-network 
-I../src/libsystemd/sd-resolve -Isrc/libudev -I../src/libudev -Isrc/login 
-I../src/login -Isrc/nspawn -I../src/nspawn -Isrc/resolve -I../src/resolve 
-Isrc/shared -I../src/shared -Isrc/shutdown -I../src/shutdown -Isrc/systemd 
-I../src/systemd -I../src/time-wait-sync -Isrc/timesync -I../src/timesync 
-Isrc/udev -I../src/udev -I../src/xdg-autostart-generator -I. -I.. -flto 
-fdiagnostics-color=always -pipe -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch 
-Wextra -std=gnu99 -Wno-unused-parameter -Wno-missing-field-initializers 
-Wno-unused-result -Wno-format-signedness -Werror=undef -Wlogical-op 
-Wmissing-include-dirs -Wold-style-definition -Wpointer-arith -Winit-self 
-Wfloat-equal -Wsuggest-attribute=noreturn -Werror=missing-prototypes 
-Werror=implicit-function-declaration -Werror=missing-declarations 
-Werror=return-type -Werror=incompatible-pointer-types -Werror=format=2 
-Wstrict-prototypes -Wredundant-decls -Wmissing-noreturn 
-Wimplicit-fallthrough=5 -Wshadow -Wendif-labels -Wstrict-aliasing=2 
-Wwrite-strings -Werror=overflow -Werror=shift-count-overflow 
-Werror=shift-overflow=2 -Wdate-time -Wnested-externs -Wno-maybe-uninitialized 
-ffast-math -fno-common -fdiagnostics-show-option -fno-strict-aliasing 
-fvisibility=hidden -fstack-protector -fstack-protector-strong 
--param=ssp-buffer-size=4 -ffunction-sections -fdata-sections -Werror=shadow 
-include config.h -g -O2 '-fdebug-prefix-map=/<>=.' 
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
-D_FORTIFY_SOURCE=2 -fPIC -pthread -fvisibility=default -MD -MQ 
src/basic/libbasic.a.p/fd-util.c.o -MF src/basic/libbasic.a.p/fd-util.c.o.d -o 
src/basic/libbasic.a.p/fd-util.c.o -c ../src/basic/fd-util.c
In file included from ../src/basic/fd-util.c:19:
../src/basic/missing_syscall.h:190:4: warning: #warning "name_to_handle_at 
number is not defined" [-Wcpp]
  190 | #  warning "name_to_handle_at number is 

Bug#974139: libpango1.0-dev: PangoFcFont, PangoFcFontMap no longer subclassable

[Marc Lehmann]

On Thu, Nov 12, 2020 at 11:27:13AM +, Simon McVittie  
wrote:
> So, the core issue there is less that PangoFcFontClass,
> PangoFcFontMapClass are no longer available for subclassing, but more
> that they *were* visible in the past, and therefore code outside Pango
> (like yours) might already be relying on them to continue to have the
> same struct layout that they had in buster. Is that correct?

Yes. And in addition, upstream has changed their members and increased
their sizes, so existing binaries might or might not work, and might or
might not cause out of bounds accesses.

> Are you aware of code in Debian that subclasses them, or is this only a
> concern for non-Debian code making use of the fact that subclassing is/was
> allowed?

I don't know of a registry or anything to keep track of that - certainly
most libpango users don't use this functionality (at leats not in this
way), but it is the only way to get your own renderer as far as I can see.

There are two issues: subclassing embeds (by necessity) the structure inside
the client binary. That is probably quite rare, as most programs just use one
of the existing backends. The size change will affect that.

The other issue is changed structure members. This is probably quite a bit
more common (but again, I have no way to find out), because a lot more code
might want to access the previously public members. This will typically not
(immediately) cause out of bounds accesses, but more likely in crashes, but
every case

I also only looked at two of the many classes in pango, namely
pangofc-font and pangofc-fontmap, but the changes are larger and ongoing,
and a few minor changes already have caused issues with existing programs
such as lilypad and have been undone, and I initially hoped that pango
upstream might undo the other breaking changes, but it seems clear to me
that the changes overall are extensive and they are not willing to undo
more than tiny parts of it (although I got very frustrated because I just
couldn't get a clear answer).

So I don't know what else changed in detail, and even less what the impact
is, and even less than that how to find affected programs.

I also don't know if this ABI breakage is ongoing - in the past, pango
develoeprs have broken the AIB before without changing the soname (I
opened a bug report for this in debian in 2009 and the then debian
maintainer got upstream to partially change it), but the conflicting claim
by pango upstream is that essentially nbody is working on pango, but on
the other hand, there is recent widespread breakage introduced by changign
a lot of the API, and and unknown amount of the ABI.

So while I don't know the extent of actual ABI breakage overall, most of the
changes so far seem to have *prepared* libpango for more extensive ABI
breakage.

As a data point, I created a copy of the class structure with extra
padding at the end to aovid out of bounds issues and recompiled one of my
opengl clients with it. It did seem to run with 1.45, but crashed with
1.47, so my idea with just adding the header files back wouldn't work
anyway, as pango not only changed the struct size, it also changed the
meaning of some struct members in incompatible ways.

So debian would have to bump the soname on, possibly, every release. And/or
would have to assess the amount fo breakage and the danger introduced on
every release.

Mabye this explains some of my frustration and the wording I used -
upstream is aware of this, but clearly doesn't care and the result puts
distributions such as debian in a horrible spot. And again, it all makes
very little sense, because of the claim that pango is essentially in
maintenance-only mode, there are no developers left, so who does all this
breakage and why.

That's of course only my opinion based on two of the pango classes that
directly affect me. Since this will force me to dump pango and implement
my own replacement for pango (probably based on raqm, but it's still a lot
of work), these changes in pango will, medium-term, not affect me at all
anymore.

> It might be possible to revert the changes to the layout of those classes
> to how they were in buster, mark them as private/deprecated/something,
> and if necessary move the new functionality that upstream subsequently
> added into an intermediate subclass that is then used by their in-tree
> subclasses.

Yes, making part of the API private but keeping the ABI would have been
what pango clearly should have done, followed by a 2.0 release which then
removes all the deprecated stuff. Upstream has said they won't do this, of
course.

> The good news is that, because the affected versions treat
> those classes as private and non-subclassable, this approach shouldn't
> break anything that has been compiled against the affected versions and
> expects to see the ABI that is currently in bullseye.

Yes, but I don't see how this amounts to anything less then forking pango.

For example, some of the crashes I observed are due to 

Bug#581852: Fixed in 0.6.4

[raf]

This issue can be closed. It was fixed in 0.6.4.

Bug#166694: Fixed in 0.6.4

[raf]

This issue can be closed. It was fixed in 0.6.4 (--idiot option).

Bug#580169: Fixed in 0.6.4

[raf]

This issue can be closed. It was fixed in 0.6.4.

Bug#436692: Fixed in 0.6.4

[raf]

This issue can be closed. It was fixed in 0.6.4.

Bug#651263: Fixed in 0.7

[raf]

This issue can be closed. It has been fixed in 0.7.

Bug#571205: Fixed in 0.7

[raf]

This issue can be closed. It has been fixed in 0.7.

Bug#404371: Fixed in 0.6.4

[raf]

This issue can be closed. It was fixed in 0.6.4.

Bug#439556: Fixed in 0.6.4

[raf]

This issue can be closed. It was fixed in 0.6.4.

Bug#971879: [Pkg-kde-extras] Bug#971879: Bug#971879: gthumb: "charset=Ascii" appears before the comment of the image

[Vincent Lefevre]

Control: reopen -1
Control: affects -1 nomacs

I'm reopening the bug because it also affects nomacs (though much
less seriously since a better metadata is used by nomacs), and this
time, this is a bug introduced on the Debian side: nomacs ships with
exiv2 0.27.2, and it is Debian's choice to link with exiv2 0.27.3.

Before upgrading to the incompatible version exiv2 0.27.3, this
should have been discussed with the nomacs maintainers.

For nomacs, I've opened a bug there:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=974616

in case they wish to update the nomacs source (and differ from
upstream).

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#974616: nomacs: "charset=Ascii" appears before the "User Comment" metadata of the image

[Vincent Lefevre]

Control: tags -1 - upstream

Actually, not really an upstream bug since upstream ships with
exiv2 0.27.2, and it is Debian's choice to link against 0.27.3.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#974618: nomacs: please update the Homepage URL

[Vincent Lefevre]

Package: nomacs
Version: 3.12.0+dfsg-3+b1
Severity: normal

"dpkg -s nomacs" gives:

[...]
Homepage: http://www.nomacs.org

For security, this should be replaced by: https://nomacs.org/

-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 
'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)

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

Versions of packages nomacs depends on:
ii  libc6  2.31-4
ii  libexiv2-270.27.3-3
ii  libgcc-s1  10.2.0-17
ii  libopencv-core4.2  4.2.0+dfsg-6+b4
ii  libopencv-imgproc4.2   4.2.0+dfsg-6+b4
ii  libqt5concurrent5  5.15.1+dfsg-2
ii  libqt5core5a   5.15.1+dfsg-2
ii  libqt5gui5 5.15.1+dfsg-2
ii  libqt5network5 5.15.1+dfsg-2
ii  libqt5printsupport55.15.1+dfsg-2
ii  libqt5svg5 5.15.1-2
ii  libqt5widgets5 5.15.1+dfsg-2
ii  libquazip5-1   0.9.1-1
ii  libraw20   0.20.2-1
ii  libstdc++6 10.2.0-17
ii  libtiff5   4.1.0+git191117-2
ii  qt5-image-formats-plugins  5.15.1-2

Versions of packages nomacs recommends:
ii  nomacs-l10n  3.12.0+dfsg-3

nomacs suggests no packages.

-- no debconf information

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#974617: nomacs 3.16 is available upstream

[Vincent Lefevre]

Package: nomacs
Version: 3.12.0+dfsg-3+b1
Severity: normal

nomacs 3.16 is available upstream:

  https://nomacs.org/nomacs-3-16/

It may have bug fixes.

-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 
'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)

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

Versions of packages nomacs depends on:
ii  libc6  2.31-4
ii  libexiv2-270.27.3-3
ii  libgcc-s1  10.2.0-17
ii  libopencv-core4.2  4.2.0+dfsg-6+b4
ii  libopencv-imgproc4.2   4.2.0+dfsg-6+b4
ii  libqt5concurrent5  5.15.1+dfsg-2
ii  libqt5core5a   5.15.1+dfsg-2
ii  libqt5gui5 5.15.1+dfsg-2
ii  libqt5network5 5.15.1+dfsg-2
ii  libqt5printsupport55.15.1+dfsg-2
ii  libqt5svg5 5.15.1-2
ii  libqt5widgets5 5.15.1+dfsg-2
ii  libquazip5-1   0.9.1-1
ii  libraw20   0.20.2-1
ii  libstdc++6 10.2.0-17
ii  libtiff5   4.1.0+git191117-2
ii  qt5-image-formats-plugins  5.15.1-2

Versions of packages nomacs recommends:
ii  nomacs-l10n  3.12.0+dfsg-3

nomacs suggests no packages.

-- no debconf information

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#974616: nomacs: "charset=Ascii" appears before the "User Comment" metadata of the image

[Vincent Lefevre]

Control: retitle -1 nomacs: "charset=Ascii" appears before the "User Comment" 
metadata of the image
Control: severity -1 minor
Control: tags -1 upstream

On 2020-11-13 01:17:36 +0100, Vincent Lefevre wrote:
> After the upgrade to libexiv2-27 0.27.3-3, nomacs displays
> "charset=Ascii" before the comment of the image, visible via
> Panels → Metadata Info, then Exif → Photo.

However, the preferred "Image Description" has no issue, and nomacs
seems to primarily use "Image Description" rather than "User Comment"
(contrary to gthumb, for instance). So, a rather minor issue.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#972945: They're a set

[David Steele]

todo.txt-base (#973903), todo.txt-cli (#971288), and topydo (#972945)
are being submitted as a set.
>



signature.asc
Description: OpenPGP digital signature

Bug#971288: They're a set

[David Steele]

todo.txt-base (#973903), todo.txt-cli (#971288), and topydo (#972945)
are being submitted as a set.




signature.asc
Description: OpenPGP digital signature

Bug#928037: mailcap(5): please document security considerations about %-escapes

[Marriott NZ]

Thanks for your interest in the issue, Frank.

I've looked into the run-mailcap(1) script (the reference parser, included in 
this package), and I found it also vulnerable to shell command injection.

(Test with --norun, at your own risk.)
-- rule
text/*; /usr/bin/w3m -T %t %s
-- exploit
$ type='text/$(rm -fr *)' # e.g. from a malicious mail header
$ run-mailcap --action=view "$type":filename

-- rule
text/html; /usr/bin/w3m -I %{charset} %s
-- exploit
$ charset="'\$(rm -fr *)'" # e.g. from a malicious mail header
$ charset=$charset run-mailcap --action=view filename.html

If run-mailcap is used by some mail program or script for mailcap support, then 
it's a vector for arbitrary command execution. Perhaps this deserves its own 
bug report.

Quotes on the rule obviously don't help:
-- rule
text/*; /usr/bin/w3m -T '%t' '%s'
-- exploit
$ type="text/'\$(rm -fr *)' "
-- rule
text/html; /usr/bin/w3m -I '%{charset}' '%s'
-- exploit
$ charset=" '\$(rm -rf *)' "

Other run-mailcap quirks include the replacement of '' with ', breaking 
commands like join -t ''. Not that you want to do that often, but such 
manipulation is nonstandard nonetheless.

Fortunately run-mailcap handling of %s seems safe because, if the name contains 
any shell-special punctuation or whitespace, a temporary symlink with a safe 
name is created, and the link name is used instead.

Please don't try to fix the command injection issue by adding special cases. It 
just makes it more complex to reason about, and there's always a way around it!
The only fix that would work with both quoted and unquoted rules is to just 
reject *any* shell-special punctuation or whitespaces in %-expansions.
But even if that was acceptable, it would just encourage rule writers to do 
whatever they want, and bury the security problem deeper.
Vulnerable mailcap parsers are common, in fact I haven't seen a secure one yet, 
do they actually exist?
Well, it's not entirely their fault, the right thing to do is not written 
anywhere; the standard is underspecified and security was not even considered.

I also tried to look into Thunderbird source code, which is huge and unfamiliar 
to me, so correct me if I got something wrong.

https://hg.mozilla.org/mozilla-central/file/661f0d8ae4c44db58e668c831b555dbc038b77d0/uriloader/exthandler/unix/nsOSHelperAppService.cpp

I made a couple of disturbing discoveries:
1) Thunderbird doesn't really use the %-expansion in the rules at all!
The parsing function extracts what it thinks is the "executable name" and 
returns just that.
Comments are hilarious:
"UnescapeCommand really needs some work -- it should actually do some 
unescaping"
// XXX ugly hack.  Just grab the executable name
...
// XXX End ugly hack
:D

2) Thunderbird gives a higher priority to non-wildcard rules, even if they 
appear later.
E.g. given this two rules and a text/rtf, Thunderbird picks the second rule:
text/*; emacs %s
text/rtf; soffice %s

As a consequence, it's impossible to force the use of, say emacs, for all text 
subtypes without explicitly enumerating them (generated rules can change 
anytime).
This is a violation of the rfc, which states that "The configuration 
information will be obtained from the FIRST matching entry".


In summary, mailcap is harmful.
And I won't feel safe until I can get rid of it.

I already have MAILCAP/MAILCAPS environment variables set to /dev/null, and NOP 
rules on my /etc/mailcap:
# - User Section Begins - #
application/*; true; compose=true; composetyped=true; edit=true; print=true
audio/*;   true; compose=true; composetyped=true; edit=true; print=true
font/*;true; compose=true; composetyped=true; edit=true; print=true
image/*;   true; compose=true; composetyped=true; edit=true; print=true
message/*; true; compose=true; composetyped=true; edit=true; print=true
model/*;   true; compose=true; composetyped=true; edit=true; print=true
multipart/*;   true; compose=true; composetyped=true; edit=true; print=true
text/*;true; compose=true; composetyped=true; edit=true; print=true
video/*;   true; compose=true; composetyped=true; edit=true; print=true
# -  User Section Ends  - #

But I've seen programs bypass both tricks and still pick a generated rule!
Now I'm considering doing this to prevent automatic update of /etc/mailcap:
# echo 'exit;' >/etc/update-mime.conf

Is this solution supported? If not, is there another way? update-mime.conf is 
sourced from update-mime(8), but undocumented.

Personally, I don't like the idea of having automatic associations between 
types and programs anyway, so I'm not going to miss mailcap. I'm just very 
concerned about the overall quality of the system, because something is so 
obviously broken and no one seems to care.

Bug#973287: systemd autopkgtest-virt-lxc failure on arm64

[Ryutaroh Matsumoto]

Control: block -1 by 973038

From: Michael Biebl 
Date: Wed, 11 Nov 2020 20:47:42 +0100
> Unfortunately I lack the necessary hardware to reproduce this issue.
> Can you please forward this to upstream yourself at
> https://github.com/systemd/systemd
> 
> It's likely that upstream has further questions which are best answered
> by you.

Hi Michael, thank you for your attention.
I expect autopkgtest-virt-qemu will very soon(?) support arm64/armhf guests
as
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=973038#45

autopkgtest-virt-qemu 
* should be more consistent than autopkgtest-virt-lxc, and
* can work on amd64 (and other arch.) hosts and much more people can
   reproduce the symptom with no difficulty.

So for a while I wait autopkgtest-virt-qemu for arm64/armhf, with
adding 973038 as blocking bug to this.

Best regards, Ryutaroh

Bug#974107: Segfault when running isenkram-lookup

[Gunnar Hjalmarsson]

On 2020-11-12 23:20, Matthias Klumpp wrote:

You want this patch for AppStream:
https://github.com/ximion/appstream/commit/b52858bff55d358f925b8e64bab77b953067f248


But only comments are changed there!?

Still... I built AppStream with that commit applied:

https://launchpad.net/~gunnarhj/+archive/ubuntu/appstream

and that miraculously fixes it. Thanks!

(I'm getting old.)


In any case, it'll be fixed in Debian soon-ish with the new AppStream
release, but Ubuntu will need a backported fix.


Right, we'll need to backport to Ubuntu 20.10. For some reason isenkram 
is not present in the archive for Ubuntu 20.04. Is there any other 
reason for such an appstream backport to 20.04?


On 2020-11-12 23:54, Petter Reinholdtsen wrote:

Should this BTS report be reassigned somewhere, given that the
code issue is not in isenkram?


Yeah, looks like it should be reassigned to the appstream package.

--
Gunnar Hjalmarsson
https://launchpad.net/~gunnarhj

Bug#974616: nomacs: "charset=Ascii" appears before the comment of the image

[Vincent Lefevre]

Package: nomacs
Version: 3.12.0+dfsg-3+b1
Severity: normal

After the upgrade to libexiv2-27 0.27.3-3, nomacs displays
"charset=Ascii" before the comment of the image, visible via
Panels → Metadata Info, then Exif → Photo.

This is due to the following change:

  https://github.com/Exiv2/exiv2/issues/1258

-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 
'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)

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

Versions of packages nomacs depends on:
ii  libc6  2.31-4
ii  libexiv2-270.27.3-3
ii  libgcc-s1  10.2.0-17
ii  libopencv-core4.2  4.2.0+dfsg-6+b4
ii  libopencv-imgproc4.2   4.2.0+dfsg-6+b4
ii  libqt5concurrent5  5.15.1+dfsg-2
ii  libqt5core5a   5.15.1+dfsg-2
ii  libqt5gui5 5.15.1+dfsg-2
ii  libqt5network5 5.15.1+dfsg-2
ii  libqt5printsupport55.15.1+dfsg-2
ii  libqt5svg5 5.15.1-2
ii  libqt5widgets5 5.15.1+dfsg-2
ii  libquazip5-1   0.9.1-1
ii  libraw20   0.20.2-1
ii  libstdc++6 10.2.0-17
ii  libtiff5   4.1.0+git191117-2
ii  qt5-image-formats-plugins  5.15.1-2

Versions of packages nomacs recommends:
ii  nomacs-l10n  3.12.0+dfsg-3

nomacs suggests no packages.

-- no debconf information

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#974563: corosync unable to communicate with pacemaker 1.1.16-1+deb9u1 which contains the fix for CVE-2020-25654

[Markus Koschany]

Hi,

Am Donnerstag, den 12.11.2020, 18:21 +0100 schrieb Pallai Roland:
> Hi Markus,
> 
> The problem is still the same here:

Thanks for your debug log. I have looked at every line of code again and
compared the original upstream patch from here


https://bugzilla.redhat.com/attachment.cgi?id=1722701

with the released fix from here

https://github.com/ClusterLabs/pacemaker/pull/2210/commits/7babd406e7195fcce57850a8589b06e095642c33

There is only one thing that stands out, in fencing/commands.c

if client = NULL, then they assume now it is a peer and this is always allowed
to interact. For me it is the only explanation at the moment why you still see

Rejecting IPC request 'lrmd_rsc_info' from unprivileged client crmd
 
If you take a closer look at the patch then the allowed variable must be true
in lrmd/lrmd.c but in your case it is (incorrectly) false. Since crmd is part
of pacemaker it should not be rejected. Please try the new version at

https://people.debian.org/~apo/lts/pacemaker/

and report back if that addresses the problem.

Thanks,

Markus


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

Bug#974537: [Pkg-fonts-devel] Bug#974537: fonts-noto-core: Fallback font selection changed and incorrect glyph displayed

[Jonas Smedegaard]

Quoting astian (2020-11-12 16:58:00)
> Jonas Smedegaard:
> > Quoting astian (2020-11-11 21:31:00)
> >> With version 20200323-1, when attempting to render code points such 
> >> as 0x3001 and 0x3002, fontconfig would choose "Noto Sans CJK JP" 
> >> [0] as fallback for "Monospace".  This was expected behaviour, I 
> >> want to see Japanese punctuation glyphs.
> >>   0: /usr/share/fonts/opentype/noto/NotoSansCJK-Regular.ttc
> >>
> >> Binary packages for version 20200323-1 seem to be gone from the 
> >> archive but version 20181227-1 also shows the wanted behaviour.
> >
> > Some are here: https://snapshot.debian.org/binary/fonts-noto-core/
> 
> I forgot about that site.  Unfortunately the APT package lists in 
> stable/testing/unstable no longer have a record of that version and 
> consequently I no longer have a trusted path to those files.
> 
> >> After updating to version 20201027-3 and later also 20201109-1, 
> >> fontconfig chooses "Noto Sans Mongolian" [1].  This results in 
> >> unintended glyphs.
> >>   1: /usr/share/fonts/truetype/noto/NotoSansMongolian-Regular.ttf
> >
> > I understand that this changed.  But is it a bug?  I mean, is it 
> > universally preferred to use Japanese over Mongolian for those 
> > characters?
> 
> Universally?  How could I say?  I know nothing about Mongolian, but 
> taking U+3001 as example, it's described as "ideographic comma" and 
> fontconfig (FC) recognises it as part of the charset of various CJK 
> languages (see for example "fc-lang/{ja,ko,zh_tw,zh_hk}.orth" in FC 
> sources).  Interestingly, FC does not think it is part of mn_cn (see 
> "fc-lang/mn_cn.orth").

How you could say?  Well, you just did. :-)


> It seems an odd change to me.  Here are some cases I can imagine:
> 
>   - No bug in fonts-noto-core, no technical bug in FC, no policy bug 
> in FC: I should explicitly configure FC to prioritise a Japanese 
> fallback font.  I should still want an explanation for why is 
> Mongolian preferred.
> 
>   - No bug in fonts-noto-core, no technical bug in FC, but policy bug 
> in FC: Lacking explicit configuration, a Japanese (or some other 
> CJK language) font should be generally preferred over Mongolian.
> 
>   - No bug in fonts-noto-core, but technical bug in FC: The changes in 
> fonts-noto-core have exposed a bug that causes FC to incorrectly 
> change the fallback selection in favour of this Mongolian font.
> 
>   - Bug in fonts-noto-core: Either the glyphs don't belong or there is 
> some incorrect metadata or configuration, or bad interaction with 
> other fonts, or any combination thereof, which causes FC to 
> correctly (in technical terms) change the fallback selection in 
> favour of this Mongolian font.
> 
>   - Bug in fonts-noto-cjk: As above.
> 
> I don't currently have the expertise to decide myself and at present 
> don't have the time to investigate in depth.  Maybe a FC expert's 
> opinion could help.

Thanks for lining up those possibilities.

Yeah, gathering some fontconfig experts could help clarify this.

Or the more lazy option of simply wait some time, grab another snapshot 
of Noto, and see if the problem goes away... :-P


> >> Expected behaviour:
> >>
> >>   a) The pango-view window shows the Japanese comma glyph (see for
> >>  example "Noto Sans CJK JP" in fontforge).
> >>
> >>   b) A Japanese font is preferred:
> >>Noto Sans CJK 
> >> JP:style=Regular:file=/usr/share/fonts/opentype/noto/NotoSansCJK-Regular.ttc
> >>Noto Sans 
> >> Mongolian:style=Regular:file=/usr/share/fonts/truetype/noto/NotoSansMongolian-Regular.ttf
> >>
> >> Actual behaviour:
> >>
> >>   a) The pango-view window shows a different glyph (from "Noto Sans
> >>  Mongolian").
> >>
> >>   b) A Mongolian font is preferred:
> >>Noto Sans 
> >> Mongolian:style=Regular:file=/usr/share/fonts/truetype/noto/NotoSansMongolian-Regular.ttf
> >>Noto Sans CJK 
> >> JP:style=Regular:file=/usr/share/fonts/opentype/noto/NotoSansCJK-Regular.ttc
> >
> > When I try the above with packages in unstable as of today, I get 
> > what looks to me as the comma glyph, even though fc-cache indeed 
> > shows Mongolian as prioritized.
> 
> Here's a Japanese comma (base64, PNG):
> 
>   iVBORw0KGgoNSUhEUgAAACQsCAIAAACCMY2iCXBIWXMAAAsTAAALEwEAmpwY
>   i0lEQVRYw2P8//8/A70AEwMdwahlo5aNWjZq2ahlo5aNWjZq2ahlo5ZRw7IfNxfEOoRNu/SVHpax
>   CcrI/NyT5+zVdOQ95e30/wTBv4+nu13FWARtmk98+vefEsBAlKp/H080WvGzaVec/EF7y/73
>   xZmjt75R5LH/jKNdplHLRi0btWzUsoG1DADyRkmF4+MjugBJRU5ErkJggg==
> 
> Here's what I get instead (base64, PNG):
> 
>   iVBORw0KGgoNSUhEUgAAABsxCAIAAACkgUVSCXBIWXMAAAsTAAALEwEAmpwY
>   d0lEQVRIx2P8//8/A1UBEwO1waiJoyaOmjhq4qiJoyaOmjjQJv79+fMPFU3893R9mrFR+sYX//Cp
>   +k80+Hau1Ypf0DRv/f2f+JQRbeLf2/328q49Zz4TUshIfEvq58cP//gFOAkpYxxtm42aOGriqImj
>   Jo6aCAcAgcywLcj1CDYASUVORK5CYII=
> 
> Indeed it looks like a comma, but not like a typical Japanese one.
> 
> To compare the fonts you can 

Bug#974615: ITP: libsecrecy -- C++ header only library for random access to encrypted files

[Étienne Mollier]

Package: wnpp
Severity: wishlist
Owner: Étienne Mollier 
X-Debbugs-Cc: debian-de...@lists.debian.org
X-Debbugs-Cc: debian-...@lists.debian.org

* Package name: libsecrecy
  Version : 0.0.2
  Upstream Author : German Tischler 
* URL : https://gitlab.com/german.tischler/libsecrecy/
* License : BSD 2-clause "Simplified" License
  Programming Lang: C++
  Description : C++ header only library for random access to encrypted files

 libsecrecy is a header only C++ library implementing an encrypted file format
 based on GCM (Galois Counter Mode) and AES128 or AES256.
 .
 It uses nettle[1] routines for file encryption and decryption via GCM using
 AES128 or AES256 as cipher function and gpgme[2] for key storage.
 .
 While encryption is currently only supported in a streaming fashion,
 decryption allows random access in the encrypted file due to independently
 encoded subunits.
 .
 [1] http://www.lysator.liu.se/~nisse/nettle/
 [2] https://gnupg.org/software/gpgme/index.html


Greetings,

This library popped up fairly recently as a dependency of newer
versions of the libmaus2 (version 2.0.762 is the last one I've
been able to get working on Debian without libsecrecy).  These
libraries are currently having fast paced minor releases, so I
wouldn't be surprised to close the ITP with a newer version than
announced.

Current plan is to maintain this component under Debian Med
umbrella[3], alongside its reverse dependencies.

[3] https://salsa.debian.org/med-team/libsecrecy

Kind Regards,
-- 
Étienne Mollier 
Fingerprint:  8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
Sent from /dev/pts/5, please excuse my verbosity.


signature.asc
Description: PGP signature

Bug#974538: libkscreenlocker5: kwin cannot start due to missing libkscreenunlocker5 symbols

[Norbert Preining]

Hi Scarlett, hi all,

> However, it seems that because of the ABI break in libkscreenlocker5
> there may need to be more specific dependency requirements (like

I suggest the following change in kscreenlocker debian/control, Scarlett, wdyt?
diff --git a/debian/control b/debian/control
index b961e0d..b2ba44d 100644
--- a/debian/control
+++ b/debian/control
@@ -86,6 +86,7 @@ Package: libkscreenlocker5
 Architecture: any
 Pre-Depends: psmisc
 Depends: ${misc:Depends}, ${shlibs:Depends}
+Breaks: kwin-common (<< 4:5.19), kwin-common (>> 4:5.19.90~)
 Recommends: kde-config-screenlocker
 Multi-Arch: same
 Description: Secure lock screen architecture


Norbert

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

Bug#974107: Segfault when running isenkram-lookup

[Petter Reinholdtsen]

[Matthias Klumpp]
> Oh, btw: Thank you all for the last messages, knowing which commands
> to run to reproduce this easily helped quite a bit with finding the
> culprit quite quickly (and I also looked in the code for other
> instances of this, but found only the ones in AsPool).

Well, thank you for looking into this.  Should this BTS report be
reassigned somewhere, given that the code issue is not in isenkram?

-- 
Happy hacking
Petter Reinholdtsen

Bug#973435: biosig build-depends on python3-all-dev, but only builds for the default python3 version

[Alois Schlögl]

Thanks for the hint on py3versions, this helped solving the issue for v2.1.0.


I believe bug #972684, #973435 are fixed now.

Debian packages of biosig 2.1.0-1 are now availab
https://pub.ist.ac.at/~schloegl/biosig/debian/unstable/?C=M;O=D



On 11/10/20 11:28 AM, Andreas Tille wrote:

Hi again,

On Tue, Nov 10, 2020 at 10:10:21AM +0100, Alois Schlögl wrote:

Ok, I see. Biosig can be build with any python version (it is just using the
general API for  module extension which is not)

That means, building it for any python version will work like this

(cd biosig4c++/python && python3 setup.py sdist )

(cd biosig4c++/python && python2.7 setup.py install )

This is not needed since python2.7 will be removed.


(cd biosig4c++/python && python3.8 setup.py install )
(cd biosig4c++/python && python3.9 setup.py install )

This would be

 for py in $(py3versions -s) ; do
 (cd biosig4c++/python && $py setup.py install )
  

The question is: when packaging this in debian, how to tell which python
versions are available, and how to trigger the build for that version ?

See above.
  

Will there be a python3.8-biosig and python3.9-biosig package, and how does
this affect debian/control ?

It does not affect debian/control but debian/rules.  OK, if you want
the *easy* solutition just use

 s/python3-all-dev/python3-dev/
  
in d/control, which solves the issue since only the default python3

will be used (py3versions -d).  This is the *quick* fix for the bug.
It simply depends what you *want* from your users.  I hope Michael
or Yaroslav could comment on this.  I'm out at this point since I'm
not a user of this package.


I've reverted the change, and partially fixed the build. Some issues remain
unsolved - as described before.

Hope this helps.  Other hints might be given by debian-pyt...@lists.debian.org.

Kind regards

 Andreas.

Bug#971879: [Pkg-kde-extras] Bug#971879: Bug#971879: gthumb: "charset=Ascii" appears before the comment of the image

[Pino Toscano]

retitle 971879 "charset=Ascii" appears before the comment of the image
severity 971879 normal
thanks

In data giovedì 12 novembre 2020 23:33:17 CET, Vincent Lefevre ha scritto:
> On 2020-11-12 22:48:32 +0100, Pino Toscano wrote:
> > This is not how SONAME works, especially in a binary distro like Debian.
> > Even assuming an SONAME bump is due (which IMHO is not), the consequence
> > will be:
> > 1) the SONAME of the library is bumped, either by upstream or in Debian
> > 2) the Debian package is renamed
> > 3) exiv2 will go through NEW
> > 4) there will be a new exiv2 transition, and all the packages using the
> >exiv2 library will be rebuilt anyway (including gthumb)
> > 5) we are back to the same situation
> 
> Not really. The applications should notice the change of the API via
> their testsuites (if the build does not fail in the first place),
> because they do not get the expected result. [...]
> Now, it appears that in the particular
> case of gthumb, its testsuite does not detect the issue. :( I don't
> know about the other applications, though.

That is not that much different than any other API or behaviour change.

> So, what happens in
> practice is that both versions of the library are coinstallable, and
> applications that do not support the new API yet can still use the old
> library until support is added.

That only works for your local system, not for the Debian archive.
If gthumb will not build during a library transition (for whichever
reason, API change or test suite failure), then either it is fixed to
build, or it will be removed from testing until it is fixed.
The exiv2 source is one, and it provides only a library package.

> > This is a behaviour change of the API, and IMHO there are two only
> > options:
> > a) restore the old behaviour, optionally adding a new API if needed
> > b) adapt the applications to the new behaviour of the API
> > 
> > Considering that it seems a wanted change by upstream, then I don't
> > see (a) happening, so (b) seems to me the only alternative. Sure,
> > it is not nice, but meh, not something else to do.
> > 
> > Because of the above, Vincent, what about closing this bug, since there
> > is nothing actionable in exiv2?
> 
> I think that the best workaround is to temporarily restore the old
> behavior until the applications support both the old one and the
> new one.

That would mean changing the behaviour for all _the_ exiv2 users,
including the ones that adapted to the new behaviour. Also, this is
definitely not a kind of change that I will apply locally in Debian,
since it will make exiv2 behave differently than how upstream does,
and how applications expect.

Sorry, but unless upstream changes the behaviour, then the only viable
solution is adapting the applications. Definitely this is *not* an
rc-bug, though, especially with a misleading reason.

-- 
Pino Toscano

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

Bug#971001: Please support caching packages outside the chroot

[Johannes Schauer]

Hi,

Quoting Johannes Schauer (2020-09-29 08:22:18)
> > >   $ sudo mmdebstrap --variant=apt --include='systemd-sysv udev' \
> > >   > --setup-hook='mkdir -p ./cache.ess "$1"/var/cache/apt/archives' \
> > >   > --setup-hook='sync-in ./cache.ess /var/cache/apt/archives' \
> > >   > --extract-hook="sync-out /var/cache/apt/archives ./cache.ess" \
> > >   > --essential-hook='mkdir -p ./cache.rest "$1"/var/cache/apt/archives' \
> > >   > --essential-hook='sync-in ./cache.rest /var/cache/apt/archives' \
> > >   > --customize-hook='sync-out /var/cache/apt/archives ./cache.rest' \
> > >   > unstable debian-unstable
> > 
> > This is definitely at the level of complexity where it'd be *really
> > nice* to just be able to pass `--cache-debs cachedir`, without depending
> > deeply on the specific nuance of mmdebstrap's essential/non-essential
> > handling (and potential future changes to that).
> 
> This is what the --hook-directory option is for. You put a directory 
> somewhere,
> place scripts in it according to each hook and their order and then run
> mmdebstrap like with `--hook-dir cachedir` which is just as short as your
> example. :)

thanks to an idea by David Kalnischkies, it's actually much easier. Instead of
copying the *.deb archives to /var/cache/apt/archives, they can be copied into
/var/cache/apt/archives/partial and then we don't need to keep track of two
individual caches:

$ sudo mmdebstrap --variant=apt --skip=essential/unlink \
> --setup-hook='mkdir -p ./cache "$1"/var/cache/apt/archives/partial' \
> --setup-hook='sync-in ./cache /var/cache/apt/archives/partial' \
> --customize-hook='rm -r "$1"/var/cache/apt/archives/partial' \
> --customize-hook='sync-out /var/cache/apt/archives ./cache' \
> unstable debian-unstable

This needs --skip=essential/unlink which will be part of the next mmdebstrap
release. Is there something missing to close this bug with the next release?

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#971879: [Pkg-kde-extras] Bug#971879: gthumb: "charset=Ascii" appears before the comment of the image

[Vincent Lefevre]

On 2020-11-12 22:48:32 +0100, Pino Toscano wrote:
> This is not how SONAME works, especially in a binary distro like Debian.
> Even assuming an SONAME bump is due (which IMHO is not), the consequence
> will be:
> 1) the SONAME of the library is bumped, either by upstream or in Debian
> 2) the Debian package is renamed
> 3) exiv2 will go through NEW
> 4) there will be a new exiv2 transition, and all the packages using the
>exiv2 library will be rebuilt anyway (including gthumb)
> 5) we are back to the same situation

Not really. The applications should notice the change of the API via
their testsuites (if the build does not fail in the first place),
because they do not get the expected result. So, what happens in
practice is that both versions of the library are coinstallable, and
applications that do not support the new API yet can still use the old
library until support is added. Now, it appears that in the particular
case of gthumb, its testsuite does not detect the issue. :( I don't
know about the other applications, though.

> This is a behaviour change of the API, and IMHO there are two only
> options:
> a) restore the old behaviour, optionally adding a new API if needed
> b) adapt the applications to the new behaviour of the API
> 
> Considering that it seems a wanted change by upstream, then I don't
> see (a) happening, so (b) seems to me the only alternative. Sure,
> it is not nice, but meh, not something else to do.
> 
> Because of the above, Vincent, what about closing this bug, since there
> is nothing actionable in exiv2?

I think that the best workaround is to temporarily restore the old
behavior until the applications support both the old one and the
new one.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#974212: Acknowledgement (kwin-x11 crashes, windows missing decorations)

[Karsten Hilbert]

The latest KDE in testing fixes the problem for me.

Karsten
--
GPG  40BE 5B0E C98E 1713 AFA6  5BC0 3BEA AC80 7D4F C89B

Bug#974107: Segfault when running isenkram-lookup

[Matthias Klumpp]

Am Do., 12. Nov. 2020 um 23:20 Uhr schrieb Matthias Klumpp :
> [...]
> You want this patch for AppStream:
> https://github.com/ximion/appstream/commit/b52858bff55d358f925b8e64bab77b953067f248
> Basically, Python thought it could free more objects than it should
> actually have freed - not sure why this has worked before, this
> behavior was apparently broken for quite a while. Maybe it just worked
> by accident, or another bug was fixed in Python which triggered this
> issue.
>
> In any case, it'll be fixed in Debian soon-ish with the new AppStream
> release, but Ubuntu will need a backported fix.
> [...]

Oh, btw: Thank you all for the last messages, knowing which commands
to run to reproduce this easily helped quite a bit with finding the
culprit quite quickly (and I also looked in the code for other
instances of this, but found only the ones in AsPool).

Cheers,
Matthias

-- 
I welcome VSRE emails. See http://vsre.info/

Bug#974107: Segfault when running isenkram-lookup

[Matthias Klumpp]

Am Do., 12. Nov. 2020 um 22:21 Uhr schrieb Gunnar Hjalmarsson
:
>
> On 2020-11-12 21:28, Petter Reinholdtsen wrote:
> > [Gunnar Hjalmarsson]
> >> Additional observations:
> >>
> >> * The testing failure in Ubuntu started around October 31.
> >>
> >> * The test-command-line script fails on amd64 and i386 but succeeds on
> >> other architectures.
> >
> > Is it possible to 'diff' the logs from a successful and a failing test,
> > to see what changed?  Perhaps a new version of some package or
> > something?
> >
> > I get the following when running in my Sid chroot:
> >
> >isenkram-lookup
> >
> >(process:10498): GLib-GObject-CRITICAL (recursed) **:
> >g_object_get_qdata: assertion 'G_IS_OBJECT (object)' failedAborted
> >
> > No idea what it mean. :)
>
> Unfortunately I don't have the knowledge to help with the analysis. But
> yes, since isenkram hasn't changed recently, the explanation ought to be
> changes in some other package(s).
>
> Anyway, I attached two logs from test runs in Ubuntu's autopkgtest which
> passed. One is on amd64 from October 29 and one is on arm64 from
> yesterday. They both show a bunch of warning messages, but lack the
> "KeyError" from a recent amd64 test run (attached in my last message).

You want this patch for AppStream:
https://github.com/ximion/appstream/commit/b52858bff55d358f925b8e64bab77b953067f248
Basically, Python thought it could free more objects than it should
actually have freed - not sure why this has worked before, this
behavior was apparently broken for quite a while. Maybe it just worked
by accident, or another bug was fixed in Python which triggered this
issue.

In any case, it'll be fixed in Debian soon-ish with the new AppStream
release, but Ubuntu will need a backported fix.

Cheers,
Matthias

-- 
I welcome VSRE emails. See http://vsre.info/

Bug#974614: afuse: Wrong homepage

[Davide Prina]

Package: afuse
Version: 0.4.1-1
Severity: normal

Hi,

I have see that the homepage
https://code.google.com/archive/
is no more updatable

I think the actual homepage for this project is
https://github.com/pcarrier/afuse

Ciao
Davide

Bug#974613: acme: wrong homepage + possible new version

[Davide Prina]

Package: acme
Version: 1:0.96.4-5
Severity: normal

Hi,

I have see that the homepage
https://github.com/jan0sch/acme
is no more present

I think the actual homepage for this project is
https://sourceforge.net/projects/acme-crossass/

I think also that there is a new version 0.97

Ciao
Davide

Bug#974612: an: test bug

[Paride Legovini]

Package: an
Version: 1.2-6+b1
Severity: wishlist
X-Debbugs-Cc: par...@debian.org

Just a test bug, ignore.

Bug#974611: isc-kea: Please package the *stable* versions of Kea

[Paride Legovini]

Source: isc-kea
Version: Please package the *stable* versions of Kea
Severity: normal
X-Debbugs-Cc: par...@debian.org, isc-...@packages.debian.org

Dear Maintainers,

As you certainly know Kea has a versioning scheme where odd minor
numbers are used for development releases, while even minor numbers
are considered stable. I.e.

  1.5.x development
  1.6.x stable
  1.7.x development
  1.8.x stale
  ...

I think it would make sense for Debian to package only the stable (even)
releases, perhaps uploading the development ones to experimental for
testing purposes. At the moment this would mean packaging Kea-1.8.0,
and not 1.9.1. What do you think?

As a related question, do you plan to update the package any soon? If
you can use some help please let me know and I'll submit salsa MRs.

Thanks!

Paride

Bug#974610: nextcloud-desktop: Unable to add, change or remove accounts

[René Seindal]

Package: nextcloud-desktop
Version: 3.0.1-3
Severity: important

Dear Maintainer,

With a recent upgrade the tray icon has changed behaviour.  As a
consequence of that change, it is no longer possible to add, change or
remove accounts.

If I click on the tray icon, nothing happens.  This, I believe, is by
design, but it is a change in behaviour with the upgrade.  I happen to
like the previous behaviour more.

If I right click on the tray icon, I'm presented with a menu
- Open main dialog
- Settings
- Exit

The entries "Settings" and "Exit" work as expected, but the "Open main
dialog" entry does nothing whatsoever.  Nothing appears anywhere. No
window and no error messages.

There's nothing in the journal, and if I run the nextcloud client from
the command line, nothing related appears there.

Without access to the "Main dialog" there is no longer any way to add,
change or remove an account.

-- System Information:
Debian Release: bullseye/sid
  APT prefers stable
  APT policy: (600, 'stable'), (550, 'testing'), (500, 'stable'), (1, 
'experimental'), (1, 'unstable')
Architecture: amd64 (x86_64)

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

Versions of packages nextcloud-desktop depends on:
ii  libc6  2.31-4
ii  libcloudproviders0 0.3.0-3
ii  libgcc-s1  10.2.0-16
ii  libglib2.0-0   2.66.2-1
ii  libnextcloudsync0  3.0.1-3
ii  libqt5core5a   5.15.1+dfsg-2
ii  libqt5dbus55.15.1+dfsg-2
ii  libqt5gui5 5.15.1+dfsg-2
ii  libqt5keychain10.10.0-1
ii  libqt5network5 5.15.1+dfsg-2
ii  libqt5qml5 5.15.1+dfsg-3
ii  libqt5quick5   5.15.1+dfsg-3
ii  libqt5quickcontrols2-5 5.15.1+dfsg-2
ii  libqt5sql5-sqlite  5.15.1+dfsg-2
ii  libqt5svg5 5.15.1-2
ii  libqt5webenginecore5   5.15.1+dfsg-5
ii  libqt5webenginewidgets55.15.1+dfsg-5
ii  libqt5webkit5  5.212.0~alpha4-7
ii  libqt5widgets5 5.15.1+dfsg-2
ii  libstdc++6 10.2.0-16
ii  nextcloud-desktop-common   3.0.1-3
ii  nextcloud-desktop-l10n 3.0.1-3
ii  qml-module-qtgraphicaleffects  5.15.1-2
ii  qml-module-qtqml-models2   5.15.1+dfsg-3
ii  qml-module-qtquick-controls2   5.15.1+dfsg-2
ii  qml-module-qtquick-layouts 5.15.1+dfsg-3
ii  qml-module-qtquick-window2 5.15.1+dfsg-3
ii  qml-module-qtquick25.15.1+dfsg-3

Versions of packages nextcloud-desktop recommends:
ii  nextcloud-desktop-doc  3.0.1-3

nextcloud-desktop suggests no packages.

-- no debconf information

Bug#974609: abootimg: Wrong homepage

[Davide Prina]

Package: abootimg
Version: 0.6-1
Severity: normal

Hi,

I have see that the homepage
http://gitorious.org/ac100/abootimg
is no more reachable

I think the actual homepage for this project is
https://github.com/ggrandou/abootimg

Ciao
Davide

Bug#971879: [Pkg-kde-extras] Bug#971879: gthumb: "charset=Ascii" appears before the comment of the image

[Pino Toscano]

In data giovedì 12 novembre 2020 22:25:31 CET, Vincent Lefevre ha scritto:
> Control: retitle -1 libexiv2-27: change in both the API and the ABI
> Control: severity -1 serious
> 
> On 2020-10-09 03:11:19 +0200, Vincent Lefevre wrote:
> > I think that this is
> > 
> >   https://github.com/Exiv2/exiv2/issues/1258
> > 
> > but this bug has been closed. So I don't know the current status.
> 
> According to upstream, this is a change in the behavior on purpose,
> which affects the ABI as one can see (and probably the API too). It
> is not normal that one can upgrade libexiv2-27 only, affecting other
> applications like gthumb as a consequence.
> 
> The soname should have been changed.

This is not how SONAME works, especially in a binary distro like Debian.
Even assuming an SONAME bump is due (which IMHO is not), the consequence
will be:
1) the SONAME of the library is bumped, either by upstream or in Debian
2) the Debian package is renamed
3) exiv2 will go through NEW
4) there will be a new exiv2 transition, and all the packages using the
   exiv2 library will be rebuilt anyway (including gthumb)
5) we are back to the same situation

This is a behaviour change of the API, and IMHO there are two only
options:
a) restore the old behaviour, optionally adding a new API if needed
b) adapt the applications to the new behaviour of the API

Considering that it seems a wanted change by upstream, then I don't
see (a) happening, so (b) seems to me the only alternative. Sure,
it is not nice, but meh, not something else to do.

Because of the above, Vincent, what about closing this bug, since there
is nothing actionable in exiv2?

-- 
Pino Toscano

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

Bug#927302: apache2ctl graceful can cause apache to run in a different cgroup

[Bryce Harrington]

Attached is our attempt for fixing this for ubuntu, I think this or
something like it should fix for Debian too.

Brycediff -Nru apache2-2.4.46/debian/apache2ctl apache2-2.4.46/debian/apache2ctl
--- apache2-2.4.46/debian/apache2ctl2020-08-05 11:40:13.0 -0700
+++ apache2-2.4.46/debian/apache2ctl2020-10-05 16:06:32.0 -0700
@@ -143,6 +143,18 @@
 fi
 }
 
+need_systemd () {
+# Detect if systemd is in use and should be used for managing
+# the Apache2 httpd service.  Returns 0 if so, 1 otherwise.
+if [ -z "${APACHE_STARTED_BY_SYSTEMD}" ]; then
+   case "$(readlink -f /proc/1/exe)" in
+   *systemd*)
+   return 0
+   ;;
+   esac
+fi
+return 1
+}
 
 [ ! -d ${APACHE_RUN_DIR:-/var/run/apache2} ] && mkdir -p 
${APACHE_RUN_DIR:-/var/run/apache2}
 [ ! -d ${APACHE_LOCK_DIR:-/var/lock/apache2} ] && mkdir_chown 
${APACHE_RUN_USER:-www-data} ${APACHE_LOCK_DIR:-/var/lock/apache2}
@@ -153,38 +165,38 @@
 # (this is bad if there are several apache2 instances running)
 rm -f ${APACHE_RUN_DIR:-/var/run/apache2}/*ssl_scache*
 
-need_systemd=false
-if [ -z "$APACHE_STARTED_BY_SYSTEMD" ] ; then
-case "$(readlink -f /proc/1/exe)" in
-*systemd*)
-need_systemd=true
-;;
-*)
-;;
-esac
-fi
-if $need_systemd ; then
+if need_systemd; then
 # If running on systemd we should not start httpd without systemd
 # or systemd will get confused about the status of httpd.
-echo "Invoking 'systemctl start $APACHE_SYSTEMD_SERVICE'."
-echo "Use 'systemctl status $APACHE_SYSTEMD_SERVICE' for more info."
-systemctl start "$APACHE_SYSTEMD_SERVICE"
+echo "Invoking 'systemctl start ${APACHE_SYSTEMD_SERVICE}'."
+echo "Use 'systemctl status ${APACHE_SYSTEMD_SERVICE}' for more info."
+systemctl start "${APACHE_SYSTEMD_SERVICE}"
 else
 unset APACHE_STARTED_BY_SYSTEMD
-$HTTPD ${APACHE_ARGUMENTS} -k "$ARGV"
+${HTTPD} ${APACHE_ARGUMENTS} -k "${ARGV}"
 fi
 
 ERROR=$?
 ;;
 stop|graceful-stop)
-$HTTPD ${APACHE_ARGUMENTS} -k "$ARGV"
+${HTTPD} ${APACHE_ARGUMENTS} -k "$ARGV"
 ERROR=$?
 ;;
 restart|graceful)
 if $HTTPD ${APACHE_ARGUMENTS} -t 2> /dev/null ; then
-$HTTPD ${APACHE_ARGUMENTS} -k "$ARGV"
+if need_systemd; then
+# If running on systemd we should not directly restart httpd since
+# systemd would be confused about httpd's status.
+# (See LP: #1832182)
+echo "Invoking 'systemctl restart ${APACHE_SYSTEMD_SERVICE}'."
+echo "Use 'systemctl status ${APACHE_SYSTEMD_SERVICE}' for more 
info."
+systemctl restart "${APACHE_SYSTEMD_SERVICE}"
+else
+unset APACHE_STARTED_BY_SYSTEMD
+${HTTPD} ${APACHE_ARGUMENTS} -k "${ARGV}"
+fi
 else
-$HTTPD ${APACHE_ARGUMENTS} -t
+${HTTPD} ${APACHE_ARGUMENTS} -t
 fi
 ERROR=$?
 ;;
diff -Nru apache2-2.4.46/debian/changelog apache2-2.4.46/debian/changelog
--- apache2-2.4.46/debian/changelog 2020-08-25 05:13:38.0 -0700
+++ apache2-2.4.46/debian/changelog 2020-10-05 16:06:32.0 -0700
@@ -1,3 +1,12 @@
+apache2 (2.4.46-1ubuntu2) groovy; urgency=medium
+
+  * d/apache2ctl: Also use systemd for graceful if it is in use.  This
+extends an earlier fix for the start command to behave similarly for
+restart / graceful.  Fixes service failures on unattended upgrade.
+(LP: #1832182)
+
+ -- Bryce Harrington   Mon, 05 Oct 2020 16:06:32 -0700
+
 apache2 (2.4.46-1ubuntu1) groovy; urgency=medium
 
   * Merge with Debian unstable. Remaining changes:

Bug#971879: gthumb: "charset=Ascii" appears before the comment of the image

[Vincent Lefevre]

Control: clone -1 -2
Control: reassign -2 gthumb 3:3.8.0-2.1
Control: found -2 3:3.8.3-0.1
Control: retitle -2 gthumb: "charset=Ascii" appears before the comment of the 
image
Control: severity -2 normal
Control: tags -2 upstream

As a summary, libexiv2-27 changed its API and ABI. So gthumb needs to
take this new API into account when getting the comment from libexiv2
(gthumb 3:3.8.3-0.1, which is the current version, is still affected).

(I've cloned the bug, which I initially reported against gthumb,
to keep the history.)

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#963340: (no subject)

[gustavo panizzo]

Hello Adam/release team

can you comment if the attached patch [1] is acceptable for inclusion in the
next stable update?

It addresses #961589, #963012 and the flushing rules logic [2]?


[1] also in salsa, https://salsa.debian.org/debian/iptables-persistent/-/compare/0b041b4bdeb590a58c34aadd6a44c8eef68a09ca...buster 
[2] https://salsa.debian.org/debian/iptables-persistent/-/commit/e8046c6d0434e229f4ca1732ecfa72816bddaf1c 


thanks again
--
IRC: gfa
GPG: 0x27263FA42553615F904A7EBE2A40A2ECB8DAD8D5
OLD GPG: 0x44BB1BA79F6C6333
diff -Nru iptables-persistent-1.0.11/debian/changelog 
iptables-persistent-1.0.11+deb10u1/debian/changelog
--- iptables-persistent-1.0.11/debian/changelog 2019-02-09 05:36:39.0 
+0100
+++ iptables-persistent-1.0.11+deb10u1/debian/changelog 2020-11-12 
22:12:57.0 +0100
@@ -1,3 +1,15 @@
+iptables-persistent (1.0.11+deb10u1) buster; urgency=medium
+
+  * [cdc4a5] Do not load modules.
+Thanks to Thorsten Glaser 
+(Closes: #963012)
+  * [cdc4a5] Do not call log_action_cont_msg()
+Thanks to Synthea 
+(Closes: #961589)
+  * [b6e6f9] Backport the logic to flush rules from 1.0.14
+
+ -- gustavo panizzo   Thu, 12 Nov 2020 21:12:57 +
+
 iptables-persistent (1.0.11) unstable; urgency=medium
 
   * [e491d7] Make iptables-persistent to Pre-Depends on iptables.
diff -Nru iptables-persistent-1.0.11/plugins/15-ip4tables 
iptables-persistent-1.0.11+deb10u1/plugins/15-ip4tables
--- iptables-persistent-1.0.11/plugins/15-ip4tables 2019-02-09 
03:10:09.0 +0100
+++ iptables-persistent-1.0.11+deb10u1/plugins/15-ip4tables 2020-11-12 
22:12:40.0 +0100
@@ -27,34 +27,26 @@
 save_rules()
 {
#save IPv4 rules
-   #need at least iptable_filter loaded:
-   modprobe -b -q iptable_filter || true
-   if [ ! -f /proc/net/ip_tables_names ]; then
-   echo "Warning: skipping IPv4 (Kernel support is missing)"
-else
-   touch /etc/iptables/rules.v4
-   chmod 0640 /etc/iptables/rules.v4
-   iptables-save > /etc/iptables/rules.v4
-   fi
+   touch /etc/iptables/rules.v4
+   chmod 0640 /etc/iptables/rules.v4
+   iptables-save > /etc/iptables/rules.v4
 }
 
 flush_rules()
 {
-   if [ ! -f /proc/net/ip_tables_names ]; then
-   log_action_cont_msg "Warning: skipping IPv4 (Kernel support is 
missing)"
-elif [ $(which iptables) ]; then
-   for chain in INPUT FORWARD OUTPUT
-   do
-   iptables -P $chain ACCEPT
-   done
-   for param in F Z X; do iptables -$param; done
-   for table in $(cat /proc/net/ip_tables_names)
-   do
-   iptables -t $table -F
-   iptables -t $table -Z
-   iptables -t $table -X
-   done
-   fi
+TABLES=$(iptables-save | sed -E -n 's/^\*//p')
+for table in $TABLES
+do
+CHAINS=$(iptables-save -t $table | sed -E -n 's/^:([A-Z]+).*/\1/p')
+for chain in $CHAINS
+do
+# policy can't be set on user-defined chains
+iptables -t $table -P $chain ACCEPT || true
+done
+iptables -t $table -F
+iptables -t $table -Z
+iptables -t $table -X
+done
 }
 
 case "$1" in
diff -Nru iptables-persistent-1.0.11/plugins/25-ip6tables 
iptables-persistent-1.0.11+deb10u1/plugins/25-ip6tables
--- iptables-persistent-1.0.11/plugins/25-ip6tables 2019-02-09 
03:10:09.0 +0100
+++ iptables-persistent-1.0.11+deb10u1/plugins/25-ip6tables 2020-11-12 
22:12:40.0 +0100
@@ -30,34 +30,26 @@
 save_rules()
 {
#save IPv6 rules
-   #need at least ip6table_filter loaded:
-   modprobe -b -q ip6table_filter || true
-   if [ ! -f /proc/net/ip6_tables_names ]; then
-   log_action_cont_msg "Warning: skipping IPv6 (Kernel support is 
missing)"
-   else
-   touch /etc/iptables/rules.v6
-   ip6tables-save > /etc/iptables/rules.v6
-   chmod 0640 /etc/iptables/rules.v6
-   fi
+   touch /etc/iptables/rules.v6
+   ip6tables-save > /etc/iptables/rules.v6
+   chmod 0640 /etc/iptables/rules.v6
 }
 
 flush_rules()
 {
-   if [ ! -f /proc/net/ip6_tables_names ]; then
-   echo "Warning: skipping IPv6 (Kernel support is missing)"
-elif [ $(which ip6tables) ]; then
-   for chain in INPUT FORWARD OUTPUT
-   do
-   ip6tables -P $chain ACCEPT
-   done
-   for param in F Z X; do ip6tables -$param; done
-   for table in $(cat /proc/net/ip6_tables_names)
-   do
-   ip6tables -t $table -F
-   ip6tables -t $table -Z
-   ip6tables -t $table -X
-   done
-   fi
+TABLES=$(ip6tables-save | sed -E -n 's/^\*//p')
+for table in $TABLES
+do
+

Bug#971879: gthumb: "charset=Ascii" appears before the comment of the image

[Vincent Lefevre]

Control: retitle -1 libexiv2-27: change in both the API and the ABI
Control: severity -1 serious

On 2020-10-09 03:11:19 +0200, Vincent Lefevre wrote:
> I think that this is
> 
>   https://github.com/Exiv2/exiv2/issues/1258
> 
> but this bug has been closed. So I don't know the current status.

According to upstream, this is a change in the behavior on purpose,
which affects the ABI as one can see (and probably the API too). It
is not normal that one can upgrade libexiv2-27 only, affecting other
applications like gthumb as a consequence.

The soname should have been changed.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#974107: Segfault when running isenkram-lookup

[Gunnar Hjalmarsson]

On 2020-11-12 21:28, Petter Reinholdtsen wrote:

[Gunnar Hjalmarsson]

Additional observations:

* The testing failure in Ubuntu started around October 31.

* The test-command-line script fails on amd64 and i386 but succeeds on
other architectures.


Is it possible to 'diff' the logs from a successful and a failing test,
to see what changed?  Perhaps a new version of some package or
something?

I get the following when running in my Sid chroot:

   isenkram-lookup

   (process:10498): GLib-GObject-CRITICAL (recursed) **:
   g_object_get_qdata: assertion 'G_IS_OBJECT (object)' failedAborted

No idea what it mean. :)


Unfortunately I don't have the knowledge to help with the analysis. But 
yes, since isenkram hasn't changed recently, the explanation ought to be 
changes in some other package(s).


Anyway, I attached two logs from test runs in Ubuntu's autopkgtest which 
passed. One is on amd64 from October 29 and one is on arm64 from 
yesterday. They both show a bunch of warning messages, but lack the 
"KeyError" from a recent amd64 test run (attached in my last message).


--
Gunnar Hjalmarsson
https://launchpad.net/~gunnarhj


test-command-line-stdout_success_amd64_20201029.gz
Description: application/gzip


test-command-line-stdout_success_arm64_2020.gz
Description: application/gzip

Bug#974539: diff NMU for aspcud_1.9.4-2.1

[Ralf Treinen]

Hello,

On Thu, Nov 12, 2020 at 10:02:57PM +0100, Anton Gladky wrote:

> Dear maintainer,
> 
> I have prepared an NMU (versioned as 1.9.4-2.1) and
> uploaded to DELAYED/10.

I have just uploaded 1.9.4-3 including your patch, so you may cancel
your upload.

Thanks for your patch -Ralf.

Bug#974595: [Pkg-javascript-devel] Bug#974595: node-snapdragon-util: missing Breaks+Replaces: node-snapdragon (<= 0.12.0+repack-2)

[Xavier]

Control: reassign -1 node-snapdragon
Control: affects -1 node-snapdragon

Le 12/11/2020 à 20:49, Andreas Beckmann a écrit :
> Package: node-snapdragon-util
> Version: 5.0.1-2
> Severity: serious
> User: debian...@lists.debian.org
> Usertags: piuparts
> 
> Hi,
> 
> during a test with piuparts I noticed your package fails to upgrade from
> 'testing'.
> It installed fine in 'testing', then the upgrade to 'sid' fails
> because it tries to overwrite other packages files without declaring a
> Breaks+Replaces relation.
> 
> See policy 7.6 at
> https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces
> 
> From the attached log (scroll to the bottom...):
> 
>   Preparing to unpack .../node-snapdragon-util_5.0.1-2_all.deb ...
>   Unpacking node-snapdragon-util (5.0.1-2) ...
>   dpkg: error processing archive 
> /var/cache/apt/archives/node-snapdragon-util_5.0.1-2_all.deb (--unpack):
>trying to overwrite '/usr/share/nodejs/snapdragon-util/index.js', which is 
> also in package node-snapdragon 0.12.0+repack-2
>   Errors were encountered while processing:
>/var/cache/apt/archives/node-snapdragon-util_5.0.1-2_all.deb
> 
> 
> cheers,
> 
> Andreas

Reassigned to node-snapdragon that requires an older node-snapdragon-util

Bug#974603: diff NMU for colobot_0.1.12-6.1

[Anton Gladky]

tags 974603 +pending +patch
thanks

Dear maintainer,

I have prepared an NMU (versioned as 0.1.12-6.1) and
uploaded to DELAYED/10.

Please feel free to tell me if I should delay it longer, cancel
or reschedule.

Diff is attached.

Best regards

Anton Gladky


nmu.debdiff
Description: Binary data

Bug#974539: diff NMU for aspcud_1.9.4-2.1

[Anton Gladky]

tags 974539 +pending +patch
thanks

Dear maintainer,

I have prepared an NMU (versioned as 1.9.4-2.1) and
uploaded to DELAYED/10.

Please feel free to tell me if I should delay it longer, cancel
or reschedule.

Diff is attached.

Best regards

Anton Gladky


nmu.debdiff
Description: Binary data

Bug#974594: [Pkg-javascript-devel] Bug#974594: node-snapdragon-node: missing Breaks+Replaces: node-snapdragon (<= 0.12.0+repack-2)

[Xavier]

control: reassign -1 node-snapdragon
control: affects -1 node-snapdragon-node

Le 12/11/2020 à 20:47, Andreas Beckmann a écrit :
> Package: node-snapdragon-node
> Version: 3.0.0-2
> Severity: serious
> User: debian...@lists.debian.org
> Usertags: piuparts
> 
> Hi,
> 
> during a test with piuparts I noticed your package fails to upgrade from
> 'testing'.
> It installed fine in 'testing', then the upgrade to 'sid' fails
> because it tries to overwrite other packages files without declaring a
> Breaks+Replaces relation.
> 
> See policy 7.6 at
> https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces
> 
> From the attached log (scroll to the bottom...):
> 
>   Preparing to unpack .../node-snapdragon-node_3.0.0-2_all.deb ...
>   Unpacking node-snapdragon-node (3.0.0-2) ...
>   dpkg: error processing archive 
> /var/cache/apt/archives/node-snapdragon-node_3.0.0-2_all.deb (--unpack):
>trying to overwrite '/usr/share/nodejs/snapdragon-node/index.js', which is 
> also in package node-snapdragon 0.12.0+repack-2
>   Errors were encountered while processing:
>/var/cache/apt/archives/node-snapdragon-node_3.0.0-2_all.deb

Reassigned to node-snapdragon that installs an older version of
snapdragon-node

Bug#974437: Providing a non-superficial test

[Pierre Gruet]

Control: tags -1 pending


Hi,

I have marked the test as superficial and provided another one, which
runs some of the build-time tests.

Upload to come soon.

Best,
Pierre

Bug#974606: rust-tokio-process: unsatisfiable build-dependency

[Ralf Treinen]

Source: rust-tokio-process
Version: 0.2.4-1
Severity: serious
User: trei...@debian.org
Usertags: edos-uninstallable

Hi,

rust-tokio-process build-depends on librust-crossbeam-queue-0.1+default-dev.
This package does not exist in sid or in the NEW queue.

-Ralf.

Bug#974607: RM: musescore -- ROM; renamed to musescore3

[Thorsten Glaser]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: t...@mirbsd.de

Dear ftpmasters,

please g/c src:musescore from unstable; it’s been renamed
to src:musescore3 fully taking over every binary package
formerly built from there.

Thanks in advance,
//mirabilos

Bug#974605: zeromq3 should build-depend on libbsd-dev

[Adrian Bunk]

Source: zeromq3
Version: 4.3.3-1
Severity: normal

https://github.com/zeromq/libzmq/releases/tag/v4.3.3

Note for packagers: an internal reimplementation of strlcpy is now included,
for wider platform compatibility.
libbsd can be used and is enabled by default if available instead of the
internal implementation, for better security maintenance in distros.


https://buildd.debian.org/status/fetch.php?pkg=zeromq3=amd64=4.3.3-2%2Bb1=1602351295=0

...
checking for libbsd... no
configure: WARNING: Cannot find libbsd
...

Bug#974604: rust-sloppy-rfc4880: unsatisfiable build-dependency

[Ralf Treinen]

Source: rust-sloppy-rfc4880
Version: 0.1.5-2
Severity: serious
User: trei...@debian.org
Usertags: edos-uninstallable

Hi,

rust-sloppy-rfc4880 build-depends on
librust-base64-0.11+default-dev | librust-base64-0.10+default-dev.
However none of these exists in sid.

-Ralf.

Bug#974603: colobot: FTBFS agsinst boost_1.74

[Anton Gladky]

Package: colobot
Version: 0.1.12-6
Severity: important
Tags: ftbfs
User: team+bo...@tracker.debian.org
Usertags: boost174

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear maintainer,

it was discovered that your package failed to build against boost_1.74.
Logs can be found here [1]. Most relevant part is probably this:


cd /<>/obj-x86_64-linux-gnu/src && /usr/bin/c++ 
-DBOOST_NO_CXX11_SCOPED_ENUMS -DBOOST_NO_SCOPED_ENUMS -DHAVE_DEMANGLE 
-DNOEXCEPT=noexcept -DTESTS -DTEST_VIRTUAL=virtual -I/<>/src 
-I/<>/src/.. -I/<>/obj-x86_64-linux-gnu/src -isystem 
/usr/include/AL -isystem /usr/include/SDL2 -isystem 
/<>/lib/localename -g -O2 -fdebug-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
-D_FORTIFY_SOURCE=2 -std=gnu++11 -Wall -Werror -Wold-style-cast 
-pedantic-errors -Wmissing-declarations -Wno-error=deprecated-declarations 
-Wsuggest-override  -O2 -g -DNDEBUG -o 
CMakeFiles/colobotbase.dir/script/scriptfunc.cpp.o -c 
/<>/src/script/scriptfunc.cpp
In file included from /<>/src/script/script.cpp:21:
/<>/src/script/script.h:81:89: error: ‘numeric_limits’ is not a 
member of ‘std’
   81 | static void ColorizeScript(Ui::CEdit* edit, int rangeStart = 0, int 
rangeEnd = std::numeric_limits::max());
  | 
^~
/<>/src/script/script.h:81:104: error: expected primary-expression 
before ‘int’
   81 | static void ColorizeScript(Ui::CEdit* edit, int rangeStart = 0, int 
rangeEnd = std::numeric_limits::max());
  | 
   ^~~  
  ^~


It is planned to push boost_1.74 as the default version in Debian/Bullseye.

[1] 
http://qa-logs.debian.net/2020/10/27-boost/boost/colobot_0.1.12-6_unstable_boost.log

Best regards

Anton Gladky

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

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

-BEGIN PGP SIGNATURE-

iQJFBAEBCgAvFiEEu71F6oGKuG/2fnKF0+Fzg8+n/wYFAl+tnQkRHGdsYWRrQGRl
Ymlhbi5vcmcACgkQ0+Fzg8+n/wareQ//bPwtC9PqlgMw+JFzjFQtx4SKUSNPCn2P
hpQ++bvWb/O+moov7iBaLSIgkyVyxxj0XPOKAiioPdTIzgl1r9ybudJuVcBHvVwP
GcoJiU6kUBnJnW++3Qwvl0qgjFqBG3Kky+EMHFAZW1z9JECeM8Np19rlmdZpEM6c
qWhAZCyGSwgwlP9nSdWe4UFiCRKI4lDqrb3pl+Q06Y6IXChlxtIq0xoITp1gJAnd
wkxarfKNY5LWG8b4e0dfhdMxWFzhi/UWmEmgv7qMFn1HnOvZVKTts5lzQE4Dav+O
BeTXQsL8+lMoZi1HAa147VKTU+r+eKrlyU8QBTbg0UVco9kQcwWK3bvtTSHOLL6z
CvM9ItuAQYaH2ZF2OJJPX2l9pT4cfarPxOtlBauJN6dJrxZqeQm9WljjmV+Pncep
+iUUnMdX9/lGGkNbO75HtuPsXYEi6wO8OZJ1cwO1AhxAumuPjDISGeXmkzqOvv+b
pm8p6CpJrm03obqYGTB71Waq6P3l/r4TxfYQs1X9abjmSVwWb0IZGWdBJbLtSZR3
p1jQ2tkit4QAU1oe5PwFA+U4wtbBsSA2kbCcAU3MKoz1tWSdbX4JmMBSoxlPsR16
KWypOugqmoWnPlxfHqGAYd0DSxQkXk4J/DVDkKZT2iJAir0LmmTgAkNbVQO0XcPm
49XfVnpnuvI=
=f27V
-END PGP SIGNATURE-

Bug#974107: Segfault when running isenkram-lookup

[Petter Reinholdtsen]

[Gunnar Hjalmarsson]
> Additional observations:
>
> * The testing failure in Ubuntu started around October 31.
>
> * The test-command-line script fails on amd64 and i386 but succeeds on
>other architectures.

Is it possible to 'diff' the logs from a successful and a failing test,
to see what changed?  Perhaps a new version of some package or
something?

I get the following when running in my Sid chroot:

  isenkram-lookup 

  (process:10498): GLib-GObject-CRITICAL (recursed) **:
  g_object_get_qdata: assertion 'G_IS_OBJECT (object)' failedAborted

No idea what it mean. :)

-- 
Happy hacking
Petter Reinholdtsen

Bug#974602: libqt5core5a: Upstream issue with QProcess breaks debugging with QtCreator in 5.15.1

[Richard Duivenvoorde]

Package: libqt5core5a
Version: 5.15.1+dfsg-2
Severity: important
Tags: upstream patch

We (as QGIS developers) hit this today:
https://lists.osgeo.org/pipermail/qgis-developer/2020-November/062625.html

Since recent Qt update to 5.15.1 in Debian, QtCreator fails to debug 
Qt-Applications
(like QGIS) because of an upstream issue related to gdb, lldb and the use 
of QProcess in applications:
https://bugreports.qt.io/browse/QTBUG-86319

There seems to be an upstream fix:
https://codereview.qt-project.org/c/qt/qtbase/+/313535
of which myself I cannot check if it is OK.
I do not have enough knowledge about how to handle this: wait for 5.15.2? 
Or try to get this patch into debian (like Fedora did apparently, see osgeo 
thread).

Hope this is enough information. If you need more information let me know.
More experienced Qt/QGIS devs will probably respond on the osgeo/qgis dev list.

Regards,
Richard Duivenvoorde


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

Kernel: Linux 5.9.0-1-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_WARN
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)
LSM: AppArmor: enabled

Versions of packages libqt5core5a depends on:
ii  libc6  2.31-4
ii  libdouble-conversion3  3.1.5-6
ii  libgcc-s1  10.2.0-16
ii  libglib2.0-0   2.66.2-1
ii  libicu67   67.1-4
ii  libpcre2-16-0  10.34-7
ii  libstdc++6 10.2.0-16
ii  libzstd1   1.4.5+dfsg-4
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.1-2

Versions of packages libqt5core5a suggests:
ii  libthai0  0.1.28-3

-- no debconf information

Bug#974601: neomutt: new upstream version (latest release is 20200925)

[Benjamin Mako Hill]

Package: neomutt
Version: 20200626+dfsg.1-1
Severity: wishlist

Greetings!

Thank you for maintaining neomutt! There was a new release of neomutt in late
September that I suppose should be uploaded into Debian. It's available here
and fixes a number of bugs:

https://github.com/neomutt/neomutt/releases/tag/20200925

Some of the debian patches don't apply cleanly because the maintainers have
moved some of the documentation out from mutt_config.c over to docs/config.c
but the code itself seems to have been copied. I've made a working version of
the package (downloadable with dget) which is online here:

https://mako.cc/outgoing/neomutt-20200925-1~mako/neomutt_20200925-1~mako.dsc
https://mako.cc/outgoing/neomutt-20200925-1~mako/

I haven't done (or even looked into) the DFSG issues so I suppose those still
need to happen. I figured I'd share my work since it might be useful to you or
others. If it's not, feel free to ignore!

Regards,
Mako


-- Package-specific info:
NeoMutt 20200925
Copyright (C) 1996-2020 Michael R. Elkins and others.
NeoMutt comes with ABSOLUTELY NO WARRANTY; for details type 'neomutt -vv'.
NeoMutt is free software, and you are welcome to redistribute it
under certain conditions; type 'neomutt -vv' for details.

System: Linux 4.19.0-6-amd64 (x86_64)
ncurses: ncurses 6.2.20200212 (compiled with 6.2.20200212)
libidn: 1.33 (compiled with 1.33)
GPGME: 1.14.0-unknown
GnuTLS: 3.6.15
libnotmuch: 5.3.0
storage: tokyocabinet

Configure options: --build=x86_64-linux-gnu --prefix=/usr 
{--includedir=${prefix}/include} {--mandir=${prefix}/share/man} 
{--infodir=${prefix}/share/info} --sysconfdir=/etc --localstatedir=/var 
--disable-option-checking --disable-silent-rules 
{--libdir=${prefix}/lib/x86_64-linux-gnu} 
{--libexecdir=${prefix}/lib/x86_64-linux-gnu} --disable-maintainer-mode 
--disable-dependency-tracking --mandir=/usr/share/man --libexecdir=/usr/libexec 
--with-mailpath=/var/mail --gpgme --lua --notmuch --with-ui --gnutls --gss 
--idn --mixmaster --sasl --tokyocabinet --sqlite --autocrypt

Compilation CFLAGS: -g -O2 
-fdebug-prefix-map=/home/mako/debian/neomutt/neomutt-20200925=. 
-fstack-protector-strong -Wformat -Werror=format-security -std=c99 
-D_ALL_SOURCE=1 -D_GNU_SOURCE=1 -D__EXTENSIONS__ -I/usr/include 
-I/usr/include/lua5.4 -DNCURSES_WIDECHAR -isystem /usr/include/mit-krb5

Default options:
  +attach_headers_color +compose_to_sender +compress +cond_date +debug 
  +encrypt_to_self +forgotten_attachments +forwref +ifdef +imap +index_color 
  +initials +limit_current_thread +multiple_fcc +nested_if +new_mail +nntp +pop 
  +progress +quasi_delete +regcomp +reply_with_xorig +sensible_browser +sidebar 
  +skip_quoted +smtp +status_color +timeout +tls_sni +trash 

Compile options:
  +autocrypt +bkgdset +color +curs_set +fcntl -flock -fmemopen +futimens 
  +getaddrinfo +gnutls +gpgme +gss +hcache -homespool +idn +inotify 
  -locales_hack +lua +meta +mixmaster +nls +notmuch -openssl +pgp +regex +sasl 
  +smime +sqlite +start_color +sun_attachment +typeahead 
MAILPATH="/var/mail"
MIXMASTER="mixmaster"
PKGDATADIR="/usr/share/neomutt"
SENDMAIL="/usr/sbin/sendmail"
SYSCONFDIR="/etc"

To learn more about NeoMutt, visit: https://neomutt.org
If you find a bug in NeoMutt, please raise an issue at:
https://github.com/neomutt/neomutt/issues
or send an email to: 

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

Kernel: Linux 4.19.0-6-amd64 (SMP w/4 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) (ignored: LC_ALL 
set to en_US.UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages neomutt depends on:
ii  libc6 2.31-3
ii  libgnutls30   3.6.15-4
ii  libgpg-error0 1.38-2
ii  libgpgme111.14.0-1+b1
ii  libgssapi-krb5-2  1.17-10
ii  libidn11  1.33-2.4
ii  liblua5.4-0   5.4.0-2
ii  libncursesw6  6.2-1
ii  libnotmuch5   0.31-1+b1
ii  libsasl2-22.1.27+dfsg-2
ii  libsqlite3-0  3.33.0-1
ii  libtinfo6 6.2-1
ii  libtokyocabinet9  1.4.48-13
ii  sensible-utils0.0.12+nmu1

Versions of packages neomutt recommends:
ii  libsasl2-modules  2.1.27+dfsg-2
ii  locales   2.31-3
ii  mime-support  3.64

Versions of packages neomutt suggests:
ii  aspell  0.60.8-1
ii  ca-certificates 20200601
ii  gnupg   2.2.20-1
ii  ispell  3.4.00-8
pn  mixmaster   
ii  openssl 1.1.1g-1
ii  postfix [mail-transport-agent]  3.5.6-1
pn  urlview 

Versions of packages neomutt is related to:
ii  neomutt  20200925-1~mako

-- no debconf information

Bug#974600: damapper FTCBFS: hard codes the build architecture compiler

[Helmut Grohne]

Source: damapper
Version: 0.0+git20200322.b2c9d7f-2
Tags: patch upstream
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

damapper fails to cross build from source, because the upstream Makefile
hard codes the build architecture compiler gcc. Please consider applying
the attached patch to make the compiler substitutable. Doing so will
make damapper cross buildable.

Helmut
--- damapper-0.0+git20200322.b2c9d7f.orig/Makefile
+++ damapper-0.0+git20200322.b2c9d7f/Makefile
@@ -5,10 +5,10 @@
 all: $(ALL)
 
 damapper: damapper.c map.c map.h align.c align.h DB.c DB.h QV.c QV.h
-	gcc $(CFLAGS) $(shell dpkg-buildflags --get CFLAGS) -o damapper damapper.c map.c align.c DB.c QV.c -lpthread -lm
+	$(CC) $(CFLAGS) $(shell dpkg-buildflags --get CFLAGS) -o damapper damapper.c map.c align.c DB.c QV.c -lpthread -lm
 
 HPC.damapper: HPC.damapper.c DB.c DB.h QV.c QV.h
-	gcc $(CFLAGS) $(shell dpkg-buildflags --get CFLAGS) -o HPC.damapper HPC.damapper.c DB.c QV.c -lm
+	$(CC) $(CFLAGS) $(shell dpkg-buildflags --get CFLAGS) -o HPC.damapper HPC.damapper.c DB.c QV.c -lm
 
 clean:
 	rm -f $(ALL)

Bug#974599: fmit FTCBFS: missing Build-Depends: qt5-qmake:native for running lrelease

[Helmut Grohne]

Source: fmit
Version: 1.2.6-0.2
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

fmit fails to cross build from source, because it misses a build
dependency on qt5-qmake:native, which is required for running lrelease
on a .pro file. Please consider applying the attached patch.

Helmut
diff --minimal -Nru fmit-1.2.6/debian/changelog fmit-1.2.6/debian/changelog
--- fmit-1.2.6/debian/changelog 2019-09-07 20:48:24.0 +0200
+++ fmit-1.2.6/debian/changelog 2020-11-12 21:03:38.0 +0100
@@ -1,3 +1,11 @@
+fmit (1.2.6-0.3) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Add missing Build-Depends: qt5-qmake:native for lrelease.
+(Closes: #-1)
+
+ -- Helmut Grohne   Thu, 12 Nov 2020 21:03:38 +0100
+
 fmit (1.2.6-0.2) unstable; urgency=medium
 
   * Non-maintainer upload.
diff --minimal -Nru fmit-1.2.6/debian/control fmit-1.2.6/debian/control
--- fmit-1.2.6/debian/control   2019-09-07 20:46:29.0 +0200
+++ fmit-1.2.6/debian/control   2020-11-12 21:03:37.0 +0100
@@ -14,6 +14,7 @@
  libqt5svg5-dev,
  portaudio19-dev,
  qt5-qmake,
+ qt5-qmake:native,
  qtbase5-dev,
  qtmultimedia5-dev,
  qttools5-dev-tools,

Bug#973407: Help for r-bioc-rhdf5filters needed (Was: Bug#973407: transition: r-api-bioc-3.12)

[Sebastian Ramacher]

On 2020-11-10 08:57:32 +0100, Andreas Tille wrote:
> On Tue, Nov 03, 2020 at 12:06:11PM +0100, Andreas Tille wrote:
> > there is a new dependency r-bioc-rhdf5filters[1] which needed some work
> > to exclude code copies of Debian packaged libs.  The current packaging
> > is *not* *finished* since the actual libraries are not properly linked.
> > There are also some failures in autopkgtest.
> 
> I think my suspicion that r-bioc-rhdf5filters is not correct is proven
> by the fact that r-bioc-rhdf5 is stumbling in its test upon missing
> bzip2 and blosc - which is exactly what is introduced in
> r-bioc-rhdf5filters:
> 
> 
> > library(testthat)
> > library(rhdf5)
> > 
> > test_check("rhdf5")
> ── 1. Failure: BZIP2 filter works when reading (@test_external_filters.R#49)  
> ──
> H5Dget_storage_size(did) is not strictly less than 4 * 2000. Difference: 0
> 
> ── 2. Failure: BLOSC filter works when reading (@test_external_filters.R#57)  
> ──
> H5Dget_storage_size(did) is not strictly less than 4 * 2000. Difference: 0
> 
> ── 3. Error: Failing to read BLOSC (@test_h5read.R#342)  
> ───
> Unable to read dataset.
> Not all required filters available.
> Missing filters: blosc
> Backtrace:
>   1. testthat::expect_silent(h5read(blosc_file, "dset"))
>   9. rhdf5::h5read(blosc_file, "dset")
>  10. rhdf5:::h5readDataset(...)
>  11. base::tryCatch(...)
>  12. base:::tryCatchList(expr, classes, parentenv, handlers)
>  13. base:::tryCatchOne(expr, names, parentenv, handlers[[1L]])
>  14. value[[3L]](cond)
> 
> ── 4. Error: Failing to read BLOSC (@test_h5read.R#342)  
> ───
> Error in h5checktype(). H5Identifier not valid.
> Backtrace:
>   1. testthat::expect_silent(h5read(blosc_file, "dset"))
>   9. rhdf5::h5read(blosc_file, "dset")
>  10. rhdf5::H5Dclose(h5dataset)
>  11. rhdf5:::h5checktype(h5dataset, "dataset")
> 
> ══ testthat results  
> ═══
> [ OK: 776 | SKIPPED: 0 | WARNINGS: 0 | FAILED: 4 ]
> 1. Failure: BZIP2 filter works when reading (@test_external_filters.R#49) 
> 2. Failure: BLOSC filter works when reading (@test_external_filters.R#57) 
> 3. Error: Failing to read BLOSC (@test_h5read.R#342) 
> 4. Error: Failing to read BLOSC (@test_h5read.R#342) 
> 
> Error: testthat unit tests failed
> Execution halted
> 
> 
> 
> I think we should clarify this before uploading r-bioc-rhdf5 with a
> broken test which will prevent the migration.

Is a fix for that issues in sight? Or should we consider removal of the
r-bioc-rhdf5 and its reverse dependencies to finish the transition once
r-bioc-genomicfiles, r-bioc-degreport, and r-bioc-dexseq have been
uploaded to finish the transition?

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#974598: libflint-arb-dev: missing dependency on libflint-dev

[Claude Heiland-Allen]

Package: libflint-arb-dev
Version: 1:2.18.1-3
Severity: normal
X-Debbugs-Cc: cla...@mathr.co.uk

Dear Maintainer,

   * What led up to the situation?

I installed libflint-arb-dev and tried to compile my program,
compilation failed with:

/usr/include/mag.h:23:10: fatal error: flint/flint.h: No such file or directory
   23 | #include "flint/flint.h"
  |  ^~~

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

After installing libflint-dev compilation succeeded.

   * What outcome did you expect instead?

That installing libflint-arb-dev should allow programs using
arb to be compiled without needing to install extra packages
by hand.

Thanks for your work,


Claude


-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'testing-debug'), (500, 'unstable'), 
(500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.9.0-1-amd64 (SMP w/16 CPU threads)
Kernel taint flags: 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 /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libflint-arb-dev depends on:
ii  libflint-arb2  1:2.18.1-3

libflint-arb-dev recommends no packages.

libflint-arb-dev suggests no packages.

-- no debconf information

Bug#974596: node-snapdragon: some parts are now packaged separately

[Andreas Beckmann]

Package: node-snapdragon
Version: 0.12.0+repack-2
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package has file conflicts
with some newly introduced packages in sid, which seem to package
some components currently in node-snapdragon as separate packages.

See #974594 (node-snapdragon-node) and #974595 (node-snapdragon-util).


cheers,

Andreas

Bug#974590: wrong breakout-link warning

[Felix Lechner]

Control: retitle -1 lintian: Exempt gcc-10 and friends from breakout-link

Hi Matthias,

> It might be a good thing to check a new lintian release against some fixed set
> of packages, maybe including gcc-10 and gcc-10-cross.

We are working on away for maintainers to request exemptions for
groups of packages. It has been a long-standing pattern in Lintian but
will soon be resolved in a better place. The current effort was
prompted by Bug#974175. Your bug will likely be resolved using that
new mechanism when it is ready.

Also, it was pointed out on IRC that this bug is similar to
Bug#968525. That remark is for our records. We do not currently expect
bug reporters to check our list of open bugs, because it is so long.

Kind regards
Felix Lechner

Bug#974597: kiten: Segfaults on startup if KConfigGui::sessionConfig() returns nullptr

[Frédéric Brière]

Package: kiten
Version: 4:20.04.3-1
Severity: important
Tags: patch

kiten invariably segfaults on startup for me:

#0  0x7f3833a898ff in KConfigBase::hasGroup (this=0x0,
group=group@entry=0x561e19ce44a3 "app") at ./src/core/kconfigbase.cpp:22
#1  0x561e19cd660a in Kiten::finishInit (this=0x561e1b286560)
at ./app/kiten.cpp:297

This is due to KConfigGui::sessionConfig() no longer creating a session
config when the application is not actually being restored from an
earlier session, and returning nullptr instead.  Hence the segfault.

Patch attached.


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

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

Versions of packages kiten depends on:
ii  edict 2020.07.01-1
ii  fonts-ipafont-gothic [fonts-japanese-gothic]  00303-21
ii  fonts-kanjistrokeorders   4.003~dfsg-1
ii  kanjidic  2020.06.29-1
ii  kio   5.74.0-2
ii  libc6 2.31-4
ii  libkf5archive55.74.0-2
ii  libkf5completion5 5.74.0-2
ii  libkf5configcore5 5.74.0-2
ii  libkf5configgui5  5.74.0-2
ii  libkf5configwidgets5  5.74.0-2
ii  libkf5coreaddons5 5.74.0-2
ii  libkf5crash5  5.74.0-2
ii  libkf5i18n5   5.74.0-3
ii  libkf5kiocore55.74.0-2
ii  libkf5notifications5  5.74.0-2
ii  libkf5widgetsaddons5  5.74.0-3
ii  libkf5xmlgui5 5.74.0-2+b1
ii  libqt5core5a  5.15.1+dfsg-2
ii  libqt5dbus5   5.15.1+dfsg-2
ii  libqt5gui55.15.1+dfsg-2
ii  libqt5widgets55.15.1+dfsg-2
ii  libstdc++610.2.0-16

kiten recommends no packages.

Versions of packages kiten suggests:
pn  khelpcenter  

-- no debconf information
From 7b97ea2ba1eca291d313b92421c76eb07d0c9251 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Fr=C3=A9d=C3=A9ric=20Bri=C3=A8re?= 
Date: Tue, 10 Nov 2020 08:17:12 -0500
Subject: [PATCH] Check the return value of KConfigGui::sessionConfig() for
 nullptr
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

KConfigGui::sessionConfig() no longer creates a session config when the
application is not actually being restored from an earlier session.¹  In
this case, it will now return a null pointer, so we need to check for
that to avoid a segfault.

 ¹ See commit KDE/kconfig@23d4f14601fd8ff5ca7f28b0ad245ec1935799b2
---
 app/kiten.cpp | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/app/kiten.cpp b/app/kiten.cpp
index b6f577a..1ff9d0d 100644
--- a/app/kiten.cpp
+++ b/app/kiten.cpp
@@ -294,7 +294,8 @@ void Kiten::finishInit()
   // the app group won't exist and we show demo
   if ( _config->initialSearch() )
   {
-if ( ! KConfigGui::sessionConfig()->hasGroup( "app" ) )
+KConfig *config = KConfigGui::sessionConfig();
+if ( config && ! config->hasGroup( "app" ) )
 {
   searchTextAndRaise( QStringLiteral( "辞書" ) );
   //Note to future tinkerers... DO NOT EDIT OR TRANSLATE THAT
-- 
2.28.0

Bug#974595: node-snapdragon-util: missing Breaks+Replaces: node-snapdragon (<= 0.12.0+repack-2)

[Andreas Beckmann]

Package: node-snapdragon-util
Version: 5.0.1-2
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

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

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

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

  Preparing to unpack .../node-snapdragon-util_5.0.1-2_all.deb ...
  Unpacking node-snapdragon-util (5.0.1-2) ...
  dpkg: error processing archive 
/var/cache/apt/archives/node-snapdragon-util_5.0.1-2_all.deb (--unpack):
   trying to overwrite '/usr/share/nodejs/snapdragon-util/index.js', which is 
also in package node-snapdragon 0.12.0+repack-2
  Errors were encountered while processing:
   /var/cache/apt/archives/node-snapdragon-util_5.0.1-2_all.deb


cheers,

Andreas


node-snapdragon=0.12.0+repack-2_node-snapdragon-util=5.0.1-2.log.gz
Description: application/gzip

Bug#974594: node-snapdragon-node: missing Breaks+Replaces: node-snapdragon (<= 0.12.0+repack-2)

[Andreas Beckmann]

Package: node-snapdragon-node
Version: 3.0.0-2
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

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

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

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

  Preparing to unpack .../node-snapdragon-node_3.0.0-2_all.deb ...
  Unpacking node-snapdragon-node (3.0.0-2) ...
  dpkg: error processing archive 
/var/cache/apt/archives/node-snapdragon-node_3.0.0-2_all.deb (--unpack):
   trying to overwrite '/usr/share/nodejs/snapdragon-node/index.js', which is 
also in package node-snapdragon 0.12.0+repack-2
  Errors were encountered while processing:
   /var/cache/apt/archives/node-snapdragon-node_3.0.0-2_all.deb


cheers,

Andreas


node-snapdragon=0.12.0+repack-2_node-snapdragon-node=3.0.0-2.log.gz
Description: application/gzip

Bug#974591: [pkg-cryptsetup-devel] Bug#974591: cryptsetup: `service cryptdisks stop` fails with `loop_cryptdevs: not found` and does not close disks

[Guilhem Moulin]

Hi,

On Thu, 12 Nov 2020 at 19:17:43 +0100, Peter Corlett wrote:
> A cursory Google (and DDG etc) for `loop_cryptdevs` finds nothing
> except this line, and it is unclear what this broken code was supposed
> to achieve.

See #918008.  Seems I renamed the function to foreach_cryptdev() (see
also 1d97d98) before committing.  Ooops.

FWIW removing loop_cryptdevs() but preserving the rest of the line might
lead to undesired side-effects if a mapped device name is in the form
MAJ:MIN.  _do_stop_skipped() is meant to be used as callback with a
mapped device name as argument, not devnos.

Cheers,
-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#974593: libavif8-gdk-pixbuf: missing Breaks+Replaces: libavif7-gdk-pixbuf

[Andreas Beckmann]

Package: libavif8-gdk-pixbuf
Version: 0.8.3-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

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

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

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

  Preparing to unpack .../libavif8-gdk-pixbuf_0.8.3-1_amd64.deb ...
  Unpacking libavif8-gdk-pixbuf:amd64 (0.8.3-1) ...
  dpkg: error processing archive 
/var/cache/apt/archives/libavif8-gdk-pixbuf_0.8.3-1_amd64.deb (--unpack):
   trying to overwrite 
'/usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-avif.so',
 which is also in package libavif7-gdk-pixbuf:amd64 0.8.2-4
  Errors were encountered while processing:
   /var/cache/apt/archives/libavif8-gdk-pixbuf_0.8.3-1_amd64.deb

Since libavif7-gdk-pixbuf is gone, the Breaks+Replaces can be unversioned.


cheers,

Andreas


libavif7-gdk-pixbuf=0.8.2-4_libavif8-gdk-pixbuf=0.8.3-1.log.gz
Description: application/gzip

Bug#974592: libimobiledevice-utils: Backup fails with IOS 14

[Limewood]

Package: libimobiledevice-utils
Version: 1.2.1~git20181030.92c5462-2
Severity: important
Tags: patch

Package: libimobiledevice-utils

Version: 1.2.1~git20181030.92c5462-2


Tested with an iPhone X running IOS 14.2.

To reproduce the bug:

1. Create a directory called "iPhone"

2. Run: idevicebackup2 backup iPhone

Expected result: The connected device should be backed up to the "iPhone"
directory.

Actual result:

Backup directory is "iPhone"
Started "com.apple.mobilebackup2" service on port 49194.
Could not perform backup protocol version exchange, error code -1


It looks like this issue has been fixed in newer upstream versions. See
upstream issue report:
https://github.com/libimobiledevice/libimobiledevice/issues/1001



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

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

Versions of packages libimobiledevice-utils depends on:
ii  libc6  2.28-10
ii  libgcrypt201.8.4-5
ii  libgnutls303.6.7-4+deb10u5
ii  libimobiledevice6  1.2.1~git20181030.92c5462-2
ii  libplist3  2.0.1~git20190104.3f96731-1
ii  libtasn1-6 4.13-3
ii  libusbmuxd41.1.0~git20181007.07a493a-1

libimobiledevice-utils recommends no packages.

libimobiledevice-utils suggests no packages.

-- no debconf information

Bug#974588: openvswitch: DPDK 20.11 support and transition for bullseye

[Ben Pfaff]

[adding d...@openvswitch.org]

On Thu, Nov 12, 2020 at 04:09:20PM +, Luca Boccassi wrote:
> Source: openvswitch
> Version: 2.13.0+dfsg1-12
> Severity: normal
> X-Debbugs-CC: pkg-dpdk-de...@lists.alioth.debian.org 
> christian.ehrha...@canonical.com
> Tags: bullseye
> 
> Dear Openvswitch Maintainers,
> 
> We are scoping the src:dpdk 19.11 -> 20.11 transition. If possible,
> we'd really like to go to bullseye with the latest upstream LTS, as
> 19.11 is EOL at the end of next year.
> 
> OVS support for DPDK 20.11 will be released upstream in v2.15, which is
> due for release on February 15 [1].
> Bullseye transition freeze is on January 12 [2], so the dates
> don't align very well.
> 
> So we are looking to formulate a plan that you can agree with, to sort
> this out.
> 
> Based on experience, what Ubuntu usually does to meet release deadlines
> is to upload from git earlier than the release, so that all major
> incompatibilities can be sorted. And then after the freeze, once the
> release is officially out, do a final upgrade to the released version -
> since a similar enough version was uploaded from git, and at the end of
> a release cycle it's mostly bug fixes that land upstream, such an
> upload is acceptable.
> 
> So we'd like to propose the following ideas:
> 
> - between now and December: upload v2.14, to minimize the later jump
> - by the first week of January: upload 2.15~git from the tip of the
> master branch to experimental
> - stabilize and sort eventual build issues
> - upload dpdk 20.11 and ovs 2.15~git to unstable
> - upload 2.15 proper in February as a bug fix upload to unstable
> 
> What do you think? Does this sound like a workable plan?
> 
> We are of course happy to help - Ubuntu will go through the exact same
> process for 21.04, so a lot of the work is "shared".
> 
> Thank you!
> 
> -- 
> Kind regards,
> Luca Boccassi
> 
> [1] https://docs.openvswitch.org/en/latest/internals/release-process/
> [2] https://release.debian.org/bullseye/freeze_policy.html

Bug#974538: libkscreenlocker5: kwin cannot start due to missing libkscreenunlocker5 symbols

[Ben Wagner]

$ which kwin
/usr/bin/kwin

$ dpkg -S usr/bin/kwin
kwin-x11: /usr/bin/kwin
kwin-x11: /usr/bin/kwin_x11

$ ls -l /usr/bin/kwin
/usr/bin/kwin -> kwin_x11

$ dpkg --list kwin-x11
ii kwin-11 4:5.17.5-4 amd64 KDE window manager, X11 version

$ kwin --version
kwin: symbol lookup error: /lib/x86_64-linux-gnu/libkwin.so.5:
undefined symbol:
_ZN12ScreenLocker7KSldApp30greeterClientConnectionChangedEv

$ sudo apt clean

$ sudo apt install --reinstall kwin-x11 libkscreenlocker5
... finishes with no errors ...

$ kwin --version
kwin: symbol lookup error: /lib/x86_64-linux-gnu/libkwin.so.5:
undefined symbol:
_ZN12ScreenLocker7KSldApp30greeterClientConnectionChangedEv

$ objdump -T /lib/x86_64-linux-gnu/libkwin.so.5 | grep
greeterClientConnectionChanged
0 DF *UND* 0 _ZN12ScreenLocker7KSldApp30greeterClientConnectionChangedEv

$ dpkg -S lib/x86_64-linux-gnu/libkwin.so.5
kwin-common: /lib/x86_64-linux-gnu/libkwin.so.5.17.5
kwin-common: /lib/x86_64-linux-gnu/libkwin.so.5

$ dpkg --list kwin-common
ii kwin-common 4:5.17.5-4 amd64 KDE window manager, common files

$ sudo apt install --reinstall kwin-x11 libkscreenlocker5 kwin-common
... finishes with no errors ...

$ kwin --version
kwin: symbol lookup error: /lib/x86_64-linux-gnu/libkwin.so.5:
undefined symbol:
_ZN12ScreenLocker7KSldApp30greeterClientConnectionChangedEv

Bug#974537: [Pkg-fonts-devel] Bug#974537: fonts-noto-core: Fallback font selection changed and incorrect glyph displayed

[astian]

astian:
>   - Bug in fonts-noto-core: Either the glyphs don't belong or there is
> some incorrect metadata or configuration, or bad interaction with
> other fonts, or any combination thereof, which causes FC to
> correctly (in technical terms) change the fallback selection in
> favour of this Mongolian font.

BTW, looking at fontconfig's description of the font (fc-list -v 'Noto Sans
Mongolian') I can see that while it did gain glyphs for new code points, it
already had coverage for U+3001 and U+3002 back in version 20181227-1.  Also
"fullname" and "postscriptname" were extended with "Regular".  Full diff
against 20201109-1:

   Pattern has 24 elts (size 32)
 family: "Noto Sans Mongolian"(s)
 familylang: "en"(s)
 style: "Regular"(s)
 stylelang: "en"(s)
  -  fullname: "Noto Sans Mongolian"(s)
  +  fullname: "Noto Sans Mongolian Regular"(s)
 fullnamelang: "en"(s)
 slant: 0(i)(s)
 weight: 80(f)(s)
 width: 100(f)(s)
 foundry: "GOOG"(s)
 file: "/usr/share/fonts/truetype/noto/NotoSansMongolian-Regular.ttf"(s)
 index: 0(i)(s)
 outline: True(s)
 scalable: True(s)
 charset: 
  -  :  80002003    0001  

  -  0018: 03ff7fff   00ff  07ff  

  -  0020: 00183000 8000 0300     

  +  :  80002307    0001  

  +  0018: 03ff7fff   01ff  07ff  

  +  0020: 30183000 8000 0300     

 0024:    000f    

 0025:       1000 

  -  0030: 0006       

  -  00fe:  6000 001e     
8000
  +  0030: fc06       

  +  00fe:  6000 001e     

  +  0116:    1fff    

   (s)
 lang: mn-cn(s)
  -  fontversion: 68157(i)(s)
  -  capability: "otlayout:DFLT otlayout:mong"(s)
  +  fontversion: 131138(i)(s)
  +  capability: "otlayout:mong"(s)
 fontformat: "TrueType"(s)
 decorative: False(s)
  -  postscriptname: "NotoSansMongolian"(s)
  +  postscriptname: "NotoSansMongolian-Regular"(s)
 color: False(s)
 symbol: False(s)
 variable: False(s)

Cheers.

Bug#974563: corosync unable to communicate with pacemaker 1.1.16-1+deb9u1 which contains the fix for CVE-2020-25654

[Alejandro Taboada]

Hi !

Just tested v1.1 and the issue persists. The problem is quiet local connection 
when using with corosync

Thanks,
Alejandro

> On 12 Nov 2020, at 14:21, Pallai Roland  wrote:
> 
> Hi Markus,
> 
> The problem is still the same here:
> Nov 12 18:14:46 srv1 lrmd[990]:  warning: Rejecting IPC request 
> 'lrmd_rsc_info' from unprivileged client crmd
> Nov 12 18:14:46 srv1 lrmd[990]:  warning: Rejecting IPC request 
> 'lrmd_rsc_register' from unprivileged client crmd
> Nov 12 18:14:46 srv1 crmd[993]:error: Could not add resource 
> dummy_activenode to LRM nmsrv1
> Nov 12 18:14:46 srv1 crmd[993]:error: Invalid resource definition for 
> dummy_activenode
> 
> [root@srv1 root]# dpkg -l pacemaker
> ii  pacemaker 1.1.16-1+deb9u1.1 amd64 cluster 
> resource manager
> 
> Downgrading to "pacemaker=1.1.16-1" fixed it again.
> 
> 
> On 2020. november 12., csütörtök 17:51:28 CET, Markus Koschany wrote:
>> Thanks for reporting. This is a permission problem. I assume your clients are
>> local and not remote and you don't use the tls_backend. I have prepared 
>> another
>> update that should grant the local hacluser clients the necessary privileges.
>> You can download the source and binary files from
>> 
>> https://people.debian.org/~apo/lts/pacemaker/
>> 
>> Please report back if this fixes the problem. If not, please send me your log
>> file via private email after you have set the logfile_priority to debug in
>> corosync.conf.
> 

Bug#974591: cryptsetup: `service cryptdisks stop` fails with `loop_cryptdevs: not found` and does not close disks

[Peter Corlett]

Package: cryptsetup
Version: 2:2.3.4-1
Severity: important

Dear Maintainer,

I can no longer do e.g. `/etc/init.d/cryptdisks stop` to close all unmounted 
encrypted devices
because it fails with `loop_cryptdevs: not found`. This error comes from line 
198 of
/lib/cryptsetup/cryptdisks-functions, which appears to have been introduced 
last January in commit
863e91f0e763b92a5f70d84278116a28357e74eb by guil...@debian.org. There is no 
command `loop_cryptdevs`
installed, nor is such a shell function defined.

Deleting the token `loop_cryptdevs` from the start of the line (retaining the 
rest of the line as
`do_stop_skipped $devno_rootfs $devno_usr`) seems to make it work well enough 
for my purposes.

A cursory Google (and DDG etc) for `loop_cryptdevs` finds nothing except this 
line, and it is
unclear what this broken code was supposed to achieve. It is however quite 
clear that it was
released without being tested.

-- Package-specific info:

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

Kernel: Linux 5.9.0-1-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages cryptsetup depends on:
ii  cryptsetup-bin 2:2.3.4-1
ii  debconf [debconf-2.0]  1.5.74
ii  dmsetup2:1.02.171-3
ii  libc6  2.31-4

Versions of packages cryptsetup recommends:
ii  cryptsetup-initramfs  2:2.3.4-1
ii  cryptsetup-run2:2.3.4-1

Versions of packages cryptsetup suggests:
ii  dosfstools  4.1-2
ii  keyutils1.6.1-2
ii  liblocale-gettext-perl  1.07-4

-- debconf information:
* cryptsetup/prerm_active_mappings: true

Bug#973254: pacemaker: CVE-2020-25654 upload prepared

[Salvatore Bonaccorso]

Hi,

On Thu, Nov 12, 2020 at 07:08:26PM +0100, wf...@niif.hu wrote:
> Moritz Mühlenhoff  writes:
> 
> > On Sat, Nov 07, 2020 at 08:56:38PM +0100, wf...@niif.hu wrote:
> > 
> >> I propose a security upload with the debdiff below.  The patch series
> >> posted by upstream against 2.0.3 applies cleanly to the buster source,
> >> and is hereby included.  I'll try to do some testing while you review.
> >
> > Thanks, this looks. I also compared the upstream 2.0.3 patch set against
> > the update Ubuntu released for their 20.4 release (which also ships
> > 2.0.3) and which is identical (and without reported regressions so far)
> 
> Cool.  One can't possibly test all relevant use cases here.
> 
> > Please upload to security-master if your tests were fine as well
> 
> Done.  I managed to provoke some of the new denials with the updated
> package, and basic cluster operation remained unperturbed.
> 
> I think the changelog entry will work well enough as the DSA text.
> The LTS update used a shorter version, which is fine as well.
> 
> > (and remember to build with -sa since pacemaker is new in
> > buster-security (ftp.debian.org and security.debian.org don't share
> > tarballs)
> 
> The --source-only-changes switch of sbuild seems to counteract -sa, but
> I tried to revert that with changestool.  Hope it's fine.  If only I
> also remembered to remove the buildinfo file...  Or is that problem
> fixed already?

Just quickly commenting on that: Yes the buildd now append a suffix so
that there will be no clash with the potential uploaded
_amd64.buildinfo (I have recently seen one buildd which did not yet
did so, but I hope this is fixed as well yet).

So yes, does not matter anymore if you have an _amd64.buildinfo in the
source only. If still we trigger the issue, we will do our package
reinject dance one time :)

Regards,
Salvatore

Bug#973254: pacemaker: CVE-2020-25654 upload prepared

[wferi]

Moritz Mühlenhoff  writes:

> On Sat, Nov 07, 2020 at 08:56:38PM +0100, wf...@niif.hu wrote:
> 
>> I propose a security upload with the debdiff below.  The patch series
>> posted by upstream against 2.0.3 applies cleanly to the buster source,
>> and is hereby included.  I'll try to do some testing while you review.
>
> Thanks, this looks. I also compared the upstream 2.0.3 patch set against
> the update Ubuntu released for their 20.4 release (which also ships
> 2.0.3) and which is identical (and without reported regressions so far)

Cool.  One can't possibly test all relevant use cases here.

> Please upload to security-master if your tests were fine as well

Done.  I managed to provoke some of the new denials with the updated
package, and basic cluster operation remained unperturbed.

I think the changelog entry will work well enough as the DSA text.
The LTS update used a shorter version, which is fine as well.

> (and remember to build with -sa since pacemaker is new in
> buster-security (ftp.debian.org and security.debian.org don't share
> tarballs)

The --source-only-changes switch of sbuild seems to counteract -sa, but
I tried to revert that with changestool.  Hope it's fine.  If only I
also remembered to remove the buildinfo file...  Or is that problem
fixed already?

Salvatore Bonaccorso  writes:

> Thanks for your upload to unstable!
>
> On Tue, Nov 10, 2020 at 10:34:18PM +, Debian FTP Masters wrote:
>>* [6956006] New upstream pre-release (2.0.5~rc2) (Closes: #973254)
>
> Bonus point: please do include the assigned CVE id references which
> makes it easier to cross-check and track fixes for security issues.

I'll add the CVE ID to the changelog in the next upload, sorry.

> Thanks for your work here and for the stable upload!

Rather: thanks for your (plural) tireless work archive wide!
-- 
Cheers,
Feri

Bug#974220: libreoffice-writer: Double paste in Writer

[Rene Engelhard]

severity 974220 normal

tag 974220 + unreproducble

tag 974220 + moreinfo

thanks


Hi

Am 11.11.20 um 15:06 schrieb Claudio Ferreira Filho:
> Severity: important

As for your other bug,  this is IMHO not "important".


> When I copy anything (from browser, terminal or other application) and paste 
> in
> Writer, it paste duplicated.

Tried it with konsole and konqueror (as you use KDE) and with firefox to
try a non-KDE program.

> Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE

> [...]

> ii  gstreamer1.0-libav 1:1.18.1-dmo1
> ii  gstreamer1.0-plugins-bad   1:1.18.1-dmo2
> ii  gstreamer1.0-plugins-base  1.18.1-dmo1
> ii  gstreamer1.0-plugins-good  1.18.1-dmo1
> ii  gstreamer1.0-plugins-ugly  1:1.18.1-dmo1

Oh my.

I thought about some x11 vs. wayland difference but a) my VM says x11
anyway and b) it looks like you use drivers outside of Debian for some
graphic chips of a company I am not going to name... which apparently
then forces x11 anyway.

Long story short: works here.


Just thinking out loud: Some extra clipboard stuff or stuff doing
something with the clipboard running? But then it might also happen on
the context menu...


Regards,


Rene

Bug#974531: krb5: Please include upstream fix "Unregister thread key in SPNEGO finalization"

[Sam Hartman]

This was not clear from my message yesterday.

If you want me to prepare an update for buster, and agree to test such
an update, I'm happy to do so.

Bug#974563: corosync unable to communicate with pacemaker 1.1.16-1+deb9u1 which contains the fix for CVE-2020-25654

[Pallai Roland]

Hi Markus,

The problem is still the same here:
Nov 12 18:14:46 srv1 lrmd[990]:  warning: Rejecting IPC request 
'lrmd_rsc_info' from unprivileged client crmd
Nov 12 18:14:46 srv1 lrmd[990]:  warning: Rejecting IPC request 
'lrmd_rsc_register' from unprivileged client crmd
Nov 12 18:14:46 srv1 crmd[993]:error: Could not add resource 
dummy_activenode to LRM nmsrv1
Nov 12 18:14:46 srv1 crmd[993]:error: Invalid resource definition for 
dummy_activenode


[root@srv1 root]# dpkg -l pacemaker
ii  pacemaker 1.1.16-1+deb9u1.1 amd64 cluster 
resource manager


Downgrading to "pacemaker=1.1.16-1" fixed it again.


On 2020. november 12., csütörtök 17:51:28 CET, Markus Koschany wrote:
Thanks for reporting. This is a permission problem. I assume 
your clients are
local and not remote and you don't use the tls_backend. I have 
prepared another
update that should grant the local hacluser clients the 
necessary privileges.

You can download the source and binary files from

https://people.debian.org/~apo/lts/pacemaker/

Please report back if this fixes the problem. If not, please 
send me your log

file via private email after you have set the logfile_priority to debug in
corosync.conf.

Bug#974421: Wrong title

[Rene Engelhard]

retitle 974421 TexMaths 0.48.2 not working in Debian unstable

tag  974421 + moreinfo

tag 974421 + unreproducible

thanks


Hi,

Am 11.11.20 um 17:27 schrieb g.l. gragnani:
> Of course, title should read:
> TexMaths 0.48.2 NOT working in Debian unstable
>
You could have retitled it yourself


Anyways, replying to this mail since the first one (apparently due to
the attachement, one could have written the error message as text, maybe
then it wouldn't have been caught by spam measures):

> The last version of TexMaths (0.48.2) does not work with the packages 
> provided by Debian.

Works fine here. sid VM. TexMaths 0.48.2 from the homepage.

clicked the "pi icon", entered \int_0^1 x^2 + \frac{1}{2} -> LaTeX. I do get 
the expected integral.

Maybe you should decribe what exactly does not work?

> Instead, by using the deb packages provided by libreoffice.org all work as 
> expected.

libreoffice.org has no "deb packages".
It has stuff put out of the build system into something which happens to be a 
container in "deb" format without following standards,
I won't call that packages.


Regards,

Rene

Bug#974345: libreoffice-writer: shortcut keys don't work

[Rene Engelhard]

tag 974345 + moreinfo

tag 974345 + unreproducible

severity 974345 normal

thanks

Hi,

Am 11.11.20 um 15:17 schrieb Claudio Ferreira Filho:
>  Severity: important

Sorry, no.


|important|
a bug which has a major effect on the usability of a package,
without rendering it completely unusable to everyone.
|normal|
the default value, applicable to most bugs.

How does this have "a major effect on the usability of a package"? One
could just click the buttons?

> Working in my text, I give a insight that all shortcut keys, like (B)old,
> (I)talic, ..., aren't working.

In my de_DE env:

Ctrl-Shift-F -> Fett (bold)

Ctrl-I -> Kursiv (italic)

(yeah, a bit inconsistent, but probably some MS Office "compatibility"...)

Ctrl-U -> Unterstrichen (underline)

just works.


Now trying pt_BR.

Tooltip of the N,I,S buttons say:

Ctrl-B -> Negrito

Ctrl-I -> Itálico

Ctrl-U -> Sublinhado

And yes, that works for me. Uptodate sid VM under KDE.


Regards,


Rene

Bug#974590: wrong breakout-link warning

[Matthias Klose]

Package: lintian

gcc-N binary packages trigger some dozen warnings of the form:

W: libgcc-11-dev: breakout-link usr/lib/gcc/x86_64-linux-gnu/11/libgomp.so ->
usr/lib/x86_64-linux-gnu/libgomp.so.1

These are wrong.

It might be a good thing to check a new lintian release against some fixed set
of packages, maybe including gcc-10 and gcc-10-cross.

Bug#939424: Debian vcs

[Filippo Giunchedi]

Hi all,
 
On Tue, Apr 21, 2020 at 09:19 PM, Mahishasura wrote:
> 
> 
> Hello,
> 
> I could not find where this debian package is maintained. Please share link.
 
I'm also interested in helping out with inspircd!
 
I've gone ahead and created a shared repo on salsa, and added VCS
information: https://salsa.debian.org/debian/inspircd imported from
Christoph's repo.
 
Please let me know if this works for you!
 
Next steps IMHO would be to package the latest version and go over
triaging bugs; I'll likely start doing that in the next few days, time
permitting

Bug#974563: corosync unable to communicate with pacemaker 1.1.16-1+deb9u1 which contains the fix for CVE-2020-25654

[Markus Koschany]

Thanks for reporting. This is a permission problem. I assume your clients are
local and not remote and you don't use the tls_backend. I have prepared another
update that should grant the local hacluser clients the necessary privileges.
You can download the source and binary files from

https://people.debian.org/~apo/lts/pacemaker/

Please report back if this fixes the problem. If not, please send me your log
file via private email after you have set the logfile_priority to debug in
corosync.conf.


Regards,

Markus


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

Bug#974589: pam-python: broken autopkgtest.

[peter green]

Source: pam-python
Version: 1.0.8-1
Severity: serious

The autopkgtest for pam-python is broken, it tries to install a binary package
that does not exist.


Investigating (0) autopkgtest-satdep:amd64 < 0 @iU mK Nb Ib >
Broken autopkgtest-satdep:amd64 Depends on python-pam:amd64 < none @un H >
  Removing autopkgtest-satdep:amd64 because I can't find python-pam:amd64
Done
 Done
Starting pkgProblemResolver with broken count: 0
Starting 2 pkgProblemResolver with broken count: 0
Done
The following packages will be REMOVED:
  autopkgtest-satdep
0 upgraded, 0 newly installed, 1 to remove and 16 not upgraded.
1 not fully installed or removed.
After this operation, 0 B of additional disk space will be used.
(Reading database ... 
(Reading database ... 5%

(Reading database ... 10%
(Reading database ... 15%
(Reading database ... 20%
(Reading database ... 25%
(Reading database ... 30%
(Reading database ... 35%
(Reading database ... 40%
(Reading database ... 45%
(Reading database ... 50%
(Reading database ... 55%
(Reading database ... 60%
(Reading database ... 65%
(Reading database ... 70%
(Reading database ... 75%
(Reading database ... 80%
(Reading database ... 85%
(Reading database ... 90%
(Reading database ... 95%
(Reading database ... 100%
(Reading database ... 15356 files and directories currently installed.)
Removing autopkgtest-satdep (0) ...
autopkgtest: WARNING: package libpam-python is not installed though it should be
autopkgtest: WARNING: Test dependencies are unsatisfiable - calling apt install 
on test deps directly for further data about failing dependencies in test logs
Reading package lists...
Building dependency tree...
Reading state information...
E: Unable to locate package python-pam
pam-python-test.sh   FAIL badpkg
blame: pam-python
badpkg: Test dependencies are unsatisfiable. A common reason is that your testbed is out of date with respect to the archive, and you need to use a current testbed or run apt-get 


Also your last upload included binaries, if you want your package to migrate to 
testing then you need to make
your next upload source only.