Bug#832405: tex-common: fmtutil failed to build pdftex/cont-en xetex/cont-en as cont-en.mkii missing

[cp . montanari]

Package: tex-common
Version: 6.05
Severity: normal

Dear Maintainer,

this tex-common does not install on my system,
here is the end of the fmtutil log...:

"...
Running mktexlsr. This may take some time... done.
Running updmap-sys. This may take some time... done.
Running mktexlsr /var/lib/texmf ... done.
Building format(s) --all.
This may take some time... 
fmtutil failed. Output has been stored in
/tmp/fmtutil.5xBG5aqo
Please include this file if you report a bug.
"..."
font\OMS/cmsy/m/n/5=cmsy5
\font\OMS/cmsy/m/n/7=cmsy7
\font\OMS/cmsy/m/n/10=cmsy10
14 preloaded fonts
warning  (pdf backend): no pages of output.
Transcript written on lualatex.log.
fmtutil [INFO]: /var/lib/texmf/web2c/luatex/lualatex.fmt installed.
fmtutil [WARNING]: inifile cont-en.mkii for cont-en/pdftex not found.
fmtutil [WARNING]: inifile cont-en.mkii for cont-en/xetex not found.
fmtutil [INFO]: Disabled formats: 3
fmtutil [INFO]: Successfully rebuilt formats: 19
fmtutil [INFO]: Failed to build: 2 (pdftex/cont-en xetex/cont-en)
fmtutil [INFO]: Total formats: 24
fmtutil [INFO]: exiting with status 2
..."

I wonder if this is the right problem? and how to generate this  "cont-en.mkii" 
file?


PTZ.


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

Versions of packages tex-common depends on:
ii  dpkg  1.18.9
ii  ucf   3.0036

tex-common recommends no packages.

Versions of packages tex-common suggests:
ii  debhelper  9.20160709

Versions of packages texlive-base depends on:
ii  debconf [debconf-2.0]  1.5.59
ii  libpaper-utils 1.1.24+nmu4
ii  texlive-binaries   2016.20160513.41080-4
ii  ucf3.0036
ii  xdg-utils  1.1.1-1

Versions of packages texlive-base recommends:
ii  lmodern  2.004.5-3

Versions of packages texlive-base suggests:
ii  ghostscript [postscript-viewer]  9.19~dfsg-1+b1
ii  gv [postscript-viewer]   1:3.7.4-1
ii  okular [postscript-viewer]   4:16.04.2-1
ii  perl-tk  1:804.033-1+b2
ii  xpdf [pdf-viewer]3.04-1+b1

Versions of packages texlive-binaries depends on:
ii  dpkg  1.18.9
ii  install-info  6.1.0.dfsg.1-8
ii  libc6 2.23-2
ii  libcairo2 1.14.6-1+b1
ii  libfontconfig12.11.0-6.4
ii  libfreetype6  2.6.3-3+b1
ii  libgcc1   1:6.1.1-9
ii  libgmp10  2:6.1.1+dfsg-1
ii  libgraphite2-31.3.8-1
ii  libgs99.19~dfsg-1+b1
ii  libharfbuzz-icu0  1.2.7-1
ii  libharfbuzz0b 1.2.7-1
ii  libice6   2:1.0.9-1+b1
ii  libicu55  55.1-7
ii  libkpathsea6  2016.20160513.41080-4
ii  libmpfr4  3.1.4-2
ii  libpaper1 1.1.24+nmu4
ii  libpixman-1-0 0.33.6-1
ii  libpng16-16   1.6.23-1
ii  libpoppler61  0.44.0-3
ii  libpotrace0   1.13-2
ii  libptexenc1   2016.20160513.41080-4
ii  libsm62:1.2.2-1+b1
ii  libstdc++66.1.1-9
ii  libsynctex1   2016.20160513.41080-4
ii  libtexlua52   2016.20160513.41080-4
ii  libtexluajit2 2016.20160513.41080-4
ii  libx11-6  2:1.6.3-1
ii  libxaw7   2:1.0.13-1
ii  libxext6  2:1.3.3-1
ii  libxi62:1.7.6-1
ii  libxmu6   2:1.1.2-2
ii  libxpm4   1:3.5.11-1+b1
ii  libxt61:1.1.5-1
ii  libzzip-0-13  0.13.62-3
ii  perl  5.22.2-2
ii  t1utils   1.39-2
ii  zlib1g1:1.2.8.dfsg-2+b1

Versions of packages texlive-binaries recommends:
ii  python2.7.11-2
ii  ruby  1:2.3.0+4
ii  texlive-base  2016.20160623-1
ii  tk [wish] 8.6.0+9

-- debconf information:
  texlive-base/texconfig_ignorant:
  tex-common/check_texmf_wrong:
  texlive-base/binary_chooser: pdftex, dvips, dvipdfmx, xdvi
  tex-common/check_texmf_missing:

--- fmtutil full log...:

*** /tmp/fmtutil.5xBG5aqo
fmtutil: fmtutil is using the following fmtutil.cnf files (in precedence order):
fmtutil:   /var/lib/texmf/web2c/fmtutil.cnf
fmtutil:   /usr/share/texmf/web2c/fmtutil.cnf
fmtutil:   /usr/share/texlive/texmf-dist/web2c/fmtutil.cnf
fmtutil: fmtutil is using the following fmtutil.cnf file for writing changes:
fmtutil:   /etc/texmf/web2c/fmtutil.cnf
fmtutil [INFO]: writing formats under /var/lib/texmf/web2c
fmtutil [INFO]: --- remaking luatex with luatex
fmtutil: running `luatex -ini   -jobname=luatex -progname=luatex luatex.ini' ...
This is LuaTeX, Version 0.95.0 (TeX Live 2016/Debian)  (INITEX)
 restricted system commands enabled.
(/usr/share/texlive/texmf-dist/tex/generic/tex-ini-files/luatex.ini
(/usr/share/texlive/texmf-dist/tex/generic/tex-ini-files/luatexconfig.tex
(/var/lib/texmf/tex/generic/config/pdftexconfig.tex))
(/usr/share/texlive/texmf-dist/tex/generic/config/luatexiniconfig.tex)

Bug#708296: git-buildpackage: gbp-pull "sleeps" with git+ssh:// and ssh sockets

[gregor herrmann]

On Mon, 25 Jul 2016 08:45:28 +0200, Guido Günther wrote:

> > > Here's a possible solution within openssh:
> > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=714526
> > Great, thanks!
> This work now since this bug has been fixed with the recent ssh upload.

Confirmed, I was very happy to test the new ssh successfully :)
(And I had forgotten that _this_ bug was still open, sorry for that.)

Cheers,
gregor

-- 
 .''`.  Homepage https://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06
 : :' : Debian GNU/Linux user, admin, and developer -  https://www.debian.org/
 `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   BOFH excuse #420:  Feature was not beta tested 

Bug#778778: [libarchive13] Missing some files zip archive

[Alexandr Danilow]

The Ark version 16.04.3 archive opened correctly, thank you.

Bug#755287: src:libmng: Please upload new version

[Kartik Mistry]

On Sat, Mar 12, 2016 at 10:49 PM, Kartik Mistry  wrote:
> On Sat, Mar 12, 2016 at 9:23 PM, Manuel A. Fernandez Montecelo
>  wrote:
>> Working along with Helmut, he determined that the problem was to use -cc
>> instead of -gcc.
>>
>> So I pushed one more change:
>>
>>  Use "CC = $(DEB_HOST_GNU_TYPE)-gcc" instead of "-cc"
>>
>> Things build fine and lintian only complains about the latest policy
>> standard version, non-nmu revision (since you signed it, it's not a NMU
>> anymore), and some formatting stuff in d/copyright.
>>
>> Since you are active now and this needs some package-specific knowledge
>> (that I don't have) to deal with rdeps and so on, should I understand
>> that you'll take care of this, or do you prefer me to handle the upload
>> and transition?
>
> I should be able to upload and fix remaining issues.
>
> And, thanks a lot for your work! Would all you like to be
> co-maintainer of the package? If yes, I will add your names and then
> you'll not have to NMU :)

And, this package is up for adoption. CC'ed Amin Tarbalouti who showed interest.

Can you all work together and have a new shiny package? :)

-- 
Kartik Mistry/કાર્તિક મિસ્ત્રી | IRC: kart_
{kartikm, 0x1f1f}.wordpress.com

Bug#832407: GC Warning: Repeated allocation of very large block... May lead to memory leak and poor performance.

[積丹尼 Dan Jacobson]

Package: w3m
Version: 0.5.3-29

w3m -dump https://goo.gl/photos/Ur9cjBQeeC7Qihhy5
gives
GC Warning: Repeated allocation of very large block... May lead to memory leak 
and poor performance.

Bug#832408: amule: I am using Debian 64 8.5(stable release), and I can not find "amule" package, or packages related to it, only found "amule-emc".

[Vita]

Package: amule
Severity: normal

Dear Maintainer,

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

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
-I tryed to search for "amule" package, Debian 8.5 64(stable release), with 
default repositories, I can only find "amule-emc" package, I did not removed 
any official repository. "amule" and related packages, are missing.

jessie debian 8.5 64 main

REPOSITORIES:

http://ftp.es.debian.org/debian/
http://security.debian.org/
http://ftp.es.debian.org/debian/


   * What was the outcome of this action?
   * What outcome did you expect instead?

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


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

Kernel: Linux 4.6.4-gnu (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)

Bug#788546: nfs4 mount.nfs does not respect option "user" in fstab in Jessie

[Ingo]

Am 24.07.2016 um 22:07 schrieb Andreas Henriksson:
>
> Are you sure this is the correct syntax? I would expect that you
> should specify the mountpoint (target directory) rather than the
> source of the mount. eg. mount /home/ingo/leo.Bilder
> Do using that still give you the same problem?

Great, at least that works as expected if target directory is used.

But "man mount" explicitely states:

"When mounting a filesystem mentioned in fstab or mtab, it suffices to
give only the device, or only the mount point."
Moreover my syntax (using the device/source has worked flawlewssly since
I am using Linux. In Debian I use it since Lenny! And it works if the
command is issued as 'root'.

>
> Might also be useful to have a log of what strace tells you about
> running the command.

For completenes here the stace output:

~$ strace -Ff -tt mount leo:/Bilder 2>&1 | tee strace-mount.log

09:54:06.486801 execve("/bin/mount", ["mount", "leo:/Bilder"], [/* 36
vars */]) = 0
09:54:06.487198 brk(0)  = 0x1295000
09:54:06.487350 fcntl(0, F_GETFD)   = 0
09:54:06.487410 fcntl(1, F_GETFD)   = 0
09:54:06.487438 fcntl(2, F_GETFD)   = 0
09:54:06.487465 access("/etc/suid-debug", F_OK) = -1 ENOENT (No such
file or directory)
09:54:06.487533 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such
file or directory)
09:54:06.487571 mmap(NULL, 8192, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f4315787000
09:54:06.487629 access("/etc/ld.so.preload", R_OK) = 0
09:54:06.487704 open("/etc/ld.so.preload", O_RDONLY|O_CLOEXEC) = 3
09:54:06.487742 fstat(3, {st_mode=S_IFREG|0644, st_size=28, ...}) = 0
09:54:06.48 mmap(NULL, 28, PROT_READ|PROT_WRITE, MAP_PRIVATE, 3, 0)
= 0x7f4315786000
09:54:06.487810 close(3)= 0
09:54:06.487846 open("/opt/lib/libmediaclient.so", O_RDONLY|O_CLOEXEC) = 3
09:54:06.487880 read(3,
"\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\340\35\0\0\0\0\0\0"...,
832) = 832
09:54:06.487914 fstat(3, {st_mode=S_IFREG|0755, st_size=64168, ...}) = 0
09:54:06.487948 mmap(NULL, 2161808, PROT_READ|PROT_EXEC,
MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f4315359000
09:54:06.487981 mprotect(0x7f4315368000, 2093056, PROT_NONE) = 0
09:54:06.488017 mmap(0x7f4315567000, 8192, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xe000) = 0x7f4315567000
09:54:06.488061 close(3)= 0
09:54:06.488094 munmap(0x7f4315786000, 28) = 0
09:54:06.488130 open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
09:54:06.488163 fstat(3, {st_mode=S_IFREG|0644, st_size=144332, ...}) = 0
09:54:06.488195 mmap(NULL, 144332, PROT_READ, MAP_PRIVATE, 3, 0) =
0x7f4315763000
09:54:06.488227 close(3)= 0
09:54:06.488259 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such
file or directory)
09:54:06.488297 open("/lib/x86_64-linux-gnu/libmount.so.1",
O_RDONLY|O_CLOEXEC) = 3
09:54:06.488333 read(3,
"\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0P\254\0\0\0\0\0\0"...,
832) = 832
09:54:06.488366 fstat(3, {st_mode=S_IFREG|0644, st_size=284096, ...}) = 0
09:54:06.488400 mmap(NULL, 2383648, PROT_READ|PROT_EXEC,
MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f4315113000
09:54:06.488432 mprotect(0x7f4315156000, 2097152, PROT_NONE) = 0
09:54:06.488465 mmap(0x7f4315356000, 8192, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x43000) = 0x7f4315356000
09:54:06.488504 mmap(0x7f4315358000, 3872, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f4315358000
09:54:06.488542 close(3)= 0
09:54:06.488577 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such
file or directory)
09:54:06.488611 open("/lib/x86_64-linux-gnu/libselinux.so.1",
O_RDONLY|O_CLOEXEC) = 3
09:54:06.488644 read(3,
"\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\20c\0\0\0\0\0\0"...,
832) = 832
09:54:06.488677 fstat(3, {st_mode=S_IFREG|0644, st_size=142728, ...}) = 0
09:54:06.488709 mmap(NULL, 4096, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f4315762000
09:54:06.488745 mmap(NULL, 2246896, PROT_READ|PROT_EXEC,
MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f4314eee000
09:54:06.488777 mprotect(0x7f4314f0f000, 2097152, PROT_NONE) = 0
09:54:06.488814 mmap(0x7f431510f000, 8192, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x21000) = 0x7f431510f000
09:54:06.488852 mmap(0x7f4315111000, 6384, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f4315111000
09:54:06.488890 close(3)= 0
09:54:06.488924 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such
file or directory)
09:54:06.488960 open("/lib/x86_64-linux-gnu/libc.so.6",
O_RDONLY|O_CLOEXEC) = 3
09:54:06.488995 read(3,
"\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0P\34\2\0\0\0\0\0"...,
832) = 832
09:54:06.489028 fstat(3, {st_mode=S_IFREG|0755, st_size=1738176, ...}) = 0
09:54:06.489061 mmap(NULL, 3844640, PROT_READ|PROT_EXEC,
MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f4314b43000
09:54:06.489094 mprotect(0x7f4314ce5000, 2093056, PROT_NONE) = 0
09:54:06.489128 mmap(0x7f4314ee4000,

Bug#832409: thunar-dropbox-plugin: FTBFS.. /usr/bin/env: 'python': No such file or directory

[Andreas Beckmann]

Package: thunar-dropbox-plugin
Version: 0.2.1+dfsg1-2
Severity: serious
Justification: fails to build from source (but built successfully in the past)

Hi,

thunar-dropbox-plugin FTBFS in current sid:

 fakeroot debian/rules clean
dh clean
   dh_testdir
   debian/rules override_dh_auto_clean
make[1]: Entering directory '/build/thunar-dropbox-plugin-0.2.1+dfsg1'
./waf distclean --nocache
/usr/bin/env: 'python': No such file or directory
debian/rules:26: recipe for target 'override_dh_auto_clean' failed
make[1]: *** [override_dh_auto_clean] Error 127
make[1]: Leaving directory '/build/thunar-dropbox-plugin-0.2.1+dfsg1'
debian/rules:14: recipe for target 'clean' failed
make: *** [clean] Error 2
dpkg-buildpackage: error: fakeroot debian/rules clean gave error exit status 2


There are two problems here:

* /usr/bin/env is used to lookup python
  
https://www.debian.org/doc/packaging-manuals/python-policy/ch-python.html#s-interpreter_loc

* python is not found in the minimal chroot (some transitive 
  Build-Depends: python seems to have gone away)


Andreas


thunar-dropbox-plugin_0.2.1+dfsg1-2.log.gz
Description: application/gzip

Bug#831039: totem crash on startup, can't start it

[Andrea Zagli]

same here

and i have the same problem with rhytmnbox and epiphany (if i open  
some video, as in youtube)


it seems the problem is "solved" using locale C

Bug#832405: tex-common: fmtutil failed to build pdftex/cont-en xetex/cont-en as cont-en.mkii missing

[Preuße]

On 25.07.2016 09:11, cp.montan...@tiscali.co.uk wrote:

Hi,


this tex-common does not install on my system,
here is the end of the fmtutil log...:

"...
Running mktexlsr. This may take some time... done.
Running updmap-sys. This may take some time... done.
Running mktexlsr /var/lib/texmf ... done.
Building format(s) --all.
This may take some time...



And this is the head:


--- fmtutil full log...:

*** /tmp/fmtutil.5xBG5aqo
fmtutil: fmtutil is using the following fmtutil.cnf files (in precedence order):
fmtutil:   /var/lib/texmf/web2c/fmtutil.cnf
fmtutil:   /usr/share/texmf/web2c/fmtutil.cnf
fmtutil:   /usr/share/texlive/texmf-dist/web2c/fmtutil.cnf
fmtutil: fmtutil is using the following fmtutil.cnf file for writing changes:
fmtutil:   /etc/texmf/web2c/fmtutil.cnf

That file /etc/texmf/web2c/fmtutil.cnf is not delivered w/ Debian, 
instead normally the files in /var are used. I guess that file contains 
a reference to the context formats, although context is not installed.


Try two things:
1. Does installing context solves your problem?
2. Please send a copy of the file /etc/texmf/web2c/fmtutil.cnf.

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

Bug#831962: binary packages in recent z3 uploads

[Gianfranco Costamagna]

Hi,



>I will have another look at this, although I probably won't get around
>to doing that before next week.


not really needed, I did have another look, and you are correct.
I forgot the rationale for the change, but now that I look at it again,
it seems the only good way to make the package installable/buildable
and probably migrate to Stretch.

I don't think there is a better solution!

G.

Bug#832401: Mouse cursor disappeared when long-time playing

[Sebastian Ramacher]

Control: tags -1 + moreinfo
Control: severity -1 normal

On 2016-07-25 10:57:18, M0xkLurk3r wrote:
> Package: src:vlc
> Version: 2.2.4-2
> Severity: grave
> 
> I know that VLC will hid the cursor when it stand still on the playback
> interface during clips playing, but my problem is the cursor did not appears
> again when I try to wake my mouse up. but in the meantime the mouse seems 
> alive
> indeed (I can move the cursor outside, even right-click on the playback could
> still triggered the playback menu)

Please provide the log of output of vlc -vvv. We need to know which vout plugin
you're using, etc.

> this bug always reproduce after a certain amount of time clip play. exactly
> this is not a serious bug, but it's really hard to control my mouse without 
> the
> cursor ...

So let's reduce the severity.

Cheers

> 
> 
> 
> -- System Information:
> Debian Release: stretch/sid
>   APT prefers testing
>   APT policy: (500, 'testing')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 4.6.0-1-amd64 (SMP w/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 vlc depends on:
> ii  dpkg1.18.9
> ii  fonts-freefont-ttf  20120503-4
> ii  libaa1  1.4p5-44
> ii  libc6   2.23-1
> ii  libcaca00.99.beta19-2+b1
> ii  libcairo2   1.14.6-1+b1
> ii  libegl1-mesa [libegl1-x11]  11.2.2-1
> ii  libfreerdp-client1.11.1.0~git20140921.1.440916e+dfsg1-10
> ii  libfreerdp-core1.1  1.1.0~git20140921.1.440916e+dfsg1-10
> ii  libfreerdp-gdi1.1   1.1.0~git20140921.1.440916e+dfsg1-10
> ii  libfreetype62.6.3-3+b1
> ii  libfribidi0 0.19.7-1
> ii  libgcc1 1:6.1.1-9
> ii  libgl1-mesa-glx [libgl1]11.2.2-1
> ii  libgles1-mesa [libgles1]11.2.2-1
> ii  libgles2-mesa [libgles2]11.2.2-1
> ii  libglib2.0-02.48.1-2
> ii  libpulse0   9.0-1.1
> ii  libqt5core5a5.6.1+dfsg-3
> ii  libqt5gui5  5.6.1+dfsg-3
> ii  libqt5widgets5  5.6.1+dfsg-3
> ii  libqt5x11extras55.6.1-2
> ii  librsvg2-2  2.40.16-1
> ii  libsdl-image1.2 1.2.12-5+b6
> ii  libsdl1.2debian 1.2.15+dfsg1-4
> ii  libstdc++6  6.1.1-9
> ii  libva-drm1  1.7.1-1
> ii  libva-x11-1 1.7.1-1
> ii  libva1  1.7.1-1
> ii  libvlccore8 2.2.4-2
> ii  libvncclient1   0.9.10+dfsg-3+b1
> ii  libx11-62:1.6.3-1
> ii  libxcb-composite0   1.11.1-1
> ii  libxcb-keysyms1 0.4.0-1
> ii  libxcb-randr0   1.11.1-1
> ii  libxcb-shm0 1.11.1-1
> ii  libxcb-xv0  1.11.1-1
> ii  libxcb1 1.11.1-1
> ii  libxext62:1.3.3-1
> ii  libxi6  2:1.7.6-1
> ii  libxinerama12:1.1.3-1+b1
> ii  libxpm4 1:3.5.11-1+b1
> ii  vlc-nox 2.2.4-2
> ii  zlib1g  1:1.2.8.dfsg-2+b1
> 
> Versions of packages vlc recommends:
> ii  vlc-plugin-notify  2.2.4-2
> ii  vlc-plugin-samba   2.2.4-2
> ii  xdg-utils  1.1.1-1
> 
> vlc suggests no packages.
> 
> Versions of packages vlc-nox depends on:
> ii  dpkg   1.18.9
> ii  liba52-0.7.4   0.7.4-18
> ii  libasound2 1.1.1-2
> ii  libass50.13.2-1
> ii  libavahi-client3   0.6.32-1
> ii  libavahi-common3   0.6.32-1
> ii  libavc1394-0   0.5.4-4
> ii  libbasicusageenvironment1  2016.06.26-1
> ii  libbluray1 1:0.9.3-2
> ii  libbz2-1.0 1.0.6-8
> ii  libc6  2.23-1
> ii  libcddb2   1.3.2-5
> ii  libcdio13  0.83-4.2+b1
> ii  libchromaprint01.3-1+b1
> ii  libcrystalhd3  1:0.0~git20110715.fdd2f19-11+b1
> ii  libdbus-1-31.10.8-1
> ii  libdc1394-22   2.2.4-1
> ii  libdca00.0.5-10
> ii  libdirectfb-1.2-9  1.2.10.0-5.2+b1
> ii  libdvbpsi101.3.0-4
> ii  libdvdnav4 5.0.3-1
> ii  libdvdread45.0.3-1
> ii  libebml4v5 1.3.4-1
> ii  libfaad2   2.8.0~cvs20150510-1
> ii  libflac8   1.3.1-4
> ii  libfontconfig1 2.11.0-6.4
> ii  libfreetype6   2.6.3-3+b1
> ii  libfribidi00.19.7-1
> ii  libgcc11:6.1.1-9
> ii  libgcrypt201.7.1-2
> ii  libgme00.6.0-3
> ii  libgnutls303.4.14-1
> ii  libgpg-error0  1.24-1
> ii  libgroupsock8  2016.06.26-1
> ii  libgsm1   

Bug#832410: python-clang-4.0, python-lldb-4.0: missing Breaks+Replaces against the corresponding python-*-3.9 packages

[Andreas Beckmann]

Package: python-clang-4.0,python-lldb-4.0
Version: 1:4.0~svn276280-1~exp1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Here we go again ... since this problem is reappearing in every new
upstream version, I'd recommend to use Provides/Conflicts/Replaces on a
virtual package, e.g. python-clang-x.y, python-lldb-x.y (literal x.y).

  Selecting previously unselected package python-lldb-4.0.
  Preparing to unpack .../python-lldb-4.0_1%3a4.0~svn276280-1~exp1_amd64.deb ...
  Unpacking python-lldb-4.0 (1:4.0~svn276280-1~exp1) ...
  dpkg: error processing archive 
/var/cache/apt/archives/python-lldb-4.0_1%3a4.0~svn276280-1~exp1_amd64.deb 
(--unpack):
   trying to overwrite '/usr/lib/python2.7/dist-packages/lldb', which is also 
in package python-lldb-3.9 1:3.9~svn275918-1~exp1

  Selecting previously unselected package python-clang-4.0.
  Preparing to unpack .../python-clang-4.0_1%3a4.0~svn276280-1~exp1_amd64.deb 
...
  Unpacking python-clang-4.0 (1:4.0~svn276280-1~exp1) ...
  dpkg: error processing archive 
/var/cache/apt/archives/python-clang-4.0_1%3a4.0~svn276280-1~exp1_amd64.deb 
(--unpack):
   trying to overwrite '/usr/lib/python2.7/dist-packages/clang/__init__.py', 
which is also in package python-clang-3.9 1:3.9~svn275918-1~exp1

Andreas

Bug#832411: cli-common-dev: Fails when .exe file has spaces in the name

[Salvatore Tomaselli]

Package: cli-common-dev
Version: 0.9+nmu1
Severity: normal

Dear Maintainer,
if a .exe file in the package contains spaces, the dh_ tool will fail, 
trying to process it as separate files.

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

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

Versions of packages cli-common-dev depends on:
ii  debhelper  9.20160709
ii  libxml-dom-perl1.44-2
ii  mono-devel [strong-name-tool]  4.2.1.102+dfsg2-8
ii  mono-utils [cil-disassembler]  4.2.1.102+dfsg2-8
ii  perl   5.22.2-2

cli-common-dev recommends no packages.

cli-common-dev suggests no packages.

-- no debconf information

Bug#827953: maxima: Uses too much memory to build

[Santiago Vila]

On Sun, 10 Jul 2016, Camm Maguire wrote:

> Greetings, and thanks so much for your report!  More reply later, but
> just want to point out for now that the memory used for the build
> depends on the memory available at runtime.  These packages will build
> just fine on machines with small memories.  The memory usage algorithm
> is a performance booster only.

Hello Camm.

There are at least two problems with the current approach:

* One of them (which I already pointed out) is that I can't measure how
much this program really needs by looking at memory usage. I can do
that for more than 3300 different packages in stretch, but I can't for
maxima and axiom, which is a pity.

* The other problem is that not only maxima takes as much RAM as I
have, it seems to use all available SWAP as well! This would explain
the effect "the more memory I have, the more memory it takes". Let's
suppose that I build with 4 GB RAM and 4 GB SWAP. Then I measure
that maxima takes 8GB and next time I will need 8 GB RAM to build.

If maxima is going to take all the memory I have, whatever the amount,
it should be the available RAM only, not available RAM + available SWAP.

If it's not able to do that and it only takes the total memory in
account, meybe it should assume that at least half of that is SWAP and
avoid using it.

Currently, it seems to assume that all the memory is available to use,
which is not realistic for people using SWAP as a safety net.

Thanks.

Bug#832412: libemos-data: 257 *.distinct files missing

[Manolo Díaz]

Package: libemos-data
Version: 2:4.4.2-1
Severity: normal

Dear Maintainer,

There are 257 *.distinct files missing in /usr/share/emos/bufrtables/
The complete list is below this lines, where the left term of each
line is a broken symlink.

Best regards,
Manolo Díaz


./D0016000.TXT  D_37f24485fa8f2c4abd0c02a2b42ee3fc.distinct
./D1016001.TXT  D_37f24485fa8f2c4abd0c02a2b42ee3fc.distinct
./D2016001.TXT  D_37f24485fa8f2c4abd0c02a2b42ee3fc.distinct
./D3016001.TXT  D_37f24485fa8f2c4abd0c02a2b42ee3fc.distinct
./D4016001.TXT  D_37f24485fa8f2c4abd0c02a2b42ee3fc.distinct
./D5016001.TXT  D_37f24485fa8f2c4abd0c02a2b42ee3fc.distinct
./D6016001.TXT  D_37f24485fa8f2c4abd0c02a2b42ee3fc.distinct
./D7016001.TXT  D_37f24485fa8f2c4abd0c02a2b42ee3fc.distinct
./D8016001.TXT  D_37f24485fa8f2c4abd0c02a2b42ee3fc.distinct
./D9016001.TXT  D_37f24485fa8f2c4abd0c02a2b42ee3fc.distinct
./D00010016001.TXT  D_37f24485fa8f2c4abd0c02a2b42ee3fc.distinct
./D00011016001.TXT  D_37f24485fa8f2c4abd0c02a2b42ee3fc.distinct
./D00012016001.TXT  D_37f24485fa8f2c4abd0c02a2b42ee3fc.distinct
./D00013016001.TXT  D_37f24485fa8f2c4abd0c02a2b42ee3fc.distinct
./D00014016001.TXT  D_37f24485fa8f2c4abd0c02a2b42ee3fc.distinct
./D00015016001.TXT  D_37f24485fa8f2c4abd0c02a2b42ee3fc.distinct
./D00016016001.TXT  D_37f24485fa8f2c4abd0c02a2b42ee3fc.distinct
./D00017016001.TXT  D_37f24485fa8f2c4abd0c02a2b42ee3fc.distinct
./D00018016001.TXT  D_37f24485fa8f2c4abd0c02a2b42ee3fc.distinct
./D00019016001.TXT  D_37f24485fa8f2c4abd0c02a2b42ee3fc.distinct
./D00020016001.TXT  D_37f24485fa8f2c4abd0c02a2b42ee3fc.distinct
./D00021016001.TXT  D_37f24485fa8f2c4abd0c02a2b42ee3fc.distinct
./D00022016001.TXT  D_37f24485fa8f2c4abd0c02a2b42ee3fc.distinct
./D00023016001.TXT  D_37f24485fa8f2c4abd0c02a2b42ee3fc.distinct
./D00024016001.TXT  D_37f24485fa8f2c4abd0c02a2b42ee3fc.distinct
./D00025016001.TXT  D_37f24485fa8f2c4abd0c02a2b42ee3fc.distinct
./D00026016001.TXT  D_37f24485fa8f2c4abd0c02a2b42ee3fc.distinct
./D00027016001.TXT  D_37f24485fa8f2c4abd0c02a2b42ee3fc.distinct
./D00028016001.TXT  D_37f24485fa8f2c4abd0c02a2b42ee3fc.distinct
./D00029016001.TXT  D_37f24485fa8f2c4abd0c02a2b42ee3fc.distinct
./D00030016001.TXT  D_37f24485fa8f2c4abd0c02a2b42ee3fc.distinct
./D00031016001.TXT  D_37f24485fa8f2c4abd0c02a2b42ee3fc.distinct
./D00032016001.TXT  D_37f24485fa8f2c4abd0c02a2b42ee3fc.distinct
./D00033016001.TXT  D_37f24485fa8f2c4abd0c02a2b42ee3fc.distinct
./D00034016001.TXT  D_37f24485fa8f2c4abd0c02a2b42ee3fc.distinct
./D00035016001.TXT  D_37f24485fa8f2c4abd0c02a2b42ee3fc.distinct
./D00036016001.TXT  D_37f24485fa8f2c4abd0c02a2b42ee3fc.distinct
./D00037016001.TXT  D_37f24485fa8f2c4abd0c02a2b42ee3fc.distinct
./D00038016001.TXT  D_37f24485fa8f2c4abd0c02a2b42ee3fc.distinct
./D00039016001.TXT  D_37f24485fa8f2c4abd0c02a2b42ee3fc.distinct
./D00040016001.TXT  D_37f24485fa8f2c4abd0c02a2b42ee3fc.distinct
./D00041016001.TXT  D_37f24485fa8f2c4abd0c02a2b42ee3fc.distinct
./D00042016001.TXT  D_37f24485fa8f2c4abd0c02a2b42ee3fc.distinct
./D00043016001.TXT  D_37f24485fa8f2c4abd0c02a2b42ee3fc.distinct
./D00044016001.TXT  D_37f24485fa8f2c4abd0c02a2b42ee3fc.distinct
./D00045016001.TXT  D_37f24485fa8f2c4abd0c02a2b42ee3fc.distinct
./D00046016001.TXT  D_37f24485fa8f2c4abd0c02a2b42ee3fc.distinct
./D00047016001.TXT  D_37f24485fa8f2c4abd0c02a2b42ee3fc.distinct
./D00048016001.TXT  D_37f24485fa8f2c4abd0c02a2b42ee3fc.distinct
./D00049016001.TXT  D_37f24485fa8f2c4abd0c02a2b42ee3fc.distinct
./D00050016001.TXT  D_37f24485fa8f2c4abd0c02a2b42ee3fc.distinct
./D00051016001.TXT  D_37f24485fa8f2c4abd0c02a2b42ee3fc.distinct
./D00052016001.TXT  D_37f24485fa8f2c4abd0c02a2b42ee3fc.distinct
./D00053016001.TXT  D_37f24485fa8f2c4abd0c02a2b42ee3fc.distinct
./D00054016001.TXT  D_37f24485fa8f2c4abd0c02a2b42ee3fc.distinct
./D00055016001.TXT  D_37f24485fa8f2c4abd0c02a2b42ee3fc.distinct
./D00056016001.TXT  D_37f24485fa8f2c4abd0c02a2b42ee3fc.distinct
./D00057016001.TXT  D_37f24485fa8f2c4abd0c02a2b42ee3fc.distinct
./D00058016001.TXT  D_37f24485fa8f2c4abd0c02a2b42ee3fc.distinct
./D00059016001.TXT  D_37f24485fa8f2c4abd0c02a2b42ee3fc.distinct
./D00060016001.TXT  D_37f24485fa8f2c4abd0c02a2b42ee3fc.distinct
./D00061016001.TXT  D_37f24485fa8f2c4abd0c02a2b42ee3fc.distinct
./D0006201

Bug#832412: It's just one *.distinct file missing

[Manolo Díaz]

Dear Maintainer,

I've just realized that there is _just one_ distinct file missing and
257 symlinks pointing to it. Sorry.

Best regards,
-- 
Manolo Díaz

Bug#830816: mpdris2: GLib.Error: ... The name org.freedesktop.Notifications was not provided by any .service files (2)

[Simon McVittie]

On Mon, 11 Jul 2016 at 13:11:47 -0700, Ben Longbons wrote:
> GLib.Error: g-dbus-error-quark: 
> GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name 
> org.freedesktop.Notifications was not provided by any .service files (2)

Which desktop environment are you using? (If you are not using a major
desktop environment like GNOME/KDE/XFCE, please summarize how your
graphical session starts, instead.)

Do you have dbus-user-session installed?

Do you have an implementation of o.fd.Notifications? (In no particular
order: lxqt-notificationd, xfce4-notifyd, notify-osd, dunst,
mate-notification-daemon, notification-daemon, cinnamon, gnome-shell,
plasma-workspace or gnome-flashback.)

mpdris2 should probably have a Recommends on notification-daemon to
ensure that one of those is pulled in. It should perhaps also
log-but-ignore errors communicating with the notification service.

S

Bug#832413: google-android-m2repository-installer: fails to install, remove, and install again

[Andreas Beckmann]

Package: google-android-m2repository-installer
Version: 33
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package failed to install,
remove (but not purge), and install again.
Before the second installation the package is in config-files-remaining
state. The configuration is remaining from the last version that was
successfully configured - which is the same version that is going to be
installed again.

Like a plain failure on initial install this makes the package too buggy
for a release, thus the severity.

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

[...]
  install -d -m0755 /usr/share/doc/google-android-m2repository
  gzip -9 --stdout 
/var/cache/google-android-m2repository-installer/m2repository/NOTICE.txt > 
/usr/share/doc/google-android-m2repository/copyright.gz
  install -m0644 
/var/cache/google-android-m2repository-installer/m2repository/source.properties 
/usr/share/doc/google-android-m2repository/
  install -d -m0755 /usr/lib/android-sdk/extras/android
  mv /var/cache/google-android-m2repository-installer/m2repository 
/usr/lib/android-sdk/extras/android/
  mv: cannot move 
'/var/cache/google-android-m2repository-installer/m2repository' to 
'/usr/lib/android-sdk/extras/android/m2repository': Directory not empty
  Makefile:15: recipe for target 'install' failed
  make: *** [install] Error 1
  make: Leaving directory '/var/cache/google-android-m2repository-installer'
  dpkg: error processing package google-android-m2repository-installer 
(--configure):
   subprocess installed post-installation script returned error exit status 2
  Errors were encountered while processing:
   google-android-m2repository-installer


Probably the maintainer scripts don't clean up properly on removal
but just on purge.


cheers,

Andreas


google-android-m2repository-installer_33.log.gz
Description: application/gzip

Bug#832414: RM: golang-goyaml -- RoQA; Superseeded by golang-yaml.v2, which is already in the archive

[Dr. Tobias Quathamer]

Package: ftp.debian.org
Severity: normal

Hi,

I think you could remove golang-goyaml from unstable. It's already
been removed from testing and has an RC bug which prevents the 
migration.

Regards,
Tobias

Bug#826807: blender: OpenJPEG removal

[Matteo F. Vescovi]

Control: tag -1 + pending

Hi!

On Mon, Jul 25, 2016 at 8:51 AM Mathieu Malaterre  wrote:

> Matteo,
>
> According to our latest chat, I believe you can mark this bug as
> pending. That would clarify for debian-release@l.d.o
>

Right. Done with this follow-up.
The package is fixed about the OpenJPEG issue but something connected with
the manpage creation is failing now. Gonna dig in it within today or
tomorrow.


> > You seem to use libjpeg-turbo already, and openjpeg support seems to be
> > optional. If this can't get ported to openjpeg2 in time for Stretch, you
> could
> > drop the openjpeg support.
>
> There is no link in between libjpeg-turbo (ITU-81 standard) and
> openjpeg (ITU-800 standard).


Cheers.

mfv

Bug#832397: tin: fails after reconnection, losing all downloaded data

[Urs Janßen]

On Mon, Jul 25, 2016 at 03:48:57AM +0200, Vincent Lefevre wrote:
> Package: tin
> Version: 1:2.3.2-1
> Severity: important
> 
> On a large newsgroup, tin starts to download the headers, but at
> some point, there's a disconnection. And tin always fails after a
> reconnection. However, if I start tin again, the connection succeeds,
> showing the problem occurs only for a reconnection.
> 
> With "tin -D 1", here's how /tmp/NNTP looks like.
> 
> nntp_open() BEGIN
> nntp_open() news.gandi.net:119
> <<< [01:26:48.881604] 200 groups.gandi.net Papercut server ready (posting 
> allowed)
> nntp_open() groups.gandi.net Papercut server ready (posting allowed)
[...]
> >>> [01:26:50.929886] LIST
> <<< [01:26:51.136585] 215 list of newsgroups follows
> nntp_command(LIST) OK
> <<< [01:26:51.136650] gandi.en.api 166 1 y
[...]
> <<< [01:26:51.136861] gandi.fr.domaine 8478 1 y
[...]
> nntp_command(LISTGROUP gandi.fr.domaine)
> >>> [01:26:54.579698] LISTGROUP gandi.fr.domaine
> <<< [01:26:54.935979] 211 8317 1 8478 gandi.fr.domaine Article numbers follow 
> (multiline)
> nntp_command(LISTGROUP gandi.fr.domaine) OK
> setup_hard_base(LISTGROUP gandi.fr.domaine)
> nntp_command(XOVER 1-8478)
> >>> [01:26:54.980474] XOVER 1-8478
> <<< [01:27:06.850014] 224 Overview information follows
> nntp_command(XOVER 1-8478) OK

the XOVER response from the server is empty, thus tin tries XHDR XREF

> nntp_command(XHDR XREF 1-8478)
> >>> [01:27:06.850150] XHDR XREF 1-8478
> <<< [01:27:06.860971] 501 command syntax error (or un-implemented option)
> nntp_command(XHDR XREF 1-8478) NOT_OK

which fails so it uses HEAD (damned slow) instead

> nntp_command(HEAD 1)
> >>> [01:27:06.861101] HEAD 1
> <<< [01:27:06.920651] 221 1 <45ca0f06$0$22737$afc38...@groups.gandi.net> 
> article retrieved - head follows
> nntp_command(HEAD 1) OK
> nntp_command(HEAD 2)
> >>> [01:27:06.920916] HEAD 2
> <<< [01:27:06.980840] 221 2 <45ca0f7a$0$22731$afc38...@groups.gandi.net> 
> article retrieved - head follows
> nntp_command(HEAD 2) OK
[...]
> >>> [01:31:51.906590] HEAD 4702
> <<< [01:31:51.967943] 221 4702 
> <95d6f1cc7df4d5dac6dd6736fc53e...@groups.gandi.net> article retrieved - head 
> follows
> nntp_command(HEAD 4702) OK
> nntp_command(HEAD 4703)
> >>> [01:31:51.968080] HEAD 4703

and here the connection is closed by the server for whatever reason

(verified manually via:
~ > telnet groups.gandi.net 119
Trying 217.70.184.33...
Connected to groups.gandi.net.
Escape character is '^]'.
200 groups.gandi.net Papercut server ready (posting allowed)
GROUP gandi.fr.domaine
211 8317 1 8478 gandi.fr.domaine group selected
head 4703
Connection closed by foreign host.

so tin reconnects and retires the last HEAD again:

> >>> [01:31:56.123696] GROUP gandi.fr.domaine
> <<< [01:31:56.252672] 211 8317 1 8478 gandi.fr.domaine group selected
> 
> >>> [01:31:56.252717] HEAD 4703

till it reaches its reconnection limit, and then quits with (undocumented)
NNTP_ERROR_EXIT (3)

> And then tin quits with no error messages, and exit status 3, which is

there should have been a "NNTP connection error. Exiting..."
message (shown for 2 seconds but then [n]curses is switched off ...).
I've added a log message to the NNTP-log when started with -D 1 now:
"reconnect(3) limit 2 reached, giving up".

> If I restart tin and retry on the same newsgroup, it starts again
> to download the headers from 1! Thus it is impossible to read this
> newsgroup.

you can use "-G positive_number" to download only the last n articles
(i.e. tin -G 2500 -g groups.gandi.net) - but with that buggy server there is
currently no way to read all articles (except 4703).

HTH,
urs
-- 
"Only whimps use tape backup: _real_ men just upload their important stuff
 on ftp, and let the rest of the world mirror it ;)" - Linus

Bug#814762: kmail: CSS from HTML mail interfers with header layout

[Maximiliano Curia]

Control: severity -1 important

¡Hola Dominik!

El 2016-07-24 a las 22:11 +0200, Dominik George escribió:
Package: kmail 
Version: 4:16.04.3-1 
Followup-For: Bug #814762


It got worse. Today, I stumbled about a legitimate HTML mail that just 
trashed the whole UI.



Find attached the mail that caused the issue and a screenshot.


Raising severity to grave. Please do something! Firstly, I am certain 
this is a security-relevant bug; secondly, it now makes stuff break in 
daily use.


I'm temporarily lowering the severity of this mail to finish the kdepim 16.04 
transition.


Also, I think that this issue should be easily reproduceable in the older 
kmail2 versions, thus I see no reason to block the transition by this.


Even more, a mail header can be "spoofed" using simpler tools, like an smtp 
server, thus I'm not really convinced that this bug deserves a "grave" 
severity.


Happy hacking,
--
"There are only two things wrong with C++: The initial concept and the
implementation."
-- Bertrand Meyer
Saludos /\/\ /\ >< `/


signature.asc
Description: Digital signature

Bug#832415: octave-parallel: Any attempt to use parcellfun leads to unhandled error in subprocesses

[Eric S Fraga]

Package: octave-parallel
Version: 3.1.0-1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

Any attempt to use parcellfun leads to errors such as these:

warning: parcellfun: unhandled error in subprocess 1
warning: called from
parcellfun at line 291 column 9
[...] traceback on my own code elided
error: '__exit__' undefined near line 311 column 7

Searching the Interweb leads me to a discussion on the GNU bug site
which seems to indicate that the problem is known in the Octave
community and that the problem has been introduced by the Debian
packaging:

https://savannah.gnu.org/bugs/?39481

Thank you.

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

Kernel: Linux 4.6.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 octave-parallel depends on:
ii  libc6  2.23-1
ii  libgcc11:6.1.1-9
ii  libgnutls303.4.14-1
ii  liboctave3v5   4.0.3-1
ii  libstdc++6 6.1.1-9
ii  octave 4.0.3-1
ii  octave-struct  1.0.13-1

octave-parallel recommends no packages.

octave-parallel suggests no packages.

-- no debconf information

Bug#831768: radiotray stops at start a radiostream

[Jörg Frings-Fürst]

Hallo Elías,

Am Donnerstag, den 21.07.2016, 13:35 -0500 schrieb Elías Alejandro:
> > 
> Hi,
> Firstly thanks for your report.
> Could you provide what is your radiostream? and send please the
> complete log again. 

my part of the bookmark.xml:


http://internetradio.salue.de:8000/salue.aac"/>
http://mp3-live.swr3.de/swr3_m.m3u"/>
http://streams.xenim.de/osm.mp3"/>
http://stream.rs2.de/rs2/mp3-128/internetradio/"/>
http://www.popstop.eu/playlist.php?ip=musik.pop-stop.de:8050&mountpoint=&format=M3U"/>


And the logfile is attached.

> Are you using gnome 3 shell? if so, there's a bug about it #687007.
> 

I'm using XFCE.

> 
> Best regards.
> 
> Elías Alejandro
> 
> On Tue, Jul 19, 2016 at 5:06 AM, Jörg Frings-Fürst  .de> wrote:
[...]


Mit freundlichen Grüßen

Jörg Frings-Fürst

-- 
Jörg Frings-Fürst

ViciDial.de

Skype:flyingpenguin.de
Tel:+49 6542 934889 5

flyingpenguin.de UG   Tel: 06542 934889 0Sitz Pünderich
(haftungsbeschränkt)  i...@flyingpenguin.de  Eingetragen in
Hauptstrasse 75   www.flyingpenguin.de   Koblenz HRB 22160
56862 Pünderich   Geschäftsführer:   USt-IdNr. DE273878135
Deutschland   Frank Gorgas-WallerSteuer-Nr. 40/659/014832016-07-25 12:10:46,712 - DEBUG - Loading configuration...
2016-07-25 12:10:46,712 - INFO - Starting Radio Tray...
2016-07-25 12:10:46,713 - INFO - Loading bookmarks file: /home/jff/.local/share/radiotray/bookmarks.xml
2016-07-25 12:10:46,713 - DEBUG - Bookmarks file loaded with success
2016-07-25 12:10:46,714 - DEBUG - PLS playlist decoder
2016-07-25 12:10:46,714 - DEBUG - M3U playlist decoder
2016-07-25 12:10:46,714 - DEBUG - ASX-familiy playlist decoder
2016-07-25 12:10:46,714 - DEBUG - XSPF playlist decoder
2016-07-25 12:10:46,714 - DEBUG - Initializing ASF playlist decoder
2016-07-25 12:10:46,715 - DEBUG - RAM playlist decoder
2016-07-25 12:10:46,715 - INFO - Using url timeout = 100
2016-07-25 12:10:46,715 - DEBUG - Initializing gstreamer...
2016-07-25 12:10:46,722 - DEBUG - Loading playbin...
2016-07-25 12:10:46,728 - DEBUG - GStreamer initialized.
2016-07-25 12:10:46,728 - DEBUG - Tooltip manager initialized.
2016-07-25 12:10:46,728 - DEBUG - No appindicator support found. Choosing notification area...
2016-07-25 12:10:46,729 - DEBUG - Systray selected
2016-07-25 12:10:46,801 - DEBUG - GUI initialized
2016-07-25 12:10:46,803 - INFO - finding plugins in user plugin path
2016-07-25 12:10:46,804 - INFO - finding plugins in system plugin path
2016-07-25 12:10:46,804 - DEBUG - /usr/share/radiotray/plugins/sleeptimer.plugin
2016-07-25 12:10:46,804 - DEBUG - /usr/share/radiotray/plugins/helloworld.plugin
2016-07-25 12:10:46,804 - DEBUG - /usr/share/radiotray/plugins/notification.plugin
2016-07-25 12:10:46,804 - DEBUG - /usr/share/radiotray/plugins/StationSwitcher.plugin
2016-07-25 12:10:46,804 - DEBUG - /usr/share/radiotray/plugins/history.plugin
2016-07-25 12:10:46,805 - DEBUG - /usr/share/radiotray/plugins/gnomemediakeys.plugin
2016-07-25 12:10:46,805 - DEBUG - /usr/share/radiotray/plugins/matemediakeys.plugin
2016-07-25 12:10:49,627 - DEBUG - Request to play
2016-07-25 12:10:49,627 - DEBUG - connecting
2016-07-25 12:10:49,629 - INFO - Requesting stream... http://mp3-live.swr3.de/swr3_m.m3u
2016-07-25 12:10:49,682 - DEBUG - Metadata obtained...
2016-07-25 12:10:49,682 - INFO - Content-Type: audio/x-mpegurl
2016-07-25 12:10:49,683 - INFO - Checking decoder
2016-07-25 12:10:49,683 - INFO - Checking decoder
2016-07-25 12:10:49,683 - INFO - Checking decoder
2016-07-25 12:10:49,683 - INFO - Checking decoder
2016-07-25 12:10:49,683 - INFO - Checking decoder
2016-07-25 12:10:49,683 - INFO - Checking decoder
2016-07-25 12:10:49,684 - INFO - Stream is readable by M3U Playlist Decoder
2016-07-25 12:10:49,684 - INFO - Downloading playlist...
2016-07-25 12:10:49,723 - INFO - Playlist downloaded
2016-07-25 12:10:49,723 - INFO - Decoding playlist...
2016-07-25 12:10:49,723 - DEBUG - ['http://swr-mp3-m-swr3.akacast.akamaistream.net/7/720/137136/v1/gnl.akacast.akamaistream.net/swr-mp3-m-swr3']
2016-07-25 12:10:49,724 - INFO - Play "http://swr-mp3-m-swr3.akacast.akamaistream.net/7/720/137136/v1/gnl.akacast.akamaistream.net/swr-mp3-m-swr3";
2016-07-25 12:10:49,724 - INFO - Requesting stream... http://swr-mp3-m-swr3.akacast.akamaistream.net/7/720/137136/v1/gnl.akacast.akamaistream.net/swr-mp3-m-swr3
2016-07-25 12:10:50,050 - DEBUG - Metadata obtained...
2016-07-25 12:10:50,050 - INFO - Content-Type: audio/mpeg
2016-07-25 12:10:50,051 - INFO - Checking decoder
2016-07-25 12:10:50,051 - INFO - Checking decoder
2016-07-25 12:10:50,051 - INFO - Checking decoder
2016-07-25 12:10:50,051 - INFO - Checking decoder
2016-07-25 12:10:50,051 - INFO - Checking decoder
2016-07-25 12:10:50,051 - INFO - Checking decoder
2016-07-25 12:10:50,051 - INFO - No playlist decoder could handle the stream. Maybe direct stream...
2016-07-25 12:10:50,121 - DEBUG - Received MESSAGE_STATE_CHANGED ( -> )
2016-07-25 12:10:50,121 - DEBUG - Received MESSAGE_STATE_CHANGED ( -> )
2016-07-25

Bug#814762: kmail: CSS from HTML mail interfers with header layout

[Dominik George]

Control: severity -1 grave

Hi,

>Even more, a mail header can be "spoofed" using simpler tools, like an
>smtp 
>server, thus I'm not really convinced that this bug deserves a "grave" 
>severity.

Did you read all of this bug report?

1. I explained that this method can do more than other ways of spoofing mail 
headers because mail filters do not see the spoofed headers,

2. in my follow-up, I showed that in 16.04, legitimate HTML mail breaks the UI. 
This has nothing to do with spoofing - KMail breaks when opening random, 
legitimate mail. I cannot even click any controls in the mail view anymore. 
This affects daily, normal work with KMail and makes it unusable for reading 
legitimate mail. That is the definition of "grave functionality bug".

I am ok with dropping the security tag, but the grave was for the follow-up.

The bug with the legitimate mail does *not* occur in any prior version, so 
migration would introduce this issue into testing.

In conclusion: I can read legitimate mail in kmail in testing; I can't do so in 
unstable. Thus, the new version should not migrate unless the bug is fixed.

-nik
-- 
PGP-Fingerprint: 3C9D 54A4 7575 C026 FB17 FD26 B79A 3C16 A0C4 F296

Dominik George · Mobil: +49-1520-1981389

Teckids e.V. · FrOSCon e.V. · OpenRheinRuhr e.V.
Fellowship of the FSFE · Piratenpartei Deutschland
Opencaching Deutschland e.V. · Debian Contributor

LPIC-3 Linux Enterprise Professional (Security)

Bug#827755: transition: kdepim-16.04

[Maximiliano Curia]

¡Hola Emilio!

El 2016-07-13 a las 16:17 +0200, Emilio Pozuelo Monfort escribió:

Just let me know when things are ready to migrate and I will lift the block.


I think that every kdepim 16.04 package is ready to migrate to testing, some 
of the issues have been addressed, and delaying the transition even further 
will not have any positive effect. Thus, can you please lift the blocks so 
that the complete set of packages enter into testing?


Happy hacking,
--
"Fighting patents one by one will never eliminate the danger of software
patents, any more than swatting mosquitoes will eliminate malaria."
-- Richard M. Stallman
Saludos /\/\ /\ >< `/


signature.asc
Description: Digital signature

Bug#832416: libimage-magick-q16-perl: Stack smash detected on i386 with perl and Image::Magick

[Marvin]

Package: libimage-magick-q16-perl
Version: 8:6.8.9.9-5+deb8u3
Severity: important

Dear Maintainer,

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

   * What led up to the situation?

Perl Skript err.pl:
--snip--
#!/usr/bin/perl
use strict;
use warnings;
use Image::Magick;

my  $image = Image::Magick->new;
$image->Set(size=>'100x100');
$image->ReadImage('xc:white');
$image->Set('pixel[49,49]'=>'red');

exit;
--snip--

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

run Perl Skript

   * What was the outcome of this action?

perl err.pl 
*** stack smashing detected ***: perl terminated
=== Backtrace: =
/lib/i386-linux-gnu/i686/cmov/libc.so.6(+0x6c773)[0xb756f773]
/lib/i386-linux-gnu/i686/cmov/libc.so.6(__fortify_fail+0x45)[0xb75ffb85]
/lib/i386-linux-gnu/i686/cmov/libc.so.6(+0xfcb3a)[0xb75ffb3a]
/usr/lib/i386-linux-gnu/perl5/5.20/auto/Image/Magick/Q16/Q16.so(_fini+0x0)[0xb73242d4]
/usr/lib/i386-linux-gnu/perl5/5.20/auto/Image/Magick/Q16/Q16.so(+0xc757)[0xb72fb757]
=== Memory map: 
08048000-08213000 r-xp  08:03 15575573   /usr/bin/perl
08213000-08214000 r--p 001ca000 08:03 15575573   /usr/bin/perl
08214000-08216000 rw-p 001cb000 08:03 15575573   /usr/bin/perl
096fb000-09824000 rw-p  00:00 0  [heap]
b66bf000-b66c4000 r-xp  08:03 15578982   
/usr/lib/i386-linux-gnu/libXdmcp.so.6.0.0
b66c4000-b66c5000 rw-p 4000 08:03 15578982   
/usr/lib/i386-linux-gnu/libXdmcp.so.6.0.0
b66c5000-b66c7000 r-xp  08:03 15578980   
/usr/lib/i386-linux-gnu/libXau.so.6.0.0
b66c7000-b66c8000 r--p 1000 08:03 15578980   
/usr/lib/i386-linux-gnu/libXau.so.6.0.0
b66c8000-b66c9000 rw-p 2000 08:03 15578980   
/usr/lib/i386-linux-gnu/libXau.so.6.0.0
b66c9000-b6739000 r-xp  08:03 2048053
/lib/i386-linux-gnu/libpcre.so.3.13.1
b6739000-b673b000 r--p 0006f000 08:03 2048053
/lib/i386-linux-gnu/libpcre.so.3.13.1
b673b000-b673c000 rw-p 00071000 08:03 2048053
/lib/i386-linux-gnu/libpcre.so.3.13.1
b673c000-b676 r-xp  08:03 15578984   
/usr/lib/i386-linux-gnu/libxcb.so.1.1.0
b676-b6761000 r--p 00023000 08:03 15578984   
/usr/lib/i386-linux-gnu/libxcb.so.1.1.0
b6761000-b6762000 rw-p 00024000 08:03 15578984   
/usr/lib/i386-linux-gnu/libxcb.so.1.1.0
b6762000-b678d000 r-xp  08:03 2048188
/lib/i386-linux-gnu/libpng12.so.0.50.0
b678d000-b678e000 r--p 0002a000 08:03 2048188
/lib/i386-linux-gnu/libpng12.so.0.50.0
b678e000-b678f000 rw-p 0002b000 08:03 2048188
/lib/i386-linux-gnu/libpng12.so.0.50.0
b678f000-b67b5000 r-xp  08:03 2048159
/lib/i386-linux-gnu/libexpat.so.1.6.0
b67b5000-b67b7000 r--p 00026000 08:03 2048159
/lib/i386-linux-gnu/libexpat.so.1.6.0
b67b7000-b67b8000 rw-p 00028000 08:03 2048159
/lib/i386-linux-gnu/libexpat.so.1.6.0
b67b8000-b68de000 r-xp  08:03 2048058
/lib/i386-linux-gnu/libglib-2.0.so.0.4200.1
b68de000-b68df000 r--p 00125000 08:03 2048058
/lib/i386-linux-gnu/libglib-2.0.so.0.4200.1
b68df000-b68e rw-p 00126000 08:03 2048058
/lib/i386-linux-gnu/libglib-2.0.so.0.4200.1
b68e-b68fc000 r-xp  08:03 2048004
/lib/i386-linux-gnu/libgcc_s.so.1
b68fc000-b68fd000 rw-p 0001b000 08:03 2048004
/lib/i386-linux-gnu/libgcc_s.so.1
b68fd000-b6915000 r-xp  08:03 15580601   
/usr/lib/i386-linux-gnu/libgomp.so.1.0.0
b6915000-b6916000 rw-p 00017000 08:03 15580601   
/usr/lib/i386-linux-gnu/libgomp.so.1.0.0
b6916000-b692 r-xp  08:03 15580071   
/usr/lib/i386-linux-gnu/libltdl.so.7.3.0
b692-b6921000 r--p 9000 08:03 15580071   
/usr/lib/i386-linux-gnu/libltdl.so.7.3.0
b6921000-b6922000 rw-p a000 08:03 15580071   
/usr/lib/i386-linux-gnu/libltdl.so.7.3.0
b6922000-b693c000 r-xp  08:03 2048101
/lib/i386-linux-gnu/libz.so.1.2.8
b693c000-b693e000 r--p 00019000 08:03 2048101
/lib/i386-linux-gnu/libz.so.1.2.8
b693e000-b693f000 rw-p 0001b000 08:03 2048101
/lib/i386-linux-gnu/libz.so.1.2.8
b693f000-b694f000 r-xp  08:03 2048036
/lib/i386-linux-gnu/libbz2.so.1.0.4
b694f000-b6951000 r--p f000 08:03 2048036
/lib/i386-linux-gnu/libbz2.so.1.0.4
b6951000-b6952000 rw-p 00011000 08:03 2048036
/lib/i386-linux-gnu/libbz2.so.1.0.4
b6952000-b6a9f000 r-xp  08:03 15578988   
/usr/lib/i386-linux-gnu/libX11.so.6.3.0
b6a9f000-b6aa1000 r--p 0014d000 08:03 15578988   
/usr/lib/i386-linux-gnu/libX11.so.6.3.0
b6aa1000-b6aa4000 rw-p 0014f000 08:03 15578988   
/usr/lib/i386-linux-gnu/libX11.so.6.3.0
b6aa4000-b6ab7000 r-xp  08:03 15579072   
/usr/lib/i386-linux-gnu/libXext.so.6.4.0
b6ab7000-b6ab8000 r--p 00012000 08:03 15579072   
/usr/lib/i386-linux-gnu/libXext.so.6.4.0
b6ab8000-b6ab9000 rw-p 00013000 08:03 15579072   
/usr/lib/i386-linux-gnu/libXext.so.6.4.0
b6ab9000-b6b66000 r-xp  08:03 12068825   
/usr/lib/i386-linux-gnu/libfreetype.so.6.11.1
b6b66000-b6b6a000 r--p 000ac000 08:03 12068825   
/usr/lib/i386-linux-gnu/libfreetype.so.6.11

Bug#832417: shotwell: Shotwell crashes when videos are imported

[karl]

Package: shotwell
Version: 0.22.1-1
Severity: important

Dear Maintainer,

If you want to import Vidoes , format .MOV crashes Shotwell.

Importing photos works flawlessly.

Terminal Output in import of videos:

(shotwell:11929): Gtk-WARNING **: Theme parsing error: :2:38: The style
property GtkPaned:handle-size is deprecated and shouldn't be used anymore. It
will be removed in a future version
Abgebrochen



-- Package-specific info:

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

Kernel: Linux 4.6.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_AT.utf8, LC_CTYPE=de_AT.utf8 (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.23-2
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-2
ii  libgexiv2-2 0.10.3-2
ii  libglib2.0-02.48.1-2
ii  libgomp16.1.1-9
ii  libgphoto2-62.5.10-3
ii  libgphoto2-port12   2.5.10-3
ii  libgstreamer-plugins-base1.0-0  1.8.2-1
ii  libgstreamer1.0-0   1.8.2-1
ii  libgtk-3-0  3.20.6-2
ii  libgudev-1.0-0  230-3
ii  libjavascriptcoregtk-4.0-18 2.12.3-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.2-3
ii  librest-0.7-0   0.8.0-1
ii  librsvg2-common 2.40.16-1
ii  libsoup2.4-12.54.1-1
ii  libsqlite3-03.13.0-1
ii  libstdc++6  6.1.1-9
ii  libwebkit2gtk-4.0-372.12.3-1
ii  libx11-62:1.6.3-1
ii  libxml2 2.9.4+dfsg1-1
ii  shotwell-common 0.22.1-1

shotwell recommends no packages.

shotwell suggests no packages.

-- no debconf information

Bug#807654: jessie-pu: package python-django/1.7.11-1

[Raphael Hertzog]

On Tue, 28 Jun 2016, Julien Cristau wrote:
> Please go ahead.

Thanks, uploaded 1.7.11-1.

Note that I had to merge in the latest security updates and due to
git-dpm usage by the python team and its lack of proper merge support
(#801667), there is some noise in the debdiff due to renamed patches.

I also added DEP-8 tests because I wanted to make sure that the resulting
package worked fine (at the time of the initial request, distro tracker
was still running Django 1.7 and it was my testbed).

> Especially for stable updates, the changelog should include the actual
> useful information directly, not links (or not *just* links).

Done.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

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

Bug#814762: Info received (Bug#814762: kmail: CSS from HTML mail interfers with header layout)

[Dominik George]

In order to speed things up, I will look into providing a patch today.

-nik
-- 
PGP-Fingerprint: 3C9D 54A4 7575 C026 FB17 FD26 B79A 3C16 A0C4 F296

Dominik George · Mobil: +49-1520-1981389

Teckids e.V. · FrOSCon e.V. · OpenRheinRuhr e.V.
Fellowship of the FSFE · Piratenpartei Deutschland
Opencaching Deutschland e.V. · Debian Contributor

LPIC-3 Linux Enterprise Professional (Security)

Bug#832418: gmap: no longer builds on all little-endian architectures

[Graham Inggs]

Source: gmap
Version: 2016-05-01-1
Severity: wishlist
Control: tags -1 patch

Dear Maintainer

Since version 2016-05-01-1, it no longer builds on all little-endian 
architectures in Ubuntu.

Since version 2016-06-09-1, it builds again on ppc64el.

The attached patch, against version 2016-07-11.v2-1, only does CPUID on 
amd64 and i386 architectures, instead of everywhere that is not POWER8.
This allows gmap to build again on armhf and amd64, where version 
2015-12-31.v9-1 built previously.


Regards
Graham

Description: Only do CPUID on amd64 and i386
 This fixes a FTBFS on armhf and arm64.
Author: Graham Inggs 
Last-Update: 2016-07-24
--- a/src/cpuid.c
+++ b/src/cpuid.c
@@ -7,7 +7,7 @@
 #include 
 
 
-#if defined(AX_HOST_POWER8)
+#if !defined(__x86_64) && !defined(__i386)
 
 void
 CPUID_support (bool *sse2_support_p, bool *ssse3_support_p, bool *sse4_1_support_p, bool *sse4_2_support_p, bool *avx2_support_p) {

Bug#814762: Info received (Bug#814762: kmail: CSS from HTML mail interfers with header layout)

[Sandro Knauß]

Hey,

I actually set down today and fixed the issue or at least makes it more 
difficult 
to break the UI. 

http://commits.kde.org/messagelib/3f9d16c7dadd2c98b00c5e7216cd69cfb518cab9
http://commits.kde.org/kdepim-addons/a97f99b2769d39ffa03a2cd2454f10ef93222486
http://commits.kde.org/kdepim-addons/cab925e9d4769762ea0080d49f392022cd8e78dd

Regards,

sandro


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

Bug#832397: tin: fails after reconnection, losing all downloaded data

[Vincent Lefevre]

On 2016-07-25 11:44:47 +0200, Urs Janßen wrote:
> and here the connection is closed by the server for whatever reason
> 
> (verified manually via:
> ~ > telnet groups.gandi.net 119
> Trying 217.70.184.33...
> Connected to groups.gandi.net.
> Escape character is '^]'.
> 200 groups.gandi.net Papercut server ready (posting allowed)
> GROUP gandi.fr.domaine
> 211 8317 1 8478 gandi.fr.domaine group selected
> head 4703
> Connection closed by foreign host.

I see. So, the problem occurs because each time tin tries to get 4703,
the connection is closed. I've reported the problem to Gandi.

> so tin reconnects and retires the last HEAD again:
> 
> > >>> [01:31:56.123696] GROUP gandi.fr.domaine
> > <<< [01:31:56.252672] 211 8317 1 8478 gandi.fr.domaine group selected
> > 
> > >>> [01:31:56.252717] HEAD 4703
> 
> till it reaches its reconnection limit, and then quits with (undocumented)
> NNTP_ERROR_EXIT (3)

IMHO, it should be documented.

> > And then tin quits with no error messages, and exit status 3, which is
> 
> there should have been a "NNTP connection error. Exiting..."
> message (shown for 2 seconds but then [n]curses is switched off ...).
> I've added a log message to the NNTP-log when started with -D 1 now:
> "reconnect(3) limit 2 reached, giving up".

And since the logs are not always enabled, perhaps the error message
should also be output again *after* [n]curses is switched off.

The problem is that if one isn't looking at the terminal in the
2 seconds when the message appears, one misses it entirely.

> > If I restart tin and retry on the same newsgroup, it starts again
> > to download the headers from 1! Thus it is impossible to read this
> > newsgroup.
> 
> you can use "-G positive_number" to download only the last n articles
> (i.e. tin -G 2500 -g groups.gandi.net) - but with that buggy server there is
> currently no way to read all articles (except 4703).

OK, thanks (BTW, the man page doesn't say that these are the *last* N
articles).

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#828475: openssh: FTBFS with openssl 1.1.0

[Colin Watson]

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

OpenSSH upstream say they hope to work on this after the 7.3 release:

  https://lists.mindrot.org/pipermail/openssh-unix-dev/2016-July/035206.html

-- 
Colin Watson   [cjwat...@debian.org]

Bug#832419: CVE-2016-3498

[Moritz Muehlenhoff]

Source: openjfx
Severity: grave
Tags: security

CVE-2016-3498 from 
http://www.oracle.com/technetwork/security-advisory/cpujul2016-2881720.html#AppendixJAVA
  
should affected openjfx.

Cheers,
Moritz

Bug#832420: ITP: qtwebengine -- Web content engine library for Qt

[Sandro Knauß]

Package: wnpp
Severity: wishlist
Owner: "Sandro Knauß" 

* Package name: qtwebengine
  Version : 5.6.1
  Upstream Author : The Qt Company Ltd.
* URL : http://trac.webengine.org/wiki/QtWebEngine
* License : LGPL2+,GPL2+, BSD
  Programming Lang: C++
  Description : Web content engine library for Qt

 QtWebEngine provides a Web browser engine that makes it easy to embed content
 from the World Wide Web into your Qt application.
 .
 This package contains the development files needed to build Qt 5 applications
 using QtWebEngine library.

We want to package it within the  Debian Qt/KDE Maintainers 
 umrella
and need it for newer KDE Applications.

Bug#832421: ITP: qtwebchannel -- Publish `QObjects` for the usage of webengine

[Sandro Knauß]

Package: wnpp
Severity: wishlist
Owner: "Sandro Knauß" 

* Package name: qtwebchannel
  Version : 5.6.1
  Upstream Author : The QtCompany Ltd.
* URL : http://doc.qt.io/qt-5/qtwebchannel-index.html
* License : LGPL2.1, LGPL3
  Programming Lang: C++
  Description : Publish `QObjects` for the usage of webengine

 Provides public API shared by both QtWebEngine and QtWebEngineWidgets

 We intend to package it under the Debian Qt/KDE Maintainers 
 umbrella.
 It is needed for QtWebEngine.

Bug#832159: Processed: block 832159 with 832420

[Florian Bruhin]

* Debian Bug Tracking System  [2016-07-25 11:03:05 
+]:
> Processing commands for cont...@bugs.debian.org:
> 
> > block 832159 with 832420

I don't think this should be blocked by QtWebEngine. In fact,
QtWebEngine support is still in heavy development, and most (if not
all) users are using it with QtWebKit.

If this was unclear in Fritz' original mail - qutebrowser works with
either QtWebKit or - in the near future - QtWebEngine.

Florian

-- 
http://www.the-compiler.org | m...@the-compiler.org (Mail/XMPP)
   GPG: 916E B0C8 FD55 A072 | http://the-compiler.org/pubkey.asc
 I love long mails! | http://email.is-not-s.ms/


signature.asc
Description: PGP signature

Bug#831418: #831418 EOL: not to be released with Stretch

[Markus Frosch]

Hey all,
this is a interesting problem, while looking on the 3 dependent packages. (see 
below)

We have 3 choices to go on:

1. Still provide zendframework 1 in a separated path, so it won't conflict with 
ZF2/3
2. Embed needed code into the packages, and drop the full library
3. Remove all 3 packages from stretch

I'd prefer to go with #1, there should not be any major security issues in the 
future with the code base.

And if so, we should be able to tackle them.

I would love to hear the opinion of the security team on the matter.

Regards
Markus


## icingaweb2

The integrations of Zend in terms of controllers/templates is not that big of a 
problem. Zend_Form is integrated tightly into the application.

Any adaption to ZF2/3 will need rewriting, that is not simple and certainly not 
a drop-in replacement in terms of functionality.

## postfixadmin

Zend_Xmlrpc_Server is used to provide API functionality, this is not a must for 
the package.

But adapting to ZF2/3 will cause rewriting the XMLRPC interface.

## php-letodms-lucene

The package is relying on Zend_Search_Lucene to index documents and search them.

A removal of ZF1 will cause massive problems here. Question is: who uses the 
package?


-- 
mar...@lazyfrosch.de / lazyfro...@debian.org
http://www.lazyfrosch.de



signature.asc
Description: OpenPGP digital signature

Bug#827755: transition: kdepim-16.04

[Maximiliano Curia]

¡Hola Emilio!

El 2016-07-25 a las 12:19 +0200, Maximiliano Curia escribió:

¡Hola Emilio!

El 2016-07-13 a las 16:17 +0200, Emilio Pozuelo Monfort escribió:

Just let me know when things are ready to migrate and I will lift the block.


I think that every kdepim 16.04 package is ready to migrate to 
testing, some of the issues have been addressed, and delaying the 
transition even further will not have any positive effect. Thus, can 
you please lift the blocks so that the complete set of packages enter 
into testing?


Sorry, we are going to push some extra patches to fix #814762. Sorry for the 
noise.


Happy hacking,
--
"C makes it easy to shoot yourself in the foot; C++ makes it harder,
but when you do it blows your whole leg off."
-- Bjarne Stroustrup
Saludos /\/\ /\ >< `/


signature.asc
Description: Digital signature

Bug#829272: [openssl.org #4602] Missing accessors

[Mischa Salle]

On Sat, Jul 23, 2016 at 09:44:18AM +, Richard Levitte via RT wrote:
> To get current_cert, it's X509_STORE_CTX_get_current_cert().
> To get current_issuer, it's X509_STORE_CTX_get0_current_issuer()

Hi Richard,

yes, those I know, but the problem is the *setting* of the failing cert.
Since we need to walk the whole chain for the proxy pathlength
verification, we need to be able to indicate which cert is failing. See
e.g.
https://github.com/globus/globus-toolkit/blob/globus_6_branch/gsi/callback/source/library/globus_gsi_callback.c#L1691
and further, in particular line 1731.
VOMS is basically using the same code
https://github.com/italiangrid/voms/blob/master/src/sslutils/sslutils.c#L2236
and further, in particular line 2255.

Jan Just also sets the current_issuer in his grid-proxy-verify.c,
http://www.nikhef.nl/~janjust/proxy-verify/
line 346, but I'm not sure that's necessary.

Mischa

> 
> Those functions are already present in pre-1.1 OpenSSL (at least in the 1.0.2
> series)
> 
> On Fri Jul 22 15:51:16 2016, msa...@nikhef.nl wrote:
> > Hi,
> >
> > unless I didn't look careful enough I think we might still be missing
> > the current_cert (and current_issuer) from the X509_STORE_CTX, as
> > advertised in
> >
> https://github.com/openssl/openssl/blob/master/doc/HOWTO/proxy_certificates.txt#L204
> > and used in e.g.
> > https://github.com/italiangrid/voms/blob/master/src/sslutils/sslutils.c
> > and many other places for verifying the proxy chain or is there a
> > better/other solution for that?
> >
> > Best wishes,
> > Mischa
> >
> > On Fri, Jul 22, 2016 at 03:26:26PM +, Richard Levitte via RT
> > wrote:
> > > In addition to github PR 1294, there's now also PR 1339 which adds
> > > the function to set the EXFLAG_PROXY flag on a given certificate.
> > >
> > > Also, PR 1295 has been updated. Instead of a function that returns a
> > > lock, there is now a lock and an unlock function.
> > >
> > > To me, it seems that that covers what's being asked for. Perhaps not
> > > exactly (the setters are for X509_STORE only), but should be
> > > workable.
> > >
> > > (writing this from my mobile, sorry for the lack of github links)
> > >
> > > --
> > > Richard Levitte
> > > levi...@openssl.org
> > > --
> > > Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4602
> > > Please log in as guest with password guest if prompted
> > >
> > > --
> > > To unsubscribe, send mail to 829272-unsubscr...@bugs.debian.org.
> 
> 
> --
> Richard Levitte
> levi...@openssl.org
> 
> -- 
> Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4602
> Please log in as guest with password guest if prompted
> 

-- 
Nikhef  Room  H155
Science Park 105Tel.  +31-20-592 5102
1098 XG Amsterdam   Fax   +31-20-592 5155
The Netherlands Email msa...@nikhef.nl
  __ .. ... _._.  ._  ... ._ ._.. ._.. .._..


smime.p7s
Description: S/MIME cryptographic signature

Bug#829272: Missing accessors

[msa...@nikhef.nl via RT]

On Sat, Jul 23, 2016 at 09:44:18AM +, Richard Levitte via RT wrote:
> To get current_cert, it's X509_STORE_CTX_get_current_cert().
> To get current_issuer, it's X509_STORE_CTX_get0_current_issuer()

Hi Richard,

yes, those I know, but the problem is the *setting* of the failing cert.
Since we need to walk the whole chain for the proxy pathlength
verification, we need to be able to indicate which cert is failing. See
e.g.
https://github.com/globus/globus-toolkit/blob/globus_6_branch/gsi/callback/source/library/globus_gsi_callback.c#L1691
and further, in particular line 1731.
VOMS is basically using the same code
https://github.com/italiangrid/voms/blob/master/src/sslutils/sslutils.c#L2236
and further, in particular line 2255.

Jan Just also sets the current_issuer in his grid-proxy-verify.c,
http://www.nikhef.nl/~janjust/proxy-verify/
line 346, but I'm not sure that's necessary.

Mischa

> 
> Those functions are already present in pre-1.1 OpenSSL (at least in the 1.0.2
> series)
> 
> On Fri Jul 22 15:51:16 2016, msa...@nikhef.nl wrote:
> > Hi,
> >
> > unless I didn't look careful enough I think we might still be missing
> > the current_cert (and current_issuer) from the X509_STORE_CTX, as
> > advertised in
> >
> https://github.com/openssl/openssl/blob/master/doc/HOWTO/proxy_certificates.txt#L204
> > and used in e.g.
> > https://github.com/italiangrid/voms/blob/master/src/sslutils/sslutils.c
> > and many other places for verifying the proxy chain or is there a
> > better/other solution for that?
> >
> > Best wishes,
> > Mischa
> >
> > On Fri, Jul 22, 2016 at 03:26:26PM +, Richard Levitte via RT
> > wrote:
> > > In addition to github PR 1294, there's now also PR 1339 which adds
> > > the function to set the EXFLAG_PROXY flag on a given certificate.
> > >
> > > Also, PR 1295 has been updated. Instead of a function that returns a
> > > lock, there is now a lock and an unlock function.
> > >
> > > To me, it seems that that covers what's being asked for. Perhaps not
> > > exactly (the setters are for X509_STORE only), but should be
> > > workable.
> > >
> > > (writing this from my mobile, sorry for the lack of github links)
> > >
> > > --
> > > Richard Levitte
> > > levi...@openssl.org
> > > --
> > > Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4602
> > > Please log in as guest with password guest if prompted
> > >
> > > --
> > > To unsubscribe, send mail to 829272-unsubscr...@bugs.debian.org.
> 
> 
> --
> Richard Levitte
> levi...@openssl.org
> 
> -- 
> Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4602
> Please log in as guest with password guest if prompted
> 

-- 
Nikhef  Room  H155
Science Park 105Tel.  +31-20-592 5102
1098 XG Amsterdam   Fax   +31-20-592 5155
The Netherlands Email msa...@nikhef.nl
  __ .. ... _._.  ._  ... ._ ._.. ._.. .._..

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4602
Please log in as guest with password guest if prompted



smime.p7s
Description: S/MIME cryptographic signature

Bug#832422: albatross-gtk-theme: broken with GTK3.20

[Jeremy Bicha]

Package: albatross-gtk-theme
Version: 1.7.4-1
Severity: important
Tags; upstream
Forwarded: https://github.com/shimmerproject/Albatross/issues/10

GTK 3.20 includes a major rewrite of the theming code and broke all
existing GTK3 themes. I'm linking the upstream tracking bug for
Albatross. Since Albatross is not really maintained upstream any more,
it's unclear when someone will get around to fixing this.

Considering we still have quite a few GTK2 themes in Debian with no
GTK3 support at all, I don't think we should remove albatross at this
time. The theme is still usable on Xfce if you don't use GTK3 apps.

Thanks,
Jeremy Bicha

Bug#829063: graphicsmagick: regression convert: Non-conforming drawing primitive definition (push)

[GCS]

On Sun, Jul 24, 2016 at 3:16 PM, Paul Gevers  wrote:
> On Sun, 3 Jul 2016 13:39:40 -0500 (CDT) Bob Friesenhahn
>  wrote:
>> While the SVG rendering properties are not improved, this error is
>> fixed by GraphicsMagick Mercurial changeset 14869:ae78bb613993.
>
> Are the graphicsmagick maintainers considering to upload the fix to Debian?
 As I read, Bob found two other SVG related problems[1]:
"I found two problems.  One was related to the pixel limits checks and
the other was related to an arbitrary limit I added to try to limit
DoS opportunities."

> Please let us know either way, so we can judge if we need to work around
> this issue that is causing our FTBFS.
 If this is the only SVG problem and fix, I can backport it and do an
upload. However I recall an other email from Bob who said (wrote) that
GraphicsMagick 1.3.25 is expected soon with several important fixes.
Waiting on feedback.

Regards,
Laszlo/GCS
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=829063#32

Bug#832423: bluebird-gtk-theme: broken with GTK3.20

[Jeremy Bicha]

Package: bluebird-gtk-theme
Version: 1.2-1
Severity: important
Tags: upstream
Forwarded: https://github.com/shimmerproject/Bluebird/issues/16

GTK 3.20 includes a major rewrite of the theming code and broke all
existing GTK3 themes. I'm linking the upstream tracking bug for
Bluebird. Since Bluebird is not really maintained upstream any more,
it's unclear when someone will get around to fixing this.

Considering we still have quite a few GTK2 themes in Debian with no
GTK3 support at all, I don't think we should remove Bluebird at this
time. The theme is still usable on Xfce if you don't use GTK3 apps.

Thanks,
Jeremy Bicha

Bug#830555: new Foolscap release available

[Ramakrishnan Muthukrishnan]

On Fri, Jul 22, 2016, at 12:11 AM, Julian Taylor wrote:
> On 21.07.2016 05:00, Brian Warner wrote:
> > I've just released foolscap-0.12.0 to PyPI, which should fix this. We've
> > deprecated a function that talks to the root nameservers, and this
> > release removes the test that used to exercise that function. I think
> > that was the only place which should be doing off-box network access
> > (there's plenty of localhost access, of course, this being a networking
> > package).
> >
> > I hope that will resolve the issue. Please let me know if there's
> > anything I can do to help get this packaged and (most importantly) the
> > auto-removal of Foolscap and Tahoe-LAFS resolved.
> >
> 
> thanks for the quick release, the network access appears to be fixed in 
> this release.
> I have pushed it to the debian git.
> 
> Ramakrishnan, as there are a couple changes can you verify that 
> tahoelafs still works correctly?

Yes, I have verified that it runs correctly. 

> I tried building the tahoe package but to my surprise it doesn't run any 
> tests. Does tahoe have none or are they not run in the package build?

The debian package does not run the tests on the build. Perhaps we
should be running it so that ci.debian.net captures the test results.
Thanks.

-- 
  Ramakrishnan

Bug#829272: Missing accessors

[Richard Levitte via RT]

On Mon Jul 25 11:32:17 2016, msa...@nikhef.nl wrote:
> On Sat, Jul 23, 2016 at 09:44:18AM +, Richard Levitte via RT
> wrote:
> > To get current_cert, it's X509_STORE_CTX_get_current_cert().
> > To get current_issuer, it's X509_STORE_CTX_get0_current_issuer()
>
> Hi Richard,
>
> yes, those I know, but the problem is the *setting* of the failing
> cert.
> Since we need to walk the whole chain for the proxy pathlength
> verification, we need to be able to indicate which cert is failing.
> See
> e.g.
> https://github.com/globus/globus-
>
toolkit/blob/globus_6_branch/gsi/callback/source/library/globus_gsi_callback.c#L1691
> and further, in particular line 1731.
> VOMS is basically using the same code
> https://github.com/italiangrid/voms/blob/master/src/sslutils/sslutils.c#L2236
> and further, in particular line 2255.

Is that code to cope with pathlen checking bugs? That's what it looks to me. In
that case, it might no longer be needed with OpenSSL 1.1, along with some other
stuff (the subject checking stuff comes to mind). Quite frankly, I think the
grid source needs a good and hard look over, quite a bit of it shouldn't be
needed any more. The exception is recognising pre-3820 proxy certs.

> Jan Just also sets the current_issuer in his grid-proxy-verify.c,
> http://www.nikhef.nl/~janjust/proxy-verify/
> line 346, but I'm not sure that's necessary.

> Mischa
>
> >
> > Those functions are already present in pre-1.1 OpenSSL (at least in
> > the 1.0.2
> > series)
> >
> > On Fri Jul 22 15:51:16 2016, msa...@nikhef.nl wrote:
> > > Hi,
> > >
> > > unless I didn't look careful enough I think we might still be
> > > missing
> > > the current_cert (and current_issuer) from the X509_STORE_CTX, as
> > > advertised in
> > >
> >
https://github.com/openssl/openssl/blob/master/doc/HOWTO/proxy_certificates.txt#L204
> > > and used in e.g.
> > > https://github.com/italiangrid/voms/blob/master/src/sslutils/sslutils.c
> > > and many other places for verifying the proxy chain or is there a
> > > better/other solution for that?
> > >
> > > Best wishes,
> > > Mischa
> > >
> > > On Fri, Jul 22, 2016 at 03:26:26PM +, Richard Levitte via RT
> > > wrote:
> > > > In addition to github PR 1294, there's now also PR 1339 which
> > > > adds
> > > > the function to set the EXFLAG_PROXY flag on a given certificate.
> > > >
> > > > Also, PR 1295 has been updated. Instead of a function that
> > > > returns a
> > > > lock, there is now a lock and an unlock function.
> > > >
> > > > To me, it seems that that covers what's being asked for. Perhaps
> > > > not
> > > > exactly (the setters are for X509_STORE only), but should be
> > > > workable.
> > > >
> > > > (writing this from my mobile, sorry for the lack of github links)
> > > >
> > > > --
> > > > Richard Levitte
> > > > levi...@openssl.org
> > > > --
> > > > Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4602
> > > > Please log in as guest with password guest if prompted
> > > >
> > > > --
> > > > To unsubscribe, send mail to 829272-unsubscr...@bugs.debian.org.
> >
> >
> > --
> > Richard Levitte
> > levi...@openssl.org
> >
> > --
> > Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4602
> > Please log in as guest with password guest if prompted
> >


--
Richard Levitte
levi...@openssl.org

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4602
Please log in as guest with password guest if prompted

Bug#824059: plasma-desktop: When used with pulseaudio, can make people deaf

[John Kirk]

Package: plasma-desktop
Version: 4:5.6.5-1
Followup-For: Bug #824059

Dear Maintainer,

It is still there with new packagages. Should we try to report it to KDE bugs
system?

Best wishes,
John



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

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

Versions of packages plasma-desktop depends on:
ii  breeze   4:5.7.0-1
ii  kactivitymanagerd5.7.0-1
ii  kde-cli-tools4:5.7.0-1
ii  kded55.23.0-1
ii  kio  5.23.0-1
ii  libc62.23-2
ii  libcanberra0 0.30-3
ii  libfontconfig1   2.11.0-6.4
ii  libgcc1  1:6.1.1-9
ii  libkf5activities55.23.0-1
ii  libkf5activitiesexperimentalstats1   4:5.6.5-1
ii  libkf5archive5   5.24.0-1
ii  libkf5auth5  5.23.0-1
ii  libkf5baloo5 5.23.0-1
ii  libkf5bookmarks5 5.23.0-1
ii  libkf5codecs55.23.0-1
ii  libkf5completion55.23.0-1
ii  libkf5configcore55.23.0-1
ii  libkf5configgui5 5.23.0-1
ii  libkf5configwidgets5 5.23.0-1
ii  libkf5coreaddons55.23.0-1
ii  libkf5dbusaddons55.23.0-1
ii  libkf5emoticons-bin  5.23.0-1
ii  libkf5emoticons5 5.23.0-1
ii  libkf5globalaccel5   5.23.0-1
ii  libkf5guiaddons5 5.23.0-1
ii  libkf5i18n5  5.23.0-1
ii  libkf5iconthemes55.23.0-1
ii  libkf5itemmodels55.23.0-1
ii  libkf5itemviews5 5.23.0-1
ii  libkf5jobwidgets55.23.0-1
ii  libkf5kcmutils5  5.23.0-1
ii  libkf5kdelibs4support5   5.23.0-1
ii  libkf5kiocore5   5.23.0-1
ii  libkf5kiofilewidgets55.23.0-1
ii  libkf5kiowidgets55.23.0-1
ii  libkf5newstuff5  5.23.0-1
ii  libkf5notifications5 5.23.0-1
ii  libkf5notifyconfig5  5.23.0-1
ii  libkf5parts5 5.23.0-1
ii  libkf5people55.23.0-1
ii  libkf5peoplewidgets5 5.23.0-1
ii  libkf5plasma55.23.0-1
ii  libkf5plasmaquick5   5.23.0-1
ii  libkf5quickaddons5   5.23.0-1
ii  libkf5runner55.23.0-1
ii  libkf5service-bin5.23.0-1
ii  libkf5service5   5.23.0-1
ii  libkf5solid5 5.23.0-1
ii  libkf5sonnetui5  5.23.0-1
ii  libkf5wallet-bin 5.23.0-3
ii  libkf5wallet55.23.0-3
ii  libkf5widgetsaddons5 5.23.0-1
ii  libkf5windowsystem5  5.23.0-1
ii  libkf5xmlgui55.23.0-1
ii  libkfontinst54:5.6.5-1
ii  libkfontinstui5  4:5.6.5-1
ii  libkworkspace5-5 4:5.6.5.1-1
ii  libphonon4qt5-4  4:4.9.0-3
ii  libpulse-mainloop-glib0  9.0-1.1
ii  libpulse09.0-1.1
ii  libqt5concurrent55.6.1+dfsg-3
ii  libqt5core5a 5.6.1+dfsg-3
ii  libqt5dbus5  5.6.1+dfsg-3
ii  libqt5gui5   5.6.1+dfsg-3
ii  libqt5network5   5.6.1+dfsg-3
ii  libqt5printsupport5  5.6.1+dfsg-3
ii  libqt5qml5   5.6.1-5
ii  libqt5quick5 5.6.1-5
ii  libqt5quickwidgets5  5.6.1-5
ii  libqt5sql5   5.6.1+dfsg-3
ii  libqt5svg5   5.6.1-2
ii  libqt5widgets5   5.6.1+dfsg-3
ii  libqt5x11extras5 5.6.1-2
ii  libqt5xml5   5.6.1+dfsg-3
ii  libstdc++6   6.1.1-9
ii  libtaskmanager5  4:5.6.5.1-1
ii  libx11-6 2:1.6.3-1
ii  libx11-xcb1  2:1.6.3-1
ii  libxcb-record0   1.11.1-1
ii  libxcb-xkb1  1.11.1-1
ii  libxcb1 

Bug#832371: Disable lldb on sparc64

[Sylvestre Ledru]

Le 24/07/2016 à 21:27, James Clarke a écrit :
> Source: llvm-toolchain-3.8
> Version: 1:3.8.1-4
> User: debian-sp...@lists.debian.org
> Usertags: sparc64
> X-Debbugs-Cc: debian-sp...@lists.debian.org
>
> Hi,
> Please disable lldb on sparc64, as there is no support for it. I
> have performed a test build with a patched gold (which will soon be
> uploaded to the unreleased suite and pinned on the buildds) and lldb
> disabled, and it built successfully (there were the usual big-endian
> test suite failures in polly).
done in the svn for 3.8, 3.9 & 4.0

S




signature.asc
Description: OpenPGP digital signature

Bug#832299: python-ruffus: FTBFS: sphinx.ext.mathjax: other math package is already loaded

[Andreas Tille]

On Sun, Jul 24, 2016 at 12:43:02AM +0200, Chris Lamb wrote:
>   Running Sphinx v1.4.5
>   making output directory...
>   WARNING: sphinx.ext.pngmath has been deprecated. Please use 
> sphinx.ext.imgmath instead.
>   
>   Extension error:
>   sphinx.ext.mathjax: other math package is already loaded
>   
> ['/home/lamby/temp/cdt.20160723234148.mpT9WCevsF.python-ruffus/python-ruffus-2.6.3+dfsg',
>  '/usr/share/sphinx/scripts/python2', 
> '/home/lamby/temp/cdt.20160723234148.mpT9WCevsF.python-ruffus/python-ruffus-2.6.3+dfsg/debian/python-ruffus/usr/lib/python2.7/dist-packages',
>  
> '/home/lamby/temp/cdt.20160723234148.mpT9WCevsF.python-ruffus/python-ruffus-2.6.3+dfsg/.pybuild/pythonX.Y_2.7/build',
>  '/usr/lib/python2.7', '/usr/lib/python2.7/plat-x86_64-linux-gnu', 
> '/usr/lib/python2.7/lib-tk', '/usr/lib/python2.7/lib-old', 
> '/usr/lib/python2.7/lib-dynload', '/usr/local/lib/python2.7/dist-packages', 
> '/usr/lib/python2.7/dist-packages']
>   2.6.3 2.6.3
>   Makefile:53: recipe for target 'html' failed
>   make[2]: *** [html] Error 1

I think this is fixed in last commit to Git[1].

However, I'm running into another build issue which is strange since dot
does not seem to support jpg any more:

...
OK
Running test_split_subdivide_checkpointing.py
 Run pipeline normally...
 Check that running again does nothing. (All up to date).
 Running again with forced tasks to generate more files...
 Check that running again does nothing. (All up to date).
 Running again with forced tasks to generate even more files...
 Check that running again does nothing. (All up to date).
. Run pipeline normally...
 Check that running again does nothing. (All up to date).
 Running again with forced tasks to generate more files...
 Check that running again does nothing. (All up to date).
 Running again with forced tasks to generate even more files...
 Check that running again does nothing. (All up to date).
.
--
Ran 2 tests in 5.001s

OK
Running test_pipeline_printout_graph.py
EE
==
ERROR: test_newstyle_ruffus (test_pipeline_printout_graph.Test_ruffus)
--
Traceback (most recent call last):
  File "test_pipeline_printout_graph.py", line 181, in test_newstyle_ruffus
no_key_legend = True)
  File "/build/python-ruffus-2.6.3+dfsg/ruffus/task.py", line 1558, in 
printout_graph
pipeline_printout_graph(*unnamed_args, **named_args)
  File "/build/python-ruffus-2.6.3+dfsg/ruffus/task.py", line 4659, in 
pipeline_printout_graph
signal_callback=is_node_up_to_date)
  File "/build/python-ruffus-2.6.3+dfsg/ruffus/graph.py", line 1175, in 
graph_printout
raise subprocess.CalledProcessError(retcode, cmd + "\n" + 
"\n".join([str(result_str), str(error_str)]))
CalledProcessError: Command 'dot -Gsize='(11,8)' -Gdpi='120' -Tjpg < 
/tmp/tmpW40AHi.dot

Format: "jpg" not recognized. Use one of: canon cmap cmapx cmapx_np dot eps fig 
gd gd2 gv imap imap_np ismap pdf pic plain plain-ext png pov ps ps2 svg svgz tk 
vml vmlz x11 xdot xdot1.2 xdot1.4 xlib
' returned non-zero exit status 1

==
ERROR: test_ruffus (test_pipeline_printout_graph.Test_ruffus)
--
Traceback (most recent call last):
  File "test_pipeline_printout_graph.py", line 150, in test_ruffus
no_key_legend = True)
  File "/build/python-ruffus-2.6.3+dfsg/ruffus/task.py", line 4659, in 
pipeline_printout_graph
signal_callback=is_node_up_to_date)
  File "/build/python-ruffus-2.6.3+dfsg/ruffus/graph.py", line 1175, in 
graph_printout
raise subprocess.CalledProcessError(retcode, cmd + "\n" + 
"\n".join([str(result_str), str(error_str)]))
CalledProcessError: Command 'dot -Gsize='(11,8)' -Gdpi='120' -Tjpg < 
/tmp/tmpgacay7.dot

Format: "jpg" not recognized. Use one of: canon cmap cmapx cmapx_np dot eps fig 
gd gd2 gv imap imap_np ismap pdf pic plain plain-ext png pov ps ps2 svg svgz tk 
vml vmlz x11 xdot xdot1.2 xdot1.4 xlib
' returned non-zero exit status 1

--
Ran 2 tests in 0.029s

FAILED (errors=2)
 Run pipeline normally...
 Run pipeline normally...


Before I cowardly deactivate these tests I wonder whether there is a
more sensible solution.

Kind regards

 Andreas.

[1] 
https://anonscm.debian.org/git/debian-med/python-ruffus.git/tree/debian/patches/sphinx.ext.pngmath_deprecated.patch

-- 
http://fam-tille.de

Bug#814762: Info received (Bug#814762: kmail: CSS from HTML mail interfers with header layout)

[Dominik George]

Hi,

> I actually set down today and fixed the issue or at least makes it more
> difficult to break the UI.
> 
> http://commits.kde.org/messagelib/3f9d16c7dadd2c98b00c5e7216cd69cfb518cab9
> http://commits.kde.org/kdepim-addons/a97f99b2769d39ffa03a2cd2454f10ef9322248
> 6
> http://commits.kde.org/kdepim-addons/cab925e9d4769762ea0080d49f392022cd8e78
> dd

Would this also fix the issue with the second mail I posted (positioning of 
content elements over the header)?

My suggestion would have been to wrap the mail body in an iframe instead.

-nik

-- 
PGP-Fingerprint: 3C9D 54A4 7575 C026 FB17  FD26 B79A 3C16 A0C4 F296

Dominik George · Mobil: +49-1520-1981389

Teckids e.V. · FrOSCon e.V. · OpenRheinRuhr e.V.
Fellowship of the FSFE · Piratenpartei Deutschland
Opencaching Deutschland e.V. · Debian Contributor

LPIC-3 Linux Enterprise Professional (Security)

Bug#824667: emacs24: icons in tool bar are missing

[Michael Biebl]

On Thu, 19 May 2016 00:13:23 +0900 Norbert Preining 
wrote:
> Package: emacs24
> Version: 24.5+1-6+b2
> Severity: important
> 
> Dear all,
> 
> I don't remember which update it was, but at some point the icons of 
> my emacs' toolbar got missing, see attached screenshot. Whatever scheme
> I select, no change. 

This might be fixed upstream by commit

https://github.com/emacs-mirror/emacs/commit/3f4c6d52d34538bc2d4a53246af4c61ef176

At least according to
https://bugs.archlinux.org/task/48862#comment147316


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



signature.asc
Description: OpenPGP digital signature

Bug#724284: RFP: tryton-nereid -- web framework on top of Tryton Application Platform

[Mathias Behrle]

Hi Jonas,

just to update the state of this RFP:

I don't expect further nereid[1] to be included in Tryton core. The Tryton
maintainer prefers more generic solutions like tryton_flask, tryton_web_user...
I doesn't look like there is any roadmap from the side of the involved
maintainers to integrate nereid into Tryton core.

Furthermore nereid is lagging substantialy behind Tryton trunk. nereid is
depending on Tryton, which currently has 4.0 (soonish 4.2) in unstable. Last
available version of nereid is 3.6, so there is no available candidate for
inclusion into Tryton mainline in Debian. I don't expect that ever to happen.

For the given arguments nereid probably will remain an unplausible candidate
for packaging in Debian. Therefore I would propose to close this RFP.

Best,
Mathias


[1] https://github.com/fulfilio/nereid

-- 

Mathias Behrle
PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6

Bug#766316: subdownloader: Fails to download substitles when having an accent in the path "é"

[Sylvestre Ledru]

The attached patch fixed it.

https://bugs.launchpad.net/subdownloader/+bug/1289949 provided a partial
fix. I fixed the last issue in main.py

My test didn't show other regressions but don't hesitate to double check
(you should ;)

Sylvestre


Index: changelog
===
--- changelog	(révision 13414)
+++ changelog	(copie de travail)
@@ -1,3 +1,11 @@
+subdownloader (2.0.18-3) unstable; urgency=medium
+
+  * Fix the locale issues when downloading (Closes: #766316) (LP: #1289949)
+Thanks to Beniamin Jalinowski for the patch
+Patch updated by Sylvestre Ledru
+
+ -- Sylvestre Ledru   Mon, 25 Jul 2016 13:56:54 +0200
+
 subdownloader (2.0.18-2) unstable; urgency=medium
 
   * Team upload
Index: patches/encoding-issue.diff
===
--- patches/encoding-issue.diff	(nonexistent)
+++ patches/encoding-issue.diff	(copie de travail)
@@ -0,0 +1,41 @@
+Index: subdownloader/FileManagement/FileScan.py
+===
+--- subdownloader.orig/FileManagement/FileScan.py
 subdownloader/FileManagement/FileScan.py
+@@ -52,6 +52,8 @@ def ScanFilesFolders(filepaths,recursive
+ 
+ """Scanning all the Video and Subtitle files inside a Folder/Recursive Folders"""
+ def ScanFolder(folderpath,recursively = True,report_progress=None, progress_end=None):
++if (type(folderpath) is not str):
++folderpath = folderpath.encode(sys.getfilesystemencoding())
+ #Let's reset the progress bar to 0%
+ log.debug("Scanning Folder %s" % folderpath)
+ 
+Index: subdownloader/modules/videofile.py
+===
+--- subdownloader.orig/modules/videofile.py
 subdownloader/modules/videofile.py
+@@ -25,6 +25,9 @@ class VideoFile(object):
+
+ def __init__(self, filepath):
+ self._filepath = filepath
++if (type(filepath) is not str):
++import sys
++self._filepath = filepath.encode(sys.getfilesystemencoding())
+ self._size = os.path.getsize(filepath)
+ self._hash = self.calculateOSDBHash()
+ try:
+Index: subdownloader/gui/main.py
+===
+--- subdownloader.orig/gui/main.py
 subdownloader/gui/main.py
+@@ -1065,7 +1065,8 @@ class Main(QObject, Ui_MainWindow):
+ 
+ #Check if we have write permissions, otherwise show warning window
+ while True:
+-#If the file and the folder don't have writte access.
++destinationPath = destinationPath.decode(sys.getfilesystemencoding())
++ #If the file and the folder don't have writte access.
+ if not QFileInfo(destinationPath).isWritable() and not QFileInfo(QFileInfo(destinationPath).absoluteDir().path()).isWritable() :
+ warningBox = QMessageBox(_("Error write permission"),
+ _("%s cannot be saved.\nCheck that the folder exists and you have write-access permissions.") %destinationPath ,
Index: patches/series
===
--- patches/series	(révision 13414)
+++ patches/series	(copie de travail)
@@ -3,3 +3,4 @@
 desktop-file-remove-path.patch
 no-mime-type-in-desktop-file.patch
 follow-opensubtitles-download-link
+encoding-issue.diff

Bug#724285: tryton-nereid-project -- web application for Tryton project management

[Mathias Behrle]

Hi Jonas,

the arguments exposed for nereid in #724784 apply as well for this RFP.

Furthermore development of nereid-project seems to have stalled definitely.

I recommend to close this RFP.

Best,
Mathias

-- 

Mathias Behrle
PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6

Bug#832424: vagrant in jessie is not compatible with ruby-bundler from jessie-backports

[caio2k]

Package: vagrant
Version: 1.8.4+dfsg-1
Severity: important
Tags: d-i

Dear Maintainer,

Could you please specify the minimum dependency for package ruby-bundler?
The one in jessie-backports (1.11.2-1~bpo8+1) does not satisfy binary
requirement (> 1.12.5). Error message below:

  Could not find gem 'bundler (~> 1.12.5)', which is required by gem
'vagrant (= 1.8.4)', in any of the sources.

Regards!

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

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

Versions of packages vagrant depends on:
ii  bsdtar 3.1.2-11+deb8u1
ii  curl   7.38.0-4+deb8u3
ii  openssh-client 1:6.7p1-5+deb8u3
ii  ruby   1:2.1.5+deb8u2
ii  ruby-bundler   1.11.2-1~bpo8+1
ii  ruby-childprocess  0.5.5-1
ii  ruby-erubis2.7.0-3
ii  ruby-i18n  0.6.9-2
ii  ruby-listen2.4.0-4
ii  ruby-log4r 1.1.10-4
ii  ruby-net-scp   1.2.1-1
ii  ruby-net-sftp  1:2.1.2-2
ii  ruby-net-ssh   1:2.9.1-1
ii  ruby-nokogiri  1.6.3.1+ds-1
ii  ruby-rb-inotify0.9.5-1
ii  ruby-rest-client   1.6.7-6

vagrant recommends no packages.

Versions of packages vagrant suggests:
ii  virtualbox  5.0.16-dfsg-2~bpo8+1

Bug#804079: [Xen-devel] Kernel panic on Xen virtualisation in Debian

[Ingo Jürgensmann]

On 25.07.2016 12:23, Wei Liu wrote:

First, thank you for replying! Very much appreciated! :)


I did skim your emails. But the oops was happening in memcpy+0x6 which
indicated it came back to the origin question why would it got an
exception there.

Just by staring at the code doesn't get me anywhere. Without a concrete
reproduction of the issue, I'm afraid I can't provide more input here.


Well, from my point of view, it happens quite often when accessing the 
server via SSH. For example today it crashed when I wanted to add 
something and after I clicked into putty and typed the first char. In 
another putty, where I have my netconsole log open, I instantly saw the 
oops.


But what exactly causing these kinds of reboots, I'm clueless as you 
too. Only that I do experience far more frequent crashes when accessing 
the server from workplace via putty on Windows than via SSH on OSX or 
Debian Linux.



There are several moving parts:
0. Hardware
1. Xen hypervisor
2. Dom0 kernel
Your report and the debian report suggested that Dom0 kernel is less
likely to be the culprit because you've tried different Dom0 kernels.


As just written in the other mail, I already tried kernel 4.5 from 
backports. Still crashing.



As for Xen, not sure if you would be up for trying a debug build from
source tree. That would help provide information on whether this is a
bug in Xen or not.


Will try to build from Debian source, but how to enable debug build?

--
Ciao...  //http://blog.windfluechter.net
  Ingo \X/ XMPP: i...@jabber.windfluechter.net


gpg pubkey:  http://www.juergensmann.de/ij_public_key.asc

Bug#829272: Missing accessors

[msa...@nikhef.nl via RT]

Hi Richard,

On Mon, Jul 25, 2016 at 11:46:50AM +, Richard Levitte via RT wrote:
> Is that code to cope with pathlen checking bugs? That's what it looks to me. 
> In
> that case, it might no longer be needed with OpenSSL 1.1, along with some 
> other
> stuff (the subject checking stuff comes to mind). Quite frankly, I think the
> grid source needs a good and hard look over, quite a bit of it shouldn't be
> needed any more. The exception is recognising pre-3820 proxy certs.
Yes it is, and although it's true that it's probably not needed for
RFC3820 proxy certs (although I haven't checked that) but we will need
to be able to verify GT3 proxies and we will need to be able to do the
whole chain verification there with the callback...

Mischa

> > Jan Just also sets the current_issuer in his grid-proxy-verify.c,
> > http://www.nikhef.nl/~janjust/proxy-verify/
> > line 346, but I'm not sure that's necessary.
> 
> > Mischa
> >
> > >
> > > Those functions are already present in pre-1.1 OpenSSL (at least in
> > > the 1.0.2
> > > series)
> > >
> > > On Fri Jul 22 15:51:16 2016, msa...@nikhef.nl wrote:
> > > > Hi,
> > > >
> > > > unless I didn't look careful enough I think we might still be
> > > > missing
> > > > the current_cert (and current_issuer) from the X509_STORE_CTX, as
> > > > advertised in
> > > >
> > >
> https://github.com/openssl/openssl/blob/master/doc/HOWTO/proxy_certificates.txt#L204
> > > > and used in e.g.
> > > > https://github.com/italiangrid/voms/blob/master/src/sslutils/sslutils.c
> > > > and many other places for verifying the proxy chain or is there a
> > > > better/other solution for that?
> > > >
> > > > Best wishes,
> > > > Mischa
> > > >
> > > > On Fri, Jul 22, 2016 at 03:26:26PM +, Richard Levitte via RT
> > > > wrote:
> > > > > In addition to github PR 1294, there's now also PR 1339 which
> > > > > adds
> > > > > the function to set the EXFLAG_PROXY flag on a given certificate.
> > > > >
> > > > > Also, PR 1295 has been updated. Instead of a function that
> > > > > returns a
> > > > > lock, there is now a lock and an unlock function.
> > > > >
> > > > > To me, it seems that that covers what's being asked for. Perhaps
> > > > > not
> > > > > exactly (the setters are for X509_STORE only), but should be
> > > > > workable.
> > > > >
> > > > > (writing this from my mobile, sorry for the lack of github links)
> > > > >
> > > > > --
> > > > > Richard Levitte
> > > > > levi...@openssl.org
> > > > > --
> > > > > Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4602
> > > > > Please log in as guest with password guest if prompted
> > > > >
> > > > > --
> > > > > To unsubscribe, send mail to 829272-unsubscr...@bugs.debian.org.
> > >
> > >
> > > --
> > > Richard Levitte
> > > levi...@openssl.org
> > >
> > > --
> > > Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4602
> > > Please log in as guest with password guest if prompted
> > >
> 
> 
> --
> Richard Levitte
> levi...@openssl.org
> 
> -- 
> Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4602
> Please log in as guest with password guest if prompted
> 

-- 
Nikhef  Room  H155
Science Park 105Tel.  +31-20-592 5102
1098 XG Amsterdam   Fax   +31-20-592 5155
The Netherlands Email msa...@nikhef.nl
  __ .. ... _._.  ._  ... ._ ._.. ._.. .._..

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4602
Please log in as guest with password guest if prompted



smime.p7s
Description: S/MIME cryptographic signature

Bug#829272: [openssl.org #4602] Missing accessors

[Mischa Salle]

Hi Richard,

On Mon, Jul 25, 2016 at 11:46:50AM +, Richard Levitte via RT wrote:
> Is that code to cope with pathlen checking bugs? That's what it looks to me. 
> In
> that case, it might no longer be needed with OpenSSL 1.1, along with some 
> other
> stuff (the subject checking stuff comes to mind). Quite frankly, I think the
> grid source needs a good and hard look over, quite a bit of it shouldn't be
> needed any more. The exception is recognising pre-3820 proxy certs.
Yes it is, and although it's true that it's probably not needed for
RFC3820 proxy certs (although I haven't checked that) but we will need
to be able to verify GT3 proxies and we will need to be able to do the
whole chain verification there with the callback...

Mischa

> > Jan Just also sets the current_issuer in his grid-proxy-verify.c,
> > http://www.nikhef.nl/~janjust/proxy-verify/
> > line 346, but I'm not sure that's necessary.
> 
> > Mischa
> >
> > >
> > > Those functions are already present in pre-1.1 OpenSSL (at least in
> > > the 1.0.2
> > > series)
> > >
> > > On Fri Jul 22 15:51:16 2016, msa...@nikhef.nl wrote:
> > > > Hi,
> > > >
> > > > unless I didn't look careful enough I think we might still be
> > > > missing
> > > > the current_cert (and current_issuer) from the X509_STORE_CTX, as
> > > > advertised in
> > > >
> > >
> https://github.com/openssl/openssl/blob/master/doc/HOWTO/proxy_certificates.txt#L204
> > > > and used in e.g.
> > > > https://github.com/italiangrid/voms/blob/master/src/sslutils/sslutils.c
> > > > and many other places for verifying the proxy chain or is there a
> > > > better/other solution for that?
> > > >
> > > > Best wishes,
> > > > Mischa
> > > >
> > > > On Fri, Jul 22, 2016 at 03:26:26PM +, Richard Levitte via RT
> > > > wrote:
> > > > > In addition to github PR 1294, there's now also PR 1339 which
> > > > > adds
> > > > > the function to set the EXFLAG_PROXY flag on a given certificate.
> > > > >
> > > > > Also, PR 1295 has been updated. Instead of a function that
> > > > > returns a
> > > > > lock, there is now a lock and an unlock function.
> > > > >
> > > > > To me, it seems that that covers what's being asked for. Perhaps
> > > > > not
> > > > > exactly (the setters are for X509_STORE only), but should be
> > > > > workable.
> > > > >
> > > > > (writing this from my mobile, sorry for the lack of github links)
> > > > >
> > > > > --
> > > > > Richard Levitte
> > > > > levi...@openssl.org
> > > > > --
> > > > > Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4602
> > > > > Please log in as guest with password guest if prompted
> > > > >
> > > > > --
> > > > > To unsubscribe, send mail to 829272-unsubscr...@bugs.debian.org.
> > >
> > >
> > > --
> > > Richard Levitte
> > > levi...@openssl.org
> > >
> > > --
> > > Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4602
> > > Please log in as guest with password guest if prompted
> > >
> 
> 
> --
> Richard Levitte
> levi...@openssl.org
> 
> -- 
> Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4602
> Please log in as guest with password guest if prompted
> 

-- 
Nikhef  Room  H155
Science Park 105Tel.  +31-20-592 5102
1098 XG Amsterdam   Fax   +31-20-592 5155
The Netherlands Email msa...@nikhef.nl
  __ .. ... _._.  ._  ... ._ ._.. ._.. .._..


smime.p7s
Description: S/MIME cryptographic signature

Bug#829272: Missing accessors

[Salz, Rich via RT]

Perhaps the GRID folks can just write their own validation routine completely?




-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4602
Please log in as guest with password guest if prompted

Bug#832425: apache2-bin: Apache segfault when ltrace is attached to it

[Florent Mendoza]

Package: apache2-bin
Version: 2.4.10-10+deb8u5
Severity: normal


hello, we found that apache occasionally segfault if a ltrace is running on
it.
I managed to reproduce this with default config.
A simple way to reproduce :
start apache with /usr/sbin/apache2 -X
attach a ltrace on it : ltrace -p  -o 
do some request (I run ab -c 1 -n 100 http://hostname/)
After a few seconds, a segfault occurs.

Let me know if you need any additional information.

-- Package-specific info:

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

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

Versions of packages apache2-bin depends on:
ii  libapr1  1.5.1-3
ii  libaprutil1  1.5.4-1
ii  libaprutil1-dbd-sqlite3  1.5.4-1
ii  libaprutil1-ldap 1.5.4-1
ii  libc62.19-18+deb8u4
ii  libldap-2.4-22.4.40+dfsg-1+deb8u2
ii  liblua5.1-0  5.1.5-7.1
ii  libpcre3 2:8.35-3.3+deb8u4
ii  libssl1.0.0  1.0.1t-1+deb8u2
ii  libxml2  2.9.1+dfsg1-5+deb8u2
ii  perl 5.20.2-3+deb8u5
ii  zlib1g   1:1.2.8.dfsg-2+b1

apache2-bin recommends no packages.

Versions of packages apache2-bin suggests:
pn  apache2-doc  
pn  apache2-suexec-pristine | apache2-suexec-custom  
ii  lynx-cur [www-browser]   2.8.9dev1-2+deb8u1
ii  w3m [www-browser]0.5.3-19

Versions of packages apache2 depends on:
ii  apache2-data   2.4.10-10+deb8u5
ii  apache2-utils  2.4.10-10+deb8u5
ii  dpkg   1.17.27
ii  lsb-base   4.1+Debian13+nmu1
ii  mime-support   3.58
ii  perl   5.20.2-3+deb8u5
ii  procps 2:3.3.9-9

Versions of packages apache2 recommends:
pn  ssl-cert  

Versions of packages apache2 suggests:
pn  apache2-doc  
pn  apache2-suexec-pristine | apache2-suexec-custom  
ii  lynx-cur [www-browser]   2.8.9dev1-2+deb8u1
ii  w3m [www-browser]0.5.3-19

Versions of packages apache2-bin is related to:
ii  apache2  2.4.10-10+deb8u5
ii  apache2-bin  2.4.10-10+deb8u5

-- no debconf information

Bug#829272: Missing accessors

[msa...@nikhef.nl via RT]

On Mon, Jul 25, 2016 at 12:42:21PM +, Salz, Rich via RT wrote:
> Perhaps the GRID folks can just write their own validation routine completely?

That's exactly what we currently do, we provide a verification callback,
but we do need to be able to set the failing cert in a chain for that.

Mischa


> -- 
> Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4602
> Please log in as guest with password guest if prompted
> 

-- 
Nikhef  Room  H155
Science Park 105Tel.  +31-20-592 5102
1098 XG Amsterdam   Fax   +31-20-592 5155
The Netherlands Email msa...@nikhef.nl
  __ .. ... _._.  ._  ... ._ ._.. ._.. .._..

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4602
Please log in as guest with password guest if prompted



smime.p7s
Description: S/MIME cryptographic signature

Bug#829272: [openssl-dev] [openssl.org #4602] Missing accessors

[Salz, Rich]

> That's exactly what we currently do, we provide a verification callback, but
> we do need to be able to set the failing cert in a chain for that.

Stick it in EXDAT?

Bug#829272: [openssl-dev] [openssl.org #4602] Missing accessors

[Salz, Rich]

Perhaps the GRID folks can just write their own validation routine completely?

Bug#829272: [openssl-dev] [openssl.org #4602] Missing accessors

[Mischa Salle]

On Mon, Jul 25, 2016 at 12:42:21PM +, Salz, Rich via RT wrote:
> Perhaps the GRID folks can just write their own validation routine completely?

That's exactly what we currently do, we provide a verification callback,
but we do need to be able to set the failing cert in a chain for that.

Mischa


> -- 
> Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4602
> Please log in as guest with password guest if prompted
> 

-- 
Nikhef  Room  H155
Science Park 105Tel.  +31-20-592 5102
1098 XG Amsterdam   Fax   +31-20-592 5155
The Netherlands Email msa...@nikhef.nl
  __ .. ... _._.  ._  ... ._ ._.. ._.. .._..


smime.p7s
Description: S/MIME cryptographic signature

Bug#829272: Missing accessors

[Salz, Rich via RT]

> That's exactly what we currently do, we provide a verification callback, but
> we do need to be able to set the failing cert in a chain for that.

Stick it in EXDAT?

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4602
Please log in as guest with password guest if prompted

Bug#832426: sipwitch FTBFS on mips64el - incorrect symbols

[Daniel Knezevic]

Package: sipwitch
Version: 1.9.15-3
Severity: important
Tags: sid + patch
Justification: FTBFS
User: debian-m...@lists.debian.org
Usertags: mips-patch

Hi,


Package sipwitch FTBFS on mips64el with following error:
dpkg-gensymbols: warning: some new symbols appeared in the symbols file: see 
diff output below
dpkg-gensymbols: warning: some symbols or patterns disappeared in the symbols 
file: see diff output below
dpkg-gensymbols: warning: debian/libsipwitch1/DEBIAN/symbols doesn't match 
completely debian/libsipwitch1.symbols
--- debian/libsipwitch1.symbols (libsipwitch1_1.9.15-3_mips64el)
+++ dpkg-gensymbolsqMAiNS   2016-05-06 11:26:51.143472215 +
@@ -276,6 +276,8 @@
  _ZTVN8sipwitch7service8callbackE@Base 1.9.15
  _ZTVN8sipwitch7serviceE@Base 1.9.15
  _ZTVN8sipwitch9UserCacheE@Base 1.9.15
+ _ZTv0_n40_N7ucommon9stringbufILm1024EED0Ev@Base 1.9.15-3
+ _ZTv0_n40_N7ucommon9stringbufILm1024EED1Ev@Base 1.9.15-3
  (c++)"virtual thunk to sipwitch::Cache::~Cache()@Base" 1.9.15
  (c++)"virtual thunk to sipwitch::UserCache::release()@Base" 1.9.15
  (c++)"virtual thunk to sipwitch::UserCache::~UserCache()@Base" 1.9.15
@@ -283,6 +285,6 @@
  (c++)"virtual thunk to sipwitch::modules::sipwitch::~sipwitch()@Base" 1.9.15
  (c++)"virtual thunk to sipwitch::service::callback::~callback()@Base" 1.9.15
  (c++)"virtual thunk to sipwitch::service::~service()@Base" 1.9.15
- (c++|arch=!amd64 !arm64 !kfreebsd-amd64 !ppc64el !s390x !sparc64)"virtual 
thunk to ucommon::stringbuf<1024u>::~stringbuf()@Base" 1.9.15
+#MISSING: 1.9.15-3# (c++|arch=!amd64 !arm64 !kfreebsd-amd64 !ppc64el !s390x 
!sparc64)"virtual thunk to ucommon::stringbuf<1024u>::~stringbuf()@Base" 1.9.15
  (c++|arch=amd64 arm64 kfreebsd-amd64 ppc64el s390x sparc64)"virtual thunk to 
ucommon::stringbuf<1024ul>::~stringbuf()@Base" 1.9.15
  (c++)"virtual thunk to ucommon::treemap::~treemap()@Base" 1.9.15
dh_makeshlibs: failing due to earlier errors
/usr/share/cdbs/1/rules/debhelper.mk:262: recipe for target 
'binary-fixup/libsipwitch1' failed
make: *** [binary-fixup/libsipwitch1] Error 255

https://buildd.debian.org/status/fetch.php?pkg=sipwitch&arch=mips64el&ver=1.9.15-3&stamp=1462534017

The attached patch adds support to mips64el in debian/libsipwitch1.symbols file.

With this patch I was able to build sipwitch successfully for mips64el.

Thanks,
Daniel
--- orig/sipwitch-1.9.15/debian/libsipwitch1.symbols2016-04-24 16:05:44.0 +
+++ sipwitch-1.9.15/debian/libsipwitch1.symbols 2016-07-25 11:28:54.226686087 +
@@ -1,4 +1,4 @@
-# SymbolsHelper-Confirmed: 1.9.15 amd64 arm64 armel armhf hppa hurd-i386 i386 kfreebsd-amd64 kfreebsd-i386 m68k mips mipsel powerpc ppc64el s390x sparc64
+# SymbolsHelper-Confirmed: 1.9.15 amd64 arm64 armel armhf hppa hurd-i386 i386 kfreebsd-amd64 kfreebsd-i386 m68k mips mipsel mips64el powerpc ppc64el s390x sparc64
 libsipwitch.so.1 libsipwitch1 #MINVER#
  (optional=templinst)_ZN7ucommon12mapped_arrayIN8sipwitch5statsEED0Ev@Base 1.9.15
  (optional=templinst)_ZN7ucommon12mapped_arrayIN8sipwitch5statsEED1Ev@Base 1.9.15
@@ -284,6 +284,6 @@
  (c++)"virtual thunk to sipwitch::modules::sipwitch::~sipwitch()@Base" 1.9.15
  (c++)"virtual thunk to sipwitch::service::callback::~callback()@Base" 1.9.15
  (c++)"virtual thunk to sipwitch::service::~service()@Base" 1.9.15
- (c++|arch=!amd64 !arm64 !kfreebsd-amd64 !ppc64el !s390x !sparc64)"virtual thunk to ucommon::stringbuf<1024u>::~stringbuf()@Base" 1.9.15
- (c++|arch=amd64 arm64 kfreebsd-amd64 ppc64el s390x sparc64)"virtual thunk to ucommon::stringbuf<1024ul>::~stringbuf()@Base" 1.9.15
+ (c++|arch=!amd64 !arm64 !kfreebsd-amd64 !ppc64el !s390x !sparc64 !mips64el)"virtual thunk to ucommon::stringbuf<1024u>::~stringbuf()@Base" 1.9.15
+ (c++|arch=amd64 arm64 kfreebsd-amd64 ppc64el s390x sparc64 mips64el)"virtual thunk to ucommon::stringbuf<1024ul>::~stringbuf()@Base" 1.9.15
  (c++)"virtual thunk to ucommon::treemap::~treemap()@Base" 1.9.15

Bug#829272: [openssl-dev] [openssl.org #4602] Missing accessors

[Mischa Salle]

On Mon, Jul 25, 2016 at 12:47:56PM +, Salz, Rich via RT wrote:
> 
> > That's exactly what we currently do, we provide a verification callback, but
> > we do need to be able to set the failing cert in a chain for that.
> 
> Stick it in EXDAT?

I don't think I understand what you mean...
For a proper callback, we need to be able to indicate which cert in the
chain has failed. This used to be done by setting the 'current_cert'
field in the CTX. I'm perfectly happy if we need to do this differently
e.g. by using something like a
X509_STORE_CTX_set_error_depth(X509_STORE_CTX *ctx,int depth);
similar to the existing X509_STORE_CTX_get_error_depth()
That actually would make the most sense in any case I would think,
although I would mean that for properly handling proxy chains it would
have negative values according to the man-page...

Mischa


-- 
Nikhef  Room  H155
Science Park 105Tel.  +31-20-592 5102
1098 XG Amsterdam   Fax   +31-20-592 5155
The Netherlands Email msa...@nikhef.nl
  __ .. ... _._.  ._  ... ._ ._.. ._.. .._..


smime.p7s
Description: S/MIME cryptographic signature

Bug#774148: fontforge: please propagate creation and modification times to generated ttf files

[Chris Lamb]

Hi,

> fontforge: please propagate creation and modification
> times to generated ttf files

I've appended an--entirely untested patch--to upstream's bug for this:

 https://github.com/fontforge/fontforge/issues/2490#issuecomment-234947526

This was before I realised they were trying to remove timestamps
altogether.


Regards,

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

Bug#829272: Missing accessors

[msa...@nikhef.nl via RT]

On Mon, Jul 25, 2016 at 12:47:56PM +, Salz, Rich via RT wrote:
> 
> > That's exactly what we currently do, we provide a verification callback, but
> > we do need to be able to set the failing cert in a chain for that.
> 
> Stick it in EXDAT?

I don't think I understand what you mean...
For a proper callback, we need to be able to indicate which cert in the
chain has failed. This used to be done by setting the 'current_cert'
field in the CTX. I'm perfectly happy if we need to do this differently
e.g. by using something like a
X509_STORE_CTX_set_error_depth(X509_STORE_CTX *ctx,int depth);
similar to the existing X509_STORE_CTX_get_error_depth()
That actually would make the most sense in any case I would think,
although I would mean that for properly handling proxy chains it would
have negative values according to the man-page...

Mischa


-- 
Nikhef  Room  H155
Science Park 105Tel.  +31-20-592 5102
1098 XG Amsterdam   Fax   +31-20-592 5155
The Netherlands Email msa...@nikhef.nl
  __ .. ... _._.  ._  ... ._ ._.. ._.. .._..

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4602
Please log in as guest with password guest if prompted



smime.p7s
Description: S/MIME cryptographic signature

Bug#832427: RM: kbackup -- ROM; Dead upstream and maintained alternatives exist

[Scott Kitterman]

Package: ftp.debian.org
Severity: normal

Upstream hasn't touched this in 4 years and it's KDE 4 based, so eventually it
has to go.  I'd prefer not to see it in the next release, so best remove it
now.

Bug#826042: Spyder crashes on start

[Ghislain Vaillant]

On 24/07/16 21:49, Ghislain Vaillant wrote:

Regarding rope, the package has a wishlist bug for Python 3 and also a
CVE (which is bad). It might be worth checking with the package
maintainer whether he still actively maintains it, and propose a
migration to the DPMT Git. I'll contact him and propose my help.


I have contacted Arnaud Fontaine, who's the current package maintainer
for rope, to ask for an update on this. I'll report when he responds.
Until he does, rope remains a pending issue for spyder in Python 3.

Ghis

Bug#832413: google-android-m2repository-installer: fails to install, remove, and install again

[Mouaad Aallam]

>
>  Hi,
>
> during a test with piuparts I noticed your package failed to install,
> remove (but not purge), and install again.


Hello,

Thank you for the report :)
This error has been fixed and more other improvements have been introduced
already
in the next patch which will be introduced soon.

Regards,
*Mouaad Aallam*

Bug#832428: override: r10k:admin/optional

[Markus Frosch]

Package: ftp.debian.org
Severity: normal
Control: block 832251 by -1

As suggested in "Bug#832251: r10k: Section should not be “ruby”"

The section “ruby” is for packages that install the Ruby programming
language or libraries. Its packages are primarily of interest only to
Ruby programmers.

The package ‘r10k’ installs primarily an application, of interest
regardless of the programming language. It should not be in the “ruby”
section.

By the section descriptions, this package may belong in section
“admin”.

Regards
Markus
-- 
mar...@lazyfrosch.de / lazyfro...@debian.org
http://www.lazyfrosch.de



signature.asc
Description: OpenPGP digital signature

Bug#814762: Info received (Bug#814762: kmail: CSS from HTML mail interfers with header layout)

[Sandro Knauß]

Hi,

> Would this also fix the issue with the second mail I posted (positioning of
> content elements over the header)?

yes because now the header css is only active in the header.
 
> My suggestion would have been to wrap the mail body in an iframe instead.

mmh do you can add headers etc. inside iframe? for me all docus looks like, 
that you can only place a url and nothing else.

Regards,

sandro

Bug#804079: [Xen-devel] Kernel panic on Xen virtualisation in Debian

[Wei Liu]

On Mon, Jul 25, 2016 at 01:41:41PM +0200, Ingo Jürgensmann wrote:
> On 25.07.2016 12:23, Wei Liu wrote:
> 
> First, thank you for replying! Very much appreciated! :)
> 
> >I did skim your emails. But the oops was happening in memcpy+0x6 which
> >indicated it came back to the origin question why would it got an
> >exception there.
> >
> >Just by staring at the code doesn't get me anywhere. Without a concrete
> >reproduction of the issue, I'm afraid I can't provide more input here.
> 
> Well, from my point of view, it happens quite often when accessing the
> server via SSH. For example today it crashed when I wanted to add something
> and after I clicked into putty and typed the first char. In another putty,
> where I have my netconsole log open, I instantly saw the oops.
> 
> But what exactly causing these kinds of reboots, I'm clueless as you too.
> Only that I do experience far more frequent crashes when accessing the
> server from workplace via putty on Windows than via SSH on OSX or Debian
> Linux.
> 
> >There are several moving parts:
> >0. Hardware
> >1. Xen hypervisor
> >2. Dom0 kernel
> >Your report and the debian report suggested that Dom0 kernel is less
> >likely to be the culprit because you've tried different Dom0 kernels.
> 
> As just written in the other mail, I already tried kernel 4.5 from
> backports. Still crashing.
> 
> >As for Xen, not sure if you would be up for trying a debug build from
> >source tree. That would help provide information on whether this is a
> >bug in Xen or not.
> 
> Will try to build from Debian source, but how to enable debug build?
> 

I was thinking about building directly from xen.git.

http://wiki.xenproject.org/wiki/Compiling_Xen_From_Source

Probably try the Xen 4.7 release.

Wei.

> -- 
> Ciao...  //http://blog.windfluechter.net
>   Ingo \X/ XMPP: i...@jabber.windfluechter.net
> 
> 
> gpg pubkey:  http://www.juergensmann.de/ij_public_key.asc

Bug#832338: [PKG-Openstack-devel] Bug#832338: openstack-dashboard: fails to install: No template loaders defined.

[Thomas Goirand]

On 07/24/2016 02:13 PM, Andreas Beckmann wrote:
> Package: openstack-dashboard
> Version: 3:10.0.0~b2-1
> Severity: serious
> User: debian...@lists.debian.org
> Usertags: piuparts
> 
> Hi,
> 
> during a test with piuparts I noticed your package failed to install. As
> per definition of the release team this makes the package too buggy for
> a release, thus the severity.
> 
>>From the attached log (scroll to the bottom...):
> 
> [...]
>   1917 static files copied to '/usr/share/openstack-dashboard/static'.
>   Traceback (most recent call last):
> File "/usr/share/openstack-dashboard/manage.py", line 25, in 
>   execute_from_command_line(sys.argv)
> File 
> "/usr/lib/python2.7/dist-packages/django/core/management/__init__.py", line 
> 367, in execute_from_command_line
>   utility.execute()
> File 
> "/usr/lib/python2.7/dist-packages/django/core/management/__init__.py", line 
> 359, in execute
>   self.fetch_command(subcommand).run_from_argv(self.argv)
> File "/usr/lib/python2.7/dist-packages/django/core/management/base.py", 
> line 305, in run_from_argv
>   self.execute(*args, **cmd_options)
> File "/usr/lib/python2.7/dist-packages/django/core/management/base.py", 
> line 356, in execute
>   output = self.handle(*args, **options)
> File 
> "/usr/lib/python2.7/dist-packages/compressor/management/commands/compress.py",
>  line 286, in handle
>   self.compress(sys.stdout, **options)
> File 
> "/usr/lib/python2.7/dist-packages/compressor/management/commands/compress.py",
>  line 110, in compress
>   raise OfflineGenerationError("No template loaders defined. You "
>   compressor.exceptions.OfflineGenerationError: No template loaders defined. 
> You must set TEMPLATE_LOADERS in your settings or set 'loaders' in your 
> TEMPLATES dictionary.
>   dpkg: error processing package openstack-dashboard (--configure):
>subprocess installed post-installation script returned error exit status 1
>   Errors were encountered while processing:
>openstack-dashboard
> 
> 
> cheers,
> 
> Andreas

FYI, this is a very well known issue which we're currently working on.
The problem is compatibility with Django 1.10. I already pushed many
patches to the Git in this regard, and also pushed them upstream. Though
this is still a work in progress.

Cheers,

Thomas Goirand (zigo)

Bug#793387:

[Daniel Scharon]

Hi Antonio, 
 
> > can we still expect an update for stable that fixes this?
> 
> we could, but I need help as I explained earlier in this bug report.

unfortunatly I am not quite sure about the specifics of the help needed.
Do you mean testing the packages in your repo at
https://people.debian.org/~terceiro/redmine-jessie/ ?

> > Or do we have to wait for a backport of the version in stretch (if that
> > is in any way feasible)?
> 
> probably not happening as that would involve also backporting the entire
> rails stack and quite a few other dependencies.

I understand.

Cheers,
Dan



smime.p7s
Description: S/MIME cryptographic signature

Bug#814762: kmail: CSS from HTML mail interfers with header layout

[Lisandro Damián Nicanor Pérez Meyer]

Control: severity -1 important

On lunes, 25 de julio de 2016 12:17:55 P. M. ART Dominik George wrote:
> Control: severity -1 grave

Please: do not override a maintainer's severity.

> Hi,
> 
> >Even more, a mail header can be "spoofed" using simpler tools, like an
> >smtp
> >server, thus I'm not really convinced that this bug deserves a "grave"
> >severity.
> 
> Did you read all of this bug report?

I did. I will not emit a judgment on the security side of this as this is 
really something I don't manage, but...

> 2. in my follow-up, I showed that in 16.04, legitimate HTML mail breaks the
> UI. This has nothing to do with spoofing - KMail breaks when opening
> random, legitimate mail. I cannot even click any controls in the mail view
> anymore. This affects daily, normal work with KMail and makes it unusable
> for reading legitimate mail. That is the definition of "grave functionality
> bug".

Yes, it breaks but:

- only on certain mails. Not any mail shows this behaviour. In fact I haven't 
even seen it before and I use kmail daily.

- you can change the way headers are displayed and this bug doesn't shows up 
(I have just tried your example with "Fancy headers"), so there is a known 
work around.

So it might be annoying for you, but considering the above it does not meets 
the RC criterion at least from the usability side.

On the other hand, please avoid expressions that might sound harsh like 
"Please do something!" and "Did you read all of this bug report?". Always do 
your best to be kind. After all you already did the only thing we can do: 
report the bug upstream. We are volunteers trying to make things happen, we do 
not get paid for doing this and definitely we are not your employees. A little 
respect goes a long way :)

Thank you for your undertanding!

-- 
This end should point toward the ground if you want to go to space.
If it starts pointing toward space you are having a bad problem
and you will not get to space today.
  http://xkcd.com/1133/

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


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

Bug#829063: graphicsmagick: regression convert: Non-conforming drawing primitive definition (push)

[Bob Friesenhahn]

On Mon, 25 Jul 2016, László Böszörményi (GCS) wrote:


On Sun, Jul 24, 2016 at 3:16 PM, Paul Gevers  wrote:

On Sun, 3 Jul 2016 13:39:40 -0500 (CDT) Bob Friesenhahn
 wrote:

While the SVG rendering properties are not improved, this error is
fixed by GraphicsMagick Mercurial changeset 14869:ae78bb613993.


Are the graphicsmagick maintainers considering to upload the fix to Debian?

As I read, Bob found two other SVG related problems[1]:
"I found two problems.  One was related to the pixel limits checks and
the other was related to an arbitrary limit I added to try to limit
DoS opportunities."


There is an unfortunate issue in that the many SVG-based icons 
delivered under /usr/share are almost all authored using inkscape and 
apparently inkscape makes no consideration for the size of the 
gradient images that it requests.  For example, I have observed a 
gradient image request of 20,000x20,000 pixels for a SVG which renders 
to 8x8 pixels.  GraphicsMagick actually produces a gradient image 
based on requests (in advance) rather than storing values for later 
use in an equation.  It is possible that some gradients which were 
requested were not subsequenty used.


The fact that gradients consume real resources is a flaw in 
GraphicsMagick, but inkscape's propensity to produce unreasonably huge 
gradient requests is not helping.


Allowing gradient requests of 5000x5000 pixels (outrageous!) is 
sufficent to render most of the icon SVGs delivered via /usr/share.



Please let us know either way, so we can judge if we need to work around
this issue that is causing our FTBFS.

If this is the only SVG problem and fix, I can backport it and do an
upload. However I recall an other email from Bob who said (wrote) that
GraphicsMagick 1.3.25 is expected soon with several important fixes.
Waiting on feedback.


It is true that I do not plan to do much more work on GraphicsMagick 
before making another release.  I only expect to make changes related 
to security issues.


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/

Bug#829272: [openssl-dev] [openssl.org #4602] Missing accessors

[Salz, Rich]

I am not sure what to suggest.  This conversation is bouncing across two ticket 
systems and is all about a legacy certificate format that is, what, outdated 
since 2002?

I am hard-pressed to see why OpenSSL 1.1 has to do anything other than what 
Richard proposed.

Bug#829272: Missing accessors

[Salz, Rich via RT]

I am not sure what to suggest.  This conversation is bouncing across two ticket 
systems and is all about a legacy certificate format that is, what, outdated 
since 2002?

I am hard-pressed to see why OpenSSL 1.1 has to do anything other than what 
Richard proposed.

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4602
Please log in as guest with password guest if prompted

Bug#832429: RFS: python-hydroffice.bag/0.2.15-1 [ITP]

[Ghislain Vaillant]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "python-hydroffice.bag"

* Package name: python-hydroffice.bag
  Version : 0.2.15-1
  Upstream Author : Brian R. Calder and Giuseppe Masetti
* URL : http://www.hydroffice.org
* License : LGPL-3
  Section : science

It builds those binary packages:

  hydroffice.bag-tools - tools for hydroffice.bag
  python-hydroffice.bag - manage Bathymetric Attributed Grid (BAG) data 
files in Python 2

  python-hydroffice.bag-doc - documentation for hydroffice.bag
  python3-hydroffice.bag - manage Bathymetric Attributed Grid (BAG) 
data files in Python 3


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


  https://mentors.debian.net/package/python-hydroffice.bag

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

  dget -x 
https://mentors.debian.net/debian/pool/main/p/python-hydroffice.bag/python-hydroffice.bag_0.2.15-1.dsc


Successful build on debomatic:


http://debomatic-amd64.debian.net/distribution#unstable/python-hydroffice.bag/0.2.15-1/buildlog

Changes since the last upload:

   * Initial release. (Closes: #823233)

Regards,
Ghislain Vaillant

Bug#832430: ITP: haskell-th-data-compat -- Compatibility for data definition template of TemplateHaskell

[Kei Hibino]

Package: wnpp
Severity: wishlist
Owner: Kei Hibino 

* Package name: haskell-th-data-compat
  Version : 0.0.2.2
  Upstream Author : Kei Hibino 
* URL : https://github.com/khibino/haskell-th-data-compat
* License : BSD3
  Programming Lang: Haskell
  Description : Compatibility for data definition template of 
TemplateHaskell

This package contains wrapped name definitions of data definition template
using in TemplateHaskell.

- This package provides compatible interface for data definition template
  in TemplateHaskell between GHC 7.x and 8.0
- This package is used in Haskell Relatoinal Record 
  ( http://khibino.github.io/haskell-relational-record/ ) project.
- I'm planning to maintain this package inside the pkg-haskell team.
- I need a sponsor.

Bug#829272: [openssl-dev] [openssl.org #4602] Missing accessors

[Mischa Salle]

On Mon, Jul 25, 2016 at 01:44:18PM +, Salz, Rich via RT wrote:
> I am not sure what to suggest.  This conversation is bouncing across
> two ticket systems and is all about a legacy certificate format that
> is, what, outdated since 2002?
> I am hard-pressed to see why OpenSSL 1.1 has to do anything other than
> what Richard proposed.

The two ticket systems is indeed annoying and I don't know what to do
about that (I did not start this thread) other than removing one of
them.

The point is that if OpenSSL is providing a verification callback which
can be used to provide a custom verification of the cert chain, then it
should provide the necessary handles and the thing still missing from
what Richard proposed is a way to point to the failing certificate in
the chain. We can set the error, but not at which depth in the chain the
error occurred.
This in itself is not limited to our use-case but is a general API
request.

Mischa




> 
> -- 
> Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4602
> Please log in as guest with password guest if prompted
> 

-- 
Nikhef  Room  H155
Science Park 105Tel.  +31-20-592 5102
1098 XG Amsterdam   Fax   +31-20-592 5155
The Netherlands Email msa...@nikhef.nl
  __ .. ... _._.  ._  ... ._ ._.. ._.. .._..

Bug#832431: getting 444 error

[Brent S. Elmer]

Package: galileo
Version: 0.5.0~git160510-1
Severity: grave

Recently I started getting a 444 error when running galileo.

$ galileo
# A serious error happened, which is probably due to a
# programming error. Please open a new issue with the following
# information on the galileo bug tracker:
#https://bitbucket.org/benallard/galileo/issues/new
# /usr/local/bin/galileo: 0.4.4
# Python: 2.7.12 (default, Jun 29 2016, 08:18:26) [GCC 5.4.0 20160609]
# Platform: Linux brente 4.5.1.160421 #1 SMP PREEMPT Thu Apr 21 14:55:11 CDT
2016 x86_64
# pyusb: 1.0.0b2
# requests: 2.10.0
# yaml: 3.11 (with libyaml)
Traceback (most recent call last):
  File "/usr/local/bin/galileo", line 9, in 
load_entry_point('galileo==0.4.4', 'console_scripts', 'galileo')()
  File "/usr/local/lib/python2.7/dist-packages/galileo/main.py", line 276, in
main
}[config.mode](config)
  File "/usr/local/lib/python2.7/dist-packages/galileo/main.py", line 206, in
sync
for tracker in syncAllTrackers(config):
  File "/usr/local/lib/python2.7/dist-packages/galileo/main.py", line 76, in
syncAllTrackers
if not galileo.requestStatus(not config.httpsOnly):
  File "/usr/local/lib/python2.7/dist-packages/galileo/net.py", line 164, in
requestStatus
self.post('status')
  File "/usr/local/lib/python2.7/dist-packages/galileo/net.py", line 120, in
post
r.raise_for_status()
  File "/usr/lib/python2.7/dist-packages/requests/models.py", line 844, in
raise_for_status
raise HTTPError(http_error_msg, response=self)
requests.exceptions.HTTPError: 444 Client Error:  for url:
https://client.fitbit.com:443/tracker/client/message



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

Kernel: Linux 4.5.1.160421 (SMP w/8 CPU cores; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages galileo depends on:
ii  python3-requests  2.10.0-2
ii  python3-usb   1.0.0-1
pn  python3:any   

galileo recommends no packages.

galileo suggests no packages.

-- no debconf information

Bug#832434: dpkg-shlibdeps.1: typos

[Carsten Leonhardt]

Package: src:dpkg
Version: 1.18.9
Severity: minor
Tags: patch
Justification: documentation

Dear Maintainer,

I noticed two typos / grammatical errors in dpkg-shlibdeps.1 and
attached a patch. The phrase "they uses" also occurs in several files in
man/po/ but the patch does not touch that directory, as I didn't check
if these are somehow autogenerated.

Carsten

diff --git a/man/dpkg-shlibdeps.1 b/man/dpkg-shlibdeps.1
index 5573779..0a9d409 100644
--- a/man/dpkg-shlibdeps.1
+++ b/man/dpkg-shlibdeps.1
@@ -300,14 +300,14 @@ symbols provided by the library. By fixing all the binaries, you would avoid
 the dependency associated to this library (unless the same dependency is
 also generated by another library that is really used).
 .TP
-.BI "package could avoid a useless dependency if " binaries " were not linked against " library " (they uses none of the library's symbols)"
+.BI "package could avoid a useless dependency if " binaries " were not linked against " library " (they use none of the library's symbols)"
 Exactly the same as the above warning, but for multiple binaries.
 .TP
 .IB binary " should not be linked against " library " (it uses none of the library's symbols)"
 The \fIbinary\fR is linked to a library that it doesn't need. It's not a
 problem but some small performance improvements in binary load time can be
 obtained by not linking this library to this binary. This warning checks
-the same information than the previous one but does it for each binary
+the same information as the previous one but does it for each binary
 instead of doing the check globally on all binaries analyzed.
 .SS Errors
 .B dpkg\-shlibdeps

Bug#832237: [Pkg-javascript-devel] Bug#832237: libjs-mousetrap: Section should not be “ruby”

[Alexandre Viau]

Hello Ben,

On 23/07/16 08:36 AM, Ben Finney wrote:
> The package ‘libjs-mousetrap’ installs primarily a library in the
> JavaScript programming language. It should not be in the “ruby”
> section.
> 
> By the section descriptions, this package may belong in section
> “web”.

The section in the control field is "web".

-
https://sources.debian.net/src/libjs-mousetrap/1.6.0%2Bdfsg1-1/debian/control/#L2

I wonder where the issue is from? I can confirm that the section shows
as ruby by running apt-get show.

Perhaps a bit more history is needed to understand the issue.
libjs-mousetrap was originally shipped by another source package
(ruby-mousetrap-rails), which I had hijacked inadvertently.

Cheers,

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



signature.asc
Description: OpenPGP digital signature

Bug#829731: Correct repository

[u]

Hi,

Carsten Schoenert:
> Hello intri,
> 
> On Sat, Jul 23, 2016 at 02:45:19PM +0200, intrigeri wrote:
>> FWIW, a profile refresh for Thunderbird 45 has been proposed there:
>> https://code.launchpad.net/~sdeziel/+git/apparmor-profiles/+ref/thunderbird-45-refresh
> 
> due this reflect some needed changes to the apparmor profile for
> Icedove? I think so, nor?
> Guido added the suggested patch from this report with a small addition
> for the dh_install section.
> 
> https://anonscm.debian.org/cgit/pkg-mozilla/icedove.git/commit/?id=b24bbaa782da7b416f40943931bf994000ea006b
> https://anonscm.debian.org/cgit/pkg-mozilla/icedove.git/commit/?id=6fe4897bbe86dc74a74aa1747454adbcacbf2e7f
> 
> Could you please, if needed, prepare a new patch against the already
> commited changes?

I'll take care of it tomorrow.

Cheers!
u.

Bug#825956: [Pkg-utopia-maintainers] Bug#825956: Bug#825956: policykit-1: greyed out reboot, shutdown, hibernate with 0.105-15~deb8u1, but 0.105-8 is ok

[Jeffrey Sheinberg]

On Tue, May 31, 2016 at 09:09:08PM +0200, Michael Biebl wrote:
> Am 31.05.2016 um 21:03 schrieb Jeffrey Sheinberg:
> > On Tue, May 31, 2016 at 08:14:47PM +0200, Michael Biebl wrote:
> >> Am 31.05.2016 um 19:52 schrieb Jeffrey Sheinberg:
> >>> Kernel: Linux 4.5.0-0.bpo.2-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)
> >>
> >> Please also try to reproduce that issue with the default init system,
> >> i.e. systemd-sysv.
> >>
> > 
> > As far as I understand it, the following configuration is fully
> > supported on Debian-8 (jessie),
> 
> I'm using neither LXDE nor sysvinit. So I rely on others that do to
> provide support for those configurations.
> 
> Me asking to try systemd-sysv was an attempt to try narrow down the problem.

Hi Michael,

I installed systemd-sysv on my jessie testing partition so that I could
gain some familiarity with systemd and init-select.

Somewhere along the way, I accidently upgraded policykit from 0.105-8 to
0.105-15~deb8u1.  As I was switching back and forth between systemd and 
sysvinit, I noticed that when systemd was active, the greyed out menus were
no longer greyed out, and were now working properly - and at the next
reboot using sysvinit - those same menus are still working properly.

Back to my production jessie partition, with policykit 0.105-8
installed, along with sysvinit-core - menus are working properly. I
installed systemd-sysv and init-select, deinstalling sysvinit-core.
Over the next few days, I reboot a few times, alternating between
systemd and sysvinit - then when sysvinit is active, I upgrade policykit
from 0.105-8 to 0.105-15~deb8u1 - the menus are working properly.

Note that I had submitted the original bug report after having upgraded
policykit from 0.105-8 to 0.105-15~deb8u1 with sysvinit-core installed,
and never having had installed systemd-sysv.

Finally, I install sysvinit-core, and deinstall init-select and systemd-sysv,
and then shutdown using the still working lightdm menus.  Next morning,
I reboot and the menus are again working properly.

So it appears that this bug report can be closed, since the original
problem no longer manifests.

Thanks,
-- 
Jeffrey Sheinberg

Bug#832435: ITP: lua-nvim -- lua client for neovim

[Jason Pleau]

Package: wnpp
Severity: wishlist
Owner: Jason Pleau 

* Package name: lua-nvim
  Version : 0.0.1-25
  Upstream Author : Neovim contributors
* URL : https://github.com/neovim/lua-client/
* License : Apache-2.0
  Programming Lang: Lua, C
  Description : lua client for neovim

Lua library to communicate with Neovim through its msgpack-rpc API

It will eventually be able to act as a Lua plugin host, enabling the use and
development of Lua plugins for Neovim.



This package is required to run the tests for neovim

It will be maintained in pkg-lua

Bug#832433: CVE-2016-1000108

[Moritz Muehlenhoff]

Source: yaws
Severity: normal
Tags: security

http://seclists.org/oss-sec/2016/q3/95 claims that yaws sets
HTTP_PROXY based a passed Proxy: header. I don't see any
evidence for that in the source, but maybe I'm missing something?

heers,
Moritz

Bug#814762: kmail: CSS from HTML mail interfers with header layout

[Dominik George]

Hi,

> > 2. in my follow-up, I showed that in 16.04, legitimate HTML mail breaks
> > the
> > UI. This has nothing to do with spoofing - KMail breaks when opening
> > random, legitimate mail. I cannot even click any controls in the mail view
> > anymore. This affects daily, normal work with KMail and makes it unusable
> > for reading legitimate mail. That is the definition of "grave
> > functionality
> > bug".
> 
> Yes, it breaks but:
> 
> - only on certain mails. Not any mail shows this behaviour. In fact I
> haven't even seen it before and I use kmail daily.
> 
> - you can change the way headers are displayed and this bug doesn't shows up
> (I have just tried your example with "Fancy headers"), so there is a known
> work around.

That'd be ok if I chose some header format in the first place. I am using what 
KMail imposes on me (changing with every version). As a matter of fact, after 
the upgrade, KMail imposed a new header layout on me *and* failed to display 
some e-mail messages correctly.

Maybe not overriding user settings with every upgrade would be a good starting 
poitn (I do not know whether this should address the Debian maintainers or 
upstream).

> 
> So it might be annoying for you, but considering the above it does not meets
> the RC criterion at least from the usability side.

OK… I still do not agree with that, though.

> 
> On the other hand, please avoid expressions that might sound harsh like
> "Please do something!" and "Did you read all of this bug report?". Always do
> your best to be kind. After all you already did the only thing we can do:
> report the bug upstream. We are volunteers trying to make things happen, we
> do not get paid for doing this and definitely we are not your employees. A
> little respect goes a long way :)

Well, this bug report has been open for almost half a year without any 
reaction whatsoever, neither by upstream nor by a maintainer. Instead, with 
another upgrade, it even got worse. I understand that both upstream and 
maintainers are volunteers, but they agreed on reacting to certain kinds of 
bug reports within a reasonable time. I know that if I completely ignored a 
security bug in one of my packages for several months, I'd be beheaded by my 
sponsors.

Doing something in your freetime does not mean users can't get annoyed when 
the software they use gets worse instead of better.

Cheers,
Nik


-- 
PGP-Fingerprint: 3C9D 54A4 7575 C026 FB17  FD26 B79A 3C16 A0C4 F296

Dominik George · Mobil: +49-1520-1981389

Teckids e.V. · FrOSCon e.V. · OpenRheinRuhr e.V.
Fellowship of the FSFE · Piratenpartei Deutschland
Opencaching Deutschland e.V. · Debian Contributor

LPIC-3 Linux Enterprise Professional (Security)

Bug#829272: Missing accessors

[Richard Levitte via RT]

On Mon Jul 25 12:39:43 2016, msa...@nikhef.nl wrote:
> Hi Richard,
>
> On Mon, Jul 25, 2016 at 11:46:50AM +, Richard Levitte via RT
> wrote:
> > Is that code to cope with pathlen checking bugs? That's what it looks
> > to me. In
> > that case, it might no longer be needed with OpenSSL 1.1, along with
> > some other
> > stuff (the subject checking stuff comes to mind). Quite frankly, I
> > think the
> > grid source needs a good and hard look over, quite a bit of it
> > shouldn't be
> > needed any more. The exception is recognising pre-3820 proxy certs.
> Yes it is, and although it's true that it's probably not needed for
> RFC3820 proxy certs (although I haven't checked that) but we will need
> to be able to verify GT3 proxies and we will need to be able to do the
> whole chain verification there with the callback...

Why do you need to do that? That sounds like your duplicating what's already
being done for reasons I cannot fathom.

BUT... I'm realising that when you do recognise a GT3 proxy (I think I've seen
check_issued functions being used for that), there's no way for external code
to set the proxy path length for the certificate in question. While that's fine
for GT2 proxies (there's no pc path length there that I can see), it does need
to be properly set for GT3 proxies.

For the rest, though, I don't quite see why you'd need to check that path
length *again* in the verification callback. The verification callback is meant
to be used for the certification currently being checked, and should return 0
or 1, depending on if you want the current certificate to verify to to fail.
That's it.

The remaining thing to check, as far as I understand, is proxy policy. The
X509_STORE_CTX ex_data is the place to accumulate data in to make sure policy
continues to be valid thoughout the verification process.

What, in all this, am I missing?

>
> Mischa
>
> > > Jan Just also sets the current_issuer in his grid-proxy-verify.c,
> > > http://www.nikhef.nl/~janjust/proxy-verify/
> > > line 346, but I'm not sure that's necessary.
> >
> > > Mischa
> > >
> > > >
> > > > Those functions are already present in pre-1.1 OpenSSL (at least
> > > > in
> > > > the 1.0.2
> > > > series)
> > > >
> > > > On Fri Jul 22 15:51:16 2016, msa...@nikhef.nl wrote:
> > > > > Hi,
> > > > >
> > > > > unless I didn't look careful enough I think we might still be
> > > > > missing
> > > > > the current_cert (and current_issuer) from the X509_STORE_CTX,
> > > > > as
> > > > > advertised in
> > > > >
> > > >
> >
https://github.com/openssl/openssl/blob/master/doc/HOWTO/proxy_certificates.txt#L204
> > > > > and used in e.g.
> > > > >
https://github.com/italiangrid/voms/blob/master/src/sslutils/sslutils.c
> > > > > and many other places for verifying the proxy chain or is there
> > > > > a
> > > > > better/other solution for that?
> > > > >
> > > > > Best wishes,
> > > > > Mischa
> > > > >
> > > > > On Fri, Jul 22, 2016 at 03:26:26PM +, Richard Levitte via
> > > > > RT
> > > > > wrote:
> > > > > > In addition to github PR 1294, there's now also PR 1339 which
> > > > > > adds
> > > > > > the function to set the EXFLAG_PROXY flag on a given
> > > > > > certificate.
> > > > > >
> > > > > > Also, PR 1295 has been updated. Instead of a function that
> > > > > > returns a
> > > > > > lock, there is now a lock and an unlock function.
> > > > > >
> > > > > > To me, it seems that that covers what's being asked for.
> > > > > > Perhaps
> > > > > > not
> > > > > > exactly (the setters are for X509_STORE only), but should be
> > > > > > workable.
> > > > > >
> > > > > > (writing this from my mobile, sorry for the lack of github
> > > > > > links)
> > > > > >
> > > > > > --
> > > > > > Richard Levitte
> > > > > > levi...@openssl.org
> > > > > > --
> > > > > > Ticket here:
> > > > > > http://rt.openssl.org/Ticket/Display.html?id=4602
> > > > > > Please log in as guest with password guest if prompted
> > > > > >
> > > > > > --
> > > > > > To unsubscribe, send mail to 829272-
> > > > > > unsubscr...@bugs.debian.org.
> > > >
> > > >
> > > > --
> > > > Richard Levitte
> > > > levi...@openssl.org
> > > >
> > > > --
> > > > Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4602
> > > > Please log in as guest with password guest if prompted
> > > >
> >
> >
> > --
> > Richard Levitte
> > levi...@openssl.org
> >
> > --
> > Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4602
> > Please log in as guest with password guest if prompted
> >


--
Richard Levitte
levi...@openssl.org

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4602
Please log in as guest with password guest if prompted

Bug#832436: debhelper: pass -I. through to Makefile.PL and Build.PL

[Dominic Hargreaves]

Package: debhelper
Version: 9.20160709
Severity: important

Hi maintainer,

An update for debhelper has been released as part of our handling for
the issue described below. This allows many packages to continue to
build once '.' is removed from @INC. The plan is to do that as soon as
practical in stable and unstable.

I attach the patch I applied for jessie; please could you review this
and apply something similar for sid?

Thanks,
Dominic.

- Forwarded message from Salvatore Bonaccorso  -

Date: Mon, 25 Jul 2016 14:18:38 +
From: Salvatore Bonaccorso 
To: debian-security-annou...@lists.debian.org
Subject: [SECURITY] [DSA 3628-1] perl security update

-
Debian Security Advisory DSA-3628-1   secur...@debian.org
https://www.debian.org/security/ Salvatore Bonaccorso
July 25, 2016 https://www.debian.org/security/faq
-

Package: perl
CVE ID : CVE-2016-1238 CVE-2016-6185
Debian Bug : 829578

Multiple vulnerabilities were discovered in the implementation of the
Perl programming language. The Common Vulnerabilities and Exposures
project identifies the following problems:

CVE-2016-1238

John Lightsey and Todd Rinaldo reported that the opportunistic
loading of optional modules can make many programs unintentionally
load code from the current working directory (which might be changed
to another directory without the user realising) and potentially
leading to privilege escalation, as demonstrated in Debian with
certain combinations of installed packages.

The problem relates to Perl loading modules from the includes
directory array ("@INC") in which the last element is the current
directory ("."). That means that, when "perl" wants to load a module
(during first compilation or during lazy loading of a module in run-
time), perl will look for the module in the current directory at the
end, since '.' is the last include directory in its array of include
directories to seek. The issue is with requiring libraries that are
in "." but are not otherwise installed.

With this update several modules which are known to be vulnerable
are updated to not load modules from current directory.

Additionally the update allows configurable removal of "." from @INC
in /etc/perl/sitecustomize.pl for a transitional period. It is
recommended to enable this setting if the possible breakage for a
specific site has been evaluated. Problems in packages provided in
Debian resulting from the switch to the removal of '.' from @INC
should be reported to the Perl maintainers at
p...@packages.debian.org .

It is planned to switch to the default removal of '.' in @INC in a
subsequent update to perl via a point release if possible, and in
any case for the upcoming stable release Debian 9 (stretch).

CVE-2016-6185

It was discovered that XSLoader, a core module from Perl to
dynamically load C libraries into Perl code, could load shared
library from incorrect location. XSLoader uses caller() information
to locate the .so file to load. This can be incorrect if
XSLoader::load() is called in a string eval. An attacker can take
advantage of this flaw to execute arbitrary code.

For the stable distribution (jessie), these problems have been fixed in
version 5.20.2-3+deb8u6. Additionally this update includes the
following updated packages to address optional module loading
vulnerabilities related to CVE-2016-1238, or to address build failures
which occur when '.' is removed from @INC:

 - cdbs 0.4.130+deb8u1
 - debhelper 9.20150101+deb8u2
 - devscripts 2.15.3+deb8u1
 - exim4 4.84.2-2+deb8u1
 - libintl-perl 1.23-1+deb8u1
 - libmime-charset-perl 1.011.1-1+deb8u2
 - libmime-encwords-perl 1.014.3-1+deb8u1
 - libmodule-build-perl 0.421000-2+deb8u1
 - libnet-dns-perl 0.81-2+deb8u1
 - libsys-syslog-perl 0.33-1+deb8u1
 - libunicode-linebreak-perl 0.0.20140601-2+deb8u2

We recommend that you upgrade your perl packages.

Further information about Debian Security Advisories, how to apply
these updates to your system and frequently asked questions can be
found at: https://www.debian.org/security/

Mailing list: debian-security-annou...@lists.debian.org



- End forwarded message -
>From d4ac7680af8f2d9c265bf96b9cb96942c7fe54a7 Mon Sep 17 00:00:00 2001
From: Dominic Hargreaves 
Date: Thu, 7 Jul 2016 16:54:15 +0200
Subject: [PATCH 1/2] Invoke Makefile.PL and Build.PL with perl -I. as part of
 the fixes for CVE-2016-1238

---
 Debian/Debhelper/Buildsystem/perl_build.pm | 2 +-
 Debian/Debhelper/Buildsystem/perl_makemaker.pm | 2 +-
 debian/changelog   | 8 
 3 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/Debian/Debhelper/Buildsystem/perl_build.pm b/Debian/

Bug#814762: Info received (Bug#814762: kmail: CSS from HTML mail interfers with header layout)

[Dominik George]

Hi,

> > Would this also fix the issue with the second mail I posted (positioning
> > of
> > content elements over the header)?
> 
> yes because now the header css is only active in the header.

Did you test with the example mail I provided?

> 
> > My suggestion would have been to wrap the mail body in an iframe instead.
> 
> mmh do you can add headers etc. inside iframe? for me all docus looks like,
> that you can only place a url and nothing else.

You can either load a document from a URL with the src="…" attribute or add a 
document inline with the srcdoc="…" attribute. The latter would require smart 
escaping of the message body and is in general a somewhat broken idea in my 
opinion.

I'd actually write the message body to be displayed as HTML to a temporary 
file and load that with .

Actually, the iframe's sandbox attribute seams to be the way to go here, as it 
prevents the exact things we want to prevent here.

Your approach is a good additional safety net, though.

-nik

-- 
PGP-Fingerprint: 3C9D 54A4 7575 C026 FB17  FD26 B79A 3C16 A0C4 F296

Dominik George · Mobil: +49-1520-1981389

Teckids e.V. · FrOSCon e.V. · OpenRheinRuhr e.V.
Fellowship of the FSFE · Piratenpartei Deutschland
Opencaching Deutschland e.V. · Debian Contributor

LPIC-3 Linux Enterprise Professional (Security)

Bug#832437: stunnel4: /etc/stunnel/README should note that pid= needed for more than one tunnel

[Sean Whitton]

Package: stunnel4
Version: 3:5.35-1
Severity: wishlist

Dear maintainer,

If there is more than one *.conf file in /etc/stunnel defining more than
one tunnel, each one needs its own pid= setting or only one tunnel will
be started.

Confusingly, this pid= setting must come /before/ the square-bracketed
section header for the tunnel configured by the *.conf file.  For
example, this is correct:

pid = /var/run/stunnel/foo.pid
[foo]
accept = 127.0.0.1:143
...

but this will fail:

[foo]
pid = /var/run/stunnel/foo.pid
accept = 127.0.0.1:143
...

I only figured this out by trial-and-error.  Since it's
counterintuitive, I think that /etc/stunnel/README should explain the
requirement.

Thanks.

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

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

Versions of packages stunnel4 depends on:
ii  adduser  3.115
ii  libc62.23-1
ii  libssl1.0.2  1.0.2h-1
ii  libsystemd0  230-7
ii  libwrap0 7.6.q-25
ii  netbase  5.3
ii  openssl  1.0.2h-1
pn  perl:any 

stunnel4 recommends no packages.

Versions of packages stunnel4 suggests:
pn  logcheck-database  

-- Configuration Files:
/etc/default/stunnel4 changed [not included]

-- no debconf information

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#832438: cdbs: pass -I. through to Makefile.PL and Build.PL

[Dominic Hargreaves]

Package: cdbs
Version: 0.4.142
Severity: important

Hi maintainer,

An update for debhelper has been released as part of our handling for
the issue described below. This allows many packages to continue to
build once '.' is removed from @INC. The plan is to do that as soon as
practical in stable and unstable.

I attach the patch I applied for jessie; please could you review this
and apply something similar for sid?

Thanks,
Dominic.

- Forwarded message from Salvatore Bonaccorso  -

Date: Mon, 25 Jul 2016 14:18:38 +
From: Salvatore Bonaccorso 
To: debian-security-annou...@lists.debian.org
Subject: [SECURITY] [DSA 3628-1] perl security update

-
Debian Security Advisory DSA-3628-1   secur...@debian.org
https://www.debian.org/security/ Salvatore Bonaccorso
July 25, 2016 https://www.debian.org/security/faq
-

Package: perl
CVE ID : CVE-2016-1238 CVE-2016-6185
Debian Bug : 829578

Multiple vulnerabilities were discovered in the implementation of the
Perl programming language. The Common Vulnerabilities and Exposures
project identifies the following problems:

CVE-2016-1238

John Lightsey and Todd Rinaldo reported that the opportunistic
loading of optional modules can make many programs unintentionally
load code from the current working directory (which might be changed
to another directory without the user realising) and potentially
leading to privilege escalation, as demonstrated in Debian with
certain combinations of installed packages.

The problem relates to Perl loading modules from the includes
directory array ("@INC") in which the last element is the current
directory ("."). That means that, when "perl" wants to load a module
(during first compilation or during lazy loading of a module in run-
time), perl will look for the module in the current directory at the
end, since '.' is the last include directory in its array of include
directories to seek. The issue is with requiring libraries that are
in "." but are not otherwise installed.

With this update several modules which are known to be vulnerable
are updated to not load modules from current directory.

Additionally the update allows configurable removal of "." from @INC
in /etc/perl/sitecustomize.pl for a transitional period. It is
recommended to enable this setting if the possible breakage for a
specific site has been evaluated. Problems in packages provided in
Debian resulting from the switch to the removal of '.' from @INC
should be reported to the Perl maintainers at
p...@packages.debian.org .

It is planned to switch to the default removal of '.' in @INC in a
subsequent update to perl via a point release if possible, and in
any case for the upcoming stable release Debian 9 (stretch).

CVE-2016-6185

It was discovered that XSLoader, a core module from Perl to
dynamically load C libraries into Perl code, could load shared
library from incorrect location. XSLoader uses caller() information
to locate the .so file to load. This can be incorrect if
XSLoader::load() is called in a string eval. An attacker can take
advantage of this flaw to execute arbitrary code.

For the stable distribution (jessie), these problems have been fixed in
version 5.20.2-3+deb8u6. Additionally this update includes the
following updated packages to address optional module loading
vulnerabilities related to CVE-2016-1238, or to address build failures
which occur when '.' is removed from @INC:

 - cdbs 0.4.130+deb8u1
 - debhelper 9.20150101+deb8u2
 - devscripts 2.15.3+deb8u1
 - exim4 4.84.2-2+deb8u1
 - libintl-perl 1.23-1+deb8u1
 - libmime-charset-perl 1.011.1-1+deb8u2
 - libmime-encwords-perl 1.014.3-1+deb8u1
 - libmodule-build-perl 0.421000-2+deb8u1
 - libnet-dns-perl 0.81-2+deb8u1
 - libsys-syslog-perl 0.33-1+deb8u1
 - libunicode-linebreak-perl 0.0.20140601-2+deb8u2

We recommend that you upgrade your perl packages.

Further information about Debian Security Advisories, how to apply
these updates to your system and frequently asked questions can be
found at: https://www.debian.org/security/

Mailing list: debian-security-annou...@lists.debian.org



- End forwarded message -
>From 494b17cb191b0ba216194b38182f69105811e33b Mon Sep 17 00:00:00 2001
From: Dominic Hargreaves 
Date: Sat, 9 Jul 2016 11:24:41 +0200
Subject: [PATCH] Invoke Makefile.PL and Build.PL with perl -I. as part of the
 fixes for CVE-2016-1238

---
 1/class/perl-build.mk.in  | 2 +-
 1/class/perl-makemaker-vars.mk.in | 2 +-
 1/class/perlmodule-vars.mk.in | 2 +-
 debian/changelog  | 8 
 4 files changed, 11 insertions(+), 3 deletions(-)

diff --git a/1/class/perl-build.mk.in b/1/class/perl-build.mk.in
index 416

Bug#832439: libunicode-linebreak-perl: CVE-2016-1238 fix

[Dominic Hargreaves]

Package: libunicode-linebreak-perl
Version: 0.0.20160301-1
Severity: important

Hi maintainer,

An update for this package has been released as part of our handling for
the issue described below. This fixes an instance of the dynamic module
loading vulnerability alluded to.

I attach the patch I applied for jessie; please could you review this
and apply something similar for sid?

Thanks,
Dominic.

- Forwarded message from Salvatore Bonaccorso  -

Date: Mon, 25 Jul 2016 14:18:38 +
From: Salvatore Bonaccorso 
To: debian-security-annou...@lists.debian.org
Subject: [SECURITY] [DSA 3628-1] perl security update

-
Debian Security Advisory DSA-3628-1   secur...@debian.org
https://www.debian.org/security/ Salvatore Bonaccorso
July 25, 2016 https://www.debian.org/security/faq
-

Package: perl
CVE ID : CVE-2016-1238 CVE-2016-6185
Debian Bug : 829578

Multiple vulnerabilities were discovered in the implementation of the
Perl programming language. The Common Vulnerabilities and Exposures
project identifies the following problems:

CVE-2016-1238

John Lightsey and Todd Rinaldo reported that the opportunistic
loading of optional modules can make many programs unintentionally
load code from the current working directory (which might be changed
to another directory without the user realising) and potentially
leading to privilege escalation, as demonstrated in Debian with
certain combinations of installed packages.

The problem relates to Perl loading modules from the includes
directory array ("@INC") in which the last element is the current
directory ("."). That means that, when "perl" wants to load a module
(during first compilation or during lazy loading of a module in run-
time), perl will look for the module in the current directory at the
end, since '.' is the last include directory in its array of include
directories to seek. The issue is with requiring libraries that are
in "." but are not otherwise installed.

With this update several modules which are known to be vulnerable
are updated to not load modules from current directory.

Additionally the update allows configurable removal of "." from @INC
in /etc/perl/sitecustomize.pl for a transitional period. It is
recommended to enable this setting if the possible breakage for a
specific site has been evaluated. Problems in packages provided in
Debian resulting from the switch to the removal of '.' from @INC
should be reported to the Perl maintainers at
p...@packages.debian.org .

It is planned to switch to the default removal of '.' in @INC in a
subsequent update to perl via a point release if possible, and in
any case for the upcoming stable release Debian 9 (stretch).

CVE-2016-6185

It was discovered that XSLoader, a core module from Perl to
dynamically load C libraries into Perl code, could load shared
library from incorrect location. XSLoader uses caller() information
to locate the .so file to load. This can be incorrect if
XSLoader::load() is called in a string eval. An attacker can take
advantage of this flaw to execute arbitrary code.

For the stable distribution (jessie), these problems have been fixed in
version 5.20.2-3+deb8u6. Additionally this update includes the
following updated packages to address optional module loading
vulnerabilities related to CVE-2016-1238, or to address build failures
which occur when '.' is removed from @INC:

 - cdbs 0.4.130+deb8u1
 - debhelper 9.20150101+deb8u2
 - devscripts 2.15.3+deb8u1
 - exim4 4.84.2-2+deb8u1
 - libintl-perl 1.23-1+deb8u1
 - libmime-charset-perl 1.011.1-1+deb8u2
 - libmime-encwords-perl 1.014.3-1+deb8u1
 - libmodule-build-perl 0.421000-2+deb8u1
 - libnet-dns-perl 0.81-2+deb8u1
 - libsys-syslog-perl 0.33-1+deb8u1
 - libunicode-linebreak-perl 0.0.20140601-2+deb8u2

We recommend that you upgrade your perl packages.

Further information about Debian Security Advisories, how to apply
these updates to your system and frequently asked questions can be
found at: https://www.debian.org/security/

Mailing list: debian-security-annou...@lists.debian.org



- End forwarded message -
diff -Nru libunicode-linebreak-perl-0.0.20140601/debian/changelog libunicode-linebreak-perl-0.0.20140601/debian/changelog
--- libunicode-linebreak-perl-0.0.20140601/debian/changelog	2014-08-24 23:23:55.0 +0100
+++ libunicode-linebreak-perl-0.0.20140601/debian/changelog	2016-07-24 22:12:45.0 +0100
@@ -1,3 +1,17 @@
+libunicode-linebreak-perl (0.0.20140601-2+deb8u2) jessie-security; urgency=high
+
+  * Non-maintainer upload.
+  * Provide fixed version of previous security patch
+
+ -- Dominic Hargreaves   Sun, 24 Jul 2016 22:12:19 +0100
+
+libunicode-linebreak