Bug#811670: FTBFS with GCC 6: cannot convert x to y

[Jonas Smedegaard]

Quoting Andreas Steigmiller (2016-07-16 01:37:13)
> Many thanks for maintaining the packaging of Konclude for Debian and 
> for reporting this problem. I fixed the compilation errors and zipped 
> a new source code package of version 0.6.2 that can be downloaded with 
> the following link (it is also available on Konclude's webpage):
> 
> http://www.derivo.de/fileadmin/externe_websites/ext.derivo/KoncludeReleases/v0.6.2-544/Konclude-v0.6.2-544-SourceCode-GCC6Fixes.zip
> 
> Of course, we will also include the fixes in the next release.

That was quick!  Thanks a lot!

Is your develpment done in a public version control system somewhere?  
Such knowledge would be helpful to include in the Debian package, but I 
failed to locate info on that from your website or in the source zip.

 - 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#831446: plaso: log2timeline.py fail cannot import name protobuf_serializer

[Vitry David Gilbert]

Package: plaso
Version: 1.4.0+dfsg-2
Severity: important

Dear Maintainer,

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

   * What led up to the situation?
I try to use plaso
   * What exactly did you do (or not do) that was effective (or ineffective)?
I want to use log2timeline.py

   * What was the outcome of this action?
 #log2timeline.py
Traceback (most recent call last):
  File "/usr/bin/log2timeline.py", line 25, in 
from plaso.frontend import log2timeline
  File "/usr/lib/python2.7/dist-packages/plaso/frontend/log2timeline.py", line
15, in 
from plaso import output  # pylint: disable=unused-import
  File "/usr/lib/python2.7/dist-packages/plaso/output/__init__.py", line 11, in

from plaso.output import pstorage
  File "/usr/lib/python2.7/dist-packages/plaso/output/pstorage.py", line 8, in

from plaso.storage import zip_file
  File "/usr/lib/python2.7/dist-packages/plaso/storage/zip_file.py", line 101,
in 
from plaso.serializer import protobuf_serializer
  File "/usr/lib/python2.7/dist-
packages/plaso/serializer/protobuf_serializer.py", line 6, in 
from dfvfs.serializer import protobuf_serializer as
dfvfs_protobuf_serializer
ImportError: cannot import name protobuf_serializer

   * What outcome did you expect instead?
Working as expected :-)

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



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

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

Versions of packages plaso depends on:
ii  ipython  2.4.1-1
ii  python-binplist  0.1.5-1
ii  python-bittorrent3.4.2-12
ii  python-construct 2.5.2-0.1
ii  python-dateutil  2.4.2-1
ii  python-dfvfs 20160510-1
ii  python-dpkt  1.8.r98-0.1
ii  python-hachoir-core  1.3.3-4
ii  python-hachoir-metadata  1.3.3-2
ii  python-hachoir-parser1.3.4-2
ii  python-libbde20160418-2
ii  python-libesedb  20151213-1
ii  python-libevt20160421-1
ii  python-libevtx   20160421-1
ii  python-libewf20140608-6+b1
ii  python-libfsntfs 20160418-1
ii  python-libfwsi   20160110-1
ii  python-liblnk20160420-1
ii  python-libmsiecf 20160421-1
ii  python-libolecf  20160423-1
ii  python-libqcow   20160123-2
ii  python-libregf   20160424-1
ii  python-libsigscan20160312-1
ii  python-libsmdev  20160320-1
ii  python-libsmraw  20160424-1
ii  python-libvhdi   20160424-1
ii  python-libvmdk   20160119-3
ii  python-libvshadow20160110-2
ii  python-pefile2016.3.28-3
ii  python-protobuf  2.6.1-2
ii  python-psutil4.2.0-1
ii  python-pyparsing 2.1.5+dfsg1-1
ii  python-requests  2.10.0-2
ii  python-six   1.10.0-3
ii  python-tsk   20160325-1
ii  python-tz2015.7+dfsg-0.1
ii  python-xlsxwriter0.7.3-1
ii  python-yaml  3.11-3+b1
ii  python-zmq   15.2.0-1
pn  python:any   

plaso recommends no packages.

plaso suggests no packages.

-- no debconf information

Bug#815506: dh_install: not-installed requires debian/tmp/ prefix

[Drew Parsons]

severity 815506 important
thanks

On Mon, 22 Feb 2016 00:12:50 +0100 Felix Geyer 
wrote:
> 
> For example this d/not-installed file doesn't work:
> usr/bin/passenger-install-nginx-module
> 
> While this works:
> debian/tmp/usr/bin/passenger-install-nginx-module
> 
> This seems unnecessary and is not documented.
> It would be great if dh_install could add the prefix automatically.
> 

It's even worse than that.  debhelper now no longer installs by default
into debian/tmp, but into individual package subdirs, so Felix's
workaround does not work.

The debian/not-installed feature of dh_install does not work as
documented.

Bug#831447: jessie-pu: package firefox-branding-iceweasel/0.4.0

[nord-stream]

Package: release.debian.org
Severity: normal
Tags: jessie
User: release.debian@packages.debian.org
Usertags: pu

With the introduction of firefox-esr in stable Iceweasel is gone.
Because many users want to keep the branding, I've packaged the branding
into a native moz-ext package: firefox-branding-iceweasel (binary:
xul-ext-iceweasel-branding). It is in testing now. It provides an option
to restore Iceweasel branding.

As it is important to have this option also in stable, I'd like the
package in stable.

Description:
Branding for Firefox to apply Iceweasel name and images
This package preserves and restores the look and feel of Iceweasel, the
Debian- rebranded version of Firefox distributed before Firefox came
back to Debian. Most files were just copied from the original Iceweasel
package, including the famous about:iceweasel page of historic value.


firefox-branding-iceweasel (0.4.0) unstable; urgency=low

  * Register a .desktop file and icons.
  * Marked as multiprocess-compatible.

firefox-branding-iceweasel (0.3.2) unstable; urgency=low

  * Initial Debian packaging.  (Closes: #821210)
  * Removed support for older Firefox releases (<45.0).


Correct me if wrong.
Thanks.

nord-stream

Bug#815506: dh_install: not-installed requires debian/tmp/ prefix

[Drew Parsons]

severity 815506 important
thanks

On Mon, 22 Feb 2016 00:12:50 +0100 Felix Geyer 
wrote:
> 
> For example this d/not-installed file doesn't work:
> usr/bin/passenger-install-nginx-module
> 
> While this works:
> debian/tmp/usr/bin/passenger-install-nginx-module
> 
> This seems unnecessary and is not documented.
> It would be great if dh_install could add the prefix automatically.
> 

It's even worse than that.  debhelper now no longer installs by default
into debian/tmp, but into individual package subdirs, so Felix's
workaround does not work.

The debian/not-installed feature of dh_install does not work as
documented, nor as expected.

Bug#783165: debhelper: dh_installdocs --link-doc does not install copyright if doc directory is already present

[Sven Joachim]

On 2015-04-23 10:52 +0200, Ferenc Wágner wrote:

> Package: debhelper
> Version: 9.20120909
> Severity: normal
>
> Hi,
>
> man dh_installdocs says:
>
>   --link-doc=package
>   [...] This has no effect when [...] the documentation directory to
>   be created already exists when dh_installdocs is run. [...]
>
> Based on this I expected dh_installdocs to install (eg.) debian/copyright
> into an already existing documentation directory.  This does not seem to
> happen, I had to add debian/copyright to debian/package.docs.  Is the bug
> in debhelper or in my interpretation of the manual?

When code and documentation disagree, usually both are wrong. ;-)
Indeed, contrary to the documentation dh_installdocs does not install
debian/copyright and some other standard files like debian/TODO or
debian/README, if the --link-doc option is given.  This has been the
behavior since the --link-doc option was added in debhelper 7.4.2.

I'm not sure what to do here.  Not installing these files does not seem
quite correct, but on the other hand it is almost certainly a packaging
error to use the --link-doc option if the documentation directory
already exists.  This can happen if you run dh_installchangelogs before
dh_installdocs, for instance.

At least in the current situation lintian will detect such mistakes and
trigger the no-copyright-file error (which does not seem to happen for
any packages in the archive), so the packager can correct them.

Cheers,
   Sven

Bug#831181: patch updated for gcc-6

[Gianfranco Costamagna]

Hi, attached the patch updated for gcc-6 (addition of the incomplete upstream 
one)
and the complete debdiff for a building oding against gcc-6

basically the new issues (excluding the already upstream-patched 
"odinseq/odinpulse.cpp"

were:
in odinseq/seqgradspiral.cpp
bad compare between double and float

-  max_grad_diff=STD_max(double(max_grad_diff),fabs(tds.Gx-last_Gx));
-  max_grad_diff=STD_max(double(max_grad_diff),fabs(tds.Gy-last_Gy));
+  max_grad_diff=STD_max(max_grad_diff,fabs(tds.Gx-last_Gx));
+  max_grad_diff=STD_max(max_grad_diff,fabs(tds.Gy-last_Gy));


- max_grad_magn=STD_max(double(max_grad_magn),fabs(tds.Gx));
-max_grad_magn=STD_max(double(max_grad_magn),fabs(tds.Gy));
+max_grad_magn=STD_max(max_grad_magn,fabs(tds.Gx));
+max_grad_magn=STD_max(max_grad_magn,fabs(tds.Gy));



and in cmdline-utils/swab.cpp

ifstream return check
-  if(in_data == NULL) {
+  if(in_data.fail()) {


-  if(out_data == NULL) {
+  if(out_data.fail()) {


-  if(out_data == NULL) {
+  if(out_data.fail()) {


they seem to be correct to me, but I'm ccing upstream to be sure :)

BTW, in deferred/5.
thanks,

G.


debdiff-v2
Description: Binary data
Description: Fix some std::max(double,float) call mismatch and some "ifstream not comparable with NULL"

Author: Gianfranco Costamagna 

--- odin-2.0.2.orig/odinseq/seqgradspiral.cpp
+++ odin-2.0.2/odinseq/seqgradspiral.cpp
@@ -27,12 +27,12 @@ float SeqGradSpiral::readout_npts() cons
 const kspace_coord& tds=traj_cache->calculate(s);
 if(i) {
   deltaKtangential=STD_max(double(deltaKtangential),norm(tds.kx-last_kx,tds.ky-last_ky));
-  max_grad_diff=STD_max(double(max_grad_diff),fabs(tds.Gx-last_Gx));
-  max_grad_diff=STD_max(double(max_grad_diff),fabs(tds.Gy-last_Gy));
+  max_grad_diff=STD_max(max_grad_diff,fabs(tds.Gx-last_Gx));
+  max_grad_diff=STD_max(max_grad_diff,fabs(tds.Gy-last_Gy));
 }
 
-max_grad_magn=STD_max(double(max_grad_magn),fabs(tds.Gx));
-max_grad_magn=STD_max(double(max_grad_magn),fabs(tds.Gy));
+max_grad_magn=STD_max(max_grad_magn,fabs(tds.Gx));
+max_grad_magn=STD_max(max_grad_magn,fabs(tds.Gy));
 
 last_kx=tds.kx;
 last_ky=tds.ky;
--- odin-2.0.2.orig/cmdline-utils/swab.cpp
+++ odin-2.0.2/cmdline-utils/swab.cpp
@@ -28,7 +28,7 @@ int main(int argc, char* argv[]) {
   }
 
   std::ifstream in_data(argv[2],std::ios::in|std::ios::binary);
-  if(in_data == NULL) {
+  if(in_data.fail()) {
 std::cerr << "swab: ERROR: can't open file " << argv[2] << std::endl;
 return -1;
   }
@@ -56,14 +56,14 @@ int main(int argc, char* argv[]) {
   for(k=0;k

Bug#830454: labplot: FTBFS: CartesianCoordinateSystem.cpp:560:27: error: 'isnan' was not declared in this scope

[Stefan Gerlach]

Hi,

please replace "isnan" with "std::isnan" and use  instead of 
. This is already fixed in the upcoming release 2.3.0 coming 
next week.


Stefan

On 07/08/2016 09:23 AM, Lucas Nussbaum wrote:

Source: labplot
Version: 2.2.0-1
Severity: serious
Tags: stretch sid
User: debian...@lists.debian.org
Usertags: qa-ftbfs-20160707 qa-ftbfs
Justification: FTBFS on amd64

Hi,

During a rebuild of all packages in sid, your package failed to build on
amd64.

Relevant part (hopefully):



^
[ 67%] Building CXX object 
src/CMakeFiles/labplot2.dir/backend/worksheet/plots/cartesian/CartesianCoordinateSystem.cpp.o
cd /«PKGBUILDDIR»/obj-x86_64-linux-gnu/src && /usr/bin/c++   -DGSL_VERSION=GSL_VERSION 
-DHAVE_GSL -DHAVE_NETCDF -DKCOREADDONS_LIB -DKGUIADDONS_LIB -DLVERSION=\"2.2.0\" 
-DQT_CORE_LIB -DQT_DBUS_LIB -DQT_DISABLE_DEPRECATED_BEFORE=0 -DQT_GUI_LIB -DQT_NETWORK_LIB 
-DQT_NO_DEBUG -DQT_PRINTSUPPORT_LIB -DQT_SVG_LIB -DQT_WIDGETS_LIB -DQT_XML_LIB -D_GNU_SOURCE 
-D_LARGEFILE64_SOURCE -I/«PKGBUILDDIR»/obj-x86_64-linux-gnu/src -I/«PKGBUILDDIR»/src 
-I/«PKGBUILDDIR» -I/«PKGBUILDDIR»/obj-x86_64-linux-gnu -I/«PKGBUILDDIR»/src/. -I/usr/include/gsl 
-I/.. -isystem /usr/include/KF5/KDELibs4Support -isystem /usr/include/KF5/KDELibs4Support/KDE 
-isystem /usr/include/KF5 -isystem /usr/include/x86_64-linux-gnu/qt5 -isystem 
/usr/include/x86_64-linux-gnu/qt5/QtWidgets -isystem /usr/include/x86_64-linux-gnu/qt5/QtGui 
-isystem /usr/include/x86_64-linux-gnu/qt5/QtCore -isystem 
/usr/lib/x86_64-linux-gnu/qt5/mkspecs/linux-g++-64 -isystem 
/usr/include/x86_64-linux-gnu/qt5/QtDBus -isystem 
/usr/include/x86_64-linux-gnu/qt5/QtPrintSupport -isystem /usr/include/KF5/KCoreAddons -isystem 
/usr/include/KF5/KCrash -isystem /usr/include/KF5/KWidgetsAddons -isystem 
/usr/include/KF5/KConfigCore -isystem /usr/include/KF5/KConfigWidgets -isystem 
/usr/include/KF5/KCodecs -isystem /usr/include/KF5/KConfigGui -isystem 
/usr/include/x86_64-linux-gnu/qt5/QtXml -isystem /usr/include/KF5/KAuth -isystem 
/usr/include/KF5/KIOCore -isystem /usr/include/KF5/KService -isystem 
/usr/include/KF5/KIOFileWidgets -isystem /usr/include/KF5/KIOWidgets -isystem 
/usr/include/KF5/KJobWidgets -isystem /usr/include/x86_64-linux-gnu/qt5/QtNetwork -isystem 
/usr/include/KF5/KCompletion -isystem /usr/include/KF5/KBookmarks -isystem 
/usr/include/KF5/KItemViews -isystem /usr/include/KF5/KXmlGui -isystem /usr/include/KF5/Solid 
-isystem /usr/include/KF5/KI18n -isystem /usr/include/KF5/KNotifications -isystem 
/usr/include/KF5/KIconThemes -isystem /usr/include/KF5/KWindowSystem -isystem 
/usr/include/KF5/KGuiAddons -isystem /usr/include/KF5/KUnitConversion -isystem 
/usr/include/KF5/KTextWidgets -isystem /usr/include/KF5/SonnetUi -isystem /usr/include/KF5/KParts 
-isystem /usr/include/KF5/KArchive -isystem /usr/include/x86_64-linux-gnu/qt5/QtSvg  -g -O2 
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2  
-std=c++0x -fno-exceptions -Wall -Wextra -Wcast-align -Wchar-subscripts -Wformat-security 
-Wno-long-long -Wpointer-arith -Wundef -Wnon-virtual-dtor -Woverloaded-virtual 
-Werror=return-type -Wall -Wextra -Wundef -Wpointer-arith -Wcast-align -Wunreachable-code 
-fno-omit-frame-pointer -fstack-protector -fno-exceptions   -fvisibility=default -fPIC -o 
CMakeFiles/labplot2.dir/backend/worksheet/plots/cartesian/CartesianCoordinateSystem.cpp.o -c 
/«PKGBUILDDIR»/src/backend/worksheet/plots/cartesian/CartesianCoordinateSystem.cpp
/«PKGBUILDDIR»/src/backend/worksheet/plots/cartesian/CartesianCoordinateSystem.cpp: In member 
function 'virtual QList CartesianCoordinateSystem::mapLogicalToScene(const 
QList&, const MappingFlags&) const':
/«PKGBUILDDIR»/src/backend/worksheet/plots/cartesian/CartesianCoordinateSystem.cpp:560:27:
 error: 'isnan' was not declared in this scope
  if (!isnan(xGapBefore)) {
   ^
/«PKGBUILDDIR»/src/backend/worksheet/plots/cartesian/CartesianCoordinateSystem.cpp:560:27:
 note: suggested alternative:
In file included from 
/«PKGBUILDDIR»/src/backend/worksheet/plots/cartesian/CartesianCoordinateSystem.cpp:32:0:
/usr/include/c++/5/cmath:641:5: note:   'std::isnan'
 isnan(_Tp __x)
 ^
/«PKGBUILDDIR»/src/backend/worksheet/plots/cartesian/CartesianCoordinateSystem.cpp:575:26:
 error: 'isnan' was not declared in this scope
  if (!isnan(xGapAfter)) {
  ^
/«PKGBUILDDIR»/src/ 
backend/worksheet/plots/cartesian/CartesianCoordinateSystem.cpp:575:26: note: 
suggested alternative:
In file included from 
/«PKGBUILDDIR»/src/backend/worksheet/plots/cartesian/CartesianCoordinateSystem.cpp:32:0:
/usr/include/c++/5/cmath:641:5: note:   'std::isnan'
 isnan(_Tp __x)
 ^
/«PKGBUILDDIR»/src/backend/worksheet/plots/cartesian/CartesianCoordinateSystem.cpp:590:27:
 error: 'isnan' was not declared in this scope
  if (!isnan(yGapBefore)) {
   ^
/«PKGBUILDDIR»/src/backend/worksheet/plots

Bug#831446: plaso: log2timeline.py was python-dfvfs

[Vitry David Gilbert]

Bonjour,

copying this file from ubuntu 16.04 seems to make it work.

Ubunto python-dfvfs 20160203-2

╭─ ✘  lours@lours
╰─☛ ll
/usr/lib/python2.7/dist-packages/dfvfs/serializer/protobuf_serializer.py*
-rw-r--r-- 1 root root 4,6K févr.  4 00:47
/usr/lib/python2.7/dist-packages/dfvfs/serializer/protobuf_serializer.py
-rw-r--r-- 1 root root 4,7K juil. 16 11:46
/usr/lib/python2.7/dist-packages/dfvfs/serializer/protobuf_serializer.pyc
╭─ lours@lours
╰─☛ ll /usr/lib/python2.7/dist-packages/dfvfs/proto
total 28K
-rw-r--r-- 1 root root   24 févr.  4 00:47 __init__.py
-rw-r--r-- 1 root root  143 juil. 16 11:46 __init__.pyc
-rw-r--r-- 1 root root  11K févr.  4 00:47 transmission_pb2.py
-rw-r--r-- 1 root root 6,3K juil. 16 11:46 transmission_pb2.pyc


The problem is not with plaso but with python-dfvfs

Thanks

Bug#815506: dh_install: not-installed requires debian/tmp/ prefix

[Niels Thykier]

On Sat, 16 Jul 2016 15:34:28 +0800 Drew Parsons  wrote:
> severity 815506 important
> thanks
> 
> On Mon, 22 Feb 2016 00:12:50 +0100 Felix Geyer 
> wrote:
> >
> > For example this d/not-installed file doesn't work:
> > usr/bin/passenger-install-nginx-module
> >
> > While this works:
> > debian/tmp/usr/bin/passenger-install-nginx-module
> >
> > This seems unnecessary and is not documented.
> > It would be great if dh_install could add the prefix automatically.
> >
> 
> It's even worse than that. debhelper now no longer installs by default
> into debian/tmp, but into individual package subdirs, so Felix's
> workaround does not work.
> 

debhelper by default installs into debian/ for *single* binary
package builds and to debian/tmp for *multi* binary builds.  This
behaviour has been unchanged for years.

If you see a different *default* behaviour, please file that as a
separate bug.

Thanks,
~Niels

Bug#831077: Set pending

[Ole Streicher]

Control: tags -1 pending

This is fixed in git:

https://anonscm.debian.org/cgit/debian-astro/packages/casacore.git/commit/?id=2e9bb9a2939d8c55b2b89a96dc96684c69c6b001

Bug#831448: gitlab: fails to install database

[cloos]

Package: gitlab
Version: 8.9.0+dfsg-4
Severity: grave
Justification: renders package unusable

installing gitlab via apt with LANG=en_US.UTF-8 results in this:

Create database if not present
psql: FATAL:  database "gitlab_production" does not exist
createdb: database creation failed: ERROR:  encoding "UTF8" does not match 
locale "en_US"
DETAIL:  The chosen LC_CTYPE setting requires encoding "LATIN1".
dpkg: error processing package gitlab (--configure):
 subprocess installed post-installation script returned error exit status 1
Errors were encountered while processing:
 gitlab
E: Sub-process /usr/bin/dpkg returned an error code (1)
  

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

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

Bug#825833: libkms

[Víctor M . Jáquez L .]

On 07/15/16 at 10:33pm, Julien Cristau wrote:
> On Wed, Jul  6, 2016 at 18:46:32 +0200, ydir...@free.fr wrote:
> 
> > In fact, it looks like libkms was built in the past, but is explicitely
> > disabled now.  There is probably a reason for this, but there is no more
> > information than that in the changelog, and no README.Debian.
> > 
> > Could we please have more insight about why this decision was made ?
> > 
> libkms wasn't used/useful then, I'd need some convincing to re-enable
> it.

Perhaps it won't be useful in desktop systems or servers, but, as far as I
see, it is useful in embedded, if you want to draw without any display
server.

But I agree, I only have one modest example: kmssink, a simple GStreamer video
sink, targeted precisely to embedded systems.

Recently I ended up installing Fedora because it ships libkms.

Thanks

vmjl


signature.asc
Description: PGP signature

Bug#815506: dh_install: not-installed requires debian/tmp/ prefix

[Drew Parsons]

On Sat, 2016-07-16 at 07:52 +, Niels Thykier wrote:
> 
> debhelper by default installs into debian/ for *single*
> binary
> package builds and to debian/tmp for *multi* binary builds.  This
> behaviour has been unchanged for years.
> 
> If you see a different *default* behaviour, please file that as a
> separate bug.

Niels, I think you missed the point.  This bug is not about where
dh_install installs files, it's about the debian/not-installed file and
the failure of dh_install to not install the files listed within it.

Drew

Bug#790766: Fixed long time ago, libpng-dev is now a real package

[Gianfranco Costamagna]

Version: 1.6.20-3

thanks,

G.

Bug#831449: lintian on Sid amd64 reports volatile false spelling errors in binaries

[Thomas Schmitt]

Subject: lintian on Sid amd64 reports volatile false spelling errors in binaries
Package: lintian
Version: 2.5.45
Severity: normal
Tags: upstream

Hi,

I encountered the problem with lintian checks while and after packaging
libisoburn 1.4.4-1.

After apt-get dist-upgrade on my Sid VM on juli 4 2016 and debuild from
libisoburn-1.4.4.tar.gz i got from lintian a warning about a typo "lengH"
in the resulting shared library file. This is a false positive.
So i overrode it.

But after upload by my sponsor i see on
  
https://lintian.debian.org/full/pkg-libburnia-de...@lists.alioth.debian.org.html#libisoburn
the complaint
  unused-override
spelling-error-in-binary *libisoburn.so* lengH length


Reason for the "lengH" complaint on my Sid is probably the output of
strings which reflects a strange habit of gcc to chop texts into pieces
which are separated by non-printable bytes.
Source line:

  xorriso/iso_manip.c: "Suitable are strings of length 4 or length 
1");

yields with "strings" from libisoburn.so

  SuitableL
  th 1I
  are strA
  ings of E1
  length 41
  or lengH

Binary snippet from libisoburn.so:

  00094e50 :61  62  6c  65  4c  8d  05  71  5b  01  00  41  c7  84  24  bc
 a   b   l   e   L   q   [   A   $

  00094e60 :b1  02  00  74  68  20  31  49  89  84  24  94  b1  02  00  48
 t   h   1   I   $   H

  00094e70 :b8  20  61  72  65  20  73  74  72  41  c6  84  24  c0  b1  02
 a   r   e   s   t   r   A   $

  00094e80 :00  00  49  89  84  24  9c  b1  02  00  48  b8  69  6e  67  73
 I   $   H   i   n   g   s

  00094e90 :20  6f  66  20  45  31  c9  49  89  84  24  a4  b1  02  00  48
 o   f   E   1   I   $   H

  00094ea0 :b8  6c  65  6e  67  74  68  20  34  31  c9  49  89  84  24  ac
 l   e   n   g   t   h   4   1   I   $

  00094eb0 :b1  02  00  48  b8  20  6f  72  20  6c  65  6e  67  48  89  da
 H   o   r   l   e   n   g   H

A similar binary representation can be found in libisoburn.so when i
build it on my Debian 8 workstation. So this problem is not just about
newest gcc versions.


Another similar override in debian/libisoburn1.lintian-overrides is not
reported as unused by lintian.debian.org:

  # Here: "ment off" from "Displacement offset leads outside 32 bit range"
  libisoburn1 binary: spelling-error-in-binary *libisoburn.so* ment meant

So i assume that lintian.debian.org still spellchecks binaries and
still finds false positives in them.


Have a nice day :)

Thomas


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

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

Versions of packages lintian depends on:
ii  binutils  2.26.1-1
ii  bzip2 1.0.6-8
ii  diffstat  1.61-1
ii  file  1:5.28-2
ii  gettext   0.19.8.1-1
ii  hardening-includes2.8+nmu2
ii  intltool-debian   0.35.0+20060710.4
ii  libapt-pkg-perl   0.1.29+b5
ii  libarchive-zip-perl   1.57-1
ii  libclass-accessor-perl0.34-1
ii  libclone-perl 0.38-1+b1
ii  libdata-alias-perl1.20-1+b1
ii  libdpkg-perl  1.18.7
ii  libemail-valid-perl   1.200-1
ii  libfile-basedir-perl  0.07-1
ii  libipc-run-perl   0.94-1
ii  liblist-moreutils-perl0.413-1+b1
ii  libparse-debianchangelog-perl 1.2.0-9
ii  libperl5.22 [libdigest-sha-perl]  5.22.2-1
ii  libtext-levenshtein-perl  0.13-1
ii  libtimedate-perl  2.3000-2
ii  liburi-perl   1.71-1
ii  libyaml-libyaml-perl  0.41-6+b1
ii  man-db2.7.5-1
ii  patchutils0.3.4-1
ii  perl  5.22.2-1
ii  t1utils   1.39-2
ii  xz-utils  5.1.1alpha+20120614-2.1

Versions of packages lintian recommends:
ii  dpkg 1.18.7
ii  libperlio-gzip-perl  0.19-1+b1
ii  perl 5.22.2-1
ii  perl-modules-5.22 [libautodie-perl]  5.22.2-1

Versions of packages lintian suggests:
pn  binutils-multiarch 
ii  dpkg-dev   1.18.7
ii  libhtml-parser-perl3.72-1
ii  libtext-template-perl  1.46-1

-- Configuration Files:
/etc/lintianrc changed:
color = never


-- no debconf information

Bug#831414: systemd: learns IPv6 prefix from its own RAs and configures IP address on wrong interface

[Martin Pitt]

Control: severity -1 important

Hello Marc,

Marc Haber [2016-07-15 21:00 +0200]:
> I am filing this as severity minor because this bug is in a version
> that is not officially in Debian.

Bumping as I dropped the reverted patch in git, i. e. the next upload
will have the original upstream behaviour again.

> While following up Martin's requests for #815793 and #815884, I have
> found new misbehsvior regarding IPv6.

Thanks for the detailled description. To ensure that we have all the
things to reproduce it, can you please attach the corresponding
.network and .netdev files for eth0 and br0? Are you only using
networkd on this machine, or ifupdown/NM as well?

Thanks,

Martin

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

Bug#831450: libp4est-dev: arch-dependent file in "Multi-Arch: same" package

[Jakub Wilk]

Package: libp4est-dev
Version: 1.1-1
Severity: important
User: multiarch-de...@lists.alioth.debian.org
Usertags: multiarch

libp4est-dev is marked as "Multi-Arch: same", but the following file is 
architecture-dependent:


/usr/include/sc_config.h

An example diff between i386 and s390x is attached.

--
Jakub Wilk
diff -ur libp4est-dev_1.1-1_i386/usr/include/sc_config.h 
libp4est-dev_1.1-1_s390x/usr/include/sc_config.h
--- libp4est-dev_1.1-1_i386/usr/include/sc_config.h 2016-07-14 
17:52:19.0 +0200
+++ libp4est-dev_1.1-1_s390x/usr/include/sc_config.h2016-07-14 
17:52:19.0 +0200
@@ -231,7 +231,9 @@
 #endif
 
 /* Define to 1 on a bigendian machine */
-/* #undef IS_BIGENDIAN */
+#ifndef SC_IS_BIGENDIAN
+#define SC_IS_BIGENDIAN 1
+#endif
 
 /* Linker flags */
 #ifndef SC_LDFLAGS
@@ -309,7 +311,7 @@
 
 /* The size of `long', as computed by sizeof. */
 #ifndef SC_SIZEOF_LONG
-#define SC_SIZEOF_LONG 4
+#define SC_SIZEOF_LONG 8
 #endif
 
 /* The size of `long long', as computed by sizeof. */
@@ -319,7 +321,7 @@
 
 /* The size of `unsigned long', as computed by sizeof. */
 #ifndef SC_SIZEOF_UNSIGNED_LONG
-#define SC_SIZEOF_UNSIGNED_LONG 4
+#define SC_SIZEOF_UNSIGNED_LONG 8
 #endif
 
 /* The size of `unsigned long long', as computed by sizeof. */

Bug#824944: closed by Julian Wollrath (Bug#824944: fixed in lua-discount 2.1.8-1)

[Julian Wollrath]

Hi,

the problem seems to lie with discount (bug #826197). The architectures
you mention have discount 2.1.8, while the others have a newer version.
It seems like the output of discount changed between these versions.


Cheers,
Julian

Bug#825749: xul-ext-foxyproxy-standard: foxyproxy cannot be installed if icedove 45 is present

[David Prévot]

Control: unmerge -1 with 827170
Control: reopen -1
Control: reassign -1 icedove 1:45.1.0-1

Hi Christoph and all,

On Sun, May 29, 2016 at 09:50:40AM -0400, Robbie Harwood wrote:
> Package: xul-ext-foxyproxy-standard
> Version: 4.5.6-debian-1
> Severity: important
> 
> Dear Maintainer,
> 
> It is currently not possible to have both xul-ext-foxyproxy-standard and
> icedove 45.1.0-1 (i.e., the icedove from sid) present on the same system:
> 
> ```
> $ aptitude -s install -t unstable icedove
[…]
> The following packages have unmet dependencies:
>  icedove : Breaks: xul-ext-foxyproxy-standard (> 3.4-1) but 4.5.6-debian-1 is 
> installed.
> The following actions will resolve these dependencies:
> 
> Remove the following packages:
> 1) xul-ext-foxyproxy-standard

Since 4.5.6-debian-2, xul-ext-foxyproxy-standard is not available (thus
does not show up) in Icedove/Thunderbird anymore (since #827170 has been
fixed), so please, do change the
Breaks: […] xul-ext-foxyproxy-standard (>> 3.4-1)
into
Breaks: xul-ext-foxyproxy-standard (<< 4.5.6-debian-2~)
If a fix for #820026 is also needed for stable, we can provide a version
3.4-1.1+deb8u1 including a similar patch to 827170 (and of course, the
Break will need to be changed against “<< 3.4-1.1+deb8u1~”).

Regards

David


signature.asc
Description: PGP signature

Bug#815506: [debhelper-devel] Bug#815506: dh_install: not-installed requires debian/tmp/ prefix

[Niels Thykier]

Drew Parsons:
> On Sat, 2016-07-16 at 07:52 +, Niels Thykier wrote:
>>  
>> debhelper by default installs into debian/ for *single*
>> binary
>> package builds and to debian/tmp for *multi* binary builds.  This
>> behaviour has been unchanged for years.
>>
>> If you see a different *default* behaviour, please file that as a
>> separate bug.
> 
> Niels, I think you missed the point.  This bug is not about where
> dh_install installs files, it's about the debian/not-installed file and
> the failure of dh_install to not install the files listed within it.
> 
> Drew
> 
> [...]
> 

My reply was to understand/refute your remark:

"""
It's even worse than that. debhelper now no longer installs by default
into debian/tmp, but into individual package subdirs, so Felix's
workaround does not work.
"""

And I do believe that it warrants a separate bug if what you say is true
(modulo my remark).

Thanks,
~Niels

Bug#830978: Browserified javascript and DFSG 2

[Sam Hartman]

> "Ian" == Ian Jackson  writes:

Ian> I would like to comment briefly on the general idea about the
Ian> TC offering advice and making statements of opinion.


Ian> If someone in authority in the project, such as a maintainer of
Ian> the ftpmasters or the release team, is doing something which
Ian> the TC thinks is wrong, then (if the question is important) I
Ian> think it would be entirely appropriate for the TC to issue a
Ian> statement of opinion, disagreeing with the other authority.

Ian> Conversely, if a contributor has been criticised, they may
Ian> welcome a message of support from the TC.  That may help lay to
Ian> rest an unfounded criticism and save the contributor the energy
Ian> required to wonder whether they're really right, rebut any
Ian> public criticisms, and so on.


Ian> And finally if a question needs authoritative input but the
Ian> relevant authority in Debian has not made a clear decision, TC
Ian> involvement might help get the matter properly resolved.

Agreed on both the first two points.
Also, from the discussion on IRC, it seems fairly clear that most TC
members agree that we can give advice if we wish.

I agree in general on the third point about  authority and clear
decisions, with a lot of emphasis on the "might."
Sometimes that's good, sometimes it is not.


Ian> In this case I think that it would be worth TC members
Ian> considering, for themselves, briefly, and without too much
Ian> back-and-forth enquiry, what their initial assessments of the
Ian> merits of the situation are.

I'm fairly sure that's happened for a majority of the TC members.

Ian> If TC members feel that the submitter of #817092 (Luke, who is
Ian> complaining that the aggregated file is not source, along with
Ian> Ben, Jonas etc.) are right, they could ask the release team and
Ian> the ftpmasters (informally, perhaps) whether the release team
Ian> would welcome a supportive TC intervention.

The release team has indicated that this call is the FTP team's.
The members of the TC and members of the FTP team have talked informally.

Ian> That would allow the TC to help settle this long-running
Ian> question (which keeps coming up on -devel and is frankly quite
Ian> annoying).

So, here's why I personally don't think that would be helpful.
I want to emphasize this is pure Sam, not even Sam making a best guess
at how things might fall out if other people got involved, not me giving
my read on anything else.

As best I can tell, the ftp team has a clear position; it is reflected
in their new rejection FAQ, and in their decisions.

(As an aside, there was a keynote at Debconf talking about how it would
(in the speaker's opinion) be better to get more transparency in that.  Based 
on what I heard at
the keynote I think getting the TC involved in that would slow it
down/make it more political)

I haven't seen a lot of doubt expressed from the ftp team about what its
policies are.  You see careful language from people not wanting to step
on each others' toes, but they are all saying the same thing.

Having an outsider to the process like the TC say something isn't going
to help in a case where there is already fairly good internal consensus
and not a lot of doubt.

I think the reason this comes up on -devel is that there may not be a
consensus project-wide, and if there is a rough consensus project-wide
on  this issue, it's really on the rough side.

In general, I think that those who spend a lot of time in Debian are
more radically pro-free-software than the developers as a whole.  That
is, folks on the TC, the DPL, the ftp team, etc are probably not
representative of the developers overall.  I think we've seen this when
we've taken things like getting rid of non-free or binary firmware to a
GR.  The project is clearly pro-free-software, but also fairly clearly
pro-getting-stuff-done-for-real-users even when that gets messy with
regard to free software.

Part of having good governance is to have those discussions on devel.
You have an honest disagreement between parts of your community--between
the people deciding and the people affected by the decisions.
That's not inherently a sign that the people deciding are wrong: Debian
culturally chooses to give significant power to those doing the work.

The TC isn't going to be able to add anything here.  We have similar
biases to the ftp team.  We deal with licenses less often, so they are
probably even more aware of the issues than we are.
Having two teams say the same thing isn't going to shut up anyone on
devel frustrated that we're insisting they do significantly more work.

We also need to continue to pay attention to those discussions and bugs
filed like this.  If we
find that the overall project unhappiness with the balance we strike is
growing, we need to do something.

That said, my personal opinion about this issue is that it is a
datapoint, not a tren

Bug#831396: procps: [ps] fails on kfreebsd

[Carsten Leonhardt]

Hi,

> Could it be they have "improved" the procfs in some way from 9.x to 10.x?
> Can you strace the ps command? I'm looking for opens under /proc that fail.

this is the end of a ktrace:

  3857 ps   CALL  open(0x80146de1b,0,0)
  3857 ps   NAMI  "/proc/sys/vm/min_free_kbytes"
  3857 ps   RET   open -1 errno 2 No such file or directory
  3857 ps   CALL  write(0x2,0x80146e350,0xb0)
  3857 ps   GIO   fd 2 wrote 176 bytes
   "Error: /proc must be mounted
  To mount /proc at boot you need an /etc/fstab line like:
  proc   /proc   procdefaults
  In the meantime, run "mount proc /proc -t proc"
   "
  3857 ps   RET   write 176/0xb0
  3857 ps   CALL  exit(0x66)

That file is referenced in proc/sysinfo.c and used in function
meminfo(). I've re-checked: all commands that use meminfo() fail.

There is no directory /proc/sys/vm in either the FreeBSD-kernel
10.1-0-amd64 (jessie-kfreebsd) nor in 10.3-0-amd64 (sid).

The reference to /proc/sys/vm/min_free_kbytes apparently was introduced
with your commit f65d2815913f5d8ff4156384dceb160edd6da812 titled
"Imported Upstream version 3.3.10".

Carsten

Bug#831452: pcp-export-pcp2graphite: fails to upgrade from 'testing' - trying to overwrite /usr/bin/pcp2graphite

[Andreas Beckmann]

Package: pcp-export-pcp2graphite
Version: 3.11.3
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

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

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

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

  Selecting previously unselected package pcp-export-pcp2graphite.
  Preparing to unpack .../pcp-export-pcp2graphite_3.11.3_amd64.deb ...
  Unpacking pcp-export-pcp2graphite (3.11.3) ...
  dpkg: error processing archive 
/var/cache/apt/archives/pcp-export-pcp2graphite_3.11.3_amd64.deb (--unpack):
   trying to overwrite '/usr/bin/pcp2graphite', which is also in package pcp 
3.10.8+b1
  Processing triggers for libc-bin (2.23-1) ...
  Errors were encountered while processing:
   /var/cache/apt/archives/pcp-export-pcp2graphite_3.11.3_amd64.deb


cheers,

Andreas


pcp=3.10.8+b1_pcp-export-pcp2graphite=3.11.3.log.gz
Description: application/gzip

Bug#831453: meld crashed when invoked from command line after recent upgrade (suspect GTK)

[Chris Tillman]

Package: meld
Version: 3.16.1-1
Severity: normal

Dear Maintainer,

Hi,

I invoked meld with two small documents.

$ meld 6100.1.chk 6100.2.chk

The result was

No protocol specified
Unable to init server: Could not connect: Connection refused
No protocol specified
Unable to init server: Could not connect: Connection refused

(meld:14422): Gtk-CRITICAL **: gtk_icon_theme_get_for_screen: assertion
'GDK_IS_SCREEN (screen)' failed
Traceback (most recent call last):
  File "/usr/bin/meld", line 260, in 
setup_resources()
  File "/usr/bin/meld", line 193, in setup_resources
Gtk.IconTheme.get_default().append_search_path(icon_dir)
AttributeError: 'NoneType' object has no attribute 'append_search_path'

I noticed bug 830952, so checked my GTK version; it was 3.20.6-2. Perhaps "too
new"?

When I opened meld through the menu instead, I was able to use it to view the
diff.

Let me just say that I think meld provides the most attractive diff result
display I have ever seen, it's a joy to use just because of that.




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

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

Versions of packages meld depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.24.0-2
ii  gir1.2-gtksource-3.0 3.20.4-1
ii  libcanberra-gtk3-module  0.30-2.1
ii  libgtk-3-0   3.20.6-2
ii  libgtksourceview-3.0-1   3.20.4-1
ii  patch2.7.5-1
ii  python-gi3.18.2-2+b1
ii  python-gi-cairo  3.18.2-2+b1
pn  python:any   

Versions of packages meld recommends:
ii  yelp  3.20.1-1

meld suggests no packages.

-- no debconf information

Bug#830740: mrpt: FTBFS on hppa: parse_NMEA_RMC assertion failure

[JOSE LUIS BLANCO CLARACO]

Thanks Aaron! I'm really busy these days with other open fronts in
MRPT, but will try to eventually fix this.

Best,


On Mon, Jul 11, 2016 at 12:24 AM, Aaron M. Ucko  wrote:
> Source: mrpt
> Version: 1:1.4.0-3
> Severity: important
> Justification: fails to build from source
>
> Thanks for looking into the build failures I previously reported.
> mrpt builds are in much better shape now, but the hppa build still fails:
>
>   [ RUN  ] CGPSInterface.parse_NMEA_RMC
>   unknown file: Failure
>   C++ exception with description "
>
>=== MRPT EXCEPTION =
>   void mrpt::system::timestampToParts(mrpt::system::TTimeStamp, 
> mrpt::system::TTimeParts&, bool), line 120:
>   Assert condition failed: sec_frac<1.0
>   " thrown in the test body.
>   [  FAILED  ] CGPSInterface.parse_NMEA_RMC (8 ms)
>
> Could you please take a look?
>
> Thanks!



-- 
___

Jose Luis Blanco-Claraco
CITE-IV 1.05
Universidad de Almería, Departamento de Ingeniería
04120 Almería (Spain)
http://www.ual.es/~jlblanco/
___

Bug#831396: procps: [ps] fails on kfreebsd

[Craig Small]

On Sat, Jul 16, 2016 at 7:20 PM Carsten Leonhardt  wrote:

>   3857 ps   NAMI  "/proc/sys/vm/min_free_kbytes"
>
  3857 ps   RET   open -1 errno 2 No such file or directory
>

Ah ha, I think I know the problem. And it is related to the kernel version.
asdfasdf has this:
$ more /proc/sys/kernel/osrelease
2.6.16
I bet you have something else, something bigger than 2.6.27

The relevant procps code:
if (linux_version_code < LINUX_VERSION(2, 6, 27))
  kb_main_available = kb_main_free;
else {
  FILE_TO_BUF(VM_MIN_FREE_FILE, vm_min_free_fd);

So, the fix will be to have some #if around that extra check and just use
the old school make available the same as free.

 - Craig

Bug#815506: [debhelper-devel] Bug#815506: dh_install: not-installed requires debian/tmp/ prefix

[Drew Parsons]

On Sat, 2016-07-16 at 09:09 +, Niels Thykier wrote:
> 
> 
> My reply was to understand/refute your remark:
> 
> """
> It's even worse than that. debhelper now no longer installs by
> default
> into debian/tmp, but into individual package subdirs, so Felix's
> workaround does not work.
> """


Take the transition from mirrormagic 2.0.2.0deb1-12 to -13 as an
example.  I placed .gitignore in the subdir scores to keep the empty
upstream directory in the git repo.  scores was installed into
/var/games/mirrormagic using debian/mirrormagic.install

Obviously I don't want .gitignore installed in the mirrormagic deb
package.  Trying to prevent its installation using debian/not-installed 
is the bug here.  

>From the wording of the man page, "List the files that are deliberately
not installed in any binary package.", I would expect, or hope, that
just .gitignore alone in not-installed to work.

The manpage also says "Paths listed in this file are ignored". Since
the entry in mirrormagic.install was
"scores var/games/mirrormagic", it would make sense
that "var/games/mirrormagic/scores/.gitignore" in not-installed should
work, even if .gitignore alone does not.

That's the bug that Felix reported, but he found a workaround by
prefixing debian/tmp/...

But debian/tmp is not always used. An alternative workaround would be
prefixing with debian//..

But none of these alternatives work. None of the possible permutations

  .gitignore
  var/games/mirrormagic/scores/.gitignore
  /var/games/mirrormagic/scores/.gitignore
  debian/tmp/var/games/mirrormagic/scores/.gitignore
  debian/mirrormagic/var/games/mirrormagic/scores/.gitignore

in debian/not-installed manages to prevent .gitignore from being
installed.

Bug#831449: lintian on Sid amd64 reports volatile false spelling errors in binaries

[Thomas Schmitt]

Hi,

possibly the false positives are not volatile but rather my overrides
are interpreted differently between local Sid and lintian.debian.org.

The problem of reading mangled strings from binaries remains.

--

While processing the other lintian complaints i notice that on
lintian.debian.org all spelling-error-in-binary of libisoburn1 are
reported as "O". Among them is a complaint about "lengH".

So possibly something is wrong with my debian/libisoburn1.lintian-overrides
which is meant to be essentially:

  libisoburn1 binary: spelling-error-in-binary *libisoburn.so* paramters 
parameters
  libisoburn1 binary: spelling-error-in-binary *libisoburn.so* Allow to Allow 
one to
  libisoburn1 binary: spelling-error-in-binary *libisoburn.so* ment meant
  libisoburn1 binary: spelling-error-in-binary *libisoburn.so* lengH length

Complete file:
  
http://anonscm.debian.org/viewvc/pkg-libburnia/trunk/libisoburn/debian/libisoburn1.lintian-overrides?revision=381&view=markup

If one of the rules covers all typos, then "lengH" is indeed unused.
But how come ?

(And why does local lintian not find the typos "Programm", "someting"
 which are rightly reported by lintian.debian.org ?
 Locally i run:
   lintian -I -E --color never --show-overrides | less
)

--

Have a nice day :)

Thomas

Bug#831454: android-platform-tools-base: please rename package to conform with java library naming - i.e. lib*-java

[Jonas Smedegaard]

Source: android-platform-tools-base
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

The contents of android-platform-tools-base is solely java library code.

Therefore, please rename the package to conform with the general naming
sceme for java library packages - lib*-java.

 - Jonas

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJXigNcAAoJECx8MUbBoAEhzlAP/Avr5B+Dduf+0OfzF1LQQ5UX
5Hws1p+YDL32+8LeiBAHXlYYwj2yJibeU/X87v6/9D6+eHG9ayYzucAZWFpdRbXe
wGZflfALjwBF3/6mp8y+joQ7axq5I/U2Sh4ZL1XJfmKVAub2YP9lOdkSX5BB+RGl
GaELB4OzUdUzi5Gmc1/dhKLazTHNhh2bqW5n9pFq6udIbYPeevNnlnX83/kC1hsc
U/l53Xj4mhFbwfwyoqgkF21rSph9oVu27y3wddhg0qQqklpE/qzu/O8xSuHrzc+V
w/QF/OpUzdJ7uOdrrfqNDiQWKSszr86cY4yZSUsWSJLRDaOLc52xpAeTooPRmw76
vl+SsXNIOSO/2ZMWHDzKM8Huh60ofi3noPcmVnhINmXOwKl0mARTnf2Agybsxc6l
tD47WqxuavwMn58S+7KHoWrWXZgCTKUwwouvFay/T7OiFb4YSPuv+LJRSGmWMeFo
mtGFMWKtI2H2JOdHPhj8ARbn3u42mkVwbFYDZt0805W4ArbJY6YC9kZc0jAzKe74
c+KmaEDf7KjIYyEI1YsuAxt69iZUmAm8xgp7Wi345rnuEgIHxBK17t9yxzjIEFq0
4Miez7s/H59tQhef7UH6DVPN7vLP2wWhqFSSyc0bI3TLSm2rXJazcGkwfQPWASOT
0xDaMY5XpfjACaxjBh0o
=th4P
-END PGP SIGNATURE-

Bug#830991: [PKG-OpenRC-Debian] Bug#830991: Summary of needed changes

[Michael Biebl]

On Thu, 14 Jul 2016 16:45:08 +0200 Svante Signell
 wrote:
> On Thu, 2016-07-14 at 12:41 +0200, Andreas Henriksson wrote:
> 
> > Hello Adam Borowski.>Â 
> > >Â This bug report is unfortunately getting offtopic from its
> > original>Â purpose and there's cross-fire with #829488 ... :/>Â 
> > >Â On Thu, Jul 14, 2016 at 03:33:22AM +0200, Adam Borowski
> > wrote:>Â >Â On Thu, Jul 14, 2016 at 01:15:31AM +0200, Thomas Goirand
> > wrote:
> ...
> > > >  systemd-sysv: Make Conflicts against openrc versioned<<.y.z.
> > > Why?  I don't think it's a good idea to have two rc systems
> > > installed
> > > together, and as you want openrc to Depend: on sysvinit-core, you
> > > appear to
> > > want to preserve that Conflicts:.  
> > 
> > Having both installed isn't a good idea isn't the same thing as what
> > policy says about Conflicts. The packages *can* be installed together
> > and thus should not conflict.
> 
> Why does systemd-sysv conflict with file-rc, openrc, sysvinit-core,
> upstart, upstart-sysv then?

conflicting files (sysvinit-core,upstart,upstart-sysv) or conflicting
implementations of invoke-rc.d/update-rc.d (file-rc, openrc) which break
systemd.

For openrc that is no longer the case in newer versions, that's why we
want to make that versioned.


-- 
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#831455: tracker.debian.org: please reconsider where certificates are prompted for

[Christian Hofstaedtler]

Package: tracker.debian.org

Dear tracker maintainers,

apparently the tracker.d.o webserver asks for client certificates on
many/all URLs, instead of just on a dedicated login URL. This causes
quite some annoyance with some browsers, which will pop up
certificate selection dialogs way too often, sometimes even multiple
times for the same page.

Thanks,
-- 
 ,''`.  Christian Hofstaedtler 
: :' :  Debian Developer
`. `'   7D1A CFFA D9E0 806C 9C4C  D392 5C13 D6DB 9305 2E03
  `-

Bug#830991: Summary of needed changes

[Michael Biebl]

On Thu, 14 Jul 2016 01:15:31 +0200 Thomas Goirand  wrote:
> Hi,
> 
> Continuing our discussions in #debian-systemd, here's what need to happen.
> 
>  openrc (stable + sid): add Depends: sysvinit-core, Drop Provides:
> sysv-rc


Dropping the Provides: sysv-rc will make openrc uninstallable, as
sysvinit-core atm has
Depends: sysv-rc | file-rc.
We'd need a corresponding src:sysvinit upload for that. So I think that
change is not suitable for stable.

Making openrc depend on sysvinit-core is enough though to avoid the
current broken situation that caused #829488



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#830329: qwt: FTBFS: dh_makeshlibs: failing due to earlier errors

[Sebastiaan Couwenberg]

On 07/16/2016 03:43 AM, Lisandro Damián Nicanor Pérez Meyer wrote:
> On viernes, 15 de julio de 2016 10:36:27 P. M. ART Lisandro Damián Nicanor 
> Pérez Meyer wrote:
> [snip] 
>> I really *love* them (I haven't used cme before, someday I'll need to
>> investigate that one). Sadly I think applying them without the maintainer's
>> approval it's a bad idea.
> 
> It is worth to note here that the last upload was marked as "Team upload" 
> because it was prepared by Gudjon and I while we where working towards pushin 
> qwt with qt5 support to unstable and I just coordinated with Gudjon to do the 
> upload.
> 
> I'm really not too interested in maintaining qwt myself, I just happen to 
> have 
> another package that requires it too.

I'd like to see qwt properly team maintained, preferably within an
existing team (Debian Science seems a good candidate) instead of using a
single individual as Maintainer.

If that move it accompanied by the switch to git, I'm willing to be move
structurally involved in qwt packaging because it's an important
dependency of one of my packages too, although I also don't want to be
the sole maintainer.

Gudjon, please consider a more formal team structure for the maintenance
of the qwt package.

Kind Regards,

Bas

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



signature.asc
Description: OpenPGP digital signature

Bug#831449: lintian on Sid amd64 reports volatile false spelling errors in binaries

[Jakub Wilk]

Hi Thomas!

* Thomas Schmitt , 2016-07-16, 10:37:

But after upload by my sponsor i see on
 
https://lintian.debian.org/full/pkg-libburnia-de...@lists.alioth.debian.org.html#libisoburn
the complaint
 unused-override
   spelling-error-in-binary *libisoburn.so* lengH length


I think it's because "lengH" exists in the amd64 binary but in the in 
the i386 one. On lintian.d.o we check both of them.


Reason for the "lengH" complaint on my Sid is probably the output of 
strings which reflects a strange habit of gcc to chop texts into pieces 
which are separated by non-printable bytes.

Source line:

 xorriso/iso_manip.c: "Suitable are strings of length 4 or length 
1");

yields with "strings" from libisoburn.so

 SuitableL
 th 1I
 are strA
 ings of E1
 length 41
 or lengH


This is bizarre. Do you know why GCC does it? :-/

--
Jakub Wilk

Bug#830991: Summary of needed changes

[Michael Biebl]

On Thu, 14 Jul 2016 03:33:22 +0200 Adam Borowski 
wrote:

> > Drop Provides: sysv-rc
> 
> Sounds good, it'd be easier to manage relations with real sysv-rc.
> 
> It's not that trivial a change, though: there's a number of packages whose
> relations need to be transitioned.  
> 
> bum
> lbcd
> puppet
> rcconf
> sysv-rc-conf
> initscripts
> sysvinit-core


Bugs for puppet and lbcd have been filed [1] and are either fixed or pending
The remaining packages bum, rcconf and sysv-rc-conf are runlevel
editors, so would need to be checked carefully if they actually support
alternative -rc implementations.

As for initscripts and sysvinit-core: Those currently have
Depends: sysv-rc | file-rc

We'll need to update that list and include openrc as alternative.
I'd be fine with NMUing src:sysvinit to make that change.

Michael

[1]
https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=pkg-systemd-maintain...@lists.alioth.debian.org;tag=sysv-rc-dep


-- 
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#831240: google-perftools: FTBFS: Running death test 0 hangs

[Santiago Vila]

On Fri, 15 Jul 2016, Aliaksey Kandratsenka wrote:

> Thanks for reporting the issue. I just tried to reproduce the problem
> on my sid laptop in cleanly deboostrap-ed sid chroot and was unable to
> hit this issue. This maybe indicates that kernel matters or maybe
> there is something else in the host that is relevant.

For the record: While checking for "dpkg-buildpackage -A", I was also
able to reproduce this problem in the past:

Running death test 0...make[2]: *** wait: No child processes.  Stop.
make[2]: *** Waiting for unfinished jobs
make[2]: *** wait: No child processes.  Stop.
make[1]: *** wait: No child processes.  Stop.
make[1]: *** Waiting for unfinished jobs
make[1]: *** wait: No child processes.  Stop.
make: *** wait: No child processes.  Stop.
make: *** Waiting for unfinished jobs
make: *** wait: No child processes.  Stop.
Build killed with signal TERM after 150 minutes of inactivity

I'm also using sbuild, triggered by a cron job.

Thanks.

Bug#586486: Hello friend i have a business issue to discuss with you

[barr koffi]

Bug#831456: ITP: policyd-rate-limit -- postfix policy daemon limiting the number of mails a user can send

[Valentin Samir]

Package: wnpp
Severity: wishlist
Owner: Valentin Samir 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

* Package name: policyd-rate-limit
  Version : 0.5.0
  Upstream Author : Valentin Samir 
* URL : https://pypi.python.org/pypi/policyd-rate-limit
* License : GPLv3
  Programming Lang: Python
  Description : postfix policy daemon limiting the number of mails a user 
can send

policyd-rate-limit is a simple postfix policy daemon written in python3
allowing to limit the number of mails a user can send over time.
Users are identified either via their sasl usernames or their ip addresses.
Limitation rules are a list of couples (number of mails, number of seconds).
If a user has sent more than number of mails in number of seconds,
a configurable error is returned to the user.


By limiting the number of mails sent by users, this package allow to mitigate
the effects of a compromised email user account: instead for starting to send 
thousand
of spams, the compromised account will be limited, by default, to 150 mails a 
day.
An option allows policyd-rate-limit to send daily mail reports about who reach
limits to allow abuse detection.


I use it on my personal server.
Once package, it is planned to use it on
https://www.crans.org (a french small ISP) smtp server.

The packages postfix-cluebringer and postfwd provides similar functionalities.
postfix-cluebringer is written in php and use an interface web for 
configuration.
It is also lacking of ipv6 support,
postfwd is written in perl and offer a lot of other advanced functionality and
is more like a firewall for postfix.
Both lack of the mail report support.


The package is uploaded to mentors.debian.net.


I do need sponsor for upload to the debian archive.


-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJXig7RAAoJEJwmwSdHaXDdtAoQAJQka30oXCLxJC98a9eRSTjk
txS2vOwuX7jfXxfp1E2FRLnHrDhKKNZa9PvA0hlhrTKffgDu+W+PQIXF5b768JRB
r0S8xGw86S6EI6phCTwfhQ/R28Mv0z+ztLQPqqj/nDiUaS7IcxRv+bU49TC7PwWb
bvIa2/h/PEyCGnhBS8JVpcim0YEpKB+qbCvxmhek0FntanKKMCC4zJxMzz6aUmKX
+Tp4z5GMQQMmRs8to8X0v0TFl1HY5bCGOG9TjIdDzHF4q3QkBt8p1ho+SDvgEzwX
86sgoXVK2sp4i34JjT4PtqNpnMNzCanLGPRJdRXb+zyU4ctKiUsnHL5Yi5h4HaeB
sDLkG/hgKRY+QJN8GfIel5Asxm6uVLpEPhVs6v/Fpnur264rgYVFSheOmxudw2JH
SdtVI3TIh0v74QlA3C2pOoStvuhoSFoaze2bWD95LOdVcJ4a6fR73HSbf2+Uxskc
oRkUMuoraz3OVNO95xWAqV9ju0y/DHLjFTMXyBSu96uFlnX8WsxBnvjH89vyl9UE
1qqjT/ZxC18YB66xT1UefCrEutQeLKoDqhBKd4+umzs1pHhMuNK61HYKsS2yByAB
m+B7Bc6ermo1qMXP9ivk0Bq/Zg7AjmaY1V3Zx0ZkmSV5Q88a6MUAvthFUmFcPspt
qWxrWcuFrNX7Xoe1Abz8
=5Q9r
-END PGP SIGNATURE-

Bug#830991: Summary of needed changes

[Michael Biebl]

Hi

On Thu, 14 Jul 2016 03:33:22 +0200 Adam Borowski 
wrote:
> On Thu, Jul 14, 2016 at 01:15:31AM +0200, Thomas Goirand wrote:
> > Continuing our discussions in #debian-systemd, here's what need to happen.
> > 
> >  openrc (stable + sid): add Depends: sysvinit-core,
> 
> That's wrong -- openrc works fine with most if not all modular inits.  In
> Debian that's currently only sysvinit-core (maybe also busybox?), but a
> number of derivatives experiment with or use others, there's no reason to
> make their life harder if a better way to represent this relation exists,
> ie, Conflicts: with systemd-sysv.  Which happens to be already in place.

So, my POV is, that a user that runs
apt install openrc
get's a system that will boot with openrc. At least that would be my
expectation. So openrc should make sure to pull in all necessary bits
and pieces.
A Conflicts: systemd-sysv in openrc isn't the correct solution to ensure
this, as you might get an arbitrary /sbin/init implementation (like
upstart, which I'm not sure actually works with openrc) or no /sbin/init
at all (init is no longer essential).

Regards,
Michael

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



signature.asc
Description: OpenPGP digital signature

Bug#815506: [debhelper-devel] Bug#815506: dh_install: not-installed requires debian/tmp/ prefix

[Niels Thykier]

Drew Parsons:
> [...]
> 
> 
> [...]
> 
> From the wording of the man page, "List the files that are deliberately
> not installed in any binary package.", I would expect, or hope, that
> just .gitignore alone in not-installed to work.
> 

Ok, so this is where the misunderstanding starts.  Thanks for clarifying.

The "not-installed" file is *not* a way of doing "--exclude", although I
can see how you have arrived at that conclusion.

> The manpage also says "Paths listed in this file are ignored". [...]

That is only reading half the sentence.  The rest goes:

  [...] by the check done via --list-missing (or --fail-missing)

So that is the only part where the listed paths are ignored.


I will clarify the documentation in the next version.

Thanks,
~Niels

Bug#824806: golang: random_build_path_by_golang_compiler is #824806

[Nicolas Braud-Santoni]

Ping?

On Wed, Jul 06, 2016 at 08:05:32PM +0200, Nicolas Braud-Santoni wrote:
> 
> Hi,
> 
> I backported the upstream commit that solves the issue and tested it
> (by building the package, then rebuilding the Go compiler and standard
> library using the produced compiler).
> 
> This would allow us to make progress on reproducible builds for all
> Golang binary package now, rather than waiting for Golang 1.7 to land.
> 
> 
> Would this be acceptable for inclusion?
> 
> 
> Best,
> 
>   nicoo


signature.asc
Description: PGP signature

Bug#830978: Browserified javascript and DFSG 2

[Sam Hartman]

> "Neil" == Neil Williams  writes:
>> > * The point of having the source code (with an appropriate
>> licence > etc.) is so that all our contributors, downstreams, and
>> users are > able to modify the code and to share their
>> modifications with each > other, with Debian, and with upstream.
>> 
>> I agree this is an important consideration, but not serious
>> enough to reject a package.

Neil> So you consider that upstream are not fully-qualified users
Neil> somehow and therefore do not get the benefits of the DFSG? If
Neil> the freedoms of users who choose to interact with upstream are
Neil> reduced by choices made within the package then the package is
Neil> breaking the DFSG by penalising a field of endeavour.

Neil, I have a fairly strong negative emotional reaction when I read the
paragraph you wrote.  I'd like to share that because I think if I share
where I'm coming from it will be easier for me to hear you, and easier
to participate calmly.

When I read the above, I'm worried because I think that freedoms I care
about would be limited, and I don't like to see the DFSG reshaped to
limit freedoms.
I'm afraid when I think I hear us seeding the contents of Debian to
upstream.  We are Debian; we choose what Debian is.

I want to stress that I think you and I are in agreement on handlebars.

However, I do think the freedom to fork from upstream, to move away from
upstream practices we disagree with is important.

I also think that the freedom to "free," over time software even in
cases where upstream has a non-free source control system, or where
we're having to build up a new form of source code because of
restrictions on what's currently the source code are important.

I do not agree that being an upstream is a field of endeavour.

I do not agree that we must always use the same source code form that
upstream does.  Sometimes upstream is wrong.  Sometimes there are
multiple upstreams.
Sometimes we want to fork.

We do however need to ship the source code we use whatever that is.  It
needs to really be source code.  It needs to be a reasonable form in
which we would choose to make modifications.  If there are other
plausible source forms that are being used (even if some of them are
non-free), and those source forms would make the modifications easier,
that's a strong argument that the software is probably not free as we
propose to ship it.

I do not wish us to make the upstream form of source so special that we
in our best judgment cannot override it.

I do hear your worry that you want to be able to exchange modifications
with upstream.  Without modifications, without free flow of those
modifications, software is not free.  I ask that we have the flexibility
to reject people who aren't actually shipping source they would use to
modify software while accepting people who legitimately disagree about
what the source form is.

Bug#831449: lintian on Sid amd64 reports volatile false spelling errors in binaries

[Thomas Schmitt]

Hi,

strings wrote:
> >  ings of E1
> >  length 41
> >  or lengH

Jakub Wilk wrote:
> This is bizarre. Do you know why GCC does it? :-/

Not at all.
I wonder how the machine code puts these fragments together to a
human readable text. But on the other hand i did not do assembler
since the days of the 6502 CPU.

The disease is present at the start of the .so file, after some
unmangled program symbols have been shown by "strings". At some
point of sequential reading the texts suddenly become normal.
The disease does not come back until the end.

Same with the GNU xorriso binary, a static compilation of 4 library
sources and a tiny main program.
But i do not see this pattern with big binaries in /usr/bin (vim.basic,
gcc-5, gpg).

Is this some special amd64 trick which is applied only at low
addresses ?
The first full length strings appear at byte addresses
  0x0aa960  of libisoburn.so
  0x104a20  of GNU xorriso
  

As said, it also happens on my Debian 8 but with less non-text bytes
put inbetween the text snippets.


Have a nice day :)

Thomas

Bug#830991: Summary of needed changes

[Benda Xu]

Hi Michael,

Michael Biebl  writes:

> For openrc that is no longer the case in newer versions, that's why we
> want to make that versioned.

I agree that systemd-sysv version-conflict with openrc (<0.20.4-1).

Do you have an estimated date for that?

Thanks,
Benda


signature.asc
Description: PGP signature

Bug#811670: FTBFS with GCC 6: cannot convert x to y

[Andreas Steigmiller]

Hi Jonas,

Our development is currently done with a non-public version control system (in 
order to easily manage non-public test ontologies).

Best,

Andreas

Am 16.07.2016 um 09:10 schrieb Jonas Smedegaard:
> Quoting Andreas Steigmiller (2016-07-16 01:37:13)
>> Many thanks for maintaining the packaging of Konclude for Debian and 
>> for reporting this problem. I fixed the compilation errors and zipped 
>> a new source code package of version 0.6.2 that can be downloaded with 
>> the following link (it is also available on Konclude's webpage):
>>
>> http://www.derivo.de/fileadmin/externe_websites/ext.derivo/KoncludeReleases/v0.6.2-544/Konclude-v0.6.2-544-SourceCode-GCC6Fixes.zip
>>
>> Of course, we will also include the fixes in the next release.
> That was quick!  Thanks a lot!
>
> Is your develpment done in a public version control system somewhere?  
> Such knowledge would be helpful to include in the Debian package, but I 
> failed to locate info on that from your website or in the source zip.
>
>  - Jonas 
>

Bug#830991: Summary of needed changes

[Michael Biebl]

On Thu, 14 Jul 2016 12:41:19 +0200 Andreas Henriksson 
wrote:
> 
> On Thu, Jul 14, 2016 at 03:33:22AM +0200, Adam Borowski wrote:

..

> > It'd also introduce a circular Depends: which is a no-no.
> 
> There's nothing in the archive which depends on openrc. How could
> it create a dependency loop? Please inform me about the loop you're
> seeing.

sysvinit-core and initscripts have
Depends: sysv-rc | file-rc

As I wrote earlier, once we drop Provides: sysv-rc from openrc, openrc
would be uninstallable, unless we drop that Depends line altogether or
add openrc as alternative. If we add openrc as alternative and make
openrc depend on sysvinit-core and initscripts, then we have two loops.

dependency loops are not nice, but they aren't the end of the world
either. That said, I'm open to alternative suggestions how this should
be done.
A Conflicts: systemd-sysv instead of Depends: sysvinit-core is not a
solution, as explained earlier.
Dropping the Depends: sysv-rc | file-rc from initscripts might be
possible. At least I don't see why it needs that dependency.

So we'd still have the sysvinit-core <-> openrc interrelation ship.

Any suggestions how to express the dependencies differently?

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#830991: Summary of needed changes

[Michael Biebl]

Hi Benda

Am 16.07.2016 um 12:54 schrieb Benda Xu:
> Hi Michael,
> 
> Michael Biebl  writes:
> 
>> For openrc that is no longer the case in newer versions, that's why we
>> want to make that versioned.
> 
> I agree that systemd-sysv version-conflict with openrc (<0.20.4-1).

I chose 0.20.4-2.1, as this also contained the cleanup of the diversions
from previous versions.

> Do you have an estimated date for that?


http://anonscm.debian.org/cgit/pkg-systemd/systemd.git/commit/?id=1ab8d4836dcca0485cd7b8307b2469c295584898

Will be in the next upload of systemd. We don't have a date for that
yet, but it should be soonish.



-- 
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#831457: g++-5: cannot find -ltsan

[Olaf van der Spek]

Package: g++-5
Version: 5.4.0-6
Severity: normal

Dear Maintainer,

libtsan appears to be missing..

$ g++ -fsanitize=thread z.cpp   
/usr/bin/ld: cannot find -ltsan

Gr,

Olaf

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

Kernel: Linux 4.6.0-1-686-pae (SMP w/3 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 g++-5 depends on:
ii  gcc-55.4.0-6
ii  gcc-5-base   5.4.0-6
ii  libc62.23-1
ii  libgmp10 2:6.1.1+dfsg-1
ii  libisl15 0.17.1-1
ii  libmpc3  1.0.3-1
ii  libmpfr4 3.1.4-2
ii  libstdc++-5-dev  5.4.0-6
ii  zlib1g   1:1.2.8.dfsg-2+b1

g++-5 recommends no packages.

Versions of packages g++-5 suggests:
pn  g++-5-multilib
pn  gcc-5-doc 
pn  libstdc++6-5-dbg  

-- no debconf information

Bug#831457: g++-5: cannot find -ltsan

[Olaf van der Spek]

Oops

$ clang++-3.9 -fsanitize=thread z.cpp
clang: error: unsupported option '-fsanitize=thread' for target
'i686-pc-linux-gnu'

Perhaps G++ should error out too?

2016-07-16 13:04 GMT+02:00 Olaf van der Spek :
> Package: g++-5
> Version: 5.4.0-6
> Severity: normal
>
> Dear Maintainer,
>
> libtsan appears to be missing..
>
> $ g++ -fsanitize=thread z.cpp
> /usr/bin/ld: cannot find -ltsan
>
> Gr,
>
> Olaf
>
> -- System Information:
> Debian Release: stretch/sid
>   APT prefers stable-updates
>   APT policy: (500, 'stable-updates'), (500, 'unstable'), (500, 'stable')
> Architecture: i386 (i686)
>
> Kernel: Linux 4.6.0-1-686-pae (SMP w/3 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 g++-5 depends on:
> ii  gcc-55.4.0-6
> ii  gcc-5-base   5.4.0-6
> ii  libc62.23-1
> ii  libgmp10 2:6.1.1+dfsg-1
> ii  libisl15 0.17.1-1
> ii  libmpc3  1.0.3-1
> ii  libmpfr4 3.1.4-2
> ii  libstdc++-5-dev  5.4.0-6
> ii  zlib1g   1:1.2.8.dfsg-2+b1
>
> g++-5 recommends no packages.
>
> Versions of packages g++-5 suggests:
> pn  g++-5-multilib
> pn  gcc-5-doc 
> pn  libstdc++6-5-dbg  
>
> -- no debconf information



-- 
Olaf

Bug#815506: [debhelper-devel] Bug#815506: dh_install: not-installed requires debian/tmp/ prefix

[Drew Parsons]

On Sat, 2016-07-16 at 10:46 +, Niels Thykier wrote:
> 
> The "not-installed" file is *not* a way of doing "--exclude",
> although I
> can see how you have arrived at that conclusion.
...
> I will clarify the documentation in the next version.

Thanks Niels.

Drew

Bug#831458: tidy: adds too much vertical space

[Francesco Poli (wintermute)]

Package: tidy
Version: 1:5.2.0-1.1
Severity: normal

Hello again,
besides bug #830066, another thing that I noticed after the upgrade

  [UPGRADE] tidy:amd64 20091223cvs-1.5 -> 1:5.2.0-1.1

is that tidy started to add too much vertical space.

Please let me explain the steps to reproduce the issue.

Let's start with an HTML document, such as, for instance:

  $ wget http://www.inventati.org/frx/progs/scripts/refresh-pubring.html

Please note that this HTML file is already formatted by an older
version of Tidy (as shown by the  item).
Hence, I expect that that the re-formatting performed by the current
version of Tidy should not change too much in the file.

Let's set the HTML_TIDY environment variable, in order to work around
bug #830066:

  $ export HTML_TIDY=~/.tidyrc

The ~/.tidyrc file is attached and includes:

  $ grep vertical-space ~/.tidyrc
  vertical-space: yes

Let's start by reformatting the file:

  $ tidy refresh-pubring.html > refresh-pubring_T1.html

Tidy adds two lines of vertical space around  and  headers,
between  items, around  items, around  items.
I really think that two lines are too much vertical space: I am
convinced that the behavior of older versions of Tidy was saner
(only one line of vertical space was added).
Please restore the previous behavior.

Moreover each  end tag is moved to the next line for no
good reason. Again, I think the behavior of older versions of
Tidy was saner: please fix this regression, too.

On the other hand, I appreciate that the 

Bug#830991: [PKG-OpenRC-Debian] Bug#830991: Summary of needed changes

[Benda Xu]

Hi Thomas,

Thanks for the summarization.

Thomas Goirand  writes:

> Continuing our discussions in #debian-systemd, here's what need to happen.
>
> Drop Provides: sysv-rc

>  zigo: in jessie, systemd-sysv tries to ensure correct combination
> of packages by depending on sysv-rc ... unfortunately openrc provides
> sysv-rc, so satisfies that. Which means you can start out with a messy
> situation which only goes downhill from there when also throwing file-rc
> into the mix.

This is the only reason to stop openrc from providing sysv-rc.  But
systemd-sysv in sid no longer depend on sysv-rc.  No need to do that
anymore, if we don't want to touch jessie.

>  openrc (sid/stretch): replace Recommends: init-system-helpers
> with
> Pre-Depends: init-system-helpers (>= 1.29) 

Ok.  That seems to be the only to guarantee availability of 
{update,invoke}-rc.d.

>  plus depends on initscripts, to be safe and add Depends:
> initscripts

I don't think so.

  initscripts Depends: sysv-rc | file-rc

and openrc provides sysv-rc.  The dependence relation is already there.

>  openrc (stable + sid): add Depends: sysvinit-core, 

  sysvinit-core Depends: sysv-rc | file-rc

The same logic applies.

>  systemd-sysv: Make Conflicts against openrc versioned << y.z.

openrc (<<0.20.4-1) to be precise.

> Benda, if you push such changes, I'll sponsor the uploads.

In conclusion, the bugs are resolved if openrc Pre-Depends
init-system-helpers and systemd-sysv only conflicts with a older version
of OpenRC.

Benda

Bug#831414: systemd: learns IPv6 prefix from its own RAs and configures IP address on wrong interface

[Marc Haber]

On Sat, Jul 16, 2016 at 10:55:29AM +0200, Martin Pitt wrote:
> Marc Haber [2016-07-15 21:00 +0200]:
> > I am filing this as severity minor because this bug is in a version
> > that is not officially in Debian.
> 
> Bumping as I dropped the reverted patch in git, i. e. the next upload
> will have the original upstream behaviour again.

Please don't, I do have another IPv6 showstopper bug in the pipe. The
code is IMO beyond repair and should be dumped and rewritten by
somebody who does actually know the protocol. How much more can
upstream do wrong with the default IP protocol of 2016 for exactly not
reason, we do have standard conforming and working code in the kernel.

> > While following up Martin's requests for #815793 and #815884, I have
> > found new misbehsvior regarding IPv6.
> 
> Thanks for the detailled description. To ensure that we have all the
> things to reproduce it, can you please attach the corresponding
> .network and .netdev files for eth0 and br0?

Nothing fancy at all:

[4/504]mh@fan:~$ head -n-0 /etc/systemd/network/*
==> /etc/systemd/network/br0.netdev <==
[NetDev]
Name=br0
Kind=bridge

==> /etc/systemd/network/br0.network <==
[Match]
Name=br0

[Network]
Address=192.168.29.254/24
DHCP=no
IPForward=yes

[Address]
Address=2a01:db8:0:328d::1d:100/64

[Address]
Address=2a01:db8:0:328d::1d:153/64

#[Address]
#Address=fe80::1/64

[Address]
Address=fec0:0:0:::1/128

[Address]
Address=fec0:0:0:::2/128

[Address]
Address=fec0:0:0:::3/128

[Route]
Gateway=192.168.29.180
Destination=172.16.0.0/24
Source=192.168.181.0/24

==> /etc/systemd/network/eth0.network <==
[Match]
Name=eth0

[Network]
DHCP=yes
IPForward=yes
DNS=192.168.181.53
DNS=192.168.251.53
DNS=fec0:0:0:::1
Domains=zugschlus.de ka51.zugschlus.de
IPv6AcceptRouterAdvertisements=1

[Address]
Address=2a01:db8:0:3282::1d:100/64

[Address]
Address=2a01:db8:0:3282::1d:250/128

[Address]
Address=192.168.182.250/32

==> /etc/systemd/network/eth0.network~ <==
[Match]
Name=eth0

[Network]
DHCP=yes
IPForward=yes
DNS=192.168.181.53
DNS=192.168.251.53
DNS=fec0:0:0:::1
Domains=zugschlus.de ka51.zugschlus.de
#IPv6AcceptRouterAdvertisements=1

[Address]
Address=2a01:db8:0:3282::1d:100/64

[Address]
Address=2a01:db8:0:3282::1d:250/128

[Address]
Address=192.168.182.250/32
[5/505]mh@fan:~$ 

This is plain networkd, no network-manager or ifupdown here.

If the systemd IPv6 userspace code does neighbor discovery as well,
then there is an additional bug since I have seen the system go the
neighbor cache entry for the default gateway go stale, thus losing
IPv6 connectivity, without re-soliciting the neighbor. I am not
reporting this as a bug right away since I saw this behavior in the
kernel code a few years ago, so this might be a new kernel issue. It
just appeared when I went to the 5pitti1 packages.

Greetings
Marc

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421

Bug#831396: procps: [ps] fails on kfreebsd

[Carsten Leonhardt]

> Ah ha, I think I know the problem. And it is related to the kernel version.
> asdfasdf has this:
> $ more /proc/sys/kernel/osrelease
> 2.6.16
> I bet you have something else, something bigger than 2.6.27
>
> The relevant procps code:
> if (linux_version_code < LINUX_VERSION(2, 6, 27))
>   kb_main_available = kb_main_free;
> else {
>   FILE_TO_BUF(VM_MIN_FREE_FILE, vm_min_free_fd);
>
> So, the fix will be to have some #if around that extra check and just use
> the old school make available the same as free.

correct:

$ more /proc/sys/kernel/osrelease
2.6.32

Bug#831459: jessie-pu: package virtualbox-guest-additions-iso

[Gianfranco Costamagna]

Package: release.debian.org
Severity: normal
Tags: jessie
User: release.debian@packages.debian.org
Usertags: pu


Forwarding the email from security team.

the debdiff is the new iso file and a new changelog entry, nothing more.



you can grab the file from here
http://debomatic-amd64.debian.net/distribution#stable/virtualbox-guest-additions-iso/4.3.36-1+deb8u1/buildlog

this is the changelog entry

diff -Nru virtualbox-guest-additions-iso-4.3.18/debian/changelog 
virtualbox-guest-additions-iso-4.3.36/debian/changelog
--- virtualbox-guest-additions-iso-4.3.18/debian/changelog  2015-03-26 
11:39:19.0 +0100
+++ virtualbox-guest-additions-iso-4.3.36/debian/changelog  2016-07-16 
13:19:14.0 +0200
@@ -1,3 +1,14 @@
+virtualbox-guest-additions-iso (4.3.36-1+deb8u1) jessie; urgency=medium
+
+  * New upstream bugfix release.
+- Addressed CVE-2016-0592,
+  CVE-2016-0495, CVE-2015-8104,
+  CVE-2015-7183, CVE-2015-5307,
+  CVE-2015-7183, CVE-2015-4813,
+  CVE-2015-4896, CVE-2015-3456
+
+ -- Gianfranco Costamagna   Fri, 15 Jul 2016 
18:11:50 +0200
+
virtualbox-guest-additions-iso (4.3.18-3) unstable; urgency=high

* Reuploading the previous package, the -2 got removed because of
Binary files 
/tmp/0fmDQ7p0Ij/virtualbox-guest-additions-iso-4.3.18/VBoxGuestAdditions_4.3.18.iso
 and 
/tmp/BRDWMDWXw8/virtualbox-guest-additions-iso-4.3.36/VBoxGuestAdditions_4.3.18.iso
 differ
Binary files 
/tmp/0fmDQ7p0Ij/virtualbox-guest-additions-iso-4.3.18/VBoxGuestAdditions_4.3.36.iso
 and 
/tmp/BRDWMDWXw8/virtualbox-guest-additions-iso-4.3.36/VBoxGuestAdditions_4.3.36.iso
 differ


cheers,

Gianfranco


Il Venerdì 15 Luglio 2016 20:25, Salvatore Bonaccorso  ha 
scritto:



Hi Gianfranco,


On Fri, Jul 15, 2016 at 04:10:38PM +, Gianfranco Costamagna wrote:
> Hi Security Team, a while ago we got virtualbox updated from 4.3.18
> to 4.3.36 as security > upload.
> 
> This was a complete success, but now we have two "issues" 1) there
> is a mismatch between virtualbox and virtualbox-guest-additions-iso
> packages (this isn't a big issue, since it is just a warning)
> 
> 
> 2) the guest-additions-iso package is an iso file that contains some
> source code (from virtualbox) and builds kernel modules and some
> tools used in the guest machines.
> 
> I don't know, but it might be affected by some/many of the same CVEs
> that we fixed in virtualbox, so I think it is a sane idea to have a
> security upload also for this package.
> 
> What is your opinion?  I can upload a 4.3.36 in a few minutes if
> needed, it is just a matter of packing an iso and creating a
> changelog entry.

The package beeing non-free in all supported suites is not really
supported via security.d.o. Could you contact the stable release
managers to have an update sheduled via a point release?

Cf.
https://www.debian.org/doc/manuals/developers-reference/ch05.en.html#upload-stable

Regards,
Salvatore

debdiff
Description: Binary data

Bug#815884: does not retry IPv6 router solicitations

[Marc Haber]

On Wed, Jul 06, 2016 at 10:50:53AM +0200, Martin Pitt wrote:
> networkd actually tries a RS three times, but from then on only
> regularly retries DHCPv6 soliciations, no router solicitations:

I can confirm this. So this bug can be closed.

Greetings
Marc

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421

Bug#813274: A red X is a bad image for "Verified and encrypted connection".

[Sergio Durigan Junior]

Control: tags -1 + unreproducible
Control: tags -1 + moreinfo

On Saturday, January 30 2016, 積丹尼 Dan Jacobson wrote:

> A red X is a bad image for "Verified and encrypted connection".
>
> In fact it conveys the opposite.
> Or maybe some parts of the browser are missing.

I can't reproduce this bug.  I am using the Midori from experimental,
but even on Midori from unstable/testing I still can see the little
locker.

Do you still see this problem?  Did it always happen?

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/


signature.asc
Description: PGP signature

Bug#715490: a browser with no URL bar

[Sergio Durigan Junior]

Control: tags -1 + moreinfo

On Tuesday, September 22 2015, I wrote:

> On Thursday, September 17 2015, 積丹尼 Dan Jacobson wrote:
>
>> Make the window fullscreen, via the middle icon in the top right frame
>> (icewm) and the URL bar appears.
>>
>> Make it back to default, and the URL bar disappears.
>
> OK, mentioning icewm helped me a lot here.  I tested Midori there, and I
> saw that the URL bar disappears when you resize the window and make it
> very, very small.
>
> Soon I plan to upload a new version of Midori compiled against GTK+ 3.0
> (the current one uses GTK+ 2.0); I think this change could help improve
> things in this bug.

The Midori from experimental is built against GTK-3.0 and WebKit 2.
Could you please try it and see if it fixes this bug?

Thanks,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/


signature.asc
Description: PGP signature

Bug#706264: Segmentation fault upon giving location

[Sergio Durigan Junior]

On Thursday, September 17 2015, 積丹尼 Dan Jacobson wrote:

> But now I see instead nine exact copies of "m.here.com wants to save an HTML5 
> database."
> Maybe they should all be one question:
> "m.here.com wants to save 9 HTML5 databases."

Out of curiosity, do you still see this with the Midori from
experimental (built against GTK-3.0 and WebKit 2)?  I could not
reproduce the bug anymore.

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/


signature.asc
Description: PGP signature

Bug#830991: [PKG-OpenRC-Debian] Bug#830991: Summary of needed changes

[Benda Xu]

Hi Michael,

I would like to clarify that OpenRC is a service manager, not an init.
Treat it as a shell script that can call (or supervise) a set of tools.
OpenRC is not at all exclusive. It can coexist with anything provided
there is no file conflict.

So...

Michael Biebl  writes:

> So, my POV is, that a user that runs apt install openrc get's a system
> that will boot with openrc. At least that would be my expectation. 

Although common, this is not all the use cases of OpenRC.  It is
perfectly fine to execute openrc by the user at any time.

A user does not install OpenRC to get his system to boot.  He should
install runit / sysvinit / systemd / s6 instead.  If the user *happens*
to install both sysvinit and OpenRC, he will have a system that booted
with sysvinit and OpenRC.

> So openrc should make sure to pull in all necessary bits and pieces.

That said, an openrc Suggests: sysvinit-core could make sense.

If it is not a dependency, no need to depend on it.

> A Conflicts: systemd-sysv in openrc isn't the correct solution to
> ensure this,

I agree, they can coexist.  Systemd can call openrc, no problem at all.

No conflict here.   The only point of the conflict was
{update,invoke}-rc.d, which is now gone thanks to init-system-helpers.

> as you might get an arbitrary /sbin/init implementation (like upstart,
> which I'm not sure actually works with openrc)

Sure upstart works with OpenRC.  (Only that upstart is removed from
Debian.)

> or no /sbin/init at all (init is no longer essential).

This is acceptable, no problem at all.  You can boot with init=/bin/bash
and manually invoke openrc as you like.  A docker instance, for example,
behaves like that.

Yours,
Benda


signature.asc
Description: PGP signature

Bug#830991: [PKG-OpenRC-Debian] Bug#830991: Summary of needed changes

[Michael Biebl]

On Sat, 16 Jul 2016 20:16:47 +0900 Benda Xu  wrote:
> Hi Thomas,
> 
> Thanks for the summarization.
> 
> Thomas Goirand  writes:
> 
> > Continuing our discussions in #debian-systemd, here's what need to happen.
> >
> > Drop Provides: sysv-rc
> 
> >  zigo: in jessie, systemd-sysv tries to ensure correct combination
> > of packages by depending on sysv-rc ... unfortunately openrc provides
> > sysv-rc, so satisfies that. Which means you can start out with a messy
> > situation which only goes downhill from there when also throwing file-rc
> > into the mix.
> 
> This is the only reason to stop openrc from providing sysv-rc.  But
> systemd-sysv in sid no longer depend on sysv-rc.  No need to do that
> anymore, if we don't want to touch jessie.

I think dropping that Provides is logically correct and should be done
in any case, maybe not for stretch, but in sid for sure.


> >  plus depends on initscripts, to be safe and add Depends:
> > initscripts
> 
> I don't think so.
> 
>   initscripts Depends: sysv-rc | file-rc
> 
> and openrc provides sysv-rc.  The dependence relation is already there.

Ahem, no. It's the inverse dependency
With initscripts no longer being installed by default, nothing will
guarantee that initscripts will be installed. If openrc depends on
initscripts to boot a system successfully, it should depend on it.


> >  openrc (stable + sid): add Depends: sysvinit-core, 
> 
>   sysvinit-core Depends: sysv-rc | file-rc
> 
> The same logic applies.

No, it's the same issue as above.


> >  systemd-sysv: Make Conflicts against openrc versioned << y.z.
> 
> openrc (<<0.20.4-1) to be precise.
> 
> > Benda, if you push such changes, I'll sponsor the uploads.
> 
> In conclusion, the bugs are resolved if openrc Pre-Depends
> init-system-helpers and systemd-sysv only conflicts with a older version
> of OpenRC.

The Pre-Depends and versioned Conflicts only address the failing dist
upgrade (#829488).
They don't address that the prioritoy of initscripts will be lowered for
stretch and is no longer installed by default.

It also doesn't address the problem that "apt install openrc" doesn't
lead to a system actually booting with openrc as init system (the
combination openrc + systemd-sysv|upstart simply doesn't make sense)

Regards,
Michael

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



signature.asc
Description: OpenPGP digital signature

Bug#830836: midori misses some command line commands. Must try again once or twice

[Sergio Durigan Junior]

On Monday, July 11 2016, 積丹尼 Dan Jacobson wrote:

> Often with midori already fully running,
> I do
> $ midori http://SOME.WEB/PAGE
> but nothing happens. Sometimes I need to go back to the shell and do the
> same command one or two times more before midori suddely gets the
> message and starts browsing the page. Otherwise it is just like I did
> $ #midori ...
> with a shell comment character in front.

I could not reproduce this bug entirely here.  Here's what I found.

When Midori is already running and I try to open a page on the same
session via the command line, i.e., by doing:

  $ midori http://some.page

I can see that Midori opens the page normally.  However, if I close the
tab and issue the same command on the terminal (i.e., if I ask Midori to
open the same page I had opened before), Midori does not open the page
anymore.

But as I said, Midori works fine for and opens pages normally from the
command line.

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/


signature.asc
Description: PGP signature

Bug#800573: heimdall-flash: fails to download PIT for Galaxy S5 (G900T3)

[Ben Hutchings]

Control: tag -1 fixed-upstream

On Wed, 30 Sep 2015 22:42:15 -0400 "Andrew J. Buehler"
 wrote:
> Package: heimdall-flash
> Version: 1.4.1-1
> Severity: important
> Tags: upstream
> 
> Dear Maintainer,
> 
> I recently purchased a Samsung Galaxy S5 smartphone, through T-Mobile.
> Its model / stock-firmware number is SM-G900T3, which is relatively new
> for this device; most successful use of Heimdall with this device in the
> past has been with earlier model / firmware numbers. (I am not clear
> whether the number represents a model number or the stock device
> firmware, though I suspect the former.)
[...]
> Although the package currently in Debian is version 1.4.1 (the latest
> numbered upstream release), not 1.4.0, it still exhibits this problem.
> 
> However, when I built Heimdall from current git HEAD (commit
> d0526a3b74a003dfc6f805682693be9173ffcd88, from March 21st), the
> resulting binary was able to download the PIT without issues (aside from
> cosmetic warning messages).
[...]

I just ran into the same problem, and again current git HEAD works for
me.  Please update to a git snapshot.  I'd be happy to make an NMU to
fix this, if you don't have time.

Ben.
 
-- 

Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.


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

Bug#830991: [PKG-OpenRC-Debian] Bug#830991: Summary of needed changes

[Michael Biebl]

Hi,

Am 16.07.2016 um 13:40 schrieb Benda Xu:
> Hi Michael,
> 
> I would like to clarify that OpenRC is a service manager, not an init.

The package description says "dependency based init system".

If you want openrc to be treated as you say,i.e. not as an init, you
should make that super-clear in the package description that installing
openrc will *not* necessarily lead to a system booting with openrc.

Otherwise it's highly confusing.

Regards,
Michael


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



signature.asc
Description: OpenPGP digital signature

Bug#831460: mirrors: broken mirror site

[Ritesh Raj Sarraf]

Package: mirrors
Severity: important

Please find below a mirror host, redirected through
httpredir.debian.org, which seems to not be carrying a common
architecture. This failure escalates into user's apt database remaining
stale.

Should such mirrors be dropped ?
What should APT do in cases where some mirrors have dropped certain
architecture support ?

Get:52 http://debian.grena.ge/debian experimental/main amd64 Packages 
2016-07-16-0911.40.pdiff [33 B]
Ign:53 http://debian.grena.ge/debian experimental/main i386 Packages
  
Get:54 http://debian.grena.ge/debian experimental/main Translation-en 
2016-07-16-0911.40.pdiff [473 B]
Get:51 http://debian.grena.ge/debian experimental/main Sources 
2016-07-16-0911.40.pdiff [31 B]
Get:52 http://debian.grena.ge/debian experimental/main amd64 Packages 
2016-07-16-0911.40.pdiff [33 B]
Get:54 http://debian.grena.ge/debian experimental/main Translation-en 
2016-07-16-0911.40.pdiff [473 B]
Ign:54 http://debian.grena.ge/debian experimental/main Translation-en 
2016-07-16-0911.40.pdiff
Ign:15 http://debian.grena.ge/debian testing/main i386 Packages 
  
Ign:20 http://debian.grena.ge/debian testing/contrib i386 Packages  
  
Ign:25 http://debian.grena.ge/debian testing/non-free i386 Packages 
  
Ign:33 http://debian.grena.ge/debian unstable/main i386 Packages
  
Ign:38 http://debian.grena.ge/debian unstable/contrib i386 Packages 
  
Ign:43 http://debian.grena.ge/debian unstable/non-free i386 Packages
  
Ign:53 http://debian.grena.ge/debian experimental/main i386 Packages
  
Get:55 http://debian.grena.ge/debian experimental/main Translation-en   
  
Get:55 http://debian.grena.ge/debian experimental/main Translation-en   
  
Get:55 http://debian.grena.ge/debian experimental/main Translation-en   
  
Get:55 http://debian.grena.ge/debian experimental/main Translation-en   
  
Get:55 http://debian.grena.ge/debian experimental/main Translation-en [234 kB]  
  
Err:15 http://debian.grena.ge/debian testing/main i386 Packages 
  
  404  Not Found
Err:33 http://debian.grena.ge/debian unstable/main i386 Packages
  
  404  Not Found
Err:53 http://debian.grena.ge/debian experimental/main i386 Packages
  
  404  Not Found
Fetched 62.3 MB in 3min 15s (319 kB/s)  
  
Reading package lists... Done
E: Failed to fetch 
http://debian.grena.ge/debian/dists/testing/main/binary-i386/Packages  404  Not 
Found
E: Failed to fetch 
http://debian.grena.ge/debian/dists/unstable/main/binary-i386/Packages  404  
Not Found
E: Failed to fetch 
http://debian.grena.ge/debian/dists/experimental/main/binary-i386/Packages  404 
 Not Found
E: Some index files failed to download. They have been ignored, or old ones 
used instead.
2016-07-16 / 17:25:11 ♒♒♒  ☹  => 100  

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

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

Bug#830329: qwt: FTBFS: dh_makeshlibs: failing due to earlier errors

[Lisandro Damián Nicanor Pérez Meyer]

On sábado, 16 de julio de 2016 12:13:19 P. M. ART Sebastiaan Couwenberg wrote:
> On 07/16/2016 03:43 AM, Lisandro Damián Nicanor Pérez Meyer wrote:
> > On viernes, 15 de julio de 2016 10:36:27 P. M. ART Lisandro Damián Nicanor
> > Pérez Meyer wrote:
> > [snip]
> > 
> >> I really *love* them (I haven't used cme before, someday I'll need to
> >> investigate that one). Sadly I think applying them without the
> >> maintainer's
> >> approval it's a bad idea.
> > 
> > It is worth to note here that the last upload was marked as "Team upload"
> > because it was prepared by Gudjon and I while we where working towards
> > pushin qwt with qt5 support to unstable and I just coordinated with
> > Gudjon to do the upload.
> > 
> > I'm really not too interested in maintaining qwt myself, I just happen to
> > have another package that requires it too.
> 
> I'd like to see qwt properly team maintained, preferably within an
> existing team (Debian Science seems a good candidate) instead of using a
> single individual as Maintainer.
> 
> If that move it accompanied by the switch to git, I'm willing to be move
> structurally involved in qwt packaging because it's an important
> dependency of one of my packages too, although I also don't want to be
> the sole maintainer.
> 
> Gudjon, please consider a more formal team structure for the maintenance
> of the qwt package.

I agree, a team should be much better.

By the way I'll take care of the current FTBFSs, it seems we need some more 
symbols tweaking.


-- 
Dadme voto electrónico y con una terminal os haré presidente.
  el.machi

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


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

Bug#827835: XMLParser Ruby module: fails to build with Expat 2.2.0

[Antonio Terceiro]

Dear Yoshida,

For several years he have shipped your XMLParser Ruby module in Debian,
and it is even used by a tool that is very important to the Debian
community (apt-listbugs).

Recently it was detected that XMLParser fails to build, and I suspect
that is related to a new version of Expat (2.2.0). The details can be
found in the Debian bug:

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

Do you think you would be able to look at this?

Thanks in advance!


signature.asc
Description: PGP signature

Bug#830300: RE: Bug#830300: bug in mdadm

[Michael Biebl]

On Sat, 9 Jul 2016 19:47:07 +0300
=?utf-8?B?0JvRjtCx0LXQvSDQmtCw0YDQsNCy0LXQu9C+0LI=?= 
wrote:
> Hi,
> 
> The problem I am trying to solve is that my laptop (ASUS Zenbook UX301LAA) is 
> using Intel RAID0 setup:
> 
> 00:1f.2 RAID bus controller: Intel Corporation 82801 Mobile SATA Controller 
> [RAID mode] (rev 04)
> 
> But it stopped working 5-6 months ago (3.3.2-5 was the last version that was 
> working out of the box). My understanding is that for some reason mdadm is 
> not recognizing the setup as being a IMSM RAID and I was forcing the RAID 
> assembly to bypass this check with the envvars until this was also broken by 
> the last mdadm update.
> 

Have you filed a bug report back then?
Seems to me that fixing the root cause is a better approach then keeping
this workaround alive (and 3.4-2 out of testing).

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#830991: [PKG-OpenRC-Debian] Bug#830991: Summary of needed changes

[Michael Biebl]

Am 16.07.2016 um 13:41 schrieb Michael Biebl:
> On Sat, 16 Jul 2016 20:16:47 +0900 Benda Xu  wrote:
>>
>> Thomas Goirand  writes:
>>
>>> Continuing our discussions in #debian-systemd, here's what need to happen.
>>>
>>> Drop Provides: sysv-rc
>>
>>>  zigo: in jessie, systemd-sysv tries to ensure correct combination
>>> of packages by depending on sysv-rc ... unfortunately openrc provides
>>> sysv-rc, so satisfies that. Which means you can start out with a messy
>>> situation which only goes downhill from there when also throwing file-rc
>>> into the mix.
>>
>> This is the only reason to stop openrc from providing sysv-rc.  But
>> systemd-sysv in sid no longer depend on sysv-rc.  No need to do that
>> anymore, if we don't want to touch jessie.
> 
> I think dropping that Provides is logically correct and should be done
> in any case, maybe not for stretch, but in sid for sure.

s/stretch/jessie/



-- 
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#815793: IPv6 code ignores unsolicited router advertisements

[Marc Haber]

Hi Martin,

On Fri, Jul 15, 2016 at 09:04:59PM +0200, Marc Haber wrote:
> On Wed, Jul 06, 2016 at 08:57:43AM +0200, Martin Pitt wrote:
> > while we reverted the change in 229, we don't want to carry the
> > reversion forever. Also, some problems were fixed already in 230, like
> > [1]. I forwarded this upstream to
> > https://github.com/systemd/systemd/issues/3663, and will now play
> > relay :-)
> > 
> > If this is hardware specific, can you please try this with 230 with
> > the patch reverted? I build packages for amd64 here:
> > https://people.debian.org/~mpitt/tmp/systemd-userspace-ndisc/
> > (there's also a Packages.gz so this can be used as an apt deb line)
> > There were a lot of changes to the RA handling in 230.
> 
> Unfortunately the system I have been seeing this on is a Banana Pi,
> thus armhf, and I cannot run your test packages on this system. This
> bug does not, however, show itself on a reference system running amd64
> with 230-5pitti1.

I regret to inform you that we have a heisenbug here. When
reconfiguring and restarting radvd, systemd sometimes decides to act
on the new announcement, and sometimes doesn't.

For example, after receiving this announcement:

13:40:23.075889 IP6 (flowlabel 0x4717d, hlim 255, next-header ICMPv6 (58) 
payload length: 240) fe80::1 > ff02::1: [icmp6 sum ok] ICMP6,
hop limit 64, Flags [none], pref medium, router lifetime 1800s, 
reachable time 0s, retrans time 0s
  prefix info option (3), length 32 (4): 2a01:db8:0::3282::/64, Flags 
[onlink, auto], valid time 86400s, pref. time 14400s
  route info option (24), length 24 (3):  ::/0, pref=high, 
lifetime=1800s
  route info option (24), length 24 (3):  2000::/3, pref=high, 
lifetime=1800s
  route info option (24), length 24 (3):  2a01:db8:0::3280::/60, 
pref=high, lifetime=1800s
  route info option (24), length 24 (3):  2a01:db8:0::32b0::/60, 
pref=high, lifetime=1800s
  rdnss option (25), length 40 (5):  lifetime 600s, addr: 
2a01:db8:0::3281::35:100 addr: 2a01:db8:0::328e::35:100
  dnssl option (31), length 48 (6):  lifetime 600s, domain(s): 
zugschlus.de. ka51.zugschlus.de.
  source link-address option (1), length 8 (1): 7e:79:61:31:55:28

systemd didn't configure an SLAAC IPv6 address on the interface. I
guess that this depends on whether and how many other IP addresses are
on the interface. It seems to work more reliably if the interface
doesn't already have an address from this prefix. If this is the case,
it is another proof of the gross misunderstanding of IPv6 that the
person writing this piece of the code has.

Greetings
Marc

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421

Bug#828834: #828834: apcupsd: FTBFS in testing (configure: error: Missing required tool)

[Christian Hofstaedtler]

Control: tags -1 + confirmed

* Aurelien Jarno  [160716 12:17]:
> This now happens on the build daemons, though only on mips64el (i don't
> really know why):

Only recently the "init" package became non-essential, so only newly
created chroots will show this problem.

-- 
 ,''`.  Christian Hofstaedtler 
: :' :  Debian Developer
`. `'   7D1A CFFA D9E0 806C 9C4C  D392 5C13 D6DB 9305 2E03
  `-

Bug#819083: fixed

[Nathaniel Roach]

It fixed the lack of cursor on unlock but the flicker that only clears 
with a TTY switch persists.



On 07/07/16 17:21, Paride Legovini wrote:

Fixed in 2:2.99.917+git20160706-1, thank you!

The annoying "blink" on lightdm is also gone.
I can't find a Debian bug for it, but this was the issue:

https://bugs.launchpad.net/lightdm-gtk-greeter/+bug/1531224
https://bbs.archlinux.org/viewtopic.php?id=206657

Paride

Bug#830991: [PKG-OpenRC-Debian] Bug#830991: Summary of needed changes

[Benda Xu]

Hi Michael,

Michael Biebl  writes:

>> I agree that systemd-sysv version-conflict with openrc (<0.20.4-1).
>
> I chose 0.20.4-2.1, as this also contained the cleanup of the diversions
> from previous versions.
>
>> Do you have an estimated date for that?
>
> http://anonscm.debian.org/cgit/pkg-systemd/systemd.git/commit/?id=1ab8d4836dcca0485cd7b8307b2469c295584898
>
> Will be in the next upload of systemd. We don't have a date for that
> yet, but it should be soonish.

Great. Thanks!

>> This is the only reason to stop openrc from providing sysv-rc.  But
>> systemd-sysv in sid no longer depend on sysv-rc.  No need to do that
>> anymore, if we don't want to touch jessie.

> I think dropping that Provides is logically correct and should be done
> in any case, maybe not for stretch, but in sid for sure.

In the long run, yes. It was a hack as a drop-in replacement of sysv-rc.

> > >  plus depends on initscripts, to be safe and add Depends:
> > > initscripts
> > 
> > I don't think so.
> > 
> >   initscripts Depends: sysv-rc | file-rc
> > 
> > and openrc provides sysv-rc.  The dependence relation is already there.

> Ahem, no. It's the inverse dependency
> With initscripts no longer being installed by default, nothing will
> guarantee that initscripts will be installed. 

I can see sysvinit-core Depends: initscripts (>= 2.88dsf-13.3).

> If openrc depends on initscripts to boot a system successfully, it
> should depend on it.

Hmm, I think we can express the dependency chain as

 sysvinit-core -> sysv-rc/openrc -> initscripts

and drop sysvinit-core -> initscripts.

> > >  systemd-sysv: Make Conflicts against openrc versioned << y.z.
> > 
> > openrc (<<0.20.4-1) to be precise.
> > 
> > > Benda, if you push such changes, I'll sponsor the uploads.
> > 
> > In conclusion, the bugs are resolved if openrc Pre-Depends
> > init-system-helpers and systemd-sysv only conflicts with a older version
> > of OpenRC.

> The Pre-Depends and versioned Conflicts only address the failing dist
> upgrade (#829488).
> They don't address that the prioritoy of initscripts will be lowered for
> stretch and is no longer installed by default.

As stated above.

> The package description says "dependency based init system".

> If you want openrc to be treated as you say,i.e. not as an init, you
> should make that super-clear in the package description that installing
> openrc will *not* necessarily lead to a system booting with openrc.

> Otherwise it's highly confusing.

Good point and nice catch!

Thanks!
Benda


signature.asc
Description: PGP signature

Bug#831462: sbuild: requires gpg in chroot but does not install it

[Christian Hofstaedtler]

Package: sbuild
Version: 1.6.10-2

Dear sbuild Maintainer,

recently apt has stopped depending on gnupg; as such it is not
installed any more in the chroot created by sbuild-createchroot.

But then at build time, sbuild wants gpg to create the APT archive
and aborts.

Please consider installing gpg in sbuild-createchroot?

Thanks,
-- 
 ,''`.  Christian Hofstaedtler 
: :' :  Debian Developer
`. `'   7D1A CFFA D9E0 806C 9C4C  D392 5C13 D6DB 9305 2E03
  `-

Bug#831461: knot-resolver: please ship configuration documentation (e.g. daemon/README.rst, etc)

[Daniel Kahn Gillmor]

Package: knot-resolver
Version: 1.1.0~git2016071300-1
Severity: wishlist

knot-resolver source contains a lot of documentation about how to
configure the daemon and its various modules.  see all the README.*
files in the source.

Currently, the binary package ships very little of it, plus a few
example config files.

It would be great to ship the documentation, either in a separate -doc
package, or directly in the knot-resolver package itself.

 --dkg

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

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

Versions of packages knot-resolver depends on:
ii  dns-root-data2015052300+h+1
ii  init-system-helpers  1.36
ii  libc62.23-1
ii  libdnssec0   2.2.1-2
ii  libhiredis0.13   0.13.3-2
ii  libknot1 2.2.1-2
ii  liblmdb0 0.9.18-4
ii  libluajit-5.1-2  2.0.4+dfsg-1
ii  libmemcached11   1.0.18-4.1
ii  libmemcachedutil21.0.18-4.1
ii  libuv1   1.9.1-1
ii  libzscanner0 2.2.1-2
ii  lua-sec  0.5.1-1
ii  lua-socket   3.0~rc1+git+321c0c9-1

Versions of packages knot-resolver recommends:
pn  knot-resolver-module-http  

knot-resolver suggests no packages.

-- no debconf information

Bug#831463: libqt4-xml: Package 4:4.8.7+dfsg-8~bpo8+1 conflicts with k3b

[rpnpif]

Package: libqt4-xml
Version: 4:4.8.6+git64-g5dc8b2b+dfsg-3+deb8u1
Severity: important

Dear Maintainer,

When I wanted to upgrade to 4:4.8.7+dfsg-8~bpo8+1 from jessie-backports,
 k3b should be removed as requested by apt-get, but it is not what I want.

Please, make libqt4-xml compatible with k3b from jessie/main.

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

Kernel: Linux 4.6.0-0.bpo.1-amd64 (SMP w/2 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 libqt4-xml depends on:
ii  libc6  2.19-18+deb8u4
ii  libgcc11:4.9.2-10
ii  libqtcore4 4:4.8.6+git64-g5dc8b2b+dfsg-3+deb8u1
ii  libstdc++6 4.9.2-10
ii  multiarch-support  2.19-18+deb8u4

libqt4-xml recommends no packages.

libqt4-xml suggests no packages.

-- no debconf information

Bug#744301: systemd: [PATCH] Provide a kernel-install package and enable EFI support

[Martin Pitt]

Hello Julian,

Julian Andres Klode [2014-04-12 18:45 +0200]:
> systemd ships kernel-install which can be used to install kernels
> for boot loaders conforming to the boot loader spec, such as gummiboot,
> barebox, and potentially others I am not aware of.

Thanks for this work. We have neglected it for a while and the patches
became obsolete, sorry. But Lennart pinged me about this as he is
working on some mkosi scripts and would appreciate getting sd-boot to
work on Debian.

I now have this by and large working in

  http://anonscm.debian.org/cgit/pkg-systemd/systemd.git/log/?h=kernel-install

The branch does this:

 * Ship kernel-install (and install.d scripts, manpage) in systemd.

   Since the kernel-install scripts are so small (< 10 kB altogether)
   I think adding a new binary package for this is overkill. Fedora
   and arch just ship this in the systemd binary, and I think we want
   to do the same.

 * Add a kernel install.d script to copy the initrd. (Not sure why
   that isn't upstream, I'll ask)

 * A cheap patch to change /boot to /boot/efi. This is being fixed
   upstream in https://github.com/systemd/systemd/pull/3737 and
   there's the intention to do a corresponding auto-detection in
   bootctl, so we can lose this soon.

With that, you can now install sd-boot with:

   # kernel-install add `uname -r` /boot/vmlinuz-`uname -r`
   # bootctl install

Note that the latter will most probably fail because of
https://github.com/systemd/systemd/issues/3740 . At least it does for
my Debian testing EFI install. Just remove or rename
/boot/efi/EFI/Boot before calling bootctl to work around this.

I did *not* add a /etc/kernel/postinst.d/ hook for calling
kernel-install automatically, as this would create pointless copies of
the kernel and initrd in /boot/efi/ for every user.  I don't want to
advertise this much yet, as Debian's officially supported boot loader
is grub. But it should be good enough (once we find a fix for #3740)
for anyone who wants to play around with this and knows what they are
doing.

Thanks,

Martin

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


signature.asc
Description: PGP signature

Bug#831464: [munin-plugins-extra] spamstats: add debian-specific default configuration

[Lars Kruse]

Package: munin-plugins-extra
Version: 2.0.25-1
Severity: normal

--- Please enter the report below this line. ---

Dear maintainers,

I just tried to enable the spamstat plugin on my host with a local running
spamassassing daemon. 

In order to get the munin plugin running, I needed to add a configuration for
spamassassins default setup (at least for the Debian one):

 [spamstats]
 group adm
 env.logfile mail.log

Maybe the package munin-plugins-extra should deliver an additional plugin
configuration file (e.g. /etc/munin/plugin-conf.d/munin-plugins-extra) next to
the one delivered by munin-node? Or maybe the section above should be included
in the configuration file that is part of munin-node?

Thank you for your time!

Cheers,
Lars

Bug#830991: [PKG-OpenRC-Debian] Bug#830991: Summary of needed changes

[Michael Biebl]

Am 16.07.2016 um 14:28 schrieb Benda Xu:
> Michael Biebl  writes:

>>> This is the only reason to stop openrc from providing sysv-rc.  But
>>> systemd-sysv in sid no longer depend on sysv-rc.  No need to do that
>>> anymore, if we don't want to touch jessie.
> 
>> I think dropping that Provides is logically correct and should be done
>> in any case, maybe not for stretch, but in sid for sure.
> 
> In the long run, yes. It was a hack as a drop-in replacement of sysv-rc.

Ok, good we have agreement here.

  plus depends on initscripts, to be safe and add Depends:
 initscripts
>>>
>>> I don't think so.
>>>
>>>   initscripts Depends: sysv-rc | file-rc
>>>
>>> and openrc provides sysv-rc.  The dependence relation is already there.
> 
>> Ahem, no. It's the inverse dependency
>> With initscripts no longer being installed by default, nothing will
>> guarantee that initscripts will be installed. 
> 
> I can see sysvinit-core Depends: initscripts (>= 2.88dsf-13.3).

Sure. My point was, that installing openrc should lead to a system
booting with openrc as init. This was my premise.
And sysvinit-core depending on initscripts would therefor not help.

You made clear that this is *not* how you want openrc to be seen.

Afaics, you only want providers of /sbin/init to be treated as init
system. And only those packages need to make sure that the resulting
system is bootable. I acknowledge there is some logic in that.


>> If openrc depends on initscripts to boot a system successfully, it
>> should depend on it.
> 
> Hmm, I think we can express the dependency chain as
> 
>  sysvinit-core -> sysv-rc/openrc -> initscripts
> 
> and drop sysvinit-core -> initscripts.

Well, given your explanations about how you see the purpose of openrc, I
no longer think this change is needed.

So, with Benda's input here, I think what should happen is

a/ Add a Pre-Depends: init-system-helpers to openrc for #829488
b/ Make the Conflicts: openrc in systemd versioned, related to #829488,
as it avoids the switch to file-rc during the dist-upgrade
c1/ Drop the Provides: sysv-rc from openrc
c2/ Update initscripts and sysvinit-core and add openrc as an
alternative to sysv-rc | file-rc
d/ Clarify the openrc package description, make it clear that it is not
supposed to be an init system and that booting with openrc requires a
compatible /sbin/init to be installed.


Benda, is that a fair summary in your POV?

If so, we should probably merge #830991 and #831053 and retitle it,
asking for a clarification in the package description.

I think c/ is related to #829488 as well. systemd in jessie has a
Depends: sysv-rc, as this was supposed to ensure compatible
implementations of invoke-rc.d/update-rc.d are installed. That obviously
did not work out, due to openrc providing sysv-rc.

So I think, dropping Provides: sysv-rc should be done as part of
#829488. Or instead of merging #830991 and #831053 we repurpose one to
deal with Provides: sysv-rc.

Benda, any preferences?


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#831465: debhelper: tests for dh_installdocs

[Sven Joachim]

Source: debhelper
Version: 9.20160709
Severity: wishlist
Tags: patch

On 2016-07-09 11:54 +, Niels Thykier wrote:

> Sven Joachim:
>
>> It seems to me that dh_installdocs really needs a testsuite
>> for all the possible cases though.
>> 
>> Cheers,
>>Sven
>> 
>
> Indeed, I have been missing that for several debhelper tools.  It would
> need some infrastructure in place and probably have to be optional to
> keep build-depends minimal.

Here is a patch which adds a few build-time tests for dh_installdocs.
It catches the problems observed in #830309, but does not do much more.
Still, at least it's a start.

Cheers,
   Sven

>From 096142e8db595389d7ec1ff4da26448d3453fa77 Mon Sep 17 00:00:00 2001
From: Sven Joachim 
Date: Mon, 11 Jul 2016 18:12:54 +0200
Subject: [PATCH] Add some tests for for dh_installdocs

This is a small test suite for dh_installdocs, motivated by the problems
found in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=830309.  It
catches both the bug introduced in commit 71007f72da682dd9d7f932d81ca
and the regression caused by commit 863ef397c939340e863be1e96c822934a.

The tests verify that the correct /usr/share/doc symlinks and
directories are set up with and without the --link-doc option, in both
compat level 9 and 11.

Since dh_installdocs runs chown(1), the tests are skipped if run by an
ordinary user and fakeroot is unavailable.
---
 Makefile  |  2 +-
 t/dh_installdocs/debian/changelog |  5 +++
 t/dh_installdocs/debian/compat|  1 +
 t/dh_installdocs/debian/control   | 20 ++
 t/dh_installdocs/debian/docfile   |  1 +
 t/dh_installdocs/dh_installdocs.t | 78 +++
 6 files changed, 106 insertions(+), 1 deletion(-)
 create mode 100644 t/dh_installdocs/debian/changelog
 create mode 100644 t/dh_installdocs/debian/compat
 create mode 100644 t/dh_installdocs/debian/control
 create mode 100644 t/dh_installdocs/debian/docfile
 create mode 100755 t/dh_installdocs/dh_installdocs.t

diff --git a/Makefile b/Makefile
index 9c2e9f9..e27779b 100644
--- a/Makefile
+++ b/Makefile
@@ -101,6 +101,6 @@ install:
 	install -m 0644 Debian/Debhelper/Buildsystem/*.pm $(DESTDIR)$(PERLLIBDIR)/Buildsystem
 
 test: version
-	./run perl -MTest::Harness -e 'runtests grep { ! /CVS/ && ! /\.svn/ && -f && -x } @ARGV' t/* t/buildsystems/*
+	./run perl -MTest::Harness -e 'runtests grep { ! /CVS/ && ! /\.svn/ && -f && -x } @ARGV' t/* t/*/*
 	# clean up log etc
 	./run dh_clean
diff --git a/t/dh_installdocs/debian/changelog b/t/dh_installdocs/debian/changelog
new file mode 100644
index 000..5850f0e
--- /dev/null
+++ b/t/dh_installdocs/debian/changelog
@@ -0,0 +1,5 @@
+foo (1.0-1) unstable; urgency=low
+
+  * Initial release. (Closes: #XX)
+
+ -- Test   Mon, 11 Jul 2016 18:10:59 +0200
diff --git a/t/dh_installdocs/debian/compat b/t/dh_installdocs/debian/compat
new file mode 100644
index 000..ec63514
--- /dev/null
+++ b/t/dh_installdocs/debian/compat
@@ -0,0 +1 @@
+9
diff --git a/t/dh_installdocs/debian/control b/t/dh_installdocs/debian/control
new file mode 100644
index 000..48d4de2
--- /dev/null
+++ b/t/dh_installdocs/debian/control
@@ -0,0 +1,20 @@
+Source: foo
+Section: misc
+Priority: optional
+Maintainer: Test 
+Standards-Version: 3.9.8
+
+Package: foo
+Architecture: all
+Description: package foo
+ Package foo
+
+Package: bar
+Architecture: all
+Description: package bar
+ Package bar
+
+Package: baz
+Architecture: all
+Description: package baz
+ Package baz
diff --git a/t/dh_installdocs/debian/docfile b/t/dh_installdocs/debian/docfile
new file mode 100644
index 000..2719eec
--- /dev/null
+++ b/t/dh_installdocs/debian/docfile
@@ -0,0 +1 @@
+This file must not be empty, or dh_installdocs won't install it.
diff --git a/t/dh_installdocs/dh_installdocs.t b/t/dh_installdocs/dh_installdocs.t
new file mode 100755
index 000..2c7b381
--- /dev/null
+++ b/t/dh_installdocs/dh_installdocs.t
@@ -0,0 +1,78 @@
+#!/usr/bin/perl
+use strict;
+use Test::More;
+use File::Basename ();
+
+# Let the tests be run from anywhere, but current directory
+# is expected to be the one where this test lives in.
+chdir File::Basename::dirname($0) or die "Unable to chdir to ".File::Basename::dirname($0);
+
+my $TOPDIR = "../..";
+my $rootcmd;
+
+if ($< == 0) {
+	$rootcmd = '';
+}
+else {
+	system("fakeroot true 2>/dev/null");
+	$rootcmd = $? ? undef : 'fakeroot';
+}
+
+if (not defined($rootcmd)) {
+	plan skip_all => 'fakeroot required';
+}
+else {
+	plan(tests => 17);
+}
+
+system("rm -rf debian/foo debian/bar debian/baz");
+
+my $doc = "debian/docfile";
+
+system("$rootcmd $TOPDIR/dh_installdocs -pbar $doc");
+ok(-e "debian/bar/usr/share/doc/bar/docfile");
+system("rm -rf debian/foo debian/bar debian/baz");
+
+#regression in debhelper 9.20160709 (#830309)
+system("DH_COMPAT=11 $rootcmd $TOPDIR/dh_installdocs -pbar $doc");
+ok(-e "debian/bar/usr/share/doc/foo/docfile");
+system("rm -rf debian/foo debian/bar debian/baz");
+
+#regression in debhelper

Bug#811670: FTBFS with GCC 6: cannot convert x to y

[Jonas Smedegaard]

Quoting Andreas Steigmiller (2016-07-16 12:55:04)
> Our development is currently done with a non-public version control 
> system (in order to easily manage non-public test ontologies).

Fair enough.

I will look forward to your upcoming release :-)

 - 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#831466: systemd: please make IPv6 user space code run time configurable

[Marc Haber]

Package: systemd
Version: 230-5pitti1
Severity: important

Dear Maintainer,

since a few months, systemd upstream tries to implement parts of IPv6
inside systemd/networkd while we have perfectly working code inside
the Linux kernel. Unfortunately, the systemd code is wrong in so many
places that it literally takes days to diagnose the new
misbehavior-of-the-day, making it necessary to build complex test labs
or to break existing productive systems just to find out what is wrong
in systemd's IPv6 code this week.

Nevertheless, upstream has decided to make this new code mandatory,
making it necessary for distributions to derive patches to disable the
misbehavior. This takes, again, valuable developer time.

Please convince upstream to implement a run-time switch to revert to
the kernel IPv6 code just in case a system actually needs working
IPv6. It would be so much easier to help upstream to develop reliable
code if switching back and forth between kernel and user space code
was not so damn hard.

Greetings
Marc

Bug#831467: transmission-daemon: Should the daemon have a systemd ExecStop= command

[Ritesh Raj Sarraf]

Package: transmission-daemon
Version: 2.84-3.1
Severity: normal

When I look at the status of the transmission-daemon service after a
"Stop", the status is not clean. I then checked into the .service file
and noticed that it doesn't have any directive for ExecStop.

Should there be one ?
The actual problem I have is is that the torrents eventually get into
the paused state. Now, there's nothing in the kernel logs about a bad
file system. The only odd log I see is from the transmission-daemon
service.


rrs@chutzpah:~/Community/Packaging/user-mode-linux (master)$ sudo systemctl 
status transmission-daemon
_ transmission-daemon.service - Transmission BitTorrent Daemon
   Loaded: loaded (/lib/systemd/system/transmission-daemon.service; enabled; 
vendor preset: enabled)
   Active: failed (Result: signal) since Sat 2016-07-16 18:14:42 IST; 1s ago
 Main PID: 3145 (code=killed, signal=SEGV)
   Status: "Closing transmission session..."

Jul 16 18:14:37 chutzpah systemd[1]: Stopping Transmission BitTorrent Daemon...
Jul 16 18:14:42 chutzpah systemd[1]: transmission-daemon.service: Main process 
exited, code=killed, status=11/SEGV
Jul 16 18:14:42 chutzpah systemd[1]: Stopped Transmission BitTorrent Daemon.
Jul 16 18:14:42 chutzpah systemd[1]: transmission-daemon.service: Unit entered 
failed state.
Jul 16 18:14:42 chutzpah systemd[1]: transmission-daemon.service: Failed with 
result 'signal'.

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

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

Versions of packages transmission-daemon depends on:
ii  adduser  3.115
ii  init-system-helpers  1.39
ii  libc62.23-1
ii  libcurl3-gnutls  7.47.0-1
ii  libevent-2.0-5   2.0.21-stable-2+b1
ii  libminiupnpc10   1.9.20140610-2.1
ii  libnatpmp1   20110808-4
ii  libssl1.0.2  1.0.2h-1
ii  libsystemd0  230-7
ii  lsb-base 9.20160629
ii  transmission-common  2.84-3.1
ii  zlib1g   1:1.2.8.dfsg-2+b1

Versions of packages transmission-daemon recommends:
ii  transmission-cli  2.84-3.1

transmission-daemon suggests no packages.

-- Configuration Files:
/etc/transmission-daemon/settings.json [Errno 13] Permission denied: 
u'/etc/transmission-daemon/settings.json'

-- no debconf information

Bug#815506: dh_install: not-installed requires debian/tmp/ prefix

[Sven Joachim]

On 2016-02-21 23:12 +0100, Felix Geyer wrote:

> Package: debhelper
> Version: 9.20160115
> Severity: normal
>
> Hi,
>
> Contrary to *.install files the lines in debian/not-installed require a
> debian/tmp/ prefix.
>
> For example this d/not-installed file doesn't work:
> usr/bin/passenger-install-nginx-module
>
> While this works:
> debian/tmp/usr/bin/passenger-install-nginx-module
>
> This seems unnecessary and is not documented.
> It would be great if dh_install could add the prefix automatically.

Something like this should do the trick (lightly tested):

--8<---cut here---start->8---
diff --git a/dh_install b/dh_install
index f7d5739..d7e849b 100755
--- a/dh_install
+++ b/dh_install
@@ -262,8 +262,12 @@ if ($dh{LIST_MISSING} || $dh{FAIL_MISSING}) {

my @missing;
if ( -f 'debian/not-installed') {
+   my @not_installed = filearray('debian/not-installed');
+   foreach (@not_installed) {
+ s:^\s*:debian/tmp/: unless m:\s*debian/tmp/:;
+   }
# Pretend that these are also installed.
-   push(@installed, filearray('debian/not-installed'));
+   push(@installed, @not_installed);
}
my $installed=join("|", map {
# Kill any extra slashes, for robustness.
--8<---cut here---end--->8---

Maybe there's a better way to achieve this goal, I'm not really a
debhelper or perl guru.

Cheers,
   Sven

Bug#627961: inkscape: rasterizing effects when exporting from the commandline

[Mattia Rizzolo]

control: tag -1 moreinfo unreproducible

As upstream wrote in the forwarded bug report 2 years ago:

> > Version: 0.48.1-2
> >
> > when exporting from the commandline to pdf, ps or eps it seems not to
> > be possible to select to raster effects (…)
> 
> Not reproduced with Inkscape 0.48.1 and current stable (Inkscape 0.48.3.1)
> using a simple test file with a blurred circle:
> command line export to PDF always exports filter effects rasterized
> unless explicitly disabled with '--export-ignore-filters', as described
> in the man page and in the release notes about the initial implementation
> of cairo-based exports to PDF/PS/EPS [1]. With the simple test case, the
> object from the SVG file is present in the PDF file with both export
> methods (GUI, command line).
> 
> > (…) but instead the effected objects are just left out from the export
> 
> The identical file, with exactly the same export options as used in the
> GUI? Odd. If objects are missing completely in the generated PDF, this
> is very likely not a failure of exporting via command line (as opposed
> to using the GUI), but due to hitting a memory limitation while
> generating huge bitmaps in memory during the export (see bug #494115).
> 
> Could you please attach a sample file which triggered the reported issue,
> to allow further investigation?
> 
> [1] 
> 


furthermore, a lot changed from 0.48.x to 0.91.x, do you mind retesting?

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#830978: Browserified javascript and DFSG 2

[Ian Jackson]

Sam Hartman writes ("Re: Bug#830978: Browserified javascript and DFSG 2"):
> [stuff]

There is much that you've said that I don't necessarily disagree with,
but:

> Part of having good governance is to have those discussions on devel.

The problem isn't having the discussion.

The problem is that we keep having the discussion again and again.
The same people rehearse the same points.  Over and over.

This is a terrible pattern in our community, because it invites the
more functional people to disengage.  They leave -devel, or kill these
threads, because they want to get something useful done.

That leaves the less functional to dominate the discourse.  Eventually
we end up with situations where the apparent public discourse elides
large sections of the community, or is even substantially at variance
with the consensus view of the project as a whole.

> The TC isn't going to be able to add anything here.  We have similar
> biases to the ftp team.  We deal with licenses less often, so they are
> probably even more aware of the issues than we are.
> Having two teams say the same thing isn't going to shut up anyone on
> devel frustrated that we're insisting they do significantly more work.

"Adding" does not necessarily mean disagreeing.  If the TC agrees with
ftpmaster, the TC can still help.

The TC can communicate the status quo more clearly, and provide it
with more legitimacy.  The TC members are focused on communication.
TC members are (or should be) able to reason and write exceptionally
clearly.  The TC has an established mechanism by which it can debate
an issue, vote on it, and publish a clear an authoritative statement
of the collective view.

Now I agree that it would be nice if ftpmaster were better at these
things, but ftpmaster have lots of other things to do besides clear up
these kind of disputes.

Specifically, Pirate has acknowledged the authority of the TC by
asking the TC to intervene.  I think it is possibly even rather
disrespectful to Pirate to suggest that if the TC formally disagrees
with them, they'll continue their campaign on -devel as before.

Absent a radical change in the ftpmaster team's approach to
communicating these kind of decisions, the only other way we are going
to settle this is a GR.

To put it another way: could you (the TC) please at least _try_ to
help ?  If it doesn't work then little harm is done.

Ian.

Bug#830978: Browserified javascript and DFSG 2

[Neil Williams]

On Sat, 16 Jul 2016 06:49:56 -0400
Sam Hartman  wrote:

> > "Neil" == Neil Williams  writes:  
> >> > * The point of having the source code (with an appropriate  
> >> licence > etc.) is so that all our contributors, downstreams,
> >> and users are > able to modify the code and to share their
> >> modifications with each > other, with Debian, and with
> >> upstream.
> >> 
> >> I agree this is an important consideration, but not serious
> >> enough to reject a package.  
> 
> Neil> So you consider that upstream are not fully-qualified users
> Neil> somehow and therefore do not get the benefits of the DFSG?
> Neil> If the freedoms of users who choose to interact with
> Neil> upstream are reduced by choices made within the package
> Neil> then the package is breaking the DFSG by penalising a field
> Neil> of endeavour.  
> 
> Neil, I have a fairly strong negative emotional reaction when I read
> the paragraph you wrote.  I'd like to share that because I think if I
> share where I'm coming from it will be easier for me to hear you, and
> easier to participate calmly.
> 
> When I read the above, I'm worried because I think that freedoms I
> care about would be limited, and I don't like to see the DFSG
> reshaped to limit freedoms.
> I'm afraid when I think I hear us seeding the contents of Debian to
> upstream.  We are Debian; we choose what Debian is.
> 
> I want to stress that I think you and I are in agreement on
> handlebars.
> 
> However, I do think the freedom to fork from upstream, to move away
> from upstream practices we disagree with is important.

Absolutely - I think it depends on the upstreams we've each experienced
over time. I have been part of or become the entirety of upstream in
nearly all the packages which I've packaged for Debian and it has
always been friendly. Never a need for a fork, I started to contribute
and shortly afterwards got asked to take over upstream...

So I tend to have a more upstream approach than some other DD's, yet I
haven't needed to fork anything - I just got handed it and told to go
ahead! (It also means I rarely have anything in debian/patches...)
 
> I also think that the freedom to "free," over time software even in
> cases where upstream has a non-free source control system, or where
> we're having to build up a new form of source code because of
> restrictions on what's currently the source code are important.
> 
> I do not agree that being an upstream is a field of endeavour.
> 
> I do not agree that we must always use the same source code form that
> upstream does.  Sometimes upstream is wrong.  Sometimes there are
> multiple upstreams.
> Sometimes we want to fork.

Sometimes we do, yes, and we need to retain that ability. However, that
is actually rare. More often, we are interacting with upstream or
supporting users who want to contribute to upstream themselves.
 
> We do however need to ship the source code we use whatever that is.
> It needs to really be source code.  It needs to be a reasonable form
> in which we would choose to make modifications.  If there are other
> plausible source forms that are being used (even if some of them are
> non-free), and those source forms would make the modifications easier,
> that's a strong argument that the software is probably not free as we
> propose to ship it.
> 
> I do not wish us to make the upstream form of source so special that
> we in our best judgment cannot override it.

OK, I didn't mean that we cannot diverge from upstream ever, just that
the majority of the time we are trying to work with upstream rather
than reaching immediately for a fork. Our decisions should make this
collaboration easy, without denying the possibility of the rather blunt
instrument of forking the package.

Part of this collaboration may involve educating upstream about the
problems of distributing their code. This can include source code
freedom issues, it can include software architecture (lack of stable
APIs preventing a large codebase with plugins being separated out) and
it can include portability issues with assumptions in their code which
don't work on all our architectures. Fixing these things requires a
positive attitude to upstream with few structural barriers.

> I do hear your worry that you want to be able to exchange
> modifications with upstream.  Without modifications, without free
> flow of those modifications, software is not free.  I ask that we
> have the flexibility to reject people who aren't actually shipping
> source they would use to modify software while accepting people who
> legitimately disagree about what the source form is.

Agreed.

-- 


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



pgpzZ74AW2AVU.pgp
Description: OpenPGP digital signature

Bug#827733: Better manage /sbin/init by busybox

[Benda Xu]

Hi Jon,

Very interesting patch!

A package busybox-init, similar to busybox-syslogd, makes more sense to
me.  It can be made openrc-neutral.

The Debian openrc package is a drop-in replacement to sysv-rc, the
latter provides /etc/init.d/rc and /etc/init.d/rcS.  OpenRC follows this
convention so that /etc/inittab (of sysvinit) is not needed to be
updated.

It is also desirable to run busybox-init + sysv-rc or busybox-init +
file-rc.  It can be achieved if the /etc/inittab of busybox-init is
written as that in the appendix.


@debian-boot team, do you think such a busybox-init package feasible?  If
so I am going to reassign this bug to src:busybox.

Yours,
Benda

Appendix: busybox-inittab

::sysinit:/etc/init.d/rcS
::wait:/etc/init.d/rc 2
::shutdown:/etc/init.d/rc 0

# What to do when CTRL-ALT-DEL is pressed.
::ctrlaltdel:/etc/init.d/rc 6

# /sbin/getty invocations for the runlevels.
#
::respawn:/sbin/getty 38400 tty1
::respawn:/sbin/getty 38400 tty2
::respawn:/sbin/getty 38400 tty3
::respawn:/sbin/getty 38400 tty4
::respawn:/sbin/getty 38400 tty5
::respawn:/sbin/getty 38400 tty6

# Example how to put a getty on a serial line (for a terminal)
#
#::respawn:/sbin/getty -L ttyS0 9600 vt100
#::respawn:/sbin/getty -L ttyS1 9600 vt100

# Example how to put a getty on a modem line.
#
#::respawn:/sbin/mgetty -x0 -s 57600 ttyS3

Bug#824779: container getty-static.service causes lxcfs high cpu usage

[Martin Pitt]

Control: tag -1 pending

Wang Jian [2016-05-19 23:59 +0800]:
> getty-static.service starts getty on tty2-6, but container has only 4
> ttys (1-4) at default. getty will exit and be respawned for tty5-tty6.
> This leads to high cpu usage on host's lxcfs daemon.
> 

There is no point in even wasting four getty processes on tty1-4 in
LXC -- containers are not meant to have gettys on ttys in the first
place. I committed a fix to git for that.
(ConditionVirtualization=!container)

Thanks,

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

Bug#831468: base: Can not start graphical programs after changing user language from settings

[MrBump]

Package: base
Severity: important

Dear Maintainer,

After changing the user locale or language to spanish, cannot start any 
graphical interface. It did not ask
to download the proper packages.

~$ gnome-terminal

(process:1943): Gtk-WARNING **: Locale not supported by C library.
Using the fallback 'C' locale.
Error constructing proxy for org.gnome.Terminal:/org/gnome/Terminal/Factory0: 
Error calling StartServiceByName for org.gnome.Terminal: 
GDBus.Error:org.freedesktop.DBus.Error.Spawn.ChildExited: Process 
org.gnome.Terminal exited with status 8


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


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

Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=es_ES.utf8, LC_CTYPE=es_ES.utf8 (charmap=locale: Cannot set 
LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#831470: gdb manual: missing documentation of the -tui option

[Paul Wise]

Package: gdb-doc
Version: 7.11.1-1
Severity: normal
File: /usr/share/man/man1/gdb.1.gz

The manual page is missing documentation of the -tui option:

https://sourceware.org/gdb/onlinedocs/gdb/TUI.html

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

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

-- no debconf information

-- 

bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#831469: brp-pacu has a new version

[Herbert Parentes Fortes Neto]

Source: brp-pacu
Severity: normal

Dear Maintainer,

brp-acu seems to have a new version - 2.1.2.

[0] - https://sourceforge.net/projects/brp-pacu/files/brp-pacu-v2-any/2.1.2/

I do not use it. An email telling that brp-pacu
is marked for autoremovel was sent and I decide to do a QA. So I
checked sf.net.

The autoremove was because of fftw (deps). But fftw
is already fixed.



regards,
Herbert


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

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

Bug#718937: uploaded to archive

[Marcelo Jorge Vieira]

Hi Pirate Praveen,

On Mon, 2016-07-11 at 13:58 +0530, Pirate Praveen wrote:
> I have uploaded 3.3.4 to unstable (in NEW).
> 
> Even though I'm a member of pkg-javascript team, I was not able to
> push
> the changes
> 
> I pushed it to https://git.fosscommunity.in/praveen/underscore.string


I've fixed the repository permissions, please try again.


Cheers,

-- 

Marcelo Jorge Vieira
xmpp:me...@jabber-br.org
http://metaldot.alucinados.com

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

Bug#830991: [PKG-OpenRC-Debian] Bug#830991: Summary of needed changes

[Benda Xu]

Hi Michael,

Very nice wrap-up.  Thank you!

Michael Biebl  writes:

>> I can see sysvinit-core Depends: initscripts (>= 2.88dsf-13.3).
>
> Sure. My point was, that installing openrc should lead to a system
> booting with openrc as init. This was my premise.
> And sysvinit-core depending on initscripts would therefor not help.
>
> You made clear that this is *not* how you want openrc to be seen.
>
> Afaics, you only want providers of /sbin/init to be treated as init
> system. And only those packages need to make sure that the resulting
> system is bootable. I acknowledge there is some logic in that.
>
>
>>> If openrc depends on initscripts to boot a system successfully, it
>>> should depend on it.
>> 
>> Hmm, I think we can express the dependency chain as
>> 
>>  sysvinit-core -> sysv-rc/openrc -> initscripts
>>
>> and drop sysvinit-core -> initscripts.

On a second thought, this is not optimal.  We'd better do

  sysvinit-core -> initscripts -> sysv-rc/openrc

> Well, given your explanations about how you see the purpose of openrc, I
> no longer think this change is needed.

FYI, I am planning to introduce openrc-native initscripts packaged as
"openrc-initscripts" as an alternative to initscripts.  Also in bug
827733, we will have busybox-init in the future. All the following
systems are valid to boot:

  sysvinit-core | busybox-init -> initscripts -> sysv-rc | file-rc | openrc
  sysvinit-core | busybox-init -> openrc-initscripts -> openrc

> So, with Benda's input here, I think what should happen is
>
> a/ Add a Pre-Depends: init-system-helpers to openrc for #829488

Done in openrc package git repo.

> b/ Make the Conflicts: openrc in systemd versioned, related to #829488,
> as it avoids the switch to file-rc during the dist-upgrade

Done in systemd package git repo.

> c1/ Drop the Provides: sysv-rc from openrc

Yes, but c2 should happen first.

> c2/ Update initscripts and sysvinit-core and add openrc as an
> alternative to sysv-rc | file-rc

> d/ Clarify the openrc package description, make it clear that it is not
> supposed to be an init system and that booting with openrc requires a
> compatible /sbin/init to be installed.

Done in openrc package git repo.

> Benda, is that a fair summary in your POV?

Yes, we are reaching consensus here.

> we should probably merge #830991 and #831053 and retitle it, asking
> for a clarification in the package description.

Yeah!

> I think c/ is related to #829488 as well. systemd in jessie has a
> Depends: sysv-rc, as this was supposed to ensure compatible
> implementations of invoke-rc.d/update-rc.d are installed. That obviously
> did not work out, due to openrc providing sysv-rc.
>
> So I think, dropping Provides: sysv-rc should be done as part of
> #829488. Or instead of merging #830991 and #831053 we repurpose one to
> deal with Provides: sysv-rc.
>
> Benda, any preferences?

I prefer the former.

Cool.  I can sense an ultimate resolution around the corner.
Benda


signature.asc
Description: PGP signature

Bug#831492: keepass2: Virus scanner detects Mal/Generic-S in /usr/lib/keepass2/KeePass.exe

[Joerg]

Package: keepass2
Version: 2.34+dfsg-1
Severity: normal

Dear Maintainer,

the installed virus scanner claims the software is affected, see
https://virustotal.com/en/file/a598c3f80598eb6828e1d163aed22fb263e328a144b3c0bbab9fe9ac94799693/analysis/1468677287/

It's the same result when downloading the deb file from mirror
(http://ftp.de.debian.org/debian/pool/main/k/keepass2/keepass2_2.34+dfsg-1_all.deb)
ar x keepass2_2.34+dfsg-1_all.deb
tar xfJ data.tar.xz

The image fetched from sourceforge mirror
http://downloads.sourceforge.net/project/keepass/KeePass%202.x/2.34/KeePass-2.34.zip?r=http%3A%2F%2Fkeepass.info%2Fdownload.html&ts=1468677831&use_mirror=jaist
seems to be clean (at least the virus scanner doesn't complain)
Virus Total marks it as OK also:
https://virustotal.com/en/file/a6e929cf62d9ce3a7e1909b64829a678c60bc94fad4fdaa0178d28fc932f722b/analysis/

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

Kernel: Linux 4.5.0-2-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)

Versions of packages keepass2 depends on:
ii  libmono-corlib4.5-cil4.2.1.102+dfsg2-8
ii  libmono-system-drawing4.0-cil4.2.1.102+dfsg2-8
ii  libmono-system-security4.0-cil   4.2.1.102+dfsg2-8
ii  libmono-system-windows-forms4.0-cil  4.2.1.102+dfsg2-8
ii  libmono-system-xml4.0-cil4.2.1.102+dfsg2-8
ii  libmono-system4.0-cil4.2.1.102+dfsg2-8
ii  libx11-6 2:1.6.3-1
ii  mono-runtime 4.2.1.102+dfsg2-8

Versions of packages keepass2 recommends:
pn  xsel  

Versions of packages keepass2 suggests:
pn  keepass2-doc  
pn  mono-dmcs 
pn  xdotool   

-- no debconf information

Bug#831493: O: aptsh -- apt interactive shell

[Tobias Frost]

Package: wnpp
Severity: normal

The current maintainer of aptsh, Marcin Wrochniak ,
is apparently not active anymore.  Therefore, I orphan this package now.

Maintaining a package requires time and skills. Please only adopt this
package if you will have enough time and attention to work on it.

If you want to be the new maintainer, please see
https://www.debian.org/devel/wnpp/index.html#howto-o for detailed
instructions how to adopt a package properly.

Some information about this package:

Package: aptsh
Binary: aptsh
Version: 0.0.7+nmu2
Maintainer: Marcin Wrochniak 
Build-Depends: debhelper (>= 4.0.0), libreadline-gplv2-dev, libapt-pkg-dev (>= 
0.5.28.6)
Architecture: any
Standards-Version: 3.7.2.2
Format: 1.0
Files:
 51cb3978a31eb0258219db61ffe81f90 770 aptsh_0.0.7+nmu2.dsc
 139ce1d1d9836cbad85ab00227fc9ab9 142481 aptsh_0.0.7+nmu2.tar.gz
Checksums-Sha256:
 170a598b878da1d3cfa687d09dad3841b48d83995a130678f50b9184ea99b7af 770 
aptsh_0.0.7+nmu2.dsc
 9a844e9f8fb342303bee62dc51dfd19abc84ff213a481e657e2305378dd3b05a 142481 
aptsh_0.0.7+nmu2.tar.gz
Directory: pool/main/a/aptsh
Priority: source
Section: admin

Package: aptsh
Source: aptsh (0.0.7+nmu2)
Version: 0.0.7+nmu2+b3
Installed-Size: 147
Maintainer: Marcin Wrochniak 
Architecture: amd64
Depends: libapt-pkg5.0 (>= 1.1~exp4), libc6 (>= 2.14), libgcc1 (>= 1:4.1.1), 
libreadline5 (>= 5.2), libstdc++6 (>= 5.2)
Description-en: apt interactive shell
 Aptsh helps in managing packages by providing nice pseudo-shell,
 with commands completion and simplified access to Apt's commands.
 Additional features, like command-queue and orphaned packages
 searcher are also included.
Description-md5: ed5977f655a6cd7b96919ada35f290fc
Tag: admin::package-management, interface::commandline, interface::shell,
 protocol::http, role::program, scope::utility, suite::debian,
 use::downloading, works-with::software:package
Section: admin
Priority: optional
Filename: pool/main/a/aptsh/aptsh_0.0.7+nmu2+b3_amd64.deb
Size: 49526
MD5sum: a986044051da7c4214b19788d456dc3c
SHA256: f153f08d23ecd9e2841a02a134bd5ffa0d26c7591840336e1bc73f0debf134ad



signature.asc
Description: PGP signature

Bug#830985: tulip: error while loading shared libraries: libbfd-2.26-system.so

[ydirson]

Well, I have never really felt libbfd.so-linking rejection from the project 
before,
as tulip has undergone numerous binNMU's to keep pace with libbfd.

Furthermore, the fact that the .so link is installed whenever bfd.h is installed
rather calls for linking against the shared lib.  If we want to provide them for
convenience to use cases which can't really do without, then I feel they ought 
to be
split in a separate deb, right ?

- Mail original -
> De: "Helmut Grohne" 
> À: "Yuri D'Elia" , 830...@bugs.debian.org
> Cc: "Matthias Klose" 
> Envoyé: Vendredi 15 Juillet 2016 00:11:31
> Objet: Bug#830985: tulip: error while loading shared libraries: 
> libbfd-2.26-system.so
> 
> Control: severity -1 grave
> 
> On Wed, Jul 13, 2016 at 04:49:40PM +0200, Yuri D'Elia wrote:
> > Seems like tulip depends on libbfd-2.26-system.so, but only
> > libbfd-2.26-system.so.1 is available on my system.
> 
> Linking libbfd dynamically is explicitly disallowed (see package
> description of binutils-dev). Please do not close this bug without
> removing the dynamic linking entirely. If you link libbfd statically,
> please ensure to add an appropriate Built-Using header.
> 
> Helmut
> 

Bug#811497: marked as done (Unclean shutdown after switch from sysvinit-core to systemd-sysv)

[Martin Pitt]

Debian Bug Tracking System [2016-07-16 14:09 +]:
> We could start "telinit u" as part of the switch from sysvinit-core to
> systemd. That will replace the running sysvinit with systemd, which is
> pretty scary though.

I accidentally ran into this in Ubuntu when a running upstart was
replaced in-place with systemd due to a bug in upstart. The result was
broken beyond repair. So indeed, let's not do this :-)

Thus closing is fine, or reassigning to systemd-shim.

Martin

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


signature.asc
Description: PGP signature

Bug#831465: [debhelper-devel] Bug#831465: debhelper: tests for dh_installdocs

[Niels Thykier]

Sven Joachim:
> Source: debhelper
> Version: 9.20160709
> Severity: wishlist
> Tags: patch
> 
> On 2016-07-09 11:54 +, Niels Thykier wrote:
> [...]
> 
> Here is a patch which adds a few build-time tests for dh_installdocs.
> It catches the problems observed in #830309, but does not do much more.
> Still, at least it's a start.
> 
> Cheers,
>Sven
> 
> 
> [...]

Excellent! :) I have applied this to master!

Thanks, it is very appreciated.  :)

~Niels