Bug#942016: libopencv3.2-java is archtecture: all, but not M-A: foreign

[Лухнов Андрей Олегович]

Package: libopencv3.2-java
Version: 3.2.0+dfsg-6
Severity: important

Dear Maintainer,

for some reason libopencv3.2-java is archtecture: all, but not marked as M-A:
foreign.

this blocks cross-building of packages (or I'm doing something totally wrong).

My package (a private one) depends on libgstreamer-plugins-bad1.0-dev and
everything compiles just fine if I compile for native arch.

but during cross-compilation build-deps installation fails with the following:

The following packages have unmet dependencies:
 libgstreamer-plugins-bad1.0-dev:armel : Depends: libopencv-dev:armel (>=
2.3.0) but it is not going to be installed

which leads me to:

libopencv-dev:armel : Depends: libopencv3.2-java:armel (= 3.2.0+dfsg-6) but it
is not installable
   Recommends: opencv-data:armel but it is not installable

and...

E: Package 'libopencv3.2-java:armel' has no installation candidate

able to reproduce it on buster, bullseye and sid.

May be, it wasn't marked for a reason, but I haven't found it yet.
Any hints would be appreciated!

Best,
Andrey

Bug#941753: bpfcc: New upstream version (0.10.0)

[Ritesh Raj Sarraf]

On Fri, 2019-10-04 at 21:51 +0200, Salvatore Bonaccorso wrote:
> Source: bpfcc
> Severity: wishlist
> 
> Hi 
> 
> there are new upstream version(s) available for bpfcc. Would be great
> to see these uploaded for unstable. 

I worked on one of the past weekends to refresh it. But this version
(0.10.0) is broken as in it fails to build. I will look at it again,
soon.

Ah!! Yes... I do have the build file lying around...


make[3]: Leaving directory '/build/bpfcc-0.10.0/obj-x86_64-linux-gnu'
make -f src/cc/CMakeFiles/bpf-static.dir/build.make 
src/cc/CMakeFiles/bpf-static.dir/build
make[3]: Entering directory '/build/bpfcc-0.10.0/obj-x86_64-linux-gnu'
[  3%] Building C object src/cc/CMakeFiles/bpf-static.dir/libbpf.c.o
cd /build/bpfcc-0.10.0/obj-x86_64-linux-gnu/src/cc && /usr/lib/ccache/cc  
-I/usr/lib/llvm-6.0/include/../tools/clang/include -I/build/bpfcc-0.10.0/src 
-I/build/bpfcc-0.10.0/obj-x86_64-linux-gnu/src 
-I/build/bpfcc-0.10.0/obj-x86_64-linux-gnu/src/cc -I/build/bpfcc-0.10.0/src/cc 
-I/build/bpfcc-0.10.0/obj-x86_64-linux-gnu/src/cc/frontends/b 
-I/build/bpfcc-0.10.0/src/cc/frontends/b 
-I/build/bpfcc-0.10.0/src/cc/frontends/clang -I/usr/lib/llvm-6.0/include 
-I/build/bpfcc-0.10.0/src/cc/libbpf/include 
-I/build/bpfcc-0.10.0/src/cc/libbpf/include/uapi  -g -O2 
-fdebug-prefix-map=/build/bpfcc-0.10.0=. -fstack-protector-strong -Wformat 
-Werror=format-security -no-pie -Wdate-time -D_FORTIFY_SOURCE=2 -Wall -fPIC 
-Wno-unused-result   -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS 
-D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -o 
CMakeFiles/bpf-static.dir/libbpf.c.o   -c /build/bpfcc-0.10.0/src/cc/libbpf.c
/build/bpfcc-0.10.0/src/cc/libbpf.c:55:10: fatal error: libbpf/src/bpf.h: No 
such file or directory
   55 | #include "libbpf/src/bpf.h"
  |  ^~
compilation terminated.
make[3]: *** [src/cc/CMakeFiles/bpf-static.dir/build.make:66: 
src/cc/CMakeFiles/bpf-static.dir/libbpf.c.o] Error 1
make[3]: Leaving directory '/build/bpfcc-0.10.0/obj-x86_64-linux-gnu'
make[2]: *** [CMakeFiles/Makefile2:323: src/cc/CMakeFiles/bpf-static.dir/all] 
Error 2
make[2]: Leaving directory '/build/bpfcc-0.10.0/obj-x86_64-linux-gnu'
make[1]: *** [Makefile:144: all] Error 2
make[1]: Leaving directory '/build/bpfcc-0.10.0/obj-x86_64-linux-gnu'
dh_auto_build: cd obj-x86_64-linux-gnu && make -j1 "INSTALL=install 
--strip-program=true" returned exit code 2
make: *** [debian/rules:13: build] Error 255
dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2
ESC[0mI: copying local configurationESC[0m
ESC[0;31mE: Failed autobuilding of packageESC[0m
ESC[0mI: unmounting /var/cache/apt/archives/ filesystemESC[0m
ESC[0mI: unmounting dev/ptmx filesystemESC[0m
ESC[0mI: unmounting dev/pts filesystemESC[0m
ESC[0mI: unmounting dev/shm filesystemESC[0m
ESC[0mI: unmounting proc filesystemESC[0m
ESC[0mI: unmounting sys filesystemESC[0m
ESC[0mI: cleaning the build env ESC[0m
ESC[0mI: removing directory /tmp//14316 and its subdirectoriesESC[0m



-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System


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

Bug#942015: FTBS: Doesn't compile with upcoming qscintilla 2.11.2

[Gudjon I. Gudjonsson]

Package: qgis
Version: 3.4.12+dfsg-1
Severity: normal
Tags: patch

Dear maintainers

I tried to compile qgis with the upcoming qscintilla 2.11.2 but it failed. 
But the attached patch based on qgis 3.8 seems to solve the problem.

Regards
Gudjon

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

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

Versions of packages qgis depends on:
ii  libc62.29-2
ii  libgcc1  1:9.2.1-8
ii  libgdal20 [gdal-abi-2-4-0]   2.4.2+dfsg-1+b3
ii  libgeos-c1v5 3.7.2-1
ii  libgsl23 2.5+dfsg-6+b1
ii  libqgis-analysis3.4.12   3.4.12+dfsg-1
ii  libqgis-app3.4.123.4.12+dfsg-1
ii  libqgis-core3.4.12   3.4.12+dfsg-1
ii  libqgis-gui3.4.123.4.12+dfsg-1
ii  libqt5core5a 5.11.3+dfsg1-4
ii  libqt5gui5   5.11.3+dfsg1-4
ii  libqt5keychain1  0.9.1-2
ii  libqt5network5   5.11.3+dfsg1-4
ii  libqt5sql5   5.11.3+dfsg1-4
ii  libqt5widgets5   5.11.3+dfsg1-4
ii  libqt5xml5   5.11.3+dfsg1-4
ii  libstdc++6   9.2.1-8
ii  ocl-icd-libopencl1 [libopencl1]  2.2.12-2
ii  python3-qgis 3.4.12+dfsg-1
ii  qgis-common  3.4.12+dfsg-1
ii  qgis-providers   3.4.12+dfsg-1
ii  qt5-image-formats-plugins5.11.3-2

Versions of packages qgis recommends:
ii  qgis-plugin-grass  3.4.12+dfsg-1

Versions of packages qgis suggests:
pn  gpsbabel  
--- src/core/qgsopenclutils.h.orig	2019-10-09 06:41:29.619997213 +0200
+++ src/core/qgsopenclutils.h	2019-10-09 06:39:37.235997642 +0200
@@ -28,7 +28,7 @@
 #else
 #define CL_USE_DEPRECATED_OPENCL_1_1_APIS
 #define CL_HPP_TARGET_OPENCL_VERSION 220
-#define CL_TARGET_OPENCL_VERSION 200
+#define CL_TARGET_OPENCL_VERSION 220
 #endif
 
 #include 

Bug#941823: tabu: cell background colours broken

[Hilmar Preusse]

Control: forwarded -1 
https://github.com/tabu-issues-for-future-maintainer/tabu/issues/13

On 06.10.19 Thorsten Glaser (t...@mirbsd.de) wrote:

> >Is this https://github.com/tabu-issues-for-future-maintainer/tabu/issues/13
> 
> looks like it; note it is a regression against earlier versions.
> 
Marking as known in upstream.

Hilmar


signature.asc
Description: PGP signature

Bug#936798: Please port KisSplice to Python3 (Was: Bug#936798: kissplice: Python2 removal in sid/bullseye)

[LACROIX VINCENT]

Dear Andreas, 
Yes, we have a python 3 version of KisSplice working now. This should 
correspond to version 2.5.0 of KisSplice, which we plan to release in the 
coming months. 
When would be the deadline for updating our debian KisSplice package before 
removal ?
Best,
Vincent

De : Andreas Tille 
Envoyé : mardi 8 octobre 2019 17:23
À : 936...@bugs.debian.org; David Parsons; LACROIX VINCENT
Objet : Please port KisSplice to Python3 (Was: Bug#936798: kissplice: Python2 
removal in sid/bullseye)

Control: forwarded -1 David Parsons , 
vincent.lacr...@univ-lyon1.fr
Control: tags -1 upstream

Hi,

as you might probably know Python2 is End Of Live[1] and Debian is
actively working on removing Python2 code from the distribution.  So
Debian 11 will come without Python2.  This means we will either be
able to port all software packages to Python3 or the package will be
removed.

Do you think it is feasible for you to port KisSplice to Python3?  May be
by using 2to3 which does quite some work automatically?  If you need any
help please do not hesitate to ask.

Kind regards

  Andreas.


[1] https://pythonclock.org/

--
http://fam-tille.de

Bug#934965:

[thomasw]

I'll add a final bit of information. I discovered that the thing that I did 
while troubleshooting  that caused my problem was installing xfce4 but I am not 
sure which dependency causes the problem. One of the dependencies causes the 
mate screensaver to start misbehaving. With xfce4 installed, it takes 5 seconds 
to suspend (this is with me logged into Mate not xfce). When resuming, I am 
prompted to enter my password. After that a few seconds later, my screen reader 
stops talking. I incorrectly thought my sessionwas crashing. By switching away 
with CTRL+ALT+F5 and then CTRL+ALT+F7 to switch back, I am presented with 
another unlock dialog and after entering my password in that one, I can use the 
system again. All that was required here was installing XFCE, I didn't launch 
the session even once on this new install.

Bug#942014: gitmagic: Do you still interested in maintaining this package?

[Joao Eriberto Mota Filho]

Package: gitmagic
Version: 20160304-1
Severity: wishlist

Hi Sebastien,

I noticed since 2016 you didn't upload gitmagic to Debian. Do you still
interested in this package? If not, can I adopt it? I would like to update
and make available all translations. There are several and continuous updates
from upstream.

Cheers,

Eriberto

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

Bug#934965:

[thomasw]

Please disreguard the message I just sent. I did a fresh install of Debian and 
the screen is locking again even with the patch applied from Martin to Mate 
Session Manager. I did all sorts of installing and setting changing when trying 
to troubleshoot the bug with the long pause and mate-session-manager when 
loggin in. I must have goofed something up with all my troubleshooting because 
the screen is locking again and everything is working fine. I apologize for the 
noisy incorrect message a few minutes ago. I assumed that that patch or the new 
version of mate session manager broke something. Feel free to close this.

Bug#942013: lintian: non-consecutive-debian-revision: false positive for NMUs

[Joao Eriberto Mota Filho]

Package: lintian
Version: 2.25.0
Severity: normal

When doing an NMU, lintian doesn't recognise a revision number as consecutive.

X: gitmagic source: non-consecutive-debian-revision 20160304-1 -> 20160304-1.1

I think that this issue is related to same source code portion affecting
#941656.

Regards,

Eriberto

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

Bug#914743: setting metadata

[Diederik de Haas]

Control: forwarded -1 https://bugs.kde.org/show_bug.cgi?id=396980
Control: tag -1 fixed-upstream

Bug#934965:

[thomasw]

On Tue, Oct 8, 2019, at 10:07 AM, thom...@fastmail.cn wrote:
> 
> 
> On Mon, Sep 2, 2019, at 11:08 AM, Mike Gabriel wrote:
> > Hi,
> > 
> > On  Mi 21 Aug 2019 21:22:51 CEST, thomasw wrote:
> > 
> > > Just wonder if anyone was able to reproduce this. This patch is  
> > > adding good functionality (locking the screen before suspend) so  
> > > reverting is not the correct solution. Before I start investigating  
> > > this, I would like to know if it works correctly for some people. I  
> > > have a few friends that run Debian with Mate and everyone that I  
> > > talked to says it regressed for them. Can anyone verify that this  
> > > patch is working correctly for them and not triggering an inhibitor  
> > > timeout? If the new version of this package works correctly for you,  
> > > I would like to try to reason what is different about our  
> > > environments. I guess the easiest way to know is to click suspend  
> > > from the shutdown dialog and see if your machine takes a bit of time  
> > > to suspend. You will also be able to use the machine during the 5  
> > > second delay before suspend.
> > 
> > I have just uploaded mate-screensaver 1.22.1-3 with a revised version  
> > of the unlock_on_suspend patch. Can you check, if the issue has  
> > changed now?
> I can no longer reproduce this. Thanks for fixing!
Seems I spoke too soon. Gnome Keyring was timing out due to its new version 
conflicting with mate-session-manager) and the session was taking a long time 
to start on login. I built mate-session-manager with the latest patch added 
there in salsa from Martin to fix that. My session now takes 5 seconds to 
suspend. I am also now getting a session freeze on resume. I use a screen 
reader Orca and it stops talking so I assume this is what is happening. I am 
not sure what the problem is but wanted to update you with my findings.
> > 
> > Mike
> > -- 
> > 
> > DAS-NETZWERKTEAM
> > c\o Technik- und Ökologiezentrum Eckernförde
> > Mike Gabriel, Marienthaler str. 17, 24340 Eckernförde
> > mobile: +49 (1520) 1976 148
> > landline: +49 (4351) 850 8940
> > 
> > GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
> > mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de
> > 
> >

Bug#942012: /usr/bin/wnpp-alert: please add an option to generate clickable links

[Rogério Brito]

Package: devscripts
Version: 2.19.6
Severity: wishlist
File: /usr/bin/wnpp-alert

Hi.

Due to laziness and my part (and, I suspect, others may also appreciate it),
it would be very nice to have wnpp-alert generate its output as an HTML page
or, at least, with clickable URLs, since I often want to know why a given
package is orphaned or needs help or whatever.

At present, I am using a very dirty Perl one-liner to generate such links,
but it would be nice if something more standard would be available for
everybody.


Thanks for maintaining devscripts,

Rogério Brito.

-- Package-specific info:

--- /etc/devscripts.conf ---

--- ~/.devscripts ---
DEBUILD_PREPEND_PATH=/usr/lib/ccache
DEBUILD_PRESERVE_ENVVARS=CCACHE_DIR

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

Kernel: Linux 5.2.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf-8, LC_CTYPE=pt_BR.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)

Versions of packages devscripts depends on:
ii  dpkg-dev   1.19.7
ii  fakeroot   1.24-1
ii  file   1:5.37-5
ii  gnupg  2.2.17-3
ii  gpgv   2.2.17-3
ii  libc6  2.29-2
ii  libfile-homedir-perl   1.004-1
ii  libfile-which-perl 1.23-1
ii  libipc-run-perl20180523.0-1
ii  libmoo-perl2.003004-2
ii  libstring-shellquote-perl  1.04-1
ii  libwww-perl6.39-1
ii  patchutils 0.3.4-2+b1
ii  perl   5.28.1-6
ii  python33.7.5-1
ii  sensible-utils 0.0.12
ii  wdiff  1.2.2-2+b1

Versions of packages devscripts recommends:
ii  apt 1.8.4
pn  at  
ii  curl7.66.0-1
ii  dctrl-tools 2.24-3+b1
pn  debian-keyring  
ii  dput1.0.3
pn  equivs  
pn  libdistro-info-perl 
ii  libdpkg-perl1.19.7
ii  libencode-locale-perl   1.05-1
pn  libgit-wrapper-perl 
pn  libgitlab-api-v4-perl   
ii  liblist-compare-perl0.53-1
ii  liblwp-protocol-https-perl  6.07-2
ii  libsoap-lite-perl   1.27-1
ii  libtry-tiny-perl0.30-1
ii  liburi-perl 1.76-1
ii  licensecheck3.0.31-3
ii  lintian 2.25.0
ii  man-db  2.8.7-3
ii  patch   2.7.6-6
ii  python3-apt 1.8.4
ii  python3-debian  0.1.36
ii  python3-magic   2:0.4.15-2
ii  python3-requests2.21.0-1
ii  python3-unidiff 0.5.5-2
ii  python3-xdg 0.25-5
ii  strace  4.26-0.2
ii  unzip   6.0-25
ii  wget1.20.3-1+b1
ii  xz-utils5.2.4-1+b1

Versions of packages devscripts suggests:
ii  adequate 0.15.2
pn  autopkgtest  
pn  bls-standalone   
ii  bsd-mailx [mailx]8.1.2-0.20180807cvs-1+b1
ii  build-essential  12.8
pn  check-all-the-things 
pn  cvs-buildpackage 
ii  debhelper12.6.1
pn  devscripts-el
pn  diffoscope   
pn  disorderfs   
pn  dose-extra   
pn  duck 
pn  faketime 
pn  gnuplot  
pn  how-can-i-help   
pn  libauthen-sasl-perl  
pn  libdbd-pg-perl   
ii  libfile-desktopentry-perl0.22-1
pn  libnet-smtps-perl
ii  libterm-size-perl0.209-1+b1
ii  libtimedate-perl 2.3000-2
pn  libyaml-syck-perl
pn  mozilla-devscripts   
ii  mutt 1.10.1-2.1+b1
ii  openssh-client [ssh-client]  1:8.0p1-7
pn  piuparts 
pn  postgresql-client
ii  quilt0.65-3
pn  ratt 
pn  reprotest
pn  svn-buildpackage 
ii  w3m  0.5.3-37+b1

-- no debconf information

-- 
Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFC
http://cynic.cc/blog/ : github.com/rbrito : profiles.google.com/rbrito
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br

Bug#942011: xdg-utils should be smarter when selecting from multiple .deskop files for a mime-type

[Daniel Kahn Gillmor]

Package: xdg-utils
Version: 1.1.3-1
Severity: normal
Control: affects -1 gimp dekstop-file-utils xapers
Control: blocks 525077 by -1

different apps install .desktop files that contain a MimeType entry
that includes the same mime-types.

for example:

0 dkg@alice:~$ grep -l '^MimeType=.*application/pdf' 
/usr/share/applications/*.desktop 
/usr/share/applications/gimp.desktop
/usr/share/applications/libreoffice-draw.desktop
/usr/share/applications/mupdf.desktop
/usr/share/applications/okularApplication_pdf.desktop
/usr/share/applications/org.gnome.Evince.desktop
/usr/share/applications/org.inkscape.Inkscape.desktop
/usr/share/applications/pdf-presenter-console.desktop
0 dkg@alice:~$ 

Since all of these applications *can* handle a pdf file, they are all
right in doing so (i believe it makes it possible for drag-and-drop to
target an icon derived from the .desktop file based on the mime-type
of the dragged object, for example).

Then, /usr/bin/update-desktop-database (from desktop-file-utils)
gathers all these together and makes a list of them in
/usr/share/applications/mimeinfo.cache.  When it does so, it sorts
them ASCIIbetically (for lack of any better sorting technique):

https://sources.debian.org/src/desktop-file-utils/0.24-1/src/update-desktop-database.c/?hl=43#L310

Then, xdg-open reads this file and picks the first one.

This means that on my system, "xdg-open foo.pdf" will launch
/usr/bin/gimp.

That's clearly the wrong choice.

Presumably, on a desktop system like mine, a sensible priority is
something like:

  * evince or ocular (dedicated, full-fledged pdf viewer apps)
  * pdf-presenter-console or mupdf (specialized custom pdf renderers)
  * libreoffice-draw or inkscape or gimp (apps capable of editing single pages 
of a pdf)

The current default (having "xdg-open foo.pdf" launch gimp) is just
not credible or user-friendly (as evident in the now decade-old and
resolved https://bugs.debian.org/525077.  It also affects new projects
like xapers, which delegates opening of pdfs to xdg-open.

I don't know where else these priorities should live if not in
xdg-utils.  In the absence of some more sensible distributed priority
system, i think xdg-utils needs to step up and maintain these
mappings.

This doesn't sound like a fun task, but it's looks like the only way
for xdg-open to do a sensible thing by default, which is presumably
what it is supposed to do.

Thanks for maintaining xdg-utils in debian!

--dkg

-- Package-specific info:
Desktop environment: XDG_CURRENT_DESKTOP=

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

Kernel: Linux 5.2.0-3-amd64 (SMP w/4 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)

xdg-utils depends on no packages.

Versions of packages xdg-utils recommends:
pn  libfile-mimeinfo-perl  
ii  libnet-dbus-perl   1.1.0-6
ii  libx11-protocol-perl   0.56-7
ii  x11-utils  7.7+4
ii  x11-xserver-utils  7.7+8

xdg-utils suggests no packages.

-- no debconf information

Bug#942010: ITP: css-html-js-minify -- css-html-js-minify: A stand-alone, async, cross-platform minifier for the web implemented in Python 3.

[Gabe Livengood]

Package: wnpp
Owner: Gabe Livengood 
Severity: wishlist

* Package name    : css-html-js-minify
  Version : 1.2.0-1
  Upstream Author : Juan Carlos 
* URL : https://github.com/juancarlospaco/css-html-js-minify/
* License : GPL-3 OR LGPL-3
  Programming Lang: Python
  Description : css-html-js-minify: A stand-alone, async,
cross-platform minifier for the web implemented in Python 3.

  css-html-minify is a minification script implemented in Python 3
that allows for fast and easy compression of CSS, JavaScript,
and HTML files. It is dependency free and operates from a single
script file.

  This package helps users create incredibly small minified files
quickly, easily and efficiently. When minified, files are stripped
down to only what is necessary while still remaining valid,
streamlining the original file into one that is smaller and loads
faster. This package aims to bring a fast, verbose minifier made
for website code to Debian.

  In comparison to other packages that also provide minification,
css-html-js-minify is unique in its speed, dependency-free
implementation, simplicity, and compatability with JS, HTML, and
CSS under one roof.

  I plan to maintain this package alone in my free time. Due to
the small size and scope of the project, this should be easy to
do by myself. I do, however, need a sponsor to help me review
the package's standards compliance and upload it to the archive.

-- 
Best, Gabe Livengood




signature.asc
Description: OpenPGP digital signature

Bug#941848: Re: Re: Bug#941848: RFS: ukui-control-center/2.0.0-1 -- utilities to configure the UKUI desktop

[handsome_feng]

Thank you very much!


Okay, Thanks a lot!  :)






在2019年10月09 06时58分，"Adam Borowski"写道：

On Tue, Oct 08, 2019 at 01:11:23AM +0800, 李剑峰 wrote:
> I have added the missing depends to fix this running error, and re-upload it 
> to
> mentors (with the same version 2.0.0-1), could you have a look? 

Alas, because of some transition, the package is not installable at the
moment.  It'd be doable with some kind of a downgrade to testing, but let's
just wait a bit.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ A MAP07 (Dead Simple) raspberry tincture recipe: 0.5l 95% alcohol,
⣾⠁⢠⠒⠀⣿⡁ 1kg raspberries, 0.4kg sugar; put into a big jar for 1 month.
⢿⡄⠘⠷⠚⠋⠀ Filter out and throw away the fruits (can dump them into a cake,
⠈⠳⣄ etc), let the drink age at least 3-6 months.

Bug#941908: Latest upgrade to 3.34.0-2 solved this problem

[william l-k]

We had 5 computer affected by this problem. Every one of them booted
normally into the Gnome shell (one took two tries) after a full-
upgrade.

So as far as I can tell, this problem is solved.

Thanks for the hard work. One day after I submitted the report is
pretty good, even if the changes were made to fix a different bug.

Regards,
William

Bug#819751: Suggestion:Proper thought and real consideration must be given by the media about the impact this report will have on the entire world.

[agnes.weitzman68725]

Greetings of the day! How are things with you? I hope you're doing great and 
find this worth your attention,some serious soul searching.
It's my belief that these revelations were given for us to know the truth and 
choose the right path accordingly.It would be much appreciated if you 
acknowledge that the truth must be known to all and make as much effort as 
possible to promote public awareness of these testimonies.                      
                                                 Fear is the beginning of 
wisdom.Just ponder eternity and no way out
UK mirror newshttps://www.youtube.com/watch?v=_sRgc9NtHQI  ( unwelcome truth )
https://www.youtube.com/watch?v=dWXkBBIaiVc   a trip to hell  ( extremely 
graphic )
http://heavencometrue.com/?lang=eng   ( web site of the Heaven eyewitness  
)

                                                                         
unsubscribe

Bug#819751: Comment:Be reminded that we the public deserves to know about these testimonies so as to make our own judgement,determination.

[agnes.weitzman68725]

Good afternoon there!How are you doing and How is your country these days?I 
hope you're doing pretty good and everything is going on well with you.
 It's my belief that these revelations were given for us to know the truth and 
choose the right path accordingly.It would be much appreciated if you 
acknowledge that the truth must be known to all and make as much effort as 
possible to promote public awareness of these testimonies.                      
                                                 Fear is the beginning of 
wisdom.Just ponder eternity and no way out
UK mirror newshttps://www.youtube.com/watch?v=_sRgc9NtHQI  ( unwelcome truth )
https://www.youtube.com/watch?v=dWXkBBIaiVc   a trip to hell  ( extremely 
graphic )
http://heavencometrue.com/?lang=eng  ( web site of the Heaven eyewitness )

                                                                        
unsubscribe

Bug#819751: Awakening:It is high time all media outlets should recognize that this is the only solution for the world which is on the wrong path.

[agnes.weitzman68725]

Good morning there! How are things with you nowadays?Hope you're doing great 
and it's peaceful,tranquil over there.
 It's my belief that these revelations were given for us to know the truth and 
choose the right path accordingly.It would be much appreciated if you 
acknowledge that the truth must be known to all and make as much effort as 
possible to promote public awareness of these testimonies.                      
                                                  Fear is the beginning of 
wisdom.Just ponder eternity and no way out.UK mirror 
newshttps://www.youtube.com/watch?v=_sRgc9NtHQI  ( unwelcome truth )
https://www.youtube.com/watch?v=dWXkBBIaiVc   a trip to hell  ( extremely 
graphic )http://heavencometrue.com/?lang=eng   ( web site of the Heaven 
eyewitness )

                                                                      
unsubscribe

Bug#876365: Inquiry:Shouldn't the media stop ignoring this info studiously and start to bring the truth to the attention of the public?

[agnes.weitzman68725]

Hello. How are you doing and things in your country these days? Hope you're 
doing very well and it's peaceful over there.
It's my belief that these revelations were given for us to know the truth and 
choose the right path accordingly.It would be much appreciated if you 
acknowledge that the truth must be known to all and make as much effort as 
possible to promote public awareness of these testimonies.                      
                                            Fear is the beginning of 
wisdom.Just ponder eternity and no way out.
 UK mirror newshttps://www.youtube.com/watch?v=_sRgc9NtHQI  ( unwelcome truth )
https://www.youtube.com/watch?v=dWXkBBIaiVca trip to hell  ( extremely 
graphic )http://heavencometrue.com/?lang=eng( web site of the Heaven 
eyewitness )

                                                                      
unsubscribe

Bug#942009: stgit: please make the build reproducible

[Chris Lamb]

forwarded 942009 https://github.com/ctmarinas/stgit/pull/43
thanks

I've forwarded this upstream here:

  https://github.com/ctmarinas/stgit/pull/43


Regards,

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

Bug#941959: python3-pyqt5.qtwebengine: QWebEngineUrlScheme seems not to be exported

[Norbert Preining]

Hi Dmitry,

On Tue, 08 Oct 2019, Dmitry Shachnev wrote:
> That class is only available since Qt 5.12, however right now we ship
> Qt 5.11 in sid. So you need to wait until Qt is updated (see #941093).

Ahh, how could I miss that one ... I only checked the pyqt5 version and
forgot the qt version. Sorry.

> Also, in your import command you have an extra ‘t’. It starts with Q,

Yeah yeah, too strange all these naming ;-)

Thanks for your work on all that!

Norbert

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

Bug#942009: stgit: please make the build reproducible

[Chris Lamb]

Source: stgit
Version: 0.19-1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: randomness
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

Whilst working on the Reproducible Builds effort [0] we noticed
that stgit could not be built reproducibly.

This is because the contents of the dynamically-compiled Bash
completion script was not being generated in a deterministic manner,
as well as the cmdlist.py module.

Patch attached.

 [0] https://reproducible-builds.org/


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
--- a/debian/patches/reproducible_build 1969-12-31 16:00:00.0 -0800
--- b/debian/patches/reproducible_build 2019-10-08 16:26:23.686338925 -0700
@@ -0,0 +1,33 @@
+Description: Make the build reproducible
+Author: Chris Lamb 
+Last-Update: 2019-10-08
+
+--- stgit-0.19.orig/stgit/argparse.py
 stgit-0.19/stgit/argparse.py
+@@ -260,7 +260,7 @@ class CompgenBase(object):
+ cmd += ['-A', act]
+ words = self.words(var)
+ if words:
+-cmd += ['-W', '"%s"' % ' '.join(words)]
++cmd += ['-W', '"%s"' % ' '.join(sorted(words))]
+ cmd += ['--', '"%s"' % var]
+ return ' '.join(cmd)
+ 
+@@ -310,4 +310,4 @@ class patch_range(CompgenBase):
+ for e in self.__endpoints:
+ assert not e.actions(var)
+ words |= e.words(var)
+-return set(['$(_patch_range "%s" "%s")' % (' '.join(words), var)])
++return set(['$(_patch_range "%s" "%s")' % (' '.join(sorted(words)), 
var)])
+
+--- stgit-0.19.orig/stgit/commands/__init__.py
 stgit-0.19/stgit/commands/__init__.py
+@@ -63,7 +63,7 @@
+ def py_commands(commands, f):
+ f.write('from __future__ import unicode_literals\n\n')
+ f.write('command_list = {\n')
+-for name, (mod, kind, help) in commands.items():
++for name, (mod, kind, help) in sorted(commands.items()):
+ f.write('%r: (\n' % name)
+ f.write('%r,\n' % mod)
+ f.write('%r,\n' % kind)
--- a/debian/patches/series 2019-10-08 15:32:52.384349390 -0700
--- b/debian/patches/series 2019-10-08 16:15:53.573193060 -0700
@@ -2,3 +2,4 @@
 stg-gitk_bashism
 disable_interactive_test
 Avoid-the-git-error-messages-when-running-stg-outside-of-.patch
+reproducible_build

Bug#942007: please rebuild with GOST support

[Ondřej Surý]

Please note that ECC-GOST (GOST R 34.10-2001) has been superseded
by GOST R 34.10-2012 in [RFC7091].  GOST R 34.10-2012 hasn't been
standardized for use in DNSSEC, so there’s just a little value for most
common scenarios where softhsm2 is usually used (DNSSEC signing).

Ondrej
--
Ondřej Surý
ond...@sury.org



> On 9 Oct 2019, at 00:51, Dmitry Eremin-Solenikov  wrote:
> 
> Package: softhsm2
> Version: 2.5.0-1
> Severity: wishlist
> 
> Could you please rebuild SoftHSM2 with GOST support?
> This requires just building it withlibengine-gost-openssl1.1 installed.
> 
> -- 
> With best wishes
> Dmitry
> 
> -- System Information:
> Debian Release: bullseye/sid
>  APT prefers testing
>  APT policy: (500, 'testing')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 5.2.0-3-amd64 (SMP w/12 CPU cores)
> Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
> Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
> LANGUAGE=en_GB:en (charmap=UTF-8)
> Shell: /bin/sh linked to /usr/bin/bash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> Versions of packages softhsm2 depends on:
> ii  libc62.29-2
> ii  libgcc1  1:9.2.1-8
> ii  libsofthsm2  2.5.0-1
> ii  libsqlite3-0 3.29.0-2
> ii  libssl1.11.1.1d-1
> ii  libstdc++6   9.2.1-8
> ii  softhsm2-common  2.5.0-1
> 
> softhsm2 recommends no packages.
> 
> softhsm2 suggests no packages.
> 
> -- no debconf information
> 

Bug#938952: [debian Buster] [arm64 pinebook] [sysvinit-core] libsoup2.4-1 : Depends: glib-networking (>= 2.32.0) but it is not going to be installed

[Adam Borowski]

On Mon, Oct 07, 2019 at 10:44:12PM +0200, Thorsten Glaser wrote:
> On Mon, 7 Oct 2019, Jean-Marc LACROIX wrote:
> > It seems that now all is ok, because sysvinit is correctly installed on 
> > Debian
> > 10.1
> 
> Yes, but the other packages are not yet ready for elogind
> in Debian 10.anything and never will, because Debian 10.x
> was released in April 2019, and this will not get updated.
> 
> (Backporting elogind once everything works will help, but
> not enough, because other packages hard-depend on (usually)
> libpam-systemd and lack the | logind alternative.)

And that's basically the only problem.

elogind in buster uses a separate libelogind which makes it immune to the
libsystemd alternative problem that haunts unstable.  That makes grabbing
libpam-elogind-compat or bolting it upon buster's libpam-elogind enough
to satisfy dependencies.

I don't remember if that's enough or not for policykit-1 to work adequately,
though.

> If you wish to use elogind, either be prepared to do
> unspeakably evil things (such as editing the internal
> dpkg status database, which I did to great success on
> an RPi last week) or upgrade to unstable (in which the
> only missing piece polkit-qt is).

Editing dpkg status is bad.  An equivs package (which libpam-elogind-compat
essentially is) is a much cleaner option.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ A MAP07 (Dead Simple) raspberry tincture recipe: 0.5l 95% alcohol,
⣾⠁⢠⠒⠀⣿⡁ 1kg raspberries, 0.4kg sugar; put into a big jar for 1 month.
⢿⡄⠘⠷⠚⠋⠀ Filter out and throw away the fruits (can dump them into a cake,
⠈⠳⣄ etc), let the drink age at least 3-6 months.

Bug#942008: fwupd: uses SHA-1 for integrity

[brian m. carlson]

Package: fwupd
Version: 1.3.2-1
Severity: normal

When looking at the hashes used to check the integrity of firmware[0],
all of them appear to be using SHA-1.  In addition, the signatures over
the firmware manifests downloaded appear to be using SHA-1 as well.

SHA-1 is considered dangerously weak, and other, better alternatives
have been available for some time.  Fortunately, fwupd supports SHA-256
and SHA-512 as well[1], so it should be easy to switch over.

Much like apt, fwupd should stop using or accepting MD5 or SHA-1 both in
the manifests and signatures and only accept strong alternatives, such
as SHA-2, SHA-3, or BLAKE2.

[0] zcat /var/lib/fwupd/remotes.d/lvfs/metadata.xml.gz | grep checksum | perl 
-pe 's/^.*type="([^"]+)".*$/$1/g' | sort | uniq -c
[1] 
https://github.com/fwupd/fwupd/blob/0917fb6aec177375a2241f57d63e21a71fe19cd6/libfwupd/fwupd-common.

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

Kernel: Linux 5.3.0-trunk-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_WARN
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 fwupd depends on:
ii  libarchive13   3.4.0-1
ii  libc6  2.29-2
ii  libefiboot137-2
ii  libefivar1 37-2
ii  libelf10.176-1.1
ii  libfwupd2  1.3.2-2
ii  libgcab-1.0-0  1.2-5
ii  libglib2.0-0   2.62.1-1
ii  libgnutls303.6.9-5
ii  libgpg-error0  1.36-7
ii  libgpgme11 1.13.1-1
ii  libgudev-1.0-0 233-1
ii  libgusb2   0.3.0-1
ii  libjson-glib-1.0-0 1.4.4-2
ii  libpolkit-gobject-1-0  0.105-26
ii  libsmbios-c2   2.4.1-1
ii  libsoup2.4-1   2.68.1-2
ii  libsqlite3-0   3.30.0-1
ii  libtss2-esys0  2.1.0-4+b1
ii  libxmlb1   0.1.8-1+b1
ii  shared-mime-info   1.10-1

Versions of packages fwupd recommends:
ii  bolt   0.8-4
ii  fwupd-amd64-signed [fwupd-signed]  1.3.2+1
ii  python33.7.5-1

fwupd suggests no packages.

-- Configuration Files:
/etc/fwupd/remotes.d/lvfs-testing.conf changed:
[fwupd Remote]
Enabled=false
Title=Linux Vendor Firmware Service (testing)
Keyring=gpg
MetadataURI=https://cdn.fwupd.org/downloads/firmware-testing.xml.gz
ReportURI=
Username=
Password=
OrderBefore=lvfs,fwupd
ApprovalRequired=false

/etc/fwupd/remotes.d/lvfs.conf changed:
[fwupd Remote]
Enabled=true
Title=Linux Vendor Firmware Service
Keyring=gpg
MetadataURI=https://cdn.fwupd.org/downloads/firmware.xml.gz
ReportURI=
OrderBefore=fwupd
ApprovalRequired=false


-- no debconf information

-- 
brian m. carlson: Houston, Texas, US
OpenPGP: https://keybase.io/bk2204


signature.asc
Description: PGP signature

Bug#941837: texlive-fonts-extra: file conflice with (older) texlive-fonts-extra-links

[Norbert Preining]

On Tue, 08 Oct 2019, Hilmar Preuße wrote:
> Do you have some time to care about this? I'm lost, sorry!

Uploading soon. Rather simple, the BerenisADFProSC fonts were obviously
dropped from Debian, so I reincluded them and they end up in the
texlive-extra-fonts package, while the links previously there are in the
tl-e-f-links package. See git commit 9ab9bb01387f2604a0b65b9677e246be58d29077

Best


Norbert

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

Bug#941848: Re: Bug#941848: RFS: ukui-control-center/2.0.0-1 -- utilities to configure the UKUI desktop

[Adam Borowski]

On Tue, Oct 08, 2019 at 01:11:23AM +0800, 李剑峰 wrote:
> I have added the missing depends to fix this running error, and re-upload it 
> to
> mentors (with the same version 2.0.0-1), could you have a look? 

Alas, because of some transition, the package is not installable at the
moment.  It'd be doable with some kind of a downgrade to testing, but let's
just wait a bit.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ A MAP07 (Dead Simple) raspberry tincture recipe: 0.5l 95% alcohol,
⣾⠁⢠⠒⠀⣿⡁ 1kg raspberries, 0.4kg sugar; put into a big jar for 1 month.
⢿⡄⠘⠷⠚⠋⠀ Filter out and throw away the fruits (can dump them into a cake,
⠈⠳⣄ etc), let the drink age at least 3-6 months.

Bug#941937: apt: Unexpected linkage dependency on libsystemd

[Adam Borowski]

On Mon, Oct 07, 2019 at 09:23:01PM +0200, Julian Andres Klode wrote:
> On Mon, Oct 07, 2019 at 08:22:33PM +0200, Andreas Messer wrote:
> > Would it make sense to use dlopen() to dynamically load libsystemd when 
> > needed
> > and avoid the hard dependency on libsystemd? If systemd is installed, 
> > libsystemd
> > will be available anyways.
> 
> This is too fragile, it broke our udev integration last time for years, hence
> we are not using dlopen() anymore. A simple solution is the best solution.
> 
> We have no intention to change anything in the near future. libsystemd is
> widely available (or libelogind0 is), and is basically essential, is tiny,
> and it's dbus library is the easiest to use.

It's not about not being available in normal use, it's because switching the
library's implementation is fragile -- especially if systemd's prerm fails
which it's notorious to.  This will make apt fail, and apt happens to be the
very package supposed to fix such a problem.
 
> I expect that apt will eventually switch to using libglib's dbus support,
> once we implement a daemon, but that's a bit off, and that stuff might live
> in a separate binary to not pull in libglib on systems that don't need a
> daemon.

Would you accept a patch to move the inhibit function to a small separate
binary?  That'd be a very simple solution.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ A MAP07 (Dead Simple) raspberry tincture recipe: 0.5l 95% alcohol,
⣾⠁⢠⠒⠀⣿⡁ 1kg raspberries, 0.4kg sugar; put into a big jar for 1 month.
⢿⡄⠘⠷⠚⠋⠀ Filter out and throw away the fruits (can dump them into a cake,
⠈⠳⣄ etc), let the drink age at least 3-6 months.

Bug#942007: please rebuild with GOST support

[Dmitry Eremin-Solenikov]

Package: softhsm2
Version: 2.5.0-1
Severity: wishlist

Could you please rebuild SoftHSM2 with GOST support?
This requires just building it with libengine-gost-openssl1.1 installed.

-- 
With best wishes
Dmitry

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

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

Versions of packages softhsm2 depends on:
ii  libc62.29-2
ii  libgcc1  1:9.2.1-8
ii  libsofthsm2  2.5.0-1
ii  libsqlite3-0 3.29.0-2
ii  libssl1.11.1.1d-1
ii  libstdc++6   9.2.1-8
ii  softhsm2-common  2.5.0-1

softhsm2 recommends no packages.

softhsm2 suggests no packages.

-- no debconf information

Bug#942006: squeak-plugins-scratch: please make the build reproducible

[Chris Lamb]

Source: squeak-plugins-scratch
Version: 1.4.0.2~svn.r83-3
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: buildpath
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

Whilst working on the Reproducible Builds effort [0] we noticed
that squeak-plugins-scratch could not be built reproducibly.

This was because the upstream Makefile was not respecting CFLAGS
and/or dpkg-buildflags and thus was missing the -fdebug-prefix-map
GCC argument.

Patch attached.

 [0] https://reproducible-builds.org/


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
--- a/debian/rules  2019-10-08 15:32:45.676295877 -0700
--- b/debian/rules  2019-10-08 15:44:01.846221833 -0700
@@ -3,7 +3,7 @@
 export DH_ALWAYS_EXCLUDE=.svn
 
 LDFLAGS=-Wl,-z,defs -Wl,--as-needed -Wl,--no-undefined
-CFLAGS=-std=gnu89
+CFLAGS=-std=gnu89 $(shell dpkg-buildflags --get CFLAGS)
 
 config: config-stamp
 config-stamp: 

Bug#942005: elph: please make the build reproducible

[Chris Lamb]

Source: elph
Version: 1.0.1-2
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: buildpath
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

Whilst working on the Reproducible Builds effort [0] we noticed
that elph could not be built reproducibly.

This was because the upstream Makefile was not respecting CXXFLAGS and
thus was missing the -fdebug-prefix-map GCC argument.

Patch attached which, as a side-effect, also actually enables the
hardening features [1] that were not being enabled that the "export
DEB_BUILD_MAINT_OPTIONS = hardening=+all" was attempting to do. :)

 [0] https://reproducible-builds.org/
 [1] https://wiki.debian.org/Hardening


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
--- a/debian/patches/reproduciblebuild.patch1969-12-31 16:00:00.0 
-0800
--- b/debian/patches/reproduciblebuild.patch2019-10-08 15:37:18.238576901 
-0700
@@ -0,0 +1,15 @@
+Description: Make the build reproducible
+Author: Chris Lamb 
+Last-Update: 2019-10-08
+
+--- elph-1.0.1.orig/sources/Makefile
 elph-1.0.1/sources/Makefile
+@@ -9,7 +9,7 @@ SYSTYPE := $(shell uname)
+ # C compiler
+ 
+ CXX  := g++
+-CXXLAGS  = -Wall ${SEARCHDIRS} -fno-exceptions -fno-rtti -D_REENTRANT -g
++CXXLAGS  = -Wall ${SEARCHDIRS} -fno-exceptions -fno-rtti -D_REENTRANT -g 
$(shell dpkg-buildflags --get CXXFLAGS)
+ 
+ %.o : %.c
+   ${CXX} ${CXXLAGS} -c $< -o $@
--- a/debian/patches/series 2019-10-08 15:32:38.788241091 -0700
--- b/debian/patches/series 2019-10-08 15:37:17.282568578 -0700
@@ -1 +1,2 @@
 toplevelmakefile.patch
+reproduciblebuild.patch

Bug#941994: quassel-core: do not require execmem

[Felix Geyer]

On 08.10.19 20:57, Christian Göttsche wrote:

Package: quassel-core
Version: 1:0.13.1-1
Severity: wishlist

Currently quassel-core requires the SELinux process permission execmem.

This is not a problem by itself, but for a 24/7 daemon hanging on the
internet it would be nice to not require it.

Maybe there is a way to disable jit/scripting/... at build time?


I assume this is because quassel-core uses QtScript which is the WebKit
JavaScript engine with JIT.

Upstream has removed the QtScript dependency so execmem shouldn't
be necessary anymore with the next upstream major release:
https://github.com/quassel/quassel/pull/506

Felix

Bug#941987: [Pkg-openssl-devel] Bug#941987: libssl1.1: Ciphers AES-*-CBC-HMAC-* are missing in libssl 1.1.1d, but available in 1.1.1c

[Ondřej Surý]

Yes, I can confirm it fixes the PHP case:

# php -r 'var_dump(openssl_get_cipher_methods());' | grep 'aes-.*-hmac'
  string(21) "aes-128-cbc-hmac-sha1"
  string(23) "aes-128-cbc-hmac-sha256"
  string(21) "aes-256-cbc-hmac-sha1"
  string(23) "aes-256-cbc-hmac-sha256”

Ondrej
--
Ondřej Surý
ond...@sury.org



> On 8 Oct 2019, at 22:58, Ondřej Surý  wrote:
> 
> I issued a rebuild in the PPA 
> (https://launchpad.net/~ondrej/+archive/ubuntu/php/) and in the DPA 
> (https://packages.sury.org/php/) with the mentioned patch.
> 
> For Debian, the machine is kind of stuck building arm* builds in qemu, so it 
> might take a longer, but the PPAs should be built under an hour, so I’ll let 
> you know.
> 
> Thanks for pointing to the right direction.
> 
> Ondrej
> --
> Ondřej Surý
> ond...@sury.org
> 
>> On 8 Oct 2019, at 22:51, Kurt Roeckx  wrote:
>> 
>> On Tue, Oct 08, 2019 at 10:15:33PM +0200, Ondřej Surý wrote:
>>> The one package particularly hit by this is PHP.
>>> 
>>> The openssl_get_cipher_methods() function does list the hmac variants with 
>>> 1.1.1c, but it doesn’t with 1.1.1d, so there’s definitely a regression 
>>> somewhere.
>> 
>> Is this something that's fixed by
>> https://github.com/openssl/openssl/pull/10074?
>> 
>> 
>> Kurt
>> 
> 

Bug#942004: INSTALL: buster-backports linux-image 5.2 fails during installation on QNAP TS-219P II

[Robert Schlabbach]

Package: linux-image-5.2.0-0.bpo.2-marvell
Version: 5.2.9-2~bpo10+1

With Debian Buster installed on my QNAP TS-219P II, "aptitude -t 
buster-backports" offers an upgrade to linux-image-5.2.0-0.bpo.2-marvell, which 
fails to install when it comes to flashing the kernel, since the kernel image 
exceeds the available space on the mtd1 partition (2MB). While this is in fact 
documented in the changelog for this package:

  * [armel/marvell] Increase maximum image size (fixes FTBFS):
- This removes support for QNAP TS-109, TS-119, TS-209, TS-219, TS-409,
  and HP Media Vault mv2120
- This may be reverted if we can disable or modularise some features

I would have expected that this upgrade would not be made available on the 
affected devices instead of "wrecking" the installation.

Moreover, I would actually prefer to have this issue fixed so that my QNAP 
TS-219P-II may continue to be supported. Aside from reducing the kernel image 
size, I see at least on my model another possibility:

The QNAP TS219P-II has 16MB of flash in total, which is (AFAIK 
"soft"-)partitioned as:

mtd0: 0.5 MB U-Boot partition
mtd1: 2   MB Kernel partition (vmlinuz)
mtd2: 9   MB RootFS1 partition (initrd.img)
mtd3: 3   MB RootFS2 partition
mtd4: 0.25MB U-Boot Config partition
mtd5: 1.25MB NAS Config partition

I see two possibilities to get more space for the Kernel:

1. Resize mtd1 and mtd2 to 3 and 8 MB, respectively. All the initrd.img's I've 
had were less than 7 MB in size, so mtd2 can give up 1 MB without ill effects. 
This would require changing the device tree which AFAIK defines the partitions 
and sizes, and the U-Boot Config (which can be modified with fw_setenv) to 
change the bootcmd from:

bootcmd=uart1 0x68;cp.l 0xf820 0x80 0x8;cp.l 0xf840 0xa0 
0x24;bootm 0x80

(the first cp.l copies the kernel image from flash to RAM, the second the 
initrd image, with the parameters sourceaddr, destaddr, # of 32-bit words to 
copy)

to:

bootcmd=uart1 0x68;cp.l 0xf820 0x80 0xc;cp.l 0xf850 0xb0 
0x20;bootm 0x80

2. Keep the partitions as they are, but use mtd3 instead of mtd1 for the kernel 
image. This would require changing the kernel flashing tool and the U-Boot 
Config to change the bootcmd to:

bootcmd=uart1 0x68;cp.l 0xf8d0 0x80 0xc;cp.l 0xf840 0xb0 
0x24;bootm 0x80

Both solutions would provide 3 MB space for the kernel image, which should 
suffice for some time...

Bug#942003: libcln-dev: remove unneeded dependencies

[Pino Toscano]

Package: libcln-dev
Version: 1.3.4-4
Severity: minor
Tags: patch

Hi,

libcln-dev depends on some packages which are not strictly needed as
such:
- g++: even though cln is a C++ library, usually -dev packages with
  includes do not require a certain compiler, which is chosen by the
  user
- libc6-dev | libc-dev: as above, usually -dev packages do not require
  the standard C library headers, as they are provided by the libc
- install-info: for few years install-info has been shipping a dpkg
  trigger to automatically run update-info-dir

Patch attached removing them.

Thanks,
-- 
Pino
--- a/debian/control
+++ b/debian/control
@@ -24,7 +24,7 @@ Description: Class Library for Numbers (
 Package: libcln-dev
 Architecture: any
 Section: libdevel
-Depends: g++, libcln6 (= ${binary:Version}), libc6-dev | libc-dev, libgmp-dev, 
install-info, ${misc:Depends}
+Depends: libcln6 (= ${binary:Version}), libgmp-dev, ${misc:Depends}
 Replaces: cln-dev
 Provides: cln-dev
 Conflicts: cln-dev

Bug#941562: python-mox: diff for NMU version 0.7.8-1.1

[Iustin Pop]

On 2019-10-01 20:31:21, Sandro Tosi wrote:
> Package: python-mox
> Version: 0.5.3-5
> Severity: normal
> Tags: patch  pending
> 
> 
> Dear maintainer,
> 
> I've prepared an NMU for python-mox (versioned as 0.7.8-1.1) and
> uploaded it to DELAYED/10. Please feel free to tell me if I
> should delay it longer.

Hi!

Wow, you did all the work, no need to delay. I'll just leave it to enter
the archive as-is.

> pymox is still needed by a handful of packages, and it looks like someone
> picked up upstream duties at https://github.com/ivancrneto/pymox so i prepared
> an NMU to upgrade the packge to 0.7.8, which includes python3 support.

I was sure this was going to be Removal soon, but if it has a new
upstream, by all means.

> all of this so that i will be able to upgrade nsscache from python2 to 
> python3:
> it requires pymox for tests.

Honestly last I looked at mox, the mock library shipped with python was
as good, so maybe a better thing would be to port the unittests. But,
that's a separate thing.

> feel free to re-version it at -1 and upload it directly, and i'll cancel the
> NMU. 

This is now entering the archive in 2 days, I'll leave as such :)

> It would also be great if you'd consider migrating your python packages to
> the DPMT team :)

I'd have to learn what needs to be done first, but given this is already
under debian with righs for all DDs, what would DPMT bring on top?

thanks!
iustin

Bug#941987: [Pkg-openssl-devel] Bug#941987: Bug#941987: libssl1.1: Ciphers AES-*-CBC-HMAC-* are missing in libssl 1.1.1d, but available in 1.1.1c

[Sebastian Andrzej Siewior]

On 2019-10-08 22:51:02 [+0200], Kurt Roeckx wrote:
> On Tue, Oct 08, 2019 at 10:15:33PM +0200, Ondřej Surý wrote:
> > The one package particularly hit by this is PHP.
> > 
> > The openssl_get_cipher_methods() function does list the hmac variants with 
> > 1.1.1c, but it doesn’t with 1.1.1d, so there’s definitely a regression 
> > somewhere.
> 
> Is this something that's fixed by
> https://github.com/openssl/openssl/pull/10074?

| #include 
| 
| static void show_ciphers(const OBJ_NAME *name, void *arg)
| {
| printf("%-25s\n", name->name);
| }
| 
| int main(void)
| {
| if (!OPENSSL_init_ssl(OPENSSL_INIT_ENGINE_ALL_BUILTIN |
|   OPENSSL_INIT_LOAD_CONFIG, NULL))
| return 1;
| 
| printf("Supported:\n");
| OBJ_NAME_do_all_sorted(OBJ_NAME_TYPE_CIPHER_METH, show_ciphers, NULL);
| return 0;
| }

shows 
|$ diff -u c d
|--- c   2019-10-08 23:18:02.336236444 +0200
|+++ d   2019-10-08 23:17:48.064177075 +0200
|@@ -1,7 +1,5 @@
| Supported:
| aes-128-cbc  
|-aes-128-cbc-hmac-sha1
|-aes-128-cbc-hmac-sha256  
| aes-128-ccm  
| aes-128-cfb  
| aes-128-cfb1 
|@@ -23,8 +21,6 @@
| aes-192-ocb  
| aes-192-ofb  
| aes-256-cbc  
|-aes-256-cbc-hmac-sha1
|-aes-256-cbc-hmac-sha256  
| aes-256-ccm  
| aes-256-cfb  
| aes-256-cfb1 

> Kurt

Sebastian

Bug#941980: pod2man: Please convert zero-width space (u200B) to \:

[Russ Allbery]

Jean-Michel Vourgère  writes:

> I'm using pod to generate man files in package rrdtool.

> I had an issue with long man lines such as:
> BIvnameE>=IrrdfileE>:Ids-nameE>:ICFE>[:step=IstepE>][:start=ItimeE>][:end=ItimeE>][:reduce=IBE>][:daemon=IaddressE>]
> that results lintian "manpage-has-errors-from-man": can't break line.

> That I fixed that by inserting unicode zero-width-space characters 200B:
> BIvnameE>=IrrdfileE>:Ids-nameE>:ICFE>[:step=IstepE>][:start=ItimeE>]E<0x200B>[:end=ItimeE>]E<0x200B>[:reduce=IBE>]E<0x200B>[:daemon=IaddressE>]

> I expected pod2man to generate the corect \: escape sequence, but it
> did not.

> Right now, as a work around, I'm using in my make file:
> pod2man ... --utf8 $< | sed -e $$'s|\u200B|:|g' > $@

> This is working great.

> However, it would be nice if pod2man would generate automatically the \:
> escape sequences, so that I don't have to sed the output!

Unfortunately, \: appears to be a groff extension as far as I can tell.
It's at least not mentioned in CSTR 54, nor in other older documentation I
can find for the *roff language.  That means this gets entangled in the
general design constraint that pod2man tries to produce portable *roff
output that's not specific to groff.

I'm not certain this is fully correct because unfortunately it's very
difficult to search for \: to get more data.

Sadly, \& doesn't seem to work here; if it did, this would be easy to fix
in pod2man.

I'll have to think about this a bit and ponder what the best approach
would be.  I'm still considering whether the time has come to just assume
that the output formatter is almost certainly going to be groff or
something compatible with groff and start using more groff-specific logic
(such as assuming that the formatter can handle Unicode output).

-- 
Russ Allbery (r...@debian.org)   

Bug#933217: RM: check-mk -- RoQA, RC-Buggy, unmaintained, no reverse dependency

[Matt Taggart]

On 10/8/19 2:06 PM, Moritz Mühlenhoff wrote:
> On Mon, Sep 30, 2019 at 09:34:46AM -0700, Matt Taggart wrote:
>> Hi,
>>
>>
>> I think it's fine for check-mk to be removed from unstable, if it does
>> end up in Debian again it will be repackaged and should go through NEW
>> again anyway.
> 
> Ack, I've just filed a removal bug. I suppose the version from
> experimental should be removed as well?

Yes.

Thanks,

-- 
Matt Taggart
tagg...@debian.org

Bug#940973: libarchive-zip-perl breaks strip-nondeterminism autopkgtest: error: becoming Archive::Zip::DirectoryMember

[gregor herrmann]

Control: tag -1 - fixed-upstream
COntrol: notforwarded -1

On Tue, 08 Oct 2019 14:10:19 -0700, Chris Lamb wrote:

> This has apparently been fixed (again) upstream in version 1.67:
> 
>   
> https://github.com/redhotpenguin/perl-Archive-Zip/issues/51#issuecomment-539679696

Thanks for the notice but I'm afraid this is a different issue, and
"our" problem is not yet fixed.
(I tried with some of the merge requests earlier, and Salvatore tried
today with the 1.67 release.)

I guess now that 1.67 is out we should open a separate issue upstream
…


Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   


signature.asc
Description: Digital Signature

Bug#940973: libarchive-zip-perl breaks strip-nondeterminism autopkgtest: error: becoming Archive::Zip::DirectoryMember

[Chris Lamb]

tags 940973 + fixed-upstream
thanks

This has apparently been fixed (again) upstream in version 1.67:

  
https://github.com/redhotpenguin/perl-Archive-Zip/issues/51#issuecomment-539679696


Regards,

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

Bug#941979: adequate: ldd -r …: setting effective gid to 32767: Invalid argument at /usr/bin/adequate line 1070

[Thorsten Glaser]

Jakub Wilk dixit:

> * Thorsten Glaser , 2019-10-08, 13:57:
>> setting effective gid to 32767: Invalid argument at /usr/bin/adequate line
>> 1070.
>
> That's probably #941985.

Indeed. Good catch!

Thanks,
//mirabilos
-- 
(gnutls can also be used, but if you are compiling lynx for your own use,
there is no reason to consider using that package)
-- Thomas E. Dickey on the Lynx mailing list, about OpenSSL

Bug#941837: texlive-fonts-extra: file conflice with (older) texlive-fonts-extra-links

[Hilmar Preuße]

On 10/6/19 10:04 AM, Ansgar Burchardt wrote:

Hi Norbert,

> when upgrading in Debian testing I saw the following error message:
> 
> +---
> | Unpacking texlive-fonts-extra (2019.20190930-2) over (2019.20190830-1) ...
> | dpkg: error processing archive 
> /tmp/apt-dpkg-install-h6VDTu/50-texlive-fonts-extra_2019.20190930-2_all.deb 
> (--unpack):
> |  trying to overwrite 
> '/usr/share/texlive/texmf-dist/fonts/opentype/arkandis/berenisadf/BerenisADFProSC-Bold.otf',
>  which is also in package texlive-fonts-extra-links 2019.20190830-1
> | dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
> +---
> 
> It looks like texlive-fonts-extra is missing a (versioned) Replaces on
> texlive-fonts-extra-links.
> 
Do you have some time to care about this? I'm lost, sorry!

Hilmar
-- 
sigfault
#206401 http://counter.li.org



signature.asc
Description: OpenPGP digital signature

Bug#933217: RM: check-mk -- RoQA, RC-Buggy, unmaintained, no reverse dependency

[Moritz Mühlenhoff]

On Mon, Sep 30, 2019 at 09:34:46AM -0700, Matt Taggart wrote:
> Hi,
> 
> 
> I think it's fine for check-mk to be removed from unstable, if it does
> end up in Debian again it will be repackaged and should go through NEW
> again anyway.

Ack, I've just filed a removal bug. I suppose the version from
experimental should be removed as well?

Cheers,
Moritz

Bug#942002: RM: check-mk -- RoQA; RC-buggy

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Please remove check-mk. It's RC-buggy for a long time and needs massive
word to make it suitable for the archive again, the maintainer suggested
to remove it for now in 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=933217#10

Cheers,
Moritz

Bug#941987: [Pkg-openssl-devel] Bug#941987: libssl1.1: Ciphers AES-*-CBC-HMAC-* are missing in libssl 1.1.1d, but available in 1.1.1c

[Ondřej Surý]

I issued a rebuild in the PPA 
(https://launchpad.net/~ondrej/+archive/ubuntu/php/) and in the DPA 
(https://packages.sury.org/php/) with the mentioned patch.

For Debian, the machine is kind of stuck building arm* builds in qemu, so it 
might take a longer, but the PPAs should be built under an hour, so I’ll let 
you know.

Thanks for pointing to the right direction.

Ondrej
--
Ondřej Surý
ond...@sury.org

> On 8 Oct 2019, at 22:51, Kurt Roeckx  wrote:
> 
> On Tue, Oct 08, 2019 at 10:15:33PM +0200, Ondřej Surý wrote:
>> The one package particularly hit by this is PHP.
>> 
>> The openssl_get_cipher_methods() function does list the hmac variants with 
>> 1.1.1c, but it doesn’t with 1.1.1d, so there’s definitely a regression 
>> somewhere.
> 
> Is this something that's fixed by
> https://github.com/openssl/openssl/pull/10074?
> 
> 
> Kurt
> 

Bug#820649: Generation Jesus Christ 05-21-43

[santos]

Это голос восстановления, единственный путь для церковный восторг.
https://yadi.sk/i/79cTZA1Q3aVxzs

Библия Да! Конституция Не!



The voice of restoration, the single door for the ascension of the church.
Bible Yes, Constitution No.
 
 

  34725878

Bug#941987: [Pkg-openssl-devel] Bug#941987: libssl1.1: Ciphers AES-*-CBC-HMAC-* are missing in libssl 1.1.1d, but available in 1.1.1c

[Kurt Roeckx]

On Tue, Oct 08, 2019 at 10:15:33PM +0200, Ondřej Surý wrote:
> The one package particularly hit by this is PHP.
> 
> The openssl_get_cipher_methods() function does list the hmac variants with 
> 1.1.1c, but it doesn’t with 1.1.1d, so there’s definitely a regression 
> somewhere.

Is this something that's fixed by
https://github.com/openssl/openssl/pull/10074?


Kurt

Bug#941987: libssl1.1: Ciphers AES-*-CBC-HMAC-* are missing in libssl 1.1.1d, but available in 1.1.1c

[Ondřej Surý]

The one package particularly hit by this is PHP.

The openssl_get_cipher_methods() function does list the hmac variants with 
1.1.1c, but it doesn’t with 1.1.1d, so there’s definitely a regression 
somewhere.

O.
--
Ondřej Surý 

> On 8 Oct 2019, at 22:12, Sebastian Andrzej Siewior  
> wrote:
> 
> On 2019-10-08 17:35:22 [+0200], Greg wrote:
>> Package: libssl1.1
>> Version: 1.1.1c-1+0~20190710.13+debian10~1.gbp359e02
>> Severity: normal
>> 
>> Dear Maintainer,
>> 
>>* What led up to the situation?
>>Upgraded package libssl1.1 from 1.1.1c to 1.1.1d
>> 
>>* What exactly did you do (or not do) that was effective (or
>>  ineffective)?
>>Downgraded to 1.1.1c
>> 
>>* What was the outcome of this action?
>>4 more ciphers were back
> 
> I am completely lost here. Why is there such a strange version string?
> More importantly *how* do you determine whether or not AES-*-CBC-HMAC-*
> is available?
> 
> Sebastian
> 

Bug#941987: libssl1.1: Ciphers AES-*-CBC-HMAC-* are missing in libssl 1.1.1d, but available in 1.1.1c

[Sebastian Andrzej Siewior]

On 2019-10-08 17:35:22 [+0200], Greg wrote:
> Package: libssl1.1
> Version: 1.1.1c-1+0~20190710.13+debian10~1.gbp359e02
> Severity: normal
> 
> Dear Maintainer,
> 
>    * What led up to the situation?
>    Upgraded package libssl1.1 from 1.1.1c to 1.1.1d
> 
>    * What exactly did you do (or not do) that was effective (or
>  ineffective)?
>    Downgraded to 1.1.1c
> 
>    * What was the outcome of this action?
>    4 more ciphers were back

I am completely lost here. Why is there such a strange version string?
More importantly *how* do you determine whether or not AES-*-CBC-HMAC-*
is available?

Sebastian

Bug#942000: dune-grid build-depends on removed python-vtk6

[Anton Gladky]

Source: dune-grid
Severity: serious

Dear Maintainer,

dune-grid build-depends on the python-vtk6 package, which was dropped
due to the python2-removal.

Please remove the package from build-depends.

Thanks,

Anton

Bug#942001: RM: gmusicbrowser -- ROM; dead upstream, unmaintained, depends on libgtk2-perl

[Sebastian Ramacher]

Package: ftp.debian.org
Severity: normal

Since gmusicbrowser is unmaintained both in Debian and upstream, I don't
expect a fix for #912882 to appear soon. So let's remove the package
from the archive for now.

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#885263: caja-dropbox: Depends on unmaintained pygtk

[mike . gabriel]

Hi,

Am Dienstag, 8. Oktober 2019 schrieb Vlad Orlov:
> Hi,
> 
> The migration to Python 3 and GI had been done in caja-dropbox 1.22.0.
> I guess we can close this

This can only ve closed once the Debian packaging has switched to Py3. I will 
look into that after my VAC.

Mike

-- 
Gesendet von meinem Fairphone2 (powered by Sailfish OS).

Bug#941999: kopanocore: autopkgtest tries to install packages itself but doesn't exit appropriately if that fails

[Paul Gevers]

Source: kopanocore
Version: 8.7.0-3
Severity: serious
X-Debbugs-CC: debian...@lists.debian.org
Tags: sid bullseye
User: debian...@lists.debian.org
Usertags: issue
Control: affects -1 src:perl

Dear maintainers,

With a recent upload of perl the autopkgtest of kopanocore fails in
testing when that autopkgtest is run with the binary packages of perl
from unstable. It passes when run with only packages from testing. In
tabular form:
   passfail
perl   from testing5.30.0-5
kopanocore from testing8.7.0-3
versioned deps [0] from testingfrom unstable
all others from testingfrom testing

I copied some of the output at the bottom of this report. The problem is
that you seem to be installing the mariadb-server package (and others)
in the autopkgtest, such that the test fails if the installation in the
migration setup fails. It seems that some of the (indirect) dependencies
of mariadb-server need to come from unstable with the latest perl
installed. If you really need to install during the autopkgtest (e.g. to
have the pre-seeding work) I suggest you mark this test as skippable (an
autopkgtest restriction) and exit with code 77 in case you can't install
a package.

Currently this regression is blocking the migration of perl to testing [1].

More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul
PS: you may be interested in the hint-testsuite-triggers 'restriction'
and add a testcase with that restriction that depends on mariadb-server,
to make sure that when mariadb-server is updated, your package is also
tested for regressions.

[0] You can see what packages were added from the second line of the log
file quoted below. The migration software adds source package from
unstable to the list if they are needed to install packages from
perl/5.30.0-5. I.e. due to versioned dependencies or breaks/conflicts.
[1] https://qa.debian.org/excuses.php?package=perl

https://ci.debian.net/data/autopkgtest/testing/amd64/k/kopanocore/3120902/log.gz

autopkgtest [19:14:13]: test smoke: [---
###
# Setting up database configuration...#
# Setting up database configuration... done.  #
###

###
# Installing MariaDB server package...#
Reading package lists...
Building dependency tree...
Reading state information...
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 mariadb-server : Depends: mariadb-server-10.3 (>= 1:10.3.18-1) but it
is not going to be installed
E: Unable to correct problems, you have held broken packages.
autopkgtest [19:14:14]: test smoke: ---]



signature.asc
Description: OpenPGP digital signature

Bug#941982: libsys-info-base-perl: missing file Sys/Info.pm

[Vincent Lefevre]

On 2019-10-08 16:03:40 +0200, gregor herrmann wrote:
> On Tue, 08 Oct 2019 15:47:50 +0200, Vincent Lefevre wrote:
> 
> > Package: libsys-info-base-perl
> > Version: 0.7807-2
> > Severity: grave
> > Justification: renders package unusable
> > 
> > I wanted to get the number of CPUs (see Sys::Info::Device::CPU man page),
> > but this fails at "use Sys::Info;":
> > 
> > $ perl -MSys::Info -e ''
> > Can't locate Sys/Info.pm in @INC (you may need to install the Sys::Info 
> > module)
> > [...]
> > 
> > There is no such issue with upstream's module version 0.78
> 
> Note that libsys-info-base-perl is the package for the CPAN
> distribution https://metacpan.org/release/Sys-Info-Base which does
> not contain Sys::Info.

Then it should be provided by a dependency, since it is needed
(see the man page I've mentioned).

> Sys::Info is in https://metacpan.org/release/Sys-Info which
> apparently is currently not available in Debian; maybe this
> should be changed … Interestingly the metadata of Sys-Info-Base don't
> refer to Sys::Info, just some examples in the documentation.

Perhaps something missing in the metadata.

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

Bug#941995: patch puppet-strings manpage

[Louis-Philippe Véronneau]

tag -1 patch

Dear maintainer,

I've made a Merge Request on Salsa [1] to patch this bug.

Cheers!

[1] https://salsa.debian.org/kienan-guest/puppet-strings/merge_requests/2

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




signature.asc
Description: OpenPGP digital signature

Bug#941998: cruft: does not work at alll

[Harry Haller]

Package: cruft
Version: 0.9.38
Severity: normal

Dear Maintainer !


I think, it's apparent, that cruft does not work at all...
Most of the results are completely incorrect. Especially the "missing"-Section
has no valid contents in ponderabel extents - but also the
"unexplained"-section. Once again I have here - on two fresh dist-upgraded
systems - many thousands of missing files. Is it prepared for the package
"usrmerge" ? No need to mention, that most of the "missing" files all exist and
the
"unexplained" files are registered by dpkg...

My call of cruft:
#cruft --ignore "/root /home /mnt /proc /sys /Dummy /Schafott /Pax /dev
/lost+found /opt /run /srv /tmp" -r ~/Cruft.report

Whatever... Sorry, but in most of the debian-doks (especially the release-notes
of each stable-release since many years) there are prominent recommendations to
use this application (cruft & cruft-common). Since more than 10 years (felt)
the debian-users waste their lifetime with this - at best - "sid"-package.
Nothing justifies, that cruft finds it's way always into whatever is stable at
the moment.

Please be consequent and kick it out of the stable releases until it works
(some day in a distant future)...


Best Regards
Harry Haller



-- System Information:
Debian Release: 10.1
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 4.19.0-6-686-pae (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) (ignored: LC_ALL
set to de_DE.UTF-8), LANGUAGE=de (charmap=UTF-8) (ignored: LC_ALL set to
de_DE.UTF-8)
Shell: /bin/sh linked to /usr/bin/bash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages cruft depends on:
ii  cruft-common  0.9.38
ii  file  1:5.35-4
ii  libc6 2.28-10

cruft recommends no packages.

Versions of packages cruft suggests:
ii  bsd-mailx [mailx]  8.1.2-0.20180807cvs-1
pn  cruft-ng   

Bug#938501: Please port smalt to Python3 (Was: Bug#938501: smalt: Python2 removal in sid/bullseye) [EXT]

[Andreas Tille]

Hi James,

thanks for forwarding.  I agree that its probably a small issue
in the Python3 code.  Hope Zemin will be able to fix it soon.
@Zemin: Please feel free to ask for help from our Python team
in case you might run into any trouble.

Kind regards
Andreas.


On Tue, Oct 08, 2019 at 05:24:47PM +0100, James Bonfield wrote:
> Hi all,
> 
> Hannes is still around, but has moved jobs.  I'm including Zemin Ning
> in this reply whose team Hannes was in when he wrote Smalt.
> 
> I don't know the extent of the issue having not used Smalt myself, but
> the main tool itself is C so I doubt the python bit is a major
> component.
> 
> Regardless, it's not something I'm involved with personally.
> 
> James
> 
> 
> On Tue, Oct 08, 2019 at 05:33:42PM +0200, Andreas Tille wrote:
> > Hi again,
> > 
> > I just took James Bonfield in CC since I'm unsure whether my mail might
> > have reached someone who is currently working at sanger.ac.uk.  Just to
> > stretch the importance of the issue have a look at the Python2 EOL clock:
> > 
> >
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__pythonclock.org_=DwIBAg=D7ByGjS34AllFgecYw0iC6Zq7qlm8uclZFI0SqQnqBo=wodoR_G062E4YLZ-xu5t6g=XK--XBUkRyktzXOkgsZpq_yu16VL7H7Y75QlpOEnwGc=1ojoaFsu0HVyuhxGkiUBSnPjQJLSXJQyv1jrE-FfnMw=
> >  
> > 
> > In short: Please be so kind and verify the patch linked below and fix
> > the remaining issues with your deeper knowledge of the code.
> > 
> > Thanks a lot
> > 
> >   Andreas.
> > 
> > 
> > On Thu, Sep 05, 2019 at 03:39:35PM +0200, Andreas Tille wrote:
> > > Control: tags -1 upsteam
> > > Control: forwarded -1 Hannes Ponstingl 
> > > 
> > > Hi Hannes,
> > > 
> > > as you can read below Debian will remove Python2 since it is EOL.
> > > I tried to port your test scripts using the 2to3 tool.  The result
> > > of the automatic conversion can be found here:
> > > 
> > > 
> > > https://urldefense.proofpoint.com/v2/url?u=https-3A__salsa.debian.org_med-2Dteam_smalt_blob_master_debian_patches_2to3.patch=DwIBAg=D7ByGjS34AllFgecYw0iC6Zq7qlm8uclZFI0SqQnqBo=wodoR_G062E4YLZ-xu5t6g=XK--XBUkRyktzXOkgsZpq_yu16VL7H7Y75QlpOEnwGc=j7oR-RSaMB5DM2SvBCK63XeKcftyATF9QB_A56HxSCs=
> > >  
> > > 
> > > Unfortunately there are some remaining issues in the test suite which
> > > are probably not very hard to fix.  I wonder whether you might want
> > > to have a look at these and could prepare an official Python3 release
> > > of your nice tool.
> > > 
> > > Here is the output of the test suite:
> > > 
> > > 
> > > PASS: splitReads_test.py
> > > PASS: results_split_test.py
> > > PASS: ouform_cigar_test.py
> > > Traceback (most recent call last):
> > >   File "./sample_test.py", line 154, in 
> > > compare_mapping(oufilnam1, oufilnam3)
> > >   File "./sample_test.py", line 108, in compare_mapping
> > > if cmp(cig1.qnam, cig2.qnam):
> > > NameError: name 'cmp' is not defined
> > > FAIL: sample_test.py
> > > PASS: cigar_test.py
> > > Discrepancy:
> > > cigar:A:60 SIM_0_MAL11_001337747_10_F_75m/1 1 75 + MAL11 1337747 
> > > 1337821 + 75 M 75
> > > cigar:A:60 SIM_0_MAL11_001337747_10_F_75m/1 1 75 + MAL11 1337747 
> > > 1337821 + 75 M 75
> > > FAIL: mthread_test.py
> > > Traceback (most recent call last):
> > >   File "./ioform_test.py", line 45, in 
> > > samnam = df.unpack(READ_PREFIX + ".sam")
> > >   File "/build/smalt-0.7.6/test/testdata.py", line 71, in unpack
> > > oufil.write(lin)
> > > TypeError: write() argument must be str, not bytes
> > > FAIL: ioform_test.py
> > > PASS: xali_test.py
> > > Traceback (most recent call last):
> > >   File "./bam_cigar_test.py", line 254, in 
> > > isOK = testSAMfilesAreIdentical(sambamnam, samoufilnam)
> > >   File "./bam_cigar_test.py", line 149, in testSAMfilesAreIdentical
> > > linA = infilA.readline()
> > >   File "/usr/lib/python3.7/codecs.py", line 322, in decode
> > > (result, consumed) = self._buffer_decode(data, self.errors, final)
> > > UnicodeDecodeError: 'utf-8' codec can't decode byte 0xff in position 260: 
> > > invalid start byte
> > > FAIL: bam_cigar_test.py
> > > =
> > > 4 of 9 tests failed
> > > Please report to h...@sanger.ac.uk
> > > =
> > > 
> > > 
> > > Kind regards
> > > 
> > >   Andreas.
> > > 
> > > 
> > > On Fri, Aug 30, 2019 at 07:52:50AM +, Matthias Klose wrote:
> > > > Package: src:smalt
> > > > Version: 0.7.6-8
> > > > Severity: normal
> > > > Tags: sid bullseye
> > > > User: debian-pyt...@lists.debian.org
> > > > Usertags: py2removal
> > > > 
> > > > Python2 becomes end-of-live upstream, and Debian aims to remove
> > > > Python2 from the distribution, as discussed in
> > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.debian.org_debian-2Dpython_2019_07_msg00080.html=DwIBAg=D7ByGjS34AllFgecYw0iC6Zq7qlm8uclZFI0SqQnqBo=wodoR_G062E4YLZ-xu5t6g=XK--XBUkRyktzXOkgsZpq_yu16VL7H7Y75QlpOEnwGc=Xgujf6sRlZuNDRpgPdw-HM2EVf1K2YRkzazDPAt9sK4=
> > > >  
> > > > 
> > > > Your 

Bug#941997: barcode: Removing the library affects glabels

[Yavor Doganov]

Package: barcode
Version: 0.99-3
Severity: important
Control: affects -1 glabels

That's basically #914851 but I decided to open a new bug rather than
unarchive the old one.  glabels has been binNMUed recently for the EDS
transition and it no longer provides GNU Barcode support; from its
build log:

| checking for Barcode_Create in -lbarcode... no

I realize this is an upstream decision and I tried to write to
bug-barc...@gnu.org (see below) but my message bounced despite me being
a list subscriber.

* * *
A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:

  barc...@prosa.it
SMTP error from remote mail server after RCPT TO::
host prosa.it [50.57.43.202]: 554 5.1.1 :
Recipient address rejected: User unknown in virtual mailbox table

-- This is a copy of the message, including all the headers. --

Return-path: 
Received: from fencepost.gnu.org ([2001:470:142:3::e]:45198)
by eggs.gnu.org with esmtp (Exim 4.71)
(envelope-from )
id 1iHrmp-bb-UC
for barc...@prosa.it; Tue, 08 Oct 2019 11:52:31 -0400
Received: from yavor.doganov.org ([46.10.101.102]:56540 helo=aneto.localhost)
by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256)
(Exim 4.82)
(envelope-from )
id 1iHrmp-00088A-Ez
for bug-barc...@gnu.org; Tue, 08 Oct 2019 11:52:31 -0400
Date: Tue, 08 Oct 2019 18:52:29 +0300
Message-ID: <87v9sz8caq.GNU's_not_UNIX!-ya...@gnu.org>
From: Yavor Doganov 
To: bug-barc...@gnu.org
Subject: No library provided?
User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue)
 FLIM/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL/10.8 EasyPG/1.0.0 Emacs/26
 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO)
Organization: The GNU Emacs Church (Bulgarian Eparchy)
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset=US-ASCII
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]

Older releases of GNU Barcode included a static library libbarcode.a
and barcode.h which used to be installed in $includedir.  That's no
longer true with the current release (0.99) which unfortunately breaks
software as gLabels which uses the GNU Barcode library.  Some users
(like me) rely on this precise feature.

What was the rationale for removing it?  Is there a chance to ship the
library again with the next release, perhaps as a proper shared
library if the API is considered stable?

I can try to provide a patch if that's all that is needed.
* * *

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

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

Versions of packages barcode depends on:
ii  install-info  6.7.0.dfsg.2-3+b1
ii  libc6 2.29-2
ii  libpaper1 1.1.28+b1

barcode recommends no packages.

Versions of packages barcode suggests:
ii  info  6.7.0.dfsg.2-3+b1

-- no debconf information

Bug#941969: Arch Linux API for getting package information

[Eli Schwartz]

In order to get information about a package, you add "json/" to the link.

So, https://www.archlinux.org/packages/community/x86_64/diffoscope/
becomes https://www.archlinux.org/packages/community/x86_64/diffoscope/json/

Since this hardcodes architecture and repository information, you could
do a search and get json instead.

Given this exact-name search:

https://www.archlinux.org/packages/?name=diffoscope

You can get json like this:

https://www.archlinux.org/packages/search/json/?name=diffoscope

You should generally only get one search result due to the exact-name
search, but if the package is in both the "community" repository and the
"community-testing" repository, you could end up with two results, the
-testing version being newer.

You could either try to check that by hand, or add the search terms

=Core=Extra=Community=Multilib

to hardcode which repos you want to search in.

-- 
Eli Schwartz
Bug Wrangler and Trusted User



signature.asc
Description: OpenPGP digital signature

Bug#941996: openmpi-bin: segfaults with the 'verbs' OFI provider

[Lucas Nussbaum]

Package: openmpi-bin
Version: 3.1.3-11
Severity: serious

Hi,

This is tracked upstream as https://github.com/open-mpi/ompi/issues/7035 .

mpirun segfaults during MTL OFI provider section when run on a machine
with an InfiniBand network. This happens for the following reason: Until
version 3.1.2, OFI used an opt-in mechanism to include providers.
'verbs' wasn't included by default. This was changed by
https://github.com/open-mpi/ompi/commit/d00c387284b6197946452a0938e76615a17fa689

The discussion is still ongoing upstream, but it looks like this might
be related to the libfabric version in Debian.  The chosen solution
upstream might be to disable the 'verbs' provider.

Also, v4.x is not affected.

I believe this should be fixed in stable. Infiniband is common in HPC
clusters, so a broken OpenMPI is of limited use without its support.

Lucas


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

Kernel: Linux 4.19.0-6-amd64 (SMP w/32 CPU cores)
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:en (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 openmpi-bin depends on:
ii  libc62.28-10
ii  libevent-2.1-6   2.1.8-stable-4
ii  libevent-pthreads-2.1-6  2.1.8-stable-4
ii  libhwloc51.11.12-3
ii  libopenmpi3  3.1.3-11
ii  openmpi-common   3.1.3-11
ii  openssh-client [ssh-client]  1:7.9p1-10
ii  zlib1g   1:1.2.11.dfsg-1

Versions of packages openmpi-bin recommends:
ii  libopenmpi-dev  3.1.3-11

Versions of packages openmpi-bin suggests:
ii  gfortran [fortran-compiler]  4:8.3.0-1

-- no debconf information

Bug#941995: Please add a man page

[Louis-Philippe Véronneau]

Package: puppet-strings
Severity: wishlist

Hi!

There is currently no man pages for the "puppet strings" command :(

It would be nice if there was one!

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



signature.asc
Description: OpenPGP digital signature

Bug#941994: quassel-core: do not require execmem

[Christian Göttsche]

Package: quassel-core
Version: 1:0.13.1-1
Severity: wishlist

Currently quassel-core requires the SELinux process permission execmem.

This is not a problem by itself, but for a 24/7 daemon hanging on the
internet it would be nice to not require it.

Maybe there is a way to disable jit/scripting/... at build time?

Best regards
Christian Göttsche



p.s.: info for the case execmem is prohibited:


SELinux denial


type=PROCTITLE msg=audit(10/06/19 18:35:21.946:42) :
proctitle=/usr/bin/quasselcore --configdir=/var/lib/quassel
--logfile=/var/log/quassel/core.log --loglevel=Info --port=4242
--listen=::,0.
type=SYSCALL msg=audit(10/06/19 18:35:21.946:42) : arch=x86_64
syscall=mmap success=no exit=EACCES(Permission denied) a0=0x0
a1=0x8000 a2=PROT_READ|PROT_WRITE|PROT_EXEC
a3=MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE items=0 ppid=1 pid=462
auid=unset uid=quasselcore gid=quassel euid=quasselcore
suid=quasselcore fsuid=quasselcore egid=quassel sgid=quassel
fsgid=quassel tty=(none) ses=unset comm=QThread
exe=/usr/bin/quasselcore subj=system_u:system_r:quasselcore_t:s0
key=(null)
type=AVC msg=audit(10/06/19 18:35:21.946:42) : avc:  denied  { execmem
} for  pid=462 comm=QThread
scontext=system_u:system_r:quasselcore_t:s0
tcontext=system_u:system_r:quasselcore_t:s0 tclass=process
permissive=0


Quassel self-backtrace


Quassel IRC: 0.13.1 3778a12912369eb5add886bb65ca74e9df841744
#  0 quasselcore  0x55eefb383634 0x
#  1 quasselcore  0x55eefb358eba 0x
#  2 quasselcore  0x55eefb388b03 0x
#  3 libQt5Core.so.5  0x7f9b8e2ad463
QMetaObject::activate(QObject*, int, int, void**)
#  4 quasselcore  0x55eefb38495e 0x
#  5 quasselcore  0x55eefb38444d 0x
#  6 libQt5Core.so.5  0x7f9b8e2ad463
QMetaObject::activate(QObject*, int, int, void**)
#  7 libQt5Core.so.5  0x7f9b8e2b8b79
QSocketNotifier::activated(int, QSocketNotifier::QPrivateSignal)
#  8 libQt5Core.so.5  0x7f9b8e2b8ec1 QSocketNotifier::event(QEvent*)
#  9 libQt5Core.so.5  0x7f9b8e284006
QCoreApplication::notifyInternal2(QObject*, QEvent*)
# 10 libQt5Core.so.5  0x7f9b8e2d5fea 0x
# 11 libglib-2.0.so.0 0x7f9b8d4ecebd g_main_context_dispatch
# 12 libglib-2.0.so.0 0x7f9b8d4ed140 0x
# 13 libglib-2.0.so.0 0x7f9b8d4ed1cf g_main_context_iteration
# 14 libQt5Core.so.5  0x7f9b8e2d53c7
QEventDispatcherGlib::processEvents(QFlags)
# 15 libQt5Core.so.5  0x7f9b8e282cfb
QEventLoop::exec(QFlags)
# 16 libQt5Core.so.5  0x7f9b8e28acd2 QCoreApplication::exec()
# 17 quasselcore  0x55eefb225c8b 0x
# 18 libc.so.60x7f9b8dc8dbbb __libc_start_main
# 19 quasselcore  0x55eefb23154a _start


gdb backtrace


#0  0x77c0a935 in
QTJSC::FixedVMPoolAllocator::FixedVMPoolAllocator
(totalHeapSize=2147483648, commonSize=,
this=0x7002be10)
at 
../3rdparty/javascriptcore/JavaScriptCore/jit/ExecutableAllocatorFixedVMPool.cpp:314
#1  QTJSC::ExecutablePool::systemAlloc (size=size@entry=16384) at
../3rdparty/javascriptcore/JavaScriptCore/jit/ExecutableAllocatorFixedVMPool.cpp:447
#2  0x77c9b9c8 in QTJSC::ExecutablePool::ExecutablePool
(n=16384, this=0x7417e960) at
../3rdparty/javascriptcore/JavaScriptCore/jit/ExecutableAllocator.h:258
#3  QTJSC::ExecutablePool::create (n=16384) at
../3rdparty/javascriptcore/JavaScriptCore/jit/ExecutableAllocator.h:97
#4  QTJSC::ExecutableAllocator::ExecutableAllocator
(this=0x741789c8) at
../3rdparty/javascriptcore/JavaScriptCore/jit/ExecutableAllocator.h:150
#5  QTJSC::JSGlobalData::JSGlobalData (this=0x74177800,
isShared=) at
../3rdparty/javascriptcore/JavaScriptCore/runtime/JSGlobalData.cpp:145
#6  0x77c9be68 in QTJSC::JSGlobalData::create () at
../3rdparty/javascriptcore/JavaScriptCore/wtf/FastAllocBase.h:98
#7  0x77d4440c in QScriptEnginePrivate::QScriptEnginePrivate
(this=0x70004a00) at api/qscriptengine.cpp:989
#8  0x77d44f9f in QScriptEngine::QScriptEngine
(this=0x7000a3c0, parent=0x70005210) at
api/qscriptengine.cpp:2057
#9  0x556047e5 in CoreSession::CoreSession
(this=0x70005210, uid=..., restoreState=,
strictIdentEnabled=, parent=) at
./src/core/coreeventmanager.h:33
#10 0x556555e7 in (anonymous namespace)::Worker::initialize
(this=0x558d3d10) at ./src/core/sessionthread.cpp:48
#11 (anonymous namespace)::Worker::qt_static_metacall
(_o=0x558d3d10, _c=, _id=,
_a=) at
./obj-x86_64-linux-gnu/src/core/mod_core_autogen/include/sessionthread.moc:87
#12 0x777b8463 in QMetaObject::activate(QObject*, int, int,
void**) () from /lib/x86_64-linux-gnu/libQt5Core.so.5
#13 0x775dcde7 in QThread::started(QThread::QPrivateSignal) ()
from /lib/x86_64-linux-gnu/libQt5Core.so.5
#14 0x775e79f0 in ?? () from /lib/x86_64-linux-gnu/libQt5Core.so.5
#15 

Bug#941993: cheese: Pixart Imaging, Inc. Typhoon Easycam USB 330K does no more work with cheese

[Elmar Stellnberger]

Package: cheese
Version: 3.31.90-1
Severity: normal

Dear Maintainer,

Since Debian9 cheese can no more view the video output of my Pixart Imaging,
Inc. Typhoon Easycam USB 330K (newer)/Typhoon Easycam USB 2.0. It works with
cheese and Debian8 and also with a recent version of the program guvcview. This
seems to be a library issue as Firefox and VLC have the same problem.



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

Kernel: Linux 5.1.0 (SMP w/8 CPU cores; PREEMPT)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=de_AT.UTF-8, LC_CTYPE=de_AT.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to de_AT.UTF-8), LANGUAGE=de:pt_BR (charmap=UTF-8) (ignored: LC_ALL set to 
de_AT.UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages cheese depends on:
ii  cheese-common  3.31.90-1
ii  gnome-video-effects0.4.3-3
ii  libc6  2.28-10
ii  libcanberra-gtk3-0 0.30-7
ii  libcheese-gtk253.31.90-1
ii  libcheese8 3.31.90-1
ii  libclutter-1.0-0   1.26.2+dfsg-10
ii  libclutter-gtk-1.0-0   1.8.4-4
ii  libgdk-pixbuf2.0-0 2.38.1+dfsg-1
ii  libglib2.0-0   2.58.3-2
ii  libgnome-desktop-3-17  3.30.2.1-2
ii  libgstreamer1.0-0  1.14.4-1
ii  libgtk-3-0 3.24.5-1

Versions of packages cheese recommends:
ii  gvfs  1.38.1-5
ii  yelp  3.31.90-1

Versions of packages cheese suggests:
pn  gnome-video-effects-frei0r  

-- no debconf information

Bug#934630: transition: octave

[Paul Gevers]

Hi Sébastien,

On 08-10-2019 14:07, Sébastien Villemot wrote:
> All packages concerned by this transition are now fixed, the only
> exception being octave-mpi. For the latter, I suggest that it be
> removed from testing, because the fix is not obvious, and upstream has
> to be involved.

I'll hint it away.

What about the two autopkgtest failures, octave-splines and octave-tsa:
https://qa.debian.org/excuses.php?package=octave

Paul



signature.asc
Description: OpenPGP digital signature

Bug#938884: python-zeitgeist (binary) removal blocked by gtk-doc

[Boyuan Yang]

I'm not going to adopt zeitgeist anytime soon; please feel free to fix bugs
in zeitgeist or push new versions via QA upload.

Best,
Boyuan Yang

Simon McVittie  于2019年10月8日周二 上午4:41写道：
>
> On Sun, 22 Sep 2019 at 17:15:55 +0200, Andreas Henriksson wrote:
> > Once the two applications using python-zeitgeist stops doing that,
> > disabling the use of python2 use in zeitgeist build is still not
> > super trivial. The reason is that zeitgeist needs python(3)-rdflib
> > to generate the onthologies and the configure.ac uses the AM_PATH_PYTHON
> > macro that will find python2 before python3.
>
> It should be possible to add PYTHON=/usr/bin/python3
> to the (dh_auto_)configure command-line (preferred), or
> export it as an environment variable (as was done in 1.0.1-0.1, see
> ;
> this is less preferred than adding it to the configure command line).
> This means the new version of gtk-doc isn't required.
>
> I see Boyuan Yang has imported zeitgeist into
>  and started to update it
> to version 1.0.2. Are you intending to adopt this package? (If not,
> https://salsa.debian.org/debian/zeitgeist/ seems like a good place to
> prepare QA uploads.)
>
> smcv

Bug#938521: Please help packaging new version of spades (Was: Bug#938521: spades: Python2 removal in sid/bullseye)

[Andreas Tille]

Hi,

in the process of Python3 migration I've fixed the spades watch file and
adapted patches to the fact that the code was moved to a subdir
assembler inside the source tree.  Spades build starts so far but the
test fails with an error I have no good explanation for:

   debian/rules override_dh_auto_test
make[1]: Entering directory '/build/spades-3.13.1'
# Ugly hack to make files available for dh_aut_test and autopkgtest
mkdir -p /build/spades-3.13.1/../share/
ln -s /build/spades-3.13.1/install_spades/share/spades 
/build/spades-3.13.1/../share/
ln -s  /usr/bin/bwa /build/spades-3.13.1/install_spades/bin/spades-bwa
/build/spades-3.13.1/install_spades/bin/spades.py --test
Traceback (most recent call last):
  File "/build/spades-3.13.1/install_spades/bin/spades.py", line 38, in 
import yaml as pyyaml
ImportError: No module named yaml
make[1]: *** [debian/rules:61: override_dh_auto_test] Error 1


Seem strange since python3-yaml is installed.  Feel free to finalize
the package whatever changes might be needed.

Kind regards

   Andreas.

-- 
http://fam-tille.de

Bug#941979: adequate: ldd -r …: setting effective gid to 32767: Invalid argument at /usr/bin/adequate line 1070

[Jakub Wilk]

* Thorsten Glaser , 2019-10-08, 13:57:
setting effective gid to 32767: Invalid argument at /usr/bin/adequate 
line 1070.


That's probably #941985.

--
Jakub Wilk

Bug#882851: live-config: Wrong time when RTC is set to local time

[Marcel Partap]

Hey intrigeri et al.,
has anything changed about this situation since a year ago? I am going to 
create >100 debian live-sticks ~tomorrow for school kids out of which probably 
99% will have access to computers running windows with an RTC set to local 
time.. utc=no as boot parameter doesn't quite fix this yet. I think you have 
described the options very well and I also liked your proposal on 914001.. I 
have one day to get it implemented  .. Mind assisting me a bit? 邏
(Best Regards..)

Bug#941749: plasma-workspace: System tray not shown and no panel context menu

[Jonathan Rubenstein]

Package: plasma-workspace
Followup-For: Bug #941749

Hello all,

I concur with Soenke. After upgrading recently, this bug no longer 
exists in version 4:5.14.5.1-3 on testing. It seems like it was a 
dependency problem after all.


Sincerely,
Jonathan

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

Kernel: Linux 5.2.0-3-amd64 (SMP w/12 CPU cores)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=en_US 
(charmap=UTF-8)

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

Versions of packages plasma-workspace depends on:
ii  dbus-user-session [default-dbus-session-bus]  1.12.16-2
ii  dbus-x11 [dbus-session-bus]   1.12.16-2
ii  drkonqi   5.14.5-1
ii  frameworkintegration  5.62.0-1
ii  gdb   8.3-1
ii  iso-codes 4.4-1
ii  kactivitymanagerd 5.14.5-1
ii  kded5 5.62.0-1
ii  kinit 5.62.0-1
ii  kio   5.62.1-1
ii  kpackagetool5 5.62.0-1
ii  kwin-common   4:5.14.5-1
ii  libappstreamqt2   0.12.9-1
ii  libc6 2.29-2
ii  libcolorcorrect5  4:5.14.5.1-3
ii  libgcc1   1:9.2.1-8
ii  libgps23  3.17-7
ii  libice6   2:1.0.9-2
ii  libkf5activities5 5.62.0-1
ii  libkf5authcore5   5.62.0-1
ii  libkf5baloo5  5.62.0-2
ii  libkf5bookmarks5  5.62.0-1
ii  libkf5calendarevents5 5.62.0-1
ii  libkf5completion5 5.62.0-1
ii  libkf5config-bin  5.62.0-1
ii  libkf5configcore5 5.62.0-1
ii  libkf5configgui5  5.62.0-1
ii  libkf5configwidgets5  5.62.0-1
ii  libkf5coreaddons5 5.62.0-1
ii  libkf5crash5  5.62.0-1
ii  libkf5dbusaddons5 5.62.0-1
ii  libkf5declarative55.62.0-1
ii  libkf5globalaccel-bin 5.62.0-1
ii  libkf5globalaccel55.62.0-1
ii  libkf5guiaddons5  5.62.0-1
ii  libkf5holidays5   1:5.62.0-1
ii  libkf5i18n5   5.62.0-1
ii  libkf5iconthemes5 5.62.0-1
ii  libkf5idletime5   5.62.0-1
ii  libkf5itemviews5  5.62.0-1
ii  libkf5jobwidgets5 5.62.0-1
ii  libkf5js5 5.62.0-1
ii  libkf5jsembed55.62.0-1
ii  libkf5kdelibs4support55.62.0-1
ii  libkf5kiocore55.62.1-1
ii  libkf5kiofilewidgets5 5.62.1-1
ii  libkf5kiogui5 5.62.1-1
ii  libkf5kiowidgets5 5.62.1-1
ii  libkf5networkmanagerqt6   5.62.0-1
ii  libkf5newstuff5   5.62.0-1
ii  libkf5notifications5  5.62.0-1
ii  libkf5notifyconfig5   5.62.0-1
ii  libkf5package55.62.0-1
ii  libkf5plasma5 5.62.0-1
ii  libkf5plasmaquick55.62.0-1
ii  libkf5prison5 5.62.0-1
ii  libkf5quickaddons55.62.0-1
ii  libkf5runner5 5.62.0-1
ii  libkf5service-bin 5.62.0-1
ii  libkf5service55.62.0-1
ii  libkf5solid5  5.62.0-2
ii  libkf5texteditor5 5.62.0-1
ii  libkf5textwidgets55.62.0-1
ii  libkf5wallet-bin  5.62.0-1
ii  libkf5wallet5 5.62.0-1
ii  libkf5waylandclient5  4:5.62.0-2
ii  libkf5widgetsaddons5  5.62.0-1
ii  libkf5windowsystem5   5.62.0-2
ii  libkf5xmlgui5 5.62.0-1
ii  libkscreenlocker5 5.14.5-2
ii  libksgrd7 4:5.14.5-1
ii  libkworkspace5-5  4:5.14.5.1-3
ii  libphonon4qt5-4

Bug#941745: Tomb 2.6 provides an important fix

[Sven Geuer]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi Joerg,

thank you for your mail. The bug it is about is #930782 [1], and
fortunately there is a work-around:

> Locking the tomb specifying the valid cipher on the command line
works
>
>$ tomb lock -k x.key -o aes-xts-plain64 x.tomb
>
>[...]
>tomb  .  Done locking x using Luks dm-crypt aes-xts-plain64
>tomb (*) Your tomb is ready in x.tomb and secured with key x.key

This is something different than the luks1/luks2 issue upstream
referred to in [2].

Anyway, tomb 2.6+dfsg1-2~bpo10+1 has already been uploaded to the
backports NEW queue [3] and is awaiting release.

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=930782
[2] https://github.com/dyne/Tomb/blob/master/KNOWN_BUGS.md
[3] https://ftp-master.debian.org/backports-new.html

Sven

Am Dienstag, den 08.10.2019, 13:53 +0200 schrieb Joerg Bornemann:
> On Sun, 06 Oct 2019 22:43:32 +0200 Sven Geuer 
> wrote:
> 
> > Regarding 'important fix for usage of Tomb with cryptsetup 2.1':
> > This seems to refer to [2], 'Issue opening tombs with cryptsetup >
> > 2.0', which is an annoying bug but not a security issue.
> 
> It would be merely an annoying bug if there was a work-around.
> However, 
> this bug makes tomb unusable on buster:
> 
> $ tomb lock secret.tomb -k secret.tomb.key
> tomb  .  Commanded to lock tomb secret.tomb
> tomb  .  Checking if the tomb is empty (we never step on somebody
> else's 
> bones).
> tomb  .  Fine, this tomb seems empty.
> tomb  .  Key is valid.
> tomb  .  Locking using cipher: aes-xts-plain64:sha256
> tomb  .  A password is required to use key secret.tomb.key
> tomb  .  Password OK.
> tomb (*) Locking secret.tomb with secret.tomb.key
> tomb  .  Formatting Luks mapped device.
> tomb [W] cryptsetup luksFormat returned an error.
> tomb [E] Operation aborted.
> 
> I suggest to raise the severity again.
> 
> 
> BR,
> 
> Joerg
> 
> 
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEPfXoqkP8n9/QhvGVrfUO2vit1YUFAl2c0bkACgkQrfUO2vit
1YUG/xAAtqSak1TAuR3CuQGzf6Q4GgCmUS/8I67nb8BIS5NBfGWp/FiD3MowtOJq
a+vgY94JIjQYFcqvgt2/b98GTDHJ7YRKozaX4wAeCKMKyK0wEb2UP/b8LMhInT3m
GRnA3rbUDMsm/1uOSuQJbJ8PQie7ZZ6KgIpLtTt6knukEMdoPwwpey8q9FMa+df3
MczOCx66Kv7lDJ4jD9HyeJx+JfjTe2ibk358Svre+ScYgLA+QFxudKPn5FBj
Xdbx/Fvrs1wHtue4QwBZSDtkVzLDVCrUDsRFtsmh8g3NqxXCpo/zWbQat0VoigPe
HJbhFEHzG25bOimeXKnjeSRLQWtFpw9Xaxkfji1iO7eypnPV0ElBEbamkf3cJ4VY
tvH58RG9KQbcPACd6a4OuHoIV4ZxO+rMoH3PKN0o21e/kOaow1LGhYMdF9lTgfiY
eeY3TRtCxywzQACzasGr8+lMvVePyGp+8KEvM7zGAbrb5ji8JZC6n4A7zq5JQWo0
i2/8EPRhaer3QkxrkTjhdr/5qtC+wulK1xHxESeZl6V8NZlGBYBiXDPgrtY7yguY
wDLZD5XIxBum+WOQNO8Fp03FwX1+zcyIVKO7K31HYjCU6S7Fgy6R89Y7OOunNsvx
4zWnr/nkg6GGloeLJmAfkPBPnIIj/rvzVPSRXfTq5CTdieFSJHw=
=Iyjb
-END PGP SIGNATURE-

Bug#941959: python3-pyqt5.qtwebengine: QWebEngineUrlScheme seems not to be exported

[Dmitry Shachnev]

Hi Norbert!

On Tue, Oct 08, 2019 at 01:23:44PM +0900, Norbert Preining wrote:
> When I try to import QWebEngineUrlScheme I get an error
> $ python3
> >>> from PyQt5.QtWebEngineCore import QtWebEngineUrlScheme
> Traceback (most recent call last):
>   File "", line 1, in 
> ImportError: cannot import name 'QtWebEngineUrlScheme' from 
> 'PyQt5.QtWebEngineCore' 
> (/usr/lib/python3/dist-packages/PyQt5/QtWebEngineCore.cpython-37m-x86_64-linux-gnu.so)
>
> But it seems it should be there since there is also
> /usr/share/sip/PyQt5/QtWebEngineCore/qwebengineurlscheme.sip

That class is only available since Qt 5.12, however right now we ship
Qt 5.11 in sid. So you need to wait until Qt is updated (see #941093).

Also, in your import command you have an extra ‘t’. It starts with Q,
not with Qt.

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#782636: Fight Breast Cancer. Do More and Play to Help us Donate!

[fubar Family]

It's PINKTOBER Breast Cancer Awareness Month!



Help us raise awareness and grow our nodation amount for Breast Cancer 
Research! The more you play on fubar ... the more we can donate on your behalf.



Log in and play: 
https://fubar.com/recallclick.php?email=782...@bugs.debian.org=B3DQN%2FIENZnbgMqgQmlpZf4pBbqrrm1J.37



You're already healing us raise money for Breast Cancer Research by reading 
this message. Please support our cause even more by doing the following:


-- Send/Receive/Like BCA Bling & LE Sets

-- Like Profiles with Pink Names

-- Set Your Screen Name to Pink

-- Set Online Icon to BCA Ribbon

-- Set VIP+ Icon to BCA Ribbons

-- Set Buzz Meter to BCA Ribbons

-- Poast a Blast using a BCA Background

-- Go CRAZY and grab an Exotic BCA Bling




Download the fubar mobile app

Available at the App Store: 
https://itunes.apple.com/app/apple-store/id455311703?pt=395928=email 

Get it on Google Play: 
https://play.google.com/store/apps/details?id=com.fubar.mobile=utm_source%3Demail%26utm_medium%3Demail%26utm_campaign%3Demail




Cheers,

-fubar family




To stop receiving reminders from fubar, please adjust your email settings here:

https://fubar.com/recallclick.php?email=782...@bugs.debian.org=B3DQN%2FIENZnbgMqgQmlpZf4pBbqrrm1J.2

Bug#941992: piper: Error on upgrading Piper

[Danny O'Brien]

Package: piper
Version: 0.3-201909020946~ubuntu19.10.1
Severity: normal

Dear Maintainer,
i Piper maintainer!

Apologies if this is noise, but I hit a problem when upgrading your
package. Here's the error message I got from apt-get upgrade.

Unpacking piper (0.3-201909090646~ubuntu19.10.1) over 
(0.3-201909020946~ubuntu19.10.1) ...
Removing Piper symlink
rm: cannot remove '/usr/lib/python3/dist-packages/piper': No such file or 
directory
dpkg: warning: old piper package post-removal script subprocess returned error 
exit status 1
dpkg: trying script from the new package instead ...
Removing Piper symlink
rm: cannot remove '/usr/lib/python3/dist-packages/piper': No such file or 
directory
dpkg: error processing archive 
/tmp/apt-dpkg-install-tczR35/12-piper_0.3-201909090646~ubuntu19.10.1_amd64.deb 
(--unpack):
 new piper package post-removal script subprocess returned error exit status 1
Removing Piper symlink
rm: cannot remove '/usr/lib/python3/dist-packages/piper': No such file or 
directory

...


dpkg: error while cleaning up:
 new piper package post-removal script subprocess returned error exit status 1
Errors were encountered while processing:
 /tmp/apt-dpkg-install-tczR35/12-piper_0.3-201909090646~ubuntu19.10.1_amd64.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)

I hope this is useful for you! Ratbagd was also upgraded in this upgrade
-- and of course, this is all from the PPA.

d.



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

Kernel: Linux 4.19.0-6-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 /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages piper depends on:
ii  gir1.2-rsvg-2.0   2.44.10-2.1
iu  libratbag-tools   0.10-1-201909280947~ubuntu19.10.1
ii  python3-evdev 1.1.2+dfsg-1+b10
ii  python3-gi-cairo  3.30.4-1
ii  python3-lxml  4.3.2-1
iu  ratbagd   0.10-1-201909280947~ubuntu19.10.1

piper recommends no packages.

piper suggests no packages.

-- no debconf information

Bug#941991: gnome-shell: crashes on startup (Wayland only) with "JS ERROR: TypeError: actor.get_meta_window(...) is null"

[Zack Weinberg]

Package: gnome-shell
Version: 3.34.0-2
Severity: grave
Justification: renders package unusable

On my computer, after upgrading to gnome-shell 3.34, I consistently get a
gnome-shell catastrophic failure about 10 seconds after logging in, but only
when running under Wayland.  This error appears in the logs:

gnome-shell[2608]: JS ERROR: TypeError: actor.get_meta_window(...) is null
  destroyWindowDone@resource:///org/gnome/shell/ui/windowManager.js:1773:26
  onStopped@resource:///org/gnome/shell/ui/windowManager.js:1742:34
  makeEaseCallback/<@resource:///org/gnome/shell/ui/environment.js:73:13
  easeActor/<@resource:///org/gnome/shell/ui/environment.js:126:60
gnome-shell[2608]: JS ERROR: TypeError: actor.get_meta_window(...) is null
  destroyWindowDone@resource:///org/gnome/shell/ui/windowManager.js:1773:26
  onStopped@resource:///org/gnome/shell/ui/windowManager.js:1742:34
  makeEaseCallback/<@resource:///org/gnome/shell/ui/environment.js:73:13
  easeActor/<@resource:///org/gnome/shell/ui/environment.js:126:60
gdm-wayland-session[2571]: Received signal:15->'Terminated'

I don't see anything else that is obviously related, but I could have
missed something.  Please let me know if you need more information.

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

Kernel: Linux 5.2.0-3-amd64 (SMP w/4 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

Versions of packages gnome-shell depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.34.0-1
ii  evolution-data-server3.34.1-1
ii  gir1.2-accountsservice-1.0   0.6.45-2
ii  gir1.2-atspi-2.0 2.34.0-3
ii  gir1.2-freedesktop   1.62.0-2
ii  gir1.2-gcr-3 3.33.4-3
ii  gir1.2-gdesktopenums-3.0 3.34.0-2
ii  gir1.2-gdm-1.0   3.34.1-1
ii  gir1.2-geoclue-2.0   2.5.5-1
ii  gir1.2-glib-2.0  1.62.0-2
ii  gir1.2-gnomebluetooth-1.03.34.0-1
ii  gir1.2-gnomedesktop-3.0  3.34.0-3
ii  gir1.2-gtk-3.0   3.24.12-1
ii  gir1.2-gweather-3.0  3.28.3-2
ii  gir1.2-ibus-1.0  1.5.21-1
ii  gir1.2-mutter-5  3.34.0-4
ii  gir1.2-nm-1.01.20.4-2
ii  gir1.2-nma-1.0   1.8.22-2
ii  gir1.2-pango-1.0 1.42.4-7
ii  gir1.2-polkit-1.00.105-26
ii  gir1.2-rsvg-2.0  2.44.15-1
ii  gir1.2-soup-2.4  2.68.1-2
ii  gir1.2-upowerglib-1.00.99.11-1
ii  gjs  1.58.0-2
ii  gnome-backgrounds3.34.0-1
ii  gnome-settings-daemon3.34.0-3
ii  gnome-shell-common   3.34.0-2
ii  gsettings-desktop-schemas3.34.0-2
ii  libatk-bridge2.0-0   2.34.0-3
ii  libatk1.0-0  2.34.0-1
ii  libc62.29-2
ii  libcairo21.16.0-4
ii  libcroco30.6.13-1
ii  libecal-2.0-13.34.1-1
ii  libedataserver-1.2-243.34.1-1
ii  libgcr-base-3-1  3.33.4-3
ii  libgdk-pixbuf2.0-0   2.38.2+dfsg-1
ii  libgirepository-1.0-11.62.0-2
ii  libgjs0g 1.58.0-2
ii  libgles2 1.1.0-1+b1
ii  libglib2.0-0 2.62.1-1
ii  libglib2.0-bin   2.62.1-1
ii  libgnome-autoar-0-0  0.2.3-2
ii  libgstreamer1.0-01.16.1-1
ii  libgtk-3-0   3.24.12-1
ii  libical3 3.0.5-2
ii  libjson-glib-1.0-0   1.4.4-2
ii  libmutter-5-03.34.0-4
ii  libnm0   1.20.4-2
ii  libpango-1.0-0   1.42.4-7
ii  libpangocairo-1.0-0  1.42.4-7
ii  libpolkit-agent-1-0  0.105-26
ii  libpolkit-gobject-1-00.105-26
ii  libpulse-mainloop-glib0  13.0-2
ii  libpulse013.0-2
ii  libsecret-1-00.19.1-1
ii  libsystemd0  

Bug#939838: nftables: please apply upstream commits to fix firewalld testsuite failures

[Michael Biebl]

On Mon, 9 Sep 2019 14:25:31 +0200 Gianfranco Costamagna
 wrote:
> Source: nftables
> Version: 0.9.2-1
> Severity: serious
> Justification: breaks another package from working correctly
> 
> Hello, according to firewalld upstream devs, we need 2 commits to fixup their 
> test failures.
> I also cherry-picked another hotfix, because it seemed important to me
> (note, I just uploaded them in Ubuntu, I didn't run the tests yet)
> commit ids:
> - 2e57d4ff79fa166f2dea3686ca4fe051b656a8d2
> - 03478af1bea03eafd43df94334cb001ed26145a3
> - 1e2aae7d73ce733650d78da452d45d6c5498cc33
> 
> patch here:
> 
> http://launchpadlibrarian.net/441272565/nftables_0.9.2-1_0.9.2-1ubuntu1.diff.gz
> 
> 


Any news here?
I ran into this while packaging an update for firewalld (unfortunately
we can't yet run the qemu based autopkgtests on Debian infra yet which
would have caught this regression automatically)

Regards,
Michael
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#941990: displaycal-apply-profiles needs python-dbus

[Zack Weinberg]

Package: displaycal
Version: 3.8.7.1-1
Severity: normal

The displaycal package has no dependency on (python-)dbus, but
its script /usr/bin/displaycal-apply-profiles crashes on startup
if the dbus module is not available:

Traceback (most recent call last):
  File "/usr/bin/displaycal-apply-profiles", line 17, in 
main()
  File "/usr/lib/python2.7/dist-packages/DisplayCAL/profile_loader.py", line 
3375, in main
ProfileLoader()
  File "/usr/lib/python2.7/dist-packages/DisplayCAL/profile_loader.py", line 
1112, in __init__
self.apply_profiles_and_warn_on_error()
  File "/usr/lib/python2.7/dist-packages/DisplayCAL/profile_loader.py", line 
1834, in apply_profiles_and_warn_on_error
errors = self.apply_profiles(event, index)
  File "/usr/lib/python2.7/dist-packages/DisplayCAL/profile_loader.py", line 
1683, in apply_profiles
from worker import Worker, get_argyll_util
  File "/usr/lib/python2.7/dist-packages/DisplayCAL/worker.py", line 127, in 

import colord
  File "/usr/lib/python2.7/dist-packages/DisplayCAL/colord.py", line 27, in 

from util_dbus import DBusObject, DBusException, BUSTYPE_SYSTEM
  File "/usr/lib/python2.7/dist-packages/DisplayCAL/util_dbus.py", line 16, in 

import dbus
ImportError: No module named dbus

The package should add at least a Recommends for python-dbus and possibly
also python-gi.  After conversion to Python 3 as requested in #936404,
these dependencies should be changed to python3-{dbus,gi} respectively.

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

Kernel: Linux 5.2.0-3-amd64 (SMP w/4 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

Versions of packages displaycal depends on:
ii  argyll   2.0.1+repack-1
ii  libc62.29-2
ii  libjs-jquery 3.3.1~dfsg-3
ii  libx11-6 2:1.6.8-1
ii  libxinerama1 2:1.1.4-2
ii  libxrandr2   2:1.5.1-1
ii  libxxf86vm1  1:1.1.4-1+b2
ii  python   2.7.16-1
ii  python-numpy 1:1.16.5-1
ii  python-wxgtk3.0  3.0.2.0+dfsg-8

Versions of packages displaycal recommends:
ii  colord1.4.4-1
ii  gir1.2-colordgtk-1.0  0.1.26-2

displaycal suggests no packages.

-- no debconf information

Bug#931416: marked as done (klibc-utils: ipconfig denial of service when IP nameservers are configured on the kernel command line)

[Ben Hutchings]

Control: reopen -1

On Tue, 2019-10-08 at 02:14 +, Thorsten Glaser wrote:
> Debian Bug Tracking System dixit:
> 
> >Your message dated Tue, 08 Oct 2019 01:35:33 +
> >with message-id 
> >and subject line Bug#931416: fixed in klibc 2.0.7-1
> 
> >> - ipconfig: Implement support -d ...:dns0:dns1 options (Closes: 
> >> #931416)
> 
> >has caused the Debian Bug report #931416,
> >regarding klibc-utils: ipconfig denial of service when IP nameservers are 
> >configured on the kernel command line
> >to be marked as done.
> 
> Not sure about that:
> 
> >>
> >> ip=:
> 
> 1. is  also now handled?

No, but that was not required ("possibly even NTP configuration").

> 2. are any future colon-separated extensions now ignored
>in a way to make it not fail should they be introduced,
>i.e. to not repeat this problem?

Oops, no, that is still an error.

Ben.

> Both were requested in the original bugreport.

-- 
Ben Hutchings
[W]e found...that it wasn't as easy to get programs right as we had
thought. I realized that a large part of my life from then on was going
to be spent in finding mistakes in my own programs.
 - Maurice Wilkes, 1949



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

Bug#935086: insighttoolkit4 REMOVED from testing

[Gilles Filippini]

Control: tags -1 + patch

Hi,

Michael Crusoe a écrit le 04/10/2019 à 16:01 :
> Attached is a patch to force gcc 8; so far it has gotten farther than
> the previous failure for me (but my local build is still at 86%)

Looking at the related lines of /usr/include/c++/9/bits/stl_function.h,
it seems that __builtin_is_constant_evaluated is used only for C++
standard greater or equal to c++14:
> #if __cplusplus >= 201402L
> #ifdef _GLIBCXX_HAVE_BUILTIN_IS_CONSTANT_EVALUATED
>   if (__builtin_is_constant_evaluated())
> #else
>   if (__builtin_constant_p(__x > __y))
> #endif
> return __x > __y;
> #endif
>   return (__UINTPTR_TYPE__)__x > (__UINTPTR_TYPE__)__y;


Then I tried using '-std=c++11' and the build was successful.

Patch attached.

Thanks,

_g.
diff -Nru insighttoolkit4-4.12.2-dfsg1/debian/changelog 
insighttoolkit4-4.12.2-dfsg1/debian/changelog
--- insighttoolkit4-4.12.2-dfsg1/debian/changelog   2018-08-28 
16:27:47.0 +0200
+++ insighttoolkit4-4.12.2-dfsg1/debian/changelog   2019-10-07 
21:50:28.0 +0200
@@ -1,3 +1,10 @@
+insighttoolkit4 (4.12.2-dfsg1-4.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Force -std=c++11 to fix FTBFS with GCC-9 (closes: #935086)
+
+ -- Gilles Filippini   Mon, 07 Oct 2019 21:50:28 +0200
+
 insighttoolkit4 (4.12.2-dfsg1-4) unstable; urgency=medium
 
   * d/rules: Remove build dir right after installation
diff -Nru insighttoolkit4-4.12.2-dfsg1/debian/rules 
insighttoolkit4-4.12.2-dfsg1/debian/rules
--- insighttoolkit4-4.12.2-dfsg1/debian/rules   2018-08-28 16:27:47.0 
+0200
+++ insighttoolkit4-4.12.2-dfsg1/debian/rules   2019-10-07 21:50:28.0 
+0200
@@ -25,6 +25,9 @@
   ENABLE_UNSIGNED_LONG=ON 
 endif 
 
+# Fix for #935086
+export DEB_CXXFLAGS_MAINT_APPEND+=-std=c++11
+
 CMAKE_FLAGS = \
-DBUILD_EXAMPLES:BOOL=ON \
-DBUILD_SHARED_LIBS:BOOL=ON \


signature.asc
Description: OpenPGP digital signature

Bug#936047: firewalld: missing intltool dependency on testsuite?

[Michael Biebl]

Control: tags -1 + pending

On Thu, 29 Aug 2019 14:06:13 +0200 Gianfranco Costamagna
 wrote:
> Source: firewalld
> Version: 0.7.1-1
> Severity: important
> tags: patch
> 
> Hello, I would like to request you a little fix on your package if possible.
> 
> Add intltool to debian/tests/control.
> 
> In some environment, automake --refresh is run before tests to recreate the 
> needed files, and fails because of missing intltool
> (probably it is comparing the date of the files and the system one, to decide 
> if there is need to recreate or not, I don't know)
> 

I've never run into this issue myself.
That said, if this helps Ubuntu CI (where this apparently happens), it's
fine with me.



-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#53434: From Mr. Mohammed Sultan

[mohammed sultan]

Compliments to you,

I am a financial consultant and have Investors who are willing to invest
abroad and willing to provide funding for project development which could
be by loan or by joint venture partnership.

Kindly get back to me for more details and can we discuss?

Thanking you in advance
Yours Sincerely,
Mr. Mohammed Sultan
+27603187672
Strategic Partnership development (ADP)

Bug#938501: Please port smalt to Python3 (Was: Bug#938501: smalt: Python2 removal in sid/bullseye) [EXT]

[James Bonfield]

Hi all,

Hannes is still around, but has moved jobs.  I'm including Zemin Ning
in this reply whose team Hannes was in when he wrote Smalt.

I don't know the extent of the issue having not used Smalt myself, but
the main tool itself is C so I doubt the python bit is a major
component.

Regardless, it's not something I'm involved with personally.

James


On Tue, Oct 08, 2019 at 05:33:42PM +0200, Andreas Tille wrote:
> Hi again,
> 
> I just took James Bonfield in CC since I'm unsure whether my mail might
> have reached someone who is currently working at sanger.ac.uk.  Just to
> stretch the importance of the issue have a look at the Python2 EOL clock:
> 
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__pythonclock.org_=DwIBAg=D7ByGjS34AllFgecYw0iC6Zq7qlm8uclZFI0SqQnqBo=wodoR_G062E4YLZ-xu5t6g=XK--XBUkRyktzXOkgsZpq_yu16VL7H7Y75QlpOEnwGc=1ojoaFsu0HVyuhxGkiUBSnPjQJLSXJQyv1jrE-FfnMw=
>  
> 
> In short: Please be so kind and verify the patch linked below and fix
> the remaining issues with your deeper knowledge of the code.
> 
> Thanks a lot
> 
>   Andreas.
> 
> 
> On Thu, Sep 05, 2019 at 03:39:35PM +0200, Andreas Tille wrote:
> > Control: tags -1 upsteam
> > Control: forwarded -1 Hannes Ponstingl 
> > 
> > Hi Hannes,
> > 
> > as you can read below Debian will remove Python2 since it is EOL.
> > I tried to port your test scripts using the 2to3 tool.  The result
> > of the automatic conversion can be found here:
> > 
> > 
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__salsa.debian.org_med-2Dteam_smalt_blob_master_debian_patches_2to3.patch=DwIBAg=D7ByGjS34AllFgecYw0iC6Zq7qlm8uclZFI0SqQnqBo=wodoR_G062E4YLZ-xu5t6g=XK--XBUkRyktzXOkgsZpq_yu16VL7H7Y75QlpOEnwGc=j7oR-RSaMB5DM2SvBCK63XeKcftyATF9QB_A56HxSCs=
> >  
> > 
> > Unfortunately there are some remaining issues in the test suite which
> > are probably not very hard to fix.  I wonder whether you might want
> > to have a look at these and could prepare an official Python3 release
> > of your nice tool.
> > 
> > Here is the output of the test suite:
> > 
> > 
> > PASS: splitReads_test.py
> > PASS: results_split_test.py
> > PASS: ouform_cigar_test.py
> > Traceback (most recent call last):
> >   File "./sample_test.py", line 154, in 
> > compare_mapping(oufilnam1, oufilnam3)
> >   File "./sample_test.py", line 108, in compare_mapping
> > if cmp(cig1.qnam, cig2.qnam):
> > NameError: name 'cmp' is not defined
> > FAIL: sample_test.py
> > PASS: cigar_test.py
> > Discrepancy:
> > cigar:A:60 SIM_0_MAL11_001337747_10_F_75m/1 1 75 + MAL11 1337747 
> > 1337821 + 75 M 75
> > cigar:A:60 SIM_0_MAL11_001337747_10_F_75m/1 1 75 + MAL11 1337747 
> > 1337821 + 75 M 75
> > FAIL: mthread_test.py
> > Traceback (most recent call last):
> >   File "./ioform_test.py", line 45, in 
> > samnam = df.unpack(READ_PREFIX + ".sam")
> >   File "/build/smalt-0.7.6/test/testdata.py", line 71, in unpack
> > oufil.write(lin)
> > TypeError: write() argument must be str, not bytes
> > FAIL: ioform_test.py
> > PASS: xali_test.py
> > Traceback (most recent call last):
> >   File "./bam_cigar_test.py", line 254, in 
> > isOK = testSAMfilesAreIdentical(sambamnam, samoufilnam)
> >   File "./bam_cigar_test.py", line 149, in testSAMfilesAreIdentical
> > linA = infilA.readline()
> >   File "/usr/lib/python3.7/codecs.py", line 322, in decode
> > (result, consumed) = self._buffer_decode(data, self.errors, final)
> > UnicodeDecodeError: 'utf-8' codec can't decode byte 0xff in position 260: 
> > invalid start byte
> > FAIL: bam_cigar_test.py
> > =
> > 4 of 9 tests failed
> > Please report to h...@sanger.ac.uk
> > =
> > 
> > 
> > Kind regards
> > 
> >   Andreas.
> > 
> > 
> > On Fri, Aug 30, 2019 at 07:52:50AM +, Matthias Klose wrote:
> > > Package: src:smalt
> > > Version: 0.7.6-8
> > > Severity: normal
> > > Tags: sid bullseye
> > > User: debian-pyt...@lists.debian.org
> > > Usertags: py2removal
> > > 
> > > Python2 becomes end-of-live upstream, and Debian aims to remove
> > > Python2 from the distribution, as discussed in
> > > https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.debian.org_debian-2Dpython_2019_07_msg00080.html=DwIBAg=D7ByGjS34AllFgecYw0iC6Zq7qlm8uclZFI0SqQnqBo=wodoR_G062E4YLZ-xu5t6g=XK--XBUkRyktzXOkgsZpq_yu16VL7H7Y75QlpOEnwGc=Xgujf6sRlZuNDRpgPdw-HM2EVf1K2YRkzazDPAt9sK4=
> > >  
> > > 
> > > Your package either build-depends, depends on Python2, or uses Python2
> > > in the autopkg tests.  Please stop using Python2, and fix this issue
> > > by one of the following actions.
> > > 
> > > - Convert your Package to Python3. This is the preferred option.  In
> > >   case you are providing a Python module foo, please consider dropping
> > >   the python-foo package, and only build a python3-foo package.  Please
> > >   don't drop Python2 modules, which still have reverse dependencies,
> > >   just document them.
> > >   
> > >   This is the preferred 

Bug#941987: [Pkg-openssl-devel] Bug#941987: libssl1.1: Ciphers AES-*-CBC-HMAC-* are missing in libssl 1.1.1d, but available in 1.1.1c

[Kurt Roeckx]

There are no HMAC based ciphers, see:
https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-4


Kurt

Bug#941989: slic3r-prusa: fails to build on arm*

[gregor herrmann]

Source: slic3r-prusa
Version: 1.41.2+dfsg-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
Control: block 935737 with -1

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

During the perl transition we noticed that slic3r-prusa failed to
build on the arm* architectures (and alpha):
https://buildd.debian.org/status/package.php?p=slic3r-prusa

In fact, 1.41.* has never built on any of them:
https://buildd.debian.org/status/logs.php?pkg=slic3r-prusa


Cheers,
gregor

-BEGIN PGP SIGNATURE-

iQKTBAEBCgB9FiEE0eExbpOnYKgQTYX6uzpoAYZJqgYFAl2csKNfFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEQx
RTEzMTZFOTNBNzYwQTgxMDREODVGQUJCM0E2ODAxODY0OUFBMDYACgkQuzpoAYZJ
qgbTEA/+INFvRjbntxXOCMPkyH11sILNqhqBuEnIICEUMrA54D/Qtg2g0PzMOS30
ztmaLDY3B88LP3Mz6TqwezlXRMUZs7RB6tWIgDiUEEHkheui7PFhRuigNXdCWPRr
og1t0G3SaCF+ZkmyDHn/pv2Fi/HYXKDQaoF/xz7Sdm40QUjcLsKqQ+/fpxi7QOWA
2HuJVl+9ZIyL0dAoZKm6MfPWg4pdGymdaH7bxwnWwBIrrao69PYc6k1ZVKq8EVNF
9K7XoBqvKxKjxnqvtAfwOcSsPmhscBoCXfgygSYJo4UnalK+8L1sEEObXzQ0geOB
OvL8AMpw7Dz+2hYnrkpiGPyrO2ElzWs/9tp7X10Zu0ezSQst4K+IOTQwUTlH21X+
ZH8qlwsJAwiGtNA16GUcDjvNw/yIDLaNjaU6LEY4hzzFsUNgjy4eMThBey/hhxvs
u//A4vpr5sQEPwJ1gyra5C1CS0HUr0MK4usfG2IIiQKGCUEiCrLJqzLG859oJJ+3
oVKNVWF+tb7bY6UzUCu6W8zZUHzMW8YHEtk2w3/ZOSt5igww9ZK5+4MNKZCnzvZg
QRLTYMKFiFH4pKVXBHSEs900aS7VqpTyAD7SrW0zbCNmc3OpuU7TkVqPOymRKUrn
fcbWzcknpouDI2nGxZDSWOSZvcKwmEm03+rFH/bAOMYhaEmddRs=
=a8zO
-END PGP SIGNATURE-

Bug#941986: [debian-mysql] Bug#941986: mariadb-client-10.3: InnoTop crashes during use

[Robie Basak]

On Tue, Oct 08, 2019 at 11:31:14AM -0400, Michael Krieger wrote:
> This is because technically 10.3 is not officially supported by innotop, and 
> so it uses old legacy code which returns incorrect results.
> 
> While innotop doesn't get support 10.3, us shipping innotop with MariaDB 10.3 
> means it should really work with it.  It is substantially close to 10.1/10.2 
> to include it in the ways that works as opposed to using outdated code meant 
> for older versions of MySQL.
> 
> Ideally, innotop should be updated to include official 10.3 support.  Until 
> the developer does that, this will at least make innotop usable on Debian 
> Buster 10.

FWIW, we removed innotop from "the other side" in the MySQL packaging.
We faced similar breakages, and it seemed wrong to ship innotop inside
the MySQL packaging as it's a separate upstream that comes from a
different upstream organisation and breakages like this don't seem
infrequent.

IMHO, if we ship it at all, innotop should be shipped as a separate
Debian source package with appropriate declared dependencies and
autopkgtests. This current breakage might be an opportunity to fix that.

This would also permit people who care about innotop to become nominated
maintainers and they would then be able to look after its compatibility
against MySQL/MariaDB in the same way that Debian handles transitions
for other reverse dependencies, with all the usual tooling, process and
reporting, which might make everything run smoother.

I don't intend for this comment to block any particular approach though
- I'm just offering what I hope is a useful perspective.


signature.asc
Description: PGP signature

Bug#941988: libncurses-dev: Please package libncurses_g

[Joe Pfeiffer]

Package: libncurses-dev
Version: 6.1+20190803-1
Severity: wishlist

I'm tracking down a bug in a program of mine, which is either a
regression in the current version of libncurses-dev or a bug in my
code which has been exposed by the current version.  It would be very
helpful to me to be able to use the trace() function, to see the
activity of the library.  This is documented as requiring a program to
be linked against libncurses_g (instead of libncurses); so far as I've
been able to find this library is not currently packaged, so I'll need
to rebuild from source.  I'd appreciate it if it could be packaged.

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (700, 'testing'), (650, 'stable'), (600, 'unstable'), (550, 
'experimental'), (500, 'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages libncurses-dev depends on:
ii  libc6-dev [libc-dev]  2.29-2
ii  libncurses6   6.1+20190803-1
ii  libncursesw6  6.1+20190803-1
ii  libtinfo6 6.1+20190803-1
ii  ncurses-bin   6.1+20190803-1

libncurses-dev recommends no packages.

Versions of packages libncurses-dev suggests:
ii  ncurses-doc  6.1+20190803-1

-- no debconf information

Bug#941987: libssl1.1: Ciphers AES-*-CBC-HMAC-* are missing in libssl 1.1.1d, but available in 1.1.1c

[Greg]

Package: libssl1.1
Version: 1.1.1c-1+0~20190710.13+debian10~1.gbp359e02
Severity: normal

Dear Maintainer,

   * What led up to the situation?
   Upgraded package libssl1.1 from 1.1.1c to 1.1.1d

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   Downgraded to 1.1.1c

   * What was the outcome of this action?
   4 more ciphers were back



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

Kernel: Linux 4.19.0-6-amd64 (SMP w/16 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:en (charmap=UTF-8)

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

Versions of packages libssl1.1 depends on:
ii  debconf [debconf-2.0]  1.5.71
ii  libc6  2.28-10

libssl1.1 recommends no packages.

libssl1.1 suggests no packages.

-- debconf information excluded


Signature email

Bug#941986: mariadb-client-10.3: InnoTop crashes during use

[Michael Krieger]

Package: mariadb-client-10.3
Version: 1:10.3.17-0+deb10u1
Severity: important

Dear Maintainer,

On running `innotop`, it appears to work correctly, however upon choosing one 
of the other screens, such as pushing "L" to bring up the lock screen, it 
crashes with the error:
Use of uninitialized value $text in pattern match (m//) at 
/tmp/innotop.orig line 620.

This is because technically 10.3 is not officially supported by innotop, and so 
it uses old legacy code which returns incorrect results.

While innotop doesn't get support 10.3, us shipping innotop with MariaDB 10.3 
means it should really work with it.  It is substantially close to 10.1/10.2 to 
include it in the ways that works as opposed to using outdated code meant for 
older versions of MySQL.

Ideally, innotop should be updated to include official 10.3 support.  Until the 
developer does that, this will at least make innotop usable on Debian Buster 10.

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

Kernel: Linux 4.19.0-6-amd64 (SMP w/12 CPU cores)
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)
LSM: AppArmor: enabled

Versions of packages mariadb-client-10.3 depends on:
ii  debianutils   4.8.6.1
ii  libc6 2.28-10
ii  libconfig-inifiles-perl   3.01-1
ii  libgnutls30   3.6.7-4
ii  libstdc++68.3.0-6
ii  mariadb-client-core-10.3  1:10.3.17-0+deb10u1
ii  perl  5.28.1-6
ii  zlib1g1:1.2.11.dfsg-1

Versions of packages mariadb-client-10.3 recommends:
ii  libdbd-mysql-perl 4.050-2
ii  libdbi-perl   1.642-1+b1
ii  libterm-readkey-perl  2.38-1

mariadb-client-10.3 suggests no packages.

-- no debconf information
--- /tmp/innotop.orig   2019-10-08 11:17:31.446038258 -0400
+++ /usr/bin/innotop2019-10-08 11:21:57.258023170 -0400
@@ -471,7 +471,7 @@
# too many locks to print, the output might be truncated)
 
my $time_text;
-   if ( ($mysqlversion =~ /^5\.[67]\./) || ($mysqlversion =~ /^10\.[012]\./) ) 
{
+   if ( ($mysqlversion =~ /^5\.[67]\./) || ($mysqlversion =~ /^10\.[0123]\./) 
) {
   ( $time_text ) = $fulltext =~ m/^([0-9-]* [0-9:]*) [0-9a-fx]* INNODB 
MONITOR OUTPUT/m;
   $innodb_data{'ts'} = [ parse_innodb_timestamp_56( $time_text ) ];
} else {
@@ -639,7 +639,7 @@
return 0 unless $fulltext;
 
my ( $ts, $type );
-   if ( ($mysqlversion =~ /^5.[67]\./) || ($mysqlversion =~ /^10.[012]\./) ) {
+   if ( ($mysqlversion =~ /^5.[67]\./) || ($mysqlversion =~ /^10.[0123]\./) ) {
   ( $ts, $type ) = $fulltext =~ m/^([0-9-]* [0-9:]*)\s[0-9a-fx]*\s+(\w+)/m;
   $section->{'ts'} = [ parse_innodb_timestamp_56( $ts ) ];
} else {
@@ -899,7 +899,7 @@
my ( $ts ) = $fulltext =~ m/^$s$/m;
return 0 unless $ts;
 
-   if ( ($mysqlversion =~ /^5\.[67]\./) || ($mysqlversion =~ /^10\.[012]\./) ) 
{
+   if ( ($mysqlversion =~ /^5\.[67]\./) || ($mysqlversion =~ /^10\.[0123]\./) 
) {
   $dl->{'ts'} = [ parse_innodb_timestamp_56( $ts ) ];
}
else {

Bug#938501: Please port smalt to Python3 (Was: Bug#938501: smalt: Python2 removal in sid/bullseye)

[Andreas Tille]

Hi again,

I just took James Bonfield in CC since I'm unsure whether my mail might
have reached someone who is currently working at sanger.ac.uk.  Just to
stretch the importance of the issue have a look at the Python2 EOL clock:

   https://pythonclock.org/

In short: Please be so kind and verify the patch linked below and fix
the remaining issues with your deeper knowledge of the code.

Thanks a lot

  Andreas.


On Thu, Sep 05, 2019 at 03:39:35PM +0200, Andreas Tille wrote:
> Control: tags -1 upsteam
> Control: forwarded -1 Hannes Ponstingl 
> 
> Hi Hannes,
> 
> as you can read below Debian will remove Python2 since it is EOL.
> I tried to port your test scripts using the 2to3 tool.  The result
> of the automatic conversion can be found here:
> 
> 
> https://salsa.debian.org/med-team/smalt/blob/master/debian/patches/2to3.patch
> 
> Unfortunately there are some remaining issues in the test suite which
> are probably not very hard to fix.  I wonder whether you might want
> to have a look at these and could prepare an official Python3 release
> of your nice tool.
> 
> Here is the output of the test suite:
> 
> 
> PASS: splitReads_test.py
> PASS: results_split_test.py
> PASS: ouform_cigar_test.py
> Traceback (most recent call last):
>   File "./sample_test.py", line 154, in 
> compare_mapping(oufilnam1, oufilnam3)
>   File "./sample_test.py", line 108, in compare_mapping
> if cmp(cig1.qnam, cig2.qnam):
> NameError: name 'cmp' is not defined
> FAIL: sample_test.py
> PASS: cigar_test.py
> Discrepancy:
> cigar:A:60 SIM_0_MAL11_001337747_10_F_75m/1 1 75 + MAL11 1337747 
> 1337821 + 75 M 75
> cigar:A:60 SIM_0_MAL11_001337747_10_F_75m/1 1 75 + MAL11 1337747 
> 1337821 + 75 M 75
> FAIL: mthread_test.py
> Traceback (most recent call last):
>   File "./ioform_test.py", line 45, in 
> samnam = df.unpack(READ_PREFIX + ".sam")
>   File "/build/smalt-0.7.6/test/testdata.py", line 71, in unpack
> oufil.write(lin)
> TypeError: write() argument must be str, not bytes
> FAIL: ioform_test.py
> PASS: xali_test.py
> Traceback (most recent call last):
>   File "./bam_cigar_test.py", line 254, in 
> isOK = testSAMfilesAreIdentical(sambamnam, samoufilnam)
>   File "./bam_cigar_test.py", line 149, in testSAMfilesAreIdentical
> linA = infilA.readline()
>   File "/usr/lib/python3.7/codecs.py", line 322, in decode
> (result, consumed) = self._buffer_decode(data, self.errors, final)
> UnicodeDecodeError: 'utf-8' codec can't decode byte 0xff in position 260: 
> invalid start byte
> FAIL: bam_cigar_test.py
> =
> 4 of 9 tests failed
> Please report to h...@sanger.ac.uk
> =
> 
> 
> Kind regards
> 
>   Andreas.
> 
> 
> On Fri, Aug 30, 2019 at 07:52:50AM +, Matthias Klose wrote:
> > Package: src:smalt
> > Version: 0.7.6-8
> > Severity: normal
> > Tags: sid bullseye
> > User: debian-pyt...@lists.debian.org
> > Usertags: py2removal
> > 
> > Python2 becomes end-of-live upstream, and Debian aims to remove
> > Python2 from the distribution, as discussed in
> > https://lists.debian.org/debian-python/2019/07/msg00080.html
> > 
> > Your package either build-depends, depends on Python2, or uses Python2
> > in the autopkg tests.  Please stop using Python2, and fix this issue
> > by one of the following actions.
> > 
> > - Convert your Package to Python3. This is the preferred option.  In
> >   case you are providing a Python module foo, please consider dropping
> >   the python-foo package, and only build a python3-foo package.  Please
> >   don't drop Python2 modules, which still have reverse dependencies,
> >   just document them.
> >   
> >   This is the preferred option.
> > 
> > - If the package is dead upstream, cannot be converted or maintained
> >   in Debian, it should be removed from the distribution.  If the
> >   package still has reverse dependencies, raise the severity to
> >   "serious" and document the reverse dependencies with the BTS affects
> >   command.  If the package has no reverse dependencies, confirm that
> >   the package can be removed, reassign this issue to ftp.debian.org,
> >   make sure that the bug priority is set to normal and retitle the
> >   issue to "RM: PKG -- removal triggered by the Python2 removal".
> > 
> > - If the package has still many users (popcon >= 300), or is needed to
> >   build another package which cannot be removed, document that by
> >   adding the "py2keep" user tag (not replacing the py2remove tag),
> >   using the debian-pyt...@lists.debian.org user.  Also any
> >   dependencies on an unversioned python package (python, python-dev)
> >   must not be used, same with the python shebang.  These have to be
> >   replaced by python2/python2.7 dependencies and shebang.
> > 
> >   This is the least preferred option.
> > 
> > If the conversion or removal needs action on another package first,
> > please document the blocking by using the BTS affects command, like
> > 
> >   

Bug#941896: davmail: JAR does not include org.apache.http.HttpRequest in class path.

[Alexandre Rossi]

Hi,

> Aha, thank you for quickly investigating - yes, that other bug certainly
> looks relevant. So very likely something fixable by constraining
> versions of a couple of dependencies to be sufficiently new but I could
> easily have misjudged the degree we expect such mixed-version systems to
> work at all, may not be enough worth the maintenance effort.

Thanks, closing then.

Alex

Bug#936798: Please port KisSplice to Python3 (Was: Bug#936798: kissplice: Python2 removal in sid/bullseye)

[Andreas Tille]

Control: forwarded -1 David Parsons , 
vincent.lacr...@univ-lyon1.fr
Control: tags -1 upstream

Hi,

as you might probably know Python2 is End Of Live[1] and Debian is
actively working on removing Python2 code from the distribution.  So
Debian 11 will come without Python2.  This means we will either be
able to port all software packages to Python3 or the package will be
removed.

Do you think it is feasible for you to port KisSplice to Python3?  May be
by using 2to3 which does quite some work automatically?  If you need any
help please do not hesitate to ask.

Kind regards

  Andreas.


[1] https://pythonclock.org/

-- 
http://fam-tille.de

Bug#936652: Please port GraPhlAn to Python3 (Was: Bug#936652: graphlan: Python2 removal in sid/bullseye)

[Andreas Tille]

Control: forwarded -1 Nicola Segata 
Control: tags -1 upstream

Hi Nicola,

as you might probably know Python2 is End Of Live[1] and Debian is
actively working on removing Python2 code from the distribution.  So
Debian 11 will come without Python2.  This means we will either be
able to port all software packages to Python3 or the package will be
removed.

Do you think it is feasible for you to port GraPhlAn to Python3?  May be
by using 2to3 which does quite some work automatically?  If you need any
help please do not hesitate to ask.

Kind regards

  Andreas.


[1] https://pythonclock.org/

-- 
http://fam-tille.de

Bug#936711: Please remove binary package python-htseq (Was: Bug#936711: htseq: Python2 removal in sid/bullseye)

[Andreas Tille]

Control: reassign -1 ftp.debian.org
Control: retitle -1 Please remove binary package python-htseq

Hi ftpmasters,

the Python2 binary package python-htseq was removed from the source
package htseq.  Please remove it from the package pool to avoid cruft.

Kind regards and thanks for your work as ftpmaster

   Andreas.

-- 
http://fam-tille.de

Bug#941985: perl 5.30.0 - Unable to set supplementary group IDs

[Dagfinn Ilmari Mannsåker]

Package: perl
Version: 5.30.0-5
Forwarded: https://rt.perl.org/Public/Bug/Display.html?id=134169
Severity: serious

A regression in perl 5.30.0 breaks setting supplementary groups by
assigning a space-separated string to the $) variable.  This breaks
postgresql-common, which relies on taking on all the supplementary
groups of the postgres user (specifically ssl-cert, to be able to read
SSL certificates).

This has been fixed in blead¹, and proposed for backporting to the 5.30
branch².

[1]: 
http://perl5.git.perl.org/perl.git/commitdiff/79e302e6c3f815bf4cb72a5bacc3012595970db9
[2]: 
https://perl5.git.perl.org/perl.git/commitdiff/37615aed2d5ce7dd5e254533f5235478f3378422

- ilmari
-- 
"The surreality of the universe tends towards a maximum" -- Skud's Law
"Never formulate a law or axiom that you're not prepared to live with
 the consequences of."  -- Skud's Meta-Law

Bug#905206: Status of rostlab software in Debian (Was: Bug#905206: Seems to crash in fortran lib)

[Andreas Tille]

Hello,

back in 2009 Laszlo Kajan did quite some effort to package several
projects from rostlab.org for official Debian.  There was a very good
cooperation between RostLab and Debian - mediated by Laszlo who was
introducing other members (who probably left Rostlab meanwhile to find
other jobs).

Since Laszlo moved away from Munich he lost contact to Rostlab and had
also no time to keep on maintaining the existing Software inside Debian.
So the Debian Med team took over the maintenance.  The packages were
regularly updated to latest versions released by Rostlab as well as to
the latest packaging standards in Debian.  This also included continuous
integration tests to verify the functionality of the programs.

It now turned out that one of the tests for profnet failed (you might
like to read the full story and the effort we did to track the issue
down in the according bug report https://bugs.debian.org/905206 ).
The reason seems to be inside a FORTRAN module
(see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=905206#69 ).
Unfortunately there is nobody in the team who can even decide whether
this might be caused by a broken gfortran compiler or whether the code
is broken.  Thus we can not guarantee the proper functionality of the
code for our users without help.

As you can read below Olivier Sallou from Debian Med team found reasons
to assume that the software stack based on profnet is superseeded
anyway.  It would be nice if you could confirm this.  In this case we
could stop our desperate efforts to get profnet fully functional again.

If you consider that packaging SNAP2 is more fruitful - may be other
software you would like to see inside Debian - we would rather
concentrate on this and would be happy to package your latest and
greatest code.

In general we would love to refresh the closer relation between RostLab
and Debian since Laszlo made us believe this would be quite fruitfully.
May be you would like to send a member of your lab to our next Sprint
which will happen somewhen in the beginning of next year in Berlin (to
be announced).  Such kind of sprint once was the entry point for Laszlo
into Debian.  Inside the Debian Med team we have quite a record for
teaching about Debian packaging which could be quite interesting for
you.

I'd be really happy to revive the connection again.

Kind regards

   Andreas.

On Tue, Oct 08, 2019 at 09:26:13AM +0200, Olivier Sallou wrote:
> 
> On 10/4/19 3:07 PM, Andreas Tille wrote:
> > Hi Olivier,
> >
> > On Fri, Oct 04, 2019 at 02:14:02PM +0200, olivier sallou wrote:
> >>> Program received signal SIGSEGV: Segmentation fault - invalid memory
> >>> reference.
> >> I really do not see what error could be. Maybe a fortran issue after an
> >> upgrade (something that was working but not done the same way now)
> >> Sorry, I have no skill to fix this kind of issue. Should be reported
> >> upstream
> > Since Laszlo changed his job we do not have real upstream contact.
> >  
> >> I see on their web site that it was superseeded by snap2 in 2015. So maybe
> >> time to let it go
> > Fine for me.  Where exactly did you found this? 
> 
> On https://rostlab.org/owiki/index.php/Snapfun:
> 
> """
> 
> 2015-07-23 : The Snapfun (SNAPweb service) has been superseded by an
> improved version of SNAP, named SNAP2. Requests for the SNAPweb service
> now point to SNAP2. If for some reason, you require the original SNAPweb
> service, please contact he...@rostlab.org. More information about SNAP2
> is available here.
> 
> """
> 
> 
> Snap2 links:
> 
> https://rostlab.org/owiki/index.php/Snap2
> 
> https://github.com/Rostlab/SNAP2
> 
> 
> >  I only found a snap^2
> > web interface.  What about the reverse depends of profnet?
> 
> this is indeed an issue, but if "old" release is not maintained anymore
> and if we don't have local skills on this
> 
> This kind of issue goes beyond "maintainer" packaging, need skills in
> language and software itself.
> 
> >
> > Kind regards
> >
> >   Andreas.
> >
> -- 
> Olivier Sallou
> Univ Rennes, Inria, CNRS, IRISA
> Irisa, Campus de Beaulieu
> F-35042 RENNES - FRANCE
> Tel: 02.99.84.71.95
> 
> gpg key id: 4096R/326D8438  (keyring.debian.org)
> Key fingerprint = 5FB4 6F83 D3B9 5204 6335  D26D 78DC 68DB 326D 8438
> 
> 

-- 
http://fam-tille.de

Bug#941984: backintime: files under the GFDL

[Sean Whitton]

Source: backintime
Version: 1.1.24-0.1
Severity: serious

Dear maintainer,

Files in the source package matching qt4/docbook/en/* look to be under
the GFDL, not the GPL, as implied by d/copyright.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#941983: ITP: hey -- hey is a tiny program that sends some load to a web application.

[Arthur Diniz]

Package: wnpp
Severity: wishlist
Owner: Arthur Diniz 

* Package name: hey
  Version : 0.1.2
  Upstream Author : Jaana B. Dogan 
* URL : https://github.com/rakyll/hey
* License : Apache-2.0
  Programming Lang: Go
  Description : hey is a tiny program that sends some load to a web 
application.

hey was originally called boom and was influenced from Tarek Ziade's tool at 
tarekziade/boom.
Using the same name was a mistake as it resulted in cases where binary name 
conflicts created confusion.
To preserve the name for its original owner, we renamed this project to hey.

Bug#941967: reassign 941967 to postgresql-common, forcibly merging 941967 941948

[Thorsten Glaser]

On Tue, 8 Oct 2019, Christoph Berg wrote:

> reassign 941967 postgresql-common 

Interestingly enough, the last postgresql-common update was
a week ago and did not introduce any errors (unless it’s the
combination of buggy postgresql-common and newer postgresql-11
of course).

bye,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

**

Mit der tarent Academy bieten wir auch Trainings und Schulungen in den
Bereichen Softwareentwicklung, Agiles Arbeiten und Zukunftstechnologien an.

Besuchen Sie uns auf www.tarent.de/academy. Wir freuen uns auf Ihren Kontakt.

**

Bug#941948: postgresql-common: postgresql fails to start via systemd

[Thorsten Glaser]

On Tue, 8 Oct 2019, Andreas Kurth wrote:

> A better fix is to add
> 
>   User=postgres
> 
> to the [Service] section of your systemd unit file. This should be

Note that systemd-less operation with sysvinit is also broken,
so that alone is no fix.

bye,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

**

Mit der tarent Academy bieten wir auch Trainings und Schulungen in den
Bereichen Softwareentwicklung, Agiles Arbeiten und Zukunftstechnologien an.

Besuchen Sie uns auf www.tarent.de/academy. Wir freuen uns auf Ihren Kontakt.

**