Bug#813468: [Pkg-openssl-devel] Bug#813468: cross-references and workaround

[Kurt Roeckx]

block 813468 by 765639
thanks

On Tue, Feb 02, 2016 at 03:04:41PM +0100, Christian Beer wrote:
> Since it works in openssl 1.0.2 you can either upgrade the package in
> Jessie to 1.0.2 (which is unlikely I think) or backport the fix for
> 1.0.2 to 1.0.1 upstream (which is even more unlikely).

This has already been fixed in the upstream 1.0.1 release of a
year ago.


Kurt

Bug#809363: (probably) fixed upstream

[Stefano Costa]

On Mon, 1 Feb 2016 15:13:11 +0100 Rene Engelhard  wrote:

> so it should be fixed in 5.1.1... At least it is here with my build of
> current libreoffice-5-1 branch.
> (If you want to check yourself: deb
> http://people.debian.org/~rene/libreoffice/5.1.1 ./)

Yes, the problem is fixed in this version. Thank you,

steko

--
Stefano Costa
http://steko.iosa.it/
Editor, Journal of Open Archaeology Data
http://openarchaeologydata.metajnl.com/

Bug#775651: systemd: /run/user/$UID directories are created with type tmpfs_t on SE Linux

[Laurent Bigonville]

On Sat, 30 Jan 2016 16:56:43 +0100 Michael Biebl  wrote:
> On Mon, 19 Jan 2015 10:05:55 +0100 Michael Biebl  
wrote:

> > Am 19.01.2015 um 03:20 schrieb Russell Coker:
> > > On Mon, 19 Jan 2015, Michael Biebl  wrote:
> > >> unfortunately I don't have any selinux knowledge at all, so I 
don't have

> > >> the slightest idea how this (or your earlier bug #775613) should be
> > >> addressed.
> > >>
> > >> Help is most welcome.
> > >
> > > Would you like me to give you root access on a virtual machine that
> > > demonstrates the bugs in question?
> >
> > Thanks for the kind offer. I'm not sure if it would help, since, as
> > said, I don't know anything about selinux. At least not enough to
> > examine and understand the issue.
>
> So, where do we stand on this. Is this actually something which needs to
> be addressed in the systemd package or is this an issue of the selinux
> policy package shipped in Debian and should be reassigned accordingly?
>
> Russel, Laurent, would very much appreciate your help with this bug 
report.


After some discussion on #selinux@freenode and some testing, it seems 
that there is still an issue here.


Somebody on the channel made a patch, I hope it will be upstreamed.

Cheers,

Laurent Bigonville

Bug#811422: [Pkg-wmaker-devel] Bug#811422: wmaker: Maximize does no longer respect "Always on top" of the dock

[Andreas Tscharner]

On 21.01.2016 22:59, Doug Torrance wrote:
> On 01/21/2016 04:01 PM, Andreas Tscharner wrote:
>> No, I think you understood it correctly.
>>
>> I have never set this option before (and it worked) and now I set it,
>> and it still does not work. The window is maximized to the full size of
>> the screen and therefore a part of it is under the dock (and dock apps)
>> because it is set to always on top.
>>
>> This is also the case in the today updated Debian version 0.95.7-3
> 
> Thanks for the info!
> 
> Another question:
> 
> Is this only occurring for your email program?  Or for all windows?

It was for all applications, but I forgot to save the "Do not cover the
dock when maximizing" option. I saved it and now it works. Sorry for the
noise. This bug can be closed.

Thanks and best regards
Andreas
-- 
  ("`-''-/").___..--''"`-._
   `o_ o  )   `-.  ( ).`-.__.`)
   (_Y_.)'  ._   )  `._ `. ``-..-'
 _..`--'_..-_/  /--'_.' .'
(il).-''  (li).'  ((!.-'

Andreas Tscharner   a...@vis.ethz.ch   ICQ-No. 14356454



signature.asc
Description: OpenPGP digital signature

Bug#813447: debci: Please drop useless debian/po directory

[Christian PERRIER]

Quoting Antonio Terceiro (terce...@debian.org):
> argh, sorry about that. Just removed it in git, debian/po will be gone
> in the next upload

No problem, thanks for the quick answer. It indeed took me weeks to
realize why I was still seeing debci in the "packages with stuff to
translate" while you told me in another BR that you were about to drop
debconf (and indeed did so).


-- 




signature.asc
Description: PGP signature

Bug#813019: transition: nfft 3.3

[Ghislain Vaillant]

On 02/02/16 18:00, Emilio Pozuelo Monfort wrote:

Hi,

On 28/01/16 15:47, Ghislain Antony Vaillant wrote:

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

Dear Release Team,

I would like to request a transition for the latest version of nfft from
experimental to unstable.

Some API breaking changes were introduced from in version 3.3.0 and current
rdeps of nfft will require appropriate patching. The following bugs have been
filed with severity important:

   * pynfft: #812997
   * yorick-ynfft: #812995

Let me know if further action is required on my end. I intend to fix pynfft,
since I am the personal maintainer and upstream author of the package.


Are there patches for yorick-ynfft, or what's the plan for that?

Cheers,
Emilio


I did try to implement a fix for yorick-nfft based on my knowledge of
the API changes in nfft, but its test suite still fails for some reason.
I won't have time to investigate further, so it would be up to the
maintainer of yorick-nfft to finish the job. I believe he is also the
upstream developer.

Regarding pynfft, I am currently working on a different implementation
using cffi instead of Cython and could end-up dropping support of the
package both upstream and downstream altogether, once the new
implementation is out. I am happy to provide a patch for the current
pynfft package present in the archive if that can help.

Ghis

Bug#813524: ITP: djangocms-admin-style -- CSS styles for the django CMS admin interface

[Michael Fladischer]

Package: wnpp
Severity: wishlist
Owner: Michael Fladischer 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: djangocms-admin-style
  Version : 1.1.0
  Upstream Author : Ales Kocjancic 
* URL : https://github.com/divio/djangocms-admin-style
* License : BSD-3-clause
  Programming Lang: Python
  Description : CSS styles for the django CMS admin interface

 django CMS is a modern web publishing platform built with Django. It offers
 out-of-the-box support for the common features expected from a CMS, but can
 also be easily customised and extended by developers to create a site that is
 tailored to their precise needs.
 .
 django CMS is a well-tested CMS platform that powers sites both large and
 small. Here are a few of the key features:
  * robust internationalisation (i18n) support for creating multilingual sites
  * virtually unlimited undo history, allowing editors to revert to a previous
version
  * front-end editing, providing rapid access to the content management
interface
  * support for a variety of editors with advanced text editing features
  * a flexible plugins system that lets developers put powerful tools at the
fingertips of editors, without overwhelming them with a difficult interface
 .
 This package contains the common assets of the admin styles required by
 django CMS.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCgAGBQJWsOiNAAoJEGlMre9Rx7W2Cs0QAKn36DXm4NqpZAR9peQsfgsK
O0bnQIKedxKIwP3gEE54zDFIsN5ZsRrdDpwcoSqoxgjyPsEw26oC35k2uEZqZY01
CuGZdOeW1O7anjCgQrn+eBmc295/JMd7X27oRYJNXzjb2wOVVGA9H8ALM0eEc31p
uOpXM+VHBLCmtx1MW5cNl3Fe2jKefJSVFEKYO6fkCOyWra2noRW0MK2P/sQi6p95
96hZeFmMwpMX4UPqrPF8qApcIh+6kpB3z4uN5uTuE++R8Bz0Li3d3CGNGkF4KDW3
wzY6WSuo3NPB4gpgjXk/QV7pWP1BxorscJ/4SqUClLS3Y31q/130gJR8PhD9y9kG
340M6ggOv9eS6uqjJOm6FZkMcjS2pQafeKtWNYMOCQR+ZAXDQ8jJ8nJEir9rVPiL
pPqBLmmdWYU20aDRGcUBz7PAzsgum4bIA2AHOu/rDQ5havtCqoOZDJ+zzyyFFBar
QFIc5m2rs4v5jVJpAlrkPqG7bT9jFSpgcnO4bCqhHJs1AoPt1hsU7rHQ/fKrwKzn
kLnUGv3u7RWmmPRMVe1FpOxEmJWFw13I7tUn+PwJF4DWpCdug/I+IXzeNzlOozfA
hOXtgxHSZWQd5N0XgVKN0YPSpofvCDEuaUtUpnrTD3+UnLt3tXJ/ZtSM8J7+iaQw
GPseju16+5Uzhm/ExZ/Y
=PE5F
-END PGP SIGNATURE-

Bug#813525: lintian: Please make --no-tag-display-limit configurable

[gregor herrmann]

Package: lintian
Version: 2.5.40.2
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

As per subject -- I'd like to stick --no-tag-display-limit into my
~/.lintianrc (or set tag-display-limit=42 or something like that).

Cheers,
gregor


-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQJ8BAEBCgBmBQJWsOmHXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXREMUUxMzE2RTkzQTc2MEE4MTA0RDg1RkFC
QjNBNjgwMTg2NDlBQTA2AAoJELs6aAGGSaoG7LsP/RmKXrxrqBy2IhGeiNcropx3
q5M6ZNRcKya7wFjhBz/onMs024fqaUhEvA+TGYoDumVLdPBYAvy4kdnpYmEGQhAx
XP/yx/riWL01P5/sRCSxG875Xzngz8gH4iNqenaJBpFWwgiWJrGkFIocqN4nLXHc
GmokFOEl0sm8Kcf/kYZNSs+Z5QzvN7zmG95Rh+g+pXOtIOFMC+WkT/hvCKT5Qw/K
B/CoyiCzPfx9UnWKsNZTdu0KyNOp65RitcqyHtWBYtO1h1RpUBfc4xMsYDQSHZxd
e4Wr6keiZWegHgJxdPSXEo0EzjFJOKRbBp/p7J+RvgfOvu6LNJAtG+3WNYMZGdpI
dzyfLSrFlnXHTN/zBTc5Lka1uNQSSutzj26/QiDlA1da+N5XS5I9/7daKxVhbuyM
j69LtivrV1vGYvEUB/FvD3Vndv6QipLi2CtacpyrDkeOeEPlclN8n3xYaMZUKbjF
jTVBY2ZodcMDaTRBsBdj7va16lfLGmSQKK9kCdAi+qZJMmhNu6ez7NOjtxYZ+h/4
aKceH3TT81WkVzyxSRgnSYG1mOe/tB7hsHIT6s3RmZm3mHJ/g/aX6Ks+YEFOQAVY
2cttiCZhIdVdk38lJij9Km9P8i4CaHchVlsmn5WKfl3JMt+/unz8qXHN29eZLNTo
Gnk2mNr94rfHIQK/ydcA
=npgv
-END PGP SIGNATURE-

Bug#813414: osmo: Backup Data creates a 50 Bytes "empty" file

[Markus Koschany]

Control: tags -1 - moreinfo - unreproducible + confirmed
Control: forwarded -1 https://sourceforge.net/p/osmo-pim/bugs/108/

On Tue, 2 Feb 2016 17:29:53 +0100 Markus Koschany  wrote:
> Am 02.02.2016 um 11:30 schrieb Christian Buchmüller:
> > Did what you have suggested.
> > 
> > Quited osmo
> > Removed ~/.osmo
> > Restarted osmo
> > Added several test data
> > Backup Data
> > Restore Data
> > Everything lost, backup is still a 50 bytes file!
> 
> Something must be different but unfortunately I have no idea what.

Sorry that I haven't noticed until now that you reported this issue for
i386. Indeed on i386 I can reproduce this behavior. Forwarded to Osmo's
issue tracker on sourceforge.net.

Regards,

Markus





signature.asc
Description: OpenPGP digital signature

Bug#813497: kodi: Segfault on Startup

[Stephen Allen]

More information and potentially solved:

Since this issue only started this morning after using Kodi last
evening, and subsequent 'apt upgrade' I think it was the
libbasicusageenvironment1 update and removal of
libbasicusageenvironment0. I re-installed the latter, logged out and
motion video works as before. They seem to be happy side by side too. 

Bug#745027: Missing dependencies

[Markus Unterwaditzer]

Sorry to insist, but I'd really like to have a definitive answer on this before
vdirsyncer is packaged.

I suspect that if vdirsyncer makes its way into stable before 1.0, it
essentially means I'm forced into long-term support of whichever release is in
stable. However, ideally I'd like to only support the latest release of
vdirsyncer.

If being in stable would really hinder timely updates, I'd prefer vdirsyncer to
stay in testing/unstable forever.

On Fri, Jan 29, 2016 at 06:37:38PM +0100, Filip Pytloun wrote:
> I am pretty new to maintaining official Debian packages but if new
> release won't introduce some new dependencies (especially that are not
> packaged yet), creating new package version should be almost automatic.
> 
> Of course there's some unstable -> testing -> stable release process,
> but unfortunately I have no practical experience with this yet.
> 
> On 2016/01/29 18:31, Markus Unterwaditzer wrote:
> > A question: If I release an update of vdirsyncer the day after it is 
> > packaged for Debian, how long would it take to reach the repo? Which 
> > intermediate staging repos are there that would delay an immediate update 
> > of the package?
> > 
> > On 29 January 2016 17:05:18 CET, Filip Pytloun  wrote:
> > >Hello,
> > >
> > >I've almost finished packaging of vdirsyncer but it requires
> > >dependencies not currently in sid:
> > >python-click-log and python-atomicwrites
> > >
> > >It shouldn't be difficult to package these as well, but any help is
> > >welcome :-)
> > >
> > >Filip
> > 
> > -- 
> > Sent from my Android device with K-9 Mail. Please excuse my brevity.




signature.asc
Description: Digital signature

Bug#773287: openrc: Please enable SELinux support

[Laurent Bigonville]

On Tue, 16 Dec 2014 14:49:38 +0100 Laurent Bigonville  
wrote:


> Hello,

Hi again,

> Could it be possible to enable openrc selinux support?
>
> The attached patch should achieve this.

Please find here a new patch, it's also adding PAM and audit support

Cheers,

Laurent Bigonville
diff -Nru openrc-0.18.3/debian/changelog openrc-0.18.3/debian/changelog
--- openrc-0.18.3/debian/changelog	2015-11-09 15:11:35.0 +0100
+++ openrc-0.18.3/debian/changelog	2016-02-02 17:22:10.0 +0100
@@ -1,3 +1,11 @@
+openrc (0.18.3-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Enable SELinux, audit and PAM support on linux architectures (Closes:
+#773287)
+
+ -- Laurent Bigonville   Tue, 02 Feb 2016 17:21:55 +0100
+
 openrc (0.18.3-1) unstable; urgency=medium
 
   [ Dmitry Yu Okunev ]
diff -Nru openrc-0.18.3/debian/control openrc-0.18.3/debian/control
--- openrc-0.18.3/debian/control	2015-11-09 15:11:35.0 +0100
+++ openrc-0.18.3/debian/control	2016-02-02 18:04:48.0 +0100
@@ -5,7 +5,7 @@
 Uploaders: Roger Leigh ,
Thomas Goirand ,
Benda Xu 
-Build-Depends: debhelper (>= 9)
+Build-Depends: debhelper (>= 9), libselinux1-dev [linux-any], libaudit-dev [linux-any], libpam0g-dev [linux-any]
 Standards-Version: 3.9.6
 Homepage: http://www.gentoo.org/proj/en/base/openrc/
 Vcs-Git: git://anonscm.debian.org/openrc/openrc.git
@@ -17,6 +17,8 @@
 Replaces: sysv-rc
 Provides: sysv-rc
 Depends: insserv, ${misc:Depends}, ${shlibs:Depends}
+# newrole package is needed when using SELinux
+Suggests: newrole [linux-any]
 Description: dependency based init system (runlevel change mechanism)
  OpenRC is a dependency based init system. It provides support for System V
  init, for booting, changing runlevels, starting and stopping services, and
diff -Nru openrc-0.18.3/debian/rules openrc-0.18.3/debian/rules
--- openrc-0.18.3/debian/rules	2015-11-09 15:11:35.0 +0100
+++ openrc-0.18.3/debian/rules	2016-02-02 17:30:02.0 +0100
@@ -23,6 +23,12 @@
 export LIBEXECDIR = /lib/rc
 #export OS = Linux
 
+ifeq (linux,$(DEB_HOST_ARCH_OS))
+export MKAUDIT = yes
+export MKPAM = pam
+export MKSELINUX = yes
+endif
+
 %:
 	dh $@
 
@@ -52,6 +58,10 @@
 		rm -f $(CURDIR)/debian/openrc/sbin/$${file} ; \
 	done
 
+	# As openrc start-stop-daemon executable is removed above, we don't
+	# need to install that pam service.
+	rm -rf $(CURDIR)/debian/openrc/etc/pam.d/
+
 	# These need to be removed, the same way as other stuff above
 	for file in service.8 service.8.gz start-stop-daemon.8 start-stop-daemon.8.gz ; do \
 		rm -f $(CURDIR)/debian/openrc/usr/share/man/man8/$${file} ; \

Bug#812961: jessie-pu: package php-net-ldap2/2.0.12-1+deb8u1

[Julien Cristau]

Control: tag -1 = jessie confirmed

On Thu, Jan 28, 2016 at 11:13:23 +0700, Prach Pongpanich wrote:

> Package: release.debian.org
> Severity: normal
> Tags: jessie
> User: release.debian@packages.debian.org
> Usertags: pu
> 
> Hi,
>   
>   
>   
> Please accept the fixes for php5/5.6.17+dfsg-0+deb8u1 upgrade break 
> php-net-ldap2 in jessie (#812892).
> 
> Source debdiff attached.
> 
Go ahead.

Thanks,
Julien

Bug#813529: gdk-pixbuf: endless loop in pixops_process

[Marc Lehmann]

Source: gdk-pixbuf
Version: 2.32.3-1
Severity: normal

Dear Maintainer,

A (perl) script of mine that does a lot of image resizing with gdk-pixbuf
started to freeze a while ago. I tracked it down to gdk_pixbuf_scale never
returning. it happens rather randomly, but usually when a very large image
(thousands x thousands) is scaled to a small size (e.g. 16x16).

This almost certainly started after upgrading from some older version,
very likely from jessie.

The reason why I suspect it is gdk-pixbuf is that the script worked for
years without these freezes, and there is a correlation between upgrading
the pixbuf package.

A backtrace looks as follws:

(gdb) bt
#0  0x003a41216084 in pixops_process () from 
/usr/lib/x86_64-linux-gnu/libgdk_pixbuf-2.0.so.0
#1  0x003a41216be4 in _pixops_scale () from 
/usr/lib/x86_64-linux-gnu/libgdk_pixbuf-2.0.so.0
#2  0x003a4120e7b9 in gdk_pixbuf_scale () from 
/usr/lib/x86_64-linux-gnu/libgdk_pixbuf-2.0.so.0
#3  0x7fffee9cb045 in XS_Gtk2__Gdk__Pixbuf_scale () from 
/opt/perl/lib/perl5/auto/Gtk2/Gtk2.so
#4  0x0002 in ?? ()
#5  0x7fffee9cb00b in XS_Gtk2__Gdk__Pixbuf_scale () from 
/opt/perl/lib/perl5/auto/Gtk2/Gtk2.so
#6  0x in ?? ()

Using "fin" to get out of pixops_process never returns (even after
minutes), so it looks liked an endless loop in pixops_process.

I toyed around with it, and found it regularly reaches insn
0x003a41216099, but not insn 0x3a412160ac, and $ecx always contains
the same value (in the most recent case, -20504) at the jump just before
the latter insn.

A disassembly follows, for reference:

Dump of assembler code for function pixops_process:
   0x003a41215d40 <+0>: push   %r15
   0x003a41215d42 <+2>: push   %r14
   0x003a41215d44 <+4>: push   %r13
   0x003a41215d46 <+6>: push   %r12
   0x003a41215d48 <+8>: push   %rbp
   0x003a41215d49 <+9>: push   %rbx
   0x003a41215d4a <+10>:sub$0x108,%rsp
   0x003a41215d51 <+17>:mov0x140(%rsp),%eax
   0x003a41215d58 <+24>:mov%eax,0x24(%rsp)
   0x003a41215d5c <+28>:mov0x148(%rsp),%eax
   0x003a41215d63 <+35>:mov%eax,0x2c(%rsp)
   0x003a41215d67 <+39>:mov0x150(%rsp),%rax
   0x003a41215d6f <+47>:mov%rax,0x60(%rsp)
   0x003a41215d74 <+52>:mov0x158(%rsp),%eax
   0x003a41215d7b <+59>:mov%eax,0x28(%rsp)
   0x003a41215d7f <+63>:mov0x160(%rsp),%eax
   0x003a41215d86 <+70>:mov%eax,0x68(%rsp)
   0x003a41215d8a <+74>:mov0x168(%rsp),%eax
   0x003a41215d91 <+81>:mov%eax,0x98(%rsp)
   0x003a41215d98 <+88>:mov0x170(%rsp),%eax
   0x003a41215d9f <+95>:mov%eax,0x30(%rsp)
   0x003a41215da3 <+99>:mov0x178(%rsp),%eax
   0x003a41215daa <+106>:   mov%eax,0x34(%rsp)
   0x003a41215dae <+110>:   mov0x180(%rsp),%eax
   0x003a41215db5 <+117>:   mov%eax,0x6c(%rsp)
   0x003a41215db9 <+121>:   mov0x188(%rsp),%eax
   0x003a41215dc0 <+128>:   mov%eax,0xe8(%rsp)
   0x003a41215dc7 <+135>:   mov0x190(%rsp),%eax
   0x003a41215dce <+142>:   mov%eax,0x20(%rsp)
   0x003a41215dd2 <+146>:   mov0x198(%rsp),%eax
   0x003a41215dd9 <+153>:   mov%eax,0x90(%rsp)
   0x003a41215de0 <+160>:   mov0x1a0(%rsp),%eax
   0x003a41215de7 <+167>:   mov%eax,0x94(%rsp)
   0x003a41215dee <+174>:   movsd  0x625a(%rip),%xmm2# 0x3a4121c050
   0x003a41215df6 <+182>:   mov0x1b0(%rsp),%rax
   0x003a41215dfe <+190>:   mov0x1a8(%rsp),%rbp
   0x003a41215e06 <+198>:   movapd %xmm2,%xmm5
   0x003a41215e0a <+202>:   movsd  %xmm2,(%rsp)
   0x003a41215e0f <+207>:   divsd  %xmm0,%xmm5
   0x003a41215e13 <+211>:   movapd %xmm2,%xmm0
   0x003a41215e17 <+215>:   mov%rax,0xf0(%rsp)
   0x003a41215e1f <+223>:   mov0x1b8(%rsp),%rax
   0x003a41215e27 <+231>:   mov%rax,0x40(%rsp)
   0x003a41215e2c <+236>:   divsd  %xmm1,%xmm0
   0x003a41215e30 <+240>:   cvttsd2si %xmm5,%rax
   0x003a41215e35 <+245>:   test   %rax,%rax
   0x003a41215e38 <+248>:   mov%rax,0x10(%rsp)
   0x003a41215e3d <+253>:   cvttsd2si %xmm0,%rbx
   0x003a41215e42 <+258>:   mov%rbx,0x70(%rsp)
   0x003a41215e47 <+263>:   je 0x3a41216660 
   0x003a41215e4d <+269>:   test   %rbx,%rbx
   0x003a41215e50 <+272>:   je 0x3a41216660 
   0x003a41215e56 <+278>:   mov0x0(%rbp),%ebx
   0x003a41215e59 <+281>:   mov0x18(%rbp),%eax
   0x003a41215e5c <+284>:   cmp$0x7f,%ebx
   0x003a41215e62 <+290>:   mov%eax,%r15d
   0x003a41215e65 <+293>:   mov%eax,0x18(%rsp)
   0x003a41215e69 <+297>:   jg 0x3a41216660 
   0x003a41215e6f <+303>:   mov$0x7fff,%eax
   0x003a41215e74 <+308>:   mov%ebx,%r11d
   0x003a41215e77 <+311>:   mov

Bug#813019: transition: nfft 3.3

[Emilio Pozuelo Monfort]

Control: tags -1 confirmed

On 02/02/16 19:08, Ghislain Vaillant wrote:
> On 02/02/16 18:00, Emilio Pozuelo Monfort wrote:
>> Hi,
>>
>> On 28/01/16 15:47, Ghislain Antony Vaillant wrote:
>>> Package: release.debian.org
>>> Severity: normal
>>> User: release.debian@packages.debian.org
>>> Usertags: transition
>>>
>>> Dear Release Team,
>>>
>>> I would like to request a transition for the latest version of nfft from
>>> experimental to unstable.
>>>
>>> Some API breaking changes were introduced from in version 3.3.0 and current
>>> rdeps of nfft will require appropriate patching. The following bugs have 
>>> been
>>> filed with severity important:
>>>
>>>* pynfft: #812997
>>>* yorick-ynfft: #812995
>>>
>>> Let me know if further action is required on my end. I intend to fix pynfft,
>>> since I am the personal maintainer and upstream author of the package.
>>
>> Are there patches for yorick-ynfft, or what's the plan for that?
>>
>> Cheers,
>> Emilio
> 
> I did try to implement a fix for yorick-nfft based on my knowledge of
> the API changes in nfft, but its test suite still fails for some reason.
> I won't have time to investigate further, so it would be up to the
> maintainer of yorick-nfft to finish the job. I believe he is also the
> upstream developer.

Maybe you could send your (incomplete) patch to the bug then?

> Regarding pynfft, I am currently working on a different implementation
> using cffi instead of Cython and could end-up dropping support of the
> package both upstream and downstream altogether, once the new
> implementation is out. I am happy to provide a patch for the current
> pynfft package present in the archive if that can help.

Since there are no collisions with other transitions, I guess you can go ahead.

Cheers,
Emilio

Bug#798949: jessie-pu: package ruby-tzinfo/1.1.0-2

[Adam D. Barratt]

Control: tags -1 + pending

On Mon, 2016-02-01 at 12:17 +0300, Hleb Valoshka wrote:
> On 9/14/15, Adam D. Barratt  wrote:
> 
> > Thanks. Please feel free to upload.
> 
> The fixed package ruby-tzinfo was uploaded at last to jessie-pu.

Flagged for acceptance.

Regards,

Adam

Bug#812990: jessie-pu: package gummi/0.6.5-3+deb8u1

[Adam D. Barratt]

Control: tags -1 + pending

On Sun, 2016-01-31 at 19:36 +0100, Daniel Stender wrote:
> In: gummi_0.6.5-3+deb8u2_amd64.changes ACCEPTED into 
> proposed-updates->stable-new

Flagged for acceptance.

Regards,

Adam

Bug#812990: jessie-pu: package gummi/0.6.5-3+deb8u1

[Daniel Stender]

On 02.02.2016 21:23, Adam D. Barratt wrote:
> Control: tags -1 + pending
> 
> On Sun, 2016-01-31 at 19:36 +0100, Daniel Stender wrote:
>> In: gummi_0.6.5-3+deb8u2_amd64.changes ACCEPTED into 
>> proposed-updates->stable-new
> 
> Flagged for acceptance.
> 
> Regards,
> 
> Adam

Thanks.

Best,
Dan

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

Bug#811392: foolscap problem

[Julian Taylor]

reassign 811392 foolscap 0.10.1-1
thanks

This is a problem in foolscap packaging, caused by a change in twisted
packaging. It will get fixed today.

It can be worked around by replacing the twisted-* dependencies with
just twisted in
/usr/lib/python2.7/dist-packages/foolscap-0.10.1.egg-info/requires.txt

Bug#813528: alsa-utils-1.1.0-1: Overwrite files from unrelated package

[Michael Rasmussen]

Package: alsa-utils-1.1.0-1
Severity: critical
Justification: breaks unrelated software

Dear Maintainer,

dpkg: error processing archive 
/var/cache/apt/archives/alsa-utils_1.1.0-1_amd64.deb (--unpack):
 trying to overwrite '/usr/share/man/man1/bat.1.gz', which is also in package 
bareos-bat 14.2.6-2+b1


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

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



This mail was virus scanned and spam checked before delivery.
This mail is also DKIM signed. See header dkim-signature.

Bug#775651: systemd: /run/user/$UID directories are created with type tmpfs_t on SE Linux

[Michael Biebl]

Am 02.02.2016 um 18:21 schrieb Laurent Bigonville:
> After some discussion on #selinux@freenode and some testing, it seems
> that there is still an issue here.
> 
> Somebody on the channel made a patch, I hope it will be upstreamed.

A patch for systemd? Is this tracked somewhere?

-- 
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#759324: dbd-oracle

[Alex Muntada]

Christoph Martin:

> If you need any help with building or uploading dbd-oracle, I can help.
> I have Oracle Installations and I am a Debian developper and can do uploads.

I just need to make a few small changes and will be ready to
upload the amd64 build.

Thanks for your offer, I will keep it in mind :)

Cheers!
Alex



signature.asc
Description: Digital signature

Bug#807969: jessie-pu: package clamav/0.99+dfsg-0+deb8u1

[Adam D. Barratt]

Control: tags -1 -moreinfo +confirmed

On Mon, 2015-12-28 at 23:12 +0100, Sebastian Andrzej Siewior wrote:
> On 2015-12-28 16:57:27 [+], Adam D. Barratt wrote:
> > I have bad memories of the last time we had a libclamav SONAME change in
> > stable - more precisely, in volatile. When you say you've rebuilt the
> > packages, I assume that this means that no source changes were needed? Have
> 
> correct, no source changes except for libclamunrar.

Okay, thanks. Let's get this rolling; apologies for the delay in getting
back to you.

> > you performed any testing (either installation/upgrade or functional)
> > testing on the resulting packages?
> 
> havp seems to work (installed old, dpkg -i new package, loaded a page
> and the eicar test signature which got blocked as expected). dansguardian
> (just installed the new package, used behind havp) seems to serve content,
> too.
> I did no test the other packages (but this can change on your request).

Any testing we could get before looking at releasing the packages to the
masses via -updates would be appreciated.

Regards,

Adam

Bug#813237: transition: ruby2.3

[Emilio Pozuelo Monfort]

On 30/01/16 19:18, Antonio Terceiro wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> 
> Hi,
> 
> We want to ship ruby2.3 in stretch, so we must start the transition now.
> The Ruby transitions are done in phases, as described in
> 
> https://wiki.debian.org/Teams/Ruby/InterpreterTransitions
> 
> We are now in phase 1: I have just uploaded ruby-defaults enabling
> builds against ruby2.3 (besides ruby2.2) to experimental, and we will
> start test rebuilds ASAP. I am filing this bug now to keep this
> transition under the radar of both the Release and Ruby teams.
> 
> Ben file:
> 
> title = "ruby2.3";
> is_affected = .depends ~ "libruby2.2" | .depends ~ "libruby2.3";
> is_good = .depends ~ "libruby2.3";
> is_bad = ! .depends ~ "libruby2.3";
> 
> Note about the ben file statements above: at this stage, packages will
> gain ruby2.3 support but won't lose support for ruby2.2, so "bad"
> packages are indeed just the ones that don't have ruby2.3 support yet.
> 
> I will let you know when we are ready to begin rebuilds on unstable, but
> before even uploading ruby-defaults enabling ruby2.3 builds there.

OK.

I have created a tracker for you at:

https://release.debian.org/transitions/html/ruby2.3.html

Cheers,
Emilio

Bug#780530: [calendarserver]

[Ximin Luo]

On 29/01/16 08:42, Rahul Amaram wrote:
> On Friday 29 January 2016 05:34 AM, Ximin Luo wrote:
>> Hey just a quick reply for this (I will answer the other things later) - no 
>> I don't need to wait, I just had other stuff to do in the meantime. :) I 
>> will upload your packages soon, hopefully this weekend when I get some free 
>> time at FOSDEM. X 
> 
> Thanks. The good news is we now have all the issues sorted out. Upgrade 
> directly from 3.x works (yipee!) and I have identified the cause of the tasks 
> not being enabled. I had accidentally removed a config option which gets 
> distributed by default with the package config file. So, in your case, 
> post-upgrade the tasks should work. Could you check on this? Here are the 
> final actions items:
> 

Great! It will take me a while to test tasks as I was not using them myself, 
but I'll try to find some time for it soon.

> i. Get python-xattr version bumped to 0.7.5. Already raised a ticket for this 
> - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=813075.
> 
> ii. [fixed]
> 
> iii. If possible try to get rid of these two errors in log files (these do 
> not seem to be blocking functionality as of now).
> 
> 2016-01-29 12:44:18+0530 [-] [twext.enterprise.jobs.queue#error] workCheck: 
> jobqueue is no longer overloaded
> 
> 2016-01-29 12:37:11+0530 [-] [caldav-1] [PooledMemCacheProtocol,client] 
> [twistedcaldav.memcachepool.MemCachePool#error] Memcache error: Invalid type 
> for key: , expecting a string; request: set 
> cacheToken:/calendars/__uids__/F343A113-0C2B-5A69-B049-A4C72FCAEF9B/ 
> 40aed427-a35f-41dd-9f79-fefc56ff8006
> 

I think the first one actually isn't an error, and I did try for a bit myself 
to figure out the second problem, but I gave up because it seemed not too 
important. If we don't figure it out before the remaining issues are sorted, 
I'm happy to upload, and just file another open bug for it (and keep poking 
upstream...)

> 
> iv. Upload new packages twextpy and pg8000
> 

I've just uploaded these. I fixed a few minor things before uploading, please 
check git and review them. In general, I run "lintian -i -I --pedantic --color 
auto xxx.changes" to catch things like that, and it's a good habit to get into.

As part of the fix to (k) earlier, I pushed another patch to a side branch of 
calendarserver: [1]. You haven't applied it to debian/sid yet, but I think it 
may be necessary. To test, you should try to add/remove events with non-ascii 
unicode characters in them such as "ßßß". If it fails, then try the patch and 
if it works please add it to git as well.

X

[1] 
https://anonscm.debian.org/cgit/calendarserver/calendarserver.git/diff/debian/patches/unicode-fixes.patch?h=debian/_wip_sid=4476a73ff4df39baa297606e00e66241f371178c

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
git://github.com/infinity0/pubkeys.git

Bug#812488: libsms-send-perl: After upgrade: Can't send SMS: 500 Can't connect to api.twilio.com:443 (certificate verify failed)

[Michael Shuler]

On 02/02/2016 02:22 PM, Tim Small wrote:

#813468 is similar but impacting a different application.  I did come
across a patch which backports the fix included in newer versions of the
upstream OpenSSL 1.0.1 branch, to the 1.0.1k derived package in Jessie.

I haven't reviewed or tested the fix tho':

https://gist.github.com/h-yamamo/adf44638a1a04b8e86ea


Thanks for the additional info and openssl ticket number. I'm open to 
including the 1024-bit certificates mozilla removed and started a 
branch, but haven't completed this. I don't have the openssl expertise 
to review the patch, but it is interesting and could be a better way to 
handle the problem, but also it seems a new patch to openssl in stable 
could be more invasive.


--
Michael

Bug#812488: libsms-send-perl: After upgrade: Can't send SMS: 500 Can't connect to api.twilio.com:443 (certificate verify failed)

[Tim Small]

Package: ca-certificates
Followup-For: Bug #812488

#813468 is similar but impacting a different application.  I did come
across a patch which backports the fix included in newer versions of the
upstream OpenSSL 1.0.1 branch, to the 1.0.1k derived package in Jessie.

I haven't reviewed or tested the fix tho':

https://gist.github.com/h-yamamo/adf44638a1a04b8e86ea

Tim.

Bug#813239: [acorn] Some sources are not included in your package

[Sebastiaan Couwenberg]

On Sat, 30 Jan 2016 20:03:38 +0100 Bastien ROUCARIÈS wrote:
> In order to solve this problem, you could:
> 1.  add the source files to "debian/missing-sources" directory.
> 2. repack the origin tarball and add the missing source files to it.

Option 3. Remove acorn from the archive because adoption is not going to
happen any time soon.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Bug#813468: boinc-client: Some https connections fail due to Debian Jessie openssl and ca-certificate interactions

[Tim Small]

Package: openssl
Version: 1.0.1k-3+deb8u2
Followup-For: Bug #813468

> On Tue, Feb 02, 2016 at 19:14:24 +0100, Kurt Roeckx wrote:
> > On Tue, Feb 02, 2016 at 03:04:41PM +0100, Christian Beer wrote:
> > Since it works in openssl 1.0.2 you can either upgrade the package in
> > Jessie to 1.0.2 (which is unlikely I think) or backport the fix for
> > 1.0.2 to 1.0.1 upstream (which is even more unlikely).

> This has already been fixed in the upstream 1.0.1 release of a
> year ago.

I reference a patch above which backports the code from 1.0.1p to to
the openssl version in Jessie.

https://gist.github.com/h-yamamo/adf44638a1a04b8e86ea

... although I haven't tested or reviewed it, (the code does at least
come from the same upstream OpenSSL release series).

It would seem that the best fix would be to pull this upstream code
into an upcoming Jessie point release, because as this gives the least
surprising / least broken behaviour, and is in-line the the behaviour of
most (all?) modern SSL/TLS implementations.  

Rolling back the changes in ca-certificates would be a second best, but
this will be somewhat detrimental to security (although breaking 1024
bit RSA is believed to be hard at the time of writing, there is of
source, no guarentee that it will continue to be considered hard next
week/month/year).

> On Tue, Feb 02, 2016 at 03:04:41PM +0100, Christian Beer wrote:
> I will also reference the workaround we advise to "downgrade" the
> ca-certificates package:
> https://einstein.phys.uwm.edu/forum_thread.php?id=11760=151305

I think this is the worst solution from a security point of view, as it
would prevent systems from revoking known-compromised CA certificates,
should any become known (this has happened multiple times in the past)
and be rolled out in future Debian security updates.

It is also a system-wide change impacting the security of many other
pieces of software (including ones which aren't impacted by the openssl
bug, because they use different certificate chain verification code),
so until Debian has a fix for this, I think I'd prefer to advise
per-application workarounds, such as the one reference in the original
report.

Tim.

Bug#813493: cloud.debian.org: [AWS] Debian Jessie 8.1 images lack root partition grow

[Tiago Ilieve]

Zied,

On 2 February 2016 at 18:42, Zied ABID  wrote:
> Hi Tiago,
>
> Thank you for this useful informations.

You're welcome.

> I'll try to contact James Bromberger as he is mentioned as the AWS images
> maintainer at [6].

Worth mentioning that he follows the "debian-cloud" mailing list,
which those bug reports are forwarded to. So he will probably see our
messages and answer when the time permits.

-- 
Tiago "Myhro" Ilieve
Blog: https://blog.myhro.info/
GitHub: https://github.com/myhro
LinkedIn: https://br.linkedin.com/in/myhro
Montes Claros - MG, Brasil

Bug#813534: siproxd: WARNING:couldn't create new PID file: No such file or directory

[Geert Stappers]

Control: tag -1 moreinfo
stop

thanks for reporting


On Tue, Feb 02, 2016 at 10:09:37PM +0100, Richard van den Berg wrote:
> Package: siproxd
> Version: 1:0.8.1-4+b1
> Severity: normal
> Tags: patch

'patch' as "unified patch, output of `diff -u`"?   (I didn't see it attached)

> When running siproxd out of the box I got this in /var/log/messages:
> 
> Feb  2 21:54:48 majoron siproxd[20351]: utils.c:635 WARNING:couldn't create 
> new PID file: No such file or directory
> 
> Creating /var/lib/siproxd/var/run/siproxd owned by siproxd:siproxd fixed the 
> warning.

And that is a directory what is created?

> -- Configuration Files:
> /etc/default/siproxd changed [not included]
> /etc/siproxd.conf changed [not included]

Please send the outpot of

  grep run /etc/default/siproxd /etc/siproxd.conf



Groeten
Geert Stappers
-- 
Leven en laten leven

Bug#813530: dconf-editor: UTF8 characters are not rendered correctly

[Evangelos Skarmoutsos]

Package: dconf-editor
Version: 3.18.2-1
Severity: normal

Dear Maintainer,

When looking the last-save-directory key at org.gnome.gnome-screenshot
the non English characters was represented as percent-encoded URI (like
%CE%95%CE%B9%CE%BA%CF%8C...)

While RFC3986 permits percent-encoded URIs, a user can not understand the name
of the directory.

Key values including non Latin characters, should be shown in a human readable
way.


Reference:
RFC3986 (http://www.faqs.org/rfcs/rfc3986.html)
"1.2.1. Transcription
...
Percent-encoded octets (Section 2.1) may be used within a URI..."



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

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

Versions of packages dconf-editor depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.24.0-2
ii  libc62.21-7
ii  libdconf10.24.0-2
ii  libglib2.0-0 2.46.2-3
ii  libgtk-3-0   3.18.6-1
ii  libpango-1.0-0   1.38.1-1
ii  libxml2  2.9.3+dfsg1-1

dconf-editor recommends no packages.

dconf-editor suggests no packages.

-- no debconf information

Bug#791560: RFP: python-pysal -- library of spatial analysis functions

[Daniel Stender]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

cf. https://bugs.debian.org/788576 (ITP: pysal -- Python Spatial Analysis 
Library)

DS

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

iQIcBAEBCgAGBQJWsRbgAAoJEBXgmvTfUYLIrBsP/0pez4oGBgrYVqcIi2wptJ2+
wGBlU+TH1HLXx/5jgUFcoV1fGzLXwXGJzPtxys9T31KNQfFsseXc5eeiBDFc1891
BrdS7Be0NNxLwKlW31nEEEmKsQS7j6/Ids1dgX2h+HHZRIpUq50fkIhgsswq435s
8z8fZ52NZQLoj6VJNTL+GDIkZ2Hiv7N3LF1kKeUF6DICyK5msLUvmpNskVnpPvWI
CrAIBTOlDpO+ulwbaS9Pd9YF1yvSP0GS1TWBfSL4qK1wgefgG08mWvziDbmScNac
NZ9Ue+3aX8FuCI9oksTOgQzUjJkMEHH7iy6fKcRnj3A+tQ/pfDzw54izpMOxuQjJ
7JB61ABTstJPHXuafd0oqC7WlDFBcg+RNPbbV2nh38RICfuTQwZvAJeS2AtePBdK
krXq6DN0hzlK/rcD1OY6n7DlzBEnGv9UztB6l7qhxq1K7AMyQy9LtmvPzd0OjT6v
LKr8AG4SZkW8ZtARMfaf8FLBrGxgAiwJrMQqlY4GxXXk2nW9dL6M7olnc+NK/ubw
MOxngZUDZgqhb8DYExy5XgrAdDBJftfTJghV0t+I4nRBq2EWTTZyf8Jld84FQInH
ArcW7pBO/KjHr64UupOQczHbZS5+6Xe3e9bleNgjfPc7Mt3+LJsU+hRWRA4+RziK
CPNd5s3RUVurbMFVK7hF
=ZVUK
-END PGP SIGNATURE-

Bug#813532: transition: libjsoncpp

[Peter Spiess-Knafl]

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

I would like to start the transition for libjsoncpp.

Its been on experimental for quite a while now, until I could test all the
rdepends.

The following rdepends have been successfully tested:

cmake
bamtools
dcmtkpp
kodi-pvr-argustv
lgogdownloader
libjson-rpc-cpp
llvm-toolchain-3.7
minetest
orthanc
paraview
springlobby
sysdig
vtk6

The following rdepends have a FTBFS problem:

ginkgocadx - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=805170

Ben file:

title = "libjsoncpp";
is_affected = .depends ~ "libjsoncpp0v5" | .depends ~ "libjsoncpp1";
is_good = .depends ~ "libjsoncpp1";
is_bad = .depends ~ "libjsoncpp0v5";



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

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

Bug#813531: RM: acorn -- ROM; Unmaintained and RC-buggy

[Bas Couwenberg]

Package: ftp.debian.org
Severity: normal

Please remove acorn from the archive.

It is RC-buggy, and the maintainer is no longer interested in the package.

Kind Regards,

Bas

Bug#813493: cloud.debian.org: [AWS] Debian Jessie 8.1 images lack root partition grow

[Zied ABID]

Hi Tiago,

Thank you for this useful informations.
I'll try to contact James Bromberger as he is mentioned as the AWS 
images maintainer at [6].



Best regards,
Zied.

[6]https://wiki.debian.org/Teams/Cloud


Le 2016-02-02 18:38, Tiago Ilieve a écrit :

Hi Zied,

On 2 February 2016 at 12:03, Zied ABID  wrote:

Package: cloud.debian.org
Severity: normal
Tags: newcomer

Dear Maintainer,


   * What led up to the situation?
Create new instance from one of the official Debian Jessie 8.1 
images

(https://wiki.debian.org/Cloud/AmazonEC2Image/Jessie)
   * What exactly did you do (or not do) that was effective (or 
ineffective)?
Create instance with a volume other than the default size (8GB), 
say 30GB.

   * What was the outcome of this action?
Root partition still at size 8GB in front of 30GB (EBS) volume 
size.

   * What outcome did you expect instead?
Root partition should be resized as same as (EBS) volume.


This bug is reproducible in at least 2 tested images (in eu-west-1 and
us-west-1)
This bug affect only Jessie 8.1 images, Wheezy images looks fine.

As a work-around, installing cloud-initramfs-growroot package resolve 
the issue
for installed instances (after reboot) or for new instances created 
from nested

image.


This is a known issue, which is related to #784004[1]. We are already
tackling it on threads[2][3] at the "debian-cloud" mailing list.

PS: If you consider this issue as a bug, I'm available to reproduce, 
test and
validate new AWS images. I'm already looking at Anders Ingemann's 
bootstrap-vz
work to find-out how to suggest a patch, but I'm not sure that I'm on 
the right

path.


Patches[4][5] were suggested to bootstrap-vz and the most recent one
was merged. What happened is, AFAICT, there were no newer EC2 images
generate using those fixes.

Regards,
Tiago.

[1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=784004
[2]: https://lists.debian.org/debian-cloud/2016/01/msg00035.html
[3]: https://lists.debian.org/debian-cloud/2016/01/msg00056.html
[4]: https://github.com/andsens/bootstrap-vz/pull/239
[5]: https://github.com/andsens/bootstrap-vz/pull/269

Bug#810748: systemd does not mount /usr in initramfs, breaking split /usr

[Michael Biebl]

Hi Nis

On Tue, 19 Jan 2016 22:52:57 +0100 Nis Martensen 
wrote:
> Control: found -1 228-4
> 
> Attached a version of the patch that should work for testing/unstable.
> Again intended as a replacement for the existing patch.

I've looked a bit closer at your patch, and it looks fine.
Not generating the systemd-fsck@ instance when the flag file exists,
looks like a proper solution to this issue.

I gave the patch a quick test and it seems to work with both dracut and
initramfs-tools. There are still some (new) issues with a separate /usr
[1], but that happens with both initramfs-tools and dracut.

So I think the patch can go in as is.

Regarding the flag files dracut generates for non-systemd mode:
Could you please file a bug report so it uses
/run/initramfs/fsck-root for /
and
/run/initramfs/fsck-usr for /usr

I expect most users will use the systemd-enabled dracut initramfs, but
it still seems worthwile fixing that.

Thanks,
Michael



[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=808151
-- 
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#813534: siproxd: WARNING:couldn't create new PID file: No such file or directory

[Richard van den Berg]

Package: siproxd
Version: 1:0.8.1-4+b1
Severity: normal
Tags: patch

When running siproxd out of the box I got this in /var/log/messages:

Feb  2 21:54:48 majoron siproxd[20351]: utils.c:635 WARNING:couldn't create new 
PID file: No such file or directory

Creating /var/lib/siproxd/var/run/siproxd owned by siproxd:siproxd fixed the
warning.

-- System Information:
Debian Release: 8.3
  APT prefers stable
  APT policy: (990, 'stable'), (400, 'testing'), (300, 'unstable')
Architecture: amd64 (x86_64)

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

Versions of packages siproxd depends on:
ii  adduser  3.113+nmu3
ii  libc62.19-18+deb8u2
ii  libltdl7 2.4.2-1.11
ii  libosip2-11  4.1.0-2

siproxd recommends no packages.

siproxd suggests no packages.

-- Configuration Files:
/etc/default/siproxd changed [not included]
/etc/siproxd.conf changed [not included]

-- no debconf information

Bug#813537: [Pkg-privacy-maintainers] Bug#813537: tails-installer: tails installer fails with extlinux error

[intrigeri]

Control: tag -1 + moreinfo

Hi Stefani,

> In attempting to run tails installer an error message about missing extlinux 
> was encountered.
> It is true that this package was not installed on the system.

Thanks for reporting this to us.

Did you see this message on stdout, or in the GUI?

If the latter, how exactly did you start Tails Installer?

> I did not find a "depends" of extlinux package in the "control" file.
> Perhaps extlinux should be required?

Actually, it's totally unused IIRC. We could indeed drop the now
useless code and warning.

Cheers!

Bug#793036: sparkleshare: Sparkleshare status icon no longer visible in default Gnome DE after upgrading from wheezy to jessie

[James Cook]

Update:

After a full six months of using Gnome on Debian, I have discovered that if
I move the mouse to the bottom of the screen, and then attempt to move the
mouse down further, the status bar does appear, and I can see the
SparkleShare status.

So, this isn't a problem with SparkleShare, it's just (in my opinion)
terrible discoverability of the Gnome status bar.

James

On 20 July 2015 at 10:35, James Cook  wrote:

> Package: sparkleshare
> Version: 1.2-0.1
> Severity: important
>
> Dear Maintainer,
>
> After upgrading to jessie, I no longer see the Sparkleshare icon.  I
> depend on
> it to tell me whether my repository has been synced.  Sparkleshare is still
> successfully running and syncing in the background, though.
>
> I'm using the default Gnome desktop environment.
>
> In case it helps, below is what appears in a terminal window if I run
> "sparkleshare restart", wait a few seconds, then "sparkleshare stop".
>
> Thanks,
>   James
>
> 
>
> james copter ~ $ sparkleshare restart
> Stopping SparkleShare... Done.
> Starting SparkleShare... Done.
> james copter ~ $ 10:28:31 | Environment | SparkleShare version: 1.2.0,
> Operating system: Unix (Unix 3.16.0.4)
> 10:28:32 | Auth | Imported key
> '/home/james/.config/sparkleshare/sparkleshare.james.c...@utoronto.ca.key'
> 10:28:32 | Auth | The following keys may be used:
> 2048 17:c8:77:9b:0c:e6:e4:7a:e6:df:af:46:cb:33:f0:97 rsa w/o comment (RSA)
> 2048 88:72:48:82:48:98:fb:8c:5a:9e:a0:a3:ce:dd:00:4c james@copter (RSA)
> java version "1.7.0_79"
> OpenJDK Runtime Environment (IcedTea 2.5.5) (7u79-2.5.5-1~deb8u1)
> OpenJDK 64-Bit Server VM (build 24.79-b02, mixed mode)
> 10:28:32 | /home/james/big/SparkleShare/big | Initializing...
> 10:28:32 | Cmd | big | git log --since=1.month --raw --find-renames
> --date=iso
> --format=medium --no-color --no-merges
> 10:28:32 | Cmd | big | git log -n 75 --raw --find-renames --date=iso
> --format=medium --no-color --no-merges
> 10:28:32 | Cmd | big | git config core.ignorecase false
> 10:28:32 | ListenerFactory | Issued new listener for
> tcp://notifications.sparkleshare.org:443/
> 10:28:32 | Cmd | big | git config --get filter.bin.clean
> 10:28:32 | Cmd | big | git config remote.origin.url "ssh://james-pri@sylph
> /home
> /james-pri/sparkle/big"
> 10:28:32 | /home/james/big/SparkleShare/pri | Initializing...
> 10:28:32 | Cmd | pri | git log --since=1.month --raw --find-renames
> --date=iso
> --format=medium --no-color --no-merges
> 10:28:32 | Git | big | Checking for remote changes...
> 10:28:32 | Cmd | big | git rev-parse HEAD
> 10:28:32 | Cmd | big | git config core.ignorecase true
> 10:28:32 | Cmd | big | git config core.ignorecase false
> 10:28:32 | Cmd | big | git rev-parse --abbrev-ref HEAD
> 10:28:32 | Cmd | big | git ls-remote --heads --exit-code "ssh://james-
> pri@sylph/home/james-pri/sparkle/big" master
> 10:28:32 | Cmd | pri | git config core.ignorecase false
> 10:28:32 | ListenerFactory | Refered to existing listener for
> tcp://notifications.sparkleshare.org:443/
> 10:28:32 | Cmd | pri | git config --get filter.bin.clean
> 10:28:32 | Cmd | pri | git config remote.origin.url "ssh://james-pri@sylph
> /home
> /james-pri/sparkle/pri"
> 10:28:32 | Git | pri | Checking for remote changes...
> 10:28:32 | Cmd | pri | git rev-parse HEAD
> 10:28:32 | Cmd | pri | git config core.ignorecase true
> 10:28:32 | Cmd | pri | git config core.ignorecase false
> 10:28:32 | Cmd | pri | git rev-parse --abbrev-ref HEAD
> 10:28:32 | Cmd | pri | git ls-remote --heads --exit-code "ssh://james-
> pri@sylph/home/james-pri/sparkle/pri" master
> 10:28:33 | Avatars | Invalid certificate for https://www.gravatar.com/
> 10:28:33 | Avatars | Error fetching avatar for james.c...@utoronto.ca:
> Error
> getting response stream (Write: The authentication or decryption has
> failed.):
> SendFailure   at System.Net.HttpWebRequest.EndGetResponse (IAsyncResult
> asyncResult) [0x0] in :0
>   at System.Net.HttpWebRequest.GetResponse () [0x0] in  unknown>:0
>   at System.Net.WebClient.GetWebResponse (System.Net.WebRequest request)
> [0x0] in :0
>   at System.Net.WebClient.ReadAll (System.Net.WebRequest request,
> System.Object
> userToken) [0x0] in :0
>   at System.Net.WebClient.DownloadDataCore (System.Uri address,
> System.Object
> userToken) [0x0] in :0
> 10:28:33 | Git | big | No remote changes, local+remote:
> 227581fcc9709094dfbf59aa6abf31cb1ca9bd6a
> 10:28:33 | Cmd | big | git status --porcelain
> 10:28:33 | Git | pri | No remote changes, local+remote:
> b5945fe5a6eaf02fe471311947498ae982068752
> 10:28:33 | Cmd | pri | git status --porcelain
> sparkleshare stop
> Stopping SparkleShare... Done.
> james copter ~ $
>
>
>
> -- System Information:
> Debian Release: 8.1
>   APT prefers stable
>   APT policy: (500, 'stable')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 

Bug#813539: tails-installer: tails installer fails to sense usb stick

[Stefani Banerian]

Package: tails-installer
Version: 4.4.6+dfsg-1~bpo8+1
Severity: normal

Dear Maintainer,

in trying to use the gui, the usb stick was never displayed.

I did run the installer from command line:
/usr/lib/tails-installer/tails-installer  -v -f /dev/sdb 

** (tails-installer:26025): WARNING **: Couldn't connect to accessibility bus: 
Failed to connect to socket /tmp/dbus-6iecs4mxTn: Connection refused
[creator.py:689 (detect_supported_drives)] DEBUG: {}

the usb stick is seen by the kernel:
Bus 006 Device 007: ID 0951:1607 Kingston Technology DataTraveler 100

and it had a test partition:

parted /dev/sdb print 
Model: Kingston DataTraveler 2.0 (scsi)
Disk /dev/sdb: 4010MB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags: 

Number  Start   End SizeType File system  Flags
 1  1049kB  4010MB  4009MB  primary  ext2


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

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

Versions of packages tails-installer depends on:
ii  gdisk  0.8.10-2
ii  genisoimage9:1.1.11-3
ii  gir1.2-glib-2.01.42.0-2.2
ii  gir1.2-gtk-3.0 3.14.5-1+deb8u1
ii  gir1.2-udisks-2.0  2.1.3-5
ii  mtools 4.0.18-2
ii  p7zip-full 9.20.1~dfsg.1-4.1+deb8u1
ii  policykit-10.105-8
ii  python 2.7.9-1
ii  python-configobj   5.0.6-1
ii  python-gi  3.14.0-1
ii  python-urlgrabber  3.9.1-4.1
ii  syslinux   3:6.03+dfsg-5+deb8u1

tails-installer recommends no packages.

tails-installer suggests no packages.

-- no debconf information

Bug#788062: os-prober corrupts LVs/partitions while being mounted inside a VM

[Dominik George]

Hi,

> update-grub on a vhost running qemu/kvm virtual machines
> while grub and os-prober is installed on the host might corrupt
> guest virtual machines / guest disks.

confirmed. This just tore Teckids' main infrastructure into pieces.

-nik

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

Dominik George · Mobil: +49-151-61623918

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)

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

Bug#813536: socat: Socat security advisory 7: Bad DH p paramenter in OpenSSL

[Salvatore Bonaccorso]

Source: socat
Version: 1.7.3.0-1
Severity: important
Tags: security upstream fixed-upstream

Hi

See http://www.dest-unreach.org/socat/contrib/socat-secadv7.html for
details.

Regards,
Salvatore

Bug#813471: network access to the loopback device should be allowed

[Guillem Jover]

Hi!

On Tue, 2016-02-02 at 20:46:03 +0900, Osamu Aoki wrote:
> Package: debian-policy
> Severity: normal
> 
> Bug #770016 "Clarify network access for building packages in main"
> was about not downloading files via network.  This created new lines in
> 4.9 as:
> 
> | For packages in the main archive, no required targets may attempt
> | network access.
> 
> This is too restrictive.
> 
> The build target of devscripts has several tests testing http acess to
> the http server on the loopback device.
> 
> But the above new policy lines may be considered to prohibit this.
> 
> I thought the this should be more like:
> 
> | For packages in the main archive, no required targets may attempt
> | network access except for the access to the loopback device.

> I understand downloading from Debian or non-Debian web site is bad for
> buildd but network operation to the loopback device (like http access)
> should be OK.

This is probably too restrictive too. It would not allow local access
through TAP device or other similar things. It might be better to just
say something like:

| For packages in the main archive, no required targets may attempt
| network access outside the current machine.

or something along those lines.

Thanks,
Guillem

Bug#813535: socat: Socat security advisory 8: stack overflow vulnerability in parser

[Salvatore Bonaccorso]

Source: socat
Version: 1.7.1.3-1
Severity: important
Tags: security upstream fixed-upstream

Hi

See: http://www.dest-unreach.org/socat/contrib/socat-secadv8.html for
details.

Regards,
Salvatore

Bug#813542: transition: nvidia-cuda-toolkit

[Emilio Pozuelo Monfort]

Control: tags -1 confirmed

On 02/02/16 23:58, Andreas Beckmann wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> Forwarded: 
> https://release.debian.org/transitions/html/auto-nvidia-cuda-toolkit.html
> 
> I'd like to move nvidia-cuda-toolkit 7.0 from experimental to unstable
> to make room for working on 7.5.
> 
> The rdepends have been tested with the new toolkit.
> Since they cannot be autobuilt (B-D in non-free) this will require
> maintainer-provided binNMUs (or sourceful uploads), we are ready to do
> this.
> 
> * boinc is a false positive, it depends on a long list of cuda
>   alternatives, no action required for 7.0
> * starpu-contrib overlaps with the openmpi transition, but would require a
>   manual binNMU/upload anyway for that
> * eztrace-contrib (sid-only) may have to wait for 7.5.
> * hwloc-contrib, pycuda are ready
> 
> (just verified again myself that hwloc-contrib, pycuda, starpu-contrib
> successfully build with nvidia-cuda-toolkit (>= 7) (and openmpi 1.10.x))
> 
> There may be a few RMs be needed in sid since i386 is no longer
> supported, but most i386 rdepends binaries should be gone already.

Ack.

Cheers,
Emilio

Bug#813545: vlc: freeze followed by segmentation fault after closing the window

[Vincent Lefevre]

Package: src:vlc
Version: 2.2.2-1
Severity: important

After I close the window, VLC froze then crashed (segmentation fault).
I could reproduce this problem another time, but that's all. This never
occurred with previous versions.

Program terminated with signal SIGSEGV, Segmentation fault.
#0  __strcmp_sse2_unaligned ()
at ../sysdeps/x86_64/multiarch/strcmp-sse2-unaligned.S:30
30  ../sysdeps/x86_64/multiarch/strcmp-sse2-unaligned.S: No such file or 
directory.
[Current thread is 1 (Thread 0x7f07a02e1700 (LWP 15208))]

The backtrace:

Thread 2 (Thread 0x7f07cf935880 (LWP 15092)):
#0  0x7f07cf38d8cf in pthread_cond_wait@@GLIBC_2.3.2 () at 
../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
#1  0x7f07ceb7fe95 in vlc_cond_wait (p_condvar=, 
p_mutex=) at posix/thread.c:387
#2  0x7f07ceaff25b in playlist_fetcher_Delete (p_fetcher=0x244e3c0) at 
playlist/fetcher.c:166
p_next = 
album = 
#3  0x7f07ceb033c7 in playlist_preparser_Delete (p_preparser=0x244e330) at 
playlist/preparser.c:120
#4  0x7f07ceaebcea in libvlc_InternalCleanup (p_libvlc=0x2439ee8) at 
libvlc.c:546
#5  0x7f07cf5a5b6e in libvlc_release () at /usr/lib/libvlc.so.5
#6  0x00401396 in  ()
#7  0x7f07cedf9870 in __libc_start_main (main=0x401190, argc=1, 
argv=0x7ffe4950f0f8, init=, fini=, 
rtld_fini=, stack_end=0x7ffe4950f0e8) at libc-start.c:291
result = 
unwind_buf = {cancel_jmp_buf = {{jmp_buf = {0, 7486525756343416823, 
4199744, 140730128462064, 0, 0, -7486696018106812425, -7355813339458865161}, 
mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x401bc0, 0x7ffe4950f0f8}, data 
= {prev = 0x0, cleanup = 0x0, canceltype = 4201408}}}
not_first_call = 
#8  0x00401569 in  ()

Thread 1 (Thread 0x7f07a02e1700 (LWP 15208)):
#0  0x7f07cee6935e in __strcmp_sse2_unaligned () at 
../sysdeps/x86_64/multiarch/strcmp-sse2-unaligned.S:30
#1  0x7f07ceebecf0 in __tfind (key=key@entry=0x7f07a02e0980, 
vrootp=vrootp@entry=0x2521a08, compar=compar@entry=0x7f07ceb76700 ) at 
tsearch.c:320
root = 0x7f07cf177c58 
r = 
rootp = 
#2  0x7f07cebb in var_SetChecked (psz_name=0x7f07ceba1c0f 
"item-change", obj=0x2521a98) at misc/variables.c:154
priv = 0x2521a00
pp_var = 
i_ret = 0
oldval = {i_int = 0, b_bool = false, f_float = 0, psz_string = 0x0, 
p_address = 0x0, p_object = 0x0, p_list = 0x0, i_time = 0, coords = {x = 0, y = 
0}}
p_priv = 0x2521a00
#3  0x7f07cebb in var_SetChecked (p_this=0x2521a98, 
psz_name=psz_name@entry=0x7f07ceba1c0f "item-change", 
expected_type=expected_type@entry=112, val=...) at misc/variables.c:712
i_ret = 0
oldval = {i_int = 0, b_bool = false, f_float = 0, psz_string = 0x0, 
p_address = 0x0, p_object = 0x0, p_list = 0x0, i_time = 0, coords = {x = 0, y = 
0}}
p_priv = 0x2521a00
#4  0x7f07ceb05a7c in input_item_changed (ptr=, 
psz_name=0x7f07ceba1c0f "item-change", p_obj=) at 
../include/vlc_variables.h:287
p_item = 
#5  0x7f07ceb05a7c in input_item_changed (p_event=, 
user_data=) at playlist/item.c:180
p_item = 
#6  0x7f07ceb718ea in vlc_event_send (p_em=p_em@entry=0x7f0788047758, 
p_event=p_event@entry=0x7f07a02e0a40) at misc/events.c:237
listeners_group = 
listener = 
array_of_cached_listeners = 0x7f0785813ec0
cached_listener = 0x7f0785813ec0
i = 
i_cached_listeners = 
#7  0x7f07ceb0b2a6 in input_item_SetMeta (p_i=0x7f07880476d0, 
meta_type=vlc_meta_ArtworkURL, psz_val=0x7f0785813df8 
"http://coverartarchive.org/release/c3dd54fa-7eb7-464f-92da-e356d6c3776a/front-500;)
 at input/item.c:143
event = {type = vlc_InputItemMetaChanged, p_obj = 0x7f07880476d0, u = 
{input_state_changed = {new_state = 16}, input_selected_stream_changed = 
{unused = 0x7f070010}, input_item_meta_changed = {meta_type = 
vlc_meta_ArtworkURL}, input_item_subitem_added = {p_new_child = 
0x7f070010}, input_item_subitem_tree_added = {p_root = 0x7f070010}, 
input_item_duration_changed = {new_duration = 139668041498640}, 
input_item_preparsed_changed = {new_status = 16}, input_item_name_changed = 
{new_name = 0x7f070010 }, input_item_info_changed = {unused = 0x7f070010}, 
input_item_error_when_reading_changed = {new_value = 16}, 
services_discovery_item_added = {p_new_item = 0x7f070010, psz_category = 
0x7f07be884b8e "\205\300\017\205\062\001"}, services_discovery_item_removed = 
{p_item = 0x7f070010}, services_discovery_started = {unused = 
0x7f070010}, services_discovery_ended = {unused = 0x7f070010}, 
addon_generic_event = {p_entry = 0x7f070010}}}
#8  0x7f07be884f32 in  () at /usr/lib/vlc/plugins/lua/liblua_plugin.so
#9  0x7f07be887850 in  () at /usr/lib/vlc/plugins/lua/liblua_plugin.so
#10 0x7f07be8852c5 in  () at /usr/lib/vlc/plugins/lua/liblua_plugin.so
#11 0x7f07ceb62505 in module_load 

Bug#813533: inosync: [PATCH] So someone can -c configfile a dot file

[Eric Côté]

Package: inosync
Version: 0.2.1-1
Severity: normal
Tags: patch

line 134:
add:

  if configfile.startswith("."):
 configfile = configfile.strip(".")

right after the

  if configfile.endswith(".py"):


Thanks,
Eric


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

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

Versions of packages inosync depends on:
ii  python2.7.11-1
ii  python-pyinotify  0.9.5-1
ii  rsync 3.1.1-3

inosync recommends no packages.

inosync suggests no packages.

-- no debconf information

-- debsums errors found:
debsums: changed file /usr/bin/inosync (from inosync package)

Bug#813463: janest-core-extended: FTBFS: E: Failure("Command ''/usr/bin/ocamlbuild' src/libcore_extended_stubs.a src/dllcore_extended_stubs.so src/core_extended.cma src/core_extended.cmxa src/core_ext

[Hilko Bengen]

Control: reassign -1 janest-core

* Chris Lamb:

>   make[1]: Leaving directory 
> '/home/lamby/temp/cdt.20160202094953.sKIF2YheZX/janest-core-extended-113.00.00'
>  debian/rules override_dh_auto_build
>   make[1]: Entering directory 
> '/home/lamby/temp/cdt.20160202094953.sKIF2YheZX/janest-core-extended-113.00.00'
>   ocaml setup.ml -build
>   W: Cannot find source file matching module 'selector_lib' in library 
> selector_lib
>   W: Cannot find source file matching module 'core_extended' in library 
> core_extended
>   ocamlfind ocamlopt unix.cmxa -I /usr/lib/ocaml/ocamlbuild 
> /usr/lib/ocaml/ocamlbuild/ocamlbuildlib.cmxa -linkpkg myocamlbuild.ml 
> /usr/lib/ocaml/ocamlbuild/ocamlbuild.cmx -o myocamlbuild
>   /usr/bin/ocamlfind ocamlc -g -I src -package core -thread -ccopt -Isrc -c 
> src/extended_int_stubs.c
>   + /usr/bin/ocamlfind ocamlc -g -I src -package core -thread -ccopt -Isrc -c 
> src/extended_int_stubs.c
>   ocamlfind: Package `enumerate' not found - required by `core'

So, libcore-ocaml-dev does not declare dependencies on enumerate, this
looks similar to #813439 (missing dependency to
libcustom-printf-camlp4-dev).

This may well be a toolchain-related problem. Investigating...

Cheers,
-Hilko

Bug#813468: boinc-client: Some https connections fail due to Debian Jessie openssl and ca-certificate interactions

[Kurt Roeckx]

On Tue, Feb 02, 2016 at 08:15:03PM +, Tim Small wrote:
> It would seem that the best fix would be to pull this upstream code
> into an upcoming Jessie point release, because as this gives the least
> surprising / least broken behaviour, and is in-line the the behaviour of
> most (all?) modern SSL/TLS implementations.  

This is one of those changes that I've been trying to get into the
stable point release for a long time now.


Kurt

Bug#772131: systemd: Suspending by closing the lid opens Polkit dialogue after resume

[Michael Biebl]

Control: reassign -1 kdelibs-bin
Control: retitle -1 kde does not properly cope with logind being restarted

On Mon, 08 Dec 2014 21:51:24 +0100 Ralf Jung  wrote:
> Hi,
> 
> > postinst has:
> > 
> > if [ -n "$2" ]; then
> > systemctl daemon-reexec || true
> > systemctl try-restart systemd-logind.service || true
> > systemctl try-restart systemd-networkd.service || true
> > systemctl try-restart systemd-resolved.service || true
> > systemctl try-restart systemd-timesyncd.service || true
> > fi
> > 
> > 
> > Can you run those commands step-by-step and check if a specific restart
> > is able to trigger the issue?
> > Might be, that some KDE program doesn't cope with the restart of
> > systemd-logind and doesn't properly reconnect to the logind D-Bus service.
> 
> As you guessed: After the systemd-logind restart, suspend is broken.
> 
> It was my understanding that D-Bus operates on a per-call basis and
> there is no such thing as a "connection" between a d-bus client and a
> service it's accessing (there's of course a "connection" between each
> peer and the bus daemon, but that's an implementation detail) - but that
> may just as well be wrong.
> 

I'm going to re-assign this to kdelibs-bin, the package shipping kdeinit4,
which you mentioned in your initial message.
The KDE maintainers can then handle it from there.
It would probably help if you posted the KDE versions you use.

Regards,
Michael

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



signature.asc
Description: OpenPGP digital signature

Bug#813078: git-annex: FTBFS: libgnutls-deb0.so.28: cannot open shared object file: No such file or directory

[peter green]

On 02/02/16 05:37, peter green wrote:

found 813078 5.20150731-1
thanks

Sorry I missed the first sentance of my explanation of the found 
command, the paragraph was meant to say.


In raspbian stretch we have seen this same issue with a binnmu of 
5.20150731-1. Debian reproducability tests in testing are not showing it 
right now, but I strongly suspect that is because some other package 
hasn't been rebuilt yet, not because the underlying issue is not there.




I'm going to try scheduling a binnmu of haskell-network-protocol-xmpp 
in raspbian stretch and see if that fixes things.

I have done this and git-annex rebuilt

I guess the question now is do we just ask the release team to binnmu 
haskell-network-protocol-xmpp in Debian or does someone want to 
investigate and fix the missing dependencies.

Bug#813540: [iceweasel] Random, spontaneous returns to source page from linked page

[David Baron]

Package: iceweasel
Version: 44.0-1
Severity: important

--- Please enter the report below this line. ---
Viewing a site page, click a link and view that. Spontaneously, one is 
returned to the main page, this at random.

Workaround is naturally to open the link in another tab or window for now.

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

Debian Release: stretch/sid
  500 unstableftp.us.debian.org 
  500 testing ftp.us.debian.org 
  500 sid linux.dropbox.com 
  500 lucid   ppa.launchpad.net 
1 experimentalftp.us.debian.org 

--- Package information. ---
Depends   (Version) | Installed
===-+-===
libasound2  (>= 1.0.16) | 
libatk1.0-0 (>= 1.12.4) | 
libc6 (>= 2.17) | 
libcairo2(>= 1.2.4) | 
libdbus-1-3  (>= 1.0.2) | 
libdbus-glib-1-2  (>= 0.78) | 
libevent-2.0-5   (>= 2.0.10-stable) | 
libffi6  (>= 3.0.4) | 
libfontconfig1(>= 2.11) | 
libfreetype6 (>= 2.2.1) | 
libgcc1(>= 1:4.1.1) | 
libgdk-pixbuf2.0-0  (>= 2.22.0) | 
libglib2.0-0(>= 2.37.3) | 
libgtk2.0-0 (>= 2.24.0) | 
libhunspell-1.3-0(>= 1.3.3) | 
libnspr4  (>= 2:4.10.3) | 
libnss3 (>= 2:3.16) | 
libpango-1.0-0  (>= 1.14.0) | 
libsqlite3-0 (>= 3.7.12-1~) | 
libstartup-notification0   (>= 0.8) | 
libstdc++6 (>= 4.9) | 
libvpx1  (>= 1.3.0) | 
libx11-6| 
libxext6| 
libxrender1 | 
libxt6  | 
zlib1g (>= 1:1.2.0) | 
fontconfig  | 
procps  | 
debianutils   (>= 1.16) | 


Package's Recommends field is empty.

Suggests   (Version) | Installed
-+-===
fonts-stix   | 1.1.1-4
 OR otf-stix | 
fonts-oflb-asana-math| 
fonts-mathjax| 
mozplugger   | 
libgssapi-krb5-2 | 
 OR libkrb53 | 
libgnomeui-0 | 
libcanberra0 | 



--- Output from package bug script ---
Warning: locale not supported by C library, locale unchanged

Bug#813541: nvidia-graphics-drivers: Huge problems 'upgrading' to legacy version

[Manuel Bilderbeek]

Source: nvidia-graphics-drivers
Severity: important

Dear Maintainer,

I did my daily testing dist-upgrade just now, and I noticed I got a version of
the nvidia driver that is not going to work with my old GeForce 9600. I got a
nice pop up that the driver is not going to work, so I chose 'No', to not
install it.

But afterwards, many packages of 352 were actually installed after all.

I tried to install all the proper 340xx legacy packages, but as they didn't
conflict with the normal packages, all the normal stuff was also still
installed. Apparently that gave a lot of problems, because after booting I only
got a very blinky text console and no X.

After manually removing all packages of the 352 version and changing 'nvidia'
in /etc/modules-load.d/nvidia.conf to 'nvidia-legacy-340xx' I finally got a
working X11 again

Why did I have to do all that manual work to get X11 working again?
Which package owns that nvidia.conf anyway? I couldn't find it...

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

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

Bug#811024: jessie-pu: package imagemagick/8:6.8.9.9-5

[Vincent Fourmond]

  Dear Adam,

On Sun, Jan 31, 2016 at 7:19 PM, Adam D. Barratt 
wrote:

> Control: tags -1 + confirmed
>
> > Essentially, the upload I'm proposing (debdiff to stable attached)
> > makes stable and unstable identical, since there were only security
> > fixes involved (the bulk of the work is happening in experimental, but
> > there are transitions involved, so it's not very fast...). Is that OK
> > for an upload to jpu ?
>
> The no-op changes to the patches you haven't changed (i.e. the first 56)
> are rather noisy.
>

  I'm sorry, this is one of the current shortcomings of gitpkg, which we
find quite comfortable otherwise to deal with such a complex package.


> Some of the new patches also appear to include unrelated changes; for
> instance:
>
> +Subject: [PATCH] Fix PixelColor off by one on i386
> [...]
> +-"XmlMissingElement", ", slot \"%s\"", slot);
> ++"XmlMissingElement",", slot \"%s\"",slot);
>

  These are cosmetic fixes that come from the upstream patches also fixing
the security issues, we didn't feel like editing upstream commits.


> Assuming that the resulting package has been tested on Jessie, please go
> ahead.
>

  Yep, I've just checked it works fine, I'm uploading right away.

  Thanks !

  Vincent

Bug#792880: openvpn does not start

[Diego Fernández Durán]

Hi,

I confirm that after a reboot OpenVPN starts correctly without
modifying /etc/default/openvpn

Thanks.

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

Bug#813542: transition: nvidia-cuda-toolkit

[Andreas Beckmann]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
Forwarded: 
https://release.debian.org/transitions/html/auto-nvidia-cuda-toolkit.html

I'd like to move nvidia-cuda-toolkit 7.0 from experimental to unstable
to make room for working on 7.5.

The rdepends have been tested with the new toolkit.
Since they cannot be autobuilt (B-D in non-free) this will require
maintainer-provided binNMUs (or sourceful uploads), we are ready to do
this.

* boinc is a false positive, it depends on a long list of cuda
  alternatives, no action required for 7.0
* starpu-contrib overlaps with the openmpi transition, but would require a
  manual binNMU/upload anyway for that
* eztrace-contrib (sid-only) may have to wait for 7.5.
* hwloc-contrib, pycuda are ready

(just verified again myself that hwloc-contrib, pycuda, starpu-contrib
successfully build with nvidia-cuda-toolkit (>= 7) (and openmpi 1.10.x))

There may be a few RMs be needed in sid since i386 is no longer
supported, but most i386 rdepends binaries should be gone already.

Ben file: the autogenerated one looks good

Andreas

Bug#813128: Fwd: Bug#813128: transition: openmpi

[Michael Banck]

On Wed, Feb 03, 2016 at 12:09:18AM +0100, Michael Banck wrote:
> On Tue, Feb 02, 2016 at 12:19:10AM +0100, Matthias Klose wrote:
> > On 01.02.2016 15:38, Emilio Pozuelo Monfort wrote:
> > >On 01/02/16 12:41, Alastair McKinstry wrote:
> > >>
> > >>The upload of openmpi1.10 triggered an auto-openmpi transition, as
> > >>expected and wanted.
> > >>The rest, is premature.
> > >
> > >The problem is that you uploaded the package directly to unstable, without
> > >asking for a transition slot and without fixing those problems you mention
> > >beforehand. It'd have been better to upload it to experimental until 
> > >things were
> > >ready.
> > >
> > >Since that has already happened, it'd be good to know what packages build 
> > >fine
> > >against the new openmpi and which ones don't.
> > 
> > fyi, I was surprised as well, tried to go forward, and ended up with
> > http://people.canonical.com/~ubuntu-archive/transitions/html/openmpi.html
> > (only tried dependency level 1 to build).
> 
> Thanks!
> 
> I look at some of mine and they seem to FTBFS due to scalapack on longer
> being installable, which in turn is due to blacs-mpi FTBFSing:
> 
> /usr/bin/ld: cannot find -lmpi_f77
> 
> That library has vanished from libopenmpi-dev, Alastair, was that
> intentional, and if so, how is Fortran linking supposed to work now?
> 
> I removed that library from blacs-mpi link line and it built fine, but I
> am not sure this is the right fix.

Nevermind, I saw Alastair has filed a patch (#813490). As blacs-mpi has
been NMU'd before and looks rather central, I suggest to zero-day NMU
this, unless somebody objects.


Michael

Bug#813541: nvidia-graphics-drivers: Huge problems 'upgrading' to legacy version

[Andreas Beckmann]

Hi Manuel,

On 2016-02-02 23:56, Manuel Bilderbeek wrote:
> I did my daily testing dist-upgrade just now, and I noticed I got a version of
> the nvidia driver that is not going to work with my old GeForce 9600. I got a
> nice pop up that the driver is not going to work, so I chose 'No', to not
> install it.
> 
> But afterwards, many packages of 352 were actually installed after all.
> 
> I tried to install all the proper 340xx legacy packages, but as they didn't
> conflict with the normal packages, all the normal stuff was also still
> installed. Apparently that gave a lot of problems, because after booting I 
> only
> got a very blinky text console and no X.

The current and legacy drivers are intended to be coinstallable.

To switch to the -legacy driver while (parts of) -current is still
installed, you could just use the new command

  update-glx --config nvidia

We should probably advertise this more on the legacy warning screen.

> After manually removing all packages of the 352 version and changing 'nvidia'
> in /etc/modules-load.d/nvidia.conf to 'nvidia-legacy-340xx' I finally got a
> working X11 again
> 
> Why did I have to do all that manual work to get X11 working again?
> Which package owns that nvidia.conf anyway? I couldn't find it...

That depends ... on the setting of the alternatives. :-)


Andreas

Bug#813164: coreutils: ls suddenly quotes output

[Jamie Heilman]

This behavior needs to be reverted.  There are too many assumptions
being made, the quoting used is shell-specific, and not universally
supported.  For example, consider a file who's name contains a tab,
like "ab".

$ ls
'a'$'\t''b'

OK, so that syntax is supported by bash and zsh, so if you're using
one of those shells, maybe you know what it means, and you can cut and
paste that and make use of it, but in csh or dash, it doesn't mean the
same thing.

Bug#813532: transition: libjsoncpp

[Emilio Pozuelo Monfort]

Control: tags -1 confirmed

On 02/02/16 22:04, Peter Spiess-Knafl wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> 
> I would like to start the transition for libjsoncpp.
> 
> Its been on experimental for quite a while now, until I could test all the
> rdepends.
> 
> The following rdepends have been successfully tested:
> 
> cmake
> bamtools
> dcmtkpp
> kodi-pvr-argustv
> lgogdownloader
> libjson-rpc-cpp
> llvm-toolchain-3.7
> minetest
> orthanc
> paraview
> springlobby
> sysdig
> vtk6
> 
> The following rdepends have a FTBFS problem:
> 
> ginkgocadx - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=805170

Go ahead.

Cheers,
Emilio

Bug#813537: tails-installer: tails installer fails with extlinux error

[Stefani Banerian]

Package: tails-installer
Version: 4.4.6+dfsg-1~bpo8+1
Severity: normal

Dear Maintainer,


In attempting to run tails installer an error message about missing extlinux 
was encountered.
It is true that this package was not installed on the system.

I did not find a "depends" of extlinux package in the "control" file.
Perhaps extlinux should be required?



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

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

Versions of packages tails-installer depends on:
ii  gdisk  0.8.10-2
ii  genisoimage9:1.1.11-3
ii  gir1.2-glib-2.01.42.0-2.2
ii  gir1.2-gtk-3.0 3.14.5-1+deb8u1
ii  gir1.2-udisks-2.0  2.1.3-5
ii  mtools 4.0.18-2
ii  p7zip-full 9.20.1~dfsg.1-4.1+deb8u1
ii  policykit-10.105-8
ii  python 2.7.9-1
ii  python-configobj   5.0.6-1
ii  python-gi  3.14.0-1
ii  python-urlgrabber  3.9.1-4.1
ii  syslinux   3:6.03+dfsg-5+deb8u1

tails-installer recommends no packages.

tails-installer suggests no packages.

-- no debconf information

Bug#813543: vlc: doesn't output any sound

[Vincent Lefevre]

Package: src:vlc
Version: 2.2.2-1
Severity: grave
Justification: renders package unusable

After the upgrade to 2.2.2, VLC no longer outputs any sound. This is
specific to VLC as there is no such problem with ogg123, for instance.

I suspect a major problem with VLC 2.2.2 since it also segfaults. I'm
going to report another bug about this (I don't know whether this is
related).

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

Kernel: Linux 4.3.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=POSIX, 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.4
ii  fonts-freefont-ttf  20120503-4
ii  libaa1  1.4p5-44
ii  libavcodec-ffmpeg56 7:2.8.5-1+b1
ii  libavutil-ffmpeg54  7:2.8.5-1+b1
ii  libc6   2.21-7
ii  libcaca00.99.beta19-2+b1
ii  libcairo2   1.14.6-1
ii  libegl1-mesa [libegl1-x11]  11.1.1-2
ii  libfreerdp-client1.11.1.0~git20140921.1.440916e+dfsg1-5+b1
ii  libfreerdp-core1.1  1.1.0~git20140921.1.440916e+dfsg1-5+b1
ii  libfreerdp-gdi1.1   1.1.0~git20140921.1.440916e+dfsg1-5+b1
ii  libfreetype62.6.1-0.1
ii  libfribidi0 0.19.7-1
ii  libgcc1 1:5.3.1-7
ii  libgl1-mesa-glx [libgl1]11.1.1-2
ii  libgles1-mesa [libgles1]11.1.1-2
ii  libgles2-mesa [libgles2]11.1.1-2
ii  libglib2.0-02.46.2-3
ii  libpulse0   7.1-2
ii  libqt5core5a5.5.1+dfsg-13
ii  libqt5gui5  5.5.1+dfsg-13
ii  libqt5widgets5  5.5.1+dfsg-13
ii  libqt5x11extras55.5.1-3
ii  librsvg2-2  2.40.13-2
ii  libsdl-image1.2 1.2.12-5+b5
ii  libsdl1.2debian 1.2.15-12
ii  libstdc++6  5.3.1-7
ii  libva-drm1  1.6.2-1
ii  libva-x11-1 1.6.2-1
ii  libva1  1.6.2-1
ii  libvlccore8 2.2.2-1
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.2-1
ii  zlib1g  1:1.2.8.dfsg-2+b1

Versions of packages vlc recommends:
ii  vlc-plugin-notify  2.2.2-1
ii  vlc-plugin-samba   2.2.2-1
ii  xdg-utils  1.1.1-1

vlc suggests no packages.

Versions of packages vlc-nox depends on:
ii  dpkg   1.18.4
ii  liba52-0.7.4   0.7.4-18
ii  libasound2 1.1.0-1
ii  libass50.13.1-1
ii  libavahi-client3   0.6.32~rc+dfsg-1
ii  libavahi-common3   0.6.32~rc+dfsg-1
ii  libavc1394-0   0.5.4-2
ii  libavcodec-ffmpeg567:2.8.5-1+b1
ii  libavformat-ffmpeg56   7:2.8.5-1+b1
ii  libavutil-ffmpeg54 7:2.8.5-1+b1
ii  libbasicusageenvironment1  2016.01.29-2
ii  libbluray1 1:0.9.2-2
ii  libc6  2.21-7
ii  libcddb2   1.3.2-5
ii  libcdio13  0.83-4.2+b1
ii  libchromaprint01.2-2
ii  libcrystalhd3  1:0.0~git20110715.fdd2f19-11+b1
ii  libdbus-1-31.10.6-1
ii  libdc1394-22   2.2.3-1
ii  libdca00.0.5-7
ii  libdirectfb-1.2-9  1.2.10.0-5.1
ii  libdvbpsi101.3.0-4
ii  libdvdnav4 5.0.3-1
ii  libdvdread45.0.3-1
ii  libebml4v5 1.3.3-1
ii  libfaad2   2.8.0~cvs20150510-1
ii  libflac8   1.3.1-4
ii  libfontconfig1 2.11.0-6.3
ii  libfreetype6   2.6.1-0.1
ii  libfribidi00.19.7-1
ii  libgcc11:5.3.1-7
ii  libgcrypt201.6.4-5
ii  libgnutls303.4.8-3
ii  libgpg-error0  1.21-1
ii  libgroupsock8  2016.01.29-2
ii  libjpeg62-turbo1:1.4.2-2
ii  libkate1   0.4.1-5
ii  liblircclient0 0.9.0~pre1-1.2
ii  liblivemedia50 2016.01.29-2
ii  liblua5.2-05.2.4-1
ii  libmad00.15.1b-8
ii  libmatroska6v5 1.4.4-1
ii  libmodplug11:0.8.8.5-2
ii  libmpcdec6 2:0.1~r475-1
ii  libmpeg2-4 0.5.1-7
ii  libmtp91.1.10-2
ii  

Bug#813544: prometheus-node-exporter: cannot run as root

[Anton T]

Package: prometheus-node-exporter
Version: 0.12.0+ds-2
Severity: important
Tags: patch

Dear Maintainer,

It seems that setting USER=root in /etc/default/prometheus-node-exporter
breaks the init script because HELPER_ARGS is defined before
/etc/default/$NAME is included.

This patch fixes the issue:
--- /etc/init.d/prometheus-node-exporter.orig   2016-02-02 23:06:36.0 
+
+++ /etc/init.d/prometheus-node-exporter2016-02-02 23:07:06.0 
+
@@ -23,12 +23,12 @@
 PIDFILE=/var/run/prometheus/prometheus-node-exporter.pid
 LOGFILE=/var/log/prometheus/prometheus-node-exporter.log

-HELPER=/usr/bin/daemon
-HELPER_ARGS="--name=$NAME --output=$LOGFILE --pidfile=$PIDFILE --user=$USER"
-
 ARGS=""
 [ -r /etc/default/$NAME ] && . /etc/default/$NAME

+HELPER=/usr/bin/daemon
+HELPER_ARGS="--name=$NAME --output=$LOGFILE --pidfile=$PIDFILE --user=$USER"
+
 do_start_prepare()
 {
 mkdir -p `dirname $PIDFILE` || true


Kind regards,
Anton

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

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: systemd (via /run/systemd/system)

Versions of packages prometheus-node-exporter depends on:
ii  daemon  0.6.4-1
ii  libc6   2.19-18+deb8u1

prometheus-node-exporter recommends no packages.

prometheus-node-exporter suggests no packages.

-- debconf-show failed

Bug#788963: quota: Failed to start Check And Enable File System Quotas on Debian Jessie

[Kepi]

Confirmed, same problem our jessie servers. We are not alone according
to quick google search.

-- 
Kepi


signature.asc
Description: PGP signature

Bug#813539: [Pkg-privacy-maintainers] Bug#813539: tails-installer: tails installer fails to sense usb stick

[intrigeri]

Control: tag -1 + moreinfo

Hi,

Stefani Banerian wrote (02 Feb 2016 22:20:31 GMT) :
> in trying to use the gui, the usb stick was never displayed.

> I did run the installer from command line:
> /usr/lib/tails-installer/tails-installer  -v -f /dev/sdb 

We don't support running the installer this way (not all combinations
of options result in sane behaviour), that's why this program is not
in the $PATH.

Can you please try to reproduce this problem using
tails-installer-launcher?

And, still curious: any specific reason why are you picking your own
set of command-line options? If you have a use case that is not
addressed by tails-installer-launcher, I'm curious :)

Cheers!

Bug#813128: Fwd: Bug#813128: transition: openmpi

[Michael Banck]

On Tue, Feb 02, 2016 at 12:19:10AM +0100, Matthias Klose wrote:
> On 01.02.2016 15:38, Emilio Pozuelo Monfort wrote:
> >On 01/02/16 12:41, Alastair McKinstry wrote:
> >>
> >>The upload of openmpi1.10 triggered an auto-openmpi transition, as
> >>expected and wanted.
> >>The rest, is premature.
> >
> >The problem is that you uploaded the package directly to unstable, without
> >asking for a transition slot and without fixing those problems you mention
> >beforehand. It'd have been better to upload it to experimental until things 
> >were
> >ready.
> >
> >Since that has already happened, it'd be good to know what packages build 
> >fine
> >against the new openmpi and which ones don't.
> 
> fyi, I was surprised as well, tried to go forward, and ended up with
> http://people.canonical.com/~ubuntu-archive/transitions/html/openmpi.html
> (only tried dependency level 1 to build).

Thanks!

I look at some of mine and they seem to FTBFS due to scalapack on longer
being installable, which in turn is due to blacs-mpi FTBFSing:

/usr/bin/ld: cannot find -lmpi_f77

That library has vanished from libopenmpi-dev, Alastair, was that
intentional, and if so, how is Fortran linking supposed to work now?

I removed that library from blacs-mpi link line and it built fine, but I
am not sure this is the right fix.


Michael

Bug#813232: How are bugs #741964 and #813232 related ?

[jhcha54008]

Hi,

Moving setup_devices at the end of first_stage()
would solve partially #741964 
(debootstrap: --variant=fakechroot and --foreign) 
too.

Regards,
JH Chatenet 

Bug#813468: boinc-client: Some https connections fail due to Debian Jessie openssl and ca-certificate interactions

[Christian Beer]

On 02.02.2016 22:04, Tim Small wrote:
>> On Tue, Feb 02, 2016 at 03:04:41PM +0100, Christian Beer wrote:
>> > I will also reference the workaround we advise to "downgrade" the
>> > ca-certificates package:
>> > https://einstein.phys.uwm.edu/forum_thread.php?id=11760=151305
> I think this is the worst solution from a security point of view, as it
> would prevent systems from revoking known-compromised CA certificates,
> should any become known (this has happened multiple times in the past)
> and be rolled out in future Debian security updates.
>
> It is also a system-wide change impacting the security of many other
> pieces of software (including ones which aren't impacted by the openssl
> bug, because they use different certificate chain verification code),
> so until Debian has a fix for this, I think I'd prefer to advise
> per-application workarounds, such as the one reference in the original
> report.

You are right that this impacts security but my goal was to provide a
short non-tech workaround so our volunteers do not get disconnected from
our servers or can reestablish the connection. Telling them to download
a certificate and cat'ing it to a file is also not a good and secure
solution. They would also need to remember and repeat this procedure
every time boinc-client gets updated.

I thought that there could be a quick fix to ca-certificates by
reintroducing cross-signed certificates that would benefit all users.
Instead I now read that it can take some more time to get this fixed.
For the affected BOINC projects it would be now the best solution to add
the "Thawte Premium Server CA" to the ca-bundle.crt shipped with
boinc-client. I'm going to test if this is used on Debian right now, it
normally is only used on Windows. But then we have to get this update
into Jessie too.

Regards
Christian

Bug#813539: [Pkg-privacy-maintainers] Bug#813539: tails-installer: tails installer fails to sense usb stick

[S. Banerian]

On 02/02/2016 03:14 PM, intrigeri wrote:
> Control: tag -1 + moreinfo
> 
> Hi,
> 
> Stefani Banerian wrote (02 Feb 2016 22:20:31 GMT) :
>> in trying to use the gui, the usb stick was never displayed.
> 
>> I did run the installer from command line:
>> /usr/lib/tails-installer/tails-installer  -v -f /dev/sdb 
> 
> We don't support running the installer this way (not all combinations
> of options result in sane behaviour), that's why this program is not
> in the $PATH.
> 
> Can you please try to reproduce this problem using
> tails-installer-launcher?
> 
> And, still curious: any specific reason why are you picking your own
> set of command-line options? If you have a use case that is not
> addressed by tails-installer-launcher, I'm curious :)
> 
> Cheers!

well, whenever I try the tails-installer-launcher, it never shows the
usb stick.

that's why i tried CLI, to look for more debug information!  :)
If there is a way to use the launcher, and get the installer to sense
the usb stick, that would be nice

-- 
Stefani Banerian
206-598-0302
gpg key 6642E7EE
fingerprint = BD13 875D 2D03 5E1D 1E3B  8BF7 F4B8 63AD 6642 E7EE

Bug#813543: vlc: doesn't output any sound

[Vincent Lefevre]

Control: reassign -1 pulseaudio 7.1-2
Control: severity -1 important
Control: retitle -1 pulseaudio: [alsa-sink-ALC3228 Analog] alsa-sink.c: Error 
opening PCM device front:0: Invalid argument

Firefox also had problems.

After logging out and logging in, vlc works again. So, it seems to
be a problem with the pulseaudio daemon. Reassigning.

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

Bug#810748: systemd does not mount /usr in initramfs, breaking split /usr

[Michael Biebl]

Am 02.02.2016 um 22:27 schrieb Michael Biebl:
> Hi Nis
> 
> On Tue, 19 Jan 2016 22:52:57 +0100 Nis Martensen 
> wrote:
>> Control: found -1 228-4
>>
>> Attached a version of the patch that should work for testing/unstable.
>> Again intended as a replacement for the existing patch.
> 
> I've looked a bit closer at your patch, and it looks fine.
> Not generating the systemd-fsck@ instance when the flag file exists,
> looks like a proper solution to this issue.
> 
> I gave the patch a quick test and it seems to work with both dracut and
> initramfs-tools. There are still some (new) issues with a separate /usr
> [1], but that happens with both initramfs-tools and dracut.
> 
> So I think the patch can go in as is.

Fwiw, I think the fix is important enough that it should go into jessie.
Installing dracut should not render a system unbootable.

I'll cherry-pick the fix for our jessie branch once the patch had a bit
of testing in unstable.


-- 
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#813543: vlc: doesn't output any sound

[Vincent Lefevre]

Control: found -1 2.2.1-5

On 2016-02-03 00:03:48 +0100, Vincent Lefevre wrote:
> Package: src:vlc
> Version: 2.2.2-1
> Severity: grave
> Justification: renders package unusable
> 
> After the upgrade to 2.2.2, VLC no longer outputs any sound. This is
> specific to VLC as there is no such problem with ogg123, for instance.

Downgrading the VLC packages to 2.2.1-5+b3 doesn't solve the problem.
In the logs, I can find errors like:

Feb 03 00:28:11 zira pulseaudio[1645]: [alsa-sink-ALC3228 Analog] alsa-sink.c: 
Error opening PCM device front:0: Invalid argument
Feb 03 00:28:11 zira pulseaudio[1645]: [alsa-sink-ALC3228 Analog] alsa-sink.c: 
Error opening PCM device front:0: Invalid argument

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

Bug#813349: joe: jstar crashes on startup if old config is present

[Josip Rodin]

forwarded 813349 https://sourceforge.net/p/joe-editor/bugs/341/
thanks

On Mon, Feb 01, 2016 at 12:47:38AM +0100, Adam Borowski wrote:
> Package: joe
> Version: 4.1-2
> Severity: important
> 
> If a ~/.jstarrc from a previous version exists, jstar will segfault on 
> startup.
> This happens even for unmodified configs (ie, a straight copy of
> /etc/joe/jstarrc into ~/.jstarrc).
> 
> Prior versions complained in the presence of an outdated config, but you
> just removed that check (#560182).  But in any case, response to even
> complete garbage should be an error message rather than a segfault.

Thanks for reporting this Adam, I filed it upstream.

-- 
 2. That which causes joy or happiness.

Bug#800947: ACL for /var/log/journal not set for group adm

[Michael Biebl]

Control: tags -1 + pending

On Mon, 5 Oct 2015 12:26:02 +0200 =?UTF-8?Q?Rapha=c3=abl_Halimi?=
 wrote:
> Package: systemd
> Version: 226-4
> 
> Hi,
> 
> About persistent logging, README.Debian claims :
> 
> "systemd will add an ACL for read permissions for users in the "adm" group."
> 
> This is not working: after creating /var/log/journal with the "install"
> command as instructed in the README.Debian, and even after several
> reboots, the ACL is not set:
> 
> raph@arche:~$ getfacl /var/log/journal/
...

While the idea of shipping /var/log/journal pre-configured in the
package is still an option, I now decided to apply a different fix.

I've cherry-picked two upstream commits which also apply the ACLs to
/var/log/journal (so newly created files inherit them directly) and to
exisiting system.journal files.

I've also updated the instructions in README.Debian (which now match
what's in man systemd-journald(8):

   mkdir -p /var/log/journal
   systemd-tmpfiles --create --prefix /var/log/journal

Those two command are now sufficient to setup the persistent journal
with the correct permissions and ACLs.

This will be part of the upcoming 228-5 release.
-- 
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#782553: sbuild: 'sbuild --source --no-arch-all' fails in a very confusing way

[Dima Kogan]

Johannes Schauer  writes:

> I am not able to reproduce this behaviour. I have $sbuild_source=1; in my
> ~/.sbuildrc but neither do I see any of the above error messages nor do I get
> 'Status: attempted'. Can you confirm that this issue was fixed with the recent
> sbuild release?

Hi. I just tried to reproduce, and once again, things work now. The
cleanup you did in this area must have taken care of this issue. And the
documentation changes are probably sufficient for the option conflicts.
Thank you very much!!!

Bug#669053: smartd.conf.5.in, version 5.42: Escape before "<" and ">", spaces and orthography in the manual.

[Bjarni Ingi Gislason]

On Mon, Feb 01, 2016 at 10:47:23AM +, Jonathan Dowland wrote:
> On Sat, Jan 30, 2016 at 09:47:25PM +, Bjarni Ingi Gislason wrote:
> > On Fri, Jan 29, 2016 at 04:40:19PM +, Jonathan Dowland wrote:
> > > Hi, thanks for getting back in touch.
> > > 
> > > I'm hoping to carry this patch in the next smartmontools upload. Somebody 
> > > needs
> > > to refresh it as ~50% of the hunks no longer apply to the current
> > > smartd.conf.5.
> > > 
> > 
> >   I can make a new patch.
> > Which source file shall I use?
> 
> Please find attached the current smartd.conf.5.
> 

  What  not was done:

  Use a macro to change to the italic font, instead of \fI [1],
if possible.
The macros have the italic corrections.
[1] man-pages(7)

  Use a macro instead of an escape sequence, \f...\P.,
for font style changes.

-- End ---

  What was done for
$Id: smartd.conf.5.in 4103 2015-06-01 19:51:18Z chrfranke $

Enable and fix warnings from 'man' and 'groff'.

:40: warning: escape character ignored before `<'
:40: warning: escape character ignored before `>'

#

Change `` to ".

#

Split lines longer than about 80 characters into two or more
lines.

  References:

  1) man-pages(7) from package \"man-pages\" or
\"www.kernel.org/doc/man-pages\" section 7 or
\"man7.org/linux/man-pages/man7/man-pages.7.html\":

New sentences should be started on new lines.
This makes it easier to see the effect of patches,
which often operate at the level of individual sentences.

  2) groff_diff(7) in package \"groff\":

In GNU troff, as in UNIX troff, you should always follow a sentence
with either a newline or two spaces.

  3) \"info groff\":

  Search for \"sentence\" to get more hints about input conventions.

#

  Remove space at end of lines.

#

The space between sentences in "roff" is two spaces.
Better is to begin each sentence on a new line to avoid different
writers' conventions.

#

Change \' (acute) to \(aq, if used as a quote.
Change \' (acute) to ', if used as an apostrophe.

#

Change - to \(en (en-dash) for a numeric range.

#

Protect a full stop (.) with \&, if
 a) it can be transported to the first column, when the line is
reformatted (split).
 b) it is the last part of an abbreviation that does not end a
sentence.

#

Add a (no-break, "\ ") space between a number and an unit as these
are not one entity

#

Change a hyphen-minus to a minus (\-),
if in front of a name for an option

#

Remove space in the first column,
if not intended.

# End

  Patch is in the attachment.


-- 
Bjarni I. Gíslason


smartd.conf.5.in.diff.gz
Description: GNU Zip compressed data

Bug#813550: gitlab: Fails to install with ruby-activesupport=2:4.2.5.1-1

[Viktor Malyarchuk]

Package: gitlab
Version: 8.4.0+dfsg-1
Severity: important

Dear Maintainer,

gitlab fails to install with ruby-activesupport=2:4.2.5.1-1

Verifying we have all required libraries...
Resolving dependencies.
Could not find activesupport-4.2.5 in any of the sources
dpkg: error processing package gitlab (--configure):
 subprocess installed post-installation script returned error exit status 7

There is no ruby-activesupport 4.2.5 in Debain.

Best regards,
Viktor

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

Kernel: Linux 4.3.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.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 gitlab depends on:
ii  adduser3.113+nmu3
ii  asciidoctor1.5.3-1
ii  bc 1.06.95-9+b1
ii  debconf [debconf-2.0]  1.5.58
ii  gitlab-shell   2.6.10-1
ii  gitlab-workhorse   0.5.0-1
ii  libjs-chartjs  1.0.2-1
ii  libjs-clipboard1.4.2-1
ii  libjs-fuzzaldrin-plus  0.3.1-1
ii  libjs-graphael 0.5+dfsg-1
ii  libjs-jquery-cookie10-2
ii  libjs-jquery-history   10-2
ii  libjs-jquery-nicescroll3.6.6-1
ii  nginx  1.9.10-1
ii  nginx-full [nginx] 1.9.10-1
ii  nodejs 4.2.6~dfsg-1
ii  postgresql 9.5+172
ii  postgresql-client-9.5 [postgresql-client]  9.5.0-2
ii  rake   10.4.2-2
ii  redis-server   2:3.0.7-2
ii  ruby   1:2.3~0
ii  ruby-ace-rails-ap  3.0.3-2
ii  ruby-activerecord-deprecated-finders   1.0.4-1
ii  ruby-activerecord-session-store0.1.1-2
ii  ruby-acts-as-taggable-on   3.5.0-2
ii  ruby-addressable   2.3.8-1
ii  ruby-after-commit-queue1.3.0-1
ii  ruby-allocations   1.0.3-1
ii  ruby-asana 0.4.0-1
ii  ruby-attr-encrypted1.3.4-1
ii  ruby-babosa1.0.2-1
ii  ruby-bootstrap-sass3.3.5.1-3
ii  ruby-browser   1.0.1-1
ii  ruby-cal-heatmap-rails 3.5.1+dfsg-1
ii  ruby-carrierwave   0.10.0+gh-1
ii  ruby-charlock-holmes   0.7.3+dfsg-2
ii  ruby-coffee-rails  4.1.0-2
ii  ruby-colorize  0.7.7-1
ii  ruby-connection-pool   2.2.0-1
ii  ruby-creole0.5.0-2
ii  ruby-d3-rails  3.5.6+dfsg-1
ii  ruby-default-value-for 3.0.1-1
ii  ruby-devise3.5.2-3
ii  ruby-devise-async  0.9.0-1
ii  ruby-devise-two-factor 2.0.0-1
ii  ruby-diffy 3.0.6-1
ii  ruby-doorkeeper2.2.1-1
ii  ruby-dropzonejs-rails  0.7.1-1
ii  ruby-email-reply-parser0.5.8-1
ii  ruby-fog   1.34.0-2
ii  ruby-fogbugz   0.2.1-2
ii  ruby-font-awesome-rails4.3.0.0-1
ii  ruby-gemnasium-gitlab-service  0.2.6-1
ii  ruby-github-linguist   4.7.2-1
ii  ruby-github-markup 1.3.3+dfsg-1
ii  ruby-gitlab-emoji  0.2.1-1
ii  ruby-gitlab-flowdock-git-hook  1.0.1-1
ii  ruby-gitlab-git7.2.22-1
ii  ruby-gollum-lib4.1.0-3
ii  ruby-gon   6.0.1-1
ii  ruby-grape 0.13.0-1
ii  ruby-grape-entity  0.4.5-1
ii  ruby-haml-rails0.9.0-4
ii  ruby-hipchat   1.5.2-1
ii  ruby-html-pipeline 1.11.0-1
ii  ruby-httparty  0.13.5-1
ii  ruby-influxdb  0.2.3-1
ii  ruby-jquery-atwho-rails1.3.2-2
ii  ruby-jquery-rails  4.0.5-1
ii  ruby-jquery-scrollto-rails 1.4.3+dfsg-1
ii  ruby-jquery-turbolinks 2.1.0~dfsg-1
ii  ruby-jquery-ui-rails   5.0.5-3
ii  ruby-kaminari 

Bug#813128: Fwd: Bug#813128: transition: openmpi

[Michael Banck]

On Tue, Feb 02, 2016 at 02:40:11PM +, Mattia Rizzolo wrote:
> On Tue, Feb 02, 2016 at 08:44:46AM +0100, Alastair McKinstry wrote:
> > On 01/02/2016 16:34, Michael Banck wrote:
> > > On Mon, Feb 01, 2016 at 11:41:17AM +, Alastair McKinstry wrote:
> > >> Its not fully ready for transition, and I need to put a blocker on it.
> > >> Small fixes for kFreeBSD, Hurd: (conditional use of --verbs in
> > >> configure), pkg-config file handling,
> > >> enabling of static if possible, tests.
> 
> I wonder, why don't you build for s390x? I tried a build on a porterbox
> (version 1.10.2-2 + enable s390x on Architecture:) and it built just
> fine.
> Also I have a gut feeling x32 is going to just work too.
> And at this point it makes me wonder why not just using arch:any.
> 
> The change away from arch:any seems to be (according to the changelog)
> from 2007, version 1.2.3-3, but I'm not sure if this makes sense
> anymore.  At least, the package builds...

That's good news, I agree it makes sense to switch to Arch: any now and
turn on the test suite to see what breaks - that's certainly something
that should've better happened in experimental as intended, but oh well.


Michael

Bug#813552: spe: switch dependency from python-wxglade to wxglade

[Andreas Beckmann]

Package: spe
Version: 0.8.4.h-3.1
Severity: serious
Tags: sid stretch

Hi,

python-wxglade has been renamed to wxglade, please update your
dependencies.


Andreas

Bug#813538: please speed up checking multiple build profiles

[Helmut Grohne]

Package: dose-builddebcheck
Severity: wishlist
User: helm...@debian.org
Usertags: rebootstrap

Hi dose3 developers,

By now, rebootstrap[1] is a heavy user of dose-builddebcheck and
invoking it well over 50 times per run. This starts to manifest in the
time it takes to run rebootstrap. Thus far I am always passing the same
set of build profiles to dose, but in future I would like to ask it for
building some packages with different profiles than others. Of course, I
can simply run dose-builddebcheck for each profile combination, but each
of those invocations incurs the parsing of Packages and Sources and thus
increases the time to run rebootstrap.

For example, I would like to be able to ask dose-builddebcheck whether
util-linux can be built under stage1 or tar can be built with no
profiles.

Johannes suggested splitting the parsing phase into a separate step,
such that multiple queries could be made against the same Packages file
without incurring the cost of parsing multiple times.

Helmut

[1] https://wiki.debian.org/HelmutGrohne/rebootstrap

Bug#813546: loop when package is in "Bu" state and one tries to install it

[積丹尼 Dan Jacobson]

Package: aptitude
Version: 0.7.5-3

# aptitude install imagemagick
The following packages will be upgraded:
  imagemagick
The following packages will NOT be UPGRADED:
  libgdal1i  libssl1.0.2{a}  openssl{a}  xorg  xserver-xorg{a}
  xserver-xorg-core{a} (R: xserver-xorg)  xserver-xorg-input-evdev{a}
  xserver-xorg-input-kbd  xserver-xorg-input-mouse
  xserver-xorg-input-synaptics{a} (S: gpointing-device-settings, S: touchfreeze)
  xserver-xorg-input-vmmouse{a}  xserver-xorg-video-all
  xserver-xorg-video-ati{a}  xserver-xorg-video-cirrus{a}
  xserver-xorg-video-fbdev{a}  xserver-xorg-video-intel{a}
  xserver-xorg-video-mach64{a}  xserver-xorg-video-mga{a}
  xserver-xorg-video-neomagic{a}  xserver-xorg-video-nouveau{a}
  xserver-xorg-video-r128{a}  xserver-xorg-video-radeon{a}
  xserver-xorg-video-savage{a}  xserver-xorg-video-sisusb{a}
  xserver-xorg-video-tdfx  xserver-xorg-video-trident{a}
  xserver-xorg-video-vesa{a}  xserver-xorg-video-vmware{a}
1 packages upgraded, 0 newly installed, 0 to remove and 28 not upgraded.
Need to get 0 B/1,454 B of archives. After unpacking 236 kB will be freed.
Do you want to continue? [Y/n/?]
debconf: unable to initialize frontend: Dialog
debconf: (Dialog frontend will not work on a dumb terminal, an emacs shell 
buffer, or without a controlling terminal.)
debconf: falling back to frontend: Readline
(Reading database ... 180254 files and directories currently installed.)
Preparing to unpack .../imagemagick_8%3a6.9.2.10+dfsg-2_all.deb ...
dpkg-query: no packages found matching imagemagick:all
dpkg-query: package 'imagemagick' is not installed
Use dpkg --info (= dpkg-deb --info) to examine archive files,
and dpkg --contents (= dpkg-deb --contents) to list their contents.
dpkg-query: package 'imagemagick' is not installed
Use dpkg --info (= dpkg-deb --info) to examine archive files,
and dpkg --contents (= dpkg-deb --contents) to list their contents.

Repeats until kill -9

# aptitude search ~U
E: dpkg was interrupted, you must manually run 'dpkg --configure -a' to correct 
the problem.
W: Could not lock the cache file; this usually means that dpkg or another apt 
tool is already installing packages.  Opening in read-only mode; any changes 
you make to the states of packages will NOT be preserved!
Bu  imagemagick


Trying again
aptitude install imagemagick

Reading package lists...
Building dependency tree...
Reading state information...
Reading extended state information...
Initializing package states...
Building tag database...
Couldn't find any package whose name or description matched "imaagemagick"
Couldn't find any package whose name or description matched "imaagemagick"
The following packages will NOT be UPGRADED:
  imagemagick{b} (D: imagemagick-6.q16)  libgdal1i  libssl1.0.2{a}
  openssl{a}  xorg  xserver-xorg{a}
  xserver-xorg-core{a} (R: xserver-xorg)  xserver-xorg-input-evdev{a}
  xserver-xorg-input-kbd  xserver-xorg-input-mouse
  xserver-xorg-input-synaptics{a} (S: gpointing-device-settings, S: touchfreeze)
  xserver-xorg-input-vmmouse{a}  xserver-xorg-video-all
  xserver-xorg-video-ati{a}  xserver-xorg-video-cirrus{a}
  xserver-xorg-video-fbdev{a}  xserver-xorg-video-intel{a}
  xserver-xorg-video-mach64{a}  xserver-xorg-video-mga{a}
  xserver-xorg-video-neomagic{a}  xserver-xorg-video-nouveau{a}
  xserver-xorg-video-r128{a}  xserver-xorg-video-radeon{a}
  xserver-xorg-video-savage{a}  xserver-xorg-video-sisusb{a}
  xserver-xorg-video-tdfx  xserver-xorg-video-trident{a}
  xserver-xorg-video-vesa{a}  xserver-xorg-video-vmware{a}
No packages will be installed, upgraded, or removed.
0 packages upgraded, 0 newly installed, 0 to remove and 29 not upgraded.
Need to get 0 B of archives. After unpacking 0 B will be used.
The following packages have unmet dependencies:
 imagemagick : Depends: imagemagick-6.q16 (= 8:6.9.2.10+dfsg-1) but 
8:6.9.2.10+dfsg-2 is installed.
The following actions will resolve these dependencies:

 Remove the following packages:
1) imagemagick



Accept this solution? [Y/n/q/?] The following actions will resolve these 
dependencies:

 Upgrade the following packages:
1) imagemagick [8:6.9.2.10+dfsg-1 (experimental, now) -> 8:6.9.2.10+dfsg-2 (



Accept this solution? [Y/n/q/?] The following packages will be upgraded:
  imagemagick
The following packages will NOT be UPGRADED:
  libgdal1i  libssl1.0.2{a}  openssl{a}  xorg  xserver-xorg{a}
  xserver-xorg-core{a} (R: xserver-xorg)  xserver-xorg-input-evdev{a}
  xserver-xorg-input-kbd  xserver-xorg-input-mouse
  xserver-xorg-input-synaptics{a} (S: gpointing-device-settings, S: touchfreeze)
  xserver-xorg-input-vmmouse{a}  xserver-xorg-video-all
  xserver-xorg-video-ati{a}  xserver-xorg-video-cirrus{a}
  xserver-xorg-video-fbdev{a}  xserver-xorg-video-intel{a}
  xserver-xorg-video-mach64{a}  xserver-xorg-video-mga{a}
  xserver-xorg-video-neomagic{a}  xserver-xorg-video-nouveau{a}
  xserver-xorg-video-r128{a}  xserver-xorg-video-radeon{a}
  xserver-xorg-video-savage{a}  

Bug#813474: ITP: libhinawa -- I/O library for IEEE 1394 asynchronous

[HAYASHI Kentaro]

Here is the RFS:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=813489


> Also, I've sent RFS against bugs.debian.org to find sponsor.

-- 
haya...@clear-code.com

Bug#813350: joe: :include ignores other commands in the file

[Josip Rodin]

On Mon, Feb 01, 2016 at 01:53:24AM +0100, Adam Borowski wrote:
> /usr/share/doc/joe/README.Debian claims you can ":include /etc/joe/jstarrc"
> to avoid having to copy the entire file and to make it work over upgrades.
> However, doing so seems to ignore the entirety of ~/.jstarrc
> 
> Let's say we want to replace
> -rmsg  %S Row %4r Col %3c %t  Ctrl-J for help
> with
> -rmsg  %S Row %4r Col %3c %A
> 
> The following ~/.jstarrc
> =
> :include /etc/joe/jstarrc
> -rmsg  %S Row %4r Col %3c %A
> =
> makes "Ctrl-J for help" show up instead of the Unicode code.
> 
> so does
> =
> -rmsg  %S Row %4r Col %3c %A
> :include /etc/joe/jstarrc
> =
> so it's not a matter of "first setting stays".

Could this be some sort of a special screwup with regard to jstar, like the
previous bug? Because, I still have the latter config with .joerc and it's
working.

-- 
 2. That which causes joy or happiness.

Bug#813547: iceweasel: Wrong colors in framebuffer Xorg fbdev if enable hardware video acceleration on PowerPC

[Gianluca Renzi]

Package: iceweasel
Version: 44.0-1
Severity: important

Dear Maintainer,

After upgrading sid/experimental the iceweasel acceleration enable feature is 
not working good
if using fbdev xorg configuration with swrast (xinerama setup). It hangs the 
CPU near the 100% and all the colors are in a wrong
RGBA order. Color Swap? Bad RGBA ABGR conversion? This setup is a PowerPC BIG 
ENDIAN machine...

The only way is to use the accelerated video driver (i.e. radeon or nouveau in 
my specific setup)
or
disabling the hardware acceleration feature in the iceweasel preferences section

The biggest issue in this configuration is I am unable to upgrade either kernel 
(due to a binutils bug on PPC64 architecture),
so I can not say for sure if it happens with the 4.4.0 drivers.

Right now I am using the 4.1.0-2 kernel version and the lastest xorg drivers. 
(updated today)


-- Package-specific info:

-- Extensions information
Name: Default theme
Location: 
/usr/lib/iceweasel/browser/extensions/{972ce4c6-7e08-4474-a285-3208198ce6fd}
Package: iceweasel
Status: enabled

Name: Force PDF Download
Location: ${PROFILE_EXTENSIONS}/{d7f46ca0-899d-11da-a72b-0800200c9a65}.xpi
Status: enabled

-- Plugins information
Name: Shockwave Flash
Location: /usr/lib/gnash/libgnashplugin.so
Package: browser-plugin-gnash
Status: enabled


-- Addons package information
ii  browser-plugin 0.8.11~git20 powerpc  GNU Shockwave Flash (SWF) player 
ii  iceweasel  44.0-1   powerpc  Web browser based on Firefox

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

Kernel: Linux 4.1.0-2-powerpc64 (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 iceweasel depends on:
ii  debianutils   4.7
ii  fontconfig2.11.0-6.3
ii  libasound21.1.0-1
ii  libatk1.0-0   2.18.0-1
ii  libatomic15.3.1-7
ii  libc6 2.21-7
ii  libcairo2 1.14.6-1
ii  libdbus-1-3   1.10.6-1
ii  libdbus-glib-1-2  0.106-1
ii  libevent-2.0-52.0.21-stable-2+b1
ii  libffi6   3.2.1-4
ii  libfontconfig12.11.0-6.3
ii  libfreetype6  2.6.1-0.1
ii  libgcc1   1:5.3.1-7
ii  libgdk-pixbuf2.0-02.32.3-1.2
ii  libglib2.0-0  2.46.2-3
ii  libgtk2.0-0   2.24.29-1
ii  libhunspell-1.3-0 1.3.3-3+b2
ii  libnspr4  2:4.11-1
ii  libnss3   2:3.21-1
ii  libpango-1.0-01.38.1-1
ii  libsqlite3-0  3.10.2-1
ii  libstartup-notification0  0.12-4
ii  libstdc++65.3.1-7
ii  libvpx3   1.5.0-2
ii  libx11-6  2:1.6.3-1
ii  libxcomposite11:0.4.4-1
ii  libxdamage1   1:1.1.4-2+b1
ii  libxext6  2:1.3.3-1
ii  libxfixes31:5.0.1-2+b2
ii  libxrender1   1:0.9.9-2
ii  libxt61:1.1.5-1
ii  procps2:3.3.11-3
ii  zlib1g1:1.2.8.dfsg-2+b1

Versions of packages iceweasel recommends:
ii  gstreamer1.0-libav 1:1.6.3-dmo1
ii  gstreamer1.0-plugins-good  1.6.3-1

Versions of packages iceweasel suggests:
ii  fonts-lmodern  2.004.5-1
pn  fonts-stix | otf-stix  
ii  libcanberra0   0.30-2.1
ii  libgnomeui-0   2.24.5-3.1
ii  libgssapi-krb5-2   1.13.2+dfsg-4
pn  mozplugger 

-- no debconf information

Bug#813548: RFS: nfft/3.3.0-5

[Ghislain Vaillant]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

* Package name: nfft
  Version : 3.3.0-5
  Upstream Author : Prof. Dr. Daniel Potts 


* URL :http://www-user.tu-chemnitz.de/~potts/nfft/
* License : GPL-2+
  Section : science

It builds those binary packages:

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


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


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

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

  dget -x 
http://mentors.debian.net/debian/pool/main/n/nfft/nfft_3.3.0-5.dsc


Changes since the last upload:

  * Upload to unstable.
  * d/control:
- use secure VCS-Git URI.
- add missing Testsuite field.
- cme fix, wrap and sort.
  * d/copyright: correct NFFT3 licensing from GPL-2 to GPL-2+.

Best regards,
Ghislain Vaillant

Bug#660787: joe: hardlocks running in mrxvt; had to kill -9 it and then ctrl-c the console tab

[Josip Rodin]

tag 660787 unreproducible
thanks

On Wed, Feb 22, 2012 at 09:28:28AM +0100, Josip Rodin wrote:
> On Tue, Feb 21, 2012 at 04:00:00PM -0500, cvev...@users.sourceforge.net wrote:
> > Package: joe
> > Version: 3.7-2
> > Severity: important
> > 
> > started in mrxvt tab. 
> > after showing  the help, typed a line then attempted to exit.
> > locked solid, kill would not kill w/o -9
> 
> Can you attach a strace -p to the joe PID at some point in the process?
> Is there anything peculiar in your mrxvt configuration? What is $TERM?

Lacking any debug info whatsoever, I'm afraid I'm going to have to mark this
unreproducible. Can you try with the latest joe 4.1?

-- 
 2. That which causes joy or happiness.

Bug#813490: Bug #813490: blacs-mpi: patch for blacs-mpi to build with openmpi1.10

[Michael Banck]

Hi,

the patch is missing a Build-Depends for pkg-config. Note that
debian/control is auto-generated so it needs to be added to
debian/control.in.


Michael

Bug#813549: cobbler: New version available upstream

[Heather Ellsworth]

Package: cobbler
Version: 2.6.11
Severity: wishlist

Dear Maintainer,

Version 2.6.11 is available from https://github.com/cobbler/cobbler.git

Thanks,
Heather Ellsworth

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

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

Bug#813490: Bug #813490: blacs-mpi: patch for blacs-mpi to build with openmpi1.10

[Michael Banck]

On Wed, Feb 03, 2016 at 01:25:46AM +0100, Michael Banck wrote:
> the patch is missing a Build-Depends for pkg-config. Note that
> debian/control is auto-generated so it needs to be added to
> debian/control.in.

And the debian/rules hunk is missing a semicolon at the end.



Michael

Bug#766074: systemd: users should not have to put a value greater than desired in MaxRetentionSec to avoid loss of information

[Michael Biebl]

Control: tags -1 + upstream

Hi

On Mon, 20 Oct 2014 19:33:23 +0200 (CEST) Santiago Vila
> Manual says:
> 
> MaxRetentionSec=
> 
>   The maximum time to store journal entries. This controls whether
>   journal files containing entries older then the specified time
>   span are deleted.
> 
> Ok, but what happens if the specified time is in the middle of a journal file?
> 
> It seems that current behaviour is that as far as a journal file has a
> *single* entry older than the specified time, the entire journal file
> is discarded, including entries which are older than the time limit
> but also entries which are a little bit newer than the time limit.
> 
> We could discuss whether or not this matches the documentation, but in
> my opinion this behaviour is not what one would expect.

Imho the documentation is pretty clear, saying that journal files
containing entries older then MaxRetentionSec are deleted, which can
include newer entries. But sure, the documentation can be more specific
about this aspect.

> I would expect journal files to be discarded only when all of its
> entries have expired, or, at the very minimum, manual should warn the
> user that if he/she wants to keep a whole week of logs, then the value
> of MaxRetentionSec should be greater than a week.

This really is an upstream issue, so it would be great if you can file a
bug at https://github.com/systemd/systemd/issues/new

Regards,
Michael



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



signature.asc
Description: OpenPGP digital signature

Bug#813519: s390/template-arch: set always_halt to false to allow reboots

[Hendrik Brueckner]

Control: tags -1 + patch

>From 6790a25873838a265282bf5e97fa36d21cfebfbc Mon Sep 17 00:00:00 2001
From: Hendrik Brueckner 
Date: Tue, 2 Feb 2016 17:24:09 +0100
Subject: [PATCH] templates-arch: reset always_halt to its default for s390

Remove the s390 specific defaults for always_halt and reset it back
to false.  This allows the installer to boot into the newly installed
Linux instance on System z.

Signed-off-by: Hendrik Brueckner 
---
 debian/changelog  | 8 +++-
 debian/templates-arch | 2 --
 2 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/debian/changelog b/debian/changelog
index 30e64ca..0171f5d 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,8 +1,14 @@
 rootskel (1.114) UNRELEASED; urgency=medium
 
+  [ Colin Watson ]
   * Use HTTPS for Vcs-* URLs, and link to cgit rather than gitweb.
 
- -- Colin Watson   Fri, 29 Jan 2016 13:35:23 +
+  [ Hendrik Brueckner ]
+  * templates-arch: Set always_halt to false for s390 to allow rebooting
+into the newly installed Linux instances.  See also #813506.
+(Closes: #813519)
+
+ -- Hendrik Brueckner   Tue, 02 Feb 2016 
16:40:34 +0100
 
 rootskel (1.113) unstable; urgency=medium
 
diff --git a/debian/templates-arch b/debian/templates-arch
index f90854e..cf3a0e6 100644
--- a/debian/templates-arch
+++ b/debian/templates-arch
@@ -8,8 +8,6 @@ Description: for internal use; can be preseeded
 Template: debian-installer/exit/always_halt
 Type: boolean
 Default: false
-Default[s390]: true
-Default[s390x]: true
 Description: for internal use only
  Always halt the machine
 
-- 
2.7.0.rc3

Bug#813414: osmo: Backup Data creates a 50 Bytes "empty" file

[Christian Buchmüller]

Ok, in the meanwhile backintime will backup the ~/.osmo folder anyway.) Thx
Markus.

On Tue, Feb 2, 2016 at 7:49 PM, Markus Koschany  wrote:

> Control: tags -1 - moreinfo - unreproducible + confirmed
> Control: forwarded -1 https://sourceforge.net/p/osmo-pim/bugs/108/
>
> On Tue, 2 Feb 2016 17:29:53 +0100 Markus Koschany  wrote:
> > Am 02.02.2016 um 11:30 schrieb Christian Buchmüller:
> > > Did what you have suggested.
> > >
> > > Quited osmo
> > > Removed ~/.osmo
> > > Restarted osmo
> > > Added several test data
> > > Backup Data
> > > Restore Data
> > > Everything lost, backup is still a 50 bytes file!
> >
> > Something must be different but unfortunately I have no idea what.
>
> Sorry that I haven't noticed until now that you reported this issue for
> i386. Indeed on i386 I can reproduce this behavior. Forwarded to Osmo's
> issue tracker on sourceforge.net.
>
> Regards,
>
> Markus
>
>
>
>

Bug#812766: RFS: mdk-doc-non-dfsg/1.2.9-1 - initial packaging

[Peter Pentchev]

On Tue, Jan 26, 2016 at 01:55:45PM +0200, Peter Pentchev wrote:
> Package: sponsorship-requests
> Severity: wishlist
> 
> Dear mentors,
> 
> I am looking for a sponsor for my package "mdk-doc-non-dfsg"; it is
> the non-DFSG documentation (GNU Free Documentation License with invariant
> front and back covers) for mdk, the MIX Development Kit.
> 
>  * Package name: mdk-doc-non-dfsg
>Version : 1.2.9-1
>Upstream Author : Jose A. Ortega Ruiz 
>  * URL : http://www.gnu.org/software/mdk/mdk.html
>  * License : GPL-3+
>Section : doc
> 
> It builds a single binary package that has been tested with Lintian and
> sbuild:
> 
>   mdk-doc- Documentation for the MIX Development Kit
> 
> Note that I'm aware that Lintian produces a single pedantic message about
> the watch file checking the upstream PGP signature; well, the watch file
> actually does that, but it uses a line continuation syntax that Lintian
> does not yet understand; I intend to file a bug about that, hopefully along
> with a patch, soon.
> 
> To access further information about this package, please visit the following 
> URL:
> 
>   http://mentors.debian.net/package/mdk-doc-non-dfsg
> 
> Alternatively, one can download the package with dget using this command:
> 
>   dget -x 
> http://mentors.debian.net/debian/pool/non-free/m/mdk-doc-non-dfsg/mdk-doc-non-dfsg_1.2.9-1.dsc
> 
> More information about the MIX Development Kit can be obtained from
> http://www.gnu.org/software/mdk/mdk.html - but the package itself is
> already in Debian, this is just the documentation :)
> 
> Thanks in advance for your time!

OK, I've uploaded a new version of mdk-doc-non-dfsg to mentors.d.n at
the same location with a single major change: declare compliancy with
Debian Policy 3.9.7 and, thus, install the documentation into
/usr/share/doc/mdk/ instead of /usr/share/doc/mdk-doc/ as suggested by
the brand new policy's section 12.3.

Everything else written above still stands.

G'luck,
Peter

-- 
Peter Pentchev  r...@ringlet.net r...@freebsd.org p...@storpool.com
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115  C354 651E EFB0 2527 DF13


signature.asc
Description: PGP signature

Bug#812625: ITA: guitarix -- Rock guitar amplifier for Jack

[Hermann Meyer]

Hi

Thanks Roland for all your work over the years.

Victor, I'm glade you'll take guitarix under the hood of the Multimedia 
Team.


regards
hermann

Bug#807294: golang-go: contains some but not all race-enabled packages

[Tianon Gravi]

> + # On linux/amd64 run.bash installs some race enabled standard library
> + # packages. Delete them again to avoid accidentally including them in
> + # the package.
> + rm -rf "$(GOROOT)/pkg/linux_amd64_race/"

This seems like the most correct solution to me, but I'm a little
confused about why we're hard-coding "linux_amd64" here -- shouldn't
this be "$(GOOS)_$(GOARCH)" so that it's whatever architecture we
build on?  Or perhaps "$(GOROOT)"/pkg/*_race/ ?

♥,
- Tianon
  4096R / B42F 6819 007F 00F8 8E36  4FD4 036A 9C25 BF35 7DD4

Bug#807290: golang: does not respect DEB_BUILD_OPTIONS=nocheck

[Tianon Gravi]

Control: tags -1 + pending

On 6 December 2015 at 22:46, Michael Hudson-Doyle
 wrote:
> The package build always runs the tests, irrespective of DEB_BUILD_OPTIONS. 
> Simple patch attached.

Once again, many thanks.  Patch is applied in Git!

♥,
- Tianon
  4096R / B42F 6819 007F 00F8 8E36  4FD4 036A 9C25 BF35 7DD4

Bug#807303: [pkg-golang-devel] Bug#807303: golang: NEWUSER tests fail on ubuntu (or maybe just new kernel)

[Tianon Gravi]

Control: tags -1 + pending

On 6 December 2015 at 23:37, Michael Hudson-Doyle
 wrote:
> Tests fail in my sid chroot because, on the Ubuntu kernel at least, the tests
> that try to create a new user namespace all fail in a chroot. I fixed this
> upstream but it'd be nice to have this in the 1.5 packaging too so here's a
> backport of the patch.

You've done all the heavy lifting!  This patch is applied in Git, and
will go out with the next upload.  Thanks!

♥,
- Tianon
  4096R / B42F 6819 007F 00F8 8E36  4FD4 036A 9C25 BF35 7DD4

Bug#807455: golang-src: includes race detector runtime files not built from source in the source package

[Tianon Gravi]

On 8 December 2015 at 18:24, Michael Hudson-Doyle
 wrote:
> The files installed as /usr/share/go/src/runtime/race/*.syso are not built
> during package build, but rather come directly from the Go source 
> distribution.
> To ensure that they are built from what they claim to be, in Ubuntu we do not
> distribute these files in the golang-src package but rather build them in a
> separate golang-race-detector-runtime package which golang-go Recommends:. It
> would be nice if Debian could steal this work :-)

I'm definitely keen on this one!

I think my issue with making it happen (last I looked into it) was
that the files in question needed to come from a separate source (LLVM
was it? [1]), and the exact versioning necessary was a little strange,
and it was sources that already exist in the Debian archive for
another package so I wasn't really clear on whether that's kosher or
whether we should be talking to the existing package maintainer to
keep things sane.  Am I remembering this correctly?  I really
should've made some notes after I spent some time playing with this,
sorry. :(

[1]: https://github.com/golang/go/tree/go1.6rc1/src/runtime/race#readme

♥,
- Tianon
  4096R / B42F 6819 007F 00F8 8E36  4FD4 036A 9C25 BF35 7DD4

Bug#807299: golang: build-depends overly broad

[Tianon Gravi]

Control: tags -1 + pending

On 6 December 2015 at 23:32, Michael Hudson-Doyle
 wrote:
> bison hasn't been needed for a long time I think... Some of the others are in 
> build-essential.

#win

Applied in Git!

♥,
- Tianon
  4096R / B42F 6819 007F 00F8 8E36  4FD4 036A 9C25 BF35 7DD4