Bug#797181: freeradius: packaging 3.0.x

[Christopher Hoskin]

Superb! Thanks for your work on this!

Christopher

On 25 September 2016 at 01:54, Michael Stapelberg 
wrote:

> Hi,
>
> I’m about to upload FreeRADIUS 3.0.11+dfsg-1 to experimental. Once it
> clears NEW (because of the additional binary packages), please give it a
> shot and let me know how the package works for you. Any feedback
> (whether it’s about success or issues) is welcome.
>
> I’ll upload to unstable once I got enough success messages.
>
> Also thanks everyone for the upstream contributions to the debian
> packaging. Any further improvements to the package are very welcome,
> please submit your patches to the Debian bug tracker.
>
> PS: If you’re super-eager to check out the package even before it clears
> NEW, feel free to build it yourself:
> https://anonscm.debian.org/cgit/pkg-freeradius/freeradius.git/
>
> --
> Best regards,
> Michael
>
> --
> To unsubscribe, send mail to 797181-unsubscr...@bugs.debian.org.
>

Bug#838589: pg8000: please provide Python 3 package

[Rahul Amaram]

Will look into it sometime this week. I mainly need to ensure that 
modifying / upgrading doesn't break compatibility with calendarserver.


Thanks,
Rahul.

On Thursday 22 September 2016 10:38 PM, Dominik George wrote:

Source: pg8000
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

The package does not seem to build a python3-pg8000 package, although,
according to upstream, pg8000 works with Python 3.

I am currently packaging the testing.postgresql package for unit testing
database applications, and it uses the pg8000 interface.

Could you please enable the build for Python 3 (and, if necessary for
doing so, package the latest upstream version beforehand)?

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

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

-BEGIN PGP SIGNATURE-

iQJhBAEBCABLBQJX5A/9MRpodHRwczovL3d3dy5kb21pbmlrLWdlb3JnZS5kZS9n
cGctcG9saWN5LnR4dC5hc2MSHG5pa0BuYXR1cmFsbmV0LmRlAAoJELeaPBagxPKW
CKEP/34JRg9TEbmJR7vCmnhCkfQj629ybEWK5QTrhFCO5Cfv+xAu/mdA/izC2U2U
4uTXMhS3JoU+dwEVIwFtXXE8llIgvpDf4JvNjJt/BEVjjL/yMoF4t56QAmk9yD80
fFWEMWijXqDC0uvmqjGSCCwV3zR3ycXn1A0uB0Nh9IKbvcph1igTUhlLDlRJ1zMW
v09N5Ln2FL0oXlNEncqSa9Z9bmToyG7yCrFNrXTyE0uhgD4zpFLEZAjRfy1qbAco
rJXP3c4jzXj2rey2HplcgTaTDu03T1WjsECLitVv7aB4ugQeOWTFqgP2Cx1ONIRp
37iBu+mRVrTh1sPqTXAaYpkJFmroU7Fk9UG1PAB8dOaFX4qBTi6KYWgYtA6sabER
6I97Vj4ADhyqZFOGypoK0sUQaSi/iUFskwEVa9G0rW4Ln7RlKUXeRtlEs8JQllyg
t+OqHSLp9sUI6X2Kj9EsDF6ImYDW49GESpMIVnaahpEQEtA/Yv99xGsCN4GufR8O
v6SQEIbNUZG0UxOYhAWPHEQcbJD7Kw8hr5/tKuPlVE/f6gUg8eAvGvVgYNDjYCJv
WoUsibNhzwAnNmvsswQetgL5GbWXcBGsn/sBEtHdxYV/W0MTSa+25/QinQYTlfeQ
lQUQ3aKOCUGPRGk93r6c0neY187WmeiowI91woBLdIuud7r6
=VjWb
-END PGP SIGNATURE-



--
http://rahul.amaram.name

Bug#838806: ITP: nbsphinx -- Jupyter Notebook Tools for Sphinx

[Jerome Benoit]

Package: wnpp
Severity: wishlist
Owner: Jerome Benoit 

* Package name: nbsphinx
  Version : 0.2.9
  Upstream Author : Matthias Geier 
* URL : https://pypi.python.org/pypi/nbsphinx/
* License : MIT
  Programming Lang: Python
  Description : Jupyter Notebook Tools for Sphinx

nbsphinx is a Sphinx extension that provides a source parser for *.ipynb
files. Custom Sphinx directives are used to show Jupyter Notebook code cells
(and of course their results) in both HTML and LaTeX output.
Un-evaluatednotebooks, i.e., notebooks without stored output cells, will be
automatically executed during the Sphinx build process.

Bug#775490: ITP: natron -- Natron is an open-source, crossplatform, nodal compositing software

[Thomas Ross]

retitle 775490 RFP: natron -- Natron is an open-source, crossplatform,
nodal compositing software
noowner 775490
--

Hi IOhannes,

I am no longer interested in packaging Natron, please feel free to
package it.

Thanks,
Thomas.



signature.asc
Description: OpenPGP digital signature

Bug#802191: bats: FTBFS: not ok 7 summary passing tests

[Yaroslav Halchenko]

On Sun, 25 Sep 2016, Santiago Vila wrote:

> On Sun, Sep 25, 2016 at 01:14:16AM +0200, Tobias Frost wrote:

> > I'd then NMU it tomorrow,,,

> I would skip this package, as I think the maintainer is around and not MIA.

NMUs are welcome if you see a clear workaround (force setting up some
TERM so tests pass?)


-- 
Yaroslav O. Halchenko
Center for Open Neuroscience http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834   Fax: +1 (603) 646-1419
WWW:   http://www.linkedin.com/in/yarik

Bug#838805: DSA 3676 announcement email lack charset header

[Adrian Bunk]

Package: security.debian.org
Severity: minor

https://lists.debian.org/debian-security-announce/2016/msg00256.html

"Tuomas Räsänen" - that name is not displayed properly due to lack
of an email header for the charset of the contents.

Something like
  Content-Type: text/plain; charset=utf-8
is missing.

I don't care about this past DSA, but it would be nice if you could
fix that for future DSAs.

Bug#838787: [pkg-boost-devel] Bug#838787: libboost1.61-doc doesn't contain the actual documentation

[Steve M. Robbins]

On Saturday, September 24, 2016 11:28:43 PM CDT Evgeny Kapun wrote:
> Package: libboost1.61-doc
> Version: 1.61.0+dfsg-2.1
> 
> The package libboost1.61-doc is supposed to include Boost documentation. It
> doesn't. 

Yes, unfortunately.  My best advice to you is use the online docs at http://
www.boost.org/doc/libs/1_61_0/

-Steve


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

Bug#838804: chromium:Gtk: cannot open display:

[user]

Package: chromium
Version: 53.0.2785.113-1~deb8u1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

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

   * What led up to the situation?
I ran chromium and chromium --disable-namespace-sandbox from weston-terminal in 
weston
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
I tried export DISPLAY=:0 and :0.0 neither worked and only changed err
   * What was the outcome of this action?
ERROR:browser_main_loop.cc(261) Gtk: cannot open display:
   * What outcome did you expect instead?
for chromium to run

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


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

Kernel: Linux 3.16.0-4-amd64 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, 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 chromium depends on:
ii  libasound2   1.0.28-1
ii  libatk1.0-0  2.14.0-1
ii  libc62.19-18+deb8u6
ii  libcairo21.14.0-2.1+deb8u1
ii  libcups2 1.7.5-11+deb8u1
ii  libdbus-1-3  1.8.20-0+deb8u1
ii  libexpat12.1.0-6+deb8u3
ii  libfontconfig1   2.11.0-6.3+deb8u1
ii  libfreetype6 2.5.2-3+deb8u1
ii  libgcc1  1:4.9.2-10
ii  libgdk-pixbuf2.0-0   2.31.1-2+deb8u5
ii  libglib2.0-0 2.42.1-1+b1
ii  libgnome-keyring03.12.0-1+b1
ii  libgtk2.0-0  2.24.25-3+deb8u1
ii  libjpeg62-turbo  1:1.3.1-12
ii  libnspr4 2:4.10.7-1+deb8u1
ii  libnss3  2:3.17.2-1.1+deb8u2
ii  libpango-1.0-0   1.36.8-3
ii  libpangocairo-1.0-0  1.36.8-3
ii  libpci3  1:3.2.1-3
ii  libspeechd2  0.8-7
ii  libstdc++6   4.9.2-10
ii  libx11-6 2:1.6.2-3
ii  libxcomposite1   1:0.4.4-1
ii  libxcursor1  1:1.1.14-1+b1
ii  libxdamage1  1:1.1.4-2+b1
ii  libxext6 2:1.3.3-1
ii  libxfixes3   1:5.0.1-2+b2
ii  libxi6   2:1.7.4-1+b2
ii  libxml2  2.9.1+dfsg1-5+deb8u3
ii  libxrandr2   2:1.4.2-1+b1
ii  libxrender1  1:0.9.8-1+b1
ii  libxslt1.1   1.1.28-2+deb8u1
ii  libxss1  1:1.2.2-1
ii  libxtst6 2:1.2.2-1+b1
ii  x11-utils7.7+2
ii  xdg-utils1.1.0~rc1+git20111210-7.4

chromium recommends no packages.

Versions of packages chromium suggests:
pn  chromium-inspector  
pn  chromium-l10n   

-- no debconf information

Bug#838803: ITP: fitsh -- a software package for astronomical image processing

[Andras Pal]

Package: wnpp
Owner: Andras Pal 
Severity: wishlist
X-Debbugs-Cc: debian-de...@lists.debian.org,debian-as...@lists.debian.org

* Package name: FITSH
  Version : 0.9.2
  Upstream Author : Andras Pal 
* URL : http://fitsh.net/
* License : GPLv3
  Programming Lang: C
  Description : A software package for astronomical image processing

FITSH is a full-featured open-source software collection related to 
astronomical image analysis and data processing [1]. This package includes set 
of executables designed to perform the most essential astronomical image 
reduction (and related) steps, including:
 - Providing basic information about the images or other FITS data, pixel 
statistics

 - Conversion of FITS images to more easily presentable formats.
 - Querying and modification of FITS header keywords.
 - Calibration of raw images, including the masking of bad, saturated or 
otherwise unuseable pixels.

 - Arithmetic operations on images, both on per-image and per-pixel basis.
 - Combination of multiple images into a single one.
 - Generic spatial geometric transformations of images (shifting, dilating, 
shrinking, clipping, higher order polynomial transformations, ...), including 
the registration of images to the same reference frame.

 - Generation of artificial images.
 - Detection and characterization of stellar profiles.
 - Coordinate list manipulation (fit and evaluation of geometric 
transformations, point matching, pair matching, cross-matching of catalogues 
and source lists, matching by identifiers, ...)
 - Instrumental photometry (aperture, image subtraction, analytic profile 
modelling, point-spread functions and various other sophisticated combinations 
of these).

 - Regression analysis and general numeric data manipulation.
 - The tasks are optimized for shell-level parallel processing.

This package will maintained within the Debian Astronomy Working Group. A git 
repository will be created on alioth.


[1] http://fitsh.net/

Bug#816591: RFA: python-xmp-toolkit -- XMP library for Python

[andrew . neher1]

I'd like to get involved and try to contribute. This looks like a small, easy 
package to maintain. If I could ask the present maintainer for advice, I'd 
like to take it over.

Thanks!
Andrew M Neher

Bug#838546: closed by Ximin Luo <infini...@debian.org> (Bug#838546: fixed in mozilla-gnome-keyring 0.11+git4-2)

[johnw]

On 09/22/2016 07:51 PM, Debian Bug Tracking System wrote:
> This is an automatic notification regarding your Bug report
> which was filed against the xul-ext-gnome-keyring package:
>
> #838546: firefox 49.0-1 (amd64) break xul-ext-gnome-keyring
>
> It has been closed by Ximin Luo .
>
> Their explanation is attached below along with your original report.
> If this explanation is unsatisfactory and you have not received a
> better one in a separate message then please contact Ximin Luo 
>  by
> replying to this email.
>
>
Hi, After upgrade to "xul-ext-gnome-keyring 0.11+git4-3", I still have
this problem.

Please help, thank you.



0xCF2C80AC.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature

Bug#831240: google-perftools: FTBFS: Running death test 0 hangs

[Aliaksey Kandratsenka]

On my machine this is passing reliably. Given that KVM virtual machine
image was mentioned, maybe someone can share KVM image where this is
failing? I am still eager to debug this.

On Sun, Sep 18, 2016 at 4:07 AM, Santiago Vila  wrote:
>
> On Fri, 16 Sep 2016, Lucas Nussbaum wrote:
>
>> On 15/09/16 at 19:39 +0200, Santiago Vila wrote:
>
>> > Version 2.2.1-0.3 is the first one that does not *always* fail for me.
>> > This is a great achievement indeed.
>> >
>> > Now it builds sometimes, but 3/11 is not a very good ratio.
>>
>> I'm not sure, no. It's indeed possible that it's still failing randomly.
>
> Ok, based on available data, this package still FTBFS randomly, so I'm
> raising the severity to serious again.
>
> Since there is a new upstream release, maybe it does not make much
> sense to try to debug this in the current version.
>
> So I suggest the maintainer to disable the tests (trivial but untested
> patch attached) for this release and reenable them for the next
> upstream version.
>
> I don't use this package myself, and it is not my intention or desire
> to see it autoremoved for the sake of removing it.
>
> Everything I ask is that it builds ok, so if anybody reading this
> wants to see this package in stretch in its current form please consider
> contacting the maintainer and/or disabling the tests in a NMU.
>
> Upstream is willing to help here, but if the maintainer seems to be MIA,
> there is not much else we can do.
>
> Thanks.

Bug#828455: nmh: FTBFS with openssl 1.1.0

[Alexander Zangerl]

tags 828455 + upstream
forwarded 828455 
http://lists.nongnu.org/archive/html/nmh-workers/2016-09/msg00060.html
thanks

On Sun, 26 Jun 2016 12:23:13 +0200, Kurt Roeckx writes:
>OpenSSL 1.1.0 is about to released.  During a rebuild of all packages using
>OpenSSL this package fail to build.

upstream is now aware of the issue and the openssl-related autoconf bits
and internal code will be fixed in the upcoming 1.7 release.

regards
az


-- 
Alexander Zangerl + GPG Key 0xB963BD5F + http://snafu.priv.at/
I'm picturing Windows NT jamming a network backbone going 'la la la la I can't
hear you la la la la la' -- Graham Reed


signature.asc
Description: Digital Signature

Bug#836831: raw nroff appears on man page

[Russ Allbery]

gregor herrmann  writes:
> On Tue, 06 Sep 2016 09:22:04 -0700, Russ Allbery wrote:

>> Russ Allbery  writes:
>> 
>> > Bug in pod2man.  [..]

>> Updated patch that actually passes tests.  I'll put out a new release,
>> hopefully fairly soon.

> Thanks, Russ, much appreciated.

This is fixed in podlators 4.08, just now released.

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

Bug#838800: rss-glx build-depends on conflicting packages.

[Paul Wise]

On Sun, 2016-09-25 at 02:29 +0100, peter green wrote:

> rss-glx build-depends on both libglew-dev and libglewmx-dev.
> 
> These are now provided from seperate source packages and conflict with 
> each other. So it is not possible to satisfy the build-dependencies.

Dropping the libglewmx-dev fixes the FTBFS, didn't test the result though.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#838685: myrescue: There are some typos in the description

[Eriberto]

Hi,

2016-09-23 12:33 GMT-03:00 Alberto Luaces :
> Package: myrescue
> Severity: minor
>
> In the last paragraph of the description of this package, "midia" should be 
> "media"


Right. I will fix it.


> and maybe "forensics investigations" should be "forensic investigations".


"Forensics" is a name for a science. This name will choosen to allow
users find our packages using 'apt-cache search forensic' and
'apt-cache search forensics'.

Thanks for your suggestions.

Regards,

Eriberto

Bug#830580: Patch to install alternatives

[Josh Triplett]

On Sat, Sep 24, 2016 at 09:02:35PM -0400, James McCoy wrote:
> On Sat, Sep 24, 2016 at 12:29:15PM -0700, Josh Triplett wrote:
> > On Sat, Sep 24, 2016 at 01:10:18PM -0400, James McCoy wrote:
> > > Thanks for the patch!
> > > 
> > > On Sun, Jul 10, 2016 at 11:27:23PM -0700, Josh Triplett wrote:
> > > > From 8d4641be71797ef7d54a3067f2c15cb374b73b16 Mon Sep 17 00:00:00 2001
> > > > From: Josh Triplett 
> > > > Date: Sun, 10 Jul 2016 23:21:37 -0700
> > > > Subject: [PATCH] Install alternatives for ex, rvim, rview, vi, vim, 
> > > > view, and
> > > >  vimdiff
> > > 
> > > I don't think it makes sense to install an alternative for vi.  Neovim
> > > is explicitly dropping various "vi compatibility" pieces of
> > > functionality.
> > 
> > Neovim is still an implementation of vi, and acts like vi; it just
> > doesn't keep "bug-compatibility".  If you didn't have any other vi
> > implementation installed, I think it still makes sense for "vi" to
> > invoke nvim.
> 
> Ack.
> 
> > > Why are these alternatives 29 when editor is on-par with vim.basic at
> > > 30?
> > 
> > I was trying to be conservative, to avoid surprising anyone who installs
> > neovim to experiment with it but expects "vim" to have complete vim
> > compatibility.
> 
> From a quick experiment, update-alternatives preserves the existing
> auto-selected alternative when another is installed at the same
> priority.  If vim is already installed, it stays selected.  If neovim is
> installed first and later vim, then neovim stays the selected
> alternative.

That seems reasonable.  In that case, setting them all to priority 30
seems fine to me.

- Josh Triplett

Bug#838802: kernel-package: Possible race condition creating debian/stamp/binary

[Nikolaus Demmel]

Package: kernel-package
Version: 13.018
Severity: normal
 
Dear Maintainer,
 
I'm trying to build a custom kernel with make-kpkg. This is Ubuntu 14.04, but I 
manually
installed kernel-package from Ubuntu 16.04, namely version 13.018, since I need 
support
for localversion files.
 
I'm running something like:
 
make-kpkg --initrd buildpackage --uc --us --revision 1-foo
 
and very frequently the build fails toward the end (after about 45 minutes). I 
think the relevant part of the
output is the following:
 
 
 
[...]
/usr/bin/make -f debian/rules debian/stamp/dep-binary-arch
make[2]: Entering directory `/home/den2pal/work/zeno/zenocam/linux-kernel/linux'
== making target 
debian/stamp/binary/pre-linux-headers-4.1.30-ltsi-rt34-zenocam1+ [new prereqs: 
linux-headers-4.1.30-ltsi-rt34-zenocam1+]==
== making target 
debian/stamp/binary/pre-linux-image-4.1.30-ltsi-rt34-zenocam1+ [new prereqs: 
linux-image-4.1.30-ltsi-rt34-zenocam1+]==
 
 
This is kernel package version 13.018.
This is kernel package version 13.018.
== making target debian/stamp/BIN/linux-uml-4.1.30-ltsi-rt34-zenocam1+ [new 
prereqs: do-pre-bin-arch]==
== making target 
debian/stamp/binary/pre-linux-image-4.1.30-ltsi-rt34-zenocam1+-dbg [new 
prereqs: linux-image-4.1.30-ltsi-rt34-zenocam1+-dbg]==
 
 
/usr/bin/make -f ./debian/rules 
debian/stamp/binary/linux-headers-4.1.30-ltsi-rt34-zenocam1+
This is kernel package version 13.018.
mkdir: cannot create directory ‘debian/stamp/binary’: File exists
make[2]: *** [debian/stamp/binary/pre-linux-image-4.1.30-ltsi-rt34-zenocam1+] 
Error 1
make[2]: *** Waiting for unfinished jobs
/usr/bin/make -f ./debian/rules 
debian/stamp/binary/linux-image-4.1.30-ltsi-rt34-zenocam1+-dbg
[...]
 
 
 
I might be interpreting this wrong, but it looks like both the linux-headers 
and the linux-image targets
are typing to create the folder debian/stamp/binary. From the code of 
kernel-package, it looks like they
are both calling
 
@test -d debian/stamp/binary || mkdir debian/stamp/binary
 
which looks like it could lead to a race condition if executed in parallel. A 
solution might be something
like `mkdir -p` or `mkdir debian/stamp/binary || true`.
 
I wounder if / why noone has this issue, since it does happen very consistently 
for me. I will try to call
make-kpkg with `-j1` to see if that makes a difference.

Kind regards,
Nikolaus

 
 
-- System Information:
Debian Release: jessie/sid
  APT prefers trusty-updates
  APT policy: (500, 'trusty-updates'), (500, 'trusty-security'), (500, 
'trusty'), (400, 'trusty-proposed'), (100, 'trusty-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
 
Kernel: Linux 4.4.0-38-generic (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
 
Versions of packages kernel-package depends on:
ii  bc   1.06.95-8ubuntu1
ii  binutils 2.24-5ubuntu14.1
ii  build-essential  11.6ubuntu6
ii  bzip21.0.6-5
ii  dpkg-dev 1.17.5ubuntu5.7
ii  file 1:5.14-2ubuntu3.3
ii  gettext  0.18.3.1-1ubuntu3
ii  kmod 15-0ubuntu6
ii  po-debconf   1.0.16+nmu2ubuntu1
ii  xmlto0.0.25-2
ii  xz-utils [lzma]  5.1.1alpha+20120614-2ubuntu2
 
Versions of packages kernel-package recommends:
ii  cpio   2.11+dfsg-1ubuntu1.2
pn  docbook-utils  
pn  kernel-common  
pn  uboot-mkimage  
 
Versions of packages kernel-package suggests:
ii  libncurses5-dev [libncurses-dev]  5.9+20140118-1ubuntu1
pn  linux-source  
 
-- no debconf information

Bug#836903: RFS: qevercloud/3.0.2+ds-1 [ITP] -- Unofficial Evernote Cloud API library for Qt

[Sean Whitton]

Hello Boyuan,

One more thing -- the .so should be installed as
libqt?evercloud.so.3.0.0, with a symlink from libqt?evercloud.so.3.  See
ch. 8 of Debian policy for an explanation of this practice.

Thanks!

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#838801: RFS: zxcvbn-c/0.20150103-1 [ITP]

[Sean Whitton]

Package: sponsorship-requests
Severity: wishlist
Control: block 838492 by -1

Dear mentors,

I am looking for a sponsor for my package "zxcvbn-c".

This is a shlib dependency of a Haskell library I want to package, on
the way to packaging keysafe, the latest cool project from Joey Hess:

https://joeyh.name/code/keysafe/

* Package name: zxcvbn-c
  Version : 0.20150103-1
  Upstream Author : Tony Evans
* URL : https://github.com/tsyrogit/zxcvbn-c
* License : BSD-3-clause
  Section : libs

It builds those binary packages:

libzxcvbn-dev - password strength estimation library - development files
libzxcvbn0 - password strength estimation library

Mentors information page:

https://mentors.debian.net/package/zxcvbn-c

Download with dget:

dget -x 
https://mentors.debian.net/debian/pool/main/z/zxcvbn-c/zxcvbn-c_0.20150103-1.dsc

Or build it with gbp:

gbp clone --pristine-tar https://git.spwhitton.name/zxcvbn-c
git checkout debian/0.20150103-1
git verify-tag debian/0.20150103-1 # my key is in DM keyring
gbp buildpackage

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#838800: rss-glx build-depends on conflicting packages.

[peter green]

package: rss-glx
serverity: serious
tags: stretch, sid
x-debbugs-cc: p...@debian.org

rss-glx build-depends on both libglew-dev and libglewmx-dev.

These are now provided from seperate source packages and conflict with 
each other. So it is not possible to satisfy the build-dependencies.

Bug#838799: ITP: haskell-zxcvbn-c -- Haskell binding to C port of zxcvbn password strength estimator

[Sean Whitton]

Package: wnpp
Severity: wishlist
Owner: Sean Whitton 
Control: block 834869 by -1

* Package name: haskell-zxcvbn-c
  Version : 1.0.0
  Upstream Author : Joey Hess 
* URL : https://hackage.haskell.org/package/zxcvbn-c
* License : BSD-3-clause
  Programming Lang: Haskell
  Description : Haskell binding to C port of zxcvbn password strength 
estimator

I am packaging this as a dependency for keysafe, another ITP of mine.

I intend to maintain it as part of the Haskell team.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#830580: Patch to install alternatives

[James McCoy]

On Sat, Sep 24, 2016 at 12:29:15PM -0700, Josh Triplett wrote:
> On Sat, Sep 24, 2016 at 01:10:18PM -0400, James McCoy wrote:
> > Thanks for the patch!
> > 
> > On Sun, Jul 10, 2016 at 11:27:23PM -0700, Josh Triplett wrote:
> > > From 8d4641be71797ef7d54a3067f2c15cb374b73b16 Mon Sep 17 00:00:00 2001
> > > From: Josh Triplett 
> > > Date: Sun, 10 Jul 2016 23:21:37 -0700
> > > Subject: [PATCH] Install alternatives for ex, rvim, rview, vi, vim, view, 
> > > and
> > >  vimdiff
> > 
> > I don't think it makes sense to install an alternative for vi.  Neovim
> > is explicitly dropping various "vi compatibility" pieces of
> > functionality.
> 
> Neovim is still an implementation of vi, and acts like vi; it just
> doesn't keep "bug-compatibility".  If you didn't have any other vi
> implementation installed, I think it still makes sense for "vi" to
> invoke nvim.

Ack.

> > Why are these alternatives 29 when editor is on-par with vim.basic at
> > 30?
> 
> I was trying to be conservative, to avoid surprising anyone who installs
> neovim to experiment with it but expects "vim" to have complete vim
> compatibility.

>From a quick experiment, update-alternatives preserves the existing
auto-selected alternative when another is installed at the same
priority.  If vim is already installed, it stays selected.  If neovim is
installed first and later vim, then neovim stays the selected
alternative.

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Bug#797181: freeradius: packaging 3.0.x

[Michael Stapelberg]

Hi,

I’m about to upload FreeRADIUS 3.0.11+dfsg-1 to experimental. Once it
clears NEW (because of the additional binary packages), please give it a
shot and let me know how the package works for you. Any feedback
(whether it’s about success or issues) is welcome.

I’ll upload to unstable once I got enough success messages.

Also thanks everyone for the upstream contributions to the debian
packaging. Any further improvements to the package are very welcome,
please submit your patches to the Debian bug tracker.

PS: If you’re super-eager to check out the package even before it clears
NEW, feel free to build it yourself:
https://anonscm.debian.org/cgit/pkg-freeradius/freeradius.git/

-- 
Best regards,
Michael

Bug#821051: git branch with code signing script

[Ben Hutchings]

I've pushed all my changes to a git repo at:
https://git.decadent.org.uk/git/dak.git

Ben.

-- 
Ben Hutchings
No political challenge can be met by shopping. - George Monbiot

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

Bug#415396: "dh_install --list-missing" should ignore manpages and other installed files

[Michael Stapelberg]

[+cc Niels, who might have an idea as to how to fix this]

Hi Drew,

I’m facing the same issue in one of my packages.

Drew Parsons  writes:
> At the moment dh_install --list-missing complains about any file in
> debian/tmp not listed in the install file.  This includes manpages,
> even if they are listed in their own manpages file to be installed by
> dh_installman.

For completeness: this issue also includes documentation pages installed
by dh_installdocs, and, I assume, any other dh_install* command.

The fact that this bug is now almost 10 years old implies that the issue
is not very easy to fix (or people don’t care).

Could we make the dh_install* helpers log the files which they install
and then move dh_install to the end of the dh sequence so that it can
read in all of the files which the other helpers installed?

-- 
Best regards,
Michael

Bug#838798: ITP: jupyter-sphinx-theme -- Jupyter Sphinx Theme

[Jerome Benoit]

Package: wnpp
Severity: wishlist
Owner: Jerome Benoit 

* Package name: jupyter-sphinx-theme
  Version : 0.0.6
  Upstream Author : IPython Development Team
* URL : https://pypi.python.org/pypi/jupyter-sphinx-theme
* License : BSD
  Programming Lang: Python
  Description : Jupyter Sphinx Theme

A Jupyter Sphinx [1] theme for narrative documentation.

[1] http://www.sphinx-doc.org/en/stable/

Bug#712228: Your mail

[Bálint Réczey]

Hi,

2016-09-11 10:44 GMT+02:00 Gianfranco Costamagna :
> Hi,
>
>>https://patches.ubuntu.com/g/ghc/ghc_7.10.3-9ubuntu1.patch
>
>
> this patch was already committed on ghc 8 branch, and I also committed
> on the master branch (7.10.3), however, I won't upload it.
>>An other option would be bootstrapping GHC in Debian with
>>-fPIC, but I'm not sure if this is viable.
>
>
> that might sound better in the long run, even if it requires probably more
> effort.
>
> I finished the Ubuntu haskell transition without many issues, so I presume
> this patch is safe for unstable, but I don't feel enough confident because
> I can't rebuild and NMU stuff in Debian :)

Thank you for working on the transition for Debian, too.
I have tested the fix and it does not seem to fix the build on Debian
most probably due
to missing additional patches to GCC.

The build system needs more changes IMO.

I'll look into passing -fPIC down to all the gcc calls to fix the build.

You can test the new GCC 6, too, by adding the following line to
sources.list on your test system:
deb https://people.debian.org/~rbalint/ppa/pie-bindnow pie-bindnow-unstable/

Cheers,
Balint

Bug#798296: These bugs are really the same

[Santiago Vila]

severity 798296 serious
forcemerge 798296 802191

It is my undesrtanding that these two bugs are really the same.

It fails with sbuild (when run under cron, not manually from a
terminal) because TERM is not set.

Bug#836170:

[Thomas Adam]

This has nothing to do with FVWM at all.  FVWM has no concept of how
another application should be working.

-- Thomas Adam

Bug#838797: RM: gcc-4.9-doc -- RoQA; gcc-4.9 was removed

[Andreas Beckmann]

Package: ftp.debian.org
Severity: normal

With gcc-4.9 gone from the archive, there is no need to keep its
documentation.


Andreas

Bug#838786: debpear: error 'cp: target ‘yaml-1.2.0.orig.tar.gz’ is not a directory'

[Roland Hieber]

Control: submitter 838786 !

> File /home/rohieb/php-yaml-2.0.0~rc8+1.3.0~b1/build-area/yaml-1.2.0.tgz 
> downloaded

Okay, turns out I had already downloaded a different php-yaml*.tar.gz to
that folder.  When I tried debpear in a different folder, everything
went as expected.  I guess the script should detect this case and warn
the user, or better yet, choose the tar.gz which was downloaded before
by the script itself :-)

Cheers,
 - Roland

Bug#838734: [plasma-discover] plasma-discover uninstalls packages during upgrades without asking for confirmation

[Scott Kitterman]

On September 24, 2016 3:02:28 PM EDT, Diederik de Haas  
wrote:
>Control: reopen -1
>
>On Sat, 24 Sep 2016 15:52:33 +0100 Chris Lamb  wrote:
>> > [plasma-discover] plasma-discover uninstalls packages during
>upgrades
>> > without asking for confirmation> 
>> This is due to the ongoing Perl migration. There was a mail sent to
>> debian-devel-announce but I believe it was unfortunately blocked.
>> 
>> I'm closing your bug as this is not an issue that can be resolved by
>> plasma-discover, alas. :(
>
>From my #debian-qt-kde logs:
>[27.08 01:43]  plasma-discover is a giant piece of junk and
>imo 
>should be removed from every meta package
>[27.08 01:43]   /rant
>[27.08 01:45]  for a change I used it's function and did
>happily 
>uninstall plasma-desktop, plasma-workspace, sddm and a number of other 
>essential programs
>[27.08 01:45]  without any warning that is. Trying to fix it
>with 
>aptitude seems to be a no go as it's not able to resolve conflicts
>[27.08 01:45]  I have _never_ seen/happen that before
>
>So this happened on 24th of August and then the perl migration wasn't 
>happening, thus reopening the bug.

In any case, the message about the Perl migration said not to file bugs about 
package uninstallability.  That's not what this bug is about.

This bug is about lack of user visibility when discover removes packages and 
the consequent risk of inappropriate removals causing system problems.

I do agree that as long as this is the case it's questionable is it's suitable 
for the default KDE install.  I'm not completely convinced it's suitable to be 
in the archive at all.

Scott K

Bug#838733: [Debichem-devel] Bug#838733: experimental version of avogadro FTBFS on armel and armhf

[peter green]

Tags 838733 +patch
thanks

On 24/09/16 23:19, Michael Banck wrote:

So it seems the fix is simply to replace Eigen::Vector3d with Eigen::Matrix<
qreal , 3 , 1>. I've just set off a test build with that change, will report
results in the morning.
 

Let us know how it goes.
   

I got it to build,  debdiff attatched, no intent to NMU.


diff -Nru avogadro-1.1.1/debian/changelog avogadro-1.1.1/debian/changelog
--- avogadro-1.1.1/debian/changelog 2016-08-04 17:06:58.0 +
+++ avogadro-1.1.1/debian/changelog 2016-09-24 02:16:01.0 +
@@ -1,3 +1,10 @@
+avogadro (1.1.1-1~exp3.2) UNRELEASED; urgency=medium
+
+  * Patch for BTS, no intent to NMU
+  * Fix qreal VS double issue.
+
+ -- Peter Michael Green   Sat, 24 Sep 2016 02:16:01 +
+
 avogadro (1.1.1-1~exp3.1) experimental; urgency=medium
 
   * Non-maintainer upload.
diff -Nru avogadro-1.1.1/debian/patches/fix-qreal-vs-double.patch 
avogadro-1.1.1/debian/patches/fix-qreal-vs-double.patch
--- avogadro-1.1.1/debian/patches/fix-qreal-vs-double.patch 1970-01-01 
00:00:00.0 +
+++ avogadro-1.1.1/debian/patches/fix-qreal-vs-double.patch 2016-09-24 
02:16:01.0 +
@@ -0,0 +1,95 @@
+Description: Fix qreal VS double issue.
+ Vector3d is an alias for Eigen::Matrix< double , 3 , 1> but electronDensity 
+ expects Eigen::Matrix< qreal , 3 , 1> therefore the code broke on arm
+ platforms where qreal is defined (in qt4) as float. This patch changes the
+ code to construct the correct type.
+Author: Peter Michael Green 
+---
+The information above should follow the Patch Tagging Guidelines, please
+checkout http://dep.debian.net/deps/dep3/ to learn about the format. Here
+are templates for supplementary fields that you might want to add:
+
+Origin: , 
+Bug: 
+Bug-Debian: https://bugs.debian.org/
+Bug-Ubuntu: https://launchpad.net/bugs/
+Forwarded: 
+Reviewed-By: 
+Last-Update: 2016-09-24
+
+Index: avogadro-1.1.1/libavogadro/src/extensions/qtaim/qtaimcubature.cpp
+===
+--- avogadro-1.1.1.orig/libavogadro/src/extensions/qtaim/qtaimcubature.cpp
 avogadro-1.1.1/libavogadro/src/extensions/qtaim/qtaimcubature.cpp
+@@ -1189,7 +1189,7 @@ QList QTAIMEvaluateProperty(QL
+ 
+   QList valueList;
+ 
+-  double initialElectronDensity=eval.electronDensity( 
Eigen::Vector3d(x0,y0,z0) );
++  double initialElectronDensity=eval.electronDensity( Eigen::Matrix< qreal , 
3 , 1>(x0,y0,z0) );
+ 
+   // if less than some small value, then return zero for all integrands.
+   if( initialElectronDensity < 1.e-5 )
+@@ -1254,7 +1254,7 @@ QList QTAIMEvaluateProperty(QL
+   {
+ if( modeList.at(m) == 0 )
+ {
+-  valueList.append(eval.electronDensity( Eigen::Vector3d(x0,y0,z0) ));
++  valueList.append(eval.electronDensity( Eigen::Matrix< qreal , 3 , 
1>(x0,y0,z0) ));
+ }
+ else
+ {
+@@ -1472,7 +1472,7 @@ QList QTAIMEvaluatePropertyRTP
+ 
+   QList valueList;
+ 
+-  double initialElectronDensity=eval.electronDensity( 
Eigen::Vector3d(x0,y0,z0) );
++  double initialElectronDensity=eval.electronDensity( Eigen::Matrix< qreal , 
3 , 1>(x0,y0,z0) );
+ 
+   // if less than some small value, then return zero for all integrands.
+   if( initialElectronDensity < 1.e-5 )
+@@ -1540,7 +1540,7 @@ QList QTAIMEvaluatePropertyRTP
+ {
+   valueList.append(
+ 
+-  r0*r0*sin(t0)*eval.electronDensity( Eigen::Vector3d(x0,y0,z0) )
++  r0*r0*sin(t0)*eval.electronDensity( Eigen::Matrix< qreal , 3 , 
1>(x0,y0,z0) )
+ 
+   );
+ }
+@@ -1738,7 +1738,7 @@ void property_r(unsigned int ndim, const
+   {
+ if( mode==0 )
+ {
+-  fval[m]=r*r*eval.electronDensity( Eigen::Vector3d(x,y,z) );
++  fval[m]=r*r*eval.electronDensity( Eigen::Matrix< qreal , 3 , 1>(x,y,z) 
);
+ }
+   }
+ 
+@@ -1846,7 +1846,7 @@ QList QTAIMEvaluatePropertyTP(
+   qreal x=xyzl(0);
+   qreal y=xyzl(1);
+   qreal z=xyzl(2);
+-  qreal leftElectronDensity=eval.electronDensity( Eigen::Vector3d(x,y,z) );
++  qreal leftElectronDensity=eval.electronDensity( Eigen::Matrix< qreal , 3 , 
1>(x,y,z) );
+ 
+   if( leftElectronDensity < 1.e-5 )
+   {
+@@ -1896,7 +1896,7 @@ QList QTAIMEvaluatePropertyTP(
+   x=xyzr(0);
+   y=xyzr(1);
+   z=xyzr(2);
+-  qreal rightElectronDensity=eval.electronDensity( Eigen::Vector3d(x,y,z) );
++  qreal rightElectronDensity=eval.electronDensity( Eigen::Matrix< qreal , 3 , 
1>(x,y,z) );
+ 
+   if( rightElectronDensity < 1.e-5 )
+   {
+@@ -1959,7 +1959,7 @@ QList QTAIMEvaluatePropertyTP(
+ x=xyzm(0);
+ y=xyzm(1);
+ z=xyzm(2);
+-qreal midpointElectronDensity=eval.electronDensity( 
Eigen::Vector3d(x,y,z) );
++qreal midpointElectronDensity=eval.electronDensity( Eigen::Matrix< qreal 
, 3 , 1>(x,y,z) );
+ 
+ if( midpointElectronDensity < 1.e-5 )
+ {

Bug#802191: bats: FTBFS: not ok 7 summary passing tests

[Santiago Vila]

On Sun, Sep 25, 2016 at 01:14:16AM +0200, Tobias Frost wrote:

> At the moment I cannot install sbuild due to the perl breakage...

Oh, that's why I like running testing (not unstable).

> But I think it is not necessary as you confirmed the issue is enough
> for me. 
> Can you try to apply the patch from #798296 to see if it builds?

Yes, it fixes the build when TERM is not set.

BTW: I've just discovered that running sbuild by hand makes TERM to be
inherited from my own bash session. I had to unset TERM to check that.

(The build logs I attached are created by sbuild as a child process
of cron, so that's why TERM is not set in such case).

> I'd then NMU it tomorrow,,,

I would skip this package, as I think the maintainer is around and not MIA.

> Greetings from the Salzburg BSP,

Good luck.

Thanks.

Bug#837027: {t,}csh FTBFS

[Nicolas Braud-Santoni]

Hi,

I was working on this today at the Salzburg BSP and should finish
tomorrow.


Best,

  nicoo

Bug#838796: samba: logrotate for log.smbd is too verbose when samba is not running

[Roland Hieber]

Package: samba
Version: 2:4.4.5+dfsg-3
Severity: minor
Tags: patch

Dear Maintainer,

I have disabled the smbd process on my system, but now the daily logrotate bugs
me that it cannot restart the smbd daemon via /etc/init.d/smbd reload:

/etc/cron.daily/logrotate:
smbd.service is not active, cannot reload.
error: error running non-shared postrotate script for 
/var/log/samba/log.smbd of '/var/log/samba/log.smbd '
run-parts: /etc/cron.daily/logrotate exited with return code 1


This patch does the job for me:

-- 8< --
--- /etc/logrotate.d/samba.orig 2016-09-25 01:18:34.896469400 +0200
+++ /etc/logrotate.d/samba  2016-09-25 01:18:39.612429939 +0200
@@ -3,7 +3,7 @@
missingok
rotate 7
postrotate
-   /etc/init.d/smbd reload > /dev/null
+   [ ! -f /var/run/samba/smbd.pid ] || /etc/init.d/smbd reload > 
/dev/null
endscript
compress
notifempty
-- >8 --


Cheers,
 - Roland

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

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

Versions of packages samba depends on:
ii  adduser  3.115
ii  dpkg 1.18.10
ii  init-system-helpers  1.44
ii  libbsd0  0.8.3-1
ii  libc62.23-5
ii  libldb1  2:1.1.26-1
ii  libpam-modules   1.1.8-3.3
ii  libpam-runtime   1.1.8-3.3
ii  libpopt0 1.16-10
ii  libpython2.7 2.7.12-3
ii  libtalloc2   2.1.7-1
ii  libtdb1  1.3.9-1
ii  libtevent0   0.9.28-1
ii  libwbclient0 2:4.4.5+dfsg-3
ii  lsb-base 9.20160629
ii  procps   2:3.3.12-2
ii  python   2.7.11-2
ii  python-dnspython 1.14.0-3
ii  python-samba 2:4.4.5+dfsg-3
pn  python2.7:any
ii  samba-common 2:4.4.5+dfsg-3
ii  samba-common-bin 2:4.4.5+dfsg-3
ii  samba-libs   2:4.4.5+dfsg-3
ii  tdb-tools1.3.9-1
ii  update-inetd 4.43

Versions of packages samba recommends:
pn  attr
ii  logrotate   3.8.7-2
ii  samba-dsdb-modules  2:4.4.5+dfsg-3
pn  samba-vfs-modules   

Versions of packages samba suggests:
pn  bind9  
pn  bind9utils 
pn  ctdb   
pn  ldb-tools  
ii  ntp1:4.2.8p8+dfsg-1
pn  smbldap-tools  
pn  ufw
pn  winbind

-- debconf information:
  samba/run_mode: daemons
  samba-common/title:

Bug#802191: bats: FTBFS: not ok 7 summary passing tests

[Tobias Frost]

Am Sonntag, den 25.09.2016, 00:13 +0200 schrieb Santiago Vila:
> severity 802191 serious
> thanks
> 
> While reviewing unreproducible FTBFS bugs I found this one,
> which I can reproduce without any problem at all and it's
> not random at all.
> 
> I attach five different build logs from four different autobuilders,
> using sbuild.
> 
> I think downgrading a bug just because it does not happen with
> pbuilder is just wrong, because the official buildds use sbuild,
> not pbuilder (hence I'm raising to serious again).
> 
> If the TERM thing is an essential difference between pbuilder and
> sbuild, please consider filing a bug against pbuilder for that.
> 
> Tobias, could you please try with sbuild? In case you could still
> not reproduce this with sbuild, please contact me privately, maybe
> I can lend you a virtual machine as a last resort.

At the moment I cannot install sbuild due to the perl breakage...
But I think it is not necessary as you confirmed the issue is enough
for me. 
Can you try to apply the patch from #798296 to see if it builds?
I'd then NMU it tomorrow,,,


Greetings from the Salzburg BSP,

tobi

Bug#838760: perl: Perl/Perl-base upgrade removes 141 packages (Sid/Unstable)

[Russ Allbery]

Cindy Sue Causey  writes:

> Hi! Thank you for all the hard work you all to so #poverty level folks
> have a chance to keep up with the tech world, too! As to why I'm
> writing, just tried to upgrade a select 30+ packages in
> Sid/Unstable. Apt-get is my chosen method to do so. Received the message
> that Received the advisement that:

> 2 upgraded, 2 newly installed, 141 to remove

> ALMOST let it happen because I was in a hurry and didn't immediately
> catch that message. Only thing I know to do in this kind of situation is
> to set Perl and Perl-base aside and wait for the next release so that's
> how I'm approaching it today.

For future reference, you get results like this mostly from apt-get
install of specific packages, since then apt-get goes to considerably more
lengths to try to do what you're telling it to do (including contemplating
removing temporarily conflicting packages).

If instead you do a whole-system upgrade with apt-get upgrade, you'll see
all these packages will just be held back until they can be safely
upgraded.  Even if you use the more aggressive apt-get dist-upgrade, right
now you get something (depending on the packages you have installed) like:

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

The following packages have unmet dependencies:
 libenchant1c2a : Depends: aspell-en but it is not going to be installed or
   myspell-dictionary or
   aspell-dictionary or
   ispell-dictionary or
   hunspell-dictionary
E: Error, pkgProblemResolver::Resolve generated breaks, this may be caused by 
held packages.

which is not horribly informative but at least doesn't do the wrong thing.

You probably have reasons to want to upgrade specific packages instead of
your system in better, but it's worth being aware that this is one case
where this can be less safe (if you don't watch apt-get closely) than
letting it use its normal upgrade semantics.  (Also, a general upgrade is
safer in that you'll always get security updates.)

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

Bug#802191: bats: FTBFS: not ok 7 summary passing tests

[Santiago Vila]

I said:
> the official buildds use sbuild,

Just in case anybody want to argue that "this package does not need to
build in the official buildds because it's Arch: all".

Well, yes, it needs to be buildable in the "Arch: all" autobuilder
as well. That's precisely what release goal in Bug #830997 is about.
We should be able to upload every package in stretch in source only
form, and it should work.

Thanks.

Bug#838777: Policy 11.8.4 for x-window-manager needs update for freedesktop menus

[Russ Allbery]

Josh Triplett  writes:
> On Sat, Sep 24, 2016 at 12:57:04PM -0700, Russ Allbery wrote:
>> Josh Triplett  writes:

>>> Based on some conversations on #debian-devel on the purpose of
>>> x-window-manager (as launched by
>>> /etc/X11/Xsession.d/50x11-common_determine-startup), it seems like a
>>> window manager that just manages windows, and expects a separately
>>> launched menu/taskbar program or desktop environment to provide the
>>> ability for the user to launch programs or otherwise do anything
>>> useful, shouldn't register an x-window-manager alternative at all.
>>> Otherwise, the user might end up staring at a desktop they can't
>>> interact with at all.

>> Er, this seems to imply that twm shouldn't register as
>> x-window-manager, which sounds wrong and isn't how Debian has ever
>> worked.  Or am I misunderstanding what you mean by "just manages
>> windows"?

> twm has a menu to launch additional applications; left-click on the
> desktop.  So, it should continue registering an x-window-manager
> alternative.

> I'm talking about window managers like metacity or mutter, which without
> an associated desktop environment provide no way to launch applications
> or even exit.

Oh, okay, I see.  Yeah, that seems sensible.

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

Bug#838775: gnome-autoar: Unable to open nautilus

[Michael Biebl]

Am 25.09.2016 um 00:54 schrieb Michael Biebl:
> That's a bug in libarchive. It should provide a symbols file or at least
> ship a shlibs file which bumps the soversion when new symbols are added.
> Reassigning accordingly.

Adding a Build-Depends-Package to the shlibs/symbols file while at it
would be a good idea as well. See man deb-symbols

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



signature.asc
Description: OpenPGP digital signature

Bug#838775: gnome-autoar: Unable to open nautilus

[Michael Biebl]

Control: reassign -1 libarchive13
Control: retitle -1 provide symbols file for proper shlibs dependencies
Control: severity -1 important

Am 24.09.2016 um 20:18 schrieb Andrew Schurman:
> 
> When upgrading some combination of gnome packages from ~3.18 to ~3.21,
> I've found that I cannot open Nautilus. Running from the terminal
> gives:
> 
> undefined symbol: archive_entry_is_encrypted
> 
> It appears upgrading just these gnome packages didn't catch a required
> upgrade to libarchive13. After the following transition, nautilus
> started working again without problems.
> 
> libarchive13 (3.1.2-11+b1) to 3.2.1-2
> 
> The method appears to have been added in 3.2.0. Please add a lower
> bound runtime dependency on libarchive13.

That's a bug in libarchive. It should provide a symbols file or at least
ship a shlibs file which bumps the soversion when new symbols are added.
Reassigning accordingly.


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



signature.asc
Description: OpenPGP digital signature

Bug#838792: openmw: FTBFS on armhf: error: conflicting declaration for GLsizeiptr

[bret curtis]

We know what the problem is and are working on it.

Please see the following:
https://anonscm.debian.org/cgit/pkg-osg/openscenegraph-3.4.git/commit/?id=fa5b1385d2b82f3fec9cc6094fb3db498a36a9e3

OSG-3.4 had the same problem until this was commited, now the package
builds and OpenMW was unblocked. It too now fails and will be fixed
asap.

Cheers,
Bret

On Sat, Sep 24, 2016 at 11:25 PM, Andreas Beckmann  wrote:
> Package: openmw
> Version: 0.40.0-1
> Severity: serious
> Justification: fails to build from source (but built successfully in the past)
>
> Hi,
>
> openmw/experimental FTBFS on armhf:
>
> https://buildd.debian.org/status/fetch.php?pkg=openmw=armhf=0.40.0-1=1474694818
>
> In file included from /usr/include/osg/GL:113:0,
>  from /usr/include/osg/GLDefines:25,
>  from /usr/include/osg/GLExtensions:18,
>  from /usr/include/osg/State:18,
>  from /usr/include/osg/GraphicsContext:17,
>  from /usr/include/osgViewer/GraphicsWindow:17,
>  from /«PKGBUILDDIR»/extern/osgQt/GraphicsWindowQt:19,
>  from /«PKGBUILDDIR»/extern/osgQt/GraphicsWindowQt.cpp:14:
> /usr/include/GLES2/gl2.h:69:25: error: conflicting declaration 'typedef 
> khronos_ssize_t GLsizeiptr'
>  typedef khronos_ssize_t GLsizeiptr;
>  ^~
> In file included from /usr/include/GL/gl.h:2055:0,
>  from /usr/include/qt4/QtOpenGL/qgl.h:88,
>  from /usr/include/qt4/QtOpenGL/QGLWidget:1,
>  from /«PKGBUILDDIR»/extern/osgQt/GraphicsWindowQt:17,
>  from /«PKGBUILDDIR»/extern/osgQt/GraphicsWindowQt.cpp:14:
> /usr/include/GL/glext.h:468:19: note: previous declaration as 'typedef 
> ptrdiff_t GLsizeiptr'
>  typedef ptrdiff_t GLsizeiptr;
>^~
> In file included from /usr/include/osg/GL:113:0,
>  from /usr/include/osg/GLDefines:25,
>  from /usr/include/osg/GLExtensions:18,
>  from /usr/include/osg/State:18,
>  from /usr/include/osg/GraphicsContext:17,
>  from /usr/include/osgViewer/GraphicsWindow:17,
>  from /«PKGBUILDDIR»/extern/osgQt/GraphicsWindowQt:19,
>  from /«PKGBUILDDIR»/extern/osgQt/GraphicsWindowQt.cpp:14:
> /usr/include/GLES2/gl2.h:70:26: error: conflicting declaration 'typedef 
> khronos_intptr_t GLintptr'
>  typedef khronos_intptr_t GLintptr;
>   ^~~~
> In file included from /usr/include/GL/gl.h:2055:0,
>  from /usr/include/qt4/QtOpenGL/qgl.h:88,
>  from /usr/include/qt4/QtOpenGL/QGLWidget:1,
>  from /«PKGBUILDDIR»/extern/osgQt/GraphicsWindowQt:17,
>  from /«PKGBUILDDIR»/extern/osgQt/GraphicsWindowQt.cpp:14:
> /usr/include/GL/glext.h:469:19: note: previous declaration as 'typedef 
> ptrdiff_t GLintptr'
>  typedef ptrdiff_t GLintptr;
>^~~~
>
>
> Andreas

Bug#838051: kodi: Embedded libsquish library now available in debian

[Wookey]

On 2016-09-24 14:14 +0200, Bálint Réczey wrote:
> Control: tags -1 upstream fixed-upstream pending
> Control: notfound -1 17.0~alpha3+dfsg1-1
> 
> Hi Wookey,
> 
> 2016-09-17 2:26 GMT+02:00 Wookey :

> > The changes have also been sent upstream and will hopefully appear
> > in libsquish 1.14 at some point.

This has now happened, so I just uploaded 1.14. (no functional changes over 
1.13-3)

> Thank you for packaging libsquish.
> Kodi upstream dropped many embedded code copies recently including
> libsquish in 17.x.
> Experimental already has a kodi version without libsquish.

You mean that it doesn't actually use it any more?
 
> I'll close this bug when Kodi 17.x enters unstable.

OK. Cheers.

Wookey
-- 
Principal hats:  Linaro, Debian, Wookware, ARM
http://wookware.org/


signature.asc
Description: Digital signature

Bug#836634: libmsn: please drop the build dependency on hardening-wrapper

[Chris Lamb]

tags 836634 + pending patch
thanks

I've uploaded libmsn 4.2.1+dfsg-1.1 to DELAYED/5:
  
  libmsn (4.2.1+dfsg-1.1) unstable; urgency=medium
  
* Non-maintainer upload.
* Drop Build-Depends on hardening-wrapper. (Closes: #836634)

The full debdiff is attached.


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
diff -Nru libmsn-4.2.1+dfsg/debian/changelog libmsn-4.2.1+dfsg/debian/changelog
--- libmsn-4.2.1+dfsg/debian/changelog  2015-08-31 09:52:20.0 +0200
+++ libmsn-4.2.1+dfsg/debian/changelog  2016-09-25 00:32:03.0 +0200
@@ -1,3 +1,10 @@
+libmsn (4.2.1+dfsg-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop Build-Depends on hardening-wrapper. (Closes: #836634)
+
+ -- Chris Lamb   Sun, 25 Sep 2016 00:32:03 +0200
+
 libmsn (4.2.1+dfsg-1) unstable; urgency=medium
 
   * Package new upstream version, which was actually the same as 4.2-2
diff -Nru libmsn-4.2.1+dfsg/debian/control libmsn-4.2.1+dfsg/debian/control
--- libmsn-4.2.1+dfsg/debian/control2015-08-31 09:47:37.0 +0200
+++ libmsn-4.2.1+dfsg/debian/control2016-09-25 00:32:03.0 +0200
@@ -2,7 +2,7 @@
 Priority: optional
 Maintainer: Pau Garcia i Quiles 
 DM-Upload-Allowed: yes
-Build-Depends: debhelper (>= 6.0.7), cmake, libssl-dev, hardening-wrapper
+Build-Depends: debhelper (>= 6.0.7), cmake, libssl-dev
 Standards-Version: 3.9.6.1
 Section: libs
 Homepage: http://libmsn.sourceforge.net
diff -Nru libmsn-4.2.1+dfsg/debian/rules libmsn-4.2.1+dfsg/debian/rules
--- libmsn-4.2.1+dfsg/debian/rules  2015-08-31 10:13:56.0 +0200
+++ libmsn-4.2.1+dfsg/debian/rules  2016-09-25 00:32:03.0 +0200
@@ -10,10 +10,10 @@
 #export DH_VERBOSE=1
 
 # enable the hardening wrapper
-DEB_BUILD_HARDENING = 1
+DPKG_EXPORT_BUILDFLAGS = 1
 # but disable PIE
-DEB_BUILD_HARDENING_PIE = 0
-export DEB_BUILD_HARDENING DEB_BUILD_HARDENING_PIE
+export DEB_BUILD_MAINT_OPTIONS=hardening=-pie 
+include /usr/share/dpkg/buildflags.mk
 
 get-orig-source:
$(CURDIR)/debian/get-orig-source.sh

Bug#836999: strace: FTBFS: ../btrfs.c:68:8: error: redefinition of 'struct btrfs_ioctl_defrag_range_args'

[Sebastian Ramacher]

Control: tags -1 + fixed-upstream

On 2016-09-08 00:15:11, Lucas Nussbaum wrote:
> Source: strace
> Version: 4.12-3
> Severity: serious
> Tags: stretch sid
> User: debian...@lists.debian.org
> Usertags: qa-ftbfs-20160906 qa-ftbfs
> Justification: FTBFS on amd64
> 
> Hi,
> 
> During a rebuild of all packages in sid, your package failed to build on
> amd64.
> 
> Relevant part (hopefully):
> > gcc -DHAVE_CONFIG_H   -I./linux/x86_64 -I../linux/x86_64 -I./linux 
> > -I../linux -I. -I..   -Wdate-time -D_FORTIFY_SOURCE=2 -Wall -Wwrite-strings 
> > -Wsign-compare  -g -O2 -fdebug-prefix-map=/<>=. -fPIE 
> > -fstack-protector-strong -Wformat -Werror=format-security -Wall -g -O2 -MT 
> > strace-btrfs.o -MD -MP -MF .deps/strace-btrfs.Tpo -c -o strace-btrfs.o 
> > `test -f 'btrfs.c' || echo '../'`btrfs.c
> > ../btrfs.c:68:8: error: redefinition of 'struct 
> > btrfs_ioctl_defrag_range_args'
> >  struct btrfs_ioctl_defrag_range_args {
> > ^
> > In file included from ../btrfs.c:36:0:
> > /usr/include/linux/btrfs.h:496:8: note: originally defined here
> >  struct btrfs_ioctl_defrag_range_args {
> > ^
> > Makefile:2619: recipe for target 'strace-btrfs.o' failed
> > make[3]: *** [strace-btrfs.o] Error 1

This bugs is caused by a bug in the configure script. A fix is available
upstream:
https://github.com/strace/strace/commit/7c0e8875a432f68f391518d11a38f91a7fe91f35

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#838795: gnome-shell: Startup notification fails on Wayland

[Tony Houghton]

Package: gnome-shell
Version: 3.22.0-1
Severity: normal

When launching an application the spinner continues to show next to its
name in the taskbar, and the app menu can not be opened, for several
seconds after the app has opened, presumably until it times out. Sorry
if this is the wrong package, I don't know what's responsible if it
isn't gnome-shell.

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

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

Versions of packages gnome-shell depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.26.0-2
ii  evolution-data-server3.20.5-1
ii  gir1.2-accountsservice-1.0   0.6.40-3
ii  gir1.2-atspi-2.0 2.20.2-2
ii  gir1.2-caribou-1.0   0.4.21-1
ii  gir1.2-freedesktop   1.50.0-1
ii  gir1.2-gcr-3 3.20.0-2
ii  gir1.2-gdesktopenums-3.0 3.22.0-1
ii  gir1.2-gdm-1.0   3.22.0-1
ii  gir1.2-glib-2.0  1.50.0-1
ii  gir1.2-gnomebluetooth-1.03.20.0-1
ii  gir1.2-gnomedesktop-3.0  3.22.0-1
ii  gir1.2-gtk-3.0   3.22.0-1
ii  gir1.2-gweather-3.0  3.20.3-1
ii  gir1.2-ibus-1.0  1.5.11-1
ii  gir1.2-mutter-3.03.22.0-1
ii  gir1.2-networkmanager-1.01.4.0-3
ii  gir1.2-nmgtk-1.0 1.4.0-2
ii  gir1.2-pango-1.0 1.40.3-2
ii  gir1.2-polkit-1.00.105-16
ii  gir1.2-soup-2.4  2.56.0-1
ii  gir1.2-telepathyglib-0.120.24.1-1.1
ii  gir1.2-telepathylogger-0.2   0.8.2-1
ii  gir1.2-upowerglib-1.00.99.4-4
ii  gjs  1.46.0-1
ii  gnome-backgrounds3.22.0-2
ii  gnome-settings-daemon3.22.0-1
ii  gnome-shell-common   3.22.0-1
ii  gsettings-desktop-schemas3.22.0-1
ii  libatk-bridge2.0-0   2.20.1-4
ii  libatk1.0-0  2.22.0-1
ii  libc62.24-3
ii  libcairo21.14.6-1+b1
ii  libcanberra-gtk3-0   0.30-3
ii  libcanberra0 0.30-3
ii  libcroco30.6.11-2
ii  libdbus-glib-1-2 0.108-1
ii  libecal-1.2-19   3.20.5-1
ii  libedataserver-1.2-213.20.5-1
ii  libgcr-base-3-1  3.20.0-2
ii  libgdk-pixbuf2.0-0   2.36.0-1
ii  libgirepository-1.0-11.50.0-1
ii  libgjs0e [libgjs0-libmozjs-24-0] 1.46.0-1
ii  libglib2.0-0 2.50.0-1
ii  libglib2.0-bin   2.50.0-1
ii  libgstreamer1.0-01.8.3-1
ii  libgtk-3-0   3.22.0-1
ii  libical2 2.0.0-0.5+b1
ii  libicu57 57.1-4
ii  libjson-glib-1.0-0   1.2.2-1
ii  libmozjs-24-024.2.0-3.1
ii  libmutter0i  3.22.0-1
ii  libnm-glib4  1.4.0-3
ii  libnm-util2  1.4.0-3
ii  libpango-1.0-0   1.40.3-2
ii  libpangocairo-1.0-0  1.40.3-2
ii  libpolkit-agent-1-0  0.105-16
ii  libpolkit-gobject-1-00.105-16
ii  libpulse-mainloop-glib0  9.0-3
ii  libpulse09.0-3
ii  libsecret-1-00.18.5-2
ii  libstartup-notification0 0.12-4
ii  libsystemd0  231-7
ii  libtelepathy-glib0   0.24.1-1.1
ii  libwayland-client0   1.11.0-2
ii  libx11-6 2:1.6.3-1
ii  libxfixes3   1:5.0.2-1
ii  mutter   3.22.0-1
ii  python3  3.5.1-4
ii  telepathy-mission-control-5  1:5.16.3-2

Versions of packages gnome-shell recommends:
ii  gdm33.22.0-1
ii  gkbd-capplet   

Bug#838794: cloud-init uses $all in initscripts

[Nicolas Braud-Santoni]

Package: cloud-init
Severity: important

Dear Maintainer,

The cloud-final init script uses the $all virtual facility.
As Lintian explains:

> The given init script declares a dependency on the virtual facility "$all".
> This virtual facility is reserved for local scripts.
> Moreover, using $all in more than one init.d script is totally broken.
> Refer to https://wiki.debian.org/LSBInitScripts for details.


Best,

  nicoo

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

Kernel: Linux 4.6.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages cloud-init depends on:
ii  debconf [debconf-2.0]  1.5.59
ii  ifupdown   0.8.13
ii  init-system-helpers1.44
ii  lsb-release9.20160629
ii  procps 2:3.3.12-2
ii  python33.5.1-4
pn  python3-configobj  
ii  python3-jinja2 2.8-1
pn  python3-jsonpatch  
pn  python3-oauthlib   
pn  python3-prettytable
pn  python3-requests   
pn  python3-serial 
ii  python3-six1.10.0-3
ii  python3-yaml   3.12-1
pn  python3:any

cloud-init recommends no packages.

cloud-init suggests no packages.

Bug#838733: [Debichem-devel] Bug#838733: experimental version of avogadro FTBFS on armel and armhf

[Michael Banck]

Hi Peter,

On Sat, Sep 24, 2016 at 03:19:53AM +0100, peter green wrote:
> package: avogadro
> version: 1.1.1-1~exp3.1
> severity: serious
> X-Debbugs-CC: po...@debian.org, gl...@debian.org, gin...@debian.org,
> mba...@debian.org
> 
> While discussing possible soloutions to bug 833770 Graham Inggs sugested
> >What about uploading version 1.1.1 from experimental to unstable?
> 
> Emilio Pozuelo Monfort pointed out.
> >Note that the experimental version fails to build on armel/armhf (at least).
> 
> I decided to take a look at this.

Thank you for working on it.

The current work-around towards 1.2.0 is disabling the QTAIM extension,
but that would be a shame.

> It appears that Eigen::Vector3d produces a Matrix but
> electronDensity expects a Matrix
> 
> On most architectures qreal is defined as double, so this works but on arm32
> architectures qreal
>  is defined as float so it breaks
> 
> The first thing I tried was changing stuff from qreal to double to make it
> match but that led down a massive rabbit hole.
> 
> So I then took a closer look at what Eigen::Vector3d was. Turns out it's a
> typedef for Eigen::Matrix< double , 3 , 1>
> 
> So it seems the fix is simply to replace Eigen::Vector3d with Eigen::Matrix<
> qreal , 3 , 1>. I've just set off a test build with that change, will report
> results in the morning.

Let us know how it goes.

Also, there'a pull request for 1.2.0 adapting the current Eigen3 patch
which discusses some related problems.  I guess this needs some GUI
testing once it comiles...

The PR is here: https://github.com/cryos/avogadro/pull/38


Michael

Bug#837635: mate-settings-daemon: Segfaults when trying to display OSD notification

[pasky]

Package: mate-settings-daemon
Version: 1.14.1-1
Followup-For: Bug #837635

Note that here, brightness OSD notifications show (but display
brightness level *before* the change, or a similarly weird behavior,
but that's probably for a different bug), but volume keys do cause
the crash; worse, the volume keys have no effect on actual volume.


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

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

Versions of packages mate-settings-daemon depends on:
ii  libatk1.0-0  2.21.90-2
ii  libc62.23-5
ii  libcairo-gobject21.14.6-1+b1
ii  libcairo21.14.6-1+b1
ii  libcanberra-gtk3-0   0.30-3
ii  libcanberra0 0.30-3
ii  libdbus-1-3  1.10.10-1
ii  libdbus-glib-1-2 0.108-1
ii  libdconf10.26.0-1
ii  libfontconfig1   2.11.0-6.7
ii  libfreetype6 2.6.3-3+b1
ii  libgdk-pixbuf2.0-0   2.34.0-1
ii  libglib2.0-0 2.49.6-1
ii  libgtk-3-0   3.21.5-3
ii  libice6  2:1.0.9-1+b1
ii  libmate-desktop-2-17 1.14.1-1
ii  libmatekbd4  1.14.1-1
ii  libmatemixer01.14.0-1
ii  libnotify4   0.7.6-2
ii  libnspr4 2:4.12-2
ii  libnss3  2:3.25-1
ii  libpango-1.0-0   1.40.2-1
ii  libpangocairo-1.0-0  1.40.2-1
ii  libpolkit-gobject-1-00.105-16
ii  libpulse09.0-3
ii  libsm6   2:1.2.2-1+b1
ii  libstartup-notification0 0.12-4
ii  libx11-6 2:1.6.3-1
ii  libxext6 2:1.3.3-1
ii  libxi6   2:1.7.6-1
ii  libxklavier165.4-1
ii  mate-desktop-common  1.14.1-1
ii  mate-polkit [policykit-1-gnome]  1.14.0-1
ii  mate-settings-daemon-common  1.14.1-1
ii  policykit-1-gnome0.105-3
ii  x11-xserver-utils7.7+7

mate-settings-daemon recommends no packages.

mate-settings-daemon suggests no packages.

-- no debconf information

Bug#838793: libgtk-3-0: Menus are too small in GNOME on Wayland

[Tony Houghton]

Package: libgtk-3-0
Version: 3.22.0-1
Severity: important

Since upgrading to 3.22 (I think I was using 3.21 before) many, but not
all, GTK3 applications have broken menus in Wayland. They open very
small with only enough vertical room for scroll arrows and one item, or
less, and far narrower than necessary. Positioning is also incorrect,
and there seems to be some corruption of the content too.

This could be a HiDPI issue because I'm using a Mac Retina, but I
haven't checked another system yet. The affected apps also seem to
ignore the window scaling setting in gnome-tweak-tool, as if it's
hardwried at 2.

One unaffected app is vim-gtk3. I noticed it still depends on gtk 3.19,
so could it be that only apps which have been recompiled against 3.22
are affected?

Launching gedit from a terminal and opening its popup menu shows these
errors:

(gedit:3498): Gtk-WARNING **: gtk_widget_size_allocate(): attempt to
underallocate toplevel GtkWindow 0x5615ae656a40. Allocation is 92x115,
but minimum required size is 173x41.

(gedit:3498): Gtk-WARNING **: gtk_widget_size_allocate(): attempt to
underallocate GtkWindow's child GtkMenu 0x5615aeb4cb40. Allocation is
80x103, but minimum required size is 161x29.

(gedit:3498): Gtk-WARNING **: gtk_widget_size_allocate(): attempt to
underallocate GtkMenuItem's child GtkAccelLabel 0x5615aeb0fd90.
Allocation is 43x17, but minimum required size is 54x17.

(gedit:3498): Gtk-WARNING **: gtk_widget_size_allocate(): attempt to
underallocate GtkMenu's child GtkMenuItem 0x5615af33a190. Allocation is
80x25, but minimum required size is 111x25.

(gedit:3498): Gtk-WARNING **: gtk_widget_size_allocate(): attempt to
underallocate GtkMenuItem's child GtkAccelLabel 0x5615af2d4b70.
Allocation is 17x17, but minimum required size is 73x17.

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

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

Versions of packages libgtk-3-0 depends on:
ii  adwaita-icon-theme  3.22.0-1
ii  hicolor-icon-theme  0.15-1
ii  libatk-bridge2.0-0  2.20.1-4
ii  libatk1.0-0 2.22.0-1
ii  libc6   2.24-3
ii  libcairo-gobject2   1.14.6-1+b1
ii  libcairo2   1.14.6-1+b1
ii  libcolord2  1.3.3-2
ii  libcups22.2.0-2
ii  libepoxy0   1.3.1-1
ii  libfontconfig1  2.11.0-6.7
ii  libfreetype62.6.3-3+b1
ii  libgdk-pixbuf2.0-0  2.36.0-1
ii  libglib2.0-02.50.0-1
ii  libgtk-3-common 3.22.0-1
ii  libjson-glib-1.0-0  1.2.2-1
ii  libpango-1.0-0  1.40.3-2
ii  libpangocairo-1.0-0 1.40.3-2
ii  libpangoft2-1.0-0   1.40.3-2
ii  librest-0.7-0   0.8.0-1
ii  libsoup2.4-12.56.0-1
ii  libwayland-client0  1.11.0-2
ii  libwayland-cursor0  1.11.0-2
ii  libwayland-egl1-mesa [libwayland-egl1]  12.0.3-1
ii  libx11-62:1.6.3-1
ii  libxcomposite1  1:0.4.4-1
ii  libxcursor1 1:1.1.14-1+b1
ii  libxdamage1 1:1.1.4-2+b1
ii  libxext62:1.3.3-1
ii  libxfixes3  1:5.0.2-1
ii  libxi6  2:1.7.6-1
ii  libxinerama12:1.1.3-1+b1
ii  libxkbcommon0   0.6.1-1
ii  libxml2 2.9.4+dfsg1-2
ii  libxrandr2  2:1.5.0-1
ii  shared-mime-info1.7-1

Versions of packages libgtk-3-0 recommends:
ii  libgtk-3-bin  3.21.5-3

Versions of packages libgtk-3-0 suggests:
ii  gvfs 1.30.0-1
ii  librsvg2-common  2.40.16-1

-- no debconf information

Bug#802191: bats: FTBFS: not ok 7 summary passing tests

[Santiago Vila]

severity 802191 serious
thanks

While reviewing unreproducible FTBFS bugs I found this one,
which I can reproduce without any problem at all and it's
not random at all.

I attach five different build logs from four different autobuilders,
using sbuild.

I think downgrading a bug just because it does not happen with
pbuilder is just wrong, because the official buildds use sbuild,
not pbuilder (hence I'm raising to serious again).

If the TERM thing is an essential difference between pbuilder and
sbuild, please consider filing a bug against pbuilder for that.

Tobias, could you please try with sbuild? In case you could still
not reproduce this with sbuild, please contact me privately, maybe
I can lend you a virtual machine as a last resort.

Thanks.

bats_0.4.0-1_amd64-20160924T213546Z.gz
Description: application/gzip


bats_0.4.0-1_amd64-20160924T213559Z.gz
Description: application/gzip


bats_0.4.0-1_amd64-20160924T213603Z.gz
Description: application/gzip


bats_0.4.0-1_amd64-20160924T213606Z.gz
Description: application/gzip


bats_0.4.0-1_amd64-20160924T213608Z.gz
Description: application/gzip

Bug#838789: Fwd: caffe-contrib: FTBFS: libcaffe.so.1.0.0-rc3: undefined reference to `H5LTget_dataset_ndims'

[Mattia Rizzolo]

On Sat, Sep 24, 2016 at 10:51:37PM +0200, Andreas Beckmann wrote:
> This is Bug#838789, but for some reason the BTS considers this as an
> unknown package, so you didn't get this forwarded ...

the reason is still a regression of experimental not having
{Sources,Packages}.gz anymore, but having .xz only.
I poked dondelelcaro several times over IRC, but only get a partial fix
in place.
[this is also the reason this bug came to me: I'm in unknown-package@]

> Oh, you did a source-only upload. That does not work in this case, since
> you have Build-Depends in non-free. You'll always have to do
> source+binary uploads (for *all* architectures you want).

yes.  All good reason to not have such packages, if you ask me...
But for that you need to poke his sponsor, Gianfranco...

> And having a
> source package without binaries for some time seems to have made the
> package "partially disappear" from the archive.

umh?
AFAIK such kind of behaviour only happens with arch:all binaries (where
binaries actually get autoremoved)

>  Forwarded Message 
> Subject: caffe-contrib: FTBFS: libcaffe.so.1.0.0-rc3: undefined
> reference to `H5LTget_dataset_ndims'
> Date: Sat, 24 Sep 2016 22:36:50 +0200
> From: Andreas Beckmann 
> To: Debian Bug Tracking System 
[...]
> In case it does matter:
> This was built against hdf5 1.8.16 from sid, not against 1.10 from
> experimental.
> IIRC some time ago apt changed how Build-Depends are resolved for
> packages in experimental, preferring packages from unstable unless
> a versioned constraint actually requires something from experimental.

that really depends on the resolver you use in your build daemon.  But
that always was the behaviour you had in experimental (unless you used
pbuilder and its broken idea of experimenal from version < 0.224)

-- 
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#836627: grap: please drop the build dependency on hardening-wrapper

[Chris Lamb]

tags 836627 + pending patch
thanks

I've uploaded grap 1.44-1.1 to DELAYED/5:
  
  grap (1.44-1.1) unstable; urgency=medium
  
* Non-maintainer upload.
* Drop Build-Depends on hardening-wrapper; they are automatically set by
  debhelper (with debian/compat level >= 9) when dh_auto_* commands are 
used.
  (Closes: #836627)

The full debdiff is attached.


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
diff -Nru grap-1.44/debian/changelog grap-1.44/debian/changelog
--- grap-1.44/debian/changelog  2014-02-25 23:47:00.0 +0100
+++ grap-1.44/debian/changelog  2016-09-24 23:39:28.0 +0200
@@ -1,3 +1,11 @@
+grap (1.44-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop Build-Depends on hardening-wrapper; automatically used by Debhelper 9
+/ dh_auto_* commands. (Closes: #836627)
+
+ -- Chris Lamb   Sat, 24 Sep 2016 23:39:28 +0200
+
 grap (1.44-1) unstable; urgency=low
 
   * New maintainer. Closes: #615895
diff -Nru grap-1.44/debian/rules grap-1.44/debian/rules
--- grap-1.44/debian/rules  2014-02-25 23:43:47.0 +0100
+++ grap-1.44/debian/rules  2016-09-24 23:39:28.0 +0200
@@ -1,8 +1,5 @@
 #!/usr/bin/make -f
 
-# Use security features with hardening-wrapper
-export DEB_BUILD_HARDENING=1
-
 %:
dh $@
 

Bug#838758: [Pkg-kde-extras] Bug#838758: liblensfun1 packaging

[Pascal Obry]

Hi Pino,

> What's "acm", and how should it be used?

Adobe Camera Model.

> Are you sure you have deb-src lines in your /etc/apt/sources.list (or
> in any *.list file in /etc/apt/sources.list.d/) for the unstable
> distribution, other than stable?

Indeed, my bad :( I had commented out the deb-src line for testing and
unstable.

Fixing that I get the sources for 0.3.2 and It seems that the
LF_DIST_MODEL_ACM is not part of this version. It is on the master
branch. This ticket can be closed.

Sorry for the noise!

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

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

Bug#831174: gcc-avr: diff for NMU version 1:4.9.2+Atmel3.5.0-1.1

[Sebastian Ramacher]

Control: tags 831174 + patch
Control: tags 831174 + pending

Dear maintainer,

I've prepared an NMU for gcc-avr (versioned as 1:4.9.2+Atmel3.5.0-1.1) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.

Regards.

-- 
Sebastian Ramacher
diff -u gcc-avr-4.9.2+Atmel3.5.0/debian/changelog gcc-avr-4.9.2+Atmel3.5.0/debian/changelog
--- gcc-avr-4.9.2+Atmel3.5.0/debian/changelog
+++ gcc-avr-4.9.2+Atmel3.5.0/debian/changelog
@@ -1,3 +1,10 @@
+gcc-avr (1:4.9.2+Atmel3.5.0-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Remove an inlining attribute to fix build under GCC 6 (Closes: #831174)
+
+ -- Andreas Stührk   Sat, 24 Sep 2016 23:11:30 +0200
+
 gcc-avr (1:4.9.2+Atmel3.5.0-1) unstable; urgency=medium
 
   * New upstream release (closes: #790103)
diff -u gcc-avr-4.9.2+Atmel3.5.0/debian/patchlist gcc-avr-4.9.2+Atmel3.5.0/debian/patchlist
--- gcc-avr-4.9.2+Atmel3.5.0/debian/patchlist
+++ gcc-avr-4.9.2+Atmel3.5.0/debian/patchlist
@@ -1,0 +2 @@
+debian_patches/02_gcc6_fixes.diff
only in patch2:
unchanged:
--- gcc-avr-4.9.2+Atmel3.5.0.orig/debian/debian_patches/02_gcc6_fixes.diff
+++ gcc-avr-4.9.2+Atmel3.5.0/debian/debian_patches/02_gcc6_fixes.diff
@@ -0,0 +1,15 @@
+--- gcc.org/cp/cfns.h	2016-09-24 22:42:26.30400 +0200
 gcc/cp/cfns.h	2016-09-24 22:43:03.32400 +0200
+@@ -122,12 +122,6 @@
+   return hval + asso_values[(unsigned char)str[len - 1]];
+ }
+ 
+-#ifdef __GNUC__
+-__inline
+-#ifdef __GNUC_STDC_INLINE__
+-__attribute__ ((__gnu_inline__))
+-#endif
+-#endif
+ const char *
+ libc_name_p (register const char *str, register unsigned int len)
+ {


signature.asc
Description: PGP signature

Bug#838779: Release.gpg not downloaded unless Release is deleted

[David Kalnischkies]

On Sat, Sep 24, 2016 at 09:04:48PM +0200, Michael Stapelberg wrote:
> I tested this in Debian stable (with apt 1.0.9.8.3) and Debian
> testing/experimental (with apt 1.3~rc4 and 1.3, respectively). In Debian
> stable, this works as expected, but in Debian testing and experimental,
> I run into the bug. See the bottom of this report for a full command
> log.

That is a bug, althrough it's about not storing the Release.gpg file if
the Release file isn't stored at the same time – which it isn't if we
already got the latest version in storage – not about not downloading it…

Responsible seems to be apt-pkg/acquire-item.cc:1928 which checks if the
Release file was an IMSHit and only if not stores both files. We should
probably check here if the Release.gpg exists before skipping the
storage. If noone beats me to it I will have a look at patch+test for
next week… it gets a bit late to fiddle with security for today and I am
not really around tomorrow.


> When adding the http://dl.bintray.com/i3/i3-autobuild-ubuntu xenial
> repository, the Release and main_binary-amd64_Packages.lz4 files are
> downloaded and stored in /var/lib/apt/lists. Release.gpg is discarded
> because the necessary public key to verify the signature is not yet
> installed.

Just for the record: lz4 files aren't downloaded. The file downloaded is
likely xz or gz compressed and the current default is to uncompress, but
docker images tend to be configured to store them compressed, which apt
does by uncompressing the xz/gz and recompressing as lz4 on the fly.
Not important for this report, but just for completeness.


> After installing i3-autobuild-keyring, which adds the public key using
> apt-key add, the signature can successfully be verified (apt-get update
> no longer prints an error).

Pretty please with cherry on top don't use 'apt-key add'. Just ship your
keyring in /etc/apt/trusted.gpg.d/ avoiding the need for an installed
gpg. That works for ages now and since recently it even shows warnings.

And while I am suggesting changes: Try to provide an InRelease file,
solves a bunch of problems you likely don't have – but it also "works
around" this bug.


> This seems like a regression to me, and requires an extra step in the
> instructions for our users on how to enable our repository.

I haven't seen the instructions, but the outline you gave with the
commands doesn't look too bright. I don't have to tell you that
--allow-unauthenticated is bad and we are on an active crusade against
it… In fact, your commands just work because you used 'apt-get' and
even there it will stop working in buster. If you had used 'apt' it
would have completely failed the first update already.

I would suggest instructions like (= not tried):

$ /usr/lib/apt/apt-helper download-file http://example.org/keyring.deb 
keyring.deb SHA256:AAA…
# apt install ./keyring.deb
# apt edit-sources yourcoolstuff.list
# apt update

Beside that something like this will work in stretch and beyond it is
also more secure (assuming your users read the instructions on a https
site) as that will automatically validate at least with a hash and
doesn't rely on a user doing a check which most don't… (and which is
very hard to perform in the --allow-unauthenticated pattern even if you
want to).

(keep the URI http:// through as a https:// one needs the optional
-https transport your users might or might not have installed)

If you think that process could be streamlined you are probably right,
but nobody designed and implemented it yet.


Best regards

David Kalnischkies


signature.asc
Description: PGP signature

Bug#838612: ITP: libparams-validationcompiler-perl -- Module to build an optimized subroutine parameter validator

[gregor herrmann]

On Fri, 23 Sep 2016 10:12:39 +0200, Jonas Smedegaard wrote:

> > I also stumbled across this new dependecy some days ago, and I found
> > at https://metacpan.org/pod/Params::ValidationCompiler the
> > description:
> > 
> > "This is very alpha. The module name could change. Everything could
> > change. You have been warned."
> > 
> > which doesn't sound too inviting and maybe hints to waiting a bit
> > before packaging it.
> 
> I think we should!
 
> I looked at these packages recently, and see value in us having them 
> packaged as alternative for Type::Tiny, even if still alpha quality 
> (which I suspect might simply be a leftover warning from earlier days): 
> Type::Tiny lacks a(n active) maintainer¹, so flaws might take longer to 
> fix there than in Specio.

The "alpha status" was not about Specio but about
Params::ValidationCompiler :)
 
Anyway, I take this as yet another reason to go ahead with this set
of packages and will rest my mild concerns.


Cheers,
gregor

-- 
 .''`.  Homepage https://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06
 : :' : Debian GNU/Linux user, admin, and developer -  https://www.debian.org/
 `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   NP: Anouar Brahem: Le Pas Du Chat Noir


signature.asc
Description: Digital Signature

Bug#836760: pwauth: please drop the build dependency on hardening-wrapper

[Chris Lamb]

tags 836760 + pending patch
thanks

pwauth 2.3.11-0.2 uploaded to DELAYED/5. The corresponding debdiff is
attached.


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
diff -Nru pwauth-2.3.11/debian/changelog pwauth-2.3.11/debian/changelog
--- pwauth-2.3.11/debian/changelog  2014-05-06 12:46:28.0 +0200
+++ pwauth-2.3.11/debian/changelog  2016-09-24 22:43:40.0 +0200
@@ -1,3 +1,10 @@
+pwauth (2.3.11-0.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop Build-Depends on hardening-wrapper. (Closes: #836760)
+
+ -- Chris Lamb   Sat, 24 Sep 2016 22:43:40 +0200
+
 pwauth (2.3.11-0.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru pwauth-2.3.11/debian/control pwauth-2.3.11/debian/control
--- pwauth-2.3.11/debian/control2014-05-06 11:43:16.0 +0200
+++ pwauth-2.3.11/debian/control2016-09-24 22:43:40.0 +0200
@@ -2,7 +2,7 @@
 Section: utils
 Priority: optional
 Maintainer: Hai Zaar 
-Build-Depends: debhelper (>= 9~), libpam0g-dev, hardening-includes
+Build-Depends: debhelper (>= 9~), libpam0g-dev
 Standards-Version: 3.8.1
 
 Package: pwauth
diff -Nru pwauth-2.3.11/debian/rules pwauth-2.3.11/debian/rules
--- pwauth-2.3.11/debian/rules  2014-05-06 12:40:51.0 +0200
+++ pwauth-2.3.11/debian/rules  2016-09-24 22:43:40.0 +0200
@@ -1,12 +1,10 @@
 #!/usr/bin/make -f
 
-export DEB_BUILD_MAINT_OPTIONS:=hardening=+all
-
 %:
dh $@
 
 override_dh_auto_build:
-   make CFLAGS="`dpkg-buildflags --get CFLAGS`" LDFLAGS="`dpkg-buildflags 
--get LDFLAGS`" CPPFLAGS="`dpkg-buildflags --get CPPFLAGS`"
+   make $(shell dpkg-buildflags --export=cmdloine)
 
 override_dh_auto_install:
dh_auto_install

Bug#838792: openmw: FTBFS on armhf: error: conflicting declaration for GLsizeiptr

[Andreas Beckmann]

Package: openmw
Version: 0.40.0-1
Severity: serious
Justification: fails to build from source (but built successfully in the past)

Hi,

openmw/experimental FTBFS on armhf:

https://buildd.debian.org/status/fetch.php?pkg=openmw=armhf=0.40.0-1=1474694818

In file included from /usr/include/osg/GL:113:0,
 from /usr/include/osg/GLDefines:25,
 from /usr/include/osg/GLExtensions:18,
 from /usr/include/osg/State:18,
 from /usr/include/osg/GraphicsContext:17,
 from /usr/include/osgViewer/GraphicsWindow:17,
 from /«PKGBUILDDIR»/extern/osgQt/GraphicsWindowQt:19,
 from /«PKGBUILDDIR»/extern/osgQt/GraphicsWindowQt.cpp:14:
/usr/include/GLES2/gl2.h:69:25: error: conflicting declaration 'typedef 
khronos_ssize_t GLsizeiptr'
 typedef khronos_ssize_t GLsizeiptr;
 ^~
In file included from /usr/include/GL/gl.h:2055:0,
 from /usr/include/qt4/QtOpenGL/qgl.h:88,
 from /usr/include/qt4/QtOpenGL/QGLWidget:1,
 from /«PKGBUILDDIR»/extern/osgQt/GraphicsWindowQt:17,
 from /«PKGBUILDDIR»/extern/osgQt/GraphicsWindowQt.cpp:14:
/usr/include/GL/glext.h:468:19: note: previous declaration as 'typedef 
ptrdiff_t GLsizeiptr'
 typedef ptrdiff_t GLsizeiptr;
   ^~
In file included from /usr/include/osg/GL:113:0,
 from /usr/include/osg/GLDefines:25,
 from /usr/include/osg/GLExtensions:18,
 from /usr/include/osg/State:18,
 from /usr/include/osg/GraphicsContext:17,
 from /usr/include/osgViewer/GraphicsWindow:17,
 from /«PKGBUILDDIR»/extern/osgQt/GraphicsWindowQt:19,
 from /«PKGBUILDDIR»/extern/osgQt/GraphicsWindowQt.cpp:14:
/usr/include/GLES2/gl2.h:70:26: error: conflicting declaration 'typedef 
khronos_intptr_t GLintptr'
 typedef khronos_intptr_t GLintptr;
  ^~~~
In file included from /usr/include/GL/gl.h:2055:0,
 from /usr/include/qt4/QtOpenGL/qgl.h:88,
 from /usr/include/qt4/QtOpenGL/QGLWidget:1,
 from /«PKGBUILDDIR»/extern/osgQt/GraphicsWindowQt:17,
 from /«PKGBUILDDIR»/extern/osgQt/GraphicsWindowQt.cpp:14:
/usr/include/GL/glext.h:469:19: note: previous declaration as 'typedef 
ptrdiff_t GLintptr'
 typedef ptrdiff_t GLintptr;
   ^~~~


Andreas

Bug#806867: python-scipy: FTBFS when built with dpkg-buildpackage -A (No module named scipy)

[Julian Taylor]

On 24.09.2016 23:14, Sebastian Humenda wrote:
> Just to let people know: I'm working on it and hope to upload a new package
> shortly.
> 

hm I wanted to do it tomorrow, but if you have it done go ahead.
note there is a new upstream version that should be uploaded to fix
other issues.

Bug#702280: libdbd-mysql-perl / mariadb update

[gregor herrmann]

On Sat, 24 Sep 2016 23:13:17 +0300, Otto Kekäläinen wrote:

> > What I'd like to see is
> > - a confirmation that this is indeed the final decision, since there
> >   was a discussion round default-libmysqlient-dev on -devel after the
> >   announcement;
> Yes, this is the setup we have agreed on, and it might not be perfect,
> but no alternative has or will get more support, so please just
> proceed and build-dep on default-libmysqlclient-dev.

Ok, thanks for the clarification!


Cheers,
gregor

-- 
 .''`.  Homepage https://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06
 : :' : Debian GNU/Linux user, admin, and developer -  https://www.debian.org/
 `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   NP: Anouar Brahem: Le Pas Du Chat Noir


signature.asc
Description: Digital Signature

Bug#806867: python-scipy: FTBFS when built with dpkg-buildpackage -A (No module named scipy)

[Sebastian Humenda]

Just to let people know: I'm working on it and hope to upload a new package
shortly.

Bug#811742: smpeg: diff for NMU version 0.4.5+cvs20030824-7.2

[Manuel A. Fernandez Montecelo]

Hi,

2016-09-24 20:39 GMT+02:00 Sebastian Ramacher :
> Control: tags 811742 + patch
> Control: tags 811742 + pending
>
> Dear maintainer,
>
> I've prepared an NMU for smpeg (versioned as 0.4.5+cvs20030824-7.2) and
> uploaded it to DELAYED/2. Please feel free to tell me if I
> should delay it longer.

Hmm, somehow I missed this RC bug in the last few months when tending
to Debian things -- although, due to time constraints, I've been less
active than in the last few years.

It's fine from my side, thanks!


Cheers.
-- 
Manuel A. Fernandez Montecelo 

Bug#699917: dsc-statistics: Should probably not FTBFS just because of diff being big

[Santiago Vila]

retitle 699917 dsc-statistics: Should probably not FTBFS just because of diff 
being big
tags 699917 + patch
thanks

The bug reported by Thorsten is probably fixed, but only in the sense
that the package does not currently FTBFS.

The underlying bug, the "time bomb" in debian/rules, is still there
(and that's why I'm changing the title).

I don't think packages should fail because of diff being big.

A warning message, maybe, but not a total failure.

So I propose the attached patch. It's annoying enough for a human but
it should be completely harmless for an autobuilder.

[ OTOH, if it is really true that the condition in the "if" block really
  makes repackaging absolutely required, then this bug should just be
  closed. ]

Thanks.--- a/debian/rules
+++ b/debian/rules
@@ -37,8 +37,8 @@ binary-arch:
pdftotext docsrc/dsc-manual.pdf docsrc/dsc-manual.txt
pdftotext doc/dsc-manual.pdf doc/dsc-manual.txt
if [ "$$(wdiff --no-common docsrc/dsc-manual.txt doc/dsc-manual.txt | 
wc -l)" -gt 8 ]; then \
-   echo "too many changes in docs since release, .orig.tar.gz 
repackaging needed"; \
-   exit 1; \
+   echo "too many changes in docs since release, .orig.tar.gz 
repackaging recommended"; \
+   sleep 10; \
fi
cp docsrc/dsc-manual.pdf 
$(CURDIR)/debian/dsc-statistics-collector/usr/share/doc/dsc-statistics-collector/dsc-manual.pdf
dh_install -a

Bug#838791: ITP: python-pydbus -- Pythonic DBus library

[Sebastian Ramacher]

Package: wnpp
Severity: wishlist
Owner: Sebastian Ramacher 

* Package name: python-pydbus
  Version : 0.5.1
  Upstream Author : Janusz Lewandowski 
* URL : https://github.com/LEW21/pydbus
* License : LGPL-2.1+
  Programming Lang: Python
  Description : Pythonic DBus library

 PyGI based bindings for DBus.
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#815036: transition: msgpack-c

[James McCoy]

On Sat, Sep 03, 2016 at 02:10:08PM -0400, James McCoy wrote:
> On Wed, Aug 31, 2016 at 05:01:33PM +0200, Emilio Pozuelo Monfort wrote:
> > Upload msgpack-c to unstable, then you bump the remaining bugs to RC.
> 
> Done.  The tmate maintainer is going to move the compatible version from
> experimental to unstable today.

It looks like everything's transitioned.

Thanks!
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Bug#838789: Fwd: caffe-contrib: FTBFS: libcaffe.so.1.0.0-rc3: undefined reference to `H5LTget_dataset_ndims'

[Andreas Beckmann]

This is Bug#838789, but for some reason the BTS considers this as an
unknown package, so you didn't get this forwarded ...

Oh, you did a source-only upload. That does not work in this case, since
you have Build-Depends in non-free. You'll always have to do
source+binary uploads (for *all* architectures you want). And having a
source package without binaries for some time seems to have made the
package "partially disappear" from the archive.

(source-only uploads works for nvidia-cuda-toolkit since it no longer
Build-Depends on something from the non-free driver)


Andreas

 Forwarded Message 
Subject: caffe-contrib: FTBFS: libcaffe.so.1.0.0-rc3: undefined
reference to `H5LTget_dataset_ndims'
Date: Sat, 24 Sep 2016 22:36:50 +0200
From: Andreas Beckmann 
To: Debian Bug Tracking System 

Source: caffe-contrib
Version: 1.0.0~rc3-2
Severity: serious
Justification: fails to build from source

Hi,

caffe-contrib FTBFS in experimental:

[...]
[100%] Linking CXX executable ../../../test/test.testbin
cd "/build/caffe-contrib-1.0.0~rc3/caffe_cuda_build/src/caffe/test" &&
/usr/bin/cmake -E cmake_link_script CMakeFiles/test.testbin.dir/link.txt
--verbose=1
/usr/bin/g++-5   -g -O2
-fdebug-prefix-map=/build/caffe-contrib-1.0.0~rc3=. -fPIE
-fstack-protector-strong -Wformat -Werror=format-security -Wall
-pedantic -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -Wall -Wno-sign-comp
are -Wno-uninitialized -O3 -DNDEBUG   -fPIE -pie -Wl,-z,relro -Wl,-z,now
-Wl,--as-needed CMakeFiles/test.testbin.dir/test_accuracy_layer.cpp.o
CMakeFiles/test.testbin.dir/test_argmax_layer.cpp.o CMakeFiles/test.tes
tbin.dir/test_batch_norm_layer.cpp.o
CMakeFiles/test.testbin.dir/test_batch_reindex_layer.cpp.o
CMakeFiles/test.testbin.dir/test_benchmark.cpp.o
CMakeFiles/test.testbin.dir/test_bias_layer.cpp.o CMakeFiles/test.tes
tbin.dir/test_blob.cpp.o
CMakeFiles/test.testbin.dir/test_caffe_main.cpp.o
CMakeFiles/test.testbin.dir/test_common.cpp.o
CMakeFiles/test.testbin.dir/test_concat_layer.cpp.o
CMakeFiles/test.testbin.dir/test_contrast
ive_loss_layer.cpp.o
CMakeFiles/test.testbin.dir/test_convolution_layer.cpp.o
CMakeFiles/test.testbin.dir/test_data_layer.cpp.o
CMakeFiles/test.testbin.dir/test_data_transformer.cpp.o
CMakeFiles/test.testbin.dir/te
st_db.cpp.o CMakeFiles/test.testbin.dir/test_deconvolution_layer.cpp.o
CMakeFiles/test.testbin.dir/test_dummy_data_layer.cpp.o
CMakeFiles/test.testbin.dir/test_eltwise_layer.cpp.o
CMakeFiles/test.testbin.dir/test_e
mbed_layer.cpp.o
CMakeFiles/test.testbin.dir/test_euclidean_loss_layer.cpp.o
CMakeFiles/test.testbin.dir/test_filler.cpp.o
CMakeFiles/test.testbin.dir/test_filter_layer.cpp.o
CMakeFiles/test.testbin.dir/test_flatte
n_layer.cpp.o
CMakeFiles/test.testbin.dir/test_gradient_based_solver.cpp.o
CMakeFiles/test.testbin.dir/test_hdf5_output_layer.cpp.o
CMakeFiles/test.testbin.dir/test_hdf5data_layer.cpp.o
CMakeFiles/test.testbin.dir/
test_hinge_loss_layer.cpp.o
CMakeFiles/test.testbin.dir/test_im2col_layer.cpp.o
CMakeFiles/test.testbin.dir/test_image_data_layer.cpp.o
CMakeFiles/test.testbin.dir/test_infogain_loss_layer.cpp.o
CMakeFiles/test.tes
tbin.dir/test_inner_product_layer.cpp.o
CMakeFiles/test.testbin.dir/test_internal_thread.cpp.o
CMakeFiles/test.testbin.dir/test_io.cpp.o
CMakeFiles/test.testbin.dir/test_layer_factory.cpp.o
CMakeFiles/test.testbin.
dir/test_lrn_layer.cpp.o
CMakeFiles/test.testbin.dir/test_math_functions.cpp.o
CMakeFiles/test.testbin.dir/test_maxpool_dropout_layers.cpp.o
CMakeFiles/test.testbin.dir/test_memory_data_layer.cpp.o CMakeFiles/test.
testbin.dir/test_multinomial_logistic_loss_layer.cpp.o
CMakeFiles/test.testbin.dir/test_mvn_layer.cpp.o
CMakeFiles/test.testbin.dir/test_net.cpp.o
CMakeFiles/test.testbin.dir/test_neuron_layer.cpp.o CMakeFiles/test
.testbin.dir/test_platform.cpp.o
CMakeFiles/test.testbin.dir/test_pooling_layer.cpp.o
CMakeFiles/test.testbin.dir/test_power_layer.cpp.o
CMakeFiles/test.testbin.dir/test_protobuf.cpp.o
CMakeFiles/test.testbin.dir/t
est_random_number_generator.cpp.o
CMakeFiles/test.testbin.dir/test_reduction_layer.cpp.o
CMakeFiles/test.testbin.dir/test_reshape_layer.cpp.o
CMakeFiles/test.testbin.dir/test_scale_layer.cpp.o CMakeFiles/test.testb
in.dir/test_sigmoid_cross_entropy_loss_layer.cpp.o
CMakeFiles/test.testbin.dir/test_slice_layer.cpp.o
CMakeFiles/test.testbin.dir/test_softmax_layer.cpp.o
CMakeFiles/test.testbin.dir/test_softmax_with_loss_layer.cp
p.o CMakeFiles/test.testbin.dir/test_solver.cpp.o
CMakeFiles/test.testbin.dir/test_solver_factory.cpp.o
CMakeFiles/test.testbin.dir/test_split_layer.cpp.o
CMakeFiles/test.testbin.dir/test_spp_layer.cpp.o CMakeFiles
/test.testbin.dir/test_stochastic_pooling.cpp.o
CMakeFiles/test.testbin.dir/test_syncedmem.cpp.o
CMakeFiles/test.testbin.dir/test_tanh_layer.cpp.o
CMakeFiles/test.testbin.dir/test_threshold_layer.cpp.o CMakeFiles/t
est.testbin.dir/test_tile_layer.cpp.o
CMakeFiles/test.testbin.dir/test_upgrade_proto.cpp.o

Bug#831117: gtkimageview: diff for NMU version 1.6.4+dfsg-1.1

[Sebastian Ramacher]

Control: tags 831117 + patch
Control: tags 831117 + pending

Dear maintainer,

I've prepared an NMU for gtkimageview (versioned as 1.6.4+dfsg-1.1) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.

Regards.

-- 
Sebastian Ramacher
diff -Nru gtkimageview-1.6.4+dfsg/debian/changelog gtkimageview-1.6.4+dfsg/debian/changelog
--- gtkimageview-1.6.4+dfsg/debian/changelog	2016-02-24 22:20:19.0 +0100
+++ gtkimageview-1.6.4+dfsg/debian/changelog	2016-09-24 21:52:55.0 +0200
@@ -1,3 +1,10 @@
+gtkimageview (1.6.4+dfsg-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix indentation to allow building with GCC 6. (Closes: #831117)
+
+ -- Johannes Brandstätter   Sat, 24 Sep 2016 21:52:55 +0200
+
 gtkimageview (1.6.4+dfsg-1) unstable; urgency=low
 
   * Replace gdk_pixbuf_new_from_inline() with gdk_pixbuf_new_from_resource()
diff -Nru gtkimageview-1.6.4+dfsg/debian/patches/gcc6.patch gtkimageview-1.6.4+dfsg/debian/patches/gcc6.patch
--- gtkimageview-1.6.4+dfsg/debian/patches/gcc6.patch	1970-01-01 01:00:00.0 +0100
+++ gtkimageview-1.6.4+dfsg/debian/patches/gcc6.patch	2016-09-24 21:52:55.0 +0200
@@ -0,0 +1,18 @@
+Description: Fix indentation to allow building with GCC 6.
+Author: Johannes Brandstätter 
+Bug-Debian: https://bugs.debian.org/831117
+Last-Update: <2016-09-24>
+
+--- gtkimageview-1.6.4+dfsg.orig/src/gtkimagenav.c
 gtkimageview-1.6.4+dfsg/src/gtkimagenav.c
+@@ -71,8 +71,8 @@ static Size
+ gtk_image_nav_get_preview_size (GtkImageNav *nav)
+ {
+ 	GdkPixbuf *pixbuf = gtk_image_view_get_pixbuf (nav->view);
+-if (!pixbuf)
+-return (Size){GTK_IMAGE_NAV_MAX_WIDTH, GTK_IMAGE_NAV_MAX_HEIGHT};
++	if (!pixbuf)
++		return (Size){GTK_IMAGE_NAV_MAX_WIDTH, GTK_IMAGE_NAV_MAX_HEIGHT};
+ 	int img_width = gdk_pixbuf_get_width (pixbuf);
+ 	int img_height = gdk_pixbuf_get_height (pixbuf);
+ 
diff -Nru gtkimageview-1.6.4+dfsg/debian/patches/series gtkimageview-1.6.4+dfsg/debian/patches/series
--- gtkimageview-1.6.4+dfsg/debian/patches/series	2016-02-24 22:07:50.0 +0100
+++ gtkimageview-1.6.4+dfsg/debian/patches/series	2016-09-24 21:51:10.0 +0200
@@ -1,2 +1,3 @@
 resource.patch
 g_mem_set_vtable
+gcc6.patch


signature.asc
Description: PGP signature

Bug#798296: Unreproducible

[Tobias Frost]

When provoking TERM to be unset as in #802191, the patch attached to
this bug fixes the FTBFS.

-- 
tobi

Bug#838788: printer-driver-ptouch: Please announce supported hardware using AppStream

[Petter Reinholdtsen]

Package: printer-driver-ptouch
Version: 1.4.2-1
Severity: wishlist
User: p...@hungry.com
Usertags: appstream-modalias

Hi.

The printer-driver-ptouch package is one of the packages in the Debian
archive that should be proposed for installation when a given hardware
dongle is inserted or available.  Thanks to the appstream system, this
can now be announced in a way other tools can use and act on.  I've
written the isenkram system to ask the current user if hardware specific
packages should be installed when a new dongle is installed or already
present on a machine, and isenkram now uses appstream as one source for
hardware to package mappings.

You can read more about this on my blog, 
http://people.skolelinux.org/pere/blog/Using_appstream_with_isenkram_to_install_hardware_related_packages_in_Debian.html
 >.

Instructions on how to create the metadata XML file can be found in
https://wiki.debian.org/AppStream/Guidelines >.

It would be great if you could add an appstream metainfo file to the
printer-driver-ptouch package, with content similar to this:

  
  
   [...]
   
usb:v04F9p2015d*
   
  


If there are other hardware ids or kernel modules also supported by the
package, please add those too. :)

-- 
Happy hacking
Petter Reinholdtsen

Bug#838789: caffe-contrib: FTBFS: libcaffe.so.1.0.0-rc3: undefined reference to `H5LTget_dataset_ndims'

[Andreas Beckmann]

Source: caffe-contrib
Version: 1.0.0~rc3-2
Severity: serious
Justification: fails to build from source

Hi,

caffe-contrib FTBFS in experimental:

[...]
[100%] Linking CXX executable ../../../test/test.testbin
cd "/build/caffe-contrib-1.0.0~rc3/caffe_cuda_build/src/caffe/test" && 
/usr/bin/cmake -E cmake_link_script CMakeFiles/test.testbin.dir/link.txt 
--verbose=1
/usr/bin/g++-5   -g -O2 -fdebug-prefix-map=/build/caffe-contrib-1.0.0~rc3=. 
-fPIE -fstack-protector-strong -Wformat -Werror=format-security -Wall -pedantic 
-Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -Wall -Wno-sign-comp
are -Wno-uninitialized -O3 -DNDEBUG   -fPIE -pie -Wl,-z,relro -Wl,-z,now 
-Wl,--as-needed CMakeFiles/test.testbin.dir/test_accuracy_layer.cpp.o 
CMakeFiles/test.testbin.dir/test_argmax_layer.cpp.o CMakeFiles/test.tes
tbin.dir/test_batch_norm_layer.cpp.o 
CMakeFiles/test.testbin.dir/test_batch_reindex_layer.cpp.o 
CMakeFiles/test.testbin.dir/test_benchmark.cpp.o 
CMakeFiles/test.testbin.dir/test_bias_layer.cpp.o CMakeFiles/test.tes
tbin.dir/test_blob.cpp.o CMakeFiles/test.testbin.dir/test_caffe_main.cpp.o 
CMakeFiles/test.testbin.dir/test_common.cpp.o 
CMakeFiles/test.testbin.dir/test_concat_layer.cpp.o 
CMakeFiles/test.testbin.dir/test_contrast
ive_loss_layer.cpp.o CMakeFiles/test.testbin.dir/test_convolution_layer.cpp.o 
CMakeFiles/test.testbin.dir/test_data_layer.cpp.o 
CMakeFiles/test.testbin.dir/test_data_transformer.cpp.o 
CMakeFiles/test.testbin.dir/te
st_db.cpp.o CMakeFiles/test.testbin.dir/test_deconvolution_layer.cpp.o 
CMakeFiles/test.testbin.dir/test_dummy_data_layer.cpp.o 
CMakeFiles/test.testbin.dir/test_eltwise_layer.cpp.o 
CMakeFiles/test.testbin.dir/test_e
mbed_layer.cpp.o CMakeFiles/test.testbin.dir/test_euclidean_loss_layer.cpp.o 
CMakeFiles/test.testbin.dir/test_filler.cpp.o 
CMakeFiles/test.testbin.dir/test_filter_layer.cpp.o 
CMakeFiles/test.testbin.dir/test_flatte
n_layer.cpp.o CMakeFiles/test.testbin.dir/test_gradient_based_solver.cpp.o 
CMakeFiles/test.testbin.dir/test_hdf5_output_layer.cpp.o 
CMakeFiles/test.testbin.dir/test_hdf5data_layer.cpp.o 
CMakeFiles/test.testbin.dir/
test_hinge_loss_layer.cpp.o CMakeFiles/test.testbin.dir/test_im2col_layer.cpp.o 
CMakeFiles/test.testbin.dir/test_image_data_layer.cpp.o 
CMakeFiles/test.testbin.dir/test_infogain_loss_layer.cpp.o CMakeFiles/test.tes
tbin.dir/test_inner_product_layer.cpp.o 
CMakeFiles/test.testbin.dir/test_internal_thread.cpp.o 
CMakeFiles/test.testbin.dir/test_io.cpp.o 
CMakeFiles/test.testbin.dir/test_layer_factory.cpp.o CMakeFiles/test.testbin.
dir/test_lrn_layer.cpp.o CMakeFiles/test.testbin.dir/test_math_functions.cpp.o 
CMakeFiles/test.testbin.dir/test_maxpool_dropout_layers.cpp.o 
CMakeFiles/test.testbin.dir/test_memory_data_layer.cpp.o CMakeFiles/test.
testbin.dir/test_multinomial_logistic_loss_layer.cpp.o 
CMakeFiles/test.testbin.dir/test_mvn_layer.cpp.o 
CMakeFiles/test.testbin.dir/test_net.cpp.o 
CMakeFiles/test.testbin.dir/test_neuron_layer.cpp.o CMakeFiles/test
.testbin.dir/test_platform.cpp.o 
CMakeFiles/test.testbin.dir/test_pooling_layer.cpp.o 
CMakeFiles/test.testbin.dir/test_power_layer.cpp.o 
CMakeFiles/test.testbin.dir/test_protobuf.cpp.o CMakeFiles/test.testbin.dir/t
est_random_number_generator.cpp.o 
CMakeFiles/test.testbin.dir/test_reduction_layer.cpp.o 
CMakeFiles/test.testbin.dir/test_reshape_layer.cpp.o 
CMakeFiles/test.testbin.dir/test_scale_layer.cpp.o CMakeFiles/test.testb
in.dir/test_sigmoid_cross_entropy_loss_layer.cpp.o 
CMakeFiles/test.testbin.dir/test_slice_layer.cpp.o 
CMakeFiles/test.testbin.dir/test_softmax_layer.cpp.o 
CMakeFiles/test.testbin.dir/test_softmax_with_loss_layer.cp
p.o CMakeFiles/test.testbin.dir/test_solver.cpp.o 
CMakeFiles/test.testbin.dir/test_solver_factory.cpp.o 
CMakeFiles/test.testbin.dir/test_split_layer.cpp.o 
CMakeFiles/test.testbin.dir/test_spp_layer.cpp.o CMakeFiles
/test.testbin.dir/test_stochastic_pooling.cpp.o 
CMakeFiles/test.testbin.dir/test_syncedmem.cpp.o 
CMakeFiles/test.testbin.dir/test_tanh_layer.cpp.o 
CMakeFiles/test.testbin.dir/test_threshold_layer.cpp.o CMakeFiles/t
est.testbin.dir/test_tile_layer.cpp.o 
CMakeFiles/test.testbin.dir/test_upgrade_proto.cpp.o 
CMakeFiles/test.testbin.dir/test_util_blas.cpp.o 
CMakeFiles/cuda_compile.dir/cuda_compile_generated_test_im2col_kernel.cu.o
  -o ../../../test/test.testbin -rdynamic ../../../lib/libgtest.a 
../../../lib/libcaffe.so.1.0.0-rc3 ../../../lib/libproto.a -lboost_system 
-lboost_thread -lboost_filesystem -lboost_chrono -lboost_date_time -lboost
_atomic -lpthread -lpthread -lglog -lgflags -lprotobuf -lhdf5_cpp 
/usr/lib/x86_64-linux-gnu/hdf5/serial/libhdf5.so -lpthread -lpthread -lglog 
-lgflags -lprotobuf -lhdf5_cpp /usr/lib/x86_64-linux-gnu/hdf5/serial/lib
hdf5.so -lsz -lz -ldl -lm -llmdb -lleveldb -lsnappy -lcudart -lcurand -lcublas 
-Wl,-Bstatic -lcublas_device -Wl,-Bdynamic 
/usr/lib/x86_64-linux-gnu/libopencv_highgui.so.2.4.9 
/usr/lib/x86_64-linux-gnu/libopencv_img
proc.so.2.4.9 

Bug#836657: switchsh: please drop the build dependency on hardening-wrapper

[Chris Lamb]

tags 836657 + pending patch
thanks

switchsh 0~20070801-3.3 uploaded to DELAYED/5. The corresponding debdiff is
attached.


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
diff -u switchsh-0~20070801/debian/changelog 
switchsh-0~20070801/debian/changelog
--- switchsh-0~20070801/debian/changelog
+++ switchsh-0~20070801/debian/changelog
@@ -1,3 +1,11 @@
+switchsh (0~20070801-3.3) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop build dependency on hardening-wrapper by moving to dpkg-buildflags.
+(Closes: #836657)
+
+ -- Chris Lamb   Sat, 24 Sep 2016 22:23:00 +0200
+
 switchsh (0~20070801-3.2) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -u switchsh-0~20070801/debian/control switchsh-0~20070801/debian/control
--- switchsh-0~20070801/debian/control
+++ switchsh-0~20070801/debian/control
@@ -2,7 +2,7 @@
 Section: utils
 Priority: optional
 Maintainer: Raphael Geissert 
-Build-Depends: debhelper (>= 5), cdbs, hardening-wrapper, quilt
+Build-Depends: debhelper (>= 5), cdbs, quilt
 Standards-Version: 3.8.0
 Homepage: http://www.linux.it/~md/software/
 XS-DM-Upload-Allowed: yes
diff -u switchsh-0~20070801/debian/rules switchsh-0~20070801/debian/rules
--- switchsh-0~20070801/debian/rules
+++ switchsh-0~20070801/debian/rules
@@ -1,8 +1,6 @@
 #!/usr/bin/make -f
 
-export DEB_BUILD_HARDENING=1
-
-CFLAGS += -pedantic -Werror -Wextra -Wformat -Wformat-security
+CFLAGS += $(shell dpkg-buildflags --get CFLAGS) -pedantic -Werror -Wextra 
-Wformat -Wformat-security
 
 include /usr/share/cdbs/1/rules/debhelper.mk
 include /usr/share/cdbs/1/rules/patchsys-quilt.mk

Bug#802191: bats: FTBFS: not ok 7 summary passing tests

[Tobias Frost]

Control: severity -1 important

I also reproduce this FTBFS in a sid pbuilder enviorment when provoking
an unset TERM:

diff -Naur bats-0.4.0-orig/debian/rules bats-0.4.0/debian/rules
--- bats-0.4.0-orig/debian/rules2014-12-07 06:53:16.0
+0100
+++ bats-0.4.0/debian/rules 2016-09-24 22:23:13.569025103 +0200
@@ -3,6 +3,8 @@
 # output every command that modifies files on the build system.
 #DH_VERBOSE = 1
 
+undefine TERM
+
 # main packaging script based on dh7 syntax
 %:
dh $@

However I cannot reproduce it in a sid pbuilder, so I downgrade this
bug.

--
tobi

On Sun, 18 Oct 2015 09:08:37 +0100 "Chris West (Faux)"  wrote:
> Source: bats
> Version: 0.4.0-1
> Severity: serious
> Justification: fails to build from source
> Tags: sid stretch
> User: reproducible-bui...@lists.alioth.debian.org
> Usertags: ftbfs
> X-Debbugs-CC: reproducible-bui...@lists.alioth.debian.org
> 
> Dear Maintainer,
> 
> The package fails to build:
> 
> make[1]: Entering directory '/bats-0.4.0'
> bin/bats --tap test
> 1..43
> ok 1 no arguments prints usage instructions
> ok 2 -v and --version print version number
> ok 3 -h and --help print help
> ok 4 invalid filename prints an error
> ok 5 empty test file runs zero tests
> ok 6 one passing test
> not ok 7 summary passing tests
> # (in test file test/bats.bats, line 46)
> #   `[ "${lines[1]}" = "1 test, 0 failures" ]' failed
> not ok 8 summary passing and skipping tests
> # (in test file test/bats.bats, line 52)
> #   `[ "${lines[2]}" = "2 tests, 0 failures, 1 skipped" ]' failed
> not ok 9 summary passing and failing tests
> # (in test file test/bats.bats, line 58)
> #   `[ "${lines[4]}" = "2 tests, 1 failure" ]' failed
> not ok 10 summary passing, failing and skipping tests
> # (in test file test/bats.bats, line 64)
> #   `[ "${lines[5]}" = "3 tests, 1 failure, 1 skipped" ]' failed
> ok 11 one failing test
> ok 12 one failing and one passing test
> 
> 
> 
> debian/rules:14: recipe for target 'override_dh_auto_test' failed
> make[1]: *** [override_dh_auto_test] Error 1
> make[1]: Leaving directory '/bats-0.4.0'
> 
> Full build log:
> https://reproducible.debian.net/rb-pkg/unstable/amd64/bats.html
> 
> -- System Information:
> Debian Release: stretch/sid
> APT prefers unstable
> APT policy: (500, 'unstable')
> Architecture: amd64 (x86_64)
> 
> 

Bug#838787: libboost1.61-doc doesn't contain the actual documentation

[Evgeny Kapun]

Package: libboost1.61-doc
Version: 1.61.0+dfsg-2.1

The package libboost1.61-doc is supposed to include Boost documentation. It 
doesn't. All I can see in /usr/share/doc/libboost1.61-doc/HTML is a symlink to 
/usr/include/boost. There are some HTML files in 
/usr/share/doc/libboost1.61-doc/examples, but they only document the examples 
(also, most links in those files are broken).

Bug#657877: collectd: Does not try to reconnect when rrd daemon dies

[Sebastian Harl]

Hi,

On Thu, Aug 20, 2015 at 11:40:13AM +0200, Sebastian Harl wrote:
> On Sun, Jan 29, 2012 at 04:20:14PM +0100, Matthias Urlichs wrote:
> > When collectd logs via rrdcached, and rrdcached is restarted, 
> > collectd spews errors instead of trying to reconnect.
> 
> Thanks for reporting this and sorry for the slow reply :-/
> 
> This issue is related to how the rrdcached client library works. It only
> supports a single connection and caches that in a global variable.
> collectd calls rrdc_connect on each write but the function will simple
> return success if it succeeded previously.
> 
> I think what we'll have to do is
> (a) in collectd, close the connection on error and, thus, trigger an
> actual reconnect; possibly use exponential back-off

I've got https://github.com/collectd/collectd/pull/1959 pending for
this.

> (b) improve the RRDtool API ;-)

And https://github.com/oetiker/rrdtool-1.x/pull/742 for this.

Cheers,
Sebastian

-- 
Sebastian "tokkee" Harl +++ GnuPG-ID: 0x2F1FFCC7 +++ http://tokkee.org/

Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin



signature.asc
Description: Digital signature

Bug#837105: jessie-pu: package python-werkzeug/0.9.6+dfsg-1

[Adam D. Barratt]

Control: tags -1 + pending

On Thu, 2016-09-08 at 21:25 +0100, Adam D. Barratt wrote:
> Control: tags -1 +confirmed -moreinfo
> 
>  On Thu, 2016-09-08 at 22:21 +0200, Ondrej Novy wrote:
> > Hi,
> > 
> > 
> > 2016-09-08 21:39 GMT+02:00 Adam D. Barratt :
> > Please provide a full source debdiff for the proposed package
> > (built and
> > tested on jessie).
> > 
> > 
> > debdiff attached (which is same as linked patched)
> 
> You'd be surprised how often they're not the same (also in any case bug
> reports should stand alone, not rely on links to other resources).
> 
> > and (of course) already tested.
> 
> Again, you'd be surprised... :P
> 
> Please go ahead.

Uploaded and flagged for acceptance.

Regards,

Adam

Bug#838786: debpear: error 'cp: target ‘yaml-1.2.0.orig.tar.gz’ is not a directory'

[rohieb]

Package: debpear
Version: 0.4
Severity: normal

Dear Maintainer,

I tried installing php-yaml from PECL, but the script errored out with the error
message given above.  I'm lost and I don't know (yet) what to do.

Here is what happens when I run the script with set -x:

-- 8< --
$ debpear -c pecl yaml
+ PHPPKGINFO=/usr/share/pkg-php-tools/scripts/phppkginfo
+ DO_INSTALL=no
+ PEAR_CHANNEL=pear.php.net
+ BUILD_DIR=./build-area
+ VERBOSE=no
+ [ -z pecl ]
+ grep -w ^pecl.txt
+ cut -d/ -f7
+ grep .alias/
+ dpkg -L pear-channels
+ [ -z  -a pecl != pecl -a pecl != pear ]
+ PEAR_CHANNEL=pecl
+ shift
+ shift
+ [ 1 != 1 ]
+ PEAR_PKG_NAME=yaml
+ [ -z yaml ]
+ echoIfVerbose debpear ===> Preparing build area in ./build-area
+ [ no = yes ]
+ /usr/share/pkg-php-tools/scripts/phppkginfo debian_pkgname pecl yaml
+ DEB_PKG_NAME=php-yaml
+ [ -d ./build-area ]
+ [ -n  ]
+ cd ./build-area
+ [ -z  ]
+ [ -z pecl ]
+ pear download pecl/yaml
downloading yaml-1.2.0.tgz ...
Starting to download yaml-1.2.0.tgz (38,606 bytes)
..done: 38,606 bytes
File /home/rohieb/php-yaml-2.0.0~rc8+1.3.0~b1/build-area/yaml-1.2.0.tgz 
downloaded
+ grep yaml
+ ls
+ DOWNLOADED_PEAR_PKG=php-yaml-1.2.0
php-yaml_1.2.0.orig.tar.gz
yaml-1.2.0.tgz
+ awk {printf length($0)}
+ echo php-yaml-1.2.0 php-yaml_1.2.0.orig.tar.gz yaml-1.2.0.tgz
+ FILENAME_LEN=56
+ awk {printf length($0)}
+ echo yaml
+ PEAR_PKG_NAME_LEN=4
+ VERSION_START=6
+ VERSION_LEN=47
+ awk {printf substr($0,6,47)}
+ echo php-yaml-1.2.0 php-yaml_1.2.0.orig.tar.gz yaml-1.2.0.tgz
+ VERSION_STRING=aml-1.2.0 php-yaml_1.2.0.orig.tar.gz yaml-1.2.0
+ DEB_SRC_FOLDER=php-yaml-aml-1.2.0 php-yaml_1.2.0.orig.tar.gz yaml-1.2.0
+ DEB_PKG_RESULT=php-yaml_aml-1.2.0 php-yaml_1.2.0.orig.tar.gz 
yaml-1.2.0-1_all.deb
+ DEB_BIN_PKG_NAME=php-yaml
+ cp php-yaml-1.2.0 php-yaml_1.2.0.orig.tar.gz yaml-1.2.0.tgz 
php-yaml_aml-1.2.0 php-yaml_1.2.0.orig.tar.gz yaml-1.2.0.orig.tar.gz
cp: target ‘yaml-1.2.0.orig.tar.gz’ is not a directory

-- >8 --


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

Kernel: Linux 3.16.0-4-amd64 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages debpear depends on:
ii  build-essential  11.7
ii  devscripts   2.15.3+deb8u1
ii  fakeroot 1.20.2-1
ii  pear-channels0~20141011-1
ii  php-pear 5.6.24+dfsg-0+deb8u1
ii  pkg-php-tools1.28

debpear recommends no packages.

debpear suggests no packages.

-- no debconf information

Bug#831961: proftpd-dfsg: FTBFS with dpkg-buildpackage -A: make: *** No rule to make target 'build-indep'. Stop.

[Hilmar Preuße]

On 24.09.2016 11:29, Adrian Bunk wrote:
> On Wed, Aug 24, 2016 at 04:25:07PM -0700, Mahyuddin Susanto wrote:

Hi Adrian,

>> I have committed to proftpd-pkg git repository,
>> I will upload to mentos once the other diff has completed.
>> ...
> 
> what is the status of fixing this Release Critical bug?
> 
We have 3 RC bugs on proftp. For two of them there is a fix in git.
For the third one I/we do not know how to solve it (tag "help" is set).
I'd rather upload a fix for all of these three, as the uploaded package
won't migrate to testing if the third is still present.

I you disagree drop us a note.

Hilmar
-- 
http://www.hilmar-preusse.de.vu/   #206401 http://counter.li.org

Bug#831844: [debian-mysql] Bug#831844: mysql-5.6: Multiple security fixes from the July 2016 CPU

[Otto Kekäläinen]

Hello!

2016-09-22 18:10 GMT+03:00 Dominic Hargreaves :
>
> As I need to have a MySQL 5.6 backport supported for the foreseeable
> future, I intend to NMU a new upstream release in the next few weeks.
>
> Does anyone have any objections to this?

I've accepted your Alioth join request.

So you only plan to upload to backports..? If you upload to unstable,
please note that the mysql-5.6 source is missing some important
packaging changes done in mysql-5.7 for Debian unstable (split to
mysql-defaults etc) and anyway uploading mysql-5.6 to unstable anymore
is not recommended, as mysql-5.7 is about to overtake it.

- Otto

Bug#838777: Policy 11.8.4 for x-window-manager needs update for freedesktop menus

[Josh Triplett]

On Sat, Sep 24, 2016 at 12:57:04PM -0700, Russ Allbery wrote:
> Josh Triplett  writes:
> 
> > Based on some conversations on #debian-devel on the purpose of
> > x-window-manager (as launched by
> > /etc/X11/Xsession.d/50x11-common_determine-startup), it seems like a
> > window manager that just manages windows, and expects a separately
> > launched menu/taskbar program or desktop environment to provide the
> > ability for the user to launch programs or otherwise do anything useful,
> > shouldn't register an x-window-manager alternative at all.  Otherwise,
> > the user might end up staring at a desktop they can't interact with at
> > all.
> 
> Er, this seems to imply that twm shouldn't register as x-window-manager,
> which sounds wrong and isn't how Debian has ever worked.  Or am I
> misunderstanding what you mean by "just manages windows"?

twm has a menu to launch additional applications; left-click on the
desktop.  So, it should continue registering an x-window-manager
alternative.

I'm talking about window managers like metacity or mutter, which without
an associated desktop environment provide no way to launch applications
or even exit.

> I realize that nearly everyone uses a desktop environment these days, but
> it used to be very common to just launch a windows manager and then use
> ~/.xsession to launch some xterms, and I don't think we want to break that
> functionality unless something is actually broken now.  I'm sure someone
> is still doing this.  Last time I checked, startx relies on the
> x-window-manager alternative to figure out what to start, so removing that
> alternative would break such a setup.

That uses the Xsession mechanism (and specifically the
/etc/X11/Xsession.d/50x11-common_determine-startup script that I
mentioned above).  Keeping that from breaking was exactly my concern
here: launching an X session should never leave the user with no way to
launch applications or exit (other than switching to another VT).

Bug#838785: funnelweb: please make the build reproducible

[Reiner Herrmann]

Source: funnelweb
Version: 3.2-5
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: locale
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Hi!

While working on the "reproducible builds" effort [1], we have noticed
that funnelweb could not be built reproducibly.
It uses a wildcard to collect object files, which are sorted differently
depending on the locale.

The attached patch fixes this by printing the files with LC_ALL set to C.

Regards,
 Reiner

[1]: https://wiki.debian.org/ReproducibleBuilds
diff --git a/debian/rules b/debian/rules
index 8e4996b..d7a13e5 100755
--- a/debian/rules
+++ b/debian/rules
@@ -15,7 +15,7 @@ LDFLAGS  ?= $(shell dpkg-buildflags --get LDFLAGS)
 override_dh_auto_build:
 	(cd source && \
 	 $(CC) $(CPPFLAGS) $(CFLAGS) -c *.c && \
-	 $(CC) $(CFLAGS) $(LDFLAGS) -o fw *.o)
+	 $(CC) $(CFLAGS) $(LDFLAGS) -o fw `LC_ALL=C ls *.o`)
 
 override_dh_auto_clean:
 	rm -f source/fw source/*.o


signature.asc
Description: PGP signature

Bug#702280: libdbd-mysql-perl / mariadb update

[Otto Kekäläinen]

Hello!

2016-09-24 19:29 GMT+03:00 gregor herrmann :
> What I'd like to see is
> - a confirmation that this is indeed the final decision, since there
>   was a discussion round default-libmysqlient-dev on -devel after the
>   announcement;

Yes, this is the setup we have agreed on, and it might not be perfect,
but no alternative has or will get more support, so please just
proceed and build-dep on default-libmysqlclient-dev.

- Otto

Bug#838784: bash: Optionally append '/' to globbed directories (GLOB_MARK)

[Marc-Jano Knopp]

Package: bash
Version: 4.4-1
Severity: wishlist
Tags: upstream

{ Tried to submit this bug via 'bashbug' to no avail due to my e-mails
being rejected by the specified recipients, so let's try 'reportbug' ... }

Description
---

I would like to be able to configure bash so that directory
names that are the result of globbing have a slash ('/')
appended to their name. Currently, this seems to be only
possible for /completion/ (by means of the readline variable
'mark-directories'), but not for /globbing/.

Analogous to nullglob, dotglob etc., I suggest a shell option
named 'markglob', that can be set/unset by 'shopt'.


Repeat-By
-

Current behavior:
  $ mkdir foobar
  $ echo foob*
  foobar
  $

Desired behavior (only if configured to do so):
  $ mkdir foobar
  $ echo foob*
  foobar/
  $

Example for zsh's implementation of desired configurable
feature:
  $ mkdir foobar
  $ echo foob*
  foobar
  $ setopt MARK_DIRS
  $ echo foob*
  foobar/
  $

Fix
---
glob(3) has a flag 'GLOB_MARK' that seems to exhibit the
desired behavior, at least from the description:

  GLOB_MARK
  Append a slash to each path which corresponds to a
  directory.

So maybe shell_glob_filename() in pathexp.c and the
appropriate parts of builtins/shopt.def can be relatively
easily modified to add the desired feature.


-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (501, 'testing'), (50, 'unstable'), (25, 'experimental'), (12, 
'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.6.0-1-amd64 (SMP w/6 CPU cores)
Locale: LANG=en_US.ISO-8859-15, LC_CTYPE=en_US.ISO-8859-15 (charmap=ISO-8859-15)
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)

Versions of packages bash depends on:
ii  base-files   9.6
ii  dash 0.5.8-2.3
ii  debianutils  4.8
ii  libc62.23-5
ii  libtinfo56.0+20160625-1

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

Versions of packages bash suggests:
pn  bash-doc  

-- no debconf information

Bug#836934: frobtads: FTBFS with GCC 6: error: exception cleanup for this placement new selects non-placement operator delete

[Andreas Beckmann]

Control: reopen -1

On 2016-09-24 20:46, Sebastian Ramacher wrote:
> On 2016-09-07 13:09:40, Andreas Beckmann wrote:
>> frobtads FTBFS since the default compiler was switched to GCC 6 (which
>> defaults to -std=c++14):
>>
>> g++ -DHAVE_CONFIG_H -I. -I/build/frobtads-1.2.3/.  -DFROBTADS -DTC_TARGET_T3 
>> -DTADSNET  -DOS_DECLARATIVE_TLS  -DVMGLOB_VARS  -D_M_IX86_64 -DRUNFAST 
>> -I/build/frobtads-1.2.3/./src -I/build/frobtads-1.2.3/./tads2 
>> -I/build/frobtads-1.2.3/./tads3 -I/build/frobtads-1.2.3/./tads3/unix  
>> -DT3_INC_DIR=\"/usr/share/frobtads/tads3/include\" 
>> -DT3_LIB_DIR=\"/usr/share/frobtads/tads3/lib\" 
>> -DT3_RES_DIR=\"/usr/share/frobtads/tads3/res\" 
>> -DT3_LOG_FILE=\"/tmp/frob.log\" -I/build/frobtads-1.2.3/./src 
>> -I/build/frobtads-1.2.3/./tads2 -I/build/frobtads-1.2.3/./src 
>> -I/build/frobtads-1.2.3/./tads3 -I/build/frobtads-1.2.3/./tads3/test 
>> -Wdate-time -D_FORTIFY_SOURCE=2  -g -O2 
>> -fdebug-prefix-map=/build/frobtads-1.2.3=. -fstack-protector-strong -Wformat 
>> -Werror=format-security -fno-strict-aliasing -pthread -c -o tads3/tcprs.o 
>> /build/frobtads-1.2.3/./tads3/tcprs.cpp
>> In file included from /build/frobtads-1.2.3/./tads3/tcprs.cpp:39:0:
>> /build/frobtads-1.2.3/./tads3/vmbignum.h: In static member function 'static 
>> vm_obj_id_t CVmObjBigNum::create(int, const bignum_t*)':
>> /build/frobtads-1.2.3/./tads3/vmbignum.h:585:45: error: exception cleanup 
>> for this placement new selects non-placement operator delete [-fpermissive]
>>  new (vmg_ id) CVmObjBigNum(vmg_ prec);

> frobtads builds fine in todays sid. Closing.

Nope. It builds fine on amd64, but fails on i386 (both in pbuilder on an
amd64 host).

Andreas

Bug#838777: Policy 11.8.4 for x-window-manager needs update for freedesktop menus

[Russ Allbery]

Josh Triplett  writes:

> Based on some conversations on #debian-devel on the purpose of
> x-window-manager (as launched by
> /etc/X11/Xsession.d/50x11-common_determine-startup), it seems like a
> window manager that just manages windows, and expects a separately
> launched menu/taskbar program or desktop environment to provide the
> ability for the user to launch programs or otherwise do anything useful,
> shouldn't register an x-window-manager alternative at all.  Otherwise,
> the user might end up staring at a desktop they can't interact with at
> all.

Er, this seems to imply that twm shouldn't register as x-window-manager,
which sounds wrong and isn't how Debian has ever worked.  Or am I
misunderstanding what you mean by "just manages windows"?

I realize that nearly everyone uses a desktop environment these days, but
it used to be very common to just launch a windows manager and then use
~/.xsession to launch some xterms, and I don't think we want to break that
functionality unless something is actually broken now.  I'm sure someone
is still doing this.  Last time I checked, startx relies on the
x-window-manager alternative to figure out what to start, so removing that
alternative would break such a setup.

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

Bug#822555: ffmpeg: please compile with --enable-libtesseract

[Sebastian Ramacher]

Hi

On 2016-09-07 03:33:38, Bálint Réczey wrote:
> Control: tags -1 confirmed patch
> 
> Hi Jan,
> 
> 2016-04-25 12:43 GMT+02:00 Jan Gerber :
> > Package: ffmpeg
> > Version: 7:3.0.1-3
> > Severity: wishlist
> >
> > Dear Maintainer,
> >
> > FFmpeg 3.0 introduced a new ocr filter that depends on libtesseract.
> > Would be nice to see this enabled in Debian.
> 
> I have prepared a patch which may be enough.
> It needs testing however. Sebastian, what do you think?

I'm not a huge fan of adding more -extra flavors [1], but the patch looks 
okayish.
The dh_auto_build-arch override may need to be updated, though.

Cheers

[1] If we wouldn't have had libavcodec-extra for libav, I'd even drop the
libavcodec-extra flavor.
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#836192: transition: libdap

[Sebastiaan Couwenberg]

This transition should be done, time to close this bugreport?

Bug#836447: transition: proj

[Sebastiaan Couwenberg]

This transition should be done, time to close this bugreport?

Bug#838783: hplip: Please announce supported hardware using AppStream

[Petter Reinholdtsen]

Package: hplip
Version: 3.16.8+repack0-2
Severity: wishlist
User: p...@hungry.com
Usertags: appstream-modalias

Hi.

The hplip package is one of the packages in the Debian archive that
should be proposed for installation when a given hardware dongle is
inserted or available.  Thanks to the appstream system, this can now be
announced in a way other tools can use and act on.  I've written the
isenkram system to ask the current user if hardware specific packages
should be installed when a new dongle is installed or already present on
a machine, and isenkram now uses appstream as one source for hardware to
package mappings.

You can read more about this on my blog, 
http://people.skolelinux.org/pere/blog/Using_appstream_with_isenkram_to_install_hardware_related_packages_in_Debian.html
 >.

Instructions on how to create the metadata XML file can be found in
https://wiki.debian.org/AppStream/Guidelines >.

It would be great if you could add an appstream metainfo file to the
hplip package, with content similar to this:

  
  
   [...]
   
usb:v03F0p0004d*
usb:v03F0p0104d*
usb:v03F0p0111d*
usb:v03F0p0204d*
usb:v03F0p0304d*
usb:v03F0p0311d*
usb:v03F0p0404d*
usb:v03F0p0504d*
usb:v03F0p0604d*
usb:v03F0p0704d*
usb:v03F0p0712d*
usb:v03F0p0804d*
usb:v03F0p0904d*
usb:v03F0p1004d*
usb:v03F0p1104d*
usb:v03F0p1151d*
usb:v03F0p1204d*
usb:v03F0p1504d*
usb:v03F0p1604d*
usb:v03F0p1904d*
usb:v03F0p1C17d*
usb:v03F0p1E11d*
usb:v03F0p2004d*
usb:v03F0p2104d*
usb:v03F0p2304d*
usb:v03F0p2811d*
usb:v03F0p2D11d*
usb:v03F0p3102d*
usb:v03F0p3104d*
usb:v03F0p3304d*
usb:v03F0p3404d*
usb:v03F0p3504d*
usb:v03F0p3C02d*
usb:v03F0p3D11d*
usb:v03F0p3F11d*
usb:v03F0p5004d*
usb:v03F0p6004d*
usb:v03F0p6104d*
usb:v03F0p6204d*
usb:v03F0p6602d*
usb:v03F0p7004d*
usb:v03F0p7104d*
usb:v03F0p7204d*
usb:v03F0p7304d*
usb:v03F0pA004d*

  


If there are other hardware ids or kernel modules also supported by the
package, please add those too. :)

-- 
Happy hacking
Petter Reinholdtsen

Bug#830580: Please also add "Provides: vim"

[Josh Triplett]

On Sat, Sep 24, 2016 at 01:14:07PM -0400, James McCoy wrote:
> On Mon, Jul 11, 2016 at 01:35:22PM -0700, Josh Triplett wrote:
> > From da7da47191265c5a376c7e32726941621e47e60c Mon Sep 17 00:00:00 2001
> > From: Josh Triplett 
> > Date: Mon, 11 Jul 2016 13:33:59 -0700
> > Subject: [PATCH 2/2] Provides: vim
> > 
> > This allows vim addon packages that depend on vim to run with neovim
> > without having vim installed.
> 
> Actually, that won't currently work because nvim and vim look in
> different places for their addons.  Also, not all addons work with nvim.
> 
> vim-addon-manager, and the addon policy, need to be updated to support
> specifying whether addons are compatible with nvim and/or vim, and
> handle installation appropriately.

Hopefully that'll get a lot easier if addons start providing packages.
And ideally, addons that only support one or the other should include
that detection internally, not externally.

Bug#830580: Patch to install alternatives

[Josh Triplett]

On Sat, Sep 24, 2016 at 01:10:18PM -0400, James McCoy wrote:
> Thanks for the patch!
> 
> On Sun, Jul 10, 2016 at 11:27:23PM -0700, Josh Triplett wrote:
> > From 8d4641be71797ef7d54a3067f2c15cb374b73b16 Mon Sep 17 00:00:00 2001
> > From: Josh Triplett 
> > Date: Sun, 10 Jul 2016 23:21:37 -0700
> > Subject: [PATCH] Install alternatives for ex, rvim, rview, vi, vim, view, 
> > and
> >  vimdiff
> 
> I don't think it makes sense to install an alternative for vi.  Neovim
> is explicitly dropping various "vi compatibility" pieces of
> functionality.

Neovim is still an implementation of vi, and acts like vi; it just
doesn't keep "bug-compatibility".  If you didn't have any other vi
implementation installed, I think it still makes sense for "vi" to
invoke nvim.

That said, I don't personally use the "vi" alternative, so I won't push
hard for that one.  But I do think it'd surprise users if they had
neovim installed yet the "vi" alternative didn't work.

> vimdiff and view I understand, since there are tools that explicitly
> launch them (and the latter is registered in the mime system with the
> vim packaging).

Both of those motivated this patch in the first place: vimdiff because
"git mergetool" invokes it, and view because my fingers are used to
typing it. :)

> ex, rvim, and rview I'm more on the fence about.  I guess it makes sense
> to provide them, since Neovim should be mostly a drop-in replacement.

And since Neovim does specifically have those modes available.

> > diff --git a/debian/neovim.postinst b/debian/neovim.postinst
> > index 9c30db0..9c66ca4 100644
> > --- a/debian/neovim.postinst
> > +++ b/debian/neovim.postinst
> > @@ -5,6 +5,13 @@ set -e
> >  update-alternatives --install /usr/bin/editor editor /usr/bin/nvim 30 \
> >  --slave /usr/share/man/man1/editor.1.gz editor.1.gz \
> >  /usr/share/man/man1/nvim.1.gz
> > +update-alternatives --install /usr/bin/ex ex /usr/bin/ex.nvim 29
> 
> Why are these alternatives 29 when editor is on-par with vim.basic at
> 30?

I was trying to be conservative, to avoid surprising anyone who installs
neovim to experiment with it but expects "vim" to have complete vim
compatibility.

I don't have any objection to changing this, but I do think it might
surprise people.

- Josh Triplett

Bug#838782: linux-image-4.8.0-rc5-amd64-unsigned: Screen under X gets black for 1-2 seconds very often on Intel Skylake with onboard gfx, most time while using the mouse's scroll wheel

[Axel Beckert]

Package: src:linux
Version: 4.8~rc5-1~exp1
Severity: important

Dear Debian Linux Kernel Maintainers,

when running under kernel 4.8rc5, the following (rather annoying) issue
is easily reproducible for me on my desktop PC running Debian Unstable:

If I use my mouse[1]'s scroll wheel on an application which supports
scrolling via the mouse wheel (e.g. uxterm, emacs24-lucid, liferea or
conkeror, sometimes even on the desktop background), the screen[2] gets
completely black for 1-2 seconds and then everything is back to normal.

Scrolling sidewards inside Emacs using the tiltable scrollwheel of my
mouse[1] causes the same issues, at least in Emacs.

[1] Bus 001 Device 003: ID 046d:c069 Logitech, Inc. M-U0007 [Corded
Mouse M500]
[2] In case of multiple screens, only the one on which the mouse cursor
is located at that time becomes black.

That's how I can reproduce it very quickly despite not
always. Nevertheless it happens often enough to be very annoying and
I can't do any serious work while running under 4.8rc5 without
concentrating a lot on not using the scroll-wheel.

Scrolling quickly initially seems to trigger the issue more often, but
if it has been triggered once, _every_, even the slowest move of the
scroll-wheel triggers the issue again if it happens within a dozen of
seconds or so.

But there are also other things which can trigger it. So far I noticed
the following:

* Switching i3's currently displayed desktop using keybindings (e.g. by
  pressing the key combination -<1>). Happened a few times in this
  X session[4], but then again I needed to switch desktops rather seldom
  for writing just a bug report.)

* Using the trackpoint on my Lenovo Thinkpad USB Keyboard[3]. Happens
  seldom enough so that the felt trigger might be a coincidence. (Once
  in this X session[4].)

* Scrolling in less inside the uxterm with cursor keys or by pressing
  Shift-G. Happens occassionally, 3 or 4 times in this X session[4].)

[3] Bus 001 Device 004: ID 17ef:6009 Lenovo ThinkPad Keyboard with
TrackPoint
[4] X session running for about 1 hour now now.

What didn't make the issues go away:

* Downgrading MESA-related packages which approximately had an upstream
  version bump in Debian when the issues appeared.

* Uninstalling or installing i965-va-driver.

* Installing firmware-misc-nonfree.

* Changing the monitor or the monitor connector. (It happens with both,
  an AOC Full-HD screen[5] bought this year and connected via Display
  Port, as well as with an Samsung Full-HD screen[6] connected via
  either VGA or DVI.)

[5] (II) modeset(0): Manufacturer: AOC  Model: 2269  Serial#: 1527
[6] (II) modeset(0): Monitor name: SyncMaster
[Labeled as "SyncMaster 2343 BW"]

What makes the issue go away:

* Booting into linux-image-4.7.0-1-amd64-unsigned (4.7.4-2).

Additional, maybe related issues which don't show up with kernel 4.7
either:

* Approximately Application menu sized rectangular flickering every few
  to dozen seconds in the top left corner (or in the top right corner if
  the screen is used edgewise): often while typing but sometimes also
  without any input triggers.

* A flickering kind of scrolling of the whole screen contents.
  Occassionally happens before the whole screen gets blacks, i.e. can
  also be triggered by scrolling with the mouse wheel.

Additional information:

* I didn't notice any log entries in neither /var/log/kern.log,
  /var/log/syslog, /var/log/Xorg.0.log, nor ~/.xsession-errors when the
  screen goes black.

* Scrolling works fine despite the screen goes black.

* If I continue to use the scroll-wheel while the screen blacked out
  (with mouse cursor on the same screen), it continues to stay black
  until I stop scrolling and wait for 1-2 additional seconds. Then the
  screen comes back.

* Moving the mouse cursor to another screen while scrolling and the
  screen having become black has the same effect as stopping to use the
  scroll-wheel.

* Haven't noticed the same issue with the only other computer where I've
  tried that kernel so far: My Thinkpad X250 also has a Intel CPU and
  graphics card, but is from the Haswell generation. Works fine so far.

-- Package-specific info:
** Version:
Linux version 4.8.0-rc5-amd64 (debian-ker...@lists.debian.org) (gcc version 
5.4.1 20160904 (Debian 5.4.1-2) ) #1 SMP Debian 4.8~rc5-1~exp1 (2016-09-07)

** Command line:
BOOT_IMAGE=/vmlinuz-4.8.0-rc5-amd64 root=/dev/mapper/vgc6-root ro quiet

** Tainted: E (8192)
 * Unsigned module has been loaded (currently expected).

** Kernel log:
[   12.276352] [drm] Initialized drm 1.1.0 20060810
[   12.284364] i801_smbus :00:1f.4: SMBus using PCI interrupt
[   12.354964] EFI Variables Facility v0.08 2004-May-17
[   12.355241] input: PC Speaker as /devices/platform/pcspkr/input/input9
[   12.359190] pstore: using zlib compression
[   12.359195] pstore: Registered efi as persistent store backend
[   12.372379] ppdev: user-space parallel port driver
[   12.377205] iTCO_vendor_support: 

Bug#838780: jessie-pu: package irssi/0.8.17-1+deb8u1

[Adam D. Barratt]

Control: tags -1 + moreinfo

On Sat, 2016-09-24 at 21:18 +0200, Rhonda D'Vine wrote:
>  after the security update of irssi another report came in about a
> script included in irssi, buf.pl.  If it's loaded and an /upgrade of
> irssi is done the current buffer content is written to a temporary file
> which didn't use tightly secured file permissions to temporarily store
> the buffer content for re-reading it after re-execing irssi.
> 
>  The patch that upstream provides is this:
> https://github.com/irssi/scripts.irssi.org/commit/f1b1eb154baa684fad5d65bf4dff79c8ded8b65a
> 
>  I uploaded it to unstable already and would like to push it to stable,
> too.

That looks okay, but please could we have a source debdiff for the
proposed upload, as built and hopefully tested on jessie.

Thanks,

Adam

Bug#811981: qqwing: diff for NMU version 1.3.4-1.1

[Sebastian Ramacher]

Control: tags 811981 + patch
Control: tags 811981 + pending

Dear maintainer,

I've prepared an NMU for qqwing (versioned as 1.3.4-1.1) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.

Regards.
-- 
Sebastian Ramacher
diff -Nru qqwing-1.3.4/debian/changelog qqwing-1.3.4/debian/changelog
--- qqwing-1.3.4/debian/changelog	2015-08-03 12:13:23.0 +0200
+++ qqwing-1.3.4/debian/changelog	2016-09-24 21:07:25.0 +0200
@@ -1,3 +1,10 @@
+qqwing (1.3.4-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Replacing symbol from template instatiation with newer version. (Closes: #811981)
+
+ -- Johannes Brandstätter   Sat, 24 Sep 2016 21:07:25 +0200
+
 qqwing (1.3.4-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru qqwing-1.3.4/debian/libqqwing2v5.symbols qqwing-1.3.4/debian/libqqwing2v5.symbols
--- qqwing-1.3.4/debian/libqqwing2v5.symbols	2015-07-03 23:40:52.0 +0200
+++ qqwing-1.3.4/debian/libqqwing2v5.symbols	2016-09-24 21:05:18.0 +0200
@@ -77,6 +77,4 @@
  _ZN6qqwing7LogItemD1Ev@Base 1.3.2
  _ZN6qqwing7LogItemD2Ev@Base 1.3.2
  _ZNKSt5ctypeIcE8do_widenEc@Base 1.3.2
- _ZNSt6vectorIPN6qqwing7LogItemESaIS2_EE13_M_insert_auxEN9__gnu_cxx17__normal_iteratorIPS2_S4_EERKS2_@Base 1.3.2
-
- 
\ No newline at end of file
+ (optional)_ZNSt6vectorIPN6qqwing7LogItemESaIS2_EE19_M_emplace_back_auxIJRKS2_EEEvDpOT_@Base 1.3.4


signature.asc
Description: PGP signature

Bug#838781: tzdata: Turkey Permanent Daylight Saving Time

[Ali İhsan Barışman]

Package: tzdata
Version: 2016f-0+deb8u1
Severity: important

Dear Maintainer,

New version (2016g) of tzdata has been released by Paul Eggert.[1] But IANA
hasn't officially announced yet.

Debian unstable distribution has already merge this new version[2], we would
really appreciate it if you could update the package as soon as reasonably
possible.

Additional information can be found at the fallowing sites[3]

[1]* https://github.com/eggert/tz/releases/tag/2016g
[2]* https://packages.qa.debian.org/t/tzdata/news/20160922T225859Z.html
[3]* http://time.is/time_zone_news/turkey_to_keep_permanent_dst

Kind Regards.
-barisman



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

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

Versions of packages tzdata depends on:
ii  debconf [debconf-2.0]  1.5.56

tzdata recommends no packages.

tzdata suggests no packages.

-- debconf information:
  tzdata/Zones/US:
  tzdata/Zones/America:
  tzdata/Zones/Antarctica:
  tzdata/Zones/Pacific:
  tzdata/Zones/Indian:
  tzdata/Zones/Africa:
  tzdata/Zones/Asia:
  tzdata/Zones/Atlantic:
  tzdata/Zones/Arctic:
* tzdata/Zones/Etc: UTC
* tzdata/Zones/Europe: Istanbul
* tzdata/Areas: Europe
  tzdata/Zones/SystemV:
  tzdata/Zones/Australia:

Bug#838780: jessie-pu: package irssi/0.8.17-1+deb8u1

[Rhonda D'Vine]

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

  Hi,

 after the security update of irssi another report came in about a
script included in irssi, buf.pl.  If it's loaded and an /upgrade of
irssi is done the current buffer content is written to a temporary file
which didn't use tightly secured file permissions to temporarily store
the buffer content for re-reading it after re-execing irssi.

 The patch that upstream provides is this:
https://github.com/irssi/scripts.irssi.org/commit/f1b1eb154baa684fad5d65bf4dff79c8ded8b65a

 I uploaded it to unstable already and would like to push it to stable,
too.

 Thanks in advance,
Rhonda

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

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

Bug#836795: jessie-pu: package samba/2:4.1.17+dfsg-2+deb8u2

[Adam D. Barratt]

Control: tags -1 -moreinfo +confirmed

On Mon, 2016-09-05 at 20:50 +, Jelmer Vernooij wrote:
> I'd like to update Samba in jessie to 4.2.14+dfsg. Debdiff is attached.
> 
> The 4 Samba releases since 4.2.10 (currently in jessie) only fix
> important bugs, in particular a CVE (CVE-2016-2119) and various
> regressions introduced by the security fixes from 4.2.10.

Please go ahead, with the changelog distribution set to "jessie".

I'll hopefully be able to find a suitable machine on my work network to
test with, and I assume at least Lars Maes would also be happy to test.

Regards,

Adam

Bug#838734: [plasma-discover] plasma-discover uninstalls packages during upgrades without asking for confirmation

[Diederik de Haas]

Control: found -1 5.7.3-1

On zaterdag 24 september 2016 21:02:28 CEST Diederik de Haas wrote:
> So this happened on 24th of August and then the perl migration wasn't 
> happening, thus reopening the bug.

As 5.7.4-1 was uploaded on 26th of August, my version was thus 5.7.3-1, 
marking this bug as such.

> I'll spare you my real opinion.

That didn't last long :-P

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