Bug#882697: stretch-pu: package apparmor/2.11.0-3+deb9u2

[intrigeri]

Hi,

Adam D. Barratt:
> What's the difference between this and +deb9u1? Is it simply this
> change:

> -++features-file=/etc/apparmor/features
> +++features-file=/usr/share/apparmor-features/features

> and the equivalent in debian/install?

Yes (modulo the timing matter regarding the Linux 4.14.x bug, which
was the only reason why +deb9u1 could not make it into a stable
release last time).

> The changelog going from -3 to -3+deb9u2 is confusing, particularly
> given that +deb9u1 has been available to users of proposed-updates for
> some time. If the above is correct, please keep the previous changelog
> stanza for +deb9u1 as-is and add a new entry for +deb9u2 describing the
> path change.

Done and accordingly adjusted the maintainer scripts to remove
the old (now obsolete) /etc/apparmor/features conffile from systems
that had +deb9u1 installed.

I'm attaching 2 updated debdiffs: one from the version in Stretch and
the other one from the version that's already in stable p-u.

Cheers,
-- 
intrigeri

diff -Nru apparmor-2.11.0/debian/apparmor.install apparmor-2.11.0/debian/apparmor.install
--- apparmor-2.11.0/debian/apparmor.install	2017-03-28 12:23:08.0 +0200
+++ apparmor-2.11.0/debian/apparmor.install	2018-02-27 07:46:39.0 +0100
@@ -1,4 +1,5 @@
 debian/apport/source_apparmor.py /usr/share/apport/package-hooks/
+debian/features /usr/share/apparmor-features/
 debian/lib/apparmor/functions /lib/apparmor/
 debian/lib/apparmor/profile-load /lib/apparmor/
 etc/apparmor/parser.conf
diff -Nru apparmor-2.11.0/debian/apparmor.maintscript apparmor-2.11.0/debian/apparmor.maintscript
--- apparmor-2.11.0/debian/apparmor.maintscript	2015-08-13 21:25:45.0 +0200
+++ apparmor-2.11.0/debian/apparmor.maintscript	2018-02-27 07:46:39.0 +0100
@@ -1,3 +1,4 @@
 rm_conffile /etc/apparmor/functions 2.5.1-0ubuntu4
 rm_conffile /etc/apparmor/rc.apparmor.functions 2.5.1-0ubuntu4
 rm_conffile /etc/apparmor.d/abstractions/ubuntu-sdk-base 2.8.0-0ubuntu20~
+rm_conffile /etc/apparmor/features 2.11.0-3+deb9u2~
diff -Nru apparmor-2.11.0/debian/changelog apparmor-2.11.0/debian/changelog
--- apparmor-2.11.0/debian/changelog	2017-03-28 12:29:15.0 +0200
+++ apparmor-2.11.0/debian/changelog	2018-02-27 07:46:39.0 +0100
@@ -1,3 +1,24 @@
+apparmor (2.11.0-3+deb9u2) UNRELEASED; urgency=medium
+
+  * Move the features file to /usr/share/apparmor-features;
+accordingly remove the old (now obsolete) '/etc/apparmor/features'
+conffile (Closes: #883682).
+  * Configure gbp for DEP-14 and avoid gbp-pq prefixing patches
+with numbers.
+
+ -- intrigeri   Tue, 27 Feb 2018 06:46:39 +
+
+apparmor (2.11.0-3+deb9u1) stretch; urgency=medium
+
+  * Pin the AppArmor feature set to Stretch's kernel (Closes: #879585).
+This ensures Stretch systems, even when running a newer kernel (e.g.
+from backports), have their AppArmor feature set pinned to the one
+supported by the AppArmor policy shipped in Stretch. Otherwise they
+would experience breakage due to new AppArmor mediation features
+introduced in recent kernels.
+
+ -- intrigeri   Sat, 25 Nov 2017 18:04:05 +
+
 apparmor (2.11.0-3) unstable; urgency=medium
 
   * Fix CVE-2017-6507: don't unload unknown profiles during package
diff -Nru apparmor-2.11.0/debian/features apparmor-2.11.0/debian/features
--- apparmor-2.11.0/debian/features	1970-01-01 01:00:00.0 +0100
+++ apparmor-2.11.0/debian/features	2018-02-27 07:46:39.0 +0100
@@ -0,0 +1,23 @@
+caps {mask {chown dac_override dac_read_search fowner fsetid kill setgid setuid setpcap linux_immutable net_bind_service net_broadcast net_admin net_raw ipc_lock ipc_owner sys_module sys_rawio sys_chroot sys_ptrace sys_pacct sys_admin sys_boot sys_nice sys_resource sys_time sys_tty_config mknod lease audit_write audit_control setfcap mac_override mac_admin syslog wake_alarm block_suspend audit_read
+}
+}
+rlimit {mask {cpu fsize data stack core rss nproc nofile memlock as locks sigpending msgqueue nice rtprio rttime
+}
+}
+capability {0xff
+}
+file {mask {create read write exec append mmap_exec link lock
+}
+}
+domain {change_profile {yes
+}
+change_onexec {yes
+}
+change_hatv {yes
+}
+change_hat {yes
+}
+}
+policy {set_load {yes
+}
+}
diff -Nru apparmor-2.11.0/debian/gbp.conf apparmor-2.11.0/debian/gbp.conf
--- apparmor-2.11.0/debian/gbp.conf	1970-01-01 01:00:00.0 +0100
+++ apparmor-2.11.0/debian/gbp.conf	2018-02-27 07:46:39.0 +0100
@@ -0,0 +1,6 @@
+[DEFAULT]
+pristine-tar = True
+debian-branch = debian/stretch
+upstream-branch = upstream/latest
+upstream-vcs-tag = v%(version)s
+patch-numbers = False
diff -Nru apparmor-2.11.0/debian/patches/pin-feature-set.patch apparmor-2.11.0/debian/patches/pin-feature-set.patch
--- apparmor-2.11.0/debian/patches/pin-feature-set.patch	1970-01-01 01:00:00.0 +0100
+++ apparmor-2.11.0/debian/patches/pin-feature-set.patch	2018-02-27 07:46:39.0 +0100
@@ -0,0 +1,18 

Bug#891618: DistributionNotFound: The 'pyqt5' distribution was not found

[Ghislain Antony Vaillant]

Package: spyder3
Version: 3.2.6+dfsg1-1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

The latest update of src:spyder now explicitly requires pyqt5. Despite
being pulled transitively by python{,3}-qtpy, detection by pkg_resources 
is failing. Launching spyder3 yields a DistributionNotFound error with
the following traceback:

Traceback (most recent call last):
  File "/usr/bin/spyder3", line 6, in 
from pkg_resources import load_entry_point
  File 
"/home/ghislain/.local/lib/python3.6/site-packages/pkg_resources/__init__.py", 
line 3147, in 
@_call_aside
  File 
"/home/ghislain/.local/lib/python3.6/site-packages/pkg_resources/__init__.py", 
line 3131, in _call_aside
f(*args, **kwargs)
  File 
"/home/ghislain/.local/lib/python3.6/site-packages/pkg_resources/__init__.py", 
line 3160, in _initialize_master_working_set
working_set = WorkingSet._build_master()
  File 
"/home/ghislain/.local/lib/python3.6/site-packages/pkg_resources/__init__.py", 
line 666, in _build_master
ws.require(__requires__)
  File 
"/home/ghislain/.local/lib/python3.6/site-packages/pkg_resources/__init__.py", 
line 984, in require
needed = self.resolve(parse_requirements(requirements))
  File 
"/home/ghislain/.local/lib/python3.6/site-packages/pkg_resources/__init__.py", 
line 870, in resolve
raise DistributionNotFound(req, requirers)
pkg_resources.DistributionNotFound: The 'pyqt5' distribution was not found and 
is required by spyder

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

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

Versions of packages spyder3 depends on:
ii  python3 3.6.4-1
ii  python3-spyder  3.2.6+dfsg1-1
ii  python3.6   3.6.4-4

spyder3 recommends no packages.

spyder3 suggests no packages.

Versions of packages python3-spyder depends on:
ii  libjs-jquery 3.2.1-1
ii  libjs-mathjax2.7.2+dfsg-1
ii  pylint3  1.8.1-1
ii  python3  3.6.4-1
ii  python3-chardet  3.0.4-1
ii  python3-cloudpickle  0.5.2-2
ii  python3-jedi 0.11.1-1
ii  python3-nbconvert5.3.1-1
ii  python3-numpydoc 0.7.0-1
ii  python3-pickleshare  0.7.4-2
ii  python3-psutil   5.4.2-1
ii  python3-pycodestyle  2.3.1-2
ii  python3-pyflakes 1.6.0-1
ii  python3-pygments 2.2.0+dfsg-1
ii  python3-qtawesome0.4.4+ds1-1
ii  python3-qtconsole4.3.1-1
ii  python3-qtpy 1.3.1-1
ii  python3-rope 0.10.5-2
ii  python3-sphinx   1.6.7-1
ii  python3-zmq  16.0.2-2+b1
ii  spyder-common3.2.6+dfsg1-1

Versions of packages python3-spyder suggests:
ii  cython3 0.26.1-0.4
pn  python3-matplotlib  
pn  python3-numpy   
pn  python3-pandas  
ii  python3-pil 4.3.0-2
pn  python3-scipy   
pn  python3-sympy   
pn  spyder-doc  

Versions of packages python3-pyqt5 depends on:
ii  libc62.26-6
ii  libgcc1  1:8-20180218-1
ii  libpython3.6 3.6.4-4
ii  libqt5core5a [qtbase-abi-5-9-2]  5.9.2+dfsg-12
ii  libqt5dbus5  5.9.2+dfsg-12
ii  libqt5designer5  5.9.2-6
ii  libqt5gui5   5.9.2+dfsg-12
ii  libqt5help5  5.9.2-6
ii  libqt5network5   5.9.2+dfsg-12
ii  libqt5printsupport5  5.9.2+dfsg-12
ii  libqt5test5  5.9.2+dfsg-12
ii  libqt5widgets5   5.9.2+dfsg-12
ii  libqt5xml5   5.9.2+dfsg-12
ii  libstdc++6   8-20180218-1
ii  python3  3.6.4-1
ii  python3-sip [sip-py3api-12.3]4.19.7+dfsg-1

Versions of packages python3-pyqt5 suggests:
pn  python3-pyqt5-dbg  

-- no debconf information

Bug#891617: DistributionNotFound: The 'pyopengl' distribution was not found

[Ghislain Antony Vaillant]

Package: spyder
Version: 3.2.6+dfsg1-1
Severity: grave
Justification: renders package unusable

The latest update of src:spyder now requires pyopengl, which is
currently missing from Depends. Launching spyder yields a
DistributionNotFound error with the following traceback:

Traceback (most recent call last):
  File "/usr/bin/spyder", line 6, in 
from pkg_resources import load_entry_point
  File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 3147, 
in 
@_call_aside
  File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 3131, 
in _call_aside
f(*args, **kwargs)
  File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 3160, 
in _initialize_master_working_set
working_set = WorkingSet._build_master()
  File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 666, 
in _build_master
ws.require(__requires__)
  File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 984, 
in require
needed = self.resolve(parse_requirements(requirements))
  File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 870, 
in resolve
raise DistributionNotFound(req, requirers)
pkg_resources.DistributionNotFound: The 'pyopengl' distribution was not found 
and is required by spyder

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

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

Versions of packages spyder depends on:
ii  python 2.7.14-4
ii  python-spyder  3.2.6+dfsg1-1
ii  python2.7  2.7.14-6

spyder recommends no packages.

spyder suggests no packages.

Versions of packages python-spyder depends on:
ii  libjs-jquery3.2.1-1
ii  libjs-mathjax   2.7.2+dfsg-1
ii  pylint  1.8.1-1
ii  python  2.7.14-4
ii  python-chardet  3.0.4-1
ii  python-cloudpickle  0.5.2-2
ii  python-jedi 0.11.1-1
ii  python-nbconvert5.3.1-1
ii  python-numpydoc 0.7.0-1
ii  python-pickleshare  0.7.4-2
ii  python-psutil   5.4.2-1
ii  python-pycodestyle  2.3.1-2
ii  python-pyflakes 1.6.0-1
ii  python-pygments 2.2.0+dfsg-1
ii  python-qtawesome0.4.4+ds1-1
ii  python-qtconsole4.3.1-1
ii  python-qtpy 1.3.1-1
ii  python-rope 0.10.5-2
ii  python-sphinx   1.6.7-1
ii  python-zmq  16.0.2-2+b1
ii  spyder-common   3.2.6+dfsg1-1

Versions of packages python-spyder suggests:
pn  cython 
pn  python-matplotlib  
ii  python-numpy   1:1.13.3-2
pn  python-pandas  
ii  python-pil 4.3.0-2
pn  python-scipy   
pn  python-sympy   
pn  spyder-doc 

Versions of packages python-pyqt5 depends on:
ii  libc62.26-6
ii  libqt5core5a [qtbase-abi-5-9-2]  5.9.2+dfsg-12
ii  libqt5dbus5  5.9.2+dfsg-12
ii  libqt5designer5  5.9.2-6
ii  libqt5gui5   5.9.2+dfsg-12
ii  libqt5help5  5.9.2-6
ii  libqt5network5   5.9.2+dfsg-12
ii  libqt5printsupport5  5.9.2+dfsg-12
ii  libqt5test5  5.9.2+dfsg-12
ii  libqt5widgets5   5.9.2+dfsg-12
ii  libqt5xml5   5.9.2+dfsg-12
ii  libstdc++6   8-20180218-1
ii  python   2.7.14-4
ii  python-sip [sip-api-12.3]4.19.7+dfsg-1

Versions of packages python-pyqt5 suggests:
pn  python-pyqt5-dbg  

-- no debconf information

Bug#891616: mirror submission for mirror.174.io

[Alex Smith]

Package: mirrors
Severity: wishlist
User: mirr...@packages.debian.org
Usertags: mirror-submission

Submission-Type: new
Site: mirror.174.io
Type: leaf
Archive-architecture: amd64 i386
Archive-http: /debian/
Archive-rsync: debian/
Maintainer: Alex Smith 
Country: NZ New Zealand
Location: Wellington
Sponsor: 174.io Hosting https://174.io




Trace Url: http://mirror.174.io/debian/project/trace/
Trace Url: http://mirror.174.io/debian/project/trace/ftp-master.debian.org
Trace Url: http://mirror.174.io/debian/project/trace/mirror.174.io

Bug#875637: stretch update for iipimage-server

[Mathieu Malaterre]

On Mon, Feb 26, 2018 at 9:02 PM, Adrian Bunk  wrote:
> On Wed, Nov 22, 2017 at 09:21:10PM +, Debian Bug Tracking System wrote:
>>...
>>  iipimage (1.0-3) unstable; urgency=medium
>>  .
>>* Really fix apache configuration. Closes: #875637
>>...
>
> Thanks a lot for fixing this bug for unstable.
>
> It is still present in stretch, could you also fix it there?
> Alternatively, I can fix it for stretch if you don't object.

Please do :)

Thanks for your help!

Bug#891615: python3-zeitgeist: python3 invalid syntax error during installation

[Jean Baptiste Favre]

Package: python3-zeitgeist
Version: 1.0.1-0.1
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear Maintainer,

While upgrading python3-zeitgeist, I got a python3 invalid syntax error:

> LANG=C sudo apt install python3-zeitgeist
[sudo] password for jbfavre: 
Reading package lists... Done
Building dependency tree   
Reading state information... Done
python3-zeitgeist is already the newest version (1.0.1-0.1).
python3-zeitgeist set to manually installed.
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
2 not fully installed or removed.
After this operation, 0 B of additional disk space will be used.
Do you want to continue? [Y/n] 
Setting up python3-zeitgeist (1.0.1-0.1) ...
  File "/usr/lib/python3/dist-packages/zeitgeist/client.py", line 121
except dbus.exceptions.DBusException, e:
^
SyntaxError: invalid syntax

  File "/usr/lib/python3/dist-packages/zeitgeist/datamodel.py", line 144
except KeyError, e:
   ^
SyntaxError: invalid syntax

dpkg: error processing package python3-zeitgeist (--configure):
 installed python3-zeitgeist package post-installation script subprocess 
returned error exit status 1
dpkg: dependency problems prevent configuration of zeitgeist:
 zeitgeist depends on python3-zeitgeist; however:
  Package python3-zeitgeist is not configured yet.

dpkg: error processing package zeitgeist (--configure):
 dependency problems - leaving unconfigured
Errors were encountered while processing:
 python3-zeitgeist
 zeitgeist
E: Sub-process /usr/bin/dpkg returned an error code (1)

This error occurs at postinst level, when trying to compile python files with 
command "py3compile -p python3-zeitgeist"

Regards,
JB


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

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

Versions of packages python3-zeitgeist depends on:
ii  python3   3.6.4-1
ii  python3-dbus  1.2.6-1
ii  python3-gi3.26.1-2
ii  python3-xdg   0.25-4

python3-zeitgeist recommends no packages.

python3-zeitgeist suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQKTBAEBCgB9FiEEToRbojDLTUSJBphHtN1Tas99hzcFAlqVADlfFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDRF
ODQ1QkEyMzBDQjRENDQ4OTA2OTg0N0I0REQ1MzZBQ0Y3RDg3MzcACgkQtN1Tas99
hzf61RAArc33j3JQnKfroOE6Xwgs8TaLPDhxoxpyhrJvjzdLR2tXUPh5w9ov9+FR
4U8lgMeooKJSQaNcSpDL7XZ/xJLFxmd6FdG3aQS0BEHZn/ioXqw35+mzLWvj8SJe
RU/ICFrDEEQSThokRen0dNhDrBB9+IaMmsX2oUYnbq0ro4ovqBwqtTQEU9UOO+pm
Xmg0nn93Y4Unt8Lupg975iaaR6z8y7ajnEg+kGdN2FH9aUnMpmL8XNXowOeTxPF+
RbMDBLpp/+IUd35ySm9r8OsM5sWzXbtIaOzVEQZ8K86mvhpcJDiQ2/3G/kwMiTF2
MGUIB6mQzz+7cWWxM17PIzCpseklV0bB1kcZjTGfE37F+l1pc5lgQ16eApZOPaKF
VWYl5pilEagJ66k6uVxoLDPoMiWfBVrS0Ce1RK9QX/lajA5m+AIXUp7gOzedpJSr
dYAGLQa/k7L4p6PJ2gNHQGGJh2qUwVtXNun5gMZI0b3D0LWPgFG11t002zb2BQYO
MUL/IrmWbEDQBH472IaB7PU4gNhsX2h1/SD+XxQFeH6sgiDJMYndaJ4p8EoMTiEa
Py9aiREjO898oiGn25PKXrTAvnCj1lDJxhKBbyRMqswZow+yWehqZvTjYgaYB2aq
B/foQRqrFm/WUOXHLMfTZuylcOnCKorXyrXLKrK72D2gGInUI/I=
=FK51
-END PGP SIGNATURE-

Bug#888955: Systemd dependency

[Christian Ehrhardt]

Hi,
I just wanted to let you know that working on the related Ubuntu bug
uncovered a dependency to systemd versions.
The suggested fix works were a system is affected, but it is a bit of a big
hammer.
OTOH the systemd fix that solves it in newer versions is yet unknown.

I'd ask you to read through [1] when you start to work on this bug to fetch
the latest status.
That avoids the need for double posting on any new small step forward.

[1]: https://bugs.launchpad.net/ubuntu/+source/open-vm-tools/+bug/1750780

-- 
Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd

Bug#891614: jackson-databind: CVE-2018-7489: incomplete fix for CVE-2017-7525 permits unsafe serialization via c3p0 libraries

[Salvatore Bonaccorso]

Source: jackson-databind
Version: 2.9.4-1
Severity: grave
Tags: patch security upstream
Justification: user security hole
Forwarded: https://github.com/FasterXML/jackson-databind/issues/1931

Hi,

the following vulnerability was published for jackson-databind.

CVE-2018-7489[0]:
| FasterXML jackson-databind before 2.8.11.1 and 2.9.x before 2.9.5
| allows unauthenticated remote code execution because of an incomplete
| fix for the CVE-2017-7525 deserialization flaw. This is exploitable by
| sending maliciously crafted JSON input to the readValue method of the
| ObjectMapper, bypassing a blacklist that is ineffective if the c3p0
| libraries are available in the classpath.

If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2018-7489
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-7489
[1] https://github.com/FasterXML/jackson-databind/issues/1931
[2] 
https://github.com/FasterXML/jackson-databind/commit/6799f8f10cc78e9af6d443ed6982d00a13f2e7d2

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#661295:

[Carlos Alvarez]

juan carlos aa

Bug#891613: steam: Steam update suddenly depends on full nvidia graphic support regardless of equipment

[Main Account]

Package: steam
Version: 1.0.0.54-4
Severity: normal

Dear Maintainer,

My system uses AMD graphics and while X installs a variety of other drivers, it
is not that demanding of storage. Steam only adds nvidia support, but with the
new edition it *requires* nvidia support whether needed or not.

apt install steam
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following additional packages will be installed:
  glx-alternative-mesa glx-alternative-nvidia glx-diversions libegl-nvidia0
libegl-nvidia0:i386 libegl1:i386 libgl1-nvidia-glvnd-glx:i386 libgles-
nvidia2:i386 libgles2:i386 libglx-nvidia0 libglx-nvidia0:i386 libnvidia-
cfg1:i386 libnvidia-egl-wayland1 libnvidia-egl-wayland1:i386 libnvidia-eglcore
libnvidia-eglcore:i386 libnvidia-glcore libnvidia-glcore:i386 libopengl0:i386
libvulkan1:i386 libwayland-client0:i386 libwayland-server0:i386 nvidia-
alternative nvidia-driver-libs:i386 nvidia-driver-libs-i386:i386 nvidia-egl-
common nvidia-egl-icd:i386 nvidia-egl-wayland-common nvidia-egl-wayland-
icd:i386 nvidia-installer-cleanup nvidia-legacy-check nvidia-vulkan-common
nvidia-vulkan-icd nvidia-vulkan-icd:i386 update-glx
Suggested packages:
  nvidia-driver vulkan-utils vulkan-utils:i386 steam-devices:i386
The following NEW packages will be installed:
  glx-alternative-mesa glx-alternative-nvidia glx-diversions libegl-nvidia0
libegl-nvidia0:i386 libegl1:i386 libgl1-nvidia-glvnd-glx:i386 libgles-
nvidia2:i386 libgles2:i386 libglx-nvidia0 libglx-nvidia0:i386 libnvidia-
cfg1:i386 libnvidia-egl-wayland1 libnvidia-egl-wayland1:i386 libnvidia-eglcore
libnvidia-eglcore:i386 libnvidia-glcore libnvidia-glcore:i386 libopengl0:i386
libvulkan1:i386 libwayland-client0:i386 libwayland-server0:i386 nvidia-
alternative nvidia-driver-libs:i386 nvidia-driver-libs-i386:i386 nvidia-egl-
common nvidia-egl-icd:i386 nvidia-egl-wayland-common nvidia-egl-wayland-
icd:i386 nvidia-installer-cleanup nvidia-legacy-check nvidia-vulkan-common
nvidia-vulkan-icd nvidia-vulkan-icd:i386 update-glx
The following packages will be upgraded:
  steam:i386
1 upgraded, 35 newly installed, 0 to remove and 43 not upgraded.
Need to get 33.7 MB of archives.
After this operation, 134 MB of additional disk space will be used.



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

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

Versions of packages steam depends on:
ii  debconf [debconf-2.0] 1.5.65
ii  libc6 2.26-6
ii  libgl1-mesa-dri   17.3.5-1
ii  libgl1-mesa-glx   17.3.5-1
ii  libgpg-error0 1.27-6
ii  libstdc++68-20180218-1
ii  libtxc-dxtn-s2tc0 [libtxc-dxtn0]  0~git20131104-1.1
ii  libudev1  237-3
ii  libx11-6  2:1.6.4-3
ii  libxinerama1  2:1.1.3-1+b3
ii  xz-utils  5.2.2-1.3

Versions of packages steam recommends:
ii  fonts-liberation  1:1.07.4-5
ii  gnome-terminal [x-terminal-emulator]  3.26.2-3
ii  libxss1   1:1.2.2-1+b2
ii  pterm [x-terminal-emulator]   0.70-1
ii  xterm [x-terminal-emulator]   331-1
ii  zenity3.27.90-1

Versions of packages steam suggests:
pn  steam-devices  

-- debconf information excluded

Bug#884417: python-trezor v0.9.0 tagged - next steps?

[Jonathan Cross]

>  I'll try to take care of it this week.

Fantastic, thanks Tristan!

Bug#891612: thumbor: uninstallable after python-imaging removal

[Andreas Beckmann]

Package: thumbor
Version: 6.3.2-4
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package is no longer
installable in sid:

The following packages have unmet dependencies:
 thumbor : Depends: python-imaging but it is not installable


Cheers,

Andreas

Bug#849812: ITP: requests-ntlm -- HTTP NTLM authentication using the requests library

[Harlan Lieberman-Berg]

On Fri, 25 Aug 2017 15:37:42 +0100 Dominic Hargreaves  wrote:
> After a bit of delay I worked on this, to discover that its depedency
> ntlm-auth had no copyright statement. I am awaiting clarification
> from upstream on that:
>
> .

Hi Dom,

Just had an ansible user ping me about this (because of the transitive
dep from winrm).  Is this something you're still in the midst of
packaging, and/or is there anything I can do to help?

Sincerely,

Bug#891558: Checking in progress on ... message improvement ideas

[Theodore Ts'o]

reassign 891558 systemd 237
thanks

On Tue, Feb 27, 2018 at 08:58:25AM +0800, 積丹尼 Dan Jacobson wrote:
> (Alas the actual "Checking in progress on ..." messages are the kind one
> sees during boot that are not logged anywhere(!) and thus one only can
> tell you from personal memory.)

It appears the message you are complaining about comes from systemd:

./debian/patches/debian/fsckd-daemon-for-inter-fsckd-communication.patch:+  
   ngettext("Checking in progress on %d disk (%3.1f%% 
complete)",
./debian/patches/debian/fsckd-daemon-for-inter-fsckd-communication.patch:+  
"Checking in progress on %d disks (%3.1f%% 
complete)", m->numdevices),
./src/fsckd/fsckd.c: ngettext("Checking in progress 
on %d disk (%3.1f%% complete)",
./src/fsckd/fsckd.c:  "Checking in progress 
on %d disks (%3.1f%% complete)", m->numdevices),

- Ted

Bug#891611: jessie-pu: package subversion/1.8.10-6+deb8u6

[James McCoy]

Package: release.debian.org
Severity: normal
Tags: jessie
User: release.debian@packages.debian.org
Usertags: pu

This upload would fix crashes that are seen when using subversion's Perl
bindings.  In particular, git-svn has been a common victim since its
memory usage patterns tend to cause the right conditions.

I've verified this against the originally reported issue[0] and
Salvatore Bonaccorso, who prodded me to prepare the upload, has verified
it against their problematic repository.

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

Kernel: Linux 4.15.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.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diffstat for subversion_1.8.10-6+deb8u5 subversion_1.8.10-6+deb8u6

 debian/patches/perl-swig-crash  |  244 
 subversion-1.8.10/debian/changelog  |7 
 subversion-1.8.10/debian/patches/series |1 
 3 files changed, 252 insertions(+)

diff -u subversion-1.8.10/debian/changelog subversion-1.8.10/debian/changelog
--- subversion-1.8.10/debian/changelog
+++ subversion-1.8.10/debian/changelog
@@ -1,3 +1,10 @@
+subversion (1.8.10-6+deb8u6) jessie; urgency=medium
+
+  * Backport patches/perl-swig-crash from upstream to fix crashes with Perl
+bindings, commonly seen when using git-svn (Closes: #780246, #534763).
+
+ -- James McCoy   Mon, 26 Feb 2018 22:00:47 -0500
+
 subversion (1.8.10-6+deb8u5) jessie-security; urgency=high
 
   * patches/CVE-2016-8734: Unrestricted XML entity expansion in HTTP clients
diff -u subversion-1.8.10/debian/patches/series 
subversion-1.8.10/debian/patches/series
--- subversion-1.8.10/debian/patches/series
+++ subversion-1.8.10/debian/patches/series
@@ -33,0 +34 @@
+perl-swig-crash
only in patch2:
unchanged:
--- subversion-1.8.10.orig/debian/patches/perl-swig-crash
+++ subversion-1.8.10/debian/patches/perl-swig-crash
@@ -0,0 +1,244 @@
+
+r1668618 | philip | 2015-03-23 08:33:22 -0400 (Mon, 23 Mar 2015) | 6 lines
+
+* subversion/bindings/swig/include/svn_types.swg: Change the
+   SWIG Perl binding code that was marked "clearly buggy" so
+   that svn_swig_pl_from_md5 follows the same pattern as
+   svn_swig_pl_from_stream.  This may fix a SEGV reported
+   via Debian: https://bugs.debian.org/780246
+
+
+Index: trunk/subversion/bindings/swig/include/svn_types.swg
+===
+--- trunk/subversion/bindings/swig/include/svn_types.swg   (revision 
1668617)
 trunk/subversion/bindings/swig/include/svn_types.swg   (revision 
1668618)
+@@ -1116,11 +1116,7 @@
+ }
+ 
+ %typemap(argout) unsigned char *result_digest {
+-  /* FIXME: This code is clearly buggy. The return value of sv_newmortal()
+- is immediately overwritten by the return value
+- of svn_swig_pl_from_md5(). */
+-ST(argvi) = sv_newmortal();
+-ST(argvi++) = svn_swig_pl_from_md5($1);
++%append_output(svn_swig_pl_from_md5($1));
+ }
+ #endif
+ 
+
+
+r1671388 | rschupp | 2015-04-05 08:48:45 -0400 (Sun, 05 Apr 2015) | 6 lines
+
+* subversion/bindings/swig/include/svn_types.swg: Following r1668618
+   fix two more instances where the Perl argument stack pointer 
+   was bumped without checking if there's enough space allocated.
+   While we're at it, reduce the size of the temp array - 30 bytes
+   are more than enough to hold a decimal representation of a 64-bit integer.
+
+
+Index: trunk/subversion/bindings/swig/include/apr.swg
+===
+--- trunk/subversion/bindings/swig/include/apr.swg (revision 1671387)
 trunk/subversion/bindings/swig/include/apr.swg (revision 1671388)
+@@ -31,23 +31,21 @@
+ */
+ #ifdef SWIGPERL
+ %typemap(out) long long {
+-char temp[256];
++char temp[30];
+ sprintf(temp, "%" APR_INT64_T_FMT, (apr_int64_t) $1);
+-ST(argvi) = sv_newmortal();
+-sv_setpv((SV*)ST(argvi++), temp);
++%append_output(sv_2mortal(newSVpv(temp, 0)));
+ }
+ 
+ %typemap(out) unsigned long long {
+-char temp[256];
++char temp[30];
+ sprintf(temp, "%" APR_UINT64_T_FMT, (apr_uint64_t) $1);
+-ST(argvi) = sv_newmortal();
+-sv_setpv((SV*)ST(argvi++), temp);
++%append_output(sv_2mortal(newSVpv(temp, 0)));
+ }
+ 
+ %typemap(in, numinputs=0) long long *OUTPUT (apr_int64_t temp)
+ "$1 = ";
+ %typemap(argout) long long *OUTPUT {
+-  char temp[256];
++  char temp[30];
+   sprintf(temp, "%" APR_INT64_T_FMT, (apr_int64_t)*($1));
+   %append_output(sv_2mortal(newSVpv(temp, 

Bug#891610: Stop suggesting powermgmt-base

[Marco d'Itri]

Package: apt
Version: 1.6~beta1
Severity: minor

Please stop suggesting powermgmt-base: this is an obsolete, orphaned and 
unmantained package which I last NMU'ed myself in 2014.
It provides the on_ac_power command which is only used on non-systemd 
systems anyway.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#891020: Bug#891413: fixed in ppp 2.4.7-2+2

[Christopher Dow]

Thanks, this fixed my problem as well.

-Chris Dow

Bug#891609: apt: sub-command to show the copyright file of a package (similar to `apt changelog`)

[Paul Wise]

Package: apt
Severity: wishlist

It would be nice to have an apt sub-command to show the copyright file
of a package, with the same semantics as `apt changelog`. This would be
most useful for Debian contributors, but could also be useful for devs
wanting to ensure license compatibility with their work or for users
who are not interested in certain licenses.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#891608: ITP: python-certbot-dns-cloudflare -- a plugin to perform DNS validation for certbot through Cloudflare

[Harlan Lieberman-Berg]

Package: wnpp
Severity: wishlist
Owner: Harlan Lieberman-Berg 

* Package name: python-certbot-dns-cloudflare
  Version : 0.22.0
  Upstream Author : Certbot Project 
* URL : https://certbot.eff.org
* License : Apache-2.0
  Programming Lang: Python
  Description : a certbot plugin for validations through Cloudflare

  This will be maintained by the Debian Let's Encrypt Team inside the
  certbot sub-team.

Bug#891607: pike7.8: FTBFS on powerpc: Couldn't load master object.

[Aaron M. Ucko]

Source: pike7.8
Version: 7.8.866-8.1
Severity: normal
Tags: upstream
User: debian-powe...@lists.debian.org
Usertags: powerpc

Builds of pike7.8 for powerpc (admittedly not a release architecture)
have been failing lately, per the below excerpts from [1].  Could you
please take a look?

Thanks!

[1] 
https://buildd.debian.org/status/fetch.php?pkg=pike7.8=powerpc=7.8.866-8.1=1518195336=0



touch remake
Run make again
Makefile:451: recipe for target 'Makefile' failed
make[5]: *** [Makefile] Error 1
Original CFLAGS: -g -g -Wformat -Werror=format-security -ggdb3  -O2 
-fdebug-prefix-map=/«PKGBUILDDIR»=. -fstack-protector-strong -pipe -W -Wall 
-Wno-unused -Wcomment -Wformat -Wformat-security 
-Wimplicit-function-declaration -Wmultichar -Wswitch -Wuninitialized 
-Wpointer-arith -Wchar-subscripts -Wno-long-long -Wdeclaration-after-statement  
-fPIC -DDYNAMIC_MODULE
Modified CFLAGS:-fdebug-prefix-map=/«PKGBUILDDIR»=. 
-fstack-protector-strong -pipe  -fPIC -DDYNAMIC_MODULE  -O 
Compiling post_modules/GL/top.c
gcc -I. -I/«PKGBUILDDIR»/src/post_modules/GL 
-I/«PKGBUILDDIR»/build/linux-4.9.0-0.bpo.5-powerpc64-ppc -I/«PKGBUILDDIR»/src 
-Wdate-time -D_FORTIFY_SOURCE=2 -DDEBIAN 
-I/«PKGBUILDDIR»/build/linux-4.9.0-0.bpo.5-powerpc64-ppc/bundles/include 
-DHAVE_CONFIG_H -fdebug-prefix-map=/«PKGBUILDDIR»=. -fstack-protector-strong 
-pipe -fPIC -DDYNAMIC_MODULE -O -c /«PKGBUILDDIR»/src/post_modules/GL/top.c -o 
top.o
/«PKGBUILDDIR»/build/linux-4.9.0-0.bpo.5-powerpc64-ppc/pike -DNOT_INSTALLED 
-DPRECOMPILED_SEARCH_MORE 
-m/«PKGBUILDDIR»/build/linux-4.9.0-0.bpo.5-powerpc64-ppc/master.pike  
/«PKGBUILDDIR»/src/post_modules/GL/gen.pike 
/«PKGBUILDDIR»/src/post_modules/GL/auto.c.in > auto.c.tmp
There's no master to handle the error. Dumping it raw:
({ /* 2 elements */
"Mark stack overflow.\n",
({ /* 2 elements */
object(Users/hww3/pikebuild/src/builtin.cmod:1707),
object(Users/hww3/pikebuild/src/builtin.cmod:1707)
})
})
[...]
There's no master to handle the error. Dumping it raw:
({ /* 2 elements */
"Mark stack overflow.\n",
({ /* 2 elements */
object(Users/hww3/pikebuild/src/builtin.cmod:1707),
object(Users/hww3/pikebuild/src/builtin.cmod:1707)
})
})
/«PKGBUILDDIR»/src/object.c:696: Fatal error:
Couldn't load master object.
No stack - no backtrace.
Aborted
Makefile:528: recipe for target 'auto.c' failed
make[7]: *** [auto.c] Error 134
Makefile:118: recipe for target 'all' failed
make[6]: *** [all] Error 2
Makefile:92: recipe for target 'override' failed
make[5]: *** [override] Error 2
Makefile:105: recipe for target 'GL' failed
make[4]: *** [GL] Error 1
Makefile:1231: recipe for target 'post_module_objects' failed
make[3]: *** [post_module_objects] Error 1
Makefile:151: recipe for target '_make_in_builddir' failed
make[2]: *** [_make_in_builddir] Error 2
Makefile:68: recipe for target 'compile' failed
make[1]: *** [compile] Error 2
make[1]: Leaving directory '/«PKGBUILDDIR»'
debian/rules:148: recipe for target 'build-arch-stamp' failed

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

Bug#877195: the patches

[Russell Coker]

What's the situation with this one?  Could it be included in the next Stretch 
update?

On Saturday, 9 December 2017 1:33:39 PM AEDT Russell Coker wrote:
> On Saturday, 2 December 2017 11:05:24 AM AEDT Adam D. Barratt wrote:
> > IFF it's versioned as 2:2.20161023.1-9+deb9u1, uses "stretch" as the
> > changelog distribution, is otherwise identical to the diff presented in
> > this bug log and is built and tested on a stretch system, then OK.
> 
> I've attached a debdiff that only differs in file timestamps, the version
> change you requested, and the changelog timestamp.
> 
> I have tested it on my main mail server, one of my main web servers, one of
> my minor mail servers, and a shell server.  It passed all tests and did
> everything as well as expected with no regressions.
> 
> Please consider it for inclusion.


-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/

Bug#891606: kwayland: please version doxygen B-D per upstream

[Aaron M. Ucko]

Source: kwayland
Version: 4:5.42.0-2
Severity: normal

User: debian-powe...@lists.debian.org
Usertags: powerpcspe

Builds of kwayland for powerpcspe (admittedly not a release architecture)
have been failing lately:

  CMake Error at 
/usr/share/cmake-3.9/Modules/FindPackageHandleStandardArgs.cmake:137 (message):
Could NOT find Doxygen: Found unsuitable version "1.8.12", but required is
at least "1.8.13" (found /usr/bin/doxygen)

(Doxygen is out of date on this architecture, apparently due to Ruby
toolchain issues.)

Could you please version the build dependency on doxygen to (>= 1.8.13~)
to match upstream's requirements?

Thanks!

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

Bug#891605: kconfig: please version doxygen B-D per upstream

[Aaron M. Ucko]

Source: kconfig
Version: 5.42.0-2
Severity: normal
User: debian-powe...@lists.debian.org
Usertags: powerpcspe

Builds of kconfig for powerpcspe (admittedly not a release architecture)
have been failing lately:

  CMake Error at 
/usr/share/cmake-3.9/Modules/FindPackageHandleStandardArgs.cmake:137 (message):
Could NOT find Doxygen: Found unsuitable version "1.8.12", but required is
at least "1.8.13" (found /usr/bin/doxygen)

(Doxygen is out of date on this architecture, apparently due to Ruby
toolchain issues.)

Could you please version the build dependency on doxygen to (>= 1.8.13~)
to match upstream's requirements?

Thanks!

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

Bug#891604: libatk-wrapper-java: System.out.println in AtkWrapper static initialiser block

[Ben Caradoc-Davies]

Package: libatk-wrapper-java
Version: 0.33.3-19
Severity: normal

Dear Maintainer,

debian/patches/GC, introduced in 258a0ac1d0a2f7d15590ce72a1814c7165412936
and present in 0.33.3-18 and 0.33.3-19, inserts a line
"System.out.println(gcbean);"
into the AtkWrapper static initialiser block, causing applications to write
lines like "sun.management.GarbageCollectorImpl@52e677af" to standard output on
startup. Please remove this line.

Kind regards,
Ben.



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

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

Versions of packages libatk-wrapper-java depends on:
ii  x11-utils  7.7+3+b1

Versions of packages libatk-wrapper-java recommends:
ii  libatk-wrapper-java-jni  0.33.3-19

libatk-wrapper-java suggests no packages.

-- no debconf information

Bug#891603: RM: geany-plugin-debugger geany-plugin-multiterm geany-plugin-py geany-plugin-scope geany-plugin-markdown geany-plugin-webhelper -- RoQA; NBS; disabled plugins

[Andreas Beckmann]

Package: ftp.debian.org
Severity: normal

Please decruft geany-plugins.

This is a false positive coming from older versions of the arch:all
metapackage geany-plugins:

# Broken Depends:
geany-plugins: geany-plugins


Andreas

Bug#891602: unar: change Homepage to new upstream URL for the command-line tools

[Paul Wise]

Package: unar
Version: 1.10.1-2+b1
Severity: minor

The current Homepage in the unar package redirects to a new URL:

$ apt-cache show unar | sed -n 's/Homepage: //p' | xargs -d '\n' curl -si | 
grep Location
Location: https://theunarchiver.com/

This new URL contains info about all the Unarchiver products.
They have a more specific URL for the unar command-line tools:

https://theunarchiver.com/command-line

Please change the Homepage to the unar command-line page.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#891381: vt100 line-drawing is a bad idea here

[Paul Wise]

On Mon, 2018-02-26 at 20:31 -0500, Antoine Beaupré wrote:

> Why can't you use --no-colors here?

I definitely can, but I should not have to. The convention for tools
that use colour is to gate that on isatty, undertime should do that.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#891426: stretch-pu: package nvidia-modprobe/384.111-1~deb9u1

[Andreas Beckmann]

On 2018-02-25 15:44, Adam D. Barratt wrote:
> Control: tags -1 + confirmed
> 
> On Sun, 2018-02-25 at 15:02 +0100, Andreas Beckmann wrote:
>> please allow the upgrade of nvidia-modprobe in stretch to a new
>> upstream release matching the updated nvidia-graphics-drivers
>> package.

> Please go ahead.

That was uploaded yesterday, but I just uploaded another fix to sid that
may be worthy to be fixed in stretch, too.

nvidia-modprobe (a setuid root binary) stopped working for regular users
since dash started dropping privileges if euid != uid (like bash has
been doing for ages). The fix is a oneliner: call setuid(0) before
forking modprobe to preserve permissions through the recursive shell and
modprobe invocations needed by our modprobe configuration using install
commands.

The problem is reproducible in stretch if /bin/sh points to bash instead
of dash.

The incremental source debdiff is attached.

If that is acceptable, please reject 384.111-1~deb9u1 and I'll upload
384.111-2~deb9u1 instead.


Andreas
diff --git a/debian/changelog b/debian/changelog
index 7deb07b..0adbb7c 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,21 @@
+nvidia-modprobe (384.111-2~deb9u1) stretch; urgency=medium
+
+  * Rebuild for stretch.
+
+ -- Andreas Beckmann   Tue, 27 Feb 2018 02:06:17 +0100
+
+nvidia-modprobe (384.111-2) unstable; urgency=medium
+
+  * Add setuid.patch to run setuid(0) before forking modprobe to preserve
+privileges through shell invocations and recursive modprobe calls.
+Thanks to Hiromasa YOSHIMOTO for intensive debugging and the final patch!
+(Closes: #888952)
+  * Add debian/upstream/metadata.
+  * Fix new Lintian issues.
+  * Switch Vcs-* URLs to salsa.debian.org.
+
+ -- Andreas Beckmann   Tue, 27 Feb 2018 01:50:01 +0100
+
 nvidia-modprobe (384.111-1) unstable; urgency=medium
 
   * New upstream release.
diff --git a/debian/control b/debian/control
index c6963ee..836da1b 100644
--- a/debian/control
+++ b/debian/control
@@ -12,8 +12,8 @@ Build-Depends:
 Rules-Requires-Root: binary-targets
 Standards-Version: 4.1.3
 Homepage: https://github.com/NVIDIA/nvidia-modprobe
-Vcs-Git: https://anonscm.debian.org/git/pkg-nvidia/nvidia-modprobe.git
-Vcs-Browser: https://anonscm.debian.org/cgit/pkg-nvidia/nvidia-modprobe.git
+Vcs-Browser: https://salsa.debian.org/nvidia-team/nvidia-modprobe
+Vcs-Git: https://salsa.debian.org/nvidia-team/nvidia-modprobe.git
 
 Package: nvidia-modprobe
 Architecture: i386 amd64 armhf ppc64el
diff --git a/debian/copyright b/debian/copyright
index 0974a69..ad3f83a 100644
--- a/debian/copyright
+++ b/debian/copyright
@@ -1,6 +1,12 @@
 Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
 Upstream-Name: nvidia-modprobe
 Source: https://download.nvidia.com/XFree86/nvidia-modprobe/
+Disclaimer:
+ This package is not part of the GNU/Linux Debian distribution. It is
+ provided in the contrib archive area as a convenience to Debian users.
+ The contents of this source package are freely licensed under the Expat
+ license, but it is only useful in combination with the proprietary
+ NVIDIA drivers in non-free.
 
 Files: *
 Copyright: Copyright (C) 2004-2017 NVIDIA Corporation
diff --git a/debian/patches/series b/debian/patches/series
new file mode 100644
index 000..57623ce
--- /dev/null
+++ b/debian/patches/series
@@ -0,0 +1 @@
+setuid.patch
diff --git a/debian/patches/setuid.patch b/debian/patches/setuid.patch
new file mode 100644
index 000..106df55
--- /dev/null
+++ b/debian/patches/setuid.patch
@@ -0,0 +1,27 @@
+Author: Hiromasa YOSHIMOTO 
+Description: use setuid(0) to preserve privileges over shell invocations
+ Fixing bug https://bugs.debian.org/734869 dash recently started to drop
+ privileges if euid != uid. (Bash has been doing that for a long time
+ already, but is usually not used for /bin/sh.)
+ The Debian modprobe configuration /etc/modprobe.d/nvidia.conf uses install
+ commands that require forking a shell from within modprobe to (recursively)
+ run further modprobe commands. If the shell drops privileges in setuid
+ contexts, the inner modprobe commands are run unprivileged, failing to load
+ the modules.
+ Run setuid(0) before forking modprobe to preserve privileges through to the
+ inner modprobe commands.
+Bug-Debian: https://bugs.debian.org/888952
+
+--- nvidia-modprobe-384.111.orig/modprobe-utils/nvidia-modprobe-utils.c
 nvidia-modprobe-384.111/modprobe-utils/nvidia-modprobe-utils.c
+@@ -374,6 +374,10 @@ static int modprobe_helper(const int pri
+  */
+ silence_current_process();
+ 
++/* Workaround for debian's /etc/modprobe.d/nvidia.conf configuration.
++ * See Bug#888952 for details */
++setuid(0);
++
+ execle(modprobe_path, "modprobe",
+module_name, NULL, envp);
+ 
diff --git a/debian/source/lintian-overrides b/debian/source/lintian-overrides
index 

Bug#891381: vt100 line-drawing is a bad idea here

[Antoine Beaupré]

On 2018-02-27 08:20:14, Paul Wise wrote:
> On Mon, 2018-02-26 at 09:22 -0500, Antoine Beaupré wrote:
>
>> I am not sure i see the point of defaulting to "no colors" for !isatty.
>
> If I redirect output to a file and then load that in my text editor
> then I'm going to get icky terminal escape sequences in it.
>
> Personally I don't consider this bug fixed until colours are gated on
> isatty by default. People who want to pipe colours around can use
> --color or pipetty (from colorized-logs).

Why can't you use --no-colors here?

-- 
If it's important for you, you'll find a way.
If it's not, you'll find an excuse.
- Unknown

Bug#891543: python-daemon: python3?-daemon should not depend on python3?-docutils

[Ben Finney]

Control: tags -1 + confirmed
Control: severity -1 minor

On 26-Feb-2018, Benjamin Drung wrote:
> python-daemon depend on python-docutils and python3-daemon depends
> on python3-docutils, but docutils is only needed for building the
> package and not for the runtime. Upstream committed [1] to partially
> address the unneeded depenency.

(For reference, the bug addressed by the upstream change is to work
around a Setuptools bug: it treats ‘setup_requires’ as build-time
*and* install-time dependencies.)

This is a minor packaging bug; I think it does not affect the
library's run-time behaviour, is that right?

> Please just drop docutils from setup.py.

You mean, patch the upstream build script for the Debian package?

-- 
 \ “I object to doing things that computers can do.” —Olin Shivers |
  `\   |
_o__)  |
Ben Finney 


signature.asc
Description: PGP signature

Bug#891570: SSL connect attempt failed error:141A90B5:SSL routines:ssl_cipher_list_to_bytes:no ciphers available

[積丹尼 Dan Jacobson]

WWW::Mechanize: 500 Can't connect to mbasic.facebook.com:443...

Bug#891601: ITP: apriltags -- AprilTags Visual Fiducial System

[Dima Kogan]

Package: wnpp
Owner: Dima Kogan 
Severity: wishlist

* Package name: apriltags
  Version : 0.9.8
  Upstream Author : Edwin Olson 
* URL or Web page : https://april.eecs.umich.edu/software/apriltag.html
* License : BSD
  Description : AprilTags Visual Fiducial System

Bug#891558: Checking in progress on ... message improvement ideas

[積丹尼 Dan Jacobson]

> "TT" == Theodore Ts'o  writes:

TT> I have no idea where this message is coming from, but I don't think
TT> it's e2fsprogs.  Can you say more about where you saw it and what was
TT> running at the time?

Hmm, found in syslog:
systemd-fsck[287]: /dev/sda7 has been mounted 21 times without being checked, 
check forced.

Bug#891600: Document how to always get no matter how deep

[積丹尼 Dan Jacobson]

Package: markdown
Version: 1.0.2~b8-3
Severity: wishlist
File: /usr/share/doc/markdown/syntax
X-Debugs-Cc: comme...@daringfireball.net

Yes, even if in https://daringfireball.net/projects/markdown/syntax

```

*   Bird

*   Magic

```
will turn into:
```

Bird
Magic

```
however please document somewhere that the only way to get deeper ``s like
```
  

  A
  

  B

  


  C
  

  D

  

  
```
is to use something like
```
*   A

*   $

B

*   C

*   $

D


```
(and run through
```
tr -d $|markdown
```
stripping the $ I added here so one can see the trailing blanks needed!

Bug#891381: vt100 line-drawing is a bad idea here

[Paul Wise]

On Mon, 2018-02-26 at 09:22 -0500, Antoine Beaupré wrote:

> I am not sure i see the point of defaulting to "no colors" for !isatty.

If I redirect output to a file and then load that in my text editor
then I'm going to get icky terminal escape sequences in it.

Personally I don't consider this bug fixed until colours are gated on
isatty by default. People who want to pipe colours around can use
--color or pipetty (from colorized-logs).

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#891599: gdm3: Greeter doesn't allow control of network-manager connections even when member of netdev group

[Matthew Gabeler-Lee]

Package: gdm3
Version: 3.22.3-3+deb9u1
Severity: normal

Based on the policy-kit settings, I would expect that adding the Debian-gdm
user to the netdev group (and restarting gdm3 or rebooting) to allow me to
control network connections from the greeter (AKA login screen).  For
example, if a VPN needs to be connected first to authenticate logins
(LDAP/AD).  But this doesn't work.  The greeter seems to always show the
network connection information as read-only.

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

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

Versions of packages gdm3 depends on:
ii  accountsservice   0.6.43-1
ii  adduser   3.115
ii  dconf-cli 0.26.0-2+b1
ii  dconf-gsettings-backend   0.26.0-2+b1
ii  debconf [debconf-2.0] 1.5.61
ii  gir1.2-gdm-1.03.22.3-3+deb9u1
ii  gnome-session [x-session-manager] 3.22.3-1
ii  gnome-session-bin 3.22.3-1
ii  gnome-settings-daemon 3.22.2-2+deb9u2
ii  gnome-shell   3.22.3-3
ii  gnome-terminal [x-terminal-emulator]  3.22.2-1
ii  gsettings-desktop-schemas 3.22.0-1
ii  libaccountsservice0   0.6.43-1
ii  libaudit1 1:2.6.7-2
ii  libc6 2.26-6
ii  libcanberra-gtk3-00.30-3
ii  libcanberra0  0.30-3
ii  libgdk-pixbuf2.0-02.36.5-2+deb9u2
ii  libgdm1   3.22.3-3+deb9u1
ii  libglib2.0-0  2.50.3-2
ii  libglib2.0-bin2.50.3-2
ii  libgtk-3-03.22.11-1
ii  libkeyutils1  1.5.9-9
ii  libpam-modules1.1.8-3.6
ii  libpam-runtime1.1.8-3.6
ii  libpam-systemd232-25+deb9u1
ii  libpam0g  1.1.8-3.6
ii  librsvg2-common   2.40.16-1+b1
ii  libselinux1   2.6-3+b3
ii  libsystemd0   232-25+deb9u1
ii  libwrap0  7.6.q-26
ii  libx11-6  2:1.6.4-3
ii  libxau6   1:1.0.8-1
ii  libxcb1   1.12-1
ii  libxdmcp6 1:1.1.2-3
ii  lsb-base  9.20161125
ii  lxterminal [x-terminal-emulator]  0.3.0-2
ii  metacity [x-window-manager]   1:3.22.1-1
ii  mutter [x-window-manager] 3.22.3-2
ii  policykit-1   0.105-18
ii  terminator [x-terminal-emulator]  1.90+bzr-1705-1
ii  tilix [x-terminal-emulator]   1.7.1-2
ii  ucf   3.0036
ii  wmaker [x-window-manager] 0.95.7-8
ii  x11-common1:7.7+19
ii  x11-xserver-utils 7.7+7+b1
ii  xfce4-terminal [x-terminal-emulator]  0.8.3-1
ii  xterm [x-terminal-emulator]   327-2

Versions of packages gdm3 recommends:
ii  at-spi2-core2.22.0-6+deb9u1
ii  desktop-base9.0.2+deb9u1
ii  x11-xkb-utils   7.7+3+b1
pn  xserver-xephyr  
ii  xserver-xorg1:7.7+19
ii  zenity  3.22.0-1+b1

Versions of packages gdm3 suggests:
pn  gnome-orca
ii  libpam-gnome-keyring  3.20.0-3

-- Configuration Files:
/etc/gdm3/Init/Default changed [not included]

-- debconf information:
* shared/default-x-display-manager: gdm3
  gdm3/daemon_name: /usr/sbin/gdm3

Bug#880554: [Pkg-xen-devel] Bug#880554: xen domu freezes with kernel linux-image-4.9.0-4-amd64

[Hans van Kranenburg]

On 02/26/2018 07:35 PM, Hans van Kranenburg wrote:
> On 02/26/2018 03:52 PM, Ian Jackson wrote:
>> Christian Schwamborn writes ("Re: Bug#880554: xen domu freezes with
kernel linux-image-4.9.0-4-amd64"):
>>> I can try, but the only system I can really test this is a productive
>>> system, as this 'reliable' shows this issue (and I don't want to crash
>>> it on purpose on a regular basis). Since I set gnttab_max_frame to a
>>> higher value it runs smooth. If you're confident this will work I can
>>> try this in the eventing, when all users logged off.
>>
>> Thanks.  I understand your reluctance.  I don't want to mislead you.
>> I think the odds of it working are probably ~75%.
>>
>> Unless you want to tolerate that risk, it might be better for us to
>> try to come up with a better way to test it.
>
> I can try this.
>
> I can run a dom0 with Xen 4.8 and 4.9 domU, I already have the xen-diag
> for it (so confirmed the patch in this bug report builds ok, we should
> include it for stretch, it's really useful).
>
> I think it's mainly trying to get a domU running with various
> combinations of domU kernel, number of disks and vcpus, and then look at
> the output of xen-diag.
Ok, I spent some time trying things.

Xen: 4.8.3+comet2+shim4.10.0+comet3-1+deb9u4.1
dom0 kernel 4.9.65-3+deb9u2
domU (PV) kernel 4.9.82-1+deb9u2

Observation so far: nr_frames increases as soon as a combination of
disk+vcpu has actually been doing disk activity, and then never decreases.

I ended up with a 64-vcpu domU with additional 10 1GiB disks (xvdc,
xvdd, etc).

I created ext4 fs on the disks and mounted them.

I used fio to throw some IO at the disk, trying to hit as many
combinations of vcpu and disk.

[things]
rw=randwrite
rwmixread=75
size=8M
directory=/mnt/xvdBLAH
ioengine=libaio
direct=1
iodepth=16
numjobs=64

with BLAH replaced by c, d, e, f etc...

-# rm */things*; for i in c d e f g h i j k l; do fio fio-xvd$i; done

-# while true; do /usr/lib/xen-4.8/bin/xen-diag gnttab_query_size 2;
sleep 10; done
domid=2: nr_frames=6, max_nr_frames=128
domid=2: nr_frames=7, max_nr_frames=128
domid=2: nr_frames=7, max_nr_frames=128
domid=2: nr_frames=10, max_nr_frames=128
domid=2: nr_frames=10, max_nr_frames=128
domid=2: nr_frames=11, max_nr_frames=128
domid=2: nr_frames=13, max_nr_frames=128
domid=2: nr_frames=14, max_nr_frames=128
domid=2: nr_frames=15, max_nr_frames=128
domid=2: nr_frames=16, max_nr_frames=128
domid=2: nr_frames=18, max_nr_frames=128
domid=2: nr_frames=18, max_nr_frames=128
domid=2: nr_frames=19, max_nr_frames=128
domid=2: nr_frames=21, max_nr_frames=128
domid=2: nr_frames=21, max_nr_frames=128
domid=2: nr_frames=23, max_nr_frames=128
domid=2: nr_frames=24, max_nr_frames=128
domid=2: nr_frames=24, max_nr_frames=128
domid=2: nr_frames=24, max_nr_frames=128
domid=2: nr_frames=24, max_nr_frames=128

So I can push it up to about 24 when doing this.

-# grep . /sys/module/xen_blkback/parameters/*
/sys/module/xen_blkback/parameters/log_stats:0
/sys/module/xen_blkback/parameters/max_buffer_pages:1024
/sys/module/xen_blkback/parameters/max_persistent_grants:1056
/sys/module/xen_blkback/parameters/max_queues:4
/sys/module/xen_blkback/parameters/max_ring_page_order:4

Now, I rebooted my test domo and put the modprobe file in place.
(Note: the filename has to end in .conf)!!

-# grep . /sys/module/xen_blkback/parameters/*
/sys/module/xen_blkback/parameters/log_stats:0
/sys/module/xen_blkback/parameters/max_buffer_pages:1024
/sys/module/xen_blkback/parameters/max_persistent_grants:1056
/sys/module/xen_blkback/parameters/max_queues:1
/sys/module/xen_blkback/parameters/max_ring_page_order:0

After doing the same tests, the result ends up being exactly 24 again.
So, the modprobe settings don't seem to do anything.

-# tree /sys/block/xvda/mq
/sys/block/xvda/mq
└── 0
├── active
├── cpu0
│   ├── completed
│   ├── dispatched
│   ├── merged
│   └── rq_list
├── cpu1
│   ├── completed
│   ├── dispatched
│   ├── merged
│   └── rq_list
   [...]
├── cpu63
│   ├── completed
│   ├── dispatched
│   ├── merged
│   └── rq_list
   [...]
├── cpu_list
├── dispatched
├── io_poll
├── pending
├── queued
├── run
└── tags

65 directories, 264 files

Mwooop mwooop mwoop mwo (failure trombone).

It obviously didn't involve network traffic yet. And, all is stretch
kernels etc, which are reported to already be problematic.

But, the main thing I wanted to test is if the change would result in a
much lower total amount of grants, which is not the case.

So, anyone a better idea, or should we just add some clear documentation
for the max frames setting in the grub config example?

Hans

Bug#891598: [zfs-linux] Linux 3.14+ compatibility: free memory calculation

[Antonio Russo]

Package: zfs-linux
Version: 0.7.5-1
Severity: normal

--- Please enter the report below this line. ---
A longstanding incorrect calculation of free memory, since
Linux 3.14, has been fixed in upstream master.

I have submitted a PR to upstream that re-bases the patch
onto the 0.7.6 stable release [1].

Additionally, the fix introduces a new file needed during
module build, scripts/enum-extract.pl, which must therefore
be packaged with the dkms source. All of this has included
in the attached patch, and on [2] in pulls/proposed-0.7.6.

That branch also includes a decompression out of bounds
check, as well as the 0.7.6 release import.

[1] https://github.com/zfsonlinux/zfs/pull/7238
[2] https://github.com/aerusso/zfs
commit 87d8977aa53192a647c8bdc99e14a6ab6dfd5560
Author: Antonio Russo 
Date:   Sun Feb 25 21:18:10 2018 -0500

Linux 3.14 compat: fix free memory calculation

diff --git a/debian/patches/4-compat-fix_free_memory_calculation.patch b/debian/patches/4-compat-fix_free_memory_calculation.patch
new file mode 100644
index ..4cadf854
--- /dev/null
+++ b/debian/patches/4-compat-fix_free_memory_calculation.patch
@@ -0,0 +1,425 @@
+commit 697dd9746d93740d81c4f5a722b03aa0d9344b0b
+Author: chrisrd 
+Date:   Sat Feb 24 03:50:06 2018 +1100
+
+Fix free memory calculation on v3.14+
+
+Provide infrastructure to auto-configure to enum and API changes in the
+global page stats used for our free memory calculations.
+
+arc_free_memory has been broken since an API change in Linux v3.14:
+
+2016-07-28 v4.8 599d0c95 mm, vmscan: move LRU lists to node
+2016-07-28 v4.8 75ef7184 mm, vmstat: add infrastructure for per-node
+  vmstats
+
+These commits moved some of global_page_state() into
+global_node_page_state(). The API change was particularly egregious as,
+instead of breaking the old code, it silently did the wrong thing and we
+continued using global_page_state() where we should have been using
+global_node_page_state(), thus indexing into the wrong array via
+NR_SLAB_RECLAIMABLE et al.
+
+There have been further API changes along the way:
+
+2017-07-06 v4.13 385386cf mm: vmstat: move slab statistics from zone to
+  node counters
+2017-09-06 v4.14 c41f012a mm: rename global_page_state to
+  global_zone_page_state
+
+...and various (incomplete, as it turns out) attempts to accomodate
+these changes in ZoL:
+
+2017-08-24 2209e409 Linux 4.8+ compatibility fix for vm stats
+2017-09-16 787acae0 Linux 3.14 compat: IO acct, global_page_state, etc
+2017-09-19 661907e6 Linux 4.14 compat: IO acct, global_page_state, etc
+
+The config infrastructure provided here resolves these issues going back
+to the original API change in v3.14 and is robust against further Linux
+changes in this area.
+
+Reviewed-by: Giuseppe Di Natale 
+Reviewed-by: Brian Behlendorf 
+Reviewed-by: George Melikov 
+Signed-off-by: Chris Dunlop 
+Closes #7170
+
+diff --git a/config/kernel-global_page_state.m4 b/config/kernel-global_page_state.m4
+new file mode 100644
+index 0..f4a40011f
+--- /dev/null
 b/config/kernel-global_page_state.m4
+@@ -0,0 +1,109 @@
++dnl #
++dnl # 4.8 API change
++dnl #
++dnl # 75ef71840539 mm, vmstat: add infrastructure for per-node vmstats
++dnl # 599d0c954f91 mm, vmscan: move LRU lists to node
++dnl #
++AC_DEFUN([ZFS_AC_KERNEL_GLOBAL_NODE_PAGE_STATE], [
++	AC_MSG_CHECKING([whether global_node_page_state() exists])
++	ZFS_LINUX_TRY_COMPILE([
++		#include 
++		#include 
++	],[
++		(void) global_node_page_state(0);
++	],[
++		AC_MSG_RESULT(yes)
++		AC_DEFINE(ZFS_GLOBAL_NODE_PAGE_STATE, 1, [global_node_page_state() exists])
++	],[
++		AC_MSG_RESULT(no)
++	])
++])
++
++dnl #
++dnl # 4.14 API change
++dnl #
++dnl # c41f012ade0b mm: rename global_page_state to global_zone_page_state
++dnl #
++AC_DEFUN([ZFS_AC_KERNEL_GLOBAL_ZONE_PAGE_STATE], [
++	AC_MSG_CHECKING([whether global_zone_page_state() exists])
++	ZFS_LINUX_TRY_COMPILE([
++		#include 
++		#include 
++	],[
++		(void) global_zone_page_state(0);
++	],[
++		AC_MSG_RESULT(yes)
++		AC_DEFINE(ZFS_GLOBAL_ZONE_PAGE_STATE, 1, [global_zone_page_state() exists])
++	],[
++		AC_MSG_RESULT(no)
++	])
++])
++
++dnl #
++dnl # Create a define and autoconf variable for an enum member
++dnl #
++AC_DEFUN([ZFS_AC_KERNEL_ENUM_MEMBER], [
++	AC_MSG_CHECKING([whether enum $2 contains $1])
++	AS_IF([AC_TRY_COMMAND("${srcdir}/scripts/enum-extract.pl" "$2" "$3" | egrep -qx $1)],[
++		AC_MSG_RESULT([yes])
++		AC_DEFINE(m4_join([_], [ZFS_ENUM], m4_toupper($2), $1), 1, [enum $2 contains $1])
++		m4_join([_], [ZFS_ENUM], m4_toupper($2), $1)=1
++	],[
++		AC_MSG_RESULT([no])
++	])
++])
++
++dnl #
++dnl # Sanity check helpers
++dnl #
++AC_DEFUN([ZFS_AC_KERNEL_GLOBAL_PAGE_STATE_ENUM_ERROR],[

Bug#891422: tracker.debian.org: link to cppcheck results for packages

[Paul Wise]

On Mon, 2018-02-26 at 22:00 +0100, Daniel Marjamäki wrote:

> I analyze the debian source packages I find here:
> 
> ftp://ftp.se.debian.org/debian/pool/main/

Which suite are you analysing?

To start with I think unstable/sid would be the best option,
since that is the suite that most development happens in.

> If you have an alternative location that you would prefer let me know.

http://deb.debian.org/ would be a better location, since it is based on
a set of CDN networks and is more likely to be up to date and fast.

> Maybe there is some better location with "bleeding edge" source code
> for instance.

New versions of packages are briefly available here before they reach
the main archive and pass through the mirror network, additionally
analysing that would allow you to have cppcheck results earlier.

https://incoming.debian.org/

> Imagine I analyze these packages:
> ftp://ftp.se.debian.org/debian/pool/main/a/a2jmidid/a2jmidid_8~dfsg0.orig.tar.bz2
> ftp://ftp.se.debian.org/debian/pool/main/a/a2ps/a2ps_4.14.orig.tar.gz

These are the upstream tarballs, without any Debian patches applied, so
you might get false positives if the Debian patches fix cppcheck issues.

I don't know what constraints you have, but to unpack Debian source
packages and apply patches, dpkg-source from dpkg-dev should be used.

> How about some format like this:
> 
> [
>   { "package" : "a2jmidid", "results" :
> "http://www.cppcheck.net/devinfo/daca2/a2jmidid.txt; },
>   { "package" : "a2ps", "results" :
> "http://www.cppcheck.net/devinfo/daca2/a2ps.txt; }
> ]

That looks good to me.

> I am not against that additional output formats are added.
> 
> However I would like to understand the reason for doing it. I have the
> impression that firehose has some builtin cppcheck-import function.

The firehose Python module has support for transforming the cppcheck
XML format into the Firehose format. It would be more efficient for
consumers of the Firehose format to be able to directly consume the
output of cppcheck rather than having to pass through a converter.
Basically, the firehose Python module is a workaround for the fact
that each static analysis tool invents different output formats.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#887403: Acknowledgement (RFS: budgie-extras/0.4.0-1)

[foss.freedom]

Hi Herbert,

  no I wasn't aware of that lintian - I ran lintian -i -I --pedantic
on my latest unstable but it didn't highlight that.  Odd.

However I have now corrected that in debian/rules.  I have taken also
the opportunity to refresh the source & build with the very latest
fixes made by the team made in the last month.

https://mentors.debian.net/debian/pool/main/b/budgie-extras/budgie-extras_0.4.2-1.dsc

The changelog has been adjusted slightly to reflect this
DEB_BUILD_OPTIONS addition:

  * New upstream release
  * Packaging Changes:
- debian/control and debian/compat: update to v11
- debian/control: Bump Standards-Version - no changes required
- debian/control: new binary packages budgie-rotation-lock-applet,
  budgie-clockworks-applet,
  budgie-dropby-applet
- debian/copyright: 2018 year updates
- debian/rules remove ninja make rules since debhelper can deal
  with meson builds
- debian/rules check DEB_BUILD_OPTIONS for autotest
- remove not needed debian/files
- signing key; move and rename to debian/upstream


thanks

David

On 25 February 2018 at 14:46, Herbert Fortes  wrote:
> Em 27-01-2018 14:06, foss.freedom escreveu:
>> The team has completed a minor release with lots of useful bug-fixes.
>>
>> These are summarised in the source ChangeLog file
>>
>> dget -x 
>> https://mentors.debian.net/debian/pool/main/b/budgie-extras/budgie-extras_0.4.1-1.dsc
>>
>> The debian/changelog I have just changed the package version info -
>> everything else is the same as originally detailed.
>>
>>
>
> Are you aware about this lintian?
>
>
> I: override_dh_auto_test-does-not-check-DEB_BUILD_OPTIONS
> N:
> N:   The debian/rules file for this package has an override_dh_auto_test
> N:   target that does not appear to check DEB_BUILD_OPTIONS against
> N:   nocheck.
> N:
> N:   As this check is not automatically performed by debhelper(1), the
> N:   specified testsuite is run regardless of another maintainer using the
> N:   nocheck build profile.
> N:
> N:   Please add a check such as:
> N:
> N:override_dh_auto_test:
> N:ifeq (,$(filter nocheck,$(DEB_BUILD_OPTIONS)))
> N:./run-upstream-testsuite
> N:endif
>
> It is a:
>
> N:   Severity: wishlist, Certainty: wild-guess
>
> Let me know so I can do the upload.
>
>
>
> Regards,
> Herbert

Bug#874003: Also affected on uptodate sid

[Mikko Rapeli]

On Tue, Feb 27, 2018 at 12:49:41AM +0200, Mikko Rapeli wrote:
> Testing changes to desktop files shows that exo-file-manager.desktop
> is to blame for this behavior. It does correctly set OnlyShowIn=XFCE; so
> I don't get why it gets used in a Gnome session:
> 
> $ cat /usr/share/applications/exo-file-manager.desktop
> [Desktop Entry]
> Version=1.0
> Type=Application
> Exec=exo-open --launch FileManager %u
> Icon=system-file-manager
> StartupNotify=true
> Terminal=false
> Categories=Utility;X-XFCE;X-Xfce-Toplevel;
> OnlyShowIn=XFCE;
> X-XFCE-MimeType=inode/directory;x-scheme-handler/trash;
> Name=File Manager
> ...
> 
> But moving this file away from /usr/share/applications
> fixes external application starting from nautilus:
> 
> # mv /usr/share/applications/exo-file-manager.desktop /root/

This isn't needed after all. I traced the likely root cause on my
Debian sid installation to ~/.local/share/applications/mimeapps.list
entry:

[Added Associations]
...
x-scheme-handler/file=exo-file-manager.desktop

Commenting out this line fixes the issues for me. I was previously
using Xfce and switched to Gnome so these entries might be really
old. I still don't get what made this break few days ago though.

-Mikko

Bug#797359: Reassign

[Alessandro Ghedini]

Control: owner -1 !

Since there hasn't been an update in over a year, I'm going to reassign this
ticket to myself. I already uploaded the initial version to NEW. For those
interested, here is the salsa repo:

  https://salsa.debian.org/debian/universal-ctags

Btw, I'm open to co-maintaining this with others if anyone wants to volunteer.

Cheers


signature.asc
Description: PGP signature

Bug#891493: numix-gtk-theme: Undocumented and very likely also broken Breaks against murrine-themes since 2.6.7-2

[Jeremy Bicha]

On Mon, Feb 26, 2018 at 2:53 AM, Axel Beckert  wrote:
> Since 2.6.7-2, numix-gtk-theme has a "Breaks: murrine-themes (<=
> 0.98.11)" without any mentioning (and especially without giving a
> reason) in debian/changelog.

Yes, I should have mentioned in the debian/changelog. I have uploaded
2.6.7-3 just now that does have some explanation in the
debian/changelog.

The Breaks is intentional. As the maintainer of numix-gtk-theme, I
feel that the Recommends on murrine-themes is wrong and I don't want
it to be installed just because someone installs Numix.

I am now the 3rd Debian Developer to object to the Murrine
Maintainer's dependency decision. (I did speak to him privately
earlier.) (And it's 4 if you count Steve Langasek acting in Ubuntu way
back in 2011.) In Debian, Maintainers have a lot of power over their
packages, maybe too much. I wish there were some lower level of
conflict resolution besides the Technical Committee. This issue may
end up needing to go there.

By the way, I also object to the other open wontfix Murrine bug (
https://bugs.debian.org/883411 ) but I can't workaround that. It's an
annoyance for, say, Debian MATE.

Thanks,
Jeremy Bicha

Bug#891505: glibc: Causes FTBFS of gcc-8 on hurd-i386

[Samuel Thibault]

Svante Signell, on lun. 26 févr. 2018 11:22:22 +0100, wrote:
> creates a defect gen-sysinfo.go file when libc0.3 >= 2.26-* is installed.

A lot of cleanup has happened, yes. The question is what actually made
gcc-8 to break. Just looking at the diff of the build logs, there's

  could not determine number of signals

which seems to come from ./src/libgo/mksigtab.sh, which uses the _NSIG
definition, which does have changed indeed, and the script doesn't seem
to properly deal with it: it discovers the

  #define _NSIG (__SIGRTMAX + 1)

redirection, but not the 

  #define __SIGRTMAX __SIGRTMIN

redirection

To confirm this hypothesis, you could modify your
/usr/include/i386-gnu/bits/signum-generic.h

from

  #define _NSIG  (__SIGRTMAX + 1)

to 

  #define _NSIG  32

and check that gcc-8 then builds fine.  It then means that
./src/libgo/mksigtab.sh needs to be improved to take into account the
abovementioned redirections, like it does between _NSIG and __SIGRTMAX

Samuel

Bug#874003: Also affected on uptodate sid

[Mikko Rapeli]

On Sun, Feb 25, 2018 at 02:35:28PM -0500, Jeremy Bicha wrote:
> I suggest looking into what xdg-utils does.

Looks like xdg-utils, or at least xdg-open is not the one to blame since
it is calling gio open:

$ sh -x  $( which xdg-open) video.mp4
+ check_common_commands video.mp4
+ [ 1 -gt 0 ]
+ parm=video.mp4
+ shift
+ [ 0 -gt 0 ]
+ [ -z  ]
+ unset XDG_UTILS_DEBUG_LEVEL
+ [ 0 -lt 1 ]
+ xdg_redirect_output= > /dev/null 2> /dev/null
+ [ xvideo.mp4 != x ]
+ url=
+ [ 1 -gt 0 ]
+ parm=video.mp4
+ shift
+ [ -n  ]
+ url=video.mp4
+ [ 0 -gt 0 ]
+ [ -z video.mp4 ]
+ detectDE
+ unset GREP_OPTIONS
+ [ -n GNOME ]
+ DE=gnome
+ [ xgnome = x ]
+ [ xgnome = x ]
+ [ xgnome = x ]
+ [ xgnome = xgnome ]
+ which gnome-default-applications-properties
+ DE=gnome3
+ [ -f /run/user/1000/flatpak-info ]
+ [ xgnome3 = x ]
+ DEBUG 2 Selected DE gnome3
+ [ -z  ]
+ return 0
+ open_gnome3 video.mp4
+ gio help open
+ gio open video.mp4
+ [ 0 -eq 0 ]
+ exit_success
+ [ 0 -gt 0 ]
+ exit 0

** (exo-helper-1:20332): WARNING **: Could not open X display
Gtk-Message: GtkDialog mapped without a transient parent. This is discouraged.

My mime setup for video files is mplayer and that seems to correctly there:

$ xdg-mime query default video/mp4
userapp-mplayer-9GFM9U.desktop

Testing changes to desktop files shows that exo-file-manager.desktop
is to blame for this behavior. It does correctly set OnlyShowIn=XFCE; so
I don't get why it gets used in a Gnome session:

$ cat /usr/share/applications/exo-file-manager.desktop
[Desktop Entry]
Version=1.0
Type=Application
Exec=exo-open --launch FileManager %u
Icon=system-file-manager
StartupNotify=true
Terminal=false
Categories=Utility;X-XFCE;X-Xfce-Toplevel;
OnlyShowIn=XFCE;
X-XFCE-MimeType=inode/directory;x-scheme-handler/trash;
Name=File Manager
...

But moving this file away from /usr/share/applications
fixes external application starting from nautilus:

# mv /usr/share/applications/exo-file-manager.desktop /root/

-Mikko

Bug#891555: Detect and warn about debhelper >= 11 instead of 11~ b-d

[Thomas Goirand]

On 02/26/2018 10:02 PM, Niels Thykier wrote:
> Thomas Goirand:
>> [...]
>>
>> And then debhelper 12 is released, people start to use it, and guess
>> what happens... :)
>>
> 
> I am prototyping an alternative in debhelper that may make this issue
> obsolete.  At the moment (since 11.1.5) you can use:
> 
>  Build-Depends: debhelper-compat (= 11)
> 
> as a replacement for:
> 
>  Build-Depends: debhelper (>= 11~)
>  and d/compat set to 11.

Oh, great improvement. I always thought that debian/compat file was kind
of too much, just to express the debhelper version... :)

Thanks for this,

Thomas Goirand (zigo)

Bug#891558: Checking in progress on ... message improvement ideas

[Theodore Ts'o]

On Tue, Feb 27, 2018 at 12:35:36AM +0800, 積丹尼 Dan Jacobson wrote:
> Package: e2fsprogs
> Version: 1.43.9-2
> Severity: wishlist
> 
> I saw a message,
> > Checking in progress on 1 disk.

I have no idea where this message is coming from, but I don't think
it's e2fsprogs.  Can you say more about where you saw it and what was
running at the time?

- Ted

Bug#889001: stretch-pu: package publicsuffix/20180218.2049-0+deb9u1

[Daniel Kahn Gillmor]

Control: retitle 889001: stretch-pu: package publicsuffix/20180218.2049-0+deb9u1

Thanks, this is now uploaded.

--dkg

PS and as luck would have it, the PSL has changed again minorly in the
meantime (to add mozilla-iot.org for the Mozilla IOT initiative
described at https://iot.mozilla.org) i'll upload the new changes to
unstable, but i do wonder what the stable release managers think should
be our cadence for packages like this.

Bug#829361: clang-x.y-doc: Fix the lintian error 'privacy-breach-uses-embedded-file' [was: Re: Processed: affects 829361]

[Sylvestre Ledru]

Le 26/02/2018 à 22:51, Nicholas D Steeves a écrit :
> Hi Sylvestre,
>
> On Sun, Feb 11, 2018 at 09:32:17AM +0100, Sylvestre Ledru wrote:
>> Le 11/02/2018 à 03:17, Nicholas D Steeves a écrit :
>>> On Sat, Feb 10, 2018 at 09:42:29AM +0100, Sylvestre Ledru wrote:
 This is caused by a recent change in gold I think.

 Just add a ; XFAIL: * at in the test to silent it.

 BTW, in the future, please don't attach the full build log:
 We just need the error message.


 S


>>> Thank you for the tip!  With the two attached patches I'm able to
>>> continue working towards solving this bug. (really just implementing
>>> your suggestion, plus a patch refresh)
>>>
>>> Oh, and I xzipped them to try to atone for sending uncompressed build
>>> logs ;-) I'll send only what I suspect are the relevant portions
>>> (errors) in the future.
>> Thanks but they were already merged upstream...
>>
>> Sylvestre
> I've been able to solve this by patching various Doxyfile, conf.py,
> and doxygen.cfg.in.  Before I did that I also:
>
> -html_static_path = []
> +html_static_path = ['_static']
>
> for the affected sections.
>
> Do you approve of this approach and should I work on patching rules to
> not fail with this new configuration or would you prefer another
> approach?

Sounds good. What are you concerns about this solution?

Thanks

S

Bug#891182: RFS: ssh-tools/1.4-1

[Sven Wick]

Ah well, after some fiddling lintian stopped complaining...


On 02/26/2018 08:20 PM, Andrey Rahmatullin wrote:

On Mon, Feb 26, 2018 at 07:23:35PM +0100, Sven Wick wrote:

Yeah, I did. But when I tried to get rid of the warnings
it complained about the whole control file.

Didn't find this "empty paragraph"

Description: collection of various tools using ssh
  .


and how to get rid of the "unindented list" warning

Have you read the tag description? You aldo need to read
https://www.debian.org/doc/debian-policy/#s-f-description

Bug#891484: stretch-pu: package vagrant/1.9.1+dfsg-1+deb9u1

[Antonio Terceiro]

On Mon, Feb 26, 2018 at 08:42:56PM +, Adam D. Barratt wrote:
> Control: tags -1 + moreinfo
> 
> On Sun, 2018-02-25 at 22:10 -0300, Antonio Terceiro wrote:
> > The platform from where vagrant downloads images has been
> > discontinued
> > and we need to switch the default download location plus
> > documentation,
> > usage messages etc to match the new platform. Without this update,
> > vagrant is pretty useless.
> > 
> 
> So far as I can tell, this issue also affects the version of vagrant in
> unstable and has not yet been fixed there. Assuming that's correct, the
> bug will need resolving in unstable first.

Ah, I thought I adjusted the bug metadata yesterday, but it seems I
didn't.

No, unstable is not affected. This has been done upstream for a while,
this update is a backport of the change -- which we already have in the
version in unstable -- to stable.


signature.asc
Description: PGP signature

Bug#891597: tomboy FTBFS: No rule to make target '.config.in', needed by '../bin/Tomboy.exe.config'.

[Adrian Bunk]

Source: tomboy
Version: 1.14.1-4
Severity: serious
Tags: buster sid

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

...
make[4]: *** No rule to make target '.config.in', needed by 
'../bin/Tomboy.exe.config'.  Stop.
make[4]: Leaving directory '/build/1st/tomboy-1.14.1/Tomboy'
make[3]: *** [Makefile:694: all-recursive] Error 1

Bug#829361: clang-x.y-doc: Fix the lintian error 'privacy-breach-uses-embedded-file' [was: Re: Processed: affects 829361]

[Nicholas D Steeves]

Hi Sylvestre,

On Sun, Feb 11, 2018 at 09:32:17AM +0100, Sylvestre Ledru wrote:
> 
> Le 11/02/2018 à 03:17, Nicholas D Steeves a écrit :
> > On Sat, Feb 10, 2018 at 09:42:29AM +0100, Sylvestre Ledru wrote:
> >> This is caused by a recent change in gold I think.
> >>
> >> Just add a ; XFAIL: * at in the test to silent it.
> >>
> >> BTW, in the future, please don't attach the full build log:
> >> We just need the error message.
> >>
> >>
> >> S
> >>
> >>
> > Thank you for the tip!  With the two attached patches I'm able to
> > continue working towards solving this bug. (really just implementing
> > your suggestion, plus a patch refresh)
> >
> > Oh, and I xzipped them to try to atone for sending uncompressed build
> > logs ;-) I'll send only what I suspect are the relevant portions
> > (errors) in the future.
> 
> Thanks but they were already merged upstream...
> 
> Sylvestre

I've been able to solve this by patching various Doxyfile, conf.py,
and doxygen.cfg.in.  Before I did that I also:

-html_static_path = []
+html_static_path = ['_static']

for the affected sections.

Do you approve of this approach and should I work on patching rules to
not fail with this new configuration or would you prefer another
approach?

Cheers,
Nicholas


signature.asc
Description: PGP signature

Bug#890547: Bug localization

[Patrick Häcker]

Hi,

calling partx with the libblkid debug environment variable like
> env LIBBLKID_DEBUG=all partx --show /dev/sda
results in the following:

6729: libblkid: INIT: library debug mask: 0x 
6729: libblkid: INIT: library version: 2.31.1 [19-Dec-2017] 
Available "LIBBLKID_DEBUG=[,...]|" debug masks: 
  all  [0x] : info about all subsystems 
  cache[0x0004] : blkid tags cache 
  config   [0x0008] : config file utils 
  dev  [0x0010] : device utils 
  devname  [0x0020] : /proc/partitions evaluation 
  devno[0x0040] : conversions to device name 
  evaluate [0x0080] : tags resolving 
  help [0x0001] : this help 
  lowprobe [0x0100] : superblock/raids/partitions probing 
  buffer   [0x2000] : low-probing buffers 
  probe[0x0200] : devices verification 
  read [0x0400] : cache parsing 
  save [0x0800] : cache writing 
  tag  [0x1000] : tags utils 
6729: libblkid: LOWPROBE: allocate a new probe 0x556a99d8e2c0 
6729: libblkid: LOWPROBE: zeroize wiper 
6729: libblkid: LOWPROBE: ready for low-probing, offset=0, size=128035676160 
6729: libblkid: LOWPROBE: whole-disk: YES, regfile: NO 
6729: libblkid: LOWPROBE: partlist reset 
6729: libblkid: LOWPROBE: parts: initialized partitions list (0x556a99d8e3d0, 
size=0) 
6729: libblkid: LOWPROBE: --> starting probing loop [PARTS idx=-1] 
6729: libblkid: LOWPROBE:   read 0x556a99d8e438: off=0 len=1024 
6729: libblkid:   BUFFER:   reuse 0x556a99d8e438: off=0 len=1024 (for 
off=0 len=1024) 
6729: libblkid:   BUFFER:   reuse 0x556a99d8e438: off=0 len=1024 (for 
off=0 len=1024) 
6729: libblkid:   BUFFER:   reuse 0x556a99d8e438: off=0 len=1024 (for 
off=0 len=1024) 
6729: libblkid: LOWPROBE:   magic sboff=510, kboff=0 
6729: libblkid: LOWPROBE: dos: ---> call probefunc() 
6729: libblkid:   BUFFER:   reuse 0x556a99d8e438: off=0 len=1024 (for 
off=0 len=512) 
6729: libblkid:   BUFFER:   reuse 0x556a99d8e438: off=0 len=1024 (for 
off=0 len=1024) 
6729: libblkid:   BUFFER:   reuse 0x556a99d8e438: off=0 len=1024 (for 
off=0 len=1024) 
6729: libblkid:   BUFFER:   reuse 0x556a99d8e438: off=0 len=1024 (for 
off=0 len=1024) 
6729: libblkid:   BUFFER:   reuse 0x556a99d8e438: off=0 len=1024 (for 
off=0 len=1024) 
6729: libblkid:   BUFFER:   reuse 0x556a99d8e438: off=0 len=1024 (for 
off=0 len=1024) 
6729: libblkid:   BUFFER:   reuse 0x556a99d8e438: off=0 len=1024 (for 
off=0 len=1024) 
6729: libblkid:   BUFFER:   reuse 0x556a99d8e438: off=0 len=1024 (for 
off=0 len=1024) 
6729: libblkid: LOWPROBE:   magic sboff=0, kboff=0 
6729: libblkid:   BUFFER:   reuse 0x556a99d8e438: off=0 len=1024 (for 
off=0 len=512) 
6729: libblkid:   BUFFER:   reuse 0x556a99d8e438: off=0 len=1024 (for 
off=0 len=512) 
6729: libblkid: LOWPROBE: parts: create a new partition table (0x556a99d8e840, 
type=dos, offset=446) 
6729: libblkid: LOWPROBE: parts: add partition (0x556a99d8e8a0 start=2048, 
size=62734336, table=0x556a99d8e840) 
6729: libblkid: LOWPROBE: parts: add partition (0x556a99d8e9a0 start=62736384, 
size=141438976, table=0x556a99d8e840) 
6729: libblkid: LOWPROBE: parts: add partition (0x556a99d8eaa0 
start=204175360, size=45893632, table=0x556a99d8e840) 
6729: libblkid: LOWPROBE: parts: > solaris subprobe requested 
(parent=(nil)) 
6729: libblkid: LOWPROBE: partlist reset 
6729: libblkid: LOWPROBE: dos probefunc failed, rc -22 
6729: libblkid: LOWPROBE: dos: <--- (rc = -22) 
6729: libblkid: LOWPROBE: <-- leaving probing loop (failed=-22) [PARTS idx=3] 
6729: libblkid: LOWPROBE: partitions probe done [rc=-22] 
partx: /dev/sda: Partitionstabelle konnte nicht gelesen werden 
6729: libblkid:   BUFFER: Resetting probing buffers pr=0x556a99d8e2c0 
6729: libblkid:   BUFFER:  remove buffer: 0x556a99d8e438 [off=0, len=1024] 
6729: libblkid: LOWPROBE:  buffers summary: 1024 bytes by 1 read() calls 
6729: libblkid: LOWPROBE: free probe 0x556a99d8e2c0


There, the Solaris subprobe request fails (swap and Solaris partitions both 
seems to share the same partition type byte 0x82), which leads to the failing 
of partx.

The problem originates in dos.c:probe_dos_pt where
> p0 = mbr_get_partition(data, 0);
returns an array of length 4 with the second partition contains only 0 values 
as the partition is not used. Thus, the fourth partition (index 3) is a valid 
swap partition. However,
> ls = blkid_probe_get_partlist(pr);
returns an array of length 3 within ls->parts where only the non-empty 
partitions are listed and thus the swap partition is the third partition 
(index 2).

In the subtypes parsing block towards the end of the dos.c:probe_dos_pt 
function the code combines these logically non-aligned arrays with
> rc = blkid_partitions_do_subprobe(pr,
> blkid_partlist_get_partition(ls, i),
> dos_nested[n].id);
for i=3 which results in a NULL pointer from blkid_partlist_get_partition, 
which itself results into -EINVAL in blkid_partitions_do_subprobe as parent is 
NULL.

To be clear: The 

Bug#890878: RFS: company-irony

[Sean Whitton]

Hello,

On Mon, Feb 26 2018, Alberto Luaces wrote:

> I have refreshed those fields.  I have not still refreshed the
> changelog date in order to wait for more potential changes.

Thanks for fixing this.

I'm not in a position to properly review this package, unfortunately.
Sorry for suggesting in a previous mail that I was planning on doing
that.  Just wanted to get the Vcs-* fields fixed.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#871506: stretch update for hdf5

[Sebastiaan Couwenberg]

On 02/26/2018 10:23 PM, Adrian Bunk wrote:
> On Sun, Aug 13, 2017 at 05:51:08PM +, Debian Bug Tracking System wrote:
>> ...
>>  hdf5 (1.10.0-patch1+docs-4) unstable; urgency=medium
>>  .
>>* debian/rules: fix javahelper invocation (closes: #871506)
>> ...
> 
> Thanks a lot for fixing this bug for unstable.
> 
> It is still present in stretch, could you also fix it there?
> Alternatively, I can fix it for stretch if you don't object.

The stretch-pu was requested in #872642 and given a go-ahead.

It's just a matter of uploading or am I missing something?

Kind Regards,

Bas

Bug#891596: CVE-2018-7409

[Santiago R.R.]

Source: unixodbc
Version: 2.3.4-1.1
Severity: grave
Tags: security

Hi,

the following vulnerability was published for unixodbc.

CVE-2018-7409[0]:
| In unixODBC before 2.3.5, there is a buffer overflow in the
| unicode_to_ansi_copy() function in DriverManager/__info.c.

If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2018-7409
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-7409

Please adjust the affected versions in the BTS as needed.



signature.asc
Description: PGP signature

Bug#890878: RFS: company-irony

[Nicholas D Steeves]

Hi Alberto,

On Mon, Feb 26, 2018 at 04:30:02PM +0100, Alberto Luaces wrote:
> Sean Whitton writes:
> 
> > Hello,
> >
> > On Wed, Feb 21 2018, Alberto Luaces wrote:
> >
> >> Thanks, Sean.  It is now located at
> >>
> >> https://salsa.debian.org/aluaces-guest/company-irony
> >>
> >> I guess someone else has to clone it under the team project folders,
> >> so I created that personal repository first.
> >
> > You should be able to do it yourself... are you saying that you were
> > unable to create a repo under emacsen-team?  I just bumped your
> > permission level.
> >
> 
> Thanks for that.  Yes, I think salsa's default permissions for non-DDs
> are much more stricter than Alioth were.  Nevertheless, I have been able
> to create and populate the repository under the Team's group.
> 
> >
> > I don't want to upload the package with the wrong Vcs-* headers, so
> > let's get this fixed first.
> 
> I have refreshed those fields.  I have not still refreshed the changelog
> date in order to wait for more potential changes.
> 

Thank you for packaging company-irony!  I'd be happy to review your
packaging too; although, I can't sponsor the upload.  Please ping me
if you haven't received an update in the next 48h. ;-)

Cheers,
Nicholas


signature.asc
Description: PGP signature

Bug#891595: ITP: vnlog -- Tools to manipulate whitespace-separated ASCII logs

[Dima Kogan]

Package: wnpp
Owner: Dima Kogan 
Severity: wishlist

* Package name: vnlog
  Version : 1.2
  Upstream Author : Dima Kogan 
* URL or Web page : http://github.com/dkogan/vnlog
* License : LGPL2.1+
  Description : Tools to manipulate whitespace-separated ASCII logs

Bug#891592: tcc: -pthread no longer works

[Vincent Lefevre]

Control: tags -1 patch

On 2018-02-26 22:24:32 +0100, Vincent Lefevre wrote:
> I can read in the logs, just after the 0.9.27 release:
> 
> commit 3b27b3b1d1ae953f5ecb37f5bc95758499d66971
> Author: Michael Matz 
> Date:   2017-12-23 14:49:07 +0100
> 
> Fix -pthread in a different way

Corresponding patch attached.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
diff --git a/tcc.c b/tcc.c
index cd887d1..ee55ddd 100644
--- a/tcc.c
+++ b/tcc.c
@@ -298,8 +298,10 @@ redo:
 if (n > 1 && s->outfile)
 tcc_error("cannot specify output file with -c many files");
 } else {
-if (s->option_pthread)
+if (s->option_pthread) {
 tcc_set_options(s, "-lpthread");
+   n = s->nb_files;
+   }
 }
 
 if (s->do_bench)

Bug#891277: stretch-pu: package debian-edu-config/1.929+deb9u1

[mike . gabriel]

Hi,

On Monday, February 26, 2018, Adam D. Barratt wrote:
> Control: tags -1 + moreinfo
> 
> On Sat, 2018-02-24 at 02:25 +0100, Mike Gabriel wrote:
> [...]
> > 
> +  * Chromium: Pre-configure Chromium Webbrowser system-wide to auto-
> > detect the
> > +http proxy settings via WPAD (plus locking the proxy settings
> > dialog for
> > +users). (Closes: #891262).
> > 
> 
> The BTS metadata for this bug indicates that it also affects d-e-c in
> unstable - is that correct?

The issue is fixed in unstable and the bug was especially opened for 
documenting the issue in stable/stretch. I will update the bug's metadata 
tomorrow, once I have my notebook at hand.

Mike

-- 
Sent from my Fairphone 2 (running Sailfish OS)

Bug#887589: stretch-pu: package grilo-plugins/0.3.3-1

[Alberto Garcia]

Control: tags -1 - moreinfo

On Mon, Feb 26, 2018 at 08:55:51PM +, Adam D. Barratt wrote:

> > I would like to upload a new grilo-plugins package, which contains
> > a fix for https://bugs.debian.org/887469
> 
> The BTS metadata for that bug indicates that it affects the version
> of grilo-plugins in unstable and has not yet been resolved there -
> is that correct?

It's not correct, the version is sid is already patched.

Here's the proposed patch:

   
https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=887589;filename=grilo-plugins.diff;msg=5

Here's the source code of the version in sid:

   
https://sources.debian.org/src/grilo-plugins/0.3.5-2/src/lua-factory/sources/grl-radiofrance.lua/#L108

I'll update the metadata of the bug report.

Berto

Bug#891592: tcc: -pthread no longer works

[Vincent Lefevre]

Control: tags -1 upstream fixed-upstream

I can read in the logs, just after the 0.9.27 release:

commit 3b27b3b1d1ae953f5ecb37f5bc95758499d66971
Author: Michael Matz 
Date:   2017-12-23 14:49:07 +0100

Fix -pthread in a different way

commit 1b1b270f1e98d43f2cfc48403acc9ad826a11fca
Author: Michael Matz 
Date:   2017-12-23 14:46:27 +0100

Revert "Fix -pthread option handling"

This reverts commit 3f8225509b0b8af534ba0856b2aeb01a3310d826.
It fixes the linking case but introduces an ugly error with -c
about adding a library.  To fix both uses the old code structure is
better.

commit 3f8225509b0b8af534ba0856b2aeb01a3310d826
Author: Michael Matz 
Date:   2017-12-23 14:14:57 +0100

Fix -pthread option handling

adding -pthread confused option parsing as the number of file counting
came out wrong.  Simplify and fit it, can be handled purely within
option parsing, no need for a state flag.

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

Bug#871506: stretch update for hdf5

[Adrian Bunk]

On Sun, Aug 13, 2017 at 05:51:08PM +, Debian Bug Tracking System wrote:
>...
>  hdf5 (1.10.0-patch1+docs-4) unstable; urgency=medium
>  .
>* debian/rules: fix javahelper invocation (closes: #871506)
>...

Thanks a lot for fixing this bug for unstable.

It is still present in stretch, could you also fix it there?
Alternatively, I can fix it for stretch if you don't object.

Thanks
Adrian

-- 

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

Bug#891594: python-omniorb-dbg: broken symlinks: /usr/lib/python2.7/dist-packages/*_d.so -> *._d.so.4

[Andreas Beckmann]

Package: python-omniorb-dbg
Version: 4.2.2-0.1
Severity: normal
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package ships (or creates)
a broken symlink.

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

  /usr/lib/python2.7/dist-packages/_omnisslTPmodule_d.so -> 
_omnisslTPmodule._d.so.4
  /usr/lib/python2.7/dist-packages/_omnipymodule_d.so -> _omnipymodule._d.so.4
  /usr/lib/python2.7/dist-packages/_omnicodesetsmodule_d.so -> 
_omnicodesetsmodule._d.so.4
  /usr/lib/python2.7/dist-packages/_omniConnMgmtmodule_d.so -> 
_omniConnMgmtmodule._d.so.4

These targets seem to have weird names and do not exist anywhere
in the archive.


cheers,

Andreas


python-omniorb-dbg_4.2.2-0.1.log.gz
Description: application/gzip

Bug#890999: VirtualBox modules built against headers version 4.14.17-1 cannot be loaded by kernel version 4.14.13-1: Unknoe: Bug#890999: VirtualBox modules built against headers version 4.14.17-1 cann

[The Wanderer]

On 2018-02-26 at 14:55, Ben Hutchings wrote:

> On Mon, 2018-02-26 at 12:07 -0500, The Wanderer wrote:

>> If the automatic DKMS rebuild is expected to be able to produce
>> modules which can work with the running kernel, then clearly the
>> current behavior is buggy in some way, and should be addressed.
> 
> I don't think that's a reasonable expectation.  But I think DKMS
> should not automatically rebuild when installing a version of
> linux-headers- ABINAME that is newer than the currently *installed*
> version of linux- image-ABINAME.

It's possible that it actually doesn't. I believe the rebuild that
triggered the problem, for me, was triggered not by an upgrade of
linux-headers-ABINAME but by an upgrade of virtualbox-dkms; the
linux-headers-* package was upgraded much earlier, I believe on January
21st. (And IIRC the matching linux-image-* package was upgraded at the
same time.)

Off the top of my head, I don't see any potential way for DKMS to know
whether it's being asked to build against the sources of the running
kernel, vs. simply the sources of the currently installed kernel - and
I'm fairly sure that making the correct decision about whether or not to
rebuild when upgrading non-kernel packages would require knowing that.

>> On the other hand, if rebuilding the modules is expected to result
>> in modules which will not load against the running kernel,
>> shouldn't the DKMS machinery detect this condition and refrain from
>> automatically removing the existing (working) modules, at least
>> without an override request of some sort? Or at bare minimum, warn
>> that proceeding with the upgrade will result in functionality loss
>> until a reboot can be carried out?
> 
> If by "removing" you mean unloading a module from the kernel, I
> agree that it should not do this.

The idea of not unloading the module at upgrade time had in fact not
occurred to me. It's an interesting one, and if viable would seem to
offer a way out of the problem, but I'm not sure how viable it would be
in practice.

The upgrade process appears to consist basically of an uninstall
followed by an install. As such, all three of those scenarios would need
to be considered.


As far as I can tell without deeper investigation than I'm currently set
up for, what DKMS currently does at upgrade is to delete the old
modules, build the new ones, unload the old ones, and then load the new
ones. (I'm basing this on the output messages during the upgrade; I've
dug for the place where the underlying commands get run and the messages
get generated, but I haven't found anything I'm confident is the right
place.)

If there's a way to load the new module without unloading the other
first - if, e.g., the kernel will detect the collision and automatically
unload the old one after validating the new - it should be possible to
have DKMS do that, and skip the unload entirely. However, I don't
remember seeing any indication that such a way exists.

If there's a way to detect whether the newly-built modules will be
compatible with the currently-running kernel before trying to load them,
it might be possible to have DKMS skip the unload and subsequent load if
the latter would fail. Again, however, I don't know of any such way.

If neither of those things is possible, then the choices would seem to
be to either never unload (meaning that the old module would remain in
use until sysadmin intervention), or always unload (basically the
current situation).


What DKMS currently does at uninstall time I don't know. Clearly,
however, it would need to unload the module, as otherwise the uninstall
could not be considered complete. However, it's not clear to me that
there's any way for it to be able to tell a "permanent uninstall"
removal from an "upgrade" removal.


At install time, plainly DKMS needs to load the just-built module, but
again it's not clear to me that there's any way for it to tell a "clean
install" build from an "upgrade" build.


(That said, I've also seen my entire system hardlock when upgrading
VirtualBox packages while a VirtualBox VM was running, and it seems very
plausible that the lockup was because a module which was in use by
VirtualBox got automatically unloaded by DKMS. If it's possible to
design so as to avoid that automatic unload, without unacceptable
tradeoffs, that would make managing my upgrades easier.)

> If you mean replacing the module on disk, I disagree; it should
> build modules for the installed kernel version.

Certainly it should, and if there's no way to do that without removing
the existing modules from the disk, then that's what it should do -
possibly with a warning message or even an "are you sure?" prompt, but
still.

I had thought that the DKMS upgrade-time messages about "module was
ACTIVE" and "module version" and "original module" carried the
implication that it was possible to have DKMS managing multiple versions
of a given module for a given kernel at once, but digging deeper seems
to indicate that this 

Bug#890099: Th symlink seems to be invisible to all services

[Giuseppe Bilotta]

With some further testing, it would seem that the issue of not being
able to find/access anything under that path with the intermediate
symlink affects all services,not just nfs. I'm seeing it with
git-daemon-run (which runs via runit), as well as with apache (the
gitweb site is unable to follow those symlinks). I'm completely
stymied at what the cause might be. Is systemd somehow passing a
different view of mounted filesystems to its children?

-- 
Giuseppe "Oblomov" Bilotta

Bug#891593: python-fpylll-doc: broken symlink: /usr/share/doc/python-fpylll-doc/tests -> examples/tests

[Andreas Beckmann]

Package: python-fpylll-doc
Version: 0.3.0+ds1-4
Severity: normal
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package ships (or creates)
a broken symlink.

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

0m22.7s ERROR: FAIL: Broken symlinks:
  /usr/share/doc/python-fpylll-doc/tests -> examples/tests

The docs and examples are now placed under
/usr/share/doc/python-fpylll (probably due to debhelper 11),
the symlink should move accordingly.


cheers,

Andreas


python-fpylll-doc_0.3.0+ds1-4.log.gz
Description: application/gzip

Bug#891584: New version 1.0.4 available upstream

[Steve McIntyre]

On Mon, Feb 26, 2018 at 08:18:27PM +, Steve McIntyre wrote:
>Package: libwebservice-musicbrainz-perl
>Version: 0.93-1.1
>Severity: normal
>
>Hi,
>
>libwebservice-musicbrainz-perl is getting quite old in Debian, with
>multiple new upstream versions released now (up to 1.0.4). I'm working
>on abcde which uses this, and I'm being pestered to work with and test
>against newer versions.
>
>Happy to NMU for you if you like...

Packaging changes are fairly trivial, but the upstream code is almost
a complete re-write so the diff is quite large. I haven't yet uploaded
this anywhere, but I'd like it unstable soon so I can release a new
version of abcde which depends on it.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"Every time you use Tcl, God kills a kitten." -- Malcolm Ray


libwebservice-musicbrainz-perl_1.0.4-1.1.debdiff.gz
Description: application/gzip

Bug#889001: stretch-pu: package publicsuffix/20180125.0922-0+deb9u1

[Adam D. Barratt]

On Fri, 2018-02-23 at 10:56 -0800, Daniel Kahn Gillmor wrote:
> On Fri 2018-02-23 17:00:41 +, Adam D. Barratt wrote:
> > Control: tags -1 + confirmed
> > 
> > On Wed, 2018-01-31 at 23:21 -0500, d...@fifthhorseman.net wrote:
> > > Please consider an update to publicsuffix in debian stretch.
> > > 
> > > This package reflects the state of the network, and keeping it
> > > current
> > > is useful for all the packages that depend on it.
> > 
> > Please go ahead.
> 
> Since i filed this bug report, there are a handful of additional
> changes
> made upstream, as reflected in publicsuffix 20180218.2049-1 since
> 20180125.0922-1:
> 
> --- a/public_suffix_list.dat
> +++ b/public_suffix_list.dat
> @@ -10891,6 +10891,7 @@ virtueeldomein.nl
>  // Cloud66 : https://www.cloud66.com/
>  // Submitted by Khash Sajadi 
>  c66.me
> +cloud66.ws
>  
>  // CloudAccess.net : https://www.cloudaccess.net/
>  // Submitted by Pawel Panek 
> @@ -11786,6 +11787,11 @@ git-repos.de
>  lcube-server.de
>  svn-repos.de
>  
> +// linkyard ldt: https://www.linkyard.ch/
> +// Submitted by Mario Siegenthaler 
> +linkyard.cloud
> +linkyard-cloud.ch
> +
>  // LiquidNet Ltd : http://www.liquidnetlimited.com/
>  // Submitted by Victor Velchev 
>  we.bs
> @@ -12136,6 +12142,10 @@ sandcats.io
>  logoip.de
>  logoip.com
>  
> +// schokokeks.org GbR : https://schokokeks.org/
> +// Submitted by Hanno Böck 
> +schokokeks.net
> +
>  // Scry Security : http://www.scrysec.com
>  // Submitted by Shante Adam 
>  scrysec.com
> @@ -12316,6 +12326,10 @@ inc.hk
>  // Submitted by Ed Moore 
>  lib.de.us
>  
> +// VeryPositive SIA : http://very.lv
> +// Submitted by Danko Aleksejevs 
> +2038.io
> +
>  // Viprinet Europe GmbH : http://www.viprinet.com
>  // Submitted by Simon Kissel 
>  router.management
> @@ -12344,6 +12358,10 @@ cistron.nl
>  demon.nl
>  xs4all.space
>  
> +// YesCourse Pty Ltd : https://yescourse.com
> +// Submitted by Atul Bhouraskar 
> +official.academy
> +
>  // Yola : https://www.yola.com/
>  // Submitted by Stefano Rivera 
>  yolasite.com
> 
> 
> Would it be OK to retitle this bug report as:
> 
> stretch-pu: package publicsuffix/20180218.2049-0+deb9u1
> 

Sure.

Regards,

Adam

Bug#891592: tcc: -pthread no longer works

[Vincent Lefevre]

Package: tcc
Version: 0.9.27-4
Severity: important

There's an important regression: -pthread no longer works.

zira:~> cat tst.c
int main (void)
{
  return 0;
}
zira:~> tcc -pthread tst.c
tcc: error: undefined symbol 'main'

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

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

Versions of packages tcc depends on:
ii  libc6  2.26-6

Versions of packages tcc recommends:
ii  libc6-dev [libc-dev]  2.26-6

tcc suggests no packages.

-- no debconf information

Bug#891464: stretch-pu: package java-atk-wrapper/0.33.3-13+deb9u1

[Samuel Thibault]

Adam D. Barratt, on lun. 26 févr. 2018 20:27:38 +, wrote:
> Control: tags -1 + confirmed
> 
> On Sun, 2018-02-25 at 20:53 +0100, Samuel Thibault wrote:
> > It was reported (#837081) that notably netbeans would crash on
> > some operations due to java-atk-wrapper bugs. This was reported as
> > being fixed by a couple of small patches which have now migrated to
> > testing. I'd like to upload them to Stretch as attached diff shows.
> 
> Please go ahead.

It is now in stable-new.

Samuel

Bug#891591: lld: broken symlink: /usr/share/man/man1/lld.1.gz -> lld-5.0.1.gz

[Andreas Beckmann]

Package: lld
Version: 1:5.0-41~exp2
Severity: normal
User: debian...@lists.debian.org
Usertags: piuparts
Control: found -1 lld/1:5.0-41~exp2

Hi,

during a test with piuparts I noticed your package ships (or creates)
a broken symlink.

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

0m28.5s ERROR: FAIL: Broken symlinks:
  /usr/share/man/man1/lld.1.gz -> lld-5.0.1.gz

lld-5.0 ships a different file instead:
  /usr/share/man/man1/ld.lld-5.0.1.gz

cheers,

Andreas


lld_1:5.0-41~exp2.log.gz
Description: application/gzip

Bug#891555: Detect and warn about debhelper >= 11 instead of 11~ b-d

[Niels Thykier]

Thomas Goirand:
> [...]
> 
> And then debhelper 12 is released, people start to use it, and guess
> what happens... :)
> 

I am prototyping an alternative in debhelper that may make this issue
obsolete.  At the moment (since 11.1.5) you can use:

 Build-Depends: debhelper-compat (= 11)

as a replacement for:

 Build-Depends: debhelper (>= 11~)
 and d/compat set to 11.

Note the lack of "~" in the debhelper-compat version.


It spews out tons of warnings as it is still experimental.  Nonetheless,
feedback appreciated.

Thanks,
~Niels

Bug#891589: fonts-cantarell: broken symlink: /etc/fonts/conf.d/31-cantarell.conf -> /usr/share/fontconfig/conf.avail/31-cantarell.conf

[Andreas Beckmann]

Package: fonts-cantarell
Version: 0.100-2
Severity: important
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package ships (or creates)
a broken symlink.

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

0m25.1s ERROR: FAIL: Broken symlinks:
  /etc/fonts/conf.d/31-cantarell.conf -> 
/usr/share/fontconfig/conf.avail/31-cantarell.conf


The package in experimental no longer ships
/usr/share/fontconfig/conf.avail/31-cantarell.conf


cheers,

Andreas


fonts-cantarell_0.100-2.log.gz
Description: application/gzip

Bug#891590: sbuild: Please signalize autopkgtest failure by exit code, at least optionally

[Christoph Biedl]

Source: sbuild
Version: 0.73.0-4
Severity: wishlist

Dear Maintainer,

trying to use to autopkgtest feature of sbuild I was somewhat surprised
to learn there is no way to signalize a failing autopkgtest to the
sbuild caller. I'd expect to have something like

--- a/lib/Sbuild/Build.pm
+++ b/lib/Sbuild/Build.pm
@@ -1845,6 +1845,7 @@ sub run_autopkgtest {
 } else {
# fail if neither all tests passed nor was the package without tests
$self->log_error("Autopkgtest run failed.\n");
+   $self->set_status("failed");
return 0;
 }
 

at least as an option like --fail-from-failing-autopkgtest. So it seems
the only way was to inspect the build log. This doesn't seem right.

Did I miss something? Else, please take this as a feature request. Also
likewise for piuparts.

Regards,
Christoph


signature.asc
Description: PGP signature

Bug#889210: stretch update for libdap

[Adrian Bunk]

On Sat, Feb 03, 2018 at 01:51:18PM +, Debian Bug Tracking System wrote:
>...
>  libdap (3.19.1-2) unstable; urgency=medium
>...
>* Add libdap-doc.docs to install docs. Closes: #889210
>...

Thanks a lot for fixing this bug for unstable.

It is still present in stretch, could you also fix it there?
Alternatively, I can fix it for stretch if you don't object.

Thanks
Adrian

-- 

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

Bug#891422: tracker.debian.org: link to cppcheck results for packages

[Daniel Marjamäki]

I analyze the debian source packages I find here:

ftp://ftp.se.debian.org/debian/pool/main/

If you have an alternative location that you would prefer let me know.
Maybe there is some better location with "bleeding edge" source code
for instance.


> The format can be anything you like as long as it is machine-readable.

Imagine I analyze these packages:
ftp://ftp.se.debian.org/debian/pool/main/a/a2jmidid/a2jmidid_8~dfsg0.orig.tar.bz2
ftp://ftp.se.debian.org/debian/pool/main/a/a2ps/a2ps_4.14.orig.tar.gz

How about some format like this:

[
  { "package" : "a2jmidid", "results" :
"http://www.cppcheck.net/devinfo/daca2/a2jmidid.txt; },
  { "package" : "a2ps", "results" :
"http://www.cppcheck.net/devinfo/daca2/a2ps.txt; }
]

> PS: have cppcheck folks considered supporting the firehose static
> analysis results format?

I am not against that additional output formats are added.

However I would like to understand the reason for doing it. I have the
impression that firehose has some builtin cppcheck-import function.

Best regards,
Daniel Marjamäki

Bug#891588: sbuild: roff error in sbuild.1

[Christoph Biedl]

Source: sbuild
Version: 0.73.0-4
Severity: minor

Dear Maintainer,

studying the manpages I found something that appears to be a glitch
in the sbuild manpage. Please fix as by the patch below.

Christoph

--- a/man/sbuild.1.in
+++ b/man/sbuild.1.in
@@ -1115,7 +1115,7 @@ This command line option sets the \fBSBUILD_MODE\fP 
configuration variable. See
 .BR sbuild.conf (5)
 for more information.
 .TP
-.BR \-\tstats\-dir=\fIdirectory\fP
+.BR \-\-stats\-dir=\fIdirectory\fP
 Directory for writing build statistics to.
 This command line option sets the \fBSTATS_DIR\fP configuration variable. See
 .BR sbuild.conf (5)


signature.asc
Description: PGP signature

Bug#887589: stretch-pu: package grilo-plugins/0.3.3-1

[Adam D. Barratt]

Control: tags -1 + moreinfo

On Thu, 2018-01-18 at 11:36 +0200, Alberto Garcia wrote:
> I would like to upload a new grilo-plugins package, which contains a
> fix for https://bugs.debian.org/887469
> 

The BTS metadata for that bug indicates that it affects the version of
grilo-plugins in unstable and has not yet been resolved there - is that
correct?

Regards,

Adam

Bug#891555: Detect and warn about debhelper >= 11 instead of 11~ b-d

[Thomas Goirand]

On 02/26/2018 06:10 PM, Raphael Hertzog wrote:
> Hi,
> 
> On Mon, 26 Feb 2018, Thomas Goirand wrote:
>> Currently, there's debhelper 11~bpo9+1 in Stretch. However, mostly everyone
>> build-depends on debhelper (>= 11), making it impossible to use the 
>> backported
>> debhelper without fixing the debhelper version of the software to backport.
>>
>> It'd be nice if Lintian was warning about this, and nicely suggesting to
>> build- depend on version 11~, to allow backports.
> 
> I think it would be better to backport 11.1.4 (as 11.1.4~bpo9+1) and
> forget about this. Otherwise we will be asking developers to update this
> field for months if not years to come when in fact the problem will go
> away in a few days/weeks.
> 
> Cheers,

And then debhelper 12 is released, people start to use it, and guess
what happens... :)

So, perhaps my description wasn't broad enough, but I thought it was
obvious that we'd need something that would work forever.

BTW, to even make the scope broader, this is a general problem with
native packages and backports. We don't have the issue with non-native,
because lintian warns about the debian release number that comes after
the upstream version, which makes the problem solved. So lintian would
need to know about all native packages and suggest the addition of a ~
after the version, always (I don't think it'd be hard to embed a list of
native packages in the archive, would it?).

Your thoughts?

Cheers,

Thomas Goirand (zigo)

Bug#891577: stretch-pu: package nvidia-graphics-drivers-legacy-304xx/304.137-5~deb9u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Mon, 2018-02-26 at 21:39 +0100, Andreas Beckmann wrote:
> On 2018-02-26 20:58, Adam D. Barratt wrote:
> > +  * Use debian/substvars for substitutions by dpkg-genchanges
> > (dpkg
> > 1.19)
> > +(375.82-7).
> > 
> > What's the effect of not having support for that? (as 1.19 is newer
> > than stretch's dpkg.)
> 
> It's a no-op on stretch - debian/substvars is created but not used -
> dpkg-genchanges does not know about it - and the .changes file
> contains
> unsubstituted substvars (in the synopsis) - as it always has been.
> (The
> R³:no setting is an even noisier no-op).
> 
OK, please go ahead.

Regards,

Adam

Bug#890933: [Pkg-freeradius-maintainers] Bug#890933: freeradius: File permissions allow access to sensitive information by "others"

[Michael Stapelberg]

On Mon, Feb 26, 2018 at 8:17 PM,  wrote:

> Hi Michael,
>
>
>
> thank's for your response. The permission setting you described is exactly
> the setting I found on my host(s):
>
> root@intra:/etc/freeradius# ls -ldR /etc/freeradius/
>
> drwxr-s--x 6 freerad freerad 28 Feb 25 16:39 /etc/freeradius/
>
>
>
> _*But*_ in combination with the /etc/freeradius/users permission setting:
>
> root@intra:/etc/freeradius# ls -ldR /etc/freeradius/users
>
> -rw-r--r-- 1 root root 6524 Jul 26  2017 /etc/freeradius/users
>
>
>
> An "other" user can simply read the (maybe sensitive) content via a simple
> "cat /etc/freeradius/users".
>
>
>
> So, from my point of view the /etc/freeradius permissions should for
> example be set to 750 or the files within this directory (especially the
> „users“ file) need more restrictive permissions.
>
>
>
> Sorry for not sending the bugreport from the affected host, but in this
> case I think it is not necessary anymore?
>

It would still be good to know the version numbers involved, as permissions
have changed repeatedly over time.

When doing a fresh installation, or upgrading from < 3.0.12+dfsg-2, the
postinst script will change the permission of all files underneath
/etc/freeradius to 640, so either you must be using a very old version, or
something else went wrong. I’m also curious because recent package versions
use /etc/freeradius/3.0, not /etc/freeradius.

In any case, the packaging used mode 2751 for /etc/freeradius before I
became the maintainer, so I never questioned it.

Especially seeing that upstream is in agreement, I’m all for using a
stricter permission. I’ll change the package to use 2750 going forward.

jmm, is there any documentation regarding best practices for /etc directory
modes in Debian that I could refer to in my commit message?


>
>
> Greets
>
> Simon
>
>
>
>
>
> *Von:* mich...@i3wm.org [mailto:mich...@i3wm.org] *Im Auftrag von *Michael
> Stapelberg
> *Gesendet:* Sonntag, 25. Februar 2018 16:13
> *An:* Simon Boldinger ; 890...@bugs.debian.org
> *Betreff:* Re: [Pkg-freeradius-maintainers] Bug#890933: freeradius: File
> permissions allow access to sensitive information by "others"
>
>
>
> Hey Simon,
>
>
>
> On Tue, Feb 20, 2018 at 8:09 PM, Simon Boldinger 
> wrote:
>
> Package: freeradius
> Severity: grave
> Tags: security
> Justification: user security hole
>
> Dear Maintainer,
>
> first of all, I already shared the following information with the debian
> security team and they asked me to file this as a bug report: "I'm not why
> the
> Debian packaging diverges, can you please file a bug against freeradius to
> have
> the discussion with the maintainers in public?", Moritz Muehlenhoff from
> debian
> security team.
>
> Issue:
> It seems, that sensitive information (for example stored in
> /etc/freeradius/users) can be read by every system user ("others"). After
> asking the freeradius team I was told, that the /etc/freeradius directory
> has
> permissions 750 on their install (see Makefile). On my standard
> ubuntu/debian
> package installation there is another/divergent permission set, which
> allows
> every system user to access the freeradius directory (and therefore also
> some
> files like /etc/freeradius/users which can contain sensitive information).
>
>
>
> I cannot reproduce this. After “apt install freeradius” on debian sid, I
> end up with the following directory:
>
>
>
> root@a584ef009927:/# ls -ldR /etc/freeradius
>
> drwxr-s--x 3 freerad freerad 4096 Feb 25 15:08 /etc/freeradius
>
>
>
> The permissions are set up by https://anonscm.debian.org/
> cgit/pkg-freeradius/freeradius.git/tree/debian/freeradius.postinst?id=
> f205eab8474e33183d936f4f60006a2e070e8335#n23
>
>
>
> Unfortunately, your bug report was not filed from the machine on which you
> installed freeradius, so I can’t see which version of the package you’re
> using.
>
>
>
> Can you provide more details on your installation, along with the result
> of ls -ldR /etc/freeradius please?
>
>
>
>
> I assume the debian freeradius package should be adapted, so that access
> to the
> whole /etc/freeradius directory is restricted, as intended by the
> freeradius
> team.
>
> Best regards
> Simon Boldinger
>
>
>
> -- System Information:
> Debian Release: stretch/sid
>   APT prefers artful-updates
>   APT policy: (500, 'artful-updates'), (500, 'artful-security'), (500,
> 'artful'), (100, 'artful-backports')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 4.13.0-32-generic (SMP w/8 CPU cores)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
> LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
>
> Versions of packages freeradius depends on:
> pn  freeradius-common  
> pn  freeradius-config  
> ii  libc6  2.26-0ubuntu2.1
> pn  libct4 
> pn  libfreeradius3 
> ii  libgdbm3   1.8.3-14
> ii  libpam0g  

Bug#891555: Detect and warn about debhelper >= 11 instead of 11~ b-d

[Chris Lamb]

tags 891555 + wontfix
thanks

Thanks for providing the background detail re. the backport.

> Just bear with it for some weeks for few packages...

Mmm, that's the most sensible approach IMHO too. Closing the bug
to match, but thanks Zigo for raising this so we can get some
explicit explanation. :)


Best wishes,

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

Bug#891503: stretch-pu: package osinfo-db/0.20180226-1~deb9u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Mon, 2018-02-26 at 10:59 +0100, Guido Günther wrote:
> I'd like to update osinfo-db in stretch. This would allow us to have
> up
> to date information for operating system installs with e.g. gnome-
> boxes
> and virt-manager by adding new data for recent debian, ubuntu and
> freebsd releases as well as updating existing ones.
> 

I must admit that I'm confused by the changes of the type:

-  
http://cdimage.debian.org/cdimage/archive/9.0.0/i386/iso-cd/debian-9.0.0-i386-netinst.iso;
+  
http://cdimage.debian.org/cdimage/archive/9.2.1/i386/iso-cd/debian-9.2.1-i386-netinst.iso;
   

given that 9.3 was released on the same day as 8.10, and the latter is
reflected in the diff.

In any case, please go ahead.

Regards,

Adam

Bug#891484: stretch-pu: package vagrant/1.9.1+dfsg-1+deb9u1

[Adam D. Barratt]

Control: tags -1 + moreinfo

On Sun, 2018-02-25 at 22:10 -0300, Antonio Terceiro wrote:
> The platform from where vagrant downloads images has been
> discontinued
> and we need to switch the default download location plus
> documentation,
> usage messages etc to match the new platform. Without this update,
> vagrant is pretty useless.
> 

So far as I can tell, this issue also affects the version of vagrant in
unstable and has not yet been fixed there. Assuming that's correct, the
bug will need resolving in unstable first.

Regards,

Adam

Bug#891577: stretch-pu: package nvidia-graphics-drivers-legacy-304xx/304.137-5~deb9u1

[Andreas Beckmann]

On 2018-02-26 20:58, Adam D. Barratt wrote:
> +  * Use debian/substvars for substitutions by dpkg-genchanges (dpkg
> 1.19)
> +(375.82-7).
> 
> What's the effect of not having support for that? (as 1.19 is newer
> than stretch's dpkg.)

It's a no-op on stretch - debian/substvars is created but not used -
dpkg-genchanges does not know about it - and the .changes file contains
unsubstituted substvars (in the synopsis) - as it always has been. (The
R³:no setting is an even noisier no-op).



Andreas

Bug#891587: stretch-pu: package jdresolve/0.6.1-5.1~deb9u1

[Adrian Bunk]

Package: release.debian.org
Severity: normal
Tags: stretch
User: release.debian@packages.debian.org
Usertags: pu

   * Fix breakage with libnet-dns-perl in jessie and later,
 thanks to Klaus Rein for reporting the bug and
 Matt Johnston for forwarding the fix. (Closes: #801331)
diff -u jdresolve-0.6.1/debian/changelog jdresolve-0.6.1/debian/changelog
--- jdresolve-0.6.1/debian/changelog
+++ jdresolve-0.6.1/debian/changelog
@@ -1,3 +1,19 @@
+jdresolve (0.6.1-5.1~deb9u1) stretch; urgency=medium
+
+  * Non-maintainer upload.
+  * Rebuild for stretch.
+
+ -- Adrian Bunk   Mon, 26 Feb 2018 22:29:30 +0200
+
+jdresolve (0.6.1-5.1) unstable; urgency=high
+
+  * Non-maintainer upload.
+  * Fix breakage with libnet-dns-perl in jessie and later,
+thanks to Klaus Rein for reporting the bug and
+Matt Johnston for forwarding the fix. (Closes: #801331)
+
+ -- Adrian Bunk   Thu, 04 Jan 2018 20:21:09 +0200
+
 jdresolve (0.6.1-5) unstable; urgency=medium
 
   * debian/: merge packaging changes from Ubuntu. (Thanks Logan Rosen)
diff -u jdresolve-0.6.1/jdresolve jdresolve-0.6.1/jdresolve
--- jdresolve-0.6.1/jdresolve
+++ jdresolve-0.6.1/jdresolve
@@ -857,7 +857,12 @@
# For each DNS answer, check the data received
if ($type eq 'H') {
if (defined $_->{ptrdname}) {
+   if 
($_->isa('Net::DNS::RR::PTR')) { 
+   # Fix for a new version 
of Net::DNS 
+   $hosts{$query}{NAME} = 
$_->rdatastr();
+   } else {
$hosts{$query}{NAME} = 
$_->{ptrdname};
+   }
$hosts{$query}{RESOLVED} = 'N';
 
$resolved = 1;

Bug#891464: stretch-pu: package java-atk-wrapper/0.33.3-13+deb9u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Sun, 2018-02-25 at 20:53 +0100, Samuel Thibault wrote:
> It was reported (#837081) that notably netbeans would crash on
> some operations due to java-atk-wrapper bugs. This was reported as
> being fixed by a couple of small patches which have now migrated to
> testing. I'd like to upload them to Stretch as attached diff shows.
> 

Please go ahead.

Regards,

Adam

Bug#891277: stretch-pu: package debian-edu-config/1.929+deb9u1

[Adam D. Barratt]

Control: tags -1 + moreinfo

On Sat, 2018-02-24 at 02:25 +0100, Mike Gabriel wrote:
[...]
> 
+  * Chromium: Pre-configure Chromium Webbrowser system-wide to auto-
> detect the
> +http proxy settings via WPAD (plus locking the proxy settings
> dialog for
> +users). (Closes: #891262).
> 

The BTS metadata for this bug indicates that it also affects d-e-c in
unstable - is that correct?

Regards,

Adam

Bug#891586: tomboy-latex: Build-Depends on tomboy

[Jeremy Bicha]

Source: tomboy-latex
Version: 0.5-5
Severity: serious
Tags: buster sid

As part of an effort to remove unmaintained GNOME2 libraries from
Debian, tomboy will likely be removed from Testing soon. When this
happens, tomboy-latex will need to be removed from Testing too since
it Build-Depends and Depends on tomboy.

You may want to look into whether gnote can satisfy these dependencies.

There is also a rewrite (in Pascal!) of Tomboy that has not been
packaged in Debian yet:
https://github.com/tomboy-notes/tomboy-ng

I am filing an explicit bug here because tomboy is not eligible for
auto-removal because its popcon is still too high (it used to be part
of the 'gnome' metapackage.).

References
--
https://lists.debian.org/debian-devel/2018/02/msg00169.html
https://bugs.debian.org/885804 Tomboy depends on gconf via gnome-sharp2
https://bugs.debian.org/877259 Tomboy FTBFS

Thanks,
Jeremy Bicha

Bug#891584: New version 1.0.4 available upstream

[Steve McIntyre]

Package: libwebservice-musicbrainz-perl
Version: 0.93-1.1
Severity: normal

Hi,

libwebservice-musicbrainz-perl is getting quite old in Debian, with
multiple new upstream versions released now (up to 1.0.4). I'm working
on abcde which uses this, and I'm being pestered to work with and test
against newer versions.

Happy to NMU for you if you like...

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

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

Versions of packages libwebservice-musicbrainz-perl depends on:
ii  libclass-accessor-perl  0.34-1
ii  libwww-perl 6.15-1
ii  libxml-libxml-perl  2.0128+dfsg-1+deb9u1
ii  perl5.24.1-3+deb9u2

libwebservice-musicbrainz-perl recommends no packages.

libwebservice-musicbrainz-perl suggests no packages.

-- no debconf information

Bug#891585: nmu: intercal_30:0.30-1

[Adrian Bunk]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu
Control: block 879789 by -1

The #879789 error is linking a non-PIE static library
into a PIE binary.

Recompiling with a gcc that defaults to PIE fixes it,
and that's also how the no-change source upload in
unstable fixed it.

nmu intercal_30:0.30-1 . ANY . stretch . -m "Recompile with PIE"

Bug#884033: scilab-celestlab

[Paul Bignier]

Hello,

Indeed the changes from Scilab 5 to 6 include non-heterogeneous strings and 
quotes around the save(...) input parameters; so simply replacing
  execstr(sprintf('save(pathmacros+filesep()+''%s.bin'',%s)',vars(i),vars(i)));
by 
  
execstr(sprintf('save(pathmacros+filesep()+''%s.bin’’,'’%s'')',vars(i),vars(i)));
should do it.

Regards,
Paul

> On 24 Feb 2018, at 17:22, Sylvestre Ledru  wrote:
> 
> Context:
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=884033
> 
> + some upstream folks
> 
> Le 19/12/2017 à 19:06, Julien Puydt a écrit :
>> Hi,
>> 
>> again, a number of heterogeneous strings, then I get a prompt after
>> warnings, and quitting (several times) leads to a success.
>> 
>> I haven't reproduced the segfault in this bug report, but I have found
>> problems which indicate that the three listed packages do not support
>> the most recent scilab version.
>> 
>> What can we do to push things forward?
>> 
>> Snark on #debian-science
>> 

Bug#888006: stretch-pu: package salt/2016.11.2+ds-1

[Ondrej Novy]

Control: tags -1 - moreinfo

2018-02-26 20:38 GMT+01:00 Adam D. Barratt :

> The metadata for #887724 indicates that it currently affects the salt
> package in unstable; is that correct?
>

no, package in unstable is not affected. Bug metadata fixed, sry.

-- 
Best regards
 Ondřej Nový

Email: n...@ondrej.org
PGP: 3D98 3C52 EB85 980C 46A5  6090 3573 1255 9D1E 064B

Bug#891583: ITP: opendronemap -- A toolkit for processing aerial drone imagery

[Simon Spöhel]

Package: wnpp

* Package name  : opendronemap
  Upstream url  : https://github.com/OpenDroneMap/OpenDroneMap
* License   : GPL-v3
  Description   : A toolkit for processing aerial drone imagery

(Quoting from README.md)

"In a word, OpenDroneMap is a toolchain for processing raw civilian UAS
imagery to other useful products. What kind of products? Point Clouds,
Digital Surface Models, Textured Digital Surface Models, Orthorectified
Imagery, Digital Elevation Models, etc. Open Drone Map now includes
state-of-the-art 3D reconstruction."

Greetings
Simon

Bug#889728: stretch-pu: package bareos/16.2.4-3+deb9u2

[Felix Geyer]

On 23.02.2018 18:30, Adam D. Barratt wrote:
> Control: tags -1 + confirmed
> 
> On Tue, 2018-02-06 at 13:45 +0100, Felix Geyer wrote:
>> I'd like to fix bug #889040 in stretch:
>>
>> * Fix backups failing with "No Volume name given".
>>   - Backport upstream commit: Don't return empty volname if volume is
>> on
>> unwanted vols list.
>>
> 
> Please go ahead.

Thanks, uploaded.

Felix

Bug#890009: vulkan lunarg layers

[Brett Johnson]

These layers are found in the LunarG "VulkanTools" repository (
https://github.com/LunarG/VulkanTools).  I've already filed ITP #890474 for
these layers.

Bug#891582: Dependency missing in vulkan-utils

[Brett Johnson]

Package: vulkan
Version: 1.0.65.2+dfsg1-1
Severity: serious
Justification: 1


The utility "vulkan-smoketest" in the vulkan-utils package depends on
layers in the libvulkan-dev package, but there is no dependency.  This can
be easily verified by running it with the "--validate" option:

$ vulkan-smoketest --validate
terminate called after throwing an instance of 'std::runtime_error'
  what():  instance layer VK_LAYER_LUNARG_standard_validation is missing
Aborted


The easiest way to fix this is simply add a dependency, but it raises the
question of why the vulkan-utils package exists.  Both vulkaninfo and
smoketest could reasonably just be part of libvulkan-dev, as both are
really vulkan developer utilities, rather than general purpose utilities.

Bug#891581: stretch-pu: package chaosreader/0.96-2+deb9u1

[Adrian Bunk]

Package: release.debian.org
Severity: normal
Tags: stretch
User: release.debian@packages.debian.org
Usertags: pu

   * Added libnet-dns-perl to Depends field. (Closes: #890589)
diff -Nru chaosreader-0.96/debian/changelog chaosreader-0.96/debian/changelog
--- chaosreader-0.96/debian/changelog   2017-01-05 01:50:33.0 +0200
+++ chaosreader-0.96/debian/changelog   2018-02-26 22:05:18.0 +0200
@@ -1,3 +1,10 @@
+chaosreader (0.96-2+deb9u1) stretch; urgency=medium
+
+  * Non-maintainer upload.
+  * Added libnet-dns-perl to Depends field. (Closes: #890589)
+
+ -- Adrian Bunk   Mon, 26 Feb 2018 22:05:18 +0200
+
 chaosreader (0.96-2) unstable; urgency=medium
 
   * debian/watch: updated. The upstream is
diff -Nru chaosreader-0.96/debian/control chaosreader-0.96/debian/control
--- chaosreader-0.96/debian/control 2016-11-18 11:56:51.0 +0200
+++ chaosreader-0.96/debian/control 2018-02-26 22:05:09.0 +0200
@@ -11,7 +11,7 @@
 
 Package: chaosreader
 Architecture: all
-Depends: ${misc:Depends}, ${perl:Depends}
+Depends: ${misc:Depends}, ${perl:Depends}, libnet-dns-perl
 Suggests: tcpdump, wireshark
 Description: trace network sessions and export it to html format
  Chaosreader traces TCP/UDP/others sessions and fetches application data from