Bug#822415: [src:linux] Kernel 4.5 breaks OpenAFS client module build

[Dirk Heinrichs]

Package: src:linux
Version: 4.5.0-1
Severity: important

--- Please enter the report below this line. ---
OpenAFS client kernel module (openafs-modules-dkms) don't build for kernel 
4.5:

# dkms build -k 4.5.0-1-amd64 -m openafs -v 1.6.17

Kernel preparation unnecessary for this kernel.  Skipping...

Building module:
cleaning build area(bad exit status: 2)
(./configure --disable-linux-syscall-probing --with-afs-sysname=amd64_linux26 
--with-linux-kernel-packaging --with-linux-kernel-
headers=/lib/modules/4.5.0-1-amd64/build && make && mv src/libafs/MODLOAD-
*/openafs.ko 
.)
(bad exit status: 2)
Error! Bad return status for module build on kernel: 4.5.0-1-amd64 (x86_64)
Consult /var/lib/dkms/openafs/1.6.17/build/make.log for more information.

make.log is attached.

--- System information. ---
Architecture: amd64
Kernel:   Linux 4.4.0-1-amd64

Debian Release: stretch/sid
  990 testing www.deb-multimedia.org 
  990 testing vwakviie2ienjx6t.onion 
  990 testing security.debian.org 
  500 utopic  ppa.launchpad.net 
  500 unstabledownload.jitsi.org 
  500 syncthing   apt.syncthing.net 
  500 stable  update.devolo.com 
  500 nightly pkg.tox.chat 

--- Package information. ---
Package's Depends field is empty.

Package's Recommends field is empty.

Package's Suggests field is empty.
-- 
Dirk Heinrichs 
GPG Public Key CB614542 | Jabber: dirk.heinri...@altum.de
Tox: he...@toxme.se
Sichere Internetkommunikation: http://www.retroshare.org
Privacy Handbuch: https://www.privacy-handbuch.de
DKMS make.log for openafs-1.6.17 for kernel 4.5.0-1-amd64 (x86_64)
So 24. Apr 08:43:33 CEST 2016
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
/var/lib/dkms/openafs/1.6.17/build/build-tools/missing: Unknown `--is-lightweight' option
Try `/var/lib/dkms/openafs/1.6.17/build/build-tools/missing --help' for more information
configure: WARNING: 'missing' script is too old or missing
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables... 
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking whether gcc understands -c and -o together... yes
checking for style of include used by make... GNU
checking dependency style of gcc... none
checking build system type... x86_64-pc-linux-gnu
checking host system type... x86_64-pc-linux-gnu
checking how to run the C preprocessor... gcc -E
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking for flex... no
checking for lex... no
checking for pkg-config... /usr/bin/pkg-config
checking pkg-config is at least version 0.9.0... yes
checking for libxslt... no
checking for saxon... no
checking for xalan-j... no
checking for xsltproc... xsltproc
checking for docbook2pdf... no
checking for dblatex... dblatex
checking for library containing strerror... none required
checking for pid_t... yes
checking for size_t... yes
checking whether ln -s works... yes
checking for ranlib... ranlib
checking for bison... bison -y
checking if lex is flex... no
checking whether byte order is known at compile time... yes
checking whether byte ordering is bigendian... no
checking whether printf understands the %z length modifier... yes
checking your OS... linux
checking if gcc accepts -march=pentium... no
checking if gcc needs -fno-strength-reduce... yes
checking if gcc needs -fno-strict-aliasing... yes
checking if gcc supports -fno-common... yes
checking if gcc supports -pipe... yes
checking if linux kbuild requires EXTRA_CFLAGS... yes
checking for linux kernel module build works... yes
checking operation follow_link in inode_operations... no
checking operation put_link in inode_operations... no
checking for linux/config.h... no
checking for linux/completion.h... yes
checking for linux/exportfs.h... yes
checking for linux/freezer.h... yes
checking for linux/key-type.h... yes
checking for linux/semaphore.h... yes
checking for linux/seq_file.h... yes
checking for struct vfs_path... no
checking for kuid_t... yes
checking for backing_dev_info in struct address_space... no
checking for wr

Bug#822416: Install LVM with Free PE

[Geert Stappers]

Package: debian-installer
Severity: wishlist

Hi,

Where I can understand the service to the user for presenting her the whole 
disks,
it feels wrong to do this also for LVM installs.


Explaining:

Guided partitioning with seperate /var and /home, makes big /home partitions.

Guided partitioning with seperate /var/ and /home on LVM,
assigns all remaining Physical Extents to the /home file system.
Probably due thinking in partitions.

After installs with Logical Volumes,
I start with reducing the size of the /home FS to get P.E. available,
to create /srv/ file systems.

During install I have been waiting on creation of the too big /home.


Wish:

The guided LVM install creates only a small /home f.s.


Benefits:
- faster install due quick `mkfs /home`
- having PE available for extra filesystems,
  most likely the reason for using LVM



Groeten
Geert Stappers

Bug#822417: RM: libcommons-net2-java -- ROM; superseded by libcommons-net-java (>= 3)

[Markus Koschany]

Package: ftp.debian.org
Severity: normal

Hi,

please remove libcommons-net2-java from Debian. It was superseded by
libcommons-net-java (>= 3).

Thanks,

Markus

Bug#818974: packaging

[Dominique Dumont]

On Saturday 23 April 2016 10:10:28 Roderick MacKenzie wrote:
> I've now used license-reconcile and a bit of copy and paste from
> hedgewars to sort out the copyright file.

You can also try "cme update dpkg-copyright". 

See 
https://github.com/dod38fr/config-model/wiki/Updating-debian-copyright-file-with-cme
for instructions,

HTH

-- 
 https://github.com/dod38fr/   -o- http://search.cpan.org/~ddumont/
http://ddumont.wordpress.com/  -o-   irc: dod at irc.debian.org

Bug#794800: refcard: Incorrect Spanish translations

[Holger Wansing]

Control: tags -1 + pending


Quoting Octavio Alvarez:
"I have detected some mistakes in the Debian Reference Card Spanish translation.
I am attaching the following patches to fix them."


I have committed that. Thanks


-- 

Created with Sylpheed 3.5.0 under
D E B I A N   L I N U X   8 . 0   " J E S S I E " .

Registered Linux User #311290 - https://linuxcounter.net/

Bug#822413: mysql-workbench: Unhandled exception on Data Export

[Dmitry Smirnov]

On Sunday, 24 April 2016 1:32:26 AM AEST Juan Pablo Jaramillo Pineda wrote:
> There are reports about this issue on MySQL Workbench Bugtrack[1][2].

Thank you for checking and mentioning upstream bugs.


> It's possible to update the package to 6.3.6 version?

Unfortunately it is not possible yet because M-W depends on mysql-5.7 
libraries that we still don't have in Debian. See details in 

  https://bugs.mysql.com/bug.php?id=79054

-- 
All the best,
 Dmitry Smirnov.


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

Bug#822416: Install LVM with Free PE, partman-?????

[Geert Stappers]

On Sun, Apr 24, 2016 at 09:00:05AM +0200, Geert Stappers wrote:
> Package: debian-installer

Which partman-?  package is it?



> Wish:
> 
> The guided LVM install creates only a small /home f.s.
} so there are PE available after install


My reason of expressing my old wish
and not doing the research of which package contains the source
this posting on debian-boot@l.d.o. on 2016-04-24

| > Secondly, Do we want to limit the difficulty of supporting complicated
| > configurations by establishing simple conventions and recommendation
| > early on?  eg: all subvolumes created in the installation are peers,
| > and a subvolume that will be mounted at /var/www is named var_www.
| > A default delimiter convention would also need to be chosen.
| 
| Install a starting point.
| More complicated configuration can be done on the installed system.
| KISS

Keep It Simple

Bug#822389: ngrok: FTBFS: can't load package: package ngrok/cache: cannot find package "ngrok/cache"

[Vincent Bernat]

 ❦ 23 avril 2016 18:12 -0700, Martin Michlmayr  :

> Package: ngrok
> Version: 1.6+dfsg-1
> Severity: serious
>
> This package fails to build in unstable:
[...]

I intend to ask for its removal due to #819631.
-- 
Use the fundamental control flow constructs.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Bug#796603: closed by Anton Zinoviev (Bug#796603: fixed in console-setup 1.138)

[Christian PERRIER]

Quoting Felipe Sateler (fsate...@debian.org):
> I have uploaded a new version. I have not yet, however, secured commit
> rights to d-i git repository. If you want to pull the changes before I
> get the access, you can pull the signed tag from my fork:
> 
> git pull https://anonscm.debian.org/git/users/fsateler/console-setup.git
> debian/1.141


I just added you to committers : I didn't notice this discussion when
it happened and went on a problem when trying to upload a new version
of the package --> my new version was 1.141 as it was built from git,
and of course it was REJECTed as it conclicted with your upload.

Would you mind pushing your changes to the D-I git? I'm more confident
in you doing so than me merging from your git repo as my git skills
are.let's say incomplete..:-)




signature.asc
Description: PGP signature

Bug#822418: twisted-web2: FTBFS: twisted.python.dist module not found

[Chris Lamb]

Source: twisted-web2
Version: 8.1.0-3
Severity: serious
Justification: fails to build from source
User: reproducible-bui...@lists.alioth.debian.org
Usertags: ftbfs
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Dear Maintainer,

twisted-web2 fails to build from source in unstable/amd64:

  [..]

  dh_testdir
  dh_testroot
  dh_prep
  dh_testdir
  dh_testroot
  dh_install
  dh_installdocs
  dh_installchangelogs
  dh_compress
  dh_fixperms
  dh_installdeb
  dh_gencontrol
  dh_md5sums
  dh_builddeb
  dpkg-deb: building package 'twisted-web2-build-deps' in 
'../twisted-web2-build-deps_8.1.0-3_all.deb'.
  
  The package has been created.
  Attention, the package has been created in the current directory,
  not in ".." as indicated by the message above!
  Selecting previously unselected package twisted-web2-build-deps.
  (Reading database ... 23003 files and directories currently installed.)
  Preparing to unpack twisted-web2-build-deps_8.1.0-3_all.deb ...
  Unpacking twisted-web2-build-deps (8.1.0-3) ...
  Reading package lists...
  Building dependency tree...
  Reading state information...
  Correcting dependencies... Done
  The following additional packages will be installed:
libexpat1-dev libpython-all-dev libpython-dev libpython2.7 libpython2.7-dev
python-all python-all-dev python-attr python-cffi-backend
python-cryptography python-dev python-enum34 python-idna python-ipaddress
python-openssl python-pyasn1 python-pyasn1-modules python-service-identity
python-twisted-bin python-twisted-core python-zope.interface python2.7-dev
  Suggested packages:
python-cryptography-doc python-cryptography-vectors python-enum34-doc
python-openssl-doc python-openssl-dbg doc-base python-twisted-bin-dbg
python-tk python-gtk2 python-glade2 python-qt3 python-wxgtk3.0
  Recommended packages:
python-pam python-serial
  The following NEW packages will be installed:
libexpat1-dev libpython-all-dev libpython-dev libpython2.7 libpython2.7-dev
python-all python-all-dev python-attr python-cffi-backend
python-cryptography python-dev python-enum34 python-idna python-ipaddress
python-openssl python-pyasn1 python-pyasn1-modules python-service-identity
python-twisted-bin python-twisted-core python-zope.interface python2.7-dev
  0 upgraded, 22 newly installed, 0 to remove and 0 not upgraded.
  1 not fully installed or removed.
  Need to get 31.8 MB of archives.
  After this operation, 62.1 MB of additional disk space will be used.
  Get:1 http://httpredir.debian.org/debian sid/main amd64 python-all amd64 
2.7.11-1 [936 B]
  Get:2 http://httpredir.debian.org/debian sid/main amd64 libpython2.7 amd64 
2.7.11-8 [1069 kB]
  Get:3 http://httpredir.debian.org/debian sid/main amd64 libexpat1-dev amd64 
2.1.1-1 [126 kB]
  Get:4 http://httpredir.debian.org/debian sid/main amd64 libpython2.7-dev 
amd64 2.7.11-8 [27.8 MB]
  Get:5 http://httpredir.debian.org/debian sid/main amd64 libpython-dev amd64 
2.7.11-1 [19.6 kB]
  Get:6 http://httpredir.debian.org/debian sid/main amd64 libpython-all-dev 
amd64 2.7.11-1 [952 B]
  Get:7 http://httpredir.debian.org/debian sid/main amd64 python2.7-dev amd64 
2.7.11-8 [278 kB]
  Get:8 http://httpredir.debian.org/debian sid/main amd64 python-dev amd64 
2.7.11-1 [1116 B]
  Get:9 http://httpredir.debian.org/debian sid/main amd64 python-all-dev amd64 
2.7.11-1 [956 B]
  Get:10 http://httpredir.debian.org/debian sid/main amd64 python-twisted-bin 
amd64 16.1.1-1 [19.6 kB]
  Get:11 http://httpredir.debian.org/debian sid/main amd64 
python-zope.interface amd64 4.1.3-1+b1 [87.3 kB]
  Get:12 http://httpredir.debian.org/debian sid/main amd64 python-cffi-backend 
amd64 1.5.2-1+b1 [64.3 kB]
  Get:13 http://httpredir.debian.org/debian sid/main amd64 python-enum34 all 
1.1.2-1 [35.9 kB]
  Get:14 http://httpredir.debian.org/debian sid/main amd64 python-idna all 
2.1-1 [31.4 kB]
  Get:15 http://httpredir.debian.org/debian sid/main amd64 python-ipaddress all 
1.0.16-1 [17.9 kB]
  Get:16 http://httpredir.debian.org/debian sid/main amd64 python-pyasn1 all 
0.1.9-1 [51.4 kB]
  Get:17 http://httpredir.debian.org/debian sid/main amd64 python-cryptography 
amd64 1.3.1-1 [203 kB]
  Get:18 http://httpredir.debian.org/debian sid/main amd64 python-openssl all 
16.0.0-1 [43.0 kB]
  Get:19 http://httpredir.debian.org/debian sid/main amd64 python-attr all 
15.2.0-1 [11.2 kB]
  Get:20 http://httpredir.debian.org/debian sid/main amd64 
python-pyasn1-modules all 0.0.7-0.1 [21.5 kB]
  Get:21 http://httpredir.debian.org/debian sid/main amd64 
python-service-identity all 16.0.0-2 [9350 B]
  Get:22 http://httpredir.debian.org/debian sid/main amd64 python-twisted-core 
all 16.1.1-1 [1952 kB]
  Fetched 31.8 MB in 0s (39.9 MB/s)
  Selecting previously unselected package python-all.
  (Reading database ... 
(Reading database ... 5%
(Reading database ... 10%
(Reading database ... 15%
(Reading database ... 20%
(Reading database ... 25%
(Reading database ... 30%
(Reading database ... 35%
(Reading 

Bug#822179: xorg: X.Org X Server starts normally, crashes with Segmentation fault on starting any application

[Emilio Pozuelo Monfort]

On 23/04/16 17:27, James Clarke wrote:
>> On 23 Apr 2016, at 15:03, James Clarke  wrote:
>>
>> Hi,
>>> On 23 Apr 2016, at 14:55, Samuel Thibault >> > wrote:
>>>
>>> Hello,
>>>
>>> James Clarke, on Sat 23 Apr 2016 14:44:52 +0100, wrote:
 I have attached a proposed patch which ensures XFD_SETSIZE never
 exceeds FD_SETSIZE.
>>>
>>> Did you test it?
>>
>> Not this specific version, but changing it to 256 directly in the header.
>> I’m about to test this exact patch.
> 
> I rebuilt xorg-server-2_1.18.3-1 having patched Xpoll.h with this exact
> patch (with s/Xpoll.h.in/Xpoll.h, of course) and can confirm it works.

Great. Please send the patch to xorg-de...@lists.x.org

Cheers,
Emilio

Bug#821022: python-lldb-3.8: Broken symlinks _lldb.so and libLLVM-3.8.0.so.1

[Graham Inggs]

Confirming.  Python-lldb-3.8 has missing dependencies and some broken symlinks.

After installing python-lldb-3.8, I needed to take the steps below (as
root) before I could 'import lldb' successfully.

apt-get install lldb-3.8 liblldb-3.8 liblldb-3.8-dev

cd /usr/lib/llvm-3.8/lib/python2.7/site-packages/lldb
rm libLLVM-3.8.0.so.1
ln -s ../../../../../x86_64-linux-gnu/libLLVM-3.8.0.so.1 libLLVM-3.8.0.so.1
rm libLLVM-3.8.so.1
ln -s ../../../../../x86_64-linux-gnu/libLLVM-3.8.0.so.1 libLLVM-3.8.so.1
rm _lldb.so
ln -s ../../../../../x86_64-linux-gnu/liblldb-3.8.so _lldb.so

Bug#807878: gnome: Gnome freezes when root windows are open on user screen.

[Vlad Orlov]

Hi,


> I opened some user apps: smplayer playing radio, system monitor, gnome 
> terminal and
> two root terminals and synaptic. I used 3 workspaces and I could move freely 
> from one
> another, either hitting the upper left hand corner or clicking on Activities.

According to some comments from other reporters [1][2], you might need to run 
some
dconf-using app in these root terminals.


[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=732209#15
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=767173#20

Bug#822419: mirror listing update for miroir.vbrunet.eu

[brunet victorien]

Package: mirrors
Severity: minor
User: mirr...@packages.debian.org
Usertags: mirror-list

Submission-Type: update
Site: miroir.vbrunet.eu
Aliases: www.miroir.vbrunet.eu
Type: leaf
Archive-architecture: ALL amd64 arm64 armel armhf hurd-i386 i386 kfreebsd-amd64 
kfreebsd-i386 mips mips64el mipsel powerpc ppc64el s390x 
Archive-ftp: /debian/
Archive-http: /debian/
CDImage-ftp: /debian-cd/
CDImage-http: /debian-cd/
IPv6: no
Archive-upstream: syncproxy.eu.debian.org
CDImage-upstream: cdimage.debian.org
Updates: four
Maintainer: brunet victorien 
Country: FR France
Location: fr

Bug#741196: License incompatibility below RC threshold

[Niels Thykier]

Francesco Poli:
> On Sat, 23 Apr 2016 15:34:44 + Niels Thykier wrote:
> 
>> Francesco Poli:
>>> [...]
>>
>> Hi,
> 
> Hello Niels,
> thanks for your prompt reply.
> 
>>
>> AFAICT, the FTP masters are the authoritative source on dealing with
>> license issues and they have not yet made a ruling.
> 
> Yes, and that's the problem: they seem to never answer, no matter who
> and when tries to ask for a reply.
> 

Sorry, but I cannot help with that part. :-/  Though please note that
silence might not be absence of progress.  As I recall, they were
completely silent during the zfs/linux license issue despite working on
it.  Can't say if that is an apt comparison though (I don't usually deal
with licensing issues).

> Am I writing to the right e-mail address?
> I originally wrote to  (which is listed in
> ), but I see that you wrote
> to .
> Which one should I use?
> 

To be honest, I have no idea where ftpmas...@ftp-master.debian.org got
from.  I do not remember adding it manually.

>>
>>  * I see no reason for the Release Team to be involving at this point as
>>we cannot answer this inquiry.
>>
>> However, should the FTP masters rule it to be a license incompatibility,
>> please do not hesitate to bump the severity to RC.
> 
> Could someone prod the FTP masters to analyze the issue and provide an
> authoritative statement?
> 
> Thanks for your time.
> 
> 

It seems to me that you just did?

Thanks,
~Niels





signature.asc
Description: OpenPGP digital signature

Bug#822420: mirror listing update for miroir.vbrunet.eu

[brunet victorien]

Package: mirrors
Severity: minor
User: mirr...@packages.debian.org
Usertags: mirror-list

Submission-Type: update
Site: miroir.vbrunet.eu
Aliases: www.miroir.vbrunet.eu
Type: leaf
Archive-architecture: ALL amd64 arm64 armel armhf hurd-i386 i386 kfreebsd-amd64 
kfreebsd-i386 mips mips64el mipsel powerpc ppc64el s390x 
Archive-ftp: /debian/
Archive-http: /debian/
Archive-rsync: debian/
CDImage-ftp: /debian-cd/
CDImage-http: /debian-cd/
IPv6: no
Archive-upstream: syncproxy.eu.debian.org
CDImage-upstream: cdimage.debian.org
Updates: four
Maintainer: brunet victorien 
Country: FR France
Location: fr

Bug#822266: paraview: FTBFS on kfreebsd-* but previously did: dilib.c:5462:18: error: storage size of 'mytime' isn't known

[Tobias Frost]

On Sat, 23 Apr 2016 13:37:30 +0200 Tobias Frost 
wrote:
> Package: src:paraview
> Followup-For: Bug #822266
> 
> The package builds on the porterboxes...
> So, I will do an binary-only upload directly from there to decruft
stuff.

strike that, I was fooled by the porterbox (did pull in old source)

But I have a patch I'm currently compiling; if it works, will NMU
tonight.

--
tobi

Bug#772555: untested hacky attempt at using systemctl preset

[Martin Pitt]

Control: tag -1 pending

Hello Raphael,

Raphael Hertzog [2016-03-08 11:12 +0100]:
> Ok. So here's the final patch that I'm now using in Kali. It seems to work
> from the quick tests that I did.

Thank you! This looks good to me, thanks to Andreas and you for
working on this! I also applied your test suite fixes.

Sorry for the delay here. Also, please feel free to push such changes
to git yourself, it's collab-maint after all :-)

Martin

-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)

Bug#822227: e2fsprogs: FTBFS when generating libext2fs.dvi if texlive is installed

[Svante Signell]

On Sat, 2016-04-23 at 22:28 -0400, Theodore Ts'o wrote:
> On Fri, Apr 22, 2016 at 10:58:53AM +0200, Svante Signell wrote:
> > 
> > Source: e2fsprogs
> > Version: 1.43~WIP.2016.03.15-2
> > Severity: important
> > Tags: patch
> > 
> > Hello,
> > 
> > When building e2fsprogs from source having texlive installed, creation of
> > libext2fs.dvi with texi2dvi fails when running pdfTeX the second time (two-
> > stage 
> > compile). This is caused by the ~ character in the source
> > directory: e2fsprogs-
> > 1.43~WIP.2016.03.15, resulting in a compile of the absolute path
> > file/home/user/.../e2fsprogs- 1.43~WIP.2016.03.15/doc/libext2fs.texinfo.
> Exactly which command is failing?  It works for me, and so I'm
> wondering if this a version-specific bug in texlive.

In the build below you don't have the ~ character in the absolute path name. In
your build /build/jessie/e2fsprogs-1.43-WIP.2016.03.15/build/doc you have a
minus sign, not ~. Additionally 

> 
> Script started on Sat 23 Apr 2016 10:27:46 PM EDT
> Top-level shell (parent script)
> 
> ]0;tytso@closure:/build/jessie/e2fsprogs-1.43-WIP.2016.03.15/build/doc @closure> {/build/jessie/e2fsprogs-1.43-WIP.2016.03.15/build/doc}  
> 501% make
>   MAKEINFO libext2fs.info
>   TEXI2DVI libext2fs.dvi
> This is pdfTeX, Version 3.14159265-2.6-1.40.16 (TeX Live 2015/Debian)
> (preloaded format=etex)
>  restricted \write18 enabled.
> entering extended mode
> (./../../doc/libext2fs.texinfo

Here the path is relative, and that works fine, also with a ~ character in the
directory path name.

> (/build/jessie/e2fsprogs-1.43-WIP.2016.03.15/doc/texinfo.tex
> Loading texinfo [version 2006-02-13.16]: Basics, pdf, fonts, page headings,
> tables, conditionals, indexing, sectioning, toc, environments, defuns, macros,
> cross references, insertions,
> (/usr/share/texlive/texmf-dist/tex/generic/epsf/epsf.tex
> This is `epsf.tex' v2.7.4 <14 February 2011>
...
> Output written on libext2fs.dvi (24 pages, 75372 bytes).
> Transcript written on libext2fs.log.
> This is pdfTeX, Version 3.14159265-2.6-1.40.16 (TeX Live 2015/Debian)
> (preloaded format=etex)
>  restricted \write18 enabled.
> entering extended mode
> (./../../doc/libext2fs.texinfo
> (/build/jessie/e2fsprogs-1.43-WIP.2016.03.15/doc/texinfo.tex
> Loading texinfo [version 2006-02-13.16]: Basics, pdf, fonts, page headings,
> tables, conditionals, indexing, sectioning, toc, environments, defuns, macros,
> cross references, insertions,
...
> Output written on libext2fs.dvi (26 pages, 102992 bytes).
> Transcript written on libext2fs.log.

I get:

texi2dvi /home/srs/Hurd/DEBs/linux_DEBs/e2fsprogs/e2fsprogs-
1.43~WIP.2016.03.15/doc/libext2fs.texinfo
This is pdfTeX, Version 3.14159265-2.6-1.40.16 (TeX Live 2015/Debian) (preloaded
format=etex)
 restricted \write18 enabled.
entering extended mode

(/home/.../e2fsprogs-1.43~WIP.2016.03.15/doc/libext2fs.texinfo



(/home/.../e2fsprogs-1.43~WIP.2016.03.15/debian/BUILD-STD/doc/libext2fs.toc [-
1]) [-2] )
(see the transcript file for additional information)
Output written on libext2fs.dvi (24 pages, 75372 bytes).
Transcript written on libext2fs.log.
This is pdfTeX, Version 3.14159265-2.6-1.40.16 (TeX Live 2015/Debian) (preloaded
format=etex)
 restricted \write18 enabled.
entering extended mode
! I can't find file `/home/.../e2fsprogs-1.43'.
 
   \penalty 
~->\penalty 
\@M \ 
<*> .../e2fsprogs-1.43~
                       WIP.2016.03.15/doc/libext2...

(Press Enter to retry, or Control-D to exit)
Please type another input file name: 

Here the ~ character is take literally, causing the build failure.

> 502% dpkg -l texlive
...
> ii  texlive 2015.20160320-1  all  TeX Live: A
> decent selection of the TeX Live packag

I've tried with both 2015.20160320-1 and 2015.20160223-1, same problem.

Bug#822421: python-jswebkit: remove from Debian?

[Emilio Pozuelo Monfort]

Package: python-jswebkit
Version: 0.0.3-2
Severity: important

Hi,

python-jswebkit are bindings for the old, deprecated, to-be-removed
webkit1. Given there are newer bindings available for both webkit1
and webkit2 using GObject introspection (gir1.2-javascriptcoregtk-3.0
and gir1.2-javascriptcoregtk-4.0 respectively), I think we should
drop python-jswebkit.

Thoughts?

If I don't hear back from you I'll make this an RM bug.

Cheers,
Emilio

Bug#607032: FTBFS [hppa, mips]: cannot stat `./javadoc/stylesheet.css': No such file or directory

[Tobias Frost]

Source: openvrml
Followup-For: Bug #607032

I think this is due to gcj creates javadoc differently.

I do have patch, currently being tested:
Move -doc generation to Build-Indep; at least currently this will fix this,
as the doc packages won't be built on those archs.

Will follow up later.

-- 
tobi


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

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

Bug#822422: arandr: some confusion with xrandr mode None

[Eduard Bloch]

Package: arandr
Version: 0.1.9-1
Severity: normal

Dear Maintainer,

   * What led up to the situation?

Connect a projector via HDMI, projector still not powered on

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

Started arandr, pushed Apply button

   * What was the outcome of this action?

Error message:

XRandR failed:
XRandR returned error code 1: xrandr: cannot find mode None

   * What outcome did you expect instead?

No error message, but no changes either.

I also tried to save a profile without powering on the device, getting
following exception:


  File "/usr/lib/python2.7/dist-packages/screenlayout/gui.py", line 64, in 
wrapper
return function(*args_out)
  File "/usr/lib/python2.7/dist-packages/screenlayout/gui.py", line 249, in 
do_save_as
self.widget.save_to_file(f, self.filetemplate)
  File "/usr/lib/python2.7/dist-packages/screenlayout/widget.py", line 114, in 
save_to_file
self.load_from_file(file)
  File "/usr/lib/python2.7/dist-packages/screenlayout/widget.py", line 88, in 
load_from_file
template = self._xrandr.load_from_string(data)
  File "/usr/lib/python2.7/dist-packages/screenlayout/xrandr.py", line 87, in 
load_from_string
self._load_from_commandlineargs(lines[xrandrlines[0]].strip())
  File "/usr/lib/python2.7/dist-packages/screenlayout/xrandr.py", line 121, in 
_load_from_commandlineargs
raise FileLoadError("Not a known mode: %s"%p[1])
screenlayout.auxiliary.FileLoadError: Not a known mode: None

FYI, xrandr verbose output attached:

Screen 0: minimum 320 x 200, current 3286 x 1080, maximum 16384 x 16384
LVDS connected primary 1366x768+0+0 (0x55) normal (normal left inverted right x 
axis y axis) 256mm x 144mm
Identifier: 0x51
Timestamp:  31002557
Subpixel:   horizontal rgb
Gamma:  1.0:1.0:1.0
Brightness: 1.0
Clones:
CRTC:   0
CRTCs:  0 1
Transform:  1.00 0.00 0.00
0.00 1.00 0.00
0.00 0.00 1.00
   filter: 
EDID: 
00000dae1811
1d150103801a0e780a69659657528f27
2250540001010101010101010101
010101010101bc1b568650001430291b
3490101800fe004e3131
364247452d4c33320a2000fe0043
4d4e0a20202020202020202000fe
004e3131364247452d4c33320a200038
scaling mode: Full 
supported: None, Full, Center, Full aspect
  1366x768 (0x55) 71.000MHz -HSync -VSync *current +preferred
h: width  1366 start 1407 end 1434 total 1500 skew0 clock  47.33KHz
v: height  768 start  771 end  775 total  788   clock  60.07Hz
  1280x720 (0x56) 74.500MHz -HSync +VSync
h: width  1280 start 1344 end 1472 total 1664 skew0 clock  44.77KHz
v: height  720 start  723 end  728 total  748   clock  59.86Hz
  1152x768 (0x57) 71.750MHz -HSync +VSync
h: width  1152 start 1216 end 1328 total 1504 skew0 clock  47.71KHz
v: height  768 start  771 end  781 total  798   clock  59.78Hz
  1024x768 (0x58) 63.500MHz -HSync +VSync
h: width  1024 start 1072 end 1176 total 1328 skew0 clock  47.82KHz
v: height  768 start  771 end  775 total  798   clock  59.92Hz
  800x600 (0x59) 38.250MHz -HSync +VSync
h: width   800 start  832 end  912 total 1024 skew0 clock  37.35KHz
v: height  600 start  603 end  607 total  624   clock  59.86Hz
  848x480 (0x5a) 31.500MHz -HSync +VSync
h: width   848 start  872 end  952 total 1056 skew0 clock  29.83KHz
v: height  480 start  483 end  493 total  500   clock  59.66Hz
  720x480 (0x5b) 26.750MHz -HSync +VSync
h: width   720 start  744 end  808 total  896 skew0 clock  29.85KHz
v: height  480 start  483 end  493 total  500   clock  59.71Hz
  640x480 (0x5c) 23.750MHz -HSync +VSync
h: width   640 start  664 end  720 total  800 skew0 clock  29.69KHz
v: height  480 start  483 end  487 total  500   clock  59.38Hz
HDMI-0 disconnected 1920x1080+1366+0 (0x4cb) normal (normal left inverted right 
x axis y axis) 0mm x 0mm
Identifier: 0x52
Timestamp:  31002557
Subpixel:   horizontal rgb
Gamma:  1.0:1.0:1.0
Brightness: 1.0
Clones:
CRTC:   1
CRTCs:  0 1
Transform:  1.00 0.00 0.00
0.00 1.00 0.00
0.00 0.00 1.00
   filter: 
output_csc: bypass 
supported: bypass, tvrgb, ycbcr601, ycbcr709
audio: auto 
supported: off, on, auto
scaling mode: None 
supported: None, Full, Center, Full aspect
dither: off 
supported: of

Bug#607032: openvrml: diff for NMU version 0.18.9-7.2

[Tobias Frost]

Hi,
this is the current state of my the patch.
As said, currently being tested, so no tag patch yet

Regards.
diff -u openvrml-0.18.9/debian/changelog openvrml-0.18.9/debian/changelog
--- openvrml-0.18.9/debian/changelog
+++ openvrml-0.18.9/debian/changelog
@@ -1,3 +1,11 @@
+openvrml (0.18.9-7.2) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Move the documentation build to Build-Indep, as on the gcj
+based archs this will fail.
+
+ -- Tobias Frost   Sun, 24 Apr 2016 09:09:09 +0200
+
 openvrml (0.18.9-7.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -u openvrml-0.18.9/debian/control openvrml-0.18.9/debian/control
--- openvrml-0.18.9/debian/control
+++ openvrml-0.18.9/debian/control
@@ -11,7 +11,9 @@
libboost-thread-dev, libboost-filesystem-dev, libgtk2.0-dev,
libxmu-dev, procps, graphviz, libgnomeui-dev, libglade2-dev,
libcurl4-gnutls-dev, libgtkglext1-dev, libltdl-dev,
-   libdbus-glib-1-dev, ghostscript, doxygen-latex
+   libdbus-glib-1-dev
+Build-Depends-Indep:
+   ghostscript, doxygen-latex
 Standards-Version: 3.9.5
 Vcs-Git: git://git.debian.org/git/collab-maint/openvrml.git
 Vcs-Browser: http://git.debian.org/?p=collab-maint/openvrml.git;a=summary
diff -u openvrml-0.18.9/debian/rules openvrml-0.18.9/debian/rules
--- openvrml-0.18.9/debian/rules
+++ openvrml-0.18.9/debian/rules
@@ -47,14 +47,16 @@
LIBS="-lboost_system" BOOST_LIB_SUFFIX="" ./configure $(confflags)
touch configure-stamp
 
+build-indep: build-stamp
+   $(MAKE) -C doc html-local
+
 build: build-arch build-indep
 build-arch: build-stamp
-build-indep: build-stamp
 build-stamp: configure-stamp 
dh_testdir
$(MAKE)
#Shouldn't be necessary but upstream svn doesn't have the docs built.
-   $(MAKE) -C doc html-local
+   #$(MAKE) -C doc html-local
touch build-stamp
 
 clean:

Bug#822415: [src:linux] Kernel 4.5 breaks OpenAFS client module build

[Ben Hutchings]

Control: reassign -1 src:openafs 1.6.17-2
Control: severity -1 serious

On Sun, 2016-04-24 at 08:56 +0200, Dirk Heinrichs wrote:
> Package: src:linux
> Version: 4.5.0-1
> Severity: important
> 
> --- Please enter the report below this line. ---
> OpenAFS client kernel module (openafs-modules-dkms) don't build for kernel 
> 4.5:
[...]

But that's not a bug in the kernel, so reassigning this.

Ben.

-- 
Ben Hutchings
Larkinson's Law: All laws are basically false.

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

Bug#822423: debhelper: is there any way to reduce the impact of the dh-autoreconf dependency?

[Stephen Kitt]

Package: debhelper
Version: 9.20160403
Severity: wishlist

Dear Maintainer,

With the introduction of the dependency from debhelper to
dh-autoreconf, non-development systems with debhelper installed (in my
case, because of equivs) suddenly end up pulling in the autotools
suite and gcc. That’s “only” ~230MB but it seems unfortunate... It’s
not directly relevant since the correct solution is to stop installing
equivs, but many companies forbid installing gcc on servers. (And no,
I’m not running testing on servers.)

Is there any way of reducing the dependency’s impact? Or is it not
worth it?

Regards,

Stephen


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

Kernel: Linux 4.4.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)

Versions of packages debhelper depends on:
ii  autotools-dev20150820.1
ii  binutils 2.26-8
ii  dh-autoreconf12
ii  dh-strip-nondeterminism  0.016-1
ii  dpkg 1.18.5
ii  dpkg-dev 1.18.4
ii  file 1:5.25-2
ii  libdpkg-perl 1.18.4
ii  man-db   2.7.5-1
ii  perl 5.22.1-10
ii  po-debconf   1.0.19

debhelper recommends no packages.

Versions of packages debhelper suggests:
ii  dh-make  2.201605

-- no debconf information

Bug#822174: exim4: Please add hosts_require_tls = REMOTE_SMTP_SMARTHOST_HOSTS_REQUIRE_TLS

[Andreas Metzler]

Control: tags -1 pending

On 2016-04-21 Samuel Thibault  wrote:
> Package: exim4
> Version: 4.87-1
> Severity: normal
> Tags: patch

> Hello,

> Due to network hickups, some of my mails couldn't go through TLS to my
> smarthost, and exim4 reverted to an unencrypted send:
[...]
> And thus I got a bounce.  I need to prevent that by setting
> hosts_require_tls, but this doesn't seem to be supported by the debian
> packaging. More precisely, I would need the attached patch to be
> applied.

Applied, since TLS SMTP delivery seems to finally have made headway.

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Bug#819247: wheezy-pu: package java-common/0.47

[Julien Cristau]

On Sat, Apr 23, 2016 at 15:41:41 +0200, Markus Koschany wrote:

> Am 23.04.2016 um 13:42 schrieb Julien Cristau:
> > On Sat, Apr 23, 2016 at 10:56:33 +0200, Markus Koschany wrote:
> > 
> >> Hello,
> >>
> >> what are your thoughts about this bug? I intend to upload java-common
> >> myself on the 26 June but I think it would still be preferable to fix
> >> the other packages with a point update.
> >>
> >> I saw that Rene intends to fix libreoffice-nlpsolver (#819443) himself.
> >> Of course that's fine with me, just wanted to let you know that I'm
> >> aware of it.
> >>
> > Is there a particular reason these changes shouldn't be done in
> > wheezy-lts rather than wheezy proper?
> 
> There are mainly two reasons:
> 
>  - Dealing with those bugs in Wheezy proper would be the correct way of
>fixing them IMO. Actually they are not security related but are
>already a concern for Wheezy users. A fix would allow users to
>choose a different Java runtime and would not force them to install
>OpenJDK 6 or a non-free alternative. It will only become a matter of
>security when the support for OpenJDK 6 is discontinued in Wheezy
>LTS in two months.
> 
As long as openjdk-6 is still supported they're not nearly serious
enough for a (old)stable update though...

>  - wheezy-proposed-updates would be a sensible way to test the new
>packages. I don't expect any complications with those packages
>because we only change runtime dependencies but it would be
>a less abrupt change than uploading to wheezy-lts later.
> 
I don't understand the "only" in "we only change runtime dependencies".
I'd expect that changing runtime dependencies means you need to test all
those packages with openjdk7 and make sure they still work?

Cheers,
Julien

Bug#822424: ketm: wasteful CPU usage

[Markus Koschany]

Source: ketm
Version: 0.0.6-22
Severity: normal

ketm is very wasteful and consumes a lot of CPU time. This is most
likely related to the game's main loop and how often the screen is
redrawn. If the game ever wants to leave the alpha stage, this should
be fixed.

Markus

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

Kernel: Linux 4.5.0-1-amd64 (SMP w/2 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: unable to detect

Bug#822425: [appstream] "double free or corruption" when called from "apt update"

[Dietrich Brunn]

Package: appstream
Version: 0.9.4-1
Severity: critical

--- Please enter the report below this line. ---
Dear maintainer,
"apt update" crashes with the following backtrace  message:

*** Error in `appstreamcli': double free or corruption (fasttop): 
0x03494470 *** 

...

E: Problem executing scripts APT::Update::Post-Invoke-Success 'if /usr/bin/test 
-w 
/var/cache/app-info -a -e /usr/b


The same behavior can be reproduced when calling "appstreamcli refresh" 
directly. I 
attached the resulting trace.

Cheers, dietrich



--- System information. ---
Architecture: amd64
Kernel:   Linux 4.5.0-1-amd64

Debian Release: stretch/sid
  500 unstableftp.de.debian.org 
  500 testing ftp.de.debian.org 
  500 stable  ftp.de.debian.org 
1 experimentalftp.de.debian.org 

--- Package information. ---
Package's Depends field is empty.

Package's Recommends field is empty.

Package's Suggests field is empty.
root@Rechenknecht:~# appstreamcli refresh 
*** Error in `appstreamcli': double free or corruption (fasttop): 
0x0204f320 ***
=== Backtrace: =
/lib/x86_64-linux-gnu/libc.so.6(+0x71fe5)[0x7f695407efe5]
/lib/x86_64-linux-gnu/libc.so.6(+0x77936)[0x7f6954084936]
/lib/x86_64-linux-gnu/libc.so.6(+0x7811e)[0x7f695408511e]
/usr/lib/x86_64-linux-gnu/libappstream.so.3(as_component_complete+0x439)[0x7f6954ff7599]
/usr/lib/x86_64-linux-gnu/libappstream.so.3(as_data_pool_update+0x44a)[0x7f6954ff878a]
/usr/lib/x86_64-linux-gnu/libappstream.so.3(as_cache_builder_refresh+0x1c2)[0x7f6954fedaf2]
appstreamcli(ascli_refresh_cache+0x12e)[0x404a1e]
appstreamcli(as_client_run+0x6fb)[0x403d2b]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf0)[0x7f695402d610]
appstreamcli(_start+0x29)[0x403559]
=== Memory map: 
0040-00408000 r-xp  08:01 132714 
/usr/bin/appstreamcli
00607000-00608000 r--p 7000 08:01 132714 
/usr/bin/appstreamcli
00608000-00609000 rw-p 8000 08:01 132714 
/usr/bin/appstreamcli
00df8000-025b2000 rw-p  00:00 0  [heap]
7f694c00-7f694c021000 rw-p  00:00 0 
7f694c021000-7f695000 ---p  00:00 0 
7f6950293000-7f69502b5000 r--s  08:01 394202 
/usr/share/mime/mime.cache
7f69502b5000-7f69502b9000 r-xp  08:01 2359459
/lib/x86_64-linux-gnu/libuuid.so.1.3.0
7f69502b9000-7f69504b8000 ---p 4000 08:01 2359459
/lib/x86_64-linux-gnu/libuuid.so.1.3.0
7f69504b8000-7f69504b9000 r--p 3000 08:01 2359459
/lib/x86_64-linux-gnu/libuuid.so.1.3.0
7f69504b9000-7f69504ba000 rw-p 4000 08:01 2359459
/lib/x86_64-linux-gnu/libuuid.so.1.3.0
7f69504ba000-7f69504dc000 r-xp  08:01 2364276
/lib/x86_64-linux-gnu/liblzma.so.5.0.0
7f69504dc000-7f69506db000 ---p 00022000 08:01 2364276
/lib/x86_64-linux-gnu/liblzma.so.5.0.0
7f69506db000-7f69506dc000 r--p 00021000 08:01 2364276
/lib/x86_64-linux-gnu/liblzma.so.5.0.0
7f69506dc000-7f69506dd000 rw-p 00022000 08:01 2364276
/lib/x86_64-linux-gnu/liblzma.so.5.0.0
7f69506dd000-7f6951f93000 r-xp  08:01 133802 
/usr/lib/x86_64-linux-gnu/libicudata.so.55.1
7f6951f93000-7f6952192000 ---p 018b6000 08:01 133802 
/usr/lib/x86_64-linux-gnu/libicudata.so.55.1
7f6952192000-7f6952193000 r--p 018b5000 08:01 133802 
/usr/lib/x86_64-linux-gnu/libicudata.so.55.1
7f6952193000-7f6952194000 rw-p 018b6000 08:01 133802 
/usr/lib/x86_64-linux-gnu/libicudata.so.55.1
7f6952194000-7f6952313000 r-xp  08:01 140259 
/usr/lib/x86_64-linux-gnu/libicuuc.so.55.1
7f6952313000-7f6952513000 ---p 0017f000 08:01 140259 
/usr/lib/x86_64-linux-gnu/libicuuc.so.55.1
7f6952513000-7f6952523000 r--p 0017f000 08:01 140259 
/usr/lib/x86_64-linux-gnu/libicuuc.so.55.1
7f6952523000-7f6952524000 rw-p 0018f000 08:01 140259 
/usr/lib/x86_64-linux-gnu/libicuuc.so.55.1
7f6952524000-7f6952528000 rw-p  00:00 0 
7f6952528000-7f695277a000 r-xp  08:01 133893 
/usr/lib/x86_64-linux-gnu/libicui18n.so.55.1
7f695277a000-7f695297a000 ---p 00252000 08:01 133893 
/usr/lib/x86_64-linux-gnu/libicui18n.so.55.1
7f695297a000-7f6952989000 r--p 00252000 08:01 133893 
/usr/lib/x86_64-linux-gnu/libicui18n.so.55.1
7f6952989000-7f695298a000 rw-p 00261000 08:01 133893 
/usr/lib/x86_64-linux-gnu/libicui18n.so.55.1
7f695298a000-7f695298c000 r-xp  08:01 2363841
/lib/x86_64-linux-gnu/libdl-2.22.so
7f695298c000-7f6952b8c000 ---p 2000 08:01 2363841
/lib/x86_64-linux-gnu/libdl-2.22.so
7f6952b8c000-7f6952b8d000 r--p 2000 08:01 

Bug#822426: libncursesw5: wget_wch() returning KEY_CODE_YES with xterm Ctrl/Alt/Shift keys outside the range KEY_MIN <= key <= KEY_MAX

[Kevin Lamonte]

Package: libncursesw5
Version: 5.9+20140913-1+b1
Severity: normal

Dear Maintainer,

I am the author of a curses-based terminal emulator, and noticed that
wget_wch() is returning KEY_CODE_YES with values that are outside the
range KEY_MIN and KEY_MAX.  This behavior is inconsistent with the
documented API.

I have confirmed that xterm is doing the right thing, e.g.
   PgUp   = "CSI 5 ~"
   Ctrl-PgUp  = "CSI 5;5 ~"
   Alt-PgUp   = "CSI 5;3 ~"

Keystrokes and values I have seen (these are decimal values, not
octal) returned from wget_wch() include:
 
538 == Alt-Ins
517 == Alt-Del
533 == Alt-Home
528 == Alt-End
540 == Ctrl-Ins
519 == Ctrl-Del
555 == Ctrl-PgUp
550 == Ctrl-PgDn
535 == Ctrl-Home
530 == Ctrl-End
553 == Shift-PgUp
548 == Shift-PgDn

I can replicate this behavior on xterm, xfce-terminal, and konsole.  I
suspect that this might be terminfo rather than ncurses.

I have put a small test program to demonstrate this behavior over at
http://qodem.sf.net/misc/ncurses_wget_wch_tester.c .  'gcc -o test
ncurses_wget_wch_tester.c -lncursesw' builds it.  Run it, press Ctrl-C
to exit.

I think this behavior started somewhere in Jessie, but possibly
Wheezy.  Between Sarge and Squeeze wget_wch() would return the full
xterm sequence which I could parse myself.

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

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

Versions of packages libncursesw5 depends on:
ii  libc6  2.19-18+deb8u4
ii  libtinfo5  5.9+20140913-1+b1
ii  multiarch-support  2.19-18+deb8u4

Versions of packages libncursesw5 recommends:
ii  libgpm2  1.20.4-6.1+b2

libncursesw5 suggests no packages.

-- no debconf information

Bug#822425: Upgrading to version 0.9.4-2

[Dietrich Brunn]

Dear Maintainer,
updating to  0.9.4-2 resolved the issue. Sorry for the buzz,
dietrich

Bug#811476:

[Simon Bin]

Hi Arthur,

any chance of getting an official jessie update for this?

Bug#765578: vlc: FTBFS on Hurd

[Samuel Thibault]

Control: tags -1 - wontfix
Control: tags -1 + patch

Hello,

We still can't the whole KDE world on hurd-i386 because of vlc not
building, while the remaining proposed patches should really not pose
problem (the controversial part was fixed in glibc). FTR, here are again
the proposed patches:

- hurd_path_max.patch: fixes an occurrence of PATH_MAX the exactly same
  way as it is arealdy done in src/posix/filesystem.c

- hurd_zsh_completion.patch: just tell zsh_completion that the library
  suffix is .so on GNU/Hurd too.

I don't see anything that can be controversial here, could you *please*
apply them, so we can move on?

Samuel
Description: Replace PATH_MAX, unsupported on Hurd, with fixed size as in
 src/posix/filesystem.c
Author: Gabriele Giacone <1o5g4...@gmail.com>
--- a/modules/gui/skins2/src/theme_loader.cpp
+++ b/modules/gui/skins2/src/theme_loader.cpp
@@ -509,7 +509,10 @@ int tar_extract_all( TAR *t, char *prefi
 union tar_buffer buffer;
 int   len, err, getheader = 1, remaining = 0;
 FILE  *outfile = NULL;
-char  fname[BLOCKSIZE + PATH_MAX];
+
+long path_max = pathconf (".", _PC_PATH_MAX);
+size_t maxsize = (path_max == -1 || path_max > 4096) ? 4096 : path_max;
+char  fname[BLOCKSIZE + maxsize];
 
 while( 1 )
 {
--- a/extras/analyser/zsh_completion.sh.orig2015-08-28 21:34:50.0 
+
+++ b/extras/analyser/zsh_completion.sh 2015-08-28 21:35:10.0 +
@@ -13,7 +13,7 @@
 *cygwin*|*mingw*)
 SUFFIX=dll
 ;;
-*linux*|*bsd*)
+*linux*|*bsd*|*gnu*)
 SUFFIX=so
 ;;
 *)

Bug#822427: pristine-tar: should create reproducible deltas

[Andreas Beckmann]

Package: pristine-tar
Version: 1.33
Severity: normal

Hi,

pristine-tar gendelta tarball.tar.gz delta1
pristine-tar gendelta tarball.tar.gz delta2

produces two different deltas, mainly due to different timestamps.
It would be great, if pristine-tar could take this into account and
create more easily reproducible deltas.

One would be to use gzip -n to omit the timestamp when compressing the
delta data.
Another problem are the timestamps inside the (delta) tarball.
The input tarball should have enough sources to provide a usable
timestamp:
* the gzip timestamp (unless created with gzip -n)
* the modification time of the newest file/directory inside the tarball
(the filesystem timestamp of that tarball is not a usable option)
With a recent tar, there is a --mtime option that could be used while
creating the delta tarball.


Andreas

PS: hmm, using pristine-tar again on the delta it created ... no I'm not
going to explore this idea :-)

Bug#819247: wheezy-pu: package java-common/0.47

[Markus Koschany]

Am 24.04.2016 um 11:49 schrieb Julien Cristau:
> On Sat, Apr 23, 2016 at 15:41:41 +0200, Markus Koschany wrote:
> 
>> Am 23.04.2016 um 13:42 schrieb Julien Cristau:
>>> On Sat, Apr 23, 2016 at 10:56:33 +0200, Markus Koschany wrote:
>>>
 Hello,

 what are your thoughts about this bug? I intend to upload java-common
 myself on the 26 June but I think it would still be preferable to fix
 the other packages with a point update.

 I saw that Rene intends to fix libreoffice-nlpsolver (#819443) himself.
 Of course that's fine with me, just wanted to let you know that I'm
 aware of it.

>>> Is there a particular reason these changes shouldn't be done in
>>> wheezy-lts rather than wheezy proper?
>>
>> There are mainly two reasons:
>>
>>  - Dealing with those bugs in Wheezy proper would be the correct way of
>>fixing them IMO. Actually they are not security related but are
>>already a concern for Wheezy users. A fix would allow users to
>>choose a different Java runtime and would not force them to install
>>OpenJDK 6 or a non-free alternative. It will only become a matter of
>>security when the support for OpenJDK 6 is discontinued in Wheezy
>>LTS in two months.
>>
> As long as openjdk-6 is still supported they're not nearly serious
> enough for a (old)stable update though...
> 
>>  - wheezy-proposed-updates would be a sensible way to test the new
>>packages. I don't expect any complications with those packages
>>because we only change runtime dependencies but it would be
>>a less abrupt change than uploading to wheezy-lts later.
>>
> I don't understand the "only" in "we only change runtime dependencies".
> I'd expect that changing runtime dependencies means you need to test all
> those packages with openjdk7 and make sure they still work?

Sorry, I can't follow you here. Of course those packages were tested
against OpenJDK 7 but this isn't really a counter-argument against
updating the packages in Wheezy before Wheezy LTS starts. The intention
was to fix those bugs as quickly as possible, if they need fixing anyway.

Ok nevermind, it appears to me that you are rather reluctant to grant
upload permissions. One month ago I thought that fixing those issues
before Wheezy LTS would be a win-win situation for everyone, it seems I
was wrong. I'll take care of it myself, feel free to close this bug report.

Regards,

Markus



signature.asc
Description: OpenPGP digital signature

Bug#822236: vDSO is not in effect in static linked executable on jessie

[Aurelien Jarno]

control: tag -1 + moreinfo

On 2016-04-22 11:11, Mattia Rizzolo wrote:
> control: reassign -1 libc6  2.19-18+deb8u4
> 
> On Fri, Apr 22, 2016 at 06:27:34PM +0800, jian wang wrote:
> > Package: lib6
> 
> lost a 'c' :)
> reassigning.
> 
> > Version: 2.19-18+deb8u4
> > Severity: important
> > 
> > vDSO is not in effect in static linked executable on jessie. This is
> > not the case with wheezy.
> > 
> > We build binary to run on both wheezy and jessie, so -static. When
> > building platform is wheezy, vdso works fine, but jessie the opposite.
> > 
> > This leads to performance hit. Unfortunately, we use g++ 4.9 for some
> > application, so wheezy can't be used as build platform.

There is not of information about your environment, so given what you
describe, it seems you are using an i386 installation.

The vDSO support requires at least a i686 CPU, while Debian i386 targets
i586. When using dynamic linking, one can install libc6-i686 which
provides an i686 optimized version of the libc, therefore with vDSO
support. It is automatically loaded if the CPU supports it.

In your case, given you use static linking, the i586 version of the libc
is used, and it therefore doesn't support vDSO . That is true on wheezy,
jessie, stretch, sid. I don't believe this is a regression, and in
addition I can't reproduce it.

Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net


signature.asc
Description: PGP signature

Bug#821457: gnutls28: FTBFS on amd64: killed after 150 minutes of inactivity during x509-auth.scm test

[Simon McVittie]

On Sat, 23 Apr 2016 at 16:06:02 +0200, Andreas Metzler wrote:
> FWIW I cannot reproduce this, while I still can easily see #805863.

This seems to be intermittent even with the same buildd. binet
timed out once for 3.4.11-3, then built it successfully when retried:
https://buildd.debian.org/status/logs.php?pkg=gnutls28&arch=amd64
https://buildd.debian.org/status/package.php?p=gnutls28

> Given the lack of progress I am probably going to drop gnutls guile
> bindings.

I think that's a good idea. Better to sacrifice what's presumably a
rarely-used feature than to hold everything up.

S

Bug#822391: wmwave: FTBFS: undefined reference to `iw_get_range_info'

[Guido Günther]

reassign 822391 wireless-tools
retitle 822391 wireless-tools: Broken symlink in dev package
affects 822391 wmwave
thanks

Hi,
the dev packages symlink is broken since the lib is in /lib/ not /usr/lib:

 $ ls -l /usr/lib/x86_64-linux-gnu/libiw.so 
lrwxrwxrwx 1 root root 11 Mär 24 22:32 /usr/lib/x86_64-linux-gnu/libiw.so -> 
libiw.so.30

 $ ls /usr/lib/x86_64-linux-gnu/libiw.so.30
ls: cannot access '/usr/lib/x86_64-linux-gnu/libiw.so.30': No such file or 
directory
 
This causes wmwave to FTBFS.
Cheers,
 -- Guido

Bug#822423: [debhelper-devel] Bug#822423: debhelper: is there any way to reduce the impact of the dh-autoreconf dependency?

[Niels Thykier]

Stephen Kitt:
> Package: debhelper
> Version: 9.20160403
> Severity: wishlist
> 
> Dear Maintainer,
> 
> With the introduction of the dependency from debhelper to
> dh-autoreconf, non-development systems with debhelper installed (in my
> case, because of equivs) suddenly end up pulling in the autotools
> suite and gcc. That’s “only” ~230MB but it seems unfortunate... It’s
> not directly relevant since the correct solution is to stop installing
> equivs, but many companies forbid installing gcc on servers. (And no,
> I’m not running testing on servers.)
> 
> Is there any way of reducing the dependency’s impact? Or is it not
> worth it?
> 
> Regards,
> 
> Stephen
> 
> 
> [...]

Hi,

I am open to suggestions for how to solve it, but at first glance I do
not see one (without neutering compat/10's auto-enabling of dh_autoreconf).

Thanks,
~Niels





signature.asc
Description: OpenPGP digital signature

Bug#822428: dnssec-trigger-panel: options to turn on/off forwarders and to flush the cache

[Paul Wise]

Package: dnssec-trigger
Version: 0.13~svn685-5
Severity: wishlist
File: /usr/bin/dnssec-trigger-panel

Sometimes I am on a network where the DNS server returned by DHCP are
on a crappy router and resolving doesn't always work, resulting in
unbound caching these failures and DNS being broken. For those
situations it would be nice to be able to disable unbound forwarders
and to flush the unbound cache.

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

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

Versions of packages dnssec-trigger depends on:
ii  gir1.2-networkmanager-1.0  1.1.94-1
ii  init-system-helpers1.29
ii  libc6  2.22-6
ii  libgdk-pixbuf2.0-0 2.32.3-2
ii  libglib2.0-0   2.48.0-1
ii  libgtk2.0-02.24.30-1.1
ii  libldns1   1.6.17-8
ii  libssl1.0.21.0.2g-1
ii  python 2.7.11-1
ii  python-gi  3.18.2-2+b1
ii  python-lockfile1:0.12.2-1
ii  unbound1.5.8-1

dnssec-trigger recommends no packages.

dnssec-trigger suggests no packages.

-- no debconf information

-- 
bye,
pabs

https://wiki.debian.org/PaulWise




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

Bug#822362: RFS: mitlm/0.4-2 -- MIT Language Modeling toolkit

[Jakub Wilk]

* Giulio Paci , 2016-04-24, 01:13:

+  * Update Source field in copyright.
Policy §12.5 says that the “the copyright file must say where the 
upstream sources (if any) were obtained”, but they are not available 
(and never were AIUI) at the new location. So I think keeping the 
original Source would be better^Wless wrong, at least until the 
tarball Debian uses appears on the new site.

Reverted the change


But the changelog still say it's been updated.


spellintian(1) says:
debian/patches/1003_make_logger_more_flexible.patch: Allows to -> 
Allows one to

Fixed.


But not documented in the changelog...

--
Jakub Wilk

Bug#822429: plasma-nm: Upstream Bug 362141: Connection editor fails with "connection.gateway-ping-timeout: can not set property: value"

[J Mo]

Package: plasma-nm
Version: 4:5.4.3-1
Severity: normal

Already fixed upstream, this bug is a huge pain. It prevents most configuration 
changes. Even non-configuration changes like changing one letter of the name of 
a connection/entry.

https://bugs.kde.org/show_bug.cgi?id=362141

The user's ~/.xsession.errors log will have something like this:

 New Notification:  "Failed to update connection WHATEVER" 
"connection.gateway-ping-timeout: can not set property: value \"31456224\" of 
type 'guint' is invalid or out of range for property 'gateway-ping-timeout' of 
type 'guint'" -1 & Part of: 0




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

Kernel: Linux 4.5.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 plasma-nm depends on:
ii  libc6   2.22-7
ii  libkf5completion5   5.16.0-1
ii  libkf5configcore5   5.16.0-1
ii  libkf5configwidgets55.16.0-1
ii  libkf5coreaddons5   5.16.0-1
ii  libkf5dbusaddons5   5.16.0-1
ii  libkf5i18n5 5.16.0-1
ii  libkf5iconthemes5   5.16.0-1
ii  libkf5itemviews55.16.0-1
ii  libkf5kdelibs4support5  5.16.0-1
ii  libkf5kiowidgets5   5.16.0-1
ii  libkf5modemmanagerqt6   5.16.0-1
ii  libkf5networkmanagerqt6 5.16.0-1
ii  libkf5notifications55.16.0-1
ii  libkf5service-bin   5.16.0-1
ii  libkf5service5  5.16.0-1
ii  libkf5solid55.16.0-1
ii  libkf5wallet-bin5.16.0-1
ii  libkf5wallet5   5.16.0-1
ii  libkf5widgetsaddons55.16.0-1
ii  libkf5windowsystem5 5.16.0-1
ii  libkf5xmlgui5   5.16.0-1
ii  libopenconnect5 7.06-2+b2
ii  libqt5core5a5.5.1+dfsg-16+b1
ii  libqt5dbus5 5.5.1+dfsg-16+b1
ii  libqt5gui5  5.5.1+dfsg-16+b1
ii  libqt5network5  5.5.1+dfsg-16+b1
ii  libqt5qml5  5.5.1-3
ii  libqt5widgets5  5.5.1+dfsg-16+b1
ii  libqt5xml5  5.5.1+dfsg-16+b1
ii  libstdc++6  5.3.1-15
ii  mobile-broadband-provider-info  20140317-1
ii  network-manager 1.1.94-1
ii  plasma-framework5.16.0-1
ii  qml-module-org-kde-kcoreaddons  5.16.0-1

plasma-nm recommends no packages.

Versions of packages plasma-nm suggests:
ii  network-manager-openconnect  1.2.0-1
ii  network-manager-openvpn  1.2.0-1
pn  network-manager-pptp 
pn  network-manager-vpnc 

-- debconf-show failed

Bug#799619: kio: FTBFS on hurd-i386: warning about posix_fadvise

[Samuel Thibault]

Hello,

Samuel Thibault, on Sun 20 Sep 2015 22:53:07 +0200, wrote:
> kio FTBFS on hurd-i386:
> 
> /«PKGBUILDDIR»/obj-i586-gnu/src/ioslaves/file/../../../../src/ioslaves/file/file.cpp:338:
>  warning: posix_fadvise64 is not implemented and will always fail

This is still a problem with 5.16.0, making basically the whole KDE world
unbuildable on hurd-i386.

> which turns into an error due to -Wl,--fatal-warnings
> 
> This function is actually probed by the CMakefiles, but only with
> check_function_exists.  It happens that the posix_fadvise function is
> provided by glibc as a stub, which always returns ENOSYS.  The fact that
> the function is actually not implemented is announced by the presence
> of #define __stub_posix_fadvise in /usr/include/i386-gnu/gnu/stubs.h
> Autoconf automatically detects that in its ac_fn_c_check_func()
> function, but it seems that cmake unfortunately didn't integrate that
> kind of detection yet into check_function_exists, and thus wrongly
> believes the support is available.  It happens that cmake has a proper
> check_function_exists_glibc function defined in
> ./Utilities/cmlibarchive/build/cmake/CheckFuncs.cmake
> but it doesn't seem to be shipped in the standard cmake. So the
> solutions I see would be:
> 
> - avoid -Wl,--fatal-warnings, since it may actually bring other kinds of
>   unexpected FTBFS along upgrades of gcc or binutils in the future.
> - either to integrate ./Utilities/cmlibarchive/build/cmake/CheckFuncs.cmake
>   into kio's cmake/ directory to be able to call the proper
>   check_function_exists_glibc detection function
> - or to patch over src/ioslaves/file/file.cpp and file_unix.cpp's
>   #if HAVE_FADVISE into #if HAVE_FADVISE && !defined(__hurd__) (but once
>   hurd-i386 gets posix_fadvise support it should get reverted).

So what do you think, how do you prefer to proceed?  The simplest would
be the third solution, as attached.

Also, the symbols file needs to be update, see attached patch.

In the meanwhile, the hurd-i386 port looks in terribly bad shape due to
all the not-rebuilt KDE packages.

Samuel
Kio's check_function_exists_glibc does not actually detect for the presence of
posix_fadvise: it ignores the stubs.h provided by glibc. See #799619 for the
details.

Index: kio-5.16.0/src/ioslaves/file/file.cpp
===
--- kio-5.16.0.orig/src/ioslaves/file/file.cpp
+++ kio-5.16.0/src/ioslaves/file/file.cpp
@@ -333,7 +333,7 @@ void FileProtocol::get(const QUrl &url)
 return;
 }
 
-#if HAVE_FADVISE
+#if HAVE_FADVISE && !defined(__GNU__)
 //TODO check return code
 posix_fadvise(f.handle(), 0, 0, POSIX_FADV_SEQUENTIAL);
 #endif
Index: kio-5.16.0/src/ioslaves/file/file_unix.cpp
===
--- kio-5.16.0.orig/src/ioslaves/file/file_unix.cpp
+++ kio-5.16.0/src/ioslaves/file/file_unix.cpp
@@ -128,7 +128,7 @@ void FileProtocol::copy(const QUrl &srcU
 return;
 }
 
-#if HAVE_FADVISE
+#if HAVE_FADVISE && !defined(__GNU__)
 posix_fadvise(src_file.handle(), 0, 0, POSIX_FADV_SEQUENTIAL);
 #endif
 
@@ -144,7 +144,7 @@ void FileProtocol::copy(const QUrl &srcU
 return;
 }
 
-#if HAVE_FADVISE
+#if HAVE_FADVISE && !defined(__GNU__)
 posix_fadvise(dest_file.handle(), 0, 0, POSIX_FADV_SEQUENTIAL);
 #endif
 
--- debian/libkf5kiocore5.symbols.original  2016-04-24 10:55:11.0 
+
+++ debian/libkf5kiocore5.symbols   2016-04-24 10:55:15.0 +
@@ -901,12 +901,12 @@
  _ZN3KIO8UDSEntry6insertEjRK7QString@Base 4.96.0
  _ZN3KIO8UDSEntry6insertEjx@Base 4.96.0
  _ZN3KIO8UDSEntry7reserveEi@Base 5.5.0+git20141229.0049+15.04
- (arch=kfreebsd-any)_ZN3KIO8UDSEntryC1ERK4statRK7QString@Base 5.11.0
- (arch=!kfreebsd-any)_ZN3KIO8UDSEntryC1ERK6stat64RK7QString@Base 4.100.0
+ (arch=kfreebsd-any hurd-i386)_ZN3KIO8UDSEntryC1ERK4statRK7QString@Base 5.11.0
+ (arch=!kfreebsd-any !hurd-i386)_ZN3KIO8UDSEntryC1ERK6stat64RK7QString@Base 
4.100.0
  _ZN3KIO8UDSEntryC1ERKS0_@Base 4.96.0
  _ZN3KIO8UDSEntryC1Ev@Base 4.96.0
- (arch=kfreebsd-any)_ZN3KIO8UDSEntryC2ERK4statRK7QString@Base 5.11.0
- (arch=!kfreebsd-any)_ZN3KIO8UDSEntryC2ERK6stat64RK7QString@Base 4.100.0
+ (arch=kfreebsd-any hurd-i386)_ZN3KIO8UDSEntryC2ERK4statRK7QString@Base 5.11.0
+ (arch=!kfreebsd-any !hurd-i386)_ZN3KIO8UDSEntryC2ERK6stat64RK7QString@Base 
4.100.0
  _ZN3KIO8UDSEntryC2ERKS0_@Base 4.96.0
  _ZN3KIO8UDSEntryC2Ev@Base 4.96.0
  _ZN3KIO8UDSEntryD1Ev@Base 4.96.0

Bug#807418: This bug applies also to Firefox-esr in Stretch

[Ingo]

This bug applies also to Firefox-esr in Stretch:

The only difference is the directory name, here affected files are:


/usr/share/firefox-esr/browser/defaults/preferences/webide-prefs.js
/usr/share/firefox-esr/browser/defaults/preferences/firefox.js
/usr/share/firefox-esr/browser/defaults/preferences/devtools.js

All 3 files have a modification date of 2010, January 1st, which did not
change since Firefox 45 was introduced in Stretch.

Bug#822430: debian-policy: Please update 8.1.1 to use the "ldconfig" trigger instead

[Niels Thykier]

Package: debian-policy
Severity: normal

Hi,

Please update 8.1.1 to use the "ldconfig" trigger[1].

Possible wording could be:

"""
Any package installing shared libraries in one of the default library
directories of the dynamic linker (which are currently /usr/lib and
/lib) or a directory that is listed in /etc/ld.so.conf[60] must use
ldconfig to update the shared library system.

Any such package must have an "activate-noawait ldconfig" line in
their "triggers" control file.
"""
(replacing the entire section).

Alternative wordings welcome; I am not entirely certain the one above
is all that well.

Thanks,
~Niels

[1] https://lists.debian.org/debian-glibc/2015/08/msg00056.html

Bug#802208: jq: FTBFS on mips*: tests fail

[Jakub Wilk]

* Jakub Wilk , 2016-04-23, 16:02:

This is most likely caused by this GCC bug:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68273

Indeed, the package no longer FTBFS on mips when built against current 
gcc-5 (5.3.1-15), which is supposed to fix PR68273.


I've tested gcc-5_5.3.1-15 on mipsel, and it does fix the FTBFS there 
too.


Dear mips* buildd admins, could you upgrade gcc-5 in buildd chroots (if 
necessary) and give back jq?


gb jq_1.5+dfsg-1 . mips mipsel

--
Jakub Wilk

Bug#820736: xmltex is marked for autoremoval from testing

[Norbert Preining]

reassign 820736 texlive-htmlxml
retitle 820736 missing conflicts against old xmltx
tag 820736 + pending
thanks

reassigning to the correct package

Norbert


PREINING, Norbert   http://www.preining.info
JAIST, Japan TeX Live & Debian Developer
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0  ACF0 6CAC A448 860C DC13

Bug#822336: perl: Stable update taking patches from 5.20.3

[Niko Tyni]

On Sat, Apr 23, 2016 at 04:36:26PM +0100, Dominic Hargreaves wrote:
> Source: perl
> Version: 5.20.2-3+deb8u4

> I analysed the 165 commits in upstream's git repository between
> 5.20.2 and 5.20.3 and selected what I believe to be the 40-odd
> relevant patches (the others are either non-functional changes in
> release notes, Module::CoreList or changes for platforms Debian does
> not support).

Thanks for doing this!

> In terms of practicalities, my preferred approach would be to cherry-pick
> the commits individually into the git-dpm patched branch, thus producing
> patch files in the usual way. The alternative would be to make a combined
> patch fixing all issues in one file, but this seems to have no real
> benefits and plenty of downsides.

Separate commits would definitely be preferrable IMO.

I wonder if it would be useful to prefix the patch (file)names with
something else than the current 'debian/' or 'fixes/', perhaps '5.20.3/',
to highlight their origins? This might at least make 'perl -V' output
a bit clearer.

Another thing: we need to make sure the fixes are in unstable + testing
before pushing them to stable.  In this case, given 5.20.3 was released
before 5.22.1 (see perlhist.pod), I expect it's all fine but it shouldn't
hurt to check.  I guess I'm sort of volunteering :)
-- 
Niko

Bug#802208: jq: FTBFS on mips*: tests fail

[Aurelien Jarno]

On 2016-04-24 13:29, Jakub Wilk wrote:
> * Jakub Wilk , 2016-04-23, 16:02:
> >This is most likely caused by this GCC bug:
> >https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68273
> >
> >Indeed, the package no longer FTBFS on mips when built against current
> >gcc-5 (5.3.1-15), which is supposed to fix PR68273.
> 
> I've tested gcc-5_5.3.1-15 on mipsel, and it does fix the FTBFS there too.

Thanks for the test and feedback.

> Dear mips* buildd admins, could you upgrade gcc-5 in buildd chroots (if
> necessary) and give back jq?

The chroots are now automatically recreated on Wednesdays and Sundays.
This should happen in a few hours, so it's probably better to wait.

> gb jq_1.5+dfsg-1 . mips mipsel

Done, using an extra-depends to force the GCC version.

Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net

Bug#821778: autopkgtest: adt-run fails with QEMU - BrokenPipe

[Martin Pitt]

Control: tag -1 confirmed

Hello Neil,

Neil Williams [2016-04-19  9:36 +0100]:
> adt-run /tmp/tmp.lXjW2N5fd3/lava-server_2016.4-1.dsc -U --- qemu adt-sid-2.raw
> adt-run [09:21:28]: ERROR: testbed failure: cannot send to testbed: 
> ['BrokenPipeError: [Errno 32] Broken pipe\n']

I confirm that too, with a freshly built sid testbed, thanks for the
report!

Some debugging notes (mostly for myself):

 - This is because eofcat hangs around for a long time even after the
   executed command finished long ago. The exit.tmp stamp also exists.

 - Adding some logging to eofcat shows that it doesn't really begin
   running and polling for half a minute or so.

 - After the first runcmd fails, re-running it again works fine.

 - I noticed that the time when the first eofcat finally finishes
   coincides with this kernel log entry:

   [1.549882] [TTM] Initializing DMA pool allocator
   [   39.586483] random: nonblocking pool is initialized

  I. e. in this case it took 39s (after boot) to collect enough
  entropy, and that's exactly the time that eofcat hangs.

 - So I attached strace to eofcat, and this confirms the suspicion
   above:

   437   11:21:36.118034 
getrandom("/V#\200^O*HD+D_\32\345\223M\205a\336/\36x\335\246", 24, 0) = 24
   437   11:21:57.93 ioctl(0, TCGETS, 0x7ffde1d152a0) = -1 ENOTTY 
(Inappropriate ioctl for device)

   which blocks for that time.

So this comes down to a regression in python3.5 3.5.1-11 (which
Antonio and Felix confirmed):

With -10:
  $ strace -e getrandom python3 -c 'True'
  +++ exited with 0 +++

With -11:
  $ strace -e getrandom python3 -c 'True'
  
getrandom("\300\0209\26&v\232\264\325\217\322\303:]\30\212Q\314\244\257t%\206\"",
 24, 0) = 24
  +++ exited with 0 +++

This is really unfriendly -- it essentially means that you stop being
able to use python3 early in the boot process. It would be better to
initialize that random stuff lazily, until/if things actually need it.
This could very well be the same reason as in
https://bugs.debian.org/821877, I'll follow up there.

In the diff between -10 and -11 I do seem some getrandom() fixes to
supply the correct buffer size (but that should be irrelevant as in
-10 getrandom() wasn't called in the first place), and a new call
which should apply to Solaris only (#ifdef sun), so it's not entirely
clear where that comes from or how to work around it. The "eofcat"
helper can't be implemented in shell sensibly, so we need some more
powerful scripting language.

In the meantime I'll think about a workaround.

Martin

-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)

Bug#817927: needrestart emits a lot of "Unknown option:" warnings (python buildbot)

[Thomas Liske]

tags 817927 fixed-upstream
thanks


Hi Francois,

needrestart uses the default Getopt::Std implementation shipped by
perl-modules - but python implements a custom getopts parser and
handles '-c' in the special way you've already described.

I dislike reimplementing the python approach again, but other
languages might make simular problems (i.e. perl using -e).

The upcoming needrestart 2.8 release will silence any getopts warnings
about unknown options. Furthermore, interpreters will be skipped if
they are using command line options (python -c, perl -e|E, ruby -e)


Thx & HTH,
Thomas


On Fri, Mar 11, 2016 at 06:22:51PM +0100, francois.petitj...@bureauveritas.com 
wrote:
> Package: needrestart
> Version: 1.2-8+deb8u1
> Severity: normal
> Tags: upstream
> 
> Dear Maintainer,
> 
> I have installed needrestart on a number of jessie systems.
>  Yesterday, I upgraded a machine from wheezy to jessie,
> This system acts as a buildmaster.
>  and asoon asI instaled needrestart, I get the following warnings after
> each run of apt/aptitude::
> =
> [Core] Using UI 'NeedRestart::UI::stdio'...
> [main] detected systemd
> [Core] #1537 is a NeedRestart::Interp::Python
> Unknown option: -
> Unknown option: n
> Unknown option: o
> Unknown option: _
> Unknown option: a
> Unknown option: e
> Unknown option: -
> Unknown option: l
> Unknown option: o
> Unknown option: g
> Unknown option: f
> Unknown option: l
> Unknown option: e
> Unknown option: =
> Unknown option: w
> Unknown option: .
> Unknown option: l
> Unknown option: o
> Unknown option: g
> Unknown option: -
> Unknown option: p
> Unknown option: y
> Unknown option: o
> Unknown option: n
> Unknown option: =
> Unknown option: b
> Unknown option: l
> Unknown option: b
> Unknown option: o
> Unknown option: .
> Unknown option: a
> [Python] #1537: could not get a source file, skipping
> =
> 
> 
> The 1537 processus is the twisted daemon (buildmaster)
> fp2x@drbuildbot:~$ ps -edf | fgrep 1537
> buildbot  1537 1  0 10:24 ?00:00:05 /usr/bin/python -c from 
> twisted.scripts import twistd; twistd.run() --no_save --logfile=twistd.log 
> --python=buildbot.tac
> fp2x 13192 10967  0 17:34 pts/100:00:00 grep -F --color=auto 1537
> fp2x@drbuildbot:~$ cat /proc/1537/cmdline | tr '\0' '\n'
> /usr/bin/python
> -c[1]
> from twisted.scripts import twistd; twistd.run()  [2]
> --no_save [3]
> --logfile=twistd.log  [4]
> --python=buildbot.tac [5]
> 
> Extract of /usr/share/perl5/NeedRestart/Interp/Python.pm
>104  # get original ARGV
>105  (my $bin, local @ARGV) = nr_parse_cmd($pid);
> 
>106  # eat Python's command line options
>107  my %opts;
>108  getopts('BdEhim:ORQ:sStuvVW:x3?c:', \%opts);
> 
>109  # extract source file
>110  unless($#ARGV > -1) {
>111  chdir($cwd);
>112  print STDERR "$LOGPREF #$pid: could not get a source file, 
> skipping\n" if($self->{debug});
>113  return ();
>114  }
>115  my $src = $ARGV[0];
> 
> We see that the getops() in line 108 emits a warning for each letter in 
> lines
> [3] through [5] of ARGV which is not in the 'BdEhim:ORQ:sStuvVW:x3?c: set
> 
> This parsing of a python command line is wrong. getopts() should be 
> applied
> only to the part of ARGV which is before the '-c' option.
> 
> The [3-[5] parameters are interpreted by the python twited daemon 
> instance.
> 
> I am not at ease enough with perl programming to provide a patch but the 
> logic is
> Search backwards the (python) command line  (argv) if there is a '-c' 
> option.
> If the '-c' option is found, please ignore all the following tokens, and
> thre is no hope to detect a source file.
> 
> IMHO, it is not a packagning bug, and it can affect a number of systems.
> 
> 
> -- Package-specific info:
> needrestart output:
> Running kernel seems to be up-to-date.
> No services need to be restarted.
> 
> checkrestart output:
> 
> 
> -- System Information:
> Debian Release: 8.3
>   APT prefers stable-updates
>   APT policy: (500, 'stable-updates'), (500, 'stable')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores)
> Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> 
> Versions of packages needrestart depends on:
> ii  dpkg   1.17.26
> ii  libmodule-find-perl0.12-1
> ii  libmodule-scandeps-perl1.16-1
> ii  libproc-processtable-perl  0.51-1
> ii  libsort-naturally-perl 1.03-1
> ii  libterm-readkey-perl   2.32-1+b1
> ii  perl   5.20.2-3+deb8u4
> 
> needrestart recommends no packages.
> 
> needrestart suggests no packages.
> 
> -- no debconf information
> 
> Cordialement,
> Regards,
> Mit freundlichen Grüßen,
> مع  تحياتي 

Bug#822431: python3.5: regression in -11: always calls getrandom() at start, causing long hang after boot

[Martin Pitt]

Package: python3.5
Version: 3.5.1-11
Severity: important

I just debugged the adt-virt-qemu failure with python 3.5.1-11 and
tracked it down to python3.5 hanging for a long time when it gets
called before the kernel initializes its RNG (which can take a minute
in VMs which have low entropy sources).

With 3.5.1-10:

  $ strace -e getrandom python3 -c 'True'
  +++ exited with 0 +++

With -11:
  $ strace -e getrandom python3 -c 'True'
  
getrandom("\300\0209\26&v\232\264\325\217\322\303:]\30\212Q\314\244\257t%\206\"",
 24, 0) = 24
  +++ exited with 0 +++

When you do this with -11 right after booting a VM, the getrandom()
can block for a long time, until the kernel initializes its random
pool:

   11:21:36.118034 
getrandom("/V#\200^O*HD+D_\32\345\223M\205a\336/\36x\335\246", 24, 0) = 24
   11:21:57.93 ioctl(0, TCGETS, 0x7ffde1d152a0) = -1 ENOTTY (Inappropriate 
ioctl for device)

   [1.549882] [TTM] Initializing DMA pool allocator
   [   39.586483] random: nonblocking pool is initialized

(Note the time stamps in the strace in the first paragraph)

This is really unfriendly -- it essentially means that you stop being
able to use python3 early in the boot process or even early after
booting. It would be better to initialize that random stuff lazily,
until/if things actually need it.

In the diff between -10 and -11 I do seem some getrandom() fixes to
supply the correct buffer size (but that should be irrelevant as in
-10 getrandom() wasn't called in the first place), and a new call
which should apply to Solaris only (#ifdef sun), so it's not entirely
clear where that comes from or how to work around it.

It's very likely that this is the same cause as for #821877, but the
description of that is both completely different and also very vague,
so I file this separately for now.

Martin

-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)


signature.asc
Description: PGP signature

Bug#822320: closed by Felix Geyer (Re: cmake depends on cmake-data which is uninstallable (FTBFS arch:all))

[Laurent Bigonville]

The fact that the build is failing in the "CMake.FileDownload" is 
expected I guess?


The build system should never download files outside of the tarball, 
most of the buildd disable the network. Shouldn't this test be disabled 
or the result be ignored if failing?


Cheers,

Laurent Bigonville


Le 24/04/16 à 09:51, Debian Bug Tracking System a écrit :

This is an automatic notification regarding your Bug report
which was filed against the src:cmake package:

#822320: cmake arch:all package FTBFS

It has been closed by Felix Geyer .

Their explanation is attached below along with your original report.
If this explanation is unsatisfactory and you have not received a
better one in a separate message then please contact Felix Geyer 
 by
replying to this email.

Bug#811351: linux-image-4.3.0-0.bpo.1-kirkwood: MMC does not work on OpenRD Client / fix pending

[Roger Shimizu]

Control: tags -1 + patch pending

On Fri, Apr 22, 2016 at 12:20 PM, Martin Michlmayr  wrote:
> * Rick Thomas  [2016-01-18 00:15]:
>> The 4.3.0.0 kernel on an "OpenRD Client" fails to recognize the SD card -- 
>> there is no mmc device shown by lsblk.
>>
>> This is fixed by using a modified DTB file provided by Aaro Koskinen.
>
> This has been fixed in the meantime and the fix will finally be in
> 4.6.
>
> commit 28c494d0c5b7e0993d067086b26c901ae23d3841
> Author: Aaro Koskinen 
> Date:   Tue Jan 12 22:07:33 2016 +0200
>
> ARM: dts: kirkwood: fix SD slot default configuration for OpenRD
>
> The SD card slot was enabled by default with legacy booting.
> It does not work anymore with DT boot. Fix by providing GPIO configuration
> that matches the old default.
>
> Signed-off-by: Aaro Koskinen 
> Reviewed-by: Andrew Lunn 
> Signed-off-by: Gregory CLEMENT 

Ben already added this patch to sid branch [0]

[0]: https://anonscm.debian.org/cgit/kernel/linux.git/commit/?h=sid&id=b20f5e

Cheers,
-- 
Roger Shimizu, GMT +9 Tokyo
PGP/GPG: 17B3ACB1

Bug#821877: python3.5.1-11 causes a 90 second delay to startup time on cinnamon desktop

[Martin Pitt]

Hello,

peter [2016-04-20  7:21 +0100]:
> I have a fully up-to-date system running cinnamon desktop except for :
> 
> python3.5
> python3.5-minimal
> libpython3.5
> libpython3.5-minimal
> libpython3.5-stdlib
> 
> 
> using current installed version  3.5.1-10 of all the above my startup time
> to
> login screen,
> as shown by the first line of systemd-analyze critical-chain is :
> graphical.target @2.918s
> 
> If I upgrade them all to version 3.5.1-11 my system boots to a black screen
> until eventually the login screen appears.
> The first line of systemd-analyze critical-chain now shows  :
> graphical.target
> @1min 32.408s

I just filed https://bugs.debian.org/822431 with a regression in -11
that can lead to long startup delays. Your report does not contain
much detail, and while it's likely that it's the same cause it is not
completely clear.

Martin

-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)

Bug#819824: easy mode for needrestart

[Thomas Liske]

tags 819824 upstream
thanks


Hi Patrick,

On Sat, Apr 02, 2016 at 07:18:39PM +, Patrick Schleizer wrote:
> we are wondering if needrestart should be installed by default in Whonix.
> 
> When needrestart is automatically run during apt-get dist-upgrade,
> I am concerned, that its output by default is too technical and verbose
> and will therefore add more confusion.

ACK

> Therefore I am hereby kindly asking if you could add an easy mode please?
> 
> - can be enabled by dropping some file into /etc/needrestart/conf.d
> - no automatic restart
> - it's output would be limited to the following
> 
> > Services need to be restarted. Reboot recommended.
> > For more information, see 'man needrestart'.
> 
> Or does the current configuration already allow configuring needrestart
> that way?

to disable any restarts you could try:

# Restart services (l)ist only, (i)nteractive or (a)utomatically.
$nrconf{restart} = 'l';

But it will still print the commands to restart the affected services.
To reduce the output to a minimum as in your example requires changes
in needrestart. 


HTH,
Thomas

--

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

Bug#822432: libharfbuzz-dev: Missing dependency on libgraphite2-dev

[Dmitry Shachnev]

Package: libharfbuzz-dev
Version: 1.2.6-1
Severity: grave
Justification: makes other packages FTBFS

Dear Maintainer,

The recent harfbuzz update made most of packages using pkg-config and depending
on libharfbuzz FTBFS (including those depending indirectly via gtk+-3.0).

Examples: https://buildd.debian.org/status/package.php?p=gnome-panel
  https://buildd.debian.org/status/package.php?p=gnome-flashback

The error message is:

  configure: error: Package requirements (
gtk+-3.0 >= 3.19.5
  ) were not met:

  Package 'graphite2', required by 'harfbuzz', not found

  Consider adjusting the PKG_CONFIG_PATH environment variable if you
  installed software in a non-standard prefix.

If adding this new dependency was intentional, then libharfbuzz-dev should
gain a dependency on libgraphite2-dev.

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#822320: closed by Felix Geyer (Re: cmake depends on cmake-data which is uninstallable (FTBFS arch:all))

[Felix Geyer]

On 24.04.2016 13:57, Laurent Bigonville wrote:
> The fact that the build is failing in the "CMake.FileDownload" is expected I 
> guess?

No, I've never seen that test fail.

> The build system should never download files outside of the tarball, most of 
> the buildd disable
> the network. Shouldn't this test be disabled or the result be ignored if 
> failing?

The test just downloads file://@CMAKE_CURRENT_SOURCE_DIR@/FileDownloadInput.png

Felix

Bug#538067: status of the opencpn PPA for inclusion in Debian

[Pavel Kalian]

Paul…
Many thanks for the review.

> On Apr 23, 2016, at 00:34, Paul Wise  wrote:
> 
> On Fri, 2016-04-22 at 16:20 -0300, Pavel Kalian wrote:
> 
>> Unfortunately I still did not receive any useful feedback from
>> anybody, neither on Debian GIS mailing list, or any information on
>> where I should submit something for review.
> 
> Generally it works like this:
> 
> https://mentors.debian.net/intro-maintainers
> 
> Here is a review of this package:
> 
> https://launchpad.net/~nohal/+archive/ubuntu/opencpn/+files/opencpn_4.2.0-0~xenial1.dsc
> 
> Based on my review, not much has been fixed since I last reviewed it.
> 
> In my opinion these issues block the upload of this package:
> 
> Others may accept the package despite these issues but I wouldn't.
> 
> All the embedded code copies (wxSVG etc) need to be removed from the
> upstream VCS repo and tarballs and packaged separately (some are now).
> For folks on other platforms they could provide a dependencies tarball.
> 
> https://wiki.debian.org/EmbeddedCodeCopies
The linked document says “Debian packages *should* not use convenience copies”, 
is it now changed to a hard requirement? It would IMO be unfortunate for the 
upstream to have to make the build from Git more complicated and per se broken 
for 99% of the people because of the packaging requirements of one single 
flavor of one single platform, especially as the files possibly offending 
Debian can be removed during the creation of the tarball. The embedded code 
also receives fixes for problems that affect us, which is just natural to 
handle in a VCS, not by making people watch for updates to some tarball (Which 
they fail to do as we know by experience). We do not include copies of 
libraries that do not need patching or where upstream exists and accepts 
patches.
Also, I wonder what sense does it make to create packages nobody else uses? 
(https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=813151)

> 
> I encourage de-forking the modified embedded code copies (zygrib etc).
While OpenCPN’s grib implementation originally came from zygrib many years ago, 
they are completely different now, how do you imagine the de-forking to be 
done? Same with GDAL etc.
Is this a hard requirement? If so, I’m afraid the Debian inclusion is out of 
question as zygrib internally is a Qt application, not a library, while OpenCPN 
is a wxWidgets application.

> 
> I encourage de-duplicating the duplicated embedded code copies (wxJSON etc).

It is upstream policy that the plugins have to be buildable completely 
independently of the core source tree.

> 
> I encourage removing the non-free embedded code copies (unrar) and
> replacing them with dependencies on free equivalents (unar).

No problem, done and ready to be pushed upstream.

> 
> There are some generated files in the source package (see the
> licensecheck output below), these should be removed from the upstream
> VCS repo and tarballs and created at build time by the upstream build
> system instead.
> 
> Some of the generated PNG images have got out of sync with their SVG
> source, upstream needs to investigate this.
There is no problem as far as I can see, the SVGs being “out of sync” are not 
meant to be “in sync” but are “original artwork templates".

> 
> Some of the generated PNG images (pkg_background.jpg for eg) look like
> they were generated from proprietary maps.

Do you say that taking a screenshot of a public domain chart (NOAA copyright 
states “No copyright is claimed by the United States Government under Title 17 
U.S.C.") produces an image incompatible with GPL? They of course can be 
removed, I’m just wondering if this situation is really considered problematic.

> 
> Some of the generated files (MathJax.js and *.min.*) do not have their
> corresponding source available in the package. This may be either a GPL
> violation or a DFSG violation depending on the license of those files.
Resolved, ready to be ushed upstream.

> 
> Helvetica.txf seems to have been generated from a proprietary font.
I’m confused, this file is already distributed by Debian in several packages. 
Is it now a hard requirement to replace it with another font in new packages?

> 
> There are some Depends/Recommends that need to be packaged and uploaded
> before opencpn can be uploaded.

You mean the opencpn-* data packages? Yes, they will be submitted once it will 
look like there is a chance the packaging effort is going to be succesful. 
Should be much easier than the code.

> 
> The debian/copyright file is not accurate, it needs to document the
> copyright and licenses of all the files in the source package.
> 
> https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
> http://people.skolelinux.org/pere/blog/Creating__updating_and_checking_debian_copyright_semi_automatically.html
> 
> In my opinion these issues would be nice to fix:
> 
> Please pass Debian's guide for upstreams along to the OpenCPN devs: 
> 
> https://wiki.debian.org/UpstreamGuide
> 
> data/lic

Bug#816542: RFS: connman/1.31-0.1 [RC]

[Mateusz Łukasik]

Pong back.

http://mentors.debian.net/debian/pool/main/c/connman/connman_1.21-1.3.dsc

I was tested it on Ubuntu 16.04 and all is fine.

Bug#822433: virt-viewer: Please enable oVirt support

[Laurent Bigonville]

Package: virt-viewer
Version: 1.0-1
Severity: wishlist

Hi,

Could you please enable oVirt support now that libgovirt is in the
archive?

Thanks,

Laurent Bigonville

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

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

Bug#822434: [Stub] update CUDA from 7.5 to 8.0

[lumin]

Package: nvidia-cuda-toolkit
Version: 7.5.18-1
Severity: wishlist

Hi,

This bug is opened for CUDA 8.0 package discussion, since CUDA 8.0
is comming soon, but it currently acts as a stub.

After cuda/7.5.18-1 was landed onto the archive, we can
coordinate work related to CUDA 8.0 in this bug.

FYI: CUDA 8.0 is comming soon,
https://developer.nvidia.com/cuda-toolkit

FYI: estimated package changes:
 * new upstream release 8.0.X (MM 2016)
 * new library package libnvgraph for nvGRAPH

Thanks.

Bug#796603: closed by Anton Zinoviev (Bug#796603: fixed in console-setup 1.138)

[Felipe Sateler]

On 24 April 2016 at 04:33, Christian PERRIER  wrote:
>
> Quoting Felipe Sateler (fsate...@debian.org):
> > I have uploaded a new version. I have not yet, however, secured commit
> > rights to d-i git repository. If you want to pull the changes before I
> > get the access, you can pull the signed tag from my fork:
> >
> > git pull https://anonscm.debian.org/git/users/fsateler/console-setup.git
> > debian/1.141
>
>
> I just added you to committers : I didn't notice this discussion when
> it happened and went on a problem when trying to upload a new version
> of the package --> my new version was 1.141 as it was built from git,
> and of course it was REJECTed as it conclicted with your upload.
>
> Would you mind pushing your changes to the D-I git? I'm more confident
> in you doing so than me merging from your git repo as my git skills
> are.let's say incomplete..:-)

Done. I did not reapply the changelog commit though.

-- 

Saludos,
Felipe Sateler

Bug#822330: bumblebee : unable to work with any newer driver than 340.96 - even backported bumblebee-nvidia install doesn't work (failed to set DRM interface version 1.4 too)

[Julien ROBIN]

Hi Vincent,

I already tried that grub modification (rcutree.rcu_idle_gp_delay=1) a lot of 
times in the past but probably in different conditions, because here, it worked 
!

In summary now, here is how you can simply get it working, following all that I 
did (I made a new fresh legacy-bios install just to be double sure !)

   0 - You need a computer with an Intel Display + Nvidia discrete card (mine 
is Asus R510JK - DM086H, with up to date bios, i5-4200H and GeForce 850M)
   1 - the simplest and minimalist net-installer for example (amd64 - 8.4.0 - 
started and installed as efi or legacy-bios, workaround work for both)
   2 - in my case, I work with : apt-get install lightdm lxde-core aptitude 
mesa-utils (I also added leafpad, synaptic and chromium, realtek and WiFi 
drivers + wicd, xarchiver pavucontrol for having sound card selection, and 
xbacklight for screen light intensity)
   3 - modify /etc/default/grub to add rcutree.rcu_idle_gp_delay=1 into 
GRUB_CMD_LINE and GRUB_CMD_LINE_DEFAULT, then "update-grub" as root and 
"reboot".
   4 - aptitude -t jessie-backports install bumblebee-nvidia, rebooted and it 
works ! Today it installs bumblebee 3.2.1-10~bpo8+1, and nvidia 352.79-1~bpo8+1 
and a lot of others things.

Having already tried that grub modification in the past without success for 
what seemed to be the same error, before I can confirm you that this workaround 
doesn't work with the standard jessie's bumblebee installation - and all the 
sub-packages that comes with - it would be more nearly sure for me to try again 
and look if the error logs were the same !

Thanks for your help, and :

I would suggest adding this simple procedure, for those who need a version 
>340.96 of the nvidia driver, into the Debian bumblebee installation's wiki :

  1 - with backports enabled into source.list, apt-get update and aptitude -t 
jessie-backports install bumblebee-nvidia
  2 - modify /etc/default/grub to add rcutree.rcu_idle_gp_delay=1 into 
GRUB_CMD_LINE and GRUB_CMD_LINE_DEFAULT, then "update-grub" and "reboot"
  (or may be, 2bis, use the backported version of the kernel, but I didn't 
tested it)

And last thing : is this backported simple and full installation of 
bumblebee-nvidia working for anyone without the second point ? I didn't tested 
the newer backported kernel, because few days in the past, I had game crashes 
and kernel panics every few minutes with a more recent kernel on ubuntu 15.10, 
that's why I will first give it a try with 3.16 before upgrading if I really 
need :)

Thanks again for you help, I hope this thread could have clarified things for 
others people trying to play with Debian !

Best regards,
Julien ROBIN

Bug#822336: perl: Stable update taking patches from 5.20.3

[Niko Tyni]

On Sun, Apr 24, 2016 at 02:43:26PM +0300, Niko Tyni wrote:

> I wonder if it would be useful to prefix the patch (file)names with
> something else than the current 'debian/' or 'fixes/', perhaps '5.20.3/',
> to highlight their origins? This might at least make 'perl -V' output
> a bit clearer.

Dominic proposed fixes/5.20.3/ which is fine by me assuming git-dpm
copes (I expect it does).

> Another thing: we need to make sure the fixes are in unstable + testing
> before pushing them to stable.  In this case, given 5.20.3 was released
> before 5.22.1 (see perlhist.pod), I expect it's all fine but it shouldn't
> hurt to check.  I guess I'm sort of volunteering :)

OK, I've had a quick look at these. They are all in 5.22.1 so fixed in
sid/stretch, no worries about that.

Here are a few things that caught my eye while at it. +1 from me to all
the others on the list.

d40f1ca59e9f4eb4e0e717b5304072636b24a62a lib/perl5db.pl: Restore noop lock 
prototype
  this is already in jessie as fixes/perldb-threads.diff

0f19268d11e0e7ce38b5a449f9f53461a0dc3226 [perl #123748] - Add test case for 
possible getenv/putenv/setenv stomping in perl.c (also squash 
63209b393029691eb62065536b4aaab4ade1ad7b into it)
  This is not a functional change, just a new test. Do we want that?
  Also, I'm not sure if squashing is the right thing to do but I don't
  feel strongly about that.

8d89c0509dd5eb1de58dc6617f6e08599eb24792 [PATCH] [perl #123786] don't leak the 
temp utf8 copy of namep
  This is the only one that's not a cherry-pick from another branch so it's
  worth a mention, though it definitely needs to be included.
  The ticket says:
"This isn't an issue in blead, since the leaking code is no longer present 
- all pad names are in utf-8 so there's no need to convert."
  Blead at the time (Feb 2015) was pre-5.22 so it should be OK on sid. I've
  verified that the test case leaks on jessie but not sid.

ccafce1bfd59cdbdd7af0ad68f7557a7471d6c64 Perl_save_re_context(): re-indent 
after last commit
  Whitespace only but would be nice to group with 
17d9707d444517764c7bcb479c236a8c58a1d605
  Again, to squash or not to squash?

0cb29f21ba1db04416bb1a2dbc32cd5f7c75bc84 lib/h2ph.t to test generated 
t/_h2ph_pre.ph instead of the system one
  Another test-only commit. 

41575f0a39566008526e7e38eab84cba82cf372b Add pthread to libswanted
  This is not a doc fix though it was grouped there.
  We override libswanted in debian/prune_libs.diff so maybe not that useful?

-- 
Niko

Bug#820895: sphinx: please extend SOURCE_DATE_EPOCH support

[Dmitry Shachnev]

Hi Alexis,

On Wed, Apr 13, 2016 at 03:00:24PM +0200, Alexis Bienvenüe wrote:
> The attached patch extends the SOURCE_DATE_EPOCH support in copyright
> year and gettext, and corrects copyright strings that does not
> corresponds to SOURCE_DATE_EPOCH, so that affected packages can be built
> reproducibly without any change.

Thanks a lot for your efforts!

Can you please submit your patch upstream (like you did it for #822197)?

I would really prefer to get this patch reviewed/accepted by upstream before
including it in the Debian packaging. (Also, if you will be submitting it,
better use stable branch of git rather than master, which will make sure your
change will be in the next bugfix release if accepted.)

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#822435: python-extractor,python-sfepy: error when trying to install together

[Andreas Beckmann]

Package: python-extractor,python-sfepy
Severity: serious
User: trei...@debian.org
Usertags: edos-file-overwrite
Control: found -1 1:0.6-4
Control: found -1 2016.1-1

Hi,

automatic installation tests of packages that share a file and at the
same time do not conflict by their package dependency relationships has
detected the following problem:

  Selecting previously unselected package python-sfepy.
  Preparing to unpack .../python-sfepy_2016.1-1_amd64.deb ...
  Unpacking python-sfepy (2016.1-1) ...
  dpkg: error processing archive 
/var/cache/apt/archives/python-sfepy_2016.1-1_amd64.deb (--unpack):
   trying to overwrite '/usr/lib/python2.7/dist-packages/extractor.py', which 
is also in package python-extractor 1:0.6-4

This is a serious bug as it makes installation fail, and violates
sections 7.6.1 and 10.1 of the policy. An optimal solution would
consist in only one of the packages installing that file, and renaming
or removing the file in the other package. Depending on the
circumstances you might also consider Replace relations or file
diversions. If the conflicting situation cannot be resolved then, as a
last resort, the two packages have to declare a mutual
Conflict. Please take into account that Replaces, Conflicts and
diversions should only be used when packages provide different
implementations for the same functionality.

Here is a list of files that are known to be shared by both packages
(according to the Contents file for sid/amd64, which may be
slightly out of sync):

   usr/lib/python2.7/dist-packages/extractor.py

This bug is assigned to both packages. If you, the maintainers of
the two packages in question, have agreed on which of the packages will
resolve the problem please reassign the bug to that package. You may
also register in the BTS that the other package is affected by the bug.

Cheers,

Andreas

PS: for more information about the detection of file overwrite errors
of this kind see https://qa.debian.org/dose/file-overwrites.html


python-extractor=1%0.6-4_python-sfepy=2016.1-1.log.gz
Description: application/gzip

Bug#607032: openvrml: diff for NMU version 0.18.9-7.2

[Tobias Frost]

Control: tags 607032 + patch
Control: tags 607032 + pending

Dear maintainer,

I've prepared an NMU for openvrml (versioned as 0.18.9-7.2) and
uploaded it to DELAYED/7. Please feel free to tell me if I
should delay it longer.

Regards.
diff -u openvrml-0.18.9/debian/changelog openvrml-0.18.9/debian/changelog
--- openvrml-0.18.9/debian/changelog
+++ openvrml-0.18.9/debian/changelog
@@ -1,3 +1,11 @@
+openvrml (0.18.9-7.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Move the documentation build to Build-Indep, as on the gcj
+based archs this will fail. (Closes: #607032)
+
+ -- Tobias Frost   Sun, 24 Apr 2016 11:24:13 +0200
+
 openvrml (0.18.9-7.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -u openvrml-0.18.9/debian/control openvrml-0.18.9/debian/control
--- openvrml-0.18.9/debian/control
+++ openvrml-0.18.9/debian/control
@@ -11,7 +11,9 @@
libboost-thread-dev, libboost-filesystem-dev, libgtk2.0-dev,
libxmu-dev, procps, graphviz, libgnomeui-dev, libglade2-dev,
libcurl4-gnutls-dev, libgtkglext1-dev, libltdl-dev,
-   libdbus-glib-1-dev, ghostscript, doxygen-latex
+   libdbus-glib-1-dev
+Build-Depends-Indep:
+   ghostscript, doxygen-latex
 Standards-Version: 3.9.5
 Vcs-Git: git://git.debian.org/git/collab-maint/openvrml.git
 Vcs-Browser: http://git.debian.org/?p=collab-maint/openvrml.git;a=summary
diff -u openvrml-0.18.9/debian/rules openvrml-0.18.9/debian/rules
--- openvrml-0.18.9/debian/rules
+++ openvrml-0.18.9/debian/rules
@@ -47,14 +47,14 @@
LIBS="-lboost_system" BOOST_LIB_SUFFIX="" ./configure $(confflags)
touch configure-stamp
 
+build-indep: build-stamp
+   $(MAKE) -C doc html-local
+
 build: build-arch build-indep
 build-arch: build-stamp
-build-indep: build-stamp
 build-stamp: configure-stamp 
dh_testdir
$(MAKE)
-   #Shouldn't be necessary but upstream svn doesn't have the docs built.
-   $(MAKE) -C doc html-local
touch build-stamp
 
 clean:

Bug#822236: vDSO is not in effect in static linked executable on jessie

[jian wang]

On Sun, Apr 24, 2016 at 6:31 PM, Aurelien Jarno  wrote:
> control: tag -1 + moreinfo
>
> On 2016-04-22 11:11, Mattia Rizzolo wrote:
>> control: reassign -1 libc6  2.19-18+deb8u4
>>
>> On Fri, Apr 22, 2016 at 06:27:34PM +0800, jian wang wrote:
>> > Package: lib6
>>
>> lost a 'c' :)
>> reassigning.
>>
>> > Version: 2.19-18+deb8u4
>> > Severity: important
>> >
>> > vDSO is not in effect in static linked executable on jessie. This is
>> > not the case with wheezy.
>> >
>> > We build binary to run on both wheezy and jessie, so -static. When
>> > building platform is wheezy, vdso works fine, but jessie the opposite.
>> >
>> > This leads to performance hit. Unfortunately, we use g++ 4.9 for some
>> > application, so wheezy can't be used as build platform.
>
> There is not of information about your environment, so given what you
> describe, it seems you are using an i386 installation.
>

The context is for lots of servers. We use amd64 all over datacenters.

> The vDSO support requires at least a i686 CPU, while Debian i386 targets
> i586. When using dynamic linking, one can install libc6-i686 which
> provides an i686 optimized version of the libc, therefore with vDSO
> support. It is automatically loaded if the CPU supports it.
>
> In your case, given you use static linking, the i586 version of the libc
> is used, and it therefore doesn't support vDSO . That is true on wheezy,
> jessie, stretch, sid. I don't believe this is a regression, and in
> addition I can't reproduce it.
>

No.

We have looked into the code now.

Glibc 2.13 (wheezy) uses an asm version of gettimeofday.S for x86_64
which uses vDSO.

On the way up to glibc 2.19 (jessie), vDSO was rewritten into
gettimeofday.c. And as we dig out, Ulrich Drepper decided to not
optimize static linking, or even to dwarf static linking

https://sourceware.org/bugzilla/show_bug.cgi?id=12813

2.19 uses vDSO for 'SHARED' build,  otherwise uses syscall.

U.D. does have his reasons. I personally agree that static linking is
not good. But considering there is no universal or even popular method
to bundle binaries and libraries (compile once and run everywhere) on
linux, static linking _is_ useful in some cases, there is no need to
dwarf it intentionally.

See source code of 2.19,  sysdeps/unix/sysv/linux/x86_64/gettimeofday.c

Bug#822330: bumblebee : unable to work with any newer driver than 340.96 - even backported bumblebee-nvidia install doesn't work (failed to set DRM interface version 1.4 too)

[Luca Boccassi]

Hi Vincent,

Thanks for the suggestion!

On Sun, 2016-04-24 at 14:35 +0200, Julien ROBIN wrote:
> Hi Vincent,
> 
> I already tried that grub modification (rcutree.rcu_idle_gp_delay=1) a lot of 
> times in the past but probably in different conditions, because here, it 
> worked !
> 
> In summary now, here is how you can simply get it working, following all that 
> I did (I made a new fresh legacy-bios install just to be double sure !)
> 
>0 - You need a computer with an Intel Display + Nvidia discrete card (mine 
> is Asus R510JK - DM086H, with up to date bios, i5-4200H and GeForce 850M)
>1 - the simplest and minimalist net-installer for example (amd64 - 8.4.0 - 
> started and installed as efi or legacy-bios, workaround work for both)
>2 - in my case, I work with : apt-get install lightdm lxde-core aptitude 
> mesa-utils (I also added leafpad, synaptic and chromium, realtek and WiFi 
> drivers + wicd, xarchiver pavucontrol for having sound card selection, and 
> xbacklight for screen light intensity)
>3 - modify /etc/default/grub to add rcutree.rcu_idle_gp_delay=1 into 
> GRUB_CMD_LINE and GRUB_CMD_LINE_DEFAULT, then "update-grub" as root and 
> "reboot".
>4 - aptitude -t jessie-backports install bumblebee-nvidia, rebooted and it 
> works ! Today it installs bumblebee 3.2.1-10~bpo8+1, and nvidia 
> 352.79-1~bpo8+1 and a lot of others things.
> 
> Having already tried that grub modification in the past without success for 
> what seemed to be the same error, before I can confirm you that this 
> workaround doesn't work with the standard jessie's bumblebee installation - 
> and all the sub-packages that comes with - it would be more nearly sure for 
> me to try again and look if the error logs were the same !
> 
> Thanks for your help, and :
> 
> I would suggest adding this simple procedure, for those who need a version 
> >340.96 of the nvidia driver, into the Debian bumblebee installation's wiki :
> 
>   1 - with backports enabled into source.list, apt-get update and aptitude -t 
> jessie-backports install bumblebee-nvidia
>   2 - modify /etc/default/grub to add rcutree.rcu_idle_gp_delay=1 into 
> GRUB_CMD_LINE and GRUB_CMD_LINE_DEFAULT, then "update-grub" and "reboot"
>   (or may be, 2bis, use the backported version of the kernel, but I 
> didn't tested it)
> 
> And last thing : is this backported simple and full installation of 
> bumblebee-nvidia working for anyone without the second point ? I didn't 
> tested the newer backported kernel, because few days in the past, I had game 
> crashes and kernel panics every few minutes with a more recent kernel on 
> ubuntu 15.10, that's why I will first give it a try with 3.16 before 
> upgrading if I really need :)
> 
> Thanks again for you help, I hope this thread could have clarified things for 
> others people trying to play with Debian !
> 
> Best regards,
> Julien ROBIN

Hi Julien,

Thanks for helping digging into this!

I just tried, and without the kernel cmdline workaround it works for me
on both 3.16 and 4.4 from backports.

I can only assume at this point that the issue is hardware-specific.

I have a Dell Latitude E5540 with an Haswell i7-4600U and a GT720M.

I'll document this workaround in the debian/README.source, not much else
we can do I'm afraid.

Kind regards,
Luca Boccassi


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

Bug#822436: nestopia closes when launching roms

[diego]

Package: nestopia
Version: 1.47-1
Severity: important

Dear Maintainer,

When launching a rom the program closes. I don't know how to retrieve more
information about the bug, so if more information is needed you will have to
say me how I should obtain it.



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

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

Versions of packages nestopia depends on:
ii  libao4  1.1.0-3
ii  libarchive133.1.2-11+b1
ii  libc6   2.22-6
ii  libepoxy0   1.3.1-1
ii  libgcc1 1:5.3.1-14
ii  libgdk-pixbuf2.0-0  2.34.0-1
ii  libglib2.0-02.48.0-1
ii  libgtk-3-0  3.18.9-1
ii  libsdl2-2.0-0   2.0.4+dfsg1-2+b1
ii  libstdc++6  5.3.1-14
ii  zlib1g  1:1.2.8.dfsg-2+b1

nestopia recommends no packages.

nestopia suggests no packages.

-- no debconf information

Bug#663738: apt-listchanges doesn't wait for confirmation before installation proceeds

[Gregor Zattler]

Hi Robert,
* Robert Luberda  [04. Apr. 2016]:
>> I can confirm this: I'm using apt-get and apt-listchanges on an
>> up-to-date debian/testing system and since some time
> 
> Since when exactly?  I assume that your version of apt-listchanges is
> 2.86 which has been available in testing since March 23rd. Does the
> issue started to appear earlier or later than the above date?
> 
> Is there any chance that you call apt-get with `-y' or `-q'
> (`--assume-yes' or `--quiet') option?

Thanks for the hint.  I found the NEWS section and reconfigured
apt-listchanges.

Ciao; Gregor 

Bug#822327:

[allan]

Found that libpepflashplayer.so was missing
from /usr/lib/pepperflashplugin-nonfree.

I downloaded the 64-bit Chrome deb from google,
extracted libpepflashplayer.so, placed it in the proper location and
pepperflash works now.

Sorry, it appears this bug needs to be against pepperflashplugin-nonfree.
Can someone please move the bug if they think it's appropriate?

Thanks -

Bug#806248: shotwell: Round Tripping Too

[Stephen]

Package: shotwell
Version: 0.22.0-4
Followup-For: Bug #806248

Dear Maintainer,

For me, it's not so much opening with the external editor that causes a
segfault, but round tripping from GIMP back to Shotwell. Once the image
is updated from GIMP it segfaults when one switches back to Shotwell to
see the image results. HTH

-- Package-specific info:

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

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

Versions of packages shotwell depends on:
ii  dbus-x111.10.8-1
ii  dconf-cli   0.26.0-1
ii  libatk1.0-0 2.20.0-1
ii  libc6   2.22-7
ii  libcairo-gobject2   1.14.6-1+b1
ii  libcairo2   1.14.6-1+b1
ii  libexif12   0.6.21-2
ii  libgdk-pixbuf2.0-0  2.34.0-1
ii  libgee-0.8-20.18.0-1
ii  libgexiv2-2 0.10.3-2
ii  libglib2.0-02.48.0-1
ii  libgomp15.3.1-15
ii  libgphoto2-62.5.10-2
ii  libgphoto2-port12   2.5.10-2
ii  libgstreamer-plugins-base1.0-0  1.8.1-1
ii  libgstreamer1.0-0   1.8.1-1
ii  libgtk-3-0  3.20.3-1
ii  libgudev-1.0-0  230-3
ii  libjavascriptcoregtk-4.0-18 2.12.1-1
ii  libjson-glib-1.0-0  1.2.0-1
ii  liblcms2-2  2.7-1
ii  libpango-1.0-0  1.40.1-1
ii  libpangocairo-1.0-0 1.40.1-1
ii  libraw150.17.1-1
ii  librest-0.7-0   0.7.93-1
ii  librsvg2-common 2.40.15-1
ii  libsoup2.4-12.54.0.1-1
ii  libsqlite3-03.12.2-1
ii  libstdc++6  5.3.1-15
ii  libwebkit2gtk-4.0-372.12.1-1
ii  libx11-62:1.6.3-1
ii  libxml2 2.9.3+dfsg1-1
ii  shotwell-common 0.22.0-4

shotwell recommends no packages.

shotwell suggests no packages.

-- no debconf information

Bug#726661: login fails with pam_loginuid(sshd:session): set_loginuid failed

[Evgeni Golov]

Hey,

On Sun, Apr 17, 2016 at 09:57:51PM +0200, Evgeni Golov wrote:
> > There are PAM patches at [1][2][3], maybe they just need backporting to 
> > Jessie?
> > 
> > [1] 
> > https://git.fedorahosted.org/cgit/linux-pam.git/commit/modules/pam_loginuid/pam_loginuid.c?id=5825450540e6620ac331c64345b42fdcbb1d6e87
> > [2] 
> > https://git.fedorahosted.org/cgit/linux-pam.git/commit/modules/pam_loginuid/pam_loginuid.c?id=24f3a88e7de52fbfcb7b8a1ebdae0cdbef420edf
> > [3] 
> > https://git.fedorahosted.org/cgit/linux-pam.git/commit/modules/pam_loginuid/pam_loginuid.c?id=2e62d5aea3f5ac267cfa54f0ea1f8c07ac85a95a
> 
> [3] is missing from src:pam/debian/patches-applied/pam-loginuid-in-containers
> Ubuntu has it backported at [4].
> 
> I think the following should be done (but I am unsure that's the only failure 
> here, so maybe rather a clone? - I'll let the openssh maintainers decide)
> reassign -1 libpam-modules
> retitle -1 pam_loginuid fails in unprivileged containers
> found -1 1.1.8-3.1+deb8u1
> found -1 1.1.8-3.2
> tags -1 + patch

This has been done, thanks.

> [4] 
> https://bazaar.launchpad.net/~ubuntu-branches/ubuntu/wily/pam/wily/view/head:/debian/patches-applied/pam-loginuid-in-containers

This patch seems only to adress LXC containers.
The original report looks like it was happening on Linux VServer and Myon 
confirms he has this issues on such a box too.

I think we would need to teach PAM to detect also Linux VServers similar how it 
is done for LXC in [5]

Detecting a VServer guest should as easy as looking at /proc/self/status for a 
line "VxID: x" with x != 0. [6]

Oh, and what's abou OpenVZ? :)

[5] 
https://git.fedorahosted.org/cgit/linux-pam.git/tree/modules/pam_loginuid/pam_loginuid.c#n61
[6] 
https://github.com/puppetlabs/facter/blob/master/lib/src/facts/linux/virtualization_resolver.cc#L146

Bug#822077: Should dh_apparmor disable a profile when the package that ships it is removed?

[intrigeri]

Control: tag -1 + upstream
Control: severity -1 wishlist

Hi,

Andrew Pollock wrote (21 Apr 2016 03:24:52 GMT) :
> dh_apparmor installs a postinst that activates a policy when a package that 
> ships a policy is installed.

> There doesn't seem to be any equivalent postrm action added when the package 
> is removed.

> Should there be? I would have thought so for completeness.

I'm sorry I don't remember the specifics, but I'm pretty sure I've
read somewhere a good explanation of why this would be problematic.

I suggest asking on the appar...@lists.ubuntu.com mailing-list :)

Cheers,
-- 
intrigeri

Bug#606421: refcard: Czech PDF rendering issues

[Miroslav Kure]

On Thu, Apr 21, 2016 at 09:57:49PM +0200, Holger Wansing wrote:
> 
> I have filed
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=821119
> which has chances to fix this longstanding bugreport, too.
> 
> Please find some proposed pdf files for Czech, Greek and Slovak under
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=821119#45

Renders fine for Czech, thank you Holger!

-- 
Miroslav Kure

Bug#822437: tor: Please add Multi-Arch: foreign

[Elrond]

Package: tor
Version: 0.2.7.6-1
Severity: wishlist

Hi,

It looks like tor offers an architecture independent
(process/cli/network level) interface to its users.
Would you mind setting it to Multi-Arch: foreign?  It's
usually a matter of adding one line to debian/control.

This would hopefully improve install options for different
architectures.  Like for example using the x32 variant of
the package on a mixed amd64/x32 system.


Cheers

Elrond

Bug#822438: libx11-6: xlib does not support en_HK.UTF-8 even installed

[Michael Tsang]

Package: libx11-6
Version: 2:1.6.2-3
Severity: important
Tags: l10n

Dear Maintainer,

When LC_CTYPE=en_HK.UTF-8, X applications fail to set the locale as
demonstrated below:

[michael@server ~]$ locale -a
C
C.UTF-8
en_DK.utf8
en_GB.utf8
en_HK.utf8
en_ZA.utf8
POSIX
zh_CN.utf8
zh_HK.utf8
zh_TW.utf8
[michael@server ~]$ LC_CTYPE=en_GB.UTF-8 xterm
[michael@server ~]$ LC_CTYPE=en_HK.UTF-8 xterm
Warning: locale not supported by Xlib, locale set to C
[michael@server ~]$

Therefore, I have to set another LC_CTYPE in order for X applications to work
properly.



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

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

Versions of packages libx11-6 depends on:
ii  libc6  2.19-18+deb8u4
ii  libx11-data2:1.6.2-3
ii  libxcb11.10-3+b1
ii  multiarch-support  2.19-18+deb8u4

libx11-6 recommends no packages.

libx11-6 suggests no packages.

-- no debconf information

Bug#757231: retitle 757231 to O: php-cas -- Central Authentication Service client library in php

[Olivier Berger]

retitle 757231 O: php-cas -- Central Authentication Service client library in 
php
thanks

I'm no longer able to dedicate time and effort to maintaining the package.

I've just uploaded 1.3.3-3 with maintainer set to QA.

I'm also not sure it's feasable to test that the package is working easily. 
Maybe as an advice for future maintainers, I'd suggest to investigate using 
docker for setting up a test env for CAS server and PHP webapp + phpcas.

Hth.

-- 
Olivier BERGER 
(OpenPGP: 4096R/7C5BB6A5 : http://weusepgp.info)
http://www.olivierberger.com/weblog/

Bug#822439: lokalize: please remove kdesdk-strigi-plugins and python-kde4 from dependencies

[Nick]

Package: lokalize
Version: 4:15.12.1-1
Severity: normal

those are leftovers from kde4 times

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

Kernel: Linux 4.5.0-pf1netbook (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 lokalize depends on:
ii  kdesdk-strigi-plugins  4:14.12.2-1+b1
ii  libc6  2.22-6
ii  libhunspell-1.3-0  1.3.3-4
ii  libkf5completion5  5.19.0-1
ii  libkf5configcore5  5.19.0-1
ii  libkf5configgui5   5.19.0-1
ii  libkf5configwidgets5   5.19.0-1
ii  libkf5coreaddons5  5.19.0-1
ii  libkf5dbusaddons5  5.19.0-1
ii  libkf5i18n55.19.0-1
ii  libkf5itemviews5   5.19.0-1
ii  libkf5kiocore5 5.19.0-1
ii  libkf5kiofilewidgets5  5.19.0-1
ii  libkf5kiowidgets5  5.19.0-1
ii  libkf5krosscore5   5.19.0-1
ii  libkf5krossui5 5.19.0-1
ii  libkf5notifications5   5.19.0-1
ii  libkf5parts5   5.19.0-1
ii  libkf5sonnetcore5  5.19.0-1
ii  libkf5sonnetui55.19.0-1
ii  libkf5textwidgets5 5.19.0-1
ii  libkf5widgetsaddons5   5.19.0-1
ii  libkf5xmlgui5  5.19.0-1
ii  libqt5core5a   5.6.0+dfsg-2
ii  libqt5dbus55.6.0+dfsg-2
ii  libqt5gui5 5.6.0+dfsg-2
ii  libqt5sql5 5.6.0+dfsg-2
ii  libqt5sql5-sqlite  5.6.0+dfsg-2
ii  libqt5widgets5 5.6.0+dfsg-2
ii  libqt5xml5 5.6.0+dfsg-2
ii  libstdc++6 5.3.1-14

Versions of packages lokalize recommends:
ii  gettext0.19.7-2
pn  krosspython
ii  python-dbus1.2.4-1
pn  python-kde4
pn  python-lxml
pn  subversion 
pn  translate-toolkit  

Versions of packages lokalize suggests:
ii  khelpcenter  4:5.4.3-1
pn  poxml

-- no debconf information

Bug#790814: ITP: kanboard -- A PHP project management system with a kanban workflow style interface and various integrations.

[Olivier Berger]

Hi.

Last year, you stated your intent to create a Debian package for kanboard.

Are there any progress one could review ? Any shared code repo containing you 
package sources ?

Thanks in advance.

Best regards,


On Wed, Jul 01, 2015 at 10:51:41PM +0100, John Hackett wrote:
> Package: wnpp
> Severity: wishlist
> Owner: John Hackett 
> 
> * Package name: kanboard
>   Version : v1.0.16
>   Upstream Author : Frédéric Guillot 
> * URL : http://www.kanboard.net/
> * License : AGPLv3
>   Programming Lang: PHP
>   Description : A web based project management system with a kanban 
> workflow style interface and various integrations.
> 
> Kanboard allows for fast and easy project management and has robust task 
> management built in. 

-- 
Olivier BERGER 
(OpenPGP: 4096R/7C5BB6A5)
http://www.olivierberger.com/weblog/

Bug#822362: RFS: mitlm/0.4-2 -- MIT Language Modeling toolkit

[Giulio Paci]

Il 24/apr/2016 12:54, "Jakub Wilk"  ha scritto:
>
> * Giulio Paci , 2016-04-24, 01:13:
>
 +  * Update Source field in copyright.
>>>
>>> Policy §12.5 says that the “the copyright file must say where the
upstream sources (if any) were obtained”, but they are not available (and
never were AIUI) at the new location. So I think keeping the original
Source would be better^Wless wrong, at least until the tarball Debian uses
appears on the new site.
>>
>> Reverted the change
>
>
> But the changelog still say it's been updated.

Removed the line.

>>> spellintian(1) says:
>>> debian/patches/1003_make_logger_more_flexible.patch: Allows to ->
Allows one to
>>
>> Fixed.
>
> But not documented in the changelog...

Added a line for it.

Bests,
Giulio

Bug#822440: imagemagick-6.q16: Can't convert PDF to PNG

[Pierre Rudloff]

Package: imagemagick-6.q16
Version: 8:6.8.9.9-5+deb8u1
Severity: important

Hello,

I get an error when I try to convert a PDF file to PNG:
pierre@pierre ~/T/Slides> convert Formation-Audit-2016.pdf Formation-
Audit-2016.png
convert: FailedToExecuteCommand `"gs" -q -dQUIET -dSAFER -dBATCH -dNOPAUSE
-dNOPROMPT -dMaxBitmap=5 -dAlignToPixels=0 -dGridFitTT=2
"-sDEVICE=pngalpha" -dTextAlphaBits=4 -dGraphicsAlphaBits=4 "-r72x72"
"-sOutputFile=/tmp/magick-265297JkA2yLXVqla%d" "-f/tmp/magick-26529eJ-
qsRWQWa7D" "-f/tmp/magick-26529UMC4Bj3knZS7"' (-1) @
error/delegate.c/ExternalDelegateCommand/461.
convert: no images defined `Formation-Audit-2016.png' @
error/convert.c/ConvertImageCommand/3210.

It used to work with previous versions.

Regards,



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

Kernel: Linux 3.16.0-4-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 imagemagick-6.q16 depends on:
ii  hicolor-icon-theme 0.13-1
ii  libc6  2.19-18+deb8u4
ii  libmagickcore-6.q16-2  8:6.8.9.9-5+deb8u1
ii  libmagickwand-6.q16-2  8:6.8.9.9-5+deb8u1

Versions of packages imagemagick-6.q16 recommends:
ii  ghostscript  9.06~dfsg-2+deb8u1
ii  libmagickcore-6.q16-2-extra  8:6.8.9.9-5+deb8u1
ii  netpbm   2:10.0-15.2

Versions of packages imagemagick-6.q16 suggests:
pn  autotrace
ii  cups-bsd [lpr]   1.7.5-11+deb8u1
ii  curl 7.38.0-4+deb8u3
pn  enscript 
pn  ffmpeg   
ii  gimp 2.8.14-1+b1
pn  gnuplot  
pn  grads
ii  graphviz 2.38.0-7
ii  groff-base   1.22.2-8
pn  hp2xx
pn  html2ps  
pn  imagemagick-doc  
ii  libwmf-bin   0.2.8.4-10.3+deb8u1
ii  mplayer2 [mplayer]   2.0-728-g2c378c7-4+b1
pn  povray   
pn  radiance 
ii  sane-utils   1.0.24-8+deb8u1
ii  texlive-binaries [texlive-base-bin]  2014.20140926.35254-6
ii  transfig 1:3.2.5.e-4
pn  ufraw-batch  
ii  xdg-utils1.1.0~rc1+git20111210-7.4

-- no debconf information

Bug#822349: does not enable policy if it's the system's first

[intrigeri]

Control: tag -1 + pending

Hi,

Peter Palfrader wrote (23 Apr 2016 17:57:37 GMT) :
> If a package ships an apparmor policy, and it's the first policy on the
> system, then it's not getting enabled during postinst configure, causing
> the service to fail to start: [...]

Thanks for the analysis!

> This made it work:

Thanks, applied (to the relevant file) in the Vcs-Bzr, so it'll be
part of the next upload (which should happen soonish since a new
version just got released upstream).

Cheers,
-- 
intrigeri

Bug#821945: abstractions/ubuntu-browsers: please include /usr/lib/firefox-esr/firefox-esr as a browser

[intrigeri]

Control: tag -1 + upstream
Control: forwarded -1 
https://code.launchpad.net/~intrigeri/apparmor/add-firefox-esr-to-ubuntu-browsers/+merge/292725

Hi,

Simon McVittie wrote (20 Apr 2016 17:15:23 GMT) :
> This pseudo-patch appears to work:

Thanks submitted upstream:
https://code.launchpad.net/~intrigeri/apparmor/add-firefox-esr-to-ubuntu-browsers/+merge/292725

Cheers,
-- 
intrigeri

Bug#822441: libcgal-dev: fails to upgrade from 'jessie' - trying to overwrite /usr/include/CGAL/Qt/PolygonWithHolesGraphicsItem.h

[Andreas Beckmann]

Package: libcgal-dev
Version: 4.8-2
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'jessie'.
It installed fine in 'jessie', then the upgrade to 'sid' fails
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.

See policy 7.6 at
https://www.debian.org/doc/debian-policy/ch-relationships.html#s-replaces

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

  Preparing to unpack .../libcgal-dev_4.8-2_amd64.deb ...
  Unpacking libcgal-dev:amd64 (4.8-2) over (4.5-2) ...
  dpkg: error processing archive 
/var/cache/apt/archives/libcgal-dev_4.8-2_amd64.deb (--unpack):
   trying to overwrite '/usr/include/CGAL/Qt/PolygonWithHolesGraphicsItem.h', 
which is also in package libcgal-qt4-dev 4.5-2


cheers,

Andreas


libcgal-qt4-dev=4.5-2_libcgal-dev=4.8-2.log.gz
Description: application/gzip

Bug#821022: python-lldb-3.8: Broken symlinks _lldb.so and libLLVM-3.8.0.so.1

[Sylvestre Ledru]

Hello,
Le 24/04/2016 à 10:08, Graham Inggs a écrit :
> Confirming.  Python-lldb-3.8 has missing dependencies and some broken 
> symlinks.
>
> After installing python-lldb-3.8, I needed to take the steps below (as
> root) before I could 'import lldb' successfully.
>
> apt-get install lldb-3.8 liblldb-3.8 liblldb-3.8-dev
>
> cd /usr/lib/llvm-3.8/lib/python2.7/site-packages/lldb
> rm libLLVM-3.8.0.so.1
> ln -s ../../../../../x86_64-linux-gnu/libLLVM-3.8.0.so.1 libLLVM-3.8.0.so.1
> rm libLLVM-3.8.so.1
> ln -s ../../../../../x86_64-linux-gnu/libLLVM-3.8.0.so.1 libLLVM-3.8.so.1
> rm _lldb.so
> ln -s ../../../../../x86_64-linux-gnu/liblldb-3.8.so _lldb.so
>
> ___
> Pkg-llvm-team mailing list
> pkg-llvm-t...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-llvm-team

yes, this is fine. A patch would be appreciated as I don't have the
bandwidth for the next two weeks.

Sylvestre

Bug#822421: python-jswebkit: remove from Debian?

[Aron Xu]

> On Apr 24, 2016, at 11:16, Emilio Pozuelo Monfort  wrote:
> 
> Package: python-jswebkit
> Version: 0.0.3-2
> Severity: important
> 
> Hi,
> 
> python-jswebkit are bindings for the old, deprecated, to-be-removed
> webkit1. Given there are newer bindings available for both webkit1
> and webkit2 using GObject introspection (gir1.2-javascriptcoregtk-3.0
> and gir1.2-javascriptcoregtk-4.0 respectively), I think we should
> drop python-jswebkit.
> 
> Thoughts?
> 
> If I don't hear back from you I'll make this an RM bug.
> 
> Cheers,
> Emilio

Please go ahead and remove it, ty!

Best,
Aron

Bug#822342: xinit: startx fails with AddScreen/ScreenInit failed for driver 0

[Julien Cristau]

On Sat, Apr 23, 2016 at 18:18:56 +0200, Attila Kinali wrote:

> Package: xinit
> Version: 1.3.4-3
> Severity: important
> 
> Dear Maintainer,
> 
> I am not sure whether this is the right package to file the bug against.
> 
> I just updated my system and the following x related packages got updated:
> xorg amd64 1:7.7+14
> xorg-dev all 1:7.7+14
> xserver-xorg amd64 1:7.7+14
> xserver-xorg-input-all amd64 1:7.7+14
> xserver-xorg-video-amdgpu amd64 1.1.0-1
> xserver-xorg-video-radeon amd64 1:7.7.0-1
> xserver-xorg-video-ati amd64 1:7.7.0-1
> xserver-xorg-video-all amd64 1:7.7+14
> xserver-xorg-video-intel amd64 2:2.99.917+git20160325-1
> xserver-xorg-core amd64 2:1.18.3-1
> xserver-xorg-legacy amd64 2:1.18.3-1
> x11-xserver-utils amd64 7.7+7
> xserver-common all 2:1.18.3-1
> 
> 
> The problem is similar (the same?) as #803364, startx fails to run seemingly
> lacking permission to run. Running startx as root works. Also using xdm
> instead of startx works.
> 
> I don't have systemd installed, which makes the use of xserver-xorg-legacy,
> respectively Xorg.wrap necessary.
> 
Is libpam-systemd installed?

Cheers,
Julien

Bug#822266: paraview: diff for NMU version 5.0.1+dfsg1-5.1

[Tobias Frost]

Control: tags 822266 + patch
Control: tags 822266 + pending

Dear maintainer,

I've prepared an NMU for paraview (versioned as 5.0.1+dfsg1-5.1) and
uploaded it to DELAYED/5. Please feel free to tell me if I
should delay it longer.

Regards.
diff -Nru paraview-5.0.1+dfsg1/debian/changelog 
paraview-5.0.1+dfsg1/debian/changelog
--- paraview-5.0.1+dfsg1/debian/changelog   2016-04-20 21:11:49.0 
+0200
+++ paraview-5.0.1+dfsg1/debian/changelog   2016-04-24 16:55:06.0 
+0200
@@ -1,3 +1,11 @@
+paraview (5.0.1+dfsg1-5.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTBFS on kfreebsd-* by including the required headers not only on
+linux but also on kfreebsd. (Closes: #822266)
+
+ -- Tobias Frost   Sun, 24 Apr 2016 16:55:06 +0200
+
 paraview (5.0.1+dfsg1-5) unstable; urgency=medium
 
   * [ad5f3f0] Fix FTBFS against ffmpeg_3.0. (Closes: #821419)
diff -Nru paraview-5.0.1+dfsg1/debian/patches/fix-ftbfs-kfreebsd.patch 
paraview-5.0.1+dfsg1/debian/patches/fix-ftbfs-kfreebsd.patch
--- paraview-5.0.1+dfsg1/debian/patches/fix-ftbfs-kfreebsd.patch
1970-01-01 01:00:00.0 +0100
+++ paraview-5.0.1+dfsg1/debian/patches/fix-ftbfs-kfreebsd.patch
2016-04-24 15:47:03.0 +0200
@@ -0,0 +1,18 @@
+Description: Fix FTBFS on kfreeBSD
+ also include the linux heraders for this arch
+Author: Tobias Frost 
+Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=822266
+Last-Update: 2014-04-24
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+--- a/Plugins/CDIReader/cdilib.c
 b/Plugins/CDIReader/cdilib.c
+@@ -47,7 +47,7 @@
+ #define _XOPEN_SOURCE 600
+ #endif
+ 
+-#ifdef __linux__ 
++#if defined (__linux__) || defined (__FreeBSD_kernel__)
+   #include 
+   #include 
+   #include 
diff -Nru paraview-5.0.1+dfsg1/debian/patches/series 
paraview-5.0.1+dfsg1/debian/patches/series
--- paraview-5.0.1+dfsg1/debian/patches/series  2016-04-20 15:54:06.0 
+0200
+++ paraview-5.0.1+dfsg1/debian/patches/series  2016-04-24 10:44:40.0 
+0200
@@ -8,3 +8,4 @@
 use_system_mpi4py.patch
 remove_webgl.patch
 ffmpeg.patch
+fix-ftbfs-kfreebsd.patch

Bug#822442: pulseaudio: Missing extra-hdmi.conf file

[Corcodel Marian]

Package: pulseaudio
Version: 8.0-2+b2
Severity: normal

On my card internal Intel pulseaudio fail to start , check  file "extra-
hdmi.conf profile set on
/etc/udev/rules.d/90-pulseaudio.rules but not found.



-- Package-specific info:
File '/etc/default/pulseaudio' does not exist


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

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

Versions of packages pulseaudio depends on:
ii  adduser   3.113+nmu3
ii  libasound21.1.0-1
ii  libasound2-plugins1.1.0-1+b1
ii  libc6 2.19-18+deb8u4
ii  libcap2   1:2.24-8
ii  libdbus-1-3   1.10.8-1
ii  libfftw3-single3  3.3.4-2
ii  libgcc1   1:4.9.2-10
ii  libice6   2:1.0.9-1+b1
ii  libltdl7  2.4.6-0.1
ii  liborc-0.4-0  1:0.4.25-1
ii  libpulse0 8.0-2+b2
ii  libsm62:1.2.2-1+b1
ii  libsndfile1   1.0.25-9.1+deb8u1
ii  libsoxr0  0.1.2-1
ii  libspeexdsp1  1.2~rc1.2-1
ii  libstdc++65.3.1-15
ii  libsystemd0   229-4
ii  libtdb1   1.3.6-0+deb8u1
ii  libudev1  229-4
ii  libwebrtc-audio-processing-0  0.1-3
ii  libx11-6  2:1.6.2-3
ii  libx11-xcb1   2:1.6.2-3
ii  libxcb1   1.10-3+b1
ii  libxtst6  2:1.2.2-1+b1
ii  lsb-base  4.1+Debian13+nmu1
ii  pulseaudio-utils  8.0-2+b2
ii  udev  229-4

Versions of packages pulseaudio recommends:
ii  pulseaudio-module-x11  8.0-2+b2
ii  rtkit  0.11-2

Versions of packages pulseaudio suggests:
pn  paman
pn  paprefs  
ii  pavucontrol  2.0-3
pn  pavumeter

-- no debconf information
# This file is part of PulseAudio.
#
# PulseAudio is free software; you can redistribute it and/or modify
# it under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
#
# PulseAudio 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.
#
# You should have received a copy of the GNU Lesser General Public License
# along with PulseAudio; if not, see .

## Configuration file for PulseAudio clients. See pulse-client.conf(5) for
## more information. Default values are commented out.  Use either ; or # for
## commenting.

; default-sink =
; default-source =
; default-server =
; default-dbus-server =

; autospawn = yes
; daemon-binary = /usr/bin/pulseaudio
; extra-arguments = --log-target=syslog

; cookie-file =

; enable-shm = yes
; shm-size-bytes = 0 # setting this 0 will use the system-default, usually 64 
MiB

; auto-connect-localhost = no
; auto-connect-display = no
# This file is part of PulseAudio.
#
# PulseAudio is free software; you can redistribute it and/or modify
# it under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
#
# PulseAudio 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.
#
# You should have received a copy of the GNU Lesser General Public License
# along with PulseAudio; if not, see .

## Configuration file for the PulseAudio daemon. See pulse-daemon.conf(5) for
## more information. Default values are commented out.  Use either ; or # for
## commenting.

; daemonize = no
; fail = yes
; allow-module-loading = yes
; allow-exit = yes
; use-pid-file = yes
; system-instance = no
; local-server-type = user
; enable-shm = yes
; shm-size-bytes = 0 # setting this 0 will use the system-default, usually 64 
MiB
; lock-memory = no
; cpu-limit = no

; high-priority = yes
; nice-level = -11

; realtime-scheduling = yes
; realtime-priority = 5

; exit-idle-time = 20
; scache-idle-time = 20

; dl-search-path = (depends on architecture)

; load-default-script-file = yes
; default-script-file = /etc/pulse/default.pa

; log-target = auto
; log-level = notice
; log-meta = no
; log-time = no
; log-backtrace = 0

; resample-method = speex-float-1
; enable-remixing = yes
; enable-lfe-remixing = yes
; lfe-crossover-freq = 120

; flat-volumes = yes

Bug#822443: linux-image-4.4.0-1-amd64: Dell XPS-13 9350 (DE) backlight not detected

[Ian Jackson]

Package: src:linux
Version: 4.4.6-1
Severity: normal

On my new Dell XPS-13 Developer Edition, running stretch (installed
from Stretch Alpha 5), the screen backlight is not detected.

/sys/class/backlight is empty.


The system came with an OEM install of Ubuntu trusty, which has
working backlight controls and has this in /sys/class/backlight:
 lrwxrwxrwx 1 root root 0 Apr 24 13:18 intel_backlight ->
 ../../devices/pci:00/:00:02.0/drm/card0/card0-eDP-1/intel_backlight
echoing things into the appropriate file there changes the brightness
as expected, on trusty.

That's with linux-image-3.19.0-58-generic from trusty,
FYI Ubuntu's apt-get source informs me:
  Picking 'linux-lts-vivid' as source package instead of 
'linux-image-3.19.0-58-generic'
  NOTICE: 'linux-lts-vivid' packaging is maintained in the 'Git' version 
control system at:
  http://kernel.ubuntu.com/git-repos/ubuntu/ubuntu-trusty.git



FYI, other things, which may or may not be relevant:

 * I have to boot with `nomodeset' or the screen goes blank during
   boot.  The X server works just fine.

 * Resume from suspend does not work.  It's hard to tell exactly, but
   I have at leaast once had a resume which was successful apart from
   the fact that the display was black: I had suspended from a text
   console, on which I was logged in, and on resume I was able to
   type commands which were then executed.

 * Hibernation seems to sometimes not work; again, black screen.

 * At least once, after a failed resume, I saw (in very strong
   sunlight) a very faint pattern on the screen, which might have been
   due to the screen displaying the expected picture but without the
   backlight.

 * Cursory inspection of logs recorded on-disk after a failed resume
   seems to suggest that the resume was mostly successful from the
   point of view of the OS, even though the screen did not show
   anything.

 * The provided Ubuntu install doesn't seem to work entirely properly.
   I haven't bothered debugging the issues with it, except to the
   extent needed to use the Ubuntu install as a comparator for
   hardware support problems etc.

 * The laptop also has a keyboard backlight.  This seems to be handled
   entirely by a peripheral controller or something; the key (FN+F10)
   for adjusting its brightness shows up in acpi_listen as an unknown
   ACPI event, but works in all contexts (including the BIOS, grub,
   and the stretch kernel).  (I'm mostly using acpi-support for magic
   key handling.)

 * I'm using a customised version of xf86-input-mtrack to get the
   trackpad to behave the way I want it to.  I don't think this is
   relevant.

 * I'm using sysvinit as pid 1 rather than systemd.  My display
   manager is lightdm.  My login session does use systemd-logind.

I suspect that the backlight problem is relevant to (perhaps even the
only cause of) the suspend failures.


I'm happy to provide more information, carry out experiments, etc.
These issues are a high priority for me so you should find me
responsive :-).


Thanks,
Ian.


-- Package-specific info:
** Version:
Linux version 4.4.0-1-amd64 (debian-ker...@lists.debian.org) (gcc version 5.3.1 
20160307 (Debian 5.3.1-11) ) #1 SMP Debian 4.4.6-1 (2016-03-17)

** Command line:
BOOT_IMAGE=/vmlinuz-4.4.0-1-amd64 root=/dev/mapper/vg--zealot2-lv--root ro 
nomodeset quiet

** Not tainted

** Kernel log:
[ 1361.182521] PM: Saving platform NVS memory
[ 1361.196094] Disabling non-boot CPUs ...
[ 1361.196897] Broke affinity for irq 283
[ 1361.198014] smpboot: CPU 1 is now offline
[ 1361.200203] Broke affinity for irq 276
[ 1361.200212] Broke affinity for irq 283
[ 1361.201289] smpboot: CPU 2 is now offline
[ 1361.204420] Broke affinity for irq 1
[ 1361.204428] Broke affinity for irq 8
[ 1361.204434] Broke affinity for irq 9
[ 1361.204441] Broke affinity for irq 12
[ 1361.204447] Broke affinity for irq 14
[ 1361.204454] Broke affinity for irq 16
[ 1361.204461] Broke affinity for irq 17
[ 1361.204469] Broke affinity for irq 51
[ 1361.204506] Broke affinity for irq 275
[ 1361.204513] Broke affinity for irq 276
[ 1361.204520] Broke affinity for irq 283
[ 1361.205569] smpboot: CPU 3 is now offline
[ 1361.207667] PM: Creating hibernation image:
[ 1361.403818] PM: Need to copy 351458 pages
[ 1361.403820] PM: Normal pages needed: 351458 + 1024, available pages: 3802049
[ 1361.208985] PM: Restoring platform NVS memory
[ 1361.210117] ACPI : EC: EC started
[ 1361.210910] Enabling non-boot CPUs ...
[ 1361.211000] x86: Booting SMP configuration:
[ 1361.211000] smpboot: Booting Node 0 Processor 1 APIC 0x2
[ 1361.215124]  cache: parent cpu1 should not be sleeping
[ 1361.215271] CPU1 is up
[ 1361.215342] smpboot: Booting Node 0 Processor 2 APIC 0x1
[ 1361.219346]  cache: parent cpu2 should not be sleeping
[ 1361.219484] CPU2 is up
[ 1361.219559] smpboot: Booting Node 0 Processor 3 APIC 0x3
[ 1361.223474]  cache: parent cpu3 should not be sleeping
[ 1361.223615] CPU3 is up
[ 1361.228814] ACPI: Waking up from system sl

Bug#289632: RFP: brlcad -- BRL-CAD is a constructive solid geometry (CSG) solid modeling computer-aided design (CAD) system

[Francesco Poli]

Control: merge 705640 816543


On Wed, 2 Mar 2016 19:27:53 + shirish शिरीष wrote:

> Package: wnpp
> Severity: wishlist
> 
> * Package name: brlcad
>   Version : 7.24.2
>   Upstream Author : Army Research Laboratary
> * URL : brlcad.org
> * License : BSD, LGPL
>   Programming Lang: C, C++, Tcl
>   Description : BRL-CAD is a constructive solid geometry (CSG)
> solid modeling computer-aided design (CAD) system
> 
> BRL-CAD is a constructive solid geometry (CSG) solid modeling
> computer-aided design (CAD) system. It includes an interactive
> geometry editor, ray tracing support for graphics rendering and
> geometric analysis, computer network distributed framebuffer support,
> scripting, image-processing and signal-processing tools.

Hello, there are already other three (merged) RFP bugs open for BRL-CAD.
I am merging this fourth bug with the others.

I hope someone will finally convert these bugs into ITP bugs and create
the package... Thanks to anyone who is willing to step in.

Bye.
 

-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpHcTkyrRDiv.pgp
Description: PGP signature

Bug#822444: clamav-daemon does not start with same options using sysinit and systemd

[xavier quost]

Package: clamav-daemon
Version: 0.99+dfsg-0+deb8u2
Severity: important

Dear Maintainer,

It seems that clamav-daemon does not start with thes sames options when using 
systemd or sysvinit.
This leads to problem with clamsmtp / clamd communication breaking mail 
checking systeme.

when using sysv 

## check sysv
# pidof /sbin/init 
1
# pidof systemd  
zsh: exit 1 pidof systemd


clamd process is started with those default options :
# ps -ef |grep clam   
clamav6673 1  0 16:53 ?00:00:00 /usr/bin/freshclam -d --quiet 
--config-file=/etc/clamav/freshclam.conf --pid=/run/clamav/freshclam.pid
clamav8357 1  0 16:57 ?00:00:00 /usr/sbin/clamd -c 
/etc/clamav/clamd.conf --pid=/run/clamav/clamd.pid
clamsmtp  8409 1  0 16:58 ?00:00:00 /usr/sbin/clamsmtpd
root  8430  4011  0 16:58 pts/000:00:00 grep clam


and communication between clamsmtp and clamd works (extract from mail.info) :
Apr 24 16:59:47 pc251270 postfix/pickup[3311]: 39761221B8E: uid=0 from=
Apr 24 16:59:47 pc251270 postfix/cleanup[8443]: 39761221B8E: 
message-id=<20160424145947.39761221...@pc251270.valfontenay.ratp>
Apr 24 16:59:47 pc251270 postfix/qmgr[3312]: 39761221B8E: 
from=, size=459, nrcpt=1 (queue active)
Apr 24 16:59:47 pc251270 clamsmtpd: 10: accepted connection from: 127.0.0.1
Apr 24 16:59:47 pc251270 postfix/smtpd[8447]: connect from localhost[127.0.0.1]
Apr 24 16:59:47 pc251270 postfix/smtpd[8447]: 4956C221DD1: 
client=localhost[127.0.0.1]
Apr 24 16:59:47 pc251270 postfix/cleanup[8443]: 4956C221DD1: 
message-id=<20160424145947.39761221...@pc251270.valfontenay.ratp>
 

switching to systemd (and rebooting ;-)) )


## check systemd
# pidof systemd   
1188
# pidof /sbin/init
1190 1188 1


## it seems that clamav-daemon is no more start with good options
# ps -ef |grep clam  
clamav 678 1  0 17:11 ?00:00:00 /usr/bin/freshclam -d 
--foreground=true
clamsmtp   747 1  0 17:11 ?00:00:00 /usr/sbin/clamsmtpd
clamav 791 1  7 17:11 ?00:00:07 /usr/sbin/clamd 
--foreground=true
root  1996  1733  0 17:12 pts/000:00:00 grep clam


Communication beetween clamsmtp and clamd is now failing 
Apr 24 17:14:02 pc251270 postfix/pickup[1163]: 3CC4F221B8E: uid=1000 
from=
Apr 24 17:14:02 pc251270 postfix/cleanup[2006]: 3CC4F221B8E: 
message-id=<20160424151402.3cc4f221...@pc251270.valfontenay.ratp>
Apr 24 17:14:02 pc251270 postfix/qmgr[1164]: 3CC4F221B8E: 
from=, size=473, nrcpt=1 (queue active)
Apr 24 17:14:02 pc251270 clamsmtpd: 10: accepted connection from: 127.0.0.1
Apr 24 17:14:02 pc251270 postfix/smtpd[2010]: connect from localhost[127.0.0.1]
Apr 24 17:14:02 pc251270 postfix/smtpd[2010]: 535FA221DD1: 
client=localhost[127.0.0.1]
Apr 24 17:14:02 pc251270 clamsmtpd: 10: clamav error: 
/var/spool/clamsmtp/clamsmtpd.9g7gF4: lstat() failed: Permission denied. ERROR
Apr 24 17:14:02 pc251270 clamsmtpd: 10: 
from=xqu...@pc251270.valfontenay.ratp, to=xquost@localhost, status=CLAMAV-ERROR

Thanks, best regards

XQ


Clamsmtp configuration file :
# --
#SAMPLE CLAMSMTPD CONFIG FILE
# --
# 
# - Comments are a line that starts with a #
# - All the options are found below with their defaults commented out


# The address to send scanned mail to. 
# This option is required unless TransparentProxy is enabled
OutAddress: 10026

# The maximum number of connection allowed at once.
# Be sure that clamd can also handle this many connections
#MaxConnections: 64

# Amount of time (in seconds) to wait on network IO
#TimeOut: 180

# Address to listen on (defaults to all local addresses on port 10025)
Listen: 127.0.0.1:10025

# The address clamd is listening on
ClamAddress: /var/run/clamav/clamd.ctl

# A header to add to all scanned email
#Header: X-AV-Checked: ClamAV using ClamSMTP

# Directory for temporary files
TempDirectory: /var/spool/clamsmtp

# PidFile: location of PID file
PidFile: /var/run/clamsmtp/clamsmtpd.pid

# Whether or not to bounce email (default is to silently drop)
#Bounce: off

# Whether or not to keep virus files 
#Quarantine: off

# Enable transparent proxy support 
#TransparentProxy: off

# User to run as
User: clamsmtp

# Virus actions: There's an option to run a script every time a 
# virus is found. Read the man page for clamsmtpd.conf for details.



-- Package-specific info:
--- configuration ---
Checking configuration files in /etc/clamav

Config file: clamd.conf
---
LogFile = "/var/log/clamav/clamav.log"
StatsHostID = "auto"
StatsEnabled disabled
StatsPEDisabled = "yes"
StatsTimeout = "10"
LogFileUnlock disabled
LogFileMaxSize = "4294967295"
LogTime = "yes"
LogClean disabled
LogSyslog disabled
LogFacility = "LOG_LOCAL6"
LogVerbose disabled
LogRotate = "yes"
ExtendedDetectionInfo = "yes"
PidFile 

Bug#799619: kio: FTBFS on hurd-i386: warning about posix_fadvise

[Samuel Thibault]

Samuel Thibault, on Sun 24 Apr 2016 13:00:44 +0200, wrote:
> In the meanwhile, the hurd-i386 port looks in terribly bad shape due to
> all the not-rebuilt KDE packages.

(it would be good to have a kio upload before the migration to the
newer qt/kio/etc. currently in experimental, so we get to see possible
unrelated build failures of KDE packages.)

Samuel

Bug#820589: jessie-pu: package opam/1.2.0-1+deb8u1

[Jonathan Wiltshire]

Control: tag -1 pending

On 2016-04-23 16:58, Mehdi Dogguy wrote:

On 20/04/2016 11:50, Julien Cristau wrote:

Control: tags -1 confirmed

On Mon, Apr 11, 2016 at 00:57:58 +0200, Mehdi Dogguy wrote:


Hi,

On 10/04/2016 17:27, Julien Cristau wrote:

--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+opam (1.2.0-1+deb8u1) jessie; urgency=medium
+
+  * Stop using insecure and no-check-certificate flags when 
fetching

+files using wget and curl.
+


Missing "closes:"?



Fixed in attached new diff.


Looks fine, thanks.



Uploaded, thanks!


Flagged for acceptance.


--
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51

 i have six years of solaris sysadmin experience, from
8->10. i am well qualified to say it is made from bonghits
layered on top of bonghits

Bug#822445: libgc: update symbols for nios2

[Helmut Grohne]

Source: libgc
Version: 1:7.4.2-7.4
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

Hi,

nios2 is a new architecture and since libgc has quite a few architecture
specific symbols, these need to be updated for nios2. Luckily, nios2
behaves exactly like arm64 with respect to libgc symbols. The following
sed invocation will update the symbols file to work with nios2:

sed -i -e '/^ /s/=\(!\?\)arm64 /&\1nios2 /' debian/libgc1c2.symbols

Helmut

Bug#820295: network-manager-pptp: pppd segfaults when NM tries to establish PPTP connection since 1.1.92-1

[Vladimir K]

Upgraded to 1.2.0, the bug is gone.

Bug#798167: [Debian-med-packaging] Bug#798167: camitk and vtk/itk transitions

[Emmanuel Promayon]

Dear all,

I am just back from vacation and sorry for my silence during last week.

On 20/04/16 23:21, Mattia Rizzolo wrote:

On Wed, Apr 20, 2016 at 10:12:45PM +0200, Tobias Frost wrote:
> (If you go for experimental, please reopen the RM bug for the binaries
> in sid once it enters the archives)

In the case this goes to experimental the right kind of thing to do is
to completely remove it from unstable (sources included).  This might
seems harsh, but it's really not :)

But I'm not sure what would be the problem of having it on experimental:
if the only problem this thing has is that it misrenders images on some
cards, then I'd say to upload this version to unstable, and block it
there with another RC bug on it, and treat it as a separate bug.  I know
voluntarily introducing a bug is bad, but I'd weight it against *this*
bug, and keeping in mind we're talking about debian *unstable*.


Maintainers, what do you think?
Can you prepare an upload, maybe based on Gianfranco's work?  Or either
say that what he did is "Great And Blessed" and confirm that you're cool
with us uploading it? :)
And tell us what you prefers between uploading the new in experimental
and removing the current one from unstable or uploading this directly to
unstable.


I am only a beginner in packaging, and I completely trust Mattia, Tobias, 
Andreas and Gianfranco knowledge and experience.

I checked Gianfranco's experimental branch and his work is great! There is few 
build-depend packages that can be removed (and I noticed the problem with the 
pixmaps), but this would be my pleasure to fix that very soon.

I agree that the display bug, although a priority for upstream, should not 
delay any debian cleaning up.

Unfortunately I will not be able to work on the package (not at least for 
another week and a half).

Therefore, I hereby declare that what Gianfranco did is great and blessed! 
Thanks you very much!
If Gianfranco and everyone else is ok with it (I did not have time to check the 
packaging here), it would be great if it can be uploaded directly in unstable.
In the next few weeks, hopefully upstream 4.0.1 will solve the display bug and 
I can polish the packaging.

Thanks you again all for your work, it is amazing how every time there is 
something new to learn!

Emmanuel


--
Emmanuel Promayon, Maitre de conférences
Univ. Grenoble Alpes / Polytech Grenoble
Laboratoire TIMC-IMAG / équipe GMCAO
Tel. +33/0 456 52 00 03




smime.p7s
Description: S/MIME Cryptographic Signature