Bug#873832:

[Arturo Borrero Gonzalez]

Control: tags -1 pending

Thanks, I did the change and is now pending:

https://anonscm.debian.org/cgit/pkg-suricata/pkg-suricata.git/commit/?id=93ee9030a53a45c800ad5879c4e7c754c1dc1331

Bug#873508: sparse test failures on ppc32le (and other not so common archs)

[Josh Triplett]

On Thu, Aug 31, 2017 at 08:47:55PM -0400, Christopher Li wrote:
> On Thu, Aug 31, 2017 at 4:55 PM, Uwe Kleine-König  Yes
> that works. So to address the Debian bug I can do:
> >
> >  - move sparse to /usr/lib
> >  - teach cgcc about the move of sparse
> >  - make /usr/bin/sparse call cgcc -no-compile "$@"
> 
> I don't like that. It means the user can't invoke sparse directly.
> 
> >
> > or is it easier to teach sparse about the architecture stuff?
> 
> First of all. It is not very trivial to teach sparse about the architecture
> stuff. To my mind, we need to move all the cgcc logic into sparse.

Related to that: while it would mean we couldn't necessarily just rely
entirely on GCC's definitions for a target platform, I think in an ideal
world we could have a sparse binary that understood *all* target
platforms at once, such that you could ask Sparse on x86_64 to "compile"
as though targeting any arbitrary architecture. That would also have the
major advantage of making it easy to run the Sparse testsuite for
*every* target architecture without needing compilers for every such
architecture.

Bug#873913: firebird3.0-server-core: adequate reports broken symlinks for databases.conf and fbtrace.conf

[shirish शिरीष]

Package: firebird3.0-server-core
Version: 3.0.2.32703.ds4-9
Severity: normal

Dear Maintainer,

Thank you for maintaining firebird. While I was upgrading one of my
systems, noticed that adequate was sharing/telling about broken
symlinks as below -

$ adequate firebird3.0-server-core

firebird3.0-server-core:amd64: broken-symlink
/usr/lib/x86_64-linux-gnu/firebird/3.0/databases.conf ->
/etc/firebird/3.0/databases.conf
firebird3.0-server-core:amd64: broken-symlink
/usr/lib/x86_64-linux-gnu/firebird/3.0/fbtrace.conf ->
/etc/firebird/3.0/fbtrace.conf

Please fix the same.

-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (990, 'testing'), (100, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

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

Versions of packages firebird3.0-server-core depends on:
ii  firebird3.0-common  3.0.2.32703.ds4-9
ii  firebird3.0-common-doc  3.0.2.32703.ds4-9
ii  libc6   2.24-12
ii  libfbclient23.0.2.32703.ds4-9
ii  libgcc1 1:7.2.0-1
ii  libib-util  3.0.2.32703.ds4-9
ii  libicu5757.1-6
ii  libncurses5 6.0+20170715-2
ii  libstdc++6  7.2.0-1
ii  libtinfo5   6.0+20170715-2
ii  libtommath1 1.0-4

Versions of packages firebird3.0-server-core recommends:
ii  firebird3.0-utils  3.0.2.32703.ds4-9

Versions of packages firebird3.0-server-core suggests:
pn  firebird3.0-server  

-- no debconf information

-- 
  Regards,
  Shirish Agarwal  शिरीष अग्रवाल
  My quotes in this email licensed under CC 3.0
http://creativecommons.org/licenses/by-nc/3.0/
http://flossexperiences.wordpress.com
EB80 462B 08E1 A0DE A73A  2C2F 9F3D C7A4 E1C4 D2D8

Bug#873914: doc: apt-get manpage mentions '--allow-releaseinfo-changes' instead of '--allow-releaseinfo-change'

[Christos Trochalakis]

Package: apt
Version: 1.5~rc1
Severity: normal
Tags: patch

There is a typo in apt-get manpage mentioning '--allow-releaseinfo-changes-*'
instead of '--allow-releaseinfo-changes-*', I am attaching a patch that
replaces all occurrences.



>From b2c62b51cd9f78fce156b97d0a1e859199842fc9 Mon Sep 17 00:00:00 2001
From: Christos Trochalakis 
Date: Fri, 1 Sep 2017 10:20:18 +0300
Subject: [PATCH] doc: correct '--allow-releaseinfo-change-*' typos

---
 doc/apt-get.8.xml  | 4 ++--
 doc/po/apt-doc.pot | 2 +-
 doc/po/de.po   | 2 +-
 doc/po/es.po   | 2 +-
 doc/po/fr.po   | 2 +-
 doc/po/it.po   | 2 +-
 doc/po/ja.po   | 2 +-
 doc/po/nl.po   | 2 +-
 doc/po/pl.po   | 2 +-
 doc/po/pt.po   | 2 +-
 doc/po/pt_BR.po| 2 +-
 11 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/doc/apt-get.8.xml b/doc/apt-get.8.xml
index c9c876dfd..cc4159fdf 100644
--- a/doc/apt-get.8.xml
+++ b/doc/apt-get.8.xml
@@ -579,7 +579,7 @@
  Configuration Item: Acquire::AllowInsecureRepositories.
  
 
- --allow-releaseinfo-changes
+ --allow-releaseinfo-change
  Allow the update command to continue downloading
  data from a repository which changed its information of the release
  contained in the repository indicating e.g a new major release.
@@ -588,7 +588,7 @@
  See also &apt-secure; for details on the concept and configuration.
  
  Specialist options
- (--allow-releaseinfo-changes-field)
+ (--allow-releaseinfo-change-field)
  exist to allow changes only for certain fields like origin,
  label, codename, suite,
  version and defaultpin. See also &apt-preferences;.
diff --git a/doc/po/apt-doc.pot b/doc/po/apt-doc.pot
index 88b3ee327..a1dfb814e 100644
--- a/doc/po/apt-doc.pot
+++ b/doc/po/apt-doc.pot
@@ -1427,7 +1427,7 @@ msgstr ""
 #: apt-get.8.xml:1
 msgid ""
 "Specialist options "
-"(--allow-releaseinfo-changes-field)  "
+"(--allow-releaseinfo-change-field)  "
 "exist to allow changes only for certain fields like "
 "origin, label, "
 "codename, suite, "
diff --git a/doc/po/de.po b/doc/po/de.po
index 7cfdd3386..d0033eb2c 100644
--- a/doc/po/de.po
+++ b/doc/po/de.po
@@ -2001,7 +2001,7 @@ msgstr ""
 #. type: Content of: 
 #: apt-get.8.xml
 msgid ""
-"Specialist options (--allow-releaseinfo-changes---allow-releaseinfo-change-field)  exist to allow changes only for "
 "certain fields like origin, label, "
 "codename, suite, version
 #: apt-get.8.xml
 msgid ""
-"Specialist options (--allow-releaseinfo-changes---allow-releaseinfo-change-field)  exist to allow changes only for "
 "certain fields like origin, label, "
 "codename, suite, version
 #: apt-get.8.xml
 msgid ""
-"Specialist options (--allow-releaseinfo-changes---allow-releaseinfo-change-field)  exist to allow changes only for "
 "certain fields like origin, label, "
 "codename, suite, version
 #: apt-get.8.xml
 msgid ""
-"Specialist options (--allow-releaseinfo-changes---allow-releaseinfo-change-field)  exist to allow changes only for "
 "certain fields like origin, label, "
 "codename, suite, version
 #: apt-get.8.xml
 msgid ""
-"Specialist options (--allow-releaseinfo-changes---allow-releaseinfo-change-field)  exist to allow changes only for "
 "certain fields like origin, label, "
 "codename, suite, version
 #: apt-get.8.xml
 msgid ""
-"Specialist options (--allow-releaseinfo-changes---allow-releaseinfo-change-field)  exist to allow changes only for "
 "certain fields like origin, label, "
 "codename, suite, version
 #: apt-get.8.xml
 msgid ""
-"Specialist options (--allow-releaseinfo-changes---allow-releaseinfo-change-field)  exist to allow changes only for "
 "certain fields like origin, label, "
 "codename, suite, version
 #: apt-get.8.xml
 msgid ""
-"Specialist options (--allow-releaseinfo-changes---allow-releaseinfo-change-field)  exist to allow changes only for "
 "certain fields like origin, label, "
 "codename, suite, version
 #: apt-get.8.xml
 msgid ""
-"Specialist options (--allow-releaseinfo-changes---allow-releaseinfo-change-field)  exist to allow changes only for "
 "certain fields like origin, label, "
 "codename, suite, version

Bug#873831: [debhelper-devel] Bug#873831: debhelper: [meson] Default to a UTF8 locale?

[Jussi Pakkanen]

On Fri, Sep 1, 2017 at 12:37 AM, Steve Langasek  wrote:

> Because the transition is fraught.  C.UTF-8 is now built and always
> available as part of the libc package, but it's not built into the binary
> and making libc itself treat it as a built-in default is problematic; which
> means there's a need to configure C.UTF-8 on the system at install time as
> the default.

Seems reasonable. For this particular issue Python 3.7 will do the
ANSI -> UTF-8 coercion itself so this will only be an issue until that
lands. In the mean time the simplest solution would seem to be for
debhelper to add the necessary locale setting. This should match what
some of the packages are doing already.

Bug#873915: python2.7: fpectl removal breaks cython

[Ole Streicher]

Package: python2.7
Version: 2.7.14~rc1-2
Severity: serious
Affects: cython

Like #873791, Cython is also affected. This causes an FTBFS for
python-numpy:

https://buildd.debian.org/status/logs.php?pkg=python-numpy&ver=1%3A1.12.1-3.1

The same problem probably happens with  python3.6 3.6.2-3.

Best

Ole

Bug#873916: RFP: shoogle -- use the Google API from the shell

[Chris Lamb]

Package: wnpp
Severity: wishlist

* Package name: shoogle
* URL : https://github.com/tokland/shoogle
  Upstream Author : Arnau Sanchez (@tokland)
* License : GPLv3

Command-line utility to use the Google API from the shell. An example
to get the long URL using the urlshortener service:


  $ echo '{"shortUrl": "http://goo.gl/Du5PSN"}' | \
  shoogle execute urlshortener:v1.url.get -
  {
"status": "OK",
"id": "http://goo.gl/Du5PSN";,
"longUrl": 
"http://1.bp.blogspot.com/-R0HSXDqlJI8/Tr67i-kr7hI/AAABMko/gaId6iYuhjA/s1600/12_%252520Cross%252520that%252520bridge%252520when%252520we%252520come%252520to%252520it.jpg";,
"kind": "urlshortener#url"
  }


Regards,

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

Bug#853568: [Debian-med-packaging] Bug#853568: No idea how to fix abs arguments in nanopolish

[Gert Wollny]

Am Donnerstag, den 31.08.2017, 21:00 -0700 schrieb Walter Landry:
> Andreas Tille  wrote:
> > Hi,
> > 
> > to fix bug #853568 I tried a patch (gcc-7.patch) to fix abs()
> > arguments
> > in nanopolish[1] but I have no idea how to deal with this:
> > 
> > ...
> > g++ -o src/hmm/nanopolish_pore_model_set.o -c -g -O2 -fdebug-
> > prefix-map=/build/nanopolish-0.5.0=. -fstack-protector-strong
> > -Wformat -Werror=format-security -g -O3 -std=c++11 -fopenmp -Wdate-
> > t
> > src/common/nanopolish_variant.cpp: In function
> > 'std::vector extract_variants(const string&, const
> > string&)':
> > src/common/nanopolish_variant.cpp:32:69: error: call of overloaded
> > 'abs(std::__cxx11::basic_string::size_type)' is ambiguous
> >  size_t difference = std::abs(reference.size() -
> > haplotype.size());
> 
> The result of subtracting two size_t's is still a size_t, which is
> unsigned.  So you need to cast it to a signed type.  The correct type
> is ptrdiff_t.
> 
>   http://en.cppreference.com/w/cpp/types/ptrdiff_t
> 
> The line then becomes
> 
>   size_t difference =
> std::abs(static_cast(reference.size() -
> haplotype.size()));

Casting the difference may result in undefined behavior. Consider the
case 

   reference.size() == 1
   haplotype.size() == 2 

then 

   reference.size() - haplotype.size() 

will be 0x (on 32 bit), and how this is casted to a signed type
is implementation dependent (i.e. it is not guaranteed that this simply
wraps to -1, it may also raise a trap because of integer overflow). 

It would be better to avoid the cast altogether by doing something like

   size_t difference = reference.size() > haplotype.size() ? 
   reference.size() - haplotype.size() : 
   haplotype.size() - reference.size(); 


or cast both values before doing the subtraction.

Best, 
Gert 

Bug#873508: sparse test failures on ppc32le (and other not so common archs)

[Uwe Kleine-König]

Hello,

On Thu, Aug 31, 2017 at 11:43:53PM +0100, Ramsay Jones wrote:
> On 31/08/17 21:55, Uwe Kleine-König wrote:
> > On Wed, Aug 30, 2017 at 08:11:49PM -0400, Christopher Li wrote:
> >> That is very much like on x86_64 missing define "#weak_define __x86_64__ 1"
> >>
> >> Does cgcc work for you? In the future we do want to move the archetecture
> >> related define from cgcc into sparse by itself. For now you can set
> >> "sparse" as "cgcc -no-compile"
> > 
> > Yes that works. So to address the Debian bug I can do:
> > 
> >  - move sparse to /usr/lib
> >  - teach cgcc about the move of sparse
> >  - make /usr/bin/sparse call cgcc -no-compile "$@"
> 
> Hmm, I don't think that would be a good idea ...
> 
> > or is it easier to teach sparse about the architecture stuff?
> 
> I now understand (I think!) that you are building a sparse
> package (presumably a .deb) and you are concerned that sparse
> does not pass it's own testsuite on those platforms.

Nearly right. I'm responsible for the sparse Debian package and the
problem at hand is https://bugs.debian.org/873508. This bug report has
"Severity: serious" wihch might eventually result in the removal of
sparse from the Debian archive.

@anarcat: Given that cgcc seems to work, would you agree to apply the
following patch to horst:

diff --git a/Makefile b/Makefile
index 4f924fa..d563652 100644
--- a/Makefile
+++ b/Makefile
@@ -110,7 +110,7 @@ $(NAME): $(OBJS)
 $(OBJS): .buildflags
 
 check:
-   sparse $(CFLAGS) *.[ch]
+   cgcc -no-compile $(CFLAGS) *.[ch]
 
 clean:
-rm -f *.o radiotap/*.o *~

and downgrade the bug to "important"? That would be a compromise that
buys us a bit of time.
 
> As I said before, the additional failures you are seeing are
> in the 'llvm backend' code (which, as far as I know, only passes
> on x86_64 Linux), and in my opinion the llvm-backend programs should
> not be installed. (The Makefile will build them automatically if
> you have llvm installed, likewise for c2xml/libxml and test-inspect/gtk).

Currently the sparse package contains /usr/include/sparse/, c2xml, cgcc,
sparse, sparse-llvm, sparsec and a separate package sparse-test-inspect
includes test-inspect. (That's how I inherited the package some time
ago.)
 
> [I would like to see build variable(s) to allow the user to suppress
> the build (or installation) of the other 'non-primary' sparse programs.]
> 
> Anyway, if you were to un-install llvm, sparse-llvm etc., would not
> be built, and the tests would not be run ... ;-)
> 
> Christopher, as the project maintainer, has the joy of making these
> kinds of decisions! :-D

This only solves a part of the problem because the bug report is about
sparse itself, not it's llvm part.

Best regards
Uwe


signature.asc
Description: PGP signature

Bug#873915: python2.7: fpectl removal breaks cython

[Matthias Klose]

Control: severity -1 important

On 01.09.2017 09:32, Ole Streicher wrote:
> Package: python2.7
> Version: 2.7.14~rc1-2
> Severity: serious
> Affects: cython
> 
> Like #873791, Cython is also affected. This causes an FTBFS for
> python-numpy:
> 
> https://buildd.debian.org/status/logs.php?pkg=python-numpy&ver=1%3A1.12.1-3.1
> 
> The same problem probably happens with  python3.6 3.6.2-3.

yes, please check the archive for uploads before you file issues.

Bug#873917: charmtimetracker: Please drop "Cross-Platform" from package description

[Chris Lamb]

Package: charmtimetracker
Version: 1.11.4-1
Severity: wishlist

Hi,

The package description says "Cross-Platform" which means Windows,
Mac & Linux according to the homepage.

Given the context, it seems sensible to drop the "cross-platform"
bit given that, well, we are producing a GNU/Linux distribution. :)


Regards,

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

Bug#873508: sparse test failures on ppc32le (and other not so common archs)

[Uwe Kleine-König]

On Fri, Sep 01, 2017 at 12:02:12AM -0700, Josh Triplett wrote:
> On Thu, Aug 31, 2017 at 08:47:55PM -0400, Christopher Li wrote:
> > On Thu, Aug 31, 2017 at 4:55 PM, Uwe Kleine-König  Yes
> > that works. So to address the Debian bug I can do:
> > >
> > >  - move sparse to /usr/lib
> > >  - teach cgcc about the move of sparse
> > >  - make /usr/bin/sparse call cgcc -no-compile "$@"
> > 
> > I don't like that. It means the user can't invoke sparse directly.
> > 
> > >
> > > or is it easier to teach sparse about the architecture stuff?
> > 
> > First of all. It is not very trivial to teach sparse about the architecture
> > stuff. To my mind, we need to move all the cgcc logic into sparse.
> 
> Related to that: while it would mean we couldn't necessarily just rely
> entirely on GCC's definitions for a target platform, I think in an ideal
> world we could have a sparse binary that understood *all* target
> platforms at once, such that you could ask Sparse on x86_64 to "compile"
> as though targeting any arbitrary architecture. That would also have the
> major advantage of making it easy to run the Sparse testsuite for
> *every* target architecture without needing compilers for every such
> architecture.

You'd need the target arch's system headers though. But still it would
be great. In a first attempt something like:

#ifdef __powerpc__
add_pre_buffer("#weak_define __powerpc__ " __powerpc__ "\n");
#ifdef _CALL_ELF
add_pre_buffer("#weak_define _CALL_ELF " _CALL_ELF "\n");
#endif
#endif

would be helpful already.

Best regards
Uwe


signature.asc
Description: PGP signature

Bug#865586: live-build: binary_hdd failed with mkfs.vfat error

[Raphael Hertzog]

Hello,

On Tue, 29 Aug 2017, Matthijs Kooijman wrote:
> I also ran into this same error a while ago. It is caused by partition
> devices being created when parted creates partitions, which are not
> cleaned up when the loop devices are cleaned up. I'm attaching a patch
> that fixes this, by passing --partscan to losetup to clear out any
> lingering partition devices when the partition itself is mounted.

Thanks, applied in git.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

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

Bug#873903: libidn2-0: CVE-2017-14062: integer overflow in decode_digit

[Tim Rühsen]

On Fri, 01 Sep 2017 06:52:53 +0200 Salvatore Bonaccorso
 wrote:
> Source: libidn2-0
> Version: 0.10-2
> Severity: important
> Tags: upstream security patch
> 
> Hi,
> 
> the following vulnerability was published for libidn2-0.
> 
> CVE-2017-14062[0]:
> | Integer overflow in the decode_digit function in puny_decode.c in
> | Libidn2 before 2.0.4 allows remote attackers to cause a denial of
> | service or possibly have unspecified other impact.
> 
> If you fix the vulnerability please also make sure to include the
> CVE (Common Vulnerabilities & Exposures) id in your changelog entry.
> 
> For further information see:
> 
> [0] https://security-tracker.debian.org/tracker/CVE-2017-14062
> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-14062
> [1] 
> https://gitlab.com/libidn/libidn2/commit/3284eb342cd0ed1a18786e3fcdf0cdd7e76676bd

Just backported the fix from libidn2 into libidn upstream (commit
e9e81b8063b095b02cf104bb992fa9bf9515b9d8).

Regards, Tim




signature.asc
Description: OpenPGP digital signature

Bug#873918: charmtimetracker: Missing binary dependency on libqt5sql5-sqlite

[Chris Lamb]

Package: charmtimetracker
Version: 1.11.4-1
Severity: grave
Tags: patch
Justification: Renders package unusable

Hi,

charmtimetracker appears to be missing a binary dependency on
libqt5sql5-sqlite. Installing libqt5sql5-sqlite manually moves
past this.

  $ charmtimetracker
  QSqlDatabase: QSQLITE driver not loaded
  QSqlDatabase: available drivers: 

Screenshot of UI error:

  https://i.imgur.com/1RLOZ4L.jpg


Patch attached.



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

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

Versions of packages charmtimetracker depends on:
ii  libc62.24-17
ii  libgcc1  1:7.2.0-1
ii  libqt5core5a 5.9.1+dfsg-9
ii  libqt5dbus5  5.9.1+dfsg-9
ii  libqt5gui5   5.9.1+dfsg-9
ii  libqt5keychain1  0.7.0-3
ii  libqt5network5   5.9.1+dfsg-9
ii  libqt5printsupport5  5.9.1+dfsg-9
ii  libqt5script55.9.1+dfsg-2
ii  libqt5sql5   5.9.1+dfsg-9
ii  libqt5widgets5   5.9.1+dfsg-9
ii  libqt5xml5   5.9.1+dfsg-9
ii  libstdc++6   7.2.0-1
ii  libxcb-screensaver0  1.12-1
ii  libxcb1  1.12-1

charmtimetracker recommends no packages.

charmtimetracker suggests no packages.

-- no debconf information


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
diff --git a/debian/control b/debian/control
index 32ff76f..ebdba87 100644
--- a/debian/control
+++ b/debian/control
@@ -20,7 +20,7 @@ Vcs-Browser: 
https://anonscm.debian.org/cgit/pkg-kde/kde-extras/charmtimetracker
 
 Package: charmtimetracker
 Architecture: any
-Depends: ${misc:Depends}, ${shlibs:Depends}
+Depends: ${misc:Depends}, ${shlibs:Depends}, libqt5sql5-sqlite
 Description: Cross-Platform Time Tracker
  It is built around two major ideas - tasks and events.
  Tasks are the things time is spend on, repeatedly. Tasks

Bug#873791: [python-numpy] Undefined symbols on several architectures

[Adrian Bunk]

On Thu, Aug 31, 2017 at 12:48:53PM +0200, Matthias Klose wrote:
> On 31.08.2017 12:35, Adrian Bunk wrote:
> > Control: reassign -1 python2.7 2.7.14~rc1-1
> > Control: retitle -1 python2.7: fpectl extension removal broke the ABI for C 
> > extensions
> > Control: affects -1 python-numpy
> > 
> > On Thu, Aug 31, 2017 at 11:34:55AM +0200, Michał Klichowicz wrote:
> >> Got that error on amd64, too.
> >>
> >> This started today, after the upgrading python2.7 packages to 2.7.14~rc1
> >> in sid. Downgrading back to buster's 2.7.13-2 solves the problem.
> > 
> > I got the same error with Cython:
> > 
> > ImportError: 
> > /usr/lib/python2.7/dist-packages/Cython/Compiler/Code.x86_64-linux-gnu.so: 
> > undefined symbol: PyFPE_jbuf.  You should look at http://www.cython.org"; 
> > 
> > It seems the following change in 2.7.14~rc1-1 broke the ABI:
> >   * Stop building the fpectl extension.
> 
> yes, that's intended. I'll add a break.  Are there other known packages 
> besides
> python-numpy?

As written above, Cython is the one where I ran into this issue.

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#870599: Re; upload ansible version with Depends: python-jinja2 < 2.9

[Jack Henschel]

Thanks for fixing this, greatly appreciated!

Greetings
Jack



signature.asc
Description: OpenPGP digital signature

Bug#871765: please don't force a specific TLS version

[Julian Gilbey]

On Fri, Aug 11, 2017 at 08:20:38AM +0200, Evgeni Golov wrote:
> Package: isync
> Version: 1.2.1-2
> Severity: important
> Tags: upstream
> 
> Ohai,
> 
> isync/mbsync defaults to use TLSv1, which was recently disabled in Debian [1].
> This results in funny errors when trying to use mbsync now:
>  Socket error: secure connect to mail.die-welt.net (81.7.13.250:143): 
> error:141640BF:SSL routines:tls_construct_client_hello:no protocols available
> 
> Please don't hardcode any TLS defaults, let OpenSSL use whatever it knows is 
> best.
> 
> Tempted to add a "security" tag.

I wonder whether this should be a "serious" bug: it makes the package
unusable whenever a mailbox has an SSL handshake.

   Julian

Bug#873640: live-build: Hdd image fails due to hard links in binary directory

[Raphael Hertzog]

Hi Matthijs,

On Tue, 29 Aug 2017, Matthijs Kooijman wrote:
> To fix this I've attached a patch that, passes --count-links to du when
> the target is FAT, to make the space estimation correct.

Thanks for your multiple patches, I applied them all in git.

Would you like to become co-maintainer of live-build? I maintain
it because I use it in Kali but I use only a very limited set of
the features and it would be nice to have other people who can
look at bugs.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

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

Bug#873920: libgssapi-krb5-2: adequate reports obsolete conffile in libgssapi-krb5-2

[shirish शिरीष]

Package: libgssapi-krb5-2
Version: 1.15.1-2
Severity: normal

Dear Maintainer,

Thank you for maintaining the library. libgssapi-krb5-2. While
upgrading today, saw adequate telling libgssapi-krb5-2 has an obsolete
conffile.

$ adequate libgssapi-krb5-2
   [100%]
libgssapi-krb5-2:amd64: obsolete-conffile /etc/gss/mech.d/README

If possible, please fix the same.

-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (990, 'testing'), (100, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

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

Versions of packages libgssapi-krb5-2 depends on:
ii  libc62.24-12
ii  libcomerr2   1.43.5-1
ii  libk5crypto3 1.15.1-2
ii  libkeyutils1 1.5.9-9
ii  libkrb5-31.15.1-2
ii  libkrb5support0  1.15.1-2

libgssapi-krb5-2 recommends no packages.

Versions of packages libgssapi-krb5-2 suggests:
pn  krb5-doc   
pn  krb5-user  

-- no debconf information


-- 
  Regards,
  Shirish Agarwal  शिरीष अग्रवाल
  My quotes in this email licensed under CC 3.0
http://creativecommons.org/licenses/by-nc/3.0/
http://flossexperiences.wordpress.com
EB80 462B 08E1 A0DE A73A  2C2F 9F3D C7A4 E1C4 D2D8

Bug#871813: isync: please allow the usage of TLS1.1+ by default

[Julian Gilbey]

On Sat, Aug 12, 2017 at 12:11:20PM +0200, Oswald Buddenhagen wrote:
> this should be considered a duplicate of Bug#871765.
> 
> the patch is rather incomplete in the compat wrapper part. but my own
> patch does not touch it at all, and i think i'll leave it at that
> (introducing new features to the compat wrapper seems anti-thetical).
> 
> also, don't mix in the ssl2/3 removal into the same patch. i'll remove
> sslv2 separately in master (to be 1.3 soon). i know that debian disables
> sslv3 in openssl, but it seems odd to prune it from mbsync at this point.

Hi Oswald,

Would you be able to share your patch here, or upload a patched
version of this package as an NMU (or both)?  I'd love to have a
working mbsync again

Many thanks,

   Julian

Bug#873878: Acknowledgement (glusterfs-client: mount.glusterfs needs bash as /bin/sh)

[Michael Lundkvist]

Here is a quick and dirty patch. I manually applied the same change to 
/sbin/mount.glusterfs and got it working with dash again.


No real testing done...

/Micke
diff --git a/xlators/mount/fuse/utils/mount.glusterfs.in b/xlators/mount/fuse/utils/mount.glusterfs.in
index 216d03c41..51792c479 100755
--- a/xlators/mount/fuse/utils/mount.glusterfs.in
+++ b/xlators/mount/fuse/utils/mount.glusterfs.in
@@ -673,8 +673,9 @@ main ()
 [ -n "$volume_str" ] && {
 volume_id=$volume_str
 volume_str_temp=$volume_str
-[ ${volume_str:0:1} = '/' ] && {
-volume_str_temp=${volume_str:1}
+	first_char=$(echo "$volume_str" | cut -c 1)
+[ ${first_char} = '/' ] && {
+volume_str_temp=$(echo "$volume_str" | cut -c 2-)
 }
 [ $(echo $volume_str_temp | grep -c "/") -eq 1 ] && {
 volume_id=$(echo "$volume_str_temp" | cut -f1 -d '/');

Bug#873919: make dpkg-buildpackage default locale UTF-8

[Hans-Christoph Steiner]

Package: dpkg-dev

More and more packages are adding unicode files as unicode support has
become more reliable and available.  The package building process is not
guaranteed to happen in a unicode locale since the Debian default locale
is LC_ALL=C, which is ASCII not UTF-8.  Reading UTF-8 filenames when the
system is using ASCII causes errors (Python makes them very visible, for
example).

mbiebl, youpi, wRAR, bunk, and I had a discussion in #debian-devel.  It
looks like setting the default locale to C.UTF-8 in dpkg-buildpackage is
an easy way to improve this situation a lot.  Any package that needs an
encoding besides UTF-8 could always set it by adding something like this
to debian/rules:

  export LC_ALL = C

Setting C.UTF-8 as the global default in Debian would be the best
solution to this and many other issues, but that's a much much larger
project:
https://sourceware.org/glibc/wiki/Proposals/C.UTF-8

Bug#862051: Bug#754462: Bug#862051: nodejs (6.11.2~dfsg-1) experimental; urgency=medium

[Jérémy Lal]

2017-08-31 19:08 GMT+02:00 Sam Hartman :

> > "Dominique" == Dominique Dumont  writes:
>
> Dominique> On Thursday, 31 August 2017 13:58:23 CEST Thorsten Glaser
> wrote:
> >> > How about printing a "nice" warning explaining it would be a
> >> good idea to > move to /usr/bin/node ?
> >>
> >> That will break scripts that do:
> >>
> >> x=$(nodejs somescript)
>
> Dominique> This kind of script won't break if the deprecation
> Dominique> warning is sent to STDERR
>
>
> Sigh.
> I wish I had seen your message before your earlier reply.
> This breaks too in more complex situations involving ssh, things like
> expect scripts and the like.
> There are cases where people mix stderr and stdout.  There are cases
> where people treat any unexpected output on stderr as a failure in
> automated scripts.
>
> The next level you can look at is considering whether /dev/stdin in a
> tty and printing the warning to either stderr or /dev/tty only in that
> case.
> And that will reduce the breakage but not remove it.
> And yes, when you actually have something it's important to deprecate,
> accepting some level of breakage and adopting one of those strategies is
> the right thing.
>
> It's just not worth it in this case.
> People who use more than Debian are very quickly going to learn that
> /usr/bin/node is preferred to /usr/bin/nodejs.
> As several people have already pointed out we've far exceeded the amount
> of effort in considering whether to deprecate or remove the link that
> will be spent maintaining the link until the end of time.
> In one sense we've already lost:-)
>

So, a short NEWS entry explaining /usr/bin/node is now available by default,
and that /usr/bin/nodejs will stay available indefinitely ?
Or even nothing and just a changelog entry ?

Jérémy

Bug#873921: python3.5_3.5.4-3 breaks borgbackup: undefined symbol: PyFPE_jbuf

[Sven Hartge]

Package: borgbackup
Version: 1.0.11-3
Severity: grave

Hi!

I am reporting this bug against borgbackup, because I am not sure if the
bug is in python3.5 or borgbackup just needs to be binNMUd. Please
reassign as you see fit.

The upload of python3.5 (3.5.4-3) disables the fpectl extension and
breaks borgbackup:

$ borg
Traceback (most recent call last):
  File "/usr/bin/borg", line 11, in 
load_entry_point('borgbackup==1.0.11', 'console_scripts', 'borg')()
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 564, in 
load_entry_point
return get_distribution(dist).load_entry_point(group, name)
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 2662, 
in load_entry_point
return ep.load()
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 2316, 
in load
return self.resolve()
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 2322, 
in resolve
module = __import__(self.module_name, fromlist=['__name__'], level=0)
  File "/usr/lib/python3/dist-packages/borg/archiver.py", line 22, in 
from .helpers import Error, location_validator, archivename_validator, 
format_line, format_time, format_file_size, \
  File "/usr/lib/python3/dist-packages/borg/helpers.py", line 35, in 
from . import crypto
ImportError: 
/usr/lib/python3/dist-packages/borg/crypto.cpython-35m-i386-linux-gnu.so: 
undefined symbol: PyFPE_jbuf

Grüße,
Sven.

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

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

Versions of packages borgbackup depends on:
ii  fuse   2.9.7-1
ii  libacl12.2.52-3+b1
ii  libc6  2.24-17
ii  liblz4-1   0.0~r131-2+b1
pn  libssl1.1  
ii  python33.5.3-3
ii  python3-llfuse 1.2+dfsg-1+b1
ii  python3-msgpack0.4.8-1+b1
ii  python3-pkg-resources  36.2.7-2

borgbackup recommends no packages.

Versions of packages borgbackup suggests:
pn  borgbackup-doc  

-- debconf-show failed

Bug#870069: orig-tarball-missing-upstream-signature error breaks rebuilding existing packages and more

[Chris Lamb]

Hey Stefan and Paul,

> orig-tarball-missing-upstream-signature error breaks rebuilding
> existing packages

The next version of Lintian will ignore "repacked" tarballs - ones
that contain "dfsg" in their version.

Perhaps we could also ignore "UNRELEASED" in the distribution? Or
is there something else we could check for in the version...?


Regards,

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

Bug#871956: lintian: false positive: binary-file-built-without-LFS-support on x32

[Chris Lamb]

Hi all,

> false positive: binary-file-built-without-LFS-support on x32

I think the next step here would be to identify which of these
archs should be skipped for this check:

  
https://anonscm.debian.org/git/lintian/lintian.git/tree/data/common/architectures


Regards,

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

Bug#857123: lintian: warning about missing classpath is confusing

[Chris Lamb]

tags 857123 + moreinfo
thanks

> Can someone give a concrete example?

(Tagging as moreinfo...)


Regards,

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

Bug#873919: make dpkg-buildpackage default locale UTF-8

[Guillem Jover]

Control: forcemerge -1 843776

Hi!

On Fri, 2017-09-01 at 10:23:59 +0200, Hans-Christoph Steiner wrote:
> Package: dpkg-dev
> 
> More and more packages are adding unicode files as unicode support has
> become more reliable and available.  The package building process is not
> guaranteed to happen in a unicode locale since the Debian default locale
> is LC_ALL=C, which is ASCII not UTF-8.  Reading UTF-8 filenames when the
> system is using ASCII causes errors (Python makes them very visible, for
> example).
> 
> mbiebl, youpi, wRAR, bunk, and I had a discussion in #debian-devel.  It
> looks like setting the default locale to C.UTF-8 in dpkg-buildpackage is
> an easy way to improve this situation a lot.  Any package that needs an
> encoding besides UTF-8 could always set it by adding something like this
> to debian/rules:
> 
>   export LC_ALL = C

As long as the project considers debian/rules the main entry point to a
package build, I'm not planning on predefining new general purpose
environment variables from dpkg-buildpackage that would otherwise not
be set by the builder.

The distinction here would be something like LC_*, against something
like CC on a cross-compilation, which you need to set no matter what.

But please, see the rationale on the other bug. I think I'll be adding
an entry to the dpkg FAQ, because it seems this has become a recurring
request. :)

> Setting C.UTF-8 as the global default in Debian would be the best
> solution to this and many other issues, but that's a much much larger
> project:
> https://sourceware.org/glibc/wiki/Proposals/C.UTF-8

That _might_ help on buildds, but not on maintainer systems for example.

Thanks,
Guillem

Bug#871765: please don't force a specific TLS version

[Evgeni Golov]

On Fri, Sep 01, 2017 at 09:01:29AM +0100, Julian Gilbey wrote:
> On Fri, Aug 11, 2017 at 08:20:38AM +0200, Evgeni Golov wrote:
> > isync/mbsync defaults to use TLSv1, which was recently disabled in Debian 
> > [1].
> > This results in funny errors when trying to use mbsync now:
> >  Socket error: secure connect to mail.die-welt.net (81.7.13.250:143): 
> > error:141640BF:SSL routines:tls_construct_client_hello:no protocols 
> > available
> > 
> > Please don't hardcode any TLS defaults, let OpenSSL use whatever it knows 
> > is best.
> > 
> > Tempted to add a "security" tag.
> 
> I wonder whether this should be a "serious" bug: it makes the package
> unusable whenever a mailbox has an SSL handshake.

Well, the workaround is kinda trivial, just add:
  SSLVersions TLSv1.2
to your config.

And there is no data leakage/corruption/loss.

What do the maintainers think?

Bug#849622: lintian: unexpected description-starts-with-leading-spaces

[Chris Lamb]

tags 849622 + pending
thanks

Fixed in Git:

  
https://anonscm.debian.org/git/lintian/lintian.git/commit/?id=d947c8318c0e8b0cd08cda1582358558d5befccb

Thanks!


Regards,

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

Bug#873792: qjackctl will not start at all

[Ed Peguillan III]

My mail client replied to the wrong address, my apologies.

After performing
$ sudo mv 
/usr/lib/x86_64-linux-gnu/freetype-infinality/liblibfreetype.so.6 ~


qjackctl and virtualbox seem to start and work normally.

It's too bad that I can't use infinality fonts anymore, my screen is 
back to looking terrible.


Thank you for your help! This bug can be closed.

Ed

On Thu, 31 Aug 2017 23:46:16 +0200 Sebastian Ramacher 
 wrote:

> Re-adding the bug to CC.
>
> On 2017-08-31 16:02:13, Ed Peguillan III wrote:
> > Sure.
> >
> > |$ ldd -r /usr/lib/x86_64-linux-gnu/libQt5XcbQpa.so.5||
> > || linux-vdso.so.1 (0x7ffd883f3000)||
> > || libxcb-xinerama.so.0 => 
/usr/lib/x86_64-linux-gnu/libxcb-xinerama.so.0

> > (0x7f6ec82f9000)||
> > || libglib-2.0.so.0 => /lib/x86_64-linux-gnu/libglib-2.0.so.0
> > (0x7f6ec7fe4000)||
> > || libfontconfig.so.1 => /usr/lib/x86_64-linux-gnu/libfontconfig.so.1
> > (0x7f6ec7da)||
> > || libfreetype.so.6 =>
> > /usr/lib/x86_64-linux-gnu/freetype-infinality/libfreetype.so.6
>
> And that's the issue. Please remove it and try again.
>
> Cheers
>
> > (0x7f6ec7aef000)||
> > || libQt5Gui.so.5 => /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5
> > (0x7f6ec7388000)||
> > || libQt5DBus.so.5 => /usr/lib/x86_64-linux-gnu/libQt5DBus.so.5
> > (0x7f6ec70fe000)||
> > || libQt5Core.so.5 => /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
> > (0x7f6ec69b5000)||
> > || libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
> > (0x7f6ec6798000)||
> > || libX11.so.6 => /usr/lib/x86_64-linux-gnu/libX11.so.6
> > (0x7f6ec6458000)||
> > || libX11-xcb.so.1 => /usr/lib/x86_64-linux-gnu/libX11-xcb.so.1
> > (0x7f6ec6256000)||
> > || libXi.so.6 => /usr/lib/x86_64-linux-gnu/libXi.so.6
> > (0x7f6ec6046000)||
> > || libSM.so.6 => /usr/lib/x86_64-linux-gnu/libSM.so.6
> > (0x7f6ec5e3e000)||
> > || libICE.so.6 => /usr/lib/x86_64-linux-gnu/libICE.so.6
> > (0x7f6ec5c21000)||
> > || libxcb-xkb.so.1 => /usr/lib/x86_64-linux-gnu/libxcb-xkb.so.1
> > (0x7f6ec5a05000)||
> > || libxcb-render-util.so.0 =>
> > /usr/lib/x86_64-linux-gnu/libxcb-render-util.so.0 
(0x7f6ec5801000)||

> > || libxcb-render.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-render.so.0
> > (0x7f6ec55f3000)||
> > || libxcb-sync.so.1 => /usr/lib/x86_64-linux-gnu/libxcb-sync.so.1
> > (0x7f6ec53ec000)||
> > || libxcb-xfixes.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-xfixes.so.0
> > (0x7f6ec51e4000)||
> > || libxcb-randr.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-randr.so.0
> > (0x7f6ec4fd4000)||
> > || libxcb-image.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-image.so.0
> > (0x7f6ec4dcf000)||
> > || libxcb-shm.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-shm.so.0
> > (0x7f6ec4bcb000)||
> > || libxcb-keysyms.so.1 => /usr/lib/x86_64-linux-gnu/libxcb-keysyms.so.1
> > (0x7f6ec49c8000)||
> > || libxcb-icccm.so.4 => /usr/lib/x86_64-linux-gnu/libxcb-icccm.so.4
> > (0x7f6ec47c3000)||
> > || libxcb.so.1 => /usr/lib/x86_64-linux-gnu/libxcb.so.1

Bug#873791: Bug#873915: python2.7: fpectl removal breaks cython

[Ole Streicher]

Hi Mathias,

On 01.09.2017 09:51, Matthias Klose wrote:
> Control: severity -1 important

IMO it is RC, isn't it?

> yes, please check the archive for uploads before you file issues.
Which one do you mean?

Currently (from the tracker): Python 2.7 is still 2.7.14~rc1-2, and
Python 3.6 is still 3.6.2-3, both from yesterday, and both don't break
Cython. Cython also did not get an binNMU yet.

To me, this looks as it is still unresolved on both Python 2 and 3. I
just didn't want to create another issue since you do probably both in
the same step anyway.

Best regards

Ole

Bug#867724: Multiple security issues

[Fabian Greffrath]

Hi Markus,

Markus Koschany wrote:
> I uploaded a security update for faad2 to wheezy-security a few hours
> ago. I am attaching the debdiff to this bug report.

thank you very much for that!

> Do you intend to fix the issue in Stretch too? I could prepare the
> update for Jessie and ask the release team for a jessie-pu.

I don't have any plans to do that.

Cheers,

 - Fabian

Bug#873791: [python-numpy] Undefined symbols on several architectures

[Adrian Bunk]

On Fri, Sep 01, 2017 at 11:18:00AM +0300, Adrian Bunk wrote:
> On Thu, Aug 31, 2017 at 12:48:53PM +0200, Matthias Klose wrote:
> > On 31.08.2017 12:35, Adrian Bunk wrote:
> > > Control: reassign -1 python2.7 2.7.14~rc1-1
> > > Control: retitle -1 python2.7: fpectl extension removal broke the ABI for 
> > > C extensions
> > > Control: affects -1 python-numpy
> > > 
> > > On Thu, Aug 31, 2017 at 11:34:55AM +0200, Michał Klichowicz wrote:
> > >> Got that error on amd64, too.
> > >>
> > >> This started today, after the upgrading python2.7 packages to 2.7.14~rc1
> > >> in sid. Downgrading back to buster's 2.7.13-2 solves the problem.
> > > 
> > > I got the same error with Cython:
> > > 
> > > ImportError: 
> > > /usr/lib/python2.7/dist-packages/Cython/Compiler/Code.x86_64-linux-gnu.so:
> > >  undefined symbol: PyFPE_jbuf.  You should look at http://www.cython.org"; 
> > > 
> > > It seems the following change in 2.7.14~rc1-1 broke the ABI:
> > >   * Stop building the fpectl extension.
> > 
> > yes, that's intended. I'll add a break.  Are there other known packages 
> > besides
> > python-numpy?
> 
> As written above, Cython is the one where I ran into this issue.

And based on #873921, borgbackup.

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#873923: installer not detecting/configuring existing LUKS/LVM setup

[Eduard Bloch]

Package: debian-installer
Severity: normal

this is a follow-up to #873862 , see there for most details.

So, the outcome is, when the installer fails with the problem mentioned
there, I can still reboot the system.

But then, the d-i is basically stuck at the same step. The LUKS
partition is not displayed as LUKS or crypto but "unused". There is no
way to tell it "this is crypto, unencrypt it only". The only
sensible option in the usage types is apparently "PV for encryption". But
then, nothing asks me for the password, instead it presents me a list of
cryptsetup parameters. Hard to tell for a normal user whether it did
detect LUKS or not.

When I go to the main partman menu, there is the option "configure
crypto volumes".  But it does NOT configure the existing one. It only
offers me the choice "create a new crypto volume" and "go back". This is
pretty ... useless if I want to keep existing data.

So apparently the d-i is inept to use the same device setup that it has
created before or there is maybe no LUKS detection whatsoever?

When I try to investigate later with Ubuntu Live, the file manager shows
the encrypted volume and lets me unencrypt it with a a double-click and
it even detects and scans the LVM and registers LVs there). It doesn't
redisplay the discovered PVs in the filemanager, though, but I can mkfs
and mount them manually.

Regards,
Eduard.

Bug#873791: Bug#873915: python2.7: fpectl removal breaks cython

[Axel Beckert]

Ole Streicher wrote:
> On 01.09.2017 09:51, Matthias Klose wrote:
> > Control: severity -1 important
> 
> IMO it is RC, isn't it?

I'd even say "critical" instead of the previous "serious" since it
breaks unrelated packages like apt and aptitude. (But the "unrelated"
is discussable so I didn't raise the severity from serious.)

IMHO this issue (since there are breaks in the python packages) now
should be filed again against python-numpy and what else is affected.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#873812: e2fsprogs: Please move l10n package from Suggests to Recommends

[Guillem Jover]

Hi!

On Thu, 2017-08-31 at 11:35:13 -0400, Theodore Ts'o wrote:
> On Thu, Aug 31, 2017 at 02:03:58PM +0200, Guillem Jover wrote:
> > Package: e2fsprogs
> > Version: 1.43.6-1
> > 
> > The recently split translations ended up being added as a Suggests in
> > e2fsprogs, which means they will not be installed by default anymore.
> > This should probably be a Recommends, which would allow people to
> > remove them, but would be pulled in by default.
> 
> It hasn't been clear to me whether there is some kind of de factor
> standard about what the priority of translations should be.  They are
> not strictly speaking necessary for the proper operation of e2fsprogs,
> and people have started complaining that the translation files is
> getting very heavyweight.

Right, they are not necessary for the operation of the program by
itself, but might instead be necessary by the (non-English-speaking)
user to be able to operate the program. :)

> Some kind of guideline about how these packages should be named (e.g.,
> -l10n versus -locales) and what priority they would be might be a good
> thing to publish somewhere, if it doesn't already exist?  I'm not
> entirely certain it needs to be in Debian Policy as a mandatory thing,
> but I spent a bunch of time trying to figure out what was considered
> best practice, and it wasn't obvious to me.  Perhaps my Google-Fu failed me.  
> :-)

I think the common trend now is to use -l10n, which seems like the
correct thing to do, as even though it's a bit of a technical term
it's also pretty unambiguous.

I even filed a report against lintian to that effect some time ago:

  

And regarding the strength of the dependency. I still think Recommends
is the right bar, even though I (being a non-native English speaker)
do remove all l10n packages from my primary system as I tend to use
just LANG=C.UTF-8. :)

Thanks,
Guillem

Bug#682264: #682264,libapache2-mod-perl2: Crash at server startup when pre-loading Plack app

[Dominic Hargreaves]

On Fri, Sep 01, 2017 at 03:47:57PM +1000, Dmitry Smirnov wrote:
> I had the same problem until I've realised that Apache now uses event module
> by default. Solution is simple -- just switch to (traditional) MPM Prefork
> model as follows:
> 
> 
> a2dismod mpm_event
> a2enmod mpm_prefork
> 

Hi Dmitry,

Thanks for pointing this out. And to the original submitter, I'm sorry
that there was no reply on this bug before in many years!

As far as I know from a quick bit of digging it is indeed the case
that mod_perl will not work with the event mpm, so we should
arrange for it to either not be possible to load it it in that
configuration, or at least to print dire warnings if that happens
(which may be safer in any case).

I will try and have a look at this at some point but it might not be
soon, so help would be appreciated.

FTR, Red Hat does the same thing:
.

Kjetil, do you have any additional observations about this bug since
it was first filed in 2012? (For example did you find out that it
was in fact caused by use of the event mpm?)

.

Best,
Dominic. 

Bug#862051: nodejs (6.11.2~dfsg-1) experimental; urgency=medium

[Dominique Dumont]

On Thursday, 31 August 2017 13:08:58 CEST Sam Hartman wrote:
> There are cases where people mix stderr and stdout.  There are cases
> where people treat any unexpected output on stderr as a failure in
> automated scripts.

I rest my case. Thanks for the explanation. :-)

All the best

Bug#873924: piuparts should also test -dbgsym packages

[Adrian Bunk]

Source: piuparts
Severity: normal

Based on https://lintian.debian.org/tags/binaries-have-file-conflict.html
I recently went manually through possible file conflicts in -dbgsym packages
(caused by copies of a binary in several binary packages built by the same
source package), and reported these as:
#868537
#868538
#868541
#868545
#868546
#868547
#868549
#868551
#868552
#868564

Automated piuparts testing of file conflicts should be extended
to also include -dbgsym, for covering such bugs automatically.

Bug#873897: ITP: ocaml-result -- Compatibility Result module for OCaml

[Andy Li]

Turn out it has already been packaged (#873897).

Bug#868558: nmu: multiple r-* packages

[Emilio Pozuelo Monfort]

Hi Dirk,

On 26/08/17 14:29, Dirk Eddelbuettel wrote:
> 
> So I tried that -- and I cannot currently tickle the bug:
> 
>  -- r-cran-spatial (from the initial bug report) was long rebuilt by me
>  
>  -- r-cran-logspline (which you mentioned) is actually no longer on my
> refined (shorter) list, no issues there
> 
>  -- r-cran-data.table (on my list) is a false positive, the one grep()
> find is actually in commented-out code (but hey, the maintainer is a
> slacker too as the package had two updates not reflected yet...)
> 
>  -- r-cran-rcurl just works too, there is one .C() call in getCurlInfo()
> and it all passes as well.
> 
> In short I can NOT currently reproduce the issue on Debian unstable.
> 
> So this may be a huge nothingburger (and another reason not to enforce an
> API-tag rebuild over 500+ packages).

What Niels meant is whether having an old, non-rebuilt R module with the new
r-base works, and whether having a new, rebuilt R module with the old r-base
works. Is that so? Sorry if you already answered this, but it's not clear to me
and I'm not familiar with R at all so it's possible that I missed it.

>From your initial post, you say that the new R breaks loading optional code 
>with
two of the available mechanisms. That seems to imply that having a non-rebuilt
module with the new R 3.4 would break (some things). Right?

Thanks,
Emilio

Bug#873925: nfs-ganesha FTBFS with libntirpc-dev 1.5.3-1

[Adrian Bunk]

Source: nfs-ganesha
Version: 2.4.5-2
Severity: serious

https://buildd.debian.org/status/package.php?p=nfs-ganesha&suite=sid

...
make -f log/CMakeFiles/log.dir/build.make log/CMakeFiles/log.dir/build
make[4]: Entering directory '/<>/src/obj-x86_64-linux-gnu'
[  1%] Building C object log/CMakeFiles/log.dir/display.c.o
cd /<>/src/obj-x86_64-linux-gnu/log && /usr/bin/cc -D__USE_GNU 
-I/usr/include/glusterfs -I/usr/include/uuid 
-I/<>/src/obj-x86_64-linux-gnu/include 
-I/<>/src/include -I/<>/src/include/os/linux 
-I/include -I/usr/include/ntirpc -I/usr/include/dbus-1.0 
-I/usr/lib/x86_64-linux-gnu/dbus-1.0/include  -g -O2 
-fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -D_LARGEFILE64_SOURCE 
-D_FILE_OFFSET_BITS=64 -O2 -g -DNDEBUG   -D _GNU_SOURCE -o 
CMakeFiles/log.dir/display.c.o   -c /<>/src/log/display.c
[  1%] Building C object log/CMakeFiles/log.dir/log_functions.c.o
cd /<>/src/obj-x86_64-linux-gnu/log && /usr/bin/cc -D__USE_GNU 
-I/usr/include/glusterfs -I/usr/include/uuid 
-I/<>/src/obj-x86_64-linux-gnu/include 
-I/<>/src/include -I/<>/src/include/os/linux 
-I/include -I/usr/include/ntirpc -I/usr/include/dbus-1.0 
-I/usr/lib/x86_64-linux-gnu/dbus-1.0/include  -g -O2 
-fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -D_LARGEFILE64_SOURCE 
-D_FILE_OFFSET_BITS=64 -O2 -g -DNDEBUG   -D _GNU_SOURCE -o 
CMakeFiles/log.dir/log_functions.c.o   -c 
/<>/src/log/log_functions.c
In file included from /<>/src/log/log_functions.c:49:0:
/<>/src/include/gsh_rpc.h:27:10: fatal error: rpc/rpc_dplx.h: No 
such file or directory
 #include 
  ^~~~
compilation terminated.
log/CMakeFiles/log.dir/build.make:89: recipe for target 
'log/CMakeFiles/log.dir/log_functions.c.o' failed
make[4]: *** [log/CMakeFiles/log.dir/log_functions.c.o] Error 1

Bug#873926: enigmail: show short Key ID, where it should be long Key ID or fingerprint

[W. Martin Borgert]

Package: enigmail
Version: 2:1.9.8.1-1~deb9u1
Severity: important
Tags: security

When clicking on "Download missing keys" in the "Enigmail Key
Selection" window, a new window "Download OpenPGP Keys" appears. It
shows the columns, "Account / User ID", "Created", and "Key ID".
Unfortunately, the latter shows only short Key IDs, which should
not be used anywhere, because they are too easy to forge. This can
affect the privacy of conversation, if accidently a forged key is
selected, based on short Key ID only.

Please use at least the long Key ID or, mabye better, even the
complete fingerprint. This affects all uses of the short Key ID,
whereever it might appear.

Bug#864829: espeakup is incompatible with default pulseaudio

[Paul Gevers]

Package: espeakup
Followup-For: Bug #864829

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

There is also a Launchpad bug¹ (with lots of duplicates) that shows the same
symptoms. There is an interesting note there:
"""
The error does not occur when the kernel module "espeakup_soft" was previously
loaded before installation. (modprobe speakup_soft)
"""

Not sure what to do with it yet, but I wanted to cross-post it.

Paul

¹ https://bugs.launchpad.net/bugs/1711800

-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEEWLZtSHNr6TsFLeZynFyZ6wW9dQoFAlmpKo4ACgkQnFyZ6wW9
dQowagf9GP7rt2qS8XThbcPxGW036j23OuZ5EzEtRYjH04YIXpaLeJyhybXsc62A
9WwzH7GFTYlqOQuezoK3exvcB7OG+I5cgb4JRq/Wr3sQjOgNxU0WlPkInGLJkFCn
ubYO+a1KKNm6Gg++rBqri6OosbdvchtiX2/CIJMttbDto8RFGzdyyZHYXIWWVjif
I+aXA1P5JazRr6xUSkUIOGoKgY4Nh9dMdvKlf0xCZhCZTA1ZamEpPczZT0MeN7PU
K0r7hjw0X+sGrw0/8eETRr2gLZrTCz/nlsQA1kdO2Upb2/LXDJXVM/Otrdv3dQ2v
4wOOJgt3bzMcOxzLVlin1hYi/GfaQQ==
=noIP
-END PGP SIGNATURE-

Bug#873927: amavisd-new-cronjob returns unknown cron routine when bayes is

[Alexander Bachmer - rockenstein AG]

Package: amavisd-new
Version: 1:2.10.1-2~deb8u1


Hi,


root@host:/tmp# dpkg --list amavisd-new
Gewünscht=Unbekannt/Installieren/R=Entfernen/P=Vollständig
Löschen/Halten
| Status=Nicht/Installiert/Config/U=Entpackt/halb konFiguriert/
 Halb installiert/Trigger erWartet/Trigger anhängig
|/ Fehler?=(kein)/R=Neuinstallation notwendig (Status, Fehler:
GROSS=schlecht)
||/
NameVersion
  Architektur  Beschreibung
+++-===-
--
===

ii  amavisd-new 1:2.10.1-
2~deb8u1all  Interface between MTA
and virus scanner/content filters



root@host:/tmp# dpkg --status amavisd-new
Package: amavisd-new
Status: install ok installed
Priority: extra
Section: mail
Installed-Size: 2702
Maintainer: Brian May 
Architecture: all
Version: 1:2.10.1-2~deb8u1
Replaces: amavis
Provides: amavis
Depends: adduser (>= 3.34), debconf | debconf-2.0, file, libarchive-
tar-perl, libarchive-zip-perl (>= 1.14), libberkeleydb-perl,
libconvert-tnef-perl (>= 0.06), libconvert-uulib-perl (>= 1.0.5),
libdigest-md5-perl, libio-stringy-perl, libmail-dkim-perl,
libmailtools-perl (>= 1.58), libmime-base64-perl, libmime-tools-perl,
libnet-libidn-perl, libnet-server-perl, libtime-hires-perl, libunix-
syslog-perl, pax, perl (>= 5.10.1) | libcompress-raw-zlib-perl (>=
2.017), perl
Recommends: altermime, libnet-patricial-perl, ripole
Suggests: apt-listchanges (>= 2.35), arj, cabextract, clamav, clamav-
daemon, cpio, dspam, lhasa, libauthen-sasl-perl, libdbi-perl (>= 1.43),
libmail-dkim-perl (>= 0.31), libnet-ldap-perl (>= 1:0.32), libsnmp-
perl, libzeromq-perl, lzop, nomarch, p7zip, rpm, spamassassin (>=
3.1.0a), unrar
Conflicts: amavis, logcheck (<= 1.2.62)
Conffiles:
 /etc/amavis/README.l10n bbb66708bafec2e3a006a7c8a00b7fba
 /etc/amavis/conf.d/01-debian 8bafedb2fa9ee9fecde4aa799d3abfd6
 /etc/amavis/conf.d/05-domain_id 5a3ba3c821a0554711b69bb32ac1ec1a
 /etc/amavis/conf.d/05-node_id 3d109ebfe69ba511d3c6583e812996a4
 /etc/amavis/conf.d/15-av_scanners a649d3a343fc55231a6cbfa730be9383
 /etc/amavis/conf.d/15-content_filter_mode
ff3563e0243ee84609ac6550fc940e84
 /etc/amavis/conf.d/20-debian_defaults 82a326cc5433960dce50be288ac4ca5f
 /etc/amavis/conf.d/25-amavis_helpers 0e846eed3e25e7aff00142ce859fd664
 /etc/amavis/conf.d/30-template_localization
c0955e34f12453cd5af02c2d2a0fef96
 /etc/amavis/conf.d/50-user 9739f0cdb97227db6cfe63c8474275d0
 /etc/amavis/en_US/charset df071f78599059e5b73a6618f813050b
 /etc/amavis/en_US/template-auto-response.txt
5a53e5694afbabe1d17ba3d4f0c75b89
 /etc/amavis/en_US/template-dsn.txt 223a39803783bc8654854f4e26a299ef
 /etc/amavis/en_US/template-problem-feedback.txt
f81dcc93691c4c75738a3e79d46fcada
 /etc/amavis/en_US/template-release-quarantine.txt
f88b0a5cc4eae1c5b70cd3eeac60eb49
 /etc/amavis/en_US/template-spam-admin.txt
36332a61a9ec0037357d64605f620133
 /etc/amavis/en_US/template-spam-sender.txt
5cd876d98aa3f1c0cce9486f0edd988e
 /etc/amavis/en_US/template-virus-admin.txt
36109fc98bafabf3ef9098ce867c094c
 /etc/amavis/en_US/template-virus-recipient.txt
af6d5da9062ec14e733b51ee5a77e29c
 /etc/amavis/en_US/template-virus-sender.txt
d6146428b420fb5bfb34c2dd4cca7f89
 /etc/cron.d/amavisd-new 2c283e533f525067201141f167477fc8
 /etc/default/amavis-mc 6c6c2528750ddd9c16c4ffb8e4b614e8
 /etc/default/amavisd-snmp-subagent 0dada54b357dc873d1ea3f121e1f5468
 /etc/init.d/amavis 86921647364eb0221c89829a680c5c41
 /etc/init.d/amavis-mc b6b7b0034a330cf615a6cf8efa7228bb
 /etc/init.d/amavisd-snmp-subagent b60aee679ebcd5ad3fa723ba11516318
 /etc/ldap/schema/amavis.schema 6156b1e5fe1579839433480cd2a8b0e9
 /etc/spamassassin/sa-update-hooks.d/amavisd-new
aaab9a78bec4858d0bc25b1b31c6ef52
Description: Interface between MTA and virus scanner/content filters
 AMaViSd-new is a script that interfaces a mail transport agent (MTA)
with
 zero or more virus scanners, and spamassassin (optional).
 .
 It supports all common virus scanners (more than 20 different AVs),
with
 direct talk-to-daemon support for ClamAV, OpenAntiVirus, Trophie, AVG,
 f-prot, and Sophos AVs.
 .
 AMaViSd-new supports all MTAs through its generic SMTP/LMTP filter
mode
 (ideal for postfix and exim).  It is faster and safer to use the
SMTP/LMTP
 filter mode than using the AMaViS pipe client.  It supports sendmail
milter
 through the amavisd-new-milter package.
Homepage: http://www.ijs.si/software/amavisd/



root@host:/tmp# cat /etc/cron.d/amavisd-new
#
#  SpamAssassin maintenance for amavisd-new
#
# m h dom mon dow user  command
18 */3  * * *   amavis  test -e /usr/sbin/amavisd-new-
cronjob && /usr/sbin/amavisd-new-cronjob sa-sync
24 1  * * *   amavis  test -e /usr/sbin/amavisd-new-cronjob &&
/usr/sbin/amavisd-new-cronjob sa-clean



As user amavis:
$ /usr/sbin/

Bug#873929: gcc7: Enable libgo tests and rebuilds with make -C

[Svante Signell]

Source: gcc-7
Version: 7.2.0-2
Severity: important
Tags: patch

Hello,

Currently the libgo tests are not run due to a bug in libgo/Makefile.am
(and Makefile.in). This error is found on all architectures where the
testsuite is enabled. The attached patch fixes this bug as well as
enables rebuilds with
make -C build//libgo clean;
;
make -C build//libgo;
by adding more entries to the CLEANFILES target.

(The GOBENCH = entry is due to a trailing white space in the original
file)

On amd64:

tail build/x86_64-linux-gnu/libgo/libgo.sum
=== libgo Summary ===

# of expected passes145

As a side note many go tests are not run:

tail build/gcc/testsuite/go/go.sum
=== go Summary ===

# of expected passes486
# of untested testcases 834

Looking at build/x86_64-linux-gnu/libgo/libgo.log one finds:
ia3232309.c:2:6: error: size of array 'dummy' is negative
ia3232309.c:4:41: error: '__i386__' undeclared here (not in a
function); did you mean '__k8__'?

However, that problem is the subject of another bug report.

Thanks!Index: gcc-7-7.2.0/src/libgo/Makefile.am
===
--- gcc-7-7.2.0.orig/src/libgo/Makefile.am
+++ gcc-7-7.2.0/src/libgo/Makefile.am
@@ -930,7 +930,7 @@ BUILDGOX = \
 	$(SHELL) $(srcdir)/mvifdiff.sh $@.tmp `echo $@ | sed -e 's/s-gox/gox/'`
 
 GOTESTFLAGS =
-GOBENCH = 
+GOBENCH =
 
 # Check a package.
 CHECK = \
@@ -955,6 +955,7 @@ CHECK = \
 	  echo "$$RUNTESTFLAGS" | grep -q "$${MULTILIBDIR\#/*}" || run_check=; \
 	esac; \
 	if test "$$run_check" = "yes"; then \
+	if test "$(USE_DEJAGNU)" = "yes"; then \
 	  $(SHELL) $(srcdir)/testsuite/gotest --goarch=$(GOARCH) --goos=$(GOOS) --dejagnu=yes --basedir=$(srcdir) --srcdir=$(srcdir)/go/$(@D) --pkgpath="$(@D)" --pkgfiles="$$files" --testname="$(@D)" $(GOTESTFLAGS); \
 	elif test "$(GOBENCH)" != ""; then \
 	  $(SHELL) $(srcdir)/testsuite/gotest --goarch=$(GOARCH) --goos=$(GOOS) --basedir=$(srcdir) --srcdir=$(srcdir)/go/$(@D) --pkgpath="$(@D)" --pkgfiles="$$files" --bench="$(GOBENCH)" $(GOTESTFLAGS); \
@@ -969,6 +970,7 @@ CHECK = \
 	echo "FAIL: $(@D)" > $@-testsum; \
 	exit 1; \
 	  fi; \
+	fi; \
 	fi
 
 # Build all packages before checking any.
@@ -1421,7 +1423,9 @@ mostlyclean-local:
 	find . -name '*-testsum' -print | xargs rm -f
 	find . -name '*-testlog' -print | xargs rm -f
 
-CLEANFILES = *.go *.gox goc2c *.c s-version libgo.sum libgo.log
+CLEANFILES = *.go *.gox goc2c *.c s-* libgo.sum libgo.log \
+	*.dep */*.dep */*/*.dep */*/*/*.dep */*/*.dep */*/*/*/*.dep \
+	*/*/*/*/*/*.dep
 
 clean-local:
 	find . -name '*.la' -print | xargs $(LIBTOOL) --mode=clean rm -f
Index: gcc-7-7.2.0/src/libgo/Makefile.in
===
--- gcc-7-7.2.0.orig/src/libgo/Makefile.in
+++ gcc-7-7.2.0/src/libgo/Makefile.in
@@ -,6 +,7 @@ CHECK = \
 	  echo "$$RUNTESTFLAGS" | grep -q "$${MULTILIBDIR\#/*}" || run_check=; \
 	esac; \
 	if test "$$run_check" = "yes"; then \
+	if test "$(USE_DEJAGNU)" = "yes"; then \
 	  $(SHELL) $(srcdir)/testsuite/gotest --goarch=$(GOARCH) --goos=$(GOOS) --dejagnu=yes --basedir=$(srcdir) --srcdir=$(srcdir)/go/$(@D) --pkgpath="$(@D)" --pkgfiles="$$files" --testname="$(@D)" $(GOTESTFLAGS); \
 	elif test "$(GOBENCH)" != ""; then \
 	  $(SHELL) $(srcdir)/testsuite/gotest --goarch=$(GOARCH) --goos=$(GOOS) --basedir=$(srcdir) --srcdir=$(srcdir)/go/$(@D) --pkgpath="$(@D)" --pkgfiles="$$files" --bench="$(GOBENCH)" $(GOTESTFLAGS); \
@@ -1125,6 +1126,7 @@ CHECK = \
 	echo "FAIL: $(@D)" > $@-testsum; \
 	exit 1; \
 	  fi; \
+	fi; \
 	fi
 
 
@@ -1345,7 +1347,10 @@ TEST_PACKAGES = \
 	unicode/utf8/check
 
 MOSTLYCLEAN_FILES = libgo.head libgo.sum.sep libgo.log.sep
-CLEANFILES = *.go *.gox goc2c *.c s-version libgo.sum libgo.log
+CLEANFILES = *.go *.gox goc2c *.c s-* libgo.sum libgo.log \
+	*.dep */*.dep */*/*.dep */*/*/*.dep */*/*.dep */*/*/*/*.dep \
+	*/*/*/*/*/*.dep
+
 all: config.h
 	$(MAKE) $(AM_MAKEFLAGS) all-recursive
 

Bug#873928: caveconverter: please Build-Depend on rename

[Dominic Hargreaves]

Source: caveconverter
Version: 0~20170114-1
Severity: serious
Justification: FTBFS with impending change
User: debian-p...@lists.debian.org
Usertags: rename-deprecation

As announced last year[1] and as advised by deprecation messages,
rename(1) will be removed from the perl package after the stretch
release, and this is now imminent.

Your package FTBFS with perl from experimental as a result. Please
add a Build-Depends: rename to your package, and all will be well
again:

#change to unix command name in examples files
sed --in-place -e 's/java -jar CaveConverter.jar/caveconverter/' 
debian//caveconverter/usr/share/doc/caveconverter/examples/*.bat
rename 's/\.bat$//' 
debian//caveconverter/usr/share/doc/caveconverter/examples/*.bat
/bin/sh: 1: rename: not found

Let me know if you would prefer an NMU to get this trivial change made.

Cheers,
Dominic.

[1] 

Bug#873930: linux-image-4.9.0-3-amd64: nf_conntrack_sane does not work anymore

[Gian Piero Carrubba]

Package: src:linux
Version: 4.9.30-2+deb9u3
Severity: normal

Dear Maintainer,

I've recently noted that after having upgraded my home server to
stretch, I cannot use the scanner attached to the server remotely via network
anymore.

Like FTP in passive mode, the saned daemon listens on a control port
for commands, then opens up a data port for letting the client retrieve
the output file.
nf_conntrack_sane is regularly loaded, but with kernel
linux-image-4.9.0-3-amd64 it fails to recognize the connection trying to
connect to the data port as related as the established connection to the
control port.

Booting back with the linux-image-3.16.0-4-amd64 from jessie fixes the
issue.

Thanks,
Gian Piero.

-- Package-specific info:
** Version:
Linux version 4.9.0-3-amd64 (debian-ker...@lists.debian.org) (gcc version 6.3.0 
20170516 (Debian 6.3.0-18) ) #1 SMP Debian 4.9.30-2+deb9u3 (2017-08-06)

** Command line:
BOOT_IMAGE=/vmlinuz-4.9.0-3-amd64 root=/dev/mapper/valentina_main-root ro quiet

** Not tainted

** Kernel log:
Unable to read kernel log; any relevant messages should be attached

** Model information
sys_vendor: HP
product_name: ProLiant MicroServer
product_version:
chassis_vendor: HP
chassis_version:
bios_vendor: HP
bios_version: O41

** Loaded modules:
nf_conntrack_netlink
nfnetlink
cpufreq_powersave
cpufreq_conservative
cpufreq_userspace
ip6t_REJECT
nf_reject_ipv6
nf_conntrack_ipv6
nf_defrag_ipv6
nf_log_ipv6
ip6table_filter
ip6_tables
xt_multiport
xt_recent
xt_tcpudp
nf_conntrack_ipv4
nf_defrag_ipv4
xt_conntrack
ipt_REJECT
nf_reject_ipv4
nf_log_ipv4
nf_log_common
xt_LOG
xt_hashlimit
iptable_filter
nf_conntrack_sane
nf_conntrack
tun
ip_tables
x_tables
loop
parport_pc
ppdev
lp
parport
usblp
amd64_edac_mod
edac_mce_amd
edac_core
kvm_amd
kvm
irqbypass
snd_hda_codec_hdmi
snd_hda_intel
amdkfd
snd_hda_codec
pcspkr
radeon
k10temp
snd_hda_core
evdev
snd_hwdep
joydev
ttm
snd_pcm
snd_timer
drm_kms_helper
sg
snd
drm
soundcore
i2c_algo_bit
sp5100_tco
shpchp
tpm_infineon
button
acpi_cpufreq
ext4
crc16
jbd2
fscrypto
lrw
gf128mul
glue_helper
ablk_helper
cryptd
aes_x86_64
mbcache
ecb
cbc
algif_skcipher
af_alg
dm_crypt
dm_mod
raid10
raid0
multipath
linear
hid_sunplus
raid456
async_raid6_recov
async_memcpy
async_pq
async_xor
async_tx
xor
raid6_pq
libcrc32c
crc32c_generic
raid1
uas
usb_storage
md_mod
sr_mod
cdrom
sd_mod
ata_generic
hid_generic
usbhid
hid
ohci_pci
i2c_piix4
pata_atiixp
tg3
ahci
ptp
pps_core
libahci
libphy
libata
ehci_pci
ohci_hcd
ehci_hcd
scsi_mod
usbcore
usb_common

** PCI devices:
00:00.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] RS880 Host 
Bridge [1022:9601]
Subsystem: Hewlett-Packard Company RS880 Host Bridge [103c:1609]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- 
SERR- 

00:01.0 PCI bridge [0604]: Hewlett-Packard Company Device [103c:9602] (prog-if 
00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR+ FastB2B- DisINTx-
Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- 
SERR- TAbort- 
Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: 
Kernel modules: shpchp

00:02.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] RS780 PCI to PCI 
bridge (ext gfx port 0) [1022:9603] (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR+ FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: 
Kernel driver in use: pcieport
Kernel modules: shpchp

00:06.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] RS780 PCI to PCI 
bridge (PCIE port 2) [1022:9606] (prog-if 00 [Normal decode])
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR+ FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: 
Kernel driver in use: pcieport
Kernel modules: shpchp

00:11.0 SATA controller [0106]: Advanced Micro Devices, Inc. [AMD/ATI] 
SB7x0/SB8x0/SB9x0 SATA Controller [AHCI mode] [1002:4391] (rev 40) (prog-if 01 
[AHCI 1.0])
Subsystem: Hewlett-Packard Company SB7x0/SB8x0/SB9x0 SATA Controller 
[AHCI mode] [103c:1609]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR+ FastB2B- DisINTx+
Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- 
SERR- 
Kernel driver in use: ahci
Kernel modules: ahci

00:12.0 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD/ATI] 
SB7x0/SB8x0/SB9x0 USB OHCI0 Cont

Bug#873557: mbedtls: CVE-2017-14032: authentication bypass

[James Cowgill]

Hi,

On 30/08/17 20:48, Salvatore Bonaccorso wrote:
> Control: retitle mbedtls: CVE-2017-14032: authentication bypass
> 
> Hi
> 
> On Tue, Aug 29, 2017 at 12:09:30AM +0100, James Cowgill wrote:
>> Source: mbedtls
>> Version: 2.1.2-1
>> Severity: grave
>> Tags: security
>>
>> Hi,
>>
>> The following security advisory was published for mbedtls:
>> https://tls.mbed.org/tech-updates/security-advisories/mbedtls-security-advisory-2017-02
> 
> MITRE has assigned CVE-2017-14032 for this issue.

Does the attached patch look OK for stretch? I did a bit of testing with
it and it seems to fix the issue for me.

Thanks,
James
diff -Nru mbedtls-2.4.2/debian/changelog mbedtls-2.4.2/debian/changelog
--- mbedtls-2.4.2/debian/changelog  2017-03-14 10:54:33.0 +
+++ mbedtls-2.4.2/debian/changelog  2017-09-01 09:29:59.0 +0100
@@ -1,3 +1,12 @@
+mbedtls (2.4.2-1+deb9u1) stretch-security; urgency=high
+
+  * Fix CVE-2017-14032:
+If optional authentication is configured, allows remote attackers to
+bypass peer authentication via an X.509 certificate chain with many
+intermediates. (Closes: #873557)
+
+ -- James Cowgill   Fri, 01 Sep 2017 09:29:59 +0100
+
 mbedtls (2.4.2-1) unstable; urgency=high
 
   * New upstream version.
diff -Nru mbedtls-2.4.2/debian/patches/CVE-2017-14032.patch 
mbedtls-2.4.2/debian/patches/CVE-2017-14032.patch
--- mbedtls-2.4.2/debian/patches/CVE-2017-14032.patch   1970-01-01 
01:00:00.0 +0100
+++ mbedtls-2.4.2/debian/patches/CVE-2017-14032.patch   2017-09-01 
09:29:59.0 +0100
@@ -0,0 +1,149 @@
+Description: Fix CVE-2017-14032: authentication bypass
+ If a malicious peer supplies an X.509 certificate chain that has more
+ than MBEDTLS_X509_MAX_INTERMEDIATE_CA intermediates (which by default is
+ 8), it could bypass authentication of the certificates, when the
+ authentication mode was set to 'optional' eg.
+ MBEDTLS_SSL_VERIFY_OPTIONAL. The issue could be triggered remotely by
+ both the client and server sides.
+ .
+ Fix by backporting two patches from the upstream 2.6 branch:
+  d15795acd507 = Improve behaviour on fatal errors
+  31458a18788b = Only return VERIFY_FAILED from a single point
+Author: Manuel Pégourié-Gonnard 
+Origin: backport, 
https://github.com/ARMmbed/mbedtls/commit/d15795acd5074e0b44e71f7ede8bdfe1b48591fc
+Origin: backport, 
https://github.com/ARMmbed/mbedtls/commit/31458a18788b0cf0b722acda9bb2f2fe13a3fb32
+Bug-Debian: https://bugs.debian.org/873557
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+
+--- a/library/x509_crt.c
 b/library/x509_crt.c
+@@ -2055,8 +2055,8 @@ static int x509_crt_verify_child(
+ /* path_cnt is 0 for the first intermediate CA */
+ if( 1 + path_cnt > MBEDTLS_X509_MAX_INTERMEDIATE_CA )
+ {
+-*flags |= MBEDTLS_X509_BADCERT_NOT_TRUSTED;
+-return( MBEDTLS_ERR_X509_CERT_VERIFY_FAILED );
++/* return immediately as the goal is to avoid unbounded recursion */
++return( MBEDTLS_ERR_X509_FATAL_ERROR );
+ }
+ 
+ if( mbedtls_x509_time_is_past( &child->valid_to ) )
+@@ -2200,11 +2200,14 @@ int mbedtls_x509_crt_verify_with_profile
+ mbedtls_x509_sequence *cur = NULL;
+ mbedtls_pk_type_t pk_type;
+ 
+-if( profile == NULL )
+-return( MBEDTLS_ERR_X509_BAD_INPUT_DATA );
+-
+ *flags = 0;
+ 
++if( profile == NULL )
++{
++ret = MBEDTLS_ERR_X509_BAD_INPUT_DATA;
++goto exit;
++}
++
+ if( cn != NULL )
+ {
+ name = &crt->subject;
+@@ -2278,7 +2281,7 @@ int mbedtls_x509_crt_verify_with_profile
+ ret = x509_crt_verify_top( crt, parent, ca_crl, profile,
+pathlen, selfsigned, flags, f_vrfy, p_vrfy 
);
+ if( ret != 0 )
+-return( ret );
++goto exit;
+ }
+ else
+ {
+@@ -2293,17 +2296,28 @@ int mbedtls_x509_crt_verify_with_profile
+ ret = x509_crt_verify_child( crt, parent, trust_ca, ca_crl, 
profile,
+  pathlen, selfsigned, flags, f_vrfy, 
p_vrfy );
+ if( ret != 0 )
+-return( ret );
++goto exit;
+ }
+ else
+ {
+ ret = x509_crt_verify_top( crt, trust_ca, ca_crl, profile,
+pathlen, selfsigned, flags, f_vrfy, 
p_vrfy );
+ if( ret != 0 )
+-return( ret );
++goto exit;
+ }
+ }
+ 
++exit:
++/* prevent misuse of the vrfy callback */
++if( ret == MBEDTLS_ERR_X509_CERT_VERIFY_FAILED )
++ret = MBEDTLS_ERR_X509_FATAL_ERROR;
++
++if( ret != 0 )
++{
++*flags = (uint32_t) -1;
++return( ret );
++}
++
+ if( *flags != 0 )
+ return( MBEDTLS_ERR_X509_CERT_VERIFY_FAILED );
+ 
+--- a/include/mbedtls/error.h
 b/include/mbedtls/error.h
+@@ -71,7 +71,7 @@
+  * Name  ID  Nr of Errors
+  * PEM   1   9
+  * PKCS#12   1   4 (Started from top)
+- * 

Bug#873931: nm-applet missing on MATE and Xfce desktop

[Holger Levsen]

package: debian-edu
x-debbugs-cc: debian-...@lists.debian.org

On Thu, Aug 31, 2017 at 10:29:02PM +0200, Wolfgang Schweer wrote:
> > tasks/{standalone,roaming-workstation}: Ideally both 
> > network-manager applets are available (plasma-nm, 
> > network-manager-gome). As we don't know the desktop-environment, let's 
> > pull in both.
> 
> After investigating this issue I noticed:
> 
> GNOME: nothing to do (gnome depends on network-manager-gnome)
> KDE Plasma: ditto (kde-standard depends on plasma-nm)
> LXDE: ditto (lxde depends on wicd)
> LXQt: ditto (lxqt depends on cmst) [cmst: 'connman system tray']
> MATE: network-manager-gnome needs to be installed
> Xfce: network-manager-gnome needs to be installed; also, 
>   tasks/desktop-xfce needs xfce4-notifyd as additional dependency
>   to actually let the applet show up in the system tray.
> 
> IMO only one applet for each DE is needed / wanted.
> So tasks/standalone and tasks/roaming-workstation should depend on
> network-manager-gnome | plasma-nm | cmst | wicd
> 
> Please check.


-- 
cheers,
Holger


signature.asc
Description: Digital signature

Bug#873933: please drop transitional package qml-module-org-kde-extensionplugin

[Holger Levsen]

Package: qml-module-org-kde-extensionplugin
Version: 5.28.0-1
Severity: normal
user: qa.debian@packages.debian.org
usertags: transitional

Please drop transitional package qml-module-org-kde-extensionplugin for Buster, 
as it has been released with Stretch.

Thanks for maintaining kactivities-kf5!


-- 
cheers,
Holger


signature.asc
Description: Digital signature

Bug#873932: please drop transitional package libkf5akonadicore-bin

[Holger Levsen]

Package: libkf5akonadicore-bin
Version: 4:16.04.3-4
Severity: normal
user: qa.debian@packages.debian.org
usertags: transitional

Please drop transitional package libkf5akonadicore-bin for Buster, as it has 
been released with Stretch.

Thanks for maintaining akonadi!


-- 
cheers,
Holger


signature.asc
Description: Digital signature

Bug#754462: Bug#862051: nodejs (6.11.2~dfsg-1) experimental; urgency=medium

[Ian Jackson]

Jérémy Lal writes ("Re: Bug#754462: Bug#862051: nodejs (6.11.2~dfsg-1) 
experimental; urgency=medium"):
> So, a short NEWS entry explaining /usr/bin/node is now available by default,
> and that /usr/bin/nodejs will stay available indefinitely ?
> Or even nothing and just a changelog entry ?

I would go for the latter, personally.

My philosophy is that a NEWS entry is something you use when people
have to change something.  The best packages do not need NEWS entries
because they simply keep working.  Starting to provide /usr/bin/node
and keeping /usr/bin/nodejs means that no-one has to change anything,
which is perfect - and therefore we don't need to bother users.

It's true that NEWS might be used when a new opportunity arises that
means many users might want to change something, even though they
don't have to.  I would reserve that for situations where the user's
existing setup is (likely to be) hazardous or seriously suboptimal,
especially in a non-obvious way.

Existing scripts that use /usr/bin/nodejs are not as portable to other
OSes as they could be, but of course the script's author will probably
be aware of that already.  It doesn't seem to me to be the kind of
opportunity for remedying a significant defect that would warrant a
NEWS entry.

However:

One thing you I would consider is that it would be nice if scripts in
Debian packages were made more portable to other distros.  So Debian
packages should gradually change to use /usr/bin/node.  I am very
conservative about these things because I like to keep backporting
(within Debian) as easy as possible.  So if I were the maintainer of a
node.js package which had scripts mentioning /usr/bin/nodejs, I would
probably make that change in buster+1 rather than in buster.

In buster+1 you should probably consider asking for a lintian warning
about references to /usr/bin/nodejs.  Not because you intend to drop
/usr/bin/nodejs ever (why do that - see previous emails) but because
it would be better, as I've just discussed, for Debian packages to
contain fewer hurdles to adoption elsewhere.

Regards,
Ian.

-- 
Ian JacksonThese opinions are my own.

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

Bug#871697: jellyfish: Please add arm64

[Andreas Tille]

On Fri, Sep 01, 2017 at 07:06:46AM +0100, Edmund Grimley Evans wrote:
> 
> "portability.patch" is commented out in debian/patches/series and was
> not applied?

Thanks for watching me. ;-)

 Andreas.

-- 
http://fam-tille.de

Bug#873934: apt: apt_auth.conf man page is not installed

[Felix Geyer]

Package: apt
Version: 1.5~rc1
Severity: minor

apt prints:
> N: Usage of apt_auth.conf(5) should be preferred over embedding login 
> information directly in the sources.list(5) entry for [...]

but the man page is not actually included in the package.


>From the build log:
> dh_missing: usr/share/man/man5/apt_auth.conf.5 exists in debian/tmp but is 
> not installed to anywhere

Bug#682264: #682264,libapache2-mod-perl2: Crash at server startup when pre-loading Plack app

[Kjetil Kjernsmo]

On Friday, 1 September 2017 10:33:38 CEST Dominic Hargreaves wrote:
> Kjetil, do you have any additional observations about this bug since
> it was first filed in 2012? (For example did you find out that it
> was in fact caused by use of the event mpm?)

To be honest, I don't remember anything about it...  I probably just 
switched to prefork too. Nowadays, I run my stuff with uwsgi and ngnix.

I feel there are many things that have improved when considering automating 
installation and configuration with uwsgi, so from my perspective just an  
improved error message would be the right approach.

Best,

Kjetil

Bug#871514: gcc-7: miscompiles stack spills on mips64el

[James Cowgill]

Control: tags -1 patch

Hi,

On 23/08/17 17:42, James Cowgill wrote:
> This bug is very closely related to an earlier GCC bootstrap failure on
> mips64el: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78660
> In comment 17 Matthew sent a patch and applying it also fixes this bug.
> However, he tells me it has some other issues and isn't suitable to be
> applied (which is presumably why it was reverted).

Matthew has now had a better look at the bug and has posted a patch to
fix it which is a tweaked version of the patch above:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81803#c9

I've done some testing, and it seems to solve all the known package
failures (at least the ones on my list) caused by this bug and I haven't
noticed any failures with it. I also tested it on armhf and it causes no
regressions there (this was one of the issues with the earlier patch).

So I think the attached debdiff should be applied to gcc-7. Currently
the patch is applied everywhere, but if you want you could limit it to
mips64el.

Thanks,
James
diff -u gcc-7-7.2.0/debian/rules.patch gcc-7-7.2.0/debian/rules.patch
--- gcc-7-7.2.0/debian/rules.patch
+++ gcc-7-7.2.0/debian/rules.patch
@@ -72,6 +72,7 @@
gcc-fuse-ld-lld \
libgo-s390x-default-isa \
pr81829 \
+   gcc-mips64-stack-spilling \
 
 
 #  $(if $(filter yes, $(DEB_CROSS)),,gcc-print-file-name) \
only in patch2:
unchanged:
--- gcc-7-7.2.0.orig/debian/patches/gcc-mips64-stack-spilling.diff
+++ gcc-7-7.2.0/debian/patches/gcc-mips64-stack-spilling.diff
@@ -0,0 +1,16 @@
+--- a/src/gcc/lra-constraints.c
 b/src/gcc/lra-constraints.c
+@@ -4235,7 +4235,12 @@ curr_insn_transform (bool check_only_p)
+ && (goal_alt[i] == NO_REGS
+ || (simplify_subreg_regno
+ (ira_class_hard_regs[goal_alt[i]][0],
+- GET_MODE (reg), byte, mode) >= 0)
++ GET_MODE (reg), byte, mode) >= 0
++|| (type != OP_IN
++&& GET_MODE_PRECISION (mode)
++< GET_MODE_PRECISION (GET_MODE (reg))
++&& GET_MODE_SIZE (GET_MODE (reg)) <= UNITS_PER_WORD
++&& WORD_REGISTER_OPERATIONS))
+   {
+ /* An OP_INOUT is required when reloading a subreg of a
+mode wider than a word to ensure that data beyond the


signature.asc
Description: OpenPGP digital signature

Bug#873935: grub-coreboot: Explain use cases and what it does

[Julian Andres Klode]

Package: grub-coreboot
Version: 2.02-2
Severity: minor

I'm currently evaluating coreboot (reading a bit about it)
and came across this package and wonder what its purpose is.

I assume it is supposed to be chainloaded from an initial coreboot
payload, but since it's missing any instructions whatsoever, I can't
really figure out what it's doing.

I noticed it is creating a '/boot/grub/i386-coreboot/core.elf', so
I assume you could build like a FILO or grub2 coreboot image that
essentially chainloads a grub/i386-coreboot/core.elf binary from
a hard disk, but if you already have grub2 in the coreboot image,
it seems pointless to chainload into another one, so I really
can't see the usual use case here.

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

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

Versions of packages grub-coreboot depends on:
ii  debconf1.5.63
ii  dpkg   1.18.24
ii  grub-common2.02-2
ii  grub-coreboot-bin  2.02-2
ii  grub2-common   2.02-2
ii  ucf3.0036

grub-coreboot recommends no packages.

grub-coreboot suggests no packages.

-- debconf information excluded

-- 
Debian Developer - deb.li/jak | jak-linux.org - free software dev
  |  Ubuntu Core Developer |
When replying, only quote what is necessary, and write each reply
directly below the part(s) it pertains to ('inline').  Thank you.

Bug#873936: Backporting proxy usage

[Frank Brütting]

Package: chrome-gnome-shell
Version: 8.4

I’m not that sure of the version, I have Debian Stretch 9.1 at work 
but I’m not there at the moment, should be 8.4.


The shipped version doesn’t make use of proxy settings, so everytime 
I log into the shell, I get displayed a message, that CGS cannot 
connect to the internet (in our corporate environment). This is fixed 
in master, please backport this!


Here’s the link to my bug report against CGS:
https://bugzilla.gnome.org/show_bug.cgi?id=787101

Additionally, I cannot install gnome shell extensions via Firefox. If 
this won’t be solved by this bug, it would be nice if it would be 
solved otherwise!


Best regards,
Frank

Bug#873876: apt-cacher: File size mismatch error when downloading similar to #755184

[Mark Hindley]

On Fri, Sep 01, 2017 at 11:57:41AM +0100, Mark Hindley wrote:
> > I have squid and apt-cacher installed on the same server, at first I thought
> > they were in conflict but with further anylsis squid is not involved at 
> > all. I
> > tried to route the traffic through squid using http_proxy = 127.0.0.1:8080 
> > and
> > 127.0.0.1:80 and 10.1.0.1:8080 and 10.1.0.1:80 but all of those attempts
> > received a 503. Can apt-cacher use squid on the same server?
> 
> Yes, I have used apt-cacher with an upstream cache with no problems.

It has occurred to me that insufficient free space will also trigger 503 from
most caches as well.

What is the descriptive text attached to the 503 error?

Mark

Bug#868558: nmu: multiple r-* packages

[Dirk Eddelbuettel]

Emilio,

Thanks for your follow-up.  I will try to get to each point.

On 1 September 2017 at 11:42, Emilio Pozuelo Monfort wrote:
| What Niels meant is whether having an old, non-rebuilt R module with the new
| r-base works, 

Yes, in general, and here in this case.

| and whether having a new, rebuilt R module with the old r-base

Yes.

(You get a warning when you run, say, R 3.3.3 and load a module built with R
3.4.1: "foo was built with R 3.4.1".  But it is harmless. It still works.)

| works. Is that so? Sorry if you already answered this, but it's not clear to 
me
| and I'm not familiar with R at all so it's possible that I missed it.

I am.

(20 year R user; package developer; contributor; R Foundation Board member)

| >From your initial post, you say that the new R breaks loading optional code 
with
| two of the available mechanisms. 

Allow me to repeat and stress:

  From R (< 3.4.0) to R (>= 3.4.0) the mechanism to use dynamically-loadable
  modules via .C() and .Fortran() changed, and requires a rebuild for the
  __subset of packages have loadable modules__ and the __subset of those
  packages actually using .C() and .Fortran() and not .Call()__ and the
  __subset of those package actually deploying the (before-than optional)
  registration mechanism.

It is a subset of a subset of a subset that is affected,

I identified the subset and asked the release team for 46 binNMUs.

| That seems to imply that having a non-rebuilt module with the new R 3.4 would 
break (some things). Right?

I do not think so.  And I am not aware of a bug report anywhere (here in
Debian or the wider R community) seeing it.

This issue is not an ABI/API change.  We very likely will get one of those in
April with R 3.5.0.  And as it stands, we'll all just wait for that. 

Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Bug#677508: gnome-terminal: received signal SIGSEGV in g_object_notify kills all terminals

[doak]

All terminal windows will still be closed if any one is killed by an SIGSEGV.

Version:
ii  gnome-terminal  3.22.2-1   amd64  GNOME terminal emulator 
application

There is a workaround starting a dedicated 'gnome-terminal-server:
  
https://unix.stackexchange.com/questions/201900/run-true-multiple-process-instances-of-gnome-terminal

Regards,
doak

Bug#873937: dpkg: should include information about the used kernel in .buildinfo files

[Holger Levsen]

Source: dpkg
Version: 1.8.24
Severity: wishlist
User: reproducible-bui...@lists.alioth.debian.org
Usertags: toolchain
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi Guillem,

during discussing #844431 it became clear, that some information about the
running kernel should be included in .buildinfo files, as this can affect the
build.

For a start, including the output of "uname -s -r -v -m -i -o" (so basically
uname -a without the hostname) would be better than the current status quo,
though it would probably be even nicer to also include a hash of
/proc/config.gz or maybe even the whole thing.

Filing a bug now so that we can discuss the best implementation.

Thanks for maintaining dpkg!


-- 
cheers,
Holger


signature.asc
Description: Digital signature

Bug#873878: [gluster-packaging] Fwd: Bug#873878: glusterfs-client: mount.glusterfs needs bash as /bin/sh

[Patrick Matthäi]

Am 01.09.2017 um 11:40 schrieb Niels de Vos:
> On Fri, Sep 01, 2017 at 09:36:16AM +0200, Patrick Matthäi wrote:
>> Hi,
>>
>> how should it be fixed for glusterfs now? Better shell code without
>> bashishm or do you want /bin/bash as shebang?
> Do you have a preference? I do not know how much work is it is to
> rewrite the mount.glusterfs script to remove all the Bashisms. At least
> in the Debian builds you may want to patch it to /bin/bash for the time
> being.

I would prefer a patch, so that it works without bash. Luckily the bug
reporter just wrote a patch :)
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=873878#10

If you would merge it, I also would add it to the repository. I have
attached two other patches for 3.12.x, too.

>
> Opinions welcome :) Thanks,
> Niels
>
>>
>>
>>  Weitergeleitete Nachricht 
>> Betreff: Bug#873878: glusterfs-client: mount.glusterfs needs bash as
>> /bin/sh
>> Weitersenden-Datum:  Thu, 31 Aug 2017 20:21:01 +
>> Weitersenden-Von:Michael Lundkvist 
>> Weitersenden-An: debian-bugs-dist@lists.debian.org
>> Weitersenden-CC: Patrick Matthäi 
>> Datum:   Thu, 31 Aug 2017 21:46:18 +0200
>> Von: Michael Lundkvist 
>> Antwort an:  Michael Lundkvist ,
>> 873...@bugs.debian.org
>> An:  Debian Bug Tracking System 
>>
>>
>>
>> Package: glusterfs-client
>> Version: 3.12.0-1
>> Severity: serious
>> Tags: upstream
>> Justification: Policy 10.4
>>
>> Version 3.12 of Glusterfs adds code in /sbin/mount.glusterfs that depends on 
>> bash.
>>
>> With dash as /bin/sh, I get the following error message when trying to mount 
>> a glusterfs volume:
>>> /sbin/mount.glusterfs: 667: /sbin/mount.glusterfs: Bad substitution
>> Line 667 is:
>> 667 [ ${volume_str:0:1} = '/' ] && {
>>
>> Modifying mount.glusterfs to use /bin/bash makes it possible to mount again.
>>
>> /Micke
>>
>>
>> -- System Information:
>> Debian Release: buster/sid
>>   APT prefers unstable
>>   APT policy: (500, 'unstable')
>> Architecture: amd64 (x86_64)
>>
>> Kernel: Linux 4.12.0-1-amd64 (SMP w/4 CPU cores)
>> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
>> LANGUAGE=en_US:en (charmap=UTF-8)
>> Shell: /bin/sh linked to /bin/dash
>> Init: systemd (via /run/systemd/system)
>>
>> Versions of packages glusterfs-client depends on:
>> ii  fuse  2.9.7-1
>> ii  glusterfs-common  3.12.0-1
>> ii  libc6 2.24-17
>> ii  libssl1.1 1.1.0f-5
>> ii  python2.7.13-2
>>
>> glusterfs-client recommends no packages.
>>
>> glusterfs-client suggests no packages.
>>
>> -- no debconf information
>>
>> ___
>> packaging mailing list
>> packag...@gluster.org
>> http://lists.gluster.org/mailman/listinfo/packaging

-- 
/*
Mit freundlichem Gruß / With kind regards,
 Patrick Matthäi
 GNU/Linux Debian Developer

  Blog: http://www.linux-dev.org/
E-Mail: pmatth...@debian.org
patr...@linux-dev.org
*/

# Fix syntax error in shell script.

diff -Naur 
glusterfs-3.11.1.orig/extras/hook-scripts/create/post/S10selinux-label-brick.sh 
glusterfs-3.11.1/extras/hook-scripts/create/post/S10selinux-label-brick.sh
--- 
glusterfs-3.11.1.orig/extras/hook-scripts/create/post/S10selinux-label-brick.sh 
2017-06-27 17:25:12.237136825 +0200
+++ glusterfs-3.11.1/extras/hook-scripts/create/post/S10selinux-label-brick.sh  
2017-07-03 16:21:05.113301642 +0200
@@ -43,7 +43,7 @@
 do
 # Add a file context for each brick path and associate with the
 # glusterd_brick_t SELinux type.
-semanage fcontext --add -t glusterd_brick_t -r s0 $b(/.*)?
+semanage fcontext --add -t glusterd_brick_t -r s0 $b
 
 # Set the labels on the new brick path.
 restorecon -R $b
# Fix new spelling errors.

diff -Naur glusterfs-3.12.0.orig/xlators/mgmt/glusterd/src/glusterd-geo-rep.c 
glusterfs-3.12.0/xlators/mgmt/glusterd/src/glusterd-geo-rep.c
--- glusterfs-3.12.0.orig/xlators/mgmt/glusterd/src/glusterd-geo-rep.c  
2017-08-30 14:46:33.875359178 +0200
+++ glusterfs-3.12.0/xlators/mgmt/glusterd/src/glusterd-geo-rep.c   
2017-08-31 10:43:14.228479030 +0200
@@ -3615,7 +3615,7 @@
 "geo-replication start failed",
 strerror (errno));
 snprintf (errmsg, sizeof(errmsg),
-  "fuse unvailable");
+  "fuse unavailable");
 ret = -1;
 goto out;
 }
diff -Naur 
glusterfs-3.12.0.orig/xlators/mgmt/glusterd/src/glusterd-volume-set.c 
glusterfs-3.12.0/xlators/mgmt/glusterd/src/glusterd-volume-set.c
--- glusterfs-3.12.0.orig/xlators/mgmt/glusterd/src/glusterd-volume-set.c   
2017-08-30 14:46:33.901359256 +0200
+++ glusterfs-3.12.0/xlators/mgmt/glusterd/src/glusterd-volume-s

Bug#873929: gcc7: Enable libgo tests and rebuilds with make -C

[Matthias Klose]

On 01.09.2017 11:55, Svante Signell wrote:
> Source: gcc-7
> Version: 7.2.0-2
> Severity: important
> Tags: patch
> 
> Hello,
> 
> Currently the libgo tests are not run due to a bug in libgo/Makefile.am
> (and Makefile.in). This error is found on all architectures where the
> testsuite is enabled. The attached patch fixes this bug as well as
> enables rebuilds with
> make -C build//libgo clean;
> ;
> make -C build//libgo;
> by adding more entries to the CLEANFILES target.
> 
> (The GOBENCH = entry is due to a trailing white space in the original
> file)

ok, this is the libgo-testsuite.diff patch.  Why do you test USE_DEJAGNU twice 
then?

The go testsuite is special, because it's normally run from every multilib
directory instead of the top libdir only.

Bug#873508: sparse test failures on ppc32le (and other not so common archs)

[Antoine Beaupré]

On 2017-09-01 09:46:44, Uwe Kleine-König wrote:
> Hello,
>
> On Thu, Aug 31, 2017 at 11:43:53PM +0100, Ramsay Jones wrote:
>> On 31/08/17 21:55, Uwe Kleine-König wrote:
>> > On Wed, Aug 30, 2017 at 08:11:49PM -0400, Christopher Li wrote:
>> >> That is very much like on x86_64 missing define "#weak_define __x86_64__ 
>> >> 1"
>> >>
>> >> Does cgcc work for you? In the future we do want to move the archetecture
>> >> related define from cgcc into sparse by itself. For now you can set
>> >> "sparse" as "cgcc -no-compile"
>> > 
>> > Yes that works. So to address the Debian bug I can do:
>> > 
>> >  - move sparse to /usr/lib
>> >  - teach cgcc about the move of sparse
>> >  - make /usr/bin/sparse call cgcc -no-compile "$@"
>> 
>> Hmm, I don't think that would be a good idea ...
>> 
>> > or is it easier to teach sparse about the architecture stuff?
>> 
>> I now understand (I think!) that you are building a sparse
>> package (presumably a .deb) and you are concerned that sparse
>> does not pass it's own testsuite on those platforms.
>
> Nearly right. I'm responsible for the sparse Debian package and the
> problem at hand is https://bugs.debian.org/873508. This bug report has
> "Severity: serious" wihch might eventually result in the removal of
> sparse from the Debian archive.
>
> @anarcat: Given that cgcc seems to work, would you agree to apply the
> following patch to horst:
>
> diff --git a/Makefile b/Makefile
> index 4f924fa..d563652 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -110,7 +110,7 @@ $(NAME): $(OBJS)
>  $(OBJS): .buildflags
>  
>  check:
> - sparse $(CFLAGS) *.[ch]
> + cgcc -no-compile $(CFLAGS) *.[ch]
>  
>  clean:
>   -rm -f *.o radiotap/*.o *~
>
> and downgrade the bug to "important"? That would be a compromise that
> buys us a bit of time.

Well right now I have simply disabled the checks for those broken
architectures, so sparse isn't as affected anymore.

Frankly, I don't quite know what to do with this - but I'd be happy to
happly that patch to sparse if it fixes the issue better.

A.

-- 
Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety.
- Benjamin Franklin, 1755

Bug#873876: apt-cacher: File size mismatch error when downloading similar to #755184

[Mark Hindley]

On Thu, Aug 31, 2017 at 12:44:41PM -0700, michael goff wrote:
> Package: apt-cacher
> Version: 1.7.10+deb8u2
> Severity: important
> 
> Dear Maintainer,
> 
> Greetings, I have the most current apt-cacher in the raspbian repository, 
> using armhf.
> I found ticket #755184 which seems to be the same problem but reported at a
> different version number.
> When trying to perform apt-get on a large package that is not in the cache 
> the download will begin then fail and start over again, repetedly.
> doing tail on the error file and watch on the file being downloaded the error 
> msg happens at the same time as the file size being reset to 0B.
> Wed Aug 30 02:07:26 2017|info [9904]: ALARM!
> /mnt/addon/apt-cacher-cache/packages/archive.raspberrypi.org_debian/wolfram-engine_11.0.1+2017031701_armhf.deb
> file size mismatch (found 5259264, expected 240084788). Renaming to
> /mnt/addon/apt-cacher-cache/packages/archive.raspberrypi.org_debian/wolfram-engine_11.0.1+2017031701_armhf.deb.corrupted.

Michael,

If this occurs with any large file it is different to #755184 (which is fixed
AFAIK). Are you sure there is enough space on the partition to cache a 240MB
package?

If there is enough free space, can you send /var/log/apt-cacher/error.log with
debugging enabled for a single file. You can use wget to do a single manual file
request.

> I have squid and apt-cacher installed on the same server, at first I thought
> they were in conflict but with further anylsis squid is not involved at all. I
> tried to route the traffic through squid using http_proxy = 127.0.0.1:8080 and
> 127.0.0.1:80 and 10.1.0.1:8080 and 10.1.0.1:80 but all of those attempts
> received a 503. Can apt-cacher use squid on the same server?

Yes, I have used apt-cacher with an upstream cache with no problems.

> I would like to
> use this feature while this bug is being looked at, maybe even
> perminently. What am I doing wrong with that? I changed the squid port to 8080
> btw. The private address the server uses is 10.1.0.1.

If you have changed squid to 8080 then :80 won't work.

You need to see if apt-cacher is returning the 503 or if squid is not configured
correctly. Do a single request both to squid directly and through apt-cacher
using something that will show you the response headers (HEAD, wget -S etc.)

> The problem is reproducable on any large file.

Define large. What is the threshold to trigger it?

Mark

Bug#873938: RFS: engauge-digitizer/10.3+ds.1-1

[Tobias Winchen]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "engauge-digitizer"

 * Package name: engauge-digitizer
   Version : 10.3+ds.1-1
  Upstream Author : Mark Mitchell 
 * URL : https://github.com/markummitchell/engauge6
 * License : GPL-2+
   Section : science

  It builds those binary packages:

engauge-digitizer - interactively extracts numbers from bitmap graphs or 
maps
 engauge-digitizer-doc - engauge-digitizer user manual and tutorial

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

  https://mentors.debian.net/package/engauge-digitizer


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

dget -x https://mentors.debian.net/debian/pool/main/e/engauge-digitizer/
engauge-digitizer_10.3+ds.1-1.dsc

  More information about hello can be obtained from https://www.example.com.

  Changes since the last upload:

  * New upstream release
  * Updated to standards version 4.0.0
  * engauge-digitizer-doc as Multi-Arch: foreign


  Regards,
   Tobias Winchen

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

Bug#873940: ITP: libluksmeta -- LUKSMeta is a simple library for storing metadata in the LUKSv1 header

[Christoph Biedl]

Package: wnpp
Severity: wishlist
Owner: Christoph Biedl 

* Package name: libluksmeta
  Version : 7
  Upstream Author : Nathaniel McCallum https://github.com/npmccallum
* URL : https://github.com/latchset/luksmeta
* License : LGPL-2.1+
  Programming Lang: C
  Description : LUKSMeta is a simple library for storing metadata in the 
LUKSv1 header

LUKSmeta is a dependency for clevis which I've just ITP'd (#854410), and
probably needed by tang as well (ITP is #854409).

Christoph



signature.asc
Description: Digital signature

Bug#873939: ITP: libjose -- Jose is a C-language implementation of the Javascript Object Signing and Encryption standards?=

[Christoph Biedl]

Package: wnpp
Severity: wishlist
Owner: Christoph Biedl 

* Package name: libjose
  Version : 9
  Upstream Author : Nathaniel McCallum https://github.com/npmccallum
* URL : https://github.com/latchset/jose
* License : Apache-2.0
  Programming Lang: C
  Description : José is a C-language implementation of the Javascript 
Object Signing and Encryption standards

Quoting the project homepage:

| José is a C-language implementation of the Javascript Object Signing
| and Encryption standards. Specifically, José aims towards implementing
| the following standards:
| 
| RFC 7515 - JSON Web Signature (JWS)
| RFC 7516 - JSON Web Encryption (JWE)
| RFC 7517 - JSON Web Key (JWK)
| RFC 7518 - JSON Web Algorithms (JWA)
| RFC 7519 - JSON Web Token (JWT)
| RFC 7520 - Examples of ... JOSE
| RFC 7638 - JSON Web Key (JWK) Thumbprint
| 
| José is extensively tested against the RFC test vectors.

Jose is a dependency for tang which I've just ITP'd (#854409).

Christoph


signature.asc
Description: Digital signature

Bug#854409: RFP: tang -- A server for binding data to network presence

[Christoph Biedl]

retitle 854409 ITP: tang -- A server for binding data to network presence
owner 854409 !
thanks

Guido Günther wrote...

> * Package name: tang
>   Version : 4
>   Upstream Author : Nathaniel McCallum
> * URL : https://github.com/latchset/tang

> The client side is implemented in clevis. The only missing dependency in
> Debian is jose a C-language implementation of the Javascript Object
> Signing and Encryption standards.

ITP for jose will follow shortly.

Christoph


signature.asc
Description: Digital signature

Bug#854410: RFP: clevis -- A plugable framework for automated decryption.

[Christoph Biedl]

retitle 854410 ITP: clevis -- A plugable framework for automated decryption.
owner 854410 !
thanks

Guido Günther wrote...

> * Package name: clevis
>   Version : 2
>   Upstream Author : Nathaniel McCallum
> * URL : http://www.example.org/

That should be https://github.com/latchset/clevis

FWIW, depends also on luksmeta, ITP will follow shortly.

Christoph


signature.asc
Description: Digital signature

Bug#709988: python-evdev: changing back from ITP to RFP

[Stephen Kitt]

Control: retitle -1 ITP: python-evdev -- python bindings for the generic input 
event interface
Control: owner -1 !

This is now needed for libratbag.

Bug#873508: sparse test failures on ppc32le (and other not so common archs)

[Christopher Li]

On Fri, Sep 1, 2017 at 3:46 AM, Uwe Kleine-König  wrote:
\>
> Nearly right. I'm responsible for the sparse Debian package and the
> problem at hand is https://bugs.debian.org/873508. This bug report has
> "Severity: serious" wihch might eventually result in the removal of
> sparse from the Debian archive.
>
> @anarcat: Given that cgcc seems to work, would you agree to apply the
> following patch to horst:
>
> diff --git a/Makefile b/Makefile
> index 4f924fa..d563652 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -110,7 +110,7 @@ $(NAME): $(OBJS)
>  $(OBJS): .buildflags
>
>  check:
> -   sparse $(CFLAGS) *.[ch]
> +   cgcc -no-compile $(CFLAGS) *.[ch]

You patch definitely works.
I think it is the better way to fix it.
Sparse "selfcheck" target was doing the same thing.
It is using "cgcc -no-compile" already.

I suggest in your patch you can do some thing
similar to "selfcheck" target:

CHECKER = cgcc -no-compile

 $(CHECKER) $(CFLAGS) *.[ch]

Later when we update sparse to handle architecture
properly. We can just invoke make with "CHECKER="
to test.


> and downgrade the bug to "important"? That would be a compromise that
> buys us a bit of time.

Agree.

>
> This only solves a part of the problem because the bug report is about
> sparse itself, not it's llvm part.

I agree with that too.

Chris

Bug#868558: nmu: multiple r-* packages

[Emilio Pozuelo Monfort]

On 01/09/17 13:25, Dirk Eddelbuettel wrote:
> 
> Emilio,
> 
> Thanks for your follow-up.  I will try to get to each point.
> 
> On 1 September 2017 at 11:42, Emilio Pozuelo Monfort wrote:
> | What Niels meant is whether having an old, non-rebuilt R module with the new
> | r-base works, 
> 
> Yes, in general, and here in this case.

Then I don't understand why these binNMUs are needed.

>From #861333 OP:

"With current R, R packages built for Debian before the upload of R
3.3.3.20170413-1
on 14 April that use .C or .Fortran do no work properly, because the functions
calling .C or .Fortran do not find the compiled objects."

That tells me that if you upgrade R but don't upgrade some modules, those will
(partially) break. Hence we need either an ABI bump, or versioned breaks against
the affected modules in r-base.

Cheers,
Emilio

Bug#871956: lintian: false positive: binary-file-built-without-LFS-support on x32

[Adam Borowski]

On Fri, Sep 01, 2017 at 09:51:56AM +0100, Chris Lamb wrote:
> > false positive: binary-file-built-without-LFS-support on x32
> 
> I think the next step here would be to identify which of these
> archs should be skipped for this check:
> 
>   
> https://anonscm.debian.org/git/lintian/lintian.git/tree/data/common/architectures

I'm afraid I don't know how to check this in a systematic way.
* x32 is a fully functional second-class Debian port, so all it takes is to
  compile and run printf("%ld", sizeof(off_t));
* arm64ilp32 has Documentation/arm64/ilp32.txt say: "off_t is s64 type."
... but what about the rest?

Thus, unless someone knows where the authoritative table these definitions
come from is, I'd suggest just marking what we have an idea about.  It's not
like lintian warnings matter for something that's not in the archive...

Also, the vast majority of packages don't trigger this warning as they
request LFS unconditionally instead of trying to autodetect it.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢰⠒⠀⣿⡁ Vat kind uf sufficiently advanced technology iz dis!?
⢿⡄⠘⠷⠚⠋⠀ -- Genghis Ht'rok'din
⠈⠳⣄ 

Bug#873508: sparse test failures on ppc32le (and other not so common archs)

[Christopher Li]

On Fri, Sep 1, 2017 at 3:02 AM, Josh Triplett  wrote:
>> First of all. It is not very trivial to teach sparse about the architecture
>> stuff. To my mind, we need to move all the cgcc logic into sparse.
>
> Related to that: while it would mean we couldn't necessarily just rely
> entirely on GCC's definitions for a target platform, I think in an ideal
> world we could have a sparse binary that understood *all* target
> platforms at once, such that you could ask Sparse on x86_64 to "compile"

Yes, that is what I want to have. It is list as one of the project in
project idea document as well. I have  a related question. How do we
test the different architecture handling without actually run sparse
on different platform? I am thinking maybe using gcc cross platform
compiler and compare some macro against the sparse one.

> as though targeting any arbitrary architecture. That would also have the
> major advantage of making it easy to run the Sparse testsuite for
> *every* target architecture without needing compilers for every such
> architecture.

Another way to fix the test suite for now would be let testsuite
specify using cgcc instead of sparse directly, for the test source
that needs it. That will buy us some time. Fixing sparse properly
in the long term obvious would be better.

Chris

Bug#873941: ImportError: undefined symbol: PyFPE_jbuf on some modules

[Sébastien “Elzen” Dufromentel]

Package: python3.5
Version: 3.5.4-3
Severity: normal

Hi,

I upgraded today to python3.5=3.5.4-3, and some modules can no more be
imported, causing the subject-given exception.

As an example, importing SFML on the interpretor:

seth@fadreils: ~$ python3
Python 3.5.4 (default, Aug 31 2017, 12:22:39)
[GCC 7.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.

~~~> import sfml
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python3/dist-packages/sfml/__init__.py", line 3, in 
import sfml.graphics
ImportError: /usr/lib/python3/dist-
packages/sfml/graphics.cpython-35m-x86_64-linux-gnu.so: undefined symbol:
PyFPE_jbuf
~~~>

I have the same problem with some home-made python modules compiled to .so
using cython3 (but import the .py source file instead works perfectly).

I tried to downgrade to the 3.5.4-2 version of the package, which immediatly
solved the problem. Going back to the newest version make it immediatly
reappear.



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

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

Versions of packages python3.5 depends on:
ii  libpython3.5-stdlib  3.5.4-3
ii  mime-support 3.60
ii  python3.5-minimal3.5.4-3

python3.5 recommends no packages.

Versions of packages python3.5 suggests:
ii  binutils2.29-8
pn  python3.5-doc   
pn  python3.5-venv  

-- no debconf information

Bug#862051: [Pkg-javascript-devel] Bug#754462: Bug#862051: nodejs (6.11.2~dfsg-1) experimental; urgency=medium

[Mattia Rizzolo]

On Fri, Sep 01, 2017 at 11:41:36AM +0100, Ian Jackson wrote:
> One thing you I would consider is that it would be nice if scripts in
> Debian packages were made more portable to other distros.  So Debian
> packages should gradually change to use /usr/bin/node.  I am very
> conservative about these things because I like to keep backporting
> (within Debian) as easy as possible.  So if I were the maintainer of a
> node.js package which had scripts mentioning /usr/bin/nodejs, I would
> probably make that change in buster+1 rather than in buster.

It's enough to depend on
nodejs (>= 6.11.2~dfsg-1) | nodejs-legacy
And then you can backport it to whatever debian release you like the
most.

> In buster+1 you should probably consider asking for a lintian warning
> about references to /usr/bin/nodejs.  Not because you intend to drop
> /usr/bin/nodejs ever (why do that - see previous emails) but because
> it would be better, as I've just discussed, for Debian packages to
> contain fewer hurdles to adoption elsewhere.

That's already done.
https://anonscm.debian.org/git/lintian/lintian.git/commit/?id=4ea7bdf953e1fb23bfc85830ad743efaf0ad0373
https://anonscm.debian.org/git/lintian/lintian.git/commit/?id=7d0c0732e792cf0a0cadeb583c9878463813e24a
(will be in the next lintian release)

-- 
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#873942: ITP: node-stream-splicer -- streaming pipeline with a mutable configuration

[Bastien ROUCARIES]

Package: wnpp
Severity: wishlist
Owner: ro...@debian.org
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name: node-stream-splicer
  Version : 2.0.0
  Upstream Author : James Halliday  (http://substack.net)
* URL : https://github.com/substack/stream-splicer
* License : Expat
  Programming Lang: JavaScript
  Description : streaming pipeline with a mutable configuration

 This modules allows one to create a pipeline duplex stream given an
 array of streams. Each stream will be piped to the next.
 .
 Stream could also be added and removed dynamically at runtime.
 .
 Node.js is an event-based server-side JavaScript engine.

Bug#868558: nmu: multiple r-* packages

[Dirk Eddelbuettel]

On 1 September 2017 at 13:52, Emilio Pozuelo Monfort wrote:
| On 01/09/17 13:25, Dirk Eddelbuettel wrote:
| > 
| > Emilio,
| > 
| > Thanks for your follow-up.  I will try to get to each point.
| > 
| > On 1 September 2017 at 11:42, Emilio Pozuelo Monfort wrote:
| > | What Niels meant is whether having an old, non-rebuilt R module with the 
new
| > | r-base works, 
| > 
| > Yes, in general, and here in this case.
| 
| Then I don't understand why these binNMUs are needed.
| 
| >From #861333 OP:
| 
| "With current R, R packages built for Debian before the upload of R
| 3.3.3.20170413-1
| on 14 April that use .C or .Fortran do no work properly, because the functions
| calling .C or .Fortran do not find the compiled objects."
| 
| That tells me that if you upgrade R but don't upgrade some modules, those will
| (partially) break. Hence we need either an ABI bump, or versioned breaks 
against
| the affected modules in r-base.

The Bug:

   - package foo contains .C() or .Fortran and registers it
   - it is built with R 3.3.* (or any R before R 3.4.0)
   - you upgrade to R 3.4.0 tries to load that function in foo

Not a bug:

   - any other use case including staying at R 3.3.3 and using
 a package from R 3.4.0 (not that you could with Debian because all
 r-cran-* packages already impose a >= on the R that built it).

Dirk
  

| 
| Cheers,
| Emilio

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Bug#873943: p7zip-full: Error in 7z manpage

[Yvan Masson]

Package: p7zip-full
Version: 16.02+dfsg-4

Dear maintainer,

In the 7z manpage, the following sentence misses its end:
"Set Password (NOTE: this flag does not work with 7z,"

Best regards,
Yvan



signature.asc
Description: OpenPGP digital signature

Bug#873613: systemd gets confused at shutdown time

[Felipe Sateler]

On Fri, Sep 1, 2017 at 7:27 AM, Harald Dunkel  wrote:
> On Wed, 30 Aug 2017 10:17:55 -0300
> Felipe Sateler  wrote:
>
>> On Wed, Aug 30, 2017 at 6:53 AM, Harald Dunkel 
>> wrote:
>>
>> > On Tue, 29 Aug 2017 11:17:03 -0300
>> > Felipe Sateler  wrote:
>> > >
>> > > Please attach the full configuration for your mount points.
>> > >
>> >
>> > /proc/mounts is attached (as it is now).
>> >
>>
>> Looks like your nfs mounts are missing the _netdev option. Does the problem
>> persist if you add that option? Is this generated from fstab or mount units?
>>
>
> Its in /etc/fstab. Is the "nfs" or "nfs4" in /proc/mounts somehow
> ambiguous?
>
> Anyhow, the (tiny) problem is that systemd ignored the NFS mount point
> completely. The local mount points were released, even though they
> don't have the _netdev attribute set, either.
>
> Even if systemd would have managed to unmount the NFS mount points,
> the bigger problem is still that systemd stops basic services like
> portmap very early at shutdown time.

AFAICS, the umount is attempted at the correct place, but it fails:

Aug 29 15:08:40 dpcl082.example.com systemd[1]: Stopped target Remote File 
Systems.
Aug 29 15:08:40 dpcl082.example.com systemd[1]: Unmounting /home...
Aug 29 15:08:40 dpcl082.example.com systemd[1]: Unmounting /data...
Aug 29 15:08:40 dpcl082.example.com systemd[1]: home.mount: Mount process 
exited, code=exited status=16
Aug 29 15:08:40 dpcl082.example.com systemd[1]: Failed unmounting /home.
Aug 29 15:08:40 dpcl082.example.com systemd[1]: Unmounted /data.
Aug 29 15:08:40 dpcl082.example.com systemd[1]: Stopped target Network is 
Online.
Aug 29 15:08:40 dpcl082.example.com systemd[1]: Stopped Network Manager Wait 
Online.
Aug 29 15:08:40 dpcl082.example.com systemd[1]: Stopped target Remote File 
Systems (Pre).
Aug 29 15:08:40 dpcl082.example.com systemd[1]: Stopped target NFS client 
services.
Aug 29 15:08:40 dpcl082.example.com systemd[1]: Stopping RPC security service 
for NFS client and server...


It appears something is keeping /home still open at the time of the
unmount. Maybe some service has an undeclared dependency on /home?
Finding out who is keeping it open can be done with a unit like the
following:

=== list-open.service
[Unit]
Description=List Open files in /home
RequiresMountsFor=/home
Before=remote-fs.target

[Service]
Type=oneshot
ExecStart=/bin/true
ExecStop=-/usr/bin/lsof +f -- /home

[Install]
WantedBy=multi-user.target
===


Anyway, I think this general problem is helped by this patch:

https://github.com/systemd/systemd/pull/6588

At the time of systemd-shutdown, because the network is disconnected,
any operations on the nfs mount will fail.

>
>>
>> >
>>  [...]
>> > >
>> > > Looks like systemd shut down your network before it unnmounted remote
>> > > filesystems.
>> > >
>> >
>> > Maybe it should have tried to run "umount -f" or to kill user processes
>> > keeping the mount point busy? Anyway, if you look at the log file you
>> > will notice that portmap was stopped *very* early at shutdown time, even
>> > though /home was still mounted via NFS.
>> >
>> > >
>> > > Could you attach full logs? Attaching the info generated by reportbug
>> > > would be useful too.
>> > >
>> >
>> > journalctl.log is attached (in ASCII). Unfortunately journald stopped
>> > logging. The long delay at shutdown time doesn't show, but I took a
>> > photo.
>> >
>>
>> The full info that reportbug would have generated is important. Please
>> attach it.
>>
>
> Attached.
>
> On Wed, 30 Aug 2017 11:53:38 +0200 I had sent some attachments to this
> bug (the output of journalctl and a screen snapshot). What happened to
> these?
>

I received them, and made a cursory look only. The information from
reportbug is very complete, and avoids a lot of back-and-forth with
questions. For this reason I don't look into much detail without the
full info available. There is a reason we tell reportbug to include
it, and it is that it saves everybodys time.

-- 

Saludos,
Felipe Sateler

Bug#873944: acmetool: private keys should be readable by ssl-cert group

[David Magda]

Package: acmetool
Version: 0.0.59-1+b1
Severity: wishlist

There is a bit of a convention, created by the "ssl-cert" package AFAICT,
that private keys are owned by the group "ssl-cert". This allows packages
to not run as root but still have use the certs.

It also allows for processes to drop privileges and still have access if
they do a "reload".

The way the "ssl-cert" package does it is that it has a "postinst"
script that create the group if it doesn't already exist:

# Create the ssl-cert system group for snakeoil ownership:
if ! getent group ssl-cert >/dev/null; then
addgroup --quiet --system --force-badname ssl-cert
fi

https://anonscm.debian.org/cgit/pkg-apache/ssl-cert.git/tree/debian/postinst

For "acmetool" it may need to be a "preinst" script so newly created dirs
can be chgrp'd properly.

That would mean that "/var/lib/acme/keys/" would be owned by "ssl-cert" 
group and be have the set-GID bit on so new sub-dirs (and files with-in 
them) have correct ownership. The umask would probably also have to change 
from 077 to 027.


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

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

Versions of packages acmetool depends on:
ii  init-system-helpers  1.22
ii  libc62.19-18+deb8u10
ii  libcap2  1:2.24-8

Versions of packages acmetool recommends:
pn  dialog  

acmetool suggests no packages.

-- no debconf information

Bug#873174: Ticket on conversations

[Elena ``of Valhalla'']

This is a relevant issue on Conversations, which I believe can give
more informations

https://github.com/siacs/Conversations/issues/2612
-- 
Elena ``of Valhalla''

Bug#873945: apache2-bin: apache2 with http2 segfault

[Hosted Power Sales]

Package: apache2-bin
Version: 2.4.25-3+deb9u2
Severity: important
 Dear Maintainer,
 *** Reporter, please consider answering these questions, where appropriate ***
    * What led up to the situation?
 SEGFAULT Apache2 with http2, just by having users visiting the site.
 gdb /usr/sbin/apache2 core-apache2-11-33-33-16474-1504205745
GNU gdb (Debian 7.12-6) 7.12.0.20161007-git
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/sbin/apache2...Reading symbols from 
/usr/lib/debug/.build-id/1b/81c3ec196acae651912c3a4025bc1c6a07c375.debug...done.
done.
[New LWP 16532]
[New LWP 16477]
[New LWP 16474]
[New LWP 16475]
[New LWP 16479]
[New LWP 16476]
[New LWP 16480]
[New LWP 16481]
[New LWP 16511]
[New LWP 16478]
[New LWP 16487]
[New LWP 16482]
[New LWP 16512]
[New LWP 16489]
[New LWP 16483]
[New LWP 16491]
[New LWP 16494]
[New LWP 16513]
[New LWP 16484]
[New LWP 16499]
[New LWP 16485]
[New LWP 16500]
[New LWP 16516]
[New LWP 16502]
[New LWP 16486]
[New LWP 16504]
[New LWP 16517]
[New LWP 16488]
[New LWP 16506]
[New LWP 16507]
[New LWP 16490]
[New LWP 16518]
[New LWP 16492]
[New LWP 16509]
[New LWP 16514]
[New LWP 16519]
[New LWP 16522]
[New LWP 16527]
[New LWP 16520]
[New LWP 16523]
[New LWP 16524]
[New LWP 16525]
[New LWP 16529]
[New LWP 16495]
[New LWP 16533]
[New LWP 16496]
[New LWP 16497]
[New LWP 16535]
[New LWP 16498]
[New LWP 16501]
[New LWP 16536]
[New LWP 16503]
[New LWP 16537]
[New LWP 16505]
[New LWP 16510]
[New LWP 16515]
[New LWP 16521]
[New LWP 16526]
[New LWP 16528]
[New LWP 16530]
[New LWP 16531]
[New LWP 16534]
[New LWP 16538]
[New LWP 16539]
[New LWP 16540]
[New LWP 16541]
[New LWP 16493]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `/usr/sbin/apache2 -k start'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  h2_stream_out_prepare (stream=stream@entry=0x7ff7772330a0, 
plen=plen@entry=0x7ff77cfe89e0, peos=peos@entry=0x7ff77cfe89dc, 
presponse=presponse@entry=0x7ff77cfe89e8) at h2_stream.c:604
604     h2_stream.c: No such file or directory.
[Current thread is 1 (Thread 0x7ff77cfe9700 (LWP 16532))]
(gdb) bt
#0  h2_stream_out_prepare (stream=stream@entry=0x7ff7772330a0, 
plen=plen@entry=0x7ff77cfe89e0, peos=peos@entry=0x7ff77cfe89dc, 
presponse=presponse@entry=0x7ff77cfe89e8) at h2_stream.c:604
#1  0x7ff7ae7bb6cb in on_stream_resume (ctx=0x7ff7768410a0, 
stream=0x7ff7772330a0) at h2_session.c:1576
#2  0x7ff7ae7b2e3b in h2_mplx_dispatch_master_events (m=0x7ff7768412d0, 
on_resume=on_resume@entry=0x7ff7ae7bb500 , 
on_ctx=on_ctx@entry=0x7ff7768410a0) at h2_mplx.c:1379
#3  0x7ff7ae7bc7ab in h2_session_process (session=0x7ff7768410a0, 
async=async@entry=1) at h2_session.c:2210
#4  0x7ff7ae7a8b2a in h2_conn_run (ctx=ctx@entry=0x7ff78c144360, 
c=c@entry=0x7ff78c14b348) at h2_conn.c:212
#5  0x7ff7ae7aea5b in h2_h2_process_conn (c=0x7ff78c14b348) at h2_h2.c:658
#6  0x558b46d1e6f0 in ap_run_process_connection (c=c@entry=0x7ff78c14b348) 
at connection.c:42
#7  0x7ff7ad8976e8 in process_socket (my_thread_num=, 
my_child_num=, cs=0x7ff78c14b2b8, sock=, 
p=0x7ff78c14b028, thd=) at event.c:1099
#8  worker_thread (thd=, dummy=) at event.c:2003
#9  0x7ff7b1862494 in start_thread (arg=0x7ff77cfe9700) at 
pthread_create.c:333
#10 0x7ff7b15a4aff in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:97
    * What exactly did you do (or not do) that was effective (or ineffective)?
 http2 enabled caused it, disable module fixes it immediately
   -- Package-specific info:
 -- System Information:
Debian Release: 9.1
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
 Kernel: Linux 4.9.0-3-amd64 (SMP w/3 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
 Versions of packages apache2-bin depends on:
ii  libapr1                  1.5.2-5
ii  libaprutil1              1.5.4-3
ii  libaprutil1-dbd-sqlite3  1.5.4-3
ii  libaprutil1-ldap         1.5.4-3
ii  libc6                    2.24-11+deb9u1
ii  libldap-2.4-2            2.4.44+dfsg-5
ii  liblua5.2-0              5.2.4-1.1+b2
ii  libnghttp2-14            1.18.1-1
ii  libpcre3                 2:8.39-3
ii  libssl1.0.2     

Bug#873921: python3.5_3.5.4-3 breaks borgbackup: undefined symbol: PyFPE_jbuf

[Gianfranco Costamagna]

control: reassign -1 src:python3.5
control: found -1 3.5.4-3
control: notfound -1 3.5.4-2

control: affects -1 src:borgbackup


Hello, I don't know why this should be a borgbackup issue.

If they changed ABI, they have to track the transition


G.

Il Venerdì 1 Settembre 2017 10:51, Sven Hartge  ha scritto:



Package: borgbackup

Version: 1.0.11-3

Severity: grave


Hi!


I am reporting this bug against borgbackup, because I am not sure if the

bug is in python3.5 or borgbackup just needs to be binNMUd. Please

reassign as you see fit.


The upload of python3.5 (3.5.4-3) disables the fpectl extension and

breaks borgbackup:


$ borg

Traceback (most recent call last):

  File "/usr/bin/borg", line 11, in 

load_entry_point('borgbackup==1.0.11', 'console_scripts', 'borg')()

  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 564, in 
load_entry_point

return get_distribution(dist).load_entry_point(group, name)

  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 2662, 
in load_entry_point

return ep.load()

  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 2316, 
in load

return self.resolve()

  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 2322, 
in resolve

module = __import__(self.module_name, fromlist=['__name__'], level=0)

  File "/usr/lib/python3/dist-packages/borg/archiver.py", line 22, in 

from .helpers import Error, location_validator, archivename_validator, 
format_line, format_time, format_file_size, \

  File "/usr/lib/python3/dist-packages/borg/helpers.py", line 35, in 

from . import crypto

ImportError: 
/usr/lib/python3/dist-packages/borg/crypto.cpython-35m-i386-linux-gnu.so: 
undefined symbol: PyFPE_jbuf


Grüße,

Sven.


-- System Information:

Debian Release: buster/sid

  APT prefers unstable-debug

  APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 
'unstable'), (500, 'testing'), (200, 'experimental'), (1, 'experimental-debug')

Architecture: i386 (x86_64)

Foreign Architectures: amd64


Kernel: Linux 4.9.0-3-amd64 (SMP w/4 CPU cores)

Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), 
LANGUAGE=de_DE.utf8 (charmap=UTF-8)

Shell: /bin/sh linked to /bin/dash

Init: systemd (via /run/systemd/system)


Versions of packages borgbackup depends on:

ii  fuse   2.9.7-1

ii  libacl12.2.52-3+b1

ii  libc6  2.24-17

ii  liblz4-1   0.0~r131-2+b1

pn  libssl1.1  

ii  python33.5.3-3

ii  python3-llfuse 1.2+dfsg-1+b1

ii  python3-msgpack0.4.8-1+b1

ii  python3-pkg-resources  36.2.7-2


borgbackup recommends no packages.


Versions of packages borgbackup suggests:

pn  borgbackup-doc  


-- debconf-show failed

Bug#754462: [Pkg-javascript-devel] Bug#754462: Bug#754462: Bug#862051: nodejs (6.11.2~dfsg-1) experimental; urgency=medium

[Bastien Roucaries]

Le 1 septembre 2017 14:16:14 GMT+02:00, Mattia Rizzolo  a 
écrit :
>On Fri, Sep 01, 2017 at 11:41:36AM +0100, Ian Jackson wrote:
>> One thing you I would consider is that it would be nice if scripts in
>> Debian packages were made more portable to other distros.  So Debian
>> packages should gradually change to use /usr/bin/node.  I am very
>> conservative about these things because I like to keep backporting
>> (within Debian) as easy as possible.  So if I were the maintainer of
>a
>> node.js package which had scripts mentioning /usr/bin/nodejs, I would
>> probably make that change in buster+1 rather than in buster.
>
>It's enough to depend on
>nodejs (>= 6.11.2~dfsg-1) | nodejs-legacy
>And then you can backport it to whatever debian release you like the
>most.
>
>> In buster+1 you should probably consider asking for a lintian warning
>> about references to /usr/bin/nodejs.  Not because you intend to drop
>> /usr/bin/nodejs ever (why do that - see previous emails) but because
>> it would be better, as I've just discussed, for Debian packages to
>> contain fewer hurdles to adoption elsewhere.
>
>That's already done.
>https://anonscm.debian.org/git/lintian/lintian.git/commit/?id=4ea7bdf953e1fb23bfc85830ad743efaf0ad0373
>https://anonscm.debian.org/git/lintian/lintian.git/commit/?id=7d0c0732e792cf0a0cadeb583c9878463813e24a
>(will be in the next lintian release)


Please also parse autopkgtest like require ans dix npm2deb

-- 
Envoyé de mon appareil Android avec K-9 Mail. Veuillez excuser ma brièveté.

Bug#864439: Disable bowtie for mips64el

[Andreas Tille]

Hi,

do we have any better idea than disabling bowtie for mips64el architecture?

Kind regards

   Andreas.

-- 
http://fam-tille.de

Bug#853672: svxlink: diff for NMU version 15.11-2.1

[Adrian Bunk]

Control: tags 853672 + pending

Dear maintainer,

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

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

diff -Nru svxlink-15.11/debian/changelog svxlink-15.11/debian/changelog
--- svxlink-15.11/debian/changelog	2016-12-10 02:45:49.0 +0200
+++ svxlink-15.11/debian/changelog	2017-09-01 16:15:22.0 +0300
@@ -1,3 +1,10 @@
+svxlink (15.11-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Add upstream patch to fix FTBFS with gcc 7. (Closes: #853672)
+
+ -- Adrian Bunk   Fri, 01 Sep 2017 16:15:22 +0300
+
 svxlink (15.11-2) unstable; urgency=medium
 
   * Bugfix release
diff -Nru svxlink-15.11/debian/patches/0001-Fix-compilation-problem-in-Async-AudioDeviceAlsa.patch svxlink-15.11/debian/patches/0001-Fix-compilation-problem-in-Async-AudioDeviceAlsa.patch
--- svxlink-15.11/debian/patches/0001-Fix-compilation-problem-in-Async-AudioDeviceAlsa.patch	1970-01-01 02:00:00.0 +0200
+++ svxlink-15.11/debian/patches/0001-Fix-compilation-problem-in-Async-AudioDeviceAlsa.patch	2017-08-17 18:05:06.0 +0300
@@ -0,0 +1,26 @@
+From 611cc5cc134f710f94fc8987375259bd8af34604 Mon Sep 17 00:00:00 2001
+From: Tobias Blomberg 
+Date: Mon, 19 Jun 2017 22:04:20 +0200
+Subject: Fix compilation problem in Async::AudioDeviceAlsa
+
+- On newer compilers the compilation would fail on ambiguous call to abs
+---
+ src/async/audio/AsyncAudioDeviceAlsa.cpp | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/src/async/audio/AsyncAudioDeviceAlsa.cpp b/src/async/audio/AsyncAudioDeviceAlsa.cpp
+index 17d255e8..15d760d5 100644
+--- a/src/async/audio/AsyncAudioDeviceAlsa.cpp
 b/src/async/audio/AsyncAudioDeviceAlsa.cpp
+@@ -548,7 +548,7 @@ bool AudioDeviceAlsa::initParams(snd_pcm_t *pcm_handle)
+ return false;
+   }
+ 
+-  if (::abs(real_rate - sample_rate) > 100)
++  if (::abs(static_cast(real_rate) - sample_rate) > 100)
+   {
+ cerr << "*** ERROR: The sample rate could not be set to "
+  << sample_rate << "Hz for ALSA device \"" << dev_name << "\". "
+-- 
+2.11.0
+
diff -Nru svxlink-15.11/debian/patches/series svxlink-15.11/debian/patches/series
--- svxlink-15.11/debian/patches/series	2016-01-13 20:50:43.0 +0200
+++ svxlink-15.11/debian/patches/series	2017-08-17 18:06:19.0 +0300
@@ -10,3 +10,4 @@
 enable-static-libs.patch
 use-default-compile-flags.patch
 enable-verbose-output.patch
+0001-Fix-compilation-problem-in-Async-AudioDeviceAlsa.patch

Bug#853368: dbf2mysql: diff for NMU version 1.14a-5.1

[Adrian Bunk]

Control: tags 853368 + pending

Dear maintainer,

I've prepared an NMU for dbf2mysql (versioned as 1.14a-5.1) and uploaded 
it to DELAYED/10. Please feel free to tell me if I should cancel it.

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

diff -Nru dbf2mysql-1.14a/debian/changelog dbf2mysql-1.14a/debian/changelog
--- dbf2mysql-1.14a/debian/changelog	2016-12-13 00:30:47.0 +0200
+++ dbf2mysql-1.14a/debian/changelog	2017-09-01 16:20:46.0 +0300
@@ -1,3 +1,10 @@
+dbf2mysql (1.14a-5.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTBFS with gcc 7. (Closes: #853368)
+
+ -- Adrian Bunk   Fri, 01 Sep 2017 16:20:46 +0300
+
 dbf2mysql (1.14a-5) unstable; urgency=medium
 
   * Moved to new libmysql-dev b-d.
diff -Nru dbf2mysql-1.14a/debian/patches/35_gcc-7.patch dbf2mysql-1.14a/debian/patches/35_gcc-7.patch
--- dbf2mysql-1.14a/debian/patches/35_gcc-7.patch	1970-01-01 02:00:00.0 +0200
+++ dbf2mysql-1.14a/debian/patches/35_gcc-7.patch	2017-08-17 20:28:30.0 +0300
@@ -0,0 +1,55 @@
+Description: Make strtoupper/strtolower static inline
+ This seems to have been intended,
+ and the static makes gcc 7 happy.
+Author: Adrian Bunk 
+Bug-Debian: https://bugs.debian.org/853368
+
+--- dbf2mysql-1.14a.orig/dbf2mysql.c
 dbf2mysql-1.14a/dbf2mysql.c
+@@ -41,21 +41,19 @@ char	*convert = NULL;
+ 
+ void do_onlyfields (char *flist, dbhead *dbh);
+ void do_substitute(char *subarg, dbhead *dbh);
+-inline void strtoupper(char *string);
+-inline void strtolower(char *string);
+ void do_create(MYSQL *, char*, dbhead*);
+ void do_inserts(MYSQL *, char*, dbhead*);
+ int check_table(MYSQL *, char*);
+ void usage(void);
+ 
+-inline void strtoupper(char *string) {
++static inline void strtoupper(char *string) {
+ 	while(*string != '\0') {
+ 		*string = toupper(*string);
+ 		string++;
+ 	}
+ }
+ 
+-inline void strtolower(char *string) {
++static inline void strtolower(char *string) {
+ 	while(*string != '\0') {
+ 		*string = tolower(*string);
+ 		string++;
+--- dbf2mysql-1.14a.orig/mysql2dbf.c
 dbf2mysql-1.14a/mysql2dbf.c
+@@ -21,18 +21,16 @@ char	*table = NULL;
+ char*pass = NULL;
+ char*user = NULL;
+ 
+-inline void strtoupper(char *string);
+-inline void strtolower(char *string);
+ void usage(void);
+ 
+-inline void strtoupper(char *string) {
++static inline void strtoupper(char *string) {
+ while(*string != '\0') {
+ *string = toupper(*string);
+ 		string++;
+ }
+ }
+ 
+-inline void strtolower(char *string) {
++static inline void strtolower(char *string) {
+ while(*string != '\0') {
+ *string = tolower(*string);
+ 		string++;
diff -Nru dbf2mysql-1.14a/debian/patches/series dbf2mysql-1.14a/debian/patches/series
--- dbf2mysql-1.14a/debian/patches/series	2016-03-06 16:32:58.0 +0200
+++ dbf2mysql-1.14a/debian/patches/series	2017-09-01 16:20:46.0 +0300
@@ -4,3 +4,4 @@
 20-u-char.patch
 25-mysql-real-connect.patch
 30-makefile
+35_gcc-7.patch

Bug#873946: freedombox-setup: Cleanup setup steps based on Plinth changes

[Sunil Mohan Adapa]

Package: freedombox-setup
Version: 0.10
Severity: normal
Tags: patch

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Currently, Plinth is undergoing changes to move a lot of setup steps into
Plinth.  This will eliminate the need for many steps in freedombox-setup.

Attached patch is a work-in-progress patch to indicate the kind of cleanups
that may be done on freedombox-setup after these changes.  Note that both the
packages should depend on particular versions with these changes (using Depends
and Breaks to avoid circular dependencies).

This patch is somewhat aggressive.  While the first-run can be completely
removed without question, same is not true setup process.  However, what
remains in setup step is so minimal that it does not warrant an extra
FreedomBox install complication.  So, with this patch I suggest removing
functionalities of etckeeper and provide source temporarily in order to gain
the huge advantage of simplification of the FreedomBox install/setup process.



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

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

-BEGIN PGP SIGNATURE-

iQJFBAEBCgAvFiEE5xPDY9ZyWnWupXSBQ+oc/wqnxfIFAlmpYusRHHN1bmlsQG1l
ZGhhcy5vcmcACgkQQ+oc/wqnxfJhahAAgbhTVkCHrbG5oPUQj1RQqHrjiBeVDuJr
FQv+F4Pa/OvPrrdQOUW54jCt9VP9QC87y2cxXVU6j5gxzZ7290oOC0t1Q0yOSiPy
NH9X6wZ1629ywTd6tmat1rphWlmPFLTANZTJlKeR4ZWUB/MnIaH5f2jT2wbgI0lC
Y1503luAfAGlwiBKjAQJnOMGQPFQekibpsgEUwtWSBskA0DO7My+oTChuXY429jg
vPy5ACMkSLH+GBSqFwwj7dv8RvLpzEDGbmudb+Ry5+GQJDgrG66XleyEo+ut62f4
V4vm3kIsl3tjsVYnL1+DhMC8pFFkUYShIDlSucNoF01J1UHahiIuGsotQTS9W5YB
vq6D29nXw+UE+eLRJQdS47SjXwgsdrNGLd+E0SKHOXkvXHjXArmRQ45u9dCbhgaO
whDtvZxtyGcfHXweHW4WncB7VG8sjXDlb+F16Q5PjZ0vK12hSq7GIjjbARphLMFU
vaeNYv43sWmscu2lse4SNw1y9kUjukmJ5umg3a5ZjLcEC5Czc6jPGO2zherZxatf
9mdcec90ahPOgu0Pm5fa7TpDUlVsOex79zsKSIbPh9XnlhswVnrJBHs7hI8EjAK6
232MPuywB/e7r7kHv5m4KF2h74UJc/agB1igrZR3bUBqDkKnZ5yFrRyGkcD9lFOb
0zxK4ysd8rw=
=hE65
-END PGP SIGNATURE-
>From c7b26d6e2df98ae97b0ed4263bc3d94d98ec0bee Mon Sep 17 00:00:00 2001
From: Sunil Mohan Adapa 
Date: Fri, 1 Sep 2017 18:41:33 +0530
Subject: [PATCH] WIP: Move most setup steps to Plinth

Signed-off-by: Sunil Mohan Adapa 
---
 debian/freedombox-setup.freedombox-first-run.init |  64 
 debian/freedombox-setup.install   |   3 -
 debian/freedombox-setup.maintscript   |   1 +
 debian/rules  |   3 -
 debian/tests/control  |   2 -
 debian/tests/test-run-setup   |  15 ---
 first-run.d/05_network| 119 --
 first-run.d/10_ssh-keys   |  12 ---
 first-run.d/40_apache2|   8 --
 setup |  29 --
 setup.d/01_etckeeper-pre  |  15 ---
 setup.d/90_apache2|  44 
 setup.d/98_next-is-first-run  |   7 --
 setup.d/99_etckeeper  |   7 --
 setup.d/99_provide-source |  28 -
 setup.d/99_zmessage   |  22 
 16 files changed, 1 insertion(+), 378 deletions(-)
 delete mode 100755 debian/freedombox-setup.freedombox-first-run.init
 delete mode 100644 debian/tests/control
 delete mode 100755 debian/tests/test-run-setup
 delete mode 100755 first-run.d/05_network
 delete mode 100755 first-run.d/10_ssh-keys
 delete mode 100755 first-run.d/40_apache2
 delete mode 100755 setup
 delete mode 100755 setup.d/01_etckeeper-pre
 delete mode 100755 setup.d/90_apache2
 delete mode 100755 setup.d/98_next-is-first-run
 delete mode 100755 setup.d/99_etckeeper
 delete mode 100755 setup.d/99_provide-source
 delete mode 100755 setup.d/99_zmessage

diff --git a/debian/freedombox-setup.freedombox-first-run.init 
b/debian/freedombox-setup.freedombox-first-run.init
deleted file mode 100755
index bb8cd96..000
--- a/debian/freedombox-setup.freedombox-first-run.init
+++ /dev/null
@@ -1,64 +0,0 @@
-#!/bin/sh
-### BEGIN INIT INFO
-# Provides:  freedombox-first-run
-# Default-Start: 2 3 4 5
-# Default-Stop:
-# Required-Start:$network $remote_fs $syslog
-# Required-Stop: $remote_fs $syslog
-# Should-Start:  firewalld tor haveged
-# Short-Description: Finish Freedombox install after first boot
-# Description:
-#   Script to complete the post-install process on first FBX boot.
-### END INIT INFO
-
-RUNONCE=/var/lib/freedombox/first-run-enable
-LOGFILE=/var/log/freedombox-first-run.log
-
-if [ ! -e $RUNONCE ]
-then
-exit
-fi
-
-. /lib/lsb/init-functions
-
-exec > $LOGFILE 2>&1
-
-etckeeper_commit() {
-if type etckeeper > /dev/null 2>&1 ; then

Bug#873889: elvish: FTBFS on ppc64(el): several tests fail

[Shengjing Zhu]

Control: tags -1 pending

with following two commits
https://anonscm.debian.org/cgit/pkg-go/packages/elvish.git/commit/?id=e3a9f22186a6ff9035fd9c26f8675c719f1190c2
https://anonscm.debian.org/cgit/pkg-go/packages/elvish.git/commit/?id=1da0634a7fe5585202c3cd69fb908de9ebe263fd

I have tested elvish successfully on a ppc64le VM provided by Minicloud.


-- 
Best regards,
Shengjing Zhu

Bug#873947: plinth: Move setting up /var/{lib,log}/plinth to postinst script

[Sunil Mohan Adapa]

Package: plinth
Version: 0.14.0+ds-1
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Currently in plinth/data/usr/lib/freedombox/setup/86_plinth script the
following happens:

# Ensure that DB and log file permissions are correct
chown -R plinth: /var/lib/plinth /var/log/plinth

Do this to plinth/debian/postint.  After recent changes, freedombox-setup will
no longer run any setup scripts so this has to be done here.  And the duty
rightfully belongs here.



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

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

Versions of packages plinth depends on:
ii  adduser3.115
ii  augeas-tools   1.8.0-1+deb9u1
ii  avahi-daemon   0.6.32-2
pn  batctl 
ii  firewalld  0.4.4.2-1
ii  gettext0.19.8.1-2
ii  gir1.2-glib-2.01.50.0-1+b1
ii  gir1.2-networkmanager-1.0  1.6.2-3
ii  init-system-helpers1.48
ii  javascript-common  11
ii  ldap-utils 2.4.44+dfsg-5
ii  ldapscripts2.0.7-2
ii  libjs-bootstrap3.3.7+dfsg-2
ii  libjs-jquery   3.1.1-2
ii  libjs-modernizr2.6.2+ds1-1
pn  libnss-ldapd   
pn  libpam-ldapd   
ii  network-manager1.6.2-3
pn  nslcd  
pn  ntp
ii  ppp2.4.7-1+4
ii  pppoe  3.12-1.1
ii  python33.5.3-1
ii  python3-apt1.4.0~beta3
ii  python3-augeas 0.5.0-1
ii  python3-bootstrapform  3.2.1-2
ii  python3-cherrypy3  3.5.0-2
ii  python3-django 1:1.10.7-2
ii  python3-django-stronghold  0.2.7+debian-3
ii  python3-gi 3.22.0-2
ii  python3-psutil 5.0.1-1
ii  python3-requests   2.12.4-1
ii  python3-ruamel.yaml0.13.4-2
pn  slapd  
ii  sudo   1.8.19p1-2.1
ii  unattended-upgrades0.93.1+nmu1

plinth recommends no packages.

plinth suggests no packages.

-BEGIN PGP SIGNATURE-

iQJFBAEBCgAvFiEE5xPDY9ZyWnWupXSBQ+oc/wqnxfIFAlmpY9ARHHN1bmlsQG1l
ZGhhcy5vcmcACgkQQ+oc/wqnxfLDBxAAgBX+CPvOp+9QygcU9UXkDUzaF8fWfGn/
b02Zd+PINfwN/9XDDOCo+8E+tExeFAT/k7v6Y85DgddYbHidhDGkQtGjTrgaGhST
kuo5OXP15rJYPuu1rUVfrEFZva+sy4B+3vrOmiP6C500rdqc4eY54Wjdf+9DhTTU
bfszX/TpbaxS4phRTEFmTfBYZ9Hnfi05r6zYwdPDgY2AJUVK460DWPYC2hwelm8g
Y0STqB0JBYZPHeeADgiepStJpI2XFNHGGOYl1qzpJXsuup/1BRqtZq+o5LGhLtov
7enkV9kBJ3J0ZhhkLTq4DPFiDsNPFqhU6XJFT9xtzqS8xB3//7dts/XDBqaJSxXG
8MRsXeCo3PW1PQwSqXwIhkPSizHZeAwYfrx4fERE3os2C4Rei03EFq+pDeEFlTCE
RFUH0RJcG/t+WsJ4rpcJrqUJOF2Fgu+GPhNMnB4STiUCellANPyxI8KQc7uuaEp0
CW8yOG/QP2/bVA8WG5XYdaE2JCoxDjUvjDaJRsLSLDfrvTRKLwi4rgEdyAtTGteD
MSKy/aXwbGx5UWyeEfVBD/jFB8GMtaiTv6i7aSjB1OjJYgTPDC03Sr0Dxh2cMroR
XXhw84ejRS9JjgsmFoPP3wdaS2jkN9vyOUMTCUUP2lPWPj/nM5Y5Kc94YgpDQc/2
TX1MC6i5Okg=
=a0GX
-END PGP SIGNATURE-

Bug#857248: nullmailer: bug found!

[Felix Lechner]

David,

I found the bug affecting the tests. (It was an issue only when TLS was
enabled, and there were some race conditions.) I packaged version 2.0
and uploaded
it to Mentors .

You are still welcome to adopt the package. Or, you can sponsor me---I
really don't care. Just trying to help.

Some of the open items in my version are:

1. Syslog code (and therefore '--daemon') not adopted from prior version.
It probably would be a good idea, but is complicated, and the package works
without it.

2. I slightly modified the interplay between '/etc/mailname', 'me' and
'defaulthost' to allow the tests to complete. Not sure if that broke the
'/etc/mailname' behavior. I don't use that feature.

Sorry I did not work through collab-maint. I did not see the package on
Alioth until today. (I also did not see your bug message from Aug 2,
although I did see your letter to upstream.)

Best regards,
Felix

Bug#870198: This is issue 67 in upstream -- Filters editing window hangs in TB 47

[John Hughes]

https://github.com/thsmi/sieve/issues/67

There is a patch for it -- 
https://github.com/thsmi/sieve/commit/cdf54a49fe50641dac73e657346e8c2249fbb63f


--
John Hughes, CalvaEDI S.A.S. -- An Esker Company


+33 1 4313 3131

Bug#873948: plinth: Turn Plinth into a native Debian package

[Sunil Mohan Adapa]

Package: plinth
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Plinth is very much tied to Debian.  Even if it is not, we will want to have
Debian as first class candidate for Plinth.  So, every release of Plinth would
mean release of Plinth Debian package.

Merging the two repositories will also make creating Debian packages easier.  I
will make releases faster and of higher quality.  We can eliminate maintenance
of Debian patches.

We can make renaming of Plinth to freedombox much faster and easier.  Breaking
into smaller packages will also be easier.

We can move the debian directory to Plinth upstream and write the next
changelog entry with native package version number.  Unless I missed something
serious that is all there should be to it.



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

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

Versions of packages plinth depends on:
ii  adduser3.115
ii  augeas-tools   1.8.0-1+deb9u1
ii  avahi-daemon   0.6.32-2
pn  batctl 
ii  firewalld  0.4.4.2-1
ii  gettext0.19.8.1-2
ii  gir1.2-glib-2.01.50.0-1+b1
ii  gir1.2-networkmanager-1.0  1.6.2-3
ii  init-system-helpers1.48
ii  javascript-common  11
ii  ldap-utils 2.4.44+dfsg-5
ii  ldapscripts2.0.7-2
ii  libjs-bootstrap3.3.7+dfsg-2
ii  libjs-jquery   3.1.1-2
ii  libjs-modernizr2.6.2+ds1-1
pn  libnss-ldapd   
pn  libpam-ldapd   
ii  network-manager1.6.2-3
pn  nslcd  
pn  ntp
ii  ppp2.4.7-1+4
ii  pppoe  3.12-1.1
ii  python33.5.3-1
ii  python3-apt1.4.0~beta3
ii  python3-augeas 0.5.0-1
ii  python3-bootstrapform  3.2.1-2
ii  python3-cherrypy3  3.5.0-2
ii  python3-django 1:1.10.7-2
ii  python3-django-stronghold  0.2.7+debian-3
ii  python3-gi 3.22.0-2
ii  python3-psutil 5.0.1-1
ii  python3-requests   2.12.4-1
ii  python3-ruamel.yaml0.13.4-2
pn  slapd  
ii  sudo   1.8.19p1-2.1
ii  unattended-upgrades0.93.1+nmu1

plinth recommends no packages.

plinth suggests no packages.

-BEGIN PGP SIGNATURE-

iQJFBAEBCgAvFiEE5xPDY9ZyWnWupXSBQ+oc/wqnxfIFAlmpZV0RHHN1bmlsQG1l
ZGhhcy5vcmcACgkQQ+oc/wqnxfIL9xAAlJ4e6IO5WI/kFXWvuYRnl40WLw2xL09v
B1WHj6B+LjHHcmfdOnG6MImgqT2NeqFoysdQG6a8WaOazNBi3IcBzMWufjxyVHKZ
7ijONt5AXh3iR7zRLSUePSaw4xc20fEStyVUXNI8UHQ9VZC6/s/t5PBocotk5CaZ
kmnl58yA8AOK2vaWph2+BwB3h15zMPgf40FB0tCicVLjyIrqvCasNqB4/OT90x5z
MbeUg6A5T5AbpxJKB4bdKq4x1g7QkT3huiwUdIwixNu8x/kh6GwYbp57c4KIsz+F
CwRtTD5Fre7gJcD+rO0+9/1/YlOUT1jKoigy1OTy++JRXJWX6DPagu+5FFqC+ErN
bBenEgvwcJoGzO/yAiKnvH0yhxpXhBvopHpOorVChbRvk2pKMOmYnbFc9AvT9rnu
nwMTwJBV2rvO1M7h8++PldLb5JmqRQfrzFhVH/e001/6y3nH2JfjThJrrx7Z/5XY
dyPjMRX/OfWDZXrAm2C9PkgNLv6PJEPMVOlhXOshuiDCtxzjvUd7sL2FzchD8c+O
BzLGPYF5SlF3mTRlwg75GKmEcOMgFeIeWUMvGMrkggjcfh4zUX8pSr6Bv/AtBECX
k99arINS36Jv74auTvDnF0RmnDgSXzOY4JZRwpJKx5YL0VHy5k7XQRIT2N4onBXM
wOoU80Vixjo=
=7rg1
-END PGP SIGNATURE-

Bug#873878: [gluster-packaging] Fwd: Bug#873878: glusterfs-client: mount.glusterfs needs bash as /bin/sh

[Michael Lundkvist]

On 09/01/2017 01:25 PM, Patrick Matthäi wrote:


Am 01.09.2017 um 11:40 schrieb Niels de Vos:

On Fri, Sep 01, 2017 at 09:36:16AM +0200, Patrick Matthäi wrote:

Hi,

how should it be fixed for glusterfs now? Better shell code without
bashishm or do you want /bin/bash as shebang?

Do you have a preference? I do not know how much work is it is to
rewrite the mount.glusterfs script to remove all the Bashisms. At least
in the Debian builds you may want to patch it to /bin/bash for the time
being.


I would prefer a patch, so that it works without bash. Luckily the bug
reporter just wrote a patch :)
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=873878#10



To be very clear, I've only tested this by manually modifying 
/sbin/mount.glusterfs in the same way. I've not even tried building it.


Also, this code seems related to the new sub-directory mounts that came 
in 3.12 and I'm not using that.


But at least it takes the package from unusable to fully functional for 
me. :)


/Micke