Bug#916478: hamradio-maintguide: 'package template' link on page 5 is broken

[Petter Reinholdtsen]

[Garie Miller]
> Clicking on subject link gives server not found error. Link on DebianHam web
> page is also broken.

I had a look to see if I could find out where
http://anonscm.debian.org/viewvc/pkg-hamradio/trunk/package_template/ >.
went, without any success.  It is linked to from both packaging.rst and
vcs.rst (the latter explain how to use svn export)...

-- 
Happy hacking
Petter Reinholdtsen

Bug#933283: BD on texlive-generic-extra which isn't build anymore and isn't in bullseye

[Petter Reinholdtsen]

This was fixed in upload 0.6, but the changelog had a typo failing
to close the bug:

hamradio-maintguide (0.6) unstable; urgency=medium

  * Packaging:
   - No longer talk about priority extra
   - Add a subsection about the /var/ax25 directory and that it is
 preferred over /var/lib/ax25
  * Compat level bumped to 12
  * d/control:
   - Update dependency for texlive-plain-generic (Fixes: #933283)
   - Update standards-version to 4.4.0
  * d/copyright:
   - Use secure URL for Format

 -- Iain R. Learmonth   Mon, 05 Aug 2019 19:14:25 +0100

-- 
Happy hacking
Petter Reinholdtsen

Bug#935771: openafs-modules-source: Tries to use missing cc-wrapper with ctfutils installed

[Benjamin Kaduk]

On Sun, Aug 25, 2019 at 10:04:30PM -0400, Aaron M. Ucko wrote:
> Package: openafs-modules-source
> Version: 1.8.4~pre1-1
> Severity: normal
> 
> Attempting to build modules from openafs-modules-source (or,
> presumably, -dkms) with ctfutils installed fails because the build
> system tries to use .../src/config/cc-wrapper, which is unavailable
> here.  (In a full source tree, configure would have generated it from
> .../cc-wrapper.in.)
> 
> AFAICT, these utilities would provide little or no actual benefit
> here, at least on Linux, so I'd suggest explicitly doing without them
> by configuring --without-ctf-tools.
> 
> Could you please take a look?

Sure, and thanks for the report -- upstream made this change in
https://gerrit.openafs.org/13487 to let Solaris use the CTF information
(i.e., dtrace, if I understand correctly) in userspace as well as the
kernel, and just applying the change globally was by far the easiest
integration in the build system.  (It wasn't limited to Solaris so as to
not artificially limit any other OS that might gain the requisite
CTF/dtrace support, e.g., FreeBSD.)

I'd be vaguely curious if you wanted to drop in the cc-wrapper from a full
source tree and see if it produced anything useful, though I agree that
just configuring with --without-ctf-tools would be a fine workaround for
now.

Thanks for the report,

Ben

Bug#935932: partclone FTCBFS: does not pass --host to ./configure

[Helmut Grohne]

Source: partclone
Version: 0.3.13+dfsg-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

partclone fails to cross build from source, because it does not pass
--host to ./configure. The actual failure mode is very bad though: The
missing --host flag causes pkg-config to not find uuid, whose else
branch simply says "exit". That makes configure exit successfully
without creating a Makefile. Consequently dh skips dh_auto_build. This
is bad. Having it fail early and loudly would be very useful here.

With --host, things go much better, but it still misses the actual uuid
flags, because it ignores the ones discovered and runs the wrong
pkg-config instead. The attached patch fixes all of this. Please
consider applying it. Also consider using AC_MSG_ERROR in place of
"exit".

Helmut
diff --minimal -Nru partclone-0.3.13+dfsg/debian/changelog 
partclone-0.3.13+dfsg/debian/changelog
--- partclone-0.3.13+dfsg/debian/changelog  2019-08-26 14:37:10.0 
+0200
+++ partclone-0.3.13+dfsg/debian/changelog  2019-08-27 20:38:00.0 
+0200
@@ -1,3 +1,12 @@
+partclone (0.3.13+dfsg-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: (Closes: #-1)
++ Let dh_auto_configure pass --host to ./configure.
++ cross.patch: Don't hard code the build architecture pkg-config
+
+ -- Helmut Grohne   Tue, 27 Aug 2019 20:38:00 +0200
+
 partclone (0.3.13+dfsg-1) unstable; urgency=medium
 
   * New upstream version 0.3.13
diff --minimal -Nru partclone-0.3.13+dfsg/debian/patches/cross.patch 
partclone-0.3.13+dfsg/debian/patches/cross.patch
--- partclone-0.3.13+dfsg/debian/patches/cross.patch1970-01-01 
01:00:00.0 +0100
+++ partclone-0.3.13+dfsg/debian/patches/cross.patch2019-08-27 
20:38:00.0 +0200
@@ -0,0 +1,13 @@
+--- partclone-0.3.13+dfsg.orig/configure.ac
 partclone-0.3.13+dfsg/configure.ac
+@@ -55,8 +55,8 @@
+ fi
+ 
+ dnl Check for uuid 
+-PKG_CHECK_MODULES(UUID, uuid,,exit)
+-uuidcfg=`pkg-config --cflags --libs uuid`
++PKG_CHECK_MODULES(UUID, uuid,,exit 1)
++uuidcfg="$UUID_CFLAGS $UUID_LIBS"
+ 
+ AC_ARG_ENABLE([fuse],
+ AS_HELP_STRING(
diff --minimal -Nru partclone-0.3.13+dfsg/debian/patches/series 
partclone-0.3.13+dfsg/debian/patches/series
--- partclone-0.3.13+dfsg/debian/patches/series 2019-08-26 14:36:41.0 
+0200
+++ partclone-0.3.13+dfsg/debian/patches/series 2019-08-27 20:38:00.0 
+0200
@@ -1,3 +1,4 @@
 config-stuff.patch
 reiserfsclone.patch
 no-pie.patch
+cross.patch
diff --minimal -Nru partclone-0.3.13+dfsg/debian/rules 
partclone-0.3.13+dfsg/debian/rules
--- partclone-0.3.13+dfsg/debian/rules  2019-08-26 14:36:41.0 +0200
+++ partclone-0.3.13+dfsg/debian/rules  2019-08-27 20:38:00.0 +0200
@@ -18,7 +18,7 @@
 
 override_dh_auto_configure:
./autogen
-   ./configure --prefix=$(DESTDIR)/usr --enable-ncursesw --enable-all
+   dh_auto_configure -- --prefix=$(DESTDIR)/usr --enable-ncursesw 
--enable-all
 
 override_dh_clean: # keep the special file fail-mbr/fail-mbr.bin.orig
dh_clean

Bug#928392: fzf: zsh integration doesn't work out of the box

[Bart Joy]

Package: fzf
Version: 0.18.0-2
Followup-For: Bug #928392

Dear Maintainer,

I notice that this package copies key-bindings.zsh and completion.zsh
to the following locations:
- /usr/share/doc/fzf/examples/key-bindings.zsh
- /usr/share/zsh/vendor-completions/_fzf

However, in Arch, the files are copied to the following, different,
locations:
- /usr/share/fzf/key-bindings.zsh
- /usr/share/fzf/completion.zsh

I don't believe that completion.zsh is a valid zsh completion file, but
is instead intended to be sourced.

Would it be possible to update the package to match the Arch
installation locations, and update the README to instruct the user to
source both files?

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

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

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

fzf recommends no packages.

fzf suggests no packages.

-- no debconf information

Bug#935931: debian-installer: Reinstalling Debian on a current Debian installation without erasing or fomatting the home folder

[Daniel]

Package: debian-installer
Severity: wishlist

Dear Maintainer, this is a feature request.

Debian related distros like POP!_os and ElementaryOS, when the system is
installed in one partition: I mean inside "/", have the ability to recognize
the previous installation and reinstalling the system without erasing the user
folders already existing, so you can reuse your actual existent user. It would
be a nice feature having the same on Debian; for desktop installations this
eliminates the necessity to have partitions separated while you can reinstall
your system several times for whatever reason. Even macOS has this feature
since a very long time.

Best regards,

Daniel



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

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

Bug#935930: racket: build with -O2 to avoid misbuild with CFLAGS=-O3

[Steve Langasek]

Package: racket
Version: 7.2+dfsg1-2
Severity: minor
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu eoan ubuntu-patch

Hi David,

In Ubuntu, racket has been failing to build on ppc64el because the Ubuntu
ppc64el port, unlike Debian's, uses -O3 as the default optimization level;
and it appears that when built this way the software misbehaves, resulting
in tools segfaulting during the build:

[...]
make[6]: Entering directory '/<>/racket-7.2+dfsg1/build/gracket/gc2'
../../racket/racket3m  -O "info@compiler/cm error" -l- setup --boot 
/<>/racket-7.2+dfsg1/src/gracket/gc2/../../setup-go.rkt 
../../compiled --tag ++out 
/<>/racket-7.2+dfsg1/src/gracket/gc2/../../racket/gc2/xform-mod.rkt 
--cpp "gcc -E -I/<>/racket-7.2+dfsg1/src/gracket/gc2/../../racket/gc2 
-I./../../racket/ 
-I/<>/racket-7.2+dfsg1/src/gracket/gc2/../../racket/include/ 
-DUSE_SENORA_GC   -Wdate-time -D_FORTIFY_SOURCE=2  -Dwx_xt -MMD"  --keep-lines 
-o ++out xsrc/grmain.c +D INITIAL_COLLECTS_DIRECTORY='"'"`cd 
/<>/racket-7.2+dfsg1/src/gracket/gc2/../../../collects; pwd`"'"' +D 
INITIAL_CONFIG_DIRECTORY='"'"`cd 
/<>/racket-7.2+dfsg1/src/gracket/gc2/../../..; pwd`/etc"'"' 
/<>/racket-7.2+dfsg1/src/gracket/gc2/../grmain.c
Aborted (core dumped)
make[6]: *** [Makefile:76: xsrc/grmain.c] Error 134
[...]

  (https://launchpad.net/ubuntu/+source/racket/7.2+dfsg1-2/+build/16664122)

I've therefore uploaded the attached patch to Ubuntu to get the package
building on all architectures.

While this issue doesn't affect Debian in its default configuration, this
patch or one like it would help make the package more resilient to
downstreams that use other build flags.

Thanks for considering,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru racket-7.2+dfsg1/debian/rules racket-7.2+dfsg1/debian/rules
--- racket-7.2+dfsg1/debian/rules   2019-02-19 13:11:01.0 -0800
+++ racket-7.2+dfsg1/debian/rules   2019-08-27 17:11:35.0 -0700
@@ -1,9 +1,11 @@
 #!/usr/bin/make -f
 
+DEB_CFLAGS_MAINT_APPEND := -O2
 include /usr/share/cdbs/1/rules/debhelper.mk
 include /usr/share/cdbs/1/class/autotools.mk
 include debian/racket-arch.mk
 
+export DEB_CFLAGS_MAINT_APPEND
 DEB_HOST_ARCH ?= $(shell dpkg-architecture -qDEB_HOST_ARCH)
 DEB_CONFIGURE_SCRIPT := $(CURDIR)/src/configure
 MZDYN := mzdyn3m.o

Bug#931949: transition: proj

[Sebastiaan Couwenberg]

On 8/26/19 5:42 AM, Sebastiaan Couwenberg wrote:
> On 8/25/19 4:31 PM, Sebastiaan Couwenberg wrote:
>> On 8/25/19 3:22 PM, Jonathan Wiltshire wrote:
>>> On Fri, Jul 12, 2019 at 09:39:26PM +0200, Bas Couwenberg wrote:
 For the Debian GIS team I'd like to transition to PROJ 6.

 This is a major change that affects the wider GIS ecosystem, with proj
 being at the bottom of the dependency chain.
>>>
>>> Please go ahead.
>>
>> Thanks!
>>
>> proj (6.1.1-1), libgeotiff (1.5.1-1) & python-pyproj (2.3.0+ds-1) have
>> been uploaded to unstable. And the severity of the remaining bugreports
>> has been raised.
> 
> The packages are now also installed on all release architectures.

Thanks for the binNMUs.

For some reason survex was not included in the list of packages to
rebuild, but libgeotiff-dfsg was. Please also binnmu survex.

The FTBFS of libgeotiff-dfsg will likely result in someone filing an RC
bug which will get and keep it out of testing until it can be removed
from the archive.

It looks like the recent update of scons broke the mapnik build, I've
reporting it upstream and am trying various things to make it work again
but haven't succeeded so far.

Kind Regards,

Bas

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

Bug#935887: python3-mapproxy: Change default template_dir and fix capabilities for Python >= 3.6.7

[Sebastiaan Couwenberg]

On 8/27/19 9:53 PM, Marek Lukács wrote:
> at the moment I do not have good sandbox for playing with packaging. But I
> have checked the source package of mapproxy_1.11.0-3 (Debian Buster apt).

It's easy to setup a cowbuild chroot, see:

 https://debian-gis-team.pages.debian.net/policy/packaging.html#git-pbuilder

> For the issue with capabilities I prepared patch
> python3.7-capabilities.patch I attached. This patch can be included into
> patches and patches/series.

Your initial patch changed the installed files, not the source files in
the package used for the build as your second does, so that's good.

The changes from that patch are already included in the version uploaded
to unstable, see:

 
https://salsa.debian.org/debian-gis-team/mapproxy/commit/90539830463705197b1b6a75aada698c25f55932

Note the DEP3 patch headers. For more information about those see:

 https://dep-team.pages.debian.net/deps/dep3/

This commit will be cherry-picked for the stable update.

> And one more tip: I saw in debian/mapproxy.links:
> usr/lib/python-mapproxy/mapproxy-seed usr/bin/mapproxy-seed
> usr/lib/python-mapproxy/mapproxy-util usr/bin/mapproxy-util
> 
> It will be very useful for those using Python 3 to add:
> usr/lib/python3-mapproxy/mapproxy-seed usr/bin/mapproxy-seed
> usr/lib/python3-mapproxy/mapproxy-util usr/bin/mapproxy-util

The package in buster won't be switched to Python 3, such a change is
inappropriate for a stable update. The package in bullseye has already
dropped Python 2 support, see:

 
https://salsa.debian.org/debian-gis-team/mapproxy/commit/bc7861a0e431033554ce59cb7715d19d73be2934

I'll start preparing the stable update to fix this issue (including the
missing symlinks) soon. Since we cannot upload it before the fixed
package has migrated to testing, I'll focus on the broken mapnik that
surfaced during the ongoing proj transition first.

Kind Regards,

Bas

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

Bug#935929: RFS: btrfs-progs/5.2.1-1~bpo10+1 -- Checksumming Copy on Write Filesystem utilities

[Nicholas D Steeves]

Package: sponsorship-requests
Severity: normal

Dear mentors (CCing Gianfranco who sponsored this pkg many times in the past),

I am looking for a sponsor for my package "btrfs-progs" and am
continuing my support for a stable-backport of this package.  In
addition to the usual btrfs-check (offline fsck equivalent)
improvements and bugfixes, this release includes a variety of cosmetic 
enhancements.  P.S. the stanza below was autogenerated on mentors.

 * Package name: btrfs-progs
   Version : 5.2.1-1~bpo10+1
   Upstream Author : linux-bt...@vger.kernel.org
 * URL : http://btrfs.wiki.kernel.org/
 * License : GPL-2
 * Vcs : https://salsa.debian.org/debian/btrfs-progs/tree/debian
   Section : admin

It builds these binary packages:

  btrfs-progs - Checksumming Copy on Write Filesystem utilities
  libbtrfs0 - Checksumming Copy on Write Filesystem utilities (runtime library)
  libbtrfs-dev - Checksumming Copy on Write Filesystem utilities (development 
headers)
  libbtrfsutil1 - Checksumming Copy on Write Filesystem utilities (runtime util 
library)
  libbtrfsutil-dev - Checksumming Copy on Write Filesystem utilities (util 
development headers)
  python3-btrfsutil - Checksumming Copy on Write Filesystem utilities (python3 
bindings)
  btrfs-progs-udeb - Checksumming Copy on Write Filesystem utilities (udeb)

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

  https://mentors.debian.net/package/btrfs-progs

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

  dget -x 
https://mentors.debian.net/debian/pool/main/b/btrfs-progs/btrfs-progs_5.2.1-1~bpo10+1.dsc

Changes since the last upload:

   * Rebuild for buster-backports.
   * Restore Provides: btrfs-tools.
 .
 btrfs-progs (5.2.1-1) unstable; urgency=medium
 .
   * New upstream release.
   * Fix an option-parsing crash on btrfs check -E (Closes: #916538).
   * Avoid patching the Makefile.
   * Remove references to btrfs-tools (gone since before Stretch).
 .
 btrfs-progs (5.2-1) unstable; urgency=medium
 .
   * New upstream release.
   * Install mkfs.btrfs to /sbin (Nicholas D Steeves; closes: #911623).
   * Fix a printf format-security fatal warning.
 .
 btrfs-progs (5.1.1-1) experimental; urgency=medium
 .
   * New upstream release.
 .
 btrfs-progs (5.1-1) experimental; urgency=medium
 .
   * New maintainer.  Closes: #924368.
   * New upstream release.
   * Move the VCS to Salsa.
   * Use asciidoctor not asciidoc.  Closes: #895501.
   * Install fsck.btrfs to /sbin not /bin.  Closes: #798072.
   * Always build with ZSTD support.
   * Bring back missing btrfs-convert.  Closes: #870286.
 .
 btrfs-progs (4.20.2-1) unstable; urgency=medium
 .
   * New upstream release
   * Orphan package


Full upstream changelog here:
  https://raw.githubusercontent.com/kdave/btrfs-progs/master/CHANGES


Regards,
Nicholas
  

Bug#935928: RFS: assaultcube-data/1.2.0.2.1-4 -- data files and documentation for AssaultCube

[Carlos Donizete Froes]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "assaultcube-data"

 * Package name: assaultcube-data
   Version : 1.2.0.2.1-4
   Upstream Author : Rabid Viper Productions
 * URL : http://assault.cubers.net
 * License : Other
 * Vcs : https://salsa.debian.org/games-team/assaultcube-data
   Section : non-free/games

It builds those binary packages:

  assaultcube-data - data files and documentation for AssaultCube

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

  https://mentors.debian.net/package/assaultcube-data

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

  dget -x 
https://mentors.debian.net/debian/pool/non-free/a/assaultcube-data/assaultcube-data_1.2.0.2.1-4.dsc

Changes since the last upload:

   * debian/control: Fixed 'Suggests' related to assaultcube-data.

Regards,

--
  Carlos Donizete Froes [a.k.a coringao]

Bug#700513: (no subject)

[Smadar Barber]

I am Ms.Smadar Barber-Tsadik, I am the Chief Executive Officer with
FIRST INTERNATIONAL BANK OF ISRAEL LTD (FIBI). I am getting in touch
with you regarding an extremely important and urgent matter. If you
would oblige me the opportunity, I shall provide you with details upon
your response, please you are to contact me on my private email: 
barbertsad...@hotmail.com
 

Bug#935669: assaultcube-data: Outdated version makes assaultcube uninstallable

[Carlos Donizete Froes]

Hi Reiner,

> I think the problem is that assaultcube-data 1.2.0.2.1-2 was uploaded
> source-only. Someone needs to do a new upload including the arch:all
> binary package, as it is in non-free (which the buildds don't seem to
> build).

I suspected it was, so I added "Multi-Arch: Foreign". I don't know if it's the 
correct one.

> I think this change [0] does not help, as you can't enforce a version
> on a suggested package:
> 
> > -Suggests: assaultcube
> > +Suggests: assaultcube (>= 1.2.0.2.1)

I will be removing and awaiting sponsor review.

Thanks!

-- 
⢀⣴⠾⠻⢶⣦⠀ Carlos Donizete Froes [a.k.a coringao]
⣾⠁⢠⠒⠀⣿⡁ Debian Wiki: https://wiki.debian.org/coringao
⢿⡄⠘⠷⠚⠋⠀ GPG: 4096R/B638B780
⠈⠳⣄⠀⠀⠀  2157 630B D441 A775 BEFF  D35F FA63 ADA6 B638 B780


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

Bug#927731: epiphany-browser/i386: private libdazzle not loaded

[Carlos Alberto Lopez Perez]

On 28/08/2019 03:07, Carlos Alberto Lopez Perez wrote:
> I can confirm this bug in last Debian sid (also in stable) and on AMD64.
> 
> if you simply do "apt install epiphany-browser" libdazzle-1.0-0 is not
> installed.
> 
> The problem is not only the ugly warning on stderr, but that you miss
> the new nice search bar at all. You can read about this here:
> 
> https://blogs.gnome.org/mcatanzaro/2019/03/27/epiphany-3-32-and-webkitgtk-2-24/
> 
> Installing libdazzle-1.0-0 fixes the problem and makes the new nice
> address bar work.
> 
> You can check this yourself by installing/removing libdazzle-1.0-0 and
> reopening epiphany and seeing the different address bar.
> 
> Please, declare a dependency on libdazzle for the epiphany-browser.

Sorry, seem i tested too fast here.

What is broke is not the new search bar, but the libephywebextension.so
which is unrelated with the search bar.

This extension is injected into the WebProcess and is used for things
like remembering passwords on sites (the typical login form)


Also you can check how libephywebextension.so only loads into the
WebKitWebProcess pid map if it can resolve the linker reference to
libdazzle.

It seems that in the linking process this .so library got linked with
the system libdazzle by mistake.


So the fix is either to declare a dependecy on the system libdazzle or
rebuild this library declaring a build-conflicts with the system
libdazzle to avoid this .so linking with it (instead the package embeded
copy of libdazzle)

$ ldd 
/usr/lib/x86_64-linux-gnu/epiphany-browser/web-extensions/libephywebextension.so|grep
 -i dazz
libdazzle-1.0.so.0 => not found


$ apt-cache policy epiphany-browser
epiphany-browser:
  Installed: 3.32.1.2-2
  Candidate: 3.32.1.2-2
  Version table:
 *** 3.32.1.2-2 990
990 http://httpredir.debian.org/debian buster/main amd64 Packages
100 /var/lib/dpkg/status




signature.asc
Description: OpenPGP digital signature

Bug#933311: bitcoin-qt: symbol lookup error: bitcoin-qt: undefined symbol: _ZN7leveldb4port5Mutex6UnlockEv

[Matthew Gabeler-Lee]

On Mon, 26 Aug 2019, Jonas Smedegaard wrote:


Quoting Matthew Gabeler-Lee (2019-08-26 15:42:32)

Given its a symbols related issue, arguably that package needs its
soversion bumped?


If you mean bumping SOVERSION of bitcoin-qt, then I disagree, and ask
you to please elaborate why you think that should be done.

If you mean bumping SOVERSION of libleveldb1d then I agree.


Yes, bumping soname/soversion of libleveldb is what I meant, sorry if 
wording was unclear there.



Indeed, this package needs its dependency on libleveldb1d bumped.


This problem happened while there was no change to bitcoin-qt and while
libleveldb1d was upgraded to a newer upstream version.

The cause of this problem is therefore likely that libleveldb1d failed
to bump its soname.  Only if bitcoin-qt is linking beyond the public API
of libleveldb1d is bitcoin-qt to blame for this failure.

I see no need for bumping any dependencies: A simple rebuild made the
package work again, which to me indicates that this is a bug in
libleveldb1d.


Again, unclear wording on my part, sorry.  I didn't mean 
bumping source dependency versions, just the binary version, 
which rebuilding does.



Given this makes the daemon not launch, it probably merits a severity
bump.


Raising severity beyond "important" practically means "if this issue
isn't fixed then better to remove the package from the arcive" which
arguably doesn't make sense for bitcoin-qt (it works when only the right
library is available) but certainly makes sense if reassigned to
libleveldb1d (it is suspected that this issue affects other applications
too).

I have not had time to investigate closer if relevant to reassign, and
prefer for now to leave this open but at non-fatal severity, as it is
does not affect the 0.18.1~dfsg-1 release.


I suspect that, whatever is done to libleveldb, a rebuild of the 
bitcoin package will be required.



Help investigating closer would be much appreciated.


apt-rdepends --reverse libleveldb1d gives:

  Reverse Depends: bitcoin-qt (0.18.1~dfsg-1)
  Reverse Depends: bitcoind (0.18.1~dfsg-1)
  Reverse Depends: caffe-tools-cpu (1.0.0+git20180821.99bd997-2+b1)
  Reverse Depends: caffe-tools-cuda (1.0.0+git20180821.99bd997-4)
  Reverse Depends: ceph-base (12.2.11+dfsg1-2.1)
  Reverse Depends: ceph-mon (12.2.11+dfsg1-2.1)
  Reverse Depends: ceph-osd (12.2.11+dfsg1-2.1)
  Reverse Depends: ceph-test (12.2.11+dfsg1-2.1)
  Reverse Depends: groestlcoin-qt (2.17.2~dfsg-1)
  Reverse Depends: groestlcoind (2.17.2~dfsg-1)
  Reverse Depends: libcaffe-cpu1 (1.0.0+git20180821.99bd997-2+b1)
  Reverse Depends: libcaffe-cuda1 (1.0.0+git20180821.99bd997-4)
  Reverse Depends: libleveldb-dev (= 1.22-3)
  Reverse Depends: libleveldb1.2-cil (1.9.1-1.2)
  Reverse Depends: libleveldb1d-dbgsym (= 1.20-2.1)
  Reverse Depends: librime1 (1.4.0+dfsg1-2+b1)
  Reverse Depends: litecoin-qt (0.17.1-1)
  Reverse Depends: litecoind (0.17.1-1)
  Reverse Depends: minetest (5.0.1+repack-2)
  Reverse Depends: minetest-server (5.0.1+repack-2)
  Reverse Depends: node-leveldown (1.5.0+dfsg-3+b1)
  Reverse Depends: python-leveldb (0~svn68-3+b3)
  Reverse Depends: python3-leveldb (0~svn68-3+b3)
  Reverse Depends: stenographer (0.0~git20190528.0.6415e2b-1)

Presumably this bug needs to be reassigned to libleveldb, and once fixed 
there, bitcoin (and many other packages) will need to be rebuilt to 
depend on the new binary package that generates (liblevedb1e?).


Digging into the leveldb source and its differences between 1.20 and 
1.22, the "port" section of the library looks to have been completely 
rewritten, so I think the first step here is to reassign this to leveldb 
with a need for a soname bump since breaking changes were made to the 
ABI there.


--
-- Matt
"Reality is that which, when you stop believing in it, doesn't go away".
-- Philip K. Dick
GPG fingerprint: 0061 15DF D282 D4A9 57CE  77C5 16AF 1460 4A3C C4E9

Bug#935927: debian-science: migrate all python dependencies to their python3 variant

[Sandro Tosi]

Source: debian-science
Severity: important

Hello,
many of the packages on this set refer to python packages.  Theres an effort
on-going to remove Python 2 for Bullseye,
https://wiki.debian.org/Python/2Removal .

It would be great if you could migrate all the python dependencies here into
their python3 correspondent ones.

This will "free" packages from being reverse dependencies of debian-science deps
packages, hence they could ideally be removed (once we figure out the
remaining rdeps).

Given the high number of python deps from debian-science, it would be awesome if
you could tackle this sooner rather than later.

Let me know if i could help (ideally porting some of the deps to python3).

Regards,
Sandro

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

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

Bug#927731: epiphany-browser/i386: private libdazzle not loaded

[Carlos Alberto Lopez Perez]

On 28/04/2019 01:01, Simon McVittie wrote:
> Control: tags -1 + moreinfo
> 
> On Tue, 23 Apr 2019 at 02:46:53 +0800, 積丹尼 Dan Jacobson wrote:
>> SM> Does this perhaps depend on settings or something? If you create a new
>> SM> temporary user account, log in as the new user and run epiphany-browser,
>> SM> do you get the same warnings?
>>
>> Same on AMD64:
>>
>> $ su - some_vanilla_acct
>> $ DISPLAY=:0 epiphany
> ...
>> Error loading module 
>> '/usr/lib/x86_64-linux-gnu/epiphany-browser/web-extensions/libephywebextension.so':
>>  libdazzle-1.0.so.0: cannot open shared object file: No such file or 
>> directory
> 
> I haven't been able to reproduce this, but libephywebextension.so also
> doesn't appear in epiphany's /proc/$pid/maps for me.
> 


It doesn't appear inside the epiphany's pid map because
libephywebextension.so is a WebKitGTK WebProcess extension and not an
epiphany/UIProcess plugin.

It get's loaded in the WebKitWebProcess pid that epiphany executes.

And it only gets loaded if the linker is able to resolve all the symbols
(including libdazzle-1.0.so.0), otherwise the WebProcess skips loading it.

> Was some_vanilla_acct an entirely new user account with no prior
> configuration?
> 
> Do you have some sort of configuration, perhaps system-wide, that might
> cause epiphany-browser to load web extensions, where it doesn't for me?
> 
> Is there any feature that is observably not working as a result of
> libephywebextension.so not loading, or is the warning message the only
> symptom that you see?
> 

I can confirm this bug in last Debian sid (also in stable) and on AMD64.

if you simply do "apt install epiphany-browser" libdazzle-1.0-0 is not
installed.

The problem is not only the ugly warning on stderr, but that you miss
the new nice search bar at all. You can read about this here:

https://blogs.gnome.org/mcatanzaro/2019/03/27/epiphany-3-32-and-webkitgtk-2-24/

Installing libdazzle-1.0-0 fixes the problem and makes the new nice
address bar work.

You can check this yourself by installing/removing libdazzle-1.0-0 and
reopening epiphany and seeing the different address bar.

Please, declare a dependency on libdazzle for the epiphany-browser.

Thanks



signature.asc
Description: OpenPGP digital signature

Bug#935669: assaultcube-data: Outdated version makes assaultcube uninstallable

[Carlos Donizete Froes]

Hi Simon,

> Alternatively, if it's legally and technically OK to build assaultcube-data
> on buildds, a maintainer can mark it to be autobuilt and do source uploads:
> https://www.debian.org/doc/manuals/developers-reference/ch05.en.html#non-free-buildd

"XS-Autobuild: yes" is in debian/control[0] and commented in
debian/copyright[1].

[0] 
https://salsa.debian.org/games-team/assaultcube data/blob/master/debian/control

[1] 
https://salsa.debian.org/games-team/assaultcube-data/blob/master/debian/copyright

Thanks!

-- 
⢀⣴⠾⠻⢶⣦⠀ Carlos Donizete Froes [a.k.a coringao]
⣾⠁⢠⠒⠀⣿⡁ Debian Wiki: https://wiki.debian.org/coringao
⢿⡄⠘⠷⠚⠋⠀ GPG: 4096R/B638B780
⠈⠳⣄⠀⠀⠀  2157 630B D441 A775 BEFF  D35F FA63 ADA6 B638 B780


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

Bug#935926: RM: mauve -- unused java testsuite

[Matthias Klose]

Package: ftp.debian.org
Severity: normal

Please remove mauve -- unused java testsuite.

Bug#935925: RM: python-fontconfig

[Matthias Klose]

Package: ftp.debian.org
Severity: normal
User: debian-pyt...@lists.debian.org
Usertag: py2removal

Please remove python-fontconfig, apparently unused, and according to #895581, 
better alternatives exist.

Bug#935924: RM: gadfly -- Python2 only package

[Matthias Klose]

Package: ftp.debian.org
Severity: normal
User: debian-pyt...@lists.debian.org
Usertag: py2removal

Please remove gadfly, Python2 only package, low popcon, and no Python3 support. 
No reverse dependencies.

Bug#935923: libmodbus: FTBFS on hppa - unit-test-server: no process found

[John David Anglin]

Source: libmodbus
Version: 3.0.6-2
Severity: normal

Dear Maintainer,

See build log:
https://buildd.debian.org/status/fetch.php?pkg=libmodbus=hppa=3.1.6-1=1566917369=0

Test fails:
FAIL: ./unit-tests.sh
=

Starting server
Starting client
unit-test-server: no process found
FAIL unit-tests.sh (exit status: 255)

Regards,
Dave Anglin


-- System Information:
Debian Release: bullseye/sid
  APT prefers buildd-unstable
  APT policy: (500, 'buildd-unstable'), (500, 'unstable')
Architecture: hppa (parisc64)

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

Bug#912603: libsane1: discolored bar (genesys_gl847)

[Owen Heisler]

On 8/27/19 7:06 AM, Jörg Frings-Fürst wrote:
> I am working on the sane-backends version 1.28.0 together with my
> sponsor. 

That's great news, thanks for the update!

> But it will take some time, because I have to make a transition due to
> some fundamental changes.
Okay, I did notice some mention of that in the 1.0.28 changelog. Thanks
for working on it, and thanks for maintaining the SANE tools!

Owen



signature.asc
Description: OpenPGP digital signature

Bug#935917: suricata-update: cannot use suricata-update command

[Sascha Steinbiss]

Dear Aaron,

Thanks for bringing this to my attention.


> I just installed the suricata-update package from the Debian buster repo. 
> Before that, I used the github version which worked fine. 

I see.

> 
> The "suricata-update" command of the Debian package tries to execute a file 
> /usr/local/bin/suricata-update which doesn't exist (even the folder 
> /usr/local/bin doesn't exist).
> The right path should be /usr/bin/suricata-update (without local!).

Indeed the package installs suricata-update into that directory. I just tried a 
clean install on buster and all I get is exactly that file [1], which executes 
perfectly. The package never makes any reference to /usr/local/bin.

My first suspicion was that there might be a leftover script from your old 
GitHub install in your /usr/local/bin directory. /usr/local/bin is a typical 
install path for non-distribution installations, e.g. via pip/setup.py or the 
like, and comes before /usr/bin in the $PATH search dir.
However, as you are mentioning that the directory does not even exist at all, I 
am a bit puzzled.

Can you probably share the output of your ‘which suricata-update’ and the exact 
error message you get when trying to execute the command? Have you tried 
executing the command in a new shell or after doing a ‘hash -r’ (assuming you 
are using bash)? This could help find out where the problematic path comes from.

Cheers
Sascha

[1] https://packages.debian.org/buster/amd64/suricata-update/filelist

Bug#933754: buster-pu: package mariadb-10.3 10.3.17-0+deb9u1

[Otto Kekäläinen]

commit b7529cdcab61f416e3fc003e42c50153475f1bd1 (HEAD -> buster, origin/buster)
Author: Otto Kekäläinen 
Date:   Tue Aug 27 23:52:54 2019 +0200

Amend changelog to surely include all changes since 1:10.3.15-1

diff --git a/debian/changelog b/debian/changelog
index 80556fc88..c0dfdf308 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,6 +1,7 @@
 mariadb-10.3 (1:10.3.17-0+deb10u1) buster; urgency=high

-  * New upstream version 10.3.17. Includes security fixes for:
+  * SECURITY UPDATE: New upstream version 10.3.17. Includes fixes for the
+following security vulnerabilities:
 - CVE-2019-2737
 - CVE-2019-2739
 - CVE-2019-2740
@@ -11,8 +12,15 @@ mariadb-10.3 (1:10.3.17-0+deb10u1) buster; urgency=high
   * Multiple Gitlab-CI/Salsa-CI improvements
   * Update libmariadb3 symbols to match MariaDB Connector C 3.1 API
   * Add Lintian override for new test binary wsrep_check_version
-
- -- Otto Kekäläinen   Fri, 02 Aug 2019 19:46:11 +0100
+  * Make libzstd dependency versioned as RocksDB need at least 1.3.3
+  * Rename 'mariadbcheck' to 'mariadb-check' as upstream is doing in 10.4
+  * Improve cross building (Closes: #930314)
+- Perform a native build of import_executables first.
+- cross.patch: Fix missing include in cmake/systemd.cmake.
+- Build-Depends: libreadline-gplv2-dev:native for the native pass.
+- Forward IMPORT_EXECUTABLES to the cross build pass.
+
+ -- Otto Kekäläinen   Tue, 27 Aug 2019 23:42:59 +0200

Bug#935914: kinit: Signal: Segmentation fault (11) after rebooting

[Nicholas D Steeves]

I'm still not sure how to reliably reproduce this bug, but the
kdeinit5 crashes have continued to occur every ~30min today (within a
single session).

The memory usage spike I mentioned in a previous message seems to be
caused by baloosearch.so ... which didn't have this issue in stretch.
The backtrace seems to support a possible baloo<->kdeinit5
malinteraction.

P.S. I'm blacklisting most directories, because Baloo has always
choked when fed too much data.


signature.asc
Description: PGP signature

Bug#935809: fdroidserver 1.1.4-1~deb10u1 flagged for acceptance

[Adam D Barratt]

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

Hi,

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

Thanks for your contribution!

Upload details
==

Package: fdroidserver
Version: 1.1.4-1~deb10u1

Explanation: new upstream release

Bug#935308: android-sdk-meta 25.0.0+11~deb10u1 flagged for acceptance

[Adam D Barratt]

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

Hi,

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

Thanks for your contribution!

Upload details
==

Package: android-sdk-meta
Version: 25.0.0+11~deb10u1

Explanation: new upstream release

Bug#935770: ncbi-tools6 6.1.20170106+dfsg1-0+deb10u2 flagged for acceptance

[Adam D Barratt]

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

Hi,

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

Thanks for your contribution!

Upload details
==

Package: ncbi-tools6
Version: 6.1.20170106+dfsg1-0+deb10u2

Explanation: fix test-suite to handle UniVec removal

Bug#935465: jython 2.7.1+repack1-4~deb10u1 flagged for acceptance

[Adam D Barratt]

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

Hi,

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

Thanks for your contribution!

Upload details
==

Package: jython
Version: 2.7.1+repack1-4~deb10u1

Explanation: preserve backward compatibility with Java 7

Bug#932460: vlc: UPNP does not work in VLC

[Sebastian Ramacher]

Control: reassign -1 libupnp13 1:1.8.4-2
Control: forcemerge 935709 -1
Control: forwarded 935709 https://github.com/mrjimenez/pupnp/issues/91
Control: tags 935709 upstream fixed-upstream

Hi

On 2019-07-19 18:52:05, Sebastien CHAVAUX wrote:
> Package: vlc
> Version: 3.0.7-1
> Severity: normal
> 
> Dear Maintainer,
> 
> 
> 
> Since upgrading to Debian 10, Windows does not see my Upnp network. I can no
> longer play videos and other multimedia files that are made available from my
> many Dlna servers.
> 
> On my PC under Debian 10, I have a Minidlna server visible from all over the
> house on all my devices (TV, dlna player, PC with Debian 9 via Vlc, ...) and I
> also have a Dlna multimedia server, but I do not see anything on my Debian PC
> 10 with Vlc.
> 
> When I run via a terminal it gives me this:
> 
> $ vlc
> VLC media player 3.0.7 Vetinari (revision 3.0.7-0-g86cee31099)
> [55fc26d82570] main libvlc: Launching vlc with the default interface. Use
> "cvlc" to start VLC without an interface.
> [55fc26d864a0] main playlist: playlist is empty
> [7fbf7c4aaf20] upnp discovery services: Initializing libupnp on 'default'
> interface
> [7fbf7c4aaf20] upnp services discovery error: Initialization failed:
> UPNP_E_SOCKET_BIND
> [7fbf7c4aaf20] main service error discovery: no suitable services 
> discovery
> module
> [7fbf7c4aaf20] upnp discovery services: Initializing libupnp on 'default'
> interface
> [7fbf7c4aaf20] upnp services discovery error: Initialization failed:
> UPNP_E_SOCKET_BIND
> [7fbf7c4aaf20] main service error discovery: no suitable services 
> discovery
> module
> QObject :: ~ QObject: Timers can not be stopped from another thread

This issue looks like it could be caused by #935709 in pupnp-1.8.
Reassigning and merging.

Cheers

> 
> It looks like the bug I sent a few months ago at openSUSE for the same thing:
> https://bugzilla.opensuse.org/show_bug.cgi?id=1132829
> 
> If I use the Vlc flatpack it works and I can see the Dlna servers.
> 
> If you need more information, I will do my best to give it.
> 
> Sincerely, seb.
> 
> 
> 
> -- System Information:
> Debian Release: 10.0
>   APT prefers stable
>   APT policy: (500, 'stable')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores)
> Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE= 
> (charmap=UTF-8)
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> Versions of packages vlc depends on:
> ii  vlc-bin  3.0.7-1
> ii  vlc-plugin-base  3.0.7-1
> ii  vlc-plugin-qt3.0.7-1
> ii  vlc-plugin-video-output  3.0.7-1
> 
> Versions of packages vlc recommends:
> ii  vlc-l10n   3.0.7-1
> ii  vlc-plugin-notify  3.0.7-1
> ii  vlc-plugin-samba   3.0.7-1
> ii  vlc-plugin-skins2  3.0.7-1
> ii  vlc-plugin-video-splitter  3.0.7-1
> ii  vlc-plugin-visualization   3.0.7-1
> 
> vlc suggests no packages.
> 
> Versions of packages libvlc-bin depends on:
> ii  libc62.28-10
> ii  libvlc5  3.0.7-1
> 
> Versions of packages libvlc5 depends on:
> ii  libc62.28-10
> ii  libvlccore9  3.0.7-1
> 
> Versions of packages libvlc5 recommends:
> ii  libvlc-bin  3.0.7-1
> 
> Versions of packages vlc-bin depends on:
> ii  libc6   2.28-10
> ii  libvlc-bin  3.0.7-1
> ii  libvlc5 3.0.7-1
> 
> Versions of packages vlc-plugin-base depends on:
> ii  liba52-0.7.4 0.7.4-19
> ii  libaom0  1.0.0-3
> ii  libarchive13 3.3.3-4
> ii  libaribb24-0 1.0.3-2
> ii  libasound2   1.1.8-1
> ii  libass9  1:0.14.0-2
> ii  libavahi-client3 0.7-4+b1
> ii  libavahi-common3 0.7-4+b1
> ii  libavc1394-0 0.5.4-5
> ii  libavcodec58 7:4.1.3-1
> ii  libavformat587:4.1.3-1
> ii  libavutil56  7:4.1.3-1
> ii  libbasicusageenvironment12018.11.26-1.1
> ii  libbluray2   1:1.1.0-1
> ii  libc62.28-10
> ii  libcairo21.16.0-4
> ii  libcddb2 1.3.2-6
> ii  libchromaprint1  1.4.3-3
> ii  libcrystalhd31:0.0~git20110715.fdd2f19-13
> ii  libdbus-1-3  1.12.16-1
> ii  libdc1394-22 2.2.5-1
> ii  libdca0  0.0.6-1
> ii  libdvbpsi10  1.3.2-1
> ii  libdvdnav4   6.0.0-1
> ii  libdvdread4  6.0.1-1
> ii  libebml4v5   1.3.6-2
> ii  libfaad2 2.8.8-3
> ii  libflac8 1.3.2-3
> ii  libfontconfig1

Bug#532815: latex-beamer: Please include the "beamerthemeprogressbar"

[Hilmar Preuße]

On 12.06.09 00:20, Alexander Reichle-Schmehl wrote:

Hi Alexander,

> There's a nice theme for Latex beamer.  Main advantage of that theme is, that
> it has a progress bar showing how far your progressed in your talk.
>
> It's available from
> http://www.cert.fr/dcsd/THESES/sbouveret/francais/LaTeX.html and licensend
> under the terms of the GPL-2.  I think it would be worth to be added in 
> Debian,
> but don't think it warrants a package for itself, since it's archive is just
> 5kb.  So, maybe you could add it to the latex-beamer main package?
>
The old URL is dead, I guess it is now [1]. I didn't find the package on
CTAN. Please tell the author he should upload to CTAN, so it will make
its way into TeX Live.

Hilmar

[1] https://github.com/cedricmauclair/beamer-progressbar
--
sigfault
#206401 http://counter.li.org




signature.asc
Description: OpenPGP digital signature

Bug#928176: vlc: BOBOOvlc cannot play cd audio without net connection and crash

[Sebastian Ramacher]

Control: tags -1 + moreinfo

Hi

On 2019-04-29 15:18:19, Serge Pouliquen wrote:
> Package: src:vlc
> Version: 3.0.6-0+deb9u1
> Severity: normal
> 
> Dear Maintainer,
> 
> 
>* What led up to the situation?
> remove wire cable from ethernet
> play cd audio with vlc
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
> with net connection, vlc can play cd audio and display title from cddb 
> protocol
>* What was the outcome of this action?
> fix network connection
>* What outcome did you expect instead?
> to be able to play cd audio without internet connection

Sorry for the delay. If this issue is still reproducible with 3.0.8,
please install the -dbgsym packages and provide a backtrace (including
the vlc -vvv log). Additionally, please report the issue on upstream's
bug tracker (https://trac.videolan.org/vlc/) and let us know the bug
number.

Cheers

> 
> 
> -- System Information:
> Debian Release: 9.9
>   APT prefers stable-updates
>   APT policy: (700, 'stable-updates'), (700, 'stable'), (80, 'testing'), (58, 
> 'unstable'), (55, 'experimental')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 4.9.0-9-amd64 (SMP w/4 CPU cores)
> Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8), 
> LANGUAGE=en_GB:en (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> 
> Versions of packages vlc depends on:
> ii  dpkg 1.18.25
> ii  vlc-bin  3.0.6-0+deb9u1
> ii  vlc-l10n 3.0.6-0+deb9u1
> ii  vlc-plugin-base  3.0.6-0+deb9u1
> ii  vlc-plugin-qt3.0.6-0+deb9u1
> ii  vlc-plugin-video-output  3.0.6-0+deb9u1
> 
> Versions of packages vlc recommends:
> ii  vlc-plugin-notify  3.0.6-0+deb9u1
> ii  vlc-plugin-samba   3.0.6-0+deb9u1
> ii  vlc-plugin-skins2  3.0.6-0+deb9u1
> ii  vlc-plugin-video-splitter  3.0.6-0+deb9u1
> ii  vlc-plugin-visualization   3.0.6-0+deb9u1
> 
> vlc suggests no packages.
> 
> Versions of packages libvlc-bin depends on:
> ii  libc62.24-11+deb9u4
> ii  libvlc5  3.0.6-0+deb9u1
> 
> Versions of packages libvlc5 depends on:
> ii  dpkg 1.18.25
> ii  libc62.24-11+deb9u4
> ii  libvlccore9  3.0.6-0+deb9u1
> 
> Versions of packages libvlc5 recommends:
> ii  libvlc-bin  3.0.6-0+deb9u1
> 
> Versions of packages vlc-bin depends on:
> ii  libc6   2.24-11+deb9u4
> ii  libvlc-bin  3.0.6-0+deb9u1
> ii  libvlc5 3.0.6-0+deb9u1
> 
> Versions of packages vlc-plugin-base depends on:
> ii  dpkg 1.18.25
> ii  liba52-0.7.4 0.7.4-19
> ii  libarchive13 3.2.2-2+deb9u1
> ii  libasound2   1.1.3-5
> ii  libass5  1:0.13.4-2
> ii  libavahi-client3 0.6.32-2
> ii  libavahi-common3 0.6.32-2
> ii  libavc1394-0 0.5.4-4+b1
> ii  libavcodec57 7:3.2.12-1~deb9u1
> ii  libavformat577:3.2.12-1~deb9u1
> ii  libavutil55  7:3.2.12-1~deb9u1
> ii  libbasicusageenvironment12016.11.28-1+deb9u2
> ii  libbluray1   1:0.9.3-3
> ii  libc62.24-11+deb9u4
> ii  libcairo21.14.8-1
> ii  libcddb2 1.3.2-5
> ii  libchromaprint1  1.4.2-1
> ii  libcrystalhd31:0.0~git20110715.fdd2f19-12
> ii  libdbus-1-3  1.10.26-0+deb9u1
> ii  libdc1394-22 2.2.5-1
> ii  libdca0  0.0.5-10
> ii  libdvbpsi10  1.3.0-5
> ii  libdvdnav4   5.0.3-3
> ii  libdvdread4  5.0.3-2
> ii  libebml4v5   1.3.4-1
> ii  libfaad2 2.8.0~cvs20161113-1+deb9u1
> ii  libflac8 1.3.2-1
> ii  libfontconfig1   2.11.0-6.7+b1
> ii  libfreetype6 2.6.3-3.2
> ii  libfribidi0  0.19.7-1+b1
> ii  libgcc1  1:6.3.0-18+deb9u1
> ii  libgcrypt20  1.7.6-2+deb9u3
> ii  libglib2.0-0 2.50.3-2
> ii  libgnutls30  3.5.8-5+deb9u4
> ii  libgpg-error01.26-2
> ii  libgroupsock82016.11.28-1+deb9u2
> ii  libharfbuzz0b1.4.2-1
> ii  libjpeg62-turbo  1:1.5.1-2
> ii  libkate1 0.4.1-7+b1
> ii  liblirc-client0  0.9.4c-9
> ii  liblivemedia57   2016.11.28-1+deb9u2
> ii  liblua5.2-0  5.2.4-1.1+b2
> ii  libmad0  0.15.1b-8+deb9u1
> ii  libmatroska6v5   1.4.5-2
> ii  libmicrodns0 

Bug#935913: gle-graphics: qgle segfaults when modifying text strings

[Francesco Poli]

On Tue, 27 Aug 2019 21:56:23 +0200 Christian T. Steigies wrote:

[...]
> On Tue, Aug 27, 2019 at 07:15:24PM +0200, Francesco Poli (wintermute) wrote:
> > Package: gle-graphics
> > Version: 4.2.5-7+b1
> > Severity: normal
> > 
> > Hello again!
> > 
> > I found a reproducible segfault in gle-graphics:
> 
> Thanks for your bug reports,

You're welcome!   :-)

> these issues are already being discussed on the
> gle users list.

That's good to know.

> The main issue is that qgle needs to be ported to qt5, or
> (temporarily?) dropped from the package, otherwise the whole package will
> not be in bullseye.

I am aware of this issue: the package is risking an autoremoval from
testing (currently scheduled for September, the 2nd, according to the
[tracker page]) and, possibly, a removal from unstable (like other
packages not ported to Qt5)...

[tracker page]: 

> Laurence already sent me some patches, I will try to
> get this into a package.

That's a relief...

> 
> >   0) start the GUI
> > 
> >  $ qgle
> 
> You know that you can run gle on the command line?

Sure, but I am searching for a tool capable of satisfying a number of
(potentially conflicting) needs.


It has to be able to produce high-quality (vector graphics) plots,
diagrams, and sketches, in both 2D and 3D forms.
gle-graphics seems to qualify (at least judging by the example gallery).

It has to be usable in a non-interactive manner, with a language that's
simple to write, yet expressive. And which avoids too much boilerplate.
This is useful when you want to generate a great number of similarly
looking plots (for instance by feeding different data to be plotted
with the same visual look...).
gle-graphics seems to qualify (at least judging by a quick look at the
documentation).

But it has also to be usable in an interactive manner, with a GUI.
which, in its turn, must be able to read and write the non-interactive
language.
This is useful when you want to quickly construct a sketch or diagram,
or even a plot, to play with in a WYSIWYG way. But you also want to be
ready to turn what you interactively prepared into a non-interactive
script, because your quick need to plot something has evolved into a
more systematic need to generate a great number of similar plots (see
the previous example).
gle-graphics seems to be less than optimal on this front, since the GUI
looks a bit minimalist (do I understand correctly that only a subset of
the features are accessible through the GUI?) and prone to crashes. 


I hope all this makes sense...


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


pgpwAlTkgkl5J.pgp
Description: PGP signature

Bug#914641: faad2: CVE-2018-19502 CVE-2018-19503 CVE-2018-19504 CVE-2019-6956

[Fabian Greffrath]

Am Dienstag, den 27.08.2019, 13:49 -0400 schrieb Hugo Lefeuvre:
> Please let me know if you want me to change anything, otherwise I am
> waiting for your ack to upload.

Please go ahead!

Is the list of closed CVEs complete?

Thank you!

 - Fabian



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

Bug#935386: buster-pu: package raspi3-firmware/1.20190215-1+deb10u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Thu, 2019-08-22 at 09:51 +0200, Cyril Brulebois wrote:
> I'd like to request a raspi3-firmware update in buster to add some
> hardware support. The buster kernel already had all required code to
> handle Raspberry Pi CM 3 in addition to the regular Raspberry Pi 3
> but
> the former needs:
>  - an updated linux kernel which ships an extra DTB;
>  - an updated raspi3-firmware that deploys the extra DTB under
>/boot/firmware.
> 

Please go ahead.

Regards,

Adam

Bug#935918: cups: can't read hpcups PPDs

[Till Kamppeter]

This is caused by changes in CUPS 2.2.12. I have already reported an 
appropriate issue on CUPS upstream:


https://github.com/apple/cups/issues/5639

   Till

Bug#711135: CLOUD COMPUTING 2020 || Invitation for committee membership || April 26 - 30, 2020 - Nice, France

[IARIA Committees]

Invitation:

We are in the process of re-inviting the program committee members and inviting 
new members for CLOUD COMPUTING 2020, The Eleventh International Conference on 
Cloud Computing, GRIDs, and Virtualization

We would greatly appreciate you accept our invitation to join the CLOUD 
COMPUTING 2020 committee.

CLOUD COMPUTING 2020 is scheduled to be April 26 - 30, 2020 in Nice, France 
under the ComputationWorld 2020 umbrella;

see   http://www.iaria.org/conferences2020/CLOUDCOMPUTING20.html

for photos from CLOUD COMPUTING 2019, see 
http://www.iaria.org/conferences2019/PhotosCLOUDCOMPUTING19.html


The Board and Chairs count on program committee members to:

- submit papers and/or encourage their teams/entourage to contribute;

- help review 1-2 papers;

- disseminate the Call for Papers, frequently emailed by the logistics;

- recommend new program committee members, and

- suggest topics to update the Call for Papers


Please reply to the invitation to t...@iaria.org with your most up to date 
affiliation and a few topics of interest; we would like to post the committee 
as soon as possible and start distributing the Call for Papers. Make sure to 
include your topics of interest so as to facilitate the reviewing assignments.

-- 


On behalf of the IARIA Board:

Claus-Peter Rueckemann, Leibniz Universitaet Hannover/ WWU Muenster / 
North-German Supercomputing Alliance (HLRN), Germany

Pascal Lorenz, University of Haute-Alsace, France

-- 

=  details   



CLOUD COMPUTING 2020 Tracks (topics and submission details: see CfP on the site)

TRENDS: New trends

Fog-computing; Mobile Edge Computing; Cloudlets; Hosted Cloud services (WebRTC, 
Containers, Cloud micro-services); Cloud computing and SDN/NFV; Cloud computing 
and 5G; Cloud computing and LTE Pro 4.5; Cloud computing ad Big Data; High 
performance computing (HPC) in the Cloud; Superfluid Clouds; Mobile Apps to the 
public Clouds; Vehicular Cloud networks; Cloud orchestration features; 
Converged edge systems; Cloud federation; Micro-cloud provider federation; 
Open-implementation Cloud infrastructures; Untrusted Cloud environments; 
Multiple Clouds and data centers; Power Constrained VMs; Cloud Green 
abstraction layer

CLOUD: Cloud computing

Cloud economics; Core cloud services; Cloud technologies; Cloud computing; 
On-demand computing models; Hardware-as-a-service; Software-as-a-service [SaaS 
applications]; Platform-as-service; Storage as a service in cloud; 
Data-as-a-Service; Service-oriented architecture (SOA); Cloud computing 
programming and application development; Scalability, discovery of services and 
data in Cloud computing infrastructures; Trust and clouds; Client-cloud 
computing challenges; Geographical constraints for deploying clouds

CLOUD: Challenging features

Privacy, security, ownership and reliability issues; Performance and QoS; 
Dynamic resource provisioning; Power-efficiency and Cloud computing; Load 
balancing; Application streaming; Cloud SLAs; Business models and pricing 
policies; Cloud service subscription models; Cloud standardized SLA; 
Cloud-related privacy; Cloud-related control; Managing applications in the 
clouds; Mobile clouds; Roaming services in Clouds; Agent-based cloud computing; 
Cloud brokering; Cloud contracts (machine readable); Cloud security; Security 
and assurance properties in cloud environments; Big Data Analytics in clouds; 
Cloud computing back-end solutions; Cloud applications portability; 
Cloud-native application design; Security by design for cloud services; Data 
privacy guarantee at run-time

CLOUD: Platforms, Infrastructures and Applications

Custom platforms; Large-scale compute infrastructures; Data centers; Processes 
intra- and inter-clouds; Content and service distribution in Cloud computing 
infrastructures; Multiple applications can run on one computer (virtualization 
a la VMWare); Grid computing (multiple computers can be used to run one 
application); Cloud-computing vendor governance and regulatory compliance; 
Enterprise clouds; Enterprise-centric cloud computing; Interaction between 
vertical clouds; Public, Private, and Hybrid clouds; Cloud computing testbeds

GRID: Grid networks, services and applications

GRID theory, frameworks, methodologies, architecture, ontology; GRID 
infrastructure and technologies; GRID middleware; GRID protocols and 
networking; GRID computing, utility computing, autonomic computing, 
metacomputing; Programmable GRID; Data GRID; Context ontology and management in 
GRIDs; Distributed decisions in GRID networks; GRID services and applications; 
Virtualization, modeling, and metadata in GRID; Resource management, 
scheduling, and scalability in GRID; GRID monitoring, control, and management; 
Traffic and load balancing in GRID; User profiles and priorities in GRID; 
Performance and security in GRID systems; Fault tolerance, resilience, 
survivability, robustness in 

Bug#935888: buster-pu: package osinfo-db/0.20181120-1+deb10u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Tue, 2019-08-27 at 12:05 +0200, Laurent Bigonville wrote:
> The current version of osinfo-db in Buster is not supporting buster
> itself which is quite annoying (see #919486 and #935551). In addition
> to that, the download links for the stretch iso are no longer valid.
> 

Please go ahead; thanks.

Regards,

Adam

Bug#935098: nmap 7.80: random segfaults while scanning

[Lucas Nussbaum]

On 19/08/19 at 12:41 +, Stefan Pietsch wrote:
> Package: nmap
> Version: 7.80+dfsg1-1
> Severity: normal
> 
> 
> nmap randomly stops while doing a scan.
> Starting program: /usr/bin/nmap -vv --stats-every=60s -Pn -sV -O -sS 
> -p1-65535 -oA report [IP address]

I see this as well, and can reproduce with:
i=0 ; while nmap --min-rtt-timeout 300ms -sV -p 22 bitbucket.org; do echo $i ; 
i=$(($i+1)); done

Maybe due to the combination of -sV and something that deals with time?

Lucas

Bug#935922: Uploading a Video to YouTube returns "the Server has Rejected the File"

[mason1920]

Package: epiphany-browser
Version: 3.32.1.2-2
Severity: normal

Dear Maintainer,

I have done multiple test with multiple files, all uploaded to YouTube using 
Firefox and Epiphany.

Every time I upload with Firefox, the server accepts the file and allows me to 
publish it.
But when I use Epiphany, I get the error "the server has rejected the file" 
when the video has been 100% uploaded.

I'd like to break my dependency on multiple browsers, but I can't do so if my 
workflow requires Firefox but I prefer Epiphany. If Epiphany could upload to 
YouTube, this problem would be solved.

Bug#929257: stretch-pu: package mariadb-10.1 10.1.41-0+deb9u

[Adam D. Barratt]

Control: tags -1 + confirmed

On Tue, 2019-08-27 at 19:53 +0200, Otto Kekäläinen wrote:
> Control: tags -1 -moreinfo
> 
> Hello!
> 
> Refreshed debdiff attached. Created with commands:
> git diff --stat debian/10.1.38-0+deb9u1..stretch | xz >
> debian-10.1.40-0+deb9u1.debdiff.stat.xz
> git diff debian/10.1.38-0+deb9u1..stretch | xz >
> debian-10.1.40-0+deb9u1.debdiff.xz
> 
> I will do the final git tag and upload source when given permission
> to do so.
> 

Please go ahead with this one.

Regards,

Adam

Bug#935921: libpam-cap doesn't work with sudo because PAM_REINITIALIZE_CRED is ignored

[Daniel Gröber]

Package: libpam-cap
Version: 1:2.25-2dxld1
Severity: important
Tags: patch upstream

Dear Maintainer,

libpam-cap is currently incompatible with the way 'sudo' handles
`pam_setcred`. If you look at the sudo source code in
`sudo_pam_begin_session` at plugins/sudoers/auth/pam.c:340:

if (def_pam_setcred) {
rc = pam_setcred(pamh, PAM_REINITIALIZE_CRED);
[...]

This is the only PAM_*INITIALIZE_CRED call in sudo. I did some digging
through the commit log and it seems some other platforms handle
PAM_INITIALIZE_CRED wrong and that's why sudo does things this way.
According to the (sparse) documentation on PAM I could find this
should work.

However libpam-cap has this in it's `pam_sm_setcred`
pam_cap/pam_cap.c:289:

if (!(flags & PAM_ESTABLISH_CRED)) {
return PAM_IGNORE;
}

which will skip the call to `set_capabilities` when sudo passes
PAM_REINITIALIZE_CRED. This prevents the code from applying the
capabilities from the config file as expected.

Since sudo only ever passes PAM_REINITIALIZE_CRED this obviously can't
work.

The fix is simple, just change the first line to

if (!(flags & (PAM_ESTABLISH_CRED | PAM_REINITIALIZE_CRED)))

I have been using a version of libpam-cap with the attached patch
applied for a while now and everything seems to work.

I also tried submitting this patch upstream with Andrew G. Morgan but
I think my either my mails aren't getting through and I couldn't find
a mailinglist or anything else so it's time to at least get this fixed
in Debian at least.

Thanks,
Daniel

-- System Information:
Debian Release: 10.0
  APT prefers stable
  APT policy: (990, 'stable')
Architecture: amd64 (x86_64)

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

Versions of packages libpam-cap depends on:
ii  libc6   2.28-10
ii  libcap2 1:2.25-2
ii  libpam-runtime  1.3.1-5
ii  libpam0g1.3.1-5

libpam-cap recommends no packages.

libpam-cap suggests no packages.

-- Configuration Files:
/etc/security/capability.conf changed [not included]

-- no debconf information
>From 7fe7190ae8f6944f54bc0dce628fec5804ca7724 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Daniel=20Gr=C3=B6ber?= 
Date: Fri, 12 Apr 2019 22:47:38 +0200
Subject: [PATCH resend] Fix pam_cap ignoring PAM_REINITIALIZE_CRED

Some applications, such as sudo, only ever call pam_setcap() with
PAM_REINITIALIZE_CRED and expect this to have the same effect as
PAM_ESTABLISH_CRED on the first call.

Currently pam_cap simply ignores such calls causing inheritable capabilities
configured in it's config file not to be set when using such applications.
---
 pam_cap/pam_cap.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/pam_cap/pam_cap.c b/pam_cap/pam_cap.c
index b1cc5cb..9813e71 100644
--- a/pam_cap/pam_cap.c
+++ b/pam_cap/pam_cap.c
@@ -286,7 +286,7 @@ int pam_sm_setcred(pam_handle_t *pamh, int flags,
 int retval;
 struct pam_cap_s pcs;
 
-if (!(flags & PAM_ESTABLISH_CRED)) {
+if (!(flags & (PAM_ESTABLISH_CRED | PAM_REINITIALIZE_CRED))) {
D(("we don't handle much in the way of credentials"));
return PAM_IGNORE;
 }
-- 
2.20.1

Bug#935913: gle-graphics: qgle segfaults when modifying text strings

[Christian T. Steigies]

Hi,
On Tue, Aug 27, 2019 at 07:15:24PM +0200, Francesco Poli (wintermute) wrote:
> Package: gle-graphics
> Version: 4.2.5-7+b1
> Severity: normal
> 
> Hello again!
> 
> I found a reproducible segfault in gle-graphics:

Thanks for your bug reports, these issues are already being discussed on the
gle users list.  The main issue is that qgle needs to be ported to qt5, or
(temporarily?) dropped from the package, otherwise the whole package will
not be in bullseye.  Laurence already sent me some patches, I will try to
get this into a package.

>   0) start the GUI
> 
>  $ qgle

You know that you can run gle on the command line? I rarely use qgle, for me
it defeats the purpose of "programming" graphics, but I can understand that
new users look at this first. If you want to learn gle, however, I suggest
that you have a look a gle and the examples in the manual or on the website.

Christian

Bug#933754: buster-pu: package mariadb-10.3 10.3.17-0+deb9u1

[Adam D. Barratt]

On Tue, 2019-08-27 at 20:02 +0200, Otto Kekäläinen wrote:
> Refreshed debdiff attached. Created with commands:
> git diff --stat debian/1%10.3.15-1..buster | xz > debian-1%10.3.17-
> 0+deb10u1.debdiff.stat.xz
> git diff debian/1%10.3.15-1..buster | xz > debian-1%10.3.17-
> 0+deb10u1.debdiff.xz
> 
> I will do the final git tag and upload source when given permission
> to do so.
> 

-- a/debian/control
+++ b/debian/control
@@ -24,10 +24,11 @@ Build-Depends: bison,
libpam0g-dev,
libpcre3-dev (>= 2:8.35-3.2~),
libreadline-gplv2-dev,
+   libreadline-gplv2-dev:native,
libsnappy-dev,
libsystemd-dev [linux-any],
libxml2-dev,
-   libzstd-dev,
+   libzstd-dev (>= 1.3.3),

What's the rationale for those changes? Neither of them seem to be
mentioned in the changelog.

Regards,

Adam

Bug#935887: python3-mapproxy: Change default template_dir and fix capabilities for Python >= 3.6.7

[Marek Lukács]

Hi Bas,

at the moment I do not have good sandbox for playing with packaging. But I
have checked the source package of mapproxy_1.11.0-3 (Debian Buster apt).

As I have not tested it and I just read it and checked on my filesystem I
get feeling, that something is going wrong during packaging. Looks like the
debain/rules do some tweaks, move files and create symlinks and uses
../python3.7/... names. Than probably something (or task of dh) renames
.../python3.7/... to .../python3/...

I am not good in package maintenance and do not know the correct sequence
it executes during packaging.

I have the possible explanation, what happens:

For me it looks like, it moves /templates/ from
/usr/lib/python3.7/dist-packages into /usr/share/python3-mapproxy and
creates broken link in /usr/lib/python3.7/dist-packages pointing to
(system) /usr/lib/python3.7/dist-packages (I expect that the file is
missing on building machine, so it is broken link). Later dh (or whatever
it is) task which corrects it, it ignores broken links so it will not fix
it, and those broken links remains and for example on my system I see those
links really in /usr/lib/python3.7/dist-packages/mapproxy/...

But as I noticed, I have not tested it, and I do not fully understand to
packaging sequences and tools, so it is only my feeling.

Why I get this feeling:

Check mapproxy-1.11.0/debian/rules, block override_dh_auto_install and
inside this block to following part:

for V in `py3versions -v -s`; do \
for F in DejaVuSans.ttf DejaVuSansMono.ttf; do \
$(RM)
debian/python3-$(PYBUILD_NAME)/usr/lib/python$$V/dist-packages/mapproxy/image/fonts/$$F
; \
ln -s /usr/share/fonts/truetype/dejavu/$$F \

debian/python3-$(PYBUILD_NAME)/usr/lib/python$$V/dist-packages/mapproxy/image/fonts/$$F
; \
done ; \
if [ ! -e
debian/python3-$(PYBUILD_NAME)/usr/share/python3-$(PYBUILD_NAME)/service/templates
]; then \
mkdir -p
debian/python3-$(PYBUILD_NAME)/usr/share/python3-$(PYBUILD_NAME)/service ; \
mv
debian/python3-$(PYBUILD_NAME)/usr/lib/python$$V/dist-packages/mapproxy/service/templates
\

 debian/python3-$(PYBUILD_NAME)/usr/share/python3-$(PYBUILD_NAME)/service/
; \
else \
$(RM) -r
debian/python3-$(PYBUILD_NAME)/usr/lib/python$$V/dist-packages/mapproxy/service/templates
; \
fi ; \
ln -s /usr/share/python3-$(PYBUILD_NAME)/service/templates \

debian/python3-$(PYBUILD_NAME)/usr/lib/python$$V/dist-packages/mapproxy/service/templates
; \
if [ ! -e
debian/python3-$(PYBUILD_NAME)/usr/share/python3-$(PYBUILD_NAME)/test/schemas
]; then \
mkdir -p
debian/python3-$(PYBUILD_NAME)/usr/share/python3-$(PYBUILD_NAME)/test ; \
mv
debian/python3-$(PYBUILD_NAME)/usr/lib/python$$V/dist-packages/mapproxy/test/schemas
\

 debian/python3-$(PYBUILD_NAME)/usr/share/python3-$(PYBUILD_NAME)/test/ ; \
else \
$(RM) -r
debian/python3-$(PYBUILD_NAME)/usr/lib/python$$V/dist-packages/mapproxy/test/schemas
; \
fi ; \
ln -s /usr/share/python3-$(PYBUILD_NAME)/test/schemas \

debian/python3-$(PYBUILD_NAME)/usr/lib/python$$V/dist-packages/mapproxy/test/schemas
; \
if [ ! -e
debian/python3-$(PYBUILD_NAME)/usr/share/python3-$(PYBUILD_NAME)/test/system/fixture/cache_data
]; then \
mkdir -p
debian/python3-$(PYBUILD_NAME)/usr/share/python3-$(PYBUILD_NAME)/test/system/fixture
; \
mv
debian/python3-$(PYBUILD_NAME)/usr/lib/python$$V/dist-packages/mapproxy/test/system/fixture/cache_data
\

 
debian/python3-$(PYBUILD_NAME)/usr/share/python3-$(PYBUILD_NAME)/test/system/fixture/
; \
else \
$(RM) -r
debian/python3-$(PYBUILD_NAME)/usr/lib/python$$V/dist-packages/mapproxy/test/system/fixture/cache_data
; \
fi ; \
ln -s
/usr/share/python3-$(PYBUILD_NAME)/test/system/fixture/cache_data \

debian/python3-$(PYBUILD_NAME)/usr/lib/python$$V/dist-packages/mapproxy/test/system/fixture/cache_data
; \
done

For me it looks like it move templates from
debian/python3-$(PYBUILD_NAME)/usr/lib/python$$V/dist-packages/mapproxy/service/templates
into
debian/python3-$(PYBUILD_NAME)/usr/share/python3-$(PYBUILD_NAME)/service/templates,
but it creates symlink
debian/python3-$(PYBUILD_NAME)/usr/lib/python$$V/dist-packages/mapproxy/service/templates
pointing to system path
/usr/share/python3-$(PYBUILD_NAME)/service/templates instead expected
debian/usr/share/python3-$(PYBUILD_NAME)/service/templates, so debian is
missing at the beginning ($(PYBUILD_NAME)=mapproxy, $$V=3.7 (result of
py3versions -v -s)).

During build time it creates broken symlink, as system path
/usr/share/python3-$(PYBUILD_NAME)/service/templates does not exists at the
build 

Bug#935846: musescore-snapshot: please make the build reproducible

[Chris Lamb]

Hi Thorsten,

> >Huh, it appeared to work for me so I wonder what was wrong with my
> >testcase. Anyway, I defer to thee. :)
> 
> oh, interesting… I’ve been told that cmake has a tar builtin,
> which doesn’t do these options…

Ahh, I see:

  
http://manpages.ubuntu.com/manpages/xenial/man1/cmake.1.html#command-line%20tool%20mode

> perhaps it calls out to the system-wide tar if one exists

Seems unlikely, alas. :(


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org  chris-lamb.co.uk
   `-

Bug#935920: Upgrade from stretch to buster removes /etc/network/if-up.d/

[Pascal Mainini]

Package: openssh-server
Version: 1:7.9p1-10

After upgrading from stretch to buster, I noticed that the DHCP client
(isc-dhcp-client, 4.4.1-2) exits after initially assigning an IP
address. Further investigation showed, that "ifup@ens3.service" exited
abnormally. The reason for this seems to be that the directory
"/etc/network/if-up.d" is missing.
As I keep my /etc under git control (using etckeeper), I was able to
identify the removal of of "/etc/network/if-up.d/openssh-server" as the
last action taking place which at least involved files in the if-up.d
directory. On this machine, openssh-server was the only file in
/etc/network/if-up.d, so I suppose that some script executed during the
installation/upgrade of openssh-server removed the complete directory.

Recreating the directory resolves the issue and "ifup@ens3.service"
works and terminates properly.

The following is the output obtained from systemctl status:

ifup@ens3.service - ifup for ens3
   Loaded: loaded (/lib/systemd/system/ifup@.service; static; vendor
preset: enabled)
   Active: failed (Result: exit-code) since Tue 2019-08-27 21:18:51
CEST; 9s ago
  Process: 6510 ExecStart=/bin/sh -ec ifup --allow=hotplug ens3; ifquery
--state ens3 (code=exited, status=1/FAILURE)
 Main PID: 6510 (code=exited, status=1/FAILURE)

Aug 27 21:18:51 hostname sh[6510]: DHCPREQUEST for 10.X.X.X on ens3 to
255.255.255.255 port 67
Aug 27 21:18:51 hostname dhclient[6518]: DHCPREQUEST for 10.X.X.X on
ens3 to 255.255.255.255 port 67
Aug 27 21:18:51 hostname dhclient[6518]: DHCPACK of 10.X.X.X from 10.X.X.X
Aug 27 21:18:51 hostname sh[6510]: DHCPACK of 10.X.X.X from 10.X.X.X
Aug 27 21:18:51 hostname dhclient[6518]: bound to 10.X.X.X -- renewal in
3089 seconds.
Aug 27 21:18:51 hostname sh[6510]: bound to 10.X.X.X -- renewal in 3089
seconds.
Aug 27 21:18:51 hostname sh[6510]: run-parts: failed to open directory
/etc/network/if-up.d: No such file or directory
Aug 27 21:18:51 hostname sh[6510]: ifup: failed to bring up ens3
Aug 27 21:18:51 hostname systemd[1]: ifup@ens3.service: Main process
exited, code=exited, status=1/FAILURE
Aug 27 21:18:51 hostname systemd[1]: ifup@ens3.service: Failed with
result 'exit-code'.

Bug#935496: Fuse 2.9.9-1

[Karl-Heinz Künzel]

On Mon, 26 Aug 2019 08:39:31 +0200 t3ChN0M4G3  wrote:

Hi, Bullseye - Official Snapshot amd64 NETINST.iso  20190819-10:57

Installation crashes with that message

"Fehler traten auf beim Bearbeiten von:  fuse"

'Error while handling of: fuse'

Attach full /var/log/apt/history.log and /var/log/apt/term.log

br



Start-Date: 2019-08-27  05:43:42
Commandline: apt-get -o APT::Status-Fd=4 -o APT::Keep-Fds::=5 -o APT::Keep-Fds::=6 -q -y --no-remove install locales
Install: locales:amd64 (2.28-10), libc-l10n:amd64 (2.28-10, automatic)
End-Date: 2019-08-27  05:43:43

Start-Date: 2019-08-27  07:43:45
Commandline: apt-get -o APT::Status-Fd=4 -o APT::Keep-Fds::=5 -o APT::Keep-Fds::=6 -q -y --no-remove install busybox
Install: busybox:amd64 (1:1.30.1-4)
End-Date: 2019-08-27  07:43:46

Start-Date: 2019-08-27  07:43:46
Commandline: apt-get -o APT::Status-Fd=4 -o APT::Keep-Fds::=5 -o APT::Keep-Fds::=6 -q -y --no-remove install initramfs-tools
Install: linux-base:amd64 (4.6, automatic), libklibc:amd64 (2.0.6-1, automatic), klibc-utils:amd64 (2.0.6-1, automatic), initramfs-tools-core:amd64 (0.133, automatic), initramfs-tools:amd64 (0.133)
End-Date: 2019-08-27  07:43:48

Start-Date: 2019-08-27  07:43:51
Commandline: apt-get -o APT::Status-Fd=4 -o APT::Keep-Fds::=5 -o APT::Keep-Fds::=6 -q -y --no-remove -o APT::Install-Recommends=true install linux-image-amd64
Install: libpython3.7-minimal:amd64 (3.7.4-2, automatic), libsqlite3-0:amd64 (3.29.0-1, automatic), linux-image-4.19.0-5-amd64:amd64 (4.19.37-6, automatic), python3.7:amd64 (3.7.4-2, automatic), python3:amd64 (3.7.3-1, automatic), mime-support:amd64 (3.63, automatic), libmagic1:amd64 (1:5.37-5, automatic), libmpdec2:amd64 (2.4.2-2, automatic), libpython3.7-stdlib:amd64 (3.7.4-2, automatic), libexpat1:amd64 (2.2.7-1, automatic), python3.7-minimal:amd64 (3.7.4-2, automatic), firmware-linux-free:amd64 (3.4, automatic), python3-minimal:amd64 (3.7.3-1, automatic), libmagic-mgc:amd64 (1:5.37-5, automatic), libpython3-stdlib:amd64 (3.7.3-1, automatic), linux-image-amd64:amd64 (4.19+105), xz-utils:amd64 (5.2.4-1, automatic), bzip2:amd64 (1.0.6-9.2, automatic), file:amd64 (1:5.37-5, automatic), apparmor:amd64 (2.13.3-4, automatic)
End-Date: 2019-08-27  07:44:25

Start-Date: 2019-08-27  07:44:26
Commandline: apt-get -o APT::Status-Fd=4 -o APT::Keep-Fds::=5 -o APT::Keep-Fds::=6 -q -y --no-remove install pciutils
Install: pciutils:amd64 (1:3.6.2-2), libpci3:amd64 (1:3.6.2-2, automatic)
End-Date: 2019-08-27  07:44:26

Start-Date: 2019-08-27  07:44:27
Commandline: apt-get -o APT::Status-Fd=4 -o APT::Keep-Fds::=5 -o APT::Keep-Fds::=6 -q -y --no-remove install usbutils
Install: libusb-1.0-0:amd64 (2:1.0.22-2, automatic), usb.ids:amd64 (2019.07.27-1, automatic), usbutils:amd64 (1:012-1)
End-Date: 2019-08-27  07:44:28

Start-Date: 2019-08-27  07:44:28
Commandline: apt-get -o APT::Status-Fd=4 -o APT::Keep-Fds::=5 -o APT::Keep-Fds::=6 -q -y --no-remove install wireless-tools
Install: wireless-tools:amd64 (30~pre9-13), libiw30:amd64 (30~pre9-13, automatic)
End-Date: 2019-08-27  07:44:29

Start-Date: 2019-08-27  07:44:30
Commandline: apt-get -o APT::Status-Fd=4 -o APT::Keep-Fds::=5 -o APT::Keep-Fds::=6 -q -y --no-remove install wpasupplicant
Install: libnl-route-3-200:amd64 (3.4.0-1, automatic), libdbus-1-3:amd64 (1.12.16-1, automatic), libpcsclite1:amd64 (1.8.25-2, automatic), libnl-genl-3-200:amd64 (3.4.0-1, automatic), libnl-3-200:amd64 (3.4.0-1, automatic), wpasupplicant:amd64 (2:2.9-1)
End-Date: 2019-08-27  07:44:32

Start-Date: 2019-08-27  07:44:33
Commandline: apt-get -o APT::Status-Fd=4 -o APT::Keep-Fds::=5 -o APT::Keep-Fds::=6 -q -y --no-remove install keyboard-configuration
Install: keyboard-configuration:amd64 (1.191)
End-Date: 2019-08-27  07:44:34

Start-Date: 2019-08-27  07:44:35
Commandline: apt-get -o APT::Status-Fd=4 -o APT::Keep-Fds::=5 -o APT::Keep-Fds::=6 -q -y --no-remove install console-setup
Install: console-setup-linux:amd64 (1.191, automatic), console-setup:amd64 (1.191), xkb-data:amd64 (2.26-2, automatic), kbd:amd64 (2.0.4-4, automatic)
End-Date: 2019-08-27  07:44:38

Start-Date: 2019-08-27  07:51:15
Commandline: apt-get -o APT::Status-Fd=4 -o APT::Keep-Fds::=5 -o APT::Keep-Fds::=6 -q --no-install-recommends -y -o DPkg::options=--force-confnew upgrade --with-new-pkgs
Install: linux-image-5.2.0-2-amd64:amd64 (5.2.9-2, automatic)
Upgrade: libpython3.7-minimal:amd64 (3.7.4-2, 3.7.4-3), libnl-route-3-200:amd64 (3.4.0-1, 3.4.0-1+b1), gcc-9-base:amd64 (9.2.1-1, 9.2.1-4), libnl-genl-3-200:amd64 (3.4.0-1, 3.4.0-1+b1), libsystemd0:amd64 (241-7, 242-4), wireless-tools:amd64 (30~pre9-13, 30~pre9-13+b1), libsqlite3-0:amd64 (3.29.0-1, 3.29.0-2), libiw30:amd64 (30~pre9-13, 30~pre9-13+b1), liblognorm5:amd64 (2.0.5-1, 2.0.5-1+b1), console-setup-linux:amd64 (1.191, 1.193), python3.7:amd64 (3.7.4-2, 3.7.4-3), udev:amd64 (241-7, 242-4), console-setup:amd64 (1.191, 1.193), procps:amd64 (2:3.3.15-2, 2:3.3.15-2+b1), readline-common:amd64 (8.0-2, 8.0-3), libprocps7:amd64 (2:3.3.15-2, 

Bug#935919: new upstream (1.20190819)

[Daniel Baumann]

Package: raspi-firmware
Severity: wishlist

Hi,

it would be nice if you could upgrade to the current upstream version
(1.20190819).

Regards,
Daniel

Bug#931943: vtk6: FTBFS with PROJ 6

[Anton Gladky]

Yes, I will do it soon. Thanks.

Anton

Am Di., 27. Aug. 2019 um 18:51 Uhr schrieb Sebastiaan Couwenberg
:
>
> vtk6 is failing to build with the new proj in unstable as part of the
> transition. Please move the fixed packages from experimental to unstable.
>
> Kind Regards,
>
> Bas
>
> --
>  GPG Key ID: 4096R/6750F10AE88D4AF1
> Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1
>
> --
> debian-science-maintainers mailing list
> debian-science-maintain...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#935909: python3-pyqt5: Segmentation fault when switching between image and text with html tags using style sheets

[Dmitry Shachnev]

Control: reassign -1 libqt5widgets5 5.11.3+dfsg1-4
Control: fixed -1 qtbase-opensource-src/5.12.4+dfsg-1

Hi Danny!

On Tue, Aug 27, 2019 at 04:06:07PM +, Danny Milosavljevic wrote:
> there is a segmentation fault problem with python3-qt5 and/or qt5 when
> switching between image and text with html tags.
>
> To reproduce,
>
> (1) Use Debian 10 live iso (or any Debian 10; it happened on a finished
> installation as well)
> (2) Invoke: sudo apt-get update
> (3) Invoke: sudo apt-get install python3-pyqt5
> (4) Invoke: cp 
> /usr/share/icons/Adwaita/48x48/status/network-wired-disconnected.png .
> (or any other png)
> (5) Save the text below as "a.py"
> (6) Invoke: QT_QPA_PLATFORM=offscreen python3 a.py 1
> (7) Wait for 5 seconds
> (8) See the segmentation fault
>
> It's very very reproducible for me.

I can reproduce it with the attached C++ source. So it is a bug in Qt, not
in PyQt. Reassigning accordingly.

Also I can reproduce it with Qt 5.11.3 but not with 5.12.4 from experimental.
Looking at upstream changes, I found [1] which most probably fixed this.

So it will be fixed in Sid as soon as we upgrade to 5.12. Do you want a fix
in Buster as well?

[1]: https://codereview.qt-project.org/c/qt/qtbase/+/242929

--
Dmitry Shachnev
#include 
#include 
#include 
#include 
#include 
#include 

static const char *styleSheet =
"QLabel {"
"padding: 2px;"
"min-width: 84px;"
"min-height: 84px;"
"}"
"QLabel[state=\"image\"]{"
"background-color: orange;"
"qproperty-text: \"Image\";"
"}"
"QLabel[state=\"text\"]{"
"background-color: #ee;"
"qproperty-text: \"This is aText\";"
"}";

int main(int argc, char **argv) {
QApplication app(argc, argv);
QWidget widget;
QLabel topLabel();
widget.setGeometry(100, 100, 100, 100);
QString labelProp = QStringLiteral("text");

QTimer flipTimer();
flipTimer.setInterval(1000);
QObject::connect(, ::timeout, [&]() {
if (labelProp == QStringLiteral("text"))
labelProp = QStringLiteral("image");
else
labelProp = QStringLiteral("text");
topLabel.setProperty("state", QVariant(labelProp));
widget.setStyleSheet(styleSheet);
});
flipTimer.start();

widget.show();
return app.exec();
}


signature.asc
Description: PGP signature

Bug#935671: fixed in rust-rle-decode-fast 1.0.1-2

[Steve Langasek]

Control: reopen -1

On Tue, Aug 27, 2019 at 07:08:13AM +, Sylvestre Ledru wrote:
>  rust-rle-decode-fast (1.0.1-2) unstable; urgency=medium
>  .
>* Team upload.
>* Package rle-decode-fast 1.0.1 from crates.io using debcargo 2.4.0
>  Hopefully, the rebuild will (Closes: #935671)

It did not.  (Why did you believe it would?  I filed this bug against
1.0.1-1, which is the same upstream version; and the dependencies of rust
modules are calculated based on the contents of the source package.)

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature

Bug#935917: suricata-update: cannot use suricata-update command

[Aaron Schaal]

Package: suricata-update
Version: 1.0.3-2
Severity: grave
Justification: renders package unusable

Dear Maintainer,

I just installed the suricata-update package from the Debian buster repo. 
Before that, I used the github version which worked fine. 

The "suricata-update" command of the Debian package tries to execute a file 
/usr/local/bin/suricata-update which doesn't exist (even the folder 
/usr/local/bin doesn't exist).
The right path should be /usr/bin/suricata-update (without local!).

best regards 
Aaron 

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

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

Versions of packages suricata-update depends on:
ii  ca-certificates  20190110
ii  python3  3.7.3-1
ii  python3-yaml 3.13-2

suricata-update recommends no packages.

suricata-update suggests no packages.

-- no debconf information

Bug#935918: cups: can't read hpcups PPDs

[Raphaël Halimi]

Package: cups
Version: 2.2.12-1

Hi,

Today I was unable to print on a HP Envy 5030 connected with USB that
used to work perfectly. The error message in CUPS web interface was
"filter failed" or something (from memory).

Not able to find the problem, I tried to reinstall the printer;
curiously, it worked with hpijs but not with hpcups. The error message
was "Unable to copy PPD file" (again from memory).

Using the hpijs driver was not satisfying because the printing is not
centered (in CUPS test page, the upper and right-most frame borders are
missing, even after setting paper size to A4 from the default Letter),
and it can't be corrected because the options are very limited, so I was
determined to find why adding the printer with the hpcups driver was not
working.

Adding it through HP ToolBox (from hplip) failed too, with an error
message I don't remember.

Adding it manually with lpadmin failed too, but with a much more
explicit message:

raph@arche:~$ LANG=C sudo lpadmin -p HP_ENVY_5030 -v
"usb://HP/ENVY%205000%20series?serial=redacted=1" -m
"drv:///hpcups.drv/hp-envy_5000_series.ppd" -D "HP Envy 5030"

lpadmin: Unable to open PPD "/tmp/0587f5d6ca5c8": Illegal option keyword
string on line 198.

Line 198 reads:

*PageSize Custom/Custom: "<>setpagedevice"

Googling some more, I found a very recent thread on the ArchLinux forum
which described exactly the same problem:

https://bbs.archlinux.org/viewtopic.php?id=248631

Unlike this Arch user, I didn't want to fiddle with the PPD (more
precisely, it may seem silly, but I stalled because I wasn't sure about
what I could replace the word "Custom" with...)

So instead I downgraded all cups packages from 2.2.12-1 to 2.2.10-6 and
that solved the problem completely (long live snapshot.debian.org), I
could add the printer with the hpcups driver and print documents as
expected.

Aside from that, other reasons that make me think that the problem comes
from the cups upgrade and not from printer-driver-hpcups are:

- the generated PPDs are identical (on failure, lpadmin left it in /tmp;
I compared it to the one in /etc/cups/ppd generated after the downgrade)

- cups was upgraded very recently (08/18 according to apt log) whereas
printer-driver-hpcups was not upgraded since I installed my Sid box
(06/06) and I clearly remember printing without problems between those dates

I was tempted to file this bug with a high severity since it prevents
installing a printer or simply printing, but since it also seems limited
to hpcups, I'll let you decide on this.

Regards,

-- 
Raphaël Halimi



signature.asc
Description: OpenPGP digital signature

Bug#935914: kinit: Signal: Segmentation fault (11) after rebooting

[Nicholas D Steeves]

Wow, it was harder than expected to get the dbsym packages without a
security-debug suite.  Thanks to adsb and ansgar on #debian-qt-kde for
the help (adds additional steps to my easy useful backtraces for end
users plan).  Here it is:

Application: kdeinit5 (kdeinit5), signal: Segmentation fault
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[KCrash Handler]
#6  0x7f966bfb6465 in QVector::reallocData 
(this=this@entry=0x5630f066f3a8, asize=268435452, aalloc=, 
options=...) at /usr/include/x86_64-linux-gnu/qt5/QtCore/qarraydata.h:218
#7  0x7f966bfba78e in QVector::append (t=: , this=0x5630f066f3a8) at 
/usr/include/x86_64-linux-gnu/qt5/QtCore/qrefcount.h:102
#8  QVector::operator<< (t=: , this=0x5630f066f3a8) at 
/usr/include/x86_64-linux-gnu/qt5/QtCore/qvector.h:283
#9  IdTreePostingIterator::next (this=0x5630f066f380) at 
./src/engine/idtreedb.cpp:128
#10 0x7f966bfa9444 in Baloo::AndPostingIterator::next (this=0x5630f0662de0) 
at ./src/engine/andpostingiterator.cpp:42
#11 Baloo::AndPostingIterator::next (this=0x5630f0662de0) at 
./src/engine/andpostingiterator.cpp:45
#12 0x7f966c18c4c1 in Baloo::SearchStore::exec 
(this=this@entry=0x7ffe684bfcb0, term=..., offset=, 
limit=, sortResults=) at 
./src/lib/searchstore.cpp:127
#13 0x7f966c17b190 in Baloo::Query::exec (this=this@entry=0x7ffe684bfd40) 
at ./src/lib/query.cpp:210
#14 0x7f967332f519 in Baloo::SearchProtocol::listDir (this=0x7ffe684bffa0, 
url=...) at ./src/kioslaves/search/kio_search.cpp:120
#15 0x7f966e512f36 in KIO::SlaveBase::dispatch (this=0x7ffe684bffa0, 
command=71, data=...) at ./src/core/slavebase.cpp:1176
#16 0x7f966e513876 in KIO::SlaveBase::dispatchLoop 
(this=this@entry=0x7ffe684bffa0) at ./src/core/slavebase.cpp:325
#17 0x7f967332fd07 in kdemain (argc=, argv=) 
at ./src/kioslaves/search/kio_search.cpp:218
#18 0x5630f0593e1c in launch (argc=4, _name=0x5630f0641248 
"/usr/lib/x86_64-linux-gnu/qt5/plugins/kf5/kio/baloosearch.so", args=, cwd=, envc=0, envs=, reset_env=false, 
tty=0x0, avoid_loops=false, startup_id_str=0x5630f0597187 "0") at 
./src/kdeinit/kinit.cpp:706
#19 0x5630f0594eea in handle_launcher_request (sock=8, who=) 
at ./src/kdeinit/kinit.cpp:1146
#20 0x5630f05958fb in handle_requests (waitForPid=0) at 
./src/kdeinit/kinit.cpp:1339
#21 0x5630f0590645 in main (argc=5, argv=) at 
./src/kdeinit/kinit.cpp:1785
[Inferior 1 (process 2571) detached]


signature.asc
Description: PGP signature

Bug#935669: assaultcube-data: Outdated version makes assaultcube uninstallable

[Simon McVittie]

On Tue, 27 Aug 2019 at 16:13:10 +0200, Reiner Herrmann wrote:
> I think the problem is that assaultcube-data 1.2.0.2.1-2 was uploaded
> source-only. Someone needs to do a new upload including the arch:all
> binary package, as it is in non-free (which the buildds don't seem to
> build).

Alternatively, if it's legally and technically OK to build assaultcube-data
on buildds, a maintainer can mark it to be autobuilt and do source uploads:
https://www.debian.org/doc/manuals/developers-reference/ch05.en.html#non-free-buildd

(I have not reviewed whether it's legally and technically OK in this case.)

smcv

Bug#935910: apt: Should be less tolerant of dpkg errors when forcing removal

[Julian Andres Klode]

Control: reassign -1 dpkg

On Tue, Aug 27, 2019 at 05:34:05PM +0100, Mark Hindley wrote:
> Package: apt
> Version: 1.8.3
> Severity: important
> 
> Dear apt maintainers,
> 
> This report is a result of my investigation of #934491 which shows that when
> trying to migrate a sid install from systemd to sysvinit and elogind by the 
> most
> obvious route it is possible to break the system in a way that is difficult to
> recover with the fairly simple command:
> 
>  apt install libpam-elogind sysvinit-core
> 
> I think the root cause of the issue is the way apt invokes dpkg when forcing
> removals which is not sufficiently responsive to errors.
> 
> In this case apt's dpkg commands are:
> 
>  echo 'libpam-systemd:amd64 deinstall' | /usr/bin/dpkg --set-selections 
>  echo 'systemd-sysv:amd64 deinstall' | /usr/bin/dpkg --set-selections 
>  echo 'systemd:amd64 deinstall' | /usr/bin/dpkg --set-selections 
>  echo 'libsystemd0:amd64 deinstall' | /usr/bin/dpkg --set-selections 
>  /usr/bin/dpkg --status-fd 18 --no-triggers --force-depends --remove 
> libpam-systemd:amd64 
>  /usr/bin/dpkg --status-fd 18 --no-triggers --unpack --auto-deconfigure 
> /var/cache/apt/archives/libpam-elogind_241.3-1+debian1_amd64.deb 
>  /usr/bin/dpkg --status-fd 18 --no-triggers --force-depends --remove 
> systemd-sysv:amd64 
>  /usr/bin/dpkg --status-fd 18 --no-triggers --unpack --auto-deconfigure 
> /var/cache/apt/archives/sysvinit-core_2.96~beta-1_amd64.deb 
>  /usr/bin/dpkg --status-fd 18 --no-triggers --force-depends --remove 
> systemd:amd64 libsystemd0:amd64 
>^^^ The line above causes the problem ^^^
>  /usr/bin/dpkg --status-fd 18 --no-triggers --unpack --auto-deconfigure 
> /var/cache/apt/archives/libelogind0_241.3-1+debian1_amd64.deb 
>  /usr/bin/dpkg --status-fd 18 --no-triggers --configure libelogind0:amd64 
>  /usr/bin/dpkg --status-fd 18 --no-triggers --unpack --auto-deconfigure 
> /var/cache/apt/archives/elogind_241.3-1+debian1_amd64.deb 
>  /usr/bin/dpkg --status-fd 18 --configure --pending 
> 
> The problem is caused by the invocation forcing the removal of systemd and
> libsystemd0. If systemd is pid 1 then its prerm will fail to prevent
> removal. However, dpkg still continues to remove libsystemd0 as requested
> *before* exiting and signalling an error. apt then stops in response to the 
> dpkg
> error. The system is then broken as there is no libsystemd.so.0 installed 
> which
> apt itself requires.
> 
> My solution is to invoke dpkg with --abort-after=1.  The command line
> 
>  apt install -o DPkg::Options::="--abort-after=1" install libpam-elogind 
> sysvinit-core
> 
> no longer breaks a sid systemd system. This means that dpkg exits immediately
> after the systemd prerm fails and libsystemd0 remains installed. The
> dependencies can then be fixed with apt.
> 
> I suggest that --abort-after=1 should be apt's default when forcing package
> removal.

APT is the wrong place for that. We're trying to move to a future where
we only tell dpkg all the actions to do and then run a single dpkg, so
adding hacks like that feels counter-intuitive.

If we agree that this is a good thing to do, dpkg should do it.

-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer  i speak de, en

Bug#916918: iptables translation issues

[Arturo Borrero Gonzalez]

Control: reassign -1 iptables 1.8.3-2

This bugs really belongs to the iptables-translate binary which lives in the
iptables package rather than in nft.

Bug#916918: iptables translation issues

[Arturo Borrero Gonzalez]

Control: tags -1 upstream
Control: forwarded -1 https://bugzilla.netfilter.org/show_bug.cgi?id=1362

On Thu, 20 Dec 2018 15:19:25 +0200 debian-reportbug-2...@ssd.axu.tm wrote:
> Package: nftables
> Version: 0.9.0-2
> Severity: normal
> 
> The following examples used to work with native iptables, but either 
> fail or produce the wrong functionality with nftables:
> 
> bash# iptables-translate -4 -A bogoncheck -m set --match-set bogons4 src 
> -j DROP
> nft # -4 -A bogoncheck -m set --match-set bogons4 src -j DROP
> bash#
> 
> (i.e. fails to translate rule)

There is not translation possible for this AFAIK. Sorry for that.
See here for more info:

https://wiki.nftables.org/wiki-nftables/index.php/Moving_from_ipset_to_nftables

The rest of the bug report was forwarded upstream.

thanks!

Bug#932878: nft segfault on overlapping intervals

[Arturo Borrero Gonzalez]

Control: tags -1 upstream confirmed
Control: forwarded -1 https://bugzilla.netfilter.org/show_bug.cgi?id=1361

On Wed, 24 Jul 2019 14:47:54 +1000 "Trent W. Buck"  wrote:
> Package: nftables
> Version: 0.9.1-2
> Severity: normal
> 
> While studying RFC 4890 I ran into parsing problems.
> I have narrowed it down to the ruleset below.
> 

Thanks for your report!

I've forwarded the information upstream and hopefully we will see a fix in
upcoming releases.

Bug#932877: parser rejects blank/comment lines in literal sets/maps

[Arturo Borrero Gonzalez]

Control: tags -1 upstream confirmed
Control: forwarded -1 https://bugzilla.netfilter.org/show_bug.cgi?id=1196

On Wed, 24 Jul 2019 14:17:06 +1000 "Trent W. Buck"  wrote:
> Package: nftables
> Version: 0.9.1-2
> Severity: minor
> 
> The nftables file parser allows newlines in literal sets and maps.
> It allows comments in them -- but it doesn't allow comments on their own line.
> I think this is a mistake, and the parser should be changed to allow them.
> 

This is a known limitation that was already reported in upstream bug tracker.

Thanks for your report!

Bug#914150: pcmanfm: SIGSEGV, Segmentation fault on opening folder

[devel]

Hello,


On Sun, 17 Mar 2019 18:39:10 +0100 bernha...@mailbox.org wrote:

> Therefore I would propose to
> - reassign this bug 914150 to libfm/1.3.0-1
> - clone it and reassign the clone to librsvg2-common/2.44.10-1
> - and close this bug 914150

this sounds reasonable to me.

In my local installation, I solved this issue by upgrading librsvg2-common (and
librsvg2-2) from 2.44.10-2.1 to 2.44.14-1.

Thus Bernhard's suggestion regarding the patch for librsvg2 would probably be a
great relief for many LXDE users on Buster.

Cheers,
Lars

Bug#933621: BUG: invalid expression type concat on invalid input "iifname . oifname p . q"

[Arturo Borrero Gonzalez]

Control: tags -1 upstream confirmed
Control: forwarded -1 https://bugzilla.netfilter.org/show_bug.cgi?id=1360

On Thu, 01 Aug 2019 13:25:32 +1000 "Trent W. Buck"  wrote:
> Package: nftables
> Version: 0.9.1-2
> Severity: minor
> 
> I found a parser bug when experimenting with concatenations:
> 

Thanks for your report. I've forwarded it upstream.

Bug#933531: accept hostnames with one IPv4 address and one IPv6 address in single-stack chain?

[Arturo Borrero Gonzalez]

Control: tags -1 wontfix

On Wed, 31 Jul 2019 18:54:42 +1000 "Trent W. Buck"  wrote:
> Package: nftables
> Version: 0.9.1-2
> Severity: wishlist
> 
> In iptables-restore, if a hostname has 3 addresses, you will end up with 3 
> rules, e.g.
> 
> -A INPUT -d www -j ACCEPT
> 
> --expands to-->
> 
> -A INPUT -d 127.0.0.1  -j ACCEPT
> -A INPUT -d 10.0.0.1   -j ACCEPT
> -A INPUT -d 172.16.0.1 -j ACCEPT
> 
> In nftables, this is simply not allowed, which is reasonable:
> 
> # nft table inet a
> # nft chain inet a b
> # nft  rule inet a b ip saddr one-ipv4-address
> # nft  rule inet a b ip saddr two-ipv4-addresses
> Error: Hostname resolves to multiple addresses
> rule inet a b ip saddr two-ipv4-addresses
>^^
> 
> I think there is one case where nftables COULD make a smarter decision:
> the hostname has one IPv4 address and one IPv6 address, AND
> we are operating in a single-stack table.
> 

This is specifically designed this way. Building firewall rules from FQDNs is
confusing and can lead to errors. Typical case is: the rule won't change if the
A register change in DNS.

I believe nft accepting FQDNs in such a simple way is the right balance between
not accepting them at all and doing smart things.

I think doing DNS tricks is a thing for higher level wrappers such as firewalld.

Bug#614769: Bug confirmation on Debian Bubster 10

[Tobias Boesch]

I can confirm the described behavior in Evolution 3.30.5-1.1 on Debian
Buster.

Bug#935915: apt-cacher-ng: Extremely low transfer rate on LAN

[sixerjman]

Package: apt-cacher-ng
Version: 3.2-2
Severity: important

Dear Maintainer,

   * What led up to the situation?
Very low transfer speed for clients on LAN
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
apt update / apt upgrade
   * What was the outcome of this action?
Approximately 1/10 transfer rate for packages which had been previously
downloaded to the server (same architecture AMD64)
   * What outcome did you expect instead?
LAN speed equivalent to speed from direct download from same Debian mirror

Attached is a compressed 'apt-cacher-ng.err' log of the apt update






-- Package-specific info:

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

Kernel: Linux 5.2.0-2-amd64 (SMP w/2 CPU cores)
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=en_US.UTF-8 (charmap=UTF-8) (ignored:
LC_ALL set to en_US.UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages apt-cacher-ng depends on:
ii  adduser3.118
ii  debconf [debconf-2.0]  1.5.73
ii  dpkg   1.19.7
ii  libbz2-1.0 1.0.6-9.2
ii  libc6  2.28-10
ii  libgcc11:9.2.1-4
ii  liblzma5   5.2.4-1+b1
ii  libssl1.1  1.1.1c-1
ii  libstdc++6 9.2.1-4
ii  libsystemd0242-4
ii  libwrap0   7.6.q-28
ii  lsb-base   11.1.0
ii  zlib1g 1:1.2.11.dfsg-1+b1

apt-cacher-ng recommends no packages.

Versions of packages apt-cacher-ng suggests:
ii  avahi-daemon  0.7-4+b1
pn  doc-base  
ii  libfuse2  2.9.9-1

-- Configuration Files:
/etc/apt-cacher-ng/acng.conf changed:
CacheDir: /var/cache/apt-cacher-ng
LogDir: /var/log/apt-cacher-ng
SupportDir: /usr/lib/apt-cacher-ng
Remap-debrep: file:deb_mirror*.gz /debian ; file:backends_debian # Debian
Archives
Remap-uburep: file:ubuntu_mirrors /ubuntu ; file:backends_ubuntu # Ubuntu
Archives
Remap-cygwin: file:cygwin_mirrors /cygwin # ; file:backends_cygwin #
incomplete, please create this file or specify preferred mirrors here
Remap-sfnet:  file:sfnet_mirrors # ; file:backends_sfnet # incomplete,
please create this file or specify preferred mirrors here
Remap-alxrep: file:archlx_mirrors /archlinux # ; file:backend_archlx # Arch
Linux
Remap-fedora: file:fedora_mirrors # Fedora Linux
Remap-epel:   file:epel_mirrors # Fedora EPEL
Remap-slrep:  file:sl_mirrors # Scientific Linux
Remap-gentoo: file:gentoo_mirrors.gz /gentoo ; file:backends_gentoo #
Gentoo Archives
Remap-secdeb: security.debian.org ; security.debian.org
deb.debian.org/debian-security
ReportPage: acng-report.html
ExThreshold: 4
Debug:3
LocalDirs: acng-doc /usr/share/doc/apt-cacher-ng
PassThroughPattern: ^repo\.nordvpn\.com:443$

/etc/apt-cacher-ng/security.conf [Errno 13] Permission denied:
'/etc/apt-cacher-ng/security.conf'


apt-cacher-ng.err.gz
Description: application/gzip

Bug#914641: faad2: CVE-2018-19502 CVE-2018-19503 CVE-2018-19504 CVE-2019-6956

[Hugo Lefeuvre]

Hi,

Following a discussion with Fabian on GitHub[0], here is a NMU for faad2 in
unstable. This NMU addresses the last few open security issues via targeted
patches, until they are integrated in the next upstream release.

Please let me know if you want me to change anything, otherwise I am waiting
for your ack to upload.

regards,
Hugo

[0] https://github.com/knik0/faad2/pull/38

-- 
Hugo Lefeuvre (hle)|www.owl.eu.com
RSA4096_ 360B 03B3 BF27 4F4D 7A3F D5E8 14AA 1EB8 A247 3DFD
ed25519_ 37B2 6D38 0B25 B8A2 6B9F 3A65 A36F 5357 5F2D DC4C
diff -Nru faad2-2.8.8/debian/changelog faad2-2.8.8/debian/changelog
--- faad2-2.8.8/debian/changelog	2019-06-07 14:07:34.0 -0400
+++ faad2-2.8.8/debian/changelog	2019-08-27 13:29:39.0 -0400
@@ -1,3 +1,15 @@
+faad2 (2.8.8-3.1) unstable; urgency=medium
+
+  * Non-maintainer upload with maintainer's permission.
+  * CVE-2019-6956: Buffer over read in the function ps_mix_phase()
+(libfaad/ps_dec.c) (Closes: #914641).
+  * CVE-2018-20196: Stack buffer overflow in the function calculate_gain
+(libfaad/sbr_hfadj.c).
+  * CVE-2018-20199, CVE-2018-20360: NULL pointer dereference in the function
+ifilter_bank (libfaad/filtbank.c).
+
+ -- Hugo Lefeuvre   Tue, 27 Aug 2019 13:29:39 -0400
+
 faad2 (2.8.8-3) unstable; urgency=high
 
   * Team upload.
diff -Nru faad2-2.8.8/debian/patches/CVE-2018-20196.patch faad2-2.8.8/debian/patches/CVE-2018-20196.patch
--- faad2-2.8.8/debian/patches/CVE-2018-20196.patch	1969-12-31 19:00:00.0 -0500
+++ faad2-2.8.8/debian/patches/CVE-2018-20196.patch	2019-08-27 13:29:39.0 -0400
@@ -0,0 +1,48 @@
+Description: fix stack based buffer overflow in calculate_gain (libfaad/sbr_hfadj.c)
+ sbr_fbt: sbr->M should not exceed MAX_M
+ .
+ sbr->M is set by derived_frequency_table() from user-passed input
+ without checking for > MAX_M.
+ .
+ This leads to out-of-bounds accesses later, crashes and potential
+ security relevant issues. It should be considered a fatal error for
+ the SBR block.
+ .
+ return error code if sbr->M > MAX_M.
+ .
+ also, in some cases sbr_extension_data() ignores the return value of
+ calc_sbr_tables, probably assuming that sbr is always valid. It should
+ almost certainly not do that.
+Author: Hugo Lefeuvre 
+Origin: upstream, https://github.com/knik0/faad2/commit/6aeeaa1af0caf986daf22
+--- a/libfaad/sbr_fbt.c	2009-05-31 03:02:54.0 -0400
 b/libfaad/sbr_fbt.c	2019-08-26 09:14:35.368320494 -0400
+@@ -526,6 +526,8 @@
+ }
+ 
+ sbr->M = sbr->f_table_res[HI_RES][sbr->N_high] - sbr->f_table_res[HI_RES][0];
++if (sbr->M > MAX_M)
++return 1;
+ sbr->kx = sbr->f_table_res[HI_RES][0];
+ if (sbr->kx > 32)
+ return 1;
+--- a/libfaad/sbr_syntax.c	2009-05-31 03:02:54.0 -0400
 b/libfaad/sbr_syntax.c	2019-08-26 09:15:14.108163215 -0400
+@@ -196,7 +196,7 @@
+ /* if an error occured with the new header values revert to the old ones */
+ if (rt > 0)
+ {
+-calc_sbr_tables(sbr, saved_start_freq, saved_stop_freq,
++result += calc_sbr_tables(sbr, saved_start_freq, saved_stop_freq,
+ saved_samplerate_mode, saved_freq_scale,
+ saved_alter_scale, saved_xover_band);
+ }
+@@ -215,7 +215,7 @@
+ if ((result > 0) &&
+ (sbr->Reset || (sbr->bs_header_flag && sbr->just_seeked)))
+ {
+-calc_sbr_tables(sbr, saved_start_freq, saved_stop_freq,
++result += calc_sbr_tables(sbr, saved_start_freq, saved_stop_freq,
+ saved_samplerate_mode, saved_freq_scale,
+ saved_alter_scale, saved_xover_band);  
+ }
diff -Nru faad2-2.8.8/debian/patches/CVE-2018-20360-20199.patch faad2-2.8.8/debian/patches/CVE-2018-20360-20199.patch
--- faad2-2.8.8/debian/patches/CVE-2018-20360-20199.patch	1969-12-31 19:00:00.0 -0500
+++ faad2-2.8.8/debian/patches/CVE-2018-20360-20199.patch	2019-08-27 13:29:39.0 -0400
@@ -0,0 +1,49 @@
+Description: fix NULL pointer dereference in ifilter_bank (libfaad/filtbank.c)
+ specrec: better handle unexpected PS
+ .
+ Parametric Stereo (PS) can arrive at any moment in input files. PS
+ changes the number of output channels and therefore requires more
+ allocated memory in various structures from hDecoder.
+ .
+ The current faad2 code attempts to perform allocation surgery in
+ hDecoder to recover from this. This works well when there is only one
+ frame channel, else it creates large number of memory corruption
+ issues.
+ .
+ If there is more than one input channel, return cleanly with error
+ code. It would be nice to handle this, but this is likely to be a lot
+ of work and is beyond the scope of a security fix.
+ .
+ This patch addresses CVE-2018-20360 and CVE-2018-20199.
+Author: Hugo Lefeuvre 
+Origin: upstream, https://github.com/knik0/faad2/commit/3b80a57483a6bc822d3ce3c
+--- 

Bug#935914: kinit: Signal: Segmentation fault (11) after rebooting

[Nicholas D Steeves]

Package: kinit
Version: 5.54.0-1
Severity: important

Hi,

I haven't been able to reproduce this 100% of the time, but it happens
some of the time after logging in after rebooting.  I have a system
load monitor and have noticed that memory balloons and system
responsiveness drops right before the crash occurs.  Sorry for the
partially incomplete backtrace; libkf5configcore5-dbgsym wasn't
updated to 5.54.0-1+deb10u1 for some reason and is uninstallable.

Application: kdeinit5 (kdeinit5), signal: Segmentation fault
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[KCrash Handler]
#6  0x7f966bfb6465 in QVector::reallocData 
(this=this@entry=0x5630f066f3a8, asize=268435452, aalloc=, 
options=...) at /usr/include/x86_64-linux-gnu/qt5/QtCore/qarraydata.h:218
#7  0x7f966bfba78e in QVector::append (t=: , this=0x5630f066f3a8) at 
/usr/include/x86_64-linux-gnu/qt5/QtCore/qrefcount.h:102
#8  QVector::operator<< (t=: , this=0x5630f066f3a8) at 
/usr/include/x86_64-linux-gnu/qt5/QtCore/qvector.h:283
#9  IdTreePostingIterator::next (this=0x5630f066f380) at 
./src/engine/idtreedb.cpp:128
#10 0x7f966bfa9444 in Baloo::AndPostingIterator::next (this=0x5630f0662de0) 
at ./src/engine/andpostingiterator.cpp:42
#11 Baloo::AndPostingIterator::next (this=0x5630f0662de0) at 
./src/engine/andpostingiterator.cpp:45
#12 0x7f966c18c4c1 in ?? () from /usr/lib/x86_64-linux-gnu/libKF5Baloo.so.5
#13 0x7f966c17b190 in Baloo::Query::exec() () from 
/usr/lib/x86_64-linux-gnu/libKF5Baloo.so.5
#14 0x7f967332f519 in ?? () from 
/usr/lib/x86_64-linux-gnu/qt5/plugins/kf5/kio/baloosearch.so
#15 0x7f966e512f36 in KIO::SlaveBase::dispatch (this=0x7ffe684bffa0, 
command=71, data=...) at ./src/core/slavebase.cpp:1176
#16 0x7f966e513876 in KIO::SlaveBase::dispatchLoop (this=0x7ffe684bffa0) at 
./src/core/slavebase.cpp:325
#17 0x7f967332fd07 in kdemain () from 
/usr/lib/x86_64-linux-gnu/qt5/plugins/kf5/kio/baloosearch.so
#18 0x5630f0593e1c in launch (argc=4, _name=0x5630f0641248 
"/usr/lib/x86_64-linux-gnu/qt5/plugins/kf5/kio/baloosearch.so", args=, cwd=, envc=0, envs=, reset_env=false, 
tty=0x0, avoid_loops=false, startup_id_str=0x5630f0597187 "0") at 
./src/kdeinit/kinit.cpp:706
#19 0x5630f0594eea in handle_launcher_request (sock=8, who=) 
at ./src/kdeinit/kinit.cpp:1146
#20 0x5630f05958fb in handle_requests (waitForPid=0) at 
./src/kdeinit/kinit.cpp:1339
#21 0x5630f0590645 in main (argc=5, argv=) at 
./src/kdeinit/kinit.cpp:1785
[Inferior 1 (process 2571) detached]


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

Kernel: Linux 4.19.68 (SMP w/2 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_CA:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages kinit depends on:
ii  kio  5.54.1-1
ii  libc62.28-10
ii  libcap2  1:2.25-2
ii  libcap2-bin  1:2.25-2
ii  libkf5configcore55.54.0-1+deb10u1
ii  libkf5coreaddons55.54.0-1
ii  libkf5crash5 5.54.0-1
ii  libkf5i18n5  5.54.0-1
ii  libkf5kiocore5   5.54.1-1
ii  libkf5kiowidgets55.54.1-1
ii  libkf5service-bin5.54.0-1
ii  libkf5service5   5.54.0-1
ii  libkf5windowsystem5  5.54.0-1
ii  libqt5core5a 5.11.3+dfsg1-1
ii  libqt5dbus5  5.11.3+dfsg1-1
ii  libqt5gui5   5.11.3+dfsg1-1
ii  libstdc++6   8.3.0-6
ii  libx11-6 2:1.6.7-1
ii  libxcb1  1.13.1-2

kinit recommends no packages.

kinit suggests no packages.

-- no debconf information

Bug#935809: Re: buster-pu: package fdroidserver_1.1.4-1~deb10u1

[Adam D. Barratt]

Control: tags -1 - moreinfo

On Mon, 2019-08-26 at 23:37 +0200, Hans-Christoph Steiner wrote:
> Adam D. Barratt:
[...]
> > On Mon, 2019-08-26 at 14:54 +0200, Hans-Christoph Steiner wrote:
[...]
> They are mostly from compatibility bugs discovered since the final
> buster freeze.  Some were fixed before the freeze, but we spent a lot
> of time testing this package on buster, so we wanted until the tests
> were complete before requesting an unblock.  This release is meant to
> be an LTS for fdroidserver, and we'll be working to get it into other
> distros too.
[...]
> > >   What
> > > makes the debdiff long is the cruft that were removed upstream in
> > > the
> > > source tarball due to a cleanup (see diffstat).
> > 
> > Are you really saying that what looks from the diff like dropping
> > all localisation support is cruft cleanup? I feel like I may be
> > missing something.
> 
> The localization was not removed.  The localization user-editable .po
> files were removed while the .mo files are still there, which are
> what are actually used to display the strings..  The .mo files can be
> converted back to .po files as needed using msgunfmt, so they are
> also "source".

That seems an unusual approach, in that I would instead have expected
you to ship the .po files and generate the .mo at package build time,
but I guess it works.

> > In any case, cleaning up cruft by removing 60K lines of files from
> > your source package is generally not the sort of thing that would
> > be expected in a stable update.
> 
> Yeah, this is annoying for sure. This cleanup was not triggered by
> me, it came from creating the source tarball on buster, while v1.1.1
> was created on stretch.  The update to the standard Python tools that
> generate source tarballs seems to be the cause.  I only noticed this
> after the release was done and uploaded. Sorry.

Well, you said above that you (as in upstream) intentionally removed
the PO files, so it seems you at least partly triggered it.

> > > The next largest block of changes is fixes to the test suite to
> > > work
> > > properly on Debian/buster.
> > >  The remaining changes are compatibility fixes related to:
> > > 
> > > 929905: incompatible with upstream's data repository
[...]
> > Please provide a diff that only includes the non-"cruft" changes,
> > so
> > there's a chance of us knowing what you're actually changing.
> 
> I attached an excerpted debdiff without the aforementioned source
> tarball removals.

Thanks for that.

As a note, it may have been worth describing at least the "no-keep-git-
mirror-archive" and "archive-older" changes in your changelog(s). It's
possible they relate to one of the changes that you /have/ described,
but I'm honestly not sure.

+help=_("If a git mirror gets to big, allow the archive 
to be deleted"))

That first "to" should be "too" - i.e. "gets too big".

Regards,

Adam

Bug#935900: RFS: z3 4.8.4-0.1 [NMU]

[Matthew Fernandez]

> On Aug 27, 2019, at 08:48, Fabian Wolff  wrote:
> 
> On 8/27/19 4:00 PM, Matthew Fernandez wrote:
>>> z3 (4.8.4-0.1) unstable; urgency=medium
>> 
>> I am not a z3 dev, but the latest z3 release is 4.8.5. Is there a
>> particular motivation for uploading a 4.8.4-based release?
> 
> Thanks for pointing this out; I did not notice this, because I was
> using uscan, and upstream suddenly changed the tag format on Github for
> tagging new releases:
> 
>  https://github.com/Z3Prover/z3/tags 

Ah, I was not aware of this either, so we both learned something :)

> In the last hour or so, I have tried to import version 4.8.5, but they
> apparently changed something in the build system so that building with
> Mono no longer works (it fails with 'dotnet: Command not found', and I
> don't know what the Mono equivalent of the dotnet command is, or if one
> exists at all).

I’ve built 4.8.5 before, but not the .net bindings which I guess is what you’re 
dealing with. I can attempt this but unfortunately won’t have time in the short 
term.

> So, I'd say having version 4.8.4 is still better than 4.4.1, and if
> someone else wants to give 4.8.5 another try in the future, they can do
> so after this upload.

Agreed. Having 4.8.4 available would be a significant improvement. Thanks!

Bug#924712: crypt() not available _XOPEN_SOURCE is defined

[Francesco Poli]

On Sun, 25 Aug 2019 15:51:21 +0200 Francesco Poli wrote:

> On Sun, 25 Aug 2019 13:46:36 +0200 Florian Weimer wrote:
[...]
> > We provided a solution acceptable to the reporter.  I do not think
> > further action is needed on the glibc side.  The manual page needs to
> > be updated to reflect the change, but that's not part of glibc.
> 
> OK, good.
> Thanks for your prompt reply!
> 
> Why is the bug report being kept open, though?
> Should it be reassigned to package manpages-dev and fixed there?

If you do not object (by the end of August), I can reassign the bug
report to package manpages-dev.



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


pgpqsxlSaUzCX.pgp
Description: PGP signature

Bug#935913: gle-graphics: qgle segfaults when modifying text strings

[Francesco Poli (wintermute)]

Package: gle-graphics
Version: 4.2.5-7+b1
Severity: normal

Hello again!

I found a reproducible segfault in gle-graphics:

  0) start the GUI

 $ qgle

  1) click on "New" in the toolbar

  2) accept the default size by clicking on "OK" in the dialog window

  3) click on "Edit Mode" in the toolbar

  4) click on "Text Tool" in the sidebar

  5) click somewhere on the canvas: the ``X'' string appears

  6) click on the "Pointer Tool" in the sidebar

  7) click on the ``X'' string on the canvas

  8) in the Properties sidepane, double-click on the Value of the
 "Text" Property

  9) enter another string (such as ``foo'') and press [Enter]
 on the keyboard

If you manage to get here, you should see an application crash
with the following output in the terminal:

  Script:
  size 12.0 12.0
  
  GLE 4.2.5[gle-GjwQeU.gle]-C-R-[gle-3XcUnT][.eps]
  GLE 4.2.5[gle-GjwQeU.gle]-C-R-[gle-sXinOo][.eps]
  Segmentation fault

and the following error in /var/log/kern.log:

  traps: qgle[4876] general protection fault ip:7f3a56129a4f sp:7ffcb0605670 
error:0 in libgs.so.9.27[7f3a55ee+357000]


Please note that the segfault may even happen at an earlier step...


Please investigate and fix the bug and/or forward my report upstream,
as appropriate.

Thanks for your time!
Bye.


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

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

Versions of packages gle-graphics depends on:
ii  libc6   2.28-10
ii  libcairo2   1.16.0-4
ii  libgcc1 1:9.2.1-4
ii  libgl1  1.1.0-1+b1
ii  libglib2.0-02.60.6-2
ii  libglu1-mesa [libglu1]  9.0.0-2.1+b3
ii  libjpeg62-turbo 1:1.5.2-2+b1
ii  libncurses6 6.1+20190803-1
ii  libpng16-16 1.6.37-1
ii  libpoppler-glib80.71.0-5+b1
ii  libqt4-network  4:4.8.7+dfsg-19
ii  libqt4-opengl   4:4.8.7+dfsg-19
ii  libqtcore4  4:4.8.7+dfsg-19
ii  libqtgui4   4:4.8.7+dfsg-19
ii  libstdc++6  9.2.1-4
ii  libtiff54.0.10+git190818-1
ii  libtinfo6   6.1+20190803-1
ii  zlib1g  1:1.2.11.dfsg-1+b1

Versions of packages gle-graphics recommends:
pn  gle-graphics-doc  
ii  libgs99.27~dfsg-3.1

gle-graphics suggests no packages.

-- no debconf information

Bug#588666: boot message stuck onto next message

[Dmitry Bogatov]

control: tags -1 +fixed-upstream

[2019-08-26 16:32] Jesse Smith 
> On Sun, 25 Aug 2019 16:07:30 + Dmitry Bogatov wrote:
>
> > > > Each line a process sends:
> > > > * should be prefixed by the name of the process that sent it.
> > > > * should end with a newline.
> > >
> > > And (#398269) each line should be either from a process or the kernel,
> > > distinguishable enough.
> > >
> > > I fully agree, that should be basic and not need discussion.
> >
> > Okay, reassigning then.
> >
> > @Jesse, yet another feature request for startpar :)
>
>
> I have added a command line flag (-n) which causes the name of the
> sending process to prefix output, unless the command is interactive.
>
> It looks like this: startpar -n -t 1 process-a process-b
>
> process-a: Starting process...
> process-b: Starting process...
> process-b: Done.
> process-a: Done.
>
> This will be in the next release of startpar. I'm looking at adding a
> newline to the end of output too.

Great. Thank you. Tagged as-needed.
-- 
Note, that I send and fetch email in batch, once in a few days.
Please, mention in body of your reply when you add or remove recepients.

Bug#883014: XIM related

[Changwoo Ryu]

Control: tag -1 + upstream

This also looks like XIM related. I can't reproduce this bug with
ibus-gtk3 installed.

Please note that XIM related issues are nowadays considered as non-supported by
upstream IM frameworks.

Bug#935846: musescore-snapshot: please make the build reproducible

[Thorsten Glaser]

Hi Chris,

>Huh, it appeared to work for me so I wonder what was wrong with my
>testcase. Anyway, I defer to thee. :)

oh, interesting… I’ve been told that cmake has a tar builtin,
which doesn’t do these options… perhaps it calls out to the
system-wide tar if one exists (in which case the patch is not
upstreamable).

I’ll have a look when I have the time.

Thanks,
//mirabilos
-- 
 Beware of ritual lest you forget the meaning behind it.
 yeah but it means if you really care about something, don't
ritualise it, or you will lose it. don't fetishise it, don't
obsess. or you'll forget why you love it in the first place.

Bug#935698: amule-utils-gui: amulegui crashing with current libwxgtk3.0-0v5 3.0.4+dfsg-9 and friends

[Martintxo]

OK. Many thanks for you response Bernhard.

Today I find some time for make this.

I installed the following packages:

ii  amule  1:2.3.2-5+b1
ii  amule-common   1:2.3.2-5 
ii  amule-daemon1:2.3.2-5+b1
ii  amule-emc   0.5.2-4+b1
ii  amule-gnome-support1:2.3.2-5 all
ii  amule-utils1:2.3.2-5+b1
ii  amule-utils-gui 1:2.3.2-5+b1
ii  amule-utils-gui-dbgsym 1:2.3.2-5+b1

ii  libwxbase3.0-0v5:amd64 3.0.4+dfsg-9
ii  libwxbase3.0-0v5-dbgsym:amd643.0.4+dfsg-9
ii  libwxgtk-media3.0-gtk3-0v5:amd64  3.0.4+dfsg-9
ii  libwxgtk3.0-0v5:amd643.0.4+dfsg-9 
ii  libwxgtk3.0-0v5-dbgsym:amd64 3.0.4+dfsg-9
ii  libwxgtk3.0-gtk3-0v5:amd64   3.0.4+dfsg-9 

ii  libgtk2.0-0:amd64  2.24.32-3
ii  libgtk2.0-0-dbgsym:amd64 2.24.32-3
ii  libgtk2.0-bin   2.24.32-3 
ii  libgtk2.0-common 2.24.32-3

ii  libglib2.0-0:amd64 2.60.6-2 
ii  libglib2.0-0-dbgsym:amd64 2.60.6-2 
ii  libglib2.0-bin  2.60.6-2
ii  libglib2.0-data2.60.6-2

And run gdb for the backtrace in the same way than the other day. I now have a
gdb2.txt file of 23,9 Mb. And I cleaned it, cutting the duplicate lines. I
attached the clean file as gdb2-clean.txt. But if you need it, I can send the
whole file too (maybe compresed)...

Finally, this is my environmment:

$ env
SHELL=/bin/bash
QT_ACCESSIBILITY=1
LESS=--ignore-case --long-prompt
LANGUAGE=eu_ES:eu:es_ES:es:en_GB:en
TINT2_BUTTON_PANEL_X2=38
TINT2_BUTTON_PANEL_X1=38
LESS_TERMCAP_se=
LESS_TERMCAP_so=
SSH_AUTH_SOCK=/tmp/ssh-u5F1SJXaKW67/agent.769
TINT2_BUTTON_ALIGNED_Y2=562
SSH_AGENT_PID=817
TINT2_BUTTON_ALIGNED_Y1=532
XDG_SEAT=seat0
PWD=/home/martintxo
LOGNAME=martintxo
QT_QPA_PLATFORMTHEME=qt5ct
XDG_SESSION_TYPE=Icewm
TINT2_BUTTON_W=30
GPG_AGENT_INFO=/run/user/1000/gnupg/S.gpg-agent:0:1
TINT2_BUTTON_X=14
TINT2_BUTTON_Y=14
TINT2_BUTTON_H=30
XAUTHORITY=/home/martintxo/.Xauthority
TINT2_CONFIG=/home/martintxo/.config/tint2/tint2rc-botonbar
WINDOWPATH=1
LD_PRELOAD=libgtk3-nocsd.so.0
GTK2_RC_FILES=/home/martintxo/.gtkrc-2.0
HOME=/home/martintxo
LANG=eu_ES.UTF-8
LS_COLORS=rs=0:di=01;34:ln=01;36:mh=00:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=40;31;01:mi=00:su=37;41:sg=30;43:ca=30;41:tw=30;42:ow=34;42:st=37;44:ex=01;32:*.tar=01;31:*.tgz=01;31:*.arc=01;31:*.arj=01;31:*.taz=01;31:*.lha=01;31:*.lz4=01;31:*.lzh=01;31:*.lzma=01;31:*.tlz=01;31:*.txz=01;31:*.tzo=01;31:*.t7z=01;31:*.zip=01;31:*.z=01;31:*.dz=01;31:*.gz=01;31:*.lrz=01;31:*.lz=01;31:*.lzo=01;31:*.xz=01;31:*.zst=01;31:*.tzst=01;31:*.bz2=01;31:*.bz=01;31:*.tbz=01;31:*.tbz2=01;31:*.tz=01;31:*.deb=01;31:*.rpm=01;31:*.jar=01;31:*.war=01;31:*.ear=01;31:*.sar=01;31:*.rar=01;31:*.alz=01;31:*.ace=01;31:*.zoo=01;31:*.cpio=01;31:*.7z=01;31:*.rz=01;31:*.cab=01;31:*.wim=01;31:*.swm=01;31:*.dwm=01;31:*.esd=01;31:*.jpg=01;35:*.jpeg=01;35:*.mjpg=01;35:*.mjpeg=01;35:*.gif=01;35:*.bmp=01;35:*.pbm=01;35:*.pgm=01;35:*.ppm=01;35:*.tga=01;35:*.xbm=01;35:*.xpm=01;35:*.tif=01;35:*.tiff=01;35:*.png=01;35:*.svg=01;35:*.svgz=01;35:*.mng=01;35:*.pcx=01;35:*.mov=01;35:*.mpg=01;35:*.mpeg=01;35:*.m2v=01;35:*.mkv=01;35:*.webm=01;35:*.ogm=01;35:*.mp4=01;35:*.m4v=01;35:*.mp4v=01;35:*.vob=01;35:*.qt=01;35:*.nuv=01;35:*.wmv=01;35:*.asf=01;35:*.rm=01;35:*.rmvb=01;35:*.flc=01;35:*.avi=01;35:*.fli=01;35:*.flv=01;35:*.gl=01;35:*.dl=01;35:*.xcf=01;35:*.xwd=01;35:*.yuv=01;35:*.cgm=01;35:*.emf=01;35:*.ogv=01;35:*.ogx=01;35:*.aac=00;36:*.au=00;36:*.flac=00;36:*.m4a=00;36:*.mid=00;36:*.midi=00;36:*.mka=00;36:*.mp3=00;36:*.mpc=00;36:*.ogg=00;36:*.ra=00;36:*.wav=00;36:*.oga=00;36:*.opus=00;36:*.spx=00;36:*.xspf=00;36:
XDG_CURRENT_DESKTOP=GNOME
GTK_CSD=0
XDG_SESSION_CLASS=user
TERM=xterm
LESS_TERMCAP_mb=
LESS_TERMCAP_me=
LESS_TERMCAP_md=
G_FILENAME_ENCODING=@locale
USER=martintxo
TINT2_BUTTON_ALIGNED_X1=38
DISPLAY=:0
TINT2_BUTTON_ALIGNED_X2=38
SHLVL=1
LESS_TERMCAP_ue=
LESS_TERMCAP_us=
XDG_VTNR=1
DBUS_SESSION_BUS_PID=737
XDG_SESSION_ID=1
TINT2_BUTTON_PANEL_Y1=0
TINT2_BUTTON_PANEL_Y2=768
XDG_RUNTIME_DIR=/run/user/1000
TINT2_BUTTON_ALIGNED_Y=532
TINT2_BUTTON_ALIGNED_X=38
HUSHLOGIN=FALSE
PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus
MAIL=/var/mail/martintxo
_JAVA_OPTIONS=-Dawt.useSystemAAFontSettings=on -Dswing.aatext=true
-Dswing.defaultlaf=com.sun.java.swing.plaf.gtk.GTKLookAndFeel
-Dswing.crossplatformlaf=com.sun.java.swing.plaf.gtk.GTKLookAndFeel
_=/usr/bin/env

I don't use a desktop environment. I use plain old icewm. Here are my other
settings:

$ neofetch --off
martintxo@fundy 
--- 
OS: Debian GNU/Linux bullseye/sid x86_64 
Host: HP Compaq dc7700 Small Form Factor 
Kernel: 5.2.0-10.3-liquorix-amd64 
Uptime: 1 hour, 9 mins 
Packages: 3148 (dpkg) 
Shell: bash 5.0.3 
Resolution: 1368x768 
WM: IceWM 1.5.5+git20190610 (Linux/x86_64) 
WM Theme: IceClearlooks-mio 
Theme: Clearlooks Compact [GTK2], Clearlooks-Phenix-mio [GTK3] 
Icons: nuoveXT2 [GTK2/3] 

Bug#914704: unreproducible in ibus 1.5.19-4+b1

[Changwoo Ryu]

Control: tag -1 + moreinfo unreproducible

I couldn't reproduce it in GNOME session w/ ibus 1.5.19-4+b1 and ibus-libpinyin.

Bug#935308: buster-pu: package android-sdk-meta/25.0.0+11

[Adam D. Barratt]

Control: tags -1 - moreinfo

On Tue, 2019-08-27 at 09:30 +0200, Hans-Christoph Steiner wrote:
> Adam D. Barratt:
> > Control: tags -1 + moreinfo
> > 
> > On Wed, 2019-08-21 at 15:44 +0200, Hans-Christoph Steiner wrote:
[..]
> This is my first try to start a process to include new device IDs in
> Debian/stable so that these devices work with Debian/stable without
> extra tricks.  There are always new Android devices, which will have
> new device IDs.  I think that if Debian is going to provide

I think you missed the end of that thought.

[...]
> +android-sdk-meta (25.0.0+11~deb10u1) buster; urgency=medium
> > 
> > Such a version should include the changelog for the +11 upload to
> > unstable, and then have a short "rebuild for buster" or similar
> > stanza for ~deb10u1, in the same fashion as one would for
> > backports. The style
> > that you've used is generally used for +10+deb10u1 versioning.
> 
> Thanks for this explanation!  I was looking all over for this.  It
> was not in the manual.

Which manual? Policy doesn't mention stable versioning at all, and
arguably shouldn't get into such specific detail. DevRef's coverage is
somewhat disjointed and tends to get outdated - and doesn't even
mention +debXuY versioning in the stable uploads section, only in
discussions of uploads to the security archive, t-p-u uploads and NMUs.

> So I looked through other packages tagged with
> release.debian.org, and copied what I saw there.  From what I read,
> +deb10u1 is for security updates that are not also in testing/sid,
> and ~deb10u1 is for things also in testing/sid.
> 
> So right now, the changelog entry for 25.0.0+11 in testing and
> 25.0.0+11~deb10u1 in proposed-updated are the exact same, except for
> the date and ~deb10u1.  I figured that 25.0.0+11 would never be in
> buster.

Sort of. The distinction is more whether the update package for stable
is created by starting with the package already in stable and adding
desired changes to that (+debXuY), or takes the package from unstable
and rebuilds that on stable with only changes required to do so applied
(~debXuY). The latter case should necessarily include the changelog
stanza from the unstable upload(s) "as-is", as it represents a fork
from that package.

In some cases those methods may produce packages that are identical
other than the version and which stanzas are included in the changelog.

> Should I make ~deb10u2 to do the changes you describe?

I'm not sure it's worth an upload cycle now that the package is already
in stable-new, just bearing the discussion in mind for the future.

> Seems like the FAQ on this page could be a good place for this to be
> explained:
> https://wiki.debian.org/StableProposedUpdates
> 
> I can edit this discussion into a FAQ there, if you agree.

To be entirely honest, I would rather get the information from the
"bits from SRM" posts, together with some from our "how to be an SRM"
manualette, turned into more formal documentation on release.d.o

We already have too many places that contain outdated, conflicting or
plain incorrect information and I'm not sure that trying to make a wiki
page that hasn't been written or reviewed by the Release Team to be
canonical is a useful approach.

> > >[ Jeff Muizelaar ]
> > >* Add some more Amazon devices
> > >  .
> > >[ Hans-Christoph Steiner ]
> > >* fix DEB_REVISION parsing to work with more than one digit
> > > 
> > 
> > I assume that's this change:
> > 
> > -DEB_REVISION = $(shell echo $(DEB_VERSION) | sed 's,.*\+\([0-9][0-
> > 9]*\).*,\1,')
> > +DEB_REVISION = $(shell echo $(DEB_VERSION) | sed 's,.*+\([0-9][0-
> > 9]*\).*,\1,')
> > 
> > However, I'm confused as to how this corresponds to the
> > description. It removes a match for a literal "+" symbol, but does
> > nothing related to the number of digits involved so far as I can
> > tell.
> 
> sed != PCRE.   By default, sed does not treat + as a special
> character.
>  'sed -E' makes it PCRE.   This was fixed by testing.  The original
> regex was only ever returning a single digit, this returns one or
> more.

Ugh, yeah.

>  I've been writing regexs for over 20 years, and this one took me a
> while to see...

Similarly. This is one of the reasons that I tend to end up writing
horrible RE when using sed, because trying to get it to do what I
expect is more annoying than just hacking something that works
together. But I digress...

[...]
> >  debian/android-sdk.metainfo.xml  |  109 ++
> > 
> > +debian/android-sdk.metainfo.xml  usr/share/metainfo
> > 
> > Is that related to one of the items mentioned in the changelog?
> 
> * document udev rule for providing device access to the console user

OK. "metainfo" didn't sound very documentationey. :-)

Regards,

Adam

Bug#935912: Stack-buffer-overflow in main function

[Hu Jiahui]

Package: apng2gif

Version: <=1.8

When apng2gif runs with a very long parameter(>256) in argv[2]
For example:
in command line:
$ apng2gif a.png `python -c 'print "a"*0x100'`

apng2gif 1.7

*** buffer overflow detected ***: apng2gif terminated
已放弃 (核心已转储)







*There is a stack-buffer-overflow in main function(in apng2gif.cpp)In
fact,this vulnerability affects all versions less than 1.8Download the
sourcecode:https://sourceforge.net/projects/apng2gif/files/1.8/
 then:$ make
CC="clang -fsanitize=address"$ ./apng2gif a.png `python -c 'print
"a"*0x100'`Output:*
apng2gif 1.8

=
==37921==ERROR: AddressSanitizer: stack-buffer-overflow on address
0x7ffeb22ff840 at pc 0x0046282c bp 0x7ffeb22ff710 sp 0x7ffeb22feec0
WRITE of size 257 at 0x7ffeb22ff840 thread T0
#0 0x46282b  (/home/kirin/apng/apng2gif+0x46282b)
#1 0x51a821  (/home/kirin/apng/apng2gif+0x51a821)
#2 0x7f710b37bb96  (/lib/x86_64-linux-gnu/libc.so.6+0x21b96)
#3 0x41cb39  (/home/kirin/apng/apng2gif+0x41cb39)

Address 0x7ffeb22ff840 is located in stack of thread T0 at offset 288 in
frame
#0 0x51a5cf  (/home/kirin/apng/apng2gif+0x51a5cf)

  This frame has 3 object(s):
[32, 288) 'szOut'
[352, 356) 'num_loops' <== Memory access at offset 288 partially
underflows this variable
[368, 392) 'img' <== Memory access at offset 288 partially underflows
this variable
HINT: this may be a false positive if your program uses some custom stack
unwind mechanism or swapcontext
  (longjmp and C++ exceptions *are* supported)
SUMMARY: AddressSanitizer: stack-buffer-overflow
(/home/kirin/apng/apng2gif+0x46282b)
Shadow bytes around the buggy address:
  0x100056457eb0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x100056457ec0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x100056457ed0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x100056457ee0: 00 00 00 00 f1 f1 f1 f1 00 00 00 00 00 00 00 00
  0x100056457ef0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x100056457f00: 00 00 00 00 00 00 00 00[f2]f2 f2 f2 f2 f2 f2 f2
  0x100056457f10: 04 f2 00 00 00 f3 f3 f3 f3 f3 f3 f3 00 00 00 00
  0x100056457f20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x100056457f30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x100056457f40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x100056457f50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:   00
  Partially addressable: 01 02 03 04 05 06 07
  Heap left redzone:   fa
  Freed heap region:   fd
  Stack left redzone:  f1
  Stack mid redzone:   f2
  Stack right redzone: f3
  Stack after return:  f5
  Stack use after scope:   f8
  Global redzone:  f9
  Global init order:   f6
  Poisoned by user:f7
  Container overflow:  fc
  Array cookie:ac
  Intra object redzone:bb
  ASan internal:   fe
  Left alloca redzone: ca
  Right alloca redzone:cb
==37921==ABORTING


*Analyze:you can see there is a bug when the main function calls strcpy:*
..
if (back_b < 0) back_b = 0;
if (back_b > 255) back_b = 255;
bcolor = (back_r<<16) + (back_g<<8) + back_b;
  }
}
  }
}
else
  if (szOut[0] == 0)
strcpy(szOut, szOpt);
  }
..

*In fact, in the above example:szOpt=[2],and szOut is defined in stack
with size 256so when argv[2] is too lang,it will lead to a
stack-buffer-overflow in main function.*

Bug#721410: PPC / ARM ?

[Sven Eckelmann]

On Saturday, 31 August 2013 12:17:12 CEST you wrote:
> Package: mupen64plus-core
> 
> As per release:
> 
> http://code.google.com/p/mupen64plus/wiki/ReleasePage
> 
> Makefiles: support for ARM, PPC, and MINGW architectures

I just checked the 2.5.9 release and arm + PPC are still not officially 
supported. I was hoping that at least armhf is now considered working. I will 
close this for now with the option that armhf could be added (because it 
should have been matured) after testing. PPC (actually all big endian) still 
seems to be some bigger problem.

Kind regards,   
Sven

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

Bug#934491: libelogind0: failing to switch from systemd to sysvinit-core/elogind results in libsystemd.so.0 disappearing

[Mark Hindley]

Control: block -1 935910

On Thu, Aug 15, 2019 at 08:42:35PM +0100, Mark Hindley wrote:
> > > Unsure if that’s apt or dpkg. Plus, the failing prerm is in systemd,
> > > not in libsystemd0.
> > 
> > I think this is probably dpkg, but it's dpkg being told what to do by
> > apt, so it could be either one causing this. I would have hoped that if
> > systemd.prerm fails, that's a fairly heavy hint that not only is it not
> > OK to remove systemd at this time, it's also not OK to remove systemd's
> > dependencies.

Simon,

I think I have finally got to the bottom of this. As you suspected it is apt's
invocation of dpkg. See #935910.

Mark

Bug#931943: vtk6: FTBFS with PROJ 6

[Sebastiaan Couwenberg]

vtk6 is failing to build with the new proj in unstable as part of the
transition. Please move the fixed packages from experimental to unstable.

Kind Regards,

Bas

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

Bug#935911: librust-uuid+md5-dev/amd64 unsatisfiable Depends: librust-md5-0.6+default-dev

[Steve Langasek]

Source: rust-uuid
Version: 0.7.2-2
Severity: serious
Affects: src:rust-md5
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu eoan

The rust-uuid package depends on a newer rust-md5 than is available in the
Debian archive.

 librust-uuid+md5-dev/amd64 unsatisfiable Depends: librust-md5-0.6+default-dev

Only rust-md5 0.3 is currently available.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature

Bug#935910: apt: Should be less tolerant of dpkg errors when forcing removal

[Mark Hindley]

Package: apt
Version: 1.8.3
Severity: important

Dear apt maintainers,

This report is a result of my investigation of #934491 which shows that when
trying to migrate a sid install from systemd to sysvinit and elogind by the most
obvious route it is possible to break the system in a way that is difficult to
recover with the fairly simple command:

 apt install libpam-elogind sysvinit-core

I think the root cause of the issue is the way apt invokes dpkg when forcing
removals which is not sufficiently responsive to errors.

In this case apt's dpkg commands are:

 echo 'libpam-systemd:amd64 deinstall' | /usr/bin/dpkg --set-selections 
 echo 'systemd-sysv:amd64 deinstall' | /usr/bin/dpkg --set-selections 
 echo 'systemd:amd64 deinstall' | /usr/bin/dpkg --set-selections 
 echo 'libsystemd0:amd64 deinstall' | /usr/bin/dpkg --set-selections 
 /usr/bin/dpkg --status-fd 18 --no-triggers --force-depends --remove 
libpam-systemd:amd64 
 /usr/bin/dpkg --status-fd 18 --no-triggers --unpack --auto-deconfigure 
/var/cache/apt/archives/libpam-elogind_241.3-1+debian1_amd64.deb 
 /usr/bin/dpkg --status-fd 18 --no-triggers --force-depends --remove 
systemd-sysv:amd64 
 /usr/bin/dpkg --status-fd 18 --no-triggers --unpack --auto-deconfigure 
/var/cache/apt/archives/sysvinit-core_2.96~beta-1_amd64.deb 
 /usr/bin/dpkg --status-fd 18 --no-triggers --force-depends --remove 
systemd:amd64 libsystemd0:amd64 
   ^^^ The line above causes the problem ^^^
 /usr/bin/dpkg --status-fd 18 --no-triggers --unpack --auto-deconfigure 
/var/cache/apt/archives/libelogind0_241.3-1+debian1_amd64.deb 
 /usr/bin/dpkg --status-fd 18 --no-triggers --configure libelogind0:amd64 
 /usr/bin/dpkg --status-fd 18 --no-triggers --unpack --auto-deconfigure 
/var/cache/apt/archives/elogind_241.3-1+debian1_amd64.deb 
 /usr/bin/dpkg --status-fd 18 --configure --pending 

The problem is caused by the invocation forcing the removal of systemd and
libsystemd0. If systemd is pid 1 then its prerm will fail to prevent
removal. However, dpkg still continues to remove libsystemd0 as requested
*before* exiting and signalling an error. apt then stops in response to the dpkg
error. The system is then broken as there is no libsystemd.so.0 installed which
apt itself requires.

My solution is to invoke dpkg with --abort-after=1.  The command line

 apt install -o DPkg::Options::="--abort-after=1" install libpam-elogind 
sysvinit-core

no longer breaks a sid systemd system. This means that dpkg exits immediately
after the systemd prerm fails and libsystemd0 remains installed. The
dependencies can then be fixed with apt.

I suggest that --abort-after=1 should be apt's default when forcing package
removal.

Thanks

Mark

Bug#935290: rakudo: FTBFS on amd64

[M. Zhou]

On Tue, 27 Aug 2019 at 15:21, Dominique Dumont  wrote:
>
> On Tuesday, 27 August 2019 10:04:23 CEST Dominique Dumont wrote:
> > Right.. This is the same error than the one showing in the FTBS issue.
> >
> > I guess we need to talk to upstream. They may not have seen this issue yet
> > if they use an older version of libuv.
>
> On the other hand, I'm able to build rakudo 2019-07 on my system with latest
> libuv1.

Have you built it with the root user? The build would pass.
Try to switch to a normal user and it would FTBFS.

If I build this package with root, the resulting package doesn't work correctly:

root@ossbox-lumin ~/D/rakudo# perl6
Unhandled exception: While looking for
'/usr/share/perl6/runtime/perl6.moarvm': no such file or directory

I'm recently too busy to dig into these issues.

> I mean that I've built and installed new moarvm, then built and installed new
> nqp. Then rakudo builds fine.

Yes, that is the correct order, as implied by the verioned B-Ds.

> Mho Zou, can you check on your side if your can build rakudo on your system ?
   ^
This is a Chinese name and the correct spelling is "Mo Zhou".

-- 
Best,

Bug#935887: python3-mapproxy: Change default template_dir and fix capabilities for Python >= 3.6.7

[Sebastiaan Couwenberg]

Control: tags -1 - moreinfo
Control: severity -1 important

I've installed mapproxy on a test server with stretch, it contains the
symlinks as well:

 # find /usr/lib/python2.7/dist-packages/mapproxy/ -type l -exec ls -l {} \;
 lrwxrwxrwx 1 root root 73 Jan  7  2018
/usr/lib/python2.7/dist-packages/mapproxy/test/system/fixture/cache_data
-> ../../../../../../../share/python-mapproxy/test/system/fixture/cache_data
 lrwxrwxrwx 1 root root 49 Jan  7  2018
/usr/lib/python2.7/dist-packages/mapproxy/test/schemas ->
../../../../../share/python-mapproxy/test/schemas
 lrwxrwxrwx 1 root root 54 Jan  7  2018
/usr/lib/python2.7/dist-packages/mapproxy/service/templates ->
../../../../../share/python-mapproxy/service/templates
 lrwxrwxrwx 1 root root 60 Jan  7  2018
/usr/lib/python2.7/dist-packages/mapproxy/image/fonts/DejaVuSans.ttf ->
../../../../../../share/fonts/truetype/dejavu/DejaVuSans.ttf
 lrwxrwxrwx 1 root root 64 Jan  7  2018
/usr/lib/python2.7/dist-packages/mapproxy/image/fonts/DejaVuSansMono.ttf
-> ../../../../../../share/fonts/truetype/dejavu/DejaVuSansMono.ttf

It as successfully serves the demo with your mapproxy.yaml, both the PNG
& Capabilities document.

After the upgrade to buster, the demo still works when using the default
python2.7 packages, python-mapproxy also contains the symlinks:

 # find /usr/lib/python2.7/dist-packages/mapproxy/ -type l -exec ls -l {} \;
 lrwxrwxrwx 1 root root 73 Jan  7  2018
/usr/lib/python2.7/dist-packages/mapproxy/test/system/fixture/cache_data
-> ../../../../../../../share/python-mapproxy/test/system/fixture/cache_data
 lrwxrwxrwx 1 root root 49 Jan  7  2018
/usr/lib/python2.7/dist-packages/mapproxy/test/schemas ->
../../../../../share/python-mapproxy/test/schemas
 lrwxrwxrwx 1 root root 54 Jan  7  2018
/usr/lib/python2.7/dist-packages/mapproxy/service/templates ->
../../../../../share/python-mapproxy/service/templates
 lrwxrwxrwx 1 root root 60 Jul 31  2018
/usr/lib/python2.7/dist-packages/mapproxy/image/fonts/DejaVuSans.ttf ->
../../../../../../share/fonts/truetype/dejavu/DejaVuSans.ttf
 lrwxrwxrwx 1 root root 64 Jul 31  2018
/usr/lib/python2.7/dist-packages/mapproxy/image/fonts/DejaVuSansMono.ttf
-> ../../../../../../share/fonts/truetype/dejavu/DejaVuSansMono.ttf

python3-mapproxy indeed does not:

 # find /usr/lib/python3/dist-packages/mapproxy/ -type l -exec ls -l {} \;
 lrwxrwxrwx 1 root root 60 Jul 31  2018
/usr/lib/python3/dist-packages/mapproxy/image/fonts/DejaVuSans.ttf ->
../../../../../../share/fonts/truetype/dejavu/DejaVuSans.ttf
 lrwxrwxrwx 1 root root 64 Jul 31  2018
/usr/lib/python3/dist-packages/mapproxy/image/fonts/DejaVuSansMono.ttf
-> ../../../../../../share/fonts/truetype/dejavu/DejaVuSansMono.ttf

And hence also cannot run the demo successfully.

I've downgraded the severity of this issue since the defaults still work.

While mapproxy 1.11.1 doesn't contain any related changes, it does
successfully serve the PNG with Python 3 on bullseye (testing). It fails
with an internal error for the Capabilities document:

 TypeError: Extra position arguments: True at line 169 column 3 in file
/usr/lib/python3/dist-packages/mapproxy/service/templates/wms111capabilities.xml

I'll fix this first in unstable by cherry-picking the commit.

Do you really need to run mapproxy with Python 3 on buster?

If not, we can leave the package as it, just use python-mapproxy on
buster (which is installed as a dependency of the mapproxy package).

Otherwise I'll need to prepare a stable update with the commit for the
TypeError and find a fix for the missing symlinks in the python3 package.

Kind Regards,

Bas

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

Bug#917931: XIM only issue

[Changwoo Ryu]

Control: tag -1 + upstream
Control: forwarded -1 https://github.com/ibus/ibus/issues/2073

This can be reproduce only with XIM. Users can just install ibus-gtk3.

Todays, XIM related issues are considered as non-supported ones by
upstream IM frameworks.

Bug#935909: python3-pyqt5: Segmentation fault when switching between image and text with html tags using style sheets

[Danny Milosavljevic]

Package: python3-pyqt5
Version: 5.11.3+dfsg-1+b3
Severity: important

Dear Maintainer,

there is a segmentation fault problem with python3-qt5 and/or qt5 when 
switching between image and text with html tags.

To reproduce,

(1) Use Debian 10 live iso (or any Debian 10; it happened on a finished 
installation as well)
(2) Invoke: sudo apt-get update
(3) Invoke: sudo apt-get install python3-pyqt5
(4) Invoke: cp 
/usr/share/icons/Adwaita/48x48/status/network-wired-disconnected.png .
(or any other png)
(5) Save the text below as "a.py"
(6) Invoke: QT_QPA_PLATFORM=offscreen python3 a.py 1
(7) Wait for 5 seconds
(8) See the segmentation fault

It's very very reproducible for me.

Text:

from PyQt5.QtWidgets import QWidget, QLabel, QApplication
from PyQt5.QtCore import QTimer, QVariant, pyqtSlot


style=\
"""QLabel {
qproperty-alignment: AlignCenter;
min-width: 84px;
min-height: 84px; 
max-width: 84px;
max-height: 84px; 
}
QLabel[state="image"]{
background-image: url(network-wired-disconnected.png);
background-repeat: no-repeat;
background-position: center;
background-color: #ee;
qproperty-text: " ";
}
QLabel[state="text"]{
background-image: none;
background-repeat: no-repeat;
background-position: center;
background-color: #ee;
qproperty-text: "This isanexample";
} 
"""
style2=\
"""QLabel {
qproperty-alignment: AlignCenter;
min-width: 84px;
min-height: 84px; 
max-width: 84px;
max-height: 84px; 
}
QLabel[state="image"]{
background-color: orange;
qproperty-text: "Image";
}
QLabel[state="text"]{
background-color: #ee;
qproperty-text: "This isanexample";
} 
"""
# NO segfault!!
style3=\
"""QLabel {
qproperty-alignment: AlignCenter;
min-width: 84px;
min-height: 84px; 
max-width: 84px;
max-height: 84px; 
}
QLabel[state="image"]{
background-color: orange;
qproperty-text: "Image";
}
QLabel[state="text"]{
background-color: #ee;
qproperty-text: "Text";
} 
"""
style4=\
"""QLabel {
qproperty-alignment: AlignCenter;
border: 1px solid #cc;
border-bottom: 1px solid white;
background-color: #ee;
padding: 2px;
font-size: 15px;
font-family: "free sans";
qproperty-alignment: AlignCenter;
min-width: 84px;
min-height: 84px; 
max-width: 84px;
max-height: 84px; 
}
QLabel[state="image"]{
background-color: orange;
qproperty-text: "Image";
}
QLabel[state="text"]{
background-color: #ee;
qproperty-text: "This is 
aText";
} 
"""
# NO segfault!!
style5=\
"""QLabel {
qproperty-alignment: AlignCenter;
min-width: 84px;
min-height: 84px; 
max-width: 84px;
max-height: 84px; 
}
QLabel[state="image"]{
background-image: url(network-wired-disconnected.png);
background-repeat: no-repeat;
background-position: center;
background-color: #ee;
qproperty-text: " ";
}
QLabel[state="text"]{
background-image: none;
background-repeat: no-repeat;
background-position: center;
background-color: #ee;
qproperty-text: "Text";
}
"""
# Program crashes with "segmentation fault" when
# html-tags are in the label text
# ---
# ---
class LabelDemoWidget(QWidget):
def __init__(self, style=style, parent=None):
QWidget.__init__(self, parent=parent)

self.style=style
self.topLabel=QLabel(self)
self.topLabel.setObjectName("topLabel")
self.label_prop="text"
self.switch={"text":"image","image":"text"}
self.setGeometry(100, 100, 100, 100)
flip=QTimer(self)
flip.setInterval(1000)
flip.timeout.connect(self.new_style)
flip.start()
# ---
@pyqtSlot()
def new_style(self):

self.topLabel.setProperty("state",QVariant(self.switch[self.label_prop]))
self.label_prop=self.switch[self.label_prop]
self.setStyleSheet(self.style)
# ---
if __name__=='__main__':
# usage python3 label_demo.py 0 ... 4
# 2 and 4 cause no segfault
# all others with html-tags in text will crash after some time with segfault
# debian buster (10) with python3 (3.7.3), python3-qt5 (5.11.3) out of the 
box

import sys
app=QApplication(sys.argv)
w = LabelDemoWidget([style, style2, style3, style4, 
style5][int(sys.argv[1])])
w.show()
sys.exit(app.exec_())

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

Kernel: Linux 4.19.0-5-amd64 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages python3-pyqt5 depends on:
ii  libc6 2.28-10
ii  libgcc1 

Bug#786750: pavucontrol: supertuxkart can't change output device

[radiodurans]

Package: pavucontrol
Version: 3.0-4
Followup-For: Bug #786750

Dear Maintainer,

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

   * What led up to the situation?
 
 Playing supertuxkart with an attached USB DAC

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

 I opened Pulse audio control to changed from Built-In Audio to my DAC.
 Clicking on the Built-in audio to change to the DAC, I could select
 the DAC not with mouse, but by hitting space.

 I also tried a suggestion from pulseaudio freenode channel: 
 
https://askubuntu.com/questions/433459/move-audio-stream-from-openal-application-to-different-audio-device
 
 Basically, it was to add a ~/.alsoftrc file with allow-moves = true

   * What was the outcome of this action?

 Upon hitting enter with the DAC select, it reverted back to built-in
 audio for the stream

 Adding the "allow-moves = true"  and restarting also did nothing

   * What outcome did you expect instead?

 DAC setting to be set and audio to start streaming to the DAC -- neither
 happened


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

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

Versions of packages pavucontrol depends on:
ii  libatk1.0-0  2.30.0-2
ii  libatkmm-1.6-1v5 2.28.0-2
ii  libc62.28-10
ii  libcairo-gobject21.16.0-4
ii  libcairo21.16.0-4
ii  libcairomm-1.0-1v5   1.12.2-4
ii  libcanberra-gtk3-0   0.30-7
ii  libcanberra0 0.30-7
ii  libgcc1  1:8.3.0-6
ii  libgdk-pixbuf2.0-0   2.38.1+dfsg-1
ii  libglib2.0-0 2.58.3-2
ii  libglibmm-2.4-1v52.58.0-2
ii  libgtk-3-0   3.24.5-1
ii  libgtkmm-3.0-1v5 3.24.0-2
ii  libpango-1.0-0   1.42.4-7~deb10u1
ii  libpangocairo-1.0-0  1.42.4-7~deb10u1
ii  libpangomm-1.4-1v5   2.42.0-2
ii  libpulse-mainloop-glib0  12.2-4
ii  libpulse012.2-4
ii  libsigc++-2.0-0v52.10.1-2
ii  libstdc++6   8.3.0-6
ii  libx11-6 2:1.6.7-1

Versions of packages pavucontrol recommends:
ii  pulseaudio  12.2-4

pavucontrol suggests no packages.

-- no debconf information

Bug#711774: CVE-2015-3885

[Sven Eckelmann]

On Thursday, 4 June 2015 17:41:01 CEST you wrote:
> I can drop the dcraw support in exactimage. But I want to avoid shipping 
> libraw patches which are not accepted by upstream and then give me even more 
> problems with René.

The different view on libraw vs. dcraw couldn't be solved with upstream (yet). 
I will close this ticket for now but in case someone wants to spend time on 
it, the package is currently marked as RFA (because I don't use it anymore 
myself).

Thanks,
Sven

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

Bug#806219: Build mupen64plus-ui-console everywhere

[Sven Eckelmann]

On Thursday, 26 November 2015 11:20:07 CEST you wrote:
[...]
> But my offer to add Mathieu Malaterre and/or Sérgio Benjamim when they want to
> maintain the "not officially supported" armhf architecture in Debian is still
> open. I've just uploaded the mupen64plus* packages to the pkg-games
> (Debian Games Team) git repositories to have everything under the same team
> umbrella.
> 
> Just tell me and I merge the branch armhf_test in all repositories and add the
> voluntaril(y|ies) to the uploaders.

The offer to add another architecture based on the test code wasn't pursued. I 
will close this ticket now because the original request was not possible to 
fulfill in a sensible way.

Kind regards,
Sven

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

Bug#935900: RFS: z3 4.8.4-0.1 [NMU]

[Fabian Wolff]

On 8/27/19 4:00 PM, Matthew Fernandez wrote:
>> z3 (4.8.4-0.1) unstable; urgency=medium
> 
> I am not a z3 dev, but the latest z3 release is 4.8.5. Is there a
> particular motivation for uploading a 4.8.4-based release?

Thanks for pointing this out; I did not notice this, because I was
using uscan, and upstream suddenly changed the tag format on Github for
tagging new releases:

  https://github.com/Z3Prover/z3/tags

In the last hour or so, I have tried to import version 4.8.5, but they
apparently changed something in the build system so that building with
Mono no longer works (it fails with 'dotnet: Command not found', and I
don't know what the Mono equivalent of the dotnet command is, or if one
exists at all).

So, I'd say having version 4.8.4 is still better than 4.4.1, and if
someone else wants to give 4.8.5 another try in the future, they can do
so after this upload.

Bug#935908: ITP: dmsh -- simple 2D mesh generator inspired by distmesh

[Drew Parsons]

Package: wnpp
Severity: wishlist
Owner: Drew Parsons 

* Package name: python-dmsh
  Version : 0.1.3
  Upstream Author : Nico Schlömer 
* URL : https://github.com/nschloe/dmsh
* License : MIT
  Programming Lang: Python
  Description : simple mesh generator inspired by distmesh

 dmsh: "The worst mesh generator you'll ever use."
 
 Inspired by distmesh, dmsh is slow, requires a lot of memory, and
 isn't terribly robust either.

 On the plus side, it's got a usable interface, is pure Python (and
 hence easily installable on any system), and if it works, it produces
 pretty high-quality meshes.

 Combined with optimesh, dmsh produces the highest-quality 2D meshes
 in the west.

 Example capabilities:
 * Primitives
   - circle, rectangle, polygon
   - halfspace
 * Combinations
   - difference
   - nonconstant edge length
   - union
   - intersection
 * Transformations
   - rotation, translation, scaling
 * Local refinement


A simple-to-use tool for creating 2D meshes. Complements mshr
(which is not actively developed)

To be packaged under the Debian Science team alongside other related
packages by the same author: meshio (mesh file conversion), pygalmesh
(3D meshes)

Some debate about source package name: dmsh? python-dmsh? python3-dmsh?
A quick poll on irc indicates some preference for python-dmsh. Further
debate welcome.

Bug#935290: rakudo: FTBFS on amd64

[Dominique Dumont]

On Tuesday, 27 August 2019 10:04:23 CEST Dominique Dumont wrote:
> Right.. This is the same error than the one showing in the FTBS issue.
> 
> I guess we need to talk to upstream. They may not have seen this issue yet
> if they use an older version of libuv.

On the other hand, I'm able to build rakudo 2019-07 on my system with latest 
libuv1.

I mean that I've built and installed new moarvm, then built and installed new 
nqp. Then rakudo builds fine.

Mho Zou, can you check on your side if your can build rakudo on your system ?

All the best

Dod

Bug#935907: lintian: Build only needed test packages on partial tests

[Felix Lechner]

Hi,

On Tue, Aug 27, 2019 at 8:09 AM Xavier  wrote:
>
> This can be workaround using a "manifest"

That's exactly what is coming.

Bug#935907: lintian: Build only needed test packages on partial tests

[Xavier]

Le 27/08/2019 à 16:54, Chris Lamb a écrit :
> Hi Xavier,
> 
>> an idea to build only needed test packages (and rebuild only needed
>> ones): use a Makefile to detect changes in t/tags/checks.
> 
> I suspect this isn't enough given for production caching in that these
> packages are built using the installed toolchain (see t/bin/build-
> test-packages-if-needed..) but it might be fine locally when you know
> it hasn't changed.
> 
> Regards,

Yes, the idea here is to provide a way to build only related test
packages for lintian contributors.
NB: the makefile detects any change in t/tags source dir except the
removal of a file. This can be workaround using a "manifest"

Bug#934147: geoip-database: Please ship GeoLite2 databases in MMDB format

[Faidon Liambotis]

Hi there,

Thanks Colin for re-raising this! My intention for #885442 was to
include the GeoLite2 *databases* (i.e. MMDB), rather than their data
converted to the legacy GeoIP format. I'll avoid making a mess out of
the BTS though, given we have this bug now :)

On Thu, Aug 08, 2019 at 09:33:27AM +0200, Patrick Matthäi wrote:
> Dont know. Patches would be welcome :)

I'd be happy to help with that. Is the package in git somewhere? I don't
see Vcs-* headers - perhaps you could import it to salsa?

> Then also everything which is required to build the MMDB format has to
> be in buster-backports and stretch-backports-sloppy. It was enough work
> now to get everything to work again on both releases

Could you elaborate a little bit more on why do you think that's a
requirement? As I mentioned repeatedly in #885442, I don't share that
view; I think we should be shipping MMDBs as-is and not building them
out of CSVs. We have no reason to believe that MMDBs are generated out
of CSVs and the most likely scenario is that the opposite holds true.
Moreover, MMDB is openly and freely documented and with reader and
writer implementations in all kinds of languages -- more than what we
can say for most file formats out there.

Regards,
Faidon

Bug#935907: lintian: Build only needed test packages on partial tests

[Felix Lechner]

Hi,

On Tue, Aug 27, 2019 at 7:57 AM Chris Lamb  wrote:
>
> it might be fine locally when you know it hasn't changed.

I have something in the works that will use per-test checksums to
restore behavior that was lost when building was split from testing. I
assure you the current situation is a problem for me.

Kind regards,
Felix

Bug#930775: dialog: fails when window gets resized

[Alex Tsitsimpis]

Hi!

Any feedback on this? I see here [1] that upstream has acknowledged this as a
bug and that it has been fixed in a new upstream release:

2019/07/24
+ modify dlg_will_resize() and dlg_result_key() functions to reduce
  the chance that dialog exits on a SIGWINCH (Debian #930775).

Are there any plans to update the dialog Debian package to include the fix?

[1] https://invisible-island.net/dialog/CHANGES

Thanks,
Alex