Bug#887924: slurm-drmaa FTBFS with slurm-llnl 17.11.2-1

[Steve Langasek]

Looking closer, I see:

configure:12821: checking for usable SLURM libraries/headers
configure:12842: gcc -o conftest -pedantic -ansi -g -O2 -fdebug-prefix-map=/tmp/
slurm-drmaa-1.0.7=. -fstack-protector-strong -Wformat -Werror=format-security -p
thread -D_REENTRANT -D_THREAD_SAFE -DNDEBUG -Wdate-time -D_FORTIFY_SOURCE=2 -D_G
NU_SOURCE -I/usr/include/slurm/ -Wl,-Bsymbolic-functions -Wl,-z,relro -L/usr/lib
/libslurm.so conftest.c -pthread  -lslurm  >&5
conftest.c:23:11: fatal error: slurm/slurm.h: No such file or directory
  #include "slurm/slurm.h"
   ^~~
compilation terminated.

But the libslurm-dev package doesn't provide such a path:

$ dpkg -L libslurm-dev | grep usr/include
/usr/include
/usr/include/slurm-wlm
/usr/include/slurm-wlm/slurm.h
/usr/include/slurm-wlm/slurm_errno.h
/usr/include/slurm-wlm/smd_ns.h
/usr/include/slurm-wlm/spank.h
$

Certainly, /usr/include/slurm/slurm/slurm.h (as implied by the combination
of configure options with m4/ax_slurm.m4) does not exist.

It's possible this is a bug in both slurm-llnl and slurm-drmaa.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature

Bug#889689: pytest-arraydiff: Incomplete debian/copyright?

[Ole Streicher]

Control: tags -1 moreinfo

Hi Chris,

thank you for the review of pytest-arraydiff!

On 05.02.2018 22:33, Chris Lamb wrote:
> I just ACCEPTed pytest-arraydiff from NEW but noticed it was missing 
> attribution in debian/copyright for at least src/jsonrpc-version-macros.h.

Hmm, there is no file src/jsonrpc-version-macros.h in the
pytest-arraydiff source? Are you sure you filed the bug against the
correct package?

Best regards

Ole

$ ls -lR
.:
insgesamt 56
-rw-r--r-- 1 ole ole  218 Feb  5 08:34 CHANGES.md
drwxr-xr-x 5 ole ole 4096 Feb  5 08:34 debian
-rw-r--r-- 1 ole ole 1448 Feb  5 08:34 LICENSE
-rw-r--r-- 1 ole ole  113 Feb  5 08:34 MANIFEST.in
-rw-r--r-- 1 ole ole 9567 Feb  5 08:34 PKG-INFO
drwxr-xr-x 3 ole ole 4096 Feb  5 08:34 pytest_arraydiff
drwxr-xr-x 2 ole ole 4096 Feb  5 08:34 pytest_arraydiff.egg-info
-rw-r--r-- 1 ole ole 7156 Feb  5 08:34 README.rst
-rw-r--r-- 1 ole ole   59 Feb  5 08:34 setup.cfg
-rwxr-xr-x 1 ole ole 1370 Feb  5 08:34 setup.py
drwxr-xr-x 3 ole ole 4096 Feb  5 08:34 tests

./debian:
insgesamt 36
-rw-r--r-- 1 ole ole  160 Feb  5 08:34 changelog
-rw-r--r-- 1 ole ole3 Feb  5 08:34 compat
-rw-r--r-- 1 ole ole 1193 Feb  5 08:34 control
-rw-r--r-- 1 ole ole 1615 Feb  5 08:34 copyright
drwxr-xr-x 2 ole ole 4096 Feb  5 08:34 patches
-rwxr-xr-x 1 ole ole  118 Feb  5 08:34 rules
drwxr-xr-x 2 ole ole 4096 Feb  5 08:34 source
drwxr-xr-x 2 ole ole 4096 Feb  5 08:34 tests
-rw-r--r-- 1 ole ole  157 Feb  5 08:34 watch

./debian/patches:
insgesamt 8
-rw-r--r-- 1 ole ole   38 Feb  5 08:34 series
-rw-r--r-- 1 ole ole 2601 Feb  5 08:34 Use-Python-3-version-of-py.test.patch

./debian/source:
insgesamt 4
-rw-r--r-- 1 ole ole 12 Feb  5 08:34 format

./debian/tests:
insgesamt 4
-rw-r--r-- 1 ole ole 34 Feb  5 08:34 control

./pytest_arraydiff:
insgesamt 20
-rwxr-xr-x 1 ole ole20 Feb  5 08:34 __init__.py
-rwxr-xr-x 1 ole ole 11576 Feb  5 08:34 plugin.py
drwxr-xr-x 2 ole ole  4096 Feb  5 08:34 __pycache__

./pytest_arraydiff/__pycache__:
insgesamt 0

./pytest_arraydiff.egg-info:
insgesamt 32
-rw-r--r-- 1 ole ole1 Feb  5 08:34 dependency_links.txt
-rw-r--r-- 1 ole ole   55 Feb  5 08:34 entry_points.txt
-rw-r--r-- 1 ole ole 9567 Feb  5 08:34 PKG-INFO
-rw-r--r-- 1 ole ole   17 Feb  5 08:34 requires.txt
-rw-r--r-- 1 ole ole  635 Feb  5 08:34 SOURCES.txt
-rw-r--r-- 1 ole ole   17 Feb  5 08:34 top_level.txt

./tests:
insgesamt 12
drwxr-xr-x 2 ole ole 4096 Feb  5 08:34 baseline
-rw-r--r-- 1 ole ole 4128 Feb  5 08:34 test_pytest_arraydiff.py

./tests/baseline:
insgesamt 40
-rw-r--r-- 1 ole ole 5760 Feb  5 08:34 test_succeeds_class.fits
-rw-r--r-- 1 ole ole   35 Feb  5 08:34 test_succeeds_func_default.txt
-rw-r--r-- 1 ole ole 5760 Feb  5 08:34 test_succeeds_func_fits.fits
-rw-r--r-- 1 ole ole 5760 Feb  5 08:34 test_succeeds_func_fits_hdu.fits
-rw-r--r-- 1 ole ole   35 Feb  5 08:34 test_succeeds_func_text.txt
-rw-r--r-- 1 ole ole 5760 Feb  5 08:34 test_tolerance.fits

Bug#882017: solution available upstream

[Christian Ehrhardt]

I tried to pick the patch mentioned before and it is ok, but not enough.
In addition Debian needs the changes in [1] to build correctly again.

[1]: https://github.com/MagicStack/asyncpg/issues/256

-- 
Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd

Bug#889701: comet-ms: unsatisfiable build dependency

[Steve Langasek]

Source: comet-ms
Version: 2017012-1
Severity: serious

Hi Filippo,

The comet-ms package in Debian unstable is unbuildable on all architectures,
because it build-depends on libmstoolkit-dev (>= 82) but the most recent
version of libmstoolkit which has been uploaded to the archive is
77.0.0-1.1.  If this newer version is required, please upload it to Debian
(I see you are the maintainer of both packages); otherwise, please relax the
build-dependency.

Cheers,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature

Bug#889700: mininet: Missing test dependency on openvswitch-switch

[Steve Langasek]

Package: mininet
Version: 2.2.2-2
Severity: important
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu bionic ubuntu-patch autopkgtest

Dear maintainers,

Since the upload of mininet 2.2.2-2, the autopkgtests for this package have
been consistently failing in Ubuntu:

*** Adding switches:
Cannot find required executable ovs-vsctl.
Please make sure that Open vSwitch (openvswitch.org) is installed and available 
in your $PATH:
(/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin)
autopkgtest [15:11:15]: test simple: ---]
simple   FAIL non-zero exit status 1

  http://autopkgtest.ubuntu.com/packages/m/mininet/bionic/amd64

The openvswitch-switch package is only a recommends: of the binary package,
so is not automatically installed in the test environment.

This test failure is not reported on ci.debian.net, because the test
infrastructure there does not provide machine-isolation, so these tests are
skipped instead.

The attached patch, which has been uploaded to Ubuntu, adds an explicit test
dependency on openvswitch-switch to let it pass.  Please consider applying
this patch in Debian.

Thanks,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru mininet-2.2.2/debian/tests/control mininet-2.2.2/debian/tests/control
--- mininet-2.2.2/debian/tests/control  2017-12-03 05:29:47.0 -0800
+++ mininet-2.2.2/debian/tests/control  2018-02-05 23:29:08.0 -0800
@@ -1,3 +1,3 @@
 Tests: simple
-Depends: @, sudo, net-tools
+Depends: @, sudo, net-tools, openvswitch-switch
 Restrictions: isolation-machine, needs-root

Bug#889699: gnome-terminal-server leaves left-over processes, causing systemd to complain

[Matijs van Zuijlen]

Package: gnome-terminal
Version: 3.26.2-3
Severity: normal

Dear maintainer,

Gnome-terminal-server is set up to leave child processes running after
it exits. I think this is a good thing, but it seems that it exits as
soon as all UI windows are closed, and systemd feels the need to
complain about the left-over processes. As a result, whenever I close
the terminal, my log is filled with systemd warnings.

I'm not sure what the best solution is here, but it seems at least the
server could just stay around in anticipation of a new UI window being
opened.

Kind regards,
Matijs

PS: See https://github.com/systemd/systemd/issues/7864 for a discussion
about the possibility of systemd not logging as much.

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

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

Versions of packages gnome-terminal depends on:
ii  dbus-user-session [default-dbus-session-bus]  1.12.2-1
ii  dbus-x11 [dbus-session-bus]   1.12.2-1
ii  dconf-gsettings-backend [gsettings-backend]   0.26.1-3
ii  gnome-terminal-data   3.26.2-3
ii  gsettings-desktop-schemas 3.24.1-2
ii  libatk1.0-0   2.26.1-3
ii  libc6 2.26-6
ii  libdconf1 0.26.1-3
ii  libglib2.0-0  2.54.3-2
ii  libgtk-3-03.22.26-2
ii  libnautilus-extension1a   3.26.2-2
ii  libpango-1.0-01.40.14-1
ii  libuuid1  2.30.2-0.3
ii  libvte-2.91-0 0.50.2-4
ii  libx11-6  2:1.6.4-3

Versions of packages gnome-terminal recommends:
ii  gvfs  1.34.1-2
ii  yelp  3.26.0-2

gnome-terminal suggests no packages.

-- no debconf information

Bug#805414: An alternate workaround

[Matthias Urlichs]

is to bite the bullet and run pulseaudio as a system-wide service. Yes I
know this is not "recommended" but, to be blunt, IMHO that
recommendation is bollocks.

No more fighting about which PA daemon gets a device, and you can
actually use mpd without impacting your regular audio output.

-- 
-- Matthias Urlichs

Bug#889640: lintian: init.d-script-possible-missing-stop misfire on rcS scripts

[Ron]

On Tue, Feb 06, 2018 at 03:32:55AM +0530, Chris Lamb wrote:
> tags 820770 + moreinfo
> thanks
> 
> 
> Hi Ron and Felipe,
> 
> Hm, are #820770 and #889640 the same issue? If so, we should either
> close them both or reopen both of them.

Yes, that was exactly my line of thinking when I first saw this warning,
before discovering that in practice /etc/rc1.d/S01killprocs is going to
stop it anyway before switching to rcS and restarting it again.  And
that is exactly what the extended lintian warning was trying to explain
(and probably successfully would have if the system I first saw it on
had initscripts installed which provides that script).

These two should definitely be merged, but I'd welcome Felipe reviewing
the conclusions I came to here https://bugs.debian.org/889640#15 just
in case I did miss something we ought to do other than just close this
now.

  Cheers,
  Ron

Bug#889698: nss 3.35 now defaults to SQL database, broke certmonger/mod_nss/dogtag/freeipa

[Timo Aaltonen]

Package: nss
Severity: grave

Hi, please revert this commit which switched the default certificate database 
format to SQL:

https://github.com/nss-dev/nss/commit/33b114e38278c4ffbb6b244a0ebc9910e5245cd3

Several packages are not ready for it yet, including but likely not limited to:

certmonger
libapache2-mod-nss
dogtag-pki
freeipa

respective upstreams are working on it but getting everything merged will take 
a month or two.


-- 
t

Bug#889697: RFS: zerotier-one/1.2.4+ds-1 [ITP]

[Yangfl]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "zerotier-one"

 * Package name: zerotier-one
   Version : 1.2.4+ds-1
   Upstream Author : ZeroTier, Inc.
 * URL : https://www.zerotier.com/
 * License : GPLv3+
   Section : net

It builds those binary packages:

  zerotier-one - ZeroTier network virtualization service

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

https://mentors.debian.net/package/zerotier-one


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

  dget -x 
https://mentors.debian.net/debian/pool/main/z/zerotier-one/zerotier-one_1.2.4+ds-1.dsc

More information about hello can be obtained from https://www.example.com.

Changes since the last upload:

[your most recent changelog entry]


Regards,
 Yangfl

Bug#889696: ITP: editorconfig-gedit -- EditorConfig support for GEdit

[Ben Finney]

Package: wnpp
Severity: wishlist
Owner: Ben Finney 

* Package name: editorconfig-gedit
  Version : 0.5.3
  Upstream Author : EditorConfig Team
* URL : https://github.com/editorconfig/editorconfig-gedit/
* License : BSD-2-clause
  Programming Lang: Python
  Description : EditorConfig support for GEdit

  EditorConfig makes it easy to maintain the correct coding style
  when switching between different text editors and between
  different projects.
  .
  This package installs the plug-in for GEdit to support
  EditorConfig settings.

-- 
 \ “I'm a born-again atheist.” —Gore Vidal |
  `\   |
_o__)  |
Ben Finney 


signature.asc
Description: PGP signature

Bug#888089: Really serious?

[Ondřej Surý]

Thanks for understanding. If you are to switch to embedded botan 1.10 before 
upstream sorts this out, you probably ought to upgrade the embedded version to 
latest upstream (1.10.17).

I think Christian has already filled RM bug: 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=889675

Ondřej 
--
Ondřej Surý 

> On 5 Feb 2018, at 21:08, Lisandro Damián Nicanor Pérez Meyer 
>  wrote:
> 
>> On 5 February 2018 at 16:54, Ondřej Surý  wrote:
>> We want to remove botan1.10 from testing, so yes, this warrants a serious 
>> severity, and it has only three r-depends:
>> 
>> 1. monotone is dead (last upstream release 2011), we shouldn’t keep zombies 
>> in Debian
>> 
>> 2. ovito is leaf package and ranked very low in popcon
>> 
>> 3. qtcreator is a leaf package[a] and ranked high in popcon
>> 
>> So I think it’s quite appropriate to fill serious bug instantly, as it 
>> doesn’t affect half of the archive, but just two (one) package.
>> 
>> From quickly skimming the Botan usage in qtcreator, I think it might be 
>> quite easy to use botan 2.x in QtCreator.  It’s just only a matter of 
>> somebody packaging it (and afaik our conversation will reset the auto-RM 
>> timer)...
> 
> ACK then. I think you should really go and file the RoM bug then, I
> can make qtcreator fall back to it's embedded version for the
> meantime.
> 
> I asked qtcreator's upstreams and so far I did not receive a reply on
> this. we want to avoid a delta with them as much as possible.

Bug#889695: RFS: worklog/1.9-1 [ITA] -- Keep Track of Time worked on Projects

[Adam Bilbrough]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

   Package name: worklog
   Version: 1.9-1
   Upstream Author: Adam Bilbrough 
   URL: https://gitlab.com/atsb/worklog
   License: Public Domain
   Section: misc

  It builds these binary packages:

worklog - Keep Track of Time worked on Projects

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

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


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

dget -x 
https://mentors.debian.net/debian/pool/main/w/worklog/worklog_1.9-1.dsc

  More information about worklog can be obtained from:

https://gitlab.com/atsb/worklog

  Changes since the last upload:

  * New maintainer. (Closes: #628157)
  * New upstream release.
  * Merged patch for time update. (Closes: #548349)
  * Merged patch for negative times. (Closes: #571718)
  * Merged patch for using too much CPU. (Closes: #630570)
  * Merged patch for rounding text. (Closes: #548347)
  * Merged all debian quilt patches into codebase.


  Regards,

   Adam

Bug#889592: lintian: false positive for override_dh_auto_test-does-not-check-DEB_BUILD_PROFILES

[Mattia Rizzolo]

don't forget, the tag could also be marked as experimental, which is
thought exactly to help out developing of the tags with high chances of
fpos.

On Tue, Feb 6, 2018 at 4:48 AM Daniel Kahn Gillmor  wrote:

> On Mon 2018-02-05 04:38:14 +0530, Chris Lamb wrote:
> > tags 889592 + pending
> > thanks
> >
> > "Fixed" in Git, pending upload:
> >
> >
> https://anonscm.debian.org/git/lintian/lintian.git/commit/?id=293c897ef968e0f50ac4f48986034aeda57e179d
> >
> > Ah well, just too many false-positive cases.. I mean, we'd have to start
> > ignoring ": " comments, as well as detecting the differences between,
> say:
> >
> > override_dh_auto_test:
> >   echo "input" | ./testsuite.sh
> >
> > and
> >
> > override_dh_auto_test:
> >   echo "Not running"
>
> Hm, ripping it out entirely seems suboptimal, i'd love to be able to
> find and fix a bunch of these.
>
> What if the tag didn't trigger if there was only one command in
> override_dh_auto_test, and it started with either "dh_auto_test " or
> with ": "?
>
> i think that would avoid most of the important false-positives, and the
> tag could provide guidance for folks who were doing 'echo "Not running"'
> to use ': Not running' instead.
>
> Seems a shame to lose a bunch of good catches if we can prune down the
> false-positives.  And even if this ends up missing some true positives,
> it would be a net win to catch the packages that *do* fail to check
> DEB_BUILD_PROFILES.
>
>--dkg
>

Bug#889592: lintian: false positive for override_dh_auto_test-does-not-check-DEB_BUILD_PROFILES

[Daniel Kahn Gillmor]

On Mon 2018-02-05 04:38:14 +0530, Chris Lamb wrote:
> tags 889592 + pending
> thanks
>
> "Fixed" in Git, pending upload:
>
>   
> https://anonscm.debian.org/git/lintian/lintian.git/commit/?id=293c897ef968e0f50ac4f48986034aeda57e179d
>
> Ah well, just too many false-positive cases.. I mean, we'd have to start
> ignoring ": " comments, as well as detecting the differences between, say:
>
> override_dh_auto_test:
>   echo "input" | ./testsuite.sh
>
> and
>
> override_dh_auto_test:
>   echo "Not running"

Hm, ripping it out entirely seems suboptimal, i'd love to be able to
find and fix a bunch of these.

What if the tag didn't trigger if there was only one command in
override_dh_auto_test, and it started with either "dh_auto_test " or
with ": "?

i think that would avoid most of the important false-positives, and the
tag could provide guidance for folks who were doing 'echo "Not running"'
to use ': Not running' instead.

Seems a shame to lose a bunch of good catches if we can prune down the
false-positives.  And even if this ends up missing some true positives,
it would be a net win to catch the packages that *do* fail to check
DEB_BUILD_PROFILES.

   --dkg


signature.asc
Description: PGP signature

Bug#889605: libreoffice: FTBFS on m68k: udkapi.rdb build fails ("Bad input")

[Aaron M. Ucko]

Control: notforwarded -1

"Aaron M. Ucko"  writes:

> Per the official bug-reporting instructions, I already reported this
> bug upstream (as #115450), and have marked this bug as forwarded
> accordingly.

This approach turned out to be inappropriate for FTBFS bugs, so I
e-mailed the upstream developer list instead.   (My e-mail has not yet
shown up in the archives, so I'm simply marking this bug as not
forwarded for now.)

-- 
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#850660: nodejs-dev: npm conflicts transitively with libssl-dev since nodejs-dev 4.7.2~dfsg-1

[anomie]

It looks like this is fixed with nodejs version 8.9.3~dfsg-1.

  * Backport #16130: support both openssl 1.0.1 and 1.1.0
Add openssl/fixups.patch to take care of additional fixes.
  * Build against latest ssl-dev version

Only took a year...

Bug#889693: htop exits with a strange message in a terminal with no more than 41 columns

[Vincent Lefevre]

Package: htop
Version: 2.1.0-2
Severity: minor

If I start htop in a terminal with no more than 41 columns, it
immediately exits with the message:

htop: Success

I don't see any success.

-- 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.14.0-3-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 htop depends on:
ii  libc6 2.26-6
ii  libncursesw5  6.0+20171125-1
ii  libtinfo5 6.0+20171125-1

htop recommends no packages.

Versions of packages htop suggests:
ii  lsof4.89+dfsg-0.1
ii  strace  4.19-1

-- no debconf information

Bug#889694: ITP: editorconfig-core-py -- Python library for working with EditorConfig

[Ben Finney]

Package: wnpp
Severity: wishlist
Owner: Ben Finney 

* Package name: editorconfig-core-py
  Version : 0.12.1
  Upstream Author : EditorConfig Team
* URL : https://pypi.org/project/EditorConfig/
* License : PSF-2
  Programming Lang: Python
  Description : Python library for working with EditorConfig

  EditorConfig makes it easy to maintain the correct coding style
  when switching between different text editors and between
  different projects.
  .
  When developing an editor plugin for reading EditorConfig files,
  the EditorConfig core code can be used to locate and parse these
  files.
  .
  This package is the Python library of EditorConfig Core.

This is a dependency for the ‘editorconfig-gedit’ package.

-- 
 \   德不孤、必有鄰。 (The virtuous are not abandoned, |
  `\   they shall surely have neighbours.) |
_o__)—孔夫子 Confucius (551 BCE – 479 BCE) |
Ben Finney 


signature.asc
Description: PGP signature

Bug#889692: qml-module-org-kde-newstuff: Should depend on kirigami2 instead of kirigami

[Zhang Jingqiang]

Package: qml-module-org-kde-newstuff
Version: 5.41.0-1
Severity: normal

Dear Maintainer,

Please fix the dependency as it contains
"import org.kde.kirigami 2.1 as Kirigami" in NewStuffItem.qml.

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

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

Versions of packages qml-module-org-kde-newstuff depends on:
ii  libc62.26-6
ii  libgcc1  1:7.3.0-1
ii  libkf5attica55.41.0-1
ii  libkf5coreaddons55.41.0-1
ii  libkf5newstuffcore5  5.41.0-1
ii  libqt5core5a 5.9.2+dfsg-9
ii  libqt5gui5   5.9.2+dfsg-9
ii  libqt5network5   5.9.2+dfsg-9
ii  libqt5qml5   5.9.2-3
ii  libqt5quick5 5.9.2-3
ii  libstdc++6   7.3.0-1
ii  qml-module-org-kde-kirigami  1.1.0-2

qml-module-org-kde-newstuff recommends no packages.

qml-module-org-kde-newstuff suggests no packages.

-- no debconf information

Bug#889691: gedit-plugin-git: AttributeError calling get_repository on None

[Carl Suster]

Package: gedit-plugin-git
Version: 3.22.0-4
Severity: normal

The system logs for gedit contain lines like the following coming from the git
plugin:

Feb  6 11:21:47 colt org.gnome.gedit[1326]: Traceback (most recent call last):
Feb  6 11:21:47 colt org.gnome.gedit[1326]:   File 
"/usr/lib/x86_64-linux-gnu/gedit/plugins/git/windowactivatable.py", line 291, 
in root_changed
Feb  6 11:21:47 colt org.gnome.gedit[1326]: repo = 
self.get_repository(location, True)
Feb  6 11:21:47 colt org.gnome.gedit[1326]:   File 
"/usr/lib/x86_64-linux-gnu/gedit/plugins/git/windowactivatable.py", line 282, 
in get_repository
Feb  6 11:21:47 colt org.gnome.gedit[1326]: return 
self.app_activatable.get_repository(location, is_dir)
Feb  6 11:21:47 colt org.gnome.gedit[1326]: AttributeError: 'NoneType' object 
has no attribute 'get_repository'
Feb  6 11:21:47 colt org.gnome.gedit[1326]: Traceback (most recent call last):
Feb  6 11:21:47 colt org.gnome.gedit[1326]:   File 
"/usr/lib/x86_64-linux-gnu/gedit/plugins/git/windowactivatable.py", line 298, 
in inserted
Feb  6 11:21:47 colt org.gnome.gedit[1326]: repo = 
self.get_repository(location, msg.is_directory)
Feb  6 11:21:47 colt org.gnome.gedit[1326]:   File 
"/usr/lib/x86_64-linux-gnu/gedit/plugins/git/windowactivatable.py", line 282, 
in get_repository
Feb  6 11:21:47 colt org.gnome.gedit[1326]: return 
self.app_activatable.get_repository(location, is_dir)
Feb  6 11:21:47 colt org.gnome.gedit[1326]: AttributeError: 'NoneType' object 
has no attribute 'get_repository'

Incidentally, the version of the plugin included in the debian package seems to
be very old. The copyright information installed with the package is a decade
behind the latest release, though the year in the plugin's about dialog is only
about 3 years behind upstream.


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

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

Versions of packages gedit-plugin-git depends on:
ii  gedit 3.22.1-3
ii  gedit-plugins-common  3.22.0-4
ii  gir1.2-ggit-1.0   0.26.2-1
ii  gir1.2-glib-2.0   1.54.1-4
ii  gir1.2-gtk-3.03.22.26-2
ii  gir1.2-gtksource-3.0  3.24.6-1
ii  python3   3.6.4-1
ii  python3-gi3.26.1-2
ii  python3-gi-cairo  3.26.1-2

gedit-plugin-git recommends no packages.

gedit-plugin-git suggests no packages.

-- no debconf information

Bug#889690: gimp: Cage transform always crashes Gimp

[Pelle Hjek]

Package: gimp
Version: 2.8.18-1+deb9u1
Severity: important

Dear Maintainer,

Cage tool always causes Gimp to crash.

I created a new image, selected Cage Transform, created some selection
points, clicked on the first selection point to finish the selection.

The result is that Gimp becomes completely unresponsive.

I expected Gimp to let me apply a cage transformation to the selection.

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

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

Versions of packages gimp depends on:
ii  gimp-data2.8.18-1+deb9u1
ii  libaa1   1.4p5-44+b1
ii  libatk1.0-0  2.22.0-1
ii  libbabl-0.1-00.1.18-1
ii  libbz2-1.0   1.0.6-8.1
ii  libc62.24-11+deb9u1
ii  libcairo21.14.8-1
ii  libdbus-1-3  1.10.24-0+deb9u1
ii  libdbus-glib-1-2 0.108-2
ii  libexif120.6.21-2+b2
ii  libexpat12.2.0-2+deb9u1
ii  libfontconfig1   2.11.0-6.7+b1
ii  libfreetype6 2.6.3-3.2
ii  libgdk-pixbuf2.0-0   2.36.5-2+deb9u2
ii  libgegl-0.3-00.3.8-4
ii  libgimp2.0   2.8.18-1+deb9u1
ii  libglib2.0-0 2.50.3-2
ii  libgs9   9.20~dfsg-3.2+deb9u1
ii  libgtk2.0-0  2.24.31-2
ii  libgudev-1.0-0   230-3
ii  libice6  2:1.0.9-2
ii  libjpeg62-turbo  1:1.5.1-2
ii  libjson-glib-1.0-0   1.2.6-1
ii  liblcms2-2   2.8-4
ii  libmng1  1.0.10+dfsg-3.1+b5
ii  libpango-1.0-0   1.40.5-1
ii  libpangocairo-1.0-0  1.40.5-1
ii  libpangoft2-1.0-01.40.5-1
ii  libpng16-16  1.6.28-1
ii  libpoppler-glib8 0.48.0-2+deb9u2
ii  librsvg2-2   2.40.16-1+b1
ii  libsm6   2:1.2.2-1+b3
ii  libtiff5 4.0.8-2+deb9u2
ii  libwmf0.2-7  0.2.8.4-10.6
ii  libx11-6 2:1.6.4-3
ii  libxcursor1  1:1.1.14-1+deb9u1
ii  libxext6 2:1.3.3-1+b2
ii  libxfixes3   1:5.0.3-1
ii  libxmu6  2:1.1.2-2
ii  libxpm4  1:3.5.12-1
ii  libxt6   1:1.1.5-1
ii  python   2.7.13-2
ii  python-gtk2  2.24.0-5.1
ii  python2.72.7.13-2+deb9u2
ii  zlib1g   1:1.2.8.dfsg-5

Versions of packages gimp recommends:
ii  ghostscript  9.20~dfsg-3.2+deb9u1

Versions of packages gimp suggests:
pn  gimp-data-extras  
pn  gimp-help-en | gimp-help  
ii  gvfs-backends 1.30.4-1
ii  libasound21.1.3-5

-- no debconf information

Bug#860995: Correction for CVE-2017-8054 patch (was: Bug#860995: libpodofo: CVE-2017-8054 fix tested in unstable chroot, PoC generator source attached)

[Mattia Rizzolo]

Control: tag -1 -fixed-upstream

On Tue, Feb 06, 2018 at 01:26:00AM +0100, Matthias Brinke wrote:
> I've investigated that and implemented a
> correction, which I tested with -fsanitize=address (ASan) in
> a Debian sid chroot (up-to-date, mostly? minimal) through
> sbuild (from jessie-backports), attached here.

Thank you!

> This patch is complete to add to the Debian package, so please
> disregard the older (and incorrect) patch in this bug thread.
> 
> I'm sorry I'm answering only now, the divergence between the
> package and the upstream svn repository (also through the partial
> revert) presented some challenges in patch handling. Because of
> this, the patch is also not for forwarding (it wouldn't apply there).

Well, in cases like this I usually try to make it apply to the upstream
SVN tree and forward it.
It's a job that one day or another I'd need to do anyway (consider what
would happen if I applied it to the debian package, then an upstream
release happened without it, I'd need to rebase it at that point). :)

> I'm not changing the fixed-upstream tag as the partial revert is
> already mentioned in the security-tracker notes and would've been
> reflected in the (removal of the) tag if it was necessary, right?

I actually just forgot to do it, while updating the sec tracker I didn't
check this bug status.


Thank you again for your patches!

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#889106: Multiarch interpreter names for traditional architectures

[Javier Serrano Polo]

Debian glibc officially supports multiarch interpreter names, even for
traditional architectures. For instance, the multiarch interpreter for
x86_64 is /lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 . There is
consensus among Debian-based distros.


smime.p7s
Description: S/MIME cryptographic signature

Bug#824383: gnome-software: packages not installed from repositories are claimed to be non-free

[Pelle Hjek]

Package: gnome-software
Version: 3.22.5-1
Followup-For: Bug #824383

Dear Maintainer,

Gnome Software reports Puredata as being proprietary. I've installed
Puredata from the Debian Stretch Backports repository, so not sure if
it's exactly the same bug.

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

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

Versions of packages gnome-software depends on:
ii  appstream0.10.6-2
ii  dconf-gsettings-backend [gsettings-backend]  0.26.0-2+b1
ii  gnome-software-common3.22.5-1
ii  gsettings-desktop-schemas3.22.0-1
ii  libappstream-glib8   0.6.8-1
ii  libatk1.0-0  2.22.0-1
ii  libc62.24-11+deb9u1
ii  libcairo-gobject21.14.8-1
ii  libcairo21.14.8-1
ii  libenchant1c2a   1.6.0-11+b1
ii  libfwupd10.7.4-2
ii  libgdk-pixbuf2.0-0   2.36.5-2+deb9u2
ii  libglib2.0-0 2.50.3-2
ii  libgnome-desktop-3-123.22.2-1
ii  libgtk-3-0   3.22.11-1
ii  libgtkspell3-3-0 3.0.9-1
ii  libgudev-1.0-0   230-3
ii  libjson-glib-1.0-0   1.2.6-1
ii  libpackagekit-glib2-18   1.1.5-2
ii  libpango-1.0-0   1.40.5-1
ii  libpangocairo-1.0-0  1.40.5-1
ii  libpolkit-gobject-1-00.105-18
ii  libsecret-1-00.18.5-3.1
ii  libsoup2.4-1 2.56.0-2+deb9u1
ii  libsqlite3-0 3.16.2-5+deb9u1
ii  packagekit   1.1.5-2
ii  software-properties-gtk  0.96.20.2-1

gnome-software recommends no packages.

Versions of packages gnome-software suggests:
pn  fwupd  
pn  gnome-software-plugin-flatpak  
pn  gnome-software-plugin-limba

-- no debconf information

Bug#860995: Correction for CVE-2017-8054 patch (was: Bug#860995: libpodofo: CVE-2017-8054 fix tested in unstable chroot, PoC generator source attached)

[Matthias Brinke]

Hello Mattia,

> Mattia Rizzolo has written on 21 December 2017 at 22:54:
> 
> 
> Control: tag -1 patch
> 
> On Thu, Dec 21, 2017 at 04:55:00PM +0100, Matthias Brinke wrote:
>> I have simplified my fix for CVE-2017-8054 (stack overflow
>> by infinite recursion from loop in pages tree) and tested
>> it again in an unstable chroot (entered by sbuild from
>> ... snip ...
> 
> I could, but could you please send it upstream?
> The only way to interact with upstream is the podofo-users ML
> https://sourceforge.net/p/podofo/mailman/podofo-users/

There is a post on the podofo-users mailing list by zyx which
says that running test/unit/podofo-test a heap-use-after-free
bug was detected [1]. I've investigated that and implemented a
correction, which I tested with -fsanitize=address (ASan) in
a Debian sid chroot (up-to-date, mostly? minimal) through
sbuild (from jessie-backports), attached here. Only memory leaks
were detected, therefore the test log is not attached here, also
because it's 292 KiB large (many leaks, but that's OT here). As
far as I've already seen, the leaks seems to be elsewhere.

This patch is complete to add to the Debian package, so please
disregard the older (and incorrect) patch in this bug thread.

I'm sorry I'm answering only now, the divergence between the
package and the upstream svn repository (also through the partial
revert) presented some challenges in patch handling. Because of
this, the patch is also not for forwarding (it wouldn't apply there).

I'm not changing the fixed-upstream tag as the partial revert is
already mentioned in the security-tracker notes and would've been
reflected in the (removal of the) tag if it was necessary, right?

> 
> -- 
> regards,
>  Mattia Rizzolo
> 

Best regards, Matthias Brinke

[1] https://sourceforge.net/p/podofo/mailman/message/36215307/Description: Fix CVE-2017-8054, also avoiding use-after-free
  The recursive call in the case of the requested page index
  having an array has been removed to prevent possibility of
  stack overflow there, and replaced it by code setting the
  variable which had been modified in the new stack frame in
  the former revision, directly, after checking its validity.
  The second hunk inserts cycle detection for the parent list.
Author: Matthias Brinke 
Bug-Debian: https://bugs.debian.org/860995
Forwarded: not-needed
Last-Update: 2018-02-05
---
Index: src/doc/PdfPagesTree.cpp
===
--- libpodofo-0.9.5.orig/src/doc/PdfPagesTree.cpp
+++ libpodofo-0.9.5/src/doc/PdfPagesTree.cpp
@@ -34,6 +34,7 @@
 #include "PdfPagesTree.h"
 
 #include "base/PdfDefinesPrivate.h"
+#include 
 
 #include "base/PdfArray.h"
 #include "base/PdfDictionary.h"
@@ -478,7 +479,18 @@
 if( rVar.IsArray() ) 
 {
 // Fixes some broken PDFs who have trees with 1 element kids arrays
-return GetPageNodeFromArray( 0, rVar.GetArray(), rLstParents );
+// Recursive call removed to prevent stack overflow, replaced by:
+// all the following inside this conditional, plus restart looping
+const PdfArray & rVarArray = rVar.GetArray();
+if (rVarArray.GetSize() == 0)
+{
+PdfError::LogMessage( eLogSeverity_Critical, "Trying to access"
+" first page index of empty array" );
+return NULL;
+}
+PdfVariant rVarFirstEntry = rVarArray[0]; // avoids use-after-free
+rVar = rVarFirstEntry; // in this line (rVar-ref'd array is freed)
+continue;
 }
 else if( !rVar.IsReference() )
 {
@@ -502,6 +516,18 @@
 if( !pgObject->GetDictionary().HasKey( "Kids" ) )
 return NULL;
 
+if ( std::find( rLstParents.begin(), rLstParents.end(), pgObject )
+!= rLstParents.end() ) // cycle in parent list detected, fend
+{ // off security vulnerability CVE-2017-8054 (infinite recursion)
+std::ostringstream oss;
+oss << "Cycle in page tree: child in /Kids array of object "
+<< ( *(rLstParents.rbegin()) )->Reference().ToString()
+<< " back-references to object " << pgObject->Reference()
+.ToString() << " one of whose descendants the former is.";
+
+PODOFO_RAISE_ERROR_INFO( ePdfError_PageNotFound, oss.str() );
+}
+
 rLstParents.push_back( pgObject );
 rVar = *(pgObject->GetDictionary().GetKey( "Kids" ));
 } else {
--- libpodofo-0.9.5.orig/src/base/PdfError.cpp
+++ libpodofo-0.9.5/src/base/PdfError.cpp
@@ -60,6 +60,12 @@ PdfErrorInfo::PdfErrorInfo()
 {
 }
 
+PdfErrorInfo::PdfErrorInfo( int line, const char* pszFile, std::string sInfo )
+: m_nLine( line ), m_sFile( pszFile ? pszFile : "" ), m_sInfo( sInfo )
+{
+
+}
+
 PdfErrorInfo::PdfErrorInfo( int line, const char* pszFile, 

Bug#886944: python3-regex: unhandled symlink to directory conversion: /usr/share/doc/PACKAGE

[Nicholas D Steeves]

Hi Andreas and Sandro,

On Thu, Jan 11, 2018 at 05:04:13PM +0100, Andreas Beckmann wrote:
> Followup-For: Bug #886944
> Control: affects -1 + python-regex-dbg
> 
> Hi,
> 
> similar issue in python-regex-dbg:
> 
> 0m33.5s ERROR: FAIL: silently overwrites files via directory symlinks:
>   /usr/share/doc/python-regex-dbg/Features.html (python-regex-dbg) != 
> /usr/share/doc/python-regex/Features.html (python-regex)
> /usr/share/doc/python-regex-dbg -> python-regex
>   /usr/share/doc/python-regex-dbg/Features.rst.gz (python-regex-dbg) != 
> /usr/share/doc/python-regex/Features.rst.gz (python-regex)
> /usr/share/doc/python-regex-dbg -> python-regex
>   /usr/share/doc/python-regex-dbg/README (python-regex-dbg) != 
> /usr/share/doc/python-regex/README (python-regex)
> /usr/share/doc/python-regex-dbg -> python-regex
>   /usr/share/doc/python-regex-dbg/UnicodeProperties.txt.gz (python-regex-dbg) 
> != /usr/share/doc/python-regex/UnicodeProperties.txt.gz (python-regex)
> /usr/share/doc/python-regex-dbg -> python-regex
>   /usr/share/doc/python-regex-dbg/changelog.Debian.gz (python-regex-dbg) != 
> /usr/share/doc/python-regex/changelog.Debian.gz (python-regex)
> /usr/share/doc/python-regex-dbg -> python-regex
>   /usr/share/doc/python-regex-dbg/copyright (python-regex-dbg) != 
> /usr/share/doc/python-regex/copyright (python-regex)
> /usr/share/doc/python-regex-dbg -> python-regex
> 
> and probably python3-regex-dbg as well, although that does not get
> tested by piuparts as long as python3-regex fails.
> 
> 
> Andreas

I'll attempt to fix this evening, because if calibre is removed from
testing than my planned backport will be in jeopardy.  If I succeed
I'll prepare an NMU, but in any case I'll reply to this bug with my
results.

Cheers,
Nicholas


signature.asc
Description: PGP signature

Bug#889674: pari: Error ("unknown type 64") for galoissubfields on mips architectures

[Tobias Hansen]

On 02/05/2018 11:23 PM, Bill Allombert wrote:
> On Mon, Feb 05, 2018 at 06:05:50PM +0100, Tobias Hansen wrote:
>> On 02/05/2018 06:03 PM, Bill Allombert wrote:
>>> On Mon, Feb 05, 2018 at 05:35:12PM +0100, Tobias Hansen wrote:
 Source: pari
 Version: 2.9.4-1
 Severity: normal

 Hi there,

 one of the tests of cypari2 failed on the mips architectures (at least
 mips and mips64el) and the problem is in pari itself (this was on
 mips):
>> Cool. Yes it is, on all other architectures the test ran fine:
>>
>> https://buildd.debian.org/status/package.php?p=cypari2=experimental
> Some ieee754 operations give unexpected results:
>
> The attached program give on mipsel:
> a=inf ai=2147483647  b=-inf bi=2147483647
> while
> a=inf ai=-2147483648 b=-inf bi=-2147483648
> is expected (and seen on other plateforms).
>
> Cheers,

Where does it say that this is expected? I would say it's undefined. From the 
c0x standard:

When a finite value of real floating type is converted to an integer type other 
than _Bool, the fractional part is discarded (i.e., the value is truncated 
toward zero). If the value of the integral part cannot be represented by the 
integer type, the behavior is undefined.

http://c0x.coding-guidelines.com/6.3.1.4.html

Best, Tobias

Bug#889600: closed by Sven Hoexter <s...@timegate.de> (Re: Bug#889600: btrfsmaintenance/0.4-1~exp1 [I maintain the package])

[Nicholas D Steeves]

On Mon, Feb 05, 2018 at 08:51:14AM +, Debian Bug Tracking System wrote:
> On Sun, Feb 04, 2018 at 04:59:27PM -0500, Nicholas D Steeves wrote:
> > Package: sponsorship-requests
> > Severity: normal
> > 
> > Dear mentors,
> > 
> > I am looking for a sponsor for my package "btrfsmaintenance".
> > 
> > Dear Marc and Sven,
> > 
> > I have CCed you because you sponsored previous releases of this
> > package.
> 
> Hi Nicholas,
> build & uploaded.
> 
> Sven

Thank you Sven!


signature.asc
Description: PGP signature

Bug#679124: lintian: error on d/rules having dh_make templates

[Chris Lamb]

tags 679124 + pending
thanks

Fixed in Git, pending upload:

  
https://anonscm.debian.org/git/lintian/lintian.git/commit/?id=d0fec9183b5977fa8f5e0a779631bb140ee3415d


Regards,

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

Bug#839046: debootstrap: enable --merged-usr by default

[Holger Levsen]

On Mon, Feb 05, 2018 at 08:19:33PM +0100, Julien Cristau wrote:
> On Sat, Feb  3, 2018 at 09:16:40 +0100, Marco d'Itri wrote:
> > On Dec 23, md wrote:
> > > On Dec 20, Julien Cristau  wrote:
> > > > > This change was reverted in 1.0.87 as dpkg-shlibdeps didn't cope
> > > > > properly with a merged-usr system. Thus reopening this bug report for
> > > > > that version.
> > > > > 
> > > > > The dpkg-shlibdeps bugs has been fixed [1] in the mean time. So it 
> > > > > would
> > > > > be great if this bug report could be re-considered.
> > > > That'll be after stretch now.
> > > Stretch was been released long ago: please re-enable --merged-usr in 
> > > debootstrap.
> > There has not been any negative feedback, can we move on please?
> Is there buy-in from the dpkg maintainer?

cc:ing them.


-- 
cheers,
Holger


signature.asc
Description: PGP signature

Bug#889674: pari: Error ("unknown type 64") for galoissubfields on mips architectures

[Bill Allombert]

On Mon, Feb 05, 2018 at 06:05:50PM +0100, Tobias Hansen wrote:
> On 02/05/2018 06:03 PM, Bill Allombert wrote:
> > On Mon, Feb 05, 2018 at 05:35:12PM +0100, Tobias Hansen wrote:
> >> Source: pari
> >> Version: 2.9.4-1
> >> Severity: normal
> >>
> >> Hi there,
> >>
> >> one of the tests of cypari2 failed on the mips architectures (at least
> >> mips and mips64el) and the problem is in pari itself (this was on
> >> mips):
> 
> Cool. Yes it is, on all other architectures the test ran fine:
> 
> https://buildd.debian.org/status/package.php?p=cypari2=experimental

Some ieee754 operations give unexpected results:

The attached program give on mipsel:
a=inf ai=2147483647  b=-inf bi=2147483647
while
a=inf ai=-2147483648 b=-inf bi=-2147483648
is expected (and seen on other plateforms).

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 
#include 
int
main(void)
{
  double a = 1./0.;
  long ai = (long) a;
  double b = -a;
  long bi = (long) b;
  printf("a=%g ai=%ld b=%g bi=%ld\n",a,ai,b,bi);
}

Bug#820770: Bug#889640: lintian: init.d-script-possible-missing-stop misfire on rcS scripts

[Chris Lamb]

tags 820770 + moreinfo
thanks


Hi Ron and Felipe,

Hm, are #820770 and #889640 the same issue? If so, we should either
close them both or reopen both of them.


Regards,

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

Bug#889102: [lintian] Please detect source missing .wasm file

[Chris Lamb]

tags 889102 + pending
thanks

This was fixed by Bastien in:

  
https://anonscm.debian.org/git/lintian/lintian.git/commit/?id=740e6738e364f18662264d5cdd14552bc869a54b


Regards,

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

Bug#884247: Debian Bug #884247 - linphone with upnp 1.8 - patch.

[Uwe Kleine-König]

Hello,

On 02/05/2018 08:08 PM, Sebastian Ramacher wrote:
>> I am using Slackware.
>>
>> Bye, Robert
> 
>>mbedtls 2.6.1libraries/mbedtls
>>   mbedtls-2.6.1-i586-1_SBo
>>  bctoolbox 0.6.0libraries/bctoolbox  
>>   bctoolbox-0.6.0-i586-1_SBo
>>  mbedtls 2.6.1  libraries/mbedtls
>>   mbedtls-2.6.1-i586-1_SBo
>>bctoolbox 0.6.0  libraries/bctoolbox  
>>   bctoolbox-0.6.0-i586-1_SBo
>>jdk 8u162development/jdk  
>>   jdk-7u80-i586-1
>>libantlr3c 3.4   libraries/libantlr3c 
>>   libantlr3c-3.4-i486-1_SBo
>>mbedtls 2.6.1libraries/mbedtls
>>   mbedtls-2.6.1-i586-1_SBo
>>  belle-sip 1.6.3libraries/belle-sip  
>>   belle-sip-1.6.3-i586-1_SBo
>>  mbedtls 2.6.1  libraries/mbedtls
>>   mbedtls-2.6.1-i586-1_SBo
>>bctoolbox 0.6.0  libraries/bctoolbox  
>>   bctoolbox-0.6.0-i586-1_SBo
>>mbedtls 2.6.1libraries/mbedtls
>>   mbedtls-2.6.1-i586-1_SBo
>>  bzrtp 1.0.6libraries/bzrtp  
>>   bzrtp-1.0.6-i586-1_SBo
>>  ffmpeg 3.2.4   multimedia/ffmpeg
>>   ffmpeg-2.6.8-i686_custom-1_SBo
>>  libsrtp 1.6.0  libraries/libsrtp
>>   libsrtp-1.6.0-i586-1_SBo
>>  libupnp 1.8.3  libraries/libupnp
>>   libupnp-1.8.3-i586-1_SBo
>>  mbedtls 2.6.1  libraries/mbedtls
>>   mbedtls-2.6.1-i586-1_SBo
>>  speex 1.2.0audio/speex  
>>   speex-1.2.0-i486-1_SBo
>>linphone 3.12.0  network/linphone 
>>   linphone-3.12.0-i586-1_SBo
>>x264 20170225multimedia/x264  
>>   x264-20131101-i486-2_SBo
>>  msx264 1.5.3   libraries/msx264 
>>   msx264-1.5.3-i586-1_SBo
> 
>> diff --git a/linphone-3.12.0/mediastreamer2/src/upnp/upnp_igd.c 
>> b/linphone-3.12.0/mediastreamer2/src/upnp/upnp_igd.c
>> index 4f7d161..cee436c 100644
>> --- a/linphone-3.12.0/mediastreamer2/src/upnp/upnp_igd.c
>> +++ b/linphone-3.12.0/mediastreamer2/src/upnp/upnp_igd.c
>> @@ -395,7 +395,7 @@ int upnp_igd_send_action(upnp_igd_context* igd_ctxt, 
>> upnp_igd_device_node *devic
>>   *   d_event  -- event associated with the new device
>>   *
>>   
>> /
>> -void upnp_igd_add_device(upnp_igd_context *igd_ctxt, IXML_Document 
>> *desc_doc, struct Upnp_Discovery *d_event) {
>> +void upnp_igd_add_device(upnp_igd_context *igd_ctxt, IXML_Document 
>> *desc_doc, UpnpDiscovery *d_event) {
>>  upnp_igd_device_node *deviceNode, *tmpdevnode;
>>  int found = 0;
>>  int ret;
>> @@ -423,7 +423,7 @@ void upnp_igd_add_device(upnp_igd_context *igd_ctxt, 
>> IXML_Document *desc_doc, st
>>  baseURL = upnp_igd_get_first_document_item(igd_ctxt, desc_doc, 
>> "URLBase");
>>  relURL = upnp_igd_get_first_document_item(igd_ctxt, desc_doc, 
>> "presentationURL");
>>  
>> -ret = UpnpResolveURL((baseURL ? baseURL : d_event->Location), relURL, 
>> presURL);
>> +ret = UpnpResolveURL((baseURL ? baseURL : 
>> UpnpString_get_String(UpnpDiscovery_get_Location(d_event))), relURL, 
>> presURL);

The third parameter to the ?: operator can be simplified to:

UpnpDiscovery_get_Location_cstr(d_event)

>>  if (UPNP_E_SUCCESS != ret) {
>>  upnp_igd_print(igd_ctxt, UPNP_IGD_ERROR, "Error generating 
>> presURL from %s + %s", baseURL, relURL);
>> @@ -444,7 +444,7 @@ void upnp_igd_add_device(upnp_igd_context *igd_ctxt, 
>> IXML_Document *desc_doc, st
>>  if (found) {
>>  /* The device is already there, so just update  
>> */
>>  /* the advertisement timeout field */
>> -tmpdevnode->device.advr_time_out = 
>> d_event->Expires;
>> +tmpdevnode->device.advr_time_out = 
>> UpnpDiscovery_get_Expires(d_event);
>>

Bug#844125: dgit: Built-in support for pbuilder [and 1 more messages]

[Mattia Rizzolo]

On Mon, Feb 05, 2018 at 02:27:50PM -0700, Sean Whitton wrote:
> I would suggest that we require the user to pass/set
> --build-products-dir rather than adding all the parsing code to dgit.

FTR, I agree.
Especially if you make it configurable instead of forcing a cli flag.

-- 
regards,
Mattia Rizzolo

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

Bug#889097: nvidia-libopencl1: Missing NVidia OpenCL platform

[Krzysztof Marczak]

Module loading mechanism seem to be working properly.
I have tested it as you described:

$ sudo modprobe -r nvidia
$ lsmod | grep nvidia   # there was no output
$ sudo nvidia-modprobe -u
$ lsmod | grep nvidia  #returned folowing:

nvidia_uvm765952  0
nvidia  13168640  1 nvidia_uvm

It loaded nvidia_uvm as it should be.
After that I started sddm and tested OpenCL. It worked properly (like after
sudo clinfo).
So the problem is somewhere else.


2018-02-05 6:01 GMT+01:00 Andreas Beckmann :

> Control: tag -1 moreinfo
>
> On 2018-02-02 17:19, Krzysztof Marczak wrote:
> > Thank you for quick reply.
> > You were right. It's look like it's the same problem as reported in
> #888952
> > When after reboot I don't run clinfo as a root, the NVidia OpenCL
> platform
> > is not visible. After running 'sudo clinfo' it starts to work properly.
> > It's reproducible all the time.
> I cannot reproduce the problem here. (Tried the 384.111 driver from
> stretch-backports, using both ocl-icl-libopencl1 and nvidia-libopencl1.
> Only possible difference is that I'm running a rather old non-distro
> kernel for unrelated reasons.)
>
> But it should be easy for you to test the module loading mechanism,
> assuming you don't have X running using the nvidia driver:
>
> $ sudo modprobe -r nvidia   # unload all nvidia modules
> $ lsmod | grep nvidia   # expect no output
> $ nvidia-modprobe -u# NVIDIA's setuid root helper
> $ lsmod | grep nvidia   # expect nvidia and nvidia-uvm
>
> If that doesn't work for you, the setuid helper nvidia-modprobe is not
> working properly on your system
>
> $ ls -la /usr/bin/nvidia-modprobe
>
> should print
>
> -rwsr-xr-x 1 root root ...
>^ 
>
>
> Andreas
>

Bug#863520: cyrus-imapd version 2.5.10-3 Fatal error with SSL

[Philip Iezzi]

Dear maintainer,

I would greatly appreciate if you could push this fix into current Debian 
Stretch. The problem still persists in Cyrus-imapd 2.5.10-3 and above patch 
from upstream fixes it. After having upgraded a mailserver to Debian Stretch we 
had a massive amount of negative customer feedback complaining about dropped 
connections.

The patched and recompiled packages are now running for more than 2 weeks on 
two rather busy mail servers (datenpark.ch / onlime.ch) and all trouble has 
gone away, cyrus-imapd works stable again.

Thanks Vladislav for your great support!

Here's a short howto for people who never built a Deb package before:

$ apt-get source cyrus-imapd
$ wget 
https://github.com/cyrusimap/cyrus-imapd/commit/a1c917df8de04e108228f38f0010498bec3d81e8.patch
 -O cyrus-imapd-issue1872.patch 
$ cd cyrus-imapd-2.5.10/
$ patch -p1 < ../cyrus-imapd-issue1872.patch
$ apt-get build-dep cyrus-imapd
$ dpkg-buildpackage -b
$ cd ../

# install at least the following and put those packages on hold:
$ dpkg -i cyrus-common_2.5.10-3_amd64.deb cyrus-imapd_2.5.10-3_amd64.deb 
cyrus-pop3d_2.5.10-3_amd64.deb libcyrus-imap-perl_2.5.10-3_amd64.deb
$ echo cyrus-common hold | dpkg --set-selections
$ echo cyrus-imapd hold | dpkg --set-selections
$ echo cyrus-pop3d hold | dpkg --set-selections
$ echo libcyrus-imap-perl hold | dpkg --set-selections

# check package state
$ dpkg --get-selections | grep cyrus | grep -v deinstall

This fixes the issue and the "lib/cyrusdb_twoskip.c" fatal errors no longer pop 
up in mail.log

Best regards,
Philip

Bug#809762: lasso: Here's a patch to enable tests during build

[Corey Bryant]

Package: lasso
Version: 2.5.0-5
Followup-For: Bug #809762
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu bionic ubuntu-patch

Dear Maintainer,

In Ubuntu, the attached patch was applied to achieve the following:

  * d/control, d/rules: Enable test execution during build.


Thanks for considering the patch.


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

Kernel: Linux 4.13.0-32-generic (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
diff -Nru lasso-2.5.0/debian/control lasso-2.5.0/debian/control
--- lasso-2.5.0/debian/control  2017-11-02 01:36:18.0 -0400
+++ lasso-2.5.0/debian/control  2018-02-05 16:26:12.343664245 -0500
@@ -5,6 +5,7 @@
 XSBC-Original-Maintainer: Frederic Peters 
 Build-Depends: debhelper (>= 8),
 dh-python,
+liberror-perl,
 libxml2-dev,
 libxslt1-dev,
 libxmlsec1-dev,
diff -Nru lasso-2.5.0/debian/control.in lasso-2.5.0/debian/control.in
--- lasso-2.5.0/debian/control.in   2017-11-02 01:36:18.0 -0400
+++ lasso-2.5.0/debian/control.in   2018-02-05 16:22:17.942022704 -0500
@@ -5,6 +5,7 @@
 XSBC-Original-Maintainer: Frederic Peters 
 Build-Depends: debhelper (>= 8),
 dh-python,
+liberror-perl,
 libxml2-dev,
 libxslt1-dev,
 libxmlsec1-dev,
diff -Nru lasso-2.5.0/debian/rules lasso-2.5.0/debian/rules
--- lasso-2.5.0/debian/rules2016-05-05 05:08:20.0 -0400
+++ lasso-2.5.0/debian/rules2018-02-05 16:16:35.782381565 -0500
@@ -99,6 +99,9 @@
  $(MAKE) -C bindings/python$$v; \
done
 
+   # Run tests
+   $(MAKE) check
+
touch build-stamp
 
 clean:

Bug#887933: src:nose2: Provide a binary package for PyPy

[Pierre-Elliott Bécue]

Le lundi 05 février 2018 à 19:50:02+, Ghislain Vaillant a écrit :
> Can you build a pypy-nose2 package for pypy, in addition to the current binary
> packages for Python 2 (python-nose2) and Python 3 (python3-nose2).
> 
> Thanks,

I can't, as nose2 depends on mock which is not pypy-packaged.

Sorry,

-- 
Pierre-Elliott Bécue
GPG: 9AE0 4D98 6400 E3B6 7528  F493 0D44 2664 1949 74E2


signature.asc
Description: PGP signature

Bug#879741: phpmyadmin help

[Aman Soni]

Hi,



I'm not currently a Debian contributor however it's something that I want to 
get involved in. I've used the tool for several years, and have done a fair 
amount of PHP development for WordPress and Drupal. Please let me know if you 
think that I would be suitable? If so, where should I start on getting 
registered with the Debian development community?



Regards,

Aman Soni

http://amansoni.com

Bug#889689: pytest-arraydiff: Incomplete debian/copyright?

[Chris Lamb]

Source: pytest-arraydiff
Version: 0.2-1
Severity: serious
Justication: Policy 12.5
X-Debbugs-CC: Ole Streicher 

Hi,

I just ACCEPTed pytest-arraydiff from NEW but noticed it was missing 
attribution in debian/copyright for at least src/jsonrpc-version-macros.h.

(This is not exhaustive so please check over the entire package 
carefully and address these on your next upload.)


Regards,

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

Bug#879053: pygoocanvas can be removed now

[Dr. Tobias Quathamer]

control: tag -1 - moreinfo

Dear FTP masters,

I've just uploaded a new version of openshot, removing the last reverse
dependency of pygoocanvas. I think the package can now safely be removed.

Regards,
Tobias



signature.asc
Description: OpenPGP digital signature

Bug#844125: dgit: Built-in support for pbuilder [and 1 more messages]

[Sean Whitton]

Hello,

On Mon, Feb 05 2018, Ian Jackson wrote:

> Sean Whitton writes ("Re: Bug#844125: dgit: Built-in support for
>pbuilder [and 1 more messages]"):
>> I haven't yet read your older mail where you came to the conclusion
>> that it would be necessary for dgit to parse pbuilder's config, but
>> we should be really sure it's necessary before going for that.
>
> I don't think there was a mail.  I looked for it but couldn't find it.
> Nor does my blather in ad-hoc git commits explain.  My best guess now
> is that I wanted dgit to honour pbuilder's build area configuration.
> Let us proceed on that assumption, and therefore take your advice.

I would suggest that we require the user to pass/set
--build-products-dir rather than adding all the parsing code to dgit.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#847280: qpdfview: Debian version is 3 releases behind, missing important features

[sfr...@gmail.com]

Dear Maintainer,

this problem is still valid and leads to not being able to open djvu
files (of course the djvu plugin is installed). Please consider to
update to a newer version.

Thank you.

On Tue, 06 Dec 2016 13:57:37 -0800 Nemo Inis  wrote:
> Package: qpdfview
> Version: 0.4.14-1
> Severity: important
> 
> Dear Maintainer,
> 
> qpdfview 0.4.17 has been released. Could we replace the 0.4.14 version we have
> in Debian?
> 
> Thanks for great work!
> 
> 
> 
> -- System Information:
> Debian Release: stretch/sid
>   APT prefers testing
>   APT policy: (500, 'testing')
> Architecture: i386 (i686)
> 
> Kernel: Linux 4.7.0-1-686-pae (SMP w/4 CPU cores)
> Locale: LANG=en_US.utf8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> 
> Versions of packages qpdfview depends on:
> ii  hicolor-icon-theme0.15-1
> ii  libc6 2.24-5
> ii  libcups2  2.2.1-2
> ii  libgcc1   1:6.2.0-13
> ii  libgl1-mesa-glx [libgl1]  12.0.4-2
> ii  libpoppler-qt5-1  0.48.0-2
> ii  libqt5concurrent5 5.7.1~20161021+dfsg-6
> ii  libqt5core5a  5.7.1~20161021+dfsg-6
> ii  libqt5dbus5   5.7.1~20161021+dfsg-6
> ii  libqt5gui55.7.1~20161021+dfsg-6
> ii  libqt5printsupport5   5.7.1~20161021+dfsg-6
> ii  libqt5sql55.7.1~20161021+dfsg-6
> ii  libqt5sql5-sqlite 5.7.1~20161021+dfsg-6
> ii  libqt5svg55.7.1~20161021-2
> ii  libqt5widgets55.7.1~20161021+dfsg-6
> ii  libqt5xml55.7.1~20161021+dfsg-6
> ii  libstdc++66.2.0-13
> ii  zlib1g1:1.2.8.dfsg-2+b3
> 
> Versions of packages qpdfview recommends:
> pn  qpdfview-djvu-plugin   
> pn  qpdfview-ps-plugin 
> pn  qpdfview-translations  
> 
> qpdfview suggests no packages.
> 
> -- no debconf information
> 
> 

Bug#889158: Package wine-development is less recent than wine

[Jens Reyer]

On 02/02/2018 08:10 PM, Joerg Schiermeier, Bielefeld/Germany wrote:
> the package version of 'wine-development' is lower than the version of 
> 'normal' wine:
> 
> wine-development: 3.0~rc6-1
> wine: 3.0-1
> 
> Since January 18th, 2018 until today the WineHQ versions were set to v3.0. 
> This was the version from their stable wine and also from their developer 
> version of wine.
> So this should also be in Debians package 'wine' and 'wine-development'! The 
> version of 'wine-development' has to be minimum the version of 'wine' and not 
> below. This is what the prefix '-development' means. Or not? Maybe I'm wrong.
> And: No, I didn't want to change the packages in my installation from 
> 'wine-development' to 'wine' for this period of same version between WinHQs 
> 'Wine stable release' and WineHQs 'Wine development release'
> 
> So this is a bug.

No.  Latest is not the same as development.  I didn't see 3.0 offered
upstream as -development (at least it's not in
https://dl.winehq.org/wine/source/3.x/), but that wouldn't change my mind.

And because of the duplication I definitely won't package stable 3.0
also as src:wine-development.

An exception to my first point might be if the stable upstream release
is too late in the Debian release cycle, so that src:wine gets the
previous stable, and src:wine-development the current stable release -
but currently we're just in the middle of the release cycle.

I'm just packaging 3.1 which will close this bug anyway.  If you just
wanted to request that version packaged: 36 minutes after its release is
a bit early.  But you're interest in wine-development is appreciated!

Greets
jre

Bug#781909: NMU dropping python-zeitgeist package

[Jeremy Bicha]

After discussing this with ricotz a bit more, it looks like we can
build this with python3 instead. I intend to NMU this as soon as vala
0.38 is in unstable (as soon as tomorrow). python3-zeitgeist will need
to go through the NEW queue.

Updated patches attached.

Thanks,
Jeremy Bicha
From 8ebac33bdb02ea78ee671944d1e832417608104a Mon Sep 17 00:00:00 2001
From: Jeremy Bicha 
Date: Mon, 5 Feb 2018 15:56:02 -0500
Subject: [PATCH 1/3] Switch python-zeitgeist to python3-zeitgeist

Closes: #781909
---
 debian/changelog   |  7 +++
 debian/control | 18 --
 ...hon-zeitgeist.install => python3-zeitgeist.install} |  0
 debian/rules   |  4 +++-
 4 files changed, 18 insertions(+), 11 deletions(-)
 rename debian/{python-zeitgeist.install => python3-zeitgeist.install} (100%)

diff --git a/debian/changelog b/debian/changelog
index de65579..f815f88 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+zeitgeist (1.0-0.2) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Switch python-zeitgeist to python3-zeitgeist (Closes: #781909)
+
+ -- Jeremy Bicha   Mon, 05 Feb 2018 15:54:49 -0500
+
 zeitgeist (1.0-0.1) unstable; urgency=medium
 
   [ Jeremy Bicha ]
diff --git a/debian/control b/debian/control
index 8806363..f8d21bb 100644
--- a/debian/control
+++ b/debian/control
@@ -15,9 +15,9 @@ Build-Depends: debhelper (>= 10),
  libsqlite3-dev (>= 3.7.11),
  libtelepathy-glib-dev (>= 0.18.0),
  libxapian-dev,
- python-all (>= 2.6.6-3~),
+ python3-all (>= 2.6.6-3~),
  python-gi,
- python-rdflib,
+ python3-rdflib,
  raptor2-utils,
  valac (>= 0.22),
  valadoc
@@ -25,13 +25,12 @@ Homepage: http://zeitgeist-project.com/
 Standards-Version: 4.1.1
 Vcs-Git: https://anonscm.debian.org/git/collab-maint/zeitgeist.git
 Vcs-Browser: https://anonscm.debian.org/git/collab-maint/zeitgeist.git
-X-Python-Version: >= 2.6
 
 Package: zeitgeist
 Architecture: all
 Depends: ${misc:Depends},
  zeitgeist-core,
- python-zeitgeist,
+ python3-zeitgeist,
  zeitgeist-datahub
 Description: event logging framework
  Zeitgeist is a service which logs the user's activities and events (files
@@ -63,15 +62,14 @@ Description: event logging framework - engine
  codenamed "Bluebird"). It also includes the FTS (Full Text Search)
  extension.
 
-Package: python-zeitgeist
+Package: python3-zeitgeist
 Architecture: all
 Section: python
 Depends: ${misc:Depends},
- ${python:Depends},
- python-xdg,
- python-dbus,
- python-gobject-2,
- python-gi
+ ${python3:Depends},
+ python3-xdg,
+ python3-dbus,
+ python3-gi
 Replaces: zeitgeist-core (<< 0.8.99~alpha1)
 Breaks: zeitgeist-core (<< 0.8.99~alpha1)
 Description: event logging framework - Python bindings
diff --git a/debian/python-zeitgeist.install b/debian/python3-zeitgeist.install
similarity index 100%
rename from debian/python-zeitgeist.install
rename to debian/python3-zeitgeist.install
diff --git a/debian/rules b/debian/rules
index 7e8eb77..8ea99ab 100755
--- a/debian/rules
+++ b/debian/rules
@@ -1,7 +1,9 @@
 #!/usr/bin/make -f
 
+export PYTHON=python3
+
 %:
-	dh $@ --with python2,gir
+	dh $@ --with python3,gir
 
 override_dh_auto_configure:
 	dh_auto_configure -- --libexecdir=/usr/lib/zeitgeist \
-- 
2.15.1

From 323e8d910f3a8d69ed99bef9b4d81a295e4cdb98 Mon Sep 17 00:00:00 2001
From: Jeremy Bicha 
Date: Sun, 4 Feb 2018 17:48:17 -0500
Subject: [PATCH 2/3] Use Launchpad site as homepage (LP: #1744536)

---
 debian/control | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/control b/debian/control
index f8d21bb..4b71432 100644
--- a/debian/control
+++ b/debian/control
@@ -21,7 +21,7 @@ Build-Depends: debhelper (>= 10),
  raptor2-utils,
  valac (>= 0.22),
  valadoc
-Homepage: http://zeitgeist-project.com/
+Homepage: https://launchpad.net/zeitgeist-project
 Standards-Version: 4.1.1
 Vcs-Git: https://anonscm.debian.org/git/collab-maint/zeitgeist.git
 Vcs-Browser: https://anonscm.debian.org/git/collab-maint/zeitgeist.git
-- 
2.15.1

From a31e7cb36e768a75b916f7a2a1cfa84edfae15a2 Mon Sep 17 00:00:00 2001
From: Jeremy Bicha 
Date: Mon, 5 Feb 2018 16:06:12 -0500
Subject: [PATCH 3/3] releasing package zeitgeist version 1.0-0.2

---
 debian/changelog | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/debian/changelog b/debian/changelog
index f815f88..2d9affa 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,9 +1,10 @@
-zeitgeist (1.0-0.2) UNRELEASED; urgency=medium
+zeitgeist (1.0-0.2) unstable; urgency=medium
 
   * Non-maintainer upload.
   * Switch python-zeitgeist to python3-zeitgeist (Closes: #781909)
+  * Use Launchpad site as homepage (LP: #1744536)
 
- -- Jeremy Bicha   Mon, 05 Feb 2018 15:54:49 -0500
+ -- Jeremy Bicha   Mon, 05 Feb 2018 16:05:52 -0500
 
 zeitgeist (1.0-0.1) unstable; 

Bug#888952: nvidia-driver and opencl

[Pascal Obry]

Andreas,

> Are there any hardening settings enabled on your system that could
> prevent this setuid executable from doing its job?
> * filesystems mounted with option nosuid
> * apparmor
> * selinux
> ...

Yes apparmor is installed.

> BTW, which version of the nvidia-modprobe package do you have
> installed?

Latest version:

$ apt-cache policy nvidia-modprobe
nvidia-modprobe:
  Installed: 384.111-1
  Candidate: 384.111-1
  Version table:
 *** 384.111-1 750
700 http://ftp.fr.debian.org/debian testing/contrib amd64 Packages
750 http://ftp.fr.debian.org/debian unstable/contrib amd64 Packages
100 /var/lib/dpkg/status
 375.26-1 650
650 http://ftp.fr.debian.org/debian stable/contrib amd64 Packages

Current nvidia driver in sid is 384.111-4.

Thanks,

-- 
  Pascal Obry /  Magny Les Hameaux (78)

  The best way to travel is by means of imagination

  http://www.obry.net

  gpg --keyserver keys.gnupg.net --recv-key F949BD3B

Bug#877450: RFS: bash-completion/1:2.7-1 [ITA]

[Juhani Numminen]

Gabriel F. T. Gomes kirjoitti 04.02.2018 klo 23:05:
> On 03 Feb 2018, Juhani Numminen wrote:
>
>> Instead of doing version parsing the hard way, could you perhaps
>> include /usr/share/dpkg/pkg-info.mk and use a suitable variable that
>> it defines?
> 
> Indeed, but you also made me realize that the manpage was not being
> re-generated, because the output (dh_bash-completion.1) was versioned
> and not listed as a target dependency on debian/rules.
> 
> What do you think of the following change:
>...

I think you will also need to clean up the generated file, e.g. put it
into debian/clean.


Regards,
Juhani

Bug#889687: nut-client: upsmon error: Unable to call shutdown command

[Thomas]

Package: nut-client
Version: 2.7.4-5.1+b1
Severity: normal
Tags: patch

Dear Maintainer,

Description
===
I had a power failure last week and upsmon tried correctly to shutdown
the system. This did not work.

During the process I got first on all terminals the wall message:
> Executing automatic power-fail shutdown 

And at the same time in syslog:
> upsmon[2965]: Auto logout and shutdown proceeding

5 seconds later I have gotten in syslog:
> upsmon[2963]: parent: Unable to call shutdown command: /sbin/shutdown -P +0

and the shutdown was never started.

Investigation
=
The package nut-client comes preconfigured in /etc/nut/upsmon.conf with
SHUTDOWNCMD "/sbin/shutdown -P +0"

If I run this command as root at the command line I get:
> shutdown: -H and -P flags can only be used along with -h flag.

Solution

I added "-h" to the SHUTDOWNCMD and the problem is gone.
SHUTDOWNCMD "/sbin/shutdown -h -P +0"

Kindly adjust the default upsmon.conf.

Thanks!
Thomas

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

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

Versions of packages nut-client depends on:
ii  adduser3.116
ii  libc6  2.26-4
ii  libupsclient4  2.7.4-5.1+b1
ii  lsb-base   9.20170808

Versions of packages nut-client recommends:
ii  bash-completion  1:2.1-4.3

Versions of packages nut-client suggests:
pn  nut-monitor  

-- Configuration Files:
/etc/nut/nut.conf [Errno 13] Permission denied: '/etc/nut/nut.conf'
/etc/nut/upsmon.conf [Errno 13] Permission denied: '/etc/nut/upsmon.conf'
/etc/nut/upssched.conf [Errno 13] Permission denied: '/etc/nut/upssched.conf'

-- no debconf information

Bug#814601: chm2pdf: TypeError - doesn't work at all

[sageg]

Package: chm2pdf
Version: 0.9.1-1.2
Followup-For: Bug #814601

Dear Maintainer,

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

Versions of packages chm2pdf depends on:
ii  htmldoc 1.8.27-9
ii  libchm-bin  2:0.40a-4
ii  python  2.7.14-4
ii  python-chm  0.8.4.1-1

chm2pdf recommends no packages.

Versions of packages chm2pdf suggests:
pn  python-beautifulsoup  

-- no debconf information

Bug#889686: nbdkit build-depends on various kernel images

[Matthias Klose]

Package: src:nbdkit
Version: 1.1.28-2
Severity: minor

nbdkit build-depends on various kernel images, however I don't see yet a reason
why it should, and I cannot find anything in the debian changelog.  Please could
you document why it needs the kernel images for the build?

Bug#889685: krb5: CVE-2018-5710

[Salvatore Bonaccorso]

Source: krb5
Version: 1.16-2
Severity: important
Tags: security upstream

Hi,

the following vulnerability was published for krb5, filling a bug to
track the issue once more details are available.

CVE-2018-5710[0]:
| An issue was discovered in MIT Kerberos 5 (aka krb5) through 1.16. The
| pre-defined function "strlen" is getting a "NULL" string as a parameter
| value in plugins/kdb/ldap/libkdb_ldap/ldap_principal2.c in the Key
| Distribution Center (KDC), which allows remote authenticated users to
| cause a denial of service (NULL pointer dereference) via a modified
| kadmin client.

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-5710
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-5710

Please adjust the affected versions in the BTS as needed, once known.

Regards,
Salvatore 

Bug#889684: krb5: CVE-2018-5709

[Salvatore Bonaccorso]

Source: krb5
Version: 1.16-2
Severity: important
Tags: security upstream

Hi,

the following vulnerability was published for krb5, filling a bug to
track the issue once more details are available.

CVE-2018-5709[0]:
| An issue was discovered in MIT Kerberos 5 (aka krb5) through 1.16.
| There is a variable "dbentry-n_key_data" in kadmin/dbutil/dump.c that
| can store 16-bit data but unknowingly the developer has assigned a "u4"
| variable to it, which is for 32-bit data. An attacker can use this
| vulnerability to affect other artifacts of the database as we know that
| a Kerberos database dump file contains trusted data.

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-5709
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-5709

Please adjust the affected versions in the BTS as needed, once known.

Regards,
Salvatore

Bug#889680: git: CVE-2018-1000021: client prints server sent ANSI escape codes to the terminal, allowing for unverified messages to potentially execute arbitrary commands

[Jonathan Nieder]

+cc: upstream
Hi,

Salvatore Bonaccorso wrote[1]:

> the following vulnerability was published for git.
>
> CVE-2018-121[0]:
> |client prints server sent ANSI escape codes to the terminal, allowing
> |for unverified messages to potentially execute arbitrary commands
>
> Creating this bug to track the issue in the BTS. Apparently the CVE
> was sssigned without notifying/discussing it with upstream, at least
> according to [1].
>
> 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-121
> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-121
> [1] https://bugzilla.novell.com/show_bug.cgi?id=1079389#c1

Thanks.  Upstream was notified about this and we dropped the ball on
passing it on to a more public forum.  Sorry about that.

I'd be interested in your advice on this.  There are cases where the
user may *want* ANSI escape codes to be passed through without change
and other cases where the user doesn't want that.  Commands like "git
diff" pass their output through a pager by default, which itself may
or may not sanitize the output.

In other words, there are multiple components at play:

 1. A terminal.  IMHO, it is completely inexcusable these days for a
terminal to allow arbitrary code execution by writing output to
it.  If bugs of that kind still exist, I think we should fix them
(and perhaps even make it a requirement in Debian policy to make
the expectations clear for new terminals).

That said, for defense in depth, it can be useful to also guard
against this kind of issue in other components.  In particular:

 2. A pager.  Are there clear guidelines for what it is safe and not
safe for a pager to write to a terminal?

"less -R" tries to only allow ANSI "color" escape sequences
through but I wouldn't be surprised if there are some cases it
misses.

 3. Output formats.  Some git commands are designed for scripting
and do not have a sensible way to sanitize their output without
breaking scripts.  Fortunately, in the case of "git diff", git
has a notion of a "binary patch" where everything is sanitized,
at the cost of the output being unreadable to a human (email-safe
characters but not something that a human can read at a glance).
So if we know what sequences to avoid writing to stdout, then we
can treat files with those sequences as binary.

Pointers welcome.

Thanks,
Jonathan

[1] https://bugs.debian.org/889680

Bug#530584: mutt: should use /var/tmp for mail drafts by default

[Nicholas D Steeves]

Hi Antonio,

On Tue, Jun 27, 2017 at 06:47:54AM +, Antonio Radici wrote:
> Control: tags -1 + pending
> 
> Time to revisit this bug, probably worth changing the default at this point.

What is the status of this bug now?  I've lost enough drafts due to my
laptop's acpi not triggering a "low battery, hibernate NOW!" that I've
lost count...and am now looking into how best to configure where mutt
stores WIP drafts.

Wouldn't the least disruptive way to do this be to set compose dir on
stable storage only when mutt is started without '-F config' or when
~/.muttrc does not exist?  That way existing users are not affected
and new users never experience the nasty surprise of lost drafts.

Cheers,
Nicholas

Bug#888062: pocl: FTBFS on arm64: test_fabs and test_shuffle_{char, ..., float} fail

[Punit Agrawal]

On Mon, Feb 5, 2018 at 4:15 PM, Andreas Beckmann  wrote:

> But could you first try, whether the exact same problem occurs if you
> build pocl from the pristine upstream tarball with the default
> configuration options and run the tests there? Just to make sure it is
> not caused^Wuncovered by my configuration settings and patches.
> This will be a the equivalent of a -march=native build for your hardware ...

I've found the same behaviour in the debian package as well as when
using a clone of the upstream repo.

Bug#889640: lintian: init.d-script-possible-missing-stop misfire on rcS scripts

[Ron]

On Mon, Feb 05, 2018 at 08:48:57PM +0530, Chris Lamb wrote:
> tags 889640 + moreinfo
> thanks
> 
> Hi Ron,
> 
> >  # Default-Start: S
> >  # Default-Stop:  0 6
> > 
> > Will cause lintian to complain about it not being stopped in runlevel 1,
> > with a rationale that would be fine for services started in 2-5, but that
> > doesn't really apply for things which can be shut down in an orderly way
> > but shouldn't be just because you're switching to or entering runlevel 1.
> 
> Getcha. I'm not an runlevel expert, but do you suggest we don't emit
> this tag at all for scripts that /include/ 'S' in Default-Start or for
> ones that /only/ have 'S' (ie. "Default-Start: S")

Ok, so this one turns out to be a little more convoluted than I always
understood it to be ...

The rcS runlevel is/was used for things which need to be started early
in the boot sequence, regardless of which runlevel the system was going
to enter.  Ostensibly the 'S' stands for 'single user', but there's a
fuzzy overlap in that particular role as rc1 is also a/the single user
mode runlevel (but rc1 scripts only get invoked when explicitly entering
or leaving runlevel 1) ...

With that in mind, for something started in rcS, there's usually only
two sensible behaviours for when it should be stopped.  It may be a
one-shot task, which runs at early boot then exits, so it never needs
to be stopped, or it sets up or runs something which shouldn't be
explicitly stopped before the CPU itself is halted or rebooted - for
both those cases nothing would be specified for Default-Stop.

Alternatively, it does start some long-running early boot service, which
can and should be explicitly shut down in an orderly way when the system
is being halted (0) or rebooted (6).  But which should remain running in
single user mode (S/1).

In line with that, every rcS script I recall ever looking at (and all
the ones still on the machines I checked here), used either:

  # Default-Start: S
  # Default-Stop:  0 6
or
  # Default-Start: S
  # Default-Stop:

So to directly answer your question above, it would probably be a
(separate) bug for anything that had 'S' in Default-Start to have
any other runlevel included there too (because entering any other
runlevel will have already run the rcS start scripts anyway).


Where things start to get a bit more confusing is that the initscripts
package ships a SysV init script 'killprocs' - which is 'started' upon
entering runlevel 1, and basically brutally slaughters *every* process
except the kernel threads, init, and the shell running it, with
killall5(8) ...  after which the /etc/rc1.d/single script is run, which
then changes from runlevel 1 to runlevel S - restarting all the things
in rcS again to actually enter the real 'single user mode' ...

So ostensibly, the lintian warning is actually correct about what will
happen if 1 isn't included in Default-Stop - it will still get killed
anyway, but then immediately be (re)started again ...


But wait! There's more!!  The reason I missed that detail when I first
reported this was that on the buster system I looked at this all on,
the initscripts package isn't installed, so there is no killprocs
script on it - and even if it was installed, when systemd is installed
it masks that script so that it won't run at all.  But that in turn
makes this all a bit moot on current releases, because since Stretch,
systemd won't run rcS scripts at all - if they don't have a native unit
now, it simply ignores them completely ...  which means this all really
only matters for Hurd/kFreeBSD and people not running systemd (in which
case sysvinit-core will pull in initscripts again).


So with all that said and done, I think the somewhat dizzying conclusion
is that:

 - lintian is actually right.
 - almost everything I know of providing an rcS script gets this wrong.
 - killprocs seems a little bit batshit, but I can sort of see the
   logic of wiping out everything and starting again with a clean
   slate if you're changing to runlevel 1 from some other runlevel
   (and who ever does that anymore anyway if you weren't thrown into
   it due to a boot failure!)
 - hopefully everything in rcS is actually safely idempotent if anyone
   does try that.
 - there was probably something else, but now I need a stiff drink and
   a lie down, safe in the knowledge that every time I look at init
   stuff it's always more horribly broken in ways that I never imagined
   the last time I shook my head at how horribly broken it all was ...

And unless I've really missed some other detail there, we can probably
just close this one, leave lintian as is, and point at this bug log if
anyone scratches their head at this warning again in the future ...


Sorry for the noise on this one then.  For most things, killprocs will
probably only do the same thing that the service's own stop function
would do (send a polite, then more insistent signal to terminate it),
so it's probably not a big deal to have 

Bug#889558: qtcreator: (Build-)Depends on obsolete libbotan1.10-dev

[Lisandro Damián Nicanor Pérez Meyer]

forwarded 889558 https://bugreports.qt.io/browse/QTCREATORBUG-19745
thanks

It seems that qt creator is the only real package preventing the botan 
removal, so please go ahead with it. I'll make qtcreator use it's internal 
copy for the moment being.

Kinds regards, Lisandro.


-- 
You are the Doc, Doc!
  Marty McFly To Dr. Emmett Brown, Back to the Future III

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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

Bug#888089: Really serious?

[Lisandro Damián Nicanor Pérez Meyer]

On 5 February 2018 at 16:54, Ondřej Surý  wrote:
> We want to remove botan1.10 from testing, so yes, this warrants a serious 
> severity, and it has only three r-depends:
>
> 1. monotone is dead (last upstream release 2011), we shouldn’t keep zombies 
> in Debian
>
> 2. ovito is leaf package and ranked very low in popcon
>
> 3. qtcreator is a leaf package[a] and ranked high in popcon
>
> So I think it’s quite appropriate to fill serious bug instantly, as it 
> doesn’t affect half of the archive, but just two (one) package.
>
> From quickly skimming the Botan usage in qtcreator, I think it might be quite 
> easy to use botan 2.x in QtCreator.  It’s just only a matter of somebody 
> packaging it (and afaik our conversation will reset the auto-RM timer)...

ACK then. I think you should really go and file the RoM bug then, I
can make qtcreator fall back to it's embedded version for the
meantime.

I asked qtcreator's upstreams and so far I did not receive a reply on
this. we want to avoid a delta with them as much as possible.

Bug#889683: openjpeg2: CVE-2018-6616: Excessive Iteration in opj_t1_encode_cblks

[Salvatore Bonaccorso]

Source: openjpeg2
Version: 2.3.0-1
Severity: important
Tags: security upstream
Forwarded: https://github.com/uclouvain/openjpeg/issues/1059

Hi,

the following vulnerability was published for openjpeg2.

CVE-2018-6616[0]:
| In OpenJPEG 2.3.0, there is excessive iteration in the
| opj_t1_encode_cblks function of openjp2/t1.c. Remote attackers could
| leverage this vulnerability to cause a denial of service via a crafted
| bmp file.

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-6616
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-6616
[1] https://github.com/uclouvain/openjpeg/issues/1059

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#889682: openimageio: Provide Python 3 interface

[Nico Schlömer]

Package: libopenimageio-dev
Version: 1.6.17~dfsg0-1ubuntu5
Severity: normal
File: openimageio

OpenImageIO supports Python 3 for a while now. Please provide the respective
package in Debian.



-- 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/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)

Versions of packages libopenimageio-dev depends on:
ii  libopenimageio-doc  1.6.17~dfsg0-1ubuntu5
ii  libopenimageio1.6   1.6.17~dfsg0-1ubuntu5

libopenimageio-dev recommends no packages.

libopenimageio-dev suggests no packages.

-- no debconf information

Bug#888089: Really serious?

[Ondřej Surý]

We want to remove botan1.10 from testing, so yes, this warrants a serious 
severity, and it has only three r-depends:

1. monotone is dead (last upstream release 2011), we shouldn’t keep zombies in 
Debian

2. ovito is leaf package and ranked very low in popcon

3. qtcreator is a leaf package[a] and ranked high in popcon

So I think it’s quite appropriate to fill serious bug instantly, as it doesn’t 
affect half of the archive, but just two (one) package.

From quickly skimming the Botan usage in qtcreator, I think it might be quite 
easy to use botan 2.x in QtCreator.  It’s just only a matter of somebody 
packaging it (and afaik our conversation will reset the auto-RM timer)...

~~~

a:
Checking reverse dependencies...
# Broken Build-Depends:
gcompris-qt: qtcreator

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

> On 5 Feb 2018, at 20:20, Lisandro Damián Nicanor Pérez Meyer 
>  wrote:
> 
> The fact that botan is going to loose support doesn't makes this an instant 
> RC 
> bug. Not the fact that you want to remove it.
> 
> You should really consider raising the rdepends bugs to severity serious once 
> the RoM bug for botan has been filed.
> 
> -- 
> 20:57  * m4rgin4l patento el proceso de invencion
> 20:57 < m4rgin4l> de aqui en mas cualquier inventor me tiene que pagar
> regalias por inventar algo
> 20:57  * m4rgin4l tiene la patente pendiente del metodo cientifico
> 
> Lisandro Damián Nicanor Pérez Meyer
> http://perezmeyer.com.ar/
> http://perezmeyer.blogspot.com/

Bug#889656: chrony: dhclient exit hook to add/remove NTP servers

[Vincent Blut]

On Mon, Feb 05, 2018 at 01:25:13PM +0100, Julian Wollrath wrote:

Package: chrony
Version: 3.2-2
Severity: wishlist

Dear Maintainer,


Hi Julian,


in contrast to ntp chrony does not provide a dhclient exit hook, which
adds NTP server adresses received from the DHCP server. Attached is a
script which fills this gap if put into /etc/dhcp/dhclient-exit-hooks.d/


Thanks for the script, but note that I’m already working on 
“debianizing” one, notably used in Fedora, allowing chronyd to obtain 
NTP servers from DHCP and _ntp._udp DNS SRV records.



Best regards,
Julian Wollrath


Cheers,
Vincent


signature.asc
Description: PGP signature

Bug#887933: src:nose2: Provide a binary package for PyPy

[Ghislain Vaillant]

Can you build a pypy-nose2 package for pypy, in addition to the current
binary packages for Python 2 (python-nose2) and Python 3 (python3-nose2).

Thanks,
Ghis

2018-02-05 16:05 GMT+00:00 Pierre-Elliott Bécue :
> Dear Ghislain,
>
> I might be unaware of something, but I'm not able to understand what you
are
> currently asking.
>
> Could you please give me some hints? :)
>
> Cheers,
>
> --
> Pierre-Elliott Bécue
> GPG: 9AE0 4D98 6400 E3B6 7528 F493 0D44 2664 1949 74E2

Bug#889681: wayland: CVE-2017-16612

[Salvatore Bonaccorso]

Source: wayland
Version: 1.6.0-1
Severity: important
Tags: patch security upstream
Forwarded: https://bugs.freedesktop.org/show_bug.cgi?id=103961

Hi,

the following vulnerability was published for wayland.

CVE-2017-16612[0]:
| libXcursor before 1.1.15 has various integer overflows that could lead
| to heap buffer overflows when processing malicious cursors, e.g., with
| programs like GIMP. It is also possible that an attack vector exists
| against the related code in cursor/xcursor.c in Wayland through
| 1.14.0.

Note, I asked MITRE for advice if the CVE should apply as well to
wayland leading to the above updated description.

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-2017-16612
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-16612
[1] https://bugs.freedesktop.org/show_bug.cgi?id=103961
[2] 
https://cgit.freedesktop.org/wayland/wayland/commit/?id=5d201df72f3d4f4cb8b8f75f980169b03507da38
[3] 
https://lists.freedesktop.org/archives/wayland-devel/2017-November/035979.html

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#888297: closed by Robert Luberda <rob...@debian.org> (Bug#888297: fixed in p7zip 16.02+dfsg-5)

[Robert Luberda]

Antoine Beaupré writes:

Hi,

>> The check for cur against kNumItems is missing, not sure this can
>> cause any further problem.
> 
> I concur: the original researcher explicitly sent me a patch that checks
> the `cur` counter as well.

Thanks, I'm just uploading -6 with updated patch.

Regards,
robert

Bug#889680: git: CVE-2018-1000021: client prints server sent ANSI escape codes to the terminal, allowing for unverified messages to potentially execute arbitrary commands

[Salvatore Bonaccorso]

Source: git
Version: 1:2.15.1-1
Severity: normal
Tags: security upstream

Hi,

the following vulnerability was published for git.

CVE-2018-121[0]:
|client prints server sent ANSI escape codes to the terminal, allowing
|for unverified messages to potentially execute arbitrary commands

Creating this bug to track the issue in the BTS. Apparently the CVE
was sssigned without notifying/discussing it with upstream, at least
according to [1].

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-121
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-121
[1] https://bugzilla.novell.com/show_bug.cgi?id=1079389#c1

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#889679: xgammon fails to start because of font error

[Regis Smith]

Package: xgammon
Version: 0.99.1128-3+b2
Severity: important

Dear Maintainer,

When starting xgammon from the command line, I get the following error.

$ xgammon 
couldn't load doubler dice font, using default, sorry
X Error of failed request:  BadFont (invalid Font parameter)
  Major opcode of failed request:  55 (X_CreateGC)
  Resource id in failed request:  0x0
  Serial number of failed request:  132
  Current serial number in output stream:  134
$

The program works correctly if given the -doublerfont option with an
appropriate font (from, say, the list generated by xlsfonts).  But, this is
really hard to discover.

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

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

Versions of packages xgammon depends on:
ii  libc6 2.24-11+deb9u1
ii  libice6   2:1.0.9-2
ii  libsm62:1.2.2-1+b3
ii  libx11-6  2:1.6.4-3
ii  libxaw7   2:1.0.13-1+b2
ii  libxext6  2:1.3.3-1+b2
ii  libxt61:1.1.5-1

xgammon recommends no packages.

xgammon suggests no packages.

-- no debconf information

Bug#889558: qtcreator: (Build-)Depends on obsolete libbotan1.10-dev

[Lisandro Damián Nicanor Pérez Meyer]

severity 889558 important
thanks

El domingo, 4 de febrero de 2018 11:25:37 -03 Christian Hofstaedtler escribió:
> Package: qtcreator
> Version: 4.5.0-2
> Severity: serious
> 
> Dear Maintainer,
> 
> your package qtcreator (build-)depends on botan1.10, which itself is
> obsolete. Upstream will end security support at the end of 2018, so it
> must not be part of buster.
> 
> Please drop the libbotan1.10-dev build dependency.

The fact that a lib will loose support does not make it insta RC. You can 
raise the severity once the removal bug for libbotab1.10 is filed.


-- 
Bebe a bordo (pero con moderación)

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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

Bug#888089: Really serious?

[Lisandro Damián Nicanor Pérez Meyer]

The fact that botan is going to loose support doesn't makes this an instant RC 
bug. Not the fact that you want to remove it.

You should really consider raising the rdepends bugs to severity serious once 
the RoM bug for botan has been filed.

-- 
20:57  * m4rgin4l patento el proceso de invencion
20:57 < m4rgin4l> de aqui en mas cualquier inventor me tiene que pagar
regalias por inventar algo
20:57  * m4rgin4l tiene la patente pendiente del metodo cientifico

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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

Bug#889293: src:alot: Please drop "Use file-magic instead of python-magic" patch, alot will FTBFS soon

[Christoph Biedl]

Christoph Biedl wrote...

> Also, I've prepared a NMU as attached but found alot fails to build on
> some (non-release) archs and like to investigate first. Feel free to go
> ahead, though.

No worries, this turned out to be a schroot configuration issue.

So I uploaded the NMU to DELAYED/7, diff debdiff as in the previous
message. Please feel free to tell me if I should delay it longer.

Regards,

Christoph


signature.asc
Description: PGP signature

Bug#839046: debootstrap: enable --merged-usr by default

[Julien Cristau]

On Sat, Feb  3, 2018 at 09:16:40 +0100, Marco d'Itri wrote:

> On Dec 23, md wrote:
> 
> > On Dec 20, Julien Cristau  wrote:
> > 
> > > > This change was reverted in 1.0.87 as dpkg-shlibdeps didn't cope
> > > > properly with a merged-usr system. Thus reopening this bug report for
> > > > that version.
> > > > 
> > > > The dpkg-shlibdeps bugs has been fixed [1] in the mean time. So it would
> > > > be great if this bug report could be re-considered.
> > > That'll be after stretch now.
> > Stretch was been released long ago: please re-enable --merged-usr in 
> > debootstrap.
> There has not been any negative feedback, can we move on please?

Is there buy-in from the dpkg maintainer?

Cheers,
Julien

Bug#838537: sponsoring Dia package

[Rodrigo Siqueira]

Hello Tomas,
 
> Are you still willing to adopt the package? I'd be ready to sponsor you.

Yes :)
Should we change the status of the package?

> As a first step I'd suggest to send your patches upstream [1], so that they
> can be applied there.

Nice! I will read the documentation about send patches to Dia project, and try
to upload the patches. I will let you know when I finish it.

Again, Thanks :)

Bug#889678: par FTCBFS: uses the build architecture compiler

[Helmut Grohne]

Source: par
Version: 1.52-3
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

par fails to cross build from source, because its upstream build system
uses the build architecture compiler. It ignores cdbs' passing of cross
compilers on the environment and uses CC in an uncommon way: It expects
it to contain CFLAGS and -c. The attached patch makes it CC have the
usual meaning and makes all compiler invocations use CC. After doing so,
par cross builds successfuly. Please consider applying the patch.

Helmut
diff -u par-1.52/debian/changelog par-1.52/debian/changelog
--- par-1.52/debian/changelog
+++ par-1.52/debian/changelog
@@ -1,3 +1,11 @@
+par (1.52-3.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Add p/patches/cross. Update d/patches/add_Makefile. Closes:
+#-1.
+
+ -- Helmut Grohne   Sun, 04 Feb 2018 17:15:38 +0100
+
 par (1.52-3) unstable; urgency=low
 
   * debian/README.Debian:
diff -u par-1.52/debian/patches/add_Makefile 
par-1.52/debian/patches/add_Makefile
--- par-1.52/debian/patches/add_Makefile
+++ par-1.52/debian/patches/add_Makefile
@@ -14,7 +14,7 @@
 +
 +include protoMakefile
 +
-+CC = cc $(CFLAGS) -c -D_GNU_SOURCE
++CC := $(CC) $(CFLAGS) -D_GNU_SOURCE
 +
 +install: par par.doc
 +  install -o root -g root -m 0755 par $(BIN)/par
diff -u par-1.52/debian/patches/series par-1.52/debian/patches/series
--- par-1.52/debian/patches/series
+++ par-1.52/debian/patches/series
@@ -1,3 +1,4 @@
+cross
 catch_output_errors
 fix_man_spellings
 add_Makefile
--- par-1.52.orig/debian/patches/cross
+++ par-1.52/debian/patches/cross
@@ -0,0 +1,46 @@
+From: Helmut Grohne 
+Subject: fix cross compilation
+
+ * Make CC have the usual semantics: Drop the -c and move it into the rule.
+ * Make CC and LINK1 substitutable to allow debhelper substituting it.
+
+--- a/protoMakefile
 b/protoMakefile
+@@ -34,7 +34,7 @@
+ 
+ # Define CC so that the command
+ #
+-# $(CC) foo.c
++# $(CC) -c foo.c
+ #
+ # compiles the ANSI C source file "foo.c" into the object file "foo.o".
+ # You may assume that foo.c uses no floating point math.
+@@ -45,9 +45,8 @@
+ # time efficiency by defining DONTFREE.
+ #
+ # Example (for Solaris 2.x with SPARCompiler C):
+-# CC = cc -c -O -s -Xc -DDONTFREE
++# CC = cc -O -s -Xc -DDONTFREE
+ 
+-CC = cc -c
+ 
+ # Define LINK1 and LINK2 so that the command
+ #
+@@ -61,7 +60,7 @@
+ # LINK1 = cc -s
+ # LINK2 = -o
+ 
+-LINK1 = cc
++LINK1 = $(CC)
+ LINK2 = -o
+ 
+ # Define RM so that the command
+@@ -93,7 +92,7 @@
+ OBJS = buffer$O charset$O errmsg$O par$O reformat$O
+ 
+ .c$O:
+-  $(CC) $<
++  $(CC) -c $<
+ 
+ par$E: $(OBJS)
+   $(LINK1) $(OBJS) $(LINK2) par$E

Bug#884247: Debian Bug #884247 - linphone with upnp 1.8 - patch.

[Sebastian Ramacher]

Control: tags -1 + patch

Hi Robert

On 2018-02-05 06:56:54, Robert Jansen wrote:
> Hello Sebastian,
> 
> Here's a patch so that linphone 3.12.0 can be build with libupnp 1.8.3.

Thanks for the patch. Forwarding to the bug tracker.

Cheers

> 
> I am using Slackware.
> 
> Bye, Robert

>mbedtls 2.6.1libraries/mbedtls 
>  mbedtls-2.6.1-i586-1_SBo
>  bctoolbox 0.6.0libraries/bctoolbox   
>  bctoolbox-0.6.0-i586-1_SBo
>  mbedtls 2.6.1  libraries/mbedtls 
>  mbedtls-2.6.1-i586-1_SBo
>bctoolbox 0.6.0  libraries/bctoolbox   
>  bctoolbox-0.6.0-i586-1_SBo
>jdk 8u162development/jdk   
>  jdk-7u80-i586-1
>libantlr3c 3.4   libraries/libantlr3c  
>  libantlr3c-3.4-i486-1_SBo
>mbedtls 2.6.1libraries/mbedtls 
>  mbedtls-2.6.1-i586-1_SBo
>  belle-sip 1.6.3libraries/belle-sip   
>  belle-sip-1.6.3-i586-1_SBo
>  mbedtls 2.6.1  libraries/mbedtls 
>  mbedtls-2.6.1-i586-1_SBo
>bctoolbox 0.6.0  libraries/bctoolbox   
>  bctoolbox-0.6.0-i586-1_SBo
>mbedtls 2.6.1libraries/mbedtls 
>  mbedtls-2.6.1-i586-1_SBo
>  bzrtp 1.0.6libraries/bzrtp   
>  bzrtp-1.0.6-i586-1_SBo
>  ffmpeg 3.2.4   multimedia/ffmpeg 
>  ffmpeg-2.6.8-i686_custom-1_SBo
>  libsrtp 1.6.0  libraries/libsrtp 
>  libsrtp-1.6.0-i586-1_SBo
>  libupnp 1.8.3  libraries/libupnp 
>  libupnp-1.8.3-i586-1_SBo
>  mbedtls 2.6.1  libraries/mbedtls 
>  mbedtls-2.6.1-i586-1_SBo
>  speex 1.2.0audio/speex   
>  speex-1.2.0-i486-1_SBo
>linphone 3.12.0  network/linphone  
>  linphone-3.12.0-i586-1_SBo
>x264 20170225multimedia/x264   
>  x264-20131101-i486-2_SBo
>  msx264 1.5.3   libraries/msx264  
>  msx264-1.5.3-i586-1_SBo

> diff --git a/linphone-3.12.0/mediastreamer2/src/upnp/upnp_igd.c 
> b/linphone-3.12.0/mediastreamer2/src/upnp/upnp_igd.c
> index 4f7d161..cee436c 100644
> --- a/linphone-3.12.0/mediastreamer2/src/upnp/upnp_igd.c
> +++ b/linphone-3.12.0/mediastreamer2/src/upnp/upnp_igd.c
> @@ -395,7 +395,7 @@ int upnp_igd_send_action(upnp_igd_context* igd_ctxt, 
> upnp_igd_device_node *devic
>   *   d_event  -- event associated with the new device
>   *
>   
> /
> -void upnp_igd_add_device(upnp_igd_context *igd_ctxt, IXML_Document 
> *desc_doc, struct Upnp_Discovery *d_event) {
> +void upnp_igd_add_device(upnp_igd_context *igd_ctxt, IXML_Document 
> *desc_doc, UpnpDiscovery *d_event) {
>   upnp_igd_device_node *deviceNode, *tmpdevnode;
>   int found = 0;
>   int ret;
> @@ -423,7 +423,7 @@ void upnp_igd_add_device(upnp_igd_context *igd_ctxt, 
> IXML_Document *desc_doc, st
>   baseURL = upnp_igd_get_first_document_item(igd_ctxt, desc_doc, 
> "URLBase");
>   relURL = upnp_igd_get_first_document_item(igd_ctxt, desc_doc, 
> "presentationURL");
>  
> - ret = UpnpResolveURL((baseURL ? baseURL : d_event->Location), relURL, 
> presURL);
> + ret = UpnpResolveURL((baseURL ? baseURL : 
> UpnpString_get_String(UpnpDiscovery_get_Location(d_event))), relURL, presURL);
>  
>   if (UPNP_E_SUCCESS != ret) {
>   upnp_igd_print(igd_ctxt, UPNP_IGD_ERROR, "Error generating 
> presURL from %s + %s", baseURL, relURL);
> @@ -444,7 +444,7 @@ void upnp_igd_add_device(upnp_igd_context *igd_ctxt, 
> IXML_Document *desc_doc, st
>   if (found) {
>   /* The device is already there, so just update  
> */
>   /* the advertisement timeout field */
> - tmpdevnode->device.advr_time_out = 
> d_event->Expires;
> + tmpdevnode->device.advr_time_out = 
> UpnpDiscovery_get_Expires(d_event);
>  

Bug#869547: lintian: udev-rule-missing-subsystem false positive

[Ron]

On Mon, Feb 05, 2018 at 09:06:35PM +0530, Chris Lamb wrote:
> forcemerge 869547 889639
> thanks
> 
> Hi Ron,
> 
> This appears to be same issue as #869547 ("udev-rule-missing-subsystem
> false-positive when rules file uses a GOTO").

Ah, indeed.  Sorry about the duplicate, this is the same and that patch
looks (conceptually at least!) right by eye to address it.

Re your question in the other bug about how common GOTO is, it's used a
lot in just about any set of non-trivial rules testing for common things,
so if there are (or will be) any other tests for things like this, the
same logic probably should apply to them too.

  Cheers,
  Ron

Bug#599573: add support for LaCie 321 (LCA21C0)

[Miroslav Kravec]

Hello Mourad De Clerck,

the official repository for ddccontrol-db has been moved to github:
https://github.com/ddccontrol/ddccontrol-db

Sorry for the delay, the package wasn't maintained for a long time.

Would you like to submit your contribution as GitHub PR? Or, should I
add it to git repository (sources) for you?

Kind regards,
Miroslav Kravec

Bug#869547: udev-rule-missing-subsystem false-positive when rules file uses a GOTO

[Chris Lamb]

Hi Didier,

> > Fixed in Git, pending upload
> 
> Yay, thanks; and sorry for my unresponsiveness.

No problem; it was quite an "expansive" question :)


Regards,

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

Bug#869547: udev-rule-missing-subsystem false-positive when rules file uses a GOTO

[Didier 'OdyX' Raboud]

Le lundi, 5 février 2018, 16.58:46 h CET Chris Lamb a écrit :
> Fixed in Git, pending upload

Yay, thanks; and sorry for my unresponsiveness.

-- 
OdyX

Bug#889677: O: libgltf -- Library for rendering glTF models

[Rene Engelhard]

Package: wnpp
Severity: normal

I intend to orphan the libgltf package(s).

$ apt-cache show libgltf-0.0-0v5
Package: libgltf-0.0-0v5
Source: libgltf
Version: 0.0.2-5
Installed-Size: 406
Maintainer: Debian LibreOffice Maintainers 
Architecture: amd64
Depends: libc6 (>= 2.14), libgcc1 (>= 1:3.0), libgl1-mesa-glx | libgl1, 
libglew2.0 (>= 1.12.0), libglu1-mesa | libglu1, libstdc++6 (>= 5.2)
Conflicts: libgltf-0.0-0
Description-en: Library for rendering glTF models
 glTF, the GL Transmission Format, is the runtime asset format for the GL APIs:
 WebGL, OpenGL ES, and OpenGL. glTF bridges the gap between formats used by
 modeling tools and the GL APIs.
 .
 LIBGLTF provides methods to load the OpenGL scene from glTF format and render
 it into an existing OpenGL context. LIBGLTF also allows one to change the
 camera position so the scene can be displayed from different points of view.
Description-md5: 70f62d8a1049e73e44d96799377d
Multi-Arch: same
Tag: role::shared-lib
Section: libs
Priority: optional
Filename: pool/main/libg/libgltf/libgltf-0.0-0v5_0.0.2-5_amd64.deb
Size: 137638
MD5sum: b44b6af9210c15a5b6093bb10da33abe
SHA256: 26b9a39a09ecc00dddfe494281e37a58a707614f58a0fcc6f2d900fbceb464d3

This was maintained upstream by the document foundation to render glTF
models inside LibreOffice. (and thus also maintained by
debian-openoff...@lists.debian.org).

LibreOffice 6.0 removed that feature, and so I lost any interest of it.

It right now is affected by a RC bug (doesn't build against glm 0.9.9,
probably just needs to define -DGLM_ENABLE_EXPERIMENTAL - also in
configure.ac - see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=888930

I already moved it from libreoffice-team to debian on salsa.

Given there is no r-dep besides LibreOffice and the library is
effectively unmaintained upstream, too (see
https://gerrit.libreoffice.org/#/c/41994/) it probably should just be
removed?

Regards,

Rene

Bug#889676: xvfb: xvfb-run script contains an unnecessary dependency on the external tool "which"

[Eli Schwartz]

Package: xvfb
Version: 2:1.19.6-1
Severity: minor

Arch Linux has imported the xvfb-run script from Debian's package, but
our package dependencies do not mandate that the "which" utility be
installed. OTOH we do have it in our base package group, which users are
expected to have installed, although there is a bit of bikeshedding
about whether these unstated dependencies should actually be explicitly
listed... See the following xvfb bugreport on our bugtracker:
https://bugs.archlinux.org/task/56997

All that being said, this immediately made me think, why is the script
using `which` at all, rather than the POSIX `command -v` which is far
more portable as any #!/bin/sh shell has this as a builtin. It also
provides a micro-optimization by avoiding an external subprocess.

Please consider making this script more reusable by switching to the
POSIX shell builtin.

Example output on a system which does not have /usr/bin/which available:

$ xvfb-run some_command
/usr/bin/xvfb-run: line 139: which: command not found
xvfb-run: error: xauth command not found

(This error message seems rather redundant.)

-- 
Eli Schwartz
Bug Wrangler and Trusted User

Bug#832806: Build time test failure

[Andreas Tille]

Hi Jose,

I had a sponsor look at ignition-common but when building in a pbuilder
chroot I've got:

...
 #7: UNIT_Console_TEST ...***Timeout 240.00 sec
[==] Running 17 tests from 1 test case.
[--] Global test environment set-up.
[--] 17 tests from Console_TEST
[ RUN  ] Console_TEST.NoInitAndLog
Error opening log file: /nonexistent/.ignition/auto_default.log

  
98% tests passed, 1 tests failed out of 61

Total Test time (real) = 240.07 sec

The following tests FAILED:
  7 - UNIT_Console_TEST (Timeout)
Errors while running CTest
Makefile:143: recipe for target 'test' failed
make[1]: *** [test] Error 8
make[1]: Leaving directory '/build/ignition-common-1.0.1/obj-x86_64-linux-gnu'


Kind regards

   Andreas.

-- 
http://fam-tille.de

Bug#873424: git: handling HTTPS proxy w/ password inappropriately

[Yangfl]

2018-02-06 1:55 GMT+08:00 Jonathan Nieder :
> Hi,
>
> Yangfl  wrote[1]:
>
>> not affected any more
>
> Can you say a little more about this?  Do you mean that newer versions
> of Git are working better for you or that your proxy setup changed?
>
> This looks similar to
> https://public-inbox.org/git/cahnnmh6qcnhtycbmdljffyoxw4dertzothsprkydhzknxch...@mail.gmail.com/
> to me, which makes me fear it hasn't been fixed.
>
> Thanks,
> Jonathan
>
> [1] http://bugs.debian.org/873424

I just repeated it three times to make sure it works perfectly.
However, I still see 2 connection attempts in my wireshark, the first
one without password (then FINed), and the following one with.

$ git --version
git version 2.15.1

Versions of packages git depends on:
ii  git-man  1:2.15.1-3
ii  libc62.26-4
ii  libcurl3-gnutls  7.58.0-2
ii  liberror-perl0.17025-1
ii  libexpat12.2.5-3
ii  libpcre2-8-0 10.22-5
ii  perl 5.26.1-4
ii  zlib1g   1:1.2.8.dfsg-5

Versions of packages git recommends:
ii  less 487-0.1
ii  openssh-client [ssh-client]  1:7.6p1-3
ii  patch2.7.5-1+b2

Versions of packages git suggests:
ii  gettext-base  0.19.8.1-4
pn  git-cvs   
pn  git-daemon-run | git-daemon-sysvinit  
pn  git-doc   
pn  git-el
pn  git-email 
pn  git-gui   
pn  git-mediawiki 
pn  git-svn   
pn  gitk  
pn  gitweb

Bug#859698: Stressant requires smartctl to run

[Antoine Beaupré]

Control: tags -1 +patch +pending

Hi!

smartctl is in the "recommends" of the stressant package, and so are
other tools used by the program like lshw, fio, stress-ng and so on. The
idea is to keep the program simple and the dependencies minimal.

But yes, it seems there is a problem, even with that minimal dependency:
"smartctl" is only a virtual package, if at all. The right package name
is of course smartmontools.

I'll fix this in git and this should propagate to Debian in the next
upload.

Thanks for the report.

A.

Bug#882353: Possible upstreams bug report

[Peter Habcak]

On Sun, 7 Jan 2018 06:26:57 +0100 =?UTF-8?Q?Torbj=c3=b6rn_Andersson?= 
 wrote:

> Perhaps this is the relevant upstreams bug report:
>
> https://bugzilla.gnome.org/show_bug.cgi?id=789491
>
> ("Bug 789491 - mtp volume is not removed when unplugging")
>
> If so, it was supposedly fixed in gvfs 1.35.2, "mtp: Fix volume removal
> with current udev behavior":
>

I compiled latest gvfs (1.35.4) from upstream sources and it seems to 
work correctly with linux-image-4.14.0-3-amd64 (4.14.13-1), no stale 
device entries anymore.

Bug#873424: git: handling HTTPS proxy w/ password inappropriately

[Jonathan Nieder]

Hi,

Yangfl  wrote[1]:

> not affected any more

Can you say a little more about this?  Do you mean that newer versions
of Git are working better for you or that your proxy setup changed?

This looks similar to
https://public-inbox.org/git/cahnnmh6qcnhtycbmdljffyoxw4dertzothsprkydhzknxch...@mail.gmail.com/
to me, which makes me fear it hasn't been fixed.

Thanks,
Jonathan

[1] http://bugs.debian.org/873424

Bug#812721: gbp could filter out Files-Excluded: entries when committing to the pristine-tar branch

[Raphael Hertzog]

On Thu, 25 Jan 2018, Michael Stapelberg wrote:
> > or (since upstream is somewhat redundant):
> 
> I don’t feel that “upstream” is redundant. I think the contents of a branch
> should be obvious from the name.

Ack.

> The “pristine” namespace could easily be confused with “pristine-tar”, so
> I’d prefer avoiding that name altogether if possible.

Ack, as well.

> > this would also allow to retain upstream/ with the original meaning for
> 
> Wait, now I’m confused. Isn’t “upstream” the same as “upstream/latest”?
> What “original meaning” are you referring to? :)

I'm also confused.

On Fri, 26 Jan 2018, Michael Stapelberg wrote:
> One thing came up during the implementation to which I’d like your
> feedback: if the upstream branch isn’t by chance already tagged with a
> proper version number (e.g. v1.2), how do we get a suitable version number
> for the git snapshot we’re about to package? We have such logic in
> dh-make-golang:
> https://github.com/Debian/dh-make-golang/blob/5a5180dce36c9c878b7551640ff018a6dfabf0dd/version.go#L19
> — as you can see it’s rather complicated. I couldn’t find anything
> comparable in git-buildpackage yet. Did I miss it? If no, could such logic
> be added?

I don't know what's available in git-buildpackage but if it's not, then I
think it's OK to add something like this.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#804791: [correction] netdiag: netwatch crashes when interface name is enp3s6

[Jure Spik]

Hi, I don't have the old machine anymore, but testing this on another
PC with similiar configuration still results in an error, though it now
states Buffer overflow.

Interestingly, when I tried to improve the formatting of program output
for this mail, I noticed that the program does not crash when terminal
window width is set to 69. I found the breaking to occur with 156 and
wider window, while window width 155 characters works ok.

output:
┌───NETWATCH Program 1.0c-
gm─
───
──┐
│  LOCAL
NETWORK
 REMOTE
NETWORK   │
│ HOST  (PKTS) X  R*** buffer overflow detected
***: netwatch
terminated   HOST  (PKTS) X  R 
 │
│  
 Aborted   
   

Thank you, Jure

Bug#888952: nvidia-driver and opencl

[Andreas Beckmann]

I still cannot reproduce it ...

On 2018-02-05 16:11, Hiromasa YOSHIMOTO wrote:
> modprobe: INFO: ../libkmod/libkmod.c:364 kmod_set_log_fn() custom logging 
> function 0x559425f77b90 registered
> modprobe: INFO: ../libkmod/libkmod-module.c:886 kmod_module_insert_module() 
> Failed to insert module 
> '/lib/modules/4.14.8-custom/updates/dkms/nvidia-current.ko': Operation not 
> permitted
> modprobe: ERROR: could not insert 'nvidia_current_uvm': Operation not 
> permitted
> modprobe: INFO: ../libkmod/libkmod.c:331 kmod_unref() context 0x5594264a8400 
> released

 882 err = init_module(mem, size, args);
 883 init_finished:
 884 if (err < 0) {
 885 err = -errno;
 886 INFO(mod->ctx, "Failed to insert module '%s': %m\n", path);
 887 }
 888 return err;

init_module is from glibc ...

and (from the manpage) these are the two errors occuring:

   EPERM  The caller was not privileged (did not have the CAP_SYS_MODULE 
capability), or module loading is disabled (see 
/proc/sys/kernel/modules_disabled in proc(5)).

   EEXIST A module with this name is already loaded.

I think you are hitting EPERM as user and EEXIST under sudo.

So perhaps we need to apply some capabilities to nvidia-modprobe, try this:

setcap cap_sys_module+ep /usr/bin/nvidia-modprobe


Andreas

Bug#889674: pari: Error ("unknown type 64") for galoissubfields on mips architectures

[Bill Allombert]

On Mon, Feb 05, 2018 at 05:35:12PM +0100, Tobias Hansen wrote:
> Source: pari
> Version: 2.9.4-1
> Severity: normal
> 
> Hi there,
> 
> one of the tests of cypari2 failed on the mips architectures (at least
> mips and mips64el) and the problem is in pari itself (this was on
> mips):
> 
> ? G=galoisinit(x^6 + 108)
> %1 = [x^6 + 108, [31, 11, 25408476896404831], [12621652611058331, 
> 20536155253519755, 17659145928231576, 7749330968173255, 4872321642885076, 
> 12786824285346500]~, [78732, 78732, 78732, 78732, 78732, 78732; 
> 5076109892172044, 10233067611024537, 10099299393208250, 15309177503196581, 
> 15175409285380294, 20332367004232787; 18565751806301230, 20562176763619678, 
> 11689025222888754, 11689025222888754, 20562176763619678, 18565751806301230; 
> 1987912437694300, 1987912437694300, 1987912437694300, 23420564458710531, 
> 23420564458710531, 23420564458710531; 24004326414261023, 17218050680994121, 
> 9594576697554518, 9594576697554518, 17218050680994121, 24004326414261023; 
> 22092359933430354, 20144189062948895, 8580404796430413, 16828072099974418, 
> 5264287833455936, 3316116962974477], 472392, [Vecsmall([1, 2, 3, 4, 5, 6]), 
> Vecsmall([2, 3, 1, 5, 6, 4]), Vecsmall([3, 1, 2, 6, 4, 5]), Vecsmall([4, 6, 
> 5, 1, 3, 2]), Vecsmall([5, 4, 6, 2, 1, 3]), Vecsmall([6, 5, 4, 3, 2, 1])], 
> [Vecsmall([2, 3, 1, 5, 6, 4]), Vecsmall([4, 6, 5, 1, 3, 2])], Vecsmall([3, 
> 2])]
> ? galoissubfields(G,2,z)
>   ***   at top-level: galoissubfields(G,2,
>   *** ^
>   *** galoissubfields: unknown type 64.
>   ***   Break loop: type 'break' to go back to GP prompt
> 
> Could you please have a look?

Doing that now... mipsel has the same bug.
Is it mips specific ?

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#880888: maven-enforcer FTBFS with libmaven-dependency-tree-java 3.0.1-1

[Markus Koschany]

So apparently in libmaven-dependency-tree-java 3.0.1-1 the devs decided
to rename the word tree to graph...There were some other issues though
and I was not sure how to proceed. I had a look at the Fedora package
and they patched maven-enforcer to work with Maven 3 but they also added
a dependency on maven-transfer-artifact. Maybe it might help to resolve
this bug.

https://src.fedoraproject.org/cgit/rpms/maven-enforcer.git/tree/0001-Port-to-Maven-3-API.patch

Bug#889674: pari: Error ("unknown type 64") for galoissubfields on mips architectures

[Tobias Hansen]

On 02/05/2018 06:03 PM, Bill Allombert wrote:
> On Mon, Feb 05, 2018 at 05:35:12PM +0100, Tobias Hansen wrote:
>> Source: pari
>> Version: 2.9.4-1
>> Severity: normal
>>
>> Hi there,
>>
>> one of the tests of cypari2 failed on the mips architectures (at least
>> mips and mips64el) and the problem is in pari itself (this was on
>> mips):
>>
>> ? G=galoisinit(x^6 + 108)
>> %1 = [x^6 + 108, [31, 11, 25408476896404831], [12621652611058331, 
>> 20536155253519755, 17659145928231576, 7749330968173255, 4872321642885076, 
>> 12786824285346500]~, [78732, 78732, 78732, 78732, 78732, 78732; 
>> 5076109892172044, 10233067611024537, 10099299393208250, 15309177503196581, 
>> 15175409285380294, 20332367004232787; 18565751806301230, 20562176763619678, 
>> 11689025222888754, 11689025222888754, 20562176763619678, 18565751806301230; 
>> 1987912437694300, 1987912437694300, 1987912437694300, 23420564458710531, 
>> 23420564458710531, 23420564458710531; 24004326414261023, 17218050680994121, 
>> 9594576697554518, 9594576697554518, 17218050680994121, 24004326414261023; 
>> 22092359933430354, 20144189062948895, 8580404796430413, 16828072099974418, 
>> 5264287833455936, 3316116962974477], 472392, [Vecsmall([1, 2, 3, 4, 5, 6]), 
>> Vecsmall([2, 3, 1, 5, 6, 4]), Vecsmall([3, 1, 2, 6, 4, 5]), Vecsmall([4, 6, 
>> 5, 1, 3, 2]), Vecsmall([5, 4, 6, 2, 1, 3]), Vecsmall([6, 5, 4, 3, 2, 1])], 
>> [Vecsmall([2, 3, 1, 5, 6, 4]), Vecsmall([4, 6, 5, 1, 3, 2])], Vecsmall([3, 
>> 2])]
>> ? galoissubfields(G,2,z)
>>   ***   at top-level: galoissubfields(G,2,
>>   *** ^
>>   *** galoissubfields: unknown type 64.
>>   ***   Break loop: type 'break' to go back to GP prompt
>>
>> Could you please have a look?
> Doing that now... mipsel has the same bug.
> Is it mips specific ?
>
> Cheers,


Cool. Yes it is, on all other architectures the test ran fine:

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

Best, Tobias

Bug#872998: transition: php7.2

[Carsten Schoenert]

Hi,

On Thu, Feb 01, 2018 at 09:47:21AM +0100, Emilio Pozuelo Monfort wrote:
> On 28/01/18 14:19, Ondřej Surý wrote:
> > Yes, please, go ahead, and I will fix any eventual build failures as it 
> > goes.
> 
> Done, see the failures on 
> https://release.debian.org/transitions/html/php7.2.html

don't care much about kopanocore, it's no problem to build recent
kopanocore versions against PHP7.2 and we just need to find some time to
prepare a new upstrem version of kopanocore for unstable now it has left
NEW. Should be done within this week.

Regards
Carsten

Bug#889571: yaz-client: segmentation fault when connecting via UNIX socket

[Adam Dickmeiss]

Fixed a long time ago in upstream YAZ 4.2.46. Upstream should really
updated to latest 4 in https://github.com/indexdata/yaz/commits/yaz4

/ Adam

Bug#889066: lintian should warn if the maintainer scripts include "chown -R" or "chmod -R"

[Raphael Hertzog]

Hi,

On Fri, 02 Feb 2018, Chris Lamb wrote:
> > In my case, I remember having touched many packages with dedicated
> > users created and I expect this tag to have a very high false positive
> > ratio
> 
> Can you make this more concrete? (Or, perhaps, why is colord
> vulnerable but your particular package is not..?)

I'm not quite sure of what colord is vulnerable. #889060 assumes the
attacker can create arbitrary hardlinks as the "colord" user in
/var/lib/colord. I don't know colord enough to know if that's the case
and why that would be the case.

In general, when you have a dedicated user it's because you want to run a
daemon under that user to restrict its accesses. The interfaces of most
daemons do not allow end users to create hardlinks/symlinks in the data
directories of the daemon... hence this chown -R vulnerability is only
exploitable after having found another vulnerability in the daemon to
create the hardlinks and/or symlinks.

That makes it much less important as a vulnerability.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#887394: Packaging Veyon (was: Re: Accepted italc 1:3.0.3+dfsg1-2 (source) into unstable)

[Mike Gabriel]

Hi Tobias,

On  Do 25 Jan 2018 09:32:53 CET, Tobias Doerffel wrote:


Hi Mike,

FYI: Veyon 4.0.4 is available at
https://github.com/veyon/veyon/releases/tag/v4.0.4

I integrated the possibility to build without x11vnc builtin but
instead use an external x11vnc binary (do not get confused that the
plugin is still called "builtin-x11vnc.so" but it should be notably
smaller). Simply pass -DVEYON_X11VNC_EXTERNAL=ON to cmake. No need for
applying a patch.


2018-01-18 13:42 GMT+01:00 Mike Gabriel :

  2. Can kldap be used from Debian?



Theoretically this would work however this would introduce a strong
dependency on KDE while Veyon uses only a small part of the kldap
library without any dependencies on KDE at all. Veyon's LDAP support
plugin uses some (Qt-based) core classes of kldap but none of it's
KDE-specific model and widget classes. For all non-KDE users this
would unnecessarily install many KDE libraries and make them think
Veyon is a KDE program (which it isn't).



Let me check the deps tree myself here. I'll get back to you on this.


Any news? I still encourage you to keep things as they are as
everything else will make things unnecessarily complicated for
everyone without any notable benefit for the end user (except saving a
few KB disk space in case KDE is installed vs. many MB disk space
additionally in every other case).

Best regards

Tobias


I need some more feedback on the distribution of files over the  
various packages:


Package: veyon-master
Package: veyon-service
Package: veyon-configurator
Package: libveyon-core

And in debian/tmp I see these files directly after the build:

./usr/lib/x86_64-linux-gnu/veyon/powercontrol.so
./usr/lib/x86_64-linux-gnu/veyon/servicecontrol.so
./usr/lib/x86_64-linux-gnu/veyon/desktopservices.so
./usr/lib/x86_64-linux-gnu/veyon/localdata.so
./usr/lib/x86_64-linux-gnu/veyon/demo.so
./usr/lib/x86_64-linux-gnu/veyon/ldap.so
./usr/lib/x86_64-linux-gnu/veyon/linux-platform.so
./usr/lib/x86_64-linux-gnu/veyon/builtin-x11vnc-server.so
./usr/lib/x86_64-linux-gnu/veyon/textmessage.so
./usr/lib/x86_64-linux-gnu/veyon/screenlock.so
./usr/lib/x86_64-linux-gnu/veyon/config.so
./usr/lib/x86_64-linux-gnu/veyon/remoteaccess.so
./usr/lib/x86_64-linux-gnu/veyon/screenshot.so
./usr/share/icons/hicolor/scalable/apps/veyon-configurator.svg
./usr/share/icons/hicolor/scalable/apps/veyon-master.svg
./usr/share/icons/hicolor/48x48/apps/veyon-configurator.png
./usr/share/icons/hicolor/48x48/apps/veyon-master.png
./usr/share/pixmaps/veyon-configurator.xpm
./usr/share/pixmaps/veyon-master.xpm
./usr/share/polkit-1/actions/io.veyon.veyon-configurator.policy
./usr/share/applications/veyon-configurator.desktop
./usr/share/applications/veyon-master.desktop
./usr/bin/veyon-master
./usr/bin/veyon-ctl
./usr/bin/veyon-auth-helper
./usr/bin/veyon-configurator
./usr/bin/veyon-service
./usr/bin/veyon-worker

How shall I distribute these files over the above named packages? And:  
do I need another package (e.g. veyon-ctl or veyon-worker? Or a  
plugins package?).


Does it make sense to package plugins separately so that the site  
admin can add/remove features?


Mike
--

mike gabriel aka sunweaver (Debian Developer)
mobile: +49 (1520) 1976 148
landline: +49 (4354) 8390 139

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: sunwea...@debian.org, http://sunweavers.net



pgpu85JqQrGhx.pgp
Description: Digitale PGP-Signatur

Bug#889675: RM: botan1.10 -- ROM; obsolete

[Chris Hofstaedtler]

Package: ftp.debian.org
Severity: normal

Dear ftpmasters,

please remove botan1.10. It is obsolete.

Note rgd. ROM: discussed this with Ondrej in person.

Thanks,
Chris

Bug#882017: solution available upstream

[Christian Ehrhardt]

Hi,
I debugged the same case on Ubuntu and
  
eventually found [1].
The fix itself is [2] and would according to my tests unblock this issue.

There is also a 0.14 now, but the fix is not included in there yet.

[1]: https://github.com/MagicStack/asyncpg/issues/250
[2]: 
https://github.com/MagicStack/asyncpg/commit/05dce25f15090ae8ebfb7ba2f67a0edc60cd915a

-- 
Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd

Bug#889674: pari: Error ("unknown type 64") for galoissubfields on mips architectures

[Tobias Hansen]

Source: pari
Version: 2.9.4-1
Severity: normal

Hi there,

one of the tests of cypari2 failed on the mips architectures (at least mips and 
mips64el) and the problem is in pari itself (this was on mips):

? G=galoisinit(x^6 + 108)
%1 = [x^6 + 108, [31, 11, 25408476896404831], [12621652611058331, 
20536155253519755, 17659145928231576, 7749330968173255, 4872321642885076, 
12786824285346500]~, [78732, 78732, 78732, 78732, 78732, 78732; 
5076109892172044, 10233067611024537, 10099299393208250, 15309177503196581, 
15175409285380294, 20332367004232787; 18565751806301230, 20562176763619678, 
11689025222888754, 11689025222888754, 20562176763619678, 18565751806301230; 
1987912437694300, 1987912437694300, 1987912437694300, 23420564458710531, 
23420564458710531, 23420564458710531; 24004326414261023, 17218050680994121, 
9594576697554518, 9594576697554518, 17218050680994121, 24004326414261023; 
22092359933430354, 20144189062948895, 8580404796430413, 16828072099974418, 
5264287833455936, 3316116962974477], 472392, [Vecsmall([1, 2, 3, 4, 5, 6]), 
Vecsmall([2, 3, 1, 5, 6, 4]), Vecsmall([3, 1, 2, 6, 4, 5]), Vecsmall([4, 6, 5, 
1, 3, 2]), Vecsmall([5, 4, 6, 2, 1, 3]), Vecsmall([6, 5, 4, 3, 2, 1])], 
[Vecsmall([2, 3, 1, 5, 6, 4]), Vecsmall([4, 6, 5, 1, 3, 2])], Vecsmall([3, 2])]
? galoissubfields(G,2,z)
  ***   at top-level: galoissubfields(G,2,
  *** ^
  *** galoissubfields: unknown type 64.
  ***   Break loop: type 'break' to go back to GP prompt

Could you please have a look?

Best,
Tobias