Bug#849637: [DSE-Dev] Bug#849637: /sys/devices/system/cpu/online SELinux context

[Laurent Bigonville]

reassign src:refpolicy 2.20161023.1-2
thanks

On Sat, 31 Dec 2016 11:34:38 +0100 cgzones  wrote:
> Wow!
>
> Thank you very much, I was completely unaware of this feature.
> I did not read any documentation of it on selinuxproject.org or in The
> SELinux Notebook v4 about it.
>
> I got it working via
>
> genfscon sysfs /devices/system/cpu/online
> gen_context(system_u:object_r:cpu_online_t,s0)
>
> at 
https://github.com/cgzones/debian-package-refpolicy/commit/3ba127468436334275398a824260383208ee58b1


Could you please try to get this patch merged upstream?

[...]
> I think otherwise this bug can be reassigned to refpolicy.

Yes I also feels it's cleaner than relabeling at boot.

Bug#849370: aptitude: Aptitude crashes with SIGABRT on install command

[Jean-Luc Coulon]

Hi Manuel,

1 - Happy 2017 for you and your family :)

2 - I've not always the problem, this explains the late answer. I get it 
100% with the curses interface, but not with the command line.


3 - Yes this occurs also with 0.8.4-1

4 - I had to rebuild the package because it is supplied stripped (the 
dbgsyms package is not supplied in the repositories).


5 - Please find attached the backtrace for "aptitude upgrade"

6 - the same with "aptitude install ssh"

Best regards

Jean-Luc
Le 31/12/2016 à 17:16, Manuel A. Fernandez Montecelo a écrit :

--args aptitude install pkgs_that_you_want_installed
Starting program: /usr/bin/aptitude install ssh
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7fffefb00700 (LWP 10942)]

Thread 1 "aptitude" received signal SIGABRT, Aborted.
__GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:58
58  ../sysdeps/unix/sysv/linux/raise.c: Aucun fichier ou dossier de ce type.
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:58
#1  0x7556040a in __GI_abort () at abort.c:89
#2  0x55732a45 in subsumes (d2=..., d1=...)
at ../../../../src/generic/apt/apt.cc:1182
#3  or_group_subsumes (d1=..., d2=..., cache=)
at ../../../../src/generic/apt/apt.cc:1205
#4  0x55734b5f in internal_is_interesting_dep (cache=0x55c41220, 
d=...) at ../../../../src/generic/apt/apt.cc:1303
#5  is_interesting_dep (d=..., cache=0x55c41220)
at ../../../../src/generic/apt/apt.cc:1344
#6  0x557564e0 in aptitude_resolver_version::dep_iterator::applicable (
dep=..., prv=..., prv_open=, cache=)
at ../../../../src/generic/apt/aptitude_resolver_universe.cc:283
#7  0x557509ad in aptitude_resolver_version::dep_iterator::applicable (
this=this@entry=0x7fffbcf0)
at ../../../../src/generic/apt/aptitude_resolver_universe.cc:302
#8  0x55750a98 in aptitude_resolver_version::dep_iterator::normalize (
this=this@entry=0x7fffbcf0)
at ../../../../src/generic/apt/aptitude_resolver_universe.cc:317
#9  0x55751c5a in aptitude_resolver_version::dep_iterator::operator++ (
this=this@entry=0x7fffbcf0)
at ../../../../src/generic/apt/aptitude_resolver_universe.cc:529
#10 0x558286c6 in aptitude_universe::dep_iterator::operator++ (
this=0x7fffbcc0)
at ../../../../src/generic/apt/aptitude_resolver_universe.h:1246
#11 generic_problem_resolver::generic_problem_resolver (
this=this@entry=0x56a52070, _step_score=_step_score@entry=-10, 
_broken_score=_broken_score@entry=-100, 
_unfixed_soft_score=_unfixed_soft_score@entry=-200, 
infinity=infinity@entry=100, 
_full_solution_score=_full_solution_score@entry=50, 
_unfixed_soft_cost=..., _future_horizon=50, _initial_state=..., 
_universe=...)
at ../../../../src/generic/problemresolver/problemresolver.h:3782
#12 0x558187d4 in aptitude_resolver::aptitude_resolver (
this=0x56a52070, step_score=-10, broken_score=-100, 
unfixed_soft_score=-200, infinity=100, resolution_score=50, 
unfixed_soft_cost=..., future_horizon=50, _cost_settings=..., 
initial_installations=..., cache=0x55c41220, _policy=0x55ba6f00)
at ../../../../src/generic/apt/aptitude_resolver.cc:731
#13 0x557a0066 in resolver_manager::create_resolver (
this=this@entry=0x55c330d0)
at ../../../../src/generic/apt/resolver_manager.cc:968
#14 0x557a1c71 in resolver_manager::maybe_create_resolver (
this=0x55c330d0, consider_policybroken=)
at ../../../../src/generic/apt/resolver_manager.cc:805
#15 0x5569693a in sigc::internal::signal_emit0::emit (
impl=0x55c33410) at /usr/include/sigc++-2.0/sigc++/signal.h:798
#16 0x55727443 in sigc::signal0::emit (
this=0x55c41380) at /usr/include/sigc++-2.0/sigc++/signal.h:2804
#17 sigc::signal0::operator() (this=0x55c41380)
at /usr/include/sigc++-2.0/sigc++/signal.h:2820
#18 aptitudeDepCache::end_action_group (this=0x55c41220, undo=0x0)
at ../../../../src/generic/apt/aptcache.cc:2336
#19 0x556b12bb in cmdline_do_action (argc=, 
argv=, status_fname=, 
simulate=, assume_yes=, 
download_only=, fix_broken=false, showvers=false, 
showdeps=false, showsize=false, showwhy=false, visual_preview=false, 
always_prompt=false, resolver_mode=resolver_mode_full, 
safe_resolver_show_actions=false, no_new_installs=false, 
no_new_upgrades=false, user_tags=std::vector of length 0, capacity 0, 
arch_only=false, queue_only=false, verbose=)
at ../../../src/cmdline/cmdline_do_action.cc:249
#20 0x555b4250 in main (argc=3, argv=)
at ../../src/main.cc:1278
Starting program: /usr/bin/aptitude install pkgs_that_you_want_installed
[Thread debugging using libthread_db enabled]
Using host libthread_db library 

Bug#840227: libgit2: CVE-2016-8568 CVE-2016-8569

[Salvatore Bonaccorso]

Hi Russell,

On Tue, Jan 03, 2017 at 05:55:31PM +1100, Russell Sim wrote:
> Hi,
> 
> Sorry, I messed this up.
> 
> The fix for CVE-2016-8569 was included in the 0.24.2-1 release but the
> fix for CVE-2016-8568 wasn't.
> 
> Sorry about that, I have pushed a new version to unstable that includes
> the fix, the version is 0.24.5-1.  I realised the mistake when I was
> reviewing some diffs before an upload yesterday.

Thanks. I have fixed the security-tracker information regarding those
CVEs.

Regards,
Salvatore

Bug#850015: magic-wormhole debian package should default to using magic-wormhole-transit.debian.net for transit

[Daniel Kahn Gillmor]

Package: magic-wormhole
Version: 0.8.2-1

I spoke with Brian Warner, the magic-wormhole upstream, and we concluded
that one risk for the debian package is that if it becomes really
popular and the magic-wormhole transit server becomes really expensive
to run, it would be a bummer for him.

as a result, we decided that the debian package should default to using
magic-wormhole-transit.debian.net, which i've registered as currently
just a cname for transit.magic-wormhole.io (the upstream default).

if, in the future, traffic from debian wormhole clients becomes too
expensive for Brian to float, we can simply set up another wormhole
transit server and repoint magic-wormhole-transit.debian.net to it.

Note that the debian package should continue to use the default
rendezvous server, which consumes far less bandwidth, and is necessarily
a singleton for nameplate resolution and rendezvous.

Only the transit server should be tuned in the debian package.

 --dkg


signature.asc
Description: PGP signature

Bug#850004: Disk Space Usage totally wrong

[Daniel Baumann]

Sven Hartge  wrote:
> This looks a lot like https://github.com/firehol/netdata/issues/605
> but it does not seem to be fixed as claimed in the issue.

well, it's fixed in git as of October 23rd, whereas 1.4 in debian is
from beginning of October.

updating netdata or cherry-picking the commit should be enough.

https://github.com/firehol/netdata/commit/25ffc015051f98268d4cd406dea3b1f7d6ec4160

Regards,
Daniel

Bug#849918: RFS: tinymux/2.10.1.13-1

[Stephen Dennis]

Very much appreciate the feedback. Willing to learn, but overwhelmed by the
Debian machinery.

Stupid question at the top: If I dput another package, does it update this
one or do I need to delete the currently uploaded package from mentors
first?


- d/changelog. A lot has changed. Here are pointers to 'brief' change logs
for 2.7, 2.9, and 2.10:

http://www.tinymux.org/changes27.txt
http://www.tinymux.org/changes29.txt
http://www.tinymux.org/changes.txt

That's four years of why to retrace, and the actual check-in messages from
the repository would be much longer. Does Debian really want all of that?

- d/patches

  - Not sure what a dep3 header is, yet. More to learn.
  - All but one of the patches is checked-in upstream already.
  - I don't know how to have config.guess be updated at build time? Did not
know about that one. Is this part of automake? TinyMUX is more autoconf
than it once was, but it still doesn't use automake or libtool.
  - Dependency-created-noise.patch. The way users normally build TinyMUX is
untar the package, ./configure;make depend;make. The 'make depend' scans
all the include files and builds ".depend" which is then re-consumed by
Makefile. It must exist -- at least empty. The Debian build system would
see either way as a source change, but it isn't a change to taken upstream.
It always changes in different ways in every environment.

- d/copyright dep5...OK, more to study. The copyright is the same as
previous 2.6 package except for the dates. That was hammered out between
the four MUSH flavors (PennMUSH, TInyMUSH, TinyMUX, and RhostMUSH). I'm
loath to change the substance of it, but if there is some Debian-friendly
form to call out that it is the Artistic license, that seems reasonable
enough.

- silent rule. TinyMUX uses the other autoconf tools, but not libool or
automake. Silent rule seems to be a term from those things?

- d/rules. I'm picking this up from the previous maintainer, Noltar, and
there should be simpler ways of doing this now. I'm just not up to speed on
them and haven't found examples I grok, yet. I want to use the simple
debhelper method. dh, done.

Stephen

On Mon, Jan 2, 2017 at 11:41 PM, Tobias Frost  wrote:

> control: tags -1 moreinfo
>
> Hallo Stephen,
>
> (not taking ownership of the bug as I cannot guarantee to find time for
> follow ups. Other DDs are welcome to take this bug)
>
> Many thanks for your intention to adopt your pacakge.
> I see that you're also upstream of it; this means that I can also
> request to fix some upstream parts, like the build system ;-)
>
> here is a review:
>
> - d/changelog is incomplete. You've changed quite a bit in the debian
> packaging, more than "new upstream reelase" ;-)
> Please make sure that you really document everything you changed,
> (and as this is often done wrong, the changelog should ensure that
> it explains the "why (have it been changed)" adequately.
>
> - d/patches
>   - they could have use of a dep3 header
>   - as you're upstream, do you plan to roll out a new release with
> them? (question out of curiosity, not required for sponsoring)
>
>autoconf patch:
>   - you should not patch config.guess. They need to be updated on
> build-time! (autotools-dev is your friend, and debhelper with
> compat level 10 will be even better.)
>dependency-created-noise patch:
>- I'm not sure about this patch. What is its purpose?
>  The header reads as it is for canceling changes due to the build
>  process? Looks like it is regenerated at build time? If so, it
>  should not be patched but mereley deleted in the clean target.
>  (Otherwise the build system should be fixed that this is not
>   needed; automake is capable to create dependencie)
>
> - d/copyright should be transferred to dep5 format.
>
> - Please disable silent rules (the buildlog should emit all compiler
> flags)
>
> - d/rules should be converted to short debhelper format.
>   - the buildsystem should be really fixed to properly clean up.
>   - otherwise, errors from rm should not be ignored, also not errors
> from make realclen. Just don't execute it when there is no Makefile.
>
> (Stopping here for time reasons; especially I did not do a d/copyright
> audit, not checked the upstream code)
>
> Please fix above, remove the moreinfo tag, and -- time permitting -- I
> will iterate.
>
> --
> tobi
>
>

Bug#850014: unblock: libgit2/0.24.5-1

[Russell Sim]

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

Please unblock package libgit2

The main reasons is that i messed up the packaging of version 0.24.2-1, and
have flagged CVE-2016-8568 [0] as being fixed which is untrue.  This package
both addresses this issue correctly and fixes the serious bug [1].

Thanks,
Russell

0. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=840227
1. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=841532


unblock libgit2/0.24.5-1

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

Kernel: Linux 4.6.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8)
diff -Nru libgit2-0.24.2/debian/changelog libgit2-0.24.5/debian/changelog
--- libgit2-0.24.2/debian/changelog	2016-11-04 18:36:41.0 +1100
+++ libgit2-0.24.5/debian/changelog	2017-01-02 20:35:08.0 +1100
@@ -1,3 +1,11 @@
+libgit2 (0.24.5-1) unstable; urgency=medium
+
+  * New upstream release.
+  * debian/patch/fix_gmt14_timzone_bug.patch (Closes: #841532)
+  * Correcty address CVE-2016-8568
+
+ -- Russell Sim   Mon, 02 Jan 2017 20:35:08 +1100
+
 libgit2 (0.24.2-2) unstable; urgency=medium
 
   * Upload to unstable.
diff -Nru libgit2-0.24.2/debian/patches/commit-always-initialize-commit-message.patch libgit2-0.24.5/debian/patches/commit-always-initialize-commit-message.patch
--- libgit2-0.24.2/debian/patches/commit-always-initialize-commit-message.patch	2016-11-04 18:36:41.0 +1100
+++ libgit2-0.24.5/debian/patches/commit-always-initialize-commit-message.patch	1970-01-01 10:00:00.0 +1000
@@ -1,43 +0,0 @@
-From a719ef5e6d4a1a8ec53469c7914032ed67922772 Mon Sep 17 00:00:00 2001
-From: Patrick Steinhardt 
-Date: Fri, 7 Oct 2016 09:31:41 +0200
-Subject: [PATCH] commit: always initialize commit message
-
-When parsing a commit, we will treat all bytes left after parsing
-the headers as the commit message. When no bytes are left, we
-leave the commit's message uninitialized. While uncommon to have
-a commit without message, this is the right behavior as Git
-unfortunately allows for empty commit messages.
-
-Given that this scenario is so uncommon, most programs acting on
-the commit message will never check if the message is actually
-set, which may lead to errors. To work around the error and not
-lay the burden of checking for empty commit messages to the
-developer, initialize the commit message with an empty string
-when no commit message is given.

- src/commit.c | 7 ---
- 1 file changed, 4 insertions(+), 3 deletions(-)
-
-diff --git a/src/commit.c b/src/commit.c
-index 99a8085..76e6dcb 100644
 a/src/commit.c
-+++ b/src/commit.c
-@@ -459,10 +459,11 @@ int git_commit__parse(void *_commit, git_odb_object *odb_obj)
- 	buffer = buffer_start + header_len + 1;
- 
- 	/* extract commit message */
--	if (buffer <= buffer_end) {
-+	if (buffer <= buffer_end)
- 		commit->raw_message = git__strndup(buffer, buffer_end - buffer);
--		GITERR_CHECK_ALLOC(commit->raw_message);
--	}
-+	else
-+		commit->raw_message = git__strdup("");
-+	GITERR_CHECK_ALLOC(commit->raw_message);
- 
- 	return 0;
- 
--- 
-2.8.1
-
diff -Nru libgit2-0.24.2/debian/patches/fix_gmt14_timzone_bug.patch libgit2-0.24.5/debian/patches/fix_gmt14_timzone_bug.patch
--- libgit2-0.24.2/debian/patches/fix_gmt14_timzone_bug.patch	1970-01-01 10:00:00.0 +1000
+++ libgit2-0.24.5/debian/patches/fix_gmt14_timzone_bug.patch	2017-01-02 20:35:08.0 +1100
@@ -0,0 +1,29 @@
+From 23c9ff8632d8ae90d211601d3254ab7f4d35e853 Mon Sep 17 00:00:00 2001
+From: Andreas Henriksson 
+Date: Sat, 17 Dec 2016 17:33:13 +0100
+Subject: [PATCH] Fix off-by-one problems in git_signature__parse
+
+Etc/GMT-14 aka UTC+14:00 is a thing
+https://en.wikipedia.org/wiki/UTC%2B14:00
+
+Also allow offsets on the last minute (59).
+
+Addresses: https://bugs.debian.org/841532
+Fixes: #3970
+---
+ src/signature.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/src/signature.c b/src/signature.c
+index dcc3797..22cba7e 100644
+--- a/src/signature.c
 b/src/signature.c
+@@ -251,7 +251,7 @@ int git_signature__parse(git_signature *sig, const char **buffer_out,
+ 			 * only store timezone if it's not overflowing;
+ 			 * see http://www.worldtimezone.com/faq.html
+ 			 */
+-			if (hours < 14 && mins < 59) {
++			if (hours <= 14 && mins <= 59) {
+ sig->when.offset = (hours * 60) + mins;
+ if (tz_start[0] == '-')
+ 	sig->when.offset = -sig->when.offset;
diff -Nru libgit2-0.24.2/debian/patches/series libgit2-0.24.5/debian/patches/series
--- libgit2-0.24.2/debian/patches/series	2016-11-04 18:36:41.0 +1100
+++ libgit2-0.24.5/debian/patches/series	2017-01-02 20:35:08.0 +1100
@@ -1,2 +1,2 @@
 disable_tests.patch

Bug#842427: php7.0-common: Timezone is set incorrectly

[Russell Stuart]

Tags: patch

Attached is a new version of:

   php7.0-7.0.14/debian/patches/0032-Use-system-timezone.patch

It verifies the files written by tzdata's debconf, /etc/timezone and
/etc/localtime, are consistent.  If they are it sets the guessed time
zone to be whatever is in /etc/timezone.  If they aren't Debian's
timezone isn't used, which currently means the guessed timezone will be
"UTC".

Obviously this only works on Debian, but since upstream rejected the
patch I doubt that's a problem.From: Russell Stuart 
Date: Tue,  3 Jan 2017 14:28:39 +1000
Subject: Use Debian timezone

Upstream don't want this patch. See
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=730771 for a summary.
---
 ext/date/php_date.c | 17 +
 1 file changed, 17 insertions(+)

--- a/ext/date/php_date.c
+++ b/ext/date/php_date.c
@@ -29,6 +29,7 @@
 #include "php_date.h"
 #include "zend_interfaces.h"
 #include "lib/timelib.h"
+#include 
 #include 
 
 #ifdef PHP_WIN32
@@ -992,6 +993,47 @@
 		DATEG(timezone_valid) = 1;
 		return DATEG(default_timezone);
 	}
+	/* Use the timezone written by the tzdata packages debconf */
+	{
+		static char* debian_timezone = NULL;
+		struct stat localtime_st;
+		struct stat zoneinfo_st;
+		char zone_path[2048];
+		int bytes_read = 0;
+		int l;
+
+		if (debian_timezone == NULL) {
+			/* Verify the data written by tzdata debconf is self consistent */
+			int fd = open("/etc/timezone", O_RDONLY);
+			if (fd != -1) {
+strcpy(zone_path, "/usr/share/zoneinfo/");
+l = strlen(zone_path);
+bytes_read = read(fd, zone_path + l, sizeof(zone_path) - l - 1);
+close(fd);
+if (bytes_read > 0) {
+	while (zone_path[l + bytes_read - 1] < ' ')
+		bytes_read -= 1;
+	zone_path[bytes_read + l] = '\0';
+	if (stat("/etc/localtime", _st) != -1 &&
+		stat(zone_path, _st) != -1 &&
+		localtime_st.st_dev == zoneinfo_st.st_dev &&
+		localtime_st.st_ino == zoneinfo_st.st_ino &&
+		timelib_timezone_id_is_valid(zone_path + l, tzdb)
+	) {
+		debian_timezone = emalloc(bytes_read);
+		strcpy(debian_timezone, zone_path + l);
+	}
+}
+			}
+		}
+		if (debian_timezone == NULL) {
+			debian_timezone = emalloc(1);
+			*debian_timezone = '\0';
+		}
+		if (*debian_timezone != '\0') {
+			return debian_timezone;
+		}
+	}
 	/* Fallback to UTC */
 	return "UTC";
 }


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

Bug#828262: cfengine2: FTBFS with openssl 1.1.0

[Antonio Radici]

Control: severity -1 important

On Wed, Dec 07, 2016 at 11:19:20PM +0100, Petter Reinholdtsen wrote:
> Given that cfengine2 no longer get any upstream development, as far as I know,
> I guess the easiest and most sensible way to fix this is to build with
> libssl1.0-dev for now.  If cfengine2 is still needed in Stretch+1 someone 
> should
> consider to port the code to openssl 1.1.
> 
> Debian Edu still uses cfengine2, and would very much like to see it still
> available in Stretch.
> 
> If this patch is applied, this BTS report should have its severity lowered to
> important or normal.
> 
> diff -ur cfengine2-2.2.10/debian/control cfengine2-2.2.10-pere/debian/control
> --- cfengine2-2.2.10/debian/control 2016-08-21 08:24:15.0 +
> +++ cfengine2-2.2.10-pere/debian/control2016-12-07 22:14:28.911881217 
> +
> @@ -3,7 +3,7 @@
>  Priority: optional
>  Maintainer: Antonio Radici 
>  Build-Depends: debhelper (>= 7.0.50), autoconf, automake, autotools-dev,
> - bison, dh-autoreconf, flex, libdb-dev, libssl-dev, libtool, perl (>= 5),
> + bison, dh-autoreconf, flex, libdb-dev, libssl1.0-dev, libtool, perl (>= 5),
>   po-debconf, texinfo, quilt, libselinux1-dev [linux-any]
>  Standards-Version: 3.9.8
>  Homepage: http://www.cfengine.org/

I concur with this assessment, I'll downgrade the severity of this bug to
important, unfortunately there is no upstream development of cfengine2, Peter
has submitted a patch to modify the dependency for 2.2.10-7.

If I have time I might consider to patch it for 1.1 (I did it for cfengine3 in
the past).

Bug#835452: debian-policy: Deprecating dependency of "binary" on "build"

[Niels Thykier]

On Thu, 25 Aug 2016 22:06:51 +0200 (CEST) Santiago Vila
 wrote:
> Package: debian-policy
> Version: 3.9.8
> Severity: wishlist
> 
> Greetings.
> 
Hi,

CCing debian-dpkg@l.d.o because I think Guillem would be interested in this.

> Debian Policy 4.9 says:
> 
>  Both binary-* targets should depend on the build target, or on the
>  appropriate build-arch or build-indep target, if provided, so that the
>  package is built if it has not been already.
> 
> 
> I don't see the point at all:
> 
> 
> * Autobuilders *always* invoke the build-* targets first.
> 
> * dpkg-buildpackage *always* invoke the build/build-* target first.
> 
> [...]
>
> * Building as root should be discouraged.
> 

It is my understanding that Guillem is working on making the requirement
for using (fake)root obsolete.  This would have different benefits that
relevant to this discussion:

 * We can reduce the number of calls to make and by extension all
   the $(shell ...) invocation in d/rules (see #793404 for a discussion
   of that)

 * In theory, /if/ we could do a 100% transition, we could ditch the
   build target as a mandatory target. (Though this is hardly in the
   "near future" by any measure).

> 
> [...]
> 
> I don't know if this proposal will seem controversial, because we have
> been doing that for ages, so please let us consider all the pros and
> all the cons.
> 
> [...]
> 
> Thanks.
> 
> 

I have no strong feeling for whether build should remain a mandated
target (re: my second bullet above).  But I have a conflict of interest
with mandating that build must always be done in a separate invocation
as it would complicate a major progress on #793404.
  My understanding is that removing the dependency would do exactly the
latter (as "debian/rules build binary" is no longer well defined).

Thanks,
~Niels




signature.asc
Description: OpenPGP digital signature

Bug#840227: libgit2: CVE-2016-8568 CVE-2016-8569

[Russell Sim]

Hi,

Sorry, I messed this up.

The fix for CVE-2016-8569 was included in the 0.24.2-1 release but the
fix for CVE-2016-8568 wasn't.

Sorry about that, I have pushed a new version to unstable that includes
the fix, the version is 0.24.5-1.  I realised the mistake when I was
reviewing some diffs before an upload yesterday.

Salvatore Bonaccorso  writes:

> Source: libgit2
> Version: 0.24.1-2
> Severity: grave
> Tags: security upstream
>
> Hi,
>
> the following vulnerabilities were published for libgit2.
>
> CVE-2016-8568[0, 3]:
> Read out-of-bounds in git_oid_nfmt
>
> CVE-2016-8569[1, 4]:
> DoS using a null pointer dereference in git_commit_message
>
> If you fix the vulnerabilities please also make sure to include the
> CVE (Common Vulnerabilities & Exposures) ids in your changelog entry.
>
> For further information see:
>
> [0] https://security-tracker.debian.org/tracker/CVE-2016-8568
> [1] https://security-tracker.debian.org/tracker/CVE-2016-8569
> [2] https://marc.info/?l=oss-security=147594097425642=2
> [3] https://github.com/libgit2/libgit2/issues/3936
> [4] https://github.com/libgit2/libgit2/issues/3937
> [5] https://github.com/libgit2/libgit2/pull/3956
>
> Please adjust the affected versions in the BTS as needed.
>
> Regards,
> Salvatore

-- 
Cheers,
Russell

Bug#849743: logrotate: Please specify a default mailx provider

[Matthias Klose]

I uploaded a NMU with the Recommends change to DELAYED/5.

Bug#850013: vim-youcompleteme: Please provide a newer version, the current one doesn't work any more

[Philipp Marek]

Package: vim-youcompleteme
Version: 0+20160327+git1b76af4-2
Severity: normal

Please provide a newer version, the current one doesn't work with current 
neovim and python-neovim (0.1.12, via pip) any more.

When starting to edit a file (going into insert mode) I get this error:

Error detected while processing function 
80_SetOmnicompleteFunc[1]..80_Pyeval[2]..provider#python#Call:
line   18:
error caught in request handler 'python_eval 
('ycm_state.NativeFiletypeCompletionUsable()',)':
Traceback (most recent call last):
  File 
"/usr/local/lib/python2.7/dist-packages/neovim/plugin/script_host.py", line 
150, in python_eval
return eval(expr, self.module.__dict__)
  File "", line 1, in 
  File "/usr/share/vim-youcompleteme/python/ycm/youcompleteme.py", line 
255, in NativeFiletypeCompletionUsable
self.NativeFiletypeCompletionAvailable() )
  File "/usr/share/vim-youcompleteme/python/ycm/youcompleteme.py", line 
250, in NativeFiletypeCompletionAvailable
vimsupport.CurrentFiletypes() ] )
  File "/usr/share/vim-youcompleteme/python/ycm/youcompleteme.py", line 
240, in FiletypeCompleterExistsForFiletype
exists_completer = SendCompleterAvailableRequest( filetype )
  File 
"/usr/share/vim-youcompleteme/python/ycm/client/completer_available_request.py",
 line 57, in SendCompleterAvailableRequest
request.Start()

But as requested on #neovim I already fetched the current python-neovim and 
python3-neovim libraries.


Thanks a lot for your efforts!


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

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

Versions of packages vim-youcompleteme depends on:
ii  python3-future0.15.2-4
ii  python3-requests  2.12.4-1
ii  python3-requests-futures  0.9.7-1
pn  python3:any   
ii  vim-athena [vim-python]   2:8.0.0134-1
ii  vim-gtk3 [vim-python] 2:8.0.0134-1
ii  ycmd  0+20160327+gitc3e6904-1+b1

Versions of packages vim-youcompleteme recommends:
ii  vim-addon-manager  0.5.6

vim-youcompleteme suggests no packages.

-- no debconf information

Bug#850012: base: gamepad not registering up or left

[Dustin Sallings]

Package: base
Severity: normal

Dear Maintainer,

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

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

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

I'm using a NES gamepad USB interface and found that up and left are
not registered.  This seems to be a known issue, with many people
complaining here:
https://www.raspberrypi.org/forums/viewtopic.php?t=44233=831372

as well as a solution found here:

https://www.raspberrypi.org/forums/viewtopic.php?f=78=36564=25

It seems the range is not properly detected.  All the other buttons,
and right and down seem to work as expected, but left and up send
nothing to the joystick device and leads to nearly working sadness.

-- System Information:
Debian Release: 8.6
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: armhf (armv7l)

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

Bug#849918: RFS: tinymux/2.10.1.13-1

[Tobias Frost]

control: tags -1 moreinfo

Hallo Stephen,

(not taking ownership of the bug as I cannot guarantee to find time for
follow ups. Other DDs are welcome to take this bug)

Many thanks for your intention to adopt your pacakge.
I see that you're also upstream of it; this means that I can also 
request to fix some upstream parts, like the build system ;-)

here is a review:

- d/changelog is incomplete. You've changed quite a bit in the debian
packaging, more than "new upstream reelase" ;-)
Please make sure that you really document everything you changed,
(and as this is often done wrong, the changelog should ensure that 
it explains the "why (have it been changed)" adequately.

- d/patches
  - they could have use of a dep3 header
  - as you're upstream, do you plan to roll out a new release with    
them? (question out of curiosity, not required for sponsoring)
  
   autoconf patch:
  - you should not patch config.guess. They need to be updated on 
build-time! (autotools-dev is your friend, and debhelper with 
compat level 10 will be even better.)
   dependency-created-noise patch:
   - I'm not sure about this patch. What is its purpose?
 The header reads as it is for canceling changes due to the build  
 process? Looks like it is regenerated at build time? If so, it
 should not be patched but mereley deleted in the clean target.
 (Otherwise the build system should be fixed that this is not 
  needed; automake is capable to create dependencie)

- d/copyright should be transferred to dep5 format.

- Please disable silent rules (the buildlog should emit all compiler
flags)

- d/rules should be converted to short debhelper format.
  - the buildsystem should be really fixed to properly clean up.
  - otherwise, errors from rm should not be ignored, also not errors
from make realclen. Just don't execute it when there is no Makefile.

(Stopping here for time reasons; especially I did not do a d/copyright
audit, not checked the upstream code)

Please fix above, remove the moreinfo tag, and -- time permitting -- I
will iterate.

--
tobi

Bug#849564: python3-reportbug: reportbug fails with AttributeError: 'str' object has no attribute 'utils'

[Philipp Marek]

Package: reportbug
Version: 7.1.1
Followup-For: Bug #849564

Thanks for the hints, I found out that me having an abbreviated first name 
in ~/.reportbugrc was causing the same problem.

Reverting back to the full name (so with no "." in it) is a workaround, at 
least.


-- Package-specific info:
** Environment settings:
EDITOR="vim"
DEBEMAIL="Philipp Marek "
INTERFACE="gtk2"

** /home/marek/.reportbugrc:
reportbug_version "4.12.6"
mode advanced
ui gtk2
realname "Philipp Marek"
email "philipp.ma...@linbit.com"
no-cc
header "X-Debbugs-CC: philipp.ma...@linbit.com"
smtphost reportbug.debian.org
mutt

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

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

Versions of packages reportbug depends on:
ii  apt1.4~beta2
ii  python3-reportbug  7.1.1
pn  python3:any

reportbug recommends no packages.

Versions of packages reportbug suggests:
pn  claws-mail   
pn  debconf-utils
ii  debsums  2.1.3
pn  dlocate  
pn  emacs23-bin-common | emacs24-bin-common  
ii  file 1:5.29-2
ii  gir1.2-gtk-3.0   3.22.5-1
ii  gir1.2-vte-2.91  0.46.1-1
ii  gnupg2.1.16-3
ii  postfix [mail-transport-agent]   3.1.3-6
ii  python3-gi   3.22.0-2
ii  python3-gtkspellcheck4.0.5-1
pn  python3-urwid
ii  xdg-utils1.1.1-1

-- no debconf information

Bug#850011: systemd package removal issue

[Vitaliyi]

Package: systemd
Version: 215-17+deb8u

I've tried to remove systemd package, as all normal users of Linux.
But it won't clean after itself properly:

# apt-get remove --purge --auto-remove systemd
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages will be REMOVED:
  systemd*
0 upgraded, 0 newly installed, 1 to remove and 5 not upgraded.
After this operation, 12.2 MB disk space will be freed.
Do you want to continue? [Y/n]
(Reading database ... 60858 files and directories currently installed.)
Removing systemd (215-17+deb8u5) ...
systemd is the active init system, please switch to another before removing
systemd.
dpkg: error processing package systemd (--purge):
 subprocess installed pre-removal script returned error exit status 1
Failed to stop lib-init-rw.mount: Unit lib-init-rw.mount not loaded.
addgroup: The group `systemd-journal' already exists as a system group.
Exiting.
Errors were encountered while processing:
 systemd
E: Sub-process /usr/bin/dpkg returned an error code (1)


For some reason this poor thing tries to add group systemd-journal when
being removed.

Bug#850010: libgmp10: please update symbols for tilegx

[Helmut Grohne]

Package: libgmp10
Version: 2:6.1.2+dfsg-1
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

Dear gmp maintainer,

gmp fails to build from source on tilegx (which is a new architecture
from a Debian point of view). dpkg-gensymbols fails missing a lot of
symbols. This is kinda expected for a new port. As it happens, tilegx
behaves exactly the same as m68k (and a few other architectures) from a
gmp symbols point of view. Thus

sed -i '/^ /s/!m68k /!tilegx &/' debian/libgmp10.symbols

can be used to make the gmp build succeed on tilegx. Can you apply this
fix?

Helmut

Bug#850009: logrotate: daily cron fails if .1.gz file already exists

[Witold Baryluk]

Package: logrotate
Version: 3.8.7-2
Severity: normal

Stock configs.


/etc/cron.daily/logrotate:
error: error creating output file /var/log/apache2/error.log.1.gz: File exists
error: error creating output file /var/log/cups/access_log.1.gz: File exists
error: error creating output file /var/log/exim4/mainlog.1.gz: File exists
run-parts: /etc/cron.daily/logrotate exited with return code 1


few days later:

/etc/cron.daily/logrotate:
error: error creating output file /var/log/apache2/error.log.1.gz: File exists
error: error creating output file /var/log/clamav/clamav.log.1.gz: File exists
error: error creating output file /var/log/clamav/freshclam.log.1.gz: File 
exists
error: error creating output file /var/log/cups/access_log.1.gz: File exists
error: error creating output file /var/log/exim4/mainlog.1.gz: File exists
error: error creating output file /var/log/mail.info.1.gz: File exists
error: error creating output file /var/log/mail.warn.1.gz: File exists
error: error creating output file /var/log/mail.err.1.gz: File exists
error: error creating output file /var/log/mail.log.1.gz: File exists
error: error creating output file /var/log/kern.log.1.gz: File exists
error: error creating output file /var/log/auth.log.1.gz: File exists
error: error creating output file /var/log/debug.1.gz: File exists
error: error creating output file /var/log/messages.1.gz: File exists


That is rather annoying.



-- Package-specific info:
Contents of /etc/logrotate.d
total 84
-rw-r--r-- 1 root root 433 Dec 19  2015 apache2
-rw-r--r-- 1 root root 173 Dec 13  2012 apt
-rw-r--r-- 1 root root  79 Nov  7  2012 aptitude
-rw-r--r-- 1 root root 382 Feb 21  2016 clamav-daemon
-rw-r--r-- 1 root root 409 Feb 21  2016 clamav-freshclam
-rw-r--r-- 1 root root 135 Jul 30  2012 consolekit
-rw-r--r-- 1 root root 181 Mar 20  2014 cups-daemon
-rw-r--r-- 1 root root 232 Oct 20  2012 dpkg
-rw-r--r-- 1 root root 146 Jan  2  2013 exim4-base
-rw-r--r-- 1 root root 126 Jan  2  2013 exim4-paniclog
-rw-r--r-- 1 root root 151 Oct  4  2012 iptraf
-rw-r--r-- 1 root root 165 Jan 22  2016 libvirtd
-rw-r--r-- 1 root root 164 Jan 22  2016 libvirtd.libxl
-rw-r--r-- 1 root root 162 Jan 22  2016 libvirtd.lxc
-rw-r--r-- 1 root root 163 Jan 22  2016 libvirtd.qemu
-rw-r--r-- 1 root root 162 Jan 22  2016 libvirtd.uml
-rw-r--r-- 1 root root 101 Feb  5  2013 mpd
-rw-r--r-- 1 root root 157 Jan 16  2012 pm-utils
-rw-r--r-- 1 root root  94 Jun 22  2012 ppp
-rw-r--r-- 1 root root 515 Sep 26  2012 rsyslog
-rw-r--r-- 1 root root 235 Feb 18  2016 unattended-upgrades


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

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

Versions of packages logrotate depends on:
ii  anacron 2.3-23
ii  base-passwd 3.5.42
ii  cron [cron-daemon]  3.0pl1-128
ii  libacl1 2.2.52-3
ii  libc6   2.24-8
ii  libpopt01.16-10
ii  libselinux1 2.6-3

Versions of packages logrotate recommends:
ii  bsd-mailx [mailx]  8.1.2-0.20160123cvs-3

logrotate suggests no packages.

-- no debconf information

Bug#836710: dput: Handle ‘setuptools’ specially to work around circular dependency

[Scott Kitterman]

On Thu, 29 Dec 2016 15:43:46 +1100 Ben Finney  wrote:
...
> I'd appreciate help with understanding what needs to be done, and how
> the tools should be configured to do it automatically.

As I understand it, this is a bug in setup.py for dput (at least as it relates 
how things are packaged in Debian):

install_requires=[
"setuptools",

>From a Debian perspective, this is overkill, since we've split pkg-resources 
out into it's own binary.  pkg-resources itself doesn't require setuptools.

What the error message is telling you:

pkg_resources.DistributionNotFound: The 'setuptools' distribution was not 
found and is required by dput

Is that dput has said it needs setuptools and it's not found, not that pkg-
resrouces needs the rest of setuptools to run.

If you take setuptools out of install_requires and add python-pkg-resources to 
Depends in debian/control, then it all works fine.

The only usage of the package is in helper/dputhelper.py and pkg-resources is 
enough.

Since pkg-resources isn't seen by setuptools, so you have to do it this way as 
far as I can tell.

Scott K

Bug#850007: libvncserver: CVE-2016-9941

[Salvatore Bonaccorso]

Source: libvncserver
Version: 0.9.10+dfsg-3
Severity: grave
Tags: upstream security patch
Justification: user security hole

Hi,

the following vulnerability was published for libvncserver.

CVE-2016-9941[0]:
| Heap-based buffer overflow in rfbproto.c in LibVNCClient in
| LibVNCServer before 0.9.11 allows remote servers to cause a denial of
| service (application crash) or possibly execute arbitrary code via a
| crafted FramebufferUpdate message containing a subrectangle outside of
| the client drawing area.

Fixing commit for the rfbproto.c part of the pull request in [1].

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2016-9941
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-9941
[1] 
https://github.com/LibVNC/libvncserver/pull/137/commits/5418e8007c248bf9668d22a8c1fa9528149b69f2

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#850008: libvncserver: CVE-2016-9942

[Salvatore Bonaccorso]

Source: libvncserver
Version: 0.9.10+dfsg-3
Severity: grave
Tags: security patch upstream
Justification: user security hole

Hi,

the following vulnerability was published for libvncserver.

CVE-2016-9942[0]:
| Heap-based buffer overflow in ultra.c in LibVNCClient in LibVNCServer
| before 0.9.11 allows remote servers to cause a denial of service
| (application crash) or possibly execute arbitrary code via a crafted
| FramebufferUpdate message with the Ultra type tile, such that the LZO
| payload decompressed length exceeds what is specified by the tile
| dimensions.

Fixing commit in [1].

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2016-9942
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-9942
[1] 
https://github.com/LibVNC/libvncserver/pull/137/commits/5fff4353f66427b467eb29e5fdc1da4f2be028bb

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#634184: dput: stops uploading changes files after one that has already been uploaded

[Ben Finney]

Control: tags -1 - patch + confirmed moreinfo
Control: found -1 dput/0.11.0

On 17-Jul-2011, Thorsten Glaser wrote:

> dput uploaded the first .changes file, looked at the second and
> decided it was already uploaded… and stopped processing, instead
> of uploading the third one. This was totally unexpected and could
> have led to loss, had I not seen that.

I agree this is undesirable, because the result is that the requested
action (“upload all these releases to the remote host now”) has
aborted with an error, leaving only a partial success.

> Please fix this – already uploaded files for which there is nothing
> more to do must not pre- vent dput from processing the remaining
> files on the command line.

Thinking about possible failure modes, I don't agree with that
suggestion. The result would be another undesirable “partial success”
result.


We can do better, I think. I am inclined to change the behaviour so that:

* Before any uploads, ‘dput’ will check “is there already an upload
  log for this release” for every package changes file.

* If any of them already exist, they are all reported as errors. The
  attempt is then aborted before any upload.

* If none of them already exist, the uploads attempts begin.

That way, the user can address the problem before getting partway
through and encountering the error.

That doesn't quite match your request, but I would still like your
opinion on whether you think this correctly addresses the reported
problem.

-- 
 \   “The long-term solution to mountains of waste is not more |
  `\  landfill sites but fewer shopping centres.” —Clive Hamilton, |
_o__)_Affluenza_, 2005 |
Ben Finney 


signature.asc
Description: PGP signature

Bug#849950: [Pkg-freeipa-devel] Bug#849950: freeipa: CVE-2016-9575: Insufficient permission check in certprofile-mod

[Salvatore Bonaccorso]

Hello Timo,

On Tue, Jan 03, 2017 at 12:40:10AM +0200, Timo Aaltonen wrote:
> On 02.01.2017 17:45, Salvatore Bonaccorso wrote:
> > Source: freeipa
> > Version: 4.3.2-5
> > Severity: grave
> > Tags: upstream security
> > Justification: user security hole
> > 
> > Hi,
> > 
> > the following vulnerability was published for freeipa. Note that I'm
> > not too familiar with freeipa, so just checked source wise. The code
> > should be present in ipalib/plugins/certprofile.py, and according to
> > the Red Hat bug [1] all freeipa versions above 4.2 should be affected.
> > it contains a patch as well.
> 
> Yes, I'm aware of these recent cve's but can't test any updates because
> tomcat 8.5 broke dogtag-pki. Will need to wait for that to get fixed
> first I guess, and then push 4.4.3 out.

Great, thank you for you quick feedback!

Regards,
Salvatore

Bug#850006: sddm: pam_systemd errors in auth.log

[Russell Coker]

Package: sddm
Version: 0.13.0-1
Severity: normal

/etc/pam.d/{sddm,sddm-autologin,sddm-greeter} all have
"session required pam_systemd.so" and they all also include common-session
which has "session optionalpam_systemd.so".

This leads to errors such as the following:
Jan  3 12:23:28 unicorn sddm-helper: pam_systemd(sddm-greeter:session): Cannot 
create session: Already running in a session
Jan  3 12:23:28 unicorn sddm-helper: pam_unix(sddm-greeter:session): session 
opened for user sddm by (uid=0)
Jan  3 12:23:28 unicorn sddm-helper: pam_systemd(sddm-greeter:session): Cannot 
create session: Already running in a session

Also why do you need to fail a login if a systemd session can't be established?
The maintainers of the common-session decided to make it optional, why does
it need to be required for sddm and if so wouldn't it need to be required for
other login daemons too?

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

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

Versions of packages sddm depends on:
ii  adduser 3.115
ii  debconf [debconf-2.0]   1.5.59
ii  libc6   2.24-8
ii  libgcc1 1:6.3.0-2
ii  libpam0g1.1.8-3.4
ii  libqt5core5a5.7.1+dfsg-2
ii  libqt5dbus5 5.7.1+dfsg-2
ii  libqt5gui5  5.7.1+dfsg-2
ii  libqt5network5  5.7.1+dfsg-2
ii  libqt5qml5  5.7.1-1
ii  libqt5quick55.7.1-1
ii  libstdc++6  6.3.0-2
ii  libsystemd0 232-8
ii  libxcb-xkb1 1.12-1
ii  libxcb1 1.12-1
ii  qml-module-qtquick2 5.7.1-1
ii  sddm-theme-breeze [sddm-theme]  4:5.8.4-1

Versions of packages sddm recommends:
ii  libpam-systemd  232-8

Versions of packages sddm suggests:
pn  libpam-kwallet5  

-- debconf information:
  sddm/daemon_name: /usr/bin/sddm
* shared/default-x-display-manager: sddm

Bug#848729: fails with UnicodeDecodeError: 'utf-8' codec can't decode byte 0xa3 in position 4341: invalid start byte

[Sven Hartge]

Hi!

I want to add some other observations to this bug. reportbug seems to
die during the parsing of /var/lib/dpkg/status, hitting some incorrectly
encoded characters. But if I launch reportbug with

   LC_ALL=de_DE@euro reportbug netdata

switching to the old 8bit locale, I am able to report a bug against netdata.

| UnicodeDecodeError: 'utf-8' codec can't decode byte 0xa3 in position
5333: invalid start byte

The character "0xa3" would be the "£" sign in ISO-8859-1

I am seeing this character on i386 in the following package:


Package: libfsplib0
Status: install ok installed
Priority: optional
Section: libs
Installed-Size: 76
Maintainer: £Ø­Ù<85>د اÙ<84>Ù<85>Ø­Ù<85>Ù<88>دÙ<8a> (Ahmed
El-Mahmoudy) 
Architecture: i386
Source: fsplib
Version: 0.11-2
Depends: libc6 (>= 2.2)

There is another package from Ahmed El-Mahmoudy in the file, but here
his name is encoded differently:

Package: libharfbuzz0b
Status: install ok installed
Priority: optional
Section: libs
Installed-Size: 985
Maintainer: أحÙ<85>د اÙ<84>Ù<85>Ø­Ù<85>Ù<88>دÙ<8a> (Ahmed
El-Mahmoudy) 
Architecture: i386
Multi-Arch: same
Source: harfbuzz (1.2.7-1)
Version: 1.2.7-1+b1


Looking at the status file with "od -t cx1 /var/lib/dpkg/status" shows
the following byte sequences:

a) wrong:

243 330 255 331 205 330 257
a3  d8  ad  d9  85  d8  af

b) right:
330 243 330 255 331 205 330 257
d8  a3  d8  ad  d9  85  d8  af

So far I only see this problem in my i386 Sid system, the files on the
amd64 systems seem correct and reportbug does not show any errors there.

Grüße,
Sven.

Bug#850005: dgit push without dgit build-source

[Nikolaus Rath]

Package: dgit
Version: 2.13
Severity: normal

Hello,

I'm trying to build a source package for unstable on a stable system. I
think this should work just fine, but:


$ dgit --dpm build-source
[...]
dpkg-checkbuilddeps: Unmet build dependencies: python-pytest-catchlog
dpkg-buildpackage: warning: build dependencies/conflicts unsatisfied; aborting
dpkg-buildpackage: warning: (Use -d flag to override.)
dgit: failed command: dpkg-buildpackage '-i'\\'.git/' -I.git -T clean
dgit: subprocess failed with error exit status 3

$ dgit --dpm build-source -- d
dgit: build-source takes no additional arguments
[...]

$ debuild -S -uc -us # hrmpf
[...]
dpkg-buildpackage: binary and diff upload (original source NOT included)

$ dgit --dpm push
canonical suite name for unstable is sid
downloading 
http://ftp.debian.org/debian//pool/main/p/python-llfuse/python-llfuse_1.1.1+dfsg-4.dsc...
last upload to archive has NO git hash
using existing python-llfuse_1.1.1+dfsg.orig.tar.xz
  % Total% Received % Xferd  Average Speed   TimeTime Time  Current
 Dload  Upload   Total   SpentLeft  Speed
100  138k  100  138k0 0   138k  0 --:--:-- --:--:-- --:--:--  138k
dpkg-source: info: extracting python-llfuse in python-llfuse-1.1.1+dfsg
dpkg-source: info: unpacking python-llfuse_1.1.1+dfsg.orig.tar.xz
dpkg-source: info: unpacking python-llfuse_1.1.1+dfsg-4.debian.tar.xz
synthesised git commit from .dsc 1.1.1+dfsg-4
Format `3.0 (quilt)', need to check/update patch stack
dgit: split brain (separate dgit view) may be needed (--quilt=dpm).
! Push failed, while preparing your push.
! You can retry the push, after fixing the problem, if you like.
dgit: --quilt=dpm but no cached dgit view:
dgit:  perhaps tree changed since dgit build[-source] ?
! Push failed, while preparing your push.
! You can retry the push, after fixing the problem, if you like.

Bug#849903: [py3porters-devel] Python 2 in the default installation -- progress made!

[Daniel Kahn Gillmor]

On Mon 2017-01-02 19:47:00 -0500, Ansgar Burchardt wrote:
> There was an open bug about changing the overrides (#849903) and I just
> set all packages built from gpgme1.0 to "Priority: optional".
>
> I don't think there is any reason for the lib*-dev packages to be at
> Priority: extra?

I read:

https://www.debian.org/doc/debian-policy/ch-archive.html#s-priorities

as suggesting that -dev packages are generally more "extra-ish" than
"optional", but then again, i think of workstations set up for software
development as having "specialized requirements" compared with what most
computers might reasonably want to install:

>>   optional
>> 
>>  (In a sense everything that isn't required is optional, but that's
>>  not what is meant here.) This is all the software that you might
>>  reasonably want to install if you didn't know what it was and don't
>>  have specialized requirements. This is a much larger system and
>>  includes the X Window System, a full TeX distribution, and many
>>  applications. Note that optional packages should not conflict with
>>  each other.
>> 
>>   extra
>> 
>>  This contains all packages that conflict with others with required,
>>  important, standard or optional priorities, or are only likely to
>>  be useful if you already know what they are or have specialized
>>  requirements (such as packages containing only detached debugging
>>  symbols).

I personally develop software, and i maintain many computers (for
myself, even), and i definitely *don't* want most of my computers to
include the -dev packages.

I'm happy to go with whatever the ftp-master team prefers, though. :)

 --dkg


signature.asc
Description: PGP signature

Bug#781457: ada bootstrap failure on mips and mipsel

[Matthias Klose]

Control: severity -1 important

This is now fixed in the packages, however it is not yet applied upstream to GCC
trunk, and not backported.

Bug#451356: [bug #22436] callback/minitests fails on x86_64

[Bruno Haible]

Update of bug #22436 (project libffcall):

  Status:None => Fixed  
 Open/Closed:Open => Closed 

___

Follow-up Comment #4:

This is a duplicate of bug #32466.
It is fixed now.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

Bug#850004: Disk Space Usage totally wrong

[Sven Hartge]

Package: netdata
Version: 1.4.0+dfsg-3
Severity: normal

Hi!

I am seeing a totally wrong disk space usage in netdata, see attached
screenshots.

The output from df and /proc/diskstats is as follows:
---8<-

$ df /var/remotelog/
Filesystem1K-blocks  Used Available Use% Mounted on
/dev/mapper/vg01-remotelog_lv  10190100 42848   9606580   1% /var/remotelog

$ df -h /var/remotelog/
Filesystem Size  Used Avail Use% Mounted on
/dev/mapper/vg01-remotelog_lv  9,8G   42M  9,2G   1% /var/remotelog

/proc/diskstats for /var/remotelog/ (dm-16)
 253  16 dm-16 44689 0 476002 581312 485563 0 3965960 15878468 0 11185824 
16460180

---8<-

It seems netdata misinterprets or miscalulates the numbers, resulting in
only 1.16 GB available in the graphic while in reality the number
is much higher.

This looks a lot like https://github.com/firehol/netdata/issues/605 but it does
not seem to be fixed as claimed in the issue.

Greetings,
Sven.

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

Kernel: Linux 4.7.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=ISO-8859-15) (ignored: 
LC_ALL set to de_DE@euro)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages netdata depends on:
ii  adduser  3.115
ii  fonts-font-awesome   4.7.0~dfsg-1
ii  init-system-helpers  1.46
ii  libc62.24-8
ii  libcap2-bin  1:2.25-1
ii  libjs-bootstrap  3.3.7+dfsg-2
ii  libjs-d3 3.5.17-1
ii  libjs-jquery 3.1.1-2
ii  libjs-raphael2.1.0-1
ii  libuuid1 2.29-1
ii  lsb-base 9.20161125
ii  netdata-data 1.4.0+dfsg-3
ii  python   2.7.13-1
ii  zlib1g   1:1.2.8.dfsg-4

netdata recommends no packages.

netdata suggests no packages.

-- Configuration Files:
/etc/netdata/health.d/disks.conf changed [not included]
/etc/netdata/health_alarm_notify.conf changed [not included]
/etc/netdata/netdata.conf changed [not included]
/etc/netdata/python.d/apache.conf changed [not included]
/etc/netdata/python.d/exim.conf changed [not included]

-- debconf-show failed

Bug#850003: jessie-pu: package python-cryptography/0.6.1-1+deb8u1

[Tristan Seligmann]

Package: release.debian.org
Severity: normal
Tags: jessie
User: release.debian@packages.debian.org
Usertags: pu

Backport the fix for CVE-2016-9243 which was deemed not severe enough for a
DSA. I've attached a full debdiff, the patch is quite small and self-contained,
although I needed another patch to fix building against the libssl now in
jessie.

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

Kernel: Linux 4.8.0-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_ZA.utf8, LC_CTYPE=en_ZA.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
diff -Nru python-cryptography-0.6.1/debian/changelog 
python-cryptography-0.6.1/debian/changelog
--- python-cryptography-0.6.1/debian/changelog  2014-10-16 06:46:31.0 
+0200
+++ python-cryptography-0.6.1/debian/changelog  2017-01-01 22:19:17.0 
+0200
@@ -1,3 +1,12 @@
+python-cryptography (0.6.1-1+deb8u1) stable; urgency=high
+
+  * Stable update.
+  * Backport the fix for CVE-2016-9243 (HKDF returns an empty byte string
+for small key sizes).
+  * Fix FTBFS due to SSL2 method detection.
+
+ -- Tristan Seligmann   Sun, 01 Jan 2017 22:19:17 +0200
+
 python-cryptography (0.6.1-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru python-cryptography-0.6.1/debian/patches/3215.patch 
python-cryptography-0.6.1/debian/patches/3215.patch
--- python-cryptography-0.6.1/debian/patches/3215.patch 1970-01-01 
02:00:00.0 +0200
+++ python-cryptography-0.6.1/debian/patches/3215.patch 2017-01-01 
22:19:17.0 +0200
@@ -0,0 +1,40 @@
+From d945a5213f2b2bbb189bbc2be407aa35e0dab204 Mon Sep 17 00:00:00 2001
+From: Alex Gaynor 
+Date: Sat, 5 Nov 2016 21:18:15 -0400
+Subject: [PATCH] Fixes #3211 -- fixed hkdf's output with short length
+
+Index: python-cryptography/cryptography/hazmat/primitives/kdf/hkdf.py
+===
+--- python-cryptography.orig/cryptography/hazmat/primitives/kdf/hkdf.py
2017-01-01 22:24:27.090828930 +0200
 python-cryptography/cryptography/hazmat/primitives/kdf/hkdf.py 
2017-01-01 22:24:27.086828861 +0200
+@@ -99,7 +99,7 @@
+ output = [b""]
+ counter = 1
+ 
+-while (self._algorithm.digest_size // 8) * len(output) < self._length:
++while self._algorithm.digest_size * (len(output) - 1) < self._length:
+ h = hmac.HMAC(key_material, self._algorithm, 
backend=self._backend)
+ h.update(output[-1])
+ h.update(self._info)
+Index: python-cryptography/tests/hazmat/primitives/test_hkdf.py
+===
+--- python-cryptography.orig/tests/hazmat/primitives/test_hkdf.py  
2017-01-01 22:24:27.090828930 +0200
 python-cryptography/tests/hazmat/primitives/test_hkdf.py   2017-01-01 
22:24:27.086828861 +0200
+@@ -152,6 +152,17 @@
+ 
+ hkdf.verify(b"foo", six.u("bar"))
+ 
++def test_derive_short_output(self, backend):
++hkdf = HKDF(
++hashes.SHA256(),
++4,
++salt=None,
++info=None,
++backend=backend
++)
++
++assert hkdf.derive(b"\x01" * 16) == b"gJ\xfb{"
++
+ 
+ @pytest.mark.hmac
+ class TestHKDFExpand(object):
diff -Nru python-cryptography-0.6.1/debian/patches/series 
python-cryptography-0.6.1/debian/patches/series
--- python-cryptography-0.6.1/debian/patches/series 1970-01-01 
02:00:00.0 +0200
+++ python-cryptography-0.6.1/debian/patches/series 2017-01-01 
22:19:17.0 +0200
@@ -0,0 +1,2 @@
+ssl2-detection.patch
+3215.patch
diff -Nru python-cryptography-0.6.1/debian/patches/ssl2-detection.patch 
python-cryptography-0.6.1/debian/patches/ssl2-detection.patch
--- python-cryptography-0.6.1/debian/patches/ssl2-detection.patch   
1970-01-01 02:00:00.0 +0200
+++ python-cryptography-0.6.1/debian/patches/ssl2-detection.patch   
2017-01-01 22:19:17.0 +0200
@@ -0,0 +1,13 @@
+Index: python-cryptography/cryptography/hazmat/bindings/openssl/ssl.py
+===
+--- python-cryptography.orig/cryptography/hazmat/bindings/openssl/ssl.py   
2017-01-01 22:33:41.640198755 +0200
 python-cryptography/cryptography/hazmat/bindings/openssl/ssl.py
2017-01-01 22:34:20.336845122 +0200
+@@ -384,7 +384,7 @@
+ #else
+ static const long Cryptography_HAS_SECURE_RENEGOTIATION = 1;
+ #endif
+-#ifdef OPENSSL_NO_SSL2
++#ifdef OPENSSL_NO_SSL2_METHOD
+ static const long Cryptography_HAS_SSL2 = 0;
+ SSL_METHOD* (*SSLv2_method)(void) = NULL;
+ SSL_METHOD* (*SSLv2_client_method)(void) = NULL;

Bug#850002: octave-common: startup reports error about "pkg load auto"

[Wang S]

Package: octave-common
Version: 4.2.0-1
Severity: normal

Dear Maintainer,

According to http://savannah.gnu.org/bugs/?49974
the config file installed by the Debian package octave-common needs to be 
updated, which is /etc/octave.conf, since autoload is no longer supported in 
Octave 4.2.


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

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

-- no debconf information

Bug#849569: spice: Please package 0.13 branch to experimental

[Erik Adler]

The only reason I would maybe say no is because that branch is labeled
“development release” on the spice site. Looking at their git code
commits it seems there is nothing that earth shattering going on.

I have not tested spice for anything other then using it with
virt-manager, QEMU desktop VMs. For that it works really well and I have
had no problems. Don’t need VMware anymore ... finally!

Really would like to hear what Marc-André Lureau (RedHat) has to say
about how ready this code is.

All the best

Erik Adler
GPG/PGP key ID: 0x2B4B58FE
gpg --keyserver pgp.mit.edu --recv-keys 0x2B4B58FE

Bug#840931: libimobiledevice4 GnuTLS settings broken with iOS 10

[Nicolas Boulenguez]

Package: libimobiledevice4
Followup-For: Bug #840931
Control: reassign 840931 libimobiledevice6 1.2.0+dfsg-3
Control: affects 840931 ifuse
Control: merge 840931 847977
Control: tags 840931 patch

Hello.

The attached diff applies the two upstream commits described above, as
well as another one described at the end of
https://github.com/libimobiledevice/libimobiledevice/issues/413.

All three patches are required to connect an iOS 4.5.1.
diff -Nru libimobiledevice-1.2.0+dfsg/debian/changelog libimobiledevice-1.2.0+dfsg/debian/changelog
--- libimobiledevice-1.2.0+dfsg/debian/changelog	2016-06-02 18:55:15.0 +0200
+++ libimobiledevice-1.2.0+dfsg/debian/changelog	2017-01-03 01:32:36.0 +0100
@@ -1,3 +1,12 @@
+libimobiledevice (1.2.0+dfsg-3.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Upstream commits replacing SSL3.0 with TLS1.0. Closes: #840931, #847977.
+Also fix related bug in GNUTLS pairing record generation, see
+https://github.com/libimobiledevice/libimobiledevice/issues/413.
+
+ -- Nicolas Boulenguez   Tue, 03 Jan 2017 01:32:36 +0100
+
 libimobiledevice (1.2.0+dfsg-3) unstable; urgency=high
 
   * Team upload
diff -Nru libimobiledevice-1.2.0+dfsg/debian/patches/fix-ssl-version-negotiation-for-newer-versions-of-openssl.diff libimobiledevice-1.2.0+dfsg/debian/patches/fix-ssl-version-negotiation-for-newer-versions-of-openssl.diff
--- libimobiledevice-1.2.0+dfsg/debian/patches/fix-ssl-version-negotiation-for-newer-versions-of-openssl.diff	1970-01-01 01:00:00.0 +0100
+++ libimobiledevice-1.2.0+dfsg/debian/patches/fix-ssl-version-negotiation-for-newer-versions-of-openssl.diff	2017-01-03 01:32:36.0 +0100
@@ -0,0 +1,20 @@
+Description: Fix SSL version negotiation for newer versions of OpenSSL
+ Depending on the OpenSSL version (and custom distribution patches), `SSLv3_method()`
+ would return NULL on some systems and also `SSLv23_method()` fails with some older
+ iOS versions...
+Origin: upstream, https://cgit.libimobiledevice.org/libimobiledevice.git/commit/?id=13bf235cac2201747de11652cf14fe2714ca0718
+Author: David Weinstein
+Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=840931
+Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=847977
+
+--- a/src/idevice.c
 b/src/idevice.c
+@@ -687,7 +687,7 @@
+ 	}
+ 	BIO_set_fd(ssl_bio, (int)(long)connection->data, BIO_NOCLOSE);
+ 
+-	SSL_CTX *ssl_ctx = SSL_CTX_new(SSLv3_method());
++	SSL_CTX *ssl_ctx = SSL_CTX_new(TLSv1_method());
+ 	if (ssl_ctx == NULL) {
+ 		debug_info("ERROR: Could not create SSL context.");
+ 		BIO_free(ssl_bio);
diff -Nru libimobiledevice-1.2.0+dfsg/debian/patches/idevice-update-gnutls-code-to-support-ios-10.diff libimobiledevice-1.2.0+dfsg/debian/patches/idevice-update-gnutls-code-to-support-ios-10.diff
--- libimobiledevice-1.2.0+dfsg/debian/patches/idevice-update-gnutls-code-to-support-ios-10.diff	1970-01-01 01:00:00.0 +0100
+++ libimobiledevice-1.2.0+dfsg/debian/patches/idevice-update-gnutls-code-to-support-ios-10.diff	2017-01-03 01:32:36.0 +0100
@@ -0,0 +1,21 @@
+Description: idevice: Update GnuTLS code to support iOS 10
+ As of iOS 10 beta 4, the GnuTLS implementation idevice_connection_enable_ssl
+ needs to be updated to support TLS. Using +VERS-TLS-ALL did not work on some
+ of the devices I tested and I wasn't sure how to fix it, but +VERS-TLS1.0 is
+ working on every device I've tested: iOS 9.0.2, 10.0b4, 8.1.1, 6.0, and 3.0.
+Origin: upstream, https://cgit.libimobiledevice.org/libimobiledevice.git/commit/?id=72643b2b83990b9cf97cc84b285b30763d44a72d
+Author: Jay Freeman (saurik)
+Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=840931
+Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=847977
+
+--- a/src/idevice.c
 b/src/idevice.c
+@@ -758,7 +758,7 @@
+ 	gnutls_certificate_client_set_retrieve_function(ssl_data_loc->certificate, internal_cert_callback);
+ #endif
+ 	gnutls_init(_data_loc->session, GNUTLS_CLIENT);
+-	gnutls_priority_set_direct(ssl_data_loc->session, "NONE:+VERS-SSL3.0:+ANON-DH:+RSA:+AES-128-CBC:+AES-256-CBC:+SHA1:+MD5:+COMP-NULL", NULL);
++	gnutls_priority_set_direct(ssl_data_loc->session, "NONE:+VERS-TLS1.0:+ANON-DH:+RSA:+AES-128-CBC:+AES-256-CBC:+SHA1:+MD5:+COMP-NULL", NULL);
+ 	gnutls_credentials_set(ssl_data_loc->session, GNUTLS_CRD_CERTIFICATE, ssl_data_loc->certificate);
+ 	gnutls_session_set_ptr(ssl_data_loc->session, ssl_data_loc);
+ 
diff -Nru libimobiledevice-1.2.0+dfsg/debian/patches/series libimobiledevice-1.2.0+dfsg/debian/patches/series
--- libimobiledevice-1.2.0+dfsg/debian/patches/series	2016-06-02 18:55:15.0 +0200
+++ libimobiledevice-1.2.0+dfsg/debian/patches/series	2017-01-03 01:32:36.0 +0100
@@ -2,3 +2,6 @@
 09_use_python_config.patch
 local-only-sockets.patch
 gnutls-api-update.patch
+fix-ssl-version-negotiation-for-newer-versions-of-openssl.diff
+idevice-update-gnutls-code-to-support-ios-10.diff

Bug#827452:

[dju`]

I'm also experiencing this bug although I don't have the libinput driver
installed...
-- 
--dju`

Bug#850001: dnssec-trigger: conffiles not removed

[Paul Wise]

Package: dnssec-trigger
Version: 0.13-3
Severity: normal
User: debian...@lists.debian.org
Usertags: obsolete-conffile adequate

The recent upgrade did not deal with obsolete conffiles properly.
Please use the dpkg-maintscript-helper support provided by dh_installdeb
to remove these obsolete conffiles on upgrade.

https://www.debian.org/doc/debian-policy/ch-files.html#s-config-files
http://manpages.debian.org/man/1/dh_installdeb

This bug report brought to you by adequate:

http://bonedaddy.net/pabs3/log/2013/02/23/inadequate-software/

$ pkg=dnssec-trigger ; adequate $pkg ; dpkg-query -W -f='${Conffiles}\n' $pkg | 
grep obsolete
dnssec-trigger: obsolete-conffile /etc/dnssec-trigger/dnssec.conf
 /etc/dnssec-trigger/dnssec.conf 725d746bd60cfe638a1c1ed5655d86f2 obsolete

-- System Information:
Debian Release: stretch/sid
  APT prefers testing-debug
  APT policy: (900, 'testing-debug'), (900, 'testing'), (800, 
'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700, 
'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental')
Architecture: amd64 (x86_64)

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

Versions of packages dnssec-trigger depends on:
ii  gir1.2-networkmanager-1.0  1.4.4-1
ii  libc6  2.24-8
ii  libgdk-pixbuf2.0-0 2.36.2-1
ii  libglib2.0-0   2.50.2-2
ii  libgtk2.0-02.24.31-1
ii  libldns2   1.7.0-1
ii  libssl1.1  1.1.0c-2
ii  python 2.7.13-1
ii  python-gi  3.22.0-2
ii  python-lockfile1:0.12.2-2
ii  unbound1.6.0-2

dnssec-trigger recommends no packages.

dnssec-trigger suggests no packages.

-- no debconf information

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#788253: gfsd: unowned files after purge (policy 6.8, 10.8): /var/lib/systemd/deb-systemd-helper-masked/gfsd.service

[Felipe Sateler]

On 30 December 2016 at 22:14, Dmitry Smirnov  wrote:
> On Tuesday, 20 December 2016 9:32:18 PM AEDT Felipe Sateler wrote:
>> Moving
>> the removal to after the debhelper block should fix this as well.
>
> Would that be an ugly workaround for bug in the other package?
>
>
>> Upon package remove but not purge, dh_systemd will mask the unit so
>> that upon the next boot you do not get boot failures because the
>> program is no longer installed.
>
> I still do not understand how/why is that a problem in gfarm (but not in
> other packages) and why gfarm needs workaround.
>
> It still looks like a bug in debhelper. Could you please elaborate why you've
> reassigned this bug back to gfarm?

Because gfarm, unlike other packages, removes the file
/etc/systemd/system/$foo.service. The debhelper-systemd machinery does
the following:

1. Upon package removal, remove the file
/etc/systemd/system/$foo.service if it exists, and records that fact
in a state file
(/var/lib/systemd/deb-systemd-helper-masked/$foo.service).  This is
done to prevent the service from being brought up during boot when the
package is removed but not purged (see policy 9.3.2 for the analogous
recommendation for sysvinit scripts).
2. Upon purge, if the file /etc/systemd/system/$foo.service exists, is
a symlink to /dev/null, and the corresponding state file exists, both
the state file and and the link are removed.

Because the gfarm postrm script deletes the service file in /etc, step
2 is not done, and the state file is not deleted.

I hope this makes it clear why I think this is a bug in gfarm.

If you really want to remove the file in /etc (which I'm still not
sure why would you want to), you should do so after the debhelper
machinery has done its work.

-- 

Saludos,
Felipe Sateler

Bug#393145: vtwm: strange behaviour under fr_FR.UTF-8 locale

[Ian Jackson]

Control: tags -1 moreinfo

I just did
  LC_ALL=fr_FR.UTF-8 vtwm &
and it seemed to DTRT.  The menus and window titles look just like
they did in my usual locale.

Is this still a bug for you, and if so do you have a clearer repro ?

Thanks,
Ian.

-- 
Ian Jackson    These opinions are my own.

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

Bug#850000: libdebian-source-perl: fails to parse build-depends restriction formulas

[gregor herrmann]

Control: block -1 with 757760 # half-jokingly

On Mon, 02 Jan 2017 20:56:10 -0400, David Bremner wrote:

> Build-Depends: debhelper (>= 10),
>  dh-elpa,
>  racket 
> 
> % dh_elpa_test
> 
> leads to
> 
> Unable to parse 'racket ' at /usr/share/perl5/Debian/Dependency.pm 
> line 331

Debian::Dependency just follows Debian Policy (7.1) which doesn't
know yet about build profiles:
https://bugs.debian.org/757760
https://wiki.debian.org/BuildProfileSpec

If the spec in the wiki is correct, adding this to the parse() sub in
./lib/Debian/Dependency.pm should be relatively straightforward.
And there's even a t/Dep.t.


Cheers,
gregor

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


signature.asc
Description: Digital Signature

Bug#849885: sweethome3d: SweetHome3D does not show up in "Open with application" list

[Markus Koschany]

Control: tags -1 pending
Control: severity -1 normal

On 02.01.2017 01:13, Nagy Attila István wrote:
> Package: sweethome3d
> Version: 4.5+dfsg-3
> Severity: important
> Tags: patch
> 
> SweetHome3D is not listed in the application list reachable via right 
> clicking a file and selecting 
>  "Open with"->"Other application..."->"View all applications".
> The cause of this is that the SweetHome3D desktop file 
> (/usr/share/applications/sweethome3d.desktop) lacks a %U from the Exec line, 
>  this way Gnome3 doesn't recognise the program as being able to handle 
> parameters, so it is excluded from 
>  the list of appications.
> 
> The solution is to change the line in the file 
> /usr/share/applications/sweethome3d.desktop:
> 
> Exec=sweethome3d
> 
> to:
> 
> Exec=sweethome3d %U

Hi,

thanks for the report. I have just uploaded a new revision which changes
the Exec line to Exec=sweethome3d %U. However I don't think that it will
be backported to Jessie.

Regards,

Markus




signature.asc
Description: OpenPGP digital signature

Bug#849885: Pending fixes for bugs in the sweethome3d package

[pkg-java-maintainers]

tag 849885 + pending
thanks

Some bugs in the sweethome3d package are closed in revision
fa306840a9ee67661615ee600a84a4001acce30b in branch 'master' by Markus
Koschany

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

Commit message:

Update sweethome3d.desktop's Exec command and pass the %U parameter to it.

This allows users to choose Sweethome3d from the Open with dialogue.

Closes: #849885

Bug#849884: qemu-kvm: USB host device pass through causes instant VM poweroff

[Kyle Gordon]

Hey,

I've managed to reproduce it on 2.7 from jessie-backports again, and the
assert is...

qemu-system-x86_64: /build/qemu-1VqMQS/qemu-2.7+dfsg/hw/usb/core.c:584:
usb_packet_copy: Assertion `p->actual_length + bytes <= iov->size' failed.

Also, this has been known to happen when adding the USB device, leaving the
VM in a 'Shutoff (Crashed)' state. I'm not sure if it's related.

*** Error in `qemu-system-x86_64': double free or corruption (!prev):
0x7f45d2b3a200 ***

and ...

*** Error in `qemu-system-x86_64': double free or corruption (!prev):
0x7fa2cd10b560 ***

I'll try the 2.8 version shortly!

Cheers

Kyle

On Mon, Jan 2, 2017 at 11:06 AM Michael Tokarev  wrote:

02.01.2017 13:57, Kyle Gordon wrote:
> Hi Michael,
>
> Thanks for the response. I have tried upgrading qemu* to
> 2.7+dfsg-3~bpo8+2 from jessie-backports, and the behaviour is
> unfortunately the same. I haven't tried upgrading the system to Stretch
> yet, as that might be a bit of a one way road!

Hmm... I see.

I re-read you first message, and it turns out I missed the info
about the bpo version. Please excuse me for that, that's ENOCOFFEE :)

This smells like something specific to this usb device. Did you
try other devices? The thing is that usb passthrough generally
works.

Can you also please show where it asserts out in case of 2.7 version
from bpo?

Also there's 2.8 version built for bpo (but not uploaded yet, since
2.8 hasn't been entered -testing), available at
http://www.corpit.ru/debian/tls/qemu/qemu-system-x86_2.8+dfsg-1~bpo8+1_amd64.deb
which can be of interest in this context too, but this might be
too much for you to try (this version is built with gtk and
virgl support, so there will be other deps).

Thanks,

/mjt

Bug#850000: libdebian-source-perl: fails to parse build-depends restriction formulas

[David Bremner]

Package: libdebian-source-perl
Version: 0.92
Severity: normal

Debian::Dependency is used by dh_elpa_test (source dh-elpa) to parse build 
deps, but it chokes on
build profiles, so called "restriction formulas".

for example

Build-Depends: debhelper (>= 10),
 dh-elpa,
 racket 

% dh_elpa_test

leads to

Unable to parse 'racket ' at /usr/share/perl5/Debian/Dependency.pm 
line 331

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

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

Versions of packages libdebian-source-perl depends on:
ii  dpkg-dev  1.18.18
ii  libapt-pkg-perl   0.1.30
ii  libarray-unique-perl  0.08-2
ii  libclass-accessor-perl0.34-1
ii  liblist-moreutils-perl0.416-1+b1
ii  libparse-debcontrol-perl  2.005-4
ii  libtie-ixhash-perl1.23-2
ii  libwww-mechanize-perl 1.83-1
ii  libwww-perl   6.15-1
ii  perl  5.24.1~rc4-1

libdebian-source-perl recommends no packages.

libdebian-source-perl suggests no packages.

-- no debconf information

Bug#849903: [py3porters-devel] Python 2 in the default installation -- progress made!

[Ansgar Burchardt]

Daniel Kahn Gillmor writes:
> On Thu 2016-12-29 23:41:39 -0500, Stuart Prescott wrote:
>> one of the objectives for stretch was to reduce the number of Python 2
>> packages that are installed in common scenarios, instead having the
>> Python 3 stack take over. The "standard task" within tasksel is a
>> reasonable place to look.¹
>  [...]
>> python-gpg
>> python3-gpg
>
> fwiw, python-gpg and python3-gpg should not be Priority: standard, and
> they are indicated as such in the source packages.
>
>https://packages.qa.debian.org/g/gpgme1.0.html
>
> indicates that they're marked that way due to override files, but i
> don't think there'd be any objection from myself or any of the other
> pkg-gnupg-maint team (cc'ed here) if those overrides were removed.

There was an open bug about changing the overrides (#849903) and I just
set all packages built from gpgme1.0 to "Priority: optional".

I don't think there is any reason for the lib*-dev packages to be at
Priority: extra?

Ansgar

Bug#847698: sbcl arm64 fixes

[Christoph Egger]

Hi!

Just uploaded 1.3.13-2 to unstable which should include the fix and is
the version I want for stretch. Can you please confirm it's now fine?

Thanks!

  Christoph

-- 
9FED 5C6C E206 B70A 5857  70CA 9655 22B9 D49A E731
Debian Developer | Lisp Hacker | CaCert Assurer


signature.asc
Description: PGP signature

Bug#816150: debdelta: support debian-debug archive

[Paul Wise]

On Mon, 2017-01-02 at 18:30 +0100, A Mennucc1 wrote:

> Try to add these 4 lines to /etc/debdelta/sources.conf

I've done that and will let you know of the result when I have an
upgrade that includes dbgsym packages.

PS: I note that the backports stanza duplicates the Debian one.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#848059:

[Markus Koschany]

On Wed, 14 Dec 2016 11:13:59 + =?iso-8859-1?Q?Sch=F6ke=2C_Karsten?=
 wrote:
> Hi,
> 
> the problem is, that tomcat7 don't use the proxy.
> The tomcat6 use this option on the same server...
> 
> tomcat7/javaopts: -Djava.awt.headless=true -Xmx4096m -XX:+UseConcMarkSweepGC 
> -XX:MaxPermSize=1024m -XX:+UseParNewGC -XX:MaxNewSize=512m -XX:NewSize=512m 
> -XX:SurvivorRatio=128 -XX:MaxTenuringThreshold=0 -XX:+UseTLAB 
> -XX:+CMSClassUnloadingEnabled -Dhttp.proxySet=true 
> -Dhttp.proxyHost=10.xxx.xx.xx -Dhttp.proxyPort=3128 
> -Dhttps.proxyHost=10.xxx.xx.xx -Dhttps.proxyPort=3128 
> -Dhttp.nonProxyHosts=*.domain.local
> 
> Tomcat Applications can't connect services over the proxy on Dhttp.proxyHost 
> on Dhttp.proxyPort
> 

Hi,

I still don't understand the actual issue. Were you able to resolve it
in the meantime. Was it just a configuration issue? Do you use
/etc/default/tomcat7 for passing these values or another method?

Regards,

Markus



signature.asc
Description: OpenPGP digital signature

Bug#849999: dpkg-dev should not set SOURCE_DATE_EPOCH to the empty string

[Guillem Jover]

Hi!

On Tue, 2017-01-03 at 00:09:37 +, Ian Jackson wrote:
> Package: dpkg-dev
> Version: 1.18.15

> If one runs dpkg-buildpackage with an unfinalised changelog entry, it
> sets SOURCE_DATE_EPOCH to the empty string.  Then, dpkg-deb can fail.

Yes, and probably other stuff too.

> I think setting SOURCE_DATE_EPOCH to the empty string is always
> wrong, so I think the bug is in dpkg-buildpackage, not dpkg-deb.

Indeed, and that's how I had already locally fixed your other report
(#849081), by always setting SOURCE_DATE_EPOCH in dpkg-buildpackage,
dpkg-source and Dpkg::Source::Archive. :)

I think I'll just merge these bug reports, as they are about the same
underlying issue.

Thanks,
Guillem

Bug#849949: version: tomcat7 (7.0.28-4+deb7u8)

[Markus Koschany]

Control: tags -1 confirmed

On 02.01.2017 18:00, Emmanuel Bourg wrote:
> Hi Karten,
> 
> Thank you for the report.
> 
> It looks like the patch for CVE-2016-6816 applied in 7.0.28-4+deb7u7 is
> incomplete. The patch removes the AstAttribute class but
> SecurityClassLoad still attempts to load it (along with other classes in
> the same package, also removed).
> 
> This issue is specific to the version of tomcat7 in Wheezy, in Jessie
> the AstAttribute class no longer exists.

Hi Karsten,

thanks for the report and thanks to Emmanuel for the analysis.

@Karsten

I have uploaded some new binary packages of Tomcat7 to

https://people.debian.org/~apo/wheezy-lts/tomcat7/

Could you test them on your system and report back if it works for you?
There is also a tomcat7.debdiff which you just need to apply to the
source package, if you want to build everything from source.

Regards,

Markus




signature.asc
Description: OpenPGP digital signature

Bug#849993: qtwebengine5-dev:amd64: References libQt5WebEngineWidgets.so in cmake and package, but destination of the symbolic link does not exist

[Sandro Knauß]

Control: tags -1 +pending

Hey,

it is fixed now already in git (4d99a899721d44dad57ff5a1ed439c6a3290ebce).

Best Regards,

sandro

--
Am Montag, 2. Januar 2017, 23:26:57 CET schrieb Witold Baryluk:
> Package: qtwebengine5-dev
> Version: 5.7.1+dfsg-1
> Severity: normal
> 
> It looks like one of the symbolic links in the package is dangling.
> 
> I couldn't find a destination file in any of the packages in debian, nor
> in dependent packages (like libqt5webengine5 or libqt5webenginecore5)
> 
> 
> $ dpkg -L qtwebengine5-dev | egrep 'usr/lib.*libQt.*so'
> /usr/lib/x86_64-linux-gnu/libQt5WebEngine.so
> /usr/lib/x86_64-linux-gnu/libQt5WebEngineCore.so
> /usr/lib/x86_64-linux-gnu/libQt5WebEngineWidgets.so
> 
> 
> $ LC_ALL=C ls -l /usr/lib/x86_64-linux-gnu/libQt5WebEngine*.so
> lrwxrwxrwx 1 root root 24 Dec 24 03:15
> /usr/lib/x86_64-linux-gnu/libQt5WebEngine.so -> libQt5WebEngine.so.5.7.1
> lrwxrwxrwx 1 root root 28 Dec 24 03:15
> /usr/lib/x86_64-linux-gnu/libQt5WebEngineCore.so ->
> libQt5WebEngineCore.so.5.7.1 lrwxrwxrwx 1 root root 31 Dec 24 03:15
> /usr/lib/x86_64-linux-gnu/libQt5WebEngineWidgets.so ->
> libQt5WebEngineWidgets.so.5.7.1
> 
> $ env LC_ALL=C stat -L /usr/lib/x86_64-linux-gnu/libQt5WebEngineWidgets.so
> stat: cannot stat '/usr/lib/x86_64-linux-gnu/libQt5WebEngineWidgets.so': No
> such file or directory $
> 
> 
> # apt-get install qtbase5-dev qtmultimedia5-dev qtdeclarative5-dev
> libqt5xmlpatterns5-dev  libqt5webkit5-dev qtwebengine5-dev libhunspell-dev
> 
> $ git clone https://github.com/OtterBrowser/otter-browser.git
> $ cd otter-browser && mkdir build && cd build && cmake ../
> 
> This leads to this error when trying to run 'cmake ../' in otter-browser
> from github.
> 
> CMake Error at
> /usr/lib/x86_64-linux-gnu/cmake/Qt5WebEngineWidgets/Qt5WebEngineWidgetsConf
> ig.cmake:27 (message): The imported target "Qt5::WebEngineWidgets"
> references the file
> 
>  "/usr/lib/x86_64-linux-gnu/libQt5WebEngineWidgets.so.5.7.1"
> 
>   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/Qt5WebEngineWidgets/Qt5WebEngineWidgetsCon
> fig.cmake"
> 
>   but not all the files it references.
> 
> Call Stack (most recent call first):
>  
> /usr/lib/x86_64-linux-gnu/cmake/Qt5WebEngineWidgets/Qt5WebEngineWidgetsConf
> ig.cmake:43 (_qt5_WebEngineWidgets_check_file_exists)
> /usr/lib/x86_64-linux-gnu/cmake/Qt5WebEngineWidgets/Qt5WebEngineWidgetsConf
> ig.cmake:134 (_populate_WebEngineWidgets_target_properties)
> CMakeLists.txt:86 (find_package)
> ...
> 
> $
> 
> Thanks.
> 
> 
> -- System Information:
> Debian Release: stretch/sid
>   APT prefers unstable
>   APT policy: (500, 'unstable'), (1, 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 4.8.0-1-amd64 (SMP w/12 CPU cores)
> Locale: LANG=pl_PL.UTF-8, LC_CTYPE=pl_PL.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> 
> Versions of packages qtwebengine5-dev:amd64 depends on:
> ii  libqt5webchannel5-dev  5.7.1-1
> ii  libqt5webengine5   5.7.1+dfsg-1
> ii  qtbase5-dev5.7.1+dfsg-2
> ii  qtdeclarative5-dev 5.7.1-1
> 
> qtwebengine5-dev:amd64 recommends no packages.
> 
> qtwebengine5-dev:amd64 suggests no packages.
> 
> -- no debconf information



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

Bug#849999: dpkg-dev should not set SOURCE_DATE_EPOCH to the empty string

[Ian Jackson]

Package: dpkg-dev
Version: 1.18.15

If one runs dpkg-buildpackage with an unfinalised changelog entry, it
sets SOURCE_DATE_EPOCH to the empty string.  Then, dpkg-deb can fail.

Steps to reproduce:

 git clone git://git.chiark.greenend.org.uk/~ianmdlvl/vtwm.git \
-b for-debian/dpkg-dev-source-date-bug
 cd vtwm
 sudo apt-get build-dep vtwm
 dpkg-builldpackage -uc -b

Actual output:

 ...
 dpkg-gencontrol: warning: debian/changelog(l7): found end of file where 
expected more change data or trailer
 dh_md5sums
 dh_builddeb
 dpkg-deb: building package 'vtwm-dbgsym' in 
'../vtwm-dbgsym_5.4.7-4~_amd64.deb'.
 dpkg-deb: error: unable to parse timestamp '': Success
 dh_builddeb: dpkg-deb -z1 -Zxz -Sextreme --build 
debian/.debhelper/vtwm/dbgsym-root .. returned exit code 2
 debian/rules:55: recipe for target 'binary-arch' failed
 make: *** [binary-arch] Error 1
 dpkg-buildpackage: error: fakeroot debian/rules binary gave error exit status 2

Expected output: successful build (with SOURCE_DATE_EPOCH unset, so
unreproducible).

I determined by use of strace that the first program that gets
   SOURCE_DATE_EPOCH=
in the environment is a dpkg-architecture spawned by
dpkg-buildpackage, which is why I think this is dpkg-buildpackage's
fault. 

I think setting SOURCE_DATE_EPOCH to the empty string is always
wrong, so I think the bug is in dpkg-buildpackage, not dpkg-deb.

Thanks,
Ian.

-- 
Ian Jackson    These opinions are my own.

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

Bug#849354: fvwm: Click not always taken into account or freezes the desktop

[Vincent Lefevre]

On 2016-12-26 02:24:30 +0100, Vincent Lefevre wrote:
> I'd say that problem 1 occurs at around 1 over 10. AFAIK, it had never
> occurred before the upgrade.

Actually, I've now found that what matters was not the upgrade,
but the fact that I had been using this config (a bit recent)
only with a real mouse, and the problems started to appear only
when I used the touchpad of my laptop.

After doing more tests with xev, I've noticed that the time delta
between the ButtonPress event and the ButtonRelease event was in
general much lower with the touchpad: about 120 units with the
mouse button, but sometimes less than 10 units with the button
of the touchpad.

Then I tried to reproduce the problem with the touchpad but letting
the touchpad button pressed a bit longer, and I couldn't.

So, it seems to be a timing issue in Fvwm. Perhaps it "forgets" the
ButtonRelease event, since the behavior when the bug occurs is similar
to what happens when I SCM-press the button but don't release it.

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

Bug#848935: [Pkg-samba-maint] Bug#848935: libnss-winbind: winbind authentication and wbinfo --uid-info no longer work after uprading to 4.5.2+dfsg-1

[Stéphane Pgt]

Hi Mathieu,


Thank you for pointing me to these bugs that I hadn't found during my previous 
searches.

>From what I've understood, the changes introduced in response to upstream bug 
>12155 are likely to be related with the issue.


Indeed, the configuration with which I was able to reproduce the bug contains 
those lines:

idmap uid = 1-2

idmap gid = 1-2


But the UID and GID returned by getent for the domain accounts are all greater 
than 10:

administrator:*:100500:100513:Administrator:/data/administrator:/bin/false
testusr:*:101103:100513:testusr:/data/testusr:/bin/false
krbtgt:*:100502:100513:krbtgt:/data/krbtgt:/bin/false
guest:*:100501:100514:Guest:/data/guest:/bin/false


Therefore, it may cause the computed UID value to fail the boundary check that 
was introduced in the _wbint_Sids2UnixIDs function.


What I don't explain is that the mapping of a domain account to a local UID 
seems to works correctly (which is what _wbint_Sids2UnixIDs do), it is the 
reverse operation that fails.


I've upgraded the lab to 4.5.2+dfsg-2 that has been released to testing since, 
and I've noticed a very different behavior: the mapped UID and GID now falls 
within the range defined by the idmap uid and idmap gid directives. It seems 
that some change introduced in 4.5.2+dfsg-2 has solved this problem:


root@v-smb-fs:~# getent passwd

administrator:*:1:10004:Administrator:/data/administrator:/bin/false
testusr:*:10001:10004:testusr:/data/testusr:/bin/false
krbtgt:*:10002:10004:krbtgt:/data/krbtgt:/bin/false
guest:*:10003:10005:Guest:/data/guest:/bin/false


root@v-smb-fs:~# wbinfo --user-info=testusr
testusr:*:10001:10004:testusr:/data/testusr:/bin/false

root@v-smb-fs:~# wbinfo --uid-info=10001
testusr:*:10001:10004:testusr:/data/testusr:/bin/false

Thank you for your help,


Best regards,


Stephane


De : Mathieu Parent 
Envoyé : dimanche 1 janvier 2017 17:36
À : stephane; 848...@bugs.debian.org
Objet : Re: [Pkg-samba-maint] Bug#848935: libnss-winbind: winbind 
authentication and wbinfo --uid-info no longer work after uprading to 
4.5.2+dfsg-1

Control: tag -1 + upstream

2016-12-21 0:25 GMT+01:00 stephane :
> Package: libnss-winbind
> Version: 2:4.5.2+dfsg-1
> Severity: important
>
> Dear maintener,

Hi,

> I'm encountering the following problem since the upgrade of the 
> libnss-winbind, winbind and samba packages from
> 4.4.7+dfsg-1 to 4.5.2+dfsg-1: users can no longer access network shares
> on a file server joined (as a member) to a samba-ad-dc based domain.
>
> After further troubleshooting, it appears that the local UID and GID
> numbers fails to be mapped to the domain accounts.


Thanks for your complete bug report.

It's hard to me to come to a conclusion, but it looks like:
  https://bugzilla.samba.org/show_bug.cgi?id=12410
and the corresponding change:
  https://bugzilla.samba.org/show_bug.cgi?id=12155
Bug 12155 - Some idmap backends don't perform range checks 
...
bugzilla.samba.org
The Samba-Bugzilla - Bug 12155. Some idmap backends don't perform range checks 
for the result of sids_to_xids. Last modified: 2016-12-19 18:38:28 UTC



Regards

--
Mathieu

Bug#849997: python3-gitdb depends on both python-smmap and python3-smmap

[wavexx]

Package: python3-gitdb
Severity: normal

I noticed that python3-gitdb depends on both python versions of smmap.

-- System Information:
Debian Release: stretch/sid
 APT prefers unstable
 APT policy: (900, 'unstable'), (800, 'experimental')
Architecture: amd64 (x86_64)

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

Bug#849998: replace device-specific ACPI brightness script with a general script

[Stephen Gildea]

Package: acpi-support
Version: 0.142-8
Tags: patch

Please accept this patch updating the brightness-adjusting script.

I noticed that asus-keyboard-backlight.sh did all the things I wanted,
but it had the path of the device class hardwired in, and I have
different hardware.  So I pulled out the path into a second argument.
In the process I enhanced the values you can pass as the first
(up/down) argument to support a wide variety of devices and behavior.

Because the new script is more general, I renamed it from
asus-keyboard-backlight.sh to brightness.sh and changed the callers.

With this change, anyone will be able to add brightness support for a
new device merely by adding new events files.

 < Stephen


diff --git a/events/asus-keyboard-backlight-down 
b/events/asus-keyboard-backlight-down
index 88bcfc1..892a338 100644
--- a/events/asus-keyboard-backlight-down
+++ b/events/asus-keyboard-backlight-down
@@ -1,7 +1,5 @@
 # /etc/acpi/events/asus-keyboard-backlight-down
-# This is called when the user presses the key brightness 
-# down button and calls /etc/acpi/asus-keyboard-backlight.sh for
-# further processing.
+# This is called when the user presses the key brightness down button.
 
 event=hotkey ATKD 00c5
-action=/etc/acpi/asus-keyboard-backlight.sh down
+action=/etc/acpi/brightness.sh down leds/asus::kbd_backlight
diff --git a/events/asus-keyboard-backlight-up 
b/events/asus-keyboard-backlight-up
index 52a3d5a..ba438ac 100644
--- a/events/asus-keyboard-backlight-up
+++ b/events/asus-keyboard-backlight-up
@@ -1,7 +1,5 @@
 # /etc/acpi/events/asus-keyboard-backlight-up
-# This is called when the user presses the key brightness 
-# up button and calls /etc/acpi/asus-keyboard-backlight.sh for
-# further processing.
+# This is called when the user presses the key brightness up button.
 
 event=hotkey ATKD 00c4
-action=/etc/acpi/asus-keyboard-backlight.sh up
+action=/etc/acpi/brightness.sh up leds/asus::kbd_backlight
diff --git a/brightness.sh b/brightness.sh
new file mode 100755
index 000..c47b76c
--- /dev/null
+++ b/brightness.sh
@@ -0,0 +1,98 @@
+#! /bin/sh
+# Generic script to increase or decrease an ACPI brightness level.
+# Can be used for screen backlight, keyboard backlight,
+# and even to turn on and off binary LEDs.
+
+# An example entry in /etc/acpi/events/ might contain these two lines:
+#
+# event=video/brightnessup *
+# action=/etc/acpi/brightness.sh +12% backlight/myvendor_backlight
+#
+# The "event" line gives the event as reported by acpi_listen when
+# that hotkey is pressed.
+# The "action" lines gives the path to this script and its arguments.
+# Here, we are increasing by 12% the brightness of "myvendor_backlight".
+#
+# See comments about the arguments in the code, below.
+
+acpi_basedir=/sys/class
+
+# The amount to change the brightness.  Values can be:
+# +N%  -- up by that percentage, e.g., "+5%"
+# -N%  -- down by that percentage
+# =N%  -- set to that percentage
+# +N   -- up by that raw value
+# -N   -- down by that raw value
+# =N   -- set to that raw value
+#  -- there are various aliases defined; see the case statement below.
+
+# In the +/- cases, the amount may be adjusted to make some difference.
+# For example, raising a two-value keyboard backlight by +5% will actually
+# raise it by 50%, because that is the granularity of the value.
+# This behavior is intended to make the "up" and "down" aliases most useful.
+
+adjustment_arg=$1
+case $adjustment_arg in
+  up)   adjustment_arg="+5%" ;;
+  down) adjustment_arg="-5%" ;;
+  on)   adjustment_arg="=100%" ;;
+  off)  adjustment_arg="=0%" ;;
+  +*|-*|=*) ;;
+  *) echo "$0: Unknown adjustment argument '$1'" >&2 ; exit 1 ;;
+esac
+
+# The subdirectory of /sys/class that contains the brightness files
+# This is probably a directory under leds/ or backlight/
+# If unspecified and there is a unique directory under backlight/
+# we use that.
+
+if [ "$2" ]; then
+  # no leading .. allowed in directory names
+  case $2 in ..*|*/..*) exit 1;; esac
+  acpi_dir=$acpi_basedir/$2
+else
+  acpi_dir=$(echo "$acpi_basedir"/backlight/*)
+fi
+
+# Quit if we don't find the directory or the files we expect.
+set -e
+
+cd "$acpi_dir"
+
+read -r max_value < ./max_brightness
+read -r cur_value < ./brightness
+
+case $adjustment_arg in
+  =*)
+absolute_arg=${adjustment_arg#=}
+case $absolute_arg in
+  *%) new_value=$((max_value * ${absolute_arg%\%} / 100));;
+  *) new_value=$absolute_arg;;
+esac
+;;
+  *%)
+step_by=$((max_value * ${adjustment_arg%\%} / 100))
+if [ "$step_by" = 0 ]; then
+  # This works for keyboard backlights (which often have only 2 levels),
+  # and binary lights with only one level.
+  case $adjustment_arg in
+-*) step_by=-1 ;;
+*)  step_by=1 ;;
+  esac
+fi
+new_value=$((cur_value + step_by))
+;;
+  *)
+new_value=$((cur_value + adjustment_arg))
+;;
+esac
+
+if [ "$new_value" -lt 0 ]; then
+  new_value=0
+elif [ "$new_value" -gt 

Bug#849532: flash-kernel does not remove dtb backups

[Martin Michlmayr]

* Heinrich Schuchardt  [2016-12-28 10:10]:
> The .bak file should not be created on the first install of a Linux kernel.

Yeah, that's a separate issue but it's definitely something I noticed
too.  The DTB handling code is run several times under some
circumstances, see e.g. the log below.

I'm afraid to touch that code and hope Ian will look into it at some
point.

...
Taking backup of tegra210-p2371-2180.dtb.
Installing new tegra210-p2371-2180.dtb.
flash-kernel: deferring update (trigger activated)
/etc/kernel/postinst.d/zz-flash-kernel:
DTB: tegra210-p2371-2180.dtb
Installing 
/usr/lib/linux-image-4.9.0-trunk-arm64/nvidia/tegra210-p2371-2180.dtb into 
/boot/dtbs/4.9.0-trunk-arm64/tegra210-p2371-2180.dtb
Taking backup of tegra210-p2371-2180.dtb.
Installing new tegra210-p2371-2180.dtb.
Installing 
/usr/lib/linux-image-4.9.0-trunk-arm64/nvidia/tegra210-p2371-2180.dtb into 
/boot/dtbs/4.9.0-trunk-arm64/tegra210-p2371-2180.dtb
Taking backup of tegra210-p2371-2180.dtb.
Installing new tegra210-p2371-2180.dtb.
flash-kernel: deferring update (trigger activated)
Processing triggers for flash-kernel (3.73) ...
DTB: tegra210-p2371-2180.dtb
Installing 
/usr/lib/linux-image-4.9.0-trunk-arm64/nvidia/tegra210-p2371-2180.dtb into 
/boot/dtbs/4.9.0-trunk-arm64/tegra210-p2371-2180.dtb
Taking backup of tegra210-p2371-2180.dtb.
Installing new tegra210-p2371-2180.dtb.
flash-kernel: installing version 4.9.0-trunk-arm64
Generating boot script u-boot image... done.
Taking backup of boot.scr.
Installing new boot.scr.

-- 
Martin Michlmayr
http://www.cyrius.com/

Bug#845779: flash-kernel: flashkernel uses mkimage -A arm on arm64

[Martin Michlmayr]

Thanks, I applied this patch.

U-boot on the ARM64 system I tested (a Jetson TX1) accepts boot
scripts with both -A arm and -A arm64, but as you point out this may
not be the case on all systems.

-- 
Martin Michlmayr
http://www.cyrius.com/

Bug#849996: tigervncserver doesn't work

[Daniel Baumann]

Package: tigervnc
Version: 1.7.0+dfsg-1
Severity: serious

Hi,

thanks for fixing #849963, however, tighervncserver still just doesn't
work at all for me:

daniel@daniel:~$ tigervncserver
Exiting subroutine via next at /usr/bin/tigervncserver line 129.
Exiting subroutine via next at /usr/bin/tigervncserver line 129.
Label not found for "next cmd" at /usr/bin/tigervncserver line 129.
daniel@daniel:-$

Regards,
Daniel

Bug#849991: breathe: FTBFS with new doxygen?

[Sebastian Ramacher]

Control: reassign doxygen 1.8.13-3
Control: affects -1 + src:breathe

On 2017-01-02 22:22:41, Gianfranco Costamagna wrote:
> Source: breathe
> Version: 4.4.0-1
> Severity: Serious
> Justification: FTBFS
> 
> Hello, seems that a no-change binNMU now makes the package fail to build from 
> source [1]
> I discovered this in Ubuntu autopkgtestsuite, and seems probably related to 
> the new doxygen 1.8.13.
> (I didn't investigate the failure, so feel free to disregard or reassign this 
> bug where appropriate)

That's doxygen crashing:

$ apt-get source breathe
$ cd breathe-4.4.0/examples/tinyxml
$ gdb --args doxygen tinyxml.cfg
GNU gdb (Debian 7.12-4) 7.12
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from doxygen...Reading symbols from 
/usr/lib/debug/.build-id/2c/5b57e61012c209a82ea5c47759da68b259573c.debug...done.
done.
(gdb) r

< snip many warnings >

Program received signal SIGSEGV, Segmentation fault.
generateXMLForMember (md=md@entry=0x56902930, ti=..., t=..., 
def=def@entry=0x5696bee0) at ./src/xmlgen.cpp:623
623 ./src/xmlgen.cpp: No such file or directory.
(gdb) bt
#0  generateXMLForMember (md=md@entry=0x56902930, ti=..., t=..., 
def=def@entry=0x5696bee0) at ./src/xmlgen.cpp:623
#1  0x55a6eb99 in generateXMLSection (d=d@entry=0x5696bee0, ti=..., 
t=..., ml=ml@entry=0x569536d0, kind=0x55ddbc9d "friend", 
header=header@entry=0x0, documentation=0x0) at ./src/xmlgen.cpp:1066
#2  0x55a706de in generateXMLForClass (cd=0x5696bee0, ti=...) at 
./src/xmlgen.cpp:1390
#3  0x55a747f4 in generateXML () at ./src/xmlgen.cpp:1919
#4  0x55812ce2 in generateOutput () at ./src/doxygen.cpp:11590
#5  0x557c69ae in main (argc=2, argv=0x7fffeb68) at 
./src/main.cpp:38

Reassigning to doxygen
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#849995: [j.d.n] Store coverage report of diffoscope builds

[Mattia Rizzolo]

Package: jenkins.debian.org
X-Debbugs-Cc: Chris Lamb 
Control: submitter -1 Chris Lamb 

https://jenkins.debian.net/view/reproducible/job/reproducible_diffoscope_from_git_master/
https://jenkins.debian.net/view/reproducible/job/reproducible_diffoscope_from_git_branches/

These two job should store the coverage reports that are automatically
done by a diffoscope build.  It's currently a tad tricy as the regular
Debian build that it's being done just discard the files (as we don't
want them to be installed in the resulting binary package.

We want those to be stored so we can know how the coverage changes over
time, and improve the testing coverage of diffoscope itself.

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#849994: roundcube-core: install fails; Class 'Patchwork\Utf8\Bootup' not found

[Claude Heiland-Allen]

Package: roundcube
Version: 1.1.5+dfsg.1-1~bpo8+2
Severity: grave
Justification: renders package unusable

Dear Maintainer,

   * What led up to the situation?

Regular maintainance aptitude safe-upgrade pulled a new version of roundcube
from jessie-backports which failed to install.  Here is the log:

$ sudo aptitude safe-upgrade
Resolving dependencies...
The following partially installed packages will be configured:
  roundcube roundcube-core roundcube-plugins
No packages will be installed, upgraded, or removed.
0 packages upgraded, 0 newly installed, 0 to remove and 3 not upgraded.
Need to get 0 B of archives. After unpacking 0 B will be used.
Setting up roundcube-core (1.1.5+dfsg.1-1~bpo8+2) ...
Determining localhost credentials from /etc/mysql/debian.cnf: succeeded.
dbconfig-common: writing config to /etc/dbconfig-common/roundcube.conf
dbconfig-common: flushing administrative password
PHP Fatal error:  Uncaught Error: Class 'Patchwork\Utf8\Bootup' not
found in /usr/share/roundcube/program/include/iniset.php:81
Stack trace:
#0 /usr/share/roundcube/program/include/clisetup.php(26): require_once()
#1 /usr/share/roundcube/bin/update.sh(31):
require_once('/usr/share/roun...')
#2 {main}
  thrown in /usr/share/roundcube/program/include/iniset.php on line 81
dpkg: error processing package roundcube-core (--configure):
 subprocess installed post-installation script returned error exit
status 255
dpkg: dependency problems prevent configuration of roundcube:
 roundcube depends on roundcube-core (= 1.1.5+dfsg.1-1~bpo8+2); however:
  Package roundcube-core is not configured yet.

dpkg: error processing package roundcube (--configure):
 dependency problems - leaving unconfigured
dpkg: dependency problems prevent configuration of roundcube-plugins:
 roundcube-plugins depends on roundcube-core (= 1.1.5+dfsg.1-1~bpo8+2);
however:
  Package roundcube-core is not configured yet.

dpkg: error processing package roundcube-plugins (--configure):
 dependency problems - leaving unconfigured
Errors were encountered while processing:
 roundcube-core
 roundcube
 roundcube-plugins
E: Sub-process /usr/bin/dpkg returned an error code (1)
Failed to perform requested operation on package.  Trying to recover:
Setting up roundcube-core (1.1.5+dfsg.1-1~bpo8+2) ...
Determining localhost credentials from /etc/mysql/debian.cnf: succeeded.
dbconfig-common: writing config to /etc/dbconfig-common/roundcube.conf
dbconfig-common: flushing administrative password
PHP Fatal error:  Uncaught Error: Class 'Patchwork\Utf8\Bootup' not
found in /usr/share/roundcube/program/include/iniset.php:81
Stack trace:
#0 /usr/share/roundcube/program/include/clisetup.php(26): require_once()
#1 /usr/share/roundcube/bin/update.sh(31):
require_once('/usr/share/roun...')
#2 {main}
  thrown in /usr/share/roundcube/program/include/iniset.php on line 81
dpkg: error processing package roundcube-core (--configure):
 subprocess installed post-installation script returned error exit
status 255
dpkg: dependency problems prevent configuration of roundcube-plugins:
 roundcube-plugins depends on roundcube-core (= 1.1.5+dfsg.1-1~bpo8+2);
however:
  Package roundcube-core is not configured yet.

dpkg: error processing package roundcube-plugins (--configure):
 dependency problems - leaving unconfigured
dpkg: dependency problems prevent configuration of roundcube:
 roundcube depends on roundcube-core (= 1.1.5+dfsg.1-1~bpo8+2); however:
  Package roundcube-core is not configured yet.

dpkg: error processing package roundcube (--configure):
 dependency problems - leaving unconfigured
Errors were encountered while processing:
 roundcube-core
 roundcube-plugins
 roundcube

$


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

I installed php-patchwork-utf8 from testing but that did not resolve
the issue.


Thanks,

Claude


-- System Information:
Debian Release: 8.6
  APT prefers stable
  APT policy: (900, 'stable'), (800, 'testing'), (500, 'stable-updates')
Architecture: amd64 (x86_64)

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

Versions of packages roundcube-core depends on:
ii  dbconfig-common2.0.6~bpo8+1
ii  debconf [debconf-2.0]  1.5.56
ii  dpkg   1.17.27
ii  libapache2-mod-php55.6.29+dfsg-0+deb8u1
ii  libmagic1  1:5.22+15-2+deb8u2
ii  php-auth-sasl  1.0.6-1+deb8u1
ii  php-mail-mime  1.8.9-1+deb8u1
ii  php-net-sieve  1.3.2-4
ii  php-net-smtp   1.6.2-2
ii  php-net-socket 1.0.14-1
ii  php-patchwork-utf8 1.3.1-1
ii  php-pear   5.6.29+dfsg-0+deb8u1
ii  php5   5.6.29+dfsg-0+deb8u1
ii  php5-cli   5.6.29+dfsg-0+deb8u1
ii  php5-common5.6.29+dfsg-0+deb8u1
ii  php5-intl  5.6.29+dfsg-0+deb8u1
ii  php5-json  1.3.6-1
ii  php5-mcrypt

Bug#848046: glances: upgrade fails when server is disabled

[Axel Beckert]

Hi Daniel,

Axel Beckert wrote:
> > --- a/etc/init.d/glances2016-12-14 11:14:04.0 +0100
> > +++ b/etc/init.d/glances2016-12-14 11:13:43.0 +0100
> > @@ -118,7 +118,12 @@ case "$1" in
> >  ;;
> >*)
> >  # Failed to stop
> > -log_end_msg 1
> > +if [ "$RUN" != "true" ]; then
> > +log_action_msg "disabled by /etc/default/$NAME"
> > +log_end_msg 0
> > +else
> > +log_end_msg 1
> > +fi
> >  ;;
> >  esac
> >  ;;
> 
> I'll test that patch later.

That patch works fine for me. The following "one-liner" fixed all
affected machines for me:

cd /; GET 
https://bugs.debian.org/cgi-bin/bugreport.cgi\?att\=1\;bug\=848046\;filename\=glances-init.d.diff\;msg\=15
 | patch -p1 ; dpkg --configure --pending

Would be so kind an apply that patch in an upload before the freeze
for Stretch?

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


signature.asc
Description: Digital signature

Bug#849950: [Pkg-freeipa-devel] Bug#849950: freeipa: CVE-2016-9575: Insufficient permission check in certprofile-mod

[Timo Aaltonen]

On 02.01.2017 17:45, Salvatore Bonaccorso wrote:
> Source: freeipa
> Version: 4.3.2-5
> Severity: grave
> Tags: upstream security
> Justification: user security hole
> 
> Hi,
> 
> the following vulnerability was published for freeipa. Note that I'm
> not too familiar with freeipa, so just checked source wise. The code
> should be present in ipalib/plugins/certprofile.py, and according to
> the Red Hat bug [1] all freeipa versions above 4.2 should be affected.
> it contains a patch as well.

Yes, I'm aware of these recent cve's but can't test any updates because
tomcat 8.5 broke dogtag-pki. Will need to wait for that to get fixed
first I guess, and then push 4.4.3 out.


-- 
t

Bug#849974: openmpi: not enough slots available

[Thibaut Paumard]

Dear Heinrich,

I also had noted this change in behaviour, I don't know whether this is
intentional. It looks like openmpi does not want to do oversubscription
by default anymore. You can get the old behaviour back by using the
--map-by option:

mpirun --map-by socket:OVERSUBSCRIBE -np 4 python -c "print 'hello'"



Le 02/01/2017 à 20:37, Heinrich Schuchardt a écrit :
> I am running on Intel Core i5-6300U CPU @ 2.40GHz.
> /proc/cpuinfo reports 4 CPUs.

http://ark.intel.com/fr/products/88190/Intel-Core-i5-6300U-Processor-3M-Cache-up-to-3_00-GHz

Your CPU has 4 threads, but only 2 real cores. So the real limit for
oversubscription is 2 rather than 4.

> mpirun -np 2 --hostfile hostfile python -c "print 'hello'"
> works fine.
> 
> mpirun -np 4 --hostfile hostfile python -c "print 'hello'"
> fails with
> "There are not enough slots available in the system to satisfy the 4 slots"
> 
> https://www.open-mpi.org/faq/?category=running#slots-without-hostfiles
> describes that overprovisioning should work
> 
> Best regards
> 
> Heinrich Schuchardt

Kind regards, Thibaut

Bug#799535: Processed: retitle to RFP: bauble-installer -- bauble is a botanic collection manager

[Mario Frasca]

Hi here

I had almost forgotten about this issue, but I'm still and absolutely
very much busy with the software mentioned here.

my work concerning the software is mostly at
http://github.com/Ghini/ghini.desktop

if there's anything I should do to make the software more
debian-compliant, please let me know.

MF


On 2017-01-02 17:21, Debian Bug Tracking System wrote:
> Processing commands for cont...@bugs.debian.org:
>
>> retitle 799535 RFP: bauble-installer -- bauble is a botanic collection 
>> manager
> Bug #799535 [wnpp] ITP: bauble-installer -- bauble is a botanic collection 
> manager
> Changed Bug title to 'RFP: bauble-installer -- bauble is a botanic collection 
> manager' from 'ITP: bauble-installer -- bauble is a botanic collection 
> manager'.
>> noowner 799535
> Bug #799535 [wnpp] RFP: bauble-installer -- bauble is a botanic collection 
> manager
> Removed annotation that Bug was owned by Mario Frasca .
>> stop
> Stopping processing here.
>
> Please contact me if you need assistance.

Bug#837154: your "itemfix" commit to AWL / vProperty

[Florian Schlichting]

Hi Clemens,

while investigating Debian bug #837154 ("backslash escaping sometimes
broken in vCard", see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=837154)
I happened upon an AWL commit by you merged about a year ago:

Fixed grouped Properties naming (e.g. Addresses: item1.ADR instead of just 
ADR) that caused item1.ADR to be written to DB(address_address_adr) because it 
doesn't match ADR, fix works ofr every grouped Property (yet there is only 
ADR...).
Added VCard Property ORG as nondefault (because it takes more then one 
Value).
Fixed false handling of Properties that can have more than one value (e.g. 
ORG) where values are seperated by semicolons


https://gitlab.com/davical-project/awl/commit/164e22151e1ed80b048e84003f8106c443f8718d

One hunk of this was reverted by Andrew in May:


https://gitlab.com/davical-project/awl/commit/4eb8f1bc91062296e0e24e8ef46a6403c70c2936

And I'm about to revert some more lines of it, in order to resurrect backslash 
escaping
as well as escaping of semicolons for "other" properties (which fixes #837154):

--- a/inc/vProperty.php
+++ b/inc/vProperty.php
@@ -398,13 +398,15 @@ class vProperty extends vObject {
 /** Content escaping does not apply to these properties culled 
from RFC6350 / RFC2426 */
 case 'ADR':case 'N':case 'ORG':
 // escaping for ';' for these fields also needs to happen to the 
components they are built from.
+$escaped = str_replace( '\\', '', $escaped);
 $escaped = preg_replace( '/\r?\n/', '\\n', $escaped);
 $escaped = str_replace( ',', '\\,', $escaped);
 break;
 /** Content escaping applies by default to other properties */
 default:
+$escaped = str_replace( '\\', '', $escaped);
 $escaped = preg_replace( '/\r?\n/', '\\n', $escaped);
-$escaped = preg_replace( "/([,])/", '$1', $escaped);
+$escaped = preg_replace( "/([,;])/", '$1', $escaped);
 }
.
 $rendered = '';

I wonder if these parts of your commit were in fact not necessary to
achieve what you wanted to achieve, or if this will break your fix? Do
you have a test case, like an actual vCard or two, where you can explain
how it's supposed to be handled and what went wrong before your commit?

(I think it would be good to have more regression tests for vCard
handling, and to have the carddav suite fully passing, because this
seems to be a complicated area and from my cursory reading of the vCard
spec I think we may be cutting some corners currently. So it would be
good to have clearer documentation in the code what assumptions we make,
which parts of the spec we skip, how those lists of properties are
compiled from the mentioned RFCs etc., as well as the ability to rely on
regression testing to be sure we're not accidentally breaking stuff with
our fixes...)

Florian

Bug#849992: fbreader: provides no way to mark books as read or unread

[Francesco Poli]

Package: fbreader
Version: 0.12.10dfsg2-2
Severity: wishlist

Hello Eugene!

I failed to find a way to mark books as read/unread in fbreader.

I mean: fbreader remembers which is the book the user is reading and
the point the user were, when the program was last closed.

This is good, but there should be a way to distinguish which books
have already been completed, and which books are still be read.
It's an important feature, especially when the user's collection of
e-books begins to grow beyond the few books that may easily be remembered
as read or unread and easily be searched by simply glancing over the
list.

Is there a way (other than moving read books out of the directories
scanned by fbreader...)?
If this feature has already been implemented, it should be documented
in a more prominent place.
Otherwise, it should be implemented (and documented, obviously).

Please help upstream to implement and/or document this feature and/or
forward my bug report upstream, as appropriate.

Thanks for your time!
Bye.


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

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

Versions of packages fbreader depends on:
ii  libc6  2.24-8
ii  libgcc11:6.2.1-5
ii  libsqlite3-0   3.15.2-2
ii  libstdc++6 6.2.1-5
ii  libzlcore0.13  0.12.10dfsg2-2
ii  libzltext0.13  0.12.10dfsg2-2
ii  libzlui-qt40.12.10dfsg2-2

fbreader recommends no packages.

fbreader suggests no packages.

-- no debconf information

Bug#849993: qtwebengine5-dev:amd64: References libQt5WebEngineWidgets.so in cmake and package, but destination of the symbolic link does not exist

[Witold Baryluk]

Package: qtwebengine5-dev
Version: 5.7.1+dfsg-1
Severity: normal

It looks like one of the symbolic links in the package is dangling.

I couldn't find a destination file in any of the packages in debian, nor
in dependent packages (like libqt5webengine5 or libqt5webenginecore5)


$ dpkg -L qtwebengine5-dev | egrep 'usr/lib.*libQt.*so'
/usr/lib/x86_64-linux-gnu/libQt5WebEngine.so
/usr/lib/x86_64-linux-gnu/libQt5WebEngineCore.so
/usr/lib/x86_64-linux-gnu/libQt5WebEngineWidgets.so


$ LC_ALL=C ls -l /usr/lib/x86_64-linux-gnu/libQt5WebEngine*.so
lrwxrwxrwx 1 root root 24 Dec 24 03:15 
/usr/lib/x86_64-linux-gnu/libQt5WebEngine.so -> libQt5WebEngine.so.5.7.1
lrwxrwxrwx 1 root root 28 Dec 24 03:15 
/usr/lib/x86_64-linux-gnu/libQt5WebEngineCore.so -> libQt5WebEngineCore.so.5.7.1
lrwxrwxrwx 1 root root 31 Dec 24 03:15 
/usr/lib/x86_64-linux-gnu/libQt5WebEngineWidgets.so -> 
libQt5WebEngineWidgets.so.5.7.1

$ env LC_ALL=C stat -L /usr/lib/x86_64-linux-gnu/libQt5WebEngineWidgets.so
stat: cannot stat '/usr/lib/x86_64-linux-gnu/libQt5WebEngineWidgets.so': No 
such file or directory
$


# apt-get install qtbase5-dev qtmultimedia5-dev qtdeclarative5-dev 
libqt5xmlpatterns5-dev  libqt5webkit5-dev qtwebengine5-dev libhunspell-dev

$ git clone https://github.com/OtterBrowser/otter-browser.git
$ cd otter-browser && mkdir build && cd build && cmake ../

This leads to this error when trying to run 'cmake ../' in otter-browser from 
github.

CMake Error at 
/usr/lib/x86_64-linux-gnu/cmake/Qt5WebEngineWidgets/Qt5WebEngineWidgetsConfig.cmake:27
 (message):
  The imported target "Qt5::WebEngineWidgets" references the file

 "/usr/lib/x86_64-linux-gnu/libQt5WebEngineWidgets.so.5.7.1"

  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/Qt5WebEngineWidgets/Qt5WebEngineWidgetsConfig.cmake"

  but not all the files it references.

Call Stack (most recent call first):
  
/usr/lib/x86_64-linux-gnu/cmake/Qt5WebEngineWidgets/Qt5WebEngineWidgetsConfig.cmake:43
 (_qt5_WebEngineWidgets_check_file_exists)
  
/usr/lib/x86_64-linux-gnu/cmake/Qt5WebEngineWidgets/Qt5WebEngineWidgetsConfig.cmake:134
 (_populate_WebEngineWidgets_target_properties)
  CMakeLists.txt:86 (find_package)
...

$

Thanks.


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

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

Versions of packages qtwebengine5-dev:amd64 depends on:
ii  libqt5webchannel5-dev  5.7.1-1
ii  libqt5webengine5   5.7.1+dfsg-1
ii  qtbase5-dev5.7.1+dfsg-2
ii  qtdeclarative5-dev 5.7.1-1

qtwebengine5-dev:amd64 recommends no packages.

qtwebengine5-dev:amd64 suggests no packages.

-- no debconf information

Bug#849991: breathe: FTBFS with new doxygen?

[Gianfranco Costamagna]

Source: breathe
Version: 4.4.0-1
Severity: Serious
Justification: FTBFS

Hello, seems that a no-change binNMU now makes the package fail to build from 
source [1]
I discovered this in Ubuntu autopkgtestsuite, and seems probably related to the 
new doxygen 1.8.13.
(I didn't investigate the failure, so feel free to disregard or reassign this 
bug where appropriate)


[1] 
http://debomatic-amd64.debian.net/distribution#unstable/breathe/4.4.0-1/buildlog

thanks,

G.

Bug#818926: perl6-panda: panda doesn't start up / find needed libraries

[gregor herrmann]

On Mon, 05 Sep 2016 23:29:27 +0200, gregor herrmann wrote:

> Maybe zef is in option:
> https://github.com/ugexe/zef

I'm just reading 
http://blogs.perl.org/users/steve_mynott/2017/01/rakudo-star-past-present-and-future.html
which mentions that Rakudo Star is moving from panda to zef.
 

Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at/ - Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   NP: Leonard Cohen: Alexandra Leaving


signature.asc
Description: Digital Signature

Bug#844081: Reproducer

[Filip Pytloun]

Great, thank you.

We have two options now before stretch code freeze:

- do upload of new upstream (even major, eg. 0.9) version before
  2017-02-05 (minus 10 days, better sooner)

- maintain 0.8.x as a stable serie in stretch with bugfixes, etc.
  Newer releases will be uploaded normally to unstable and testing after
  stretch code freeze (+ stretch-backports eventually)

I would personally prefer 2nd option as refactor around vdir seems to be
pretty huge and 0.8.4 version is working very well (I am using it since
it's release) so I would stick to that as it's well tested and stable.

Filip

On 2017/01/02 22:55, Christian Geier wrote:
> I'll backport those changes onto the 0.8 branch tomorrow. I'll send another 
> email when it's done. 
> 
> Am 2. Januar 2017 22:48:21 MEZ, schrieb Filip Pytloun :
> >Hello,
> >
> >I checked the changes and as they are done on top of huge refactoring
> >(introduce of vdir.py), backporting it back to 0.8.4 seems to be too
> >risky so I will workaround this occasional FTBFS by marking the test as
> >xfail to avoid autoremoval from stretch.
> >
> >If we want to fix this issue correctly back in stretch after it's is
> >stable, it's possible to do upload of new minor version.
> >
> >Filip
> >
> >On 2016/12/19 19:06, Christian Geier wrote:
> >> Hi,
> >> I could reproduce the issue and have fixed it, see the PR on github
> >[1].
> >> Depending on how urgent this is, you can either just take the
> >os.sync()
> >> commit and apply that to the version currently in Debian (which,
> >while
> >> brute force, certainly fixes this problem), or you might want to wait
> >if
> >> we find a more elegant solution.
> >> 
> >> Christian
> >> 
> >> [1] https://github.com/pimutils/khal/pull/543
> >> 
> >> Quoting Filip Pytloun (2016-12-11 13:16:56)
> >> > Hello,
> >> > 
> >> > unfortunately I have no longer access to environment where this was
> >> > happening. But if you were able to reproduce the issue and this
> >fixed it
> >> > for you, I'll apply it and make new release.
> >> > 
> >> > Anyway wouldn't it better to ensure data is written to disk
> >directly
> >> > during db updates and other operations? Eg. use O_SYNC for safety
> >as
> >> > these operations doesn't happen so often.
> >> > 
> >> > Filip
> >> > 
> >> > On 2016/12/11 01:14, Christian Geier wrote:
> >> > > Hi Filip,
> >> > > could you perhaps try to change all those sleep()s to
> >`os.sync()`? For
> >> > > me it seems to fix the issue.
> >> > > 
> >> > > See [0] for a patch.
> >> > > 
> >> > > If this doesn fix the issue, we obviously need to move the sync
> >call out
> >> > > of the tests and into the db update.
> >> > > 
> >> > > Best regards,
> >> > > Christian
> >> > > 
> >> > > [0]
> >https://github.com/pimutils/khal/commit/0b636f7633e86b9e136b06e9965cd3af0e3918f2
> >> > > 
> 
> -- 
> Sent from my phone. Please excuse my brevity.


signature.asc
Description: Digital signature

Bug#849564: python3-reportbug: reportbug fails with AttributeError: 'str' object has no attribute 'utils'

[Francesco Poli]

Control: severity -1 important


On Sat, 31 Dec 2016 04:56:37 -0500 Matthew Gabeler-Lee wrote:

[...]
> This bug seems like it maybe should be higher severity than 'normal'.

Agreed. I am setting the severity to "important", since this bug seems
to have a major effect on the usability of reportbug, even though it
does not make it completely unusable

> On
> systems that have 7.1.1 installed, I can't seem to run reportbug no matter
> what I do.

In my case, reportbug reads my e-mail address from the DEBEMAIL
environment variable, while my name is read from the DEBFULLNAME
environment variable.

Unfortunately:

  $ echo $DEBFULLNAME
  Francesco Poli (wintermute)

which also includes some characters which are not letters, digits, or
underscores [\w], nor whitespace characters [\s]: in my case, the
non-matching characters are the parentheses.
In the case of Matthew, it's probably the hyphen between the double
surname.
In the case of Bernhard, I guess it's the dot after the first letter of
the middle name.

The consequence is that the regexp at line 313 of
/usr/lib/python3/dist-packages/reportbug/utils.py
does not match and the subsequent return statement (line 314) is not
executed.
The Python interpreter attempts to execute line 316, where the email
string has no attribute 'utils'.

I am under the impression that the email string variable is masking the
email module, or something like that?!?

Anyway, if I set:

  $ DEBFULLNAME="Francesco Poli"

reportbug is able to run.


I hope this bug may be fixed soon.
Thanks for your time!
Bye.

-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgprMRb8ihQxD.pgp
Description: PGP signature

Bug#849989: wicd-curses.py crashed with AttributeError in keypress(): 'Text' object has no attribute 'keypress'

[giovanni . alberotanza]

Package: wicd-curses
Version: 1.7.4+tb2-2


=

ProblemType: Crash
Architecture: amd64
CrashCounter: 1
CurrentDesktop: KDE
Date: Mon Jan  2 23:08:30 2017
Dependencies:
 adduser 3.115
 adwaita-icon-theme 3.22.0-1
 apt 1.4~beta2
 apt-utils 1.4~beta2
 at-spi2-core 2.22.0-4
 bzip2 1.0.6-8
 coreutils 8.26-1
 dbus 1.10.14-1
 dbus-user-session 1.10.14-1
 dconf-gsettings-backend 0.26.0-2
 dconf-service 0.26.0-2
 debconf 1.5.59
 debconf-i18n 1.5.59
 debian-archive-keyring 2014.3
 debianutils 4.8.1
 dirmngr 2.1.16-3
 dmsetup 2:1.02.137-1
 dpkg 1.18.18
 file 1:5.29-2
 fontconfig 2.11.0-6.7
 fontconfig-config 2.11.0-6.7
 fonts-dejavu-core 2.37-1
 gcc-6-base 6.2.1-5
 gconf-service 3.2.6-4
 gconf2 3.2.6-4
 gconf2-common 3.2.6-4
 gcr 3.20.0-3
 gir1.2-glib-2.0 1.50.0-1
 gksu 2.0.2-9 [modified: usr/share/applications/gksu.desktop]
 glib-networking 2.50.0-1
 glib-networking-common 2.50.0-1
 glib-networking-services 2.50.0-1
 gnome-icon-theme 3.12.0-2
 gnome-keyring 3.20.0-3
 gnupg 2.1.16-3
 gnupg-agent 2.1.16-3
 gnupg-l10n 2.1.16-3
 gpgv 2.1.16-3
 gsettings-desktop-schemas 3.22.0-1
 gtk-update-icon-cache 3.22.5-1
 hicolor-icon-theme 0.15-1
 init-system-helpers 1.46
 iputils-ping 3:20161105-1
 krb5-locales 1.15-1
 libacl1 2.2.52-3
 libapparmor1 2.10.95-8
 libapt-inst2.0 1.4~beta2
 libapt-pkg5.0 1.4~beta2
 libassuan0 2.4.3-2
 libatk-bridge2.0-0 2.22.0-1
 libatk1.0-0 2.22.0-1
 libatk1.0-data 2.22.0-1
 libatspi2.0-0 2.22.0-4
 libattr1 1:2.4.47-2
 libaudit-common 1:2.6.7-1
 libaudit1 1:2.6.7-1
 libavahi-client3 0.6.32-1
 libavahi-common-data 0.6.32-1
 libavahi-common3 0.6.32-1
 libblas-common 3.6.1-2
 libblas3 3.6.1-2
 libblkid1 2.29-1
 libbz2-1.0 1.0.6-8
 libc6 2.24-8
 libcairo-gobject2 1.14.8-1
 libcairo2 1.14.8-1
 libcap-ng0 0.7.7-3
 libcap2 1:2.25-1
 libcap2-bin 1:2.25-1
 libcolord2 1.3.3-2
 libcomerr2 1.43.3-1
 libcroco3 0.6.11-2
 libcryptsetup4 2:1.7.3-3
 libcups2 2.2.1-4
 libdatrie1 0.2.10-4
 libdb5.3 5.3.28-12
 libdbus-1-3 1.10.14-1
 libdbus-glib-1-2 0.108-1
 libdconf1 0.26.0-2
 libdevmapper1.02.1 2:1.02.137-1
 libdrm2 2.4.74-1
 libegl1-mesa 13.0.2-3
 libepoxy0 1.3.1-1
 libexpat1 2.2.0-1
 libfdisk1 2.29-1
 libffi6 3.2.1-6
 libfontconfig1 2.11.0-6.7
 libfreetype6 2.6.3-3+b1
 libgail-common 2.24.31-1
 libgail18 2.24.31-1
 libgbm1 13.0.2-3
 libgcc1 1:6.2.1-5
 libgck-1-0 3.20.0-3
 libgconf-2-4 3.2.6-4
 libgcr-3-common 3.20.0-3
 libgcr-base-3-1 3.20.0-3
 libgcr-ui-3-1 3.20.0-3
 libgcrypt20 1.7.5-2
 libgdk-pixbuf2.0-0 2.36.2-1
 libgdk-pixbuf2.0-common 2.36.2-1
 libgfortran3 6.2.1-5
 libgirepository-1.0-1 1.50.0-1
 libgksu2-0 2.0.13~pre1-9
 libglade2-0 1:2.6.4-2
 libglib2.0-0 2.50.2-2
 libglib2.0-data 2.50.2-2
 libgmp10 2:6.1.2+dfsg-1
 libgnome-keyring-common 3.12.0-1
 libgnome-keyring0 3.12.0-1+b1
 libgnutls30 3.5.7-3
 libgpg-error0 1.25-2
 libgpm2 1.20.4-6.2
 libgraphite2-3 1.3.9-2
 libgssapi-krb5-2 1.15-1
 libgtk-3-0 3.22.5-1
 libgtk-3-bin 3.22.5-1
 libgtk-3-common 3.22.5-1
 libgtk2.0-0 2.24.31-1
 libgtk2.0-bin 2.24.31-1
 libgtk2.0-common 2.24.31-1
 libgtop-2.0-10 2.34.1-2
 libgtop2-common 2.34.1-2
 libharfbuzz0b 1.2.7-1+b1
 libhogweed4 3.3-1
 libicu57 57.1-5
 libidn11 1.33-1
 libip4tc0 1.6.0+snapshot20161117-4
 libiw30 30~pre9-12
 libjbig0 2.1-3.1
 libjpeg62-turbo 1:1.5.1-2
 libjson-glib-1.0-0 1.2.2-1
 libjson-glib-1.0-common 1.2.2-1
 libk5crypto3 1.15-1
 libkeyutils1 1.5.9-9
 libkmod2 23-1
 libkrb5-3 1.15-1
 libkrb5support0 1.15-1
 libksba8 1.3.5-2
 liblapack3 3.6.1-2
 liblcms2-2 2.8-3
 libldap-2.4-2 2.4.44+dfsg-2
 libldap-common 2.4.44+dfsg-2
 liblocale-gettext-perl 1.07-3+b1
 liblz4-1 0.0~r131-2
 liblzma5 5.2.2-1.2
 libmagic-mgc 1:5.29-2
 libmagic1 1:5.29-2
 libmount1 2.29-1
 libncursesw5 6.0+20161126-1
 libnettle6 3.3-1
 libnl-3-200 3.2.27-1
 libnl-genl-3-200 3.2.27-1
 libnotify4 0.7.7-1
 libnpth0 1.3-1
 libp11-kit0 0.23.2-5
 libpam-cap 1:2.25-1
 libpam-gnome-keyring 3.20.0-3
 libpam-modules 1.1.8-3.4
 libpam-modules-bin 1.1.8-3.4
 libpam-runtime 1.1.8-3.4
 libpam-systemd 232-8
 libpam0g 1.1.8-3.4
 libpango-1.0-0 1.40.3-3
 libpangocairo-1.0-0 1.40.3-3
 libpangoft2-1.0-0 1.40.3-3
 libpcre3 2:8.39-2
 libpcsclite1 1.8.19-1
 libpixman-1-0 0.34.0-1
 libpng16-16 1.6.26-6
 libproxy1v5 0.4.13-1.1
 libpython-stdlib 2.7.13-1
 libpython2.7-minimal 2.7.13-1
 libpython2.7-stdlib 2.7.13-1
 libquadmath0 6.2.1-5
 libreadline7 7.0-1
 librest-0.7-0 0.8.0-2
 librsvg2-2 2.40.16-1
 librsvg2-common 2.40.16-1
 libsasl2-2 2.1.27~101-g0780600+dfsg-1
 libsasl2-modules 2.1.27~101-g0780600+dfsg-1
 libsasl2-modules-db 2.1.27~101-g0780600+dfsg-1
 libseccomp2 2.3.1-2.1
 libsecret-1-0 0.18.5-2
 libsecret-common 0.18.5-2
 libselinux1 2.6-3
 libsemanage-common 2.6-1
 libsemanage1 2.6-1
 libsepol1 2.6-2
 libsmartcols1 2.29-1
 libsoup-gnome2.4-1 2.56.0-2
 libsoup2.4-1 2.56.0-2
 libsqlite3-0 3.15.2-2
 libssl1.0.2 1.0.2j-4
 libssl1.1 1.1.0c-2
 libstartup-notification0 0.12-4
 libstdc++6 6.2.1-5
 libsystemd0 232-8
 libtasn1-6 4.9-4
 libtext-charwidth-perl 0.04-7+b5
 libtext-iconv-perl 1.7-5+b4
 libtext-wrapi18n-perl 0.06-7.1
 

Bug#849923: openssh-server: no login possible after upgrade on x32

[Aurelien Jarno]

On 2017-01-02 17:49, Colin Watson wrote:
> On Mon, Jan 02, 2017 at 11:36:55AM +0100, Thorsten Glaser wrote:
> > After upgrading from 1:7.3p1-5 to 1:7.4p1-3 I can no longer
> > 'ssh localhost' on x32; switching to openssh-server:i386 with
> > the exact same configuration works, though.
> 
> sshd's seccomp sandbox is denying a clock_gettime call.  But it's more
> interesting than that: its seccomp filter allows clock_gettime; but the
> actual syscall being used is not the x32 clock_gettime (with bit 30
> set), but the x86-64 variant instead.
> 
> You can see a similar effect like this in an x32 environment:
> 
>   strace dmesg -e
> 
> ... and buried in the output you'll find something like:
> 
>   strace: syscall_228(...) in unsupported 64-bit mode of process PID=19943
> 
> Neither sshd nor dmesg is using anything like manual syscall(2) here,
> just the glibc wrappers.
> 
> This feels like a glibc bug to me.  Shouldn't it be using x32 syscalls
> consistently?  The x86-64 variants work, but that's not very
> seccomp-friendly.  (And if necessary I can hack around it in sshd, but
> if you agree that it's a glibc bug then I think it should simply be
> fixed there.)

Looking at the issue, it actually appears in __vdso_clock_gettime, which
is provided by the kernel. This code handle the simple cases (REALTIME, 
MONOTONIC, REALTIME_COARSE and _MONOTONIC_COARSE) and fallbacks to 
the syscall in otherwise, CLOCK_BOOTTIME in the case of sshd.

This therefore looks like a kernel issue to me.

Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net

Bug#849990: wicd-curses.py crashed with AttributeError in keypress(): 'Text' object has no attribute 'keypress'

[giovanni . alberotanza]

Package: wicd-curses
Version: 1.7.4+tb2-2


=

ProblemType: Crash
Architecture: amd64
CrashCounter: 1
CurrentDesktop: KDE
Date: Mon Jan  2 23:08:30 2017
Dependencies:
 adduser 3.115
 adwaita-icon-theme 3.22.0-1
 apt 1.4~beta2
 apt-utils 1.4~beta2
 at-spi2-core 2.22.0-4
 bzip2 1.0.6-8
 coreutils 8.26-1
 dbus 1.10.14-1
 dbus-user-session 1.10.14-1
 dconf-gsettings-backend 0.26.0-2
 dconf-service 0.26.0-2
 debconf 1.5.59
 debconf-i18n 1.5.59
 debian-archive-keyring 2014.3
 debianutils 4.8.1
 dirmngr 2.1.16-3
 dmsetup 2:1.02.137-1
 dpkg 1.18.18
 file 1:5.29-2
 fontconfig 2.11.0-6.7
 fontconfig-config 2.11.0-6.7
 fonts-dejavu-core 2.37-1
 gcc-6-base 6.2.1-5
 gconf-service 3.2.6-4
 gconf2 3.2.6-4
 gconf2-common 3.2.6-4
 gcr 3.20.0-3
 gir1.2-glib-2.0 1.50.0-1
 gksu 2.0.2-9 [modified: usr/share/applications/gksu.desktop]
 glib-networking 2.50.0-1
 glib-networking-common 2.50.0-1
 glib-networking-services 2.50.0-1
 gnome-icon-theme 3.12.0-2
 gnome-keyring 3.20.0-3
 gnupg 2.1.16-3
 gnupg-agent 2.1.16-3
 gnupg-l10n 2.1.16-3
 gpgv 2.1.16-3
 gsettings-desktop-schemas 3.22.0-1
 gtk-update-icon-cache 3.22.5-1
 hicolor-icon-theme 0.15-1
 init-system-helpers 1.46
 iputils-ping 3:20161105-1
 krb5-locales 1.15-1
 libacl1 2.2.52-3
 libapparmor1 2.10.95-8
 libapt-inst2.0 1.4~beta2
 libapt-pkg5.0 1.4~beta2
 libassuan0 2.4.3-2
 libatk-bridge2.0-0 2.22.0-1
 libatk1.0-0 2.22.0-1
 libatk1.0-data 2.22.0-1
 libatspi2.0-0 2.22.0-4
 libattr1 1:2.4.47-2
 libaudit-common 1:2.6.7-1
 libaudit1 1:2.6.7-1
 libavahi-client3 0.6.32-1
 libavahi-common-data 0.6.32-1
 libavahi-common3 0.6.32-1
 libblas-common 3.6.1-2
 libblas3 3.6.1-2
 libblkid1 2.29-1
 libbz2-1.0 1.0.6-8
 libc6 2.24-8
 libcairo-gobject2 1.14.8-1
 libcairo2 1.14.8-1
 libcap-ng0 0.7.7-3
 libcap2 1:2.25-1
 libcap2-bin 1:2.25-1
 libcolord2 1.3.3-2
 libcomerr2 1.43.3-1
 libcroco3 0.6.11-2
 libcryptsetup4 2:1.7.3-3
 libcups2 2.2.1-4
 libdatrie1 0.2.10-4
 libdb5.3 5.3.28-12
 libdbus-1-3 1.10.14-1
 libdbus-glib-1-2 0.108-1
 libdconf1 0.26.0-2
 libdevmapper1.02.1 2:1.02.137-1
 libdrm2 2.4.74-1
 libegl1-mesa 13.0.2-3
 libepoxy0 1.3.1-1
 libexpat1 2.2.0-1
 libfdisk1 2.29-1
 libffi6 3.2.1-6
 libfontconfig1 2.11.0-6.7
 libfreetype6 2.6.3-3+b1
 libgail-common 2.24.31-1
 libgail18 2.24.31-1
 libgbm1 13.0.2-3
 libgcc1 1:6.2.1-5
 libgck-1-0 3.20.0-3
 libgconf-2-4 3.2.6-4
 libgcr-3-common 3.20.0-3
 libgcr-base-3-1 3.20.0-3
 libgcr-ui-3-1 3.20.0-3
 libgcrypt20 1.7.5-2
 libgdk-pixbuf2.0-0 2.36.2-1
 libgdk-pixbuf2.0-common 2.36.2-1
 libgfortran3 6.2.1-5
 libgirepository-1.0-1 1.50.0-1
 libgksu2-0 2.0.13~pre1-9
 libglade2-0 1:2.6.4-2
 libglib2.0-0 2.50.2-2
 libglib2.0-data 2.50.2-2
 libgmp10 2:6.1.2+dfsg-1
 libgnome-keyring-common 3.12.0-1
 libgnome-keyring0 3.12.0-1+b1
 libgnutls30 3.5.7-3
 libgpg-error0 1.25-2
 libgpm2 1.20.4-6.2
 libgraphite2-3 1.3.9-2
 libgssapi-krb5-2 1.15-1
 libgtk-3-0 3.22.5-1
 libgtk-3-bin 3.22.5-1
 libgtk-3-common 3.22.5-1
 libgtk2.0-0 2.24.31-1
 libgtk2.0-bin 2.24.31-1
 libgtk2.0-common 2.24.31-1
 libgtop-2.0-10 2.34.1-2
 libgtop2-common 2.34.1-2
 libharfbuzz0b 1.2.7-1+b1
 libhogweed4 3.3-1
 libicu57 57.1-5
 libidn11 1.33-1
 libip4tc0 1.6.0+snapshot20161117-4
 libiw30 30~pre9-12
 libjbig0 2.1-3.1
 libjpeg62-turbo 1:1.5.1-2
 libjson-glib-1.0-0 1.2.2-1
 libjson-glib-1.0-common 1.2.2-1
 libk5crypto3 1.15-1
 libkeyutils1 1.5.9-9
 libkmod2 23-1
 libkrb5-3 1.15-1
 libkrb5support0 1.15-1
 libksba8 1.3.5-2
 liblapack3 3.6.1-2
 liblcms2-2 2.8-3
 libldap-2.4-2 2.4.44+dfsg-2
 libldap-common 2.4.44+dfsg-2
 liblocale-gettext-perl 1.07-3+b1
 liblz4-1 0.0~r131-2
 liblzma5 5.2.2-1.2
 libmagic-mgc 1:5.29-2
 libmagic1 1:5.29-2
 libmount1 2.29-1
 libncursesw5 6.0+20161126-1
 libnettle6 3.3-1
 libnl-3-200 3.2.27-1
 libnl-genl-3-200 3.2.27-1
 libnotify4 0.7.7-1
 libnpth0 1.3-1
 libp11-kit0 0.23.2-5
 libpam-cap 1:2.25-1
 libpam-gnome-keyring 3.20.0-3
 libpam-modules 1.1.8-3.4
 libpam-modules-bin 1.1.8-3.4
 libpam-runtime 1.1.8-3.4
 libpam-systemd 232-8
 libpam0g 1.1.8-3.4
 libpango-1.0-0 1.40.3-3
 libpangocairo-1.0-0 1.40.3-3
 libpangoft2-1.0-0 1.40.3-3
 libpcre3 2:8.39-2
 libpcsclite1 1.8.19-1
 libpixman-1-0 0.34.0-1
 libpng16-16 1.6.26-6
 libproxy1v5 0.4.13-1.1
 libpython-stdlib 2.7.13-1
 libpython2.7-minimal 2.7.13-1
 libpython2.7-stdlib 2.7.13-1
 libquadmath0 6.2.1-5
 libreadline7 7.0-1
 librest-0.7-0 0.8.0-2
 librsvg2-2 2.40.16-1
 librsvg2-common 2.40.16-1
 libsasl2-2 2.1.27~101-g0780600+dfsg-1
 libsasl2-modules 2.1.27~101-g0780600+dfsg-1
 libsasl2-modules-db 2.1.27~101-g0780600+dfsg-1
 libseccomp2 2.3.1-2.1
 libsecret-1-0 0.18.5-2
 libsecret-common 0.18.5-2
 libselinux1 2.6-3
 libsemanage-common 2.6-1
 libsemanage1 2.6-1
 libsepol1 2.6-2
 libsmartcols1 2.29-1
 libsoup-gnome2.4-1 2.56.0-2
 libsoup2.4-1 2.56.0-2
 libsqlite3-0 3.15.2-2
 libssl1.0.2 1.0.2j-4
 libssl1.1 1.1.0c-2
 libstartup-notification0 0.12-4
 libstdc++6 6.2.1-5
 libsystemd0 232-8
 libtasn1-6 4.9-4
 libtext-charwidth-perl 0.04-7+b5
 libtext-iconv-perl 1.7-5+b4
 libtext-wrapi18n-perl 0.06-7.1
 

Bug#849342: [xrdp] xrdp-sesman: Fails to start Xorg

[Ben Armstrong]

Interesting. Well, the system has a long and complicated history so this is 
unsurprising, I guess. Thanks for that insight. If it happens to any of my 
or systems, I'll know where to look.


Ben
P.S. This system also had a hardware-specific section for the console's 
monitor in /etc/X11/xorg.conf.d/ that initially prevented xrdp from 
starting at all. I worked around the issue by migrating that to 
/etc/X11/xorg.conf. Is that expected behavior or should I file a bug about it?

Bug#849988: wicd-curses.py crashed with AttributeError in keypress(): 'Text' object has no attribute 'keypress'

[giovanni . alberotanza]

Package: wicd-curses
Version: 1.7.4+tb2-2


=

ProblemType: Crash
Architecture: amd64
CurrentDesktop: KDE
Date: Mon Jan  2 23:08:10 2017
Dependencies:
 adduser 3.115
 adwaita-icon-theme 3.22.0-1
 apt 1.4~beta2
 apt-utils 1.4~beta2
 at-spi2-core 2.22.0-4
 bzip2 1.0.6-8
 coreutils 8.26-1
 dbus 1.10.14-1
 dbus-user-session 1.10.14-1
 dconf-gsettings-backend 0.26.0-2
 dconf-service 0.26.0-2
 debconf 1.5.59
 debconf-i18n 1.5.59
 debian-archive-keyring 2014.3
 debianutils 4.8.1
 dirmngr 2.1.16-3
 dmsetup 2:1.02.137-1
 dpkg 1.18.18
 file 1:5.29-2
 fontconfig 2.11.0-6.7
 fontconfig-config 2.11.0-6.7
 fonts-dejavu-core 2.37-1
 gcc-6-base 6.2.1-5
 gconf-service 3.2.6-4
 gconf2 3.2.6-4
 gconf2-common 3.2.6-4
 gcr 3.20.0-3
 gir1.2-glib-2.0 1.50.0-1
 gksu 2.0.2-9 [modified: usr/share/applications/gksu.desktop]
 glib-networking 2.50.0-1
 glib-networking-common 2.50.0-1
 glib-networking-services 2.50.0-1
 gnome-icon-theme 3.12.0-2
 gnome-keyring 3.20.0-3
 gnupg 2.1.16-3
 gnupg-agent 2.1.16-3
 gnupg-l10n 2.1.16-3
 gpgv 2.1.16-3
 gsettings-desktop-schemas 3.22.0-1
 gtk-update-icon-cache 3.22.5-1
 hicolor-icon-theme 0.15-1
 init-system-helpers 1.46
 iputils-ping 3:20161105-1
 krb5-locales 1.15-1
 libacl1 2.2.52-3
 libapparmor1 2.10.95-8
 libapt-inst2.0 1.4~beta2
 libapt-pkg5.0 1.4~beta2
 libassuan0 2.4.3-2
 libatk-bridge2.0-0 2.22.0-1
 libatk1.0-0 2.22.0-1
 libatk1.0-data 2.22.0-1
 libatspi2.0-0 2.22.0-4
 libattr1 1:2.4.47-2
 libaudit-common 1:2.6.7-1
 libaudit1 1:2.6.7-1
 libavahi-client3 0.6.32-1
 libavahi-common-data 0.6.32-1
 libavahi-common3 0.6.32-1
 libblas-common 3.6.1-2
 libblas3 3.6.1-2
 libblkid1 2.29-1
 libbz2-1.0 1.0.6-8
 libc6 2.24-8
 libcairo-gobject2 1.14.8-1
 libcairo2 1.14.8-1
 libcap-ng0 0.7.7-3
 libcap2 1:2.25-1
 libcap2-bin 1:2.25-1
 libcolord2 1.3.3-2
 libcomerr2 1.43.3-1
 libcroco3 0.6.11-2
 libcryptsetup4 2:1.7.3-3
 libcups2 2.2.1-4
 libdatrie1 0.2.10-4
 libdb5.3 5.3.28-12
 libdbus-1-3 1.10.14-1
 libdbus-glib-1-2 0.108-1
 libdconf1 0.26.0-2
 libdevmapper1.02.1 2:1.02.137-1
 libdrm2 2.4.74-1
 libegl1-mesa 13.0.2-3
 libepoxy0 1.3.1-1
 libexpat1 2.2.0-1
 libfdisk1 2.29-1
 libffi6 3.2.1-6
 libfontconfig1 2.11.0-6.7
 libfreetype6 2.6.3-3+b1
 libgail-common 2.24.31-1
 libgail18 2.24.31-1
 libgbm1 13.0.2-3
 libgcc1 1:6.2.1-5
 libgck-1-0 3.20.0-3
 libgconf-2-4 3.2.6-4
 libgcr-3-common 3.20.0-3
 libgcr-base-3-1 3.20.0-3
 libgcr-ui-3-1 3.20.0-3
 libgcrypt20 1.7.5-2
 libgdk-pixbuf2.0-0 2.36.2-1
 libgdk-pixbuf2.0-common 2.36.2-1
 libgfortran3 6.2.1-5
 libgirepository-1.0-1 1.50.0-1
 libgksu2-0 2.0.13~pre1-9
 libglade2-0 1:2.6.4-2
 libglib2.0-0 2.50.2-2
 libglib2.0-data 2.50.2-2
 libgmp10 2:6.1.2+dfsg-1
 libgnome-keyring-common 3.12.0-1
 libgnome-keyring0 3.12.0-1+b1
 libgnutls30 3.5.7-3
 libgpg-error0 1.25-2
 libgpm2 1.20.4-6.2
 libgraphite2-3 1.3.9-2
 libgssapi-krb5-2 1.15-1
 libgtk-3-0 3.22.5-1
 libgtk-3-bin 3.22.5-1
 libgtk-3-common 3.22.5-1
 libgtk2.0-0 2.24.31-1
 libgtk2.0-bin 2.24.31-1
 libgtk2.0-common 2.24.31-1
 libgtop-2.0-10 2.34.1-2
 libgtop2-common 2.34.1-2
 libharfbuzz0b 1.2.7-1+b1
 libhogweed4 3.3-1
 libicu57 57.1-5
 libidn11 1.33-1
 libip4tc0 1.6.0+snapshot20161117-4
 libiw30 30~pre9-12
 libjbig0 2.1-3.1
 libjpeg62-turbo 1:1.5.1-2
 libjson-glib-1.0-0 1.2.2-1
 libjson-glib-1.0-common 1.2.2-1
 libk5crypto3 1.15-1
 libkeyutils1 1.5.9-9
 libkmod2 23-1
 libkrb5-3 1.15-1
 libkrb5support0 1.15-1
 libksba8 1.3.5-2
 liblapack3 3.6.1-2
 liblcms2-2 2.8-3
 libldap-2.4-2 2.4.44+dfsg-2
 libldap-common 2.4.44+dfsg-2
 liblocale-gettext-perl 1.07-3+b1
 liblz4-1 0.0~r131-2
 liblzma5 5.2.2-1.2
 libmagic-mgc 1:5.29-2
 libmagic1 1:5.29-2
 libmount1 2.29-1
 libncursesw5 6.0+20161126-1
 libnettle6 3.3-1
 libnl-3-200 3.2.27-1
 libnl-genl-3-200 3.2.27-1
 libnotify4 0.7.7-1
 libnpth0 1.3-1
 libp11-kit0 0.23.2-5
 libpam-cap 1:2.25-1
 libpam-gnome-keyring 3.20.0-3
 libpam-modules 1.1.8-3.4
 libpam-modules-bin 1.1.8-3.4
 libpam-runtime 1.1.8-3.4
 libpam-systemd 232-8
 libpam0g 1.1.8-3.4
 libpango-1.0-0 1.40.3-3
 libpangocairo-1.0-0 1.40.3-3
 libpangoft2-1.0-0 1.40.3-3
 libpcre3 2:8.39-2
 libpcsclite1 1.8.19-1
 libpixman-1-0 0.34.0-1
 libpng16-16 1.6.26-6
 libproxy1v5 0.4.13-1.1
 libpython-stdlib 2.7.13-1
 libpython2.7-minimal 2.7.13-1
 libpython2.7-stdlib 2.7.13-1
 libquadmath0 6.2.1-5
 libreadline7 7.0-1
 librest-0.7-0 0.8.0-2
 librsvg2-2 2.40.16-1
 librsvg2-common 2.40.16-1
 libsasl2-2 2.1.27~101-g0780600+dfsg-1
 libsasl2-modules 2.1.27~101-g0780600+dfsg-1
 libsasl2-modules-db 2.1.27~101-g0780600+dfsg-1
 libseccomp2 2.3.1-2.1
 libsecret-1-0 0.18.5-2
 libsecret-common 0.18.5-2
 libselinux1 2.6-3
 libsemanage-common 2.6-1
 libsemanage1 2.6-1
 libsepol1 2.6-2
 libsmartcols1 2.29-1
 libsoup-gnome2.4-1 2.56.0-2
 libsoup2.4-1 2.56.0-2
 libsqlite3-0 3.15.2-2
 libssl1.0.2 1.0.2j-4
 libssl1.1 1.1.0c-2
 libstartup-notification0 0.12-4
 libstdc++6 6.2.1-5
 libsystemd0 232-8
 libtasn1-6 4.9-4
 libtext-charwidth-perl 0.04-7+b5
 libtext-iconv-perl 1.7-5+b4
 libtext-wrapi18n-perl 0.06-7.1
 libthai-data 

Bug#849987: fonts-font-awesome: Symlink in /usr/share/javascript for javascript-common

[Michael Fladischer]

Package: fonts-font-awesome
Version: 4.7.0~dfsg-1
Severity: wishlist

Dear Maintainer,

would it be possible to add a symlink at /usr/share/javascript/font-awesome that
points to ../fonts-font-awesome?

This would provide an easy way to use this package with javascript-common and
its apache2 integration. The FontAwesome CSS and its assets would then be
available at URL /javascript/font-awesome/css/font-awesome.css from the
installed apache2 instance.


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

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

-- no debconf information

Bug#848001: supertuxkart: Fix credits for Boom-boom-boom song

[Vincent Cheng]

On Thu, Dec 15, 2016 at 7:08 AM, Legimet  wrote:
> Just to be clear, this affects the credits that show up after clicking the
> "About" button in the lower-right corner of the start screen. To fix it, the
> file data/CREDITS needs to be changed.
>
> On Monday, December 12, 2016 9:39:30 PM EST Legimet wrote:
>> Package: supertuxkart
>> Severity: normal
>>
>> In the credits (data/CREDITS), the Boom-boom-boom song should be
>> credited to its author, Keith Baylis aka Vim, rather than Matt Thomas.

diff recognizes data/CREDITS as a binary file instead of a plain-text
ASCII file or similar; I can't generate a quilt patch to fix this. The
only way to fix this bug right now would be to repack the orig tarball
yet again, which I would rather not do. Given that this has already
been fixed upstream [1], I'm inclined to just wait for a new upstream
release instead.

Regards,
Vincent

[1] 
https://github.com/supertuxkart/stk-code/commit/ee17928382876226a0082d60458c6eb40e643d80

Bug#836885: Re-add heimdal-multidev?

[Ryan Tandy]

On Sun, Dec 25, 2016 at 09:05:15PM +0100, Michael Fladischer wrote:

Now that heimdal has some upstream activity again and 7.1.0 has been
uploaded to unstable, is there a chance that openldap will reenable
support for "krb5" in "olcSmbK5PwdEnable"?


Restored in git, and opened an RFS. #849986.

Bug#844081: Reproducer

[Christian Geier]

I'll backport those changes onto the 0.8 branch tomorrow. I'll send another 
email when it's done. 

Am 2. Januar 2017 22:48:21 MEZ, schrieb Filip Pytloun :
>Hello,
>
>I checked the changes and as they are done on top of huge refactoring
>(introduce of vdir.py), backporting it back to 0.8.4 seems to be too
>risky so I will workaround this occasional FTBFS by marking the test as
>xfail to avoid autoremoval from stretch.
>
>If we want to fix this issue correctly back in stretch after it's is
>stable, it's possible to do upload of new minor version.
>
>Filip
>
>On 2016/12/19 19:06, Christian Geier wrote:
>> Hi,
>> I could reproduce the issue and have fixed it, see the PR on github
>[1].
>> Depending on how urgent this is, you can either just take the
>os.sync()
>> commit and apply that to the version currently in Debian (which,
>while
>> brute force, certainly fixes this problem), or you might want to wait
>if
>> we find a more elegant solution.
>> 
>> Christian
>> 
>> [1] https://github.com/pimutils/khal/pull/543
>> 
>> Quoting Filip Pytloun (2016-12-11 13:16:56)
>> > Hello,
>> > 
>> > unfortunately I have no longer access to environment where this was
>> > happening. But if you were able to reproduce the issue and this
>fixed it
>> > for you, I'll apply it and make new release.
>> > 
>> > Anyway wouldn't it better to ensure data is written to disk
>directly
>> > during db updates and other operations? Eg. use O_SYNC for safety
>as
>> > these operations doesn't happen so often.
>> > 
>> > Filip
>> > 
>> > On 2016/12/11 01:14, Christian Geier wrote:
>> > > Hi Filip,
>> > > could you perhaps try to change all those sleep()s to
>`os.sync()`? For
>> > > me it seems to fix the issue.
>> > > 
>> > > See [0] for a patch.
>> > > 
>> > > If this doesn fix the issue, we obviously need to move the sync
>call out
>> > > of the tests and into the db update.
>> > > 
>> > > Best regards,
>> > > Christian
>> > > 
>> > > [0]
>https://github.com/pimutils/khal/commit/0b636f7633e86b9e136b06e9965cd3af0e3918f2
>> > > 

-- 
Sent from my phone. Please excuse my brevity.

Bug#822604: scanmem: depends on gksu which is deprecated

[Vincent Bernat]

 ❦  2 janvier 2017 21:49 +0100, Sebastian Parschauer  :

> It is intended and requested upstream to provide a separate libscanmem
> so that further tools can be built against it. We'll have to rework the
> public API any ways in v0.17. So I've dropped the separate libscanmem
> package for now to get the package uploaded faster. Lintian is still
> happy this way and the packages are working fine.

OK. In debian/control, ${python:Depends} already expands to python (>=
2.7), so you don't need to put it a second time (but that's really
nitpicking). Also, I just noticed that gameconqueror is "Architecture:
any" while it should be "Architecture: all" (there is nothing
architecture-dependant in it). In this case, you should also replace the
dependency on scanmem by:

 Depends: scanmem (>= ${source:Version}), scanmem (<< 
${source:Upstream-Version}.0~)

And the suggestion for gameconqueror by:

 Suggests: gameconqueror (= ${source:Version}

The reasons are explained here:
 https://wiki.debian.org/binNMU

I don't see any other problem. As per policy, there is a whole procedure
to take over a package. However, Lu and Kartik were in copy of your
intent to take over the package since April and didn't say a thing, I
suppose they are fine with it.
-- 
Program defensively.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Bug#844081: Reproducer

[Filip Pytloun]

Hello,

I checked the changes and as they are done on top of huge refactoring
(introduce of vdir.py), backporting it back to 0.8.4 seems to be too
risky so I will workaround this occasional FTBFS by marking the test as
xfail to avoid autoremoval from stretch.

If we want to fix this issue correctly back in stretch after it's is
stable, it's possible to do upload of new minor version.

Filip

On 2016/12/19 19:06, Christian Geier wrote:
> Hi,
> I could reproduce the issue and have fixed it, see the PR on github [1].
> Depending on how urgent this is, you can either just take the os.sync()
> commit and apply that to the version currently in Debian (which, while
> brute force, certainly fixes this problem), or you might want to wait if
> we find a more elegant solution.
> 
> Christian
> 
> [1] https://github.com/pimutils/khal/pull/543
> 
> Quoting Filip Pytloun (2016-12-11 13:16:56)
> > Hello,
> > 
> > unfortunately I have no longer access to environment where this was
> > happening. But if you were able to reproduce the issue and this fixed it
> > for you, I'll apply it and make new release.
> > 
> > Anyway wouldn't it better to ensure data is written to disk directly
> > during db updates and other operations? Eg. use O_SYNC for safety as
> > these operations doesn't happen so often.
> > 
> > Filip
> > 
> > On 2016/12/11 01:14, Christian Geier wrote:
> > > Hi Filip,
> > > could you perhaps try to change all those sleep()s to `os.sync()`? For
> > > me it seems to fix the issue.
> > > 
> > > See [0] for a patch.
> > > 
> > > If this doesn fix the issue, we obviously need to move the sync call out
> > > of the tests and into the db update.
> > > 
> > > Best regards,
> > > Christian
> > > 
> > > [0] 
> > > https://github.com/pimutils/khal/commit/0b636f7633e86b9e136b06e9965cd3af0e3918f2
> > > 


signature.asc
Description: Digital signature

Bug#849986: RFS: openldap/2.4.44+dfsg-3

[Ryan Tandy]

Package: sponsorship-requests
Severity: normal

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor to upload an updated openldap package.

Changes since the last upload:

  * Apply upstream patch to fix FTBFS on kFreeBSD. (Closes: #845394)
  * Restore heimdal support to the smbk5pwd overlay.

I am aware there is still a slight chance heimdal may not be released with
stretch. However, heimdal in unstable has all the RC bugs fixed, so it should
migrate as soon as #844357 in binutils is fixed and mips* are given back; and
I'd rather have to disable the dependency again after the freeze than risk
entering the freeze with the current crippled package.

The package can be obtained from:

https://pkg-openldap.alioth.debian.org/stretch/openldap_2.4.44+dfsg-3.dsc

The git history may be obtained from or browsed at:

https://anonscm.debian.org/git/pkg-openldap/openldap.git

The debdiff relative to 2.4.44+dfsg-2 is attached.

The test suite for openldap takes over an hour to run. You may want to 
build locally with DEB_BUILD_OPTIONS=nocheck and let the buildds take 
care of running the tests.

thanks,
Ryan
diff -Nru openldap-2.4.44+dfsg/debian/changelog openldap-2.4.44+dfsg/debian/changelog
--- openldap-2.4.44+dfsg/debian/changelog	2016-12-01 19:40:20.0 -0800
+++ openldap-2.4.44+dfsg/debian/changelog	2017-01-01 19:47:36.0 -0800
@@ -1,3 +1,10 @@
+openldap (2.4.44+dfsg-3) unstable; urgency=medium
+
+  * Apply upstream patch to fix FTBFS on kFreeBSD. (Closes: #845394)
+  * Restore heimdal support to the smbk5pwd overlay.
+
+ -- Ryan Tandy   Sun, 01 Jan 2017 19:47:36 -0800
+
 openldap (2.4.44+dfsg-2) unstable; urgency=medium
 
   [ Ryan Tandy ]
diff -Nru openldap-2.4.44+dfsg/debian/control openldap-2.4.44+dfsg/debian/control
--- openldap-2.4.44+dfsg/debian/control	2016-11-23 21:57:19.0 -0800
+++ openldap-2.4.44+dfsg/debian/control	2017-01-01 19:46:51.0 -0800
@@ -12,6 +12,7 @@
dh-autoreconf,
dpkg-dev (>= 1.17.14),
groff-base,
+   heimdal-multidev ,
libdb5.3-dev ,
libgnutls28-dev,
libltdl-dev ,
@@ -55,10 +56,11 @@
 Architecture: any
 Build-Profiles: 
 Depends: slapd (= ${binary:Version}), ${shlibs:Depends}, ${misc:Depends}
-Description: Keeps Samba passwords in sync within slapd.
- Extends the PasswordModify Extended Operation to update Samba password hashes
- for an LDAP user. The Samba support is written using the Samba 3.0 LDAP
- schema.
+Description: Keeps Samba and Kerberos passwords in sync within slapd.
+ Extends the PasswordModify Extended Operation to update Kerberos keys
+ and Samba password hashes for an LDAP user. The Kerberos support is
+ written for Heimdal using its hdb-ldap backend. The Samba support is
+ written using the Samba 3.0 LDAP schema.
 
 Package: ldap-utils
 Section: net
diff -Nru openldap-2.4.44+dfsg/debian/dh_installscripts-common openldap-2.4.44+dfsg/debian/dh_installscripts-common
--- openldap-2.4.44+dfsg/debian/dh_installscripts-common	2016-11-10 20:10:26.0 -0800
+++ openldap-2.4.44+dfsg/debian/dh_installscripts-common	2017-01-01 19:46:51.0 -0800
@@ -5,10 +5,9 @@
 
 init();
 
-my $scriptscommon = $ARGV[0];
-
 foreach my $package (@{$dh{DOPACKAGES}}) {
 	my $tmp=tmpdir($package);
+	my $ext=pkgext($package);
 
 	if (! -d "$tmp/DEBIAN") {
 		next;
@@ -16,10 +15,8 @@
 
 	foreach my $file (qw{postinst preinst prerm postrm config}) {
 		my $f="$tmp/DEBIAN/$file";
-		if (! -e $f) {
-			next;
+		if ($f) {
+			complex_doit("perl -pe 's~#SCRIPTSCOMMON#~qx{cat debian/${ext}scripts-common}~eg' -i $f");
 		}
-		print "changing $f with $scriptscommon\n";
-		complex_doit("perl -pe 's~#SCRIPTSCOMMON#~qx{cat $scriptscommon}~eg' -i $f");
 	}
 }
diff -Nru openldap-2.4.44+dfsg/debian/patches/ITS-8554-kFreeBSD-is-like-BSD.patch openldap-2.4.44+dfsg/debian/patches/ITS-8554-kFreeBSD-is-like-BSD.patch
--- openldap-2.4.44+dfsg/debian/patches/ITS-8554-kFreeBSD-is-like-BSD.patch	1969-12-31 16:00:00.0 -0800
+++ openldap-2.4.44+dfsg/debian/patches/ITS-8554-kFreeBSD-is-like-BSD.patch	2016-12-28 10:56:32.0 -0800
@@ -0,0 +1,26 @@
+From 74d64d0eb245ce07383abcd444c23e7438e8a083 Mon Sep 17 00:00:00 2001
+From: Howard Chu 
+Date: Wed, 28 Dec 2016 18:32:14 +
+Subject: [PATCH] ITS#8554 kFreeBSD is like BSD
+
+Doesn't have POSIX robust mutexes - GNU userland on BSD kernel
+---
+ libraries/liblmdb/mdb.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/libraries/liblmdb/mdb.c b/libraries/liblmdb/mdb.c
+index 7a181d4..23c1f00 100644
+--- a/libraries/liblmdb/mdb.c
 b/libraries/liblmdb/mdb.c
+@@ -120,7 +120,7 @@ typedef SSIZE_T	ssize_t;
+ #include 	/* defines BYTE_ORDER on HPUX and Solaris */
+ #endif
+ 
+-#if defined(__APPLE__) || defined (BSD)
++#if defined(__APPLE__) || defined (BSD) || defined(__FreeBSD_kernel__)
+ # define MDB_USE_POSIX_SEM	1
+ # define 

Bug#849893: libdigidoc: please add dependency “Suggests: libdigidoc-doc”

[Andrew Shadura]

On 2 January 2017 at 22:04, Ben Finney  wrote:
> On 02-Jan-2017, Andrew Shadura wrote:
>
>> Thanks for the suggestion, I will update the package.
>>
>> However, please be aware I'm not touching this package before the
>> release
>
> That's fine. This bug is of minor severity, it can be resolved among
> other more important problems.
>
>> as I believe it's not quite fit for the release, as it's only
>> one of the dependencies of a bigger set of packages, for packaging
>> which I don't have time right now, and as the upstream provides a
>> repository I think it's better to keep this package out of stable for
>> the time being.
>
> Then, please be aware this package is already in ‘testing’
>  which means it will enter
> ‘stable’ automatically.

It will not, it has an RC bug (it migrated to testing because of a BTS issue).

-- 
Cheers,
  Andrew

Bug#836330: package build failure: "No rule to make target"

[Russ Allbery]

"Robert J. Clay"  writes:

> There is an ITP [1] I've been working on, wherein Debian package build
> attempts just result in an error lke the following:

> make[1]: *** No rule to make target
> '/usr/lib/x86_64-linux-gnu/perl/5.20/Config.pm', needed by 'Makefile'.
> Stop.

> It comes up when attempting to use 'gbp buildpackage' or 'debuild' [2],
> under stretch, sid, or jessie.  It does not come up when doing a normal
> Perl module build ('perl Makefile.PL && make test', for instance).  It
> also does not come up attempting a Debian test build of another ITP I
> have.  (Can't finish that one because it's dependent on this one...)

Usually this means that you've accidentally included a generated Makefile
in the source package and are trying to use it, instead of running perl
Makefile.PL to regenerate the Makefile.  (And that generated Makefile was
generated with an older version of Perl, namely 5.20 instead of 5.24 which
is the current version in Debian unstable.)

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

Bug#848016: brltty-espeak: very monotonous speech and noticable delays in speech output

[Eric Scheibler]

Hello Samuel,

Samuel Thibault  schrieb am 02.01.2017, 20:56 +0100:
>Can you please test with the latest version libespeak-ng, 1.49.0+dfsg-3?

Same problem.

First I've updated espeak-ng, espeak-ng-data and libespeak-ng1 to version 
1.49.0+dfsg-3 (unstable).
Then I started brltty from the testing repository (version 5.4-4). The 
monotonous speech output and
delay are still there.

Secondly, I've installed libespeak-ng-dev and libespeak-ng-libespeak-dev from 
unstable (version
1.49.0+dfsg-3) and built brltty from the git master branch with espeak speech 
driver support. Same
result.

Lastly, I've removed libespeak-ng-dev and libespeak-ng-libespeak-dev and built 
brltty against
the old libespeak-dev library from testing (version 1.48.04+dfsg-5) again. This 
still works as
expected.

Eric

Bug#836330: package build failure: "No rule to make target"

[gregor herrmann]

On Mon, 02 Jan 2017 15:28:10 -0500, Robert J. Clay wrote:

> There is an ITP [1] I've been working on, wherein Debian package build
> attempts just result in an error lke the following:
> 
> make[1]: *** No rule to make target
> '/usr/lib/x86_64-linux-gnu/perl/5.20/Config.pm', needed by 'Makefile'.
> Stop.

Stray Makefile in the tarball?

(Downloading the tarball says "yes, there is a Makefile".)
 
> It comes up when attempting to use 'gbp buildpackage' or 'debuild' [2],
> under stretch, sid, or jessie.  It does not come up when doing a normal
> Perl module build ('perl Makefile.PL && make test', for instance).  

The former two call `debian/rules clean' which calls `make clean' as
there is a Makefile, which fails as it was created by `perl
Makefile.PL' on the authors machince with perl 5.20 installed.

In the latter case, your `perl Makefile.PL' rewrites the Makefile.

> It also
> does not come up attempting a Debian test build of another ITP I have.
> (Can't finish that one because it's dependent on this one...)

Luckily, these failures in `make dist' on the upstream side are quite
rare :)

Not sure what the quickest workaround is: Either putting Makefile in
debian/clean or re-running `perl Makefile.PL' in
override_dh_auto_clean if the Makefile is around [0] or repacking the
tarball.

Of course asking upstream to release a fixed tarball what benefit
everyone :)


Cheers,
gregor

[0]

libamazon-sqs-simple-perl/debian/rules does the
override_dh_auto_clean dance with a comment:

override_dh_auto_clean:
# recreate Makefile if it exists. path from the author's MacOS are not
# helpful for us
[ ! -f Makefile ] || perl Makefile.PL
dh_auto_clean


-- 
 .''`.  https://info.comodo.priv.at/ - Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   NP: Funny van Dannen: Emotionen Pause machen


signature.asc
Description: Digital Signature

Bug#849980: qt3d5-dev: please add dependency “Suggests” for documentation

[Lisandro Damián Nicanor Pérez Meyer]

tag 849980 pending
thanks

On martes, 3 de enero de 2017 06:54:08 ART Ben Finney wrote:
> Source: qt3d-opensource-src
> Version: 5.7.1+dfsg-1
> Severity: minor
> 
> Dear Maintainer,
> 
> Working with the ‘qt3d’ packages requires understanding how it works
> and what it does.
> 
> Please set a “Suggests: qt3d5-doc” and “Suggests: qt3d5-doc-html”
> dependency to the binary package ‘qt3d5-dev’, or other binary packages
> for which it is appropriate.

I find it just right so I have just commited the changes into our repo. I will 
probably not push a new version of qt3d just for this though.

Thanks, Lisandro.

-- 
20:16 < Gerardo_Cabero> che me tengo que ir volando .. sino me matan..
esto de tener novia es tan complicacdo como instalar paketes sin internet

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


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

Bug#849893: libdigidoc: please add dependency “Suggests: libdigidoc-doc”

[Ben Finney]

On 02-Jan-2017, Andrew Shadura wrote:

> Thanks for the suggestion, I will update the package.
> 
> However, please be aware I'm not touching this package before the
> release

That's fine. This bug is of minor severity, it can be resolved among
other more important problems.

> as I believe it's not quite fit for the release, as it's only
> one of the dependencies of a bigger set of packages, for packaging
> which I don't have time right now, and as the upstream provides a
> repository I think it's better to keep this package out of stable for
> the time being.

Then, please be aware this package is already in ‘testing’
 which means it will enter
‘stable’ automatically.

-- 
 \“A learning experience is one of those things that say, “You |
  `\know that thing you just did? Don't do that.”” —Douglas Adams, |
_o__)   2000-04-05 |
Ben Finney 


signature.asc
Description: PGP signature

Bug#849342: [xrdp] xrdp-sesman: Fails to start Xorg

[Ben Armstrong]

I do indeed (or did)! Purging it fixes the issue. Thanks for all of your
help. I believe you can close this now, though it may be helpful to point
users at potential issues with xserver-xorg-legacy in the README.Debian
unless you work out a fix for that.

I'm happy to report the MS Android client connects fine (xrdp 0.9.1-2),
which was what I was hoping for.

Ben

On Mon, Jan 2, 2017 at 4:35 PM, Dominik George  wrote:

> Hi,
>
> > Oh, I just needed "exec 2> .local/share/xorg/xorg.err.log" in the
> already
> > present /usr/bin/Xorg wrapper. OK. So now I get:
> >
> > synrg@lear:~$ cat .local/share/xorg/xorg.err.log
> > /usr/lib/xorg/Xorg.wrap: Only console users are allowed to run the X
> server
>
> This looks like you have xserver-xorg-legacy installed.
>
> Do you need it? If not, remove it.
>
> If you need it, then something tells me that it needs Xorg suid root…
>
> I think the issue is somewhere in between there and it manifested itself
> after authentication on the X server was re-enabled.
>
> -nik
>
> --
> PGP-Fingerprint: 3C9D 54A4 7575 C026 FB17  FD26 B79A 3C16 A0C4 F296
>
> Dominik George · Hundeshagenstr. 26 · 53225 Bonn
> Mobile: +49-1520-1981389 · https://www.dominik-george.de/
>
> Teckids e.V. · FrOSCon e.V.
> Fellowship of the FSFE · Piratenpartei Deutschland
> Opencaching Deutschland e.V. · Debian Maintainer
>
> LPIC-3 Linux Enterprise Professional (Security)
>

Bug#849891: gmt-doc: please add dependency “Recommends: gmt-tutorial”

[Ben Finney]

On 02-Jan-2017, Sebastiaan Couwenberg wrote:

> The gmt-tutorial package is not maintained and needs to be removed
> from Debian.

I see that bug#849910 requested this, and the package is now removed
. Thanks.

-- 
 \ “People's Front To Reunite Gondwanaland: Stop the Laurasian |
  `\  Separatist Movement!” —wiredog, http://kuro5hin.org/ |
_o__)  |
Ben Finney 


signature.asc
Description: PGP signature

Bug#849274: dbconfig-common: [INTL:pt] Updated Portuguese translation for debconf messages

[Paul Gevers]

Control: tags -1 moreinfo

Hi Miguel,

Thanks for bug report, but the file that you attached didn't contain any
update of the translation with respect to the old one and has lots of
strings still untranslated. Did you send the wrong file?

Paul



signature.asc
Description: OpenPGP digital signature

Bug#849985: libahven5-dev: /usr/lib/ada/adalib/ahven/ahven.ali is obsolete and read-only

[Nicolas Boulenguez]

Package: libahven5-dev
Version: 2.6-1.1
Severity: normal
Control: affects -1 libalog

Hello.

Build-time tests for libalog-0.5.2-2 fail on some architectures with
the following message.

  error: ("/usr/lib/ada/adalib/ahven/ahven.ali" is obsolete and read-only)
  error: "ahven-framework.adb" must be compiled

An easy work-around would disable the ALOG tests, but it would be
better to understand why the ALI files from libahven*-dev are older
the sources from the same package, and fix the problem there.

Bug#822604: scanmem: depends on gksu which is deprecated

[Sebastian Parschauer]

On 02.01.2017 12:04, Vincent Bernat wrote:
>  ❦  2 janvier 2017 11:10 +0100, Sebastian Parschauer  :
>> See:
>> https://github.com/sriemer/scanmem-debian/blob/source/scanmem_0.16-1.dsc
> 
> This is not very convenient since I cannot use dget on this URL. But, I
> have downloaded the source code successfully nonetheless. I am dropping
> debian-release@ but keeping Emilio since he did a review before.

Thank you very much for downloading and reviewing! I've implemented the
requested changes and updated the source branch.

Please use the following to get the reworked source:

dget
https://raw.githubusercontent.com/sriemer/scanmem-debian/source/scanmem_0.16-1.dsc

Please provide feedback if you're fine with it now. TIA

>  - d/control: don't depends on libc6-dev, this is part of
>build-essential
>  - d/control: short descriptions should be something like:
> 
>  locate and modify a variable in a running process (library)
>  locate and modify a variable in a running process (development)
>  locate and modify a variable in a running process
> 
>  - d/control: a "This package contains the development files" should be
>appended to the long description for libscanmem-dev
>  - d/control: a library should not suggest its dependencies
>  - d/dirs: empty, remove it
>  - d/docs: README is automatically added, if TODO is not interesting for
>end-users, you may consider to remove the whole file (but you are
>free to keep it)

Okay, I've removed both files.

>  - d/libscanmem-dev.install: except if you have some users for that,
>remove the .a.
>  - d/changelog: don't use urgency=high (this is for security updates),
>keep urgency=low or urgency=medium (there is currently no difference
>between them)
>  - d/copyright: the rule is last match wins, so you need to put the
>"Files: *" section first

I've implemented everything like requested and I've added a trivial
upstream patch to fix an icon (replaced deprecated 'gtk-jump-to' with
'go-jump').

> Overall, I don't think that Emilio asked for a separate package for
> libscanmem1. Since this is a private library, this can be kept in the
> scanmem package. The only drawback would be that people using
> gameconqueror will have to also install scanmem to get the lib. I don't
> think you get a Lintian warning when doing that (since the library is
> not installed in /usr/lib directly). But, it's up to you. Note that with
> the two new binary packages, the upload will take some time since it
> will be blocked in the NEW queue (expect at least a 1-week delay).

It is intended and requested upstream to provide a separate libscanmem
so that further tools can be built against it. We'll have to rework the
public API any ways in v0.17. So I've dropped the separate libscanmem
package for now to get the package uploaded faster. Lintian is still
happy this way and the packages are working fine.

Cheers,
Sebastian

Bug#849984: xserver-xorg-video-nouveau: Kernel 4.8.0-2 start with black screen on NVidia ION

[Sven Joachim]

Control: reassign -1 src:linux 4.8.11-1
Control: severity -1 important

On 2017-01-02 21:17 +0100, Torben Schou Jensen wrote:

> Package: xserver-xorg-video-nouveau
> Version: 1:1.0.13-1+b1
> Severity: critical
> Justification: breaks the whole system
>
> Dear Maintainer,
>
> *** Reporter, please consider answering these questions, where appropriate
> ***
>
>* What led up to the situation?
> Computer here is setup with Debian Testing and was updated with latest
> updates.
> Booting with latest kernel, 4.8.0-2, then result in black screen.
> In end of boot kernel drop connection to monitor.
> Not even a command prompt is available, and only hard reboot is way forward.
> Same problem on kernel 4.8.0-1.

This is a kernel problem then, no way for the xserver-xorg-video-nouveau
package to do anything about it.

> But everything work fine on kernel 4.7.0-1.
>
> In SYSLOG I see the following messages on a failed 4.8.0-2 boot.
>
> nouveau :01:00.0: bus: MMIO write of 8015 FAULT at 61a804
> nouveau :01:00.0: bus: MMIO read of  FAULT at 61a804
> nouveau :01:00.0: bus: MMIO read of 0010 FAULT at 64
> nouveau :01:00.0: bus: MMIO read of 0001 FAULT at 64
> nouveau :01:00.0: bus: MMIO read of 0010 FAULT at 64
> nouveau :01:00.0: bus: MMIO write of 0014 FAULT at 64
>
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
>
> If I boot on kernel 4.7.0-1 everything work fine and I have full display
> on my my monitor (PHILIPS 273V5HSB 1920 x
> 1080).
> If I boot on kernel 4.8.0-2 with kernel parameter "nomodeset" it start
> fine, but then Debian only use VESA in X.
>
>* What was the outcome of this action?
>
> With "nomodeset" system start fine, but NVidia card is not used as expected.
> Until further I can use kernel 4.7.0-1.
>
>* What outcome did you expect instead?
>
> I expect kernel to set modes correct so nouveau driver can start correct
> on kernel 4.8.
>
> *** End of the template - remove these template lines ***
>
>
> -- Package-specific info:
> X server symlink status:
> 
> lrwxrwxrwx 1 root root 13 Feb 17  2015 /etc/X11/X -> /usr/bin/Xorg
> -rwxr-xr-x 1 root root 274 Dec 16 19:39 /usr/bin/Xorg
>
> VGA-compatible devices on PCI bus:
> --
> 01:00.0 VGA compatible controller [0300]: NVIDIA Corporation ION VGA
> [10de:087d] (rev b1)
>
> /etc/X11/xorg.conf does not exist.
>
> /etc/X11/xorg.conf.d does not exist.
>
> /etc/modprobe.d contains no KMS configuration files.
>
> Kernel version (/proc/version):
> ---
> Linux version 4.8.0-2-686-pae (debian-ker...@lists.debian.org) (gcc
> version 5.4.1 20161019 (Debian 5.4.1-3) ) #1 SMP Debian 4.8.11-1
> (2016-12-02)
>
> Xorg X server log files on system:
> --
> -rw-r--r-- 1 root root 71875 Jan  2 20:39 /var/log/Xorg.0.log
>
> Contents of most recent Xorg X server log file (/var/log/Xorg.0.log):
> -
> [   508.572]
> X.Org X Server 1.19.0
> Release Date: 2016-11-15
> [   508.573] X Protocol Version 11, Revision 0
> [   508.573] Build Operating System: Linux 3.16.0-4-amd64 i686 Debian
> [   508.573] Current Operating System: Linux asrock 4.8.0-2-686-pae #1 SMP
> Debian 4.8.11-1 (2016-12-02) i686
> [   508.574] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-4.8.0-2-686-pae
> root=UUID=ce862291-20d7-4312-9e8b-33cef86c57dd ro acpi=force nomodeset
> [   508.574] Build Date: 16 December 2016  07:33:27PM
> [   508.574] xorg-server 2:1.19.0-3 (https://www.debian.org/support)
> [   508.575] Current version of pixman: 0.34.0
> [   508.575]  Before reporting problems, check http://wiki.x.org
>   to make sure that you have the latest version.
> [   508.575] Markers: (--) probed, (**) from config file, (==) default
> setting,
>   (++) from command line, (!!) notice, (II) informational,
>   (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
> [   508.577] (==) Log file: "/var/log/Xorg.0.log", Time: Mon Jan  2
> 20:39:49 2017
> [   508.601] (==) Using system config directory "/usr/share/X11/xorg.conf.d"
> [   508.659] (==) No Layout section.  Using the first Screen section.
> [   508.659] (==) No screen section available. Using defaults.
> [   508.659] (**) |-->Screen "Default Screen Section" (0)
> [   508.659] (**) |   |-->Monitor ""
> [   508.675] (==) No monitor specified for screen "Default Screen Section".
>   Using a default monitor configuration.
> [   508.675] (==) Automatically adding devices
> [   508.675] (==) Automatically enabling devices
> [   508.675] (==) Automatically adding GPU devices
> [   508.675] (==) Max clients allowed: 256, resource mask: 0x1f
> [   508.718] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not
> exist.
> [   508.718]  Entry deleted from font path.
> [   508.722] (==) FontPath set to:
>   /usr/share/fonts/X11/misc,
>

Bug#837895: lightdm-gtk-greeter: GUI does not run, black screen, on startup

[Michal Sojka]

Hi all,

I'm still having this problem with current sid. When I added
"active-monitor=0" to /etc/lightdm/lightdm-gtk-greeter.conf, as
suggested in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=785055,
the problem disappeared.

-Michal

Bug#849984: Xorg log

[Torben Schou Jensen]

Here Xorg logs from working 4.7.0-1 and failing 4.8.0-2.

-- 
Torben Schou Jensen
[42.510] 
X.Org X Server 1.19.0
Release Date: 2016-11-15
[42.511] X Protocol Version 11, Revision 0
[42.511] Build Operating System: Linux 3.16.0-4-amd64 i686 Debian
[42.511] Current Operating System: Linux asrock 4.7.0-1-686-pae #1 SMP Debian 4.7.8-1 (2016-10-19) i686
[42.511] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-4.7.0-1-686-pae root=UUID=ce862291-20d7-4312-9e8b-33cef86c57dd ro acpi=force
[42.511] Build Date: 23 November 2016  07:24:59PM
[42.511] xorg-server 2:1.19.0-2 (https://www.debian.org/support) 
[42.511] Current version of pixman: 0.34.0
[42.511] 	Before reporting problems, check http://wiki.x.org
	to make sure that you have the latest version.
[42.511] Markers: (--) probed, (**) from config file, (==) default setting,
	(++) from command line, (!!) notice, (II) informational,
	(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[42.512] (==) Log file: "/var/log/Xorg.0.log", Time: Thu Dec 29 20:33:52 2016
[42.975] (==) Using system config directory "/usr/share/X11/xorg.conf.d"
[43.243] (==) No Layout section.  Using the first Screen section.
[43.243] (==) No screen section available. Using defaults.
[43.243] (**) |-->Screen "Default Screen Section" (0)
[43.243] (**) |   |-->Monitor ""
[43.337] (==) No monitor specified for screen "Default Screen Section".
	Using a default monitor configuration.
[43.337] (==) Automatically adding devices
[43.337] (==) Automatically enabling devices
[43.337] (==) Automatically adding GPU devices
[43.337] (==) Max clients allowed: 256, resource mask: 0x1f
[43.492] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist.
[43.492] 	Entry deleted from font path.
[43.710] (==) FontPath set to:
	/usr/share/fonts/X11/misc,
	/usr/share/fonts/X11/100dpi/:unscaled,
	/usr/share/fonts/X11/75dpi/:unscaled,
	/usr/share/fonts/X11/Type1,
	/usr/share/fonts/X11/100dpi,
	/usr/share/fonts/X11/75dpi,
	built-ins
[43.710] (==) ModulePath set to "/usr/lib/xorg/modules"
[43.710] (II) The server relies on udev to provide the list of input devices.
	If no devices become available, reconfigure udev or disable AutoAddDevices.
[43.804] (II) Loader magic: 0x8028a720
[43.804] (II) Module ABI versions:
[43.804] 	X.Org ANSI C Emulation: 0.4
[43.804] 	X.Org Video Driver: 23.0
[43.804] 	X.Org XInput driver : 24.1
[43.804] 	X.Org Server Extension : 10.0
[43.806] (++) using VT number 7

[43.806] (II) systemd-logind: logind integration requires -keeptty and -keeptty was not provided, disabling logind integration
[43.808] (II) xfree86: Adding drm device (/dev/dri/card0)
[43.812] (--) PCI:*(0:1:0:0) 10de:087d:1849:087d rev 177, Mem @ 0xfb00/16777216, 0xe000/268435456, 0xf800/33554432, I/O @ 0xec00/128, BIOS @ 0x/131072
[43.840] (II) LoadModule: "glx"
[43.875] (II) Loading /usr/lib/xorg/modules/extensions/libglx.so
[44.840] (II) Module glx: vendor="X.Org Foundation"
[44.840] 	compiled for 1.19.0, module version = 1.0.0
[44.840] 	ABI class: X.Org Server Extension, version 10.0
[44.841] (==) Matched nouveau as autoconfigured driver 0
[44.841] (==) Matched nv as autoconfigured driver 1
[44.841] (==) Matched nouveau as autoconfigured driver 2
[44.841] (==) Matched nv as autoconfigured driver 3
[44.841] (==) Matched modesetting as autoconfigured driver 4
[44.841] (==) Matched fbdev as autoconfigured driver 5
[44.841] (==) Matched vesa as autoconfigured driver 6
[44.841] (==) Assigned the driver to the xf86ConfigLayout
[44.841] (II) LoadModule: "nouveau"
[44.841] (II) Loading /usr/lib/xorg/modules/drivers/nouveau_drv.so
[44.948] (II) Module nouveau: vendor="X.Org Foundation"
[44.948] 	compiled for 1.19.0, module version = 1.0.13
[44.948] 	Module class: X.Org Video Driver
[44.948] 	ABI class: X.Org Video Driver, version 23.0
[44.948] (II) LoadModule: "nv"
[44.949] (WW) Warning, couldn't open module nv
[44.949] (II) UnloadModule: "nv"
[44.949] (II) Unloading nv
[44.950] (EE) Failed to load module "nv" (module does not exist, 0)
[44.950] (II) LoadModule: "modesetting"
[44.950] (II) Loading /usr/lib/xorg/modules/drivers/modesetting_drv.so
[44.983] (II) Module modesetting: vendor="X.Org Foundation"
[44.983] 	compiled for 1.19.0, module version = 1.19.0
[44.983] 	Module class: X.Org Video Driver
[44.983] 	ABI class: X.Org Video Driver, version 23.0
[44.984] (II) LoadModule: "fbdev"
[44.984] (II) Loading /usr/lib/xorg/modules/drivers/fbdev_drv.so
[44.999] (II) Module fbdev: vendor="X.Org Foundation"
[44.999] 	compiled for 1.19.0, module version = 0.4.4
[44.999] 	Module class: X.Org Video Driver
[44.999] 	ABI class: X.Org Video Driver, version 23.0
[44.999] (II) LoadModule: "vesa"
[44.999] (II) 

Bug#849323: [Pkg-nagios-devel] Bug#849323: icinga: FTBFS with -Wl, -Bsymbolic-functions

[Sebastiaan Couwenberg]

On 01/02/2017 10:11 AM, Markus Frosch wrote:
> I'm no expert on C, but I think -fPIE -pie is just the wrong method for a 
> module, in our case, we are using symbols of the main process,
> which is loading the module. So no linking can occur.
> 
> We have to discuss how to fix it properly.

For now I think we should just not use PIE on Ubuntu, e.g. using the
attached path.

Kind Regards,

Bas


0001-Disable-PIE-on-Ubuntu-and-derivatives-causes-FTBFS.patch
Description: inode/symlink