Bug#840020: entropybroker: FTBFS on sparc64: B2500000+ not declared

[Aaron M. Ucko]

Source: entropybroker
Version: 2.8-1
Severity: important
Justification: fails to build from source

The build of entropybroker for sparc64 (admittedly not a release
architecture) failed:

  server_stream.cpp: In function 'void set_serial_parameters(int, char*)':
  server_stream.cpp:166:10: error: 'B250' was not declared in this scope
  bps = B250;
^~~~
  server_stream.cpp:170:10: error: 'B300' was not declared in this scope
  bps = B300;
^~~~
  server_stream.cpp:174:10: error: 'B350' was not declared in this scope
  bps = B350;
^~~~
  server_stream.cpp:178:10: error: 'B400' was not declared in this scope
  bps = B400;
^~~~

Could you please accommodate these constants' possible absence?

Thanks!

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

Bug#840019: entropybroker: FTBFS (32-bit): 'min(unsigned int, long unsigned int)' -- no match

[Aaron M. Ucko]

Source: entropybroker
Version: 2.8-1
Severity: important
Justification: fails to build from source

Builds of entropybroker for 32-bit architectures that get past #840018
(so, 32-bit x86) fail anyway:

  server_smartcard.cpp:242:52: error: no matching function for call to 
'min(unsigned int, long unsigned int)'
 int n_to_add = std::min(sizeof bytes - index, 8lu);

On these architectures, size_t is technically unsigned int rather than
unsigned long; although those types are de facto equivalent there, C++
formally distinguishes them as a matter of principle.  TTBOMK, the
only portable way to express size_t constants is with a cast:

 int n_to_add = std::min(sizeof bytes - index, (size_t)8);

Could you please take a look?

Thanks!

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

Bug#839594: /proc/iomem requires root privileges (changed in kernel 4.6)

[William L. DeRieux IV]

#...quit
Using debian kernel 3.16.0-4-amd64 (3.16.36-1+deb8u1) -- /proc/iomem can 
be accessed without root.


Added in linux kernel 4.6: /proc/iomem: only expose physical resource 
addresses to privileged users


-
https://bugzilla.redhat.com/show_bug.cgi?id=1370281#c1
This was intentionally changed with

commit 51d7b120418e99d6b3bf8df9eb3cc31e8171dee4
Author: Linus Torvalds 
Date:   Thu Apr 14 12:05:37 2016 -0700

/proc/iomem: only expose physical resource addresses to privileged 
users


In commit c4004b02f8e5b ("x86: remove the kernel code/data/bss 
resources

from /proc/iomem") I was hoping to remove the phyiscal kernel address
data from /proc/iomem entirely, but that had to be reverted because 
some

system programs actually use it.

This limits all the detailed resource information to properly
credentialed users instead.

Signed-off-by: Linus Torvalds 

which was in the 4.6 kernel release.

Bug#835264: (no subject)

[Jeremy Stanley]

An updated package of 2.2 is in the works for sid, and I'm planning
to propose a trivial build-time revision to the 2.0 package suitable
for stable-proposed-updates.

The expanded correlation data format in 2.0 came about as a result
of an earlier change in NWS/NOAA's content hosting, and was aimed at
making it easier for users to work around future disruption on that
scale. The simplest workaround is to either add a section like:

  [default]
  setpath = ~/.weather

...to a ~/.weather/weatherrc file or apt-get purge
weather-util-data, and then create or copy updated correlation data
into your custom setpath, for example:

  mkdir -p ~/.weather
  wget -P $HOME/.weather/ 
http://fungi.yuggoth.org/weather/src/weather/{airports,places,stations,zctas,zones}

After that, weather commands should use your newer correlation data
(note that due to a separate bug fixed in 2.2, you need to either
remove the weather-util-data package or override setpath as above
since the setpath precedence ordering isn't done correctly in 2.1
and earlier).

Bug#840018: entropybroker: FTBFS on non-x86: rdtsc unavailable

[Aaron M. Ucko]

Source: entropybroker
Version: 2.8-1
Severity: important
Justification: fails to build from source

Builds of entropybroker for non-x86 architectures failed due to the
unconditional use of

   asm volatile("rdtsc" : "=a" (a), "=d" (d));

with either

  impossible constraint in 'asm'

or

  unrecognized opcode `rdtsc'

depending on the architecture.

Could you please take a look, and make do without this call where it
is unavailable?

Thanks!

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

Bug#840017: cysignals: FTBFS: unable to load addon sphinxdoc

[Aaron M. Ucko]

Source: cysignals
Version: 1.1.1+ds-1
Severity: serious
Justification: fails to build from source

Builds of cysignals in minimal environments geared for building only
its architecture-dependent binary packages (as on the autobuilders, or
with suitably tuned pbuilder or the like) have been failing:

  dh clean --with autoreconf --with python2,sphinxdoc --buildsystem=pybuild
  dh: unable to load addon sphinxdoc: Can't locate 
Debian/Debhelper/Sequence/sphinxdoc.pm in @INC (you may need to install the 
Debian::Debhelper::Sequence::sphinxdoc module) (@INC contains: [...]) at (eval 
15) line 2.
  BEGIN failed--compilation aborted at (eval 15) line 2.

Please either conditionalize the use of --with sphinxdoc appropriately
or move python-sphinx from Build-Depends-Indep to Build-Depends.

Thanks!

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

Bug#840016: aoflagger: FTBFS on non-x86

[Aaron M. Ucko]

Source: aoflagger
Version: 2.8.0-1
Severity: important
Justification: fails to build from source

Builds of aoflagger for non-x86 architectures have been failing due
to the unconditional use of  and the insufficiently
conditional use of -msse2 (observed on the non-release architecture
sparc64).  Since casacore still FTBFS on most architectures, that
leaves amd64 as the only architecture on which aoflagger successfully
builds.

Could you please take a look and either fix aoflagger to build on a
wider range of architectures (subject to B-D avaiability) or, if
that's infeasible, restrict its Architecture field so the autobuilders
don't waste time on it?

Thanks!

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

Bug#836772: Working solution

[Matthew Orlando]

This works fine for me:

# export GNUPGHOME=/home/soandso/.gnupg
# gpg-agent --allow-loopback-pinentry --daemon
# gpg --clearsign --pinentry-mode=loopback

Hope it helps.

Cogwheel



signature.asc
Description: OpenPGP digital signature

Bug#839993: May be there is a hook, but it does not work

[Alexander Betaev]

Interesting. Is your user shown as active in the current seat? Check
via the `loginctl` command.
Sorry, my fault. It looks like this isGDM3 issue not related to PA. So 
just disregard my message.


--
Best regards,
Alexander Betaev

Bug#839978: exim4: Potential backdoor'ed D-H groups in use by Exim4?

[Andreas Metzler]

Control: forwarded -1 https://bugs.exim.org/show_bug.cgi?id=1895

On 2016-10-07 "Theodore Y. Ts'o"  wrote:
> Source: exim4
> Severity: important
[...]

Bug#840015: opendkim: Relaxed canonicalization of folded headers breaks signatures

[Andreas Schamanek]

Package: opendkim
Version: 2.9.2-2
Severity: important
Tags: patch


OpenDKIM, or more precisely, libopendkim up to 2.10.3 fails to canonicalize
folded mail headers according to the RFC 6376 "relaxed" algorithm when a
header is folded (wrapped) right after the ":" as for instance in

| Subject:\r\n
|long subject text continued on subsequent lines ...

https://tools.ietf.org/html/rfc6376#section-3.4 Section 3.4.2 requires 
that this is canonicalized into

| subject:long subject text continued on subsequent lines ...

but libopendkim produces (note the single space after ":")

| subject: long subject text continued on subsequent lines ...

Hence, DKIM signatures derived from such headers are broken for all 
systems other than OpenDKIM (up to and including 2.10.3), and OpenDKIM
fails to verify valid signatures produced by systems other than 
OpenDKIM.

For the "From:" header this has been reported upstream at

  #226 Bad signature of From:\r\n wrapped field 
  https://sourceforge.net/p/opendkim/bugs/226/

but the bug affects canonicalization in general.

The provided patches are trivial, see DEP-3 patch by A. Schulze at
https://sourceforge.net/p/opendkim/bugs/_discuss/thread/d08319d2/bd34/attachment/ticket226.patch
Quoting thereof for reference:

-- dv-opendkim-2.10.3.orig/libopendkim/dkim-canon.c
+++ dv-opendkim-2.10.3/libopendkim/dkim-canon.c
@@ -388,7 +388,7 @@ dkim_canon_header_string(struct dkim_dst
/* skip all spaces before first word */
-   while (*p != '\0' && DKIM_ISWSP(*p))
+   while (*p != '\0' && DKIM_ISLWSP(*p))
p++;

The patch was applied upstream in opendkim-2.11.0.Alpha0 as of 
2015-10-22.

I was not yet able to assess which or how many mailers produce headers 
that wrap immediately after the header keyword.

However, I want to mention that Debian's default configuration of 
OpenDKIM as in Jessie and Stretch is unfortunately more likely to 
produce invalid signatures due to the fact that headers such as 
"References:" and "In-Reply-To:" which are often wrapped are signed. 
This is a default setting by OpenDKIM left unchanged by Debian, cf. 
opendkim.conf(5) + https://tools.ietf.org/html/rfc6376#section-5.4

So, signers can somewhat mitigate this bug's consequences using 
"OmitHeaders". Receivers, though, need to apply the patch.



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

Versions of packages opendkim depends on:
ii  adduser3.113+nmu3
ii  libbsd00.4.2-1
ii  libc6  2.19-18+deb8u6
ii  libdb5.3   5.3.28-9
ii  libldap-2.4-2  2.4.31-2+deb7u2
ii  liblua5.1-05.1.5-4+deb7u1
ii  libmemcached11 1.0.18-4
ii  libmemcachedutil2  1.0.18-4
ii  libmilter1.0.1 8.14.4-4+deb7u1
ii  libopendbx11.4.6-8
ii  libopendkim9   2.9.2-2
ii  librbl12.9.2-2
ii  libssl1.0.01.0.1t-1+deb8u5
ii  libunbound21.4.17-3+deb7u2
ii  libvbr22.9.2-2
ii  lsb-base   4.1+Debian8+deb7u1

opendkim recommends no packages.

Versions of packages opendkim suggests:
ii  opendkim-tools  2.9.2-2

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

-- no debconf information

Bug#839570: Browserified javascript and DFSG 2 (reopening)

[Joseph R. Justice]

For the record for this bug / discussion:

I note Didier 'OdyX' Raboud 's mail to the Debian Secretary, CC'd to the TC
list and the FTP Master list, requesting a general interpretation of the
TC's ability (if any) to override the decisions made by various Debian
delegate teams and individuals.  A copy of the mail can be found at
https://lists.debian.org/debian-ctte/2016/10/msg00060.html .  If the
request had been made as a bug filed to the bug tracking system, perhaps to
a "secretary" meta-package, I'd have suggested this bug be blocked by that
bug.

(As an aside, perhaps there should be a wishlist bug to create such a
meta-package, for use in similar situations in the future?)

While the request for interpretation was clearly prompted by the discussion
in this bug (indeed, the request explicitly says as much!), it is phrased
to be very general in nature, which I personally think is a good idea.

I look forward to any discussion on that request for interpretation.  (I
suspect I'll have to subscribe to the secretary mailing list, if there is
one such, to make sure I see all of it.)



To all: Should Mr's Raboud's request for interpretation be expanded to
include clarification on whether, and if so when and how, the TC can
require some other delegate to take a particular action or actions, even if
the delegate has not made a decision (or perhaps even been asked to make a
decision) on the action?  (This, presumably if and only if the TC is
capable of overriding a delegate's decision in the first place; if the TC
cannot override a delegate's decision, it does not make sense then that
they could require a delegate to decide to take an action!)

The particular specific case here would be as to whether the TC can require
the release masters to add stretch-ignore tags either to bugs for
individual packages affected by the "browserified Javascript" issue
(whatever it is determined that "browserified Javascript" is ultimately
defined to mean; in particular, I am *not* claiming at this time that the
definition of browserified Javascript does include or should include
packages affected by the includes generated lexer/parser code / jison (?)
issue) and/or for all bugs which fall under this issue (e.g. bugs which are
determined to block a meta-bug "resolution of browserified Javascript"
issue and/or which are determined to be blocked by a "ITP: grunt" or "IT
Create and Package: sufficiently capable replacement for grunt" bug.

I realize that the idea of the TC overriding a delegate's decision *can* be
interpreted to include this sort of thing, too.  However, I do not know if
it is sufficiently obvious that such an interpretation should be made (the
obvious counter-question is "How can the TC override a decision which has
not yet been made, or which has not yet been requested to be made, or which
perhaps is not a request-able decision in the first place (e.g. that there
is no procedure in place to request that such a decision be made)?").

I am tempted to write the secretary to request just such an expanded
consideration of Mr. Raboud's request.  However, before I do so, I think it
is prudent to seek the counsel of older and wiser heads as to whether or
not this is a good idea or if it will instead just confuse things and muddy
the waters.

So...  What, if anything, do all'y'all think?



Thanks for your time.  Hope this is of some use, interest.



Joseph

Bug#840003: [Reportbug-maint] Bug#840003: reportbug: wrong reporting about bug

[Ritesh Raj Sarraf]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On Fri, 2016-10-07 at 08:34 -0400, Sandro Tosi wrote:
> On Fri, Oct 7, 2016 at 8:23 AM, Ritesh Raj Sarraf  wrote:
> > Now, I expected reportbug to fail stating network timeout, with an
> > exception, or maybe a nice relevant message.
> 
> were there actual timeouts/network issues at that time? it could also
> be something on the BTS side

There was an actual power outage affecting my ISP cable modem. My wifi router
was on because it was backed by my UPS.

So, for this bug report, it was an actual network issue.

- -- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System
-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJX99f4AAoJEKY6WKPy4XVpB+IP/2S/T12gpFW7h9KB5/VSKTvc
bXwUDSoJ4J2VeSTYLkgf5CT/nCP8aar6QDyB8ClXRafkMdORbsaRcAQruTDqIvj1
/h7JPBRduwVEtThrxSLDGBi9fg0ccIiTxlf2fW+B3pko8KfPwCoQABLK4pWUV7Dx
WMYuIWKOF7W28Yvcy9xkd8jpm8CiKLRue1k/t1DAc/GD3gKQPoqDjMXOiot8VxPM
Sqog6OSdHkL/Pb37VchSz/+4Gdh7t8YSXxAs22/3gWACzKvWzTxteJqmeBdMz8z3
AUF7o3sHhu0KnVWafO00aWSRscvIiCofxBkckEGmD1EhrBuCIe3Df+21MN1hhsN5
cSRrPnc8rj014dIG/9xwhncNsqOuLy3d/dGfrIQOJ6zwOTqko/PsgyHY+EUtgiGj
0+oRFzetgu5EuF5tBuNuE3Wo9b/EyRSg9Ac0WI/oKpbpW1X7EZZZ9aKxPo33tqIG
JvicBzchtasrlOS4v3py1zPvWyKZSTGgzcuERlncMTw5YQ/+5NEqbDQrbnPd9rk0
P/ULcUZlpNrLJfdLaIPZMbOYW+a0zkwmlJyK/lzWGCuWyndEFueaBu6xnblTCzrH
QUlpfbc/OFspkiok81+j0pIY6JbzoLcJsiu4RN6BC4dfZgUmAxT/Ir4jbYUriGu9
Gt0xusisej0LwCep0MwR
=uyWJ
-END PGP SIGNATURE-

Bug#688760: iceweasel: please enable upstream crash reporting

[Julien Cristau]

On Fri, Oct 7, 2016 at 5:14 PM, Sylvestre Ledru 
wrote:

> Not yet. If I understood correctly, the way firefox   compresses the
> symbol is not managed by breakpad.
> My gut feeling is that the final link might fail with an oom.
> Maybe Julien has more
>
Right, AIUI the missing piece is to upload the symbols from our firefox
builds (and related libraries) to https://crash-stats.mozilla.com/symbols/
so crash reports can be properly analyzed.  I'm working on teaching
breakpad about compressed debug symbols to make that easier.

Cheers,
Julien



> Le 7 oct. 2016 17:09, "Laurent Bigonville"  a écrit :
>
> On Tue, 25 Sep 2012 15:16:48 +0200 Albert Dengg  wrote:
>
> > hi,
>
> Hi,
>
> > i think it would be good to enable upstream crash reporting in the
> > iceweasel build, because even though it is not offically branded, there
> > is quite a userbase with the same builds so that reports and also
> > importing the symbols for this build could be usefull for all parties
> > involved.
>
> Hasn't this be enabled in 49.0-4 ?
>
>
>

Bug#807543: postfix-policyd-spf-python: regex syntax errors in logcheck config

[Rainer Müller]

I can confirm that the logcheck rule is not working. The regex actually
works, which can also be confirmed with logcheck-test when passing the
rule file explicitly:

# logcheck-test -r 
/etc/logcheck/ignore.d.server/postfix-policyd-spf-python.logcheck -l 
/var/log/mail.log
...

However, this rule file is being ignored because it is installed with
this .logcheck suffix. logcheck internally uses 'run-parts --list' to
get the list of rule files, which will not include filenames
containing dots (only [a-zA-Z0-9_-]+ are allowed).

# ls -la /etc/logcheck/ignore.d.server/postfix-policyd-spf-python.logcheck
-rw-r--r-- 1 root root 201 Jun  4  2014 
/etc/logcheck/ignore.d.server/postfix-policyd-spf-python.logcheck
# run-parts --list /etc/logcheck/ignore.d.server |grep 
postfix-policyd-spf-python
#

Please remove the suffix from the file and rename it to
/etc/logcheck/ignore.d.server/postfix-policyd-spf-python

Bug#840014: webcheckout: missing URL sanitization

[Jakub Wilk]

Package: myrepos
Version: 1.20160123
Tags: security

webcheckout passes the extracted URL to "git clone", without any sanitization. 
Malicious website operators or MitM attackers could exploit it for arbitrary 
code execution.


PoC:

 $ webcheckout /path/to/badgit.html
 git clone ext::sh -c cowsay% pwned% >% /dev/tty
 Cloning into 'tty'...
  ___
 < pwned >
  ---
 \   ^__^
  \  (oo)\___
 (__)\   )\/\
 ||w |
 || ||
 fatal: Could not read from remote repository.


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

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

myrepos depends on no packages.

Versions of packages myrepos recommends:
ii  libhtml-parser-perl  3.72-2+b1
ii  libio-pty-easy-perl  0.09-2
ii  libwww-perl  6.15-1
ii  perl 5.24.1~rc3-3

Versions of packages myrepos suggests:
pn  ack-grep  
ii  bzr   2.7.0+bzr6619-2
ii  curl  7.50.1-1
pn  cvs   
pn  darcs 
pn  fossil
ii  git [git-core]1:2.9.3-1
pn  kdesdk-scripts
ii  liburi-perl   1.71-1
ii  mercurial 3.9.1-1
ii  subversion1.9.4-3+b1
pn  subversion-tools  
pn  vcsh  

--
Jakub Wilk
% /dev/tty" />

Bug#840013: bluez: Please announce supported hardware using AppStream

[Petter Reinholdtsen]

Package: bluez
Version: 5.36-1
Severity: wishlist
User: p...@hungry.com
Usertags: appstream-modalias

Hi.

The bluez package is one of the packages in the Debian archive that
should be proposed for installation when a given piece of hardware is
inserted or available.  Thanks to the appstream system, this can now be
announced in a way other tools can use and act on.  I've written the
isenkram system to ask the current user if hardware specific packages
should be installed when a new dongle is installed or already present on
a machine, and isenkram now uses appstream as one source for hardware to
package mappings.

You can read more about this on my blog, 
http://people.skolelinux.org/pere/blog/Using_appstream_with_isenkram_to_install_hardware_related_packages_in_Debian.html
 >.

Instructions on how to create the metadata XML file can be found in
https://wiki.debian.org/AppStream/Guidelines >.

It would be great if you could add an appstream metainfo file to the
bluez package, with content similar to this:

  
  
   [...]
   
lkmodule:bluetooth
   
  


If there are other hardware ids or kernel modules also supported by the
package, please add those too. :)

-- 
Happy hacking
Petter Reinholdtsen

Bug#837930: icedove: Since security update, crashes frequently and randomly

[Guido Günther]

On Fri, Oct 07, 2016 at 11:00:58AM -0500, John Goerzen wrote:
> Hi Guido,
> 
> Where do I find the 45.4?  (For Jessie?)  I'm only seeing it in sid so far.
> 
> Attached is a better-formatted backtrace from 1:45.3.0-1~deb8u1

See the text I put in brackets in the mail:

   chris is about to upload this

so it's not there yet but should be ssonish# (he wanted to get it done
this week). I wrote that since there's little point in trying another
version since upstream will very likely not bother.
Cheers,
 -- Guido

Bug#837930: icedove: Since security update, crashes frequently and randomly

[John Goerzen]

Hi Guido,

Where do I find the 45.4?  (For Jessie?)  I'm only seeing it in sid so far.

Attached is a better-formatted backtrace from 1:45.3.0-1~deb8u1

John

On 10/07/2016 01:02 AM, Guido Günther wrote:

That looks different to others I've seen so far. Could you update to
45.4 (chris is about to upload this) and send a non-line wrapped version
of the trace so I can forward this upstream. Does this happen with any
particular action (startup, when clicking on s.th.) or just random?

Cheers
  -- Guido


Script started on Fri 07 Oct 2016 10:59:06 AM CDT
]0;jgoerzen@minerva: ~jgoerzen@minerva:~$ gdb /usr/bin/icedove core
GNU gdb (Debian 7.7.1+dfsg-5) 7.7.1
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/bin/icedove...Reading symbols from 
/usr/lib/debug//usr/lib/icedove/icedove...done.
done.
[New LWP 18731]
[New LWP 18735]
[New LWP 18743]
[New LWP 18736]
[New LWP 18738]
[New LWP 18739]
[New LWP 18734]
[New LWP 18749]
[New LWP 18762]
[New LWP 18751]
[New LWP 18771]
[New LWP 18755]
[New LWP 18761]
[New LWP 18759]
[New LWP 18944]
[New LWP 18753]
[New LWP 18737]
[New LWP 18754]
[New LWP 18948]
[New LWP 18768]
[New LWP 18775]
[New LWP 18765]
[New LWP 18949]
[New LWP 18767]
[New LWP 18752]
[New LWP 32678]
[New LWP 18801]
[New LWP 18789]
[New LWP 18773]
[New LWP 18744]
[New LWP 18769]
[New LWP 18766]
[New LWP 22336]
[New LWP 10085]
[New LWP 3183]
[New LWP 22072]
[New LWP 32677]
[New LWP 18770]
[New LWP 22075]
[New LWP 18745]
[New LWP 3919]
[New LWP 22010]
[New LWP 18772]
[New LWP 31980]
[New LWP 18750]
[New LWP 22215]
[New LWP 20487]
[New LWP 18742]
[New LWP 18776]
[New LWP 18764]
[New LWP 18748]
[New LWP 18746]
[New LWP 18778]
[New LWP 18774]
[New LWP 18797]
[New LWP 18747]
[New LWP 18784]
[New LWP 4694]
[New LWP 18740]
[New LWP 18760]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `icedove'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x7fa4b3d8779b in raise (sig=11) at 
../nptl/sysdeps/unix/sysv/linux/pt-raise.c:37
37  ../nptl/sysdeps/unix/sysv/linux/pt-raise.c: No such file or directory.
(gdb) bt
#0  0x7fa4b3d8779b in raise (sig=11) at 
../nptl/sysdeps/unix/sysv/linux/pt-raise.c:37
#1  0x7fa4ae37bca1 in nsProfileLock::FatalSignalHandler (signo=11, 
info=0x7ffcccf4e830, context=0x7ffcccf4e700) at 
/build/icedove-W7xjY6/icedove-45.3.0/mozilla/toolkit/profile/nsProfileLock.cpp:185
#2  0x7fa4aec56cb6 in AsmJSFaultHandler (signum=, 
info=, context=0x7ffcccf4e700) at 
/build/icedove-W7xjY6/icedove-45.3.0/mozilla/js/src/asmjs/AsmJSSignalHandlers.cpp:1161
#3  
#4  XPCWrappedNativeProto::Mark (this=0x0) at 
/build/icedove-W7xjY6/icedove-45.3.0/mozilla/js/xpconnect/src/xpcprivate.h:1897
#5  0x7fa4acf4f405 in XPCWrappedNativeScope::MarkAllWrappedNativesAndProtos 
() at 
/build/icedove-W7xjY6/icedove-45.3.0/mozilla/js/xpconnect/src/XPCWrappedNativeScope.cpp:566
#6  0x7fa4acf2fc37 in XPCJSRuntime::FinalizeCallback (fop=, 
status=, isCompartmentGC=, data=) 
at 
/build/icedove-W7xjY6/icedove-45.3.0/mozilla/js/xpconnect/src/XPCJSRuntime.cpp:756
#7  0x7fa4ae96c55a in js::gc::GCRuntime::callFinalizeCallbacks 
(this=this@entry=0x7fa4a13923f8, fop=fop@entry=0x7ffcccf4edf0, 
status=status@entry=JSFINALIZE_COLLECTION_END) at 
/build/icedove-W7xjY6/icedove-45.3.0/mozilla/js/src/jsgc.cpp:1651
#8  0x7fa4ae97a95d in js::gc::GCRuntime::endSweepPhase 
(this=this@entry=0x7fa4a13923f8, 
destroyingRuntime=destroyingRuntime@entry=false) at 
/build/icedove-W7xjY6/icedove-45.3.0/mozilla/js/src/jsgc.cpp:5557
#9  0x7fa4ae988633 in js::gc::GCRuntime::incrementalCollectSlice 
(this=this@entry=0x7fa4a13923f8, budget=..., 
reason=reason@entry=JS::gcreason::INTER_SLICE_GC) at 
/build/icedove-W7xjY6/icedove-45.3.0/mozilla/js/src/jsgc.cpp:6089
#10 0x7fa4ae98924a in js::gc::GCRuntime::gcCycle 
(this=this@entry=0x7fa4a13923f8, 
nonincrementalByAPI=nonincrementalByAPI@entry=false, budget=..., 
reason=reason@entry=JS::gcreason::INTER_SLICE_GC)
at /build/icedove-W7xjY6/icedove-45.3.0/mozilla/js/src/jsgc.cpp:6278
#11 0x7fa4ae9896a5 in js::gc::GCRuntime::collect 
(this=this@entry=0x7fa4a13923f8, 
nonincrementalByAPI=nonincrementalByAPI@entry=false, budget=..., 
reason=reason@entry=JS::gcreason::INTER_SLICE_GC)
at 

Bug#839222: evolution: Not white, but displays garbage pixels

[Christopher Sasarak]

Package: evolution
Version: 3.22.0-2
Followup-For: Bug #839222

Dear Maintainer,

Evolution doesn't crash, but in the preview message pane I get garbage.
Additionally, I get the same thing when I try to open the message in a
new window. Sometimes when I click to another message the garbage pixels
change. It's still garbage, but it looks like it's trying to display the
message. 

When I open the program in a terminal I get these error messages:
** (evolution:2883): WARNING **: Couldn't register with accessibility
bus: Did not receive a reply. Possible causes include: the remote
application did not send a reply, the message bus security policy
blocked the reply, the reply timeout expired, or the network connection
was broken.
OpenGL Warning: crPixelCopy3D:  simply crMemcpy'ing from srcPtr to
dstPtr

** (evolution-alarm-notify:2897): WARNING **: Couldn't register with
accessibility bus: Did not receive a reply. Possible causes include: the
remote application did not send a reply, the message bus security policy
blocked the reply, the reply timeout expired, or the network connection
was broken.

** (WebKitWebProcess:2936): WARNING **: Couldn't register with
accessibility bus: Did not receive a reply. Possible causes include: the
remote application did not send a reply, the message bus security policy
blocked the reply, the reply timeout expired, or the network connection
was broken.

(evolution:2883): Gdk-CRITICAL **: gdk_window_get_window_type: assertion
'GDK_IS_WINDOW (window)' failed

which leads me to suspect the problem is with libwebkitgtk2-4.0, but I'm
not sure. I also get similar bad behavior when I open a browser which
uses that webkit library like epiphany, but not  midori which depends on
an earlier version.

I tried going into the settings and setting Evolution to only ever show
messages at plaintext, but this didn't fix the problem either. 

Occasionally Evolution won't start and I get this error in addition to 
the others:
(evolution:3925): Gdk-ERROR **: The program 'evolution' received an X
Window System error.  This probably reflects a bug in the program.
The error was 'BadDrawable (invalid Pixmap or Window parameter)'.
(Details: serial 1463 error_code 9 request_code 143 (DAMAGE) minor_code 1)
(Note to programmers: normally, X errors are reported
asynchronously; that is, you will receive the error a while after causing it.
To debug your program, run it with the GDK_SYNCHRONIZE
environment variable to change this behavior. You can then get a meaningful
backtrace from your debugger if you break on the gdk_x_error() function.)
fish: “evolution” terminated by signal SIGTRAP (Trace or breakpoint trap)

But am not sure that it's related.

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

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

Versions of packages evolution depends on:
ii  dbus   1.10.10-1
ii  evolution-common   3.22.0-2
ii  evolution-data-server  3.22.0-2
ii  libc6  2.24-3
ii  libcamel-1.2-593.22.0-2
ii  libclutter-gtk-1.0-0   1.8.2-1
ii  libecal-1.2-19 3.22.0-2
ii  libedataserver-1.2-22  3.22.0-2
ii  libevolution   3.22.0-2
ii  libglib2.0-0   2.50.0-2
ii  libgtk-3-0 3.22.1-1
ii  libical2   2.0.0-0.5+b1
ii  libicu57   57.1-4
ii  libnotify4 0.7.6-2
ii  libsoup2.4-1   2.56.0-1
ii  libwebkit2gtk-4.0-37   2.14.0-1
ii  libxml22.9.4+dfsg1-2
ii  psmisc 22.21-2.1+b1

Versions of packages evolution recommends:
ii  bogofilter 1.2.4+dfsg1-8
ii  evolution-plugins  3.22.0-2
ii  yelp   3.22.0-1

Versions of packages evolution suggests:
ii  evolution-ews   3.22.0-2
pn  evolution-plugins-experimental  
ii  gnupg   2.1.15-3
ii  network-manager 1.4.2-1

-- debconf information:
  evolution/needs_shutdown:
  evolution/kill_processes:

Bug#840012: nagios-nrpe-server: post install does not allow upgrading for people not using it as a daemon

[rui]

Package: nagios-nrpe-server
Version: 2.15-1+b1
Severity: normal

Dear Maintainer,

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

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

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


When upgrading from Jessie to Stretch, at the end of dist-upgrade, it
ends with an error:

Errors were encountered while processing:
 nagios-nrpe-server
  E: Sub-process /usr/bin/dpkg returned an error code (1)

To finish installing nagios-nrpe-server, I ended up verifying the
post-install scripts.

At nagios-nrpe-server.postinst:

#!/bin/sh
set -e
# Automatically added by dh_installinit
if [ -x "/etc/init.d/nagios-nrpe-server" ]; then
update-rc.d nagios-nrpe-server defaults >/dev/null
invoke-rc.d nagios-nrpe-server start || exit $?
fi


As I have nagios-nrpe being invoked by (x)inetd and not running
as a daemon, it failed startup and thus the apt dist-upgrade
error.

I do not recommend activating the service for boot and starting it, as
the service can also be started on non daemon-mode.

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

Kernel: Linux 4.7.0-0.bpo.1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=UTF-8 (charmap=UTF-8) (ignored: LC_ALL set 
to en_US.utf8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages nagios-nrpe-server depends on:
ii  adduser  3.115
ii  libc62.24-3
ii  libssl1.0.2  1.0.2j-1
ii  libwrap0 7.6.q-25
ii  lsb-base 9.20160629

Versions of packages nagios-nrpe-server recommends:
ii  nagios-plugins2.1.2-2
ii  nagios-plugins-basic  2.1.2-2

nagios-nrpe-server suggests no packages.

-- Configuration Files:
/etc/default/nagios-nrpe-server changed [not included]
/etc/nagios/nrpe.cfg changed [not included]

-- no debconf information

Bug#839898: Acknowledgement (libopenblas-base: Segmentation fault on calling expm() from Octave with libopenblas-base)

[Sébastien Villemot]

Control: tags -1 + moreinfo

Dear David,

Le jeudi 06 octobre 2016 à 09:01 +, David Lindelöf a écrit :
> Here is how to reproduce the issue. From Octave, run

> load crashexpm
> expm([[a b]*t; zeros(nb,n+nb)])

I can't replicate your problem on my system. This may be due to the fact
that I have a different CPU from yours: OpenBLAS has a different kernel
for each microarchitecture, and the bug you encountered is probably
specific to yours.

Here are a few inquiries:

- if you have access to a Debian unstable system on the same hardware,
are you still able to replicate the bug? Debian unstable has a more
recent version of OpenBLAS (0.2.19), which may already contain a bugfix.
If you don't have a Debian unstable system, you can create one inside a
chroot (see https://wiki.debian.org/chroot for some explanations)

- I need to know which OpenBLAS kernel you are using. The easiest way of
figuring it is to install the "julia" package, then run "julia" at the
shell prompt, and then type "versioninfo()" at the julia prompt. Then
copy/paste the output

- is it possible to have a backtrace of the crash? Please install the
octave-dbg package (unfortunately there is no debug package for OpenBLAS
in Debian jessie). Then run octave from gdb, and get a backtrace. See
https://wiki.debian.org/HowToGetABacktrace for more details (note: the
part on automatic debug packages only applies to Debian unstable, not to
Debian jessie)

Best,

-- 
 .''`.Sébastien Villemot
: :' :Debian Developer
`. `' http://sebastien.villemot.name
  `-  GPG Key: 4096R/381A7594

Bug#769158: [Packaging] Bug#769158: munin, munin-node: fails to upgrade from 'sid' - trying to overwrite /usr/share/man/man5/munin.conf.5.gz

[Holger Levsen]

Hi Andreas,

On Thu, Oct 06, 2016 at 10:38:45AM +0200, Andreas Beckmann wrote:
> Followup-For: Bug #769158
> Control: found -1 2.999.3-1
> and now we have even more overwrite conflicts (without
> guarantee on completeness):

hmpf. where do you see those?
https://piuparts.debian.org/sid2experimental/source/m/munin.html looks
sunny and well…


-- 
cheers,
Holger


signature.asc
Description: Digital signature

Bug#836686: fixed upstream

[Gianfranco Costamagna]

control: tags -1 patch
Hi,
> 
> hedgewars build-depends on dataenc, which has been deprecated in favor
> of sandi[0].  dataenc is broken with GHC 8, which should mean that
> upstream hedgewars already won't build with GHC 8.  I imagine that
> switching to sandi will make everyone happy.
> 

fixed upstream, can upload if the transition is starting

http://hg.hedgewars.org/hedgewars/rev/ad435d95ca4b

G.

> [0] https://hackage.haskell.org/package/dataenc
> 
> 

Bug#839987: libcompress-raw-lzma-perl: Version Mismatch due to new src:xz-utils

[gregor herrmann]

Control: tag -1 + confirmed

On Fri, 07 Oct 2016 09:56:28 +0300, Niko Tyni wrote:

> As noticed by the autopkgtest checks at ci.debian.net, this library
> can't be used on current sid/amd64 anymore.
> 
>   # perl -e 'use Compress::Raw::Lzma'
>   Subroutine Compress::Raw::Lzma::constant redefined at 
> /usr/lib/x86_64-linux-gnu/perl5/5.24/Compress/Raw/Lzma.pm line 165.
>   Subroutine Compress::Raw::Lzma::lzma_version_number redefined at 
> /usr/lib/x86_64-linux-gnu/perl5/5.24/Compress/Raw/Lzma.pm line 165.
> [...]
>   Subroutine Compress::Raw::Lzma::Options::DESTROY redefined at 
> /usr/lib/x86_64-linux-gnu/perl5/5.24/Compress/Raw/Lzma.pm line 165.
>   Version Mismatch - Built with version 5001, library used is version 
> 50020022
>   Compilation failed in require at -e line 1.
>   BEGIN failed--compilation aborted at -e line 1.
>  
> This is clearly caused by the new liblzma5 (src:xz-utils) in sid. We seem
> to need either tighter (preferably binNMU-safe) versioned dependencies
> or disabling the version check.

I tend to disabling the version check. liblzma5 has a proper symbols
file which is used by dh_shlibdeps/dpkg-shlibdeps, so we should be
safe, I guess.
 
> Not sure what triggered all the warnings but it's presumably related.

Probably ...

eval {
require XSLoader;
XSLoader::load('Compress::Raw::Lzma', $XS_VERSION);
1;
} 
or do {
require DynaLoader; 
local @ISA = qw(DynaLoader);
bootstrap Compress::Raw::Lzma $XS_VERSION ; # ← line 165
};


Cheers,
gregor

-- 
 .''`.  Homepage https://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06
 : :' : Debian GNU/Linux user, admin, and developer -  https://www.debian.org/
 `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   NP: Mark Knopfler: Silvertown Blues


signature.asc
Description: Digital Signature

Bug#840000: libapache-mod-jk: CVE-2016-6808

[Markus Koschany]

Looks like Apache is not affected. [1] I guess  would be
justified here.

Markus


[1]
https://mail-archives.apache.org/mod_mbox/tomcat-users/201610.mbox/%3CCABzHfVmjt6oRKZfETgrP22wX%3DMF%2BSZsYDw2mAJkmhwcHDt0T3Q%40mail.gmail.com%3E



signature.asc
Description: OpenPGP digital signature

Bug#824449: mmap with MAP_FIXED

[Djalal Harouni]

Hi,

Sending this dump bad map_fixed one that can be combined with other flags
MAP_ANONYMOUS... be useful on Linux ?  Adrian asked.

link: https://gist.github.com/tixxdz/301158c64cdcdd0b976891579ce52609


$ ./a.out
0x7f2995bb9000 0x700 0x6fff000 0x6ffe000 0x6ffd000
0x6ffc000 0x7f29955fc000
#include 
#include 
#include 
#include 

/* MAP_FIXED is bad... map a big ANONYMOUS and let MAP_FIXED reclame it... */

/* This is wrong and was written quickly it ignores linux mmap_min_addr
 * addresses and plenty of bugs ... */
static void *mmap_hint(void *base_addr) {
unsigned offset = 0;
static void *addr = NULL;
static void *up = NULL;
static unsigned long psize = 0;

if (!psize)
psize = getpagesize();

if ((void *)base_addr != NULL) {
if (!addr) {
addr = base_addr;
offset = 0;
up = base_addr;
} else if (up) {
if ((unsigned long)base_addr > (unsigned long)up) {
errno = -EINVAL;
return  MAP_FAILED;
}

offset += psize;
} else {
errno = -EINVAL;
return MAP_FAILED;
}

addr -= offset;
addr = (void *)((unsigned long)addr & ~(psize - 1));
goto mmap_call;
}

addr = NULL;

/* MAP_FIXED is bad... */
mmap_call:
return mmap(addr, psize, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS | MAP_FIXED, -1, 0);
}

int main(void)
{
void *ptr1, *ptr2, *ptr3, *ptr4, *ptr5, *ptr6, *ptr7;
ptr1 = mmap(NULL, 1024*1024, PROT_READ | PROT_WRITE, MAP_SHARED | MAP_ANONYMOUS, -1, 0);
ptr2 = mmap_hint((void *)0x0700ULL);
ptr3 = mmap_hint((void *)0x0700ULL);
ptr4 = mmap_hint((void *)0x0700ULL);
ptr5 = mmap_hint((void *)0x0700ULL);
ptr6 = mmap_hint((void *)0x0700ULL);
ptr7 = mmap(NULL, 1024*1024, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
printf("%p %p %p %p %p %p %p\n", ptr1, ptr2, ptr3, ptr4, ptr5, ptr6, ptr7);
}

Bug#840011: RFS (on ITP): node-typescript/2.0.5-1

[Julien Puydt]

Package: sponsorship-requests
Severity: wishlist

  Dear mentors,

  I am looking for a sponsor for my package "node-typescript"

 * Package name: node-typescript
   Version : 2.0.5-1
   Upstream Author : Microsoft Corp.
 * URL : http://typescriptlang.org/
 * License : Apache-2.0
   Section : web

  It builds those binary packages:

node-typescript - TypeScript is a language for application scale 
JavaScript develop


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


  https://mentors.debian.net/package/node-typescript


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

dget -x 
https://mentors.debian.net/debian/pool/main/n/node-typescript/node-typescript_2.0.5-1.dsc


  It is packaged within the Debian Javascript Maintainers' repository:
Vcs-Git: https://anonscm.debian.org/git/pkg-javascript/node-typescript.git
Vcs-Browser: 
https://anonscm.debian.org/cgit/pkg-javascript/node-typescript.git


 It is a new build-depend of my node-esprima package.

 Cheers,

Snark on #debian-js

Bug#839985: bluetooth: cannot receive files from android 5.1.1 / no obvious idea how to send

[Fulano Diego Perez]

this is logs when trying to receive file:

Oct 08 02:23:23 local obexd[26073]: CONNECT(0x0), (null)(0x)
Oct 08 02:23:23 local obexd[26073]: CONNECT(0x0), (null)(0x0)
Oct 08 02:23:23 local obexd[26073]: PUT(0x2), (null)(0x)
Oct 08 02:23:23 local obexd[26073]: PUT(0x2), FORBIDDEN(0x43)
Oct 08 02:23:23 local obexd[26073]: DISCONNECT(0x1), (null)(0x)
Oct 08 02:23:23 local obexd[26073]: DISCONNECT(0x1), SUCCESS(0x20)
Oct 08 02:23:23 local obexd[26073]: disconnected: Transport got disconnected
Oct 08 02:23:23 local bluetoothd[23051]: Unable to get io data for
Object Push: getpeername: Transport endpoint is not connected (107)


eventually i could send to the phone - i had to change phone settings

Bug#822434: patch for building 8.0.27-1, based on 7.5.18-2

[lumin]

On Thu, 2016-09-29 at 18:51 +0200, Andreas Beckmann wrote:
> OK, I've updated the rules to download and repack the sources, so
> that
> all of us can start working with the same tarballs :-)

I downloaded the tarball, and I may hopefully finish the patchset
within a week or two. Is this acceptable for Ubuntu freeze exception?
And what about the Debian Stretch freeze?

Bug#839667: Addition to the bug report

[Jann Haber]

It sounds exactly like the bug described here for Kernel 4.1.28:
http://lkml.iu.edu/hypermail/linux/kernel/1607.1/05446.html

Is it possible, that this bug has been backported to the current Debian
stable kernel?

Bug#832584: elfutils: diff for NMU version 0.166-2.1

[James Clarke]

Control: tags 832584 + pending

Dear maintainer,

I've prepared an NMU for elfutils (versioned as 0.166-2.1) and
uploaded it to DELAYED/10. Please feel free to tell me if I
should delay it longer.

Regards,
James
diff -Nru elfutils-0.166/debian/changelog elfutils-0.166/debian/changelog
--- elfutils-0.166/debian/changelog 2016-07-23 17:46:33.0 +0100
+++ elfutils-0.166/debian/changelog 2016-10-07 15:16:12.0 +0100
@@ -1,3 +1,10 @@
+elfutils (0.166-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Build-Depend on gcc-multilib and libc6-dbg on sparc64 (Closes: #832584)
+
+ -- James Clarke   Fri, 07 Oct 2016 15:16:09 +0100
+
 elfutils (0.166-2) unstable; urgency=medium
 
   * Actually add ignore_strmerge.diff to the patch series.
diff -Nru elfutils-0.166/debian/control elfutils-0.166/debian/control
--- elfutils-0.166/debian/control   2016-07-23 16:24:56.0 +0100
+++ elfutils-0.166/debian/control   2016-10-07 15:16:00.0 +0100
@@ -1,7 +1,7 @@
 Source: elfutils
 Priority: optional
 Maintainer: Kurt Roeckx 
-Build-Depends: debhelper (>= 9), autotools-dev, autoconf, automake, bzip2, 
zlib1g-dev, libbz2-dev, liblzma-dev, m4, gettext, autoconf, automake, gawk, 
dpkg-dev (>= 1.16.1~), gcc-multilib [any-amd64], libc6-dbg [powerpc powerpcspe 
ppc64 ppc64el armel armhf arm64], flex, bison
+Build-Depends: debhelper (>= 9), autotools-dev, autoconf, automake, bzip2, 
zlib1g-dev, libbz2-dev, liblzma-dev, m4, gettext, autoconf, automake, gawk, 
dpkg-dev (>= 1.16.1~), gcc-multilib [any-amd64 sparc64], libc6-dbg [powerpc 
powerpcspe ppc64 ppc64el armel armhf arm64 sparc64], flex, bison
 Build-Conflicts: autoconf2.13, automake1.4
 Standards-Version: 3.9.8
 Section: libs

Bug#688760: iceweasel: please enable upstream crash reporting

[Sylvestre Ledru]

Not yet. If I understood correctly, the way firefox   compresses the symbol
is not managed by breakpad.
My gut feeling is that the final link might fail with an oom.
Maybe Julien has more

Le 7 oct. 2016 17:09, "Laurent Bigonville"  a écrit :

On Tue, 25 Sep 2012 15:16:48 +0200 Albert Dengg  wrote:

> hi,

Hi,

> i think it would be good to enable upstream crash reporting in the
> iceweasel build, because even though it is not offically branded, there
> is quite a userbase with the same builds so that reports and also
> importing the symbols for this build could be usefull for all parties
> involved.

Hasn't this be enabled in 49.0-4 ?

Bug#838242: transition: imagemagick

[roucaries bastien]

I have tried and it seems so.

Due to perl transition I get some transient problem but it seems ok,
except package only available under unstable

On Wed, Sep 21, 2016 at 10:43 PM, Emilio Pozuelo Monfort
 wrote:
> user release.debian@packages.debian.org
> usertags 838242 transition
> thanks
>
> On 18/09/16 23:08, Bastien ROUCARIÈS wrote:
>> Package: release.debian.org
>> Severity: normal
>
> Please use reportbug next time, you missed the appropriate usertags.
>
>>
>> Hi,
>>
>> imagemagick waiting in NEWs (8:6.9.5.9+dfsg-1) will need a transition to
>> experimental to unstable;
>>
>> Next stable version need to be based on this version from a security point of
>> view. It fix more than 50 securities bugs..;
>>
>> Moreover this version use autopkg test improving the quality of testing.
>
> Did you try to rebuild all the rdeps?
>
> Cheers,
> Emilio

Bug#839867: pygtk: diff for NMU version 2.24.0-5.1

[James Clarke]

Control: tags 839867 + pending

Dear maintainer,

I've prepared an NMU for pygtk (versioned as 2.24.0-5.1) and
uploaded it directly (as agreed with pochu on IRC).

Regards,
James
diff -Nru pygtk-2.24.0/debian/changelog pygtk-2.24.0/debian/changelog
--- pygtk-2.24.0/debian/changelog   2016-07-22 18:24:42.0 +0100
+++ pygtk-2.24.0/debian/changelog   2016-10-07 14:49:52.0 +0100
@@ -1,3 +1,11 @@
+pygtk (2.24.0-5.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * 05_Fix_GdkColor_pixel_parse.patch: Fix bus error on sparc64.
+Closes: #839867.
+
+ -- James Clarke   Fri, 07 Oct 2016 14:49:35 +0100
+
 pygtk (2.24.0-5) unstable; urgency=medium
 
   * Add build-indep and build-arch targets. Closes: #831945.
diff -Nru pygtk-2.24.0/debian/patches/05_Fix_GdkColor_pixel_parse.patch 
pygtk-2.24.0/debian/patches/05_Fix_GdkColor_pixel_parse.patch
--- pygtk-2.24.0/debian/patches/05_Fix_GdkColor_pixel_parse.patch   
1970-01-01 01:00:00.0 +0100
+++ pygtk-2.24.0/debian/patches/05_Fix_GdkColor_pixel_parse.patch   
2016-10-07 14:46:42.0 +0100
@@ -0,0 +1,31 @@
+Description: Fix bus error on sparc64
+ Since GdkColor.pixel is a guint32, but "k" in the format string means unsigned
+ long, a temporary local needs to be used to get the right alignment and size
+ on platforms where unsigned long is not 32-bit.
+Author: James Clarke 
+Bug-Debian: https://bugs.debian.org/839867
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+Index: pygtk-2.24.0/gtk/gdkcolor.override
+===
+--- pygtk-2.24.0.orig/gtk/gdkcolor.override
 pygtk-2.24.0/gtk/gdkcolor.override
+@@ -33,6 +33,7 @@ _wrap_gdk_color_new(PyGBoxed *self,
+ static char *kwlist1[] = {"red", "green", "blue", "pixel", NULL };
+ static char *kwlist2[] = { "spec", NULL };
+ PyObject *red = Py_None, *green = Py_None, *blue = Py_None;
++unsigned long pixel;
+ const char *spec = NULL;
+ GdkColor colour;
+ 
+@@ -56,7 +57,9 @@ _wrap_gdk_color_new(PyGBoxed *self,
+ PyErr_Clear();
+ 
+ if (PyArg_ParseTupleAndKeywords(args, kwargs, "|OOOk:gdk.Color", kwlist1,
+-, , , )) {
++, , , )) {
++colour.pixel = pixel;
++
+ /* We don't allow mixing floats and non-floats as that is too
+  * error-prone.  All non-floats are deemed integers in case
+  * they have __int__() method. */
diff -Nru pygtk-2.24.0/debian/patches/series pygtk-2.24.0/debian/patches/series
--- pygtk-2.24.0/debian/patches/series  2015-02-07 04:49:14.0 +
+++ pygtk-2.24.0/debian/patches/series  2016-10-07 14:36:11.0 +0100
@@ -1,3 +1,4 @@
 01_pygtk-demo.patch
 03_testsuite_filechooser.patch
 04_Fix_leaks_of_Pango_objects.patch
+05_Fix_GdkColor_pixel_parse.patch

Bug#840010: Bug applies to contributors.debian.org

[Dieter Adriaenssens]

Control: summary -1 contributors.debian.org: Urls to git repo are incorrect

To clarify, this bugreport applies to the contributors.debian.org website.

The fix applies to the nm/dc.git repo

Kind regards,
Dieter

Bug#770458: does this actually work

[Alex Georgiev]

Hello, I don't know if that's offtopic but I tried the suggested service
file and I got

|root@ubuntu-512mb-ams3-01:/etc/systemd/system# sctl status
myapp.service ●myapp.service -myapp xsp4 WebAPI2Loaded:loaded
(/etc/systemd/system/myapp.service;disabled;vendor
preset:enabled)Active:inactive
(dead)Oct0714:32:00ubuntu-512mb-ams3-01systemd[1]:myapp.service:Startrequest
repeated too
quickly.Oct0714:32:00ubuntu-512mb-ams3-01systemd[1]:Failedto start
myapp xsp4
WebAPI2.Oct0714:59:12ubuntu-512mb-ams3-01systemd[1]:Stoppedmyapp
xsp4
WebAPI2.Oct0714:59:16ubuntu-512mb-ams3-01systemd[1]:Startedmyapp
xsp4 WebAPI2.Oct0714:59:19ubuntu-512mb-ams3-01xsp4[26490]:xsp4
Oct0714:59:19ubuntu-512mb-ams3-01xsp4[26490]:Listeningon

address:127.0.0.1Oct0714:59:19ubuntu-512mb-ams3-01xsp4[26490]:Rootdirectory:/var/www/myapp.com/server
Oct0714:59:19ubuntu-512mb-ams3-01xsp4[26490]:Listeningon

port:9000(non-secure)Oct0714:59:19ubuntu-512mb-ams3-01xsp4[26490]:HitReturnto
stop the

server.Oct0714:59:19ubuntu-512mb-ams3-01xsp4[26490]:[0x7f24851e9700:]EXCEPTION
handling:System.Threading.ThreadAbortException:|


signature.asc
Description: OpenPGP digital signature

Bug#755415: ITA: gexiv2 -- GObject-based wrapper around the Exiv2 library

[Jason Crain]

On Tue, Oct 04, 2016 at 12:04:39PM +0200, Luca Falavigna wrote:
> Hi Jason,
> 
> 2016-10-03 13:23 GMT+02:00 Jason Crain :
> > I would like to adopt gexiv2.  I've done a bit of work already for
> > packaging the new version and I plan on uploading it to collab-maint
> > soon.  I'll need a sponsor though.  Would you be willing to sponser it?
> 
> Great!
> Feel free to ping me when ready, I'll be glad to sponsor it.

I've uploaded the package to mentors.  I'm a little bit nervous about
upstream's changes to gexiv2.vapi.  The new version removes some things
about streams and a log hander, but I don't know enough about vala to
know if that's a problem, or whether anything in Debian uses the vala
bindings.

* Package name: gexiv2
  Version : 0.10.4-1
  Upstream Author : Jens Georg 
* URL : https://wiki.gnome.org/Projects/gexiv2
* License : GPL-2+
  Section : libs

It builds those binary packages:

gir1.2-gexiv2-0.10 - GObject-based wrapper around the Exiv2 library - 
introspection da
libgexiv2-2 - GObject-based wrapper around the Exiv2 library
libgexiv2-dev - GObject-based wrapper around the Exiv2 library - development 
file

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/g/gexiv2/gexiv2_0.10.4-1.dsc

More information about gexiv2 can be obtained from 
https://wiki.gnome.org/Projects/gexiv2.

Changes since the last upload:

  * New upstream version 0.10.4
  * Make compile warnings nonfatal.  Add --disable-Werror to debian/rules
override_dh_auto_configure.
  * Add fix-typelib-install-directory.patch from upstream.  The .typelib files
were being installed in $(datadir)/gir-1.0.  This patch moves them to the
correct location $(libdir)/girepository-1.0.
  * Add always-install-vapi-file.patch from upstream.  The .vapi file was only
being installed when valac was present.  This patch causes the pre-built
vapi file to be used when valac is not available.
  * Update to standards version 3.9.8
  * Switch to automatic dbgsym packages
  * Move from debhelper 9 to 10
- Remove --parallel and --with autoreconf, they're default now
  * Enable hardening flags.  Add DEB_BUILD_MAINT_OPTIONS = hardening=+all.
  * Add linker flags -Wl,-z,defs -Wl,-O1 -Wl,--as-needed
  * Remove shlibs:Depends for gir1.2-gexiv2-0.10.  There's no use for it when
the package only contains python and typelib files and it causes a warning
message.
  * Update debian/copyright.
- Upstream has assigned copyright to SFC.
- Add copyright of several new m4 macros.
- Add comment clarifying origin of gexiv2-managed-stream.h.
  * Add debian/upstream/metadata
  * Remove Build-Depends on libtool-bin.  It's no longer necessary since
upstream fixed their call to g-ir-scanner in
https://bugzilla.gnome.org/765827.
  * Add debian/control VCS fields
  * Update debian/libgexiv2-2.symbols.
  * New maintainer (Closes: #755415)

 Regards,
  Jason Crain

Bug#688760: iceweasel: please enable upstream crash reporting

[Laurent Bigonville]

On Tue, 25 Sep 2012 15:16:48 +0200 Albert Dengg  wrote:

> hi,

Hi,

> i think it would be good to enable upstream crash reporting in the
> iceweasel build, because even though it is not offically branded, there
> is quite a userbase with the same builds so that reports and also
> importing the symbols for this build could be usefull for all parties
> involved.

Hasn't this be enabled in 49.0-4 ?

Bug#833893: network-manager: wifi hot spot w/ dnsmasq conflicts unbound/dns requests)

[Fulano Diego Perez]

segfault was probably the window crash

Oct  8 01:53:34 local kernel: [64581.986026] gnome-control-c[24097]:
segfault at 8 ip 7fc7a9fddf13 sp 7fff580558e0 error 4 in
libnm.so.0.1.0[7fc7a9f9a000+d4000]

Bug#839570: Browserified javascript and DFSG 2 (reopening)

[Bdale Garbee]

Adrian Bunk  writes:

> Only DFSG-free packages that depend on non-free software are allowed 
> in contrib.

At Debconf in Heidelberg, this definition was tweaked somewhat by
inspiration of the sitting DPL in light of the ZFS discussion to include
software which itself is free, but the use of which is unlikely to be
possible without creating an unredistributable result in combination
with other DFSG-free but license incompatible packages.  So it's not
strictly necessary for there to be a dependence on non-free software to
push something to contrib.

Bdale


signature.asc
Description: PGP signature

Bug#833893: network-manager: wifi hot spot w/ dnsmasq conflicts unbound/dns requests)

[Fulano Diego Perez]

stopped dnscrypt-proxy, unbound systemd services

re-installed dnsmasq and base - i removed it because i dont use it
day-to-day

start hotspot

network-manager window crash

no hotspot


dnsmasq is conflicting with unbound and dnscrypt-proxy


is the only solution to disable unbound/dnscrypt-proxy ?

does hotspot work "out-of-the-box" ?




Oct 08 01:19:22 local dnsmasq[23381]: started, version 2.76 cachesize 150
Oct 08 01:19:22 local dnsmasq[23381]: compile time options: IPv6 GNU-getopt 
DBus i18n IDN DHCP DHCPv6 no-Lua TFTP conntrack ipset auth DNSSEC loop-detect 
inotify
Oct 08 01:19:22 local dnsmasq[23381]: DNS service limited to local subnets
Oct 08 01:19:22 local dnsmasq[23381]: DNSSEC validation enabled
Oct 08 01:19:22 local dnsmasq[23381]: reading /etc/resolv.conf
Oct 08 01:19:22 local dnsmasq[23381]: ignoring nameserver 127.0.0.1 - local 
interface
Oct 08 01:19:22 local dnsmasq[23381]: read /etc/hosts - 5 addresses
Oct 08 01:26:30 local NetworkManager[23533]:   [1475850390.9455] 
NetworkManager (version 1.4.0) is starting...
Oct 08 01:26:30 local NetworkManager[23533]:   [1475850390.9456] Read 
config: /etc/NetworkManager/NetworkManager.conf
Oct 08 01:26:30 local NetworkManager[23533]:   [1475850390.9498] 
manager[0xbb5050]: monitoring kernel firmware directory '/lib/firmware'.
Oct 08 01:26:30 local NetworkManager[23533]:   [1475850390.9499] 
monitoring ifupdown state file '/run/network/ifstate'.
Oct 08 01:26:30 local NetworkManager[23533]:   [1475850390.9515] 
dns-mgr[0xbaf170]: init: dns=default, rc-manager=resolvconf
Oct 08 01:26:30 local NetworkManager[23533]:   [1475850390.9527] rfkill5: 
found WiFi radio killswitch (at 
/sys/devices/pci:00/:00:14.0/usb3/3-1/3-1.4/3-1.4:1.0/ieee80211/phy3/rfkill5)
 (driver ath9k_htc)
Oct 08 01:26:30 local NetworkManager[23533]:   [1475850390.9529] 
manager[0xbb5050]: WiFi hardware radio set enabled
Oct 08 01:26:30 local NetworkManager[23533]:   [1475850390.9529] 
manager[0xbb5050]: WWAN hardware radio set enabled
Oct 08 01:26:30 local NetworkManager[23533]:   [1475850390.9700] init!
Oct 08 01:26:30 local NetworkManager[23533]:   [1475850390.9701]   
interface-parser: parsing file /etc/network/interfaces
Oct 08 01:26:30 local NetworkManager[23533]:   [1475850390.9702]   
interface-parser: source line includes interfaces file(s) 
/etc/network/interfaces.d/*
Oct 08 01:26:30 local NetworkManager[23533]:   [1475850390.9702] 
interfaces file /etc/network/interfaces.d/* doesn't exist
Oct 08 01:26:30 local NetworkManager[23533]:   [1475850390.9702]   
interface-parser: finished parsing file /etc/network/interfaces
Oct 08 01:26:30 local NetworkManager[23533]:   [1475850390.9702] 
management mode: unmanaged
Oct 08 01:26:30 local NetworkManager[23533]:   [1475850390.9708] devices 
added (path: 
/sys/devices/pci:00/:00:14.0/usb3/3-1/3-1.4/3-1.4:1.0/net/, iface: )
Oct 08 01:26:30 local NetworkManager[23533]:   [1475850390.9708] device 
added (path: 
/sys/devices/pci:00/:00:14.0/usb3/3-1/3-1.4/3-1.4:1.0/net/, iface: ): 
no ifupdown configuration found.
Oct 08 01:26:30 local NetworkManager[23533]:   [1475850390.9709] devices 
added (path: 
/sys/devices/pci:00/:00:14.0/usb3/3-2/3-2:1.0/net/enp0s20u2, iface: 
enp0s20u2)
Oct 08 01:26:30 local NetworkManager[23533]:   [1475850390.9709] device 
added (path: 
/sys/devices/pci:00/:00:14.0/usb3/3-2/3-2:1.0/net/enp0s20u2, iface: 
enp0s20u2): no ifupdown configuration found.
Oct 08 01:26:30 local NetworkManager[23533]:   [1475850390.9709] devices 
added (path: /sys/devices/pci:00/:00:1c.3/:03:00.2/net/enp3s0f2, 
iface: enp3s0f2)
Oct 08 01:26:30 local NetworkManager[23533]:   [1475850390.9709] device 
added (path: /sys/devices/pci:00/:00:1c.3/:03:00.2/net/enp3s0f2, 
iface: enp3s0f2): no ifupdown configuration found.
Oct 08 01:26:30 local NetworkManager[23533]:   [1475850390.9709] devices 
added (path: /sys/devices/virtual/net/lo, iface: lo)
Oct 08 01:26:30 local NetworkManager[23533]:   [1475850390.9709] device 
added (path: /sys/devices/virtual/net/lo, iface: lo): no ifupdown configuration 
found.
Oct 08 01:26:30 local NetworkManager[23533]:   [1475850390.9709] end 
_init.
Oct 08 01:26:30 local NetworkManager[23533]:   [1475850390.9709] 
settings: loaded plugin ifupdown: (C) 2008 Canonical Ltd.  To report bugs 
please use the NetworkManager mailing list. 
(/usr/lib/x86_64-linux-gnu/NetworkManager/libnm-settings-plugin-ifupdown.so)
Oct 08 01:26:30 local NetworkManager[23533]:   [1475850390.9710] 
settings: loaded plugin keyfile: (c) 2007 - 2015 Red Hat, Inc.  To report bugs 
please use the NetworkManager mailing list.
Oct 08 01:26:30 local NetworkManager[23533]:   [1475850390.9710] 
(12412272) ... get_connections.
Oct 08 01:26:30 local NetworkManager[23533]:   [1475850390.9710] 
(12412272) ... get_connections (managed=false): return empty list.
Oct 08 01:26:30 local NetworkManager[23533]:   [1475850390.9842] keyfile: 
new connection 

Bug#840010: nm.debian.org: Urls to git repo are incorrect

[Dieter Adriaenssens]

Package: nm.debian.org
Severity: normal
Tags: patch

Dear Maintainer,

Two urls pointing to anonscm.debian.org are incorrect : 
- location of source-code in website footer
- link to a README on how to add more data sources

A patch is included to fix these urls.

Kind regards,
Dieter Adriaenssens


-- System Information:
Debian Release: jessie/sid
diff --git a/dclayout/templates/dc-base.html b/dclayout/templates/dc-base.html
index 9043c13..be88c47 100644
--- a/dclayout/templates/dc-base.html
+++ b/dclayout/templates/dc-base.html
@@ -54,7 +54,7 @@
 
 {% block footer %}
 Copyright © 2013 Enrico Zini enr...@debian.org. See license terms.
-Source code is http://anonscm.debian.org/gitweb/?p=nm/dc.git;a=summary;>here, to help see
+Source code is https://anonscm.debian.org/cgit/nm/dc.git/;>here, to help see
 https://wiki.debian.org/Teams/FrontDesk/DcSiteDevel;>here.
 Please report bugs against the http://bugs.debian.org/nm.debian.org;>nm.debian.org pseudo-package.
 
diff --git a/sources/templates/sources/list.html b/sources/templates/sources/list.html
index 584b08d..e040d47 100644
--- a/sources/templates/sources/list.html
+++ b/sources/templates/sources/list.html
@@ -39,7 +39,7 @@ $(function() {
 This is a list of all the data sources that feed the Debian Contributors list.
 To create a new one, see
 https://wiki.debian.org/DebianContributors;>here and
-http://anonscm.debian.org/gitweb/?p=nm/python-debiancontributors.git;a=blob;f=README.md;>here.
+https://anonscm.debian.org/cgit/nm/python-debiancontributors.git/tree/README.md;>here.
 
 
 

Bug#838870: RFS: nbsphinx/0.2.9+ds-1 [ITP] -- Jupyter Notebook Tools for Sphinx

[Frederic Bonnard]

Thanks Benoit for all the documentation work.
The package looks good to me.
Good catch for the audio link ; indeed lintian does not seem to handle 
element (I sent a patch : https://bugs.debian.org/840009 )

As a side node, I'd advise you consider (report from check-all-the-things tool) 
:
- adding some upstream metadata: https://wiki.debian.org/UpstreamMetadata
- asking upstream to sign their release (debian-watch-may-check-gpg-signature)
  : https://wiki.debian.org/Creating%20signed%20GitHub%20releases
I still have to follow those advises for my packages :)

F.

On Fri, 7 Oct 2016 00:58:08 +0100, Jerome BENOIT  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> Hello,
> 
> On 05/10/16 13:26, Frederic Bonnard wrote:
> > Thanks Benoit/Ghislain,
> > indeed with experimental archive it's much better :)
> > 
> > Benoit,
> > my last point would be about privacy-breach-generic lintian.
> > You overrided it with :
> > --
> > N: The involved links are meant to illustrate URL examples, so it is 
> > meaningless
> > N: to bring the involved material in a local folder.
> > --
> > 
> > I agree that bringing stuff locally (as it is advised in the lintian
> > description) is useless when the goal is to show the code for how to embed
> > content of remote images/videos URLs.
> > Though I still think there's a breach, as loading the documentation makes 
> > your
> > browser connect to the internet, load images but also javascripts and so 
> > on, which
> > is originally the reason of this lintian definition (or let me know if I'm 
> > wrong).
> > Even if you point to DFSG-free ressources, you'll have your browser that 
> > will still
> > connect outside, and that's the issue in my understanding.
> > 
> > I've been thinking about this and reading your discussion with Paul Wise,
> > I came to the following idea : why not changing after generation the html 
> > (sed...) :
> > 
> > For images :
> > ---
> > -https://www.python.org/static/img/python-logo-large.png"/>
> > +https://www.python.org/static/img/python-logo-large.png should be 
> > displayed, but it got removed because of 
> > https://lintian.debian.org/tags/privacy-breach-generic.html.;
> > ---
> > 
> > and for the embedded video :
> > 
> > ---
> >   >  width="400"
> >  height="300"
> > -src="https://www.youtube.com/embed/WAikxUGbomY;
> > +src="about:blank"
> >  frameborder="0"
> >  allowfullscreen
> > +srcdoc="This video : https://www.youtube.com/embed/WAikxUGbomY should 
> > be displayed, but it got removed because of 
> > https://lintian.debian.org/tags/privacy-breach-generic.html.;
> >  >
> > ---
> > 
> > That way, you'll keep the source code example clean, and despite the fact 
> > the html
> > is modified, the user reading the documentation will still understand the 
> > example, what
> > it should do, what is displayed and altered and why.
> > Ok the documentation html code is modified but the goal of the doc is to get
> > the idea of the use (source code) and visual result (rather than html 
> > output that got modified)
> > I also thought of playing with Content-Security-Policy in  of the 
> > document to block
> > all outside connections but, I'm not sure all browser implement this 
> > correctly.
> > It's also less understable for the reader to understand why things 
> > disappeared (except
> > if this "framework" have information facilities). But it would be very good 
> > to fix
> > all the privacy-breach-generic in a general manner.
> 
> 
> When I wrote the lintian override, I have in mind beside the HTML output the 
> ipynb input,
> only the former is taken into account by lintian.
> Meanwhile, I relized that lintian was not able to point out an audio 
> privacy-breatch..
> 
> Anyway, I brought the suggested material. The hard part was the refreshment 
> of the debian/copyright file:
> it is getting large.
> 
> I hope the package is fine now.
> 
> Thanks,
> Jerome
> 
> 
> 
> > 
> > 
> > F.
> > 
> 
> - -- 
> Jerome BENOIT | calculus+at-rezozer^dot*net
> https://qa.debian.org/developer.php?login=calcu...@rezozer.net
> AE28 AE15 710D FF1D 87E5  A762 3F92 19A6 7F36 C68B
> -BEGIN PGP SIGNATURE-
> 
> iQQcBAEBCgAGBQJX9uUQAAoJED+SGaZ/NsaL7W8f/i7CCIYZzleqbHqaCn1Hhz7V
> rCfXDVGuIfVsYoRQrFZX/w7DMOX6teiwwlOTiD4kwZc8YcwX+4E+ZkaHx4zCvqii
> QqFIXUWiVgJ+Z0+ZMdMi1X+ef708K5M/92iAKWBPFp6F2Kri7qJQsTwkrsVRMt7k
> RaldggeFiNTJfKqZFp6kLlh8acSFHOdccQ8/EAnBUT1Uz6xByWRofl1JA09zncZ/
> 4U7SaOH6p9Cfa3xa9SAN++BFDmOMjJ/J6NlJ6ieXg9+LV213l7WbU/hxD+YANtRu
> hICHZhvTNmX66S95nZKuPqCwla+CIEByO9p/973ocrrtQPktdyg+b8AV0vrkkxDA
> JmBxKiR3rwQs9oaN7er9zj2H97jMMJhH5THBbdWxXTSAAE645+x9G7M8sIq3CAxB
> feTaaXVElye8sKAU4PyI9smJrHs8GBKxmBWzf3hwsc+f11FjT7vgnt3NRTLs5oFH
> xN2xy/tvWAucnJXH7he7fJ+M9yh7jDidXlhS5NbzNrB5JeUdWkZL4mUGKS7sloXh
> KsGzaQ3OyaILpq4o79KGzl0vvYpxGLngTOlb+IITqsZVEVIwcW9CN4mr9bH7hLKt
> vzn9mEteOG3nADvQdUaBmJveuT5TcsHLE87rofCCjyo5LXzdzC0Ydtiph9UfDNX+
> pxBoEC/gCDSgEzQXSWGCbpkme3ZOlC1HK6vvp3g9lmoK0PO+a3yXvuxb+L36ixxL

Bug#840009: [PATCH] lintian : privacy-breach-generic support for

[Frederic Bonnard]

Package: lintian
Version: 2.5.48
Tags: patch

--

Dear maintainer,

it seems lintian does not currently detect privacy breaches within  
element
; Jerome Benoit noticed that in #838870.
Could you confirm and review the attached patch ?
Thank you,

F.
diff -Nru lintian-2.5.48/data/files/privacy-breaker-tag-attr lintian-2.5.48/data/files/privacy-breaker-tag-attr
--- lintian-2.5.48/data/files/privacy-breaker-tag-attr	2016-09-25 18:21:57.0 +
+++ lintian-2.5.48/data/files/privacy-breaker-tag-attr	2016-10-04 19:37:17.0 +
@@ -19,3 +19,4 @@
 track~~ src="http   && ]+)? \s+ src="()" [^>]*>)
 video src=   ~~ src="http   && ]+)? \s+ src="()" [^>]*>)
 video poster=~~ poster="http&& ]+)? \s+ poster="()" [^>]*>)
+audio~~ src="http   && ]+)? \s+ src="()" [^>]*>)
diff -Nru lintian-2.5.48/t/tests/files-privacybreach/debian/src/privacy-breach-generic/audio.html lintian-2.5.48/t/tests/files-privacybreach/debian/src/privacy-breach-generic/audio.html
--- lintian-2.5.48/t/tests/files-privacybreach/debian/src/privacy-breach-generic/audio.html	1970-01-01 00:00:00.0 +
+++ lintian-2.5.48/t/tests/files-privacybreach/debian/src/privacy-breach-generic/audio.html	2016-10-04 19:37:17.0 +
@@ -0,0 +1,7 @@
+
+
+
+ftp://1984.os/tuxistrackingme.ogg; />
+
+
+
diff -Nru lintian-2.5.48/t/tests/files-privacybreach/debian/src/privacy-breach-generic/audiotrack.html lintian-2.5.48/t/tests/files-privacybreach/debian/src/privacy-breach-generic/audiotrack.html
--- lintian-2.5.48/t/tests/files-privacybreach/debian/src/privacy-breach-generic/audiotrack.html	1970-01-01 00:00:00.0 +
+++ lintian-2.5.48/t/tests/files-privacybreach/debian/src/privacy-breach-generic/audiotrack.html	2016-10-04 19:37:17.0 +
@@ -0,0 +1,11 @@
+
+
+
+
+  
+  
+  
+  http://1984.os/notracking.vtt; kind="captions" srclang="no" label="Norwegian">
+
+
+
diff -Nru lintian-2.5.48/t/tests/files-privacybreach/tags lintian-2.5.48/t/tests/files-privacybreach/tags
--- lintian-2.5.48/t/tests/files-privacybreach/tags	2016-09-25 18:22:03.0 +
+++ lintian-2.5.48/t/tests/files-privacybreach/tags	2016-10-04 19:37:17.0 +
@@ -53,6 +53,8 @@
 E: files-privacybreach: privacy-breach-w3c-valid-html usr/share/files-privacy-breach/privacy-breach-w3c-valid-html/htmlvalid.html (http://www.w3.org/icons/valid-xhtml10)
 X: files-privacybreach: privacy-breach-generic usr/share/files-privacy-breach/privacy-breach-generic/applet.html (//1984.os/trackme2)
 X: files-privacybreach: privacy-breach-generic usr/share/files-privacy-breach/privacy-breach-generic/applet.html (http://1984.os/trackme)
+X: files-privacybreach: privacy-breach-generic usr/share/files-privacy-breach/privacy-breach-generic/audio.html (ftp://1984.os/tuxistrackingme.ogg)
+X: files-privacybreach: privacy-breach-generic usr/share/files-privacy-breach/privacy-breach-generic/audiotrack.html (http://1984.os/notracking.vtt)
 X: files-privacybreach: privacy-breach-generic usr/share/files-privacy-breach/privacy-breach-generic/div.html (//trackme.1984/index-3.html)
 X: files-privacybreach: privacy-breach-generic usr/share/files-privacy-breach/privacy-breach-generic/div.html (http://trackme.1984/index-2.html)
 X: files-privacybreach: privacy-breach-generic usr/share/files-privacy-breach/privacy-breach-generic/embed.html (//1984.os/givemydata2.swf)

Bug#840000: libapache-mod-jk: CVE-2016-6808

[Markus Koschany]

On 07.10.2016 16:20, Salvatore Bonaccorso wrote:
> Hi Markus,
[...]

> Thanks for your investigation! Have you good upstream contact to try
> to clarify why the above statement was made?

Hi Salvatore,

unfortunately not. I'm just the guy who tries to keep these packages
alive. But I agree that we need an upstream clarification because I also
don't understand why they singled out the IIS server. I'll try to get in
contact with them.






signature.asc
Description: OpenPGP digital signature

Bug#840000: libapache-mod-jk: CVE-2016-6808

[Salvatore Bonaccorso]

Hi Markus,

On Fri, Oct 07, 2016 at 03:21:54PM +0200, Markus Koschany wrote:
> On 07.10.2016 14:15, Salvatore Bonaccorso wrote:
> [...]
> > 
> > Now whilst the affected code is back present in 1.2.0, I need some
> > help understanding the actual impact for us. According to the build
> > log this common code is as well compiled in into the mod_jk, The
> > upstream description though mention that the resulting security impact
> > is seems only relevant when run under IIS.
> > https://marc.info/?l=oss-security=147575324211141=2 as well states
> > that a mitigation would be to "Where available, use IIS configuration
> > to restrict the maximum URI length to 4095 - (the length of the
> > longest virtual host name)".
> > 
> > Can you clarify if this is correct? If so we would mark the CVE as
> > (unimportant) and thus as well not release a DSA, and a 1:1.2.42
> > upload to unstable can then mark the CVE as fixed.
> > 
> > Please let me know if the above statement about the issue beeing
> > relevant only under IIS is correct this way.
> 
> Looking at native/common/jk_uri_worker_map.c it appears that the
> affected map_uri_to_worker_ext function is shared between the IIS,
> Apache 1.3 and Apache-2.0 modules and the latter is used by Debian. So
> for me it looks relevant to us.

Thanks for your investigation! Have you good upstream contact to try
to clarify why the above statement was made?

Regards,
Salvatore

Bug#840000: libapache-mod-jk: CVE-2016-6808

[Salvatore Bonaccorso]

On Fri, Oct 07, 2016 at 02:15:32PM +0200, Salvatore Bonaccorso wrote:
> Can you clarify if this is correct? If so we would mark the CVE as
> (unimportant) and thus as well not release a DSA, and a 1:1.2.42
> upload to unstable can then mark the CVE as fixed.

... or actually  (Windows specific) in that case, it
turns true.

Regards,
Salvatore

Bug#839993: pulseaudio: Pulseaudio is able to share non-ALSA audio devices across differens user sessions

[Felipe Sateler]

Control: tags -1 confirmed upstream
Control: forwarded -1 https://bugs.freedesktop.org/show_bug.cgi?id=98144

On 7 October 2016 at 05:02, Alexander Betaev  wrote:
> Package: pulseaudio
> Version: 9.0-3
> Severity: important
>
> Dear Maintainer,
>
> I found that Pulseaudio in per user session mode does not allow all users to
> use all devices I have on my machine.
> Only ALSA devices may be shared across different user sessions without an
> issue.
>
> I noticed such behaviour with native TCP device which is provided by my media
> center (JIC, also runs Stretch under KVM with GFX passthrough), and with
> Bluetooth device which works pretty well until you try to use it under another
> user.
>
> In order to achieve working Bluetooth Headset I had to disable pulseaudio for
> GDM3 user (Debian-gdm) because it grab it before my user almost each time.
>
> I believe there should be a hook which suspends pulseaudio when user looses
> focus on his/her session and a hook to restore when user grabs session focus.
>
> The only way to use pulseaudio in multi-user installations now is to make it
> system-wide which is also not recommended because of other issues
> (https://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/User/WhatIsWrongWithSystemWide/)

I discussed this with upstream and they agree that this is only
implemented for alsa devices. I have thus created an issue upstream,
and am marking this bug as forwarded there. I have mainly focused in
the bluetooth case since that is the most likely to cause problems for
users.

-- 

Saludos,
Felipe Sateler

Bug#839250: - gunicorn backport >= 19.6.0-6

[Neil Williams]

On Fri, 07 Oct 2016 11:19:02 +0100
Chris Lamb  wrote:

(sorry, missed the CC: list in error)

> > > Right, but that's for stretch where the sysadmin will be clearly
> > > be more aware of and/or even looking for issues. I don't want to
> > > break existing systems right now.  
>  
> > So how are packages using gunicorn to handle support for both
> > stretch and jessie-backports? Packages in jessie can't be changed,
> > so changes need to take place in backports to prepare for
> > stretch.   
>  
> > Adding packages from backports should be about preparing for the
> > next stable release.  
> 
> I completely understand that and strongly agree, but *weighed up
> against* breaking existing stable-based systems I relaly feel it the
> worst of two bad options to upload it to backports.
> 
> I mean, I know I have deployed systems that--if they were to blindly
> upgrade from backports after such an upload--would have a broken
> system!

and just how is python-django 1.8 from backports any different?

I had a number of users reporting broken systems because the package
using django wasn't ready for 1.8 at the time. The only fix is to have
a version in backports which works with packages in stretch to allow
those to be backported as well. That's what backports is supposed to
provide.

-- 


Neil Williams
=
http://www.linux.codehelp.co.uk/



pgp5zoClCemK1.pgp
Description: OpenPGP digital signature

Bug#840008: fakechroot.sh sould set FAKECHROOT_CMD_ORIG if needed

[jhcha54008]

Package: fakechroot
Version: 2.18-1.1
Severity: normal
Tags: patch

Dear Maintainer,

fakechroot.sh currently doesn't set FAKECHROOT_CMD_ORIG
if it performs a command substitution. In contrast,
execve does.

This results in subtile bugs.

Regards,
JH Chatenet

--- a/scripts/fakechroot.sh
+++ b/scripts/fakechroot.sh
@@ -213,6 +213,11 @@
 esac
 done
 `
+# Set FAKECHROOT_CMD_ORIG if required
+if [ -n "$fakechroot_cmd_wrapper" ]; then
+FAKECHROOT_CMD_ORIG="$fakechroot_cmd"
+export FAKECHROOT_CMD_ORIG
+fi
 fakechroot_cmd=${fakechroot_cmd_wrapper:-$1}
 
 



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

Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Versions of packages fakechroot depends on:
ii  libfakechroot  2.18-1.1

fakechroot recommends no packages.

fakechroot suggests no packages.

-- no debconf information

Bug#770135: Reproduced in Ubuntu 16.04

[Wiebe Cazemier]

Should it be relevant, this keeps hapenning on Ubuntu 16.04. Systemd and
libpam-systemd version 229-4ubuntu10.

Bug#840007: fakechroot: ldd.fakechroot : a missing path separator ?

[jhcha54008]

Package: fakechroot
Version: 2.18-1.1
Severity: minor
Tags: patch

Dear Maintainer,

It may be useful to distinguish different paths with
the same beginning (e.g. mychroot and mychroot2 :
$Base=mychroot matches mychroot2 too, which is not
intended). One may check that a path separator '/' is
present after $BASE in the path (e.g. mychroot/ does
not match mychroot2/, and this is the correct behaviour).

Regards,
JH Chatenet

--- a/scripts/ldd.fakechroot.pl
+++ b/scripts/ldd.fakechroot.pl
@@ -57,7 +57,7 @@
 
 push @Libs, $lib;
 if (-f $path) {
-$path =~ s/^\Q$Base\E// if $Base;
+$path =~ s/^\Q$Base\/\E/\// if $Base;
 $Libs{$lib} = $path;
 objdump($path);
 }



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

Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Versions of packages fakechroot depends on:
ii  libfakechroot  2.18-1.1

fakechroot recommends no packages.

fakechroot suggests no packages.

-- no debconf information

Bug#833893: [Pkg-utopia-maintainers] Bug#833893: (network-manager: wifi hot spot w/ dnsmasq conflicts unbound/dns requests)

[Fulano Diego Perez]

you wrote:
> Am 07.10.2016 um 07:19 schrieb Fulano Diego Perez:
>> Oct  7 14:56:23 local NetworkManager[897]:  [1475812583.5192] device 
>> (): share: () failed to start dnsmasq: Could not find "dnsmasq" binary
> 
> You haven't installed the dnsmasq-base package.
> The hotspot functionality requires it. It's as simple as that.

if you refer to earlier msgs you would know i did have dnsmasq installed
prior and it didnt work

i request the bug to be re-opened

im not convinced of the use of the hotspot, dnsmasq and unbound
simultaneously is bug free

if you can otherwise confirm that it is, id like to see that

Bug#839867: pygtk: FTBFS on sparc64 - bus error in testsuite

[John Paul Adrian Glaubitz]

On 10/07/2016 03:22 PM, Andreas Henriksson wrote:
> I'm not personally interested, just trying to provide some feedback
> that might be useful to you. I asked on #debian-gnome and atleast
> pochu answered he's still interested in keeping the package around
> in pkg-gnome and offered to take care of it. If you want to NMU I think
> just handing him a NMUdiff so we can keep packaging svn up to date
> to avoid accidentally loosing NMU changes in the future could work.

James (CC'ed) is currently working on a NMUdiff and I'm sure he can send
one to pochu. He wanted to do the NMU himself with me being the sponsor,
but I guess this way is fine, too.

> (Also, not sure why you want to build these having them missing
> could in this case even be considered a feature. ;P
> ... but I guess you have "% of the archive" criterias to meet which
> doesn't take into considerations how much of the archive is just
> zombies and how your missing set intersects with the zombie set.)

Exactly. We just want to increase this percentage to the highest
possible value.

> Again, thanks for providing a patch (which is in my experience
> unfortunately too rare despite this being an open source volunteer
> effort). Hope it works out.

All credits for the patch go to James :). In fact, he has already
fixed so many issues particularly on sparc64 that I'm all for making
him a DD as soon as possible!

Adrian

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

Bug#840000: libapache-mod-jk: CVE-2016-6808

[Markus Koschany]

On 07.10.2016 14:15, Salvatore Bonaccorso wrote:
[...]
> 
> Now whilst the affected code is back present in 1.2.0, I need some
> help understanding the actual impact for us. According to the build
> log this common code is as well compiled in into the mod_jk, The
> upstream description though mention that the resulting security impact
> is seems only relevant when run under IIS.
> https://marc.info/?l=oss-security=147575324211141=2 as well states
> that a mitigation would be to "Where available, use IIS configuration
> to restrict the maximum URI length to 4095 - (the length of the
> longest virtual host name)".
> 
> Can you clarify if this is correct? If so we would mark the CVE as
> (unimportant) and thus as well not release a DSA, and a 1:1.2.42
> upload to unstable can then mark the CVE as fixed.
> 
> Please let me know if the above statement about the issue beeing
> relevant only under IIS is correct this way.

Looking at native/common/jk_uri_worker_map.c it appears that the
affected map_uri_to_worker_ext function is shared between the IIS,
Apache 1.3 and Apache-2.0 modules and the latter is used by Debian. So
for me it looks relevant to us.

Regards,

Markus




signature.asc
Description: OpenPGP digital signature

Bug#839867: pygtk: FTBFS on sparc64 - bus error in testsuite

[Andreas Henriksson]

Hello Adrian!

On Fri, Oct 07, 2016 at 10:29:50AM +0200, John Paul Adrian Glaubitz wrote:
> Hi Andreas!
> 
> We as the sparc64 porters would still appreciate to have the package
> fixed though. Especially since - as you mentioned yourself - pygtk
> still has many reverse dependencies. We just want to fix as many
> packages on sparc64 as possible so that we're absolutely ready
> to turn it into a release architecture when Oracle finally ships
> the hardware :).
> 
> So, if you cannot be bothered to do the upload yourself, I'd be
> happy to NMU this package to get this issue resolved :).

I'm not personally interested, just trying to provide some feedback
that might be useful to you. I asked on #debian-gnome and atleast
pochu answered he's still interested in keeping the package around
in pkg-gnome and offered to take care of it. If you want to NMU I think
just handing him a NMUdiff so we can keep packaging svn up to date
to avoid accidentally loosing NMU changes in the future could work.

(Also, not sure why you want to build these having them missing
could in this case even be considered a feature. ;P
... but I guess you have "% of the archive" criterias to meet which
doesn't take into considerations how much of the archive is just
zombies and how your missing set intersects with the zombie set.)

Again, thanks for providing a patch (which is in my experience
unfortunately too rare despite this being an open source volunteer
effort). Hope it works out.

Regards,
Andreas Henriksson

Bug#839246: linux-image-4.7.0-1-amd64: Graphic artifacts since upgrade to 4.7.0-1 with Intel HD4600

[Helios Solaris]

On 10/07/2016 03:05 PM, Ben Hutchings wrote:

That's not the same as removing the parameter (the default is -1).
Please can you check that?


My bad. Also no artifacts with the parameter removed.

Bug#840006: cgi-fcgi-interp: support CGI command line arguments

[Ian Jackson]

Package: chiark-utils-bin
Version: 4.5.0~iwj2

--- Begin Message ---
---
 cprogs/cgi-fcgi-interp.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/cprogs/cgi-fcgi-interp.c b/cprogs/cgi-fcgi-interp.c
index 7a5a5db..d6c08c2 100644
--- a/cprogs/cgi-fcgi-interp.c
+++ b/cprogs/cgi-fcgi-interp.c
@@ -4,7 +4,7 @@
  *   #!/usr/bin/cgi-fcgi-interp [],
  */
 /*
- * cgi-fcgi-interp.[ch] - C helpers common to the whole of chiark-utils
+ * cgi-fcgi-interp.[ch] - script wrapper for cgi-fcgi
  *
  * Copyright 2016 Ian Jackson
  * Copyright 1982,1986,1993 The Regents of the University of California
-- 
2.1.4

--- End Message ---
--- Begin Message ---
If the QUERY_STRING does not contain an = then it is also passed
on the command line.

See https://tools.ietf.org/html/rfc3875#section-4.4
---
 cprogs/cgi-fcgi-interp.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/cprogs/cgi-fcgi-interp.c b/cprogs/cgi-fcgi-interp.c
index d6c08c2..3daf025 100644
--- a/cprogs/cgi-fcgi-interp.c
+++ b/cprogs/cgi-fcgi-interp.c
@@ -604,7 +604,6 @@ int main(int argc, const char *const *argv) {

   script = *argv++;
   if (!script) badusage("need script argument");
-  if (*argv) badusage("too many arguments");

   if (!stage2) {

-- 
2.1.4
--- End Message ---

-- 
Ian Jackson    These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Bug#839994: [pkg-cryptsetup-devel] Bug#839994: Newest version prevent boot of full encrypted disk

[Guilhem Moulin]

On Fri, 07 Oct 2016 at 13:56:27 +0100, Klaus Ethgen wrote:
> Am Fr den  7. Okt 2016 um 13:04 schrieb Guilhem Moulin:
>> I see.  Indeed, we've unfortunately been too fast at releasing a fix for
>> #786578.  That is, we documented setting KEYFILE_PATTERN
>> /etc/initramfs-tools/initramfs.conf (or alternatively, under
>> /etc/initramfs-tools/conf.d) while the initramfs-tools maintainers later
>> (#807527) objected to using /etc/initramfs-tools for hook configuration:
>> 
>>???If a hook script requires configuration beyond the exported
>>variables listed below, it should read a private configuration file
>>that is separate from the /etc/initramfs-tools directory.  It must
>>not read initramfs-tools configuration files directly.??? ???
>>initramfs-tools(8)
>> 
>> Can you confirm your system boots as expected once you delete
>> /etc/initramfs-tools/conf.d/diskkey and use
>> /etc/cryptsetup-initramfs/conf-hook instead?
> 
> Partly. It will boot but the rights of the resulting initrd are 0644, so
> world-readable with credentials in it.

UMASK *is* a mkinitramfs(8) option, so setting UMASK should stay in
/etc/initramfs-tools.  Modifying UMASK from the hook script doesn't have
any effect since it's exected in a subshell.  On the other hand its
value is accessible read only, and the hook script prints a warning if
it's too permissive.

As of 2:1.7.2-1 you'll find the following under
/usr/share/doc/cryptsetup/README.initramfs:

12. Storing keyfiles directly in the initrd
---
Normally devices using a keyfile are ignored (with a loud warning), and
the key file itself is not included in the initrd, because the initramfs
image typically lives on an unencrypted /boot partition. However in
some cases it is desirable to include the key file in the initrd; for
instance recent versions of GRUB support booting from encrypted block
devices, allowing an encrypted /boot partition.

Among the key files listed in the crypttab(5), those matching the value
of the environment variable KEYFILE_PATTERN (interpreted as a shell
pattern) will be included in the initramfs image. For instance if
/etc/crypttab lists two key files /etc/keys/{root,swap}.key, you can add
the following to /etc/cryptsetup-initramfs/conf-hook to add them to the
initrd.

  KEYFILE_PATTERN="/etc/keys/*.key"

Furthermore if the initramfs image is to include private key material,
you'll want to create it with a restrictive umask in order to keep
non-privileged users at bay.  This can be achived by adding the
following to /etc/initramfs-tools/initramfs.conf.

  UMASK=0077
 
>> I'll push a proper fix
>> later today, to make the latter config file take precedence over
>> mkinitramfs(8) settings; but *not override them* as it's incorrectly
>> done now.
> 
> Well, just keep 'em commented out I would says that will fix it?

Yup nothing fancy as the hook isn't executed with -u anyway.

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#839246: linux-image-4.7.0-1-amd64: Graphic artifacts since upgrade to 4.7.0-1 with Intel HD4600

[Ben Hutchings]

[Re-sending with cc to the bug]

On Fri, 2016-10-07 at 09:33 +0200, Helios Solaris wrote:
> i915.enable_ppgtt=0 seem to have solved the problem. Thank you.


That's not the same as removing the parameter (the default is -1).
Please can you check that?

Ben.


-- 
Ben Hutchings
Every program is either trivial or else contains at least one bug



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

Bug#839993: May be there is a hook, but it does not work

[Felipe Sateler]

On 7 October 2016 at 06:21, Alexander Betaev  wrote:
> Looks like I found one more related issue: when user uses audio device and
> tries to logout it does not work.
>
> I see these messages in GDM log (journalctl -u gdm):
> окт 07 12:09:21 inftop gdm-launch-environment][5570]:
> pam_systemd(gdm-launch-environment:session): Failed to create session: No
> seat 'seat0allow-timed-login' known
> окт 07 12:09:21 inftop gdm3[3099]: gdm_session_set_environment_variable:
> assertion 'value != NULL' failed
>
> Looks like missprint somewhere, but I don't know where.

Interesting. Is your user shown as active in the current seat? Check
via the `loginctl` command.


-- 

Saludos,
Felipe Sateler

Bug#840005: yowsup-cli: Whatsapp registration fails with "reason":"old_version"

[Jean-Marc Liotier]

Package: yowsup-cli
Version: 2.4.102-1~bpo8+1
Severity: important

Package from jessie-backports

https://github.com/tgalal/yowsup/search?utf8=%E2%9C%93=old_version does
not return any file containing the string "old_version" so I'm guessing
that this issue might be caused by a library not being up to date with
Whatsapp current protocol.


$ yowsup-cli registration -c .yowsup -r sms -C 43 -p 33609537924
yowsup-cli  v2.0.15
yowsup  v2.4.102

Copyright (c) 2012-2016 Tarek Galal
http://www.openwhatsapp.org

This software is provided free of charge. Copying and redistribution is
encouraged.

If you appreciate this software and you would like to support future
development please consider donating:
http://openwhatsapp.org/yowsup/donate


INFO:yowsup.common.http.warequest:{"status":"fail","reason":"old_version"}

status: fail
reason: old_version

Bug#839994: [pkg-cryptsetup-devel] Bug#839994: Newest version prevent boot of full encrypted disk

[Klaus Ethgen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hello Guilhem,

Am Fr den  7. Okt 2016 um 13:04 schrieb Guilhem Moulin:
> I see.  Indeed, we've unfortunately been too fast at releasing a fix for
> #786578.  That is, we documented setting KEYFILE_PATTERN
> /etc/initramfs-tools/initramfs.conf (or alternatively, under
> /etc/initramfs-tools/conf.d) while the initramfs-tools maintainers later
> (#807527) objected to using /etc/initramfs-tools for hook configuration:
> 
> ???If a hook script requires configuration beyond the exported
> variables listed below, it should read a private configuration file
> that is separate from the /etc/initramfs-tools directory.  It must
> not read initramfs-tools configuration files directly.??? ???
> initramfs-tools(8)
> 
> Can you confirm your system boots as expected once you delete
> /etc/initramfs-tools/conf.d/diskkey and use
> /etc/cryptsetup-initramfs/conf-hook instead?

Partly. It will boot but the rights of the resulting initrd are 0644, so
world-readable with credentials in it.

> I'll push a proper fix
> later today, to make the latter config file take precedence over
> mkinitramfs(8) settings; but *not override them* as it's incorrectly
> done now.

Well, just keep 'em commented out I would says that will fix it?

> (Just to be clear, we *will* drop backward compatibility at
> some point, but after at least one stable release cycle, and with a
> loud warning printed at each update-initramfs run meanwhile.)

Sure... But that should be done via debconf probably.

Regards
   Klaus
- -- 
Klaus Ethgen   http://www.ethgen.ch/
pub  4096R/4E20AF1C 2011-05-16Klaus Ethgen 
Fingerprint: 85D4 CA42 952C 949B 1753  62B3 79D0 B06F 4E20 AF1C
-BEGIN PGP SIGNATURE-
Comment: Charset: ISO-8859-1

iQGcBAEBCgAGBQJX95txAAoJEKZ8CrGAGfasRYEL/2+BH8sh2I6OIQy8Nyd9IwIp
yRnltgRepla3lFdC+Kj9AgT18azVZjbOQ9w6RtJ2BkcvHzq6RzDfkmvM0Vzeoz5y
xOuMtfyI4au3TIK0o4Bn1OdJXuKvVzq8HjmFGjrEvsJIN2TA610wNhKwi4fDjdCd
0Ey7moK6u85n4acR18Of+MaX4M7iMbC/WA6cTxZOgHlQEgaxe1FC9Yn+230V1iNL
SAn0Z+uqmHkQZpHBPOunH0hQwfC4XMx8SyOMgeTjy8X8/sL/MBlkVUUiYU158V9E
ESR3QdbCq0mugmBIf1VGpqJ6m/JruvYK3MIQ2rZWO+kxAfSzbT6A7WotjTjKV0jJ
U+SlyzjkVzecKCSxVQ3MSl/TCsqGoBL4t4FPFAtqqTJo3IzMwcwrOD+wDTUIZ6Ew
YZbeOIbRySKTWZJI+GQNfzqsOY/I8eZAov/Yrmk/B9Tx4CbwcJ2Q/Fqji6+zN8+1
uCy3Ix5LDqCgE1PEqAbUDxQZFaXqUmfnWINwMWTHdw==
=fvPC
-END PGP SIGNATURE-

Bug#840004: glare: [INTL:it] Italian translation of debconf messages

[Beatrice Torracca]

Package: glare
Severity: wishlist
Tags: l10n patch

Hi.

Please find attached the Italian translation of glare debconf messages
proofread by the Italian localization team.

Please include it in your next upload.

Thanks,
Beatrice
# Italian translation of glare debconf messages
# Copyright (C) 2016, glare package's copyright holder
# This file is distributed under the same license as the glare package.
# Beatrice Torracca , 2013, 2014, 2016.
msgid ""
msgstr ""
"Project-Id-Version: glare\n"
"Report-Msgid-Bugs-To: gl...@packages.debian.org\n"
"POT-Creation-Date: 2016-09-30 16:26+0200\n"
"PO-Revision-Date: 2016-10-07 14:37+0200\n"
"Last-Translator: Beatrice Torracca \n"
"Language-Team: Italian \n"
"Language: it\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Plural-Forms: nplurals=2; plural=(n != 1);\n"
"X-Generator: Virtaal 0.7.1\n"

#. Type: boolean
#. Description
#: ../glare-common.templates:2001
msgid "Set up a database for Glare?"
msgstr "Impostare un database per Glare?"

#. Type: boolean
#. Description
#: ../glare-common.templates:2001
msgid ""
"No database has been set up for Glare to use. Before continuing, you should "
"make sure you have the following information:"
msgstr ""
"Non è stato impostato alcun database per l'uso da parte di Glare. Se si "
"desidera impostarne uno ora assicurarsi di avere tutte le informazioni "
"necessarie:"

#. Type: boolean
#. Description
#: ../glare-common.templates:2001
msgid ""
" * the type of database that you want to use;\n"
" * the database server hostname (that server must allow TCP connections from "
"this\n"
"   machine);\n"
" * a username and password to access the database."
msgstr ""
" * il tipo di database che si desidera usare;\n"
" * il nome host del server di database (che deve permettere le connessioni\n"
"   TCP da questa macchina);\n"
" * un nome utente e una password per accedere al database."

#. Type: boolean
#. Description
#: ../glare-common.templates:2001
msgid ""
"If some of these requirements are missing, do not choose this option and run "
"with regular SQLite support."
msgstr ""
"Se non si ha uno o più di questi requisiti, non scegliere questa opzione ed "
"eseguire con il regolare supporto per SQLite."

#. Type: boolean
#. Description
#: ../glare-common.templates:2001
msgid ""
"You can change this setting later on by running \"dpkg-reconfigure -plow "
"glare\"."
msgstr ""
"È possibile cambiare questa impostazione successivamente eseguendo «dpkg-"
"reconfigure -plow glare»."

#. Type: string
#. Description
#: ../glare-common.templates:3001
msgid "Authentication server hostname:"
msgstr "Nome host del server di autenticazione:"

#. Type: string
#. Description
#: ../glare-common.templates:3001
msgid ""
"Please specify the hostname of the authentication server. Typically this is "
"also the hostname of the OpenStack Identity Service (Keystone)."
msgstr ""
"Specificare l'URL del server di autenticazione Glare. Tipicamente, è anche "
"l'URL dell'OpenStack Identity Service (Keystone)."

#. Type: string
#. Description
#. Translators: a "tenant" in OpenStack world is
#. an entity that contains one or more username/password couples.
#. It's typically the tenant that will be used for billing. Having more than one
#. username/password is very helpful in larger organization.
#. You're advised to either keep "tenant" without translating it
#. or keep it aside with your translation. Example for French:
#. proprietaire ("tenant")
#: ../glare-common.templates:4001
msgid "Authentication server tenant name:"
msgstr "Nome del locatario («tenant») per il server di autenticazione:"

#. Type: string
#. Description
#. Translators: a "tenant" in OpenStack world is
#. an entity that contains one or more username/password couples.
#. It's typically the tenant that will be used for billing. Having more than one
#. username/password is very helpful in larger organization.
#. You're advised to either keep "tenant" without translating it
#. or keep it aside with your translation. Example for French:
#. proprietaire ("tenant")
#: ../glare-common.templates:4001
msgid "Please specify the authentication server tenant name."
msgstr ""
"Specificare il nome del locatario («tenant») per il server di autenticazione."

#. Type: string
#. Description
#: ../glare-common.templates:5001
msgid "Authentication server username:"
msgstr "Nome utente per il server di autenticazione:"

#. Type: string
#. Description
#: ../glare-common.templates:5001
msgid "Please specify the username to use with the authentication server."
msgstr "Inserire il nome utente da usare con il server di autenticazione."

#. Type: password
#. Description
#: ../glare-common.templates:6001
msgid "Authentication server password:"
msgstr "Password per il server di autenticazione:"

#. Type: password
#. Description
#: ../glare-common.templates:6001
msgid "Please specify the password to 

Bug#840003: [Reportbug-maint] Bug#840003: reportbug: wrong reporting about bug

[Sandro Tosi]

On Fri, Oct 7, 2016 at 8:23 AM, Ritesh Raj Sarraf  wrote:
> Now, I expected reportbug to fail stating network timeout, with an
> exception, or maybe a nice relevant message.

were there actual timeouts/network issues at that time? it could also
be something on the BTS side

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

Bug#839990: [akonadi-server] Latest Upgrade Unstable

[Sandro Knauß]

Control: forwarded -1 https://bugs.kde.org/show_bug.cgi?id=363741

Hey,

I also can reproduce this behaviour. It look like the problem is the new 
xapian ( libxapian30 ), that lets crash akonadi server.
As workaround I removed the  libkf5akonadisearchxapian5.

Btw. the workaround from OpenSuse is to rebuild akonadi with old axapian and 
ship the old version of xapian.

Regards,

sandro

Am Freitag, 7. Oktober 2016, 12:00:44 CEST schrieb David Baron:
> On יום שישי, 7 באוקטובר 2016 10:46:56 IDT Maximiliano Curia wrote:
> > On October 7, 2016 9:24:08 AM GMT+02:00, David Baron 
> 
> wrote:
> > >Package: akonadi-server
> > >Version: 4:16.04.3-2
> > >Severity: normal
> > >
> > >--- Please enter the report below this line. ---
> > >When exercising emails in KMail2, the server will crash out.
> > 
> > What do you mean by exercising? Are you able to reproduce the crash with a
> > particular (small of possible) set of emails that you can share?
> > 
> > >Brings up box to "start" it.
> > >Restarts by itself, box disappears
> > 
> > That's the expected way to handle a crash.
> > 
> > >Note: Can duplicate this by stopping server via akonadiconsole.
> > 
> > By this last part it seems to me that you are more concerned about the
> > crashing message than of the crash itself.
> > 
> > I might be wrong, of course, but from this report I don't see anything
> > wrong in the crash message when the server stops unexpectedly (either by
> > a crash or because of a forced stop).
> 
> Does not matter. Scrolling, moving, deleting, sometimes just reading.
> Writing this answer.



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

Bug#839397: libwebkit2gtk-4.0-37: gobject-introspection on package build with webkit2gtk fails without active X session

[Alberto Garcia]

On Fri, Oct 07, 2016 at 02:18:54PM +0200, Paul Gevers wrote:

> > - Set the environment variable WEBKIT_DISABLE_COMPOSITING_MODE=1
> >   when running g-ir-scanner
> 
> I haven't tried yet, but this looks really promising. I will try
> this soon (and report back once I've done that).

In short, add this to debian/rules:

export WEBKIT_DISABLE_COMPOSITING_MODE=1

I tried it with the package in experimental and it builds.

Berto

Bug#840003: reportbug: wrong reporting about bug

[Ritesh Raj Sarraf]

Package: reportbug
Version: 6.6.6
Severity: important

Here's the captured console log.

Need to get 0 B/89.4 MB of archives.
After this operation, 11.5 MB of additional disk space will be used.
Do you want to continue? [Y/n] 
Retrieving bug reports... Done
Parsing Found/Fixed information... Done
critical bugs of cryptsetup (2:1.7.0-2 → 2:1.7.2-2) 
 b1 - #839994 - Newest version prevent boot of full encrypted disk
Summary:
 cryptsetup(1 bug)
Are you sure you want to install/upgrade the above packages? [Y/n/?/...] 839994
Retrieving report #839994 from Debian bug tracking system...
No report available: #839994
No bug reports found.
Are you sure you want to install/upgrade the above packages? [Y/n/?/...] 839994
Retrieving report #839994 from Debian bug tracking system...
No report available: #839994
No bug reports found.
Are you sure you want to install/upgrade the above packages? [Y/n/?/...] 839994
Retrieving report #839994 from Debian bug tracking system...
What do you want to do now? [N|x|o|r|b|e|q|?]? 




As you can see, in the 3rd attempt, it was able to fetch the report. The
first 2 attempts failed because my router's ISP network was down.

Now, I expected reportbug to fail stating network timeout, with an
exception, or maybe a nice relevant message.

But instead it gave me the wrong impression that #839994 is not an
available/valid bug report.



-- Package-specific info:
** Environment settings:
DEBEMAIL="r...@debian.org"
DEBFULLNAME="Ritesh Raj Sarraf"
INTERFACE="text"

** /home/rrs/.reportbugrc:
reportbug_version "6.6.3"
mode advanced
editor "editor"
ui text
realname "Ritesh Raj Sarraf"
email "r...@debian.org"
no-cc
header "X-Debbugs-CC: r...@debian.org"
smtphost reportbug.debian.org

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

Kernel: Linux 4.8.0brk0+ (SMP w/4 CPU cores)
Locale: LANG=en_IN, LC_CTYPE=en_IN (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages reportbug depends on:
ii  apt   1.3.1
ii  python-reportbug  6.6.6
pn  python:any

reportbug recommends no packages.

Versions of packages reportbug suggests:
pn  claws-mail   
pn  debconf-utils
pn  debsums  
pn  dlocate  
pn  emacs23-bin-common | emacs24-bin-common  
ii  file 1:5.28-4
ii  gnupg2.1.15-3
ii  postfix [mail-transport-agent]   3.1.0-5+b1
ii  python-gtk2  2.24.0-5
pn  python-gtkspellcheck 
ii  python-urwid 1.3.1-2+b1
pn  python-vte   
ii  xdg-utils1.1.1-1

Versions of packages python-reportbug depends on:
ii  apt   1.3.1
ii  file  1:5.28-4
ii  python-debian 0.1.29
ii  python-debianbts  2.6.1
pn  python:any

python-reportbug suggests no packages.

-- no debconf information

Bug#784881: [pkg-cryptsetup-devel] Bug#784881: cryptsetup: WARNING: failed to detect canonical device

[Guilhem Moulin]

On Thu, 06 Oct 2016 at 22:12:28 +0200, Guilhem Moulin wrote:
> Looking at the hook script's diff since 1.7.0-2 it's unclear to me
> what now causes the warning to appear.

For the record, this is because up to 2:1.7.0-1 get_fs_devices() used to
prefix the list of underlying devices with a space " " character for
btrfs.  Hence $rootdevs was never empty regardless of the value returned
by canonical_device().

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#839397: libwebkit2gtk-4.0-37: gobject-introspection on package build with webkit2gtk fails without active X session

[Paul Gevers]

Hi Alberto,

On 07-10-16 12:44, Alberto Garcia wrote:
> first of all, sorry for the late reply!

No problem. We are well before the stretch freeze.

> I'm not sure if this is a webkit bug, but I reported it upstream
> anyway.

Thanks.

> - Set the environment variable WEBKIT_DISABLE_COMPOSITING_MODE=1 when
>   running g-ir-scanner

I haven't tried yet, but this looks really promising. I will try this
soon (and report back once I've done that).

Paul



signature.asc
Description: OpenPGP digital signature

Bug#836246: Acknowledgement (libgtk-3-0: Upgrade from 3.20.9 to 3.21.5 broke Mate desktop)

[Mike Gabriel]

Hi all,

On  Do 06 Okt 2016 00:52:39 CEST, Mehdi Dogguy wrote:


On 06/10/2016 00:32, John Paul Adrian Glaubitz wrote:

On 10/06/2016 12:21 AM, Mehdi Dogguy wrote:



Again, I did not attack anyone directly, I was swearing in public
and I think this is something which is covered by freedom of speech.




I believe that your original message did hurt some people, even if it
wasn't directed towards anybody specifically. So freedom of speech is
guaranteed as long as nobody feels attacked, hurt or shocked. And, CoC
is not meant to censor anyone. It is a tool to ensure that we interact
in a pleasant and welcoming environment, for the maximum of people.


Just for the record: I received a personal mail from one of the bug  
submitters who took Adrian's public swearing pretty personal.



I'm not going to comment further on this. I'm also no longer subscribed
to the pkg-mate-team mailing list and I will most likely also leave
the team because I honestly didn't just feel annoyed but outright
harassed by those people you abuse the Debian bug tracker as their
personal support ticket system. Those aren't just lapses and oversights,
this is outright laziness and malicious entitlement by those people.



We are not forced to reply to every bug. We have also ways to ensure that
specific people are banned from interacting with the BTS and mailing lists
if we show they have a malicious behavior, by contacting BTS admins and
listmasters. We all feel the same when some minority abuses some system.
Some maintainers know better how to deal with those. I believe it is better
to ignore those abusers instead of swearing.


Adrian, unsubscribing from the ML is no real solution here IMHO. If  
you also leave the team, then Debian MATE will only have me as  
uploading DD left. Under the bottom line, we then have lost a main  
contributor _and_ one of the developers.


Please reconsider!
Mike

--

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

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



pgpARH1fhbIO6.pgp
Description: Digitale PGP-Signatur

Bug#831786: dh-exec: breaks dh_install --fail-missing

[Ferenc Wágner]

Won't this reintroduce a variant of #698054?  To keep --fail-missing and
--list-missing working, dh-exec absolutely has to run all executable
.install files, also for the side effects of the renames (as far as I
understand the current implementation).  Making it work differently when
-[ai] or -p is in effect might invoke confusion.

Why does dh-exec translate the file name when it does not do the rename,
because it's in no-op mode based on DH_CONFIG_ACT_ON_PACKAGES?

(Unrelated idea: if you start to use DH_INTERNAL_OPTIONS, maybe the
restriction on --sourcedir with dh-exec-install could be lifted.)
-- 
Regards,
Feri

Bug#840000: libapache-mod-jk: CVE-2016-6808

[Salvatore Bonaccorso]

Control: found -1 1:1.2.37-4

Hi

On Fri, Oct 07, 2016 at 01:26:00PM +0200, Salvatore Bonaccorso wrote:
> Source: libapache-mod-jk
> Version: 1:1.2.41-1
> Severity: important
> Tags: security upstream patch
> 
> Hi,
> 
> the following vulnerability was published for libapache-mod-jk.
> 
> CVE-2016-6808[0]:
> buffer overflow
> 
> If you fix the vulnerability please also make sure to include the
> CVE (Common Vulnerabilities & Exposures) id in your changelog entry.
> 
> For further information see:
> 
> [0] https://security-tracker.debian.org/tracker/CVE-2016-6808

Now whilst the affected code is back present in 1.2.0, I need some
help understanding the actual impact for us. According to the build
log this common code is as well compiled in into the mod_jk, The
upstream description though mention that the resulting security impact
is seems only relevant when run under IIS.
https://marc.info/?l=oss-security=147575324211141=2 as well states
that a mitigation would be to "Where available, use IIS configuration
to restrict the maximum URI length to 4095 - (the length of the
longest virtual host name)".

Can you clarify if this is correct? If so we would mark the CVE as
(unimportant) and thus as well not release a DSA, and a 1:1.2.42
upload to unstable can then mark the CVE as fixed.

Please let me know if the above statement about the issue beeing
relevant only under IIS is correct this way.

Regards,
Salvatore

Bug#839994: [pkg-cryptsetup-devel] Bug#839994: Newest version prevent boot of full encrypted disk

[Guilhem Moulin]

On Fri, 07 Oct 2016 at 11:10:08 +0100, Klaus Ethgen wrote:
>> This is an undocumented way of forcing cryptsetup initramfs integration.
>> As of 2:1.7.2-1, the hook script configuration variable are to be set in
>> /etc/crytsetup-initramfs/conf-hook, cf. the following changelog entry
>> 
>> * Use /etc/crytsetup-initramfs/conf-hook for initramfs hook script
>>  configuration.  For backward compatibility setting CRYPTSETUP and
>>  KEYFILE_PATTERN in /etc/initramfs-tools/initramfs.conf is still supported
>>  for now, but causes the hook to print a warning.
>>  This is done following the initramfs-tools maintainers' request (see
>>  #807527) that hook and boot script configuration files be stored outside
>>  the /etc/initramfs-tools directory. (Closes: #783393)
> 
> Ah, in that file (/etc/cryptsetup-initramfs/conf-hook, not
> /etc/crytsetup-initramfs/conf-hook) is a (empty) setting "CRYPTSETUP=".
> This file is from yesterday, and was installed by today with the
> upgrade.
> 
> However, that particulare problem was only about including cryptsetup
> out of the chroot from a recovery grml stick.
> 
> The current implementation following some documenations I had in the
> past. The main key is a file "initramfs-tools/conf.d/diskkey" with the
> following content:
> KEYFILE_PATTERN="/etc/security/disk.key"
> export KEYFILE_PATTERN

I see.  Indeed, we've unfortunately been too fast at releasing a fix for
#786578.  That is, we documented setting KEYFILE_PATTERN
/etc/initramfs-tools/initramfs.conf (or alternatively, under
/etc/initramfs-tools/conf.d) while the initramfs-tools maintainers later
(#807527) objected to using /etc/initramfs-tools for hook configuration:

“If a hook script requires configuration beyond the exported
variables listed below, it should read a private configuration file
that is separate from the /etc/initramfs-tools directory.  It must
not read initramfs-tools configuration files directly.” —
initramfs-tools(8)

Can you confirm your system boots as expected once you delete
/etc/initramfs-tools/conf.d/diskkey and use
/etc/cryptsetup-initramfs/conf-hook instead?  I'll push a proper fix
later today, to make the latter config file take precedence over
mkinitramfs(8) settings; but *not override them* as it's incorrectly
done now.  (Just to be clear, we *will* drop backward compatibility at
some point, but after at least one stable release cycle, and with a
loud warning printed at each update-initramfs run meanwhile.)

Cheers,
-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#836606: aspectc++/oclgrind: Please use llvm 3.8 or, better, 3.9

[Reinhard Tartler]

On 10/07/2016 05:56 AM, Gianfranco Costamagna wrote:
> control: tags -1 pending
>
>> Bumping severities accordingly.
> and now this is the last blocker.
>
> I imported new release, refactored a little bit the packaging and team 
> uploaded in deferred/2.
>
> changes are committed on git
>
> summary of the changes:
>
> * Team upload (collab-maint)
> * New upstream release
> * Add VCS browser and fix VCS fields
> * Bump std-version to 3.9.8
> * Bump compat level to 9
> * Switch to llvm 3.8 (Closes: #836606)
>
> G.
>

Thank you so much for this update, I'm sorry for not getting sooner to it!

Bug#831750: mini-buildd: Poor support for reverse proxy when working with apache

[Stephan Sürken]

Hi Boyuan,

On Di, 2016-07-19 at 09:55 +0800, Boyuan Yang wrote:
> Source: mini-buildd
> Version: 1.0.12
> Severity: normal

(...)

> However, someone may want to setup using reverse proxy. For example,
> let
> "https://mywebsite.com/debian/buildd/; proxy_pass to
> "http://localhost:8066/;.
> For apache, `mod_proxy` and `mod_rewrite` may be used to fix URLs in
> the HTML
> file.

fwiw, there is an example in mini-buildd

/usr/share/doc/mini-buildd/examples/apache-ssl-proxy.conf

which does "work for me" (albeit a somewhat different use case, afaiu).

> The problem is there are *always* some resource files failing with
> 404. The
(...)
> something else, and failed to be converted by mod_rewrite.

That's a little over my head for now ;).

I guess I need some more details about your configuration, and what
resources actually fail.

> May consider setting up an option for such situation, just as what
> gogs and
> some other web applications do.

What do you mean exactly here? Is there some django option to do just
that?

Thanks!

S

Bug#840002: [5.6.12 Version] Wrong version ordering with "+XXXX" suffixes

[Ole Streicher]

Package: packaging-manual

When a package uses a changed tarball (by removing some files from the
original one), this is usually indicated by adding a "+dfsg" or
"+repack" to the upstream version number.

This, however, may lead to a wrong version ordering of version numbers,
as seen in the "saods9" package:

The old package version is 7.5rc by upstream, which translates to
7.5~rc+repack for the (squeezed) debian orig tarball.

After that, upstream released a 7.5rc2, which would translate to
7.5~rc2+repack using the same rules.

However, they have the wrong order:

$ dpkg --compare-versions 7.5~rc+repack lt 7.5~rc2+repack && \
echo lt || echo ge
ge

dbkg is not to blame here, since this order is determined by the Debian
Policy, § 5.6.12.

IMO the policy should be changed here to handle the "+" differently
according to its common use: analogous to the "~" it should be sorted
before everything else, but /after/ the end of a part.

Best regards

Ole

Bug#839999: python3-gunicorn: fails to install: SyntaxError

[Chris Lamb]

forcemerge 83 839984
thanks

Andreas Beckmann wrote:

> during a test with piuparts I noticed your package failed to install. As
> per definition of the release team this makes the package too buggy for
> a release, thus the severity.

Already filed (and fixed!) in #83. Thanks for reporting :)


Regards,

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

Bug#784881: [pkg-cryptsetup-devel] Bug#784881: cryptsetup: WARNING: failed to detect canonical device

[Guilhem Moulin]

On Fri, 07 Oct 2016 at 11:55:35 +0200, Paride Legovini wrote:
> but I'm not sure of what happens when several devices contain a
> filesystem with the same UUID. I guess this is the reason for using
> devids instead of the uuid. In the case of multiple devices the output
> of btrfs filesystem show is:

Yeah, the UUID listed is that of the FS itself, while we want the
canonical names of each underlying device.

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#840001: mandos-client: fails to install noninteractively

[Andreas Beckmann]

Package: mandos-client
Version: 1.7.12-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package failed to install. As
per definition of the release team this makes the package too buggy for
a release, thus the severity.

piuparts tests installation in a chroot with
DEBIAN_FRONTEND=noninteractive.

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

  Selecting previously unselected package mandos-client.
  (Reading database ... 
(Reading database ... 9826 files and directories currently installed.)
  Preparing to unpack .../mandos-client_1.7.12-1_amd64.deb ...
  Unpacking mandos-client (1.7.12-1) ...
  Setting up mandos-client (1.7.12-1) ...
  gpg: agent_genkey failed: Inappropriate ioctl for device
  gpg: key generation failed: Inappropriate ioctl for device
  dpkg: error processing package mandos-client (--configure):
   subprocess installed post-installation script returned error exit status 2
  Errors were encountered while processing:
   mandos-client


cheers,

Andreas


mandos-client_1.7.12-1.log.gz
Description: application/gzip

Bug#840000: libapache-mod-jk: CVE-2016-6808

[Salvatore Bonaccorso]

Source: libapache-mod-jk
Version: 1:1.2.41-1
Severity: important
Tags: security upstream patch

Hi,

the following vulnerability was published for libapache-mod-jk.

CVE-2016-6808[0]:
buffer overflow

If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2016-6808

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#836193: Improper handling of arch all only package

[Stephan Sürken]

Hi Sam!

On Mi, 2016-08-31 at 06:50 -0400, Sam Hartman wrote:
> package: mini-buildd
> version: 1.0.12
> severity: normal
> 
> I uploaded  the source of an arch all package (no arch any in the
> resulting build) and got:
> 
> 2016-08-30 22:06:57,398 mini_buildd.packager (0039):(...) 

(...)

> issing_mandatory_archs), a=" ".join(missing_mandatory_archs)))
> Exception: 1 mandatory architecture(s) missing: amd64

Hmm -- there is the internal test package "mbd-test-archall"; this one
works fine for me.

> I'll admit that sbuild isn't great with that situation either; I've
> filed some bugs there too.

I assume this is #836154?

Could you be any means provide an URL to that failing DSC, so I can
check myself?

Thanks!

S

Bug#839999: python3-gunicorn: fails to install: SyntaxError

[Andreas Beckmann]

Package: python3-gunicorn
Version: 19.6.0-7
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package failed to install. As
per definition of the release team this makes the package too buggy for
a release, thus the severity.

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

  Selecting previously unselected package python3-gunicorn.
  (Reading database ... 
(Reading database ... 7406 files and directories currently installed.)
  Preparing to unpack .../python3-gunicorn_19.6.0-7_all.deb ...
  Unpacking python3-gunicorn (19.6.0-7) ...
  Setting up python3-gunicorn (19.6.0-7) ...
File "/usr/lib/python3/dist-packages/gunicorn/util.py", line 179
  except OSError, e:
^
  SyntaxError: invalid syntax
  
  dpkg: error processing package python3-gunicorn (--configure):
   subprocess installed post-installation script returned error exit status 1
  Errors were encountered while processing:
   python3-gunicorn


cheers,

Andreas


python3-gunicorn_19.6.0-7.log.gz
Description: application/gzip

Bug#839998: ntp: CVE-2016-0727: NTP statsdir cleanup cronjob insecure

[Salvatore Bonaccorso]

Source: ntp
Version: 1:4.2.6.p5+dfsg-2
Severity: normal
Tags: security patch

Hi,

the following vulnerability was published for ntp.

CVE-2016-0727[0]:
NTP statsdir cleanup cronjob insecure

If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2016-0727
[1] 
http://www.halfdog.net/Security/2015/NtpCronjobUserNtpToRootPrivilegeEscalation/

Regards,
Salvatore

Bug#838495: RFS: python-cartopy/0.14.2-1 [ITP]

[Ghislain Vaillant]

Hi Frederic,

I have uploaded a new version of python-cartopy/0.14.2+dfsg1-1 [1] for
you to review and sponsor.

I ended up doing a dfsg-repack of the source to exclude the files you
suggested, for which the copyright was either missing, non-free or
ambiguous.


[1] https://mentors.debian.net/debian/pool/main/p/python-cartopy/python
-cartopy_0.14.2+dfsg1-1.dsc

Please let me know whether you have any other comments.

Best regards,
Ghis

Bug#833667: freemat: FTBFS with LLVM 3.8

[Gianfranco Costamagna]

control: tags -1 patch pending

Hi, based on Graham little testing (sorry but I can't provide testing, I'll 
trust
his wordings), I uploaded on deferred/1 and git committed the patch on repo.

cheers

G.

Bug#839397: libwebkit2gtk-4.0-37: gobject-introspection on package build with webkit2gtk fails without active X session

[Alberto Garcia]

Control: forwarded -1 https://bugs.webkit.org/show_bug.cgi?id=163105

On Sat, Oct 01, 2016 at 02:42:55PM +0200, Paul Gevers wrote:

> In a last attempt to figure out what was going on, I build the
> package in my normal (stretch) environment, where the build fails
> latter on something else. This leads me to think that apperently a
> working X session is required. (I may be wrong).

Hey,

first of all, sorry for the late reply!

Yes, it seems that the webkit_settings_new() call in liferea checks
whether XComposite is enabled, and that fails if there's no X Session.

I'm not sure if this is a webkit bug, but I reported it upstream
anyway.

Possible solutions if you don't want to have a full-featured X
session:

- Run g-ir-scanner with xvfb-run
- Set the environment variable WEBKIT_DISABLE_COMPOSITING_MODE=1 when
  running g-ir-scanner

The latter is probably the easiest option.

Berto

Bug#836872: (caja:2909): Gtk-WARNING **: Theme parsing error: gtk-widgets.css:3397:17: Not using units is deprecated. Assuming 'px'.

[Mike Gabriel]

Control: tags -1 moreinfo

Hi Joao,

On  Di 06 Sep 2016 19:45:29 CEST, Joao Pedro wrote:


Package: caja
Version: 1.14.2-1
Severity: important

Dear Maintainer,

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


   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

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


From the but title we cannot tell where your issue is coming from.  
For sure it does not come from caja.


It is probably caused by the theme you use, but we don't have that  
information either. Please complete your bug report within the next  
week. If we don't here back from you, this bug will be closed.


Thanks,
Mike
--

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

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



pgpi99QZqHdIq.pgp
Description: Digitale PGP-Signatur

Bug#837537: "Mkdir: file exists" error if any debootstrap file download failed

[Stephan Sürken]

Hi Boyuan!

On Mi, 2016-09-14 at 10:43 +0800, Boyuan Yang wrote:

(...)

> to download *once*. The dir-chroot creating process should either
> fail
> immediately or re-run the debootstrap process again with a warning
> sent to the logger,
> but it just continued as if everything is fine *until* the mkdir
> error
> happens (which is due to the unclean exit of debootstrap, maybe?)

Hmm don't know. I tested around quite a lot lately, and did not
experience such a behavior.

Could you try to reproduce this with 1.0.21? This may have some nicer
logging for these calls, and maybe an excerpt of this log might shed
some light ;).

Thx!

P.S.: Ah: <= 1.0.21 has a little bug in the service file (mini-buildd
might not use the default log level), so you might want to apply this
first (or wait for 1.0.22):

diff --git a/debian/mini-buildd.service b/debian/mini-buildd.service
index 6809dda..0a184f2 100644
--- a/debian/mini-buildd.service
+++ b/debian/mini-buildd.service
@@ -4,6 +4,7 @@ Documentation=man:mini-buildd(8)
 After=remote-fs.target
 
 [Service]
+Environment=MINI_BUILDD_OPTIONS="--verbose"
 EnvironmentFile=-/etc/default/mini-buildd
 User=mini-buildd
 ExecStart=/usr/sbin/mini-buildd $MINI_BUILDD_OPTIONS

Bug#837195: mate-themes: causes theme parsing errors on stderr with gtk 3.21.5

[Mike Gabriel]

Hi Brian,

On  Sa 10 Sep 2016 01:09:58 CEST, brian m. carlson wrote:


Package: mate-themes
Version: 3.20.8-1
Severity: normal

When loading vim-gtk3, atril, or any other GTK+ 3 program from the
command line with GTK 3.21.5, I get messages like the following on
stderr (blank lines removed):

  (atril:917803): Gtk-WARNING **: Theme parsing error:  
mate-applications.css:415:16: not a number
  (atril:917803): Gtk-WARNING **: Theme parsing error:  
mate-applications.css:415:16: Expected a string.
  (atril:917803): Gtk-WARNING **: Theme parsing error:  
other-applications.css:146:13: not a number
  (atril:917803): Gtk-WARNING **: Theme parsing error:  
other-applications.css:146:13: Expected a string.


These messages appear regardless of what MATE theme I use (e.g. Menta)
but are no longer present if I switch to Adwaita.  (Some programs, such
as vim-gtk3, produce other messages, but those are probably better
handled by #832077.)


Can you check, if the above issue is gone with MATE 1.16 and  
mate-themes 3.22.3?


If the issue is fixed, please directly close this bug report with your  
answer mail.


Thanks,
Mike
--

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

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



pgpsiiSid7XjA.pgp
Description: Digitale PGP-Signatur

Bug#839184: zkCli.sh unusable as packaged

[Felix Dreissig]

Tags: patch

Hi,

sorry, I broke this with the patch from #830222: In commit 8c69d33, I moved
the "JAVA" environment variable to the init script, as it cannot not be used
in the systemd unit file (that requires absolute executable paths).

However, other ZooKeeper tools rely on it being set in zkEnv.sh, which is
symlinked to /etc/zookeeper/conf/environment on Debian.
This not only affects zkCli.sh, but also zkCleanup.sh and zkServer.sh. Another
similar situation occurs for zkServer.sh, which relies on "$ZOOCFGDIR". Even
though that script is not used by the init files from zookeeperd, it is still
part of the zookeeper package and should probably be working as well.

I think the easiest solution is to just re-add the variables to the
environment file, the attached patch does that.

An alternative would be changing the scripts to not use "$JAVA" and
"$ZOOCFGDIR", but that would required patching the upstream files. Or remove
the symlink and use another zkEnv.sh (like the one from upstream), but I can't
comprehend the implications of that.

Best regards,
Felix

java-env.patch
Description: Binary data

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

[Santiago Vila]

On Sun, 2 Oct 2016, Camm Maguire wrote:

> Greetings!  I just wanted to keep you abreast of the latest upload.
> I've put in an improvement which I hope will allow better use of the
> ram available without running into the fork/exec faults we had seen in
> some configurations.  This does not address the question of 'how much
> memory should we attempt to make use of', but you may find this upload
> more robust nonetheless.  GCL_MEM_MULTIPLE defaults back to 1.0 from
> 0.85 without apparent issue.
> 
> Feedback appreciated.

Hello.

I finally tested maxima_5.38.1-2 today.

On a machine with 6GB RAM and 4 GB swap, memory usage was about
7500 MB (1500 MB more than the available RAM).

On a machine with 3GB RAM and 4 GB swap, memory usage was about
3700 MB (700 MB more than the available RAM).

I'm still measuring memory usage with Committed_AS, by taking note of
its value during the build and substracting the value before the build
starts.

In your previous email, you suggest that I don't use Committed_AS
to measure memory usage, but something else.

I'm not sure what else I could use instead which is better than
Committed_AS, and I fear that the more memory I have available, the
more memory would maxima use as well, just as it happens with
Committed_AS, so are you sure that using something else other
than Committed_AS would really fix my problem?

Do you have a suggestion about which other parameter in /proc/meminfo
would be more suitable than Committed_AS?

Maybe this Committed_AS value being higher than the available RAM is
"normal and expected", but the way I see it, it seems part of a
general problem called "overcommit".

The question would be: How much overcommit should we reasonably expect
from a package when it's being built?

[ I still have to read your previous email in detail, this is just a
  first reply to tell my experience with maxima_5.38.1-2 ]

Thanks.

Bug#839250: - gunicorn backport >= 19.6.0-6

[Chris Lamb]

> > Right, but that's for stretch where the sysadmin will be clearly be
> > more aware of and/or even looking for issues. I don't want to break
> > existing systems right now.
 
> So how are packages using gunicorn to handle support for both stretch
> and jessie-backports? Packages in jessie can't be changed, so changes
> need to take place in backports to prepare for stretch. 
 
> Adding packages from backports should be about preparing for the next
> stable release.

I completely understand that and strongly agree, but *weighed up against*
breaking existing stable-based systems I relaly feel it the worst of two
bad options to upload it to backports.

I mean, I know I have deployed systems that--if they were to blindly
upgrade from backports after such an upload--would have a broken system!


Regards,

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

Bug#839994: [pkg-cryptsetup-devel] Bug#839994: Newest version prevent boot of full encrypted disk

[Klaus Ethgen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi Guilhem,

Am Fr den  7. Okt 2016 um 10:43 schrieb Guilhem Moulin:
> On Fri, 07 Oct 2016 at 10:20:08 +0100, Klaus Ethgen wrote:
> > However, it was not that easy to create the initramfs as the "most"
> > setting for MODULES do not include cryptsetup stuff and "dep" setting
> > does not work in a chroot.
> 
> Do you have CRYPTSETUP set in your /etc/initramfs-tools/initramfs.conf?

Ehem, no. The file has the following settings:
   MODULES=most
   BUSYBOX=y
   KEYMAP=n
   COMPRESS=gzip
   DEVICE=
   NFSROOT=auto

There is no mentioning about a "CRYPTSETUP" setting.

However, the "MODULES=most" setting gets overwritten in
/etc/initramfs-tools/conf.d/driver-policy to value "dep".

> This is an undocumented way of forcing cryptsetup initramfs integration.
> As of 2:1.7.2-1, the hook script configuration variable are to be set in
> /etc/crytsetup-initramfs/conf-hook, cf. the following changelog entry
> 
>   * Use /etc/crytsetup-initramfs/conf-hook for initramfs hook script
> configuration.  For backward compatibility setting CRYPTSETUP and
> KEYFILE_PATTERN in /etc/initramfs-tools/initramfs.conf is still supported
> for now, but causes the hook to print a warning.
> This is done following the initramfs-tools maintainers' request (see
> #807527) that hook and boot script configuration files be stored outside
> the /etc/initramfs-tools directory. (Closes: #783393)

Ah, in that file (/etc/cryptsetup-initramfs/conf-hook, not
/etc/crytsetup-initramfs/conf-hook) is a (empty) setting "CRYPTSETUP=".
This file is from yesterday, and was installed by today with the
upgrade.

However, that particulare problem was only about including cryptsetup
out of the chroot from a recovery grml stick.

The current implementation following some documenations I had in the
past. The main key is a file "initramfs-tools/conf.d/diskkey" with the
following content:
   KEYFILE_PATTERN="/etc/security/disk.key"
   export KEYFILE_PATTERN
   UMASK=0077

And the crypttab entry:
   _sda1 UUID=---- /etc/security/disk.key 
luks,discard

Gruß
   Klaus
- -- 
Klaus Ethgen   http://www.ethgen.ch/
pub  4096R/4E20AF1C 2011-05-16Klaus Ethgen 
Fingerprint: 85D4 CA42 952C 949B 1753  62B3 79D0 B06F 4E20 AF1C
-BEGIN PGP SIGNATURE-
Comment: Charset: ISO-8859-1

iQGcBAEBCgAGBQJX93RzAAoJEKZ8CrGAGfas1OAL/1bIF/GXGVttJJTP+qW13guw
77cvr53oSFtMAMXQOJf7aPwEAf6iJI9emobPiq9r/pTZYuJkoYiNrDFnpE/LEtpq
/yEAxYzt2y3HWdsWe+2MmHhisy1AKKNFAtBOmKtiL1FSDVzZo26RD4CwRPVTp4RU
iQmeOzgImh3/DzDJKxfd/l8IWoazEMlRMQwLdZzvfC1/E845F3bYJIXQVtRvyIra
xC7+eBrLjoExTJ/2HJs8/rorKDuy9rO/KpAZF3bGvq3A00xiKyDqBdb4SViOGbLB
GZGmkO6ymph5Pae/qH2Tq/hgIQoNTOq69cNf6IlQQ6V7toy0FLu65nFSyoRuSUBT
SDl7DDXVyfoJ+gNCHWAFyZrNpsg2eGDvTh84wr7xrPcg7/4jajx8SlmgCVZTALOR
HLC8mqkdwGWlAMA7In63j5+dezRYMPAyTc1BR1QmsMlH2SlCyVIPXIkKLQO1A9LP
X1w0L/fCKjs67RXPju9fosTOjS8+n7wANnMaJKxNsA==
=x+ek
-END PGP SIGNATURE-

Bug#839984: gunicorn3: Ancient Python code appeared in gunicorn/util.py file

[Chris Lamb]

tags 839984 + pending
thanks

Uploading now; sorry about that :)


Regards,

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

Bug#836606: aspectc++/oclgrind: Please use llvm 3.8 or, better, 3.9

[Gianfranco Costamagna]

control: tags -1 pending

> Bumping severities accordingly.
and now this is the last blocker.

I imported new release, refactored a little bit the packaging and team uploaded 
in deferred/2.

changes are committed on git

summary of the changes:

* Team upload (collab-maint)
* New upstream release
* Add VCS browser and fix VCS fields
* Bump std-version to 3.9.8
* Bump compat level to 9
* Switch to llvm 3.8 (Closes: #836606)

G.

Bug#813658: virgl status update?

[Daniel Pocock]

Has anybody considered building with --enable-virglrenderer now that the
dependency is available in sid, stretch and jessie-backports?

It may be possible to finally close this bug and it would be good to
have it working in stretch.

Please tell me if an update of the virglrenderer package is needed or
feel free to NMU / add yourself to uploaders

Bug#784881: [pkg-cryptsetup-devel] Bug#784881: cryptsetup: WARNING: failed to detect canonical device

[Paride Legovini]

On 2016-10-07 11:30, Guilhem Moulin wrote:
>> Perhaps we should add a --no-simplify to that loop?
> 
> Hmm but we'll still want unambiguous crypttab(5) lookups.  It's
> unfortunate that `btrfs filesystem` lists /dev/sda2 while the FS
> actually uses device UUIDs internally.  I think we need to call blkid(8)
> to pass the device's UUID to canonical_device().

This is the full output of btrfs filesystem show:

# btrfs filesystem show /
Label: none  uuid: 5651d651-5c48-425f-9fc9-56f2a9ad004f
Total devices 1 FS bytes used 211.01GiB
devid1 size 237.97GiB used 237.97GiB path /dev/sda2

the UUID is there, easy to parse, e.g.:

# btrfs filesystem show / | sed -nr 's/^Label: .+ uuid: (.+)/\1/p'
5651d651-5c48-425f-9fc9-56f2a9ad004f

but I'm not sure of what happens when several devices contain a
filesystem with the same UUID. I guess this is the reason for using
devids instead of the uuid. In the case of multiple devices the output
of btrfs filesystem show is:

Label: none  uuid: 21f33aaa-b2b3-464b-8cf1-0f8cc3689529
Total devices 3 FS bytes used 28.00KB
devid3 size 5.00GB used 1.01GB path /dev/sdd
devid2 size 5.00GB used 1.01GB path /dev/sdc
devid1 size 5.00GB used 2.02GB path /dev/sdb

Paride




signature.asc
Description: OpenPGP digital signature

Bug#839994: [pkg-cryptsetup-devel] Bug#839994: Newest version prevent boot of full encrypted disk

[Guilhem Moulin]

Hi Klaus,

On Fri, 07 Oct 2016 at 10:20:08 +0100, Klaus Ethgen wrote:
> However, it was not that easy to create the initramfs as the "most"
> setting for MODULES do not include cryptsetup stuff and "dep" setting
> does not work in a chroot.

Do you have CRYPTSETUP set in your /etc/initramfs-tools/initramfs.conf?
This is an undocumented way of forcing cryptsetup initramfs integration.
As of 2:1.7.2-1, the hook script configuration variable are to be set in
/etc/crytsetup-initramfs/conf-hook, cf. the following changelog entry

  * Use /etc/crytsetup-initramfs/conf-hook for initramfs hook script
configuration.  For backward compatibility setting CRYPTSETUP and
KEYFILE_PATTERN in /etc/initramfs-tools/initramfs.conf is still supported
for now, but causes the hook to print a warning.
This is done following the initramfs-tools maintainers' request (see
#807527) that hook and boot script configuration files be stored outside
the /etc/initramfs-tools directory. (Closes: #783393)

Of course, we didn't intend to break backward compatibility :-/  The
problem here is that sourcing /etc/initramfs-tools/initramfs.conf resets
the CRYPTSETUP variable to the empty string regardless of its previous
value.

-- 
Guilhem.


signature.asc
Description: PGP signature