Bug#892401: squid3: build-depends on GCC 6

[Amos Jeffries]

For the record, the intention is not to include the squid3 package in
Buster. Squid-4 packages intended for buster are currently in
experimental awaiting upstream stable release.

Amos

Bug#896063: Aw: Re: gcc-default-ports: cross compiler for RISC-V 32bit

[Heinrich Schuchardt]

I do not need glibc, just the toolchain for Risk-V 32 bit:

gcc, ld, objdump, gdb
Am 20.04.18, 06:40, Paul Wise  schrieb:
On Fri, Apr 20, 2018 at 12:05 PM, Karsten Merker wrote:

> I'm CCing the debian-riscv list in case somebody there should
> have further insights regarding riscv32 support in glibc.

I think Heinrich was looking for a bare-metal compiler for
microcontroller-class RISC-V rather than one for a hypothetical Debian
riscv32 port?

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Bug#896115: RFS: python-cerberus/1.2-1 [ITP]

[Sergio Durigan Junior]

On Thursday, April 19 2018, Joel Cross wrote:

>   Dear mentors,
>
>   I am looking for a sponsor for my package "python-cerberus"
>
>  * Package name: python-cerberus
>Version : 1.2-1
>Upstream Author : Nicola Iarocci 
>  * URL : http://github.com/pyeve/cerberus
>  * License : ISC
>Section : python
>
>   It builds those binary packages:
>
> python-cerberus-doc - Documentation for python3-cerberus
>  python3-cerberus - Lightweight, extensible data validation library for Python

Thanks for the package, Joel.  A few nits, mostly small:

1) The d/control file is missing a Vcs-Browser field, which informs the
URL where the git repository can be visited using a web browser.  It
should be:

  Vcs-Browser: https://salsa.debian.org/joelcross-guest/python-cerberus

2) On d/rules, there's no need to override dh_compress.  It
automatically excludes HTML files when compressing things.

3) Because your package installs online documentation, you'll need to
provide a .doc-base file for the -doc package.  Look at:

  


for an example, and at:

  

for more info.

4) You can enable the testsuite from autopkgtest to run automatically on
Python packages.  On d/control, just use:

  Testsuite: autopkgtest-pkg-python

5) Thanks for taking care of the privacy issue with a patch on
d/patches/.  Just one nit: you don't actually need the disclaimer "The
information above should follow...".  Please remove that.  And do you
think upstream would consider this patch?  I think it's worth trying
sending it.

Also, still on the topic of patch management, it's a good practice to
not push the "patch-queue/master" branch to the official repository.

6) There are a bunch of spelling errors in the manpage.  You can see
them by using:

  lintian -EI --pedantic python-cerberus_1.2-1_amd64.changes

You might consider fixing them in another patch, and submitting the fix
upstream as well.  But I'm OK with uploading the package with these
spelling errors initially, and fixing them later.

7) You will want to install CHANGES.rst as the changelog file.  Just
override dh_installchangelogs:

  override_dh_installchangelogs:
  dh_installchangelogs CHANGES.rst




Other than that, the package is ready for upload.  Let's just wait until
you're accepted into the Debian Python team (so you can move the
repository to the official Debian Python namespace on salsa and change
the Vcs-* fields accordingly), and then I will happily upload it.

Thanks,

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


signature.asc
Description: PGP signature

Bug#896120: squid: Squid 4: Please enable acl proxy_auth -i again

[Amos Jeffries]

forwarded +1 https://bugs.squid-cache.org/show_bug.cgi?id=4847
thanks

Bug#857230: [Pkg-sugar-devel] Bug#857230: closed by Santiago Ruano Rincón <santi...@debian.org> (Bug#857230: fixed in sugar 0.112-4)

[James Cameron]

On Thu, Apr 19, 2018 at 04:02:12PM +0200, Michael Biebl wrote:
> Am 19.04.2018 um 11:06 schrieb Debian Bug Tracking System:
> >  sugar (0.112-4) unstable; urgency=medium
> >  .
> >* Stop depending on gir1.2-nmgtk-1.0 (Closes: #857230)
> 
> Hm, you dropped the dependency, but I don't think this is actually a
> proper fix, as I still see this in the code:
> 
> $ grep import -R | grep NM
> extensions/cpsection/network/model.py:from gi.repository import NMClient
> 
> I.e., sugar still uses the old libnm-glib based GIR bindings (
> gir1.2-networkmanager-1.0 to be precise).

Agreed.

> The code should be ported to use gir1.2-nm-1.0, the libnm based GIR
> bindings.

Takes longer to talk about it than do it.  ;-)

Nobody told upstream.  Upstream has ported now.  You may cherry-pick.

https://github.com/sugarlabs/sugar/commit/04c63f6dd2b6f10a80376a43c735822f5283bda7

For your interest, neither the new nor the old API actually works on
recent Debian or Ubuntu; silently failing.

https://github.com/sugarlabs/sugar/issues/794

-- 
James Cameron
http://quozl.netrek.org/

Bug#896137: ITP: rebound -- Command-line tool to fetch Stack Overflow results when program execution error

[林上智]

Package: wnpp
Severity: wishlist
Owner: SZ Lin (林上智) 
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name: rebound
  Version : 1.6
  Upstream Author : Jonathan Shobrook 
* URL : https://github.com/shobrook/rebound
* License : Expat
  Programming Lang: Python
  Description:  Command-line tool to fetch Stack Overflow results when
program execution error

 Rebound is a command-line tool that instantly fetches
 Stack Overflow results when getting a program execution
 error in Python and Node.js. This tool will execute the
 program, pull the error message if needed, and display
 related Stack Overflow questions and answers without
 leaving the terminal.
 .
 Features
 .
 - Supported file types: Python and Node.js
 - View answers in command line mode
 - Open browser for GUI
 .
 rebound is under Expat
--

SZ Lin (林上智) , http://people.debian.org/~szlin

Debian Developer

4096R/ 178F 8338 B314 01E3 04FC 44BA A959 B38A 9561 F3F9

Bug#895993: squid3 packages need SSL support

[Amos Jeffries]

reassign 641944 squid
merge 641944 895993
thanks

Due to license issues while using OpenSSL in squid code-base an
SSL-enabled version of Squid cannot be uploaded to the main repository.
I'm merging this bug with the other one asking for SSL support.

FWIW; the Squid-4 packages are coming with GnuTLS support for basic TLS
operations. OpenSSL is also working on a license change. Both are
ongoing works.


Cheers,
Amos

Bug#896063: gcc-default-ports: cross compiler for RISC-V 32bit

[Paul Wise]

On Fri, Apr 20, 2018 at 12:05 PM, Karsten Merker wrote:

> I'm CCing the debian-riscv list in case somebody there should
> have further insights regarding riscv32 support in glibc.

I think Heinrich was looking for a bare-metal compiler for
microcontroller-class RISC-V rather than one for a hypothetical Debian
riscv32 port?

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Bug#881785: gnome-session-flashback: input source does not show input mode

[ciel]

How is this going? I cannot use gnome-flashback and need to use mate.

2017-11-15 11:36 GMT+09:00 T Yamada :
> Package: gnome-session-flashback
> Version: 3.22.0-3
> Severity: important
> Tags: patch
>
> Dear Maintainer,
>
> *** Reporter, please consider answering these questions, where appropriate ***
>
> gnome-session-flashback's input source does not show input mode, so I cannot
> select Hiragana in ibus-mozc.
>
> It is fixed in upstream: https://bugzilla.gnome.org/show_bug.cgi?id=788547
> Debian buster is ok, but stretch will not have gnome 3.26... So could you
> backport the fix to 3.22?
>
> *** End of the template - remove these template lines ***
>
>
>
> -- System Information:
> Debian Release: 9.2
>   APT prefers stable-updates
>   APT policy: (500, 'stable-updates'), (500, 'stable')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 4.9.0-4-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 gnome-session-flashback depends on:
> ii  gnome-flashback3.22.0-3
> ii  gnome-panel3.20.1-1+b2
> ii  gnome-session-bin  3.22.3-1
> ii  gnome-session-common   3.22.3-1
> ii  gnome-settings-daemon  3.22.2-2+deb9u2
> ii  metacity   1:3.22.1-1
> ii  nautilus   3.22.3-1+deb9u1
>
> Versions of packages gnome-session-flashback recommends:
> ii  gnome-power-manager  3.22.2-2
> ii  gnome-screensaver3.6.1-7+b2
>
> Versions of packages gnome-session-flashback suggests:
> ii  desktop-base  9.0.2+deb9u1
> ii  gnome-keyring 3.20.0-3
> ii  gnome-user-guide  3.22.0-1
>
> -- no debconf information

Bug#896063: gcc-default-ports: cross compiler for RISC-V 32bit

[Karsten Merker]

On Thu, Apr 19, 2018 at 07:58:13AM +0200, Heinrich Schuchardt wrote:

> Source: gcc-defaults-ports
> Version: 1.176
> Severity: wishlist
> 
> Dear Maintainer,
> 
> we have a package to cross compile RISC-V 64-bit (gcc-riscv64-linux-gnu).
> 
> Could you, please, also provide a similar package to cross compile RISC-V
> 32-bit.
> 
> This package is needed when developing software for 32-bit embedded RISC-V
> systems.

Hello,

providing a gcc-riscv32-linux-gnu cross-compiler in Debian
unfortunately isn't possible yet as upstream glibc currently has
only support for riscv64, but not for riscv32.  Making
predictions about the future is obviously difficult, but from
looking at the current state of development I would guess that
riscv32 support probably won't make it into the glibc 2.28
release which is planned for August 1, 2018, so we are probably
talking about a timeframe of "sometime in 2019".

I'm CCing the debian-riscv list in case somebody there should
have further insights regarding riscv32 support in glibc.

Regards,
Karsten
-- 
Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung
sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der
Werbung sowie der Markt- oder Meinungsforschung.

Bug#895235: sugar-toolkit-gtk3 FTBFS: devlibs error: There is no package matching [libfribidi0-dev] and noone provides it

[Jeremy Bicha]

Control: reassign -1 d-shlibs 0.82

The build itself completes fine. If pango were broken, I'd expect a
lot more bug reports.

But it's the d-shlibmove command that fails. Note this line in the build log:

> devlibs error: There is no package matching [libfribidi0-dev] and noone
> provides it, please report bug to d-shlibs maintainer

Therefore I am reassigning.

Thanks,
Jeremy Bicha

Bug#661008: dovecot-imapd: Corrupted index cache file

[Dominic Schallert]

Following up on my previous email, we fixed the issue by enabling

maildir_broken_filename_sizes = yes

Kind Regards
Dominic

Bug#895184: roundcube: CVE-2018-9846: check_request() bypass in archive plugin

[Salvatore Bonaccorso]

Hi Guilhem,

Thanks for following up for stretch. First a quick comment. Please
always CC t...@security.debian.org on such questions for if an update
is wanted for DSA. This alows team members to better share the load
for review, release, etc ... (and it's recorded futhermore on the team
alias).

On Wed, Apr 18, 2018 at 09:27:36PM +0200, Guilhem Moulin wrote:
> Hi Salvatore,
> 
> On Sun, 08 Apr 2018 at 10:27:10 +0200, Salvatore Bonaccorso wrote:
> > The following vulnerability was published for roundcube.
> > 
> > CVE-2018-9846[0]:
> > | In Roundcube from versions 1.2.0 to 1.3.5, with the archive plugin
> > | enabled and configured, it's possible to exploit the unsanitized,
> > | user-controlled "_uid" parameter (in an archive.php
> > | _task=mail_mbox=INBOX_action=plugin.move2archive request) to 
> > perform
> > | an MX (IMAP) injection attack by placing an IMAP command after a %0d%0a
> > | sequence. NOTE: this is less easily exploitable in 1.3.4 and later
> > | because of a Same Origin Policy protection mechanism.
> > 
> > If you fix the vulnerability please also make sure to include the
> > CVE (Common Vulnerabilities & Exposures) id in your changelog entry.
> 
> 1.2.8 was released yesterday.  Attached is a debdiff with the following
> upstream commits cherry-picked (ignoring changes to CHANGELOG):
> 
> 
> https://github.com/roundcube/roundcubemail/commit/cdeb6234a2e029c499898c3432fdf5b2cf093640
> 
> https://github.com/roundcube/roundcubemail/commit/5b7e9a2c960eb4fd2364921297020a5dcd2d7dbc
> 
> https://github.com/roundcube/roundcubemail/commit/c69b851b8a704f6483ec9d1cae7cd1ecd33c3343
> 
> https://github.com/roundcube/roundcubemail/commit/7901047474729a7f466eb8c59c92a36fc7cf0e70
> 
> Should we go via stretch-security, or aim for the next stable point
> release?

I think we should release this through stretch-security. The debdiff
per se looks already good. Were you able to test the update in
production under stretch?

There is though one no-dsa issue,
https://security-tracker.debian.org/tracker/CVE-2018-171 which
would be good to be included. Could you backport that fix as well and
send a new debdiff for quick review+ack for upload?

Regards,
Salvatore

Bug#892664: dpkg: Please add support for zstd (Zstandard) compressed packages

[Guillem Jover]

Hi!

On Wed, 2018-04-18 at 11:56:27 +0200, Balint Reczey wrote:
> On Mon, Apr 16, 2018 at 3:51 AM, Balint Reczey
>  wrote:
> > On Sun, Mar 18, 2018 at 3:38 AM, Guillem Jover  wrote:
> >> On Sun, 2018-03-11 at 21:51:05 +0100, Balint Reczey wrote:
> >>> Package: dpkg
> >>> Version: 1.19.0.5
> >>> Severity: wishlist
> >>> Tags: patch
> >>
> >>> Please add support for Zstandard compression to dpkg and other
> >>> programs generated by the dpkg source package [1].
> >>
> >> Thanks. I started implementing this several weeks ago after having
> >> discussed it with Julian Andres Klode on IRC, but stopped after seeing
> >> the implementation getting messy given the current code structure.
> >
> > I think it is not that bad. :-)

Well, that file is a mess already. :)

> >> So, the items that come to mind (most from the dpkg FAQ [F]:
> >>
> >> * Availability in general Unix systems would be one. I think the code
> >>   should be portable, but I've not checked properly.
> >
> > The libzstd package does not have any special dependency and there are
> > packages for other Unix-like systems [2][3][4].

Right, as suspected, but it's nice to get confirmation, thanks.

> >> * Size of the shared library another, it would be by far the fattest
> >>   compression lib used by dpkg. It's not entirely clear whether the
> >>   shlib embeds a zlib library?
> >
> > I agree that the libzstd library is fairly big and I'd like to look
> > into ways of making it leaner, maybe creating a variant with limited
> > features covering what is needed in dpkg, apt, btrfs-progs and other
> > system packages.

That could be an option, ideally sanctioned by upstream to avoid a
perpetual fork, and possible divergence from upstream format, encoding,
etc.

> > It does not seem to embed the zlib library, but it offers many
> > features which may be obsolete for dpkg.
> >
> > I tried dropping support for legacy file formats for example
> > (ZSTD_LEGACY_SUPPORT=8) and the size of the library dropped to 382K
> > from the original 490K.

Still a pretty fat. :)

> >> * Increase in the (build-)essential set (directly and transitively).
> >
> > Yes, that's true, while apt also started supporting Zstd and .

apt is not part of the essential-set though.

> >> * It also seems the format has changed quite some times already, and
> >>   it's probably the reason for the fat shlib. Not sure if the format
> >>   has stabilized enough to use this as good long-term storage format,
> >>   and what's the policy regarding supporting old formats for example,
> >>   given that this is intended mainly to be used for real-time and
> >>   streaming content and similar. For example the Makefile for libzstd
> >>   defaults to supporting v0.4+ only, which does not look great.
> >
> > Format stability is a very valid concern and upstream claims the
> > current format to be stable [5] (since zstd v0.8.1).

I understand that to mean the current format will not change, but what
will happen when and iff a new format is needed/wanted, what's their
stability guarantees, etc.? As I mentioned, one thing is to target
streaming compression, the other long-term storage; the time-frames
expected from each of those might be completely opposite.

> >> * The license seems fine, as being very permissive, or it could affect
> >>   availability. This one I need to add to the FAQ.
> >> * Memory usage seemed fine or slight better depending on the compression
> >>   level, but not when wanting equal or less space used?
> >> * Space used seemed worse.
> >
> > Yes, space used is worse than with xz compression, but I think the
> > much better compression and decompression speed would make up for
> > that.

That still depends at least on the local hardware used and on the
network speed.

> >> * Compression and decompression speed seemed better depending on the
> >>   compression and decompression levels.
> >>
> >> [F] 
> >> 
> >>
> >> Overall I'm still not sure whether this is worth it. Also the
> >> tradeoffs for stable are different to unstable/testing, or for
> >> fast/slow networks, or long-term storage, one-time installations,
> >> or things like CI and similar.
> >>
> >> In any case this would still need discussion on debian-devel, and
> >> involvement from other parts of the project, at least ftp-masters for
> >> example. And whether the added "eternal" support makes sense if we are
> >> or not planning to eventually switch to the compressor as the default,
> >> for example, etc.
> >
> > I agree that the tradeoffs are very different for the use cases and
> > please feel free to bring this topic to debian-devel quoting any part
> > of my emails.

I'll try to do that probably tomorrow. I'll probably start the
conversation and CC you guys, so that you can chime in and fill in any
blanks/details you want to provide.

> >>> $ rm -rf firefox-xz/* ;time  

Bug#894602: [dpkg] Strange cron error mails from executing /etc/cron.daily/dpkg

[Guillem Jover]

On Thu, 2018-04-12 at 18:45:48 +0200, Dirk Heinrichs wrote:
> Am 12.04.2018 um 14:16 schrieb Guillem Jover:
> > Do you perhaps have something like unattended-ugrades or something
> > similar enabled on all those hosts?
> 
> No, I don't. That's one of the packages I uninstall immediately ;-)

Then I'm afraid I'm a bit at a loss here. Could you check your
dpkg.log files and compare times with when those errors occurred on
those hosts, to try to see whether there was some dpkg invoked at the
same time?

Thanks,
Guillem

Bug#893806: tiff: CVE-2018-8905: heap-based buffer overflow in LZWDecodeCompat

[Hugo Lefeuvre]

Hi,

My current understanding of the problem (based on investigations on
latest master, but also valid for older versions):

The code_t string type is defined as a kind of chained list. Each entry
contains:

. a pointer to the next string entry
. a length field indicating the remaining length of the string

This length field includes the current entry.

. a value field containing the current string character
. the first character of the string

In the affected source code

> do {
> *--tp = codep->value;
> } while ( (codep = codep->next) != NULL );

we read such a string and put the values into a buffer (in reverse order, but,
well, it doesn't matter).

Here we assume that the string always has the size it claims to have in its
length field.

But it's not the case with the reproducer. There is a list that claims to have
only one character but defines two, so we continue to read and write to the
buffer even if we are already OOB.

So now the question is: why is that happening ? Is it directly user input or is
coming from an earlier bug in the source code ?

Even if I can't reproduce the issue with the original reproducer, the
versions in Wheezy, Jessie and Stretch are likely to be affected because
the affected code is present.

I'm going to continue my investigations, try to prepare a poc for older
versions, prepare a patch for latest master and backport it to Wheezy
(+ Jessie & Stretch if needed).

Regards,
 Hugo

-- 
 Hugo Lefeuvre (hle)|www.owl.eu.com
4096/ 9C4F C8BF A4B0 8FC5 48EB 56B8 1962 765B B9A8 BACA


signature.asc
Description: PGP signature

Bug#895234: libcommons-lang3-java: update for OpenJDK 10 and OpenJDK 11

[Tiago Daitx]

As per LP: #1765570 [1] I have been able to simplify the required
build steps to 3 simpler steps:

1) Apply the newly attached debdiff that includes the required patches
and overrides build/test/install targets, rebuild
2) Rebuild surefire, make sure the debian binary from step #1 is used
during build time
3) Rebuild this package without the 3 build/test/install overrides,
make sure the debian binaries from steps #1 and #2 are included during
build time

cheers!

References:
[1] https://bugs.launchpad.net/bugs/1765570
diff -Nru libcommons-lang3-java-3.5/debian/changelog libcommons-lang3-java-3.5/debian/changelog
--- libcommons-lang3-java-3.5/debian/changelog	2018-04-16 09:30:12.0 -0300
+++ libcommons-lang3-java-3.5/debian/changelog	2018-04-19 22:43:40.0 -0300
@@ -1,3 +1,16 @@
+libcommons-lang3-java (3.5-3) UNRELEASED; urgency=medium
+
+  * debian/patches/fix-openjdk-10-nullpointer-lang-1365.diff: calls to
+org.apache.commons.lang3.SystemUtils.isJavaVersionAtLeast cause
+NullPointerException when running under openjdk-10 which in turn causes
+other packages to FTBFS with the message "Execution default-cli of goal
+groupId:artifactId:version:jar failed.: NullPointerException -> [Help 1]".
+LP: #1765570. (Closes: #895234)
+  * debian/patches/fix-numeric-3-area-code-support-lang-1312.diff: pull
+upstream fix for numeric-3 area code support. (Closes: #895583)
+
+ -- Tiago Stürmer Daitx   Fri, 20 Apr 2018 01:43:40 +
+
 libcommons-lang3-java (3.5-2) unstable; urgency=medium
 
   * Team upload.
diff -Nru libcommons-lang3-java-3.5/debian/patches/fix-numeric-3-area-code-support-lang-1312.diff libcommons-lang3-java-3.5/debian/patches/fix-numeric-3-area-code-support-lang-1312.diff
--- libcommons-lang3-java-3.5/debian/patches/fix-numeric-3-area-code-support-lang-1312.diff	1969-12-31 21:00:00.0 -0300
+++ libcommons-lang3-java-3.5/debian/patches/fix-numeric-3-area-code-support-lang-1312.diff	2018-04-19 22:43:40.0 -0300
@@ -0,0 +1,65 @@
+Description: Fix UN M.49 numeric-3 area code support.
+ LocaleUtils#toLocale does not support language followed by UN M.49 numeric-3
+ area code. 
+Author: pascalschumacher 
+Origin: upstream, https://github.com/apache/commons-lang/pull/239
+Bug: https://issues.apache.org/jira/browse/LANG-1312
+Bug-Debian: https://bug.debian.org/895234
+Forwarded: not-needed
+Applied-Upstream: https://github.com/apache/commons-lang/commit/4bd982d1a1df87724682c17c39bf27b5cbe389be
+Reviewed-by: Tiago Stürmer Daitx 
+Last-Update: 2018-04-13
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+
+From 4bd982d1a1df87724682c17c39bf27b5cbe389be Mon Sep 17 00:00:00 2001
+From: pascalschumacher 
+Date: Sun, 19 Feb 2017 20:39:05 +0100
+Subject: [PATCH] LANG-1312: LocaleUtils#toLocale does not support language
+ followed by UN M.49 numeric-3 area code (closes #239)
+
+---
+ src/main/java/org/apache/commons/lang3/LocaleUtils.java | 4 +++-
+ src/test/java/org/apache/commons/lang3/LocaleUtilsTest.java | 7 +++
+ 3 files changed, 11 insertions(+), 1 deletion(-)
+
+diff --git a/src/main/java/org/apache/commons/lang3/LocaleUtils.java b/src/main/java/org/apache/commons/lang3/LocaleUtils.java
+index a3126ebf4..f13b52f38 100644
+--- a/src/main/java/org/apache/commons/lang3/LocaleUtils.java
 b/src/main/java/org/apache/commons/lang3/LocaleUtils.java
+@@ -67,6 +67,7 @@ public LocaleUtils() {
+  *   LocaleUtils.toLocale("")   = new Locale("", "")
+  *   LocaleUtils.toLocale("en") = new Locale("en", "")
+  *   LocaleUtils.toLocale("en_GB")  = new Locale("en", "GB")
++ *   LocaleUtils.toLocale("en_001") = new Locale("en", "001")
+  *   LocaleUtils.toLocale("en_GB_xxx")  = new Locale("en", "GB", "xxx")   (#)
+  * 
+  *
+@@ -134,7 +135,8 @@ public static Locale toLocale(final String str) {
+ case 1:
+ if (StringUtils.isAllLowerCase(split[0]) &&
+ (split[0].length() == 2 || split[0].length() == 3) &&
+- split[1].length() == 2 && StringUtils.isAllUpperCase(split[1])) {
++ (split[1].length() == 2 && StringUtils.isAllUpperCase(split[1])) ||
++  (split[1].length() == 3 && StringUtils.isNumeric(split[1]))) {
+ return new Locale(split[0], split[1]);
+ }
+ throw new IllegalArgumentException("Invalid locale format: " + str);
+diff --git a/src/test/java/org/apache/commons/lang3/LocaleUtilsTest.java b/src/test/java/org/apache/commons/lang3/LocaleUtilsTest.java
+index 4a867bab1..79198af5b 100644
+--- a/src/test/java/org/apache/commons/lang3/LocaleUtilsTest.java
 b/src/test/java/org/apache/commons/lang3/LocaleUtilsTest.java
+@@ -505,6 +505,13 @@ public void testLang328() {
+ assertValidToLocale("fr__POSIX", "fr", "", "POSIX");
+ }
+ 
++   

Bug#896136: [uscan] Git mode fails to download due to custom pretty format

[Lumin]

Package: devscripts
Version: 2.18.1

Hi,

uscan failes to download upstream tarball from this watch file

version=4
opts="mode=git, pgpmode=none, pretty=0~%cd-g%h" \
https://github.com/google/farmhash \
HEAD debian uupdate

the error log is shown at [1].
However if I remove the custom pretty format, the error will disappear.

[1]

uscan info: Upstream URL(+tag) to download is identified as
https://github.com/google/farmhash HEAD
uscan info: Filename (filenamemangled) for downloaded file:
farmhash-0~20171030-g2f0e005.tar.xz
uscan: Newest version of farmhash on remote site is
0~20171030-g2f0e005, local version is 0~20170626-g23eecfb
uscan:=> Newer package available from
  https://github.com/google/farmhash HEAD
uscan info: Downloading upstream package: farmhash-0~20171030-g2f0e005.tar.xz
uscan info: Execute: git
--git-dir=../farmhash-0~20171030-temporary.21832.git archive
--format=tar --prefix=farmhash-0~20171030-g2f0e005/
--output=/home/lumin/packages/farmhash.pkg/farmhash/../farmhash-0~20171030-g2f0e005.tar
HEAD
fatal: not a git repository: '../farmhash-0~20171030-temporary.21832.git'
uscan die: git archive failed



-- 
Best,

Bug#896115: RFS: python-cerberus/1.2-1 [ITP]

[Sergio Durigan Junior]

Control: owner -1 !

On Thursday, April 19 2018, Joel Cross wrote:

>   Dear mentors,
>
>   I am looking for a sponsor for my package "python-cerberus"
>
>  * Package name: python-cerberus
>Version : 1.2-1
>Upstream Author : Nicola Iarocci 
>  * URL : http://github.com/pyeve/cerberus
>  * License : ISC
>Section : python
>
>   It builds those binary packages:
>
> python-cerberus-doc - Documentation for python3-cerberus
>  python3-cerberus - Lightweight, extensible data validation library for Python
>
>   To access further information about this package, please visit the following
> URL:
>
>   https://mentors.debian.net/package/python-cerberus
>
>
>   Alternatively, one can download the package with dget using this command:
>
> dget -x https://mentors.debian.net/debian/pool/main/p/python-
> cerberus/python-cerberus_1.2-1.dsc
>
>   More information about Cerberus can be obtained from http://python-
> cerberus.org/.
>
>   Regards,
>Joel Cross

Thanks for your interest.  I'll review this package.

Cheers,

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


signature.asc
Description: PGP signature

Bug#896132: thermald uninitialised member causes loss of temperature control

[Ben Caradoc-Davies]

I added a comment to warn Ubuntu users following Launchpad #1764320, the 
patch for which caused this problem:

https://bugs.launchpad.net/ubuntu/+source/thermald/+bug/1764320

--
Ben Caradoc-Davies 
Director
Transient Software Limited 
New Zealand

Bug#887563: corosync prerm will stop pacemaker and not start it again

[Anders Kaseorg]

Control: found 887563 2.4.2-3
Control: severity 887563 important

This just bit me on a Stretch cluster when upgrading corosync from 2.4.2-3 
to 2.4.2-3+deb9u1.  Marking as such.  Please apply the suggested fixes as 
soon as possible.

Anders

Bug#895274: octave and OpenJDK 10

[Mike Miller]

On Mon, Apr 09, 2018 at 10:38:52 +0200, Matthias Klose wrote:
> With the recent java-common upload to experimental, octave would need a
> no-change rebuild/upload in experimental to pick up the new defaults.

I posted the attached patch to the Ubuntu bug tracker. This is an
upstream patch that enables octave configure to detect and build with
OpenJDK 10 and 11.

I can add this to the octave packaging repo if we expect to have a
4.2.2-3 source upload, and if that would be helpful for testing OpenJDK
transitions.

We already have 4.4 release candidates (not yet in experimental) and
expect Octave 4.4 to be stamped in the next week or so, at which point
the patch won't be needed.

-- 
mike
Description: configure: Remove characters after java version string
 Fixes configure detection of Java version with OpenJDK 10 and 11, where some
 text appears after the quoted version number.
Author: Rik 
Origin: upstream, https://hg.savannah.gnu.org/hgweb/octave/rev/523298448352
Bug: https://savannah.gnu.org/bugs/?53531
Reviewed-by: Mike Miller 
Last-Update: 2018-04-19
---
This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
--- a/configure.ac
+++ b/configure.ac
@@ -2759,7 +2759,7 @@
 
   ## Check Java version is recent enough.
   AC_MSG_CHECKING([for Java version])
-  java_version=[`"$JAVA" -version 2>&1 | $SED -n -e 's/^[^ ]* version[^0-9"]*"\([^"]*\)"/\1/p'`]
+  java_version=[`"$JAVA" -version 2>&1 | $SED -n -e 's/^[^ ]* version[^0-9"]*"\([^"]*\)".*/\1/p'`]
   AC_MSG_RESULT([$java_version])
   java_major=[`echo $java_version | $SED -e 's/^\([0-9][0-9]*\)\.\([0-9][0-9]*\)\..*$/\1/'`]
   java_minor=[`echo $java_version | $SED -e 's/^\([0-9][0-9]*\)\.\([0-9][0-9]*\)\..*$/\2/'`]


signature.asc
Description: PGP signature

Bug#896135: tessa: Upstream project (on Alioth) will disappear very soon

[Boyuan Yang]

Source: tessa
Version: 0.3.1-6.2
Severity: normal

Dear Maintainer,

With Alioth service closing soon, tessa's upstream
(https://alioth.debian.org/projects/tessa/) will also disappear.

You seems to be also the upstream developer for tessa; please take a look and
move the project out of Alioth if needed. Since there's already no upstream
activity for > 13 years, it might be also suitable for a package removal.

--
Regards,
Boyuan Yang



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

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

Bug#896134: boinc-app-seti: "Computation error" reported and output file absent

[Russell Coker]

Package: boinc-app-seti
Version: 8.00~svn3701-1
Severity: normal

The boincmgr program when it connects to thie system reports all SETI@home
tasks as having status "Computation error".  The daemon.log file has the
following which may be related (or may be something different):
Apr 19 11:03:49 localhost boinc[7970]: 19-Apr-2018 11:03:49 [SETI@home] 
Computation for task 15ja17ab.21217.2530.14.41.100_1 finished
Apr 19 11:03:49 localhost boinc[7970]: 19-Apr-2018 11:03:49 [SETI@home] Output 
file 15ja17ab.21217.2530.14.41.100_1_r1054471590_0 for task 
15ja17ab.21217.2530.14.41.100_1 absent
Apr 19 11:03:49 localhost boinc[7970]: 19-Apr-2018 11:03:49 [SETI@home] 
Starting task 15ja17ab.21217.2530.14.41.78_1
Apr 19 11:03:50 localhost boinc[7970]: 19-Apr-2018 11:03:50 [SETI@home] 
Computation for task 15ja17ab.21217.2530.14.41.78_1 finished
Apr 19 11:03:50 localhost boinc[7970]: 19-Apr-2018 11:03:50 [SETI@home] Output 
file 15ja17ab.21217.2530.14.41.78_1_r1830334407_0 for task 
15ja17ab.21217.2530.14.41.78_1 absent
Apr 19 11:03:50 localhost boinc[7970]: 19-Apr-2018 11:03:50 [SETI@home] 
Starting task 15ja17ab.20715.2530.13.40.41_1
Apr 19 11:03:51 localhost boinc[7970]: 19-Apr-2018 11:03:51 [SETI@home] 
Computation for task 15ja17ab.20715.2530.13.40.41_1 finished
Apr 19 11:03:51 localhost boinc[7970]: 19-Apr-2018 11:03:51 [SETI@home] Output 
file 15ja17ab.20715.2530.13.40.41_1_r1253324646_0 for task 
15ja17ab.20715.2530.13.40.41_1 absent
Apr 19 11:03:51 localhost boinc[7970]: 19-Apr-2018 11:03:51 [SETI@home] 
Starting task 15ja17ab.21217.2530.14.41.86_1
Apr 19 11:03:52 localhost boinc[7970]: 19-Apr-2018 11:03:52 [SETI@home] 
Computation for task 15ja17ab.21217.2530.14.41.86_1 finished
Apr 19 11:03:52 localhost boinc[7970]: 19-Apr-2018 11:03:52 [SETI@home] Output 
file 15ja17ab.21217.2530.14.41.86_1_r267685211_0 for task 
15ja17ab.21217.2530.14.41.86_1 absent
Apr 19 11:03:52 localhost boinc[7970]: 19-Apr-2018 11:03:52 [SETI@home] 
Starting task 15ja17ab.15060.1303.16.43.35_1
Apr 19 11:03:53 localhost boinc[7970]: 19-Apr-2018 11:03:53 [SETI@home] 
Computation for task 15ja17ab.15060.1303.16.43.35_1 finished
Apr 19 11:03:53 localhost boinc[7970]: 19-Apr-2018 11:03:53 [SETI@home] Output 
file 15ja17ab.15060.1303.16.43.35_1_r1275461904_0 for task 
15ja17ab.15060.1303.16.43.35_1 absent
Apr 19 11:03:53 localhost boinc[7970]: 19-Apr-2018 11:03:53 [SETI@home] 
Starting task 15ja17ab.21217.2530.14.41.55_1
Apr 19 11:03:54 localhost boinc[7970]: 19-Apr-2018 11:03:54 [SETI@home] 
Computation for task 15ja17ab.21217.2530.14.41.55_1 finished
Apr 19 11:03:54 localhost boinc[7970]: 19-Apr-2018 11:03:54 [SETI@home] Output 
file 15ja17ab.21217.2530.14.41.55_1_r579096671_0 for task 
15ja17ab.21217.2530.14.41.55_1 absent


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

Kernel: Linux 4.15.0-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_AU:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Enforcing - Policy name: default

Versions of packages boinc-app-seti depends on:
ii  boinc-client  7.9.3+dfsg-4
ii  libboinc-app7 7.9.3+dfsg-4
ii  libboinc7 7.9.3+dfsg-4
ii  libc6 2.27-3
ii  libfftw3-single3  3.3.7-1
ii  libgcc1   1:8-20180414-1
ii  libstdc++68-20180414-1

boinc-app-seti recommends no packages.

Versions of packages boinc-app-seti suggests:
ii  boinc-manager  7.9.3+dfsg-4

-- no debconf information

Bug#896124: uninstallable in sid, please use new clisp-memfile-hash virtual dependency

[Norbert Preining]

> Following the discussion in #886986, clisp now provides a virtual dependency
> (clisp-memfile-hash-X) corresponding to the supported lisp memory file
> format.
> 
> Since xindy embeds a lisp memory file (and not FASL files), it should move to
> the new scheme.
> 
> I attach a patch that implements this.

Thanks a lot for your work! I will update xindy ASAP, for now I am
struggling with the texlive-bin/synctex breakage!

All the 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#890791: stretch-pu: package dpkg/1.18.25

[Guillem Jover]

Hi!

On Wed, 2018-02-28 at 18:45:49 +, Adam D. Barratt wrote:
> On Wed, 2018-02-28 at 16:05 +0100, Manuel A. Fernandez Montecelo wrote:
> > 2018-02-18 22:26 Guillem Jover:
> > > I'd like to update dpkg in stretch. This includes several fixes for
> > > documentation, regressions, misbheavior, minor security issues, and
> > > a new arch definition so that DAK can accept packages using it. The
> > > fixes have been in sid/buster for a while now.
> > 
> > We depend on this version being accepted and installed in the systems
> > where DAK lives to learn about the new architecture.  After that,
> > several other packages can add support for the architecture, without
> > receiving an automatic reject when uploaded.
> > 
> > It would be great if this update could enter in the next stable
> > update, so we can make progress on that front.

> We've been discussing this amongst the SRMs and are quite wary of a
> dpkg update this close to the p-u freeze. We appreciate that the
> changes individually seem self-contained but would like to have an
> update of such a key package able to be tested more than is feasible in
> the time available.
> 
> (On a related note, in practical terms it's very unlikely that there
> would be sufficient time to get the new strings that are introduced 
> translated.)

Is there perhaps anything you are waiting for me to do here?

For the strings I realized afterwards I can take the ones from sid.
I've not yet checked how many, or if I'd really need a call for
translation, but I'd rather do that only after I know which parts you
are going to accept. :) But TBH, this being gettext I'm not sure it
matters that much, as only those strings might end up not being
translated and dpkg does not have 100% coverage for all languages
anyway. :)

Thanks,
Guillem

Bug#896133: lintian: False positives on binary-package-depends-on-toolchain-package with Breaks/Conflicts

[Guillem Jover]

Package: lintian
Version: 2.5.83
Severity: normal

Hi!

The new tag binary-package-depends-on-toolchain-package seems to have
some false positives, as it checks all dependency fields, including
Breaks and Conflicts. But if another package uses those fields then it
most probably means it cannot work with those versions. So I think
these fields should be excluded?

This currently affects both dpkg-dev and dpkg-cross.

Thanks,
Guillem

Bug#896132: thermald uninitialised member causes loss of temperature control

[Ben Caradoc-Davies]

Package: thermald
Version: 1.7.0-5
Severity: critical
Tags: patch
Justification: breaks the whole system

Dear Maintainer,

0002-Don-t-keep-on-reading-a-sensor-if-the-temperature-is.patch, added in
1.7.0-5,
introduces a new cthd_sensor data member temp_unreadable but fails to
initialise it.
This causes nondeterministic behaviour. If any bits of the uninitialised
boolean are
nonzero, it will be evaluate to true, and the sensor will be silently disabled,
causing loss of temperature control.

This bug is critical because loss of temperature control risks physical
hardware damage.

Attached patch initialises temp_unreadable to restore temperature control.

Kind regards,
Ben.



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

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

Versions of packages thermald depends on:
ii  libc6 2.27-3
ii  libdbus-1-3   1.12.6-2
ii  libdbus-glib-1-2  0.110-2
ii  libgcc1   1:8-20180414-1
ii  libglib2.0-0  2.56.1-2
ii  libstdc++68-20180414-1
ii  libxml2   2.9.4+dfsg1-6.1
ii  lsb-base  9.20170808

thermald recommends no packages.

thermald suggests no packages.

-- Configuration Files:
/etc/thermald/thermal-conf.xml changed:



Passive control of CPU temperature
*
QUIET


cpu


8
passive








-- no debconf information
--- src/thd_sensor.cpp.orig 2018-04-20 10:23:54.571949701 +1200
+++ src/thd_sensor.cpp  2018-04-20 10:24:17.291460842 +1200
@@ -28,7 +28,7 @@
 cthd_sensor::cthd_sensor(int _index, std::string control_path,
std::string _type_str, int _type) :
index(_index), type(_type), sensor_sysfs(control_path.c_str()), 
sensor_active(
-   false), type_str(_type_str), 
async_capable(false), virtual_sensor(false), thresholds(0) {
+   false), type_str(_type_str), 
async_capable(false), virtual_sensor(false), temp_unreadable(false), 
thresholds(0) {
 
 }
 

Bug#893934: openssh-client: Potentially unintended dependency on libbsd

[Guillem Jover]

Control: retitle -1 libedit-dev: Unnecessarily leaks libbsd linkage into all 
its users

Hi!

On Tue, 2018-04-03 at 12:39:54 +0100, Colin Watson wrote:
> Control: reassign -1 libedit-dev 3.1-20170329-1
> 
> On Sat, Mar 24, 2018 at 02:37:57AM +0100, Guillem Jover wrote:
> > I just noticed that the latest version of this package depends on
> > libbsd0, which at first thought it was nice given my previous bug
> > request :), but then realized it was probably unintended when I
> > checked the actual sources. Here's the reasons why:
> > 
> >   * Build-Depends on libedit-dev, which pulls in libbsd-dev.
> >   * configure.ac uses AC_CHECK_LIB instead of AC_SEARCH_LIBS to
> > check for daemon(), which detects daemon() from glibc and
> > concludes that libsd is needed.

> Nope.  The check you mention is in the false branch of an
> AC_CHECK_FUNC([daemon], ...), so isn't run because we detect glibc's
> version first.

Argh! Sorry, you are right, should have stared at the code a bit
longer. :)

> The actual reason is:
> 
>   $ pkg-config --libs libedit
>   -ledit -lncurses -lbsd
> 
> Maybe -lbsd should be moved to Libs.private?  But I don't know the
> libedit interface in detail, and in any case this is up to the libedit
> maintainers, so reassigning.

I think so, yes. This seems like an actual regression from upstream,
because the patch to switch it to use libbsd which I sent and got
carried for a while in Debian was using Requires.private.

Thanks,
Guillem

Bug#297688: ITP: libsmack-java -- XMPP (Jabber) client library for instant messaging and presence

[W. Martin Borgert]

Note, that Smack 4.2.4 has been released on 2018-04-15.

Bug#895868: munin-cron: Fontconfig error: failed reading config file

[BERTRAND Joël]

Same bug here. I've only found a quick an dirty workaround:

*/5 * * * * munin if [ -x /usr/bin/munin-cron ]; then
/usr/bin/munin-cron; fi > /dev/null 2>&1

Regards,

JKB

Bug#896057: gcc-7: doesn't look for "as" in dir specified by -B

[Jakub Wilk]

* Helmut Grohne , 2018-04-19, 06:36:
perhaphs gcc-7 should ship an appropriate symlink in 
/usr/lib/gcc//7/, instead of hardcoding path to "as" at 
configure time?


Your suggestion makes a lot of sense. The devil is in the detail 
though:

* Does it work the same way for ld?


Yes.


* Do cross toolchains also need such a symlink?


No. (Although I suppose it wouldn't hurt either.)


* If yes, where to place it? (They use a different directory layout.)
* Which make variable contains the correct path?


$(gcc_lib_dir) would be my guess.

--
Jakub Wilk

Bug#895346: devscripts: dcmd --buildinfo is not documented

[Adam D. Barratt]

On Tue, 2018-04-10 at 10:42 +0200, Eberhard Beilharz wrote:
> Package: devscripts
> Version: 2.16.2ubuntu3
> Severity: serious
> Justification: Policy 12.1

This got fixed already, but for the record a policy "should" is
unlikely to ever qualify for a Release Critical severity (i.e. >=
serious). A manpage missing an option like this definitely doesn't.

Regards,

Adam

Bug#690210: Bug 690210 : debootstrap : debian-ports support

[Raphael Hertzog]

On Wed, 18 Apr 2018, Hideki Yamane wrote:
> control: tags -1 +pending

It's not "pending" because it's not yet pushed to the official git
repository. I don't know if you just forgot to push or if willingly kept
it out for now...

But please can you avoid committing intrusive changes before seeking
reviews ?

I know that I encouraged you to work on debootstrap but now I feel
responsible to double check all your work because I found out (an
non-negligible rate) of simple mistakes and discutable design decisions
in what you submitted so far.

>  Adjust it to current git code, could you check it, please?

I feel really uncomfortable with this patch. It's really intrusive
and adds tons of perl code in a codebase that was not depending
on perl. The comment even suggests that we would need an alternative
C implementation in case perl is not available (and that C implementation
is not provided here). And the perl code is actually duplicating
code from libdpkg-perl.

IMO the special casing for ports.debian.org architectures should be
handled in a dedicated wrapper. And maybe debootstrap needs new features
to make this wrapper possible.

But I ask you to not commit this unless you get other reviews explaining
that this change is OK despite the above comments.

Alternatively, some sort of middle ground would be to provide a script
dedicated to stuff hosted ports.debian.org, the main script would be
unmodified and the hackish code would be hidden in a script that the user
would have to request explicitly.

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#896126: mpg123: symbols update for riscv64

[James Cowgill]

Hi,

On 19/04/18 21:32, Manuel A. Fernandez Montecelo wrote:
> Source: mpg123
> Version: 1.25.10-1
> Severity: normal
> Tags: patch
> User: debian-ri...@lists.debian.org
> Usertags: riscv64
> 
> Hi,
> 
> We are in the process of bootstrapping a Debian port for the riscv64
> architecture (https://wiki.debian.org/RISC-V).
> 
> The symbols need to be updated for this arch, please see the patch attached.
> 
> We would appreciate if you could upload a version soonish to unstable 
> including
> this fix, to keep the delta as small as possible.

Is it possible to do this more intelligently to cope with the most
common cases, and handle new architectures (at least the ones which
follow the same rules)?

These symbols are present iff the default (without LFS) size of off_t is
32-bits.

My scouring of the glibc source tells me:
 on kfreebsd sizeof(off_t) == 8
 on hurd sizeof(off_t) == sizeof(long)
 on linuxsizeof(off_t) == sizeof(long)
  with the sole exception of x32, where sizeof(off_t) == 8

Maybe this is a better restriction (requires dpkg-dev 1.18)?
 (arch-bits=32|arch=!kfreebsd-any !x32)

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#896131: musescore-general-soundfont: maybe don't override xz compression level

[Jeremy Bicha]

Source: musescore-general-soundfont
Version: 0.1.1-2

musescore-general-soundfont has this in its 0.1.1-2 changelog:
   * Use xz -9e, it’s larger than Fluid so it’s worth it
   * Override xz-compression-level-too-high (good warning, but
 this specific case is checked and correct)

But when I looked at
https://incoming.debian.org/debian-buildd/pool/main/m/musescore-general-soundfont/

both the 0.1.1-1 and 0.1.1-2 versions are 31 MB.

It doesn't look like it's worth bothering to override the deb compression.

Thanks,
Jeremy Bicha

Bug#896130: RFP: vim-julia -- Vim plugin for Julia support

[Francesco Poli (wintermute)]

Package: wnpp
Severity: wishlist

* Package name: vim-julia
  Version : N/A
  Upstream Author : Carlo Baldassi  and others
* URL : https://github.com/JuliaEditorSupport/julia-vim
* License : Expat
  Programming Lang: Vim script
  Description : Vim plugin for Julia support

julia-vim is a plugin for programming in Julia. It adds a number of useful
features to help you in writing Julia code.
.
The plugin provides:
* basic support for editing Julia files (automatic filetype detection,
  indentation, syntax highlighting)
* support for the matchit plugin
* support for Julia block-wise movements (i.e. jumping around between
  Julia blocks like if/end, function/end etc.) and block text-objects
* facilities for conversion of LaTeX entries to Unicode symbols which
  mimic and extend what the Julia REPL and the IJulia notebook
  interface do (optionally, this functionality can be used with all
  file types, not just Julia files)




I think this package may be useful to make the user's life easier,
while editing Julia code.
I hope someone will package and maintain it in Debian, it would
be really great. Thanks to anyone willing to do so!

Bug#895995: mate-themes: High contrast themes show transparent zones instead of black when rendered with metacity

[Samuel Thibault]

Samuel Thibault, le jeu. 19 avril 2018 23:39:04 +0200, a ecrit:
> Mike Gabriel, le jeu. 19 avril 2018 21:37:03 +, a ecrit:
> > Do you think you can rebase your patch against 3.22.11 (for the stretch-pu)
> > and against 3.22.16? Another option would be to wait for 3.22.17/.18 for
> > unstable, but then we still need the rebased patch for the s-pu.
> > 
> > Any chance you can work on that?
> 
> Sure. I believe it's really just a matter of renaming only.

Yes, the attached just-renamed patch works fine on 3.22.11 and 3.22.16.

Samuel
commit 4438dd67f526d4a9c915235d7426de985cec9da3
Author: Samuel Thibault 
Date:   Wed Apr 18 13:54:11 2018 +0200

Fix HighContrast themes visibility with metacity

When rendered with metacity (e.g. with metacity-theme-viewer), the
back background parts of HighContrast and HighContrastInverse actually
show up transparent. This is because the corresponding rectangles were
missing the filled attribute.

In the HighContrast case, the gtk_arrow is getting drawn black on black (and
there is currently no way to change the color), so we can as well draw
it by hand to be able to change the color.

The close button also deserves bigger width to be more visible.

Fixes #211

diff --git a/desktop-themes/ContrastHighInverse/metacity-1/metacity-theme-1.xml 
b/desktop-themes/ContrastHighInverse/metacity-1/metacity-theme-1.xml
index 9129356a..d2fd4c33 100644
--- a/desktop-themes/ContrastHighInverse/metacity-1/metacity-theme-1.xml
+++ b/desktop-themes/ContrastHighInverse/metacity-1/metacity-theme-1.xml
@@ -135,11 +135,11 @@
   
+width="3"/>
   
+   width="3"/>
 
 
 
@@ -147,7 +147,9 @@
 
 
 
-  
+  
   
diff --git a/marco-themes/HighContrast/metacity-theme-1.xml 
b/marco-themes/HighContrast/metacity-theme-1.xml
index 06c7e3cd..d6135f47 100644
--- a/marco-themes/HighContrast/metacity-theme-1.xml
+++ b/marco-themes/HighContrast/metacity-theme-1.xml
@@ -72,11 +72,18 @@
 
 
 
-  
+  
+  
 
 
 
@@ -135,11 +142,11 @@
   
+width="3"/>
   
+   width="3"/>
 
 
 
@@ -147,7 +154,7 @@
 
 
 
-  
   

Bug#895995: mate-themes: High contrast themes show transparent zones instead of black when rendered with metacity

[Samuel Thibault]

Mike Gabriel, le jeu. 19 avril 2018 21:37:03 +, a ecrit:
> On  Do 19 Apr 2018 19:37:01 CEST, Samuel Thibault wrote:
> 
> > Here is the patch that upstream likes.
> > 
> > Samuel
> 
> your patch is based on some newer HEAD of mate-themes, one that has renamed
> the ContrastHighInverse folder to HighContrastInverse. It scarcely applies.

Ah, right, eww, already had to do that several times.

> Do you think you can rebase your patch against 3.22.11 (for the stretch-pu)
> and against 3.22.16? Another option would be to wait for 3.22.17/.18 for
> unstable, but then we still need the rebased patch for the s-pu.
> 
> Any chance you can work on that?

Sure. I believe it's really just a matter of renaming only.

Samuel

Bug#896129: UTF-8 characters are not recognized correctly on Buster

[Louis-Philippe Véronneau]

package: owncloud-client
severity: important

I did a dist-upgrade on my laptop running buster (testing), and since
then, UTF-8 support for owncloud-client is broken.

My old sync connection now fails with this message:

"CSync failed to access /path/to/dir/��pice"

Instead of Mojibake, it should be written "Épice"

The GUI popup that lets me choose what dirs I want to sync also shows
Mojibake instead of proper UTF-8 chars in the directory where things
used to work.

If I try to create a new sync connection in a new directory, the
directories containing UTF-8 chars are not synced at all and I get this
error message:

"The filename cannot be encoded on your file system."

I think this last issue is related to this:
https://github.com/owncloud/client/issues/5719, but I think it's now
normal behavior.

I tried downgrading to 2.4.0+dfsg-1 and even to 2.2.4+dfsg-2. It did
solve the problems of files not syncing and Mojibake, but UTF-8 chars
are replaced by "?", as in "?pice" instead of "Épice".

As of now, my guess is that this is due to some Qt5 package update that
broke something.

I know this is not the best bug report in the world, but I've been
trying to debug this for a few hours now without success. I'll post
updates here if I find the guilty package.

-- 
pollo



signature.asc
Description: OpenPGP digital signature

Bug#895995: mate-themes: High contrast themes show transparent zones instead of black when rendered with metacity

[Mike Gabriel]

HI Samuel,

On  Do 19 Apr 2018 19:37:01 CEST, Samuel Thibault wrote:


Here is the patch that upstream likes.

Samuel


your patch is based on some newer HEAD of mate-themes, one that has  
renamed the ContrastHighInverse folder to HighContrastInverse. It  
scarcely applies.


Do you think you can rebase your patch against 3.22.11 (for the  
stretch-pu) and against 3.22.16? Another option would be to wait for  
3.22.17/.18 for unstable, but then we still need the rebased patch for  
the s-pu.


Any chance you can work on that?

Mike
--

DAS-NETZWERKTEAM
mike gabriel, herweg 7, 24357 fleckeby
mobile: +49 (1520) 1976 148
landline: +49 (4354) 8390 139

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de



pgpn8PJuuofdq.pgp
Description: Digitale PGP-Signatur

Bug#894995: rdma-core: Please add support for new architecture "riscv64" (RISC-V 64 bits little-endian)

[Manuel A. Fernandez Montecelo]

2018-04-19 14:00 GMT+02:00 Benjamin Drung :
>
> RISC-V has a FENCE instruction and the A extension (which is part of
> the G instruction set) provides atomic memory operations. So the
> architecture should provide coherent DMA support. To enable support,
> util/udma_barrier.h needs to be adjusted. I am including
> linux-r...@vger.kernel.org in the loop for help.

Thanks!

(not CC'ing the list).


-- 
Manuel A. Fernandez Montecelo 

Bug#896093: missing dependencies for quaternion

[Hubert Chathi]

On Thu, 19 Apr 2018 17:48:47 +0500, Pirate Praveen  
said:

> When running quaternion from commandline, the following error is shown
> on the terminal

[...]

Thanks for the report.  I'll try to upload a fixed package maybe some
time next week.

-- 
Hubert Chathi  -- https://www.uhoreg.ca/
Jabber: hub...@uhoreg.ca -- Matrix: @uhoreg:matrix.org
PGP/GnuPG key: 4096R/F24C F749 6C73 DDB8 DCB8  72DE B2DE 88D3 113A 1368

Bug#896128: glusterfs: CVE-2018-1088 privilege escalation flaw

[Markus Koschany]

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

Hi,

The following vulnerability was published for glusterfs.

CVE-2018-1088[0]:
| A privilege escalation flaw was found in gluster 3.x snapshot
| scheduler. Any gluster client allowed to mount gluster volumes could
| also mount shared gluster storage volume and escalate privileges by
| scheduling malicious cronjob via symlink.

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-1088
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-1088

Please adjust the affected versions in the BTS as needed.

Regards,

Markus



signature.asc
Description: OpenPGP digital signature

Bug#894217: reprotest: robust mode to make it usuable in CI pipelines

[Vagrant Cascadian]

On 2018-04-19, Ximin Luo wrote:
> Holger Levsen:
>> control: retitle -1 "reprotest: robust mode to make it more usuable in CI 
>> pipelines"

> I'm confused, are people not reading what I'm writing in this thread?
> There is already a "robust mode", it's called "switch off variations
> by passing the documented command-line flags until you find a
> combination that suits you".
>
> It's impossible to predict in advance what will be "robust" on any
> given day due to old bugs lying around dormant from legacy
> software. Part of R-B is to disturb them and fix them.

I also don't see the point in hiding problems by default.  Hidden
problems rarely get fixed.

Reprotest should default to enabling all variations it knows about, and
require selectively and explicitly turning off things when needed.

There might be the case to make a "--debian-policy" flag, since the
requirements there are much laxer than what reprotest tests by
default. But that would basically just probably be a shorthand for
disabling variations x,y,z and so on, and instead could just document
what those options are. I'm not sure that would be maintainable or
implementable in the long-term.


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#896127: glew: needs config.guess/sub update for riscv64

[Manuel A. Fernandez Montecelo]

Source: glew
Version: 2.0.0-5
Severity: normal
User: debian-ri...@lists.debian.org
Usertags: riscv64

Hi,

We are in the process of bootstrapping a Debian port for the riscv64
architecture (https://wiki.debian.org/RISC-V).

The files config.{guess,sub} included in this package are too old to detect this
system.

Debian Policy §4.3 recommends to update these automatically [1], one of the best
ways to achieve this is to depend on newer versions of debhelper and use
dh-autoreconf.

This package is QA-maintained, anybody who reads this please feel free to work
on it and upload :)


[1] https://www.debian.org/doc/debian-policy/#changes-to-the-upstream-sources

"You should make sure that the configure utility detects the correct
architecture specification string (refer to Architecture specification
strings for details).

If your package includes the scripts config.sub and config.guess, you should
arrange for the versions provided by the package autotools-dev be used
instead (see autotools-dev documentation for details how to achieve
that). This ensures that these files can be updated distribution-wide at
build time when introducing new architectures."


Thanks and cheers.
--
Manuel A. Fernandez Montecelo 

Bug#896126: mpg123: symbols update for riscv64

[Manuel A. Fernandez Montecelo]

Source: mpg123
Version: 1.25.10-1
Severity: normal
Tags: patch
User: debian-ri...@lists.debian.org
Usertags: riscv64

Hi,

We are in the process of bootstrapping a Debian port for the riscv64
architecture (https://wiki.debian.org/RISC-V).

The symbols need to be updated for this arch, please see the patch attached.

We would appreciate if you could upload a version soonish to unstable including
this fix, to keep the delta as small as possible.

If you need help or want us to NMU, etc., please tell.


Thanks and cheers.
--
Manuel A. Fernandez Montecelo 
diff -Nru mpg123-1.25.10/debian/libmpg123-0.symbols 
mpg123-1.25.10/debian/libmpg123-0.symbols
--- mpg123-1.25.10/debian/libmpg123-0.symbols   2016-09-28 18:43:08.0 
+0200
+++ mpg123-1.25.10/debian/libmpg123-0.symbols   2018-04-19 18:13:34.0 
+0200
@@ -1,3 +1,3 @@
 #include "libmpg123-0.symbols.common.in"
 #include "libmpg123-0.symbols.64bit.in"
-(arch=!amd64 !arm64 !ia64 !kfreebsd-i386 !kfreebsd-amd64 !s390x !ppc64 
!ppc64el !alpha !sparc64 !mips64 !mips64el !x32)#include 
"libmpg123-0.symbols.32bit.in"
+(arch=!amd64 !arm64 !ia64 !kfreebsd-i386 !kfreebsd-amd64 !s390x !ppc64 
!ppc64el !alpha !sparc64 !mips64 !mips64el !x32 !riscv64)#include 
"libmpg123-0.symbols.32bit.in"

Bug#894217: Info received (reprotest: robust mode to make it usuable in CI pipelines)

[Ximin Luo]

Holger Levsen:
> control: retitle -1 "reprotest: robust mode to make it more usuable in CI 
> pipelines"
> # thanks
> 

I'm confused, are people not reading what I'm writing in this thread? There is 
already a "robust mode", it's called "switch off variations by passing the 
documented command-line flags until you find a combination that suits you".

It's impossible to predict in advance what will be "robust" on any given day 
due to old bugs lying around dormant from legacy software. Part of R-B is to 
disturb them and fix them.

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

Bug#894217: [reprotest] kk_KZ.RK1048 again

[Ximin Luo]

Agustin Henze:
> [..]
> 
> As I said above and previously, we already found the bug... We were trying to
> use reprotest in our CI pipeline on salsa.
> 

Like I already said before, why not just give `--vary=-locales` until the 
underlying problem(s) in Perl/Python/whatever is fixed?

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

Bug#894217: Info received (reprotest: robust mode to make it usuable in CI pipelines)

[Holger Levsen]

control: retitle -1 "reprotest: robust mode to make it more usuable in CI 
pipelines"
# thanks

-- 
cheers,
Holger


signature.asc
Description: PGP signature

Bug#880169: Please enable Indicator support and build against Ayatana Indicators

[Mike Gabriel]

Hi,

On  Mi 18 Apr 2018 19:47:31 CEST, Michael Biebl wrote:


Am 17.04.2018 um 16:57 schrieb Mike Gabriel:

Forwarded upstream with a patch rebased against master HEAD of
network-manager-applet as found on git.gnome.org.


Thanks, Mike.

On a related note, you might be interested to know that Google's chrome
browser with its latest update was updated to depend on libappindicator.

Kinda odd, if libappindicator is no longer supported upstream as you say:

Reading package lists... Done
Building dependency tree
Reading state information... Done
The following additional packages will be installed:
  libappindicator3-1 libdbusmenu-gtk3-4 libindicator3-7 libu2f-udev
The following NEW packages will be installed:
  libappindicator3-1 libdbusmenu-gtk3-4 libindicator3-7 libu2f-udev
The following packages will be upgraded:
  google-chrome-stable
1 upgraded, 4 newly installed, 0 to remove and 5 not upgraded.
Need to get 52.4 MB of archives.
After this operation, 515 kB of additional disk space will be used.


I just made Thomas Anderson from the Chrome/ium team aware of this.

They might consider linking Google Chrome statically against  
lib(ayatana-)appindicator for a while until the transition has settled.


As there is only one Chrome build for all .deb based Linuxes, a  
removal of libappindicator from buster might become problematic, if  
not going the above pathway.


Anyway, this is OT here (#880169)

Mike
--

DAS-NETZWERKTEAM
mike gabriel, herweg 7, 24357 fleckeby
mobile: +49 (1520) 1976 148
landline: +49 (4354) 8390 139

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de



pgpnkjyRyEon5.pgp
Description: Digitale PGP-Signatur

Bug#895995: mate-themes: High contrast themes show transparent zones instead of black when rendered with metacity

[Mike Gabriel]

On  Do 19 Apr 2018 21:33:40 CEST, Samuel Thibault wrote:


Mike Gabriel, le jeu. 19 avril 2018 18:53:12 +, a ecrit:

On  Do 19 Apr 2018 19:37:01 CEST, Samuel Thibault wrote:



Do I get you right, that this issue is also a problem in Debian stretch?


It is, yes, and it'd be very useful to spu the patch once settled in
testing etc.


Yep. Understood.

Mike

--

DAS-NETZWERKTEAM
mike gabriel, herweg 7, 24357 fleckeby
mobile: +49 (1520) 1976 148
landline: +49 (4354) 8390 139

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de



pgpwETCoR115y.pgp
Description: Digitale PGP-Signatur

Bug#833415: ring: no dialpad

[Alexandre Viau]

> to clarify, is this a bug

No, this is not a bug. There is no dialpad in Ring.

However, we recognize that this is a missing feature.

-- 
Alexandre Viau
av...@debian.org



signature.asc
Description: OpenPGP digital signature

Bug#896125: squid: Squid 4: /etc/default/squid KRB5_KTNAME not permanently set

[Christian Meyer]

Package: squid
Version: 4.0.23-1~exp8
Severity: normal

Dear Maintainer,

I don't know if it is a bug, at least it is 'unexpected behaviour'.
I'm playing with squid 4.0.23-1~exp8 from experimental and trying to
authenticate with kerberos.
It seems that /etc/default/squid is not correctly processed.

Following various howto's I created /etc/default/squid with:
KRB5_KTNAME=/etc/squid/PROXY.keytab
export KRB5_KTNAME

At first it worked as expected, but a couple of hours (and a squid
reload/restart) later,
I see errors about using the default keytab (and not the one specified in
/etc/default/squid).

negotiate_kerberos_auth.cc(546): pid=21176 :2018/04/19 00:08:35|
negotiate_kerberos_auth: INFO: Setting keytab to /etc/squid/PROXY.keytab
negotiate_kerberos_auth.cc(570): pid=21176 :2018/04/19 00:08:35|
negotiate_kerberos_auth: INFO: Changed keytab to
MEMORY:negotiate_kerberos_auth_21176
...
negotiate_kerberos_auth.cc(546): pid=18468 :2018/04/19 04:31:47|
negotiate_kerberos_auth: INFO: Setting keytab to FILE:/etc/krb5.keytab
negotiate_kerberos_auth.cc(75): pid=18468 :2018/04/19 04:31:47|
negotiate_kerberos_auth: ERROR: krb5_read_keytab failed: Permission denied
2018/04/19 04:31:47| negotiate_kerberos_auth: ERROR: krb5_read_keytab:
Permission denied
negotiate_kerberos_auth.cc(556): pid=18468 :2018/04/19 04:31:47|
negotiate_kerberos_auth: ERROR: Reading keytab FILE:/etc/krb5.keytab into list
failed

I tried to:
systemctl restart squid,
systemctl reload squid
systemctl stop squid; systemctl start squid

same with KRB5_KTNAME=FILE:/etc/squid/PROXY.keytab
but nothing of this was able to bring back the correct keytab.


Of course a '-k /etc/squid/PROXY.keytab' added to 'negotiate_kerberos_auth' in
squid.conf fixes the situation,
but I would expect squid to respect /etc/default/squid.

Thanks a lot,
Christian



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

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

Versions of packages squid depends on:
ii  adduser  3.115
ii  libc62.24-11+deb9u3
ii  libcap2  1:2.25-1
ii  libcomerr2   1.43.4-2
ii  libdb5.3 5.3.28-12+deb9u1
pn  libdbi-perl  
pn  libecap3 
ii  libexpat12.2.0-2+deb9u1
ii  libgcc1  1:6.3.0-18+deb9u1
ii  libgssapi-krb5-2 1.15-1+deb9u1
ii  libkrb5-31.15-1+deb9u1
ii  libldap-2.4-22.4.44+dfsg-5+deb9u1
ii  libltdl7 2.4.6-2
ii  libnetfilter-conntrack3  1.0.6-2
ii  libnettle6   3.3-1+b2
ii  libpam0g 1.1.8-3.6
ii  libsasl2-2   2.1.27~101-g0780600+dfsg-3
ii  libstdc++6   6.3.0-18+deb9u1
ii  libxml2  2.9.4+dfsg1-2.2+deb9u2
ii  logrotate3.11.0-0.1
ii  lsb-base 9.20161125
ii  netbase  5.4
pn  squid-common 

Versions of packages squid recommends:
ii  libcap2-bin  1:2.25-1

Versions of packages squid suggests:
pn  resolvconf   
pn  smbclient
pn  squid-cgi
pn  squid-purge  
pn  squidclient  
pn  ufw  
pn  winbindd 

Bug#896124: uninstallable in sid, please use new clisp-memfile-hash virtual dependency

[Sébastien Villemot]

Package: xindy
Version: 2.5.1.20160104-4
Severity: serious
Tags: patch

Dear Maintainer,

Following the discussion in #886986, clisp now provides a virtual dependency
(clisp-memfile-hash-X) corresponding to the supported lisp memory file
format.

Since xindy embeds a lisp memory file (and not FASL files), it should move to
the new scheme.

I attach a patch that implements this.

Note that in the future, the memory file format may change in some or all
architectures, depending on internal changes in clisp. You will then have to
schedule binNMUs to make xindy installable again. I will try to avoid that as
much as possible however.

Best,

-- 
⢀⣴⠾⠻⢶⣦⠀  Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁  Debian Developer
⢿⡄⠘⠷⠚⠋⠀  http://sebastien.villemot.name
⠈⠳⣄  http://www.debian.org
diff -Nru xindy-2.5.1.20160104/debian/changelog xindy-2.5.1.20160104/debian/changelog
--- xindy-2.5.1.20160104/debian/changelog	2017-10-23 01:00:47.0 +0200
+++ xindy-2.5.1.20160104/debian/changelog	2018-04-19 21:10:49.0 +0200
@@ -1,3 +1,10 @@
+xindy (2.5.1.20160104-5) UNRELEASED; urgency=medium
+
+  * Use clisp-memfile-hash instead of clisp-fasl-loader virtual dependency. See
+the discussion in #886986 for more details. (Closes: #XX)
+
+ -- Sébastien Villemot   Thu, 19 Apr 2018 21:10:49 +0200
+
 xindy (2.5.1.20160104-4) unstable; urgency=medium
 
   * rebuild for new clisp-fasl-loader
diff -Nru xindy-2.5.1.20160104/debian/control xindy-2.5.1.20160104/debian/control
--- xindy-2.5.1.20160104/debian/control	2017-10-23 01:00:47.0 +0200
+++ xindy-2.5.1.20160104/debian/control	2018-04-19 21:06:29.0 +0200
@@ -6,7 +6,7 @@
 Build-Depends-Indep: texlive-latex-base,
  texlive-lang-cyrillic, texlive-lang-greek,
  texlive-latex-recommended, texlive-fonts-recommended, cm-super
-Build-Depends: debhelper (>= 7), autotools-dev, flex, clisp (>= 2.49.20170913), dh-autoreconf
+Build-Depends: debhelper (>= 7), autotools-dev, flex, clisp (>= 1:2.49.20180212), dh-autoreconf
 Standards-Version: 4.1.1
 Homepage: http://www.xindy.org/
 Vcs-Git: git://anonscm.debian.org/debian-tex/xindy.git
@@ -15,7 +15,7 @@
 Package: xindy
 Architecture: any
 Depends: xindy-rules, ${clisp:Depends}, ${shlibs:Depends}, ${perl:Depends},
-  ${misc:Depends}, clisp (>= 2.49.20170913)
+  ${misc:Depends}, clisp (>= 1:2.49.20180212)
 Description: index generator for structured documents like LaTeX or SGML
  xindy is an index processor that can be used to generate book-like
  indexes for arbitrary document-preparation systems. This includes
diff -Nru xindy-2.5.1.20160104/debian/rules xindy-2.5.1.20160104/debian/rules
--- xindy-2.5.1.20160104/debian/rules	2017-10-23 01:00:47.0 +0200
+++ xindy-2.5.1.20160104/debian/rules	2018-04-19 21:10:49.0 +0200
@@ -108,7 +108,7 @@
 	dh_installdeb -a
 	dh_shlibdeps -a
 	dh_gencontrol -a \
-	  -- -Vclisp:Depends="clisp-fasl-loader-$(shell clisp -x --quiet "(car (system::version))")"
+	  -- -Vclisp:Depends="clisp-memfile-hash-$$(clisp -memfile-hash-of $(xindy_dir)/usr/lib/xindy/xindy.mem)"
 	dh_md5sums -a
 	dh_builddeb -a
 


signature.asc
Description: PGP signature

Bug#895995: mate-themes: High contrast themes show transparent zones instead of black when rendered with metacity

[Samuel Thibault]

Mike Gabriel, le jeu. 19 avril 2018 18:53:12 +, a ecrit:
> On  Do 19 Apr 2018 19:37:01 CEST, Samuel Thibault wrote:
> 
> > Here is the patch that upstream likes.
> > 
> > Samuel
> 
> I am currently waiting for mate-themes upstream to look into your patch(set).

Sure!

> Do I get you right, that this issue is also a problem in Debian stretch?

It is, yes, and it'd be very useful to spu the patch once settled in
testing etc.

Samuel

Bug#894217: reprotest: robust mode to make it usuable in CI pipelines

[Holger Levsen]

control: retitle -1 "reprotest: robust mode to make it usuable in CI pipelines"
control: severity -1 wishlist
# trying to summarize this feature request
# thanks

hi,

maybe there could be a robust mode using "safe" locales and another
mode, thoroughly testing stuff...


-- 
cheers,
Holger


signature.asc
Description: PGP signature

Bug#896123: unattended-upgrades: [INTL:nl] Dutch po file for the unattended-upgrades package

[Frans Spiesschaert]

 
 
Package: unattended-upgrades 
Severity: wishlist 
Tags: l10n patch 
 
 
 
Dear Maintainer, 
 
 
Please find attached the updated Dutch po file for the unattended-
upgrades package. 
It has been submitted for review to the debian-l10n-dutch mailing
list. 
Please add it to your next package revision. 
It should be put as "po/nl.po" in your package build tree. 
 

-- 
Regards,
Frans Spiesschaert


nl.po.gz
Description: application/gzip


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

Bug#894217: [reprotest] kk_KZ.RK1048 again

[Agustin Henze]

Ximin, before you start reading this. Please, think about if you have enough
time and interest, because it seems that you are not reading me :(. If you
don't have time for this, please, just don't answer. I'll understand.

On 04/19/18 15:04, Ximin Luo wrote:
[...]
> 
> I'm sorry but I don't have any more time to look into this problem in depth, 
> but this output suggests there is something wrong with either Perl or the 
> locales-all package. Clearly it recognises RK1048 over  but then 
> something it's expecting is missing.
> 

I can see that you don't have time for this... You are not reading me or I am
too bad explaining myself... We already found the bug and we already reported
it... But thank you for the hint anyway.

[...]
> 
> 2 or 3 is not "a lot", back when I was doing reproducible builds full-time I 
> would look at fixing issues affecting 20-30 packages or sometimes several 
> hundred. Please try to understand the exact nature of the problem I am 
> pointing out rather than coming back with the same point.
> 

Ok, I wasn't doing a comparison of problems here... And I said 2 of 3, that's
66.66% and because we migrated just 3 packages to salsa. We are applying the
same pipeline for all our packages and reprotest is a single job inside the
pipeline... I have no idea how are you testing it, but every single package
that uses help2man or sphinx is not going to be reproducible according to
reprotest and it'll fail randomly.

> If you do more in-depth research on the problem I might be inclined to take 
> it more seriously, but so far it looks like that isn't the case here. Reading 
> the POSIX and C standards for locale-related functions might help you 
> understand the problem better.

As I said above and previously, we already found the bug... We were trying to
use reprotest in our CI pipeline on salsa.

Cheers,

-- 
TiN



signature.asc
Description: OpenPGP digital signature

Bug#896122: isc-dhcp-server: DHCPv6 server crashes, DHCPv4 OK

[Giorgos Skafidas]

Package: isc-dhcp-server
Version: 4.3.5-4
Severity: important
Tags: ipv6

Dear Maintainer,

I use isc-dhcp-server as a DHCPv6+DHCPv4 server in a home network with mostly 
Windows and a few Linux and Android clients.

After upgrading to 4.3.5-4, I noticed that the DHCPv6 server would die after a 
while, with no error messages in syslog. Meanwhile, 
DHCPv4 keeps functioning without a problem. Trying to reproduce this today, I 
found that running the "ipconfig /release6" and "ipconfig /renew6"
commands in Windows, to release and reacquire the lease respectively, is enough 
to trigger the crash.

I do not have this issue after downgrading to 4.3.5-3.1. Below is the output 
from running dhcpd in foreground mode.

Thank you!

---
# /usr/sbin/dhcpd -6 -d -tf dhcpd6-trace -cf /etc/dhcp/dhcpd6.conf eth0_lan 
eth0.2 eth0.3
Internet Systems Consortium DHCP Server 4.3.5
Copyright 2004-2016 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/
lease_id_format is: hex
Config file: /etc/dhcp/dhcpd6.conf
Database file: /var/lib/dhcp/dhcpd6.leases
PID file: /var/run/dhcpd6.pid
Wrote 0 class decls to leases file.
Wrote 0 deleted host decls to leases file.
Wrote 0 new dynamic host decls to leases file.
Wrote 1 NA, 0 TA, 0 PD leases to lease file.
Bound to *:547
Listening on Socket/6/eth0.3/fd11:2358:1321:3403::/64
Sending on   Socket/6/eth0.3/fd11:2358:1321:3403::/64
Listening on Socket/6/eth0.2/fd11:2358:1321:3402::/64
Sending on   Socket/6/eth0.2/fd11:2358:1321:3402::/64
Listening on Socket/6/eth0_lan/fd11:2358:1321:3401::/64
Sending on   Socket/6/eth0_lan/fd11:2358:1321:3401::/64
Server starting service.
Solicit message from fe80::a169:84d:c547:5adb port 546, transaction ID 
0x25AA8000
Advertise NA: address fd11:2358:1321:3401:10:c363:685c:6495 to client with duid 
00:01:00:01:15:6f:15:33:08:00:27:f1:f0:f0 iaid = 336068647 valid for 604800 
seconds
Sending Advertise to fe80::a169:84d:c547:5adb port 546
Request message from fe80::a169:84d:c547:5adb port 546, transaction ID 
0x25AA8000
Reply NA: address fd11:2358:1321:3401:10:c363:685c:6495 to client with duid 
00:01:00:01:15:6f:15:33:08:00:27:f1:f0:f0 iaid = 336068647 valid for 604800 
seconds
Sending Reply to fe80::a169:84d:c547:5adb port 546
Added new forward map from VM-Win7.kantza.lan to 
fd11:2358:1321:3401:10:c363:685c:6495
Added reverse map from 
5.9.4.6.c.5.8.6.3.6.3.c.0.1.0.0.1.0.4.3.1.2.3.1.8.5.3.2.1.1.d.f.ip6.arpa. to 
VM-Win7.kantza.lan
Release message from fe80::a169:84d:c547:5adb port 546, transaction ID 
0x7EC9FB00
Client 00:01:00:01:15:6f:15:33:08:00:27:f1:f0:f0 releases address 
fd11:2358:1321:3401:10:c363:685c:6495
Sending Reply to fe80::a169:84d:c547:5adb port 546
Removed forward map from VM-Win7.kantza.lan to 
fd11:2358:1321:3401:10:c363:685c:6495
Removed reverse map on 
5.9.4.6.c.5.8.6.3.6.3.c.0.1.0.0.1.0.4.3.1.2.3.1.8.5.3.2.1.1.d.f.ip6.arpa.
Solicit message from fe80::a169:84d:c547:5adb port 546, transaction ID 
0x14EE2200
Advertise NA: address fd11:2358:1321:3401:10:c363:685c:6495 to client with duid 
00:01:00:01:15:6f:15:33:08:00:27:f1:f0:f0 iaid = 336068647 valid for 604800 
seconds
Sending Advertise to fe80::a169:84d:c547:5adb port 546
Request message from fe80::a169:84d:c547:5adb port 546, transaction ID 
0x14EE2200
Reply NA: address fd11:2358:1321:3401:10:c363:685c:6495 to client with duid 
00:01:00:01:15:6f:15:33:08:00:27:f1:f0:f0 iaid = 336068647 valid for 604800 
seconds
../../../lib/isc/heap.c:217: REQUIRE(idx >= 1 && idx <= heap->last) failed, 
back trace
#0 0x7f8a33c74737 in ??
#1 0x7f8a33c7468a in ??
#2 0x7f8a33c7b6aa in ??
#3 0x563855dda9a2 in ??
#4 0x563855ddadc1 in ??
#5 0x563855dd5fd1 in ??
#6 0x563855dd83d5 in ??
#7 0x563855dd97ba in ??
#8 0x563855dda3cc in ??
#9 0x563855df56e2 in ??
#10 0x563855de4d13 in ??
#11 0x563855e13776 in ??
#12 0x7f8a33cab4bb in ??
#13 0x7f8a33c9adce in ??
#14 0x7f8a33c9fc90 in ??
#15 0x7f8a33ca0155 in ??
#16 0x563855de6f20 in ??
#17 0x563855d9adf9 in ??
#18 0x7f8a338c8a87 in ??
#19 0x563855d9b6ea in ??
Aborted
---

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

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

Versions of packages isc-dhcp-server depends on:
ii  debconf [debconf-2.0]  1.5.66
ii  debianutils4.8.4
ii  libc6  2.27-3
ii  libdns-export1100  1:9.11.3+dfsg-1
ii  libirs-export160   1:9.11.3+dfsg-1
ii  libisc-export169   1:9.11.3+dfsg-1
ii  lsb-base   9.20170808

Versions of packages isc-dhcp-server recommends:
ii  isc-dhcp-common  4.3.5-4
pn  

Bug#895808: thunderbird(+enigmail): crashes when sending GPG-encrypted email

[Paride Legovini]

On 19/04/2018 18.26, Carsten Schoenert wrote:
> Hi,
> 
> On Thu, Apr 19, 2018 at 03:29:03PM +0200, Paride Legovini wrote:
>  
>> It seems there is no ‘thunderbird-dbgsym’ package available.
>> Am I missing something?
> 
> ahm, yes. You will need for sure to add some extra sources to your apt
> configuration get the dbgsym packages.
> 
> https://wiki.debian.org/HowToGetABacktrace

Admittedly, I had never installed debug symbols packages before. Bad
news anyway: the debug symbols are read, but I still get only those
. I'm sending you the output as an attachment, just in case I
missed something useful.

Let me know if there is anything else I can try.
Thanks for looking into this.

Paride
$ RUST_BACKTRACE=1 gdb /usr/lib/thunderbird/thunderbird
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/lib/thunderbird/thunderbird...Reading symbols from 
/usr/lib/debug/.build-id/b6/c0cb8e98c17eed7d909b82d3ed4b5d2390cb48.debug...done.
done.
(gdb) run
Starting program: /usr/lib/thunderbird/thunderbird
/usr/lib/thunderbird/defaults/pref/vendor.js:2: prefs parse error: unknown 
keyword
thread '' panicked at '`before_sheet` stylesheet not found', 
src/libcore/option.rs:891:5
stack backtrace:
   0: 
   1: 
   2: 
   3: 
   4: 
   5: 
   6: 
   7: 
   8: 
   9: 
  10: 
  11: 
  12: 
  13: 
  14: 
  15: 
  16: 
  17: 
  18: 
  19: 
  20: 
  21: 
  22: 
  23: 
  24: 
  25: 
  26: 
  27: 
  28: 
  29: 
  30: 
  31: 
  32: 
  33: 
  34: 
  35: 
  36: 
  37: 
  38: 
  39: 
  40: 
  41: 
  42: 
  43: 
  44: 
  45: 
  46: 
  47: 
  48: 
  49: 
  50: 
  51: 
  52: 
  53: 
  54: 
  55: 
  56: 
  57: 
  58: 
  59: 
  60: 
  61: 
  62: 
  63: 
  64: 
  65: 
  66: 
  67: 
  68: 
  69: 
  70: 
  71: 
  72: 
  73: 
  74: 
  75: 
  76: 
  77: 
  78: 
  79: 
  80: 
  81: 
  82: 
  83: 
  84: 
  85: 
  86: 
  87: 
  88: 
  89: 
  90: 
  91: 
  92: 
  93: 
  94: 
  95: 
  96: 
  97: 
  98: 
  99: 
Redirecting call to abort() to mozalloc_abort

ExceptionHandler::GenerateDump cloned child 10969
ExceptionHandler::SendContinueSignalToChild sent continue signal to child
ExceptionHandler::WaitForContinueSignal waiting for continue signal...
During startup program exited with code 11.
(gdb)

Bug#896121: pgbackrest: package files are not on @INC anymore with perl 5.26.2

[Paul Gevers]

Source: pgbackrest
Version: 2.01-1
Severity: serious
User: debian...@lists.debian.org
Usertags: needs-update

Your autopkgtest¹ of version 2.01-1 started to fail when perl 5.26.2 hit
the archive with the error copied below. It seems the package installs
files in /usr/lib//perl/5.26.1/. That path is not on @INC
with perl 5.26.2, so either you need to put the files somewhere else, or
you need a hard Depends on perl 5.26.1.

I think the issue is much more severe than just the autopkgtest failing,
I think the package stopped working with the default perl and INC.
Please lower the severity if I am wrong.

Can you please investigate the situation, and fix it?

Paul

¹ https://ci.debian.net/packages/p/pgbackrest/

autopkgtest [12:44:54]: test suite: [---
Creating new PostgreSQL cluster 10/regress ...
/usr/lib/postgresql/10/bin/initdb -D
/tmp/pg_virtualenv.auY3uu/data/10/regress --username=debci
--pwfile=/tmp/pg_virtualenv.auY3uu/postgresql-common/pwfile --nosync -A
trust -k
The files belonging to this database system will be owned by user "debci".
This user must also own the server process.

The database cluster will be initialized with locale "C.UTF-8".
The default database encoding has accordingly been set to "UTF8".
The default text search configuration will be set to "english".

Data page checksums are enabled.

fixing permissions on existing directory
/tmp/pg_virtualenv.auY3uu/data/10/regress ... ok
creating subdirectories ... ok
selecting default max_connections ... 100
selecting default shared_buffers ... 128MB
selecting dynamic shared memory implementation ... posix
creating configuration files ... ok
running bootstrap script ... ok
performing post-bootstrap initialization ... ok

Sync to disk skipped.
The data directory might become corrupt if the operating system crashes.

Success. You can now start the database server using:

/usr/lib/postgresql/10/bin/pg_ctl -D
/tmp/pg_virtualenv.auY3uu/data/10/regress -l logfile start

Warning: The parent /var/run/postgresql of the selected
stats_temp_directory is not writable for the cluster owner. Not adding this
setting in postgresql.conf.
Ver Cluster Port Status Owner Data directory
Log file
10  regress 5433 online debci /tmp/pg_virtualenv.auY3uu/data/10/regress
/tmp/pg_virtualenv.auY3uu/log/postgresql-10-regress.log

2018-04-19 12:44:57.741 P00   INFO: stanza-create command begin 2.01:
--config=/tmp/tmp.b6UCSvxeNs --lock-path=/tmp/tmp.xtGbWpBYWQ
--log-level-console=info --log-path=/tmp/tmp.YjvM5IHqOT
--pg1-path=/tmp/pg_virtualenv.auY3uu/data/10/regress --pg1-port=5433
--repo1-path=/tmp/tmp.5sk1LHA4Qy --stanza=demo
Can't locate pgBackRest/LibC.pm in @INC (you may need to install the
pgBackRest::LibC module) (@INC contains: /etc/perl
/usr/local/lib/x86_64-linux-gnu/perl/5.26.2 /usr/local/share/perl/5.26.2
/usr/lib/x86_64-linux-gnu/perl5/5.26 /usr/share/perl5
/usr/lib/x86_64-linux-gnu/perl/5.26 /usr/share/perl/5.26
/usr/local/lib/site_perl) at
/usr/share/perl5/pgBackRest/Config/Config.pm line 21.
BEGIN failed--compilation aborted at
/usr/share/perl5/pgBackRest/Config/Config.pm line 21.
Compilation failed in require at
/usr/share/perl5/pgBackRest/Common/Lock.pm line 19.
BEGIN failed--compilation aborted at
/usr/share/perl5/pgBackRest/Common/Lock.pm line 19.
Compilation failed in require at
/usr/share/perl5/pgBackRest/Common/Exit.pm line 16.
BEGIN failed--compilation aborted at
/usr/share/perl5/pgBackRest/Common/Exit.pm line 16.
Compilation failed in require at /usr/share/perl5/pgBackRest/Main.pm
line 20.
BEGIN failed--compilation aborted at /usr/share/perl5/pgBackRest/Main.pm
line 20.
Compilation failed in require.
BEGIN failed--compilation aborted.
Undefined subroutine ::Main::configSet called at (eval 47)
line 1.
Cleaning files...
*** /tmp/pg_virtualenv.auY3uu/log/postgresql-10-regress.log (last 100
lines) ***
LOG:  listening on IPv4 address "0.0.0.0", port 5433
LOG:  listening on IPv6 address "::", port 5433
LOG:  listening on Unix socket "/tmp/.s.PGSQL.5433"
LOG:  database system was shut down at 2018-04-19 12:44:55 UTC
LOG:  database system is ready to accept connections
LOG:  incomplete startup packet
LOG:  incomplete startup packet
Dropping cluster 10/regress ...
autopkgtest [12:44:58]: test suite: ---]
autopkgtest [12:44:58]: test suite:  - - - - - - - - - - results - - - -
- - - - - -
suiteFAIL non-zero exit status 2



signature.asc
Description: OpenPGP digital signature

Bug#896120: squid: Squid 4: Please enable acl proxy_auth -i again

[Christian Meyer]

Package: squid
Version: 4.0.23-1~exp8 
Severity: normal

Dear Maintainer,

in squid3 I used
acl AllowedUsers proxy_auth -i alice bob
to handle ActiveDirectory usernames like 'AliCe'.

In squid 4 I get the following error:
FATAL: bad configuration: unsupported ACL option: -i

BTW:
acl AllowedUsers proxy_auth_regex -i alice bob
works well, but is slow with a big number of users.

Is it possible to bring back 'proxy_auth -i' again?

Thank you for your attention.
Christian



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

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

Versions of packages squid depends on:
ii  adduser  3.115
ii  libc62.24-11+deb9u3
ii  libcap2  1:2.25-1
ii  libcomerr2   1.43.4-2
ii  libdb5.3 5.3.28-12+deb9u1
pn  libdbi-perl  
pn  libecap3 
ii  libexpat12.2.0-2+deb9u1
ii  libgcc1  1:6.3.0-18+deb9u1
ii  libgssapi-krb5-2 1.15-1+deb9u1
ii  libkrb5-31.15-1+deb9u1
ii  libldap-2.4-22.4.44+dfsg-5+deb9u1
ii  libltdl7 2.4.6-2
ii  libnetfilter-conntrack3  1.0.6-2
ii  libnettle6   3.3-1+b2
ii  libpam0g 1.1.8-3.6
ii  libsasl2-2   2.1.27~101-g0780600+dfsg-3
ii  libstdc++6   6.3.0-18+deb9u1
ii  libxml2  2.9.4+dfsg1-2.2+deb9u2
ii  logrotate3.11.0-0.1
ii  lsb-base 9.20161125
ii  netbase  5.4
pn  squid-common 

Versions of packages squid recommends:
ii  libcap2-bin  1:2.25-1

Versions of packages squid suggests:
pn  resolvconf   
pn  smbclient
pn  squid-cgi
pn  squid-purge  
pn  squidclient  
pn  ufw  
pn  winbindd 

Bug#872572: ring: Account status "Not Registered"

[Alexandre Viau]

Hello,

As said by Petter Reinholdtsen, "Not Registered" is due to the fact that
Ring cannot connect to the DHT to "register" your account.

This isn't a bug, but due to your current connectivity.

If you can reproduce this in a non-locked-down network, feel free to
comment on this bug again.

Until then, I will close this bug.

Cheers,

-- 
Alexandre Viau
av...@debian.org



signature.asc
Description: OpenPGP digital signature

Bug#862678: Switch from network-manager-dev to libnm-dev

[Ari Pollak]

Sorry, I haven't had time to do anything about it yet and I won't be able
to look at it for the next month or so.

Bug#895995: mate-themes: High contrast themes show transparent zones instead of black when rendered with metacity

[Mike Gabriel]

Hi Samuel,

On  Do 19 Apr 2018 19:37:01 CEST, Samuel Thibault wrote:


Here is the patch that upstream likes.

Samuel


I am currently waiting for mate-themes upstream to look into your patch(set).

Do I get you right, that this issue is also a problem in Debian stretch?

Mike
--

DAS-NETZWERKTEAM
mike gabriel, herweg 7, 24357 fleckeby
mobile: +49 (1520) 1976 148
landline: +49 (4354) 8390 139

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de



pgplph0gBDYkE.pgp
Description: Digitale PGP-Signatur

Bug#896119: scilab: ATOMS system is broken in Scilab 6 on buster

[Nrbrtx]

Subject: scilab: ATOMS system is broken in Scilab 6 on buster
Package: scilab
Version: 6.0.1-1
Severity: important

Steps to reproduce:
1. Install Debian 10 (x86_64 in my case)
2. Install `scilab` package (from buster or from unstable)
3. Launch Scilab from terminal with `scilab`
4. Try to show information of a package from ATOMS system with
`atomsShow('coselica')`

Expected results:
* Scilab updates local ATOMS cache, then shows information about Coselica
toolbox

Actual results:
* Scilab shows error in its console:

Startup execution:
  loading initial environment

--> atomsShow('coselica')
Scanning repository http://atoms.scilab.org/6.0 ... Done

at line   265 of function atomsDESCRIPTIONget (
/usr/share/scilab/modules/atoms/macros/atoms_internals/atomsDESCRIPTIONget.sci
line 284 )
at line31 of function atomsIsPackage  (
/usr/share/scilab/modules/atoms/macros/atoms_internals/atomsIsPackage.sci
line 47 )
at line43 of function atomsShow   (
/usr/share/scilab/modules/atoms/macros/atomsShow.sci line 59 )

atomsDESCRIPTIONget: save
('/home/debian/.Scilab/scilab-6.0.1/.atoms/packages') has failed.

and in terminal:

HDF5-DIAG: Error detected in HDF5 (1.10.0-patch1) thread
140556419344320:
  #000: ../../../src/H5G.c line 553 in H5Gget_info(): invalid argument
major: Invalid arguments to routine
minor: Bad value
HDF5-DIAG: Error detected in HDF5 (1.10.0-patch1) thread
140556419344320:
  #000: ../../../src/H5G.c line 301 in H5Gcreate2(): not a location
major: Invalid arguments to routine
minor: Inappropriate type
  #001: ../../../src/H5Gloc.c line 253 in H5G_loc(): invalid object ID
major: Invalid arguments to routine
minor: Bad value
HDF5-DIAG: Error detected in HDF5 (1.10.0-patch1) thread
140556419344320:
  #000: ../../../src/H5A.c line 265 in H5Acreate2(): not a location
major: Invalid arguments to routine
minor: Inappropriate type
  #001: ../../../src/H5Gloc.c line 253 in H5G_loc(): invalid object ID
major: Invalid arguments to routine
minor: Bad value
HDF5-DIAG: Error detected in HDF5 (1.10.0-patch1) thread
140556419344320:
  #000: ../../../src/H5D.c line 121 in H5Dcreate2(): not a location ID
major: Invalid arguments to routine
minor: Inappropriate type
  #001: ../../../src/H5Gloc.c line 253 in H5G_loc(): invalid object ID
major: Invalid arguments to routine
minor: Bad value
HDF5-DIAG: Error detected in HDF5 (1.10.0-patch1) thread
140556419344320:
  #000: ../../../src/H5F.c line 749 in H5Fclose(): not a file ID
major: Invalid arguments to routine
minor: Inappropriate type
failed to close file




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

Kernel: Linux 4.15.0-2-amd64 (SMP w/1 CPU core)
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

Versions of packages scilab depends on:
ii  scilab-cli   6.0.1-1
ii  scilab-full-bin  6.0.1-1

Versions of packages scilab recommends:
ii  scilab-doc  6.0.1-1

Versions of packages scilab suggests:
pn  scilab-doc-fr 
pn  scilab-doc-ja 
pn  scilab-doc-pt-br  

-- no debconf information

Bug#761441: RFP: node-istanbul -- a JS code coverage tool written in JS

[Thorsten Glaser]

On Sat, 13 Sep 2014, W. Martin Borgert wrote:

> Yet another code coverage tool for Javascript, with the

Second that RFP (not going to delve into ECMAscript packaging
myself though, I do enough crazy stuff already, tyvm), but do
mind nyc which is the new official front-end, supporting run‐
ning stuff that itself spawns, e.g.

nyc mocha […]

Thanks,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

Bug#895763: matplotlib: missing depends on python(3)-kiwisolver

[Adrian Bunk]

Control: reassign -1 src:matplotlib 2.2.2-1
Control: affects -1 python-matplotlib-dbg python3-matplotlib-dbg 
src:python-ltfatpy src:pyfai
Control: retitle -1 python{,3}-matplotlib-dbg must depend on 
python{,3}-kiwisolver-dbg
Control: severity -1 serious
Control: reassign 895776 src:kiwisolver
Control: retitle 895776 kiwisolver must provide python{,3}-kiwisolver-dbg 
packages
Control: severity 895776 serious
Control: block -1 by 895776

On Sun, Apr 15, 2018 at 08:27:59PM +, PICCA Frederic-Emmanuel wrote:
> there is two problemes.
> 
> kiwisolver MUST provide -dbg packages AND matplotlib should depends on these 
> packages once available.

Correct, I'm reshuffling the bugs accordingly.

At least for python-ltfatpy his is even a FTBFS, therefore RC:
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/python-ltfatpy.html

> Cheers
> 
> Frederic

cu
Adrian

-- 

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

Bug#896118: scilab: Scilab 6.0 launches, shows its window and closes immediately on buster

[Nrbrtx]

Package: scilab
Version: 6.0.1-1
Severity: important

Steps to reproduce:
1. Install Debian 10 (x86_64 in my case)
2. Install `scilab` package (from buster or from unstable)
3. Try to launch it from menu (in MATE - Applications->Other->Scilab)

Expected results:
Scilab is started, user can use it.

Actual results:
Scilab is started, shows its window with

Startup execution:
  loading initial environment


and then closes immediately.

Notes:
Scilab starts normally from terminal, here is its output:

libEGL warning: DRI2: failed to authenticate


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

Kernel: Linux 4.15.0-2-amd64 (SMP w/1 CPU core)
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

Versions of packages scilab depends on:
ii  scilab-cli   6.0.1-1
ii  scilab-full-bin  6.0.1-1

Versions of packages scilab recommends:
ii  scilab-doc  6.0.1-1

Versions of packages scilab suggests:
pn  scilab-doc-fr 
pn  scilab-doc-ja 
pn  scilab-doc-pt-br  

-- no debconf information

Bug#894175: ddccontrol: Please drop gksu dependency on Ubuntu

[Miroslav Kravec]

On Thu, Apr 19, 2018 at 11:03 AM, Simon McVittie  wrote:
> Control: tags -1 + pending
>
> On Tue, 27 Mar 2018 at 06:21:57 +, Miroslav Kravec wrote:
>> Sorry for accidental drop of your changes. Please provide a patch containing
>> your changes.
>
> They appear to have been committed upstream as
> https://github.com/ddccontrol/debian-ddccontrol/commit/b8205d744649f80f509cca074aa9df48123501bd

It was merged in this PR:
https://github.com/ddccontrol/debian-ddccontrol/pull/1.

I'll add a patch to use pkexec as a replacement of gksu. And, then
release a new version of Debian package.

> This did make an excellent example for #850156 of a package where the
> existence of d/p/ubuntu.series was harmful to Ubuntu, though, so thanks
> for (accidentally) providing that :-)
>
>> As for gksu, current version of ddccontrol still depends on it.
>
> Does this mean that gddccontrol has never worked as intended on Debian,
> only on Ubuntu?

Looking at changelog, it was added in:

ddccontrol (0.4.2-9) unstable; urgency=low
-- ... <...@...>  Fri, 01 Jul 2011 14:39:06 +0200

I have no idea, what was intended then. But, I don't consider an
application without access to its resources (i2c) devices to be
working correctly.

>> This will
>> change with next release of ddccontrol, where D-Bus daemon is used to perform
>> HW access
>
> That is a much better approach to this sort of controlled privilege
> escalation. (Note that I haven't reviewed the specific implementation
> here.)

Quality of implementation matters, and that's the reason why I'm not
rushing a release of the new ddccontrol version. However, it takes
much longer, than expected, because I have much less free time now.

>> It will get into next Ubuntu release.
>
> (It didn't get into the next Ubuntu release. Ubuntu bionic contains
> a patched version in which Jeremy reapplied the 0.4.2-11 changes to
> fix this.)

I had in mind 18.10, as it was already after Debian import freeze for
18.04. As I see, this gksu removal is quite a special case, which
ignores freeze, and a new debian package version gets pushed anyway.

I'll add this pkexec patch on this weekend, and release a new Debian package.

Bug#896117: qpid-proton: Incomplete debian/copyright?

[Chris Lamb]

Source: qpid-proton
Version: 0.22.0-1
Severity: serious
Justication: Policy 12.5
X-Debbugs-CC: Daniel Pocock 

Hi,

I just ACCEPTed qpid-proton from NEW but noticed it was missing 
attribution in debian/copyright for at least Barclays, the stuff
under tests.

In addition, debian/copyright is very much out of date (eg.
examples/c/include/pncompat/internal/* does not match any files), 
you are not using https://qpid.apache.org/proton/ as the Homepage
in debian/control / URI in debian/copyright, and you are not using
a secure URI in debian/watch when apache.org supports this.

(This is in no way exhaustive so please check over the entire package 
carefully and address these on your next upload.)


Regards,

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

Bug#896098: krita: Krita's Python scripting not working

[Aleksey Samoilov]

19.04.2018 21:56, Lisandro Damián Nicanor Pérez Meyer пишет:

Oh, please do reply to the bug report! This has been sent to me in private!

On 19 April 2018 at 14:16, Sunderland93  wrote:

It needs libpython3.6m.so, which is contained in libpython3.6-dev. Without
it Python scripting is not available in Tools > Scripting menu, and error is

Loading Python plugin
"" false
()
()
()
Could not create /usr/lib/x86_64-linux-gnu/libpython3.6m.so
"Cannot load Python library"


On 19.04.2018 20:33, Lisandro Damián Nicanor Pérez Meyer wrote:

El jue., 19 de abr. de 2018 10:15, Sunderland93 
escribió:

Package: krita
Version: 1:4.0.1+dfsg-1
Severity: important

Dear Maintainer,

Krita's Python scripting not working in this version. It needs
libpython3-dev package,
which must added into dependency's (or Recommends section), just like in
Ubuntu


Why would it need a development package for runtime use?

Bug#894217: [reprotest] kk_KZ.RK1048 again

[Ximin Luo]

Agustin Henze:
> [..]
> 
> Yeah, you're right about the test I sent before. I'm sorry I am not a Perl
> expert. But take a look at this, please
> 
> $ apt-get install locales-all -y # It's important having all locales installed
> because this is what reprotest does and also the way to reproduce the error
> 
> $ LC_ALL=kk_KZ.XX perl -e 'use open IO => ":locale"; print "yes\n"'
> perl: warning: Setting locale failed.
> perl: warning: Please check that your locale settings:
> LANGUAGE = "de:de_DE",
> LC_ALL = "kk_KZ.XX",
> LANG = "de_DE.UTF-8"
> are supported and installed on your system.
> perl: warning: Falling back to a fallback locale ("de_DE.UTF-8").
> yes
> 
> $ LC_ALL=kk_KZ.RK1048 perl -e 'use open IO => ":locale"; print "yes\n"'
> Cannot find encoding "RK1048" at /usr/share/perl/5.26/open.pm line 126.
> Cannot find encoding "RK1048" at /usr/share/perl/5.26/open.pm line 134.
> 
> $ LC_ALL=kk_KZ.RK1048 help2man
> Unknown encoding 'RK1048' at /usr/bin/help2man line 56.
> 

I'm sorry but I don't have any more time to look into this problem in depth, 
but this output suggests there is something wrong with either Perl or the 
locales-all package. Clearly it recognises RK1048 over  but then something 
it's expecting is missing.

> [..]
> 
> Totally agree with you. But just to see if we are on the same page... You are
> saying that reprotest will fail with a lot of packages if you don't pass
> `--vary=-locales` because Perl and Python2 are broken, well I wouldn't say
> broken but they don't support the encoding that reprotest is using for testing
> random locales.
> 
> I thought that choosing another encoding in reprotest was reasonable because a
> lot of packages will fail if you try to use reprotest for this. We got 2 of 3
> packages broken by this.
> 

2 or 3 is not "a lot", back when I was doing reproducible builds full-time I 
would look at fixing issues affecting 20-30 packages or sometimes several 
hundred. Please try to understand the exact nature of the problem I am pointing 
out rather than coming back with the same point.

If you do more in-depth research on the problem I might be inclined to take it 
more seriously, but so far it looks like that isn't the case here. Reading the 
POSIX and C standards for locale-related functions might help you understand 
the problem better.

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

Bug#896098: krita: Krita's Python scripting not working

[Lisandro Damián Nicanor Pérez Meyer]

On 19 April 2018 at 13:33, Lisandro Damián Nicanor Pérez Meyer
 wrote:
[snip]
> Why would it need a development package for runtime use?

User just checked: the app is looking for the unversioned .so instead
of the versioned one. This is a bug in the app I''m afraid.


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

Bug#896014: inotify-tools: Consider using dgit-maint-gbp workflow

[Jeremy Bicha]

On Thu, Apr 19, 2018 at 1:14 PM, Sean Whitton  wrote:
> Since we have submitted two sessions to DebConf18 about this new
> workflow, you can be confident the release will come before August :)  So
> what I would like to suggest is that both of you hang tight for now and
> then evaluate this new workflow.  inotify-tools can just stay how it is
> until then.

Sean, thanks for replying. This isn't an urgent issue for me, so I'm
happy to wait a few months.

Jeremy Bicha

Bug#895995: mate-themes: High contrast themes show transparent zones instead of black when rendered with metacity

[Samuel Thibault]

Here is the patch that upstream likes.

Samuel
commit 4438dd67f526d4a9c915235d7426de985cec9da3
Author: Samuel Thibault 
Date:   Wed Apr 18 13:54:11 2018 +0200

Fix HighContrast themes visibility with metacity

When rendered with metacity (e.g. with metacity-theme-viewer), the
back background parts of HighContrast and HighContrastInverse actually
show up transparent. This is because the corresponding rectangles were
missing the filled attribute.

In the HighContrast case, the gtk_arrow is getting drawn black on black (and
there is currently no way to change the color), so we can as well draw
it by hand to be able to change the color.

The close button also deserves bigger width to be more visible.

Fixes #211

diff --git a/desktop-themes/HighContrastInverse/metacity-1/metacity-theme-1.xml 
b/desktop-themes/HighContrastInverse/metacity-1/metacity-theme-1.xml
index 9129356a..d2fd4c33 100644
--- a/desktop-themes/HighContrastInverse/metacity-1/metacity-theme-1.xml
+++ b/desktop-themes/HighContrastInverse/metacity-1/metacity-theme-1.xml
@@ -135,11 +135,11 @@
   
+width="3"/>
   
+   width="3"/>
 
 
 
@@ -147,7 +147,9 @@
 
 
 
-  
+  
   
diff --git a/marco-themes/HighContrast/metacity-theme-1.xml 
b/marco-themes/HighContrast/metacity-theme-1.xml
index 06c7e3cd..d6135f47 100644
--- a/marco-themes/HighContrast/metacity-theme-1.xml
+++ b/marco-themes/HighContrast/metacity-theme-1.xml
@@ -72,11 +72,18 @@
 
 
 
-  
+  
+  
 
 
 
@@ -135,11 +142,11 @@
   
+width="3"/>
   
+   width="3"/>
 
 
 
@@ -147,7 +154,7 @@
 
 
 
-  
   

Bug#895633: transition: poppler

[Emilio Pozuelo Monfort]

Control: tags -1 confirmed

On 13/04/18 20:02, Emilio Pozuelo Monfort wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> Control: block -1 with 894371
> 
> Time for another poppler transition. It's in experimental, and all
> the rdepends build fine, except for
> 
> gdcm, due to an unrelated bug #894371.

This is ongoing now.

Cheers,
Emilio

Bug#896116: games-minesweeper: Should depend on at least one game

[Markus Koschany]

Am 19.04.2018 um 19:02 schrieb Celelibi:
> Package: games-minesweeper
> Version: 2.2
> Severity: normal
> 
> Dear Maintainer,
> 
> If the goal of this package is to install mineweeper games, it should
> depends on them, not just list them as recommended.
> 
> Alternatively, it could depend on a disjunction of the mineweeper games,
> so that at least one get installed.

This is intentional because games-minesweeper is a metapackage. If it
depended on those games you would not be able to remove single games
from your system anymore, all games of a certain metapackage would be
removed. In addition some metapackages would become uninstallable on
some architectures if the dependencies could not be satisfied.

The current Recommends mechanism avoids all that. I don't consider this
to be a bug.

Markus



signature.asc
Description: OpenPGP digital signature

Bug#896014: inotify-tools: Consider using dgit-maint-gbp workflow

[Sean Whitton]

Hello both,

If Dmitry wants to continue to use dgit-maint-merge(7), using 3.0
(quilt) will not help.  It will not introduce any additional metadata.
The only change will be the addition of a patch header pointing to
dgit-repos.

Switching to dgit-maint-gbp(7) means using a patches-unapplied workflow.
I assume Dmitry does not actually want to do that, but if he does, he
should be able to do this:

- `git revert` all commits to the upstream source
- `gbp pq import`
- `git cherry-pick` commits to the upstream source
- `gbp export`
- commit the new d/patches directory

Now `dgit quilt-fixup` should succeed.  Let me know if it doesn't.

There is, however, a third option.

In the next month or so we (Ian Jackson and I) will be releasing a
workflow called dgit-maint-debrebase(7) which

- is patches-applied; but
- automatically generates a perfect 3.0 (quilt) representation of the
  Debian changes.

I.e. it should satisfy everyone.

Since we have submitted two sessions to DebConf18 about this new
workflow, you can be confident the release will come before August :)  So
what I would like to suggest is that both of you hang tight for now and
then evaluate this new workflow.  inotify-tools can just stay how it is
until then.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#896116: games-minesweeper: Should depend on at least one game

[Celelibi]

Package: games-minesweeper
Version: 2.2
Severity: normal

Dear Maintainer,

If the goal of this package is to install mineweeper games, it should
depends on them, not just list them as recommended.

Alternatively, it could depend on a disjunction of the mineweeper games,
so that at least one get installed.

Best regards,
Celelibi

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

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

Versions of packages games-minesweeper depends on:
ii  games-tasks  2.2

Versions of packages games-minesweeper recommends:
pn  ace-of-penguins  
pn  freesweep
pn  sgt-puzzles  
pn  xbomb
pn  xdemineur

Versions of packages games-minesweeper suggests:
pn  aptitude 
pn  gnome-mines  
pn  kmines   

-- no debconf information

Bug#896010: lintian: FP for source-contains-empty-directory if directory isn't listed with trailing slash

[Chris Lamb]

tags 896010 + pending
thanks

Thanks James! Fixed in Git, pending upload:

  
https://salsa.debian.org/lintian/lintian/commit/914e7b1c97baff09a0017227414a8df3fedaa0f5

  debian/changelog   | 6 ++
  lib/Lintian/Collect/Package.pm | 4 
  2 files changed, 10 insertions(+)


Regards,

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

Bug#895387: wavelet-decompose overlaps with gimp 2.10

[Jeremy Bicha]

Control: tags -1 +pending

I have uploaded an NMU to fix this bug to the DELAYED/7 queue. Please
let me know if I should speed up or slow down this upload.

A diff of my changes can be found at
https://github.com/bzed/gimp-plugin-registry/pull/1

Thanks,
Jeremy Bicha

Bug#896098: krita: Krita's Python scripting not working

[Lisandro Damián Nicanor Pérez Meyer]

El jue., 19 de abr. de 2018 10:15, Sunderland93 
escribió:

> Package: krita
> Version: 1:4.0.1+dfsg-1
> Severity: important
>
> Dear Maintainer,
>
> Krita's Python scripting not working in this version. It needs
> libpython3-dev package,
> which must added into dependency's (or Recommends section), just like in
> Ubuntu


Why would it need a development package for runtime use?

Bug#895808: thunderbird(+enigmail): crashes when sending GPG-encrypted email

[Carsten Schoenert]

Hi,

On Thu, Apr 19, 2018 at 03:29:03PM +0200, Paride Legovini wrote:
 
> It seems there is no ‘thunderbird-dbgsym’ package available.
> Am I missing something?

ahm, yes. You will need for sure to add some extra sources to your apt
configuration get the dbgsym packages.

https://wiki.debian.org/HowToGetABacktrace

Regards
Carsten

Bug#896115: RFS: python-cerberus/1.2-1 [ITP]

[Joel Cross]

Package: sponsorship-requests
Severity: wishlist

  Dear mentors,

  I am looking for a sponsor for my package "python-cerberus"

 * Package name: python-cerberus
   Version : 1.2-1
   Upstream Author : Nicola Iarocci 
 * URL : http://github.com/pyeve/cerberus
 * License : ISC
   Section : python

  It builds those binary packages:

python-cerberus-doc - Documentation for python3-cerberus
 python3-cerberus - Lightweight, extensible data validation library for Python

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

  https://mentors.debian.net/package/python-cerberus


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

dget -x https://mentors.debian.net/debian/pool/main/p/python-
cerberus/python-cerberus_1.2-1.dsc

  More information about Cerberus can be obtained from http://python-
cerberus.org/.

  Regards,
   Joel Cross



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

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

Bug#896071: debootstrap fails to retrive Release file over https

[Alf Gaida]

No, sorry, no journal entries, no coredumps - nothing



signature.asc
Description: OpenPGP digital signature

Bug#896114: python3-alabaster: Multiple privacy breaches

[Joel Cross]

Package: python3-alabaster
Version: 0.7.8-1
Severity: normal

Dear Maintainer,

These templates contain a number of 'phone home' type privacy breaches, which
are transmitted into all documentation that is built from the templates. The
relevant Lintian output is below:

W: python3-alabaster: privacy-breach-generic usr/lib/python3/dist-
packages/alabaster/about.html [https://ghbtns.com/github-
btn.html?user={{ theme_github_user }}={{ theme_github_repo }}={{
theme_github_type }}={{ theme_github_count }}=large=2"\n
allowtransparency="true" frameborder="0" scrolling="0" width="200px"
height="35px">] (https://ghbtns.com/github-btn.html?user={{ theme_github_user
}}={{ theme_github_repo }}={{ theme_github_type }}={{
theme_github_count }}=large=2)
W: python3-alabaster: privacy-breach-generic usr/lib/python3/dist-
packages/alabaster/about.html [] (https://secure.travis-ci.org/{{
path }}.svg?branch=master)
W: python3-alabaster: privacy-breach-generic usr/lib/python3/dist-
packages/alabaster/about.html [] (https://codecov.io/github/{{ path
}}/coverage.svg?branch=master)
W: python3-alabaster: privacy-breach-generic usr/lib/python3/dist-
packages/alabaster/donate.html 

Bug#894217: [reprotest] kk_KZ.RK1048 again

[Agustin Henze]

Hi Ximin,

On 04/18/18 18:40, Ximin Luo wrote:
[...]
> 
> Your perl/python tests miss the point. I think it's fine for .encode() to 
> crash or raise an exception when given an unrecognised encoding, because it's 
> an explicit command. I don't think it's fine for LC_ALL to crash or raise an 
> exception, because it's meant to be an opportunistic override.
> 

Yeah, you're right about the test I sent before. I'm sorry I am not a Perl
expert. But take a look at this, please

$ apt-get install locales-all -y # It's important having all locales installed
because this is what reprotest does and also the way to reproduce the error

$ LC_ALL=kk_KZ.XX perl -e 'use open IO => ":locale"; print "yes\n"'
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = "de:de_DE",
LC_ALL = "kk_KZ.XX",
LANG = "de_DE.UTF-8"
are supported and installed on your system.
perl: warning: Falling back to a fallback locale ("de_DE.UTF-8").
yes

$ LC_ALL=kk_KZ.RK1048 perl -e 'use open IO => ":locale"; print "yes\n"'
Cannot find encoding "RK1048" at /usr/share/perl/5.26/open.pm line 126.
Cannot find encoding "RK1048" at /usr/share/perl/5.26/open.pm line 134.

$ LC_ALL=kk_KZ.RK1048 help2man
Unknown encoding 'RK1048' at /usr/bin/help2man line 56.

> They work fine on my computer but since I was unable to reproduce the bug 
> here anyways, I am not sure if it means much. But these tests are more "to 
> the point" than your tests in your output.txt.
> 

I guess you couldn't reproduce it because you don't have locales-all package
installed

> IMO the time spent discussing this on this bug report would have been better 
> spent writing patches for the affected programs.
> 

Sorry if you feel discussing this is a waste of time :(. Iñaki already reported
it[0] some time ago. But here, we are trying to "fix" reprotest because it's
easier than waiting for all the other projects that are failing with this
encoding. Just that.

> I really don't think reprotest should be coded to ignore known problems. If 
> you want to avoid these bugs (in other programs), give `reprotest 
> --vary=-locales` then the problem is evident visually on the command-line and 
> not "brushed under the carpet" and you can still continue with your other 
> tests.
> 

Totally agree with you. But just to see if we are on the same page... You are
saying that reprotest will fail with a lot of packages if you don't pass
`--vary=-locales` because Perl and Python2 are broken, well I wouldn't say
broken but they don't support the encoding that reprotest is using for testing
random locales.

I thought that choosing another encoding in reprotest was reasonable because a
lot of packages will fail if you try to use reprotest for this. We got 2 of 3
packages broken by this.

Anyway, we are going to report this bug to the packages that don't support the
encoding in order to be able to use reprotest, I hope it doesn't take long.
Thank you for spending time on this.

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

-- 
TiN



signature.asc
Description: OpenPGP digital signature

Bug#896084: dose-builddebcheck: Finds invalid solution with versioned provides

[James Clarke]

On Thu, Apr 19, 2018 at 11:40:53AM +0100, James Clarke wrote:
> Package: dose-builddebcheck
> Version: 5.0.1-9
> Tags: upstream
>
> [It's quite likely this should be against libdose3-ocaml(-dev) as I
> imagine this is a bug in the common library code also used by
> dose-distcheck]
>
> Hi,
> Whilst running a new kfreebsd-{amd64,i386} buildd, I noticed that
> dose-builddebcheck doesn't quite handle versioned provides correctly[1],
> when combined with versioned dependencies. This
> stems from the use of MAX_INT32-1 for an unversioned provides, which is
> of course greater than any version number used in the dependency.

It turns out this is the same problem as upstream's two failing
versioned provides tests[1]. The attached patch fixes all of this.

Regards,
James

[1] 
https://lists.gforge.inria.fr/pipermail/dose-devel/2017-September/000660.html
>From 2b89c68f0711880ce06037d3aa2680215f9a0ab1 Mon Sep 17 00:00:00 2001
From: James Clarke 
Date: Thu, 19 Apr 2018 14:59:49 +0100
Subject: [PATCH] Fix >> and >= constraints against virtual packages

Previously, MAX_INT32-1 was used as the version number for an
unversioned provide (and also generated alongside a versioned provide),
which incorrectly satisfies any >> or >= constraint. Instead,
use --virtual--versioned- as a separate prefix for versioned
provides and constraints, whilst keeping --virtual- for unversioned
provides. This fixes the remaining broken versioned provides test cases.
---
 deb/debcudf.ml | 53 +-
 deb/tests.ml   | 26 -
 2 files changed, 35 insertions(+), 44 deletions(-)

diff --git a/deb/debcudf.ml b/deb/debcudf.ml
index c70ed67..534cb63 100644
--- a/deb/debcudf.ml
+++ b/deb/debcudf.ml
@@ -224,12 +224,16 @@ let get_cudf_version tables (package,version) =
   end
 
 let get_real_name name = 
-  (* Remove --virtual- and architecture encoding *)
+  (* Remove --virtual(--versioned)- and architecture encoding *)
   let dn = (CudfAdd.decode name) in
   let no_virtual =
 if ExtString.String.starts_with dn "--vir"
-then ExtString.String.slice ~first:10 dn
-else dn
+then begin
+  let maybe_versioned = ExtString.String.slice ~first:10 dn in
+  if ExtString.String.starts_with maybe_versioned "-ver"
+  then ExtString.String.slice ~first:11 maybe_versioned
+  else maybe_versioned
+end else dn
   in
   try
 let (n,a) = ExtString.String.split no_virtual ":" in
@@ -260,35 +264,21 @@ let loadl ?native_arch ?package_arch tables l =
   List.flatten (
 List.map (fun ((name,_) as vpkgname,constr) ->
   let encname = add_arch_info ?native_arch ?package_arch vpkgname in
-  match constr with
-  |None ->
+  let (virt_prefix, constr) =
+match constr with
+|None ->
   (* Versioned virtual packages will satisfiy non versioned 
dependencies *)
-  if (OcamlHashtbl.mem tables.virtual_table name) then
-[(encname, None);("--virtual-"^encname,Some(`Eq,Util.max32int - 
1))]
-  else
-[(encname, None)]
-  |Some(op,v) ->
+  ("--virtual-", None)
+|Some(op,v) ->
   (* Non-versioned virtual packages will not satisfy versioned 
dependencies. *)
   let op = Pef.Pefcudf.pefcudf_op op in
-  try
-match SSet.elements !(OcamlHashtbl.find tables.virtual_table name) 
with
-|[] -> assert false
-|l ->
-let dl = 
-  List.filter_map (function
-|(_,None) -> Some 
("--virtual-"^encname,Some(`Eq,Util.max32int))
-|(_,Some _) ->
-let constr = Some(op,get_cudf_version tables (name,v)) 
in
-Some ("--virtual-"^encname,constr)
-  ) l
-in
-if Util.StringHashtbl.mem tables.unit_table name then
-  let constr = Some(op,get_cudf_version tables (name,v)) in
-  (encname,constr)::dl
-else dl
-  with Not_found -> 
-  let constr = Some(op,get_cudf_version tables (name,v)) in
-  [(encname,constr)]
+  let constr = Some(op,get_cudf_version tables (name,v)) in
+  ("--virtual--versioned-",constr)
+  in
+  if (OcamlHashtbl.mem tables.virtual_table name) then
+[(encname, constr);(virt_prefix^encname,constr)]
+  else
+[(encname, constr)]
 ) l
   )
 
@@ -308,12 +298,13 @@ let loadlp ?native_arch ?package_arch tables l =
   List.flatten (
 List.map (fun ((name,_) as vpkgname,constr) ->
 let encname = add_arch_info ?native_arch ?package_arch vpkgname in
-let vencname = "--virtual-"^encname in 
+let vencname = "--virtual-"^encname in
+let vvencname = "--virtual--versioned-"^encname in
 match constr with
 |None -> [(vencname,Some(`Eq,Util.max32int - 1))]
 |Some("=",v) ->
   let 

Bug#896113: please package astroid >= 1.6.3

[Helmut Grohne]

Package: python3-astroid
Version: 1.6.0-1
Control: affects -1 + pylint3

When checking a file with an uninstantiated class with pylint3, one gets
the message "Unused variable '__class__'" very often. This is reported
upstream as https://github.com/PyCQA/pylint/issues/1784. The proposed
fix is updating astroid to >= 1.6.3. Thus I ask for updating astroid in
Debian to get rid of the annoying warning.

Thank you for maintaining pylint and astroid.

Helmut

Bug#896076: libconfig-model-dpkg-perl: seems to miss a versioned depends on libconfig-model-perl

[Dominique Dumont]

On Thursday, 19 April 2018 11:04:06 CEST you wrote:
> Your autopkgtest¹ of version 2.108 passes in unstable, but when we
> migrate that version to testing, it fails with the error below.

I wonder why you're trying to use an unstable version of libconfig-model-dpkg-
perl with a testing version of libconfig-model-perl... Oh well...

> Can you please investigate the situation, and raise the severity if I am
> right?

There's indeed a bug in older version of Config::Model. Instead of raising the 
severity, I'll fix this right away.

All the best

Bug#894736: Checker config files allow arbitrary code execution scenarios

[Andrea Capriotti]

Il giorno mar, 03/04/2018 alle 20.03 +0200, Enrico Zini ha scritto:
> Package: vim-syntastic
> Version: 3.8.0-1
> Severity: serious
> 
> Hello,
> 
> syntastic has a Configuration Files[1] feature enabled for several
> checkers, where:
> 
>   a configuration file is looked up in the directory of the file
> being
>   checked, then upwards in parent directories.  The search stops
> either
>   when a file with the right name is found, or when the root of the
>   filesystem is reached.[1]
> 
> [1] https://github.com/vim-syntastic/syntastic/blob/master/doc/syntas
> tic-checkers.txt#L7744
> 
> Each line found in the configuration file is escaped as a single
> argument and appended to the checker command being run.
> 
> I am not an expert on the various possibly dangerous command line
> options of all possible checkers, but I played with one I knew how to
> play with, and what follows is a possible attack. There might be
> easier
> attacks on checkers that are enabled by default, since the
> configuration
> files features, as it is now, leaves a pretty wide attack surface
> open.

Hi Enrico, 

you are right and the attack works. I opened this upstream issue:

https://github.com/vim-syntastic/syntastic/issues/2170

and he fixed the problem in 3.9.0 release. I'll build and upload it as
soon as possible.

Best Regards
-- 
Andrea Capriotti 

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

Bug#896105: openmpi 3.0.1 - release candidate or release ?

[Alastair McKinstry]

Upstream tarball (and webpage) states 3.0.1, VERSION file contains
'greek=rc5'.

Reported issue upsteam: https://github.com/open-mpi/ompi/issues/5082

regards

Alastair


On 19/04/2018 15:10, Adrian Bunk wrote:
> Source: openmpi
> Version: 3.0.1-6
> Severity: normal
>
> The version number implies it would be the 3.0.1,
> but it identifies itself as release candidate:
>
> $  ompi_info
>  Package: Open MPI pbuilder@debian Distribution
> Open MPI: 3.0.1rc5
>   Open MPI repo revision: date2018-04-18
>Open MPI release date: Unreleased developer copy
> Open RTE: 3.0.1rc5
>   Open RTE repo revision: date2018-04-18
>Open RTE release date: Unreleased developer copy
> OPAL: 3.0.1rc5
>   OPAL repo revision: date2018-04-18
>OPAL release date: Unreleased developer copy
>  MPI API: 3.1.0
> Ident string: 3.0.1rc5

-- 
Alastair McKinstry, , , 
https://diaspora.sceal.ie/u/amckinstry
Commander Vimes didn’t like the phrase “The innocent have nothing to fear,”
 believing the innocent had everything to fear, mostly from the guilty but in 
the longer term
 even more from those who say things like “The innocent have nothing to fear.”
 - T. Pratchett, Snuff

Bug#896102: libsynctex1: Version is too recent, and prevent texmaker and zathura (at least) to launch

[Victor Morel]

I just did, still the same error ...
Thanks for the tip, I had it installed on another machine, but forgot to set it
on this one.
Surprisingly, I didn't find it in the list provided by reportbug.

On 19/04/18 16:02, Hilmar Preuße wrote:
> from testing? Please re-test w/ the one from testing.
> Further I recommend to install apt-listbugs to see serious bugs bevore the
> upgrade happens: your bug was reported yesterday as #895980.
>
> Thanks,
>   Hilmar 

-- 
Victor

Bug#896076: libconfig-model-dpkg-perl: seems to miss a versioned depends on libconfig-model-perl

[gregor herrmann]

On Thu, 19 Apr 2018 11:04:06 +0200, Paul Gevers wrote:

> Your autopkgtest¹ of version 2.108 passes in unstable, but when we
> migrate that version to testing, it fails with the error below.
[..]
> The error is a file from libconfig-model-perl, which you also updated in
> unstable. Hence, I suspect that the new version of
> libconfig-model-dpkg-perl needs a versioned depends on
> libconfig-model-perl (the old version is fine with the new version of
> libconfig-model-perl), but I may be wrong.

Right, I think that's the case.
Thanks for catching this.

I've now bumped the versioned (build) dependency in git, and I expect
an upload in the near future for other reasons.
 
> Can you please investigate the situation, and raise the severity if I am
> right?

Not sure if the severity should be raised; both packages were
uploaded in lockstep and will migrate together, so "naturally" there
shouldn't be a problem (unlike in your - very much appreciated! -
tests). But feel free to go ahead.
 
Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   NP: U2: Zooropa


signature.asc
Description: Digital Signature

Bug#896112: fontconfig-config: Inconsolata no longer emboldened

[kawupnik]

Package: fontconfig-config
Version: 2.13.0-4
Severity: normal

Dear Maintainer,

the Inconsolata font doesn't have a bold variant, but until I got the recent
update to 2.13, it displayed text in bold anyway.

I've tracked this magic down to
/usr/share/fontconfig/conf.avail/90-synthetic.conf, which has a rule that sets
"embolden" to true for fonts without a bold variant.

I've fixed this issue for me by changing this part



regular


into this



normal


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

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

Versions of packages fontconfig-config depends on:
ii  debconf [debconf-2.0]  1.5.66
ii  fonts-dejavu-core  2.37-1
ii  fonts-liberation   1:1.07.4-5
ii  ucf3.0038

fontconfig-config recommends no packages.

fontconfig-config suggests no packages.

-- debconf information:
  fontconfig/hinting_type: Native
  fontconfig/subpixel_rendering: Automatic
  fontconfig/hinting_style: hintslight
  fontconfig/enable_bitmaps: false

Bug#896111: ITP: servo-hdctools -- Chrome OS Hardware Debug & Control Tools

[Ana Guerrero Lopez]

Package: wnpp
Owner: Ana Guerrero Lopez 
Severity: wishlist

* Package name : servo-hdctools
Version : 20180401
Upstream Author : The Chromium OS Authors 
* URL : https://chromium.googlesource.com/chromiumos/third_party/hdctools
* License : BSD-3-clause
Programming Language: Python, C
Description : Chrome OS Hardware Debug & Control Tools

Servo is a debug board used for Chromium OS test and development.
This code contains:
* the backend server that talks to servo boards
* a binary allowing to control the server
* usbkm232, an RS232 (uart) to USB keyboard emulator

Bug#896110: mpi-defaults: FTBFS on all architectures

[Boyuan Yang]

Source: mpi-defaults
Version: 1.10
Severity: grave
Justification: renders package unusable

Dear Maintainer,

https://buildd.debian.org/status/logs.php?pkg=mpi-defaults=1.11

   dh_installdeb -a
install -d debian/mpi-default-dev/DEBIAN
install -d debian/mpi-default-bin/DEBIAN
rm -f debian/mpi-default-dev.debhelper.log
   debian/rules override_dh_gencontrol
make[1]: Entering directory '/<>'
rm -f debian/*.substvars
if [ "" = "openmpi" ]; then \
  echo "mpi=openmpi-bin" > debian/mpi-default-bin.substvars; \
  echo "mpi-dev=libopenmpi-dev" > debian/mpi-default-dev.substvars; \
elif [ "" = "mpich" ]; then \
  echo "mpi=mpich" > debian/mpi-default-bin.substvars; \
  echo "mpi-dev=libmpich-dev" > debian/mpi-default-dev.substvars; \
else \
  echo "Unknown MPI implementation, stopping"; \
  exit 1; \
fi
Unknown MPI implementation, stopping
debian/rules:109: recipe for target 'override_dh_gencontrol' failed
make[1]: *** [override_dh_gencontrol] Error 1
make[1]: Leaving directory '/<>'
debian/rules:94: recipe for target 'binary-arch' failed
make: *** [binary-arch] Error 2

Something must have went wrong. Please look into it.

--
Regards,
Boyuan Yang




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

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

Bug#896109: flif FTBFS: bouncing-ball-frame01.png is not the same image as decoded-test-frame-000.pam

[Adrian Bunk]

Source: flif
Version: 0.3-1
Severity: serious

flif FTBFS (also reproduced on amd64):

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

...
+ check ../tools/bouncing_ball_frames/ decoded-test-frame-000.pam 
decoded-test-frame-001.pam decoded-test-frame-002.pam 
decoded-test-frame-003.pam decoded-test-frame-004.pam 
decoded-test-frame-005.pam decoded-test-frame-006.pam 
decoded-test-frame-007.pam decoded-test-frame-008.pam 
decoded-test-frame-009.pam decoded-test-frame-010.pam 
decoded-test-frame-011.pam decoded-test-frame-012.pam 
decoded-test-frame-013.pam decoded-test-frame-014.pam 
decoded-test-frame-015.pam decoded-test-frame-016.pam 
decoded-test-frame-017.pam decoded-test-frame-018.pam decoded-test-frame-019.pam
+ one='../tools/bouncing_ball_frames/*.png'
+ for c in $one
++ compare -metric mepp ../tools/bouncing_ball_frames/bouncing-ball-frame01.png 
decoded-test-frame-000.pam null:
+ [[ 2.52947e-10 (1.09221e-36, 5.54578e-17) == \0\ \(\0\,\ \0\) ]]
+ echo 'BUG DETECTED!!!'
BUG DETECTED!!!
+ echo 'PROBLEM IN FILE ../tools/bouncing_ball_frames/ : 
../tools/bouncing_ball_frames/bouncing-ball-frame01.png is not the same image 
as decoded-test-frame-000.pam'
PROBLEM IN FILE ../tools/bouncing_ball_frames/ : 
../tools/bouncing_ball_frames/bouncing-ball-frame01.png is not the same image 
as decoded-test-frame-000.pam
+ exit 1
Makefile:146: recipe for target 'test' failed
make[1]: *** [test] Error 1