Bug#921043: [Pkg-dpdk-devel] Bug#921043: dpdk-dev: dpdk-sdk-env.sh no longer included in dpdk-dev

[Luca Boccassi]

On Thu, 2019-01-31 at 16:16 -0800, Nicolas S. Dade wrote:
> Package: dpdk-dev
> Version: 18.11-4~bpo9+1
> Severity: normal
> 
> Dear Maintainer,
> 
> The file
>  /usr/share/dpdk/dpdk-sdk-env.sh
> used to be part of the dpdk-dev packages. It defines the environment
> variables needed to use the dpdk sdk, and the debian documentation
> recommended sourcing it into your shell in order to use dpdk.
> 
> The file debian/dpsk-sdk-env.sh.in file is present in the dpdk
> 18.11-4~bpo9+1 sources, but the line in debian/rule that produced it
> is missing. (For that matter, other lines related to the dpdk-dev
> package
> in rules are missing too).
> 
> Perhaps this is on purpose. But I don't see it in changelog, nor do I
> see a suitable alternative.

It was mentioned in the changelog for 18.11-1: "Drop the dpdk-dev SDK
package, users should just use pkg-config now."
There is no SDK anymore. All you need is the pkg-config file that was
already shipped before in libdpdk-dev. Perhaps I'll add a NEWS entry
for the next upload.

-- 
Kind regards,
Luca Boccassi

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

Bug#921042: [Pkg-dpdk-devel] Bug#921042: dpdk-dev: dpdk 18.11-4 and dpdk-dev conflict

[Luca Boccassi]

On Thu, 2019-01-31 at 16:10 -0800, Nicolas S. Dade wrote:
> Package: dpdk-dev
> Version: 18.11-4~bpo9+1
> Severity: important
> 
> Dear Maintainer,
> 
> Installing the dpdk-dev-18.11-4~bpo9+1 is not possible. dpkg refuses,
> claiming dpdk-dev breaks dpdk 18.11-4. For example:
> 
> 
> # dpkg --install dpdk-dev_18.11-4~bpo9+1_amd64.deb 
> Selecting previously unselected package dpdk-dev. 
> dpkg: regarding dpdk-dev_18.11-4~bpo9+1_amd64.deb containing dpdk-
> dev: 
> dpdk-dev breaks dpdk (<< 18.11-4) 
>  dpdk (version 18.11-4~bpo9+1) is present and installed. 
> 
> dpkg: error processing archive dpdk-dev_18.11-4~bpo9+1_amd64.deb (
> --install): 
> installing dpdk-dev would break dpdk, and 
> deconfiguration is not permitted (--auto-deconfigure might help) 
> Errors were encountered while processing: 
> dpdk-dev_18.11-4~bpo9+1_amd64.deb
> 
> 
> The Replaces lines in the debian/control file for the dpdk and dpdk-
> dev
> sections look strange to me. Why would dpdk replace dpdk-dev?
> 
> However I am not able to work around this except by commenting out
> the Replaces and Breaks lines entirely.

This is due to 18.11-4~ working out as lower than 18.11-4, which I
should have thought about. Sorry about that, will be fixed in the next
upload.

-- 
Kind regards,
Luca Boccassi

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

Bug#918510: kwin-wayland incorrectly depends on kwayland-integration

[Maximiliano Curia]

¡Hola Martin!

El 2019-01-06 a las 21:06 +0100, Martin Graesslin escribió:

Package: kwin-wayland
Version: 4:5.13.5-1+b1
Severity: normal


kwin-wayland incorrectly depends on kwayland-integration. KWin neither at 
build nor at run time uses anyting from kwayland-integration.


This dependency was added to have the KF5WindowSystemKWaylandPlugin available 
at runtime. Is this causing a problem?


Happy hacking,
--
"Any change looks terrible at first." -- Principle of Design Inertia
Saludos /\/\ /\ >< `/


signature.asc
Description: PGP signature

Bug#921062: pkg-config: installing multiple architectures is not possible

[Christian Gmeiner]

Package: pkg-config
Version: 0.29-6

I want to create a singe docker image where I can cross compile for different
architectures (armhf and arm64). I tried to install both variants but got the
following error:

 pkg-config:armhf : Conflicts: pkg-config
Conflicts: pkg-config:arm64
 pkg-config:arm64 : Conflicts: pkg-config
Conflicts: pkg-config:armhf

-- 
greets
--
Christian Gmeiner, MSc

https://christian-gmeiner.info

Bug#618607: reproducer(?)

[Vincent.Mcintyre]

package mutt
found 618607 1.7.2-1+deb9
thanks

I think I can reproduce this by using a davmail imap server
(which gives easy control of the socket timeout).
Disabling the socket timeout made for a much improved experience.
The davmail version I used was 5.0.0.2801-2~bpo9+1.

My only non-default imap setting is
set imap_keepalive = 120
The $timeout variable is set at default (600s)

Regards
Vince

Bug#921061: Upgrade added "amazon.co.uk" search engine

[Josh Triplett]

Package: firefox
Version: 65.0-1
Severity: normal

Upgrading firefox for some reason added a new search engine for
"amazon.co.uk", which was enabled by default as a "one-click search
engine", which made it show up as part of the drop-down when typing in
the address bar by default.

Bug#921040: CVE-2019-5010

[Salvatore Bonaccorso]

Control: retitle -1 python2.7: CVE-2019-5010: NULL pointer dereference using a 
specially crafted X509 certificate
Control clone -1 -2 -3
Control: reassign -2 src:python3.6 3.6.8-1
Control: retitle -2 python3.6: CVE-2019-5010: NULL pointer dereference using a 
specially crafted X509 certificate
Control: reassign -3 src:python3.7 3.7.2-1
Control: retitle -3 python3.7: CVE-2019-5010: NULL pointer dereference using a 
specially crafted certificate

On Fri, Feb 01, 2019 at 12:33:35AM +0100, Moritz Muehlenhoff wrote:
> Package: python2.7
> Version: 2.7.15-5
> Severity: important
> Tags: security
> 
> This was assigned CVE-2019-5010:
> https://bugs.python.org/issue35746
> https://github.com/python/cpython/pull/11569
> 
> Patch for 2.7:
> https://github.com/python/cpython/commit/06b15424b0dcacb1c551b2a36e739fffa8d0c595

Affects as well the versions in unstable for python3.6 and python3.7
so cloning the bug accordingly.

Regards,
Salvatore

Bug#921060: php-xdebug: just installed and not enabled, browser lost always connection to localhost, not able to show local content

[Dietmar Czekay]

Package: php-xdebug
Version: 2.7.0~beta1+2.6.1+2.5.5-2
Severity: grave
Justification: renders package unusable

Dear Maintainer,

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


   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

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


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

Kernel: Linux 4.19.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE= (charmap=UTF-8)

Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages php-xdebug depends on:
ii  libapache2-mod-php7.3 [phpapi-20180731]  7.3.1-1
ii  libc6    2.28-5
ii  php-common   2:69
ii  php7.3-cgi [phpapi-20180731] 7.3.1-1
ii  php7.3-cli [phpapi-20180731] 7.3.1-1
ii  php7.3-phpdbg [phpapi-20180731]  7.3.1-1
ii  ucf  3.0038+nmu1

php-xdebug recommends no packages.

php-xdebug suggests no packages.

Bug#919121: RM: yaml-cpp -- NBS; packages superseded during transition

[Scott Kitterman]

libyaml-cpp0.5d1 has been removed.  libyaml-cpp0.5v5 has not, so reopening.

Scott K

Bug#921059: gitlab: CVE-2019-6781 CVE-2019-6782 CVE-2019-6783 CVE-2019-6784 CVE-2019-6785 CVE-2019-6786 CVE-2019-6787 CVE-2019-6788 CVE-2019-6789 CVE-2019-6790 CVE-2019-6791 CVE-2019-6792 CVE-2019-679

[Salvatore Bonaccorso]

Source: gitlab
Version: 11.5.7+dfsg-1
Severity: grave
Tags: security upstream
Justification: user security hole

Hi

See
https://about.gitlab.com/2019/01/31/security-release-gitlab-11-dot-7-dot-3-released/
for details to the announce and fixes in 11.7.3, 11.6.8, and 11.5.10.

Regards,
Salvatore

Bug#680668: tasksel: Input methods for chinese - (Was: Updating chinese-t-desktop in tasksel for Wheezy.)

[Aron Xu]

On Fri, Feb 1, 2019 at 3:38 AM John Paul Adrian Glaubitz
 wrote:
>
> Hello!
>
> > On Jan 12, 2019, at 10:02 AM, Yao Wei (魏銘廷)  wrote:
> >
> > or we can follow task-chinese-s-desktop and use fcitx instead of ibus in
> > task-chinese-t-desktop:
> >
> > fcitx,
> > fcitx-chewing,
> > fcitx-table,
> > im-config,
> > fonts-arphic-ukai,
> > fonts-arphic-uming,
> > fonts-noto, # this seems to be unnecessary, but not really sure.
> > fonts-noto-cjk,
> > libreoffice-l10n-zh-tw,
> > libreoffice-help-zh-tw,
> > firefox-esr-l10n-zh-tw | firefox-l10n-zh-tw,
> > poppler-data
>
> I haven’t yet understood why people are moving to fcitx. I have tried it 
> myself after it was automatically installed on my openSUSE machine to replace 
> iBus and found it completely unusable. I didn’t even manage to get any input 
> languages added.
>
> I am using iBus for writing Japanese and I consider it the superior and 
> simpler-to-use solution.
>
> Is there anything that fcitx is supposed to do better than iBus?
>
> Adrian

One of the reasons people moving to fcitx is that the framework has
some architectural advantages that gives a lot room of extending the
input method which ibus does not have so far. An example for Chinese
(China) users is that there are several other alternative
implementations of UI and, even further, commercial products with both
UI and engines.

GNOME's built-in support for ibus is a very old topic that a lot
discussions happened on GNOME's mailing list years ago - in short
there are two reasons: 1) ibus has slightly better support for those
non-CJK languagues whereas GNOME developers are mostly non-CJK native
speakers, 2) RedHat has continued investment on it.

Cheers,
Aron

Bug#921058: Cannot release-build crate `sysinfo` on i386

[Wolfgang Silbermayr]

Package: rustc
Version: 1.32.0+dfsg1-1
Severity: normal

When using the debian package of rustc, an attempt to build the sysinfo 0.8.0
crate fails:

> LLVM ERROR: No support for lowering a copy into EFLAGS when used by this
> instruction!

I only got this on the i386 with the debian package of rustc, in both version
1.31.0 and 1.32.0. A rustc installed through rustup works fine. The debian
rustc only shows this behavior when compiling a release build of the crate, the
debug build works just fine.

It seems to be the cause for the process-viewer build failure on i386 [0].

LLVM weekly #240 [1] mentions a fix for a subtle bug in EFLAGS copy lowering
[2], but as far as I can see, the debian llvm 0.7 code has these changes
included already, so I assume this is not the cause.

The cause might be triggered by the way structures are defined and/or used in
the sysinfo crate's src/linux/processor.rs file. Even though I didn't directly
find something suspicious in the source code, for example replacing the
contents of the CpuValues::work_time(&self) function with an unimplemented!()
call makes the crate compile, I assume because the relevant code gets optimized
out.

--

[0] https://buildd.debian.org/status/fetch.php?pkg=rust-process-
viewer&arch=i386&ver=0.2.0-1&stamp=1547395957&raw=0
[1] https://lists.llvm.org/pipermail/llvm-dev/2018-August/125111.html
[2] https://reviews.llvm.org/rL338481



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

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

Versions of packages rustc depends on:
ii  binutils  2.31.1-11
ii  gcc   4:8.2.0-2
ii  libc6 2.28-5
ii  libc6-dev [libc-dev]  2.28-5
ii  libgcc1   1:8.2.0-16
ii  libllvm7  1:7.0.1-4
ii  libstd-rust-dev   1.32.0+dfsg1-1
ii  libstdc++68.2.0-16

Versions of packages rustc recommends:
ii  cargo 0.32.0-1
ii  rust-gdb  1.32.0+dfsg1-1

Versions of packages rustc suggests:
pn  rust-doc  
pn  rust-src  

-- no debconf information
silwol@debian:~/Downloads/sysinfo$ cargo build --release --verbose
   Compiling arrayvec v0.4.10   

 
   Compiling nodrop v0.1.13 

 
 Running `rustc --crate-name build_script_build 
/home/silwol/.cargo/registry/src/github.com-1ecc6299db9ec823/arrayvec-0.4.10/build.rs
 --color always --crate-type bin --emit=dep-info,link -C opt-level=3 -C 
metadata=bfa3fe6e9c3844c9 -C extra-filename=-bfa3fe6e9c3844c9 --out-dir 
/home/silwol/Downloads/sysinfo/target/release/build/arrayvec-bfa3fe6e9c3844c9 
-L dependency=/home/silwol/Downloads/sysinfo/target/release/deps --cap-lints 
allow`
 Running `rustc --crate-name nodrop 
/home/silwol/.cargo/registry/src/github.com-1ecc6299db9ec823/nodrop-0.1.13/src/lib.rs
 --color always --crate-type lib --emit=dep-info,link -C opt-level=3 -C 
metadata=23b87706b0f0a70a -C extra-filename=-23b87706b0f0a70a --out-dir 
/home/silwol/Downloads/sysinfo/target/release/deps -L 
dependency=/home/silwol/Downloads/sysinfo/target/release/deps --cap-lints allow`
   Compiling libc v0.2.48   

 
 Running `rustc --crate-name build_script_build 
/home/silwol/.cargo/registry/src/github.com-1ecc6299db9ec823/libc-0.2.48/build.rs
 --color always --crate-type bin --emit=dep-info,link -C opt-level=3 --cfg 
'feature="default"' --cfg 'feature="use_std"' -C metadata=b27fc7f09868766c -C 
extra-filename=-b27fc7f09868766c --out-dir 
/home/silwol/Downloads/sysinfo/target/release/build/libc-b27fc7f09868766c -L 
dependency=/home/silwol/Downloads/sysinfo/target/release/deps --cap-lints allow`
   Compiling cfg-if v0.1.6  

 
 Running `rustc --crate-name cfg_if 
/home/silwol/.cargo/registry/src/github.com-1ecc6299db9ec823/cfg-if-0.1.6/src/lib.rs
 --color always --crate-type lib --emit=dep-info,link -C opt-level=3 -C 
metadata=8e9fdbf021b92c7d -C extra-filename=-8e9fdbf021b92c7d --out-dir 
/home/silwol/Downloads/sysinfo/target/release/deps -L 
dependency=/home/silwol/Downloads/sysinfo/target/release/deps --cap-lints allow`
   Compiling scopeguard v0.3.3  
  

Bug#919712: Uploaded

[Mathieu Parent]

Hello,

I've uploaded the package.

I've also added the attached diff.

Here's the changelog:

samba (2:4.5.16+dfsg-1) stretch; urgency=medium

  * New upstream release (latest 4.5.x)
- Drop merged patches
  * Fix CVE-2018-14629 regression when there're more than 20 records on a non
CNAME record.
  * Fix rmdir on non-empty samba directory (Closes: #915248)
  * Ignore nmbd start errors when there is no non-loopback interface
(Closes: #893762)
  * Ignore nmbd start errors when there is  no local IPv4 non-loopback interface
(Closes: #859526)
  * s3:ntlm_auth: fix memory leak in manage_gensec_request() (Closes: #919611)
  * Add debian/gitlab-ci.yml

 -- Mathieu Parent   Thu, 31 Jan 2019 23:12:28 +0100
diff --git a/debian/changelog b/debian/changelog
index a2f86eff095..26f1ab0ddbe 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,4 +1,4 @@
-samba (2:4.5.16+dfsg-1) UNRELEASED; urgency=medium
+samba (2:4.5.16+dfsg-1) stretch; urgency=medium
 
   * New upstream release (latest 4.5.x)
 - Drop merged patches
@@ -10,8 +10,9 @@ samba (2:4.5.16+dfsg-1) UNRELEASED; urgency=medium
   * Ignore nmbd start errors when there is  no local IPv4 non-loopback interface
 (Closes: #859526)
   * s3:ntlm_auth: fix memory leak in manage_gensec_request() (Closes: #919611)
+  * Add debian/gitlab-ci.yml
 
- -- Mathieu Parent   Fri, 18 Jan 2019 07:35:15 +0100
+ -- Mathieu Parent   Thu, 31 Jan 2019 23:12:28 +0100
 
 samba (2:4.5.12+dfsg-2+deb9u4) stretch-security; urgency=high
 
diff --git a/debian/gitlab-ci.yml b/debian/gitlab-ci.yml
new file mode 100644
index 000..8d3e6f810f1
--- /dev/null
+++ b/debian/gitlab-ci.yml
@@ -0,0 +1,14 @@
+#include: https://salsa.debian.org/salsa-ci-team/pipeline/raw/master/salsa-ci.yml
+include: https://salsa.debian.org/sathieu/pipeline/raw/master/salsa-ci.yml
+
+build:
+extends: .build-stretch
+
+lintian:
+extends: .test-lintian-stretch
+
+autopkgtest:
+extends: .test-autopkgtest-stretch
+
+piuparts:
+extends: .test-piuparts-stretch
diff --git a/debian/patches/fix-rmdir.patch b/debian/patches/fix-rmdir.patch
index 1db437695de..6b9c0eefb79 100644
--- a/debian/patches/fix-rmdir.patch
+++ b/debian/patches/fix-rmdir.patch
@@ -1,3 +1,170 @@
+From: Stefan Metzmacher 
+Date: Tue, 20 Jun 2017 08:35:13 +0200
+Subject: s3:libsmb: add cli_smb2_delete_on_close*()
+
+Signed-off-by: Stefan Metzmacher 
+Reviewed-by: Jeremy Allison 
+(cherry picked from commit 8d4005b07b08d5673b75d5d79f9b3d6936596fae)
+
+diff --git a/source3/libsmb/cli_smb2_fnum.c b/source3/libsmb/cli_smb2_fnum.c
+index 43f116b681d..674c52e4405 100644
+--- a/source3/libsmb/cli_smb2_fnum.c
 b/source3/libsmb/cli_smb2_fnum.c
+@@ -484,6 +484,133 @@ NTSTATUS cli_smb2_close_fnum(struct cli_state *cli, uint16_t fnum)
+ 	return status;
+ }
+ 
++struct cli_smb2_delete_on_close_state {
++	struct cli_state *cli;
++	uint16_t fnum;
++	struct smb2_hnd *ph;
++	uint8_t data[1];
++	DATA_BLOB inbuf;
++};
++
++static void cli_smb2_delete_on_close_done(struct tevent_req *subreq);
++
++struct tevent_req *cli_smb2_delete_on_close_send(TALLOC_CTX *mem_ctx,
++	struct tevent_context *ev,
++	struct cli_state *cli,
++	uint16_t fnum,
++	bool flag)
++{
++	struct tevent_req *req = NULL;
++	struct cli_smb2_delete_on_close_state *state = NULL;
++	struct tevent_req *subreq = NULL;
++	uint8_t in_info_type;
++	uint8_t in_file_info_class;
++	NTSTATUS status;
++
++	req = tevent_req_create(mem_ctx, &state,
++struct cli_smb2_delete_on_close_state);
++	if (req == NULL) {
++		return NULL;
++	}
++	state->cli = cli;
++	state->fnum = fnum;
++
++	if (smbXcli_conn_protocol(cli->conn) < PROTOCOL_SMB2_02) {
++		tevent_req_nterror(req, NT_STATUS_INVALID_PARAMETER);
++		return tevent_req_post(req, ev);
++	}
++
++	status = map_fnum_to_smb2_handle(cli, fnum, &state->ph);
++	if (tevent_req_nterror(req, status)) {
++		return tevent_req_post(req, ev);
++	}
++
++	/*
++	 * setinfo on the handle with info_type SMB2_SETINFO_FILE (1),
++	 * level 13 (SMB_FILE_DISPOSITION_INFORMATION - 1000).
++	 */
++	in_info_type = 1;
++	in_file_info_class = SMB_FILE_DISPOSITION_INFORMATION - 1000;
++	/* Setup data array. */
++	SCVAL(&state->data[0], 0, flag ? 1 : 0);
++	state->inbuf.data = &state->data[0];
++	state->inbuf.length = 1;
++
++	subreq = smb2cli_set_info_send(state, ev,
++   cli->conn,
++   cli->timeout,
++   cli->smb2.session,
++   cli->smb2.tcon,
++   in_info_type,
++   in_file_info_class,
++   &state->inbuf, /* in_input_buffer */
++   0, /* in_additional_info */
++   state->ph->fid_persistent,
++   state->ph->fid_volatile);
++	if (tevent_req_nomem(subreq, req)) {
++		return tevent_req_post(req, ev);
++	}
++	tevent_req_set_callback(subreq,
++cli_smb2_delete_on_close_done,
++req);
++	return req;
++}
++
++static void cli_smb2_delete_on_close_done(struct tevent_req *subreq)
++{
++	NTSTATUS status = smb2cli_set_info_recv(subreq);
++	tevent_req_simple_fini

Bug#921057: unanimity: don't depend on build target

[Steve Langasek]

Package: unanimity
Version: 3.3.0+dfsg-1
Severity: serious
Tags: patch
Justification: FTFS
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu disco ubuntu-patch

Dear maintainers,

unanimity is failing to build from source on the Debian buildds because the
package relies on certain html documentation being regenerated at build
time, but it's only regenerated if the 'build' target is called, which is
not the case for an arch-only build.

The attached patch fixes debian/rules to build the docs as part of the
binary-arch target instead.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru unanimity-3.3.0+dfsg/debian/rules unanimity-3.3.0+dfsg/debian/rules
--- unanimity-3.3.0+dfsg/debian/rules   2019-01-31 21:22:11.0 -0800
+++ unanimity-3.3.0+dfsg/debian/rules   2019-01-31 21:49:06.0 -0800
@@ -23,7 +23,7 @@
  PBCCS.html \
 )
 
-build: $(docs)
+binary-arch: $(docs)
 %:
dh $@ \
--package=unanimity \

Bug#920285: mate-panel: Panel widgets should expose an Accessible object to at-spi

[Mike Gabriel]

Hi Samuel,

On Wednesday, 23 January 2019, Samuel Thibault wrote:
> Package: mate-panel
> Version: 1.20.1-1
> Severity: normal
> Tags: a11y upstream
> Owner: b...@hypra.fr
> User: b...@hypra.fr
> Usertags: hypra
> Forwarded: https://github.com/mate-desktop/mate-panel/issues/835
> 
> From upstream report, for tracking in Debian:
> 
> Steps to reproduce the behaviour
> 
> Run a mate desktop
> Run orca, enable mouse review ("Speak object under mouse" option in its 
> general configuration panel)
> Move mouse to mate panel wigets, for instance here the clock
> 
> Expected behaviour
> 
> Orca should speak the panel widget content, in the instance here the 
> clock date & time
> 
> Actual behaviour
> 
> Orca just says "panel"
> 
> MATE general version
> 
> 1.20
> Package version
> 
> 1.20.1
> Linux Distribution
> 
> Debian buster
> Additional information
> 
> The issue is that mate-panel widgets do not expose Accessible objects through 
> at-spi. When looking in accerciser, we see mate-panel expose the panel 
> structure (thus why Orca says "panel"), but the final widgets are not exposed.
> 
> Of course, for proper complete support, probably each and every panel widget 
> needs to be fixed to expose its content through at-spi. Perhaps mate-panel 
> should at least put the name of the widget in the panel description (just 
> like it does with panel_a11y_set_atk_name_desc for "Top Panel"), so at least 
> the user knows which widget it is. We can then work on adding support to 
> widgets, at least the most commonly used.
> 
> Samuel

Is the patch mature enough for Debian buster? I am open to shipoing it with 
Debian's MATE 1.20, once upstream has applied it. So, what's the status of this?

Mike
-- 
Sent from my Sailfish device

Bug#913714: RM: libgap-sage -- ROM; abandoned upstream

[Jerome BENOIT]

tags 913714 - moreinfo



signature.asc
Description: OpenPGP digital signature

Bug#921056: ITP: ruby-blade -- Sprockets Toolkit for Building and Testing JavaScript Libraries

[Utkarsh Gupta]

Package: wnpp
Severity: wishlist
Owner: Utkarsh Gupta 

* Package name  : ruby-blade
   Version  : 0.7.1
   Upstream Author  : Javan Makhmali
* URL   : https://github.com/javan/blade
* License   : Expat
   Programming Lang : Ruby
   Description  : Sprockets Toolkit for Building and Testing JavaScript
Libraries

It is a Sprockets Toolkit for Building and Testing JavaScript Libraries and
ruby-actioncable needs blade. Hence this needs to be packaged.

Thanks,
Utkarsh Gupta

Bug#921055: ITP: ruby-blade-qunit_adapter --Blade adapter for the QUnit testing framework

[Utkarsh Gupta]

Package: wnpp
Severity: wishlist
Owner: Utkarsh Gupta 

* Package name  : ruby-blade-qunit_adapter
   Version  : 1.20.0
   Upstream Author  : Javan Makhmali
* URL   : https://github.com/javan/blade-qunit_adapter
* License   : Expat
   Programming Lang : Ruby
   Description  : Blade adapter for the QUnit testing framework

It is a blade adapter for the QUnit testing framework and a dependency of
blade and hence needs to be packaged.

Thanks,
Utkarsh Gupta

Bug#921054: unanimity: build compatibility with -Wl,--as-needed

[Steve Langasek]

Package: unanimity
Version: 3.3.0+dfsg-1
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu disco ubuntu-patch

Dear maintainers,

The unanimity package fails to build in Ubuntu because it supplies options
to the linker in the wrong order:

[...]
[ 95%] Linking CXX executable ../gcpp
cd /<>/unanimity-3.3.0+dfsg/build/src && /usr/bin/cmake -E 
cmake_link_script CMakeFiles/gcpp.dir/link.txt --verbose=1
/usr/bin/c++  -g -O2 -fdebug-prefix-map=/<>/unanimity-3.3.0+dfsg=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
-D_FORTIFY_SOURCE=2 -Wall -Wextra -Wno-unused-parameter -Wno-unused-variable 
-Wno-unused-local-typedefs  -lpthread  -rdynamic 
CMakeFiles/gcpp.dir/main/gcpp.cpp.o  -o ../gcpp -ldl libunanimity.a libcc2.a 
-lpbbam -Wl,-Bstatic -lpbcopper -Wl,-Bdynamic 
/usr/bin/ld: libunanimity.a(Workflow.cpp.o): undefined reference to symbol 
'pthread_create@@GLIBC_2.2.5'
/usr/bin/ld: 
/usr/lib/gcc/x86_64-linux-gnu/8/../../../x86_64-linux-gnu/libpthread.so: error 
adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
[...]

  (https://launchpad.net/ubuntu/+source/unanimity/3.3.0+dfsg-1)

Per ,
libraries must be passed on the commandline after the objects which
reference them, otherwise they will be discarded by the linker, resulting in
errors such as the above.

In the case of unanimity, the out-of-order option that's being passed is
-lpthread, which is specified in debian/rules.  However, if we pass -pthread
instead of -lpthread, gcc knows to put the options in the right order when
passing to ld.  So attached is a simple patch to fix this issue.

I have uploaded this patch to Ubuntu.  Please consider applying it in Debian
as well.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru unanimity-3.3.0+dfsg/debian/rules unanimity-3.3.0+dfsg/debian/rules
--- unanimity-3.3.0+dfsg/debian/rules   2019-01-24 02:40:05.0 -0800
+++ unanimity-3.3.0+dfsg/debian/rules   2019-01-31 21:22:11.0 -0800
@@ -44,7 +44,7 @@
 
 config-main:
dh_auto_configure -- \
-   -DCMAKE_EXE_LINKER_FLAGS="-lpthread" \
+   -DCMAKE_EXE_LINKER_FLAGS=-pthread \
-DUNY_build_tests=OFF \
-DPYTHON_SWIG=ON \
-DZLIB_INCLUDE_DIRS=$(INCLUDE) \

Bug#921053: ITP: ruby-faye -- Simple pub/sub messaging for the web

[Utkarsh Gupta]

Package: wnpp
Severity: wishlist
Owner: Utkarsh Gupta 

* Package name  : ruby-faye
   Version  : 1.2.4
   Upstream Author  : James Coglan
* URL   : https://github.com/faye/faye
* License   : Expat
   Programming Lang : Ruby
   Description  : Simple pub/sub messaging for the web

Faye is a set of tools for simple publish-subscribe messaging between web
clients. It ships with easy-to-use message routing servers for Node.js and
Rack applications, and clients that can be used on the server and in the
browser.

This is an unpackaged gem for blade and hence needs to be packaged.

Thanks,
Utkarsh Gupta

Bug#920886: btrfs-progs: btrfs send failed to determine mount point for snapshots stored in /

[Chris Lawrence]

Package: btrfs-progs
Followup-For: Bug #920886

Here's a properly formatted patch that fixes the bug; it appears to
work on my system at least.

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

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

Versions of packages btrfs-progs depends on:
ii  libblkid1  2.33.1-0.1
ii  libc6  2.28-5
ii  liblzo2-2  2.10-0.1
ii  libuuid1   2.33.1-0.1
ii  libzstd1   1.3.8+dfsg-3
ii  zlib1g 1:1.2.11.dfsg-1

btrfs-progs recommends no packages.

Versions of packages btrfs-progs suggests:
ii  duperemove  0.11.1-3

-- no debconf information
--- a/utils.c
+++ b/utils.c
@@ -2079,7 +2079,7 @@ int find_mount_root(const char *path, ch
while ((ent = getmntent(mnttab))) {
len = strlen(ent->mnt_dir);
if (strncmp(ent->mnt_dir, path, len) == 0 &&
-   (path[len] == '/' || path[len] == '\0')) {
+   (len == 1 || path[len] == '/' || path[len] == '\0')) {
/* match found and use the latest match */
if (longest_matchlen <= len) {
free(longest_match);

Bug#921052: ITP: ruby-faye-websocket -- Standards-compliant WebSocket client and server

[Utkarsh Gupta]

Package: wnpp
Severity: wishlist
Owner: Utkarsh Gupta 

* Package name  : ruby-faye-websocket
   Version  : 0.10.7
   Upstream Author  : James Coglan
* URL   : https://github.com/faye/faye-websocket-ruby
* License   : Expat
   Programming Lang : Ruby
   Description  : Standards-compliant WebSocket client and server

faye-websocket is a general-purpose WebSocket implementation extracted from
the Faye  project. It provides classes for easily
building WebSocket servers and clients in Ruby. It does not provide a
server itself, but rather makes it easy to handle WebSocket connections
within an existing Rack  application. It does not
provide any abstraction other than the standard WebSocket API
.
.
This is an unpackaged gem for blade and hence needs to be packaged.

Thanks,
Utkarsh Gupta

Bug#919272: Is multiple-layers of alternatives a good thing to users?

[Mo Zhou]

Hi devel,

A user suggested[1] that the 6 variants[2] of BLIS should be
co-installable. However, making them co-installable would result in
multiple layers of alternatives in the update-alternatives system and
will possibly confuse users, as discussed in [3]. I wrote this mail
in case anyone has a better solution so we will have a chance to fix[1].

Tacking the three 32-bit variants as examples, we will have the
following alternative chain if the 3 variants were made co-installable:

  Package: libblis2-openmp,  Provides: libblis.so.2
  Package: libblis2-pthread, Provides: libblis.so.2
  Package: libblis2-serial,  Provides: libblis.so.2
  Package: libblis2 (meta),  Provides: libblas.so.3,  Depends: libblis.so.2,
  Package: python3-numpy,Depends: libblas.so.3

  numpy asks for libblas.so.3
-> libblas.so.3 is an alternative pointing to libblis2
  -> libblis.so.2 is an alternative pointing to any one of the three 
variants

Such layout not only makes the packaging more difficult to maintain, but
also makes it harder for the user to understand what BLAS backend is
actually invoked. So my current solution is only allowing one instance
of the three variants installed on the system, i.e. every one of the
three variants conflicts with each other.  Drew and Sébastien agreed
with the choice to make the variants conflict to each other. So I
personally tend to leave the bug[1] unresolved.

However if anyone comes up with a better idea or solution, or believes
that multiple layers of alternatives are fine, we could discuss about it
and try to address the co-installability issue[1].

As a side note, different variants of BLIS are co-installable on Fedora,
but they come with different SONAMEs and there is no any mechanism
similar to update-alternatives at all.

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=919272
[2] 6 variants = (32-bit index, 64-bit index) x (openmp, pthread, serial)
[3] https://lists.debian.org/debian-science/2019/01/msg7.html

Bug#921051: RM: ruby-facebox-rails/0.2.0-2

[Pirate Praveen]

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

This package is no longer required but since diaspora 0.6 still depends
on it, this cannot be removed before diaspora is updated to 0.7
(#920814). But diaspora update is still in progress, so to facilitate 
rails 5

migration to testing, please remove this from testing.

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

Kernel: Linux 4.16.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=ml_IN.UTF-8, LC_CTYPE=ml_IN.UTF-8 (charmap=UTF-8), 
LANGUAGE=ml_IN.UTF-8 (charmap=UTF-8)

Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#921050: RM: ruby-protected-attributes/1.1.4-2

[Pirate Praveen]

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

This package is not compatible with rails 5, but redmine 3 still depends
on it, so it cannot be removed from unstable till redmine is updated
(which is still in progress). Since this is blocking rails 5 migration
to testing, it should be removed from testing to facilitate this
migration.

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

Kernel: Linux 4.16.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=ml_IN.UTF-8, LC_CTYPE=ml_IN.UTF-8 (charmap=UTF-8), 
LANGUAGE=ml_IN.UTF-8 (charmap=UTF-8)

Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#921049: RM: redmine/3.4.6-1

[Pirate Praveen]

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

Please remove redmine from testing to facilitate migration of rails 5.

redmine 4 is being prepared which is compatible with rails 5 but it is
not ready yet.

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

Kernel: Linux 4.16.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=ml_IN.UTF-8, LC_CTYPE=ml_IN.UTF-8 (charmap=UTF-8), 
LANGUAGE=ml_IN.UTF-8 (charmap=UTF-8)

Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#921047: netdata: mysql plugin requires further post-install work

[Nye Liu]

Package: netdata
Version: 1.11.1+dfsg-5
Severity: normal

Out of the box, the mysql plugin does not work on debian.

The /usr/lib/netdata/conf.d/python.d/mysql.conf debiancfg entry requires
/etc/mysql/debian.cnf to be readable by user or group netdata, and the
error log does not indicate this is the case, it silently fails.

Preferably, though, there should be a post-install script which installs a
mysql netdata user using debian-sys-maint credentials and which has limited
permissions.

This would be safer, as giving netdata debian-sys-maint privs to mysql is
probably a bad idea.

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

Kernel: Linux 4.18.16-x86_64-linode118 (SMP w/4 CPU cores; PREEMPT)
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 netdata depends on:
ii  netdata-core  1.11.1+dfsg-5
ii  netdata-plugins-bash  1.11.1+dfsg-5
ii  netdata-web   1.11.1+dfsg-5

Versions of packages netdata recommends:
ii  netdata-plugins-nodejs  1.11.1+dfsg-5
ii  netdata-plugins-python  1.11.1+dfsg-5

netdata suggests no packages.

-- debconf information:
  netdata/title:
  netdata/send_email: YES

Bug#791609: Error on restoring ledger buffer from desktop file

[Ben Hutchings]

On Fri, 2019-02-01 at 02:59 +, Ben Hutchings wrote:
[...]
> I've just tested using emacs-gtk version 1:26.1+1-3.

...and ledger version 3.1.2~pre1+g3a00e1c+dfsg1-5+b3.

> I can't reproduce
> the bug with either a freshly created desktop file or with the desktop
> entry quoted in my original report.

Ben.

-- 
Ben Hutchings
Life is what happens to you while you're busy making other plans.
  - John Lennon



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

Bug#921046: xserver-xorg-core: Xorg crashes when I run the Easystroke application

[Mark St. John]

Package: xserver-xorg-core
Version: 2:1.19.6-1
Severity: normal
Tags: patch

Dear Maintainer,
When I use the Easystroke application (https://github.com/thjaeger/easystroke), 
it causes Xorg to sporadically crash when multiple monitors are enabled. If I 
update hw/xfree86/drivers/modesetting/drmmode_display.c to remove the call to 
drmModeSetCursor2, the crashes no longer happen.

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

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

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


-- Package-specific info:
/etc/X11/X does not exist.
/etc/X11/X is not a symlink.
/etc/X11/X is not executable.

VGA-compatible devices on PCI bus:
--
00:02.0 VGA compatible controller [0300]: Intel Corporation HD Graphics 630 
[8086:591b] (rev 04)

/etc/X11/xorg.conf does not exist.

/etc/X11/xorg.conf.d does not exist.

/etc/modprobe.d contains no KMS configuration files.

Kernel version (/proc/version):
---
Linux version 4.19.12-1rodete1-amd64 (glinux-t...@google.com) (gcc version 
8.0.1 20180218 (experimental) [trunk revision 257787] (Debian 8-20180218-1)) #1 
SMP Debian 4.19.12-1rodete1 (2018-12-26)

Xorg X server log files on system:
--
-rw-r--r-- 1 mstjohn primarygroup 107406 Jan 31 18:15 
/home/mstjohn/.local/share/xorg/Xorg.1.log
-rw-r--r-- 1 rootroot  97664 Jan 31 18:45 /var/log/Xorg.1.log
-rw-r--r-- 1 mstjohn primarygroup  93767 Jan 31 18:58 
/home/mstjohn/.local/share/xorg/Xorg.0.log
-rw-r--r-- 1 rootroot  73230 Jan 31 20:42 /var/log/Xorg.0.log

Contents of most recent Xorg X server log file (/var/log/Xorg.0.log):
-
[  6697.336] 
X.Org X Server 1.19.6
Release Date: 2017-12-20
[  6697.336] X Protocol Version 11, Revision 0
[  6697.336] Build Operating System: Linux 4.19.12-1rodete1-amd64 x86_64 Debian
[  6697.336] Current Operating System: Linux mstjohn 4.19.12-1rodete1-amd64 #1 
SMP Debian 4.19.12-1rodete1 (2018-12-26) x86_64
[  6697.336] Kernel command line: BOOT_IMAGE=/vmlinuz-4.19.12-1rodete1-amd64 
root=/dev/mapper/sysvg-root ro ima_hash=sha256 slab_nomerge 
intel_iommu=on,igfx_off elevator=deadline apparmor=1 security=apparmor quiet 
splash
[  6697.336] Build Date: 31 January 2019  08:34:00PM
[  6697.336] xorg-server 2:1.19.6-1 (https://www.debian.org/support) 
[  6697.336] Current version of pixman: 0.34.0
[  6697.336]Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
[  6697.336] Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[  6697.336] (==) Log file: "/var/log/Xorg.0.log", Time: Thu Jan 31 20:39:16 
2019
[  6697.336] (==) Using system config directory "/usr/share/X11/xorg.conf.d"
[  6697.336] (==) No Layout section.  Using the first Screen section.
[  6697.336] (==) No screen section available. Using defaults.
[  6697.336] (**) |-->Screen "Default Screen Section" (0)
[  6697.336] (**) |   |-->Monitor ""
[  6697.336] (==) No monitor specified for screen "Default Screen Section".
Using a default monitor configuration.
[  6697.336] (==) Automatically adding devices
[  6697.336] (==) Automatically enabling devices
[  6697.336] (==) Automatically adding GPU devices
[  6697.336] (==) Max clients allowed: 256, resource mask: 0x1f
[  6697.336] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist.
[  6697.336]Entry deleted from font path.
[  6697.336] (==) FontPath set to:
/usr/share/fonts/X11/misc,
/usr/share/fonts/X11/100dpi/:unscaled,
/usr/share/fonts/X11/75dpi/:unscaled,
/usr/share/fonts/X11/Type1,
/usr/share/fonts/X11/100dpi,
/usr/share/fonts/X11/75dpi,
built-ins
[  6697.336] (==) ModulePath set to "/usr/lib/xorg/modules"
[  6697.336] (II) The server relies on udev to provide the list of input 
devices.
If no devices become available, reconfigure udev or disable 
AutoAddDevices.
[  6697.336] (II) Loader magic: 0x5568adc5dde0
[  6697.336] (II) Module ABI versions:
[  6697.336]X.Org ANSI C Emulation: 0.4
[  6697.336]X.Org Video Driver: 23.0
[  6697.336]X.Org XInput driver : 24.1
[  6697.336]X.Org Server Extension : 10.0
[  6697.337] (++) using VT number 7

[  6697.337] (II) systemd-logind: logind integration requires -keeptty and 
-keeptty was not provided, disabling logind integration
[  6697.338] (II) xfree86: Adding drm device (/dev/dri/card0)
[  6697.353] (--) PCI:*(0:0:2:0) 8086:591b:1028:07bf rev 4, Mem @ 
0xeb00/16777216, 0x8000/268435456, I/O @ 0xf000/64, BIOS @

Bug#791609: Error on restoring ledger buffer from desktop file

[Ben Hutchings]

On Sat, 2019-01-26 at 13:31 -0300, Martin Michlmayr wrote:
> * David Bremner  [2015-07-10 20:58]:
> > > Thanks for the report.  Here is how I tried, and failed, to
> > > reproduce this:
> > > 
> > > emacs -q foo.lgr

My bug report relates to ledger-mode, but this command sequence doesn't
activate ledger-mode...

> > > M-x desktop-save
> > > C-x C-c
> > > emacs -q
> > > M-x desktop-read
> > > 
> > > I'm using emacs24.4 still, so maybe this is 24.5 specific.
> > > 
> > > Cheers,
> > 
> > I tried the same recipe with 24.5, but still did not reproduce the
> > failure.
> 
> Ben, it seems like David cannot reproduce your issue.  Can you check
> again?

I've just tested using emacs-gtk version 1:26.1+1-3.  I can't reproduce
the bug with either a freshly created desktop file or with the desktop
entry quoted in my original report.

Ben.

-- 
Ben Hutchings
Life is what happens to you while you're busy making other plans.
  - John Lennon



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

Bug#913823: apache2: dav.load does not check for an already loaded dav_module

[Nye Liu]

Package: apache2
Version: 2.4.38-1
Followup-For: Bug #913823

Workaround in /etc/apache2/mods-available/dav.load:


LoadModule dav_module /usr/lib/apache2/modules/mod_dav.so


Alternately just make dav_fs not depend on dav, it will autoload it.

Bug#921045: RFS: ncurses-hexedit/0.9.7+orig-7

[Carlos Maddela]

Package: sponsorship-requests
Severity: normal

  Dear mentors,

  I am looking for a sponsor for my package "ncurses-hexedit"

 * Package name: ncurses-hexedit
   Version : 0.9.7+orig-7
   Upstream Author : Adam Rogoyski 
 * URL : http://www.rogoyski.com/adam/programs/hexedit/
 * License : GPL-2.0+
   Section : editors

  It builds this binary package:

ncurses-hexedit - Edit files/disks in hex, ASCII and EBCDIC

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

  https://mentors.debian.net/package/ncurses-hexedit


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

dget -ux 
https://mentors.debian.net/debian/pool/main/n/ncurses-hexedit/ncurses-hexedit_0.9.7+orig-7.dsc

  Changes since the last upload:

  * Build with Debhelper compat level 12.
  * Perform wrap-and-sort.
  * Update debian/gbp.conf to conform with DEP14 conventions.
  * Add support for nodoc build profile.
  * Add note about upstream version number in debian/README.source.
Thanks to Dmitry Bogatov for the suggestion.
  * Reformat debian/README.Debian.

  Regards,
   Carlos Maddela

Bug#920935: docker.io: ships /usr/bin/containerd-shim, already provided by containerd

[Dmitry Smirnov]

On Friday, 1 February 2019 12:06:37 PM AEDT Arnaud Rebillout wrote:
> Is it a situation where we should put a Conflict statement? Like
> `Conflicts: containerd` ?

No, we should not conflict without a good reason.

On this instance we have to rename binary back to "docker-containerd-shim" or 
install the binary into a private location.

-- 
Cheers,
 Dmitry Smirnov.

---

It is a fine thing to be honest, but it is also very important to be right.
-- Winston Churchill


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

Bug#908055: Processed: fixed 908055 in 17.12.1+dfsg-1

[Dmitry Smirnov]

On Friday, 1 February 2019 12:13:01 PM AEDT Arnaud Rebillout wrote:
> If I understand, this bug is fixed? Should we close it?

Yes, I think it should be closed.
There is no actionable tasks are left for maintainers to do...

-- 
All the best,
 Dmitry Smirnov.

---

No person, no idea, and no religion deserves to be illegal to insult,
not even the Church of Emacs.
-- Richard Stallman


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

Bug#895425: pciutils: New upstream version 3.5.6

[Guillem Jover]

Control: retitle -1 pciutils: New upstream version 3.6.2

Hi!

On Wed, 2018-04-11 at 14:02:15 +0200, Michael Schaller wrote:
> Package: pciutils
> Version: 1:3.5.2-1
> Severity: normal
> Tags: upstream

> Please consider updating the pciutils package as there is the new
> upstream version 3.5.6 from 2017-11-17. The current version 3.5.2
> is from 2016-10-03 and hence quite a lot of current hardware IDs
> aren't included.
> 
> Furthermore please note that the check for new upstream versions
> is also broken for this package.

There is now a new upstream release from 2018-08-12. It would be nice
to get this packaged, ideally before the freeze, if it does not bump
the SONAME.

Michael, maybe you'd be interested in taking over this package? I'm
afraid Anibal is pretty much MIA (CCing Matt too). :/

Thanks,
Guillem

Bug#909071: pbbam: FTBFS on every release architecture where it previously built

[Steve Langasek]

Package: pbbam
Version: 0.19.0+dfsg-1
Followup-For: Bug #909071
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu disco ubuntu-patch

This build failure is caused by a wrong hard-coded assumption about the
build directory path on the autobuilders.  Instead of mangling the generated
files one direction by stripping +dfsg and then readding it in select cases,
instead limit the fields from which +dfsg is stripped so that the build
works regardless of the path to the build directory.

The attached patch has been uploaded to Ubuntu to fix this build failure
there.  Please consider applying this path in Debian as well.

Cheers,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru pbbam-0.19.0+dfsg/debian/rules pbbam-0.19.0+dfsg/debian/rules
--- pbbam-0.19.0+dfsg/debian/rules  2018-10-10 03:45:02.0 -0700
+++ pbbam-0.19.0+dfsg/debian/rules  2019-01-31 16:56:25.0 -0800
@@ -55,7 +55,7 @@
-e 's|@PacBioBAM_TestsDir@|$(CURDIR)/tests|g' \
-e 's|@PacBioBAM_VERSION@|$(DEB_VERSION_UPSTREAM)|g' \
-e 's|@GeneratedTestDataDir@|$(generated_data_dir)|g' \
-   -e 's|+dfsg||g' -e 's|\(/build/$(DEB_SOURCE)-[0-9.]\+\)/|\1+dfsg/|' \
+   -e '/@PG/s|+dfsg||g' \
-e 's/$$SAMTOOLS/samtools/g' \
$< > $@
 

Bug#908055: Processed: fixed 908055 in 17.12.1+dfsg-1

[Arnaud Rebillout]

On Mon, 10 Sep 2018 08:18:56 +0200 Salvatore Bonaccorso
 wrote:
> Hi Dmitry,
>
> On Mon, Sep 10, 2018 at 09:23:59AM +1000, Dmitry Smirnov wrote:
> > On Thursday, 6 September 2018 2:19:24 PM AEST Salvatore Bonaccorso
wrote:
> > > > > fixed 908055 17.12.1+dfsg-1
> > >
> > > Is this the first version which was using the fixed
> > > golang-github-vbatts-tar-split?
> >
> > Yes it is. I've confirmed that by examining the build log.
>
> Perfect, thanks for confirming!
>
> Regards,
> Salvatore
>

If I understand, this bug is fixed? Should we close it?

Bug#920935: docker.io: ships /usr/bin/containerd-shim, already provided by containerd

[Arnaud Rebillout]

On Wed, 30 Jan 2019 18:23:14 +0100 Andreas Beckmann  wrote:
>
> Here is a list of files that are known to be shared by both packages
> (according to the Contents file for sid/amd64, which may be
> slightly out of sync):
>
> /usr/bin/containerd-shim
>
>
> Cheers,
>
> Andreas
>
> PS: for more information about the detection of file overwrite errors
> of this kind see https://qa.debian.org/dose/file-overwrites.html

Is it a situation where we should put a Conflict statement? Like
`Conflicts: containerd` ?

Bug#921044: RFS: mlucas/17.1-3 [RC]

[Alex Vong]

Package: sponsorship-requests
Severity: important

Hi mentors,

I am looking for a sponsor for my package "mlucas"

* Package name: mlucas
  Version : 17.1-3
  Upstream Author : Ernst W. Mayer 
* URL : 
* License : GPL-2+
  Section : math

It builds those binary packages:

  mlucas - program to perform Lucas-Lehmer test on a Mersenne number

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

  https://mentors.debian.net/package/mlucas


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

  dget -x https://mentors.debian.net/debian/pool/main/m/mlucas/mlucas_17.1-3.dsc

More information about mlucas can be obtained from
https://www.mersenneforum.org/mayer/README.html.

Changes since the last upload:

  mlucas (17.1-3) unstable; urgency=medium

* RC bug fix release (Closes: #920835), fix missing binary name in wrapper
script and undefined macro error in powerpc build.
* Add architecture hurd-i386.

   -- Alex Vong   Fri, 01 Feb 2019 05:10:29 +0800

Additional info
===
As I've mentioned in , there's in fact
still bug to be fixed, namely the SIMD binaries in i386 and arm64
segfault when being run. Luckily, there's a fallback generic c
binary. It is slower, but it should work.

I also add the new arch hurd-i386 since it is supported (but hasn't been
tested yet).

Cheers,
Alex


signature.asc
Description: PGP signature

Bug#921043: dpdk-dev: dpdk-sdk-env.sh no longer included in dpdk-dev

[Nicolas S. Dade]

Package: dpdk-dev
Version: 18.11-4~bpo9+1
Severity: normal

Dear Maintainer,

The file
 /usr/share/dpdk/dpdk-sdk-env.sh
used to be part of the dpdk-dev packages. It defines the environment
variables needed to use the dpdk sdk, and the debian documentation
recommended sourcing it into your shell in order to use dpdk.

The file debian/dpsk-sdk-env.sh.in file is present in the dpdk
18.11-4~bpo9+1 sources, but the line in debian/rule that produced it
is missing. (For that matter, other lines related to the dpdk-dev package
in rules are missing too).

Perhaps this is on purpose. But I don't see it in changelog, nor do I
see a suitable alternative.



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

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

Versions of packages dpdk-dev depends on:
ii  libbsd00.8.3-1
ii  libc6  2.24-11+deb9u3
ii  libdpdk-dev18.11-4~bpo9+1
ii  libelf10.168-1
ii  libgcc11:6.3.0-18+deb9u1
ii  libjansson42.9-1
ii  libnuma1   2.0.11-2.1
ii  librte-acl18.1118.11-4~bpo9+1
pn  librte-acl2
ii  librte-bbdev18.11  18.11-4~bpo9+1
ii  librte-bpf18.1118.11-4~bpo9+1
ii  librte-bus-dpaa18.11   18.11-4~bpo9+1
ii  librte-bus-pci18.1118.11-4~bpo9+1
ii  librte-bus-vdev18.11   18.11-4~bpo9+1
ii  librte-cfgfile18.1118.11-4~bpo9+1
pn  librte-cfgfile2
ii  librte-cmdline18.1118.11-4~bpo9+1
pn  librte-cmdline2
ii  librte-common-dpaax18.11   18.11-4~bpo9+1
ii  librte-compressdev18.1118.11-4~bpo9+1
ii  librte-cryptodev18.11  18.11-4~bpo9+1
pn  librte-cryptodev2  
pn  librte-distributor1
ii  librte-distributor18.1118.11-4~bpo9+1
ii  librte-eal18.1118.11-4~bpo9+1
pn  librte-eal3
ii  librte-efd18.1118.11-4~bpo9+1
ii  librte-ethdev18.11 18.11-4~bpo9+1
pn  librte-ethdev5 
ii  librte-eventdev18.11   18.11-4~bpo9+1
ii  librte-flow-classify18.11  18.11-4~bpo9+1
ii  librte-gro18.1118.11-4~bpo9+1
ii  librte-gso18.1118.11-4~bpo9+1
ii  librte-hash18.11   18.11-4~bpo9+1
pn  librte-hash2   
pn  librte-ip-frag1
ii  librte-ip-frag18.1118.11-4~bpo9+1
pn  librte-jobstats1   
ii  librte-kni18.1118.11-4~bpo9+1
pn  librte-kni2
pn  librte-kvargs1 
ii  librte-kvargs18.11 18.11-4~bpo9+1
ii  librte-lpm18.1118.11-4~bpo9+1
pn  librte-lpm2
ii  librte-mbuf18.11   18.11-4~bpo9+1
pn  librte-mbuf2   
ii  librte-member18.11 18.11-4~bpo9+1
ii  librte-mempool-dpaa18.11   18.11-4~bpo9+1
ii  librte-mempool18.1118.11-4~bpo9+1
pn  librte-mempool2
pn  librte-meter1  
ii  librte-meter18.11  18.11-4~bpo9+1
ii  librte-metrics18.1118.11-4~bpo9+1
pn  librte-net1
ii  librte-net18.1118.11-4~bpo9+1
ii  librte-pci18.1118.11-4~bpo9+1
pn  librte-pdump1  
ii  librte-pdump18.11  18.11-4~bpo9+1
ii  librte-pipeline18.11   18.11-4~bpo9+1
pn  librte-pipeline3   
ii  librte-pmd-bnxt18.11   18.11-4~bpo9+1
pn  librte-pmd-bond1   
ii  librte-pmd-bond18.11   18.11-4~bpo9+1
ii  librte-pmd-dpaa18.11   18.11-4~bpo9+1
ii  librte-pmd-i40e18.11   18.11-4~bpo9+1
ii  librte-pmd-ixgbe18.11  18.11-4~bpo9+1
pn  librte-pmd-null1   
ii  librte-pmd-ring18.11   18.11-4~bpo9+1
pn  librte-pmd-ring2   
ii  librte-pmd-softnic18.1118.11-4~bpo9+1
pn  librte-pmd-xenvirt1
ii  librte-port18.11   18.11-4~bpo9+1
pn  librte-port3   
pn  librte-power1  
ii  librte-power18.11  18.11-4~bpo9+1
pn  librte-reorder1
ii  librte-reorder18.1118.11-4~bpo9+1
pn  librte-ring1   
ii  librte-ring18.11   18.11-4~bpo9+1
pn  librte-sched1  
ii  librte-sched18.11  18.11-4~bpo9+1
ii  librte-security18.11   18.11-4~bpo9+1
ii  librte-table18.11  18.11-4~bpo9+1
pn  librte-table2  
ii  librte-telemetry18.11  18.11-4~bpo9+1
pn  librte-timer1  
ii  librte-timer18.11  18.11-4~bpo9+1
pn  librte-vhost3  
ii  libxenstore3.0 4.8.5+shim4.10.2+xsa282-1+deb9u11
ii  zlib1g 1:1.2.8.dfsg-5

dpdk-dev recommends no packages.

dpdk-dev suggests no packages.

Bug#921042: dpdk-dev: dpdk 18.11-4 and dpdk-dev conflict

[Nicolas S. Dade]

Package: dpdk-dev
Version: 18.11-4~bpo9+1
Severity: important

Dear Maintainer,

Installing the dpdk-dev-18.11-4~bpo9+1 is not possible. dpkg refuses,
claiming dpdk-dev breaks dpdk 18.11-4. For example:


# dpkg --install dpdk-dev_18.11-4~bpo9+1_amd64.deb 
Selecting previously unselected package dpdk-dev. 
dpkg: regarding dpdk-dev_18.11-4~bpo9+1_amd64.deb containing dpdk-dev: 
dpdk-dev breaks dpdk (<< 18.11-4) 
 dpdk (version 18.11-4~bpo9+1) is present and installed. 

dpkg: error processing archive dpdk-dev_18.11-4~bpo9+1_amd64.deb (--install): 
installing dpdk-dev would break dpdk, and 
deconfiguration is not permitted (--auto-deconfigure might help) 
Errors were encountered while processing: 
dpdk-dev_18.11-4~bpo9+1_amd64.deb


The Replaces lines in the debian/control file for the dpdk and dpdk-dev
sections look strange to me. Why would dpdk replace dpdk-dev?

However I am not able to work around this except by commenting out
the Replaces and Breaks lines entirely.




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

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

Versions of packages dpdk-dev depends on:
ii  libbsd00.8.3-1
ii  libc6  2.24-11+deb9u3
ii  libdpdk-dev18.11-4~bpo9+1
ii  libelf10.168-1
ii  libgcc11:6.3.0-18+deb9u1
ii  libjansson42.9-1
ii  libnuma1   2.0.11-2.1
ii  librte-acl18.1118.11-4~bpo9+1
pn  librte-acl2
ii  librte-bbdev18.11  18.11-4~bpo9+1
ii  librte-bpf18.1118.11-4~bpo9+1
ii  librte-bus-dpaa18.11   18.11-4~bpo9+1
ii  librte-bus-pci18.1118.11-4~bpo9+1
ii  librte-bus-vdev18.11   18.11-4~bpo9+1
ii  librte-cfgfile18.1118.11-4~bpo9+1
pn  librte-cfgfile2
ii  librte-cmdline18.1118.11-4~bpo9+1
pn  librte-cmdline2
ii  librte-common-dpaax18.11   18.11-4~bpo9+1
ii  librte-compressdev18.1118.11-4~bpo9+1
ii  librte-cryptodev18.11  18.11-4~bpo9+1
pn  librte-cryptodev2  
pn  librte-distributor1
ii  librte-distributor18.1118.11-4~bpo9+1
ii  librte-eal18.1118.11-4~bpo9+1
pn  librte-eal3
ii  librte-efd18.1118.11-4~bpo9+1
ii  librte-ethdev18.11 18.11-4~bpo9+1
pn  librte-ethdev5 
ii  librte-eventdev18.11   18.11-4~bpo9+1
ii  librte-flow-classify18.11  18.11-4~bpo9+1
ii  librte-gro18.1118.11-4~bpo9+1
ii  librte-gso18.1118.11-4~bpo9+1
ii  librte-hash18.11   18.11-4~bpo9+1
pn  librte-hash2   
pn  librte-ip-frag1
ii  librte-ip-frag18.1118.11-4~bpo9+1
pn  librte-jobstats1   
ii  librte-kni18.1118.11-4~bpo9+1
pn  librte-kni2
pn  librte-kvargs1 
ii  librte-kvargs18.11 18.11-4~bpo9+1
ii  librte-lpm18.1118.11-4~bpo9+1
pn  librte-lpm2
ii  librte-mbuf18.11   18.11-4~bpo9+1
pn  librte-mbuf2   
ii  librte-member18.11 18.11-4~bpo9+1
ii  librte-mempool-dpaa18.11   18.11-4~bpo9+1
ii  librte-mempool18.1118.11-4~bpo9+1
pn  librte-mempool2
pn  librte-meter1  
ii  librte-meter18.11  18.11-4~bpo9+1
ii  librte-metrics18.1118.11-4~bpo9+1
pn  librte-net1
ii  librte-net18.1118.11-4~bpo9+1
ii  librte-pci18.1118.11-4~bpo9+1
pn  librte-pdump1  
ii  librte-pdump18.11  18.11-4~bpo9+1
ii  librte-pipeline18.11   18.11-4~bpo9+1
pn  librte-pipeline3   
ii  librte-pmd-bnxt18.11   18.11-4~bpo9+1
pn  librte-pmd-bond1   
ii  librte-pmd-bond18.11   18.11-4~bpo9+1
ii  librte-pmd-dpaa18.11   18.11-4~bpo9+1
ii  librte-pmd-i40e18.11   18.11-4~bpo9+1
ii  librte-pmd-ixgbe18.11  18.11-4~bpo9+1
pn  librte-pmd-null1   
ii  librte-pmd-ring18.11   18.11-4~bpo9+1
pn  librte-pmd-ring2   
ii  librte-pmd-softnic18.1118.11-4~bpo9+1
pn  librte-pmd-xenvirt1
ii  librte-port18.11   18.11-4~bpo9+1
pn  librte-port3   
pn  librte-power1  
ii  librte-power18.11  18.11-4~bpo9+1
pn  librte-reorder1
ii  librte-reorder18.1118.11-4~bpo9+1
pn  librte-ring1   
ii  librte-ring18.11   18.11-4~bpo9+1
pn  librte-sched1  
ii  librte-sched18.11  18.11-4~bpo9+1
ii  librte-security18.11   18.11-4~bpo9+1
ii  librte-table18.11  18.11-4~bpo9+1
pn  librte-table2  
ii  librte-telemetry18.11  18.11-4~bpo9+1
pn  librte-timer1  
ii  librte-timer18.11  18.11-4~bpo9+1
pn  librte-vhost3  
ii  libx

Bug#875858: pkgsel: Offer to install/manage unattended-upgrades

[Holger Wansing]

Control: notfound -1 0.57


Raphael Hertzog  wrote:
> Hi,
> 
> On Wed, 27 Jun 2018, Justin B Rye wrote:
> > _Description: Updates management on this system:
> >  Applying updates on a frequent basis is an important part of keeping the
> >  system secure.
> >  .
> >  By default, security updates are not automatically installed, as security
> >  advisories should be reviewed before manual installation of the updates
> >  using standard package management tools.
> >  .
> >  Alternatively the unattended-upgrades package can be installed, which will
> >  install security updates automatically. Note however that automatic
> >  installation of updates may occasionally cause unexpected downtime of
> >  services provided by this machine in the rare cases where the update is
> >  not fully backward-compatible, or where the security advisory requires the
> >  administrator to perform some other manual operation.
> 
> Thanks for the review. I updated the string in git. I will not upload the
> package right away, maybe later once translators had a chance to catchup
> (or maybe someone else will decide to upload before me).

This has been committed in
https://salsa.debian.org/installer-team/pkgsel/commit/2b9b594855a409fa6d03f259ccca4b1a1bd4727b
however this bug was not mentioned in the changelog, and therefore not closed.

Tagging this bug as fixed in version 0.57


Holger



-- 
Holger Wansing 
PGP-Finterprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#920377: dpkg > 1.19.3 breaks reprepro

[Raphael Hertzog]

Hi,

On Thu, 24 Jan 2019, Alf Gaida wrote:
> Commit 
> https://salsa.debian.org/dpkg-team/dpkg/commit/4a4619831de8b8972f86b489660dc98f187cfa34.patch
>  breaks reprepro.

For reference, that commit says this:
| dpkg-genchanges: Only reference binary packages being uploaded
| 
| The .changes file describes an upload, and its Binary and Description
| fields should contain (as documented) only references to the packages
| being uploaded.
| 
| In case of a source-only upload, the Binary and Description fields
| should be empty.
|
| Closes: #818618

And the "--ignore=missingfield" option is not sufficient to ignore the
error (the "Binary" field is not among the fields that are ignorable).

$ reprepro --ignore=missingfield processincoming kali 
rfcat_170508-0kali3_source.changes
In 'rfcat_170508-0kali3_source.changes': Missing 'Binary' field!
There have been errors!

This is rather annoying as we can't use the latest dpkg to upload packages
to any reprepro-based repository.

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#921041: shellia: FTBFS (failing tests)

[Santiago Vila]

Package: src:shellia
Version: 5.2
Severity: serious
Tags: ftbfs

Dear maintainer:

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


[...]
 debian/rules build-indep
dh build-indep
   dh_update_autotools_config -i
   dh_auto_configure -i
   dh_auto_build -i
make -j1
make[1]: Entering directory '/<>'
rm -f shellia-tested-stamp
./run_tests && touch shellia-tested-stamp
ERROR "./test.backslash" -s "bash"
OK "./test.backslash" -s "dash"
OK "./test.backslash" -s "busybox sh"
OK "./test.backslash" -s "mksh"
OK "./test.backslash" -s "posh"
ERROR "./test.buffer" -s "bash"
OK "./test.buffer" -s "dash"
OK "./test.buffer" -s "busybox sh"
OK "./test.buffer" -s "mksh"
OK "./test.buffer" -s "posh"
ERROR "./test.debug" -s "bash"
OK "./test.debug" -s "dash"
OK "./test.debug" -s "busybox sh"
OK "./test.debug" -s "mksh"
OK "./test.debug" -s "posh"
OK "./test.debug_iptables" -s "bash"
OK "./test.debug_iptables" -s "dash"
OK "./test.debug_iptables" -s "busybox sh"
OK "./test.debug_iptables" -s "mksh"
OK "./test.debug_iptables" -s "posh"
ERROR "./test.func" -s "bash"
OK "./test.func" -s "dash"
OK "./test.func" -s "busybox sh"
OK "./test.func" -s "mksh"
OK "./test.func" -s "posh"
ERROR "./test.hello_world" -s "bash"
OK "./test.hello_world" -s "dash"
OK "./test.hello_world" -s "busybox sh"
OK "./test.hello_world" -s "mksh"
OK "./test.hello_world" -s "posh"
ERROR "./test.hello_world_debug" -s "bash"
OK "./test.hello_world_debug" -s "dash"
OK "./test.hello_world_debug" -s "busybox sh"
OK "./test.hello_world_debug" -s "mksh"
OK "./test.hello_world_debug" -s "posh"
ERROR "./test.hello_world_error" -s "bash"
OK "./test.hello_world_error" -s "dash"
OK "./test.hello_world_error" -s "busybox sh"
OK "./test.hello_world_error" -s "mksh"
OK "./test.hello_world_error" -s "posh"
ERROR "./test.hello_world_fun" -s "bash"
OK "./test.hello_world_fun" -s "dash"
OK "./test.hello_world_fun" -s "busybox sh"
OK "./test.hello_world_fun" -s "mksh"
OK "./test.hello_world_fun" -s "posh"
ERROR "./test.hello_world_log" -s "bash"
OK "./test.hello_world_log" -s "dash"
OK "./test.hello_world_log" -s "busybox sh"
OK "./test.hello_world_log" -s "mksh"
OK "./test.hello_world_log" -s "posh"
OK "./test.hello_world_trace" -s "bash"
OK "./test.hello_world_trace" -s "dash"
OK "./test.hello_world_trace" -s "busybox sh"
OK "./test.hello_world_trace" -s "mksh"
OK "./test.hello_world_trace" -s "posh"
ERROR "./test.ia-C-error" -s "bash"
OK "./test.ia-C-error" -s "dash"
OK "./test.ia-C-error" -s "busybox sh"
OK "./test.ia-C-error" -s "mksh"
OK "./test.ia-C-error" -s "posh"
ERROR "./test.ia-C-expr" -s "bash"
OK "./test.ia-C-expr" -s "dash"
OK "./test.ia-C-expr" -s "busybox sh"
OK "./test.ia-C-expr" -s "mksh"
OK "./test.ia-C-expr" -s "posh"
ERROR "./test.ia-c-C" -s "bash"
OK "./test.ia-c-C" -s "dash"
OK "./test.ia-c-C" -s "busybox sh"
OK "./test.ia-c-C" -s "mksh"
OK "./test.ia-c-C" -s "posh"
ERROR "./test.ia-c-error" -s "bash"
OK "./test.ia-c-error" -s "dash"
OK "./test.ia-c-error" -s "busybox sh"
OK "./test.ia-c-error" -s "mksh"
OK "./test.ia-c-error" -s "posh"
ERROR "./test.ia-c-expr" -s "bash"
OK "./test.ia-c-expr" -s "dash"
OK "./test.ia-c-expr" -s "busybox sh"
OK "./test.ia-c-expr" -s "mksh"
OK "./test.ia-c-expr" -s "posh"
ERROR "./test.ia-c-nocheck" -s "bash"
OK "./test.ia-c-nocheck" -s "dash"
OK "./test.ia-c-nocheck" -s "busybox sh"
OK "./test.ia-c-nocheck" -s "mksh"
OK "./test.ia-c-nocheck" -s "posh"
ERROR "./test.ia-c-s-m" -s "bash"
OK "./test.ia-c-s-m" -s "dash"
OK "./test.ia-c-s-m" -s "busybox sh"
OK "./test.ia-c-s-m" -s "mksh"
OK "./test.ia-c-s-m" -s "posh"
OK "./test.ia-empty" -s "bash"
OK "./test.ia-empty" -s "dash"
OK "./test.ia-empty" -s "busybox sh"
OK "./test.ia-empty" -s "mksh"
OK "./test.ia-empty" -s "posh"
ERROR "./test.ia-expr" -s "bash"
OK "./test.ia-expr" -s "dash"
OK "./test.ia-expr" -s "busybox sh"
OK "./test.ia-expr" -s "mksh"
OK "./test.ia-expr" -s "posh"
ERROR "./test.ia-s" -s "bash"
OK "./test.ia-s" -s "dash"
OK "./test.ia-s" -s "busybox sh"
OK "./test.ia-s" -s "mksh"
OK "./test.ia-s" -s "posh"
OK "./test.ia_mktemp" -s "bash"
OK "./test.ia_mktemp" -s "dash"
OK "./test.ia_mktemp" -s "busybox sh"
ERROR "./test.multiply" -s "bash"
OK "./test.multiply" -s "dash"
OK "./test.multiply" -s "busybox sh"
OK "./test.multiply" -s "mksh"
OK "./test.multiply" -s "posh"
OK "./test.only_debug" -s "bash"
OK "./test.only_debug" -s "dash"
OK "./test.only_debug" -s "busybox sh"
OK "./test.only_debug" -s "mksh"
OK "./test.only_debug" -s "posh"
ERROR "./test.only_interactive" -s "bash"
OK "./test.only_interactive" -s "dash"
OK "./test.only_interactive" -s "busybox sh"
OK "./test.only_interactive" -s "mksh"
OK "./test.only_log" -s "bash"
OK "./test.only_log" -s "dash"
OK "./test.only_log" -s "busybox sh"
OK "./test.only_log" -s "mksh"
OK "./test.only_log" -s "posh"
ERROR "./test.prefix" -s "bash"
ERROR "./test.redo" -s "bash"
OK "./test.redo" -s "dash"
OK "./test.redo

Bug#921040: CVE-2019-5010

[Moritz Muehlenhoff]

Package: python2.7
Version: 2.7.15-5
Severity: important
Tags: security

This was assigned CVE-2019-5010:
https://bugs.python.org/issue35746
https://github.com/python/cpython/pull/11569

Patch for 2.7:
https://github.com/python/cpython/commit/06b15424b0dcacb1c551b2a36e739fffa8d0c595

Cheers,
Moritz
 

Bug#921039: CVE-2018-14647

[Moritz Muehlenhoff]

Package: python2.7
Version: 2.7.15-5
Severity: grave
Tags: security

CVE-2018-14647 as fixed in DSA-4306-1 needs to be fixed in testing as well:

https://bugs.python.org/issue34623
https://github.com/python/cpython/commit/18b20bad75b4ff0486940fba4ec680e96e70f3a2

Cheers,
Moritz
 
 

Bug#776424: [kgb-maintainers] Bug#776424: can be crashed by some network traffic

[Moritz Mühlenhoff]

On Wed, Apr 05, 2017 at 01:38:08PM -0400, Joey Hess wrote:
> Antoine Beaupre wrote:
> > Joey, did you manage to reproduce this issue without an external
> > attacker? Can you still reproduce in 1.34?
> 
> Just saw the issue again with 1..34-2

What's the status, did this re-occur with current versions, like
the one in testing?

Cheers,
Moritz

Bug#902722: CVE-2018-1000532

[Moritz Mühlenhoff]

severity 902722 grave
thanks

On Fri, Jun 29, 2018 at 11:05:17PM +0200, Moritz Muehlenhoff wrote:
> Package: beep
> Severity: important
> Tags: security
> 
> Please see http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-1000532

There's now a new release/fork:
https://github.com/johnath/beep/issues/11#issuecomment-454056858

Also, can we drop the setuid bit for buster, either in total or at least
make it not the default, but only opt-in?

Cheers,
Moritz

Bug#842504: CVE-2016-7954: code execution via gem name collission in bundler

[Moritz Mühlenhoff]

On Sat, Oct 29, 2016 at 09:27:25PM +0200, Salvatore Bonaccorso wrote:
> Package: bundler
> Version: 1.7.4-1
> Severity: important
> Tags: security upstream
> 
> Hi,
> 
> the following vulnerability was published for bundler.
> 
> CVE-2016-7954[0]:
> code execution via gem name collission in bundler
> 
> Please correct me if I'm wrong. As far I understand, this issue cannot
> be fixed within the 1.x series due to lockfile format. This bug is to
> continue tracking the CVE in the Debian BTS.

JFTR; Bundler 2 was relased in early January.

Cheers,
Moritz

Bug#636689: affects on binary packages are not displayed for the source package

[Daniel Kahn Gillmor]

On Sun 2017-01-29 22:05:36 +, James Clarke wrote:
> I have attached a patch which hopefully fixes this. I have only tested
> it by extracting the new function to a separate perl script; it may or
> may not function incorrectly as-is, so beware!

It's really great to see a patch here.

This gap in the BTS bothers me, and it would be great if someone with
more knowledge and skill than i have in it could review this patch and
see whether it works.  (and if it works, please apply it!)

thanks for maintaining the BTS,

--dkg


signature.asc
Description: PGP signature

Bug#921038: "btrfs filesystem resize", add "min" to minimize a Btrfs filesystem

[21naown]

Package: btrfs-progs
Version: 4.7.3-1
Severity: wishlist
Tags: upstream


"min" could be used to minimize a Btrfs filesystem as "max" is used to 
maximize a Btrfs filesystem, which would avoid to use "btrfs 
inspect-internal min-dev-size" and at least one other software to 
extract the number (for example "cut").



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

Kernel: Linux 4.9.0-8-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
LANGUAGE= (charmap=UTF-8)

Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages btrfs-progs depends on:
ii e2fslibs 1.43.4-2
ii libblkid1 2.29.2-1+deb9u1
ii libc6 2.24-11+deb9u3
ii libcomerr2 1.43.4-2
ii liblzo2-2 2.08-1.2+b2
ii libuuid1 2.29.2-1+deb9u1
ii zlib1g 1:1.2.8.dfsg-5

btrfs-progs recommends no packages.

btrfs-progs suggests no packages.

-- no debconf information

Bug#767250: virtualbox: Guests still crash with virtualbox 5.2.24-dfsg-4~bpo9+1

[voxderloop]

Package: virtualbox
Version: 5.2.24-dfsg-4~bpo9+1
Followup-For: Bug #767250

Dear Maintainer,

I have tried to enable 3D acceleration on different guests with 
different
OSs and experienced crashes. I have tried Windows 7, Windows XP and 
Debian Jessie
guests. It reproduces with libdrm-nouveau2 2.4.74-1 and 2.4.95-1~bpo9+1. 
The only
difference from crashes reported by Tom Maneiro is that the only thing 
that

crashes is the guest machine.

One of the ways to reproduce:

1) Run guest with Debian Jessie.
2) Install virtualbox-guest-dkms and mesa-utils on guest.
3) Reboot guest with 3D acceleration enabled.
4) Ensure that the virtualbox guest kernel modules are loaded on guest.
5) Run glxgears or several instances of glxgears on guest.

Sometimes the guest will crash after several minutes of running 
glxgears, sometimes
it will crash after starting second instance of glxgears. Also, the 
gears inside
glxgears' window disappears for several frames from time to time, and 
sometimes

they renders over other windows inside guest.

Kernel log messages after starting the VM:
.
[11655.378341] nouveau :04:00.0: fifo: DMA_PUSHER - ch 8 
[VirtualBox[13900]] get 0020046e6c put 002004789c ib_get 01d6 ib_put 
01d9 state 80007a04 (err: INVALID_CMD) push 00406040
[11655.378356] nouveau :04:00.0: gr: DATA_ERROR 000c 
[INVALID_BITFIELD]
[11655.378362] nouveau :04:00.0: gr: 0010 [] ch 8 [001f2cb000 
VirtualBox[13900]] subc 3 class 8297 mthd 020c data 00047338
[11709.928968] nouveau :04:00.0: fifo: DMA_PUSHER - ch 8 
[VirtualBox[13900]] get 002012bea8 put 002012ccf4 ib_get 0176 ib_put 
0177 state 80007a04 (err: INVALID_CMD) push 00406040
[11728.163004] nouveau :04:00.0: fifo: DMA_PUSHER - ch 8 
[VirtualBox[13900]] get 002004ee5c put 002004fc38 ib_get 03f1 ib_put 
03f2 state 80006db8 (err: INVALID_CMD) push 00406040
[11728.163022] nouveau :04:00.0: gr: DATA_ERROR 0005 
[INVALID_ENUM]
[11728.163027] nouveau :04:00.0: gr: 0010 [] ch 8 [001f2cb000 
VirtualBox[13900]] subc 3 class 8297 mthd 0dac data 0001
[11728.163039] nouveau :04:00.0: gr: DATA_ERROR 0005 
[INVALID_ENUM]
[11728.163044] nouveau :04:00.0: gr: 0010 [] ch 8 [001f2cb000 
VirtualBox[13900]] subc 3 class 8297 mthd 0db0 data 000c7228
[11728.163062] nouveau :04:00.0: gr: DATA_ERROR 0005 
[INVALID_ENUM]
[11728.163067] nouveau :04:00.0: gr: 0010 [] ch 8 [001f2cb000 
VirtualBox[13900]] subc 3 class 8297 mthd 0db4 data 0106
[11744.540838] nouveau :04:00.0: VirtualBox[13900]: multiple 
instances of buffer 6 on validation list

[11744.540847] nouveau :04:00.0: VirtualBox[13900]: validate_init
[11744.540851] nouveau :04:00.0: VirtualBox[13900]: validate: -22
[11763.72] nouveau :04:00.0: fifo: DMA_PUSHER - ch 8 
[VirtualBox[13900]] get 0020030d30 put 0020031520 ib_get 00ab ib_put 
00ae state 80006f05 (err: INVALID_CMD) push 00406040
[11794.189191] nouveau :04:00.0: fifo: DMA_PUSHER - ch 8 
[VirtualBox[13900]] get 0020102fec put 0020103f94 ib_get 0100 ib_put 
0103 state 80006c08 (err: INVALID_CMD) push 00406040
[11794.189207] nouveau :04:00.0: gr: DATA_ERROR 0005 
[INVALID_ENUM]
[11794.189213] nouveau :04:00.0: gr: 0010 [] ch 8 [001f2cb000 
VirtualBox[13900]] subc 3 class 8297 mthd 1534 data 0040
[11813.555346] nouveau :04:00.0: VirtualBox[13900]: multiple 
instances of buffer 7 on validation list

[11813.555355] nouveau :04:00.0: VirtualBox[13900]: validate_init
[11813.555358] nouveau :04:00.0: VirtualBox[13900]: validate: -22
[11859.419713] ShCrOpenGL[13946]: segfault at 8 ip 7f0ed6df532f sp 
7f0e97980a00 error 4 in libdrm_nouveau.so.2.0.0[7f0ed6df1000+7000]
[11859.419734] nouveau :04:00.0: VirtualBox[13900]: multiple 
instances of buffer 10 on validation list

[11859.419744] nouveau :04:00.0: VirtualBox[13900]: validate_init
[11859.419748] nouveau :04:00.0: VirtualBox[13900]: validate: -22
.

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

Kernel: Linux 4.9.0-8-amd64 (SMP w/2 CPU cores)
Locale: LANG=uk_UA.UTF-8, LC_CTYPE=uk_UA.UTF-8 (charmap=UTF-8), 
LANGUAGE=uk_UA.UTF-8 (charmap=UTF-8)

Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages virtualbox depends on:
ii  adduser   3.115
ii  init-system-helpers   1.48
ii  iproute2  4.9.0-1+deb9u1
ii  libc6 2.24-11+deb9u3
ii  libcurl3-gnutls   7.52.1-5+deb9u8
ii  libdevmapper1.02.12:1.02.137-2
ii  libgcc1   1:6.3.0-18+deb9u1
ii  libgsoap102.8.35-4+deb9u1
ii  libopus0   

Bug#920970: dgit: should ensure .orig is not in the .changes when the .orig is already in DEFERRED

[Sean Whitton]

Hello,

On Thu 31 Jan 2019 at 11:40AM +00, Ian Jackson wrote:

> Sean Whitton writes ("Bug#920970: dgit: should ensure .orig is not in the 
> .changes when the .orig is already in DEFERRED"):
>> Hmm.  After this, with both the -1 and -2 uploads in DEFERRED, I tried
>> to `dcut cancel` the -1 upload so that I could be sure an ftp-master
>> would not try to review -1 in the interval before -2's DEFERRED timer
>> ran out.
>>
>> This caused queued to delete the .orig.tar, such that, presumably, the
>> -2 would be REJECTed immediately upon its DEFERRED timer elapsing.
>> Nice.  I have had to `dcut cancel` the -2 upload too and
>
> What a mess.
>
> Maybe dgit should automatically do the dcut for you.  But maybe that
> would mean waiting for the queue daemon to act on the dcut ?
>
> None of this seems particularly straightforward, and the problems stem
> from the strange and organically grown ad-hoc "API" offered by the
> queue daemon.

Right.  I don't think it is useful for dgit to try to dcut for you.
It's too complicated, and we don't know the order in which queued will
process things.

Instead it can say "looks like this package is NEW and in deferred;
it is highly recommended that you `dcut cancel` that upload, wait for it
to be processed, then dgit push."

>> ask my sponsee for a -3 changelog entry.
>
> Did you not feel able to add one yourself for something like this ?  I
> would have done.

I would have done had I had push access to his git repo.  Asking him for
a new changelog entry seemed like less effort for him than telling him
to pull from some random git server of mine (since dgit-repos would not
let him fetch my commit until the package is through NEW..).

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#916912: [pre-approval] stretch-pu: package freerdp/1.1.0~git20140921.1.440916e+dfsg1-13+deb9u3

[Mike Gabriel]

HI Adam,

On  Do 31 Jan 2019 21:28:43 CET, Adam D. Barratt wrote:


On Fri, 2019-01-11 at 15:26 +0100, Mike Gabriel wrote:

Please review the attached .debdiff (for stretch) and give your go
for uploading to stretch.


   + Add 0010_add-support-for-credssp-v3-and-rdpproto-v6.patch. Add  
CredSSP v3

  and RDP proto v6 support. This allows users to connect to recently
  (since March 2018) update Microsoft RDP servers again.
  Thanks to Bernhard Miklautz and Martin Fleisz for helping out ith
  backporting this patch. Much appreciated!

s/recently.*update/&d/ s/helping out ith/helping out with/


Thanks! Will fix that.


  * debian/control:
+ B-D on libssh1.0-dev (instead of libssh-dev).


It's libssh1.0-dev for stretch and nothing needs to be changed.


This change doesn't appear to have actually been included. (Which is
just as well, as there is no such package in Debian.)


Yeah, I guess I mixed those up in the changelog. The  
debian/jessie/updates branch needs a switch-back [1] from  
libssl1.0-dev to libssl-dev whereas the debian/stretch/updates branch  
does not need a change here.


Glad that you spotted this.


After that, I will upload the same version (slighty backported to 
jessie) to jessie-security.

I will also publish a blog post that will appear on Planet Debian
that links to built binaries that users may be table to test.


Has there been much take-up / feedback there?


Over the last 8 days my webserver has registered 18 downloads of  
freerdp-x11 (either for jessie or for stretch). Without any positive  
feedback given (which I requested explicitly). Unfortunately, log  
files on that machine use the default logrotate rules for Apache2.


I have been using the patched version from my notebook (I downgraded  
from freerdp2 to freerdp1.1). And in fact, I forgot that I actually  
downgraded it. It simply worked with all kinds of recent RDP servers  
(Win 2016 server, Win 2012 server mainly).


The patch author Bernhard Miklautz tested against Win7, Win10 and  
WinXP. I just did a quick test with the stretch version against an  
xRDP server.


Mike

[1]  
https://salsa.debian.org/debian-remote-team/freerdp-1.1-legacy/commit/c598db8583e5a0cc8c38ac55f680cd501b1fe892

--

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



pgpbyQgS6289T.pgp
Description: Digitale PGP-Signatur

Bug#920988: please consider dropping SPDY support

[Tomasz Buchert]

On 31/01/19 12:23, Andrej Shadura wrote:
> Package: nghttp2
> Severity: wishlist
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Dear Maintainer,
>
> With HTTP/2 having been finalised, SPDY has been deprecated three years
> ago, and none of the modern browsers support it anymore. On the other
> hand, the spdylay package, which provides SPDY support in nghttp2, has
> been orphaned both upstream and in Debian.
>
> Please consider disabling SPDY support and removing the build dependency
> om libspdylay-dev.
>
> Thanks.
>
> --
> Cheers,
> Andrej

Hey Andrej,
do you think it should be resolved before buster?

Tomasz


signature.asc
Description: PGP signature

Bug#913726: nheko: upstream project looks dead

[redsky17]

On Wed, 14 Nov 2018 11:08:13 -0500 Hubert Chathi  wrote:
> On Wed, 14 Nov 2018 12:35:34 +0100, Jonas Smedegaard  said:
>
> > Package: nheko Version: 0.6.1-1 Severity: important Tags: upstream
>
> > Upstream homepage - a Github page - is marked as "archived by its
> > owner" and its short description starts with "No longer maintained".
>
> Yup.  I'm hoping someone will pick up maintainership (or fork it), but
> if not, we may need to remove it in buster.
>
> --
> 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
>
>

Hey there.  I was alerted to this bug by a user earlier.  I wanted to reach out 
to mention that I have started maintaining a fork of nheko located at:
https://github.com/Nheko-Reborn/nheko

I'm hoping to get a new release out shortly (the current release is still 0.6.2 
from the old repo).  I need to finish up the current set of features for the 
0.6.3 release (want to verify performance and stability for a bit before 
committing to a new version).

Hopefully the Debian package can continue being maintained from the new fork.

Thanks for your time,
Joe

Bug#921037: typo correction

[Howard Johnson]

I accidentally left out the Types: line.   Should be:

--- start of code ---
#NOTE: Most preferred source listed first!

#=== NEW MULTI-LINE FORMAT ===
Types:  deb deb-src
URIs:http://ftp.uk.debian.org/debian/
Suites: stretch
Components: main contrib non-free
--- end of code --


But note that the bug occurs both with that missing line, and without it.

So this follow-up is just so, you the maintainer, don't look at this and jump 
to the conclusion that the missing Types line has anything to do with this bug. 
 It does not.


In fact, this even more simple example with a single comment line followed by 
two blank lines, also demonstrates this bug:

--- start of code ---
#NOTE: Most preferred source listed first!


--- end of code --

Bug#921036: vagrant: doesn't work with virtualbox 6

[Damyan Ivanov]

-=| Damyan Ivanov, 31.01.2019 21:18:45 + |=-
> I tried to update the package…

In case it would be of any use, my attempt is available at 
https://salsa.debian.org/dmn/vagrant

-- Damyan

Bug#921037: apt: Additional empty lines not ignored in multi-line format

[Howard Johnson]

Package: apt
Version: 1.4.9
Severity: normal
Tags: newcomer

In  `man sources.list`,  under the heading: "DEB822-STYLE FORMAT",  it says,

"Individual entries are separated by an empty line; additional empty
lines are ignored".

However, additional empty lines are not being ignored.  Consider this from my
/etc/apt/source.list.d/sources.sources:

--- start of code ---
#NOTE:  Most preferred source listed first!


#=== NEW MULTI-LINE FORMAT ===
URIs:   http://ftp.uk.debian.org/debian/
Suites: stretch
Components: main contrib non-free
--- end of code --


When I run `apt update` it gives this unexpected error message:

E: Malformed stanza 1 in source list
/etc/apt/sources.list.d/sources.sources (type)


If I remove one of the two blank lines the error goes away.

I would expect that two blank lines in succession would act as a single blank
line.

___
Apt v 1.4.9 (amd64)

OS: GNU/Linux Debian 9.6 (x86-64);
Cinnamon desktop: 3.2.7;
Linux Kernel: 4.9.0-8-amd64;
Processor: Intel Core 2 Duo P8800;
Graphics Card: AMD/ATI RV710/M92 Mobility Radeon HD 4530/4570/545v



-- Package-specific info:

-- apt-config dump --

APT "";
APT::Architecture "amd64";
APT::Build-Essential "";
APT::Build-Essential:: "build-essential";
APT::Install-Recommends "true";
APT::Install-Suggests "0";
APT::Sandbox "";
APT::Sandbox::User "_apt";
APT::Authentication "";
APT::Authentication::TrustCDROM "true";
APT::NeverAutoRemove "";
APT::NeverAutoRemove:: "^firmware-linux.*";
APT::NeverAutoRemove:: "^linux-firmware$";
APT::NeverAutoRemove:: "^linux-image-4\.9\.0-7-amd64$";
APT::NeverAutoRemove:: "^linux-image-4\.9\.0-8-amd64$";
APT::NeverAutoRemove:: "^linux-headers-4\.9\.0-7-amd64$";
APT::NeverAutoRemove:: "^linux-headers-4\.9\.0-8-amd64$";
APT::NeverAutoRemove:: "^linux-image-extra-4\.9\.0-7-amd64$";
APT::NeverAutoRemove:: "^linux-image-extra-4\.9\.0-8-amd64$";
APT::NeverAutoRemove:: "^linux-signed-image-4\.9\.0-7-amd64$";
APT::NeverAutoRemove:: "^linux-signed-image-4\.9\.0-8-amd64$";
APT::NeverAutoRemove:: "^kfreebsd-image-4\.9\.0-7-amd64$";
APT::NeverAutoRemove:: "^kfreebsd-image-4\.9\.0-8-amd64$";
APT::NeverAutoRemove:: "^kfreebsd-headers-4\.9\.0-7-amd64$";
APT::NeverAutoRemove:: "^kfreebsd-headers-4\.9\.0-8-amd64$";
APT::NeverAutoRemove:: "^gnumach-image-4\.9\.0-7-amd64$";
APT::NeverAutoRemove:: "^gnumach-image-4\.9\.0-8-amd64$";
APT::NeverAutoRemove:: "^.*-modules-4\.9\.0-7-amd64$";
APT::NeverAutoRemove:: "^.*-modules-4\.9\.0-8-amd64$";
APT::NeverAutoRemove:: "^.*-kernel-4\.9\.0-7-amd64$";
APT::NeverAutoRemove:: "^.*-kernel-4\.9\.0-8-amd64$";
APT::NeverAutoRemove:: "^linux-backports-modules-.*-4\.9\.0-7-amd64$";
APT::NeverAutoRemove:: "^linux-backports-modules-.*-4\.9\.0-8-amd64$";
APT::NeverAutoRemove:: "^linux-tools-4\.9\.0-7-amd64$";
APT::NeverAutoRemove:: "^linux-tools-4\.9\.0-8-amd64$";
APT::VersionedKernelPackages "";
APT::VersionedKernelPackages:: "linux-image";
APT::VersionedKernelPackages:: "linux-headers";
APT::VersionedKernelPackages:: "linux-image-extra";
APT::VersionedKernelPackages:: "linux-signed-image";
APT::VersionedKernelPackages:: "kfreebsd-image";
APT::VersionedKernelPackages:: "kfreebsd-headers";
APT::VersionedKernelPackages:: "gnumach-image";
APT::VersionedKernelPackages:: ".*-modules";
APT::VersionedKernelPackages:: ".*-kernel";
APT::VersionedKernelPackages:: "linux-backports-modules-.*";
APT::VersionedKernelPackages:: "linux-tools";
APT::Never-MarkAuto-Sections "";
APT::Never-MarkAuto-Sections:: "metapackages";
APT::Never-MarkAuto-Sections:: "contrib/metapackages";
APT::Never-MarkAuto-Sections:: "non-free/metapackages";
APT::Never-MarkAuto-Sections:: "restricted/metapackages";
APT::Never-MarkAuto-Sections:: "universe/metapackages";
APT::Never-MarkAuto-Sections:: "multiverse/metapackages";
APT::Move-Autobit-Sections "";
APT::Move-Autobit-Sections:: "oldlibs";
APT::Move-Autobit-Sections:: "contrib/oldlibs";
APT::Move-Autobit-Sections:: "non-free/oldlibs";
APT::Move-Autobit-Sections:: "restricted/oldlibs";
APT::Move-Autobit-Sections:: "universe/oldlibs";
APT::Move-Autobit-Sections:: "multiverse/oldlibs";
APT::Update "";
APT::Update::Post-Invoke-Success "";
APT::Update::Post-Invoke-Success:: "/usr/bin/test -e 
/usr/share/dbus-1/system-services/org.freedesktop.PackageKit.service && 
/usr/bin/test -S /var/run/dbus/system_bus_socket && /usr/bin/gdbus call 
--system --dest org.freedesktop.PackageKit --object-path 
/org/freedesktop/PackageKit --timeout 4 --method 
org.freedesktop.PackageKit.StateHasChanged cache-update > /dev/null; /bin/echo 
> /dev/null";
APT::Update::Post-Invoke-Success:: "if /usr/bin/test -w /var/cache/app-info -a 
-e /usr/bin/appstreamcli; then appstreamcli refresh-cache > /dev/null; fi";
APT::Architectures "";
APT::Architectures:: "amd64";
APT::Architectures:: "i386";
APT::Compressor "";
APT::Com

Bug#921034: Depends on MaxMind GeoIP Legacy databases - superseded by GeoIP2

[Thomas Ward]

Hi.

The GeoIP module is a core module in NGINX upstream.  Keeping this in
mind, it's just packaged here as a dynamic module.

For reference purposes, I have forwarded this bug report to nginx
upstream's nginx-devel mailing list [1] for their response.

(Note that this is just me adding information, not adding anything 'new'
to this discussion, as it is ultimately up to the maintainers to include
a third party module or not here in Debian)


Thomas

[1]: http://mailman.nginx.org/pipermail/nginx-devel/2019-January/011852.html

Bug#916587: AppArmor breaks virtio-gpu + virgl

[Hillel Lubman]

How exactly do you see these logs?

I'm trying to start a Linux guest on Debian testing host, using virt-manager 
and user session.
I enabled OpenGL and 3D acceleration and it fails like this:

Error starting domain: internal error: qemu unexpectedly closed the monitor

Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/asyncjob.py", line 75, in cb_wrapper
callback(asyncjob, *args, **kwargs)
  File "/usr/share/virt-manager/virtManager/asyncjob.py", line 111, in tmpcb
callback(*args, **kwargs)
  File "/usr/share/virt-manager/virtManager/libvirtobject.py", line 66, in newfn
ret = fn(self, *args, **kwargs)
  File "/usr/share/virt-manager/virtManager/domain.py", line 1400, in startup
self._backend.create()
  File "/usr/lib/python3/dist-packages/libvirt.py", line 1080, in create
if ret == -1: raise libvirtError ('virDomainCreate() failed', dom=self)
libvirt.libvirtError: internal error: qemu unexpectedly closed the monitor

When OpenGL isn't enabled, it starts fine.  I have libvirglrenderer0 installed. 
I wonder if it's related to the above apparmor issue.

Editing  /etc/apparmor.d/libvirt/TEMPLATE.qemu didn't help in my case either.

Regards,
Hillel Lubman.

Bug#919083: corsix-th: FTBFS: convert-im6.q16: InvalidImageIndex `CorsixTH/CorsixTH.ico' @ error/list.c/CloneImages/281.

[Phil Morrell]

An upstream change appears to have broken frame indexing syntax, as used here
within an icon size loop. The fix is to use the built-in batch mode to convert
setting a variable for the icon size.

convert ico:CorsixTH/CorsixTH.ico[2] corsix-th.png
https://github.com/ImageMagick/ImageMagick6/commit/02023b057fbceb60df963612d42bab2f311de67b


signature.asc
Description: PGP signature

Bug#601054: add comments to /etc/init.d/.depend.* saying what program put them there

[Jesse Smith]

I don't think there is any reason to add comments mentioning the author
in these files. Almost none of the config files under /etc list the
program which created them. Plus these files are hidden so it's unlikely
someone is going to stumble across them by accident. Suggest we close
this report.

- Jesse

Bug#633858: -v not as safe as it sounds

[Jesse Smith]

I think the manual page is correct and the flag is documented as
expected. The -v command only turns on verbose messages, it doesn't do
anything else, as documented in the man page. This bug can probably be
closed as there doesn't seem to be anything here to fix.

- Jesse

Bug#921036: vagrant: doesn't work with virtualbox 6

[Damyan Ivanov]

Package: vagrant
Version: 2.1.5+dfsg-1
Severity: normal
Tags: upstream fixed-upstream

Hi,

The version of vagrant in unstable (2.1.5) doesn't work with virtualbox in 
unstable (6.0.4):

 Vagrant has detected that you have a version of VirtualBox installed
 that is not supported by this version of Vagrant. Please install one of
 the supported versions listed below to use Vagrant:

 4.0, 4.1, 4.2, 4.3, 5.0, 5.1, 5.2

There is version 2.2.3 upstream, which claims to work with virtualbox 6.

I tried to update the package, but after updating the patches the build fails 
with a missing dependency:

  /usr/lib/ruby/2.5.0/rubygems/dependency.rb:310:in `to_specs': Could not find
  'vagrant_cloud' (>= 0) among 51 total gem(s) (Gem::MissingSpecError)

Dropping the requirement makes the build pass, but then results in a runtime 
error:

 /usr/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in `require': 
 cannot load such file -- vagrant_cloud (LoadError)

My (rather non-existent) ruby packaging skills end here, alas :)


-- Damyan

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

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

Versions of packages vagrant depends on:
ii  curl   7.63.0-1
ii  libarchive-tools   3.3.3-3
ii  openssh-client 1:7.9p1-5
ii  rsync  3.1.3-5
ii  ruby   1:2.5.1
ii  ruby-childprocess  0.9.0-1
ii  ruby-erubis2.7.0-3
ii  ruby-i18n  0.7.0-3
ii  ruby-listen3.1.5-1
ii  ruby-log4r 1.1.10-4
ii  ruby-net-scp   1.2.1-5
ii  ruby-net-sftp  1:2.1.2-4
ii  ruby-net-ssh   1:5.1.0-1
ii  ruby-rest-client   2.0.2-3.1

Versions of packages vagrant recommends:
ii  vagrant-libvirt  0.0.45-2

Versions of packages vagrant suggests:
ii  virtualbox  6.0.4-dfsg-3

-- no debconf information

Bug#920179: Buster: klavaro crashes with segmentation fault?

[Felipe Castro]

Hi, maybe the problem arises when you use ./configure --disable-nls ?
And I guess also that the user don't have localization support installed
there.
See that in the file "auxiliar.h" of Klavaro, the header "libintl.h" for
NLS stuff is conditionally included. But when NLS is disabled, the macro
"dngettext" stays with no definition, becoming implicitly declared. So we
should provide a dummy for it, as for the other macros provided there.
I'll try to fix this on next release, 3.04.

Kind regards,
Felipe Castro

Bug#680668: tasksel: Input methods for chinese - (Was: Updating chinese-t-desktop in tasksel for Wheezy.)

[Holger Wansing]

Hi,

John Paul Adrian Glaubitz  wrote:
> Hello!
> 
> > On Jan 12, 2019, at 10:02 AM, Yao Wei (魏銘廷)  wrote:
> > 
> > or we can follow task-chinese-s-desktop and use fcitx instead of ibus in
> > task-chinese-t-desktop:
> > 
> > fcitx,
> > fcitx-chewing,
> > fcitx-table,
> > im-config,
> > fonts-arphic-ukai,
> > fonts-arphic-uming,
> > fonts-noto, # this seems to be unnecessary, but not really sure.
> > fonts-noto-cjk,
> > libreoffice-l10n-zh-tw,
> > libreoffice-help-zh-tw,
> > firefox-esr-l10n-zh-tw | firefox-l10n-zh-tw,
> > poppler-data
> 
> I haven’t yet understood why people are moving to fcitx. I have tried it 
> myself after it was automatically installed on my openSUSE machine to replace 
> iBus and found it completely unusable. I didn’t even manage to get any input 
> languages added.
> 
> I am using iBus for writing Japanese and I consider it the superior and 
> simpler-to-use solution.
> 
> Is there anything that fcitx is supposed to do better than iBus?

I cannot judge on fcitx, but it was stated that GNOME3 has built-in support
for iBus, so we have that in any case.
The question "fcitx or scim" is just sort of a fallback.


Holger


-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#547717: Applying suggested documentation change upstream

[Jesse Smith]

I agree this makes sense. I'll update the upstream manual page to
indicate no .depend.* files are created.

- Jesse

Bug#846645: Project Email

[Tóth Eszter]

I don't know if you receive the transaction email I sent you.

Bug#921034: Depends on MaxMind GeoIP Legacy databases - superseded by GeoIP2

[Nicolas Dandrimont]

Package: libnginx-mod-http-geoip
Version: 1.14.2-2
Severity: important

Dear maintainer,

In its current form, the geoip module for nginx depends on the MaxMind GeoIP
database in the Legacy format, the free version of which (GeoLite Legacy) has
been deprecated since January 2018 and discontinued at the beginning of 2019.

https://support.maxmind.com/geolite-legacy-discontinuation-notice/

Paying customers of MaxMind still get access to the GeoIP Legacy database as far
as I can tell, however people who used the royalty-free option such as the
DebConf Video Team can't do that any longer.

To make sure IP Geolocation functionality stays functional long-term in nginx,
please consider providing a GeoIP2 module such as
https://github.com/leev/ngx_http_geoip2_module.

Thanks for your work on nginx!

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

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

Versions of packages libnginx-mod-http-geoip depends on:
ii  libc6 2.28-5
ii  libgeoip1 1.6.12-1
ii  nginx-common  1.14.2-2

libnginx-mod-http-geoip recommends no packages.

libnginx-mod-http-geoip suggests no packages.

-- no debconf information

Bug#921035: RFS: streamlink/1.0.0+dfsg-1

[Alexis Murzeau]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "streamlink" for a new
upstream version 1.0.0.

 * Package name: streamlink
   Version : 1.0.0+dfsg-1
   Upstream Author : Streamlink Team
 * URL : https://streamlink.github.io/
 * License : BSD-2-clause, Apache-2.0, MIT/Expat, SIL-OFL-1.1
   Section : python

It builds those binary packages:

  livestreamer - transitional package - streamlink
  python3-streamlink - Python module for extracting video streams from
various websites
  python3-streamlink-doc - CLI for extracting video streams from various
websites (documentation)
  streamlink - CLI for extracting video streams from various websites to
a video player

To access further information about this package, please visit the
following URL:
  https://mentors.debian.net/package/streamlink


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

  dget -x
https://mentors.debian.net/debian/pool/main/s/streamlink/streamlink_1.0.0+dfsg-1.dsc

More information about streamlink can be obtained at
https://streamlink.github.io/

Changes since the last upload:
streamlink (1.0.0+dfsg-1) unstable; urgency=medium

  * docs: mark Multi-Arch: foreign
  * Update d/copyright years to 2019
  * Bump standard version to 4.3.0, no change required
  * New upstream version 1.0.0+dfsg
  * Update patch remove_new_version_check
  * Update d/README.source to use gbp pq

 -- Alexis Murzeau   Thu, 31 Jan 2019 20:09:50 +0100


Regards,
-- 
Alexis Murzeau
PGP: B7E6 0EBB 9293 7B06 BDBC  2787 E7BD 1904 F480 937F




signature.asc
Description: OpenPGP digital signature

Bug#921033: ITP: ontospy -- query, inspect and visualize RDF/OWL ontologies

[Jonas Smedegaard]

Package: wnpp
Severity: wishlist
Owner: Jonas Smedegaard 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: ontospy
  Version : 0~20190107
  Upstream Author : Michele Pasin 
* URL : https://lambdamusic.github.io/Ontospy/
* License : Expat
  Programming Lang: Python
  Description : query, inspect and visualize RDF/OWL ontologies

 Ontospy is a lightweight Python library and command line tool
 for inspecting and visualizing vocabularies
 encoded using W3C Semantic Web standards,
 that is, RDF or any of its dialects (RDFS, OWL, SKOS).
 .
 Ontospy can be used to generate HTML documentation
 for an ontology pretty easily.

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAlxTZNIACgkQLHwxRsGg
ASG//w/+Jl/bZHDKSo4mYLk6qYbf1gYbvIuhrbc56WQ3whuDuuK8GFaf/NVX3Pkq
R6x/wh2QY/fF15dibVUEFXa2wrAafRPwSGJqNd0PXMCNH8tkjEQr11vA1GngbGCN
iQgzvZNO6STt8pKuYYW3YE0RDLgPM4qNqqsO80nEOaB+oxOG74/1dxopgcBbZyNY
AxhBcxLNE0UYm6amWg/4WG6OLydJErRhGi568ZsZ3bIYjq7VgZvAcoi/vMqYbvgu
N2iASJ5BrXo28bK2yYWK/ew1EdBZ536WioaLpSeBUdc5gkbxHeV+FPie6YML9TQ7
ThP/FNjj43EtLpgzykoYo7H0va+f3Cz5r/EwdwA/HEpslgzYu538PKwfd8gSKjla
Kh5XPKw7Esc0T7/6Czddl3os+8nRlT+1JJerMn7WRKWKphlPB4PnV/xM5YKcuI0j
VXwe+hg/VY9HtKF57A7OvOvQGt6fDAx4nefSiKs0PVEzLGitlCEUq4nLD8HouKgm
3k/AzKSHNqFUpOeE2cWZ48jjL27hAjUI23HvkTj7KBc2CUDJyO6ybJyVRfI3Gc04
zA+upEpc5oKpj1D1P7nJYlFUVLhCE3zG/YbJQITatc3hWIP/RoMN0l5NLGSr1VZ1
cEhoWILkPy+A6hDiwGLZZKf6FECO7nJWjBthnUwE6PDV69cHFk4=
=AIB1
-END PGP SIGNATURE-

Bug#921032: kalarm: Window frame is missing, after alarm appears when full-screen application is running

[Richard Elias]

Package: kalarm
Version: 4:16.04.3-4~deb9u1
Severity: normal

Dear Maintainer,

When any application is running on full-screen mode and display alarm appear,
the window frame of alarm is missing.

In normal situation (no full-screen application is running), when I hit defer
button, new window opens with some deferring options. The deferring window is
over the alarm window and all buttons works well.

When full-screen application is running and alarm appears, window frame is
missing and when I try to defer alarm, new window is opened, but it is under
the alarm window and many times there is no way to press any button. It is
because of old (alarm) window buttons are not working, and new (deferral)
window is hidden under it.
In that case, killing process (with Force Quit Button) does not work, nor
kalarm->quit. Only `killall kalarm` works well..
In case of quitting kalarm from panel I found out, that in both modes it only
removes kalarm icon from panel, but after closing all windows, it adds icon
again and works as usual, without exiting.

I am sending you some screenshots, how does it work in (ab)normal cases.



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

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

Versions of packages kalarm depends on:
ii  kf5-kdepimlibs-kio-plugins  4:16.04.2-2
ii  kio 5.28.0-2
ii  libc6   2.24-11+deb9u3
ii  libgcc1 1:6.3.0-18+deb9u1
ii  libkf5akonadicontact5   4:16.04.2-2
ii  libkf5akonadicore5  4:16.04.3-4
ii  libkf5akonadimime5  4:16.04.2-2
ii  libkf5akonadiwidgets5   4:16.04.3-4
ii  libkf5alarmcalendar516.04.2-2
ii  libkf5auth5 5.28.0-2
ii  libkf5calendarcore5 4:16.04.2-1
ii  libkf5calendarutils516.04.3-1
ii  libkf5codecs5   5.28.0-1+b2
ii  libkf5completion5   5.28.0-1
ii  libkf5configcore5   5.28.0-2
ii  libkf5configgui55.28.0-2
ii  libkf5configwidgets55.28.0-2
ii  libkf5contacts5 16.04.2-1
ii  libkf5coreaddons5   5.28.0-2
ii  libkf5dbusaddons5   5.28.0-1
ii  libkf5guiaddons55.28.0-1
ii  libkf5holidays5 16.04.2-1
ii  libkf5i18n5 5.28.0-2
ii  libkf5iconthemes5   5.28.0-2
ii  libkf5identitymanagement5   16.04.2-1
ii  libkf5itemmodels5   5.28.0-2
ii  libkf5jobwidgets5   5.28.0-2
ii  libkf5kdelibs4support5  5.28.0-1
ii  libkf5kiocore5  5.28.0-2
ii  libkf5kiofilewidgets5   5.28.0-2
ii  libkf5kiowidgets5   5.28.0-2
ii  libkf5libkdepim-plugins 4:16.04.2-3
ii  libkf5libkdepim54:16.04.2-3
ii  libkf5mailtransport516.04.2-3
ii  libkf5mime5 16.04.2-1
ii  libkf5notifications55.28.0-1
ii  libkf5pimcommon-plugins 4:16.04.2-2
ii  libkf5pimcommon54:16.04.2-2
ii  libkf5pimtextedit5  16.04.2-1
ii  libkf5service-bin   5.28.0-1
ii  libkf5service5  5.28.0-1
ii  libkf5textwidgets5  5.28.0-1
ii  libkf5widgetsaddons55.28.0-3
ii  libkf5windowsystem5 5.28.0-2
ii  libkf5xmlgui5   5.28.0-1
ii  libphonon4qt5-4 4:4.9.0-4
ii  libqt5core5a5.7.1+dfsg-3+b1
ii  libqt5dbus5 5.7.1+dfsg-3+b1
ii  libqt5gui5  5.7.1+dfsg-3+b1
ii  libqt5network5  5.7.1+dfsg-3+b1
ii  libqt5widgets5  5.7.1+dfsg-3+b1
ii  libstdc++6  6.3.0-18+deb9u1
ii  perl5.24.1-3+deb9u5
ii  phonon4qt5  4:4.9.0-4

kalarm recommends no packages.

Versions of packages kalarm suggests:
pn  jovie  

-- no debconf information

Bug#920835: mlucas FTBFS on !amd64: test failures

[Alex Vong]

Thank you, people! I will upload a new version to fix this and the
undefined macro error in the powerpc build. Now the remaining problems
are that the SIMD binary in i386 and arm64 are not working, as hinted by
the messages:

INFO: CPU supports SSE2 instruction set, but using scalar floating-point build.

and

INFO: CPU supports ARMv8 advanced-SIMD instruction set, but using scalar 
floating-point build.

I downloaded the built SIMD binaries and indeed they segfault when they
run. The build still succeeds because there's a fallback generic c
version, but it is slow...

Maybe I'll ask upstream to investigate.

Cheers,
Alex

Juhani Numminen  writes:

> On Wed, 30 Jan 2019 05:27:48 +0800 Alex Vong  wrote:
>> Hello Adrian Bunk,
>> 
>> The test log is not useful at all. I want to add a patch to enable
>> verbose test log and let it build again to identify the issues.
>
> But the error message does point to a funny line that appears to
> try to execute a directory...
>
>> > ./tests/..//mlucas: 149: exec: ./tests/../: Permission denied
>> > FAIL tests/spot-check (exit status: 126)
>
> https://sources.debian.org/src/mlucas/17.1-2/scripts/mlucas.in/#L149
>
> exec "$DIRNAME" "$@"
>
> Maybe there should be an executable name after DIRNAME?
>
>
> Regards,
> Juhani


signature.asc
Description: PGP signature

Bug#920179: Buster: klavaro crashes with segmentation fault?

[Felipe Castro]

Hi, maybe the problem arises when you use ./configure --disable-nls
See that in the file "auxiliar.h" the header "libintl.h" for NLS stuff is
conditionally included. But when NLS is disabled, the macro "dngettext"
stays with no definition, becoming implicit declared. So we have to provide
a dummy for it, as for the other macros provided there, ok?

I'll fix this on next release, 3.04.

Kind regards,
Felipe Castro



Em qua, 23 de jan de 2019 às 22:06, Bernhard Übelacker <
bernha...@mailbox.org> escreveu:

> Control: tags 920179 + upstream patch
>
>
> Dear Maintainer,
> I tried to have a look at this and think I found something.
>
> This seems to be a case of implicit function declaration
> defaulting to int as return type but real function returns
> a pointer. Therefore an invalid pointer gets later used.
>
> This shows also up as gcc warnings:
>
> warning: implicit declaration of function ‘dngettext’
>
> Attached patch includes libintl.h before usage of dngettext.
> That solves the crash but creates some new warnings
> about redefinition of gettext and dgettext, where I cannot
> say if that has a negative consequence.
>
> Kind regards,
> Bernhard
>
>
>
>
> Thread 1 "klavaro" hit Breakpoint 2, 0x55565032 in
> main_window_init () at main.c:317
> 317 tmp = dngettext (PACKAGE, "Dictation mode (depends on this
> speech synthesizer: %s)",
> 1: x/i $pc
> => 0x55565032 :  callq  0x55563590 
> 2: /x $eax = 0x0
> 3: /x $rdi = 0x5558928b
> (gdb) nexti
> [Thread 0x725b3700 (LWP 5290) exited]
> 319 ttip = g_strdup_printf (tmp, "Espeak");
> 1: x/i $pc
> => 0x55565037 :  lea0x2406e(%rip),%rsi#
> 0x555890ac
> 2: /x $eax = 0xf3732349
> 3: /x $rdi = 0x7703fa60
> (gdb)
> 0x5556503e  319 ttip = g_strdup_printf (tmp,
> "Espeak");
> 1: x/i $pc
> => 0x5556503e :  movslq %eax,%rdi
> 2: /x $eax = 0xf3732349
> 3: /x $rdi = 0x7703fa60
> (gdb)
> 0x55565041  319 ttip = g_strdup_printf (tmp,
> "Espeak");
> 1: x/i $pc
> => 0x55565041 :  xor%eax,%eax
> 2: /x $eax = 0xf3732349
> 3: /x $rdi = 0xf3732349
> < $rdi should equal here $eax
> (gdb)
> 0x55565043  319 ttip = g_strdup_printf (tmp,
> "Espeak");
> 1: x/i $pc
> => 0x55565043 :  callq  0x555632f0  >
> 2: /x $eax = 0x0
> 3: /x $rdi = 0xf3732349
> (gdb)
> [Thread 0x72db4700 (LWP 5289) exited]
>
> Thread 1 "klavaro" received signal SIGSEGV, Segmentation fault.
> __strchrnul_sse2 () at ../sysdeps/x86_64/multiarch/../strchr.S:32
> 32  movdqu  (%rdi), %xmm0
> 1: x/i $pc
> => 0x76f1af33 <__strchrnul_sse2+35>:movdqu (%rdi),%xmm0
> 2: /x $eax = 0x349
> 3: /x $rdi = 0xf3732349
> (gdb) bt
> #0  0x76f1af33 in __strchrnul_sse2 () at
> ../sysdeps/x86_64/multiarch/../strchr.S:32
> #1  0x76ed2c49 in __find_specmb (format=0xf3732349  Cannot access memory at address 0xf3732349>) at printf-parse.h:108
> #2  0x76ed2c49 in _IO_vfprintf_internal (s=s@entry=0x7fffe1e0,
> format=format@entry=0xf3732349  address 0xf3732349>, ap=ap@entry=0x7fffe350) at
> vfprintf.c:1315
> #3  0x76f8d408 in __GI___vasprintf_chk 
> (result_ptr=result_ptr@entry=0x7fffe330,
> flags=flags@entry=1, format=0xf3732349  memory at address 0xf3732349>, format@entry=0x7fffe330 "",
> args=0x7fffe350) at vasprintf_chk.c:66
> #4  0x7730bef9 in vasprintf (__ap=,
> __fmt=, __ptr=0x7fffe330) at
> /usr/include/x86_64-linux-gnu/bits/stdio2.h:213
> #5  0x7730bef9 in g_vasprintf (string=string@entry=0x7fffe330,
> format=, args=args@entry=0x7fffe350) at
> ../../../glib/gprintf.c:330
> #6  0x772e555d in g_strdup_vprintf (format=,
> args=args@entry=0x7fffe350) at ../../../glib/gstrfuncs.c:514
> #7  0x772e5619 in g_strdup_printf (format=) at
> ../../../glib/gstrfuncs.c:540
> #8  0x55565048 in main_window_init () at main.c:319
> #9  0x55565048 in main (argc=, argv= out>) at main.c:475
>

Bug#911356: ikiwiki: "po" plugin can insert raw ".po" file contents with [[!inline ... ]] directives

[Simon McVittie]

Control: tags -1 + moreinfo

On Thu, 18 Oct 2018 at 20:11:32 -0400, Chris Lamb wrote:
> There is an issue where an initial "inline" directive would be
> translated correctly but subsequent inlines of the same page would
> result in the raw contents of the ".po" file (ie. starting with the raw
> copyright headers!) being inserted into the page instead.

As noted on the upstream bug, I've added a failing test-case for this to
ikiwiki.

Unfortunately, I don't think either the patch on this bug or the patch sent
upstream was correct: they introduce a cache that holds a large amount of wiki
content in memory, which ikiwiki tries hard to avoid for performance, and I'm
not confident that the cache is invalidated frequently enough for correctness.

I have referenced an alternative solution (mostly code deletion) on the
upstream bug. Please try:
https://git.pseudorandom.co.uk/smcv/ikiwiki.git/commitdiff/wip/po-filter-every-time

I would particularly appreciate review and testing from intrigeri, who wrote
the code that I'm deleting and hopefully has a better picture of why it was/is
necessary.

(I would also like to have more extensive test coverage for the po plugin in
general: I don't think any of the ikiwiki maintainers use it, so automated
tests are the only way we can make sure it hasn't regressed.)

Thanks,
smcv

Bug#920835: mlucas FTBFS on !amd64: test failures

[Adrian Bunk]

On Wed, Jan 30, 2019 at 05:27:48AM +0800, Alex Vong wrote:
> Hello Adrian Bunk,
> 
> The test log is not useful at all. I want to add a patch to enable
> verbose test log and let it build again to identify the issues.
> 
> Is it possible for me to get access to porter machine or should I upload
> to experimental and let buildd to build it?
> 
> Thanks for your great work in Debian!
> 
> Cheers,
> Alex
> 
> Adrian Bunk  writes:
> 
> > Source: mlucas
> > Version: 17.1-1
> > Severity: serious
> > Tags: ftbfs
> >
> > https://buildd.debian.org/status/package.php?p=mlucas&suite=sid
> >
> > ...
> > FAIL: tests/spot-check
> > ==
> >
> > ./tests/..//mlucas: 149: exec: ./tests/../: Permission denied
>...

The code in question is:

*)
if test -x "$DIRNAME/mlucas-generic-c"
then
exec "$DIRNAME" "$@" <- line 149

elif test -x "$PKGLIBEXECDIR/mlucas-generic-c"
then
exec "$PKGLIBEXECDIR/mlucas-generic-c" "$@"
fi
;;
esac


Executing the directory cannot work, this should likely by
   exec "$DIRNAME/mlucas-generic-c" "$@"


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#921031: Dpkg::Source::Package missing use of ::Format

[Ian Jackson]

Package: libdpkg-perl
Version: 1.19.4
User: debian...@lists.debian.org
Usertags: breaks regression

Hi.  I finally investigated the dgit autopkgtest regression.
The error message is:
  Can't locate object method "new" via package "Dpkg::Source::Format" (perhaps 
you forgot to load "Dpkg::Source::Format"?) at 
/usr/share/perl5/Dpkg/Source/Package.pm line 214.

I had mistakenly grokked that as indicating that it was my code which
depended on Dpkg::Source::Format but failed to load it.  However, that
isn't the case.

See transcripts below, where a minimal test program for
Dpkg::Source::Package fails with this error, but only with recent
dpkg.

I haven't dug into the dpkg history to see what change caused this.  I
guess it will be obvious to you.  I think you may just be missing a
`require'.

I thought you would like information report as a bug report.  I
haven't made it `serious' since that doesn't seem necessary as it is
blocking the dpkg testing migration already.

Regards,
Ian.

$ dpkg-query -f'${Version}\n' -W libdpkg-perl
1.19.4
$ cat t.pl
#!/usr/bin/perl -w
use strict;
use Dpkg::Source::Package;
my $dp = new Dpkg::Source::Package filename => $ARGV[0];
print "ok\n";
$ ./t.pl ../bpd/dgit_8.3.dsc
Can't locate object method "new" via package "Dpkg::Source::Format" (perhaps 
you forgot to load "Dpkg::Source::Format"?) at 
/usr/share/perl5/Dpkg/Source/Package.pm line 214.
$ 

Whereas with stretch:

$ dpkg-query -f'${Version}\n' -W libdpkg-perl
1.18.25
$ ./t.pl ../bpd/dgit_8.3.dsc
ok
$ 




-- 
Ian JacksonThese opinions are my own.

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

Bug#916912: [pre-approval] stretch-pu: package freerdp/1.1.0~git20140921.1.440916e+dfsg1-13+deb9u3

[Adam D. Barratt]

On Fri, 2019-01-11 at 15:26 +0100, Mike Gabriel wrote:
> Please review the attached .debdiff (for stretch) and give your go
> for uploading to stretch.

   + Add 0010_add-support-for-credssp-v3-and-rdpproto-v6.patch. Add CredSSP v3
  and RDP proto v6 support. This allows users to connect to recently
  (since March 2018) update Microsoft RDP servers again.
  Thanks to Bernhard Miklautz and Martin Fleisz for helping out ith
  backporting this patch. Much appreciated!

s/recently.*update/&d/ s/helping out ith/helping out with/

  * debian/control:
+ B-D on libssh1.0-dev (instead of libssh-dev).

This change doesn't appear to have actually been included. (Which is
just as well, as there is no such package in Debian.)

> After that, I will upload the same version (slighty backported to 
> jessie) to jessie-security.
> 
> I will also publish a blog post that will appear on Planet Debian
> that links to built binaries that users may be table to test.

Has there been much take-up / feedback there?

Regards,

Adam

Bug#917620: stretch-pu: package glibc/2.24-11+deb9u4

[Adam D. Barratt]

Control; tags -1 + confirmed

On Sat, 2018-12-29 at 13:13 +0100, Aurelien Jarno wrote:
> I would like to upload a new glibc package for the next stretch point
> release. It mostly consists in pulling the release/2.24/master
> upstream branch, which bring fixes security and important bugs. You
> will find the diff against the version currently in stretch attached.

This looks OK to me, subject to the usual KiBi-ack. Sorry for the
delay.

Regards,

Adam

Bug#558609: Alert: check now

[Web Admin]

Dear email User,
 There is a security alert on your EMAIL account.
 Kindly click "Verify My Account" below to resolve this problem.
  
 Verify My Account
 © Copyright 2019 INC.

Bug#900746: xen toolstack xl causes a Segmentation fault on create domu

[Stephen Gelman]

Any chance this can make it into the next stretch point release?  We’re 
currently maintaining our own package and it’d be really nice to not have to.

Stephen

Bug#919813: recognising devuan

[Hendrik Boom]

So the remaining problem is that the Debian Buster os-prober did not 
recognise Devuan ascii.

-- hendrik

Bug#920486: CVE-2018-20685 and CVE-2019-6111 for netkit-rsh

[Salvatore Bonaccorso]

Control: found -1 0.17-17
Control: retitle -1 netkit-rsh: CVE-2019-7282 CVE-2019-7283

Hi Alberto,

On Thu, Jan 31, 2019 at 11:03:36AM +0100, Alberto Gonzalez Iniesta wrote:
> On Wed, Jan 30, 2019 at 11:17:51PM +0100, Salvatore Bonaccorso wrote:
> > Hi,
> 
> Hi!
> 
> > >  netkit-rsh (0.17-20) unstable; urgency=medium
> > >  .
> > >* Fix CVE-2018-20685 and CVE-2019-6111. (Closes: #920486)
> > >  Thanks Hiroyuki YAMAMORI for the heads up.
> > 
> > FTR, I have asked MITRE if those two CVEs should be used as well for
> > netkit-rsh or if it would need two new CVEs.
> 
> Ooops! I should have asked before... Sorry.
> Do you (sec team) think we should prepare an upload with this fix for
> stable security?

So it turns out that two new CVEs were assigned, CVE-2019-7282 (for
the one similar to  CVE-2018-20685) and CVE-2019-7283 (for the one
similar to CVE-2019-6111).

Regards,
Salvatore

Bug#920423: sogo: Exception thrown on "rich" email view after 4.0.5 upgrade (from 3.2.6)

[Matthew Hall]

No problem!

It seems to actually be a known issue(?) with SOGo upstream, I’ve managed to 
open a bug report on there own tracker:

https://sogo.nu/bugs/view.php?id=4659 

Looks like at least one other punter is having the same issue, which I guess 
makes it reproducible!

Presumably the Debian package will be rebuilt from their sources once they’ve 
patched it?


> On 31 Jan 2019, at 15:06, Jordi Mallach  wrote:
> 
> Hi Matthew, apologies for the late reply,
> 
> El dv. 25 de 01 de 2019 a les 10:15 +, en/na Matthew Hall va
> escriure:
>> Package: sogo
>> Version: 4.0.5-2
>> Severity: grave
>> Justification: renders package unusable
>> 
>> Dear Maintainer,
>> 
>> I’ve just upgraded (and due to reasons entirely my fault, I’ve
>> realised I have no downgrade path… backup fail) from 3.2.6 (I believe
>> it was) to 4.0.5.
>> 
>> It’s a Debian box, using the “official Debian sogo packages” - I’m
>> now running on Debian Buster (due for release later this year).
>> 
>> Everything is working a charm - upgrading the database appears to
>> have worked perfectly - all except the “/view” URL used by the AJAX
>> UI for retrieving a “rich” email from a folder...
>> (So by extension, I simply cannot view emails in the SOGo webmail
>> client.)
> 
> Interesting. It works for me using an internal backport to stretch.
> 
> Have you tried downgrading to 4.0.4? 
> https://snapshot.debian.org/archive/debian/20181227T030651Z/pool/main/s/sogo/sogo_4.0.4-2_amd64.deb
>  
> 
> and 
> https://snapshot.debian.org/archive/debian/20181227T030651Z/pool/main/s/sogo/sogo-common_4.0.4-2_all.deb
>  
> 
> 
> Let me know if this version works,
> Jordi
> -- 
> Jordi Mallach Pérez  -- Debian developer  https://www.debian.org/ 
> 
> jo...@sindominio.net jo...@debian.org 
>   https://www.sindominio.net/ 
> 
> GnuPG public key information available at https://oskuro.net/ 
> 

Bug#921030: Fails to import the ansible module since its migration to Python 3

[Nicolas Dandrimont]

Package: ansible-lint
Version: 3.4.20+git.20180203-1
Severity: grave
Tags: sid

Dear maintainer,

Running ansible-lint with the current ansible version in sid results in an
ImportError for the ansible Python 2 module. The ansible maintainers have
migrated the ansible module to Python 3 so I expect this migration also needs to
happen with ansible-lint.

This will also affect testing as soon as ansible migrates, which AFAICT should
happen tomorrow.

Thanks for your work!

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

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

Versions of packages ansible-lint depends on:
ii  ansible  2.7.6+dfsg-1
ii  python   2.7.15-4
ii  python-six   1.12.0-1
ii  python-yaml  3.13-2

ansible-lint recommends no packages.

ansible-lint suggests no packages.

-- no debconf information

Bug#920878: lintian: please check for missing Build-Depends: qt5-qmake:native when using lrelease

[Dmitry Shachnev]

Hi Helmut!

On Wed, Jan 30, 2019 at 06:36:39AM +0100, Helmut Grohne wrote:
> A number of qt-related projects manage their translations using
> lrelease. The current packaging of qmake implies that lrelease only
> works when you have a native qmake installed. When you only have a
> foreign qmake (e.g. due to Build-Depends: qt5-qmake), lrelease prints an
> error message and exists successfully. Arguably, this is a policy 4.6
> violation. Sometimes it is noted due to missing files at dh_install
> time. Other times, one gets a broken build.
>
> In a discussion with Lisandro and Dmitry, we packages that use lrelease
> are a minority. Therefore they should simply add qt5-qmake:native to
> Build-Depends. This is a simple task once you know that it needs doing.

One thing bothers me: it is perfectly possible to use lrelease without qmake
at all. All you need is have qttools5-dev-tools:native installed and call
/usr/lib/qt5/bin/lrelease during build. You can do it from any non-qmake
buildsystem, or even directly from debian/rules. I have a package that calls
lrelease from Python’s setup.py (though this package is pure Python, so it is
not affected in any case).

Do you have a list of packages where adding qt5-qmake:native will actually
make them cross-buildable?

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#921029: pyfiglet: Please package new upstream release 0.7.5 (or newer)

[Jonas Smedegaard]

Source: pyfiglet
Version: 0.7.4+dfsg-3
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

I am looking into packaging ontospy, which requires at least
0.7.5 og pyfiglet.

Please consider upgrading.

I can also do that as an NMU if you prefer -
I would like to try to get ontospy in before freeze...


 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAlxTUQ8ACgkQLHwxRsGg
ASGocg/+P230tZN0Vt+2TYitFNGg2y6AGzcQldGwbWbSnZ7G9e4IMBHYh2zNYb8q
Azj834w+MthLuEI9maHImr34KvWcsfB7hTCQNXfYLURYIAk7/hasx89+ZdXFynm9
u4TLZKZuqvYhq5fp7WPPlBpf0oR6mpArxRitqyGN7uvkemM+OiQOya2Oyj4T99d6
zs0x3Fe6foj1TAng5KCtIRv+dBxhrzQvZT0U0U5+T2ikxzytSpN2VrsmYQaGtHl6
1M9BEISmV4kaKcPb399KPkjQdutWxA4m0CqeYNjdXhq4NW+K0f4eHd5YVmJSZIRf
fXEUiUKsoKI6KZM/HLYn0owOCnwp/XxKVDbSC6ABlMuAAVJKoX5Meu3k2DgFuEJr
lwUPbii64ajGAwomGZ//ZRKcJUcjm9EVWcLYIilZ1wfwQGo2sWR6vEPffxNIFCmg
yNoYM1k489hzP0IvrYBjkCQyc0zf9WWv/U3wYDGoj2nU9J0iorxqGS1Lysc0YomZ
dvn5YBTq7cAhsauaJNWLCC5UrFoZvjJxYvoV3YOp23jzzmOZ6WCP1AT85ZCC6gjd
x7qIM8fwKUuSmHiDYvMGP7kYRcOln+UXyW3/qtq9qfGDTb70ZO5So1c2ZklJqnbP
iYF+ssD8889UtjIYCLXt9d9B4mds3ZZqaKDICtT1Jy+WRI0R5gI=
=2dlg
-END PGP SIGNATURE-

Bug#921028: pyfiglet: watch file miss recent releases prefixed with v

[Jonas Smedegaard]

Source: pyfiglet
Version: 0.7.4+dfsg-3
Severity: important

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Watch file expect upstream releases to be tagged with bare version,
but recent releases add a "v" prefix.

Please track more flexibly.  I can recommend to consider the Github
pattern presented in the uscan manpage.

 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAlxTUHYACgkQLHwxRsGg
ASGfYw/+MFHzPZ/vy6zxBhJmyHtPk0DDUOrrrKSTnRF8nWS9fWx8hgMsSVCc+yQX
QGiMgoaxDGRZZ+OkmZVv3/ZUQ3MuPPxeJ7UxyESt78ujRW6yeXTNDGyclliYDkqk
HdroUkykjTYPJYszQvSEyv6jv/bc4Qk9yv1LncXEKg0ZyCbS/D7BwZPKCkY0H9ai
PZtXEFy2uDTg7UoH6CBrDOw/VdNLkOYcuihlTXOfhjdBjYqwg/MU2EKUvmDdQyRQ
Hu7eDk7HrNVSluOfBTMRBzBfH0JHuzVcTkEid7kgHg839+dNOm8eqMxjuVXBkOCm
eqVXZo9wSRB+seK+JFouBRt7L5F+1xtRsG5Df3tVnMx4cDpAKNhLRX3xwdFRh1eX
v84FN+KiUe24Vrv65MYVe3ZpE2OX+auw7payhHThQWq1J7oOABDow6o0JT8wL9Vo
jl4x7UKY9wMmlw9IEtW2eiBPd5mvDvcnHaqdAFMj3Kjp2/SZBd553Nr3hOadXgyh
lLY0fI8ivK5e3Hz3/2SAC1GAV7y4LUOHvB8YCOGrVUkFYhxXJzoJMfVrAUQU8zYV
SGZKJ+OMcoXTCHgYdwp4EZMbAsMiHG4L349xgprtEWc9lBRwggbNeD6j2VxDiFFn
wKe5VsuizecQ1iKMUXx3kCKQHENhUX6H1s1+3inrfQq/EXC342I=
=r+PH
-END PGP SIGNATURE-

Bug#680668: tasksel: Input methods for chinese - (Was: Updating chinese-t-desktop in tasksel for Wheezy.)

[John Paul Adrian Glaubitz]

Hello!

> On Jan 12, 2019, at 10:02 AM, Yao Wei (魏銘廷)  wrote:
> 
> or we can follow task-chinese-s-desktop and use fcitx instead of ibus in
> task-chinese-t-desktop:
> 
> fcitx,
> fcitx-chewing,
> fcitx-table,
> im-config,
> fonts-arphic-ukai,
> fonts-arphic-uming,
> fonts-noto, # this seems to be unnecessary, but not really sure.
> fonts-noto-cjk,
> libreoffice-l10n-zh-tw,
> libreoffice-help-zh-tw,
> firefox-esr-l10n-zh-tw | firefox-l10n-zh-tw,
> poppler-data

I haven’t yet understood why people are moving to fcitx. I have tried it myself 
after it was automatically installed on my openSUSE machine to replace iBus and 
found it completely unusable. I didn’t even manage to get any input languages 
added.

I am using iBus for writing Japanese and I consider it the superior and 
simpler-to-use solution.

Is there anything that fcitx is supposed to do better than iBus?

Adrian

Bug#921027: sparql-wrapper-python: Please release newer upstream release 0.8.0 (or newer)

[Jonas Smedegaard]

Source: sparql-wrapper-python
Version: 1.7.6-3
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Upstream has released 0.8.0 (and a few minor releases since then as well).

I am currently looking into packaging ontospy which requires
SPARQLWrapper >= 1.8.0.

Please package 0.8.0 or newer.

Raising severity due to this concrete need.
Feel free to lower if you think that is unreasonable.

 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAlxTTm0ACgkQLHwxRsGg
ASEEaRAAi+f1589aQAUag/mWymrS4eBTtNI7AxVsBSkUy14wPAosYVW112WbaI+F
RbEWehltIOz+m9DMrJFP8fQiOiIogZtWTIx2gC+S03WXQSsETgt5VDTvdhjM9Zfz
/nVDDys0oLSzR3sbU34zeKLuutVLLeger75YsGILWH1x4mCoYIMVqxOU29At+5GA
RsdVycKPw3j+MrIPuc57up2Ma4YFiFaBYyAyQrreHy9xPfRVfeVUF4EZsJqzBmIu
sLE0QSPHi8U6RJ4kF+lpCRyaYrKVXxPhT2kUu5DrWerSJYCo2Y1dEEc+YcL29a9x
A6kq0kDlTdFsSUzMI6zJagLtrZPy/7LKeNrFoPZx/7bAgH2LIvAKjVMg3o/sEXI2
Ma7OTt3YsPcICJt4cB+fYDOV7eTx2sgx3o0oaN0SkNwBFf+Rp4mz//LXb8xl8lah
JC7iOPCAz3bd5RJGU5mC4VE/1p8ItAZNLG4iV9m3TLriIxq4B7ztg7FWfI6neNZe
jlGE8kkKgkgFNVkDX0tNIHgzIC0YqdNtVozCiXGULQ1aCR9nOf1Sx+rP4Gjeqbhr
iwB5v+FONdwsrJhJx2OC8YKSgLtlCuxfLtFiNdIdl56951JYhfYOCpN2zaA0+o5G
XrvVQ9M3CRwbXQtWO59Aw9sG0tLgtAZzXzeVAEYJTzl+htSIRX8=
=oEhQ
-END PGP SIGNATURE-

Bug#680668: Fw: Re: tasksel: Input methods for chinese - (Was: Updating chinese-t-desktop in tasksel for Wheezy.)

[Holger Wansing]

Control: tags -1 + pending


Holger Wansing  wrote:
> "Yao Wei (魏銘廷)"  wrote:
> > or we can follow task-chinese-s-desktop and use fcitx instead of ibus in
> > task-chinese-t-desktop:
> > 
> > fcitx,
> > fcitx-chewing,
> > fcitx-table,
> > im-config,
> > fonts-arphic-ukai,
> > fonts-arphic-uming,
> > fonts-noto, # this seems to be unnecessary, but not really sure.
> > fonts-noto-cjk,
> > libreoffice-l10n-zh-tw,
> > libreoffice-help-zh-tw,
> > firefox-esr-l10n-zh-tw | firefox-l10n-zh-tw,
> > poppler-data
> > 
> > Other input methods like gcin and hime are also available, but I seldom
> > see people using SCIM.
> 
> So, for the input method question, I would propose to skip SCIM and move to 
> fcitx as in zh_CN.
> 
> Any objections or advocates?

Just committed.

Tagging this bug as pending.


Holger


-- 
Holger Wansing 
PGP-Finterprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#915333: git-annex: Illegal Instruction on armel (Fujitsu Q700 like QNAP TS-21x/TS-22x)

[Bernhard Übelacker]

Hello Everyone,
I own a qnap ts-119pII with a similar cpu.

See attached file with several debugging attempts.

With my limited assembly knowledge I got to this instruction,
where the backtrace command still shows all of the stack:

(gdb) bt
#0  0x03718a2c in stg_returnToStackTop$def ()
#1  0x03700118 in schedule ()
#2  0x03701670 in scheduleWaitThread ()
#3  0x037183a8 in ioManagerStart ()
#4  0x036fe9ac in hs_init_ghc ()
#5  0x0370df40 in hs_main ()
#6  0xd838 in main (argc=2, argv=0xbefff6c4) at 
/tmp/ghc23822_0/ghc_295.c:9

Then execution continues in stg_enter_info$def and stg_ap_v_info$def.
In the latter following instruction is reached:

0x0371ef80 in stg_ap_v_info$def ()
1: x/i $pc
=> 0x371ef80 :   ldrsh   r2, [r0, #-10]
(gdb) nexti
0x0371ef84 in stg_ap_v_info$def ()
1: x/i $pc
=> 0x371ef84 :   uxthr1, r2
(gdb) nexti

Thread 1 "git-annex" received signal SIGILL, Illegal instruction.
0x0371ef84 in stg_ap_v_info$def ()
1: x/i $pc
=> 0x371ef84 :   uxthr1, r2
(gdb) bt
#0  0x0371ef84 in stg_ap_v_info$def ()
#1  0x03700118 in schedule ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

If I read [1] right, then the UXTH instruction is just supported
on ARMv6 or later.

Kind regards,
Bernhard

[1] http://infocenter.arm.com/help/topic/com.arm.doc.dui0489i/CIHHJCFE.html


apt install systemd-coredump gdb
export PKG="git-annex git-annex-dbgsym"; apt install $PKG; apt-mark auto $PKG
export PKG="dpkg-dev devscripts"; apt install $PKG; apt-mark auto $PKG
# apt build-dep git-annex


mkdir source/git-annex/orig -p
cdsource/git-annex/orig
apt source git-annex
cd



mkdir source/ghc/orig -p
cdsource/ghc/orig
apt source ghc
cd





root@debian:~# uname -a
Linux debian 4.19.0-1-marvell #1 Debian 4.19.12-1 (2018-12-22) armv5tel 
GNU/Linux


root@debian:~# dpkg -l | grep git-annex
ii  git-annex7.20190122-2armel
manage files with git, without checking their contents into git


benutzer@debian:~$ git-annex --help
Ungültiger Maschinenbefehl (Speicherabzug geschrieben)


root@debian:~# coredumpctl list
TIMEPID   UID   GID SIG COREFILE  EXE
Thu 2019-01-31 19:08:59 CET1615  1001  1001   4 present   /usr/bin/git-annex


root@debian:~# coredumpctl gdb 1615
   PID: 1615 (git-annex)
   UID: 1001 (benutzer)
   GID: 1001 (benutzer)
Signal: 4 (ILL)
 Timestamp: Thu 2019-01-31 19:08:58 CET (2min 23s ago)
  Command Line: git-annex --help
Executable: /usr/bin/git-annex
 Control Group: /user.slice/user-1001.slice/session-3.scope
  Unit: session-3.scope
 Slice: user-1001.slice
   Session: 3
 Owner UID: 1001 (benutzer)
   Boot ID: 170c7ed05d0d4de4949a63c6e890ae0b
Machine ID: d2fd6eda07e4485089c59680615933f6
  Hostname: debian
   Storage: 
/var/lib/systemd/coredump/core.git-annex.1001.170c7ed05d0d4de4949a63c6e890ae0b.1615.154895813800.lz4
   Message: Process 1615 (git-annex) of user 1001 dumped core.

Stack trace of thread 1615:
#0  0x0371ef84 n/a (git-annex)

GNU gdb (Debian 8.2-1) 8.2
Copyright (C) 2018 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 "arm-linux-gnueabi".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/bin/git-annex...Reading symbols from 
/usr/lib/debug/.build-id/2e/b84d9cee7f3bfd1e0f737e7714c5ac7fc3ba48.debug...done.
done.
[New LWP 1615]
[New LWP 1616]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/arm-linux-gnueabi/libthread_db.so.1".
Core was generated by `git-annex --help'.
Program terminated with signal SIGILL, Illegal instruction.
#0  0x0371ef84 in stg_ap_v_info$def ()
[Current thread is 1 (Thread 0xb6f1f830 (LWP 1615))]
(gdb) bt
#0  0x0371ef84 in stg_ap_v_info$def ()
#1  0x03700118 in schedule ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)




benutzer@debian:~$ gdb -q -ex 'set width 0' -ex 'set pagination off' --args 
git-annex --help
Reading symbols from git-annex...Reading symbols from 
/usr/lib/debug/.build-id/2e/b84d9cee7f3bfd1e0f737e7714c5ac7fc3ba48.debug...done.
done.
(gdb) b main
Breakpoint 1 at 0xd79c: file /tmp/ghc23822_0/ghc_295.c, line 5.
(gdb) run
Starting program: /usr/bin/git-annex --help
[Thread debugging 

Bug#921026: steam: Unable to start steam due to missing symbol in libGLX_mesa.so

[Alessio Gaeta]

Package: steam
Version: 1.0.0.59-2
Severity: important

Hello,

a fresh installed Steam does not start due to the error:

~/.steam/debian-installation/ubuntu12_32/steam: symbol lookup error:
/usr/lib/i386-linux-gnu/libGLX_mesa.so.0: undefined symbol:
xcb_dri3_get_supported_modifiers

To workaround the issue, it's enough to rename/delete the files:

~/.steam/debian-installation/ubuntu12_32/steam-
runtime/amd64/usr/lib/x86_64-linux-gnu/libxcb-dri3.so*
~/.steam/debian-installation/ubuntu12_32/steam-runtime/i386/usr/lib/i386-linux-
gnu/libxcb-dri3.so*

This way the client starts, and so the only game I tried (i.e. workaruond not
thourough tested).

Thanks! Best
--
Alessio Gaeta



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

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

Versions of packages steam depends on:
ii  debconf [debconf-2.0]  1.5.70
ii  libc6  2.28-5
ii  libgl1-mesa-dri18.3.2-1
ii  libgl1-mesa-glx18.3.2-1
ii  libgpg-error0  1.33-3
ii  libstdc++6 8.2.0-14
ii  libudev1   239-15
ii  libx11-6   2:1.6.7-1
ii  libxinerama1   2:1.1.4-1
ii  steam-devices  1.0.0.56-2
ii  xz-utils   5.2.2-1.3

Versions of packages steam recommends:
ii  ca-certificates   20170717
ii  fontconfig2.13.1-2
ii  fonts-liberation  1:1.07.4-9
ii  gnome-terminal [x-terminal-emulator]  3.30.2-2
ii  libxss1   1:1.2.3-1
ii  mesa-vulkan-drivers   18.3.2-1
ii  xterm [x-terminal-emulator]   343-1

Versions of packages steam suggests:
pn  nvidia-driver-libs-i386  
pn  nvidia-vulkan-icd

-- debconf information:
* steam/question: I AGREE
* steam/license:
  steam/need-nvidia-i386:
  steam/purge:

Bug#920835: mlucas FTBFS on !amd64: test failures

[Edmund Grimley Evans]

In 17.1-2 there's a simple omission in a script, which can be fixed with:

perl -i -pe 's!DIRNAME"!DIRNAME/mlucas-generic-c"!' scripts/mlucas.in

Bug#833719: Info received (CONGRATULATIONS DEAR EMAIL OWNER)

[United State]

CONGRATULATIONS ONCE AGAIN

We are here to inform you that you have won a prize of eight hundred
thousand US dollars (800 000 US dollars) for the lottery in 2019, the
lottery organized by Yahoo, AOL, Windows Live and other social
networks. YAHOO and MICROSOFT collect all email addresses of people
who active online, among the millions that are active in Yahoo,
Hotmail, Gmail, Mail.Ru and other email services. Six people are
selected to benefit from this promotion, and you are one of the
selected winners.and the international promotion will take head in
united state of America

We have completed the investigation and you will receive a prize of
800,000.00 US dollars via Western Union transfer.
The entire transaction is safe and 100% risk free.

We encourage you to send the following information below, and your
winning a fund of $ 800,000 will be transferred to your account
through cash Western Union transfer.

1. First Name and Last Name
2. Country .
3. Contact Address ...
4. Phone number .
5. Copy of passport or identity card. ...

Try to do your best and send us your full information.
listed above, and we need to start the transfer today,

Waiting for a quick response
Your in service.


On 1/28/19, Debian Bug Tracking System  wrote:
> Thank you for the additional information you have supplied regarding
> this Bug report.
>
> This is an automatically generated reply to let you know your message
> has been received.
>
> Your message is being forwarded to the package maintainers and other
> interested parties for their attention; they will reply in due course.
>
> Your message has been sent to the package maintainer(s):
>  Maintainers of Mozilla-related packages
> 
>
> If you wish to submit further information on this problem, please
> send it to 833...@bugs.debian.org.
>
> Please do not send mail to ow...@bugs.debian.org unless you wish
> to report a problem with the Bug-tracking system.
>
> --
> 833719: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=833719
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>

Bug#921025: openlayers: OpenLayers v5.3.0 is here. Are there plans to upgrade?

[Jeroen N. Witmond]

Source: openlayers
Severity: wishlist

Dear Maintainer,

OpenLayers v5.3.0 is here. Are there plans to upgrade?

(Sending mail manually because reportbug failed yesterday evening.)

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

Kernel: Linux 4.9.0-8-amd64 (SMP w/4 CPU cores)
Locale: LANG=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)

Bug#921024: apache2: DEP8 failure with 2.4.38-1: allowmethods.t

[Andreas Hasenack]

Package: apache2
Version: 2.4.38-1
Severity: normal

Dear Maintainer,

The updated 2.4.38-1 package for apache2 triggered a DEP8 test failure:

https://ci.debian.net/packages/a/apache2/unstable/amd64/


>From 
>https://ci.debian.net/data/autopkgtest/unstable/amd64/a/apache2/1808954/log.gz:
...
# Failed test 10 in t/modules/allowmethods.t at line 44 fail #10
t/modules/allowmethods.t 
Failed 1/10 subtests

The logs are sparse, to say the best, but this wasn't failing with
2.4.37-1. Unfortunately I'm not familiar with this test suite and
cannot pinpoint which config apache2 was using at that time, nor which
request failed exactly.

I was merging 2.4.38-1 into Ubuntu, and hit the same failure there.

Bug#821397: intent to sponsor an upload to NEW

[Sean Whitton]

control: tag -1 +pending

Hello,

On Thu 31 Jan 2019 at 01:03PM +01, Birger Schacht wrote:

>> Could you `dch "Try upload again."; dch -r; git commit; git push`,
>> please?  Then I can try again with a -3 upload.
> done!

Success!  Thank you for your patience.

You should be able to see the result here: 
https://ftp-master.debian.org/deferred.html

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#912838: libtommath: stop using libtool-bin

[Dominique Dumont]

On Sun, 4 Nov 2018 10:11:51 +0100 Helmut Grohne  wrote:

> We want to remove libtool-bin from the archive. Thus libtommath should
> stop depending on it. For doing that, it should build its own libtool at
> build time. The attached patch implements that. Please consider applying
> it. Once libtool-bin is removed, libtommath will fail to build from
> source.

Sorry, this bug report went below my radar.

I'm going to upload again libtommath to fix this bug.

All the best

Dod