Bug#918773: [debian-refcard] improve layout for Bulgarian

[Holger Wansing]

Package: refcard
Tags: patch


For Bulgarian, we currently use a smaller font.
This can be changed to standard size these days without any other disadvantage,
to improve readability.


Patch is attached.


Holger




-- 
Holger Wansing 
PGP-Finterprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076
diff --git a/dblatex.xsl b/dblatex.xsl
index 0e17175..03f5624 100644
--- a/dblatex.xsl
+++ b/dblatex.xsl
@@ -82,8 +82,8 @@
 
 \newpages{
 
-2
-2
+0
 1
 
diff --git a/preproc.xsl b/preproc.xsl
index aede642..a4eab3c 100644
--- a/preproc.xsl
+++ b/preproc.xsl
@@ -20,7 +20,7 @@
   
   
 	
-	  footnotesize
 	  small
 	

Bug#316494: Aktivieren Sie Ihre E-Mail erneut

[Strato Email Konto]

Sehr geehrter Telekom-Mitglied,
  
 Aktualisiere deine E-Mail, um zu vermeiden
  
 Aussetzung auf Ihrem -Konto
  
 strato/update
  
 Strato E-Mail Team

Bug#918772: Fetching fails with NoSuchMethodError under Java 8 (java.nio.ByteBuffer.flip())

[Timo Kalliomäki]

Package: libwagon-http-shaded-java
Version: 3.2.0-2
Severity: important

Dear Maintainer,

when trying to run Maven for a Java 8 project, fetching metadata fails with
java.lang.NoSuchMethodError. See log excerpt below for details.

The gist is that handling URLs, HttpClient does a flip() to a ByteBuffer. From
Java 9 the said method has a covariant return type, so the resultant bytecode
calls java.nio.ByteBuffer.flip()Ljava/nio/ByteBuffer which fails under Java 8.
A quick search showed that one strategy people are using to produce bytecode
compatible on both JREs is doing ((Buffer)byteBuffer).flip().

Br,
Timo

$ mvn initialize -X
Apache Maven 3.6.0
Maven home: /usr/share/maven
Java version: 1.8.0_171, vendor: Oracle Corporation, runtime:
/usr/lib/jvm/java-8-openjdk-amd64/jre
Default locale: fi_FI, platform encoding: UTF-8
OS name: "linux", version: "4.19.0-1-amd64", arch: "amd64", family: "unix"
...
[DEBUG] Using transporter WagonTransporter with priority -1.0 for
https://jcenter.bintray.com/
[DEBUG] Using connector BasicRepositoryConnector with priority 0.0 for
https://jcenter.bintray.com/
Downloading from jcenter:
https://jcenter.bintray.com/net/minidev/json-smart/2.3-SNAPSHOT/json-smart-2.3-SNAPSHOT.pom
[INFO] 
[INFO] BUILD FAILURE
[INFO] 
[INFO] Total time:  3.936 s
[INFO] Finished at: 2019-01-09T09:19:46+02:00
[INFO] 
---
constituent[0]: file:/usr/share/maven/conf/logging/
constituent[1]: file:/usr/share/maven/lib/maven-settings-builder-3.x.jar
constituent[2]: file:/usr/share/maven/lib/maven-plugin-api-3.x.jar
constituent[3]: file:/usr/share/maven/lib/plexus-cipher.jar
constituent[4]: file:/usr/share/maven/lib/aopalliance.jar
constituent[5]: file:/usr/share/maven/lib/maven-model-3.x.jar
constituent[6]: file:/usr/share/maven/lib/wagon-http-shaded.jar
constituent[7]: file:/usr/share/maven/lib/plexus-utils.jar
constituent[8]: file:/usr/share/maven/lib/maven-resolver-transport-wagon.jar
constituent[9]: file:/usr/share/maven/lib/cdi-api.jar
constituent[10]: file:/usr/share/maven/lib/plexus-component-annotations.jar
constituent[11]: file:/usr/share/maven/lib/maven-resolver-spi.jar
constituent[12]: file:/usr/share/maven/lib/maven-builder-support-3.x.jar
constituent[13]: file:/usr/share/maven/lib/guava.jar
constituent[14]: file:/usr/share/maven/lib/sisu-inject.jar
constituent[15]: file:/usr/share/maven/lib/sisu-plexus.jar
constituent[16]: file:/usr/share/maven/lib/jcl-over-slf4j.jar
constituent[17]: file:/usr/share/maven/lib/maven-resolver-connector-basic.jar
constituent[18]: file:/usr/share/maven/lib/maven-repository-metadata-3.x.jar
constituent[19]: file:/usr/share/maven/lib/commons-cli.jar
constituent[20]: file:/usr/share/maven/lib/commons-io.jar
constituent[21]: file:/usr/share/maven/lib/maven-embedder-3.x.jar
constituent[22]: file:/usr/share/maven/lib/plexus-interpolation.jar
constituent[23]: file:/usr/share/maven/lib/maven-artifact-3.x.jar
constituent[24]: file:/usr/share/maven/lib/maven-resolver-provider-3.x.jar
constituent[25]: file:/usr/share/maven/lib/plexus-sec-dispatcher.jar
constituent[26]: file:/usr/share/maven/lib/wagon-file.jar
constituent[27]: file:/usr/share/maven/lib/jsr250-api.jar
constituent[28]: file:/usr/share/maven/lib/maven-slf4j-provider-3.x.jar
constituent[29]: file:/usr/share/maven/lib/jansi.jar
constituent[30]: file:/usr/share/maven/lib/javax.inject.jar
constituent[31]: file:/usr/share/maven/lib/maven-model-builder-3.x.jar
constituent[32]: file:/usr/share/maven/lib/maven-resolver-impl.jar
constituent[33]: file:/usr/share/maven/lib/maven-resolver-api.jar
constituent[34]: file:/usr/share/maven/lib/maven-compat-3.x.jar
constituent[35]: file:/usr/share/maven/lib/maven-settings-3.x.jar
constituent[36]: file:/usr/share/maven/lib/maven-core-3.x.jar
constituent[37]: file:/usr/share/maven/lib/slf4j-api.jar
constituent[38]: file:/usr/share/maven/lib/guice.jar
constituent[39]: file:/usr/share/maven/lib/wagon-provider-api.jar
constituent[40]: file:/usr/share/maven/lib/maven-shared-utils.jar
constituent[41]: file:/usr/share/maven/lib/commons-lang3.jar
constituent[42]: file:/usr/share/maven/lib/maven-resolver-util.jar
---
Exception in thread "main" java.lang.NoSuchMethodError:
java.nio.ByteBuffer.flip()Ljava/nio/ByteBuffer;
at 
org.apache.maven.wagon.providers.http.httpclient.client.utils.URLEncodedUtils.urlDecode(URLEncodedUtils.java:590)
at 
org.apache.maven.wagon.providers.http.httpclient.client.utils.URLEncodedUtils.decodeFormFields(URLEncodedUtils.java:619)
at 
org.apache.maven.wagon.providers.http.httpclient.client.utils.URLEncodedUtils.parse(URLEncodedUtils.java:316)
at 

Bug#918399: Please add versioned breaks for packages failing in testing and succeeding in unstable

[Antonio Valentino]

Hello,
I think that a versioned breaks shall be also added for the for the
pytables package.

pytables << 3.4.4-2

Pytables failed in their CI tests because versions earlier than 3.4.4-2
was incompatible with the new numpy 1.16.

A fix has been implemented in pytables package version 3.4.4-2 and the
patch has been already integrated upstream.



kind regards

-- 
Antonio Valentino

Bug#918771: theano: FTBFS with cython3 0.29

[Rebecca N. Palmer]

Source: theano
Severity: important

[Originally reported privately]

When using cython3 from experimental, the build fails at this point:

cd theano/scan_module && cython3 scan_perform.pyx && patch 
--no-backup-if-mismatch scan_perform.c numpy_api_changes.diff && mv 
scan_perform.c -t c_code
/usr/lib/python3/dist-packages/Cython/Compiler/Main.py:367: 
FutureWarning: Cython directive 'language_level' not set, using 2 for 
now (Py2). This will change in a later release! File: 
/home/rnpalmer/Debian/builds/stackbuild/theano/theano/scan_module/scan_perform.pyx

  tree = Parsing.p_module(s, pxd, full_module_name)
patching file scan_perform.c
Hunk #1 FAILED at 6667.
Hunk #2 FAILED at 8237.
Hunk #3 FAILED at 8246.
Hunk #4 FAILED at 8285.
Hunk #5 FAILED at 8307.
5 out of 5 hunks FAILED -- saving rejects to file scan_perform.c.rej
make[1]: *** [debian/rules:31: override_dh_auto_build] Error 1
make[1]: Leaving directory '/home/rnpalmer/Debian/builds/stackbuild/theano'
make: *** [debian/rules:12: binary] Error 2

Skipping this patch is reported to build, but has not yet been tested.

Bug#864082: [Fontconfig] Next steps for a reproducible Fontconfig?

[Akira TAGOH]

Thank you for reminding and sorry for late response on this. I was on
long holidays.

On Fri, Jan 4, 2019 at 9:29 PM Chris Lamb  wrote:
> Since then, I don't believe there has been any review of this
> branch both in the sense of the code itself but also in terms of
> the architectural changes that it implies. I might be able to help
> on the former front but without knowing the "lore" of Fontconfig I
> simply cannot comment on the latter parts.

As of the discussion on the list, Keith's changes doesn't address the
original purpose - allow sharing caches on bind-mounts in flatpaks.
particularly for the case where flatpaks uses same location in
sandbox. this is the reason why it can't be merged into master.
So just reverting the change that removes .uuid file only when a
directory has empty is done in master so far. if you have .uuid file
prior to run fc-cache, your issue could be worked around at this
moment. for more details, you can check what Alex Larsson said on this
list.

>
> Anyway, I'd love to get this resolved once and for all ideally get
> it into Debian buster which is about to start "freezing" very
> soon.
>
> What would be the best way for me to help here? Can I entreat Keith
> to merge his branch? I can put some cycles onto this issue if that is
> of some assistance.
>
>
> Best wishes,
>
> --
> Chris Lamb
> chris-lamb.co.uk / @lolamby
> ___
> Fontconfig mailing list
> fontcon...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/fontconfig



-- 
Akira TAGOH

Bug#907492: fixed in pam 1.1.8-4

[Niels Thykier]

On Wed, 09 Jan 2019 06:49:21 + Steve Langasek  wrote:
> Source: pam
> Source-Version: 1.1.8-4
> 
> [...]
> Changes:
>  pam (1.1.8-4) unstable; urgency=medium
>  .
>* [...]
>* Actually remove Roger Leigh from uploaders (change not included in
>  previous upload).  Thanks Roger for your contributions to Debian!
>* Use DEB_BUILD_PROFILES instead of the obsolete DEB_BUILD_PROFILE.
>  Closes: #907492.


Hi Steve,

Thanks for doing this upload and using the standardized
DEB_BUILD_PROFILES now. :)

And I apologies for my previous email to this report.  I feel some of my
frustrations visibly leaked through and that was not acceptable on my
part for you asking that I cancelled my NMU.

>* Don't include changes to autogenerated files in patches.

I am glad this is fixed; that was a rather annoying bug when testing
building the NMU. :)  I am a bit surprised it did not have a bug
already.  Oh well, it is fixed. :)

Thanks,
~Niels

Bug#918529: openconnect: version 8.01 available upstream

[Mike Miller]

Control: tags -1 + pending

On Sun, Jan 06, 2019 at 22:14:36 -0500, Daniel Kahn Gillmor wrote:
> on the mailing list, i see that openconnect 8.01 is available
> upstream.  it's also tagged in the upstream git repository.
> 
> please package the new version for debian!

Yeah, in progress now, partially done in git, should be in unstable in a
day or two.

Thanks for your interest!

-- 
mike


signature.asc
Description: PGP signature

Bug#918770: ocaml-migrate-parsetree: build-dep on opam-installer

[Ralf Treinen]

Source: ocaml-migrate-parsetree
Version: 1.2.0-1
Severity: wishlist

The package build-depends on opam, which is not installable on some
architecures [1]. These architecures are not release architecures,
hence this is only wishlist.

I strongly suspect that this build-dependency can be replaced by
opam-installer which has much less dependencies. This might make
the package build on all architectures.

-Ralf.

[1] 
https://buildd.debian.org/status/package.php?p=ocaml-migrate-parsetree=sid

Bug#918769: ocaml-migrate-parsetree FTBFS:dh_install fails

[Ralf Treinen]

Source: ocaml-migrate-parsetree
Version: 1.2.0-1
Severity: serious
Tags: ftbfs

ocaml-migrate-parsetree fails to build on sid using debhelper version 12
(12 is the version of the debhelper package, I haven't touched the DH
compat level) :

dh_install: libmigrate-parsetree-ocamlbuild-ocaml missing files: 
usr/doc/ocaml-migrate-parsetree-ocamlbuild/{CHANGES.md,README.md,LICENSE.md}
dh_install: missing files, aborting
make: *** [debian/rules:8: binary] Error 25

-Ralf.

Bug#918768: opencolorio FTBFS with yaml-cpp 0.6.2

[Adrian Bunk]

Source: opencolorio
Version: 1.1.0~dfsg0-3
Severity: serious
Tags: ftbfs

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/opencolorio.html

...
/usr/bin/c++ -fPIC -g -O2 
-ffile-prefix-map=/build/1st/opencolorio-1.1.0~dfsg0=. -fstack-protector-strong 
-Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -Wall -Wextra 
-Wshadow -Wconversion -Wcast-qual -Wformat=2 -Wl,-z,relro -shared 
-Wl,-soname,libOpenColorIO.so.1 -o libOpenColorIO.so.1.1.0 
CMakeFiles/OpenColorIO.dir/AllocationOp.cpp.o 
CMakeFiles/OpenColorIO.dir/AllocationTransform.cpp.o 
CMakeFiles/OpenColorIO.dir/Baker.cpp.o 
CMakeFiles/OpenColorIO.dir/CDLTransform.cpp.o 
CMakeFiles/OpenColorIO.dir/Caching.cpp.o 
CMakeFiles/OpenColorIO.dir/ColorSpace.cpp.o 
CMakeFiles/OpenColorIO.dir/ColorSpaceTransform.cpp.o 
CMakeFiles/OpenColorIO.dir/Config.cpp.o 
CMakeFiles/OpenColorIO.dir/Context.cpp.o 
CMakeFiles/OpenColorIO.dir/Display.cpp.o 
CMakeFiles/OpenColorIO.dir/DisplayTransform.cpp.o 
CMakeFiles/OpenColorIO.dir/Exception.cpp.o 
CMakeFiles/OpenColorIO.dir/ExponentOps.cpp.o 
CMakeFiles/OpenColorIO.dir/ExponentTransform.cpp.o 
CMakeFiles/OpenColorIO.dir/FileFormat3DL.cpp.o 
CMakeFiles/OpenColorIO.dir/FileFormatCC.cpp.o 
CMakeFiles/OpenColorIO.dir/FileFormatCCC.cpp.o 
CMakeFiles/OpenColorIO.dir/FileFormatCDL.cpp.o 
CMakeFiles/OpenColorIO.dir/FileFormatCSP.cpp.o 
CMakeFiles/OpenColorIO.dir/FileFormatHDL.cpp.o 
CMakeFiles/OpenColorIO.dir/FileFormatIridasCube.cpp.o 
CMakeFiles/OpenColorIO.dir/FileFormatIridasItx.cpp.o 
CMakeFiles/OpenColorIO.dir/FileFormatIridasLook.cpp.o 
CMakeFiles/OpenColorIO.dir/FileFormatPandora.cpp.o 
CMakeFiles/OpenColorIO.dir/FileFormatSpi1D.cpp.o 
CMakeFiles/OpenColorIO.dir/FileFormatSpi3D.cpp.o 
CMakeFiles/OpenColorIO.dir/FileFormatSpiMtx.cpp.o 
CMakeFiles/OpenColorIO.dir/FileFormatTruelight.cpp.o 
CMakeFiles/OpenColorIO.dir/FileFormatVF.cpp.o 
CMakeFiles/OpenColorIO.dir/FileTransform.cpp.o 
CMakeFiles/OpenColorIO.dir/GpuShaderDesc.cpp.o 
CMakeFiles/OpenColorIO.dir/GpuShaderUtils.cpp.o 
CMakeFiles/OpenColorIO.dir/GroupTransform.cpp.o 
CMakeFiles/OpenColorIO.dir/HashUtils.cpp.o 
CMakeFiles/OpenColorIO.dir/ImageDesc.cpp.o 
CMakeFiles/OpenColorIO.dir/ImagePacking.cpp.o 
CMakeFiles/OpenColorIO.dir/LogOps.cpp.o 
CMakeFiles/OpenColorIO.dir/LogTransform.cpp.o 
CMakeFiles/OpenColorIO.dir/Logging.cpp.o CMakeFiles/OpenColorIO.dir/Look.cpp.o 
CMakeFiles/OpenColorIO.dir/LookParse.cpp.o 
CMakeFiles/OpenColorIO.dir/LookTransform.cpp.o 
CMakeFiles/OpenColorIO.dir/Lut1DOp.cpp.o 
CMakeFiles/OpenColorIO.dir/Lut3DOp.cpp.o 
CMakeFiles/OpenColorIO.dir/MathUtils.cpp.o 
CMakeFiles/OpenColorIO.dir/MatrixOps.cpp.o 
CMakeFiles/OpenColorIO.dir/MatrixTransform.cpp.o 
CMakeFiles/OpenColorIO.dir/NoOps.cpp.o 
CMakeFiles/OpenColorIO.dir/OCIOYaml.cpp.o CMakeFiles/OpenColorIO.dir/Op.cpp.o 
CMakeFiles/OpenColorIO.dir/OpOptimizers.cpp.o 
CMakeFiles/OpenColorIO.dir/ParseUtils.cpp.o 
CMakeFiles/OpenColorIO.dir/PathUtils.cpp.o 
CMakeFiles/OpenColorIO.dir/Platform.cpp.o 
CMakeFiles/OpenColorIO.dir/Processor.cpp.o 
CMakeFiles/OpenColorIO.dir/ScanlineHelper.cpp.o 
CMakeFiles/OpenColorIO.dir/Transform.cpp.o 
CMakeFiles/OpenColorIO.dir/TruelightOp.cpp.o 
CMakeFiles/OpenColorIO.dir/TruelightTransform.cpp.o 
CMakeFiles/OpenColorIO.dir/UnitTest.cpp.o 
CMakeFiles/OpenColorIO.dir/md5/md5.cpp.o 
CMakeFiles/OpenColorIO.dir/pystring/pystring.cpp.o -ltinyxml -lyaml-cpp 
/usr/bin/ld: CMakeFiles/OpenColorIO.dir/OCIOYaml.cpp.o: in function 
`YAML::BadSubscript::BadSubscript()':
/usr/include/yaml-cpp/exceptions.h:122: undefined reference to `vtable for 
YAML::Exception'
/usr/bin/ld: CMakeFiles/OpenColorIO.dir/OCIOYaml.cpp.o: relocation 
R_X86_64_PC32 against undefined hidden symbol `_ZTVN4YAML9ExceptionE' can not 
be used when making a shared object
/usr/bin/ld: final link failed: bad value
collect2: error: ld returned 1 exit status
make[3]: *** [src/core/CMakeFiles/OpenColorIO.dir/build.make:1004: 
src/core/libOpenColorIO.so.1.1.0] Error 1


The Ubuntu diff seems to contain a fix.

Bug#918767: rivet FTBFS with yaml-cpp 0.6.2

[Adrian Bunk]

Source: rivet
Version: 1.8.3-2
Severity: serious
Tags: ftbfs patch

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/rivet.html

...
In file included from /usr/include/c++/8/array:35,
 from /usr/include/yaml-cpp/node/convert.h:10,
 from /usr/include/yaml-cpp/yaml.h:18,
 from AnalysisInfo.cc:7:
/usr/include/c++/8/bits/c++0x_warning.h:32:2: error: #error This file requires 
compiler and library support for the ISO C++ 2011 standard. This support must 
be enabled with the -std=c++11 or -std=gnu++11 compiler options.
 #error This file requires compiler and library support \


Fix attached.
Description: Don't force a lower C++ standard with -ansi
 This causes FTBFS with yaml-cpp 0.6.2.
Author: Adrian Bunk 

--- rivet-1.8.3.orig/configure.ac
+++ rivet-1.8.3/configure.ac
@@ -316,7 +316,6 @@ AM_CPPFLAGS="$AM_CPPFLAGS -I\$(BOOSTINCP
 AM_CPPFLAGS="$AM_CPPFLAGS -I\$(HEPMCINCPATH)"
 AM_CPPFLAGS="$AM_CPPFLAGS -I\$(FASTJETINCPATH)"
 AC_CEDAR_CHECKCXXFLAG([-pedantic], [AM_CXXFLAGS="$AM_CXXFLAGS -pedantic"])
-AC_CEDAR_CHECKCXXFLAG([-ansi], [AM_CXXFLAGS="$AM_CXXFLAGS -ansi"])
 AC_CEDAR_CHECKCXXFLAG([-Wall], [AM_CXXFLAGS="$AM_CXXFLAGS -Wall"])
 AC_CEDAR_CHECKCXXFLAG([-Wno-long-long], [AM_CXXFLAGS="$AM_CXXFLAGS 
-Wno-long-long"])
 AC_CEDAR_CHECKCXXFLAG([-Wno-format], [AM_CXXFLAGS="$AM_CXXFLAGS -Wno-format"])

Bug#918569: Could not find 'activerecord' (~> 4.2) - did find: [activerecord-5.2.0]

[Pirate Praveen]

On Mon, 07 Jan 2019 22:39:41 +0100 t...@schleuder.org wrote:
> 
> Upstream (aka us) is working on switching to activerecord 5.2:
> https://0xacab.org/schleuder/schleuder/issues/372

Hi paz,

Would it be possible to upload a release candidate/dev version right now
to help with rails transition? You can update it to stable version as
per your current schedule.

Thanks
Praveen



signature.asc
Description: OpenPGP digital signature

Bug#918766: RM: ruby-rack-contrib -- ROM; no uploaders, no reverse depends, delaying rails 5 transition

[Pirate Praveen]

Package: ftp.debian.org
Severity: normal

The last uploader removed themselves, its last reverse build dependency 
(ruby-grape) does not actually need it (removed build dependency in 
last update), and it is delaying rails 5 transition.

Bug#918765: hhsuite-data: does not provide /usr/share/hhsuite/data/context_data.crf

[Andrius Merkys]

Package: hhsuite-data
Severity: important
Control: tags -1 + patch

Hello,

hhsuite-data does not provide /usr/share/hhsuite/data/context_data.crf, which 
is the default context file for computing context-specific pseudocounts. This 
effectively breaks hhmake and hhblits unless path to existing context_data.crf 
is provided via '-contxt' command line option.

Steps to reproduce:

andrius@amalas:~$ gunzip -c /usr/share/doc/hhsuite/examples/query.a3m.gz > 
query.a3m
andrius@amalas:~$ hhmake -i query.a3m
- 01:33:47.860 ERROR: Could not open file 
'/usr/share/hhsuite/data/context_data.crf'

The following patch should fix the bug (was not able to try due to #917495):

diff --git a/debian/hhsuite-data.install b/debian/hhsuite-data.install
index e4403f1..f7d762c 100644
--- a/debian/hhsuite-data.install
+++ b/debian/hhsuite-data.install
@@ -1,4 +1,6 @@
 usr/data/context_data.lib usr/share/hhsuite/data
+usr/data/context_data.crf usr/share/hhsuite/data
 usr/data/cs219.lib usr/share/hhsuite/data
 usr/data/context_data.lib usr/lib/hhsuite/data
+usr/data/context_data.crf usr/lib/hhsuite/data
 usr/data/cs219.lib usr/lib/hhsuite/data
diff --git a/debian/hhsuite-data.links b/debian/hhsuite-data.links
index 4efda75..e9a226f 100644
--- a/debian/hhsuite-data.links
+++ b/debian/hhsuite-data.links
@@ -1,2 +1,3 @@
 usr/share/hhsuite/data/context_data.lib usr/lib/hhsuite/data/context_data.lib
+usr/share/hhsuite/data/context_data.crf usr/lib/hhsuite/data/context_data.crf
 usr/share/hhsuite/data/cs219.lib usr/lib/hhsuite/data/cs219.lib

Best,
Andrius

[#917495] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=917495

-- 
Andrius Merkys
Vilnius University Institute of Biotechnology, Saulėtekio al. 7, room V325
LT-10257 Vilnius, Lithuania

Bug#918764: udev: "udevadm control --reload-rules" kills all processes except init

[Axel Beckert]

Package: udev
Version: 240-2
Severity: critical
Justification: Breaks whole system

Hi,

I have no idea why this is happening, but several packages use "udevadm
control --reload-rules" in their postinst (e.g. fuse) and if that's run,
all process except init are instantly killed (reproducibly; the gettys
seem to be respawned by init then, so I can login locally again) and
since sshd is killed, too, the system is usually no more accessible from
remote (hence the severity "critical") despite still responding to ping
replies.

There's nothing in dmesg. And corekeeper didn't catch any core either.

Some more details which might be helpful:

* The udev daemon itself also vanishes and this happens independently of
  the udev daemon being running or not (i.e. "service udev start" before
  calling udevadm doesn't prevent this from happening).

* The other two udevadm command from fuse's postinst don't seem to
  trigger this:

  udevadm test --action -p  $(udevadm info -q path -n /dev/fuse)

* It first happened when I install linux-image-4.20-trunk-amd64 from
  experimental about a week ago or so. Since I was away from home until
  yesterday evening, I could only recently start to debug this.

Here's an strace of that command:

execve("/sbin/udevadm", ["udevadm", "control", "--reload-rules"], 
0x7ffd60743730 /* 39 vars */) = 0
brk(NULL)   = 0x561a4e851000
access("/etc/ld.so.nohwcap", F_OK)  = -1 ENOENT (No such file or directory)
access("/etc/ld.so.preload", R_OK)  = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=446764, ...}) = 0
mmap(NULL, 446764, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f52728ca000
close(3)= 0
access("/etc/ld.so.nohwcap", F_OK)  = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\260A\2\0\0\0\0\0"..., 
832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=1824496, ...}) = 0
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0x7f52728c8000
mmap(NULL, 1837056, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f5272707000
mprotect(0x7f5272729000, 1658880, PROT_NONE) = 0
mmap(0x7f5272729000, 1343488, PROT_READ|PROT_EXEC, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x22000) = 0x7f5272729000
mmap(0x7f5272871000, 311296, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 
0x16a000) = 0x7f5272871000
mmap(0x7f52728be000, 24576, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1b6000) = 0x7f52728be000
mmap(0x7f52728c4000, 14336, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f52728c4000
close(3)= 0
access("/etc/ld.so.nohwcap", F_OK)  = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/libkmod.so.2", O_RDONLY|O_CLOEXEC) 
= 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\0206\0\0\0\0\0\0"..., 
832) = 832
fstat(3, {st_mode=S_IFREG|0644, st_size=100400, ...}) = 0
mmap(NULL, 102472, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f52726ed000
mprotect(0x7f52726f, 86016, PROT_NONE) = 0
mmap(0x7f52726f, 61440, PROT_READ|PROT_EXEC, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x3000) = 0x7f52726f
mmap(0x7f52726ff000, 20480, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 
0x12000) = 0x7f52726ff000
mmap(0x7f5272705000, 8192, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x17000) = 0x7f5272705000
close(3)= 0
access("/etc/ld.so.nohwcap", F_OK)  = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libacl.so.1", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\0\37\0\0\0\0\0\0"..., 
832) = 832
fstat(3, {st_mode=S_IFREG|0644, st_size=35488, ...}) = 0
mmap(NULL, 2130592, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 
0x7f52724e4000
mprotect(0x7f52724eb000, 2097152, PROT_NONE) = 0
mmap(0x7f52726eb000, 8192, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x7000) = 0x7f52726eb000
close(3)= 0
access("/etc/ld.so.nohwcap", F_OK)  = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libblkid.so.1", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0P\257\0\0\0\0\0\0"..., 
832) = 832
fstat(3, {st_mode=S_IFREG|0644, st_size=343008, ...}) = 0
mmap(NULL, 345896, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f527248f000
mprotect(0x7f5272499000, 282624, PROT_NONE) = 0
mmap(0x7f5272499000, 212992, PROT_READ|PROT_EXEC, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xa000) = 0x7f5272499000
mmap(0x7f52724cd000, 65536, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 
0x3e000) = 0x7f52724cd000
mmap(0x7f52724de000, 24576, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x4e000) = 

Bug#918763: stretch-pu: package twitter-bootstrap3/3.3.7+dfsg-2

[Xavier Guimard]

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

Hello, twitter-bootstrap3 has some CVEs to fix (issues marked as
no-dsa). This patch imports related fix from twitter-bootstrap 3.4.

Cheers,
Xavier

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

Kernel: Linux 4.19.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE= 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru twitter-bootstrap3-3.3.7+dfsg/debian/changelog 
twitter-bootstrap3-3.3.7+dfsg/debian/changelog
--- twitter-bootstrap3-3.3.7+dfsg/debian/changelog  2016-10-24 
14:45:58.0 +0200
+++ twitter-bootstrap3-3.3.7+dfsg/debian/changelog  2019-01-06 
23:34:50.0 +0100
@@ -1,3 +1,11 @@
+twitter-bootstrap3 (3.3.7+dfsg-2+deb9u1) stretch; urgency=high
+
+  * Team upload.
+  * Fix multiples XSS vulnerabilities (Closes: #907414)
+  * Update debian/copyright
+
+ -- Xavier Guimard   Sun, 06 Jan 2019 23:34:50 +0100
+
 twitter-bootstrap3 (3.3.7+dfsg-2) unstable; urgency=medium
 
   * Team upload
diff -Nru twitter-bootstrap3-3.3.7+dfsg/debian/copyright 
twitter-bootstrap3-3.3.7+dfsg/debian/copyright
--- twitter-bootstrap3-3.3.7+dfsg/debian/copyright  2016-10-24 
14:45:58.0 +0200
+++ twitter-bootstrap3-3.3.7+dfsg/debian/copyright  2019-01-06 
23:34:36.0 +0100
@@ -9,7 +9,7 @@
 js/tests/vendor/jquery.min.js
 
 Files: *
-Copyright: 2011-2015, Twitter, Inc.
+Copyright: 2011-2018, Twitter, Inc.
2014, jQuery Foundation and other contributors
2014, "Cowboy" Ben Alman, contributors
HTML5 Boilerplate
diff -Nru 
twitter-bootstrap3-3.3.7+dfsg/debian/patches/fix-xss-vulnerabilities.patch 
twitter-bootstrap3-3.3.7+dfsg/debian/patches/fix-xss-vulnerabilities.patch
--- twitter-bootstrap3-3.3.7+dfsg/debian/patches/fix-xss-vulnerabilities.patch  
1970-01-01 01:00:00.0 +0100
+++ twitter-bootstrap3-3.3.7+dfsg/debian/patches/fix-xss-vulnerabilities.patch  
2019-01-06 23:34:15.0 +0100
@@ -0,0 +1,305 @@
+Description: Fix multies vulnerabilities
+Author: Xavier Guimard 
+Origin: upstream, 
https://github.com/twbs/bootstrap/pull/26630/commits/efca80bb5bb34546a2e7a9488b89f71457d2ad92
+Bug: https://github.com/twbs/bootstrap/pull/26630
+Bug-Debian: https://bugs.debian.org/907414
+Forwarded: not-needed
+Last-Update: 2019-01-06
+
+--- a/dist/js/bootstrap.js
 b/dist/js/bootstrap.js
+@@ -1,6 +1,6 @@
+ /*!
+  * Bootstrap v3.3.7 (http://getbootstrap.com)
+- * Copyright 2011-2016 Twitter, Inc.
++ * Copyright 2011-2018 Twitter, Inc.
+  * Licensed under the MIT license
+  */
+ 
+@@ -109,7 +109,8 @@
+   selector = selector && selector.replace(/.*(?=#[^\s]*$)/, '') // strip 
for ie7
+ }
+ 
+-var $parent = $(selector === '#' ? [] : selector)
++selector= selector === '#' ? [] : selector
++var $parent = $(document).find(selector)
+ 
+ if (e) e.preventDefault()
+ 
+@@ -443,7 +444,9 @@
+ var slidEvent = $.Event('slid.bs.carousel', { relatedTarget: 
relatedTarget, direction: direction }) // yes, "slid"
+ if ($.support.transition && this.$element.hasClass('slide')) {
+   $next.addClass(type)
+-  $next[0].offsetWidth // force reflow
++  if (typeof $next === 'object' && $next.length) {
++$next[0].offsetWidth // force reflow
++  }
+   $active.addClass(direction)
+   $next.addClass(direction)
+   $active
+@@ -505,10 +508,17 @@
+   // =
+ 
+   var clickHandler = function (e) {
+-var href
+ var $this   = $(this)
+-var $target = $($this.attr('data-target') || (href = $this.attr('href')) 
&& href.replace(/.*(?=#[^\s]+$)/, '')) // strip for ie7
++var href= $this.attr('href')
++if (href) {
++  href = href.replace(/.*(?=#[^\s]+$)/, '') // strip for ie7
++}
++
++var target  = $this.attr('data-target') || href
++var $target = $(document).find(target)
++
+ if (!$target.hasClass('carousel')) return
++
+ var options = $.extend({}, $target.data(), $this.data())
+ var slideIndex = $this.attr('data-slide-to')
+ if (slideIndex) options.interval = false
+@@ -674,7 +684,7 @@
+   }
+ 
+   Collapse.prototype.getParent = function () {
+-return $(this.options.parent)
++return $(document).find(this.options.parent)
+   .find('[data-toggle="collapse"][data-parent="' + this.options.parent + 
'"]')
+   .each($.proxy(function (i, element) {
+ var $element = $(element)
+@@ -697,7 +707,7 @@
+ var target = $trigger.attr('data-target')
+   || (href = $trigger.attr('href')) && href.replace(/.*(?=#[^\s]+$)/, '') 
// strip for ie7
+ 
+-return $(target)
++return $(document).find(target)
+   }
+ 
+ 
+@@ -779,7 +789,7 @@
+   

Bug#918762: stretch-pu: package twitter-bootstrap3/3.3.7+dfsg-2

[Xavier Guimard]

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

Hello, twitter-bootstrap3 has some CVEs to fix (issues marked as
no-dsa). This patch imports related fix from twitter-bootstrap 3.4.

Cheers,
Xavier

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

Kernel: Linux 4.19.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE= 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru twitter-bootstrap3-3.3.7+dfsg/debian/changelog 
twitter-bootstrap3-3.3.7+dfsg/debian/changelog
--- twitter-bootstrap3-3.3.7+dfsg/debian/changelog  2016-10-24 
14:45:58.0 +0200
+++ twitter-bootstrap3-3.3.7+dfsg/debian/changelog  2019-01-06 
23:34:50.0 +0100
@@ -1,3 +1,11 @@
+twitter-bootstrap3 (3.3.7+dfsg-3+deb9u1) stretch; urgency=high
+
+  * Team upload.
+  * Fix multiples XSS vulnerabilities (Closes: #907414)
+  * Update debian/copyright
+
+ -- Xavier Guimard   Sun, 06 Jan 2019 23:34:50 +0100
+
 twitter-bootstrap3 (3.3.7+dfsg-2) unstable; urgency=medium
 
   * Team upload
diff -Nru twitter-bootstrap3-3.3.7+dfsg/debian/copyright 
twitter-bootstrap3-3.3.7+dfsg/debian/copyright
--- twitter-bootstrap3-3.3.7+dfsg/debian/copyright  2016-10-24 
14:45:58.0 +0200
+++ twitter-bootstrap3-3.3.7+dfsg/debian/copyright  2019-01-06 
23:34:36.0 +0100
@@ -9,7 +9,7 @@
 js/tests/vendor/jquery.min.js
 
 Files: *
-Copyright: 2011-2015, Twitter, Inc.
+Copyright: 2011-2018, Twitter, Inc.
2014, jQuery Foundation and other contributors
2014, "Cowboy" Ben Alman, contributors
HTML5 Boilerplate
diff -Nru 
twitter-bootstrap3-3.3.7+dfsg/debian/patches/fix-xss-vulnerabilities.patch 
twitter-bootstrap3-3.3.7+dfsg/debian/patches/fix-xss-vulnerabilities.patch
--- twitter-bootstrap3-3.3.7+dfsg/debian/patches/fix-xss-vulnerabilities.patch  
1970-01-01 01:00:00.0 +0100
+++ twitter-bootstrap3-3.3.7+dfsg/debian/patches/fix-xss-vulnerabilities.patch  
2019-01-06 23:34:15.0 +0100
@@ -0,0 +1,305 @@
+Description: Fix multies vulnerabilities
+Author: Xavier Guimard 
+Origin: upstream, 
https://github.com/twbs/bootstrap/pull/26630/commits/efca80bb5bb34546a2e7a9488b89f71457d2ad92
+Bug: https://github.com/twbs/bootstrap/pull/26630
+Bug-Debian: https://bugs.debian.org/907414
+Forwarded: not-needed
+Last-Update: 2019-01-06
+
+--- a/dist/js/bootstrap.js
 b/dist/js/bootstrap.js
+@@ -1,6 +1,6 @@
+ /*!
+  * Bootstrap v3.3.7 (http://getbootstrap.com)
+- * Copyright 2011-2016 Twitter, Inc.
++ * Copyright 2011-2018 Twitter, Inc.
+  * Licensed under the MIT license
+  */
+ 
+@@ -109,7 +109,8 @@
+   selector = selector && selector.replace(/.*(?=#[^\s]*$)/, '') // strip 
for ie7
+ }
+ 
+-var $parent = $(selector === '#' ? [] : selector)
++selector= selector === '#' ? [] : selector
++var $parent = $(document).find(selector)
+ 
+ if (e) e.preventDefault()
+ 
+@@ -443,7 +444,9 @@
+ var slidEvent = $.Event('slid.bs.carousel', { relatedTarget: 
relatedTarget, direction: direction }) // yes, "slid"
+ if ($.support.transition && this.$element.hasClass('slide')) {
+   $next.addClass(type)
+-  $next[0].offsetWidth // force reflow
++  if (typeof $next === 'object' && $next.length) {
++$next[0].offsetWidth // force reflow
++  }
+   $active.addClass(direction)
+   $next.addClass(direction)
+   $active
+@@ -505,10 +508,17 @@
+   // =
+ 
+   var clickHandler = function (e) {
+-var href
+ var $this   = $(this)
+-var $target = $($this.attr('data-target') || (href = $this.attr('href')) 
&& href.replace(/.*(?=#[^\s]+$)/, '')) // strip for ie7
++var href= $this.attr('href')
++if (href) {
++  href = href.replace(/.*(?=#[^\s]+$)/, '') // strip for ie7
++}
++
++var target  = $this.attr('data-target') || href
++var $target = $(document).find(target)
++
+ if (!$target.hasClass('carousel')) return
++
+ var options = $.extend({}, $target.data(), $this.data())
+ var slideIndex = $this.attr('data-slide-to')
+ if (slideIndex) options.interval = false
+@@ -674,7 +684,7 @@
+   }
+ 
+   Collapse.prototype.getParent = function () {
+-return $(this.options.parent)
++return $(document).find(this.options.parent)
+   .find('[data-toggle="collapse"][data-parent="' + this.options.parent + 
'"]')
+   .each($.proxy(function (i, element) {
+ var $element = $(element)
+@@ -697,7 +707,7 @@
+ var target = $trigger.attr('data-target')
+   || (href = $trigger.attr('href')) && href.replace(/.*(?=#[^\s]+$)/, '') 
// strip for ie7
+ 
+-return $(target)
++return $(document).find(target)
+   }
+ 
+ 
+@@ -779,7 +789,7 @@
+   

Bug#918761: abcde: glyrc and recode required

[David Griffith]

Package: abcde
Version: 2.9.2-1
Severity: important

Dear Maintainer,

Abcde depends upon glyrc and recode.  Glyrc is currently recommended, 
but not required.  Abcde refuses to start without this package 
installed.  Recode is not mentioned at all in abcde's APT entry.  If 
abcde is used without recode available, a complaint will be printed and 
the output directory is set to "-", which can be confusing given the 
meaning of the command "cd -".

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

Kernel: Linux 4.19.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.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages abcde depends on:
ii  cd-discid   1.4-1+b1
ii  cdparanoia  3.10.2+debian-13
ii  flac1.3.2-3
ii  libmusicbrainz-discid-perl  0.04-1+b1
ii  libwebservice-musicbrainz-perl  1.0.4-2
ii  sensible-utils  0.0.12
ii  vorbis-tools1.4.0-10.1
ii  wget1.20.1-1

Versions of packages abcde recommends:
pn  bsd-mailx
pn  glyrc1.0.10-1
ii  imagemagick  8:6.9.10.14+dfsg-7
ii  imagemagick-6.q16 [imagemagick]  8:6.9.10.14+dfsg-7
pn  libdigest-sha-perl   
ii  vorbis-tools 1.4.0-10.1

Versions of packages abcde suggests:
pn  atomicparsley
pn  distmp3  
ii  eject2.1.5+deb1+cvs20081104-13.2
pn  eyed3
pn  id3  
pn  id3v2
pn  mkcue
pn  mp3gain  
ii  normalize-audio  0.7.7-14+b1
ii  vorbisgain   0.37-2+b1

-- no debconf information

Bug#693230: latest upstream 0.51 release

[Fernando Toledo]

Hi!

anyone can update the package to the latest 0.51 version?


thanks!

Bug#885742: linsmith: GTK+ 3 / GooCanvas port may be available upstream

[Jeremy Bicha]

linsmith is now the last package keeping several libgnome libraries in
Debian Unstable. [1]

We'd like to remove those libraries soon, but I am willing to wait a
bit longer for someone to port linsmith to gtk3.

Note that the Debian Release Team requires your package to reach
Testing by February 12 to be included in the Buster release. [2]

[1] gnome-vfs, libbonobo, libbonoboui, libgnome, libgnome, libgnomeui, orbit2
[2] https://release.debian.org/buster/freeze_policy.html

Thanks,
Jeremy Bicha

Bug#918760: agree on how to find qhelpgenerator

[Helmut Grohne]

Package: qt5-qmake,qttools5-dev-tools,extra-cmake-modules
User: helm...@debian.org
Usertags: rebootstrap
Control: affects -1 + src:kpackage

kpackage fails to cross build from source and the cause is tricky. We
start our journey on extra-cmake-modules'
/usr/share/ECM/find-modules/FindQHelpGenerator.cmake. That file assumes
that it will find a "qhelpgenerator" executable next to the qmake
executable. The path of qmake is determined using

get_target_property(_qmake_EXECUTABLE Qt5::qmake LOCATION)

and results in:

/usr/lib//qt5/bin/qmake

Now, qttools5-dev-tools places qhelpgenerator in

/usr/lib/qt5/bin/qhelpgenerator
/usr/lib//qt5/bin/qhelpgenerator

and qtchooser additionally makes it available as:

/usr/bin/qhelpgenerator

The end result is that qhelpgenerator is not found and that kpackage
fails to cross build.

extra-cmake-modules's assumption on how to find qhelpgenerator is not
presently valid. We'll either have to reinstate the assumption or make
extra-cmake-modules not assume that.

Now I need your input on which package we need to touch.

Helmut

Bug#918702: ITP: nvtop -- Interactive NVIDIA GPU process monitor

[M. Zhou]

Hi  Maxime,

This utility looks cool!

If you intend to catch up with Buster freeze and get it into Buster
in time, please check the release schedule here:

  https://release.debian.org/

Don't hesitate to ask me or the debian-mentors list if you encountered
any problem.

> * Package name: nvtop
>   Version : 0.3.0
>   Upstream Author : Maxime Schmitt 
> * URL : https://github.com/Syllo/nvtop
> * License : GPL, MIT
>   Programming Lang: C
>   Description : Interactive NVIDIA GPU process monitor
> 
> Nvtop is a ncurses-based GPU monitoring interface which provides
> information on the GPU states (GPU and memory utilization, temperature,
> etc) and well as information about the processes executing on the GPUs.
> 
> --
> 
> This package provides a terminal-based monitoring tool for the GPUs when
> the NVIDIA proprietary drivers are installed. It provides a convenient
> interactive alternative to nvidia-smi.
> 
> I have personally no Debian packaging experience. I am willing to create
> the package and maintain it with some help to kick-start if possible.

Bug#918759: ITP: ruby-feature -- feature toggle library for ruby.

[李健秋]

Package: wnpp
Severity: wishlist
Owner: =?utf-8?b?QW5kcmV3IExlZSAo5p2O5YGl56eLKQ==?= 

* Package name: ruby-feature
  Version : 1.4.0
  Upstream Author : mgsnova 
* URL : https://github.com/mgsnova/feature
* License : MIT
  Programming Lang: Ruby
  Description : feature toggle library for ruby.

The feature toggle functionality has to be configured by feature
repositories. A feature repository simply provides lists of active
features (symbols!). Unknown features are assumed inactive.

With this approach Feature is highly configurable and not bound to a
specific kind of configuration.

Bug#918758: iftop: Doesn't support multi-gigabit interfaces

[Matthew Gabeler-Lee]

Package: iftop
Version: 1.0~pre4-5
Severity: normal
Tags: upstream

iftop doesn't properly handle interface speeds (e.g.  -m option) above
1Gbps.  Upstream has fixed this in git:
https://code.blinkace.com/pdw/iftop/commit/77901c8c53e01359d83b8090aacfe62214658183

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

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

Versions of packages iftop depends on:
ii  libc62.28-2
ii  libncurses6  6.1+20181013-1
ii  libpcap0.8   1.8.1-6
ii  libtinfo66.1+20181013-1

iftop recommends no packages.

iftop suggests no packages.

-- no debconf information

Bug#917492: fam: FTBFS ('minor' was not declared in this scope)

[Logan Rosen]

Control: tags -1 patch

Dear Maintainer,

In Ubuntu, the attached patch was applied to achieve the following:

  * debian/patches/19_glibc_2.28.patch: Fix FTBFS with glibc 2.28.

Thanks for considering the patch.

Logan Rosen

-- System Information:
Debian Release: buster/sid
  APT prefers cosmic-updates
  APT policy: (500, 'cosmic-updates'), (500, 'cosmic-security'), (500, 
'cosmic'), (400, 'cosmic-proposed'), (100, 'cosmic-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.18.0-13-generic (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
only in patch2:
unchanged:
--- fam-2.7.0.orig/debian/patches/19_glibc_2.28.patch
+++ fam-2.7.0/debian/patches/19_glibc_2.28.patch
@@ -0,0 +1,17 @@
+## Description: Fix FTBFS against glibc 2.28
+## Origin/Author: Logan Rosen 
+## Bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=917492
+diff -Nur -x '*.orig' -x '*~' fam-2.7.0/build-tree/fam-2.7.0/src/DNotify.c++ 
fam-2.7.0.new/build-tree/fam-2.7.0/src/DNotify.c++
+--- fam-2.7.0/src/DNotify.c++  2019-01-08 23:35:20.513574095 -0500
 fam-2.7.0/src/DNotify.c++  2019-01-08 23:36:37.568605429 -0500
+@@ -36,6 +36,10 @@
+ #include 
+ #include 
+ 
++#ifdef __GNU_LIBRARY__
++#include 
++#endif
++
+ #include "DNotify.h"
+ 
+ #include "Interest.h"

Bug#917857: NMU diff for aufs 4.19+20181217-0.1

[Ben Hutchings]

On Tue, 2019-01-08 at 13:08 +0100, Jan Luca Naumann wrote:
> Hey,
> 
> thank you for the upload and your work. I am sorry that I did not manage
> to upload the new version due to too much other workload.

There's nothing to be sorry about.  I usually check that out-of-tree
module packages are up-to-date as we approach the freeze.  This time I
took the time to update some of them too.

> I have seen that your delete the dependency on linux-kbuild. I have
> added it to avoid transition of the aufs-packages to testing before the
> linux package is available in the requested version. One time there was
> the problem that the aufs-package already migrated but the linux package
> had some RC-bug.

That's a good point, which perhaps should have been recorded in the git
commit log or the changelog, so that I didn't think it was a mistake.
:-)  To expand on what I wrote in the changelog:

- In order to use aufs-dkms, it's necessary to install a linux-headers
  package for a suitable kernel version.
- If that linux-headers package is one built by Debian, it already
  depends on linux-kbuild-4.19.
- However, if it's a custom package built using "make deb-pkg", it
  includes all the kbuild scripts and other tools.  Then there's no
  need to install linux-kbuild-4.19 at all.

But I suppose the extra dependency doesn't matter that much.  You're
the maintainer and should of course add it back if you still think it's
justified.

It's unfortunate that backwards-compatibility for aufs is maintained
through separate git branches rather than conditional code.  None of
the other out-of-tree modules packaged for Debian seem to be like this.
I wonder if it would be possible to support multiple kernel versions
like this:

- When preparing the source package, run a script to generate diffs
  from the latest upstream branch to each older branch that's still
  maintained, and add those under the debian directory.
- When building the binary packages, include the diffs in aufs-dkms.
- When building under dkms, start by applying the appropriate diff for
  the target kernel version.  (You might need to copy-and-patch, as I'm
  not sure whether dkms will unpack the source again when building for
  a different version.)

I haven't spent a whole lot of time thinking about this, so this might
well be impractical.

Ben.

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




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

Bug#918757: i965-va-driver: Please update to 2.3.0 for fuller Coffee Lake support

[Matthew Gabeler-Lee]

Package: i965-va-driver
Version: 2.2.0+dfsg1-2
Severity: normal

While the description of this package claims it contains support for Coffee
Lake, that support is incomplete in v2.2.0.  Upstream 2.3.0 release has
support for newer Coffee Lake (and Kaby Lake) PCI IDs that the 2.2 driver is
lacking.

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

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

Versions of packages i965-va-driver depends on:
ii  libc6  2.28-2
ii  libdrm-intel1  2.4.95-1
ii  libdrm22.4.95-1
ii  libva2 [libva-driver-abi-1.2]  2.3.0-2

i965-va-driver recommends no packages.

Versions of packages i965-va-driver suggests:
pn  i965-va-driver-shaders  

-- no debconf information

Bug#918432: [Pkg-samba-maint] Bug#918432: samba: net ads join to armel arch Samba DC failed

[Mathieu Parent]

Le dim. 6 janv. 2019 à 01:12, Tomasz Jelinski  a écrit :
>
> Package: samba
> Version: 2:4.5.12+dfsg-2+deb9u4
> Severity: normal
>
> Dear Maintainer,

Hi,

> I can't connect workstation to samba DC configured on Orion platform
> (armel arch) with installed  Debian Stretch (packages are fully updated to 
> newest avaliable versions).

Are you able to reproduce this from Debian testing (4.9.4)?

Regards

-- 
Mathieu Parent

Bug#918727: [Pkg-openssl-devel] Bug#918727: openssl.cnf incompatible with libssl1.0.2, libssl1.0.0

[Kurt Roeckx]

On Tue, Jan 08, 2019 at 08:17:42PM +, Simon McVittie wrote:
> Package: openssl
> Version: 1.1.1a-1
> Severity: important
> Control: found -1 1.1.1~~pre3-1
> Control: affects -1 steam
> 
> The openssl.cnf in the openssl package since 1.1.1~~pre3-1 is incompatible
> with libssl < 1.1.0 (I think that's the right cutoff point), either from
> a partial upgrade or bundled with third-party software.
> 
> It should probably at least have a Breaks on libssl1.0.2, to protect
> partial upgrades from stretch. Some release notes for users of
> third-party software might also be useful. I realise it probably isn't
> feasible to keep openssl.cnf compatible with all past and future versions.
[...]
> This affects libssl1.0.0 in the Steam Runtime installed by the non-free
> steam package, and possibly other third-party software bundles.
> ()

We can add a Breaks, but I'm not sure that's actually going to fix
anything for those non-free 3rd party things.


Kurt

Bug#918142: linux-image-4.19.0-1-amd64: Can no longer disable the touchscreen module

[Ben Hutchings]

Control: reassign -1 src:linux
Control: severity -1 wishlist
Control: tag -1 upstream

On Tue, 2019-01-08 at 14:27 +0100, Michael Biebl wrote:
[...]
> I thus don't see a problem in udev's way of loading the modules.
> 
> Ben, can you elaborate why you reassigned this to udev?
> Maybe I'm missing something obvious.

Because fakefur seemed to be saying that hid_multitouch was still
loaded.

I'm reassigning this back, but I won't take any action to fix this.

Ben.

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




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

Bug#900663: ITA: note -- small program managing notes from

[eamanu15]

Hi Simon,

Could you please push the version 1.3.26 to salsa?. I can see that
this version was upload to unstable on 2018-12-29
but on salsa is the 1.3.22.

Thanks!
Regards!

-- 
Arias Emmanuel
http://eamanu.com
Github/Gitlab; @eamanu
Debian: @eamanu-guest

Bug#918756: Broken by .txt.gz

[Trent W. Buck]

Package: dodgy
Version: 0.1.9-3
Severity: important
File: /usr/lib/python3/dist-packages/dodgy/run.py

dodgy basically does this:

  • recursively find all regular files under ./
  • for each file,
  • if its MIME type appears to be text/*,
  • assume it is UTF-8
  • assume it is uncompressed
  • search it for "bad" regular expressions, and report any matches

This misdetects compressed text files:

bash4$ with-temp-dir
with-temp-dir: entering directory `/tmp/with-temp-dir.stBmJY'
This directory will be deleted when you exit.
bash4$ wget -nv https://secure.eicar.org/eicar.com.txt
2019-01-09 13:54:31 URL:https://secure.eicar.org/eicar.com.txt [68/68] -> 
"eicar.com.txt" [1]
bash4$ gzip eicar.com.txt
bash4$ file --mime eicar.com.txt.gz
eicar.com.txt.gz: application/gzip; charset=binary
bash4$ python3 -m mimetypes eicar.com.txt.gz
type: text/plain encoding: gzip
bash4$ dodgy
Traceback (most recent call last):
  File "/usr/bin/dodgy", line 4, in 
dodgy.run.run()
  File "/usr/lib/python3/dist-packages/dodgy/run.py", line 56, in run
warnings = run_checks(os.getcwd())
  File "/usr/lib/python3/dist-packages/dodgy/run.py", line 44, in run_checks
for msg_parts in check_file(filepath):
  File "/usr/lib/python3/dist-packages/dodgy/checks.py", line 72, in 
check_file
return check_file_contents(to_check.read())
  File "/usr/lib/python3.7/codecs.py", line 701, in read
return self.reader.read(size)
  File "/usr/lib/python3.7/codecs.py", line 504, in read
newchars, decodedbytes = self.decode(data, self.errors)
UnicodeDecodeError: 'utf-8' codec can't decode byte 0x8b in position 1: 
invalid start byte

This happens because dodgy expects compressed files to be application/*, but 
mimetypes reports them as text/*.

To fix this, dodgy can be extended to check the encoding property and
then use different open/gzopen/lzmaopen calls depending on what kind
of compression is used.



I think dodgy's assumption of UTF-8 will also produce crashes and false 
negatives if UTF-16 is used for Windows/Java compatibility reasons.
However I was not able to produce a trivial example.



You may also want to switch from mimetypes to python3-magic, which uses 
libmagic1 (i.e. file(1)).
This will make guess the MIME type based on the file's *CONTENTS*, rather than 
just the file's *NAME*.



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

Kernel: Linux 4.19.0-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_AU.utf8, LC_CTYPE=en_AU.utf8 (charmap=UTF-8), LANGUAGE=en_AU:en 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages dodgy depends on:
ii  python3  3.7.1-3

dodgy recommends no packages.

dodgy suggests no packages.

-- no debconf information

Bug#918755: deborphan: guess-python suggests removing python3-cffi-backend despite being needed by certbot

[Matthew Gabeler-Lee]

Package: deborphan
Version: 1.7.30
Severity: normal

I have certbot explicitly installed, which depends on python3-certbot, on
python3-cryptography, which depends on (virtual?) packages
python3-cffi-backend-api-min (<= 9729),
python3-cffi-backend-api-max (>= 9729).

Runing deborpha --guess-python suggests uninstalling python3-cffi-backend,
which would force certbot to be removed, which is clearly not desirable.

I'm guessing from context that this is a problem with virtual packages like
this?

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

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

Versions of packages deborphan depends on:
ii  libc6  2.28-2

Versions of packages deborphan recommends:
ii  apt   1.8.0~alpha3
ii  dialog1.3-20181022-1
ii  gettext-base  0.19.8.1-9

deborphan suggests no packages.

-- no debconf information

Bug#917850: Fwd: Server Error (500) on nm.d.o

[eamanu15]

Hi!

El sáb., 5 de ene. de 2019 a la(s) 05:56, Jonathan McDowell (
nood...@earth.li) escribió:

> On Fri, Jan 04, 2019 at 11:12:24PM -0300, eamanu15 wrote:
> > > > I am trying to update my keyring using: *gpg --keyserver
> > > > keyring.debian.org  --send-keys ...*
> > > > But I don't see the change. On Debian wiki say that this could
> > > > take some time, because the keyring push is monthly. Do you know
> > > > approx when it occur? Or, there are other way to update the key?
> > >
> > > keyring.debian.org is only for keys that are already part of the
> > > Debian keyring, not for new applicants. Your key will be accepted
> > > and silently discarded there. You should send your updated key to
> > > the keyserver network (nm.debian.org is currently using
> > > keys.gnupg.net I believe, which is a pointer to the SKS keyserver
> > > network).
> > >
> > Hmmm I've just upload my keyring to keys.gnupg.net.
> >  Currently If I run --recv-key this is ok. But
> > on nm.debian.org still give me the same error :(
>
> You have renewed the certificate/signing part of your key, but the
> encryption key is still expired. The challenge is encrypted, so there is
> still no usable part of your key for this step:
>
> $ gpg -v --list-key 630362FCC33595B4CA3BCFB1D85007169B2B9F26
> pub   rsa4096 2017-11-03 [SC] [expires: 2028-10-07]
>   6303 62FC C335 95B4 CA3B  CFB1 D850 0716 9B2B 9F26
> uid   [ unknown] Emmanuel Arias (eamanu ) <
> emmanuelaria...@gmail.com>
> sub   rsa4096 2017-11-03 [E] [expired: 2018-11-03]
>

Currently, I update the expired time and upload it to
keys.gnupg.net and nothing.

eamanu@debianPC:~$ gpg -v --list-key
630362FCC33595B4CA3BCFB1D85007169B2B9F26
gpg: using pgp trust model
pub   rsa4096 2017-11-03 [SC] [expires: 2028-10-07]
  630362FCC33595B4CA3BCFB1D85007169B2B9F26
uid   [ultimate] Emmanuel Arias (eamanu ) <
emmanuelaria...@gmail.com>
sub   rsa4096 2017-11-03 [E] [expires: 2028-01-07]

I think that I have to revoke the key and create a new :-(

Regards!


> J.
>
> --
> ] https://www.earth.li/~noodles/ []   If I follow you home, will you   [
> ]  PGP/GPG Key @ the.earth.li[]  keep me?  [
> ] via keyserver, web or email.   [][
> ] RSA: 4096/0x94FA372B2DA8B985   [][
>


-- 
Arias Emmanuel
http://eamanu.com
Github/Gitlab; @eamanu
Debian: @eamanu-guest

Bug#918754: bash: $PATH in bash does not include /sbin and /usr/sbin

[Raju Devidas]

Package: bash
Version: 4.4.18-3.1
Severity: important

Dear Maintainer,

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

   * What led up to the situation?
   On a fresh installation of Debian testing/buster, used the Debian Testing
net install CD.
   Installed the MATE desktop from the selection menu in the installer to
install MATE desktop
   Was trying to install Wi-Fi drivers for my laptop. After installing the
drivers, I was trying
   reinsert the iwlwifi kernel module using modprobe.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   root@sanganak:~# adduser rajudev sudo
   bash: adduser: command not found
   root@sanganak:~# reboot
   bash: reboot: command not found
   root@sanganak:~# modprobe -r iwlwifi
   bash: modprobe: command not found
   root@sanganak:~#

   * What was the outcome of this action?
apparently the above commands were not there in there relative PATH's by
default

root@sanganak:~# echo $PATH
/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games


   * What outcome did you expect instead?
   Since this was a fresh install of Debian Testing/Buster, the PATH should
have contained
   the paths for /sbin or /usr/sbin etc. by default.



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

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

Versions of packages bash depends on:
ii  base-files   10.1
ii  debianutils  4.8.6
ii  libc62.28-2
ii  libtinfo66.1+20181013-1

Versions of packages bash recommends:
ii  bash-completion  1:2.8-5

Versions of packages bash suggests:
pn  bash-doc  

-- no debconf information

Bug#918753: xscreensaver: xdg desktop files miss many items from debian menu file

[Matthew Gabeler-Lee]

Package: xscreensaver
Version: 5.40-1
Severity: normal

I noticed on an upgrade that I lost (in wmaker) many menu items related to
xscreensaver.  On investigation this is because these menu items are only
provided in xscreensaver in the legacy Debian menu system and not in the
modern xdg / freedesktop .desktop files, which is all that many things
support these days.

Of particular note to me personally was the menu item to lock the screen
immediately, which was very useful.

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

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

Versions of packages xscreensaver depends on:
ii  libatk1.0-0  2.30.0-2
ii  libc62.28-2
ii  libcairo21.16.0-2
ii  libfontconfig1   2.13.1-2
ii  libfreetype6 2.9.1-3
ii  libgdk-pixbuf2.0-0   2.38.0+dfsg-7
ii  libglade2-0  1:2.6.4-2+b1
ii  libglib2.0-0 2.58.2-3
ii  libgtk2.0-0  2.24.32-3
ii  libice6  2:1.0.9-2
ii  libpam0g 1.1.8-3.8
ii  libpango-1.0-0   1.42.4-6
ii  libpangocairo-1.0-0  1.42.4-6
ii  libpangoft2-1.0-01.42.4-6
ii  libsm6   2:1.2.2-1+b3
ii  libx11-6 2:1.6.7-1
ii  libxext6 2:1.3.3-1+b2
ii  libxi6   2:1.7.9-1
ii  libxinerama1 2:1.1.4-1
ii  libxml2  2.9.4+dfsg1-7+b3
ii  libxmu6  2:1.1.2-2
ii  libxrandr2   2:1.5.1-1
ii  libxrender1  1:0.9.10-1
ii  libxt6   1:1.1.5-1
ii  libxxf86vm1  1:1.1.4-1+b2
ii  xscreensaver-data5.40-1

Versions of packages xscreensaver recommends:
ii  libjpeg-turbo-progs 1:1.5.2-2+b1
ii  perl5.28.1-3
ii  wamerican [wordlist]2018.04.16-1
ii  wamerican-large [wordlist]  2018.04.16-1

Versions of packages xscreensaver suggests:
ii  elinks [www-browser]0.12~pre6-14
ii  firefox [www-browser]   64.0-1
pn  fortune 
pn  gdm3 | kdm-gdmcompat
ii  google-chrome-stable [www-browser]  71.0.3578.98-1
ii  links [www-browser] 2.17-1
ii  lynx [www-browser]  2.8.9rel.1-2
pn  qcam | streamer 
ii  w3m [www-browser]   0.5.3-36+b1
pn  xdaliclock  
pn  xfishtank   
pn  xscreensaver-data-extra 
ii  xscreensaver-gl 5.40-1
pn  xscreensaver-gl-extra   

-- no debconf information

Bug#918752: bbswitch-source fails to build with m-a due to undefined dh compat

[David Kalnischkies]

Package: bbswitch-source
Version: 0.8-6
Severity: important

Hi,

with the switch to debhelper compat level 11 the debian/compat file was
removed in favor of using debhelper-compat (= 11) in the control file.

This breaks building with module-assistent as the debian/control.modules.in
file wasn't changed as well and so debhelper has no idea in which compat
mode it should be running and hence bails out failing the build.

Would be nice if you could adapt that file to say:
Build-Depends: debhelper-compat (= 9)

Changing the other fields like Vcs-*, Priority and co is probably in
order, too, but I don't want to ask for too much given that I might be
the only user…
I can do a proper patch/MR on salsa if that is preferred, it just felt
like overkill for the time being [in my timezone at least]. :)


Best regards

David Kalnischkies


signature.asc
Description: PGP signature

Bug#877002: nslcd installation broken: missing ca-certificates.crt

[Sunil Mohan Adapa]

severity 877002 important
tags 877002 + patch
thanks

This bug is causing issues with autopkgtests for FreedomBox package.
Bumping severity as simple install on a minimal machine fails.

On Wed, 27 Sep 2017 17:32:22 +0200 (CEST) Robert Wolf wrote:
[...]
> 
> 
> Either must nslcd depends on ca-certificates or nslcd.conf should not contain 
> configuration:

It seems reasonable to add ca-certificates as dependency as the initial
configuration for nslcd uses the certificates from the package.

The attached patch adds ca-certificates as dependency. I have tested
that bug is indeed resolved after building nslcd package with change in
dependency.

Please consider uploading a fix for the issue.

Thanks,

-- 
Sunil
From e813e8c1a9c5e1653b7dc88eaf59f2e6b0c2e8c6 Mon Sep 17 00:00:00 2001
From: Sunil Mohan Adapa 
Date: Tue, 8 Jan 2019 16:45:47 -0800
Subject: [PATCH] Change ca-certificates as dependency

Change ca-certificates as dependency instead of recommends since initial
configuration uses certificates.

Closes #877002.

Signed-off-by: Sunil Mohan Adapa 
---
 debian/changelog | 5 +
 debian/control   | 5 +++--
 2 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/debian/changelog b/debian/changelog
index 7d551c7..94025e7 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,7 +1,12 @@
 nss-pam-ldapd (0.9.10-2) UNRELEASED; urgency=medium
 
+  [ Arthur de Jong ]
   * Fix crash in chsh.ldap (closes: 908319)
 
+  [ Sunil Mohan Adapa ]
+  * Change ca-certificates as dependency instead of recommends since
+initial configuration uses certificates (closes: #877002).
+
  -- Arthur de Jong   Sat, 08 Sep 2018 17:43:56 +0200
 
 nss-pam-ldapd (0.9.10-1) unstable; urgency=medium
diff --git a/debian/control b/debian/control
index 76734d7..3abef55 100644
--- a/debian/control
+++ b/debian/control
@@ -16,8 +16,9 @@ Architecture: any
 Multi-Arch: foreign
 Provides: nslcd-2
 Pre-Depends: ${misc:Pre-Depends}, debconf (>= 0.5) | debconf-2.0
-Depends: ${misc:Depends}, ${shlibs:Depends}, adduser, lsb-base (>= 3.0-6)
-Recommends: nscd, ca-certificates,
+Depends: ${misc:Depends}, ${shlibs:Depends}, adduser, lsb-base (>= 3.0-6),
+ ca-certificates
+Recommends: nscd,
 libnss-ldapd | libnss-ldap,
 libpam-ldapd | libpam-ldap | libpam-krb5 | libpam-heimdal | libpam-sss,
 nslcd-utils, ldap-utils, bind9-host | host
-- 
2.20.1



signature.asc
Description: OpenPGP digital signature

Bug#918751: python-shade: FTBFS in sid

[Santiago Vila]

I said:

> I tried to build this package in buster but it failed:
Sorry for this typo, I meant sid of course.

Bug#905581: lists.debian.org: Request for new mailing list: debian-salsa-ci

[Agustin Henze]

Hi Alex,

On Wed, 2 Jan 2019 19:17:24 +0100 Alexander Wirt 
wrote:
> On Wed, 02 Jan 2019, Agustin Henze wrote:
> 
> > Hi formorer, I really appreciate your opinion but we still needing the
> > mailing list.
> Let me rephrase. I don't think that any other listmaster will create that
> list. 
> 

Mmm ok, I think the process is completely unclear then... You have the
requirements written and I think the request followed them.

Could you explain me please how do you decide not creating the mailing
list. What is the criteria? What area the objective reasons to decline
the request?

In that way, we can decide what to do... If we ask a mailing list on
riseup or try to fill the requirements because we really need it,
otherwise I wouldn't be spending time here...

Thanks,

--
TiN

Bug#918751: python-shade: FTBFS in sid

[Santiago Vila]

Package: src:python-shade
Version: 1.30.0-1
Severity: serious
Tags: ftbfs

Dear maintainer:

I tried to build this package in buster but it failed:


[...]
 debian/rules build-indep
dh build-indep --with python2 --with python3 --buildsystem=pybuild
   dh_update_autotools_config -i -O--buildsystem=pybuild
   dh_auto_configure -i -O--buildsystem=pybuild
I: pybuild base:217: python2.7 setup.py config 
running config
I: pybuild base:217: python3.7 setup.py config 
running config
   dh_auto_build -i -O--buildsystem=pybuild
I: pybuild base:217: /usr/bin/python setup.py build 
running build
running build_py
creating /<>/.pybuild/cpython2_2.7_shade/build/shade
creating /<>/.pybuild/cpython2_2.7_shade/build/shade/tests

[... snipped ...]

b'"id": "v2.0",'
b'"links": ['
b'  {'
b'"href": "https://identity.example.com/v2.0/;,'
b'"rel": "self"'
b'  },'
b'  {'
b'"href": "http://docs.openstack.org/;,'
b'"type": "text/html",'
b'"rel": "describedby"'
b'  }'
b']'
b'  }'
b']'
b'  }'
b'}'
b''
b'2019-01-09 00:07:23,806 shade.task_manager   Manager 
_test_cloud_:RegionOne ran task 
object-store.PUT.shade.tests.unit.test_object.TestObjectUploads.test_object_segment_retry_failure-2.02
 in 0.966373920441s'
b'2019-01-09 00:07:23,826 keystoneauth.identity.v3.baseMaking 
authentication request to https://identity.example.com/v3/auth/tokens'
b'2019-01-09 00:07:23,943 keystoneauth.identity.v3.base{"token": 
{"methods": ["password"], "roles": [{"id": "9fe2ff9ee4384b1894a90878d3e92bab", 
"name": "_member_"}, {"id": "37071fc082e14c2284c32a2761f71c63", "name": 
"swiftoperator"}], "expires_at": "-12-31T23:59:59Z", "project": {"domain": 
{"id": "default", "name": "default"}, "id": "1c36b64c840a42cd9e9b931a369337f0", 
"name": "Default Project"}, "catalog": [{"endpoints": [{"interface": "public", 
"url": "https://compute.example.com/v2.1/;, "region": "RegionOne", "id": 
"32466f357f3545248c47471ca51b0d3a"}], "type": "compute", "name": "nova"}, 
{"endpoints": [{"interface": "public", "url": 
"https://volume.example.com/v2/1c36b64c840a42cd9e9b931a369337f0;, "region": 
"RegionOne", "id": "1e875ca2225b408bbf3520a1b8e1a537"}], "type": "volumev2", 
"name": "cinderv2"}, {"endpoints": [{"interface": "public", "url": 
"https://image.example.com;, "region": "RegionOne", "id": 
"5a64de3c4a614d8d8f8d1ba3dee5f45f"}], "type": "image", "name": "g
 lance"}, {"endpoints": [{"interface": "public", "url": 
"https://volume.example.com/v1/1c36b64c840a42cd9e9b931a369337f0;, "region": 
"RegionOne", "id": "3d15fdfc7d424f3c8923324417e1a3d1"}], "type": "volume", 
"name": "cinder"}, {"endpoints_links": [], "endpoints": [{"interface": 
"public", "url": "https://identity.example.com;, "region": "RegionOne", "id": 
"4deb4d0504a044a395d4480741ba628c"}, {"interface": "admin", "url": 
"https://identity.example.com;, "region": "RegionOne", "id": 
"012322eeedcd459edabb4933021112bc"}], "type": "identity", "name": "keystone"}, 
{"endpoints_links": [], "endpoints": [{"interface": "public", "url": 
"https://network.example.com;, "region": "RegionOne", "id": 
"4deb4d0504a044a395d4480741ba628d"}], "type": "network", "name": "neutron"}, 
{"endpoints_links": [], "endpoints": [{"interface": "public", "url": 
"https://container-infra.example.com/v1;, "region": "RegionOne", "id": 
"4deb4d0504a044a395d4480741ba628e"}], "type": "container-infra", "name": 
"magnum"}, {"end
 points_links": [], "endpoints": [{"interface": "public", "url": 
"https://object-store.example.com/v1/1c36b64c840a42cd9e9b931a369337f0;, 
"region": "RegionOne", "id": "4deb4d0504a044a395d4480741ba628c"}], "type": 
"object-store", "name": "swift"}, {"endpoints_links": [], "endpoints": 
[{"interface": "public", "url": "https://bare-metal.example.com/;, "region": 
"RegionOne", "id": "652f0612744042bfbb8a8bb2c777a16d"}], "type": "baremetal", 
"name": "ironic"}, {"endpoints_links": [], "endpoints": [{"interface": 
"public", "url": 
"https://orchestration.example.com/v1/1c36b64c840a42cd9e9b931a369337f0;, 
"region": "RegionOne", "id": "4deb4d0504a044a395d4480741ba628c"}], "type": 
"orchestration", "name": "heat"}, {"endpoints_links": [], "endpoints": 
[{"interface": "public", "url": "https://dns.example.com;, "region": 
"RegionOne", "id": "10c76ffd2b744a67950ed1365190d352"}], "type": "dns", "name": 
"designate"}], "user": {"domain": {"id": "default", "name": "default"}, "id": 
"c17534835f8f42bf98fc367e0
 bf35e09", "name": "mordred"}, "audit_ids": ["Rvn7eHkiSeOwucBIPaKdYA"], 
"issued_at": "2016-12-17T14:25:05.00Z"}}'
b'2019-01-09 00:07:24,016 shade.task_manager   Manager 
defaults: running task baremetal.GET.nodes'
b'2019-01-09 00:07:24,063 keystoneauth.session REQ: curl -g -i 
-X GET 

Bug#918700: grub2-common: update-grub fails with bogus error messages if it doesn't like the current dir

[Colin Watson]

On Wed, Jan 09, 2019 at 10:43:42AM +1100, Russell Coker wrote:
> It would probably be easier to just canonicalise all path names given
> on the command line and then cd / before starting work. Apart from the
> possibility of a relative pathname on the command line there's no
> benefit in restoring the directory.

I'm pretty sure it will in fact be easier to use save-cwd from Gnulib,
and I'm already working on patches in that direction.  (The only real
obstacle is that GRUB's use of Gnulib is currently a bit of a mess, so
I'm working on cleaning that up first.)  Of course you're free to submit
a patch upstream implementing your preferred approach, but this is mine.

-- 
Colin Watson   [cjwat...@debian.org]

Bug#918750: transition: simbody

[Jose Luis Rivero]

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

Dear release team:

simbody 3.6.1+dfsg-1 is now in experimental, we can start the transition
for the existing package in the archive currently using it.
The following source package need to be rebuild:

gazebo 9.6.0-1

I think that in terms of 'ben' lingo, the transition has the following
parameters:

Affected: .depends ~ 
/\b(libsimbody3\.6|libsimbody3\.5v5|libsimbody3\.5v5\-dbg)\b/
Good: .depends ~ /\b(libsimbody3\.6)\b/
Bad: .depends ~ /\b(libsimbody3\.5v5|libsimbody3\.5v5\-dbg)\b/

Sorry for sending this close to the freeze but it will kill the 2 RC bugs 
pending on Simbody.
Please schedule binNMUs for gazebo packages on all architectures.

Thanks.

Bug#918655: msmtp: Apparmor causing Permission denied when creating tmp files and logging

[Simon Deziel]

Hi,

On 2019-01-08 5:03 p.m., Emmanuel Bouthenot wrote:
> On Mon, Jan 07, 2019 at 08:35:25PM -0500, Simon Deziel wrote:
> [...]
> 
>> I agree, I should have thought of that. How about adding the text from
>> README.Debian as a NEWS entry?
>>
>> I will do some testing with 1.8.1-1 but in the meantime, please find
>> attached a more up to date profile that received more testing and also
>> incorporates your feedback (thanks!).
> 
> Thanks (to you and Ondra) for your feedback.
> 
> I've just uploaded msmtp 1.8.1-2 with your patch and a notice in
> debian/NEWS

Your fast turnaround is much appreciated, thanks!

Regards,
Simon

Bug#887399: stretch-pu: package python-certbot/0.10.2-1

[Harlan Lieberman-Berg]

Hello Julien, everyone,

I've uploaded the relevant packages for your examination.  The
packages uploaded are:

- python-acme_0.28.0-1+deb9u1
- python-certbot_0.28.0-1+deb9u1
- python-certbot-nginx_0.28.0-1+deb9u1
- python-certbot-apache_0.28.0-1+deb9u1
- python-josepy_1.1.0-2+deb9u1
- parsedatetime_2.1-3+deb9u1

On Sun, Dec 2, 2018 at 7:55 PM Harlan Lieberman-Berg
 wrote:
>
> On Sun, Dec 2, 2018 at 10:48 AM Julien Cristau  wrote:
> > OK, let's do that then.  Sorry for not getting back to this sooner.
>
> Sounds good.  I'm preparing the uploads now.
>
> It looks like I will need to rebuild the version of
> python-parsedatetime in stable to also build the python3 version.  I
> could also backport a newer version that builds python3.  Let me know.
>
> Sincerely,
> --
> Harlan Lieberman-Berg
> ~hlieberman



-- 
Harlan Lieberman-Berg
~hlieberman

Bug#821397: ITP: sway -- i3-compatible Wayland compositor

[Martin Michlmayr]

* Michele Cane  [2018-12-14 19:32]:
> Thanks for the work already done to bring this package to debian.
> 
> Any update of a possible upload of b2 to experimental?

Yes, please.

Any update on this?  Birger?  nicoo?

-- 
Martin Michlmayr
https://www.cyrius.com/

Bug#918700: grub2-common: update-grub fails with bogus error messages if it doesn't like the current dir

[Russell Coker]

It would probably be easier to just canonicalise all path names given on the 
command line and then cd / before starting work. Apart from the possibility of 
a relative pathname on the command line there's no benefit in restoring the 
directory.
-- 
Sent from my Huawei Mate 9 with K-9 Mail.

Bug#909497: CUDA 10 available now

[Andreas Beckmann]

On 2018-12-12 15:48, Graham Inggs wrote:
> On 2018/12/11 21:51, Andreas Beckmann wrote:
>> Which packages
>> * can be binNMUed (manually by me or another DD, not by the release team)
>> * need sourceful uploads
>> * should get sourceful uploads to change ... and ...
>> ?
> 
> eztrace-contrib, hwloc-contrib and starpu-contrib all built with no
> changes required, so I guess can be binNMU'd.
> 
> pycuda built with the patch from #914804 (already in git)
> 
> caffe-contrib and lua-torch-cutorch failed to build, but I think for
> reasons unrelated to the CUDA transition.
> 
>> I think there is not much point opening a transition bug since this will
>> be completely at our hands ...

Let the fun start. I just uploaded 9.2 to sid :-)
Note that you'll need the drivers from experimental ... I've relaxed the
dependencies a bit to allow installation in sid regardless of the driver
version. This will be undone once the 410 driver is there, but I first
want to do the driver transition to 390 in stretch.

I'll do binNMUs tomorrow (but I'll wait for pycuda to migrate to testing
first).

Andreas

Bug#918749: libtss2-dev: missing Depends: libgcrypt20-dev, pkg-config --libs tss2-esys lists -lgcrypt

[Mike Miller]

Package: libtss2-dev
Version: 2.1.0-2
Severity: normal

Dear Maintainer,

Installing libtss2-dev and running pkg-config --libs tss2-esys produces

-ltss2-esys -lgcrypt -ltss2-sys -ltss2-mu

The package should therefore declare Depends: libgcrypt20-dev so that
the "-lgcrypt" part of this is satisfied.

Thanks!


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

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

Versions of packages libtss2-dev depends on:
ii  libtss2-esys0  2.1.0-2

libtss2-dev recommends no packages.

libtss2-dev suggests no packages.

-- no debconf information

Bug#874025: [debian-mysql] Bug#874025: garbd does not start

[Otto Kekäläinen]

Control: tag -1 wontfix

To get any progress with this issue, please collaborate with upstream.
Consider for example paying them to fix their issue #313.

> Forwarded: https://github.com/codership/galera/issues/313
>
> Hello!
>
> This looks like a duplicate of upstream bug
> https://github.com/codership/galera/issues/313
>
> This is not something we should fix on packaging level in Debian.
> Please contribute upstream to get this fixed once and for all.

Bug#918748: nmu: kadu_4.1-1.1

[Boris Pek]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu
X-Debbugs-CC: sha...@debian.org

Package with qxmpp library was updated today and is successfully built for all
supported architectures: https://buildd.debian.org/status/package.php?p=qxmpp
Please schedule the binNMUs for rebuilding of kadu packages with qxmpp/1.0.0-1.

  nmu kadu_4.1-1.1 . ANY . buster . -m "rebuild after update of qxmpp"

This is my first binNMUs, so please correct me if I am doing anything wrong.

Thanks,
Boris

Bug#881034: Galera-3 default configuration; nodes beyond primary will not connect

[Otto Kekäläinen]

Control: tag -1 wontfix

To get any progress with this issue, please collaborate with upstream.

>
> Hello!
>
> I can see in the logs:
>
> 2017-11-06 17:10:13 139930521723456 [Warning] WSREP: access
> file(/var/lib/mysql//gvwstate.dat) failed(No such file or directory)
>
> This issue might ultimately be related to
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=874025
> or upstream
> https://github.com/codership/galera/issues/313
>
> I don't think this is related to the Debian packaging in any way. You
> hypothesis of issues with systemd script are not supported by any
> evidence. You workaround does not sound like something that would be
> recommended to do, and I don't understand why killing the original
> process even can help, interesting.
>
> I suggest you seek support from the upstream mailing list or buy
> support from Codership, the company behind Galera.

Bug#918747: octave-splines: FTBFS randomly

[Santiago Vila]

Package: src:octave-splines
Version: 1.3.2-4
Severity: important
Tags: ftbfs

Dear maintainer:

I tried to build this package in buster but it failed:


[...]
 debian/rules binary-indep
dh binary-indep --buildsystem=octave --with=octave
   dh_update_autotools_config -i -O--buildsystem=octave
   dh_autoreconf -i -O--buildsystem=octave
   dh_octave_version -i -O--buildsystem=octave
Checking the Octave version... ok
   dh_auto_configure -i -O--buildsystem=octave
   dh_auto_build -i -O--buildsystem=octave
   dh_auto_test -i -O--buildsystem=octave
   create-stamp debian/debhelper-build-stamp
   dh_testroot -i -O--buildsystem=octave
   dh_prep -i -O--buildsystem=octave
   dh_auto_install -i -O--buildsystem=octave
octave --no-gui --no-history --silent --no-init-file --no-window-system 
/usr/share/dh-octave/install-pkg.m
warning: pkg: creating the directory 
/<>/debian/octave-splines/usr/share/octave/packages
warning: pkg: creating the directory 
/<>/debian/octave-splines/usr/lib/x86_64-linux-gnu/octave/packages
For information about changes from previous versions of the splines package, 
run 'news splines'.
   dh_octave_check -i -O--buildsystem=octave
Checking package...
Checking m files ...
[inst/csaps.m]
> /<>/inst/csaps.m
* shared x,y,xi,yi,p,sigma2,unc_yi,df
 x = ([1:10 10.5 11.3])'; y = sin(x); xi = linspace(min(x), max(x), 30)';
* assert (csaps(x,y,1,x), y, 10*eps);
* assert (csaps(x,y,1,x'), y', 10*eps);
* assert (csaps(x',y',1,x'), y', 10*eps);
* assert (csaps(x',y',1,x), y, 10*eps);
* assert (csaps(x,[y 2*y],1,x)', [y 2*y], 10*eps);
 [yi,p,sigma2,unc_yi,df] = csaps(x,y,1,xi);
* assert (yi, ppval(csape(x, y, "variational"), xi), eps);
* assert (p, 1);
* assert (unc_yi, zeros(size(xi)));
* assert (sigma2, 0);
* assert (df, numel(x));
 [yi,p,~,~,df] = csaps(x,y,0,xi);
* assert (yi, polyval(polyfit(x, y, 1), xi), 10*eps);
* assert (p, 0);
* assert (df, 2, 100*eps);
13 tests, 13 passed, 0 known failure, 0 skipped
[inst/csaps_sel.m]
> /<>/inst/csaps_sel.m
* shared x,y,ret,p,sigma2,unc_y
 x = [0:0.01:1]'; y = sin(x);
 [ret,p,sigma2,unc_y] = csaps_sel(x,y,x);
* assert (1 - p, 0, 1E-6);
* assert (sigma2, 0, 1E-10);
* assert (ret - y, zeros(size(y)), 1E-4);
* assert (ret, (csaps_sel(x,[y 2*y],x))'(:, 1), 1E-4);
* assert (unc_y, zeros(size(unc_y)), 1E-5);
5 tests, 5 passed, 0 known failure, 0 skipped
[inst/dedup.m]
> /<>/inst/dedup.m
* shared x, y, w
 x = [1; 2; 2; 3; 4];
 y = [0 0; 1 1; 2 1; 3 4; 5 NaN];
 w = [1; 0.1; 1; 0.5; 1];
* assert (nthargout(1:3, @dedup, x, y, ones(size(x))), nthargout(1:3, 
@dedup, x, y))
 [x y w] = dedup(x, y, w);
* assert (x, [1; 2; 3]);
* assert (y, [0 0; 21/11 1; 3 4], 10*eps);
* assert (w, [1; 1.1; 0.5]);
4 tests, 4 passed, 0 known failure, 0 skipped
[inst/bin_values.m]
> /<>/inst/bin_values.m
* shared x, y, x_bin, y_bin, w_bin, n_bin
 x = [1; 2; 2; 3; 4];
 y = [0 0; 1 1; 2 1; 3 4; 5 NaN];
 [x_bin y_bin w_bin n_bin] = bin_values(x, y);
* assert (x_bin, [1; 7/3]);
* assert (y_bin, [0 0; 2 2]);
* assert (!any(isfinite(w_bin(1, :;
* assert (w_bin(2, :), [3 1]);
* assert (n_bin, [1; 3]);
5 tests, 5 passed, 0 known failure, 0 skipped
[inst/tpaps.m]
> /<>/inst/tpaps.m
* shared x,y
 x = ([1:10 10.5 11.3])'; y = sin(x);
* assert (tpaps(x,y,1,x), y, 1E3*eps);
 x = rand(100, 2)*2 - 1; 
 y = x(:, 1) .^ 2 + x(:, 2) .^ 2;
* assert (tpaps(x,y,1,x), y, 1E-10);
2 tests, 2 passed, 0 known failure, 0 skipped
[inst/tps_val_der.m]
> /<>/inst/tps_val_der.m
* shared a,b,x,y,x1,x2,y1,c,dy,dy0
 a = 2; b = -3; x = ([1:2:10 10.5 11.3])'; y = a*x;
 c = tpaps(x,y,1);
* assert (a*ones(size(x)), tps_val_der(x,c,x), 1E3*eps);
 [x1 x2] = meshgrid(x, x);
 y1 = a*x1+b*x2;
 c = tpaps([x1(:) x2(:)],y1(:),0.5);
 dy = tps_val_der([x1(:) x2(:)],c,[x1(:) x2(:)]);
 dy0 = tps_val_der([x1(:) x2(:)],c,[x1(:) x2(:)],false);
* assert (a*ones(size(x1(:))), dy(:, 1), 1E3*eps);
* assert (b*ones(size(x2(:))), dy(:, 2), 1E3*eps); 
* assert (dy0, dy, 1E3*eps);
4 tests, 4 passed, 0 known failure, 0 skipped
[inst/csape.m]
> /<>/inst/csape.m
* shared x,x2,y,cond,pp,h,valc
 x = linspace(0,2*pi,5); y = sin(x); x2 = linspace(0,2*pi,16);
* assert (ppval(csape(x,y),x), y, 10*eps);
* assert (ppval(csape(x,y),x'), y', 10*eps);
* assert (ppval(csape(x',y'),x'), y', 10*eps);
* assert (ppval(csape(x',y'),x), y, 10*eps);
* assert (ppval(csape(x,[y;y]),x), ...
[ppval(csape(x,y),x);ppval(csape(x,y),x)], 10*eps)
* assert (ppval(csape(x,[y;y]),x2),  ...
[ppval(csape(x,y),x2);ppval(csape(x,y),x2)], 10*eps)
* test cond='complete';
* assert (ppval(csape(x,y,cond),x), y, 10*eps);
* assert (ppval(csape(x,y,cond),x'), y', 10*eps);
* assert (ppval(csape(x',y',cond),x'), y', 10*eps);
* assert (ppval(csape(x',y',cond),x), y, 

Bug#918746: Should this package be removed?

[Moritz Muehlenhoff]

Source: pam-ssh-agent-auth
Severity: serious

Should pam-ssh-agent-auth be removed from the archive?

It seems dead upstream, the last commits are from March 2014, it's broken
with OpenSSL 1.1 and was removed from testing more than a year ago. It's
also one of the few remaining packages blocking the removal of OpenSSL 1.0.

Cheers,
Moritz
  

Bug#915804: Should this package be removed?

[Moritz Mühlenhoff]

On Wed, Dec 19, 2018 at 11:56:47PM +0100, Sebastian Andrzej Siewior wrote:
> On 2018-12-06 22:52:32 [+0100], Moritz Muehlenhoff wrote:
> > Source: cfengine2
> > Severity: serious
> > 
> > This is replaced by src:cfengine2 and stretch has both cfengine2 and 
> > cfengine3,
> > so users can migrate within a stable release to 3.
> > 
> > The current version is also RC-buggy for a long time and blocks the removal
> > of OpenSSL 1.0.
> 
> cfengine2 is like a decade old. I found nothing in their blog. Only the
> convert tool:
>   https://cfengine.com/company/blog-detail/cfengine-2-conversion-tool/

No objections to my bug for a month, so I went ahead and filed a removal
bug.

Cheers,
Moritz

Bug#918745: RM: cfengine2 -- RoQA; Obsolete, RC-buggy, unmaintained

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Please remove cfengine2. It's RC-buggy and the 2.2.10 upstream release
was uploaded almost a decade ago and one of the few remaining packages
blocking the removal of OpenSSL 1.0. The package hasn't been uploaded
for two years.

Stretch have both cfengine2 and cfengine3, so users can migrate within
a stable release to cfengine3.

Cheers,
Moritz

Bug#918744: stretch-pu: package opensc/0.1.9-1~deb9u1

[Hilko Bengen]

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

Dear release team,

I'd like to update opensc in stretch to 0.1.9-1~deb9u1 in order to fix a
regression that introduced with the last update, 0.1.6-3+deb9u1, in an
attempt to fix security issues (see #910786 for details).

I am aware that this is by no means a minimal change. I have tried to
fix the backported patch that broke Yubikey NEO support for me, but I
have not been able to restore functionality without reverting the patch
that fixed a CVE-worthy buffer overflow.

Because I own no other smartcard hardware, I cannot tell if the other
patches that were introduced with 0.16.0-3+deb9u1 broke any other
hardware support.

The .debian.tar.xz is attached. Given the size of the effective change,
a debdiff does not seem to make a lot of sense. I have not done an
upload yet.

Cheers,
-Hilko


opensc_0.19.0-1~deb9u1.debian.tar.xz
Description: application/xz

Bug#918659: Debootstrap started to fail with Busybox

[Hideki Yamane]

control: tags -1 +patch

Hi,

On Tue, 8 Jan 2019 04:43:40 +0100
Piotr Jurkiewicz  wrote:
> Debootstrap started to fail with busybox since version 1.0.113. 

 I've created a merge request for that.
 https://salsa.debian.org/installer-team/debootstrap/merge_requests/24

 Hope someone in -boot would review it.


-- 
Regards,

 Hideki Yamane henrich @ debian.org/iijmio-mail.jp

Bug#917648: [Pkg-clamav-devel] Bug#917648: clamav-freshclam: doesn't properly clean up temporary files, consumes all disk

[Sebastian Andrzej Siewior]

On 2019-01-02 22:50:32 [+0100], To Witold Baryluk wrote:
> "dmesg" should give you the output you look for. Like "apparmor: denied
> $this because of $reason".

Could you please send me the dmesg output for your failure? I have an
up-to-date sid system here with enabled apparmor and I can't reproduce
the problem. All I see is:
| audit: type=1400 audit(1546987681.334:13): apparmor="DENIED" operation="open" 
profile="/usr/sbin/clamd" name="/etc/ssl/openssl.cnf" pid=2408 comm="clamd" 
requested_mask="r" denied_mask="r" fsuid=102 ouid=0
| audit: type=1400 audit(1546987714.594:14): apparmor="DENIED" operation="open" 
profile="/usr/bin/freshclam" name="/etc/ssl/openssl.cnf" pid=2454 
comm="freshclam" requested_mask="r" denied_mask="r" fsuid=0 ouid=0

and the logfile says:
|-> freshclam daemon 0.100.2 (OS: linux-gnu, ARCH: x86_64, CPU: x86_64)
|-> ClamAV update process started at Tue Jan  8 23:48:34 2019
|-> WARNING: Your ClamAV installation is OUTDATED!
|-> WARNING: Local version: 0.100.2 Recommended version: 0.101.1
|-> DON'T PANIC! Read https://www.clamav.net/documents/upgrading-clamav
|-> main.cld is up to date (version: 58, sigs: 4566249, f-level: 60, builder: 
sigmgr)
|-> nonblock_connect: connect(): fd=4 errno=101: Network is unreachable
|-> Can't connect to port 80 of host db.local.clamav.net (IP: 
2606:4700::6810:ba8a)
|-> Downloading daily-25281.cdiff [100%]
|-> daily.cld updated (version: 25281, sigs: 2202390, f-level: 63, builder: 
raynman)
|-> bytecode.cld is up to date (version: 328, sigs: 94, f-level: 63, builder: 
neo)
|-> Database updated (6768733 signatures) from db.local.clamav.net (IP: 
104.16.186.138)
|-> Clamd successfully notified about the update.

so it works…

Sebastian

Bug#881704: RM: ttf-marvosym -- ROM; abandoned upstream

[Moritz Mühlenhoff]

tags 881704 -moreinfo
thanks

On Thu, Dec 14, 2017 at 08:05:29PM -0500, Scott Kitterman wrote:
> On Tue, 14 Nov 2017 11:37:43 +0100 =?UTF-8?Q?G=C3=BCrkan_Myczko?= 
>  wrote:
> > Package: ftp.debian.org
> > Severity: normal
> > 
> > Please remove ttf-marvosym from the archive:
> >   * The removal closes: #820231
> >   * it hasn't been maintained upstream since about 2015
> > 
> > http://www.martinvogel.de/blog/index.php?/archives/131-Marvosym.ttf.html
> 
> Unfortunately there are rdepends that need to be fixed first:
> 
> Checking reverse dependencies...
> # Broken Depends:
> openscad: openscad-testing-data
> 
> # Broken Build-Depends:
> openscad: ttf-marvosym
> 
> Dependency problem found.
> 
> Please remove the moreinfo tag once that's been resolved.

openscad has been fixed.

Cheers,
Moritz

Bug#918743: php-fpm.conf: Shouldn't pass URLs for missing files to PHP-FPM

[Kevin Locke]

Package: php7.3-fpm
Version: 7.3.0-2
Severity: minor
Tags: patch

Dear Maintainer,

The current behavior of php-fpm.conf is to pass URLs for files which
match ".+\.ph(ar|p|tml)$" to PHP-FPM regardless of whether the file
exists.  This causes a few issues:

- It prevents Apache error handling (e.g. ErrorDocument).
- It adds unnecessary load to PHP-FPM.
- It adds unnecessary request overhead for the request.
- It causes "AH01071: Got error 'Primary script unknown'" to be logged
  to the Apache error log for each request.

This can be avoided by using an  directive around SetHandler, as
done on the PHP-FPM page on the Apache Wiki.[1]  I have attached a patch
which does this.

Thanks for considering,
Kevin

1.  https://wiki.apache.org/httpd/PHP-FPM


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

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

Versions of packages php7.3-fpm depends on:
ii  libapparmor12.13.2-3
ii  libargon2-1 0~20171227-0.1
ii  libc6   2.28-2
ii  libmagic1   1:5.34-2
ii  libpcre2-8-010.32-3
ii  libsodium23 1.0.16-2
ii  libssl1.1   1.1.1a-1
ii  libsystemd0 240-2
ii  libxml2 2.9.4+dfsg1-7+b3
ii  mime-support3.61
ii  php7.3-cli  7.3.0-2
ii  php7.3-common   7.3.0-2
ii  php7.3-json 7.3.0-2
ii  php7.3-opcache  7.3.0-2
ii  tzdata  2018i-1
ii  ucf 3.0038+nmu1
ii  zlib1g  1:1.2.11.dfsg-1

php7.3-fpm recommends no packages.

Versions of packages php7.3-fpm suggests:
ii  php-pear  1:1.10.6+submodules+notgz-1

Versions of packages php7.3-common depends on:
ii  libc6   2.28-2
ii  libssl1.1   1.1.1a-1
ii  php-common  2:69
ii  ucf 3.0038+nmu1

-- Configuration Files:
/etc/apache2/conf-available/php7.3-fpm.conf changed [not included]

-- no debconf information
>From 2d80e7bd564cce570b8725614e3b73ccd8b74a11 Mon Sep 17 00:00:00 2001
Message-Id: 
<2d80e7bd564cce570b8725614e3b73ccd8b74a11.1546987306.git.ke...@kevinlocke.name>
From: Kevin Locke 
Date: Tue, 8 Jan 2019 15:32:19 -0700
Subject: [PATCH] Don't pass URLs for missing files to PHP-FPM

When there is no file matching a request URL ending in a matched PHP
extension, passing it to PHP-FPM doesn't make sense.  It adds
unnecessary PHP-FPM load and request overhead, prevents Apache error
handling (e.g.  ErrorDocument), and causes `AH01071: Got error 'Primary
script unknown'` to be logged.

Avoid this by using an  directive to only configure SetHandler if
the requested file exists, as documented on [PHP-FPM] on the Apache
Wiki.

[PHP-FPM]: https://wiki.apache.org/httpd/PHP-FPM

Signed-off-by: Kevin Locke 
---
 debian/php-fpm.conf | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/debian/php-fpm.conf b/debian/php-fpm.conf
index 3fc2f80c0..1d78fbb48 100644
--- a/debian/php-fpm.conf
+++ b/debian/php-fpm.conf
@@ -7,7 +7,9 @@
 
 
 
-SetHandler 
"proxy:unix:/run/php/php@php_vers...@-fpm.sock|fcgi://localhost"
+
+SetHandler 
"proxy:unix:/run/php/php@php_vers...@-fpm.sock|fcgi://localhost"
+
 
 
 # Deny access to raw php sources by default
-- 
2.20.1

Bug#913674: Preparing p-u upload

[Hilko Bengen]

* Adam D. Barratt:

> Ah, I suspect there has been some confusion regarding the quoted text -
> "that" is "a fixed package", not "the package in unstable". The mention
> of unstable was a general reference to the workflow requirement for
> issues to be resolved in unstable first, not a specific suggestion to
> upload the unstable package to stable.

Ah, I see.

I think I stated my case about not being able to properly fix the patch
within the 0.16 codebase, so I'm going to open a p-u bug for
0.19.1~deb9u1.

Cheers,
-Hilko

Bug#918376: nsis 3.03-2: FTBFS, alignment problem

[Thomas Gaugler]

Thanks for your detailed bug report.

I tried to reproduce the bug via the Disco Dingo Ubuntu/arm64 cloud 
image running inside the QEMU emulator [1]. I did not succeed in 
triggering the bug with this setup.


I concluded from your debug output that the icon group boundary is not 
aligned to the nearest multiple of a double word.


The size of the icon group is calculated as the following:
   size_t group_size = sizeof(IconGroupHeader) // header
 + order.size() * SIZEOF_RSRC_ICON_GROUP_ENTRY; // entries

sizeof(IconGroupHeader) = 6
SIZEOF_RSRC_ICON_GROUP_ENTRY = 14

group_size is a multiple of a double word for uneven numbers of 
order.size() but not if order.size() is an even number.


For illustration group_size for the order.size() values of 1 and 2:
group_size = 6 + 1 * 14 = 20 (double word aligned)
group_size = 6 + 2 * 14 = 34 (not double word aligned)

Therefore I expect something like the attached patch 
(fix-icongroup-alignment.patch) would be necessary. I need to verify 
with the
Microsoft Portable Executable and Common Object File Format 
Specification [2] and upstream.


[1] https://wiki.ubuntu.com/ARM64/QEMU
[2] http://www.microsoft.com/whdc/system/platform/firmware/PECOFF.mspx
Align icon group boundary to the nearest multiple of a double word.
--- a/Source/icon.cpp
+++ b/Source/icon.cpp
@@ -341,8 +341,12 @@
   // calculate size
   size_t group_size = sizeof(IconGroupHeader) // header
 + order.size() * SIZEOF_RSRC_ICON_GROUP_ENTRY; // entries
+  size_t padding = group_size % sizeof(DWORD);
+  if (padding > 0) {
+padding = sizeof(DWORD) - padding;
+  }
 
-  data_size = group_size // group header
+  data_size = group_size + padding // group header
 + sizeof(DWORD) * 2 // offset and size of group header
 + (sizeof(DWORD) * 2) * icon2.size() // offset and size per entry
 + sizeof(DWORD); // terminator
@@ -358,13 +362,16 @@
   LPBYTE seeker = uninst_data;
 
   // fill group header
-  *(LPDWORD) seeker = FIX_ENDIAN_INT32((UINT32)group_size);
+  *(LPDWORD) seeker = FIX_ENDIAN_INT32((UINT32)(group_size + padding));
   seeker += sizeof(DWORD);
   *(LPDWORD) seeker = 0;
   seeker += sizeof(DWORD);
 
   memcpy(seeker, group, group_size);
   seeker += group_size;
+  for (;padding > 0; padding--) {
+*(seeker++) = '\0';
+  }
 
   // fill entries
   for (i = 0; i < icon2.size(); i++)

Bug#918742: Initialization loop/deadlock when used with jemalloc

[Faidon Liambotis]

Package: src:fakechroot
Version: 2.19-3
Severity: serious

Hi again,

So jemalloc 5.1.0-2 was recently uploaded to unstable. The build
currently fails due to the explicit dependency on libjemalloc1 (cf.
#918741), but as soon as this gets fixed, another issue is uncovered:

While building this package, the jemalloc test deadlocks, and the build
hangs. This can be easily reproduced as follows:
  apt install libfakechroot libjemalloc2
  LD_PRELOAD="libjemalloc.so.2 libfakechroot.so" /bin/true
  

The test isn't spurious but an actual issue. One could do:
  fakechroot 
...and still hit this bug.

The bug is effectively the same as #872669, which I had previously
resolved by disabling jemalloc's --enable-prof. This option was
re-enabled in 5.x (I forgot about that bug :/) and...  I'd like to keep
it that way, so I tried to troubleshoot this further.

It looks like there's a preloading loop between those libraries that
results in deadlocking. Effectively, during its initialization
(malloc_init) jemalloc tries to initialize libgcc's unwind code
(_Unwind_Backtrace), which in turn calls dl_iterate_phdr, which is
captured by libfakechroot, which calls dlsym()/dlerror(), which tries to
allocate memory back again, which deadlocks jemalloc.

The backtrace is (note how #6 and #20 are the same):
#0  __lll_lock_wait () at ../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:103
#1  0x7fd764008704 in __GI___pthread_mutex_lock (mutex=0x7fd7647a0500 
) at ../nptl/pthread_mutex_lock.c:80
#2  0x7fd76475f0dc in malloc_mutex_lock_final (mutex=0x7fd7647a04c0 
) at include/jemalloc/internal/mutex.h:141
#3  je_malloc_mutex_lock_slow (mutex=mutex@entry=0x7fd7647a04c0 ) at 
src/mutex.c:84
#4  0x7fd76470e244 in malloc_mutex_lock (mutex=0x7fd7647a04c0 , 
tsdn=0x0) at include/jemalloc/internal/mutex.h:205
#5  malloc_init_hard () at src/jemalloc.c:1506
#6  0x7fd76471524d in malloc_init () at src/jemalloc.c:217
#7  imalloc (dopts=, sopts=) at 
src/jemalloc.c:1986
#8  calloc (num=num@entry=1, size=size@entry=32) at src/jemalloc.c:2138
#9  0x7fd763ff8a25 in _dlerror_run (operate=operate@entry=0x7fd763ff8390 
, args=args@entry=0x7ffdd14ddfa0) at dlerror.c:141
#10 0x7fd763ff840f in __dlsym (handle=, name=) at dlsym.c:70
#11 0x7fd7644f49b4 in ?? () from 
/usr/lib/x86_64-linux-gnu/fakechroot/libfakechroot.so
#12 0x7fd7644edffc in dl_iterate_phdr () from 
/usr/lib/x86_64-linux-gnu/fakechroot/libfakechroot.so
#13 0x7fd763ff02a1 in _Unwind_Find_FDE (pc=0x7fd763fee867 
<_Unwind_Backtrace+55>, bases=bases@entry=0x7ffdd14de368) at 
../../../src/libgcc/unwind-dw2-fde-dip.c:469
#14 0x7fd763fec983 in uw_frame_state_for 
(context=context@entry=0x7ffdd14de2c0, fs=fs@entry=0x7ffdd14de110) at 
../../../src/libgcc/unwind-dw2.c:1257
#15 0x7fd763fedb60 in uw_init_context_1 (context=0x7ffdd14de2c0, 
outer_cfa=0x7ffdd14de570, outer_ra=0x7fd76476a878 )
at ../../../src/libgcc/unwind-dw2.c:1586
#16 0x7fd763fee868 in _Unwind_Backtrace (trace=trace@entry=0x7fd76475fdb0 
, trace_argument=trace_argument@entry=0x0)
at ../../../src/libgcc/unwind.inc:295
#17 0x7fd76476a878 in je_prof_boot2 (tsd=tsd@entry=0x7fd763fd7740) at 
src/prof.c:2392
#18 0x7fd76470e308 in malloc_init_hard () at src/jemalloc.c:1538
#19 malloc_init_hard () at src/jemalloc.c:1500
#20 0x7fd764710a85 in malloc_init () at src/jemalloc.c:217

I don't think it's a bug on either library per se. I was wondering if
you had any insight on how we could address this in fakechroot somehow
rather than in jemalloc, as that doesn't look to be easy without
disabling the profiling feature.

Regards,
Faidon

Bug#918700: grub2-common: update-grub fails with bogus error messages if it doesn't like the current dir

[Colin Watson]

On Wed, Jan 09, 2019 at 12:05:53AM +1100, Russell Coker wrote:
> Below is one example of the problem.  A trivial fix for this sort of problem
> would be to have the /usr/sbin/update-grub shell script do "cd /" before
> running grub-mkconfig (as update-grub is the documented way of doing things
> on Debian).  But a better solution would be to make grub-mkconfig either give
> useful error messages, or even better just not care about whether it can read
> the current directory.

This is in grub-probe, which is called by grub-mkconfig.  It's searching
/dev for a device, and doing that by changing to each directory as it
goes, which means it needs to save the initial directory so that it can
change back at the end.

The reason for this is opaque, because it goes back to the original
addition of the relevant section of code in the early days of GRUB 2,
but I'm going to guess that it's a performance optimisation to reduce
repeated path lookups; there can be quite a lot of inodes in /dev and
grub-probe can be quite slow as it is, so it's possible that this could
actually be worthwhile.

The ideal approach these days is probably to use the *at family of
syscalls where they're available, which would preserve the efficiency
gain without having to save and restore the current directory.  It would
take a bit of work, especially since that code is used on more than just
Linux, but shouldn't be prohibitively difficult.

However, since GRUB already uses Gnulib, a quicker fix would be to use
its save-cwd module, which knows how to use open/fchdir rather than
getcwd/chdir on systems that support it.

-- 
Colin Watson   [cjwat...@debian.org]

Bug#918467: lxpanel: Weather plugin uses obsolete APIs, does not work.

[Andriy Grytsenko]

Yes, Yahoo unfortunately ended free service at January 3.

New API requires registering the application and has unknown restrictions
which probably will lead the weather plugin to DoS situation, because if
developer registers API to get a key then that limitation will be applied
to each user of that API so may be soon exceeded.

Abother issue that new Yahoo API requires digital signature for each
request which in turn will involve libssl with all their restrictions.

Unfortunately all weather providers now made their API available via some
kind of registration. We can force each user to register but that will be
pretty inconvenient for users. Another approach is to register some token
for LXDE developers public e-mail but if (for example) 50 users will
use the plugin and we set update time once in two hours, that will make
50/120=4000 requests per minute, which exceeds number for any free
subscription which definitely makes the plugin unusable at all, so this
approach is not a way to go. Thus I have no idea what else to do except
to remove the plugin from distribution.

Bug#918655: msmtp: Apparmor causing Permission denied when creating tmp files and logging

[Emmanuel Bouthenot]

Hello,

On Mon, Jan 07, 2019 at 08:35:25PM -0500, Simon Deziel wrote:
[...]

> I agree, I should have thought of that. How about adding the text from
> README.Debian as a NEWS entry?
> 
> I will do some testing with 1.8.1-1 but in the meantime, please find
> attached a more up to date profile that received more testing and also
> incorporates your feedback (thanks!).

Thanks (to you and Ondra) for your feedback.

I've just uploaded msmtp 1.8.1-2 with your patch and a notice in
debian/NEWS

Regards,

-- 
Emmanuel Bouthenot
  mail: kolter@{openics,debian}.orggpg: 4096R/0x929D42C3
  xmpp: kol...@im.openics.org  irc: kolter@{freenode,oftc}

Bug#918741: Build-Depends on deprecated libjemalloc SONAME directly

[Faidon Liambotis]

Package: src:fakechroot
Version: 2.19-3
Severity: serious

Hi,

I uploaded jemalloc 5.1.0-2 to unstable the other day. It involves a new
ABI and SONAME and thus a transition from libjemalloc1 -> libjemalloc2.

I noticed that your package Build-Depends directly on libjemalloc1, and
thus this package will start FTBFSing once libjemalloc1 gets removed
from the archive.

It seems like the B-D is there because the test suite includes a test
for jemalloc (which is great!), and specifically the binary library
which it's LD_PRELOADing, hence the dependency on the binary package.

Rather than s/libjemalloc1/libjemalloc2/, I would recommend to B-D on
"libjemalloc-dev" like a regular source package, and then modify the
test suite to search for the symlink "libjemalloc.so" (e.g.
/usr/lib/x86_64-linux-gnu/libjemalloc.so). This would make it future
proof for future ABI/SONAME bumps.

Apologies for filing this after the transition has already started -- as
a B-D on the binary package is unsual, it didn't occur to me to
grep-dctrl for that beforehand.

Regards,
Faidon

Bug#575482: Propose to NMU icoutils

[Colin Watson]

On Thu, Dec 13, 2018 at 10:23:48PM +0100, Helge Kreutzmann wrote:
> I propose to NMU icoutils to solve the long standing translation bug
> 575482.
> 
> You can find my proposed updates at
> http://www.helgefjell.de/data/icoutils_0.32.3-2.1.debian.tar.xz
> http://www.helgefjell.de/data/icoutils_0.32.3-2.1.dsc
> 
> I would prefer if you could add this to your next MU, but if I don't
> hear from you I would upload this NMU early January.
> 
> If you have any questions do not hesitate to ask.

Hi,

I'm sorry for not noticing this earlier, but I really can't say that I
would have accepted this.  Translations need to go upstream or they
cannot be maintained effectively.  Is there some reason why this
translation hasn't been sent upstream for integration into a new
upstream release instead of pushing it into Debian?

-- 
Colin Watson   [cjwat...@debian.org]

Bug#918664: linux-latest: please provide a meta package for a sane architecture-specific default

[Ben Hutchings]

On Tue, 2019-01-08 at 10:50 +0100, Johannes Schauer wrote:
> Hi Ben,
> 
> Quoting Ben Hutchings (2019-01-08 09:46:43)
> > > I know that the right kernel image is not a function of the
> > > Debian
> > > architecture alone. But this meta-package is not supposed to
> > > replace
> > > kernel selection for d-i or the like. It is meant to be one
> > > central
> > > place to encode a sane default mapping in the Debian linux kernel
> > > package instead of (poorly) replicating such a mapping in
> > > individual
> > > packages.
> > 
> > For many architectures there is no single good default - that's the
> > main reason why we have multiple flavours.
> 
> But for other architectures there is.
> 
> So this binary package could be built for architectures where a
> reasonable
> default exists but not for those where it doesn't.

Then it wouldn't be safe to depend on it, so how would it be used?

> Package: linux-image-default
> Architecture: i386, alpha, amd64, arm64, armhf, ia64, m68k, armel,
> hppa, powerpc, ppc64, ppc64el, powerpcspe, riscv64, s390x, sparc64
> Depends:
>  linux-image-686 [i386],

Most i386 systems should use 686-pae.  But some can't (otherwise we
would drop 686).

>  linux-image-alpha-generic [alpha],

Useless for SMP systems.

>  linux-image-amd64 [amd64],
>  linux-image-arm64 [arm64],

Right.

(Although for cloud deployments cloud-amd64 and (proposed)
cloud-arm64 may be more suitable.)

>  linux-image-armmp [armhf],

Some armhf systems need armmp-lpae to access all their RAM.

>  linux-image-itanium [ia64],

I think this is rather slow on later Itanium chips.

>  linux-image-m68k [m68k],
>  linux-image-marvell [armel],

Right.

>  linux-image-parisc [hppa],

I don't think this will run on 64-bit systems.

>  linux-image-powerpc [powerpc],

This won't run on most 64-bit systems (probably the majority).

>  linux-image-powerpc64 [ppc64],
>  linux-image-powerpc64le [ppc64el],
>  linux-image-powerpcspe [powerpcspe],
>  linux-image-riscv64 [riscv64],
>  linux-image-s390x [s390x],

Right.

>  linux-image-sparc64 [sparc64]

Useless for SMP systems.

> Maybe some of the above still has to be removed but do really too few
> architectures remain where a sane choice exists?

If there is only one sensible choice then we only build one flavour.

Ben.

-- 
Ben Hutchings
Any smoothly functioning technology is indistinguishable
from a rigged demo.




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

Bug#918740: rdkit: baseline violation on amd64/i386 and FTBFS everywhere else

[Adrian Bunk]

Source: rdkit
Version: 201803.4+dfsg-2
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/package.php?p=rdkit=sid

...
gcc -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement 
-Wendif-labels -Wmissing-format-attribute -Wformat-security 
-fno-strict-aliasing -fwrapv -fexcess-precision=standard -Wno-format-truncation 
-Wno-stringop-truncation -g -g -O2 -fstack-protector-strong -Wformat 
-Werror=format-security -g -O2 
-fdebug-prefix-map=/<>/rdkit-201803.4+dfsg=. -fstack-protector-strong 
-Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC 
-I/usr/local/include -I/<>/rdkit-201803.4+dfsg/Code 
-DRDKITVER='"007300"'   -DUSE_BUILTIN_POPCOUNT -mpopcnt -I. 
-I/<>/rdkit-201803.4+dfsg/Code/PgSQL/rdkit 
-I/usr/include/postgresql/11/server -I/usr/include/postgresql/internal  
-Wdate-time -D_FORTIFY_SOURCE=2 -D_GNU_SOURCE -I/usr/include/libxml2  
-I/usr/include/mit-krb5 -fPIC -c -o rdkit_io.o 
/<>/rdkit-201803.4+dfsg/Code/PgSQL/rdkit/rdkit_io.c
gcc: error: unrecognized command line option '-mpopcnt'
make[2]: *** [/<>/rdkit-201803.4+dfsg/Code/PgSQL/rdkit/Makefile:101: 
rdkit_io.o] Error 1


Due to Code/PgSQL/rdkit/Makefile:
POPCOUNTFLAGS=-DUSE_BUILTIN_POPCOUNT -mpopcnt

Bug#918176: libixion: autopkgtest references old libixion binary

[Rene Engelhard]

On Thu, Jan 03, 2019 at 08:07:26PM -0500, Logan Rosen wrote:
> In Ubuntu, the attached patch was applied to achieve the following:
> 
>   * d/t/control: Update dependency to libixion-0.14-0.

Which is incomplete. Note the find in the test itself, without what it
won't remove the lib and thus test the built lib instead of the
installed one...

(Fixed in Debian after applying your patch.)

Regards,

Rene

Bug#918739: node-duplexer2 FTBFS with nodejs 10.15.0

[Adrian Bunk]

Source: node-duplexer2
Version: 0.1.4-1
Severity: serious
Tags: ftbfs buster sid

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/node-duplexer2.html

...
mocha -R tap
1..14
ok 1 duplexer2 should interact with the writable stream properly for writing
ok 2 duplexer2 should interact with the readable stream properly for reading
ok 3 duplexer2 should end the writable stream, causing it to finish
ok 4 duplexer2 should finish when the writable stream finishes
ok 5 duplexer2 should end when the readable stream ends
ok 6 duplexer2 should bubble errors from the writable stream when no behaviour 
is specified
ok 7 duplexer2 should bubble errors from the readable stream when no behaviour 
is specified
ok 8 duplexer2 should bubble errors from the writable stream when bubbleErrors 
is true
ok 9 duplexer2 should bubble errors from the readable stream when bubbleErrors 
is true
ok 10 duplexer2 should not bubble errors from the writable stream when 
bubbleErrors is false
ok 11 duplexer2 should not bubble errors from the readable stream when 
bubbleErrors is false
ok 12 duplexer2 should work with streams1
ok 13 duplexer2 should export the DuplexWrapper constructor
not ok 14 duplexer2 should not force flowing-mode
  AssertionError [ERR_ASSERTION]: false == null
  at Context. (test/tests.js:195:12)
  at callFnAsync (/usr/lib/nodejs/mocha/lib/runnable.js:377:21)
  at Test.Runnable.run (/usr/lib/nodejs/mocha/lib/runnable.js:324:7)
  at Runner.runTest (/usr/lib/nodejs/mocha/lib/runner.js:442:10)
  at /usr/lib/nodejs/mocha/lib/runner.js:560:12
  at next (/usr/lib/nodejs/mocha/lib/runner.js:356:14)
  at /usr/lib/nodejs/mocha/lib/runner.js:366:7
  at next (/usr/lib/nodejs/mocha/lib/runner.js:290:14)
  at /usr/lib/nodejs/mocha/lib/runner.js:329:7
  at done (/usr/lib/nodejs/mocha/lib/runnable.js:301:5)
  at callFn (/usr/lib/nodejs/mocha/lib/runnable.js:372:7)
  at Hook.Runnable.run (/usr/lib/nodejs/mocha/lib/runnable.js:346:7)
  at next (/usr/lib/nodejs/mocha/lib/runner.js:304:10)
  at Immediate._onImmediate (/usr/lib/nodejs/mocha/lib/runner.js:334:5)
# tests 14
# pass 13
# fail 1
make[1]: *** [debian/rules:13: override_dh_auto_test] Error 1

Bug#918723: "ERROR: TypeError: a bytes-like object is required, not 'str'" on committing

[Jelmer Vernooij]

tags 918723 +confirmed
tags 918723 +upstream
thanks

Hi Martin,

On Tue, Jan 08, 2019 at 07:52:38PM +0100, Martin Steigerwald wrote:
>   File "/usr/lib/python3/dist-packages/breezy/bzr/pack_repo.py", line 883, in 
> autopack
> return self._do_autopack()
>   File "/usr/lib/python3/dist-packages/breezy/bzr/pack_repo.py", line 924, in 
> _do_autopack
> reload_func=self._restart_autopack)
>   File "/usr/lib/python3/dist-packages/breezy/bzr/pack_repo.py", line 943, in 
> _execute_pack_operations
> result = packer.pack()
>   File "/usr/lib/python3/dist-packages/breezy/bzr/pack_repo.py", line 711, in 
> pack
> return self._create_pack_from_packs()
>   File "/usr/lib/python3/dist-packages/breezy/bzr/knitpack_repo.py", line 
> 914, in _create_pack_from_packs
> new_pack.signature_index)
>   File "/usr/lib/python3/dist-packages/breezy/bzr/knitpack_repo.py", line 
> 639, in _copy_nodes
> write_index, pb, output_lines=output_lines)
>   File "/usr/lib/python3/dist-packages/breezy/bzr/knitpack_repo.py", line 
> 663, in _do_copy_nodes
> bits = value[1:].split(' ')
> TypeError: a bytes-like object is required, not 'str'
> 
> brz 3.0a2 on python 3.7.2 (Linux-4.20.0-tp520-x86_64-with-debian-buster-sid)
> arguments: ['/usr/bin/brz', 'commit', '-m', 'Updated.', '.gnupg/pubring.gpg']
> plugins: bash_completion[3.0a2], changelog_merge[3.0a2],
> commitfromnews[unknown], cvs[3.0a2], darcs[unknown], email[unknown],
> fastimport[unknown], grep[3.0a2], launchpad[3.0a2], mtn[3.0a2],
> netrc_credential_store[3.0a2], news_merge[3.0a2], po_merge[3.0a2],
> propose[unknown], repodebug[unknown], stats[3.0a2], upload[3.0a2],
> weave_fmt[3.0a2]
> encoding: 'utf-8', fsenc: 'utf-8', lang: 'de_DE.UTF-8'
> 
> *** Bazaar has encountered an internal error.  This probably indicates a
> bug in Bazaar.  You can help us fix it by filing a bug report at
> https://bugs.launchpad.net/brz/+filebug
> including this traceback and a description of the problem.
Hmm, interesting. It looks like you have encountered an untested
corner case while dealing with signatures during autopack when running
on Python 3. It looks like we missed this when porting to Python 3.

I'll make sure this gets fixed before the beta.

> I attempted to write to baz...@lists.canonical.com but got:
> 
> % postqueue -p
> -Queue ID-  --Size-- Arrival Time -Sender/Recipient---
> E086C42C103 5829 Sat Jan  5 15:08:39  mymailaddress
>   (connect to lists-mx.canonical.com[162.213.33.250]:25: Connection timed out)
>  baz...@lists.canonical.com
> 
> -- 5 Kbytes in 1 Request.
Hmm, I'm not sure what that's about. lists.canonical.com is still up,
so I'm guessing that is a transient issue. Can you perhaps try again?

Cheers,

Jelmer


signature.asc
Description: PGP signature

Bug#918738: libodb-api-dev is not installable due to typo in the dependencies

[Adrian Bunk]

Package: libodb-api-dev
Version: 0.18.1-3
Severity: serious

The following packages have unmet dependencies:
 libodb-api-dev : Depends: ibodb-api-bin (= 0.18.1-3) but it is not installable

Bug#918729: Acknowledgement (gearman-server: Some gearadmin commands do not work with gearman-server: --getpid, --server-verbose)

[Christian Weiske]

Hello,


The mentioned problems are gone when using "gearman-job-server" (the
C-reimplementation).

I'd still consider it a bug that those problems exist on
gearman-server, and that gearman-server does not start.

-- 
Regards/Mit freundlichen Grüßen
Christian Weiske

-=≡ Geeking around in the name of science since 1982 ≡=-

Bug#882993: mlocate: please supply a systemd unit for updatedb.mlocate

[Luisteam]

Package: mlocate
Version: 0.26-2
Followup-For: Bug #882993

Dear Maintainer,

good morning, I created a systemd drive for debian 9, start and update mlocate

sudo nano /lib/systemd/system/mlocate.service

[Unit]
Description= quickly find files on the filesystem based on their name
After=syslog.target

[Service]
ExecStart=/bin/bash -c "flock --nonblock /run/mlocate.daily.lock $NOCACHE
$IONICE /usr/bin/updatedb.mlocate"
Restart=always
KillSignal=SIGQUIT
Type=notify
StandardError=syslog
NotifyAccess=all

[Install]
WantedBy=multi-user.target

sudo systemctl enable mlocate.service

sudo systemctl start mlocate.service

test:

sudo systemctl status mlocate.service

● mlocate.service - quickly find files on the filesystem based on their name
   Loaded: loaded (/lib/systemd/system/mlocate.service; enabled; vendor preset:
enabled)
   Active: active (running) since Thu 2018-12-20 00:12:21 CET; 3s ago
 Main PID: 12847 (flock)
Tasks: 2 (limit: 4915)
   Memory: 56.1M
  CPU: 1.512s
   CGroup: /system.slice/mlocate.service
   ├─12847 flock --nonblock /run/mlocate.daily.lock
/usr/bin/updatedb.mlocate
   └─12848 /usr/bin/updatedb.mlocate

dic 20 00:12:21 MiAir systemd[1]: Started quickly find files on the filesystem
based on their name.



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

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

Versions of packages mlocate depends on:
ii  adduser  3.115
ii  libc62.24-11+deb9u3

mlocate recommends no packages.

mlocate suggests no packages.

-- no debconf information

Bug#918736: libthrift-java: CVE-2018-1320

[Salvatore Bonaccorso]

Source: libthrift-java
Version: 0.9.1-2
Severity: important
Tags: patch security upstream
Forwarded: https://issues.apache.org/jira/browse/THRIFT-4506

Hi,

The following vulnerability was published for libthrift-java.

CVE-2018-1320[0]:
| Apache Thrift Java client library versions 0.5.0 through 0.11.0 can
| bypass SASL negotiation isComplete validation in the
| org.apache.thrift.transport.TSaslTransport class. An assert used to
| determine if the SASL handshake had successfully completed could be
| disabled in production settings making the validation incomplete.

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-2018-1320
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-1320
[1] https://issues.apache.org/jira/browse/THRIFT-4506
[2] 
https://github.com/apache/thrift/commit/d973409661f820d80d72c0034d06a12348c8705e

Regards,
Salvatore

Bug#918737: docs and desks

[Barak A. Pearlmutter]

Package: pulseaudio-equalizer:
Version: 12.2-2
Severity: wishlist

I got turned on to this package by a nice blog post:

https://tqdev.com/2018-equalizer-for-pulseaudio-in-ubuntu-18-04

It would be nice if the package contained the information in that
post, in condensed form, in /usr/share/doc/pulseaudio-equalizer/. In
particular:

To try it:

$ pactl load-module module-equalizer-sink
$ pactl load-module module-dbus-protocol
$ qpaeq

To get qpaeq to work without the above after a restart:

$ echo "load-module module-equalizer-sink" >> /etc/pulse/default.pa
$ echo "load-module module-dbus-protocol" >> /etc/pulse/default.pa

It would also be nice if there were a qpaeq.desktop file.

Bug#917633: Also blocks migration of tails-installer

[Ulrike Uhlig]

Hello!

this issue currently also blocks the migration of tails-installer,
shortly before the freeze.

Cheers!
u.

Bug#918735: abyss: Accidental dropping of armel

[Adrian Bunk]

Source: abyss
Version: 2.1.5-2
Severity: normal

abyss successfully built on armel (which is little endian),
please re-add armel to the architecture list.

Bug#918734: thrift: CVE-2018-11798

[Salvatore Bonaccorso]

Source: thrift
Version: 0.11.0-3
Severity: normal
Tags: patch security upstream
Forwarded: https://issues.apache.org/jira/browse/THRIFT-4647

Hi,

The following vulnerability was published for thrift.

Note this is only unimportant, and actually just to track the
source-code fix at some point. The binary package are not affected in
Debian as we do not build with nodejs support enabled.

CVE-2018-11798[0]:
| The Apache Thrift Node.js static web server in versions 0.9.2 through
| 0.11.0 have been determined to contain a security vulnerability in
| which a remote user has the ability to access files outside the set
| webservers docroot path.

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-2018-11798
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-11798
[1] https://issues.apache.org/jira/browse/THRIFT-4647
[2] 
https://github.com/apache/thrift/commit/2a2b72f6c8aef200ecee4984f011e06052288ff2

Regards,
Salvatore

Bug#917633: udisk2 post-installation fails in chrooted environments

[Vagrant Cascadian]

Control: affects 917633 src:ltsp

Also blocking migration for ltsp:

  https://piuparts.debian.org/sid/fail/ltsp-server-standalone_5.18.12-1.log

live well,
  vagrant


signature.asc
Description: PGP signature

Bug#918733: googletest FTBFS on mips/mipsel: out of memory

[Adrian Bunk]

Source: googletest
Version: 1.8.1-2
Severity: serious
Tags: ftbfs patch

https://buildd.debian.org/status/package.php?p=googletest

...
as: out of memory allocating 4072 bytes after a total of 543838208 bytes
/tmp/ccnTRJ3H.s: Assembler messages:
/tmp/ccnTRJ3H.s: Fatal error: can't close 
CMakeFiles/gmock-matchers_test.dir/test/gmock-matchers_test.cc.o: memory 
exhausted
make[3]: *** [googlemock/CMakeFiles/gmock-matchers_test.dir/build.make:66: 
googlemock/CMakeFiles/gmock-matchers_test.dir/test/gmock-matchers_test.cc.o] 
Error 1


Fix:

--- debian/rules.old2019-01-08 12:16:26.188970969 +
+++ debian/rules2019-01-08 12:16:43.685280431 +
@@ -9,11 +9,11 @@
 ifeq ($(DEB_HOST_ARCH),hppa)
 CXXFLAGS += -mlong-calls
 else ifeq ($(DEB_BUILD_ARCH), mips)
-CXXFLAGS += -mxgot
+CXXFLAGS += -mxgot -g1
 else ifeq ($(DEB_BUILD_ARCH), mips64el)
 CXXFLAGS += -mxgot
 else ifeq ($(DEB_BUILD_ARCH), mipsel)
-CXXFLAGS += -mxgot
+CXXFLAGS += -mxgot -g1
 endif
 
 export CXXFLAGS

Bug#918731: ruby-diaspora-vines: autopkgtest needs update for new version of rails

[Paul Gevers]

Source: ruby-diaspora-vines
Version: 0.2.0.develop.4-2
X-Debbugs-CC: debian...@lists.debian.org, ra...@packages.debian.org
User: debian...@lists.debian.org
Usertags: needs-update
Control: affects -1 src:rails

Dear maintainers,

With a recent upload of rails the autopkgtest of ruby-diaspora-vines
fails in testing when that autopkgtest is run with the binary packages
of rails from unstable. It passes when run with only packages from
testing. In tabular form:
   passfail
rails  from testing2:5.2.2+dfsg-1
ruby-diaspora-vinesfrom testing0.2.0.develop.4-2
versioned deps [0] from testingfrom unstable
all others from testingfrom testing

I copied some of the output at the bottom of this report. It seems you
need to adapt the version to the new version of rails.

Currently this regression is contributing to the delay of the migration
of rails to testing [1]. Of course, rails shouldn't just break your
autopkgtest (or even worse, your package), but it seems to me that the
change in rails was intended and your package needs to update to the new
situation. If needed, please change the bug's severity.

If this is a real problem in your package (and not only in your
autopkgtest), the right binary package(s) from rails should really add a
versioned Breaks on the unfixed version of (one of your) package(s).
Note: the Breaks is nice even if the issue is only in the autopkgtest as
it helps the migration software to figure out the right versions to
combine in the tests.

More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[0] You can see what packages were added from the second line of the log
file quoted below. The migration software adds source package from
unstable to the list if they are needed to install packages from
rails/2:5.2.2+dfsg-1. I.e. due to versioned dependencies or
breaks/conflicts.
[1] https://qa.debian.org/excuses.php?package=rails

https://ci.debian.net/data/autopkgtest/testing/amd64/r/ruby-diaspora-vines/1663564/log.gz
autopkgtest [05:36:43]: test command1: gem2deb-test-runner --autopkgtest
--check-dependencies 2>&1
autopkgtest [05:36:43]: test command1: [---

┌──┐
│ Checking Rubygems dependency resolution on ruby2.5
  │
└──┘

GEM_PATH= ruby2.5 -e gem\ \"diaspora-vines\"
/usr/lib/ruby/2.5.0/rubygems/dependency.rb:312:in `to_specs': Could not
find 'activerecord' (~> 4.1) - did find: [activerecord-5.2.2]
(Gem::MissingSpecVersionError)
Checked in
'GEM_PATH=/home/debci/.gem/ruby/2.5.0:/var/lib/gems/2.5.0:/usr/lib/x86_64-linux-gnu/rubygems-integration/2.5.0:/usr/share/rubygems-integration/2.5.0:/usr/share/rubygems-integration/all',
execute `gem env` for more information
from /usr/lib/ruby/2.5.0/rubygems/specification.rb:1469:in `block in
activate_dependencies'
from /usr/lib/ruby/2.5.0/rubygems/specification.rb:1458:in `each'
from /usr/lib/ruby/2.5.0/rubygems/specification.rb:1458:in
`activate_dependencies'
from /usr/lib/ruby/2.5.0/rubygems/specification.rb:1440:in `activate'
from /usr/lib/ruby/2.5.0/rubygems/core_ext/kernel_gem.rb:68:in `block
in gem'
from /usr/lib/ruby/2.5.0/rubygems/core_ext/kernel_gem.rb:67:in
`synchronize'
from /usr/lib/ruby/2.5.0/rubygems/core_ext/kernel_gem.rb:67:in `gem'
from -e:1:in `'




signature.asc
Description: OpenPGP digital signature

Bug#918732: botan: CVE-2018-20187: Side channel during ECC key generation

[Salvatore Bonaccorso]

Source: botan
Version: 2.8.0-3
Severity: important
Tags: security upstream
Forwarded: https://github.com/randombit/botan/pull/1792

Hi,

The following vulnerability was published for botan.

CVE-2018-20187[0]:
Timing side channel during ECC key generation could leak information...

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-2018-20187
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-20187
[1] https://github.com/randombit/botan/pull/1792

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#917303: Request for help with MariaDB 10.3 / libdbd-mysql-perl packaging

[Otto Kekäläinen]

For the records of this bug report and people following it, there are a lot
of discussions going on in both
https://github.com/perl5-dbi/DBD-mysql/issues/275 and
https://github.com/MariaDB/mariadb-connector-c/pull/95

I will now import MariaDB 10.3.12 into
https://salsa.debian.org/mariadb-team/mariadb-10.3 but postpone uploading
it for now in case the issues above might produce something that we can
backport and patch upon the mariadb-10.3 packaging in Debian to help fix
the issue in Debian. Personally I cannot follow all the details in the
Github issues above, so please let me know if something actionable on my
side emerges (e.g. patches as mentioned).

Bug#918730: libexif: CVE-2018-20030: Input validation issue resulting in a denial of service

[Salvatore Bonaccorso]

Source: libexif
Version: 0.6.21-5
Severity: important
Tags: security upstream
Control: found -1 0.6.21-2

Hi,

The following vulnerability was published for libexif, for now filling
primarly for tracking, as there is not much details provided as well
if searching the cross references to other distros bugtrackers.

CVE-2018-20030[0]:
Input validation issue resulting in a denial of service

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-2018-20030
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-20030
[1] https://secuniaresearch.flexerasoftware.com/secunia_research/2018-28/

Regards,
Salvatore

Bug#864440: xclip: Please package new upstream version 0.13

[Boyuan Yang]

Hi Alessandro,

Alessandro Ghedini  于2019年1月7日周一 下午2:58写道：
>
> If you are interested in maintaining xclip you are very welcome to join as
> co-maintainer (or even only maintainer as I don't a whole lot of time to
> dedicate to it).
>
> The git repo is on salsa https://salsa.debian.org/debian/xclip so you are
> welcome to do changes there.

Thanks for your response. I have uploaded the 0.13-1 version with myself
added as uploader.

--
Thanks,
Boyuan Yang

Bug#918729: gearman-server: Some gearadmin commands do not work with gearman-server: --getpid, --server-verbose

[Christian Weiske]

Package: gearman-server
Version: 1.130.1-1
Severity: normal

Dear Maintainer,

I'm trying to use gearman-server and inspect it with gearadmin.

Starting gearman via systemd does not work, so I had to start it as follows:

$ start-stop-daemon --start --quiet --pidfile /var/run/gearmand.pid --exec 
/usr/bin/gearmand -- --pidfile=/var/run/gearmand.pid --debug=1

When trying to query server status now, I get errors:

$ gearadmin --server-verbose
Error: unknown_command

The server shows:
> Use of uninitialized value $a in substitution (s///) at 
> /usr/share/perl5/Gearman/Server/Client.pm line 847.
> Use of uninitialized value $a in transliteration (tr///) at 
> /usr/share/perl5/Gearman/Server/Client.pm line 848.
> Use of uninitialized value in concatenation (.) or string at 
> /usr/share/perl5/Gearman/Server/Client.pm line 841.

Next problematic command:

$ gearadmin --getpid
Error: unknown_command 

The server shows the same error as for --server-verbose



gearman-tools version 1.0.6-9

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

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

Versions of packages gearman-server depends on:
ii  libdanga-socket-perl1.61-1
ii  libgearman-client-perl  1.130.004-1
ii  perl5.24.1-3+deb9u5

gearman-server recommends no packages.

gearman-server suggests no packages.

-- Configuration Files:
/etc/default/gearman-server changed:
DAEMON_OPTS="-d --pidfile=/var/run/gearmand.pid"
ENABLED="true"


-- no debconf information

Bug#918728: libvirt-daemon should provide iscsi-direct storage backend

[Matthew Gabeler-Lee]

Package: libvirt-daemon
Version: 4.10.0-2
Severity: normal

Upstream now has an "iscsi-direct" storage backend which has several
advantages over the iscsiadm-based "iscsi" storage backend, including
performance and not having the iscsi devices visible to the rest of the
system.

Debian's libvirt-daemon package should build with this enabled, or provide a
libvirt-daemon-driver-storage-iscsi-direct package.

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

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

Versions of packages libvirt-daemon depends on:
ii  libacl1 2.2.52-3+b1
ii  libapparmor12.11.0-3+deb9u2
ii  libaudit1   1:2.6.7-2
ii  libavahi-client30.6.32-2
ii  libavahi-common30.6.32-2
ii  libblkid1   2.33-0.2
ii  libc6   2.28-2
ii  libcap-ng0  0.7.9-1+b1
ii  libcurl3-gnutls 7.62.0-1
ii  libdbus-1-3 1.10.26-0+deb9u1
ii  libdevmapper1.02.1  2:1.02.155-1
ii  libfuse22.9.8-2
ii  libgcc1 1:8.2.0-13
ii  libgnutls30 3.6.5-2
ii  libnetcf1   1:0.2.8-1+b2
ii  libnl-3-200 3.2.27-2
ii  libnl-route-3-200   3.2.27-2
ii  libnuma12.0.11-2.1
ii  libparted2  3.2-23
ii  libpcap0.8  1.8.1-3
ii  libpciaccess0   0.13.4-1+b2
ii  libsasl2-2  2.1.27~101-g0780600+dfsg-3
ii  libselinux1 2.6-3+b3
ii  libssh2-1   1.7.0-1
ii  libudev1232-25+deb9u6
ii  libvirt04.10.0-2
ii  libxenmisc4.11  4.11.1~pre.20180911.5acdd26fdc+dfsg-5
ii  libxenstore3.0  4.8.4+xsa273+shim4.10.1+xsa273-1+deb9u10
ii  libxentoollog1  4.11.1~pre.20180911.5acdd26fdc+dfsg-5
ii  libxml2 2.9.4+dfsg1-2.2+deb9u2
ii  libyajl22.1.0-2+b3

Versions of packages libvirt-daemon recommends:
ii  libxml2-utils   2.9.4+dfsg1-2.2+deb9u2
ii  netcat-openbsd  1.195-1
ii  qemu1:3.1+dfsg-2
ii  qemu-kvm1:3.1+dfsg-2

Versions of packages libvirt-daemon suggests:
pn  libvirt-daemon-driver-storage-gluster   
pn  libvirt-daemon-driver-storage-rbd   
pn  libvirt-daemon-driver-storage-sheepdog  
pn  libvirt-daemon-driver-storage-zfs   
ii  libvirt-daemon-system   4.10.0-2
pn  numad   

-- no debconf information

Bug#913674: Preparing p-u upload

[Adam D. Barratt]

Hi,

On Mon, 2019-01-07 at 20:28 +0100, Hilko Bengen wrote:
> I had the impression that updating to a new upstream version was a
> done deal. Quoting yourself
> (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=913674#10):
> 
> ,
> > Firstly, one needs to identify whether the same issue affects the
> > package in unstable.
> > 
> > Once it's been confirmed that unstable is no{t, longer} affected,
> > someone should produce a fixed package and open a p-u bug to
> > document
> > uploading that to proposed-updates.
> 
> `

Ah, I suspect there has been some confusion regarding the quoted text -
"that" is "a fixed package", not "the package in unstable". The mention
of unstable was a general reference to the workflow requirement for
issues to be resolved in unstable first, not a specific suggestion to
upload the unstable package to stable.

Apologies for any confusion.

Regards,

Adam

Bug#918727: openssl.cnf incompatible with libssl1.0.2, libssl1.0.0

[Simon McVittie]

Package: openssl
Version: 1.1.1a-1
Severity: important
Control: found -1 1.1.1~~pre3-1
Control: affects -1 steam

The openssl.cnf in the openssl package since 1.1.1~~pre3-1 is incompatible
with libssl < 1.1.0 (I think that's the right cutoff point), either from
a partial upgrade or bundled with third-party software.

It should probably at least have a Breaks on libssl1.0.2, to protect
partial upgrades from stretch. Some release notes for users of
third-party software might also be useful. I realise it probably isn't
feasible to keep openssl.cnf compatible with all past and future versions.

It would perhaps be a good idea for future OpenSSL branches to
use a configuration file that's tied to the major version in their SONAME,
or otherwise parallel-installable? (openssl1.1.0.cnf, etc.)

Minimal reproducer:

* start from Debian testing (buster)
* unpack libssl1.0.2 1.0.2q-2, from unstable, and openssl 1.0.2j-1
  from snapshots.debian.org (the newest openssl.deb that still depended
  on libssl1.0.2) into ~/102
* then run:
  LD_LIBRARY_PATH=$HOME/102/usr/lib/x86_64-linux-gnu $HOME/102/usr/bin/openssl 
s_client example.com:443

Expected result: successful connection

Actual result:

Error configuring OpenSSL
140099788864256:error:25066067:DSO support routines:DLFCN_LOAD:could not load 
the shared library:dso_dlfcn.c:187:filename(libssl_conf.so): libssl_conf.so: 
cannot open shared object file: No such file or directory
140099788864256:error:25070067:DSO support routines:DSO_load:could not load the 
shared library:dso_lib.c:233:
140099788864256:error:0E07506E:configuration file 
routines:MODULE_LOAD_DSO:error loading dso:conf_mod.c:271:module=ssl_conf, 
path=ssl_conf
140099788864256:error:0E076071:configuration file routines:MODULE_RUN:unknown 
module name:conf_mod.c:212:module=ssl_conf

The same thing can be reproduced with libssl1.0.0 and openssl from jessie.

Workaround: use OPENSSL_CONF=/dev/null when running software that depends
on an older libssl.

For context, libssl_conf.so never actually existed on disk, and
isn't really meant to. In OpenSSL's approach to configuration,
/etc/ssl/openssl.cnf configuration parameters cause loading of
native-code modules, which can either be built-in to libcrypto or
libssl, or real files on disk to be dlopen()ed (like the way Python's
sys module is built-in to the interpreter, but its readline module is
external). libssl_conf.so in the default library search path (!) is one
of several names OpenSSL would try for the ssl_conf module - I think
the reason it appears in the error message is that it's the last one to
be tried.

Since 1.1.0 (commit 59b1696c), there is a ssl_conf module built-in to
libssl. It moved into libcrypto in 1.1.1 (commit d8f031e8).

In Debian, since 1.1.1 (August 2018, if we don't count experimental),
/etc/ssl/openssl.cnf has made use of the ssl_conf mechanism to enforce
TLS1.2 as the minimum protocol, and 112-bit security (level 2) as
the minimum security level. This file is only installed if the openssl
package (containing the openssl command-line tool) is installed. However,
ca-certificates depends on openssl, so in practice basically all users
will have it.

This affects libssl1.0.0 in the Steam Runtime installed by the non-free
steam package, and possibly other third-party software bundles.
()

smcv

Bug#918725: grafx2 FTCBFS: hard codes the build architecture pkg-config

[Adrien Destugues]

Hi,

Thanks, patch is now upstreamed. It will be part of GrafX2 2.6, which we will 
release soon.

-- 
Adrien.

8 janvier 2019 20:54 "Helmut Grohne"  a écrit:

> Source: grafx2
> Version: 2.5+git20181211-1
> Tags: patch upstream
> User: helm...@debian.org
> Usertags: rebootstrap
> 
> grafx2 fails to cross build from source, because src/Makefile hard codes
> plain pkg-config. For cross compilation, we need to use a
> triplet-prefixed pkg-config and dh_auto_build substitutes that.
> Therefore making pkg-config substitutable is sufficient for making
> grafx2 cross buildable. Please consider applying the attached patch.
> 
> Helmut

Bug#917745: cross-toolchain-base: FTBFS: applying patches fails

[Paul Gevers]

user debian...@lists.debian.org
usertags needs-update
thanks

Hi all,

On Sat, 29 Dec 2018 23:46:40 +0100 Lucas Nussbaum  wrote:
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
> 
> Relevant part (hopefully):
> >  debian/rules build
> > linux: 4.19.12-1 / 4.18.20-2cross2
> > glibc: 2.28-4 / 2.28-2cross2
> > 
> > old linux version: 4.18.20-2 / 2
> > old glibc version: 2.28-2 / 2
> > 
> > new linux version: 4.19.12-1cross1
> > new glibc version: 2.28-4cross1
> > START stamp-dir/init-glibc
> > rm -rf glibc-2.28
> > tar -x -f  /usr/src/glibc/glibc-2.28.tar.xz
> > cp -a /usr/src/glibc/debian/ glibc-2.28
> > cd glibc-2.28 ; \
> > QUILT_PATCHES=/<>/debian/patches/glibc/debian quilt --quiltrc 
> > /dev/null push -a && \
> > rm -rf .pc/
> > Applying patch dpkg-shlibs.patch
> > patching file debian/rules.d/debhelper.mk
> > 
> > Applying patch local-kill-locales.patch
> > patching file debian/rules
> > patching file localedata/SUPPORTED
> > 
> > Applying patch glibc-build-tools.diff
> > patching file debian/rules
> > 
> > Applying patch gcc-8-armel.diff
> > patching file debian/sysdeps/armel.mk
> > Hunk #1 FAILED at 1.
> > 1 out of 1 hunk FAILED -- rejects in file debian/sysdeps/armel.mk
> > Patch gcc-8-armel.diff does not apply (enforce with -f)
> > make: *** [debian/rules:436: stamp-dir/init-glibc] Error 1

I hope you are aware that the same issue is currently blocking the
latest version of glibc from migrating to testing as the autopkgtest of
cross-toolchain-base fails on the same error:

https://ci.debian.net/data/autopkgtest/testing/amd64/c/cross-toolchain-base/1663556/log.gz

autopkgtest [05:36:03]: test build: [---
Testing cross builds on amd64 ...
+ CROSS_ARCHS=ppc64el DEB_BUILD_OPTIONS=parallel=2 dpkg-buildpackage -d
-b --no-sign
dpkg-buildpackage: info: source package cross-toolchain-base
dpkg-buildpackage: info: source version 30
dpkg-buildpackage: info: source distribution unstable
dpkg-buildpackage: info: source changed by Matthias Klose 
 dpkg-source --before-build .
dpkg-buildpackage: info: host architecture amd64
 fakeroot debian/rules clean
linux: 4.19.12-1 / 4.18.20-2cross2
glibc: 2.28-4 / 2.28-2cross2

old linux version: 4.18.20-2 / 2
old glibc version: 2.28-2 / 2

new linux version: 4.19.12-1cross1
new glibc version: 2.28-4cross1
rm -rf linux-source-*
rm -rf glibc-*
rm -rf gcc
rm -rf binutils-*
rm -rf debian/tmp.ppc64el
rm -f debian/files debian/no-packages
rm -f debian/cross-compile
find debian -name '*~' | xargs -r rm -f
rm -f *.*deb *.changes *.buildinfo
rm -rf repackfiles tmp tmp-* debian/tmp.*
rm -rf stamp-dir/
mkdir stamp-dir/
dh_clean
 debian/rules build
linux: 4.19.12-1 / 4.18.20-2cross2
glibc: 2.28-4 / 2.28-2cross2

old linux version: 4.18.20-2 / 2
old glibc version: 2.28-2 / 2

new linux version: 4.19.12-1cross1
new glibc version: 2.28-4cross1
START stamp-dir/init-glibc
rm -rf glibc-2.28
tar -x -f  /usr/src/glibc/glibc-2.28.tar.xz
cp -a /usr/src/glibc/debian/ glibc-2.28
cd glibc-2.28 ; \
QUILT_PATCHES=/tmp/autopkgtest-lxc.3kye5ugg/downtmp/build.o4e/src/debian/patches/glibc/debian
quilt --quiltrc /dev/null push -a && \
rm -rf .pc/
Applying patch dpkg-shlibs.patch
patching file debian/rules.d/debhelper.mk

Applying patch local-kill-locales.patch
patching file debian/rules
patching file localedata/SUPPORTED

Applying patch glibc-build-tools.diff
patching file debian/rules

Applying patch gcc-8-armel.diff
patching file debian/sysdeps/armel.mk
Hunk #1 FAILED at 1.
1 out of 1 hunk FAILED -- rejects in file debian/sysdeps/armel.mk
Patch gcc-8-armel.diff does not apply (enforce with -f)
make: *** [debian/rules:436: stamp-dir/init-glibc] Error 1
dpkg-buildpackage: error: debian/rules build subprocess returned exit
status 2
autopkgtest [05:36:10]: test build: ---]

Paul



signature.asc
Description: OpenPGP digital signature

Bug#917829: python-intbitset: FTBFS when built with dpkg-buildpackage -A

[Adrian Bunk]

On Sun, Dec 30, 2018 at 07:52:26PM +, Santiago Vila wrote:
>...
> In case it helps, this stopped working in buster sometime between 2018-12-11 
> and 2018-12-23
>...

The Python3 default change 3.6 -> 3.7 migrated on 2018-12-19 to buster.

> Thanks.

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#918726: printer-driver-gutenprint: PPD files not updated during upgrade of printer-driver-gutenprint

[Helmar Gerloni]

Package: printer-driver-gutenprint
Version: 5.3.1-6
Severity: important

Dear Maintainer,

after upgrading my PC from stretch to buster (printer-driver-gutenprint from 
5.2.11-1+b2 to 5.3.1-6) most of my printers were broken.

Message in /var/log/cups/error_log:
E [08/Jan/2019:19:04:03 +0100] Brother_HL-5150D_USB: Datei 
\"/usr/lib/cups/filter/rastertogutenprint.5.2\" nicht verfügbar: No such file 
or directory
E [08/Jan/2019:19:04:03 +0100] Brother_HL-5150D_WLAN: Datei 
\"/usr/lib/cups/filter/rastertogutenprint.5.2\" nicht verfügbar: No such file 
or directory
E [08/Jan/2019:19:04:03 +0100] OKI_B4350_USB: Datei 
\"/usr/lib/cups/filter/rastertogutenprint.5.2\" nicht verfügbar: No such file 
or directory

'cups-genppdupdate -x' and restarting cups fixed the problem (-x allows update 
across major Gutenprint releases).

root@mypc:~# cups-genppdupdate -x
Correcting DefaultImageableArea from Letter to A4
Correcting DefaultPaperDimension from Letter to A4
Updated /etc/cups/ppd/Brother_HL-5150D_USB.ppd using 
gutenprint.5.3://brother-hl-5150d/expert
Correcting DefaultImageableArea from Letter to A4
Correcting DefaultPaperDimension from Letter to A4
Updated /etc/cups/ppd/Brother_HL-5150D_WLAN.ppd using 
gutenprint.5.3://brother-hl-5150d/expert
Correcting DefaultImageableArea from Letter to A4
Correcting DefaultPaperDimension from Letter to A4
Updated /etc/cups/ppd/OKI_B4350_USB.ppd using gutenprint.5.3://oki-b4350/expert
Updated 3 PPD files, 1 skipped.  Restart cupsd for the changes to take effect.

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

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

Versions of packages printer-driver-gutenprint depends on:
ii  cups 2.2.10-3
ii  cups-client  2.2.10-3
ii  cups-filters [ghostscript-cups]  1.21.6-2
ii  libc62.28-2
ii  libcups2 2.2.10-3
ii  libcupsimage22.2.10-3
ii  libgutenprint9   5.3.1-6
ii  libusb-1.0-0 2:1.0.22-2
ii  zlib1g   1:1.2.11.dfsg-1

printer-driver-gutenprint recommends no packages.

Versions of packages printer-driver-gutenprint suggests:
pn  gutenprint-doc  
pn  gutenprint-locales  

-- no debconf information

Bug#918725: grafx2 FTCBFS: hard codes the build architecture pkg-config

[Helmut Grohne]

Source: grafx2
Version: 2.5+git20181211-1
Tags: patch upstream
User: helm...@debian.org
Usertags: rebootstrap

grafx2 fails to cross build from source, because src/Makefile hard codes
plain pkg-config. For cross compilation, we need to use a
triplet-prefixed pkg-config and dh_auto_build substitutes that.
Therefore making pkg-config substitutable is sufficient for making
grafx2 cross buildable. Please consider applying the attached patch.

Helmut
--- grafx2-2.5+git20181211.orig/src/Makefile
+++ grafx2-2.5+git20181211/src/Makefile
@@ -90,6 +90,7 @@
 ifeq (default,$(origin CC))
   CC = gcc
 endif
+PKG_CONFIG ?= pkg-config
 
 # There is no uname under windows, but we can guess we are there with the COMSPEC env.var
 # Windows specific
@@ -191,14 +192,14 @@
 SDLCOPT = $(shell sdl-config --cflags)
   ifeq ($(OSX_STATIC), 1)
 SDLLOPT = $(shell sdl-config --static-libs | sed 's/-lSDL //' | sed 's/-lX[^ ]*//g' | sed 's/-L[^ ]*//g')
-SDLLIBDIR = $(shell pkg-config --variable=libdir SDL_image)
+SDLLIBDIR = $(shell $(PKG_CONFIG) --variable=libdir SDL_image)
 #SDLLOPT += $(SDLLIBDIR)/libSDL.a
 SDLLOPT += $(addsuffix .a, $(shell ../tools/osx_find_dependencies.sh $(SDLLIBDIR)/libSDL_image.dylib $(SDLLIBDIR)/libSDL_ttf.dylib | grep -v SDL | cut -d'.' -f 1))
 SDLLOPT += $(SDLLIBDIR)/libSDL_image.a
 TTFLOPT =
-SDLLOPT += $(shell pkg-config --variable=libdir SDL_ttf)/libSDL_ttf.a
+SDLLOPT += $(shell $(PKG_CONFIG) --variable=libdir SDL_ttf)/libSDL_ttf.a
   else
-SDLLOPT = $(shell sdl-config --libs) $(shell pkg-config --libs SDL_image)
+SDLLOPT = $(shell sdl-config --libs) $(shell $(PKG_CONFIG) --libs SDL_image)
   endif
 else
 # these are for use with Mac OS X native frameworks
@@ -209,32 +210,32 @@
 endif
 ifeq ($(API),sdl2)
 SDLCOPT = $(shell sdl2-config --cflags)
-#TTFCOPT = $(shell pkg-config --cflags SDL2_ttf)
+#TTFCOPT = $(shell $(PKG_CONFIG) --cflags SDL2_ttf)
   ifeq ($(OSX_STATIC), 1)
 SDLLOPT = $(shell sdl2-config --static-libs | sed 's/-lSDL2//' | sed 's/-L[^ ]*//')
-SDLLIBDIR = $(shell pkg-config --variable=libdir SDL2_image)
+SDLLIBDIR = $(shell $(PKG_CONFIG) --variable=libdir SDL2_image)
 SDLLOPT += $(SDLLIBDIR)/libSDL2.a
 # trick to get all dependencies
 SDLLOPT += $(addsuffix .a, $(shell ../tools/osx_find_dependencies.sh $(SDLLIBDIR)/libSDL2_image.dylib $(SDLLIBDIR)/libSDL2_ttf.dylib | grep -v SDL2 | cut -d'.' -f 1))
 SDLLOPT += $(SDLLIBDIR)/libSDL2_image.a
 TTFLOPT =
-SDLLOPT += $(shell pkg-config --variable=libdir SDL2_ttf)/libSDL2_ttf.a
+SDLLOPT += $(shell $(PKG_CONFIG) --variable=libdir SDL2_ttf)/libSDL2_ttf.a
   else
-SDLLOPT = $(shell sdl2-config --libs) $(shell pkg-config --libs SDL2_image)
+SDLLOPT = $(shell sdl2-config --libs) $(shell $(PKG_CONFIG) --libs SDL2_image)
 SDLLOPT += -Wl,-framework,Cocoa
-TTFLOPT = $(shell pkg-config --libs SDL2_ttf)
+TTFLOPT = $(shell $(PKG_CONFIG) --libs SDL2_ttf)
   endif
 endif
 
 # these are for use with macports
-LUAPKG := $(shell for p in lua lua5.3 lua-5.3 lua53 lua5.2 lua-5.2 lua52 lua5.1 lua-5.1 lua51 ; do pkg-config --exists $$p && echo $$p && break ; done)
+LUAPKG := $(shell for p in lua lua5.3 lua-5.3 lua53 lua5.2 lua-5.2 lua52 lua5.1 lua-5.1 lua51 ; do $(PKG_CONFIG) --exists $$p && echo $$p && break ; done)
 ifneq ($(LUAPKG), )
 ifeq ($(OSX_STATIC),1)
-  LUACOPT = $(shell pkg-config $(LUAPKG) --cflags | sed 's/-I/-idirafter/')
-  LUALOPT = $(shell pkg-config $(LUAPKG) --variable=libdir)/liblua.a
+  LUACOPT = $(shell $(PKG_CONFIG) $(LUAPKG) --cflags | sed 's/-I/-idirafter/')
+  LUALOPT = $(shell $(PKG_CONFIG) $(LUAPKG) --variable=libdir)/liblua.a
 else
-  LUACOPT = $(shell pkg-config $(LUAPKG) --cflags)
-  LUALOPT = $(shell pkg-config $(LUAPKG) --libs)
+  LUACOPT = $(shell $(PKG_CONFIG) $(LUAPKG) --cflags)
+  LUALOPT = $(shell $(PKG_CONFIG) $(LUAPKG) --libs)
 endif
 else
 # these are for use with Mac OS X native frameworks
@@ -342,8 +343,8 @@
   LUALOPT =
 else
   LUAPKG=lua
-  LUACOPT = -D__ENABLE_LUA__ $(shell pkg-config $(LUAPKG) --cflags)
-  LUALOPT = $(shell pkg-config $(LUAPKG) --libs)
+  LUACOPT = -D__ENABLE_LUA__ $(shell $(PKG_CONFIG) $(LUAPKG) --cflags)
+  LUALOPT = $(shell $(PKG_CONFIG) $(LUAPKG) --libs)
 endif
 COPT = -W -Wall -g $(shell sdl-config --cflags) $(TTFCOPT) -I/boot/common/include $(LUACOPT)
 COPT += -DENABLE_FILENAMES_ICONV
@@ -436,9 +437,9 @@
 ifdef WIN32CROSS
   LUACOPT = -I../3rdparty/usr/include
 else
-  LUAPKG := $(shell for p in lua5.3 lua-5.3 lua53 lua5.2 lua-5.2 lua52 lua5.1 lua-5.1 lua51 lua ; do pkg-config --exists $$p && echo $$p && break ; done)
-  LUACOPT = $(shell pkg-config $(LUAPKG) --cflags)
-  LUALOPT = $(shell pkg-config $(LUAPKG) --libs)
+  LUAPKG := $(shell for p in lua5.3 lua-5.3 lua53 lua5.2 lua-5.2 lua52 lua5.1 lua-5.1 lua51 lua ; do 

Bug#918631: [Python-modules-team] Bug#918631: Bug#918631: python-pyramid: autopkgtest regression

[eamanu15]

Hi Paul,

El mar., 8 de ene. de 2019 a la(s) 16:27, Paul Gevers (elb...@debian.org)
escribió:

> Hi eamanu15,
>
> On 08-01-2019 13:24, eamanu15 wrote:
> > I am not familiar with autopkgtest.
>
> But your package has one.
>
> > But reading
> > https://people.debian.org/~mpitt/autopkgtest/README.package-tests.html
>
> Please don't use this outdated information. Use
>
> https://salsa.debian.org/ci-team/autopkgtest/raw/master/doc/README.package-tests.rst


Thanks

>
>
> > the $AUTOPKGTEST_TMP variable start empty and I think that we have to
> > copy the test code there. something like here:
> >
> >
> https://salsa.debian.org/python-team/modules/sphinx/blob/debian/master/debian/tests/python-sphinx#L3
> >
> > If this sound correct, tonight I will prepare a MR.
>
> Most tests don't need to copy anything and can just run in place. Tests
> that need to write stuff in-place should copy first.
>
> I have no clue if your suggestion is going to fix anything, the
> autopkgtest has run successfully until the latest version.
>
> Paul
>
But the CI log seems like there is not a __init__.py (maybe not.)

Regards


> ___
> Python-modules-team mailing list
> python-modules-t...@alioth-lists.debian.net
>
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/python-modules-team



-- 
Arias Emmanuel
http://eamanu.com
Github/Gitlab; @eamanu
Debian: @eamanu-guest