Bug#892523: calibre: please explicitly add the libusb-1.0-0-dev build dependency

[Norbert Preining]

> Hence, please explicitly add libusb-1.0-0-dev to the build dependencies,
> to make sure it is always installed.

Thanks, added in the git repo, will be in the next upload.

Best

Norbert

--
PREINING Norbert   http://www.preining.info
Accelia Inc. +JAIST +TeX Live +Debian Developer
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Bug#892525: cups-daemon: Cannot print with HPLIP backend

[intrigeri]

Package: cups-daemon
Version: 2.2.6-5
Severity: normal

Hi,

for now this bug report is mostly a note to myself (and to whoever
wants to help investigating/fixing this problem).

A few days ago on an up-to-date sid system I was unable to print with
the HPLIP backend. In the Journal I saw:

  /hpfax[4306]: [4306]: error: Failed to create /var/spool/cups/tmp/.hplip

I don't know yet if this issue is AppArmor-related and will
investigate once I have access to that printer again in a few days.
/usr/lib/cups/backend/hpfax is supposed to be confined under the
third_party child profile which allows any "file" operation so in
theory AppArmor cannot trigger the above log line.

(Probably unrelated, on cupsd startup I see:

  audit[14628]: AVC apparmor="DENIED" operation="capable"
  profile="/usr/sbin/cupsd" pid=14628 comm="cupsd" capability=12
  capname="net_admin"

I'll file a dedicated bug (+patch) for that one once I've confirmed
it's orthogonal to the HPLIP issue.)

Cheers,
-- 
intrigeri

Bug#889406: Pending fixes for bugs in the bnd package

[pkg-java-maintainers]

tag 889406 + pending
thanks

Some bugs in the bnd package are closed in revision
07d94cd20778a1efa2303043aed55835650a7c6a in branch 'master' by
殷啟聰 | Kai-Chung Yan

The full diff can be seen at
https://anonscm.debian.org/cgit/pkg-java/bnd.git/commit/?id=07d94cd

Commit message:

d/control: Remove Damien Raude-Morvan from Uploaders (Closes: #889406)

Bug#875336: FTBFS with Java 9: _ as identifier

[殷啟聰 | Kai-Chung Yan]

I recently updated the package to 3.5.0 just to find out the current Groovy 
(2.4.8) does not support Java 9 [1]. Groovy was used by the bootstrapping 
script. Setting source & target to Java 8 doesn't solve the problem either.

[1]: https://github.com/gradle/gradle/issues/2995



signature.asc
Description: OpenPGP digital signature

Bug#892524: ITP: r-bioc-pcamethods -- BioConductor collection of PCA methods

[Andreas Tille]

Package: wnpp
Severity: wishlist
Owner: Andreas Tille 

* Package name: r-bioc-pcamethods
  Version : 1.70.0
  Upstream Author : Henning Redestig 
* URL : https://bioconductor.org/packages/pcaMethods/
* License : GPL
  Programming Lang: GNU R
  Description : BioConductor collection of PCA methods
 Provides Bayesian PCA, Probabilistic PCA, Nipals PCA,
 Inverse Non-Linear PCA and the conventional SVD PCA. A cluster
 based method for missing value estimation is included for
 comparison. BPCA, PPCA and NipalsPCA may be used to perform PCA
 on incomplete data as well as for accurate missing value
 estimation. A set of methods for printing and plotting the
 results is also provided. All PCA methods make use of the same
 data structure (pcaRes) to provide a common interface to the
 PCA results. Initiated at the Max-Planck Institute for
 Molecular Plant Physiology, Golm, Germany.


Remark: This package is needed in BioLinux and thus a sensible target for
the Debian Med team.  The actual packaging will be done by the r-pkg team
at
https://salsa.debian.org/r-pkg-team/r-bioc-pcamethods

Bug#892523: calibre: please explicitly add the libusb-1.0-0-dev build dependency

[Pino Toscano]

Source: calibre
Version: 3.19.0+dfsg-1
Severity: minor
Tags: patch

Hi,

calibre uses libusb-1.0 for one extension; though, libusb-1.0-0-dev is
indirectly pulled by libmtp-dev on Linux, while it might not on other
architectures.

Hence, please explicitly add libusb-1.0-0-dev to the build dependencies,
to make sure it is always installed.

Thanks,
-- 
Pino
--- a/debian/control
+++ b/debian/control
@@ -47,6 +47,7 @@ Build-Depends: cdbs (>= 0.4.43),
  libmtdev-dev [linux-any],
  libegl1-mesa-dev,
  libchm-dev,
+ libusb-1.0-0-dev,
  xdg-utils
 Maintainer: Norbert Preining 
 Uploaders: Martin Pitt 

Bug#892522: ITP: r-bioc-bitseq -- transcript expression inference and analysis for RNA-seq data

[Andreas Tille]

Package: wnpp
Severity: wishlist
Owner: Andreas Tille 

* Package name: r-bioc-bitseq
  Version : 1.22.0
  Upstream Author : Peter Glaus, Antti Honkela and Magnus Rattray
* URL : https://bioconductor.org/packages/BitSeq/
* License : Artistic-2.0
  Programming Lang: GNU R
  Description : transcript expression inference and analysis for RNA-seq 
data
 The BitSeq package is targeted for transcript expression
 analysis and differential expression analysis of RNA-seq data
 in two stage process. In the first stage it uses Bayesian
 inference methodology to infer expression of individual
 transcripts from individual RNA-seq experiments. The second
 stage of BitSeq embraces the differential expression analysis
 of transcript expression. Providing expression estimates from
 replicates of multiple conditions, Log-Normal model of the
 estimates is used for inferring the condition mean transcript
 expression and ranking the transcripts based on the likelihood
 of differential expression.


Remark: This package is needed in BioLinux and thus a sensible target for
the Debian Med team.  The actual packaging will be done by the r-pkg team
at
https://salsa.debian.org/r-pkg-team/r-bioc-bitseq

Bug#892515: meson: please make the generated pkgconfig files reproducible

[Chris Lamb]

Hi,

> Patch attached.

Updated patch attached.


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
From 61bf45705cdcb96e4963d4f4e4e429238a6f7768 Mon Sep 17 00:00:00 2001
From: Chris Lamb 
Date: Fri, 9 Mar 2018 21:57:01 -0800
Subject: [PATCH] Make the generated pkgconfig files reproducible.

Whilst working on the Reproducible Builds effort [0], we noticed
that meson creates non-reproducible pkgconfig files as it iterates
over Python sets.

This was originally filed in Debian as #892515 [1].

 [0] https://reproducible-builds.org/
 [1] https://bugs.debian.org/892515
---
 mesonbuild/modules/pkgconfig.py | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/mesonbuild/modules/pkgconfig.py b/mesonbuild/modules/pkgconfig.py
index 5573a2e41..c89de24c5 100644
--- a/mesonbuild/modules/pkgconfig.py
+++ b/mesonbuild/modules/pkgconfig.py
@@ -167,12 +167,12 @@ def generate_pkgconfig_file(self, state, deps, subdirs, name, description,
 ofile.write('URL: %s\n' % url)
 ofile.write('Version: %s\n' % version)
 if len(deps.pub_reqs) > 0:
-ofile.write('Requires: {}\n'.format(' '.join(deps.pub_reqs)))
+ofile.write('Requires: {}\n'.format(' '.join(sorted(deps.pub_reqs
 if len(deps.priv_reqs) > 0:
 ofile.write(
-'Requires.private: {}\n'.format(' '.join(deps.priv_reqs)))
+'Requires.private: {}\n'.format(' '.join(sorted(deps.priv_reqs
 if len(conflicts) > 0:
-ofile.write('Conflicts: {}\n'.format(' '.join(conflicts)))
+ofile.write('Conflicts: {}\n'.format(' '.join(sorted(conflicts
 
 def generate_libs_flags(libs):
 msg = 'Library target {0!r} has {1!r} set. Compilers ' \
@@ -201,9 +201,9 @@ def generate_libs_flags(libs):
 yield '-l%s' % lname
 
 if len(deps.pub_libs) > 0:
-ofile.write('Libs: {}\n'.format(' '.join(generate_libs_flags(deps.pub_libs
+ofile.write('Libs: {}\n'.format(' '.join(sorted(generate_libs_flags(deps.pub_libs)
 if len(deps.priv_libs) > 0:
-ofile.write('Libs.private: {}\n'.format(' '.join(generate_libs_flags(deps.priv_libs
+ofile.write('Libs.private: {}\n'.format(' '.join(sorted(generate_libs_flags(deps.priv_libs)
 ofile.write('Cflags:')
 for h in subdirs:
 ofile.write(' ')

Bug#821111: nginx, unix sockets and graceful/fast stop policy

[Maxim Nikulin]

On Sat, 16 Jul 2016 18:07:22 -0700 Michael Lustfield 
 wrote:

After looking at this patch, I see that it was resolved in a previous commit.
Commit: caee1c2a8790f3f5ad1e8f277d0426189a43558f


Sorry, that commit does not fix the problem with non-removed unix 
sockets and there is some confusion with patches attached to the bug report.


+ExecStop=-/sbin/start-stop-daemon --quiet --stop --retry QUIT/5 
--pidfile /run/nginx.pid


line causes graceful stop, survived sockets, and so failure to start 
next time. If the intention is fast shutdown as suggested in [1] then 
stop retry schedule should be TERM/5. STOP_SCHEDULE in 
debian/nginx-common.nginx.init should be changed accordingly e.g. to 
TERM/10/KILL/5. There should be no QUIT in both cases. Also there is 
some mess in comments in the file debian/nginx-common.nginx.service and 
in the changelog.Debian and the commit messages, nobody sends the namely 
SIGSTOP signal.


Sorry, I do not provide patch due to I am a bit lazy to setup 
environment and check that patched package will be successfully built.


I was considering an additional hook in init scripts for removing 
sockets after graceful stop. There are might be rare cases when it is 
desirable to wait till finishing of some long transaction so graceful 
shutdown is preferable. Unfortunately I do not see an easy way to get 
list of stale sockets from the init scripts.


[1] https://trac.nginx.org/nginx/ticket/753#comment:5

Bug#892520: libpodofo: CVE-2018-8000 CVE-2018-8001 CVE-2018-8002

[Luciano Bello]

Package: libpodofo
X-Debbugs-CC: t...@security.debian.org
Severity: grave
Tags: security

Hi,

the following vulnerabilities were published for libpodofo.

CVE-2018-8000[0]:
| In PoDoFo 0.9.5, there exists a heap-based buffer overflow
| vulnerability in PoDoFo::PdfTokenizer::GetNextToken() in
| PdfTokenizer.cpp, a related issue to CVE-2017-5886. Remote attackers
| could leverage this vulnerability to cause a denial-of-service or
| potentially execute arbitrary code via a crafted pdf file.

CVE-2018-8001[1]:
| In PoDoFo 0.9.5, there exists a heap-based buffer over-read
| vulnerability in UnescapeName() in PdfName.cpp. Remote attackers could
| leverage this vulnerability to cause a denial-of-service or possibly
| unspecified other impact via a crafted pdf file.

CVE-2018-8002[2]:
| In PoDoFo 0.9.5, there exists an infinite loop vulnerability in
| PdfParserObject::ParseFileComplete() in PdfParserObject.cpp which may
| result in stack overflow. Remote attackers could leverage this
| vulnerability to cause a denial-of-service or possibly unspecified
| other impact via a crafted pdf file.

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2018-8000
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-8000
[1] https://security-tracker.debian.org/tracker/CVE-2018-8001
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-8001
[2] https://security-tracker.debian.org/tracker/CVE-2018-8002
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-8002

Please adjust the affected versions in the BTS as needed.

Bug#892309: groff: crash (SIGSYS) when running `man man | head -n1`

[Paul Wise]

On Thu, 2018-03-08 at 13:38 +, Colin Watson wrote:

> Hmm, this doesn't seem to show a SIGSYS, and man exited 0.

I added some debugging to groff and looked at the code.

It seems that groff passes on a SIGPIPE it receives to its children via
kill(pids[j], SIGPIPE) but man-db does not allow it to do that due to
the seccomp filter. The SIGPIPE seems to be sent to man-db initially.

I managed to workaround the issue with a simple patch to man-db:

--- a/lib/sandbox.c
+++ b/lib/sandbox.c
@@ -257,6 +257,7 @@ scmp_filter_ctx make_seccomp_filter (int
SC_ALLOW ("exit");
SC_ALLOW ("exit_group");
SC_ALLOW ("futex");
+   SC_ALLOW ("kill");
SC_ALLOW ("get_robust_list");
SC_ALLOW ("get_thread_area");
SC_ALLOW ("getegid");

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#892519: ITP: maven-dependency-tree-2 -- Tree-based API for resolution of Maven project dependencies

[殷啟聰 | Kai-Chung Yan]

Package: wnpp
Severity: wishlist

* Package Name : maven-dependency-tree-2
* Version : 2.2-1
* License : Apache-2.0
* Programming Lang: Java
* Description : Tree-based API for resolution of Maven project dependencies
* VCS : https://anonscm.debian.org/git/pkg-java/maven-dependency-tree-2.git

This package builds the following binary package:

* libmaven-dependency-tree-2-java

This is a 2.x version of "maven-dependency-tree" [1]. The latest version of 
"maven-bundle-plugin" [2] is only compatible with this version, hence the new 
package.

This package may be removed once "maven-bundle-plugin" fixes the issue [3].

[1]: https://tracker.debian.org/pkg/maven-dependency-tree
[2]: https://tracker.debian.org/pkg/maven-bundle-plugin
[3]: https://issues.apache.org/jira/browse/FELIX-5795



signature.asc
Description: OpenPGP digital signature

Bug#892144: lintian: check for relationships with packages that provide mail-transport-agent but don't use m-t-a

[Chris Lamb]

tags 892144 + pending
thanks

Thanks for the clarification. Implemented in Git, pending upload:

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


Regards,

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

Bug#860495: chromium: cannot sign into Ankama Zendesk

[Michael Gilbert]

control: tag -1 moreinfo

Upstream fixed a memory leak in chrome 65.  Could you test whether
that fixes this problem?

Best wishes,
Mike

Bug#891939: ITP: python-gitlab -- GitLab API client library for Python

[Paul Wise]

On Fri, 02 Mar 2018 20:20:15 + Federico Ceratto wrote:

> This package is meant to replace the current package with same name

The pyapi-gitlab upstream responded to my email and mentioned that he
doesn't have time to maintain it and suggested that it would be fine
for Debian to switch to python-github.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#892144: lintian: check for relationships with packages that provide mail-transport-agent but don't use m-t-a

[Paul Wise]

On Fri, 2018-03-09 at 16:44 +, Chris Lamb wrote:

> I'm a little bit lost by the grammar here. Can you provide a few
> examples of good (and bad) dependencies so I'm 100% clear what you
> mean?

This test should check Depends, Recommends, Suggests.

Bad:

citadel-server
courier-mta
dma
esmtp-run
exim4
exim4-daemon-heavy
exim4-daemon-light
masqmail
msmtp-mta
nullmailer
nullmailer
opensmtpd
postfix
qmail-run
sendmail-bin
ssmtp

Good:

default-mta | exim4 | mail-transport-agent
default-mta | postfix | mail-transport-agent
default-mta | mail-transport-agent

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#888531: transition: ruby2.5 - binNMU round #5, and next steps

[Andreas Beckmann]

On Fri, 9 Mar 2018 11:53:17 -0300 Antonio Terceiro 
wrote:
> ruby-pgplot: it's in contrib and has a dependency on a non-free package,
> so it can't be built on buildds. I could do binary uploads myself now,
> or ask someone who cares about it to do that, but then when it's time to
> drop ruby2.3 I would need to do that again, and I would prefer to do it
> just once. I just reported a serious bugs about this.

If you have the infrastructure ready to do contrib/non-free binNMUs (and
some experience with it), this is not really much work. Uploaded a +b1
binNMU. Please ping me once you need the ruby2.5-only binNMU.


Andreas

PS: I don't care about this particular package, but I do care about a
different non-free/contrib software stack ;-)

Bug#892518: zerofree: new upstream version

[Christoph Anton Mitterer]

Package: zerofree
Version: 1.0.4-1
Severity: wishlist


Hi.

There seems to be a new upstream version (1.1.1).

Cheers,
Chris.

Bug#892063: cpputest: FTBFS on hppa - __canonicalize_funcptr_for_compare (0xdeadbeef)

[John David Anglin]

On 2018-03-09 7:59 PM, Raphael Hertzog wrote:

Thanks for the report, I forwarded it upstream but it seems strange that
hppa is the only architecture with such a problem. Is there something
special about this architecture that could explain this singularity?
Yes.  Function pointers on hppa differ from all other architectures.  
Firstly, there is a
bit in function pointers that determines whether or not the pointer 
points directly to
the function or a function descriptor.  The former mode is only used in 
a handful of
applications that don't link against shared libraries.  Secondly, the 
hppa runtime didn't
require that there be an official procedure descriptor for functions 
called indirectly.
As a result, there can be multiple function descriptors for any given 
function.  Thus,
one can't just compare function pointers directly.  One has to look into 
the function
descriptor and if necessary call into the dynamic linker to resolve the 
function's
address in the descriptor.  Once the descriptors are resolved, the 
pointers from the

descriptors can be compared.  The whole process is pretty horrible.

I applied a patch to gcc-8 to fix the "0xdeadbeef" problem.  It adds a 
check to ensure
that the pointer points to read accessible memory.  It also checks that 
the address in
the descriptor is read accessible.  Will backport to 7 and 6 when I get 
a chance.


Regards,
Dave Anglin

--
John David Anglin  dave.ang...@bell.net

Bug#876426: A patch with a gist (JDK only)

[Raymond Rakesh Chetty]

Might not be quite right, but maybe mergeworthy? (See the linked patch)

https://gist.github.com/RayWithAnA/f5ce4e673d947761d31e99006fadb813

Are those the right instructions? If not let me know. Not sure I saw a better 
explanation.

Best,
Raymond
raymond.che...@berkeley.edu

Bug#892517: linux: swiotlb coherent allocation failed

[Michael Gilbert]

package: src:linux
version: 4.15.4-1
severity: minor
forwarded: https://lkml.org/lkml/2017/12/18/1259

This is a message that shows up a lot in dmesg starting with linux
4.15.  See LKML discussion and Ubuntu bug:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1749202

Best wishes,
Mike

Bug#891956: Your mail

[William L. DeRieux IV]

On Fri, 9 Mar 2018 20:07:32 -0500 "William L. DeRieux IV" wrote:
> after editing /etc/eclipse.ini
> and adding -debug to it
>
> I get the following output (when running eclipse):
> -
> OpenJDK 64-Bit Server VM warning: ignoring option MaxPermSize=256m;
> support was removed in 8.0
> Install location:
>     file:/usr/lib/eclipse/
> Configuration file:
>     file:/usr/lib/eclipse/configuration/config.ini loaded
> Configuration location:
> 
file:/home/william/.eclipse/org.eclipse.platform_3.8_155965261/configuration/

> Configuration file:
> 
file:/home/william/.eclipse/org.eclipse.platform_3.8_155965261/configuration/config.ini 


> not found or not read
> Shared configuration location:
>     file:/usr/lib/eclipse/configuration/
> Framework located:
> file:/usr/lib/eclipse/plugins/org.eclipse.osgi_3.8.1.dist.jar
> Framework classpath:
> Splash location:
> /usr/lib/eclipse//plugins/org.eclipse.platform_3.8.1.dist/splash.bmp
> -
>
> And the error message written to the log file:
>
> -
> !SESSION Fri Mar 09 20:00:00 EST 2018
> !ENTRY org.eclipse.equinox.launcher 4 0 2018-03-09 20:00:00.374
> !MESSAGE Exception launching the Eclipse Platform:
> !STACK
> java.lang.ClassNotFoundException:
> org.eclipse.core.runtime.adaptor.EclipseStarter
>     at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
>     at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
>     at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
>     at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:626)
>     at org.eclipse.equinox.launcher.Main.basicRun(Main.java:584)
>     at org.eclipse.equinox.launcher.Main.run(Main.java:1438)
>     at org.eclipse.equinox.launcher.Main.main(Main.java:1414)
>
>
> -
>
> It seems that this error is happening because the framework's class path
> is not being properly set (hence it can't find the class).
>
>
>


I resolved this issue (on my system) by reinstalling libequinox

$ sudo apt-get install --reinstall libequinox-osgi-java

The debug output claimed that the framework has been found, but this was 
a lie since:

/usr/lib/eclipse/plugins/org.eclipse.osgi_3.8.1.dist.jar was missing.

Maybe there needs to be better sanity checking here.

Bug#892516: mg.1: Some cleaning of the manual

[Bjarni Ingi Gislason]

Package: mg
Version: 20171014-1
Severity: minor
Tags: patch

Dear Maintainer,

Input file is mg.1

Test nr. 2:
Enable and fix warnings from 'test-groff'.
Input file is /tmp/mg.1

git/groff/build/tmac/doc.tmac:705: backtrace
git/groff/build/tmac/doc.tmac:77: backtrace: macro 'doc-parse-args'
git/groff/build/tmac/doc.tmac:705: backtrace: macro 'doc-enclose-string'
git/groff/build/tmac/doc.tmac:646: backtrace: macro 'Dq'
troff: :1066: warning: escape character ignored before ';'
git/groff/build/tmac/doc.tmac:705: backtrace
git/groff/build/tmac/doc.tmac:79: backtrace: macro 'doc-parse-args'
git/groff/build/tmac/doc.tmac:705: backtrace: macro 'doc-enclose-string'
git/groff/build/tmac/doc.tmac:646: backtrace: macro 'Dq'
troff: :1066: warning: escape character ignored before ';'
git/groff/build/tmac/doc.tmac:705: backtrace: string 'doc-arg1'
git/groff/build/tmac/doc.tmac:1112: backtrace: macro 'doc-get-arg-type*'
git/groff/build/tmac/doc.tmac:84: backtrace: macro 'doc-parse-args'
git/groff/build/tmac/doc.tmac:705: backtrace: macro 'doc-enclose-string'
git/groff/build/tmac/doc.tmac:646: backtrace: macro 'Dq'
troff: :1066: warning: escape character ignored before ';'
git/groff/build/tmac/doc.tmac:705: backtrace: string 'doc-arg1'
git/groff/build/tmac/doc.tmac:1118: backtrace: macro 'doc-get-arg-type*'
git/groff/build/tmac/doc.tmac:84: backtrace: macro 'doc-parse-args'
git/groff/build/tmac/doc.tmac:705: backtrace: macro 'doc-enclose-string'
git/groff/build/tmac/doc.tmac:646: backtrace: macro 'Dq'
troff: :1066: warning: escape character ignored before ';'
git/groff/build/tmac/doc.tmac:705: backtrace: string 'doc-arg1'
git/groff/build/tmac/doc.tmac:731: backtrace: while loop
git/groff/build/tmac/doc.tmac:736: backtrace: macro 'doc-enclose-string'
git/groff/build/tmac/doc.tmac:646: backtrace: macro 'Dq'
troff: :1066: warning: escape character ignored before ';'
git/groff/build/tmac/doc.tmac:705: backtrace: string 'doc-arg1'
git/groff/build/tmac/doc.tmac:733: backtrace: while loop
git/groff/build/tmac/doc.tmac:736: backtrace: macro 'doc-enclose-string'
git/groff/build/tmac/doc.tmac:646: backtrace: macro 'Dq'
troff: :1066: warning: escape character ignored before ';'
git/groff/build/tmac/doc.tmac:705: backtrace: string 'doc-str-dpr'
git/groff/build/tmac/doc.tmac:252: backtrace: macro 'doc-do-2'
git/groff/build/tmac/doc.tmac:761: backtrace: macro 'doc-enclose-string'
git/groff/build/tmac/doc.tmac:646: backtrace: macro 'Dq'
troff: :1066: warning: escape character ignored before ';'

chk_manuals: Output is from: test-groff -Tutf8 -b -e -mandoc -rF0 -t -w w -z 




#

Test nr. 8:
Protect a full stop (.) with "\&", if it has a blank (white-space) in front
of or (ignoring transparent characters to the full stop) after it, and it does
not mean an end of a sentence.

35:backwards from the end of the file i.e. +-1 will be the last
64:throwaway; i.e. the user will not be prompted to save changes when
425:words; i.e. convert the first character of the word to
593:Unbind a key from the global (fundamental) key map; i.e. set it to 'rescan'.
756:Insert the next character verbatim into the current buffer; i.e. ignore
1043:represents the name of the terminal type; e.g. if the terminal type

#

Test nr. 17:
Change - to \- if it means a minus sign.

35:backwards from the end of the file i.e. +-1 will be the last
36:line of the file, +-2 will be second last, and so on.

#

Test nr. 28:

The "indicator" is an "end-of-sentence character" (.!?).

  The space between sentences in "roff" is two spaces.
Better is to begin each sentence on a new line
to avoid different writers' conventions.
Begin each subordinate clause on a new line for the benefits of
patches.

  References:

  1) man-pages(7) from package "man-pages" or
"www.kernel.org/doc/man-pages" section 7 or
"man7.org/linux/man-pages/man7/man-pages.7.html":

"New sentences should be started on new lines.
This makes it easier to see the effect of patches,
which often operate at the level of individual sentences."

  2) groff_diff(7) in package "groff":

"In GNU troff, as in UNIX troff, you should always follow a sentence
with either a newline or two spaces."

  3) "info groff":

  Search for the word "sentence" in the output to get more hints about input
conventions.

35:backwards from the end of the file i.e. +-1 will be the last
64:throwaway; i.e. the user will not be prompted to save changes when
425:words; i.e. convert the first character of the word to
550:Invoke an extended command; i.e. M-x.
593:Unbind a key from the global (fundamental) key map; i.e. set it to 'rescan'.
756:Insert the next character verbatim into the current buffer; i.e. ignore
1043:represents the name of the terminal type; e.g. if the terminal type

#

Test nr. 30:
Surround a block of comments with the macros ".ig" and "..".
The .\" at the beginning of each line is then not needed.
Makes it easier to add and remove text and adjust lenght of lines.

NO PATCH

1:.\"   $OpenBSD: mg.1,v 1.105 

Bug#892515: meson: please make the generated pkgconfig files reproducible

[Chris Lamb]

forwarded 892515 https://github.com/mesonbuild/meson/pull/3211
thanks

I've forwarded this upstream here:

  https://github.com/mesonbuild/meson/pull/3211


Regards,

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

Bug#892515: meson: please make the generated pkgconfig files reproducible

[Chris Lamb]

Source: meson
Version: 0.45.0-1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: randomness toolchain
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

Whilst working on the Reproducible Builds effort [0], we noticed
that meson creates non-reproducible pkgconfig files as it iterates
over Python sets.

Patch attached.

 [0] https://reproducible-builds.org/


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
diff --git a/mesonbuild/modules/pkgconfig.py b/mesonbuild/modules/pkgconfig.py
index 5573a2e..9b608e9 100644
--- a/mesonbuild/modules/pkgconfig.py
+++ b/mesonbuild/modules/pkgconfig.py
@@ -90,11 +90,11 @@ class DependenciesHelper:
 return processed_libs, processed_reqs, processed_cflags
 
 def remove_dups(self):
-self.pub_libs = list(set(self.pub_libs))
-self.pub_reqs = list(set(self.pub_reqs))
-self.priv_libs = list(set(self.priv_libs))
-self.priv_reqs = list(set(self.priv_reqs))
-self.cflags = list(set(self.cflags))
+self.pub_libs = list(sorted(set(self.pub_libs)))
+self.pub_reqs = list(sorted(set(self.pub_reqs)))
+self.priv_libs = list(sorted(set(self.priv_libs)))
+self.priv_reqs = list(sorted(set(self.priv_reqs)))
+self.cflags = list(sorted(set(self.cflags)))
 
 # Remove from pivate libs/reqs if they are in public already
 self.priv_libs = [i for i in self.priv_libs if i not in self.pub_libs]

Bug#891956: (no subject)

[William L. DeRieux IV]

after editing /etc/eclipse.ini
and adding -debug to it

I get the following output (when running eclipse):
-
OpenJDK 64-Bit Server VM warning: ignoring option MaxPermSize=256m; 
support was removed in 8.0

Install location:
    file:/usr/lib/eclipse/
Configuration file:
    file:/usr/lib/eclipse/configuration/config.ini loaded
Configuration location:
file:/home/william/.eclipse/org.eclipse.platform_3.8_155965261/configuration/
Configuration file:
file:/home/william/.eclipse/org.eclipse.platform_3.8_155965261/configuration/config.ini 
not found or not read

Shared configuration location:
    file:/usr/lib/eclipse/configuration/
Framework located:
    file:/usr/lib/eclipse/plugins/org.eclipse.osgi_3.8.1.dist.jar
Framework classpath:
Splash location:
/usr/lib/eclipse//plugins/org.eclipse.platform_3.8.1.dist/splash.bmp
-

And the error message written to the log file:

-
!SESSION Fri Mar 09 20:00:00 EST 2018
!ENTRY org.eclipse.equinox.launcher 4 0 2018-03-09 20:00:00.374
!MESSAGE Exception launching the Eclipse Platform:
!STACK
java.lang.ClassNotFoundException: 
org.eclipse.core.runtime.adaptor.EclipseStarter

    at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
    at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:626)
    at org.eclipse.equinox.launcher.Main.basicRun(Main.java:584)
    at org.eclipse.equinox.launcher.Main.run(Main.java:1438)
    at org.eclipse.equinox.launcher.Main.main(Main.java:1414)


-

It seems that this error is happening because the framework's class path
is not being properly set (hence it can't find the class).

Bug#892063: cpputest: FTBFS on hppa - __canonicalize_funcptr_for_compare (0xdeadbeef)

[Raphael Hertzog]

Control: forwarded -1 https://github.com/cpputest/cpputest/issues/1145

Hi,

On Sun, 04 Mar 2018, John David Anglin wrote:
> It looks like __canonicalize_funcptr_for_compare needs to be improved to
> prevent access fault on garbage pointer, but maybe there's something that
> can be done in cpputest.

Thanks for the report, I forwarded it upstream but it seems strange that
hppa is the only architecture with such a problem. Is there something
special about this architecture that could explain this singularity?

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

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

Bug#888955: open-vm-tools.service 10.2.0 does not start on boot on jessie/stretch/etc

[Michael Biebl]

Am 10.03.2018 um 01:39 schrieb Bernd Zeimetz:
> Hi,
> 
> because it needs to run before cloud-init. 

Why does it need to run before cloud-init i.e. why does cloud-init need
open-vm-tools?
Feel free to point me to the relevant parts of the bug report which
explain that.

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



signature.asc
Description: OpenPGP digital signature

Bug#892488: pcre2: FTBFS on mips* - test failures

[Jonathan Nieder]

severity 892488 serious
tags 892488 + upstream pending
quit

Matthew Vernon wrote:
> Hi,
>
>> This is blocking git updates from migrating to testing
>> (https://qa.debian.org/excuses.php?package=git), so my preference
>> would be removing "mips mipsel mips64el" from the list of JIT arches
>> for now as a stopgap.
>
> Done and uploaded, so I've downgraded this bug to important.

Thanks.  This FTBFS bug is still serious, but even better, you can
close it.

I don't see the new version at
https://salsa.debian.org/debian/pcre2/commits/master. Is it on a
different branch?

Jonathan

Bug#887323: dewalls i386 test failure

[Wookey]

On 2018-03-09 19:24 +, Philip Schuchardt wrote:
> Wow, we were using long doubles before. I don't think we need that much
> precision for cave survey. In catch there is Approx() that should take care of
> floating point comparison correctly.

Yes. Catch has approx and margin and epsilon which let us specify
accuracy/precision for the tests, but don't solve the throw/no-throw
issue because that's a binary test on the catch side - all the
thresholds are entirely on the dewalls side.

In the meantime the bodge in 1.0.0+ds1-5 has fixed the builds on all arches:
https://buildd.debian.org/status/package.php?p=dewalls

Wookey
-- 
Principal hats:  Linaro, Debian, Wookware, ARM
http://wookware.org/


signature.asc
Description: PGP signature

Bug#887323: dewalls i386 test failure

[Philip Schuchardt]

So we need to fixed the comparisons on the dewalls library.

On Fri, Mar 9, 2018 at 2:24 PM Philip Schuchardt  wrote:

> Wow, we were using long doubles before. I don't think we need that much
> precision for cave survey. In catch there is Approx() that should take care
> of floating point comparison correctly.
>
> On Fri, Mar 9, 2018 at 11:30 AM Wookey  wrote:
>
>> A bit of research tells that using 'long double' causes 80-bit fp on x86
>> (i386 and amd64), as opposed to the 64-bit IEE 754 fp representation used
>> on other platforms, which is what you get if you specify double.
>>
>> So I tried changing the angle.{cpp.h} code to use double instead of long
>> double.
>>
>> That doesn't fix the problrematic tests, but does cause another 43 to
>> fail:
>> test cases:   8 |   3 passed |  5 failed
>> assertions: 202 | 155 passed | 47 failed
>>
>> They all fail equality tests, despite them clearly being 'equal
>> enough' for our purposes.
>>
>> e.g.
>> /home/wookey/dewalls-1.0.0+ds1/test/azimuthparsingtests.cpp:31: FAILED:
>>   CHECK( WallsSurveyParser("5:4").azimuth(Angle::Degrees) == UAngle(5 + 4
>> / 60.0, Angle::Degrees) )
>> with expansion:
>>   5.06667 deg == 5.06667 deg
>>
>> I see that 'approx' is used in the codebase which you might hope would
>> get all this right, but clearly excessive precision is being used for
>> our purposes (cave survey data).
>>
>> I'm not sure how to fix this.
>>
>> I've done an upload in the meantime with the previous bodge of the
>> tests, and to fix another bug too and let the package migrate to
>> testing. But getting the codebase to do what we actually expect would
>> be good.
>>
>> This is the patch I used to try double for angles:
>>
>> Author: Wookey 
>> Last-Update: 2018-03-09
>>
>> --- dewalls-1.0.0+ds1.orig/src/angle.cpp
>> +++ dewalls-1.0.0+ds1/src/angle.cpp
>> @@ -3,13 +3,13 @@
>>
>>  namespace dewalls {
>>
>> -const long double PI = acosl(-1.0L);
>> -const long double DegreesToRadians = PI / 180.0L;
>> -const long double GradiansToRadians = PI / 200.0L;
>> -const long double MilsNATOToRadians = PI / 3200.0L;
>> -const long double RadiansToDegrees = 180.0L / PI;
>> -const long double RadiansToGradians = 200.0L / PI;
>> -const long double RadiansToMilsNATO = 3200.0L / PI;
>> +const double PI = acosl(-1.0L);
>> +const double DegreesToRadians = PI / 180.0L;
>> +const double GradiansToRadians = PI / 200.0L;
>> +const double MilsNATOToRadians = PI / 3200.0L;
>> +const double RadiansToDegrees = 180.0L / PI;
>> +const double RadiansToGradians = 200.0L / PI;
>> +const double RadiansToMilsNATO = 3200.0L / PI;
>>
>>  QString Angle::Name("angle");
>>
>> @@ -30,7 +30,7 @@ QString Angle::symbolFor(Unit unit) {
>>  }
>>  }
>>
>> -long double Angle::toBase(long double quantity, Unit fromUnit) {
>> +double Angle::toBase(double quantity, Unit fromUnit) {
>>  switch (fromUnit) {
>>  case Radians:
>>  return quantity;
>> @@ -47,7 +47,7 @@ long double Angle::toBase(long double qu
>>  }
>>  }
>>
>> -long double Angle::fromBase(long double quantity, Unit toUnit) {
>> +double Angle::fromBase(double quantity, Unit toUnit) {
>>  switch (toUnit) {
>>  case Radians:
>>  return quantity;
>> @@ -64,7 +64,7 @@ long double Angle::fromBase(long double
>>  }
>>  }
>>
>> -long double Angle::convert(long double quantity, Unit fromUnit, Unit
>> toUnit) {
>> +double Angle::convert(double quantity, Unit fromUnit, Unit toUnit) {
>>  return fromBase(toBase(quantity, fromUnit), toUnit);
>>  }
>>
>> --- dewalls-1.0.0+ds1.orig/src/angle.h
>> +++ dewalls-1.0.0+ds1/src/angle.h
>> @@ -21,9 +21,9 @@ public:
>>
>>  static QString Name;
>>
>> -static long double toBase(long double quantity, Unit fromUnit);
>> -static long double fromBase(long double quantity, Unit toUnit);
>> -static long double convert(long double quantity, Unit fromUnit, Unit
>> toUnit);
>> +static double toBase(double quantity, Unit fromUnit);
>> +static double fromBase(double quantity, Unit toUnit);
>> +static double convert(double quantity, Unit fromUnit, Unit toUnit);
>>  static QString symbolFor(Unit unit);
>>  };
>>
>>
>>
>> Wookey
>> --
>> Principal hats:  Linaro, Debian, Wookware, ARM
>> http://wookware.org/
>>
> --
> Phi|ip
>
-- 
Phi|ip

Bug#888955: open-vm-tools.service 10.2.0 does not start on boot on jessie/stretch/etc

[Bernd Zeimetz]

Hi,

because it needs to run before cloud-init. Please read free Ubuntu bug I've 
linked, most details are discussed there. 

Thanks,
Bernd

Am 10. März 2018 00:22:32 MEZ schrieb Michael Biebl :
>On Fri, 2 Feb 2018 09:31:28 +0100 =?UTF-8?Q?Patrick_Matth=c3=a4i?= >
>for
>the public:
>> systemd does not start open-vm-tools at all in this scenario. If you
>> configure open-vm-tools.service to use DefaultDependencies=yes
>instead
>> of =no, it works as a workaround.
>
>Why does open-vm-tools.service need DefaultDependencies=no? Those
>should
>only be used by very few selected early boot services.
>
>vmtoolsd doesn't ship a man page, but from a quick internet search,
>this
>tool does not seem to fall into this category.
>
>-- 
>Why is it that all of the instruments seeking intelligent life in the
>universe are pointed away from Earth?

-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.

Bug#892488: pcre2: FTBFS on mips* - test failures

[Matthew Vernon]

Hi,


This is blocking git updates from migrating to testing
(https://qa.debian.org/excuses.php?package=git), so my preference
would be removing "mips mipsel mips64el" from the list of JIT arches
for now as a stopgap.


Done and uploaded, so I've downgraded this bug to important.

Regards,

Matthew

Bug#892077: rakarrack: Segfaults after jackd upgrade

[Stefan Potyra]

Hi Ben,

been bitten by this myself. Looks like your analysis is correct.
Attached is a debdiff with a fix.

I contacted Ryan with the proposed patch (but didn't file a SF ticket, since I
lost my credentials there).

Cheers,
  Stefan.


signature.asc
Description: PGP signature

Bug#892420: [PKG-Openstack-devel] Bug#892420: nova: please make the build reproducible

[Chris Lamb]

Hi Thomas,

> Of course it does make sense. Though I told you because you attempted to
> upstream the patch using github, and I thought it was best to let you
> know that you shouldn't do that, because it's a waste of time

That was considerate of you, thanks :)  But don't worry too much; 
have some shell aliases that semi-automate it so I only expended
about five minutes on it.

Oh, you might wish to update:

  Source: https://github.com/openstack/nova.git

.. in debian/copyright (and possibly other reference).

> I also feel like cheating you if I upload the change, and then take over
> the ownership of the patch.

Not at all! And you should get a vote; indeed, I would have thought
you would have one anyway as someone who takes care of that in Debian.
It would definitely make sense for you to have a vote.

(Feel free to take over the patch entirely; it is so trivial anyway
it's probably not even copyrightable...)

> Thanks for your patch, and working on reproducible-build,

A pleasure as always :)


Regards,

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

Bug#890043: wcc: diff for NMU version 0.0.2+dfsg-2.1

[Raphael Hertzog]

On Fri, 09 Mar 2018, Adrian Bunk wrote:
> I've prepared an NMU for wcc (versioned as 0.0.2+dfsg-2.1) and uploaded 
> it to DELAYED/3. Please feel free to tell me if I should cancel it.

Thanks for this, but I just uploaded a new version with this change and
other cleanups too.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

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

Bug#892428: pocl: FTBFS on x32: tries to build kernel/host/ for amd64

[Andreas Beckmann]

On 2018-03-09 17:11, Aaron M. Ucko wrote:
> Good question.  Copying the LLVM maintainers accordingly.

The problems started with 0.13-12 where we switched the buildsystem from 
autotools to cmake.

>From the 0.13-11 buildlog:
...
checking build system type... x86_64-pc-linux-gnux32
checking host system type... x86_64-pc-linux-gnux32
checking target system type... x86_64-pc-linux-gnux32
...
/usr/lib/llvm-3.8/bin/clang -I/usr/include/x86_64-linux-gnux32 
--target=x86_64-pc-linux-gnux32 -march=westmere -D_CL_DISABLE_HALF ...
...

>From the 0.13-12 buildlog:
...
-- llvm-config's LLVM_HOST_TARGET is: x86_64-pc-linux-gnu
...
/usr/bin/clang-3.8 --target=x86_64-pc-linux-gnu -D_CL_DISABLE_HALF -march= ...
...


>From the 1.1~rc2-1 buildlog:
...
-- llvm-config's LLVM_HOST_TARGET is: x86_64-pc-linux-gnu
...
/usr/bin/clang-4.0 --target=x86_64-pc-linux-gnu -D_CL_DISABLE_HALF 
-march=x86-64 ...
...

The LLVM_HOST_TARGET setting comes from llvm-config-4.0 --host-target:

cmake/LLVM.cmake:
  run_llvm_config(LLVM_HOST_TARGET --host-target)

which seems to return a wrong value on x32.
Due to lack of a x32 porterbox I cannot test this myself.

at least on an amd64 host --target=x86_64-pc-linux-gnux32 seems to do the right 
thing:

$ clang-4.0 --target=x86_64-pc-linux-gnux32 -march=x86-64 -c -x c /dev/null -o 
o.o
$ file o.o
o.o: ELF 32-bit LSB relocatable, x86-64, version 1 (SYSV), not stripped


Andreas

Bug#888955: open-vm-tools.service 10.2.0 does not start on boot on jessie/stretch/etc

[Michael Biebl]

On Fri, 2 Feb 2018 09:31:28 +0100 =?UTF-8?Q?Patrick_Matth=c3=a4i?= > for
the public:
> systemd does not start open-vm-tools at all in this scenario. If you
> configure open-vm-tools.service to use DefaultDependencies=yes instead
> of =no, it works as a workaround.

Why does open-vm-tools.service need DefaultDependencies=no? Those should
only be used by very few selected early boot services.

vmtoolsd doesn't ship a man page, but from a quick internet search, this
tool does not seem to fall into this category.

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



signature.asc
Description: OpenPGP digital signature

Bug#888955: open-vm-tools.service 10.2.0 does not start on boot on jessie/stretch/etc

[Michael Biebl]

On Wed, 31 Jan 2018 16:06:16 +0100 =?UTF-8?Q?Patrick_Matth=c3=a4i?=
 wrote:
> Package: open-vm-tools
> Version: 2:10.2.0-2
> Severity: important
> 
> Dear Maintainer,
> 
> here all systems on vSphere 6.0/6.5 fail to start open-vm-tools.service
> on boot.
> The only thing I see is:
> 
> # systemctl status open-vm-tools.service
> ● open-vm-tools.service - Service for virtual machines hosted on VMware
>    Loaded: loaded (/lib/systemd/system/open-vm-tools.service; enabled)
>    Active: failed (Result: resources)
>  Docs: http://open-vm-tools.sourceforge.net/about.php
> 
> This happens on jessie and stretch:
> 
> Stretch:
> Works: 2:10.1.5-5055683-4+deb9u1
> Fails: 2:10.2.0-2~bpo9+1

Please attach the output of /etc/fstab, systemctl show
open-vm-tools.service, systemctl cat open-vm-tools.service and
journalctl -alb from a boot where the service failed.

Is this happening reproducibly?

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



signature.asc
Description: OpenPGP digital signature

Bug#891956: updating found version

[William L. DeRieux IV]

found 891956 3.8.1-10

Bug#892420: [PKG-Openstack-devel] Bug#892420: nova: please make the build reproducible

[Thomas Goirand]

On 03/09/2018 05:49 PM, Chris Lamb wrote:
> Hi Thomas,
> 
>> https://review.openstack.org/551269
> 
> Thanks for doing this. :)  But wouldn't it make more sense — as the
> package maintainer in Debian — for you to handle these? :)

Of course it does make sense. Though I told you because you attempted to
upstream the patch using github, and I thought it was best to let you
know that you shouldn't do that, because it's a waste of time: the pull
request will automatically be closed telling you to use gerrit.

I also feel like cheating you if I upload the change, and then take over
the ownership of the patch. If you're ok with that, then I'm very happy
to have a few patch here and there in OpenStack, so I can participate in
the elections of the leaders of each project ! It's always nice to have
the opportunity to vote for friends.

> Sure, if the patch was huge, added features or was otherwise invasive
> I would perfectly understand going to upstream, but for these smaller
> changes I can't help but feel this is the responsibility of the
> maintainer in Debian.

Sure.

> This is especially so as there seems to be a number of things one needs
> to do to get a single line upstream, such as the CLA (meh..) as well as
> knowing how to use navigate Gerrit and even to know *where* to send
> the patch.

FYI, there's just the CLA once (I don't like it either... though it's
the nicer type of CLA, where you just confirm you're using the upstream
Apache-2.0 license for all of your contrib, nothing more), and then
nothing else to know about. Just "git review" and it will send the patch
to the correct place automatically (thanks to the .gitreview file in
each project). The only other thing there is to know is from were to
clone the upstream source. If it's a package from Debian OpenStack team,
then either there's an UPSTREAM_GIT= in debian/rules, or it's
systematically from https://git.openstack.org/ (or from Github
which holds a copy).

Again, all I'm telling here, you don't need to know, I'm very happy to
upstream these patches myself, I just didn't want you to waste your time
sending patches as Github pull requests which goes nowhere.

Thanks for your patch, and working on reproducible-build,
Cheers,

Thomas Goirand (zigo)

Bug#892514: libdbd-mysql-perl: 4.046-1 SSL certificate validation failure

[Corey Hickey]

Package: libdbd-mysql-perl
Version: 4.046-1
Severity: normal

Dear Maintainer,

Upon upgrade from 4.041-2+b1 to 4.046-1, I can no longer connect to our
mysql database with SSL. Reverting to 4.041-2+b1 makes the connection
work again.

Here is a test script to reproduce (with database name and hostname set
to example values).
---
#!/usr/bin/perl
use DBI;
my $dsn = 
'DBI:mysql:database=exampledb;host=example.com;mysql_ssl=1;mysql_ssl_ca_file=/tmp/ca_cert.pem';
my $conn = DBI->connect($dsn, 'foo', 'foo');
---



Outputs from the versions follow, with internal
information replaced with ''.

On 4.041-2+b1:
---
DBI 
connect('database=;host=;mysql_ssl=1;mysql_ssl_ca_file=/tmp/ca_cert.pem','foo',...)
 failed: Access denied for user 'foo'@'' (using password: YES) at 
/tmp/test.pl line 4.
---
(access denied is ok--it got past the SSL part)


On 4.046-1:
---
DBI 
connect('database=;host=;mysql_ssl=1;mysql_ssl_ca_file=/tmp/ca_cert.pem','foo',...)
 failed: SSL connection error: SSL certificate validation failure at 
/tmp/test.pl line 4.
---
(this one fails)


I have verified the following:
1. That the old version is indeed using SSL, via wireshark.
2. That both old and new versions are reading /tmp/ca_cert.pem, via
   strace.
3. That the server certificate has not expired, that it contains the
   target servername (as an X509v3 SAN), and that it verifies OK
   against the CA cert, via openssl.


I can imagine two possiblities; either:
a. Version 4.046-1 is more strict about validation and something is
   actually wrong, but I can't tell what.
b. There is a regression in validation in 4.046-1.

Either way, it worked before and does not now, so that seems worth
filing a bug over, to start with.

Thanks for your support,
Corey


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

Kernel: Linux 4.14.0-3-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 /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libdbd-mysql-perl depends on:
ii  libc6 2.27-1
ii  libdbi-perl [perl-dbdabi-94]  1.640-1
ii  libmariadbclient181:10.1.29-6
ii  perl  5.26.1-5
ii  perl-base [perlapi-5.26.1]5.26.1-5
ii  zlib1g1:1.2.8.dfsg-5

libdbd-mysql-perl recommends no packages.

libdbd-mysql-perl suggests no packages.

-- no debconf information

Bug#892513: ITP: r-cran-wavethresh -- GNU R wavelets statistics and transforms

[Andreas Tille]

Package: wnpp
Severity: wishlist
Owner: Andreas Tille 

* Package name: r-cran-wavethresh
  Version : 4.6.8
  Upstream Author : Guy Nason 
* URL : https://cran.r-project.org/package=wavethresh
* License : GPL
  Programming Lang: GNU R
  Description : GNU R wavelets statistics and transforms
 Performs 1, 2 and 3D real and complex-valued wavelet transforms,
 nondecimated transforms, wavelet packet transforms, nondecimated
 wavelet packet transforms, multiple wavelet transforms,
 complex-valued wavelet transforms, wavelet shrinkage for
 various kinds of data, locally stationary wavelet time series,
 nonstationary multiscale transfer function modeling, density
 estimation.


Remark: This package is needed in BioLinux and thus a sensible target for
the Debian Med team.  The actual packaging will be done by the r-pkg team
at
https://salsa.debian.org/r-pkg-team/r-cran-wavethresh

Bug#873321: wrk FTBFS with luajit 2.1

[Rinat Ibragimov]

Hi.

I believe patch below should fix the build. Here is why changes
are made.

First, is luaL_reg. It was a macro for compatibility with Lua
5.0.  It was defined in LuaJIT 2.0 headers, but removed in LuaJIT
2.1. The solution is to use luaL_Reg (note capital R), or to
define the macro again.

Next is removal of "luajit-2.0" substring from the include
directives. LuaJIT 2.0 puts its headers into
/usr/include/luajit-2.0, but since pkg-config files mention
/usr/include/luajit-2.0, it's sufficient to include lua.h without
additional paths. With LuaJIT 2.1 path was changed to luajit-2.1,
that broke the build.


diff -ur wrk-4.0.2-before/src/script.c wrk-4.0.2/src/script.c
--- wrk-4.0.2-before/src/script.c   2016-10-03 03:17:03.0 +0300
+++ wrk-4.0.2/src/script.c  2018-03-10 00:14:53.795446821 +0300
@@ -6,6 +6,10 @@
 #include "http_parser.h"
 #include "zmalloc.h"
 
+#ifndef luaL_reg
+#define luaL_reg luaL_Reg
+#endif
+
 typedef struct {
 char *name;
 int   type;
diff -ur wrk-4.0.2-before/src/script.h wrk-4.0.2/src/script.h
--- wrk-4.0.2-before/src/script.h   2016-10-03 03:17:03.0 +0300
+++ wrk-4.0.2/src/script.h  2018-03-10 00:14:07.745818846 +0300
@@ -2,9 +2,9 @@
 #define SCRIPT_H
 
 #include 
-#include 
-#include 
-#include 
+#include 
+#include 
+#include 
 #include 
 #include "stats.h"
 #include "wrk.h"
diff -ur wrk-4.0.2-before/src/wrk.h wrk-4.0.2/src/wrk.h
--- wrk-4.0.2-before/src/wrk.h  2016-10-03 03:17:03.0 +0300
+++ wrk-4.0.2/src/wrk.h 2018-03-10 00:14:23.830408060 +0300
@@ -10,7 +10,7 @@
 
 #include 
 #include 
-#include 
+#include 
 
 #include "stats.h"
 #include "ae.h"



---
Rinat

Bug#779814: bash-completion: please support new pkey, genpkey, pkeyparam, and pkeyutl subcommands of openssl

[Gabriel F. T. Gomes]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 05 Mar 2018, Brian Minton wrote:

>This is just a placeholder to inform you that the current version of
>bash-completion still does not have the new openssl commands.

Completion for these commands is not available, because they don't have
upstream (bash-completion) support.  Completion for other openssl
commands should be available, but not under /etc/bash_completion.d, as
has been mentioned in the first message in this bug report (maybe it
was a correct assumption such a long time ago :)).  Nowadays,
completions are shipped under /usr/share/bash-completion.

Anyhow, I thought it would be nice to see completions for these
commands, too, so I created a pull request upstream [1].  I'll wait for
comments, since I have little experience with openssl (maybe you could
provide some feedback, there?).

Thanks for reaching out. :)

[1] https://github.com/scop/bash-completion/pull/191
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEE+wUJHFVUA1wadvc8rpsRODhuyvIFAlqjCrgACgkQrpsRODhu
yvJNaw/7ByjREf6y+l2x2Xj+ouG3dfiQkYrp5/9BnRLZu3+3CdPdwipfk9I1pR3i
b2n/u3y/66SOrgQhgvmbCPb/Nj6Ob9CQtofWzUEfWBaXZHsfk1ZBLAIUWc/pjpuS
jbSMkC080Z357SFyIx+QD/Nz1IcKwiqWzNMmGu6eP5dhRn28R4hHs8CFvOqzKz73
oVT3eA2FwghhuvNin9Ks53OSI+MJLx1h/ZRRiavUGswuljUORwDboLysnqZBpCPh
xCmIOSIFC9UVGGaBxWA2S+SQLhR1JqC2Vt87tdl1mflzo0jBSy8sFfxEbEACkxe+
b5xvVR4OpxrjxNiRfmGvvUiLWHO+sLTBraIya9lYJUMvuHApzob0ooFpyoV348Qd
tUeecVjOWqSbPUqbla9mAvaQGa8tU0RUa2Z/c+a6Eth+C0BApKTSH0stZ2zv3yY/
6jvyL5tbXQA1OLqVNrgd+HJ9LXmRkDueZU+LJJVmpimCyEITfMBaRxgoJFmMVwPk
I9zeqKIdxG4TiQr1iK1Pm0uf64JxTWx2G1KT+GRNi9WEvIKMErZXYj1rHlg7R321
HqmdQjAV32laH8e2UiAUlN00bTx6PYRm1DxxQ/892qZLy65Z2Du9UjmCpgQFhsF5
pD2hJrDjCnh59x3Qf0/Vg8xW18j4auZO45JFBxRj3gLRIzH/Y6A=
=RInE
-END PGP SIGNATURE-

Bug#884337: ITP: kio-gdrive -- KIO Slave to access Google Drive

[Nicholas D Steeves]

Package: wnpp
Severity: wishlist
Owner: Nicholas D Steeves 
 
Package name: kio-gdrive
Version : 1.2.1
Upstream Author : Elvis Angelaccio 
URL : https://community.kde.org/KIO_GDrive
License : GPL-2+
Programming Lang: C++
Description : KIO Slave to access Google Drive
 
KIO GDrive is a KIO slave that enables KIO-aware applications (such as
Dolphin, Kate or Gwenview) to access and edit Google Drive files in
the cloud.

Bug#892373: [INFO] Bug#892373: proftpd-mod-fsync FTBFS with proftpd 1.3.6-1

[Hilmar Preuße]

On 09.03.2018 16:28, Francesco P. Lovergine wrote:

Hi,

> Here the fix is trivial as suggested. Even in this case it is better 
> upgrading to current upstream version.
> 
Where did you get a later version from? According to
http://www.castaglia.org/proftpd/ the 0.2 is the latest version.

H.
-- 
#206401 http://counter.li.org

Bug#285955: Salute!

[LeCates, Jenna]

Salute!
I pray that your email address is still active, I would like us to discuss 
about something.
You can email me at  alissa.cot...@hotmail.com

Bug#892290: [Pkg-xfce-devel] Bug#892290: light-locker: at unlock, crash with: arguments to dbus_message_new_method_call() were incorrect

[Stuart Pook]

On 09/03/18 14:50, Yves-Alexis Perez wrote:

control: tag -1 unreproducible moreinfo
On Wed, 2018-03-07 at 22:37 +0100, Stuart Pook wrote:

Dear Maintainer,

Light-locker crashes when I unlock my session. This means that my session
is not locked the next time it should be,


hi  Yves-Alexis


there was no recent update to light-locker. What did change on your system?
Unlock works fine here so I'll need more information in order to reproduce.


I guess I don't normally run it from the command line.

:; gdb $(type -p light-locker)
GNU gdb (Debian 7.12-6+b1) 7.12.0.20161007-git
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/bin/light-locker...Reading symbols from 
/usr/lib/debug/.build-id/e0/45019311f6cb6efe20e0fcd299a4f1d8ed64b0.debug...done.
done.
(gdb) run --debug
Starting program: /usr/bin/light-locker --debug
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7fffedcf0700 (LWP 27177)]
[New Thread 0x7fffed4ef700 (LWP 27178)]
[New Thread 0x7fffecab8700 (LWP 27179)]
[gs_debug_init] gs-debug.c:106 (22:27:46):   Debugging enabled
[main] light-locker.c:142 (22:27:46):initializing light-locker 1.8.0
[main] light-locker.c:164 (22:27:46):Platform:
gtk:3
systemd:yes
ConsoleKit: yes
UPower: yes
[main] light-locker.c:196 (22:27:46):Features:
lock-after-screensaver: yes
late-locking:   yes
lock-on-suspend:yes
lock-on-lid:yes
settings backend:   GSETTINGS
[main] light-locker.c:198 (22:27:46):lock after screensaver 3600
[main] light-locker.c:199 (22:27:46):late locking 0
[main] light-locker.c:200 (22:27:46):lock on suspend 1
[main] light-locker.c:201 (22:27:46):lock on lid 0
[main] light-locker.c:202 (22:27:46):idle hint 0
[query_session_id] gs-listener-dbus.c:2101 (22:27:46):   
org.freedesktop.login1.NoSessionForPID raised:
 PID 27173 does not belong to any known session


[init_session_id] gs-listener-dbus.c:2193 (22:27:46):Got session-id: (null)
[query_sd_session_id] gs-listener-dbus.c:2177 (22:27:46):Couldn't 
determine our own sd session id: No data available
[init_session_id] gs-listener-dbus.c:2198 (22:27:46):Got sd-session-id: 
(null)
[init_seat_path] gs-listener-dbus.c:2279 (22:27:46): Got seat: 
/org/freedesktop/DisplayManager/Seat0
[gs_listener_delay_suspend] gs-listener-dbus.c:449 (22:27:46):   Delay suspend
[gs_listener_x11_acquire] gs-listener-x11.c:172 (22:27:46):  ScreenSaver 
Registered
[listener_dbus_handle_system_message] gs-listener-dbus.c:1343 (22:27:46):   
 obj_path=/org/freedesktop/DBus interface=org.freedesktop.DBus 
method=NameAcquired destination=:1.1767
[listener_dbus_handle_session_message] gs-listener-dbus.c:1010 (22:29:00):  
 Received Lock request
[gs_grab_grab_root] gs-grab-x11.c:647 (22:29:00):Grabbing the root 
window
[gs_grab_get_keyboard] gs-grab-x11.c:153 (22:29:00): Grabbing keyboard 
widget=DF
[gs_grab_get_mouse] gs-grab-x11.c:213 (22:29:00):Grabbing mouse 
widget=DF
[gs_manager_create_windows_for_screen] gs-manager.c:548 (22:29:00):  
Creating 1 windows for screen 0
[gs_manager_create_window_for_monitor] gs-manager.c:324 (22:29:00):  
Creating window for monitor 0 [0,0] (1920x1200)
[update_geometry] gs-window-x11.c:197 (22:29:00):got geometry for 
monitor 0: x=0 y=0 w=1920 h=1200
[update_geometry] gs-window-x11.c:210 (22:29:00):using geometry for 
monitor 0: x=0 y=0 w=1920 h=1200
[update_geometry] gs-window-x11.c:197 (22:29:00):got geometry for 
monitor 0: x=0 y=0 w=1920 h=1200
[update_geometry] gs-window-x11.c:210 (22:29:00):using geometry for 
monitor 0: x=0 y=0 w=1920 h=1200
[gs_window_move_resize_window] gs-window-x11.c:243 (22:29:00):   Move and/or 
resize window on monitor 0: x=0 y=0 w=1920 h=1200
[update_geometry] gs-window-x11.c:197 (22:29:00):got geometry for 
monitor 0: x=0 y=0 w=1920 h=1200
[update_geometry] gs-window-x11.c:210 (22:29:00):using geometry for 
monitor 0: x=0 y=0 w=1920 h=1200
[gs_window_move_resize_window] gs-window-x11.c:243 (22:29:00):   Move and/or 
resize window on monitor 0: x=0 y=0 w=1920 h=1200
[update_geometry] gs-window-x11.c:197 (22:29:00):got geometry for 
monitor 0: x=0 y=0 w=1920 h=1200

Bug#875592: FTBFS with Java 9: javadoc classpath

[Emmanuel Bourg]

Control: tag -1 + patch

This is easily fixed by setting the javadoc classpath in debian/rules:

-   javadoc -locale en_US -d debian/build/javadoc -link 
/usr/share/doc/default-jdk-doc/api $(shell find -name "*.java")
+   javadoc -locale en_US -d debian/build/javadoc -classpath 
/usr/share/java/junit4.jar -link /usr/share/doc/default-jdk-doc/api $(shell 
find -name "*.java")

Bug#851810: xcalib: "Error - unsupported ramp size 0" when trying to invert screen

[Rinat Ibragimov]

Patch was merged in [1]. It's not going to make into any 1.19.x releases, but 
most probably
will be included in 1.20.x. (I'm talking about X.Org, not xcalib). Then xcalib 
should work again.

[1] 
https://cgit.freedesktop.org/xorg/xserver/commit/?id=ac138f9b31b0fba00742edbc3326afe66e28099a

Bug#874303: (no subject)

[Emmanuel Bourg]

reassign 874303 ftp.debian.org
retitle 874303 RM: jsymphonic -- ROM; obsolete, FTBFS with Java 9

Bug#873222: FTBFS with Java 9 due to Terrible Swing

[Emmanuel Bourg]

Control: tag -1 + wontfix

This package is about to be removed (see #874303).

Bug#892512: scribus: Eyedropper tool is not working

[Jérôme Marant]

Package: scribus
Version: 1.4.6+dfsg-4+b1
Severity: normal

Dear Maintainer,

The eyedropper tool currently does not work.
Clicking on it should show a dialog asking for a new color
name.

It used to work one year ago. It is quite strange since the package has
not been updated since october 2016. Could it be possible that some
libraries it depends on be broken?

Regards,

Jérôme.
 

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

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

Versions of packages scribus depends on:
ii  ghostscript  9.22~dfsg-2
ii  libc62.27-1
ii  libcairo21.15.10-2
ii  libcups2 2.2.6-5
ii  libfontconfig1   2.12.6-0.1
ii  libfreetype6 2.8.1-2
ii  libgcc1  1:8-20180218-1
ii  libhyphen0   2.8.8-5
ii  libjpeg62-turbo  1:1.5.2-2+b1
ii  liblcms2-2   2.9-1
ii  libpodofo0.9.5   0.9.5-9
ii  libpython2.7 2.7.14-6
ii  libqt4-network   4:4.8.7+dfsg-11
ii  libqt4-xml   4:4.8.7+dfsg-11
ii  libqtcore4   4:4.8.7+dfsg-11
ii  libqtgui44:4.8.7+dfsg-11
ii  libstdc++6   8-20180218-1
ii  libtiff5 4.0.9-4
ii  libxml2  2.9.4+dfsg1-6.1
ii  python-tk2.7.14-2
ii  scribus-data 1.4.6+dfsg-4
ii  zlib1g   1:1.2.8.dfsg-5

Versions of packages scribus recommends:
ii  cups-bsd2.2.6-5
ii  fonts-dejavu2.37-1
ii  fonts-liberation1:1.07.4-5
ii  hyphen-en-us [hyphen-hyphenation-patterns]  2.8.8-5
ii  icc-profiles-free   2.0.1+dfsg-1
ii  xfonts-scalable 1:1.0.3-1.1

Versions of packages scribus suggests:
ii  icc-profiles   2.1-2
pn  scribus-doc
pn  scribus-template   
ii  texlive-latex-recommended  2017.20180305-1

-- no debconf information

Bug#891966: transition: proj

[Sebastiaan Couwenberg]

On 03/03/2018 12:10 PM, Bas Couwenberg wrote:
>  survex  (1.2.32-1)   FTBFS (#889936)

proj (5.0.0-3) contains a patch to fix the regression that caused the
survex build failure.

Please rebuild survex with libproj-dev (>= 5.0.0-3).

 dw survex_1.2.32-1 . ANY . -m 'libproj-dev (>= 5.0.0-3)'

Kind Regards,

Bas

Bug#854679: Clarify license for Beneath a Steel Sky

[James 'Ender' Brown]

Hi Javier,

Original license author chiming in here again, since this seems to be a 
biennial thing :/


This is hopefully the last time I'll write on this matter, by this point 
pretty much every detail I can remember now documented
across half-a-dozen reports in BTS. Mostly across this one and 
https://bugs.debian.org/478898 tho. Also, as both Markus and Russ
noted - this has been debated over and over again in the BTS for this 
package.. but this is simply not the right forum for it.


 I'm not really sure what outcome you are looking for here...

Anyway - first I'll answer to your question.. then provide some more 
background on the conception of the license & Revolutions input!


*Yes. *It was pretty obvious to all parties that the license was "weak, 
and there are certainly ways to break the spirit legally. By design.

Without allowing that freedom, we couldn't honor the spirit of the DFSG.

Our guidelines from Tony Warriner @ Revolution were pretty darn simple 
(in relation to the Game Data at least).

I can paraphrase the basic points in a few short sentences:

 *   "We lost the original code, but we'll entrust you with this
   ports code"
 *   "Freeware? Hrm... I'll talk (to Charles / Dave?) but I think
   we can do that"
 *   "Wow you got the basic engine working already?"
 *   "We've decided to trust you and permit re-distribute it as
   freeware"
 *   ".. oh, but we don't want people to sell the game individually
   for $$$" (* see footnote 1)


We had a lot of freedom here - Charles, Tony and Revolution as a studio 
were amazing. So when I pitched them on the first draft of the
license the reply was not "We'll just run this by our legal team and 
lead council", but rather (very very paraphrased) "Looks good, ship it!"


To be perfectly honest - Debian-legal provided more input on the wording 
than Revolution.


This 'conflict' exists because of a the single restriction requested by 
Tony Warriner @ Revolution - that the game not be made
available for individual resale. This is the same sort of exception 
already implemented in other DFSG-approved licenses, and
we used similar logic to try and reconcile the authors wishes against 
the needs of the DFSG and legalities of redistribution

through various channels (/* see footnote 2/)

So we employed a complicated bit of Game Theory known as 'compromise'.

Let's recap the original goals:

 * Honor Revolutions request to limit individual resale
 * Satisfy the "fields of endeavor" clause of the DFSG to encourage 
Linux Distros able to ship

 * Permit redistribution as part of a Linux distribution
 * Permit redistribution on magazine cover discs (/* see footnote 3/)
 * "Plain Language" (/* see footnote 4/)

It was an exciting time, and this whole process laid the seed for 
ScummVM negotiating with right-holders - the silly levels of
cooperation from Revolution made us actively engage in outreach to 
original developers and right-holders. (/* see footnote 5/)


These early relationships were hard-earned and thanks to an amazing team 
and community. While ScummVM now has quite
an established and trusted reputation for treating both the games and 
their creators with respect, it was a long bumpy road.


With bad suspension and broken seatbelts. And I was driving without a 
license (no pun intended).



TL/DR: Revolution Software are Revolutionary Good People; /Compromise 
involves shades of grey/; In hindsight, your wording
   choices 15 years ago were terrible and will haunt you 
forever. /The phrase 'in hindsight' is also terrible and overused/,
           Throwing rocks at traffic from a bridge is stupid, dangerous 
and irresponsible. So is writing a custom software license.

*

*Kind regards
    Ender
    Former Co-Lead
    ScummVM Project


* _Footnote 1:_

   Many reasons, some commercial obligations but honestly mostly just
   to avoid legally permitting 'scammy' behaviour such as
   sellers charging RRP for a free download (such as producing fake
   originals, or hacking some title/copyright bitmaps and selling the game
   as their own work.

* _Footnote 2:_

   It was a learning experience, and of course in hindsight I should
   have just pitched something like the Artistic license instead
   of making the silly choice of writing YANL

* _Footnote 3:_

   Remember those?


* _Footnote 4:_

   Humanitarian theory - large international and ESL audience (as per
   most adventure games), so keep the license simple
 Observable outcome - the 'net has more lawyers than a law school /
   it seems a license clause really does need 3-4 subparagraphs...


* Footnote 5:

  Working with Revolution on implementing and re-releasing BASS was
   a major catalyst for ScummVM. I've always seen it as
  a win-win-win-win. A positive for ScummVM (as a project),
   developers/rightholders (as creators), the user/community (as
  consumers), and lastly distributions  (here, plz package some
   commercial-quality games).
 

Bug#892511: ruby-grape-route-helpers: FTBFS and Debci failure with ruby-grape 0.19.2-3

[Adrian Bunk]

Source: ruby-grape-route-helpers
Version: 2.1.0-1
Severity: serious

https://ci.debian.net/packages/r/ruby-grape-route-helpers/unstable/amd64/
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/ruby-grape-route-helpers.html

...
Failures:

  1) GrapeRouteHelpers::DecoratedRoute#helper_names when an API has multiple 
versions returns the route's helper name for each version
 Failure/Error: route_version.scan(version_pattern)

 NoMethodError:
   undefined method `scan' for ["beta", "alpha", "v1"]:Array
 # ./lib/grape-route-helpers/decorated_route.rb:69:in `route_versions'
 # ./lib/grape-route-helpers/decorated_route.rb:33:in `define_path_helpers'
 # ./lib/grape-route-helpers/decorated_route.rb:17:in `initialize'
 # ./spec/grape_route_helpers/decorated_route_spec.rb:8:in `new'
 # ./spec/grape_route_helpers/decorated_route_spec.rb:8:in `block (3 
levels) in '
 # ./spec/grape_route_helpers/decorated_route_spec.rb:7:in `map'
 # ./spec/grape_route_helpers/decorated_route_spec.rb:7:in `block (2 
levels) in '
 # ./spec/grape_route_helpers/decorated_route_spec.rb:29:in `block (2 
levels) in '
 # ./spec/grape_route_helpers/decorated_route_spec.rb:75:in `block (4 
levels) in '

  2) GrapeRouteHelpers::DecoratedRoute#path_helper_name when the path is a 
catch-all path returns a name without the glob star
 Failure/Error: expect(result).to eq('api_v1_path_path')

   expected: "api_v1_path_path"
got: "api_v1___path_path"

   (compared using ==)
 # ./spec/grape_route_helpers/decorated_route_spec.rb:147:in `block (4 
levels) in '

  3) GrapeRouteHelpers::DecoratedRoute path helper method when a route's API 
has multiple versions returns a path for each version
 Failure/Error: route_version.scan(version_pattern)

 NoMethodError:
   undefined method `scan' for ["beta", "alpha", "v1"]:Array
 # ./lib/grape-route-helpers/decorated_route.rb:69:in `route_versions'
 # ./lib/grape-route-helpers/decorated_route.rb:33:in `define_path_helpers'
 # ./lib/grape-route-helpers/decorated_route.rb:17:in `initialize'
 # ./spec/grape_route_helpers/decorated_route_spec.rb:8:in `new'
 # ./spec/grape_route_helpers/decorated_route_spec.rb:8:in `block (3 
levels) in '
 # ./spec/grape_route_helpers/decorated_route_spec.rb:7:in `map'
 # ./spec/grape_route_helpers/decorated_route_spec.rb:7:in `block (2 
levels) in '
 # ./spec/grape_route_helpers/decorated_route_spec.rb:29:in `block (2 
levels) in '
 # ./spec/grape_route_helpers/decorated_route_spec.rb:222:in `block (4 
levels) in '

  4) GrapeRouteHelpers::NamedRouteMatcher#route_match? when route responds to a 
method name returns true
 Failure/Error: route_version.scan(version_pattern)

 NoMethodError:
   undefined method `scan' for ["beta", "alpha", "v1"]:Array
 # ./lib/grape-route-helpers/decorated_route.rb:69:in `route_versions'
 # ./lib/grape-route-helpers/decorated_route.rb:33:in `define_path_helpers'
 # ./lib/grape-route-helpers/decorated_route.rb:17:in `initialize'
 # ./lib/grape-route-helpers/all_routes.rb:8:in `new'
 # ./lib/grape-route-helpers/all_routes.rb:8:in `block in decorated_routes'
 # ./lib/grape-route-helpers/all_routes.rb:8:in `map'
 # ./lib/grape-route-helpers/all_routes.rb:8:in `decorated_routes'
 # ./spec/grape_route_helpers/named_route_matcher_spec.rb:7:in `block (2 
levels) in '
 # ./spec/grape_route_helpers/named_route_matcher_spec.rb:11:in `block (2 
levels) in '
 # ./spec/grape_route_helpers/named_route_matcher_spec.rb:30:in `block (4 
levels) in '
 # ./spec/grape_route_helpers/named_route_matcher_spec.rb:43:in `block (4 
levels) in '

  5) GrapeRouteHelpers::NamedRouteMatcher#route_match? when route responds to a 
method name when segments is not a hash raises an ArgumentError
 Failure/Error:
   expect do
 route_match?(route, method_name, 1234)
   end.to raise_error(ArgumentError)

   expected ArgumentError, got # with backtrace:
 # ./lib/grape-route-helpers/decorated_route.rb:69:in `route_versions'
 # ./lib/grape-route-helpers/decorated_route.rb:33:in 
`define_path_helpers'
 # ./lib/grape-route-helpers/decorated_route.rb:17:in `initialize'
 # ./lib/grape-route-helpers/all_routes.rb:8:in `new'
 # ./lib/grape-route-helpers/all_routes.rb:8:in `block in 
decorated_routes'
 # ./lib/grape-route-helpers/all_routes.rb:8:in `map'
 # ./lib/grape-route-helpers/all_routes.rb:8:in `decorated_routes'
 # ./spec/grape_route_helpers/named_route_matcher_spec.rb:7:in `block 
(2 levels) in '
 # ./spec/grape_route_helpers/named_route_matcher_spec.rb:11:in `block 
(2 levels) in '
 # ./spec/grape_route_helpers/named_route_matcher_spec.rb:30:in `block 
(4 levels) in '
 # ./spec/grape_route_helpers/named_route_matcher_spec.rb:37:in `block 
(6 levels) in '
 # 

Bug#892510: python-distutils-extra FTBFS: FAIL: test_apport_hook

[Adrian Bunk]

Source: python-distutils-extra
Version: 2.40
Severity: serious
Tags: buster sid

Some recent change in unstable makes python-distutils-extra FTBFS:

https://tests.reproducible-builds.org/debian/history/python-distutils-extra.html
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/python-distutils-extra.html

...
==
FAIL: test_apport_hook (__main__.T)
Apport hooks
--
Traceback (most recent call last):
  File "test/auto.py", line 198, in test_apport_hook
self.assertEqual(len(f), 3, f) # 2 hook files plus .egg-info
AssertionError: 0 != 3 : []

--
Ran 26 tests in 17.308s

FAILED (failures=1)
make[1]: *** [debian/rules:9: override_dh_auto_test] Error 1

Bug#891881: [Pkg-mailman-hackers] Bug#891881: Bug#891881: mailman3-suite: On system using exim (no postfix install) the list create script tries to create postfix aliases

[Jonas Meurer]

Hi Markus,

Am 09.03.2018 um 21:43 schrieb Markus Gschwendt:
> After further debugging and discussion i bring this back here because i
> think it is related to the debian packages.
> 
> Summary:
> 
> I figured out that a restart/stop-start of mailman3-suite and mailman3-
> core does not stop mailman.
> 
> 'service mailman3-suite stop' kills only the uwsgi processes (not
> mailman)

That's expected. 'mailman3-suite' provides only the the uWSGI daemon
with the Django webinterface. 'mailman3-core' on the other hand provides
the actual mailman3 daemon.

I agree that this is somewhat confusing.

> this is why the changed config is not active for the webUI after stop-
> start mailman in this way.
> 
> a 'mailman stop' and 'mailman start' seems to work

Can you verify that restarting 'mailman3-core' (e.g. via `service
mailman3-core restart`) solves the issue for you?

Cheers,
 jonas



signature.asc
Description: OpenPGP digital signature

Bug#892129: RFS: urlwatch/2.8-3

[Maxime Werlen]

Hi Paul,

Thanks for your help.
I've uploaded a new package with python3 dependencies and "default-mta |
mail-transport-agent"

Maxime

2018-03-06 1:54 GMT+01:00 Paul Wise :

> On Mon, 2018-03-05 at 22:29 +0100, Maxime Werlen wrote:
>
> >   * Fix missing optional dependencies (Closes: #891884)
> ...
> > + python-html2text,
> > + python-vobject,
>
> Since urlwatch uses Python 3, I think urlwatch should be
> suggesting the
> Python 3 html2text and vobject modules.
>
> > + sendmail,
>
> I don't think urlwatch should just suggest sendmail, since
> it is not the only MTA in Debian. Please use this instead:
>
> Suggests: default-mta | mail-transport-agent
>
> https://www.debian.org/doc/debian-policy/#mail-transport-
> delivery-and-user-agents
>
> --
> bye,
> pabs
>
> https://wiki.debian.org/PaulWise
>

Bug#892509: [chromium] uBlock Origin extension do not work anymore

[Boris Pek]

Package: chromium
Version: 65.0.3325.146-1
Severity: important


Hi,

uBlock Origin extension do not work with new version of chromium
(65.0.3325.146-1), with previous version from unstable (64.0.3282.119-2) all
works fine. What have changed? Any recommendations how to fix loading of this
popular ad blocker?

Best regards,
Boris


--- System information. ---
Kernel:   Linux 4.15.0-1-amd64

Debian Release: buster/sid
  500 unstableriot.im 
  500 unstabledeb.debian.org 
  500 unstabledeb-multimedia.org 
1 experimentaldeb.debian.org 

Bug#884697: Progress

[Christian Göttsche]

There is now a salsa project for logrotate:
https://salsa.debian.org/debian/logrotate

I also pushed my current packaging progress of version 3.14.0 to the
branch cgzones_master.

Bug#892499: Non-ascii characters broken in d-i (text-based installer)

[Samuel Thibault]

Control: reassign -1 installation-locale
Control: done -1 1.7+b1

As mentioned on the list, this gets fixed by rebuilding
installation-locale (against the latest glibc)

Samuel

Bug#892062: bug 892062 is forwarded to https://github.com/OSGeo/proj.4/issues/833

[Sebastiaan Couwenberg]

On 03/09/2018 09:17 PM, Olly Betts wrote:
> On Fri, Mar 09, 2018 at 07:00:50AM +0100, Sebastiaan Couwenberg wrote:
>>> There's now a patch for this:
>>>
>>> https://github.com/OSGeo/proj.4/pull/845
>>
>> The changes look a little invasive, though.
> 
> Yeah, I sighed a bit when I saw it looked like most of the file was
> rewritten.  OTOH, it's an x.0.0 version with a new API added so
> presumably already full of invasive changes compared to 4.9.x - it's
> not like we're backporting a patch to Debian stable here.

I'm quite wary of Thomas Knudsens changes, with this PR he has once
again proven his tendency to introduce regressions. Also not learning
from that by adding regression tests.

> Looks like there are some teething problems with the patch but
> upstream are being responsive to dealing with them.

Fortunately there are people who test his changes. Unfortunately there
aren't enough to do this early in development to catch regressions
before they're committed and included in a release.

> Thanks for the package in experimental - I'll try to do some additional
> testing with Survex and that package.

With the patch for the regression introduced by the changes from PR #845
no further regressions were uncovered with the most recent round of rdep
rebuilds, so I'll move the proj package from experimental to unstable soon.

Kind Regards,

Bas

Bug#789247: di-netboot-assistant: broken deb.d.o urls

[Matt Taggart]

It looks like the deb.debian.org URLs in di-sources.list need to be updated

E: Can't download 'stretch' for 'amd64' 
(http://deb.debian.org/dists/stretch/main/installer-amd64/current/images/MD5SUMS).


The URL should have a leading 'debian/' in the path, ie

http://deb.debian.org/dists/stretch/main/installer...

I don't know if this is just some mirrors or everywhere, but not having 
it resulted in an error for me (it resolved to cdn-aws.deb.debian.org)


Thanks,

--
Matt Taggart
tagg...@debian.org

Bug#892508: ruby-psych FTBFS with Ruby 2.5

[Adrian Bunk]

Source: ruby-psych
Version: 2.2.4-6
Severity: serious

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

...
   dh_auto_configure -O--buildsystem=ruby
dh_ruby --configure
   debian/rules override_dh_auto_build-indep
make[1]: Entering directory '/build/1st/ruby-psych-2.2.4'
jruby -S rake compile
/usr/lib/ruby/vendor_ruby/psych.rb:6: warning: already initialized constant 
SNAKEYAML_VERSION
/usr/lib/ruby/vendor_ruby/psych.rb:6: warning: already initialized constant ANY
/usr/lib/ruby/vendor_ruby/psych.rb:6: warning: already initialized constant UTF8
/usr/lib/ruby/vendor_ruby/psych.rb:6: warning: already initialized constant 
UTF16LE
/usr/lib/ruby/vendor_ruby/psych.rb:6: warning: already initialized constant 
UTF16BE
/usr/share/jruby/lib/ruby/stdlib/rubygems/core_ext/kernel_require.rb:59:in 
`require':
It seems your ruby installation is missing psych (for YAML output).
To eliminate this warning, please install libyaml and reinstall your ruby.
rake aborted!
LoadError: load error: psych -- java.lang.NoClassDefFoundError: Could not 
initialize class org.jruby.ext.psych.PsychEmitter
/build/1st/ruby-psych-2.2.4/Rakefile:1:in `(root)'
/build/1st/ruby-psych-2.2.4/Rakefile:13:in `block in (root)'
(See full trace by running task with --trace)
make[1]: *** [debian/rules:9: override_dh_auto_build-indep] Error 1

Bug#892507: ruby-sequel FTBFS with Ruby 2.5

[Adrian Bunk]

Source: ruby-sequel
Version: 4.37.0-1
Severity: serious
Tags: buster sid

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

...
  1) Failure:
Sequel::Database dump methods#test_0036_should handle converting common 
defaults 
[/build/1st/ruby-sequel-4.37.0/spec/extensions/schema_dumper_spec.rb:636]:
--- expected
+++ actual
@@ -4,7 +4,7 @@
   String :c2, :default=>\"blah\"
   Integer :c3, :default=>-1
   Float :c4, :default=>1.0
-  BigDecimal :c5, :default=>BigDecimal.new(\"0.1005E3\")
+  BigDecimal :c5, :default=>BigDecimal.new(\"0.1005e3\")
   File :c6, :default=>Sequel::SQL::Blob.new(\"blah\")
   Date :c7, :default=>Date.new(2008, 10, 29)
   DateTime :c8, :default=>DateTime.parse(\"2008-10-29T10:20:30.0\")


  2) Failure:
LooserTypecasting Extension#test_0004_should not raise errors for invalid 
strings in decimal columns 
[/build/1st/ruby-sequel-4.37.0/spec/extensions/looser_typecasting_spec.rb:35]:
--- expected
+++ actual
@@ -1 +1,2 @@
-0.0
+# encoding: UTF-8
+"a"


2462 runs, 7090 assertions, 2 failures, 0 errors, 0 skips
rake aborted!
Command failed with status (1): [/usr/bin/ruby2.5 spec/plugin_spec.rb...]
/build/1st/ruby-sequel-4.37.0/Rakefile:89:in `block in '
/build/1st/ruby-sequel-4.37.0/Rakefile:96:in `block (2 levels) in '
Tasks: TOP => spec => spec_plugin
(See full trace by running task with --trace)
ERROR: Test "ruby2.5" failed. Exiting.
dh_auto_install: dh_ruby --install 
/build/1st/ruby-sequel-4.37.0/debian/ruby-sequel returned exit code 1
make: *** [debian/rules:15: binary] Error 1

Bug#892506: ITP: r-cran-waveslim -- GNU R wavelet routines for 1-, 2- and 3-D signal processing

[Andreas Tille]

Package: wnpp
Severity: wishlist
Owner: Andreas Tille 

* Package name: r-cran-waveslim
  Version : 1.7.5
  Upstream Author : Brandon Whitcher 
* URL : https://cran.r-project.org/package=waveslim
* License : BSD
  Programming Lang: GNU R
  Description : GNU R wavelet routines for 1-, 2- and 3-D signal processing
 Basic wavelet routines for time series (1D), image (2D)
 and array (3D) analysis.  The code provided here is based on
 wavelet methodology developed in Percival and Walden (2000);
 Gencay, Selcuk and Whitcher (2001); the dual-tree complex wavelet
 transform (DTCWT) from Kingsbury (1999, 2001) as implemented by
 Selesnick; and Hilbert wavelet pairs (Selesnick 2001, 2002).  All
 figures in chapters 4-7 of GSW (2001) are reproducible using this
 package and R code available at the book website(s) below.


Remark: This package is needed in BioLinux and thus a sensible target for
the Debian Med team.  The actual packaging will be done by the r-pkg team
at
https://salsa.debian.org/r-pkg-team/r-cran-waveslim

Bug#891881: [Pkg-mailman-hackers] Bug#891881: mailman3-suite: On system using exim (no postfix install) the list create script tries to create postfix aliases

[Markus Gschwendt]

After further debugging and discussion i bring this back here because i
think it is related to the debian packages.

Summary:

I figured out that a restart/stop-start of mailman3-suite and mailman3-
core does not stop mailman.

'service mailman3-suite stop' kills only the uwsgi processes (not
mailman)

this is why the changed config is not active for the webUI after stop-
start mailman in this way.

a 'mailman stop' and 'mailman start' seems to work

Details: https://gitlab.com/mailman/mailman/issues/455

Bug#892505: transition: openexr

[Matteo F. Vescovi]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
X-Debbugs-CC: pkg-phototools-de...@lists.alioth.debian.org, ma...@debian.org

Dear Release Team,

I'm filing this bug for a new transition of openexr package.

On March 8, 2018 a fixed testing-purpose package (2.2.1-2) has been
uploaded to experimental.

So, following the auto-openexr checklist[1], here is the list of source
packages depending on openexr and the results of the test builds
(honoring the dependency levels as reported in the checklist, as
relevant for the correct order):

### Dependency level 2 ###
 * aqsis_1.8.2-8 => OK
 * darktable_2.4.0-1 => OK
 * exactimage_1.0.1-1 => OK
 * freeimage_3.17.0+ds1-5 => OK
 * gegl_0.3.28-2 => OK
 * imagemagick_8:6.9.9.34+dfsg-3 => OK
 * kde-runtime_4:17.08.3-1 => OK
 * kimageformats_5.42.0-2 => OK
 * kio-extras_4:17.08.3-2 => OK
 * krita_1:3.3.3+dfsg-1 => OK
 * libvigraimpex_1.10.0+git20160211.167be93+dfsg-5 => OK
 * luminance-hdr_2.5.1+dfsg-3 => OK
 * mia_2.4.6-2 => OK
 * nvidia-texture-tools_2.0.8-1+dfsg-8.1 => OK
 * opencv_3.2.0+dfsg-4 => OK
 * openexr-viewers_1.0.1-6 => OK
 * openvdb_5.0.0-1 => OK
 * povray_1:3.7.0.4-2 => OK

### Dependency level 3 ###
 * gmic_1.7.9+zart-4 => FTBFS (not openexr related)
 * gst-plugins-bad1.0_1.8.3-1 => FTBFS (not openexr related)
 * hugin_2018.0.0+dfsg-1 => OK
 * k3d_0.8.0.6-6 => OK
 * openimageio_1.8.9~dfsg0-1 => OK
 * pfstools_2.1.0-3 => OK
 * synfig_1.0.2-1 => OK
 * vips_8.4.5-1 => FTBFS (not openexr related)

### Dependency level 4 ###
  blender_2.79+dfsg0-3 => OK

Thanks for your time and patience.

mfv


[1] https://release.debian.org/transitions/html/auto-openexr.html

Ben file:

title = "openexr";
is_affected = .depends ~ "libopenexr22" | .depends ~ "libopenexr23";
is_good = .depends ~ "libopenexr23";
is_bad = .depends ~ "libopenexr22";


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

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


signature.asc
Description: PGP signature

Bug#892328: python3.6: Please add support for riscv64

[Aurelien Jarno]

On 2018-03-08 12:52, Aurelien Jarno wrote:
> Package: python3.6
> Version: 3.6.4-4
> Severity: wishlist
> Tags: patch
> User: debian-ri...@lists.debian.org
> Usertags: riscv64
> 
> The python3 configure script doesn't know about the platform triplet of
> the riscv64 architecture. In addition it requires a small symbols
> update. Please find attached a patch to fix both issues.

It happened that I forgot to update debian/multiarch.h.in in my previous
patch. Please find a new version attached.

Thanks,
Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net
diff -Nru python3.6-3.6.4/debian/libpython.symbols.in python3.6-3.6.4/debian/libpython.symbols.in
--- python3.6-3.6.4/debian/libpython.symbols.in
+++ python3.6-3.6.4/debian/libpython.symbols.in
@@ -1367,8 +1367,8 @@
  _PyParser_TokenNames@Base @SVER@
  _PyRandom_Fini@Base @SVER@
  _PyRandom_Init@Base @SVER@
- (arch=alpha amd64 arm64 ia64 mips64 mips64el mips64r6 mips64r6el ppc64el kfreebsd-amd64)_PySHA3_KeccakF1600_FastLoop_Absorb@Base @SVER@
- (arch=!alpha !amd64 !arm64 !ia64 !mips64 !mips64el !mips64r6 !mips64r6el !ppc64el !kfreebsd-amd64)_PySHA3_KeccakP1600_AddByte@Base @SVER@
+ (arch=alpha amd64 arm64 ia64 mips64 mips64el mips64r6 mips64r6el ppc64el kfreebsd-amd64 riscv64)_PySHA3_KeccakF1600_FastLoop_Absorb@Base @SVER@
+ (arch=!alpha !amd64 !arm64 !ia64 !mips64 !mips64el !mips64r6 !mips64r6el !ppc64el !kfreebsd-amd64 !riscv64)_PySHA3_KeccakP1600_AddByte@Base @SVER@
  _PySHA3_KeccakP1600_AddBytes@Base @SVER@
  _PySHA3_KeccakP1600_AddBytesInLane@Base @SVER@
  _PySHA3_KeccakP1600_AddLanes@Base @SVER@
@@ -1385,8 +1385,8 @@
  _PySHA3_KeccakP1600_OverwriteWithZeroes@Base @SVER@
  _PySHA3_KeccakP1600_Permute_12rounds@Base @SVER@
  _PySHA3_KeccakP1600_Permute_24rounds@Base @SVER@
- (arch=!alpha !amd64 !arm64 !ia64 !mips64 !mips64el !mips64r6 !mips64r6el !ppc64el !kfreebsd-amd64)_PySHA3_KeccakP1600_Permute_Nrounds@Base @SVER@
- (arch=!alpha !amd64 !arm64 !ia64 !mips64 !mips64el !mips64r6 !mips64r6el !ppc64el !kfreebsd-amd64)_PySHA3_KeccakP1600_SetBytesInLaneToZero@Base @SVER@
+ (arch=!alpha !amd64 !arm64 !ia64 !mips64 !mips64el !mips64r6 !mips64r6el !ppc64el !kfreebsd-amd64 !riscv64)_PySHA3_KeccakP1600_Permute_Nrounds@Base @SVER@
+ (arch=!alpha !amd64 !arm64 !ia64 !mips64 !mips64el !mips64r6 !mips64r6el !ppc64el !kfreebsd-amd64 !riscv64)_PySHA3_KeccakP1600_SetBytesInLaneToZero@Base @SVER@
  _PySHA3_KeccakWidth1600_Sponge@Base @SVER@
  _PySHA3_KeccakWidth1600_SpongeAbsorb@Base @SVER@
  _PySHA3_KeccakWidth1600_SpongeAbsorbLastFewBits@Base @SVER@
diff -Nru python3.6-3.6.4/debian/multiarch.h.in python3.6-3.6.4/debian/multiarch.h.in
--- python3.6-3.6.4/debian/multiarch.h.in
+++ python3.6-3.6.4/debian/multiarch.h.in
@@ -81,6 +81,12 @@
 #  include 
 # elif defined(__sparc__)
 #  include 
+# elif defined(__riscv)
+#  if __riscv_xlen == 64
+#include 
+#  else
+#include 
+#  endif
 # else
 #   error unknown multiarch location for @header@
 # endif
diff -Nru python3.6-3.6.4/debian/patches/riscv64.diff python3.6-3.6.4/debian/patches/riscv64.diff
--- python3.6-3.6.4/debian/patches/riscv64.diff
+++ python3.6-3.6.4/debian/patches/riscv64.diff
@@ -0,0 +1,17 @@
+--- python3.6-3.6.4.orig/configure.ac
 python3.6-3.6.4/configure.ac
+@@ -866,6 +866,14 @@ cat >> conftest.c <

Bug#892062: bug 892062 is forwarded to https://github.com/OSGeo/proj.4/issues/833

[Olly Betts]

On Fri, Mar 09, 2018 at 07:00:50AM +0100, Sebastiaan Couwenberg wrote:
> > There's now a patch for this:
> > 
> > https://github.com/OSGeo/proj.4/pull/845
> 
> The changes look a little invasive, though.

Yeah, I sighed a bit when I saw it looked like most of the file was
rewritten.  OTOH, it's an x.0.0 version with a new API added so
presumably already full of invasive changes compared to 4.9.x - it's
not like we're backporting a patch to Debian stable here.

Looks like there are some teething problems with the patch but
upstream are being responsive to dealing with them.

Thanks for the package in experimental - I'll try to do some additional
testing with Survex and that package.

Cheers,
Olly

Bug#892280: libcdk5: library package needs to be renamed for libncurses6 transition

[Sven Joachim]

On 2018-03-09 15:18 -0300, Herbert Fortes wrote:

> Hi Sven Joachim,
>
>>> My conclusion is that it is very risky to allow such combinations, and
>>> to rule them out I propose to change the package name of the cdk
>>> library, say to libcdk5a.  It would then have to build-depend on
>>> libncurses-dev (>= 6.1+20180210) to ensure that it is linked against
>>> libncurses6 and not libncurses5.  Of course this can only be uploaded
>>> to experimental for now, but should go to unstable when the ncurses
>>> transition starts there.
>
>
> I am OK with changing the name. But libcdk5a does not say 
> much about why the change.
>
> Since the package name will change because of SONAME of 
> libncurses, I thought to follow the SONAME of the library.

Well, the SONAME of the cdk library does not change with my proposal.

> libcdk5-6

If you like that better than libcdk5a, choose it.  Or any other name,
it's rather arbitrary anyway.

> But maybe this will cause misunderstanding. The change is
> on version 6.1+20180210.

That's why the build-dependency on libncurses-dev (>= 6.1+20180210) is
needed.

I am not sure we understand each other yet, but I'm happy to answer
questions.

Cheers,
   Sven

Bug#890954: With this version all extensions crash

[Jesse Coumont]

Just an FYI to anyone who wants to downgrade back to 64.x (and not to
buster's 62.x) you can still grab the deb files from:
http://snapshot.debian.org/package/chromium-browser/64.0.3282.119-2/
(64.0.3282.119-2+b2 specifically)

Make sure to install chromium-common as well. You will get a profile
downgrade compliant but it hasn't caused me any actual issues.

Bug#892503: tmux: display garbling with nested sessions

[Vagrant Cascadian]

Package: tmux
Version: 2.6-3
Severity: normal

Many thanks for maintaining tmux! I use it constantly!

I've noticed a new problem with tmux on at least two buster machines,
but I have not observed it on any stretch machines.

I've got a tmux (2.3-4) session running on a stretch machine, from which
I ssh to a buster machine and run tmux (2.6-3). In both cases,
TERM=screen. When the output reaches the bottom of the screen, the
output gets garbled, leaving artifacts from previous states:

vagrant@wbs:~$ ip a
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group 
default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
   valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
   valid_lft forever preferred_lft forever
2: eth0:  mtu 1500 qdisc pfifo_fast state UP 
group default qlen 1000
link/ether 00:1f:7b:b0:0c:43 brd ff:ff:ff:ff:ff:ff
inet 10.0.0.115/24 brd 10.0.0.255 scope global eth0
   valid_lft forever preferred_lft forever
inet6 fe80::21f:7bff:feb0:c43/64 scope link
   valid_lft forever preferred_lft forever
vagrant@wbs:~$ ip a
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group 
default qlen 1000
2: eth0:  mtu 1500 qdisc pfifo_fast state UP 
group default qlen 1000
link/ether 00:1f:7b:b0:0c:43 brd ff:ff:ff:ff:ff:ff
inet 10.0.0.115/24 brd 10.0.0.255 scope global eth0
   valid_lft forever preferred_lft forever
vagrant@wbs:~$ ip a:7bff:feb0:c43/64 scope link
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group 
default qlen 1000
link/ether 00:1f:7b:b0:0c:43 brd ff:ff:ff:ff:ff:ff:00
inet 10.0.0.115/24 brd 10.0.0.255 scope global eth0
   valid_lft forever preferred_lft forever
inet6 fe80::21f:7bff:feb0:c43/64 scope link
   valid_lft forever preferred_lft forever
vagrant@wbs:~$ CAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP 
group default qlen 1000


It gets progressively more garbled as more commands produce more
output. Issuing "reset" doesn't clear the screen, though the cursor
moves to the top.

It doesn't appear to happen if I ssh in from an xterm and start tmux,
so seems to have something to do with nested tmux sessions over ssh,
maybe some incompatibility between versions... ?

If it matters, the stretch machine was running amd64, but the buster
machines were armhf and arm64.

live well,
  vagrant


-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (500, 'testing'), (1, 'experimental')
Architecture: armhf (armv7l)

Kernel: Linux 4.15.0-1-armmp (SMP w/1 CPU core)
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 tmux depends on:
ii  libc6   2.27-1
ii  libevent-2.1-6  2.1.8-stable-4
ii  libtinfo5   6.1-1
ii  libutempter01.1.6-3

tmux recommends no packages.

tmux suggests no packages.

-- no debconf information


signature.asc
Description: PGP signature

Bug#825983: [Pkg-erlang-devel] Bug#825983: yaws: no script exists to create the link in /etc/yaws/conf.d

[Sergei Golovan]

Hi Alexandros,

Sorry about the delay.

On Wed, Jun 1, 2016 at 7:21 AM, Alexandros Prekates
 wrote:
>
> Shouldnt there be an automatic way to create the links
> that i see between conf files in /etc/yaws/conf.avail
> and /etc/yaws/cond.d ?

There are only two configs in conf.avail in yaws itself (example
virtual hosts for localhost) and a few in yaws-* packages, for which I
don't see the point of creating another uncommon config utility. The
links are created on packages install, and not recreated on upgrade if
the admin has deleted them. I think that should be enough.

Cheers!
-- 
Sergei Golovan

Bug#826064: [Pkg-erlang-devel] Bug#826064: yaws: how invoke-rc.d script works?

[Sergei Golovan]

Hi Alexandros,

Sorry for such a delay.

On Thu, Jun 2, 2016 at 2:49 AM, Alexandros Prekates
 wrote:
>
> Dear Maintainer,
>
> how invoke-rc.d script works?
>
> For example i change one directive to a virt_serv conf file (like a port)
> and then execute:
> # invoke-rc.d yaws reload
> but i dont see the change.

I can't reproduce this as for now. Both

invoke-rc.d yaws reload

and

systemctl reload yaws

make YAWS reload its config and change the listened port.

>
> But if i restart with :
> # service yaws stop
> # service yaws start
>
> then the change is seen.

This way the port is changed as well.

Cheers!
-- 
Sergei Golovan

Bug#865013: network-manager-gnome: Consistent segfault when connecting to WPA2 network

[BenWiederhake.GitHub]

Control: found -1 1.8.10-2

Heyaloha,

it seems like this is going to take a while to update.
Meanwhile, I sent in a patch [1], and it got "applied, with a small 
change" [2].  You may want to do the following:


apt-get source network-manager-applet
sudo apt-get build-dep network-manager-applet
fakeroot ./debian/rules binary
sudo dpkg -i ../libnma0*.deb

Plus minus a few 'cd'.

Cheers,
Ben

[1] https://bugzilla.gnome.org/show_bug.cgi?id=785674#c5
[2] 
https://git.gnome.org/browse/network-manager-applet/commit/?id=a37483c1a364ef3cc1cfa29e7ad51ca108d75674

Bug#887323: dewalls i386 test failure

[Philip Schuchardt]

Wow, we were using long doubles before. I don't think we need that much
precision for cave survey. In catch there is Approx() that should take care
of floating point comparison correctly.

On Fri, Mar 9, 2018 at 11:30 AM Wookey  wrote:

> A bit of research tells that using 'long double' causes 80-bit fp on x86
> (i386 and amd64), as opposed to the 64-bit IEE 754 fp representation used
> on other platforms, which is what you get if you specify double.
>
> So I tried changing the angle.{cpp.h} code to use double instead of long
> double.
>
> That doesn't fix the problrematic tests, but does cause another 43 to fail:
> test cases:   8 |   3 passed |  5 failed
> assertions: 202 | 155 passed | 47 failed
>
> They all fail equality tests, despite them clearly being 'equal
> enough' for our purposes.
>
> e.g.
> /home/wookey/dewalls-1.0.0+ds1/test/azimuthparsingtests.cpp:31: FAILED:
>   CHECK( WallsSurveyParser("5:4").azimuth(Angle::Degrees) == UAngle(5 + 4
> / 60.0, Angle::Degrees) )
> with expansion:
>   5.06667 deg == 5.06667 deg
>
> I see that 'approx' is used in the codebase which you might hope would
> get all this right, but clearly excessive precision is being used for
> our purposes (cave survey data).
>
> I'm not sure how to fix this.
>
> I've done an upload in the meantime with the previous bodge of the
> tests, and to fix another bug too and let the package migrate to
> testing. But getting the codebase to do what we actually expect would
> be good.
>
> This is the patch I used to try double for angles:
>
> Author: Wookey 
> Last-Update: 2018-03-09
>
> --- dewalls-1.0.0+ds1.orig/src/angle.cpp
> +++ dewalls-1.0.0+ds1/src/angle.cpp
> @@ -3,13 +3,13 @@
>
>  namespace dewalls {
>
> -const long double PI = acosl(-1.0L);
> -const long double DegreesToRadians = PI / 180.0L;
> -const long double GradiansToRadians = PI / 200.0L;
> -const long double MilsNATOToRadians = PI / 3200.0L;
> -const long double RadiansToDegrees = 180.0L / PI;
> -const long double RadiansToGradians = 200.0L / PI;
> -const long double RadiansToMilsNATO = 3200.0L / PI;
> +const double PI = acosl(-1.0L);
> +const double DegreesToRadians = PI / 180.0L;
> +const double GradiansToRadians = PI / 200.0L;
> +const double MilsNATOToRadians = PI / 3200.0L;
> +const double RadiansToDegrees = 180.0L / PI;
> +const double RadiansToGradians = 200.0L / PI;
> +const double RadiansToMilsNATO = 3200.0L / PI;
>
>  QString Angle::Name("angle");
>
> @@ -30,7 +30,7 @@ QString Angle::symbolFor(Unit unit) {
>  }
>  }
>
> -long double Angle::toBase(long double quantity, Unit fromUnit) {
> +double Angle::toBase(double quantity, Unit fromUnit) {
>  switch (fromUnit) {
>  case Radians:
>  return quantity;
> @@ -47,7 +47,7 @@ long double Angle::toBase(long double qu
>  }
>  }
>
> -long double Angle::fromBase(long double quantity, Unit toUnit) {
> +double Angle::fromBase(double quantity, Unit toUnit) {
>  switch (toUnit) {
>  case Radians:
>  return quantity;
> @@ -64,7 +64,7 @@ long double Angle::fromBase(long double
>  }
>  }
>
> -long double Angle::convert(long double quantity, Unit fromUnit, Unit
> toUnit) {
> +double Angle::convert(double quantity, Unit fromUnit, Unit toUnit) {
>  return fromBase(toBase(quantity, fromUnit), toUnit);
>  }
>
> --- dewalls-1.0.0+ds1.orig/src/angle.h
> +++ dewalls-1.0.0+ds1/src/angle.h
> @@ -21,9 +21,9 @@ public:
>
>  static QString Name;
>
> -static long double toBase(long double quantity, Unit fromUnit);
> -static long double fromBase(long double quantity, Unit toUnit);
> -static long double convert(long double quantity, Unit fromUnit, Unit
> toUnit);
> +static double toBase(double quantity, Unit fromUnit);
> +static double fromBase(double quantity, Unit toUnit);
> +static double convert(double quantity, Unit fromUnit, Unit toUnit);
>  static QString symbolFor(Unit unit);
>  };
>
>
>
> Wookey
> --
> Principal hats:  Linaro, Debian, Wookware, ARM
> http://wookware.org/
>
-- 
Phi|ip

Bug#892499: Non-ascii characters broken in d-i (text-based installer)

[Holger Wansing]

> It seems there is something generic broken in the installer.
> A screenshot of the languagechooser screen is attached, where several broken
> characters can be seen (in Arabic, Belarusian, Bulgarian, Chinese, Czech and
> Greek, for example). Please also note the broken alignment of the right frame 
> border.

I managed to boil this down to the build of 2018-03-05:
https://d-i.debian.org/daily-images/amd64/20180305-00:29/

20180302ok
20180303ok
< no build for 2018-03-04, hmm >
20180305broken
20180306broken


Holger


-- 

Created with Sylpheed 3.5.1 under 
D E B I A N   L I N U X   9   " S T R E T C H " .

Registered Linux User #311290 - https://linuxcounter.net/

Bug#892502: bluefish: Non English characters in html document breaks zen coding

[Goran Vulić]

Package: bluefish
Version: 2.2.9-1+b1
Severity: normal

Dear Maintainer,

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

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
Type non English character in html document.
   * What was the outcome of this action?
Zen coding are not working.



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


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

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

Versions of packages bluefish depends on:
ii  bluefish-data2.2.9-1
ii  bluefish-plugins 2.2.9-1+b1
ii  gvfs-backends1.30.4-1
ii  libatk1.0-0  2.22.0-1
ii  libc62.24-11+deb9u1
ii  libcairo-gobject21.14.8-1
ii  libcairo21.14.8-1
ii  libenchant1c2a   1.6.0-11+b1
ii  libgdk-pixbuf2.0-0   2.36.5-2+deb9u1
ii  libglib2.0-0 2.50.3-2
ii  libgtk-3-0   3.22.11-1
ii  libpango-1.0-0   1.40.5-1
ii  libpangocairo-1.0-0  1.40.5-1
ii  libpython2.7 2.7.13-2
ii  libxml2  2.9.4+dfsg1-2.2+deb9u1

bluefish recommends no packages.

Versions of packages bluefish suggests:
ii  chromium [www-browser] 57.0.2987.98-1~deb8u1
ii  csstidy1.4-5
pn  dos2unix   
ii  firefox-esr [www-browser]  52.5.0esr-1~deb9u1
ii  iceweasel  52.5.0esr-1~deb9u1
ii  libxml2-utils  2.9.4+dfsg1-2.2+deb9u1
pn  php-codesniffer
pn  pylint 
ii  tidy   1:5.2.0-2
ii  w3m [www-browser]  0.5.3-34
ii  weblint-perl [weblint] 2.22+dfsg-1

-- no debconf information

Bug#892488: pcre2: FTBFS on mips* - test failures

[Matthew Vernon]

On 9 March 2018 18:47:25 GMT+00:00, Jonathan Nieder  wrote:
>Hi,
>
>Matthew Vernon wrote:
>> On 09/03/18 15:20, James Cowgill wrote:
>
>>> Source: pcre2
>>> Version: 10.31-1
>>> Severity: serious
>[...]
>>> pcre2 FTBFS on mips* with lots of testsuite failures. It looks to me
>>> like the JIT is bust.
>>>
>>> I forwarded the log upstream to the above address. I'll try to take
>a
>>> look at what's causing this.
>>
>> Thanks for the bug report, and the forwarding upstream. Do you want
>me to
>> remove "mips mipsel mips64el" from the list of arches with JIT
>enabled and
>> do a new upload? Or leave it broken now and see what upstream say?
>
>This is blocking git updates from migrating to testing
>(https://qa.debian.org/excuses.php?package=git), so my preference
>would be removing "mips mipsel mips64el" from the list of JIT arches
>for now as a stopgap.
>
>Thanks,
>Jonathan

Hi,

OK. I'll get to this, probably tomorrow.

Regards,

Matthew

Bug#892407: initramfs-tools: scripts/local: ignore /dev/ram*

[Kevin Hilman]

On Thu, Mar 8, 2018 at 6:37 PM, Ben Hutchings  wrote:
> On Thu, 2018-03-08 at 17:08 -0800, Kevin Hilman wrote:
>> I'm not sure exactly what you're referring to, so I guess that means no.
>
> Aren't you using LAVA in conjunction with kernelci?  That's where I've
> seen this odd usage of "root=/dev/ram0" before.

Yes, this came up in the contect of kernelCI.

>> I'm just trying to avoid an unnecessary delay when "root=/dev/ram*" is
>> (mistakenly) used on the command-line when passing in the debian
>> ramdisk.  If that happens, it eventually falls through to the
>> initramfs shell, but not before trying 30 times (with a "sleep 1"
>> between each) to find another ramdisk on /dev/ramX
>
> I'm pretty sure "break" does what you need.

Well, break does what you describe, but not exactly what I need.  I'm
trying to workaround the (mis)use of root=/dev/ramX on the
commandline.  If I could add stuff to the kernel command-line, I would
instead just remove the "root=/dev/ramX" rather than add
"break=premount", but I'm trying to solve the problem for LAVA labs
that we don't control, so we cannot change all the device-types out
there and remove "root=/dev/ram0".

So, back to the patch at hand...

Is there ever a usecase for the debian initrd.img to switch_root to
another initrd/ramdisk?

If so, then my proposed patch is invalid.  If not, then it's a nice
optimization and fixup for (mis)use of root=/dev/ram in conjuction
with an existing initrd/ramdisk.

Kevin

Bug#892501: ITP: r-cran-snowfall -- GNU R easier cluster computing (based on snow)

[Andreas Tille]

Package: wnpp
Severity: wishlist
Owner: Andreas Tille 

* Package name: r-cran-snowfall
  Version : 1.84-6.1
  Upstream Author : Jochen Knaus 
* URL : https://cran.r-project.org/package=snowfall
* License : GPL
  Programming Lang: GNU R
  Description : GNU R easier cluster computing (based on snow)
 Usability wrapper around snow for easier development of
 parallel R programs. This package offers e.g. extended error
 checks, and additional functions. All functions work in
 sequential mode, too, if no cluster is present or wished.
 Package is also designed as connector to the cluster management
 tool sfCluster, but can also used without it.


Remark: This package is needed in BioLinux and thus a sensible target for
the Debian Med team.  The actual packaging will be done by the r-pkg team
at
https://salsa.debian.org/r-pkg-team/r-cran-snowfall

Bug#892500: mitmproxy: Doesn't start with dependency versions currently available in Debian

[Nicolás Alvarez]

Package: mitmproxy
Version: 2.0.2-3
Severity: grave
Justification: renders package unusable

The package has unversioned dependencies like "python3-ruamel.yaml", and
versioned like python3-pyperclip (>= 1.5.22). However,
mitmproxy-2.0.2.egg-info/requires.txt has stricter versioning
requirements, like ruamel.yaml<0.14,>=0.13.2 and pyperclip<1.6,>=1.5.22.

Debian buster currently ships versions newer than what requires.txt
considers "too new", so mitmproxy doesn't start:

pkg_resources.ContextualVersionConflict: (ruamel.yaml 0.15.34 
(/usr/lib/python3/dist-packages), 
Requirement.parse('ruamel.yaml<0.14,>=0.13.2'), {'mitmproxy'})
pkg_resources.DistributionNotFound: The 'ruamel.yaml<0.14,>=0.13.2' 
distribution was not found and is required by mitmproxy

I downgraded python3-ruamel.yaml from 0.15.34-1 to 0.13.4-2+b1 (via 
snapshots.d.o)
and it failed again:
pkg_resources.ContextualVersionConflict: (pyperclip 1.6.0 
(/usr/lib/python3/dist-packages), Requirement.parse('pyperclip<1.6,>=1.5.22'), 
{'mitmproxy'})

After manually downgrading 5 deps I still couldn't get it to run and I gave up.

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

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

Versions of packages mitmproxy depends on:
ii  dpkg  1.19.0.5
ii  fonts-font-awesome4.7.0~dfsg-3
ii  python3   3.6.4-1
ii  python3-blinker   1.4+dfsg1-0.1
ii  python3-brotli1.0.2-3
ii  python3-certifi   2018.1.18-2
ii  python3-configargparse0.11.0-1
ii  python3-construct 2.8.16-0.2
ii  python3-cryptography  2.1.4-1
ii  python3-cssutils  1.0.2-1
ii  python3-flask 0.12.2-3
ii  python3-h23.0.1-3
ii  python3-hpack 3.0.0-2
ii  python3-html2text 2018.1.9-1
ii  python3-hyperframe5.1.0-1
ii  python3-jsbeautifier  1.6.4-6
ii  python3-kaitaistruct  0.7-1
ii  python3-lxml  4.1.0-1
ii  python3-openssl   17.5.0-1
ii  python3-passlib   1.7.1-1
ii  python3-pil   4.3.0-2
ii  python3-pyasn10.4.2-3
ii  python3-pyparsing 2.2.0+dfsg1-2
ii  python3-pyperclip 1.6.0-1
ii  python3-requests  2.18.4-2
ii  python3-ruamel.yaml   0.15.34-1
ii  python3-six   1.11.0-2
ii  python3-sortedcontainers  1.5.7-1
ii  python3-tornado   4.5.3-1
ii  python3-urwid 1.3.1-2+b2
ii  python3-watchdog  0.8.3-2

mitmproxy recommends no packages.

mitmproxy suggests no packages.

-- no debconf information

Bug#889680: Good day

[GRACE FOLLY]

Good day

Blessings to you,am contacting you based on a mutual benefit
inheritance transaction of ($10.5 million US dollars)
that has to do with your last name contact me for more details.
Contact email [ gracefollyt...@gmail.com ]

Regards,
Mrs Grace Folly

Bug#892498: ITP: r-cran-samr -- GNU R significance analysis of microarrays

[Andreas Tille]

Package: wnpp
Severity: wishlist
Owner: Andreas Tille 

* Package name: r-cran-samr
  Version : 2.0
  Upstream Author : R. Tibshirani, G. Chu, Balasubramanian Narasimhan, Jun Li
* URL : https://cran.r-project.org/package=samr
* License : LGPL
  Programming Lang: GNU R
  Description : GNU R significance analysis of microarrays
 This GNU R package provides significance analysis of microarrays.
 A microarray is a multiplex lab-on-a-chip. It is a 2D array on a solid
 substrate (usually a glass slide or silicon thin-film cell) that assays
 large amounts of biological material using high-throughput screening
 miniaturized, multiplexed and parallel processing and detection methods.
 .
 This package helps analysing this kind of microarrays.


Remark: This package is needed in BioLinux and thus a sensible target for
the Debian Med team.  The actual packaging will be done by the r-pkg team
at
https://salsa.debian.org/r-pkg-team/r-cran-samr

Bug#892488: pcre2: FTBFS on mips* - test failures

[Jonathan Nieder]

Hi,

Matthew Vernon wrote:
> On 09/03/18 15:20, James Cowgill wrote:

>> Source: pcre2
>> Version: 10.31-1
>> Severity: serious
[...]
>> pcre2 FTBFS on mips* with lots of testsuite failures. It looks to me
>> like the JIT is bust.
>>
>> I forwarded the log upstream to the above address. I'll try to take a
>> look at what's causing this.
>
> Thanks for the bug report, and the forwarding upstream. Do you want me to
> remove "mips mipsel mips64el" from the list of arches with JIT enabled and
> do a new upload? Or leave it broken now and see what upstream say?

This is blocking git updates from migrating to testing
(https://qa.debian.org/excuses.php?package=git), so my preference
would be removing "mips mipsel mips64el" from the list of JIT arches
for now as a stopgap.

Thanks,
Jonathan

Bug#883965: nm-connection-editor crashes when opening a connection

[BenWiederhake.GitHub]

Heyaloha,

is it possible that this is a duplicate of #865013?

- Both crash Consistently when clicking "modify"
- Both crash in src/libnma/nma-cert-chooser-button.c due to this line:
g_critical (…, error->message);
  (it used to be line 95, currently it's line 98)

Note that I sent in a patch [1], and it got "applied, with a small 
change" [2].  You may want to do the following:


apt-get source network-manager-applet
sudo apt-get build-dep network-manager-applet
fakeroot ./debian/rules binary
sudo dpkg -i ../libnma0*.deb

Plus minus a few 'cd'.

Cheers,
Ben

[1] https://bugzilla.gnome.org/show_bug.cgi?id=785674#c5
[2] 
https://git.gnome.org/browse/network-manager-applet/commit/?id=a37483c1a364ef3cc1cfa29e7ad51ca108d75674

Bug#892355: findutils on testing breaks fslint recursive search

[Andreas Metzler]

On 2018-03-08 "jEsuSdA 8)"  wrote:
[...]
> I have a folder with subfolders, and inside them, there are duplicate files.

> /main-folder/
>   > /sub-folder1/
>   > /sub-folder2/
>   > file-1.jpg
>   > file-2.jpg
>   > file-2-copy.jpg


> If I run fslint-gui inside sub-folder2, when searching for duplicate files,
> fslint detects file2.jpg and file2-copy.jpg are duplicates.

> But, if I run fslint-gui inside main-folder and check "recursive", when
> searching for duplicate files, no one is located, although we know there are
> two duplicate files in sub-folder2.

> If I downgrade the findutils package, fslint-gui is capable to find
> file2.jpg and file-2-copy.jpg as duplicates when searching from main-folder
> recursively.

> I hope been able to explain this issue. ;)



Hello,

thanks for the detailed description. Do you see the error without gui?
I have just tried in vain:

ametzler@argenau:~$ mkdir -p /tmp/main-folder/sub-folder{1,2}/ ; echo 
"identical files" > /tmp/main-folder/sub-folder2/file-2.jpg ; echo "identical 
files" > /tmp/main-folder/sub-folder2/file-2-copy.jpg ; echo different > 
/tmp/main-folder/sub-folder2/file-1.jpg
ametzler@argenau:~$ dpkg -s findutils | grep Version
Version: 4.6.0+git+20170828-2
ametzler@argenau:/tmp$ /usr/share/fslint/fslint/findup /tmp/main-folder
sub-folder2/file-2-copy.jpg
sub-folder2/file-2.jpg

TIA, cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Bug#541538: duplicates and age of this bug

[draeath]

Hello,

it seems that there are several older bugs about this configuration:
#674935 and #674936 (duplicate submission)
#697119

These go back to *early 2012*

Can we maybe get this default configuration value adjusted? We're not
talking about a code patch, here.

Thanks.

Bug#892280: libcdk5: library package needs to be renamed for libncurses6 transition

[Herbert Fortes]

Hi Sven Joachim,

>> My conclusion is that it is very risky to allow such combinations, and
>> to rule them out I propose to change the package name of the cdk
>> library, say to libcdk5a.  It would then have to build-depend on
>> libncurses-dev (>= 6.1+20180210) to ensure that it is linked against
>> libncurses6 and not libncurses5.  Of course this can only be uploaded
>> to experimental for now, but should go to unstable when the ncurses
>> transition starts there.


I am OK with changing the name. But libcdk5a does not say 
much about why the change.

Since the package name will change because of SONAME of 
libncurses, I thought to follow the SONAME of the library.

libcdk5-6

But maybe this will cause misunderstanding. The change is
on version 6.1+20180210.



Regards,
Herbert

Bug#892497: qemu: CVE-2018-7858: cirrus: OOB access when updating vga display allowing for DoS

[Salvatore Bonaccorso]

Source: qemu
Version: 1:2.11+dfsg-1
Severity: important
Tags: security upstream

Hi,

the following vulnerability was published for qemu.

CVE-2018-7858[0]:
cirrus: OOB access when updating vga display

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-7858
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-7858
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1553402

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#892496: yt: please make the build reproducible

[Chris Lamb]

Source: yt
Version: 3.4.0-3
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: fileordering
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

Whilst working on the Reproducible Builds effort [0], we noticed
that yt could not be built reproducibly as it includes a generated
file that has non-determinstic contents.

We shouldn't ship the .c file anyway - it is generated from a .pyx
anyway.


Patch attached.

 [0] https://reproducible-builds.org/


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
diff --git a/debian/rules b/debian/rules
index d2f12a7..8c64866 100755
--- a/debian/rules
+++ b/debian/rules
@@ -17,6 +17,7 @@ override_dh_auto_install:
dh_auto_install
rm 
$(CURDIR)/debian/python-yt/usr/lib/python*/dist-packages/yt/extern/tqdm/LICENSE
rm 
$(CURDIR)/debian/python3-yt/usr/lib/python*/dist-packages/yt/extern/tqdm/LICENSE
+   rm 
$(CURDIR)/debian/python-yt/usr/lib/python*/dist-packages/yt/frontends/artio/_artio_caller.c
rm 
$(CURDIR)/debian/python-yt/usr/lib/python*/dist-packages/yt/frontends/artio/artio_headers/LICENSE
rm 
$(CURDIR)/debian/python3-yt/usr/lib/python*/dist-packages/yt/frontends/artio/artio_headers/LICENSE
mv $(CURDIR)/debian/python-yt/usr/bin/yt 
$(CURDIR)/debian/python-yt/usr/bin/yt2

Bug#892488: pcre2: FTBFS on mips* - test failures

[Matthew Vernon]

Hi,

On 09/03/18 15:20, James Cowgill wrote:

Source: pcre2
Version: 10.31-1
Severity: serious
Tags: sid buster
Forwarded: https://bugs.exim.org/show_bug.cgi?id=2254

Hi,

pcre2 FTBFS on mips* with lots of testsuite failures. It looks to me
like the JIT is bust.

I forwarded the log upstream to the above address. I'll try to take a
look at what's causing this.


Thanks for the bug report, and the forwarding upstream. Do you want me 
to remove "mips mipsel mips64el" from the list of arches with JIT 
enabled and do a new upload? Or leave it broken now and see what 
upstream say?


Regards,

Matthew

Bug#860444: no longer reproducible

[Jeffrey Cliff]

Version annotated: 1.1.4-1 Identified issues:
Identifier: gcc_captures_build_path

Description Captures build path, e.g., /build/1st/foo-42.0 v.
/build/foo-42.0/2nd
Currently we vary the build path only when testing packages from unstable
and experimental, for stretch we recommend that rebuilds are done in the
same
path as the original build.
.
These packages should all be reproducible, because Jenkins is running a
custom
toolchain which contains a patch to fix this specific issue:
.
https://gcc.gnu.org/ml/gcc-patches/2017-04/msg00513.html
.
When this is accepted into GCC upstream, we could remove this note.
In the meantime, please do not remove this issue, nor mark it as
deterministic,
nor untag these packages.

Bug#891656: chromium: uBlock Origin and HTTPS Everywhere crash with 65.0.3325.146-1, not before

[Diederik de Haas]

Package: chromium
Version: 65.0.3325.146-1
Followup-For: Bug #891656

My extensions worked fine with 64.0.3282.119-2+b2 but after having just 
upgraded to
65.0.3325.146-1, both uBlock Origin and HTTPS Everywhere crash.
Started chromium with logging and the part till the 2nd 'Core file will
not be generated' is from the startup and the next 2 parts till that
line are when I subsequently restarted HTTPS Everywhere and then uBlock
Origin.

$ chromium --enable-logging --v=1
[4:83:0309/182811.779112:ERROR:adm_helpers.cc(73)] Failed to query stereo 
recording.
Received signal 11 SEGV_MAPERR ff00
#0 0x56366d21373e 
#1 0x56366ba7004f 
#2 0x56366d213af7 
#3 0x7f955662cf50 
#4 0x7f954ac26010 
#5 0x7f954b5539be std::__cxx11::basic_string<>::compare()
#6 0x56366dd3a92c 
#7 0x56366ce97f3d 
#8 0x56366cea2db5 
#9 0x56366ed01188 
#10 0x56366eb60874 
#11 0x56366eb6b3b3 
#12 0x56366fce2e4b 
#13 0x56366fce35ff 
#14 0x56366fbc0569 
#15 0x56366c62dbc7 
#16 0x56366c6b6f6e 
#17 0x56366c6b7c66 
#18 0x0c04fc88431d 
  r8: 7ffd7854fb78  r9: 7ffd7854fba0 r10: 6e6f63692f706462 r11: 
612d6e6f63692f73
 r12: 7ffd7854fb58 r13: 5636705ec846 r14: 7ffd7854fd18 r15: 
7ffd7854fbc8
  di: ff00  si: 5636705ec846  bp: 0001  bx: 
7ffd7854fbb0
  dx: 0001  ax: 0001  cx: 0846  sp: 
7ffd7854fa08
  ip: 7f954ac26010 efl: 00010246 cgf: 002b0033 erf: 
0004
 trp: 000e msk:  cr2: ff00
[end of stack trace]
Calling _exit(1). Core file will not be generated.
Received signal 11 SEGV_MAPERR ff00
#0 0x56366d21373e 
#1 0x56366ba7004f 
#2 0x56366d213af7 
#3 0x7f955662cf50 
#4 0x7f954ac26010 
#5 0x7f954b5539be std::__cxx11::basic_string<>::compare()
#6 0x56366dd3a92c 
#7 0x56366ce97f3d 
#8 0x56366cea2db5 
#9 0x56366ed01188 
#10 0x56366eb60874 
#11 0x56366eb6b3b3 
#12 0x56366fce2e4b 
#13 0x56366fce35ff 
#14 0x56366fbc0569 
#15 0x56366c62dbc7 
#16 0x56366c6b6f6e 
#17 0x56366c6b7c66 
#18 0x2f7217f8431d 
  r8: 7ffd7854fb98  r9: 7ffd7854fbc0 r10: 0067 r11: 
7f954ac51160
 r12: 7ffd7854fb78 r13: 5636705ec846 r14: 7ffd7854fd38 r15: 
7ffd7854fbe8
  di: ff00  si: 5636705ec846  bp: 0001  bx: 
7ffd7854fbd0
  dx: 0001  ax: 0001  cx: 0846  sp: 
7ffd7854fa28
  ip: 7f954ac26010 efl: 00010246 cgf: 002b0033 erf: 
0004
 trp: 000e msk:  cr2: ff00
[end of stack trace]
Calling _exit(1). Core file will not be generated.
[10025:10060:0309/182812.486101:ERROR:upload_data_presenter.cc(73)] Not 
implemented reached in virtual void 
extensions::RawDataPresenter::FeedNext(const net::UploadElementReader&)
libpng warning: iCCP: known incorrect sRGB profile
Received signal 11 SEGV_MAPERR ff00
#0 0x56366d21373e 
#1 0x56366ba7004f 
#2 0x56366d213af7 
#3 0x7f955662cf50 
#4 0x7f954ac26010 
#5 0x7f954b5539be std::__cxx11::basic_string<>::compare()
#6 0x56366dd3a92c 
#7 0x56366ce97f3d 
#8 0x56366cea2db5 
#9 0x56366ed01188 
#10 0x56366eb60874 
#11 0x56366eb6b3b3 
#12 0x56366fce2e4b 
#13 0x56366fce35ff 
#14 0x56366fbc0569 
#15 0x56366c62dbc7 
#16 0x56366c6b6f6e 
#17 0x56366c6b7c66 
#18 0x0eeb1e18431d 
  r8: 7ffd7854fb78  r9: 7ffd7854fba0 r10: 6e6f63692f706462 r11: 
612d6e6f63692f73
 r12: 7ffd7854fb58 r13: 5636705ec846 r14: 7ffd7854fd18 r15: 
7ffd7854fbc8
  di: ff00  si: 5636705ec846  bp: 0001  bx: 
7ffd7854fbb0
  dx: 0001  ax: 0001  cx: 0846  sp: 
7ffd7854fa08
  ip: 7f954ac26010 efl: 00010246 cgf: 002b0033 erf: 
0004
 trp: 000e msk:  cr2: ff00
[end of stack trace]
Calling _exit(1). Core file will not be generated.
[646:663:0309/182912.646104:ERROR:adm_helpers.cc(73)] Failed to query stereo 
recording.
Received signal 11 SEGV_MAPERR ff00
#0 0x56366d21373e 
#1 0x56366ba7004f 
#2 0x56366d213af7 
#3 0x7f955662cf50 
#4 0x7f954ac26010 
#5 0x7f954b5539be std::__cxx11::basic_string<>::compare()
#6 0x56366dd3a92c 
#7 0x56366ce97f3d 
#8 0x56366cea2db5 
#9 0x56366ed01188 
#10 0x56366eb60874 
#11 0x56366eb6b3b3 
#12 0x56366fce2e4b 
#13 0x56366fce35ff 
#14 0x56366fbc0569 
#15 0x56366c62dbc7 
#16 0x56366c6b6f6e 
#17 0x56366c6b7c66 
#18 0x0b55c1c8431d 
  r8: 7ffd7854fb78  r9: 7ffd7854fba0 r10: 2f676d692f6d6761 r11: 
69726573776f7262
 r12: 7ffd7854fb58 r13: 5636705ec846 r14: 7ffd7854fd18 r15: 
7ffd7854fbc8
  di: ff00  si: 5636705ec846  bp: 0001  bx: 
7ffd7854fbb0
  dx: 0001  ax: 0001  cx: 0846  sp: 
7ffd7854fa08
  ip: 7f954ac26010 efl: 00010246 cgf: 002b0033 erf: 
0004
 trp: 000e msk:  cr2: ff00
[end of stack 

Bug#892495: ITP: python3-aiohttp-swagger -- Swagger API Documentation builder for aiohttp server

[Joel Cross]

Package: wnpp
Severity: wishlist
Owner: Joel Cross 

* Package name: python3-aiohttp-swagger
  Version : 1.0.5
  Upstream Author : Daniel Garcia 
* URL : https://github.com/cr0hn/aiohttp-swagger
* License : BSD
  Programming Lang: Python
  Description : Swagger API Documentation builder for aiohttp server

aiohttp-swagger is a plugin for aiohttp.web server that allows an API developer
to document APIs using Swagger and the Swagger-ui console.

I am interested in packaging a project that depends on this library, hence why
I am packaging this library.

Bug#892494: diceware: "diceware" name violates trademark

[Simon Fondrie-Teitler]

Source: diceware
Severity: serious
Tags: upstream
Justification: Policy 2.1

As stated in the footer of http://world.std.com/%7Ereinhold/diceware.html the 
original creator of diceware claims a trademark on the name. I've filed a bug 
with upstream here: https://github.com/ulif/diceware/issues/48

Upstream does not have permission from Arnold Reinhold to use the trademark, 
but is aware of the issue and has reached out to Reinhold with no response. 
This package should probably be removed or renamed if upstream does not get a 
response soon.

Bug#823624: tgz etc. in @ARCHIVE_EXT@

[Pierre-Elliott Bécue]

Le vendredi 09 mars 2018 à 17:45:44+0100, Pierre-Elliott Bécue a écrit :
> Le samedi 10 mars 2018 à 01:21:20+0900, Osamu Aoki a écrit :
> > Hi,
> > 
> > Yes this looks trivial patch which I chose not to add complication at
> > one point in history.  But people insist and applied patch ...
> > 
> > Whoever take responsibility for this patch need to read all other parts
> > of code too.  By adding this convenience feature, signature check and
> > repacking code may not function as documented unless you add handling
> > code for them. --- This was my reason not adding these.  Now you are-in.
> > Please continue your work on uscan ;-)  Welcome to uscan maintenance.
> 
> Hi,
> 
> I'm not sure to understand how this could induce any issue? People already
> put tgz or other extensions in their d/watch file[1] and this seems to work
> properly so far.
> 
> This piece of code is just designed to replace @ARCHIVE_EXT@ and
> @SIGNATURE_EXT@ by a regexp. These are never used in the remaining portions
> of uscan.pl or mk-origtargz.pl.
> 
> Could you help me at seeing how these changes might introduce any issue?
> 
> Cheers. :)

To be more specific, I reviewed your changes introducing these lines of code
before applying the patch. The commit that introduced the @ARCHIVE_EXT@
feature is
https://salsa.debian.org/debian/devscripts/commit/8ebab1c2bfa97830ca670d6830444297910282c7

Seeing that, I determined that adding extensions wouldn't break uscan any
more than it could be by having directly these in d/watch files.

-- 
Pierre-Elliott Bécue
GPG: 9AE0 4D98 6400 E3B6 7528  F493 0D44 2664 1949 74E2
It's far easier to fight for one's principles than to live up to them.


signature.asc
Description: PGP signature