Bug#883341: [3dprinter-general] Bug#883341: slic3r: Missing dependencies: wx-common, libopengl-perl, libwx-glcanvas-perl

[Chow Loong Jin]

Control: tags -1 + wontfix

On Tue, Jan 02, 2018 at 12:52:38AM +0200, Adrian Bunk wrote:
> [...]
> They are only recommended since the non-GUI functionality of the package 
> does work without these packages.
> 
> Whether these should be recommends or dependencies is a valid question, 
> and as far as I can see both choices would be reasonable maintainer[1] 
> choices in this case.
> 
> cu
> Adrian
> 
> [1] I am not the maintainer of slic3r

I still think setting the GUI dependencies as recommends is the right choice as
per the explanation Adrian gave, so I'm not going to change this.

I recommend that you don't skip installing recommended packages if you want the
full functionality of any Debian package. If you're using a derivative distro
that disables the installation of recommended packages, then please take the
issue up with the developers of the distro you're using.

-- 
Kind regards,
Loong Jin


signature.asc
Description: PGP signature

Bug#886214: kdepim lost kjots

[Harald Dunkel]

Package: kdepim
Version: 4:16.04.3-4~deb9u1

Installing the kdepim package kjots is not even suggested.
Is it possible that kdepim lost kjots?

Regards
Harri

Bug#886213: ITP: node-detect-port-alt -- detect available port

[Pirate Praveen]

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

* Package name: node-detect-port-alt
  Version : 1.1.3
  Upstream Author : xdf
* URL : https://github.com/node-modules/detect-port
* License : Expat
  Programming Lang: JavaScript
  Description : detect available port

 JavaScript Implementation of Port Detector. This library can detect if
a port
 is available or it can also return a random available port.
 .
 Node.js is an event-based server-side JavaScript engine.

In dependency chain for gitlab 9.5 (dependency of react-dev-utils).



signature.asc
Description: OpenPGP digital signature

Bug#886194: src:qgis: QScintilla2 -dev packages renamed, please update build-depends

[Sebastiaan Couwenberg]

Control: tags -1 pending

Hi Scott,

On 01/03/2018 01:50 AM, Scott Kitterman wrote:
> In the transition that has just started, libqscintilla2-dev has been renamed
> libqscintilla2-qt4-dev to match upstream changes.  libqscintilla2-qt4-dev
> provides libqscintilla2-dev, so your package won't immediately FTBFS, but it
> would be good to update the build-depends in your next upload.

A transitional package would probably have been better.

> If you plan an upload soon, please let us know so that we con't binNMU the
> package and save the buildd time of doing it twice.

The B-D has been updated in git, and a new upload to unstable will
follow sometime today.

Kind Regards,

Bas

Bug#886212: pure-ftpd FTCBFS: configures for the build architecture

[Helmut Grohne]

Source: pure-ftpd
Version: 1.0.46-1
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

pure-ftpd fails to cross build from source, because it does not pass the
required --host flag to ./configure. The easiest way of doing that is
deferring the task to dh_auto_configure. After doing so, pure-ftpd still
fails to cross build, because it uses AC_RUN_IFELSE without a default.
Most of the checks can be converted to AC_COMPILE_IFELSE or
AC_LINK_IFELSE with little loss, but that requires autoreconfing the
package and that is quite difficult to achieve with the current
packaging. Thus I ask you to just apply the attached patch and closing
this bug when doing so to make the AC_RUN_IFELSE issue apparent to cross
builders. It would also be nice to run autoreconf to be able to fix the
other issues.

Helmut
diff -u pure-ftpd-1.0.46/debian/changelog pure-ftpd-1.0.46/debian/changelog
--- pure-ftpd-1.0.46/debian/changelog
+++ pure-ftpd-1.0.46/debian/changelog
@@ -1,3 +1,11 @@
+pure-ftpd (1.0.46-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Partially fix FTCBFS: Let dh_auto_configure pass --host to ./configure.
+(Closes: #-1)
+
+ -- Helmut Grohne   Tue, 02 Jan 2018 19:51:18 +0100
+
 pure-ftpd (1.0.46-1) unstable; urgency=medium
 
   * New upstream release (Closes: #861159, #867380):
diff -u pure-ftpd-1.0.46/debian/rules pure-ftpd-1.0.46/debian/rules
--- pure-ftpd-1.0.46/debian/rules
+++ pure-ftpd-1.0.46/debian/rules
@@ -5,7 +5,7 @@
 # Uncomment this to turn on verbose mode.
 #export DH_VERBOSE=1
 
-cfgflags=--prefix=/usr --mandir='$${prefix}'/share/man 
--sysconfdir=/etc/pure-ftpd CFLAGS="-O2 -DMAX_USER_LENGTH=128U"
+cfgflags=--sysconfdir=/etc/pure-ftpd CFLAGS="-O2 -DMAX_USER_LENGTH=128U"
 optflags=--with-everything --with-largefile --with-pam --with-privsep 
--with-tls --with-rfc2640
 bin=pure-pw pure-statsdecode pure-pwconvert
 sbin=pure-authd pure-ftpwho pure-uploadscript pure-quotacheck pure-ftpd 
pure-mrtginfo
@@ -15,7 +15,7 @@
 src/vanilla/pure-ftpd:
dh_testdir
[ ! -f Makefile ] || $(MAKE) distclean
-   ./configure $(cfgflags) $(optflags)
+   dh_auto_configure -- $(cfgflags) $(optflags)
$(MAKE)
mkdir $(@D)
mv $(addprefix src/, $(bin) $(sbin)) $(@D)
@@ -23,7 +23,7 @@
 src/ldap/pure-ftpd:
dh_testdir
[ ! -f Makefile ] || $(MAKE) distclean
-   ./configure $(cfgflags) $(optflags) --with-ldap
+   dh_auto_configure -- $(cfgflags) $(optflags) --with-ldap
$(MAKE)
mkdir $(@D)
mv $(addprefix src/, $(bin) $(sbin)) $(@D)
@@ -31,7 +31,7 @@
 src/mysql/pure-ftpd:
dh_testdir
[ ! -f Makefile ] || $(MAKE) distclean
-   ./configure $(cfgflags) $(optflags) --with-mysql
+   dh_auto_configure -- $(cfgflags) $(optflags) --with-mysql
$(MAKE)
mkdir $(@D)
mv $(addprefix src/, $(bin) $(sbin)) $(@D)
@@ -39,7 +39,7 @@
 src/postgresql/pure-ftpd:
dh_testdir
[ ! -f Makefile ] || $(MAKE) distclean
-   ./configure $(cfgflags) $(optflags) --with-pgsql
+   dh_auto_configure -- $(cfgflags) $(optflags) --with-pgsql
$(MAKE)
mkdir $(@D)
mv $(addprefix src/, $(bin) $(sbin)) $(@D)
@@ -47,7 +47,7 @@
 src/vanilla-virtualchroot/pure-ftpd:
dh_testdir
[ ! -f Makefile ] || $(MAKE) distclean
-   ./configure $(cfgflags) $(optflags) --with-virtualchroot
+   dh_auto_configure -- $(cfgflags) $(optflags) --with-virtualchroot
$(MAKE)
mkdir $(@D)
mv $(addprefix src/, $(bin) $(sbin)) $(@D)
@@ -55,7 +55,7 @@
 src/ldap-virtualchroot/pure-ftpd:
dh_testdir
[ ! -f Makefile ] || $(MAKE) distclean
-   ./configure $(cfgflags) $(optflags) --with-virtualchroot --with-ldap
+   dh_auto_configure -- $(cfgflags) $(optflags) --with-virtualchroot 
--with-ldap
$(MAKE)
mkdir $(@D)
mv $(addprefix src/, $(bin) $(sbin)) $(@D)
@@ -63,7 +63,7 @@
 src/mysql-virtualchroot/pure-ftpd:
dh_testdir
[ ! -f Makefile ] || $(MAKE) distclean
-   ./configure $(cfgflags) $(optflags) --with-virtualchroot --with-mysql
+   dh_auto_configure -- $(cfgflags) $(optflags) --with-virtualchroot 
--with-mysql
$(MAKE)
mkdir $(@D)
mv $(addprefix src/, $(bin) $(sbin)) $(@D)
@@ -71,7 +71,7 @@
 src/postgresql-virtualchroot/pure-ftpd:
dh_testdir
[ ! -f Makefile ] || $(MAKE) distclean
-   ./configure $(cfgflags) $(optflags) --with-virtualchroot --with-pgsql
+   dh_auto_configure -- $(cfgflags) $(optflags) --with-virtualchroot 
--with-pgsql
$(MAKE)
mkdir $(@D)
mv $(addprefix src/, $(bin) $(sbin)) $(@D)

Bug#886004: elfutils should build without -Werror

[Helmut Grohne]

On Wed, Jan 03, 2018 at 12:42:44AM +0100, Mark Wielaard wrote:
> In general, if it is a new gcc release, we will likely have seen the
> issue before upstream or in another distro and can providing a patch to 
> include in the debian package can normally be done in 3 days. This
> is what we do with other distros too.

While that doesn't reflect elfutils' Debian history, the prospect is
useful to work with. I am willing to try. Please go ahead and upload the
two gcc-8 fixes you mentioned in your other mail to unstable.

I think you can close this bug when doing so. We'll see how it goes. If
it happens to not fix -Werror fallout in a timely manner I'll open it
again.

> > We can try using jenkins.d.n resources. There I'm cross building
> > elfutils for alpha, arm64, armel, armhf, i386, kfreebsd-i386, m68k,
> > mips64el, mips, mipsel, nios2, powerpc, powerpcspe, ppc64, ppc64el,
> > s390x, sh4, sparc, sparc64, tilegx, x32 and would like to cross build it
> > for some more (including musl-linux-any, mips64r6el, ia64, sh3, hppa).
> 
> That would be nice. Note that some of those setups (particular the mips
> variants) don't have upstream support yet. It would be nice to get the
> Debian backend patches upstreamed before we add some of those to the CI.

For most of those architectures, Debian provides cross-toolchains that
can be installed with apt-get install. So if you already have
Debian-based autobuilders, you could simply extend them with that
functionality. Architecture-specific patches are beyond my realm though.

> elfutils is a bit like glibc indeed. It gets tested against the latest
> stable gcc and binutils releases in the various distros (at least those
> in debian, fedora, centos through the CI) and if gcc is in stage1 then
> the next version will most likely also have been checked already.

I trust you that it is quick. However that does not - in practise -
translate to the Debian package yet.

> When tested a new arch/toolchain please involve upstream as soon as
> possible. We really are interested. And would like to have warning
> free and zero-fail builds for all distros.

Sounds great. Thus far I've only seen annoying -Werror fallout, which
has contributed to slowing down test progress. Before we can actually
run stuff, we still need to make perl work.

Helmut

Bug#836408: ITP: jquery-caret.js -- library to query input caret position

[Sergio Durigan Junior]

On Tuesday, January 02 2018, Ben Finney wrote:

> On 02-Jan-2018, Sergio Durigan Junior wrote:
>> On Sunday, December 11 2016, Ben Finney wrote:
>> > I am still not clear about how this is meant to be used, so after
>> > it clears the NEW queue please experiment and report bugs if it is
>> > not working.
>> 
>> Do you think you could upload this to unstable?
>
> Can you confirm that, when you install the package, it works as
> expected (for Pagure, since that is your use case) without needing any
> changes?

Yeah, I'll test here.

Thanks,

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


signature.asc
Description: PGP signature

Bug#886211: debchange: new tests fail when vendor != Debian

[Steve Langasek]

Package: devscripts
Version: 2.17.12
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu bionic ubuntu-patch

Dear maintainers,

devscripts 2.17.12 fails to build in Ubuntu because a new test enforces the
Debian vendor behavior, but does not ensure that Debian is actually set as
the vendor:

testGuessedDistribution
ASSERT:expected: but was:
[...]
ASSERT:expected: but was:
[...]
ASSERT:expected: but was:
ASSERT:expected: but was:
[...]

(https://launchpad.net/ubuntu/+source/devscripts/2.17.12/+build/14199899)

I have uploaded the attached patch to Ubuntu to fix this build failure. 
Please consider including 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 Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru devscripts-2.17.12/test/test_debchange 
devscripts-2.17.12ubuntu1/test/test_debchange
--- devscripts-2.17.12/test/test_debchange  2017-11-11 15:13:54.0 
-0800
+++ devscripts-2.17.12ubuntu1/test/test_debchange   2018-01-02 
21:03:46.0 -0800
@@ -205,9 +205,10 @@
 # $2 → action
 # $3 → expected suite after the action
 rm -f "$CHANGELOG"
-success "--create -D $1 --package test-package -v 1.0-1 'First upload'"
-success "$2 'Second Upload'"
-success "-r ''"
+vdeb="--vendor Debian"
+success "$vdeb --create -D $1 --package test-package -v 1.0-1 'First 
upload'"
+success "$vdeb $2 'Second Upload'"
+success "$vdeb -r ''"
 local dist="$(dpkg-parsechangelog -l"$CHANGELOG" -SDistribution)"
 assertEquals "$3" "$dist"
 }

Bug#884268: gdb back trace after installing libavcodec57-dbgsym

[Kingsley G. Morse Jr.]

Here's gdb's back trace of the seg fault, but
with debugging symbols for libavcodec57.

-- 
Time is the fire in which we all burn.
#0  move_audio (sf_size=, venc=0x9e40ddc0) at 
src/libavcodec/vorbisenc.c:1073
save = 
input = 
len = 
cur = 0x0
frame_size = 
subframes = 
sf = 0
ch = 0
#1  vorbis_encode_frame (avctx=0x9e40d380, avpkt=0x9ed9ce94, frame=0x9e4708a0, 
got_packet_ptr=0x9ed9ce88)
at src/libavcodec/vorbisenc.c:1124
venc = 0x9e40ddc0
i = 
ret = 
frame_size = 1024
mode = 
mapping = 
pb = {bit_buf = 0, bit_left = -1208666538, buf = 0x4 , 
  buf_ptr = 0xb7f53c8c  
"\203\304\020\203\304\034\061\300[^_]Í\264&", 
  buf_end = 0x8000 "\177ELF\001\001\001", size_in_bits = 0}
#2  0xabd8ffa4 in avcodec_encode_audio2 (avctx=, 
avpkt=, frame=0x9e4708a0, 
got_packet_ptr=) at src/libavcodec/encode.c:198
extended_frame = 
padded_frame = 0x0
ret = 
user_pkt = 
needs_realloc = 
#3  0xb2005f23 in consumer_thread (arg=0x80770710) at consumer_avformat.c:1622
p = 0x912a6030
got_packet = 0
ret = 
stream = 0x9e40d0a0
codec = 0x9e40d380
pkt = {buf = 0x0, pts = -9223372036854775808, dts = 
-9223372036854775808, data = 0x9e400480 "", size = 43008, 
  stream_index = 0, flags = 0, side_data = 0x0, side_data_elems = 0, 
duration = 0, pos = -1, convergence_duration = 0}
j = 0
n = 
consumer = 0x80770710
properties = 0x80770710
terminate_on_pause = 1
terminated = 0
real_time_output = -1
ante = {tv_sec = 1514957417, tv_usec = 124160}
fps = 25
width = 1920
height = 1080
img_width = 1920
img_height = 1080
channels = 2
total_channels = 2
frequency = 48000
pcm = 0x950298e0
samples = 64
audio_outbuf = 0x9e400480 ""
audio_input_nb_samples = 64
frame_count = 1
video_outbuf = 0x9a3ff020 "P\222\r\235\001*\200\a8\004"
frame = 0x0
frame_properties = 
queue = 0x8076ecd0
fifo = 0x9e40bb88
image = 0x925f8030 
"\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200\020\200"...
img_fmt = mlt_image_yuv422
converted_avframe = 
audio_avframe = 0x9e4708a0
video_avframe = 0x9e40cf00
audio_buf_1 = 0x9a343020 ""
audio_buf_2 = 0x0
count = 1
oc = 0x9e40b080
video_st = 0x9e40bc60
audio_st = {0x9e40d0a0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}
audio_pts = 0.02
video_pts = 0.040001
frames = 1
total_time = 39562
fmt = 0xabb53c40 
filename = 0x9e40acd8 "/home/kingsley/tmp/test.webm"
format = 
vcodec = 
acodec = 
audio_codec = 
video_codec = 
audio_codec_id = 86021
video_codec_id = 
key = "channels.7", '\000' 
frame_meta_properties = 0x9e40ad00
error_count = 0
sample_count = {1024, 0, 0, 0, 0, 0, 0, 0}
header_written = 1
i = 0
aud_fmt = mlt_audio_f32le
sample_bytes = 4
#4  0xb7f2c32d in start_thread (arg=0x9ed9db40) at pthread_create.c:456
__res = 
pd = 0x9ed9db40
now = 
unwind_buf = {cancel_jmp_buf = {{jmp_buf = {-1208741888, -1629889728, 
-1629889728, -1629891544, 435968905, 1340044251}, 
  mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = 
{prev = 0x0, cleanup = 0x0, canceltype = 0}}}
not_first_call = 0
#5  0xb7e54616 in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:110
No locals.

Bug#882934: pcb-gtk crash

[Dima Kogan]

Hi.

Let's try to get to the bottom of this. Are you still experiencing the
crash?

My suspicion is that you have some shared library installed that's
incompatible with some other component. You say you upgrade the whole
system regularly?

I'd like to see the list of shared libraries your pcb-gtk is depending
on. What does this say:

  ldd /usr/bin/pcb-gtk

It'd also be interesting to get the list of all the packages that
provide those dependencies. What does this say:

  ldd /usr/bin/pcb-gtk | awk '{print $3}' | sort | uniq | xargs dpkg -S | awk 
-F: '!/diversion/ {print $1}' | xargs dpkg -l

Past that, I'd like to get a core. If that doesn't work, we can bring
out bigger guns, but hopefully this would be enough. Please do this:

1. ulimit -c unlimited
2. cat /proc/sys/kernel/core_pattern
   This should be "core" or "core.something". If it isn't, please write
   "core" into that file, as root. This is non-permanent and would be
   reset to whatever it was when you reboot.
3. In the same shell, invoke pcb-gtk, and trigger the crash

The kernel should dump a file named "core" into your current directory.
If I could get a copy of that file, that'd be very useful. It might be
quite large so maybe emailing that wouldn't be ideal. Maybe hold off on
this, and just send me the output of the two ldd commands above.

Thanks much for helping us debug!

dima

Bug#880036: avahi: FTBFS: dh_systemd_start: Could not open avahai-daemon.socket

[Steve Langasek]

Package: avahi
Followup-For: Bug #880036
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu bionic ubuntu-patch

Hello,

I agree with the analysis given at .

The fix for this build failure is straightforward; just drop the Also= line,
which is not needed and has wrong side-effects.

The attached patch, which implements this, has been uploaded to Ubuntu. 
Please consider applying it to 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 Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru avahi-0.7/debian/patches/no-systemd-also.patch 
avahi-0.7/debian/patches/no-systemd-also.patch
--- avahi-0.7/debian/patches/no-systemd-also.patch  1969-12-31 
16:00:00.0 -0800
+++ avahi-0.7/debian/patches/no-systemd-also.patch  2018-01-02 
17:27:56.0 -0800
@@ -0,0 +1,18 @@
+Description: Don't use 'Also=' in dnsconfd systemd unit
+ 'Also=avahi-daemon.socket' means that 'systemctl disable avahi-dnsconfd'
+ will also disable avahi-daemon.socket, which is definitely not what we
+ want, and it also causes debhelper to throw an error.  Just drop this entry
+ from the configuration.
+Author: Steve Langasek 
+Last-Modified: 2018-01-02 20:30:00 -0800
+Bug-Debian: https://bugs.debian.org/878911
+
+Index: avahi-0.7-3ubuntu1/avahi-dnsconfd/avahi-dnsconfd.service.in
+===
+--- avahi-0.7-3ubuntu1.orig/avahi-dnsconfd/avahi-dnsconfd.service.in
 avahi-0.7-3ubuntu1/avahi-dnsconfd/avahi-dnsconfd.service.in
+@@ -26,4 +26,3 @@
+ 
+ [Install]
+ WantedBy=multi-user.target
+-Also=avahi-daemon.socket
diff -Nru avahi-0.7/debian/patches/series avahi-0.7/debian/patches/series
--- avahi-0.7/debian/patches/series 2017-09-18 14:25:27.0 -0700
+++ avahi-0.7/debian/patches/series 2018-01-02 17:27:56.0 -0800
@@ -1,3 +1,4 @@
 fix-manpage-install-conditions.patch
 man-add-missing-bshell.1-symlink.patch
 man-fix-reference-to-avahi-autoipd.action-8-in-avahi-auto.patch
+no-systemd-also.patch

Bug#885626: QScintilla2 Transition Started

[Scott Kitterman]

Now that qscintilla2 2.10.2 is in unstable, your package no longer builds, so 
I've just raised the bug to severity serious.  If you haven't already, please 
let me know if you intend to upload, otherwise I'll NMU in the next few days.

Scott K

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

Bug#886210: Downgrade "old-standards-version" to an info

[Steve M. Robbins]

Package: lintian
Version: 2.5.66
Severity: normal

I agree with suggestion by Niels Thykier (on debian-devel):

Andrey Rahmatullin:
> On Mon, Jan 01, 2018 at 05:26:35PM +, Sean Whitton wrote:
>> IMO the point of the field is to ensure that you /don't/ have to upgrade
>> to the latest version of Policy right away.  It allows you to keep track
>> of the version of Policy you are up-to-date with, so you can do it
>> later/someone more interested in the changes can do it.
>>
>> I think that Lintian shouldn't warn about not using the latest
>> Standards-Version; perhaps it should warn when you're using a really old
>> one.

This would just be a question of turning down the warning for
"old-standards-version" to an info.  We have a separate warning
(ancient-standards-version) that triggers when your S-V is (currently) 2
years behind.

IOW, trivially doable in lintian, please file a bug if you want this.


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

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

Versions of packages lintian depends on:
ii  binutils  2.29.1-12
ii  bzip2 1.0.6-8.1
ii  diffstat  1.61-1+b1
ii  dpkg  1.19.0.4
ii  file  1:5.32-1
ii  gettext   0.19.8.1-4
ii  intltool-debian   0.35.0+20060710.4
ii  libapt-pkg-perl   0.1.33
ii  libarchive-zip-perl   1.60-1
ii  libclass-accessor-perl0.51-1
ii  libclone-perl 0.39-1
ii  libdpkg-perl  1.19.0.4
ii  libemail-valid-perl   1.202-1
ii  libfile-basedir-perl  0.07-1
ii  libipc-run-perl   0.96-1
ii  liblist-moreutils-perl0.416-1+b3
ii  libparse-debianchangelog-perl 1.2.0-12
ii  libperl5.24 [libdigest-sha-perl]  5.24.1-7
ii  libperl5.26 [libdigest-sha-perl]  5.26.1-3
ii  libtext-levenshtein-perl  0.13-1
ii  libtimedate-perl  2.3000-2
ii  liburi-perl   1.72-2
ii  libxml-simple-perl2.24-1
ii  libyaml-libyaml-perl  0.63-2+b2
ii  man-db2.7.6.1-4
ii  patchutils0.3.4-2
ii  perl  5.26.1-3
ii  t1utils   1.41-2
ii  xz-utils  5.2.2-1.3

Versions of packages lintian recommends:
ii  libperlio-gzip-perl  0.19-1+b4

Versions of packages lintian suggests:
pn  binutils-multiarch 
ii  dpkg-dev   1.19.0.4
ii  libhtml-parser-perl3.72-3+b2
ii  libtext-template-perl  1.47-1

-- no debconf information

Bug#885631: [pkg-lxqt-devel] Bug#885631: src:juffed: Will FTBFS with new qscintilla2

[Scott Kitterman]

On Thursday, December 28, 2017 07:15:22 PM Alf Gaida wrote:
> What ever you prefer - i can apply the patch so the package just need to
> be uploaded when qupzilla hit sid.

The new qscintilla2 is in Sid and built on all release archs, so please go 
ahead ASAP.

Scott K

Bug#836408: ITP: jquery-caret.js -- library to query input caret position

[Ben Finney]

On 02-Jan-2018, Sergio Durigan Junior wrote:
> On Sunday, December 11 2016, Ben Finney wrote:
> > I am still not clear about how this is meant to be used, so after
> > it clears the NEW queue please experiment and report bugs if it is
> > not working.
> 
> Do you think you could upload this to unstable?

Can you confirm that, when you install the package, it works as
expected (for Pagure, since that is your use case) without needing any
changes?

-- 
 \  “As the evening sky faded from a salmon color to a sort of |
  `\   flint gray, I thought back to the salmon I caught that morning, |
_o__)and how gray he was, and how I named him Flint.” —Jack Handey |
Ben Finney 


signature.asc
Description: PGP signature

Bug#886205: wdm: French debconf translation update

[Axel Beckert]

Control: tag -1 + pending

Hi,

Alban Vidal wrote:
> Please find attached the French debconf templates update, proofread
> by the debian-l10n-french mailing list contributors.

Appreciated and applied, thanks!

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

Bug#886209: FTBFS: configure: error: please install and enable pecl/raphf

[Adam Borowski]

Source: php-pecl-http
Version: 3.1.0+2.6.0-4
Severity: serious
Justification: fails to build from source (but built successfully in the past)

Hi!
I'm afraid your package fails to build on current unstable:

checking whether ext/raphf is enabled... no
configure: error: please install and enable pecl/raphf
cd build-7.1 && tail -v -n \+0 config.log
==> config.log <==

Tried on armhf amd64.  Log attached.


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

Kernel: Linux 4.15.0-rc6-00023-g1414bf97abd7 (SMP w/4 CPU cores; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)


php-pecl-http_armhf.build
Description: inode/symlink

Bug#886207: magnum: French debconf translation update

[Alban Vidal]

Package: magnum
Version: 5.0.1-2
Severity: wishlist
Tags: patch l10n

Dear Maintainer,

Please find attached the French debconf templates update, proofread by the
debian-l10n-french mailing list contributors.

Best regards,

Alban Vidal
# Translation of magnum debconf templates to French.
# Copyright (C) 2013, 2015, 2017, French l10n team 

# This file is distributed under the same license as the MAGNUM package.
#
# Translators:
# Julien Patriarca , 2013.
# Jean-Pierre Giraud , 2015.
# Alban Vidal , 2017.
msgid ""
msgstr ""
"Project-Id-Version: magnum 5.0.1-2\n"
"Report-Msgid-Bugs-To: mag...@packages.debian.org\n"
"POT-Creation-Date: 2016-03-29 13:38+\n"
"PO-Revision-Date: 2017-12-31 10:40+0100\n"
"Last-Translator: Alban Vidal \n"
"Language-Team: French \n"
"Language: fr\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"X-Generator: Lokalize 2.0\n"
"Plural-Forms: nplurals=2; plural=(n > 1);\n"

#. Type: boolean
#. Description
#: ../magnum-common.templates:2001
msgid "Set up a database for Magnum?"
msgstr "Voulez-vous installer une base de données pour Magnum ?"

#. Type: boolean
#. Description
#: ../magnum-common.templates:2001
msgid ""
"No database has been set up for Magnum to use. Before continuing, you should "
"make sure you have the following information:"
msgstr ""
"Aucune base de données n’est configurée que Magnum puisse utiliser. Avant de "
"continuer, assurez-vous de disposer des informations suivantes :"

#. Type: boolean
#. Description
#: ../magnum-common.templates:2001
msgid ""
" * the type of database that you want to use;\n"
" * the database server hostname (that server must allow TCP connections from "
"this\n"
"   machine);\n"
" * a username and password to access the database."
msgstr ""
" — le type de base de données que vous souhaitez utiliser ;\n"
" — le nom d'hôte du serveur de base de données (ce serveur doit accepter les "
"connexions TCP depuis cette machine) ;\n"
" — un nom d'utilisateur et un mot de passe pour accéder à cette base de "
"données."

#. Type: boolean
#. Description
#: ../magnum-common.templates:2001
msgid ""
"If some of these requirements are missing, do not choose this option and run "
"with regular SQLite support."
msgstr ""
"Si certains de ces prérequis sont manquants, ignorez cette option et "
"exécutez l'application avec la prise en charge de SQLite standard."

#. Type: boolean
#. Description
#: ../magnum-common.templates:2001
msgid ""
"You can change this setting later on by running \"dpkg-reconfigure -plow "
"magnum-common\"."
msgstr ""
"Vous pouvez modifier ce réglage plus tard en lançant « dpkg-reconfigure -"
"plow magnum-common »."

#. Type: string
#. Description
#: ../magnum-common.templates:3001
msgid "Authentication server hostname:"
msgstr "Nom d'hôte du serveur d'authentification :"

#. Type: string
#. Description
#: ../magnum-common.templates:3001
msgid ""
"Please specify the hostname of the authentication server. Typically this is "
"also the hostname of the OpenStack Identity Service (Keystone)."
msgstr ""
"Veuillez indiquer le nom d'hôte du serveur d'authentification. En général, "
"il s'agit du nom d'hôte du Service d'Identité d'OpenStack (Keystone)."

#. Type: string
#. Description
#. Translators: a "tenant" in OpenStack world is
#. an entity that contains one or more username/password couples.
#. It's typically the tenant that will be used for billing. Having more than one
#. username/password is very helpful in larger organization.
#. You're advised to either keep "tenant" without translating it
#. or keep it aside with your translation. Example for French:
#. proprietaire ("tenant")
#: ../magnum-common.templates:4001
msgid "Authentication server tenant name:"
msgstr "Nom du projet (« tenant ») sur le serveur d'authentification :"

#. Type: string
#. Description
#. Translators: a "tenant" in OpenStack world is
#. an entity that contains one or more username/password couples.
#. It's typically the tenant that will be used for billing. Having more than one
#. username/password is very helpful in larger organization.
#. You're advised to either keep "tenant" without translating it
#. or keep it aside with your translation. Example for French:
#. proprietaire ("tenant")
#: ../magnum-common.templates:4001
msgid "Please specify the authentication server tenant name."
msgstr ""
"Veuillez indiquer le nom du projet (« tenant ») sur le serveur "
"d’authentification."

#. Type: string
#. Description
#: ../magnum-common.templates:5001
msgid "Authentication server username:"
msgstr "Nom d'utilisateur pour le serveur d'authentification :"

#. Type: string
#. Description
#: ../magnum-common.templates:5001
msgid "Please specify the username to use with the authentication server."
msgstr ""
"Veuillez indiquer le nom d'utilisateur 

Bug#886206: openstack-trove: French debconf translation update

[Alban Vidal]

Package: openstack-trove
Version: 1_8.0.0-2
Severity: wishlist
Tags: patch l10n

Dear Maintainer,

Please find attached the French debconf templates update, proofread by the
debian-l10n-french mailing list contributors.

Best regards,

Alban Vidal
# Translation of trove debconf templates to french
# Copyright (C) 2013, 2017, French l10n team 

# This file is distributed under the same license as the trove package.
#
# Translators:
# Julien Patriarca , 2013.
# Alban Vidal , 2017.
msgid ""
msgstr ""
"Project-Id-Version: trove 1_8.0.0-2\n"
"Report-Msgid-Bugs-To: openstack-tr...@packages.debian.org\n"
"POT-Creation-Date: 2016-03-31 10:25+0200\n"
"PO-Revision-Date: 2017-12-31 10:24+0100\n"
"Last-Translator: Alban Vidal \n"
"Language-Team: French \n"
"Language: fr\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Plural-Forms: nplurals=2; plural=(n > 1);\n"
"X-Generator: Lokalize 2.0\n"

#. Type: boolean
#. Description
#: ../trove-api.templates:2001
#| msgid "Register Glance in the Keystone endpoint catalog?"
msgid "Register Trove in the Keystone endpoint catalog?"
msgstr ""
"Voulez-vous enregistrer Trove dans le catalogue de points d'accès de "
"Keystone ?"

#. Type: boolean
#. Description
#: ../trove-api.templates:2001
msgid ""
"Each OpenStack service (each API) should be registered in order to be "
"accessible. This is done using \"keystone service-create\" and \"keystone "
"endpoint-create\". This can be done automatically now."
msgstr ""
"Chaque service d'OpenStack (chaque API) doit être enregistré pour être "
"accessible. Cela peut être fait en utilisant « keystone service-create » et "
"« keystone endpoint-create ». Cela peut être fait automatiquement maintenant."

#. Type: boolean
#. Description
#: ../trove-api.templates:2001
#| msgid ""
#| "Note that you will need to have an up and running Keystone server on "
#| "which to connect using the Keystone authentication token."
msgid ""
"Note that you will need to have an up and running Keystone server on which "
"to connect using a known admin project name, admin username and password. "
"The admin auth token is not used anymore."
msgstr ""
"Veuillez noter que vous aurez besoin d'un serveur Keystone fonctionnel sur "
"lequel vous pouvez vous connecter en utilisant un nom de projet connu "
"d'administrateur, le nom d'utilisateur de l'administrateur ainsi que son mot "
"de passe. Le jeton d'authentification d'administration n'est plus utilisé."

#. Type: string
#. Description
#: ../trove-api.templates:3001
msgid "Keystone server IP address:"
msgstr "Adresse IP du serveur Keystone :"

#. Type: string
#. Description
#: ../trove-api.templates:3001
#| msgid ""
#| "Please enter the IP address of the Keystone server, so that trove-api can "
#| "contact Keystone to do the Glance service and endpoint creation."
msgid ""
"Please enter the IP address of the Keystone server, so that trove-api can "
"contact Keystone to do the Trove service and endpoint creation."
msgstr ""
"Veuillez indiquer l'adresse IP du serveur Keystone, pour que l'API de Trove "
"puisse contacter Keystone pour établir le service Trove et créer le point "
"d'accès."

#. Type: string
#. Description
#: ../trove-api.templates:4001
#| msgid "Keystone authentication token:"
msgid "Keystone admin name:"
msgstr "Nom de l'administrateur de Keystone :"

#. Type: string
#. Description
#. Type: string
#. Description
#. Type: password
#. Description
#: ../trove-api.templates:4001 ../trove-api.templates:5001
#: ../trove-api.templates:6001
msgid ""
"To register the service endpoint, this package needs to know the Admin "
"login, name, project name, and password to the Keystone server."
msgstr ""
"Pour enregistrer le service de point d'accès, ce paquet a besoin de "
"connaître le nom de connexion de l'administrateur, son nom, le nom du "
"projet, ainsi que le mot de passe du serveur Keystone."

#. Type: string
#. Description
#: ../trove-api.templates:5001
msgid "Keystone admin project name:"
msgstr "Nom du projet de l'administrateur de Keystone :"

#. Type: password
#. Description
#: ../trove-api.templates:6001
msgid "Keystone admin password:"
msgstr "Mot de passe de l'administrateur de Keystone :"

#. Type: string
#. Description
#: ../trove-api.templates:7001
#| msgid "Glance endpoint IP address:"
msgid "Trove endpoint IP address:"
msgstr "Adresse IP du point d'accès Trove :"

#. Type: string
#. Description
#: ../trove-api.templates:7001
#| msgid "Please enter the IP address that will be used to contact Glance."
msgid "Please enter the IP address that will be used to contact Trove."
msgstr "Veuillez indiquer l'adresse IP qui sera utilisée pour contacter Trove."

#. Type: string
#. Description
#: ../trove-api.templates:7001
msgid ""
"This IP address should be accessible from the clients that will use this "

Bug#886208: nova: French debconf translation update

[Alban Vidal]

Package: nova
Version: 2_16.0.3-4
Severity: wishlist
Tags: patch l10n

Dear Maintainer,

Please find attached the French debconf templates update, proofread by the
debian-l10n-french mailing list contributors.

Best regards,

Alban Vidal
# Translation of nova debconf templates to french.
# Copyright (C) 2012-2014, 2017, French l10n team 

# This file is distributed under the same license as the nova package.
#
# Translators:
# Julien Patriarca , 2012-2014.
# Alban Vidal , 2017.
msgid ""
msgstr ""
"Project-Id-Version: nova 2_16.0.3-4\n"
"Report-Msgid-Bugs-To: n...@packages.debian.org\n"
"POT-Creation-Date: 2017-10-26 22:06+\n"
"PO-Revision-Date: 2017-12-28 12:42+0100\n"
"Last-Translator: Alban Vidal \n"
"Language-Team: French \n"
"Language: fr\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"X-Generator: Lokalize 2.0\n"
"Plural-Forms: nplurals=2; plural=(n > 1);\n"

#. Type: string
#. Description
#: ../nova-common.templates:2001
msgid "Auth server hostname:"
msgstr "Nom d'hôte du serveur d'authentification :"

#. Type: string
#. Description
#: ../nova-common.templates:2001
msgid ""
"Please specify the URL of your Nova authentication server. Typically this is "
"also the URL of your OpenStack Identity Service (Keystone)."
msgstr ""
"Veuillez indiquer l'adresse URL du serveur d'authentification Nova. En "
"général, il s'agit également de l'adresse URL du Service d'Identité "
"d'OpenStack (Keystone)."

#. Type: string
#. Description
#: ../nova-common.templates:3001
msgid "Auth server tenant name:"
msgstr "Nom du projet (« tenant ») sur le serveur d'authentification :"

#. Type: string
#. Description
#: ../nova-common.templates:4001
msgid "Auth server username:"
msgstr "Nom d'utilisateur pour le serveur d'authentification :"

#. Type: password
#. Description
#: ../nova-common.templates:5001
msgid "Auth server password:"
msgstr "Mot de passe pour le serveur d'authentification :"

#. Type: boolean
#. Description
#: ../nova-common.templates:6001
msgid "Set up a database for Nova?"
msgstr "Voulez-vous installer une base de données pour Nova ?"

#. Type: boolean
#. Description
#: ../nova-common.templates:6001 ../nova-api.templates:8001
msgid ""
"No database has been set up for Nova to use. If you want to set one up now, "
"please make sure you have all needed information:"
msgstr ""
"Aucune base de données n’est configurée que Nova puisse utiliser. Si vous "
"voulez en configurer une maintenant, assurez-vous de disposer des "
"informations suivantes :"

#. Type: boolean
#. Description
#: ../nova-common.templates:6001 ../nova-api.templates:8001
msgid ""
" * the host name of the database server (which must allow TCP\n"
"   connections from this machine);\n"
" * a username and password to access the database;\n"
" * the type of database management software you want to use."
msgstr ""
" – le nom d'hôte du serveur de bases de données (qui doit autoriser les "
"connexions TCP depuis cette machine) ;\n"
" – un nom d'utilisateur et un mot de passe pour accéder à la base de "
"données ;\n"
" – le type de gestionnaire de base de données que vous souhaitez utiliser."

#. Type: boolean
#. Description
#: ../nova-common.templates:6001 ../nova-api.templates:8001
msgid ""
"If you don't choose this option, no database will be set up and Nova will "
"use regular SQLite support."
msgstr ""
"Si vous ne choisissez pas cette option, aucune base de données ne sera "
"installée et Nova utilisera la prise en charge de SQLite standard."

#. Type: boolean
#. Description
#: ../nova-common.templates:6001
msgid ""
"You can change this setting later on by running \"dpkg-reconfigure -plow "
"nova-common\"."
msgstr ""
"Vous pouvez modifier ce réglage plus tard en lançant « dpkg-reconfigure -"
"plow nova-common »."

#. Type: multiselect
#. Description
#: ../nova-common.templates:7001
msgid "API to activate:"
msgstr "API à activer :"

#. Type: multiselect
#. Description
#: ../nova-common.templates:7001
msgid ""
"Openstack Nova supports different API services, each of them binding on a "
"different port. Select which one nova-api should support."
msgstr ""
"OpenStack Nova prend en charge différents services d'API, chacun d'entre eux "
"relié à un port différent. Veuillez choisir quelle API Nova devra utiliser."

#. Type: multiselect
#. Description
#: ../nova-common.templates:7001
msgid ""
"If it is a compute node that you are setting-up, then you only need to run "
"the metadata API server. If you run Cinder, then you don't need osapi_volume "
"(you cannot run osapi_volume and cinder-api on the same server: they bind on "
"the same port)."
msgstr ""
"Dans le cas de l'installation d'un nœud de calcul, il suffit de lancer le "
"serveur d'API de métadonnées. Si vous utilisez Cinder, vous n'avez pas "
"besoin d'osapi_volume (vous ne pouvez pas lancer 

Bug#886205: wdm: French debconf translation update

[Alban Vidal]

Package: wdm
Version: 1.28-22
Severity: wishlist
Tags: patch l10n

Dear Maintainer,

Please find attached the French debconf templates update, proofread by the
debian-l10n-french mailing list contributors.

Best regards,

Alban Vidal
# Translation of wdm debconf templates to French.
# Copyright (C) 2003, 2017, French l10n team 

# This file is distributed under the same license as the wdm package.
#
# Translators:
# Jean-Christophe Dubacq , 2003.
# Alban Vidal , 2017.
msgid ""
msgstr ""
"Project-Id-Version: wdm 1.28-22\n"
"Report-Msgid-Bugs-To: w...@packages.debian.org\n"
"POT-Creation-Date: 2017-10-08 21:22+0200\n"
"PO-Revision-Date: 2017-12-31 10:50+0100\n"
"Last-Translator: Alban Vidal \n"
"Language-Team: French \n"
"Language: fr\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Plural-Forms: nplurals=2; plural=(n > 1);\n"
"X-Generator: Lokalize 2.0\n"

#. Type: select
#. Description
#: ../templates:1001
#| msgid "Select the desired default display manager."
msgid "Desired default display manager."
msgstr "Choix du gestionnaire de session par défaut :"

#. Type: select
#. Description
#: ../templates:1001
msgid ""
"A display manager is a program that provides graphical login capabilities "
"for the X Window System."
msgstr ""
"Un gestionnaire de session est un programme qui fournit une fenêtre de "
"connexion graphique pour le système de fenêtrage X."

#. Type: select
#. Description
#: ../templates:1001
msgid ""
"Only one display manager can manage a given X server, but multiple display "
"manager packages are installed.  Please select which display manager should "
"run by default."
msgstr ""
"Un seul gestionnaire de session peut gérer un serveur X donné, mais "
"plusieurs paquets de gestionnaire de session sont installés. Veuillez "
"sélectionner le gestionnaire de session que vous souhaitez lancer par "
"défaut."

#. Type: select
#. Description
#: ../templates:1001
msgid ""
"(Multiple display managers can run simultaneously if they are configured to "
"manage different servers; to achieve this, configure the display managers "
"accordingly, edit each of their init scripts in /etc/init.d, and disable the "
"check for a default display manager.)"
msgstr ""
"Plusieurs gestionnaires de session peuvent être démarrés en même temps s'ils "
"sont configurés pour gérer des serveurs différents. Pour cela, configurez "
"les gestionnaires de session en conséquence, pour chacun d'entre eux éditez "
"le script d'initialisation présent dans /etc/init.d, et désactivez la "
"vérification de gestionnaire de session par défaut."

#~ msgid "${choices}"
#~ msgstr "${choices}"

Bug#886204: FTBFS: Vector.h:251:64: error: no matching function for call

[Adam Borowski]

Source: android-platform-build
Version: 1:7.0.0+r33-1
Severity: serious
Justification: fails to build from source (but built successfully in the past)

Hi!
I'm afraid your package fails to build on current unstable:

In file included from tools/zipalign/ZipFile.h:24:0,
 from tools/zipalign/ZipAlign.cpp:20:
/usr/include/android/utils/Vector.h: In member function 'const 
android::Vector& android::Vector::operator=(const 
android::Vector&) const':
/usr/include/android/utils/Vector.h:251:64: error: no matching function for 
call to 'android::Vector::operator=(const android::VectorImpl&) const'
 VectorImpl::operator = (static_cast(rhs));
^
See also https://bugs.debian.org/886122 in android-platform-frameworks-base

Tried on armhf amd64.  Log attached.


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

Kernel: Linux 4.15.0-rc6-00023-g1414bf97abd7 (SMP w/4 CPU cores; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)


android-platform-build_armhf.build
Description: inode/symlink

Bug#886203: FTBFS: dh: unable to load addon scour

[Adam Borowski]

Source: wavbreaker
Version: 0.11-1
Severity: serious
Justification: fails to build from source (but built successfully in the past)

Hi!
I'm afraid that your package fails to build on current unstable:

dh clean --parallel --with=autotools_dev,scour
dh: Compatibility levels before 9 are deprecated (level 7 in use)
dh: The autotools-dev sequence is deprecated and replaced by dh in debhelper 
(>= 9.20160115)
dh: This feature will be removed in compat 12.
dh: unable to load addon scour: Can't locate Debian/Debhelper/Sequence/scour.pm 
in @INC (you may need to install t
he Debian::Debhelper::Sequence::scour module) (@INC contains: /etc/perl 
/usr/local/lib/arm-linux-gnueabihf/perl/5.
26.1 /usr/local/share/perl/5.26.1 /usr/lib/arm-linux-gnueabihf/perl5/5.26 
/usr/share/perl5 /usr/lib/arm-linux-gnue
abihf/perl/5.26 /usr/share/perl/5.26 /usr/local/lib/site_perl 
/usr/lib/arm-linux-gnueabihf/perl-base) at (eval 3) 
line 1.
BEGIN failed--compilation aborted at (eval 3) line 1.

Tried on armhf amd64.  Log attached.


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

Kernel: Linux 4.15.0-rc6-00023-g1414bf97abd7 (SMP w/4 CPU cores; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)


wavbreaker_armhf.build
Description: inode/symlink

Bug#886202: FTBFS: chown: cannot access '.../fcoll_8cpp__incl.dot': No such file or directory

[Adam Borowski]

Source: zipios++
Version: 0.1.5.9+cvs.2007.04.28-10
Severity: serious
Justification: fails to build from source

Hi!
I'm afraid your package fails to build on current unstable:

   dh_fixperms
chown: cannot access 
'debian/libzipios++-doc/usr/share/doc/libzipios++-doc/html/fcoll_8cpp__incl.dot':
 No such file or directory
dh_fixperms: find debian/libzipios++-doc -true -print0 2>/dev/null | xargs -0r 
chown --no-dereference 0:0 returned exit code 123
dh_fixperms: Aborting due to earlier error

Tried on armhf amd64.  Log attached.


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

Kernel: Linux 4.15.0-rc6-00023-g1414bf97abd7 (SMP w/4 CPU cores; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Bug#886201: libffi: mips/ffi.c fix jr encoding for r6

[YunQiang Su]

Package: src:libffi
Version: 3.2.1-7

in mips/ffi.c, there are some binary encoding for some instructions,
while `jr' changes its encoding.

https://github.com/libffi/libffi/pull/401

-- 
YunQiang Su

Bug#886200: FTBFS: XPA$ERROR: invalid host name specified: $host:$port.

[Adam Borowski]

Source: xpa
Version: 2.1.18-3
Severity: serious
Justification: fails to build from source (but built successfully in the past)

Hi!
I'm afraid your package fails to build on current unstable:

debian/tests/xpa_test_build
XPA$ERROR: invalid host name specified: $host:$port.
XPA$ERROR no 'xpaset' access points match template: xpa
debian/rules:17: recipe for target 'override_dh_auto_test' failed

Tried on armhf amd64.  Log attached.


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

Kernel: Linux 4.15.0-rc6-00023-g1414bf97abd7 (SMP w/4 CPU cores; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)


xpa_armhf.build
Description: inode/symlink

Bug#886153: anything-el: A stale file lock of anything-c-adaptive-history breaks emacs batch processing

[H.-Dirk Schmitt]

On Di, 2018-01-02 at 20:09 -0400, David Bremner wrote:
> David Bremner  writes:
> 
> On the other hand, if I uncomment the (require 'anything-startup) in
> /etc/emacs/site-start.d/50anything-el.el, then I can duplicate the
> hanging of emacs -q -batch.

Seem to be the point.

I look in /etc/emacs/site-start.d/50anything-el.el
and see the line:

> ;; (require 'anything-startup)

I'm a bit confused why it is not commented out in your version of the
file ?

Bug#836408: ITP: jquery-caret.js -- library to query input caret position

[Sergio Durigan Junior]

On Sunday, December 11 2016, Ben Finney wrote:

> Control: tags -1 + pending
>
> On 04-Sep-2016, Ben Finney wrote:
>
>> I have a complete package for this, and am interested to know whether
>> it meets the need of dependent packages
>
> This is now uploaded to ‘experimental’ at version “0.3.1+dfsg.1-1”. As
> of this writing it is waiting in the NEW queue.
>
> I am still not clear about how this is meant to be used, so after it
> clears the NEW queue please experiment and report bugs if it is not
> working.

Hey Ben,

Do you think you could upload this to unstable?  pagure still needs this
dependency, and it won't build right now because the package is in
experimental.

Thanks,

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


signature.asc
Description: PGP signature

Bug#886154: gnome-shell: segfault in libgobject

[Kjö Hansi Glaz]

Hi again

Simon McVittie:
> On Tue, 02 Jan 2018 at 19:03:12 +0100, Kjö Hansi Glaz wrote:
>> On the journal, I see:
>>
>> janv. 02 15:10:59 debian kernel: gnome-shell[2009]: segfault at 1b 
>> ip 7f775a314da2 sp 7ffc562f53a0 error 4 in libgobject-2.0.
> 
> Is there anything else at a nearby timestamp in the Journal? I'd expect
> to see messages logged from at least Xwayland, followed by all your
> applications crashing as they lose their Wayland or X11 displays. Any
> useful information here would be within a few seconds before or after
> the segfault.

Here it is:

janv. 02 19:18:20 debian gnome-shell[1981]: invalid unclassed pointer in
cast to 'ClutterText'
janv. 02 19:18:20 debian gnome-shell[1981]: clutter_text_get_editable:
assertion 'CLUTTER_IS_TEXT (self)' failed
janv. 02 19:18:20 debian gnome-shell[1981]: clutter_text_get_text:
assertion 'CLUTTER_IS_TEXT (self)' failed
janv. 02 19:18:20 debian gnome-shell[1981]: clutter_text_set_text:
assertion 'CLUTTER_IS_TEXT (self)' failed
janv. 02 19:18:20 debian gnome-shell[1981]: clutter_content_invalidate:
assertion 'CLUTTER_IS_CONTENT (content)' failed
janv. 02 19:18:25 debian gnome-shell[1981]: invalid unclassed pointer in
cast to 'ClutterText'
janv. 02 19:18:25 debian gnome-shell[1981]: clutter_text_get_editable:
assertion 'CLUTTER_IS_TEXT (self)' failed
janv. 02 19:18:25 debian gnome-shell[1981]: clutter_text_get_text:
assertion 'CLUTTER_IS_TEXT (self)' failed
janv. 02 19:18:25 debian gnome-shell[1981]: clutter_text_set_text:
assertion 'CLUTTER_IS_TEXT (self)' failed
janv. 02 19:18:25 debian gnome-shell[1981]: clutter_content_invalidate:
assertion 'CLUTTER_IS_CONTENT (content)' failed

These happen every 5 seconds and doesn't seem related to the crash.

janv. 02 19:18:30 debian kernel: gnome-shell[1981]: segfault at 60 ip
7fe7ba4d0da2 sp 7fff897c1cb0 error 4 in libgobject-2.0.so.0.540
janv. 02 19:18:30 debian systemd[1]: Created slice
system-systemd\x2dcoredump.slice.
janv. 02 19:18:30 debian systemd[1]: Started Process Core Dump (PID
21041/UID 0).
janv. 02 19:18:32 debian gnome-terminal-[11504]: Error reading events
from display: Connexion ré-initialisée par le correspondant
janv. 02 19:18:32 debian gnome-calendar[19855]: Error reading events
from display: Relais brisé (pipe)
janv. 02 19:18:32 debian nautilus[18249]: Error reading events from
display: Relais brisé (pipe)
janv. 02 19:18:32 debian evolution-alarm[2270]: Error reading events
from display: Relais brisé (pipe)
janv. 02 19:18:32 debian parcimonie-appl[2279]: Error reading events
from display: Relais brisé (pipe)
janv. 02 19:18:32 debian systemd[1929]: gnome-terminal-server.service:
Main process exited, code=exited, status=1/FAILURE
janv. 02 19:18:32 debian systemd[1929]: gnome-terminal-server.service:
Failed with result 'exit-code'.
janv. 02 19:18:32 debian org.gnome.Shell.desktop[1981]: (EE)
janv. 02 19:18:32 debian org.gnome.Shell.desktop[1981]: Fatal server error:
janv. 02 19:18:32 debian org.gnome.Shell.desktop[1981]: (EE) failed to
read Wayland events: Connection reset by peer
janv. 02 19:18:32 debian org.gnome.Shell.desktop[1981]: (EE)
janv. 02 19:18:32 debian gnome-session[1950]:
gnome-session-binary[1950]: WARNING: Application
'org.gnome.Shell.desktop' killed by signal 11
janv. 02 19:18:32 debian polkitd(authority=local)[983]: Unregistered
Authentication Agent for unix-session:1 (system bus name :1.36, object p
janv. 02 19:18:32 debian gedit[18518]: Error reading events from
display: Relais brisé (pipe)
janv. 02 19:18:32 debian gnome-session-binary[1950]: WARNING:
Application 'org.gnome.Shell.desktop' killed by signal 11
janv. 02 19:18:32 debian gnome-session-binary[1950]: Unrecoverable
failure in required component org.gnome.Shell.desktop
janv. 02 19:18:32 debian libvirtd[1101]: 2018-01-02 18:18:32.249+:
1101: error : virNetSocketReadWire:1810 : End of file while reading da
janv. 02 19:18:32 debian sudo[20902]: pam_unix(sudo:session): session
closed for user root
janv. 02 19:18:32 debian pulseaudio[2060]: ICE default IO error handler
doing an exit(), pid = 2060, errno = 11
janv. 02 19:18:32 debian thunderbird.desktop[19178]:
xcb_connection_has_error() a retourné une valeur true
janv. 02 19:18:32 debian audit[19178]: AVC apparmor="DENIED"
operation="open" profile="thunderbird"
name="/etc/pulse/client.conf.d/00-disable
janv. 02 19:18:32 debian upowerd[1985]: unhandled action 'unbind' on
/sys/devices/pci:00/:00:14.0/usb3/3-1/3-1:1.0
janv. 02 19:18:32 debian bluetoothd[1544]: Endpoint unregistered:
sender=:1.41 path=/MediaEndpoint/A2DPSource
janv. 02 19:18:32 debian bluetoothd[1544]: Endpoint unregistered:
sender=:1.41 path=/MediaEndpoint/A2DPSink
janv. 02 19:18:32 debian systemd[1929]: pulseaudio.service: Main process
exited, code=exited, status=1/FAILURE
janv. 02 19:18:32 debian systemd[1929]: pulseaudio.service: Failed with
result 'exit-code'.
janv. 02 19:18:32 debian gsd-rfkill[2150]: g_object_notify: object class
'CcRfkillGlib' has no property 

Bug#886024: split off anything-el related part

[H.-Dirk Schmitt]

On Mi, 2018-01-03 at 02:06 +0200, era eriksson wrote:
> Code outline for an emacs batch wrapper
   

I do not insist on bash – you are free to fix it in any programming
language ;-)



-- 




  
  

  Signature H.-Dirk Schmitt



  

  

  H.-Dirk Schmitt
  

  Dipl.Math.

  eMail:dirk.schm...@computer42.org
  

  mobile:+49 177 616 8564
  

  phone: +49 2642 99 41 14
  

  fax: +49 2642 99 41 15
  

  Schillerstr. 42, D-53489 Sinzig

  pgp: http://www.computer42.org/~dirk/OpenPGP-fingerprint.html

Bug#886199: keybinder-3.0: Please upgrade to 0.3.2

[Jeremy Bicha]

Source: keybinder-3.0
Version: 0.3.1-1
Severity: wishlist

Please upgrade to 0.3.2.

https://github.com/kupferlauncher/keybinder/blob/master/NEWS

Thanks,
Jeremy Bicha

Bug#886198: streamtuner: Depends on unmaintained pygtk

[Jeremy Bicha]

Source: streamtuner2
Version: 2.2.0-2
Severity: serious
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: oldlibs pygtk
Tags: sid buster

pygtk is unmaintained upstream. It has not had a release since GNOME 3
was released in 2011.

The way forward is to port your app to use GObject Introspection
bindings (and gtk3).

For more information on GObject Introspection see [1] and [2].

Please try to do this before the Buster release as we're going to
try to remove pygtk this cycle.

If you have any question don't hesitate to ask.

[1] https://wiki.gnome.org/Projects/GObjectIntrospection
[2] https://wiki.gnome.org/Projects/PyGObject

On behalf of the Debian GNOME team,
Jeremy Bicha

Bug#881985: [request-tracker-maintainers] Bug#881985: request-tracker4: Correctly set RT version in configure if a Debian epoch is used

[Andrew Ruthven]

Update patch to only strip the epoch off the version is attached.
-- 
Andrew Ruthven, Wellington, New Zealand
Data Centre Manager
MIITP

At work: andrew.ruth...@catalyst.net.nz
At home: and...@etc.gen.nz
Card   : http://qr.catalyst.net.nz/907675e1
Cloud  : NZs only real cloud - https://catalyst.net.nz/cloud
GPG fpr: C603 FC4E 600F 1CEC D1C8  D97C 4B53 D931 E4D3 E863
LCA2018: Just a little bit of history repeating - http://linux.conf.au
--- debian/patches/debianize_version.diff	2017-08-30 07:05:39.0 +1200
+++ ../rt-patches/debianize_version.diff	2018-01-03 14:22:22.964614844 +1300
@@ -6,6 +6,9 @@
 Also make clear in the web interface that this version number is from
 Debian.
 
+Updated to strip any epoch off the version. Commands taken from
+/usr/share/dpkg/pkg-info.mk .
+
 Patch-Name: debianize_version.diff
 ---
  configure.ac   | 8 
@@ -21,7 +24,7 @@
  dnl Setup autoconf
  AC_PREREQ([2.53])
 -AC_INIT(RT, m4_esyscmd([( git describe --tags || cat ./.tag 2> /dev/null || echo "rt-3.9.EXPORTED" )| tr -d "\n"]), [rt-b...@bestpractical.com])
-+AC_INIT(RT, m4_esyscmd([( dpkg-parsechangelog -SVersion )| tr -d "\n"]), [https://www.debian.org/Bugs/Reporting])
++AC_INIT(RT, m4_esyscmd([( dpkg-parsechangelog -SVersion | sed -e 's/^[0-9]*://' )| tr -d "\n"]), [https://www.debian.org/Bugs/Reporting])
  AC_CONFIG_SRCDIR([lib/RT.pm])
  
  dnl Save our incant early since $@ gets overwritten by some macros.

Bug#790176: guake: depends on vte which is deprecated

[Jeremy Bicha]

Control: forwarded -1 https://github.com/Guake/guake/issues/1009

Bug#884632: rtv crashes when viewing submission

[Josue Ortega]

On Sun, Dec 17, 2017 at 03:43:09PM -0500, Legimet wrote:
> Package: rtv
> Version: 1.14.1+dfsg-1
> Severity: important
> Tags: upstream
> 
> Dear Maintainer,
> 
> The version of rtv in stretch crashes whenever trying to view a
> submission, making this package unusable. This was fixed
> upstream: https://github.com/michael-lazar/rtv/issues/462
> 
> -- System Information:
> Debian Release: 9.3
>   APT prefers stable-updates
>   APT policy: (500, 'stable-updates'), (500, 'stable')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 4.9.0-4-amd64 (SMP w/4 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 /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> 
> Versions of packages rtv depends on:
> ii  python33.5.3-1
> ii  python3-bs44.5.3-1
> ii  python3-decorator  4.0.11-1
> ii  python3-kitchen1.2.4-2
> ii  python3-praw   3.3.0-1
> ii  python3-requests   2.12.4-1
> ii  python3-six1.10.0-3
> 
> rtv recommends no packages.
> 
> rtv suggests no packages.
> 
> -- no debconf information

Hi Legimet,

I will upload the upstream version 1.19 to stretch-backports by now.

My plan is to patch the current version in Stretch and include it in
some point release.

Regards

---
Josue Ortega
«Happy Hacking»
http://josueortega.org

signature.asc
Description: PGP signature

Bug#875615: please document that --digest-algo must be used to sign

[Lionel Vaux]

Package: apt
Version: 1.4.8
Followup-For: Bug #875615

Hi,

I have the same problem, not using a homemade repo, but using that for Epson
printer drivers [1]. Running apt-get update leads to the following error:

W: GPG error: http://download.ebz.epson.net/dsc/op/stable/debian lsb3.2
Release: The following signatures were invalid:
E5220FB7014D0FBDA50DFC2BE5E86C008AA65D56
W: The repository 'http://download.ebz.epson.net/dsc/op/stable/debian lsb3.2
Release' is not signed.
N: Data from such a repository can't be authenticated and is therefore
potentially dangerous to use.
N: See apt-secure(8) manpage for repository creation and user configuration
details.

I have check that the signature was OK (although the key from Epson uses
dsa1024). I have also checked using strace that the call to gpgv from apt-get
resulted in a VALIDSIG.
Here is the relevant part:

[pid 16805] execve("/usr/bin/gpgv", ["gpgv", "--homedir", "/tmp/apt-key-
gpghome.sxAuZhFxxd", "--keyring", "/tmp/apt-key-
gpghome.sxAuZhFxxd/pubring.gpg", "--ignore-time-conflict", "--status-fd", "3",
"/var/lib/apt/lists/partial/download.ebz.epson.net_dsc_op_stable_debian_dists_lsb3.2_Release.gpg",
"/var/lib/apt/lists/download.ebz.epson.net_dsc_op_stable_debian_dists_lsb3.2_Release"],
[/* 22 vars */]) = 0
[pid 16805] write(3, "[GNUPG:] KEY_CONSIDERED
E5220FB7014D0FBDA50DFC2BE5E86C008AA65D56 0\n", 67) = 67
[pid 16805] write(3, "[GNUPG:] SIG_ID
S+6Mraiq7SfaBNvnalpm+mH2OwI 2014-07-22 1406003740\n", 66) = 66
[pid 16805] write(3, "[GNUPG:] KEY_CONSIDERED
E5220FB7014D0FBDA50DFC2BE5E86C008AA65D56 0\n", 67) = 67
[pid 16805] write(3, "[GNUPG:] GOODSIG E5E86C008AA65D56 Seiko
Epson Corporation (Epson Inkjet Printer Driver) \n", 119) = 119
[pid 16805] write(3, "[GNUPG:] VALIDSIG
E5220FB7014D0FBDA50DFC2BE5E86C008AA65D56 2014-07-22 1406003740 0 4 0 17 2 00
E5220FB7014D0FBDA50DFC2BE5E86C008"..., 136) = 136

I guess there is an additional requirement, other than the signature being
valid.

Best,
L.


[1] http://download.ebz.epson.net/dsc/op/stable/debian/dists/lsb3.2/



-- Package-specific info:

-- apt-config dump --

APT "";
APT::Architecture "amd64";
APT::Build-Essential "";
APT::Build-Essential:: "build-essential";
APT::Install-Recommends "1";
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\.8\.0-0\.bpo\.2-amd64$";
APT::NeverAutoRemove:: "^linux-image-4\.9\.0-4-amd64$";
APT::NeverAutoRemove:: "^linux-headers-4\.8\.0-0\.bpo\.2-amd64$";
APT::NeverAutoRemove:: "^linux-headers-4\.9\.0-4-amd64$";
APT::NeverAutoRemove:: "^linux-image-extra-4\.8\.0-0\.bpo\.2-amd64$";
APT::NeverAutoRemove:: "^linux-image-extra-4\.9\.0-4-amd64$";
APT::NeverAutoRemove:: "^linux-signed-image-4\.8\.0-0\.bpo\.2-amd64$";
APT::NeverAutoRemove:: "^linux-signed-image-4\.9\.0-4-amd64$";
APT::NeverAutoRemove:: "^kfreebsd-image-4\.8\.0-0\.bpo\.2-amd64$";
APT::NeverAutoRemove:: "^kfreebsd-image-4\.9\.0-4-amd64$";
APT::NeverAutoRemove:: "^kfreebsd-headers-4\.8\.0-0\.bpo\.2-amd64$";
APT::NeverAutoRemove:: "^kfreebsd-headers-4\.9\.0-4-amd64$";
APT::NeverAutoRemove:: "^gnumach-image-4\.8\.0-0\.bpo\.2-amd64$";
APT::NeverAutoRemove:: "^gnumach-image-4\.9\.0-4-amd64$";
APT::NeverAutoRemove:: "^.*-modules-4\.8\.0-0\.bpo\.2-amd64$";
APT::NeverAutoRemove:: "^.*-modules-4\.9\.0-4-amd64$";
APT::NeverAutoRemove:: "^.*-kernel-4\.8\.0-0\.bpo\.2-amd64$";
APT::NeverAutoRemove:: "^.*-kernel-4\.9\.0-4-amd64$";
APT::NeverAutoRemove:: "^linux-backports-modules-.*-4\.8\.0-0\.bpo\.2-amd64$";
APT::NeverAutoRemove:: "^linux-backports-modules-.*-4\.9\.0-4-amd64$";
APT::NeverAutoRemove:: "^linux-tools-4\.8\.0-0\.bpo\.2-amd64$";
APT::NeverAutoRemove:: "^linux-tools-4\.9\.0-4-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";

Bug#885954: cenon.app: \r in filename in .orig tarball

[Adam Borowski]

On Wed, Jan 03, 2018 at 02:48:22AM +0200, Yavor Doganov wrote:
> On Mon, 01 Jan 2018 00:55:00 +0200,
> Adam Borowski wrote:
> > Source: cenon.app
> > Version: 4.0.2-1
> 
> > There are two files with \r in name in the tarball:
> > tar: Cenon/Cenon.xcodeproj/Icon\r: Cannot open: Permission denied
> > tar: Cenon/Cenon.xcodeproj/Icon\r: Cannot open: Permission denied
> > Note that this already confuses tar!
> 
> Hmm, I'm afraid that I can't reproduce this with tar/1.29b-2.  Perhaps
> that's something specific to your environment or filesystem?  I tried
> both with dpkg-source and tar and I get no errors/warnings.

Yeah, as I mentioned, the kernel has a patch that bans control characters in
file names -- they can be used for security bugs (at least '\n') or to play
nasty with the user (01..31), and unlike other nastiness such as invalid
Unicode, controls have no known legitimate use in the wild.

> There is one file (not two) with \r under Cenon.xcodeproj.  I guess
> it's automatically created by XCode (proprietary IDE for Muck OS X) so
> I suspect it's never going to be fixed upstream.
> 
> I'll repackage the tarball, removing the entire directory, but I'd
> like to postpone this for the next upsteam release (4.0.6).  It can't
> be uploaded right now because it depends on a new gnustep-gui method
> that is available in 0.26, so it'll be after the (forthcoming)
> gnustep-gui transition.  (Unless the current version fails to build
> with -gui/0.26, of course.)  OK?

No hurry; the security module is not even written yet (current patches were
NACKed and I was told to reimplement them as a LSM, which I did not get
around to doing yet), so it'll be a while until this hits Debian.

> I use the opportunity to thank you wholeheartedly for sponsoring
> basically all of my uploads recently.

Looks like Gianfranco just got back, he tends to overdo me by a factor of
2-3.  At least I used his absence to rack up some score :)

> > However, I'm developing a security module that bans problematic
> > filenames, and in the configuration I'd like to recommend for
> > distributions to default to, \r is forbidden.
> 
> Are there any plans this to be enforced or at least recommended in
> Debian distro-wide?  (Just asking out of curiosity.)

This tends to take a few years.  With my simple hard-coded approach
rejected, it'll be a LSM, and those, even after being accepted, usually get
enabled by only "hardened" distros and Gentooites for a while, then by
mainstream distros, only then possibly becoming kernel default.

I'm filing bugs already only because it'll make my Big Plot For World
Domination easier -- changes like this are far more likely to get accepted
if I can claim I did an archive rebuild and it doesn't break anything
anymore.


Meow!
-- 
// If you believe in so-called "intellectual property", please immediately
// cease using counterfeit alphabets.  Instead, contact the nearest temple
// of Amon, whose priests will provide you with scribal services for all
// your writing needs, for Reasonable And Non-Discriminatory prices.

Bug#886157: pristine-tar should sign git commits if enabled in git

[Mattia Rizzolo]

On Tue, Jan 02, 2018 at 07:12:52PM +0100, Guido Günther wrote:
> There are several issues here so let's split them:

right, thanks for cloning!

> Try pristine-tar without using gpg and it will not sign your commit so
> this should _also_ be filed against pristine-tar (so cloning this
> report)

In the case pristine-tar is using `git commit-tree` as well, that might
actually be the same being dealt with at #886061.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#886061: git-buildpackage: import-orig doesn't sign anymore commits on non-master branches

[Mattia Rizzolo]

On Tue, Jan 02, 2018 at 10:58:13AM -0800, Jonathan Nieder wrote:
> 
> > The option is called commit.gpgsign not commit.pgpsign (according to
> > "man git-config")…

Right, sorry for mistyping this.

> > …and it doesn't affect git-commit-tree, that's why "gbp import-orig" is
> > unaffected
> 
> This behavior is intentional.  Often convenience features like this
> one are provided in user-facing commands (like "git commit") and not
> scripting commands (like "git commit-tree").  Part of that is because
> it is easier to understand the intent behind a user calling a
> user-facing command.  When a script calls a command like commit-tree,
> we don't have information about the higher-level operation that this
> was a component of, so we err on the side of predictability.

ACK, that makes sense.

> Could "gbp import-orig" gain a --sign-commits option to allow a user
> to explicitly indicate whether they want to pass --gpg-sign to
> commit-tree?  That way, the user intent is clearer.  Making it default
> to true when commit.gpgsign would make sense in that context.

I'm happy to tweak my own configuration, to add or change something in
either ~/.gitconfig or ~/.gbp.conf.

> Despite how it may seem from the above comments, I am not completely
> sure about whether "git commit-tree" should default to --gpg-sign when
> commit.gpgsign is set.

Also, isn't commit-tree configurable at all?  git-commit-tree(1) doesn't
mention any configuration item, and neither does the zsh autocompletion.
Having a commit-tree.gpgsign config item (defaulting to the value of
commit.gpgsign, IMHO, but not necessarily) would definitly cover this
bug report.

> It's possible that there's a use case that
> would warrant it.  But for this particular use case, passing the
> option explicitly from "gbp import-orig" seems preferable.

Right, it probably makes sense for gbp to do something clever here.

Anyway, as I said I'd call myself happy with whatever solution that
doesn't make me pass extra manual flags, tweaking user configuration
files of any kind is fine :)


Anyway, did something changed behaviour "recently"?  Like gbp starting
to use commit-tree instead of commit?

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#886190: RFS: zapping/0.10~cvs6-13 [QA] [RC]

[Yavor Doganov]

Adam Borowski wrote:
> > * Package name : zapping
> >   Version  : 0.10~cvs6-13

> Alas, still fails on i386.  Log attached.

That's the old version (-12) according to the log.  I tested -13 on
i386 before uploading to mentors and it builds successfully.

Bug#886196: src:openscad: QScintilla2 -dev packages renamed, please update build-depends

[Scott Kitterman]

Package: src:openscad
Version: 2015.03-2+dfsg-2
Severity: normal

Dear Maintainer,

In the transition that has just started, libqt5scintilla2-dev has been renamed
libqscintilla2-qt5-dev to match upstream changes.  libqscintilla2-qt5-dev
provides libqt5scintilla2-dev, so your package won't immediately FTBFS, but it
would be good to update the build-depends in your next upload.

If you plan an upload soon, please let us know so that we con't binNMU the
package and save the buildd time of doing it twice.

Thanks,

Scott K

Bug#886195: src:octave: QScintilla2 -dev packages renamed, please update build-depends

[Scott Kitterman]

Package: src:octave
Version: 4.2.1-4
Severity: normal

Dear Maintainer,

In the transition that has just started, libqt5scintilla2-dev has been renamed
libqscintilla2-qt5-dev to match upstream changes.  libqscintilla2-qt5-dev
provides libqt5scintilla2-dev, so your package won't immediately FTBFS, but it
would be good to update the build-depends in your next upload.

If you plan an upload soon, please let us know so that we con't binNMU the
package and save the buildd time of doing it twice.

Thanks,

Scott K

Bug#886197: ITP: node-js-cookie -- Lightweight JavaScript cookie API

[Daniel Ring]

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

* Package name: node-js-cookie
  Version : 2.2.0
  Upstream Author : Klaus Hartl
* URL : https://github.com/js-cookie/js-cookie
* License : Expat
  Programming Lang: JavaScript
  Description : Lightweight JavaScript cookie API

 JS-Cookie is a simple, lightweight JavaScript API for handling cookies. It
 supports JSON data, custom encodings, and standard JavaScript module loaders.
 .
 Node.js is an event-based server-side JavaScript engine.

Bug#886194: src:qgis: QScintilla2 -dev packages renamed, please update build-depends

[Scott Kitterman]

Package: src:qgis
Version: 2.14.21+dfsg-1
Severity: normal

Dear Maintainer,

In the transition that has just started, libqscintilla2-dev has been renamed
libqscintilla2-qt4-dev to match upstream changes.  libqscintilla2-qt4-dev
provides libqscintilla2-dev, so your package won't immediately FTBFS, but it
would be good to update the build-depends in your next upload.

If you plan an upload soon, please let us know so that we con't binNMU the
package and save the buildd time of doing it twice.

Thanks,

Scott K

Bug#886190: RFS: zapping/0.10~cvs6-13 [QA] [RC]

[Adam Borowski]

On Wed, Jan 03, 2018 at 12:53:41AM +0200, Yavor Doganov wrote:
> 
> I'm looking for a sponsor for the orphaned package "zapping".  I
> introduced a FTBFS bug in my previous upload; a oneliner fixes it.
> 
> * Package name : zapping
>   Version  : 0.10~cvs6-13

> Changes since the last upload:
> 
>   * QA upload.
>   * debian/patches/15-Misc-warnings.patch: Fix conflicting function
> declaration which led to FTBFS on a bunch of architectures.

Alas, still fails on i386.  Log attached.


Meow!
-- 
// If you believe in so-called "intellectual property", please immediately
// cease using counterfeit alphabets.  Instead, contact the nearest temple
// of Amon, whose priests will provide you with scribal services for all
// your writing needs, for Reasonable And Non-Discriminatory prices.


zapping_i386.build.xz
Description: application/xz

Bug#886193: src:codequery: QScintilla2 -dev packages renamed, please update build-depends

[Scott Kitterman]

Package: src:codequery
Version: 0.21.0+dfsg1-1
Severity: normal

Dear Maintainer,

In the transition that has just started, libqscintilla2-dev has been renamed
libqscintilla2-qt4-dev to match upstream changes.  libqscintilla2-qt4-dev
provides libqscintilla2-dev, so your package won't immediately FTBFS, but it
would be good to update the build-depends in your next upload.

If you plan an upload soon, please let us know so that we con't binNMU the
package and save the buildd time of doing it twice.

Thanks,

Scott K

Bug#885954: cenon.app: \r in filename in .orig tarball

[Yavor Doganov]

On Mon, 01 Jan 2018 00:55:00 +0200,
Adam Borowski wrote:
> Source: cenon.app
> Version: 4.0.2-1

> There are two files with \r in name in the tarball:
> tar: Cenon/Cenon.xcodeproj/Icon\r: Cannot open: Permission denied
> tar: Cenon/Cenon.xcodeproj/Icon\r: Cannot open: Permission denied
> Note that this already confuses tar!

Hmm, I'm afraid that I can't reproduce this with tar/1.29b-2.  Perhaps
that's something specific to your environment or filesystem?  I tried
both with dpkg-source and tar and I get no errors/warnings.

There is one file (not two) with \r under Cenon.xcodeproj.  I guess
it's automatically created by XCode (proprietary IDE for Muck OS X) so
I suspect it's never going to be fixed upstream.

I'll repackage the tarball, removing the entire directory, but I'd
like to postpone this for the next upsteam release (4.0.6).  It can't
be uploaded right now because it depends on a new gnustep-gui method
that is available in 0.26, so it'll be after the (forthcoming)
gnustep-gui transition.  (Unless the current version fails to build
with -gui/0.26, of course.)  OK?

I use the opportunity to thank you wholeheartedly for sponsoring
basically all of my uploads recently.

> However, I'm developing a security module that bans problematic
> filenames, and in the configuration I'd like to recommend for
> distributions to default to, \r is forbidden.

Are there any plans this to be enforced or at least recommended in
Debian distro-wide?  (Just asking out of curiosity.)

Bug#877450: RFS: bash-completion/1:2.7-1 [ITA]

[Gabriel F. T. Gomes]

The repository for the packaging of bash-completion is now hosted on
https://salsa.debian.org/debian/bash-completion/

The latest commit is not on the master branch, but on

https://salsa.debian.org/debian/bash-completion/commits/unstable

Mentors has been updated with a new build:

https://mentors.debian.net/package/bash-completion

Thank you all for the feedback! :)


pgpxqnnB3rK5T.pgp
Description: OpenPGP digital signature

Bug#885775: [pkg-apparmor] Bug#885775: It seems it is not related to apparmor

[Seth Arnold]

On Sun, Dec 31, 2017 at 08:19:06AM +0200, Laszlo KERTESZ wrote:
> So it happened again with no apparmor loaded.Twice.

Thanks for the bug report.

Are you in a position where you can run memtest86 or memtest86+ on this
system? If nothing else it might be something useful to do while hoping
someone else may spot something.

Thanks


signature.asc
Description: PGP signature

Bug#885860: wine registers mime handlers with too high priority

[Michal Suchanek]

Package: wine
Followup-For: Bug #885860

Hello,

indeed removing files previously created by wine I can no longer
reproduce the problem. I used many older versions of wine so one of them
created these files.

It is unfortunate that winemenubuilder cannot identify the old files and
remove them when updating the associations but this should not reappear
on new systems at least.

Thanks

-- Package-specific info:
/usr/bin/wine points to /usr/bin/wine-stable.

-- System Information:
Debian Release: 9.3
  APT prefers stable
  APT policy: (900, 'stable'), (505, 'oldstable'), (500, 'oldoldstable'), (500, 
'testing'), (171, 'unstable'), (151, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armhf

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

Versions of packages wine depends on:
ii  wine32  1.8.7-2
ii  wine64  1.8.7-2

wine recommends no packages.

Versions of packages wine suggests:
ii  dosbox   0.74-4.2+b2
pn  playonlinux  
pn  winbind  
ii  wine-binfmt  1.8.7-2
ii  winetricks   0.0+20170101-1

Versions of packages wine is related to:
ii  fonts-wine   1.8.7-2
ii  wine 1.8.7-2
ii  wine-development [wine]  3.0~rc1-1
ii  wine32   1.8.7-2
ii  wine64   1.8.7-2

-- no debconf information

Bug#886186: akonadi-server: akonadi server fails to start mysqld due to apparmor intervention

[Sandro Knauß]

Hey,

I can't reproduce this issue for unstable. Me having 17.08.3-1 running and 
also apparmor 2.11.1-4 (running) and everything works for me.
Maybe the path for #869865 fixes your issue too?

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=869865

hefee

> I am following debian testing and in the course of the last months have
> twice run into the following issue:
> 
> after aptitude update/full-upgrade, akonadi-server will not start.
> Running akonadictl start from the command line I spotted the failing command
> as being the  invocation of mysqld.
> 
> I cannot provide the text of the failing command here because I upgraded
> akonadi-server and apparmor to unstable to see if the problem goes away (no
> it
> doesn't) and now akonadictl keeps crashing on me
> (and if I would downgrade the data base format does not match any longer).
> apparmor and  libapparmor are at 2.11.1-4.
> 
> However, the state of my analysis is
> 
> 1. When starting kontact, akonadi fails to invoke mysqld because the
> daemon cannot open its configuration file in my home directory
> (strace). The file exists and is world-readable. The mysqld command line
> looks unsuspicious and specifies a socket (which exists), the configuration
> file and something else which I do not remember.
> 
> 2. The problem disappears after disabling apparmor (which I did not
> explicitly install, thus the bug classification as important). A
> reboot is necessary, though - probably systemctl stop apparmor is not
> sufficient to 'really' stop it.
> 
> 3. There is a configuration file for myslqd and akonadis invocation of
> mysqld in /etc/apparmor.d
> 
>usr.sbin.mysqld
>usr.sbin.myslqd-akonadi
> 
> which I did not touch, but whose correctness I cannot judge either.
> The relevant line seems to come from usr.sbin.mysqld-akonadi
> 
>@{HOME}/.local/share/akonadi/** rwk,
> 
> which feels correct, as this describes the path to my configuration file:
> 
> root@nbof16:/home/sts# ls -l .local/share/akonadi/mysql.conf
> -rw-r--r-- 1 sts sts 3531 Jan  2 21:19 .local/share/akonadi/mysql.conf
> 
> OK - this is as far as I feel able to go. Maybe some akonadi or
> apparmor specialist can take over from here?


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

Bug#832061: Please backport duc to jessie

[Louis-Philippe Véronneau]

> Would you still be interested in a jessie backport? I had forgotten I
> was also interested, but I've since upgraded my machines to current
> stable (stretch) so I'm not as invested in this anymore. I'm curious to
> test interest though.

Not anymore no. This was a while ago and my machines now all run Stretch.

As far as I'm concerned, you can close this bug.

Thanks!

-- 
pollo



signature.asc
Description: OpenPGP digital signature

Bug#886153: anything-el: A stale file lock of anything-c-adaptive-history breaks emacs batch processing

[David Bremner]

David Bremner  writes:

>> At this point the emacs is hanging.
>> Trying to answer the „lock“ prompt is not possible. You have to terminate 
>> the processing *SIGINT* (Ctrl+C) or killing it.
>
> Following your recipe, I can't duplicate this behaviour with emacs24 or 
> emacs25.

On the other hand, if I uncomment the (require 'anything-startup) in
/etc/emacs/site-start.d/50anything-el.el, then I can duplicate the
hanging of emacs -q -batch. I suspect this is actually an emacs bug, and
mostly unrelated to anything.el (except that it writes the same file
every time emacs exits, thus triggering the emacs bug).

Bug#886024: split off anything-el related part

[era eriksson]

Your emacs-batch script seems to have some issues. I have not reviewed
it properly, but e.g. your prevalent use of the declare keyword is
definitely a bashism.
More generally, making Emacs package compilation more robust  is
absolutely not a bad idea; but introducing new requirements should also
be reflected in the Emacs policy (though honestly not sure what its
current status is?)
On Tue, Jan 2, 2018, at 22:34, H.-Dirk Schmitt wrote:
> Here a simple wrapper script would help to :
> - avoid copy and paste errors
> - simplify the fix of this bug
> - simple reuse
>
>
> Code outline for an emacs batch wrapper
> 
>
> Assume a bash script *emacs_batch* replacing the `-q --batch` options.> It 
> should take as 1st option the emacs flavour (e.g. emacs25) and pass> trough 
> all other options except `-q`,
> `--no-init-file` (alias to `-q`)  and `--batch`.
>
> The emacs call could be implemented in this way:
>
> ```
> declare -r catchFile=$(mktemp)  # create temporary
> file> for output

Exit on failure; $(mktemp) || exit

> trap rm --force ${catchFile}#   and ensure cleanup
The trap declaration  seems to be wrong (the trap code needs to be a
single string and you need to specify which signals and conditions
to trap on).
> ${FLAVOUR} --batch "${cmdlineOptions[@]}" &>"${catchFile}" & #
> fork> declare -i emacsPid=$!  # and remember
> sleep ${emacsTimeOut} & # fork timeout watch
> declare -i sleepPid=$!  # and remember
> wait -n ${emacsPid} ${sleepPid} # -n  → wait for the
> next ending job
> declare -r rc=$?# don't forget the
> exit> code
> if ! $(kill ${sleepPid})

The command substitution is fishy too.I guess you mean simply

if ! kill $sleepPid

or do you actually expect kill to print something?

> then# oops run in timeout>
> … add error handling here
> else# emacs terminates
> without timeout
>cat ${catchFile} # forward console
>output>exit ${rc}   # rc is 
> originating
>from> emacs
> fi
> ```
>
> 

/* era */

--
If this were a real .signature, it would suck less.  Well, maybe not.

Bug#886173: general: ls quotes results with special characters in its output

[Russ Allbery]

mqu...@neosmart.net writes:

> In particular, `ls` output (both in regular and `-l` modes) wraps in
> single quotes the names of files that contain special characters (or, at
> least, a parenthesis), meaning its output is not an accurate reflection
> of the actual contents of the directory.

This was an upstream change in coreutils 8.25, not something specific to
Debian:

  ls now quotes file names unambiguously and appropriate for use in a shell,
  when outputting to a terminal.

Whatever one's opinion of the merits of that upstream change, I think it's
unlikely Debian will want to diverge from upstream behavior for a package
as central as coreutils and a command as central as ls.

-- 
Russ Allbery (r...@debian.org)   

Bug#886192: python-click: upstream changelog is virtually empty

[Jonas Smedegaard]

Package: python-click
Version: 6.7-2
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

$ zcat /usr/share/doc/python-click/changelog.gz
.. currentmodule:: click

.. include:: ../CHANGES

Seems the file ../CHANGES should be installed instead.

 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAlpMGlgACgkQLHwxRsGg
ASHJ0A//TBNye758ji2wcspKOtEy2nEc07mPtidEYP8vXAHMbEEBJGH4EzzTADIm
5Eq0dBOehVun8HelQuztcMldvATBf+HLNRyOA9YnRPkNQiu8Y6lCsL7bLyzwVrkk
FPfUrSJvSD3QxgmaC3VlQjOMAkIIvwJe6QyTO64jkVtmaveN7Yk+VJvSSuaEdykW
TJL9aD2TpcrK12b12K5fCTYa/dryl/hkwu/ezxsUWLbFKZIKNiwirMhDvPTqyFEM
G8srSxcg3R0Srjq2madLkGSX7WwhcfMHMuUXJJz+3k7Lp+3xYu+Xcevo0oayBDpV
WpQ12cHO32GIRPw6ZvDbZiRsRygxIvVmrk2d9GHco++VLbx1SImWlww1VlhQNbR6
yzhFG6PjY5CrjII/D942Ai7EbNC7/kgY5q8aasnK6ySgCoBuChbaCRU38AWC7SnP
pvJnEhiMHL7XwocsMk3bheDgJagcoyGp7OXyHHhwmcciwT0388luaJa5qh7vKn1/
XR7R9QcqwRvilgehhpAFn/leo+shflu9vLhFky90j2bwruDLkxUtYrYDBpFWPcWs
jkiWYPMr8TJeM38uVQ4yxwnlNJu68L4CVw+Jvqa4A1DXjploKq2sUodZda1U14ZB
FcZ18ArLOTmPH21R+FTyUunmdKVovGddsQyAE8X5wRjxZB+c06E=
=44Jn
-END PGP SIGNATURE-

Bug#885537: Bug#886121: nullmailer: cannot be installed: Broken nullmailer:amd64 Depends on systemd-sysv:amd64

[Thorsten Glaser]

Adam Borowski dixit:

>> Even worse: my usual nullmailer use case is within a(n init-less)
>> chroot, so this is completely obliterating the *one* environment
>> in which oneb@Yd want to run it.
>
>Thorsten: just curious: how do you start and keep the queue runner running
>in an init- (and thus presunably rc-)less chroot?

Normally, not at all, as the smtpd on the main system is
running and accepts all messages immediately (and queues
them itself).

bye,
//mirabilos
-- 
I believe no one can invent an algorithm. One just happens to hit upon it
when God enlightens him. Or only God invents algorithms, we merely copy them.
If you don't believe in God, just consider God as Nature if you won't deny
existence.  -- Coywolf Qi Hunt

Bug#886004: elfutils should build without -Werror

[Mark Wielaard]

On Tue, Jan 02, 2018 at 01:49:06PM +0100, Helmut Grohne wrote:
> On Tue, Jan 02, 2018 at 10:57:44AM +0100, Mark Wielaard wrote:
> > Could you please file a bug for that. I am not aware of any such issue.
> > So would like to fix it, and would if I knew about it. Thanks.
> 
> No. Matthias Klose will file them, when he considers gcc-8 ready as some
> of the gcc-8 issues are indeed compiler bugs.

That is good. I know Matthias and he does indeed report issues like these
upstream early and often.

> Reporting this issue again is useless as
> you'd have to wade through the report again figuring that it already is
> fixed and turn it into a "new upstream release please"-bug.

Don't worry too much about duplicates. You can just file it against
the debian bugtracker. I am happy to provide patches, and it is good
to know which distro is using which gcc/binutils release.

> In contrast, what we need is that essential is buildable roughly 90% of
> the time. That means you get roughly 3 days for fixing, not 3 months. In
> Debian, not upstream. This is a hard requirement or we can just stop
> doing QA as it would become infeasible.

In general, if it is a new gcc release, we will likely have seen the
issue before upstream or in another distro and can providing a patch to 
include in the debian package can normally be done in 3 days. This
is what we do with other distros too.

> We can try using jenkins.d.n resources. There I'm cross building
> elfutils for alpha, arm64, armel, armhf, i386, kfreebsd-i386, m68k,
> mips64el, mips, mipsel, nios2, powerpc, powerpcspe, ppc64, ppc64el,
> s390x, sh4, sparc, sparc64, tilegx, x32 and would like to cross build it
> for some more (including musl-linux-any, mips64r6el, ia64, sh3, hppa).

That would be nice. Note that some of those setups (particular the mips
variants) don't have upstream support yet. It would be nice to get the
Debian backend patches upstreamed before we add some of those to the CI.

> Compare to glibc maybe. glibc relates very closely to gcc, so it
> declares which compiler versions are "supported".

elfutils is a bit like glibc indeed. It gets tested against the latest
stable gcc and binutils releases in the various distros (at least those
in debian, fedora, centos through the CI) and if gcc is in stage1 then
the next version will most likely also have been checked already.

When tested a new arch/toolchain please involve upstream as soon as
possible. We really are interested. And would like to have warning
free and zero-fail builds for all distros.

Cheers,

Mark

Bug#886191: Errors with run-vmblock\\x2dfuse.mount in install/removal scripts

[Bernd Zeimetz]

Hi Oliver,

sounds like the debhelper guys changed things in the handling of escapes
in filenames again... I'll figure it out ... again :)

Bernd


On 01/03/2018 12:19 AM, Oliver Kurth wrote:
> Package: open-vm-tools-desktop
> Version: 2:10.1.15-1
> 
> I thought there was already a bug about this in Debian. There is at
> Canonical: 
> https://bugs.launchpad.net/ubuntu/+source/open-vm-tools/+bug/1639222 .
> There is an issue on
> github: https://github.com/vmware/open-vm-tools/issues/207 .
> 
> 
> TL;DR: the unit run-vmblock\\x2dfuse.mount is neither started nor
> enabled started on install, and removing the package
> open-vm-tools-desktop fails because of errors.
> 
> 
> This is in Debian/sid, updated just today (01/02/2018):
> 
> 
> vmware@debian:~$ sudo apt-get install open-vm-tools-desktop
> ...
> Unpacking open-vm-tools (2:10.1.15-1) ...
> Selecting previously unselected package open-vm-tools-desktop.
> Preparing to unpack .../6-open-vm-tools-desktop_2%3a10.1.15-1_amd64.deb ...
> Unpacking open-vm-tools-desktop (2:10.1.15-1) ...
> ...
> Setting up open-vm-tools (2:10.1.15-1) ...
> Created symlink
> /etc/systemd/system/multi-user.target.wants/open-vm-tools.service →
> /lib/systemd/system/open-vm-tools.service.
> Created symlink
> /etc/systemd/system/open-vm-tools.service.requires/vgauth.service →
> /lib/systemd/system/vgauth.service.
> Setting up open-vm-tools-desktop (2:10.1.15-1) ...
> Failed to preset unit: Unit file run-vmblock\\x2dfuse.mount does not exist.
> /usr/bin/deb-systemd-helper: error: systemctl preset failed on
> run-vmblock\\x2dfuse.mount: No such file or directory
> Failed to get unit file state for run-vmblock\\x2dfuse.mount: No such
> file or directory
> run-vmblock\\x2dfuse.mount is a disabled or a static unit, not starting it.
> Processing triggers for libc-bin (2.25-6) ...
> Processing triggers for systemd (236-2) ...
> 
> 
> vmware@debian:~$ sudo systemctl status run-vmblock\\x2dfuse.mount
> ● run-vmblock\x2dfuse.mount - VMware vmblock fuse mount
>    Loaded: loaded (/lib/systemd/system/run-vmblock\x2dfuse.mount;
> disabled; vendor preset: enabled)
>    Active: inactive (dead)
>     Where: /run/vmblock-fuse
>      What: vmware-vmblock-fuse
>      Docs:
> https://github.com/vmware/open-vm-tools/blob/master/open-vm-tools/vmblock-fuse/design.txt
> vmware@debian:~$ sudo systemctl start run-vmblock\\x2dfuse.mount
> vmware@debian:~$ sudo systemctl status run-vmblock\\x2dfuse.mount
> ● run-vmblock\x2dfuse.mount - VMware vmblock fuse mount
>    Loaded: loaded (/lib/systemd/system/run-vmblock\x2dfuse.mount;
> disabled; vendor preset: enabled)
>    Active: active (mounted) since Tue 2018-01-02 14:35:43 PST; 1s ago
>     Where: /run/vmblock-fuse
>      What: vmware-vmblock
>      Docs:
> https://github.com/vmware/open-vm-tools/blob/master/open-vm-tools/vmblock-fuse/design.txt
>   Process: 4371 ExecMount=/bin/mount vmware-vmblock-fuse
> /run/vmblock-fuse -t fuse -o
> subtype=vmware-vmblock,default_permissions,allow_other (code=exited,
> status=0/SUCCESS)
>     Tasks: 3 (limit: 19660)
>    CGroup: /system.slice/run-vmblock\x2dfuse.mount
>            └─4375 vmware-vmblock-fuse /run/vmblock-fuse -o
> rw,subtype=vmware-vmblock,default_permissions,allow_other,dev,suid
> 
> Jan 02 14:35:43 debian systemd[1]: Mounting VMware vmblock fuse mount...
> Jan 02 14:35:43 debian systemd[1]: Mounted VMware vmblock fuse mount.
> 
> On removing the package, I see the error. open-vm-tools is removed, but
> open-vm-tools-desktop is not:
> 
> vmware@debian:~$ sudo apt-get remove open-vm-tools
> [sudo] password for vmware: 
> Reading package lists... Done
> Building dependency tree       
> Reading state information... Done
> The following packages were automatically installed and are no longer
> required:
>   ethtool libdumbnet1 libmspack0 libxmlsec1 libxmlsec1-openssl zerofree
> Use 'sudo apt autoremove' to remove them.
> The following packages will be REMOVED:
>   open-vm-tools open-vm-tools-desktop
> 0 upgraded, 0 newly installed, 2 to remove and 266 not upgraded.
> After this operation, 2,651 kB disk space will be freed.
> Do you want to continue? [Y/n] 
> (Reading database ... 147604 files and directories currently installed.)
> Removing open-vm-tools-desktop (2:10.1.15-1) ...
> Failed to stop run-vmblock\\x2dfuse.mount: Unit
> run-vmblock\\x2dfuse.mount not loaded.
> dpkg: error processing package open-vm-tools-desktop (--remove):
>  installed open-vm-tools-desktop package pre-removal script subprocess
> returned error exit status 5
> Failed to preset unit: Unit file run-vmblock\\x2dfuse.mount does not exist.
> /usr/bin/deb-systemd-helper: error: systemctl preset failed on
> run-vmblock\\x2dfuse.mount: No such file or directory
> Failed to get unit file state for run-vmblock\\x2dfuse.mount: No such
> file or directory
> run-vmblock\\x2dfuse.mount is a disabled or a static unit, not starting it.
> dpkg: open-vm-tools: dependency problems, but removing anyway as you
> requested:
>  open-vm-tools-desktop 

Bug#885042: Check inclusion of Apache 2.0 NOTICE files

[Russ Allbery]

Vincent Bernat  writes:

> There is some irony on having a warning about license.txt that shouldn't
> be in the binary copyright (because "all license information should be
> collected in the debian/copyright file") but an error when we don't copy
> the notice file.

Yeah, this provision of the Apache 2.0 license is a little weird, and I
get the impression it doesn't register with people as much as it should.
A bit like the GPL requirement to keep a changelog, which I see violated
all over the place.  (Including probably occasionally in Debian, although
normal Debian best practices with debian/changelog would satisfy it.)

Free software licenses have a lot more restrictions and specific
requirements than a lot of people realize they do, and there are a *lot*
of technical violations of free software licenses out there.

-- 
Russ Allbery (r...@debian.org)   

Bug#886191: Errors with run-vmblock\\x2dfuse.mount in install/removal scripts

[Oliver Kurth]

Package: open-vm-tools-desktop
Version: 2:10.1.15-1


I thought there was already a bug about this in Debian. There is at Canonical: 
https://bugs.launchpad.net/ubuntu/+source/open-vm-tools/+bug/1639222 . There is 
an issue on github: https://github.com/vmware/open-vm-tools/issues/207 .

TL;DR: the unit run-vmblock\\x2dfuse.mount is neither started nor enabled 
started on install, and removing the package open-vm-tools-desktop fails 
because of errors.


This is in Debian/sid, updated just today (01/02/2018):


vmware@debian:~$ sudo apt-get install open-vm-tools-desktop
...
Unpacking open-vm-tools (2:10.1.15-1) ...
Selecting previously unselected package open-vm-tools-desktop.
Preparing to unpack .../6-open-vm-tools-desktop_2%3a10.1.15-1_amd64.deb ...
Unpacking open-vm-tools-desktop (2:10.1.15-1) ...
...
Setting up open-vm-tools (2:10.1.15-1) ...
Created symlink 
/etc/systemd/system/multi-user.target.wants/open-vm-tools.service → 
/lib/systemd/system/open-vm-tools.service.
Created symlink 
/etc/systemd/system/open-vm-tools.service.requires/vgauth.service → 
/lib/systemd/system/vgauth.service.
Setting up open-vm-tools-desktop (2:10.1.15-1) ...
Failed to preset unit: Unit file run-vmblock\\x2dfuse.mount does not exist.
/usr/bin/deb-systemd-helper: error: systemctl preset failed on 
run-vmblock\\x2dfuse.mount: No such file or directory
Failed to get unit file state for run-vmblock\\x2dfuse.mount: No such file or 
directory
run-vmblock\\x2dfuse.mount is a disabled or a static unit, not starting it.
Processing triggers for libc-bin (2.25-6) ...
Processing triggers for systemd (236-2) ...


vmware@debian:~$ sudo systemctl status run-vmblock\\x2dfuse.mount
● run-vmblock\x2dfuse.mount - VMware vmblock fuse mount
   Loaded: loaded (/lib/systemd/system/run-vmblock\x2dfuse.mount; disabled; 
vendor preset: enabled)
   Active: inactive (dead)
Where: /run/vmblock-fuse
 What: vmware-vmblock-fuse
 Docs: 
https://github.com/vmware/open-vm-tools/blob/master/open-vm-tools/vmblock-fuse/design.txt
vmware@debian:~$ sudo systemctl start run-vmblock\\x2dfuse.mount
vmware@debian:~$ sudo systemctl status run-vmblock\\x2dfuse.mount
● run-vmblock\x2dfuse.mount - VMware vmblock fuse mount
   Loaded: loaded (/lib/systemd/system/run-vmblock\x2dfuse.mount; disabled; 
vendor preset: enabled)
   Active: active (mounted) since Tue 2018-01-02 14:35:43 PST; 1s ago
Where: /run/vmblock-fuse
 What: vmware-vmblock
 Docs: 
https://github.com/vmware/open-vm-tools/blob/master/open-vm-tools/vmblock-fuse/design.txt
  Process: 4371 ExecMount=/bin/mount vmware-vmblock-fuse /run/vmblock-fuse -t 
fuse -o subtype=vmware-vmblock,default_permissions,allow_other (code=exited, 
status=0/SUCCESS)
Tasks: 3 (limit: 19660)
   CGroup: /system.slice/run-vmblock\x2dfuse.mount
   └─4375 vmware-vmblock-fuse /run/vmblock-fuse -o 
rw,subtype=vmware-vmblock,default_permissions,allow_other,dev,suid

Jan 02 14:35:43 debian systemd[1]: Mounting VMware vmblock fuse mount...
Jan 02 14:35:43 debian systemd[1]: Mounted VMware vmblock fuse mount.

On removing the package, I see the error. open-vm-tools is removed, but 
open-vm-tools-desktop is not:

vmware@debian:~$ sudo apt-get remove open-vm-tools
[sudo] password for vmware:
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages were automatically installed and are no longer required:
  ethtool libdumbnet1 libmspack0 libxmlsec1 libxmlsec1-openssl zerofree
Use 'sudo apt autoremove' to remove them.
The following packages will be REMOVED:
  open-vm-tools open-vm-tools-desktop
0 upgraded, 0 newly installed, 2 to remove and 266 not upgraded.
After this operation, 2,651 kB disk space will be freed.
Do you want to continue? [Y/n]
(Reading database ... 147604 files and directories currently installed.)
Removing open-vm-tools-desktop (2:10.1.15-1) ...
Failed to stop run-vmblock\\x2dfuse.mount: Unit run-vmblock\\x2dfuse.mount not 
loaded.
dpkg: error processing package open-vm-tools-desktop (--remove):
 installed open-vm-tools-desktop package pre-removal script subprocess returned 
error exit status 5
Failed to preset unit: Unit file run-vmblock\\x2dfuse.mount does not exist.
/usr/bin/deb-systemd-helper: error: systemctl preset failed on 
run-vmblock\\x2dfuse.mount: No such file or directory
Failed to get unit file state for run-vmblock\\x2dfuse.mount: No such file or 
directory
run-vmblock\\x2dfuse.mount is a disabled or a static unit, not starting it.
dpkg: open-vm-tools: dependency problems, but removing anyway as you requested:
 open-vm-tools-desktop depends on open-vm-tools (= 2:10.1.15-1).

Removing open-vm-tools (2:10.1.15-1) ...
Errors were encountered while processing:
 open-vm-tools-desktop
E: Sub-process /usr/bin/dpkg returned an error code (1)
vmware@debian:~$ dpkg -l open-vm-tools*
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required 

Bug#868408: xnee: Please drop the (build-)dependency against gnome-vfs

[Henrik Sandklef]

On 2018-01-02 02:02, Andreas Henriksson wrote:

Hej Henrik, Vincent,

On Tue, Jan 02, 2018 at 12:11:16AM +0100, Henrik Sandklef wrote:

I have removed deps to gnomeui (gconf had already been removed) from Xnee
sources.


Vincent, please see the attached debdiff that incorporates Henriks
change as a patch in debian/patches/ for your convenience.
(You might also want to look into upgrading to a non-deprecated
debhelper compat level (apparently 5 is currently used while anything
before 9 is deprecated), etc. See also other lintian warnings.)



Can I assist you in any way?


Thanks for the offer! From my point of view it's really up to Vincent
how he wants to handle this - I just wanted to remind and point out
the urgency of this issue being resolved in any way.
Hopefully Vincent will get in touch with you if he has something
to discuss.

While poking around I noticed a couple of things which I'm just
mentioning in case it'll interest you:
- Is it true CVS is still used? (Or else I've probably looked at the
wrong upstream location)


Yes. I do not have time to maintain Xnee as I should. Switching VCS is 
not prio #1.



- I guess $(libgnomeui_LIBS) and $(libgnomeui_CFLAGS) can now also
   be dropped from gnee/src/Makefile.am (and possibly other places?)


Thanks a lot.


- Apparently configure(.in) has no check for pkg-config modules actually
   exiting (which I ran into while having pkg-config itself, but not
   gtk+-2.0.pc since the libgtk2.0-dev build-dependency was missing in
   the debian xnee package). A more obvious error message could have
   been produced by explicitly checking
   if ! $PKGCONF --exists $GTK2_MODULE >= GTK2_VERSION and erroring out.
   Even better though... (see below).



- directly invoking pkg-config is not cross compilation safe (as lintian
   points out). It would probably be better to replace all pkg-config
   usage with PKG_CHECK_MODULES macro usage instead. (And gtk-config is
   long gone so you can probably retire that code path while at it.)
   This should also give a more modern and fool-proof configure process.


See if I can squeeze these in.


The lintian report might also give you useful information:
https://lintian.debian.org/maintainer/ber...@debian.org.html#xnee_3.19-1

Med vänlig hälsning,
Andreas Henriksson


Tusen tack och gott nytt år
/henrik

Bug#885423: [Pkg-opencl-devel] Bug#885423: Beignet: self-test failed: (3, 7, 5) + (5, 7, 3) returned (6, 7, 5)

[Achim Schaefer]

Hi,
I just noticed:
now boinc does not find the GPU anymore.
This was after a restart, I don't know when I started boinc the last time.


I noticed as well I see something strange in clinfo:
clinfo
Number of platforms   1
  Platform Name   Intel Gen OCL Driver
  Platform Vendor Intel
  Platform Version    OpenCL 2.0 beignet 1.3
...
  Platform Name   Intel Gen OCL Driver
Number of devices 1
  Device Name Intel(R) HD Graphics
Haswell GT2 Desktop
...
  Device Version  OpenCL 1.2 beignet 1.3
  Driver Version  1.3
  Device OpenCL C Version OpenCL C 1.2 beignet 1.3
.. (until now everything as expected)

NULL platform behavior
(NULL?)
  clGetPlatformInfo(NULL, CL_PLATFORM_NAME, ...)  Intel Gen OCL Driver
...
ICD loader properties
...
  ICD loader Profile  OpenCL 2.2
    NOTE:   your OpenCL library declares to support OpenCL 2.2,
    but it seems to support up to OpenCL 2.1 only.
(I would expect 1.x only, haswell does not support 2.0 as far as I
remember, right?

full output attached.

Achim
On 02.01.2018 08:30, Rebecca N. Palmer wrote:
> On 01/01/18 22:38, Achim Schaefer wrote:
>> Here I see something different:
>> displacement_map_element()    [SUCCESS]
>> compiler_mandelbrot()utest_run:
>> /build/beignet-ydQSQk/beignet-1.3.2/utests/utest_helper.cpp:713: void
>> cl_write_bmp(const int*, int, int, const char*): Assertion `fp' failed.
>>  Interrupt signal (SIGABRT) received.
>
> That's not a self-test failure: it's a failure to create a file,
> possibly due to running the tests in a directory the current user
> doesn't have permission to write to.
>
> Does the original error (in darktable) still exist?
>

Number of platforms   1
  Platform Name   Intel Gen OCL Driver
  Platform Vendor Intel
  Platform VersionOpenCL 2.0 beignet 1.3
  Platform ProfileFULL_PROFILE
  Platform Extensions 
cl_khr_global_int32_base_atomics cl_khr_global_int32_extended_atomics 
cl_khr_local_int32_base_atomics cl_khr_local_int32_extended_atomics 
cl_khr_byte_addressable_store cl_khr_3d_image_writes cl_khr_image2d_from_buffer 
cl_khr_depth_images cl_khr_spir cl_khr_icd cl_intel_accelerator 
cl_intel_subgroups cl_intel_subgroups_short cl_khr_gl_sharing
  Platform Extensions function suffix Intel

  Platform Name   Intel Gen OCL Driver
Number of devices 1
  Device Name Intel(R) HD Graphics Haswell 
GT2 Desktop
  Device Vendor   Intel
  Device Vendor ID0x8086
  Device Version  OpenCL 1.2 beignet 1.3
  Driver Version  1.3
  Device OpenCL C Version OpenCL C 1.2 beignet 1.3
  Device Type GPU
  Device Profile  FULL_PROFILE
  Max compute units   20
  Max clock frequency 1000MHz
  Device Partition(core)
Max number of sub-devices 1
Supported partition types None, None, None
  Max work item dimensions3
  Max work item sizes 512x512x512
  Max work group size 512
  Preferred work group size multiple  16
  Preferred / native vector sizes 
char16 / 8   
short8 / 8   
int  4 / 4   
long 2 / 2   
half 0 / 8(n/a)
float4 / 4   
double   0 / 2(n/a)
  Half-precision Floating-point support   (n/a)
  Single-precision Floating-point support (core)
Denormals No
Infinity and NANs Yes
Round to nearest  Yes
Round to zero No
Round to infinity No
IEEE754-2008 fused multiply-add   No
Support is emulated in software   No
Correctly-rounded divide and sqrt operations 

Bug#886154: gnome-shell: segfault in libgobject

[Simon McVittie]

On Tue, 02 Jan 2018 at 19:03:12 +0100, Kjö Hansi Glaz wrote:
> On the journal, I see:
> 
> janv. 02 15:10:59 debian kernel: gnome-shell[2009]: segfault at 1b ip 
> 7f775a314da2 sp 7ffc562f53a0 error 4 in libgobject-2.0.

Is there anything else at a nearby timestamp in the Journal? I'd expect
to see messages logged from at least Xwayland, followed by all your
applications crashing as they lose their Wayland or X11 displays. Any
useful information here would be within a few seconds before or after
the segfault.

smcv

Bug#886154: more stack trace

[Simon McVittie]

On Tue, 02 Jan 2018 at 18:42:00 +, Kjö Hansi Glaz wrote:
> Actually there are two crashes, which you can find below:
> 
> $ coredumpctl | tee
> TIMEPID   UID   GID SIG COREFILE  EXE
> Tue 2018-01-02 19:18:33 CET2042  1000  1000   6 present
> /usr/bin/Xwayland
> Tue 2018-01-02 19:18:33 CET1981  1000  1000  11 present
> /usr/bin/gnome-shell

One of these probably causes the other - it'll be a bug in the error
handing code paths of either Xwayland or gnome-shell.

> #1  0x7fe7b7c65278 in st_label_set_text (label=0x558a749ee890
> [StLabel], text=0x558a772bcf90 "76") at ../src/st/st-label.c:331

Does the text "76" mean anything to you? Perhaps it's a battery level or
the name of a wireless network near you or something? That would narrow
it down a bit... it's hard to tell what caused a crash like this where
most of the stack is "interpret JavaScript".

> #23 0x7fe7b13f1040 in js::jit::InvokeFunctionInfo () at
> /usr/lib/x86_64-linux-gnu/libmozjs-52.so.0

libmozjs-52-0-dbgsym would provide more information about this part of
the stack, although it probably isn't particularly interesting.

"thread apply all bt" might also be interesting: that'll tell us which
threads were active and which were just waiting.

> #0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
> #1  0x7f080f05e19a in __GI_abort () at abort.c:89
> #2  0x5561bc7418ba in OsAbort ()
> #3  0x5561bc7473d3 in ?? ()
> #4  0x5561bc7481f5 in FatalError ()
> #5  0x5561bc5cf84f in ?? ()
> #6  0x5561bc73f371 in ?? ()
> #7  0x5561bc73835b in WaitForSomething ()
> #8  0x5561bc704193 in ?? ()
> #9  0x5561bc708410 in ?? ()
> #10 0x7f080f049561 in __libc_start_main (main=0x5561bc5cee60,
> argc=11, argv=0x7ffe218ae768, init=,
> fini=, rtld_fini=,
> stack_end=0x7ffe218ae758) at ../csu/libc-start.c:297

I think this is also missing some debug symbols, but I can't tell
which ones; perhaps xwayland-dbgsym if you don't already have that.

smcv

Bug#886190: RFS: zapping/0.10~cvs6-13 [QA] [RC]

[Yavor Doganov]

Package: sponsorship-requests
Severity: important

I'm looking for a sponsor for the orphaned package "zapping".  I
introduced a FTBFS bug in my previous upload; a oneliner fixes it.

* Package name : zapping
  Version  : 0.10~cvs6-13
  Upstream Author  : Iñaki García Etxebarria 
 Michael H. Schimek 
 and others
 * URL : http://zapping.sourceforge.net/
 * License : GPL-2
   Section : gnome

It builds this binary package:

  zapping- television viewer for the GNOME environment

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

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

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

dget -x 
https://mentors.debian.net/debian/pool/main/z/zapping/zapping_0.10~cvs6-13.dsc

Changes since the last upload:

  * QA upload.
  * debian/patches/15-Misc-warnings.patch: Fix conflicting function
declaration which led to FTBFS on a bunch of architectures.

Bug#886173: general: ls quotes results with special characters in its output

[Mahmoud Al-Qudsi]

On Tue, Jan 2, 2018 at 3:26 PM, Ben Hutchings  wrote:
> The output of ls on a terminal has never, in general, been an accurate
> reflection of the contents of a directory.  Consider that filenames can
> contain *any* byte value other than '\0' or '/', so including carriage
> return, newline, backspace and escape characters.

Yes, but those are not characters one would reasonably expect to encounter in
a filename or at least would only run into them when expecting to find them
there, whereas one may often run `ls` to see if they correctly escaped the
output of a command (for instance). Both `(` and `'` are commonly found in
document names, too.

> ls also uses multiple columns by default, but without quoting you can't
> generally tell where the columns are, e.g. is:
>
> aa  ba  ca ab  bb  cb
>
> a list of 6 two-letter filenames, or 2 filenames with spaces in, or
> something else again?

This is a carefully chosen example where all entries have the same length; in
a more realistic context, column spacing can easily be determined in the
presence of entries of varying widths. Note that I specifically pointed out
the broken behavior of `ls -l`, including the revered `ls -ahltr`

> I think that the behaviour of single-quoting is very consistent across
> shells, in part because it is specified by POSIX.

You are correct; I should have used double quotes in my example. We're all
C/C++ programmers here, single quotes are for individual characters only ;-)

> Be careful what you wish for.  But I think this will revert the recent
> change:
>
> alias ls='ls --literal'

Thanks for sharing that option, and I shall certainly make heavy use of it.

My final example which demonstrates precisely why this behavior only makes
things worse for both beginners and newcomers to the terminal alike remains
unaddressed:

```
mqudsi@buster ~> touch \'\test\(\'
mqudsi@buster ~> ls -l
-rw-r--r-- 1 mqudsi mqudsi0 Jan  2 14:22 ''\''test('\'''
```

And with regards to the following from your later message:
> You're looking for the ls --quoting-style=WORD option of ls. ls defaults
> to shell-escape if the output is a terminal, and literal otherwise.

If I may be so bold as to disagree, the outut of `ls` executed in a terminal
without and not piped to any other process, is primarily meant for human
consumption. How often does "human consumption" manifest as copy-and-paste vs
"show me the contents of this directory so I can see what it contains?"

Modern shells have solved the escaping problem by using bracketed paste mode to
trigger escaping of content pasted to the terminal. For everyone else that
doesn't need to copy-and-paste and knows offhand that typing certain
characters in a shell requires them to be escaped, that quoting behavior is
only a source of confusion. If you don't have a mouse to copy-and-paste with
(and you're not using vim/tmux or some other esoteric method of selecting text
to copy and paste to the keyboard that would take more time than actually
typing out what you see on the screen), how does this change in any way make
things better or easier?

I really do appreciate that time and effort has gone into the implementation
of this feature, and that dismissing it out of hand like this is bound to
induce a defensive reply, but I ask you to consider that I ran into this bug
within the hour of deploying debian-testing, and in almost two decades of
using everything ranging from the most popular to the most esoteric unix-like
platforms out there, I have never had reason to spend so long or put this much
effort into understanding the output of `ls` or figuring out what files I
actually had on my filesystem. I am sure that I'm not going to be the only one
that is this flummoxed when buster is released with this breaking change - and,
seriously, if the filenames output by `ls` are not held sacrosanct, what is?

Mahmoud Al-Qudsi
NeoSmart Technologies

Bug#885649: transition: src:qscintilla2

[Scott Kitterman]

On Tuesday, January 02, 2018 10:58:22 PM Emilio Pozuelo Monfort wrote:
> Control: tags -1 confirmed
> 
> On 28/12/17 22:11, Scott Kitterman wrote:
> > Package: release.debian.org
> > Severity: normal
> > User: release.debian@packages.debian.org
> > Usertags: transition
> > 
> > I've uploaded the new qscintilla2 to experimental and tested all the
> > reverse- build-depends.  Due to upstream library renaming, this requires
> > a number of sourceful uploads.  In all cases that an upload is required,
> > I've file a bug with the appropriate debdiff. There are two packages that
> > are already broken; monkeystudio is FTBFS and orphaned and ovito is FTBFS
> > unstable only.  I do not plan to touch those packages for the transition.
> > 
> > libqscintilla2-dev
> > Reverse-Build-Depends
> > =
> > * codequery - binNMU
> > * qgis - binNMU
> > * smokeqt - Upload dropping binary in unstable
> > * tora - bug filed with debdiff #885643
> > * universalindentgui - bug filed with debdiff #885647
> > 
> > libqt5scintilla2-dev
> > Reverse-Build-Depends
> > =
> > * juffed - bug filed with debdiff #885631
> > * monkeystudio - orphaned already, FTBFS already #877198
> > * octave binNMU
> > * openscad binNMU
> > * ovito configure fail - needs patch, then fails (bug already) filed new
> > bug with debdiff #885644 * sonic-pi bug filed with debdiff #885626
> > * sqlitebrowser bug filed with debdiff #885635
> 
> It looks like you are renaming the -dev packages, and the new ones provide
> the old ones. We'll need the old ones to be decrufted before we schedule
> the binNMUs, otherwise the old real packages may be installed during the
> rebuilds.
> 
> Otherwise it looks fine. Go ahead.

Thanks.  Uploaded.

Scott K

Bug#886189: recommend important plugins

[W. Martin Borgert]

Package: gajim
Version: 1.0.0~alpha2-1
Severity: wishlist

E.g. httpupload, omemo, urlimagepreview.
That's what most users want to have.

Bug#885436: /var/log/aptitude shows wrong architecture for architecture:all packages

[David Kalnischkies]

On Tue, Jan 02, 2018 at 01:11:32PM -0500, Marvin Renich wrote:
> * David Kalnischkies  [180102 06:03]:
> > On Mon, Jan 01, 2018 at 05:09:21PM -0500, Marvin Renich wrote:
> > > IOW, using pkg-name:amd64 in the log loses information that is harder to
> > > recover, while using pkg-name:all hides an internal detail of aptitude's
> > > processing that is trivial to obtain.
> > 
> > I can't argue about aptitudes log, but it sounds like it would be
> > similar to /var/log/apt/history.log in what it contains. In that log it
> > is also always pkg:native instead of pkg:all.
> 
> That seems wrong as well to me.

For apt I can decide and for apt I have to close this bugreport – you
can choose your preference between wontfix and notabug with the
reasoning following below + the usual backward compatibility reasoning
as we can't just break format.


> > I don't think "sometimes" saying pkg:all will help you much as there are
> > still the "rare" situations in which that info will be wrong as the
> > 'all' applies to the old/new version only, so you have to work with this
> > either way and it is "just" a matter of how often a certain codepath is
> > called.
> 
> Actually, it helps a great deal, even when a binary package changes
> between native and all (either way), as long as the log gives the old
> package's stated arch.  Whether changing architecture is rare or common,
> the current log entry is unhelpful, and giving the old pkg arch is
> significantly more helpful.
> 
> Determining both the new pkg arch and the native arch are trivial
> without it being stated in the log; finding the old pkg arch is
> non-trivial unless it is in the log.

Assuming the "old" version is the one you don't have information in
current Packages files for. Your tool installing the "old" version will
have this old one be the "new" one so an undo of the undo has your
problem. The "new" version being a now-disappeared version from
experimental/backports might be a slightly more realistic example of
this situation (especially for your tool I guess).


> > Perhaps it is a matter of what you are doing that you need this
> > architecture – I can only imagine it being needed to guess download URIs
> > which I consider a problem enough (mirror selection, filenames,
> > security, …) that native/all is trivial to solve (e.g. try all after
> > native failed) or is solved as by-product (for security you need indexes
> > and in those indexes the filenames are given).
> 
> You are actually proving my point.  Knowing whether to look in
> http://snapshot.debian.org/archive/debian/20171201/dists/buster/main/binary-all/
> or
> http://snapshot.debian.org/archive/debian/20171201/dists/buster/main/binary-amd64/
> to begin with is a big jump forward.  By having the package
> architecture, the URIs for both the Packages file and the .deb file are
> deterministic.  If you only have the native architecture, you have to go
> searching to figure out which package architecture is the right one.

If we assume the old package started as pkg:all and became a pkg:native
you might be right. If the package started as pkg:native and ended in
pkg:all you haven't gained anything as by your deterministic reasoning
you are looking into the wrong file.

It is actually a good idea to look into the binary-all files for the
future, but at present they aren't used by apt¹ as arch:all packages
appear in the binary-any files – so they can easily not include the
arch:all version you expect to be there (as different archs can have
different versions of arch:all packages "installed" in the archive).


¹ apt supports using the binary-all file but based on the current
Release file metadata it figures out that it would be a pointless
download. The idea is to remove arch:all eventually from the arch:any
files but not all other tools working with Packages file handle it so
far.


> The native architecture is a detail of the internal operation of
> aptitude (and apt), and does not represent how packages are stored in
> the archive or how packages are identified by users.

Well, you can just as well come from the point of view that "all" is an
implementation detail a user shouldn't be concerned with. Realistically
a user isn't identifying a package as "native" or "all". Most are
probably not identifying a package with any sort of architecture, which
is why "apt install steam" works on amd64 even if (or in fact because)
it exists only for i386. The log file will speak of steam:i386.


Best regards

David Kalnischkies


signature.asc
Description: PGP signature

Bug#885949: RM: gnome-specimen -- RoM; RoQA; depends on gnome-python

[Scott Kitterman]

On Sun, 31 Dec 2017 15:26:24 -0500 Jeremy Bicha  wrote:
> Package: ftp.debian.org
> User: release.debian@packages.debian.org
> Usertags: rm
> X-Debbugs-Cc: gnome-speci...@packages.debian.org
> 
> Please remove gnome-specimen from Debian. The Maintainer, Kartik
> Mistry, approved this request years ago in
> https://bugs.debian.org/790589 (comment 10)
> 
> It is now blocking the removal of the unmaintained gnome-python
> packages from Debian.

gnome-specimen |0.4-8.1 | source, all

Maintainer: Kartik Mistry 
Will also close bugs: 885949
Will also send CCs to: gnome-speci...@packages.debian.org, gnome-
speci...@packages.qa.debian.org
Will also close associated bug reports.

--- Reason ---
RoM; RoQA; depends on gnome-python
--

Checking reverse dependencies...
# Broken Depends:
open-font-design-toolkit: open-font-design-toolkit

Dependency problem found.

Please resolve the dependency problem and then remove the moreinfo tag.

Scott K

Bug#885704: liblept5 negatively plays with paths in /tmp when opening TIFFs

[Jeff Breidenbach]

Most likely we'll have a fix into Debian within 48 hours.

Bug#885704: liblept5 negatively plays with paths in /tmp when opening TIFFs

[Jeff Breidenbach]

I've reproduced by setting TMPDIR to /var/tmp. Talking to Leptonica author.

Bug#847984: please include SGR mouse reporting patch

[Romain Francoise]

Great news, thanks!

Bug#847984: please include SGR mouse reporting patch

[Ryan Kavanagh]

tag 847984 + upstream
thanks

Hi Romain,

Upstream has decided to implement this mode, and it should appear in the next
upstream release.

Best wishes,
Ryan

-- 
|_)|_/  Ryan Kavanagh  | GPG: 4E46 9519 ED67 7734 268F
| \| \  https://ryanak.ca/ |  BD95 8F7B F8FC 4A11 C97A


signature.asc
Description: PGP signature

Bug#885649: transition: src:qscintilla2

[Emilio Pozuelo Monfort]

Control: tags -1 confirmed

On 28/12/17 22:11, Scott Kitterman wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> 
> I've uploaded the new qscintilla2 to experimental and tested all the reverse-
> build-depends.  Due to upstream library renaming, this requires a number of
> sourceful uploads.  In all cases that an upload is required, I've file a bug
> with the appropriate debdiff. There are two packages that are already broken;
> monkeystudio is FTBFS and orphaned and ovito is FTBFS unstable only.  I do
> not plan to touch those packages for the transition.
> 
> libqscintilla2-dev
> Reverse-Build-Depends
> =
> * codequery - binNMU
> * qgis - binNMU
> * smokeqt - Upload dropping binary in unstable
> * tora - bug filed with debdiff #885643
> * universalindentgui - bug filed with debdiff #885647
> 
> libqt5scintilla2-dev
> Reverse-Build-Depends
> =
> * juffed - bug filed with debdiff #885631
> * monkeystudio - orphaned already, FTBFS already #877198
> * octave binNMU 
> * openscad binNMU
> * ovito configure fail - needs patch, then fails (bug already) filed new bug 
> with debdiff #885644 
> * sonic-pi bug filed with debdiff #885626
> * sqlitebrowser bug filed with debdiff #885635

It looks like you are renaming the -dev packages, and the new ones provide the
old ones. We'll need the old ones to be decrufted before we schedule the
binNMUs, otherwise the old real packages may be installed during the rebuilds.

Otherwise it looks fine. Go ahead.

Emilio

Bug#873480: confirming

[Daniel Kahn Gillmor]

On Tue 2018-01-02 21:35:16 +0100, Mateusz Łukasik wrote:
> On Tue, 02 Jan 2018 12:11:24 -0500 Daniel Kahn Gillmor 
>  wrote:
>  > On Tue 2018-01-02 09:33:46 +0100, Martin Bagge / brother wrote:
>  > > this issue is real. downgrading to 3.6.1-4 solves the error at hand.
>  > > that patch should be reversed and if needed reimplemented to not break
>  > > other stuff.
>  >
>  > i've just uploaded openbox 3.6.1-5.1 as an NMU with the patch from 
> Bing Xia.
>  > A debdiff is attached.
>
> NMU without ask maintainer? Nice.
>
> I add changes to my sources. Thanks for all.

thanks for taking care of this, Mateusz.

No offense was intended by the NMU, i'll be happy to see it flushed from
unstable by your replacement upload.

All the best,

  --dkg


signature.asc
Description: PGP signature

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

[Moritz Mühlenhoff]

Hi,

Sorry for the late reply, busy over the holiday season.

On Mon, Dec 18, 2017 at 12:12:08PM +0100, Raphael Hertzog wrote:
> Hi,
> 
> On Sun, 17 Dec 2017, Moritz Mühlenhoff wrote:
> > unattended-upgrades are not an appropriate default. It's okay for a desktop
> > system which gets powered down daily, so you can add it to tasksel lists for
> > desktop roles, but not enable it by default for servers.
> 
> I think it's not really useful for GNOME since it already has the required
> plumbing to install updates when you shut down.

Even more reason not to enable it if desktops are already catered for.

> > - It does not handle restarts. If you upgrade OpenSSL (or any library) with
> > it, all your services will be left vulnerable until restarted. It will
> > give people a warm fuzzy feeling, but not any actual security benefit.
> 
> Right, there are cases where a service restart is required. There are also
> many cases where it's not at all required because the library is only used
> by short-lived processes. And there are security updates of applications
> too. In all those cases, there are security benefits.

But it also provides a completely false sense of security as in "Debian takes
care of this by default, no need to bother".

> > - We do need to make the occasional breaking change where people have to
> > modify configuration settings or perform additional manual steps. With
> > unattended-upgrades people don't have a chance to intervene. And if their
> > setups break, we're the ones who get blamed.
> 
> If this is a real concern, we can maybe have some environment variable
> indicating that the upgrade is automatic without any human watching it and
> have the preinst fail?
> 
> Or we could have a way to tag such breaking upgrades and teach
> unattended-upgrades to skip them? And the unattended upgrades would notify
> the admin about the need to manually upgrade?

Possibly, yes.

> In any case, I'm not convinced that not installing updates and keeping a
> running vulnerable service is better than breaking the service and letting
> the admin fix it. If the admin is really concerned with the occasional
> breakage then he will use another process and deinstall
> unattended-upgrades.

unattended-upgrades is a crude hack at best, it's _not_ suitable for a default
installation. There might be scenarios where it's fine to apply (e.g.
in some test/staging environment or a desktop where breakage is acceptable and
where people can install unattended-upgrades), but not for Debian installations
per se.

It also totally changes the dynamics from "Debian releases updates and it's
my responsibility to test and deploy them within the parameters of my setup"
to "updates are installed by default and the inevitable random regression 
broke our systems, it's Debian's fault".

Providing security support for the biggest distro on a volunteer basis
is complex enough, no need for unattended-upgrades to interfere further.

> > Why was this change made without contacting t...@security.debian.org (as
> > the ones who are affected the most)?
> 
> Because it was largely discussed on debian-devel already and I was not
> aware that the security team had any reservation about this. I would
> rather that we keep going and improve where needed instead of reverting
> the change.

Random mailing discussions are not a useful consensus building mechanism,
most of us don't follow them on a timely basis. This primarily affects the
Security Team and such changes need to be brought to the attention of
t...@security.debian.org

Cheers,
Moritz

Bug#886153: anything-el: A stale file lock of anything-c-adaptive-history breaks emacs batch processing

[David Bremner]

H.-Dirk Schmitt  writes:


>
> Without the stale lock this command will finish after a short time.
> With the lock, you will see the following output:
>
[snip]
>> Loading 95c42_defaults (compiled; note, source file is newer)...

What's that? it doesn't look like a debian package. Does your problem
persist if you remove it?

>> Loading log-edit...
>> Trailing whitespace highlighting is now ON.
>> TAB highlighting is now ON.
>> Loading /home/dschmi/.recentf...

I guess you ran this as your user, rather than as root? It also seems odd to
me that recentf is being invoked at all.

>> Cleaning up the recentf list...
>> Cleaning up the recentf list...done (0 removed)
>> Loading /usr/local/share/emacs/site-lisp/ob-eukleides.el (source)...
>> Loading /home/dschmi/.emacs.d/anything-c-adaptive-history...

I can't understand what is loading that. The standard startup file for
anything-el just sets the load-path

>> [yas] Prepared just-in-time loading of snippets successfully.
>> Loading systemd...
>> Loading crontab-mode...
>> Loading json-mode...
>> Loading ldap-mode...
>> Loading nagios-mode...
>> Loading org-journal...
>> Loading 99c42_keymap...
>> Local Ispell dictionary set to british
>> Starting new Ispell process aspell with british dictionary...
>> ...ing-c-adaptive-history locked by xx@xx... (pid 5423): (s, q, p, 
>> ?)?
>
> At this point the emacs is hanging.
> Trying to answer the „lock“ prompt is not possible. You have to terminate the 
> processing *SIGINT* (Ctrl+C) or killing it.

Following your recipe, I can't duplicate this behaviour with emacs24 or emacs25.

Bug#886182: transition: glibc 2.26

[Emilio Pozuelo Monfort]

Control: tags -1 confirmed

On 02/01/18 22:37, Aurelien Jarno wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> 
> Dear release team,
> 
> I would like to get a transition slot for glibc 2.26. It is available in
> experimental for one month and a half, and there is no known regression.
> It has been built successfully on all release architectures, and most
> other architectures besides kfreebsd-* which do not have build daemons
> anymore. The failures on hurd-i386 and hppa are being worked on and can
> be fixed in the upload to sid or later, so I don't think we should block
> the transition on that.
> 
> As the glibc is using symbol versioning, there is no soname change. That
> said a few packages are using libc internal symbols and have to be
> rebuilt for this transition:
>  - apitrace
>  - bro
>  - dante
>  - libnih
>  - libnss-db
>  - p11-kit
>  - unscd
> 
> Here is the corresponding ben file:
>   title = "glibc";
>   is_affected = .depends ~ /libc[0-9.]* \(<   is_good = .depends ~ /libc[0-9.]* \(<< 2.27\)/;
>   is_bad = .depends ~ /libc[0-9.]* \(<< 2.26\)/;
> 
> In addition a few new symbols have been added that might prevent a few
> other packages to migrate to testing until glibc migrates if they pick
> up the new symbols. That's mostly the case for libm.so, which added
> 128-bit floating point support on amd64, i386, and ppc64el. On the
> libc.so side the new functions are reallocarray, preadv2 and pwritev2,
> which should not be widely used so far.
> 
> Thanks for considering

Please go ahead.

Emilio

Bug#886186: akonadi-server: akonadi server fails to start mysqld due to apparmor intervention

[Stefan Schwarzer]

Package: akonadi-server
Version: 4:17.08.3-1
Severity: important

Dear Maintainer,

I am following debian testing and in the course of the last months have
twice run into the following issue: 

after aptitude update/full-upgrade, akonadi-server will not start. 
Running akonadictl start from the command line I spotted the failing command
as being the  invocation of mysqld. 

I cannot provide the text of the failing command here because I upgraded 
akonadi-server
and apparmor to unstable to see if the problem goes away (no it
doesn't) and now akonadictl keeps crashing on me
(and if I would downgrade the data base format does not match any longer).
apparmor and  libapparmor are at 2.11.1-4.

However, the state of my analysis is

1. When starting kontact, akonadi fails to invoke mysqld because the
daemon cannot open its configuration file in my home directory
(strace). The file exists and is world-readable. The mysqld command line looks
unsuspicious and specifies a socket (which exists), the configuration file
and something else which I do not remember.

2. The problem disappears after disabling apparmor (which I did not
explicitly install, thus the bug classification as important). A
reboot is necessary, though - probably systemctl stop apparmor is not
sufficient to 'really' stop it.

3. There is a configuration file for myslqd and akonadis invocation of
mysqld in /etc/apparmor.d 

 usr.sbin.mysqld
 usr.sbin.myslqd-akonadi

which I did not touch, but whose correctness I cannot judge either.
The relevant line seems to come from usr.sbin.mysqld-akonadi

 @{HOME}/.local/share/akonadi/** rwk,

which feels correct, as this describes the path to my configuration file:

root@nbof16:/home/sts# ls -l .local/share/akonadi/mysql.conf 
-rw-r--r-- 1 sts sts 3531 Jan  2 21:19 .local/share/akonadi/mysql.conf

OK - this is as far as I feel able to go. Maybe some akonadi or
apparmor specialist can take over from here?


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

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

Versions of packages akonadi-server depends on:
ii  akonadi-backend-mysql  4:17.08.3-1
ii  libc6  2.25-5
ii  libgcc11:7.2.0-18
ii  libkf5akonadiprivate5  4:17.08.3-1
ii  libkf5akonadiwidgets5  4:17.08.3-1
ii  libkf5configcore5  5.37.0-2
ii  libkf5coreaddons5  5.37.0-2
ii  libkf5crash5   5.37.0-2
ii  libkf5i18n55.37.0-2
ii  libqt5core5a   5.9.2+dfsg-6
ii  libqt5dbus55.9.2+dfsg-6
ii  libqt5gui5 5.9.2+dfsg-6
ii  libqt5network5 5.9.2+dfsg-6
ii  libqt5sql5 5.9.2+dfsg-6
ii  libqt5widgets5 5.9.2+dfsg-6
ii  libqt5xml5 5.9.2+dfsg-6
ii  libstdc++6 7.2.0-18

akonadi-server recommends no packages.

Versions of packages akonadi-server suggests:
ii  akonadi-backend-mysql   4:17.08.3-1
pn  akonadi-backend-postgresql  
pn  akonadi-backend-sqlite  

-- no debconf information

Bug#886187: zapping: Depends on libgnomeui

[Jeremy Bicha]

Source: zapping
Version: 0.10~cvs6-12
Severity: important
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: oldlibs libgnomeui
Tags: sid buster
X-Debbugs-CC: ya...@gnu.org, locutusofb...@debian.org

As announced [1], we do not intend to release Debian 10 "Buster" with
the old libgnome (and related) libraries. These libraries have been
deprecated and unmaintained for several years.

Your package depends and or build-depends on libgnomeui.

Please port your package to GTK3 and related maintained libraries.
Otherwise, please consider requesting that your package be removed from
Debian to help us complete this goal.

My apologies for not being more specific in bug 868412.

[1] https://lists.debian.org/debian-devel/2017/10/msg00299.html

On behalf of the Debian GNOME team,
Jeremy Bicha

Bug#886188: zapping: Depends on gconf

[Jeremy Bicha]

Source: zapping
Version: 0.10~cvs6-12
Severity: important
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: oldlibs gconf
Tags: sid buster
X-Debbugs-CC: ya...@gnu.org, locutusofb...@debian.org

Your package depends or build-depends on gconf, but gconf will be
removed from Debian soon.

gconf's last release was about 5 years ago. It has been replaced by
gsettings (provided in Debian by source glib2.0 )

References
--
https://developer.gnome.org/gio/stable/ch34.html
https://developer.gnome.org/gio/stable/GSettings.html

On behalf of the Debian GNOME team,
Jeremy Bicha

Bug#886182: transition: glibc 2.26

[Aurelien Jarno]

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

Dear release team,

I would like to get a transition slot for glibc 2.26. It is available in
experimental for one month and a half, and there is no known regression.
It has been built successfully on all release architectures, and most
other architectures besides kfreebsd-* which do not have build daemons
anymore. The failures on hurd-i386 and hppa are being worked on and can
be fixed in the upload to sid or later, so I don't think we should block
the transition on that.

As the glibc is using symbol versioning, there is no soname change. That
said a few packages are using libc internal symbols and have to be
rebuilt for this transition:
 - apitrace
 - bro
 - dante
 - libnih
 - libnss-db
 - p11-kit
 - unscd

Here is the corresponding ben file:
  title = "glibc";
  is_affected = .depends ~ /libc[0-9.]* \(<

Bug#886181: rrdtool: Please switch to automatic dbgsym package

[Jeremy Bicha]

Source: rrdtool
Version: 1.6.0-1

Please drop the -dbg package and use an automatic dbgsym packge instead.

https://wiki.debian.org/AutomaticDebugPackages

Thanks,
Jeremy Bicha

Bug#886179: foo2zjs: Don't recommend tk

[Jeremy Bicha]

From 9a278faf4c76d6cd88ed67a1a3b72a3ba3df9d96 Mon Sep 17 00:00:00 2001
From: Jeremy Bicha 
Date: Tue, 2 Jan 2018 16:09:54 -0500
Subject: [PATCH] Don't recommend tk on Ubuntu

Closes: #886179
---
 debian/control |  4 ++--
 debian/rules   | 15 ---
 2 files changed, 10 insertions(+), 9 deletions(-)

diff --git a/debian/control b/debian/control
index 13ef4f5..fe135b7 100644
--- a/debian/control
+++ b/debian/control
@@ -41,8 +41,8 @@ Description: printer driver for ZjStream-based printers
 Package: printer-driver-foo2zjs-common
 Architecture: all
 Depends: ${misc:Depends}
-Recommends: ${debian:tix}, tk, printer-driver-foo2zjs (>= ${source:Version})
-Suggests: ${ubuntu:tix}
+Recommends: ${debian:tix}, ${debian:tk}, printer-driver-foo2zjs (>= ${source:Version})
+Suggests: ${ubuntu:tix}, ${ubuntu:tk}
 Enhances: printer-driver-foo2zjs (>= ${source:Version})
 Breaks: udev (<< 136-1), cups (<< 1.5.0-3~), foo2zjs (<< 20111023dfsg0-1~), printer-driver-foo2zjs (<< 20131225dfsg0-5~)
 Replaces: foo2zjs (<< 20111023dfsg0-1~), printer-driver-foo2zjs (<< 20131225dfsg0-5~)
diff --git a/debian/rules b/debian/rules
index 00368ff..bb4d3bb 100755
--- a/debian/rules
+++ b/debian/rules
@@ -72,16 +72,17 @@ override_dh_gencontrol:
 ifeq ($(derives_from_ubuntu),yes)
 	# Ubuntu considers mscompress to be a Depends of printer-driver-foo2zjs
 	echo "ubuntu:mscompress=mscompress" >> debian/printer-driver-foo2zjs.substvars
+	# Ubuntu considers tix to be a Suggests of printer-driver-foo2zjs
+	echo "ubuntu:tix=tix" >> debian/printer-driver-foo2zjs-common.substvars
+	# Ubuntu considers tk to be a Suggests of printer-driver-foo2zjs
+	echo "ubuntu:tk=tk" >> debian/printer-driver-foo2zjs-common.substvars
 else
 	# Debian considers mscompress to be a Recommends of printer-driver-foo2zjs
 	echo "debian:mscompress=mscompress" >> debian/printer-driver-foo2zjs.substvars
-endif
-ifeq ($(derives_from_ubuntu),yes)
-	# Ubuntu considers tix to be a Suggest of printer-driver-foo2zjs
-	echo "ubuntu:tix=tix" >> debian/printer-driver-foo2zjs.substvars
-else
-	# Debian considers tix to be a Depends of printer-driver-foo2zjs
-	echo "debian:tix=tix" >> debian/printer-driver-foo2zjs.substvars
+	# Debian considers tix to be a Recommends of printer-driver-foo2zjs
+	echo "debian:tix=tix" >> debian/printer-driver-foo2zjs-common.substvars
+	# Debian considers tix to be a Recommends of printer-driver-foo2zjs
+	echo "debian:tk=tk" >> debian/printer-driver-foo2zjs-common.substvars
 endif
 	dh_gencontrol
 
-- 
2.14.1

Bug#878764: [pkg-ntp-maintainers] Bug#878764: init script does not wait for ntpd to stop

[Bernhard Schmidt]

On 16.10.2017 16:44, Kajetan Staszkiewicz wrote:

Hi,

> When issuing a restart command for ntpd the old daemon is killed and new one 
> started before the old one really terminates. The new one can't bind to 
> network as the old one is has the sockets.
> 
> This was already reported in bug #802040 and was fixed in Debian Stretch. Any 
> chance on fixing this in Jessie too?

jessie is already oldstable and will be handed over to LTS in a couple
of months. I don't think it is worth the hassle to backport this.

Any particular reason you cannot upgrade?

Bernhard

Bug#886173: general: ls quotes results with special characters in its output

[Ben Hutchings]

Control: reassign -1 coreutils

On Tue, 2018-01-02 at 20:38 +, mqu...@neosmart.net wrote:
[...]
> In particular, `ls` output (both in regular and `-l` modes) wraps in
> single quotes the names of files that contain special characters (or, at
> least, a parenthesis), meaning its output is not an accurate reflection
> of the actual contents of the directory.

The output of ls on a terminal has never, in general, been an accurate
reflection of the contents of a directory.  Consider that filenames can
contain *any* byte value other than '\0' or '/', so including carriage
return, newline, backspace and escape characters.

ls also uses multiple columns by default, but without quoting you can't
generally tell where the columns are, e.g. is:

aa  ba  ca
ab  bb  cb

a list of 6 two-letter filenames, or 2 filenames with spaces in, or
something else again?

[...]
> Additionally, the output cannot be copied-and-pasted as it is. What is
> the point of injecting quotes if they don't actually escape/quote their
> content? To illustrate with an example:
> 
> ```
> mqudsi@buster ~> touch \$\(test\)
> mqudsi@buster ~> ls -l
> -rw-r--r-- 1 mqudsi mqudsi0 Jan  2 14:27 '$(test)'
> ```
> 
> That's not shell-safe, but the quotes might lead you to think it were.[...]

It is shell-safe.  No $-expansion is done within single-quoted text.

> There's no good way to account for all inputs or to account for the
> idiosyncrasies of the quoting behavior of all the different shells.

I think that the behaviour of single-quoting is very consistent across
shells, in part because it is specified by POSIX.

[...]
> Hopefully this behavior can be changed to simply listing the contents of
> the specified directory as-is.

Be careful what you wish for.  But I think this will revert the recent
change:

alias ls='ls --literal'

and this will disable all transformation of filenames (the same as if
output is not sent to a terminal):

alias ls='ls --literal --color=never --show-control-chars -1'

Ben.

-- 
Ben Hutchings
Lowery's Law:
If it jams, force it. If it breaks, it needed replacing anyway.


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

Bug#885055: timeline: don't depend only on iceowl-extension without lightning

[Carsten Schoenert]

Control: severity -1 serious

On Fri, Dec 22, 2017 at 01:53:33PM +0100, Carsten Schoenert wrote:
> Source: timeline
> Severity: important
> 
> Dear Maintainer,
> 
> the package src:thunderbird got finally reowrked and all transitional
> packages for icedove* and iceowl-* are no gone with thunderbird
> 1:52.5.0-1
> 
> xul-ext-timeline is using the following Depends
> 
> Depends: iceowl-extension, thunderbird (>= 17.0) | icedove (>= 17.0)
> 
> Please add at least a depends on 'lightning | iceowl-extension' instead
> only depending only on iceowl-extension. This prevents currently the
> transition of thunderbird >= 52.5.0-1 into testing.

raised severity due the blocked migration of src:thunderbird into
testing.

Regards
Carsten

Bug#823533: allow to skip ntpdate on ifup

[Bernhard Schmidt]

On Thu, May 05, 2016 at 01:44:06PM -0500, Christian Ehrhardt wrote:

Hi Christian,

thanks for bringing this up.

> While these days the systemd based timesync* tools are doing most of the
> work there is still a lot of buzz around the automated ntpdate on ifup
> being good/bad for various reasons.
> 
> I'll try to to summarize the outcome of multiple discussions and bugs
> around this that I recently passed and propose a solution.

I think we even need a few more changes around here.

First of all, we need to change the actual binary for a one-shot time
sync from the long deprecated ntpdate to sntp.

If we use sntp with the default configuration it uses an unpriviledged
port, which should not race the startup of ntpd anymore. So we could get
rid of all the locking. I've posted a mail regarding this on the mailing
list a couple of months ago.

https://lists.alioth.debian.org/pipermail/pkg-ntp-maintainers/2017-October/004850.html

Third, I think a major issue is the package "ntpdate" both shipping the
ntpdate binary (which one might want to use for debugging or because you
just don't know sntp) and the ifup hooks, which simply do not work well
with a lot of use cases. I'm pretty sure that most installations of
ntpdate do not need it.

I'm therefor proposing a complete rewrite

- new package sntp-hooks
  - depends on sntp, ships hooks for ifupdown and possibly others (like
NetworkManager or systemd-network or whatever Ubuntu is doing now)
  - executes the actual sntp synchronisation non-blocking, possibly with
a one-shot systemd unit using --no-block when systemd is running
- make ntpdate depend on sntp-hooks and rm_conffile all installed hooks

So if you don't want hooks you just don't install sntp-hooks. 

The package sntp-hooks could additionally ship an /etc/default file to
change behaviour.

I have attempted to spin up some patches for this lately, but ran out of
time. Is this something you could agree on Ubuntu-side?

Bernhard

Bug#886114: Please support X-GitLab-Project in addition to X-Git-Repo.

[Raphael Hertzog]

Hi Charles,

On Tue, 02 Jan 2018, Charles Plessy wrote:
> 
> Emails sent by the GitLab system installed on salsa.debian.org using the
> "Emails on push" integration setting contain a "X-GitLab-Project:"
> header by default.  How about changing vendor/debian/rules.py so that
> this header would be parsed just like the "X-Git-Repo" header ?  In my
> understanding, it would allow to use "dispa...@tracker.debian.org" as a
> recipient for the commit emails, which would simplify the management of
> repositories (by using the same address everywhere).

Yes, certainly. I have a commit ready for this. I will push it and
deploy it later.

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#886179: foo2zjs: Don't recommend tk

[Jeremy Bicha]

Source: foo2zjs
Version: 20170320dfsg0-2
Tags: patch

foo2zjs used to recommend tix and tk until they were dropped to
suggests after complaints. See https://bugs.debian.org/601591

It was silently re-promoted to recommends at
https://anonscm.debian.org/cgit/printing/foo2zjs.git/commit/?id=859e9b

I don't know much about the foo2zjs package but I thought the
recommends were only for the /usr/share/applications/hplj1020.desktop
which is hidden by default.

1. At least on Ubuntu, we don't want the tk and tix recommends. I am
attaching a patch for this in my next email (so that it includes this
bug number).

2. Or maybe the tix and tk recommends should be downgraded to Suggests
on Debian too. I think it's worth mentioning that Debian actually has
not recommended tix in 3 years because of a typo in
https://anonscm.debian.org/cgit/printing/foo2zjs.git/commit/?id=3a8e1f
(should be -common.substvars). This is fixed in my #1 patch.

3. Or maybe the .desktop should be split to a separate binary package.
That way it can have the depends it needs and the .desktop could drop
the NoDisplay=true line. I think users would find it easier to install
the one package instead of needing to manually re-enable the .desktop
(more difficult since the alacarte app isn't installed by default
these days).

Thanks,
Jeremy Bicha

Bug#886178: An extra trailing slash is added to ZFS root pool and it's not bootable

[Fejes József]

Package: grub-common
Version: 2.02-2
Severity: grave

I have my root filesystem on ZFS. I'm using a ZFS pool's root dataset
(rpool) as opposed to a sub-dataset (eg. rpool/foo or rpool/foo/bar).

update-grub calls calls /etc/grub.d/10_linux which sets the root=ZFS=
parameter for grub/initrd. In this case, it sets it as
root=ZFS=rpool/. Note the trailing slash. This is invalid and makes
the system unbootable.

I already filed this bug at https://savannah.gnu.org/bugs/?52746 . But
that bugtracker looks completely abandoned for months. I'm pretty sure
it only needs a small fix to remove extra trailing slashes.

Bug#867722: xul-ext-imap-acl: please depend on icedove | thunderbird

[Carsten Schoenert]

Control: severity -1 serious
Control: affects -1 src:thunderbird

Dear maintainers of xul-ext-imap-acl, 

On Sat, Jul 08, 2017 at 11:55:42PM +0200, Roland Hieber wrote:
> Package: xul-ext-imap-acl
> Version: 0.2.7-1
> Severity: normal
> 
> Dear Maintainer,
> 
> Icedove has since been re-rebranded to Thunderbird, but xul-ext-imap-acl still
> depends on icedove only. Please change the dependency accordingly.

starting with uploading src:thunderbird 1:52.5.0-1 there no transitional
packages like icedove* or iceowl* are built anymore. So the package
xul-ext-imap-acl is depending on a binary package icedove which isn't
existing any longer in unstable.

I raised the severity for xul-ext-imap-acl to serious as this prevents
now the migration of thunderbird packages to testing. Please upload a
rebuilded package.

Regards
Carsten

Bug#886177: xul-ext-sieve: Please depend on thunderbird | icedove

[Carsten Schoenert]

Package: xul-ext-sieve
Severity: serious

Dear Maintainer of xul-ext-sieve,

starting with uploading src:thunderbird 1:52.5.0-1 there no transitional
packages like icedove* or iceowl* are built anymore. So the package
xul-ext-sieve is depending on a binary package icedove which isn't
existing any longer in unstable.

I raised the severity for xul-ext-sieve to serious as this prevents now
the migration of thunderbird packages to testing. Please upload a
rebuilded package.

Regards
Carsten

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

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

Bug#885042: Check inclusion of Apache 2.0 NOTICE files

[Vincent Bernat]

 ❦  2 janvier 2018 12:04 -0800, Russ Allbery  :

>>> We currently allow distribution of a binary-package-only Debian image
>>> along with a written offer of source or, for non-commercial
>>> distribution, a simple pointer to the Debian source archives.  This
>>> complies with the GPL but wouldn't, at least by my reading, comply with
>>> the Apache 2.0 license unless we include the NOTICE files in binary
>>> packages.  (Which is fairly trivial to do -- in fact, I wonder if we
>>> should just solve this problem in debhelper and add NOTICE to the
>>> default debhelper dh_installdocs whitelist.)
>
>> Except for cases where the whole work is not under Apache license, only
>> part of it. In this case, the NOTICE file may not be at the
>> root. License also says documentation is fine, so debian/copyright could
>> be enough.
>
> debian/copyright would definitely be enough if people remembered to check
> NOTICE for each upstream release and copy its contents into
> debian/copyright, but I've forgotten to do this for packages in the past.
> Just installing the NOTICE files seems more foolproof to me, and involves
> less fiddly checklist stuff with each new upstream release.
>
> Good point about it possibly being hard for debhelper to find all the
> NOTICE files, though.

There is some irony on having a warning about license.txt that shouldn't
be in the binary copyright (because "all license information should be
collected in the debian/copyright file") but an error when we don't copy
the notice file.
-- 
Patch griefs with proverbs.
-- William Shakespeare, "Much Ado About Nothing"


signature.asc
Description: PGP signature

Bug#886168: closed by Jörg Frings-Fürst <debian@jff.email> (Re: Bug#886168: new upstream release)

[Antoine Beaupré]

Understood. I wasn't aware of that versioning scheme in
Shotwell... Would be be appropriate to upload it to experimental though?

A.
-- 
We are discreet sheep; we wait to see how the drove is going, and then go
with the drove.
- Mark Twain

Bug#886168: new upstream release

[Jörg Frings-Fürst]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hello Antoine,

thank you for spending your time helping to make Debian better with
this bug report.


Odd minor version numbers development releases and highly unstable.
Due to the experience with release 0.25.4, development releases are no
longer published in Debian.



CU
Jörg


- -- 
New:
GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB  30EE 09F8 9F3C 8CA1 D25D
GPG key (long) : 09F89F3C8CA1D25D
GPG Key: 8CA1D25D
CAcert Key S/N : 0E:D4:56

Old pgp Key: BE581B6E (revoked since 2014-12-31).

Jörg Frings-Fürst
D-54470 Lieser

Threema: SYR8SJXB
Wire:  @joergfringsfuerst
Skype: joergpenguin
Ring:  jff

IRC: j_...@freenode.net
 j_...@oftc.net

My wish list: 
 - Please send me a picture from the nature at your home.
-BEGIN PGP SIGNATURE-

iQIyBAEBCgAdFiEEY+AHX8jUOrs1qzDuCfifPIyh0l0FAlpL8m8ACgkQCfifPIyh
0l0ajQ/4rdOJ0JYfqrMvUKECWd3rRSR95o3oGPK7txR5e2nqsTbG5s7w2Hh+vz+C
cfynditsaZUgljqaW2V+2jAPRkhjucnP43yE74SGCYUNtNw4pFCMMH1LDRyc+kKy
/O2X0AeEQX18cSITjzKn4i+eKtmQV4gSJDInRp/J1FaxgGpkmpuizsRmExae75r9
njxt9IlDONQV4ACesA6/Pm1lpkjMlKZh4hc5kXEi7HDBKnnSED3/gHwAsNr5VusA
q7+CoOM282FvMMueER42AT8pC8GIfB1pD8NQ/mU3KXkNYkymvl2u/8YQfTyBFSIw
BqI8jEAvmj+duFL8hIdYMcdpltubc/Lf+gGtOsU8hG492Pefh9cTco2SMrM1rlFb
8QayI7bGUNMvh1HwE5xFBuFAXQemydLtajSw66sI3V0h6XKlqdu7eIjEaCukef0x
82BRG4CM1lSeKbMyKAgVgzL0nTvrRJpPR2q3nH/G2v+4ti+TptfFf3Xr3x6oU3VR
7zT8lbL7p8IDLVocQviI7aMVvYTLfRCCNgnJH07QWmdFl4yRMOTsdV2L9bLz0MCj
6OOJYuOLrvouO8v8/QX13mPz4x7q6NlC2+YZmhuzGcA0p+ozIdsy9OUs4PEmlTkC
HIFlAQnv12CMgwHLaGdLv6P3M9238yc8OnHc+cOGDcXDZ5qeNQ==
=Apys
-END PGP SIGNATURE-

Bug#886176: ITP: libmail-transport-perl -- perl library for sending email

[Damyan Ivanov]

Package: wnpp
Owner: Damyan Ivanov 
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org, debian-p...@lists.debian.org

* Package name: libmail-transport-perl
  Version : 3.001
  Upstream Author : Mark Overmeer
* URL : https://metacpan.org/release/Mail-Transport
* License : Artistic
  Programming Lang: Perl
  Description : perl library for sending email

Mail::Transport is a base class providing common functionality for sending
and receiving mail.

Included in this package are modules for sending mail via various means -
smtp, mailx, exim, qmail and sendmail.

-

This is the second (and last) part separated from libmail-box-perl in version
3.

The package will be maintained under the umbrella of the Debian Perl Group.

--
Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.

Bug#886166: [pkg-lxqt-devel] Bug#886166: pcmanfm-qt: Feature Request: Add 'gvfs-fuse' to 'Recommended packages'

[Alf Gaida]

I'm fine with - thanks for the suggestion.

Cheers Alf