Bug#906626: mypy failure

[Salvo Tomaselli]

Hello,

thanks for your report. It is indeed failing to build, due to a newer
version of mypy that fails.

I suspect this is actually an issue with mypy,

See this example

NONETYPE = type(None)

def f(a) -> None:
if type(a) == NONETYPE:
pass

I will contact the mypy upstream about this.

But I intend to make a typedload update to workaround this.

Best

-- 
Salvo Tomaselli

"Io non mi sento obbligato a credere che lo stesso Dio che ci ha dotato di
senso, ragione ed intelletto intendesse che noi ne facessimo a meno."
-- Galileo Galilei

http://ltworf.github.io/ltworf/

Bug#906717: Print Screen key doesn't print screen but creates a local copy instead

[Jeffrey H. Ingber]

Package: GNOME
Version: 3.14

When I press the Print Screen key (the key located above the Num Lock key), a 
copy of the the screen is not sent to the printer.  A local copy is saved in my 
home directory instead.

I suggest pressing the Print Screen key sends a copy of the screen to the 
default printer.


I am using Debian GNU/Linux 8, kernel 3.16.0-6-686-pae
and libc6 2.19-18+deb8u10.

Bug#906451: tar-pack seems an unmaintained module

[Pirate Praveen]

On 2018, ഓഗസ്റ്റ് 20 1:17:52 AM IST, Sebastiaan Couwenberg  
wrote:
>I don't know, you should do a round of rebuilds to find out.

Rebuilds won't be enough I think because these are runtime dependencies. As 
they don't have functional autopkgtests enabled, we have to use upstream test 
suite to confirm.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Bug#906201: duktape: Please consider using a 'real' make target & clarify no debugging comment

[Carsten Schoenert]

Hello Thorsten,

On Sun, Aug 19, 2018 at 11:23:16PM +0200, Thorsten Alteholz wrote:
> Hi Chris,
> 
> On Wed, 15 Aug 2018, Chris Lamb wrote:
> > I just ACCEPTed duktape from NEW but was wondering if:
> 
> thanks a lot for accepting the package ...
> 
> >  cat debian/duktape.pc.in|sed "s/#TRIPLE#/$(DEB_HOST_MULTIARCH)/g" > 
> > debian/duktape.pc
> > 
> > … might be better written as a 'real' Make target?
> 
> ... but I am not really sure what you mean by 'real make target'?

I guess Chris wanted to say that you could turn the substition into a
Make traget so other targets can depend on it. I use very often
basically the following snippet for creating the "real" debhelper
sequencer files at build time.

> ...
> PREPROCESS_FILES := $(wildcard debian/*.in)
>
> $(PREPROCESS_FILES:.in=): %: %.in
> sed 's,/@DEB_HOST_MULTIARCH@,$(DEB_HOST_MULTIARCH:%=/%),g' $< > $@
>
> ...
> override_dh_auto_install: $(PREPROCESS_FILES:.in=)
> foo
> bar

The basic make target here can be even more complex and can be more
depending on PREPROCESS_FILES.

> $(PREPROCESS_FILES:.in=): %: %.in
> sed -e 's,/@DEB_HOST_MULTIARCH@,$(DEB_HOST_MULTIARCH:%=/%),g' \
> -e 's,/@PHP_VERSION@,$(PHP_VERSION:%=/%),g' \
> -e 's,/@PHP_API_DATE@,$(PHP_API_DATE:%=/%),g' $< > $@

Regards
Carsten

Bug#906716: rgbpaint FTCBFS: uses the build architecture compiler and pkg-config

[Helmut Grohne]

Source: rgbpaint
Version: 0.8.7-6
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

rgbpaint fails to cross build from source, because it uses the build
architecture compiler and pkg-config. Unlike autotools-generated
configure scripts, this hand written one does not understand the usual
--host flag. Instead one is supposed to pass a suitable CC environment
variable. It also hard codes the build architecture pkg-config leaving
no choice on replacing it. The attached patch make pkg-config
substitutable in ./configure and extends debian/rules to supply both
variables. The values are seeded from dpkg's buildtools.mk, which
generally does the right thing. It makes rgbpaint cross buildable.
Please consider applying it.

Helmut
diff --minimal -Nru rgbpaint-0.8.7/debian/changelog 
rgbpaint-0.8.7/debian/changelog
--- rgbpaint-0.8.7/debian/changelog 2016-04-06 16:04:37.0 +0200
+++ rgbpaint-0.8.7/debian/changelog 2018-08-20 06:18:10.0 +0200
@@ -1,3 +1,10 @@
+rgbpaint (0.8.7-6.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Use host tools for CC and PKG_CONFIG. (Closes: #-1)
+
+ -- Helmut Grohne   Mon, 20 Aug 2018 06:18:10 +0200
+
 rgbpaint (0.8.7-6) unstable; urgency=low
 
   * Set Standards-Version to 3.9.7, no changes.
diff --minimal -Nru rgbpaint-0.8.7/debian/patches/cross.patch 
rgbpaint-0.8.7/debian/patches/cross.patch
--- rgbpaint-0.8.7/debian/patches/cross.patch   1970-01-01 01:00:00.0 
+0100
+++ rgbpaint-0.8.7/debian/patches/cross.patch   2018-08-20 06:17:41.0 
+0200
@@ -0,0 +1,17 @@
+--- rgbpaint-0.8.7.orig/configure
 rgbpaint-0.8.7/configure
+@@ -146,11 +146,12 @@
+   echo "MT_VERSION=$MT_VERSION" >> $GTK_FILE
+   echo "MT_DATE=$MT_DATE" >> $GTK_FILE
+ 
++  : "${PKG_CONFIG:=pkg-config}"
+   if [ "$OS" = "GNU/Linux" ]
+   then
+   BIN_INSTALL=$LIN_BIN_INSTALL
+-  GTK_INCLUDE=`pkg-config gtk+-2.0 --cflags`
+-  GTK_LIB=`pkg-config gtk+-2.0 --libs`
++  GTK_INCLUDE=`$PKG_CONFIG gtk+-2.0 --cflags`
++  GTK_LIB=`$PKG_CONFIG gtk+-2.0 --libs`
+   else
+   BIN_INSTALL=$WIN_BIN_INSTALL
+   MT_LANG_DEST=locale
diff --minimal -Nru rgbpaint-0.8.7/debian/patches/series 
rgbpaint-0.8.7/debian/patches/series
--- rgbpaint-0.8.7/debian/patches/series2016-04-06 12:15:52.0 
+0200
+++ rgbpaint-0.8.7/debian/patches/series2018-08-20 06:15:50.0 
+0200
@@ -10,3 +10,4 @@
 10-fix_lib_underlinkage.diff
 11-hardening_errors.diff
 12-build_portability.diff
+cross.patch
diff --minimal -Nru rgbpaint-0.8.7/debian/rules rgbpaint-0.8.7/debian/rules
--- rgbpaint-0.8.7/debian/rules 2016-04-06 12:15:53.0 +0200
+++ rgbpaint-0.8.7/debian/rules 2018-08-20 06:18:07.0 +0200
@@ -3,6 +3,9 @@
 DPKG_EXPORT_BUILD_FLAGS = 1
 
 include /usr/share/dpkg/buildflags.mk
+-include /usr/share/dpkg/buildtools.mk
+export CC
+export PKG_CONFIG ?= pkg-config
 
 %:
dh $@

Bug#906715: ITP: lloconv -- command line document converter using libreofficekit

[Olly Betts]

Package: wnpp
Severity: wishlist
Owner: Olly Betts 

* Package name: lloconv
  Version : 6.1.0
  Upstream Author : Olly Betts 
* URL : https://gitlab.com/ojwb/lloconv
* License : MPL-2.0
  Programming Lang: C++
  Description : command line document converter using LibreOfficeKit

A command line document format converter which uses LibreOffice (via
its LibreOfficeKit API) to do all the hard work.  It should support
the same formats which LibreOffice does.

LibreOfficeKit was formerly known as liblibreoffice, hence the name
"lloconv".

Bug#906714: paraview: FTBFS in Sid

[Simon Quigley]

Package: paraview
Severity: serious

Dear Maintainer,

Your package fails to build from source in Sid. Here is the build log
after LocutusOfBorg triggered the build in debomatic:

http://debomatic-amd64.debian.net/distribution#unstable/paraview/5.4.1+dfsg4-3/buildlog

Please fix this.

Thanks.

-- 
Simon Quigley
tsimo...@ubuntu.com
tsimonq2 on freenode and OFTC
5C7A BEA2 0F86 3045 9CC8
C8B5 E27F 2CF8 458C 2FA4



signature.asc
Description: OpenPGP digital signature

Bug#906713: libkwalletbackend5-5: under 5.49.0-1 chromium does not call up kwallet

[Arthur Marsh]

Package: libkwalletbackend5-5
Version: 5.47.0-1
Severity: important

Dear Maintainer,

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

   * What led up to the situation?

upgrading kwallet related libraries from 5.47 to 5.49 I couldn't not access
my passwords stored in kwallet for chromium.

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

downgrading and restarting plasma desktop restored chromium calling kwallet

   * What was the outcome of this action?
   * What outcome did you expect instead?

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


-- System Information:
Debian Release: buster/sid
  APT prefers experimental
  APT policy: (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.18.0+ (SMP w/4 CPU cores; PREEMPT)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)

Versions of packages libkwalletbackend5-5 depends on:
ii  libc6 2.27-5
ii  libgcrypt20   1.8.3-1
ii  libgpgme111.11.1-1
ii  libgpgmepp6   1.11.1-1
ii  libkf5i18n5   5.47.0-1
ii  libkf5notifications5  5.47.0-1
ii  libkf5widgetsaddons5  5.47.0-1
ii  libqt5core5a  5.11.1+dfsg-6
ii  libstdc++68.2.0-4

libkwalletbackend5-5 recommends no packages.

libkwalletbackend5-5 suggests no packages.

-- no debconf information

Bug#850156: Please firmly deprecate vendor-specific series files [and 1 more messages]

[Russ Allbery]

Guillem Jover  writes:

> But for the Ubuntu case, which is what I was explicitly discussing with
> Steve, the reality is slightly different. The Ubuntu organization is
> reigned by their own rules, and it's a different entity to Debian, and
> how they reach their conclusions and policies is for them to decide, and
> even if how they do that might not be my cup of tea, I'm just not
> involved and I don't think it's my place to question their processes.

> So, if Ubuntu, as an organization, decides that the ubuntu.series file
> is not good for them, and they are going to ban it no matter what,
> probably at their boundaries. Asking ftp-masters or lintian maintainers
> to honor that wish and do that for them would just help them, and not
> change the outcome much. Those two teams could obviously decide they do
> not want to be in the middle of possibly angry maintainers and the
> derivative, but that's for these teams to decide. I'm not sure why we'd
> reject that at the Debian level TBH. It's also in their namespace so it
> seems only fair they get to have a say IMO.

Very belatedly, thank you, this makes a lot of sense.  I hadn't thought
about the angle of the most likely vendor to be used in a vendor-specific
series file deciding whether they want this feature to be used at all.
When you point that out, it makes perfect sense to me that Ubuntu should
be able to decide via their own project governance methods if this is a
feature that Ubuntu doesn't want.

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

Bug#905964: update-inetd: "update-inetd --disable dict" fails on missing /etc/inetd.conf

[Guillem Jover]

Hi!

On Sun, 2018-08-12 at 14:50:28 +0200, Roland Rosenfeld wrote:
> Package: update-inetd
> Version: 4.46
> Severity: important

> I had to notice that installing package dictd on a sid chroot fails
> since update-inetd was upgraded from 4.45 to 4.46.
> (see CI logs of ding which installs dictd as a test dependency:
> https://ci.debian.net/packages/d/ding/unstable/amd64/).

Sorry about that, I've got now a fix for this locally, and will upload
an update-inetd package tomorrow.

> I tracked this down a little and in the postinst of dictd I find the
> following code:
> update-inetd --disable dict
> (which is called if dictd should run as daemon instead via inetd).
> 
> On this chroot no /etc/inetd.conf exists.  So I expected that
>  update-inetd --disable dict 
> should simply terminate with return code 0 (as it does with 4.45), but
> the 4.46 version terminates with return code 2, which leads
> dictd.postinst to fail.

I guess it does make sense to consider disabling and removing services
when there's no inetd.conf to be no-ops, as it's equivalent to an already
disabled or removed action.

> For testing I downgraded to 4.45 and now it works as expected again:
> 
> root@dinghy:/var/lib/dpkg/info# dpkg -i /tmp/update-inetd_4.45_all.deb 
> dpkg: warning: downgrading update-inetd from 4.46 to 4.45
> (Reading database ... 15458 files and directories currently installed.)
> Preparing to unpack /tmp/update-inetd_4.45_all.deb ...
> Unpacking update-inetd (4.45) over (4.46) ...
> Setting up update-inetd (4.45) ...
> root@dinghy:/var/lib/dpkg/info# update-inetd --disable dict
> root@dinghy:/var/lib/dpkg/info# echo $?
> 0
> 
> 
> Since this looks like a bug in update-inetd I report the bug against
> update-inetd and not against dictd.

Sure. Although dictd and many other package are actually in a way
buggy, because they do not follow the stated "contract" of the
update-inetd interface, which is that only inet-superserver providing
packages should depend on that one, because it's considered an
implementation detail of the superserver, and service should instead
depend on an inet-superserver virtual + readl package..

But, given that I'd like to soon start switching to declarative inetd
support, fixing this right now seems a bit pointless anyway. :)

Thanks,
Guillem

Bug#906711: appstream glib error - not fixed in 0.12.2-2

[Matthias Klumpp]

2018-08-20 3:41 GMT+02:00 william l-k :
> Package: appstream
> Version: 0.12.2-2
> Severity: normal
>
> Dear Maintainer,
>
> There were a number of bugs reported for appstream associated with glib
> assertion failures. After upgrading from 0.12.2-1 to 0.12.2-2 there is still 
> an
> assertion failure:
>
> (appstreamcli:18922): GLib-CRITICAL **: 20:19:06.758: g_variant_builder_end:
> assertion '!GVSB(builder)->uniform_item_types || GVSB(builder)->prev_item_type
> != NULL || g_variant_type_is_definite (GVSB(builder)->type)' failed
>
> (appstreamcli:18922): GLib-CRITICAL **: 20:19:06.758: g_variant_new_variant:
> assertion 'value != NULL' failed
>
> (appstreamcli:18922): GLib-ERROR **: 20:19:06.758: g_variant_new_parsed:
> 11-13:invalid GVariant format string

This indeed looks like a different issue from the one that appeared before.
I can not reproduce it here though, neither on Debian Testing nor on
Debian unstable.

Do you have any 3rd-party repos enabled?
Can you attach the output of `appstreamcli status` as well as of this
command please?

find /var/lib/app-info/ /var/cache/app-info/ /usr/share/app-info/ -not
-path "*/icons/*"

Cheers,
Matthias

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

Bug#892402: shiboken: diff for NMU version 1.2.2-5.1

[Adrian Bunk]

Control: tags 892402 + patch
Control: tags 892402 + pending

Dear maintainer,

I've prepared an NMU for shiboken (versioned as 1.2.2-5.1) and uploaded 
it to DELAYED/15. Please feel free to tell me if I should cancel it.

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

diff -Nru shiboken-1.2.2/debian/changelog shiboken-1.2.2/debian/changelog
--- shiboken-1.2.2/debian/changelog	2017-08-18 21:42:31.0 +0300
+++ shiboken-1.2.2/debian/changelog	2018-08-20 05:22:26.0 +0300
@@ -1,3 +1,11 @@
+shiboken (1.2.2-5.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop the g++-6 build dependency on mips64el,
+the gcc bug is fixed. (Closes: #892402)
+
+ -- Adrian Bunk   Mon, 20 Aug 2018 05:22:26 +0300
+
 shiboken (1.2.2-5) unstable; urgency=medium
 
   * Team upload.
diff -Nru shiboken-1.2.2/debian/control shiboken-1.2.2/debian/control
--- shiboken-1.2.2/debian/control	2017-08-18 21:42:31.0 +0300
+++ shiboken-1.2.2/debian/control	2018-08-20 05:22:26.0 +0300
@@ -11,9 +11,7 @@
  python-all-dev (>= 2.6.6-3), python-all-dbg (>= 2.6.6-3),
  python-numpy, python-numpy-dbg,
  python3-all-dev, python3-all-dbg,
- python3-numpy, python3-numpy-dbg,
-# Use gcc-6 on mips64el, to drop once #871514 is fixed
- g++-6 [mips64el]
+ python3-numpy, python3-numpy-dbg
 Build-Depends-Indep: python-sphinx
 X-Python-Version: >= 2.6
 X-Python3-Version: >= 3.3
diff -Nru shiboken-1.2.2/debian/rules shiboken-1.2.2/debian/rules
--- shiboken-1.2.2/debian/rules	2017-08-18 21:42:31.0 +0300
+++ shiboken-1.2.2/debian/rules	2018-08-20 05:22:26.0 +0300
@@ -15,14 +15,6 @@
 CMAKE_COMMON_OPTIONS := -DCMAKE_SKIP_RPATH=true \
 			-DLIB_SUFFIX=/$(DEB_HOST_MULTIARCH)
 
-# Use gcc-6 on mips64el, to drop once #871514 is fixed
-DEB_HOST_ARCH ?= $(shell dpkg-architecture -qDEB_HOST_ARCH)
-ifeq ($(DEB_HOST_ARCH),mips64el)
-	export CC=gcc-6
-	export GCC=gcc-6
-	export CXX=g++-6
-endif
-
  CONFIGURE 
 
 override_dh_auto_configure: configure_2 configure_3

Bug#906687: pymongo breaks python-motor autopkgtest

[A. Jesse Jiryu Davis]

Hi, I'm the upstream author of Motor. Motor is 2.0 now and its tests
work with PyMongo 3.7.1 in my testing systems. I've only been testing
the latest Motor against recent PyMongo versions; I haven't tested
older Motor with the latest PyMongo. Does Motor 2.0's test suite pass
with the PyMongo 3.7.1 Debian package?

Bug#906712: mrs fails on several architectures: undefined reference to __atomic_*

[Adrian Bunk]

Source: mrs
Version: 6.0.5+dfsg-6
Severity: important
Tags: patch ftbfs

https://buildd.debian.org/status/package.php?p=mrs=sid

...
obj/M6Progress.o: In function `M6Progress::Consumed(long long)':
/usr/include/c++/7/bits/atomic_base.h:312: undefined reference to 
`__atomic_fetch_add_8'
obj/M6Progress.o: In function `M6Progress::Progress(long long)':
/usr/include/c++/7/bits/atomic_base.h:374: undefined reference to 
`__atomic_store_8'
obj/M6Progress.o: In function `M6Progress::~M6Progress()':
/usr/include/c++/7/bits/atomic_base.h:374: undefined reference to 
`__atomic_store_8'
obj/M6Progress.o: In function `M6ProgressImpl::PrintProgress()':
/usr/include/c++/7/bits/atomic_base.h:396: undefined reference to 
`__atomic_load_8'
obj/M6Progress.o: In function `M6ProgressImpl::Run()':
/usr/include/c++/7/bits/atomic_base.h:396: undefined reference to 
`__atomic_load_8'
/usr/include/c++/7/bits/atomic_base.h:396: undefined reference to 
`__atomic_load_8'
/usr/include/c++/7/bits/atomic_base.h:396: undefined reference to 
`__atomic_load_8'
collect2: error: ld returned 1 exit status
GNUmakefile:100: recipe for target 'mrs' failed
make[1]: *** [mrs] Error 1


Fix:

--- debian/rules.old2018-08-20 00:03:16.554691756 +
+++ debian/rules2018-08-20 00:04:35.053856249 +
@@ -2,6 +2,10 @@
 
 export DEB_BUILD_MAINT_OPTIONS = hardening=+all
 
+ifneq (,$(filter $(DEB_HOST_ARCH), armel m68k mips mipsel powerc powerpcspe 
sh4))
+  export DEB_LDFLAGS_MAINT_APPEND=-latomic
+endif
+
 DH_VERBOSE := 1
 
 %:

Bug#906698: anbox-session-manager segmentation fault

[Shengjing Zhu]

On Mon, Aug 20, 2018 at 4:39 AM Javier Barroso  wrote:
>
> Package: anbox
> Version: 0.0~git20180709-1
> Severity: important
>
[...]
>
> $ LANG=C anbox session-manager
> Stack trace (most recent call last) in thread 6908:
> #10   Object "[0x]", at 0x, in
> #9Object "/lib/x86_64-linux-gnu/libc.so.6", at 0x7fe1d86aeede, in clone
> #8Object "/lib/x86_64-linux-gnu/libpthread.so.0", at 0x7fe1d96d4f29, in
> #7Object "anbox", at 0x55fdc495daf4, in emugl::Thread::thread_main(void*)
> #6Object "anbox", at 0x55fdc488557a, in RenderThread::main()
> #5Object "anbox", at 0x55fdc497c81f, in
> gles2_decoder_context_t::decode(void*, unsigned long, IOStream*)
> #4Object "/usr/lib/x86_64-linux-gnu/dri/i965_dri.so", at 0x7fe1ccca39d2, 
> in
> #3Object "/usr/lib/x86_64-linux-gnu/dri/i965_dri.so", at 0x7fe1ccca3261, 
> in
> #2Object "/usr/lib/x86_64-linux-gnu/dri/i965_dri.so", at 0x7fe1ccf0e880, 
> in
> #1Object "/usr/lib/x86_64-linux-gnu/dri/i965_dri.so", at 0x7fe1ccf1c7b7, 
> in
> #0Object "/usr/lib/x86_64-linux-gnu/dri/i965_dri.so", at 0x7fe1ccf24349, 
> in
> Segmentation fault (Address not mapped to object [0x7c])
>
> What can I do ? Can I provide the info that you need to debug this issue
>

I think it's caused by recent changes to mesa. Could you paste output
of `anbox system-info`. I suspect there's something wrong in
`graphics` section.

-- 
Best regards,
Shengjing Zhu

Bug#906674: consequences to deleting a (generic name) alternative? - reverse dependencies on ImageMagick binaries?

[Zenaan Harkness]

ImageMagick (IM) seems to be needed (at least on XFCE desktop) for
the PDF printer (cups-filters). There are many apparent rdepends of
IM, from a2ps and devede to inkscape and sunclock.

ImageMagick in Debian stable is a bit of a bush pig, dominating the
/usr/bin default PATH namespace with a number of excessively generic
verbs.

Although the files are apparently strictly versioned:

/usr/bin/animate-im6.q16
/usr/bin/compare-im6.q16
/usr/bin/composite-im6.q16
/usr/bin/conjure-im6.q16
/usr/bin/convert-im6.q16
/usr/bin/display-im6.q16
/usr/bin/identify-im6.q16
/usr/bin/import-im6.q16
/usr/bin/mogrify-im6.q16
/usr/bin/montage-im6.q16
/usr/bin/stream-im6.q16


, alternatives are put in place:

/usr/bin/animate -> /etc/alternatives/animate
/usr/bin/animate-im6 -> /etc/alternatives/animate-im6
/usr/bin/animate-im6.q16
/usr/bin/compare -> /etc/alternatives/compare
/usr/bin/compare-im6 -> /etc/alternatives/compare-im6
/usr/bin/compare-im6.q16
/usr/bin/composite -> /etc/alternatives/composite
/usr/bin/composite-im6 -> /etc/alternatives/composite-im6
/usr/bin/composite-im6.q16
/usr/bin/conjure -> /etc/alternatives/conjure
/usr/bin/conjure-im6 -> /etc/alternatives/conjure-im6
/usr/bin/conjure-im6.q16
/usr/bin/convert -> /etc/alternatives/convert
/usr/bin/convert-im6 -> /etc/alternatives/convert-im6
/usr/bin/convert-im6.q16
/usr/bin/display -> /etc/alternatives/display
/usr/bin/display-im6 -> /etc/alternatives/display-im6
/usr/bin/display-im6.q16
/usr/bin/identify -> /etc/alternatives/identify
/usr/bin/identify-im6 -> /etc/alternatives/identify-im6
/usr/bin/identify-im6.q16
/usr/bin/import -> /etc/alternatives/import
/usr/bin/import-im6 -> /etc/alternatives/import-im6
/usr/bin/import-im6.q16
/usr/bin/mogrify -> /etc/alternatives/mogrify
/usr/bin/mogrify-im6 -> /etc/alternatives/mogrify-im6
/usr/bin/mogrify-im6.q16
/usr/bin/montage -> /etc/alternatives/montage
/usr/bin/montage-im6 -> /etc/alternatives/montage-im6
/usr/bin/montage-im6.q16
/usr/bin/stream -> /etc/alternatives/stream
/usr/bin/stream-im6 -> /etc/alternatives/stream-im6
/usr/bin/stream-im6.q16


There is no "magick" command (or alternative), yet it seems as though
there is meant to be a "magick" program:
http://www.imagemagick.org/script/command-line-tools.php

Perhaps this "magick" command is only available in newer versions of
ImageMagick?


Anyway, "import" gets in the way, and others such as "convert",
"stream", "identify" and "display" really dominate those respective
generic namespaces, and in this particular case, are directly
obstructing:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=906674


"Alternatives" provides for choosing amongst "functionally the same"
alternatives, or "deleting" the generic name.


My question is, can I safely remove the symbolic link "generic"
names applied by the IM package, or IM's reverse dependencies going
to bite me?

TIA,

Bug#906711: appstream glib error - not fixed in 0.12.2-2

[william l-k]

Package: appstream
Version: 0.12.2-2
Severity: normal

Dear Maintainer,

There were a number of bugs reported for appstream associated with glib
assertion failures. After upgrading from 0.12.2-1 to 0.12.2-2 there is still an
assertion failure:

(appstreamcli:18922): GLib-CRITICAL **: 20:19:06.758: g_variant_builder_end:
assertion '!GVSB(builder)->uniform_item_types || GVSB(builder)->prev_item_type
!= NULL || g_variant_type_is_definite (GVSB(builder)->type)' failed

(appstreamcli:18922): GLib-CRITICAL **: 20:19:06.758: g_variant_new_variant:
assertion 'value != NULL' failed

(appstreamcli:18922): GLib-ERROR **: 20:19:06.758: g_variant_new_parsed:
11-13:invalid GVariant format string


Previously appstream tripped up on:

 appstreamcli refresh-cache




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

Kernel: Linux 4.17.0-1-amd64 (SMP w/4 CPU cores)
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 appstream depends on:
ii  libappstream4  0.12.2-1
ii  libc6  2.27-5
ii  libglib2.0-0   2.56.1-2

appstream recommends no packages.

Versions of packages appstream suggests:
ii  apt-config-icons  0.12.2-1
ii  curl  7.61.0-1

-- debconf-show failed

Bug#885180: Bug#906708: hepmc: FTBFS on i386 / arm64 / ppc64el / s390x

[Adrian Bunk]

Control: tags 906708 patch

On Sun, Aug 19, 2018 at 08:45:44PM -0400, Boyuan Yang wrote:
> Source: hepmc
> Version: 2.06.09-2
> Severity: serious
> X-Debbugs-CC: cdlumin...@gmail.com b...@debian.org lifong...@gmail.com
> 
> A team upload was made by Mo Zhou to remove multiarch-support pre-dependency 
> as well as fixing the FTBFS. However, the problem is not completely solved. 
> Package hepmc still FTBFS on several release architectures.
> 
> Mo Zhou told me that he will not attempt to fix those FTBFS since he is not 
> confident enough to provide a satisfactory patch, especially when it's a 
> scientific software from CERN.

Fix attached.

> Regards,
> Boyuan Yang

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

>From 2b9ec7bbdb99f721f53ee02b4cafec8e6d035c48 Mon Sep 17 00:00:00 2001
From: Andrii Verbytskyi 
Date: Mon, 29 Aug 2016 13:43:21 +0200
Subject: First set of small fixes

[ only the part required for #906708 ]

--- a/test/testSimpleVector.cc	2018-08-20 01:21:14.923985913 +
+++ b/test/testSimpleVector.cc	2018-08-20 01:21:17.508019107 +
@@ -14,7 +14,7 @@
   
   HepMC::ThreeVector v3copy( v3 );

-  double eps = 1.e-15; // allowed differnce between doubles
+  double eps = 4.e-15; // allowed difference between doubles
   int numbad = 0;
  
   double x = v3.x();

Bug#906710: pynagram: Should this package be removed?

[Boyuan Yang]

Source: pynagram
Version: 1.0.1-1
Severity: important
User: debian...@lists.debian.org
Usertags: proposed-removal
X-Debbugs-CC: python-apps-t...@lists.alioth.debian.org 
umang...@gmail.com

Dear pynagram maintainer,

I recently found that you are listed as the maintainer of package 
pynagram in Debian. However, package pynagram didn't receive any 
uploads since 2011 and its upstream on launchpad seems to be dead 
since 2011. Currently package pynagram is affected by Debian's Qt4 
Removal [1] and there seems to be no sign for pynagram to be ported 
to Qt5.

As a result, I'm wondering if you are still going to maintain package 
pynagram and possibly migrate it to (py)Qt5. If you are not able to 
make uploads in the forseeable future, please tell us in a timely 
manner so that the package can be dealt properly for QA purposes.

To ensure that the package can be taken care of in a reasonable 
period of time, I will try to submit a Removal bug for package 
pynagram in Debian if there's no reply in 31 days.

Thanks and looking forward to hearing from you.

--
Best Regards,
Boyuan Yang



[1] https://wiki.debian.org/Qt4Removal

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

Bug#906709: hepmc: Please update the Homepage: field

[Adrian Bunk]

Source: hepmc
Version: 2.06.09-2
Severity: minor

The new homepage seems to be http://hepmc.web.cern.ch/hepmc/

Bug#897576: Possible workaround

[tvaz]

The way I found to make it work is setting a default project path, as 
suggested in the following comment:


https://bugs.launchpad.net/ubuntu/+source/monodevelop/+bug/1682779/comments/9

Hope it helps, although the software is indeed badly bugged on this.

Bug#906708: hepmc: FTBFS on i386 / arm64 / ppc64el / s390x

[Boyuan Yang]

Source: hepmc
Version: 2.06.09-2
Severity: serious
X-Debbugs-CC: cdlumin...@gmail.com b...@debian.org lifong...@gmail.com

A team upload was made by Mo Zhou to remove multiarch-support pre-dependency 
as well as fixing the FTBFS. However, the problem is not completely solved. 
Package hepmc still FTBFS on several release architectures.

Mo Zhou told me that he will not attempt to fix those FTBFS since he is not 
confident enough to provide a satisfactory patch, especially when it's a 
scientific software from CERN.


--
Regards,
Boyuan Yang

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

Bug#874877: [freecad] Future Qt4 removal from Buster

[Adrian Bunk]

On Sat, Sep 09, 2017 at 11:18:15PM +0200, W. Martin Borgert wrote:
> On 2017-09-09 21:04, Lisandro Damián Nicanor Pérez Meyer wrote:
> > = Porting =
> >
> > Some of us where involved in various Qt4 to Qt5 migrations [migration] and 
> > we
> > know for sure that porting stuff from Qt4 to Qt5 is much much easier and 
> > less
> > painful than it was from Qt3 to Qt4.
> 
> If I understand the various posts in the FreeCAD forums correct,
> they seem to go for PySide2. It would be very helpful, if the
> Debian Qt maintainers could package PySide2! Maybe before Qt4 is
> removed, because otherwise some packages have to be removed just
> to introduce them again. I don't think that packaging PySide2
> outside of the Qt team makes sense, because PySide2 will be the
> "official" Python API of Qt, if I'm not mistaken.
> -- 
> "Furthermore, I consider that PySide2 must be packaged" -- Qt the Elder

pyside2 is now in unstable:
https://tracker.debian.org/pkg/pyside2

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#906707: thunderbird build depends on LLVM 4.0 which is scheduled for removal

[Adrian Bunk]

Source: thunderbird
Version: 1:60.0-1
Severity: serious
Control: block 893401 by -1

llvm-toolchain-4.0 is scheduled for removal, see #893401.

Bug#905232: stretch-pu: package brltty/5.4-7+deb9u1

[Cyril Brulebois]

Control: tag -1 - moreinfo

Hi,

Samuel Thibault  (2018-08-17):
> Adam D. Barratt, le ven. 17 août 2018 16:18:05 +0100, a ecrit:
> > On Wed, 2018-08-01 at 19:09 +0200, Samuel Thibault wrote:
> > > The story is that the policykit-1 package was patched in unstable
> > > with 0.115/Fix-CVE-2018-1116-Trusting-client-supplied-UID.patch
> > > to fix a CVE, and we have noticed that it completely breaks polkit
> > > authentication in brlapi, which means that braille does not work in
> > > graphical sessions, reported as bug #905058.  This is actually due to
> > > a misuse of the polkit API in brltty, which only got to pose problem
> > > with the addition of that policykit patch. A brltty fix has been
> > > uploaded to unstable so the issue is fixed there.  policykit
> > > maintainers however plan to upload their patch to stretch, so we need
> > > to upload the brltty fix in stretch too.
> > 
> > Thanks for fixing this. As brltty produces a udeb, this needs a KiBi-
> > ack; tagged and CCing accordingly.
> 
> Well, the brltty udeb doesn't contain polkit support, so it should be a
> no-op, but better have KiBi aware of the new version indeed :)

This looked like a case where I could toy with diffoscope to verify this
claim (well, I'm not doubting you, really), and it seems that there's
only a timestamp change (along with the build ID, obviously) in the
sbin/brltty binary.

No objections, thanks.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#906706: nifti2dicom should unconditionally build depend on libinsighttoolkit4-dev

[Adrian Bunk]

Source: nifti2dicom
Version: 0.4.11-1
Severity: important
Tags: ftbfs

https://buildd.debian.org/status/package.php?p=nifti2dicom=sid

...
CMake Error at CMakeLists.txt:41 (find_package):
  By not providing "FindITK.cmake" in CMAKE_MODULE_PATH this project has
  asked CMake to find a package configuration file provided by "ITK", but
  CMake did not find one.

  Could not find a package configuration file provided by "ITK" with any of
  the following names:

ITKConfig.cmake
itk-config.cmake



Please change the
  libinsighttoolkit4-dev (>= 4.3.0) [i386 amd64] | libinsighttoolkit3-dev,
build dependency to
  libinsighttoolkit4-dev
for avoiding these fruitless build attempts.

Bug#906705: reprozip FTBFS on !amd64/i386/x32: error Unrecognized architecture!

[Adrian Bunk]

Source: reprozip
Version: 1.0.10-1
Severity: important
Tags: ftbfs

https://buildd.debian.org/status/package.php?p=reprozip=sid

...
aarch64-linux-gnu-gcc -pthread -DNDEBUG -g -fwrapv -O2 -Wall 
-Wstrict-prototypes -g -O2 -fdebug-prefix-map=/«PKGBUILDDIR»=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
-D_FORTIFY_SOURCE=2 -fPIC -I/usr/include/python3.6m -c native/pytracer.c -o 
build/temp.linux-arm64-3.6/native/pytracer.o
In file included from native/tracer.h:4:0,
 from native/pytracer.c:4:
native/config.h:12:9: error: #error Unrecognized architecture!
 #   error Unrecognized architecture!
 ^
error: command 'aarch64-linux-gnu-gcc' failed with exit status 1


If this is not fixable, the
  Architecture: linux-any
should be changed to
  Architecture: amd64 i386 x32

Bug#906704: RM: camlpdf [armel] -- RoQA; FTBFS on bytecode architectures

[Adrian Bunk]

Package: ftp.debian.org
Severity: normal

ocaml (4.05.0-10) unstable; urgency=medium

  * Drop support for ocamlopt on armel as suggested by upstream.
...
 -- Ximin Luo   Wed, 04 Oct 2017 14:14:39 +0200


This causes:
https://buildd.debian.org/status/logs.php?pkg=camlpdf=armel

Bug#906703: wiredtiger: python-wiredtiger should also be Architecture: amd64

[Adrian Bunk]

Source: wiredtiger
Version: 2.9.3+ds-1
Severity: important
Tags: ftbfs

https://buildd.debian.org/status/package.php?p=wiredtiger=sid

...
   dh_shlibdeps -a -O--parallel
dpkg-shlibdeps: error: cannot find library libwiredtiger.so.0 needed by 
debian/python-wiredtiger/usr/lib/python2.7/dist-packages/_wiredtiger.aarch64-linux-gnu.so
 (ELF format: 'elf64-littleaarch64' abi: '020100b7'; RPATH: '')
dpkg-shlibdeps: error: cannot find library libwiredtiger.so.0 needed by 
debian/python-wiredtiger/usr/lib/python2.7/dist-packages/_workgen.aarch64-linux-gnu.so
 (ELF format: 'elf64-littleaarch64' abi: '020100b7'; RPATH: '')
dpkg-shlibdeps: error: cannot continue due to the errors listed above
Note: libraries are not searched in other binary packages that do not have any 
shlibs or symbols file.


There is no point in trying to build the python module
on architectures where the library is not built.

Bug#906371: Probable new default version of Java issue: Bug#906371: jmodeltest: FTBFS in buster/sid

[Emmanuel Bourg]

On 17/08/2018 14:56, Andreas Tille wrote:

> Hi Debian Java team,
> 
> do you have any hint how to deal with this issue?

The actual error is:

[javac]
/build/1st/jmodeltest-2.1.10+dfsg/src/main/java/es/uvigo/darwin/jmodeltest/ModelTestService.java:28:
error: package parser does not exist
[javac] import parser.ParseException;
[javac]  ^
[javac]
/build/1st/jmodeltest-2.1.10+dfsg/src/main/java/es/uvigo/darwin/jmodeltest/ModelTestService.java:29:
error: package converter does not exist
[javac] import converter.Converter;
[javac] ^
[javac]
/build/1st/jmodeltest-2.1.10+dfsg/src/main/java/es/uvigo/darwin/jmodeltest/ModelTestService.java:30:
error: package converter does not exist
[javac] import converter.DefaultFactory;
[javac] ^
[javac]
/build/1st/jmodeltest-2.1.10+dfsg/src/main/java/es/uvigo/darwin/jmodeltest/ModelTestService.java:31:
error: package converter does not exist
[javac] import converter.Factory;
[javac] ^

There is an issue with a dependency (alter-sequence-alignment maybe?),
the Java version isn't to blame here.

Emmanuel Bourg

Bug#906042: stretch-pu: package libxcursor/1:1.1.14-1+deb9u2

[Cyril Brulebois]

Control: tag -1 - moreinfo

Hi Adam,

Adam D. Barratt  (2018-08-17):
> I managed to miss that the package produces a udeb, so this needs a
> KiBi-ack before acceptance; tagging and CCing accordingly.

No objections here, thanks for checking.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#905762: stretch-pu: package wpa/2:2.4-1+deb9u2

[Cyril Brulebois]

Hi Adam,

Adam D. Barratt  (2018-08-17):
> Control: tags -1 + moreinfo d-i
> 
> On Thu, 2018-08-09 at 09:31 +0200, Andrej Shadura wrote:
> > I would like to fix CVE-2018-14526 (#905739) in stable:
> > 
> > CVE-2018-14526[0]:
> > > An issue was discovered in rsn_supp/wpa.c in wpa_supplicant 2.0
> > > through 2.6. Under certain conditions, the integrity of EAPOL-Key
> > > messages is not checked, leading to a decryption oracle. An
> > > attacker
> > > within range of the Access Point and client can abuse the
> > > vulnerability to recover sensitive information.
> > 
> > This is a low priority security issue, and doesn't require a DSA.
> > 
> > [0] https://security-tracker.debian.org/tracker/CVE-2018-14526
> 
> As wpa builds a udeb, this will need a KiBi-ack; CCing and tagging
> accordingly.

No objections. Not sure whether you wanted to +confirm it, so I'll leave
tagging up to you.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#906702: Please provide option to prevent elinks from indenting text

[martin f krafft]

Package: elinks
Version: 0.12~pre6-13
Severity: wishlist

elinks seems to indent the HTML body text. This is not always
desirable, especially not in dump mode. Please provide a means to
disable this.

-- System Information:
Debian Release: buster/sid
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages elinks depends on:
ii  debconf [debconf-2.0]  1.5.66
ii  elinks-data0.12~pre6-13
ii  libbz2-1.0 1.0.6-8.1
ii  libc6  2.27-5
ii  libcomerr2 1.44.1-2
ii  libexpat1  2.2.5-3
ii  libfsplib0 0.11-2
ii  libgnutls303.5.18-1
ii  libgpm21.20.7-5
ii  libgssapi-krb5-2   1.16-2
ii  libidn11   1.33-2.2
ii  libk5crypto3   1.16-2
ii  libkrb5-3  1.16-2
ii  liblua5.1-05.1.5-8.1+b2
ii  libperl5.265.26.2-3
ii  libtre50.8.0-6
ii  zlib1g 1:1.2.11.dfsg-1

elinks recommends no packages.

Versions of packages elinks suggests:
pn  elinks-doc  

-- debconf-show failed


-- 
 .''`.   martin f. krafft  @martinkrafft
: :'  :  proud Debian developer
`. `'`   http://people.debian.org/~madduck
  `-  Debian - when you have better things to do than fixing systems


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Bug#906201: duktape: Please consider using a 'real' make target & clarify no debugging comment

[Thorsten Alteholz]

Hi Chris,

On Wed, 15 Aug 2018, Chris Lamb wrote:

I just ACCEPTed duktape from NEW but was wondering if:


thanks a lot for accepting the package ...


 cat debian/duktape.pc.in|sed "s/#TRIPLE#/$(DEB_HOST_MULTIARCH)/g" > 
debian/duktape.pc

… might be better written as a 'real' Make target?


... but I am not really sure what you mean by 'real make target'?

  Thorsten

Bug#906701: peewee FTBFS with Python 3.7 as supported version

[Adrian Bunk]

Source: peewee
Version: 2.10.2+dfsg-2
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/package.php?p=peewee=sid

...
= test session starts ==
platform linux -- Python 3.7.0, pytest-3.6.2, py-1.5.3, pluggy-0.6.0
rootdir: /<>/peewee-2.10.2+dfsg, inifile:
collected 383 items

tests.py ... [ 16%]
 [ 35%]
 [ 54%]
 [ 72%]
...FFF.. [ 91%]
 [100%]

=== FAILURES ===
_ TestQueryResultWrapper.test_iterator _

self = 

def iterator(self):
while True:
>   yield self.iterate()

peewee.py:2353: 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 

self = 

def iterate(self):
row = self.cursor.fetchone()
if not row:
self._populated = True
if not getattr(self.cursor, 'name', None):
self.cursor.close()
>   raise StopIteration
E   StopIteration

peewee.py:2345: StopIteration

The above exception was the direct cause of the following exception:

self = 

def test_iterator(self):
User.create_users(10)

with self.assertQueryCount(1):
qr = User.select().order_by(User.id).execute()
>   usernames = [u.username for u in qr.iterator()]

playhouse/tests/test_query_results.py:111: 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 

.0 = 

>   usernames = [u.username for u in qr.iterator()]
E   RuntimeError: generator raised StopIteration

playhouse/tests/test_query_results.py:111: RuntimeError
-- Captured log call ---
peewee.py 3826 DEBUG('DROP TABLE IF EXISTS "comment"', [])
peewee.py 3826 DEBUG('DROP TABLE IF EXISTS "blog"', [])
peewee.py 3826 DEBUG('DROP TABLE IF EXISTS "users"', [])
peewee.py 3826 DEBUG('CREATE TABLE "users" ("id" INTEGER 
NOT NULL PRIMARY KEY, "username" VARCHAR(255) NOT NULL)', [])
peewee.py 3826 DEBUG('CREATE TABLE "blog" ("pk" INTEGER NOT 
NULL PRIMARY KEY, "user_id" INTEGER NOT NULL, "title" VARCHAR(25) NOT NULL, 
"content" TEXT NOT NULL, "pub_date" DATETIME, FOREIGN KEY ("user_id") 
REFERENCES "users" ("id"))', [])
peewee.py 3826 DEBUG('CREATE INDEX "blog_user_id" ON "blog" 
("user_id")', [])
peewee.py 3826 DEBUG('CREATE TABLE "comment" ("id" INTEGER 
NOT NULL PRIMARY KEY, "blog_id" INTEGER NOT NULL, "comment" VARCHAR(255) NOT 
NULL, FOREIGN KEY ("blog_id") REFERENCES "blog" ("pk"))', [])
peewee.py 3826 DEBUG('CREATE INDEX "comment_blog_id" ON 
"comment" ("blog_id")', [])
peewee.py 3826 DEBUG('INSERT INTO "users" ("username") 
VALUES (?)', ['u1'])
peewee.py 3826 DEBUG('INSERT INTO "users" ("username") 
VALUES (?)', ['u2'])
peewee.py 3826 DEBUG('INSERT INTO "users" ("username") 
VALUES (?)', ['u3'])
peewee.py 3826 DEBUG('INSERT INTO "users" ("username") 
VALUES (?)', ['u4'])
peewee.py 3826 DEBUG('INSERT INTO "users" ("username") 
VALUES (?)', ['u5'])
peewee.py 3826 DEBUG('INSERT INTO "users" ("username") 
VALUES (?)', ['u6'])
peewee.py 3826 DEBUG('INSERT INTO "users" ("username") 
VALUES (?)', ['u7'])
peewee.py 3826 DEBUG('INSERT INTO "users" ("username") 
VALUES (?)', ['u8'])
peewee.py 3826 DEBUG('INSERT INTO "users" ("username") 
VALUES (?)', ['u9'])
peewee.py 3826 DEBUG('INSERT INTO "users" ("username") 
VALUES (?)', ['u10'])
peewee.py 3826 DEBUG('SELECT "t1"."id", "t1"."username" 
FROM "users" AS t1 ORDER BY "t1"."id"', [])
peewee.py 3826 DEBUG('DROP TABLE IF EXISTS "comment"', [])
peewee.py 3826 DEBUG('DROP TABLE IF EXISTS "blog"', [])
peewee.py 3826 DEBUG('DROP TABLE IF EXISTS "users"', [])
 TestQueryResultWrapper.test_iterator_extended _

self = 

def iterator(self):
while True:
>   yield self.iterate()

peewee.py:2353: 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 

self = 

def iterate(self):
row = self.cursor.fetchone()
if not row:
self._populated = True
if not getattr(self.cursor, 'name', None):

Bug#906700: /usr/bin/opensc-notify: opensc-notify tool eating CPU core with no GUI

[Eduard Bloch]

Package: opensc
Version: 0.18.0-3
Severity: normal
File: /usr/bin/opensc-notify

Dear Maintainer,

   * What led up to the situation?

Found OpenSC notify in the menu. Not sure when the package was installed
and why.

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

No application window appeared. Instead, my fan is howling and I see that a 
task called opensc-notify is consuming all power of one CPU core.
I cannot not even kill it normally, needs kill -9.

   * What outcome did you expect instead?

Since it's a desktop entry, something should be shown to the user within a few 
seconds.

I straced a such opensc-notify call, I see nothing special here. Smells like a
stupid bug in the application code to me.

[pid 20602] socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC, 0) = 8
[pid 20602] connect(8, {sa_family=AF_UNIX, 
sun_path="/var/run/pcscd/pcscd.comm"}, 28) = 0
[pid 20602] fcntl(8, F_GETFL)   = 0x2 (flags O_RDWR)
[pid 20602] fcntl(8, F_SETFL, O_RDWR|O_NONBLOCK) = 0
[pid 20602] select(9, NULL, [8], NULL, NULL) = 1 (out [8])
[pid 20602] sendto(8, "\f\0\0\0\21\0\0\0", 8, MSG_NOSIGNAL, NULL, 0) = 8
[pid 20602] select(9, NULL, [8], NULL, NULL) = 1 (out [8])
[pid 20602] sendto(8, "\4\0\0\0\3\0\0\0\0\0\0\0", 12, MSG_NOSIGNAL, NULL, 0) = 
12
[pid 20602] select(9, [8], NULL, NULL, NULL) = 1 (in [8])
[pid 20602] read(8, "\4\0\0\0\3\0\0\0\0\0\0\0", 12) = 12
[pid 20602] select(9, NULL, [8], NULL, NULL) = 1 (out [8])
[pid 20602] sendto(8, "\f\0\0\0\1\0\0\0", 8, MSG_NOSIGNAL, NULL, 0) = 8
[pid 20602] select(9, NULL, [8], NULL, NULL) = 1 (out [8])
[pid 20602] sendto(8, "\0\0\0\0\0\0\0\0\0\0\0\0", 12, MSG_NOSIGNAL, NULL, 0) = 
12
[pid 20602] select(9, [8], NULL, NULL, NULL) = 1 (in [8])
[pid 20602] read(8, "\0\0\0\0\25P\366#\0\0\0\0", 12) = 12


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

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

Versions of packages opensc depends on:
ii  libc6  2.27-5
ii  libglib2.0-0   2.56.1-2
ii  libreadline7   7.0-5
ii  libssl1.1  1.1.0h-4
ii  opensc-pkcs11  0.18.0-3
ii  zlib1g 1:1.2.11.dfsg-1

Versions of packages opensc recommends:
ii  pcscd  1.8.23-3

opensc suggests no packages.

-- no debconf information

Bug#906308: CVE-2018-14348

[Markus Koschany]

Dear maintainer,

I've uploaded a new revision versioned as 0.48-8.1 to fix CVE-2018-14348.

Please find attached the debdiff.

Regards,

Markus
diff -Nru libcgroup-0.41/debian/changelog libcgroup-0.41/debian/changelog
--- libcgroup-0.41/debian/changelog 2016-04-24 18:51:45.0 +0200
+++ libcgroup-0.41/debian/changelog 2018-08-19 23:10:45.0 +0200
@@ -1,3 +1,12 @@
+libcgroup (0.41-8.1) unstable; urgency=high
+
+  * Non-maintainer upload.
+  * Fix CVE-2018-14348:
+It was discovered that the cgrulesengd daemon would create a log file which
+would allow any user to write to it. (Closes: #906308)
+
+ -- Markus Koschany   Sun, 19 Aug 2018 23:10:45 +0200
+
 libcgroup (0.41-8) unstable; urgency=medium
 
   * Drop package libcgroup-dbg in favor of automatic dbgsym packages.
diff -Nru libcgroup-0.41/debian/patches/CVE-2018-14348.patch 
libcgroup-0.41/debian/patches/CVE-2018-14348.patch
--- libcgroup-0.41/debian/patches/CVE-2018-14348.patch  1970-01-01 
01:00:00.0 +0100
+++ libcgroup-0.41/debian/patches/CVE-2018-14348.patch  2018-08-19 
23:10:45.0 +0200
@@ -0,0 +1,23 @@
+From: Markus Koschany 
+Date: Sun, 19 Aug 2018 23:09:25 +0200
+Subject: CVE-2018-14348
+
+Bug-Debian: https://bugs.debian.org/906308
+Origin: 
https://sourceforge.net/p/libcg/libcg/ci/0d88b73d189ea3440ccaab00418d6469f76fa590/
+---
+ src/daemon/cgrulesengd.c | 2 --
+ 1 file changed, 2 deletions(-)
+
+diff --git a/src/daemon/cgrulesengd.c b/src/daemon/cgrulesengd.c
+index 367b898..ffd1fc3 100644
+--- a/src/daemon/cgrulesengd.c
 b/src/daemon/cgrulesengd.c
+@@ -886,8 +886,6 @@ int cgre_start_daemon(const char *logp, const int logf,
+   exit(EXIT_SUCCESS);
+   }
+ 
+-  /* Change the file mode mask. */
+-  umask(0);
+   } else {
+   flog(LOG_DEBUG, "Not using daemon mode\n");
+   pid = getpid();
diff -Nru libcgroup-0.41/debian/patches/series 
libcgroup-0.41/debian/patches/series
--- libcgroup-0.41/debian/patches/series2016-04-24 18:51:45.0 
+0200
+++ libcgroup-0.41/debian/patches/series2018-08-19 23:10:45.0 
+0200
@@ -4,3 +4,4 @@
 initscript-return.patch
 Syntax-fixes-for-man-pages.patch
 pam_cgroup-Revert-broken-cache-usage.patch
+CVE-2018-14348.patch


signature.asc
Description: OpenPGP digital signature

Bug#906695: [Aptitude-devel] Bug#906695: aptitude: apt doesn't call fsync on the file extended_states

[Mikulas Patocka]

On Sun, 19 Aug 2018, Axel Beckert wrote:


Control: tag -1 + moreinfo

,Hi Mikulas

Mikulas Patocka wrote:

Package: aptitude

  

   * What led up to the situation?

apt doesn't call fsync when writing the file extended_states - so that if

 ^^^

If you strace aptitude, you can see that it writes the file

   

I had my file extended_states corrupted when the system crashed while
doing unattended upgrades.

   ^^^

apt should call fsync before closing the file handle

 ^^^

You've mentioned three different package managing tools: apt, aptitude
and unattended-upgrades.

Since you've straced aptitude, I assume you meant aptitude where you
wrote apt. But then again unattended-upgrades uses apt, not aptitude.

Please clarify!

Regards, Axel


All of the apt tools should use fsync (because the machine may crash when 
the user is using any of them).


In my case, unattended-upgrades corrupted the file extended_states when 
the machine crashed, but unattended-upgrades will not write the file if 
there are no upgrades being done, so stracing it doesn't show the bug.


Mikulas

Bug#904302: Why outlawing vendor-specific patch series would be a bad idea

[Adrian Bunk]

On Sun, Aug 19, 2018 at 10:13:56PM +0200, Philip Hands wrote:
> Adrian Bunk  writes:
> 
> ...
> >> "The source" is what you get after steps 1 and 2.
> >
> > Why is "The source" what you get after dpkg applied patches,
> > but before debian/rules applied patches?
> 
> I agree with Sean's point about it being a matter of definition relating
> to when we invoke debian/rules, but for an alternative justification one
> might look at this:
> 
> For the Debian Maintainer, what is the preferred form of modification?

The maintainer might actually know how his self-written patching 
machinery works.

I am doing plenty of bugfixing in packages I do not maintain, and the 
complex build machineries of some packages can be a real timeconsuming 
pain in some body part.

It is also frustrating when you end up spending hours trying to find a 
bug in the wrong sources.

> It could be the source before the patches are applied (especially if
> they're working on a patch to be sent upstream), but really, chances are
> that it's actually the state of the source after the Debian patches are
> applied.

So for src:gcc-8 the preferred form of modification are three tarballs 
that are not even unpacked, and none of the patches applied?

> It is almost certainly _not_ the state that source might get transformed
> into at some point during the build process.

Why not?
It gets transformed into the sources that actually get built.
These are the relevant sources when debugging some FTBFS or segfault.

> It is also almost certainly not the alternative version of the source
> that results from applying a patch series that only gets applied if they
> unpack the source on a different vendor's OS.

"different vendor's OS" is only a small part of the general problem.

How should we handle architecture-specific patches properly inside 
Debian? This is part of the same general problem that the notion
of exactly one "the sources" is misguided when it comes to what
actually gets compiled.

It is a real problem that there is no standard way to look on an amd64 
machine at the src:gcc-8 sources that will actually get built on armel.

And I cannot blame the maintainer, since there is no standard way to 
express things like e.g.:
- "apply the Linaro patches only on arm* and only in Ubuntu"
- "apply the Hurd patches that might touch generic code only on Hurd"

> Cheers, Phil.

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#906699: cython: Fails to import with python2.7-dbg

[Samuel Thibault]

Package: cython
Version: 0.28.4-1
Severity: important

Hello,

$ python2.7-dbg
>>> from Cython.Compiler.Main import CompilationOptions
ImportError: 
/usr/lib/python2.7/dist-packages/Cython/Compiler/Scanning.x86_64-linux-gnu.so: 
undefined symbol: Py_InitModule4_64

indeed, /usr/bin/python2.7-dbg defines Py_InitModule4TraceRefs_64, not
Py_InitModule4_64. This is the same kind of issue which is making pyzmq
FTBFS on hurd-i386, see 
https://buildd.debian.org/status/fetch.php?pkg=pyzmq=hurd-i386=17.1.0-1=1534712112=0

Samuel

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

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

Versions of packages cython depends on:
ii  libc6   2.27-5
ii  python  2.7.15-3

Versions of packages cython recommends:
ii  gcc 4:8.1.0-1
ii  python-dev  2.7.15-3

Versions of packages cython suggests:
pn  cython-doc  

-- no debconf information

-- 
Samuel
`When you say "I wrote a program that crashed Windows", people just stare at
you blankly and say "Hey, I got those with the system, *for free*".'
(By Linus Torvalds)

Bug#906617: autopkgtest: Please consider defining directory environment variables

[Martin Pitt]

Hello Paul,

Paul Hardy [2018-08-19  7:44 -0700]:
> It accesses
> environment variables that have to do with the installed package file
> locations.  By default, it will expect binaries to be in
> ${DESTDIR}${bindir}.  So I guess it wouldn't be necessary to define
> other things, such as $srcdir, but only directories that point to
> /usr/..., plus autopkgtest variables like AUTOPKGTEST_TMP.

But then an absent $DESTDIR should be just right, as you really want to check
things in /usr, not in some /usr/.

> By defining a few environment variables (like setting bindir to
> /usr/bin), it will be more straightforward for people running
> autopkgtest with Autotools to use a default "make installcheck"
> target.

Maybe, but I still don't believe this actually makes sense:

 * Defining random variables with generic names like $bindir might also
   influence other tests or packages, which makes them work differently than
   they would in a normal OS install.

 * autopkgtest is meant to be neutral to the test frame work that you use, as
   there are literally hundreds of them. There is no way it could maintain
   support for these.

 * This is too magic. Test commands should be very explicit and allow the
   developer to reproduce them step by step in a shell.

 * For even `make` to work, you need at least a configured tree, and thus all
   the build dependencies, and most likely even need to build the package.
   autopkgtests should generally avoid that.

 * I don't believe that setting static values for these variables even works
   for all automake projects. If they would, why are they even variables?

> If we can expect that autopkgtest uses package executables in
> /usr/bin, package data files in /usr/share/, likewise with
> other FHS directories, could you update the tutorial page to mention
> that?  Right now there is just an implication on that page from the
> sample script that the binary executable will be in a directory in
> $PATH.

Right, as Debian policy mandates that user-executable programs should be in
$PATH. So it's generally preferrable to call programs in $PATH without an
explicit path, to make sure they are actually in the correct place.

But note that there's also e. g. /sbin, or you might want to test a
Python module, or even the validity of a documentation package.

The spec [1] currently says "However note that the tests must test the
*installed* version of the program.", which is really the only condition. But
indeed this should really say "*installed* version of the package", as
autopkgtests are in no way limited to testing programs. I adjusted that in [2].

Martin

[1] 
https://salsa.debian.org/ci-team/autopkgtest/blob/master/doc/README.package-tests.rst
[2] 
https://salsa.debian.org/ci-team/autopkgtest/commit/90876a7598aee4408296857b8bf33a63e0355fc3

Bug#906696: second thoughts

[Josua Mayer]

While the db entry I provided works just fine, maybe because this is
u-boot, using a generic boot.scr would be preferred.
Any opinions?

Bug#906698: anbox-session-manager segmentation fault

[Javier Barroso]

Package: anbox
Version: 0.0~git20180709-1
Severity: important

Dear Maintainer,

I am not able to start anbox

$ systemctl status anbox-container-manager.service
● anbox-container-manager.service - Anbox Container Manager
   Loaded: loaded
(/lib/systemd/system/anbox-container-manager.service; enabled; vendor
preset: enabled)
   Active: active (running) since Sun 2018-08-19 20:34:57 CEST; 1h 47min ago
 Docs: man:anbox(1)
  Process: 965 ExecStartPre=/usr/share/anbox/anbox-bridge.sh start
(code=exited, status=0/SUCCESS)
  Process: 948 ExecStartPre=/sbin/modprobe binder_linux (code=exited,
status=0/SUCCESS)
  Process: 928 ExecStartPre=/sbin/modprobe ashmem_linux (code=exited,
status=0/SUCCESS)
 Main PID: 1080 (anbox)
Tasks: 9 (limit: 4515)
   Memory: 12.3M
   CGroup: /system.slice/anbox-container-manager.service
   └─1080 /usr/bin/anbox container-manager --daemon
--privileged --data-path=/var/lib/anbox

$ systemctl --user status anbox-session-manager.service
● anbox-session-manager.service - Anbox Session Manager
   Loaded: loaded
(/usr/lib/systemd/user/anbox-session-manager.service; disabled; vendor
preset: enabled)
   Active: failed (Result: signal) since Sun 2018-08-19 22:25:41 CEST; 827ms ago
 Docs: man:anbox(1)
  Process: 7289 ExecStart=/usr/bin/anbox session-manager (code=killed,
signal=SEGV)
 Main PID: 7289 (code=killed, signal=SEGV)


$ LANG=C anbox session-manager
Stack trace (most recent call last) in thread 6908:
#10   Object "[0x]", at 0x, in
#9Object "/lib/x86_64-linux-gnu/libc.so.6", at 0x7fe1d86aeede, in clone
#8Object "/lib/x86_64-linux-gnu/libpthread.so.0", at 0x7fe1d96d4f29, in
#7Object "anbox", at 0x55fdc495daf4, in emugl::Thread::thread_main(void*)
#6Object "anbox", at 0x55fdc488557a, in RenderThread::main()
#5Object "anbox", at 0x55fdc497c81f, in
gles2_decoder_context_t::decode(void*, unsigned long, IOStream*)
#4Object "/usr/lib/x86_64-linux-gnu/dri/i965_dri.so", at 0x7fe1ccca39d2, in
#3Object "/usr/lib/x86_64-linux-gnu/dri/i965_dri.so", at 0x7fe1ccca3261, in
#2Object "/usr/lib/x86_64-linux-gnu/dri/i965_dri.so", at 0x7fe1ccf0e880, in
#1Object "/usr/lib/x86_64-linux-gnu/dri/i965_dri.so", at 0x7fe1ccf1c7b7, in
#0Object "/usr/lib/x86_64-linux-gnu/dri/i965_dri.so", at 0x7fe1ccf24349, in
Segmentation fault (Address not mapped to object [0x7c])

What can I do ? Can I provide the info that you need to debug this issue

Thank you very much

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

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

Versions of packages anbox depends on:
ii  iptables1.6.2-1.1
ii  libboost-atomic1.62.0   1.62.0+dfsg-8
ii  libboost-chrono1.62.0   1.62.0+dfsg-8
ii  libboost-date-time1.62.01.62.0+dfsg-8
ii  libboost-filesystem1.62.0   1.62.0+dfsg-8
ii  libboost-iostreams1.62.01.62.0+dfsg-8
ii  libboost-log1.62.0  1.62.0+dfsg-8
ii  libboost-program-options1.62.0  1.62.0+dfsg-8
ii  libboost-regex1.62.01.62.0+dfsg-8
ii  libboost-serialization1.62.01.62.0+dfsg-8
ii  libboost-system1.62.0   1.62.0+dfsg-8
ii  libboost-thread1.62.0   1.62.0+dfsg-8
ii  libc6   2.27-5
ii  libegl1 1.1.0-1
ii  libgcc1 1:8.2.0-4
ii  libgles21.1.0-1
ii  liblxc1 1:2.0.9-6
ii  libprotobuf-lite10  3.0.0-9.1
ii  libsdl2-2.0-0   2.0.8+dfsg1-1
ii  libsdl2-image-2.0-0 2.0.3+dfsg1-1
ii  libstdc++6  8.2.0-4
ii  libsystemd0 239-7
ii  lxc 1:2.0.9-6

Versions of packages anbox recommends:
ii  dbus-user-session  1.12.10-1

anbox suggests no packages.

-- debconf-show failed

Bug#870286: btrfs-progs: btrfs-convert is missing

[Ryan Kavanagh]

On Mon, Jul 31, 2017 at 05:50:44PM +0200, Adam Borowski wrote:
> > btrfs-progs (4.12-1) unstable; urgency=medium
> >   [ Nicholas D Steeves ]
> >   * Drop btrfs-convert (Closes: #824895, #854489)
>
> Yes, there are some caveats, but the man page discusses them at length.

If you decide to continue to exclude btrfs-convert from btrfs-progs,
please also drop the manpage:

rak@zeta:~$ dpkg -S btrfs-convert
btrfs-progs: /usr/share/man/man8/btrfs-convert.8.gz

It took me a bit of searching to figure out why there was a manpage but
no associated binary.

Best wishes,
Ryan

-- 
|)|/  Ryan Kavanagh  | GPG: 4E46 9519 ED67 7734 268F
|\|\  https://rak.ac |  BD95 8F7B F8FC 4A11 C97A


signature.asc
Description: PGP signature

Bug#906697: ck: baseline violation on i386

[Adrian Bunk]

Source: ck
Version: 0.6.0-1.1
Severity: serious

ck builds with "-msse -msse2" but SSE is not part
of the i386 baseline.

Bug#904302: Why outlawing vendor-specific patch series would be a bad idea

[Philip Hands]

Adrian Bunk  writes:

...
>> "The source" is what you get after steps 1 and 2.
>
> Why is "The source" what you get after dpkg applied patches,
> but before debian/rules applied patches?

I agree with Sean's point about it being a matter of definition relating
to when we invoke debian/rules, but for an alternative justification one
might look at this:

For the Debian Maintainer, what is the preferred form of modification?

It could be the source before the patches are applied (especially if
they're working on a patch to be sent upstream), but really, chances are
that it's actually the state of the source after the Debian patches are
applied.

It is almost certainly _not_ the state that source might get transformed
into at some point during the build process.

It is also almost certainly not the alternative version of the source
that results from applying a patch series that only gets applied if they
unpack the source on a different vendor's OS.

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Bug#901044: libjnr-posix-java-doc_3.0.45-1_all.deb errors encountered while processing

[Robert Elder]

send-detail 901044

Bug#904302: Why outlawing vendor-specific patch series would be a bad idea

[Adrian Bunk]

On Sun, Aug 19, 2018 at 12:11:01PM -0700, Sean Whitton wrote:
>...
> On Sun 19 Aug 2018 at 09:51PM +0300, Adrian Bunk wrote:
>...
> > For a user it doesn't make a difference which tool applies the patches.
> 
> In my mind, it does; it matters whether or not it is part of the package
> build.  That's just my expectation of what reasonable users will think.
> 
> We're discussing what users will reasonably expect.  If you and I have
> different intuitions about the expectations that reasonable users will
> form, we're going to have to agree to disagree.
>...

The user sees that the sources get unpacked, and that patches get applied.

You are saying that the reasonable user will expect that these patched 
sources might not be the sources that will get built, and that a
reasonable user will expect that additional patches might get applied
during the build.

Yes, we have to agree to disagree on that.

> > Note that you were also arguing based on a different source
> > definition:
> >
> > On Mon, Jul 23, 2018 at 09:22:17AM +0800, Sean Whitton wrote:
> >> For example, someone might want to use a Debian system to investigate a
> >> bug on an Ubuntu system.  They might begin by downloading some source
> >> packages from the Ubuntu mirrors.  Since they obtained them from Ubuntu,
> >> they will form the reasonable expectation that unpacking these source
> >> packages will get them the code running on the Ubuntu system they are
> >> debugging.
> >
> > This would be useful for debugging problems.
> >
> > But it is important to understand that in the general case there will
> > always be cases where the code running on your system will depend on
> > the architecture of your system - after applying patches the sources
> > might be architecture-specific.
> 
> Unless I'm missing something, that can only be true when the application
> of patches to which you refer occurs during the package build.

dpkg-source -x --vendor=Ubuntu --arch=arm64 hello_2.10-1.dsc

--vendor should be implementable today based on vendor-specific patch series.
--arch would require similar support for arch-specific patch series.

I am not saying that a complete solution would be easy to implement,
or that this might happen anytime soon.

But the long-term goal should be to abolish patching during the package 
build, by bringing more conditional patching functionality to dpkg.

This will allow packages to move away from their own custom patching 
systems.

And it will give the user the sources that will actually get built.

> Sean Whitton

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#906677: apt remove php7.0-fpm wants to install apache2 but doesn't tell why

[Olaf van der Spek]

2018-08-19 21:57 GMT+02:00 David Kalnischkies :
> On Sun, Aug 19, 2018 at 09:19:57PM +0200, Olaf van der Spek wrote:
>> So after X attempts the culprit is found: adminer
>> Wouldn't been so much easier if apt told me right away.
>
> Just for the record: -o pkgProblemResolver::FixByInstall=0
> can help in these situations.

That's a lot faster, thanks!

> The "problem" here is that apt can avoid
> removing a bunch of packages if only it installs a few new ones and as
> new things tend to be less dangerous for not breaking usecases then
> removing things it does so.

I understand.
In this case the dependencies of adminer might not be right too:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=906692

Thing is, I think installing (for example) / choosing a webserver
should be an explicit action by the user and certainly not a
consequence of trying to remove something.

I understand this is a hard problem though.


-- 
Olaf

Bug#906677: apt remove php7.0-fpm wants to install apache2 but doesn't tell why

[David Kalnischkies]

On Sun, Aug 19, 2018 at 09:19:57PM +0200, Olaf van der Spek wrote:
> So after X attempts the culprit is found: adminer
> Wouldn't been so much easier if apt told me right away.

Just for the record: -o pkgProblemResolver::FixByInstall=0
can help in these situations. The "problem" here is that apt can avoid
removing a bunch of packages if only it installs a few new ones and as
new things tend to be less dangerous for not breaking usecases then
removing things it does so.

Every once in a while I wonder if we should make that the default for
'remove foo' actions, but then its less clear what 'install foo-' should
do as behind the scenes remove/install are the same code, they just flip
the default interpretation of package names without an explicit action
specified (= what Julian hinted at with '-' and '+' after a package
name) and these kinds of hidden differences can end in a nightmare.

The lesson is as it is so often the case: choose either as default but
regardless the choice someone will be unhappy.


Best regards

David Kalnischkies, who remembers writing that code initially to fix
a bunch of upgrade problems for a Debian release a couple years ago


signature.asc
Description: PGP signature

Bug#901562: invesalius is marked for autoremoval from testing

[Thiago Franco Moraes]

Hi Andreas,

Thanks, I can push to repository now. I've pushed both the master and
upstream/3.1.1

Best regards

On Sat, Aug 18, 2018 at 2:32 AM Andreas Tille  wrote:
>
> Hi Thiago,
>
> On Fri, Aug 17, 2018 at 09:12:46PM -0300, Thiago Franco Moraes wrote:
> > I' ve created a merge request in the Debian Salsa with a new version
> > tag (3.1.9991) of InVesalius. This new version fixes the bug #901562.
>
> I've added you to the Debian Med team now.  Please check whether you
> can push directly to the repository.
> > This package is not using Python3 because there is not a
> > pyhton3-vtkgdcm package in Debian Testing. But InVesalius is already
> > running with Python3.
>
> I've just opened a bug against gdcm to ask for Python3 support.  As
> I understood Gerd in #895900 this is planed and was just delayed due
> to Invesalius.  So I think we can expect pyhton3-vtkgdcm soon.
>
> Thanks for your work on this
>
>   Andreas.
>
> --
> http://fam-tille.de

Bug#906695: [Aptitude-devel] Bug#906695: aptitude: apt doesn't call fsync on the file extended_states

[Axel Beckert]

Control: tag -1 + moreinfo

,Hi Mikulas

Mikulas Patocka wrote:
> Package: aptitude
   
>* What led up to the situation?
> 
> apt doesn't call fsync when writing the file extended_states - so that if
  ^^^
> If you strace aptitude, you can see that it writes the file

> I had my file extended_states corrupted when the system crashed while
> doing unattended upgrades.
^^^
> apt should call fsync before closing the file handle
  ^^^

You've mentioned three different package managing tools: apt, aptitude
and unattended-upgrades.

Since you've straced aptitude, I assume you meant aptitude where you
wrote apt. But then again unattended-upgrades uses apt, not aptitude.

Please clarify!

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

Bug#906696: flash-kernel: Please add an entry for the Rock64

[Josua Mayer]

Package: flash-kernel
Version: 3.94
Severity: wishlist
Tags: patch

Dear Maintainer,

The rock64 from pine64 works acceptable with linux-image-arm64.
There is a vendor u-boot available based on 2017.09. It fully supports distro 
boot and 
loading EFI applications.
Therefore the rock64 can be booted with grub-arm-efi.

Only one important thing has to be dealt with: Getting the DTB loaded by U-Boot!
U-Boot searches for rockchip/rk3328-rock64.dtb in /, /dtb/, /dtb/current on the 
EFI partition.

The attached db entry takes care ot this particular path by storing it at 
/boot/efi/dtb/rockchip/rk3328-rock64.dtb.

Other rockchip boards supported by mainline u-boot omit the rockchip 
subdirectory and just search for the dtb name.
However there is no support for the rock64 in mainline u-boot so I think 
carrying this weird prefix is acceptable.

Currently most used and best documented source for rock64 U-Boot:
https://github.com/ayufan-rock64/linux-u-boot/releases

u-boot-erase-spi-rock64.img.xz can be used to flash u-boot to SPI flash once;
from then on everything is standard:
- debootstrap
- linux-image-arm64
- grub-arm-efi
- grub-install --target=arm-efi --removable

Yours sincerely
Josua Mayer

-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: arm64 (aarch64)

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

Versions of packages flash-kernel depends on:
ii  debconf [debconf-2.0]  1.5.69
ii  devio  1.2-1.2+b1
ii  initramfs-tools0.132
ii  linux-base 4.5
ii  mtd-utils  1:2.0.1-1
ii  ucf3.0038

Versions of packages flash-kernel recommends:
ii  u-boot-tools  2018.05+dfsg-1

flash-kernel suggests no packages.

-- Configuration Files:
/etc/flash-kernel/db changed:
Machine: Pine64 Rock64
Boot-DTB-Path: /boot/efi/rockchip/rk3328-rock64.dtb
DTB-Id: rockchip/rk3328-rock64.dtb


-- debconf information excluded
>From 94fb0ab7075b3f2424b8aef673d430896191f3ac Mon Sep 17 00:00:00 2001
From: Josua Mayer 
Date: Sun, 19 Aug 2018 21:55:17 +0200
Subject: [PATCH] Add Rock64

Signed-off-by: Josua Mayer 
---
 db/all.db | 4 
 1 file changed, 4 insertions(+)

diff --git a/db/all.db b/db/all.db
index 7031d21..8d946c6 100644
--- a/db/all.db
+++ b/db/all.db
@@ -1402,6 +1402,10 @@ Boot-Script-Path: /boot/boot.scr
 U-Boot-Script-Name: bootscr.uboot-generic
 Required-Packages: u-boot-tools
 
+Machine: Pine64 Rock64
+Boot-DTB-Path: /boot/efi/rockchip/rk3328-rock64.dtb
+DTB-Id: rockchip/rk3328-rock64.dtb
+
 Machine: PlatHome OpenBlocks AX3-4 board
 Kernel-Flavors: armmp armmp-lpae
 DTB-Id: armada-xp-openblocks-ax3-4.dtb
-- 
2.18.0

Bug#906451: tar-pack seems an unmaintained module

[Sebastiaan Couwenberg]

On 08/19/2018 08:27 PM, Pirate Praveen wrote:
> On Sun, 19 Aug 2018 21:54:11 +0530 Pirate Praveen wrote:
>> The only package that depends on node-tar-pack is node-pre-gyp, which
>> has a newer upstream release that no longer depends on tar-pack.
> 
> I have uploaded a new upstream version of node-pre-gyp (0.6.32-1 ->
> 0.10.2-1)  to experimental. node-mapnik, node-sqlite3 and node-zipfile
> are its reverse dependencies.
> 
> Lazslo, Sebastian, Jeremy, can you confirm if this version is compatible
> with your package?

I don't know, you should do a round of rebuilds to find out.

> I'd like to upload this to unstable soon. Since it is
> still in 0.x I assume it can have breaking changes, so just giving a
> heads up to be extra careful here.

Kind Regards,

Bas



signature.asc
Description: OpenPGP digital signature

Bug#906695: aptitude: apt doesn't call fsync on the file extended_states

[Mikulas Patocka]

Package: aptitude
Version: 0.8.7-1
Severity: normal

Dear Maintainer,

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

   * What led up to the situation?

apt doesn't call fsync when writing the file extended_states - so that if
the system crashes while doing updates, the file extended_states is
corrupted

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

If you strace aptitude, you can see that it writes the file
extended_states this way. There's no fsync, and therefore there's no
guarantee that the file will be written when renaming it to the permanent
state.

15267 open("/var/lib/apt/extended_states.plCi2E", O_RDWR|O_CREAT|O_EXCL, 0600) 
= 74
15267 umask(000)= 022
15267 umask(022)= 000
15267 fchmod(74, 0644)  = 0
15267 fcntl(74, F_SETFD, FD_CLOEXEC)= 0
15267 write(74, "Package: libmpc2\n", 17) = 17
15267 write(74, "Architecture: amd64\n", 20) = 20
15267 write(74, "Auto-Installed: 1\n", 18) = 18
15267 write(74, "\n", 1)= 1
15267 write(74, "Package: automake1.9\n", 21) = 21
15267 write(74, "Architecture: amd64\n", 20) = 20
15267 write(74, "Auto-Installed: 1\n", 18) = 18
15267 write(74, "\n", 1)= 1
15267 write(74, "Package: automake1.10\n", 22) = 22
15267 write(74, "Architecture: amd64\n", 20) = 20
15267 write(74, "Auto-Installed: 1\n", 18) = 18
15267 write(74, "\n", 1)= 1

15267 close(74) = 0
15267 rename("/var/lib/apt/extended_states.plCi2E", 
"/var/lib/apt/extended_states") = 0
15267 chmod("/var/lib/apt/extended_states", 0644) = 0

   * What was the outcome of this action?

I had my file extended_states corrupted when the system crashed while
doing unattended upgrades.

   * What outcome did you expect instead?

apt should call fsync before closing the file handle


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


-- Package-specific info:
Terminal: linux
$DISPLAY not set.
which aptitude: /usr/bin/aptitude

aptitude version information:
aptitude 0.8.7
Compiler: g++ 6.3.0 20170406
Compiled against:
  apt version 5.0.1
  NCurses version 6.0
  libsigc++ version: 2.10.0
  Gtk+ support disabled.
  Qt support disabled.

Current library versions:
  NCurses version: ncurses 6.0.20161126
  cwidget version: 0.5.17
  Apt version: 5.0.1

aptitude linkage:
linux-vdso.so.1 (0x7fff917fc000)
libapt-pkg.so.5.0 => /usr/lib/x86_64-linux-gnu/libapt-pkg.so.5.0 
(0x7f4d8f1f1000)
libncursesw.so.5 => /lib/x86_64-linux-gnu/libncursesw.so.5 
(0x7f4d8efc1000)
libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5 
(0x7f4d8ed97000)
libsigc-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libsigc-2.0.so.0 
(0x7f4d8eb9)
libcwidget.so.3 => /usr/lib/x86_64-linux-gnu/libcwidget.so.3 
(0x7f4d8e893000)
libsqlite3.so.0 => /usr/lib/x86_64-linux-gnu/libsqlite3.so.0 
(0x7f4d8e58b000)
libboost_iostreams.so.1.62.0 => 
/usr/lib/x86_64-linux-gnu/libboost_iostreams.so.1.62.0 (0x7f4d8e373000)
libboost_filesystem.so.1.62.0 => 
/usr/lib/x86_64-linux-gnu/libboost_filesystem.so.1.62.0 (0x7f4d8e15a000)
libboost_system.so.1.62.0 => 
/usr/lib/x86_64-linux-gnu/libboost_system.so.1.62.0 (0x7f4d8df56000)
libxapian.so.30 => /usr/lib/x86_64-linux-gnu/libxapian.so.30 
(0x7f4d8db42000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 
(0x7f4d8d925000)
libstdc++.so.6 => /usr/local/gcc/lib64/libstdc++.so.6 
(0x7f4d8d585000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7f4d8d281000)
libgcc_s.so.1 => /usr/local/gcc/lib64/libgcc_s.so.1 (0x7f4d8d068000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f4d8ccc9000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7f4d8cac5000)
libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 
(0x7f4d8c8ae000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x7f4d8c694000)
libbz2.so.1.0 => /lib/x86_64-linux-gnu/libbz2.so.1.0 
(0x7f4d8c484000)
liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x7f4d8c25e000)
liblz4.so.1 => /usr/lib/x86_64-linux-gnu/liblz4.so.1 
(0x7f4d8c04c000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x7f4d8be44000)
libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x7f4d8bc3f000)
/lib64/ld-linux-x86-64.so.2 (0x7f4d8fbba000)

-- System Information:
Debian Release: 9.5
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, arm64, armel, armhf, mips, mips64el, ppc64el, s390x

Kernel: Linux 4.4.128 (SMP w/12 CPU cores; PREEMPT)
Locale: LANG=cs_CZ, LC_CTYPE=cs_CZ (charmap=ISO-8859-2), LANGUAGE=cs_CZ 
(charmap=ISO-8859-2)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages aptitude depends on:
ii  

Bug#905433: git-debrebase: debrebase new-upstream fails with "uninitialized value"

[Ian Jackson]

Sean Whitton writes ("Bug#905433: git-debrebase: debrebase new-upstream fails 
with "uninitialized value""):
> 'unpatched' could be very confusing.  To me, it means that there is no
> Debian delta at all.  Let's avoid that.
> 
> We previously considered 'convert-from-unapplied'.  But that has the
> parallel problem, noted in #905573, that the command works for a tree
> with no Debian delta, which is trivially both patches-applied and
> patches-unapplied.
> 
> So I'd like to suggest 'convert-from-unpatched-upstream-source'.  That
> covers both the case where there is no Debian delta, and the case of a
> patches-unapplied view where there is a delta.
> 
> It is long, but IIRC all these subcommands have deliberately long names
> since they are expected to be run very rarely.

I think
  convert-from-unpatched-upstream-source
  convert-from-unpatched-upstream
have the same problem as
  convert-from-unpatched
TBH.

Maybe the answer is to provide aliases.
  convert-from-gbp
  convert-from-unpatched
?

Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Bug#885405: RFP: waterfox -- graphical web browser based on Firefox

[Vincent Lefevre]

Any news?

This would be really useful now that Firefox 52 is no longer in
unstable and that Mozilla delayed the support for session management
to 2019.

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

Bug#904776: /usr/bin/dpkg-source: please parse d/t/control.autodep8 like d/t/control

[Paul Gevers]

Hi Guillem,

This bug is still marked as moreinfo, are you still waiting for more
input from me?

Paul



signature.asc
Description: OpenPGP digital signature

Bug#906694: purpose: autopkgtest regression

[Paul Gevers]

Source: purpose
Version: 5.49.0-1
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: regression

Dear maintainers,

With the upload of 5.49.0-1 the autpkgtest of your package started to
fail in unstable and testing. I copied the output below.

Currently this regression is contributing to the delay of the migration
to testing [1]. Could you please investigate the situation and fix it?
If needed, please change the bug's severity as appropriate.

Two days ago there has been quite some uploads in the KDE stack which
triggered a lot of regressions, which seem to be resolved once all
packages were build. This regression however seems to remain, I am
totally sure if it is not merely waiting for some other package, but I
don't think so.

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

Paul

[1] https://qa.debian.org/excuses.php?package=purpose

https://ci.debian.net/data/autopkgtest/testing/amd64/p/purpose/845553/log.gz

autopkgtest [06:34:59]: test testsuite: [---
Openbox-Message: Unable to find a valid menu file
"/var/lib/openbox/debian-menu.xml"
libKF5Parts.so.5 was not found.
libKF5Plasma.so.5 was not found.
kdeinit5: preparing to launch
'/usr/lib/x86_64-linux-gnu/libexec/kf5/klauncher'
kdeinit5: Launched KLauncher, pid = 20492, result = 0
Connecting to deprecated signal
QDBusConnectionInterface::serviceOwnerChanged(QString,QString,QString)
kdeinit5: opened connection to :99
cd obj-x86_64-linux-gnu && make -j2 test ARGS\+=-j2
Running tests...
/usr/bin/ctest --force-new-ctest-process -j2
Test project
/tmp/autopkgtest-lxc.ob13vu9y/downtmp/build.g9E/src/obj-x86_64-linux-gnu
Start 1: alternativesmodeltest
Start 2: menutest
kdeinit5: Got EXEC_NEW
'/usr/lib/x86_64-linux-gnu/qt5/plugins/kf5/kio/file.so' from launcher.
kdeinit5: preparing to launch
'/usr/lib/x86_64-linux-gnu/qt5/plugins/kf5/kio/file.so'
kdeinit5: Got EXEC_NEW
'/usr/lib/x86_64-linux-gnu/qt5/plugins/kf5/kio/http.so' from launcher.
kdeinit5: preparing to launch
'/usr/lib/x86_64-linux-gnu/qt5/plugins/kf5/kio/http.so'
kdeinit5: Got EXEC_NEW
'/usr/lib/x86_64-linux-gnu/qt5/plugins/kf5/kio/file.so' from launcher.
kdeinit5: preparing to launch
'/usr/lib/x86_64-linux-gnu/qt5/plugins/kf5/kio/file.so'
kdeinit5: Got EXEC_NEW
'/usr/lib/x86_64-linux-gnu/qt5/plugins/kf5/kio/http.so' from launcher.
kdeinit5: preparing to launch
'/usr/lib/x86_64-linux-gnu/qt5/plugins/kf5/kio/http.so'
kf5.kio.kio_http: Can't communicate with kded_kcookiejar!
kf5.kio.kio_http: Can't communicate with kded_kcookiejar!
kdeinit5: Got EXEC_NEW
'/usr/lib/x86_64-linux-gnu/qt5/plugins/kf5/kio/http.so' from launcher.
kdeinit5: preparing to launch
'/usr/lib/x86_64-linux-gnu/qt5/plugins/kf5/kio/http.so'
kdeinit5: Got EXEC_NEW
'/usr/lib/x86_64-linux-gnu/qt5/plugins/kf5/kio/http.so' from launcher.
kdeinit5: preparing to launch
'/usr/lib/x86_64-linux-gnu/qt5/plugins/kf5/kio/http.so'
kf5.kio.kio_http: Can't communicate with kded_kcookiejar!
kf5.kio.kio_http: Can't communicate with kded_kcookiejar!
kf5.kio.kio_file:  Couldn't rename  "/tmp/purposetest.part"  to
"/tmp/purposetest"
kdeinit5: PID 20520 terminated.
kdeinit5: PID 20531 terminated.
kdeinit5: PID 20521 terminated.
1/2 Test #2: menutest .***Failed2.50 sec
* Start testing of MenuTest *
Config: Using QtTest library 5.11.1, Qt 5.11.1
(x86_64-little_endian-lp64 shared (dynamic) release build; by GCC 8.1.0)
PASS   : MenuTest::initTestCase()
QWARN  : MenuTest::runJobTest()
qrc:/org/kde/purpose/RunningJob.qml:46:16: Unable to assign ulong to double
QWARN  : MenuTest::runJobTest() kf5.kservice.services: KMimeTypeTrader:
couldn't find service type "KParts/ReadOnlyPart"
Please ensure that the .desktop file for it is installed; then run
kbuildsycoca5.
QDEBUG : MenuTest::runJobTest() job failed with error " /tmp/purposetest"
FAIL!  : MenuTest::runJobTest() Compared values are not the same
   Actual   (error): 157
   Expected (0): 0
   Loc:
[/tmp/autopkgtest-lxc.ob13vu9y/downtmp/build.g9E/src/autotests/menutest.cpp(74)]
PASS   : MenuTest::cleanupTestCase()
Totals: 2 passed, 1 failed, 0 skipped, 0 blacklisted, 2414ms
* Finished testing of MenuTest *

kdeinit5: PID 20515 terminated.
kdeinit5: PID 20513 terminated.
2/2 Test #1: alternativesmodeltest    Passed3.07 sec

50% tests passed, 1 tests failed out of 2

Total Test time (real) =   3.08 sec

The following tests FAILED:
  2 - menutest (Failed)
Errors while running CTest
make: *** [Makefile:133: test] Error 8
dh_auto_test: cd obj-x86_64-linux-gnu && make -j2 test ARGS\+=-j2
returned exit code 2
kdeinit5: PID 20530 terminated.
kdeinit5: terminate KDE.
klauncher: Exiting on signal 1
autopkgtest [06:35:04]: test testsuite: ---]



signature.asc
Description: OpenPGP digital signature

Bug#901461: your mail

[Nick Morrott]

On 17 August 2018 at 20:36, Petter Reinholdtsen  wrote:
> Hi.  Any news on packaing mu in Debian?  Who is working on it and know the
> status?  Care to write up an update?

Dear all,

With python3-pyqt5.qtchart being accepted into unstable last week I am
currently rechecking my packaging of mu (package/binary renamed
mu-editor).

I should have an upload to mentors ready for review in the next day or two.

Thanks,
Nick

Bug#906677: apt remove php7.0-fpm wants to install apache2 but doesn't tell why

[Olaf van der Spek]

2018-08-19 21:09 GMT+02:00 Julian Andres Klode :
> Well add more of the stuff you don't want. Come on.

Already did that. ;)

# apt remove php7.0-fpm libapache2-mod-php7.0- php7.0-cgi-
libapache2-mod-php- php7.2-cgi-
Reading package lists... Done
Building dependency tree
Reading state information... Done
Package 'libapache2-mod-php' is not installed, so not removed
Package 'libapache2-mod-php7.0' is not installed, so not removed
Package 'php7.0-cgi' is not installed, so not removed
Package 'php7.2-cgi' is not installed, so not removed
The following packages were automatically installed and are no longer required:
  libpq5 php-pgsql php-sqlite3 php7.2-pgsql php7.2-sqlite3
Use 'apt autoremove' to remove them.
The following packages will be REMOVED:
  adminer php7.0 php7.0-fpm
0 upgraded, 0 newly installed, 3 to remove and 0 not upgraded.
After this operation, 6,619 kB disk space will be freed.
Do you want to continue? [Y/n] n
Abort.

So after X attempts the culprit is found: adminer
Wouldn't been so much easier if apt told me right away.

>> Know what?
>
> That you don't want apache2.

If I want to remove a pkg I do NOT expect pkgs to be installed. I
might expect apt to indicate that some more pkgs might need to be
removed.

>> >> I think apt should tell where the dependency on apache2 comes from.
>> >
>> > Nah, that would be too verbose.
>>
>> Why's that?
>
> If you install a lot of packages, showing which package(s) cause the package 
> to
> be installed is very verbose. I mean, set Debug::pkgDepCache::Marker to 1 and
> see for yourself.

Note that we're not talking about the user wanting to install packages
in this case.. the initial request is to remove a pkg.


>>
>> > You could use debugging logs to figure that out, or just
>> > tell apt not to install apache2.

I find that to be a less than ideal UI / UX.

Gr,

Olaf

Bug#904302: Why outlawing vendor-specific patch series would be a bad idea

[Sean Whitton]

Hello Adrian,

On Sun 19 Aug 2018 at 09:51PM +0300, Adrian Bunk wrote:

> Why is "The source" what you get after dpkg applied patches,
> but before debian/rules applied patches?

Because we define the package build as something that starts when you
invoke the debian/rules script.

> For a user it doesn't make a difference which tool applies the patches.

In my mind, it does; it matters whether or not it is part of the package
build.  That's just my expectation of what reasonable users will think.

We're discussing what users will reasonably expect.  If you and I have
different intuitions about the expectations that reasonable users will
form, we're going to have to agree to disagree.  Neither of us is in a
position to conduct field research on this question (afaik!).

> Note that you were also arguing based on a different source
> definition:
>
> On Mon, Jul 23, 2018 at 09:22:17AM +0800, Sean Whitton wrote:
>> For example, someone might want to use a Debian system to investigate a
>> bug on an Ubuntu system.  They might begin by downloading some source
>> packages from the Ubuntu mirrors.  Since they obtained them from Ubuntu,
>> they will form the reasonable expectation that unpacking these source
>> packages will get them the code running on the Ubuntu system they are
>> debugging.
>
> This would be useful for debugging problems.
>
> But it is important to understand that in the general case there will
> always be cases where the code running on your system will depend on
> the architecture of your system - after applying patches the sources
> might be architecture-specific.

Unless I'm missing something, that can only be true when the application
of patches to which you refer occurs during the package build.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#906677: apt remove php7.0-fpm wants to install apache2 but doesn't tell why

[Julian Andres Klode]

On Sun, Aug 19, 2018 at 08:49:17PM +0200, Olaf van der Spek wrote:
> 2018-08-19 20:01 GMT+02:00 Julian Andres Klode :
> > Well then, tell apt (apt remove php7.0-fpm apache2
> 
> Like this?
> 
> # apt remove php7.0-fpm apache2
> 
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> Package 'apache2' is not installed, so not removed
> The following additional packages will be installed:
>   apache2-bin libapache2-mod-php7.0 libaprutil1-dbd-sqlite3
> libaprutil1-ldap libbrotli1 liblua5.2-0
> Suggested packages:
>   apache2-doc apache2-suexec-pristine | apache2-suexec-custom www-browser
> Recommended packages:
>   apache2
> The following packages will be REMOVED:
>   php7.0-fpm
> The following NEW packages will be installed:
>   apache2-bin libapache2-mod-php7.0 libaprutil1-dbd-sqlite3
> libaprutil1-ldap libbrotli1 liblua5.2-0
> 0 upgraded, 6 newly installed, 1 to remove and 0 not upgraded.
> Need to get 3,003 kB of archives.
> After this operation, 6,132 kB of additional disk space will be used.
> Do you want to continue? [Y/n]

Well add more of the stuff you don't want. Come on.

> 
> > apt install foo apache2-).
> 
> What's foo in this case?

A package you want to install that should not pull in apache2.


> 
> > APT can't
> > possibly know that.
> 
> Know what?

That you don't want apache2.

> 
> >> I think apt should tell where the dependency on apache2 comes from.
> >
> > Nah, that would be too verbose.
> 
> Why's that?

If you install a lot of packages, showing which package(s) cause the package to
be installed is very verbose. I mean, set Debug::pkgDepCache::Marker to 1 and
see for yourself.

> 
> > You could use debugging logs to figure that out, or just
> > tell apt not to install apache2.
> >
> >> I fell like the apt output could be cleaner as well, lots of packages are 
> >> mentioned twice and suggested pkgs really doesn't help here.
> >
> > They're mentioned as often as needed.
> 
> How does that help the user?

They know which packages are newly installed (NEW),
and which packages are installed to satisfy dependencies
(additional packages).


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

Bug#905433: git-debrebase: debrebase new-upstream fails with "uninitialized value"

[Sean Whitton]

Hello,

On Sun 19 Aug 2018 at 07:31PM +0100, Ian Jackson wrote:

> Control: retitle -1 consider renaming convert-from-gbp
>
> Ian Jackson writes ("Re: Bug#905433: git-debrebase: debrebase new-upstream 
> fails with "uninitialized value""):
>> I think you've probably figured this out now, but in your situation
>> git-debrebse convert-from-gbp will do what you need.
>>
>> I'm increasingly of the opinion that that subcommand needs to be
>> renamed, in addition to improving the docs.
>
> I am currently inclined to rename this to
>convert-from-unpatched
> or something, but I would like to hear Sean's opinion.

'unpatched' could be very confusing.  To me, it means that there is no
Debian delta at all.  Let's avoid that.

We previously considered 'convert-from-unapplied'.  But that has the
parallel problem, noted in #905573, that the command works for a tree
with no Debian delta, which is trivially both patches-applied and
patches-unapplied.

So I'd like to suggest 'convert-from-unpatched-upstream-source'.  That
covers both the case where there is no Debian delta, and the case of a
patches-unapplied view where there is a delta.

It is long, but IIRC all these subcommands have deliberately long names
since they are expected to be run very rarely.

(The trailing '-source' could be dropped but I would be inclined not
to.)

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#906693: akonadi-server: Akonadi waits to short for password

[Valentin Petzel]

Package: akonadi-server
Version: 4:17.12.3-3
Severity: normal

Dear Maintainer,

When establishing a connection to an account, where the password is
stored in KWallet, Akonadi prompts the password apparently if it doesn't
respond for some time. This is set so short that on login one is often
prompted for the e-Mail accounts' passwords before one has the chance to
enter the password for KWallet's encryption. You might want to consider
increasing the time Akonadi waits for the passwords.

-- System Information:
Debian Release: buster/sid
  APT prefers oldstable-updates
  APT policy: (500, 'oldstable-updates'), (500, 'oldstable-proposed-updates'), 
(500, 'unstable'), (500, 'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.11-towo.2-siduction-amd64 (SMP w/4 CPU cores; PREEMPT)
Locale: LANG=de_AT.UTF-8, LC_CTYPE=de_AT.UTF-8 (charmap=UTF-8), LANGUAGE=de 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages akonadi-server depends on:
ii  akonadi-backend-mysql  4:17.12.3-3
ii  akonadi-backend-sqlite 4:17.12.3-3
ii  libc6  2.27-5
ii  libgcc11:8.2.0-2
ii  libkf5akonadiprivate5abi1  4:17.12.3-3
ii  libkf5akonadiwidgets5abi1  4:17.12.3-3
ii  libkf5configcore5  5.47.0-1
ii  libkf5coreaddons5  5.47.0-1
ii  libkf5crash5   5.47.0-1
ii  libkf5i18n55.47.0-1
ii  libqt5core5a   5.11.1+dfsg-6
ii  libqt5dbus55.11.1+dfsg-6
ii  libqt5gui5 5.11.1+dfsg-6
ii  libqt5network5 5.11.1+dfsg-6
ii  libqt5sql5 5.11.1+dfsg-6
ii  libqt5widgets5 5.11.1+dfsg-6
ii  libqt5xml5 5.11.1+dfsg-6
ii  libstdc++6 8.2.0-2

akonadi-server recommends no packages.

Versions of packages akonadi-server suggests:
ii  akonadi-backend-mysql   4:17.12.3-3
pn  akonadi-backend-postgresql  
ii  akonadi-backend-sqlite  4:17.12.3-3

-- no debconf information

Bug#906663: vcswatch: should not flag an UNRELEASED changelog entry as "ready for upload"

[Marc Haber]

On Sun, Aug 19, 2018 at 08:48:02PM +0200, Christoph Berg wrote:
 Re: Marc Haber 2018-08-19 
<153468174721.19286.15758469883614485339.report...@fan.zugschlus.de>
> > I could work in a branch, but that would mean additional rules for team
> > maintained packages which I'd rather avoid. I mean, there are valid
> > reasons, for example an upload held back due to an ongoing library
> > transition, for not immediately uploading any new commit to a master
> > branch in git.
> 
> Why are you putting that .0 version there in the first place? Not
> doing that would fix the issue.

I'm trying to avoid

Case 1: Somebody working on the branch, committing things and generating
new changelog entries for a version (x-y) that is already in the archive and
should therefore not be changed in the vcs

Case 2: Somebody working on the branch with a new version (x-y+1),
deploying test versions of the package that will not be overwritten by
later versions of the package (with the same version number) from the
archive, with the side effect that different but identically numbered
versions of the packages fly around. Additionally, the tracker would
begin to remind uploading those versions.

Both cases have already happened in my personal past and caused a good
portion of confusion and grief.

The x-y.0 version nicely solves both issues: it's strictly later (and
different!) than any uploaded version, and strictly earlier (and
different!) than the next uploaded version.

Greetings
Marc

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421

Bug#906692: adminer: php7.2-fpm isn't enough?

[Olaf van der Spek]

Package: adminer
Version: 4.6.3-1
Severity: normal

Hi,

I'm using php7.2-fpm and nginx, which should be enough for adminer but 
apparently isn't..

I think the current depends for adminer are too brittle..

Gr,

Olaf

# apt-cache depends adminer
adminer
 |Depends: libapache2-mod-php
libapache2-mod-php7.0
libapache2-mod-php7.1
libapache2-mod-php7.2
libapache2-mod-php7.3
 |Depends: php-cgi
php7.0-cgi
php7.1-cgi
php7.2-cgi
php7.3-cgi
  Depends: php
php7.0
php7.1
php7.2
php7.3
uwsgi-plugin-php
 |Depends: php-mysql
 |Depends: php-sqlite3
php7.0-sqlite3
php7.1-sqlite3
php7.2-sqlite3
php7.3-sqlite3
  Depends: php-pgsql
php7.0-pgsql
php7.1-pgsql
php7.2-pgsql
php7.3-pgsql
  Recommends: php-cli
php7.0-cli
php7.1-cli
php7.2-cli
php7.3-cli
  Recommends: php-mysql
  Recommends: php-pgsql
php7.0-pgsql
php7.1-pgsql
php7.2-pgsql
php7.3-pgsql
  Recommends: php-sqlite3
php7.0-sqlite3
php7.1-sqlite3
php7.2-sqlite3
php7.3-sqlite3
 |Suggests: default-mysql-server
 |Suggests: 
mariadb-server-10.1
mysql-server-5.7
 |Suggests: postgresql
  Suggests: sqlite3

Gr,

Olaf

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

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

Versions of packages adminer depends on:
ii  php-mysql 1:7.2+62
ii  php-pgsql 1:7.2+62
ii  php-sqlite3   1:7.2+62
ii  php7.0 [php]  7.0.31-1
ii  php7.2-pgsql [php-pgsql]  7.2.9-1
ii  php7.2-sqlite3 [php-sqlite3]  7.2.9-1

Versions of packages adminer recommends:
ii  php-mysql 1:7.2+62
ii  php-pgsql 1:7.2+62
ii  php-sqlite3   1:7.2+62
ii  php7.0-cli [php-cli]  7.0.31-1
ii  php7.2-cli [php-cli]  7.2.9-1
ii  php7.2-pgsql [php-pgsql]  7.2.9-1
ii  php7.2-sqlite3 [php-sqlite3]  7.2.9-1

Versions of packages adminer suggests:
ii  mariadb-server-10.1 [virtual-mysql-server]  1:10.1.35-1

-- no debconf information

Bug#904302: Why outlawing vendor-specific patch series would be a bad idea

[Adrian Bunk]

On Sat, Aug 18, 2018 at 11:31:06AM -0700, Sean Whitton wrote:
> Hello,
> 
> On Fri 17 Aug 2018 at 07:36PM +0300, Adrian Bunk wrote:
> 
> > The main misconception is that there would always be *the* source.
> >
> > Steps you might have before the compilation starts:
> > 1. dpkg unpacks upstream sources
> > 2. dpkg applies patches
> > 3. debian/rules unpacks upstream tarballs as part of the build
> > 4. debian/rules applies patches based on distribution
> > 5. debian/rules applies patches based on release
> > 6. debian/rules applies patches based on architecture
> >
> > What is "the source running on their Ubuntu system" for src:gcc-8?
> >
> > This package skips steps 1 and 2, but does all of steps 3-6.
> 
> But all of steps 3--6 are part of the package build.
> 
> "The source" is what you get after steps 1 and 2.

Why is "The source" what you get after dpkg applied patches,
but before debian/rules applied patches?

For a user it doesn't make a difference which tool applies the patches.

Note that you were also arguing based on a different source
definition:

On Mon, Jul 23, 2018 at 09:22:17AM +0800, Sean Whitton wrote:
> For example, someone might want to use a Debian system to investigate a
> bug on an Ubuntu system.  They might begin by downloading some source
> packages from the Ubuntu mirrors.  Since they obtained them from Ubuntu,
> they will form the reasonable expectation that unpacking these source
> packages will get them the code running on the Ubuntu system they are
> debugging.

This would be useful for debugging problems.

But it is important to understand that in the general case there will 
always be cases where the code running on your system will depend on
the architecture of your system - after applying patches the sources
might be architecture-specific.

This implies that for these usecases you want to make possible dpkg 
would not require less conditional patching functionality - it would
actually require more conditional patching functionality so that
dpkg can give you the exact sources for the architecture you are
looking at.

Since we have established that conditional patching support is in any 
case required for your usecase, the vendor patching becomes less of
an issue since this will anyways require even more tooling support
for conditional patching.

> Sean Whitton

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#906663: vcswatch: should not flag an UNRELEASED changelog entry as "ready for upload"

[Christoph Berg]

Control: reassign -1 tracker.debian.org

Re: Marc Haber 2018-08-19 
<153468174721.19286.15758469883614485339.report...@fan.zugschlus.de>
> vcswatch makes this "VCS has unreleased changes", which is correct. The
> tracker, however, makes this "A new version is available int the VCS"
> which is not the case.

That sounds like this should be fixed on the tracker side.

> I could work in a branch, but that would mean additional rules for team
> maintained packages which I'd rather avoid. I mean, there are valid
> reasons, for example an upload held back due to an ongoing library
> transition, for not immediately uploading any new commit to a master
> branch in git.

Why are you putting that .0 version there in the first place? Not
doing that would fix the issue.

Christoph

Bug#906677: apt remove php7.0-fpm wants to install apache2 but doesn't tell why

[Olaf van der Spek]

2018-08-19 20:01 GMT+02:00 Julian Andres Klode :
> Well then, tell apt (apt remove php7.0-fpm apache2

Like this?

# apt remove php7.0-fpm apache2

Reading package lists... Done
Building dependency tree
Reading state information... Done
Package 'apache2' is not installed, so not removed
The following additional packages will be installed:
  apache2-bin libapache2-mod-php7.0 libaprutil1-dbd-sqlite3
libaprutil1-ldap libbrotli1 liblua5.2-0
Suggested packages:
  apache2-doc apache2-suexec-pristine | apache2-suexec-custom www-browser
Recommended packages:
  apache2
The following packages will be REMOVED:
  php7.0-fpm
The following NEW packages will be installed:
  apache2-bin libapache2-mod-php7.0 libaprutil1-dbd-sqlite3
libaprutil1-ldap libbrotli1 liblua5.2-0
0 upgraded, 6 newly installed, 1 to remove and 0 not upgraded.
Need to get 3,003 kB of archives.
After this operation, 6,132 kB of additional disk space will be used.
Do you want to continue? [Y/n]

> apt install foo apache2-).

What's foo in this case?

> APT can't
> possibly know that.

Know what?

>> I think apt should tell where the dependency on apache2 comes from.
>
> Nah, that would be too verbose.

Why's that?

> You could use debugging logs to figure that out, or just
> tell apt not to install apache2.
>
>> I fell like the apt output could be cleaner as well, lots of packages are 
>> mentioned twice and suggested pkgs really doesn't help here.
>
> They're mentioned as often as needed.

How does that help the user?

> That Suggested packages don't help is your
> opinion.
>
> --
> debian developer - deb.li/jak | jak-linux.org - free software dev
> ubuntu core developer  i speak de, en



-- 
Olaf

Bug#893700: Backports

[Olaf van der Spek]

Is there a bug report / email thread about this?

2018-08-19 20:26 GMT+02:00 Ondřej Surý :
> It would be an easy thing if I get a ack from backports masters, but I am not 
> going ask them again.
>
> Ondřej
> --
> Ondřej Surý 
>
>> On 19 Aug 2018, at 18:31, Olaf van der Spek  wrote:
>>
>> Hi,
>>
>> I'd love to see a backport as well.
>>
>> --
>> Olaf
>>
>



-- 
Olaf

Bug#906686: getrandom() blocks

[Olaf van der Spek]

Found the cause..

# strace -p 392

strace: Process 392 attached
getrandom(0x7ffcc15b8a40, 16, 0)= ? ERESTARTSYS (To be
restarted if SA_RESTART is set)
--- SIGTERM {si_signo=SIGTERM, si_code=SI_USER, si_pid=1, si_uid=0} ---
+++ killed by SIGTERM +++

-- 
Olaf

Bug#906691: deepin-movie-reborn FTBFS on armel/armhf: error: conflicting declaration 'typedef ptrdiff_t GLsizeiptr'

[Adrian Bunk]

Source: deepin-movie-reborn
Version: 3.2.8-1
Severity: important
Tags: ftbfs

https://buildd.debian.org/status/package.php?p=deepin-movie-reborn=sid

...
In file included from /usr/include/GL/gl.h:2055,
 from /usr/include/GL/glx.h:32,
 from /<>/src/libdmr/compositing_manager.cpp:44:
/usr/include/GL/glext.h:468:19: error: conflicting declaration 'typedef 
ptrdiff_t GLsizeiptr'
 typedef ptrdiff_t GLsizeiptr;
   ^~
In file included from /usr/include/arm-linux-gnueabihf/qt5/QtGui/qopengl.h:105,
 from /usr/include/arm-linux-gnueabihf/qt5/QtGui/QtGui:43,
 from /<>/src/libdmr/compositing_manager.cpp:40:
/usr/include/GLES3/gl32.h:77:25: note: previous declaration as 'typedef 
khronos_ssize_t GLsizeiptr'
 typedef khronos_ssize_t GLsizeiptr;
 ^~
In file included from /usr/include/GL/gl.h:2055,
 from /usr/include/GL/glx.h:32,
 from /<>/src/libdmr/compositing_manager.cpp:44:
/usr/include/GL/glext.h:469:19: error: conflicting declaration 'typedef 
ptrdiff_t GLintptr'
 typedef ptrdiff_t GLintptr;
   ^~~~
In file included from /usr/include/arm-linux-gnueabihf/qt5/QtGui/qopengl.h:105,
 from /usr/include/arm-linux-gnueabihf/qt5/QtGui/QtGui:43,
 from /<>/src/libdmr/compositing_manager.cpp:40:
/usr/include/GLES3/gl32.h:78:26: note: previous declaration as 'typedef 
khronos_intptr_t GLintptr'
 typedef khronos_intptr_t GLintptr;
  ^~~~
/<>/src/libdmr/compositing_manager.cpp: In member function 'bool 
dmr::CompositingManager::is_device_viable(int)':
/<>/src/libdmr/compositing_manager.cpp:295:15: warning: ignoring 
return value of 'int fscanf(FILE*, const char*, ...)', declared with attribute 
warn_unused_result [-Wunused-result]
 fscanf(fp, "%d", );
 ~~^~~~
make[3]: *** [src/libdmr/CMakeFiles/dmr.dir/build.make:66: 
src/libdmr/CMakeFiles/dmr.dir/compositing_manager.cpp.o] Error 1


The root cause is that on armel/armhf (and arm64 in Ubuntu)
Qt5 is compiled with OpenGL ES instead of OpenGL.

Ideally it should be fixed to build and work with OpenGL ES, but
if this is not easily possible please add a build dependency on
libqt5opengl5-desktop-dev to stop trying to build it on armel/armhf.

Bug#905433: git-debrebase: debrebase new-upstream fails with "uninitialized value"

[Ian Jackson]

Control: retitle -1 consider renaming convert-from-gbp

Ian Jackson writes ("Re: Bug#905433: git-debrebase: debrebase new-upstream 
fails with "uninitialized value""):
> I think you've probably figured this out now, but in your situation
> git-debrebse convert-from-gbp will do what you need.
> 
> I'm increasingly of the opinion that that subcommand needs to be
> renamed, in addition to improving the docs.

I am currently inclined to rename this to
   convert-from-unpatched
or something, but I would like to hear Sean's opinion.

> > Quoting Ian Jackson (2018-08-04 18:15:47)
> > > This error message is fixed in git but not in 6.4.
> > > My current branch says this instead:
> > > 
> > >   git-debrebase: error: found unprocessable commit, cannot cope; bare
> > >   dgit dsc import: (commit d3481fe48afe150f38f331048abe6452b8389723)
> > >   (d.0x30 0x32)
> > > 
> > > Related UI bugs are:
> > > 
> > >   #905005 Want better user hinting for unprocessable commits
> > >   #905279 Suggest `dgit convert-from-dgit-view` sometimes
> > 
> > Okay, that would tell me that it cannot cope with a commit that
> > was created by dgit very early on in my git history. From this
> > error message I would still not know what to do next.
> 
> Indeed.  Hence, in particular, #905005.

Right.  I am going to treat this bug as a request to rename the
command.

Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Bug#906659: keepassxc: FTBFS in buster/sid (invalid use of incomplete type â class QButtonGroupâ )

[Julian Andres Klode]

On Sun, Aug 19, 2018 at 07:30:31PM +0200, Nazar Zhuk wrote:
> This is fixed upstream in 2.3.3.
> Related upstream bug:
> https://github.com/keepassxreboot/keepassxc/issues/2048
> Upstream patch:
> https://github.com/keepassxreboot/keepassxc/commit/3bbc6ac0e6298d27bfe0c41999460cafda8edf18

I packaged it in git, I should upload it. Well, I'll probably wait for .4, I 
think
that's around the corner.

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

Bug#906451: tar-pack seems an unmaintained module

[Pirate Praveen]

On Sun, 19 Aug 2018 21:54:11 +0530 Pirate Praveen
 wrote:
> The only package that depends on node-tar-pack is node-pre-gyp, which
> has a newer upstream release that no longer depends on tar-pack.
> 

I have uploaded a new upstream version of node-pre-gyp (0.6.32-1 ->
0.10.2-1)  to experimental. node-mapnik, node-sqlite3 and node-zipfile
are its reverse dependencies.

Lazslo, Sebastian, Jeremy, can you confirm if this version is compatible
with your package? I'd like to upload this to unstable soon. Since it is
still in 0.x I assume it can have breaking changes, so just giving a
heads up to be extra careful here.



signature.asc
Description: OpenPGP digital signature

Bug#906690: ring: FTBFS with Boost 1.67

[Simon Quigley]

Package: ring
Severity: important

Dear Maintainer,

In Ubuntu, Boost 1.67 is the default, while in Debian 1.62 is. Your
package is FTBFS with 1.67 but working with 1.65 and 1.62, so in Ubuntu
I am setting an explicit dependency on 1.65.1 until the FTBFS is solved.

Eventually, it seems that Debian will switch to it as default, so it
would be good to get this solved to minimize the delta and ensure future
compatibility.

Attached is the amd64 build log from Ubuntu; you can likely reach the
same result by explicitly depending on 1.67 in a build with Sid.

Thanks.

-- 
Simon Quigley
tsimo...@ubuntu.com
tsimonq2 on freenode and OFTC
5C7A BEA2 0F86 3045 9CC8
C8B5 E27F 2CF8 458C 2FA4


buildlog_ubuntu-cosmic-amd64.ring_20180712.2.f3b87a6~ds1-1build1_BUILDING.txt.gz
Description: application/gzip


signature.asc
Description: OpenPGP digital signature

Bug#906686: php7.2-fpm: 7.2 FPM fails to start @boot

[Ondřej Surý]

That usually happens when fpm isn’t compiled with systemd. Can you please check 
the binary with ldd?

--
Ondřej Surý 

> On 19 Aug 2018, at 20:02, Olaf van der Spek  wrote:
> 
> Package: php7.2-fpm
> Version: 7.2.9-1
> Severity: normal
> 
> Hi,
> 
> Not sure why, 7.0 start just fine, can't find anything specific in logs.
> 
> Gr,
> 
> Olaf
> 
> # service php7.2-fpm status
> 
> ● php7.2-fpm.service - The PHP 7.2 FastCGI Process Manager
>   Loaded: loaded (/lib/systemd/system/php7.2-fpm.service; enabled; vendor 
> preset: enabled)
>   Active: failed (Result: timeout) since Sun 2018-08-19 18:33:28 CEST; 1h 
> 22min ago
> Docs: man:php-fpm7.2(8)
>  Process: 407 ExecStart=/usr/sbin/php-fpm7.2 --nodaemonize --fpm-config 
> /etc/php/7.2/fpm/php-fpm.conf (code=killed, signal=TERM)
> Main PID: 407 (code=killed, signal=TERM)
> 
> Aug 19 18:31:57 debian systemd[1]: Starting The PHP 7.2 FastCGI Process 
> Manager...
> Aug 19 18:33:28 debian systemd[1]: php7.2-fpm.service: Start operation timed 
> out. Terminating.
> Aug 19 18:33:28 debian systemd[1]: php7.2-fpm.service: Failed with result 
> 'timeout'.
> Aug 19 18:33:28 debian systemd[1]: Failed to start The PHP 7.2 FastCGI 
> Process Manager.
> 
> $ ls -l /run/php
> 
> total 4
> -rw-r--r-- 1 root root 3 Aug 19 18:31 php7.0-fpm.pid
> srw-rw 1 www-data www-data 0 Aug 19 18:31 php7.0-fpm.sock
> 
> # cat php7.2-fpm.log 
> 
> [19-Aug-2018 17:57:06] NOTICE: fpm is running, pid 1273
> [19-Aug-2018 17:57:06] NOTICE: ready to handle connections
> [19-Aug-2018 17:57:06] NOTICE: systemd monitor interval set to 1ms
> [19-Aug-2018 18:00:23] NOTICE: Terminating ...
> [19-Aug-2018 18:00:23] NOTICE: exiting, bye-bye!
> [19-Aug-2018 18:19:24] NOTICE: fpm is running, pid 388
> [19-Aug-2018 18:19:24] NOTICE: ready to handle connections
> [19-Aug-2018 18:19:24] NOTICE: systemd monitor interval set to 1ms
> [19-Aug-2018 18:31:39] NOTICE: Terminating ...
> [19-Aug-2018 18:31:39] NOTICE: exiting, bye-bye!
> 
> syslog:
> Aug 19 18:33:28 debian systemd[1]: php7.2-fpm.service: Start operation timed 
> out. Terminating.
> Aug 19 18:33:28 debian systemd[1]: php7.2-fpm.service: Failed with result 
> 'timeout'.
> Aug 19 18:33:28 debian systemd[1]: Failed to start The PHP 7.2 FastCGI 
> Process Manager.
> 
> # service php7.2-fpm start
> 
> # service php7.2-fpm status
> 
> ● php7.2-fpm.service - The PHP 7.2 FastCGI Process Manager
>   Loaded: loaded (/lib/systemd/system/php7.2-fpm.service; enabled; vendor 
> preset: enabled)
>   Active: active (running) since Sun 2018-08-19 19:59:42 CEST; 1s ago
> Docs: man:php-fpm7.2(8)
> Main PID: 1689 (php-fpm7.2)
>   Status: "Ready to handle connections"
>Tasks: 3 (limit: 2328)
>   Memory: 14.7M
>   CGroup: /system.slice/php7.2-fpm.service
>   ├─1689 php-fpm: master process (/etc/php/7.2/fpm/php-fpm.conf)
>   ├─1690 php-fpm: pool www
>   └─1691 php-fpm: pool www
> 
> Aug 19 19:59:42 debian systemd[1]: Starting The PHP 7.2 FastCGI Process 
> Manager...
> Aug 19 19:59:42 debian systemd[1]: Started The PHP 7.2 FastCGI Process 
> Manager.
> 
> 
> 
> -- Package-specific info:
>  Additional PHP 7.2 information 
> 
>  PHP 7.2 SAPI (php7.2query -S): 
> 
>  PHP 7.2 Extensions (php7.2query -M -v): 
> 
>  Configuration files: 
> [PHP]
> engine = On
> short_open_tag = Off
> precision = 14
> output_buffering = 4096
> zlib.output_compression = Off
> implicit_flush = Off
> unserialize_callback_func =
> serialize_precision = -1
> disable_functions = 
> pcntl_alarm,pcntl_fork,pcntl_waitpid,pcntl_wait,pcntl_wifexited,pcntl_wifstopped,pcntl_wifsignaled,pcntl_wifcontinued,pcntl_wexitstatus,pcntl_wtermsig,pcntl_wstopsig,pcntl_signal,pcntl_signal_get_handler,pcntl_signal_dispatch,pcntl_get_last_error,pcntl_strerror,pcntl_sigprocmask,pcntl_sigwaitinfo,pcntl_sigtimedwait,pcntl_exec,pcntl_getpriority,pcntl_setpriority,pcntl_async_signals,
> disable_classes =
> zend.enable_gc = On
> expose_php = Off
> max_execution_time = 30
> max_input_time = 60
> memory_limit = 128M
> error_reporting = E_ALL & ~E_DEPRECATED & ~E_STRICT
> display_errors = Off
> display_startup_errors = Off
> log_errors = On
> log_errors_max_len = 1024
> ignore_repeated_errors = Off
> ignore_repeated_source = Off
> report_memleaks = On
> html_errors = On
> variables_order = "GPCS"
> request_order = "GP"
> register_argc_argv = Off
> auto_globals_jit = On
> post_max_size = 8M
> auto_prepend_file =
> auto_append_file =
> default_mimetype = "text/html"
> default_charset = "UTF-8"
> doc_root =
> user_dir =
> enable_dl = Off
> file_uploads = On
> upload_max_filesize = 2M
> max_file_uploads = 20
> allow_url_fopen = On
> allow_url_include = Off
> default_socket_timeout = 60
> [CLI Server]
> cli_server.color = On
> [Date]
> [filter]
> [iconv]
> [intl]
> [sqlite3]
> [Pcre]
> [Pdo]
> [Pdo_mysql]
> pdo_mysql.cache_size = 2000
> pdo_mysql.default_socket=
> [Phar]
> [mail function]
> SMTP = localhost
> smtp_port = 25
> mail.add_x_header = 

Bug#893700: Backports

[Ondřej Surý]

It would be an easy thing if I get a ack from backports masters, but I am not 
going ask them again.

Ondřej 
--
Ondřej Surý 

> On 19 Aug 2018, at 18:31, Olaf van der Spek  wrote:
> 
> Hi,
> 
> I'd love to see a backport as well.
> 
> -- 
> Olaf
> 

Bug#906689: breezy: autopkgtest regression: can't find python3-meliae:amd64

[Paul Gevers]

Source: breezy
Version: 3.0.0~bzr7067-1
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: regression

Dear maintainers,

With a recent upload the autpkgtest of your package started to fail in
testing. I copied the output below.

Currently this regression is contributing to the delay of the migration
to testing [1]. Could you please investigate the situation and fix it?
If needed, please change the bug's severity as appropriate.

The autopkgtest of you package now defines a test dependency on a
non-existent package: python3-meliae.

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

Paul

[1] https://qa.debian.org/excuses.php?package=breezy

https://ci.debian.net/data/autopkgtest/testing/amd64/b/breezy/845560/log.gz

Broken autopkgtest-satdep:amd64 Depends on python3-meliae:amd64 < none
@un H >
  Removing autopkgtest-satdep:amd64 because I can't find
python3-meliae:amd64



signature.asc
Description: OpenPGP digital signature

Bug#906688: ruby-netrc: FTBFS in buster/sid (test_missing_environment fails)

[Santiago Vila]

Package: src:ruby-netrc
Version: 0.11.0-1
Severity: serious
Tags: ftbfs

Dear maintainer:

I tried to build this package in buster but it failed:


[...]
 debian/rules build-indep
dh build-indep --buildsystem=ruby --with ruby
   dh_update_autotools_config -i -O--buildsystem=ruby
   dh_auto_configure -i -O--buildsystem=ruby
dh_ruby --configure
   dh_auto_build -i -O--buildsystem=ruby
dh_ruby --build
   dh_ruby --build
   dh_auto_test -i -O--buildsystem=ruby
dh_ruby --test
 fakeroot debian/rules binary-indep
dh binary-indep --buildsystem=ruby --with ruby
   dh_testroot -i -O--buildsystem=ruby
   dh_prep -i -O--buildsystem=ruby

[... snipped ...]

TestNetrc#test_multi_without_default = 0.00 s = .
TestNetrc#test_set = 0.00 s = .
TestNetrc#test_missing_environment = 0.00 s = F
TestNetrc#test_permission_error = 0.00 s = .
TestNetrc#test_save = 0.00 s = .
TestNetrc#test_entry_splat = 0.00 s = .
TestNetrc#test_get_missing = DEPRECATED: Use assert_nil if expecting nil from 
/<>/test/test_netrc.rb:169. This will fail in Minitest 6.
0.00 s = .
TestNetrc#test_netrc_environment_variable = 0.00 s = .
TestNetrc#test_add_get = 0.00 s = .
TestNetrc#test_add_newlineless = 0.00 s = .
TestNetrc#test_permission_error_windows = 0.00 s = .
TestNetrc#test_multi_with_default = 0.00 s = .
TestNetrc#test_allow_permissive_netrc_file_option = 0.00 s = .
TestNetrc#test_write_entry = 0.00 s = .
TestNetrc#test_parse_file = 0.00 s = .
TestNetrc#test_with_default = 0.00 s = .
TestNetrc#test_entry_implicit_splat = 0.00 s = .
TestNetrc#test_missing_file = 0.00 s = .
TestNetrc#test_parse_empty = 0.00 s = .
TestNetrc#test_set_get = 0.00 s = .
TestNetrc#test_password_file = 0.00 s = .
TestNetrc#test_add = 0.00 s = .
TestNetrc#test_login_file = 0.00 s = .

Finished in 0.022940s, 1787.2391 runs/s, 2571.8807 assertions/s.

  1) Failure:
TestNetrc#test_missing_environment [/<>/test/test_netrc.rb:203]:
--- expected
+++ actual
@@ -1,2 +1 @@
-# encoding: ASCII-8BIT
-"/<>/.netrc"
+"/build/.netrc"


41 runs, 59 assertions, 1 failures, 0 errors, 0 skips
rake aborted!
Command failed with status (1): [ruby -w  
"/usr/lib/ruby/vendor_ruby/rake/rake_test_loader.rb" "test/test_lex.rb" 
"test/test_netrc.rb" "test/test_parse.rb" -v]

Tasks: TOP => default
(See full trace by running task with --trace)
ERROR: Test "ruby2.5" failed. Exiting.
dh_auto_install: dh_ruby --install /<>/debian/ruby-netrc returned 
exit code 1
make: *** [debian/rules:6: binary-indep] Error 1
dpkg-buildpackage: error: fakeroot debian/rules binary-indep subprocess 
returned exit status 2


The above build was made with sbuild and schroot, under a user called "buildd" 
having
/build as its home directory.

Note: This does not happen in reproducible builds, but I don't know why.
Apparently, this happens every time, in any way it's built (sbuild or by hand),
as far as the build directory is different than the HOME directory.

Thanks.

Bug#906687: pymongo breaks python-motor autopkgtest

[Paul Gevers]

Source: pymongo, python-motor
Version: pymongo/3.7.1-1
Version: python-motor/1.2.3-1
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: breaks needs-update

Dear maintainers,

With a recent upload of pymongo the autpkgtest of python-motor started
to fail in testing (it fails longer already in unstable, I didn't check
why). I copied the output below.

Currently this regression is contributing to the delay of the migration
of pymongo to testing [1]. Could you please investigate the situation
and reassign the bug to the right package? If needed, please change the
bug's severity as appropriate. Unfortunately the errors are too many and
to generic for me as an outsider to be of any help here.

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

Paul

[1] https://qa.debian.org/excuses.php?package=pymongo

https://ci.debian.net/data/autopkgtest/testing/amd64/p/python-motor/845596/log.gz

autopkgtest [07:04:38]: test command1: set -e ; for py in $(pyversions
-r 2>/dev/null) ; do echo "Testing with $py:" ; $py setup.py test ; done



==
ERROR: test_cursor_explicit_close
(tornado_tests.test_motor_cursor.MotorCursorTest)
--
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/tornado/testing.py", line 124,
in __call__
result = self.orig_method(*args, **kwargs)
  File "/usr/lib/python2.7/dist-packages/tornado/testing.py", line 543,
in post_coroutine
self._test_generator.throw(e)
  File
"/tmp/autopkgtest-lxc.u0m5abk7/downtmp/build.Qs8/src/test/tornado_tests/test_motor_cursor.py",
line 301, in test_cursor_explicit_close
request = yield self.run_thread(server.receives, "find", "coll")
TimeoutError: Operation timed out after 5 seconds

==
ERROR: test_exhaust_query_network_error_rs
(tornado_tests.test_motor_client.MotorClientExhaustCursorTest)
--
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/tornado/testing.py", line 124,
in __call__
result = self.orig_method(*args, **kwargs)
  File "/usr/lib/python2.7/dist-packages/tornado/testing.py", line 534,
in post_coroutine
timeout=timeout)
  File "/usr/lib/python2.7/dist-packages/tornado/ioloop.py", line 581,
in run_sync
return future_cell[0].result()
  File "/usr/lib/python2.7/dist-packages/tornado/concurrent.py", line
260, in result
raise_exc_info(self._exc_info)
  File "/usr/lib/python2.7/dist-packages/tornado/gen.py", line 1107, in run
yielded = self.gen.throw(*exc_info)
  File
"/tmp/autopkgtest-lxc.u0m5abk7/downtmp/build.Qs8/src/test/tornado_tests/test_motor_client.py",
line 338, in test_exhaust_query_network_error_rs
yield self._test_exhaust_query_network_error(rs=True)
  File "/usr/lib/python2.7/dist-packages/tornado/gen.py", line 1099, in run
value = future.result()
  File "/usr/lib/python2.7/dist-packages/tornado/concurrent.py", line
260, in result
raise_exc_info(self._exc_info)
  File "/usr/lib/python2.7/dist-packages/tornado/gen.py", line 1107, in run
yielded = self.gen.throw(*exc_info)
  File
"/tmp/autopkgtest-lxc.u0m5abk7/downtmp/build.Qs8/src/test/tornado_tests/test_motor_client.py",
line 313, in _test_exhaust_query_network_error
yield client.admin.command('ismaster')
  File "/usr/lib/python2.7/dist-packages/tornado/gen.py", line 1099, in run
value = future.result()
  File "/usr/lib/python2.7/dist-packages/tornado/concurrent.py", line
260, in result
raise_exc_info(self._exc_info)
  File "", line 3, in raise_exc_info
AutoReconnect: connection closed

==
ERROR: test_exhaust_query_network_error_standalone
(tornado_tests.test_motor_client.MotorClientExhaustCursorTest)
--
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/tornado/testing.py", line 124,
in __call__
result = self.orig_method(*args, **kwargs)
  File "/usr/lib/python2.7/dist-packages/tornado/testing.py", line 534,
in post_coroutine
timeout=timeout)
  File "/usr/lib/python2.7/dist-packages/tornado/ioloop.py", line 581,
in run_sync
return future_cell[0].result()
  File "/usr/lib/python2.7/dist-packages/tornado/concurrent.py", line
260, in result
raise_exc_info(self._exc_info)
  File "/usr/lib/python2.7/dist-packages/tornado/gen.py", line 1107, in run
yielded = self.gen.throw(*exc_info)
  File
"/tmp/autopkgtest-lxc.u0m5abk7/downtmp/build.Qs8/src/test/tornado_tests/test_motor_client.py",
line 334, in test_exhaust_query_network_error_standalone
yield self._test_exhaust_query_network_error(rs=False)
  File 

Bug#906683: [Piuparts-devel] Bug#906683: piuparts doesn't understand the option --ignore-regexp

[Holger Levsen]

control: severity -1 important
# thanks for filing this bug report, nicoo


-- 
cheers,
Holger

---
holger@(debian|reproducible-builds).org


signature.asc
Description: PGP signature

Bug#906677: apt remove php7.0-fpm wants to install apache2 but doesn't tell why

[Julian Andres Klode]

On Sun, Aug 19, 2018 at 06:25:19PM +0200, Olaf van der Spek wrote:
> Package: apt
> Version: 1.6.3
> Severity: normal
> 
> Hi,
> 
> I'd like to remove php7.0-fpm and I don't want to install apache2.. I've 
> already got nginx.

Well then, tell apt (apt remove php7.0-fpm apache2, apt install foo apache2-). 
APT can't
possibly know that.

> 
> I think apt should tell where the dependency on apache2 comes from.

Nah, that would be too verbose. You could use debugging logs to figure that 
out, or just
tell apt not to install apache2.

> I fell like the apt output could be cleaner as well, lots of packages are 
> mentioned twice and suggested pkgs really doesn't help here.

They're mentioned as often as needed. That Suggested packages don't help is your
opinion.

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

Bug#906686: php7.2-fpm: 7.2 FPM fails to start @boot

[Olaf van der Spek]

Package: php7.2-fpm
Version: 7.2.9-1
Severity: normal

Hi,

Not sure why, 7.0 start just fine, can't find anything specific in logs.

Gr,

Olaf

# service php7.2-fpm status

● php7.2-fpm.service - The PHP 7.2 FastCGI Process Manager
   Loaded: loaded (/lib/systemd/system/php7.2-fpm.service; enabled; vendor 
preset: enabled)
   Active: failed (Result: timeout) since Sun 2018-08-19 18:33:28 CEST; 1h 
22min ago
 Docs: man:php-fpm7.2(8)
  Process: 407 ExecStart=/usr/sbin/php-fpm7.2 --nodaemonize --fpm-config 
/etc/php/7.2/fpm/php-fpm.conf (code=killed, signal=TERM)
 Main PID: 407 (code=killed, signal=TERM)

Aug 19 18:31:57 debian systemd[1]: Starting The PHP 7.2 FastCGI Process 
Manager...
Aug 19 18:33:28 debian systemd[1]: php7.2-fpm.service: Start operation timed 
out. Terminating.
Aug 19 18:33:28 debian systemd[1]: php7.2-fpm.service: Failed with result 
'timeout'.
Aug 19 18:33:28 debian systemd[1]: Failed to start The PHP 7.2 FastCGI Process 
Manager.

$ ls -l /run/php

total 4
-rw-r--r-- 1 root root 3 Aug 19 18:31 php7.0-fpm.pid
srw-rw 1 www-data www-data 0 Aug 19 18:31 php7.0-fpm.sock

# cat php7.2-fpm.log 

[19-Aug-2018 17:57:06] NOTICE: fpm is running, pid 1273
[19-Aug-2018 17:57:06] NOTICE: ready to handle connections
[19-Aug-2018 17:57:06] NOTICE: systemd monitor interval set to 1ms
[19-Aug-2018 18:00:23] NOTICE: Terminating ...
[19-Aug-2018 18:00:23] NOTICE: exiting, bye-bye!
[19-Aug-2018 18:19:24] NOTICE: fpm is running, pid 388
[19-Aug-2018 18:19:24] NOTICE: ready to handle connections
[19-Aug-2018 18:19:24] NOTICE: systemd monitor interval set to 1ms
[19-Aug-2018 18:31:39] NOTICE: Terminating ...
[19-Aug-2018 18:31:39] NOTICE: exiting, bye-bye!

syslog:
Aug 19 18:33:28 debian systemd[1]: php7.2-fpm.service: Start operation timed 
out. Terminating.
Aug 19 18:33:28 debian systemd[1]: php7.2-fpm.service: Failed with result 
'timeout'.
Aug 19 18:33:28 debian systemd[1]: Failed to start The PHP 7.2 FastCGI Process 
Manager.

# service php7.2-fpm start

# service php7.2-fpm status

● php7.2-fpm.service - The PHP 7.2 FastCGI Process Manager
   Loaded: loaded (/lib/systemd/system/php7.2-fpm.service; enabled; vendor 
preset: enabled)
   Active: active (running) since Sun 2018-08-19 19:59:42 CEST; 1s ago
 Docs: man:php-fpm7.2(8)
 Main PID: 1689 (php-fpm7.2)
   Status: "Ready to handle connections"
Tasks: 3 (limit: 2328)
   Memory: 14.7M
   CGroup: /system.slice/php7.2-fpm.service
   ├─1689 php-fpm: master process (/etc/php/7.2/fpm/php-fpm.conf)
   ├─1690 php-fpm: pool www
   └─1691 php-fpm: pool www

Aug 19 19:59:42 debian systemd[1]: Starting The PHP 7.2 FastCGI Process 
Manager...
Aug 19 19:59:42 debian systemd[1]: Started The PHP 7.2 FastCGI Process Manager.



-- Package-specific info:
 Additional PHP 7.2 information 

 PHP 7.2 SAPI (php7.2query -S): 

 PHP 7.2 Extensions (php7.2query -M -v): 

 Configuration files: 
[PHP]
engine = On
short_open_tag = Off
precision = 14
output_buffering = 4096
zlib.output_compression = Off
implicit_flush = Off
unserialize_callback_func =
serialize_precision = -1
disable_functions = 
pcntl_alarm,pcntl_fork,pcntl_waitpid,pcntl_wait,pcntl_wifexited,pcntl_wifstopped,pcntl_wifsignaled,pcntl_wifcontinued,pcntl_wexitstatus,pcntl_wtermsig,pcntl_wstopsig,pcntl_signal,pcntl_signal_get_handler,pcntl_signal_dispatch,pcntl_get_last_error,pcntl_strerror,pcntl_sigprocmask,pcntl_sigwaitinfo,pcntl_sigtimedwait,pcntl_exec,pcntl_getpriority,pcntl_setpriority,pcntl_async_signals,
disable_classes =
zend.enable_gc = On
expose_php = Off
max_execution_time = 30
max_input_time = 60
memory_limit = 128M
error_reporting = E_ALL & ~E_DEPRECATED & ~E_STRICT
display_errors = Off
display_startup_errors = Off
log_errors = On
log_errors_max_len = 1024
ignore_repeated_errors = Off
ignore_repeated_source = Off
report_memleaks = On
html_errors = On
variables_order = "GPCS"
request_order = "GP"
register_argc_argv = Off
auto_globals_jit = On
post_max_size = 8M
auto_prepend_file =
auto_append_file =
default_mimetype = "text/html"
default_charset = "UTF-8"
doc_root =
user_dir =
enable_dl = Off
file_uploads = On
upload_max_filesize = 2M
max_file_uploads = 20
allow_url_fopen = On
allow_url_include = Off
default_socket_timeout = 60
[CLI Server]
cli_server.color = On
[Date]
[filter]
[iconv]
[intl]
[sqlite3]
[Pcre]
[Pdo]
[Pdo_mysql]
pdo_mysql.cache_size = 2000
pdo_mysql.default_socket=
[Phar]
[mail function]
SMTP = localhost
smtp_port = 25
mail.add_x_header = Off
[ODBC]
odbc.allow_persistent = On
odbc.check_persistent = On
odbc.max_persistent = -1
odbc.max_links = -1
odbc.defaultlrl = 4096
odbc.defaultbinmode = 1
[Interbase]
ibase.allow_persistent = 1
ibase.max_persistent = -1
ibase.max_links = -1
ibase.timestampformat = "%Y-%m-%d %H:%M:%S"
ibase.dateformat = "%Y-%m-%d"
ibase.timeformat = "%H:%M:%S"
[MySQLi]
mysqli.max_persistent = -1
mysqli.allow_persistent = On
mysqli.max_links = -1
mysqli.cache_size = 2000

Bug#906685: ruby-mocha breaks ruby-bourne autopkgtest

[Paul Gevers]

Source: ruby-mocha, ruby-bourne
Version: ruby-mocha/1.7.0-1
Version: ruby-bourne/1.6.0-1
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: breaks needs-update

Dear maintainers,

With a recent upload of ruby-mocha the autpkgtest of ruby-bourne started
to fail in testing. I copied the output below.

Currently this regression is contributing to the delay of the migration
of ruby-mocha to testing [1]. Could you please investigate the situation
and reassign the bug to the right package? If needed, please change the
bug's severity as appropriate.

Looking at the error I would not be surprised if the test suite of
ruby-bourne just needs an update for a deprecated function, but the
upstream of ruby-bourne may be warned about this (or may have already
fixed it). If ruby-bourne is fixed soon, than ruby-mocha may want to add
a versioned Breaks to speed up migration.

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

Paul

[1] https://qa.debian.org/excuses.php?package=ruby-mocha

https://ci.debian.net/data/autopkgtest/testing/amd64/r/ruby-bourne/846106/log.gz

autopkgtest [09:23:56]: test command1: gem2deb-test-runner --autopkgtest
--check-dependencies 2>&1
autopkgtest [09:23:56]: test command1: [---

┌──┐
│ Checking Rubygems dependency resolution on ruby2.5
  │
└──┘

GEM_PATH= ruby2.5 -e gem\ \"bourne\"

┌──┐
│ Run tests for ruby2.5 from debian/ruby-test-files.yaml
  │
└──┘

mv lib .gem2deb.lib
RUBYLIB=. GEM_PATH= ruby2.5 -ryaml -e
YAML.load_file\(\"debian/ruby-test-files.yaml\"\).each\ \{\ \|f\|\
require\ f\ \}
Warning: you should require 'minitest/autorun' instead.
Warning: or add 'gem "minitest"' before 'require "minitest/autorun"'
From:

/tmp/autopkgtest-lxc.ze38g2wo/downtmp/build.XBn/src/test/mini_test_result.rb:3:in
`'
  -e:1:in `block in '
  -e:1:in `each'
  -e:1:in `'
Loaded suite -e
Started
E
===
Error: test_fails_if_invocation_count_too_high(AssertReceivedTest):
  NoMethodError: undefined method `reset_instance' for Mocha::Mockery:Class
  Did you mean?  reset_mocha
/tmp/autopkgtest-lxc.ze38g2wo/downtmp/build.XBn/src/test/unit/assert_received_test.rb:14:in
`teardown'
===
E
===
Error: test_fails_if_invocation_count_too_low(AssertReceivedTest):
  NoMethodError: undefined method `reset_instance' for Mocha::Mockery:Class
  Did you mean?  reset_mocha
/tmp/autopkgtest-lxc.ze38g2wo/downtmp/build.XBn/src/test/unit/assert_received_test.rb:14:in
`teardown'
===
E
===
Error: test_fails_if_invocation_doesnt_exist(AssertReceivedTest):
  NoMethodError: undefined method `reset_instance' for Mocha::Mockery:Class
  Did you mean?  reset_mocha
/tmp/autopkgtest-lxc.ze38g2wo/downtmp/build.XBn/src/test/unit/assert_received_test.rb:14:in
`teardown'
===
E
===
Error:
test_fails_if_invocation_exists_only_on_other_mock(AssertReceivedTest):
  NoMethodError: undefined method `reset_instance' for Mocha::Mockery:Class
  Did you mean?  reset_mocha
/tmp/autopkgtest-lxc.ze38g2wo/downtmp/build.XBn/src/test/unit/assert_received_test.rb:14:in
`teardown'
===
E
===
Error:
test_fails_if_invocation_exists_with_different_arguments(AssertReceivedTest):
  NoMethodError: undefined method `reset_instance' for Mocha::Mockery:Class
  Did you mean?  reset_mocha
/tmp/autopkgtest-lxc.ze38g2wo/downtmp/build.XBn/src/test/unit/assert_received_test.rb:14:in
`teardown'
===
E
===
Error: test_passes_if_invocation_count_correct(AssertReceivedTest):
  NoMethodError: undefined method `reset_instance' for Mocha::Mockery:Class
  Did you mean?  reset_mocha
/tmp/autopkgtest-lxc.ze38g2wo/downtmp/build.XBn/src/test/unit/assert_received_test.rb:14:in
`teardown'
===
E

Bug#906678: newmat: FTBFS in buster/sid (ld: cannot find -lnewmat)

[Adrian Bunk]

Control: tags -1 patch

On Sun, Aug 19, 2018 at 04:36:41PM +, Santiago Vila wrote:
>...
> /bin/bash ./libtool  --tag=CXX   --mode=link x86_64-linux-gnu-g++  -g -O2 
> -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
> -Werror=format-security -Wall -g  -O2 -std=gnu++98 -lnewmat -Wl,-z,relro 
> -Wl,-z,now -o example example.o  
> libtool: link: x86_64-linux-gnu-g++ -g -O2 
> -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
> -Werror=format-security -Wall -g -O2 -std=gnu++98 -Wl,-z -Wl,relro -Wl,-z 
> -Wl,now -o example example.o  -lnewmat
> /usr/bin/ld: cannot find -lnewmat
> collect2: error: ld returned 1 exit status
> make[2]: *** [Makefile:570: example] Error 1
>...

A fixed newmat-1.10.4-libtool.diff is attached.

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Author: Philippe Coval 
Date:   Sat Aug 1 00:56:03 2009 +0200
Description: ???

--- /dev/null
+++ b/configure.in
@@ -0,0 +1,35 @@
+#   -*- Autoconf -*-
+# Process this file with autoconf to produce a configure script.
+AC_PREREQ(2.59)
+AC_INIT(newmat, 1.10.2, r...@users.sf.net)
+AM_INIT_AUTOMAKE(libnewmat, 1.10.2)
+
+AC_CONFIG_SRCDIR([config.h.in])
+AC_CONFIG_HEADER([config.h])
+# AC_CONFIG_FILES([Makefile]) 
+
+AC_LANG_CPLUSPLUS
+# Checks for programs.
+AC_PROG_CXX
+AC_PROG_CC
+AC_PROG_INSTALL
+AC_PROG_LIBTOOL
+
+# Checks for libraries.
+
+# Checks for header files.
+AC_CHECK_HEADER( [ float.h , cstdlib , setjmp.h , limits ] )
+
+# Checks for typedefs, structures, and compiler characteristics.
+AC_HEADER_STDBOOL
+AC_C_CONST
+AC_C_INLINE
+AC_TYPE_SIZE_T
+AC_STRUCT_TM
+
+# Checks for library functions.
+AC_CHECK_FUNCS([floor pow sqrt])
+AC_OUTPUT( [Makefile] )
+
+
+#eof "Id: configure.in -- pcoval $"
--- /dev/null
+++ b/Makefile.am
@@ -0,0 +1,37 @@
+#ident "$Id: Makefile.am -- pcoval"
+lib_LTLIBRARIES = libnewmat.la
+
+libnewmat_la_LDFLAGS = -version-info 10:0:0
+
+libnewmat_la_SOURCES = \
+  newmat1.cpp newmat2.cpp newmat3.cpp newmat4.cpp newmat5.cpp newmat6.cpp \
+  newmat7.cpp newmat8.cpp newmatex.cpp bandmat.cpp submat.cpp myexcept.cpp \
+  cholesky.cpp evalue.cpp fft.cpp hholder.cpp jacobi.cpp newfft.cpp \
+  sort.cpp svd.cpp newmatrm.cpp newmat9.cpp
+ #
+
+pkgincludedir = $(includedir)/newmat
+
+pkginclude_HEADERS = \
+  config.h include.h \
+  boolean.h controlw.h myexcept.h newmat.h newmatnl.h newmatrm.h solution.h \
+  newmatap.h  newmatio.h  newmatrc.h  precisio.h
+ #
+
+bin_PROGRAMS = example test_exc tmt
+
+example_SOURCES = example.cpp
+example_LDADD = libnewmat.la
+
+test_exc_SOURCES = test_exc.cpp
+test_exc_LDADD = libnewmat.la
+
+
+tmt_SOURCES = tmt.cpp \
+  tmt1.cpp tmt2.cpp tmt3.cpp tmt4.cpp tmt5.cpp tmt6.cpp tmt7.cpp tmt8.cpp \
+  tmt9.cpp tmta.cpp tmtb.cpp tmtc.cpp tmtd.cpp tmte.cpp tmtf.cpp tmtg.cpp \
+  tmth.cpp tmti.cpp tmtj.cpp tmtk.cpp tmtl.cpp tmtm.cpp
+ #
+tmt_LDADD = libnewmat.la
+
+#eof "$Id: Makefile.am -- pcoval"
--- a/newmat.h
+++ b/newmat.h
@@ -560,6 +560,8 @@ public:
 
 
 
+class Matrix;
+Real DotProduct(const Matrix& A, const Matrix& B);
 class Matrix : public GeneralMatrix // usual rectangular matrix
 {
GeneralMatrix* Image() const;// copy of matrix
@@ -1207,6 +1209,12 @@ public:
NEW_DELETE(AddedMatrix)
 };
 
+class SPMatrix;
+#ifndef TEMPS_DESTROYED_QUICKLY
+   SPMatrix SP(const BaseMatrix&, const BaseMatrix&);
+#else
+   SPMatrix& SP(const BaseMatrix&, const BaseMatrix&);
+#endif
 class SPMatrix : public AddedMatrix
 {
 protected:
@@ -1230,6 +1238,12 @@ public:
NEW_DELETE(SPMatrix)
 };
 
+class KPMatrix;
+#ifndef TEMPS_DESTROYED_QUICKLY
+   KPMatrix KP(const BaseMatrix&, const BaseMatrix&);
+#else
+   KPMatrix& KP(const BaseMatrix&, const BaseMatrix&);
+#endif
 class KPMatrix : public MultipliedMatrix
 {
 protected:
@@ -1328,6 +1342,12 @@ public:
NEW_DELETE(ShiftedMatrix)
 };
 
+class NegShiftedMatrix;
+#ifndef TEMPS_DESTROYED_QUICKLY
+   NegShiftedMatrix operator-(Real, const BaseMatrix&);
+#else
+   NegShiftedMatrix& operator-(Real, const BaseMatrix&);
+#endif
 class NegShiftedMatrix : public ShiftedMatrix
 {
 protected:
--- a/tmt1.cpp
+++ b/tmt1.cpp
@@ -10,6 +10,7 @@
 #include "tmt.h"
 
 #ifdef use_namespace
+using namespace std; //#~rzr : needed for msvc
 using namespace NEWMAT;
 #endif
 
--- a/tmtm.cpp
+++ b/tmtm.cpp
@@ -8,6 +8,7 @@
 #include "tmt.h"
 
 #ifdef use_namespace
+using namespace std; //#~rzr : needed for msvc
 using namespace NEWMAT;
 #endif
 
--- a/newmatnl.cpp
+++ b/newmatnl.cpp
@@ -10,6 +10,7 @@
 #include "newmatnl.h"
 
 #ifdef use_namespace
+using namespace std; //#~rzr : needed for msvc
 namespace NEWMAT {
 #endif
 
--- a/include.h
+++ b/include.h
@@ -7,7 +7,9 @@
 #ifndef INCLUDE_LIB
 #define INCLUDE_LIB
 
-//#define use_namespace   // define name spaces

Bug#906684: cflow: missing info pages

[Boruch Baum]

Package: cflow
Version: 1:1.4+dfsg1-3
Severity: normal

Dear Maintainer,

The man page for the package indicates the existence of an info page,
and in fact the upstream tarball does include one; however, it is not
included in the debian package. (Also btw, GNU has released version 1.5
of this package, and debian is distributing version 1.4).

-- System Information:
Distributor ID: Devuan
Description:Devuan GNU/Linux 2.0.0 (ascii)
Release:2.0.0
Codename:   ascii
Architecture: x86_64

Kernel: Linux 4.14.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: sysvinit (via /sbin/init)

Versions of packages cflow depends on:
ii  libc6  2.27-5

cflow recommends no packages.

cflow suggests no packages.

-- 
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0

Bug#906659: keepassxc: FTBFS in buster/sid (invalid use of incomplete type â class QButtonGroupâ )

[Nazar Zhuk]

This is fixed upstream in 2.3.3.
Related upstream bug:
https://github.com/keepassxreboot/keepassxc/issues/2048
Upstream patch:
https://github.com/keepassxreboot/keepassxc/commit/3bbc6ac0e6298d27bfe0c41999460cafda8edf18

Bug#906683: piuparts doesn't understand the option --ignore-regexp

[Nicolas Braud-Santoni]

Package: piuparts
Version: 0.90
Severity: important

Hi,

While trying to add automated piuparts runs to my sbuild setup, I found out
that the option --ignore-regexp (documented in the manpage) isn't valid:

> $ piuparts --schroot=sid-amd64-sbuild --fail-on-broken-symlinks 
> --ignore-regexp=/opt/deb/buildarea /opt/deb/buildarea/nyx_2.0.4-6_all.deb
> Usage: piuparts [options] package ...
> 
> piuparts: error: no such option: --ignore-regexp


Best,

  nicoo

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

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

Versions of packages piuparts depends on:
ii  debootstrap  1.0.107
ii  debsums  2.2.3
ii  lsb-release  9.20170808
ii  lsof 4.89+dfsg-0.1
ii  mount2.32.1-0.1
ii  piuparts-common  0.90
ii  python   2.7.15-3
ii  python-debian0.1.32

Versions of packages piuparts recommends:
pn  adequate  

Versions of packages piuparts suggests:
pn  docker.io  
ii  schroot1.6.10-5

-- no debconf information

Bug#906622: pulseaudio: Only provides dummy output

[Felipe Sateler]

On Sat, Aug 18, 2018, 20:45 Erik de Castro Lopo  wrote:

> Erik de Castro Lopo wrote:
>
> > After a recent upgrade and then a couple of days later a reboot
> Pulseaudio
> > stopped working with the sound hardware, and only provided a single
> "Dummy output".
> > That was using pulseaudio 11.? and since 12.0 was available I upgraded
> to that, but
> > still get nothing but the "Dummy output" device.
>
> Just after I reported this I tried one more thing, I killed the
> "mate-volume-control-applet". My sound started working again immediately.
> I didn't have to reboot or logout or anything. I already had a test
> audio program running and as soon as "mate-volume-control-applet" was
> kill, the audio started coming out.
>
> Not sure if this bug should be re-assigned to mate-media or not.
>

Yes. Since pulseaudio is below mate on the stack, the mate volume app
should take care not to disrupt pulseaudio.

Could you reassign please? So that you can provide proper version
information.

Saludos

Bug#728206: ITP: librtr -- Library implementing the client-side of the RPKI-RTR Protocol.

[Lukas Schwaighofer]

Control: owner -1 debian-security-to...@lists.debian.org
Control: retitle -1 ITP: librtr -- Library implementing the client-side of the 
RPKI-RTR Protocol.

This library has been gaining more popularity recently, e.g.
https://github.com/FRRouting/frr. Packaging it will enable more
software to be easily packageable/buildable/usable from Debian.

I intend to maintain this as part of the Debian Security Tools
Packaging Team.

Bug#906682: llvmlite: FTBFS when built with dpkg-buildpackage -A

[Santiago Vila]

Package: src:llvmlite
Version: 0.24.0-1
Severity: serious
Tags: ftbfs

Dear maintainer:

I tried to build this package with dpkg-buildpackage -A but it failed:


[...]
 debian/rules build-indep
dh build-indep --with python2,python3,sphinxdoc --buildsystem=pybuild
   dh_update_autotools_config -i -O--buildsystem=pybuild
   dh_autoreconf -i -O--buildsystem=pybuild
   dh_auto_configure -i -O--buildsystem=pybuild

[... snipped ...]

   dh_link -i -O--buildsystem=pybuild
   dh_strip_nondeterminism -i -O--buildsystem=pybuild
   dh_compress -i -O--buildsystem=pybuild
   dh_fixperms -i -O--buildsystem=pybuild
   dh_missing -i -O--buildsystem=pybuild
   dh_installdeb -i -O--buildsystem=pybuild
   debian/rules override_dh_gencontrol
make[1]: Entering directory '/<>'
dh_gencontrol
dpkg-gencontrol: warning: package llvmlite-doc: unused substitution variable 
${sphinxdoc:Built-Using}
echo "Conflicts: python3-llvmlite-dbgsym" >> 
debian/.debhelper/python-llvmlite/dbgsym-root/DEBIAN/control
/bin/sh: 1: cannot create 
debian/.debhelper/python-llvmlite/dbgsym-root/DEBIAN/control: Directory 
nonexistent
make[1]: *** [debian/rules:27: override_dh_gencontrol] Error 2
make[1]: Leaving directory '/<>'
make: *** [debian/rules:8: binary-indep] Error 2
dpkg-buildpackage: error: fakeroot debian/rules binary-indep subprocess 
returned exit status 2


To reproduce, please try "dpkg-buildpackage -A".

Hint: Try splitting override_dh_gencontrol into override_dh_gencontrol-arch
and override_dh_gencontrol-indep.

Note: Please consider uploading in source-only form (dpkg-buildpackage -S)
so that this kind of bugs never propagate to testing. We would also get
official build logs for the "all" architecture here:

https://buildd.debian.org/status/package.php?p=llvmlite

Thanks.

Bug#906590: ITP: pass-otp -- A pass extension for managing one-time-password (OTP) tokens

[Philip Rinn]

Hi,

pass-otp is already packaged: https://tracker.debian.org/pkg/pass-otp

Best,
Philip



signature.asc
Description: OpenPGP digital signature

Bug#842815: Help needed for change of build system to gradle of package libsis-jhdf5-java

[olivier sallou]

Le dim. 19 août 2018 à 16:17, Bernd Rinn  a écrit :

> On 08/19/2018 04:02 PM, olivier sallou wrote:
> >
> >
> > Le dim. 19 août 2018 à 15:23, Bernd Rinn  > > a écrit :
> >
> > Hi Andreas,
> >
> > I have no idea why the classes are missing for you as they are all
> > present in our ivy-repository which we use for dependency resolution.
> > Maybe there is an issue with your gradle build environment?
> >
> >
> > In debian, all deps must be availlable as debian packages, they are not
> > downloaded from remote repos.
> > So i think 'problem' is those dependencies are not packaged in debian
> >  They should be packaged first, then added as package build dependencies.
>
> The old build procedure involved Ivy with a publicly accessible ivy
> repository, the new build procedure is self-contained. Putting this into
> Debian packages in a form compliant with Debian policies is your task at
> Debian.
>
Agree :-) just explaining what the issue is.

Olivier

>
> Bernd
>
> > Anyway, I have now simplified the build process by removing automatic
> > dependency resolution via ivy altogether. Can you please check
> whether
> > the build works for you now when you use the build procedure on HEAD?
> >
> > All the best,
> > Bernd
> >
> > On 08/16/2018 06:46 AM, Andreas Tille wrote:
> > > Hi Bernd,
> > >
> > > could you give some hints about the missing classes?
> > >
> > > On Tue, Aug 14, 2018 at 12:23:22PM +0200, olivier sallou wrote:
> > >> Le mar. 14 août 2018 à 11:32, Andreas Tille  > > a écrit :
> > >>
> > >>> A problem occurred evaluating root project 'libsis-jhdf5-java'.
> >  Could not resolve all dependencies for configuration ':runtime'.
> > >>>> Could not resolve cisd:cisd-args4j:+.
> > >>>  Required by:
> > >>>  project :
> > >>>   > No cached version listing for cisd:cisd-args4j:+
> > available for
> > >>> offline mode.
> > >>>> Could not resolve cisd:cisd-base:+.
> > >>>  Required by:
> > >>>  project :
> > >>>   > No cached version listing for cisd:cisd-base:+ available
> for
> > >>> offline mode.
> > >>>> Could not resolve rinn:restrictions:+.
> > >>>  Required by:
> > >>>  project :
> > >>>   > No cached version listing for rinn:restrictions:+
> > available for
> > >>> offline mode.
> > >>>
> > >>>
> > >> I do not see in build deps things related to:
> > >>cisd:cisd-args4, cisd:cisd-base, rinn:restrictions
> > >
> > > I have no idea what these are. :-(
> > >
> > > Kind regards
> > >
> > >   Andreas.
> > >
> > >>> [1] https://salsa.debian.org/med-team/libsis-jhdf5-java
>
>

Bug#906681: snapd: FreeCAD comes up with squares instead of text

[Andrew Atkinson]

Package: snapd
Version: 2.30-5+b1
Severity: normal

Dear Maintainer,

After installing FreeCAD the text is not readable, see attached

I have also installed this snap on Ubuntu and it works fine, so feel that this
might be a debian problem. The rest of the functionality seems to be fine,
although it is difficult to tell when no text to run the software.

When running from terminal this is the output that is given

# freecad.FreeCAD
mkdir: cannot create directory '/root/snap/freecad/4/.config': File exists
FreeCAD 0.17, Libs: 0.17R7744 (Git)
© Juergen Riegel, Werner Mayer, Yorik van Havre 2001-2015
  #   ###   
  ##  # #   #   #
  # ##     # #   #  #   #
    # # #  # #  #  # #  #   #
  # #      ## # #   #
  # #   ## ## # #   #  ##  ##  ##
  # #       ### # #    ##  ##  ##

Fontconfig warning: line 5: unknown element "its:rules"
Fontconfig warning: line 6: unknown element "its:translateRule"
Fontconfig error: line 6: invalid attribute 'translate'
Fontconfig error: line 6: invalid attribute 'selector'
Fontconfig error: line 7: invalid attribute 'xmlns:its'
Fontconfig error: line 7: invalid attribute 'version'
Fontconfig warning: line 9: unknown element "description"
Fontconfig error: Cannot load default config file

thanks

Andrew



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

Kernel: Linux 4.16.0-2-amd64 (SMP w/12 CPU cores)
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 snapd depends on:
ii  adduser  3.117
ii  apparmor 2.13-8
ii  ca-certificates  20170717
ii  gnupg2.2.9-1
ii  libapparmor1 2.13-8
ii  libc62.27-5
ii  libcap2  1:2.25-1.2
ii  libseccomp2  2.3.3-3
ii  libudev1 239-7
ii  openssh-client   1:7.7p1-3
ii  squashfs-tools   1:4.3-6
ii  systemd  239-7

snapd recommends no packages.

snapd suggests no packages.

-- no debconf information

Bug#906680: snapd: After installing a snap it need full path to run

[Andrew Atkinson]

Package: snapd
Version: 2.30-5+b1
Severity: normal

Dear Maintainer,

After installing the snap hello as a test, hello does not become a command from
the terminal.

It would appear that the path to /snap/bin is not set, so that hello can be run
with

/snap/bin/hello

or by setting the path

# hello
bash: hello: command not found
# /snap/bin/hello
Hello, world!
# export PATH=$PATH:/snap/bin/
# hello
Hello, world!

thanks

Andrew



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

Kernel: Linux 4.16.0-2-amd64 (SMP w/12 CPU cores)
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 snapd depends on:
ii  adduser  3.117
ii  apparmor 2.13-8
ii  ca-certificates  20170717
ii  gnupg2.2.9-1
ii  libapparmor1 2.13-8
ii  libc62.27-5
ii  libcap2  1:2.25-1.2
ii  libseccomp2  2.3.3-3
ii  libudev1 239-7
ii  openssh-client   1:7.7p1-3
ii  squashfs-tools   1:4.3-6
ii  systemd  239-7

snapd recommends no packages.

snapd suggests no packages.

-- no debconf information

Bug#906679: pam-p11 FTBFS on 32bit: error: comparison between signed and unsigned integer expressions

[Adrian Bunk]

Source: pam-p11
Version: 0.2.0-1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/package.php?p=pam-p11=sid

...
pam_p11.c: In function 'randomize':
pam_p11.c:556:36: error: comparison between signed and unsigned integer 
expressions [-Werror=sign-compare]
  if (0 <= fd && read(fd, r, r_len) == r_len) {
^~

Bug#906678: newmat: FTBFS in buster/sid (ld: cannot find -lnewmat)

[Santiago Vila]

Package: src:newmat
Version: 1.10.4-6
Severity: serious
Tags: ftbfs

Dear maintainer:

I tried to build this package in buster but it failed:


[...]
 debian/rules build-arch
QUILT_PATCHES=debian/patches \
quilt --quiltrc /dev/null push -a || test $? = 2
Applying patch newmat-1.10.4-msvc.diff
patching file newmat.dsp
patching file example.dsp

[... snipped ...]

touch configure-stamp
dh_testdir
/usr/bin/make
make[1]: Entering directory '/<>'
/usr/bin/make  all-am
make[2]: Entering directory '/<>'
x86_64-linux-gnu-g++ -DHAVE_CONFIG_H -I.   -Wdate-time -D_FORTIFY_SOURCE=2  -g 
-O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wall -g  -O2 -std=gnu++98 -MT example.o -MD -MP -MF 
.deps/example.Tpo -c -o example.o example.cpp
mv -f .deps/example.Tpo .deps/example.Po
/bin/bash ./libtool  --tag=CXX   --mode=link x86_64-linux-gnu-g++  -g -O2 
-fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wall -g  -O2 -std=gnu++98 -lnewmat -Wl,-z,relro 
-Wl,-z,now -o example example.o  
libtool: link: x86_64-linux-gnu-g++ -g -O2 
-fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wall -g -O2 -std=gnu++98 -Wl,-z -Wl,relro -Wl,-z 
-Wl,now -o example example.o  -lnewmat
/usr/bin/ld: cannot find -lnewmat
collect2: error: ld returned 1 exit status
make[2]: *** [Makefile:570: example] Error 1
make[2]: Leaving directory '/<>'
make[1]: *** [Makefile:428: all] Error 2
make[1]: Leaving directory '/<>'
make: *** [debian/rules:56: build-stamp] Error 2
dpkg-buildpackage: error: debian/rules build-arch subprocess returned exit 
status 2


The build was made with "dpkg-buildpackage -B" in my autobuilder.
Most probably, it also fails here in reproducible builds:

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/newmat.html

where you can get a full build log if you need it.

If this is really a bug in one of the build-depends, please use reassign and 
affects,
so that this is still visible in the BTS web page for this package.

Thanks.

Bug#893700: Backports

[Olaf van der Spek]

Hi,

I'd love to see a backport as well.

-- 
Olaf