Bug#924325: gcc-8-cross: FTBFS for unknown reasons

[Matthias Klose]

Control: severity -1 important

On 11.03.19 17:34, Santiago Vila wrote:
> Package: src:gcc-8-cross
> Version: 26
> Tags: ftbfs
> 
> Hello Matthias.
> 
> I have been unable to build this package for the last 12 months:
[...]

> The only unusual thing is that I'm using a single-CPU virtual machine
> for the build, not a desktop computer, but I fail to see why that
> would make any difference, as the only processor-related thing
> I found is this in debian/rules:
> 
> NJOBS =
> # Support parallel= in DEB_BUILD_OPTIONS (see #209008)
> ifneq (,$(filter parallel=%,$(subst $(,), ,$(DEB_BUILD_OPTIONS
>   NJOBS := -j $(subst parallel=,,$(filter parallel=%,$(subst 
> $(,),$(space),$(DEB_BUILD_OPTIONS
> endif
> 
> which I believe is pretty standard and should not affect the end result.
> 
> So: What could be the reason for the failure? A bug in one of the Makefiles?

I have no clue, I have never seen that before, and it seems to work fine on the
buildds, and in the cross-toolchain-base* package's autopkg test.  Starting here
a build with -j1 to see if it's reproducible.

Is this seen with gcc-7-cross and gcc-9-cross as well?

Bug#924332: kdialog: no man page for kdialog

[Stéphane Blondon]

Package: kdialog
Version: 4:17.08.3-2
Severity: normal

Dear Maintainer,

no man page are found with `man kdialog`:

$ LANG=C man kdialog
No manual entry for kdialog
See 'man 7 undocumented' for help when manual pages are not available.


`kdialog --help` provides the available arguments:

$ LANG=C kdialog --help
Usage: kdialog [options] [arg]
KDialog can be used to show nice dialog boxes from shell scripts

Options:
[...]


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

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

Versions of packages kdialog depends on:
ii  kio   5.54.1-1
ii  libc6 2.28-8
ii  libkf5configcore5 5.54.0-1
ii  libkf5coreaddons5 5.54.0-1
ii  libkf5dbusaddons5 5.54.0-1
ii  libkf5guiaddons5  5.54.0-1
ii  libkf5i18n5   5.54.0-1
ii  libkf5iconthemes5 5.54.0-1
ii  libkf5kiocore55.54.1-1
ii  libkf5notifications5  5.54.0-1
ii  libkf5textwidgets55.54.0-1
ii  libkf5widgetsaddons5  5.54.0-1
ii  libkf5windowsystem5   5.54.0-1
ii  libqt5core5a  5.11.3+dfsg-5
ii  libqt5dbus5   5.11.3+dfsg-5
ii  libqt5gui55.11.3+dfsg-5
ii  libqt5widgets55.11.3+dfsg-5
ii  libstdc++68.3.0-2
ii  libx11-6  2:1.6.7-1

kdialog recommends no packages.

kdialog suggests no packages.

-- no debconf information



Stéphane

Bug#924331: RFA: pdf-redact-tools -- PDF Redact Tools helps with securely redacting and stripping

[Loic Dachary]

Package: wnpp
Severity: normal

pdf-redact-tools is one of many tools journalists need to protect the anonymity 
of their sources. Despite my desire to maintain the package and my best 
efforts, I do not feel safe within Debian to do so. I kindly ask someone to 
takeover.

Cheers



signature.asc
Description: OpenPGP digital signature

Bug#924270: O: keepassx -- Cross Platform Password Manager

[Felix Geyer]

Hi,

On 11.03.19 04:29, Shengjing Zhu wrote:
> Hi,
> 
> On Mon, Mar 11, 2019 at 3:15 AM Reinhard Tartler  wrote:
>>
>> Package: wnpp
>> Severity: normal
>>
>> Keepassx is a graphical password manager, using the Qt4 toolkit. I'm no
>> longer using this package and have personally switched to
>> 'password-store'.  Unfortunately, I've also failed to get a response
>> from upstream from
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=920616 - which
>> recommends to replace keepassx with keepassxc, a community fork,
>> possibly because of unresponsive upstream.
>>
>> I am undecided whether or not this package should be included in Debian
>> 10 (aka buster). It clearly is useful to many people, but its long-term
>> maintenance is unclear.
>>
>> I'd encourage people interested in picking up this package to coordinate
>> with Julian Klode (CC'ed), the Debian keepassxc maintainer.

I've replied to you but unfortunately your mail provider / filter seems to
discard my mails.

I will continue maintaining KeePassX for the time being but likely only do
important bugfixes and other necessary changes (like the port to Qt5).

> I'm also long-time user of keepassx.
> 
> I checked the upstream. In surprise, I found the master version has
> switched to Qt-5. And the upstream author is Felix Geyer, who is DD as
> well.
> 
> Felix, could you have some inputs here?
> 
> In person, I hope keepassx is in buster. I can help uploading the
> master version(with Qt-5) if Qt-4 is really needed to be removed from
> buster. However I'm unsure if RT is fine with this big change(I assume
> it's not ok).

Qt 4 won't be removed from buster. There are still lots of packages using it
in the archive.

Switching keepassx to Qt5 this late (essentially after the freeze) seems
inappropriate to me. I don't see the release team unblocking this.

Cheers,
Felix

Bug#924330: postinst function django_config_site() broken

[Jonas Meurer]

Package: mailman3-web
Version: 0+20180916-6
Severity: important

Hello,

the postinst function django_config_site() is broken, we need to
rewrite it.

At the moment, it tries to read (and update) the default django site
domain by using `Site.objects.all()[0]`, which seems to be wrong. If at
all, then `Site.objects.last()` seems to be the default django site
domain (i.e. first one that got created), but even that one seems
error-prone.

My impression is, that there is no reliable way for us during upgrade
to determine which django site domain got created by our postinst script
earlier. Therefore I propose the following:

If we do a fresh install (i.e. "$2" is empty) *and* a django site domain
is configured via debconf, we override the default django site domain
(i.e. 'example.com') with the configured one.

If we do an upgrade *and* a django site domain is set via debconf, we
check if a django site domain with the same domain name already exists.
If that's not the case, then we add a new django site domain.

This solution occurs much more robust to me than the current
implementation.

Only downside is, that if the django site domain gets changed in
debconf at a later point, we don't override the old django site domain
but append a new one. I don't think it's a major problem though. And
given that there is no reliable way to determine *which* of the existing
django site domains got created by our postinst script before, I think
it's an acceptable tradeoff.

Cheers
 jonas

Bug#924328: Acknowledgement (android-platform-build ftbfs, using new javahelper)

[Matthias Klose]

The real issue is:

   debian/rules override_dh_auto_build-indep
make[1]: Entering directory
'/home/packages/tmp/at/d/android-platform-build-8.1.0+r23'
jh_build --javacopts="-source 7" --no-javadoc --main=com.android.signapk.SignApk
signapk.jar tools/signapk/
warning: [options] bootstrap class path not set in conjunction with -source 7
1 warning
javadoc: error - No public or protected classes found to document.
1 error
jh_build: find tools/signapk/ -name '*.java' -and -type f -print0 | xargs -s
512000 -0 /usr/lib/jvm/default-java/bin/javadoc -locale en_US -classpath
/usr/share/java/bcprov.jar:/usr/share/java/bcpkix.jar:/usr/share/java/apksig.jar:debian/_jh_build.signapk
-d debian/_jh_build.javadoc/api -quiet -source 7 -encoding ISO8859-1
-notimestamp  returned exit code 123
make[1]: *** [debian/rules:26: signapk.jar] Error 2
make[1]: Leaving directory
'/home/packages/tmp/at/d/android-platform-build-8.1.0+r23'
make: *** [debian/rules:33: build] Error 2

Bug#924329: xastir: FTBFS (magick/image-private.h: No such file or directory)

[Santiago Vila]

Package: src:xastir
Version: 2.1.0-3
Severity: serious
Tags: ftbfs

Dear maintainer:

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


[...]
 debian/rules build-arch
dh build-arch --with autoreconf
   dh_update_autotools_config -a
   dh_autoreconf -a
   dh_auto_configure -a
./configure --build=x86_64-linux-gnu --prefix=/usr 
--includedir=\${prefix}/include --mandir=\${prefix}/share/man 
--infodir=\${prefix}/share/info --sysconfdir=/etc --localstatedir=/var 
--disable-silent-rules --libdir=\${prefix}/lib/x86_64-linux-gnu 
--runstatedir=/run --disable-maintainer-mode --disable-dependency-tracking
configure: WARNING: unrecognized options: --disable-maintainer-mode
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... no
checking for mawk... mawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes

[... snipped ...]

map_gdal.c:276:30: warning: variable 'map_x_max' set but not used 
[-Wunused-but-set-variable]
 unsigned long map_x_min, map_x_max; // xastir units
  ^
map_gdal.c: In function 'Draw_OGR_Points':
map_gdal.c:1219:16: warning: variable 'xpoint' set but not used 
[-Wunused-but-set-variable]
 XPoint xpoint;
^~
map_gdal.c: In function 'setup_coord_translation':
map_gdal.c:2372:21: warning: variable 'temp' set but not used 
[-Wunused-but-set-variable]
 const char *temp;
 ^~~~
map_gdal.c: In function 'draw_ogr_map':
map_gdal.c:4835:17: warning: variable 'num' set but not used 
[-Wunused-but-set-variable]
 int num = 0;
 ^~~
map_gdal.c:2896:32: warning: variable 'ViewZ' set but not used 
[-Wunused-but-set-variable]
 double ViewX[2], ViewY[2], ViewZ[2];
^
map_gdal.c: In function 'draw_gdal_map':
map_gdal.c:469:5: warning: ignoring return value of 'GDALRasterIO', declared 
with attribute warn_unused_result [-Wunused-result]
 GDALRasterIO( hBand, GF_Read, 0, 0, nXSize, 1,
 ^~
   pafScanline, nXSize, 1, GDT_Float32,
   
   0, 0 );
   ~~
gcc -DHAVE_CONFIG_H -I. -I..   -I/usr/include/GraphicsMagick 
-I/usr/local/include -I/usr/include/geotiff -Wdate-time -D_FORTIFY_SOURCE=2 
-I/usr/include/gdal -DXASTIR_DATA_BASE=\"/usr/share/xastir\"  -fopenmp -g -O2 
-fdebug-prefix-map=/build/graphicsmagick-Mbnjgu/graphicsmagick-1.4~hg15916=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wall -pthread 
-fdebug-prefix-map=/<>=. -pipe -Wpointer-arith -Wstrict-prototypes 
-Wno-unused-parameter -c -o map_geo.o map_geo.c
In file included from /usr/include/GraphicsMagick/magick/analyze.h:18,
 from /usr/include/GraphicsMagick/magick/api.h:55,
 from map_geo.c:137:
/usr/include/GraphicsMagick/magick/image.h:1108:10: fatal error: 
magick/image-private.h: No such file or directory
 #include "magick/image-private.h"
  ^~~~
compilation terminated.
make[4]: *** [Makefile:653: map_geo.o] Error 1
make[4]: Leaving directory '/<>/src'
make[3]: *** [Makefile:670: all-recursive] Error 1
make[3]: Leaving directory '/<>/src'
make[2]: *** [Makefile:751: all-recursive] Error 1
make[2]: Leaving directory '/<>'
make[1]: *** [Makefile:433: all] Error 2
make[1]: Leaving directory '/<>'
dh_auto_build: make -j1 returned exit code 2
make: *** [debian/rules:6: build-arch] Error 2
dpkg-buildpackage: error: debian/rules build-arch subprocess returned exit 
status 2


(The above is just how the build ends and not necessarily the most relevant 
part)

The build was made in my autobuilder with "dpkg-buildpackage -B"
and it also fails here:

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/xastir.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#924325: gcc-8-cross: FTBFS for unknown reasons

[Helmut Grohne]

On Mon, Mar 11, 2019 at 04:34:35PM +, Santiago Vila wrote:
> Status: failed  gcc-8-cross_26_amd64-20190309T042203.371Z

I've looked at the log and found a more useful bit:

| ../../gnatbind -I- -nostdinc 
-I/<>/gcc/build/x86_64-linux-gnu/libgnatvsn 
-I/<>/gcc/build/gcc/ada/rts -I. -I/<>/gcc/src/gcc/ada 
-o b_gnatm.adb gnatmake.ali
| /bin/bash: ../../gnatbind: No such file or directory
| make[6]: *** [../gcc-interface/Makefile:2707: b_gnatm.adb] Error 127
| make[6]: Leaving directory '/<>/gcc/build/gcc/ada/tools'
| make[5]: *** [Makefile:205: gnattools-native] Error 2
| make[5]: Leaving directory '/<>/gcc/build/gnattools' 
| make[4]: *** [Makefile:9602: all-gnattools] Error 2
| make[4]: Leaving directory '/<>/gcc/build'
| make[3]: *** [Makefile:923: all] Error 2
| make[3]: Leaving directory '/<>/gcc/build'

This could be a missing dependency of some sorts. Matthias usually does
source-only uploads and the package builds fine on the buildds though.
Santiago has been doing a non-parallel indep-only build here. Possibly
the parallel build gets the dependency right by chance?

Helmut

Bug#921780: esajpip: FTBFS (LaTeX error)

[Santiago Vila]

On Mon, Mar 11, 2019 at 05:50:16PM +0100, Mathieu Malaterre wrote:
> Control: tags -1 wontfix
> 
> Hi,
> 
> On Sat, Feb 9, 2019 at 1:18 AM Santiago Vila  wrote:
> > !  ==> Fatal error occurred, no output PDF file produced!
> 
> I cannot also reproduce this Latex issue. Are you sure there has not
> been a broken latex package upload recently ?

Most probably a build-dependency was to blame for this one, yes, but I
don't know which one exactly. Instead of wontfix, I would try to find
the buggy build-dependency (even if it's already fixed) and use
reassign and affects, as I suggested in my initial report.

I've noticed that this bug has made the package to be autoremoved.
I'm really sorry for that. I can't always determine easily if a
package has to adapt to new requirements or a build-dependency is to
blame, as in this case.

> In any case esajpip should migrate back to testing hopefully.

I would hope so, as this was definitely not the package's fault, but I
guess you will have to ask for it explicitly because of the freeze.

Thanks and sorry again.

Bug#924328: android-platform-build ftbfs, using new javahelper

[Matthias Klose]

Package: src:android-platform-build
Version: 1:8.1.0+r23-2
Severity: serious
Tags: sid buster

dh override_dh_auto_build-arch --with javahelper
make[1]: Leaving directory
'/home/packages/tmp/at/d/android-platform-build-8.1.0+r23'
   debian/rules override_dh_auto_build-indep
make[1]: Entering directory
'/home/packages/tmp/at/d/android-platform-build-8.1.0+r23'
jh_build --javacopts="-source 7" --no-javadoc --main=com.android.signapk.SignApk
signapk.jar tools/signapk/
/bin/sh: 1: jh_build: not found
make[1]: *** [debian/rules:25: signapk.jar] Error 127
make[1]: Leaving directory
'/home/packages/tmp/at/d/android-platform-build-8.1.0+r23'
make: *** [debian/rules:31: build] Error 2
dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2

Bug#924327: directfb FTBFS for armel,armhf: error: implicit declaration of function 'makedev'

[Helmut Grohne]

Source: directfb
Version: 1.7.7-8
Severity: serious
Tags: ftbfs
User: helm...@debian.org
Usertags: rebootstrap

directfb has build failures. A cross build for armel fails:

http://crossqa.subdivi.de/build/directfb_1.7.7-8_armel_20190223000250.log
| /bin/bash ../../libtool  --tag=CC   --mode=compile arm-linux-gnueabi-gcc 
-DHAVE_CONFIG_H -I. -I../.. -I../../include -I../../lib -I../../include 
-I../../lib -I../../src -I../../systems -I./kernel-module/include  -D_REENTRANT 
-Wdate-time -D_FORTIFY_SOURCE=2  -Wall -Wstrict-prototypes -Wmissing-prototypes 
-Wno-strict-aliasing -Werror-implicit-function-declaration -O3 -g2 -ffast-math 
-pipe -g -O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong 
-Wformat -Werror=format-security -D_GNU_SOURCE  -std=gnu99 
-Werror-implicit-function-declaration -c -o davinci_c64x.lo davinci_c64x.c
| libtool: compile:  arm-linux-gnueabi-gcc -DHAVE_CONFIG_H -I. -I../.. 
-I../../include -I../../lib -I../../include -I../../lib -I../../src 
-I../../systems -I./kernel-module/include -D_REENTRANT -Wdate-time 
-D_FORTIFY_SOURCE=2 -Wall -Wstrict-prototypes -Wmissing-prototypes 
-Wno-strict-aliasing -Werror-implicit-function-declaration -O3 -g2 -ffast-math 
-pipe -g -O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong 
-Wformat -Werror=format-security -D_GNU_SOURCE -std=gnu99 
-Werror-implicit-function-declaration -c davinci_c64x.c  -fPIC -DPIC -o 
.libs/davinci_c64x.o
| davinci_c64x.c: In function 'davinci_c64x_open':
| davinci_c64x.c:1902:42: error: implicit declaration of function 'makedev' 
[-Werror=implicit-function-declaration]
|   mknod( C64X_DEVICE, 0666 | S_IFCHR, makedev( 400, 0 ) );
|   ^~~
| cc1: some warnings being treated as errors

It is very likely that this failure is a native failure as well.

A native build for armhf fails in the same way:

https://tests.reproducible-builds.org/debian/rbuild/unstable/armhf/directfb_1.7.7-8.rbuild.log.gz
| davinci_c64x.c: In function 'davinci_c64x_open':
| davinci_c64x.c:1902:42: error: implicit declaration of function 'makedev' 
[-Werror=implicit-function-declaration]
|   mknod( C64X_DEVICE, 0666 | S_IFCHR, makedev( 400, 0 ) );
|   ^~~

So directfb presently fails to build on armhf and fails to cross build
for armel in the very same way. Most likely it FTBFS on two release
architectures.

Helmut

Bug#923036: RM: alsa-tools/unstable-debug [source] -- RoQA; package in multiple components

[Chris Lamb]

Hi Adam,

> Is there any chance this could get processed, please?

Done:

Will remove the following packages from unstable-debug:

alsa-tools |1.1.7-1 | source

Maintainer: Debian ALSA Maintainers 
Will also close bugs: 923036
Will also send CCs to: alsa-to...@packages.debian.org

--- Reason ---
RoQA; package in multiple components
--

Checking reverse dependencies...
No dependency problem found.

Going to remove the packages now.
Continue (y/N)? y
Deleting... done.

> (FWIW, I did notice that removals.html appears to be slightly confused 
> and suggesting a binary-only removal for the source architecture...)

Noted, thanks. For clarity & posterity, I ran:

  % dak rm -p -d 923036 -R -C package -m "RoQA; package in multiple components" 
-s unstable-debug -S alsa-tools

… instead of the suggested:

  % dak rm -p -d 923036 -R -C package -m "RoQA; package in multiple components" 
-b -s unstable-debug -a source alsa-tools alsa-firmware-loaders-dbgsym 
alsa-tools-dbgsym alsa-tools-gui-dbgsym ld10k1-dbgsym liblo10k1-0-dbgsym


Regards,

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

Bug#921780: esajpip: FTBFS (LaTeX error)

[Mathieu Malaterre]

Control: tags -1 wontfix

Hi,

On Sat, Feb 9, 2019 at 1:18 AM Santiago Vila  wrote:
> !  ==> Fatal error occurred, no output PDF file produced!

I cannot also reproduce this Latex issue. Are you sure there has not
been a broken latex package upload recently ?

In any case esajpip should migrate back to testing hopefully.

Bug#870186: [Pkg-sass-devel] Bug#870186: Bug#870186: libsass: CVE-2017-11608

[Jonas Smedegaard]

Quoting Salvatore Bonaccorso (2019-03-11 17:14:31)
> Control: fixed -1 3.4.6-1
> 
> Hi,
> 
> On Mon, Mar 11, 2019 at 01:49:36PM +0100, Jonas Smedegaard wrote:
> > Quoting Jonas Smedegaard (2019-03-11 13:43:41)
> > > POC on Debian stretch with libsass1 3.4.3-1 and sassc 3.4.2-1:
> > > 
> > > Error: Invalid UTF-8 sequence
> > > on line 1 of /attachment.cgi?id=1303540
> > > >> "�d\
> > >-^
> > 
> > Correction: Aboce was with libsass1 3.5.5-2 and sassc 3.5.0-1.
> 
> Did you build with ASAN to verify?
> 
> The issue should be fixed with
> https://github.com/sass/libsass/commit/648f763ede97f9a2c2c843a0a18ac18bbde3507b
> which was in 3.4.6 (so indeed the issue does not affect anymore
> sid/buster which included the above commit with the 3.4.6-1 upload).

No, I simply tested with official packaged code.

I have stopped working on the other security bugs against libsass, 
because I realize I lack the needed skills. :-(


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Bug#924326: grub2: Updated Norwegian Bokmal debconf translation

[Petter Reinholdtsen]

Package: grub2
Version: 2.02+dfsg1-11
Severity: wishlist
Tags: patch, l10n

Hi

Attached is an updated Norwegian Bokmål debconf translation for grub2.
This should bring it up to 100%.  I hope it will make it into Buster.
It is one of two translations blocking nb from reaching 100% all over
d-i.  The other is eject. :)

-- 
Happy hacking
Petter Reinholdtsen
>From 2e20b2cbd2a05c31b20141e810a26a3e16ed34ed Mon Sep 17 00:00:00 2001
From: Petter Reinholdtsen 
Date: Mon, 11 Mar 2019 16:37:53 +
Subject: [PATCH] Completed nb debconf translations.

---
 debian/changelog |  3 +++
 debian/po/nb.po  | 31 +--
 2 files changed, 28 insertions(+), 6 deletions(-)

diff --git a/debian/changelog b/debian/changelog
index e9369444d..1ca0ce9fc 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -2,6 +2,9 @@ grub2 (2.02+dfsg1-13) UNRELEASED; urgency=medium
 
   * Add regexp module to signed UEFI images.
 
+  [ Debconf translations ]
+  * [nb] Norwegian Bokmål (Petter Reinholdtsen).
+
  -- Colin Watson   Mon, 04 Mar 2019 17:25:27 +
 
 grub2 (2.02+dfsg1-12) unstable; urgency=medium
diff --git a/debian/po/nb.po b/debian/po/nb.po
index e81dedb4d..68870258a 100644
--- a/debian/po/nb.po
+++ b/debian/po/nb.po
@@ -2,20 +2,21 @@
 # Copyright (C) 2010 grub2
 # This file is distributed under the same license as the grub2 package.
 # Hans Fredrik Nordhaug , 2010-12.
+# Petter Reinholdtsen , 2019.
 msgid ""
 msgstr ""
 "Project-Id-Version: grub2\n"
 "Report-Msgid-Bugs-To: gr...@packages.debian.org\n"
 "POT-Creation-Date: 2019-02-26 09:54+\n"
-"PO-Revision-Date: 2012-03-12 02:14+0200\n"
-"Last-Translator: Hans Fredrik Nordhaug \n"
-"Language-Team: Norwegian Bokmål \n"
+"PO-Revision-Date: 2019-03-11 17:35+0100\n"
+"Last-Translator: Petter Reinholdtsen \n"
+"Language-Team: NorwegianBokmal \n"
 "Language: nb\n"
 "MIME-Version: 1.0\n"
 "Content-Type: text/plain; charset=UTF-8\n"
 "Content-Transfer-Encoding: 8bit\n"
 "Plural-Forms: nplurals=2; plural=(n != 1);\n"
-"X-Generator: Virtaal 0.7.1\n"
+"X-Generator: Lokalize 2.0\n"
 
 #. Type: boolean
 #. Description
@@ -337,7 +338,7 @@ msgstr ""
 #. Description
 #: ../templates.in:3001
 msgid "Force extra installation to the EFI removable media path?"
-msgstr ""
+msgstr "Tving ekstra installasjon til EFI-stien for flyttbare media? "
 
 #. Type: boolean
 #. Description
@@ -351,12 +352,23 @@ msgid ""
 "make sure that GRUB is configured successfully to be able to boot any other "
 "OS installations correctly."
 msgstr ""
+"Noen EFI-baserte systemer har feil og feilhåndterer nye oppstartlastere. "
+"Hvis du tvinger en ekstra installasjon av GRUB til EFI-stien for flyttbare"
+" media, "
+"så  bør dette sikre at systemet vil korrekt starte opp Debian på tross av"
+" slike "
+"feil. Dette kan dog fjerne muligheten for å starte opp et annet"
+" operativsystem "
+"som også er avhengig av denne stien.  Hvis det er tilfelle, så vil du måtte"
+" sikre "
+"at GRUB lar seg sette opp korrekt for å være i stand til å starte opp andre "
+"operativsysteminstallasjoner."
 
 #. Type: boolean
 #. Description
 #: ../templates.in:4001
 msgid "Update NVRAM variables to automatically boot into Debian?"
-msgstr ""
+msgstr "Oppdatere NVRAM-variabler til å automatisk starte Debian?"
 
 #. Type: boolean
 #. Description
@@ -368,6 +380,13 @@ msgid ""
 "your NVRAM variables have been set up such that your system contacts a PXE "
 "server on every boot, this would preserve that behavior."
 msgstr ""
+"GRUB kan sette opp din platforms NVRAM-variabler slik at den automatisk "
+"starter Debian når den slås på.  Du kan dog foretrekke å koble ut denne "
+"oppførselen og hoppe over endringer i ditt oppstartoppsett.  Hvis du for"
+" eksempel "
+"har satt opp dine NVRAM-variabler slik at systemet ditt kontakter en"
+" PXE-tjener "
+"ved hver oppstart, så kan du slik beholde opprinnelig oppførsel."
 
 #. Type: string
 #. Description
-- 
2.20.1

Bug#923036: RM: alsa-tools/unstable-debug [source] -- RoQA; package in multiple components

[Adam D. Barratt]

Hi,

On 2019-02-23 10:34, Adam D. Barratt wrote:

The dsc for alsa-tools 1.1.7-1 is in both main (in the main archive)
and contrib (in the debug archive), causing the issue tracked in
#824169.

Please remove the dsc from -debug, thus resolving the issue in this
instance.


Is there any chance this could get processed, please? I've had to block 
alsa-tools's migration to testing in order to work around this instance 
of the more general dak issue.


(FWIW, I did notice that removals.html appears to be slightly confused 
and suggesting a binary-only removal for the source architecture...)


Thanks,

Adam

Bug#924325: gcc-8-cross: FTBFS for unknown reasons

[Santiago Vila]

Package: src:gcc-8-cross
Version: 26
Tags: ftbfs

Hello Matthias.

I have been unable to build this package for the last 12 months:

Status: failed  gcc-8-cross_4_amd64-20180218T093520Z
Status: failed  gcc-8-cross_5_amd64-20180224T160324Z
Status: failed  gcc-8-cross_6_amd64-20180321T020921Z
Status: failed  gcc-8-cross_7_amd64-20180328T034559Z
Status: failed  gcc-8-cross_10_amd64-20180415T171623Z
Status: failed  gcc-8-cross_10_amd64-20180606T232216Z
Status: failed  gcc-8-cross_10_amd64-20180613T100719Z
Status: failed  gcc-8-cross_17_amd64-20180614T074203Z
Status: failed  gcc-8-cross_17_amd64-20180630T065556Z
Status: failed  gcc-8-cross_17_amd64-20180710T095437Z
Status: failed  gcc-8-cross_18_amd64-20180729T173009Z
Status: failed  gcc-8-cross_20_amd64-20180820T070711Z
Status: failed  gcc-8-cross_20_amd64-20180920T075713Z
Status: failed  gcc-8-cross_21_amd64-20180924T034119Z
Status: failed  gcc-8-cross_21_amd64-20181015T100546Z
Status: failed  gcc-8-cross_22_amd64-20181105T035318Z
Status: failed  gcc-8-cross_22_amd64-20181209T162522.011Z
Status: failed  gcc-8-cross_24_amd64-20181216T102727.612Z
Status: failed  gcc-8-cross_24_amd64-20190207T101228.086Z
Status: failed  gcc-8-cross_25_amd64-20190220T042620.026Z
Status: failed  gcc-8-cross_26_amd64-20190309T042203.371Z


This is how it fails:

[...]
 debian/rules build-indep
gcc: 8.3.0-2 / 8.3.0-2cross1

old gcc version: 8.3.0-2 / 1

new gcc version: 8.3.0-2cross1
START stamp-dir/init-gcc
mkdir -p gcc
set -ex; \
cd gcc ; \
ln -sf /usr/src/gcc-8/gcc-8.3.0-dfsg.tar.xz gcc-8.3.0-dfsg.tar.xz ;\
cp -a  /usr/src/gcc-8/debian/ . ; \
if [ -n "$(grep -v '^\#' /<>/debian/patches/gcc-8/series)" ]; then 
\
  QUILT_PATCHES=/<>/debian/patches/gcc-8 quilt push --quiltrc 
/dev/null -a ; \

[... snipped ...]

#define HAVE_ICONV 1
#define ICONV_CONST 
#define HAVE_GETIPINFO 1
#define HAVE_LINUX_FUTEX 1
#define _GLIBCXX_SYMVER_GNU 1
#define _GLIBCXX_SYMVER 1
#define HAVE_AS_SYMVER_DIRECTIVE 1
#define HAVE_SYMVER_SYMBOL_RENAMING_RUNTIME_SUPPORT 1
#define _GLIBCXX_X86_RDRAND 1
#define HAVE_UNISTD_H 1
#define HAVE_SYS_TIME_H 1
#define HAVE_SYS_RESOURCE_H 1
#define HAVE_LIMIT_DATA 1
#define HAVE_LIMIT_RSS 1
#define HAVE_LIMIT_VMEM 0
#define HAVE_LIMIT_AS 1
#define HAVE_LIMIT_FSIZE 1
#define _GLIBCXX_RES_LIMITS 1
#define HAVE_SETENV 1
#define _GTHREAD_USE_MUTEX_TIMEDLOCK 1
#define _GLIBCXX_HAS_GTHREADS 1
#define _GLIBCXX_USE_PTHREAD_RWLOCK_T 1
#define HAVE_FCNTL_H 1
#define HAVE_DIRENT_H 1
#define HAVE_SYS_STATVFS_H 1
#define HAVE_UTIME_H 1
#define HAVE_STRUCT_DIRENT_D_TYPE 1
#define _GLIBCXX_USE_REALPATH 1
#define _GLIBCXX_USE_UTIMENSAT 1
#define _GLIBCXX_USE_ST_MTIM 1
#define _GLIBCXX_USE_FCHMOD 1
#define _GLIBCXX_USE_FCHMODAT 1
#define _GLIBCXX_USE_SENDFILE 1
#define _GLIBCXX_MANGLE_SIZE_T m
#define HAVE_EXCEPTION_PTR_SINCE_GCC46 1

configure: exit 0
LOGFILE END /<>/gcc/build/x86_64-linux-gnu/libstdc++-v3/config.log
make[2]: *** [debian/rules2:1221: stamps/05-build-stamp] Error 1
make[2]: Leaving directory '/<>/gcc'
make[1]: *** [debian/rules:44: build-indep] Error 2
make[1]: Leaving directory '/<>/gcc'
dpkg-buildpackage: error: debian/rules build-indep subprocess returned exit 
status 2
make: *** [debian/rules:397: stamp-dir/build-gcc.amd64] Error 2
dpkg-buildpackage: error: debian/rules build-indep subprocess returned exit 
status 2


This is just how the build ends and probably meaningless, so I've put
all my build logs here:

https://people.debian.org/~sanvila/build-logs/gcc-8-cross/

The only unusual thing is that I'm using a single-CPU virtual machine
for the build, not a desktop computer, but I fail to see why that
would make any difference, as the only processor-related thing
I found is this in debian/rules:

NJOBS =
# Support parallel= in DEB_BUILD_OPTIONS (see #209008)
ifneq (,$(filter parallel=%,$(subst $(,), ,$(DEB_BUILD_OPTIONS
  NJOBS := -j $(subst parallel=,,$(filter parallel=%,$(subst 
$(,),$(space),$(DEB_BUILD_OPTIONS
endif

which I believe is pretty standard and should not affect the end result.

So: What could be the reason for the failure? A bug in one of the Makefiles?

Thanks.

Bug#924324: libopenscap8: Push update to 1.3.0

[Brian Holaday]

Package: libopenscap8
Version: 1.2.16-2
Severity: important

Tagged Release Branch is 1.3.0:
https://github.com/OpenSCAP/openscap/releases

It does not bother me if stretch does not get updated but please can you
import over 1.3.0 into SID.

Thank you!

Bug#924323: libopenscap8 - Issue with Scanning

[Brian Holaday]

Package: libopenscap8
Version: 1.2.9-1
Severity: important

Issue:

Installing Open SCAP works just fine on Debian 9 just fine. In order to use
the tool however there are no XML Scap files installed by default to
"/usr/share/xml/scap/ssg/content/". However doing some digging I see a
package in buster for "ssg-debian" that includes this package rules. The
only issue here is that that package includes only details for Debian 8
which does not run with Debian 9 when trying to run the tool. Running this
on Fedora the tool seems to work fine even if for example a default profile
is set which means that for some reason some content under
"/usr/share/xml/scap/ssg/content/" is not being copied over correctly on
Debian.

Can we suggest a bug fix on including a standard profile for testing?

Bug#914655: python-scipy: _flapack undefined symbol: ilaver_

[Drew Parsons]

Package: python-scipy
Version: 1.1.0-4
Followup-For: Bug #914655

This bug was partially fixed in python-scipy 0.19.1-2 when
determination of the location of atlas and openblas was fixed.
 
ilaver_ is found in libopenblas.so.0.  
_flapack.x86_64-linux-gnu.so now has NEEDED libopenblas.so.0

But python-scipy Depends: libblas3 | libblas.so.3.
That is as it should be: the dependency should be on the generic blas,
enabling local systems to choose their preferred blas, whether
OpenBLAS, ATLAS or other.

But in that cases the shared library should NEED libblas.so.3, not
libopenblas.so.0.

So there is still some work to do for this bug.



-- 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.19.0-3-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_AU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages python-scipy depends on:
ii  libc6 2.28-8
ii  libgcc1   1:8.3.0-2
ii  libgfortran5  8.3.0-2
ii  libopenblas-base  0.3.5+ds-2
ii  libquadmath0  8.3.0-2
ii  libstdc++68.3.0-2
ii  python2.7.16-1
ii  python-decorator  4.3.0-1.1
ii  python-numpy [python-numpy-abi9]  1:1.16.2-1

Versions of packages python-scipy recommends:
ii  g++   4:8.3.0-1
ii  g++-7 [c++-compiler]  7.4.0-6
ii  g++-8 [c++-compiler]  8.3.0-2
ii  python-dev2.7.16-1
ii  python-pil5.4.1-1

Versions of packages python-scipy suggests:
ii  python-scipy-doc  1.1.0-4

-- no debconf information

Bug#922783: daemontools-run: installation in docker catches job control signal

[Gerrit Pape]

On Fri, Feb 22, 2019 at 04:30:05PM +0100, Florian Lohoff wrote:
> Hi,
> i would propose a patch like this - Usage of telinit shameless stolen
> from glibc which calls telinit like this to restart init.
> 
> Otherwise we would need to check for the existance and executability
> of telinit (Which might be missing in container environments)

Hi Florian, thanks for the patch.

When reading your report I  toed recall the reason why I chose to signal
pid 1 back then, but even after reading history I failed to find out
why.  It might be a good idea to look at similar packages that hook into
sysv's inittab to see what they are doing.  runit may be a candidate.

Regards, Gerrit.

Bug#870186: libsass: CVE-2017-11608

[Salvatore Bonaccorso]

Contol: tags -1 - unreproducible

Hi,

Actually running under valgrind shows the invalid read of size 1 under
stretch. But the issue is fixed in the sid version already.

Regards,
Salvatore


valgrind.log.xz
Description: application/xz

Bug#823664: still persist

[Matus UHLAR - fantomas]

Hello,

the problem still exists. example with --format report:

*** Available security updates

CVE-2017-0786 A elevation of privilege vulnerability in the...
 
 - linux-libc-dev, linux-image-4.9.0-8-686-pae
   (remotely exploitable, medium urgency)


with --format detail:

CVE-2017-0786 (fixed, remotely exploitable, medium urgency)
 A elevation of privilege vulnerability in the Broadcom wi-fi driver. ...
 installed: linux-libc-dev 4.9.144-3.1
(built from linux 4.9.144-3.1)
[...]
 fixed on branch:   linux 4.9.110-3+deb9u6 (source package)
 fixed on branch:   linux 4.9.130-1 (source package)
 fixed on branch:   linux 4.9.135-1 (source package)
 fixed on branch:   linux 4.9.144-1 (source package)
 fixed on branch:   linux 4.9.144-3 (source package)
[...]


% apt-cache policy linux-libc-dev
linux-libc-dev:
 Installed: 4.9.144-3.1
 Candidate: 4.9.144-3.1
 Version table:
*** 4.9.144-3.1 500
   500 file:/mount/mirrors/debian stretch-updates/main i386 Packages
   100 /var/lib/dpkg/status
4.9.144-3 500
   500 file:/mount/mirrors/debian stretch/main i386 Packages
4.9.110-3+deb9u6 500
   500 http://security.debian.org/debian-security stretch/updates/main i386 
Packages

according to dpkg log, the exact fixed version was installed for 6 days
before it started complaining (I run debsecan from cron)

2019-02-16 19:43:54 upgrade linux-libc-dev:i386 4.9.130-2 4.9.144-3
2019-02-16 19:43:54 status half-configured linux-libc-dev:i386 4.9.130-2
2019-02-16 19:43:54 status unpacked linux-libc-dev:i386 4.9.130-2
2019-02-16 19:43:54 status half-installed linux-libc-dev:i386 4.9.130-2
2019-02-16 19:43:55 status half-installed linux-libc-dev:i386 4.9.130-2
2019-02-16 19:43:55 status unpacked linux-libc-dev:i386 4.9.144-3
2019-02-16 19:43:55 status unpacked linux-libc-dev:i386 4.9.144-3
2019-02-16 19:44:27 configure linux-libc-dev:i386 4.9.144-3 
2019-02-16 19:44:27 status unpacked linux-libc-dev:i386 4.9.144-3
2019-02-16 19:44:27 status half-configured linux-libc-dev:i386 4.9.144-3
2019-02-16 19:44:27 status installed linux-libc-dev:i386 4.9.144-3
2019-02-22 14:40:30 upgrade linux-libc-dev:i386 4.9.144-3 4.9.144-3.1
2019-02-22 14:40:30 status half-configured linux-libc-dev:i386 4.9.144-3
2019-02-22 14:40:30 status unpacked linux-libc-dev:i386 4.9.144-3
2019-02-22 14:40:30 status half-installed linux-libc-dev:i386 4.9.144-3
2019-02-22 14:40:30 status half-installed linux-libc-dev:i386 4.9.144-3
2019-02-22 14:40:31 status unpacked linux-libc-dev:i386 4.9.144-3.1
2019-02-22 14:40:31 status unpacked linux-libc-dev:i386 4.9.144-3.1
2019-02-22 14:40:32 configure linux-libc-dev:i386 4.9.144-3.1 
2019-02-22 14:40:32 status unpacked linux-libc-dev:i386 4.9.144-3.1
2019-02-22 14:40:32 status half-configured linux-libc-dev:i386 4.9.144-3.1
2019-02-22 14:40:32 status installed linux-libc-dev:i386 4.9.144-3.1



--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Posli tento mail 100 svojim znamim - nech vidia aky si idiot
Send this email to 100 your friends - let them see what an idiot you are

Bug#870186: [Pkg-sass-devel] Bug#870186: libsass: CVE-2017-11608

[Salvatore Bonaccorso]

Control: fixed -1 3.4.6-1

Hi,

On Mon, Mar 11, 2019 at 01:49:36PM +0100, Jonas Smedegaard wrote:
> Quoting Jonas Smedegaard (2019-03-11 13:43:41)
> > POC on Debian stretch with libsass1 3.4.3-1 and sassc 3.4.2-1:
> > 
> > Error: Invalid UTF-8 sequence
> > on line 1 of /attachment.cgi?id=1303540
> > >> "�d\
> >-^
> 
> Correction: Aboce was with libsass1 3.5.5-2 and sassc 3.5.0-1.

Did you build with ASAN to verify?

The issue should be fixed with
https://github.com/sass/libsass/commit/648f763ede97f9a2c2c843a0a18ac18bbde3507b
which was in 3.4.6 (so indeed the issue does not affect anymore
sid/buster which included the above commit with the 3.4.6-1 upload).

Regards,
Salvatore

Bug#920906: pmix: Invalid Vcs-(Browser|Git) URIs?

[Drew Parsons]

Source: pmix
Followup-For: Bug #920906

Vcs-Browser browser works successfully, at least firefox can process
it. But it could be updated to https://salsa.debian.org/science-team/pmix
The intermediate colon in the Vcs tag is wrong I think.

Vcs-Git fails to clone properly, but differently to Salvatore: 
  $ git clone https://salsa.debian.org:/science-team/pmix.git
  Cloning into 'pmix'...
  remote: Enumerating objects: 3262, done.
  remote: Counting objects: 100% (3262/3262), done.
  remote: Compressing objects: 100% (1512/1512), done.
  remote: Total 3262 (delta 2253), reused 2702 (delta 1723)
  Receiving objects: 100% (3262/3262), 2.73 MiB | 248.00 KiB/s, done.
  Resolving deltas: 100% (2253/2253), done.
  warning: remote HEAD refers to nonexistent ref, unable to checkout.

The path given by salsa is
https://salsa.debian.org/science-team/pmix.git but it gives the same
error.  .git is there, but it's otherwise empty. It refuses to
checkout master, but will checkout remotes/origin/debian/master as a
detached branch.  There's something messed up in the salsa pmix repo,
it's not configuring remotes/origin/debian/master as the master
branch.

Curiously, the upstream branch checks out fine.


-- 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.19.0-3-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_AU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#915298: Thank you and +1

[Michael Vogt]

Hi Axel,

thanks for the NMU diff - the proposed patch looks good.

Cheers,
 Michael

Bug#924302: virtualbox: ignores parallel=n setting in DEB_BUILD_OPTIONS

[Gianfranco Costamagna]

 control: tags -1 pending
committed on git, but I don't think I'll upload to unstable just because of 
this...
thanks!
G.

Il lunedì 11 marzo 2019, 10:30:14 CET, Andreas Beckmann  
ha scritto:  
 
 Source: virtualbox
Version: 6.0.4-dfsg-7
Severity: important

Hi,

virtualbox seems to ignore DEB_BUILD_OPTIONS=parallel=3
I just noticed it compiling 8 files in parallel - not a good idea if
multiple different builds are supposed to be running in parallel.
(nproc reports 8 cpus on that machine)


Andreas

  

Bug#924018: RM: python3.6 -- superseded by python3.7

[Mattia Rizzolo]

Control: tag -1 moreinfo
Control: block -1 by 916820 918427
Control: severity 918427 serious

> Please remove python3.6 from unstable.

This needs some more work.

Ingoring the hurd+kbsd-only binaries, and the broken python-escript and
ovito, it leaves us with 3 bugs that I've now marked as blockers.
dak also complains about src:poezio, but I can't understand what's wrong
with it.

Checking reverse dependencies...
# Broken Depends:
ecflow: python3-ecflow [kfreebsd-amd64 kfreebsd-i386]
gdb: gdb [hurd-i386]
 gdb-multiarch [hurd-i386]
glom: glom [kfreebsd-amd64 kfreebsd-i386]
  libglom-1.30-0 [kfreebsd-amd64 kfreebsd-i386]
libixion: python3-ixion [hurd-i386]
libkolabxml: python3-kolabformat [kfreebsd-amd64 kfreebsd-i386]
libpeas: libpeas-1.0-0 [kfreebsd-amd64 kfreebsd-i386]
libxml2: python3-libxml2 [kfreebsd-amd64 kfreebsd-i386]
 python3-libxml2-dbg [kfreebsd-amd64 kfreebsd-i386]
ovito: ovito [amd64 arm64 i386 mips mips64el mipsel ppc64el s390x]
plplot: python3-plplot [hurd-i386 kfreebsd-amd64 kfreebsd-i386]
python3-plplot-qt [hurd-i386 kfreebsd-amd64 kfreebsd-i386]
poezio: poezio
prospector: prospector
pyotherside: pyotherside-tests [kfreebsd-i386]
pyqt5: python3-pyqt5 [kfreebsd-amd64 kfreebsd-i386]
   python3-pyqt5.qtquick [kfreebsd-amd64 kfreebsd-i386]
pyside: libpyside-py3-1.2 [hurd-i386 kfreebsd-amd64 kfreebsd-i386]
python3-pyside.phonon [hurd-i386 kfreebsd-amd64 kfreebsd-i386]
python3-pyside.qtcore [hurd-i386 kfreebsd-amd64 kfreebsd-i386]
python3-pyside.qtdeclarative [hurd-i386 kfreebsd-amd64 kfreebsd-i386]
python3-pyside.qtgui [hurd-i386 kfreebsd-amd64 kfreebsd-i386]
python3-pyside.qthelp [hurd-i386 kfreebsd-amd64 kfreebsd-i386]
python3-pyside.qtnetwork [hurd-i386 kfreebsd-amd64 kfreebsd-i386]
python3-pyside.qtopengl [hurd-i386 kfreebsd-amd64 kfreebsd-i386]
python3-pyside.qtscript [hurd-i386 kfreebsd-amd64 kfreebsd-i386]
python3-pyside.qtsql [hurd-i386 kfreebsd-amd64 kfreebsd-i386]
python3-pyside.qtsvg [hurd-i386 kfreebsd-amd64 kfreebsd-i386]
python3-pyside.qttest [hurd-i386 kfreebsd-amd64 kfreebsd-i386]
python3-pyside.qtuitools [hurd-i386 kfreebsd-amd64 kfreebsd-i386]
python3-pyside.qtwebkit [hurd-i386 kfreebsd-amd64 kfreebsd-i386]
python3-pyside.qtxml [hurd-i386 kfreebsd-amd64 kfreebsd-i386]
python-escript: python3-escript [armhf hurd-i386 kfreebsd-amd64 kfreebsd-i386 
mips mips64el mipsel]
python3-escript-mpi [armhf mips mips64el mipsel]
python-numpy: python3-numpy [kfreebsd-amd64 kfreebsd-i386]
pythonqt: libpythonqt-qt5-python3-3 [kfreebsd-amd64 kfreebsd-i386]
  libpythonqt-qtall-qt5-python3-3 [kfreebsd-amd64 kfreebsd-i386]
ros-image-common: python3-camera-calibration-parsers [kfreebsd-amd64]
ros-ros-comm: python3-roslz4 [kfreebsd-amd64 kfreebsd-i386]
uwsgi: uwsgi-plugin-python3 [kfreebsd-amd64 kfreebsd-i386]
vim: vim-athena [kfreebsd-amd64 kfreebsd-i386]
 vim-gtk [kfreebsd-amd64 kfreebsd-i386]
 vim-gtk3 [kfreebsd-amd64 kfreebsd-i386]
 vim-nox [kfreebsd-amd64 kfreebsd-i386]
vitrage: python3-vitrage
wxpython4.0: python3-wxgtk-media4.0 [kfreebsd-amd64 kfreebsd-i386]
 python3-wxgtk-webview4.0 [kfreebsd-amd64 kfreebsd-i386]
 python3-wxgtk4.0 [kfreebsd-amd64 kfreebsd-i386]
zeroc-ice: python3-zeroc-ice [kfreebsd-amd64 kfreebsd-i386]

# Broken Build-Depends:
kytos-utils: python3.6
python-openflow: python3.6

Dependency problem found.


-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#924322: python3-vitrage: please drop dependency on py3.6

[Mattia Rizzolo]

Package: python3-vitrage
Version: 3.2.0-1
Severity: serious
Control: block 924018 by -1

Dear maintainer,

somehow this got this far without a bug, but apparently your package
python3-vitrage has a dependency on python3.6:any.

Please use dh-python to change whatever shebang you have to use
/usr/bin/python3 and so generate a dependency on python3:any only.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#850425: mpt3sas "swiotlb buffer is full" problem only under Xen

[Boris Ostrovsky]

On 3/11/19 2:34 AM, Juergen Gross wrote:
>
> I'm not sure. Patch 3 of this series is basically already there (see
> commit c6d4381220a0087ce19dbf6984d92c451bd6b364). So maybe all we need
> is patch 4, which should really be easy to do?


FWIW to me this also seems to be the only missing part.

-boris

Bug#924321: python-openflow: please stop buildd-depending on py3.6

[Mattia Rizzolo]

Source: python-openflow
Version: 
Severity: serious
Control: block 924018 by -1

Dear maintainer,

your package block the removal python 3.6.

Please stop build-depending on it, and in general please always prefer
to build-depend only on the unversioned python variants (which you
already do, mostly interestingly…).

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#915298: [NMU] Re: Bug#915298: gdebi FTBFS with pyflakes 2.0.0-1

[Axel Beckert]

Control: tag -1 + patch

Hi,

Andrey Rahmatullin wrote:
> ./gdebi-kde:92: local variable 'e' is assigned to but never used
> ./gdebi-gtk:80: local variable 'e' is assigned to but never used
> ./GDebi/KDEAptDialogs.py:147: local variable 'e' is assigned to but never used
> ./GDebi/GDebiKDE.py:363: local variable 'msg' is assigned to but never used
> ./GDebi/GDebiGtk.py:69: local variable 'e' is assigned to but never used
> gdebi-gtk:80: local variable 'e' is assigned to but never used
> gdebi-kde:92: local variable 'e' is assigned to but never used
> 
> I don't think aborting on non-empty pyflakes output, just like compiling
> with -Werror, should be a part of a Debian package build.

I agree, especially in this case of a rather pedantic warning.

I've prepared an NMU which fixes this issue by moving the according
test to a new subdirectory called release_tests (as that is what the
test is) so that it is still available, but not run at build time.

I intent to do an NMU later today.

Here's the debdiff (native package, hence no quilt patches):

diff -Nru gdebi-0.9.5.7+nmu2/debian/changelog 
gdebi-0.9.5.7+nmu3/debian/changelog
--- gdebi-0.9.5.7+nmu2/debian/changelog 2017-12-31 17:00:13.0 +0100
+++ gdebi-0.9.5.7+nmu3/debian/changelog 2019-03-11 16:17:10.0 +0100
@@ -1,3 +1,12 @@
+gdebi (0.9.5.7+nmu3) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Move tests/test_pyflakes.py to new directory release_tests which is no
+more run at build time. (Closes: #915298)
++ Drop build-dependencies on pyflakes and pyflakes3.
+
+ -- Axel Beckert   Mon, 11 Mar 2019 16:17:10 +0100
+
 gdebi (0.9.5.7+nmu2) unstable; urgency=medium
 
   [ Julien Lavergne ]
diff -Nru gdebi-0.9.5.7+nmu2/debian/control gdebi-0.9.5.7+nmu3/debian/control
--- gdebi-0.9.5.7+nmu2/debian/control   2017-12-31 16:55:07.0 +0100
+++ gdebi-0.9.5.7+nmu3/debian/control   2019-03-11 16:17:10.0 +0100
@@ -15,8 +15,6 @@
intltool,
xvfb,
xauth,
-   pyflakes,
-   pyflakes3,
lintian,
 X-Python3-Version: >= 3.3
 Standards-Version: 3.9.6
diff -Nru gdebi-0.9.5.7+nmu2/release_tests/test_pyflakes.py 
gdebi-0.9.5.7+nmu3/release_tests/test_pyflakes.py
--- gdebi-0.9.5.7+nmu2/release_tests/test_pyflakes.py   1970-01-01 
01:00:00.0 +0100
+++ gdebi-0.9.5.7+nmu3/release_tests/test_pyflakes.py   2014-04-14 
09:16:37.0 +0200
@@ -0,0 +1,24 @@
+import os
+import subprocess
+import unittest
+
+class TestPyflakesClean(unittest.TestCase):
+""" ensure that the tree is pyflakes clean """
+
+def setUp(self):
+self.paths = [
+os.path.join(os.path.dirname(__file__), ".."),
+os.path.join(os.path.dirname(__file__), "..", "gdebi"),
+os.path.join(os.path.dirname(__file__), "..", "gdebi-gtk"),
+os.path.join(os.path.dirname(__file__), "..", "gdebi-kde"),
+]
+
+def test_pyflakes_clean(self):
+self.assertEqual(subprocess.check_call(['pyflakes'] + self.paths), 0)
+
+def test_pyflakes3_clean(self):
+self.assertEqual(subprocess.check_call(['pyflakes3'] +  self.paths), 0)
+
+
+if __name__ == "__main__":
+unittest.main()
diff -Nru gdebi-0.9.5.7+nmu2/tests/test_pyflakes.py 
gdebi-0.9.5.7+nmu3/tests/test_pyflakes.py
--- gdebi-0.9.5.7+nmu2/tests/test_pyflakes.py   2014-04-14 09:16:37.0 
+0200
+++ gdebi-0.9.5.7+nmu3/tests/test_pyflakes.py   1970-01-01 01:00:00.0 
+0100
@@ -1,24 +0,0 @@
-import os
-import subprocess
-import unittest
-
-class TestPyflakesClean(unittest.TestCase):
-""" ensure that the tree is pyflakes clean """
-
-def setUp(self):
-self.paths = [
-os.path.join(os.path.dirname(__file__), ".."),
-os.path.join(os.path.dirname(__file__), "..", "gdebi"),
-os.path.join(os.path.dirname(__file__), "..", "gdebi-gtk"),
-os.path.join(os.path.dirname(__file__), "..", "gdebi-kde"),
-]
-
-def test_pyflakes_clean(self):
-self.assertEqual(subprocess.check_call(['pyflakes'] + self.paths), 0)
-
-def test_pyflakes3_clean(self):
-self.assertEqual(subprocess.check_call(['pyflakes3'] +  self.paths), 0)
-
-
-if __name__ == "__main__":
-unittest.main()

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


signature.asc
Description: Digital signature

Bug#924320: unblock: dehydrated/0.6.2-2

[Mattia Rizzolo]

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

Dear RT,

please consider unblocking this revision of dehydrated.
I cherry-picked a few patches from upstream, fixing bugs in a few corner
cases, plus doc updates.

Full debdiff attached.

unblock dehydrated/0.6.2-2

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-
diffstat for dehydrated-0.6.2 dehydrated-0.6.2

 changelog   |   14 +++
 control |2 
 patches/Fixes-559-when-HTTP-2-is-used-header-names-are-lower-case.patch |   34 +++
 patches/Only-match-Replace-Nonce-header-at-beginning-of-line.patch  |   24 +
 patches/document-DOMAINS_D-parameter-in-example-config-fixes-575-.patch |   25 +
 patches/fixed-a-bug-that-resulted-in-a-deleted-domains.txt-when-u.patch |   22 +
 patches/implement-POST-as-GET-closes-626.patch  |   43 ++
 patches/series  |6 +
 patches/tiny-documentation-fix-per-certificate-config-can-overrid.patch |   21 
 9 files changed, 190 insertions(+), 1 deletion(-)

diff -Nru dehydrated-0.6.2/debian/changelog dehydrated-0.6.2/debian/changelog
--- dehydrated-0.6.2/debian/changelog	2018-05-08 12:14:45.0 +0200
+++ dehydrated-0.6.2/debian/changelog	2019-03-11 16:25:53.0 +0100
@@ -1,3 +1,17 @@
+dehydrated (0.6.2-2) unstable; urgency=medium
+
+  * Add a number of patches from upstream.
+Fixing the following bugs:
+ + HTTP/2 support, where header names are lowercase
+ + Avoid over matching, checking for the Replay-Nonce header only at BOL
+ + A bug causing deletion of domains.txt when incorrect parameters are used
+ + Document the DOMAINS_D config option
+ + Impoent POST-as-GET, for the upcoming change in LE's API
+ + Document PRIVATE_KEY_ROLLOVER per-cert config option
+  * d/control: bump Standards-Version to 4.3.0, no changes needed.
+
+ -- Mattia Rizzolo   Mon, 11 Mar 2019 16:25:53 +0100
+
 dehydrated (0.6.2-1) unstable; urgency=medium
 
   * New upstream release 0.6.2.
diff -Nru dehydrated-0.6.2/debian/control dehydrated-0.6.2/debian/control
--- dehydrated-0.6.2/debian/control	2018-05-08 12:10:08.0 +0200
+++ dehydrated-0.6.2/debian/control	2019-03-11 16:25:53.0 +0100
@@ -10,7 +10,7 @@
  debhelper (>= 11),
  dh-apache2,
  dh-exec,
-Standards-Version: 4.1.4
+Standards-Version: 4.3.0
 Rules-Requires-Root: no
 Vcs-Git: https://salsa.debian.org/letsencrypt-team/dehydrated.git
 Vcs-Browser: https://salsa.debian.org/letsencrypt-team/dehydrated
diff -Nru dehydrated-0.6.2/debian/patches/document-DOMAINS_D-parameter-in-example-config-fixes-575-.patch dehydrated-0.6.2/debian/patches/document-DOMAINS_D-parameter-in-example-config-fixes-575-.patch
--- dehydrated-0.6.2/debian/patches/document-DOMAINS_D-parameter-in-example-config-fixes-575-.patch	1970-01-01 01:00:00.0 +0100
+++ dehydrated-0.6.2/debian/patches/document-DOMAINS_D-parameter-in-example-config-fixes-575-.patch	2019-03-11 16:21:33.0 +0100
@@ -0,0 +1,25 @@
+From: Lukas Schauer 
+Date: Sat, 20 Oct 2018 13:05:20 +0200
+Subject: document DOMAINS_D parameter in example config (fixes #575,
+ closes #582)
+
+---
+ docs/examples/config | 5 +
+ 1 file changed, 5 insertions(+)
+
+diff --git a/docs/examples/config b/docs/examples/config
+index 665704d..c1f9276 100644
+--- a/docs/examples/config
 b/docs/examples/config
+@@ -40,6 +40,11 @@
+ # default: 
+ #CONFIG_D=
+ 
++# Directory for per-domain configuration files.
++# If not set, per-domain configurations are sourced from each certificates output directory.
++# default: 
++#DOMAINS_D=
++
+ # Base directory for account key, generated certificates and list of domains (default: $SCRIPTDIR -- uses config directory if undefined)
+ #BASEDIR=$SCRIPTDIR
+ 
diff -Nru dehydrated-0.6.2/debian/patches/fixed-a-bug-that-resulted-in-a-deleted-domains.txt-when-u.patch dehydrated-0.6.2/debian/patches/fixed-a-bug-that-resulted-in-a-deleted-domains.txt-when-u.patch
--- dehydrated-0.6.2/debian/patches/fixed-a-bug-that-resulted-in-a-deleted-domains.txt-when-u.patch	1970-01-01 01:00:00.0 +0100
+++ dehydrated-0.6.2/debian/patches/fixed-a-bug-that-resulted-in-a-deleted-domains.txt-when-u.patch	2019-03-11 16:21:33.0 +0100
@@ -0,0 +1,22 @@
+From: Lukas Schauer 
+Date: Sat, 20 Oct 2018 12:27:23 +0200
+Subject: fixed a bug that resulted in a deleted domains.txt when using
+ incorrect parameters in combination with signcsr (fixes #597)
+
+---
+ dehydrated | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git 

Bug#924319: remmina: SSH plugin not working if public key is not supplied

[Antenore Gatta]

Package: remmina
Version: 1.3.3+dfsg-1
Severity: important
Justification: Remmina SSH unusable when a public key is not provided.

Dear Maintainer,

Since remmina 1.3.3 we have introduced a quite important bug that makes
Remmina unusable when the user doesn't have a public key.

In the SSH plugin, when an SSH private key is used as the
authentication method, Remmina expect a public key with the same name
and a .pub extension.

The enclosed patch, applied and tested in the Remmina upstream master
branch, fix the issue.

Do you mind applying it as it's blocking for many users?

Thanks in advance

Antenore Gatta

diff --git a/src/remmina_sftp_client.c b/src/remmina_sftp_client.c
index 0f43f2b3..3540e1c1 100644
--- a/src/remmina_sftp_client.c
+++ b/src/remmina_sftp_client.c
@@ -507,7 +507,7 @@ remmina_sftp_client_thread_main(gpointer data)
 		if (!sftp) {
 			sftp = remmina_sftp_new_from_ssh(REMMINA_SSH(client->sftp));
 			if (!remmina_ssh_init_session(REMMINA_SSH(sftp)) ||
-			remmina_ssh_auth(REMMINA_SSH(sftp), NULL) <= 0 ||
+			remmina_ssh_auth(REMMINA_SSH(sftp), NULL, NULL, NULL) <= 0 ||
 			!remmina_sftp_open(sftp)) {
 remmina_sftp_client_thread_set_error(client, task, (REMMINA_SSH(sftp))->error);
 remmina_ftp_task_free(task);
@@ -980,7 +980,7 @@ remmina_sftp_client_new_init(RemminaSFTP *sftp)
 	gdk_display_flush(display);
 
 	if (!remmina_ssh_init_session(REMMINA_SSH(sftp)) ||
-	remmina_ssh_auth(REMMINA_SSH(sftp), NULL) <= 0 ||
+	remmina_ssh_auth(REMMINA_SSH(sftp), NULL, NULL, NULL) <= 0 ||
 	!remmina_sftp_open(sftp)) {
 		dialog = gtk_message_dialog_new(GTK_WINDOW(gtk_widget_get_toplevel(client)),
 			GTK_DIALOG_MODAL, GTK_MESSAGE_ERROR, GTK_BUTTONS_OK,
diff --git a/src/remmina_sftp_plugin.c b/src/remmina_sftp_plugin.c
index af55c4cf..08994ac1 100644
--- a/src/remmina_sftp_plugin.c
+++ b/src/remmina_sftp_plugin.c
@@ -135,7 +135,7 @@ remmina_plugin_sftp_main_thread(gpointer data)
 		/* Create SFTP connection based on existing SSH session */
 		sftp = remmina_sftp_new_from_ssh(ssh);
 		if (remmina_ssh_init_session(REMMINA_SSH(sftp)) &&
-		remmina_ssh_auth(REMMINA_SSH(sftp), NULL) > 0 &&
+		remmina_ssh_auth(REMMINA_SSH(sftp), NULL, gp, remminafile) > 0 &&
 		remmina_sftp_open(sftp)) {
 			cont = TRUE;
 		}
diff --git a/src/remmina_ssh.c b/src/remmina_ssh.c
index 9e6ba2a8..851d4446 100644
--- a/src/remmina_ssh.c
+++ b/src/remmina_ssh.c
@@ -229,13 +229,16 @@ remmina_ssh_auth_pubkey(RemminaSSH *ssh)
 
 	g_snprintf (pubkey, sizeof(pubkey), "%s.pub", ssh->privkeyfile);
 
-	ret = ssh_pki_import_pubkey_file( pubkey, );
-	if (ret != SSH_OK) {
-		remmina_ssh_set_error(ssh, _("SSH public key cannot be imported: %s"));
-		return 0;
+	/*G_FILE_TEST_EXISTS*/
+	if (g_file_test(pubkey, G_FILE_TEST_EXISTS)) {
+		ret = ssh_pki_import_pubkey_file(pubkey, );
+		if (ret != SSH_OK) {
+			remmina_ssh_set_error(ssh, _("SSH public key cannot be imported: %s"));
+			return 0;
+		}
+		ssh_key_free(key);
 	}
 
-	ssh_key_free(key);
 
 	if ( ssh_pki_import_privkey_file( ssh->privkeyfile, (ssh->passphrase ? ssh->passphrase : ""),
 		NULL, NULL,  ) != SSH_OK ) {
@@ -258,10 +261,33 @@ remmina_ssh_auth_pubkey(RemminaSSH *ssh)
 }
 
 static gint
-remmina_ssh_auth_auto_pubkey(RemminaSSH* ssh)
+remmina_ssh_auth_auto_pubkey(RemminaSSH *ssh, RemminaProtocolWidget *gp, RemminaFile *remminafile)
 {
 	TRACE_CALL(__func__);
-	gint ret = ssh_userauth_publickey_auto(ssh->session, NULL, ssh->passphrase);
+
+	gboolean disablepasswordstoring;
+	gboolean save_password;
+	gchar *pwd;
+	gchar *pwdtype = "ssh_passphrase";
+	gint ret;
+
+	if (!ssh->passphrase) {
+		disablepasswordstoring = remmina_file_get_int(remminafile, "disablepasswordstoring", FALSE);
+		ret = remmina_protocol_widget_panel_authpwd(gp, REMMINA_AUTHPWD_TYPE_SSH_PRIVKEY, !disablepasswordstoring);
+		save_password = remmina_protocol_widget_get_savepassword(gp);
+
+		if (ret == GTK_RESPONSE_OK) {
+			if (save_password) {
+pwd = remmina_protocol_widget_get_password(gp);
+remmina_file_set_string(remminafile, pwdtype, pwd);
+g_free(pwd);
+			}
+		} else {
+			return -1;
+		}
+		ssh->passphrase = remmina_protocol_widget_get_password(gp);
+	}
+	ret = ssh_userauth_publickey_auto(ssh->session, NULL, ssh->passphrase);
 
 	if (ret != SSH_AUTH_SUCCESS) {
 		remmina_ssh_set_error(ssh, _("SSH automatic public key authentication failed: %s"));
@@ -308,7 +334,7 @@ remmina_ssh_auth_gssapi(RemminaSSH *ssh)
 }
 
 gint
-remmina_ssh_auth(RemminaSSH *ssh, const gchar *password)
+remmina_ssh_auth(RemminaSSH *ssh, const gchar *password, RemminaProtocolWidget *gp, RemminaFile *remminafile)
 {
 	TRACE_CALL(__func__);
 	gint method;
@@ -359,7 +385,7 @@ remmina_ssh_auth(RemminaSSH *ssh, const gchar *password)
 
 	case SSH_AUTH_AUTO_PUBLICKEY:
 		/* ssh_agent or none */
-		return remmina_ssh_auth_auto_pubkey(ssh);
+		return remmina_ssh_auth_auto_pubkey(ssh, gp, remminafile);
 
 #if 0
 	/* Not yet supported by libssh */
@@ -472,7 +498,7 @@ 

Bug#919699: Please support -w switch to halt(8)

[Lorenzo Puliti]

Package: runit-init
Version: 2.1.2-25helpers1
Followup-For: Bug #919699

Hi,

>I am okay with accepting patch to implement writing `wtmp' entry, if it
>is reasonably small, but I would prefer to delegate it to external
>implementation, like https://git.suckless.org/utmp (not sure it is
>applicable).

Just in case you don't know, there is already a 'sac' package that include a
'writetmp - write special wtmp entries to a wtmp file.' program.

https://packages.debian.org/sid/sac

The only thing is that last sac release is dated around Dec 2004 and last
update of the Debian sac package is from Dec 2011, otherwise it looks the
right external tool.

Lorenzo

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

Kernel: Linux 4.20.3-van (SMP w/4 CPU cores; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: runit (via /run/runit.stopit)

Versions of packages runit-init depends on:
ii  getty-run   2.1.2-25
ii  initscripts 2.93-8
ii  libc6   2.28-8
ii  runit   2.1.2-25helpers1
ii  runit-helper2.8.7
ii  sysuser-helper  1.3.3
ii  sysv-rc 2.93-8

runit-init recommends no packages.

runit-init suggests no packages.

-- no debconf information

Bug#924234: dtkcore: Cross-builds incorrectly, built packages contain paths from build architecture

[Helmut Grohne]

Control: clone -1 -2
Control: reassign -2 src:dtkwidget

On Sun, Mar 10, 2019 at 04:47:35PM +0300, Dmitry Shachnev wrote:
> When one cross-builds dtkcore package the contents of built libdtkcore-dev
> are wrong: some files are installed into /usr/lib/${DEB_BUILD_MULTIARCH}
> instead of the expected /usr/lib/${DEB_HOST_MULTIARCH} path.

Thank you. I observe that dtkwidget has a copy of this bug.

Helmut

Bug#924317: unblock: node-istanbul/0.4.5+ds-5

[Xavier Guimard]

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

Hi all,

Please unblock package node-istanbul: a RC bug has been filed just
before freeze deadline. I fixed it in node-istanbul/0.4.5+ds-5.

The debdiff contains:
 - switch test to pkg-js-tools and create links on-the-fly during build
 - debian/control update to add libjs-prettify in package dependencies
 - debian/links update to create links properly

Cheers,
Xavier

unblock node-istanbul/0.4.5+ds-5

-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (600, 'testing'), (50, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.14.0-3-amd64 (SMP w/2 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE= 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff --git a/debian/changelog b/debian/changelog
index 30cf7c5..2870ef2 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,13 @@
+node-istanbul (0.4.5+ds-5) unstable; urgency=medium
+
+  * Team upload
+  * Fix changelog install (Closes: #920342)
+  * Switch tests to pkg-js-tools
+  * Add libjs-prettify in dependencies (Closes: #919841)
+  * generate prettify.js links with dh_links
+
+ -- Xavier Guimard   Sun, 10 Mar 2019 10:27:57 +0100
+
 node-istanbul (0.4.5+ds-4) unstable; urgency=medium
 
   * Team upload
diff --git a/debian/control b/debian/control
index f69e2aa..b0abdea 100644
--- a/debian/control
+++ b/debian/control
@@ -3,6 +3,7 @@ Section: javascript
 Priority: optional
 Maintainer: Debian Javascript Maintainers 

 Uploaders: Bastien Roucariès 
+Testsuite: autopkgtest-pkg-nodejs
 Build-Depends:
  debhelper (>= 12)
  , dh-buildinfo
@@ -22,6 +23,7 @@ Build-Depends:
  , node-supports-color (>= 3.1.0) 
  , node-which (>= 1.1.1) 
  , node-wordwrap (>= 1.0.0) 
+ , pkg-js-tools
 Standards-Version: 4.3.0
 Homepage: https://github.com/gotwarlost/istanbul#readme
 Vcs-Git: https://salsa.debian.org/js-team/node-istanbul.git
@@ -31,6 +33,7 @@ Package: node-istanbul
 Architecture: all
 Depends:
  ${misc:Depends}
+ , libjs-prettify
  , nodejs
  , node-abbrev (>= 1.0.0)
  , node-async (>= 0.8)
diff --git a/debian/links b/debian/links
index f82d5f6..5fb0f43 100644
--- a/debian/links
+++ b/debian/links
@@ -1 +1,3 @@
 usr/lib/nodejs/istanbul/lib/cli.js usr/bin/istanbul
+usr/share/javascript/prettify/prettify.js 
usr/lib/nodejs/istanbul/lib/assets/vendor/prettify.js
+usr/share/javascript/prettify/prettify.css 
usr/lib/nodejs/istanbul/lib/assets/vendor/prettify.css
diff --git a/debian/rules b/debian/rules
index 1367cc8..99a5ce3 100755
--- a/debian/rules
+++ b/debian/rules
@@ -5,33 +5,16 @@
 #export DH_VERBOSE=1
 
 %:
-   dh $@
+   dh $@ --with nodejs
 
 override_dh_auto_clean:
rm -rf lib/assets/vendor
 
-override_dh_auto_build:
-   mkdir -p lib/assets/vendor
-   test -f  /usr/share/javascript/prettify/prettify.js
-   ln -s /usr/share/javascript/prettify/prettify.js  
lib/assets/vendor/prettify.js
-   test -f /usr/share/javascript/prettify/prettify.css
-   ln -s /usr/share/javascript/prettify/prettify.css 
lib/assets/vendor/prettify.css
-
-override_dh_auto_test:
-ifeq (,$(filter nocheck,$(DEB_BUILD_OPTIONS) $(DEB_BUILD_PROFILES)))
-   # smoke test
-   lib/cli.js help
-else
-   @echo '**'
-   @echo 'Skip test suite   '
-   @echo '**'
-endif
-
 override_dh_fixperms:
dh_fixperms
chmod +x debian/node-istanbul/usr/lib/nodejs/istanbul/lib/cli.js
 
 override_dh_installchangelogs:
 # fix mix of html and text
-   dh_installchangelogs
+   dh_installchangelogs CHANGELOG.md
sed -i -e 's,,,g' -e 's,,,g'  -e 's,,,g' -e 
's,,,g' -e 's/td>//g' -e 's/[ \t]*$$//' 
debian/node-istanbul/usr/share/doc/node-istanbul/changelog
diff --git a/debian/tests/control b/debian/tests/control
deleted file mode 100644
index 3fd2b47..000
--- a/debian/tests/control
+++ /dev/null
@@ -1,5 +0,0 @@
-Tests: require
-Depends: node-istanbul, nodejs (>= 6)
-
-Tests: smoketest
-Depends: node-istanbul
diff --git a/debian/tests/pkg-js/test b/debian/tests/pkg-js/test
new file mode 100644
index 000..0146830
--- /dev/null
+++ b/debian/tests/pkg-js/test
@@ -0,0 +1,13 @@
+SRC=0
+if [ ! -d lib/assets/vendor ]; then
+   mkdir -p lib/assets/vendor
+   ln -s /usr/share/javascript/prettify/prettify.js  
lib/assets/vendor/prettify.js
+   ln -s /usr/share/javascript/prettify/prettify.css 
lib/assets/vendor/prettify.css
+   SRC=1
+fi
+
+lib/cli.js help
+
+if [ "$SRC" = "1" ]; then
+   rm -rf lib/assets/vendor
+fi
diff --git a/debian/tests/require b/debian/tests/require
deleted file mode 100755
index ab27d0e..000
--- a/debian/tests/require
+++ /dev/null
@@ -1,3 +0,0 @@
-#!/bin/sh
-set 

Bug#924288: Could go either way - Your choice

[MK]

It seems iptables now uses iptables-nft compatible alternatives, so ufw will 
wrap around nftables by using iptables syntax.
 "Starting with Debian Buster, nf_tables is the default backend when using 
iptables, by means of the iptables-nft layer (i.e, using iptables syntax with 
the nf_tables kernel subsystem). This also affects ip6tables, arptables and 
ebtables."

Still, this isn't recommended:

"NOTE: Debian Buster will use the nftables framework by default."

And we certainly should be using the one Debian is planning to support for 
Buster
 "don't mix nftables and iptables rulesets unless you know what you are doing."

It recommends migrating rulesets in the wiki ( nftables - Debian Wiki )
Should I replace an iptables firewall with a nftables one?Yes, nftables is the 
replacement for iptables.

Hence, we should probably be suggesting nftables instead of ufw (which uses 
wrapped iptables)

| 
| 
| 
|  |  |

 |

 |
| 
|  | 
nftables - Debian Wiki


 |

 |

 |

Bug#924297: elpa-eshell-git-prompt: missing-powerline-fonts

[Lev Lamberov]

Hi Salman,

Пн 11 мар 2019 @ 09:04 Salman Mohammadi :

> I suggest you use `fonts-powerline` as a recommendation for this package.

thanks for you report and suggestion. I'll take care of it after the
coming buster release. We are currently in the freeze stage, so not any
change will be accepted by the release team.

Regards,
Lev

Bug#924058: runit: replace obsolete usleep with nanosleep in sv.c

[Gerrit Pape]

On Sun, Mar 10, 2019 at 07:12:36PM +, Dmitry Bogatov wrote:
> [2019-03-08 23:43] Jan 
> > >From f7b8f943d1f7a8f26df8d81eeb0a2d5a69ee7e22 Mon Sep 17 00:00:00 2001
> > From: Jan 
> > Date: Wed, 6 Mar 2019 18:38:04 +0100
> > Subject: [PATCH] fix: replace obsolete usleep with nanosleep
> >
> >  POSIX.1-2001 declares usleep obsolete,
> >  POSIX.1-2008 removes the specification of usleep,
> >  see https://linux.die.net/man/3/usleep
> 
> Looks good to me. Thank you. I will let this patch hang till release,
> and will apply and upload after thaw. While change seems perfectly fine,
> moving parts around freeze feels worriesome.
> 
> Gerrit, as you can see, there is some activity around runit, in
> particular about C code. I consider releasing runit-2.1.2 with
> all patches, accumulated in Debian package as runit-2.1.3 for
> convenience of other distributions (Void, Gentoo). Do you object?
> Would you like to do it yourself?

Hi Dmitry,

I'm about to resume some activities on FOSS which includes a runit-2.1.3
upstream version eventually.

Please put the patches you consider appropriate only into the Debian
namespace 2.1.2-*.

Thanks a lot for the energy you put into runit, it motivates to
participate a bit again.  And thanks to Jan for the patch.

Happy hacking, Gerrit.

Bug#924315: raspi3-firmware: remove kernel.img and kernel7.img from firmware package

[Florian La Roche]

Package: raspi3-firmware
Version: 1.20190215-1
Severity: minor

Dear Maintainer,

raspi3-firmware also contains the kernel.img and kernel7.img files,
but could remove these files and only ship real firmware files.
I don't see benefit to ship another kernel image.

If you think otherwise, please just close this bug report. This is
really a minor issue.

best regards,

Florian La Roche


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

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

Versions of packages raspi3-firmware depends on:
ii  dosfstools  4.1-2

raspi3-firmware recommends no packages.

raspi3-firmware suggests no packages.

-- no debconf information

Bug#912884: daemontools-run: move /etc/service to /service please, etckeeper explodes

[Gerrit Pape]

On Sun, Nov 04, 2018 at 06:09:34PM +, Thorsten Glaser wrote:
> Package: daemontools-run
> Version: 1:0.76-7
> Severity: important
> 
> I was wondering why my /etc is 11 GiB in size.
> 
> Turns out /etc/.git (from etckeeper) is 10 GiB,
> because it covers /service/*/log/main/* from dæmontools.
> 
> This is… unfortunate.

Hi Thorsten, I'd love to move to /service, from the very beginning
actually, but FHS and so Debian Policy does not allow.

daemontools works fine with symlinks, so you could setup log directories
in /var/log/ and link them into service directories, e.g.

 /etc/service/foo/log/main -> /var/log/foo/

Regards, Gerrit.

Bug#924314: test payload for CVE-2000-0482 crashes kernel 4.19.16

[Valentin Kleibel]

Package: src:linux
Version: 4.19.16-1
Severity: normal
Tags: upstream

While testing for known vulnerabilities, we realized that systems 
running debian buster on kernel 4.19.0-2-amd64 (upstream 4.19.16) crash 
when targeted by the openvas-nasl script jolt2.nasl, which is designed 
to test for CVE-2000-0482 
[https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2000-0482] also 
known as jolt2.
The script can be found in the archive 
http://dl.greenbone.net/community-nvt-feed-current.tar.bz2 In there the 
path is pre2008/jolt2.nasl
the commandline to run it (on a system with libopenvas-dev=9.0.3-1 
installed):


/usr/bin/openvas-nasl -t 10.0.0.1 -X -d jolt2.nasl

We also tested this with different hardware (cpu, motherboard, nic) with 
the exact same result.


The problem is resolved in linux-image-4.19.0-3-amd64 (upstream 4.19.20) 
and didn't exist in linux-image-4.19.0-1-amd64 (upstream 4.19.12)


Attached you can find the sylog from the crash.

Best regards,
Valentin Kleibel


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

Kernel: Linux 4.19.0-2-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)

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

Versions of packages linux-image-4.19.0-2-amd64 depends on:
ii  initramfs-tools [linux-initramfs-tool]  0.133
ii  kmod26-1
ii  linux-base  4.5

Versions of packages linux-image-4.19.0-2-amd64 recommends:
ii  apparmor 2.13.2-9
ii  firmware-linux-free  3.4
ii  irqbalance   1.5.0-3

Versions of packages linux-image-4.19.0-2-amd64 suggests:
pn  debian-kernel-handbook  
ii  grub-pc 2.02+dfsg1-12
pn  linux-doc-4.19  

Versions of packages linux-image-4.19.0-2-amd64 is related to:
ii  firmware-amd-graphics   20190114-1
pn  firmware-atheros
pn  firmware-bnx2   
pn  firmware-bnx2x  
pn  firmware-brcm80211  
pn  firmware-cavium 
pn  firmware-intel-sound
pn  firmware-intelwimax 
pn  firmware-ipw2x00
pn  firmware-ivtv   
pn  firmware-iwlwifi
pn  firmware-libertas   
ii  firmware-linux-nonfree  20190114-1
ii  firmware-misc-nonfree   20190114-1
pn  firmware-myricom
pn  firmware-netxen 
pn  firmware-qlogic 
ii  firmware-realtek20190114-1
pn  firmware-samsung
pn  firmware-siano  
pn  firmware-ti-connectivity
ii  xen-hypervisor-4.11-amd64 [xen-hypervisor]  4.11.1+26-g87f51bf366-3
Mar 11 10:39:26 helena systemd[1386]: Reached target Paths.
Mar 11 10:39:26 helena systemd[1386]: Condition check resulted in Sound System 
being skipped.
Mar 11 10:39:26 helena systemd[1386]: Listening on GnuPG network certificate 
management daemon.
Mar 11 10:39:26 helena systemd[1386]: Reached target Timers.
Mar 11 10:39:26 helena systemd[1386]: Listening on GnuPG cryptographic agent 
and passphrase cache (restricted).
Mar 11 10:39:26 helena systemd[1386]: Listening on GnuPG cryptographic agent 
and passphrase cache.
Mar 11 10:39:26 helena systemd[1386]: Starting D-Bus User Message Bus Socket.
Mar 11 10:39:26 helena systemd[1386]: Listening on GnuPG cryptographic agent 
and passphrase cache (access for web browsers).
Mar 11 10:39:26 helena systemd[1386]: Listening on GnuPG cryptographic agent 
(ssh-agent emulation).
Mar 11 10:39:26 helena systemd[1386]: Listening on D-Bus User Message Bus 
Socket.
Mar 11 10:39:26 helena systemd[1386]: Reached target Sockets.
Mar 11 10:39:26 helena systemd[1386]: Reached target Basic System.
Mar 11 10:39:26 helena systemd[1386]: Reached target Default.
Mar 11 10:39:26 helena systemd[1386]: Startup finished in 69ms.
Mar 11 10:39:26 helena systemd[1]: Started User Manager for UID 0.
Mar 11 10:39:26 helena systemd[1]: Started Session 3 of user root.
Mar 11 10:39:41 helena systemd[1]: systemd-fsckd.service: Succeeded.
Mar 11 10:39:42 helena systemd-timesyncd[625]: Synchronized to time server for 
the first time 213.235.200.199:123 (2.debian.pool.ntp.org).
Mar 11 10:39:49 helena kernel: [   67.981598] BUG: unable to handle kernel NULL 
pointer dereference at 
Mar 11 10:39:49 helena kernel: [   67.984160] PGD 0 P4D 0 
Mar 11 10:39:49 helena kernel: [   67.986673] Oops:  [#1] SMP NOPTI
Mar 11 10:39:49 helena kernel: [   67.989198] CPU: 2 PID: 0 Comm: 

Bug#850425: mpt3sas "swiotlb buffer is full" problem only under Xen

[Juergen Gross]

On 10/03/2019 23:03, Andrew Cooper wrote:
> On 10/03/2019 21:35, Hans van Kranenburg wrote:
>> found -1 4.19.20-1
>> thanks
>>
>> Hi,
>>
>> Reviving a thing from Jan 2017 here. I don't have this thread in my
>> mailbox, so no inline quotes.
>>
>> I just installed some HP z820 workstation and rebooted it into Xen
>> 4.11.1+26-g87f51bf366-3 with linux 4.19.20-1 as dom0 kernel.
>>
>> During boot I'm greeted by a long list of...
>>
>> [   14.518793] mpt3sas :02:00.0: swiotlb buffer is full (sz: 65536
>> bytes)
>> [   14.518899] mpt3sas :02:00.0: swiotlb buffer is full
>> [   14.518956] mpt3sas :02:00.0: swiotlb buffer is full (sz: 65536
>> bytes)
>> [   14.518988] sd 6:0:3:0: pci_map_sg failed: request for 786432 bytes!
>> [   14.519081] mpt3sas :02:00.0: swiotlb buffer is full
>> [   14.519309] sd 6:0:1:0: pci_map_sg failed: request for 1310720 bytes!
>> [   14.524611] mpt3sas :02:00.0: swiotlb buffer is full (sz: 65536
>> bytes)
>> [   14.527309] mpt3sas :02:00.0: swiotlb buffer is full
>> [   14.527405] sd 6:0:3:0: pci_map_sg failed: request for 786432 bytes!
>> [...]
>>
>> ...and some hangs here and there. This indeed did not happen when
>> booting just Linux, without Xen.
>>
>> Some searching brought me to this Debian bug. So, thanks for writing
>> down all kinds of research here already. Even if it's not fixed upstream
>> yet, this helps a lot. :-)
>>
>> Using dom0_mem=2GiB,max:4GiB instead of dom0_mem=2GiB,max:2GiB (which I
>> started with) makes the errors go away, so workaround confirmed.
>>
>> I can try any of the linked patches, but I see that in message 54,
>>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=850425#54
>> Andrew says: "IIRC, they were essentially rejected,". Next message, Ian
>> asks "Do you have a reference ?", but I don't see any fup on that.
>>
>> I think I'm fine with this workaround.
>>
>> If someone will ever work on the upstream patches, then this is just to
>> let know that I might be able to help testing. However, I only have one
>> of this type of box and it's gonna be installed as server at some
>> non-profit organization without OOB access, replacing even older donated
>> hardware, so, it will be kinda limited... :)
> 
> I think
> https://lists.xen.org/archives/html/xen-devel/2014-12/msg00699.html is
> the last attempt David made to upstream the fixes.

Attached is a rebase of the last part missing.

Should apply on top of 5.0 kernel, 4.20 should be okay, too. Earlier
kernels will miss some prerequisites.


Juergen
From: David Vrabel 
Date: Mon, 11 Mar 2019 14:40:00 +0100
Subject: [PATCH] x86/xen: assume a 64-bit DMA mask is required

On a Xen PV guest the DMA addresses and physical addresses are not 1:1
(such as Xen PV guests) and the generic dma_get_required_mask() does
not return the correct mask (since it uses max_pfn).

Some device drivers (such as mptsas, mpt2sas) use
dma_get_required_mask() to set the device's DMA mask to allow them to
use only 32-bit DMA addresses in hardware structures.  This results in
unnecessary use of the SWIOTLB if DMA addresses are more than 32-bits,
impacting performance significantly.

We could base the DMA mask on the maximum MFN but:

a) The hypercall op to get the maximum MFN (XENMEM_maximum_ram_page)
will truncate the result to an int in 32-bit guests.

b) Future uses of the IOMMU in Xen may map frames at bus addresses
above the end of RAM.

So, just assume a 64-bit DMA mask is always required.

Signed-off-by: David Vrabel 
Reviewed-by: Juergen Gross 
---
 drivers/xen/swiotlb-xen.c |6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index bb7888429be6..75e6e440d982 100644
--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -680,6 +680,11 @@ xen_swiotlb_get_sgtable(struct device *dev, struct sg_table *sgt,
 	return dma_common_get_sgtable(dev, sgt, cpu_addr, handle, size, attrs);
 }
 
+static u64 xen_swiotlb_get_required_mask(struct device *dev)
+{
+	return DMA_BIT_MASK(64);
+}
+
 const struct dma_map_ops xen_swiotlb_dma_ops = {
 	.alloc = xen_swiotlb_alloc_coherent,
 	.free = xen_swiotlb_free_coherent,
@@ -694,4 +699,5 @@ const struct dma_map_ops xen_swiotlb_dma_ops = {
 	.dma_supported = xen_swiotlb_dma_supported,
 	.mmap = xen_swiotlb_dma_mmap,
 	.get_sgtable = xen_swiotlb_get_sgtable,
+	.get_required_mask = xen_swiotlb_get_required_mask,
 };

Bug#923931: upgrade breaks old containers

[Antonio Terceiro]

On Mon, Mar 11, 2019 at 09:54:14AM +0100, Harald Dunkel wrote:
> Hi Pierre,
> 
> On 3/8/19 2:30 PM, Pierre-Elliott Bécue wrote:
> > 
> > I'm sorry, but lxc-templates is not needed to have lxc3 working, so it
> > won't become a Dependency. Moving the files from src:lxc-templates to
> > src:lxc and subsequently creating two DS uploads is not a fine solution
> > either.
> > 
> 
> lxc-templates is necessary for a successful migration of the containers
> generated on Stretch. I do not know what else I can say about this.

I'm not going to repeat the explanation why lxc-templates is not a hard
dependency of lxc. This hard dependency will need to be dropped at some
point, either now or in the future. Now or then, people who blindly
disable Recommends: AND don't read NEWS entries will be affected, and
we will have to live with that.


signature.asc
Description: PGP signature

Bug#832865: [Pkg-telepathy-maintainers] Bug#832865: telepathy-python: FTBFS: will not overwrite just-created '/«PKGBUILDDIR»/debian/python-telepathy//usr/lib/python2.7/dist-packages/telepathy/_generat

[Santiago Vila]

Any progress on this FTBFS bug?

Not that I can reproduce it easily, but the problem is certainly still
there, see this for example:

https://tests.reproducible-builds.org/debian/logs/unstable/armhf/telepathy-python_0.15.19-3.build2.log.gz

I did a preliminary analysis here:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=832865#24

and I think that we almost have it.

Based on the above: Can you explain why does it *not* always fail?

Would the package build the same if we applied the patch below?

Thanks.

--- a/src/Makefile.in
+++ b/src/Makefile.in
@@ -219,7 +219,6 @@ spec_files := $(patsubst 
$(spec_dir)%.xml,_generated%.py,$(wildcard $(spec_dir)/
 BUILT_SOURCES = \
_generated/interfaces.py \
_generated/constants.py \
-   _generated/errors.py \
_generated/__init__.py \
$(spec_files)
 

Bug#863601: systemd-notify doesn't work because of race condition

[Андрей Доценко]

Sorry for late answer. I'll try to test with old solution but it wouldn't
be sooner than in a month or two since I'm very limited of time.

вс, 10 мар. 2019 г. в 02:22, Michael Biebl :

> Control: forwarded -1 https://github.com/systemd/systemd/issues/2739
>
> On Thu, 1 Jun 2017 17:50:27 +0200 Michael Biebl  wrote:
> > On Mon, 29 May 2017 09:20:52 +0200
> > =?UTF-8?B?0JDQvdC00YDQtdC5INCU0L7RhtC10L3QutC+?= 
> > wrote:
> > > Package: systemd
> > > Version: 232
> > >
> > > I used unit-file with options below:
> > >
> > > Type=notify
> > > NotifyAccess=all
> > >
> > > Command `systemd-notify --ready` worked only once. All other times it
> did
> > > nothing. Service was killed by systemd after timeout. systemd-notify
> > > returned zero code (success). No error was reported.
> > >
> > > Workaround script I used to solve the issue:
> > >
> > > inport systemd.daemon;
> > > systemd.daemon.notify('READY=1')
> > >
> > > Another bug report might describe the same issue:
> > > https://bugzilla.redhat.com/show_bug.cgi?id=982376
> > > But in my case everything works without any sleeps.
> >
> > Can you please share the complete unit file and the script you used so
> > we have a minimal test case to reproduce the issue.
>
> I tried the test service that was linked in the bugzilla bug report but
> was not able to reproduce the issue.
> Do you still see the problem with a recent version of systemd?
>
> That said, I suppose the referenced upstream bug report is about the
> same issue and still marked as unfixed. So tentatively marking the bug
> as forwarded.
>
> Regards,
> Michael
>
> --
> Why is it that all of the instruments seeking intelligent life in the
> universe are pointed away from Earth?
>
>

-- 
Андрей Николаевич, инженер-программист.

Bug#924313: apt-listchanges: erroneous and misleading message

[Nicholas Joll]

Package: apt-listchanges

Version: 3.16

The program displays this text: 'You can abort the installation if you
select "no"'. Taken literally, that text has this meaning: if you select
'no', then you will be given an opportunity to abort the installation.
Yet, that is not what is meant. What is meant - the way the program
actually works (well, at least as I have it set up) - is: if you select
'no', then the installation will abort *immediately*.

Proposed fix: change the text to read as follows. 'Select "yes" to
continue with the installation. Select 'no' to abort the installation.'
Or, if shorter text is needed: 'Select "yes" to continue with the
installation. "No" will abort.'

Yours

Nicholas

Kernel: 5

Bug#924077: mini-buildd: sbuild-update has no option --keygen

[Stephan Sürken]

Hi "itd",

On Sat, 2019-03-09 at 12:31 +0100, i...@firemail.cc wrote:
> Package: mini-buildd
> Version: 1.0.36
> Severity: normal
> Tags: upstream
> 
> Dear Maintainer,
> 
> sbuild (>= 0.77.0) no longer supports `sbuild-update` option `
> --keygen` 

ups yes - thx for the hint.

It's really time to go for that old compatibility workaround ;).

Will remove this in dev, ignore the error in stable.

Thx!

S

Bug#924312: stunnel4: Fails to stop with sysvinit: start-stop-daemon: matching only on non-root pidfile /var/lib/stunnel4///stunnel4.pid is insecure

[Axel Beckert]

Package: stunnel4
Version: 3:5.50-3
Severity: serious

stopping or restarting stunnel4 on systems with sysvinit (or probably
also any other init system using start-stop-daemon) fails as follows for
me:

 invoke-rc.d stunnel4 restart
Restarting TLS tunnels: /etc/stunnel/stunnel.conf: /sbin/start-stop-daemon: 
matching only on non-root pidfile /var/lib/stunnel4///stunnel4.pid is insecure
stopped

And despite it claims at the end "stopped", stunnel is not stopped as ps
shows:

stunnel4 26991  0.0  0.0  87196   156 ?Ssl  Jan21   0:00 
/usr/bin/stunnel4 /etc/stunnel/stunnel.conf

This is caused by the following change in dpkg 1.19.3 from 22 Jan 2019:

  * start-stop-daemon: Check whether standalone --pidfile use is secure.
Prompted by Michael Orlitzky .

The usual fix seems to be to also specify the binary to be stopped with
IIRC the --exec option.

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

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

Versions of packages stunnel4 depends on:
ii  adduser  3.118
ii  libc62.28-8
ii  libssl1.11.1.1b-1
ii  libsystemd0  241-1
ii  libwrap0 7.6.q-28
ii  lsb-base 10.2018112800
ii  netbase  5.6
ii  openssl  1.1.1b-1
ii  perl 5.28.1-4

stunnel4 recommends no packages.

Versions of packages stunnel4 suggests:
pn  logcheck-database  

-- Configuration Files:
/etc/stunnel/stunnel.conf changed:
; Sample stunnel configuration file by Michal Trojnara 2002-2009
; Some options used here may not be adequate for your particular configuration
; Please make sure you understand them (especially the effect of the chroot 
jail)
; Certificate/key is needed in server mode and optional in client mode
;cert = /etc/ssl/certs/stunnel.pem
;key = /etc/ssl/certs/stunnel.pem
; Protocol version (all, SSLv2, SSLv3, TLSv1)
sslVersion = TLSv1
; Some security enhancements for UNIX systems - comment them out on Win32
chroot = /var/lib/stunnel4/
setuid = stunnel4
setgid = stunnel4
; PID is created inside the chroot jail
pid = /stunnel4.pid
; Some performance tunings
socket = l:TCP_NODELAY=1
socket = r:TCP_NODELAY=1
;compression = zlib
; Workaround for Eudora bug
;options = DONT_INSERT_EMPTY_FRAGMENTS
; Authentication stuff
;verify = 2
; Don't forget to c_rehash CApath
; CApath is located inside chroot jail
;CApath = /certs
; It's often easier to use CAfile
;CAfile = /etc/stunnel/certs.pem
; Don't forget to c_rehash CRLpath
; CRLpath is located inside chroot jail
;CRLpath = /crls
; Alternatively you can use CRLfile
;CRLfile = /etc/stunnel/crls.pem
; Some debugging stuff useful for troubleshooting
;debug = 7
;output = /var/log/stunnel4/stunnel.log
; Use it for client mode
;client = yes
; Service-level configuration
;[pop3s]
;accept  = 995
;connect = 110
;[imaps]
;accept  = 993
;connect = 143
;[ssmtp]
;accept  = 465
;connect = 25
;[https]
;accept  = 443
;connect = 80
;TIMEOUTclose = 0
[bbs]
;accept  = localhost:1984
accept  = 127.0.0.1:1984
connect = sym.noone.org:1983
client = yes
[bbs2]
;accept  = localhost:1984
accept  = 127.0.0.2:1984
connect = c3pio.deuxchevaux.org:1983
client = yes
; vim:ft=dosini


-- no debconf information

Bug#924311: miredo: Fails to stop with sysvinit: start-stop-daemon: matching only on non-root pidfile /var/run/miredo.pid is insecure

[Axel Beckert]

Package: miredo
Version: 1.2.6-7
Severity: serious

Hi,

stopping or restarting miredo on systems with sysvinit (or probably also
any other init system using start-stop-daemon) fails as follows for me:

 invoke-rc.d miredo restart
[] Stopping Teredo IPv6 tunneling daemon: miredostart-stop-daemon: matching 
only on non-root pidfile 
/var/run/miredo.pid is insecure
 failed!

And miredo is indeed not stopped:

root  1225  0.0  0.0  12100 0 ?Ss   Jan13   0:00 
/usr/sbin/miredo
miredo1226  0.0  0.0 110556 0 ?Sl   Jan13   0:33 
/usr/sbin/miredo
root  1228  0.0  0.0   6904   316 ?SJan13   0:00 
/usr/libexec/miredo/miredo-privproc B

This is caused by the following change in dpkg 1.19.3 from 22 Jan 2019:

  * start-stop-daemon: Check whether standalone --pidfile use is secure.
Prompted by Michael Orlitzky .

The usual fix seems to be to also specify the binary to be stopped with
IIRC the --exec option.

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

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

Versions of packages miredo depends on:
ii  adduser  3.118
ii  init-system-helpers  1.56+nmu1
ii  iproute2 4.20.0-2
ii  libc62.28-8
ii  libcap2  1:2.25-2
ii  libjudydebian1   1.0.5-5
ii  lsb-base 10.2018112800
ii  makedev  2.3.1-94
ii  udev 241-1

miredo recommends no packages.

miredo suggests no packages.

-- no debconf information

Bug#924310: xrdp: post-install script fails

[Hanno Stock]

$ sudo tail -n 100 /var/log/xrdp.log
[20190311-13:57:54] [INFO ] starting xrdp with pid 10763
[20190311-13:57:54] [ERROR] xrdp_listen_main_loop: listen error,
possible port already in use
[20190311-13:57:54] [DEBUG] Closed socket 11 (AF_INET6 :: port 0)

This looks strange. Might be related to this host not having IPv6?



signature.asc
Description: OpenPGP digital signature

Bug#924310: xrdp: post-install script fails

[Hanno Stock]

Package: xrdp
Version: 0.9.1-9+deb9u3
Severity: serious
Justification: Policy 6.4

Dear Maintainer,

on my system, xrdp fails to install. (see log)

Not sure what the problem here is - if it is just missing configuration,
post-install script should not fail and just skip starting the service.

Best regards

Hanno

Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut.   
Statusinformationen werden eingelesen Fertig
The following additional packages will be installed:
  xorgxrdp
Vorgeschlagene Pakete:
  guacamole
Die folgenden NEUEN Pakete werden installiert:
  xorgxrdp xrdp
0 aktualisiert, 2 neu installiert, 0 zu entfernen und 0 nicht
aktualisiert.
Es müssen 519 kB an Archiven heruntergeladen werden.
Nach dieser Operation werden 3.387 kB Plattenplatz zusätzlich benutzt.
Möchten Sie fortfahren? [J/n] j
Holen:1 http://ftp.de.debian.org/debian stretch/main amd64 xorgxrdp
amd64 0.9.1-9+deb9u3 [80,6 kB]
Holen:2 http://ftp.de.debian.org/debian stretch/main amd64 xrdp amd64
0.9.1-9+deb9u3 [439 kB]
Es wurden 519 kB in 0 s geholt (5.240 kB/s).
[master e5e3e07] saving uncommitted changes in /etc prior to apt run
 Author: [redacted]
 7 files changed, 1419 insertions(+), 45 deletions(-)
 create mode 100644 cups/ppd/LabelManager-PnP.ppd
 create mode 100644 cups/ppd/LabelWriter-450.ppd
Vormals nicht ausgewähltes Paket xorgxrdp wird gewählt.
(Lese Datenbank ... 690877 Dateien und Verzeichnisse sind derzeit
installiert.)
Vorbereitung zum Entpacken von .../xorgxrdp_0.9.1-9+deb9u3_amd64.deb ...
Entpacken von xorgxrdp (0.9.1-9+deb9u3) ...
Vormals nicht ausgewähltes Paket xrdp wird gewählt.
Vorbereitung zum Entpacken von .../xrdp_0.9.1-9+deb9u3_amd64.deb ...
Entpacken von xrdp (0.9.1-9+deb9u3) ...
Trigger für libc-bin (2.24-11+deb9u4) werden verarbeitet ...
xrdp (0.9.1-9+deb9u3) wird eingerichtet ...

Konfigurationsdatei »/etc/default/xrdp« existiert auf dem System nicht.
Neue Konfigurationsdatei wird wie gefordert installiert.

Konfigurationsdatei »/etc/init.d/xrdp« existiert auf dem System nicht.
Neue Konfigurationsdatei wird wie gefordert installiert.

Konfigurationsdatei »/etc/pam.d/xrdp-sesman« existiert auf dem System
nicht.
Neue Konfigurationsdatei wird wie gefordert installiert.

Konfigurationsdatei »/etc/xrdp/km-0407.ini« existiert auf dem System
nicht.
Neue Konfigurationsdatei wird wie gefordert installiert.

Konfigurationsdatei »/etc/xrdp/km-0409.ini« existiert auf dem System
nicht.
Neue Konfigurationsdatei wird wie gefordert installiert.

Konfigurationsdatei »/etc/xrdp/km-040a.ini« existiert auf dem System
nicht.
Neue Konfigurationsdatei wird wie gefordert installiert.

Konfigurationsdatei »/etc/xrdp/km-040b.ini« existiert auf dem System
nicht.
Neue Konfigurationsdatei wird wie gefordert installiert.

Konfigurationsdatei »/etc/xrdp/km-040c.ini« existiert auf dem System
nicht.
Neue Konfigurationsdatei wird wie gefordert installiert.

Konfigurationsdatei »/etc/xrdp/km-0410.ini« existiert auf dem System
nicht.
Neue Konfigurationsdatei wird wie gefordert installiert.

Konfigurationsdatei »/etc/xrdp/km-0411.ini« existiert auf dem System
nicht.
Neue Konfigurationsdatei wird wie gefordert installiert.

Konfigurationsdatei »/etc/xrdp/km-0412.ini« existiert auf dem System
nicht.
Neue Konfigurationsdatei wird wie gefordert installiert.

Konfigurationsdatei »/etc/xrdp/km-0414.ini« existiert auf dem System
nicht.
Neue Konfigurationsdatei wird wie gefordert installiert.

Konfigurationsdatei »/etc/xrdp/km-0415.ini« existiert auf dem System
nicht.
Neue Konfigurationsdatei wird wie gefordert installiert.

Konfigurationsdatei »/etc/xrdp/km-0416.ini« existiert auf dem System
nicht.
Neue Konfigurationsdatei wird wie gefordert installiert.

Konfigurationsdatei »/etc/xrdp/km-0419.ini« existiert auf dem System
nicht.
Neue Konfigurationsdatei wird wie gefordert installiert.

Konfigurationsdatei »/etc/xrdp/km-041d.ini« existiert auf dem System
nicht.
Neue Konfigurationsdatei wird wie gefordert installiert.

Konfigurationsdatei »/etc/xrdp/km-0807.ini« existiert auf dem System
nicht.
Neue Konfigurationsdatei wird wie gefordert installiert.

Konfigurationsdatei »/etc/xrdp/km-0809.ini« existiert auf dem System
nicht.
Neue Konfigurationsdatei wird wie gefordert installiert.

Konfigurationsdatei »/etc/xrdp/km-080c.ini« existiert auf dem System
nicht.
Neue Konfigurationsdatei wird wie gefordert installiert.

Konfigurationsdatei »/etc/xrdp/km-0813.ini« existiert auf dem System
nicht.
Neue Konfigurationsdatei wird wie gefordert installiert.

Konfigurationsdatei »/etc/xrdp/km-0816.ini« existiert auf dem System
nicht.
Neue Konfigurationsdatei wird wie gefordert installiert.

Konfigurationsdatei »/etc/xrdp/km-100c.ini« existiert auf dem System
nicht.
Neue Konfigurationsdatei wird wie gefordert installiert.

Konfigurationsdatei »/etc/xrdp/pulse/default.pa« existiert auf dem
System nicht.
Neue Konfigurationsdatei wird wie gefordert installiert.

Bug#870186: [Pkg-sass-devel] Bug#870186: libsass: CVE-2017-11608

[Jonas Smedegaard]

Quoting Jonas Smedegaard (2019-03-11 13:43:41)
> POC on Debian stretch with libsass1 3.4.3-1 and sassc 3.4.2-1:
> 
> Error: Invalid UTF-8 sequence
> on line 1 of /attachment.cgi?id=1303540
> >> "�d\
>-^

Correction: Aboce was with libsass1 3.5.5-2 and sassc 3.5.0-1.

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Bug#866354: Breaks for the armel libstdc++ symbol version changes

[Adrian Bunk]

Control: reopen -1
Control: tags -1 buster sid

The following breaks are needed to handle the moved symbols from the
pr64735 fix in gcc-6 in stretch->buster upgrades on armel:

dnsdist (<< 1.3.3-3)
lambda-align (<< 1.0.3-5)
libllvm3.8
libllvm3.9
libllvm4.0
mednafen (<< 1.22.1+dfsg-1)
nghttp2-proxy (<< 1.36.0-2)
osm2pgsql (<< 0.96.0+ds-2)
osmcoastline (<< 2.2.4-1)
osmium-tool (<< 1.10.0-1)
pdns-recursor (<< 4.1.11-1)
poedit (<< 2.2.1-2)
python-pyosmium (<< 2.15.1-1)
python3-pyosmium (<< 2.15.1-1)
seer (<< 1.1.4-2)
libsimgrid3.14
undertaker (<< 1.6.1-4.2)
libusbguard0 (<< 0.7.4+ds-1)

This does intentionally break << the version in buster/unstable,
for also breaking versions of these packages in stretch-backports.

The LLVM and libsimgrid3.14 breaks are unversioned since these versions 
are not in buster (or any future Debian release).

Thanks
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#924309: RM: passenger/5.0.30-1

[Nicolas Braud-Santoni]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: rm
Control: user bugsqu...@qa.debian.org
Control: usertags 884463 + ni...@debian.org

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512


Dear release team,

Passenger has had an open, grave security bug open since December 2017 (#884463)
and hasn't been uploaded to since August 2016.

As far as I can tell, no other package will be adversely impacted by the
removal.


Best,

  nicoo

-BEGIN PGP SIGNATURE-

iQJFBAEBCgAvFiEEU7EqA8ZVHYoLJhPE5vmO4pLV7MsFAlyGVKURHG5pY29vQGRl
Ymlhbi5vcmcACgkQ5vmO4pLV7MusqxAAicturFQ9JFffny4RcRQZqvYZJfSDWFNY
YQnCzq61CxU250FtopAYSHtMODFywP1Zacxrscay2ZxKeX9Wt0mFymVpaRVLrnLn
Yp07/A2sPRX6xBHdHAxiyv/flA/p7zlkr1WHslj8B1CO3mODtnh6ipPCqEW8Ok8v
+gujHhaHauxaYsKwIoBAANFZRFKhPGHt87hQWUiIa9JRAZ4N2K59FiwMF3teJbaS
FrKkDEmO9X5wlCm/Nc95Tl+Bb+RWueKF+umazYHbjl5MkXA6Gx1FewcpSe9gG03h
CifeBEc52AWJj9t2Ooonz21+NFyNcCnT7neP9ZesSX2TmydsDzCZ9LYhAt8FWrlR
nzIv9YF+6GR5X9Lk/sD0QpZ7abQF7zX8MA0x0IGWUd1uC0XtEoVHdrcnVNsE82tz
LSD7/DAAw4MMts5BEaYOFfMt+O+xsRvKCsuhnzN3WWY40ZhyvGlQcL6ru/FDU6ae
G/7vC43hbW3p/G2fa+vvFqhmCkByhphfWYgF5JMH4Sgc3x8M1P9tDW3E6BkP0Erv
hoonowHNWLJfQqSbDFpaDXJ94JNpg4I5k4sZX8TcAr/Nzmlwu7F4aArssS0UGAMv
lkCe3f2+p9Pd0k/qoYn5Ic9BbMWUT1ZsDC0DidTC6VN7L2AwfDn4XSyZU8FB/E+R
LdY7LIewwHo=
=0eoy
-END PGP SIGNATURE-

Bug#910224: python{,3}-saharaclient: leaves alternatives after purge: /usr/bin/sahara

[Andreas Beckmann]

Followup-For: Bug #910224
Control: tag -1 pending

Hi,

I've just tested the change in my piuparts setup and uploaded this as a 
NMU to DELAYED/5 and opened a stretch-pu request:
https://bugs.debian.org/924305


Andreas

Bug#924308: unblock: python-apt/1.8.4

[Julian Andres Klode]

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

Please unblock package python-apt

This upload fixes a few locking issues, most noticeably, Bug #922416. 

After fixing the archive locking mentioned in that bug, I also fixed the
lists/ locking in the update() function which could accidentally be unreleased
if slist.read_main_list() raises an exception. (second point in changelog).

These fixes use context managers, hence everything is indented a level
more, I therefore also provided a debdiff generated with -w, filename ending
in .w.diff.

I also updated the mirror lists shipped in the package as part of the
usual pre-build script.

unblock python-apt/1.8.4

-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer  i speak de, en
diff -Nru python-apt-1.8.3/apt/cache.py python-apt-1.8.4/apt/cache.py
--- python-apt-1.8.3/apt/cache.py	2019-02-04 12:50:31.0 +0100
+++ python-apt-1.8.4/apt/cache.py	2019-03-11 12:49:18.0 +0100
@@ -70,6 +70,29 @@
 """Exception that is thrown when the cache is used after close()."""
 
 
+class _WrappedLock(object):
+"""Wraps an apt_pkg.FileLock to raise LockFailedException.
+
+Initialized using a directory path."""
+
+def __init__(self, path):
+# type: (str) -> None
+self._path = path
+self._lock = apt_pkg.FileLock(os.path.join(path, "lock"))
+
+def __enter__(self):
+# type: () -> None
+try:
+return self._lock.__enter__()
+except apt_pkg.Error as e:
+raise LockFailedException(("Failed to lock directory %s: %s") %
+   (self._path, e))
+
+def __exit__(self, typ, value, traceback):
+# type: (object, object, object) -> None
+return self._lock.__exit__(typ, value, traceback)
+
+
 class Cache(object):
 """Dictionary-like package cache.
 
@@ -135,6 +158,11 @@
 # Call InitSystem so the change to Dir::State::Status is actually
 # recognized (LP: #320665)
 apt_pkg.init_system()
+
+# Prepare a lock object (context manager for archive lock)
+archive_dir = apt_pkg.config.find_dir("Dir::Cache::Archives")
+self._archive_lock = _WrappedLock(archive_dir)
+
 self.open(progress)
 
 def fix_broken(self):
@@ -426,16 +454,6 @@
 # fetched
 return self._run_fetcher(fetcher)
 
-def _get_archive_lock(self, fetcher):
-# type: (apt_pkg.Acquire) -> None
-# get lock
-archive_dir = apt_pkg.config.find_dir("Dir::Cache::Archives")
-try:
-fetcher.get_lock(archive_dir)
-except apt_pkg.Error as e:
-raise LockFailedException(("Failed to lock archive directory %s: "
-   " %s") % (archive_dir, e))
-
 def fetch_archives(self, progress=None, fetcher=None):
 # type: (AcquireProgress, apt_pkg.Acquire) -> int
 """Fetch the archives for all packages marked for install/upgrade.
@@ -457,10 +475,9 @@
 if fetcher is None:
 fetcher = apt_pkg.Acquire(progress)
 
-self._get_archive_lock(fetcher)
-
-return self._fetch_archives(fetcher,
-apt_pkg.PackageManager(self._depcache))
+with self._archive_lock:
+return self._fetch_archives(fetcher,
+apt_pkg.PackageManager(self._depcache))
 
 def is_virtual_package(self, pkgname):
 # type: (str) -> bool
@@ -520,43 +537,41 @@
 sources_list -- Update a alternative sources.list than the default.
 Note that the sources.list.d directory is ignored in this case
 """
-lockfile = apt_pkg.config.find_dir("Dir::State::Lists") + "lock"
-lock = apt_pkg.get_lock(lockfile)
-
-if lock < 0:
-raise LockFailedException("Failed to lock %s" % lockfile)
-
-if sources_list:
-old_sources_list = apt_pkg.config.find("Dir::Etc::sourcelist")
-old_sources_list_d = apt_pkg.config.find("Dir::Etc::sourceparts")
-old_cleanup = apt_pkg.config.find("APT::List-Cleanup")
-apt_pkg.config.set("Dir::Etc::sourcelist",
-   os.path.abspath(sources_list))
-apt_pkg.config.set("Dir::Etc::sourceparts", "xxx")
-apt_pkg.config.set("APT::List-Cleanup", "0")
-slist = apt_pkg.SourceList()
-slist.read_main_list()
-else:
-slist = self._list
+with _WrappedLock(apt_pkg.config.find_dir("Dir::State::Lists")):
+if sources_list:
+old_sources_list = apt_pkg.config.find("Dir::Etc::sourcelist")
+old_sources_list_d = (
+apt_pkg.config.find("Dir::Etc::sourceparts"))
+old_cleanup = apt_pkg.config.find("APT::List-Cleanup")
+  

Bug#924307: xfsprogs: xfs_fsr needlessly defragments fully defragmented files

[Marc Lehmann]

Package: xfsprogs
Version: 4.9.0+nmu1
Severity: normal

Dear Maintainer,

when I (rarely) run xfs_fsr, it defragments a few highly fragmented files,
and a lot of files with just 2 fragments. When I investigated some of
these files it turned out that they are not at all fragmented, but xfs_fsr
still makes a needless copy.

For example, this is a filefrag report of a "2 fragments" file:

 ext: logical_offset:physical_offset: length:   expected: flags:
   0:0..   21373:  612578242.. 612599615:  21374:
   1:21374..   21375:  612599616.. 612599617:  2: 
last,unwritten,eof

Which is completely contiguous - it is split into two fragments merely
because it has preallocated but unwritten extents at the end.

xfs_fsr happily makes a full copy of the file somewhere else, likely
increasing external fragmentation:

 ext: logical_offset:physical_offset: length:   expected: flags:
   0:0..   21375:  248078881.. 248100256:  21376: last,eof

This is possibly because the algorithm xfs_fsr uses was designed before
xfs had support for unwritten extents.

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

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

Versions of packages xfsprogs depends on:
ii  libblkid1 2.33.1-0.1
ii  libc6 2.28-7
ii  libreadline5  5.2+dfsg-3+b1
ii  libuuid1  2.33.1-0.1

xfsprogs recommends no packages.

Versions of packages xfsprogs suggests:
ii  acl  2.2.52-3+b1
ii  attr 1:2.4.47-2+b2
pn  quota
ii  xfsdump  3.1.6+nmu2+b1

-- no debconf information

Bug#900182: [Pkg-sass-devel] Bug#900182: libsass: CVE-2018-11499: heap use-after-free

[Jonas Smedegaard]

control: forwarded -1 https://github.com/sass/libsass/issues/2643
control: tags -1 patch

Quoting Salvatore Bonaccorso (2018-05-27 10:50:20)
> The following vulnerability was published for libsass.
> 
> CVE-2018-11499[0]:
> | A use-after-free vulnerability exists in handle_error() in
> | sass_context.cpp in LibSass 3.4.x and 3.5.x through 3.5.4 that could be
> | leveraged to cause a denial of service (application crash) or possibly
> | unspecified other impact.
> 
> If you fix the vulnerability please also make sure to include the
> CVE (Common Vulnerabilities & Exposures) id in your changelog entry.
> 
> For further information see:
> 
> [0] https://security-tracker.debian.org/tracker/CVE-2018-11499
> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-11499
> [1] https://github.com/sass/libsass/issues/2643

This seems to be upstream fix: 
https://github.com/sass/libsass/pull/2755/files/e81b722

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Bug#924306: unblock: live-build/1:20190311

[Luca Boccassi]

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

Dear Release Team,

Please consider unblocking migration of live-build 1:20190311 to buster
to fix #924293. It will be eligible to migrate in 10 days on the 21st,
which is past the deadline.

The small fix is necessary to fully support building buster images with
live-build.

An additional, welcome fix is a switch away from the deprecated
httpredir.debian.org to deb.debian.org as the default mirror URL.

The fix for the former is adding a symlink to a directory, which
debdiff shows as a bunch of new files which is not strictly true, so
I've truncated that from the debdiff inlined below.

Thank you!

-- 
Kind regards,
Luca Boccassi

diff -Nru live-build-20180925/debian/changelog 
live-build-20190311/debian/changelog
--- live-build-20180925/debian/changelog2018-09-25 14:28:19.0 
+0100
+++ live-build-20190311/debian/changelog2019-03-11 10:08:38.0 
+
@@ -1,3 +1,14 @@
+live-build (1:20190311) unstable; urgency=medium
+
+  [ Hideki Yamane ]
+  * use deb.debian.org as default
+  * We should add buster for release. (Closes: #924293)
+
+  [ Luca Boccassi ]
+  * Bump Standards-Version to 4.3.0, no changes.
+
+ -- Luca Boccassi   Mon, 11 Mar 2019 10:08:38 +
+
 live-build (1:20180925) unstable; urgency=medium
 
   [ Raphaël Hertzog ]
diff -Nru live-build-20180925/debian/control live-build-20190311/debian/control
--- live-build-20180925/debian/control  2018-09-21 11:41:00.0 +0100
+++ live-build-20190311/debian/control  2019-03-11 10:08:20.0 +
@@ -8,7 +8,7 @@
  debhelper (>= 10~),
  po4a,
  gettext,
-Standards-Version: 4.2.1
+Standards-Version: 4.3.0
 Rules-Requires-Root: no
 Homepage: https://debian-live.alioth.debian.org/live-build/
 Vcs-Browser: https://salsa.debian.org/live-team/live-build
diff -Nru live-build-20180925/functions/defaults.sh 
live-build-20190311/functions/defaults.sh
--- live-build-20180925/functions/defaults.sh   2018-06-07 18:29:28.0 
+0100
+++ live-build-20190311/functions/defaults.sh   2019-03-11 10:05:40.0 
+
@@ -326,12 +326,12 @@
# Setting mirror to fetch packages from
case "${LB_MODE}" in
debian)
-   
LB_MIRROR_BOOTSTRAP="${LB_MIRROR_BOOTSTRAP:-http://ftp.debian.org/debian/};
+   
LB_MIRROR_BOOTSTRAP="${LB_MIRROR_BOOTSTRAP:-http://deb.debian.org/debian/};

LB_PARENT_MIRROR_BOOTSTRAP="${LB_PARENT_MIRROR_BOOTSTRAP:-${LB_MIRROR_BOOTSTRAP}}"
;;
 
progress-linux)
-   
LB_PARENT_MIRROR_BOOTSTRAP="${LB_PARENT_MIRROR_BOOTSTRAP:-http://ftp.debian.org/debian/};
+   
LB_PARENT_MIRROR_BOOTSTRAP="${LB_PARENT_MIRROR_BOOTSTRAP:-http://deb.debian.org/debian/};

LB_MIRROR_BOOTSTRAP="${LB_MIRROR_BOOTSTRAP:-http://cdn.archive.progress-linux.org/packages/};
;;
esac
@@ -355,12 +355,12 @@
# Setting mirror which ends up in the image
case "${LB_MODE}" in
debian)
-   
LB_MIRROR_BINARY="${LB_MIRROR_BINARY:-http://httpredir.debian.org/debian/};
+   
LB_MIRROR_BINARY="${LB_MIRROR_BINARY:-http://deb.debian.org/debian/};

LB_PARENT_MIRROR_BINARY="${LB_PARENT_MIRROR_BINARY:-${LB_MIRROR_BINARY}}"
;;
 
progress-linux)
-   
LB_PARENT_MIRROR_BINARY="${LB_PARENT_MIRROR_BINARY:-http://ftp.debian.org/debian/};
+   
LB_PARENT_MIRROR_BINARY="${LB_PARENT_MIRROR_BINARY:-http://deb.debian.org/debian/};

LB_MIRROR_BINARY="${LB_MIRROR_BINARY:-${LB_MIRROR_CHROOT}}"
;;
esac


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

Bug#921952: [Pkg-sass-devel] Bug#921952: Don't include in buster without proper commitment to update in stable

[Jonas Smedegaard]

control: reopen -1

Quoting Jonas Smedegaard (2019-03-11 12:22:03)
> Quoting Moritz Muehlenhoff (2019-02-10 14:47:49)
> > Source: libsass
> > Severity: serious
> > 
> > None of the security bugs filed in the BTS has seen any maintainer followup
> > (dating back to 2017 in some cases), and that's just the tip of the iceberg,
> > the security tracker lists many more.
> > 
> > Unless someone steps forward and commits to properly maintain it during the
> > lifetime of a stable release, let's not include it in buster.
> 
> I have now looked closer at this issue, and disagree that this package 
> has a bug of general neglect.  Closing this bugreport accordingly.

Whoops - I have no idea how I could manage to "investigate" but miss the 
amount of bugreports that I now see (and are not new).

Reopening. Sorry for the noise.

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Bug#921878: libcec4: Consider building libcec with Raspberry Pi support

[Bálint Réczey]

Control: forwarded -1 https://bugs.launchpad.net/raspbian/+bug/1819444

Hi,

Bálint Réczey  ezt írta (időpont: 2019. febr.
11., H, 9:51):
>
> Control: tags -1 moreinfo help
>
> Hi Patrick,
>
> Patrick Häcker  ezt írta (időpont: 2019. febr. 10., V, 2:39):
> >
> > Package: libcec4
> > Version: 4.0.4.1~stretch
> > Severity: wishlist
> >
> > Dear Maintainer,
> >
> > the Debian package of libcec does not support the Raspberry Pi's (RPI) HDMI
> > port in version 4.0.3+dfsg1-1.
> > Version 4.0.4.1~stretch in Rasbian does support it (you can find it here:
> > http://archive.raspberrypi.org/debian/pool/main/libc/libcec/).
> >
> > Please consider if it is possible to build the package with RPI support in
> > Debian, too, as done for the Rasbian package (at least on armhf).
> >
> > If you are interested in that change and want to have help, please reach me.
> > I guess it might be trivial when diffing both source packages.
>
> I'd happily accept patches.
> The diff is small:
>
> iff -Naur ../libcec/debian/rules libcec-4.0.4.1~stretch/debian/rules
> --- ../libcec/debian/rules2018-11-16 09:33:15.567861747 +0700
> +++ libcec-4.0.4.1~stretch/debian/rules2018-12-22 04:34:14.0 +0700
> @@ -1,19 +1,11 @@
>  #!/usr/bin/make -f
>
> -export DEB_BUILD_MAINT_OPTIONS = hardening=+all
> -
> -DEB_HOST_MULTIARCH ?= $(shell dpkg-architecture -qDEB_HOST_MULTIARCH)
> +# Uncomment this to turn on verbose mode.
> +#export DH_VERBOSE=1
>
>  %:
> -dh  $@ --with python2
> +dh  $@
>
> -override_dh_auto_configure:
> -ln -s /usr/include/cec-platform include/platform && \
> -dh_auto_configure -- -DCMAKE_BUILD_TYPE=Release
> -DBUILD_SHARED_LIBS=1
> -DCMAKE_INSTALL_LIBDIR=/usr/lib/$(DEB_HOST_MULTIARCH) \
> --DHAVE_EXYNOS_API=1 \
> --DHAVE_AOCEC_API=1
>
> -override_dh_auto_install:
> -dh_auto_install
> -rm debian/tmp/usr/bin/cec-client
> -mv debian/tmp/usr/bin/cec-client-* debian/tmp/usr/bin/cec-client
> +override_dh_auto_configure:
> +cmake -DRPI_INCLUDE_DIR=/opt/vc/include -DRPI_LIB_DIR=/opt/vc/lib
> -DCMAKE_BUILD_TYPE=Release -DBUILD_SHARED_LIBS=1
> -DCMAKE_INSTALL_PREFIX=/usr
>
> However whatever is in /opt it is not in Debian yet thus it can't be
> used for the armhf build.
> Please seek the inclusion of those the files in Debian if you would
> like to see them being used in the libcec build.

I have forwarded the issue to Raspbian, to help the resolution of the
legal issues around the
linked libraries.

Cheers,
Balint

>
> Please note that the libcec packages need to work on other armhf
> systems, too, when proposing changes to the packaging.
>
> Cheers,
> Balint
>
> >
> > Kind regards
> > Patrick
> >
> > -- System Information:
> > Debian Release: buster/sid
> >   APT prefers testing
> >   APT policy: (800, 'testing'), (700, 'stable'), (500, 'stable-updates')
> > Architecture: armhf (armv7l)
> >
> > Kernel: Linux 4.19.17-v7+ (SMP w/4 CPU cores)
> > Kernel taint flags: TAINT_CRAP
> > 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)
> >
> > Versions of packages libcec4 depends on:
> > ii  libc62.28-6
> > ii  libgcc1  1:8.2.0-16
> > ii  libp8-platform2  2.1.0.1+dfsg1-2
> > ii  libstdc++6   8.2.0-16
> > ii  libudev1 240-5
> > ii  libx11-6 2:1.6.7-1
> > ii  libxrandr2   2:1.5.1-1
> >
> > libcec4 recommends no packages.
> >
> > libcec4 suggests no packages.
> >
> > -- no debconf information
> >

Bug#924269: chiark-really: providing bin:sudo

[Ian Jackson]

Dmitry Bogatov writes ("Bug#924269: chiark-really: providing bin:sudo"):
> Package: chiark-really
> Version: 6.0.3
> Severity: wishlist
...
> please consider making chiark-really drop-in replacement for sudo. For
> my own purposes,
>   alias sudo='PATH=/bin:/sbin:/usr/bin:/usr/sbin /usr/sbin/really'
> is perfectly fine, but some packages pull dependency on bin:sudo
> (ubuntu-dev-tools, as example). What about making
> 
> bin:really-sudo, which provides `sudo` wrapper and Conflicts+Provides sudo?

What an interesting idea.

I definitely don't want to make this always be the case.  In general I
really hate the way that build scripts all over the universe think
they are allowed to make themselves root, and the fact that I have no
sudo is then very useful: I get some message about sudo not found,
usually followed by a pile of random junk as the script blunders on
anyway.

I wonder if maybe
  ln -s /usr/sbin/really /usr/local/sbin/sudo
would suffice for your use case ?

Ian.

Bug#924305: unblock: python-saharaclient/2.0.0-2.1

[Andreas Beckmann]

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

Please unblock package python-saharaclient

This upload fixes removal of obsolete alternatives that would otherwise
stay around after upgrades from stretch.
The NMU was just uploaded to DELAYED/5

unblock python-saharaclient/2.0.0-2.1

Andreas
diff -Nru python-saharaclient-2.0.0/debian/changelog 
python-saharaclient-2.0.0/debian/changelog
--- python-saharaclient-2.0.0/debian/changelog  2018-09-04 22:45:05.0 
+0200
+++ python-saharaclient-2.0.0/debian/changelog  2019-03-11 12:08:08.0 
+0100
@@ -1,3 +1,10 @@
+python-saharaclient (2.0.0-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Remove obsolete alternatives on upgrade.  (Closes: #910224)
+
+ -- Andreas Beckmann   Mon, 11 Mar 2019 12:08:08 +0100
+
 python-saharaclient (2.0.0-2) unstable; urgency=medium
 
   * Uploading to unstable.
diff -Nru python-saharaclient-2.0.0/debian/python-saharaclient.postinst 
python-saharaclient-2.0.0/debian/python-saharaclient.postinst
--- python-saharaclient-2.0.0/debian/python-saharaclient.postinst   
1970-01-01 01:00:00.0 +0100
+++ python-saharaclient-2.0.0/debian/python-saharaclient.postinst   
2019-03-11 11:31:00.0 +0100
@@ -0,0 +1,8 @@
+#!/bin/sh
+set -e
+
+if [ "$1" = "configure" ] ; then
+   update-alternatives --remove sahara /usr/bin/python2-sahara
+fi
+
+#DEBHELPER#
diff -Nru python-saharaclient-2.0.0/debian/python3-saharaclient.postinst 
python-saharaclient-2.0.0/debian/python3-saharaclient.postinst
--- python-saharaclient-2.0.0/debian/python3-saharaclient.postinst  
1970-01-01 01:00:00.0 +0100
+++ python-saharaclient-2.0.0/debian/python3-saharaclient.postinst  
2019-03-11 11:31:08.0 +0100
@@ -0,0 +1,8 @@
+#!/bin/sh
+set -e
+
+if [ "$1" = "configure" ] ; then
+   update-alternatives --remove sahara /usr/bin/python3-sahara
+fi
+
+#DEBHELPER#

Bug#924304: bumpversion depends on python3-pkg-resources

[Dejan Muhamedagic]

Package: bumpversion
Version: 0.5.10-1
Severity: normal

Dear Maintainer,

Running bumpversion I ran into this error:

root@isar:~# bumpversion 
Traceback (most recent call last):
  File "/usr/bin/bumpversion", line 6, in 
from pkg_resources import load_entry_point
ModuleNotFoundError: No module named 'pkg_resources'

Installing python3-pkg-resources fixed the problem. Is this just
a missing dependency?

Best regards,

Dejan


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

Kernel: Linux 4.19.0-2-rt-amd64 (SMP w/4 CPU cores; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.utf8 (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 bumpversion depends on:
ii  python3  3.7.2-1

bumpversion recommends no packages.

bumpversion suggests no packages.

-- no debconf information

Bug#919395: Heads up to release team about MariadB 10.3

[Emilio Pozuelo Monfort]

On 08/03/2019 12:48, Andreas Beckmann wrote:
> On 2019-01-31 13:55, Andreas Beckmann wrote:
>> There is one package not covered by the tracker since it only 
>> indirectly depends on default-libmysqlclient-dev.
>>
>> nmu kannel-sqlbox_0.7.2-5 . ANY . unstable . -m "Rebuild against libmariadb3"
> 
> Ping?
> 
> And please give-back lua-sql, the FTBFS is fixed with that latest
> mariadb-10.3 upload.
> 
> 
> Andreas
> 

Bug#924254: dmtx-utils: diff for NMU version 0.7.6-1.1

[Roberto Lumbreras]

Yes, go ahead.

On Mon, Mar 11, 2019 at 10:30 AM Simon McVittie  wrote:

> On Mon, 11 Mar 2019 at 10:09:21 +0100, Roberto Lumbreras wrote:
> > You can reschedule it to unstable without delay.
>
> Thanks, rescheduled.
>
> My changes to libdmtx are waiting in the NEW queue. When they get accepted,
> may I re-upload to unstable as soon as the release team are ready for the
> transition?
>
> Thanks,
> smcv
>


-- 
Regards,
Roberto Lumbreras
Debian developer

Bug#923312: gnome-terminal ignores system ulimits

[Harald Dunkel]

Hi Simon,

On 3/11/19 10:04 AM, Simon McVittie wrote:


I assume from the version that you're using stretch? Please report
bugs with reportbug whenever possible, that way I'd already have this
information.



ACK



Do you have a line for pam_limits.so in /etc/pam.d/systemd-user?



Yes.


Do you have unmerged local changes for /etc/pam.d/systemd-user,
with a version containing "session required pam_limits.so" in
/etc/pam.d/systemd-user.dpkg-dist? If you do, please merge the changes
in the distributed version into your local version.



No.


After making sure you have "session required pam_limits.so" in
/etc/pam.d/systemd-user, do these commands, run from an ordinary
non-root login session:

 prlimit -p $(pgrep -u $(id -u) -f "systemd --user")
 prlimit -p $(pgrep -u $(id -u) -f "dbus-daemon --session")

report the limits you would expect?



No, I get 1024/4096 for nofiles. /etc/security/limits.d/local.conf
says

* soft nofile 4096
* hard nofile 16584
root soft nofile 4096
root hard nofile 16584

/proc/$$/limits shows the expected limits, unless gnome-terminal is
involved.

systemd is version 232-25+deb9u9


Regards
Harri

Bug#915333: git-annex: Illegal Instruction on armel (Fujitsu Q700 like QNAP TS-21x/TS-22x)

[Adrian Bunk]

Control: severity -1 serious
Control: reassign -1 ghc 8.4.4+dfsg1-1
Control: affects -1 git-annex

On Thu, Jan 31, 2019 at 08:12:17PM +0100, Bernhard Übelacker wrote:
> Hello Everyone,
> I own a qnap ts-119pII with a similar cpu.
> 
> See attached file with several debugging attempts.

Thanks a lot for this.

>...
> If I read [1] right, then the UXTH instruction is just supported
> on ARMv6 or later.

Looking at the code, the bug seems to be in
https://sources.debian.org/src/ghc/8.4.4+dfsg1-2/debian/patches/llvm-arm-unknown-linux-gnueabi.patch/

ARM1136JF-S is ARM11, which is ARMv6.

arm9e would be correct here instead of arm1136jf-s.

Due to the static-only nature of the ghc ecosystem the fix would then 
require a complete rebuild of all Haskell packages on armel, but with
the buildds otherwise mostly idle now this should be finished within
2-3 days.

> Kind regards,
> Bernhard
>
> [1] http://infocenter.arm.com/help/topic/com.arm.doc.dui0489i/CIHHJCFE.html

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#924303: fonts-noto-core: creates an obsolete config file

[Laurent Bonnaud]

Package: fonts-noto-core
Version: 20181227-1
Severity: normal


Dear Maintainer,

here is the problem:

$ dpkg-query -W -f='${Conffiles}\n' | grep obsolete$
 /etc/fonts/conf.avail/30-droid-noto.conf a34074694dce0a5ccc5844ec0a1315ea 
obsolete


-- Package-specific info:
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name   Version  Architecture Description
+++-==---=
ii  fontconfig 2.13.1-2 amd64generic font configuration 
library - support binaries
ii  libfreetype6:amd64 2.9.1-3  amd64FreeType 2 font engine, shared 
library files
ii  libxft2:amd64  2.3.2-2  amd64FreeType-based font drawing 
library for X

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

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

-- Configuration Files:
/etc/fonts/conf.avail/30-droid-noto.conf [Errno 2] No such file or directory: 
'/etc/fonts/conf.avail/30-droid-noto.conf'

-- no debconf information

-- 
Laurent.

Bug#918012: fix docker-compose in backports

[Marcel Partap]

Just ran into this. So basically, "someone" only has to kick up the dependency 
of docker-compose to python3-docker (>= 3.2.1). Thanks @someone 

Bug#924254: dmtx-utils: diff for NMU version 0.7.6-1.1

[Simon McVittie]

On Mon, 11 Mar 2019 at 10:09:21 +0100, Roberto Lumbreras wrote:
> You can reschedule it to unstable without delay.

Thanks, rescheduled.

My changes to libdmtx are waiting in the NEW queue. When they get accepted,
may I re-upload to unstable as soon as the release team are ready for the
transition?

Thanks,
smcv

Bug#924302: virtualbox: ignores parallel=n setting in DEB_BUILD_OPTIONS

[Andreas Beckmann]

Source: virtualbox
Version: 6.0.4-dfsg-7
Severity: important

Hi,

virtualbox seems to ignore DEB_BUILD_OPTIONS=parallel=3
I just noticed it compiling 8 files in parallel - not a good idea if
multiple different builds are supposed to be running in parallel.
(nproc reports 8 cpus on that machine)


Andreas

Bug#585905: Apache Cassandra depends on Apache Hadoop

[Andrius Merkys]

Control: block -1 by 793644

Hello,

I am looking into packaging of Apache Cassandra now. It seems to depend
on Apache Hadoop as of v3.11.4:

    [javac]
/home/andrius/debian-packages/cassandra/src/java/org/apache/cassandra/client/RingCache.java:32:
error: package org.apache.hadoop.conf does not exist
    [javac] import org.apache.hadoop.conf.Configuration;
    [javac]
/home/andrius/debian-packages/cassandra/src/java/org/apache/cassandra/hadoop/ColumnFamilySplit.java:20:
error: package org.apache.hadoop.io does not exist
    [javac] import org.apache.hadoop.io.Writable;
    [javac]
/home/andrius/debian-packages/cassandra/src/java/org/apache/cassandra/hadoop/ColumnFamilySplit.java:21:
error: package org.apache.hadoop.mapreduce does not exist
    [javac] import org.apache.hadoop.mapreduce.InputSplit;

And so on. So this is to mark the fact.

Best,
Andrius

Bug#850425: mpt3sas "swiotlb buffer is full" problem only under Xen

[Andrew Cooper]

On 10/03/2019 23:12, Hans van Kranenburg wrote:
> On 3/10/19 11:03 PM, Andrew Cooper wrote:
>> On 10/03/2019 21:35, Hans van Kranenburg wrote:
>>> [...]
>>>
>>> Using dom0_mem=2GiB,max:4GiB instead of dom0_mem=2GiB,max:2GiB (which I
>>> started with) makes the errors go away, so workaround confirmed.
> It's actually dom0_mem=2G,max:4G, I typed something before which was not
> identical to what I started that machine with.
>
>>> [...]
>>> I think I'm fine with this workaround.
>> I think
>> https://lists.xen.org/archives/html/xen-devel/2014-12/msg00699.html is
>> the last attempt David made to upstream the fixes.
>>
>> Linux is still broken, and these fixes are still necessary.
> FMI, is this max:4G DTRT for me now in the meantime, or am I still
> facing more hidden problems while using this workaround?

I believe that is good enough to work around the problem.  The issue is
that the these drivers are using dom0's max ram (well - max pfn to be
specific) to decide whether it reports itself as 32bit or 64bit DMA
capable, which is nonsense.

Therefore, if dom0 thinks it has less that 4G of potential RAM, the
driver reports the device as only 32-bit capable, and bounce-buffers all
of its DMA (as dom0 is generally allocated above the 4G boundary in
physical address space).

~Andrew

Bug#924254: dmtx-utils: diff for NMU version 0.7.6-1.1

[Roberto Lumbreras]

Hi Simon,

You can reschedule it to unstable without delay.
As soon I have a time slot I'll work on the package to merge in your
changes,
but in the meantime it's good to have all of it fixed.
Thank you very much for your help!

On Sun, Mar 10, 2019 at 6:24 PM Simon McVittie  wrote:

> Control: tags 924254 + pending
>
> Dear maintainer,
> To unblock #908815, I've prepared an NMU for dmtx-utils (versioned as
> 0.7.6-1.1) and uploaded it to DELAYED/7. Please feel free to tell me if
> I should delay or cancel it, or alternatively if I should reschedule it
> to go into unstable without delay.
>
> Regards,
> smcv
>


-- 
Regards,
Roberto Lumbreras
Debian developer

Bug#923312: gnome-terminal ignores system ulimits

[Simon McVittie]

Control: reassign -1 systemd
Control: affects -1 + dbus-user-session

On Tue, 26 Feb 2019 at 08:24:07 +0100, Harald Dunkel wrote:
> Package: gnome-terminal
> Version: 3.22.2-1

I assume from the version that you're using stretch? Please report
bugs with reportbug whenever possible, that way I'd already have this
information.

> My /etc/security/limits.d/local.conf says
> 
>   * soft nofile 4096
>   * hard nofile 16584
>   root soft nofile 4096
>   root hard nofile 16584
> 
> But within gnome-terminal I just get
> 
>   % egrep ^Limit\|open /proc/$$/limits
>   Limit Soft Limit   Hard Limit   
> Units
>   Max open files1024 4096 
> files

This seems a lot like #838191 "systemd user units do not honor resource
limits set in /etc/security/limits.conf" in systemd; but that bug was
fixed in 231-8, so it should already be fixed in stretch.

Do you have a line for pam_limits.so in /etc/pam.d/systemd-user?

Do you have unmerged local changes for /etc/pam.d/systemd-user,
with a version containing "session required pam_limits.so" in
/etc/pam.d/systemd-user.dpkg-dist? If you do, please merge the changes
in the distributed version into your local version.

After making sure you have "session required pam_limits.so" in
/etc/pam.d/systemd-user, do these commands, run from an ordinary
non-root login session:

prlimit -p $(pgrep -u $(id -u) -f "systemd --user")
prlimit -p $(pgrep -u $(id -u) -f "dbus-daemon --session")

report the limits you would expect?

(The good news is that you won't need most of this configuration in
buster, because buster's systemd sets fs.nr_open, fs.file-max and the
hard limit for RLIMIT_NOFILE to be very large by default. See systemd's
NEWS file for more information about this: in particular, they recommend
leaving the soft limit set to 1024 for compatibility with select(),
with individual programs that need lots of fds and are known not to use
select() raising their fd limit as needed.)

On Tue, 26 Feb 2019 at 15:22:47 +0100, Harald Dunkel wrote:
> Apparently this comes up only, if dbus-user-session (1.10.26-0+deb9u1)
> is involved.

That's because if you have dbus-user-session, `dbus-daemon --session`
becomes a systemd user service that is outside the scope of any of your
login sessions (and so do all the activatable services that it starts,
like gnome-terminal-server), so they inherit their rlimits from the
rlimit of `systemd --user`, not from the rlimit of whatever service
processed your login (typically xdm/gdm/etc., sshd or login). In PAM
terms, that's /etc/pam.d/systemd-user.

Regards,
smcv

Bug#924301: e2fsprogs: e2scrub failure on /

[Vincent Lefevre]

Package: e2fsprogs
Version: 1.45.0-1
Severity: normal

I got the following mail:


Date: Sun, 10 Mar 2019 03:10:04 +0100 (CET)
From: e2sc...@zira.vinc17.org
To: r...@zira.vinc17.org
Subject: e2scrub failure on /

So sorry, the automatic e2scrub of / on zira.vinc17.org failed.

A log of what happened follows:
??? e2scrub@-.service - Online ext4 Metadata Check for /
   Loaded: loaded (/lib/systemd/system/e2scrub@.service; static; vendor preset: 
enabled)
   Active: failed (Result: exit-code) since Sun 2019-03-10 03:10:04 CET; 28ms 
ago
 Docs: man:e2scrub(8)
  Process: 5133 ExecStart=/sbin/e2scrub -t / (code=exited, status=1/FAILURE)
 Main PID: 5133 (code=exited, status=1/FAILURE)

Mar 10 03:10:01 zira systemd[1]: Starting Online ext4 Metadata Check for /...
Mar 10 03:10:01 zira e2scrub@-[5133]:   Volume group "zira-vg" has insufficient 
free space (0 extents): 64 required.
Mar 10 03:10:01 zira e2scrub@-[5133]: /: e2scrub snapshot FAILED, will not 
check!
Mar 10 03:10:04 zira systemd[1]: e2scrub@-.service: Main process exited, 
code=exited, status=1/FAILURE
Mar 10 03:10:04 zira systemd[1]: e2scrub@-.service: Failed with result 
'exit-code'.
Mar 10 03:10:04 zira systemd[1]: Failed to start Online ext4 Metadata Check for 
/.
Mar 10 03:10:04 zira systemd[1]: e2scrub@-.service: Triggering OnFailure= 
dependencies.


df shows:

/dev/mapper/zira--vg-root 471942448 240303032 207643000  54% /

so the disk is not near full.

This apparently comes from the latest change in e2fsprogs:

e2fsprogs (1.45.0-1) unstable; urgency=medium
[...]
  * There is now an e2scrub script which will allow e2fsck to be run
on mounted file systems using an LVM device.  There will be a systemd
script to automatically run e2scrub on all ext4* file systems where it
can be supported.
[...]
 -- Theodore Y. Ts'o   Wed, 06 Mar 2019 12:55:18 -0500

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

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

Versions of packages e2fsprogs depends on:
ii  libblkid12.33.1-0.1
ii  libc62.28-8
ii  libcom-err2  1.45.0-1
ii  libext2fs2   1.45.0-1
ii  libss2   1.45.0-1
ii  libuuid1 2.33.1-0.1

Versions of packages e2fsprogs recommends:
ii  e2fsprogs-l10n  1.45.0-1
ii  lvm22.03.02-2

Versions of packages e2fsprogs suggests:
pn  e2fsck-static  
pn  fuse2fs
pn  gpart  
ii  parted 3.2-24

-- no debconf information

Bug#633815: MICROSOFT LOPPU VAROITUS

[Lotta Hagelberg]

Päivitä tilisi

Tietueemme osoittaa, että tiliäsi ei ole päivitetty, mikä saattaa johtaa tilisi 
lopettamiseen. Jos et päivitä tiliäsi, et voi enää lähettää
 ja vastaanottaa sähköpostiviestejä, ja et saa myös pääsyä moniin uusimpiin 
kehittyneisiin keskusteluihimme, yhteystietoihin ja liitteisiin.

Päivitä tili nopeammin ja täydellisemmällä postikokemuksella.

Päivitä tilisi napsauttamalla tätä.?
Huomautus: Jos et päivitä postilaatikkoa, tilisi poistetaan pysyvästi.

Kiitos paljon,
käyttäjältä Turvallisuusryhmä.

Tekijänoikeus © 2019 Webmail .Inc. Kaikki oikeudet pidätetään.

?

Bug#923931: upgrade breaks old containers

[Harald Dunkel]

Hi Pierre,

On 3/8/19 2:30 PM, Pierre-Elliott Bécue wrote:


I'm sorry, but lxc-templates is not needed to have lxc3 working, so it
won't become a Dependency. Moving the files from src:lxc-templates to
src:lxc and subsequently creating two DS uploads is not a fine solution
either.



lxc-templates is necessary for a successful migration of the containers
generated on Stretch. I do not know what else I can say about this.


Regards
Harri

Bug#902493: apache2-bin: Event MPM listener thread may get blocked by SSL shutdowns

[Sven Hartge]

Um 08:56 Uhr am 11.03.19 schrieb Sven Hartge:

> I am going to test these package on the systems which have shown to be 
> hit by regularly this problem here, so I am confident I will be able to 
> report within two weeks if there have been any problems and if your 
> change did indeed fix the problem.

This breaks quite fast, resulting in apache2 processes at 100% CPU, doing 
nothing but:

[pid 116644] epoll_ctl(26, EPOLL_CTL_DEL, -1, 0x7fbf20fe8d50) = -1 EBADF (Bad 
file descriptor)
[pid 116644] epoll_ctl(26, EPOLL_CTL_DEL, -1, 0x7fbf20fe8d50) = -1 EBADF (Bad 
file descriptor)
[pid 116644] epoll_ctl(26, EPOLL_CTL_DEL, -1, 0x7fbf20fe8d50) = -1 EBADF (Bad 
file descriptor)
[pid 116644] epoll_ctl(26, EPOLL_CTL_DEL, -1, 0x7fbf20fe8d50) = -1 EBADF (Bad 
file descriptor)
[pid 116644] epoll_ctl(26, EPOLL_CTL_DEL, -1, 0x7fbf20fe8d50) = -1 EBADF (Bad 
file descriptor)
[pid 116644] epoll_ctl(26, EPOLL_CTL_DEL, -1, 0x7fbf20fe8d50) = -1 EBADF (Bad 
file descriptor)
[pid 116644] epoll_ctl(26, EPOLL_CTL_DEL, -1, 0x7fbf20fe8d50) = -1 EBADF (Bad 
file descriptor)
[pid 116644] epoll_ctl(26, EPOLL_CTL_DEL, -1, 0x7fbf20fe8d50) = -1 EBADF (Bad 
file descriptor)
[pid 116644] epoll_ctl(26, EPOLL_CTL_DEL, -1, 0x7fbf20fe8d50) = -1 EBADF (Bad 
file descriptor)
[pid 116644] epoll_ctl(26, EPOLL_CTL_DEL, -1, 0x7fbf20fe8d50) = -1 EBADF (Bad 
file descriptor)
[pid 116644] epoll_ctl(26, EPOLL_CTL_DEL, -1, 0x7fbf20fe8d50) = -1 EBADF (Bad 
file descriptor)
[pid 116644] epoll_ctl(26, EPOLL_CTL_DEL, -1, 0x7fbf20fe8d50) = -1 EBADF (Bad 
file descriptor)
[pid 116644] epoll_ctl(26, EPOLL_CTL_DEL, -1, 0x7fbf20fe8d50) = -1 EBADF (Bad 
file descriptor)
[pid 116644] epoll_ctl(26, EPOLL_CTL_DEL, -1, 0x7fbf20fe8d50) = -1 EBADF (Bad 
file descriptor)
[pid 116644] epoll_ctl(26, EPOLL_CTL_DEL, -1, 0x7fbf20fe8d50) = -1 EBADF (Bad 
file descriptor)
[pid 116644] epoll_ctl(26, EPOLL_CTL_DEL, -1, 0x7fbf20fe8d50) = -1 EBADF (Bad 
file descriptor)
[pid 116644] epoll_ctl(26, EPOLL_CTL_DEL, -1, 0x7fbf20fe8d50) = -1 EBADF (Bad 
file descriptor)
[pid 116644] epoll_ctl(26, EPOLL_CTL_DEL, -1, 0x7fbf20fe8d50) = -1 EBADF (Bad 
file descriptor)
[pid 116644] epoll_ctl(26, EPOLL_CTL_DEL, -1, 0x7fbf20fe8d50) = -1 EBADF (Bad 
file descriptor)
[pid 116644] epoll_ctl(26, EPOLL_CTL_DEL, -1, 0x7fbf20fe8d50) = -1 EBADF (Bad 
file descriptor)

Grüße,
Sven.

Bug#924292: btrfs-compsize FTCBFS: does not pass cross tools to make

[Adam Borowski]

Control: tags -1 +pending

On Mon, Mar 11, 2019 at 06:25:41AM +0100, Helmut Grohne wrote:
> Source: btrfs-compsize

> 
> btrfs-compsize fails to cross build from source, because it does not
> pass cross tools to make. The easiest way of fixing that - using
> dh_auto_build - makes btrfs-compsize cross buildable. Please consider
> applying the attached patch.

>  override_dh_auto_build:
> - +$(MAKE) $(shell dpkg-buildflags --export=cmdline)
> + dh_auto_build -- $(shell dpkg-buildflags --export=cmdline)


Applied, thanks!  Alas, we're in the freeze...


Meow.
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋⠀ Have you accepted Khorne as your lord and saviour?
⠈⠳⣄

Bug#924300: libnglib-6.2.1804: ldconfig does not find netgen shared object files

[Sebastian Bachmann]

Package: libnglib-6.2.1804
Version: 6.2.1804+dfsg1-3
Severity: normal

Dear Maintainer,

I used netgen to build FreeCAD but without setting LD_LIBRARY_PATH, FreeCAD's
FEM workbench does not start up, as the required netgen libraries are not found
by ldconfig:

$ dpkg -L libnglib-6.2.1804:amd64
/.
/usr
/usr/lib
/usr/lib/x86_64-linux-gnu
/usr/lib/x86_64-linux-gnu/netgen
/usr/lib/x86_64-linux-gnu/netgen/libcsg.so

# ldconfig -p | grep libcsg
# echo $?
1

It looks like the problem is, that netgen installs itself into the netgen
folder but does not provide symlinks to the parent folder or a ld.so.conf.

The problem can be worked around by starting FreeCAD with a LD_LIBRARY_PATH set
to the netgen folder.

regards
Sebastian



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

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

Versions of packages libnglib-6.2.1804 depends on:
ii  libc62.28-8
ii  libgcc1  1:8.3.0-2
ii  libgl1   1.1.0-1
ii  libglu1-mesa [libglu1]   9.0.0-2.1
ii  libmetis55.1.0.dfsg-5+b2
ii  libocct-data-exchange-7.37.3.0+dfsg1-5
ii  libocct-foundation-7.3   7.3.0+dfsg1-5
ii  libocct-modeling-algorithms-7.3  7.3.0+dfsg1-5
ii  libocct-modeling-data-7.37.3.0+dfsg1-5
ii  libocct-ocaf-7.3 7.3.0+dfsg1-5
ii  libocct-visualization-7.37.3.0+dfsg1-5
ii  libopenmpi3  3.1.3-10
ii  libpython3.7 3.7.2-3
ii  libstdc++6   8.3.0-2
ii  libtcl8.68.6.9+dfsg-2
ii  libtk8.6 8.6.9-2
ii  libx11-6 2:1.6.7-1
ii  libxmu6  2:1.1.2-2
ii  zlib1g   1:1.2.11.dfsg-1

libnglib-6.2.1804 recommends no packages.

libnglib-6.2.1804 suggests no packages.

-- no debconf information

Bug#924299: ITP: mpi4py-fft -- a Python package for computing Fast Fourier Transforms (FFTs)

[Drew Parsons]

Package: wnpp
Severity: wishlist
Owner: Drew Parsons 

* Package name: mpi4py-fft
  Version : 2.0.0
  Upstream Author : Lisandro Dalcin , Mikael Mortensen 

* URL : https://bitbucket.org/mpi4py/mpi4py-fft/src
* License : BSD-2-clause
  Programming Lang: Python
  Description : a Python package for computing Fast Fourier Transforms 
(FFTs)

mpi4py-fft is a Python package for computing Fast Fourier Transforms
(FFTs). Large arrays are distributed and communications are handled
under the hood by MPI for Python (mpi4py). To distribute large arrays
we are using a new and completely generic algorithm that allows for
any index set of a multidimensional array to be distributed. We can
distribute just one index (a slab decomposition), two index sets
(pencil decomposition) or even more for higher-dimensional arrays.

In mpi4py-fft there is also included a Python interface to the FFTW
library. This interface can be used without MPI, much like pyfftw, and
even for real-to-real transforms, like discrete cosine or sine
transforms.

The package, like pyfftw, provides a Python interface to FFTW, but
with MPI parallelisation. This enables strong scaling tested to 16000
cores, or weak scaling tested to 2000 cores. The algorithm is
documented at https://arxiv.org/abs/1804.09536

Packaging is expected to be maintained under the Debian Science team.

Bug#924124: unblock: virtualbox/6.0.4-dfsg-7

[Gianfranco Costamagna]

control: retitle -1 unblock: virtualbox/6.0.4-dfsg-7

I had to add a new patch for the guest tools, following removals of ttm structs

https://github.com/torvalds/linux/commit/a64f784bb14a56bfdfad2dc397dd67e4564e3a29
and 
https://github.com/torvalds/linux/commit/2bb42410b1bd324912389c6ac748df1c1befd69f

and I added the previous missing changelog entry.

Please unblock virtualbox/6.0.4-dfsg-7

thanks

Gianfranco

Bug#923397: known issue with upstream bug report

[Tycho Lürsen]

Hi, as the subject says, this is a known issue ( see 
https://bugzilla.redhat.com/show_bug.cgi?id=1652992 )


and it has a upstream bugreport ( see 
https://sourceforge.net/p/lirc/tickets/341/ )


Hope that helps.

Regards, Tycho

Bug#924298: please document configuration data

[Marc Haber]

Package: tlp
Version: 1.1-2
Severity: wishlist

Hi,

powertop is sometimes overzealous to report configuration as "bad" while
it isn't. Especially "interesting" cases are SATA link power management
(where med_power_with_dipm is flaged as 'Bad') and VM writeback timeout
(where anything != the powertop-decided 1500 is 'Bad').

I have just spent time to find out from the tlp code that it's the value
of MAX_LOST_WORK_SECS_ON_BAT that get written to the
dirty_writeback_centisecs value that powertop wants to be 14500 to
badly. I was therefore able to determine that powertop is wrong here.

Please consider writing into /etc/default/tlp information, which
sysfs/procfs/other values are affected by a certain setting to make
things easier for people without them having to look at the code.

Thanks for providing tlp!

Greetings
Marc

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

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

Versions of packages tlp depends on:
ii  hdparm  9.58+ds-1
ii  iw  5.0.1-1
ii  lsb-base10.2018112800
ii  pciutils1:3.5.2-1
ii  rfkill  2.33.1-0.1
ii  usbutils1:010-3
ii  wireless-tools  30~pre9-13

Versions of packages tlp recommends:
ii  ethtool 1:4.19-1
ii  linux-cpupower  4.19.20-1
ii  tlp-rdw 1.1-2

Versions of packages tlp suggests:
ii  acpi-call-dkms  1.1.0-4
ii  smartmontools   6.6-1
pn  tp-smapi-dkms   

-- Configuration Files:
/etc/default/tlp changed [not included]

-- no debconf information

Bug#924192: ntpsec: at boot ntpsec starts before DNS is available

[Rick Thomas]

> On Mar 11, 2019, at 12:46 AM, Rick Thomas  wrote:
> 
> Examining the journal carefully, (specifically the lines labeled “Mar 11 
> 00:23:44”,
> it looks like the [Install] stanza isn’t the right place to put the “After” 
> “Wants” lines.
> 
> I’ll keep looking for a more appropriate place.  If you have any suggestions, 
> please share them.

Hmmm… Something like those two lines are already present in the [Unit] section 
of /lib/systemd/system/ntpsec.service 
but they are looking for “network.target” rather than “network-online.target”

I tried changing network => network-online (and doing “update-initramfs -u”) 
but to no avail.
Same results, but without the complaint about them being in an inappropriate 
place.

We’ll keep trying.

Rick

Bug#924297: elpa-eshell-git-prompt: missing-powerline-fonts

[Salman Mohammadi]

Package: elpa-eshell-git-prompt
Version: 0.1.2-2
Severity: normal

Dear Maintainer,

choosing powerline theme for the eshell requires the package
`fonts-powerline` otherwise the intended symbols in the eshell prompt
could not be shown.

I suggest you use `fonts-powerline` as a recommendation for this package.


Steps to reproduce:

1. Install elpa-eshell-git-prompt from the repo

2. use the following line of code in the init file

(eshell-git-prompt-use-theme 'powerline)

3. run eshell


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

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

Versions of packages elpa-eshell-git-prompt depends on:
ii elpa-dash 2.14.1+dfsg-1
ii emacsen-common 3.0.4

Versions of packages elpa-eshell-git-prompt recommends:
ii emacs 1:26.1+1-3.2
ii emacs-gtk [emacs] 1:26.1+1-3.2

elpa-eshell-git-prompt suggests no packages.

-- no debconf information

Bug#922031: Timer Disabling on Package Update? (is: #922031)

[Michael Biebl]

Am 10.03.19 um 17:54 schrieb Michael Biebl:
> Am 10.03.19 um 17:36 schrieb Harlan Lieberman-Berg:
>> On Sun, Mar 10, 2019 at 12:29 PM Michael Biebl  wrote:
>>> Can you provide the output of
>>> systemctl status certbot.timer
>>> journalctl -u certbot.timer
>>
>> The output of `systemctl show certbot.timer` is at
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=922031;filename=systemctl-show-certbot.timer.txt;msg=20
>> .  One of the reporters will have to follow up with the output of
>> journalctl -u certbot.timer, as I can't replicate the problem.
>>
>>> Is certbot.timer restarted as part of the package update?
>>
>> Not unless dh_installsystemd is doing it automagically, no.
> 
> I had a quick look, it's a bug in your package.
> What happens is roughly this:
> 
> 0.12 used and older compat level where
> dh_systemd_start defaults to stop in old/prerm, and start in
> new/postinst. So during the upgrade, certbot.prerm stops certbot.timer.
> 
> Your newer certbot package uses a newer compat level which defaults to
> restart after upgrade.
> If you check /var/lib/dpkg/info/certbot.postinst, you'll see a
> systemctl try-restart certbot-timer.

So, I need to clarify this a bit.
dh_systemd_start (or dh_installsystemd) is supposed to use
"systemctl restart" for --restart-after-upgrade (the default action with
compat 10 and above).
In your case, dh_systemd_start generated code which uses
"systemctl try-restart", which is an important difference.
"try-restart" is a nop if the unit is not already running, "restart"
will start the unit in such a case.

Now, dh_systemd_start is only supposed to use "try-restart" as action
when used in combination with "--no-start". You only use that for
certbot.service though and not for certbot.timer.

It seems dh_systemd_start in stable get's confused by

override_dh_systemd_start:
   dh_systemd_start --package=certbot certbot.timer
   dh_systemd_start --package=certbot --no-start certbot.service


and generates this imo faulty code.
I also checked  dh_systemd_start in buster which does the expected thing
here.

This doesn't really change anything regarding that the best fix is to
simply roll back the compat level to 9 in certbot for the stable upload.

The takeaway here is, that it helps to check the generated maintainer
scripts code, especially when you do a compat level bump.

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



signature.asc
Description: OpenPGP digital signature

Bug#902493: apache2-bin: Event MPM listener thread may get blocked by SSL shutdowns

[Sven Hartge]

On 10.03.19 12:51, Stefan Fritsch wrote:

> I am not comfortable with switching to mpm_worker, either, since this would 
> be 
> a significant behavior change.
> 
> I have however tried a backport of the patch referenced in the upstream bug 
> report and put a build here:
> 
> https://people.debian.org/~sf/apache2-mpm-event-902493/2.4.25-3+deb9u7~test1/
> (sha256 sums below)
> 
> I don't think that I will put this patch into the next point release (9.9), 
> but if there are a fair number of people who test this on their systems and 
> report back, I may consider it for the 9.10 point release. So, please test 
> this and report back after maybe 1-2 weeks.
> 
> * if it fixes the bug
> * if you have seen any new issues
> * on how many systems and how long you have tested it and how much load 
> (requests/day) those systems see

Thank you.

I am going to test these package on the systems which have shown to be
hit by regularly this problem here, so I am confident I will be able to
report within two weeks if there have been any problems and if your
change did indeed fix the problem.

Grüße,
Sven.



signature.asc
Description: OpenPGP digital signature

Bug#924192: ntpsec: at boot ntpsec starts before DNS is available

[Rick Thomas]

Hi Tony!

I’m not sure if I’m doing it right, but here’s what I did and what happened…

What I did:

Edited /lib/systemd/system/ntpsec-systemd-netif.path
Here’s a diff
> rbthomas@cube:~$ diff -c2 /SAVE//lib/systemd/system/ntpsec-systemd-netif.path 
> /lib/systemd/system/ntpsec-systemd-netif.path
> *** /SAVE//lib/systemd/system/ntpsec-systemd-netif.path   Mon Mar 11 
> 00:20:38 2019
> --- /lib/systemd/system/ntpsec-systemd-netif.path Mon Mar 11 00:21:33 2019
> ***
> *** 7,9 
>   
>   [Install]
> ! WantedBy=network-pre.target
> --- 7,10 
>   
>   [Install]
> ! After=network-online.target
> ! Wants=network-online.target
> rbthomas@cube:~$ 


Then i did
> root@cube:~# update-initramfs -u

and rebooted.

What happened:

I still get only the servers from the last “path” statement
.
Here’s what the journal says:
> rbthomas@cube:~$ journalctl -b | grep ntp
> Mar 11 00:23:43 cube kernel: Mountpoint-cache hash table entries: 2048 
> (order: 1, 8192 bytes)
> Mar 11 00:23:44 cube systemd[1]: 
> /lib/systemd/system/ntpsec-systemd-netif.path:7: Unknown lvalue 'After' in 
> section 'Install', ignoring
> Mar 11 00:23:44 cube systemd[1]: 
> /lib/systemd/system/ntpsec-systemd-netif.path:8: Unknown lvalue 'Wants' in 
> section 'Install', ignoring
> Mar 11 00:23:48 cube kernel: audit: type=1400 audit(1552289028.492:6): 
> apparmor="STATUS" operation="profile_load" profile="unconfined" 
> name="/usr/sbin/ntpd" pid=297 comm="apparmor_parser"
> Mar 11 00:23:48 cube audit[297]: AVC apparmor="STATUS" 
> operation="profile_load" profile="unconfined" name="/usr/sbin/ntpd" pid=297 
> comm="apparmor_parser"
> Mar 11 00:23:49 cube ntpd[350]: INIT: ntpd ntpsec-1.1.3 2019-02-04T07:38:48Z: 
> Starting
> Mar 11 00:23:50 cube ntp-systemd-wrapper[345]: 2019-03-11T00:23:49 ntpd[350]: 
> INIT: ntpd ntpsec-1.1.3 2019-02-04T07:38:48Z: Starting
> Mar 11 00:23:50 cube ntp-systemd-wrapper[345]: 2019-03-11T00:23:49 ntpd[350]: 
> INIT: Command line: /usr/sbin/ntpd -p /run/ntpd.pid -c /etc/ntpsec/ntp.conf 
> -g -N -u ntpsec:ntpsec
> Mar 11 00:23:49 cube systemd[1]: ntpsec.service: Can't open PID file 
> /run/ntpd.pid (yet?) after start: No such file or directory
> Mar 11 00:23:49 cube ntpd[350]: INIT: Command line: /usr/sbin/ntpd -p 
> /run/ntpd.pid -c /etc/ntpsec/ntp.conf -g -N -u ntpsec:ntpsec
> Mar 11 00:23:49 cube ntpd[354]: INIT: precision = 1.667 usec (-19)
> Mar 11 00:23:49 cube systemd[1]: Starting Wait for ntpd to synchronize system 
> clock...
> Mar 11 00:23:50 cube ntpd[354]: INIT: successfully locked into RAM
> Mar 11 00:23:50 cube ntpd[354]: CONFIG: readconfig: parsing file: 
> /etc/ntpsec/ntp.conf
> Mar 11 00:23:50 cube ntpd[354]: CLOCK: leapsecond file 
> ('/usr/share/zoneinfo/leap-seconds.list'): good hash signature
> Mar 11 00:23:50 cube ntpd[354]: CLOCK: leapsecond file 
> ('/usr/share/zoneinfo/leap-seconds.list'): loaded, expire=2019-06-28T00:00Z 
> last=2017-01-01T00:00Z ofs=37
> Mar 11 00:23:50 cube ntpd[354]: INIT: Using SO_TIMESTAMPNS
> Mar 11 00:23:50 cube ntpd[354]: IO: Listen and drop on 0 v6wildcard [::]:123
> Mar 11 00:23:50 cube ntpd[354]: IO: Listen and drop on 1 v4wildcard 
> 0.0.0.0:123
> Mar 11 00:23:50 cube ntpd[354]: IO: Listen normally on 2 lo 127.0.0.1:123
> Mar 11 00:23:50 cube ntpd[354]: IO: Listen normally on 3 lo [::1]:123
> Mar 11 00:23:50 cube ntpd[354]: IO: Listening on routing socket on fd #20 for 
> interface updates
> Mar 11 00:23:50 cube ntpd[354]: INIT: This system has a 32-bit time_t.
> Mar 11 00:23:50 cube ntpd[354]: INIT: This ntpd will fail on 
> 2038-01-19T03:14:07Z.
> Mar 11 00:23:51 cube ntpd[354]: DNS: dns_probe: us.pool.ntp.org, 
> cast_flags:8, flags:101
> Mar 11 00:23:51 cube ntpd[354]: DNS: dns_check: processing us.pool.ntp.org, 
> 8, 101
> Mar 11 00:23:51 cube ntpd[354]: DNS: dns_check: DNS error: -3, Temporary 
> failure in name resolution
> Mar 11 00:23:51 cube ntpd[354]: DNS: dns_take_status: us.pool.ntp.org=>temp, 9
> Mar 11 00:23:52 cube ntpd[354]: DNS: dns_probe: pool.rcthomas.org, 
> cast_flags:8, flags:121
> Mar 11 00:23:52 cube ntpd[354]: DNS: dns_check: processing pool.rcthomas.org, 
> 8, 121
> Mar 11 00:23:52 cube ntpd[354]: DNS: dns_check: DNS error: -3, Temporary 
> failure in name resolution
> Mar 11 00:23:52 cube ntpd[354]: DNS: dns_take_status: 
> pool.rcthomas.org=>temp, 9
> Mar 11 00:23:56 cube ntpd[354]: IO: Listen normally on 4 eth0 
> 192.168.3.129:123
> Mar 11 00:23:56 cube ntpd[354]: IO: Listen normally on 5 eth0 
> [fe80::d263:b4ff:fe00:912f%2]:123
> Mar 11 00:23:56 cube ntpd[354]: DNS: dns_probe: pool.rcthomas.org, 
> cast_flags:8, flags:121
> Mar 11 00:23:56 cube ntpd[354]: DNS: dns_check: processing pool.rcthomas.org, 
> 8, 121
> Mar 11 00:23:56 cube ntpd[354]: DNS: Pool taking: 192.168.3.207
> Mar 11 00:23:56 cube ntpd[354]: DNS: Pool taking: 192.168.3.111
> Mar 11 00:23:56 cube ntpd[354]: DNS: Pool taking: 192.168.3.4
> Mar 11 00:23:56 cube ntpd[354]: DNS: Pool taking: 192.168.1.14
> Mar 11 00:23:56 cube ntpd[354]: DNS: 

Bug#924294: Maintaining picosat in Debian Science team (Was: Bug#924294: ITP: python-pycosat -- Python bindings to picosat)

[Andreas Tille]

Hi Michael,

when I was doing the packaging the Python API for picosat I realised
that its lagging a bit behind upstream.  I have not realised any
drawback currently but when I checked I considered a good idea to
maintain picosat in Debian Science team repository at salsa and
use the team as maintainer.  In case you might agree with this I'd
volunteer to do the move and add you as Uploader.

Kind regards

 Andreas.

On Mon, Mar 11, 2019 at 07:24:25AM +0100, Andreas Tille wrote:
> Package: wnpp
> Severity: wishlist
> 
> Subject: ITP: python-pycosat -- Python bindings to picosat
> Package: wnpp
> Owner:  <>
> Severity: wishlist
> 
> * Package name: python-pycosat
>   Version : 0.6.3
>   Upstream Author : Ilan Schnell, Continuum Analytics, Inc.
> * URL : https://pypi.org/project/pycosat/
> * License : MIT
>   Programming Lang: Python
>   Description : Python bindings to picosat
>  PicoSAT is a popular SAT solver written by Armin Biere in pure C. This
>  package provides efficient Python bindings to picosat on the C level,
>  i.e. when importing pycosat, the picosat solver becomes part of the
>  Python process itself.
> 
> Remark: This package is maintained by Debian Med Packaging Team at
>https://salsa.debian.org/med-team/python-pycosat
> 
> ___
> Debian-med-packaging mailing list
> debian-med-packag...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-packaging

-- 
http://fam-tille.de

Bug#850425: mpt3sas "swiotlb buffer is full" problem only under Xen

[Juergen Gross]

On 10/03/2019 23:03, Andrew Cooper wrote:
> On 10/03/2019 21:35, Hans van Kranenburg wrote:
>> found -1 4.19.20-1
>> thanks
>>
>> Hi,
>>
>> Reviving a thing from Jan 2017 here. I don't have this thread in my
>> mailbox, so no inline quotes.
>>
>> I just installed some HP z820 workstation and rebooted it into Xen
>> 4.11.1+26-g87f51bf366-3 with linux 4.19.20-1 as dom0 kernel.
>>
>> During boot I'm greeted by a long list of...
>>
>> [   14.518793] mpt3sas :02:00.0: swiotlb buffer is full (sz: 65536
>> bytes)
>> [   14.518899] mpt3sas :02:00.0: swiotlb buffer is full
>> [   14.518956] mpt3sas :02:00.0: swiotlb buffer is full (sz: 65536
>> bytes)
>> [   14.518988] sd 6:0:3:0: pci_map_sg failed: request for 786432 bytes!
>> [   14.519081] mpt3sas :02:00.0: swiotlb buffer is full
>> [   14.519309] sd 6:0:1:0: pci_map_sg failed: request for 1310720 bytes!
>> [   14.524611] mpt3sas :02:00.0: swiotlb buffer is full (sz: 65536
>> bytes)
>> [   14.527309] mpt3sas :02:00.0: swiotlb buffer is full
>> [   14.527405] sd 6:0:3:0: pci_map_sg failed: request for 786432 bytes!
>> [...]
>>
>> ...and some hangs here and there. This indeed did not happen when
>> booting just Linux, without Xen.
>>
>> Some searching brought me to this Debian bug. So, thanks for writing
>> down all kinds of research here already. Even if it's not fixed upstream
>> yet, this helps a lot. :-)
>>
>> Using dom0_mem=2GiB,max:4GiB instead of dom0_mem=2GiB,max:2GiB (which I
>> started with) makes the errors go away, so workaround confirmed.
>>
>> I can try any of the linked patches, but I see that in message 54,
>>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=850425#54
>> Andrew says: "IIRC, they were essentially rejected,". Next message, Ian
>> asks "Do you have a reference ?", but I don't see any fup on that.
>>
>> I think I'm fine with this workaround.
>>
>> If someone will ever work on the upstream patches, then this is just to
>> let know that I might be able to help testing. However, I only have one
>> of this type of box and it's gonna be installed as server at some
>> non-profit organization without OOB access, replacing even older donated
>> hardware, so, it will be kinda limited... :)
> 
> I think
> https://lists.xen.org/archives/html/xen-devel/2014-12/msg00699.html is
> the last attempt David made to upstream the fixes.
> 
> Linux is still broken, and these fixes are still necessary.
> 
> Boris/Juergen: Any chance you could look into these patches?  I have no
> idea what they they're in against master, but its also liable its now
> more complicated with the host max mfn calculations which have gone in
> more recently.

I'm not sure. Patch 3 of this series is basically already there (see
commit c6d4381220a0087ce19dbf6984d92c451bd6b364). So maybe all we need
is patch 4, which should really be easy to do?

Hans, could you give it a try? You'd need to use a 4.20 kernel at least.
I can do the official patch posting in case you confirm it working.

Adding Konrad as the swiotlb-xen maintainer.


Juergen

Bug#924296: check_ping: check_ping -4 does an IPv6 check

[Guillaume Subiron]

Package: nagios-plugins
Version: 2.2-3

If the remote host has an IPv6 address configured, the check_ping
plugin seems to do an ICMPv6 check, even when we use -4 to force IPv4.

You can reproduce by doing a check_ping -4

$ /usr/lib/nagios/plugins/check_ping -4 -H www.sysnove.net -w 1000,100% -c 
2000,100% -p 1
PING OK -  Paquets perdus = 0%, RTA = 1.36 
ms|rta=1.364000ms;1000.00;2000.00;0.00 pl=0%;100;100;0

while monitoring the network with tcpdump.

$ sudo tcpdump -i any dst 2001:bc8:3977:802::1 and icmp6
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
09:58:34.772859 IP6 infra-mon04.sysnove.net > sysnove-www01.sysnove.net: ICMP6, 
echo request, seq 1, length 64


I'm using an up to date Debian 9.6 with nagios-plugins 2.2-3.
This problem is not present on 8.11 with nagios-plugins 2.1.1-1.


-- 
Guillaume Subiron 
  Mail - maet...@subiron.org
   GPG - 5BC2 EADB
 MSTDN - @maet...@mstdn.fr
   IRC - maethor@(freenode|geeknode)

Bug#919929: python-scipy: autopkgtest fails (Re: bug#919929)

[Drew Parsons]

On 2019-03-10 15:46, Drew Parsons wrote:

On 2019-03-10 03:51, Paul Gevers wrote:

Hi Drew,




To remove the deprecation warnings we'd need to deal with them at the
source. Upstream has patches
https://github.com/scipy/scipy/commit/614847c5fc8d5f8a618980df3c1b93540428ae46

https://github.com/scipy/scipy/commit/e0cfa29e2fbe86f994924c0c7514ff5bbfffd514

and for completeness
https://github.com/scipy/scipy/commit/87e48c3c54d7a85bc6628c88c1de98ac0469b6fa

...

Can you authorise an unblock to apply these 3 upstream patches to
python-scipy 1.1.0 ?
That won't necessarily fix the debci failure, but it will make it a 
lot

easier to see what's actually failing.


I am slightly unhappy with the second patch, as it seems to be doing
more than you describe above in a few places. This may be correct but
that is difficult to quickly judge.


I've adapted the 3 patches and pushed to salsa,
   matrix_API_614847c5.patch
   matrix_API_more_e0cfa29e2.patch
   matrix_API_filter_check_87e48c3c5.patch
https://salsa.debian.org/python-team/modules/python-scipy/tree/master/debian/patches

The other behaviour that you saw in the second patch I think might be 
replacement of "D*diag(v)" with "D@diag(v)". That's matrix 
multiplication, so still relevent to the matrix API patch. @ is not 
available in python2 so I changed it to numpy.matmul, which does the 
same thing.


The numpy.sparse tests pass with this patch, and most of the matrix 
PendingDeprecationWarnings are gone (the upstream patch missed 
integrate/tests/test_ivp.py, but the remaining warnings are few enough 
to not need to worry about).




Also, what is the general documented way that these wrappers can be
used? scipy is sort of taking over the maintenanceship of these
functions in this way if we're not careful.



...

There is discussion of the distinction between numpy.matrix and
numpy.ndarray (which is at the heart of the deeprecation warning) at
https://docs.scipy.org/doc/scipy/reference/tutorial/linalg.html#numpy-matrix-vs-2d-numpy-ndarray

The utility class scipy.sparse.sputils itself is apparently
undocumented, by which I infer it's intended for internal use only,
not a public API. I guess it's reasonable for a package to be testing
it's own internal functions.  Strange thing is,
scipy.sparse.sputils.matrix is not actually defined in
scipy/sparse/sputils.py. Must be inherited or defined in some deep
pythonfu that I haven't mastered yet.



Actually scipy.sparse.sputils.matrix was defined in these patches.  It 
is a bit odd that upstream is wrapping numpy.matrix just to avoid 
deprecation warnings, rather than following their own advice and using 
numpy.ndarray instead.



With these patches, the sparse matrix tests pass. There remain three 
errors unrelated to sparse matrix:
  spatial/tests/test__plotutils.py::TestPlotting::test_delaunay FAILED   
  [ 76%]
  spatial/tests/test__plotutils.py::TestPlotting::test_voronoi FAILED
  [ 76%]
  spatial/tests/test__plotutils.py::TestPlotting::test_convex_hull 
FAILED  [ 76%]
  __ TestPlotting.test_delaunay 
__


  self = 0x7f0f31156eb8>


  def test_delaunay(self):
  # Smoke test
  fig = plt.figure()
  obj = Delaunay(self.points)
  s_before = obj.simplices.copy()
  >   with suppress_warnings as sup:
  E   AttributeError: __enter__

  fig= 
  obj= 
  s_before   = array([[3, 1, 0],
 [2, 3, 0]], dtype=int32)
  self   = at 0x7f0f31156eb8>


  
/usr/lib/python3/dist-packages/scipy/spatial/tests/test__plotutils.py:31: 
AttributeError


(likewise for the other 2)
These AttributeErrors are mentioned at 
https://github.com/scipy/scipy/issues/9491. Upstream doesn't seem too 
concerned about them.


Apart from that, I'm happy to upload the sparse matrix patches once the 
s390x update reaches testing.


Drew

Bug#924295: elpa-ibuffer-projectile: fails to upgrade from stretch: ibuffer-projectile.el:51:1:Error: Cannot open load file: No such file or directory, dash

[Andreas Beckmann]

Package: elpa-ibuffer-projectile
Version: 0.2-2
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'stretch'.
It installed fine in 'stretch', then the upgrade to 'buster' fails.

This test had --install-recommends enabled (but I can also reproduce it
without). This happened during the 'apt-get upgrade' phase of a two-stage
upgrade (apt-get upgrade && apt-get dist-upgrade).

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

  Setting up elpa-ibuffer-projectile (0.2-2) ...
  tsort: -: input contains a loop:
  tsort: dash-el
  tsort: emacsen-common
  Install dash-el for emacs24
  install/dash-el: Handling install for emacsen flavor emacs24
  Loading 00debian-vars...
  Loading /etc/emacs/site-start.d/50dash-el.el (source)...
  Wrote /usr/share/emacs24/site-lisp/dash-el/dash-functional.elc
  Wrote /usr/share/emacs24/site-lisp/dash-el/dash.elc
  Install emacsen-common for emacs24
  emacsen-common: Handling install of emacsen flavor emacs24
  Wrote /etc/emacs24/site-start.d/00debian-vars.elc
  Wrote /usr/share/emacs24/site-lisp/debian-startup.elc
  Install elpa-projectile for emacs24
  install/projectile-0.14.0: Handling install of emacsen flavor emacs24
  install/projectile-0.14.0: byte-compiling for emacs24
  Install elpa-ibuffer-projectile for emacs24
  install/ibuffer-projectile-0.2: Handling install of emacsen flavor emacs24
  install/ibuffer-projectile-0.2: byte-compiling for emacs24
  
  In toplevel form:
  ibuffer-projectile.el:51:1:Error: Cannot open load file: No such file or 
directory, dash
  ERROR: install script from elpa-ibuffer-projectile package failed
  dpkg: error processing package elpa-ibuffer-projectile (--configure):
   subprocess installed post-installation script returned error exit status 1

If you need debug information from the chroot after the failure,
please let me know what you need and how to obtain it.


cheers,

Andreas


elpa-ibuffer-projectile_0.2-2.log.gz
Description: application/gzip

Bug#924294: ITP: python-pycosat -- Python bindings to picosat

[Andreas Tille]

Package: wnpp
Severity: wishlist

Subject: ITP: python-pycosat -- Python bindings to picosat
Package: wnpp
Owner:  <>
Severity: wishlist

* Package name: python-pycosat
  Version : 0.6.3
  Upstream Author : Ilan Schnell, Continuum Analytics, Inc.
* URL : https://pypi.org/project/pycosat/
* License : MIT
  Programming Lang: Python
  Description : Python bindings to picosat
 PicoSAT is a popular SAT solver written by Armin Biere in pure C. This
 package provides efficient Python bindings to picosat on the C level,
 i.e. when importing pycosat, the picosat solver becomes part of the
 Python process itself.

Remark: This package is maintained by Debian Med Packaging Team at
   https://salsa.debian.org/med-team/python-pycosat

Bug#852199: /snap is a FHS violation

[Nye Liu]

How is it possible that in 2018, paths like this are hardcoded and aren’t even 
configurable at *compile* time?

On Mon, 14 Jan 2019 08:09:52 -0500 Jeremy Bicha  wrote:
> Control: severity -1 normal
> Control: tags -1 wontfix
> 
> I'm lowering the severity back to its original level.
> 
> This isn't something that's practical to change in Debian so I'm adding 
> wontfix.
> 
> Thanks,
> Jeremy Bicha
> 
>