Bug#808799: python-cogent: build-depends on bwa makes it unbuildable on most architecture

[Mattia Rizzolo]

Package: src:python-cogent
Version: 1.5.3-3

Starting from 1.5.3-3 python-cogent build-depends on bwa, which is
available only on amd64 archs; as a result it didn't built on
 arm64 armel armhf i386 mips mipsel powerpc ppc64el s390x
hurd-i386 kfreebsd-i386
 alpha hppa m68k mips64el ppc64 sh4 sparc64 x32

The first line of failures are what is preventing the testing migration
of this package.

Also, given that we're keeping around the old sources and the old
binaries not yet updated, those old cruft still build-depend/depend on
python-support, scheduled for removal.

Please either ask ftp-masters to remove the binaries on those archs or
relax the build-depends on bwa to [any-amd64] to get it build on all the
archs (the choice depends on how important is to run the tests, I
guess).

Thanks in advance!


-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  http://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#808763: [Python-modules-team] Bug#808763: ImportError: Entry point ('console_scripts', 'py.test-3.5') not found

[Brian May]

Thomas Goirand  writes:

> diff -Nru pytest-2.8.5/debian/rules pytest-2.8.5/debian/rules
> --- pytest-2.8.5/debian/rules 2015-12-18 00:41:22.0 +
> +++ pytest-2.8.5/debian/rules 2015-12-22 14:58:43.0 +
> @@ -33,8 +33,12 @@
>  debian/python3-pytest/usr/bin/py.test-3
>   -sed -i '1s|.*|#!/usr/bin/python3.4|' \
>   debian/python3-pytest/usr/bin/py.test-3.4
> + -sed -i "s/'console_scripts', 'py.test-3.4'/'console_scripts', 
> 'py.test'/" \
> + debian/python3-pytest/usr/bin/py.test-3.4

This isn't required (although it doesn't hurt either), because the
package defines a py.test-3.4 entry point, however it doesn't defined a
py.test-3.5 entry point.

# cat /usr/lib/python3/dist-packages/pytest-2.8.5.egg-info/entry_points.txt 
[console_scripts]
py.test = pytest:main
py.test-3.4 = pytest:main


>   -sed -i '1s|.*|#!/usr/bin/python3.5|' \
>   debian/python3-pytest/usr/bin/py.test-3.5
> + -sed -i "s/'console_scripts', 'py.test-3.5'/'console_scripts', 
> 'py.test'/" \
> + debian/python3-pytest/usr/bin/py.test-3.5
>   rm -rf debian/python3-pytest/usr/lib/python3.5

I am not sure why this debian/python3-pytest/usr/bin/py.test-3.5 file
gets created. Suspect all of the above can disappear when Python 3.5
becomes the default Python in Debian - which unfortunately may not be
any time soon. So I think this change will be required for now.

I also note that python3-pytest comes with a py.test-3.1 man page,
however probably hasn't distributed the corresponding binary in years.
-- 
Brian May 

Bug#808798: Acknowledgement (evolution-mapi: MAPI account disappeared, cannot add)

[Matti Koskimies]

I just noticed that evolution-mapi is deprecated in favour of
evolution-ews. This seems to work.

// Matti

Bug#799666: m17n-db: rfc1345 input method captures unrelated keystrokes

[Ben Finney]

Control: reassign -1 m17n-db
Control: found -1 m17n-db/1.7.0-2

On 01-Dec-2015, Ben Finney wrote:
> For example, pressing ‘/’ then ‘q’ will result in the terminal
> receiving the sequences in reverse order.
> 
> So typing “/quit” sends “q/uit”.
> 
> Please investigate what has regressed to make ‘/’ and ‘Ctrl+U’ (and
> anything except ‘&’) behave like unwanted prefix keys.

This regression seems to be explicitly caused by code in
‘/usr/share/m17n/global.mim’:

=
 (fallback-input-method
  (_"Fallback input methods.
Value must be comma separated fallback input method names.
When you type a key that is not handled by the currently activated intup method,
fallback input methods (in the order specified in this variable) try
to handle that key, and the first one that can handle the key is activated
temporarily.
For instance, as the default value of this variable is \"lsymbol, unicode\",
when you type \"/...\" while you are activating an input method
that doesn't handle that key sequence, \"lsymbol\" input method is activated
and \"…\" (U+2026: HORIZONTAL ELLIPSIS) is inserted.")
  "lsymbol, unicode"))
=

Please reverse this change, and restore the behaviour of earlier
versions: only enable input methods explicitly requested by the user.

-- 
 \ “Truth would quickly cease to become stranger than fiction, |
  `\ once we got as used to it.” —Henry L. Mencken |
_o__)  |
Ben Finney 


signature.asc
Description: PGP signature

Bug#765111: buildd: [PATCH] buildd no longer parses wanna-build debug lines as real output

[Johannes Schauer]

Control: tag -1 + patch

Hi,

On Mon, 13 Oct 2014 10:38:15 -0700 Dima Kogan  wrote:
> On my local setup of buildd/sbuild/wanna-build for whatever reason the pipe
> that buildd uses to talk to wanna-build produces some debugging output. These
> are lines such as
> 
>  D: Setting Session Purged=0
>  D: Setting Log Stream=IO::File=GLOB(0x2293200)
>  D: Setting Host=Sbuild::ChrootRoot=HASH(0x22831f8)
>  D: Setting SETUP=1
>  D2: Pipe (PID 2694, GLOB(0x22935c0)) created for: ssh -l buildd 127.0.0.1 
> wanna-build --arch=amd64 --user=wbadm --api 1 --dist=sid test1_1.0-2
>  Oct 13 08:52:25 buildd[2666]: D2: Environment filter: Deleted HOME
>  Oct 13 08:52:25 buildd[2666]: D2: Environment filter: Deleted SSH_CLIENT
>  Oct 13 08:52:25 buildd[2666]: D2: Environment filter: Deleted LANGUAGE
> 
> The code that buildd was using to parse its output was not ignoring these 
> lines,
> and would try to use them as actual wanna-build output, which clearly would
> fail.

I do not have a wanna-build/buildd setup over here so I can neither reproduce
your problem nor can I verify that your patch doesn't introduce any new
problems.

Could you find somebody who has a running wanna-build/buildd setup who can
verify either or better both of these things?

Thanks!

cheers, josch


signature.asc
Description: signature

Bug#808798: evolution-mapi: MAPI account disappeared, cannot add

[Matti Koskimies]

Package: evolution-mapi
Version: 3.18.0-4
Severity: grave
Justification: renders package unusable

Dear Maintainer,

After latest updates in sid, my MS Exchange account disappeared from Evolution
and there is no way to add a MAPI account in the add account dialog. The MAPI
option is missing from the Server Type dropdown list.



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

Kernel: Linux 4.3.0-1-amd64 (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
Init: systemd (via /run/systemd/system)

Versions of packages evolution-mapi depends on:
ii  evolution   3.18.3-1
ii  libatk1.0-0 2.18.0-1
ii  libc6   2.21-4
ii  libcairo-gobject2   1.14.4-1
ii  libcairo2   1.14.4-1
ii  libcamel-1.2-54 3.18.3-1
ii  libebackend-1.2-10  3.18.3-1
ii  libebook-1.2-16 3.18.3-1
ii  libebook-contacts-1.2-2 3.18.3-1
ii  libecal-1.2-19  3.18.3-1
ii  libedata-book-1.2-253.18.3-1
ii  libedata-cal-1.2-28 3.18.3-1
ii  libedataserver-1.2-21   3.18.3-1
ii  libedataserverui-1.2-1  3.18.3-1
ii  libevolution3.18.3-1
ii  libexchangemapi-1.0-0   3.18.0-4
ii  libgdk-pixbuf2.0-0  2.32.3-1
ii  libglib2.0-02.46.2-1
ii  libgtk-3-0  3.18.6-1
ii  libical1a   1.0.1-0.1
ii  libjavascriptcoregtk-3.0-0  2.4.9-3
ii  libmapi01:2.2-7
ii  libnspr42:4.11-1
ii  libnspr4-0d 2:4.11-1
ii  libnss3 2:3.21-1
ii  libnss3-1d  2:3.21-1
ii  libpango-1.0-0  1.38.1-1
ii  libpangocairo-1.0-0 1.38.1-1
ii  libsecret-1-0   0.18.3-1
ii  libsoup2.4-12.52.2-1
ii  libsqlite3-03.9.2-1
ii  libtalloc2  2.1.5-1
ii  libtevent0  0.9.26-3
ii  libwebkitgtk-3.0-0  2.4.9-3
ii  libxml2 2.9.3+dfsg1-1
ii  samba-libs  2:4.3.3+dfsg-1

evolution-mapi recommends no packages.

evolution-mapi suggests no packages.

-- no debconf information

Bug#808797: python-foolscap: new upstream version available

[Ramakrishnan Muthukrishnan]

Package: python-foolscap
Version: 0.8.0-1
Severity: wishlist

Dear Maintainer,

There is a new upstream version 0.9.1 available at: 


It will be great if you can package it.

Thanks
Ramakrishnan

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

Kernel: Linux 4.2.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_IN.UTF-8, LC_CTYPE=en_IN.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)

Versions of packages python-foolscap depends on:
ii  python   2.7.9-1
ii  python-openssl   0.15.1-2
ii  python-service-identity  14.0.0-1
ii  python-twisted-core  15.2.1-1
ii  python-twisted-web   15.2.1-1
ii  python-zope.interface4.1.2-1+b1

Versions of packages python-foolscap recommends:
ii  python-openssl  0.15.1-2

python-foolscap suggests no packages.

-- no debconf information


signature.asc
Description: PGP signature

Bug#808796: OpenCOLLADAValidator: option to only print warnings/errors

[Paul Wise]

Package: opencollada-tools
Version: 0.1.0~20140703.ddf8f47+dfsg1-2
Severity: wishlist
File: /usr/lib/opencollada/OpenCOLLADAValidator
Control: affects -1 check-all-the-things
User: check-all-the-thi...@packages.debian.org
Usertags: noise

I added a check for running the opencolladavalidator tool to the
check-all-the-things tool. When I run opencolladavalidator it says the
file I'm checking is compliant with the spec. That isn't useful to know
for check-all-the-things users so I've had to grep -v for valid files.
It would be nice if there was a --quiet option to only print warnings
and errors about invalid files, or if that were the default.

https://anonscm.debian.org/cgit/collab-maint/check-all-the-things.git/tree/data/collada

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (900, 'testing'), (860, 'testing-proposed-updates'), (850, 
'buildd-testing-proposed-updates'), (800, 'unstable'), (790, 
'buildd-unstable'), (700, 'experimental'), (690, 'buildd-experimental'), (500, 
'unstable-debug'), (1, 'experimental-debug')
Architecture: amd64 (x86_64)

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

Versions of packages opencollada-tools depends on:
ii  libc6   2.21-4
ii  libgcc1 1:5.3.1-3
ii  libpcre32:8.35-8
ii  libstdc++6  5.3.1-3
ii  libxml2 2.9.3+dfsg1-1

opencollada-tools recommends no packages.

opencollada-tools suggests no packages.

-- no debconf information

-- 
bye,
pabs

https://wiki.debian.org/PaulWise




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

Bug#808795: OpenCOLLADAValidator: support COLLADA 1.5.0 specification from 2008

[Paul Wise]

Package: opencollada-tools
Version: 0.1.0~20140703.ddf8f47+dfsg1-2
Severity: wishlist
File: /usr/lib/opencollada/OpenCOLLADAValidator

When I run opencolladavalidator it says the file I'm checking is
compliant with version 1.4.1 of the spec, but version 1.5.0 was
released in 2008, it would be nice to support the newer version.

$ find -type f -iname '*.dae' -exec opencolladavalidator {} \;
"./bullet-2.83.6+dfsg/data/duck.dae" is valid against the COLLADA 1.4.1 schema.

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (900, 'testing'), (860, 'testing-proposed-updates'), (850, 
'buildd-testing-proposed-updates'), (800, 'unstable'), (790, 
'buildd-unstable'), (700, 'experimental'), (690, 'buildd-experimental'), (500, 
'unstable-debug'), (1, 'experimental-debug')
Architecture: amd64 (x86_64)

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

Versions of packages opencollada-tools depends on:
ii  libc6   2.21-4
ii  libgcc1 1:5.3.1-3
ii  libpcre32:8.35-8
ii  libstdc++6  5.3.1-3
ii  libxml2 2.9.3+dfsg1-1

opencollada-tools recommends no packages.

opencollada-tools suggests no packages.

-- no debconf information

-- 
bye,
pabs

https://wiki.debian.org/PaulWise




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

Bug#805063: sbuild: Vcs-... tags refer to the upstream branch, not the debianized branch

[Johannes Schauer]

Hi,

On Fri, 13 Nov 2015 21:08:46 -0800 Dima Kogan  wrote:
> Hi. debian/control contains this:
> 
> Vcs-Browser: https://anonscm.debian.org/cgit/buildd-tools/sbuild.git
> Vcs-Git: git://anonscm.debian.org/buildd-tools/sbuild
> 
> These refer to the master branch, which doesn't have a full
> debianization. Thus you can't 'debcheckout sbuild' and then run a build.
> It also makes it difficult for a user (me!) to build packages from git,
> since the correct branch to use isn't documented. The Vcs-Browser can be
> pointed to the debianization branch with this:
> 
> Vcs-Browser: 
> https://anonscm.debian.org/cgit/buildd-tools/sbuild.git?h=debian/unstable
> 
> For Vcs-Git I don't know how to do this.

Policy §5.6.26 [1] describes how to specify the branch in case of Vcs-Git. So
to fix this bug, sbuild should have:

 Vcs-Git: git://anonscm.debian.org/buildd-tools/sbuild -b debian/unstable
 Vcs-Browser: 
https://anonscm.debian.org/cgit/buildd-tools/sbuild.git?h=debian/unstable

Thanks to Stuart Prescott for making me aware of this!

cheers, josch

[1] 
https://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-VCS-fields


signature.asc
Description: signature

Bug#808575: [Aptitude-devel] Bug#808575: maybe use $PAGER when showing choices in command line mode

[積丹尼 Dan Jacobson]

> "AB" == Axel Beckert  writes:

AB> aptitude has nothing to do with journalctl. It's completely
AB> independent of systemd.

Yes, I'm just saying that journalctl's default functionality seems to work 
perfectly.

Bug#665015: python-sleekxmpp: New upstream version

[Jonas Smedegaard]

Quoting Jonas Smedegaard (2015-12-23 01:52:31)
> Quoting W. Martin Borgert (2015-12-22 04:45:04)
>> I would like to move sleekxmpp into the tender hands of DPMT and 
>> update it to the latest upstream 1.3.1. This would include migration 
>> from gpb to git-dpm and from CDBS to dh.
>>
>> Would this be OK? TIA!
>
> For my part please do go ahead!

...but I assume that such move means taking over maintainership.

Please remove me as uploader: I cannot responsibly help maintain 
packages not using CDBS.


Kind regards,

 - Jonas

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

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


signature.asc
Description: signature

Bug#808794: VESA video driver fails when Xorg is executing as non-root

[Patrik Hägglund]

Package: xserver-xorg-video-vesa
Version: 1:2.3.3-1+b4

Package: xserver-xorg-core
Version: 2:1.17.2-3

I'm unsure to which package this bug report belongs.

When I execute 'startx', the X11 startup fails. In Xorg.0.log (in my
home directory), I see:

[   132.177] xf86EnableIOPorts: failed to set IOPL for I/O (Operation
not permitted)

and later:

[   132.177] (II) VESA(0): initializing int10
[   132.177] (EE) VESA(0): Cannot read int vect

This failure should be possible to reproduce by installing Stretch
Alpha 4 on an x86-64 Windows host with VirtualBox 5.0.12, using
debian-stretch-DI-alpha4-amd64-xfce-CD-1.iso (from 2015-10-24) . In
the tasksel dialog, deselect everything, to get a minimal
installation. Then, in the new installation, do 'apt-get install
xinit' to get a minimal X11 installation. Now, execute 'startx', as a
normal user.

I found the NEWS file in xserver-xorg-core 2:1.17.3-1, telling me "The
Xorg server is no longer setuid root by default.", and some
dependencies. Installing xserver-xorg-legacy indeed fix this
problem. Installing libpam-systemd didn't.

Doing 'apt-get install lightdm', followed by a reboot, will at least
start an X11 session. But the Xorg process started seems to be
executing as root.

Upgrading the installation to current testing, and then unstable,
don't fix anything.

Using the current stable distribution, debian-8.2.0-amd64-netinst.iso
(2015-09-06) works.

Should xserver-xorg-video-vesa depend on xserver-xorg-legacy, or what
is the proper short-term solution?

Bug#808793: test, please ignore

[Phillip Susi]

Package: general

This is a test of the BTS, please ignore.

Bug#800179: empire-hub: diff for NMU version 1.0.2.1

[Raphael mota]

Hi,
I uploaded a NMU to 10-day/delay queue. Feel free to cancel this upload if
needed.

The debian/changelog is:

empire-hub (1.0.2.1+nmu1) unstable; urgency=medium

  * Non-maintainer upload.
  * Update DH level to 9 to avoid a FTBFS. (Closes: #800179)
  * debian/compat: created.
  * debian/control:
 - Added the ${msic:Depends} variable to provide the
   right install dependencies.
 - Bumped Standards-Version to 3.9.6.
  * debian/rules: changed the install to put the final
files in right place.

I attached a debdiff.

Thanks.

Regards,

Raphael Mota.


empire-hub.debdiff
Description: Binary data

Bug#744623: libtwin: Disable altivec to fix ftbfs on ppc64el

[Steve Langasek]

Hi Geoff,

I don't understand why you've suggested here that the libtwin package should
be dropped.  It is still a build-dependency of the petitboot package, which
does indeed seem to be a rather relevant thing to build for ppc64el; and you
appear to also be the maintainer for that package as well as this one.

If you prefer to drop the libtwin package, as the maintainer you can
certainly request its removal from the archive and update the petitboot
package to no longer build-depend on it.  In the meantime, however, I am
going to proceed with a 0-day porter NMU of libtwin, in order to unblock
petitboot on ppc64el.

Please find the final NMU diff attached.

Thanks,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru libtwin-13.05.03.15.06-g287d16c/debian/changelog libtwin-13.05.03.15.06-g287d16c/debian/changelog
--- libtwin-13.05.03.15.06-g287d16c/debian/changelog	2013-05-24 23:56:03.0 +
+++ libtwin-13.05.03.15.06-g287d16c/debian/changelog	2015-12-23 02:14:24.0 +
@@ -1,3 +1,16 @@
+libtwin (13.05.03.15.06-g287d16c-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop wrong direct pre-dependency on multiarch-support, as reported by
+lintian.
+
+  [ Fernando Seiti Furusato ]
+  * debian/rules: added conditional for --disable-altivec on ppc64el to fix
+ftbfs. Added --with-autoreconf to build with dh-autoreconf.
+Closes: #804273, #744623.
+
+ -- Steve Langasek   Wed, 23 Dec 2015 02:08:35 +
+
 libtwin (13.05.03.15.06-g287d16c-2)  unstable; urgency=low
 
   * debian/rules: Add conditional for --disable-linux-touchscreen. Fixes
diff -Nru libtwin-13.05.03.15.06-g287d16c/debian/control libtwin-13.05.03.15.06-g287d16c/debian/control
--- libtwin-13.05.03.15.06-g287d16c/debian/control	2013-05-22 02:34:47.0 +
+++ libtwin-13.05.03.15.06-g287d16c/debian/control	2015-12-23 02:12:22.0 +
@@ -12,8 +12,7 @@
 Section: libdevel
 Architecture: any
 Multi-Arch: same
-Pre-Depends: multiarch-support
-#Pre-Depends: ${misc:Pre-Depends}
+Pre-Depends: ${misc:Pre-Depends}
 Depends: libtwin0 (= ${binary:Version}), ${misc:Depends}, libx11-dev, libpng-dev, libjpeg-dev, libz-dev
 Description: tiny window system (development files)
  With embedded systems gaining high resolution displays and powerful CPUs, the
@@ -31,8 +30,7 @@
 Section: libs
 Architecture: any
 Multi-Arch: same
-Pre-Depends: multiarch-support
-#Pre-Depends: ${misc:Pre-Depends}
+Pre-Depends: ${misc:Pre-Depends}
 Depends: ${shlibs:Depends}, ${misc:Depends}
 Description: tiny window system (library)
  With embedded systems gaining high resolution displays and powerful CPUs, the
diff -Nru libtwin-13.05.03.15.06-g287d16c/debian/rules libtwin-13.05.03.15.06-g287d16c/debian/rules
--- libtwin-13.05.03.15.06-g287d16c/debian/rules	2013-05-24 22:41:21.0 +
+++ libtwin-13.05.03.15.06-g287d16c/debian/rules	2015-12-23 02:07:07.0 +
@@ -22,6 +22,10 @@
 		--disable-linux-joystick --disable-linux-touchscreen
 endif
 
+ifeq ($(DEB_HOST_ARCH_CPU), ppc64el)
+	extra_configure += --disable-altivec
+endif
+
 extra_CFLAGS =
 
 ifneq (,$(filter powerpc ppc64, $(DEB_HOST_ARCH_CPU)))
@@ -32,7 +36,7 @@
 export LDFLAGS = $(shell dpkg-buildflags --get LDFLAGS) -lX11 -lpng12 -ljpeg -lz
 
 %:
-	dh $@
+	dh $@ --with autoreconf
 
 override_dh_auto_configure:
 	dh_auto_configure -- --enable-x11 $(extra_configure)


signature.asc
Description: Digital signature

Bug#807323: [Pkg-utopia-maintainers] Bug#807323: gparted needs policykit-1 but its neither in depends or recommends

[Phillip Susi]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Control: reopen -1

On 12/22/2015 08:11 PM, Michael Biebl wrote:
> First, please CC the package when you re-assign a bug report.

Why?  The BTS forwards the message automatically doesn't it?

> Second, please don't use inflated severities. Third, this bug
> report was titled "Missing depends or recommends on policykit-1"
> which is highly misleading and not an issue for udisks2.
> 
> 
> All in all, a badly done bug report. Enough reason to close it and
> let the bug reporter file a new one.

That is entirely incorrect; you can not just close a bug and expect
the user to try again and do better without knowing what is wrong.  If
there is something wrong, you fix it.  If the title is wrong, you
retitle it.  If you disagree with the severity, then change it.  If it
is assigned to the wrong package, you reassign it.

> My guess is, and I can only guess since I don't have any version 
> information for neither udisks2 nor policykit-1, is that the bug 
> reporter has policykit-1 from experimental installed.

That is a good thing to ask the user to check rather than assume and
close.


-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBCgAGBQJWegGOAAoJEBB5UWFcu6UWt0gH/jTdXjaQ3R8HgGZywneufMZC
/cpUwvv38myQOQG1ozHqO2mxIo60eJicAj/g7mlsLaiCaVO2/IBoudqSD0yQn7hf
rZhRI4v1QnsEfy3C7brysr7jT4v9Z3pSqum/zh1HUCY+ZqU274wFYipPAHchzeQC
rAHLgmltBCPYLjlEPK22fEVPoPz3ySX0ORM6jgGmY+RuywAFh1OeqCIwMSBZdoAS
G4mCpU+cUVSOHabHVoHemJnyAuAijAVyFXEuM3++A/ccdh4NcNeCv4PWPTPQVpTB
g5WJH7MkmooL2WhCXmQznuPz408DPb+voA4OCMF5GwKL5ufajhgrjh67EhgBKuU=
=NT+V
-END PGP SIGNATURE-

Bug#808792: firmware-iwlwifi: iwlwifi-7260-17.ucode is missing

[Mike Hommey]

Package: firmware-iwlwifi
Version: 20151207-1
Severity: normal

# dmesg | grep iwlwifi | head -5
[7.473576] iwlwifi :06:00.0: enabling device ( -> 0002)
[7.475332] iwlwifi :06:00.0: firmware: failed to load 
iwlwifi-7260-17.ucode (-2)
[7.475337] iwlwifi :06:00.0: Direct firmware load for 
iwlwifi-7260-17.ucode failed with error -2
[7.479873] iwlwifi :06:00.0: firmware: direct-loading firmware 
iwlwifi-7260-16.ucode
[7.480478] iwlwifi :06:00.0: loaded firmware version 16.242414.0 
op_mode iwlmvm


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

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

firmware-iwlwifi depends on no packages.

firmware-iwlwifi recommends no packages.

Versions of packages firmware-iwlwifi suggests:
ii  initramfs-tools  0.120

-- no debconf information

Bug#808791: gummi: May ship in invalid directories after autoreconf

[Mathieu Trudel-Lapierre]

Package: gummi
Version: 0.6.5-6
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu xenial ubuntu-patch

Dear Maintainer,

In Ubuntu, I've noticed that gummi tries to ship locale files in
the /usr/@DATADIRNAME@ directory, litterally.

Now, I haven't done much background investigation on this, and I suspect
it is failing in Ubuntu and not currently happening in Debian because of a
difference in the toolchain package versions.

What happens precisely is that rather than correctly replacing @DATADIRNAME@
with 'share', the value is kept unreplaced. It should be sufficient to replace
uses of $(prefix)/$(DATADIRNAME) with $(datadir).

In any case, I'm including a patch for your convenience, since I expect some
time in the future gummi may catch the same issue in Debian.

If such an occurence does happen, you'll notice lintian warnings too:
W: gummi: non-standard-dir-in-usr usr/@DATADIRNAME@/
W: gummi: file-in-unusual-dir usr/@DATADIRNAME@/locale/ar/LC_MESSAGES/gummi.mo
W: gummi: file-in-unusual-dir usr/@DATADIRNAME@/locale/ca/LC_MESSAGES/gummi.mo
W: gummi: file-in-unusual-dir usr/@DATADIRNAME@/locale/cs/LC_MESSAGES/gummi.mo
W: gummi: file-in-unusual-dir usr/@DATADIRNAME@/locale/da/LC_MESSAGES/gummi.mo
W: gummi: file-in-unusual-dir usr/@DATADIRNAME@/locale/de/LC_MESSAGES/gummi.mo
[...]

*** /tmp/tmpcMIZb0/bug_body

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

  * debian/patches/upgrade_datadir.patch: replace outdated uses of
$(DATADIRNAME) with $(datadir).


Thanks for considering the patch.


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

Kernel: Linux 4.2.0-19-generic (SMP w/4 CPU cores)
Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
diff -Nru gummi-0.6.5/debian/patches/series gummi-0.6.5/debian/patches/series
--- gummi-0.6.5/debian/patches/series	2015-11-28 19:09:50.0 -0500
+++ gummi-0.6.5/debian/patches/series	2015-12-22 19:59:50.0 -0500
@@ -3,3 +3,4 @@
 libgthread-2.0_link.patch
 use-system-synctex.patch
 no-predictable-tmpfiles.patch
+upgrade_datadir.patch
diff -Nru gummi-0.6.5/debian/patches/upgrade_datadir.patch gummi-0.6.5/debian/patches/upgrade_datadir.patch
--- gummi-0.6.5/debian/patches/upgrade_datadir.patch	1969-12-31 19:00:00.0 -0500
+++ gummi-0.6.5/debian/patches/upgrade_datadir.patch	2015-12-22 20:26:26.0 -0500
@@ -0,0 +1,20 @@
+From: Mathieu Trudel-Lapierre 
+Subject: Replace outdated prefix/DATADIRNAME with just datadir.
+---
+ po/Makefile.in.in |3 +--
+ 1 file changed, 1 insertion(+), 2 deletions(-)
+
+Index: b/po/Makefile.in.in
+===
+--- a/po/Makefile.in.in
 b/po/Makefile.in.in
+@@ -33,8 +33,7 @@ exec_prefix = @exec_prefix@
+ datadir = @datadir@
+ datarootdir = @datarootdir@
+ libdir = @libdir@
+-DATADIRNAME = @DATADIRNAME@
+-itlocaledir = $(prefix)/$(DATADIRNAME)/locale
++itlocaledir = $(datadir)/locale
+ subdir = po
+ install_sh = @install_sh@
+ # Automake >= 1.8 provides @mkdir_p@.

Bug#703256: moving the gridengine team repository to collab-maint

[Afif Elghraoui]

Hi,
As I've made numerous requests on this list [1-3] and tried twice to
directly contact Michael Banck, one of the two Alioth team admins
(both of them CC'd here this time), regarding membership on the team
so that I could work on updating the gridengine package using the
team's repository.

I have so far been working from my personal fork at
, but
I'm now going to be using collab-maint as I said previously [4].

I have created the repository on collab-maint:
http://anonscm.debian.org/cgit/collab-maint/gridengine.git/

This is what I'll be using from now on.

regards
Afif

1.
https://lists.alioth.debian.org/pipermail/pkg-gridengine-devel/2015-August/000759.html
2.
https://lists.alioth.debian.org/pipermail/pkg-gridengine-devel/2015-September/000763.html
3.
http://lists.alioth.debian.org/pipermail/pkg-gridengine-devel/2015-October/000774.html
4.
https://lists.alioth.debian.org/pipermail/pkg-gridengine-devel/2015-October/000779.html

-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name



signature.asc
Description: OpenPGP digital signature

Bug#808380: mount: unknown filesystem type 'vfat'

[Phillip Susi]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 12/22/2015 02:47 PM, Sven Joachim wrote:
> Both the original report ("Kernel: Linux 3.16.0-4-amd64 (SMP w/4
> CPU cores)") and the followup in 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=808380#25 show
> that Jacob had already running 3.16.0-4.  If he had been using
> 3.16.0-3, the problem would not have shown up since modprobe does
> not try to load 3.16.0-4 modules into a 3.16.0-3 kernel.

That's what I've been saying.

> Debian does not do this, to avoid uncontrolled proliferation of 
> kernels.  In fact, the 3.16 kernel has been at the 3.16.0-4 ABI for
> over a year (the last ABI bump was in November 2014, version
> 3.16.7-1).

If that is the case, then they screwed up and broke the ABI without
bumping its revision and the bug should be reopened and reassigned to
linux so they know they broke the ABI and need to bump the revision.


-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBCgAGBQJWefMMAAoJEBB5UWFcu6UWhvMH/iVmGGTEOnfmbgpFQRt58qr/
R03ZuXt7eqQgtkwnBrKG7JmzhByv5u4rmn1oxPHf6E+6PPU1UeRMkEpVVfkEKbPd
68PtdHeU7gpf9DdmrMjR0qYu5xmZ9yvpBdJrV7pdu1zyXiOyxBlBhrLV4liiCggh
+mnr0wxTt9GAI7rsp2D/DJtnQnX9b7/SjJJHr9HG/5qxCRg0P1/yNHmZ37tOnsX1
nZaXtQOWtJZOobEzD7Fz5dvaHn/DY021aIRNsgikKfXsOuAt5H8TFJDO49mSw2/a
YEfEgtfpEVLw7TwSWy7QUn8dr8KTOc/iAB1YxLQ3MGioR5FliGvSlAPyxFkZDLs=
=zdp3
-END PGP SIGNATURE-

Bug#807323: gparted needs policykit-1 but its neither in depends or recommends

[Phillip Susi]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Control: reopen -1
Control: affects -1 gparted

On Tue, 22 Dec 2015 19:29:39 +0530 =?UTF-> > And that's why udisks2
has a Recommends policykit-1.
>> 
>> Closing the bug report.
>> 
>> Not installing recommends means you need to know what you are 
>> doing.

Closing is not appropriate.  If udisks2 functions except for
udisks2-inhibit, then gparted needs the hard depends on policykit-1.
Are you saying that the only thing udisks2 needs policykit-1 for is
inhibit?  I would think it needs it for everything.

>> 
> 
> Miichael,
> 
> Did you read the whole bug-report. I have installed it. It is 
> there.
> 
> $] aptitude search policykit-1 i A policykit-1 - framework for
> managing administrative policies and privileges
> 
> The error is even after it is installed.

Then the reason for closing is certainly incorrect.  Maybe the real
problem is not policykit-1 then but something unknown?

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBCgAGBQJWefGKAAoJEBB5UWFcu6UWC1YH+gPMU3InktrfuM6RzrW5tRqq
+tXOE+DUnjzqLeob8HVbrXJt01TDXzf3876oYC6c1Sx1M1+MzEcfk7CQCNCHimYV
QLHKpAQgI/9Y+RJfGb8yki1t3yXkafC75Q62gjx9sVTGXKbZ8y/J5EPhTaB/8ypZ
bWn6dsGNUDiskJl464DeTAhoqKpBeGKrU95/LmPd8WLXYIT5tMgy/qEi9U1SOklb
ilAzp42byKNUIWfuYEaxCwlpfHu2GU1qruzD31sbmd7eWIygFxUhPmBBadAEuFmK
XB1Q7eYlY8kyINKA2bZlg2MNNMWCeLZOxBMl9zoxyqLIwg2oHRILzqbDQq3wkO4=
=0ccK
-END PGP SIGNATURE-

Bug#808563: really should be serious bug: data loss

[積丹尼 Dan Jacobson]

Rotational.
watch outscrambled data fsck forced can't boot stay away...

Bug#736666: /usr/lib/sm.bin/mail.local: lockmailbox failed code 75 EX_TEMPFAIL

[paul . szabo]

Now at jessie, I find that my "strace trick" does not work anymore.
Testing with my cutdown code suggests that the culprit may be the
  ... setreuid(0,uid) ...
in original mail.local, as changing that to either of
  setreuid(uid,0)
  setreuid(uid,uid)
allows maillock() to succeed.

The comments in mail.local were that it changed UID to better handle
quota checks. But then:
 - should not it change GID also?
 - do quotas go by real or effective IDs?
So many questions... more digging required.

Test code below: cut down long ago from mail.local, not yet verified
whether mail.local code changed since.

Cheers, Paul

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


=

/*
   Testing code mimicking sendmail mail.local .
   Compile with
 cc mytest.c -llockfile
   Fails if we use
... setreuid(0, uid) ...
   as in original mail.local, but succeeds with either
... setreuid(uid, 0) ...
   or
... setreuid(uid, uid) ...
   so maybe bug is in sendmail, after all.
*/

#include 
#include 
#include 
#include 
#include 

int
main(argc, argv)
int argc;
char *argv[];
{
/* name and UID of some plain user */
char *p = "psz";
uid_t uid   = 1001;

int off;

/* use a reasonable umask */
(void) umask(0077);

/* This was setreuid(0,uid) in original sendmail mail.local */
/* change UID for quota checks */
if (setreuid(uid, uid) < 0)
{
printf("450 setreuid(0, %d) errno=%d (r=%d, e=%d)\n",
(int) uid, errno, (int) getuid(), (int) geteuid());
exit(1);
}

/* printf("Before:\n"); system("ls -al /var/mail"); */
if ((off = maillock(p, 15)) != 0)
{
printf("lockmailbox %s code %d errno=%d\n", p, off, errno);
}

/* printf("During:\n"); system("ls -al /var/mail"); */
mailunlock();
/* printf("After:\n"); system("ls -al /var/mail"); */
}

Bug#803298: prepare for giflib5 (boats)

[peter green]

For the latter two options, please see a patch at
http://launchpadlibrarian.net/222938828/boats_201307-1build2_201307-1ubuntu1.diff.gz
I went to apply your patch in raspbian but I found further work was 
needed to get a sucessful build. Launchpad shows it also failing in ubuntu.


The first failure I got was a "no targets specified and no makefile 
found" error.


Further investigation showed that your patch had an unexplained new file 
debian/boats.debhelper.log . I presume this was caused by a broken clean 
target. I added a line to debian/rules to remove it in the clean target.


The build then failed with

gifwriter.cpp:49:28: error: cannot convert ‘const char*’ to 
‘GifFileType*’ for argument ‘1’ to ‘void EGifSetGifVersion(GifFileType*, 
bool)’

EGifSetGifVersion("89a");

I changed it to

EGifSetGifVersion(fileType,true);

Which I think is probablly correct but i'm not an expert on the API 
changes in giflib


After making that change I got a succesful build, debdiff attatched, no 
intent to NMU in Debian.




diff -Nru boats-201307/debian/changelog boats-201307/debian/changelog
--- boats-201307/debian/changelog   2013-07-23 16:48:20.0 +
+++ boats-201307/debian/changelog   2015-12-22 23:45:12.0 +
@@ -1,3 +1,12 @@
+boats (201307-1+rpi1) stretch-staging; urgency=medium
+
+  * Apply patch by doko to partially fix build with giflib 5 (closes: 803298)
+  * Fix call to EGifSetGifVersion for giflib 5
+  * Remove debian/boats.debhelper.log in clean target to avoid
+no targets specified and no makefile found errors.
+
+ -- Peter Michael Green   Tue, 22 Dec 2015 23:10:24 
+
+
 boats (201307-1) unstable; urgency=low
 
   * New upstream release.
diff -Nru boats-201307/debian/patches/giflib5.diff 
boats-201307/debian/patches/giflib5.diff
--- boats-201307/debian/patches/giflib5.diff1970-01-01 00:00:00.0 
+
+++ boats-201307/debian/patches/giflib5.diff2015-12-22 23:57:56.0 
+
@@ -0,0 +1,48 @@
+Giflib 5 fixes by doko and plugwash
+
+Index: boats-201307/gifwriter.cpp
+===
+--- boats-201307.orig/gifwriter.cpp
 boats-201307/gifwriter.cpp
+@@ -45,11 +45,11 @@ bool GifWriter::write(QList ima
+ int retrn;
+ QImage *image = imageList.first();
+ 
+-fileType = EGifOpen((void*) this, myOutputFunc);
+-EGifSetGifVersion("89a");
++fileType = EGifOpen((void*) this, myOutputFunc, NULL);
++EGifSetGifVersion(fileType,true);
+ 
+ int colors = 256;
+-ColorMapObject * cmap = MakeMapObject(colors, NULL);
++ColorMapObject * cmap = GifMakeMapObject(colors, NULL);
+ for (int i = 0; i< qMin(colors, m_colormap.size()); i++) {
+ QRgb color = m_colormap[i];
+ cmap->Colors[i].Blue = qBlue(color);
+@@ -58,13 +58,14 @@ bool GifWriter::write(QList ima
+ }
+ 
+ retrn = EGifPutScreenDesc(fileType, image->width(), image->height(), 8, 
0, cmap);
+-FreeMapObject(cmap);
++GifFreeMapObject(cmap);
+ 
+ char nameExtension[11] = { 'N','E','T','S','C','A','P','E','2','.','0' };
+ char loopExtension[3] = { 1, 0, 0 };
+-retrn = EGifPutExtensionFirst(fileType, 0xFF, 11, &nameExtension);
+-retrn = EGifPutExtensionNext(fileType, 0xFF, 3, &loopExtension);
+-retrn = EGifPutExtensionLast(fileType, 0xFF, 0, NULL);
++
++retrn = EGifPutExtensionLeader(fileType, 0xFF);
++retrn = EGifPutExtensionBlock(fileType, 3, &loopExtension);
++retrn = EGifPutExtensionTrailer(fileType);
+ retrn = EGifPutComment(fileType, "Boat Scenario http://boats.berlios.de";);
+ 
+ char gifExtension[4] = { 0, 8, 0, 0 };
+@@ -80,6 +81,6 @@ bool GifWriter::write(QList ima
+ }
+ }
+ 
+-retrn = EGifCloseFile(fileType);
++retrn = EGifCloseFile(fileType, NULL);
+ return true;
+ }
diff -Nru boats-201307/debian/patches/series boats-201307/debian/patches/series
--- boats-201307/debian/patches/series  1970-01-01 00:00:00.0 +
+++ boats-201307/debian/patches/series  2015-12-22 23:04:44.0 +
@@ -0,0 +1 @@
+giflib5.diff
diff -Nru boats-201307/debian/rules boats-201307/debian/rules
--- boats-201307/debian/rules   2013-07-23 16:48:20.0 +
+++ boats-201307/debian/rules   2015-12-22 23:58:35.0 +
@@ -11,6 +11,7 @@
 override_dh_clean:
qmake boats.pro $(QMAKE_OPT)
$(MAKE) distclean
+   rm -f debian/boats.debhelper.log
 
 override_dh_install:
dh_install

Bug#808720:

[Jean Privat]

I did just upgraded to linux-image-4.3.0-1-amd64 and can report the
same thing I suppose.

[4.910005] [drm:intel_pipe_config_compare [i915]] *ERROR* mismatch
in has_drrs (expected 1, found 0)
[4.910007] [ cut here ]
[4.910037] WARNING: CPU: 1 PID: 6 at
/build/linux-s8yg92/linux-4.3.3/drivers/gpu/drm/i915/intel_display.c:12700
intel_atomic_commit+0xd7a/0x12f0 [i915]()
[4.910037] pipe state doesn't match!
[4.910069] Modules linked in: xt_conntrack ipt_MASQUERADE
nf_nat_masquerade_ipv4 iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4
nf_nat_ipv4 xt_addrtype iptable_filter ip_tables x_tables br_netfilter
nf_nat nf_conntrack bridge stp llc joydev btusb btrtl btbcm btintel
bluetooth hp_wmi sparse_keymap hid_generic hid_multitouch intel_rapl
iosf_mbi uvcvideo x86_pkg_temp_thermal videobuf2_vmalloc
intel_powerclamp videobuf2_memops videobuf2_core coretemp v4l2_common
videodev kvm_intel media kvm crct10dif_pclmul crc32_pclmul
jitterentropy_rng sha256_ssse3 sha256_generic hmac efi_pstore drbg
ansi_cprng aesni_intel aes_x86_64 lrw gf128mul glue_helper ablk_helper
cryptd evdev psmouse serio_raw pcspkr efivars usbhid hid dm_thin_pool
dm_persistent_data dm_bio_prison dm_bufio libcrc32c tpm_infineon arc4
loop dm_mod
[4.910100]  binfmt_misc iwlmvm mac80211 iwlwifi rtsx_pci_ms
i2c_i801(+) cfg80211 snd_hda_codec_idt sg snd_hda_codec_generic
memstick lpc_ich(+) rfkill mei_me mei wmi battery shpchp 8250_fintek
i915(+) snd_hda_intel snd_hda_codec snd_hda_core intel_smartconnect
snd_hwdep video hp_accel(+) snd_pcm drm_kms_helper lis3lv02d tpm_tis
hp_wireless input_polldev snd_timer drm tpm snd ac soundcore
i2c_algo_bit button processor parport_pc ppdev lp parport efivarfs
autofs4 ext4 crc16 mbcache jbd2 sd_mod rtsx_pci_sdmmc mmc_core
crc32c_intel ahci libahci libata xhci_pci rtsx_pci ehci_pci scsi_mod
mfd_core ehci_hcd xhci_hcd e1000e ptp pps_core usbcore usb_common
thermal
[4.910102] CPU: 1 PID: 6 Comm: kworker/u16:0 Not tainted
4.3.0-1-amd64 #1 Debian 4.3.3-2
[4.910103] Hardware name: Hewlett-Packard HP EliteBook 840
G1/198F, BIOS L71 Ver. 01.21 09/03/2014
[4.910107] Workqueue: events_unbound async_run_entry_fn
[4.910109]   4d803f94 812ddc89
88042c6cb988
[4.910111]  81072b1d 8804283c8c00 88042c6cb9e0
880427c1c000
[4.910112]  8800b241ba00 8800b244c000 81072bac
a05722e2
[4.910112] Call Trace:
[4.910119]  [] ? dump_stack+0x40/0x57
[4.910121]  [] ? warn_slowpath_common+0x7d/0xb0
[4.910123]  [] ? warn_slowpath_fmt+0x5c/0x80
[4.910152]  [] ? intel_atomic_commit+0xd7a/0x12f0 [i915]
[4.910169]  [] ? drm_atomic_check_only+0x214/0x540 [drm]
[4.910176]  [] ?
drm_atomic_helper_set_config+0x1af/0x410 [drm_kms_helper]
[4.910187]  [] ?
drm_mode_set_config_internal+0x5e/0xf0 [drm]
[4.910193]  [] ? restore_fbdev_mode+0xaa/0x110
[drm_kms_helper]
[4.910199]  [] ?
drm_fb_helper_restore_fbdev_mode_unlocked+0x20/0x60 [drm_kms_helper]
[4.910204]  [] ? drm_fb_helper_set_par+0x29/0x50
[drm_kms_helper]
[4.910232]  [] ? intel_fbdev_set_par+0x16/0x60 [i915]
[4.910234]  [] ? fbcon_init+0x54d/0x5e0
[4.910237]  [] ? visual_init+0xc3/0x120
[4.910239]  [] ? do_bind_con_driver+0x1e3/0x3d0
[4.910240]  [] ? do_take_over_console+0x13b/0x190
[4.910242]  [] ? do_fbcon_takeover+0x53/0xb0
[4.910245]  [] ? notifier_call_chain+0x45/0x70
[4.910248]  [] ? __blocking_notifier_call_chain+0x41/0x60
[4.910250]  [] ? register_framebuffer+0x20b/0x340
[4.910252]  [] ? vga_switcheroo_client_fb_set+0x19/0x70
[4.910258]  [] ?
drm_fb_helper_initial_config+0x26c/0x420 [drm_kms_helper]
[4.910260]  [] ? async_run_entry_fn+0x45/0x130
[4.910262]  [] ? process_one_work+0x19f/0x3d0
[4.910263]  [] ? worker_thread+0x4d/0x450
[4.910264]  [] ? process_one_work+0x3d0/0x3d0
[4.910266]  [] ? kthread+0xcd/0xf0
[4.910269]  [] ? kthread_create_on_node+0x190/0x190
[4.910272]  [] ? ret_from_fork+0x3f/0x70
[4.910274]  [] ? kthread_create_on_node+0x190/0x190
[4.910275] ---[ end trace 8b2f2a96e8705ef9 ]---

Bug#808789: phantomjs: FTBFS in several architectures (patch)

[Zack Weinberg]

On Tue, Dec 22, 2015 at 6:43 PM, Mattia Rizzolo  wrote:
> oh, dear upstream maintainer, I just submitted a debian bug to
> phantomjs, and I'd welcome a quick word from you in
> https://bugs.debian.org/808789 :)

As I said in #795719, Debian should not attempt to package PhantomJS at all.

zw

Bug#805980: needrestart: "consider to login" grammar fix

[Thomas Liske]

tags 805980 upstream fixed-upstream
tags 803249 moreinfo
thanks


Hi,

On Tue, Nov 24, 2015 at 02:13:57PM +, Justin B Rye wrote:
> The only option we're left with is:
> 
>   Please consider a relogin or restart of the affected processes!
> 
> In the process of correcting this message I've made it consistent;
> really this string ought to be defined in one place and made
> translatable, but that sort of major surgery is a bit more than I can
> justify for a grammar nitpick.
> 
> Please consider to checkin these changes.

I've applied your grammar fix upstream.


Thanks & HTH,
Thomas

--

::  WWW:https://fiasko-nw.net/~thomas/  ::
   :::  Jabber:   xmpp:tho...@jabber.fiasko-nw.net  :::
::  flickr: https://www.flickr.com/photos/laugufe/  ::

Bug#806366: [Python-modules-team] Bug#806366: passlib issues

[Brian May]

Neil Williams  writes:

> I've had a quick look at the django setup in passlib and the first
> impressions are *not* good.

Thanks for this. Thanks for the patch.

Have you considered adding any of this feedback to the upstream report?


> 0: I'm not sure why passlib wants to provide django support, django has
> password hashing functionality built in.

What does the Django support provide? Oh, looks like it monkey patches
Django internals, so we can have improved password hashing for Django
users.

IMHO, passlib should concentrate on password hashing, and nothing
else. Not Django settings, or monkey patching Django.

Security software like this needs to be kept as simple as possible so
people can understand it.


> 1: passlib tries to support too many different versions of django,
> including django1.0 which was old even in Lenny. That unnecessarily
> complicates the code. (passfail also uses it's own internal handling of
> the django versions which seems unnecessary.)

Apparently Django <= 1.5 will get dropped, see
https://passlib.readthedocs.org/en/stable/lib/passlib.ext.django.html


> 2: passlib doesn't handle django as a "typical" django app with no
> centralised settings - this makes the move to 1.9 error-prone. Fixing
> passlib/tests/test_ext_django.py just reveals that
> passlib/tests/test_handlers_django.py gets confused between django
> imports for 1.4, 1.6 and gets the wrong result for >> 1.7 which now
> fails with 1.9. fuzz_verifier_django tries to import from
> django.contrib.auth.models import check_password which has moved into
> django.contrib.auth.hashers.

Agreed.


> 3: It's not clear to me why passlib couldn't be separated into a
> passlib and passlib-django upstream (dropping support for all versions
> of django prior to 1.6 or 1.7 in the process) to make the whole library
> much easier and simpler to handle.

Agreed.


> 4: passlib also has the python-support dependency which is deprecated:
> https://wiki.debian.org/Python/TransitionToDHPython2

Are we looking at the same version here?

Version 1.6.5-3 looks fine to me...
-- 
Brian May 

Bug#808789: phantomjs: FTBFS in several architectures (patch)

[Mattia Rizzolo]

oh, dear upstream maintainer, I just submitted a debian bug to
phantomjs, and I'd welcome a quick word from you in
https://bugs.debian.org/808789 :)

On Tue, Dec 22, 2015 at 11:36:59PM +, Mattia Rizzolo wrote:
> Reading around the source (expecially src/breakpad.cpp) I'd say
> phantomjs can deal just fine if breakpad is not available there.  With
> this belief I wrote the attached patch, which enables the inclusion of
> breakpad only in those 4 archs (x86_64, i386 and arm in QT_ARCH lingo,
> seems).
> Not that I'm not a Qt guy, so I did the following weird things (it
> works, though!):
>  * used QT_ARCH.  I'm not really sure if this is the right variable to
>use, I saw also different ones while googling for this issue
>  * couldn't find a nice way to say ((this or this) and (this or this))
>in the qmake syntax, so I falled back in nesting curly brackets...


what do you say?  (you can see the patch at the above url, attached at
the first message.


-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  http://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#808789: phantomjs: FTBFS in several architectures (patch)

[Mattia Rizzolo]

Package: src:phantomjs
Version: 1.6.0-2
Severity: serious
Tags: patch


this packages ftbfs just about everywhere (excepts amd64, i386, armel
and armhf) since google_breakpad is not really buildable there.

Reading around the source (expecially src/breakpad.cpp) I'd say
phantomjs can deal just fine if breakpad is not available there.  With
this belief I wrote the attached patch, which enables the inclusion of
breakpad only in those 4 archs (x86_64, i386 and arm in QT_ARCH lingo,
seems).
Not that I'm not a Qt guy, so I did the following weird things (it
works, though!):
 * used QT_ARCH.  I'm not really sure if this is the right variable to
   use, I saw also different ones while googling for this issue
 * couldn't find a nice way to say ((this or this) and (this or this))
   in the qmake syntax, so I falled back in nesting curly brackets...


Turns also out that this failure is keeping in the archive the ancient
python-pyphantomjs, which depends on python-support, that I'm trying to
kick, and since I prefer fixing packages instead of breaking them, here
you go.

Please tell me if you want to me to just upload it (might actually be a
huge improvment compared to the current buildable state...).


-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  http://mapreri.org  : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-
Description: enable google_breakpad only on amd64, i386, armel, armhf.
 breakpad is really unsuitable on other architectures, and phantomjs works
 fine anyway
Author: Mattia Rizzolo 
Forwarded: no
Last-Update: 2015-12-22

--- a/src/phantomjs.pro
+++ b/src/phantomjs.pro
@@ -64,16 +64,18 @@
 include(linenoise/linenoise.pri)
 include(qcommandline/qcommandline.pri)
 
-linux*|mac|openbsd* {
+linux*|mac|openbsd* { equals(QT_ARCH, x86_64)|equals(QT_ARCH, 
i386)|equals(QT_ARCH, arm) {
 INCLUDEPATH += breakpad/src
 
 SOURCES += breakpad/src/client/minidump_file_writer.cc \
   breakpad/src/common/convert_UTF.c \
   breakpad/src/common/md5.cc \
   breakpad/src/common/string_conversion.cc 
-}
 
-linux* {
+DEFINES += USE_BREAKPAD=1
+}}
+
+linux* { equals(QT_ARCH, x86_64)|equals(QT_ARCH, i386)|contains(QT_ARCH, arm) {
 SOURCES += 
breakpad/src/client/linux/crash_generation/crash_generation_client.cc \
   breakpad/src/client/linux/handler/exception_handler.cc \
   breakpad/src/client/linux/log/log.cc \
@@ -84,7 +86,7 @@
   breakpad/src/common/linux/guid_creator.cc \
   breakpad/src/common/linux/memory_mapped_file.cc \
   breakpad/src/common/linux/safe_readlink.cc
-}
+}}
 
 mac {
 SOURCES += 
breakpad/src/client/mac/crash_generation/crash_generation_client.cc \
--- a/src/crashdump.cpp
+++ b/src/crashdump.cpp
@@ -37,6 +37,7 @@
 #include 
 #include 
 
+#ifdef USE_BREAKPAD
 #ifdef Q_OS_LINUX
 #include "client/linux/handler/exception_handler.h"
 #define HAVE_BREAKPAD
@@ -58,6 +59,7 @@
 #define MDC_PATH_ARG   const wchar_t*
 #define MDC_EXTRA_ARGS void*, EXCEPTION_POINTERS*, MDRawAssertionInfo*
 #endif
+#endif // USE_BREAKPAD
 
 #ifdef HAVE_BREAKPAD
 


signature.asc
Description: PGP signature

Bug#808786: nbtscan: Verbose output looks odd (missing format specifiers)

[Johan Eidenvall]

Package: nbtscan
Version: 1.5.1-6
Followup-For: Bug #808786

Dear Maintainer,

After sending the bug report I realized that I made a mistake. The odd output
was for the `dump' mode (-d) not the `verbose' mode (-v). The bug is still there
(in dump mode) and everything else in the report should be valid.

Regards,
--
Johan

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

Kernel: Linux 3.16.0-4-686-pae (SMP w/2 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 nbtscan depends on:
ii  libc6  2.19-18+deb8u1

nbtscan recommends no packages.

nbtscan suggests no packages.

-- no debconf information

Bug#601135: Cannot be fixed without an example file

[Standard-Postfach]

Hi Gilles,

2015-⁠12-⁠21 13:13, Gilles Filippini:

I confirm that the bug is reproducible. Back in 2010 the OP gave me
access to such a map file coming from a garmin GPS device. But I failed
solving the problem.


Yes, that file would be helpful. Is there some way to obtain this file? 
If yes, then I'll try to investigate the problem.


If not, then there is still no way to investigate further, so I'd still 
propose closing the bug.


Greetings

S.Leske

Bug#808788: higan: Outdated Homepage field in debian/control

[John Paul Adrian Glaubitz]

Package: higan
Version: 094-6
Severity: minor

Hi!

I just noticed the Homepage field in debian/control is outdated.

It points to: http://byuu.org/higan/
while the new URL is: http://byuu.org/emulation/higan/

Please update debian/control with your next upload.

PS: Higan 0.96 was just released ;-).

Cheers,
Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#807627: RFS: taskd/1.1.0+dfsg-1 [ITP]

[Sebastien Badia]

On Fri, Dec 11, 2015 at 07:19:47PM (+0100), Tobias Frost wrote:
> Patches:
> - Please forward the patches to upstream more aggresively.
> For example, /tmp/taskd.pid is a BUG, because pid files are supposed to
> be in run  (or var/run as legacy path)
> - Reproducible builds should not be only for Debian, forward them to
> make them aware of the importance of reproducible builds. 
> - There is one patch that has not an "Forwarded" indication. 
> - Some patches have been applied upstream, please add a "Applied-
> Upstream" Header (bonis: with a reference to be commit, if easily
> found.)
> 
> - get-orig-source.sh seems to remove some files, however they
> should be also mentioned in d/copyright Files-Excluded and also 
> explain why they are removed and who it would be dfsg-non-free
> otherwise. (README.source)
> Looking at the script, it seems that you are not repacking because of 
> DFSG problems, but just to stip unneeded files. If you do that, "dfsg" 
> would be wrong, use "ds" or "repack" instead.
> 
> - postinst seems to fiddle with the config file, which is installed by
> the package. This is discouraged, as this will lead in subsequent
> installations to a prompt asking the user what to be done
> (The conf file has been modified ) This is actually a RC bug
> (Policy 10.7.3 -- must not ask uneccessary questions) 
> I recommend either install a file already populated with (sane)
> defaults OR not to ship the (empty) conffile at all but to create it
> during install. (Note, when not shipping the conffile,you also have to
> handle purges in postrm manually)
> 
> Nitpicks:
> - trailing whitespaces in README.Debian
> - TODO.Debian mentions the init.d script as not yet present.
> - d/control: dh-systemd does not need a versioned dep.
> - d/copyright: the comment for the debian section is not needed
> - prefer using d/clean instead of override_dh_autoclean
> - d/taskd.dirs is not needed.
>   
> 
> The conffile thing is a show stopper, otherwise the package seems
> ready.
> 
> I did not perform copyright review yet. 

Hi here,

Many thanks Tobias for this review!
Just fixed all the issues/comments, if you want to re-take a look, it would be
super cool!

About repack, I just queried to upstream about src/tls/* (GNUTLS examples, but
apparently unused: https://bug.tasktools.org/browse/TD-110), we could maybe wait
an answer, generally Paul answer quickly.

And for config file I finally decided to ship a generated config file in order
to avoid init questions, let me know what do you think about.

Thanks!

Seb


signature.asc
Description: PGP signature

Bug#808787: Split binary package to allow coinstallation with initramfs-tools

[Ben Hutchings]

Package: dracut
Version: 044+3-1
Severity: normal
Tags: patch

As discussed at DebConf 15, it is desirable to split both dracut and
initramfs-tools binary packages so that users can install and test
both tools without overwriting their existing initramfs images.  The
packages containing kernel hook scripts would continue to conflict.

I've now implemented this split in initramfs-tools (version
0.121~rc1).  Please can you implement it in dracut now?  I've
attached a patch which I believe does this correctly.

Ben.
diff -Nru dracut-044+3/debian/changelog dracut-044+3/debian/changelog
--- dracut-044+3/debian/changelog	2015-11-29 12:49:04.0 +
+++ dracut-044+3/debian/changelog	2015-12-22 22:26:52.0 +
@@ -1,3 +1,9 @@
+dracut (044+3-2) UNRELEASED; urgency=medium
+
+  * Split dracut binary package into core and automation hooks
+
+ -- Ben Hutchings   Tue, 22 Dec 2015 22:26:51 +
+
 dracut (044+3-1) unstable; urgency=low
 
   * new upstream, Closes: #802823
diff -Nru dracut-044+3/debian/control dracut-044+3/debian/control
--- dracut-044+3/debian/control	2015-11-29 10:44:31.0 +
+++ dracut-044+3/debian/control	2015-12-22 22:55:21.0 +
@@ -9,16 +9,25 @@
 Homepage: http://www.kernel.org/pub/linux/utils/boot/dracut/dracut.html
 
 Package: dracut
-Architecture: any
+Architecture: all
 Multi-Arch: foreign
-Recommends: cryptsetup, dmsetup, dmraid, lvm2, mdadm
 Suggests: dracut-network
-Depends: cpio, kmod, udev, kpartx, console-setup, util-linux (>= 2.20), pkg-config, ${shlibs:Depends}, ${misc:Depends}
-Breaks: dracut-network (<< 043-2)
-Replaces: dracut-network (<< 043-2)
+Depends: dracut-core (>= ${binary:Version}), dracut-core (<< ${binary:Version}+b+~)
 Provides: linux-initramfs-tool
 Conflicts: initramfs-tools, live-tools
-Description: Low-level tool for generating an initramfs image
+Description: Low-level tool for generating an initramfs image (automation)
+ This package builds a bootable initramfs for Linux kernel packages.  The
+ initramfs is loaded along with the kernel and is responsible for
+ mounting the root filesystem and starting the main init system.
+
+Package: dracut-core
+Architecture: any
+Multi-Arch: foreign
+Recommends: cryptsetup, dmsetup, dmraid, lvm2, mdadm
+Depends: cpio, kmod, udev, kpartx, console-setup, util-linux (>= 2.20), pkg-config, ${shlibs:Depends}, ${misc:Depends}
+Breaks: dracut-network (<< 043-2), dracut (<< 044+3-2~)
+Replaces: dracut-network (<< 043-2), dracut (<< 044+3-2~)
+Description: Low-level tool for generating an initramfs image (core tools)
  Unlike existing initramfs's, this is an attempt at having as little as
  possible hard-coded into the initramfs as possible.  The initramfs has
  (basically) one purpose in life -- getting the rootfs mounted so that
@@ -32,7 +41,7 @@
 Package: dracut-network
 Architecture: all
 Recommends: nfs-common, open-iscsi, nbd-client, curl
-Depends: dracut, iputils-arping, isc-dhcp-client, ${misc:Depends}
+Depends: dracut-core, iputils-arping, isc-dhcp-client, ${misc:Depends}
 Description: Low-level tool for generating an initramfs image
  Unlike existing initramfs's, this is an attempt at having as little as
  possible hard-coded into the initramfs as possible.  The initramfs has
@@ -46,12 +55,12 @@
 
 Package: dracut-config-generic
 Architecture: all
-Depends: dracut
+Depends: dracut-core
 Description: Low-level tool for generating an initramfs image
  This is the dracut configuration to turn off hostonly image generation
 
 Package: dracut-config-rescue
 Architecture: all
-Depends: dracut
+Depends: dracut-core
 Description: Low-level tool for generating an initramfs image
  This is the dracut configuration to turn on rescue image generation
diff -Nru dracut-044+3/debian/dracut-core.dirs dracut-044+3/debian/dracut-core.dirs
--- dracut-044+3/debian/dracut-core.dirs	1970-01-01 01:00:00.0 +0100
+++ dracut-044+3/debian/dracut-core.dirs	2015-12-22 22:32:13.0 +
@@ -0,0 +1,25 @@
+usr/lib/dracut
+usr/lib/dracut/modules.d/00dash
+usr/lib/dracut/modules.d/01fips
+usr/lib/dracut/modules.d/02fips-aesni
+usr/lib/dracut/modules.d/90crypt
+usr/lib/dracut/modules.d/90dm
+usr/lib/dracut/modules.d/90dmraid
+usr/lib/dracut/modules.d/90kernel-modules
+usr/lib/dracut/modules.d/90lvm
+usr/lib/dracut/modules.d/90mdraid
+usr/lib/dracut/modules.d/90multipath
+usr/lib/dracut/modules.d/95dasd
+usr/lib/dracut/modules.d/95dasd_mod
+usr/lib/dracut/modules.d/95debug
+usr/lib/dracut/modules.d/95resume
+usr/lib/dracut/modules.d/95rootfs-block
+usr/lib/dracut/modules.d/95terminfo
+usr/lib/dracut/modules.d/95udev-rules
+usr/lib/dracut/modules.d/98syslog
+usr/lib/dracut/modules.d/98usrmount
+usr/lib/dracut/modules.d/99base
+/var/lib/dracut
+/etc/dracut.conf.d
+/etc/bash_completion.d
+/etc/logrotate.d
diff -Nru dracut-044+3/debian/dracut-core.docs dracut-044+3/debian/dracut-core.docs
--- dracut-044+3/debian/dracut-core.docs	1970-01-01 01:00:00.0 +0100
+++ dracut-044+3/debian/dracut-core.docs	2015-11-29 1

Bug#808786: nbtscan: Verbose output looks odd (missing format specifiers)

[Johan Eidenvall]

Package: nbtscan
Version: 1.5.1-6
Severity: normal

Dear Maintainer,

Part of the verbose output of the nbtscan probram is looking
odd. There are clearly some missing format specifiers in some of the
format strings to some of the `printf'.  This causes the verbose
output to look like:

FRMRs Received: 0x%04 (0)
FRMRs Transmitted: 0x%04 (0)
IFrame Receive errors: 0x%04 (0)
Transmit aborts: 0x%04 (0)
Transmitted: 0x%08 (0)
Received: 0x%08 (0)
IFrame transmit errors: 0x%04 (0)
No receive buffers: 0x%04 (0)
tl timeouts: 0x%04 (0)
ti timeouts: 0x%04 (0)
Free NCBS: 0x%04 (0)
NCBS: 0x%04 (0)
Max NCBS: 0x%04 (0)
No transmit buffers: 0x%04 (0)
Max datagram: 0x%04 (0)
Pending sessions: 0x%04 (0)
Max sessions: 0x%04 (0)
Packet sessions: 0x%04 (0)

 instead of ...

FRMRs Received: 0x (0)
FRMRs Transmitted: 0x (0)
IFrame Receive errors: 0x (0)
Transmit aborts: 0x (0)
Transmitted: 0x (0)
Received: 0x (0)
IFrame transmit errors: 0x (0)
No receive buffers: 0x (0)
tl timeouts: 0x (0)
ti timeouts: 0x (0)
Free NCBS: 0x (0)
NCBS: 0x (0)
Max NCBS: 0x (0)
No transmit buffers: 0x (0)
Max datagram: 0x (0)
Pending sessions: 0x (0)
Max sessions: 0x (0)
Packet sessions: 0x (0)


Changing these format strings (in function d_print_hostinfo in
nbtscan.c) to conform with other smilar `printf's seems to fix the
problem. This is the changes I made to get the fixed output above:

--- nbtscan-1.5.1~/nbtscan.c2015-12-22 22:28:08.779354535 +0100
+++ nbtscan-1.5.1/nbtscan.c 2015-12-22 22:20:54.789202494 +0100
@@ -131,24 +131,24 @@
 printf("Version major: 0x%02x (%1$d)\n", hostinfo->footer->version_major);
 printf("Version minor: 0x%02x (%1$d)\n", hostinfo->footer->version_minor);
 printf("Duration: 0x%04x (%1$d)\n", hostinfo->footer->duration);
-printf("FRMRs Received: 0x%04 (%1$d)\n", hostinfo->footer->frmps_received);
-printf("FRMRs Transmitted: 0x%04 (%1$d)\n", 
hostinfo->footer->frmps_transmitted);
-printf("IFrame Receive errors: 0x%04 (%1$d)\n", 
hostinfo->footer->iframe_receive_errors);
-printf("Transmit aborts: 0x%04 (%1$d)\n", 
hostinfo->footer->transmit_aborts);
-printf("Transmitted: 0x%08 (%1$d)\n", hostinfo->footer->transmitted);
-printf("Received: 0x%08 (%1$d)\n", hostinfo->footer->received);
-printf("IFrame transmit errors: 0x%04 (%1$d)\n", 
hostinfo->footer->iframe_transmit_errors);
-printf("No receive buffers: 0x%04 (%1$d)\n", 
hostinfo->footer->no_receive_buffer);
-printf("tl timeouts: 0x%04 (%1$d)\n", hostinfo->footer->tl_timeouts);
-printf("ti timeouts: 0x%04 (%1$d)\n", hostinfo->footer->ti_timeouts);
-printf("Free NCBS: 0x%04 (%1$d)\n", hostinfo->footer->free_ncbs);
-printf("NCBS: 0x%04 (%1$d)\n", hostinfo->footer->ncbs);
-printf("Max NCBS: 0x%04 (%1$d)\n", hostinfo->footer->max_ncbs);
-printf("No transmit buffers: 0x%04 (%1$d)\n", 
hostinfo->footer->no_transmit_buffers);
-printf("Max datagram: 0x%04 (%1$d)\n", hostinfo->footer->max_datagram);
-printf("Pending sessions: 0x%04 (%1$d)\n", 
hostinfo->footer->pending_sessions);
-printf("Max sessions: 0x%04 (%1$d)\n", hostinfo->footer->max_sessions);
-printf("Packet sessions: 0x%04 (%1$d)\n", 
hostinfo->footer->packet_sessions);
+printf("FRMRs Received: 0x%04x (%1$d)\n", 
hostinfo->footer->frmps_received);
+printf("FRMRs Transmitted: 0x%04x (%1$d)\n", 
hostinfo->footer->frmps_transmitted);
+printf("IFrame Receive errors: 0x%04x (%1$d)\n", 
hostinfo->footer->iframe_receive_errors);
+printf("Transmit aborts: 0x%04x (%1$d)\n", 
hostinfo->footer->transmit_aborts);
+printf("Transmitted: 0x%08x (%1$d)\n", hostinfo->footer->transmitted);
+printf("Received: 0x%08x (%1$d)\n", hostinfo->footer->received);
+printf("IFrame transmit errors: 0x%04x (%1$d)\n", 
hostinfo->footer->iframe_transmit_errors);
+printf("No receive buffers: 0x%04x (%1$d)\n", 
hostinfo->footer->no_receive_buffer);
+printf("tl timeouts: 0x%04x (%1$d)\n", hostinfo->footer->tl_timeouts);
+printf("ti timeouts: 0x%04x (%1$d)\n", hostinfo->footer->ti_timeouts);
+printf("Free NCBS: 0x%04x (%1$d)\n", hostinfo->footer->free_ncbs);
+printf("NCBS: 0x%04x (%1$d)\n", hostinfo->footer->ncbs);
+printf("Max NCBS: 0x%04x (%1$d)\n", hostinfo->footer->max_ncbs);
+printf("No transmit buffers: 0x%04x (%1$d)\n", 
hostinfo->footer->no_transmit_buffers);
+printf("Max datagram: 0x%04x (%1$d)\n", hostinfo->footer->max_datagram);
+printf("Pending sessions: 0x%04x (%1$d)\n", 
hostinfo->footer->pending_sessions);
+printf("Max sessions: 0x%04x (%1$d)\n", hostinfo->footer->max_sessions);
+printf("Packet sessions: 0x%04x (%1$d)\n", 
hostinfo->footer->packet_sessions);
   };
 };
 
If you apply this patch, check that it actually fixes the problem and
that there is no other underlying problem.

Regards,
--
Johan Eidenvall


-- System Information:
Debian Release: 8.2
  APT prefers stable-updates
 

Bug#808246: Maybe the bugs are related

[Lennart Sorensen]

I found indications that perhaps both problems are in fact caused by ld
no longer including undefined symbols in the output.

Here is a section from the working module built with old binutils:

  0012980: 0047 4343 3a20 2844 6562 6961 6e20 342e  .GCC: (Debian 4.
  0012990: 392e 322d 3130 2920 342e 392e 3200 0047  9.2-10) 4.9.2..G
  00129a0: 4343 3a20 2844 6562 6961 6e20 342e 392e  CC: (Debian 4.9.
  00129b0: 322d 3130 2920 342e 392e 3200 0047 4343  2-10) 4.9.2..GCC
  00129c0: 3a20 2844 6562 6961 6e20 342e 392e 322d  : (Debian 4.9.2-
  00129d0: 3130 2920 342e 392e 3200 0047 4343 3a20  10) 4.9.2..GCC: 
  00129e0: 2844 6562 6961 6e20 342e 392e 322d 3130  (Debian 4.9.2-10
  00129f0: 2920 342e 392e 3200 0047 4343 3a20 2844  ) 4.9.2..GCC: (D
  0012a00: 6562 6961 6e20 342e 392e 322d 3130 2920  ebian 4.9.2-10) 
  0012a10: 342e 392e 3200 0047 4343 3a20 2844 6562  4.9.2..GCC: (Deb
  0012a20: 6961 6e20 342e 392e 322d 3130 2920 342e  ian 4.9.2-10) 4.
  0012a30: 392e 3200 0047 4343 3a20 2844 6562 6961  9.2..GCC: (Debia
  0012a40: 6e20 342e 392e 322d 3130 2920 342e 392e  n 4.9.2-10) 4.9.
  0012a50: 3200 0047 4343 3a20 2844 6562 6961 6e20  2..GCC: (Debian 
  0012a60: 342e 392e 322d 3130 2920 342e 392e 3200  4.9.2-10) 4.9.2.
  0012a70: 002e 7379 6d74 6162 002e 7374 7274 6162  ..symtab..strtab
  0012a80: 002e 7368 7374 7274 6162 002e 6e6f 7465  ..shstrtab..note
  0012a90: 2e67 6e75 2e62 7569 6c64 2d69 6400 2e72  .gnu.build-id..r
  0012aa0: 656c 612e 7465 7874 002e 7265 6c61 2e69  ela.text..rela.i
  0012ab0: 6e69 742e 7465 7874 002e 7265 6c61 2e66  nit.text..rela.f
  0012ac0: 6978 7570 002e 7265 6c61 2e65 7869 742e  ixup..rela.exit.
  0012ad0: 7465 7874 002e 7265 6c61 2e74 6578 742e  text..rela.text.
  0012ae0: 756e 6c69 6b65 6c79 002e 7265 6c61 5f5f  unlikely..rela__
  0012af0: 6b73 796d 7461 625f 6770 6c00 2e72 656c  ksymtab_gpl..rel
  0012b00: 612e 726f 6461 7461 002e 7265 6c61 5f5f  a.rodata..rela__
  0012b10: 6275 675f 7461 626c 6500 2e72 6f64 6174  bug_table..rodat
  0012b20: 612e 7374 7231 2e38 002e 7265 6c61 5f5f  a.str1.8..rela__
  0012b30: 6d63 6f75 6e74 5f6c 6f63 002e 7265 6c61  mcount_loc..rela
  0012b40: 5f5f 6578 5f74 6162 6c65 005f 5f6b 7379  __ex_table.__ksy
  0012b50: 6d74 6162 5f73 7472 696e 6773 002e 6d6f  mtab_strings..mo
  0012b60: 6469 6e66 6f00 5f5f 7665 7273 696f 6e73  dinfo.__versions
  0012b70: 002e 7265 6c61 5f5f 6b63 7263 7461 625f  ..rela__kcrctab_
  0012b80: 6770 6c00 2e72 656c 612e 6461 7461 002e  gpl..rela.data..
  0012b90: 7265 6c61 2e64 6174 612e 7265 6c2e 726f  rela.data.rel.ro
  0012ba0: 002e 7265 6c61 2e6f 7064 002e 7265 6c61  ..rela.opd..rela
  0012bb0: 2e74 6f63 002e 7265 6c61 2e67 6e75 2e6c  .toc..rela.gnu.l
  0012bc0: 696e 6b6f 6e63 652e 7468 6973 5f6d 6f64  inkonce.this_mod
  0012bd0: 756c 6500 2e62 7373 002e 7374 7562 7300  ule..bss..stubs.
  0012be0: 2e66 7472 6163 652e 7472 616d 7000 2e63  .ftrace.tramp..c
  0012bf0: 6f6d 6d65 6e74       omment..

And the same section from the new binutils build (the disassenmbled
module is totally identical as far as code is concerned):

  0012980: 0047 4343 3a20 2844 6562 6961 6e20 342e  .GCC: (Debian 4.
  0012990: 392e 322d 3130 2920 342e 392e 3200 0047  9.2-10) 4.9.2..G
  00129a0: 4343 3a20 2844 6562 6961 6e20 342e 392e  CC: (Debian 4.9.
  00129b0: 322d 3130 2920 342e 392e 3200 0047 4343  2-10) 4.9.2..GCC
  00129c0: 3a20 2844 6562 6961 6e20 342e 392e 322d  : (Debian 4.9.2-
  00129d0: 3130 2920 342e 392e 3200 0047 4343 3a20  10) 4.9.2..GCC: 
  00129e0: 2844 6562 6961 6e20 342e 392e 322d 3130  (Debian 4.9.2-10
  00129f0: 2920 342e 392e 3200 0047 4343 3a20 2844  ) 4.9.2..GCC: (D
  0012a00: 6562 6961 6e20 342e 392e 322d 3130 2920  ebian 4.9.2-10) 
  0012a10: 342e 392e 3200 0047 4343 3a20 2844 6562  4.9.2..GCC: (Deb
  0012a20: 6961 6e20 342e 392e 322d 3130 2920 342e  ian 4.9.2-10) 4.
  0012a30: 392e 3200 0047 4343 3a20 2844 6562 6961  9.2..GCC: (Debia
  0012a40: 6e20 342e 392e 322d 3130 2920 342e 392e  n 4.9.2-10) 4.9.
  0012a50: 3200 0047 4343 3a20 2844 6562 6961 6e20  2..GCC: (Debian 
  0012a60: 342e 392e 322d 3130 2920 342e 392e 3200  4.9.2-10) 4.9.2.
  0012a70:          
  0012a80:       0300 0001  
  0012a90:          

So some stuff was dropped by the new binutils, just like it was from
vmlinux on ppc64el, and that could very well be what the module loading
code was looking for.

I can't find any way to undo this change to ld about dropping undefined
symbols from the output.

-- 
Len Sorensen

Bug#797965: bs1770gain somehow "destroys" gapless playback on (at least) lame encoded MP3s

[Andreas Cadhalpun]

Hi,

On 19.12.2015 23:55, Christoph Anton Mitterer wrote:
> On Sat, 2015-12-19 at 23:24 +0100, Andreas Cadhalpun wrote:
>> Now I'm a bit skeptical about "LAME adding some special tags".
> IIRC, the LAME tag isn't actually an ID3 tag, but padded in some other
> parts of the MP3 header which aren't used.
> http://gabriel.mp3-tech.org/mp3infotag.html
> http://wiki.hydrogenaud.io/index.php?title=LAME#VBR_header_and_LAME_tag
> http://libzplay.sourceforge.net/LAMETAG.html

Thanks for this clarification. I was indeed confused by the ID3 tags
mentioned in the initial report.

> What I would assume that ffmpeg does, is, that it simply drops or
> somehow mangles up the LAMEtag,... or actually modifies the audio
> stream so that it doesn't fit to the LAMEtag anymore.

Indeed, FFmpeg parses the XING/LAME header when demuxing and then
writes a new one when muxing.

On 20.12.2015 06:52, Peter Belkner wrote:
> AFAIK it's the so called LAME or XING header.
> I myself was adding the first version of it to FFmpeg some time ago

Oh cool! What a coincidence!

> but unfortunately not based on my proposal (just copy it) but the way
> the FFmpeg team wants to have it. Meanwhile it's changed anyway.

Well, simply copying would have its problems, e.g. if it's actually
transcoded, the copied header would most likely be quite wrong...

On the other hand, parsing the header has its own problems, as this
bug shows: While the demuxer reads the correct gapless values from
the XING/LAME header, they are never propagated to the muxer and
not written to the output.

I've hacked together a patch[1] that makes this work, but don't get too
excited: It can't be committed as is, because it uses private
libavformat fields outside of libavformat.

Best regards,
Andreas


1: https://ffmpeg.org/pipermail/ffmpeg-devel/2015-December/185657.html

Bug#734702: [Pkg-gridengine-devel] libdb dependency in v8.1.8

[Afif Elghraoui]

Control: tag -1 pending

على الجمعـة 11 كانون الأول 2015 ‫14:08، كتب Dave Love:
> Afif Elghraoui  writes:
> 
>>> * Replace dependency on db-5.1 with unversioned package
>>>
>>>   The db tools need to be consistent with the library version used in
>>>   the build.
>>
>> The versioning consistency should be taken care of with
>> {shlibs:Depends}. db-5.1 isn't in Debian anymore (it's been replaced
>> with 5.3).
> 
> How does that get you the right db-util package with the tools to handle
> the specific version of the db spool?
>

The unversioned package libdb-dev is an empty package that depends on
the latest versioned one (libdb5.3-dev). The library's versioned soname
is used to determine the right package for the runtime shared library
dependency, so building right now with libdb-dev gets you a package that
depends on libdb5.3.

Do you want to keep the build-dependency specifically on 5.3 and
manually handle libdb version upgrades?

>> By the way, we have a patch in
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=734702
>> related to this transition that touches
>> source/libs/spool/berkeleydb/sge_bdb.c
>> I'm not sure if you want to integrate that (or already have) upstream.
> 
> My current source definitely builds against 5.3.
> 

It said something about skipping non-existent error defines. I missed
that this patch actually modifies a quilt patch in the packaging and I
think you've cleaned all those out. I guess we can declare this fixed

regards
Afif

-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name

Bug#808785: /sbin/ldconfig.real: /usr/lib/x86_64-linux-gnu/liblmdb.so.0 is not a symbolic link

[Diederik de Haas]

Package: liblmdb0
Version: 0.9.17-1
Severity: normal

On tonights update I got the following message:
update-initramfs: deferring update (trigger activated)
Processing triggers for libc-bin (2.21-4) ...
/sbin/ldconfig.real: /usr/lib/x86_64-linux-gnu/liblmdb.so.0 is not a symbolic 
link

When checking what could've caused this message, I checked the following
things:

$ ls -l /usr/lib/x86_64-linux-gnu/liblmdb.*
-rw-r--r-- 1 root root 84592 dec 22 11:07 /usr/lib/x86_64-linux-gnu/liblmdb.so.0
-rw-r--r-- 1 root root 84592 dec 22 11:07 
/usr/lib/x86_64-linux-gnu/liblmdb.so.0.0.0

And diff-ing those files indicated that they are identical.
So I have a feeling that /usr/lib/x86_64-linux-gnu/liblmdb.so.0 should
be a symbolic link to /usr/lib/x86_64-linux-gnu/liblmdb.so.0.0.0


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

Kernel: Linux 4.3.0-1-amd64 (SMP w/4 CPU cores)
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 liblmdb0 depends on:
ii  libc6  2.21-4
ii  multiarch-support  2.21-4

liblmdb0 recommends no packages.

liblmdb0 suggests no packages.

-- no debconf information

Bug#808784: RFA: xserver-xorg-video-openchrome -- X.Org X server -- VIA display driver

[Julien Viard de Galbert]

Package: wnpp
Severity: normal

I request an adopter for the xserver-xorg-video-openchrome package.

The motherboard with Via chipset I owned died a few years ago, this
stopped my interest in the package. Also time is laking... so the package
has been handled by the Debian X Strike Force during my lack of
activity.
This is basically to make it clear that I'm no longer maintaining it.

Also it seams the driver fails to build with next xserver version [1]
and will probably be removed from testing if nobody steps in. So if you
rely on this driver it's time to contribute as I did 5 years ago !

 1: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=808735#17

Best Regards

Julien VdG

The package description is:
 OpenChrome is a project for the development of free and open-source drivers
 for the VIA UniChrome video chipsets.
 .
 Originally called the 'snapshot' release, since it was a snapshot of an
 experimental branch of the unichrome cvs code, this is a continued development
 of the open source unichrome driver (from http://unichrome.sf.net) which
 also incorporates support for the unichrome-pro chipsets.
 .
 Support for hardware acceleration (XvMC) for all chipsets has subsequently
 been ripped out of the unichrome.sf.net driver. Therefore your only option if
 you wish to make use of the acceleration features of your VIA chip with free
 and open-source drivers is to use this version of the driver.

Bug#808779: disorderfs: not working with --multi-user=yes

[Andrew Ayer]

On Tue, 22 Dec 2015 21:18:34 +0100
Reiner Herrmann  wrote:

> Hi Andrew!
> 
> I just noticed that disorderfs isn't working when --multi-user=yes is
> specified.  Instead of reversing the readdir order or shuffling the
> order, it is only returning the files in normal readdir order (i.e.,
> what you would also get without disorderfs).
> 
> Regards,
>  Reiner

Hi Reiner,

Thanks for noticing this!  There was some memory corruption during
option parsing that wasn't detected by the compiler because
fuse_opt_parse isn't type-safe.  If you turned on multi-user mode, it
clobbered the other options :-(

I just pushed a fix to Git and will cut a release later today.

Regards,
Andrew

Bug#803976: closed by Ondřej Surý (Bug#803976: fixed in cyrus-imapd-2.4 2.4.18-1)

[Ondřej Surý]

Hi Agustín,

do you perhaps have a backup of the /usr/lib/cyrus/*.txt files and
/var/lib/cyrus/* databases?

The patch is incorrect because it doesn't solve the main problem; the
code should not be executed if Berkeley DB is still used.

Cheers,
Ondrej

On Tue, Dec 22, 2015, at 22:30, Agustín Eijo wrote:
> Hello,
> 
> I tried to make the upgrade from wheezy to sid, but I have the same 
> problem with 2.4.18-1.
> 
> The script  /usr/lib/cyrus/bin/upgrade-db delete /var/lib/cyrus/db
> directory
> 
> I tried changing:
> 
> 190c190
> <   rm -rf $CONFIG_DIR/db
> ---
>  >   rm -rf $CONFIG_DIR/db/*
> 
> And the upgrade works well...
> 
> Agustín.
> 
> 
> El 21/12/2015 a las 09:24 a.m., Debian Bug Tracking System escribió:
> > This is an automatic notification regarding your Bug report
> > which was filed against the cyrus-common package:
> >
> > #803976: cyrus-common: /usr/lib/cyrus/bin/upgrade-db delete 
> > /var/lib/cyrus/db on upgrade from wheezy to jessie
> >
> > It has been closed by Ondřej Surý .
> >
> > 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 Ondřej Surý 
> >  by
> > replying to this email.
> >
> >
> 


-- 
Ondřej Surý 
Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server

Bug#808783: RFS: openviewerfx [ITP] Open Source JavaFX PDF Viewer

[Jerome Benoit]

Package: sponsorship-requests
Severity: normal

Dear Mentors:

I am looking for a sponsor for the package openviewerfx [1],
a Java library to manipulate PDF material (which is the
successor of the jpedal java library).

Thanks,
Jerome

[1] http://anonscm.debian.org/cgit/pkg-java/openviewerfx.git


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

Kernel: Linux 3.16.7-ckt11-amd64-mbp62 (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: sysvinit (via /sbin/init)

Bug#803976: closed by Ondřej Surý (Bug#803976: fixed in cyrus-imapd-2.4 2.4.18-1)

[Agustín Eijo]

Hello,

I tried to make the upgrade from wheezy to sid, but I have the same 
problem with 2.4.18-1.


The script  /usr/lib/cyrus/bin/upgrade-db delete /var/lib/cyrus/db directory

I tried changing:

190c190
<   rm -rf $CONFIG_DIR/db
---
>   rm -rf $CONFIG_DIR/db/*

And the upgrade works well...

Agustín.


El 21/12/2015 a las 09:24 a.m., Debian Bug Tracking System escribió:

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

#803976: cyrus-common: /usr/lib/cyrus/bin/upgrade-db delete /var/lib/cyrus/db 
on upgrade from wheezy to jessie

It has been closed by Ondřej Surý .

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 Ondřej Surý 
 by
replying to this email.

Bug#714399: a7xpg: spaceship drifts to upper left corner of screen making gameplay impossible

[Markus Koschany]

Am 22.12.2015 um 21:36 schrieb Jason Quinn:
> Your sentence that says "when you can't reproduce such an apparently
> obvious issue" that makes it sound as if I'm doing something wrong.
> It's clear you intend to say that you cannot reproduce the issue but
> your phrasing could be improved.
> 
> I do not have a joystick. The keyboard is attached to a laptop. I have
> not tried the game recently on another computer but if I get the
> chance I will. As I wrote before, I believe I have already seen this
> issue on multiple machines (likely on another Dell laptop at minimum)
> but it's been a long time since I would have tried and I don't recall
> anything for certain.
> 
> As for seeing more people report the bug, this an an obscure game.
> When you start with the small fraction of people running Debian and
> multiply it by the fraction of people who actually install this game
> and then multiply by the fraction of people who experience the bug,
> and then multiply the fraction of people who report bugs (which is
> canonically taken to be about 1 in 100 users) , you are getting down
> to a small number of expected bug reports... perhaps on the order of
> one like just me. While it's interesting that you do not experience
> the bug, I assure you the bug does happen for me; and your message
> almost makes it sound like you dismiss the concept of bugs that depend
> on various external issues or even hardware. It's far from obvious to
> me that we should have seen more confirms in this case and I also note
> the lack of additional "works for me" comments. So please don't
> dismiss my report as if you are sceptical of the problem that *I'm*
> experiencing because just because you don't see it.
> 
> Jason

The point is that you reported a bug against a7xpg which nobody could
reproduce and then we rely on the submitter to provide further
information, so that we can narrow the issue down. [1] Two years ago I
sent you an e-mail which you never replied to. Bug reports are for
tracking errors in software and to eventually make software better but
first of all we have to agree on that there is an error at all before we
can even start to work on a solution.

While reading your bug report and playing the game myself, it was
obvious to me that the game must be unplayable for you but that your
hardware must have played a decisive part. Hence my suggestion to try
the game on another computer to confirm my suspicion. It could be a bug
in the SDL library which a7xpg depends on, it could be an issue with
your keyboard or keyboard drivers or something completely different. If
we knew more about your setup, we probably could find the root cause but
that requires more information from your side.

As it stands it is unlikely that the bug is in a7xpg but in some other
package. Please try to reproduce this issue on another computer with
different hardware and also try to confirm whether this issue exists in
a more recent release of Debian like Debian Jessie or better Sid. It
might be totally possible that a system upgrade will solve all your
problems.

Markus

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=714399#8



signature.asc
Description: OpenPGP digital signature

Bug#714399: a7xpg: spaceship drifts to upper left corner of screen making gameplay impossible

[Peter De Wachter]

Hello Jason,

Even though you don't have a joystick, can you run jstest-gtk (from
the package with the same name) anway? I suspect that some device
driver in your system is masquerading as a joystick (perhaps a driver
for an accelerometer chip or something like that).

Can you also send the contents of /proc/bus/input/devices?

Regards,
Peter

On Tue, Dec 22, 2015 at 9:36 PM, Jason Quinn  wrote:
> Your sentence that says "when you can't reproduce such an apparently
> obvious issue" that makes it sound as if I'm doing something wrong.
> It's clear you intend to say that you cannot reproduce the issue but
> your phrasing could be improved.
>
> I do not have a joystick. The keyboard is attached to a laptop. I have
> not tried the game recently on another computer but if I get the
> chance I will. As I wrote before, I believe I have already seen this
> issue on multiple machines (likely on another Dell laptop at minimum)
> but it's been a long time since I would have tried and I don't recall
> anything for certain.
>
> As for seeing more people report the bug, this an an obscure game.
> When you start with the small fraction of people running Debian and
> multiply it by the fraction of people who actually install this game
> and then multiply by the fraction of people who experience the bug,
> and then multiply the fraction of people who report bugs (which is
> canonically taken to be about 1 in 100 users) , you are getting down
> to a small number of expected bug reports... perhaps on the order of
> one like just me. While it's interesting that you do not experience
> the bug, I assure you the bug does happen for me; and your message
> almost makes it sound like you dismiss the concept of bugs that depend
> on various external issues or even hardware. It's far from obvious to
> me that we should have seen more confirms in this case and I also note
> the lack of additional "works for me" comments. So please don't
> dismiss my report as if you are sceptical of the problem that *I'm*
> experiencing because just because you don't see it.
>
> Jason
>

Bug#808782: RFS: jpedal4-lgpl [ITP] Java PDF Extraction Decoding Access Library (LGPL4)

[Jerome Benoit]

Package: sponsorship-requests
Severity: normal

Dear Mentors:

I am looking for a sponsor for the packages jpedal4-lgpl, a wide used
Java library that allows one to manipulate PDF material.
The concerned version of jpedal is actually frozen, but it is still
wildly used because of its license.

Thanks,
Jerome

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

Kernel: Linux 3.16.7-ckt11-amd64-mbp62 (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: sysvinit (via /sbin/init)

Bug#808735: Heads up: transition: xserver 1.18

[Emilio Pozuelo Monfort]

On 22/12/15 21:53, Martin-Éric Racine wrote:
> Just a pointer:
> 
> 2015-12-22 22:46 GMT+02:00 Emilio Pozuelo Monfort :
>> I didn't check the drivers that don't build on x86:
>>
>> xserver-xorg-video-freedreno
>> xserver-xorg-video-geode
>> xf86-video-omap
> 
> You have your facts backwards.  Geode ONLY builds on x86. :)

Heh, right. It wasn't available on x86_64 and just assumed those three were ARM*
or whatever. Anyway if you can verify it still builds / works that'd be great.

Thanks,
Emilio

Bug#808223: python-pydot: wrong package version

[Sandro Tosi]

On Thu, Dec 17, 2015 at 12:15 PM, Alexandre Fayolle
 wrote:
> The package python-pydot has version 1.0.28 in debian. However the
> package installed reports as version 1.0.32 (see setup.py in the source
> package). This creates confusion with tools such as pip which don't see

I dont have any trace of that 1.0.32 you mention in the setup.py . the
version reported from the package is 1.0.29 as I suspect that was a
"hack" from upstream the last time they release the package on google
code (see the commented code just after 29). Now it's on github and
looks like this :
https://github.com/erocarrera/pydot/blob/pydot-1.0.28/pydot.py#L22

dont know what to do with this bug though

-- 
Sandro "morph" Tosi
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi
G+: https://plus.google.com/u/0/+SandroTosi

Bug#808781: musescore: Please remove unneeded build depends

[Sune Vuorela]

Source: musescore
Version: 2.0.2+dfsg-2
Severity: important

Dear Maintainer,

The package seems to be build-depending on qtquick1-5-dev, which is soon
going away.
I couldn't find any traces of QtQuick1 inside the application, so it is
likely an oversight from the past. Please remove the build-dep.

If I'm wrong, please speak up and I'll be happy to help.

/Sune

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

Kernel: Linux 4.2.0-1-amd64 (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
Init: systemd (via /run/systemd/system)

Bug#808780: wkhtmltopdf: Unneeded build-dep on qtquick1-5-dev

[Sune Vuorela]

Source: wkhtmltopdf
Version: 0.12.2.4-1
Severity: important

Dear Maintainer,

It looks like there is a unneeded build-dep on qtquick1-5-dev (I can't
find any traces of it in the actual sources). 

QtQuick1 for qt5 is going away soon (superceded quite some time ago by
QtQuick2)

If any help is needed, feel free to speak up.

/Sune


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

Kernel: Linux 4.2.0-1-amd64 (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
Init: systemd (via /run/systemd/system)

Bug#808735: Heads up: transition: xserver 1.18

[Emilio Pozuelo Monfort]

Hi,

We're working on the transition to xserver 1.18, which is already available in
experimental.

For the drivers in main, all build fine except for:

xserver-xorg-input-aiptek
xserver-xorg-video-openchrome

xserver-xorg-video-intel builds fine for the experimental version, so we may
just upload that to unstable when the transition starts.

I didn't check the drivers that don't build on x86:

xserver-xorg-video-freedreno
xserver-xorg-video-geode
xf86-video-omap

Please check those.

As for the non-free drivers, nvidia-* already supports this new version. fglrx
doesn't though, that needs an update.

While we have tested the new xserver, we have limited hardware and haven't
tested most drivers. So please give your driver some testing against the new
xserver.

I'd like to start this transition ASAP. We will binNMU the drivers that can be
rebuilt unless you say you want to do a sourceful upload for some reason. The
packages that don't get support for the new xserver promptly may need to be
removed from testing.

Cheers,
Emilio

Bug#714399: a7xpg: spaceship drifts to upper left corner of screen making gameplay impossible

[Jason Quinn]

Your sentence that says "when you can't reproduce such an apparently
obvious issue" that makes it sound as if I'm doing something wrong.
It's clear you intend to say that you cannot reproduce the issue but
your phrasing could be improved.

I do not have a joystick. The keyboard is attached to a laptop. I have
not tried the game recently on another computer but if I get the
chance I will. As I wrote before, I believe I have already seen this
issue on multiple machines (likely on another Dell laptop at minimum)
but it's been a long time since I would have tried and I don't recall
anything for certain.

As for seeing more people report the bug, this an an obscure game.
When you start with the small fraction of people running Debian and
multiply it by the fraction of people who actually install this game
and then multiply by the fraction of people who experience the bug,
and then multiply the fraction of people who report bugs (which is
canonically taken to be about 1 in 100 users) , you are getting down
to a small number of expected bug reports... perhaps on the order of
one like just me. While it's interesting that you do not experience
the bug, I assure you the bug does happen for me; and your message
almost makes it sound like you dismiss the concept of bugs that depend
on various external issues or even hardware. It's far from obvious to
me that we should have seen more confirms in this case and I also note
the lack of additional "works for me" comments. So please don't
dismiss my report as if you are sceptical of the problem that *I'm*
experiencing because just because you don't see it.

Jason

Bug#665015: python-sleekxmpp: New upstream version

[Jonas Smedegaard]

Quoting W. Martin Borgert (2015-12-22 04:45:04)
> Hi Jonas, hi Geoff,
> 
> I would like to move sleekxmpp into the tender hands of DPMT and
> update it to the latest upstream 1.3.1. This would include
> migration from gpb to git-dpm and from CDBS to dh.
> 
> Would this be OK? TIA!

For my part please do go ahead!

 - Jonas

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

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


signature.asc
Description: signature

Bug#650601: transition: libpng 1.5

[Nobuhiro Iwamatsu]

Hi Tobias, Gianfranco and Emilio.

Thanks for your help!
Sorry, about this transition.

I don't upload libpng16 with providing libpng-dev now. Because Depend of libpng
is very large and effect for system is large too.
I was considering to gradually transition in a way that was proposed by Michael.
I just sent a mail about this. Could you check this mail, and comment?

Best regards,
  Nobuhiro

2015-12-21 2:19 GMT+09:00 Gianfranco Costamagna :
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Hi Emilio,
>
>> It helps if you Cc the necessary addresses...
>
> I didn't cc the necessary addresses on purpose (see below).
>
>> Before starting anything, please coordinate with the right people,
>> prepare a plan (e.g. make libpng16-dev provide libpng-dev, see how
>> many packages would ftbfs), and wait for a transition slot.
>>
>
> and this is the reason, I *do* not want to start the transition, I
> don't want to be part of libpng* maintainers, just offered my help in
> fixing bugs and uploading packages.
>
> Nobuhiro, it is up to you to start the transition. I see many packages
> that needs just a change from libpng12-dev to libpng-dev, and some of
> them are FTBFS but with patches.
>
> a test rebuild should be done, but I hope we will be able to finally
> sort this long and old issue.
>
> cheers,
>
> Gianfranco
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1
>
> iQIcBAEBCAAGBQJWduM/AAoJEPNPCXROn13ZEPoQANG2/jWgX+aOEgvX2rLkNE2F
> 3VLx3nUBdHEEPcbydENfm5E38wqauZn3jzLZQkYV1OPUPBj5FHaGIFbR9AQVEndS
> xhFee6L3EEisvZN27TJmzXWOOz7MpjeFSneAAgVnCgqwtsP199VPT/sXNikhfcoS
> CO2+ji0vzGTN0uVwXlBn6S2TZNOxnHAFACqncYBFpX7w2KkZjh4lfeJSDjX5ZAcP
> 6dWweLtF/pJtVJ50FLwLwSYHBSsVLIynKJPXURalP349QYZrP7WbyzOmBXXgVwZg
> 45NppqrQzYIi/JyOR18l8toman1mfOuECqRIdvcKfnJBjzlcl41g2JLjtkkZSv/u
> VuAuVFM6cpZRJjd6E8L2LB5zRc8fieiyGQ89VFPUSSseJXwzMX4cyjsIQrWSI0RX
> NOZc/YD/0jAkguMNu6C700EcZgKv1miU/ea89jSIJL5HTCf7Qx2Mt4cHFVJdO+WP
> 9ouhyeesPJ8cLph5gYLxjBXXcxQjp2HAgLLobnBl/P1RJiNhyXc902edFXt14RhP
> 4xEh/T24R/QCd1tcb/+mcnDsbDkR+BmnMicb8RFz9If+jwpsJOvgxxoUBuha1Gq8
> /e1niqXzuDw5xDfjhi/bPKg7e8CeGGPVu+at0IjssaqgZpE18miJxlKRxOCqS2LL
> 3JEbjYfqe+XKQ+0gyoi0
> =WSo+
> -END PGP SIGNATURE-



-- 
Nobuhiro Iwamatsu
   iwamatsu at {nigauri.org / debian.org}
   GPG ID: 40AD1FA6

Bug#808502: [Pkg-cairo-dock-devel] Bug#808502: cairo-dock-dbus-plug-in-interface-mono: Please refresh list of architectures for Mono in Unstable

[Nobuhiro Iwamatsu]

Thanks!

Best regards,
  Nobuhiro

2015-12-23 3:46 GMT+09:00 Jo Shields :
> Source: cairo-dock-plug-ins
> Version: 3.4.0-1.3
> Followup-For: Bug #808502
>
> Dear Maintainer,
>
> Apologies, my fix in 3.4.0-1.3 was incomplete. Attached going to DELAYED/5.
>
> -- System Information:
> Debian Release: jessie/sid
>   APT prefers wily-updates
>   APT policy: (500, 'wily-updates'), (500, 'wily-security'), (500, 'wily'), 
> (100, 'wily-backports')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 4.2.0-22-generic (SMP w/12 CPU cores)
> Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
>
> ___
> Pkg-cairo-dock-devel mailing list
> pkg-cairo-dock-de...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-cairo-dock-devel



-- 
Nobuhiro Iwamatsu
   iwamatsu at {nigauri.org / debian.org}
   GPG ID: 40AD1FA6

Bug#353617: [/sid] Add dbconfig- and dbconfig-no-thanks packages

[Paul Gevers]

tag 353617 pending
thanks

Date: Fri Oct 30 14:32:55 2015 +0100
Author: Paul Gevers 
Commit ID: 63d8e37ae0668b96ac5a0204c90e2a4e58bb5aab
Commit URL: 
https://anonscm.debian.org/cgit/collab-maint/dbconfig-common.git;a=commitdiff;h=63d8e37ae0668b96ac5a0204c90e2a4e58bb5aab
Patch URL: 
https://anonscm.debian.org/cgit/collab-maint/dbconfig-common.git;a=commitdiff_plain;h=63d8e37ae0668b96ac5a0204c90e2a4e58bb5aab

Add dbconfig- and dbconfig-no-thanks packages

Closes: #353617
  

Bug#808245: [/sid] Update translations

[Paul Gevers]

tag 808245 pending
tag 808553 pending
tag 808647 pending
tag 808594 pending
tag 808650 pending
thanks

Date: Wed Dec 16 21:33:33 2015 +0100
Author: Paul Gevers 
Commit ID: 1a383df1aca5ee26442afc286dfc860d2847b951
Commit URL: 
https://anonscm.debian.org/cgit/collab-maint/dbconfig-common.git;a=commitdiff;h=1a383df1aca5ee26442afc286dfc860d2847b951
Patch URL: 
https://anonscm.debian.org/cgit/collab-maint/dbconfig-common.git;a=commitdiff_plain;h=1a383df1aca5ee26442afc286dfc860d2847b951

Update translations

Remove e-mail addresses from templates that bounce
Catalan (Thanks Innocent De Marchi)
Dutch (me)
French (Thanks Julien Patriarca)
German (Thanks Helge Kreutzmann)
Italian (Thanks Giuseppe Sacco)
Russian (Thanks Yuri Kozlov)
Turkish (Thanks Atila KOÇ)

Closes: #808245, #808553, #808647, #808594, #808650
  

Bug#807246: [/sid] Improve detection of localhost for PostgreSQL use

[Paul Gevers]

tag 807246 pending
thanks

Date: Tue Dec 8 21:16:51 2015 +0100
Author: Paul Gevers 
Commit ID: 2af8bbdd069c09914b684a559189465a500d0880
Commit URL: 
https://anonscm.debian.org/cgit/collab-maint/dbconfig-common.git;a=commitdiff;h=2af8bbdd069c09914b684a559189465a500d0880
Patch URL: 
https://anonscm.debian.org/cgit/collab-maint/dbconfig-common.git;a=commitdiff_plain;h=2af8bbdd069c09914b684a559189465a500d0880

Improve detection of localhost for PostgreSQL use

Closes: #807246
  

Bug#805455: [/sid] Update d/dbc.templates to improve user experience

[Paul Gevers]

tag 805455 pending
thanks

Date: Mon Dec 7 21:55:59 2015 +0100
Author: Paul Gevers 
Commit ID: 6cd4e7a11812cbb07a882c25b31ee2af9a48f820
Commit URL: 
https://anonscm.debian.org/cgit/collab-maint/dbconfig-common.git;a=commitdiff;h=6cd4e7a11812cbb07a882c25b31ee2af9a48f820
Patch URL: 
https://anonscm.debian.org/cgit/collab-maint/dbconfig-common.git;a=commitdiff_plain;h=6cd4e7a11812cbb07a882c25b31ee2af9a48f820

Update d/dbc.templates to improve user experience

Closes: #805455
  

Bug#650601: transition: libpng 1.5

[Nobuhiro Iwamatsu]

Dear Release Team,

I restart transition of libpng version 1.2(libpng12) to libpng version
1.6 (libpng16).
Sorry about late this work.

I previously had proposed the replacement of libpng12 and libpng16.
But because libpng has a lot of dependent package, there was pointed out that
it is difficult to replacement in a short period of time.

I just like libjpeg, change at the same time or we can install the
package constitutes
libpng12 and libpng16, will propose a gradual transition.
I will proceed in a way that me proposed by Michael.
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=650601#55

Here is the plan:

1. Upload to libpng1.6 to unstable.
2. libpng1.6 migrate to testing.
3. Test packages that depend libpng16 on testing with maintainer.

   1/ if it builds against both libpng12 and libpng16, change the b-depends
to libpng-dev
   2/ if it needs updates for libpng16 and the change is not backwards
   compatible, b-depends on libpng16-dev
   3/ File bugs against packages which already b-depends on
   libpng-dev but will ftbfs against libpng16

Note: I already sent patch to most packages.
  
http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=libpng15-transition;users=lib...@packages.debian.org

4. Finish checking build with libpng12 and libpng16.
5. Remove "Provides: libpng-dev" from libpng12-dev(src: libpng), and
upload to unstable.
6. Add "Provides: libpng-dev" to libpng16-dev (src:libpng1.6), and
upload to unstable.
7. Start binNMU.
8. If we need, NMU.
9. Finish transition.
10. Remove libpng12 from unstable.

How about this plan?

Best regards,
  Nobuhiro

2011-12-01 9:16 GMT+09:00 Nobuhiro Iwamatsu :
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
>
> Hi Release Team,
>
> Libpng maintainers want to update libpng from 1.2 to 1.5.
> libpng of ABI and API has been changed by change of 1.2 to 1.5, so it
> needs a transition from libopng12 to libpng15.
> We tested building of the package depending on libpng12.
> FTBFS by this change is reported and is summarized below.
>   
> http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=libpng15-transition;users=lib...@packages.debian.org
> Almost all packages have not been corrected yet.
>
> And it is necessary to change Build-depends of almost all packages
> into libpng-dev from libpng12-dev.
> The present status is as follows.
>
> So please let me know when you'd like me to upload libpng1.5 to unstable.
>
> Best regards,
>   Nobuhiro
>
> -
>
> 3depict:
> Build OK
> aaphoto:
> FTBFS 636555 (with patch)
> abiword:
> Not check
> ace-of-penguins:
> FTBFS 635741 (with patch)
> achilles:
> Build OK
> acovea:
> Build OK
> afterstep:
> FTBFS 649970
> alevt:
> FTBFS 650483
> alien-arena:
> Build OK
> ambdec:
> Build OK
> amoeba:
> FTBFS 650593
> amsn:
> FTBFS 648133
> amule:
> Build OK
> analog:
> Build OK
> antigrav:
> FTBFS 649793
> arb:
> Not check
> armagetronad:
> FTBFS 649547
> atari800:
> Build OK
> autotrace:
> Not check
> awffull:
> Build OK
> blender:
> Build OK
> blockout2:
> FTBFS 649550 (with patch)
> boswars:
> Build OK
> briquolo:
> FTBFS 649789 (with patch)
> bwbar:
> Build OK
> cairo:
> FTBFS 648141 (with patch)
> camlimages:
> Build OK
> camorama:
> Build OK
> caret:
> Build OK
> cegui-mk2:
> Build OK
> celestia:
> FTBFS 649551 (with patch)
> chimera2:
> FTBFS 635743 (with patch)
> chromium-browser:
> Build OK
> clanlib:
> FTBFS 649552 (with patch)
> cmtk:
> Build OK
> compiz:
> Build OK
> contextfree:
> Build OK
> crystalspace:
> Not check
> csound:
> Build OK
> ctsim:
> Build OK
> cultivation:
> Build OK
> cups:
> Build OK
> darkplaces:
> FTBFS 650594
> darktable:
> Build OK
> dcmtk:
> Build OK
> deng:
> FTBFS 650595
> devil:
> FTBFS 649554 (with patch)
> dia:
> FTBFS 649553 (with patch)
> digikam:
> Build OK
> dillo:
> Build OK
> directfb:
> FTBFS 648138 (with patch)
> dosbox:
> Build OK
> driftnet:
> Build OK
> dvdauthor:
> FTBFS 649971
> dvdisaster:
> FTBFS 649555
> dvipng:
> Build OK
> dx:
> Build OK
> eagle:
> Build OK
> ebumeter:
> Build OK
> elastix:
> Build OK
> emacs23:
> Build OK
> emboss:
> Build OK
> enblend-enfuse:
> Not check
> epm:
> Build OK
> evas:
> FTBFS 649556
> exactimage:
> Build OK
> exrtools:
> FTBFS 650484
> extremetuxracer:
> FTBFS 649557
> exult:
> FTBFS 649549
> fbdesk:
> Not check
> fbi:
> Build OK
> fenix:
> FTBFS 649548
> ffmpegthumbnailer:
> Build 

Bug#808779: disorderfs: not working with --multi-user=yes

[Reiner Herrmann]

Source: disorderfs
Version: 0.4.1-1

Hi Andrew!

I just noticed that disorderfs isn't working when --multi-user=yes is
specified.  Instead of reversing the readdir order or shuffling the
order, it is only returning the files in normal readdir order (i.e.,
what you would also get without disorderfs).

Regards,
 Reiner


signature.asc
Description: Digital signature

Bug#808460: pulseaudio: In case of connection of a microphone to a frontal panel, the interlocutor doesn't hear me. In order that he heard me, it is necessary to come into settings and to select a fro

[Felipe Sateler]

Control: tags -1 upstream

On 20 December 2015 at 07:54, Ildar  wrote:
> Package: pulseaudio
> Version: 5.0-13
> Severity: normal
>
> Initially the microphone generally wasn't defined. Daley I set sudo apt-get
> install pavucontrol then I manually set up the input equipment a frontal
> microphone. The interlocutor hears me. After reset of the PC of setup don't
> remain and I again set up pulseaudio
>
>

Could you please ask this question in the upstream mailing list?
AFAICT, this is because at some point the default mappings have
changed, but this is really a problem of the  upstream software as we
don't modify those mappings.

The upstream mailinglist is pulseaudio-disc...@lists.freedesktop.org.


-- 

Saludos,
Felipe Sateler

Bug#808170: pulseaudio: Since pulseadio 5 speaker output is on headphones channel And randomly resets settings.

[Felipe Sateler]

Control: tags -1 - moreinfo
Control: tags -1 upstream

Hi Mark,

On 16 December 2015 at 19:02, Mark Caglienzi  wrote:
> And these are the logs with pulseaudio 4.0-6+b1
>
> * Boot
> * Launch VLC with a video, audio ok
> * Launch pavucontrol
> * Plug headphones, audio goes through them
> * Unplug headphones, audio goes through speakers.
>
> Everything works with this version of pulseaudio, and upgrading event
> to pulseaudio 5 gives the same behaviour explained in the previous
> message.

Could you please ask this question in the upstream mailing list?
AFAICT, this is because at some point the default mappings have
changed, but this is really a problem of the  upstream software as we
don't modify those mappings.

The upstream mailinglist is pulseaudio-disc...@lists.freedesktop.org.


-- 

Saludos,
Felipe Sateler

Bug#802371: wheezy-pu: package eglibc/2.13-38+deb7u9

[Adam D. Barratt]

Control: tags -1 + pending

On Mon, 2015-12-21 at 10:03 +0100, Aurelien Jarno wrote:
> On 2015-12-20 20:52, Adam D. Barratt wrote:
> > Control: tags -1 + confirmed
> > 
> > On Wed, 2015-12-16 at 00:03 +0100, Aurelien Jarno wrote:
> > > On 2015-10-19 21:07, Aurelien Jarno wrote:
> > [...]
> > > > I would like to update the eglibc package in wheezy to fix the known
> > > > security issues for which there is a patch available. The changes match
> > > > the security bugs opened by the security team, their severity wasn't
> > > > high enough to warrant a DSA.
> > > > 
> > > > You'll find the corresponding diff against the current version in 
> > > > wheezy below.
> > > 
> > > A new security bug has been found in a meantime. Therefore please find
> > > below a new diff.
> > 
> > Apologies for the delay. Please go ahead.
> 
> No worries. I have just uploaded it.

Flagged for acceptance into o-p-u.

Regards,

Adam

Bug#808246: Should almost certainly be unmerged

[Lennart Sorensen]

I just tried building and installing binutils from sid on jessie, and
then building a kernel module for the current kernel on the machine.
Module built with binutils from jessie loads fine, modules built with
binutils from sid has the mcount symbol error.

So I would agree, these two bugs do not appear to be the same even
though they seem to have appeared at the same time (both are triggered
by changes in binutils, but not the same change most likely).

The ppc64le does look like the missing weak symbols are the problem,
and powerpc64 seems to be something else (since the powerpc64 kernel
never had the symbol that ppc64le says it can't find).

-- 
Len Sorensen

Bug#808778: warning: unable to delete old directory '/etc/bash_completion.d/xxdiff': Directory not empty

[Christoph Anton Mitterer]

Package: xxdiff-scripts
Version: 1:4.0+hg453+dfsg-1
Severity: normal


Hi.

Apparently some old config files aren't cleaned up correctly
on upgrade:
Unpacking xxdiff-scripts (1:4.0+hg453+dfsg-1) over (1:4.0+hg437+dfsg-2) ...
dpkg: warning: unable to delete old directory '/etc/bash_completion.d/xxdiff': 
Directory not empty

The dir is however empty:
$ l /etc/bash_completion.d/xxdiff/
total 0
drwxr-xr-x 1 root root   0 Dec 22 19:54 .
drwxr-xr-x 1 root root 644 Dec 16 20:56 ..
$

Could you please clean up the empty dir with one of the upcomming
updates?!

Thanks,
Chris.

Bug#808380: mount: unknown filesystem type 'vfat'

[Sven Joachim]

On 2015-12-21 19:10 -0500, Phillip Susi wrote:

> On 12/21/2015 05:29 PM, Sven Joachim wrote:
>> Wrong, both the old and the new kernel provide their modules in 
>> /lib/modules/3.16.0-4-amd64.  Jacob upgraded the 
>> linux-image-3.16.0-4-amd64 package, he did no install a new
>> package.
>
> No... if the new kernel is 3.16.0-4, then the old one was 3.16.0-3.

Both the original report ("Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU
cores)") and the followup in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=808380#25 show that
Jacob had already running 3.16.0-4.  If he had been using 3.16.0-3, the
problem would not have shown up since modprobe does not try to load
3.16.0-4 modules into a 3.16.0-3 kernel.

> This is the reason why debian adds the extra digit to the version
> number and bumps it each time the kernel is updated.

Debian does not do this, to avoid uncontrolled proliferation of
kernels.  In fact, the 3.16 kernel has been at the 3.16.0-4 ABI for over
a year (the last ABI bump was in November 2014, version 3.16.7-1).

Cheers,
   Sven

Bug#658211: irssi infinite redraw

[Rhonda D'Vine]

Hi there!

 Long time no hear!  Hope you haven't given up hope. :)   According to
upstream your bugreport might have been fixed with 0.8.17-1 which is
available in the pool for most releases (either directly or through
backports).  Can you try to reproduce it with that newer upstream
release, and if so produce a backtrace to look at?

 Thanks, and happy season greetings.
Rhonda


* Grant Bowman  [2012-02-01 03:14:21 CET]:
> Package: irssi
> Version: 0.8.15-2
> 
> Steps:
> 1. Create a 109x40 terminal locally.
> 2. ssh to my Debian squeeze 0.6.2 server.
> 3. Run tmux. Installed version is 1.3-2+squeeze1
> 4. In a tmux screen run irssi.
> 5. Detach from tmux, logout.
> 6. Login several days later and run tmux attach-session.
> 7. irssi seems to continually redraw the screen and will not accept
> commands. It is still running and logging to disk.
> 
> Other info:
> $ uname -a
> Linux  2.6.27 #1 SMP Mon Jun 13 17:16:12 UTC 2011 i686 GNU/Linux
> $ dpkg -s libc6 | grep ^Version
> Version: 2.11.2-10
> 
> 

-- 
Fühlst du dich mutlos, fass endlich Mut, los  |
Fühlst du dich hilflos, geh raus und hilf, los| Wir sind Helden
Fühlst du dich machtlos, geh raus und mach, los   | 23.55: Alles auf Anfang
Fühlst du dich haltlos, such Halt und lass los|

Bug#800286: cgvg: Please migrate a supported debhelper compat level

[Eriberto Mota]

tags 800286 patch
tags 800286 pending
thanks


Hi,

I uploaded a NMU to 10-day/delay queue. Feel free to cancel this
upload if needed.

The debian/changelog is:

 cgvg (1.6.2-2.2) unstable; urgency=medium
 .
   * Non-maintainer upload.
   * Migrated DH level to 9 to avoid a FTBFS. (Closes: #800286)
   * debian/compat: added.
   * debian/control:
  - Added the ${misc:Depends} variable to provide the right install
dependencies.
  - Bumped Standards-Version to 3.9.6.
   * debian/rules: changed the work place from debian/tmp to debian/cgvg.

I attached a debdiff.

Regards,

Eriberto


cgvg.debdiff
Description: Binary data

Bug#808698: [Debian-astro-maintainers] Bug#808698: stellarium: Please move away from qtquick1

[Sune Vuorela]

On Tuesday 22 December 2015 12:57:41 Tomasz Buchert wrote:
> Hi Alexander,
> thank you for fast response.
> @Sune: expect an upload soon!

That was amazingly fast

Thanks

/Sune
-- 
I didn’t stop pretending when I became an adult, it’s just that when I was a 
kid I was pretending that I fit into the rules and structures of this world. 
And now that I’m an adult, I pretend that those rules and structures exist.
   - zefrank

Bug#803887: Luc's answer

[Mehdi Dogguy]

Hello,

On 22/12/2015 14:25, Gabriel Scherer wrote:
> Thanks for the clarifications. I forward to Luc and here is the answer I got.
> 

Thanks for the reply. I've added Luc in CC. My reply is below.

>> As far as I understand the issue, info files are installed by
>> "GNU install-info" aka ginstall-info.
>>
>> From hand experiments on an UBUNTU 14.04, "dropping relevant files
>> into  files under /usr/share/info" is not enough. One should
>> also add an entry for ocaml into  /usr/share/info/dir.
>>

Indeed. Though is is done automatically in the packaging since we've told
the package that those files are info files. So, in order to avoid confusion
and implicit statements. Let's clarify what the package does (automatically):
1) All pointed files are put under /usr/share/info.
2) Each time the content of /usr/share/info changes, the script update-info-dir
   is called (via a trigger).

For your convenience, here is the content of update-info-dir:

https://sources.debian.net/src/texinfo/6.0.0.dfsg.1-3/debian/update-info-dir/

>> This can be done from the command line as
>> # sudo ginstall-info /usr/share/info/ocaml.info.gz /usr/share/info/dir
>>

This is not needed since it has been done by update-info-dir, which calls
install-info, which is ginstall-info (by default). And, indded, one can
check that an entry has been added for OCaml. The issue is that no content
can be read under the "ocaml" node using the "info" command-line utility.
One can read the manual using Emacs's info reader, but not with the standard
"info" program.

>> There is no need to invoke ginstall-info on other info files, as
>> "apt-get install ocaml-doc" apparently does. However, the only
>> consequence seems to be warnings.
>>

Indeed. Since they don't contain any relevant information, processing
them doesn't change the content of /usr/share/info/dir. Though the warnings
are related to real garbage files, that should not be shipped.

>> So the conclusion is (?) avoid spurious warnings during the installation
>> of the package ocaml-doc by applying ginstall-info to the file ocaml.info.gz
>> and to this file only.
>>

As explained above, there is still something missing since all is done as
you've described. I am really surprised it works on your machine using those
files and only the described steps... or maybe we took different files. Can you
please confirm that files contained in the following archive are the good ones?
Or, maybe you're not seeing the issue because you're testing using Emacs?

http://http.debian.net/debian/pool/non-free/o/ocaml-doc/ocaml-doc_4.02.orig.tar.gz

The above archive has been generated using the following script:

https://sources.debian.net/src/ocaml-doc/4.02-1/debian/generate_tarball/

Regards,

-- 
Mehdi

Bug#796686: cman deprecated by upstream

[Andreas Henriksson]

For the record,
As already noted on the on the rgmanager bug (#796688) also this
package, cman, is apparently deprecated by upstream (in favor
of something called corosync). See:
https://fedoraproject.org/wiki/Features/Cluster

Regards,
Andreas Henriksson

Bug#806438: [Pkg-sysvinit-devel] Bug#806438: update-rc.d: Do not fail when initscripts is not installed

[Felipe Sateler]

Hi all,

On 2 December 2015 at 11:51, Michael Biebl  wrote:
> On Fri, 27 Nov 2015 23:59:12 +0100 Petter Reinholdtsen 
> wrote:
>
>> I would like to ensure the package maintainer and all the package users
>> detect incorrect boot script dependencies as early as possible,
>> preferably before the package is uploaded or at least as soon as it is
>> unloaded to unstable.
>
> I think this is a reasonable request, simply so the existing sysv init
> script don't start to bit rot.
>
> That said, the current approach to let it fail during installation only
> tests this to a very limited degree. After all, the package maintainer
> usually only has a very small subset of the Debian archive installed
> (and that's true for most of our users as well)
>
> Wouldn't it be much better, if we had some automated archive wide
> testing for this, say on ci.debian.net, where you could test arbitrary
> package combinations and where it would be simple to run insserv in
> enforcing mode?

This is a good idea.

I think there should be two categories of tests: with as little
packages as possible, and with as many packages as possible. This way
both missing dependencies and conflicts are detected.

For the first case (which is the bigger worry for passing -f), maybe
it is sufficient to run (for each init-providing package) piuparts
with sysvinit installed, as that would trigger missing dependencies.

> Outputting some warnings in big fat letters in -f mode, as Felipe
> suggested, seems like a sensible thing to do. If the package maintainer
> installs the package before uploading (which he should usually do) he
> would be able to catch the error.

Petter, would you be willing to accept such a patch so that we can
start moving forward?


-- 

Saludos,
Felipe Sateler

Bug#736946: g++-mingw-w64-i686: crash in ostream with ios::fixed and large numbers due to Windows snprintf behavior

[Stephen Kitt]

Control: reopen -1
Control: found -1 gcc-mingw-w64/16

On Mon, 21 Dec 2015 16:00:48 +0100, Andrej Kacian  wrote:
> On Wed, 29 Jan 2014 00:35:24 +0100 Stephen Kitt 
> wrote:
> > Thanks for the detailed bug report and patch! I've confirmed the issue
> > occurs on gcc-mingw-w64 4.6.3 and 4.6.4, but it's fixed in the Debian
> > packages of 4.8.2, apparently thanks to a MinGW-w64-provided
> > implementation of vsnprintf which is used instead of the platform version
> > now.  
> 
> This crash can still be reproduced with libstdc++
> coming from g++-mingw-w64-i686 version 5.3.1-3+16+b1 (currently latest
> in Stretch).
> 
> I do not see 5.x.x versions mentioned anywhere here.

Indeed, the bug has re-surfaced, so I'm re-opening it. Thanks for the info!
(Now I need to figure out why...)

Regards,

Stephen


pgphYNxoqpE7S.pgp
Description: OpenPGP digital signature

Bug#808777: gwyddion-plugins: Alternative dependency on virtual package "perl5" which is gone with perl/5.22

[gregor herrmann]

Package: gwyddion-plugins
Version: 2.43-1
Severity: normal
Tags: sid stretch
User: debian-p...@lists.debian.org
Usertags: perl-5.22-transition

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

This package has

Depends: libc6 (>= 2.3.4), gwyddion, python (>= 2.2) | ruby (>= 1.8) | perl5

"perl5" is a virtual package which was provided by perl until 5.20,
and it's gone with 5.22.

Please change it to "perl" (or drop it if the essential perl-base is enough).


Cheers,
gregor


-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQJ8BAEBCgBmBQJWeZ9IXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXREMUUxMzE2RTkzQTc2MEE4MTA0RDg1RkFC
QjNBNjgwMTg2NDlBQTA2AAoJELs6aAGGSaoGO70QAIg1n6rowuqltprWXRA13QYz
DXkpkQHCYsVC/aLIwbbYsw83mIRuk5r1TsZQTw2EW8tdduWJlQbAepzq3CSHf3V9
cFeK+/EMEtx2vhyVkSzJly1X3USXhui8t6thr4MOT2FEH/bZBez3AcIXVYx4xyLi
SZyM5QUOgmjxnmnOFGM8vpTiPMdjTUBudIbB/uqzYL2VsAtxz3XqKbjAJYRPraG+
QurYxE5XpiyBgSFG+f/pImKsKksUVt6AwKwNeunbCwi0QLz8si8UOZhiiTOuYfy2
lHZpOmIrTIscVCp4+h2cq+FchrFwKHYylFKKgqqQZrpU2LX8Ego/8i4V/wmNJM7J
0msS03IgAPFVvo9P4402MvBO87edFCQ2MErUT4my4GKQAp/0H3Jfl3EByprNiCfi
kjiDGuAMXyTSDJ5IGXipHCTcyGdvB6Lf9ZiOurgClGj9iTJ3JZAPZ7UTkv0vbFJf
V0Kik6KJdconFo5oHofotpZOsliujOK6ggEWW5LXjQ4BjHCRMAdFQN8K2MRSY3fe
dhgjWhzbIhHsCKUVXvKNo50Bh3636sicV8IbQL9hNCyUqVah5bl8L5pvsETLD838
uC3aG9nsV1PBaIvxdRIJg4jo+7Zr4n89A1TOYTwIuSbhPAYe/fxddNQxwH4R/pbD
zpuTwCVCBSUQTSTcCmhf
=Ag0P
-END PGP SIGNATURE-

Bug#808776: texlive-pictures: please drop prerex from Recommends to Suggests

[Michael Terry]

Package: texlive-base
Version: 2015.20151116-1
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu xenial ubuntu-patch

Dear Maintainer,

Currently, texlive-pictures Recommends prerex.  Which itself Recommends
vprerex.  When Recommends are installed by default (as they are in Ubuntu),
that's a heavyweight Recommend for something that doesn't seem to fit the
definition of a Recommend ("packages that would be found together with this
one in all but unusual installations").

In Ubuntu, the attached patch to drop prerex to a Suggests is our only delta
with texlive-base.  I'd love to get back in sync.  And I think this change
makes sense for Debian too.

Thanks for considering the patch.


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

Kernel: Linux 4.3.0-2-generic (SMP w/4 CPU cores)
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 tex-common depends on:
ii  dpkg  1.18.3ubuntu1
ii  ucf   3.0031

Versions of packages tex-common suggests:
ii  debhelper  9.20151126ubuntu1

Versions of packages texlive-base is related to:
ii  tex-common6.04
ii  texlive-binaries  2015.20150524.37493-7build4
diff -Nru texlive-base-2015.20151116/debian/control texlive-base-2015.20151116/debian/control
--- texlive-base-2015.20151116/debian/control	2015-11-16 07:32:45.0 -0500
+++ texlive-base-2015.20151116/debian/control	2015-12-22 13:52:40.0 -0500
@@ -385,9 +385,9 @@
 Architecture: all
 Multi-Arch: foreign
 Depends: texlive-base (>= 2015), texlive-latex-recommended (>= 2015), texlive-base (>= 2015), ${misc:Depends}, texlive-binaries (>= 2015.20150524), python
-Recommends: texlive-pictures-doc, tk, prerex, ruby | ruby-interpreter
+Recommends: texlive-pictures-doc, tk, ruby | ruby-interpreter
 Provides: pgf
-Suggests: texlive-latex-extra, libtcltk-ruby, dot2tex
+Suggests: texlive-latex-extra, libtcltk-ruby, dot2tex, prerex
 Breaks: texlive-music (<< 2015.20150625), texlive-base (<< 2015)
 Description: TeX Live: Graphics, pictures, diagrams
  Including TikZ, pict, etc., but MetaPost and PStricks are separate.

Bug#808209: amanda-common: Depends on virtual package "perl5" which will is gone with perl/5.22

[gregor herrmann]

On Mon, 21 Dec 2015 12:03:20 +, Dominic Hargreaves wrote:

> > > The perl 5.22 transition just started (see
> > > https://lists.debian.org/debian-devel-announce/2015/12/msg5.html)
> > > and we seem to have missed that this package depends on the deprecated
> > > virtual package "perl5" like some other packages did.
> > 
> > Looks like the maintainer has a fix ready and is looking for a
> > sponsor:
> > 
> > http://blog.calhariz.com/post/2015/12/20/Preview-of-amanda-3.3.7p1-1
> 
> In terms of an immediate uninstallability, would you be happy to have
> an NMU with just the perl5 fix, until the new package can be reviewed and
> sponsored? I'd be happy to do the former.

Jose, could you please tell us about the status and your plans here?


Cheers,
gregor, this time with an explicit cc 

-- 
 .''`.  Homepage: http://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: Schmetterlinge: Fragelied 1


signature.asc
Description: Digital Signature

Bug#808772: Uploaded golang-github-mitchellh-go-fs

[Alexandre Viau]

Hello,

I have uploaded golang-github-mitchellh-go-fs.

Cheers,

-- 
Alexandre Viau
av...@debian.org



signature.asc
Description: OpenPGP digital signature

Bug#808502: cairo-dock-dbus-plug-in-interface-mono: Please refresh list of architectures for Mono in Unstable

[Jo Shields]

Source: cairo-dock-plug-ins
Version: 3.4.0-1.3
Followup-For: Bug #808502

Dear Maintainer,

Apologies, my fix in 3.4.0-1.3 was incomplete. Attached going to DELAYED/5.

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

Kernel: Linux 4.2.0-22-generic (SMP w/12 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
diff -Nru cairo-dock-plug-ins-3.4.0/debian/changelog cairo-dock-plug-ins-3.4.0/debian/changelog
--- cairo-dock-plug-ins-3.4.0/debian/changelog	2015-12-21 09:51:42.0 +
+++ cairo-dock-plug-ins-3.4.0/debian/changelog	2015-12-22 18:13:54.0 +
@@ -1,3 +1,12 @@
+cairo-dock-plug-ins (3.4.0-1.4) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * The architectures list is in two places? Of course it is. Make the
+rule conditional upon the existence of a file only installed if
+on a Mono platform, so it only needs maintaining in one place.
+
+ -- Jo Shields   Tue, 22 Dec 2015 18:12:32 +
+
 cairo-dock-plug-ins (3.4.0-1.3) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru cairo-dock-plug-ins-3.4.0/debian/rules cairo-dock-plug-ins-3.4.0/debian/rules
--- cairo-dock-plug-ins-3.4.0/debian/rules	2014-10-23 06:26:55.0 +0100
+++ cairo-dock-plug-ins-3.4.0/debian/rules	2015-12-22 18:12:22.0 +
@@ -17,11 +17,8 @@
 include /usr/share/cdbs/1/rules/debhelper.mk
 include /usr/share/cdbs/1/class/cmake.mk
 
-CLI_ARCH=zamd64z zarmelz zi386z zkfreebsd-i386z \
-		 zkfreebsd-amd64z zpowerpcz zs390xz
-
 common-binary-predeb-arch::
-ifneq (,$(findstring z$(DEB_HOST_ARCH)z, $(CLI_ARCH)))
-	dh_clifixperms
-	dh_clideps -d
-endif
+	if [ -e /usr/share/mono/mono-archs.make ] ; then \
+		dh_clifixperms ; \
+		dh_clideps -d ; \
+	fi

Bug#808730: stalin: Insecure use of temporary files

[Rob Browning]

Steve Kemp  writes:

> Package: stalin
> Version: 0.11-5
> Severity: critical
> Tags: security
>
>
> When `stalin` launches it attempts to detect its environment via
> the following code in /usr/lib/stalin/QobiScheme.sc:
>
>
> (system "uname -m >/tmp/QobiScheme.tmp")
> ...
> (system "rm -f /tmp/QobiScheme.tmp"))

Thanks - working on an update.

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

Bug#808548: [Pkg-owncloud-maintainers] Bug#808548: Bug#808548: owncloud-client: Wrong credentials

[john . kirk]

 Quoting Sandro Knauß :


Hey,


I use the default version of Desktop Enviroment - Gnome.
Login and password typed manually many times, there are no mistakes.
Blaucloud uses 8.2.1 (stable) version.


the 8.1 > version is known to dislike clients with version < 1.7, so you
have
to ask Blaucload if they disabled this "feature" manually. I spoke with
the
developer of owncloud and they say, that there are no real technical
reasons ,
to disable older version, they only want you to use more recent version,
because the newer ons are better.

The other thing to test if you can just use the version out of backports.

regards,
sandro


Hi,

I installed the version from backports. Works well. Thank you for your
help!

Best wishes,
John


-

ONLY AT VFEmail! - Use our Metadata Mitigator to keep your email out of the 
NSA's hands!
$24.95 ONETIME Lifetime accounts with Privacy Features!  
15GB disk! No bandwidth quotas!

Commercial and Bulk Mail Options!  

Bug#801739: plasma-workspace: plasmashell crashes after login through display manager

[sharuzzaman]

Package: plasma-workspace
Version: 4:5.4.3-1
Followup-For: Bug #801739

Dear Maintainer,


after logging in with lightdm, plasmashell straight away crash, and is 
generating stack trace

but the bug catcher don't want to send to KDE

I have saved the stack trace and will attach with this report




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

Kernel: Linux 4.2.0-1-586
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 plasma-workspace depends on:
ii  dbus-x111.10.6-1
ii  frameworkintegration5.16.0-1
ii  gdb-minimal [gdb]   7.10-1
ii  kactivities 5.16.0-1
ii  kde-cli-tools   4:5.4.3-1
ii  kded5   5.16.0-1
ii  kinit   5.16.0-1
ii  kio 5.16.0-1
ii  libc6   2.21-4
ii  libcln6 1.3.4-1
ii  libdbusmenu-qt5-2   0.9.3+15.10.20150604-1
ii  libgcc1 1:5.3.1-3
ii  libgps223.15-2
ii  libice6 2:1.0.9-1+b1
ii  libkf5activities5   5.16.0-1
ii  libkf5auth5 5.16.0-1
ii  libkf5baloo55.16.0-1
ii  libkf5bookmarks55.16.0-1
ii  libkf5completion5   5.16.0-1
ii  libkf5configcore5   5.16.0-1
ii  libkf5configgui55.16.0-1
ii  libkf5configwidgets55.16.0-1
ii  libkf5coreaddons5   5.16.0-1
ii  libkf5crash55.16.0-1
ii  libkf5dbusaddons5   5.16.0-1
ii  libkf5declarative5  5.16.0-1
ii  libkf5globalaccel-bin   5.16.0-1
ii  libkf5globalaccel5  5.16.0-1
ii  libkf5guiaddons55.16.0-1
ii  libkf5i18n5 5.16.0-1
ii  libkf5iconthemes5   5.16.0-1
ii  libkf5idletime5 5.16.0-1
ii  libkf5itemviews55.16.0-1
ii  libkf5jobwidgets5   5.16.0-1
ii  libkf5js5   5.16.0-1
ii  libkf5jsembed5  5.16.0-1
ii  libkf5kdelibs4support5  5.16.0-1
ii  libkf5kiocore5  5.16.0-1
ii  libkf5kiofilewidgets5   5.16.0-1
ii  libkf5kiowidgets5   5.16.0-1
ii  libkf5networkmanagerqt6 5.16.0-1
ii  libkf5newstuff5 5.16.0-1
ii  libkf5notifications55.16.0-1
ii  libkf5notifyconfig5 5.16.0-1
ii  libkf5package5  5.16.0-1
ii  libkf5plasma5   5.16.0-1
ii  libkf5plasmaquick5  5.16.0-1
ii  libkf5quickaddons5  5.16.0-1
ii  libkf5runner5   5.16.0-1
ii  libkf5screen6   4:5.4.3-1
ii  libkf5service-bin   5.16.0-1
ii  libkf5service5  5.16.0-1
ii  libkf5solid55.16.0-1
ii  libkf5su5   5.16.0-1
ii  libkf5texteditor5   5.16.0-1
ii  libkf5textwidgets5  5.16.0-1
ii  libkf5wallet-bin5.16.0-1
ii  libkf5wallet5   5.16.0-1
ii  libkf5waylandclient54:5.4.3-1
ii  libkf5waylandserver54:5.4.3-1
ii  libkf5webkit5   5.16.0-1
ii  libkf5widgetsaddons55.16.0-1
ii  libkf5windowsystem5 5.16.0-1
ii  libkf5xmlgui5   5.16.0-1
ii  libkf5xmlrpcclient5 5.16.0-1
ii  libksgrd7   4:5.4.3-1
ii  libkworkspace5-54:5.4.3-1
ii  libpam0g1.1.8-3.1
ii  libphonon4qt5-4 4:4.8.3-2
ii  libplasma-geolocation-interface54:5.4.3-1
ii  libprocesscore7 4:5.4.3-1
ii  libprocessui7   4:5.4.3-1
ii  libqalculate5v5 0.9.7-9.1
ii  libqt5core5a5.5.1+dfsg-8
ii  libqt5dbus5 5.5.1+dfsg-8
ii  libqt5gui5  5.5.1+dfsg-8
ii  libqt5network5  5.5.1+dfsg-8
ii  libqt5qml5  5.5.1-3
ii  libqt5quick55.5.1-3
ii  libqt5script5   5.5.1+dfsg-2
ii  libqt5sql5  5.5.1+dfsg-8
ii  libqt5webkit5   5.5.1+dfsg-2
ii  libqt5widgets5  5.5.1+dfsg-8
ii  libqt5x11extras55.5.1-3
ii  libqt5xml5  5.5.1+dfsg-8
ii  libsm6  2:1.2.2-1+b1
ii  libstdc++6  5.3.1-3
ii  libtaskmanager5   

Bug#808775: ckeditor: Please update to newer version

[Gunnar Wolf]

Package: ckeditor
Version: 4.4.4+dfsg1-3
Severity: normal
Tags: security

Please upgrade ckeditor to a newer release; several new releases have
appeared, some of them fixing security-related issues, particularly
4.4.6 and 4.4.8, but many more fixing lots of other issues.

Latest release, 4.5.6, was released on December 9, 2015; the currently
packaged version was last updated on August 2014.

Given many webapps use ckeditor, it would be much welcome for them to
carry an updated version.

Thanks!

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

Kernel: Linux 4.1.0-1-amd64 (SMP w/4 CPU cores)
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)

Bug#808521: transition: mpich

[Emilio Pozuelo Monfort]

On 22/12/15 12:37, Emilio Pozuelo Monfort wrote:
> Control: tags -1 confirmed
> Control: forwarded -1 https://release.debian.org/transitions/html/mpich.html
> 
> On 20/12/15 16:57, Anton Gladky wrote:
>> Package: release.debian.org
>> Severity: normal
>> User: release.debian@packages.debian.org
>> Usertags: transition
>>
>>
>> Dear release team,
>>
>> it seems my new upload of mpich, which removed old libmpl1 and libopa1
>> libraries requires transition at least on s390x.
>>
>>
>> Ben file:
>>
>> title = "mpich";
>> is_affected = .depends ~ "libmpl1" | .depends ~ "libmpich12" | .depends ~ 
>> "libopa1";
>> is_good = .depends ~ "libmpich12";
>> is_bad = .depends ~ "libmpl1" | .depends ~ "libopa1";
>>
>>
>> Thanks and sorry for uncoordinated transition
> 
> No problem. I've started to schedule the necessary rebuilds.

There are a few failures, mostly because libmpich-dev no longer ships
mpif90.mpich et al.

Cheers,
Emilio

Bug#808771: Uploaded golang-github-mitchellh-go-vnc

[Daniel Stender]

On Tue, 22 Dec 2015 12:31:39 -0500 Alexandre Viau  wrote:
> Hello,
> 
> I have just uploaded golang-github-mitchellh-go-vnc
> 
> Cheers!
> 
> -- 
> Alexandre Viau
> av...@debian.org

That was again very quick. Thank you.

Daniel

-- 
4096R/DF5182C8
46CB 1CA8 9EA3 B743 7676 1DB9 15E0 9AF4 DF51 82C8
LPI certified Linux admin (LPI000329859 64mz6f7kt4)
http://www.danielstender.com/blog/

Bug#808774: RFP: golang-github-masterzen-simplexml -- Go library to generate XML content from a naive DOM

[Daniel Stender]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: pkg-go-maintain...@lists.alioth.debian.org
Control: block 808773 by -1

* Package name: golang-github-masterzen-simplexml
  Version : 0.0~git20140219.0.95ba304-1
  Upstream Author : Brice Figureau
* URL : https://github.com/masterzen/simplexml
* License : Apache-2.0
  Programming Lang: Go
  Description : Go library to generate XML content from a naive DOM

This is a naive and simple Go library to build a XML DOM to be able to produce 
XML content, needed
by github.com/masterzen/winrm.

Thanks,
DS

-- 
4096R/DF5182C8
46CB 1CA8 9EA3 B743 7676 1DB9 15E0 9AF4 DF51 82C8
LPI certified Linux admin (LPI000329859 64mz6f7kt4)
http://www.danielstender.com/blog/

Bug#808773: RFP: golang-github-masterzen-winrm-dev -- Go library for Windows remote command execution

[Daniel Stender]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: pkg-go-maintain...@lists.alioth.debian.org
Control: block 740753 by -1

* Package name: winrm
  Version : 0.0~git20151214.0.54ea5d0-1
  Upstream Author : Brice Figureau
* URL : https://github.com/masterzen/winrm
* License : Apache-2.0
  Programming Lang: Go
  Description : Go library for Windows remote command execution

WinRM Go library. Packer uses WinRM as communicator instead of SSH for working 
in Windows machines
being created (provisioning, running scripts, etc., see 
https://packer.io/docs/templates/communicator.html).
The project also includes a CLI tool.

Thanks,
DS

-- 
4096R/DF5182C8
46CB 1CA8 9EA3 B743 7676 1DB9 15E0 9AF4 DF51 82C8
LPI certified Linux admin (LPI000329859 64mz6f7kt4)
http://www.danielstender.com/blog/

Bug#804914: mirror listing update for ftp.utexas.edu

[Donald Norwood]

Any update?

On Mon, 16 Nov 2015 01:51:42 -0500 Donald Norwood
 wrote:
> Control: tag -1 +moreinfo
>
>
> Hello Oscar,
>
> Your mirror update drops several architectures and keeps only: amd64,
> i386, and sparc, however the
> mirror is offering: amd64, arm64, armel, i386, ia64, kfreebsd, ppc64el,
> and sparc.
>
> Which is correct?
>
> Does the bandwidth of 10Mbps access for external users, 1Gbps access for
> UT users remain?
>
> Best regards,
>
> Donald Norwood
>
> On Thu, 12 Nov 2015 21:19:55 + "ITS Networking and Telecom Services"
>  wrote:
> > Package: mirrors
> > Severity: minor
> >
> > Submission-Type: update
> > Site: ftp.utexas.edu
> > Aliases: mirror.utexas.edu
> > Aliases: rsync.utexas.edu
> > Type: leaf
> > Archive-architecture: amd64 i386 sparc
> > Archive-ftp: /pub/debian/
> > Archive-http: /debian/
> > Archive-rsync: debian/
> > CDImage-ftp: /pub/debian-cd/
> > CDImage-http: /debian-cd/
> > CDImage-rsync: debian-cd/
> > IPv6: no
> > Archive-upstream: ftp.us.debian.org
> > CDImage-upstream: debian.osuosl.org
> > Updates: twice
> > Maintainer: ITS Networking and Telecom Services
> 
> > Country: US United States
> > Location: Austin, TX , United States
> > Sponsor: The University of Texas at Austin http://www.utexas.edu
> >
> >
>
>




signature.asc
Description: OpenPGP digital signature

Bug#806586: Please keep playitslowly in Debian

[Jonas Wagner]

I updated the application to Python3, GTK3 and GStreamer 1.x and released a
new version (1.5):
http://29a.ch/playitslowly/

I tested it on my system and everything seems to work fine - but that's
just my one box of course.

Please let me know if there are any further problems.

Cheers,
Jonas

Bug#808771: Uploaded golang-github-mitchellh-go-vnc

[Alexandre Viau]

Hello,

I have just uploaded golang-github-mitchellh-go-vnc

Cheers!

-- 
Alexandre Viau
av...@debian.org



signature.asc
Description: OpenPGP digital signature

Bug#808772: RFP: golang-github-mitchellh-go-fs -- filesystem library for Go

[Daniel Stender]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: pkg-go-maintain...@lists.alioth.debian.org
Control: block 740753 by -1

* Package name: golang-github-mitchellh-go-fs
  Version : 0.0~git20150611.0.a34c1b9-1
  Upstream Author : Mitchell Hashimoto
* URL : https://github.com/mitchellh/go-fs
* License : Expat
  Programming Lang: Go
  Description : filesystem library for Go


Filesystem library for Go, rudimentary implementing FAT. However, needed to 
build
Packer, it uses this to provide virtual floppy disks to some of the used 
machines,
if needed (common/step_create_floppy.go).

Thanks,
DS

-- 
4096R/DF5182C8
46CB 1CA8 9EA3 B743 7676 1DB9 15E0 9AF4 DF51 82C8
LPI certified Linux admin (LPI000329859 64mz6f7kt4)
http://www.danielstender.com/blog/

Bug#687838: mirror listing update for ftp.caliu.cat

[Donald Norwood]

Hello,

We are auditing the mirrors list.

Could you please clarify:

How often your mirror updates to sync with the main archive.
ipv6 available?
Your mirror carries Debian Backports and Debian CD, should these be
published?


Thank you.


Best regards,

Donald Norwood
-Debian Mirrors Team

On Tue, 18 Sep 2012 22:27:34 +0200 Simon Paillard 
wrote:
> Hi,
>
> On Sun, Sep 16, 2012 at 02:36:01PM +, Jordi Funollet Pujol wrote:
> > Package: mirrors
> > Severity: minor
> >
> > Submission-Type: update
> > Site: ftp.caliu.cat
>
> Thanks for using an up to date version of ftpsync.
>
> > Type: leaf
> > Archive-architecture: amd64 armel i386 kfreebsd-amd64 kfreebsd-i386
mipsel
>
> http://ftp.caliu.cat/debian/dists/unstable/
> You happen to also mirror armhf.
> Either eclude it again, or tell us if you want to make armhf available to
> users.
>
> > Archive-http: /debian/
> > CDImage-http: /debian-cd/
> > IPv6: no
> > Archive-upstream: ftp.de.debian.org
> > CDImage-upstream: debian.advalem.net
> > Updates: once
>
> The archive is updated 4 times a day:
> http://www.debian.org/mirror/ftpmirror#when
>
> Please consider increasing the update frequency.
>
> > Maintainer: Jordi Funollet Pujol 
> > Country: ES Spain
> > Sponsor: Caliu http://caliu.cat
>
> How much bandwidth is available to the mirror ?
>
> Best regards.
>
> --
> Simon Paillard
>
>




signature.asc
Description: OpenPGP digital signature

Bug#808120: [Reproducible-builds] Bug#808120: diffoscope: Should use less memory

[Jérémy Bobbio]

Control: tag -1 + pending

Mike Hommey:
>* What was the outcome of this action?
> 
> A 533KB HTML file that, considering its size, doesn't contain much 
> differences.
> Yet, while processing this, the diffoscope process (not its children readelf,
> objdump or diff processes) sucked more than 4GB of memory. That tells me
> something unexpectedly suboptimal is happening.

Absolutely! The code was building a full list of lines to compare in
memory instead of feeding them to diff as they were produced. The fix
was trivial once the issue was understood. Thanks for the nudge.

-- 
Lunar.''`. 
lu...@debian.org: :Ⓐ  :  # apt-get install anarchism
`. `'` 
  `-   


signature.asc
Description: Digital signature

Bug#714399: a7xpg: spaceship drifts to upper left corner of screen making gameplay impossible

[Markus Koschany]

Am 22.12.2015 um 07:31 schrieb Jason Quinn:
> Don't close. The problem still exists. Just freshly installed it and
> have same exact issue.
> 
> Jason

There is usually no point in keeping a bug report open when you can't
reproduce such an apparently obvious issue and if the game works as
intended. Normally you would see more people reporting this issue too.

You can control the ship with the arrow keys, num keys or a joystick. Do
you have a joystick attached to your computer? Did you try to replace
the keyboard with another one? Did you try to run the game on another
computer?

Markus




signature.asc
Description: OpenPGP digital signature

Bug#808771: RFP: golang-github-mitchellh-go-vnc -- VNC client and server library for Go

[Daniel Stender]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: pkg-go-maintain...@lists.alioth.debian.org
Control: block 740753 by -1

* Package name: golang-github-mitchellh-go-vnc
  Version : 0.0~git20150629.0.723ed98-1
  Upstream Author : Mitchell Hashimoto
* URL : https://github.com/mitchellh/go-vnc
* License : Expat
  Programming Lang: Go
  Description : VNC client and server library for Go

go-vnc is a VNC library for Go, initially supporting VNC clients but with the
goal of eventually implementing a VNC server.

It's another requirement for Packer (a couple more to go).

Thanks,
DS

-- 
4096R/DF5182C8
46CB 1CA8 9EA3 B743 7676 1DB9 15E0 9AF4 DF51 82C8
LPI certified Linux admin (LPI000329859 64mz6f7kt4)
http://www.danielstender.com/blog/

Bug#808770: sddm-greeter segfault

[sharuzzaman]

Package: sddm
Version: 0.12.0-5
Severity: normal

Dear Maintainer,


sddm did not start on boot, or after systemctl restart sddm.service
output in /var/log/messages have line like this:

Dec 23 00:54:24 debian kernel: [ 2163.968109] sddm-greeter[8649]: segfault at 0 
ip   (null) sp bfabf33c error 4 in sddm-greeter[8048000+44000]

this laptop is using radeon driver

do let me know if you would like more information



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

Kernel: Linux 4.2.0-1-586
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 sddm depends on:
ii  adduser   3.113+nmu3
ii  debconf [debconf-2.0] 1.5.58
ii  libc6 2.21-4
ii  libgcc1   1:5.3.1-3
ii  libpam0g  1.1.8-3.1
ii  libqt5core5a  5.5.1+dfsg-8
ii  libqt5dbus5   5.5.1+dfsg-8
ii  libqt5gui55.5.1+dfsg-8
ii  libqt5network55.5.1+dfsg-8
ii  libqt5qml55.5.1-3
ii  libqt5quick5  5.5.1-3
ii  libstdc++65.3.1-3
ii  libsystemd0   228-2+b1
ii  libxcb-xkb1   1.10-3+b1
ii  libxcb1   1.10-3+b1
ii  qml-module-qtquick2   5.5.1-3
ii  sddm-theme-maui [sddm-theme]  0.12.0-5

sddm recommends no packages.

Versions of packages sddm suggests:
pn  libpam-kwallet5  

-- debconf information:
  sddm/daemon_name: /usr/bin/sddm
* shared/default-x-display-manager: sddm

Bug#808768: python-pyhsm: Systemd unit for yhsm-daemon

[Moritz Muehlenhoff]

On Tue, Dec 22, 2015 at 05:10:27PM +0100, Moritz Muehlenhoff wrote:
> Package: python-pyhsm
> Version: 1.0.4l-1
> Severity: wishlist
> 
> Hi,
> attached patch adds systemd support to yhsm-daemon. It's
> functionally equivalent to the sysvinit script with one
> exception: YHSM_DAEMON_ENABLE from /etc/default/yhsm-daemon
> isn't abided; systemd has built-in support to control whether
> a unit is disabled or not and these should be used instead.

I made some additional tests and the unit isn't complete yet,
it misses support for DAEMON_ARGS from the default and for
choosing a different device name. I'll update the patch.

Cheers,
Moritz