Bug#840346: qjoypad: FTBFS: install: cannot create regular file '/usr/bin/qjoypad': Permission denied

[Stephen Kitt]

Control: tag -1 + patch

On Mon, 10 Oct 2016 20:12:05 +0100, Chris Lamb  wrote:
> qjoypad fails to build from source in unstable/amd64:

Thanks for filing this, the following patch fixes the build:

--- debian/rules.orig   2016-10-12 08:50:16.827628161 +0200
+++ debian/rules2016-10-12 08:50:43.104370126 +0200
@@ -20,6 +20,6 @@
rm -f src/*.png
 
 override_dh_auto_install:
-   dh_auto_install --destdir=debian/tmp
+   dh_auto_install --destdir=debian/tmp -- INSTALL_ROOT=$${PWD}/debian/tmp
install -D -m 0644 debian/qjoypad.desktop 
debian/tmp/usr/share/applications/qjoypad.desktop
 

I'm pushing the fix to the git repository; Jordan, do you want to prepare the
upload, or shall I?

Regards,

Stephen


pgpQyRwdsapRm.pgp
Description: OpenPGP digital signature

Bug#836284: Please switch from dbus-x11 to default-dbus-session-bus | dbus-session-bus | dbus-x11

[Mantas Baltix]

Please change dependency to "default-dbus-session-bus | dbus-session-bus |
dbus-x11"dependency in pcmanfm-qt 0.11.1, because
there are no "default-dbus-session-bus | dbus-session-bus" in stable Debian
and Ubuntu releases (dbus-x11 doesn't provide virtual dbus-session-bus
package), so backporters should now manually change dependancies :(

see commit
f13ec53ef13133ab40e5f793d51d4683e29f8039

I've already backported all LX-QT 0.11 packages from Debian Experimental to
Ubuntu 16.04 LTS (Xenial) successfully, see Baltix GNU/Linux distribution
PPA (ppa:baltix/ppa ):

https://launchpad.net/~baltix/+archive/ppa


But pcmanfm-qt 0.11.1 is uninstallable because of dependency to
"default-dbus-session-bus | dbus-session-bus"

-- 
Prekyba kompiuteriais su Linux OS - http://tinklas.eu/prekyba
Naudokite laisvą Linux operacinę sistemą savo kompiuteryje -
http://baltix.akl.lt
Use Baltix GNU/Linux OS !

Bug#840466: Bug#840062: tracker.debian.org and packages.qa.debian.org show different packages

[Raphael Hertzog]

Hi,

On Tue, 11 Oct 2016, Adrian Bunk wrote:
> > > I use the PTS feature of looking up historical source packages quite a
> > > lot, so it would be a shame if it went away with the transition to the
> > > tracker.
> > 
> > Fine. Let's record this as a wishlist then. Patches welcome as usual.
> > 
> > It might even be not too hard to implement. For example by checking the
> > number of associated news before deciding that we want to consider a
> > binary lookup...
> 
> I'm cloning my main point, which is slightly different, into a
> separate bug.
> 
> It should not be too hard to implement a src: syntax that disables the 
> "if no source package is found try to find a binary package with that 
> name" fallback for special cases where an error page is better than
> this fallback.

/pkg/foo is already a "source" lookup so it would be confusing to
introduce a "/pkg/src:foo" lookup. But we can add a query parameter,
like "/pkg/foo?fallback=none" to implement this.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

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

Bug#840489: dislocker: Fails to run dislocker-find due to libdislocker0-dev is required.

[Steven Shiau]

Package: dislocker
Version: 0.6.1-6
Severity: important

Dear Maintainer,

When I run dislocker-find, it shows me the error:
$ sudo dislocker-find
/usr/lib/ruby/2.3.0/rubygems/core_ext/kernel_require.rb:55:in `require': cannot 
load such file -- libdislocker (LoadError)
from /usr/lib/ruby/2.3.0/rubygems/core_ext/kernel_require.rb:55:in 
`require'
from /usr/bin/dislocker-find:26:in `'

Apparently /usr/lib/libdislocker.so is missing. After libdislocker0-dev is 
installed, dislocker-find runs without any problem.
$ dpkg -S /usr/lib/libdislocker.so
libdislocker0-dev: /usr/lib/libdislocker.so

Either libdislocker0-dev has to be the required package for dislocker, like 
libdislocker0.6:
$ apt-cache show dislocker | grep Depends
Depends: libc6 (>= 2.3.6-6~), libdislocker0.6 (>= 0.6.1), libfuse2 (>= 2.6), 
libmbedcrypto0 (>= 2.0), libruby2.3 (>= 2.3.0~preview2), ruby

Or actually /usr/lib/libdislocker.so should be in the package libdislocker0.6.
If you need more info, please let me know.
My 2 cents.
Thanks.

Steven


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

Kernel: Linux 4.7.0-1-686-pae (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages dislocker depends on:
ii  libc62.24-3
ii  libdislocker0.6  0.6.1-6
ii  libfuse2 2.9.7-1
ii  libmbedcrypto0   2.3.0-1
ii  libruby2.3   2.3.1-5+b1
ii  ruby 1:2.3.0+4

dislocker recommends no packages.

dislocker suggests no packages.

-- no debconf information

Bug#840491: ITP: node-jsonstream -- streaming JSON.parse and stringify

[Sruthi Chandran]

Package: wnpp
Severity: wishlist
Owner: Sruthi Chandran 
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name: node-jsonstream
  Version : 1.0.3
  Upstream Author : Dominic Tarr
* URL : http://github.com/dominictarr/JSONStream
* License : Apache-2.0 or Expat
  Programming Lang: JavaScript
  Description : streaming JSON.parse and stringify

Bug#577737: [pinentry-qt4] Re: gpg command won't use agent if the agent is configured to use pinentry-qt4

[Daniel Kahn Gillmor]

Control: tags 577737 + moreinfo unreproducible

On Thu 2014-02-20 16:57:15 -0500, OmegaPhil wrote:

> Package: pinentry-qt4
> Version: 0.8.3-2
>
> I also get this bug - today I finally researched into and set up
> Enigmail and gpg, yet it failed to generate a revocation certificate
> and later send an encrypted/signed mail - bad passphrase or key
> couldnt be found.

i haven't been able to reproduce this reported problem with pinentry-qt4
or its current equivalent pinentry-qt.  Is this still a problem with
0.9.7-6 in debian unstable or 0.9.7-5 in debian testing?  Is there a
straightforward way to reproduce the problem?  Is it an issue with
DBUS_SESSION_BUS_ADDRESS perhaps?

--dkg


signature.asc
Description: PGP signature

Bug#840346: qjoypad: FTBFS: install: cannot create regular file '/usr/bin/qjoypad': Permission denied

[Stephen Kitt]

On Wed, 12 Oct 2016 08:56:04 +0200, Stephen Kitt  wrote:
> On Mon, 10 Oct 2016 20:12:05 +0100, Chris Lamb  wrote:
> > qjoypad fails to build from source in unstable/amd64:  
> 
> Thanks for filing this, the following patch fixes the build:
> 
> --- debian/rules.orig 2016-10-12 08:50:16.827628161 +0200
> +++ debian/rules  2016-10-12 08:50:43.104370126 +0200
> @@ -20,6 +20,6 @@
>   rm -f src/*.png
>  
>  override_dh_auto_install:
> - dh_auto_install --destdir=debian/tmp
> + dh_auto_install --destdir=debian/tmp -- INSTALL_ROOT=$${PWD}/debian/tmp
>   install -D -m 0644 debian/qjoypad.desktop 
> debian/tmp/usr/share/applications/qjoypad.desktop 

That was based on an older incarnation of debian/rules; the correct patch is

--- a/debian/rules
+++ b/debian/rules
@@ -14,4 +14,4 @@ export QMAKE_LFLAGS_DEBUG="$(shell dpkg-buildflags --get 
LDFLAGS)"
dh $@ --sourcedirectory=src

 override_dh_auto_install:
-   dh_auto_install --destdir=debian/tmp
+   dh_auto_install --destdir=debian/tmp -- INSTALL_ROOT=$${PWD}/debian/tmp

Regards,

Stephen


pgpZ16kgto8Jb.pgp
Description: OpenPGP digital signature

Bug#840490: ptpd should run as a daemon as soon as it is installed

[Joachim Wuttke]

Package: ptpd
Version: 2.3.1-debian1-1

Upon fresh installation, ptpd does exactly nothing.
Even the explicit command "/etc/init.d/ptpd start"
is not sufficient to get the daemon started.

This is not what I expected.
I would expect that installation of package ptpd
suffices to get daemon ptpd running in the background.

I would suggest to change /etc/default/ptpd into
something like
--
# /etc/default/ptpd

# Set to "yes" to actually start ptpd automatically
START_DAEMON=yes

# Add command line options for ptpd
PTPD_OPTS="-c /etc/ptpd.conf"
--
and to add a standard /etc/ptpd.conf to the package.

- Joachim Wuttke



smime.p7s
Description: S/MIME Cryptographic Signature

Bug#800032: pinentry-gnome3: Pinentry hangs for ~30s before asking for passphrase when invoked by Enigmail

[Daniel Kahn Gillmor]

Control: tags 800032 + moreinfo unreproducible

Hi Ondřej--

Sorry for taking so long to respond to this.  A few questions below:

On Fri 2015-09-25 12:53:33 -0400, Ondřej Kuzník wrote:

> recent upgrades to either enigmail, gpg or pinentry have started to take
> a long time to ask for the passphrase on sending/decrypting an email.
> Stracing the gpg-agent daemon looks like pinentry is launched, it
> creates a process/thread(?) which doesn't seem to do much, just waits on
> a futex for 15 seconds, then times out and then another similar
> process/thread is cloned doing essentially the same thing. Only then
> after the second timeout does it display the prompt. This happens with
> pinentry-gtk2 as well. I can provide a slightly cleared up strace if
> that would help.
>
> Does not seem to happen with gpg/mutt/others, but given that the process
> that waits for too long is part of pinentry, I report here.
>
> The desktop environment is Fluxbox with gnome-settings-daemon running.

Is this still happening for you?  Do you have dbus installed?  is there
a dbus session running?  Is there a query on the dbus user session for
any particular service?  I've seen reports of timeouts of ~30s before
waiting for some "org.a11y.Bus" service to respond.  Some of those
reports were cleared up with the installation or removal of the
at-spi2-core package, but i haven't been able to reproduce it myself.
Do you have at-spi2-core installed?  if so, what version?

See also:

  https://lists.gnupg.org/pipermail/gnupg-users/2015-November/054736.html

Please let me know if you have answers to any of these questions.

Thanks,

--dkg


signature.asc
Description: PGP signature

Bug#758460: xserver-xorg-video-nouveau: [GeForce 6150 LE] complete system freeze as soon as GDM launches on kernel (>= 3.14)

[Felix Miata]

I installed Stretch with TDM/TDE 14.0.4 Monday night on
00:0d.0 VGA compatible controller: NVIDIA Corporation C61 [GeForce 6150SE 
nForce 430] (rev a2)
without installing xserver-xorg-video-nouveau. Modesetting driver
integral to X server is used. Neither  nouveau.config=NvMSI=0 nor
nouveau.noaccel=1 are required to avoid Xorg corruption (except for
the UI in mozilla.org's Firefox 49.0 built with GTK3). No video sloth
is apparent.
-- 
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/

Bug#840492: sexplib310: no longer builds libsexplib-camlp4-dev

[Emilio Pozuelo Monfort]

Source: sexplib310
Version: 113.33.03-3
Severity: serious

Hi,

Your package no longer builds libsexplib-camlp4-dev, and the
new libsexplib-ocaml-dev doesn't provide it. This would be
fine if it weren't for the number of reverse dependencies
that build-depend on it:

* source package sexplib310 version 113.33.03-3 no longer builds
  binary package(s): libsexplib-camlp4-dev
  on 
amd64,arm64,armel,armhf,i386,kfreebsd-amd64,kfreebsd-i386,mips,mips64el,mipsel,powerpc,ppc64el,s390x
  - suggested command:
dak rm -m "[auto-cruft] NBS (no longer built by sexplib310)" -s unstable -a 
amd64,arm64,armel,armhf,i386,kfreebsd-amd64,kfreebsd-i386,mips,mips64el,mipsel,powerpc,ppc64el,s390x
 -p -R -b libsexplib-camlp4-dev
  - broken Depends:
janest-core: libcore-ocaml-dev [amd64 arm64 armel armhf i386 kfreebsd-amd64 
kfreebsd-i386 powerpc]
  - broken Build-Depends:
custom-printf: libsexplib-camlp4-dev
janest-core: libsexplib-camlp4-dev
janest-core-extended: libsexplib-camlp4-dev
janest-core-kernel: libsexplib-camlp4-dev
ocaml-re2: libsexplib-camlp4-dev
ocaml-textutils: libsexplib-camlp4-dev
otags: libsexplib-camlp4-dev
pa-structural-sexp: libsexplib-camlp4-dev
pa-test: libsexplib-camlp4-dev
typerep: libsexplib-camlp4-dev

Please file bugs against those (or fix them directly if you maintain
them) or make libsexplib-ocaml-dev provide libsexplib-camlp4-dev.

Cheers,
Emilio

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

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

Bug#840452: Package is not binNMU safe

[Vincent Danjean]

Package: gnupg1
Version: 1.4.21-1+b1
Followup-For: Bug #840452

  Hi,

  There is also a problem in gnupg1-l10n (arch: all) that
has currently:
Enhances: gnupg1 (= 1.4.21-1)
while only gnupg1 1.4.21-1+b1 is available.

  This situation leads my system to propose me to remove
gnupg1-l10n:
vdanjean@eyak:~$ LC_ALL=C sudo apt upgrade
Reading package lists... Done
Building dependency tree   
Reading state information... Done
Calculating upgrade... Done
The following package was automatically installed and is no longer required:
  gnupg1-l10n
Use 'sudo apt autoremove' to remove it.
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
vdanjean@eyak:~$ apt-cache policy gnupg1-l10n gnupg1
gnupg1-l10n:
  Installé : 1.4.21-1
  Candidat : 1.4.21-1
 Table de version :
 *** 1.4.21-1 500
500 http://ftp.fr.debian.org/debian testing/main amd64 Packages
500 http://ftp.fr.debian.org/debian unstable/main amd64 Packages
100 /var/lib/dpkg/status
gnupg1:
  Installé : 1.4.21-1+b1
  Candidat : 1.4.21-1+b1
 Table de version :
 *** 1.4.21-1+b1 500
500 http://ftp.fr.debian.org/debian testing/main amd64 Packages
500 http://ftp.fr.debian.org/debian unstable/main amd64 Packages
100 /var/lib/dpkg/status


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

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

Versions of packages gnupg1 depends on:
ii  gpgv  2.1.15-4
ii  libbz2-1.01.0.6-8
ii  libc6 2.24-3
ii  libreadline7  7.0-1
ii  libusb-0.1-4  2:0.1.12-30
ii  zlib1g1:1.2.8.dfsg-2+b1

Versions of packages gnupg1 recommends:
ii  gnupg1-curl1.4.21-1+b1
ii  gnupg1-l10n1.4.21-1
ii  libldap-2.4-2  2.4.42+dfsg-2+b3

Versions of packages gnupg1 suggests:
ii  eog   3.20.5-1
pn  gnupg-doc 
ii  imagemagick   8:6.8.9.9-7.2+b1
ii  libpcsclite1  1.8.18-1
pn  parcimonie

-- no debconf information

Bug#839991: [pkg-gnupg-maint] Bug#839991: gnupg-agent: 'allow-emacs-pinentry' setting in agent conf makes gpg2 respond no secret key

[Kevin Brubeck Unhammer]

Daniel Kahn Gillmor  čálii:

[...]

>> Alrthough we could handle this in gpg-agent, I consider it better to fix
>> this in Pinentry.  The name "allow-emacs-prompt" means to me that Emacs
>> support is optional and thus Pinentry should just return OK.  A new
>> Pinentry version is anyway due.
>
> I've applied Daiki Ueno's proposed patch to debian unstable in pinentry
> 0.9.7-6.  hopefully it will resolve the issue here.  Kevin, can you
> report back whether it resolves things for you?  (there will still be no
> prompts in emacs, but at least access to the pinentry shouldn't
> automatically abort).  I'm closing the issue now because i believe it's
> resolved in 0.9.7-6, but feel free to reopen if you think it is still
> wrong.

That resolves it for me :) I'd love to have Emacs prompts as well of
course, but as someone mentioned, that's a different issue.

Thanks a bunch!


-Kevin



signature.asc
Description: PGP signature

Bug#840493: ITP: node-prelude-ls -- prelude.ls is a functionally oriented utility library.

[Pirate Praveen]

Package: wnpp
Severity: wishlist
Owner: Pirate Praveen 
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name: node-prelude-ls
  Version : 1.1.2
  Upstream Author : George Zahariev 
* URL : http://preludels.com
* License : Expat
  Programming Lang: JavaScript
  Description : prelude.ls is a functionally oriented utility
library. It is powerful and flexible. Almost all of its functions are
curried. It is written in, and is the recommended base library for,
LiveScript.



signature.asc
Description: OpenPGP digital signature

Bug#826636: This bug is NOT fixed in 1.16.0-1

[Mike Gabriel]

Control: reopen -1
Control: found -1 1.16.0-1

On  Di 11 Okt 2016 02:54:33 CEST, Laszlo KERTESZ wrote:


This bug is NOT fixed in 1.16.0-1.
On my 2 computers running Debian Testing/Stretch (one has Intel Skylake
graphics, the other AMD radeon/r600g) this bug actually started to manifest
with 1.16.0-1.


This is weird. I have a two monitor setup with some cheap onboard  
Intel chipset and screen locking works flawlessly.


I will run some more tests, reopening this bug for now...

Mike
--

DAS-NETZWERKTEAM
mike gabriel, herweg 7, 24357 fleckeby
mobile: +49 (1520) 1976 148
landline: +49 (4354) 8390 139

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de



pgptk4ZJo4pWi.pgp
Description: Digitale PGP-Signatur

Bug#840478: ksmserver: autostart service "/usr/bin/conky" finished with exit code 0

[Maximiliano Curia]

Control: reassign -1 plasma-workspace 4:5.8.0-1
Control: severity -1 minor
Control: tag -1 + confirmed
Control: forwarded -1 https://bugs.kde.org/show_bug.cgi?id=370528

¡Hola allan!

El 2016-10-11 a las 17:55 -0400, allan grossman escribió:
Package: kde-baseapps-bin 
Version: 4:16.08.0-1 
Severity: important



  * What led up to the situation?



Upgraded Debian Unstable today.

  * What exactly did you do (or not do) that was effective (or 
ineffective)?


Rebooted machine and started KDE as normal.  conky refused to start and 
.xsession-errors gave the error above.  Starting conky in a terminal window or 
with krunner works, it just won't autostart.



ksmserver: autostart service "/usr/bin/conky" finished with exit code  0


A similar report with some workarounds can be found in:
https://bbs.archlinux.org/viewtopic.php?id=217920

The problem seems to be that conky's stderr is closed when started from the 
autostart in daemonize mode. Redirecting stderr or not daemonizing solves the 
problem.


Please note that using stderr after daemonizing a process is usualy a bad 
practice, and conky should at least check for errors when writting to it before 
bailing out. (Consider a daemon started from a terminal, what happens when the 
user closes the terminal?)



  * What was the outcome of this action?

As mentioned, conky exits.

  * What outcome did you expect instead?

Expected conky to autostart.


*** /home/wizard/.config/autostart/conky.desktop 
[Desktop Entry]
Exec=/usr/bin/conky -d 
Icon=system-run 
Path=



[Desktop Entry]
Exec=/usr/bin/conky -d 
Icon=system-run 
Path= 
Terminal=false 
Type=Application


Your desktop file seems to list two desktop entries, this seems to be wrong.

--
"When explaining a command, or language feature, or hardware widget, first
describe the problem it is designed to solve."
-- David Martin
Saludos /\/\ /\ >< `/


signature.asc
Description: PGP signature

Bug#840494: mono: FTBFS on mipsel: Assertion: should not be reached at mini-mips.c:2229

[Emilio Pozuelo Monfort]

Source: mono
Version: 4.6.1.3+dfsg-4
Severity: serious

Your package failed to build on mipsel:

chmod +x _tmpinst/bin/al
if test -w /«BUILDDIR»/mono-4.6.1.3+dfsg/mcs; then :; else chmod -R +w 
/«BUILDDIR»/mono-4.6.1.3+dfsg/mcs; fi
cd /«BUILDDIR»/mono-4.6.1.3+dfsg/mcs && /usr/bin/make --no-print-directory -s 
NO_DIR_CHECK=1 PROFILES='binary_reference_assemblies net_4_x xbuild_12 
xbuild_14  ' CC='gcc' all-profiles
mkdir -p -- build/deps
build/profiles/basic.make:93: recipe for target 
'build/deps/basic-profile-check.exe' failed
make[7]: *** [build/deps/basic-profile-check.exe] Error 1
*** The compiler 'false' doesn't appear to be usable.
*** Trying the 'monolite' directory.
 long_mul R91 <- R76 R88
* Assertion: should not be reached at mini-mips.c:2229

Stacktrace:

  at  <0x>
  at System.IO.StreamReader.Init 
(System.IO.Stream,System.Text.Encoding,bool,int,bool) <0x00104>
  at System.IO.StreamReader..ctor 
(System.IO.Stream,System.Text.Encoding,bool,int,bool) <0x00100>
  at System.IO.StreamReader..ctor (System.IO.Stream,System.Text.Encoding) 
<0x00044>
  at System.IO.UnexceptionalStreamReader..ctor 
(System.IO.Stream,System.Text.Encoding) <0x00028>
  at (wrapper remoting-invoke-with-check) 
System.IO.UnexceptionalStreamReader..ctor 
(System.IO.Stream,System.Text.Encoding) <0x00070>
  at System.Console.SetupStreams (System.Text.Encoding,System.Text.Encoding) 
<0x002a8>
  at System.Console..cctor () <0x00250>
  at (wrapper runtime-invoke) object.runtime_invoke_void 
(object,intptr,intptr,intptr) <0x0008c>
  at  <0x>
  at Mono.CSharp.Driver.Main (string[]) <0x000a0>
  at (wrapper runtime-invoke) .runtime_invoke_int_object 
(object,intptr,intptr,intptr) <0x0013c>

Native stacktrace:

/«BUILDDIR»/mono-4.6.1.3+dfsg/mono/mini/mono() [0x4c2c68]

Debug info from gdb:


=
Got a SIGABRT while executing native code. This usually indicates
a fatal error in the mono runtime or one of the native libraries 
used by your application.
=

Aborted
build/profiles/basic.make:93: recipe for target 
'build/deps/basic-profile-check.exe' failed

Full logs at
https://buildd.debian.org/status/logs.php?pkg=mono&arch=mipsel

Emilio

Bug#837631: closed by Dylan Aïssi (Bug#837631: fixed in galileo 0.5.1-1)

[Petter Reinholdtsen]

Hi.  I have noticed I made a mistake with the modalias for galileo.  The
hex numbers need to be capitalized to match the modalias string
generated by the kernel.  In other words, it should read

   
  usb:v2687pFB01d*


Also, I have noticed the udev rule is missing the uaccess tag to allow
any console user, not only the one mentioned during installation, to use
the device.  Please add 'TAG+="uaccess"' to the udev rule to get this
working out of the box.

-- 
Happy hacking
Petter Reinholdtsen

Bug#840495: RM: sysprof [powerpc] -- ROM; outdated needs porting

[Andreas Henriksson]

Package: ftp.debian.org
Severity: normal

Please remove the outdated binaries lingering for sysprof
and blocking it from entering testing.
(sysprof has no reverse dependencies in unstable)

Regards,
Andreas Henriksson

Bug#838735: broadcom-sta-dkms: Please announce supported hardware using AppStream

[Petter Reinholdtsen]

Hi.  I was very happy to see you adding AppStream modalias metadata to
the broadcom-sta-dkms package.  But the modalias matching rule seem to
match more than it should.  It matches on my Thinkpad X200 and X230, and
neither have any broadcom hardware included:

  % lspci |grep -i broad
  % isenkram-lookup |grep broadc
  broadcom-sta-dkms
  %

What was the idea behind the pci:v*d*sv*sd*bc02sc80i* matching rule?
Bus class 2, subclass 80 is any network controller according to
https://pci-ids.ucw.cz/read/PD/02 >.  Perhaps you should limit it
to network controllers from broadcom using
'pci:v14e4d*sv*sd*bc02sc80i*'?

-- 
Vennlig hilsen
Petter Reinholdtsen

Bug#840497: ITP: node-assert -- simple assertion library for javascript

[Sruthi Chandran]

Package: wnpp
Severity: wishlist
Owner: Sruthi Chandran 
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name: node-assert
  Version : 1.4.1
  Upstream Author : Joyent, Inc. and other Node contributors
* URL : https://github.com/defunctzombie/commonjs-assert
* License : Expat
  Programming Lang: JavaScript
  Description : simple assertion library for javascript

Bug#840496: amule-daemon fails on startup

[david]

Package: amule-daemon
Version: 1:2.3.2-1+b1
Severity: important

Dear Maintainer,

* What led up to the situation?

  After last package update I can't start amule service

* What was the outcome of this action?

  When I "/etc/init.d/amule-daemon restart", this is what I get:

Failed to start LSB: Daemonized version of aMule..

Thank you very much.

-- 
David

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

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

Versions of packages amule-daemon depends on:
ii  amule-common   1:2.3.2-1
ii  libboost-system1.61.0  1.61.0+dfsg-2.1+b1
ii  libc6  2.24-3
ii  libcrypto++6   5.6.3-8
ii  libgcc11:6.1.1-11
ii  libpng16-161.6.25-1
ii  libreadline7   7.0-1
ii  libstdc++6 6.1.1-11
ii  libupnp6   1:1.6.19+git20160116-1
ii  libwxbase3.0-0v5   3.0.2+dfsg-2
ii  zlib1g 1:1.2.8.dfsg-2+b1

Versions of packages amule-daemon recommends:
ii  amule-utils  1:2.3.2-1+b1
ii  unzip6.0-20

amule-daemon suggests no packages.

-- Configuration Files:
/etc/default/amule-daemon changed:
AMULED_USER="david"
AMULED_HOME="/home/david"


-- no debconf information

Bug#840483: webkit2gtk: Update Vcs-* links

[Alberto Garcia]

Control: tags 840483 pending

On Tue, Oct 11, 2016 at 09:41:05PM -0400, Jeremy Bicha wrote:

> The Vcs- links should be updated. I'm attaching a patch for this, as
> well as 2 patches for building 2.14.1.

Thanks for the patch. The other two things I had already taken care
of, but I'll update the Vcs links.

Berto

Bug#797999: We are now more than one year later and this critical bug is not fixed

[Eric Valette]

On 10/11/2016 04:22 PM, Eric Valette wrote:

On 10/11/2016 04:10 PM, Dominique Dumont wrote:



Could you try that on your side ?

I can do the test but I never open the lid when docked so this will not
be my use case and this means also modifying my xorg.conf.


Once session is initialized with kdm, in system settings-> display and 
monitor, I have DP4 on at 1920x1200 (as reported by xrandr even when 
failing) and DP3 off.


--eric

Bug#840498: Please package new upstream (2.2.1)

[Jonathan McDowell]

Source: daq
Version: 2.0.4-3
Severity: wishlist

There is a new upstream daq version, 2.2.1, which is required to compile
snort++ (snort3) from build 214 onwards. Please consider updating the
version available in Debian to this one.

Thanks,
J.


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

Kernel: Linux 4.7.0-1-amd64 (SMP w/8 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)

Bug#840499: manpages-dev: Inconsistent symbolic error name for EILSEQ in errno(3)

[Igor Liferenko]

Package: manpages-dev
Version: 4.07-1
Severity: normal

Dear Maintainer,

According to bug glibc bug 20687 [1], the text

Illegal byte sequence (POSIX.1, C99)

should be changed to

Invalid or incomplete multibyte or wide character

[1]: https://sourceware.org/bugzilla/show_bug.cgi?id=20687

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

Kernel: Linux 4.7.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 manpages-dev depends on:
ii  manpages  4.07-1

manpages-dev recommends no packages.

Versions of packages manpages-dev suggests:
ii  man-db [man-browser]  2.7.5-1

-- no debconf information

Bug#839259: W: Target Contents-deb-legacy (Contents-{amd64, i386, all}) is configured multiple times in /etc/apt/sources.list

[Martin-Éric Racine]

Package: apt
Version: 1.3.1
Followup-For: Bug #839259

I just noticed this when I upgraded one host from stable. 

Until recently, Contents-{arch} wasn't fetched at all. Now, it is fetched for
every FQDN present in sources.list or in sources.list.d files. The problem is
that the change doesn't take into consideration the fact that an administrator
might have purposely split components from the same repository over many lines
for better readability and there's nothing inherently wrong with doing that.

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

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

Versions of packages apt depends on:
ii  adduser 3.115
ii  debian-archive-keyring  2014.3
ii  gpgv2.1.15-3
ii  init-system-helpers 1.45
ii  libapt-pkg5.0   1.3.1
ii  libc6   2.24-3
ii  libgcc1 1:6.1.1-11
ii  libstdc++6  6.1.1-11

Versions of packages apt recommends:
ii  gnupg   2.1.15-3
ii  gnupg2  2.1.15-3

Versions of packages apt suggests:
pn  apt-doc 
ii  aptitude0.8.3-1+b1
ii  dpkg-dev1.18.10
ii  powermgmt-base  1.31+nmu1
ii  python-apt  1.1.0~beta5

-- no debconf information

Bug#840500: RFS: asciinema/1.3.0-2 [RC]

[gustavo panizzo]

Package: sponsorship-requests
Severity: important


Hello

I'm looking for an sponsor of my updated asciinema package

If closes an RC bug, and various fixes/improvements

Here is the last entry in the changelog

asciinema (1.3.0-2) unstable; urgency=medium

  * Correct the license from MIT to GPL-3+ (Closes: #840134).
  * Relicense the debian directory to GPL-3+
  * Use upstream manpage
  * Run the test suite, as it does not get run by default
  * Store the generated tarball using pristine-tar

 -- gustavo panizzo   Tue, 11 Oct 2016 09:28:07 +0800

git repo can be found at
https://anonscm.debian.org/git/collab-maint/asciinema.git

built package can be downloaded from
https://mentors.debian.net/debian/pool/main/a/asciinema/asciinema_1.3.0-2.dsc

attached the debdiff between 1.3.0-1 and 1.3.0-2


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

Kernel: Linux 4.6.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
diff -Nru asciinema-1.3.0/debian/asciinema.manpages asciinema-1.3.0/debian/asciinema.manpages
--- asciinema-1.3.0/debian/asciinema.manpages	2016-07-29 17:06:45.0 +0800
+++ asciinema-1.3.0/debian/asciinema.manpages	2016-10-11 09:23:16.0 +0800
@@ -1 +1 @@
-debian/asciinema.1
+man/asciinema.1
diff -Nru asciinema-1.3.0/debian/changelog asciinema-1.3.0/debian/changelog
--- asciinema-1.3.0/debian/changelog	2016-07-29 18:37:47.0 +0800
+++ asciinema-1.3.0/debian/changelog	2016-10-11 09:28:07.0 +0800
@@ -1,3 +1,13 @@
+asciinema (1.3.0-2) unstable; urgency=medium
+
+  * Correct the license from MIT to GPL-3+ (Closes: #840134).
+  * Relicense the debian directory to GPL-3+
+  * Use upstream manpage
+  * Run the test suite, as it does not get run by default
+  * Store the generated tarball using pristine-tar
+
+ -- gustavo panizzo   Tue, 11 Oct 2016 09:28:07 +0800
+
 asciinema (1.3.0-1) unstable; urgency=medium
 
   * New upstream release
diff -Nru asciinema-1.3.0/debian/control asciinema-1.3.0/debian/control
--- asciinema-1.3.0/debian/control	2016-07-29 23:20:15.0 +0800
+++ asciinema-1.3.0/debian/control	2016-10-11 09:28:07.0 +0800
@@ -2,7 +2,7 @@
 Section: utils
 Priority: optional
 Maintainer: gustavo panizzo 
-Build-Depends: debhelper (>= 9), python3-setuptools, dh-python, python3-all
+Build-Depends: debhelper (>= 9), python3-setuptools, dh-python, python3-all, python3-nose
 Standards-Version: 3.9.8
 Vcs-Browser: https://anonscm.debian.org/cgit/collab-maint/asciinema.git
 Vcs-Git: https://anonscm.debian.org/git/collab-maint/asciinema.git
diff -Nru asciinema-1.3.0/debian/copyright asciinema-1.3.0/debian/copyright
--- asciinema-1.3.0/debian/copyright	2016-07-29 18:11:46.0 +0800
+++ asciinema-1.3.0/debian/copyright	2016-10-11 09:28:07.0 +0800
@@ -3,29 +3,27 @@
 Source: http://asciinema.org
 
 Files: *
-Copyright: (c) 2013-2016, Marcin Kulik
-License: MIT
+Copyright: 2013-2016, Marcin Kulik
+License: GPL-3+
 
 Files: debian/*
-Copyright: (c) 2014-2016, gustavo panizzo 
-License: MIT
+Copyright: 2014-2016, gustavo panizzo 
+License: GPL-3+
 
-License: MIT
- Permission is hereby granted, free of charge, to any person obtaining
- a copy of this software and associated documentation files (the
- "Software"), to deal in the Software without restriction, including
- without limitation the rights to use, copy, modify, merge, publish,
- distribute, sublicense, and/or sell copies of the Software, and to
- permit persons to whom the Software is furnished to do so, subject to
- the following conditions:
+License: GPL-3+
+  This program is free software; you can redistribute it and/or modify
+ it under the terms of the GNU General Public License as published by
+ the Free Software Foundation; either version 3 of the License, or
+ (at your option) any later version.
  .
- The above copyright notice and this permission notice shall be
- included in all copies or substantial portions of the Software.
+ This program is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ GNU General Public License for more details.
  .
- THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
- EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
- MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
- NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE
- LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION
- OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION
- WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
+ You should have received a copy of the GNU General Public License
+ along with this program; if not, write to the Free Software
+ Foundatio

Bug#840501: transition: ipython

[Tobias Hansen]

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

Hi,

we would like to transition to ipython 5. The version currently in
Debian (2.4.1) includes a notebook and a qt console. These components
(at least the notebook functionality) were moved to the separate project
jupyter. Because of this, the old ipython is replaced by a bunch of
packages, which are currently in experimental:

ipython
ipykernel
jupyter_client
jupyter_core
nbconvert
nbformat

Some additional are currently being packaged:

ipywidgets ITP: #838684
jupyter-notebook   ITP: #801366
widgetsnbextension ITP: #838683

There are two categories of ipython reverse dependencies: The ones that
depend only on ipython and/or ipython3, and the ones that also depend on
packages that do not exist anymore in this form in ipython 5,
ipython(3)-notebook and ipython(3)-qtconsole.

Below is a list of all these reverse dependencies. With the exception of
yade, I was able to build all the ones that have a reverse dependency
only on ipython(3) successfully against ipython 5.1.0-1.

It is clear that apart from yade, the dependencies on
ipython(3)-notebook and/or ipython(3)-qtconsole need special attention.
I would start by filing bugs against these packages to see what needs to
be done. They are:

glueviz, lmfit-py, plotly, sardana, vistrails, yade

The maintainer of lmfit-py and sardana already promised to take care of
these packages:
http://lists.alioth.debian.org/pipermail/debian-science-sagemath/Week-of-Mon-20161010/000231.html

Would you say I should also file bugs against all the other affected
packages?

Here's the list of reverse dependencies, originating from dak:

# Build-Depend only on ipython / ipython3:

ipdb builds with ipython 5.1.0-1
matplotlib   builds with ipython 5.1.0-1
nova builds with ipython 5.1.0-1
patsybuilds with ipython 5.1.0-1
pysurfer builds with ipython 5.1.0-1
python-cyclerbuilds with ipython 5.1.0-1
python-geopandas builds with ipython 5.1.0-1
python-skbio builds with ipython 5.1.0-1
sfepybuilds with ipython 5.1.0-1
yade FTBFS with ipython 5.1.0-1


# Build-Depend on ipython(3)-notebook or ipython(3)-qtconsole:

glueviz: ipython (>= 2.3.0)
 ipython3 (>= 2.3.0)
 ipython3-qtconsole (>= 2.3.0)
lmfit-py: ipython-notebook
  ipython3-notebook
plotly: ipython-notebook (>= 2.3.0)
ipython3-notebook (>= 2.3.0)


# Depend only on ipython / ipython3:

accerciser: accerciser
androguard: androguard
connectomeviewer: connectomeviewer
ipdb: python-ipdb
  python3-ipdb
plaso: plaso
pytango: python-pytango
 python3-pytango
python-pypump: pypump-shell
python-skbio: python-skbio
  python3-skbio
rabbitvcs: rabbitvcs-core
sfepy: python-sfepy
woo: python-woo
 python3-woo
yade: yade


# Depend on ipython(3)-notebook or ipython(3)-qtconsole:

glueviz: glueviz: ipython3
  ipython3-qtconsole
sardana: python-sardana: ipython
 ipython-qtconsole
vistrails: vistrails: ipython-qtconsole


Ben file:

title = "ipython";
is_affected = .depends ~ "ipython" | .depends ~ "ipython3" | .depends ~
"ipython-notebook" | .depends ~ "ipython3-notebook" | .depends ~ "ipython-
qtconsole" | .depends ~ "ipython3-qtconsole" | .depends ~ "ipython" |
.depends
~ "ipython3";
is_good = .depends ~ "ipython" | .depends ~ "ipython3";
is_bad = .depends ~ "ipython-notebook" | .depends ~ "ipython3-notebook" |
.depends ~ "ipython-qtconsole" | .depends ~ "ipython3-qtconsole";

Best,
Tobias

Bug#839605: network-manager: wireless stuck on "link is not ready"

[loris]

Package: network-manager
Version: 1.4.2-1
Followup-For: Bug #839605

Dear Maintainer,
on stretch release with linux kernel 4.6.xxx my wi-fi was ok. After a 
dist-upgrading my usb wi-fi device
(Linksys wireless-g model WUSB54GC) is not able to link with my modem (tp-link 
w8960n).

dmesg info:

[ 6862.136025] usb 5-1: new high-speed USB device number 19 using ehci-pci
[ 6862.454125] usb 5-1: New USB device found, idVendor=13b1, idProduct=0020
[ 6862.454131] usb 5-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 6862.454134] usb 5-1: Product: Compact Wireless-G USB Adapter
[ 6862.454137] usb 5-1: Manufacturer: Cisco-Linksys
[ 6862.568050] usb 5-1: reset high-speed USB device number 19 using ehci-pci
[ 6863.030123] ieee80211 phy11: rt2x00_set_chip: Info - Chipset detected - rt: 
2573, rf: 0002, rev: 000a
[ 6863.030891] ieee80211 phy11: Selected rate control algorithm 'minstrel_ht'
[ 6863.118760] rt73usb 5-1:1.0 wlx001a703874e9: renamed from wlan0
[ 6863.150061] IPv6: ADDRCONF(NETDEV_UP): wlx001a703874e9: link is not ready
[ 6863.150189] ieee80211 phy11: rt2x00lib_request_firmware: Info - Loading 
firmware file 'rt73.bin'
[ 6863.150233] rt73usb 5-1:1.0: firmware: direct-loading firmware rt73.bin
[ 6863.150241] ieee80211 phy11: rt2x00lib_request_firmware: Info - Firmware 
detected - version: 1.7
[ 6863.242063] IPv6: ADDRCONF(NETDEV_UP): wlx001a703874e9: link is not ready
[ 6863.419106] IPv6: ADDRCONF(NETDEV_UP): wlx001a703874e9: link is not ready
[ 6863.466906] IPv6: ADDRCONF(NETDEV_UP): wlx001a703874e9: link is not ready

iwconfig:

lono wireless extensions.

wlx001a703874e9  IEEE 802.11  ESSID:off/any  
  Mode:Managed  Access Point: Not-Associated   Tx-Power=20 dBm   
  Retry short limit:7   RTS thr:off   Fragment thr:off
  Encryption key:off
  Power Management:on
  
enp11s4   no wireless extensions.
  
Regards
Loris


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

Kernel: Linux 4.7.0-1-686-pae (SM w/2 CPU cores)
Locale: LANG=it_IT.utf8, LC_CTYPE=it_IT.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages network-manager depends on:
ii  adduser3.115
ii  dbus   1.10.10-1
ii  init-system-helpers1.45
ii  libaudit1  1:2.6.7-1
ii  libbluetooth3  5.36-1+b3
ii  libc6  2.24-3
ii  libglib2.0-0   2.50.0-2
ii  libgnutls303.5.4-2
ii  libgudev-1.0-0 230-3
ii  libmm-glib01.6.2-1
ii  libndp01.6-1
ii  libnewt0.520.52.18-3
ii  libnl-3-2003.2.27-1
ii  libnm0 1.4.2-1
ii  libpam-systemd 231-9
ii  libpolkit-agent-1-00.105-16
ii  libpolkit-gobject-1-0  0.105-16
ii  libreadline6   6.3-9
ii  libselinux12.5-3
ii  libsoup2.4-1   2.56.0-1
ii  libsystemd0231-9
ii  libteamdctl0   1.26-1
ii  libuuid1   2.28.2-1
ii  lsb-base   9.20160629
ii  policykit-10.105-16
ii  udev   231-9
ii  wpasupplicant  2.5-2+v2.4-3

Versions of packages network-manager recommends:
ii  crda 3.13-1+b1
ii  dnsmasq-base 2.76-4
ii  iptables 1.6.0-3
ii  iputils-arping   3:20150815-2
ii  isc-dhcp-client  4.3.5~b1-1
ii  modemmanager 1.6.2-1
ii  ppp  2.4.7-1+3

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

-- no debconf information

Bug#797999: more debug info

[Eric Valette]

On 10/12/2016 10:57 AM, Eric Valette wrote:

On 10/11/2016 04:22 PM, Eric Valette wrote:

On 10/11/2016 04:10 PM, Dominique Dumont wrote:



Could you try that on your side ?

I can do the test but I never open the lid when docked so this will not
be my use case and this means also modifying my xorg.conf.


Once session is initialized with kdm, in system settings-> display and
monitor, I have DP4 on at 1920x1200 (as reported by xrandr even when
failing) and DP3 off.


I tried to let the lid open with my actual xorg.conf and rebooted, both 
screen go black. I can still switch to laptop lid in text mode using 
ctrl-alt-f1. I loged to my accound, killed sddm service and did a 
startx, and the kde session shows up correctly on the external monitor 
and laptop screen goes black.


Could you try to use nvidia-settings to disable your laptop screen, via 
the X Server Display Configuration menu and use save X configuration 
file (in /tmp/xorg.conf) back up you actual /etx/X11/xorg.conf if you 
have one and then replace your working dual screen conf by the 
/tmp/xorg.conf


NB : actually the xorg.conf file generated is not perfect it misses the 
config for the second monitor, and still use the laptop screen 
identifier in the Screen section while adding the external monitor config



dpkg -s nvidia-settings-legacy-340xx
Package: nvidia-settings-legacy-340xx
Status: install ok installed
Priority: optional
Section: contrib/x11
Installed-Size: 1861
Maintainer: Debian NVIDIA Maintainers 


Architecture: amd64
Version: 340.93-1
Depends: pkg-config, nvidia-legacy-340xx-alternative, libc6 (>= 2.14), 
libgdk-pixbuf2.0-0 (>= 2.22.0), libglib2.0-0 (>= 2.12.0), libgtk2.0-0 
(>= 2.8.0), libjansson4 (>= 2.3), libpango-1.0-0 (>= 1.14.0), libx11-6 
(>= 2:1.4.99.1), libxext6, libxxf86vm1

Pre-Depends: nvidia-installer-cleanup
Recommends: libgl1-nvidia-legacy-340xx-glx
Breaks: nvidia-alternative (<< 313.30-2), 
nvidia-alternative-legacy-173xx (<< 173.14.37), 
nvidia-alternative-legacy-96xx (<< 96.43.23-4)
Description: tool for configuring the NVIDIA graphics driver (340xx 
legacy version)

 The nvidia-settings utility is a tool for configuring the NVIDIA
 Linux graphics driver.  It operates by communicating with the NVIDIA
 X driver, querying and updating state as appropriate.  This
 communication is done with the NV-CONTROL X extension.
 .
 Values such as brightness and gamma, XVideo attributes, temperature,
 and OpenGL settings can be queried and configured via nvidia-settings.
Homepage: ftp://download.nvidia.com/XFree86/nvidia-settings/

Bug#840503: flowblade: Please package flowblade 1.8

[Kai Weber]

Package: flowblade
Version: 1.6-2
Severity: wishlist

A new version 1.8 of Flowblade has been released September 19, 2016.
Please package this new promising version of my favorite video editor.

Thanks, Kai

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

Kernel: Linux 4.7.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 flowblade depends on:
ii  frei0r-plugins1.4-3+b2
ii  gir1.2-gdkpixbuf-2.0  2.36.0-1
ii  gir1.2-glib-2.0   1.50.0-1
ii  gir1.2-gtk-3.03.22.1-1
ii  gir1.2-pango-1.0  1.40.3-2
ii  gmic  1.6.8-3+b3
ii  librsvg2-common   2.40.16-1
ii  python-cairo  1.8.8-2.1
ii  python-dbus   1.2.4-1
ii  python-gi 3.22.0-1
ii  python-gi-cairo   3.22.0-1
ii  python-mlt6.2.0-1+b1
ii  python-numpy  1:1.11.2-1
ii  python-pil3.3.1-1
pn  python:any
ii  swh-plugins   0.4.16+git20160602~repack1-2

flowblade recommends no packages.

flowblade suggests no packages.

-- no debconf information

Bug#840502: RFS: shadowsocks-libev/2.4.8+ds-1~bpo8+1 -- lightweight and secure socks5 proxy

[Roger Shimizu]

package: sponsorship-requests
severity: normal
X-Debbugs-Cc: rogershim...@gmail.com, max.c...@gmail.com, 073p...@gmail.com

Dear mentors,

I am looking for a sponsor for my package "shadowsocks-libev" for
jessie-backports.

 * Package name: shadowsocks-libev
   Version : 2.4.8+ds-1~bpo8+1
   Upstream Author : Max Lv 
 * URL : https://www.shadowsocks.org
 * License : GPL-3+
   Section : net

It builds those binary packages:

 libshadowsocks-dev - lightweight and secure socks5 proxy (development files)
 libshadowsocks1 - lightweight and secure socks5 proxy (shared library)
 shadowsocks-libev - lightweight and secure socks5 proxy

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

  https://mentors.debian.net/package/shadowsocks-libev

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

  dget -x 
https://mentors.debian.net/debian/pool/main/s/shadowsocks-libev/shadowsocks-libev_2.4.8+ds-1~bpo8+1.dsc

or you can use git-buildpackage to build:
  gbp clone --pristine-tar
https://anonscm.debian.org/git/collab-maint/shadowsocks-libev.git
  git checkout jessie-backports_2.4.8+ds-1
  DIST=jessie-backports git-pbuilder create # Skip this if you already
have pbuilder environment
  gbp buildpackage --git-ignore-branch --git-pristine-tar
--git-pbuilder --git-dist=jessie-backports

I pushed my changes to git repo:
  
https://anonscm.debian.org/cgit/collab-maint/shadowsocks-libev.git/log/?h=jessie-backports_2.4.8+ds-1

Thank you!

Cheers,
-- 
Roger Shimizu, GMT +9 Tokyo
PGP/GPG: 4096R/6C6ACD6417B3ACB1

Bug#782435: #782435: O: pacpl -- multi-purpose audio converter/ripper/tagger script

[Maxime Chatelle]

On Tue, 11 Oct 2016 17:41:24 -0400
Matteo Cypriani  wrote:

> Hi Maxime,
> 
> I'm looking into maybe adopting pacpl. I see in the Git repository that you 
> had prepared a release for 4.0.5-8 fixing a couple of bugs, back in 2014; is 
> there a particular reason why you never uploaded it? The package still builds 
> fine and lintian doesn't report anything too bad.
> 

Hi, Matteo,

I'm happy to see someone can take over this package :)

I didn't upladed it because upstream has done a full rewrite for the
5.0.0 version. So my bug fixes was useless :/


-- 
xakz

Bug#840504: dbus: installation from chroot/systemd-nspawn fails

[linus . luessing]

Package: dbus
Version: 1.8.20-0+deb8u1
Severity: normal

Dear Maintainer,

I'm currently trying to install dbus in a freshly debootstrapped
directory with the following command:

$ systemd-nspawn --bind /usr/bin/qemu-arm-static -D "./" /bin/bash -c "export 
DEBIAN_FRONTEND=noninteractive; apt-get install -y task-desktop"

Unfortunately this fails with the following message:

~
[...]
Setting up libsmbclient:amd64 (2:4.4.5+dfsg-3+b1) ...
Setting up network-manager (1.4.2-1+b1) ...
invoke-rc.d: could not determine current runlevel
Reloading system message bus config...Failed to open connection to "system" 
message bus: Failed to connect to socket /var/run/dbus/system_bus_socket: No 
such file or directory
invoke-rc.d: initscript dbus, action "force-reload" failed.
invoke-rc.d: could not determine current runlevel
Processing triggers for libc-bin (2.24-3) ...
[...]
~

Moreover, dpkg is left in a broken state:
"E: dpkg was interrupted, you must manually run 'dpkg --configure -a' to 
correct the problem."

Which is only fixable with this command in a fully booted
system as otherwise the same dbus reload issue happens
again.

Would it be possible to just skip the reload part if
it wasn't possible to determine the current runlevel?

Regards, Linus


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

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

Versions of packages dbus depends on:
ii  adduser  3.113+nmu3
ii  libaudit11:2.4-1+b1
ii  libc62.19-18+deb8u6
ii  libcap-ng0   0.7.4-2
ii  libdbus-1-3  1.8.20-0+deb8u1
ii  libexpat12.1.0-6+deb8u3
ii  libselinux1  2.3-2
ii  libsystemd0  215-17+deb8u5
ii  lsb-base 4.1+Debian13+nmu1

dbus recommends no packages.

Versions of packages dbus suggests:
pn  dbus-x11  

Versions of packages dbus is related to:
pn  dbus-x11  
ii  systemd   215-17+deb8u5
ii  systemd-sysv  215-17+deb8u5

-- no debconf information

Bug#840505: ITP: node-samsam -- Value identification and comparison functions

[Sruthi Chandran]

Package: wnpp
Severity: wishlist
Owner: Sruthi Chandran 
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name: node-samsam
  Version : 1.2.1
  Upstream Author : Christian Johansen
* URL : http://docs.busterjs.org/en/latest/modules/samsam/
* License : BSD-3-Clause
  Programming Lang: JavaScript
  Description : Value identification and comparison functions

Bug#840507: zeroc-icee: Remove obsolte zeroc-icee package

[Jose]

Source: zeroc-icee
Severity: normal

Dear Maintainer,

This version of zeroc-icee included is obsolete and not
longer supported by upstream, all Ice developers must
use zeroc-ice that provides the latest stable version of
Ice and is supported by upstream.

zeroc-icee-translators must be also removed and that was
just used by zeroc-icee and is part of the obsolete IceE
upstream package.


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

Kernel: Linux 4.3.0-1-amd64 (SMP w/2 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#840506: r-base-core: adequate reports obsolete conffile for r-base-core

[shirish शिरीष]

Package: r-base-core
Version: 3.3.1-1+b2
Severity: normal
User: debian...@lists.debian.org
Usertags: obsolete-conffile adequate

Dear Maintainer,
Adequate reported obsolete conffiles. See -

[$] adequate r-base-core

r-base-core: obsolete-conffile /etc/bash_completion.d/R

As pabs (Paul Wise) has shared in #815563 the proper thing to do would be to -

use the dpkg-maintscript-helper support provided by dh_installdeb
to remove these obsolete conffiles on upgrade.

https://www.debian.org/doc/debian-policy/ch-files.html#s-config-files
http://manpages.debian.org/man/1/dh_installdeb

I ran the same command as he did -

┌─[shirish@debian] - [~] - [422]
└─[$] pkg=r-base-core ; adequate $pkg ; dpkg-query -W
-f='${Conffiles}\n' $pkg | grep obsolete

r-base-core: obsolete-conffile /etc/bash_completion.d/R
 /etc/bash_completion.d/R 086c63e5f408e1954ad23bee981e0dc6 obsolete

Look forward to getting this fixed soonish.

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

Kernel: Linux 4.7.0-1-amd64 (SMP w/2 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 r-base-core depends on:
ii  ca-certificates20160104
ii  libatlas3-base [liblapack.so.3]3.10.3-1
ii  libblas3 [libblas.so.3]3.6.1-2
ii  libbz2-1.0 1.0.6-8
ii  libc6  2.24-3
ii  libcairo2  1.14.6-1+b1
ii  libcurl3   7.50.1-1
ii  libgfortran3   6.1.1-11
ii  libglib2.0-0   2.50.0-2
ii  libgomp1   6.1.1-11
ii  libice62:1.0.9-1+b1
ii  libicu57   57.1-4
ii  libjpeg62-turbo1:1.5.0-1
ii  liblapack3 [liblapack.so.3]3.6.1-2
ii  liblzma5   5.1.1alpha+20120614-2.1
ii  libopenblas-base [liblapack.so.3]  0.2.19-1
ii  libpango-1.0-0 1.40.3-2
ii  libpangocairo-1.0-01.40.3-2
ii  libpaper-utils 1.1.24+nmu4
ii  libpcre3   2:8.39-2
ii  libpng16-161.6.25-1
ii  libquadmath0   6.1.1-11
ii  libreadline7   7.0-1
ii  libsm6 2:1.2.2-1+b1
ii  libtcl8.6  8.6.6+dfsg-1
ii  libtiff5   4.0.6-2
ii  libtk8.6   8.6.6-1
ii  libx11-6   2:1.6.3-1
ii  libxext6   2:1.3.3-1
ii  libxss11:1.2.2-1
ii  libxt6 1:1.1.5-1
ii  ucf3.0036
ii  unzip  6.0-20
ii  xdg-utils  1.1.1-1
ii  zip3.0-11
ii  zlib1g 1:1.2.8.dfsg-2+b1

Versions of packages r-base-core recommends:
ii  r-base-dev 3.3.1-1
ii  r-doc-html 3.3.1-1
ii  r-recommended  3.3.1-1

Versions of packages r-base-core suggests:
pn  ess 
ii  r-base-html 3.3.1-1
pn  r-doc-info | r-doc-pdf  
pn  r-mathlib   

-- no debconf information


-- 
  Regards,
  Shirish Agarwal  शिरीष अग्रवाल
  My quotes in this email licensed under CC 3.0
http://creativecommons.org/licenses/by-nc/3.0/
http://flossexperiences.wordpress.com
EB80 462B 08E1 A0DE A73A  2C2F 9F3D C7A4 E1C4 D2D8

Bug#840508: ITP: node-lolex -- Fake JavaScript timers

[Sruthi Chandran]

Package: wnpp
Severity: wishlist
Owner: Sruthi Chandran 
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name: node-lolex
  Version : 1.5.1
  Upstream Author : Christian Johansen
* URL : http://github.com/sinonjs/lolex
* License : BSD-3-Clause
  Programming Lang: JavaScript
  Description : Fake JavaScript timers

Bug#840382: samba (2:4.4.6+dfsg-2) still crashes with libtevent0-0.31

[Rene Hogendoorn]

samba (2:4.4.6+dfsg-2) still crashes with libtevent0-31; only downgrading to 
libtevent0-0.28 solves the crashes.
Regards,

Rene

Bug#840509: ITP: python-gimmik -- generator of matrix multiplication kernels

[Ghislain Antony Vaillant]

Package: wnpp
Severity: wishlist
Owner: Ghislain Antony Vaillant 

* Package name: python-gimmik
  Version : 2.1
  Upstream Author : Freddie Witherden 
* URL : https://github.com/vincentlab/GiMMiK
* License : BSD
  Programming Lang: Python
  Description : generator of matrix multiplication kernels

Long-Description:
 GiMMiK is a Python based kernel generator for matrix multiplication kernels
 for various accelerator platforms. For small operator matrices the generated
 kernels are capable of outperfoming the state-of-the-art general matrix
 multiplication routines such as cuBLAS GEMM or clBLAS GEMM.

This package is a required dependency for pyfr (>= 1.5). It will be
co-maintained by the Debian Science Team.

Bug#840510: geoip-generator-asn: broken ASN due to csv misparsing

[Yuriy M. Kaminskiy]

Package: geoip-bin
Version: 1.6.2-4
Severity: normal
Tags: patch

Dear Maintainer,

I noticed that some ASN looks mangled (first and last character cut off,
e.g. `geopiplookup 163.172.217.0|tail -1` -> 'GeoIP ASNum Edition: 
S1287' [it should've been 'GeoIP ASNum Edition: AS12876'])

and discovered that geoip-generator-asn misparses unquoted CSV fields.

This bug also affects geoip-database-extra in jessie-backports (and 
likely jessie too).


Patch attached (note: I only made minimal effort to make things work, 
this "CSV parser" is still incomplete and fails to handle full CSV syntax).


P.S. ASN/v6 change in patch is completely untested (it seems produces
mangled database [as before]).

-- System Information:
Debian Release: 8.6
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable'), (100, 
'proposed-updates')

Architecture: i386 (x86_64)
Foreign Architectures: amd64

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

Versions of packages geoip-bin depends on:
ii  libc6   2.19-18+deb8u6
ii  libgcc1 1:4.9.2-10
ii  libgeoip1   1.6.2-4
ii  libstdc++6  4.9.2-10

geoip-bin recommends no packages.

geoip-bin suggests no packages.

-- no debconf information

--- geoip_1.6.7-2~bpo8+1/debian/src/geoip-asn-csv-to-dat.cpp.orig	2016-10-12 12:17:11.0 +0300
+++ geoip_1.6.7-2~bpo8+1/debian/src/geoip-asn-csv-to-dat.cpp	2016-10-12 12:28:38.0 +0300
@@ -480,7 +480,10 @@
 			fields.push_back(buf.substr(0,fs));
 			buf.erase(0,fs + 1);
 		}
+		if (buf[0] == '"' || buf[0] == '\'')
 		fields.push_back(buf.substr(1, buf.length() - 2));
+		else
+			fields.push_back(buf);
 	}
 
 	void
@@ -489,13 +492,16 @@
 		std::vector & fields)
 	{
 		std::string buf(line);
-		std::string delim = ", ";
+		std::string delim = ",";
 		std::size_t fs;
 		for(int i = 0; i<3;++i) {
 			fs = buf.rfind(delim);
 			fields.push_back(buf.substr(fs+2, buf.length()));
 			buf.erase(fs,buf.length());
 		}
+		if (buf[0] == '"' || buf[0] == '\'')
+			fields.push_back(buf.substr(1, buf.length() - 2));
+		else
 		fields.push_back(buf.substr(0, buf.length()));
 	}
 

Bug#840511: RFS: nfft/3.3.2~rc3-1

[Ghislain Antony Vaillant]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

* Package name: nfft
  Version : 3.3.2~rc3-1
  Upstream Author : Prof. Dr. Daniel Potts 
* URL : http://www-user.tu-chemnitz.de/~potts/nfft/
* License : GPL-2+ 
  Section : science

 It builds those binary packages:

  libnfft3-2 - library for computing non-uniform Fourier transforms
  libnfft3-dev - development files for the NFFT library
  libnfft3-doc - documentation for the NFFT library
  libnfft3-double2 - library for computing non-uniform Fourier transforms 
(double prec
  libnfft3-long2 - library for computing non-uniform Fourier transforms 
(long-double
  libnfft3-single2 - library for computing non-uniform Fourier transforms 
(single prec

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/n/nfft/nfft_3.3.2~rc3-1.dsc

Successful test builds on debomatic:

  
http://debomatic-amd64.debian.net/distribution#unstable/nfft/3.3.2~rc3-1/buildlog

Changes since the last upload:

  * New upstream version 3.3.2~rc3
  * Upgrade to debhelper 10.
- Bump compat version to 10.
- Bump versioned depends on debhelper to 10.
- Drop explicit dependency on dh-autoreconf.
- Drop explicit usage of `--with autoreconf` from dh command.
- Drop explicit usage of `--parallel` from dh command.
  * Refactor and simplify content of rules file.
- Use dh_listpackages to detect long-double precision availability.
- Drop superfluous query for DEB_HOST_ARCH_CPU.
- Drop explicit setup of precision suffix, use upstream's defaults.
- Simplify all targets by looping through the available precisions.
  * Enable testing for long-double precision for all architectures.

Regards,
Ghislain Vaillant

Bug#839715: systemtray: Network Widget in Systemtray: 2 Buttons without any description or Icon

[Maximiliano Curia]

Control: tag -1 + confirmed
Control: forwarded -1 https://bugs.kde.org/show_bug.cgi?id=370541

¡Hola Maria!

El 2016-10-04 a las 11:15 +0200, Maria escribió:
Package: plasma-workspace 
Version: 4:5.7.4-1 
Severity: normal 
File: systemtray


as shown in the attached screenshot the two buttons of the network widget in 
the systemtray don't have any description or icon. 
They would be helpful. :)


I could reproduce this issue when switching to the oxygen icon theme, and 
forwarded this report upstream. You might want to switch to the breeze icon 
theme, which is the current default.


(only one icon was missing for me when using 5.8.0)

Happy hacking,
--
"It is practically impossible to teach good programming to students that have
had a prior exposure to BASIC: as potential programmers they are mentally
mutilated beyond hope of regeneration."
-- Edsger W. Dijkstra
Saludos /\/\ /\ >< `/


signature.asc
Description: PGP signature

Bug#840512: libsingular4: please provide debugging symbols for singular

[Ximin Luo]

Package: libsingular4
Version: 4.0.3-p3+ds-1
Severity: normal

Dear Maintainer,

Please provide debugging symbols for singular.

In fact I can't figure out why this is not already happening - debhelper
should in theory generate them automatically.

X

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

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

Versions of packages libsingular4 depends on:
ii  libc6   2.24-3
ii  libflint-2.5.2  2.5.2-9
ii  libgcc1 1:6.1.1-11
ii  libgmp102:6.1.1+dfsg-1
ii  libmpfr43.1.5-1
ii  libntl279.9.1-3
ii  libreadline77.0-1
ii  libstdc++6  6.1.1-11
ii  libtinfo5   6.0+20160917-1

libsingular4 recommends no packages.

libsingular4 suggests no packages.

-- no debconf information

Bug#840506: r-base-core: adequate reports obsolete conffile for r-base-core

[Dirk Eddelbuettel]

Hi there,

On 12 October 2016 at 15:45, shirish शिरीष wrote:
| Package: r-base-core
| Version: 3.3.1-1+b2
| Severity: normal
| User: debian...@lists.debian.org
| Usertags: obsolete-conffile adequate
| 
| Dear Maintainer,
| Adequate reported obsolete conffiles. See -

That is testing upgrades from old packages, correct?  debian/rules went
through some iterations to ensure it installs in the correct place:

# add tab completion by Deepayan
#install -m 0644 debian/R.bash_completion   \
#   debian/$(corepackage)/etc/bash_completion.d/R
# edd 24 Mar 2014  now installs via dh_bash-completion
dh_bash-completion  
# edd 12 Jan 2016  new location
#install -m 0644 debian/R.bash-completion \
#   debian/$(corepackage)/usr/share/bash-completion/completions/R

 
| [$] adequate r-base-core
| 
| r-base-core: obsolete-conffile /etc/bash_completion.d/R
| 
| As pabs (Paul Wise) has shared in #815563 the proper thing to do would be to -
| 
| use the dpkg-maintscript-helper support provided by dh_installdeb
| to remove these obsolete conffiles on upgrade.
| 
| https://www.debian.org/doc/debian-policy/ch-files.html#s-config-files
| http://manpages.debian.org/man/1/dh_installdeb

Well yes, link 1 explains what a config file it, link 2 is currently dead.

But the pointer to dpkg-maintscript-helper is appreciated. Did not know that
one. 

| I ran the same command as he did -
| 
| ┌─[shirish@debian] - [~] - [422]
| └─[$] pkg=r-base-core ; adequate $pkg ; dpkg-query -W
| -f='${Conffiles}\n' $pkg | grep obsolete
| 
| r-base-core: obsolete-conffile /etc/bash_completion.d/R
|  /etc/bash_completion.d/R 086c63e5f408e1954ad23bee981e0dc6 obsolete
| 
| Look forward to getting this fixed soonish.

Do you have a recommended code snippet for a upgrade of these files?
Else I grep on my system for some other postinst files and do likewise for
dpkg-maintscript-helper. 

R 3.3.2 is coming soon so we'll have rc releases to work this out.

Dirk
 
| -- System Information:
| Debian Release: stretch/sid
|   APT prefers testing
|   APT policy: (600, 'testing'), (500, 'unstable-debug'), (500,
| 'testing-debug'), (1, 'experimental-debug'), (1, 'experimental'), (1,
| 'unstable')
| Architecture: amd64 (x86_64)
| 
| Kernel: Linux 4.7.0-1-amd64 (SMP w/2 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 r-base-core depends on:
| ii  ca-certificates20160104
| ii  libatlas3-base [liblapack.so.3]3.10.3-1
| ii  libblas3 [libblas.so.3]3.6.1-2
| ii  libbz2-1.0 1.0.6-8
| ii  libc6  2.24-3
| ii  libcairo2  1.14.6-1+b1
| ii  libcurl3   7.50.1-1
| ii  libgfortran3   6.1.1-11
| ii  libglib2.0-0   2.50.0-2
| ii  libgomp1   6.1.1-11
| ii  libice62:1.0.9-1+b1
| ii  libicu57   57.1-4
| ii  libjpeg62-turbo1:1.5.0-1
| ii  liblapack3 [liblapack.so.3]3.6.1-2
| ii  liblzma5   5.1.1alpha+20120614-2.1
| ii  libopenblas-base [liblapack.so.3]  0.2.19-1
| ii  libpango-1.0-0 1.40.3-2
| ii  libpangocairo-1.0-01.40.3-2
| ii  libpaper-utils 1.1.24+nmu4
| ii  libpcre3   2:8.39-2
| ii  libpng16-161.6.25-1
| ii  libquadmath0   6.1.1-11
| ii  libreadline7   7.0-1
| ii  libsm6 2:1.2.2-1+b1
| ii  libtcl8.6  8.6.6+dfsg-1
| ii  libtiff5   4.0.6-2
| ii  libtk8.6   8.6.6-1
| ii  libx11-6   2:1.6.3-1
| ii  libxext6   2:1.3.3-1
| ii  libxss11:1.2.2-1
| ii  libxt6 1:1.1.5-1
| ii  ucf3.0036
| ii  unzip  6.0-20
| ii  xdg-utils  1.1.1-1
| ii  zip3.0-11
| ii  zlib1g 1:1.2.8.dfsg-2+b1
| 
| Versions of packages r-base-core recommends:
| ii  r-base-dev 3.3.1-1
| ii  r-doc-html 3.3.1-1
| ii  r-recommended  3.3.1-1
| 
| Versions of packages r-base-core suggests:
| pn  ess 
| ii  r-base-html 3.3.1-1
| pn  r-doc-info | r-doc-pdf  
| pn  r-mathlib   
| 
| -- no debconf information
| 
| 
| -- 
|   Regards,
|   Shirish Agarwal  शिरीष अग्रवाल
|   My quotes in this email licensed under CC 3.0
| http://creativecommons.org/licenses/by-nc/3.0/
| http://flossexperiences.wordpress.com
| EB80 462B 08E1 A0DE A73A  2C2F 9F3D C7A4 E1C4 D2D8

-- 
http://dirk.eddelbuettel.

Bug#840513: mirror submission for mirrors.pidginhost.com

[pidginhost]

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

Submission-Type: new
Site: mirrors.pidginhost.com
Type: leaf
Archive-architecture: amd64 i386 
Archive-ftp: /debian/
Archive-http: /debian/
Archive-rsync: debian/
IPv6: yes
Archive-upstream: ftp.ro.debian.org
Updates: four
Maintainer: pidginhost 
Country: RO Romania
Location: www.pidginhost.com
Sponsor: PidginHost https://www.pidginhost.com

Bug#836352: Scrollbar can't go to the bottom with a theme other than Adwaita

[Mike Gabriel]

Control: severity -1 important

On  Fr 02 Sep 2016 05:15:40 CEST, Raphaël Halimi wrote:


Package: caja
Version: 1.14.2-1
Severity: grave

This bug certainly has the same root cause as #826261, as it has the
same symptoms: it doesn't appear with Adwaita theme, and it only appear
when the window is maximized.

When a scrollbar is displayed, it can't be dragged all the way to the
bottom, making the last files of the folder "hidden". You can still
blindly select them by moving around with the arrow keys, but you can't
select them with the mouse or right-click on them, which severely
diminishes the number of possible actions on those files.

This, in addition to #826261, makes caja quite unusable for daily use.

Please fix either caja or mate-themes (or marco ? Why does the bug only
appear when the window is maximized ?). I know that someone who uses
unstable should expect breakage from time to time, but this one has been
going on for too long (and, people who maintain Debian packages *have
to* use unstable for various reasons you most probably already know).

Regards,


Dropping severity to important, this bug may be experienced personally  
as grave, but in the Debian distro context, severity "important" is  
more appropriate.


Mike
--

DAS-NETZWERKTEAM
mike gabriel, herweg 7, 24357 fleckeby
mobile: +49 (1520) 1976 148
landline: +49 (4354) 8390 139

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de



pgpQwo6YxKGm8.pgp
Description: Digitale PGP-Signatur

Bug#840514: ITP: node-livescript -- LiveScript is a language which compiles to JavaScript

[Pirate Praveen]

Package: wnpp
Severity: wishlist
Owner: Pirate Praveen 
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name: node-livescript
  Version : 1.5.0
  Upstream Author : George Zahariev 
* URL : http://livescript.net
* License : Expat
  Programming Lang: JavaScript
  Description : LiveScript is a language which compiles to
JavaScript. It has a straightforward mapping to JavaScript and allows
you to write expressive code devoid of repetitive boilerplate. While
LiveScript adds many features to assist in functional style programming,



signature.asc
Description: OpenPGP digital signature

Bug#840382: [Pkg-samba-maint] Bug#840382: samba (2:4.4.6+dfsg-2) still crashes with libtevent0-0.31

[Mathieu Parent]

Hi,



2016-10-12 12:26 GMT+02:00 Rene Hogendoorn :
> samba (2:4.4.6+dfsg-2) still crashes with libtevent0-31; only downgrading to
> libtevent0-0.28 solves the crashes.
> Regards,

Can you provide the backtrace?

Thanks.

-- 
Mathieu

Bug#840515: RFS: open-ath9k-htc-firmware/1.4.0-25-gf6af791-1 ITP #751339

[Paul Fertser]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "open-ath9k-htc-firmware"

* Package name: open-ath9k-htc-firmware
  Version : 1.4.0-25-gf6af791-1
  Upstream Author : QCA
* URL : https://github.com/qca/open-ath9k-htc-firmware
* License : BSD-3-clause
  Section : misc

It builds those binary packages:

  firmware-ath9k-htc - QCA ath9k-htc Firmware
  firmware-ath9k-htc-dbgsym - QCA ath9k-htc Firmware ELF file

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

https://mentors.debian.net/package/open-ath9k-htc-firmware


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

  dget -x 
https://mentors.debian.net/debian/pool/main/o/open-ath9k-htc-firmware/open-ath9k-htc-firmware_1.4.0-25-gf6af791-1.dsc

Regards,
  Oleksij Rempel
  Paul Fertser

Bug#108504: nqc bugs in debian

[Petter Reinholdtsen]

[Ben Pfaff 2007-06-21]:
> I think that it's a udev vs. no-udev issue.  The udev rules I see
> here show that the legousbtower0 device should be created in
> /dev/usb.  If you're not using udev, and you created the device
> by hand, perhaps it's in /dev instead of /dev/usb.

Hi.  I am looking at the udev and appstream setup for nqc, and would like to
ensure these USB towers work as they should.  Can one of you provide the output
from 'lsusb' and udevadm info /dev/bus/usb/XXX/YYY' for the device when such
tower is plugged into a machine.

Btw, are you aware of the newly formed Debian LEGO team?  It is an effort to
improve the situation for LEGO related packages in Debian.  You are most 
welcome to
join the IRC channel and mailing list. :)

See https://wiki.debian.org/LegoDesigners >.

-- 
Happy hacking
Petter Reinholdtsen

Bug#840516: doesn't work with django 1.10

[Daniel Baumann]

Package: graphite-web
Version: 0.9.15+debian-2
Severity: serious

Hi Jonas,

graphite-web doesn't work with django 1.10 anymore, can you please upgrade?

Regards,
Daniel

Bug#840504: Acknowledgement (dbus: installation from chroot/systemd-nspawn fails)

[Linus Lüssing]

Sorry, this message does not seem to have put dpkg in a broken
state, just verified with another, new installation where this
message occures too, but dpkg is absolutely fine with it.

Please close this issue for now and sorry for the noise again.

Bug#839934: PowerPC is back !

[Mathieu Malaterre]

It would be nice to re-generate the d/control from d/control.in for
gdcm 2.6.6 since mono works on powerpc.

Thanks.

Bug#828673: FTBFS under Django 1.10

[Daniel Baumann]

tag 828673 fixed-upstream
thanks

Hi,

the current upstream version (0.4.5) works fine with django 1.10.

Regards,
Daniel

Bug#840517: datapacker: Please remove build dependency on jade

[Neil Roeth]

Package: datapacker
Severity: normal

The datapacker package build depends on the package jade which is
obsolete and will be removed from Debian.  Its replacement is openjade.
Please remove the build dependency on jade.  Datapacker also depends on
docbook-utils which has a dependency on openjade, so openjade does not
need to be added as an explicit build dependency, the jade dependency
can just be removed.

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

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

-- 
Neil Roeth

Bug#839767: ncmpcpp fails to start due to undefined symbol in binary

[Christoph Egger]

Hi!

Nick Black  writes:
> I rebuilt the source package against current libtag, and it works once
> more.

Which is exactly what happened in unstable ~1 day ago as part of the
transition. So this seems to be a totally normal unstable disturbance
and not a bug.

  Christoph

-- 
9FED 5C6C E206 B70A 5857  70CA 9655 22B9 D49A E731
Debian Developer | Lisp Hacker | CaCert Assurer

Bug#840499: manpages-dev: Inconsistent symbolic error name for EILSEQ in errno(3)

[Michael Kerrisk (man-pages)]

tags 840499 fixed-upstream
thanks

On 10/12/2016 11:04 AM, Igor Liferenko wrote:
> Package: manpages-dev
> Version: 4.07-1
> Severity: normal
> 
> Dear Maintainer,
> 
> According to bug glibc bug 20687 [1], the text
> 
> Illegal byte sequence (POSIX.1, C99)
> 
> should be changed to
> 
> Invalid or incomplete multibyte or wide character
> 
> [1]: https://sourceware.org/bugzilla/show_bug.cgi?id=20687

I amended the EILSEQ description to note both the glibc text 
and the POSIX text. Thanks for the report.

Cheers,

Michael

> 
> -- System Information:
> Debian Release: stretch/sid
>   APT prefers testing
>   APT policy: (500, 'testing')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 4.7.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 manpages-dev depends on:
> ii  manpages  4.07-1
> 
> manpages-dev recommends no packages.
> 
> Versions of packages manpages-dev suggests:
> ii  man-db [man-browser]  2.7.5-1
> 
> -- no debconf information
> 
> 


-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/

Bug#840499: manpages-dev: Inconsistent symbolic error name for EILSEQ in errno(3)

[Michael Kerrisk (man-pages)]

tags 840499 fixed-upstream
thanks

On 10/12/2016 11:04 AM, Igor Liferenko wrote:
> Package: manpages-dev
> Version: 4.07-1
> Severity: normal
> 
> Dear Maintainer,
> 
> According to bug glibc bug 20687 [1], the text
> 
> Illegal byte sequence (POSIX.1, C99)
> 
> should be changed to
> 
> Invalid or incomplete multibyte or wide character
> 
> [1]: https://sourceware.org/bugzilla/show_bug.cgi?id=20687

I amended the EILSEQ description to note both the glibc text 
and the POSIX text. Thanks for the report.

Cheers,

Michael

> 
> -- System Information:
> Debian Release: stretch/sid
>   APT prefers testing
>   APT policy: (500, 'testing')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 4.7.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 manpages-dev depends on:
> ii  manpages  4.07-1
> 
> manpages-dev recommends no packages.
> 
> Versions of packages manpages-dev suggests:
> ii  man-db [man-browser]  2.7.5-1
> 
> -- no debconf information
> 
> 


-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/

Bug#840518: ITP: node-formatio -- Human-readable object formatting

[Sruthi Chandran]

Package: wnpp
Severity: wishlist
Owner: Sruthi Chandran 
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name: node-formatio
  Version : 1.2.0
  Upstream Author : Christian Johansen
* URL : http://busterjs.org/docs/formatio/
* License : BSD-3-Clause
  Programming Lang: JavaScript
  Description : Human-readable object formatting

Bug#840500: RFS: asciinema/1.3.0-2 [RC]

[Tobias Frost]

Control: owner -1 !
Thnks

Will take a look ASAP (either today evening or Friday)

--
tobi

> Package: sponsorship-requests
> Severity: important
>
>
> Hello
>
> I'm looking for an sponsor of my updated asciinema package
>
> If closes an RC bug, and various fixes/improvements
>
> Here is the last entry in the changelog
>
> asciinema (1.3.0-2) unstable; urgency=medium
>
>   * Correct the license from MIT to GPL-3+ (Closes: #840134).
>   * Relicense the debian directory to GPL-3+
>   * Use upstream manpage
>   * Run the test suite, as it does not get run by default
>   * Store the generated tarball using pristine-tar
>
>  -- gustavo panizzo   Tue, 11 Oct 2016 09:28:07 +0800
>
> git repo can be found at
> https://anonscm.debian.org/git/collab-maint/asciinema.git
>
> built package can be downloaded from
> https://mentors.debian.net/debian/pool/main/a/asciinema/asciinema_1.3.0-2.dsc
>
> attached the debdiff between 1.3.0-1 and 1.3.0-2
>
>
> -- System Information:
> Debian Release: stretch/sid
>   APT prefers testing
>   APT policy: (900, 'testing'), (300, 'unstable')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 4.6.0-1-amd64 (SMP w/4 CPU cores)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
>

Bug#840519: ITP: pakcs -- The Portland Aachen Kiel Curry System

[Mike Gabriel]

Package: wnpp
Severity: wishlist
Owner: Mike Gabriel 

* Package name: pakcs
  Version : 1.14.1
  Upstream Author : Michael Hanus 
* URL : http://www-ps.informatik.uni-kiel.de/~pakcs/
* License : BSD-3-clause
  Programming Lang: Curry, Prolog
  Description : The Portland Aachen Kiel Curry System

 PAKCS is an implementation of the multi-paradigm declarative language
 Curry jointly developed by the Portland State University, the Aachen
 University of Technology, and the University of Kiel.

 Although this is not a highly optimized implementation but based on a
 high-level compilation of Curry programs into Prolog programs, it is not
 a toy implementation: PAKCS has been used for a variety of applications
 (e.g., graphical programming environments, an object-oriented front-end
 for Curry, partial evaluators, database applications, HTML programming
 with dynamic web pages, prototyping embedded systems).

Bug#840417: pdf2htmlex: FTBFS with new release of fontforge

[Johannes Schauer]

Hi,

On Tue, 11 Oct 2016 17:55:28 +0530 Vasudev Kamath  
wrote:
> pdf2htmlex FTBFS with new version of fontforge (currently in experimental).
> Below is the snippet of log showing the error.
> 
> [...]
> /usr/bin/cc   -I/<>/pdf2htmlex-0.14.6+ds/src -I/usr/include/poppler 
> -I/usr/include/fontforge  -g -O2 
> -fdebug-prefix-map=/<>/pdf2htmlex-0.14.6+ds=. 
> -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
> -D_FORTIFY_SOURCE=2  -Wall   -o CMakeFiles/pdf2htmlEX.dir/src/util/ffw.c.o   
> -c /<>/pdf2htmlex-0.14.6+ds/src/util/ffw.c
> In file included from /usr/include/fontforge/baseviews.h:30:0,
>  from /<>/pdf2htmlex-0.14.6+ds/src/util/ffw.c:17:
> /usr/include/fontforge/ffglib.h:27:18: fatal error: glib.h: No such file or 
> directory
>  #include 
> [...]
> 
> It looks like missing dependency on glib development headers.

indeed but as far as I can see from the log, the file that includes glib.h is
/usr/include/fontforge/ffglib.h, no? Thus, it is not pdf2htmlex that is missing
the dependency but the package containing ffglib.h.

Thank you for your bug report!

cheers, josch


signature.asc
Description: signature

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

[bret curtis]

Hello everyone,

this is a follow-up email because while the bug was closed and OpenMW
compiles (and runs) on armhf, what is rendered to the screen via
OSG-3.4 is everything but pretty. The short term solution is to
disable building OpenMW on armhf and rebuild any builds still online.

I have more below inline...


On Thu, Sep 29, 2016 at 11:36 PM, Alberto Luaces  wrote:
>
> This is a list of facts that I know:
>
> - OSG "as is" does FTBFS on arm platforms.  You can verify that reading
>   the logs for 3.4: armhf (configured for GLES2) succeeds while armel
>   (default configuration) breaks.
>

That is a pity about armel, unfortunately OSG-3.4 with only GLESv2 is
useless to OpenMW, regardless of architecture. To my knowledge, OpenMW
is the only application linking against OSG-3.4 at the moment.

> - The decision of using GLES2 was already made by the Ubuntu team from
>   whom I took the patches that I told you I was going to apply
>   beforehand.  I suppose they choose GLES2 because nowadays it is rare
>   to find new hardware supporting GLES1 but not GLES2, but this is mere
>   speculation.

I do not know the reason, but I find any reason to not use standard GL
dubious regardless of architecture, specifically when it comes to
running Debian and/or Ubuntu on any platform. Not all arm[el|hf] have
the same support but GL is the baseline while GLESv[1|2] are just
subsets. Normally you would want a derivative Debian or Ubuntu to fork
to a specific target GL version.

I think it best to try to resolve the issue so that normal GL and not
ES[1|2] is used for OSG-3.4 on all platforms since Debian is trying to
be consistent across all platforms and architectures.

> - On Debian and for 3.4, which depends on Qt5, the decision of using
>   GLES2 is also taken already for us.  See their dependencies on armhf
>   and armel:
>
> https://sources.debian.net/src/qtbase-opensource-src/5.6.1%2Bdfsg-3/debian/control/#L309
>

This is just plan wrong, as I stated above we should be providing a
standard across the board. Qt5 should be using GL on armel/armhf. If
this can't be the case, then as a workaround, we should disable
building the osgQt plugin. This would allow us to build OSG-3.4 on
armhf and armel with GL instead of GLESv2.

> I do not know what would happen if we build OSG with GLES1 but linking
> to GLES2-enabled Qt5.  Does it have any chances of not breaking at
> run-time?  I am not sure.

I tried working around this with OpenMW by disabling building armhf
version of openmw-cs that makes use of osgQt. The problem is that
GLESv2 render used by OSG-3.4 cannot render OpenMW very well. It
doesn't crash which is surprising, and it renders stuff... just
nothing anyone would want to play. :)

> To me this looks like a packaging problem, because we have to decide
> what dependencies we need from a global point of view, instead of in
> a case-by-case basis.
>

It does indeed. I've tested compiling OSG-3.4 without osgQt without
the armhf patches (no GLES or EGL) and it compiled just fine. I
installed them on my RPi2 and then compiled OpenMW against it. It too
compiled without my little work-around patch. The best part is that
OpenMW runs, as expected in 1080p glory at 15fps! :)

> In my opinion, that tiny patch for OpenMW on Debian looks like a good
> compromise.

Sadly, I tested this and while it does compile and run, it just render
anything useful nor enjoyable.

> Regards,
>
> Alberto

Thanks for your comments, we really appreciate your work! :)  I hope
we can work through this!

My recommendation is if we can't get Qt-[4|5] to commit to using GL
across all platforms, that OSG-3.4 should disable building the osgQt
plugin.

Cheers,
Bret

Bug#833930: gitk: display shot, application usability gone

[Antoni Marcinek]

Hello,

I observe the same problem for about the same time with sid. I tried
purging gitk,tk,tcl and associated libs, as well as libx11-6 with all
dependent packages and reinstalling. None of this allowed to get the
functionality back (contrary to Oleg Pudeyev's case).

I also tried with new user - gitk is still broken. So there is some system
wide problem.

Regards,
Antoni

Bug#839813: mutt depends on libxapian22v5 which is for autoremove on testing today

[Elimar Riesebieter]

* Gregor Zattler  [2016-10-11 23:07 +0200]:

> Hi Elimar,
> * Elimar Riesebieter  [07. Okt. 2016]:
> > * Gregor Zattler  [2016-10-07 00:18 +0200]:
> >> * Elimar Riesebieter  [06. Okt. 2016]:
> > [...]
> >>> What tells
> >>> $ ldd $(which mutt) | grep xapian?
> >> 
> >> libxapian.so.22 => /usr/lib/x86_64-linux-gnu/libxapian.so.22 
> >> (0x7f7f4d90)
> > 
> > On my systems mutt 1.7.0-6 should have been build against
> > libxapian-dev 1.4 which let mutt point to:
> > 
> > libxapian.so.30 => /usr/lib/i386-linux-gnu/sse2/libxapian.so.30 (0xb680e000)
> > libxapian.so.30 => /usr/lib/x86_64-linux-gnu/libxapian.so.30 
> > (0x7f9790569000)
> > 
> > From where did you get the mutt package? Did you compiled it by
> > your self?
> 
> This is mutt-1.70-6 from testing repository but I compiled
> notmuch myself and this was the reason fro the wrong library
> version (don't ask me why.  Since I updated notmuch
> 
> $ ldd $(which mutt) | grep xapian
> libxapian.so.30 =>
> /usr/lib/x86_64-linux-gnu/libxapian.so.30
> (0x7fad41a27000)

So bug closed hereby.

Thanks
Elimar
-- 
  You cannot propel yourself forward by
  patting yourself on the back.


signature.asc
Description: PGP signature

Bug#839767: ncmpcpp fails to start due to undefined symbol in binary

[Christoph Egger]

Control: reopen -1
Control: reassign -1 libtag1v5
Control: found -1 1.11+dfsg.1-0.1

Christoph Egger  writes:
> Which is exactly what happened in unstable ~1 day ago as part of the
> transition. So this seems to be a totally normal unstable disturbance
> and not a bug.

Actually missing symbol seems to indicate libtag missed a soname bump?
(And the problem was hidden by an unrelated binnmu later).

  Christoph

-- 
9FED 5C6C E206 B70A 5857  70CA 9655 22B9 D49A E731
Debian Developer | Lisp Hacker | CaCert Assurer

Bug#839705: manpages-dev: "initial state" in mbstowcs(3) and wcstombs(3)

[Michael Kerrisk (man-pages)]

tags 839705 fixed-upstream
thanks

On 10/04/2016 09:30 AM, Igor Liferenko wrote:
> Package: manpages-dev
> Version: 4.07-1
> Severity: normal
> 
> Dear Maintainer,
> 
> In mbstowcs(3) there is this sentence:
> 
> The conversion starts in the initial state.
> 
> And in wcstombs(3) there are these sentences:
> 
> The conversion starts in the initial state.
> 
> In this case, the conversion ends in the initial state.
> 
> "Initial state" is associated only with mbstate_t, but mbstowcs and wcstombs
>  are stateless (in contrast with mbsrtowcs and wcsrtombs).

Looking at your later reply, you seem to understand that "Initial state" here
is sort of okay. But really, the language could be clearer. I applied the 
patch below. (Still not sure if it's 100% correct, but I believe it's an
improvement.)

Cheers,

Michael

diff --git a/man3/mbstowcs.3 b/man3/mbstowcs.3
index e02f7df..bdd624a 100644
--- a/man3/mbstowcs.3
+++ b/man3/mbstowcs.3
@@ -39,8 +39,9 @@ At most
 .I n
 wide characters are written to
 .IR dest .
-The conversion starts
-in the initial state.
+The sequence of characters in the string
+.I src
+shall begin in the initial shift state.
 The conversion can stop for three reasons:
 .IP 1. 3
 An invalid multibyte sequence has been encountered.
diff --git a/man3/wcstombs.3 b/man3/wcstombs.3
index e5498b3..073cc9b 100644
--- a/man3/wcstombs.3
+++ b/man3/wcstombs.3
@@ -36,8 +36,9 @@ At most
 .I n
 bytes are written to
 .IR dest .
-The conversion
-starts in the initial state.
+The sequence of characters placed in
+.IR dest
+begins in the initial shift state.
 The conversion can stop for three reasons:
 .IP 1. 3
 A wide character has been encountered that can not be represented as a
@@ -53,7 +54,7 @@ is returned, but the shift state at this point is lost.
 .IP 3.
 The wide-character string has been completely converted, including the
 terminating null wide character (L\(aq\\0\(aq).
-In this case, the conversion ends in the initial state.
+In this case, the conversion ends in the initial shift state.
 The number of bytes written to
 .IR dest ,
 excluding the terminating null byte (\(aq\\0\(aq), is returned.

-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/

Bug#840430: glib2.0: segfaults in nemo when opening files from the desktop

[Norbert Preining]

reassign 840430 nitroshare-nemo
retitle 840430 installing nitroshare-nemo makes nemo crash on opening files 
from desktop
thanks

Hi Jason,

after long playing around I found that nitroshare-nemo is the culprit. I first
thought it is nemo-python seeing all the python warnings, but even recompiling
nemo-python did not fix the problem. Then I went through all the nemo 
extensions and there it is ...

Sorry for the noise, reassigned.

Thanks for your time

Norbert

--
PREINING Norbert + TeX Live & Debian Developer + http://www.preining.info
GPG: 0x860CDC13fp: F7D8 A928 26E3 16A1 9FA0  ACF0 6CAC A448 860C DC13

Bug#839705: manpages-dev: "initial state" in mbstowcs(3) and wcstombs(3)

[Michael Kerrisk (man-pages)]

On 10/06/2016 10:13 AM, Igor Liferenko wrote:
> Dear Maintainer,
> 
> According to definitions of mbstowcs and wcstombs (see below), the phrase
> ``The conversion starts in the initial state.''

See my earlier reply.

> may be left in mbstowcs(3) and wcstombs(3), but the phrase
> ``In this case, the conversion ends in the initial state.''
> should be removed from wcstombs(3) (because there is no such sentence
> in corresponding section of mbstowcs(3) and because this sentence
> makes no sense):
> 
> http://code.metager.de/source/xref/gnu/glibc/stdlib/mbstowcs.c
> 
> http://code.metager.de/source/xref/gnu/glibc/stdlib/wcstombs.c

I'm not sure that the sentence makes no sense. I did change "initial state"
to "initial shift state". Still not sure if that's correct though.

> BTW, in mbstowcs(3) the phrase
> 
> including the terminating null wide character ('\0')
> 
> should be changed to
> 
> including the terminating null byte ('\0')

I fixed this. Thanks.

Cheers,

Michael



-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/

Bug#837117: This bug is not found in 1.21-3

[Daniel Silverstone]

notfound 837117 1.21-3

Hi,

I spent some time today checking, and 1.21-3 's source doesn't differ
materially from the SHA presented by the reporter.  I can confirm that
the bug is definitely present in the version in Jessie, but unstable
is clear.

If I have some time, I'll look at what is necessary to fix the Jessie
package, but honestly, once 1.21-3 gets into testing it's probably best
to just request a backport if the reporter still cares.

D.

-- 
Daniel Silverstone http://www.digital-scurf.org/
PGP mail accepted and encouraged.Key Id: 3CCE BABE 206C 3B69

Bug#822825: luasocket segfault

[Steven Price]

See also https://github.com/diegonehab/luasocket/issues/179 where I've
posted some more investigation I performed.

As far as I can tell this is caused by the Debian specific patch
0001-add-LUASOCKET_API-to-timeout_markstart-init-for-lua-.patch. This
is causing the linker to incorrectly match up the call to buffer_init
in luasocket to a different function exported by libtwolame. Dropping
the patch fixes the problem for me. However I presume the patch is
there for a reason ("for lua-sec") but I couldn't find any information
on why it is necessary.

Regards,

- Steve

Bug#840522: plotly: ipython transition: Please help assess the situation

[Tobias Hansen]

Source: plotly
Severity: normal
Control: block 840501 by -1

Hi,

we are planning to transition ipython from version 2.4 to 5 [1]. This
amounts to larger changes: ipython-notebook and ipython-qtconsole were
moved to a separate project, Jupyter. Packages for ipython 5 and several
Jupyter components are available in experimental (see [1]), however
jupyter-notebook and jupyter-qtconsole are not packaged yet.

plotly build-depends on ipython-notebook. Could you please evaluate if
this is a blocker for the transition or if plotly could work
temporarily without a dependency on ipython-notebook?
Furthermore, if the dependency on ipython-notebook is not strictly
necessary, could you please test your package with ipython 5 from
experimental?

Thanks,
Tobias

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

Bug#840524: sardana: ipython transition: Please help assess the situation

[Tobias Hansen]

Source: sardana
Severity: normal
Control: block 840501 by -1

Hi,

we are planning to transition ipython from version 2.4 to 5 [1]. This
amounts to larger changes: ipython-notebook and ipython-qtconsole were
moved to a separate project, Jupyter. Packages for ipython 5 and several
Jupyter components are available in experimental (see [1]), however
jupyter-notebook and jupyter-qtconsole are not packaged yet.

sardana depends on ipython-qtconsole. Could you please evaluate if this
is a blocker for the transition or if sardana could work temporarily
without a dependency on ipython-qtconsole?
Furthermore, if the dependency on ipython-qtconsole is not strictly
necessary, could you please test your package with ipython 5 from
experimental?

Thanks,
Tobias

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

Bug#840525: vistrails: ipython transition: Please help assess the situation

[Tobias Hansen]

Source: vistrails
Severity: normal
Control: block 840501 by -1

Hi,

we are planning to transition ipython from version 2.4 to 5 [1]. This
amounts to larger changes: ipython-notebook and ipython-qtconsole were
moved to a separate project, Jupyter. Packages for ipython 5 and several
Jupyter components are available in experimental (see [1]), however
jupyter-notebook and jupyter-qtconsole are not packaged yet.

vistrails depends on ipython-qtconsole. Could you please evaluate if
this is a blocker for the transition or if vistrails could work
temporarily without a dependency on ipython-qtconsole?
Furthermore, if the dependency on ipython-qtconsole is not strictly
necessary, could you please test your package with ipython 5 from
experimental?

Thanks,
Tobias

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

Bug#840523: debian-installer: undefined source format; .git/ may end up in source tarball

[Steven Chamberlain]

Package: src:debian-installer
Version: 20160704
Severity: important
Tags: patch

Hi!

Suppose a debian-installer source package is produced this way:

$ debcheckout debian-installer
$ cd debian-installer
$ debuild -S
[...]
dpkg-source: warning: no source format specified in debian/source/format, see 
dpkg-source(1)
dpkg-source: warning: source directory 'debian-installer' is not 
- 'debian-installer-20160704'
dpkg-source: info: using source format '1.0'
dpkg-source: info: building debian-installer in debian-installer_20160704.tar.gz
dpkg-source: info: building debian-installer in debian-installer_20160704.dsc

In source format 1.0, dpkg-source does *not* exclude the .git/ directory
from the generated tarball!  So if you built the source package that way,
your Git working tree's refs and config are all included in the upload,
which happened with my uploads here:
http://ftp.debian.org/debian/pool/main/d/debian-installer/debian-installer_20150422+kbsd8u2.tar.gz
http://ftp.debian.org/debian/pool/main/d/debian-installer/debian-installer_20150422+kbsd8u2+deb8u4.tar.gz

Note that source format 1.0 is only used because one is not specified in
debian/source/format.  dpkg-source(1) recommends to specify a version and
the lack of a debian/source/format file may be considered an error in
future.

dpkg-source(1) also recommends choosing a newer format.  3.0 (native)
by default already excludes VCS directories such as .git/ from the
generated tarball, already fixing the issue above.

3.0 (native) does however default to .tar.xz compression, rather than
.tar.gz as used at the moment.  I'm not sure if that may be an issue for
other tools.  Maybe they should be fixed in that case.  Or _if_ it's
preferred to still use .tar.gz, that could be specified in
debian/source/options:
compression = "gzip"

Attached is my proposed patch, for consideration.

Thanks!

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

Kernel: kFreeBSD 10.1-0-amd64
Locale: LANG=en_GB.UTF-8, LC_CTYPE= (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
>From d74e62562b5814a496ff485c4ba4f6bbfa542a50 Mon Sep 17 00:00:00 2001
From: Steven Chamberlain 
Date: Wed, 12 Oct 2016 12:47:02 +
Subject: [PATCH] Switch to dpkg-source format 3.0 (native)

By default this will also exclude VCS directories like .git/ from the
generated source tarball.

This changes the default compression from .tar.gz to .tar.xz also.
---
 debian/source/format | 1 +
 1 file changed, 1 insertion(+)
 create mode 100644 debian/source/format

diff --git a/debian/source/format b/debian/source/format
new file mode 100644
index 000..89ae9db
--- /dev/null
+++ b/debian/source/format
@@ -0,0 +1 @@
+3.0 (native)
-- 
2.1.4

Bug#840510: geoip-generator-asn: broken ASN due to csv misparsing

[Yuriy M. Kaminskiy]

On 12.10.2016 13:58, Yuriy M. Kaminskiy wrote:

P.S. ASN/ipv6 change in patch is completely untested (it seems produces
mangled database [as before]).


oops, above ipv6 issue was my patch fault, patch v2 attached, now

$ wget -q 
http://download.maxmind.com/download/geoip/database/asnum/GeoIPASNum2v6.zip 
&& unzip -q GeoIPASNum2v6.zip

$ geoip-generator-asn -6 -o GeoIPASNumv6.dat GeoIPASNum2v6.csv
$ geoiplookup6 -f GeoIPASNumv6.dat www.google.com
GeoIP ASNum V6 Edition: AS15169 Google Inc.
$ geoiplookup6 -f GeoIPASNumv6.dat 2001:67c:1270::
GeoIP ASNum V6 Edition: AS20712

(note: maxmind's original binary GeoIPASNumv6.dat also contains aliases 
for various mapped ipv4; above generated GeoIPASNumv6.dat contains only 
native ipv6 addresses)
--- geoip_1.6.7-2~bpo8+1/debian/src/geoip-asn-csv-to-dat.cpp.orig	2016-10-12 12:17:11.0 +0300
+++ geoip_1.6.7-2~bpo8+1/debian/src/geoip-asn-csv-to-dat.cpp	2016-10-12 15:41:31.0 +0300
@@ -478,9 +478,12 @@
 		for(int i = 0; i<2;++i) {
 			fs = buf.find(delim);
 			fields.push_back(buf.substr(0,fs));
-			buf.erase(0,fs + 1);
+			buf.erase(0,fs + delim.length());
 		}
+		if (buf[0] == '"' || buf[0] == '\'')
 		fields.push_back(buf.substr(1, buf.length() - 2));
+		else
+			fields.push_back(buf);
 	}
 
 	void
@@ -489,13 +492,16 @@
 		std::vector & fields)
 	{
 		std::string buf(line);
-		std::string delim = ", ";
+		std::string delim = ",";
 		std::size_t fs;
 		for(int i = 0; i<3;++i) {
 			fs = buf.rfind(delim);
-			fields.push_back(buf.substr(fs+2, buf.length()));
+			fields.push_back(buf.substr(fs+delim.length(), buf.length()));
 			buf.erase(fs,buf.length());
 		}
+		if (buf[0] == '"' || buf[0] == '\'')
+			fields.push_back(buf.substr(1, buf.length() - 2));
+		else
 		fields.push_back(buf.substr(0, buf.length()));
 	}
 
@@ -602,7 +608,7 @@
 		  "Cannot parse maximum address: %s",
 		  csv_fields[V6_CSV_FIELD_MAX_TEXT].c_str());
 }
-trie.set_range(minaddr.inetbytes, maxaddr.inetbytes,
+trie.set_range(minaddr.inet6.s6_addr, maxaddr.inet6.s6_addr,
 	   128, leaf);
 break;
 

Bug#833477: Remove forwarding and upstream relevant tags

[Arto Jantunen]

Control: notforwarded -1
Control: tags -1 - upstream - wontfix

Since this issue will not be fixed upstream it would seem that the next
step is to fix it for the Debian package by disabling the built in media
router as shown in the patch.

-- 
Arto Jantunen

Bug#840393: [Pkg-fonts-devel] Bug#840393: mensis: FTBFS with newly released fontforge

[Hideki Yamane]

On Tue, 11 Oct 2016 13:12:54 +0530
Vasudev Kamath  wrote:
> mensis fails to build from source with fontforge version 20161005 from
> experimental. It fails in the configure step with following error
> 
> checking fontforge/basics.h usability... no
> checking fontforge/basics.h presence... no
> checking for fontforge/basics.h... no
> You must install the include files for fontforge

 Some header files in libfontforge-dev seem to be wrong.

--- fontforge-20120731.b/inc/chardata.h 2012-08-03 00:09:09.0 +0900
+++ fontforge-20160404~dfsg/inc/chardata.h  2016-04-05 08:56:57.0 
+0900
@@ -1,4 +1,4 @@
-#include "basics.h"
+#include 
 
 struct charmap {
 int first, last;

--
  chardata.h in unstable → #include "basics.h" = /usr/include/fontforge/basics.h
  chardata.h in experimental → #include  = /usr/include/basics.h



--- fontforge-20120731.b/inc/gimage.h   2012-08-03 00:09:09.0 +0900
+++ fontforge-20160404~dfsg/inc/gimage.h2016-04-05 08:56:57.0 
+0900
@@ -26,7 +26,7 @@
  */
 #ifndef _GIMAGE_H
 #define _GIMAGE_H
-#include "basics.h"
+#include 


--- fontforge-20120731.b/inc/ustring.h  2012-08-03 00:09:09.0 +0900
+++ fontforge-20160404~dfsg/inc/ustring.h   2016-04-05 08:56:57.0 
+0900
@@ -29,13 +29,14 @@
 #include 
 #include 
 #include 
-#include "basics.h"
-#include "charset.h"
+#include 
+#include 


 However, if we'll fix header inclusion, still get failure...

libtool: link: gcc -o makenomenh -g -O2 -fdebug-prefix-map=/mensis-0.0.080507=. 
-fPIE -fstack-protector-strong -Wformat -Werror=format-security 
-Wmissing-prototypes -Wunused -Wimplicit -Wreturn-type -Wparentheses -Wformat 
-Wchar-subscripts -Wsequence-point -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" 
-DPACKAGE_VERSION=\"\" -DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\" 
-DPACKAGE_URL=\"\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 
-DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 
-DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 
-DLT_OBJDIR=\".libs/\" -D_NO_XINPUT=1 -D_NO_XKB=1 ./.libs/makenomenh.o  -lgdraw 
-lgutils -lgunicode -lSM -lICE -lX11 -ldl -lgif -lm 
/usr/lib/x86_64-linux-gnu/libfreetype.so 
./.libs/makenomenh.o: In function `handleint':
././makenomenh.c:81: undefined reference to `grealloc'
./.libs/makenomenh.o: In function `makenomenh':
././makenomenh.c:160: undefined reference to `grealloc'
././makenomenh.c:161: undefined reference to `grealloc'
collect2: error: ld returned 1 exit status
Makefile:49: recipe for target 'mensis-en.ui' failed
make[1]: *** [mensis-en.ui] Error 1

Bug#840520: glueviz: ipython transition: Please help assess the situation

[Tobias Hansen]

Source: glueviz
Severity: normal
Control: block 840501 by -1

Hi,

we are planning to transition ipython from version 2.4 to 5 [1]. This
amounts to larger changes: ipython-notebook and ipython-qtconsole were
moved to a separate project, Jupyter. Packages for ipython 5 and several
Jupyter components are available in experimental (see [1]), however
jupyter-notebook and jupyter-qtconsole are not packaged yet.

glueviz depends on ipython3-qtconsole. Could you please evaluate if this
is a blocker for the transition or if glueviz could work temporarily
without a dependency on ipython3-qtconsole?
Furthermore, if the dependency on ipython3-qtconsole is not strictly
necessary, could you please test your package with ipython 5 from
experimental?

Thanks,
Tobias

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

Bug#840521: lmfit-py: ipython transition: Please help assess the situation

[Tobias Hansen]

Source: lmfit-py
Severity: normal
Control: block 840501 by -1

Hi,

we are planning to transition ipython from version 2.4 to 5 [1]. This
amounts to larger changes: ipython-notebook and ipython-qtconsole were
moved to a separate project, Jupyter. Packages for ipython 5 and several
Jupyter components are available in experimental (see [1]), however
jupyter-notebook and jupyter-qtconsole are not packaged yet.

lmfit-py build-depends on ipython-notebook. Could you please evaluate if
this is a blocker for the transition or if lmfit-py could work
temporarily without a dependency on ipython-notebook?
Furthermore, if the dependency on ipython-notebook is not strictly
necessary, could you please test your package with ipython 5 from
experimental?

Thanks,
Tobias

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

Bug#840526: RFS: python-gimmik/2.1-1 [ITP]

[Ghislain Vaillant]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "python-gimmik"

* Package name: python-gimmik
  Version : 2.1-1
  Upstream Author : Freddie Witherden 
* URL : https://github.com/vincentlab/GiMMiK
* License : BSD
  Section : python

It builds those binary packages:

  python3-gimmik - generator of matrix multiplication kernels (Python 3)

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


  https://mentors.debian.net/package/python-gimmik

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

  dget -x 
https://mentors.debian.net/debian/pool/main/p/python-gimmik/python-gimmik_2.1-1.dsc


Successful test build on debomatic:


http://debomatic-amd64.debian.net/distribution#unstable/python-gimmik/2.1-1/buildlog

Changes since the last upload:

  * Initial release. (Closes: #840509)

Regards,
Ghislain Vaillant

Bug#840527: yade: ipython transition: FTBFS with ipython 5

[Tobias Hansen]

Source: yade
Severity: normal
Control: block 840501 by -1

Hi,

we are planning to transition ipython from version 2.4 to 5 [1].

I tried building yade against ipython 5.1.0-1 (from experimental), but
it failed. A file with the error message is attached.

Please help to fix this to speed up the transition.

Thanks,
Tobias

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=840501
dh_numpy
#Generate docs
cd /home/thansen/src/ipython/yade/yade-2016.06a/doc/sphinx; PYTHONPATH=. 
/home/thansen/src/ipython/yade/yade-2016.06a/debian/tmp/usr/bin/yade 
yadeSphinx.py; cd _build/latex; xelatex Yade.tex; xelatex Yade.tex; xelatex 
Yade.tex;
TCP python prompt on localhost:9000, auth cookie `kaysec'
Welcome to Yade 2016.06a 
Warning: no X rendering available (see 
https://bbs.archlinux.org/viewtopic.php?id=13189)
XMLRPC info provider on http://localhost:21000
Running script yadeSphinx.py
warning: unable to convert `\araa'
warning: unable to convert `\aj'
warning: reference `dec' undefined
warning: unable to convert `\aap'
warning: reference `aug' undefined
Running Sphinx v1.4.8

Exception occurred:
  File 
"/home/thansen/src/ipython/yade/yade-2016.06a/doc/sphinx/ipython_directive200.py",
 line 149, in 
from IPython import Config, InteractiveShell
ImportError: cannot import name Config
The full traceback has been saved in /tmp/sphinx-err-WCdgBk.log, if you want to 
report the issue to the developers.
Please also report this if it was a user error, so that a better error message 
can be provided next time.
A bug report can be filed in the tracker at 
. Thanks!
Traceback (most recent call last):
  File "/home/thansen/src/ipython/yade/yade-2016.06a/debian/tmp/usr/bin/yade", 
line 182, in runScript
execfile(script,globals())
  File "yadeSphinx.py", line 224, in 
makeBaseClassesClickable((outDir+'/html/yade.wrapper.html'),writer)
  File "yadeSphinx.py", line 154, in makeBaseClassesClickable
for l in open(f):
IOError: [Errno 2] No such file or directory: '_build/html/yade.wrapper.html'
/usr/lib/python2.7/dist-packages/IPython/config.py:13: ShimWarning: The 
`IPython.config` package has been deprecated. You should import from 
traitlets.config instead.
  "You should import from traitlets.config instead.", ShimWarning)
/usr/lib/python2.7/dist-packages/IPython/core/interactiveshell.py:448: 
UserWarning: As of IPython 5.0 `PromptManager` config will have no effect and 
has been replaced by TerminalInteractiveShell.prompts_class
  warn('As of IPython 5.0 `PromptManager` config will have no effect'

Bug#840009: Applied

[Bastien ROUCARIES]

Patch is fine

Applied

Bug#827335: evince: assertion failed: (wayland_display->cursor_theme_name)

[Michael Biebl]

Am 11.10.2016 um 22:53 schrieb Jason Crain:
> On Tue, Oct 11, 2016 at 09:44:48PM +0200, Michael Biebl wrote:
>> Am 11.10.2016 um 19:52 schrieb Diane Trout:
>>> --- debian/evince/etc/apparmor.d/usr.bin.evince 2016-10-10
>>> 23:32:09.826405495 -0700
>>> +++ /etc/apparmor.d/usr.bin.evince  2016-10-11 10:45:06.401131452
>>> -0700
>>> @@ -65,8 +65,9 @@
>>>owner @{HOME}/** rw,
>>>owner /media/**  rw,
>>>owner @{HOME}/.local/share/gvfs-metadata/** l,
>>>owner /{,var/}run/user/*/gvfs-metadata/** l,
>>> +  owner /{,var/}run/user/*/weston-shared-* rw,
>>
>> Does anyone know why this rule includes /var/run/user?
>> We are talking about XDG_RUNTIME_DIR here, which is /run/user/ and I
>> never saw it referenced as /var/run/user
> 
> I don't know.  If I delete every occurance of {,var/} from the file it
> still works.  It could be left over cruft from this release goal, to
> transition from /var/run to /run:
> https://wiki.debian.org/ReleaseGoals/RunDirectory

I've tried running evince under GNOME/Wayland and I don't have a
/run/user/*/weston-shared-* directory

Since I know nothing about apparmor, I'd prefer having input from the
apparmor and wayland maintainers first, if the proposed patch is
sensible. I don't like to simply guess.

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



signature.asc
Description: OpenPGP digital signature

Bug#840452: [pkg-gnupg-maint] Bug#840452: Package is not binNMU safe

[Daniel Kahn Gillmor]

On Wed 2016-10-12 04:01:42 -0400, Vincent Danjean wrote:
> Package: gnupg1
> Version: 1.4.21-1+b1
> Followup-For: Bug #840452
>
>   There is also a problem in gnupg1-l10n (arch: all) that
> has currently:
> Enhances: gnupg1 (= 1.4.21-1)
> while only gnupg1 1.4.21-1+b1 is available.
>
>   This situation leads my system to propose me to remove
> gnupg1-l10n:
> vdanjean@eyak:~$ LC_ALL=C sudo apt upgrade
> Reading package lists... Done
> Building dependency tree   
> Reading state information... Done
> Calculating upgrade... Done
> The following package was automatically installed and is no longer required:
>   gnupg1-l10n
> Use 'sudo apt autoremove' to remove it.
> 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
> vdanjean@eyak:~$ apt-cache policy gnupg1-l10n gnupg1
> gnupg1-l10n:
>   Installé : 1.4.21-1
>   Candidat : 1.4.21-1
>  Table de version :
>  *** 1.4.21-1 500
> 500 http://ftp.fr.debian.org/debian testing/main amd64 Packages
> 500 http://ftp.fr.debian.org/debian unstable/main amd64 Packages
> 100 /var/lib/dpkg/status
> gnupg1:
>   Installé : 1.4.21-1+b1
>   Candidat : 1.4.21-1+b1
>  Table de version :
>  *** 1.4.21-1+b1 500
> 500 http://ftp.fr.debian.org/debian testing/main amd64 Packages
> 500 http://ftp.fr.debian.org/debian unstable/main amd64 Packages
> 100 /var/lib/dpkg/status

indeed, that's annoying.  however, i think that when 1.4.21-2 gets
uploaded [0] with the slightly looser Recommends: from gnupg1 to
gnupg1-l10n, apt will not consider gnupg1-l10n to be abandoned
("auto-installed") from a dependency viewpoint:

[0] 
https://anonscm.debian.org/git/pkg-gnupg/gnupg1.git/commit/?id=b4b610ef8c241c23717ec7ccc423d3811e07741b

Thanks for checking in and reporting back.  Please let me know if you
think this fix isn't going to resolve your view of the problem for some
reason.

   --dkg


signature.asc
Description: PGP signature

Bug#840087: libreoffice-draw: does not compress PDFs in the latest version

[Andreas Glaeser]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Mon, 10 Oct 2016 09:32:34 +0200
Rene Engelhard  wrote:

> found 840087 1:5.2.2~rc2-2
> tag 840087 + moreinfo
> thanks
> 
> Hi,
> 
> On Sat, Oct 08, 2016 at 10:17:20AM +0200, Andreas Glaeser wrote:
> > -BEGIN PGP SIGNED MESSAGE-
> > Package: libreoffice-draw
> > Version: 1:5.2.2~rc2-2~bpo8+1  
> 
> No. There's a reason backports bug get redirected to debian-backports as
> the BTS is NOT for bpo bugs.  It does not help very much that you try to be
> smart and CC submit@bugs
> 
> See https://backports.debian.org/FAQ/, point 1.
> 
> It does not even know the version and thinks it affects everything
> (see 
> https://bugs.debian.org/cgi-bin/pkgreport.cgi?dist=stable;package=libreoffice-draw)
> (Yes, it says From other Branch bugs, but it appears open)
> 
If I am getting things correctly, the backported version is identical with the 
one in
Stretch/testing, so the same bug would be there, it migrated there in fact from 
unstable
and if nobody complains or otherwise nobody feels responsible to react to the 
report, it
will inevitably migrate to stable.

> > there appeared a new version of the LibreOffice suite from Backports today.
> > LibreOffice-Draw fails to compress multipage-PDFs, it just makes a copy of 
> > the
> > original document, regardless of the quality- and other settings.
> > I use this function quite frequently, so I can tell, the problem appeared 
> > _today_.  
> 
> So between 5.1.5 and 5.2.2. Very helpful. Another reason why bug reporting
> should be done on sid, so one knows what happens when, not only when the
> thing is (supposedly) stable enough to get into backports.
> 
Sorry, I am not using unstable, I never have in fact, I think the version in 
testing is
usually new enough, except, there is currently a freeze-phase on the 
testing-branch.

> > If there is nothing done about this, I will have to downgrade the software 
> > to the
> > normal stable version 4 again.  
> 
> Sorry, this is complete nonsense. Either it's "minor", then it's exactly that
> and there's no need to revert. Or it's more. (BTW, stretch will contain
> 5.2.x in any way.)
> 
I have downgraded my packages already agin, this is how I got rid of the 
problem:

> andrew@a68n:~$ aptitude show libreoffice
> Package: libreoffice 
> State: installed
> Automatically installed: no
> Version: 1:4.3.3-2+deb8u5
> Priority: optional
> Section: metapackages
> Maintainer: Debian LibreOffice Maintainers 
> 
> Architecture: amd64
> Uncompressed Size: 159 k
> Depends: fonts-sil-gentium-basic, libreoffice-base, libreoffice-calc, 
> libreoffice-core
> (= 1:4.3.3-2+deb8u5), libreoffice-draw, libreoffice-impress,
 libreoffice-math, libreoffice-report-builder-bin, libreoffice-writer,
libreoffice-avmedia-backend-gstreamer | libreoffice-avmedia-backend-vlc,
>  fonts-dejavu, libreoffice-java-common (>= 1:4.3.3~), python3-uno (>= 
> 4.0~) |
> python-uno
Recommends: fonts-liberation | ttf-mscorefonts-installer, libpaper-utils
> Suggests: cups-bsd, hunspell-dictionary, hyphen-hyphenation-patterns, 
> iceweasel |
> firefox | icedove | thunderbird | iceape-browser | mozilla-browser,
  imagemagick | graphicsmagick-imagemagick-compat, libgl1, 
libreoffice-gnome |
libreoffice-kde, libreoffice-grammarcheck, libreoffice-help-4.3,
>   libreoffice-l10n-4.3, libsane, libxrender1, myspell-dictionary,
> mythes-thesaurus, openclipart-libreoffice, pstoedit, unixodbc,
>
  gstreamer1.0-plugins-base, gstreamer1.0-plugins-good,
gstreamer1.0-plugins-ugly, gstreamer1.0-plugins-bad, gstreamer1.0-ffmpeg, 
default-jre |
gcj-jre
>   | openjdk-7-jre | openjdk-6-jre | sun-java5-jre | sun-java6-jre |
> java5-runtime | jre, libreoffice-officebean   
>  
Description: office productivity suite
(metapackage)   

>  LibreOffice is a full-featured office productivity suite that provides a 
> near drop-in
> replacement for Microsoft(R) Office.

   
>  This metapackage installs all components of
> libreoffice:  
> 
>  * libreoffice-writer: Word
> processor 
>  
>  * libreoffice-calc:
> Spreadsheet   
> 
>  * libreoffice-impress:
> Presentation  
>  
>  * 

Bug#667616: brltty greedily grabs serial ports, ftdi_sio loses connection

[Mariusz Gronczewski]

At this points it grabs devices that are definitely NOT a generic
non-customized FTDI device, for example it grabbed my USB<->1wire
adapter which had "manufacturer"  and "product" field customized:

Device: ID 0403:6001 Future Technology Devices International, Ltd
FT232 USB-Serial (UART) IC
Device Descriptor:
  bLength18
  bDescriptorType 1
  bcdUSB   2.00
  bDeviceClass0 (Defined at Interface level)
  bDeviceSubClass 0
  bDeviceProtocol 0
  bMaxPacketSize0 8
  idVendor   0x0403 Future Technology Devices International, Ltd
  idProduct  0x6001 FT232 USB-Serial (UART) IC
  bcdDevice6.00
  iManufacturer   1 MERA-PROJEKT
  iProduct2 USB <-> 1Wire (MP00202)
  iSerial 3 MPYRNJYY
  bNumConfigurations  1

and I also got it as suprise dependency to... *something* but it is
hard to tell what

so at least that should be fixed

-- 
Mariusz Gronczewski (XANi) 
GnuPG: 0xEA8ACE64

Bug#797999: more debug info

[Eric Valette]

On 10/12/2016 11:44 AM, Eric Valette wrote:

On 10/12/2016 10:57 AM, Eric Valette wrote:

On 10/11/2016 04:22 PM, Eric Valette wrote:

On 10/11/2016 04:10 PM, Dominique Dumont wrote:



Could you try that on your side ?

I can do the test but I never open the lid when docked so this will not
be my use case and this means also modifying my xorg.conf.


Once session is initialized with kdm, in system settings-> display and
monitor, I have DP4 on at 1920x1200 (as reported by xrandr even when
failing) and DP3 off.


I tried to let the lid open with my actual xorg.conf and rebooted, both
screen go black. I can still switch to laptop lid in text mode using
ctrl-alt-f1. I loged to my accound, killed sddm service and did a
startx, and the kde session shows up correctly on the external monitor
and laptop screen goes black.



I was in a meeting so undocked my laptop and by curiosity completely 
removed the xorg.conf and tried sddm. Even in this simpliest config it 
fails and the screen goes black after displaying the Nvidia logo 
(usually I use the No Logo option but as xorg.conf was empty). I got 
sddm errors in /var/run/sddm.log. It says the greeter can't open the 
display.


So probably the problem is not the docking and the external monitor. 
Compared to other working setup with same software stack (legacy 340 
nvidia driver), the only thing I can see that differs is the fact that 
the laptop lid is wired via DisplayPort versus HDMI.


xrandr on this config when started via kdm
Screen 0: minimum 8 x 8, current 1440 x 900, maximum 8192 x 8192
VGA-0 disconnected (normal left inverted right x axis y axis)
DP-0 disconnected (normal left inverted right x axis y axis)
DP-1 disconnected (normal left inverted right x axis y axis)
DP-2 disconnected (normal left inverted right x axis y axis)
DP-3 connected primary 1440x900+0+0 (normal left inverted right x axis y 
axis) 304mm x 190mm

   1440x900  59.96*+  39.96
DP-4 disconnected (normal left inverted right x axis y axis)



--eric

Bug#840345: firefox-esr: update packaged add-ons automatically

[att200...@yahoo.it]

Hi Mike,
Really I don't know if it depends on the setting or not. I've used Iceweasel 
with noscript for several years and it has never updated the add-on, and this 
was good, even if the packaged version was outdated (and usually it was).
In my opinion updating automatically the add-ons should not be a good practice, 
even if the behavior is new or not, otherwise packaging noscript has little 
sense (it will be replaced by the upstream version as soon as a new version 
will be released).
Best,Athos
  Da: Mike Hommey 
 A: "att200...@yahoo.it" ; 840...@bugs.debian.org 
 Inviato: Martedì 11 Ottobre 2016 0:14
 Oggetto: Re: Bug#840345: firefox-esr: update packaged add-ons automatically
   
On Mon, Oct 10, 2016 at 07:02:58PM +, att200...@yahoo.it wrote:
> Subject: firefox-esr: update packaged add-ons automatically
> Package: firefox-esr
> Version: 45.4.0esr-1~deb8u2
> Severity: wishlist
> 
> Dear Maintainer,
> 
> After the transition from Iceweasel to Firefox-ESR, the browser is now 
> configured to update add-ons automatically.

There were no changes in the default settings for that.

Mike


   

Bug#840521: lmfit-py: ipython transition: Please help assess the situation

[PICCA Frederic-Emmanuel]

> we are planning to transition ipython from version 2.4 to 5 [1]. This
> amounts to larger changes: ipython-notebook and ipython-qtconsole were
> moved to a separate project, Jupyter. Packages for ipython 5 and several
> Jupyter components are available in experimental (see [1]), however
> jupyter-notebook and jupyter-qtconsole are not packaged yet.

Juste for info, I amrezady pacakged python-qtconsole

There is no jupyter-qtconsole package, but the python modules are available 
under

python(3)-qtconsole.


Cheers

Bug#840529: systemd-sysctl.service does not run in LXC containers

[Christian Hofstaedtler]

Package: systemd
Version: 215-17+deb8u5
Severity: normal
Tags: upstream

Hi,

systemd-sysctl.service does not start in LXC containters, as they
have /proc/sys R/O. *BUT* /proc/sys/net is R/W.

It'd be useful if the net-specific settings would still be applied at
boot.

Arch has "fixed" this in their lxc package by modifying
systemd-sysctl.service when creating a new container, but this can
not be the correct solution.
See 
https://github.com/lxc/lxc/pull/683/commits/427d42930d99f93bf78c61ec9f555dd883c5039e

Thanks,
C.


-- Package-specific info:

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

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#840528: libmongoc: mongoc-stream-tls.h wants mongoc-stream-tls-private.h, which is absent

[Rinat]

Source: libmongoc
Version: 1.4.1-1
Severity: important

Hi.

Just installed libmongoc-dev=1.4.1-1 and found that 3rd-party applications now 
are
fail to compile due to missing "mongoc-stream-tls-private.h" file.

If I comment out its inclusion in "mongoc-stream-tls.h", issue disappears.


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

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

Bug#840530: xinput: 7-bit terminal not respected

[Harald Barth]

Package: xinput
Version: 1.6.1-1
Severity: minor

Dear Maintainer,

Even with LANG=C and LC_ALL=C which mandates 7-bit terminal, the
xinput command emits 8-bit characters.

Example:

# LC_ALL=C LANG=C xinput | od -c | head
000 342 216 241   V   i   r   t   u   a   l   c   o   r   e
020   p   o   i   n   t   e   r
040  \t   i   d   =
060   2  \t   [   m   a   s   t   e   r   p   o   i   n   t   e
100   r   (   3   )   ]  \n 342 216 234 342 206
120 263   V   i   r   t   u   a   l   c   o   r   e   X
140   T   E   S   T   p   o   i   n   t   e   r
160  \t   i   d   =   4  \t
200   [   s   l   a   v   e   p   o   i   n   t   e   r
220   (   2   )   ]  \n 342 216 234 342 206 263

According to the specification of the "C" locate, these characters
(for example the first Unicode Character 'LEFT SQUARE BRACKET UPPER
CORNER') should be replaced with something appropriate for the LANG=C
environment. In addition to that, all software should support the
LANG=C environment.

Regards,
Harald.

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

Kernel: Linux 3.13.0-37-generic (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages xinput depends on:
ii  libc6 2.19-0ubuntu6.6
ii  libx11-6  2:1.6.2-1ubuntu2
ii  libxi62:1.7.1.901-1ubuntu1.1
ii  libxinerama1  2:1.1.3-1
ii  libxrandr22:1.4.2-1

xinput recommends no packages.

xinput suggests no packages.

-- no debconf information

Bug#836175: [buildd-tools-devel] Bug#836175: libsbuild-perl: Do not use single quotes in embedded perl script

[Johannes Schauer]

Hi,

On Thu, 1 Sep 2016 01:00:38 +0200 Samuel Thibault  wrote:
> Johannes Schauer, on Wed 31 Aug 2016 19:29:47 +0200, wrote:
> > if your setup deviates from the default, please include in your bugreport 
> > how
> > it does.
> 
> Ok, got to reproduce it easily:
> 
> # sbuild-createchroot sid /var/tmp/foo http://ftp2.fr.debian.org/debian
> # sudo sbuild-adduser samy  
> 
> in ~samy/.sbuildrc, just put 
> 
> $chroot_mode='sudo';
> 
> and then
> 
> sbuild -d sid foo_1.1-1
> 
> gets the issue.

sorry for the long wait. Indeed the problem is with the sudo chroot mode. The
problem should also occur with the plain chroot mode. As I pointed out in
earlier messages, the solution should not be to just replace all single quotes
by double quotes. Instead, we can apply a smarter fix by properly escaping the
command string. Here is a patch:


--- a/lib/Sbuild/ChrootSudo.pm
+++ b/lib/Sbuild/ChrootSudo.pm
@@ -25,6 +25,7 @@ package Sbuild::ChrootSudo;
 use strict;
 use warnings;
 
+use Sbuild qw(shellescape);
 use Sbuild::Sysconfig;
 
 BEGIN {
@@ -111,14 +112,10 @@ sub get_command_internal {
 my $shellcommand;
 foreach (@$command) {
 my $tmp = $_;
-$tmp =~ s/'//g; # Strip any single quotes for security
-if ($_ ne $tmp) {
-$self->log_warning("Stripped single quote from command for 
security: $_\n");
-}
 if ($shellcommand) {
-$shellcommand .= " '$tmp'";
+$shellcommand .= " " . shellescape $tmp;
 } else {
-$shellcommand = "'$tmp'";
+$shellcommand = shellescape $tmp;
 }
 }
 push(@cmdline, '/bin/sh', '-c', "cd '$dir' && $shellcommand");



When I try this out, then many commands seem to be executed correctly. My build
fails as soon as sbuild attempts to execute something inside the chroot not as
the root user but as the user running sbuild. So I end up getting:

User Environment


sudo: no tty present and no askpass program specified
E: read_command failed to execute env
E: unable to open pipe


So this seems to be some problem with sudo. How can I fix it? Do you run into
the same problem?  You can easily run sbuild from git using:

PERL5LIB=$SBUILDGITPATH/lib $SBUILDGITPATH/bin/sbuild --chroot-mode=sudo

Thanks!

cheers, josch


signature.asc
Description: signature

Bug#837449: brightness not properly reset after suspend

[Michael Biebl]

On Sun, 11 Sep 2016 19:37:30 +0200 Pascal Obry  wrote:
> Package: gnome-power-manager
> Version:Â 3.21.91-1
> 
> Since recent updates on Debian/sid the brightness is not properly reset
> on resume after suspend or at boot time.
> 
> That is, the brightness is always reset to its maximum value.
> 
> Am fully up-to-date on Debian/sid.
> 
> Let me know if you need more information.
> 

gnome-power-manager no longer handles any brightness settings, so it's
most likely not the right package you filed it against.

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



signature.asc
Description: OpenPGP digital signature

Bug#826942: sbuild: buildd-uploader hangs if a stale lockfile is present

[Johannes Schauer]

Hi,

On Fri, 10 Jun 2016 11:32:02 +0200 John Paul Adrian Glaubitz 
 wrote:
> I just ran into a minor annoyance with buildd-uploader after one of our
> sparc64 buildds crashed. buildd-uploader got stuck consuming lots of CPU time
> after being invoked by the cronjob after the machine was recovered after the
> crash.
> 
> Looking into the daemon.log file, there was also no output from the uploader
> script to be seen. Since buildd-uploader worked fine for the other instances
> of the buildd on the same machine, I assumed it was some issue specific to
> this particular buildd user.
> 
> Turns out, the lockfile was still there and keeping the buildd-uploader busy.
> After deleting the lockfile, the uploader works as expected again:
> 
> root@atlantis:~# su - buildd
> buildd@atlantis:~$ touch buildd-uploader.lock
> buildd@atlantis:~$ /usr/bin/buildd-uploader
> ^C # stuck here
> buildd@atlantis:~$ rm buildd-uploader.lock
> buildd@atlantis:~$ /usr/bin/buildd-uploader
> buildd@atlantis:~$
> 
> I guess buildd-uploader should be modified to check for stale lockfiles and
> remove them.

could this be the same problem as #577421?

Thanks!

cheers, josch


signature.asc
Description: signature

Bug#837449: brightness not properly reset after suspend

[Pascal Obry]

Hi Michael,

> gnome-power-manager no longer handles any brightness settings, so
> it's most likely not the right package you filed it against.

Ok, do you have any idea about the package responsible for this?

Thanks,

-- 
  Pascal Obry /  Magny Les Hameaux (78)

  The best way to travel is by means of imagination

  http://www.obry.net

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

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

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

[Sean Whitton]

Hello Boyuan,

On Wed, Oct 12, 2016 at 11:03:43AM +0800, Boyuan Yang wrote:
> 2016-10-12 10:43 GMT+08:00 Sean Whitton :
> > Have you read /usr/share/doc/doxygen/README.jquery?
> >
> > I think you shouldn't be symlinking jquery.
> 
> Wow, I did not read it before since I trusted lintian :p

That's usually reasonable!

> Looks like it is kind of disagreement between the packager / uploader
> of doxygen and debian policy.

Debian Policy often lags behind best practices.  It's not necessarily a
disagreement, just that the process to update policy hasn't concluded.

> I found bug #736360 and dh_doxygen really interesting, but still kind
> of confused. dh_doxygen did not mention this embedding problem in its
> manpage, and those Debian bug reports did not give a final solution
> either. So what should I do? Just override the lintian warning?

Sorry, dh_doxygen is different from the jquery issue.

I suggest:

1) override the jquery warning, with a comment pointing to README.jquery
(there is a special format for lintian override comments)

2) ensure that dh_doxygen is run after you build the documentation.  It
does various things like symlink template files.

--
Sean Whitton


signature.asc
Description: PGP signature