Bug#894510: [debhelper-devel] Bug#894510: debhelper: Because it is listing tmpfiles in systemd's only, conf overriding is not working

[Seyeong Kim]

Right. Missed it.

Thanks!

> 2018. 4. 11. 오후 2:13, Niels Thykier  작성:
> 
> Seyeong Kim:
>> Please take a look this if you have time.
>> 
>> Thanks
>> 
>> [...]
> Hi Seyeong,
> 
> Please remember to Cc Felipe and Michael on this bug if you want them to
> see the follow ups. :)
> 
> Thanks,
> ~Niels

Bug#894510: [debhelper-devel] Bug#894510: debhelper: Because it is listing tmpfiles in systemd's only, conf overriding is not working

[Niels Thykier]

Seyeong Kim:
> Please take a look this if you have time.
> 
> Thanks
> 
> [...]
Hi Seyeong,

Please remember to Cc Felipe and Michael on this bug if you want them to
see the follow ups. :)

Thanks,
~Niels

Bug#894510: debhelper: Because it is listing tmpfiles in systemd's only, conf overriding is not working

[Seyeong Kim]

Please take a look this if you have time.

Thanks

On Wed, 04 Apr 2018 17:47:00 + Niels Thykier  wrote:
> Hi,
> 
> @Michael/@Felipe: Could you have a look at this bug ?
> 
> On Sat, 31 Mar 2018 08:58:21 -0700 Seyeong Kim
>  wrote:
> > Package: debhelper
> > Version: 9.20160115ubuntu3
> > Severity: normal
> > Tags: d-i
> > 
> > In autoscripts/postinst-init-tmpfiles, There is TMPFILE containing conf in 
> > systemd pkg only.
> > Then if there is 00rsyslog.conf from rsyslog pkg. and installing or 
> > upgrading systemd
> > 
> > /var/log's permission is 755(which is default) not 775(which is in 
> > 00rsyslog.conf)
> > overriding doesn't work when upgrading.
> > 
> > Please refer to below LP
> > ubuntu lp bug : 
> > https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1748147
> > 
> > removing TMPFILE from autoscripts/postinst-init-tmpfiles solves this issue.
> > e.g. change like below
> > systemd-tmpfiles --create #TMPFILES# >/dev/null || true
> > to
> > systemd-tmpfiles --create >/dev/null || true
> > 
> > and removing related code from dh_installinit maybe needed
> > e.g. below kind of part
> > if (compat(10) && !$dh{NOSCRIPTS}) {
> > # Include postinst-init-tmpfiles if the package ships any 
> > files
> > # in /usr/lib/tmpfiles.d or /etc/tmpfiles.d
> > my @tmpfiles;
> > find({
> > wanted => sub {
> > my $name = $File::Find::name;
> > return unless -f $name;
> > $name =~ s/^\Q$tmp\E//g;
> > if ($name =~ m,^/usr/lib/tmpfiles\.d/, ||
> > $name =~ m,^/etc/tmpfiles\.d/,) {
> > push @tmpfiles, $name;
> > }
> > },
> > no_chdir => 1,
> > }, $tmp);
> > if (@tmpfiles > 0) {
> > autoscript($package,"postinst", 
> > "postinst-init-tmpfiles",
> > "s,#TMPFILES#," . join(" ", sort 
> > @tmpfiles).",g");
> > }
> > }
> > 
> > Is there any reason that TMPFILE list is there? 
> > 
> > [...]
> 
> Thanks,
> ~Niels
> 
> 

Bug#895396: fonts-anonymous-pro: Please drop myself from Uploaders

[Christian Perrier]

Source: fonts-anonymous-pro
Severity: minor

I'm no longer active in maintaining fonts in Debian, so I suggest that
my name iis removed from the Uploaders field in debian/control.

Many thanks in advance.


-- System Information:
Debian Release: 9.4
  APT prefers oldoldstable
  APT policy: (500, 'oldoldstable'), (500, 'stable'), (500, 'oldstable')
Architecture: i386 (i686)

Kernel: Linux 4.9.0-4-686-pae (SMP w/1 CPU core)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Bug#895395: colord: autopkgtest started failing since glib2.0 version 2.56.1-1on output to stderr

[Paul Gevers]

Source: colord
Version: 1.3.3-2
Severity: normal
User: ci-t...@tracker.debian.org
Usertags: progression

Since some weeks ci.debian.net is running autopkgtests in testing with
packages that try to migrate from unstable. With the upload of version
2.56.1-1 of glib2.0, the autopkgtest of colord in testing¹ (and
unstable²) started to fail (see below for the relevant part of the log).

The actual test passes, the reason why the autopkgtest fails is that
there is unexpected output to stderr. Because I can't judge with my
limited knowledge of your package whether this is output is OK or not, I
filed this bug against colord (adding allow-stderr to the autopkgtest
restrictions will let the autopkgtest pass). If you believe glib2.0 to
be at fault here, please reassign this bug (you should raise the
severity if you want to block glib2.0 from migrating to testing.

PASS:
/tmp/autopkgtest-lxc.imznnddk/downtmp/build.MBo/src/src/.libs/cd-self-test
==21565== 8 bytes in 1 blocks are definitely lost in loss record 70 of 373
==21565==at 0x4C2CB8F: malloc (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==21565==by 0x18EF2D: xmalloc (in /bin/bash)
==21565==by 0x18898A: set_default_locale (in /bin/bash)
==21565==by 0x137E66: main (in /bin/bash)
==21565==

Testsuite summary for colord 1.3.3

# TOTAL: 1
# PASS:  1
# SKIP:  0
# XFAIL: 0
# FAIL:  0
# XPASS: 0
# ERROR: 0

make[4]: Leaving directory
'/tmp/autopkgtest-lxc.imznnddk/downtmp/build.MBo/src/src'
make[3]: Leaving directory
'/tmp/autopkgtest-lxc.imznnddk/downtmp/build.MBo/src/src'
make[2]: Leaving directory
'/tmp/autopkgtest-lxc.imznnddk/downtmp/build.MBo/src/src'
make[1]: Leaving directory
'/tmp/autopkgtest-lxc.imznnddk/downtmp/build.MBo/src/src'
make: Leaving directory
'/tmp/autopkgtest-lxc.imznnddk/downtmp/build.MBo/src/src'
autopkgtest [06:47:02]: test make-check: ---]
autopkgtest [06:47:02]: test make-check:  - - - - - - - - - - results -
- - - - - - - - -
make-check   FAIL stderr: ==21312== 8 bytes in 1 blocks are
definitely lost in loss record 70 of 373
autopkgtest [06:47:02]: test make-check:  - - - - - - - - - - stderr - -
- - - - - - - -
==21312== 8 bytes in 1 blocks are definitely lost in loss record 70 of 373
==21312==at 0x4C2CB8F: malloc (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==21312==by 0x18EF2D: xmalloc (in /bin/bash)
==21312==by 0x18898A: set_default_locale (in /bin/bash)
==21312==by 0x137E66: main (in /bin/bash)
==21312==
==21565== 8 bytes in 1 blocks are definitely lost in loss record 70 of 373
==21565==at 0x4C2CB8F: malloc (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==21565==by 0x18EF2D: xmalloc (in /bin/bash)
==21565==by 0x18898A: set_default_locale (in /bin/bash)
==21565==by 0x137E66: main (in /bin/bash)
==21565==
autopkgtest [06:47:02]:  summary
make-check   FAIL stderr: ==21312== 8 bytes in 1 blocks are
definitely lost in loss record 70 of 373

Paul

¹ https://ci.debian.net/packages/c/colord/testing/amd64/
² https://ci.debian.net/packages/c/colord/unstable/amd64/




signature.asc
Description: OpenPGP digital signature

Bug#895394: atf-allwinner: Not generally compatible with dpkg-buildflags LDFLAGS

[Steve Langasek]

Package: atf-allwinner
Version: 1.0.apritzel.81-1
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu bionic ubuntu-patch

The atf-allwinner package failed to build in Ubuntu because its default
buildflags differs from those in Debian, and LDFLAGS meant for gcc were
being passed directly to ld:

[...]
  LD  build/sun50iw1p1/debug/bl31/bl31.elf
[...]
aarch64-linux-gnu-ld: unrecognized option '-Wl,-Bsymbolic-functions'
aarch64-linux-gnu-ld: use the --help option for usage information
[...]

You had already handled this for the specific case of -Wl,-z,relro in
LDFLAGS in Debian, but I think a more general solution is appropriate. 
Please see the attached patch.

-- 
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 atf-allwinner-1.0.apritzel.81/debian/rules 
atf-allwinner-1.0.apritzel.81/debian/rules
--- atf-allwinner-1.0.apritzel.81/debian/rules  2018-02-25 17:21:03.0 
-0800
+++ atf-allwinner-1.0.apritzel.81/debian/rules  2018-04-10 21:09:32.0 
-0700
@@ -1,6 +1,8 @@
 #!/usr/bin/make -f
 export DEB_BUILD_MAINT_OPTIONS=hardening=-relro,-stackprotector
 
+export DEB_LDFLAGS_MAINT_SET =
+
 %:
dh $@
 

Bug#895393: tracker.debian.org thinks 3.9.8 is the latest standards version

[dequis]

Package: tracker.debian.org
Severity: normal

Dear Maintainer,

The old package tracker complains that my package is "severely out of
date", while the new one thinks it is up to date and doesn't complain
about anything.

Compare:

https://packages.qa.debian.org/b/bitlbee.html
https://tracker.debian.org/pkg/bitlbee

< kilobyte> looking at some other package, the tracker still thinks
3.9.8 is current
< pabs> IIRC the tracker code looks at the version of the debian-policy
package

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

Kernel: Linux 4.15.13-1-ARCH (SMP w/4 CPU cores; PREEMPT)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968), LANGUAGE=C 
(charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Bug#892623: fonts-noto-cjk: Noto Serif CJK for Debian stretch bpo

[Hideki Yamane]

Hi,

 I don't know why but it seems that not delivered to mailing list.
 ping to czchen, could you consider to deal with it, please?


On Sun, 11 Mar 2018 22:08:50 +0900 Kenshi Muto  wrote:
> Package: fonts-noto-cjk
> Severity: wishlist
> Tags: stretch
> 
> Dear Maintainer,
> 
> Could you consider to upload newer fonts-noto-cjk package to
> stretch-backports?
> It would be very helpful if we can use Noto Serif CJK fonts
> via backports.
> 
> Regards,
> -- 
> Kenshi Muto
> km...@debian.org
> 
> 



-- 
Regards,

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

Bug#895392: ITP: python-kiwisolver -- fast implementation of the Cassowary constraint solver

[Sandro Tosi]

Package: wnpp
Severity: wishlist
Owner: Sandro Tosi 

* Package name: python-kiwisolver
  Version : 1.0.1
  Upstream Author : sccolb...@gmail.com
* URL : https://github.com/nucleic/kiwi
* License : new BSD
  Programming Lang: C++, Python
  Description : fast implementation of the Cassowary constraint solver

Kiwi is an efficient C++ implementation of the Cassowary constraint solving
algorithm. Kiwi is an implementation of the algorithm based on the seminal
Cassowary paper. It is *not* a refactoring of the original C++ solver. Kiwi
has been designed from the ground up to be lightweight and fast. Kiwi ranges
from 10x to 500x faster than the original Cassowary solver with typical use
cases gaining a 40x improvement. Memory savings are consistently > 5x.

In addition to the C++ solver, Kiwi ships with hand-rolled Python bindings.

needed by matplotlib 2.2.0+

Bug#895391: libfontconfig1-dev: Missing dependency on uuid-dev

[Jeremy Bicha]

Package: libfontconfig-1dev
Version: 2.13.0-1
Severity: grave
X-Debbugs-CC: po...@debian.org

According to its pkgconfig file, libfontconfig1-dev needs to depend on
uuid-dev. This is causing other packages to FTBFS. First seen on arm64
with evolution, libdazzle, webkit2gtk, zenity, etc.

Thanks,
Jeremy Bicha

Bug#895390: openfoam: please add ppc64el to the list of less-parallel Ubuntu architectures

[Steve Langasek]

Package: openfoam
Version: 4.1+dfsg1-1
Severity: minor
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu bionic ubuntu-patch

Dear Anton,

The openfoam package in Ubuntu had started to fail to build on ppc64el with
an OOM error.  Digging into this, I found that amd64 and arm64 already had
special handling in debian/rules, to build with lower parallelization on
Ubuntu.

I have uploaded the attached patch to Ubuntu to add ppc64el to this list,
and the package now builds.

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 openfoam-4.1+dfsg1/debian/rules openfoam-4.1+dfsg1/debian/rules
--- openfoam-4.1+dfsg1/debian/rules 2016-11-18 12:15:14.0 -0800
+++ openfoam-4.1+dfsg1/debian/rules 2018-04-10 15:54:21.0 -0700
@@ -54,9 +54,9 @@
 ifneq (,$(filter parallel=%,$(DEB_BUILD_OPTIONS)))
 NUMJOBS := $(patsubst parallel=%,%,$(filter 
parallel=%,$(DEB_BUILD_OPTIONS)))
 endif
-# Limit parallel build to 3 processes on Ubuntu amd64 and arm64
+# Limit parallel build to 3 processes on Ubuntu amd64, arm64, and ppc64el
 ifeq ($(VENDOR),Ubuntu)
-ifneq (,$(filter $(DEB_HOST_ARCH),amd64 arm64))
+ifneq (,$(filter $(DEB_HOST_ARCH),amd64 arm64 ppc64el))
 NUMJOBS := $(shell if test $(NUMJOBS) -gt 3; then echo 3 ; else echo 
$(NUMJOBS); fi)
 endif
 endif

Bug#853502: NMU

[Adam Borowski]

Here's a NMU for this and #754322, using Jason Duerstock's patch.
Will upload to DELAYED/7; preferred way to cancel is dput with a better
version, barring that dcut or shouting at me should also work.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢰⠒⠀⣿⡁ 
⢿⡄⠘⠷⠚⠋⠀ ... what's the frequency of that 5V DC?
⠈⠳⣄
diff -u libpam-chroot-0.9/debian/changelog libpam-chroot-0.9/debian/changelog
--- libpam-chroot-0.9/debian/changelog
+++ libpam-chroot-0.9/debian/changelog
@@ -1,3 +1,11 @@
+libpam-chroot (0.9-4.3) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTBFS with GCC-7 and Clang. Closes: 853502, #754322; thanks Jason
+Duerstock, Juhani Numminen.
+
+ -- Adam Borowski   Wed, 11 Apr 2018 02:18:46 +0200
+
 libpam-chroot (0.9-4.2) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -u libpam-chroot-0.9/pam_chroot.c libpam-chroot-0.9/pam_chroot.c
--- libpam-chroot-0.9/pam_chroot.c
+++ libpam-chroot-0.9/pam_chroot.c
@@ -187,7 +187,7 @@
char **uptr;
 
if(NULL == user || NULL == ngrps) { return -1; }
-   if(0 > *ngrps || 0 > gid) { return -1; }
+   if(0 > *ngrps) { return -1; }
 
if(gcount < *ngrps) {
if(NULL != grps) { grps[gcount] = gid; }
@@ -870,7 +870,7 @@
break;
 
default:
-   if(opts.flags * _PAM_OPTS_DEBUG) {
+   if(opts.flags & _PAM_OPTS_DEBUG) {
_pam_log(LOG_NOTICE, "%s: returning failure", 
opts.module);
}
err = PAM_SESSION_ERR;

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

[Brad Warren]

I’m another upstream developer of Certbot.

Taking 0.21.1 into stable would be the most conservative update that would 
resolve this issue. The oldest version you could take is 0.21.0, but 0.21.1 was 
released 8 days later and as a result has been much more widely tested. Since 
0.21.1 was released back in January, it has been installed and run on over 
500,000 systems and been used to obtain over two million certificates from 
Let’s Encrypt. Alternatively, you could take 0.22.2 or 0.23.0 which would 
include other bug fixes (and features), but they both have been released for 
less than a month.

The switch to Python 3 would affect relatively few users, but it will affect 
some. There are around 200 installations maintaining certificates from Let’s 
Encrypt using the packages in stretch (or jessie-backports) with third party 
Certbot plugins. These plugins need to register themselves using Certbot’s 
Python interface so a change to Python 3 would likely break things for them.

There may also be Debian users using Certbot with a private CA or using 
Certbot’s Python interface in ways other than writing a plugin. We don’t have 
data on these users and the latter is not supported, however, I have seen a 
couple instances of both. I’m unsure if the people I’ve seen doing this were 
using Debian.

The certbot, python-acme, python-certbot, python-certbot-apache, and 
python-certbot-nginx would all need to be updated.

Please let me know if there’s anything else I can do to help get this resolved.

Bug#895288: Mail Source View fails

[Jeremy Bicha]

Version: 3.28.1-1

On Mon, Apr 9, 2018 at 8:59 AM, Jörg Frings-Fürst  wrote:
> if I use STRG-U for source view the new window pop up with
> empty messages or only with the message:

I believe this is fixed in evolution 3.28.1-1 which was uploaded to
unstable today. I noticed your bug right after I uploaded.

Maybe it was this commit that fixed it:
https://git.gnome.org/browse/evolution/commit/?h=gnome-3-28=a87218979fe

Thanks,
Jeremy Bicha

Bug#894560: pygame: Don't drop python2 package

[Dominik George]

Control: tags -1 + pending

Hi,

the next upload in a couple of days will re-introduce the python 2 package.

-nik


signature.asc
Description: PGP signature

Bug#894801: wmmon CPU graph gets unreadable at high loads

[Doug Torrance]

Control: tags -1 fixed-upstream pending

On 04/04/2018 07:23 AM, Pedro Gimeno wrote:

During compilation of a program, the CPU graph of wmmon kept adding horizontal 
green lines (the ones that serve as a hint for the range of the value) until 
the whole graph was just made of horizontal lines, i.e. it was completely green.

I've composed a series of snapshots into a single image to show the 
progression, and then the cooldown:

http://www.formauri.es/personal/pgimeno/temp/wmmon-cpugraph-progression.png

The program whose compilation caused that CPU load was the latest version of 
Löve, an OpenGL 2D framework. An older version is included as a Debian package, 
simply called love. The problem is also reproducible in this older version, by 
issuing 'make clean ; make -j' directly in the source; I couldn't get 
dpkg-buildpackage -j to work on Löve.

The compile was restarted after finished (make clean ; make -j); the first 
compilation didn't completely fill wmmon's graph with green.

Load average reported by /proc/loadavg peaked at 107.69 74.17 37.30 104/1136 
9178 during the compilation.

Maybe a colour change could be used as an indicator of higher ranges, past a 
certain threshold? For example, when there are going to be more than 15 
horizontal green lines, switch to purple (or some other colour) lines, where 
each purple line is equivalent to 16 green lines. Not sure if more colours 
would be needed.


Thanks for your report!

I've released a new upstream version (1.4) of wmmon which I believe 
fixes the issue based on your suggestion. [1]


In particular, once we reach a load average of 10, it switches to yellow 
hint lines for each multiple of 10.  Once it reaches 100, it switches to 
red hint lines for each multiple of 100.


We would need to reach a load average of 4000 for everything to get 
filled with red.


I should get an updated package uploaded to Debian soon.

[1] http://www.dockapps.net/wmmon

Bug#895389: patch.1: Minor adjustments to the manual

[Bjarni Ingi Gislason]

Package: patch
Version: 2.7.6-2
Severity: minor
Tags: patch

Dear Maintainer,

  Suggested commit message for "git":

Change ".BR" with one argument to ".B".

Change the argument of ".BR ." into two by separating the
punctuation from the first one.

Protect the period (with \&) from being interpreted as an end of a
sentence.

Change '--' to '\*=' (defined in the man page).

Split long lines into two (or more).

Split lines that only have one space after the end of a sentence into
two ore more (man-pages(7), groff.info).

Add a comma after "e.g." and "i.e." (man-pages(7)).



  Suggested notes for "git":

Input file is patch.1

Test nr. 2:

Enable and fix warnings from 'test-groff'.

:696 (macro BR): only 1 argument, but more are expected
:1057 (macro BR): only 1 argument, but more are expected

Output is from: test-groff -b -e -mandoc -T utf8 -rF0 -t -w w -z 

  and

Test nr. 15:

Change the name of a macro for two fonts (e.g., BR and IR) to one letter,
if there is only one argument.
Add the second argument if needed.  It is sometimes part of the first one.

696:.BR \*=suffix
1057:.BR \-p0.



Test nr. 8:

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

1190:\fB#ifdef OLDCODE\fP .\|.\|. \fB#else .\|.\|. #endif\fP),

#

Test nr. 12 (adjusted):

Change -- to the defined string "=", ".ds = \-\^\-"

437:\fB--fuzz\fR=\fInum\fP option into account.


#

Test nr. 27:

Split lines longer than 80 characters into two or more lines.
Appropriate break points are the end of a sentence and a subordinate
clause.

patch.1: line 63length 83
patch.1: line 304   length 82
patch.1: line 367   length 83

#

Test nr. 28:

Wrong distance between sentences or protect the indicator.

1) Separate the sentences and subordinate clauses; each begins on a new
line.  See man-pages(7) and "info groff".

Or

2) Adjust space between sentences (two spaces),

3) or protect the indicator by adding "\&" after it.

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

307:endings. On Windows, reads and writes do transform line endings by default,
759:given in context diff headers. Unless specified in the time stamps,
849:Marshall T. Rose and Einar A. Stefferud,
1190:\fB#ifdef OLDCODE\fP .\|.\|. \fB#else .\|.\|. #endif\fP),

#

Test nr. 42:

Add a comma after "e.g." and "i.e." (man-pages(7)).

584:and if the first command is an append (i.e. it should have been a delete)
787:(e.g. with
966:in different directories, e.g.\&
975:(e.g. the file
988:(e.g. with
1022:(e.g. a shell script) to accomplish them should accompany the patch.

#

  PATCH:


--- patch.1 2018-04-10 20:23:42.0 +
+++ patch.1.new 2018-04-10 21:08:57.0 +
@@ -60,7 +60,8 @@ Thus you could feed an article or messag
 diff listing to
 .BR patch ,
 and it should work.
-If the entire diff is indented by a consistent amount, if lines end in 
\s-1CRLF\s0,
+If the entire diff is indented by a consistent amount,
+if lines end in \s-1CRLF\s0,
 or if a diff is encapsulated one or more times by prepending
 "\fB\- \fP" to lines starting with "\fB\-\fP" as specified by Internet RFC 934,
 this is taken into account.
@@ -300,11 +301,13 @@ is
 \fB\*=binary\fP
 Write all files in binary mode, except for standard output and
 .BR /dev/tty .
-When reading, disable the heuristic for transforming CRLF line endings into LF
-line endings.  This option is needed on \s-1POSIX\s0 systems when applying 
patches
+When reading,
+disable the heuristic for transforming CRLF line endings into LF line endings.
+This option is needed on \s-1POSIX\s0 systems when applying patches
 generated on non-\s-1POSIX\s0 systems to non-\s-1POSIX\s0 files.
 (On \s-1POSIX\s0 systems, file reads and writes never transform line
-endings. On Windows, reads and writes do transform line endings by default,
+endings.
+On Windows, reads and writes do transform line endings by default,
 and patches should be generated by
 .B "diff\ \*=binary"
 when line endings are significant.)
@@ -364,7 +367,8 @@ for that.
 Set the maximum fuzz factor.
 This option only applies to diffs that have context, and causes
 .B patch
-to ignore up to that many lines of context in looking for places to install a 
hunk.
+to ignore up to that many lines of context in looking for places to
+install a hunk.
 Note that a larger fuzz factor increases the odds of a faulty patch.
 The default fuzz factor is 2.  A fuzz factor greater than or equal to the
 number of lines of context in the context diff, ordinarily 3, ignores all
@@ -434,7 +438,7 @@ lines from the patch; in the merge forma
 format is the default.
 
 This option implies \fB\*=forward\fP and does not take the
-\fB--fuzz\fR=\fInum\fP option into account.
+\fB\*=fuzz\fR=\fInum\fP option into account.
 .TP
 \fB\-n\fP  or  \fB\*=normal\fP
 Interpret the patch file as a normal diff.
@@ -581,7 +585,7 @@ If 

Bug#895388: Symbol removal prevents upgrade of postgres 9.6 cluster with postgis columns

[Ari Pollak]

Package: libsfcgal1
Version: 1.3.3-1
Severity: serious

I have postgresql-9.6-postgis-2.3 installed (no longer in Debian
buster, but was in stretch, current stable). After upgrading libsfcgal1
and trying to use postgis on my existing Postgres 9.6 server, I get an
error when trying to access a table with a geography column:

ari@ari:~ % psql
ari=# \d+
location_order_providers

ERROR:  could not load library
"/usr/lib/postgresql/9.6/lib/postgis-2.3.so":
/usr/lib/x86_64-linux-gnu/libSFCGAL.so.1: undefined symbol:
_ZN4CGAL11NULL_VECTORE


That would be fine if I could upgrade the database to Postgres 10, since
the new postgresql-10-postgis-2.4 package doesn't depend on libsfcgal1,
but I can't do that with the missing symbol:

ari@ari:~ % sudo pg_upgradecluster 9.6 main
Stopping old
cluster...

Disabling connections to the old cluster during
upgrade...

Restarting old cluster with restricted
connections...

Creating new PostgreSQL cluster 10/main .
...
Disabling connections to the new cluster during upgrade...
Roles, databases, schemas, ACLs...
pg_dump: [archiver (db)] query failed: ERROR:  could not load library
"/usr/lib/postgresql/9.6/lib/postgis-2.3.so":
/usr/lib/x86_64-linux-gnu/libSFCGAL.so.1: undefined symbol:
_ZN4CGAL11NULL_VECTORE


If I downgrade libsfcgal1, all of that works fine.


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

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

Versions of packages libsfcgal1 depends on:
ii  libboost-atomic1.62.0   1.62.0+dfsg-5
ii  libboost-chrono1.62.0   1.62.0+dfsg-5
ii  libboost-date-time1.62.01.62.0+dfsg-5
ii  libboost-filesystem1.62.0   1.62.0+dfsg-5
ii  libboost-program-options1.62.0  1.62.0+dfsg-5
ii  libboost-serialization1.62.01.62.0+dfsg-5
ii  libboost-system1.62.0   1.62.0+dfsg-5
ii  libboost-test1.62.0 1.62.0+dfsg-5
ii  libboost-thread1.62.0   1.62.0+dfsg-5
ii  libboost-timer1.62.01.62.0+dfsg-5
ii  libc6   2.27-3
ii  libgcc1 1:8-20180402-1
ii  libgmp102:6.1.2+dfsg-3
ii  libmpfr64.0.1-1
ii  libstdc++6  8-20180402-1

libsfcgal1 recommends no packages.

libsfcgal1 suggests no packages.

-- no debconf information

Bug#895387: wavelet-decompose overlaps with gimp 2.10

[Ari Pollak]

Package: gimp-plugin-registry
Version: 7.20140602+b4
Severity: important

gimp 2.10 RC 1 (now in experimental) contains
/usr/lib/gimp/2.0/plug-ins/wavelet-decompose, which overlaps with this
package. Can you please remove it from this package so it is superseded by
gimp, and gimp can Breaks/Replaces on an older version of this package?

Thanks,
Ari

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

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

Versions of packages gimp-plugin-registry depends on:
ii  gimp 2.10.0~RC1-1
ii  libatk1.0-0  2.28.1-1
ii  libblas3 [libblas.so.3]  3.7.1-4
ii  libc62.27-3
ii  libcairo21.15.10-2
ii  libfftw3-single3 3.3.7-1
ii  libfontconfig1   2.12.6-0.1
ii  libfreetype6 2.8.1-2
ii  libgcc1  1:8-20180321-1
ii  libgdk-pixbuf2.0-0   2.36.11-2
ii  libgimp2.0   2.10.0~RC1-1
ii  libgl1   1.0.0-2
ii  libgl1-mesa-glx  17.3.7-1
ii  libglew2.0   2.0.0-5
ii  libglib2.0-0 2.56.0-4
ii  libglu1-mesa [libglu1]   9.0.0-2.1
ii  libgtk2.0-0  2.24.32-1
ii  libgtkglext1 1.2.0-7
ii  libice6  2:1.0.9-2
ii  libjpeg62-turbo  1:1.5.2-2+b1
ii  liblapack3 [liblapack.so.3]  3.7.1-4
ii  liblcms2-2   2.9-1
ii  liblqr-1-0   0.4.2-2.1
ii  libpango-1.0-0   1.42.0-1
ii  libpangocairo-1.0-0  1.42.0-1
ii  libpangoft2-1.0-01.42.0-1
ii  libpangox-1.0-0  0.0.2-5+b2
ii  libsm6   2:1.2.2-1+b3
ii  libstdc++6   8-20180321-1
ii  libtiff-tools4.0.9-4
ii  libtiff5 4.0.9-4
ii  libx11-6 2:1.6.5-1
ii  libxmu6  2:1.1.2-2
ii  libxt6   1:1.1.5-1
ii  python   2.7.14-4
ii  xdg-utils1.1.2-2

Versions of packages gimp-plugin-registry recommends:
pn  gimp-gmic  

Versions of packages gimp-plugin-registry suggests:
pn  icc-profiles  

Bug#895386: qt3d5-dev: Package doesn't include dir /usr/include/x86_64-linux-gnu/qt5/Qt3DExtras

[José de Paula Rodrigues]

Package: qt3d5-dev
Version: 5.10.1+dfsg-3
Severity: important

Dear Maintainer,

When trying to build QGis 3.0 from source, at some point CMake reports
the following error:

CMake Error at 
/usr/lib/x86_64-linux-gnu/cmake/Qt53DExtras/Qt53DExtrasConfig.cmake:27 
(message):
  The imported target "Qt5::3DExtras" references the file

 "/usr/include/x86_64-linux-gnu/qt5/Qt3DExtras"

  but this file does not exist.  Possible reasons include:

  * The file was deleted, renamed, or moved to another location.

  * An install or uninstall procedure did not complete successfully.

  * The installation package was faulty and contained

 
"/usr/lib/x86_64-linux-gnu/cmake/Qt53DExtras/Qt53DExtrasConfig.cmake"

  but not all the files it references.

The directory and its contents is included in the upstream source tarball, but 
for some reason didn't make to the Debian package.

In fact, the source tarball has 13 directories under include:

~/software/qt3d-everywhere-src-5.10.1/include]$ ls -ld
Qt3DAnimation
Qt3DCore
Qt3DCoreTest
Qt3DExtras
Qt3DInput
Qt3DLogic
Qt3DQuick
Qt3DQuickAnimation
Qt3DQuickExtras
Qt3DQuickInput
Qt3DQuickRender
Qt3DQuickScene2D
Qt3DRender

whereas qt3d5-dev only has the following 8:

$ ls -d /usr/include/x86_64-linux-gnu/qt5/Qt3D*
/usr/include/x86_64-linux-gnu/qt5/Qt3DCore
/usr/include/x86_64-linux-gnu/qt5/Qt3DExtras
/usr/include/x86_64-linux-gnu/qt5/Qt3DInput
/usr/include/x86_64-linux-gnu/qt5/Qt3DLogic
/usr/include/x86_64-linux-gnu/qt5/Qt3DQuick
/usr/include/x86_64-linux-gnu/qt5/Qt3DQuickInput
/usr/include/x86_64-linux-gnu/qt5/Qt3DQuickRender
/usr/include/x86_64-linux-gnu/qt5/Qt3DQuickScene2D
/usr/include/x86_64-linux-gnu/qt5/Qt3DRender

Manually copying Qt3DExtras from the source tarball to the system include dir 
solves the problem for me; I believe the package should include all those files 
from the source tarball. Thanks.

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

Kernel: Linux 4.16.0minerva (SMP w/8 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 qt3d5-dev depends on:
ii  libqt53danimation5   5.10.1+dfsg-3
ii  libqt53dcore55.10.1+dfsg-3
ii  libqt53dextras5  5.10.1+dfsg-3
ii  libqt53dinput5   5.10.1+dfsg-3
ii  libqt53dlogic5   5.10.1+dfsg-3
ii  libqt53dquick5   5.10.1+dfsg-3
ii  libqt53dquickanimation5  5.10.1+dfsg-3
ii  libqt53dquickextras5 5.10.1+dfsg-3
ii  libqt53dquickinput5  5.10.1+dfsg-3
ii  libqt53dquickrender5 5.10.1+dfsg-3
ii  libqt53dquickscene2d55.10.1+dfsg-3
ii  libqt53drender5  5.10.1+dfsg-3
ii  qtbase5-dev  5.10.1+dfsg-5

qt3d5-dev recommends no packages.

Versions of packages qt3d5-dev suggests:
ii  qt3d5-doc   5.10.1+dfsg-3
pn  qt3d5-doc-html  

-- no debconf information

Bug#895348: gnome-panel: Description has been misleading since GNOME 3

[Simon McVittie]

On Tue, 10 Apr 2018 at 22:38:49 +0100, Justin B Rye wrote:
> The one part where I've got any doubts about the English is in the
> part covered by your "[etc.]":
> 
> notification area, volume controls and the battery charge indicator,
> and utilities ranging from weather forecast to system monitoring.
> ^^^   ^  ^^^ 
> Ands and ands and ands, plus oddly phrased "forecast" alongside
> "monitoring".  Maybe if they were "forecasts" and "monitors"...

This is awkwardly worded but not misleading, so I consider it a lower
priority than making the Description stop saying gnome-panel is still
a key part of GNOME.

smcv

Bug#895348: gnome-panel: Description has been misleading since GNOME 3

[Justin B Rye]

Simon McVittie wrote:
> gnome-panel's Description currently says:
[...]

I don't know much about GNOME of any vintage, but I can offer some
suggestions for reduced wordage:

> GNOME Flashback is a continuation of the GNOME 2 desktop user
> interface, providing a more traditional design than GNOME 3. It is
> suitable for older or more limited hardware where GNOME 3 might
> have low performance.
> .
> The GNOME Panel is an essential part of GNOME Flashback, providing
> toolbar-like “panels” which can [etc.] system monitoring.
> .
> The GNOME Panel was part of the GNOME Desktop before version 3.
> Its equivalent in the GNOME 3 desktop environment is part of the
> GNOME Shell, so the GNOME Panel is no longer required on GNOME 3
> systems.

The one part where I've got any doubts about the English is in the
part covered by your "[etc.]":

notification area, volume controls and the battery charge indicator,
and utilities ranging from weather forecast to system monitoring.
^^^   ^  ^^^ 
Ands and ands and ands, plus oddly phrased "forecast" alongside
"monitoring".  Maybe if they were "forecasts" and "monitors"...

But most of my changes are just attempts to squeeze it into fewer
lines:

  GNOME Flashback continues the traditional desktop user interface
  of GNOME 2, for hardware that would struggle with GNOME 3.
  .
  The GNOME Panel (replaced in GNOME 3 by the GNOME Shell) is an
  essential part of GNOME Flashback, providing the desktop with
  attachable sidebars. They are used to launch applications and embed
  various other functions, such as quick launch icons, the clock, the
  notification area, volume controls and the battery charge indicator,
  plus utilities ranging from weather forecasts to system monitors.

Then again, are the "quick launch icons" separate from the mechanism
for launching applications, or is this repetition?  Is there a
significant distinction between "functions" like the battery monitor
and "utilities" like the system monitor?  Perhaps it should be
something like:

  attachable sidebars. They provide quick launch icons for applications,
  and can embed various other functions, such as the notification area,
  volume controls, the clock, and displays for the weather, battery life,
  and other system monitors.

(Or should it mention wifi?)
-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package

Bug#884284: nfs4_reclaim_open_state: Lock reclaim failed

[Sergio Gelato]

Control: retitle -1 nfs4_reclaim_open_state: Lock reclaim failed

For what it's worth, I've seen the same symptoms in jessie (kernel 3.16.36
at the time) and Ubuntu trusty (3.13.0-93). In my experience, NFSv4 in
stretch is no worse than in jessie.

Rate-limiting those "Lock reclaim failed!" messages would be useful. I've
had to add a filter for them in rsyslog to prevent a DoS on my central
logging infrastructure. I don't see them often, but when a client gets stuck
it can emit this message *many* times.

There is definitely more than one trigger for these. I'm under the impression
that network partitioning events generate short bursts of such messages, but
this is usually benign and does not require a reboot for recovery. Not sure
what causes the more severe incidents (I haven't had one in a while, and
my NFS environment is intentionally v4-only).

My troubleshooting checklist for the next incident includes
  echo 1 > /sys/kernel/debug/tracing/events/nfs4_lock_reclaim/enable
but I haven't had a chance to put this into practice yet.

Bug#891393: debootstrap: Should warn about distributions that need vsyscall enabled

[Ben Hutchings]

On Tue, 2018-04-10 at 10:55 +0900, Hideki Yamane wrote:
> Hi,
> 
> On Mon, 26 Feb 2018 23:19:43 +0900 Hideki Yamane  
> wrote:
> > > debootstrap could perhaps warn about the need to enable vsyscalls for
> > > old amd64 distributions.  (Annoyingly, there's no easy way to detect
> > > whether they are currently enabled.)
> > 
> >  Just showing some errors about it is fine, IMO.
> 
>  And here's a proposed patch. Could you check it, please?
> 
> 
> diff --git a/scripts/debian-common b/scripts/debian-common
> index 4ab1fe8..830a99e 100644
> --- a/scripts/debian-common
> +++ b/scripts/debian-common
> @@ -59,6 +59,17 @@ first_stage_install () {
>  }
>  
>  second_stage_install () {
> +   case "$CODENAME" in
> +   
> etch|etch-m68k|jessie|jessie-kfreebsd|lenny|squeeze|wheezy|hoary|breezy|dapper|edgy|feisty|gusty|hardy|interpid|jaunty|karmic)

"gutsy" and "intrepid" are typo'd here.

> +   if [ "$ARCH" = amd64 ] && [ "$HOST_ARCH" = amd64 ] && 
> \
> +   [ $(uname -r | awk 
> 'BEGIN{FS="."}{printf("%d%03d", $1, $2)}') -gt 4009 ]; then

I don't think you should include the kernel version check here, because
this is a configuration change made in Debian that may be made in
different versions (or not at all) in kernel packages for Debian
derivatives or custom kernels.

> +   warning VIRTUALSYSCALL "You're trying to 
> create an old amd64 release on newer one, and it may cause segfault due to 
> incompatibility.\n   If you'd face such case, you should add 
> 'vsyscall=emulate' to your kernel parametar.\n   For detail, see 
> /usr/share/doc/linux-image-amd64/NEWS.Debian.gz"

This is slightly strange wording.  And that documentation file might
not be installed.  Can I suggest the following instead:

You're trying to create an old amd64 release, which may segfault
on later kernel versions.  You may need to add 'vsyscall=emulate'
to the kernel parameters to avoid this.

Ben.

-- 
Ben Hutchings
All the simple programs have been written, and all the good names taken


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

Bug#892392: aqemu: diff for NMU version 0.9.2-2.1

[Emilio Pozuelo Monfort]

Control: tags 892392 + pending

Dear maintainer,

I've prepared an NMU for aqemu (versioned as 0.9.2-2.1) and
uploaded it. Please find attached the debdiff.

Cheers,
Emilio

diff -Nru aqemu-0.9.2/debian/changelog aqemu-0.9.2/debian/changelog
--- aqemu-0.9.2/debian/changelog2016-07-26 04:52:32.0 +0200
+++ aqemu-0.9.2/debian/changelog2018-04-10 23:18:58.0 +0200
@@ -1,3 +1,14 @@
+aqemu (0.9.2-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+
+  [ gregor herrmann ]
+  * Fix "build-depends on GCC 6": drop explicit build dependencies on
+gcc-6 and g++-6.
+(Closes: #892392)
+
+ -- Emilio Pozuelo Monfort   Tue, 10 Apr 2018 23:18:58 +0200
+
 aqemu (0.9.2-2) unstable; urgency=medium
 
   * debian/control:
diff -Nru aqemu-0.9.2/debian/control aqemu-0.9.2/debian/control
--- aqemu-0.9.2/debian/control  2016-07-26 04:51:45.0 +0200
+++ aqemu-0.9.2/debian/control  2018-04-10 23:18:35.0 +0200
@@ -7,9 +7,7 @@
qtbase5-dev,
qtbase5-dev-tools,
zlib1g-dev,
-   cmake,
-   gcc-6,
-   g++-6
+   cmake
 Standards-Version: 3.9.8
 Homepage: http://aqemu.sourceforge.net/
 

Bug#895262: RFS: deepin-menu/3.3.2-1

[Adam Borowski]

On Mon, Apr 09, 2018 at 10:31:30AM +0800, Yanhao Mo wrote:
> * Package name: deepin-menu
>   Version : 3.3.2-1

(Note: there's a couple transitions going on, so installability of build
dependencies comes and goes, causing temporary problems; this is not your
fault.)

> Changes since the last upload:
>   * New upstream release.
>   * d/control: add new uploader Yanhao Mo 
>   * d/control: Use Salsa platform for Vcs field.
>   * debian/control: Update Standers-Version to 4.1.4.
>   * debian/compat: Switch compat to level 11.

Hi!
I see that the packaging no longer installs autostart parts:

--- deepin-menu-3.2.0/debian/install2017-08-11 15:49:21.0 +0200
+++ deepin-menu-3.3.2/debian/install1970-01-01 01:00:00.0 +0100
@@ -1,2 +0,0 @@
-data/com.deepin.menu.service /usr/share/dbus-1/services/
-deepin-menu.desktop /etc/xdg/autostart/

Files in first .deb but not in second
-
-rw-r--r--  root/root   /etc/xdg/autostart/deepin-menu.desktop
-rw-r--r--  root/root   DEBIAN/conffiles

It's a non-obvious packaging change that would be nice to be described in
the changelog.

On the other hand, DDE wasn't a part of Stretch (so not many users yet), and
for your internal purposes, it's in git:
https://github.com/linuxdeepin/deepin-menu/commit/09e65bd7bd46c9aa6cdd1b205aa4e4f7be33ef0c
so if you feel like I'm nitpicking too much, please tell me so, I can upload
as-is.


Speaking about nitpicks in the changelog: s/Standers/Standards/.

Thanks for your work!


喵!
-- 
⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢰⠒⠀⣿⡁ 
⢿⡄⠘⠷⠚⠋⠀ ... what's the frequency of that 5V DC?
⠈⠳⣄

Bug#895364: iptables: using conntrack prevents dropping ip fragments

[Jim Pirzyk]

Further research into this bug, I have found this patch report for netfilter

https://patchwork.ozlabs.org/patch/863720/

Bug#895146: blobwars FTCBFS: uses the build architecture pkg-config

[Guus Sliepen]

tags 895146 + pending
thanks

On Sat, Apr 07, 2018 at 07:37:47PM +0200, Helmut Grohne wrote:

> blobwars fails to cross build from source, because it fails finding sdl
> as it uses the build architecture pkg-config. After making pkg-config
> substitutable, it cross builds successfully as dh_auto_build substitutes
> the right pkg-config. Please consider applying the attached patch.

Thanks for the patch! I applied it upstream, and will try to make a new
release soon.

-- 
Met vriendelijke groet / with kind regards,
  Guus Sliepen 


signature.asc
Description: PGP signature

Bug#810320:

[Alexandru Băluț]

This should be fixed with
https://gitlab.gnome.org/GNOME/pitivi/commit/bb3c1c614298d67351d0297779c765c48feea8a8
since two years ago. Please recheck.

Bug#895385: Please build python3.x-dbg without using pymalloc to help detecting memory handling issues

[Balint Reczey]

Package: python3.6
Version: 3.6.5-3
Severity: wishlist
Tags: patch

Dear Maintainers,

Shipping the -dbg Python packages without using pymalloc and with
-DPy_USING_MEMORY_DEBUGGER helped me in finding memory allocation
issues easier in Python modules and I'm sure that would help others as
well. I'm aware of the negative impact on the speed, but IMO for the
-dbg packages slower execution would be acceptable.

I'm attaching the patch I used with python3.6, but the first not
disruptive opportunity for introducing this change would probably be
the switch to python3.8 which is expected to ship new shared libraries
anyway.

Thanks,
Balint

-- 
Balint Reczey
Ubuntu & Debian Developer
diff -Nru python3.6-3.6.5/debian/rules python3.6-3.6.5/debian/rules
--- python3.6-3.6.5/debian/rules	2018-04-01 05:46:30.0 +
+++ python3.6-3.6.5/debian/rules	2018-04-04 15:12:23.0 +
@@ -164,6 +164,9 @@
 DPKG_LDFLAGS := $(shell DEB_BUILD_MAINT_OPTIONS=hardening=-pie dpkg-buildflags --get LDFLAGS)
 OPT_CFLAGS   := $(filter-out -O%,$(DPKG_CFLAGS)) # default is -O3
 DEBUG_CFLAGS := $(patsubst -O%,-Og,$(DPKG_CFLAGS))
+DEBUG_CPPFLAGS:= $(shell dpkg-buildflags --get CPPFLAGS) -DPy_USING_MEMORY_DEBUGGER
+
+DEBUG_ABIFLAGS = d
 
 # on alpha, use -O2 only, use -mieee
 ifeq ($(DEB_HOST_ARCH),alpha)
@@ -406,11 +409,12 @@
 	mkdir -p $(buildd_debug)
 	cd $(buildd_debug) && \
 	  CC="$(CC)" CXX="$(CXX)" AR="$(AR)" RANLIB="$(RANLIB)" CFLAGS="$(DEBUG_CFLAGS)" \
-	  CPPFLAGS="$(DPKG_CPPFLAGS)" LDFLAGS="$(DPKG_LDFLAGS)" \
+	  CPPFLAGS="$(DEBUG_CPPFLAGS)" LDFLAGS="$(DPKG_LDFLAGS)" \
 	$(config_site) \
 	../configure \
 		$(common_configure_args) \
-		--with-pydebug
+		--with-pydebug \
+		--without-pymalloc
 
 	$(call __post_configure,$(buildd_debug))
 	touch $@
@@ -420,11 +424,12 @@
 	mkdir -p $(buildd_shdebug)
 	cd $(buildd_shdebug) && \
 	  CC="$(CC)" CXX="$(CXX)" AR="$(AR)" RANLIB="$(RANLIB)" CFLAGS="$(DEBUG_CFLAGS)" \
-	  CPPFLAGS="$(DPKG_CPPFLAGS)" LDFLAGS="$(DPKG_LDFLAGS)" \
+	  CPPFLAGS="$(DEBUG_CPPFLAGS)" LDFLAGS="$(DPKG_LDFLAGS)" \
 	$(config_site) \
 	../configure \
 		$(common_configure_args) \
 		--enable-shared \
+		--without-pymalloc \
 		--with-pydebug
 
 	$(call __post_configure,$(buildd_shdebug))
@@ -1203,20 +1208,20 @@
 	-e 's,^RUNSHARED *=.*,RUNSHARED=,' \
 	-e '/BLDLIBRARY/s/-L\. //' \
 		$(buildd_shdebug)/Makefile \
-		> $(d)-dbg/$(scriptdir)/config-$(VER)dm-$(DEB_HOST_MULTIARCH)/Makefile
+		> $(d)-dbg/$(scriptdir)/config-$(VER)$(DEBUG_ABIFLAGS)-$(DEB_HOST_MULTIARCH)/Makefile
 	sed -e 's,^RUNSHARED *=.*,RUNSHARED=,' \
 	-e '/BLDLIBRARY/s/-L\. //' \
-		$(buildd_shdebug)/$(shell cat $(buildd_shdebug)/pybuilddir.txt)/_sysconfigdata_dm_$(PLAT)_$(DEB_HOST_MULTIARCH).py \
-		> $(d)-dbg/$(scriptdir)/_sysconfigdata_dm_$(PLAT)_$(DEB_HOST_MULTIARCH).py
+		$(buildd_shdebug)/$(shell cat $(buildd_shdebug)/pybuilddir.txt)/_sysconfigdata_$(DEBUG_ABIFLAGS)_$(PLAT)_$(DEB_HOST_MULTIARCH).py \
+		> $(d)-dbg/$(scriptdir)/_sysconfigdata_$(DEBUG_ABIFLAGS)_$(PLAT)_$(DEB_HOST_MULTIARCH).py
 	sed -i 's/ -O3 / -O2 /g;s/$(LTO_CFLAGS)//g;s/-fprofile-use *-fprofile-correction//g' \
-		$(d)-dbg/$(scriptdir)/_sysconfigdata_dm_$(PLAT)_$(DEB_HOST_MULTIARCH).py
+		$(d)-dbg/$(scriptdir)/_sysconfigdata_$(DEBUG_ABIFLAGS)_$(PLAT)_$(DEB_HOST_MULTIARCH).py
 
 	mv $(d)-dbg/usr/lib/libpython*.a $(d)-dbg/usr/lib/$(DEB_HOST_MULTIARCH)/
 
 	for i in $(d)-dbg/$(scriptdir)/lib-dynload/*.so; do \
 	  case "$$i" in *$(DEB_HOST_MULTIARCH)*) continue; esac; \
-	  b=$$(basename $$i .cpython-$(EXT_VER)dm.so); \
-	  d=$${b}.cpython-$(EXT_VER)dm-$(DEB_HOST_MULTIARCH).so; \
+	  b=$$(basename $$i .cpython-$(EXT_VER)$(DEBUG_ABIFLAGS).so); \
+	  d=$${b}.cpython-$(EXT_VER)$(DEBUG_ABIFLAGS)-$(DEB_HOST_MULTIARCH).so; \
 	  mv $$i $(d)-dbg/$(scriptdir)/lib-dynload/$$d; \
 	done
 
@@ -1224,24 +1229,24 @@
 		usr/bin \
 		usr/share/man/man1 \
 		$(scriptdir)/lib-dynload \
-		usr/include/$(PVER)dm \
-		usr/include/$(DEB_HOST_MULTIARCH)/$(PVER)dm \
+		usr/include/$(PVER)$(DEBUG_ABIFLAGS) \
+		usr/include/$(DEB_HOST_MULTIARCH)/$(PVER)$(DEBUG_ABIFLAGS) \
 		usr/lib/$(DEB_HOST_MULTIARCH)/pkgconfig
 
 	cp -p $(d)-dbg/$(scriptdir)/lib-dynload/*.so \
 		$(d_ldbg)/$(scriptdir)/lib-dynload/
-	cp -p $(d)-dbg/$(scriptdir)/_sysconfigdata_dm_$(PLAT)_$(DEB_HOST_MULTIARCH).py \
+	cp -p $(d)-dbg/$(scriptdir)/_sysconfigdata_$(DEBUG_ABIFLAGS)_$(PLAT)_$(DEB_HOST_MULTIARCH).py \
 		$(d_ldbg)/$(scriptdir)/
-	cp -p $(buildd_shdebug)/libpython$(VER)dm.so.1.0 \
+	cp -p $(buildd_shdebug)/libpython$(VER)$(DEBUG_ABIFLAGS).so.1.0 \
 		$(d_ldbg)/usr/lib/$(DEB_HOST_MULTIARCH)/
 	dh_link -p$(p_ldbg) \
-	/usr/lib/$(DEB_HOST_MULTIARCH)/libpython$(VER)dm.so.1.0 \
-		/usr/lib/$(DEB_HOST_MULTIARCH)/libpython$(VER)dm.so.1 \
-	/usr/lib/$(DEB_HOST_MULTIARCH)/libpython$(VER)dm.so.1 \
-		/usr/lib/$(DEB_HOST_MULTIARCH)/libpython$(VER)dm.so
-	cp $(d)-dbg/usr/lib/$(DEB_HOST_MULTIARCH)/pkgconfig/python-$(VER)dm.pc \
+	

Bug#895384: nfs-utils: debian/watch pattern matches ../

[Sergio Gelato]

Source: nfs-utils
Version: 1:1.3.4-2.1
Tags: patch

https://tracker.debian.org/pkg/nfs-utils mentions "Problems while searching
for a new upstream version". The reason turns out to be that the version
string pattern in debian/watch matches .. as well as 2.3.1 etc. and uscan
treats .. as newest. A minimal fix (tested) is to change /([\.\d]+)/ to
/(\d[\.\d]*)/ . There may be better solutions.

Incidentally, the latest upstream release of nfs-utils is 2.3.1. Debian sid
still has 1.3.4.

Bug#894232: piuparts: deprecate --keep-tmpdir after buster in favor of --keep-env

[Agustin Henze]

Rebased patch against develop

On Tue, 10 Apr 2018 16:57:02 -0300 Agustin Henze  wrote:
> Hi holger,
> 
> On 03/27/18 12:42, Holger Levsen wrote:
> [...]
> > So we first now need to do the above code changes and then deprecate
> > --keep-env after the buster release.
> > 
> > Filing a bug so we don't forget.
> > 
> 
> Please find the patch attached

Cheers,

-- 
TiN
>From e78f80435ebe933c3cb6cdc5f56ab48f51619046 Mon Sep 17 00:00:00 2001
From: Agustin Henze 
Date: Tue, 10 Apr 2018 15:22:28 -0300
Subject: [PATCH] Deprecate --keep-tmpdir in favor of --keep-env (Closes:
 #894232)

When the user pass --keep-tmpdir as parameter, the following message is
printed out:
  WARNING `--keep-tmpdir` is deprecated, use `--keep-env` instead

Signed-off-by: Agustin Henze 
---
 piuparts.1.txt |  2 +-
 piuparts.py| 18 --
 2 files changed, 13 insertions(+), 7 deletions(-)

diff --git a/piuparts.1.txt b/piuparts.1.txt
index 7d7c91de..603eaf12 100644
--- a/piuparts.1.txt
+++ b/piuparts.1.txt
@@ -143,7 +143,7 @@ The tarball can be created with the '-s' option, or you can use one that *pbuild
 *--install-remove-install*::
   Remove package after installation and reinstall. For testing installation in config-files-remaining state.
 
-*-k*, *--keep-tmpdir*::
+*-k*, *--keep-env*::
   Depending on which option is passed, keep the environment used for testing after the program ends::
* By default it doesn't remove the temporary directory for the chroot,
* or if --schroot is used, the schroot session is not terminated,
diff --git a/piuparts.py b/piuparts.py
index 90a2851b..5a4da223 100644
--- a/piuparts.py
+++ b/piuparts.py
@@ -153,7 +153,7 @@ class Settings:
 def __init__(self):
 self.defaults = None
 self.tmpdir = None
-self.keep_tmpdir = False
+self.keep_env = False
 self.shell_on_error = False
 self.max_command_output_size = 8 * 1024 * 1024  # 8 MB (google-android-ndk-installer on install) (daptup on dist-upgrade)
 self.max_command_runtime = 60 * 60  # 60 minutes (texlive-full and blends metapackages on dist-upgrade)
@@ -826,7 +826,7 @@ class Chroot:
 
 def remove(self):
 """Remove a chroot and all its contents."""
-if not settings.keep_tmpdir and os.path.exists(self.name):
+if not settings.keep_env and os.path.exists(self.name):
 self.terminate_running_processes()
 self.unmount_all()
 if settings.lvm_volume:
@@ -844,7 +844,7 @@ class Chroot:
 if os.path.exists(self.name):
 create_file(os.path.join(self.name, ".piuparts.tmpdir"), "removal failed")
 logging.debug("Removed directory tree at %s" % self.name)
-elif settings.keep_tmpdir:
+elif settings.keep_env:
 if settings.schroot:
 logging.debug("Keeping schroot session %s at %s" % (self.schroot_session, self.name))
 elif settings.docker_image:
@@ -2738,8 +2738,14 @@ def parse_command_line():
   action="store_true", default=False,
   help="Enable the installation of Suggests.")
 
-parser.add_option("-k", "--keep-tmpdir",
-  action="store_true", default=False,
+def keep_env_parser(option, opt_str, value, parser):
+setattr(parser.values, option.dest, True)
+if "--keep-tmpdir" == opt_str:
+print('WARNING `--keep-tmpdir` is deprecated, use `--keep-env` '
+  'instead')
+
+parser.add_option("-k", "--keep-env", "--keep-tmpdir", action="callback",
+  callback=keep_env_parser, default=False, dest='keep_env',
   help="Keep the environment used for testing after the "
   "program ends.")
 
@@ -2952,7 +2958,7 @@ def parse_command_line():
 defaults = DefaultsFactory().new_defaults()
 
 settings.tmpdir = opts.tmpdir
-settings.keep_tmpdir = opts.keep_tmpdir
+settings.keep_env = opts.keep_env
 settings.shell_on_error = opts.shell_on_error
 settings.single_changes_list = opts.single_changes_list
 settings.single_packages = opts.single_packages
-- 
2.17.0

Bug#855091: fails 100% for me

[Adam Borowski]

Sorry for the delay, I've waited for docker.io to get fixed.  Me being a
disorganised fool doesn't have any relation to the delay, no siree...

On Wed, Feb 14, 2018 at 04:39:20PM -0300, Agustin Henze wrote:
> Hi Adam,
> 
> On 06/25/17 20:35, Adam Borowski wrote:
> > Control: severity -1 serious
> > 
> > Hi!
> > I've tried to build this package many times (5 on armhf, 10 on amd64, once
> > on arm64), and it fails every single time.
> > 
> > Either Santiago's systems differ from those three of mine enough for the
> > fail to be only random for him, or something else changed -- but the present
> > state is that I have yet to see a successful build.
> > 
> >> The bug should be reproducible with sbuild on a single CPU virtual machine,
> >> provided you try enough times (as the failure happens randomly).
> > 
> > All the machines I tried it on have multiple cores (4, 6 and 4,
> > respectively).
> I have tried to reproduce it with no success. Could you tell me more about 
> your
> setup please?

Regular sbuild -- same as on official buildds.

All of build machines ran modern kernels (current gregkh's stable or linus'
-rc), but I've tried with oldLTS (4.9), and with Debian official packages,
same result.

The machines are, plus retry count from today (2018-04-10) only:
* amd64, AMD Phenom II 6x, btrfs, vanilla 4.16
  ✗ 20×amd64
  ✗ 1×i386
  ✗ 1×riscv64 (qemu-user)
  ✗ 1×arm64 (qemu-user)
* i386 lxc on amd64 host, Intel Braswell 4x, btrfs, 4.14.0-0.bpo.3-amd64
  ✓ 38×i386
  ✓ 10×amd64
* i386, Intel Pentium 4 (non-nx) 1x2(HT), ext4, 4.14.0-0.bpo.3-686
  ✗ 1×i386
* armhf, Odroid-U2 (Exynos 4412) 4x, btrfs, vanilla 4.16
  ✗ 10×armhf
* arm64, Pine64 (Allwinner A64) 4x, btrfs, anarsoul's 4.16
  ✗ 1×arm64
  ✗ 1×armhf

So there's no randomness at all.  All machines are on the same network
segment, all but the Pentium4 use exactly identical (% arch) sbuild config:
btrfs backend, eatmydata.  Current unstable (except for the Pentium4, and
the Braswell's host outside lxc).  DEB_BUILT_OPTIONS is parallel=# where #
is the number of cores/hyperthreads on that machine.

So the machine that succeeds differs only by being inside lxc and on a 2017
Intel CPU with all the newest extensions.
 

> I'm using the following command for testing it
> 
> set -e && for i in $(seq 10); do docker run --rm -it debian:stretch bash -c
> 'echo "deb-src http://deb.debian.org/debian stretch main" >
> /etc/apt/sources.list.d/sources.list && apt-get update && apt-get install
> eatmydata -y && eatmydata apt-get install dpkg-dev -y && apt-get source
> aiocoap; eatmydata apt-get build-dep aiocoap -y && cd aiocoap-0.1+9ae36f4/ &&
> dpkg-buildpackage -j$(getconf _NPROCESSORS_ONLN) -A'; done

docker.io is currently broken: uninstallable:
The following packages have unmet dependencies:
 docker.io : Depends: containerd (>= 0.2.1~) but it is not going to be installed
 Depends: runc (>= 0.1.0~) but it is not going to be installed
and doesn't build from source either (BD-Uninst on armhf, fails during
testsuite on amd64).  I see 6 long-standing RC bugs, and no one has touched
it for ages, thus it doesn't look like we'll see docker.io working again
anytime soon.

In theory, I could use a virtual machine with stretch somewhere, but it's
buster that's relevant.

> Also I've tried using schroot and it finished correctly as well. As you can
> see, I ran the command successfully 10 times, with multiple cores, with only
> one core, etc. Please let me know if there is anything special on your setup 
> to
> be able to reproduce it. Or could you provide a single command to reproduce 
> it?

"sbuild aiocoap", on all my machines but one. :/

But, despite the error message being identical, the way Santiago triggers it
differs from me: he sees it randomly on 1-way machines, I see it
deterministically on multi-threaded.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ The bill with 3 years prison for mentioning Polish concentration
⣾⠁⢰⠒⠀⣿⡁ camps is back.  What about KL Warschau (operating until 1956)?
⢿⡄⠘⠷⠚⠋⠀ Zgoda?  Łambinowice?  Most ex-German KLs?  If those were "soviet
⠈⠳⣄ puppets", Bereza Kartuska?  Sikorski's camps in UK (thanks Brits!)?

Bug#895382: Adding the GSound dependency would allow Pitivi to use libcanberra

[Alexandru Băluț]

Package: pitivi

$ grep -i gsound pitivi/check.py -A 1
GIDependency("GSound", "1.0", None,
 _("enables sound notifications when rendering is
complete")),

Bug#895381: rpc.gssd: WARNING: handle_gssd_upcall: failed to find uid in upcall string 'mech=krb5'

[Sergio Gelato]

Package: nfs-common
Version: 1:1.3.4-2.1
Severity: serious
Tags: fixed-upstream patch

One of my systems has logged
rpc.gssd[1168]: WARNING: handle_gssd_upcall: failed to find uid in upcall 
string 'mech=krb5'

This turns out to be a known problem, covered extensively in
https://bugzilla.redhat.com/show_bug.cgi?id=1419280

Please cherry-pick upstream commit 5ae8be8b6af1a0fdf2fa26051a05d4c04d028849
(and possibly 0a4f5e4daccdeba767b9ef36e30efbd7fd9a76d8 as well, although
I'd rate that at a lower severity).

Bug#895379: [piuparts] Create /dev/null if it doesn't exist ASAP

[Agustin Henze]

Package: piuparts
Version: 0.84
Severity: normal
Tags: patch

Hi holger, I've moved the creation of ${ENV}/dev/null ASAP, because in some
environments it is created as a regular file and then `apt-get update` hangs
forever.

-- 
TiN
From afbee5ef7a72bc29cc18452c34e3c8b8cd97a602 Mon Sep 17 00:00:00 2001
From: Agustin Henze 
Date: Tue, 10 Apr 2018 16:58:19 -0300
Subject: [PATCH 1/2] Create ${ENV}/dev/null if it doesn't exist ASAP

Signed-off-by: Agustin Henze 
---
 piuparts.py | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/piuparts.py b/piuparts.py
index 90a2851b..16df93d7 100644
--- a/piuparts.py
+++ b/piuparts.py
@@ -1134,6 +1134,8 @@ class Chroot:
 self.create_resolv_conf()
 for bindmount in settings.bindmounts:
 self.mount(bindmount, bindmount, opts="bind")
+if not os.path.exists(self.name + '/dev/null'):
+run(['mknod', '-m' ,'666', self.name + '/dev/null', 'c', '1', '3'])
 
 def remember_available_md5(self):
 """Keep a history of 'apt-cache dumpavail | md5sum' after initial
@@ -1416,9 +1418,6 @@ class Chroot:
 'broken-symlink',
 ]
 ignored_tags = []
-if not os.path.exists(self.name + '/dev/null'):
-device = os.makedev(1, 3)
-os.mknod(self.name + '/dev/null', 0o666, device)
 (status, output) = run(["adequate", "--root", self.name] + packages, ignore_errors=True)
 for tag in ignored_tags:
 # ignore some tags
-- 
2.17.0



signature.asc
Description: OpenPGP digital signature

Bug#894232: piuparts: deprecate --keep-tmpdir after buster in favor of --keep-env

[Agustin Henze]

Hi holger,

On 03/27/18 12:42, Holger Levsen wrote:
[...]
> So we first now need to do the above code changes and then deprecate
> --keep-env after the buster release.
> 
> Filing a bug so we don't forget.
> 

Please find the patch attached


-- 
TiN
From 5fb5014a799a361de48b7dde1bce79977300d11a Mon Sep 17 00:00:00 2001
From: Agustin Henze 
Date: Tue, 10 Apr 2018 15:22:28 -0300
Subject: [PATCH] Deprecate --keep-tmpdir in favor of --keep-env (Closes:
 #894232)

When the user pass --keep-tmpdir as parameter, the following message is
printed out:
  WARNING `--keep-tmpdir` is deprecated, use `--keep-env` instead

Signed-off-by: Agustin Henze 
---
 piuparts.1.txt |  2 +-
 piuparts.py| 22 ++
 2 files changed, 15 insertions(+), 9 deletions(-)

diff --git a/piuparts.1.txt b/piuparts.1.txt
index 7d7c91de..603eaf12 100644
--- a/piuparts.1.txt
+++ b/piuparts.1.txt
@@ -143,7 +143,7 @@ The tarball can be created with the '-s' option, or you can use one that *pbuild
 *--install-remove-install*::
   Remove package after installation and reinstall. For testing installation in config-files-remaining state.
 
-*-k*, *--keep-tmpdir*::
+*-k*, *--keep-env*::
   Depending on which option is passed, keep the environment used for testing after the program ends::
* By default it doesn't remove the temporary directory for the chroot,
* or if --schroot is used, the schroot session is not terminated,
diff --git a/piuparts.py b/piuparts.py
index 90a2851b..46c1c59f 100644
--- a/piuparts.py
+++ b/piuparts.py
@@ -153,7 +153,7 @@ class Settings:
 def __init__(self):
 self.defaults = None
 self.tmpdir = None
-self.keep_tmpdir = False
+self.keep_env = False
 self.shell_on_error = False
 self.max_command_output_size = 8 * 1024 * 1024  # 8 MB (google-android-ndk-installer on install) (daptup on dist-upgrade)
 self.max_command_runtime = 60 * 60  # 60 minutes (texlive-full and blends metapackages on dist-upgrade)
@@ -826,7 +826,7 @@ class Chroot:
 
 def remove(self):
 """Remove a chroot and all its contents."""
-if not settings.keep_tmpdir and os.path.exists(self.name):
+if not settings.keep_env and os.path.exists(self.name):
 self.terminate_running_processes()
 self.unmount_all()
 if settings.lvm_volume:
@@ -844,7 +844,7 @@ class Chroot:
 if os.path.exists(self.name):
 create_file(os.path.join(self.name, ".piuparts.tmpdir"), "removal failed")
 logging.debug("Removed directory tree at %s" % self.name)
-elif settings.keep_tmpdir:
+elif settings.keep_env:
 if settings.schroot:
 logging.debug("Keeping schroot session %s at %s" % (self.schroot_session, self.name))
 elif settings.docker_image:
@@ -2738,10 +2738,16 @@ def parse_command_line():
   action="store_true", default=False,
   help="Enable the installation of Suggests.")
 
-parser.add_option("-k", "--keep-tmpdir",
-  action="store_true", default=False,
-  help="Keep the environment used for testing after the "
-  "program ends.")
+def keep_env_parser(option, opt_str, value, parser):
+setattr(parser.values, option.dest, True)
+if "--keep-tmpdir" == opt_str:
+print('WARNING `--keep-tmpdir` is deprecated, use `--keep-env` '
+  'instead')
+
+parser.add_option("-k", "--keep-env", "--keep-tmpdir", action="callback",
+  callback=keep_env_parser, default=False, dest='keep_env',
+  help="It keeps the environment used for testing after "
+  "the program ends.")
 
 parser.add_option("-K", "--keyring", action="store", metavar="FILE",
   help="Use FILE as the keyring to use with debootstrap when creating chroots.")
@@ -2952,7 +2958,7 @@ def parse_command_line():
 defaults = DefaultsFactory().new_defaults()
 
 settings.tmpdir = opts.tmpdir
-settings.keep_tmpdir = opts.keep_tmpdir
+settings.keep_env = opts.keep_env
 settings.shell_on_error = opts.shell_on_error
 settings.single_changes_list = opts.single_changes_list
 settings.single_packages = opts.single_packages
-- 
2.17.0



signature.asc
Description: OpenPGP digital signature

Bug#895380: [piuparts] Create ${ENV}/dev/ptmx path if it doesn't exist

[Agustin Henze]

Package: piuparts
Version: 0.84
Severity: normal
Tags: patch

Hi holger, piuparts just check if it is a link but when you export a chroot
from a docker container, this path doesn't exists.

Cheers,

-- 
TiN
From ebb471f5ab6a34a3558c9e8e0c2598179909ff59 Mon Sep 17 00:00:00 2001
From: Agustin Henze 
Date: Tue, 10 Apr 2018 16:58:55 -0300
Subject: [PATCH 2/2] Create ${ENV}/dev/ptmx path if it doesn't exist

Signed-off-by: Agustin Henze 
---
 piuparts.py | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/piuparts.py b/piuparts.py
index 16df93d7..d9a3428a 100644
--- a/piuparts.py
+++ b/piuparts.py
@@ -1751,7 +1751,11 @@ class Chroot:
 if not os.path.lexists(etcmtab):
 os.symlink("../proc/mounts", etcmtab)
 self.mount("devpts", "/dev/pts", fstype="devpts", opts="newinstance,noexec,nosuid,gid=5,mode=0620,ptmxmode=0666")
-if not os.path.islink(self.relative("dev/ptmx")):
+dev_ptmx_rel_path = self.relative("dev/ptmx")
+if not os.path.islink(dev_ptmx_rel_path):
+if not os.path.exists(dev_ptmx_rel_path):
+with open(dev_ptmx_rel_path, 'w'):
+pass
 self.mount(self.relative("dev/pts/ptmx"), "/dev/ptmx", opts="bind", no_mkdir=True)
 p = subprocess.Popen(["tty"], stdout=subprocess.PIPE)
 stdout, _ = p.communicate()
-- 
2.17.0



signature.asc
Description: OpenPGP digital signature

Bug#692200: sound-juicer: Cannot read audio CD

[Peter Denison]

Package: sound-juicer
Version: 3.24.0-2
Followup-For: Bug #692200

Dear Maintainer,
   * What led up to the situation?
Newly upgraded from stretch to buster
Put an audio CD into the drive, and started Sound Juicer
   * What was the outcome of this action?
CD did not play. Error message appears:
"Could not read the CD
Sound Juicer could not read the track listing on this CD
Reason: Cannot access CD: The specified location is not mounted"
   * What outcome did you expect instead?
The CD to play

I have gvfs-backends installed.
The disc does not appear correctly in Rhythmbox either (no devices section 
appears)

Brasero recognises the title of the disc and can copy the data from it.
The CD drive works OK - if I do 'cdrdao read-toc /tmp/tmp-toc' it succeeds

Audio CDs used to play and rip correctly in stretch.


This is probably something to do with gvfs/gio, but I'm afraid I'm out 
of my depth in that regard.


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

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

Versions of packages sound-juicer depends on:
ii  dbus-user-session [default-dbus-session-bus]  1.12.6-2
ii  dbus-x11 [dbus-session-bus]   1.12.6-2
ii  dconf-gsettings-backend [gsettings-backend]   0.26.1-3
ii  gsettings-desktop-schemas 3.28.0-1
ii  gstreamer1.0-plugins-base 1.14.0-2
ii  gstreamer1.0-plugins-good 1.12.4-1+b1
ii  iso-codes 3.79-1
ii  libbrasero-media3-1   3.12.2-4
ii  libc6 2.27-3
ii  libcanberra-gtk3-00.30-6
ii  libdiscid00.6.2-2
ii  libglib2.0-0  2.56.0-4
ii  libgstreamer-plugins-base1.0-01.14.0-2
ii  libgstreamer1.0-0 1.14.0-1
ii  libgtk-3-03.22.29-3
ii  libmusicbrainz5-2 5.1.0+git20150707-7
ii  libpango-1.0-01.42.0-1

sound-juicer recommends no packages.

Versions of packages sound-juicer suggests:
ii  brasero  3.12.2-4
pn  gstreamer1.0-lame
pn  gstreamer1.0-plugins-really-bad  
ii  gstreamer1.0-plugins-ugly1.14.0-1

-- no debconf information

Bug#895378: sky2: sky2: did not recover correctly after waking up from S3

[Manuel Bilderbeek]

Package: src:linux
Version: 4.15.11-1
Severity: normal
File: sky2

Dear Maintainer,

   * What led up to the situation?

I started up my PC and didn't do anything. The system went into S3.

After I woke it up, all worked, except networking.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

The system told me that the cable was unplugged, but it wasn't.
After I remember the system woke up from S3, I removed the sky2 module and
modprobed it again. After that, networking started to work again immediately.

   * What was the outcome of this action?
   * What outcome did you expect instead?

I expected that networking would just work after waking up from S3.

Here's the sky2 story:

Boot:
[0.961316] sky2: driver version 1.30
[0.961442] sky2 :02:00.0: Yukon-2 EC Ultra chip revision 3
[0.966930] sky2 :02:00.0 eth0: addr 00:22:15:0f:99:ab
[7.370976] sky2 :02:00.0 eth0: enabling interface
[9.036080] sky2 :02:00.0 eth0: Link is up at 100 Mbps, full duplex, 
flow control both

Auto-suspend to S3 due to inactivity:
[ 1214.668015] sky2 :02:00.0 eth0: disabling interface

Waking up:
[ 1219.713183] sky2 :02:00.0 eth0: enabling interface

That's all. No message that the link is up. In fact:
[ 1219.716325] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready

Me, trying to recover by rmmod and modprobing:
[ 6711.523687] sky2 :02:00.0 eth0: disabling interface
[ 6714.918429] sky2: driver version 1.30
[ 6714.918573] sky2 :02:00.0: Yukon-2 EC Ultra chip revision 3
[ 6714.919025] sky2 :02:00.0 eth0: addr 00:22:15:0f:99:ab
[ 6714.939691] sky2 :02:00.0 eth0: enabling interface
[ 6716.623117] sky2 :02:00.0 eth0: Link is up at 100 Mbps, full duplex, 
flow control both

-- Package-specific info:
** Version:
Linux version 4.15.0-2-amd64 (debian-ker...@lists.debian.org) (gcc version 
7.3.0 (Debian 7.3.0-12)) #1 SMP Debian 4.15.11-1 (2018-03-20)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-4.15.0-2-amd64 
root=UUID=8efc387d-cdc0-496d-8f3c-03cc7f4ac8a5 ro quiet

** Tainted: PO (4097)
 * Proprietary module has been loaded.
 * Out-of-tree module has been loaded.

** Kernel log:
[ 1216.216183] smpboot: Booting Node 0 Processor 1 APIC 0x1
[ 1216.223242]  cache: parent cpu1 should not be sleeping
[ 1216.223320] microcode: sig=0x10677, pf=0x10, revision=0x703
[ 1216.227607] microcode: updated to revision 0x70a, date = 2010-09-29
[ 1216.227817] CPU1 is up
[ 1216.227846] smpboot: Booting Node 0 Processor 2 APIC 0x2
[ 1216.230620]  cache: parent cpu2 should not be sleeping
[ 1216.235237] CPU2 is up
[ 1216.235255] smpboot: Booting Node 0 Processor 3 APIC 0x3
[ 1216.238015]  cache: parent cpu3 should not be sleeping
[ 1216.242645] CPU3 is up
[ 1216.247339] ACPI: Waking up from system sleep state S3
[ 1216.405572] usb usb3: root hub lost power or was reset
[ 1216.405591] usb usb4: root hub lost power or was reset
[ 1216.405627] usb usb5: root hub lost power or was reset
[ 1216.405688] usb usb6: root hub lost power or was reset
[ 1216.405734] usb usb7: root hub lost power or was reset
[ 1216.405760] usb usb8: root hub lost power or was reset
[ 1216.405818] rtc_cmos 00:01: Alarms can be up to one month in the future
[ 1216.406434] serial 00:06: activated
[ 1216.417931] sd 2:0:0:0: [sda] Starting disk
[ 1216.424886] sd 5:0:0:0: [sdf] Starting disk
[ 1216.760886] usb 3-1: reset full-speed USB device number 2 using uhci_hcd
[ 1216.787119] ata5: SATA link down (SStatus 0 SControl 300)
[ 1216.787136] ata2: SATA link down (SStatus 0 SControl 300)
[ 1216.908871] usb 8-2: reset low-speed USB device number 3 using uhci_hcd
[ 1216.948872] ata4: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[ 1216.948885] ata6: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[ 1216.949120] ata6.00: supports DRM functions and may not be fully accessible
[ 1216.953581] ata6.00: supports DRM functions and may not be fully accessible
[ 1216.958405] ata6.00: configured for UDMA/133
[ 1216.958457] ata6.00: Enabling discard_zeroes_data
[ 1217.001936] ata4.00: configured for UDMA/100
[ 1217.172872] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[ 1217.175606] ata1.00: configured for UDMA/66
[ 1217.476878] usb 8-1: reset low-speed USB device number 2 using uhci_hcd

[ 1219.548864] floppy driver state
[ 1219.548864] ---
[ 1219.548871] now=4295197184 last interrupt=4294892540 diff=304644 last called 
handler=reset_interrupt [floppy]
[ 1219.548872] timeout_message=lock fdc
[ 1219.548872] last output bytes:
[ 1219.548873]  8 80 4294892535
[ 1219.548874]  8 80 4294892535
[ 1219.548875]  8 90 4294892535
[ 1219.548875]  8 80 4294892539
[ 1219.548876]  8 90 4294892539
[ 1219.548877]  8 80 4294892539
[ 1219.548877]  8 90 4294892539
[ 1219.548878]  e 80 4294892539
[ 1219.548879] 13 90 4294892539
[ 1219.548879]  0 90 4294892539
[ 1219.548880] 1a 90 4294892539
[ 1219.548881]  0 90 4294892539
[ 1219.548881] 12 90 4294892539
[ 1219.548882]  0 90 4294892539
[ 1219.548883] 14 90 

Bug#891523: tcpxtract: diff for NMU version 1.0.1-11.1

[Adrian Bunk]

Control: tags 891523 + pending

Dear maintainer,

I've prepared an NMU for tcpxtract (versioned as 1.0.1-11.1) and 
uploaded it to DELAYED/15. Please feel free to tell me if I should 
cancel it.

cu
Adrian

-- 

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

diff -Nru tcpxtract-1.0.1/debian/changelog tcpxtract-1.0.1/debian/changelog
--- tcpxtract-1.0.1/debian/changelog	2016-12-01 15:17:16.0 +0200
+++ tcpxtract-1.0.1/debian/changelog	2018-04-10 22:35:11.0 +0300
@@ -1,3 +1,10 @@
+tcpxtract (1.0.1-11.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTBFS with shared libfl. (Closes: #891523)
+
+ -- Adrian Bunk   Tue, 10 Apr 2018 22:35:11 +0300
+
 tcpxtract (1.0.1-11) unstable; urgency=medium
 
   * debian/control: added libfl-dev to Build-Depends field.
diff -Nru tcpxtract-1.0.1/debian/patches/60_libfl.patch tcpxtract-1.0.1/debian/patches/60_libfl.patch
--- tcpxtract-1.0.1/debian/patches/60_libfl.patch	1970-01-01 02:00:00.0 +0200
+++ tcpxtract-1.0.1/debian/patches/60_libfl.patch	2018-04-10 22:35:11.0 +0300
@@ -0,0 +1,25 @@
+Description: AC_CHECK_LIB(fl, main) does not work with shared libfl
+ Use LEXLIB set by the already called AC_PROG_LEX.
+Author: Adrian Bunk 
+
+--- tcpxtract-1.0.1.orig/Makefile.am
 tcpxtract-1.0.1/Makefile.am
+@@ -2,7 +2,7 @@ AM_CFLAGS = -D_OFFSET_BITS=64 -D_LARGEFI
+ bin_PROGRAMS = tcpxtract
+ tcpxtract_SOURCES = tcpxtract.c sessionlist.c sessionlist.h util.c util.h confy.y confl.l \
+ 	conf.c conf.h confy.h search.h search.c extract.h extract.c
+-#tcpxtract_LDADD = @LEXLIB@
++tcpxtract_LDADD = @LEXLIB@
+ 
+ sysconf_DATA = tcpxtract.conf
+ 
+--- tcpxtract-1.0.1.orig/configure.in
 tcpxtract-1.0.1/configure.in
+@@ -11,7 +11,6 @@ AC_PROG_INSTALL
+ AC_PROG_MAKE_SET
+ AC_PROG_RANLIB
+ 
+-AC_CHECK_LIB(fl, main)
+ AC_CHECK_LIB(pcap, pcap_open_offline)
+  
+ AC_HEADER_STDC
diff -Nru tcpxtract-1.0.1/debian/patches/series tcpxtract-1.0.1/debian/patches/series
--- tcpxtract-1.0.1/debian/patches/series	2016-11-20 23:42:52.0 +0200
+++ tcpxtract-1.0.1/debian/patches/series	2018-04-10 22:35:11.0 +0300
@@ -3,3 +3,4 @@
 30_fix-excessive-sync.patch
 40_fix-png-header-bytes.patch
 50_fix-spelling-binary.patch
+60_libfl.patch

Bug#857970: closed by b...@debian.org (Barak A. Pearlmutter) (Bug#857970: fixed in mldemos 0.5.1+git.1.ee5d11f-3)

[Barak A. Pearlmutter]

Oops, thought it was fixed. Ah well.

Bug#833287: Adding a mandatory check before upgrade

[Mathieu Parent]

Hi,

If no one comes with a good reason to have winbind listed before
compat (or before files) in nsswitch.conf, I'll add a mandatory check
for this during install or upgrade of libwbclient0 and libnss-winbind.

Regards
-- 
Mathieu Parent

Bug#895377: /usr/bin/pristine-tar: add support for specifing branch name to pristine-tar cli

[Scott Moser]

Package: pristine-tar
Version: 1.42
Severity: normal
File: /usr/bin/pristine-tar
Tags: patch

Dear Maintainer,

git-ubuntu is using pristine-tar.  git-ubuntu tracks archive versions
of both ubuntu and debian packages (and orig tarballs).  Because of the
fact that sometimes orig tarballs have differed within the same version
of a package, the pristine-tar branches are namespaced:
  importer/ubuntu/pristine-tar
  importer/debian/pristine-tar

In order for git-ubuntu to use the 'pristine-tar' cli, then to extract
original source tarballs we need to be able to specify the branch name.

So this is a request (and attached patch) for adding a '--branch' flag
to pristine-tar.


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

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

Versions of packages pristine-tar depends on:
ii  libbz2-1.0  1.0.6-8.1
ii  libc6   2.27-0ubuntu3
ii  perl5.26.1-5
ii  tar 1.29b-2
ii  xdelta  1.1.3-9.2
ii  xdelta3 3.0.11-dfsg-1ubuntu1
ii  zlib1g  1:1.2.11.dfsg-0ubuntu2

Versions of packages pristine-tar recommends:
ii  bzip2 1.0.6-8.1
ii  pbzip21.1.9-1build1
ii  xz-utils  5.2.2-1.3

pristine-tar suggests no packages.

-- no debconf information
>From d9fdae97e557b4e7de28ad3bce1d662fe14885c5 Mon Sep 17 00:00:00 2001
From: Scott Moser 
Date: Tue, 10 Apr 2018 15:00:39 -0400
Subject: [PATCH] pristine-tar: add -b/--branch flag for specifying the branch.

Some repositories may not have the same naming convention for the
pristine-tar branch.  One such example is the 'git ubuntu' work
that is being done.

This change allows tools using pristine-tar to provide the branch via
--branch=.
---
 pristine-tar | 13 ++---
 1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/pristine-tar b/pristine-tar
index 065582f..fb59bf6 100755
--- a/pristine-tar
+++ b/pristine-tar
@@ -118,6 +118,12 @@ Use this option to specify a custom commit message to 
pristine-tar commit.
 
 Applies to the B command.
 
+=item -b branch
+
+=item --branch=branch
+
+Use branch named B rather than the default 'pristine-tar'.
+
 =item -s signaturefile
 
 =item --signature-file=signaturefile
@@ -294,6 +300,7 @@ use constant {
 my $recompress = 0;
 my $recompress_theshold_bytes = 524288000;
 my $recompress_theshold_percent = 30;
+my $branch = 'pristine-tar';
 my ($message, $signature_file);
 my $genversion =
   version_from_env(XDELTA3, "xdelta" => XDELTA, "xdelta3" => XDELTA3);
@@ -314,6 +321,7 @@ dispatch(
   },
   options => {
 "m|message=s"=> \$message,
+"b|branch=s"=> \$branch,
 "s|signature-file=s" => \$signature_file,
 "r|recompress!"  => \$recompress,
 "B|recompress-threshold-bytes=i" => \$recompress_theshold_bytes,
@@ -333,6 +341,8 @@ Options:
-v, --verbose Turn on verbose output
-k, --keepDon't delete temporary files
-h, --helpDisplay usage information
+   -b BRANCH, --branch=BRANCH
+ Use branch named B. default=pristine-tar
-m MSG, --message=MSG Set commit message
-s SIG, --signature-file  Set signature file to be stored
  together with the tarball
@@ -932,7 +942,6 @@ sub git_findbranch {
 sub checkoutdelta {
   my $tarball = shift;
 
-  my $branch= "pristine-tar";
   my $deltafile = basename($tarball) . ".delta";
   my $idfile= basename($tarball) . ".id";
   my $sigfile   = basename($tarball) . ".asc";
@@ -986,7 +995,6 @@ sub commitdelta {
   my $id  = shift;
   my $tarball = shift;
 
-  my $branch= "pristine-tar";
   my $deltafile = basename($tarball) . ".delta";
   my $idfile= basename($tarball) . ".id";
   my $sigfile   = basename($tarball) . ".asc";
@@ -1137,7 +1145,6 @@ sub checkout {
 }
 
 sub list {
-  my $branch = "pristine-tar";
   my $vcs= vcstype();
   if ($vcs eq "git") {
 my $b = git_findbranch($branch, 1);
-- 
2.15.1

Bug#857970: closed by b...@debian.org (Barak A. Pearlmutter) (Bug#857970: fixed in mldemos 0.5.1+git.1.ee5d11f-3)

[Adrian Bunk]

Control: reopen -1

On Tue, Apr 10, 2018 at 05:30:03AM +, Debian Bug Tracking System wrote:
>...
>  mldemos (0.5.1+git.1.ee5d11f-3) unstable; urgency=medium
>  .
>* fix for OpenGL ES platforms---I'm looking at you ARM---which doesnt'
>  support glColor3f (closes: #857970)
>...


Doesn't seem to work:
https://buildd.debian.org/status/package.php?p=mldemos=sid

cu
Adrian

-- 

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

Bug#895375: libqt5qml5: segfault in QV4::ExecutionContext::newCallContext on x32

[Thorsten Glaser]

Package: libqt5qml5
Version: 5.10.1-3

Hi,

during package build of, for example, qtwebsockets-opensource-src
(5.10.1-2) its testsuite gets a segfault.

I can get a backtrace; unfortunately, most values for inspection
are optimised out though:

(gdb) bt
#0  0xf7f96035 in ?? ()
#1  0x02290450 in ?? ()
#2  0xf4a345f7 in memcpy (__len=, __src=0xffe44df0, 
__dest=)
at /usr/include/x86_64-linux-gnux32/bits/string_fortified.h:34
#3  QV4::ExecutionContext::newCallContext (this=, 
function=,
callData=) at jsruntime/qv4context.cpp:94
#4  0xf4a37204 in QV4::ExecutionContext::call (this=, scope=..., 
callData=,
function=, f=f@entry=0x0) at jsruntime/qv4context.cpp:274
#5  0xf4a8a648 in QV4::Script::run (this=) at 
jsruntime/qv4script.cpp:178
#6  0xf4b36b5d in QQmlScriptData::scriptValueForContext (this=, 
parentCtxt=)
at qml/qqmltypeloader.cpp:2923
#7  0xf4ba74ed in QQmlObjectCreator::create (this=, 
subComponentIndex=,
parent=, interrupt=) at 
qml/qqmlobjectcreator.cpp:196
#8  0xf4ba65ae in QQmlObjectCreator::createInstance (this=this@entry=0x22aa940, 
index=3,
parent=, isContextObject=isContextObject@entry=false) at 
qml/qqmlobjectcreator.cpp:1183
#9  0xf4ba47d6 in QQmlObjectCreator::setPropertyBinding 
(this=this@entry=0x22aa940,
property=property@entry=0xe85723f8, binding=binding@entry=0xf7f97630) at 
qml/qqmlobjectcreator.cpp:827
#10 0xf4ba5114 in QQmlObjectCreator::setupBindings (this=this@entry=0x22aa940,
applyDeferredBindings=applyDeferredBindings@entry=false) at 
qml/qqmlobjectcreator.cpp:779
#11 0xf4ba5973 in QQmlObjectCreator::populateInstance 
(this=this@entry=0x22aa940, index=-1, index@entry=0,
instance=0x0, bindingTarget=0x0, 
valueTypeProperty=valueTypeProperty@entry=0x0)
at qml/qqmlobjectcreator.cpp:1408
#12 0xf4ba672b in QQmlObjectCreator::createInstance (this=this@entry=0x22aa940, 
index=index@entry=0,
parent=parent@entry=0x0, isContextObject=isContextObject@entry=true) at 
qml/qqmlobjectcreator.cpp:1272
#13 0xf4ba72cb in QQmlObjectCreator::create (this=, 
subComponentIndex=,
parent=parent@entry=0x0, interrupt=interrupt@entry=0x0) at 
qml/qqmlobjectcreator.cpp:202
#14 0xf4b18269 in QQmlComponentPrivate::beginCreate (this=, 
context=)
at qml/qqmlcomponent.cpp:864
#15 0xf4b1640f in QQmlComponent::create (this=, 
context=0x20b3f30) at qml/qqmlcomponent.cpp:773
#16 0xf5121134 in QQuickView::continueExecute() () from 
/usr/lib/x86_64-linux-gnux32/libQt5Quick.so.5
#17 0xf51216d2 in QQuickViewPrivate::execute() () from 
/usr/lib/x86_64-linux-gnux32/libQt5Quick.so.5
#18 0xf775f18c in quick_test_main(int, char**, char const*, char const*) ()
   from /usr/lib/x86_64-linux-gnux32/libQt5QuickTest.so.5
#19 0xf632e6a7 in __libc_start_main () from /lib/x86_64-linux-gnux32/libc.so.6
#20 0x004005bb in _start ()
(gdb) frame 3
#3  QV4::ExecutionContext::newCallContext (this=, 
function=,
callData=) at jsruntime/qv4context.cpp:94
(gdb) print *c
value has been optimized out
(gdb) print c->callData
value has been optimized out
(gdb) print callData
$8 = 
(gdb) print sizeof(CallData)
$9 = 24
(gdb) print sizeof(Value)
$10 = 8
(gdb) print c->locals.values
value has been optimized out
(gdb) print c->locals
value has been optimized out
(gdb) print sizeof(CallContext::Data)
$11 = 64
(gdb) print localsAndFormals
$12 = 0
(gdb) print callData->argc
value has been optimized out
(gdb) frame 2
#2  0xf4a345f7 in memcpy (__len=, __src=0xffe44df0, 
__dest=)
at /usr/include/x86_64-linux-gnux32/bits/string_fortified.h:34
34return __builtin___memcpy_chk (__dest, __src, __len, __bos0 (__dest));
(gdb) disas
Dump of assembler code for function 
QV4::ExecutionContext::newCallContext(QV4::Function*, QV4::CallData*):
   0xf4a344e0 <+0>: push   %r15
[…]
   0xf4a345d7 <+247>:   cmp%eax,%edi
   0xf4a345d9 <+249>:   jne0xf4a345d0 

   0xf4a345db <+251>:   mov%edi,0x4(%ebx)
   0xf4a345df <+255>:   mov0x0(%ebp),%eax
   0xf4a345e3 <+259>:   mov%rbp,%rsi
   0xf4a345e6 <+262>:   mov%ecx,0xc(%esp)
   0xf4a345eb <+267>:   lea0x10(,%rax,8),%edx
   0xf4a345f2 <+274>:   callq  0xf4927b70 
=> 0xf4a345f7 <+279>:   mov0xc(%esp),%ecx
   0xf4a345fc <+284>:   mov0x14(%ecx),%eax
   0xf4a34600 <+288>:   cmp%eax,0x0(%ebp)
   0xf4a34604 <+292>:   jge0xf4a34633 

[…]
(gdb) frame 1
#1  0x02290450 in ?? ()
(gdb) disas
No function contains program counter for selected frame.
(gdb) frame 0
#0  0xf7f96035 in ?? ()
(gdb) disas
No function contains program counter for selected frame.

This looks like a jump into nothing… from a call to memcpy?

Bug#895376: frown FTBFS: Encountered missing dependencies: base <4.10

[Adrian Bunk]

Source: frown
Version: 0.6.2.3-5
Severity: serious

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

...
Configuring frown-0.6.2.3...
CallStack (from HasCallStack):
  die', called at libraries/Cabal/Cabal/Distribution/Simple/Configure.hs:948:20 
in Cabal-2.0.1.0:Distribution.Simple.Configure
  configureFinalizedPackage, called at 
libraries/Cabal/Cabal/Distribution/Simple/Configure.hs:470:12 in 
Cabal-2.0.1.0:Distribution.Simple.Configure
  configure, called at libraries/Cabal/Cabal/Distribution/Simple.hs:570:20 in 
Cabal-2.0.1.0:Distribution.Simple
  confHook, called at 
libraries/Cabal/Cabal/Distribution/Simple/UserHooks.hs:67:5 in 
Cabal-2.0.1.0:Distribution.Simple.UserHooks
  configureAction, called at 
libraries/Cabal/Cabal/Distribution/Simple.hs:174:19 in 
Cabal-2.0.1.0:Distribution.Simple
  defaultMainHelper, called at 
libraries/Cabal/Cabal/Distribution/Simple.hs:119:27 in 
Cabal-2.0.1.0:Distribution.Simple
  defaultMain, called at Setup.hs:11:8 in main:Main
hlibrary.setup: Encountered missing dependencies:
base <4.10
make: *** [/usr/share/cdbs/1/class/hlibrary.mk:142: configure-ghc-stamp] Error 1

Bug#895373: flush display problem related

[Jeffrin Thalakkottoor]

Package: gnome-terminal
Version: 3.28.0-1



hello,

i  gave a debian source build on gnome terminal  and
after to an extent time the  gnome terninal window disappeared.
may be this happened when  my laptop screen went  idle related.


gnome-terminal-[6835]: Error flushing display: Resource temporarily
unavailable
Apr 10 03:33:58 debian systemd[1357]: gnome-terminal-server.service: Main
process exited, code=exited, status=1/FAILURE
gnome-terminal-server.service: Failed with result 'exit-code'.


Linux debian 4.8.0-2-amd64 #1 SMP Debian 4.8.11-1 (2016-12-02) x86_64
GNU/Linux

VGA compatible controller: Intel Corporation HD Graphics (rev 09)

$xrandr
Screen 0: minimum 320 x 200, current 1366 x 768, maximum 8192 x 8192
XWAYLAND0 connected 1366x768+0+0 (normal left inverted right x axis y axis)
340mm x 190mm
   1366x768  60.15*+
$

libglib2.0-0:amd64   2.56.0-6

--
software engineer
rajagiri school of engineering and technology

Bug#895370: lintian: maintainer-script-should-not-use-recursive-chown-or-chmod should also look for find.*exec.*chown

[Chris Lamb]

Hi dkg!

> I note the first half of the regex looks for chown and chmod, but the
> last half looks only for chown.  maybe look for chmod on the last half
> too?

Ah, of course! Fixed in:

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


> also, my last name has no "e" in it :P

Oh dear... I have no idea how that snuck in. Fixed in:

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

> thanks for the prompt action, Lamby!

No problem. But on that note, I'm very much a "lamby" rather than
a "Lamby" ;-)


Best wishes,

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

Bug#895372: dulwich: TypeError in deprecation warning

[Paul Gevers]

Source: dulwich
Version: 0.19.1-1
Severity: normal
User: ci-t...@tracker.debian.org
Usertags: triggers
Affects: xandikos

Since some weeks ci.debian.net is running autopkgtests in testing with
packages that try to migrate from unstable. With the upload of version
0.19.1-1 of dulwich, the autopkgtest of xandikos in testing¹ started to
fail.

If I interpret the error message correctly (please just close this bug
if I am mistaken), the autopkgtest hit a deprecation warning in dulwich
that errors out on a TypeError.

Traceback (most recent call last):
  File "/usr/lib/python3.6/wsgiref/handlers.py", line 137, in run
self.result = application(self.environ, self.start_response)
  File "/usr/lib/python3/dist-packages/xandikos/web.py", line 905, in
__call__
return self._inner_app(environ, start_response)
  File "/usr/lib/python3/dist-packages/xandikos/webdav.py", line 1787,
in __call__
return do.handle(environ, start_response, self)
  File "/usr/lib/python3/dist-packages/xandikos/webdav.py", line 1397,
in handle
unused_href, path, r = app._get_resource_from_environ(environ)
  File "/usr/lib/python3/dist-packages/xandikos/webdav.py", line 1744,
in _get_resource_from_environ
r = self.backend.get_resource(path)
  File "/usr/lib/python3/dist-packages/xandikos/web.py", line 805, in
get_resource
return store.get_member(name)
  File "/usr/lib/python3/dist-packages/xandikos/web.py", line 260, in
get_member
for (fname, content_type, fetag) in self.store.iter_with_etag():
  File "/usr/lib/python3/dist-packages/xandikos/store/git.py", line 217,
in iter_with_etag
for (name, mode, sha) in self._iterblobs(ctag):
  File "/usr/lib/python3/dist-packages/xandikos/store/git.py", line 625,
in _iterblobs
for (name, sha, mode) in index.iterblobs():
  File "/usr/lib/python3/dist-packages/dulwich/index.py", line 278, in
iterblobs
warnings.warn(PendingDeprecationWarning, 'Use iterobjects() instead.')
TypeError: category must be a Warning subclass, not 'str'

The autopkgtest in unstable are fine, I assume that xandikos is not
using the deprecated code anymore.

Paul

¹ https://ci.debian.net/packages/x/xandikos/testing/amd64/



signature.asc
Description: OpenPGP digital signature

Bug#893663: freeplane: CVE-2018-1000069 XXE vulnerability

[Felix Natter]

Salvatore Bonaccorso  writes:

> Hi Felix,

hello Salvatore,

> Sorry for the delay in getting back to you.
>
> On Fri, Apr 06, 2018 at 09:40:40PM +0200, Felix Natter wrote:
>> hello Security Team,
>> 
>> here are the CVE-2018-169 security updates for jessie and stretch:
>> 
>> [jessie]
>> https://anonscm.debian.org/cgit/pkg-java/freeplane.git/log/?h=jessie-CVE-2018-169
>> (jessie-CVE-2018-169 branch)
>> 
>> [stretch]
>> https://anonscm.debian.org/cgit/pkg-java/freeplane.git/log/?h=stretch-CVE-2018-169
>> (stretch-CVE-2018-169 branch)
>> 
>> Both are tested:
>> - builds
>> - activation log message is seen
>> - Save and Load XML works
>> 
>> In what format would you like the "tested packages"? *.deb?
>> 
>> Here is the corrsponding upstream commit:
>> https://github.com/freeplane/freeplane/commit/a5dce7f9f
>> 
>> The debdiffs are attached.
>
> Debdiffs looks good to me. I just have a question, for the
> jessie-debdiff: In the ScriptingRegistration.java was the removal of
> the import of org.freeplane.n3.nanoxml.XMLParserFactory not done on
> purpose?

Yes and no. On jessie the patch did not cleanly apply, so I would have
had to apply that change manually. Since removing the import has no
effect on the semantics of the program (as long as it still compiles), I
was too lazy. It should be ok.

> Other than that, when above question commented on, feel free to upload
> to security-master (AFICS you will need a sponsor, but guess Markus
> will cime in here as well). Remember that both needs to be build with
> -sa.

May I ask why the full source must be included?

@Markus: Would you be so kind to take care of uploading?

Cheers and Best Regards,
-- 
Felix Natter
debian/rules!

Bug#895370: lintian: maintainer-script-should-not-use-recursive-chown-or-chmod should also look for find.*exec.*chown

[Daniel Kahn Gillmor]

On Tue 2018-04-10 18:37:06 +0100, Chris Lamb wrote:
> Thanks for looking at this. Fixed in Git with a testcase, pending upload:
>
>   
> https://anonscm.debian.org/git/lintian/lintian.git/commit/?id=52e1bfac52ddba315ba66778570eb00b10c473de

thanks for the prompt action, Lamby!

i note the first half of the regex looks for chown and chmod, but the
last half looks only for chown.  maybe look for chmod on the last half
too?

also, my last name has no "e" in it :P

> (Can you point to a package that appears to have moved to find(1) to bypass
> the Lintian warning? I looked at lava-server but could not see anything in
> the changelog that was relevant.)

https://salsa.debian.org/ruby-team/schleuder/commit/644ad3de296e3328ca6ed0e70a41b30515e33b4a

Regards,

--dkg


signature.asc
Description: PGP signature

Bug#895370: lintian: maintainer-script-should-not-use-recursive-chown-or-chmod should also look for find.*exec.*chown

[Antoine Beaupre]

On Tue, Apr 10, 2018 at 06:37:06PM +0100, Chris Lamb wrote:
> Thanks for looking at this. Fixed in Git with a testcase, pending upload:
> 
>   
> https://anonscm.debian.org/git/lintian/lintian.git/commit/?id=52e1bfac52ddba315ba66778570eb00b10c473de

Dang you're quick! :)

> (Can you point to a package that appears to have moved to find(1) to bypass
> the Lintian warning? I looked at lava-server but could not see anything in
> the changelog that was relevant.)

There are a bunch. An example dkg gave me is:

https://salsa.debian.org/ruby-team/schleuder/commit/644ad3de296e3328ca6ed0e70a41b30515e33b4a

then he also found this:

https://sources.debian.org/src/4store/1.1.6+20151109-2/debian/4store.init/?hl=47#L47

Then of course there's the broader:

https://codesearch.debian.net/search?q=find.*exec.*chown=1

At the time of writing:

112256 files grepped (75 results)

Cheers!

A.


signature.asc
Description: PGP signature

Bug#830876: A new love version has been released

[Kotajacob]

Greetings,

Love version 11.0.0 was just released a few days ago with some new features and 
it is no longer backwards compatible with love 0.10.2. I've noticed this 
package is still on 0.9.1 which was released just over 4 years ago now. I was 
wondering what needs to be worked on to get this up to date so that we can 
hopefully have the new version of love shipping with Debian 10. I'd be more 
than happy to help package it or resolve problems with packaging it if that is 
needed as I use love2d on Debian daily.

(11.0.0 wasn't a typo they changed their versioning system to better reflect 
the projects state with semantic versioning.)

Thanks,
- kota

Bug#895363: only 32-bit images shown for "Download an OS" on amd64 machine

[Jeremy Bicha]

Control: forwarded -1 https://gitlab.gnome.org/GNOME/gnome-boxes/issues/196

Thank you!

Jeremy

Bug#895363: only 32-bit images shown for "Download an OS" on amd64 machine

[Roderich Schupp]

On Tue, Apr 10, 2018 at 5:25 PM, Jeremy Bicha  wrote:

> I can confirm this issue on Ubuntu 18.04. Could you please forward
> this issue to GNOME?
>

Done, https://gitlab.gnome.org/GNOME/gnome-boxes/issues/196

Bug#885947: marco: After updating, restart (user or pc) and log in, desktop fails

[Santiago]

Package: marco
Version: 1.18.1-3
Followup-For: Bug #885947

Dear Maintainer, if I upgrade the following retained packages to the latest 
version, follow the same problem. 

marco (1.18.1-3 => 1.20.1-1)
marco-common (1.18.1-3 => 1.20.1-1)
libmarco-private1 (1.18.1-3 => 1.20.1-1)

Regards.


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

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

Versions of packages marco depends on:
ii  libatk1.0-0   2.28.1-1
ii  libc6 2.27-3
ii  libcairo-gobject2 1.15.10-1
ii  libcairo2 1.15.10-1
ii  libcanberra-gtk3-00.30-6
ii  libcanberra0  0.30-6
ii  libgdk-pixbuf2.0-02.36.11-2
ii  libglib2.0-0  2.56.0-4
ii  libgtk-3-03.22.29-3
ii  libgtop-2.0-112.38.0-2
ii  libice6   2:1.0.9-2
ii  libmarco-private1 1.18.1-3
ii  libpango-1.0-01.42.0-1
ii  libpangocairo-1.0-0   1.42.0-1
ii  libsm62:1.2.2-1+b3
ii  libstartup-notification0  0.12-5
ii  libx11-6  2:1.6.5-1
ii  libxcomposite11:0.4.4-2
ii  libxcursor1   1:1.1.15-1
ii  libxdamage1   1:1.1.4-3
ii  libxext6  2:1.3.3-1+b2
ii  libxfixes31:5.0.3-1
ii  libxinerama1  2:1.1.3-1+b3
ii  libxrandr22:1.5.1-1
ii  libxrender1   1:0.9.10-1
ii  marco-common  1.18.1-3
ii  mate-desktop-common   1.20.1-1
ii  zenity3.28.0-1

marco recommends no packages.

marco suggests no packages.

-- no debconf information

Bug#895371: ejabberd: conffile edited using ucf

[Jonas Smedegaard]

Package: ejabberd
Version: 18.03-1
Severity: serious
Justification: Policy 10.7.3

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

The file /etc/default/ejabberd is registered as a conffile, but is also
manipulated using ucf in postinst script.  That is illegal, according to
Policy § 10.7.3:

> The easy way to achieve this behavior is to make the configuration
> file a conffile. This is appropriate only if it is possible to
> distribute a default version that will work for most installations,
> although some system administrators may choose to modify it. This
> implies that the default version will be part of the package
> distribution, and must not be modified by the maintainer scripts
> during installation (or at any other time).


 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAlrM9r8ACgkQLHwxRsGg
ASELFxAAlE2hJjPNX1UAp309gifGF3ayh5Xvzbo2W+c3W5BMNz+xH4f83zoVmk2M
423gXz1IMO92fT+cy9NT5btCJAwQN9wKpqveM/cQLJoqq0MQcI8EyDAhEyXeEZ4r
cu1XjbSbg8uN+5WEijEVlN7aQbPAscT8VlJcy68tdBLuwiL2mgNoGCHg7QgHLZkt
WIYfuuaRosuQn82bo9pftrVjQZxswmcnYBTsf4FTnUGx0JjG5Vbce6vUtdHu4R1L
ZeBCXtgaUp6h0apy+CF+7jE8cA/HtgUvIAR6QhciDXefvE3rhuK/cb+NNo4DaGfi
/2/Hg2KaN0tzLRnniF4pZvZdLs6w9Qm0dTzSTeq/lQ8bpCv7/2EdBdIxTUTZyf5r
IYP9Wb6JLgtzS16r6irYL1MGXtIzyj1Ll8MOf7d12A21wDacSyZbfp5wZ86QGEwK
aGbiNNu937bg79smfTNO16G9D+glYTrpFJdFl6dULOnP9SMB5EAvCLeLk+8UqwYT
yofc87VIuq0lLI5sSwwKCck30w/ovekB1bbGw4Y7e0/UxFdcZDkr5tPLRqjsNzM5
A8Dp9Jq0/IWr82prtSnf//AKbS/WEthsYuiLZfAldrBIrZWQf2+HX+Jnw0LRV7iS
My8e7R8jA7o0j+aHkM4rjAi+te4kvekpYIVzFoBDXwhFDg88whc=
=eXEr
-END PGP SIGNATURE-

Bug#895311: josm: java.lang.NoSuchMethodError when downloading data

[Sebastiaan Couwenberg]

On 04/10/2018 07:22 PM, Vincent Privat wrote:
> JOSM should display an error stacktrace in the bug report dialog. We need
> it to investigate this issue, could you please copy/paste it here?

The error is triggered when an imagery layer is added.]

This issue caused me to remove support for openjdk-8 from the josm
package as documented in the changelog.

Kind Regards,

Bas
{{{
Build-Name:Debian
Build-Date:2018-04-03 18:33:05
Revision:13576
Is-Local-Build:false
Debian-Release:0.0.svn13576+dfsg-3

Identification: JOSM/1.5 (13576 Debian en) Linux Debian GNU/Linux unstable (sid)
Memory Usage: 657 MB / 1774 MB (371 MB allocated, but free)
Java version: 1.8.0_162-8u162-b12-1-b12, Oracle Corporation, OpenJDK 64-Bit 
Server VM
Screen: :0.0 1920x1200
Maximum Screen Size: 1920x1200
Java package: openjdk-8-jre:amd64-8u162-b12-1
Java ATK Wrapper package: libatk-wrapper-java:all-0.33.3-20
VM arguments: [-Djosm.restart=true, -Djava.net.useSystemProxies=true]
Program arguments: [${HOME}/multimedia/osm/projects/areas/old-style.osm.pbf]
Dataset consistency test: No problems found

Plugins:
+ AddrInterpolation (34109)
+ DirectUpload (34109)
+ FixAddresses (34109)
+ HouseNumberTaggingTool (34109)
+ OpeningHoursEditor (34095)
+ RoadSigns (34109)
+ SimplifyArea (34109)
+ apache-commons (34109)
+ buildings_tools (34109)
+ download_along (34081)
+ editgpx (34109)
+ ejml (34126)
+ geojson (80)
+ geotools (34125)
+ jts (34038)
+ opendata (34132)
+ pbf (34109)
+ poly (34098)
+ reverter (34109)
+ terracer (34109)
+ todo (30303)
+ turnlanes (34109)
+ turnrestrictions (34129)
+ utilsplugin2 (34109)
+ waydownloader (34109)
+ wikipedia (34109)

Tagging presets:
+ /usr/share/josm/data/defaultpresets.xml

Map paint styles:
- /usr/share/josm/styles/standard/potlatch2.mapcss
- /plugins/ods-bag/Ods-bag-style-0.6.8.mapcss

Last errors/warnings:
- E: Invalid Bounds: Bounds[0.0,0.0,0.0,0.0]
- E: Handled by bug report queue: java.lang.NoSuchMethodError: 
java.nio.ByteBuffer.flip()Ljava/nio/ByteBuffer;


=== REPORTED CRASH DATA ===
BugReportExceptionHandler#handleException:
No data collected.

Warning issued by: BugReportExceptionHandler#handleException

=== STACK TRACE ===
Thread: AWT-EventQueue-0 (18) of main
java.lang.NoSuchMethodError: java.nio.ByteBuffer.flip()Ljava/nio/ByteBuffer;
at 
org.apache.commons.jcs.auxiliary.disk.block.BlockDisk.readBlock(BlockDisk.java:336)
at 
org.apache.commons.jcs.auxiliary.disk.block.BlockDisk.read(BlockDisk.java:291)
at 
org.apache.commons.jcs.auxiliary.disk.block.BlockDiskCache.verifyDisk(BlockDiskCache.java:214)
at 
org.apache.commons.jcs.auxiliary.disk.block.BlockDiskCache.(BlockDiskCache.java:145)
at 
org.apache.commons.jcs.auxiliary.disk.block.BlockDiskCacheFactory.createCache(BlockDiskCacheFactory.java:60)
at 
org.apache.commons.jcs.auxiliary.disk.block.BlockDiskCacheFactory.createCache(BlockDiskCacheFactory.java:33)
at 
org.openstreetmap.josm.data.cache.JCSCacheManager.getCacheInner(JCSCacheManager.java:182)
at 
org.openstreetmap.josm.data.cache.JCSCacheManager.getCache(JCSCacheManager.java:164)
at 
org.openstreetmap.josm.gui.layer.AbstractCachedTileSourceLayer.getCache(AbstractCachedTileSourceLayer.java:87)
at 
org.openstreetmap.josm.gui.layer.AbstractCachedTileSourceLayer.(AbstractCachedTileSourceLayer.java:63)
at org.openstreetmap.josm.gui.layer.TMSLayer.(TMSLayer.java:55)
at 
org.openstreetmap.josm.gui.layer.ImageryLayer.create(ImageryLayer.java:204)
at 
org.openstreetmap.josm.actions.AddImageryLayerAction.actionPerformed(AddImageryLayerAction.java:143)
at 
javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:2022)
at 
javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2348)
at 
javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:402)
at 
javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:259)
at javax.swing.AbstractButton.doClick(AbstractButton.java:376)
at 
javax.swing.plaf.basic.BasicMenuItemUI.doClick(BasicMenuItemUI.java:842)
at 
javax.swing.plaf.basic.BasicMenuItemUI$Handler.mouseReleased(BasicMenuItemUI.java:886)
at 
java.awt.AWTEventMulticaster.mouseReleased(AWTEventMulticaster.java:289)
at java.awt.Component.processMouseEvent(Component.java:6533)
at javax.swing.JComponent.processMouseEvent(JComponent.java:3324)
at java.awt.Component.processEvent(Component.java:6298)
at java.awt.Container.processEvent(Container.java:2237)
at java.awt.Component.dispatchEventImpl(Component.java:4889)
at java.awt.Container.dispatchEventImpl(Container.java:2295)
at java.awt.Component.dispatchEvent(Component.java:4711)
at 
java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4889)
at java.awt.LightweightDispatcher.processMouseEvent(Container.java:4526)
at 

Bug#895370: lintian: maintainer-script-should-not-use-recursive-chown-or-chmod should also look for find.*exec.*chown

[Chris Lamb]

tags 895370 + pending
thanks

Hi dkg!

Thanks for looking at this. Fixed in Git with a testcase, pending upload:

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

(Can you point to a package that appears to have moved to find(1) to bypass
the Lintian warning? I looked at lava-server but could not see anything in
the changelog that was relevant.)


Best wishes,

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

Bug#895311: josm: java.lang.NoSuchMethodError when downloading data

[Vincent Privat]

Hello Vincent,
JOSM should display an error stacktrace in the bug report dialog. We need
it to investigate this issue, could you please copy/paste it here?
Cheers,
Vincent

2018-04-09 20:55 GMT+02:00 Vincent Smeets :

> Package: josm
> Version: 0.0.svn13576+dfsg-3
> Severity: important
>
> It is not possible to download any data.
>
> Reproduced by:
> - Start josm
> - Press the "Download data" button
> => An error dialog opens the reports that an unexpected exception
>occured.
>
> The log output reports the exception:
>   2018-04-09 20:43:39.391 SEVERE: Handled by bug report queue:
> java.lang.NoSuchMethodError: java.nio.ByteBuffer.flip()
> Ljava/nio/ByteBuffer;
>   java.lang.NoSuchMethodError: java.nio.ByteBuffer.flip()
> Ljava/nio/ByteBuffer;
>
> The full output with the stack trace is attached to this report.
>
> Regards
>
> -- System Information:
> Debian Release: buster/sid
>   APT prefers testing
>   APT policy: (500, 'testing')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 4.15.0-2-amd64 (SMP w/4 CPU cores)
> Locale: LANG=nl_NL.utf8, LC_CTYPE=nl_NL.utf8 (charmap=UTF-8),
> LANGUAGE=nl_NL.utf8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> Versions of packages josm depends on:
> ii  fonts-noto 20171026-2
> ii  jmapviewer 2.7+dfsg-1
> ii  libcommons-compress-java   1.13-1
> ii  libcommons-logging-java1.2-2
> ii  libgettext-commons-java0.9.6-6
> ii  liboauth-signpost-java 1.2.1.2-1.5
> ii  libsvgsalamander-java  1.1.1+dfsg-2
> ii  openjdk-9-jre [java9-runtime]  9.0.4+12-4
> ii  proj-data  5.0.1-1
>
> Versions of packages josm recommends:
> ii  josm-l10n  0.0.svn13576+dfsg-3
>
> josm suggests no packages.
>
> -- no debconf information
>

Bug#894560: pygame: Don't drop python2 package

[Emilio Pozuelo Monfort]

Hi,

On Mon, 2 Apr 2018 00:12:58 +0200 Dominik George  wrote:
> > Your latest upload drops the python-pygame pacakge but I count 35
> > packages in Debian Testing that depend on it. Please restore the
> > python-pygame package until all those packages no longer depend on it.
> > 
> > Even without a bug being filed, I believe the broken dependency issue
> > would have prevented this package from migrating to Testing.
> 
> So, what's the use of that?
> 
> I do not target for testing - I target for buster and for sid.  Neither
> pygame nor its dependencies, using Python 2, will survive the buster release
> cycle, so there is no point in forcefully keeping it around in testing.  And
> as you said: Non of this will transition until the problem is solved (either
> by removal of the dependencies or their switch to Python 3).
> 
> All that will happen with and without the Python 2 version of Pygame.

As Jeremy said, Python 2 will be shipped with buster, so all this seems
premature. But even if you were right, this is pretty rushed and uncoordinated.
A better way to handle this would be:

- Send a mail to debian-devel@ explaining this, with a list of rdeps
- Do a MBF (mass bug filing) against all the rdeps, asking to move to Python 3,
  with severity important
- After enough time has passed, bump the severity to serious
- After some time, many unfixed rdeps will be auto-removed from testing

Then it would be time to drop python-pygame, as it would be easier to finish the
transition. This also means that during all these time, new versions of pygame
can transition to testing.

Of course the last two steps shouldn't happen during the buster cycle if
python2.7 isn't going to be dropped.

Right now all you are managing is to stall the new pygame version in unstable as
britney can't migrate it until all the rdeps are fixed or removed. So I'd
suggest to reintroduce python-pygame and to poke the rdeps so they start working
on this.

Cheers,
Emilio

Bug#895370: lintian: maintainer-script-should-not-use-recursive-chown-or-chmod should also look for find.*exec.*chown

[Daniel Kahn Gillmor]

Package: lintian
Version: 2.5.81
Severity: normal

i've seen a few places in the debian archive where maintscripts or
initscripts avoid chown -R by using something like:


find /etc/lava-server/dispatcher.d/ -maxdepth 1 -exec chown 
$LAVA_SYS_USER:$LAVA_SYS_USER {}

 (the above is from lava-server.postinst; similar things found in
 openguides, 4store, schleuder, jwchat, firebird3.0, etc)

This presents the exact same risk as "chown -R", but it's not captured
at all by the current matcher.  even worse, it appears that some of
these techniques are done specifically because they think it avoids
the problem of chown -R (e.g. 4store.init has a TOCTOU race condition
that leaves it vulnerable, but is commented as "avoiding "chown -R
hardlink attacks")

I think the lintian test should check for something like:

   find.*exec.*chown

as well as looking for chown -R.

   --dkg



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

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

Versions of packages lintian depends on:
ii  binutils  2.30-8
ii  bzip2 1.0.6-8.1
ii  diffstat  1.61-1+b1
ii  dpkg  1.19.0.5
ii  file  1:5.32-2
ii  gettext   0.19.8.1-6
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.5
ii  libemail-valid-perl   1.202-1
ii  libfile-basedir-perl  0.07-1
ii  libipc-run-perl   0.99-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-5
ii  libtext-levenshtein-perl  0.13-1
ii  libtimedate-perl  2.3000-2
ii  liburi-perl   1.73-1
ii  libxml-simple-perl2.25-1
ii  libyaml-libyaml-perl  0.69+repack-1
ii  man-db2.8.2-1
ii  patchutils0.3.4-2
ii  perl  5.26.1-5
ii  t1utils   1.41-2
ii  xz-utils  5.2.2-1.3

Versions of packages lintian recommends:
pn  libperlio-gzip-perl  

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

-- no debconf information

Bug#895368: pymoc: don't try to run python upstream testsuite on archs without healpy

[Steve Langasek]

Package: pymoc
Version: 0.5.0-2
Severity: minor
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu bionic ubuntu-patch

Dear maintainers,

Whereas Debian currently only regularly runs autopkgtests for amd64, in
Ubuntu, we run the autopkgtests across all architectures.  The pymoc
autopkgtests fail on several architectures, because they depend on
python{,3}-healpy, which has a hard-coded architecture list of [amd64 arm64
ppc64el].  However, pymoc itself only Suggests: python{,3}-healpy, implying
the package is still usable and should still be made available on these
other architectures, but the tests are wrong for these architectures.

I have uploaded the attached patch to Ubuntu, to architecture-restrict the
running of the upstream test suite as an autopkgtest; this allows us to
still run the 'pymoctool' autopkgtest and gather successful test results on
these architectures, rather than having to entirely ignore these test
results.

Please consider including this change in Debian as well.

Thanks,
-- 
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 pymoc-0.5.0/debian/tests/control pymoc-0.5.0/debian/tests/control
--- pymoc-0.5.0/debian/tests/control2018-02-22 00:42:32.0 -0800
+++ pymoc-0.5.0/debian/tests/control2018-04-09 23:32:42.0 -0700
@@ -1,9 +1,9 @@
 Tests: upstream-python3-pymoc
-Depends: python3-pymoc, python3-healpy
+Depends: python3-pymoc, python3-healpy [amd64 arm64 ppc64el]
 Restrictions: allow-stderr
 
 Tests: upstream-python-pymoc
-Depends: python-pymoc, python-healpy
+Depends: python-pymoc, python-healpy [amd64 arm64 ppc64el]
 Restrictions: allow-stderr
 
 Tests: pymoctool
diff -Nru pymoc-0.5.0/debian/tests/upstream-python3-pymoc 
pymoc-0.5.0/debian/tests/upstream-python3-pymoc
--- pymoc-0.5.0/debian/tests/upstream-python3-pymoc 2018-02-21 
06:57:29.0 -0800
+++ pymoc-0.5.0/debian/tests/upstream-python3-pymoc 2018-04-10 
09:44:09.0 -0700
@@ -1,5 +1,13 @@
 #!/bin/sh
 # per example given in README.rst
 echo "exec upstream unittests under Python 3"
+case $(dpkg --print-architecture) in
+amd64|arm64|ppc64el)
+;;
+*)
+echo "SKIPPED: healpy not available on this architecture"
+exit 0
+;;
+esac
 exec python3 -m unittest
 
diff -Nru pymoc-0.5.0/debian/tests/upstream-python-pymoc 
pymoc-0.5.0/debian/tests/upstream-python-pymoc
--- pymoc-0.5.0/debian/tests/upstream-python-pymoc  2018-02-21 
06:57:29.0 -0800
+++ pymoc-0.5.0/debian/tests/upstream-python-pymoc  2018-04-10 
09:44:22.0 -0700
@@ -1,4 +1,12 @@
 #!/bin/sh
 # per example given in README.rst
 echo "exec upstream unittests under Python 2"
+case $(dpkg --print-architecture) in
+amd64|arm64|ppc64el)
+;;
+*)
+echo "SKIPPED: healpy not available on this architecture"
+exit 0
+;;
+esac
 exec python2 -m unittest discover

Bug#895369: regressions that don't match expected failures.

[Jeffrin Thalakkottoor]

Package: glibc
Version: 2,27-3

hello ,

found regression during debian build of glibc.

+-+
| Encountered regressions that don't match expected failures. |
+-+
FAIL: misc/tst-preadvwritev2
FAIL: misc/tst-preadvwritev64v2
make: *** [debian/rules.d/build.mk:115:
/home/jeffrin/build/glibc-2.27/stamp-dir/check_i386] Error 1
dpkg-buildpackage: error: debian/rules build subprocess returned exit
status 2

gcc (Debian 7.3.0-15) 7.3.0
g++ (Debian 7.3.0-15) 7.3.0

libc6:amd642.27-3

Linux debian 4.8.0-2-amd64 #1 SMP Debian 4.8.11-1 (2016-12-02) x86_64
GNU/Linux

a typical screenshot is attached

--
software engineer
rajagiri school of engineering and technology
*  invalid macro `VDISCARD'
*  invalid macro `OLCUC'
*  invalid macro `TCION'
*  invalid macro `OFDEL'
*  invalid macro `ONLCR'
*  invalid macro `VREPRINT'
*  invalid macro `B57600'
*  invalid macro `IXANY'
*  invalid macro `VEOL2'
*  invalid macro `B1152000'
*  invalid macro `B921600'
*  invalid macro `B350'
*  invalid macro `B400'
*  invalid macro `B150'
*  invalid macro `B200'
*  invalid macro `CSTOPB'
** macro `CSTOPN' not defined
** macro `INCLR' not defined
=== time.h ===
*  invalid macro `TIME_UTC'
** macro `CLOCK_REALTIME' not defined
** macro `TIMER_ABSTIME' not defined
=== unistd.h ===
=== utime.h ===
--
+-+
| Encountered regressions that don't match expected failures. |
+-+
FAIL: misc/tst-preadvwritev2
FAIL: misc/tst-preadvwritev64v2
make: *** [debian/rules.d/build.mk:115: 
/home/jeffrin/build/glibc-2.27/stamp-dir/check_i386] Error 1
dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2

Bug#895367: New upstream release

[Laurent Bigonville]

Package: dkms
Version: 2.3-3
Severity: wishlist

Hi,

A new upstream release (2.5/30 Nov 2017) is out

Might be a good idea to update?

Kind regards,

Laurent Bigonville

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

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

Versions of packages dkms depends on:
ii  build-essential  12.4
ii  coreutils8.28-1
ii  dpkg-dev 1.19.0.5
ii  gcc  4:7.3.0-3
ii  kmod 25-1
ii  make 4.2.1-1
ii  patch2.7.6-2

Versions of packages dkms recommends:
ii  fakeroot 1.22-2
ii  linux-headers-amd64  4.15+91
ii  lsb-release  9.20170808
ii  sudo 1.8.21p2-3

Versions of packages dkms suggests:
pn  menu
pn  python3-apport  

-- no debconf information

Bug#892533: automake-1.15: diff for NMU version 1:1.15.1-3.1

[Emilio Pozuelo Monfort]

Control: tags 892533 + patch
Control: tags 892533 + pending

Dear maintainer,

I've prepared an NMU for automake-1.15 (versioned as 1:1.15.1-3.1) and
uploaded it.

This drops the gcj build-dep as gcj is being removed from Debian.

gcj.m4 is still shipped as it should be.

Please find attached the diff.

Cheers,
Emilio

diff -Nru automake-1.15-1.15.1/debian/changelog 
automake-1.15-1.15.1/debian/changelog
--- automake-1.15-1.15.1/debian/changelog   2017-09-17 03:41:45.0 
+0200
+++ automake-1.15-1.15.1/debian/changelog   2018-04-10 18:04:51.0 
+0200
@@ -1,3 +1,10 @@
+automake-1.15 (1:1.15.1-3.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Disable gcj support, as gcj is being removed. Closes: #892533.
+
+ -- Emilio Pozuelo Monfort   Tue, 10 Apr 2018 18:04:51 +0200
+
 automake-1.15 (1:1.15.1-3) unstable; urgency=medium
 
   * Acknowledge NMU. (Closes: #872052)
diff -Nru automake-1.15-1.15.1/debian/control 
automake-1.15-1.15.1/debian/control
--- automake-1.15-1.15.1/debian/control 2017-09-17 03:41:45.0 +0200
+++ automake-1.15-1.15.1/debian/control 2018-04-10 17:17:30.0 +0200
@@ -13,7 +13,6 @@
  emacs,
  expect,
  flex,
- gcj-jdk,
  gettext,
  gfortran,
  gobjc,

Bug#856159: libidn: diff for NMU version 1.33-2.2

[Emilio Pozuelo Monfort]

Control: tags 856159 + patch
Control: tags 856159 + pending
Control: tags 892540 + pending

Dear maintainer,

I've prepared an NMU for libidn (versioned as 1.33-2.2) and
uploaded it. Here's the diff.

Cheers,
Emilio

diff -Nru libidn-1.33/debian/changelog libidn-1.33/debian/changelog
--- libidn-1.33/debian/changelog2017-12-17 00:04:41.0 +0100
+++ libidn-1.33/debian/changelog2018-04-10 18:03:08.0 +0200
@@ -1,3 +1,16 @@
+libidn (1.33-2.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+
+  [ Matthias Klose ]
+  * Build using default-jdk instead of gcj-jdk (Closes: #892540)
+
+  [ Emilio Pozuelo Monfort ]
+  * Set libidn11 priority to optional rather than standard.
+  * Mark libidn11-dev as Multi-Arch same. (Closes: #856159)
+
+ -- Emilio Pozuelo Monfort   Tue, 10 Apr 2018 18:03:08 +0200
+
 libidn (1.33-2.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru libidn-1.33/debian/control libidn-1.33/debian/control
--- libidn-1.33/debian/control  2017-12-16 23:00:02.0 +0100
+++ libidn-1.33/debian/control  2018-04-10 17:23:25.0 +0200
@@ -5,7 +5,7 @@
 Uploaders: Simon Josefsson , Ondřej Surý 

 Standards-Version: 3.9.8
 Build-Depends: debhelper (>= 9), dh-autoreconf, autopoint (>= 0.19.3), 
help2man, texinfo
-Build-Depends-Indep: gcj-jdk, fastjar
+Build-Depends-Indep: default-jdk
 Homepage: https://www.gnu.org/software/libidn/
 Vcs-Browser: https://anonscm.debian.org/cgit/collab-maint/libidn.git
 Vcs-Git: https://anonscm.debian.org/git/collab-maint/libidn.git
@@ -28,6 +28,7 @@
 Architecture: any
 Depends: libidn11 (= ${binary:Version}), pkg-config, ${misc:Depends}
 Conflicts: libidn9-dev
+Multi-Arch: same
 Description: Development files for GNU Libidn, an IDN library
  GNU Libidn is a fully documented implementation of the Stringprep,
  Punycode and IDNA specifications.  Libidn's purpose is to encode and
@@ -38,7 +39,6 @@
  information, API man pages, and the Libidn manual.
 
 Package: libidn11
-Priority: standard
 Architecture: any
 Depends: ${shlibs:Depends}, ${misc:Depends}
 Conflicts: libidn9-dev

Bug#894096: Why is donizetti not currently producing any deltas?

[A Mennucc1]

Dear Carlos,

donizetti is producing deltas as always, but there is a long long queue.

I identified a problem.

Every ten minutes , or 20 deltas, the server in donizetti synced its
internal repository of deltas with  the public web repository 
http://debdeltas.debian.net/ . In the past this would take a few
minutes, For some unknown reasons now it takes 30minutes, sometimes 60.
So the server works roughly 1/4th of capacity.

The server keeps track of newly created deltas, so it could send only
newly created deltas to http://debdeltas.debian.net/ . Unfortunately
this is not currently supported by the debian infrastructure : only a
full sync is allowed.

To alleviate the problem, I changed the repository refresh to
120minutes, or 200 deltas . So the server should run its queue faster.

I also temporarely disabled creating deltas for the 'debian-debug' part
of the archive.

I will keep an eye on it.

a.

Il 26/03/2018 14:22, Carlos Maddela ha scritto:
> Package: debdelta
> Version: 0.60
> Severity: important
>
> Hi,
>
> Since about March 10, 2018, no new deltas have been available.
>
> The current unstable release [0.60] is not able to produce deltas for
> the current format of new debs being uploaded to the archive, although
> it is able to decode deltas produced by the unreleased version in VCS.
> Prior to the above date, deltas were being produced, so I suspect the
> version of debdelta that the donizetti server had was the unreleased
> version in VCS. Is it possible that this somehow got downgraded to the
> current unstable version?
>
> Please release the fixes in VCS. Perhaps this will make deltas available
> again.
>
> Thanks,
>
> Carlos
>
>
> -- System Information:
> Debian Release: buster/sid
>   APT prefers unstable
>   APT policy: (990, 'unstable'), (1, 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 4.15.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.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> Versions of packages debdelta depends on:
> ii  binutils2.30-8
> ii  bzip2   1.0.6-8.1
> ii  libbz2-1.0  1.0.6-8.1
> ii  libc6   2.27-2
> ii  python  2.7.14-4
> ii  zlib1g  1:1.2.8.dfsg-5
>
> Versions of packages debdelta recommends:
> ii  bsdiff   4.3-20
> ii  gnupg2   2.2.5-1
> ii  gpg-agent [gnupg-agent]  2.2.5-1
> ii  lzma 9.22-2.1
> ii  python-apt   1.6.0~rc2
> ii  python-debian0.1.32
> ii  xdelta   1.1.3-9.2
> ii  xdelta3  3.0.11-dfsg-1+b1
> ii  xz-utils [lzma]  5.2.2-1.3
>
> Versions of packages debdelta suggests:
> ii  debdelta-doc  0.60
>
> -- Configuration Files:
> /etc/debdelta/sources.conf changed [not included]
>
> -- no debconf information
>

Bug#860094: jaminid: please RM, or make the javadoc build reproducible

[Emilio Pozuelo Monfort]

Control: reassign -1 ftp.debian.org
Control: retitle -1 RM: jaminid -- RoQA; RC buggy, dead upstream, no rdeps, low 
popcon

On Tue, 11 Apr 2017 13:13:25 +0100 Chris West  
wrote:
> Source: jaminid
> Version: 0.99a-1.1
> User: reproducible-bui...@lists.alioth.debian.org
> Usertags: timestamps
> Priority: wishlist
> 
> jaminid uses dh_javadoc from gcj-jdk to generate javadocs, which leaves
> timestamps in the documentation. Please attempt to eliminate these
> timestamps, so the package can be reproducible.
> 
> 
> Alternatively, we could RM this package. Upstream is dead since ~2006.
> The maintainer appears absent (unfixed RC bugs since 2015: #802416).
> The last RC bug fix on this package was an NMU.

There's an RC bug for jaminid now (#892537) and I see no point in fixing
it given its overall situation. So let's remove it instead.

Cheers,
Emilio

Bug#895366: fetchmail: missing ip-up script, packaging updates

[Nicolas Boulenguez]

Package: fetchmail
Version: 6.3.26-3
Severity: normal
Tags: patch

Hello.

These lines in debian/rules
-install -m 644 debian/README.contrib \
install -D -m 755 debian/ip-up $(tmpdir)/etc/ppp/ip-up.d/fetchmail
fail to install README.contrib because a continuation line is missing,
do not report the problem because of the evil leading dash,
and miss installation of the ip-up script.

The attached changes refresh the packaging and incorporate patches for
this, #710319, #752598 as well as many trivial issues.

The last diff requires some attention, as switching to debhelper
compatibility level 11 changes the defaults for dh_installinit.  As
far as I understand
* "dh_installinit --restart-after-upgrade" is now the default
  and the override in debian/rules is not necessary.
* the induced changes in maintainer scripts (attached for review) seem safe.


fetchmail-suggestions.tar.gz
Description: application/gzip

Bug#895134: libwx-scintilla-perl: needs tighter dependency on Wx build?

[Niko Tyni]

On Mon, Apr 09, 2018 at 09:37:54PM +0100, Olly Betts wrote:

> I've read that ticket already, but I'm not really clear on why it
> requires the exact wxWidgets version.  If you built against wxWidgets
> 3.0.3.1 then the real requirement is $upstream_version >= 3.0.3.1 not
> $upstream_version == 3.0.3.1 (or perhaps >= some lower version if there
> were no ABI additions since that version).
> 
> Is there something more subtle here, or is this effectively an
> Alien::wxWidgets upstream design flaw which it's hard for distros to
> diverge from?

The latter I think. Upstream has decided to embed the wxWidgets version
(though with three digits not four, so 3.0.3) in the key used at runtime
to look up the build time configuration, creating a (possibly artificial)
requirement that they must match.

I guess we could patch it and/or file a wishlist bug upstream, but it
hasn't felt like a huge burden so far...

> > Another approach would be to consider this a one time glitch (how often
> > are we going to change toolkits anyway?), make libwx-perl Break older
> > (gtk2 based) libwx-scintilla-perl and libwx-glcanvas-perl versions,
> > and have those packages in turn depend on newer (gtk3 based) libwx-perl
> > versions. That should handle it afaics.
> 
> If this is only because of the gtk2 to gtk3 switch, then this makes
> sense to me.  It's the first time this will have happened since we've
> had these two packages, and only the second time in 18 years we've
> changed toolkit in the default wxwidgets packages (previously gtk1 to
> gtk2).

Right. I think we can quite reasonably assume it's the toolkit switch.

We can revisit this if we run into other incompabilities in the future.
-- 
Niko

Bug#895365: python3-aiosmtpd: missing dependency: python3-pkg-resources

[Anthony Baire]

Package: python3-aiosmtpd
Version: 1.1-5
Severity: normal

Dear Maintainer,

the 'aiosmtpd' command provided by python3-aiostmpd depends on the
pkg_resources module (which is not listed in setup.py by upstream because it
comes with setuptools)

root@76ead97fedf0:~# aiosmtpd -d -l 0.0.0.0:2500 -c 
aiosmtpd.handlers.Mailbox ~/Maildir 
Traceback (most recent call last):
  File "/usr/bin/aiosmtpd", line 6, in 
from pkg_resources import load_entry_point
ImportError: No module named 'pkg_resources'

root@76ead97fedf0:~# apt-get install python3-pkg-resources
Preparing to unpack .../python3-pkg-resources_39.0.1-2_all.deb ...
Unpacking python3-pkg-resources (39.0.1-2) ...
Setting up python3-pkg-resources (39.0.1-2) ...
root@76ead97fedf0:~# aiosmtpd -d -l 0.0.0.0:2500 -c 
aiosmtpd.handlers.Mailbox ~/Maildir 
INFO:mail.log:Server listening on 0.0.0.0:2500
INFO:mail.log:Starting asyncio loop

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

Kernel: Linux 4.9.0-6-amd64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968), LANGUAGE=C 
(charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect

Versions of packages python3-aiosmtpd depends on:
ii  python3 3.6.5-2
ii  python3-public  0.5-1

python3-aiosmtpd recommends no packages.

python3-aiosmtpd suggests no packages.

-- no debconf information

Bug#895363: only 32-bit images shown for "Download an OS" on amd64 machine

[Jeremy Bicha]

Control: severity -1 serious

On Tue, Apr 10, 2018 at 11:12 AM, Roderich Schupp
 wrote:
> When I try to use the option "Download an OS" in the "New" wizard
> only i686 images are shown, though I'm running on amd64

I can confirm this issue on Ubuntu 18.04. Could you please forward
this issue to GNOME? Let me know if you are unable to.
https://gitlab.gnome.org/GNOME/gnome-boxes/issues

You may want to mention there that the fix for
https://gitlab.gnome.org/GNOME/gnome-boxes/issues/190 seems to not be
working correctly.

I'm bumping the severity here not because this is a RC issue, but
because there's no reason to introduce a regression in Debian Buster
if we don't need to.

Thanks,
Jeremy Bicha

Bug#895008: kicad: can't start pcbnew

[Leonardo Canducci]

I've tried kicad 5 RC2 and pcbnew works fine with modern toolset
(sid+gnome+xorg+intel graphics).

2018-04-08 8:00 GMT+02:00 Carsten Schoenert :

> Hello Aurelien,
>
> On Sat, Apr 07, 2018 at 11:37:25PM +0200, Aurelien Jacobs wrote:
> ...
> > I've tested this new build, and I can now start pcbnew including with
> > latest version python-wxgtk3.0, so this seems to fix the issue. Thanks !
>
> excellent, thanks for testing, I also experienced no segfaulting issues
> any more while starting.
>
> > Now this has uncovered another GTK+3 related issue for me in pcbnew.
> > If I enable "Modern Toolset (Accelerated)" in the Preferences menu,
> > pcbnew segfaults. It looks like it might be related to using
> > wxGLCanvasX11 (ie. calling libGLX and libX11) even though this GTK+3
> > build is now using Wayland instead of X11.
>
> Hmm, I've no deeper knowledge about the internals of wayland vs. X11 so
> I probably can't help much here.
> It's known that pcbnew will crash under Wayland and the Modern Toolset
> in some cases. Please note the information on
>
> http://kicad-pcb.org/help/known-system-related-issues/#_wayland
>
> As you got a informative backtrace it mayed be a good idea to add this
> to the bug report mentioned on the above linked section. As this is now
> a different problem to the original bug report here I'd like close this
> report by a upload of this rebuilded version of src:kicad and create
> later a new report with the backtrace information from you.
>
> If you could spend some time to dig into this new issue under wayland
> I'd really appreciate this!
>
> Back to the origin of this report.
> Upstream is planning to release a RC2 of KiCad 5 with a string freeze.
> The feature freeze was done with RC1 so only bugfixing will be done on
> KiCad. I plan to upload these RC2 related version to unstable to get a
> broader base for testing.
> I don't have plans to upload a rebuild for KiCad 4.0.7 in unstable.
>
> Regards
> Carsten
>



-- 
Leonardo Canducci

Bug#892994: chromium 65.x issue with proxy

[Pascal Obry]

Same issue with version 66.0.3359.26-2.

And reverting back to 62.0.3202.89-1 makes chromium working with proxy
again.

Am I the only one to have this issue? I'm wondering, but since this is
100% reproducible I doubt...

Thanks,

-- 
  Pascal Obry /  Magny Les Hameaux (78)

  The best way to travel is by means of imagination

  http://www.obry.net

  gpg --keyserver keys.gnupg.net --recv-key F949BD3B

Bug#895364: iptables: using conntrack prevents dropping ip fragments

[Jim Pirzyk]

Package: src:linux
Version: 4.9.82-1+deb9u3
Severity: important
Tags: upstream

Dear Maintainer,

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

0) Background.  A caching resolver DNS server is vulnerable to cache poisioning 
via IP fragmentation attacks.  See 
https://ripe67.ripe.net/presentations/240-ipfragattack.pdf
According to iptables(8) man page we should be able to drop fragments *and* 
use connection tracking via the PREROUTE chain of the raw table, but this seems 
not to work.

  raw:
  This table is used mainly for configuring exemptions from 
connection tracking in combination with the NOTRACK target.
  It registers at the netfilter hooks with higher priority and 
is thus called before ip_conntrack, or any  other IP tables.
  It provides the following built-in chains: PREROUTING (for 
packets arriving via any network interface) OUTPUT (for packets
  generated by local processes)

Here are the steps to reproduce the issue:

1) Verify no existing firewall rules nor conntrack module loaded
sudo iptables -L
sudo iptables -L -t raw
lsmod | grep conn

2) Run this DNS query to verify UDP fragments are being accepted.
dig TXT t1500.frags.opendns.com @8.8.8.8

It should return something like this:

; <<>> DiG 9.10.3-P4-Debian <<>> TXT t1500.frags.opendns.com @8.8.8.8
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59486
;; flags: qr rd ra; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;t1500.frags.opendns.com.   IN  TXT

;; ANSWER SECTION:
t1500.frags.opendns.com. 18 IN  TXT 
""
t1500.frags.opendns.com. 18 IN  TXT 
""
t1500.frags.opendns.com. 18 IN  TXT 
""
t1500.frags.opendns.com. 18 IN  TXT 
""
t1500.frags.opendns.com. 18 IN  TXT 
""
t1500.frags.opendns.com. 18 IN  TXT 
""
t1500.frags.opendns.com. 18 IN  TXT 
""
t1500.frags.opendns.com. 18 IN  TXT 
""
t1500.frags.opendns.com. 18 IN  TXT 
""
t1500.frags.opendns.com. 18 IN  TXT 
""
t1500.frags.opendns.com. 18 IN  TXT 
""
t1500.frags.opendns.com. 18 IN  TXT 
""
t1500.frags.opendns.com. 18 IN  TXT 
"ddd"

;; Query time: 17 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Mon Apr 09 21:50:33 GMT 2018
;; MSG SIZE  rcvd: 1500

3) Add rule to iptables to drop fragments
sudo iptables -t raw -I PREROUTING 1 --fragment -j DROP

4) Verify rule is in place
sudo iptables -L -t raw

5) Re-run DNS query
dig TXT t1500.frags.opendns.com @8.8.8.8

It should return something like this:

; <<>> DiG 9.10.3-P4-Debian <<>> TXT t1500.frags.opendns.com @8.8.8.8
;; global options: +cmd
;; connection timed out; no servers could be reached

This means the rule is working.

6) Now load conntrack module via adding more rules to iptables
sudo iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

7) Verify rules and kernel module are loaded.
sudo iptables -L
lsmod | grep conn

8) Rerun DNS query
dig TXT t1500.frags.opendns.com @8.8.8.8

This should *not* return any results, like in step #5 but in reallity we 
get the answer from Step #2.

Here is a typescript session output:

Script started on Tue 10 Apr 2018 02:20:23 PM GMT
]0;stretch.localdomainvagrant@stretch:~/tmp
1>sudo iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source   destination 

Chain FORWARD (policy ACCEPT)
target prot opt source   destination 

Chain OUTPUT (policy ACCEPT)
target prot opt source   destination 

Bug#895363: only 32-bit images shown for "Download an OS" on amd64 machine

[Roderich Schupp]

Package: gnome-boxes
Version: 3.28.1-1
Severity: normal

When I try to use the option "Download an OS" in the "New" wizard
only i686 images are shown, though I'm running on amd64
(see attached download-os-try-1.png when filtering for "debian",
but all choices are for i686).

Minor point: when I go back to the wizard's initial page and
click on "Download an OS" again, it will list every image
twice (see attached download-os-try-2.png).

Cheers, Roderich



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

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

Versions of packages gnome-boxes depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.28.0-2
ii  libarchive13 3.2.2-3.1
ii  libc62.27-3
ii  libcairo21.15.10-2
ii  libgdk-pixbuf2.0-0   2.36.11-2
ii  libglib2.0-0 2.56.1-1
ii  libgovirt2   0.3.4-2
ii  libgtk-3-0   3.22.29-3
ii  libgtk-vnc-2.0-0 0.7.2-1
ii  libgudev-1.0-0   232-2
ii  libosinfo-1.0-0  1.1.0-1
ii  libosinfo-bin1.1.0-1
ii  libpango-1.0-0   1.42.1-1
ii  librest-0.7-00.8.0-2
ii  libsecret-1-00.18.6-1
ii  libsoup2.4-1 2.62.0-1
ii  libspice-client-glib-2.0-8   0.34-1.1
ii  libspice-client-gtk-3.0-50.34-1.1
ii  libtracker-sparql-2.0-0  2.0.3-1
ii  libusb-1.0-0 2:1.0.21-2
ii  libvirt-daemon   4.2.0-2
ii  libvirt-glib-1.0-0   1.0.0-1
ii  libwebkit2gtk-4.0-37 2.20.0-2
ii  libxml2  2.9.7+dfsg-1
ii  mtools   4.0.18-2+b1
ii  tracker  2.0.3-1

Versions of packages gnome-boxes recommends:
ii  qemu-system-x86  1:2.11+dfsg-1

gnome-boxes suggests no packages.

-- no debconf information

Bug#895362: Testing CD/DVD Missing algif_skcipher on Power64LE (so cannot use encrypted volumes)

[Matt Corallo]

Package: linux-image-powerpc64le
Version: 4.15+91

(I know its not the right package as this is an issue only in the
testing CD, not a running system, but I can't seem to find the right
package to file against, and figure this will at least CC the right
people, sorry about that).

Pretty self-explanatory, algif_skcipher mod is missing on the weekly
buster install CD/DVD, so any time you try to use encrypted volumes you
get a cryptic error in the install prompt and a "Error allocating crypto
tfm" error in dmesg.

Bug#895361: debirf: a system fails to boot: corrupted rootfs.cxz

[Tzafrir Cohen]

Package: debirf
Version: 0.37
Severity: minor

I'vve been looking for this issue for several days: our debirf-based
system generally works well (and debirf is a great tool!). However I get
one specific system kept failing to boot.

When I break in the first-stage loader, I see that rootfs.cxz has the
right size but an incorrect md5sum (compared to the one in nest/ , and
compared to the one extracted from the initrd.cgz file on the USB device
I boot from).

Eventually my workaround was to replace the compressor from xz to gzip
(See attached patch). I did verify that the issue is not the amount of
memory in the system, as the same image boots fine in KVM with slightly
less memory.

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

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

Versions of packages debirf depends on:
ii  apt  1.4.8
ii  cpio 2.11+dfsg-6
ii  debootstrap  1.0.89
ii  fakechroot   2.19-3
ii  fakeroot 1.21-3.1
ii  klibc-utils  2.0.4-9
ii  xz-utils 5.2.2-1.2+b1

Versions of packages debirf recommends:
ii  grub-common  2.02~beta3-5
ii  lsb-release  9.20161125
ii  xorriso  1.4.6-1+b1

Versions of packages debirf suggests:
ii  syslinux-common  3:6.03+dfsg-14.1+deb9u1

-- no debconf information
>From 44c422ffd9df729d90b59c41a8f335c25913b593 Mon Sep 17 00:00:00 2001
From: Tzafrir Cohen 
Date: Tue, 10 Apr 2018 16:07:43 +0300
Subject: [PATCH] debirf: support gzip for nested rootfs

Add configuration variable DEBIRF_COMPRESS, defaults to "xz".
May also be set to "gzip". This is the compressor to use for
the nested rootfs.

For the sake of simplicity, the name of that file remains rootfs.cxz
regardless.

Gzip-compressed images are noticably larger (roughly 150% in my case).
However we had a case of an odd corruption of the xz image when the
compressor was xz (on one specific system, with an Atom D525 based Intel
board).
---
 debirf | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/debirf b/debirf
index 1e20c5c..9133a28 100755
--- a/debirf
+++ b/debirf
@@ -39,6 +39,8 @@ STAGE_ROOT=${STAGE_ROOT:-true}
 STAGE_MODULES=${STAGE_MODULES:-true}
 STAGE_INITRD=${STAGE_INITRD:-true}
 
+DEBIRF_COMPRESS=${DEBIRF_COMPRESS:xz}
+
 # warn if running as root
 ROOT_WARNING=true
 
@@ -48,6 +50,7 @@ export 
DEVICE_ARCHIVE=${DEVICE_ARCHIVE:-/usr/share/debirf/devices.tar.gz}
 # default package include/excludes
 DEBIRF_DEFAULT_PACKAGES=${DEBIRF_DEFAULT_PACKAGES:-/usr/share/debirf/packages}
 
+
 ###
 ### FUNCTIONS
 
@@ -159,7 +162,7 @@ pack_rootfs() {
 
 # abort with a failure if our attempts to build the rootfs fail:
 set -o pipefail
-fakeroot_if_needed bash -c ". $DEBIRF_COMMON && 
FAKECHROOT_EXCLUDE_PATH=/does-not-exist debirf_exec sh -c 'find * | grep -v -e 
^run/ | cpio --create -H newc'" | xz -9 > "$1"
+fakeroot_if_needed bash -c ". $DEBIRF_COMMON && 
FAKECHROOT_EXCLUDE_PATH=/does-not-exist debirf_exec sh -c 'find * | grep -v -e 
^run/ | cpio --create -H newc'" | ${DEBIRF_COMPRESS} -9 > "$1"
 }
 export -f pack_rootfs
 
@@ -215,7 +218,7 @@ if (grep -q break=preunpack /proc/cmdline); then
 fi
 cd /newroot
 echo unpacking rootfs...
-unxz - < /rootfs.cxz | cpio -i
+$DEBIRF_UNCOMRESS - < /rootfs.cxz | cpio -i
 if (grep -q break=bottom /proc/cmdline); then
   echo "honoring break=bottom kernel arg"
   /bin/sh
@@ -317,6 +320,11 @@ setup_environment() {
 # set fakechroot save file
 DEBIRF_FAKEROOT_STATE="$DEBIRF_BUILDD/.fakeroot-state.${DEBIRF_LABEL}"
 
+DEBIRF_UNCOMRESS="unxz"
+if [ "${DEBIRF_COMPRESS}" = "gzip" ]; then
+DEBIRF_UNCOMRESS="gunzip"
+fi
+
 # set the debirf distro variables based on host distro
 set_distro
 
-- 
2.11.0

Bug#873287: Fails to administer lists whose web interfaces have redirected

[Johnny A. Solbu]

On Tuesday 10. April 2018 12.47, Johnny A. Solbu wrote:
> What happens if you add the following new line below that (and install the 
> WWW::Mechanize perl module)?
> ==
> use WWW::Mechanize
> ==

It occured to me that one of the lists I administer also have this redirection.
So I tested it, and apparently adding that require did nothing. Oh well.

-- 
Johnny A. Solbu
web site,   http://www.solbu.net
PGP key ID: 0x4F5AD64DFA687324


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

Bug#895292: Restart, Suspend, Hibernate, Shut Down all greyed out in lightdm

[Vincent Lefevre]

On 2018-04-10 12:45:51 +0200, Michael Biebl wrote:
> Do you use hidepid for /proc?

No, I don't.

> > Apr  9 15:33:25 ypig dbus-daemon[2930]: [system] Successfully activated 
> > service 'org.freedesktop.ConsoleKit'
> 
> Please uninstall/purge consolekit. It's not only useless when logind is
> used, but actively harmful:
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=92

Done. But this doesn't solve the problem.

I get in /var/log/syslog:

[...]
Apr 10 15:06:46 ypig dbus-daemon[2968]: [system] Activating service 
name='org.freedesktop.login1' requested by ':1.4' (uid=0 pid=3014 
comm="/usr/sbin/lightdm ") (using servicehelper)
Apr 10 15:06:47 ypig dbus-daemon[2968]: [system] Activating service 
name='org.freedesktop.systemd1' requested by ':1.5' (uid=0 pid=3160 
comm="/lib/systemd/systemd-logind ") (using servicehelper)
Apr 10 15:06:47 ypig dbus-daemon[2968]: [system] Successfully activated service 
'org.freedesktop.login1'
Apr 10 15:06:47 ypig dbus-daemon[2968]: [system] Successfully activated service 
'org.freedesktop.systemd1'
Apr 10 15:06:59 ypig dbus-daemon[3338]: [session uid=124 pid=3336] Activating 
service name='org.a11y.Bus' requested by ':1.0' (uid=124 pid=3324 
comm="/usr/sbin/lightdm-gtk-greeter ")
Apr 10 15:06:59 ypig dbus-daemon[3338]: [session uid=124 pid=3336] Successfully 
activated service 'org.a11y.Bus'
Apr 10 15:07:08 ypig dbus-daemon[2968]: [system] Activating service 
name='org.freedesktop.PolicyKit1' requested by ':1.5' (uid=0 pid=3160 
comm="/lib/systemd/systemd-logind ") (using servicehelper)
Apr 10 15:07:08 ypig polkitd[3361]: started daemon version 0.105 using 
authority implementation `local' version `0.105'
Apr 10 15:07:08 ypig dbus-daemon[2968]: [system] Successfully activated service 
'org.freedesktop.PolicyKit1'

The lightdm.log diff:

ypig:~> logdiff -u lightdm.log-237 lightdm.log-238
[... identical lines except pid's ...]
 DEBUG: Activating VT 7
-DEBUG: Activating login1 session c1
-DEBUG: Seat seat0 changes active session to c1
-DEBUG: Session c1 is already active
 DEBUG: Greeter connected version=1.18.3 resettable=false
[... identical lines except pid's ...]

In seat0-greeter.log for systemd 237, I have:

** Message: 15:24:55.160: Starting lightdm-gtk-greeter 2.0.4 (Feb 21 2018, 
10:34:28)
** Message: 15:24:55.247: [Configuration] Reading file: 
/usr/share/lightdm/lightdm-gtk-greeter.conf.d/01_debian.conf
** Message: 15:24:55.255: [Configuration] Reading file: 
/etc/lightdm/lightdm-gtk-greeter.conf

** (lightdm-gtk-greeter:3321): WARNING **: 15:24:57.408: [PIDs] Failed to 
execute command: upstart
[...]

In seat0-greeter.log for systemd 238, I have:

** (process:3321): WARNING **: 15:06:56.930: Failed to open CK session: 
GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name 
org.freedesktop.ConsoleKit was not provided by any .service files
** Message: 15:06:58.135: Starting lightdm-gtk-greeter 2.0.4 (Feb 21 2018, 
10:34:28)
** Message: 15:06:58.206: [Configuration] Reading file: 
/usr/share/lightdm/lightdm-gtk-greeter.conf.d/01_debian.conf
** Message: 15:06:58.214: [Configuration] Reading file: 
/etc/lightdm/lightdm-gtk-greeter.conf
libGL error: failed to open drm device: Permission denied
libGL error: failed to load driver: nouveau

** (lightdm-gtk-greeter:3324): WARNING **: 15:07:00.342: [PIDs] Failed to 
execute command: upstart
[...]

So, it seems that with systemd 238, the login1 session is not
activated (and as a consequence, it tries to open a CK session,
which does not work, but this is not the issue here).

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#889715: libopenmpi-dev: problem in alternatives handling

[Laurent Bonnaud]

On 02/06/2018 01:55 PM, Alastair McKinstry wrote:

> This appears to be a downgrade from experimental 3.0.1*.

I confirm that I had experimental packages that I later downgraded.

Thanks for looking at this and for the fix!

-- 
Laurent.

Bug#895332: marked as done (flightgear: no flightgear package present in Buster repo)

[Markus Wanner]

Control: reopen -1
Control: retitle -1 flightgear: FTBFS on armel and armhf

Hello Tobias,

On 04/10/2018 02:21 PM, Debian Bug Tracking System wrote:
> This means that you claim that the problem has been dealt with.

I don't quite think that's an appropriate response. The issue clearly
hasn't been resolved, yet.

Given there's not FTBFS for the build failure on arm, I suggest we
relabel this one.

Kind Regards

Markus



signature.asc
Description: OpenPGP digital signature

Bug#826994: [Pkg-zfsonlinux-devel] Bug#826994: Updated Patch for 0.7.6-1

[Chris Dos]

Updated the patch to remove the $local_fs dependency in the zed init script.
I'm not sure of the reasoning Håkan Johansson had for that dependency.  The
zfs-zed script requires zfs-mount to be start and zfs-mount requires local
file systems to be mounted.

Chris
diff -Nru zfs-linux-0.7.6/debian/changelog zfs-linux-0.7.6/debian/changelog
--- zfs-linux-0.7.6/debian/changelog	2018-02-26 01:32:29.0 -0700
+++ zfs-linux-0.7.6/debian/changelog	2018-04-10 07:01:21.0 -0600
@@ -1,3 +1,10 @@
+zfs-linux (0.7.6-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Add sysvinit scripts. 
+
+ -- Chris Dos   Tue, 10 Apr 2018 07:01:21 -0600
+
 zfs-linux (0.7.6-1) unstable; urgency=medium
 
   [ Lev Lamberov ]
diff -Nru zfs-linux-0.7.6/debian/patches/1004-zed-service-bindir.patch zfs-linux-0.7.6/debian/patches/1004-zed-service-bindir.patch
--- zfs-linux-0.7.6/debian/patches/1004-zed-service-bindir.patch	2018-02-26 01:32:29.0 -0700
+++ zfs-linux-0.7.6/debian/patches/1004-zed-service-bindir.patch	2018-04-09 14:19:47.0 -0600
@@ -9,7 +9,7 @@
 Forwarded: no
 --- a/etc/systemd/system/zfs-zed.service.in
 +++ b/etc/systemd/system/zfs-zed.service.in
-@@ -5,7 +5,7 @@ After=zfs-import-cache.service
+@@ -5,7 +5,7 @@
  After=zfs-import-scan.service
  
  [Service]
@@ -18,3 +18,14 @@
  Restart=on-abort
  
  [Install]
+--- a/etc/init.d/zfs-functions.in
 b/etc/init.d/zfs-functions.in
+@@ -89,7 +89,7 @@
+ 
+ # Paths to what we need
+ ZFS="@sbindir@/zfs"
+-ZED="@sbindir@/zed"
++ZED="/usr/sbin/zed"
+ ZPOOL="@sbindir@/zpool"
+ ZPOOL_CACHE="@sysconfdir@/zfs/zpool.cache"
+ 
diff -Nru zfs-linux-0.7.6/debian/rules zfs-linux-0.7.6/debian/rules
--- zfs-linux-0.7.6/debian/rules	2018-02-26 01:32:29.0 -0700
+++ zfs-linux-0.7.6/debian/rules	2018-04-09 17:35:34.0 -0600
@@ -112,6 +112,26 @@
 	chmod a-x $(CURDIR)/debian/tmp/etc/zfs/zfs-functions
 	chmod a-x $(CURDIR)/debian/tmp/etc/default/zfs
 
+override_dh_installinit:
+	@# Install the /etc/init.d/zfs-import script.
+	dh_installinit -pzfsutils-linux --name=zfs-import \
+	--no-restart-on-upgrade --no-start
+
+	@# Install the /etc/init.d/zfs-mount script.
+	dh_installinit -pzfsutils-linux --name=zfs-mount \
+	--no-restart-on-upgrade --no-start
+
+	@# Install the /etc/init.d/zfs-share script.
+	dh_installinit -pzfsutils-linux --name=zfs-share \
+	--no-restart-on-upgrade --no-start
+
+	@# Add a dummy (link to /dev/null) for zfs-import.service
+	ln -s /dev/null $(CURDIR)/debian/zfsutils-linux/lib/systemd/system/zfs-import.service
+
+	@# Install the ZED init file.
+	dh_installinit -pzfs-zed --name=zfs-zed \
+	--no-restart-on-upgrade --no-start
+
 override_dh_dkms:
 	dh_dkms -V $(DEB_VERSION_UPSTREAM)
 
diff -Nru zfs-linux-0.7.6/debian/zfsutils-linux.install zfs-linux-0.7.6/debian/zfsutils-linux.install
--- zfs-linux-0.7.6/debian/zfsutils-linux.install	2018-02-26 01:32:29.0 -0700
+++ zfs-linux-0.7.6/debian/zfsutils-linux.install	2018-04-09 17:35:34.0 -0600
@@ -1,6 +1,8 @@
 ../tree/zfsutils-linux/* /
 etc/default/zfs
 etc/zfs/zfs-functions
+etc/init.d/zfs-import
+etc/init.d/zfs-mount
 etc/zfs/zpool.d/
 lib/systemd/system-preset/
 lib/systemd/system/zfs-import-cache.service
diff -Nru zfs-linux-0.7.6/debian/zfs-zed.install zfs-linux-0.7.6/debian/zfs-zed.install
--- zfs-linux-0.7.6/debian/zfs-zed.install	2018-02-26 01:32:29.0 -0700
+++ zfs-linux-0.7.6/debian/zfs-zed.install	2018-04-09 17:35:34.0 -0600
@@ -1,4 +1,6 @@
 etc/zfs/zed.d/*
+etc/init.d/zfs-zed
+etc/init.d/zfs-share
 lib/systemd/system/zfs-zed.service
 usr/lib/*/zfs/zed.d/*
 usr/sbin/zed

Bug#888993: fakeroot: "apt update" fails with "seccomp prevented execution of syscall 0000000182 on architecture powerpc"

[Tzafrir Cohen]

On Wed, Jan 31, 2018 at 07:53:18PM -0500, Daniel Kahn Gillmor wrote:
> Package: fakeroot
> Version: 1.22-2
> Severity: normal
> Control: affects -1 + debirf apt

No idea how to properly fix this. I just wanted to post a workaround.

--- /usr/share/debirf/modules/a0_prep-root  2017-05-18 19:10:07.0 
+0300
+++ minimal/modules/a0_prep-root2018-04-09 14:23:57.636397144 +0300
@@ -62,6 +62,8 @@
 debconf debconf/frontend select Noninteractive
 EOF
 
+echo 'APT::Sandbox::Seccomp "false";' > 
"${DEBIRF_ROOT}/etc/apt/apt.conf.d/20-nosecconf"
+
 # update/upgrade
 debirf_exec apt-get --yes --force-yes update
 debirf_exec apt-get --yes --force-yes upgrade


I'm using debirf of Stretch/amd64 and it works great. I tried
troubleshooting an issue with one system and tried using a Sid system
there (a Sid schroot on a Stretch system with a Stretch kernel), so I
ran into the same issue (the error message was about syscall 79).

-- 
Tzafrir Cohen | tzaf...@jabber.org | VIM is
http://tzafrir.org.il || a Mutt's
tzaf...@cohens.org.il ||  best
tzaf...@debian.org|| friend

Bug#893578: 0.7.8

[Rich]

This should probably get changed to 0.7.8, because nobody[1] should use 0.7.7.

[1] - https://github.com/zfsonlinux/zfs/issues/7401

- Rich

Bug#895360: virsh cpu-stats -> cgroup CPUACCT controller is not mounted

[Cédric Dufour - Idiap Research Institute]

Package: libvirt-daemon-system
Version: 3.0.0-4+deb9u3

Hello,

If one is to execute the following commands:
1. systemctl daemon-reload
2. service libvirtd restart
(which are likely to happen as part of regular system updates)

Subsequent virsh CPU statistics calls will fail with the following error 
messages:

# virsh cpu-stats 
error: Failed to retrieve CPU statistics for domain ''
error: Requested operation is not valid: cgroup CPUACCT controller is not 
mounted

# virsh domstats --cpu-total 
Domain: ''
[empty ouput]


Netsearching around, I stumbled on:
a. https://www.freedesktop.org/wiki/Software/systemd/ControlGroupInterface/
b. https://github.com/moby/moby/pull/20633 (similar Docker-related issue)

I can confirm the following workaround DOES solve the issue:

cat << EOF > /etc/systemd/system/libvirtd.service.d/cgroup-delegation.conf
[Service]
Delegate=yes
EOF


Would you consider adding this setting to the stock (Debian) libvirtd unit file 
?

Thank you very much and best,

Cédric


Other ref: https://answers.launchpad.net/ubuntu/+question/665132

-- 
Cédric Dufour @ Idiap Research Institute

Bug#891916: davmail: Fails to login with latest libhtmlcleaner-java version

[Mickaël Guessant]

FYI, I merged the patch in DavMail trunk and upgrader htmlcleaner to 2.21.

--
Mickael Guessant
mailto:mgues...@free.fr

Bug#895358: ruby-license-finder: package should suggest all supported package managers

[Jonas Smedegaard]

Source: ruby-license-finder
Version: 2.1.2-2
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Package description indicates that the tool is enhanced by having
certain pacakge managers available at runtime.

Looking briefly into the sources, it seems these tools are supported:

bower (not in Debian)
bundler (pkg:ruby-bundler)
cocoa_pods (not in Debian)
go_dep (not in Debian)
godep (not in Debian)
go (pkg:golang-go)
gradle (pkg:gradle)
maven (pkg:maven)
npm (pkg:npm)
NuGet (pkg:nuget)
pip (pkg:python-pip)
rebar (pkg:rebar)

If my understanding is correct that simply having those tools available
enhances the usability of ruby-license-finder, then the package should
suggest them and the reason for their suggestion possibly be mentioned
in long description of the package - for details on that last part, see
.

On a related note, the long description of ruby-license-finder-pip could
use some expansion to explain how it is different from simply installing
ruby-license-finder and python-pip.


 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAlrMsewACgkQLHwxRsGg
ASEQow//ckmsQY5DUJk/NAU0KogD81sIPKS5NI2FaNJDvOLl5DRDlrRqWAIc5ckC
5BF8r0TIiWPD0ot7LdriDb3uLr7D7EZJlROms1BoP7moxmVGYAOLcfhkM5RiQRkg
eOTQxF25sWn5EzT4QYRLZ8i+kQ8/tlYe2m2b8Cu9fRrDfPa3kMPV4pSmhst88XZC
iZsNp16/G2S/30KwmYWZsUfQVVfJ4itpZW0LB1i5EmXfFIT0o1Inh6E5xVB7j68x
BpDHx5D8BIg0KKyEoE0kRxdwMKk08s6/on+Vj6zHx3zPF9ICS4/sBZ5OsIEglfrP
pZX8hLItlvX+nCzQhZmu90atCeFkme/3c8gah7F5lP0F8Soc+ddB/EsePgH0kgqM
pjaRhFoGwtOSKWM+TU+bXDpbvPijdlmD88xSHImuuV4Kkl480u2MmkrhlXxsB2TQ
wRe0MMyNmfRh1d50tyvIvYcluhaT5LOxZ3JKacE7ALhRqOHo8lm1RFIhjKxTtGG8
ZLDotNJx244oGEDv3AL5/0XQhcgnJCCWxqmvfRAgZMN/rtsjxRHhQRkM/k8k5IKd
bq9ix46aVdBw+JsK3JD9i1d4A22V70XOAvjsuBEtYER7uV/nMGJSzUH3EY0ZsYhE
FE/gPd7hnFMzWnVj4qMmM0eHVHq9K9jgMwuN2cX4rX7FqVYoplY=
=CHRW
-END PGP SIGNATURE-

Bug#895357: libasound2: Please pakcage 1.1.6

[Christian Marillat]

Package: libasound2
Severity: normal

Dear Maintainer,

1.1.6 has been released the 4 march 2018

We still have 1.1.3 in unstable/testing

Christian

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

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

Bug#895355: ITP: rust-getopts-0.2 -- Rust library for option parsing for CLI utilities

[Wolfgang Silbermayr]

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


   Package name: rust-getopts-0.2
Version: 0.2.17
Upstream Author: The Rust Project Developers
URL: https://github.com/rust-lang/getopts
License: MIT, Apache-2.0
Description: Rust library for option parsing for CLI utilities

--

This is one of two dependencies for getting rust-pulldown-cmark-0.1
packaged (See: #895353).

Regards,
Wolfgang.

Bug#895356: ITP: rust-bitflags-0.9 -- Rust macro to generate structures which behave like a set of bitflags

[Wolfgang Silbermayr]

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


   Package name: rust-bitflags-0.9
Version: 0.9.1
Upstream Author: The Rust Project Developers
URL: https://github.com/rust-lang-nursery/bitflags
License: MIT, Apache-2.0
Description: Rust macro to generate structures which behave like a
 set of bitflags

A Rust macro to generate structures which behave like a set of bitflags

--

This is one of two dependencies for getting rust-pulldown-cmark-0.1
packaged (See: #895353).

Regards, Wolfgang.

Bug#895353: ITP: rust-pulldown-cmark-0.1 -- Pull parser for CommonMark

[Wolfgang Silbermayr]

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


   Package name: rust-pulldown-cmark-0.1
Version: 0.1.2
Upstream Author: Raph Levien 
URL: https://github.com/google/pulldown-cmark
License: MIT
Description: Pull parser for CommonMark, written in Rust.

Pulldown-cmark is a pull parser library for CommonMark, written in Rust.
It comes with a simple command-line tool, useful for rendering to HTML,
and is also designed to be easy to use from as a library.
It is designed to be:
* Fast; a bare minimum of allocation and copying
* Safe; written in pure Rust with no unsafe blocks
* Versatile; in particular source-maps are supported
* Correct; the goal is 100% compliance with the CommonMark spec

--

I suggest to use the source package name rust-pulldown-cmark-0.1 because
the main usage is as a library, e.g. in the mdbook tool or the cobalt
static site generator.

I intend to help maintaining rust-based packages in Debian, and
CommonMark seems to be a first low-hanging fruit, because it only
depends on only two other rust libraries (bitflags and getopts) which is
not common in the rust environment. It provides value as a stand-alone
command-line tool for generating HTML from CommonMark files.

Regards,
Wolfgang.

Bug#895354: RFS: ddnet/11.1.3-1

[Yangfl]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: ddnet
   Version : 11.1.3-1
   Upstream Author : Dennis Felsing
 * URL : http://ddnet.tw/
 * License : zlib (code), CC-BY-SA 3.0 (data)
   Section : games

It builds those binary packages:

  ddnet - Teeworlds modification with a unique cooperative gameplay
 ddnet-data - Data for DDNet
 ddnet-server - Server for DDNet
 ddnet-tools - Tools for DDNet

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

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


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

  dget -x https://mentors.debian.net/debian/pool/main/d/ddnet/ddnet_11.1.3-1.dsc


Regards,
 Yangfl

Bug#895283: kgb-bot: deal with branch removal webhooks

[Damyan Ivanov]

Control: tag -1 pending

-=| Mattia Rizzolo, 09.04.2018 13:46:04 +0200 |=-
> Package: kgb-bot
> Version: 1.46-1
> 
> I noticed kgb doesn't notify when a branch is removed.
> Please notify about those as well, here is example payloads:
> 
> Incidentally, I also noticed that removed tags are reported like this:
> 
> [01:37:18 PM]  Mattia Rizzolo tags 000 pbuilder tt 
> * https://deb.li/jutM

Thanks to James Clarke, the code in Git has proper support for removed 
branches/tags.

Following a package release (soon) and bot instances upgrade (soon 
after that), it will go live.


-- Damyan

Bug#895352: override: libgail-dev:oldlibs/optional, libgail18:oldlibs/optional, libgail-common:oldlibs/optional, libgtk2.0-0:oldlibs/optional, libgtk2.0-bin:oldlibs/optional, libgtk2.0-common:oldlibs/

[Simon McVittie]

Package: ftp.debian.org
Severity: normal

GTK+ 2 (src:gtk+2.0 in Debian) was superseded by GTK+ 3
(src:gtk+3.0 in Debian) with the release of GTK+ 3.0.0 in 2011. It is
still maintained, but should not be used in new projects. Please move
GTK+ 2 and its language bindings to the oldlibs section. I think this is
most of them:

libgail-common:oldlibs/optional
libgail-dev:oldlibs/optional
libgail18:oldlibs/optional
libgtk2-gst:oldlibs/optional
libgtk2-perl:oldlibs/optional
libgtk2.0-0:oldlibs/optional
libgtk2.0-bin:oldlibs/optional
libgtk2.0-cil-dev:oldlibs/optional
libgtk2.0-cil:oldlibs/optional
libgtk2.0-common:oldlibs/optional
libgtk2.0-dev:oldlibs/optional
libgtk2.0-doc:oldlibs/optional
python-gtk2-dev:oldlibs/optional
python-gtk2:oldlibs/optional
ruby-gtk2:oldlibs/optional

Thanks,
smcv

Bug#853035: [Pkg-javascript-devel] Bug#853035: node-liftoff: Non-determistically FTBFS due to unreliable timing in tests

[Graham Inggs]

For reference, I found similar timing issues and filed bugs for the
following packages:

node-foreground-child #894797
node-tap #895312
node-once #895316
node-commander #895317

In Ubuntu, we relaxed the timing of the failing tests until they
passed on all release architectures.

Bug#895351: RM: pd-osc -- ROM; no binaries, obsoleted by pd-mrpeach

[James Cowgill]

Package: ftp.debian.org
Severity: normal
X-Debbugs-CC: debian-multime...@lists.debian.org

Hi,

Please remove the pd-osc source package. Its only binary package has
been taken over by pd-mrpeach.

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#884541: llvm-toolchain-3.9: do not release with buster

[Gianfranco Costamagna]

Hello Sylvestre

>OK, once it is time, I will probably do like 3.7 (only build llvm and
>just for arm).


I really think in a month or two ghc will move to llvm 5.0, so probably not 
worth the effort
(also, llvm 3.9 has other reverse-deps right now)
# Broken Depends:
ghc: ghc [arm64 armel armhf]
ycmd: ycmd [amd64 arm64 armhf i386 mips mips64el mipsel ppc64el s390x]

G.