Bug#905767: emacs25: FTBFS due to test failures on arm64 in a binNMU against new version of libmagick

[Niels Thykier]

Control: reassign -1 src:emacs25

Rob Browning:
> Niels Thykier  writes:
> 
>> Package: emacs25
>> Version: 25.2+1-6+b3
>> Severity: serious
>> Tags: ftbfs
>> Justification: fails to build from source
> 
> This should be fixed in emacs 1:25.2+1-9, which hopefully will be able
> to completely replace emacs25 in sid/buster soon.
> 
> Thanks
> 

Indeed.  This was intended for src:emacs25 (I had not seen we had an
src:emacs now).  Reassining to the proper package. :)

Thanks
~Niels

Bug#903182: mtr: FTBFS in buster/sid (dh_installman: Cannot find "mtr/mtr.8")

[Niels Thykier]

Samuel Henrique:
> Hello Niels,
> 
> I only had the time to look at this now, thanks for the fix, feel free
> to upload it now if you rather not wait for the 7 (now 4) days.
> 
> Regards,
> 

Thanks for reviewing.  I have uploaded it directly to unstable now. :)

Thanks,
~Niels

Bug#773663: Updated patch for popcon tor support

[Niels Thykier]

Bill Allombert:
> On Thu, Aug 09, 2018 at 07:55:00AM +, Niels Thykier wrote:
>> [...]
>>
>> Excellent, I am looking forward to it. :) Do you have an estimate of
>> when 1.67 will be in unstable?
> 
> Now. Sorry I prepared the package one month ago, tested it (which is
> slow) and then forgot to upload it. Thanks for the remainder!
> 
> Cheers,
> Bill.
> 

Thanks, :)
~Niels

Bug#905767: emacs25: FTBFS due to test failures on arm64 in a binNMU against new version of libmagick

[Rob Browning]

Niels Thykier  writes:

> Package: emacs25
> Version: 25.2+1-6+b3
> Severity: serious
> Tags: ftbfs
> Justification: fails to build from source

This should be fixed in emacs 1:25.2+1-9, which hopefully will be able
to completely replace emacs25 in sid/buster soon.

Thanks
-- 
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4

Bug#905813: orc FTCBFS: does not pass a --cross-file to meson

[Helmut Grohne]

Source: orc
Version: 1:0.4.28-2
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

orc fails to cross build from source, because it does not pass a
--cross-file to meson. Doing so is not exactly trivial, though mesons'
addition of debcrossgen helps a lot. By far the easiest way of doing it
is using debhelper. The attached patch implements that and makes orc
cross build successfully. Please consider applying it. The patch also
makes the build system honour DEB_BUILD_OPTIONS=nocheck. Furthermore, I
suggest to add --parallel to dh to speed up the build (now possible via
using dh_auto_build).

Helmut
diff --minimal -Nru orc-0.4.28/debian/changelog orc-0.4.28/debian/changelog
--- orc-0.4.28/debian/changelog 2018-05-31 16:03:45.0 +0200
+++ orc-0.4.28/debian/changelog 2018-08-10 06:54:08.0 +0200
@@ -1,3 +1,10 @@
+orc (1:0.4.28-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Use debhelpers meson buildsystem. (Closes: #-1)
+
+ -- Helmut Grohne   Fri, 10 Aug 2018 06:54:08 +0200
+
 orc (1:0.4.28-2) unstable; urgency=medium
 
   * debian/control:
diff --minimal -Nru orc-0.4.28/debian/rules orc-0.4.28/debian/rules
--- orc-0.4.28/debian/rules 2017-11-20 17:40:44.0 +0100
+++ orc-0.4.28/debian/rules 2018-08-10 06:54:08.0 +0200
@@ -2,35 +2,32 @@
 
 include /usr/share/dpkg/default.mk
 
-export MAKE = ninja -v
-
 LDFLAGS += -Wl,-z,defs -Wl,-O1 -Wl,--as-needed
 
 %:
-   dh $@
+   dh $@ --buildsystem=meson
 
 override_dh_auto_configure:
if test -r /proc/cpuinfo; then \
cat /proc/cpuinfo; \
fi
-   mkdir -p deb-build && meson --buildtype plain --prefix /usr 
--default-library shared . deb-build
-   mkdir -p deb-build-static && meson --buildtype plain --prefix /usr 
--default-library static -Db_staticpic=true -Ddisable_gtkdoc=true 
-Ddisable_tests=true . deb-build-static
+   dh_auto_configure --builddirectory=deb-build -- --default-library shared
+   dh_auto_configure --builddirectory=deb-build-static -- 
--default-library=static -Db_staticpic=true -Ddisable_gtkdoc=true 
-Ddisable_tests=true
 
 override_dh_auto_build:
-   $(MAKE) -C deb-build all
-   $(MAKE) -C deb-build-static all
+   dh_auto_build --builddirectory=deb-build
+   dh_auto_build --builddirectory=deb-build-static
 
 override_dh_auto_clean:
rm -rf deb-build deb-build-static
dh_auto_clean
 
 override_dh_auto_install:
-   DESTDIR=$(CURDIR)/debian/tmp $(MAKE) -C deb-build install
-   DESTDIR=$(CURDIR)/debian/tmp $(MAKE) -C deb-build-static install
-   dh_auto_install
+   dh_auto_install --builddirectory=deb-build
+   dh_auto_install --builddirectory=deb-build-static
 
 override_dh_auto_test:
-   $(MAKE) -C deb-build test || true
+   dh_auto_test --builddirectory=test || true
 
 override_dh_strip:
dh_strip -pliborc-0.4-0 --dbg-package=liborc-0.4-0-dbg

Bug#905812: ITP: django-cas-server -- CAS server library for Django

[William Blough]

Package: wnpp
Severity: wishlist
Owner: William Blough 

* Package name: django-cas-server
  Version : 0.9.9
  Upstream Author : Valentin Samir
* URL : https://github.com/nitmir/django-cas-server
* License : GPL-3
  Programming Lang: Python
  Description : CAS server library for Django
   CAS Server is a Django application implementing the Central Authentication
   Service (CAS) Protocol version 3.0 specification.

 - Why is this package useful/relevant?

A Django client for CAS already exists in Debian
(python-django-casclient), however, there does not appear to be a
python-based  CAS server available.

 - Is it a dependency for another package?  No.

 - Do you use it?  Yes.

 - If there are other packages providing similar functionality, how does it
 compare?

The package lemonldap-ng is written in perl and supports CAS.  It is
a very full featured, standalone SSO system.   However it (in my
opinion) is a little too complex for simple environments.  In
contrast, django-cas-server can simply plug into an existing Django
deployment with little difficulty (and fewer features).

 - How do you plan to maintain it?

I am willing to join the Debian Python Module Team and maintain it under
that umbrella.  However, if it doesn't make sense for me to join the
team for one package, then I'm willing to maintain it by myself.
Either is acceptable to me.


signature.asc
Description: PGP signature

Bug#883163: lxc.network.0.link configuration value is ignored

[Harald Dunkel]

Hi Salvador,

using lxc 2.0.9 the config lines to define 2 network interfaces look
like this:

## Network eth0
lxc.network.type= veth
lxc.network.hwaddr  = 00:20:6f:dd:b4:a0
lxc.network.flags   = up
lxc.network.link= br5
lxc.network.name= eth0
# lxc.network.ipv4  = 5.xxx.yyy.zzz/26
# lxc.network.ipv4.gateway  = 5.xxx.yyy.1
# lxc.network.ipv6  = 2001:db8:30:ffe0::e4/64
# lxc.network.ipv6.gateway  = 2001:db8:30:ffe0::1

## Network eth1
lxc.network.type= veth
lxc.network.hwaddr  = 00:20:23:ee:dc:1b
lxc.network.flags   = up
lxc.network.link= br4
lxc.network.name= eth1
lxc.network.ipv4= 10.1.1.228/24


The line with "lxc.network.type" marks the start of a new block.
For lxc3 (not in Debian yet) this has been improved:

## Network eth0
lxc.net.0.type= veth
lxc.net.0.hwaddr  = 00:20:6f:dd:b4:a0
lxc.net.0.flags   = up
lxc.net.0.link= br5
lxc.net.0.name= eth0
# lxc.net.0.ipv4  = 5.xxx.yyy.zzz/26
# lxc.net.0.ipv4.gateway  = 5.xxx.yyy.1
# lxc.net.0.ipv6  = 2001:db8:30:ffe0::e4/64
# lxc.net.0.ipv6.gateway  = 2001:db8:30:ffe0::1

## Network eth1
lxc.net.1.type= veth
lxc.net.1.hwaddr  = 00:20:23:ee:dc:1b
lxc.net.1.flags   = up
lxc.net.1.link= br4
lxc.net.1.name= eth1
lxc.net.1.ipv4= 10.1.1.228/24


Hope this helps
Harri

Bug#905811: moria does not trap errors from make

[Helmut Grohne]

Source: moria
Version: 5.6.debian.1-2
Severity: serious
Justification: debian policy 4.6

The Debian policy requires that a build aborts on errors rather than
continuing. The moria package is interesting in this regard:

( cd build ; $(MAKE) )

It tries to cd to build and then runs make wherever it lands. As it
happens, the clean target removes the build folder. So the cd fails and
it runs the build directly in the source directory.

That's actually the correct thing to do as the upstream Makefile's
default target insists on setting up the build directory. The cd call
can only succeed after setting up the build directory and nothing else
in debian/rules takes care of that.

I therefore think that that this chaining (that happens in more places)
is in violation of the Debian policy section 4.6. It also is grossly
misleading and makes contributing to the package unnecessarily
difficult.

Helmut

Bug#885498: zenmap: Depends on unmaintained pygtk

[Samuel Henrique]

Hello Jeremy,

I think this has nothing to do with the maintainer of the package, it's an
upstream issue.

Can you forward this to them?

-- 
Samuel Henrique 

Bug#905810: ITP: python-smoke-zephyr - Python utility collection

[Samuel Henrique]

Package: wnpp
Owner: "Samuel Henrique" 
Severity: wishlist
User: samuel...@debian.org
Usertags: gsoc2018-portkalipackages

* Package name: python-smoke-zephyr
* URL : https://github.com/zeroSteiner/smoke-zephyr
* License : BSD-3-clause
  Programming Lang: Python
  Description : Python utility collection

This package is a build dependency of termineter (
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=905806)

-- 
Samuel Henrique 

Bug#905809: RM: node-wrench -- RoM abandoned upstream

[Julien Puydt]

Package: ftp.debian.org
Severity: normal

The package is abandoned upstream since two years, in favor of 
node-fs-extra, so there's no point putting it in the next stable: let's 
pull the plug.


Cheers,

jpuydt on irc.debian.org

Bug#905808: ITP: python-crcelk - Implementation of the CRC algorithm

[Samuel Henrique]

Package: wnpp
Owner: "Samuel Henrique" 
Severity: wishlist
User: samuel...@debian.org
Usertags: gsoc2018-portkalipackages

* Package name: python-crcelk
* URL :  https://github.com/zeroSteiner/crcelk/
* License : MIT
  Programming Lang: Python
  Description :
 Updated fork of the crcmoose module for recent
 versions of python. it provides a pure python implementation of the crc
 algorithm and allows for variants to easily be defined by providing their
 parameters such as width, starting polynomial, etc.

This package is a dependency of termineter (
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=905806)

-- 
Samuel Henrique 

Bug#657495: network-manager: Disconnect, whithout reconnect often

[Vinicius Couto]

Package: network-manager
Version: 1.12.2-2
Followup-For: Bug #657495

Dear Maintainer,

I think that begun after the last package update.

With some frequency, my wired connection disconect, but other
programs not recognise. I try disconect and connect on the
settings, but it not permit to connect again. Either 
service networking restart. My solution is to unplug/plug
the cable or restart the router.


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

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

Versions of packages network-manager depends on:
ii  adduser3.117
ii  dbus   1.12.10-1
ii  libaudit1  1:2.8.3-1+b1
ii  libbluetooth3  5.50-1
ii  libc6  2.27-5
ii  libcurl3-gnutls7.60.0-2
ii  libglib2.0-0   2.56.1-2
ii  libgnutls303.5.19-1
ii  libjansson42.11-1
ii  libmm-glib01.7.990-1
ii  libndp01.6-1+b1
ii  libnewt0.520.52.20-5
ii  libnm0 1.12.2-2
ii  libpam-systemd 239-7
ii  libpolkit-agent-1-00.105-21
ii  libpolkit-gobject-1-0  0.105-21
ii  libpsl50.20.2-1
ii  libreadline7   7.0-5
ii  libselinux12.8-1+b1
ii  libsystemd0239-7
ii  libteamdctl0   1.27-1
ii  libudev1   239-7
ii  libuuid1   2.32-0.4
ii  lsb-base   9.20170808
ii  policykit-10.105-21
ii  udev   239-7
ii  wpasupplicant  2:2.6-18

Versions of packages network-manager recommends:
ii  crda 3.18-1
ii  dnsmasq-base [dnsmasq-base]  2.79-1
ii  iptables 1.6.2-1.1
ii  isc-dhcp-client  4.3.5-4+b1
ii  modemmanager 1.7.990-1
ii  ppp  2.4.7-2+3

Versions of packages network-manager suggests:
pn  libteam-utils  

-- no debconf information

Bug#895729: RFS: mkl-dnn/0.15+git20180803.3f58c1 [ITP] -- tensorflow dependency (amd64 specific)

[Lumin]

control: tag -1 +moreinfo

On Thu, Aug 09, 2018 at 08:01:10PM +0200, Adam Borowski wrote:
> On Thu, Aug 09, 2018 at 10:16:17AM +, Lumin wrote:
> >  * Package name: mkl-dnn
> >Version : 0.15+git20180803.3f58c16-1
> >Upstream Author : intel
> 
> Alas, the build flags use -march=native -mtune=native which is a big no-no.
> The first makes the package crash on any processor lacking an extension that
> was present on the build machine and was used by the compiler; unless some
> kind of runtime detection is used, packages are allowed only the baseline
> ISA for the architecture.  As for -mtune=native, it makes the package build
> unreproducibly, differing based on where it was compiled.

My bad, I overlooked the two flags. The cmake files have been patched
in master branch of packaging repo.

https://salsa.debian.org/science-team/mkl-dnn/commit/6e0a9bea677d398ee23ac9c2f84c3551d100a6d4
http://debomatic-amd64.debian.net/distribution#unstable/mkl-dnn/0.15+git20180803.3f58c16-1/buildlog
 
> The second problem is that in the testsuite, test_convolution_format_any
> fails (0/5 sub-tests).  This might be related to my machine being:
> vendor_id : AuthenticAMD
> model name: AMD Phenom(tm) II X6 1055T Processor

Well, I have been waiting for intel to fix test failures for a long
time. Finally the snapshot 0.15+git20180803.3f58c16 doesn't fail
any test on dom-amd64 (E5 2699v?) and my I5-7440HQ, but now it failed
on AMD cpu ...

> Log of the FTBFS attached.

Thanks for the log, I've forwarded it to upstream.
https://github.com/intel/mkl-dnn/issues/291

I shouldn't let any test failure from mkl-dnn pass, so we have to wait
for upstream to fix the problem. Fortunately, TensorFlow can be compiled
with or without mkl-dnn. It doesn't matter if the initial upload of
TensorFlow is not linked against mkl-dnn. The difference that mkl-dnn
would bring to TensorFlow is computation speed-up.

Bug#905807: julia 0.7.0-1 doesn't build on ppc64el

[Lumin]

Package: julia
Version: 0.7.0-1
Severity: important
Control: tag -1 +patch +moreinfo

https://github.com/JuliaLang/julia/issues/22650
https://github.com/JuliaLang/julia/pull/26218

I don't have any ppc64el porter to test the LLVM patch.
Once the patch is confirmed, this bug should be reassigned to LLVM,
with the moreinfo tag dropped.

Bug#905674: undistributable

[Rogério Brito]

Dear Ole (and others potentially interested in having GNU Parallel in
Debian's and derivatives' repositories),

I don't know if you have been following the emails on the Debian BTS
regarding GNU Parallel having restrictions regardings its distribution etc.

Since this issue has surfaced itself once again, but now in a more intense
manner, I believe that, if you have not yet been informed, you may want to
give your opinion (and I will decide how I should follow my maintainership
within the constraints of your software and the contraints of Debian).

Thanks,

Rogério Brito...

On Aug 08 2018, Adam Borowski wrote:
> Actually, it seems to me it's not even distributable.
> 
> The wording sounds like a requirement rather than something non-mandatory --
> reinforced by providing the alternative of paying €1.  Yet the license
> is GPL3+, which expressly forbids additional fees.  This is even described
> in FSF's GPL FAQ:
> https://www.gnu.org/licenses/gpl-faq.en.html#RequireCitation
> 
> Thus, the copyright holder can distribute this software, but no one else
> can.
> 
> As the requirement is not a part of the license, we could just remove the
> demand nagware from the code.  But alas, the upstream (Ole Tange) threatened
> legal action if you do so without renaming the package.  And it doesn't seem
> to be just hot wind, as he registered it: US trademark number 87867112,
> filed Apr 07, 2018.
> 
> Multiple people tried persuading the upstream to drop this requirement,
> without success.  Thus, diplomacy doesn't appear to be likely to help,
> although letting rms know may work (this package has been blessed as an
> official GNU one, obviously before the requirement was added).
> 
> Thus, only options I see are:
> * renaming the package and removing offending code, or
> * complete removal
> 
> 
> Meow!
> -- 
> // If you believe in so-called "intellectual property", please immediately
> // cease using counterfeit alphabets.  Instead, contact the nearest temple
> // of Amon, whose priests will provide you with scribal services for all
> // your writing needs, for Reasonable And Non-Discriminatory prices.
> 

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

Bug#905806: ITP: termineter - Smart meter testing framework

[Samuel Henrique]

Package: wnpp
Owner: "Samuel Henrique" 
Severity: wishlist
User: samuel...@debian.org
Usertags: gsoc2018-portkalipackages

* Package name: termineter
* URL : https://github.com/securestate/termineter
* License : BSD-3-clause
  Programming Lang: Python
  Description :
 Python framework which provides a platform for the
 security testing of smart meters.  It implements the C1218 and C1219
protocols
 for communication over an optical interface.  Currently supported are
Meters
 using C1219-2007 with 7-bit character sets.  This is the most common
 configuration found in North America.  Termineter communicates with Smart
 Meters via a connection using an ANSI type-2 optical probe with a serial
 interface.

I intend to maintain this package under the Debian Security Tools
Packaging Team (pkg-security).

-- 
Samuel Henrique 

Bug#905794: ITP: e-wrapper -- wrapper to handle "$EDITOR file:lineno"

[Zebulon McCorkle]

On Thu, Aug 09, 2018 at 08:33:35PM +0200, Adam Borowski wrote:
>   Version : uhm... hard question
>   Upstream Author : yours truly
> * License : hard question again

I'd suggest "releasing" a 1.0 before packaging. Also, you will need to
select a license. For something small and relatively simple like this,
I'd typically use CC0, but you're free to choose any (DFSG-compliant!)
license you want of course.

-- 
Zebulon McCorkle
zebmccor...@asymptote.club | https://keybase.io/zebMcCorkle
803A 0F47 82AD DDEA 46BE  055F F8F9 DB8C 1A54 6398

   |
   |
__/
  __  Asymptote Club
 /(bad ASCII graph by yours truly)
 |
 |


signature.asc
Description: PGP signature

Bug#903182: mtr: FTBFS in buster/sid (dh_installman: Cannot find "mtr/mtr.8")

[Samuel Henrique]

Hello Niels,

I only had the time to look at this now, thanks for the fix, feel free
to upload it now if you rather not wait for the 7 (now 4) days.

Regards,

-- 
Samuel Henrique 

Bug#905805: bum: Should this package be removed?

[Boyuan Yang]

Package: bum
Severity: important
X-Debbugs-CC: thesalty...@gmail.com f...@debian.org

Hello all,

I'm suggesting we remove package bum from Debian Archive.

* The package is orphaned;
* It received no upload since 2009;
* The upstream webpage is now defunct;
* This GUI application requires root privilege so it won't run under 
Wayland anymore.

I understand that it's a hard decision but the problem has to be 
solved sooner or later. I will submit a Removal bug for bum 31 days 
later if there's no objections. Any suggestions are welcome 
meanwhile.

--
Regards,
Boyuan Yang


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

Bug#897857:

[Olly Betts]

On Fri, Aug 10, 2018 at 10:36:59AM +1200, Michael Hudson-Doyle wrote:
> On Fri, 10 Aug 2018 at 09:37, Olly Betts  wrote:
> > I actually addressed this upstream in SWIG back in May (by fixing the
> > generated code rather than disabling the warning), but there's not
> > been a release in a while.  I'll take a look and see if the fix can be
> > backported to the Debian package.  The potential problem is that it was
> > after clean-up of support for older Python versions, and it seems
> > unhelpful in the wider context for the Debian swig package to generate
> > code which supports a narrower range of Python versions than the
> > corresponding upstream SWIG version.
> 
> Hm yes. On some level it would be fine to only support versions of Python
> supported by Debian, but on another that would be a bit hostile.

Indeed.

The patch needed some adjustment, but that wasn't as painful as I
feared.

I can't easily test it with all the Python versions which SWIG claims to
support (which unbelievably is still 2.0 and up in 1.3.x) but the older
of those don't define METH_O so don't take most of the codepaths this
changes anyway.

I've confirmed my changes address the issue when running the upstream
testsuite with GCC 8 and current Python, and fixed two other new GCC 8
warnings which most SWIG-generated Python bindings will trigger.

Cheers,
Olly

Bug#897857: swig: diff for NMU version 3.0.12-1.2

[Olly Betts]

Control: tags 897857 + patch
Control: tags 897857 + pending

Dear maintainer,

I've prepared an NMU for swig (versioned as 3.0.12-1.2) and uploaded it.

NMU diff is attached.

Cheers,
Olly
diff -Nru swig-3.0.12/debian/changelog swig-3.0.12/debian/changelog
--- swig-3.0.12/debian/changelog	2018-06-18 00:25:41.0 +1200
+++ swig-3.0.12/debian/changelog	2018-08-10 12:48:36.0 +1200
@@ -1,3 +1,15 @@
+swig (3.0.12-1.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * python-fix-function-cast-warnings.patch: Fix GCC8 warnings in generated
+Python code. (Closes: #897857)
+  * python-fix-gcc8-strncpy-warning.patch: Fix more GCC8 warnings in generated
+Python code.
+  * fix-gcc8-memset-warnings.patch: Fix GCC8 warnings in generated code for
+various languages.
+
+ -- Olly Betts   Fri, 10 Aug 2018 12:48:36 +1200
+
 swig (3.0.12-1.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru swig-3.0.12/debian/patches/fix-gcc8-memset-warnings.patch swig-3.0.12/debian/patches/fix-gcc8-memset-warnings.patch
--- swig-3.0.12/debian/patches/fix-gcc8-memset-warnings.patch	1970-01-01 12:00:00.0 +1200
+++ swig-3.0.12/debian/patches/fix-gcc8-memset-warnings.patch	2018-08-10 12:48:36.0 +1200
@@ -0,0 +1,212 @@
+Description: Fix new GCC8 warnings in generated code
+ Backported from upstream git master based on the following ranges of commits:
+ git diff 74345c92^..b229d92f
+ git diff dd26e8a0^..a67eff0a
+ git diff ef1351c7..7ac21f37
+Author: Mike Romberg 
+Origin: upstream
+Last-Updated: 2018-08-10
+
+--- a/Lib/python/pycontainer.swg
 b/Lib/python/pycontainer.swg
+@@ -434,8 +434,8 @@
+ {
+   swig::SwigVar_PyObject item = PySequence_GetItem(_seq, _index);
+   try {
+-	return swig::as(item, true);
+-  } catch (std::exception& e) {
++	return swig::as(item);
++  } catch (const std::invalid_argument& e) {
+ 	char msg[1024];
+ 	sprintf(msg, "in sequence element %d ", (int)_index);
+ 	if (!PyErr_Occurred()) {
+--- a/Lib/python/pystdcommon.swg
 b/Lib/python/pystdcommon.swg
+@@ -107,14 +107,14 @@
+ 
+   template  
+   struct traits_as {
+-static Type as(PyObject *obj, bool throw_error) {
++static Type as(PyObject *obj) {
+   Type v;
+   int res = asval(obj, );
+   if (!obj || !SWIG_IsOK(res)) {
+ 	if (!PyErr_Occurred()) {
+ 	  ::%type_error(swig::type_name());
+ 	}
+-	if (throw_error) throw std::invalid_argument("bad type");
++	throw std::invalid_argument("bad type");
+   }
+   return v;
+ }
+@@ -122,7 +122,7 @@
+ 
+   template  
+   struct traits_as {
+-static Type as(PyObject *obj, bool throw_error) {
++static Type as(PyObject *obj) {
+   Type *v = 0;  
+   int res = (obj ? traits_asptr::asptr(obj, ) : SWIG_ERROR);
+   if (SWIG_IsOK(res) && v) {
+@@ -134,21 +134,17 @@
+ 	  return *v;
+ 	}
+   } else {
+-	// Uninitialized return value, no Type() constructor required.
+-	static Type *v_def = (Type*) malloc(sizeof(Type));
+ 	if (!PyErr_Occurred()) {
+ 	  %type_error(swig::type_name());
+ 	}
+-	if (throw_error) throw std::invalid_argument("bad type");
+-	memset(v_def,0,sizeof(Type));
+-	return *v_def;
++	throw std::invalid_argument("bad type");
+   }
+ }
+   };
+ 
+   template  
+   struct traits_as {
+-static Type* as(PyObject *obj, bool throw_error) {
++static Type* as(PyObject *obj) {
+   Type *v = 0;  
+   int res = (obj ? traits_asptr::asptr(obj, ) : SWIG_ERROR);
+   if (SWIG_IsOK(res)) {
+@@ -157,15 +153,14 @@
+ 	if (!PyErr_Occurred()) {
+ 	  %type_error(swig::type_name());
+ 	}
+-	if (throw_error) throw std::invalid_argument("bad type");
+-	return 0;
++	throw std::invalid_argument("bad type");
+   }
+ }
+   };
+ 
+   template 
+-  inline Type as(PyObject *obj, bool te = false) {
+-return traits_as::category>::as(obj, te);
++  inline Type as(PyObject *obj) {
++return traits_as::category>::as(obj);
+   }
+ 
+   template  
+--- a/Lib/ruby/rubycontainer.swg
 b/Lib/ruby/rubycontainer.swg
+@@ -183,8 +183,8 @@
+ {
+   VALUE item = rb_ary_entry(_seq, _index );
+   try {
+-	return swig::as(item, true);
+-  } catch (std::exception& e) {
++	return swig::as(item);
++  } catch (const std::invalid_argument& e) {
+ 	char msg[1024];
+ 	sprintf(msg, "in sequence element %d ", _index);
+ 	VALUE lastErr = rb_gv_get("$!");
+@@ -926,7 +926,7 @@
+   VALUE elem = argv[0];
+   int idx = 0;
+   try {
+-	Sequence::value_type val = swig::as( elem, true );
++	Sequence::value_type val = swig::as( elem );
+ 	if ( i >= len ) {
+ 	  $self->resize(i-1, val);
+ 	  return $self;
+@@ -943,7 +943,7 @@
+ 	  }
+ 
+   } 
+-  catch( std::invalid_argument )
++  catch( const std::invalid_argument & )
+ 	{
+ 	  rb_raise( rb_eArgError, "%s",
+ 		Ruby_Format_TypeError( "", 
+@@ -967,10 +967,10 @@
+ 	  Sequence::iterator start = $self->begin();
+ 	  VALUE elem = argv[idx];
+ 	  try {
+-	Sequence::value_type val = swig::as( 

Bug#905804: RM: pypibrowser -- RoQA; Unmaintained; Dead Upstream; Affected by Qt4 Removal

[Boyuan Yang]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-CC: da...@debian.org

Dear David and FTP Masters,

As previously discussed in https://bugs.debian.org/897004 ,
it is believed that package pypibrowser in Debian should be removed.

* Its upstream is dead (no release since 2007)
* No packaging activity in Debian (no maintainer upload since 2010)
* Affected by Qt4 Removal (see https://wiki.debian.org/Qt4Removal )
* Package maintainer didn't reply to the removal suggestion (#897004, first 
submitted in April 2018)

Hi David, please feel free to share your idea about the future of pypibrowser 
as the package maintainer.

--
Regards,
Boyuan Yang

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

Bug#901705: Latest stable version is 0.90.0

[Takeshi Soejima]

Released 0.90.1 on 8 Jul 2018.

Bug#700227: GIMP hangs

[Walter Landry]

FYI, if for whatever reason you do not want to uninstall
libopenblas-base, a workaround for this bug is to set

  OPENBLAS_NUM_THREADS=1

before running gimp.  Setting it to anything larger than 1 makes gimp
hang for me.

Cheers,
Walter Landry

Bug#905130: hedgewars: FTBFS on armhf (tests fails))

[Julian Gilbey]

reopen 905130
thanks

Hi Lisandro,

I was going to make a report about hedgewars myself, as it seems that
this package is one of the factors blocking the Qt transition (see
https://release.debian.org/transitions/html/qtbase-abi-5-11-0.html).
And then I saw this bug report which looks like it was mistakenly
closed before being fixed.

Thank you for taking responsibility for this - I do appreciate it!
I'm reopening the bug report in the meantime so that others can also
see it is still live.  When you have taken care of it and either fixed
the bug or removed hedgewars from armhf, then please feel free to
close it again.

Best wishes,

   Julian

On Thu, Aug 02, 2018 at 03:30:03PM +, Debian Bug Tracking System wrote:
> This is an automatic notification regarding your Bug report
> which was filed against the src:hedgewars package:
> 
> #905130: hedgewars: FTBFS on armhf (tests fails)
> 
> It has been closed by Gianfranco Costamagna .
> 
> Their explanation is attached below along with your original report.
> If this explanation is unsatisfactory and you have not received a
> better one in a separate message then please contact Gianfranco Costamagna 
>  by
> replying to this email.
> 
> 
> -- 
> 905130: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=905130
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems

> Date: Thu, 2 Aug 2018 17:26:29 +0200
> From: Gianfranco Costamagna 
> Subject: hedgewars: FTBFS on armhf (tests fails)
> To: 905130-d...@bugs.debian.org
> 
> I'll take care of this, I already reported the bug, but I'll probably ask to 
> remove hedgewars
> from armhf.
> 
> G.

> Date: Tue, 31 Jul 2018 11:29:49 -0300
> From: Lisandro Damián Nicanor Pérez Meyer 
> Subject: hedgewars: FTBFS on armhf (tests fails)
> To: Debian Bug Tracking System 
> 
> Source: hedgewars
> Version: 0.9.24.1-dfsg-4
> Severity: serious
> Justification: FTBFS
> 
> Hi! durent the ongoing Qt transition your package FTBFS on armhf due to tests 
> failures.
> 
> 5/7 Test #1: drillrockets_boom.lua    Passed8.23 sec
> 6/7 Test #2: drillrockets_drill.lua ...   Passed   14.54 sec
> 7/7 Test #7: twothousandmines.lua .   Passed   82.14 sec
> 
> 86% tests passed, 1 tests failed out of 7
> 
> Total Test time (real) =  84.47 sec
> 
> The following tests FAILED:
> 6 - stuckcake.lua (Failed)
> Errors while running CTest
> make[1]: *** [Makefile:144: test] Error 8
> make[1]: Leaving directory '/<>/obj-arm-linux-gnueabihf'
> dh_auto_test: cd obj-arm-linux-gnueabihf && make -j4 test ARGS\+=-j4 returned 
> exit code 2
> make: *** [debian/rules:4: build-arch] Error 2
> 
> Regards, Lisandro.

Bug#905803: libarcus: does not build python extension for all supported versions of python

[Michael Hudson-Doyle]

Source: libarcus
Version: 3.3.0-1
Severity: normal

Hi,

As you can see from the build log at

https://buildd.debian.org/status/fetch.php?pkg=libarcus=amd64=3.3.0-1=1531074898=0
 

libarcus build-depends on python3-all-dev but only builds the Python
extension for the default version of Python (currently 3.6) not all
supported versions (currently 3.7 is supported in Debian as well). It
would be best if the package could build for all supported versions but
it would also be correct to change the build-depends to python3-dev
instead. I'm going to try to write a patch for the former but I don't
speak cmake terribly well...

Cheers,
mwh

-- System Information:
Debian Release: buster/sid
  APT prefers bionic-updates
  APT policy: (500, 'bionic-updates'), (500, 'bionic-security'), (500, 
'bionic'), (400, 'bionic-proposed'), (100, 'bionic-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Bug#896447: mesa: Lintian wishlist: Add notes to glvnd-fix-gl-dot-pc.patch

[Stuart Young]

Seems like this upstream commit may negate the need for this patch:

https://cgit.freedesktop.org/mesa/mesa/commit/?id=d5ac23647110fd530f9bf5002762587be446866d

Has been also tagged for the stable queue, so may affect 18.1.6+, as well
as 18.2.x.

Note: Completely untested by me.


On Sat, 2 Jun 2018 at 13:02, Stuart Young  wrote:

> Update: Fix still not present in mesa 18.1.1, so the original patch is
> still required.
>
> On 30 May 2018 at 17:51, Stuart Young  wrote:
>
>> Seems that the source issue of this patch is going to be addressed
>> upstream. This should mean that once it's addressed, the original
>> glvnd-fix-gl-dot-pc.patch file can be dropped entirely from the
>> debian/patches/ tree of this package.
>>
>> References:
>>  https://lists.freedesktop.org/archives/mesa-dev/2018-May/196034.html
>>  https://lists.freedesktop.org/archives/mesa-dev/2018-May/196038.html
>>
>> Note: Nothing has been accepted upstream yet. May or may not happen
>> before 18.1.1 is released. Will update this bug if I can when this patch is
>> no longer needed.
>>
>> --
>> Stuart Young (aka Cefiar)
>>
>
>
>
> --
> Stuart Young (aka Cefiar)
>


-- 
Stuart Young (aka Cefiar)

Bug#887468: hpanel: Crashes with SIGSEGV sometimes

[Paul Szabo]

Dear Bernhard,

I have been using hpanel with your patch for about 2 days now, and no
crash has occurred: seems it solves this issue.

Thanks, Paul
-- 
Paul Szabo   p...@maths.usyd.edu.au   http://www.maths.usyd.edu.au/u/psz/
School of Mathematics and Statistics   University of SydneyAustralia

Bug#905478: Fwd: Re: Debian´s change of "su" to the one in util-linux

[Theodore Y. Ts'o]

On Thu, Aug 09, 2018 at 09:10:57PM +0200, Martin Steigerwald wrote:
> 
> Thing is here: It breaks existing workloads. And I have the gut feeling, 
> not *just* mine. So no matter what long-standing, under-communicated, 
> probably mostly undocumented best practices are in place in your 
> opinion, it IMO is likely to produce an uproar with users once next 
> Debian version is released.

Lots of changes break workloads.  The question is how common is a
particular change.  Heck, people tolerate random perl and pythons
scripts breaking when new versions are released, and that's
considered... OK.

Given that other Linux distributions have been using the "new" su, I
very much doubt that many people will notice.  For that matter, I set
my PATH in .bashrc, so the PATH is *always* reset in a new shell, and
in fact, I make sure I know I'm root so my .bashrc sets the prompt
like this:

 {/usr/projects/e2fsprogs/e2fsprogs}   (next)
1130# 

(And in fact it does this whether I use su or sudo su.  So I didn't
notice at all.)

Anyway, it's ultimately going to be up to Andreas as the Maintainer,
but perhaps you should try to craft some suggested changes to the
News.Debian.gz file, keeping in mind needs to be *short*.  You may
find that it is harder than it seems to write something that is
generally applicable and useful for most users.

> For example how to make available certain environment variables via 
> other means:
> 
> % cat /etc/sudoers.d/defaults 
> Defaultsenv_keep+=SSH_AUTH_SOCK

This doesn't belong in documentation for util-linux, and is
*extremely* specific to what you are trying to do.

As it turns out, I do something very differnt which is my .bashrc will
run ~/.ssh-setup, which looks for existing ssh-agents or gpg-agents,
and if it one doesn't exist, it will start one, e.g.:

   ssh-add -l >& /dev/null
   if test $? = 2 ; then
echo "Starting gpg-agent"
/bin/rm -rf /tmp/ssh-$USER
gpg-agent --daemon --enable-ssh-support --sh  > $HOME/.gpg-agent-info
. $HOME/.gpg-agent-info 2>&1 > /dev/null
   fi

(This is only part of a 40+ line script; just to give you a flavor.)

So there lots and lots of different ways of solving these sorts of
problems, depending on what sort of requirements you might have.
(Mine are designed to work in a very large set of environments, not
all of them running Debian, and for that matter, not all of them are
running Linux)

We can't really give these sorts of tips in the util-linux
Documentation.

Cheers,

- Ted

Bug#905130: hedgewars: FTBFS on armhf (tests fails))

[Lisandro Damián Nicanor Pérez Meyer]

Hi Julian!

On Thu, 9 Aug 2018 at 20:56, Julian Gilbey  wrote:
>
> reopen 905130
> thanks
>
> Hi Lisandro,
>
> I was going to make a report about hedgewars myself, as it seems that
> this package is one of the factors blocking the Qt transition (see
> https://release.debian.org/transitions/html/qtbase-abi-5-11-0.html).
> And then I saw this bug report which looks like it was mistakenly
> closed before being fixed.
>
> Thank you for taking responsibility for this - I do appreciate it!
> I'm reopening the bug report in the meantime so that others can also
> see it is still live.  When you have taken care of it and either fixed
> the bug or removed hedgewars from armhf, then please feel free to
> close it again.

Thanks, but I was not the one who closed it! ;-)

Bug#905802: changetrack: cron script accesses internal dpkg database

[Guillem Jover]

Source: changetrack
Source-Version: 4.7-5
Severity: important
User: debian-d...@lists.debian.org
Usertags: dpkg-db-access-blocker

Hi!

This package contains a cron script [M], which directly accesses
the dpkg internal database. Instead of using one of the public
interfaces provided by dpkg. The code could be replaced with something
like «dpkg-query --showformat '${Conffiles}\n' --show |
grep -E -v '(^\s*|\.schemas)$' | cut -d\  -f2 | sort | uniq».

  [M] debian/cron.daily

This a problem for multiple reasons. Even though the layout and format
of the dpkg database is administrator friendly, and it's expected that
those might need to mess with it, in case of emergency, this interface
does not extend to other programs besides the dpkg suite of tools. The
admindir can also be configured differently at dpkg build or run-time.
And finally, the contents and its format, will be changing in the near
future.

In addition the .conffiles in the database never get updated even after
conffile take overs by another package.

Thanks,
Guillem

Bug#905801: wwwconfig-common: script directly accesses internal dpkg database

[Guillem Jover]

Source: wwwconfig-common
Source-Version: 0.3.0
Severity: important
User: debian-d...@lists.debian.org
Usertags: dpkg-db-access-blocker

Hi!

This package contains a script that directly accesses the dpkg
internal database [S], instead of using the correct public interface
such as «dpkg-query --showformat '${db:Status-Status} ${Package}\n'
--show 'php?.?-*'|grep '^installed '» (also notice that the current
glob will not match current php packages in the archive with N.M
versioning, although perhaps the code should instead be dropped?).

  [S] php-extensions.sh

This a problem for multiple reasons. Even though the layout and format
of the dpkg database is administrator friendly, and it's expected that
those might need to mess with it, in case of emergency, this interface
does not extend to other programs besides the dpkg suite of tools. The
admindir can also be configured differently at dpkg build or run-time.
And finally, the contents and its format, will be changing in the near
future.

Thanks,
Guillem

Bug#905705: plainbox-provider-checkbox: script directly accesses internal dpkg database

[Guillem Jover]

Hi!

On Wed, 2018-08-08 at 11:47:26 +0200, Guillem Jover wrote:
> Source: plainbox-provider-checkbox
> Source-Version: 0.25-2
> Severity: important
> User: debian-d...@lists.debian.org
> Usertags: dpkg-db-access-blocker

[…]
>   * DebianPackageHandler: Use python-apt or python-debian to read and
> parse the status file. A simple parser will give bogus results if
> it is called from within a maintainer script for example, because
> it will not include information from the dpkg journal.

Actually for this last case, I don't see any package currently using
this Modaliases field in the archive. But in any case an easier
replacement would be to use something like:

  dpkg-query -f '${Package} : ${Modaliases}\n" -W

and then filter anything with the second part being empty.

Thanks,
Guillem

Bug#905735: emacs-goodies-el: postinst failure due to missing lcomp.el

[Sebastian P . Luque]

On Wed, 8 Aug 2018 22:50:16 -0400,
Nicholas D Steeves  wrote:

[...]

> It is highly probable that this bug occurred due to breaking changes
> introduced with emacsen-common 3.0.2, rather than from removal of this
> file.

But I have emacsen-common 2.0.8 installed as per the report.


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

> I see you're mixing testing and unstable.  Are you willing to test an
> upgrade to unversioned emacs?  It would be a valuable data-point to
> solving this emacs-goodies-el bug!  If so, please use the following
> procedure:

> # This bit returns goodies to the state it was for Stretch
> apt purge --autoremove emacs-goodies-el
> wget 
> https://snapshot.debian.org/archive/debian/20161122T032842Z/pool/main/e/emacs-goodies-el/emacs-goodies-el_36.3_all.deb
> # this next line might be paranoia
> apt autoremove --purge
> # and finally install the package
> dpkg -i emacs-goodies-el_36.3_all.deb

> # This installs emacs-goodies-el from stretch, and will pull in the
> new unversioned emacs.  Please note the list of packages, in case you
> need to roll back.
> apt install emacs-goodies-el=40.1

The last step failed for me:

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

The following packages have unmet dependencies:
 emacs-goodies-el : Depends: emacsen-common (>= 3.0.2) but 2.0.8 is to be 
installed
Recommends: elpa-bm but it is not installable
E: Unable to correct problems, you have held broken packages.
------

But succeeded by letting it choose my default testing version of the
package (40.0):

------
$ sudo aptitude safe-upgrade 
The following packages will be upgraded: 
  emacs-goodies-el 
1 packages upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 0 B/96.4 kB of archives. After unpacking 3,177 kB will be freed.
Do you want to continue? [Y/n/?] y
Reading changelogs... Done   
(Reading database ... 682251 files and directories currently installed.)
Preparing to unpack .../emacs-goodies-el_40.0_all.deb ...
Remove emacs-goodies-el for emacs25
remove/emacs-goodies-el: purging byte-compiled files for emacs25
Unpacking emacs-goodies-el (40.0) over (36.3) ...
Processing triggers for install-info (6.5.0.dfsg.1-4) ...
Setting up emacs-goodies-el (40.0) ...
Install emacsen-common for emacs25
emacsen-common: Handling install of emacsen flavor emacs25
Install emacs-goodies-el for emacs25
install/emacs-goodies-el: Handling emacs25, logged in /tmp/elc_b2o0sx.log
Building autoloads for emacs25 in /usr/share/emacs25/site-lisp/emacs-goodies-el
install/emacs-goodies-el: Deleting /tmp/elc_b2o0sx.log
 
Current status: 0 (-1) upgradable.
------

Thank you for your quick follow-up and hopefully this is useful.

-- 
Seb

Bug#897857:

[Michael Hudson-Doyle]

On Fri, 10 Aug 2018 at 09:37, Olly Betts  wrote:

> On Thu, Aug 02, 2018 at 09:23:26PM +1200, Michael Hudson-Doyle wrote:
> > upstream just "fixed" this by disabling the warning, fwiw
>
> This bug was reported in setools but reassigned to swig - I think you
> must mean "setools" by "upstream" there?
>

Ah yes. Sorry for the lack of clarity.


> I actually addressed this upstream in SWIG back in May (by fixing the
> generated code rather than disabling the warning), but there's not
> been a release in a while.  I'll take a look and see if the fix can be
> backported to the Debian package.  The potential problem is that it was
> after clean-up of support for older Python versions, and it seems
> unhelpful in the wider context for the Debian swig package to generate
> code which supports a narrower range of Python versions than the
> corresponding upstream SWIG version.
>

Hm yes. On some level it would be fine to only support versions of Python
supported by Debian, but on another that would be a bit hostile.


> Ignoring the warning is reasonable.  The code in question does invoke
> undefined behaviour, but it should be safe in practice with the calling
> conventions used on Linux.
>

I agree.


> Compiling packages with -Werror seems unwise in general, but I really
> wouldn't recommend compiling SWIG-generated code in packages with
> -Werror.
>

Totally agree! It's fine to use it during development but using it in
distributed source is just a timebomb.

Cheers,
mwh

Bug#905140: [Pkg-cmake-team] Bug#905140: Bug #905140 in cmake marked as pending

[Felix Geyer]

Hi,

On 09.08.2018 22:38, Svante Signell wrote:

Hello,

What about the bugs with patches, e.g. for Hurd and kFreeBSD. Still
somebody needs to NMU this package... You don't seem interested in
fixing bugs to your package, except RC ones.

Not the ideal way Debian maintainers should work with their packages...


Instead of making wild accusations I suggest that instead you respond
to questions on bugs you opened.
I'm not interested in maintaining patches for things that clearly belong 
upstream.
Once upstream has reviewed the changes I'm happy to cherry-pick them.

#905138 on 2018-08-01:

Have you forwarded your non-packaging changes upstream to cmake / libuv
(#905140 is already fixed in 3.12)?
I really don't want to carry those as patches.


The same applies to #900240

Cheers,
Felix

Bug#905800: thunderbird: Offline detection does not discover connection going back online

[Gregor Riepl]

Package: thunderbird
Version: 1:60.0~b10-1
Severity: normal

Dear Maintainer,

Thunderbird correctly identifies an internet connection that has gone offline.

However, it will still report 'offline' status when internet connectivity is
available again.
It's impossible to restore 'online' status unless Thunderbird is restarted.

Online functionality works fine in this state, but the 'offline' status is very
annoying and may lead to other problems.

I've experienced similar issues in Firefox (on certain web sites), so it seems
to me that 'online' status detection doesn't work reliably on Linux.

Thanks.



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

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

Versions of packages thunderbird depends on:
ii  debianutils   4.8.6
ii  fontconfig2.13.0-5
ii  libatk1.0-0   2.28.1-1
ii  libc6 2.27-5
ii  libcairo-gobject2 1.15.10-3
ii  libcairo2 1.15.10-3
ii  libdbus-1-3   1.12.10-1
ii  libdbus-glib-1-2  0.110-2
ii  libevent-2.1-62.1.8-stable-4
ii  libffi6   3.2.1-8
ii  libfontconfig12.13.0-5
ii  libfreetype6  2.8.1-2
ii  libgcc1   1:8.2.0-1
ii  libgdk-pixbuf2.0-02.36.12-1
ii  libglib2.0-0  2.56.1-2
ii  libgtk-3-03.22.30-2
ii  libgtk2.0-0   2.24.32-2
ii  libhunspell-1.6-0 1.6.2-1+b1
ii  libicu60  60.2-6
ii  libjsoncpp1   1.7.4-3
ii  libnspr4  2:4.19-3
ii  libnss3   2:3.38-1
ii  libpango-1.0-01.42.1-2
ii  libpangocairo-1.0-0   1.42.1-2
ii  libpangoft2-1.0-0 1.42.1-2
ii  libsqlite3-0  3.24.0-1
ii  libstartup-notification0  0.12-5
ii  libstdc++68.2.0-1
ii  libvpx5   1.7.0-3
ii  libx11-6  2:1.6.5-1
ii  libx11-xcb1   2:1.6.5-1
ii  libxcb-shm0   1.13-2
ii  libxcb1   1.13-2
ii  libxext6  2:1.3.3-1+b2
ii  libxrender1   1:0.9.10-1
ii  libxt61:1.1.5-1
ii  psmisc23.1-1+b1
ii  x11-utils 7.7+4
ii  zlib1g1:1.2.11.dfsg-1

Versions of packages thunderbird recommends:
ii  hunspell-de-ch [hunspell-dictionary] 20161207-5
ii  hunspell-de-de [hunspell-dictionary] 20161207-5
ii  hunspell-en-gb [hunspell-dictionary] 1:6.0.5-1
ii  hunspell-en-us [hunspell-dictionary] 1:2018.04.16-1
ii  hunspell-fr-classical [hunspell-dictionary]  1:6.2-1
ii  lightning1:60.0~b10-1

Versions of packages thunderbird suggests:
ii  apparmor  2.13-8
ii  fonts-lyx 2.3.0-2
ii  libgssapi-krb5-2  1.16-2

-- no debconf information

Bug#898113: ltrace crashes and hangs on armhf

[Petter Reinholdtsen]

[Christoph Biedl
> Tried to handle this bug but it seems this fix doesn't help - and
> honestly I fail to see how adding a definition in
> sysdeps/linux-gnu/arm/plt.c should help against the problem.

I tested the patch, and can confirm that it did not change anything
on armhf (abel.debian.org).  I suspect the correct fix for Debian is
to add a configure test to detect when PTRACE_SINGLESTEP is not
supported, and ask ftpmasters to remove the binary packages from all
arm architectures.  The alternative is to rewrite ltrace to use a
different kernel mechanism for tracing, and that is more than one
can ask of the Debian package maintainer. :)

I found this in NEWS in the source tarball:

  *** [arm] Tracing is not supported at all on ARM

ltrace might work on older kernels, but no attempt was made to
fully support it.  Newer kernels don't support PTRACE_SINGLESTEP,
which ltrace depends on.  Before singlestepping is implemented in
software, ARM is considered unsupported.

It seem prettly clear to me that until arm handle PTRACE_SINGLESTEP,
ltrace will not work on arm.

Note, the readdir_r() patch is already part of the ltrace package, applied
using debian/patches/deprecated-readdir_r.diff.

-- 
Happy hacking
Petter Reinholdtsen

Bug#773663: Updated patch for popcon tor support

[Bill Allombert]

On Thu, Aug 09, 2018 at 07:55:00AM +, Niels Thykier wrote:
> On Sun, 20 May 2018 15:50:16 +0200 Bill Allombert 
> wrote:
> > [...]
> > 
> > Thanks! (and apologies to Tim to have missed the opportunuity to check Tim
> >  original popularity-contest.gpg report).
> > 
> > I have received it just one (via http) on Sun May 20 08:02:01 UTC 2018
> > (however popcon cron.daily has a mechanism to prevent multiple submissions
> > in the same week).
> > 
> 
> Great, thanks for verifying.  :)
> 
> > >  I have attached the .gpg file.  I used
> > > the ".new" file because it seems that the popularity-contest.new.gpg is
> > > not renamed to popularity-contest.gpg any longer.
> > 
> > Yes this was changed in 1.65 (maybe by mistake) to fix bug 850568.
> > 
> > The only drawback I see is that tor has a number of dependencies that
> > will always appear as 'recently used' in popcon report. However if tor
> > is used regularly anyway this is not an issue.
> > 
> > I will apply the patch for popularity-contest 1.67
> > 
> > Cheers,
> > -- 
> > Bill. 
> > 
> > Imagine a large red swirl here. 
> > 
> > 
> 
> Excellent, I am looking forward to it. :) Do you have an estimate of
> when 1.67 will be in unstable?

Now. Sorry I prepared the package one month ago, tested it (which is
slow) and then forgot to upload it. Thanks for the remainder!

Cheers,
Bill.

Bug#897857:

[Olly Betts]

On Thu, Aug 02, 2018 at 09:23:26PM +1200, Michael Hudson-Doyle wrote:
> upstream just "fixed" this by disabling the warning, fwiw

This bug was reported in setools but reassigned to swig - I think you
must mean "setools" by "upstream" there?

I actually addressed this upstream in SWIG back in May (by fixing the
generated code rather than disabling the warning), but there's not
been a release in a while.  I'll take a look and see if the fix can be
backported to the Debian package.  The potential problem is that it was
after clean-up of support for older Python versions, and it seems
unhelpful in the wider context for the Debian swig package to generate
code which supports a narrower range of Python versions than the
corresponding upstream SWIG version.

Ignoring the warning is reasonable.  The code in question does invoke
undefined behaviour, but it should be safe in practice with the calling
conventions used on Linux.

Compiling packages with -Werror seems unwise in general, but I really
wouldn't recommend compiling SWIG-generated code in packages with
-Werror.  We do try upstream to keep the generated code warning-free,
but it's common for new compiler versions to result in new warnings, and
there are cases where it's hard to avoid the warnings (indeed even after
my fix you can still get this warning when keyword argument support is
enabled, because the Python C API inherently relies on casting function
pointers to a different type of function pointer when METH_KEYWORD is
used).

Cheers,
Olly

Bug#905791: RFS: swapspace/1.14-1 [ITA]

[Jacob Adams]

On 08/09/2018 04:25 PM, Adam Borowski wrote:
> On Thu, Aug 09, 2018 at 12:43:22PM -0400, Jacob Adams wrote:
>>  * Package name: swapspace
>>Version : 1.14-1
> 
>>   swapspace (1.14-1) unstable; urgency=medium
>>
>>   * New maintainer. (Closes: #725821)
>>   * Redo packaging with debhelper 11 (Closes: #866272)
>>   * Account for memory allocated to /dev/shm (Closes: #691128)
>>   * Removed swapd conflict as swapd was removed from Debian in 2010
>>   * Fix minor manual page typo
> 
> Hi!
> This is bad:
> Files in second .deb but not in first
> -
> -rw-r--r--  root/root   /lib/systemd/system/swapspace.service
> [...]
> 
> Files in first .deb but not in second
> -
> [...]
> -rwxr-xr-x  root/root   /etc/init.d/swapspace
> 
> 
> And this is not even an upstream change, but a regression in the packaging:
> --- swapspace-1.10/debian/swapspace.init2018-08-09 20:58:32.0 
> +0200
> +++ swapspace-1.14/debian/swapspace.init1970-01-01 01:00:00.0 
> +0100
> 
> 
> While some people may decide to use systemd, your change breaks the package
> for everyone else.  That shouldn't be done without a very good reason.

Apologizes. Accidentally dropped the file when reshuffling everything to
debhelper 11.

Fixed and reuploaded.

Thanks for keeping me accountable.

Jacob




signature.asc
Description: OpenPGP digital signature

Bug#905774: jackd2: jackd no longer starts, since device is already in use; but who's using it?

[Francesco Poli]

On Thu, 09 Aug 2018 19:34:52 +0200 Jonas Smedegaard wrote:

> Quoting Francesco Poli (2018-08-09 19:07:50)
[...]
> > All this makes perfectly sense: timidity pulled timidity-daemon by 
> > recommendation. Moreover recently, the recommendation has been turned 
> > into a suggestion.
> 
> If I am not mistaken about english grammar...
> 
> either it "perfectly makes sense" or it "makes perfect sense"
> 

I think you're right, thanks for correcting me!

> 
> 
> > OK, this leaves me with the need to understand why package "timidity" 
> > is installed on that machine, while it is not on the other similar 
> > one. I am pretty sure I haven't installed timidity by hand...
> 
> I cannot tell how your system specifically ended in that state, but 
> timidity historically got auto-installed frequently (to me) like this:
> 
>  $stuff → libsdl-mixer1.2 → freepats → timidity
> 
> My guess is that somehow (e.g. by using aptitude back when it had its 
> own its own independent tracking of auto-installed packages which then 
> got merged when APT grew support for that - I experienced some loss of 
> flags during that period) your system lost the auto-install flag for 
> timidity-daemon, keeping it around beyond removal of other packages and 
> package relationships getting relaxed.

It could be, except that timidity-daemon still had the auto-install
flag and timidity has it as well...



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


pgp_UYBZtK_4T.pgp
Description: PGP signature

Bug#889557: ovito: (Build-)Depends on obsolete libbotan1.10-dev

[Chris Hofstaedtler]

Dear ovito Maintainers,

is there any update on progress of porting to botan2, or at least
moving off botan1.10?

Cheers,
Chris

Bug#889556: monotone: (Build-)Depends on obsolete libbotan1.10-dev

[Chris Hofstaedtler]

Hi Markus,

* Markus Wanner  [180809 20:52]:
> On 03/09/2018 10:32 AM, Jack Lloyd wrote:
> > 2.4.0 was just (in last week or so) packaged for buster -
> >  https://packages.debian.org/buster/libbotan-2-4
> 
> oh, very nice. Looks like I searched only "stable". Thank you for the hint.

Is there any update on progress of switching to botan2 for monotone?

Cheers,
Chris

Bug#896085: tk8.5: Time to remove from Debian

[Chris Hofstaedtler]

Control: clone 896085 -2
Control: reassign -2 ftp.debian.org
Control: retitle -2 RM: tk8.5 -- ROQA; obsolete
Control: affects -2 src:tk8.5

* Sergei Golovan  [180809 20:47]:
> Source: tk8.5
> 
> Tcl/Tk 8.5 has reached its end-of-life, so it's time to remove it from Debian.
> Applications which use Tcl/Tk should switch to 8.6 which is available
> for a few years already.

netgen has just moved off tk8.5 in unstable, so the current status is:

Will remove the following packages from unstable:

  libtk8.5 |   8.5.19-3 | amd64, arm64, armel, armhf, hurd-i386, i386, 
kfreebsd-amd64, kfreebsd-i386, mips, mips64el, mipsel, ppc64el, s390x
 tk8.5 |   8.5.19-3 | source, amd64, arm64, armel, armhf, hurd-i386, i386, 
kfreebsd-amd64, kfreebsd-i386, mips, mips64el, mipsel, ppc64el, s390x
 tk8.5-dev |   8.5.19-3 | amd64, arm64, armel, armhf, hurd-i386, i386, 
kfreebsd-amd64, kfreebsd-i386, mips, mips64el, mipsel, ppc64el, s390x
 tk8.5-doc |   8.5.19-3 | all

Maintainer: Debian Tcl/Tk Packagers 

--- Reason ---

--

Checking reverse dependencies...
# Broken Depends:
netgen: netgen [hurd-i386 kfreebsd-amd64 kfreebsd-i386]
oce: oce-draw [kfreebsd-amd64 kfreebsd-i386]

oce is BD-Uninstallable on kfreebsd* for 91 days.
netgen is BD-Uninstallable on hurd, kfreebsd*.

Thanks,
Chris

Bug#905140: Bug #905140 in cmake marked as pending

[Svante Signell]

Hello,

What about the bugs with patches, e.g. for Hurd and kFreeBSD. Still
somebody needs to NMU this package... You don't seem interested in 
fixing bugs to your package, except RC ones.

Not the ideal way Debian maintainers should work with their packages...

On Thu, 2018-08-09 at 19:58 +, Felix Geyer wrote:
> Control: tag -1 pending
> 
> Hello,
> 
> Bug #905140 in cmake reported by you has been fixed in the
> Git repository and is awaiting an upload. You can see the commit
> message below, and you can check the diff of the fix at:
> 
> https://salsa.debian.org/cmake-team/cmake/commit/12de5624a18704f1a9d7
> 368a3267b7dddea0b3ec
> 
> ---
> -
> New upstream release.
> 
> Fixes FTBFS with recent version of libuv1. (Closes: #905140)
> 
> ---
> -
> 
> (this message was generated automatically)

Bug#904340: Fixed, close bug

[Anton Gladky]

fixed 904340 6.2.1804+dfsg1-1
thanks

The newest netgen does not depent on any
particular tk version. Closing the bug.

Regards

Anton

Bug#905798: tiff: CVE-2018-15209

[Salvatore Bonaccorso]

Source: tiff
Version: 4.0.9-6
Severity: important
Tags: security upstream
Forwarded: http://bugzilla.maptools.org/show_bug.cgi?id=2808

Hi,

The following vulnerability was published for tiff.

CVE-2018-15209[0]:
| ChopUpSingleUncompressedStrip in tif_dirread.c in LibTIFF 4.0.9 allows
| remote attackers to cause a denial of service (heap-based buffer
| overflow and application crash) or possibly have unspecified other
| impact via a crafted TIFF file, as demonstrated by tiff2pdf.

The issue is demostrable on a 32bit sid system under valgrind as well:

[...]
==2695== Invalid write of size 4
==2695==at 0x485BEF2: ChopUpSingleUncompressedStrip (tif_dirread.c:5723)
==2695==by 0x485BEF2: TIFFReadDirectory (tif_dirread.c:4186)
==2695==by 0x4880257: TIFFClientOpen (tif_open.c:466)
==2695==by 0x488E632: TIFFFdOpen (tif_unix.c:211)
==2695==by 0x488E71D: TIFFOpen (tif_unix.c:250)
==2695==by 0x10965E: main (tiff2pdf.c:753)
==2695==  Address 0x5c11028 is 0 bytes after a block of size 12,058,624 alloc'd
==2695==at 0x483019B: malloc (vg_replace_malloc.c:298)
==2695==by 0x483245C: realloc (vg_replace_malloc.c:785)
==2695==by 0x488E7FB: _TIFFrealloc (tif_unix.c:336)
==2695==by 0x484EE57: _TIFFCheckRealloc (tif_aux.c:73)
==2695==by 0x484EEC5: _TIFFCheckMalloc (tif_aux.c:88)
==2695==by 0x485BE87: ChopUpSingleUncompressedStrip (tif_dirread.c:5701)
==2695==by 0x485BE87: TIFFReadDirectory (tif_dirread.c:4186)
==2695==by 0x4880257: TIFFClientOpen (tif_open.c:466)
==2695==by 0x488E632: TIFFFdOpen (tif_unix.c:211)
==2695==by 0x488E71D: TIFFOpen (tif_unix.c:250)
==2695==by 0x10965E: main (tiff2pdf.c:753)
==2695==
==2695== Invalid write of size 4
==2695==at 0x485BEF5: ChopUpSingleUncompressedStrip (tif_dirread.c:5723)
==2695==by 0x485BEF5: TIFFReadDirectory (tif_dirread.c:4186)
==2695==by 0x4880257: TIFFClientOpen (tif_open.c:466)
==2695==by 0x488E632: TIFFFdOpen (tif_unix.c:211)
==2695==by 0x488E71D: TIFFOpen (tif_unix.c:250)
==2695==by 0x10965E: main (tiff2pdf.c:753)
==2695==  Address 0x5c1102c is 4 bytes after a block of size 12,058,624 alloc'd
==2695==at 0x483019B: malloc (vg_replace_malloc.c:298)
==2695==by 0x483245C: realloc (vg_replace_malloc.c:785)
==2695==by 0x488E7FB: _TIFFrealloc (tif_unix.c:336)
==2695==by 0x484EE57: _TIFFCheckRealloc (tif_aux.c:73)
==2695==by 0x484EEC5: _TIFFCheckMalloc (tif_aux.c:88)
==2695==by 0x485BE87: ChopUpSingleUncompressedStrip (tif_dirread.c:5701)
==2695==by 0x485BE87: TIFFReadDirectory (tif_dirread.c:4186)
==2695==by 0x4880257: TIFFClientOpen (tif_open.c:466)
==2695==by 0x488E632: TIFFFdOpen (tif_unix.c:211)
==2695==by 0x488E71D: TIFFOpen (tif_unix.c:250)
==2695==by 0x10965E: main (tiff2pdf.c:753)
==2695==
==2695== Invalid write of size 4
==2695==at 0x485BF17: ChopUpSingleUncompressedStrip (tif_dirread.c:5724)
==2695==by 0x485BF17: TIFFReadDirectory (tif_dirread.c:4186)
==2695==by 0x4880257: TIFFClientOpen (tif_open.c:466)
==2695==by 0x488E632: TIFFFdOpen (tif_unix.c:211)
==2695==by 0x488E71D: TIFFOpen (tif_unix.c:250)
==2695==by 0x10965E: main (tiff2pdf.c:753)
==2695==  Address 0x6792028 is 0 bytes after a block of size 12,058,624 alloc'd
==2695==at 0x483019B: malloc (vg_replace_malloc.c:298)
==2695==by 0x483245C: realloc (vg_replace_malloc.c:785)
==2695==by 0x488E7FB: _TIFFrealloc (tif_unix.c:336)
==2695==by 0x484EE57: _TIFFCheckRealloc (tif_aux.c:73)
==2695==by 0x484EEC5: _TIFFCheckMalloc (tif_aux.c:88)
==2695==by 0x485BEA7: ChopUpSingleUncompressedStrip (tif_dirread.c:5703)
==2695==by 0x485BEA7: TIFFReadDirectory (tif_dirread.c:4186)
==2695==by 0x4880257: TIFFClientOpen (tif_open.c:466)
==2695==by 0x488E632: TIFFFdOpen (tif_unix.c:211)
==2695==by 0x488E71D: TIFFOpen (tif_unix.c:250)
==2695==by 0x10965E: main (tiff2pdf.c:753)
==2695==
==2695== Invalid write of size 4
==2695==at 0x485BF1B: ChopUpSingleUncompressedStrip (tif_dirread.c:5724)
==2695==by 0x485BF1B: TIFFReadDirectory (tif_dirread.c:4186)
==2695==by 0x4880257: TIFFClientOpen (tif_open.c:466)
==2695==by 0x488E632: TIFFFdOpen (tif_unix.c:211)
==2695==by 0x488E71D: TIFFOpen (tif_unix.c:250)
==2695==by 0x10965E: main (tiff2pdf.c:753)
==2695==  Address 0x679202c is 4 bytes after a block of size 12,058,624 alloc'd
==2695==at 0x483019B: malloc (vg_replace_malloc.c:298)
==2695==by 0x483245C: realloc (vg_replace_malloc.c:785)
==2695==by 0x488E7FB: _TIFFrealloc (tif_unix.c:336)
==2695==by 0x484EE57: _TIFFCheckRealloc (tif_aux.c:73)
==2695==by 0x484EEC5: _TIFFCheckMalloc (tif_aux.c:88)
==2695==by 0x485BEA7: ChopUpSingleUncompressedStrip (tif_dirread.c:5703)
==2695==by 0x485BEA7: TIFFReadDirectory (tif_dirread.c:4186)
==2695==by 0x4880257: TIFFClientOpen (tif_open.c:466)
==2695==by 0x488E632: TIFFFdOpen (tif_unix.c:211)
==2695==by 0x488E71D: TIFFOpen (tif_unix.c:250)
==2695==   

Bug#905797: psmisc: FTBFS on hurd-i386

[Svante Signell]

Source: psmisc
Version: 23.1-1
Severity: important
Tags: patch
User: debian-h...@lists.debian.org
Usertags: hurd

Hi,

Currently the latest version of psmisc fails to build from source and
is flagged as out-of-date. This is due to usage of PATH_MAX, which is
not defined on GNU/Hurd. The attached patch solve this problem by
dynamically allocating space for the strings 'fullpath, linkpath and
buf' in main() of src/pslog.c and freeing it when not needed any
longer.

Thanks!
Index: psmisc-23.1/src/pslog.c
===
--- psmisc-23.1.orig/src/pslog.c
+++ psmisc-23.1/src/pslog.c
@@ -26,6 +26,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -100,30 +101,37 @@ main(int argc, char const *argv[])
 
   struct dirent *namelist;
 
-  char* fullpath = (char*) malloc(PATH_MAX+1);
-  if (!fullpath) {
-perror ("malloc");
+  char *fullpath = NULL, *linkpath = NULL;
+  ssize_t linkname_size;
+  size_t len = 0;
+  int nbytes;
+  struct stat sb;
+  char *buf = NULL;
+  DIR *pid_dir;
+
+  if (argv[1][0] != '/')
+len = snprintf(NULL, 0, "/proc/%s/fd/", argv[1]);
+  else
+len = snprintf(NULL, 0, "%s/fd/", argv[1]);
+  if (len < 0)
 return 1;
-  }
+  len++;
 
-  char* linkpath = (char*) malloc(PATH_MAX+1);
-  if (!linkpath) {
+  fullpath = (char*) malloc(len);
+  if (fullpath == NULL) {
 perror ("malloc");
 return 1;
   }
 
-  ssize_t linkname_size;
-  char buf[PATH_MAX+1];
-  DIR *pid_dir;
+  if (argv[1][0] != '/')
+   nbytes = snprintf(fullpath, len, "/proc/%s/fd/", argv[1]);
+  else
+nbytes = snprintf(fullpath, len, "%s/fd/", argv[1]);
 
-  if (argv[1][0] != '/') {
-strncpy(fullpath, "/proc/", PATH_MAX);
-strncat(fullpath, argv[1], PATH_MAX - strlen(fullpath));
-strncat(fullpath, "/fd/", PATH_MAX - strlen(fullpath));
-  } else {
-  strncpy(fullpath, argv[1], PATH_MAX);
-  strncat(fullpath, "/fd/", PATH_MAX - strlen(fullpath));
-}
+  if (nbytes < 0 || nbytes >= len) {
+perror("snprintf");
+return 1;
+  }
 
   pid_dir = opendir(fullpath);
   if (!pid_dir) {
@@ -134,11 +142,44 @@ main(int argc, char const *argv[])
   fprintf(stdout, "Pid no %s:\n", argv[1]);
 
   while((namelist = readdir(pid_dir))) {
-strncpy(linkpath, fullpath, PATH_MAX);
-strncat(linkpath, namelist->d_name, PATH_MAX - strlen(linkpath));
-linkname_size = readlink(linkpath, buf, PATH_MAX -1);
-buf[linkname_size+1] = '\0';
+len = snprintf(NULL, 0, "%s%s", fullpath, namelist->d_name);
+len++;
+linkpath = (char*) malloc(len);
+if (linkpath == NULL) {
+  perror ("malloc");
+  return 1;
+}
+nbytes = snprintf(linkpath, len, "%s%s", fullpath, namelist->d_name);
+if (nbytes < 0 || nbytes >= len) {
+  perror("snprintf");
+  return 1;
+}
+if(lstat(linkpath, ) == -1) {
+  perror("lstat");
+  return 1;
+}
+
+if (sb.st_size == 0) {
+  perror("lstat");
+  return 1;
+}
+len = sb.st_size + 1;
+buf = (char*)malloc(len);
+if (buf == NULL) {
+  perror ("malloc");
+  return 1;
+}
+linkname_size = readlink(linkpath, buf, len);
+if (linkname_size == -1) {
+  perror("readlink");
+  return 1;
+}
 
+buf[linkname_size] = '\0';
+if (linkname_size == len) {
+  perror("readlink: truncated buffer");
+  return 1;
+}
 if (regexec(_log, buf, 0, NULL, 0) == 0) {
   fprintf(stdout, "Log path: %s\n", buf);
 }
@@ -148,6 +189,7 @@ main(int argc, char const *argv[])
 
   free(linkpath);
   free(fullpath);
+  free(buf);
   regfree(_log);
 
   if (closedir(pid_dir)) {

Bug#903851: DBUS? Continuing Problems after migration to "testing"

[Thomas Hardman]

The saga continues. After several 'apt-get update ; apt-get dist-upgrade'
cycles, and taking advice to look in the logs, I found nothing that helped
me much.

Trying an experiment, I set the default boot to the multi-user.target
rather than the graphical.target.

The system, in that case, boots as expected, fully and without any obvious
error. Errors appear when trying 'startx' . Examining /var/log/Xorg.0.log,
as follow:

==[trimmed beginning]
[   313.980] (II) NVIDIA(0): Virtual screen size determined to be 1920 x
1080
[   313.983] (--) NVIDIA(0): DPI set to (30, 30); computed from
"UseEdidDpi" X config
[   313.983] (--) NVIDIA(0): option
[   313.983] (II) NVIDIA: Using 6144.00 MB of virtual memory for indirect
memory
[   313.983] (II) NVIDIA: access.
[   314.011] (EE) NVIDIA(0): Failed to allocate software rendering cache
surface: out of
[   314.011] (EE) NVIDIA(0): memory.
[   314.011] (EE) NVIDIA(0):  *** Aborting ***
[   314.015] (EE)
Fatal server error:
[   314.015] (EE) NVIDIA: A GPU exception occurred during X server
initialization(EE)
[   314.015] (EE)
Please consult the The X.Org Foundation support
 at http://wiki.x.org
 for help.
[   314.015] (EE) Please also check the log file at "/var/log/Xorg.0.log"
for additional information.
[   314.015] (EE)
[   314.067] (EE) Server terminated with error (1). Closing log file.
==

I have seen this before and will have to go back to notes to revisit that.

Further: attempting to change runlevel with 'systemctl start
graphical.target' or simply to start the SDDM greeter with `sudo service
sddm start` results in the exact same screen flashing that characterized
failed boot in graphical.target unattended boot. Looking at
/var/log/sddm.log I see:

==
[01:18:25.569] (II) DAEMON: Initializing...
[01:18:25.572] (II) DAEMON: Starting...
[01:18:25.572] (II) DAEMON: Adding new display on vt 7 ...
[01:18:25.572] (II) DAEMON: Display server starting...
[01:18:25.572] (II) DAEMON: Running: /usr/bin/X -nolisten tcp -auth
/var/run/sddm/{052cc01f-c90c-4c2f-a993-00b37ef851ce} -background none
-noreset -displayfd 18 vt7
[01:18:25.685] (EE) DAEMON: Display server failed to start. Exiting
[15:52:57.165] (II) DAEMON: Initializing...
[15:52:57.182] (II) DAEMON: Starting...
[15:52:57.182] (II) DAEMON: Logind interface found
[15:52:57.182] (II) DAEMON: Adding new display on vt 7 ...
[15:52:57.184] (II) DAEMON: Loading theme configuration from ""
[15:52:57.184] (II) DAEMON: Display server starting...
[15:52:57.184] (II) DAEMON: Running: /usr/bin/X -nolisten tcp -auth
/var/run/sddm/{6006e77c-79a4-4ad4-a791-85cea1e0e1e3} -background none
-noreset -displayfd 17 -seat seat0 vt7
[15:52:58.161] (EE) DAEMON: Failed to read display number from pipe
[15:52:58.162] (EE) DAEMON: Display server failed to start. Exiting

==

Very strangely, and this may be a pointer to a solution, although I cannot
start X from the commandline after an unattended standard boot into
multi-user.target, by booting into rescue mode and manually starting D-Bus
and invoking the graphic interface with `service dbus start ;  systemctl
start graphical.target` I get a working SDDM screen and can log in and use
Cinnamon, including applications such as Firefox ESR so that I can submit
this report from that machine.

So: I will characterize this as a bug with SDDM and/or X. Possibly SDDM
needs to be rebuilt against the latest nvidia drivers and libraries, I seem
to recall that may be one way to resolve that issue. I'll try that later,
but thought I should report this.

Incidentally, D-Bus may be only incidentally or peripherally involved.
Under the semi-successful boot to multi-user.target, I do find this
grepping in the journal.log:

Aug 09 15:38:30 nasty-1 systemd[1]: Listening on D-Bus System Message Bus
Socket.
Aug 09 15:38:30 nasty-1 systemd[1]: Started D-Bus System Message Bus.
Aug 09 15:38:30 nasty-1 systemd[1]: Starting LVM2 D-Bus service...
Aug 09 15:38:31 nasty-1 NetworkManager[846]:   [1533843511.0813]
bus-manager: acquired D-Bus service "org.freedesktop.NetworkManager"
Aug 09 15:38:31 nasty-1 systemd[1]: Started LVM2 D-Bus service.
Aug 09 15:39:03 nasty-1 systemd[2247]: Starting D-Bus User Message Bus
Socket.
Aug 09 15:39:03 nasty-1 systemd[2247]: Listening on D-Bus User Message Bus
Socket.

Thanks for your help, if I get this solved I'll let you know so this can be
closed or marked resolved as you deem fit.

Regards,



On Sun, Jul 29, 2018 at 7:12 AM Simon McVittie  wrote:

> Control: retitle -1 dbus-daemon does not start, perhaps related to having
> a separate /var
>
> On Sat, 28 Jul 2018 at 15:25:47 -0400, Thomas Hardman wrote:
> > I have /var on a "spinner" drive along with /home and /tmp, and /  and
> /usr are
> > on two different partitions of an NVME/PCIe solid-state drive.
> >
> > /etc/fstab mounts these partitions from the "spinner" drive using UUID
> rather
> > than calling (for example) /dev/sda1 to mount on /var. Possibly
> irrelevant.
> >
> > Is it possible that 

Bug#905791: RFS: swapspace/1.14-1 [ITA]

[Adam Borowski]

On Thu, Aug 09, 2018 at 12:43:22PM -0400, Jacob Adams wrote:
>  * Package name: swapspace
>Version : 1.14-1

>   swapspace (1.14-1) unstable; urgency=medium
> 
>   * New maintainer. (Closes: #725821)
>   * Redo packaging with debhelper 11 (Closes: #866272)
>   * Account for memory allocated to /dev/shm (Closes: #691128)
>   * Removed swapd conflict as swapd was removed from Debian in 2010
>   * Fix minor manual page typo

Hi!
This is bad:
Files in second .deb but not in first
-
-rw-r--r--  root/root   /lib/systemd/system/swapspace.service
[...]

Files in first .deb but not in second
-
[...]
-rwxr-xr-x  root/root   /etc/init.d/swapspace


And this is not even an upstream change, but a regression in the packaging:
--- swapspace-1.10/debian/swapspace.init2018-08-09 20:58:32.0 
+0200
+++ swapspace-1.14/debian/swapspace.init1970-01-01 01:00:00.0 
+0100


While some people may decide to use systemd, your change breaks the package
for everyone else.  That shouldn't be done without a very good reason.


Meow.
-- 
⢀⣴⠾⠻⢶⣦⠀ So a Hungarian gypsy mountainman, lumberjack by day job,
⣾⠁⢰⠒⠀⣿⡁ brigand by, uhm, hobby, invented a dish: goulash on potato
⢿⡄⠘⠷⠚⠋⠀ pancakes.  Then the Polish couldn't decide which of his
⠈⠳⣄ adjectives to use for the dish's name.

Bug#889003: Fixed, close bug

[Anton Gladky]

fixed 889003 6.2.1804+dfsg1-1
thanks

The newest netgen was successfullly built in the sid
against current libtogl-dev. Closing the bug.

Regards


Anton

Bug#905409: upgrade of util-linux and login break the xhost command for other users

[Davide Prina]

On 09/08/2018 21:06, Helge Kreutzmann wrote:


+Use a separate X display (e.g. "Switch User" in GNOME, or the equivalent 
fast-user-switching feature in other desktop environments),


here probably it is better to say that the user can switch from one to 
other user with the Ctrl-Alt-Fx keys



+Use ssh, e.g. "ssh -X -oForwardX11Trusted=no otheruser@localhost".


and here, I think it is better to write somethings like:
+Use ssh, e.g. "ssh -X -oForwardX11Trusted=no $OTHERUSER@$LOCALHOST".
+Where $OTHERUSER is the user you want to use to execute commands
+and $LOCALHOST is your localhost (it can be: localhost, 127.0.0.1, ...)

and probably it is better to mention that you need sshd process active 
in your system (you must install openssh-server).


I don't know if it is better to evidence that with this solution you can 
have performance problems and not all can work correctly as you expected.



+Allow \fBsu\fR explicit display access by issuing "xhost 
+si:localuser:otheruser" in


and here, I think it is better to write somethings like:
+explicit display access by issuing "xhost +si:localuser:$OTHERUSER"
...


+the originating X session and "DISPLAY=:0 command" under \fBsu\fR.


and here
+the originating X session and "DISPLAY=:0 $COMMAND" under \fBsu\fR.
+or export the DISPLAY variable as "export DISPLAY=:0"
+and then execute all the commands with GUI you like: "$COMMAND &"
+where $COMMAND is the GUI command you like to exec (eg: qcalculate &)

Probably it is better to put some link to documentation
man sshd
man ssh_config
man sshd_config
man xhost
...

Ciao
Davide

--
Dizionari: http://linguistico.sourceforge.net/wiki
Motivi per non comprare/usare ms-windows-vista:
http://badvista.fsf.org/
Non autorizzo la memorizzazione del mio indirizzo su outlook

Bug#905796: Please add patch supporting diffusion.commit.search

[Simon Quigley]

Package: python-phabricator
Severity: important

diffusion.querycommits has become frozen in favor of
diffusion.commit.search, however, support for this has not been tagged yet.

Please backport this patch:
https://github.com/disqus/python-phabricator/commit/a52c0e1357532f9ef8b26321d3728a0edead6ed4

I'll be happy to NMU; just let me know if you're OK with that.

Thanks!

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



signature.asc
Description: OpenPGP digital signature

Bug#904558: What should happen when maintscripts fail to restart a service

[Tollef Fog Heen]

]] Sean Whitton 

> The general question about which I am seeking advice: does the
> T.C. think that Debian can be consistent on service (re)starts in
> maintscripts, or is the best we can do to leave it up to package
> maintainer discretion?

I think we can give advice on what the default should be and that people
should not stray from that unless they have particular reasons.  That
advice might be more appropriate for the developers reference than
policy, though.

Due to the variety and complexity of daemons in the archive, I would be
reluctant to require complete consistency, there are likely various edge
cases we have not thought about.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Bug#904302: Whether vendor-specific patch series should be permitted in the archive

[Tollef Fog Heen]

]] Sean Whitton 

> The concrete question that I am asking the committee to decide, in my
> capacity as a Policy delegate, is whether or not vendor-specific patch
> series should be permitted in the Debian archive.

It's now been five days since I mailed the various package
maintainers. I intend to write up a resolution and then call for a vote
in the not-too-distant future, so if there is anything we have not
covered in the discussion so far, please chime in sooner rather than
later

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Bug#905795: rustc: Please include workaround for regression on sparc64

[John Paul Adrian Glaubitz]

Source: rustc
Version: 1.28.0+dfsg1-2
Severity: normal
Tags: patch
User: debian-sp...@lists.debian.org
Usertags: sparc64

Hello!

With version 1.28, the Rust compiler has regressed in the sense that
it generates code with unaligned access [1].

This problem existed in the past and was supposed to be fixed [2],
however it just recently came back.

The attached patch contains a workaround for sparc64 such that
rustc will at least build again. Please include it in the next
upload.

Thanks,
Adrian

> [1] https://github.com/rust-lang/rust/issues/53181
> [2] https://github.com/rust-lang/rust/pull/45679

--
  .''`.  John Paul Adrian Glaubitz
 : :' :  Debian Developer - glaub...@debian.org
 `. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
   `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
Description: 
 TODO: Put a short summary on the line above and replace this paragraph
 with a longer explanation of this change. Complete the meta-information
 with other relevant fields (see below for details). To make it easier, the
 information below has been extracted from the changelog. Adjust it or drop
 it.
 .
 rustc (1.28.0+dfsg1-2) unstable; urgency=medium
 .
   * Switch on verbose-tests to restore the old pre-1.28 behaviour, and restore
 old failure-counting logic.
   * Allow 50 test failures on s390x, restored failure-counting logic avoids
 more double-counts.
Author: Ximin Luo 

---
The information above should follow the Patch Tagging Guidelines, please
checkout http://dep.debian.net/deps/dep3/ to learn about the format. Here
are templates for supplementary fields that you might want to add:

Origin: , 
Bug: 
Bug-Debian: https://bugs.debian.org/
Bug-Ubuntu: https://launchpad.net/bugs/
Forwarded: 
Reviewed-By: 
Last-Update: 2018-08-09

--- rustc-1.28.0+dfsg1.orig/src/libsyntax_pos/span_encoding.rs
+++ rustc-1.28.0+dfsg1/src/libsyntax_pos/span_encoding.rs
@@ -26,7 +26,9 @@ use std::hash::{Hash, Hasher};
 /// The primary goal of `Span` is to be as small as possible and fit into 
other structures
 /// (that's why it uses `packed` as well). Decoding speed is the second 
priority.
 /// See `SpanData` for the info on span fields in decoded representation.
-#[repr(packed)]
+
+/// Workaround for compiler bug: https://github.com/rust-lang/rust/issues/53181
+#[cfg_attr(not(any(target_arch = "sparc64", target_arch = "sparcv9")), 
repr(packed))]
 pub struct Span(u32);
 
 impl Copy for Span {}

Bug#905478: Fwd: Re: Debian´s change of "su" to the one in util-linux

[Martin Steigerwald]

tags 905478 - moreinfo
thanks

Andreas Henriksson - 08.08.18, 21:58:
> Control: tags -1 + moreinfo
[…]
> On Mon, Aug 06, 2018 at 10:39:54AM +0200, Martin Steigerwald wrote:
[…]
> > I understand that you wrote quite something in NEWS.Debian already.
> > I lower the priority of the report to wishlist. It may still help to
> > explain it to users a bit more carefully. But as I know some of the
> > reasons now, I am fine with it either way.
> 
> I only documented changed behavior in NEWS. I have no intention to
> document long-standing best practises in detail in that file as it
> does not belong in a NEWS file. I quickly mentioned 'su' vs 'su -' as
> a hint for people to read up as many people still seem to be
> unknowing of the difference. I think a better place to document this
> is as Ted already suggested in some generic handbook.

Thing is here: It breaks existing workloads. And I have the gut feeling, 
not *just* mine. So no matter what long-standing, under-communicated, 
probably mostly undocumented best practices are in place in your 
opinion, it IMO is likely to produce an uproar with users once next 
Debian version is released.

Anyway, I won´t be who may be addressed by this kind of uproar… and I am 
not responsible for taking care of your well-being or the well-being of 
anyone who may be addressed by it. I just think, providing some 
practical hints could help to smooth the transition for all those who 
used "su" for decades.

> > I bet I will go with configuring sudo to take over SSH agent
> > environment variables to the root session. As this is on my laptop,
[…]
> Please summarize (in 2 or less sentences or I won't have time to read)

I am not responsible for how much time you have.

> what you still thinks needs to be done in util-linux package to close
> this bug report! As things currently stand I'm leaning towards
> tagging this wontfix and close the bug report because u-l is IMO not
> the place to document generic sysadmin best practises.

Well, I´d at least include some practical hints in next Debian release 
notes about this. This might also be a better place than within util-
linux. So maybe reassigning to release notes would do. It could also be 
in README.Debian of util-linux of course

For example how to make available certain environment variables via 
other means:

% cat /etc/sudoers.d/defaults 
Defaultsenv_keep+=SSH_AUTH_SOCK

(edited with visudo -f)



[moved downwards]
> […] Please lock your root account today and stop using su. […]

I do not intend to lock the root account, I see no reason to. Instead I 
did the following on my laptop:

Defaultsrootpw
Defaultstimestamp_timeout=0.5

I know this may not be suitable for different scenarios.

(So at least there is some documentation that may ease migration for 
people who used "su" for decades, at least in this bug report.)

Ciao,
-- 
Martin

Bug#905409: upgrade of util-linux and login break the xhost command for other users

[Helge Kreutzmann]

Hello Chris,
On Wed, Aug 08, 2018 at 08:58:24PM +0200, Chris Hofstaedtler wrote:
> * Helge Kreutzmann  [180808 18:57]:
> > On Tue, Aug 07, 2018 at 08:20:23PM +0100, Simon McVittie wrote:
> > > Andreas already asked for a merge request, so it seems that proposing a
> > > patch would indeed be welcome.
> > 
> > I'll do, incorporating your excellent explaination. I'll do so until
> > the end of the week (latest).
> 
> Gentle reminder about this.

Here you are:

--- ./su.1.orig 2017-09-27 11:05:13.717361420 +0200
+++ ./su.1  2018-08-09 21:04:24.370998117 +0200
@@ -261,6 +261,27 @@
 .RS
 .br
 session  required  pam_lastlog.so nowtmp
+.PP
+.RE
+Further by default 
+.B su
+does not allow the commands to access the current X display. To allow 
+graphical applications with the privileges of a different user 
+(called "otheruser" in this example) several
+options exists. These are, in order of preference (security-wise):
+.RS 10
+.TP
+o 
+Use a separate X display (e.g. "Switch User" in GNOME, or the equivalent 
fast-user-switching feature in other desktop environments), or a "thicker" 
remoting layer like VNC, Spice or Xpra.
+.TP
+o
+Use ssh, e.g. "ssh -X -oForwardX11Trusted=no otheruser@localhost".
+.TP
+o
+Allow \fBsu\fR explicit display access by issuing "xhost 
+si:localuser:otheruser" in 
+the originating X session and "DISPLAY=:0 command" under \fBsu\fR.
+This has serious security implications and hence should only be used in
+trusted environments.
 .RE
 .SH "SEE ALSO"
 .BR setpriv (1),

Feel free to update.

Greetings

   Helge
-- 
  Dr. Helge Kreutzmann deb...@helgefjell.de
   Dipl.-Phys.   http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
   Help keep free software "libre": http://www.ffii.de/


signature.asc
Description: Digital signature

Bug#904863: emacs-goodies-el: drop tc.el

[Nicholas D Steeves]

Hi Gijs,

On Thu, Aug 09, 2018 at 09:56:14AM +0200, Gijs Hillenius wrote:
> Hello
> 
> It looks like tc.el (Trivial Cite) is no longer needed. Correctly
> configuring these two variables provide by Gnus:
> 
> message-citation-line-function
> message-citation-line-format
> 
> provide the same outcome as Trivial-Cite did previously. For me anyway.
> 
> So, I won't further pursue taking over maintainership of tc.el

Thank you for following up on this bug, and for investigating and
confirming that the functionality of tc.el is provided by Gnus.  I'll
update README.Debian with this info and credit your investigation.

If you're interested in enhancing README.Debian for the benefit of
other Debian users who are transitioning from tc.el to Gnus methods,
feel free to take a look at this git repository:
  https://salsa.debian.org/emacsen-team/emacs-goodies-el

Sincerely,
Nicholas


signature.asc
Description: PGP signature

Bug#866907: screen: Please backport true color support from master branch

[Axel Beckert]

Control: tag -1 + confirmed help

Hi,

Guillem Jover wrote:
> So it would be really nice to get those patches backported into
> Debian, either via upstream or as local Debian patches. :)
> 
> Some of what appeare to be relevant commits can be found with:
> 
>   
> 
> but I'm unsure whether other commits would be needed too.

In general I'm reluctant to add new feature patches, especially
invasive ones. We've already had many of them in the past and I was
glad about each which has been accepted upstream. Rebasing them with
new upstream releases is not always trivial, but always extra work.

On the other hand there seems to be demand from more than one person
for this particular feature.

So if anyone can provide me a) a working patch against the Debian
package in unstable or the upstream screen-v4 branch, and b) a
step-by-step instructions for how to test it, I would be inclined to
add such a patch.

I though do not need this feature myself, so my motivation to gather
everthing necessary for a working patch based on the patches found by
the above mentioned search and potentially further ones, is rather
low.

Hence tagging this bug report as "help" (and "confirmed" as truecolor
support is indeed not in Debian's screen package yet).

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

Bug#905794: ITP: e-wrapper -- wrapper to handle "$EDITOR file:lineno"

[Adam Borowski]

Package: wnpp
Severity: wishlist
Owner: Adam Borowski 

* Package name: e-wrapper
  Version : uhm... hard question
  Upstream Author : yours truly
* URL : https://github.com/kilobyte/e
* License : hard question again
  Programming Lang: Perl
  Description : wrapper to handle "$EDITOR file:lineno"
 All or almost all Unix editors support the syntax of "editor +42 file", to
 open the given file and start with the cursor at line 42.  Alas, the syntax
 programs that output such data use is different: either "file:42: Something"
 or "file:42:1: Something", :1 being a column number.
 .
 This wrapper will recognize such references and call your $EDITOR using the
 + notation.  Thus, once you see an error message, you can copy the
 first word of it without having to manually adjust.  Especially if your
 mouse selection is configured to allow ':', it's a single triple-click
 (L+L+M), and still pretty handy if not.
 .
 If your editor allows multi-open, "e" can also handle pipelines such as:
 * git grep MEOW|e -:
 * make 2>&1 >/dev/null|grep error:|e -::
 .
 Also, because of its short name, it reduces the typing needed to start the
 editor by half if you use vi, by 80% if emacs or jstar -- and that's by far
 the most frequent command an Unix user does.


Such a wrapper is small enough that it might be better to avoid wasting a
separate package just for it -- but then, /usr/bin/e is a namespace grab
that some might object to, thus they might want to not have this package
installed.

Bug#905783: variety doesn't startup in mate and throws a bunch of python warnings

[James Lu]

Control: tags -1 +moreinfo

Hi,

On 2018-08-09 06:18 AM, shirish शिरीष wrote:
> Package: variety
> Version: 0.6.9-1
> Severity: normal
> 
> Dear Maintainer,
> 
> First I checked why variety isn't startup applications because I had
> put it in startup applications.
> 
> It used to work for quite sometime but recently didn't start. I saw
> for some reason it
> was now showing as variety only instead of /usr/bin/variety which I
> fixed. I have shared
> screenshots of both.

I don't see how this would make a difference unless you have a
conflicting "variety" binary elsewhere. What does "which variety" on the
command line show you?

> 
> Then I tried triggering variety via command-line and got the following
> messages -
> 
> $ variety> WARNING: 2018-08-09 18:09:04,714: create_menu() 'Variety Slideshow 
> is
> not installed. This is an optional extension adding pan-and-zoom
> slideshows to Variety: see
> https://github.com/peterlevi/variety-slideshow for details'
> /home/shirish/.config/variety/scripts/set_wallpaper: line 121: [: ==:
> unary operator expected
> 
> (variety:23253): Gdk-CRITICAL **: 18:09:05.488:
> gdk_window_thaw_toplevel_updates: assertion
> 'window->update_and_descendants_freeze_count > 0' failed
> /home/shirish/.config/variety/scripts/set_wallpaper: line 121: [: ==:
> unary operator expected

If you haven't edited set_wallpaper directly, delete
~/.config/variety/scripts/set_wallpaper and restart Variety. This will
make Variety copy over the newest set_wallpaper (this bug was fixed in
set_wallpaper since 0.6.7)

> /usr/lib/python2.7/dist-packages/urllib3/connectionpool.py:860:
> InsecureRequestWarning: Unverified HTTPS request is being made. Adding
> certificate verification is strongly advised. See:
> https://urllib3.readthedocs.io/en/latest/advanced-usage.html#ssl-warnings
>   InsecureRequestWarning)
> /usr/lib/python2.7/dist-packages/urllib3/connectionpool.py:860:
> InsecureRequestWarning: Unverified HTTPS request is being made. Adding
> certificate verification is strongly advised. See:
> https://urllib3.readthedocs.io/en/latest/advanced-usage.html#ssl-warnings
>   InsecureRequestWarning)
> /usr/lib/python2.7/dist-packages/urllib3/connectionpool.py:860:
> InsecureRequestWarning: Unverified HTTPS request is being made. Adding
> certificate verification is strongly advised. See:
> https://urllib3.readthedocs.io/en/latest/advanced-usage.html#ssl-warnings
>   InsecureRequestWarning)
> /usr/lib/python2.7/dist-packages/urllib3/connectionpool.py:860:
> InsecureRequestWarning: Unverified HTTPS request is being made. Adding
> certificate verification is strongly advised. See:
> https://urllib3.readthedocs.io/en/latest/advanced-usage.html#ssl-warnings
>   InsecureRequestWarning)
> /usr/lib/python2.7/dist-packages/urllib3/connectionpool.py:860:
> InsecureRequestWarning: Unverified HTTPS request is being made. Adding
> certificate verification is strongly advised. See:
> https://urllib3.readthedocs.io/en/latest/advanced-usage.html#ssl-warnings
>   InsecureRequestWarning)
> /usr/lib/python2.7/dist-packages/urllib3/connectionpool.py:860:
> InsecureRequestWarning: Unverified HTTPS request is being made. Adding
> certificate verification is strongly advised. See:
> https://urllib3.readthedocs.io/en/latest/advanced-usage.html#ssl-warnings
>   InsecureRequestWarning)
> /usr/lib/python2.7/dist-packages/urllib3/connectionpool.py:860:
> InsecureRequestWarning: Unverified HTTPS request is being made. Adding
> certificate verification is strongly advised. See:
> https://urllib3.readthedocs.io/en/latest/advanced-usage.html#ssl-warnings
>   InsecureRequestWarning)
> /usr/lib/python2.7/dist-packages/urllib3/connectionpool.py:860:
> InsecureRequestWarning: Unverified HTTPS request is being made. Adding
> certificate verification is strongly advised. See:
> https://urllib3.readthedocs.io/en/latest/advanced-usage.html#ssl-warnings
>   InsecureRequestWarning)

We'll likely fix this in 0.7.0:
https://github.com/varietywalls/variety/pull/48#discussion_r208742549

> /home/shirish/.config/variety/scripts/set_wallpaper: line 121: [: ==:
> unary operator expected
> 
> I see a bunch of ssl warnings along with line 121, line 121 of the
> script says -
> 
> if [ ${KDE_FULL_SESSION} == "true" ]; then
> 
> but this is mate-desktop. Also that gdk-critical error seems something
> to look at.

OK, maybe the Gdk-CRITICAL stuff is related but it looks like a bit of a
red herring. Reason being that Variety is still working after displaying
that error. It's more important to know if there actual missing
elements, e.g. a broken tray icon.

> I do not know whether it's a debian issue or something that upstream
> needs to take a look at ?

I happen to be upstream so I'm looking at it either way ;)
> 
> Look forward to your response to know what to do .
> 
> Is there a possibility of having variety-slideshow as a binary too ?

You can request a new package through the RFP process:
https://wiki.debian.org/RFP

> -- System Information:
> 

Bug#905793: Why does the Installer formats given swap

[Lennart Sorensen]

On Thu, Aug 09, 2018 at 07:37:15PM +0200, John Landmesser wrote:
> Package: debian-installer
> 
> 
> is there a reason why the installer defaults to format given swap partition?
> 
> I now know that you can opt out to format swap, but i don't understand that
> formatting swap is default!
> 
> I had several Linux on same PC and after installing aditional debian, the
> other Linux didn't find their swap anymore because UUID has changed.
> 
> I fixed it but i thought: "Debian, that should be a no go, formatting given
> swap"
> 
> So i'm curious for the reason for this behaviour!

Well 99.9% of installs don't have another linux on the system, so any
swap partition would be a new one that you just created, so you want
it formatted, or it wouldn't be used.

Maybe it would be possible to make it default to not format a swap
partition if that partition already exists and isn't being created
from scratch.

The installer at least has the option to not format it for the extremely
unusual case of wanting to reuse an existing swap partition.

-- 
Len Sorensen

Bug#905793: sharing swap is bad idea

[Adam Borowski]

> I had several Linux on same PC and after installing aditional debian, 
> the other Linux didn't find their swap anymore because UUID has changed.

Sharing swap leads to data loss if any kind of hibernate (incl. hybrid
suspend) is involved.  Thus, it really don't want to allow that by default.

If you know the danger, you can do so manually.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ So a Hungarian gypsy mountainman, lumberjack by day job,
⣾⠁⢰⠒⠀⣿⡁ brigand by, uhm, hobby, invented a dish: goulash on potato
⢿⡄⠘⠷⠚⠋⠀ pancakes.  Then the Polish couldn't decide which of his
⠈⠳⣄ adjectives to use for the dish's name.

Bug#871502: Bug #871502

[Jakson Alves de Aquino]

Hello,

Please, forgive me if this is a stupid question, but would it be
against Debian policy a package whose name could be zotero-install
that would depend on libraries that Zotero needs to work and whose
configure script would:

   - Download the binary Zotero package and unpack it at /usr/lib/

   - Add zotero.png to /usr/share/pixmaps/

   - Add zotero.desktop to /usr/share/applications/

   - Create a symbolic link to zotero shell script at /usr/bin/zotero

?

Thanks for your time!

-- 
Jakson Alves de Aquino

Bug#895729: RFS: mkl-dnn/0.15+git20180803.3f58c1 [ITP] -- tensorflow dependency (amd64 specific)

[Adam Borowski]

On Thu, Aug 09, 2018 at 10:16:17AM +, Lumin wrote:
>  * Package name: mkl-dnn
>Version : 0.15+git20180803.3f58c16-1
>Upstream Author : intel

Alas, the build flags use -march=native -mtune=native which is a big no-no.
The first makes the package crash on any processor lacking an extension that
was present on the build machine and was used by the compiler; unless some
kind of runtime detection is used, packages are allowed only the baseline
ISA for the architecture.  As for -mtune=native, it makes the package build
unreproducibly, differing based on where it was compiled.

The second problem is that in the testsuite, test_convolution_format_any
fails (0/5 sub-tests).  This might be related to my machine being:
vendor_id   : AuthenticAMD
model name  : AMD Phenom(tm) II X6 1055T Processor

Log of the FTBFS attached.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ So a Hungarian gypsy mountainman, lumberjack by day job,
⣾⠁⢰⠒⠀⣿⡁ brigand by, uhm, hobby, invented a dish: goulash on potato
⢿⡄⠘⠷⠚⠋⠀ pancakes.  Then the Polish couldn't decide which of his
⠈⠳⣄ adjectives to use for the dish's name.


mkl-dnn_0.15+git20180803.3f58c16-1_amd64.build.xz
Description: application/xz

Bug#905774: jackd2: jackd no longer starts, since device is already in use; but who's using it?

[Jonas Smedegaard]

Quoting Francesco Poli (2018-08-09 19:07:50)
> On Thu, 09 Aug 2018 17:38:54 +0200 Jonas Smedegaard wrote:
> 
> > Quoting Francesco Poli (2018-08-09 16:04:07)
> [...]
> > > I still have to understand why I had timidity-daemon installed on 
> > > that box: aptitude logs show that it had been there since long ago 
> > > (the oldest log shows an UPGRADE, rather than an INSTALL), but I 
> > > am sure I have never installed it manually. Indeed it was marked 
> > > as automatically installed, but no other installed package 
> > > currently depends on or recommends it.
> > > On another machine with an almost identical list of manually 
> > > installed packages, I do not have timidity or timidity-daemon 
> > > installed...
> > 
> > timidity used to recommend timidity-daemon (and some uses of APT 
> > wrongly flag auto-installed packages as manually-installed, or miss 
> > flagging them as auto-installed, or somesuch).  Seemingly relaxation 
> > from recommends to suggests happened at release 2.14.0-4.
> 
> Hello Jonas!
> Thanks for commenting on this bug log.
> 
> All this makes perfectly sense: timidity pulled timidity-daemon by 
> recommendation. Moreover recently, the recommendation has been turned 
> into a suggestion.

If I am not mistaken about english grammar...

either it "perfectly makes sense" or it "makes perfect sense"



> OK, this leaves me with the need to understand why package "timidity" 
> is installed on that machine, while it is not on the other similar 
> one. I am pretty sure I haven't installed timidity by hand...

I cannot tell how your system specifically ended in that state, but 
timidity historically got auto-installed frequently (to me) like this:

 $stuff → libsdl-mixer1.2 → freepats → timidity

My guess is that somehow (e.g. by using aptitude back when it had its 
own its own independent tracking of auto-installed packages which then 
got merged when APT grew support for that - I experienced some loss of 
flags during that period) your system lost the auto-install flag for 
timidity-daemon, keeping it around beyond removal of other packages and 
package relationships getting relaxed.


 - 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#905793: Why does the Installer formats given swap

[John Landmesser]

Package: debian-installer


is there a reason why the installer defaults to format given swap partition?

I now know that you can opt out to format swap, but i don't understand 
that formatting swap is default!


I had several Linux on same PC and after installing aditional debian, 
the other Linux didn't find their swap anymore because UUID has changed.


I fixed it but i thought: "Debian, that should be a no go, formatting 
given swap"


So i'm curious for the reason for this behaviour!

Regards

John Landmesser

Bug#848892: closed by Alastair McKinstry (Bug#848892: fixed in zygrib 8.0.1+dfsg.1-2)

[Damir Islamov]

reopen 848892

Shame on you...

$ dpkg -l zygrib
...
ii  zygrib8.0.1+dfsg.1-2
amd64 Weather data visualization,  GRIB file viewer


$ strings /usr/bin/zyGrib |grep 7.0.0
7.0.0


---
Sincerely yours
Damir Islamov

Debian Bug Tracking System писал 2018-07-28 21:42:

This is an automatic notification regarding your Bug report
which was filed against the zygrib package:

#848892: zygrib 8.0.1-1 ships zyGrib 7.0.0 actually

It has been closed by Alastair McKinstry .

Their explanation is attached below along with your original report.
If this explanation is unsatisfactory and you have not received a
better one in a separate message then please contact Alastair
McKinstry  by
replying to this email.

0xB5653FEF.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature

Bug#905737: reportbug: fails with '500 Internal Server Error' and 'No such bug report' retrieving only some bugnumbers

[Nis Martensen]

control: reassign 905737 python-debianbts

On 08 Aug 2018 Santiago wrote:
> Package: reportbug
> Version: 7.5.0
> Severity: important
> 
> Dear Maintainer, for several months, I reported without problems about the 
> bugnumber 885947 (the last correct was on 23-Jul-2018).
> 
> 
> From 29-Jul-2018, this command fails to recover the report, with messages 
> '500 Internal Server Error' and 'No report available'.
> 
> $ reportbug -N 885947
> *** Welcome to reportbug.  Use ? for help at prompts. ***
> . . .
> Retrieving report #885947 from Debian bug tracking system...
> b' 2.0//EN">\n\n500 Internal Server 
> Error\n\nInternal Server Error\nThe server 
> encountered an internal error or\nmisconfiguration and was unable to 
> complete\nyour request.\nPlease contact the server administrator at \n 
> ow...@bugs.debian.org to inform them of the time this error occurred,\n and 
> the actions you performed just before this error.\nMore information 
> about this error may be available\nin the server error 
> log.\n\nApache Server at bugs.debian.org Port 
> 443\n\n'
> No report available: #885947
> No such bug report.
> 
> 
> If I try other bugnumbers, several work fine (825930, 904391) but some work 
> badly (750587) with the same error.
> 
> $ reportbug -N 825930
> *** Welcome to reportbug.  Use ? for help at prompts. ***
> . . .
> Retrieving report #825930 from Debian bug tracking system...
> What do you want to do now? [N|x|o|r|b|e|q|?]? q
> Exiting.
> 
> $ reportbug -N  904391
> *** Welcome to reportbug.  Use ? for help at prompts. ***
> . . .
> Retrieving report #904391 from Debian bug tracking system...
> What do you want to do now? [x|O|r|b|e|q|?]? q
> Exiting.
> 
> $ reportbug -N 750587
> *** Welcome to reportbug.  Use ? for help at prompts. ***
> . . .
> Retrieving report #885947 from Debian bug tracking system...
> b' 2.0//EN">\n\n500 Internal Server 
> Error\n\nInternal Server Error\nThe server 
> encountered an internal error or\nmisconfiguration and was unable to 
> complete\nyour request.\nPlease contact the server administrator at \n 
> ow...@bugs.debian.org to inform them of the time this error occurred,\n and 
> the actions you performed just before this error.\nMore information 
> about this error may be available\nin the server error 
> log.\n\nApache Server at bugs.debian.org Port 
> 443\n\n'
> No report available: #885947
> No such bug report.
> 
> 
> Is it a bug in this package or is it a problem in the bug report?
> How can I now inform the maintainer of bugnumber 885947?
> 
> Regards.

Santiago, thank you for this report.
The bug is neither in reportbug nor in the bug report.
The reason is that debianbts.get_bug_log() (which is used internally by
reportbug) throws an exception. Example:

>>> import debianbts
>>> log = debianbts.get_bug_log(885947)
b'\n\n500 Internal Server
Error\n\nInternal Server Error\nThe
server encountered an internal error or\nmisconfiguration and was unable
to complete\nyour request.\nPlease contact the server
administrator at \n ow...@bugs.debian.org to inform them of the time
this error occurred,\n and the actions you performed just before this
error.\nMore information about this error may be available\nin
the server error log.\n\nApache Server at
bugs.debian.org Port 443\n\n'
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python3/dist-packages/debianbts.py", line 320, in
get_bug_log
reply = _soap_client_call('get_bug_log', nr)
  File "/usr/lib/python3/dist-packages/debianbts.py", line 492, in
_soap_client_call
return getattr(soap_client, method_name)(soap_client, *soap_args)
  File "/usr/lib/python3/dist-packages/pysimplesoap/client.py", line
179, in 
return lambda self=self, *args, **kwargs: self.call(attr, *args,
**kwargs)
  File "/usr/lib/python3/dist-packages/pysimplesoap/client.py", line
262, in call
jetty=self.__soap_server in ('jetty',))
  File "/usr/lib/python3/dist-packages/pysimplesoap/simplexml.py", line
56, in __init__
self.__document = xml.dom.minidom.parseString(text)
  File "/usr/lib/python3.5/xml/dom/minidom.py", line 1968, in parseString
return expatbuilder.parseString(string)
  File "/usr/lib/python3.5/xml/dom/expatbuilder.py", line 925, in
parseString
return builder.parseString(string)
  File "/usr/lib/python3.5/xml/dom/expatbuilder.py", line 223, in
parseString
parser.Parse(string, True)
xml.parsers.expat.ExpatError: syntax error: line 1, column 49
>>>

Bug#905767:

[J. Smith]

Just ignore this test. See https://bugs.debian.org/879020 .

Bug#905774: jackd2: jackd no longer starts, since device is already in use; but who's using it?

[Francesco Poli]

On Thu, 09 Aug 2018 17:38:54 +0200 Jonas Smedegaard wrote:

> Quoting Francesco Poli (2018-08-09 16:04:07)
[...]
> > I still have to understand why I had timidity-daemon installed on that 
> > box: aptitude logs show that it had been there since long ago (the 
> > oldest log shows an UPGRADE, rather than an INSTALL), but I am sure I 
> > have never installed it manually. Indeed it was marked as 
> > automatically installed, but no other installed package currently 
> > depends on or recommends it.
> > On another machine with an almost identical list of manually installed 
> > packages, I do not have timidity or timidity-daemon installed...
> 
> timidity used to recommend timidity-daemon (and some uses of APT wrongly 
> flag auto-installed packages as manually-installed, or miss flagging 
> them as auto-installed, or somesuch).  Seemingly relaxation from 
> recommends to suggests happened at release 2.14.0-4.

Hello Jonas!
Thanks for commenting on this bug log.

All this makes perfectly sense: timidity pulled timidity-daemon by
recommendation. Moreover recently, the recommendation has been turned
into a suggestion.

OK, this leaves me with the need to understand why package "timidity" is
installed on that machine, while it is not on the other similar one.
I am pretty sure I haven't installed timidity by hand...
And indeed it's marked as automatically installed:

  $ aptitude search timidity
  i A timidity- Software sound renderer (MIDI 
sequencer, M
  p   timidity-daemon - runs TiMidity++ as a system-wide MIDI 
sequ
  p   timidity-el - Emacs front end to Timidity++   
  
  p   timidity-interfaces-extra   - TiMidity++ extra user interfaces

Why is it there?

  $ aptitude why timidity
  i   fluid-soundfont-gm Suggests timidity

This cannot be the actual reason, because a suggestion is too weak a
relationship, and aptitude should propose to purge timidity as unused
package, whenever I issue my routine upgrade command
("aptitude update && aptitude --purge-unused safe-upgrade").

It cannot be a dependence, since aptitude is more than willing to purge
timidity, if I ask it to do so:

  $ aptitude -s --purge-unused purge timidity
  The following packages will be REMOVED:  
timidity{p} 
  0 packages upgraded, 0 newly installed, 1 to remove and 4 not upgraded.
  Need to get 0 B of archives. After unpacking 1,582 kB will be freed.
  
  Note: Using 'Simulate' mode.
  Do you want to continue? [Y/n/?] 

Hence, it must be a recommendation, maybe.

Let's search:

  $ grep-aptavail -F Recommends timidity -s Package
  Package: ecasound
  Package: mma
  Package: openttd
  Package: pianobooster
  Package: python-pykaraoke
  Package: soundkonverter
  Package: tk707
  Package: wammu

But I don't have any of these packages installed:

  $ apt policy \
$(grep-aptavail -F Recommends timidity -s Package \
  | awk -F: '{ print $2 }') | grep Installed
  
  WARNING: apt does not have a stable CLI interface. Use with caution in 
scripts.
  
Installed: (none)
Installed: (none)
Installed: (none)
Installed: (none)
Installed: (none)
Installed: (none)
Installed: (none)
Installed: (none)


Real mystery...



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



pgpeXkxm1XmIe.pgp
Description: PGP signature

Bug#905792: [libcloog-isl-dev] Conflict against libisl-dev

[Agustin Henze]

Package: libcloog-isl-dev
Version: 0.18.4-2
Severity: normal

Dear GCC Maintainers, when I try installing libcloog-isl-dev and libisl-dev
together I got the following error.

The following packages have unmet dependencies:
 libisl-0.18-dev : Conflicts: libisl-dev but 0.20-1 is to be installed

Are you planning update libcloog-isl-dev soon? Should I modify my build
dependencies and depend on the specific version libisl-0.18-dev instead of
libisl-dev?

Thanks,

-- 
TiN



signature.asc
Description: OpenPGP digital signature

Bug#905791: RFS: swapspace/1.14-1 [ITA]

[Jacob Adams]

Package: sponsorship-requests
Severity: normal

  Dear mentors,

  I am looking for a sponsor for my package "swapspace"

 * Package name: swapspace
   Version : 1.14-1
   Upstream Maintainer : Jacob Adams 
 * URL : https://github.com/Tookmund/Swapspace
 * License : GPL-2+
   Section : admin

  It builds those binary packages:

swapspace  - dynamic swap space manager

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

  https://mentors.debian.net/package/swapspace


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

dget -x
https://mentors.debian.net/debian/pool/main/s/swapspace/swapspace_1.14-1.dsc

  Changes since the last upload:

  swapspace (1.14-1) unstable; urgency=medium

  * New maintainer. (Closes: #725821)
  * Redo packaging with debhelper 11 (Closes: #866272)
  * Account for memory allocated to /dev/shm (Closes: #691128)
  * Removed swapd conflict as swapd was removed from Debian in 2010
  * Fix minor manual page typo

 -- Jacob Adams   Wed, 04 Jul 2018 12:53:34 -0400



  Regards,
   Jacob Adams



signature.asc
Description: OpenPGP digital signature

Bug#905524: usbguard: unowned files after purge (policy 6.8, 10.8): /etc/usbguard/rules.conf

[Muri Nicanor]

control: -1 + pending

Thanks for the bugreport and making me aware of piuparts!
I've added a postrm script that removes the files and uploaded a new
version to mentors. The bug should be fixed as soon as the package is
sponsored.

cheers,
muri

Bug#698668: [PATCH] Documentation/media: uapi: Explicitly say there are no Invariant Sections

[Michael Ira Krufky]

On Thu, Aug 9, 2018 at 11:19 AM Mauro Carvalho Chehab
 wrote:
>
> Em Fri, 3 Aug 2018 15:41:53 +0100
> Ben Hutchings  escreveu:
>
> > The GNU Free Documentation License allows for a work to specify
> > Invariant Sections that are not allowed to be modified.  (Debian
> > considers that this makes such works non-free.)
> >
> > The Linux Media Infrastructure userspace API documentation does not
> > specify any such sections, but it also doesn't say there are none (as
> > is recommended by the license text).  Make it explicit that there are
> > none.
> >
> > References: https://bugs.debian.org/698668
> > Signed-off-by: Ben Hutchings 
>
> From my side:
>
> Signed-off-by: Mauro Carvalho Chehab 
>
> (I'm waiting for more SoBs before merging this)
>
> I pinged some developers that don't use to listen to the media ML
> as often as they used to do, and to the sub-maintainers, via the
> sub-mainainers ML, and got some SoBs. Let me add them to this thread:
>
> Gerd:
>
> Signed-off-by: Gerd Hoffmann 
>
> Hans:
>
> Signed-off-by: Hans Verkuil 
>
> Sylwester:
>
> Signed-off-by: Sylwester Nawrocki 
>
> Johannes:
>
> "I think I didn't contribute to that documentation?
>  Anyway, just in case: I agree with the change to
>  forbid adding invariant sections."
>
> Signed-off-by: Johannes Stezenbach 
>
> Ralph:
>
> "I also do not think there is anything left in there which I contributed.
>  The original documentation up to 2002 probably is copyright of Convergence.
>
>  But I agree with the change to forbid adding invariant sections regarding
>  anything in that documentation that might be my copyright."
>
> Signed-off-by: Ralph Metzler 
>
> Markus:
>
> "Ralph> I also do not think there is anything left in there which I
>  Ralph> contributed.  The original documentation up to 2002
>  Ralph> probably is copyright of Convergence.
>  The same is true for me.
>
>  I also agree with the change to forbid adding invariant sections
>  regarding anything in that documentation that might be my copyright."
>
> Signed-off-by: Marcus Metzler 
>
>
> > ---
> >  Documentation/media/media_uapi.rst | 6 +++---
> >  1 file changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/Documentation/media/media_uapi.rst 
> > b/Documentation/media/media_uapi.rst
> > index 28eb35a1f965..5198ff24a094 100644
> > --- a/Documentation/media/media_uapi.rst
> > +++ b/Documentation/media/media_uapi.rst
> > @@ -10,9 +10,9 @@ Linux Media Infrastructure userspace API
> >
> >  Permission is granted to copy, distribute and/or modify this document
> >  under the terms of the GNU Free Documentation License, Version 1.1 or
> > -any later version published by the Free Software Foundation. A copy of
> > -the license is included in the chapter entitled "GNU Free Documentation
> > -License".
> > +any later version published by the Free Software Foundation, with no
> > +Invariant Sections. A copy of the license is included in the chapter
> > +entitled "GNU Free Documentation License".

The original founders / authors / coders of LinuxDVB have signed off
on this, and that is most important to me.

Signed-off-by: Michael Ira Krufky 

Bug#905701: closed by Félix Sipma (Bug#905701: fixed in khard 0.12.2-3)

[Félix Sipma]

Woops... I added python3-distutils to build-dependencies, not to dependencies.
Should be fixed in 0.12.2-4.


signature.asc
Description: PGP signature

Bug#879540: ImportError: No module named eyeD3

[Olivier Tilloy]

That patch is incomplete (it probably works when burning exclusively .ogg 
files, but otherwise a different code path tries to instantiate a Tag object to 
parse the ID3 metadata, and fails because there have been API changes in eyed3).

I'm attaching a patch that seems to work for me when burning mp3 files.Description: update eyed3 usage to API changes
Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=879540
Bug-Ubuntu: https://bugs.launchpad.net/ubuntu/+source/burn/+bug/1734107
Author: Olivier Tilloy 

--- a/burnlib/audio.py
+++ b/burnlib/audio.py
@@ -25,7 +25,7 @@
 
 import os.path
 import ogg.vorbis
-import eyeD3
+from eyed3 import id3
 import mad
 
 
@@ -44,11 +44,11 @@ class FileInfo:
 self.__dict__.update(fileinfo.__dict__)
 self.fileinfo = fileinfo
 else:
-tag = eyeD3.Tag()
-tag.link(fullpath)
-self.artist = tag.getArtist()
-self.title = tag.getTitle()
-self.album = tag.getAlbum()
+tag = id3.Tag()
+tag.parse(fullpath)
+self.artist = tag._getArtist()
+self.title = tag._getTitle()
+self.album = tag._getAlbum()
 fileinfo = mad.MadFile(fullpath)
 self.total_time = fileinfo.total_time() / 1024
 self.bitrate = fileinfo.bitrate() / 1000

Bug#903540: skill/snice: does not match anything

[Helmut Grohne]

Hi Craig,

On Tue, Jul 17, 2018 at 09:49:15PM +1000, Craig Small wrote:
>   Thankyou for your bug report.  git bisect analysis shows that upstream
> commit 52673d2fc7e012f5134cdfafb6d319450b3a40a3 [1] is the cause of your
> problem as reported; or is for at least the -p option.

Thank you for performing the bisect!

> I must admit having an initial look at this commit, nothing stands out that
> says "this is a problem", but here we are. It will need some further
> checking to see why it is breaking skill.

If you ask me, something does stand out.

> https://gitlab.com/procps-ng/procps/commit/52673d2fc7e012f5134cdfafb6d319450b3a40a3

That thing is:

-if (read(fd, buf, 128) <= 0)
+if (len <= 0 || (size_t)len >= sizeof(buf))

The second condition (len >= sizeof(buf)) is new. So what actually is
sizeof(buf)? Well, 128. What are we reading from? Well, /proc/$pid/stat.
How big are such stat files in general? Well, let's ask wc -c
/proc/*/stat. The smallest file has 147 bytes here. But they can go well
beyond 300 bytes.

The buffer is simply too small.

Given that the thing you read is always big. I'm in favour of simply
reverting qualys' patch and replacing it with buf[min(127, len)] = '\0';

Helmut

Bug#904441: linux-image-4.17.0-1-amd64: system disk stopped during boot

[Felipe Sologuren]

On Sun, 29 Jul 2018 11:52:10 +0200 Tomas Janousek  wrote:
> Hi Julian,
>
> On Fri, Jul 27, 2018 at 09:31:42PM +1000, Julian Calaby wrote:
> > > Does adding the kernel parameter "ahci.mobile_lpm_policy=1" avoid
this?
> >
> > No, booting with that parameter makes no difference.
>
> Can you try "dm_mod.use_blk_mq=0 scsi_mod.use_blk_mq=0" as well?
Setting "dm_mod.use_blk_mq=0 scsi_mod.use_blk_mq=0" allows to boot.

$ cat /sys/bus/scsi/devices/0\:0\:0\:0/model
Crucial_CT1050MX
$ cat /sys/bus/scsi/devices/0\:0\:0\:0/rev
R040

I have laptop-mode-tools installed too.

Thank you.

Bug#905729: laptop-mode-tools causes `sda` disk to stop indefinitely when disconnect AC power.

[Felipe Sologuren]

2018-08-09 0:33 GMT-04:00 Ritesh Raj Sarraf :

> Control: merge -1 904441
>
>
> On Wed, 2018-08-08 at 13:32 -0400, Felipe Sologuren Gutiérrez wrote:
> > Package: laptop-mode-tools
> > Version: 1.72-2
> > Severity: critical
> > Justification: breaks the whole system
> >
> >
> > I read bug #889544 and my problem is the same except my disk never
> > leave the stopped status, exactly as Jean-Marie reported.
> > After that, I observed the same issues, the whole system starts to
> > fail to write down to the disk reporting that it's damaged, and the
> > last entry that persist at syslog is that `sda` stopped.
> > My problem started when I installed kernel 4.17 and is not happening
> > with kernel 4.16.
> > My hardware is Asus n46vj, disk drive:
> > ata1.00: ATA-10: Crucial_CT1050MX300SSD1,  M0CR040, max UDMA/133
> > BIOS has enabled AHCI.
> >
>
> This is an issue with the Linux kernel. This is now uncovered, more
> often with 4.17, because the multiqueue setting was enabled by default
> with this version.
>
Thank you.


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

Bug#905774: jackd2: jackd no longer starts, since device is already in use; but who's using it?

[Jonas Smedegaard]

Quoting Francesco Poli (2018-08-09 16:04:07)
> On Thu, 9 Aug 2018 13:22:55 +0200 Klaumi Klingsporn wrote:
> 
> > Am / On Thu, 09 Aug 2018 12:35:28 +0200
> > schrieb / wrote "Francesco Poli (wintermute)"
> > :
> > 
> > > Why my jackd does not tell me which application is using
> > > hw:0 ?!? How can I figure out which application is
> > > getting in the way?
[...]
> > And than there's debian bug #901931 which gave me the same
> > problem last time: timidity-daemon 2.14.0-3 blocked the
> > sound-device (even for pulseaudio).
> 
> Bingo!
> After purging timidity-daemon, everything works again!
> 
> I still have to understand why I had timidity-daemon installed on that 
> box: aptitude logs show that it had been there since long ago (the 
> oldest log shows an UPGRADE, rather than an INSTALL), but I am sure I 
> have never installed it manually. Indeed it was marked as 
> automatically installed, but no other installed package currently 
> depends on or recommends it.
> On another machine with an almost identical list of manually installed 
> packages, I do not have timidity or timidity-daemon installed...

timidity used to recommend timidity-daemon (and some uses of APT wrongly 
flag auto-installed packages as manually-installed, or miss flagging 
them as auto-installed, or somesuch).  Seemingly relaxation from 
recommends to suggests happened at release 2.14.0-4.


 - 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#905790: ibus-gtk3: ibus pop-up on login is distracting

[Jonathan Carter]

Package: ibus-gtk3
Severity: normal

Dear Maintainer,

ibus is installed by default on a Debian desktop (or at least
on debian live media).

When logging into an Xfce or Gnome session, an ibus pop-up is
displayed. This can be particularly annoying or distracting to
users who are trying out a live image, who won't know what ibus
even is, and what typically happens is that they perceive it
as an error message, which doesn't leave a great impression on
new Debian users.

Would you perhaps consider removing the notification of the new
default ibus shortcut pop-up? It's been there for a few releases
already, not sure if it really is all that useful anymore.

Thanks,

-Jonathan

Bug#901952: find the commit

[Eric Prestemon]

It looks this commit is the problem:
http://git.savannah.gnu.org/cgit/tar.git/commit/?id=dee7e3f16e74e07504bb8f4d80426005fe4364ae

tar no longer strips a quoting level when reading lines from the manifest
file.

Bug#905784: emacs-goodies-el: No filename for emacs-goodies-el:amd64

[Sven Joachim]

Control: reassign -1 apt
Control: merge 670920 -1

On 2018-08-09 10:22 -0300, Alexandre Lymberopoulos wrote:

> Package: emacs-goodies-el
> Version: 40.0
> Severity: normal
>
> Dear Maintainer,
>
> When I tried to update this package on aptitude, it was left
> unconfigured and now, when I try to reinstall it, aptitude shows me
> the erro:
>
> E: Internal Error, No file name for emacs-goodies-el:amd64.
>
> I may provide further information if necessary.

This seems to be the same as #670920, see
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=670920#10.

Cheers,
   Sven

> Thanks in advance, Alexandre.
>
> -- System Information:
> Debian Release: buster/sid
>   APT prefers testing
>   APT policy: (900, 'testing'), (800, 'unstable')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 4.17.0-1-amd64 (SMP w/4 CPU cores)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
> LANGUAGE=en_US:en (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
>
> Versions of packages emacs-goodies-el depends on:
> ii  bash   4.4.18-3.1
> ii  dpkg   1.19.0.5+b1
> ii  emacs25 [emacsen]  25.2+1-6+b3
> ii  emacsen-common 2.0.8
> ii  install-info   6.5.0.dfsg.1-4
>
> Versions of packages emacs-goodies-el recommends:
> pn  elpa-apache-mode
> pn  elpa-bar-cursor 
> pn  elpa-bm 
> pn  elpa-boxquote   
> pn  elpa-browse-kill-ring   
> pn  elpa-csv-mode   
> pn  elpa-debian-el  
> pn  elpa-devscripts 
> pn  elpa-diminish   
> pn  elpa-dpkg-dev-el
> pn  elpa-eproject   
> pn  elpa-graphviz-dot-mode  
> pn  elpa-htmlize
> pn  elpa-initsplit  
> pn  elpa-markdown-mode  
> pn  elpa-pod-mode   
> pn  elpa-session
> pn  elpa-tabbar 
> pn  perl-doc
> ii  wget1.19.5-1
>
> emacs-goodies-el suggests no packages.
>
> -- no debconf information

Bug#698668: [PATCH] Documentation/media: uapi: Explicitly say there are no Invariant Sections

[Mauro Carvalho Chehab]

Em Fri, 3 Aug 2018 15:41:53 +0100
Ben Hutchings  escreveu:

> The GNU Free Documentation License allows for a work to specify
> Invariant Sections that are not allowed to be modified.  (Debian
> considers that this makes such works non-free.)
> 
> The Linux Media Infrastructure userspace API documentation does not
> specify any such sections, but it also doesn't say there are none (as
> is recommended by the license text).  Make it explicit that there are
> none.
> 
> References: https://bugs.debian.org/698668
> Signed-off-by: Ben Hutchings 

From my side:

Signed-off-by: Mauro Carvalho Chehab 

(I'm waiting for more SoBs before merging this)

I pinged some developers that don't use to listen to the media ML
as often as they used to do, and to the sub-maintainers, via the
sub-mainainers ML, and got some SoBs. Let me add them to this thread:

Gerd:

Signed-off-by: Gerd Hoffmann 

Hans:

Signed-off-by: Hans Verkuil 

Sylwester:

Signed-off-by: Sylwester Nawrocki 

Johannes:

"I think I didn't contribute to that documentation?
 Anyway, just in case: I agree with the change to
 forbid adding invariant sections."

Signed-off-by: Johannes Stezenbach 

Ralph:

"I also do not think there is anything left in there which I contributed.
 The original documentation up to 2002 probably is copyright of Convergence.

 But I agree with the change to forbid adding invariant sections regarding
 anything in that documentation that might be my copyright."

Signed-off-by: Ralph Metzler 

Markus:

"Ralph> I also do not think there is anything left in there which I
 Ralph> contributed.  The original documentation up to 2002
 Ralph> probably is copyright of Convergence.  
 The same is true for me.

 I also agree with the change to forbid adding invariant sections
 regarding anything in that documentation that might be my copyright."

Signed-off-by: Marcus Metzler 


> ---
>  Documentation/media/media_uapi.rst | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/Documentation/media/media_uapi.rst 
> b/Documentation/media/media_uapi.rst
> index 28eb35a1f965..5198ff24a094 100644
> --- a/Documentation/media/media_uapi.rst
> +++ b/Documentation/media/media_uapi.rst
> @@ -10,9 +10,9 @@ Linux Media Infrastructure userspace API
>  
>  Permission is granted to copy, distribute and/or modify this document
>  under the terms of the GNU Free Documentation License, Version 1.1 or
> -any later version published by the Free Software Foundation. A copy of
> -the license is included in the chapter entitled "GNU Free Documentation
> -License".
> +any later version published by the Free Software Foundation, with no
> +Invariant Sections. A copy of the license is included in the chapter
> +entitled "GNU Free Documentation License".
>  
>  .. only:: html
>  



Thanks,
Mauro

Bug#698668: [PATCH] Documentation/media: uapi: Explicitly say there are no Invariant Sections

[Mauro Carvalho Chehab]

Em Thu, 9 Aug 2018 12:19:20 -0300
Mauro Carvalho Chehab  escreveu:

> Em Fri, 3 Aug 2018 15:41:53 +0100
> Ben Hutchings  escreveu:
> 
> > The GNU Free Documentation License allows for a work to specify
> > Invariant Sections that are not allowed to be modified.  (Debian
> > considers that this makes such works non-free.)
> > 
> > The Linux Media Infrastructure userspace API documentation does not
> > specify any such sections, but it also doesn't say there are none (as
> > is recommended by the license text).  Make it explicit that there are
> > none.
> > 
> > References: https://bugs.debian.org/698668
> > Signed-off-by: Ben Hutchings   
> 
> From my side:
> 
> Signed-off-by: Mauro Carvalho Chehab 
> 
> (I'm waiting for more SoBs before merging this)
> 
> I pinged some developers that don't use to listen to the media ML
> as often as they used to do, and to the sub-maintainers, via the
> sub-mainainers ML, and got some SoBs. Let me add them to this thread:
> 
> Gerd:
> 
> Signed-off-by: Gerd Hoffmann 
> 
> Hans:
> 
> Signed-off-by: Hans Verkuil 
> 
> Sylwester:
> 
> Signed-off-by: Sylwester Nawrocki 
> 
> Johannes:
> 
> "I think I didn't contribute to that documentation?
>  Anyway, just in case: I agree with the change to
>  forbid adding invariant sections."
> 
> Signed-off-by: Johannes Stezenbach 
> 
> Ralph:
> 
> "I also do not think there is anything left in there which I contributed.
>  The original documentation up to 2002 probably is copyright of Convergence.
> 
>  But I agree with the change to forbid adding invariant sections regarding
>  anything in that documentation that might be my copyright."
> 
> Signed-off-by: Ralph Metzler 
> 
> Markus:
> 
> "Ralph> I also do not think there is anything left in there which I
>  Ralph> contributed.  The original documentation up to 2002
>  Ralph> probably is copyright of Convergence.
>  The same is true for me.
> 
>  I also agree with the change to forbid adding invariant sections
>  regarding anything in that documentation that might be my copyright."
> 
> Signed-off-by: Marcus Metzler 


Sean Young:

Signed-off-by: Sean Young 

 "Makes complete sense."


> 
> 
> > ---
> >  Documentation/media/media_uapi.rst | 6 +++---
> >  1 file changed, 3 insertions(+), 3 deletions(-)
> > 
> > diff --git a/Documentation/media/media_uapi.rst 
> > b/Documentation/media/media_uapi.rst
> > index 28eb35a1f965..5198ff24a094 100644
> > --- a/Documentation/media/media_uapi.rst
> > +++ b/Documentation/media/media_uapi.rst
> > @@ -10,9 +10,9 @@ Linux Media Infrastructure userspace API
> >  
> >  Permission is granted to copy, distribute and/or modify this document
> >  under the terms of the GNU Free Documentation License, Version 1.1 or
> > -any later version published by the Free Software Foundation. A copy of
> > -the license is included in the chapter entitled "GNU Free Documentation
> > -License".
> > +any later version published by the Free Software Foundation, with no
> > +Invariant Sections. A copy of the license is included in the chapter
> > +entitled "GNU Free Documentation License".
> >  
> >  .. only:: html
> >
> 
> 
> 
> Thanks,
> Mauro



Thanks,
Mauro

Bug#905789: nmu: irssi-plugin-otr_1.0.4-1

[Holger Levsen]

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

nmu irssi-plugin-otr_1.0.4-1 . ANY . buster . -m "Rebuild for latest irssi. 
1.1.1-1"

because

 Hey, it appears that irssi-plugin-otr requires rebuild to work with the 
newest irssi (1.1.1-1). 
   Without it, it complains about incompatibile ABIs.


-- 
cheers,
Holger

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


signature.asc
Description: PGP signature

Bug#905788: FTBFS: cannot find -lgpod

[Andrey Rahmatullin]

Package: src:libgpod
Version: 0.8.3-11
Severity: serious
Justification: fails to build from source (but built successfully in the past)
Tags: ftbfs

Trying to build the package in a fresh sid sbuild chroot I get

libtool: warning: relinking '_gpod.la'
libtool: install: (cd /<>/build/python2.7/bindings/python;
/bin/bash "/<>/build/python2.7/libtool"  --tag CC --mode=relink
gcc -g -O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong
-Wformat -Werror=format-security -module -avoid-version -shared -Wl,-z,relro
-Wl,-O1 -Wl,--as-needed -o _gpod.la -rpath /usr/lib/python2.7/dist-
packages/gpod _gpod_la-gpod_wrap.lo -lgobject-2.0 -lsqlite3 -lplist -Wl,--
export-dynamic -lgmodule-2.0 -pthread -lglib-2.0 -lxml2 -lgdk_pixbuf-2.0
-lgobject-2.0 -lglib-2.0 -lgobject-2.0 -lglib-2.0 ../../src/libgpod.la -inst-
prefix-dir /<>/debian/tmp)
Byte-compiling python modules (optimized versions) ...
__init__.pygtkpod.pyipod.py
Byte-compiling python modules (optimized versions) ...
gpod.py
libtool: relink: gcc -shared  -fPIC -DPIC  .libs/_gpod_la-gpod_wrap.o
-L/<>/debian/tmp/usr/lib/x86_64-linux-gnu -L/usr/lib/x86_64-linux-
gnu -lsqlite3 -lplist -lgmodule-2.0 -lxml2 -lgdk_pixbuf-2.0 -lgobject-2.0
-lglib-2.0 -lgpod  -g -O2 -fstack-protector-strong -Wl,-z -Wl,relro -Wl,-O1
-Wl,--as-needed -Wl,--export-dynamic -pthread   -pthread -Wl,-soname
-Wl,_gpod.so -o .libs/_gpod.so
/usr/bin/ld: cannot find -lgpod
collect2: error: ld returned 1 exit status
libtool:   error: error: relink '_gpod.la' with the above command before
installing it



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

Kernel: Linux 4.17.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8), LANGUAGE=
(charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#896230: python-gpod: gpod fails to import

[Andrey Rahmatullin]

On Mon, Apr 23, 2018 at 08:28:22PM +0100, Mark Williams wrote:
> Installing python-gobject seems to work around this. Suggest this is added
> to dependencies.
Thank you for this observation, it seems dh_python2 --depends=gobject
doesn't produce the correct depends on python-gobject-2.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#873884: [openssh-server] At boot time ssh is listening at port 22 rather than the one configured in sshd_config

[W. Martin Borgert]

Hi Colin,

thanks for your explanation! However, the bug submitter seems to like
sshd *not* to listen on port 22, which is what I want, too. (Mainly to
prevent log spamming due to failed login attempts.)

Your explanation here seems to *add* a second listening port, which is
probably not what the bug submitter — nor I — wanted.  I assume, that
the old README.Debian was correct, because it overrode the default.

To achieve the desired result, the following works for me:

systemctl start ssh.service
systemctl enable ssh.service
systemctl stop ssh.socket
systemctl disable ssh.socket

Now, only the configured ports from /etc/ssh/sshd_config are used.

Should this be added to README.Debian, maybe?

I wonder, why sshd suddenly used socket activation by systemd instead
of the standalone service? I can't remember that I changed that on my
system and the effect of listening on a different port than before was
highly confusing until reading this bug report. If this were something
intended by the package, it should be probably mentioned in
NEWS.Debian.

Cheers, Martin

Bug#905787: locks gnupg card, making it impossible to use it (!)

[Wouter Verhelst]

Package: gnome-keyring
Version: 3.28.2-1
Severity: important

Hi,

When I log in to my session or start seahorse while gpg-agent isn't
running, I get a desktop notification:

 *Smart card is ready to use*
 CryptoStick v1.2 (OpenPGP v2.0)

At this point, I can no longer use gnupg or gpg-agent to access the
card, because gnome-keyring-daemon has locked it.

Wtf?

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

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

Versions of packages gnome-keyring depends on:
ii  dbus-user-session [default-dbus-session-bus]  1.12.10-1
ii  dbus-x11 [dbus-session-bus]   1.12.10-1
ii  dconf-gsettings-backend [gsettings-backend]   0.28.0-2
ii  gcr   3.28.0-1
ii  libc6 2.27-5
ii  libcap-ng00.7.9-1
ii  libcap2-bin   1:2.25-1.2
ii  libgck-1-03.28.0-1
ii  libgcr-base-3-1   3.28.0-1
ii  libgcrypt20   1.8.3-1
ii  libglib2.0-0  2.56.1-2
ii  p11-kit   0.23.12-2
ii  pinentry-gnome3   1.1.0-1+b1

Versions of packages gnome-keyring recommends:
ii  gnome-keyring-pkcs11  3.28.2-1
ii  libpam-gnome-keyring  3.28.2-1

gnome-keyring suggests no packages.

-- no debconf information

Bug#905413: closed by Jonathan Carter (Bug#905413: fixed in gamemode 1.2-3)

[Andreas Beckmann]

Control: reassign -1 src:gamemode 1.2-2
Control: found -1 1.2-3

Thanks for naming the -dev packages in the normal way.
But they now depend on the not existing libgamemode, libgamemodeauto
packages - these of course need the SOVERSION suffix, so libgamemode0,
libgamemodeauto0.


Andreas

Bug#806229: Backport worth it?

[Osamu Aoki]

control: tags -1 -patch
Hi,

I thought if the testing package is installable to the stable system, we don't 
do
backport unless it is required by Debian infrastructure machines.

So I think we don't upload backport.  This is document package.

If OK, I will close this bug.

Osamu

PS: Now stable is sketch.

Bug#903933: openvpn cannot read config files outside /etc/openvpn when systemd is used

[Alex]

Hello Bernhard,

I edited the file (and the setting seems to be a possible cause), but it
still not works. I run openvpn still via /etc/default/openvpn AUTOSTART=
instead of using vpn@openvpn style services. Possibly there is another
service in between, which restricts the home access?

Alex

Bug#905774: jackd2: jackd no longer starts, since device is already in use; but who's using it?

[Francesco Poli]

On Thu, 9 Aug 2018 13:22:55 +0200 Klaumi Klingsporn wrote:

> Am / On Thu, 09 Aug 2018 12:35:28 +0200
> schrieb / wrote "Francesco Poli (wintermute)"
> :
> 
> > Why my jackd does not tell me which application is using
> > hw:0 ?!? How can I figure out which application is
> > getting in the way?
> 
> Maybe because jackd doesn't know about them?

What do you mean? Does jackd only check for a list of applications
known to lock the soundcard resource, and otherwise spit a more vague
error message?!?

> Top maybe the tool of your choice!

Well, top(1) shows all the running processes, in descending order of
resource (CPU, memory, ...) occupation.
Does it have an option or command to show which process is using the
soundcard? I failed to find any...

> 
> > Please help me to investigate
> 
> Only two guesses: pulseaudio may block your device. Try 
> 
> pulseaudio -k
> 
> before starting jackd.

This cannot be the case, since pulseaudio is not installed.

> 
> And than there's debian bug #901931 which gave me the same
> problem last time: timidity-daemon 2.14.0-3 blocked the
> sound-device (even for pulseaudio).

Bingo!
After purging timidity-daemon, everything works again!

I still have to understand why I had timidity-daemon installed on that
box: aptitude logs show that it had been there since long ago (the
oldest log shows an UPGRADE, rather than an INSTALL), but I am sure I
have never installed it manually. Indeed it was marked as automatically
installed, but no other installed package currently depends on or
recommends it.
On another machine with an almost identical list of manually installed
packages, I do not have timidity or timidity-daemon installed...


But anyway, thanks a lot for your really prompt and helpful reply!
I wish I could get this positive experience every time I report a
bug!  ;-)

Bye.

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


pgp35wCChFLxP.pgp
Description: PGP signature

Bug#905772: Trying to drop sysv is leading to other complexities

[Christian Ehrhardt]

Hi,
Just FYI simply removing the installation of the sysV scripts will uncover
other issues.
If sysV and systemd services are installed the former still are prefered.

So with libvirtd sysV gone it will pick up libvirtd.service
That will parse the Requires which contains virtlogd-socket  will
eventually lead to:
  deb-systemd-invoke $_dh_action 'libvirtd.service' 'virtlockd.socket'
'virtlogd.socket'

And that will stop the service to restart the socket.

I have taken a few more approcahes to this, like full conversion to
dh_isntallsystemd and others.
But all failed so far by still calling the command above which will
effectively restart virtlogd which is not what we want.

I start to consider things that look bad at first, for example keep the
libvirtd sysV script but make it almost empty.
At least the dependencies to the virtlogd sysV script have to go away -
otherwise it will block on that before the sysV to systemd wrapper kicks in
:-/

Hoping you have a better Idea how to resolve,
Christian

Bug#905786: libvncserver1: Use-after-free on shutdown when clients are still connected (causing issue for Virtualbox)

[Quentin BUATHIER]

Package: libvncserver1
Version: 0.9.11+dfsg-1+deb9u1
Severity: important
Tags: patch

In the upstream source of the project, there is an use-after-free that can lead
to an infinite wait of a non-existing thread during the shutdown of the VNC
server if some clients are still connected.

This causing an issue in Virtualbox which uses this package when a VNC client
is connected and that we shutdown the VM (the VM will be stuck in a buggy
state). See https://www.virtualbox.org/ticket/17396 for the ticket in
Virtualbox's bug tracker for more informations.

There is actually a pull request on upstream fixing this issue
(https://github.com/LibVNC/libvncserver/pull/238). There is also another issue,
a segmentation fault in the same use case when we are using a multi-threaded
VNC server (also fixed by the same pull request).

Virtualbox need both fixes to work correctly without a segmentation fault or a
infinite wait and probably some others packages using libvncserver.

The issue isn't present on Jessie with the version 0.9.9 of the package.



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

Kernel: Linux 4.9.0-7-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)

Versions of packages libvncserver1 depends on:
ii  libc62.24-11+deb9u3
ii  libgcrypt20  1.7.6-2+deb9u3
ii  libgnutls30  3.5.8-5+deb9u3
ii  libjpeg62-turbo  1:1.5.1-2
ii  zlib1g   1:1.2.8.dfsg-5

libvncserver1 recommends no packages.

libvncserver1 suggests no packages.