Bug#798458: RFS: mini-httpd/1.21-1 [ITA] -- Small HTTP server

[Vincent Bernat]

 ❦ 10 septembre 2015 10:41 -0300, J.S.Júnior  :

>> Also, the use of 'index.mini-httpd.html' don't allow mini-httpd to find
>> it. The index names do not seem configurable. Therefore, you will need
>> to patch mini-httpd to also search for index.mini-httpd.html (after
>> index.html).
>
> I am a born programmer, but I think it iso. if you can help me thank you :)
>
> Create patch for find index.mini-httpd.html
>
> Send mentors again - ok

Sorry for the bikeshed, but some of the patch names and descriptions are
quite vague. fix-mini-httpd and fix-mini-httpd-vhost don't tell much
what they do from their names.

The description of fix-mini-httpd-vhost could be "Append port number to
vhost". The name of the patch could be "append-portno-to-vhost.patch". A
bug report number to know why this is done would be great to. Also, this
would make the Debian package behaves differently than upstream. Has
this patch been pushed upstream?

The description of fix-mini-httpd could be "Fix buffer overflow in
add_to_response". The name of the patch could be
"add_to_response-buffer-overflow.patch". The stuff about indexes should
be moved out to a different patch: when your patch is applied upstream,
you may discard it and forget about this part.

Please, keep the bug report in copy as it is the one place to go to see
what has already been told about this package.
-- 
Debian package sponsoring guidelines:
 http://vincent.bernat.im/en/debian-package-sponsoring.html


signature.asc
Description: PGP signature

Bug#798624: [libcgicc5-dev] unable to link with g++-5

[Peje Nilsson]

Package: libcgicc5-dev
Version: 3.2.9-3
Severity: normal

--- Please enter the report below this line. ---
I'm unable to link a program which uses libcgicc if I compile the
program with
g++-5 ( Konsole output gcc version 5.2.1 20150903 (Debian 5.2.1-16)) or
clang++-3.7 (Debian clang version 3.7.0-1 (tags/RELEASE_370/final)
(based on LLVM 3.7.0))


Compiling the following example fetched from
http://www.gnu.org/software/cgicc/doc/cgicc_tutorial.html
Konsole output
#include 
#include 
#include 

#include "cgicc/Cgicc.h"
#include "cgicc/HTTPHTMLHeader.h"
#include "cgicc/HTMLClasses.h"

using namespace std;
using namespace cgicc;

int  
main(int argc,  
char **argv)
{
  try {
 Cgicc cgi;

 // Send HTTP header
 cout << HTTPHTMLHeader() << endl;

 // Set up the HTML document
 cout << html() << head(title("cgicc example")) << endl;
 cout << body() << endl;

 // Print out the submitted element
 form_iterator name = cgi.getElement("name");
 if(name != cgi.getElements().end()) {
cout << "Your name: " << **name << endl;
 }

 // Close the HTML document
 cout << body() << html();
  }
  catch(exception& e) {
 // handle any errors - omitted for brevity
  }
}

I get:

Konsole output
$ g++-5 testcgicc.cpp   -o testcgicc -lcgicc
/tmp/user/1000/ccLyuNZj.o: In function `main':
testcgicc.cpp:(.text+0x1d8): undefined reference to
`cgicc::Cgicc::getElement(std::__cxx11::basic_string const&)'
testcgicc.cpp:(.text+0x25c): undefined reference to
`cgicc::FormEntry::operator*[abi:cxx11]() const'
/tmp/user/1000/ccLyuNZj.o: In function
`cgicc::HTMLBooleanElement::HTMLBooleanElement()':
testcgicc.cpp:(.text._ZN5cgicc18HTMLBooleanElementINS_7htmlTagEEC2Ev[_ZN5cgicc18HTMLBooleanElementINS_7htmlTagEEC5Ev]+0x
29): undefined reference to
`cgicc::HTMLElement::HTMLElement(cgicc::HTMLAttributeList const*,
cgicc::HTMLElement const*,
std::__cxx11::basic_string const*, cgicc::HTMLElement::EElementTyp
e)'
/tmp/user/1000/ccLyuNZj.o: In function
`cgicc::HTMLBooleanElement::HTMLBooleanElement(std::__cxx11::bas
ic_string
const&)':
testcgicc.cpp:(.text._ZN5cgicc18HTMLBooleanElementINS_8titleTagEEC2ERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcE
EE[_ZN5cgicc18HTMLBooleanElementINS_8titleTagEEC5ERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE]+0x2f):
undefin
ed reference to
`cgicc::HTMLElement::HTMLElement(cgicc::HTMLAttributeList const*,
cgicc::HTMLElement const*, std::__cxx1
1::basic_string
const*, cgicc::HTMLElement::EElementType)'
/tmp/user/1000/ccLyuNZj.o: In function
`cgicc::HTMLBooleanElement::HTMLBooleanElement(cgicc::HTMLElement
const&)':   
   
testcgicc.cpp:(.text._ZN5cgicc18HTMLBooleanElementINS_7headTagEEC2ERKNS_11HTMLElementE[_ZN5cgicc18HTMLBooleanElementINS_
7headTagEEC5ERKNS_11HTMLElementE]+0x2c): undefined reference to
`cgicc::HTMLElement::HTMLElement(cgicc::HTMLAttributeLis
t const*, cgicc::HTMLElement const*, std::__cxx11::basic_string con
st*, cgicc::HTMLElement::EElementType)'
/tmp/user/1000/ccLyuNZj.o: In function
`cgicc::HTMLBooleanElement::HTMLBooleanElement()':
testcgicc.cpp:(.text._ZN5cgicc18HTMLBooleanElementINS_7bodyTagEEC2Ev[_ZN5cgicc18HTMLBooleanElementINS_7bodyTagEEC5Ev]+0x
29): undefined reference to
`cgicc::HTMLElement::HTMLElement(cgicc::HTMLAttributeList const*,
cgicc::HTMLElement const*,
std::__cxx11::basic_string const*, cgicc::HTMLElement::EElementTyp
e)'
collect2: error: ld returned 1 exit status


--- System information. ---
Architecture: amd64
Kernel: Linux 4.1.0-2-amd64

Debian Release: stretch/sid
900 unstable ftp.se.debian.org
900 unstable deb-multimedia.org
800 testing security.debian.org
800 testing ftp.se.debian.org
800 testing deb-multimedia.org
60 stable silk.apana.org.au
60 stable security.debian.org
60 stable repository.spotify.com
60 stable packages.x2go.org
60 stable ftp.se.debian.org
60 stable dl.google.com
60 stable deb-multimedia.org
500 precise ppa.launchpad.net
500 jessie linux.dropbox.com
500 intrepid ppa.launchpad.net
49 experimental ftp.se.debian.org

--- Package information. ---
Depends (Version) | Installed
=-+-
libcgicc5 (= 3.2.9-3) | 3.2.9-3


Package's Recommends field is empty.

Suggests (Version) | Installed
===-+-===
libcgicc-doc |

Bug#798622: openldap: ber_get_next denial of service vulnerability

[Salvatore Bonaccorso]

Source: openldap
Version: 2.4.31-2
Severity: important
Tags: security patch upstream fixed-upstream
Forwarded: http://www.openldap.org/its/index.cgi/Software%20Bugs?id=8240

Hi

See http://www.openldap.org/its/index.cgi/Software%20Bugs?id=8240 . A
patch is available at
http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=commitdiff;h=6fe51a9ab04fd28bbc171da3cf12f1c1040d6629

Regards,
Salvatore

Bug#798512: linux-image-3.16.0-4-amd64: e1000e hangs with Intel I217-LM

[Lucas Nussbaum]

On 10/09/15 at 14:04 +0200, Vincent Bernat wrote:
>  ❦ 10 septembre 2015 13:56 +0200, Lucas Nussbaum  :
> 
> >> > Dmesg output during the hangs:
> >> > [  876.069592] e1000e :00:19.0 eth0: Detected Hardware Unit Hang:
> >> 
> >> You can try disabling some of the offloading functions:
> >> 
> >>ethtool -K eth0 tso off gro off gso off lro off
> >
> > Yes, I saw that mentioned somewhere. But I haven't tried yet. And it's
> > not really a suitable long-term fix. :)
> > If that helps to understand the root issue, I can try that next week or
> > the week after (but the machine is in production now, so it's not that
> > easy).
> 
> Whatever the result is, it's just a workaround. The "Detected Hardware
> Unit Hang" error is quite generic and I have never found a way to get a
> probable root cause.

Well in that case, given it's fixed in 4.1, it's probably more a matter
of identifying the fix and backporting it to jessie.

Lucas


signature.asc
Description: Digital signature

Bug#796297: libcrypto++: FTBFS on armel: DH validation suite: FAILED simple key agreement domain parameters invalid

[GCS]

On Fri, Aug 21, 2015 at 10:09 AM, Christian Hofstaedtler
 wrote:
> Package: libcrypto++
> Version: 5.6.1-8
> Severity: serious
> Justification: fails to build from source
>
> libcrypto++ failed to build on armel. Hopefully relevant snippet:
>
> BlumBlumShub validation suite running...
>
> passed49ea2cfdb01064a0bbb92af101dac18a94f7b7ce
> FAILED53171c6887956cea5d3b
> FAILED49383dc6167a2638473fd4a183170f44d46d0c85
[...]
 Just for the record, I give a helping hand to upstream solving this.
It happens on different architectures with different GCC versions (4.9
to 5.2 at least) - but with different optimization levels it does
_not_. I suspect some GCC anomalies, but don't know more details yet.

Regards,
Laszlo/GCS

Bug#748056: systemd: can't boot properly when unable to mount a hibernated NTFS partition

[Michael Biebl]

On Mon, 17 Nov 2014 13:14:49 +0100 intrigeri  wrote:
> Hi,
> 
> Michael Biebl wrote (03 Jul 2014 21:07:36 GMT) :
> > Am 03.07.2014 20:57, schrieb Michal Suchanek:
> >> Also candidate for big fat release note.
> 
> > Nod. I guess the recommendation here is to simply mark non-critical
> > mounts as nofail.
> > [...]
> > So maybe just documenting the fact that this needs to be done by the
> > administrator is the best way.
> 
> So, how about:
> 
> 1. retitling this bug "Document behavior on missing/faulty filesystems

I retitled the bug report.

>more prominently" (not sure if the doc should be in fstab(5)
>and/or in systemd's NEWS.Debian)

I don't think a NEWS.Debian entry would help that much. Afaik, such an
entry would only be shown on *upgrades* of systemd, not fresh
installations. It's also not really a behavioural change *in* systemd
itself, only compared to sysvinit.

Maybe adding it to README.Debian would be better.

> 2. filing a release notes bug, whose expected outcome would be
>a paragraph in the release notes that points to the aforementioned
>documentation

That has happened for the jessie release notes which had a dedicated
section about this specific issue.

Michael


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



signature.asc
Description: OpenPGP digital signature

Bug#743217: [Pkg-systemd-maintainers] Bug#743217: systemd: systemctl enabled/disable does not print what it's doing with the unit file

[Michael Biebl]

On Mon, 31 Mar 2014 20:24:28 +0200 Ralf Jung  wrote:
> Hi,
> 
> > Hm, true. Completely missed that bit.
> > Somehow systemctl enable|disable only outputs the symlinks
> > created|created by Alias= but not WantedBy=
> > 
> > I guess this more accurately describes the bug, right?
> 
> Correct.

Looking at this bug again, this is actually an issue in update-rc.d.

We first call update-rc.d foo enable|disable if there is a matching sysv
init script.
update-rc.d then goes on and *also* handles the WantedBy= symlinks, and
does so silently.

If update-rc.d is called by systemctl, it should probably *not* process
the .service file and only handle the sysv init script.

The reason why update-rc.d has (limited) support for .service files is,
that it's not guaranteed that systemctl is always available and we
wanted to make sure the state is kept in sync.

We should rework this integration:

- If systemctl is installed and systemctl calls update-rc.d, update-rc.d
should *not* process the native .service file
- If systemctl is installed and the user runs update-rc.d foo
disable|enable, update-rc.d should call systemctl.
- If systemctl is not installed and the user runs update-rc.d, the
fallback in update-rc.d to process .service files should be called.



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



signature.asc
Description: OpenPGP digital signature

Bug#798625: systemd-networkd: Runs arbitrary inappropriate scripts on network changes

[Josh Triplett]

Package: systemd
Version: 226-1
Severity: normal

[Filing this as "normal" only because systemd-networkd is not yet
normally used in Debian, and is not packaged separately; this is
release-critical for systemd-networkd.]

>From the changelog of 226-1:

  * Make networkd call if-up.d/ scripts when it brings up interfaces, to
become compatible with ifupdown and NetworkManager for packages shipping
hooks. (LP: #1492129)

(Along with various other changes related to these hooks.)

This is an *extremely* bad idea; please revert it before any package
incorrectly starts to rely on it.  And this should have been discussed
on at least pkg-systemd-maintainers, if not systemd-devel, before being
implemented.

Several reasons why this is a bad idea:

- networkd is intended to bring up interfaces *quickly*, on the order of
  microseconds (not milliseconds) even with DHCP, let alone without.
  Spawning arbitrary processes, and especially shell scripts, is not and
  will never be compatible with networkd's performance requirements.

- These hooks don't exist upstream.  Packages shipping if-up.d hooks are
  thus still broken anywhere other than Debian, and even *in* Debian
  they're broken with dynamic network configuration.  Those package need
  fixing (upstream) to handle dynamic network configuration, and once
  they do, the Debian-specific hooks become obsolete.  Allowing these
  hooks makes it less obvious that the packages themselves need fixing.

- Network configuration can change at any time, and networkd is not
  stateful; state lives in the kernel, not in networkd.  These hooks
  break that assumption.  (This will also likely break with future
  changes to networkd and other packages integrating with it, as well as
  with other types of interfaces or virtual networks networkd can
  configure.)  Among other things, as the systemd-networkd manpage
  documents, "Network configurations applied before networkd is started
  are not removed, and static configuration applied by networkd is not
  removed when networkd exits. Dynamic configuration applied by networkd
  may also optionally be left in place on shutdown. This ensures
  restarting networkd does not cut the network connection, and, in
  particular, that it is safe to transition between the initrd and the
  real root, and back."

- Several of the existing if-up.d and if-post-down.d hooks should not
  run under networkd.  Among others: wpasupplicant's hooks shouldn't run
  at all under anything but ifupdown, mountnfs's hooks shouldn't run
  (because they conflict with several other approaches to nfs handling
  that integrate properly with systemd), avahi-daemon's hook is
  responsible for numerous problems and slowdowns even under
  ifupdown, and wireless-tools' hook shouldn't run under anything but
  ifupdown.

- Calling if-up.d and if-post-down.d, but not calling if-down.d or
  if-pre-up.d, may well break assumptions that a family of scripts in
  those directories have about when they'll be called and what state
  machine they'll go through.

Packages shipping if-up.d or if-post-down.d scripts are not compatible
with networkd.  Primarily because they aren't compatible with
dynamically changing network configurations, and secondarily because
they tend to do the kind of really silly things that happen with
arbitrary shell-script hooks available.  This is not the right way to
fix that problem.

What specific problem is this trying to solve?  If there are specific
packages you're trying to fix or integrate with, perhaps we could talk
about other solutions to work with those packages (including the
possibility of writing patches to either those packages or networkd to
improve such integration).

- Josh Triplett

-- Package-specific info:

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

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

Versions of packages systemd depends on:
ii  adduser 3.113+nmu3
ii  libacl1 2.2.52-2
ii  libapparmor12.9.2-3
ii  libaudit1   1:2.4.4-1
ii  libblkid1   2.27-1
ii  libc6   2.19-19
ii  libcap2 1:2.24-11
ii  libcap2-bin 1:2.24-11
ii  libcryptsetup4  2:1.6.6-5
ii  libgcrypt20 1.6.3-2
ii  libkmod221-1
ii  liblzma55.1.1alpha+20120614-2.1
ii  libmount1   2.27-1
ii  libpam0g1.1.8-3.1
ii  libseccomp2 2.2.3-2
ii  libselinux1 2.3-2+b1
ii  libsystemd0 226-1
ii  mount   2.27-1
ii  sysv-rc 2.88dsf-59.2
ii  udev226-1
ii  util-linux  2.27-1

Versions of packages systemd recommends:
ii  dbus1.8.20-1
ii  libpam-systemd  226-1

Versions of packages systemd suggests:
pn  systemd-container  
pn  systemd-ui 

-- Configuration Files:

Bug#798668: pcscd removes socket which systemd uses for autostart

[Eric Reischer]

Package: pcscd
Version: 1.8.13-1
Severity: important
Tags: upstream

systemd, in its infinite wisdom, listens to /var/run/pcscd/pcscd.comm for 
connections and starts up the pcscd
service on-demand if any connections come in.  However, when pcscd exits, it 
"cleans" the /var/run/pcscd folder,
thus removing the pcscd.comm file. Examination of systemctl list-sockets shows 
it is supposedly listening on that
socket, but with the file descriptor removed by the daemon (when it auto-exits, 
or when the daemon was started
manually and then terminated), systemd will never start up the program again 
because clients cannot connect to
a nonexistant FD.  Additionally, when the service is started manually via 
init.d scripts, the socket is not auto-
created as it is when it is run directly via the command line.

This is probably a bug both in pcscd and systemd, the former for not checking 
if the socket FD exists upon startup
from systemd, and the latter for not doing the same upon shutdown of the daemon 
or at least semi-periodically. The
only method I've found to re-create this socket FD is to restart the system; 
obviously not an acceptable workaround.

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

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

Versions of packages pcscd depends on:
ii  init-system-helpers   1.22
ii  libc6 2.19-18+deb8u1
ii  libgcr410 [pcsc-ifd-handler]  2.4.0-9.2
ii  libpcsclite1  1.8.13-1
ii  libudev1  215-17+deb8u2
ii  lsb-base  4.1+Debian13+nmu1

pcscd recommends no packages.

Versions of packages pcscd suggests:
ii  systemd  215-17+deb8u2

-- no debconf information

Bug#798672: qdox: please upgrade qdox to version 2.x

[Markus Koschany]

Source: qdox
Version: 1.12.1-1
Severity: wishlist


Hi,

while I was working on an update of paranamer, I discovered that this
would require an update of qdox as well.

We need the latest upstream release

https://github.com/codehaus/qdox/releases/tag/qdox-2.0-M3

I am filing this bug report as a reminder and blocking bug.

Markus

Bug#798679: Actually all translations are broken

[Julien Aubin]

Hi,

Actually when testing with Polish translation I remarked the same thing.

All the translations seem to be broken.

Bug#798684: unknown deveice - epswrite

[prathibhab]

Package: easychem
Version: 0.6-8

ghostscript package version 9.16~dfsg-2.

Issue: Onclicking File->Export->EPS, optimized for size, the following error is
displayed on the terminal:

Unknown device: epswrite

Solution:

epswrite device is deprecated as of the 9.12 release, the eps2write device
should be used instead which does not suffer these limitations. Ref:
http://ghostscript.com/doc/current/Issues.htm

Patch for resolving the same attached.

Regards,
Prathibha
Senior Engineer
CDAC Chennai

---
[ C-DAC is on Social-Media too. Kindly follow us at:
Facebook: https://www.facebook.com/CDACINDIA & Twitter: @cdacindia ]

This e-mail is for the sole use of the intended recipient(s) and may
contain confidential and privileged information. If you are not the
intended recipient, please contact the sender by reply e-mail and destroy
all copies and the original message. Any unauthorized review, use,
disclosure, dissemination, forwarding, printing or copying of this email
is strictly prohibited and appropriate legal action will be taken.
---

Description: 
   * epswrite changed to eps2write. Fixes the following error: unknown device - epswrite
Author: Prathibha B 

---
The information above should follow the Patch Tagging Guidelines, please
checkout http://dep.debian.net/deps/dep3/ to learn about the format. Here
are templates for supplementary fields that you might want to add:

Origin: , 
Bug: 
Bug-Debian: https://bugs.debian.org/
Bug-Ubuntu: https://launchpad.net/bugs/
Forwarded: 
Reviewed-By: 
Last-Update: 

--- /dev/null
+++ easychem-0.6/.save.ech
@@ -0,0 +1,3 @@
+# Save file for EasyChem (version 0.6)
+
+smpl 13300 8700 19700 14300 0 0 0 0 1 0 0 0
--- easychem-0.6.orig/export.c
+++ easychem-0.6/export.c
@@ -2084,7 +2084,7 @@ eps_size_export (struct Bond *list, char
   gchar *option;
   int fd, pid, i, j, k, l;
   FILE *file, *in, *out;
-  char *argv[11] = { "gs", "-dNOPAUSE", "-q", "-sDEVICE=epswrite", "-dBATCH",
+  char *argv[11] = { "gs", "-dNOPAUSE", "-q", "-sDEVICE=eps2write", "-dBATCH",
 "-dSAFER", "", "", "-dDEVICEWIDTH=25", "-dDEVICEHEIGHT=25", NULL
   };
 

Bug#798685: ruby-json: Contains file released under a nonfree license

[Daniel Milewski]

Source: ruby-json
Version: 1.8.3-1
Severity: serious

I've found this notice in the json
-1.8.3/ext/json/ext/generator/generator.c file:

/*
 * Copyright 2001-2004 Unicode, Inc.
 *
 * Disclaimer
 *
 * This source code is provided as is by Unicode, Inc. No claims are
 * made as to fitness for any particular purpose. No warranties of any
 * kind are expressed or implied. The recipient agrees to determine
 * applicability of information provided. If this file has been
 * purchased on magnetic or optical media from Unicode, Inc., the
 * sole remedy for any claim will be exchange of defective media
 * within 90 days of receipt.
 *
 * Limitations on Rights to Redistribute This Code
 *
 * Unicode, Inc. hereby grants the right to freely use the information
 * supplied in this file in the creation of products supporting the
 * Unicode Standard, and to make copies of this file in any form
 * for internal or external distribution as long as this notice
 * remains attached.
 */

This makes the file nonfree, at least according to the FSF which I
asked about this.

Since the JSON parser contains two parallel implementations of the same
code, native variant and pure Ruby variant, one way to solve this would
be to use the pure Ruby variant by default. I solved the bug this way
for another free distro Parabola[1].

[1] https://projects.parabola.nu/abslibre/abslibre.git/tree/libre/ruby

-- 
Daniel Milewski
GPG key ID: 8D43A4A1


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

Bug#778034: ogre-1.9 transition, blender needs binNMU

[Jonathan Wiltshire]

On Fri, Sep 11, 2015 at 10:33:32AM -0400, Scott Howard wrote:
> Looks like blender needs a binNMU to build against the v5 version of
> opencolorio. Then blender, ogre-1.9, and dependencies can transition
> https://packages.qa.debian.org/b/blender.html

Thanks, scheduled.

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

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



signature.asc
Description: Digital signature

Bug#798689: RM: qapt/experimental -- RoQA; superseded by libqapt 3.0.0

[Andreas Beckmann]

Package: ftp.debian.org
Severity: normal

qapt 1.3.0 was already removed from unstable
(https://bugs.debian.org/797753)
The source package has been renamed to libqapt.


Andreas

Bug#798683: ruby-json: Contains file released under a nonfree license

[Daniel Milewski]

Source: ruby-json
Version: 1.8.1-1
Severity: serious

I've found this notice in the json
-1.8.1/ext/json/ext/generator/generator.c file:

/*
 * Copyright 2001-2004 Unicode, Inc.
 *
 * Disclaimer
 *
 * This source code is provided as is by Unicode, Inc. No claims are
 * made as to fitness for any particular purpose. No warranties of any
 * kind are expressed or implied. The recipient agrees to determine
 * applicability of information provided. If this file has been
 * purchased on magnetic or optical media from Unicode, Inc., the
 * sole remedy for any claim will be exchange of defective media
 * within 90 days of receipt.
 *
 * Limitations on Rights to Redistribute This Code
 *
 * Unicode, Inc. hereby grants the right to freely use the information
 * supplied in this file in the creation of products supporting the
 * Unicode Standard, and to make copies of this file in any form
 * for internal or external distribution as long as this notice
 * remains attached.
 */

This makes the file nonfree, at least according to the FSF which I
asked about this.

Since the JSON parser contains two parallel implementations of the same
code, native variant and pure Ruby variant, one way to solve this would
be to use the pure Ruby variant by default. I solved the bug this way
for another free distro Parabola[1].

[1] https://projects.parabola.nu/abslibre/abslibre.git/tree/libre/ruby

-- 
Daniel Milewski
GPG key ID: 8D43A4A1


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

Bug#798682: unknown deveice - epswrite

[prathibhab]

Package: easyche,
Version: 0.6-8

ghostscript package version 9.16~dfsg-2.

Issue: Onclicking File->Export->EPS, optimized for size, the following error is
displayed on the terminal:

Unknown device: epswrite

Solution:

epswrite device is deprecated as of the 9.12 release, the eps2write device
should be used instead which does not suffer these limitations. Ref:
http://ghostscript.com/doc/current/Issues.htm

Patch for resolving the same attached.

Regards,
Prathibha
Senior Engineer
CDAC Chennai

---
[ C-DAC is on Social-Media too. Kindly follow us at:
Facebook: https://www.facebook.com/CDACINDIA & Twitter: @cdacindia ]

This e-mail is for the sole use of the intended recipient(s) and may
contain confidential and privileged information. If you are not the
intended recipient, please contact the sender by reply e-mail and destroy
all copies and the original message. Any unauthorized review, use,
disclosure, dissemination, forwarding, printing or copying of this email
is strictly prohibited and appropriate legal action will be taken.
---

Description: 
   * epswrite changed to eps2write. Fixes the following error: unknown device - epswrite
Author: Prathibha B 

---
The information above should follow the Patch Tagging Guidelines, please
checkout http://dep.debian.net/deps/dep3/ to learn about the format. Here
are templates for supplementary fields that you might want to add:

Origin: , 
Bug: 
Bug-Debian: https://bugs.debian.org/
Bug-Ubuntu: https://launchpad.net/bugs/
Forwarded: 
Reviewed-By: 
Last-Update: 

--- /dev/null
+++ easychem-0.6/.save.ech
@@ -0,0 +1,3 @@
+# Save file for EasyChem (version 0.6)
+
+smpl 13300 8700 19700 14300 0 0 0 0 1 0 0 0
--- easychem-0.6.orig/export.c
+++ easychem-0.6/export.c
@@ -2084,7 +2084,7 @@ eps_size_export (struct Bond *list, char
   gchar *option;
   int fd, pid, i, j, k, l;
   FILE *file, *in, *out;
-  char *argv[11] = { "gs", "-dNOPAUSE", "-q", "-sDEVICE=epswrite", "-dBATCH",
+  char *argv[11] = { "gs", "-dNOPAUSE", "-q", "-sDEVICE=eps2write", "-dBATCH",
 "-dSAFER", "", "", "-dDEVICEWIDTH=25", "-dDEVICEHEIGHT=25", NULL
   };
 

Bug#798674: apache-directory-server: please enable apacheds-all jar in libapacheds-java.poms

[Markus Koschany]

Source: apache-directory-server
Version: 2.0.0~M15-1
Severity: wishlist

Hi,

I am currently packaging the undertow web server which is a
prerequisite for packaging syncany. I'm not sure yet, if I really want
to maintain both packages but to make it happen, undertow requires
the artifact apacheds-all as a test dependency and I would like to
run the tests.

It would therefore be nice to remove the --ignore flag for all/pom.xml in
libapacheds-java.poms.

Markus

Bug#439267: Post-install sources.list should contain commented-out generic URIs

[Thierry Granier]

Bonjour,
vous pouvez m'appeler lundi entre 13h et 14h
ou mardi et mercredi entre 12 et 14h
Cordialement
T Granier

Le 11/09/2015 15:10, Chris Lamb a écrit :

Chris Lamb wrote:


If installing via CD or DVD, the sources.list post-installation
should contain the generic APT URIs commented-out. For example:

#deb http://ftp.debian.org/debian/ stable main
#deb-src http://ftp.debian.org/debian/ stable main

deb 

This would help users to quickly enable internet-based sources if required.

[..]


I can see two problems with it, however:

  0. Arbitrary "gb -> uk"-like mappings may get crufty over time.

We can now revisit this given that we have "httpredir.debian.org".
Whilst not a perfect solution, it would at least be commented-out by
default (and thus cannot break anyone's installation).


Regards,

Bug#733227: libxcb-xinput required for KF5+wacomtablet/kde-config-tablet

[Gregor Riepl]

stretch is currently lacking a package for kde-config-tablet, as wacomtablet
is still being ported to KF5. I tried building the package from git, but was
hit by a missing xcb-xinit.

Please add --enable-xinput to the libxcb build settings and create
libxcb-xinput and libxcb-xinput-dev packages.

Thank you!

Bug#798669: ITP: python-django-formtools -- set of high-level abstractions for Django forms

[Thomas Goirand]

Package: wnpp
Severity: wishlist
Owner: Thomas Goirand 

* Package name: python-django-formtools
  Version : 1.0
  Upstream Author : Django Software Foundation 
* URL : https://github.com/django/django-formtools
* License : BSD-3-clause
  Programming Lang: Python
  Description : set of high-level abstractions for Django forms

 Django's formtools is a set of high-level abstractions for Django forms.
 Currently for form previews and multi-step forms.
 .
 This code used to live in Django proper: in django.contrib.formtools. But it
 was separated into a standalone package in Django 1.8 to keep the framework's
 core clean.

This is a new dependency of OpenStack murano-dashboard.

Bug#797860: [RFR] templates://open-iscsi/{open-iscsi.templates}

[Justin B Rye]

Christian Seiler wrote:
>>  Description: iSCSI management tools
> 
> Actually, if we are changing the description of the package as well,
> I'd rather be more specific:
> 
>  Description: iSCSI initiator tools
> 
> Because there are also iSCSI targets packaged in Debian (iscsitarget,
> targetcli), and management seems to be too generic of a word.

This is reaching the point where I'm glad of the caveat in my sig, but
here's an updated patch.
-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package
diff -ru open-iscsi-2.0.873+git0.3b4b4500.pristine/debian/control 
open-iscsi-2.0.873+git0.3b4b4500/debian/control
--- open-iscsi-2.0.873+git0.3b4b4500.pristine/debian/control2015-08-29 
09:14:14.0 +0100
+++ open-iscsi-2.0.873+git0.3b4b4500/debian/control 2015-09-11 
17:08:20.506135626 +0100
@@ -13,21 +13,23 @@
 Architecture: any
 Depends: ${shlibs:Depends}, ${misc:Depends}, udev
 Pre-Depends: debconf | debconf-2.0
-Description: High performance, transport independent iSCSI implementation
+Description: iSCSI initiator tools
  Open-iSCSI is a high-performance, transport independent, multi-platform
- implementation of RFC3720 iSCSI
+ implementation of the RFC3720 Internet Small Computer Systems Interface
+ (iSCSI).
  .
- Open-iSCSI is partitioned into user and kernel parts where the kernel
- portion implements iSCSI data path (i.e. iSCSI Read and iSCSI Write)
- The userspace contains the entire control plane consisting of:
-  * Configuration Manager
-  * iSCSI Discovery, Login and Logout processing
-  * Connection level error processing
-  * Nop-In and Nop-Out handling
-  * Text processing, iSNS, SLP, Radius et cetera (future)
+ Open-iSCSI is partitioned into user and kernel parts, where the kernel
+ portion implements the iSCSI data path (i.e. iSCSI Read and iSCSI Write).
+ The userspace contains the entire control plane:
+  * Configuration Manager;
+  * iSCSI Discovery;
+  * Login and Logout processing;
+  * Connection level error processing;
+  * Nop-In and Nop-Out handling;
+  * (in the future) Text processing, iSNS, SLP, Radius, etc.
  .
- The userspace component consists of a daemon, iscsid and a management
- utility, iscsiadm
+ This package includes a daemon, iscsid, and a management utility,
+ iscsiadm.
 
 Package: open-iscsi-udeb
 # Note: the (virtual) udeb package scsi-modules (provided by different
@@ -40,7 +42,8 @@
 Depends: ${shlibs:Depends}, ${misc:Depends}, scsi-modules, libnss-files-udeb
 Description: Configure iSCSI
  Open-iSCSI is a high-performance, transport independent, multi-platform
- implementation of RFC3720 iSCSI.
+ implementation of the RFC3720 Internet Small Computer Systems Interface
+ (iSCSI).
  .
  This is the minimal package (udeb) used by debian-installer.
 
@@ -50,4 +53,3 @@
 #Description: Source Code for the Linux iSCSI Kernel Modules
 # Along with make-kpkg, this package maybe used to build a linux-iscsi-modules 
 # package for a kernel-image package.
-
diff -ru open-iscsi-2.0.873+git0.3b4b4500.pristine/debian/open-iscsi.templates 
open-iscsi-2.0.873+git0.3b4b4500/debian/open-iscsi.templates
--- open-iscsi-2.0.873+git0.3b4b4500.pristine/debian/open-iscsi.templates   
2015-08-29 09:14:14.0 +0100
+++ open-iscsi-2.0.873+git0.3b4b4500/debian/open-iscsi.templates
2015-09-11 12:33:52.281669203 +0100
@@ -1,31 +1,35 @@
 Template: open-iscsi/remove_even_with_active_sessions
 Type: boolean
-_Description: Do you want to proceed with removing open-iscsi?
+#flag:translate!:6,8
+_Description: Proceed with removing open-iscsi?
  There are currently active iSCSI sessions. If you remove open-iscsi
- now this may lead to data loss and/or hang your system at shutdown.
+ now this may lead to data loss and/or hang the system at shutdown.
  .
- DO NOT DO THIS IF YOUR ROOT FILESYSTEM IS ON ISCSI!
+ Do not do this if this system's root filesystem is on iSCSI.
  .
  If you do proceed, open-iscsi will try to unmount all filesystems on
- iSCSI and logout from current sessions. If that fails (because a
- filesystem is still in use), the kernel will keep open the current
- iSCSI sessions, but not perform any recovery in case there is an
- interruption of the network connection (or the target is rebooted
- etc.).
+ iSCSI and log out from current sessions. If that fails (because a
+ filesystem is still in use), the kernel will keep the current
+ iSCSI sessions open, but will not perform any recovery if there is an
+ interruption of the network connection (or if the target is rebooted).
+ .
+ If you really intend to remove open-iscsi, you should abort here and
+ then stop open-iscsi:
  .
- If you really want to remove open-iscsi, it is advisable to abort here
- and to first stop open-iscsi:
service open-iscsi stop
+ .
  If that did not clean up everything, manually umount all filesystems
- that are on iSCSI, manually dismantle the storage stack and only then
- logout from all iSCSI 

Bug#798677: sasl2-bin: include LDAP_SASLAUTHD file in the package

[David Magda]

Package: sasl2-bin
Version: 2.1.26.dfsg1-13
Severity: wishlist

If you're using the "ldap" MECHANISM, there are a bunch of configuration
variables that need to be put in /etc/saslauthd.conf. By default there
is no documentation for these values installed in the package, so one has
to go online and search for the possible values.

The risk of trying to find one online is that it may no correspond to the
version that is installed, so some configuration items may be retired, and
newer ones could have been added.

It would be nice if the "LDAP_SASLAUTHD" file was included in the package
so that it's readily available:

https://cgit.cyrus.foundation/cyrus-sasl/tree/saslauthd/LDAP_SASLAUTHD



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

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

Versions of packages sasl2-bin depends on:
ii  db-util5.3.0
ii  debconf [debconf-2.0]  1.5.56
ii  libc6  2.19-18
ii  libcomerr2 1.42.12-1.1
ii  libdb5.3   5.3.28-9
ii  libgssapi-krb5-2   1.12.1+dfsg-19
ii  libk5crypto3   1.12.1+dfsg-19
ii  libkrb5-3  1.12.1+dfsg-19
ii  libldap-2.4-2  2.4.40+dfsg-1
ii  libpam0g   1.1.8-3.1
ii  libsasl2-2 2.1.26.dfsg1-13
ii  libssl1.0.01.0.1k-3+deb8u1

sasl2-bin recommends no packages.

sasl2-bin suggests no packages.

-- debconf information excluded

Bug#798598: nghttp2: Hangs in init script upon package upgrade, causing the package manager to not continue

[Tomasz Buchert]

The trivial fix has been merged upstream:
https://github.com/tatsuhiro-t/nghttp2/pull/350

Expect a new upload soon.
Tomasz


signature.asc
Description: Digital signature

Bug#798673: libreoffice-calc: WORKDAY function is mixed with WORKDAY.INTL function with French language

[rpnpif]

Source: libreoffice
Version: 5.0.1-1~bpo8+1
Severity: normal
Tags: upstream

Dear Maintainer,

WORKDAY (SERIE.JOUR.OUVRE in French language) is mixed with WORKDAY.INTL when 
is used in French language.

This is an upstream issue. 
See https://bugs.documentfoundation.org/show_bug.cgi?id=93685

Please update when it will be fixed.

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

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

Bug#798686: RM: qof -- ROM; leaf library, no further uses in Debian

[Neil Williams]

Package: ftp.debian.org
Severity: normal

With the removal of gnotime, that completes the set, (pilot-qof &
gpe-expenses were removed for their own reasons before Jessie).

There is no particular reason to retain a library in Debian when
there are no packages using the library and it has been around long
enough for anyone who was interested to have made their use case
known.

Please remove qof from Debian.

Bug#798679: LibreOffice french translation in 5.0.1 is broken (at least in Jessie backports)

[Rene Engelhard]

notfound 798679 1:5.0.1-1~bpo8+1
close 798679
thanks
 
On Fri, Sep 11, 2015 at 07:08:47PM +0200, Julien Aubin wrote:
>After upgrading to LibreOffice 5.0.1 in jessie-backports, In noticed that
>the
>french translations seem to be broken, i.e. LibreOffice is not translated
>at
>all.
>Could you please fix it ?

Yes, known. Rebuilding right now.

And this BTS _is not_ for bpo bugs. the BTS does not know the versions of the 
bts
and gets confused.

The package correctly sets the bug report to go to the debian-backports mailing 
list.
Use that.

Closing.

Regards,

Rene

Bug#797858: devscripts: build-rdeps does not work for any but the most trivial dependency situatinos

[Jakub Wilk]

* Johannes Schauer , 2015-09-11, 10:00:

How about doing it the following way then:

If dose-ceve is not installed, throw an error message and tell the user 
to either install the dose-extra package or use the option 
--simple-mode which uses the old behaviour.


Sounds good to me.

--
Jakub Wilk

Bug#795937: NMU uploaded to DELAYED/5

[Benj. Mako Hill]

> I've sponsored Bradley's NMU to DELAYED/5 -- feel free to dcut cancel
> the upload or beat it to sid.

Sounds good! Thanks for the heads up!

Later,
Mako



-- 
Benjamin Mako Hill
http://mako.cc/

Creativity can be a social contribution, but only in so far
as society is free to use the results. --GNU Manifesto


signature.asc
Description: Digital signature

Bug#798656: roxterm: Double clicking on URL doesn't select URL anymore

[Tony Houghton]

On 11/09/15 15:18, Raphael Rigo wrote:


after upgrading to the current version from version 2.9, the behaviour
of double clicking on URL changed : it's not longer selecting the whole
URL.
For example, a double click on https://www.debian.org would select only
//www.debian.org. Changing the option for "select by word characters" to
include ':' doesn't fix it.


The old function for dealing with word characters was removed from vte, 
in version 0.36 I think. I thought it was being reinstated (in 0.38?) 
and tried to handle this without having to recompile (ignoring the 
option when the function was missing), but it seems in 0.40 they've 
replaced it with a slightly different function, so I'll have to release 
a new version of roxterm to fix this.

Bug#798688: Add backports-sloppy suite for Wheezy and Squeeze

[Vincent Bernat]

Package: dput-ng
Version: 1.10
Severity: normal
Tags: patch

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi!

wheezy-backports-sloppy and squeeze-backports-sloppy are missing from
dput-ng. I did push a patch to the GitHub repository some time ago:

 https://github.com/Debian/dput-ng/pull/15

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

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

Versions of packages dput-ng depends on:
ii  python-dput  1.10
pn  python:any   

Versions of packages dput-ng recommends:
ii  bash-completion  1:2.1-4.2

dput-ng suggests no packages.

- -- no debconf information

- -- debsums errors found:
debsums: changed file /usr/share/dput-ng/codenames/debian.json (from dput-ng 
package)

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJV8xbeAAoJEJWkL+g1NSX5kM0P/3XqkEiyQxgXAyJY5U1WYF/Z
JkH1LxjcZW1LZwIl9iiLgXrQ5fCT8tdCaVoUWlxa6pPJDEgO7Uj/YMFWaF3k9jot
TLcOhXp4JZa0mEwOjyRwmQjbEDvWy/MrgQCXzUKpqUXKknAXlAQfrik7yt52BgTX
MwsbWHSLgW7RaJAsGIIRTh5AzFazr+i7iTXaUzIs3pXtXIRQ/s0AIkqh3QEh+Vne
St85xZ6fh+L/lSmOFS33bgrSdIh5LydAuiH1xysz3Gcdf4HCsNdjuvYFQnFZuECY
igzl+LEDW5U9IS8cFiXksWDT3fwEZquzhRFs2zHNVaqJ8pEaPvJyR8GzoFCyOQoj
SSZaBVzvDBA7paB4E5fxPQsECloW09etCmQhPUQ7MRfPi5kMdYhoZ/926iKdiJ8W
906pCbAtW3njDTlPde2LeqbL+wnrSU9lOPuv+gYLECEVYU8UVk5i2rbRK7lKPW8X
ABuzMTi5p3AbiBnT1y6iDP7aMoGdRHUqtrV42e5d8p9cgwSkCNr6b/XmbV6G6/MH
b+nCsBrS6YEC/QxhatM95dXviYBLSVfsgOJvsLjZsOrY+AVDminA2fIipo19QJpq
+2ohaWMuSUn0CcZVMnwxsxZ0q24DL6+3IjJZmDGgzKBccP/eg797sP+TjIcEhDGy
VlB6VhPRMTg75XfFg+n1
=WRnr
-END PGP SIGNATURE-

Bug#798458: RFS: mini-httpd/1.21-1 [ITA] -- Small HTTP server

[Vincent Bernat]

 ❦ 11 septembre 2015 14:57 -0300, J.S.Júnior  :

> Hi, sorry I don't understand you.

Which part didn't you understand?
-- 
Debian package sponsoring guidelines:
 http://vincent.bernat.im/en/debian-package-sponsoring.html


signature.asc
Description: PGP signature

Bug#798678: ruby2.1: Contains file released under a nonfree license

[Daniel Milewski]

Source: ruby2.1
Version: 2.1.5-2+deb8u2
Severity: serious

I've found this notice in the ruby-2.1.5/ext/json/generator/generator.c
file:

/*
 * Copyright 2001-2004 Unicode, Inc.
 *
 * Disclaimer
 *
 * This source code is provided as is by Unicode, Inc. No claims are
 * made as to fitness for any particular purpose. No warranties of any
 * kind are expressed or implied. The recipient agrees to determine
 * applicability of information provided. If this file has been
 * purchased on magnetic or optical media from Unicode, Inc., the
 * sole remedy for any claim will be exchange of defective media
 * within 90 days of receipt.
 *
 * Limitations on Rights to Redistribute This Code
 *
 * Unicode, Inc. hereby grants the right to freely use the information
 * supplied in this file in the creation of products supporting the
 * Unicode Standard, and to make copies of this file in any form
 * for internal or external distribution as long as this notice
 * remains attached.
 */

This makes the file nonfree, at least according to the FSF which I
asked about this.

Since the JSON parser contains two parallel implementations of the same
code, native variant and pure Ruby variant, one way to solve this would
be to use the pure Ruby variant by default. I solved the bug this way
for another free distro Parabola[1].

[1] https://projects.parabola.nu/abslibre/abslibre.git/tree/libre/ruby

-- 
Daniel Milewski
GPG key ID: 8D43A4A1


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

Bug#798680: ruby2.2: Contains file released under a nonfree license

[Daniel Milewski]

Source: ruby2.2
Version: 2.2.3-1
Severity: serious

I've found this notice in the ruby-2.2.3/ext/json/generator/generator.c
file:

/*
 * Copyright 2001-2004 Unicode, Inc.
 *
 * Disclaimer
 *
 * This source code is provided as is by Unicode, Inc. No claims are
 * made as to fitness for any particular purpose. No warranties of any
 * kind are expressed or implied. The recipient agrees to determine
 * applicability of information provided. If this file has been
 * purchased on magnetic or optical media from Unicode, Inc., the
 * sole remedy for any claim will be exchange of defective media
 * within 90 days of receipt.
 *
 * Limitations on Rights to Redistribute This Code
 *
 * Unicode, Inc. hereby grants the right to freely use the information
 * supplied in this file in the creation of products supporting the
 * Unicode Standard, and to make copies of this file in any form
 * for internal or external distribution as long as this notice
 * remains attached.
 */

This makes the file nonfree, at least according to the FSF which I
asked about this.

Since the JSON parser contains two parallel implementations of the same
code, native variant and pure Ruby variant, one way to solve this would
be to use the pure Ruby variant by default. I solved the bug this way
for another free distro Parabola[1].

[1] https://projects.parabola.nu/abslibre/abslibre.git/tree/libre/ruby

-- 
Daniel Milewski
GPG key ID: 8D43A4A1


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

Bug#798567: [Ceph-maintainers] Bug#798567: Bug#798567: ceph: CVE-2015-5245: Rados rest gateway returns requested bucket name raw in Bucket response header

[Ken Dreyer]

On Fri, Sep 11, 2015 at 4:04 AM, Gaudenz Steinlin  wrote:
> I fail to see how this is a security issue.

Please see https://www.owasp.org/index.php/HTTP_Response_Splitting for
an explanation about HTTP header manipulation attacks.

- Ken

Bug#798458: RFS: mini-httpd/1.21-1 [ITA] -- Small HTTP server

[Vincent Bernat]

 ❦ 11 septembre 2015 08:46 -0300, J.S.Júnior  :

>> Sorry for the bikeshed,
> I don't understand this. (bikeshed) :)

Maybe this is not the proper way to use it. It's like yak shaving.
 https://en.wiktionary.org/wiki/bikeshedding

>> The description of fix-mini-httpd-vhost could be "Append port number to
>> vhost". The name of the patch could be "append-portno-to-vhost.patch". A
>> bug report number to know why this is done would be great to.
> fix name.
> Yes, look [1]

You can include the bug number in the patch (with Bug:). I see that you
already put it in the changelog but the entry doesn't help to know what
the patch is about.

>> Also, this
>> would make the Debian package behaves differently than upstream. Has
>> this patch been pushed upstream?
> No, patch suggestion bug number #491078 [1]

The bug is from 2008 and despite numerous releases, it is not present
upstream. This makes mini-httpd behaves differently in Debian than in
other distributions or when just compiled from sources.

This will also break setup of people that were relying on the original
behavior, so you would need to add an entry in NEWS.Debian to advertise
the change.

I would not include the patch until it is vetted by upstream.

>> The description of fix-mini-httpd could be "Fix buffer overflow in
>> add_to_response". The name of the patch could be
>> "add_to_response-buffer-overflow.patch". The stuff about indexes should
>> be moved out to a different patch: when your patch is applied upstream,
>> you may discard it and forget about this part.
>> 
> Ok, fix name.
> Yes, when the upstream fix in tarball original I'm remove patch.
> thanks

The patch still contains an unrelated change about how to find files
like "index.html". Upstream may never fix the index.mini-httpd.html
stuff, so you will have to separate the patch at some point. It's better
to do it now.
-- 
Debian package sponsoring guidelines:
 http://vincent.bernat.im/en/debian-package-sponsoring.html


signature.asc
Description: PGP signature

Bug#798625: systemd-networkd: Runs arbitrary inappropriate scripts on network changes

[josh]

On Fri, Sep 11, 2015 at 09:41:34AM +0200, Martin Pitt wrote:
> Josh Triplett [2015-09-10 23:54 -0700]:
> >   * Make networkd call if-up.d/ scripts when it brings up interfaces, to
> > become compatible with ifupdown and NetworkManager for packages shipping
> > hooks. (LP: #1492129)
> > 
> > (Along with various other changes related to these hooks.)
> > 
> > This is an *extremely* bad idea; please revert it before any package
> > incorrectly starts to rely on it.  And this should have been discussed
> > on at least pkg-systemd-maintainers, if not systemd-devel, before being
> > implemented.
> 
> FTR, this was discussed a few months ago with Tom Gundersen (the
> author of networkd) at the UOS discussion for this:
> 
>   
> https://blueprints.launchpad.net/ubuntu/+spec/foundations-w-networkd-vs-ifupdown

What was his response?  I'd be quite surprised to hear any upstream
systemd or networkd developers favoring this approach.

In any case, I'd really appreciate this being discussed more broadly,
ideally on systemd-devel, to get some feedback there.

The proposal there also seems somewhat different than the one
implemented here.

For that matter, it seems like there's a race condition here: if
resolveconf is going to pull in systemd-resolved's resolv.conf, networkd
hooks can't guarantee that systemd-resolved actually creates that
*before* those hooks run.  Perhaps resolveconf could start using inotify
(along with a list of places to look for generated resolv.conf files)?

> > Several reasons why this is a bad idea:
> > 
> > - networkd is intended to bring up interfaces *quickly*, on the order of
> >   microseconds (not milliseconds) even with DHCP, let alone without.
> >   Spawning arbitrary processes, and especially shell scripts, is not and
> >   will never be compatible with networkd's performance requirements.
> 
> The hooks are run asynchronously and don't block networkd.

Interesting; as far as I know, that's a change compared to how other as
far as I know those hooks are normally run synchronously by other
software.  The changelog didn't give any indication about asynchronous
invocation.  I'd still be concerned about whether this adds any delay to
the fast-path, though a bit less so.  Moving this to use networkd's
existing event mechanism seems preferable to spawning a process from
networkd.

> > - These hooks don't exist upstream.  Packages shipping if-up.d hooks are
> >   thus still broken anywhere other than Debian, and even *in* Debian
> >   they're broken with dynamic network configuration.  Those package need
> >   fixing (upstream) to handle dynamic network configuration, and once
> >   they do, the Debian-specific hooks become obsolete.  Allowing these
> >   hooks makes it less obvious that the packages themselves need fixing.
> 
> I do agree that it would be better to fix openssh, postfix, ntpdate,
> avahi-autoipd, and the zillion other packages that ship if-up.d hooks
> (and other if-*.d/ hooks,  but these are much less important).
> However, IMHO this shouldn't be a blocker for adopting networkd -- I'd
> like networkd to work in Debian as well as ifupdown and
> NetworkManager; providing if* hook and resolvconf integration should
> bring it up to par with NetworkManager, and thus I believe people can
> now actually use this. Without these, a lot of things would suddenly
> not work as expected any more, like openssh not listening to newly
> brought up interfaces or postfix not flushing the mail queue when the
> system gets online (in a hotplug environment).

Hardly a zillion packages; here's a complete list of Debian packages:

$ zgrep '^etc/network/if-up\.d' Contents-amd64.gz
etc/network/if-up.d/000resolvconf   
net/openresolv,net/resolvconf
etc/network/if-up.d/00README.linkdirnet/ifupdown-scripts-zg2
etc/network/if-up.d/00check-network-cable   admin/ifupdown-extra
etc/network/if-up.d/10check-duplicate-ipadmin/ifupdown-extra
etc/network/if-up.d/20static-routes admin/ifupdown-extra
etc/network/if-up.d/30check-gateway admin/ifupdown-extra
etc/network/if-up.d/51guidedog  net/guidedog
etc/network/if-up.d/arping  net/arping
etc/network/if-up.d/avahi-autoipd   net/avahi-autoipd
etc/network/if-up.d/avahi-daemonnet/avahi-daemon
etc/network/if-up.d/bind9   net/bind9
etc/network/if-up.d/clamav-freshclam-ifupdown   utils/clamav-freshclam
etc/network/if-up.d/controlaula.ifupadmin/controlaula
etc/network/if-up.d/epoptes-client  admin/epoptes-client
etc/network/if-up.d/ethtool net/ethtool
etc/network/if-up.d/gogoc   net/gogoc
etc/network/if-up.d/htpdate net/htpdate
etc/network/if-up.d/ifenslave   net/ifenslave

Bug#638720: Odoo packaging

[martin f krafft]

also sprach Dmitry Smirnov  [2015-05-06 18:30 +0200]:
> I'm leaving packaging in almost finished state -- as per TODO
> there are only few non-DFSG issues left. Also Bootswatch themes
> are full of "privacy-breach" issues and have to be packaged
> separately anyway.

Where is this packaging?

Has there been any progress made on the side of Odoo, or by
Martin/Ben?

-- 
 .''`.   martin f. krafft  @martinkrafft
: :'  :  proud Debian developer
`. `'`   http://people.debian.org/~madduck
  `-  Debian - when you have better things to do than fixing systems


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Bug#798690: handshake failure on get.docker.com

[Eduard Bloch]

Package: libssl1.0.0
Severity: normal

$ openssl s_client -connect get.docker.com:443
CONNECTED(0003)
139902178879120:error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert 
handshake failure:s23_clnt.c:769:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 7 bytes and written 315 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
---

I did the check above because my apt-cacher-ng recently started barking
this error for no obvious reason. Search on internet is inconclusive...
some people suggest to enforce TLSv1, other tell something about
KeyUsage extension.

I tried a code hack, change to SSL_CTX_new(TLSv1_1_client_method())
but that didn't help.

Regards,
Eduard.

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

Kernel: Linux 4.2.0+ (SMP w/4 CPU cores; PREEMPT)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)

-- 
Hart ist Hart. Weich ist Weich. Aber immer weich ist hart.

Bug#796281: jessie-pu: package pcre3/2:8.35-3.3+deb8u1

[Moritz Mühlenhoff]

On Fri, Aug 21, 2015 at 03:59:15PM +0100, Adam D. Barratt wrote:
> Control: tags -1 + moreinfo
> 
> On Fri, 2015-08-21 at 01:35 +0200, Moritz Muehlenhoff wrote:
> > This update fixes four minor security issues which don't warrant
> > a DSA. These have been tested in a production setup and were
> > working fine there.
> [...]
> > +  * CVE-2015-2325 CVE-2015-2326 CVE-2015-3210 CVE-2015-5073
> 
> The BTS and Security Tracker indicate that the first three of those
> aren't fixed in unstable yet; is that correct?

Now fixed in unstable in 2:8.35-7.2.

Cheers,
Moritz

Bug#798671: RM: s3ql [alpha kfreebsd-amd64 kfreebsd-i386 m68k] -- ROM; prevents testing migration

[Nikolaus Rath]

Package: ftp.debian.org
Severity: normal

Could you please remove the s3ql package for the architectures alpha 
kfreebsd-amd64
kfreebsd-i386 and m68k?

For some reason the package doesn't built there anymore (but used to in
the past).

I intend to investigate, but I don't want this to prevent migration to
testing (at the moment, there are no S3QL packages in testing for any
architecture).

Thanks!
-Nikolaus

Bug#795851: openjfx: FTBFS with Gradle 2.5

[Markus Koschany]

Am 10.09.2015 um 23:17 schrieb Miguel Landaeta:
> Hi Markus,
> 
> On Thu, Sep 10, 2015 at 08:24:52PM +0200, Markus Koschany wrote:
>> *ping*
> 
> (ahem, reappearing after my vacations)

Welcome back and don't forget to sign my key. :-)

Cheers,

Markus




signature.asc
Description: OpenPGP digital signature

Bug#798675: openscad: package has broken dependecies

[bartek 'basz' szurgot]

Source: openscad
Version: 2014.03+dfsg-1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

after recent dist-upgrade package has been automatically unistalled, due
to unmet dependencies.
i'm unable to install it ever since. when trying to install console
output is:

# apt-get install openscad
Reading package lists... Done
Building dependency tree
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 libgd3 : Depends: libvpx2 (>= 1.4.0) but it is not going to be installed
 libstdc++6 : Breaks: openscad (<= 2014.03+dfsg-1+b1) but 2014.03+dfsg-1
is to be installed
 libwxgtk3.0-0v5 : Depends: libsdl1.2debian (>= 1.2.11) but it is not
going to be installed
 openscad : Depends: libboost-filesystem1.55.0 but it is not going to be
installed
Depends: libboost-regex1.55.0 but it is not going to be
installed
Depends: libboost-system1.55.0 but it is not going to be
installed
Depends: libboost-thread1.55.0 but it is not going to be
installed
Depends: libcgal10 but it is not going to be installed
Depends: libglu1-mesa but it is not going to be installed or
 libglu1
Depends: libqt4-opengl (>= 4:4.5.3) but it is not going to
be installed
Depends: libqtcore4 (>= 4:4.8.0) but it is not going to be
installed
Depends: libqtgui4 (>= 4:4.7.0~beta1) but it is not going to
be installed
E: Error, pkgProblemResolver::Resolve generated breaks, this may be
caused by held packages.


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

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

-- 
pozdrawiam serdecznie / best regards,
bartek 'basz' szurgot
/* http://www.baszerr.eu */
/* http://www.baszerr.eu/lib/exe/fetch.php/about_me/basz_pub_key.txt */




signature.asc
Description: OpenPGP digital signature

Bug#798655: RFS: node-text-encoding/0.5.3-1 [ITP] -- Polyfill for the Encoding Living Standard's API

[Julien Puydt]

Hi,

Le 11/09/2015 16:44, Gianfranco Costamagna a écrit :

some issues:
1) copyright:

please mention the apache documentation without the link
(e.g. hedgewars/copyright package has a 14 lines version)


Ok, done.


2) examples.html  examples-no-indexes.html

what about installing them?


Yes, done.


3) bower.json
what does this file do?


There are two json files:
- package.json, which describes the package for node.js ;
- bower.json, which describes the package for another javascript package 
management system (named bower).


So things should be ok as-is on that part.

I updated the package on mentors.d.n and in the git repository.

Thanks,

Snark on #debian-javascript and #debian-mentors

Bug#798458: RFS: mini-httpd/1.21-1 [ITA] -- Small HTTP server

[J . S . Júnior]

Hi Sr Vicent


Hi, sorry I don't understand you.

:(

You can explanation better ?

Thanks a lot.
JJ


pgpCwj7Hsb9K4.pgp
Description: Assinatura digital OpenPGP

Bug#726820: retitle ITP: ansiweather

[Javier Fafián Álvarez]

Bug#750028: checkinstall: Allow configuring dpkg compression type

[Ivan Masar]

Another reason to specify compression flags is to make packages for
older distributions which don't support a particular type of
compression.

Regards,
~~helix84

Bug#797858: devscripts: build-rdeps does not work for any but the most trivial dependency situatinos

[Johannes Schauer]

Hi Jakub,

thanks a lot for your review - much appreciated!

Quoting Jakub Wilk (2015-09-10 16:21:26)
> >If dose-ceve is installed (and new enough) then build-rdeps will use it 
> >to calculate the reverse build dependencies of a binary packages. If 
> >dose-ceve is not installed (or too old) then it will warn that it will 
> >use the old unreliable behavior instead.
> 
> I don't like the idea of that the command semantics completely changes 
> when you install or uninstall a package. I'd rather see build-rdeps fail 
> with no output if dose-ceve can't be used.

fair enough.

How about doing it the following way then:

If dose-ceve is not installed, throw an error message and tell the user to
either install the dose-extra package or use the option --simple-mode which
uses the old behaviour.

> >If dose-ceve is installed (and new enough) then the old behaviour can be
> >forced with the --without-ceve command line argument.
> 
> I don't like the option name. Most people don't know what ceve stands 
> for, and it's an implementation detail anyway. (What if edos^Wdose 
> maintainers decide to rename it to dose-evec? ;>)

That is actually a not too far fetched possibility XD

This problem is solved with my above proposal. If you don't like that proposal,
I'm open to suggestions of how to name it.

> Your patch doesn't seem to handle contrib and non-free correctly. I get:
> 
> >Reverse Build-depends in contrib:
> >-
> >
> >No reverse build-depends found for dh-autoreconf.
> 
> even though of course there ARE packages in contrib build-depending on 
> dh-autoreconf.

I will address this problem in my next patch - thanks for spotting it!

> >+  $packages_path =~ 
> >s/_source_Sources$/_binary-${opt_buildarch}_Packages/;
> 
> The need for *_Packages should be documented in the REQUIREMENTS section 
> of the manpage.

Indeed. Will add that in my next patch.

> On my machine, your implementation is ~100x slower than the current one. 
> :\

If you know a piece of software that analyzes the interdependencies of 40k
binary packages and 20k source packages in a shorter time, I'm open for
suggestions!

cheers, josch


signature.asc
Description: signature

Bug#798628: closure-compiler: Section should be “web”

[Ben Finney]

Package: closure-compiler
Version: 20130227+dfsg1-8
Severity: minor

The section “java” is for packages that install primarily resources
(e.g. libraries) for Java programmers.

The package ‘closure-compiler’ installs primarily a library for
JavaScript programmers, not Java programmers. By the section
descriptions, this package belongs in the “web” section.

Please set the field “Section: web”.

-- 
 \“This sentence contradicts itself — no actually it doesn't.” |
  `\   —Douglas Hofstadter |
_o__)  |
Ben Finney 

Bug#798627: closure-compiler: Section should be “web”

[Ben Finney]

Package: closure-compiler
Version: 2.3.13-2
Severity: minor

The section “python” is for packages that install primarily resources
(e.g. libraries) for Python programmers.

The package ‘closure-linter’ installs primarily a library for
JavaScript programmers, not Python programmers. By the section
descriptions, this package belongs in the “web” section.

Please set the field “Section: web”.

-- 
 \   “During the Middle Ages, probably one of the biggest mistakes |
  `\   was not putting on your armor because you were ‘just going down |
_o__)to the corner.’” —Jack Handey |
Ben Finney 

Bug#737057: debmirror: Please add xz support

[Cyril Brulebois]

Hi,

John Paul Adrian Glaubitz  (2015-09-11):
> This seems to have broken debmirror now as it's no longer
> being able to retrieve the Sources.bz2 and therefore generates
> it themselves which results in an invalid Sources file.
> 
> We are using debmirror for our local Debian mirror and have
> run into problem with the validation of the Sources file:
> 
> root@jessie64:~> apt-get update
> Ign file: jessie InRelease
> Ign file: jessie/updates InRelease
> Ign file: jessie-backports InRelease
> (...)
> W: Failed to fetch
> file:/net/deb/debian/dists/jessie-backports/non-free/source/Sources
> Hash Sum mismatch
> 
> E: Some index files failed to download. They have been ignored, or old
> ones used instead.
> root@jessie64:~>
> 
> I assume the priority of this bug should be raised unless there
> is some workaround to fix this.

That doesn't seem unreasonable; helping the new maintainer with a few
patches would probably be appreciated as well, especially if you're a
regular user for your local mirror.

I've moved to using archvsync to follow what mirrors are using (so
that I can stop caring), so feel free to steal this bug report away
from me with a submitter -1 ! call.

Mraw,
KiBi.


signature.asc
Description: Digital signature

Bug#798423: RFS: alien/8.95 [QA] -- convert and install rpm and other packages

[Fabiano Antunes]

Just uploaded it a couple of minutes ago.

Best regards,
  Fabiano.
On 09/11/2015 02:50 AM, Gianfranco Costamagna wrote:

Hi, you can just dput again, it will override the previous upload!

cheers

G.

Bug#771444: SOLVED(?): Xming and gnome-session-flashback

[paul . szabo]

Seems to me that using
  Xming.exe +extension Composite -query ...
solves the issue (is a workaround for the Gnome bogosity).
More accurately, I use
  "C:\Program Files\Xming\Xming.exe" +extension Composite -clipboard -once 
-query HOST
to good effect.

Cheers, Paul

Paul Szabo   p...@maths.usyd.edu.au   http://www.maths.usyd.edu.au/u/psz/
School of Mathematics and Statistics   University of SydneyAustralia

Bug#798625: systemd-networkd: Runs arbitrary inappropriate scripts on network changes

[Martin Pitt]

Hey Josh,

Josh Triplett [2015-09-10 23:54 -0700]:
>   * Make networkd call if-up.d/ scripts when it brings up interfaces, to
> become compatible with ifupdown and NetworkManager for packages shipping
> hooks. (LP: #1492129)
> 
> (Along with various other changes related to these hooks.)
> 
> This is an *extremely* bad idea; please revert it before any package
> incorrectly starts to rely on it.  And this should have been discussed
> on at least pkg-systemd-maintainers, if not systemd-devel, before being
> implemented.

FTR, this was discussed a few months ago with Tom Gundersen (the
author of networkd) at the UOS discussion for this:

  
https://blueprints.launchpad.net/ubuntu/+spec/foundations-w-networkd-vs-ifupdown

> Several reasons why this is a bad idea:
> 
> - networkd is intended to bring up interfaces *quickly*, on the order of
>   microseconds (not milliseconds) even with DHCP, let alone without.
>   Spawning arbitrary processes, and especially shell scripts, is not and
>   will never be compatible with networkd's performance requirements.

The hooks are run asynchronously and don't block networkd.

> - These hooks don't exist upstream.  Packages shipping if-up.d hooks are
>   thus still broken anywhere other than Debian, and even *in* Debian
>   they're broken with dynamic network configuration.  Those package need
>   fixing (upstream) to handle dynamic network configuration, and once
>   they do, the Debian-specific hooks become obsolete.  Allowing these
>   hooks makes it less obvious that the packages themselves need fixing.

I do agree that it would be better to fix openssh, postfix, ntpdate,
avahi-autoipd, and the zillion other packages that ship if-up.d hooks
(and other if-*.d/ hooks,  but these are much less important).
However, IMHO this shouldn't be a blocker for adopting networkd -- I'd
like networkd to work in Debian as well as ifupdown and
NetworkManager; providing if* hook and resolvconf integration should
bring it up to par with NetworkManager, and thus I believe people can
now actually use this. Without these, a lot of things would suddenly
not work as expected any more, like openssh not listening to newly
brought up interfaces or postfix not flushing the mail queue when the
system gets online (in a hotplug environment).

> - Network configuration can change at any time, and networkd is not
>   stateful; state lives in the kernel, not in networkd.  These hooks
>   break that assumption.

Can you please explain this? How is this different from ifupdown and NM?

> (This will also likely break with future
>   changes to networkd and other packages integrating with it, as well as
>   with other types of interfaces or virtual networks networkd can
>   configure.)  Among other things, as the systemd-networkd manpage
>   documents, "Network configurations applied before networkd is started
>   are not removed, and static configuration applied by networkd is not
>   removed when networkd exits. Dynamic configuration applied by networkd
>   may also optionally be left in place on shutdown. This ensures
>   restarting networkd does not cut the network connection, and, in
>   particular, that it is safe to transition between the initrd and the
>   real root, and back."

Right, and consequently it won't call if-post-down.d/ when you stop
networkd.

> - Several of the existing if-up.d and if-post-down.d hooks should not
>   run under networkd.  Among others: wpasupplicant's hooks shouldn't run
>   at all under anything but ifupdown

Why not? If it's not meant to run under NM or other mechanisms, it
should check $METHOD. But right now the hook doesn't do anything under
!ifupdown anyway as none of the $WPA_* and $IF_* vars is supplied.

That said, as networkd doesn't have wifi support by itself, it would
certainly be *nice* to make wpa_supplicant work OOTB with networkd :-)

> , mountnfs's hooks shouldn't run (because they conflict with several
> other approaches to nfs handling that integrate properly with
> systemd)

That sounds like a real issue indeed, do you have some details? Again,
how is that not affecting NetworkManager?

> , avahi-daemon's hook is responsible for numerous problems and
> slowdowns even under ifupdown

This just disables avahi if there is a "real" .local domain. This
seems rather independent of the mechanism used to bring up networking?

> and wireless-tools' hook shouldn't run under anything but
>   ifupdown.

Same question/issues as for wpasupplicant?

> - Calling if-up.d and if-post-down.d, but not calling if-down.d or
>   if-pre-up.d, may well break assumptions that a family of scripts in
>   those directories have about when they'll be called and what state
>   machine they'll go through.

NetworkManager has done just that for many years. if-pre-up.d/ is
rather specific to ifupdown indeed (configuring device drivers and
stuff), and if-down.d/ has been a promise which we've never been able
to keep anyway since we have hotplugging and wifi.

(FTR, I consider 

Bug#794452:

[Lennart Weller]

If I can help you out with that let me know.

September 4 2015 9:55 AM, "Andrii Senkovych"  wrote:
> Hi, Lennart
> 
> I'm sorry for the late reply. I'll update the packages during this
> weekend. Thank you!
> 
> 2015-09-04 10:01 GMT+03:00 Lennart Weller :
> 
>> I keep updating the packages and newer versions now require 0.1.16.
>> If you'd like I could help out with updating the package.

Bug#683839: still a problem in stretch

[M G Berberich]

Hello,

modemmanager messes up my ttyS3 with my 1-wire DS9097 interface and
ttyS2 with my serial terminal (vt320), to a point I can’t get them
work without reboot.

There seems to be no way to prevent modemmanager to mess up these
interfaces.

There seems to be no way to prevent modemmanager from starting if it
is installed.

There seems to be no easy way to prevent modemmanager to be constantly
reinstalled by aptitude because of dependencies.

MfG
bmg

-- 
„Des is völlig wurscht, was heut beschlos- | M G Berberich
 sen wird: I bin sowieso dagegn!“  | berbe...@fmi.uni-passau.de
(SPD-Stadtrat Kurt Schindler; Regensburg)  | www.fmi.uni-passau.de/~berberic

Bug#798611: util-linux: /sbin/fsck no longer works as non-root

[Andreas Henriksson]

Hello Paul Martin.

Thanks for your bug report.

On Fri, Sep 11, 2015 at 12:31:09AM +0100, Paul Martin wrote:
> Package: util-linux
> Version: 2.27-1
> Severity: important
> Control: affects -1 cryptmount
> 
> This breaks cryptmount when run as a user.
[...]
> It is possible to work around this change in behaviour by adding /sbin 
> to the PATH, thus:
> 
> $ PATH=$PATH:/sbin /sbin/fsck /dev/null
> fsck from util-linux 2.27
> e2fsck 1.42.13 (17-May-2015)
> fsck.ext2: Inappropriate ioctl for device while trying to open /dev/null
> [etc]

See 
https://git.kernel.org/cgit/utils/util-linux/util-linux.git/commit/?id=a03bdbcd2029ed1b002d45a028f6e706845fa566

There was also a discussion on the upstream mailing list about this.

We can't have it both ways. Some people want PATH to be used instead
of hard-coding paths to search for fsck.* helpers, now you report
that passing an incorrect PATH will not work and you want it
hard-coded I'm inclined to reassign this bug report to cryptmount
saying it should pass a valid (or unset!) PATH.

(Please note that there are already packages who no longer ships
their fsck.* helpers in /sbin, so unset path (and relying on hard-coded
/sbin path) will not work for those See btrfs tools for example.
Given that it apparently is the wish from maintainers of fsck.*
helpers maintainers to be able to spread their tools around, it's
now the callers responsibility to include all their paths in
the call to fsck if you want them included)

Do you have any other suggestions on how to handle this?
If you still think this is a util-linux issue, could you please
argue your case on the upstream mailing list directly?

Regards,
Andreas Henriksson

Bug#798629: procps: w and who do not view any logged in users

[Martin Steigerwald]

Package: procps
Version: 2:3.3.11-2
Severity: important

Dear Maintainer,

I find that on my current system w and who are not displaying any users:

merkaba:~> w
 10:52:35 up 7 min,  0 users,  load average: 0,77, 0,89, 0,53
USER TTY  FROM LOGIN@   IDLE   JCPU   PCPU WHAT

merkaba:~> who
merkaba:~> 


Today there was a systemd upgrade to 226-1. I am not sure whether it is
related.

I have no idea what package to report this against, as it does not appear
to be either procps (for w) or coreutils (who). Feel free to reassign as
you see fit.

Thanks,
Martin


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

Kernel: Linux 4.2.0-tp520-btrfstrim+ (SMP w/4 CPU cores; PREEMPT)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages procps depends on:
ii  initscripts   2.88dsf-59.2
ii  libc6 2.19-19
ii  libncurses5   6.0+20150810-1
ii  libncursesw5  6.0+20150810-1
ii  libprocps52:3.3.11-2
ii  libtinfo5 6.0+20150810-1
ii  lsb-base  4.1+Debian14

Versions of packages procps recommends:
ii  psmisc  22.21-2.1

procps suggests no packages.

-- no debconf information

Bug#798629: Subject of last message was wrong: Also happens with distro kernel

[Martin Steigerwald]

Hi!

I first thought it only happens with self-built kernel, as the tty1 login was 
shown with distro kernel. But user sessions were also not shown with distro 
kernel. While also with self-built kernel tty logins are shown.

So user sessions are not shown regardless of kernel used.

Thanks,
-- 
Martin

Bug#769222: [Aptitude-devel] Bug#769222: Bug#769222: Bug#769222: aptitude: Frequent pending actions left

[David Kalnischkies]

On Fri, Sep 11, 2015 at 01:06:24AM +0100, Manuel A. Fernandez Montecelo wrote:
> >I haven't really decided (mostly thanks to time issues) yet how to tackle
> >this giant ball of pain and on top of that how to sell it to the Release
> >Team if I would find a fix from the apt side. As said in the mentioned
> >bugreport, that wouldn't help in any way with wheezy-upgrades though.

[The bugreport was 769609 and the fix which landed in jessie with
Release team approval was a2a75ff4516f7609f4c55b42270abb8d08943c60.]


> In the dpkg commit fixing #766758, it says:
> 
>  This is a mostly conformant workaround for frontends like apt that do
>  not correctly call «dpkg --configure -a» or «dpkg --triggers-only -a»
>  after their normal runs, and leave packages in triggers-pending and
>  triggers-awaited states.

apt/jessie does call "dpkg --configure -a" by default after performing
its other dpkg callings. The workaround was needed as apt/wheezy is used
in the wheezy→jessie upgrade, while at some point in this upgrade
dpkg/jessie will be used; so dpkg has to behave as apt/wheezy expects it
to work.

[The "bleed through" of internal details like triggers is why we would
prefer that dpkg would deal with ordering all by itself as talked about
in the DebConf meeting]

> I am not sure if the front-ends are suppossed to be modified to call
> dpkg correctly because this "conformant workaround" will be removed, or
> what's the situation.  Can you please clarify, if you know the reply
> right away?  If you have to dig no problem, I will do it.

I am pretty sure the workaround will be removed at some point, so if
aptitude calls dpkg itself in any way, it should call --configure -a at
the end of these actions – "--configure pkg" might be the most likely
situation to activate a trigger but any file placement or maintainer
script can call one.

I don't know if aptitude actually calls dpkg on its own, but some
reports I had read suggested as much even through I wouldn't expect it…
So I left this bug here for someone to check aptitude – feel free to
close if there is no such issue.


Best regards

David Kalnischkies


signature.asc
Description: Digital signature

Bug#774711: recommendations for changing openssh defaults

[Jens Thiele]

Matt Taggart  writes:

> Hi,

Hi,

thanks for your great work

> * diffie-hellman-group-exchange-sha256: has existed since squeeze at least

Afair I have seen small default primes with this one. Did you inspect this?

greetings,
jens

Bug#795664: Report on my efforts

[Martín Ferrari]

Hi all,

I spent several hours yesterday fixing this bug, as it affects one of my
packages (prometheus).

I managed to fix this particular error, and it is simple: MiniTest::Test
should be replaced by MiniTest::Unit::TestCase (dquilt patch attached).

The problem I could not solve, is that during the tests, the code looks
for the handlebars.js file in an absolute path, which obviously fails if
this is run in a clean chroot. I could not find a way to set the
relative path properly, as I really don't understand Ruby.


RUBYLIB=/home/tincho/repos/prometheus/ruby-handlebars-assets/debian/ruby-handlebars-assets/usr/lib/ruby/vendor_ruby:.
rake2.1 -f debian/ruby-tests.rake
Run options: --seed 30204

# Running tests:

E.E.

Finished tests in 0.281625s, 56.8131 tests/s, 17.7541 assertions/s.

  1) Error:
HandlebarsAssets::CompilingTestx#test_patching_handlebars:
Errno::ENOENT: No such file or directory @ rb_sysopen -
/usr/share/ruby-handlebars-assets/vendor/assets/javascripts/handlebars.js

/home/tincho/repos/prometheus/ruby-handlebars-assets/lib/handlebars_assets/handlebars.rb:35:in
`read'

/home/tincho/repos/prometheus/ruby-handlebars-assets/lib/handlebars_assets/handlebars.rb:35:in
`read'

/home/tincho/repos/prometheus/ruby-handlebars-assets/lib/handlebars_assets/handlebars.rb:35:in
`source'

/home/tincho/repos/prometheus/ruby-handlebars-assets/lib/handlebars_assets/handlebars.rb:18:in
`append_patch'

/home/tincho/repos/prometheus/ruby-handlebars-assets/lib/handlebars_assets/handlebars.rb:24:in
`block in apply_patches_to_source'

/home/tincho/repos/prometheus/ruby-handlebars-assets/lib/handlebars_assets/handlebars.rb:23:in
`each'

/home/tincho/repos/prometheus/ruby-handlebars-assets/lib/handlebars_assets/handlebars.rb:23:in
`apply_patches_to_source'

/home/tincho/repos/prometheus/ruby-handlebars-assets/lib/handlebars_assets/handlebars.rb:31:in
`context'

/home/tincho/repos/prometheus/ruby-handlebars-assets/lib/handlebars_assets/handlebars.rb:10:in
`precompile'

/home/tincho/repos/prometheus/ruby-handlebars-assets/test/handlebars_assets/compiling_test.rb:26:in
`test_patching_handlebars'
/usr/lib/ruby/2.1.0/minitest/unit.rb:1265:in `run'
/usr/lib/ruby/2.1.0/minitest/unit.rb:940:in `block in _run_suite'
/usr/lib/ruby/2.1.0/minitest/unit.rb:933:in `map'
/usr/lib/ruby/2.1.0/minitest/unit.rb:933:in `_run_suite'
/usr/lib/ruby/2.1.0/minitest/unit.rb:914:in `block in _run_suites'
/usr/lib/ruby/2.1.0/minitest/unit.rb:914:in `map'
/usr/lib/ruby/2.1.0/minitest/unit.rb:914:in `_run_suites'
/usr/lib/ruby/2.1.0/minitest/unit.rb:884:in `_run_anything'
/usr/lib/ruby/2.1.0/minitest/unit.rb:1092:in `run_tests'
/usr/lib/ruby/2.1.0/minitest/unit.rb:1079:in `block in _run'
/usr/lib/ruby/2.1.0/minitest/unit.rb:1078:in `each'
/usr/lib/ruby/2.1.0/minitest/unit.rb:1078:in `_run'
/usr/lib/ruby/2.1.0/minitest/unit.rb:1066:in `run'
/usr/lib/ruby/2.1.0/minitest/unit.rb:802:in `block in autorun'


-- 
Martín Ferrari (Tincho)
--- a/test/handlebars_assets/compiling_test.rb
+++ b/test/handlebars_assets/compiling_test.rb
@@ -1,7 +1,7 @@
 require 'test_helper'
 
 module HandlebarsAssets
-  class CompilingTest < ::MiniTest::Test
+  class CompilingTestx < MiniTest::Unit::TestCase
 
 def teardown
   HandlebarsAssets::Config.reset!
--- a/test/handlebars_assets/hamlbars_test.rb
+++ b/test/handlebars_assets/hamlbars_test.rb
@@ -1,7 +1,7 @@
 require 'test_helper'
 
 module HandlebarsAssets
-  class HamlbarsTest < ::Minitest::Test
+  class HamlbarsTest < ::MiniTest::Unit::TestCase
 include SprocketsScope
 include CompilerSupport
 
--- a/test/handlebars_assets/slimbars_test.rb
+++ b/test/handlebars_assets/slimbars_test.rb
@@ -1,7 +1,7 @@
 require 'test_helper'
 
 module HandlebarsAssets
-  class SlimbarsTest < ::Minitest::Test
+  class SlimbarsTest < ::MiniTest::Unit::TestCase
 include SprocketsScope
 include CompilerSupport
 
--- a/test/handlebars_assets/tilt_handlebars_test.rb
+++ b/test/handlebars_assets/tilt_handlebars_test.rb
@@ -1,7 +1,7 @@
 require 'test_helper'
 
 module HandlebarsAssets
-  class HandlebarsTemplateTest < Minitest::Test
+  class HandlebarsTemplateTest < MiniTest::Unit::TestCase
 include CompilerSupport
 include SprocketsScope
 

Bug#798567: [Ceph-maintainers] Bug#798567: ceph: CVE-2015-5245: Rados rest gateway returns requested bucket name raw in Bucket response header

[Gaudenz Steinlin]

Hi

Salvatore Bonaccorso  writes:

> Source: ceph
> Version: 0.80.7-2
> Severity: important
> Tags: security upstream
> Forwarded: http://tracker.ceph.com/issues/12537
>
> Hi,
>
> the following vulnerability was published for ceph.
>
> CVE-2015-5245[0]:
> Ceph: Rados rest gateway returns requested bucket name raw in Bucket response 
> header
>
> 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-2015-5245
> [1] http://tracker.ceph.com/issues/12537

I fail to see how this is a security issue. It's clearly a bug, but
AFAICS you can only shoot yourself in the foot with it. There is no
explanation in the upstream issue tracker why this was assigned a CVE
ID. But as I'm by no means an expert on these issues I would appreciate
someone else looking at this. Do other distros plan an update for this?

If my assessment is correct I think we can fix this with a stable
update. I already tried to convince the stable release team to allow
minor updates to stable. See #784373. A backport to the stable firefly
branch (which is in Debian stable) is in progress upstream.

Gaudenz


signature.asc
Description: PGP signature

Bug#798635: beignet-opencl-icd: beignet is not installable with llvm3.8

[Pietro Abate]

Package: beignet-opencl-icd
Severity: important

Dear Maintainer,

beignet-opencl-icd is not installable in unstable with llvm3.8.
I'm not sure if this is a dependency problem or rather this version
of beignet is not compatible with the new llvm.

regards.
pietro

$sudo apt-get install beignet-opencl-icd
Reading package lists... Done
Building dependency tree   
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
beignet-opencl-icd : Depends: libllvm3.5 but it is not going to be
installed
E: Unable to correct problems, you have held broken packages.


*** 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 ***


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

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

Bug#778063: pinot: diff for NMU version 1.05-1.1

[Jonas Smedegaard]

Quoting Olly Betts (2015-09-11 00:45:39)
> Control: tags 778063 + patch
> 
> Dear maintainer,
> 
> I uploaded an NMU for pinot (versioned as 1.05-1.1) earlier this week.
> 
> An nmudiff is attached.  Sorry for not sending this right away.

Thanks a lot, both for the NMU and this diff :-)

What you did was fine (no _need_ to do more), but you may optionally 
consider in general when doing NMUs if package/maintainer is listed at 
https://wiki.debian.org/LowThresholdNmu - here you could've released 
with a low threshold and also (if you like, and still an option) pushed 
your changed directly to git :-)

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Bug#793791: [Pkg-anonymity-tools] Bug#793791: torbrowser-launcher: Fail to start "TypeError: _getEndpoint() takes exactly 4 arguments (2 given)"

[Stéphane Glondu]

On Mon, 27 Jul 2015 12:29:10 -0700 Micah Lee  wrote:
> > while trying to launch torbrowser-launcher it fail,
> > and return me this error:
> > [...]
> I can reproduce. [...]

I cannot reproduce. Is this bug still on topic?

> I just opened an upstream bug [3].
> [3] https://github.com/micahflee/torbrowser-launcher/issues/192

It says:
> With any luck Debian will update some more packages and the problem
> will just go away :)

Maybe it happened...?


Cheers,

-- 
Stéphane

Bug#798527: virtualbox fails to work with systemd

[Ritesh Raj Sarraf]

On Thu, 2015-09-10 at 17:42 +0530, shirish शिरीष wrote:
> Dear Ritesh,
> Thank you for getting in touch quickly. The reason you didn't get to
> know about dkms is because I already had installed the dkms package.
> I
> had to play it a few times before realizing that I needed not only
> dkms package but also virtualbox-dkms package and now it seems
> virtualbox-guest-dkms as well (not sure) which in turn depends upon
> virtualbox-guest-utils.
> 


The guest packages (guest-utils and guest-dkms) are needed inside the
GUest VM.

> My main aim at the time was to share about the unavailability of a
> .service file.
> 
> I did do the usual :-
> 
> $dpkg -L $PackageName | grep service
> 
> before coming to the conclusion that there are systemd service files.
> 

No. We are not shipping any service file. What you saw was interpreted
through the systemd-sysv-generator tool.

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


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

Bug#798555: qa.debian.org: `thin` gets emails that should be for `thin-provisioning-tools`

[Raphael Hertzog]

Control: reassign -1 tracker.debian.org

On Thu, 10 Sep 2015, Antonio Terceiro wrote:
> I am behind the `thin` package, but I will sometimes receive emails that
> were supposed to be for the `thin-provisioning-tools` package, which I
> have nothing to do with.
> 
> Follows attached a compressed Maildir folder with some emails I just
> received, related to #798499.

Analyzing the headers confirm this indeed. It's probably related to the
fact that exim uses "-" as the separator between LOCAL_PART and
LOCAL_PART_SUFFX.

Looking into the tracker's code, it does not inject LOCAL_PART_SUFFIX
as it should (while the old PTS does).

Funny that nobody else noticed this until now... I'll fix this soonish.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

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

Bug#733489: Remaining patches for bug #733489

[Michael Schaller]

Friendly ping to Julian...

Bug#798632: failure building the cmis-client manual page

[Matthias Klose]

Package: src:libcmis
Version: 0.5.0-3

failure building the cmis-client manual page, and the error is ignored. looks
like some build dependency is missing?

[...]
make[4]: Nothing to be done for 'install-exec-am'.
/usr/bin/docbook-to-man doc/cmis-client.xml > cmis-client.1
/usr/bin/nsgmls:doc/cmis-client.xml:2:119:E: could not get
"/docbook/xml/4.3/docbookx.dtd" from "www.oasis-open.org" (reason given was "Not
Found")
/usr/bin/nsgmls:doc/cmis-client.xml:2:119:E: DTD did not contain element
declaration for document type name
/usr/bin/nsgmls:doc/cmis-client.xml:3:9:E: element "REFENTRY" undefined
/usr/bin/nsgmls:doc/cmis-client.xml:4:15:E: element "REFENTRYINFO" undefined
/usr/bin/nsgmls:doc/cmis-client.xml:4:15: open elements: REFENTRY
/usr/bin/nsgmls:doc/cmis-client.xml:5:9:E: element "DATE" undefined
/usr/bin/nsgmls:doc/cmis-client.xml:5:9: open elements: REFENTRY REFENTRYINFO
/usr/bin/nsgmls:doc/cmis-client.xml:7:10:E: element "REFMETA" undefined
/usr/bin/nsgmls:doc/cmis-client.xml:7:10: open elements: REFENTRY
/usr/bin/nsgmls:doc/cmis-client.xml:8:18:E: element "REFENTRYTITLE" undefined
/usr/bin/nsgmls:doc/cmis-client.xml:8:18: open elements: REFENTRY REFMETA
/usr/bin/nsgmls:doc/cmis-client.xml:9:14:E: element "MANVOLNUM" undefined
/usr/bin/nsgmls:doc/cmis-client.xml:9:14: open elements: REFENTRY REFMETA
/usr/bin/nsgmls:doc/cmis-client.xml:10:16:E: element "REFMISCINFO" undefined
/usr/bin/nsgmls:doc/cmis-client.xml:10:16: open elements: REFENTRY REFMETA
/usr/bin/nsgmls:doc/cmis-client.xml:12:13:E: element "REFNAMEDIV" undefined
/usr/bin/nsgmls:doc/cmis-client.xml:12:13: open elements: REFENTRY
/usr/bin/nsgmls:doc/cmis-client.xml:13:12:E: element "REFNAME" undefined
/usr/bin/nsgmls:doc/cmis-client.xml:13:12: open elements: REFENTRY REFNAMEDIV
/usr/bin/nsgmls:doc/cmis-client.xml:14:18:E: element "APPLICATION" undefined
/usr/bin/nsgmls:doc/cmis-client.xml:14:18: open elements: REFENTRY REFNAMEDIV
REFNAME
/usr/bin/nsgmls:doc/cmis-client.xml:16:15:E: element "REFPURPOSE" undefined
/usr/bin/nsgmls:doc/cmis-client.xml:16:15: open elements: REFENTRY REFNAMEDIV
/usr/bin/nsgmls:doc/cmis-client.xml:20:17:E: element "REFSYNOPSISDIV" undefined
/usr/bin/nsgmls:doc/cmis-client.xml:20:17: open elements: REFENTRY
/usr/bin/nsgmls:doc/cmis-client.xml:21:23:E: element "REFSYNOPSISDIVINFO" 
undefined
/usr/bin/nsgmls:doc/cmis-client.xml:21:23: open elements: REFENTRY 
REFSYNOPSISDIV
/usr/bin/nsgmls:doc/cmis-client.xml:22:11:E: element "DATE" undefined
/usr/bin/nsgmls:doc/cmis-client.xml:22:11: open elements: REFENTRY
REFSYNOPSISDIV REFSYNOPSISDIVINFO
/usr/bin/nsgmls:doc/cmis-client.xml:24:16:E: element "CMDSYNOPSIS" undefined
/usr/bin/nsgmls:doc/cmis-client.xml:24:16: open elements: REFENTRY 
REFSYNOPSISDIV
/usr/bin/nsgmls:doc/cmis-client.xml:25:14:E: element "COMMAND" undefined
/usr/bin/nsgmls:doc/cmis-client.xml:25:14: open elements: REFENTRY
REFSYNOPSISDIV CMDSYNOPSIS
/usr/bin/nsgmls:doc/cmis-client.xml:26:18:E: there is no attribute "CHOICE"
/usr/bin/nsgmls:doc/cmis-client.xml:26:18: open elements: REFENTRY
REFSYNOPSISDIV CMDSYNOPSIS
/usr/bin/nsgmls:doc/cmis-client.xml:26:25:E: element "ARG" undefined
/usr/bin/nsgmls:doc/cmis-client.xml:26:25: open elements: REFENTRY
REFSYNOPSISDIV CMDSYNOPSIS
/usr/bin/nsgmls:doc/cmis-client.xml:28:16:E: element "CMDSYNOPSIS" undefined
/usr/bin/nsgmls:doc/cmis-client.xml:28:16: open elements: REFENTRY 
REFSYNOPSISDIV
/usr/bin/nsgmls:doc/cmis-client.xml:29:14:E: element "COMMAND" undefined
/usr/bin/nsgmls:doc/cmis-client.xml:29:14: open elements: REFENTRY
REFSYNOPSISDIV CMDSYNOPSIS
/usr/bin/nsgmls:doc/cmis-client.xml:30:23:E: element "ARG" undefined
/usr/bin/nsgmls:doc/cmis-client.xml:30:23: open elements: REFENTRY
REFSYNOPSISDIV CMDSYNOPSIS
/usr/bin/nsgmls:doc/cmis-client.xml:31:25:E: element "ARG" undefined
/usr/bin/nsgmls:doc/cmis-client.xml:31:25: open elements: REFENTRY
REFSYNOPSISDIV CMDSYNOPSIS
/usr/bin/nsgmls:doc/cmis-client.xml:31:44:E: element "REPLACEABLE" undefined
/usr/bin/nsgmls:doc/cmis-client.xml:31:44: open elements: REFENTRY
REFSYNOPSISDIV CMDSYNOPSIS ARG
/usr/bin/nsgmls:doc/cmis-client.xml:32:25:E: element "ARG" undefined
/usr/bin/nsgmls:doc/cmis-client.xml:32:25: open elements: REFENTRY
REFSYNOPSISDIV CMDSYNOPSIS
/usr/bin/nsgmls:doc/cmis-client.xml:34:16:E: element "CMDSYNOPSIS" undefined
/usr/bin/nsgmls:doc/cmis-client.xml:34:16: open elements: REFENTRY 
REFSYNOPSISDIV
/usr/bin/nsgmls:doc/cmis-client.xml:35:14:E: element "COMMAND" undefined
/usr/bin/nsgmls:doc/cmis-client.xml:35:14: open elements: REFENTRY
REFSYNOPSISDIV CMDSYNOPSIS
/usr/bin/nsgmls:doc/cmis-client.xml:36:23:E: element "ARG" undefined
/usr/bin/nsgmls:doc/cmis-client.xml:36:23: open elements: REFENTRY
REFSYNOPSISDIV CMDSYNOPSIS
/usr/bin/nsgmls:doc/cmis-client.xml:37:23:E: element "ARG" undefined
/usr/bin/nsgmls:doc/cmis-client.xml:37:23: open elements: REFENTRY
REFSYNOPSISDIV CMDSYNOPSIS
/usr/bin/nsgmls:doc/cmis-client.xml:37:39:E: element "REPLACEABLE" undefined

Bug#798627: closure-linter: Section should be “web”

[Ben Finney]

Control: reassign -1 closure-linter
Control: retitle -1 closure-linter: Section should be “web”
Control: notfound -1 closure-compiler/2.3.13-2
Control: found -1 closure-linter/2.3.13-2

I muddled the package and version in the initial report. Reassigning
and setting metadata correctly for ‘closure-linter’.

-- 
 \“There are no significant bugs in our released software that |
  `\ any significant number of users want fixed.” —Bill Gates, |
_o__)   1995-10-23 |
Ben Finney 


signature.asc
Description: Digital signature

Bug#798610: ciderwebmail: Error message "Please come back later" shown when running via uWSGI

[Jonas Smedegaard]

Hi James,

Quoting James Valleroy (2015-09-11 01:22:21)
> I attempted to integrate ciderwebmail with Apache2 via uWSGI, based on 
> the instructions given in README.Debian. But when I access 
> http://localhost/cider, I just get a page that says "(en) Please come 
> back later" (along with several other translations of that error 
> message). I don't see any error messages in the uwsgi logs.

From your description it sounds like CiderWebmail instance may be served 
perfectly fine, but the Apache2 proxy is misconfigured to redirect to it 
somehow.

> This was tested on a fresh installation using the latest Debian stretch
> installer, then dist-upgraded to sid. Here's a list of the steps I took:
> # apt install apache2 uwsgi uwsgi-plugin-psgi
> # apt install libapache2-mod-uwsgi
> # ln -s -t /etc/uwsgi/apps-enabled ../apps-available/ciderwebmail.ini
> # ln -s -t /etc/apache2/conf-enabled /etc/ciderwebmail/apache-uwsgi.conf
> # service uwsgi restart ciderwebmail
> # service apache2 restart

How did you configure apache apart from that?  In particular, which 
uWSGI driver did you install and how was it configured in apache? 
(there's arguably a documentation flaw of not covering that aspect of 
setting up CiderWebmail...)


> I've attached the log file (/var/log/uwsgi/app/ciderwebmail.log).

Please provide apache logs too - and if you dd _any_ customization of 

Please also provide relevant parts of your apache2 config (e.g. vhost 
setup, if any).


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Bug#798423: RFS: alien/8.95 [QA] -- convert and install rpm and other packages

[Gianfranco Costamagna]

Built, I tested and the package was looking good.

Thanks for your contribution to Debian, I hope you will (as you said on irc)
consider contributing more in this nice package!

cheers,

G.

Bug#796899: easy as -pie

[Aurelien Jarno]

control: forwarded -1 https://sourceware.org/bugzilla/show_bug.cgi?id=16381
control: tag -1 + fixed-upstream
control: fixed -1 2.21-0experimental0

On 2015-09-11 01:30, Joey Hess wrote:
> Fully minimal test case is in the attached shell script.
> 
> This bug only occurs if the binary is linked with -pie.

Thanks a lot for this minimal test case, I have been able to reproduce
the bug and find the corresponding upstream bug. It's BZ#16381 and it
is fixed in upstream commit 798212a0.

It is fixed with the glibc version in experimental, I am therefore
marking this in the BTS. We'll fix this bug in the next glibc upload.
However so far it is unclear if the next upload to unstable will be from
the 2.19 branch or the 2.21 branch.

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


signature.asc
Description: Digital signature

Bug#798423: RFS: alien/8.95 [QA] -- convert and install rpm and other packages

[Fabiano Antunes]

Perfect!

I'll certainly do my best to continue contributing.

Thank you for your patience, guidance and support.

Best regards,
  Fabiano.

On 09/11/2015 05:28 AM, Gianfranco Costamagna wrote:

Built, I tested and the package was looking good.

Thanks for your contribution to Debian, I hope you will (as you said on irc)
consider contributing more in this nice package!

cheers,

G.

Bug#798423: RFS: alien/8.95 [QA] -- convert and install rpm and other packages

[Fabiano Antunes]

Perfect!

I'm certainly do my best to continue contributing.

Thank you for your patience, guidance and support.

Best regards,
  Fabiano.

On 09/11/2015 05:28 AM, Gianfranco Costamagna wrote:

Built, I tested and the package was looking good.

Thanks for your contribution to Debian, I hope you will (as you said on irc)
consider contributing more in this nice package!

cheers,

G.

Bug#798634: virt-manager: "Send key" translated to "Verstuur sleutel" (Dutch)

[Benedikt Wildenhain (BO)]

Package: virt-manager
Version: 1:1.2.1-4
Severity: minor

Dear Maintainer,

   * What led up to the situation?
I started virt-lang with LANG=nl_BE.UTF-8

   * What was the outcome of this action?
Menu item "Send key" gets translated to "Verstuur sleutel" (which
literally means "Send key", but "key" as in encryption)

   * What outcome did you expect instead?
Menu item "Send key" gets translated to "Verstuur toets" (which
means "key" as in keyboard)

I sent a pull request to upstream:
https://github.com/virt-manager/virt-manager/pull/1

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

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

Versions of packages virt-manager depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.24.0-2
ii  gconf2   3.2.6-3
ii  gir1.2-gtk-3.0   3.16.6-1
ii  gir1.2-gtk-vnc-2.0   0.5.3-1.3
ii  gir1.2-libosinfo-1.0 0.2.11-1.1
ii  gir1.2-libvirt-glib-1.0  0.2.2-0.1
ii  gir1.2-vte-2.91  0.40.2-2
ii  librsvg2-common  2.40.10-1
ii  python-dbus  1.2.0-2+b3
ii  python-gi3.16.2-1
ii  python-gi-cairo  3.16.2-1
ii  python-ipaddr2.1.11-2
ii  python-libvirt   1.2.15-1
ii  python-urlgrabber3.9.1-4.1
pn  python2.7:any
pn  python:any   
ii  virtinst 1:1.2.1-4

Versions of packages virt-manager recommends:
ii  gir1.2-spice-client-gtk-3.0  0.29-1
ii  gnome-icon-theme 3.12.0-1
ii  libvirt-daemon-system1.2.19-1

Versions of packages virt-manager suggests:
ii  gnome-keyring  3.16.0-4
ii  ksshaskpass [ssh-askpass]  4:5.4.0-1
pn  python-gnomekeyring
pn  python-guestfs 
ii  virt-viewer1.0-1

-- no debconf information

Bug#798633: package cleanup: use dpkg-buildflags, parallel build, remove cruft

[Matthias Klose]

Package: src:libcmis
Version: 0.5.0-3
Severity: important
Tags: patch

  * Bump the standards version.
  * Remove cruft in the debian directory.
  * Enable parallel builds.
  * Stop building with -O0 on armhf.
  * Really use dpkg-buildflags.

  * Bump the standards version.
  * Remove cruft in the debian directory.
  * Enable parallel builds.
  * Stop building with -O0 on armhf.
  * Really use dpkg-buildflags.

diff -Nru libcmis-0.5.0/debian/control libcmis-0.5.0/debian/control
--- libcmis-0.5.0/debian/control2015-08-03 14:34:29.0 +0200
+++ libcmis-0.5.0/debian/control2015-09-11 11:22:30.0 +0200
@@ -2,7 +2,7 @@
 Priority: optional
 Maintainer: Rene Engelhard 
 BuIld-Depends: debhelper (>= 8.0.0), autotools-dev, libxml2-dev, libboost-dev, 
libboost-program-options-dev, libcurl4-gnutls-dev, libcppunit-dev (= 
1.13.2-2.1), docbook-to-man, libboost-date-time-dev, dpkg-dev (>= 1.16.1), 
pkg-config, dh-autoreconf
-Standards-Version: 3.9.2
+Standards-Version: 3.9.6
 Section: libs
 Homepage: http://libcmis.sourceforge.net/
 
diff -Nru libcmis-0.5.0/debian/libcmis-0.5-5.postinst.debhelper 
libcmis-0.5.0/debian/libcmis-0.5-5.postinst.debhelper
--- libcmis-0.5.0/debian/libcmis-0.5-5.postinst.debhelper   2015-04-05 
08:57:14.0 +0200
+++ libcmis-0.5.0/debian/libcmis-0.5-5.postinst.debhelper   1970-01-01 
01:00:00.0 +0100
@@ -1,5 +0,0 @@
-# Automatically added by dh_makeshlibs
-if [ "$1" = "configure" ]; then
-   ldconfig
-fi
-# End automatically added section
diff -Nru libcmis-0.5.0/debian/libcmis-0.5-5.postrm.debhelper 
libcmis-0.5.0/debian/libcmis-0.5-5.postrm.debhelper
--- libcmis-0.5.0/debian/libcmis-0.5-5.postrm.debhelper 2015-04-05 
08:57:14.0 +0200
+++ libcmis-0.5.0/debian/libcmis-0.5-5.postrm.debhelper 1970-01-01 
01:00:00.0 +0100
@@ -1,5 +0,0 @@
-# Automatically added by dh_makeshlibs
-if [ "$1" = "remove" ]; then
-   ldconfig
-fi
-# End automatically added section
diff -Nru libcmis-0.5.0/debian/libcmis-0.5-5.substvars 
libcmis-0.5.0/debian/libcmis-0.5-5.substvars
--- libcmis-0.5.0/debian/libcmis-0.5-5.substvars2015-04-05 
08:57:17.0 +0200
+++ libcmis-0.5.0/debian/libcmis-0.5-5.substvars1970-01-01 
01:00:00.0 +0100
@@ -1,2 +0,0 @@
-shlibs:Depends=libboost-date-time1.55.0, libc6 (>= 2.14), libcmis-0.5-5, 
libcurl3-gnutls (>= 7.16.2), libgcc1 (>= 1:4.1.1), libstdc++6 (>= 4.9), libxml2 
(>= 2.7.4)
-misc:Depends=
diff -Nru libcmis-0.5.0/debian/rules libcmis-0.5.0/debian/rules
--- libcmis-0.5.0/debian/rules  2015-08-03 14:16:52.0 +0200
+++ libcmis-0.5.0/debian/rules  2015-09-11 11:34:58.0 +0200
@@ -11,15 +11,16 @@
 
 include /usr/share/dpkg/architecture.mk
 
+DPKG_EXPORT_BUILDFLAGS=1
 include /usr/share/dpkg/buildflags.mk
 
-ifneq (,$(findstring arm,$(DEB_HOST_ARCH)))
-   CXXFLAGS += -O0
-   export CXXFLAGS
+COMMA = ,
+ifneq (,$(filter parallel=%,$(subst $(COMMA), ,$(DEB_BUILD_OPTIONS
+  NJOBS := -j $(subst parallel=,,$(filter parallel=%,$(subst $(COMMA), 
,$(DEB_BUILD_OPTIONS
 endif
 
 %:
-   dh $@  --with autoreconf
+   dh $@  --parallel --with autoreconf
 
 override_dh_clean:
rm -f libcmis-0.4.pc
@@ -34,10 +35,10 @@
 endif
 
 override_dh_auto_build:
-   $(MAKE)
+   $(MAKE) $(NJOBS)
 
 override_dh_auto_test:
-   $(MAKE) check
+   $(MAKE) $(NJOBS) check
 
 override_dh_auto_install:
dh_auto_install

Bug#798626: perl: -V lies about -Duseshrplib

[Niko Tyni]

Package: perl
Version: 5.20.0-6
Severity: minor

With static builds (-Uuseshrplib, where /usr/bin/perl is statically linked
against libperl), perl -V lies about the configuration because we install
Config.pm from the shared build (-Duseshrplib). This has been the case
for a long time on i386, and since 5.20.2-5 we use a statically built
/usr/bin/perl on all architectures.

The situation is somewhat better with the 5.22 packaging, where we install
two Config.pm files: once in perl-base under /usr/lib//perl-base
and once in libperl5.22 under /usr/lib/perl/5.22. The former
Config.pm has the configuration from the static build and the latter
from the shared build.

However, the current @INC in the 5.22 packages has the perl-base
directory at the very end, so on non-minimal systems with libperl5.22
installed, perl -V still lies because the libperl5.22 Config.pm takes
precedence.  If libperl5.22 is not present, 'perl -V' will show the
correct configuration.

The right order of @INC would probably be to put
/usr/lib//perl-base right before /usr/lib/perl/5.22.
There's no configuration knob for this so it needs patching perl.c.

I'm not aware of other bad effects with the current ordering so
this is not a priority.
-- 
Niko Tyni   nt...@debian.org

Bug#766182: systemd: incorrect dmesg message about missing nss-myhostname

[Vincent Lefevre]

On 2015-09-11 08:32:41 +0200, Michael Biebl wrote:
> The presence of /etc/hosts does not mean that your local hostname is
> configured there. It can easily get out of sync from what's configured
> in /etc/hostname.

I disagree: you could also check whether the local hostname is
configured there. Anyway, I no longer get this warning message
(though libnss-myhostname is still not installed on this machine),
so everything is now OK. The disappearance of the warning message
occurred between 2015-05-12 and 2015-06-28.

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

Bug#798527: virtualbox fails to work with systemd

[Gianfranco Costamagna]

Hi Ritesh, seems that I tried and I was wrong.

WARNING: The character device /dev/vboxdrv does not exist.
Please install the virtualbox-dkms package and the appropriate
headers, most likely linux-headers-generic.

You will not be able to start VMs until this problem is fixed.


virtualbox starts, but no vm can be started




Kernel driver not installed (rc=-1908)

The VirtualBox Linux kernel driver (vboxdrv) is either not loaded or there is a 
permission problem with /dev/vboxdrv. Please reinstall the kernel module by 
executing

'/etc/init.d/vboxdrv setup'

as root. If it is available in your distribution, you should install the DKMS 
package first. This package keeps track of Linux kernel changes and recompiles 
the vboxdrv kernel module if necessary.


so yes, please commit your solution on git :)


thanks!

G.

Bug#778063: pinot: diff for NMU version 1.05-1.1

[Jonas Smedegaard]

Quoting Jonas Smedegaard (2015-09-11 10:34:31)
> What you did was fine (no _need_ to do more), but you may optionally 
> consider in general when doing NMUs if package/maintainer is listed at 
> https://wiki.debian.org/LowThresholdNmu - here you could've released 
> with a low threshold and also (if you like, and still an option) 
> pushed your changed directly to git :-)

Correction, I was wrong: LowThresholdNmu didn't encourage you to commit 
to git for packages I maintain outside of teams - now it does :-)

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Bug#798629: Only happens with self built kernel

[Martin Steigerwald]

Hello!

Also happens with linux-image-4.1.0-2-amd64 4.1.6-1 both "w" and "who".

But there is another interesting detail:

tty sessions are shown

martin@merkaba:~#1> w
 11:06:18 up 3 min,  1 user,  load average: 0,86, 0,95, 0,42
USER TTY  FROM LOGIN@   IDLE   JCPU   PCPU WHAT
root tty1 -11:015:13   0.18s  0.13s -zsh
martin@merkaba:~> who
root tty1 2015-09-11 11:01

while desktop sessions are not shown. (I am currently logged into Plasma 5).

Thanks,
-- 
Martin

Bug#798630: sasl2-bin: saslauthd rimap error with dovecot-imapd

[David Cure]

Package: sasl2-bin
Version: 2.1.26.dfsg1-13
Severity: normal



Dear Maintainer,


I configure saslauthd (for use with sendmail) to use rimap to
authenticate against dovecote-imapd.

Every time, I get this error message :

saslauthd[8707]: do_auth : auth failure: [user=]
[service=smtp] [realm=] [mech=rimap] [reason=[ALERT] Unexpected response
from remote authentication server]

and after several try (and error), the user succeed to authenticate

I check in the dovecot-log and no error

(I have the same configuration on wheezy and no problem)

Any idea ?

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

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

Versions of packages sasl2-bin depends on:
ii  db-util5.3.0
ii  debconf [debconf-2.0]  1.5.56
ii  libc6  2.19-18
ii  libcomerr2 1.42.12-1.1
ii  libdb5.3   5.3.28-9
ii  libgssapi-krb5-2   1.12.1+dfsg-19
ii  libk5crypto3   1.12.1+dfsg-19
ii  libkrb5-3  1.12.1+dfsg-19
ii  libldap-2.4-2  2.4.40+dfsg-1
ii  libpam0g   1.1.8-3.1
ii  libsasl2-2 2.1.26.dfsg1-13
ii  libssl1.0.01.0.1k-3+deb8u1

sasl2-bin recommends no packages.

sasl2-bin suggests no packages.

-- Configuration Files:
/etc/default/saslauthd changed:
START=yes
DESC="SASL Authentication Daemon"
NAME="saslauthd"
MECHANISMS="rimap"
MECH_OPTIONS="localhost"
THREADS=20
OPTIONS="-c -m /var/run/saslauthd"


-- debconf information:
  cyrus-sasl2/upgrade-sasldb2-backup-failed:
  cyrus-sasl2/purge-sasldb2: false
  cyrus-sasl2/upgrade-sasldb2-failed:
  cyrus-sasl2/backup-sasldb2: /var/backups/sasldb2.bak



signature.asc
Description: Digital signature

Bug#737057: debmirror: Please add xz support

[John Paul Adrian Glaubitz]

Hi!

> (Apparently bzip2 might go away, too.
> See Ansgar's bug report: http://bugs.debian.org/737037)

This seems to have broken debmirror now as it's no longer
being able to retrieve the Sources.bz2 and therefore generates
it themselves which results in an invalid Sources file.

We are using debmirror for our local Debian mirror and have
run into problem with the validation of the Sources file:

root@jessie64:~> apt-get update
Ign file: jessie InRelease
Ign file: jessie/updates InRelease
Ign file: jessie-backports InRelease
(...)
W: Failed to fetch
file:/net/deb/debian/dists/jessie-backports/non-free/source/Sources
Hash Sum mismatch

E: Some index files failed to download. They have been ignored, or old
ones used instead.
root@jessie64:~>

I assume the priority of this bug should be raised unless there
is some workaround to fix this.

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#798691: libc6-i686: sin() sometimes broken

[Christian Tacke]

Package: libc6-i686
Version: 2.19-18+deb8u1
Severity: important

Hi,

I was trying to create a local backport of python-cffi onto
jessie/i386.

On a system with libc6-i686 installed, I get a failure in
the self test of the build:

>   assert library.sin(12.3) == math.sin(12.3)
E   assert 0.8444952930965295 == -0.26323179136580094

Uninstalling libc6-i686 lets the full build and tests run
through.

Something very related has already happened before:
https://www.sourceware.org/bugzilla/show_bug.cgi?id=16625

This suggests a compiler bug in gcc 4.8. But jessie is
compiled with 4.9, so it must be something a bit different.


Severity: important as giving wrong results to math
functions isn't something trivial, really and can affect
multiple unrelated components/packages.


Cheers

Christian

-- 
www.cosmokey.com

Bug#798693: opensurgsim: FTBFS on i386 and powerpc: unaligned Eigen arrays

[Aaron M. Ucko]

Source: opensurgsim
Version: 0.6.0-2
Severity: serious
Justification: fails to build from source

The i386 and powerpc builds of opensurgsim both failed because many
tests reported errors of the form 

SurgSim*Test: /usr/include/eigen3/Eigen/src/Core/DenseStorage.h:86: 
Eigen::internal::plain_array::plain_array() 
[with T = double; int Size = 16; int MatrixOrArrayOptions = 0]: Assertion 
`(reinterpret_cast(eigen_unaligned_array_assert_workaround_gcc47(array))
 & 0xf) == 0 && "this assertion is explained here: " 
"http://eigen.tuxfamily.org/dox-devel/group__TopicUnalignedArrayAssert.html; " 
 READ THIS WEB PAGE !!! "' failed.

(The powerpc build also encountered an unrelated test suite error,
which I'll report separately.)

Could you please take a look?  Per the error message, you may find
http://eigen.tuxfamily.org/dox-devel/group__TopicUnalignedArrayAssert.html
helpful.

Thanks!

Bug#798692: nmu: libstdc++v5 related binNMUs in experimental

[Andreas Beckmann]

Package: release.debian.org
Severity: normal
Tags: experimental
User: release.debian@packages.debian.org
Usertags: binnmu

Some binNMUs for experimental related to the libstdc++v5 transition in
sid. These packages have finished their GCC 5 transition (usually just a
rebuild) and migrated to testing. They need to be rebuilt in experimental, too.
All packages were successfully build-tested in sid+experimental/amd64.


nmu imagemagick_8:6.9.1.2-1 . ALL . experimental . -m "Rebuild against 
libopenexr6v5"
nmu gegl_0.3.0-4 . ALL . experimental . -m "Rebuild against libopenexr6v5"

nmu tomboy_1.15.4-1 . ALL . experimental . -m "Rebuild against libproxy1v5"
nmu glib-networking_2.45.1-1 . ALL . experimental . -m "Rebuild against 
libproxy1v5"
nmu libquvi_0.9.3-1 . ALL . experimental . -m "Rebuild against libproxy1v5"

nmu lnav_0.7.2-1 . ALL . experimental . -m "Rebuild against libpcrecpp0v5"

nmu ffmpegthumbs_4:14.12.2-1 . ALL . experimental . -m "Rebuild against ffmpeg."

nmu kdesdk-strigi-analyzers_4:14.12.2-1 . ALL . experimental . -m "Rebuild 
against libstreamanalyzer0v5"
nmu kdegraphics-mobipocket_4:14.12.2-1 . ALL . experimental . -m "Rebuild 
against libstreamanalyzer0v5"
nmu kdegraphics-strigi-analyzer_4:14.12.2-1 . ALL . experimental . -m "Rebuild 
against libstreamanalyzer0v5"
nmu kdenetwork-strigi-analyzers_4:14.12.2-1 . ALL . experimental . -m "Rebuild 
against libstreamanalyzer0v5"

nmu simgear_3.6.0~git20150802+a841fc-1~exp1 . ALL . experimental . -m "Rebuild 
against libopenscenegraph100v5"

nmu kscd_4:14.12.2-1 . ALL . experimental . -m "Rebuild against 
libmusicbrainz3-6v5"


Andreas

Bug#798699: java.lang.ClassCastException: java.io.File cannot be cast to java.lang.Class

[Markus Koschany]

Control: severity -1 grave
Control: tags -1 stretch sid

On Fri, 11 Sep 2015 21:04:01 +0200 Emmanuel Fleury  wrote:
> Package: freecol
> Version: 0.10.7+dfsg-3
> Severity: important
> 
> Just running the software leads to the following Java exception:
> 
> $> freecol
> Disabling IPV6 network stack to work around bug #560056 on openjdk
> If you experience problems with connecting to remote servers,
> you can put it back by running Freecol this way:
>   freecol --enable-ipv6
> Exception in thread "main" java.lang.ClassCastException: java.io.File
> cannot be cast to java.lang.Class
>   at org.apache.commons.cli.OptionBuilder.withType(OptionBuilder.java:298)
>   at net.sf.freecol.FreeCol.handleArgs(FreeCol.java:338)
>   at net.sf.freecol.FreeCol.main(FreeCol.java:150)
> ^C
> 
> The process still hang afterward, I need to press Ctrl-C to stop it.

Thanks for the report. This makes the package basically unusable.
Raising the severity accordingly. Jessie is not affected.

Regards,

Markus



signature.asc
Description: OpenPGP digital signature

Bug#798699: java.lang.ClassCastException: java.io.File cannot be cast to java.lang.Class

[Markus Koschany]

Control: severity -1 grave
Control: tags -1 stretch sid

On Fri, 11 Sep 2015 21:04:01 +0200 Emmanuel Fleury  wrote:
> Package: freecol
> Version: 0.10.7+dfsg-3
> Severity: important
> 
> Just running the software leads to the following Java exception:
> 
> $> freecol
> Disabling IPV6 network stack to work around bug #560056 on openjdk
> If you experience problems with connecting to remote servers,
> you can put it back by running Freecol this way:
>   freecol --enable-ipv6
> Exception in thread "main" java.lang.ClassCastException: java.io.File
> cannot be cast to java.lang.Class
>   at org.apache.commons.cli.OptionBuilder.withType(OptionBuilder.java:298)
>   at net.sf.freecol.FreeCol.handleArgs(FreeCol.java:338)
>   at net.sf.freecol.FreeCol.main(FreeCol.java:150)
> ^C
> 
> The process still hang afterward, I need to press Ctrl-C to stop it.

Thanks for the report. This makes the package basically unusable.
Raising the severity accordingly. Jessie is not affected.

Regards,

Markus



signature.asc
Description: OpenPGP digital signature

Bug#798703: wreport: ABI transition needed for libstdc++ v5

[Simon McVittie]

Source: wreport
Version: 2.14-1
Severity: serious
Justification: breaks ABI without a package rename
Tags: sid stretch
User: debian-...@lists.debian.org
Usertags: libstdc++-cxx11

Background[1]: libstdc++6 introduces a new ABI to conform to the
C++11 standard, but keeps the old ABI to not break existing binaries.
Packages which are built with g++-5 from experimental (not the one
from testing/unstable) are using the new ABI.  Libraries built from
this source package export some of the new __cxx11 or B5cxx11 symbols,
dropping other symbols.  If these symbols are part of the API of
the library, then this rebuild with g++-5 will trigger a transition
for the library.

In the case of wreport, std::string appears in functions in public
headers (for example Var::format), so it seems very likely that a
transition is needed. The transition normally consists of renaming the
affected library packages, adding a v5 suffix (libwreport2v5).
The SONAME should not be changed when doing this.

If an upgrade to a new upstream SONAME is already planned, and that
SONAME has never been available in Debian compiled with g++-4, then an
alternative way to carry out the transition would be to bump the
SONAME.

These follow-up transitions for libstdc++ are not going through exactly
the normal transition procedure, because many entangled transitions are
going on at the same time, and the usual ordered transition procedure
does not scale that far. When all the C++ libraries on which this library
depends have started their transitions in unstable if required, this
library should do the same, closing this bug; the release team will deal
with binNMUs as needed.

Looking at the build-dependencies of wreport, the only C++ library
seems to be libwibble, which is static (and was already rebuilt).
So this sub-transition is ready to start.

The package might be NMU'd if there is no maintainer response. The
release team have declared a 2 day NMU delay[2] for packages involved
in the libstdc++ transition, in order to get unstable back to a usable
state in a finite time.

Regards,
S

[1] https://wiki.debian.org/GCC5#libstdc.2B-.2B-_ABI_transition
[2] https://lists.debian.org/debian-devel-announce/2015/08/msg0.html

Bug#798458: RFS: mini-httpd/1.21-1 [ITA] -- Small HTTP server

[Vincent Bernat]

 ❦ 11 septembre 2015 19:50 +0200, Vincent Bernat  :

>>> The description of fix-mini-httpd-vhost could be "Append port number to
>>> vhost". The name of the patch could be "append-portno-to-vhost.patch". A
>>> bug report number to know why this is done would be great to.
>> fix name.
>> Yes, look [1]
>
> You can include the bug number in the patch (with Bug:). I see that you
> already put it in the changelog but the entry doesn't help to know what
> the patch is about.

In the patch itself, you can include the bug number.

Description: Append port number to vhost.
   Thanks Steffen Grunewald 
Author: Jose dos Santos Junior 
Last-Update: 2015-09-05
Bug: http://bugs.debian.org/x

>>> Also, this
>>> would make the Debian package behaves differently than upstream. Has
>>> this patch been pushed upstream?
>> No, patch suggestion bug number #491078 [1]
>
> The bug is from 2008 and despite numerous releases, it is not present
> upstream. This makes mini-httpd behaves differently in Debian than in
> other distributions or when just compiled from sources.
>
> This will also break setup of people that were relying on the original
> behavior, so you would need to add an entry in NEWS.Debian to advertise
> the change.
>
> I would not include the patch until it is vetted by upstream.

The patch to remove the port number is a deviation from what is done
upstream. mini-httpd in Debian won't behave in the same way as
mini-httpd somewhere else (including in older releases of Debian). The
patch should be pushed upstream and not applied in Debian until it is
applied upstream.

Moreover, if you apply the patch in Debian, you also need to write an
entry in debian/NEWS.Debian to tell the users that the behavior of
mini-httpd has changed. This is totally not worth it.

Just send the patch upstream (with a reference to the bug report). And
don't apply it yet.

>>> The description of fix-mini-httpd could be "Fix buffer overflow in
>>> add_to_response". The name of the patch could be
>>> "add_to_response-buffer-overflow.patch". The stuff about indexes should
>>> be moved out to a different patch: when your patch is applied upstream,
>>> you may discard it and forget about this part.
>>> 
>> Ok, fix name.
>> Yes, when the upstream fix in tarball original I'm remove patch.
>> thanks
>
> The patch still contains an unrelated change about how to find files
> like "index.html". Upstream may never fix the index.mini-httpd.html
> stuff, so you will have to separate the patch at some point. It's better
> to do it now.

The add_to_response-buffer-overflow patch also contains this chunk:

#v+
@@ -1140,8 +1140,8 @@ handle_request( void )
 char* cp;
 int r, file_len, i;
 const char* index_names[] = {
-   "index.html", "index.htm", "index.xhtml", "index.xht", "Default.htm",
-   "index.cgi" };
+   "index.html", "index.mini-httpd.html", "index.htm", "index.xhtml", 
"index.xht", "Default.htm",
+   "index.cgi", "index.php" };

 /* Set up the timeout for reading. */
 #ifdef HAVE_SIGSET
#v-

This has nothing to do with the overflow problem. You need to put this
chunk into another patch.
-- 
Debian package sponsoring guidelines:
 http://vincent.bernat.im/en/debian-package-sponsoring.html


signature.asc
Description: PGP signature

Bug#798696: breeze-cursor-theme: Breeze mouse theme reverts to default X11 mouse due to lack of line in index.theme

[Alejandro Lorenzo Gallego]

Package: breeze-cursor-theme
Version: 4:5.4.0-1
Severity: normal

Dear Maintainer,

When using breee-cursor-theme the mouse theme reverts to default X11 cursor 
(for example, the resize cursor is not shown) because the index.theme file 
lacks a line describing the Inherit=breeze_cursors

Please, consider changing this

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

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

-- debconf-show failed

Bug#638720: Odoo packaging

[Dmitry Smirnov]

On Friday 11 September 2015 20:22:26 martin f krafft wrote:
> also sprach Dmitry Smirnov  [2015-05-06 18:30 +0200]:
> > I'm leaving packaging in almost finished state -- as per TODO
> > there are only few non-DFSG issues left. Also Bootswatch themes
> > are full of "privacy-breach" issues and have to be packaged
> > separately anyway.
> 
> Where is this packaging?

At collab-maint (repo's URL already mentioned earlier in this bug):

http://anonscm.debian.org/cgit/collab-maint/odoo.git


> Has there been any progress made on the side of Odoo,

No, they've never replied to me and I'm not happy with their bug handling 
either. :(


> or by Martin/Ben?

No. I was working alone...

-- 
All the best,
 Dmitry Smirnov.

---

It has been said that democracy is the worst form of government except
all the others that have been tried.
-- Winston Churchill


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

Bug#798458: RFS: mini-httpd/1.21-1 [ITA] -- Small HTTP server

[J . S . Júnior]

Em Fri, 11 Sep 2015 20:01:55 +0200
Vincent Bernat  escreveu:

> Which part didn't you understand?
All. :(

What ta missing to pack the package.

I'm sorry, but I'm learning, and I know some programming in C.

thanks.

and again thank you for your patience and dedication of their time.

[]'s
JJ


pgpH696wqQX4N.pgp
Description: Assinatura digital OpenPGP

Bug#798706: fusionforge-web: unowned files after purge (policy 6.8, 10.8): /etc/apache2/sites-available/fusionforge.conf, /etc/fusionforge/ssl-cert*

[Andreas Beckmann]

Package: fusionforge-web
Version: 6.0.2+20150908-1
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package left unowned files on
the system after purge, which is a violation of policy 6.8 (or 10.8):

https://www.debian.org/doc/debian-policy/ch-maintainerscripts.html#s-removedetails

Filing this as important as having a piuparts clean archive is a release
goal since lenny.

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

2m9.6s ERROR: FAIL: Package purging left files on system:
  /etc/apache2/sites-available/fusionforge.conf -> /etc/fusionforge/httpd.conf  
 not owned
  /etc/fusionforge/ssl-cert-scm.key  not owned
  /etc/fusionforge/ssl-cert-scm.pem  not owned
  /etc/fusionforge/ssl-cert.key  not owned
  /etc/fusionforge/ssl-cert.pem  not owned



cheers,

Andreas


fusionforge-web_6.0.2+20150908-1.log.gz
Description: application/gzip

Bug#798610: ciderwebmail: Error message "Please come back later" shown when running via uWSGI

[James Valleroy]

On 09/11/2015 04:30 AM, Jonas Smedegaard wrote:
> Hi James,
> 
> Quoting James Valleroy (2015-09-11 01:22:21)
>> I attempted to integrate ciderwebmail with Apache2 via uWSGI, based on 
>> the instructions given in README.Debian. But when I access 
>> http://localhost/cider, I just get a page that says "(en) Please come 
>> back later" (along with several other translations of that error 
>> message). I don't see any error messages in the uwsgi logs.
> 
> From your description it sounds like CiderWebmail instance may be served 
> perfectly fine, but the Apache2 proxy is misconfigured to redirect to it 
> somehow.

The page showing the error doesn't look like a usual Apache error page.
I attached a screenshot.

>> This was tested on a fresh installation using the latest Debian stretch
>> installer, then dist-upgraded to sid. Here's a list of the steps I took:
>> # apt install apache2 uwsgi uwsgi-plugin-psgi
>> # apt install libapache2-mod-uwsgi
>> # ln -s -t /etc/uwsgi/apps-enabled ../apps-available/ciderwebmail.ini
>> # ln -s -t /etc/apache2/conf-enabled /etc/ciderwebmail/apache-uwsgi.conf
>> # service uwsgi restart ciderwebmail
>> # service apache2 restart
> 
> How did you configure apache apart from that?  In particular, which 
> uWSGI driver did you install and how was it configured in apache? 
> (there's arguably a documentation flaw of not covering that aspect of 
> setting up CiderWebmail...)

There was no additional configuration other than what's shown above. I
just installed libapache2-mod-uwsgi, and it enabled itself after install.

I've attached a listing/printout of my configuration (apache-configs.txt).

> 
>> I've attached the log file (/var/log/uwsgi/app/ciderwebmail.log).
> 
> Please provide apache logs too - and if you dd _any_ customization of 
> 
> Please also provide relevant parts of your apache2 config (e.g. vhost 
> setup, if any).

I've attached the apache logs.

Thanks for the quick response!

--
James


apache_logs.tar.gz
Description: application/gzip
jvalleroy@debian:/etc/apache2$ ls sites-enabled/
000-default.conf
jvalleroy@debian:/etc/apache2$ cat sites-enabled/000-default.conf 

# The ServerName directive sets the request scheme, hostname and port 
that
# the server uses to identify itself. This is used when creating
# redirection URLs. In the context of virtual hosts, the ServerName
# specifies what hostname must appear in the request's Host: header to
# match this virtual host. For the default virtual host (this file) this
# value is not decisive as it is used as a last resort host regardless.
# However, you must set it for any further virtual host explicitly.
#ServerName www.example.com

ServerAdmin webmaster@localhost
DocumentRoot /var/www/html

# Available loglevels: trace8, ..., trace1, debug, info, notice, warn,
# error, crit, alert, emerg.
# It is also possible to configure the loglevel for particular
# modules, e.g.
#LogLevel info ssl:warn

ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined

# For most configuration files from conf-available/, which are
# enabled or disabled at a global level, it is possible to
# include a line for only one particular virtual host. For example the
# following line enables the CGI configuration for this host only
# after it has been globally disabled with "a2disconf".
#Include conf-available/serve-cgi-bin.conf


# vim: syntax=apache ts=4 sw=4 sts=4 sr noet
jvalleroy@debian:/etc/apache2$ ls mods-enabled/
access_compat.load  authz_host.load  dir.loadnegotiation.conf
alias.conf  authz_user.load  env.loadnegotiation.load
alias.load  autoindex.conf   filter.load setenvif.conf
auth_basic.load autoindex.load   mime.conf   setenvif.load
authn_core.load deflate.conf mime.load   status.conf
authn_file.load deflate.load mpm_event.conf  status.load
authz_core.load dir.conf mpm_event.load  uwsgi.load
jvalleroy@debian:/etc/apache2$ ls conf-enabled/
apache2-uwsgi.conf  localized-error-pages.confsecurity.conf
charset.confother-vhosts-access-log.conf  serve-cgi-bin.conf
jvalleroy@debian:/etc/apache2$ cat conf-enabled/apache2-uwsgi.conf 

SetHandler uwsgi-handler
uWSGISocket /run/uwsgi/app/ciderwebmail/socket

jvalleroy@debian:/etc/apache2$ 


signature.asc
Description: OpenPGP digital signature

Bug#798697: Use CSS pre-wrap for message pages on lists.debian.org

[James Y Knight]

Package: lists.debian.org

For example, the mail:
  https://lists.debian.org/debian-sparc/2015/06/msg5.html
would be a lot easier to read in the archive, if the text soft-wrapped to
the browser width, instead of making a horizontal scrollbar.

Accomplishing this should be as trivial as adding a tiny bit of css to the
page, like:

pre {
 white-space: pre-wrap;
}

Bug#798698: icewm: copyright file missing (policy 12.5)

[Andreas Beckmann]

Package: icewm
Version: 1.3.8+githubmod+20150818+ad97152-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

a test with piuparts revealed that your package misses the copyright
file, which is a violation of Policy 12.5:
https://www.debian.org/doc/debian-policy/ch-docs.html#s-copyrightfile

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

0m35.9s ERROR: WARN: Inadequate results from running adequate!
  icewm: missing-copyright-file /usr/share/doc/icewm/copyright

  # ls -la /usr/share/doc/icewm/
  total 12
  drwxr-xr-x   2 root root   60 Aug 22 21:34 .
  drwxr-xr-x 136 root root 2860 Aug 22 21:34 ..
  -rw-r--r--   1 root root 8271 Aug 18 10:33 preferences.gz


cheers,

Andreas


icewm_1.3.8+githubmod+20150818+ad97152-1.log.gz
Description: application/gzip

Bug#798591: libreoffice: Long click closes Libre Office 5

[Linux - Junior Polegato]

Hi!

On 11-09-2015 12:09, Chris Halls wrote:

tags 798591 unreproducible moreinfo
thanks

Hi

On 10/09/15 22:30, Junior Polegato wrote:

I updated some machines with the version 5 of Libre Office and now when user
holds the left button of mouse to select some text or cells, the program
closes, losing user data.

Oh dear, that doesn't sound good :(


I noticed that this happened when the user holds and doesn't move the mouse,
like a long click. Whatever, if he clicks, holds and moves the mouse, this
doesn't happen.

I'm afraid I can't reproduce the problem here. I'm going to ask some
questions that will hopefully help us work out what is happening.

Is there a particular sequence of events that you need to trigger the
problem, or is it every time you hold the mouse button down?


No particular sequence of events, any time I hold the mouse button down 
for some seconds, the program closes.



You mentioned that you have upgraded some machines. Are you able to
reproduce the problem on different machines?


Yes, even I installed from zero two formated machines and get the same 
problem.



It's possible that there are some library incompatibilities caused by
the gcc 5 transition. Could you check if all packages are at their
newest version from unstable?


Yes, all packages are at their newest version, but from testing.


If you can easily reproduce the problem, could you try to get a stack
trace for us?

-
# Install debug symbols. These are quite big, so if you don't have
enough bandwidth or disk space, skip this step for now

apt-get install --no-install-recommends libreoffice-dbg

# We need gdb installed to generate the backtrace
apt-get install gdb

# Start libreoffice using '--backtrace'

loffice --backtrace

# Make it crash!

# Then send the file gdbtrace.log, which will be in your current working
directory where you started libreoffice from
-


I did this and attached in this message goes this log file.


Thanks!
Chris


Thanks,

Junior Polegato

warning: Currently logging to gdbtrace.log.  Turn the logging off and on to make the new setting effective.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/i386-linux-gnu/i686/cmov/libthread_db.so.1".
[New Thread 0xafee2b40 (LWP 26906)]
[New Thread 0xae7bab40 (LWP 26908)]
[New Thread 0xaddffb40 (LWP 26909)]
[New Thread 0xad2b0b40 (LWP 26910)]
[New Thread 0xab704b40 (LWP 26914)]
[Thread 0xab704b40 (LWP 26914) exited]
[Thread 0xae7bab40 (LWP 26908) exited]
[New Thread 0xae7bab40 (LWP 26921)]
[Thread 0xae7bab40 (LWP 26921) exited]
[New Thread 0xae7bab40 (LWP 26939)]
[Thread 0xae7bab40 (LWP 26939) exited]

Program received signal SIGSEGV, Segmentation fault.
GtkSalFrame::gestureLongPress (gesture=0x8a153c0, frame=0x0) at /build/libreoffice-U8a4ZQ/libreoffice-5.0.1/vcl/unx/gtk3/window/../../gtk/window/gtksalframe.cxx:3552
3552	/build/libreoffice-U8a4ZQ/libreoffice-5.0.1/vcl/unx/gtk3/window/../../gtk/window/gtksalframe.cxx: Arquivo ou diretório não encontrado.
#0  GtkSalFrame::gestureLongPress (gesture=0x8a153c0, frame=0x0) at /build/libreoffice-U8a4ZQ/libreoffice-5.0.1/vcl/unx/gtk3/window/../../gtk/window/gtksalframe.cxx:3552
#1  0xb04f8d72 in ffi_call_SYSV () from /usr/lib/i386-linux-gnu/libffi.so.6
#2  0xb04f89ec in ffi_call () from /usr/lib/i386-linux-gnu/libffi.so.6
#3  0xb2db341d in g_cclosure_marshal_generic_va () from /usr/lib/i386-linux-gnu/libgobject-2.0.so.0
#4  0xb2db2abf in ?? () from /usr/lib/i386-linux-gnu/libgobject-2.0.so.0
#5  0xb2dcc8d9 in g_signal_emit_valist () from /usr/lib/i386-linux-gnu/libgobject-2.0.so.0
#6  0xb2dcd1b5 in g_signal_emit () from /usr/lib/i386-linux-gnu/libgobject-2.0.so.0
#7  0xaefbf7ac in ?? () from /usr/lib/i386-linux-gnu/libgtk-3.so.0
#8  0xaed49dfc in ?? () from /usr/lib/i386-linux-gnu/libgdk-3.so.0
#9  0xb2cc4a21 in ?? () from /lib/i386-linux-gnu/libglib-2.0.so.0
#10 0xb2cc3e03 in g_main_context_dispatch () from /lib/i386-linux-gnu/libglib-2.0.so.0
#11 0xb2cc4219 in ?? () from /lib/i386-linux-gnu/libglib-2.0.so.0
#12 0xb2cc42e6 in g_main_context_iteration () from /lib/i386-linux-gnu/libglib-2.0.so.0
#13 0xaf61b8fa in GtkData::Yield (this=0x80b7e00, bWait=true, bHandleAllCurrentEvents=false) at /build/libreoffice-U8a4ZQ/libreoffice-5.0.1/vcl/unx/gtk3/app/../../gtk/app/gtkdata.cxx:596
#14 0xaf61cbf0 in GtkInstance::Yield (this=0x80b9618, bWait=true, bHandleAllCurrentEvents=false) at /build/libreoffice-U8a4ZQ/libreoffice-5.0.1/vcl/unx/gtk3/app/../../gtk/app/gtkinst.cxx:407
#15 0xb696fdb5 in ImplYield (i_bAllEvents=false, i_bWait=true) at /build/libreoffice-U8a4ZQ/libreoffice-5.0.1/vcl/source/app/svapp.cxx:353
#16 Application::Yield () at /build/libreoffice-U8a4ZQ/libreoffice-5.0.1/vcl/source/app/svapp.cxx:382
#17 0xb696fe55 in Application::Execute () at /build/libreoffice-U8a4ZQ/libreoffice-5.0.1/vcl/source/app/svapp.cxx:336
#18 0xb59876af in desktop::Desktop::Main (this=0xb098) at /build/libreoffice-U8a4ZQ/libreoffice-5.0.1/desktop/source/app/app.cxx:1605
#19 0xb69759bb in