Bug#830313: watch: segfaults with --color

[Craig Small]

I messed up the manual patch when it wouldn't apply. I put the return
before the attrset() That'll do it!

 - Craig


On Sat, Jul 9, 2016 at 3:38 PM Craig Small  wrote:

> there seems to be a problem, watch is now not interpreting any ansi
> sequences.
> im bisecting it now to work out what went wrong, one of the patches didnt
> apply cleanly so i suspect that one.
>
>
> On Sat, Jul 9, 2016 at 3:12 PM Josh Triplett 
> wrote:
>
>> On Sat, Jul 09, 2016 at 04:59:07AM +, Craig Small wrote:
>> > Hi Josh,
>> >   Thanks for looking into this, I only do some simple use of watch so
>> don't
>> > see the problems. I agree, if it doesn't understand something then stop
>> > messing around and drop out.
>> >
>> > Patch 0001 was already fixed upstream commit 6fcb6900 has a similar fix
>> > The other three patches have been applied upstream.
>>
>> Thanks!
>>
>> It looks like the handling for \e[m still has a bug in it, as it has a
>> condition for that both before and after the loop.  The one after the
>> loop looks wrong; I think the one before the loop is the only one that
>> makes sense.
>>
>> - Josh Triplett
>>
>

Bug#830313: watch: segfaults with --color

[Craig Small]

there seems to be a problem, watch is now not interpreting any ansi
sequences.
im bisecting it now to work out what went wrong, one of the patches didnt
apply cleanly so i suspect that one.


On Sat, Jul 9, 2016 at 3:12 PM Josh Triplett  wrote:

> On Sat, Jul 09, 2016 at 04:59:07AM +, Craig Small wrote:
> > Hi Josh,
> >   Thanks for looking into this, I only do some simple use of watch so
> don't
> > see the problems. I agree, if it doesn't understand something then stop
> > messing around and drop out.
> >
> > Patch 0001 was already fixed upstream commit 6fcb6900 has a similar fix
> > The other three patches have been applied upstream.
>
> Thanks!
>
> It looks like the handling for \e[m still has a bug in it, as it has a
> condition for that both before and after the loop.  The one after the
> loop looks wrong; I think the one before the loop is the only one that
> makes sense.
>
> - Josh Triplett
>

Bug#828785: uwsgi: FTBFS in testing (uwsgiconfig.py: Command not found)

[Jeremy Bicha]

Control: block -1 830529

cdbs did some python refactoring recently which broke a feature the
uwsgi build depended on. I've reported this to cdbs.

https://bugs.debian.org/830529

Thanks,
Jeremy Bicha

Bug#830529: cdbs: curpythonindepbinary variable no longer works

[Jeremy Bicha]

Package: cdbs
Version: 0.4.142
Severity: serious
Justification: causes other package to fail to build from source

The uwsgi package has this line [1] in its debian/rules:
clean::
$(cdbs_curpythonindepbinary) $(UWSGI_BUILDER) --clean

The result is this, as seen in a successful build log [2]:

 dh_clean
 python uwsgiconfig.py -v --clean

Sometime after June 8, according to Debian's reproducible builder [3]
[4], that line stopped working.

 dh_clean
 uwsgiconfig.py -v --clean
 make: uwsgiconfig.py: Command not found
 debian/rules:335: recipe for target 'clean' failed
 make: *** [clean] Error 127


[1] https://anonscm.debian.org/cgit/pkg-uwsgi/uwsgi.git/tree/debian/rules#n333
[2] 
https://buildd.debian.org/status/fetch.php?pkg=uwsgi=i386=2.0.12-7=1462704762
[3] 
https://tests.reproducible-builds.org/debian/rbuild/testing/amd64/uwsgi_2.0.12-7.rbuild.log
[4] Check test history at
https://tests.reproducible-builds.org/debian/rb-pkg/testing/amd64/uwsgi.html

Thanks,
Jeremy Bicha

Bug#830313: watch: segfaults with --color

[Josh Triplett]

On Sat, Jul 09, 2016 at 04:59:07AM +, Craig Small wrote:
> Hi Josh,
>   Thanks for looking into this, I only do some simple use of watch so don't
> see the problems. I agree, if it doesn't understand something then stop
> messing around and drop out.
> 
> Patch 0001 was already fixed upstream commit 6fcb6900 has a similar fix
> The other three patches have been applied upstream.

Thanks!

It looks like the handling for \e[m still has a bug in it, as it has a
condition for that both before and after the loop.  The one after the
loop looks wrong; I think the one before the loop is the only one that
makes sense.

- Josh Triplett

Bug#830313: watch: segfaults with --color

[Craig Small]

Hi Josh,
  Thanks for looking into this, I only do some simple use of watch so don't
see the problems. I agree, if it doesn't understand something then stop
messing around and drop out.

Patch 0001 was already fixed upstream commit 6fcb6900 has a similar fix
The other three patches have been applied upstream.

 - Craig

Bug#830522: xfce4-session: re-login fails with dbus connection error

[Fabian Picca]

Same here, exactly as described by Ben.


Kernel:  Linux 4.6.0-1-amd64 (x86_64)
Compiled:#1 SMP Debian 4.6.2-2 (2016-06-25)
Distribution:Debian GNU/Linux stretch/sid
Desktop Environment: XFCE 4


On Sat, 09 Jul 2016 09:33:21 +1200 Ben Caradoc-Davies 
wrote:
> Package: xfce4-session
> Version: 4.12.1-4
> Severity: normal
> 
> Dear Maintainer,
> 
> xfce4 login via lightdm succeeds, but after logout, logging in again fails 
> with
> first this dialog:
> 
> "Unable to contact settings server. Failed to connect socket /tmp/dbus-
> XX: connection refused."
> 
> and after pressing OK, the second dialog.
> 
> "Unable to load a failsafe session. Unable to determine failsafe session name.
> Possible causes: xfconfd isn't running (D-Bus setup problem); environment
> variable $XDG_CONFIG_DIRS is set incorrectly (must include "/etc"), or xfce-
> session is installed incorrectly."
> 
> Repeatable every time. Problem persists over reboots. Workaround is to 
> shutdown
> and restart. Using the default XDG_CONFIG_DIRS=/etc/xdg
> 
> I suspect recent dbus upgrades.
> 
> Kind regards,
> Ben.
> 
> 
> 
> -- System Information:
> Debian Release: stretch/sid
>   APT prefers unstable
>   APT policy: (500, 'unstable')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 4.6.0-1-amd64 (SMP w/4 CPU cores)
> Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> 
> Versions of packages xfce4-session depends on:
> ii  libatk1.0-02.20.0-1
> ii  libc6  2.23-1
> ii  libcairo2  1.14.6-1+b1
> ii  libdbus-1-31.10.8-1
> ii  libdbus-glib-1-2   0.106-1
> ii  libfontconfig1 2.11.0-6.4
> ii  libfreetype6   2.6.3-3+b1
> ii  libgdk-pixbuf2.0-0 2.34.0-1
> ii  libglib2.0-0   2.48.1-1
> ii  libgtk2.0-02.24.30-2
> ii  libice62:1.0.9-1+b1
> ii  libpango-1.0-0 1.40.1-1
> ii  libpangocairo-1.0-01.40.1-1
> ii  libpangoft2-1.0-0  1.40.1-1
> ii  libpolkit-gobject-1-0  0.105-15
> ii  libsm6 2:1.2.2-1+b1
> ii  libwnck22  2.30.7-5
> ii  libx11-6   2:1.6.3-1

Bug#830528: RFS: clutter-gesture/0.0.2.1-7.1 [NMU, RC] -- Open GL based interactive canvas library Gesture framework

[Sean Whitton]

Package: sponsorship-requests
Severity: important
Control: block 811585 by -1

Dear mentors,

I am looking for a sponsor for an NMU of clutter-gesture, fixing a stretch RC
bug (older than 7 days and no maintainer activity).

I have verified this NMU in the following ways:

- fixes the bug: builds with GCC 6
- builds in a current clean sid chroot (i.e. builds without gcc-6, too)

It currently fails piuparts due to a piuparts bug, #830527.

* Package name: clutter-gesture
  Version : 0.0.2.1-7.1
  Upstream Author : Intel Corp.
* URL : http://www.clutter-project.org/
* License : LGPL-2.1+
  Section : libs

Changes since the last upload:

  * Non-maintainer upload.
  * Add 09_fix_build_with_gcc_6.patch (Closes: #811585).

Download with dget:

dget -x 
http://mentors.debian.net/debian/pool/main/c/clutter-gesture/clutter-gesture_0.0.2.1-7.1.dsc

Thanks.

-- 
Sean Whitton

Bug#811585: clutter-gesture: diff for NMU version 0.0.2.1-7.1

[Sean Whitton]

Control: tags 811585 + patch

Dear maintainer,

I've prepared an NMU for clutter-gesture (versioned as 0.0.2.1-7.1) and
submitted a request for sponsorship to have it uploaded.

Regards.

-- 
Sean Whitton
diff -Nru clutter-gesture-0.0.2.1/debian/changelog clutter-gesture-0.0.2.1/debian/changelog
--- clutter-gesture-0.0.2.1/debian/changelog	2012-06-12 08:03:35.0 +
+++ clutter-gesture-0.0.2.1/debian/changelog	2016-07-09 03:03:16.0 +
@@ -1,3 +1,10 @@
+clutter-gesture (0.0.2.1-7.1) unstable; urgency=high
+
+  * Non-maintainer upload.
+  * Add 09_fix_build_with_gcc_6.patch (Closes: #811585).
+
+ -- Sean Whitton   Sat, 09 Jul 2016 12:03:13 +0900
+
 clutter-gesture (0.0.2.1-7) unstable; urgency=low
 
   * Add 08_remove_deprecated_g_mutex_new.patch (Closes: #674106)
diff -Nru clutter-gesture-0.0.2.1/debian/patches/09_fix_build_with_gcc_6.patch clutter-gesture-0.0.2.1/debian/patches/09_fix_build_with_gcc_6.patch
--- clutter-gesture-0.0.2.1/debian/patches/09_fix_build_with_gcc_6.patch	1970-01-01 00:00:00.0 +
+++ clutter-gesture-0.0.2.1/debian/patches/09_fix_build_with_gcc_6.patch	2016-07-09 02:39:02.0 +
@@ -0,0 +1,24 @@
+Description: clarify indentation to fix build with GCC 6
+Author: Sean Whitton 
+Forwarded: yes
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+--- a/clutter-gesture/clutter-gesture.c
 b/clutter-gesture/clutter-gesture.c
+@@ -715,7 +715,7 @@ clutter_gesture_set_hold_timeout (Clutte
+   if (set_hold_timeout (priv->gesture_handle, actor, interval) == 0)
+ return TRUE;
+ 
+-return FALSE;
++  return FALSE;
+ }
+ 
+ gboolean
+@@ -743,6 +743,6 @@ clutter_gesture_set_hold_radius (Clutter
+   if (set_hold_radius (priv->gesture_handle, actor, radius) == 0)
+ return TRUE;
+ 
+-return FALSE;
++  return FALSE;
+ }
+ 
diff -Nru clutter-gesture-0.0.2.1/debian/patches/series clutter-gesture-0.0.2.1/debian/patches/series
--- clutter-gesture-0.0.2.1/debian/patches/series	2012-06-12 04:56:00.0 +
+++ clutter-gesture-0.0.2.1/debian/patches/series	2016-07-09 02:30:43.0 +
@@ -6,3 +6,4 @@
 06_make-forward-compatible-with-new-clutter.patch
 07_remove_deprecated_g_thread_init.patch
 08_remove_deprecated_g_mutex_new.patch
+09_fix_build_with_gcc_6.patch

Bug#830527: piuparts should ignore /var/log/apt/eipp.log.xz in purge test

[Sean Whitton]

Package: piuparts
Version: 0.71
Severity: important

Dear maintainers,

piuparts considers package purge to have failed if the file
/var/log/apt/eipp.log.xz remains, e.g.:

2m6.4s ERROR: FAIL: Package purging left files on system:
  /var/log/apt/eipp.log.xz   not owned

2m6.4s ERROR: FAIL: Installation and purging test.

This file can be created by the latest version of apt, and it shouldn't
be considered a purge failure since it's unrelated to the package being
tested.

Thanks.

-- 
Sean Whitton

Bug#830526: ITP: golang-github-rogpeppe-fastuuid -- fast generation of 192-bit UUIDs

[Dmitry Smirnov]

Package: wnpp
Severity: wishlist
Owner: Dmitry Smirnov 
X-Debbugs-CC: debian-de...@lists.debian.org, 
pkg-go-maintain...@lists.alioth.debian.org
Control: block 829461 by -1

   Package name: golang-github-rogpeppe-fastuuid
Version: 0.0~git20150106
Upstream Author: Roger Peppe
License: BSD-3-Clause
URL: https://github.com/rogpeppe/fastuuid
Description: fast generation of 192-bit UUIDs
 Package fastuuid provides fast UUID generation of 192 bit universally
 unique identifiers. It does not provide formatting or parsing of
 the identifiers (it is assumed that a simple hexadecimal or base64
 representation is sufficient, for which adequate functionality exists
 elsewhere).


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

Bug#830525: ITP: golang-github-dghubble-sling -- HTTP client library for creating and sending API requests

[Dmitry Smirnov]

Package: wnpp
Severity: wishlist
Owner: Dmitry Smirnov 
X-Debbugs-CC: debian-de...@lists.debian.org, 
pkg-go-maintain...@lists.alioth.debian.org
Control: block 829461 by -1

   Package name: golang-github-dghubble-sling
Version: 1.0
Upstream Author: Dalton Hubble
License: Expat
URL: https://github.com/dghubble/sling
Description: HTTP client library for creating and sending API requests
 Sling is a Go HTTP client library for creating and sending API requests.


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

Bug#830524: debian-policy: Allow building only selected flavors

[Javier Serrano Polo]

Package: debian-policy
Version: 3.9.8.0
Severity: wishlist

Some source packages build more than one version of binaries using
different configuration options; these versions are called flavors. In
some cases, only a subset of flavors or components is needed, which is
translated into a subset of binary packages. Building only selected
flavors is useful for developers that try to fix bugs, and derivatives
whose patches are not merged in Debian.

A standard to express this flavor selection is desirable, like
DEB_BUILD_OPTIONS. For instance, I use DEB_BUILD_FLAVOURS="flavor1
flavor2". The following example packages use flavors; they are from
Squeeze, but I hope you get the idea:

Package: eglibc
Flavors: libc i686 xen amd64

Package: gcc-4.4
Flavors: base fixincl fortran libmudflap objc objcxx proto

Package: libsdl1.2
Flavors: all arts esd oss nas pulseaudio alsa udeb

Package: linux-2.6
Flavors: none_amd64 none_amd64-dbg openvz_amd64 openvz_amd64-dbg
vserver_amd64 vserver_amd64-dbg xen_amd64 xen_amd64-dbg headers
indep-doc indep-linux-base

Package: mesa
Flavors: dri glw glx other dri-i915 dri-i965 dri-mach64 dri-mga dri-r128
dri-r200 dri-r300 dri-r600 dri-radeon dri-savage dri-sis
dri-swrast dri-tdfx dri-unichrome


smime.p7s
Description: S/MIME cryptographic signature

Bug#829205: RFS: btrfs-progs/4.5.3-0.1

[Nicholas D Steeves]

Hi Dimitri!

On 8 July 2016 at 05:27, Dimitri John Ledkov  wrote:
> On 6 July 2016 at 11:17, Gianfranco Costamagna  
> wrote:
>> Hi,
>>>Have you coordinated with Dimitri?  When the regular maintainer is active,
>>
>>>NMUs are appropriate for urgent changes, not for regular work.  Ie, instead
>>>of random sponsors, I'd suggest letting him do uploads.
>>>
>>>As you've helped with this package before, perhaps it might be good to
>>>consider co-maintenance?
>>
>> he declined the offer!
>> he is in lowNMU threshold however :)
>>
>
> lowNMU is not meant for hostile takeovers of the package, ok?! =)

I am motivated towards collaboration, not hostile takeover, and I
truly believe that our development strategies are complementary.  I'd
also like to help triage and follow up on bugs.  Where you prefer
large periodic updates, I prefer small incremental updates, after
verifying that they are progressive rather than regressive.  This
verification is a mix of testing on a server, testing on a laptop, and
following linux-btrfs.  Furthermore, given the following I understood
understood that smaller, more atomic and easily reversible incremental
changes over time were preferred, because that would make it easier
for you to revert ones you didn't like:

Date: Sat, 23 Apr 2016 00:20:44 +0100
Message-ID: 
Subject: Re: Bug#818687: RFS: btrfs-progs/4.4.1-1.1 [NMU]
From: Dimitri John Ledkov 
To: Nicholas D Steeves 
Cc: Christian Seiler , 818...@bugs.debian.org,
Gianfranco Costamagna 

> I haven't looked closely, but i have a lot dubious emails about btrfs package.
> (a) i do not maintain backports, anybody is free to do those
> (b) all of my packages are lowNMU, meaning I trust any/all DDs to do
> sensible things
> (c) I do not trust any other developers, meaning that nobody should be
> granting DM and/or changing Uploaders/Maintainers fields etc
> (d) any other fixes is fine to be uploaded, and if things break I am
> on the hook to fix things up afterwards =)

Getting the copyright file into a better state, making uscan work
properly, adding crypto signature verification for tarballs, and
ensuring that the upstream changelog is correctly installed are all
sensible things, are they not?

>
> And I have accepted some patches from you, not all, and I did respond
> to you about that.

You wrote something similar in the following email, but I couldn't
find a record of those responses either:

Date: Tue, 31 May 2016 12:38:48 +0100
Message-ID: 
Subject: Re: Problem with btrfs-progs package
From: Dimitri John Ledkov 
To: Gianfranco Costamagna 
Cc: Uher Marek , Nicholas D Steeves
,
"debian-backpo...@lists.debian.org" 

> I have accepted some, but not all patches from him. I disagree with
> some of them, which i have clearly stated before =)

Please let me know where you clearly state your reasons for
disagreeing with some of my patches.  If you are taking the time to
reply then I don't want to waste your time by having not read your
replies!  I follow debian-backports, debian-boot, debian-cd,
debian-devel, debian-kernel, debian-mentors, debian-multimedia,
linux-btrfs, and of course any bugs that I open.

Sincerely,
Nicholas

Bug#829302: dh-golang: Respect "--parallel" and "--max-parallel" options

[Dmitry Smirnov]

On Friday, 8 July 2016 3:39:54 PM AEST Michael Hudson-Doyle wrote:
> I haven't tried it properly, but does this not limit the parallelism
> and slow builds by default?

Yes it does. Parallel build should be explicitly enabled by "--parallel"
passed to DH. I think we should make this change in order to make build 
system consistent.
Most packages would build marginally slower by default.
For few others it is not hard to add "--parallel" to "debian/rules".

Arguably ignoring parallel build options is a bug. dh-golang should have 
respected debhelper options from very beginning so I'm not too concerned 
about behaviour change. After all there will be a note in changelog about it 
and if you think it is not enough then we can even add a NEWS file.


> (I don't know how this works and
> apparently have not got around to reading up on it in the week since
> the bug was filed, so I'll ask a potentially silly question)

Debhelper takes care of parsing "--parallel" and "--max-parallel" so we just 
need to take value returned by "get_parallel()" and convert it into 
parameters to "go build" and to "go test" (I've forgotten to include similar 
change to "test()" function).

-- 
Best wishes,
 Dmitry Smirnov.

---

We often refuse to accept an idea merely because the way in which it has
been expressed is unsympathetic to us.
-- Friedrich Nietzsche


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

Bug#829205: RFS: btrfs-progs/4.5.3-0.1

[Nicholas D Steeves]

Hi Adam,

On 8 July 2016 at 08:58, Adam Borowski  wrote:
> Might be RC but certainly isn't urgent.  I don't see Nicholas pointing any
> of the upstream changes as immediately important (and I _do_ read
> linux-bt...@vger.kernel.org); debian/copyright changes are hardly ever
> time-sentitive too.

For 4.5.3, the only potentially urgent fix was for sparc, which is no
longer a 1st tier support arch.
http://www.spinics.net/lists/linux-btrfs/msg54831.html

I believe the following two fixes in 4.5.3 are probably normal
priority, and are definitely a positive and desirable direction.  Does
reducing the probability of a corner case causing a problem count as
important?:

https://github.com/kdave/btrfs-progs/commit/df2236d73bdffd69cf6d9aac7d80c880b4413aaa
https://github.com/kdave/btrfs-progs/commit/9988284574c1692e5181ecd6f8b9e2512b0503ae

> Especially that the proposed new contents of debian/copyright is, IMHO,
> containing far more inaccuracies than the old one did.

I consulted the xfsprogs and linux-src debian/copyrights.  Other than
the git repo already mentioned in the file, do you know of another
location that could be cited?  I've attached asubstantially simplified
copyright.  Would you please review it and offer critique?

I went for the following approach, similarly to xfsprogs and linux-src:
> * a blanket statement, listing maybe some major holders but with a stress on
>   "and others".

The rules I used to order it were 1) license, alphabetised 2) date  3)
exception for debian/* to put it near the end of GPL-2+  4) Removed
configure and autoconf stuff which was either "redistributable without
notice" or able to be relicensed under the GPL-2 glob.  Further
compaction of the GPL-2+ exceptions is probably possible.  Please let
me know!

Cheers,
Nicholas


copyright
Description: Binary data

Bug#830523: xserver-xorg-input-libinput: segfaults upon plugging back a USB keyboard when two X servers are running

[Frédéric Brière]

Package: xserver-xorg-input-libinput
Version: 0.19.0-1
Severity: normal

I normally have two X servers running, and have recently encountered
this bug: after unplugging and plugging back my USB keyboard (or, more
likely, turning off/on my monitor which acts as a USB hub), the latter
action will always trigger a segfault in one (seemling chosen at random)
of the two servers.

This does not occur if only one server is running.

Following is the relevant backtrace.  (The segfault itself occurs in
libinput proper, but I'm guessing that X is the real culprit.  My
apologies if I guessed incorrectly.)


Thread 1 "Xorg" received signal SIGSEGV, Segmentation fault.
libinput_device_config_tap_get_finger_count (device=0x0) at libinput.c:3124
3124libinput.c: No such file or directory.
#0  libinput_device_config_tap_get_finger_count (device=0x0) at libinput.c:3124
No locals.
#1  0x7fb6e4e8b953 in xf86libinput_parse_tap_option (device=0x0, 
pInfo=0x5619f01abcd0) at ../../src/xf86libinput.c:1687
tap = 
#2  xf86libinput_parse_options (device=0x0, driver_data=0x5619f01dc570, 
pInfo=0x5619f01abcd0) at ../../src/xf86libinput.c:2135
options = 0x5619f01dc5d0
#3  xf86libinput_pre_init (drv=, pInfo=0x5619f01abcd0, 
flags=) at ../../src/xf86libinput.c:2466
driver_data = 0x5619f01dc570
shared_device = 
libinput = 
device = 0x0
path = 
#4  0x5619eee20468 in xf86NewInputDevice (pInfo=0x5619f01abcd0, 
pdev=pdev@entry=0x7ffd87e2ea80, enable=) at 
../../../../hw/xfree86/common/xf86Xinput.c:900
drv = 0x5619f021fcb0
dev = 0x0
paused = 0
rval = 
path = 0x5619f01a9430 "libinput"
#5  0x5619eee213ee in NewInputDeviceRequest (options=, 
attrs=0x5619f02377a0, pdev=pdev@entry=0x7ffd87e2ea80) at 
../../../../hw/xfree86/common/xf86Xinput.c:1049
pInfo = 
option = 
rval = 
is_auto = 
#6  0x7fb6e4e8a5e7 in xf86libinput_hotplug_device (hotplug=0x5619f019d340) 
at ../../src/xf86libinput.c:2225
dev = 0x5619ef1d8ae0 
#7  0x7fb6e4e8a82c in xf86libinput_hotplug_device_cb (client=, closure=) at ../../src/xf86libinput.c:2242
hotplug = 
#8  0x5619eedd6aa1 in ProcessWorkQueue () at ../../dix/dixutils.c:526
q = 0x5619f02115c0
p = 0x5619ef1d1578 
#9  0x5619eef2cb7d in WaitForSomething 
(pClientsReady=pClientsReady@entry=0x5619f01df9b0) at ../../os/WaitFor.c:176
i = 
waittime = {tv_sec = 239, tv_usec = 795324}
wt = 0x7ffd87e2eb00
timeout = 
clientsReadable = {fds_bits = {0 }}
clientsWritable = {fds_bits = {0 }}
selecterr = 
nready = 0
devicesReadable = {fds_bits = {0 }}
now = 
someReady = 0
#10 0x5619eedd1a1e in Dispatch () at ../../dix/dispatch.c:359
clientReady = 0x5619f01df9b0
result = 
client = 
nready = 
icheck = 0x5619ef1d1250 
start_tick = 
#11 0x5619eedd5c03 in dix_main (argc=7, argv=0x7ffd87e2ef08, 
envp=) at ../../dix/main.c:300
i = 
alwaysCheckForInput = {0, 1}
#12 0x7fb6ef017730 in __libc_start_main (main=0x5619eedbff60 , 
argc=7, argv=0x7ffd87e2ef08, init=, fini=, 
rtld_fini=, stack_end=0x7ffd87e2eef8) at ../csu/libc-start.c:291
result = 
unwind_buf = {cancel_jmp_buf = {{jmp_buf = {0, 1283301603599398874, 
94669381566320, 140726883249920, 0, 0, 4758024621162969050, 
4796676548256806874}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x7, 
0x5619eedbff60 }, data = {prev = 0x0, cleanup = 0x0, canceltype = 7}}}
not_first_call = 
#13 0x5619eedbff99 in _start ()
No symbol table info available.


-- Package-specific info:
X server symlink status:

lrwxrwxrwx 1 root root 13 Dec 21  2010 /etc/X11/X -> /usr/bin/Xorg
-rwxr-xr-x 1 root root 274 Apr  5 03:05 /usr/bin/Xorg

VGA-compatible devices on PCI bus:
--
01:05.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. 
[AMD/ATI] RS880 [Radeon HD 4250] [1002:9715]

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

Contents of /etc/X11/xorg.conf.d:
-
total 4
-rw-r--r-- 1 root root 57 Sep  6  2015 debug.conf

KMS configuration files:

/etc/modprobe.d/radeon-kms.conf:
  options radeon modeset=1

Kernel version (/proc/version):
---
Linux version 4.6.0-1-amd64 (debian-ker...@lists.debian.org) (gcc version 5.4.0 
20160609 (Debian 5.4.0-6) ) #1 SMP Debian 4.6.3-1 (2016-07-04)

Xorg X server log files on system:
--
-rw-r--r-- 1 root root 44890 Jul  7 14:36 /var/log/Xorg.2.log
-rw-r--r-- 1 root root 45436 Jul  8 13:59 /var/log/Xorg.1.log
-rw-r--r-- 1 root root 87164 Jul  8 13:59 /var/log/Xorg.0.log

Contents of most recent Xorg X server log file (/var/log/Xorg.0.log):
-
[29.531] 
X.Org X Server 1.18.3

Bug#774445: bsdtar: can't add files with //multiple/leading/slashes

[Peter Pentchev]

control: tag -1 + confirmed upstream
control: forward -1 https://github.com/libarchive/libarchive/issues/740

Hi,

Thanks for taking a look at libarchive and bsdtar for your tests!

Well, I do understand your case, and I forwarded it to the upstream
GitHub issue tracker.  However, the fact remains that this behavior:

- has been with libarchive since pretty much the very beginning, or
  at least the moment when it was broken out of FreeBSD as a standalone
  project, and

- there are arguments in favor of the current behavior: in the common
  case multiple slashes are, at best, useless, and, at worst, harmful
  on, say, Windows with its //hostname/path network share syntax

So let's see what the upstream authors say; in the worst case we may
decide to carry this as a Debian-specific patch for the benefit of
compatibility with GNU tar, but, to be honest, I see a couple of
potential drawbacks with this approach, too; some might even mumble
something about "gratuitous differences in behavior" and "POLA
violations" when writing portable scripts using bsdtar :)

Still, thanks for reporting this and for doing the path traversal
tests at all!

G'luck,
Peter

-- 
Peter Pentchev  r...@ringlet.net r...@freebsd.org p...@storpool.com
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115  C354 651E EFB0 2527 DF13


signature.asc
Description: PGP signature

Bug#829692: RFS: libu2f-host/1.1.2-0.1 [NMU] -- library for Universal 2nd Factor

[Nicolas Braud-Santoni]

X-Debbugs-CC: codeh...@debian.org, jw...@debian.org, locutusofb...@debian.org

Hi,

Thanks everyone for the feedback and comments, especially the
explanations regarding symbol versionning.

Sorry for the time it took to reply in here, DebConf kept me
away from my inbox (though I got quite a lot of things done).


> what does this mean? do reverse-dependencies needs a rebuild then?

No, there was no ABI-incompatible change, and no soname change is
required.  However, future builds would pickup a dependency on
libu2f-host (>= 1.0) if I'm not mistaken.

This was done because codehelp (who initially reviewed my patch) told me
that the version 0.0 was not valid, and that I may use 1.0.

Interestingly, the previous .symbols file was probably not doing the
right thing, because it refered to libu2f-host instead of libu2f-host0,
and Lintian was complaining that the Debian version number was appearing
in those symbols.


> Uploading on deferred/1

Thanks for the subsequent fix, Gianfranco.
I included it in the Git history.


> No, ACKing a NMU is not a blanket permission to do further further
> NMUs. And if the maintainers were actually happy with any NMUs
> whatsoever, then they could put the package on the lowNMU list,
> or orphan the package.

For what it's worth, I asked to join the pkg-auth team to take care
of those specific packages, and suggested filing RFAs for the other
Yubico-related packages if upstream cannot maintain them.


Best,

  nicoo


signature.asc
Description: PGP signature

Bug#830522: xfce4-session: re-login fails with dbus connection error

[Ben Caradoc-Davies]

Package: xfce4-session
Version: 4.12.1-4
Severity: normal

Dear Maintainer,

xfce4 login via lightdm succeeds, but after logout, logging in again fails with
first this dialog:

"Unable to contact settings server. Failed to connect socket /tmp/dbus-
XX: connection refused."

and after pressing OK, the second dialog.

"Unable to load a failsafe session. Unable to determine failsafe session name.
Possible causes: xfconfd isn't running (D-Bus setup problem); environment
variable $XDG_CONFIG_DIRS is set incorrectly (must include "/etc"), or xfce-
session is installed incorrectly."

Repeatable every time. Problem persists over reboots. Workaround is to shutdown
and restart. Using the default XDG_CONFIG_DIRS=/etc/xdg

I suspect recent dbus upgrades.

Kind regards,
Ben.



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

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

Versions of packages xfce4-session depends on:
ii  libatk1.0-02.20.0-1
ii  libc6  2.23-1
ii  libcairo2  1.14.6-1+b1
ii  libdbus-1-31.10.8-1
ii  libdbus-glib-1-2   0.106-1
ii  libfontconfig1 2.11.0-6.4
ii  libfreetype6   2.6.3-3+b1
ii  libgdk-pixbuf2.0-0 2.34.0-1
ii  libglib2.0-0   2.48.1-1
ii  libgtk2.0-02.24.30-2
ii  libice62:1.0.9-1+b1
ii  libpango-1.0-0 1.40.1-1
ii  libpangocairo-1.0-01.40.1-1
ii  libpangoft2-1.0-0  1.40.1-1
ii  libpolkit-gobject-1-0  0.105-15
ii  libsm6 2:1.2.2-1+b1
ii  libwnck22  2.30.7-5
ii  libx11-6   2:1.6.3-1
ii  libxfce4ui-1-0 4.12.1-2
ii  libxfce4util7  4.12.1-2
ii  libxfconf-0-2  4.12.0-2+b1
ii  xfce4-settings 4.12.0-3
ii  xfconf 4.12.0-2+b1

Versions of packages xfce4-session recommends:
ii  dbus-x11   1.10.8-1
ii  libpam-systemd 230-7
ii  light-locker   1.7.0-3
ii  systemd-sysv   230-7
ii  upower 0.99.4-3
ii  x11-xserver-utils  7.7+7
ii  xfdesktop4 4.12.3-2
ii  xfwm4  4.12.3-2

Versions of packages xfce4-session suggests:
pn  fortunes-mod  
ii  pm-utils  1.4.1-16
ii  sudo  1.8.17p1-2

-- no debconf information

Bug#825845: mrpt: FTBFS on big-endian systems, with test suite errors

[JOSE LUIS BLANCO CLARACO]

> ok, rebased with current debian/unstable package and build good
>
> I did grab the package from unstable, added the commit above, and did a 
> complete build.
> It didn't fail on s390x, so I don't know how to trigger that failure.

Well, that's good news, I guess! Thank you for your time.

I have just cherry-picked some commits and applied them to 1.4.0-1
(current "unstable") to create 1.4.0-2 which should fix all FTBFS
bugs, hopefully...
The DSC is in [1]. This is my first debian package with patches (via
dquilt) but I think it's fine.

Perhaps you could consider sponsoring its upload to Debian so we can
close a few bugs and fix the package for big-endian platforms?

Best,
JL

[1] https://mentors.debian.net/debian/pool/main/m/mrpt/mrpt_1.4.0-2.dsc

Bug#749160: [src:libarchive] Sizes of common symbol buff2 differ

[Peter Pentchev]

Hi,

Thanks for trying to improve libarchive by reporting this!

Can you confirm that this bug has been fixed in libarchive-3.2.0-1
(or, rather, in 3.2.1-1 currently in testing and unstable)?
It was fixed as part of a Watcom C compiler portability fix in

  
https://github.com/libarchive/libarchive/commit/5395502c6a2e74727bb25e83384a5da0969b0f05

For the Jessie version of libarchive this may be fixed by a stable
proposed update.

Thanks again for reporting this!

G'luck,
Peter

-- 
Peter Pentchev  r...@ringlet.net r...@freebsd.org p...@storpool.com
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115  C354 651E EFB0 2527 DF13


signature.asc
Description: PGP signature

Bug#830236: RFS: libcork/0.15.0+ds-4 -- simple, easily embeddable, cross-platform C library

[Roger Shimizu]

On Fri, Jul 8, 2016 at 9:58 AM, Roger Shimizu  wrote:
> On Fri, Jul 8, 2016 at 9:54 AM, Gianfranco Costamagna
>  wrote:
>>>
>>
>>>Besides, it'd be appreciated if you also can setup DM upload
>>>permission of this package for me, after this upload.
>>>Thank you!
>>
>>
>> https://launchpadlibrarian.net/271663979/buildlog_ubuntu-yakkety-amd64.libcork_0.15.0+ds-4_BUILDING.txt.gz
>>
>>
>> the multiarch stuff is broken in yakkety now.
>
> Dear G,
>
> Thanks for your info!
> Sorry for the breakage.. I'll take a look later today.

Dear G,

Just applied your previous patch (partly): https://github.com/rogers0/libcork
It should work now.
Since you gave me the DM upload permision (Thanks so much!), I'll try
to upload after some more changes.

Cheers,
-- 
Roger Shimizu, GMT +2 Cape Town (in DebConf16)
PGP/GPG: 4096R/6C6ACD6417B3ACB1

Bug#778778: [libarchive13] Missing some files zip archive

[Peter Pentchev]

Hi,

Thanks for trying to improve libarchive by reporting this!

Could you confirm that this bug is fixed in libarchive-3.2.0-1
(or, rather, in 3.2.1-1 in testing and unstable now)?  It seems
that the ZIP archive in question uses some extensions that are
only supported upstream since libarchive-3.2.0 (well, there is
an intermediate 3.1.900 version, but for all Debian intents and
purposes, it's 3.2.0).

Unfortunately, the changes to support Zip64 and some other ZIP
format extensions were, well, quite extensive, so I don't think
that it would be possible to make a simple patch for a stable
proposed update.  Rather, if you confirm that the version in testing
and unstable works for you (it does for me), a backport might be
in order soon.

Thanks again for reporting this!

G'luck,
Peter

-- 
Peter Pentchev  r...@ringlet.net r...@freebsd.org p...@storpool.com
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115  C354 651E EFB0 2527 DF13


signature.asc
Description: PGP signature

Bug#830514: plasma-desktop: Missing context menu (right click) on plasma desktop and desktop widgets

[Diederik de Haas]

On vrijdag 8 juli 2016 22:08:17 CEST Krzysztof Marczak wrote:
> After latest upgrade there is missing context menu which should be shown
> after right mouse click on plasma desktop or on desktop widgets.

That's likely due to your mixture of 5.22.0-1 and 5.23.0-1 versions of various 
(framework) packages on your system.
The likely solution is to either get those from sid/unstable, wait till all 
those packages are at 5.23.0-1 or downgrade all back to 5.22.0-1


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

Bug#830519: [pkg-go] Bug#830519: docker-swarm: FTBFS: docker/swarm/api/flusher.go:8:2: cannot find package "github.com/docker/docker/pkg/ioutils"

[Tianon Gravi]

On 8 July 2016 at 14:29, Chris Lamb  wrote:
>   src/github.com/docker/swarm/api/flusher.go:8:2: cannot find package 
> "github.com/docker/docker/pkg/ioutils" in any of:

This sounds like another case of #830478, which should've been fixed
with src:docker.io 1.11.2~ds1-2 (uploaded this morning).


♥,
- Tianon
  4096R / B42F 6819 007F 00F8 8E36  4FD4 036A 9C25 BF35 7DD4

Bug#828819: intel-microcode: i7-6500U doesn't boot in 4/5 cases with 3.20160607.1

[Henrique de Moraes Holschuh]

Well, more information:

Report for the same issue on Fedora:
https://bugzilla.redhat.com/show_bug.cgi?id=1353103

All reports of this issue being "fixed" by a firmware update (in Debian,
Arch and Fedora) are for firmware updates that come with microcode 0x8a
already, effectively rendering the microcode update unecessary (which is
detected by the kernel, and the microcode update is *not* attempted).

There are no reports of issues on Skylake-U K-1 (the "somewhat fixed"
hardware stepping of Skylake-U, present on Core i3-61xxU / i5-62xxU /
i5-63xxU / i7-65xxU / i7-66xxU, where XX is *not* 00). These processors
report pf=0x40.  OTOH, we don't have reports of success for them,
either.

Status for the Skylake-U/Y D-1 Pentiums and Celerons is unknown, and I
cannot even find boot logs for any of those in the 'net.

Given what is known about this issue so far, I will upload a new version
of the intel-microcode package *removing* the update for signature
0x406e3 (for all pf combinations).  This change will be reverted when
Intel issues a new revision of the 0x406e3 microcode.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Bug#830521: nvme-cli: Fix regression in nvme-cli 32-bit compatibility

[Steve Langasek]

Package: nvme-cli
Version: 0.8-1
Severity: serious
Tags: patch
Justification: FTBFS
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu yakkety ubuntu-patch

Hi Breno,

After syncing nvme-cli 0.8-1 into Ubuntu yakkety, I noticed that it has
failed to build on all of our 32-bit architectures, with a common error:

  cc -Wdate-time -D_FORTIFY_SOURCE=2 -D_GNU_SOURCE -g -O2 -fPIE 
-fstack-protector-strong -Wformat -Werror=format-security -std=gnu99 -O2 -g 
-Wall -Werror -DLIBUDEV_EXISTS -DNVME_VERSION='"0.8"' -c intel-nvme.c
  intel-nvme.c: In function ‘get_internal_log’:
  intel-nvme.c:310:13: error: cast from pointer to integer of different size 
[-Werror=pointer-to-int-cast]
cmd.addr = (__u64)(void *)buf;
   ^
  cc1: all warnings being treated as errors
  Makefile:44: recipe for target 'intel-nvme.o' failed

I've applied the attached patch in Ubuntu to address this.  Please consider
applying this patch in Debian as well, and forward upstream as necessary.

Thanks,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru nvme-cli-0.8/debian/patches/32-bit-compatibility.patch nvme-cli-0.8/debian/patches/32-bit-compatibility.patch
--- nvme-cli-0.8/debian/patches/32-bit-compatibility.patch	1969-12-31 16:00:00.0 -0800
+++ nvme-cli-0.8/debian/patches/32-bit-compatibility.patch	2016-07-08 14:34:09.0 -0700
@@ -0,0 +1,28 @@
+Author: Steve Langasek 
+Description: Fix compatibility with 32-bit systems
+ nvme-cli is failing to build on 32-bit systems with this error:
+ cc -Wdate-time -D_FORTIFY_SOURCE=2 -D_GNU_SOURCE -g -O2 -fPIE -fstack-protector-strong -Wformat -Werror=format-security -std=gnu99 -O2 -g -Wall -Werror -DLIBUDEV_EXISTS -DNVME_VERSION='"0.8"' -c intel-nvme.c
+ intel-nvme.c: In function ‘get_internal_log’:
+ intel-nvme.c:310:13: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast]
+  cmd.addr = (__u64)(void *)buf;
+ ^
+ cc1: all warnings being treated as errors
+ .
+ cmd.addr is defined as __u64 on all architectures, but a pointer is not
+ always 64-bit, making this an error.  Cast to 'unsigned long' instead,
+ which is safe on all supported architectures, and let the compiler take it
+ from there.
+
+Index: nvme-cli-0.8/intel-nvme.c
+===
+--- nvme-cli-0.8.orig/intel-nvme.c
 nvme-cli-0.8/intel-nvme.c
+@@ -307,7 +307,7 @@
+ 	cmd.cdw10 = 0x400;
+ 	cmd.cdw12 = cfg.log;
+ 	cmd.data_len = 0x1000;
+-	cmd.addr = (__u64)(void *)buf;
++	cmd.addr = (unsigned long)(void *)buf;
+ 
+ 	memset(buf, 0, sizeof(buf));
+ 	err = nvme_submit_passthru(fd, NVME_IOCTL_ADMIN_CMD, );
diff -Nru nvme-cli-0.8/debian/patches/series nvme-cli-0.8/debian/patches/series
--- nvme-cli-0.8/debian/patches/series	2016-07-03 07:44:08.0 -0700
+++ nvme-cli-0.8/debian/patches/series	2016-07-08 14:16:36.0 -0700
@@ -1,2 +1,3 @@
 0001-Making-cast-explict.patch
 0002-Fix-bash-completion-directory.patch
+32-bit-compatibility.patch

Bug#830500: redis: FTBFS: Test failure

[Daniel Schepler]

On Fri, Jul 8, 2016 at 2:36 PM, Chris Lamb  wrote:
> Interesting. Can't seem to reproduce here in latest sid. Do you have limited 
> memory or something like that..? Concurrency..?

No, the machine has 8 GB of RAM.  I also don't recall the machine
being heavily loaded when I reran the test build to confirm.  The
first time, I used DEB_BUILD_OPTIONS="parallel=8" but the second time
I think I forgot to set that.
-- 
Daniel Schepler

Bug#830500: redis: FTBFS: Test failure

[Chris Lamb]

tags 830500 + unreproducible
thanks

Daniel Schepler wrote:

> [err]: Test replication partial resync: ok psync (diskless: yes,
> reconnect: 1) in tests/integration/replication-psync.tcl
> Expected condition '[s -1 sync_partial_ok] > 0' to be true ([s -1
> sync_partial_ok] > 0)

Interesting. Can't seem to reproduce here in latest sid. Do you have limited 
memory or something like that..? Concurrency..?


Regards,

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

Bug#830519: docker-swarm: FTBFS: docker/swarm/api/flusher.go:8:2: cannot find package "github.com/docker/docker/pkg/ioutils"

[Chris Lamb]

Source: docker-swarm
Version: 1.0.1+dfsg-1
Severity: serious
Justification: fails to build from source
User: reproducible-bui...@lists.alioth.debian.org
Usertags: ftbfs
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Dear Maintainer,

docker-swarm fails to build from source in unstable/amd64:

  [..]

  DISPLAY=:0
  DOCKER_IMAGE=lamby-debian-sid
  DEB_BUILD_OPTIONS=parallel=9
  PIP_DOWNLOAD_CACHE=/home/lamby/.cache/pip
  HOME=/home/lamby
  LOGNAME=lamby
  SHLVL=1
  
PWD=/home/lamby/temp/cdt.20160708232023.ZfB4qjivAe.docker-swarm/docker-swarm-1.0.1+dfsg
  OLDPWD=/home/lamby/temp/cdt.20160708232023.ZfB4qjivAe.docker-swarm
  GPG_TTY=/dev/console
  QUILT_PATCHES=debian/patches
  QUILT_NO_DIFF_INDEX=1
  QUILT_REFRESH_ARGS=-p ab --no-timestamps --no-index
  DEBEMAIL=la...@debian.org
  DEBFULLNAME=Chris Lamb
  EDITOR=vim
  LESS=-cgiFx4M
  BLASTER=A220 I5 D1 H5 P330 T6
  _=/usr/bin/env
  
  
**
  ** Building docker-swarm 1.0.1+dfsg-1 on amd64
  **
  
**
  
   dpkg-buildpackage -rfakeroot -D -us -uc -b
  dpkg-buildpackage: info: source package docker-swarm
  dpkg-buildpackage: info: source version 1.0.1+dfsg-1
  dpkg-buildpackage: info: source distribution unstable
  dpkg-buildpackage: info: source changed by Dmitry Smirnov 
   dpkg-source --before-build docker-swarm-1.0.1+dfsg
  dpkg-buildpackage: info: host architecture amd64
   fakeroot debian/rules clean
  dh clean --buildsystem=golang --with=golang,systemd --builddirectory=_build
 dh_testdir -O--buildsystem=golang -O--builddirectory=_build
 dh_auto_clean -O--buildsystem=golang -O--builddirectory=_build
 debian/rules override_dh_clean
  make[1]: Entering directory 
'/home/lamby/temp/cdt.20160708232023.ZfB4qjivAe.docker-swarm/docker-swarm-1.0.1+dfsg'
  dh_clean
  ## Remove Files-Excluded (when built from checkout or non-DFSG tarball):
  rm -f -rv `perl -0nE 'say $1 if 
m{^Files\-Excluded\:\s*(.*?)(?:\n\n|Files:|Comment:)}sm;' debian/copyright`
  make[1]: Leaving directory 
'/home/lamby/temp/cdt.20160708232023.ZfB4qjivAe.docker-swarm/docker-swarm-1.0.1+dfsg'
   debian/rules build
  dh build --buildsystem=golang --with=golang,systemd --builddirectory=_build
 dh_testdir -O--buildsystem=golang -O--builddirectory=_build
 dh_update_autotools_config -O--buildsystem=golang -O--builddirectory=_build
 debian/rules override_dh_auto_configure
  make[1]: Entering directory 
'/home/lamby/temp/cdt.20160708232023.ZfB4qjivAe.docker-swarm/docker-swarm-1.0.1+dfsg'
  mkdir -p _build && cp -r Godeps/_workspace/src _build/
  dh_auto_configure -v
mkdir -p _build
Copy main.go -> _build/src/github.com/docker/swarm/main.go
Copy version/version.go -> 
_build/src/github.com/docker/swarm/version/version.go
Copy scheduler/scheduler.go -> 
_build/src/github.com/docker/swarm/scheduler/scheduler.go
Copy scheduler/filter/dependency_test.go -> 
_build/src/github.com/docker/swarm/scheduler/filter/dependency_test.go
Copy scheduler/filter/port_test.go -> 
_build/src/github.com/docker/swarm/scheduler/filter/port_test.go
Copy scheduler/filter/health.go -> 
_build/src/github.com/docker/swarm/scheduler/filter/health.go
Copy scheduler/filter/affinity.go -> 
_build/src/github.com/docker/swarm/scheduler/filter/affinity.go
Copy scheduler/filter/expr.go -> 
_build/src/github.com/docker/swarm/scheduler/filter/expr.go
Copy scheduler/filter/filters_test.go -> 
_build/src/github.com/docker/swarm/scheduler/filter/filters_test.go
Copy scheduler/filter/filter.go -> 
_build/src/github.com/docker/swarm/scheduler/filter/filter.go
Copy scheduler/filter/constraint_test.go -> 
_build/src/github.com/docker/swarm/scheduler/filter/constraint_test.go
Copy scheduler/filter/expr_test.go -> 
_build/src/github.com/docker/swarm/scheduler/filter/expr_test.go
Copy scheduler/filter/health_test.go -> 
_build/src/github.com/docker/swarm/scheduler/filter/health_test.go
Copy scheduler/filter/constraint.go -> 
_build/src/github.com/docker/swarm/scheduler/filter/constraint.go
Copy scheduler/filter/port.go -> 
_build/src/github.com/docker/swarm/scheduler/filter/port.go
Copy scheduler/filter/dependency.go -> 
_build/src/github.com/docker/swarm/scheduler/filter/dependency.go
Copy scheduler/filter/affinity_test.go -> 
_build/src/github.com/docker/swarm/scheduler/filter/affinity_test.go
Copy scheduler/strategy/binpack_test.go -> 
_build/src/github.com/docker/swarm/scheduler/strategy/binpack_test.go
Copy scheduler/strategy/weighted_node.go -> 
_build/src/github.com/docker/swarm/scheduler/strategy/weighted_node.go
Copy scheduler/strategy/spread.go -> 
_build/src/github.com/docker/swarm/scheduler/strategy/spread.go

Bug#830520: ekg2: FTBFS: install: cannot change permissions of 'debian/ekg2-scripting-perl/usr/share/doc/ekg2-scripting-perl': No such file or directory

[Chris Lamb]

Source: ekg2
Version: 1:0.4~pre+20120506.1-12
Severity: serious
Justification: fails to build from source
User: reproducible-bui...@lists.alioth.debian.org
Usertags: ftbfs
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Dear Maintainer,

ekg2 fails to build from source in unstable/amd64:

  [..]

  cp docs/ekg2.en.1 docs/ekg2.1
  cd docs/ && ./generate-doc.sh
  warning: The selected output language "polish" has not been updated
  since release 1.8.2.  As a result some sentences may appear in English.
  
  
/home/lamby/temp/cdt.20160708232114.PqcwTgx2G2.ekg2/ekg2-0.4~pre+20120506.1/plugins/perl/perl_core.h:10:
 warning: include file EXTERN.h not found, perhaps you forgot to add its 
directory to INCLUDE_PATH?
  
/home/lamby/temp/cdt.20160708232114.PqcwTgx2G2.ekg2/ekg2-0.4~pre+20120506.1/plugins/perl/perl_core.h:11:
 warning: include file perl.h not found, perhaps you forgot to add its 
directory to INCLUDE_PATH?
  
/home/lamby/temp/cdt.20160708232114.PqcwTgx2G2.ekg2/ekg2-0.4~pre+20120506.1/plugins/perl/perl_core.h:12:
 warning: include file XSUB.h not found, perhaps you forgot to add its 
directory to INCLUDE_PATH?
  
/home/lamby/temp/cdt.20160708232114.PqcwTgx2G2.ekg2/ekg2-0.4~pre+20120506.1/ekg/commands.c:3517:
 warning: The following parameters of cmd_desc(const char *name, const char 
**params, session_t *session, const char *target, int quiet) are not documented:
parameter 'name'
parameter 'session'
parameter 'target'
parameter 'quiet'
  
/home/lamby/temp/cdt.20160708232114.PqcwTgx2G2.ekg2/ekg2-0.4~pre+20120506.1/ekg/commands.c:725:
 warning: The following parameters of cmd_eval(const char *name, const char 
**params, session_t *session, const char *target, int quiet) are not documented:
parameter 'name'
parameter 'session'
parameter 'target'
parameter 'quiet'
  
/home/lamby/temp/cdt.20160708232114.PqcwTgx2G2.ekg2/ekg2-0.4~pre+20120506.1/plugins/gg/commands.c:889:
 warning: The following parameters of gg_command_block(const char *name, const 
char **params, session_t *session, const char *target, int quiet) are not 
documented:
parameter 'name'
parameter 'session'
parameter 'target'
parameter 'quiet'
  
/home/lamby/temp/cdt.20160708232114.PqcwTgx2G2.ekg2/ekg2-0.4~pre+20120506.1/plugins/gg/commands.c:946:
 warning: The following parameters of gg_command_unblock(const char *name, 
const char **params, session_t *session, const char *target, int quiet) are not 
documented:
parameter 'name'
parameter 'session'
parameter 'target'
parameter 'quiet'
  
/home/lamby/temp/cdt.20160708232114.PqcwTgx2G2.ekg2/ekg2-0.4~pre+20120506.1/plugins/jabber/commands.c:1884:
 warning: The following parameters of jabber_muc_command_join(const char *name, 
const char **params, session_t *session, const char *target, int quiet) are not 
documented:
parameter 'name'
parameter 'session'
parameter 'target'
parameter 'quiet'
  
/home/lamby/temp/cdt.20160708232114.PqcwTgx2G2.ekg2/ekg2-0.4~pre+20120506.1/plugins/jabber/commands.c:1952:
 warning: The following parameters of jabber_muc_command_nick(const char *name, 
const char **params, session_t *session, const char *target, int quiet) are not 
documented:
parameter 'name'
parameter 'session'
parameter 'target'
parameter 'quiet'
  
/home/lamby/temp/cdt.20160708232114.PqcwTgx2G2.ekg2/ekg2-0.4~pre+20120506.1/plugins/jabber/commands.c:2223:
 warning: The following parameters of tlen_command_alert(const char *name, 
const char **params, session_t *session, const char *target, int quiet) are not 
documented:
parameter 'name'
parameter 'session'
parameter 'target'
parameter 'quiet'
  
/home/lamby/temp/cdt.20160708232114.PqcwTgx2G2.ekg2/ekg2-0.4~pre+20120506.1/ekg/sources.c:167:
 warning: argument 'priv_data' of command @param is not found in the argument 
list of source_remove_by_d(gpointer data, gpointer user_data)
  
/home/lamby/temp/cdt.20160708232114.PqcwTgx2G2.ekg2/ekg2-0.4~pre+20120506.1/ekg/sources.c:167:
 warning: argument 'name' of command @param is not found in the argument list 
of source_remove_by_d(gpointer data, gpointer user_data)
  
/home/lamby/temp/cdt.20160708232114.PqcwTgx2G2.ekg2/ekg2-0.4~pre+20120506.1/ekg/sources.c:182:
 warning: The following parameters of source_remove_by_d(gpointer data, 
gpointer user_data) are not documented:
parameter 'data'
parameter 'user_data'
  
/home/lamby/temp/cdt.20160708232114.PqcwTgx2G2.ekg2/ekg2-0.4~pre+20120506.1/ekg/sources.c:204:
 warning: argument 'plugin' of command @param is not found in the argument list 
of source_remove_by_p(gpointer data, gpointer user_data)
  
/home/lamby/temp/cdt.20160708232114.PqcwTgx2G2.ekg2/ekg2-0.4~pre+20120506.1/ekg/sources.c:204:
 warning: argument 'name' of command @param is not found in the argument list 
of source_remove_by_p(gpointer data, gpointer user_data)
  
/home/lamby/temp/cdt.20160708232114.PqcwTgx2G2.ekg2/ekg2-0.4~pre+20120506.1/ekg/sources.c:215:
 warning: The 

Bug#806033: gmime: FTBFS when built with dpkg-buildpackage -A (No such file or directory)

[Daniel Kahn Gillmor]

On Fri 2016-07-08 12:38:57 +0200, Mirco Bauer wrote:
> This is a simple design issue and thus limtation. dh_clideps can only know
> the correct binary dependencies if the shlibs files of the called native
> library (moduelrefs) is available. If you do not build the arch-dependent
> portion first, then you can not obtain the needed metadata from it.
>
>  [0]: 
> https://pkg-mono.alioth.debian.org/cli-policy/ch-appendix.html#s-dh_clideps

hmmm -- the arch-dependent builds *are* done first.  The only thing
that's not done is dh_makeshlibs because no arch:dependent binary
packages created.

 --dkg

Bug#659653: [libarchive-dev] many broken links in manual pages (libarchive_write, archive_read_extract, etc.)

[Peter Pentchev]

Hi,

Thanks for trying to improve libarchive by reporting this bug!

Could you confirm that at least the problems that you pointed out
have been fixed in libarchive-3.2.0-1 (or, rather, in 3.2.1-1
currently in testing and unstable)?  Do you see any more problems
in the current versions of the libarchive manual pages?

G'luck,
Peter

-- 
Peter Pentchev  r...@ringlet.net r...@freebsd.org p...@storpool.com
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115  C354 651E EFB0 2527 DF13


signature.asc
Description: PGP signature

Bug#830518: dma generated headers misses the domain part

[Christian Tessarek]

Package: dma
Version: 0.9-1
Severity: important

Dear Maintainer,

in some cases, the "From:" and the "To: address headers are missing a domain
part.

When I use the command line to directly send an email like "echo somethong |
mail -s 'test' somb...@example.org" as root, the sender address is correctly
expanded to root@ if MASQUERADE is set in
/etc/dma/dma.conf, to root@ if MASQUERADE is not set, and to
root@`hostname -s` if MAILNAME is also not set.
However, when the mail is sent from cron (e.g., by a line "* * * * * echo
something" in root's crontab), the From: address header is only "root (Cron
Daemon)" and only later by the smarthost expanded to
r...@mysmarthost.sender.com, when it actually should be root@.

When using the aliases file to map local accounts to foreign adddresses, the
"To:" header is (also) missing the domain part, e.g. with an alias file "root:
b...@example.com, b...@example.org", the mail is correcly delivered to the two
addresses, but the "To:" header field contains only "root" (which is expanded
by my smarthost to r...@mysmarthost.sender.com), when it also should actually
be root@

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=697871 seems to be rather
similar, but not quite, since in my case, it's not always the case since it
works when sending from the command line using the mail command, but it also
affects the To: header field when using aliases (even when using the mail
command).
I can't say why one triggers this behaviour and the other doesn't, and I'm also
not sure whether the latest upstream version shows the same behavior.

Best, Christian Tessarek


-- System Information:
Debian Release: 8.5
Architecture: amd64 (x86_64)

Kernel: Linux 3.16.0-4-amd64 (SMP w/24 CPU cores)

Bug#830517: lightdm: Cannot start sessions after first, requires lighdm restart

[Shai Berger]

Package: lightdm
Version: 1.18.2-1
Severity: normal

Dear Maintainer,

I am encountering difficulties with starting any session beyond the first.
Whether I try to start a second session while the first is still active (that
is, to switch to another user) or after the first user logged out, I get an
error message about DBus not being accessible, and the the (new) session is
ended before anything starts.

If I restart lightdm (from a text console, tty1) then I can log in again, but
again, only once.

FWIW, I'm a KDE/Plasma user; I've had similar and worse issues with sddm, so
the problem may actually be in some other component (systemd?), however, I
currently experience it as a lightdm issue and I don't really know how to
debug it further; I don't see anything which seems related in system logs.

Thanks,
Shai.


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

Kernel: Linux 4.6.0-1-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 lightdm depends on:
ii  adduser3.115
ii  dbus   1.10.8-1
ii  debconf [debconf-2.0]  1.5.59
ii  libaudit1  1:2.6.1-1
ii  libc6  2.23-1
ii  libgcrypt201.7.1-2
ii  libglib2.0-0   2.48.1-1
ii  libpam-systemd 230-5
ii  libpam0g   1.1.8-3.3
ii  libxcb11.11.1-1
ii  libxdmcp6  1:1.1.2-1.1
ii  lightdm-gtk-greeter [lightdm-greeter]  2.0.1-2

Versions of packages lightdm recommends:
ii  xserver-xorg  1:7.7+15

Versions of packages lightdm suggests:
ii  accountsservice  0.6.40-3
ii  upower   0.99.4-3

-- debconf information:
* shared/default-x-display-manager: lightdm
  lightdm/daemon_name: /usr/sbin/lightdm

Bug#829557: [Pkg-xfce-devel] Bug#829557: One more confirmation

[Yves-Alexis Perez]

On Fri, 2016-07-08 at 17:02 +0200, Stephane Bortzmeyer wrote:
> Running stretch, I confirm that the problem still exists today (after
> a dist-upgrade).
> 
> Installing dbus-user-session AND REBOOTING cured it.

Yeah, we're still investigating the problem, but right now I don't have much
clues about the error messages returned (epoll_ctl returned EINVAL, it seems)
and didn't have time to bisect (especially since lightdm upstream uses bazaar)

Regards,
-- 

Yves-Alexis

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

Bug#823978: freeorion: FTBFS with GCC 6: no match for

[Markus Koschany]

Control: reassign 811852 libboost-regex1.58.0
Control: severity 823978 serious
Control: merge 823978 811852
Control: affects 823978 freeorion

Hi,

freeorion builds fine with GCC-6 but fails in the linker step due to the
described error with boost-regex 1.58 in #823978. Since GCC-6 FTBFS bugs
are now release critical, #823978 is also RC. Reassigning to
libbost-regex.1.58.0.

Regards,

Markus



signature.asc
Description: OpenPGP digital signature

Bug#830516: clex: Cannot read the keyboard input

[Alberto Garcia]

Package: clex
Version: 3.15-1+b1
Severity: grave
Justification: renders package unusable

Hi,

It seems that I'm unable to run clex at all:

 -
$ clex




Starting CLEX 3.15

Terminating CLEX: Cannot read the keyboard input
 -

I don't know what's causing this, but strace shows a lot of failing
ioctls:

ioctl(0, TCGETS, {B38400 opost isig -icanon -echo ...}) = 0
ioctl(0, TIOCGPGRP, [2608]) = 0
ioctl(0, TIOCSPGRP, [2612]) = 0
ioctl(1, TCGETS, 0x7ffee7859f80)= -1 ENOTTY (Inappropriate ioctl for 
device)
ioctl(2, TCGETS, 0x7ffee7859f80)= -1 ENOTTY (Inappropriate ioctl for 
device)
ioctl(2, TCGETS, 0x7ffee7859f20)= -1 ENOTTY (Inappropriate ioctl for 
device)
ioctl(2, TCGETS, 0x7ffee7859ee0)= -1 ENOTTY (Inappropriate ioctl for 
device)
ioctl(2, TCGETS, 0x7ffee7859f50)= -1 ENOTTY (Inappropriate ioctl for 
device)
ioctl(2, TCGETS, 0x7ffee7859f60)= -1 ENOTTY (Inappropriate ioctl for 
device)
ioctl(1, TCGETS, 0x7ffee7859f80)= -1 ENOTTY (Inappropriate ioctl for 
device)
ioctl(2, TCGETS, 0x7ffee7859f60)= -1 ENOTTY (Inappropriate ioctl for 
device)
ioctl(2, SNDCTL_TMR_STOP or TCSETSW, {B0 -opost isig -icanon -echo ...}) = -1 
ENOTTY (Inappropriate ioctl for device)
ioctl(2, TCGETS, 0x7ffee785a070)= -1 ENOTTY (Inappropriate ioctl for 
device)
ioctl(2, TCGETS, 0x7ffee785a010)= -1 ENOTTY (Inappropriate ioctl for 
device)
ioctl(2, SNDCTL_TMR_STOP or TCSETSW, {B0 -opost -isig -icanon -echo ...}) = -1 
ENOTTY (Inappropriate ioctl for device)
ioctl(2, TCGETS, 0x7ffee7859ee0)= -1 ENOTTY (Inappropriate ioctl for 
device)
ioctl(2, SNDCTL_TMR_STOP or TCSETSW, {B0 -opost -isig -icanon -echo ...}) = -1 
ENOTTY (Inappropriate ioctl for device)
ioctl(0, TCGETS, {B38400 opost isig -icanon -echo ...}) = 0
ioctl(0, SNDCTL_TMR_CONTINUE or TCSETSF, {B38400 opost isig -icanon -echo ...}) 
= 0
ioctl(0, TCGETS, {B38400 opost isig -icanon -echo ...}) = 0
ioctl(0, TIOCSPGRP, [2608]) = 0

Regards,

Berto

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

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

Versions of packages clex depends on:
ii  libc62.22-11
ii  libncurses5  6.0+20160319-1
ii  libtinfo56.0+20160319-1

clex recommends no packages.

clex suggests no packages.

-- no debconf information

Bug#829150: Where is the repository

[Julien Puydt]

On 08/07/2016 15:10, James Cowgill wrote:

On Fri, 2016-07-08 at 15:03 +0200, Julien Puydt wrote:

I wanted to lend a hand on the matter, but unfortunately the git
repository hasn't been updated in ages, so I can't do much...


Are you sure? This repo was updated 13 days ago:
https://anonscm.debian.org/cgit/pkg-games/minetest-v04x.git


Oh dear, I innocently tried the logical:
$ gbp clone dg:minetest

With this other and more up to date repository, I see that the move of 
the .svg file from the minetest to the minetest-data package appears to 
have been done in commit 319831d7..., and hence was first shipped with 
0.4.14+repack-1.


I'm still pondering what Breaks/Replaces combination will do the trick 
(the relevant sections of the Debian policy seem to be 7.3 and 7.6).


Not today : my bed is calling.

Snark on #debian-games

Bug#828052: Please update Ports wiki page

[John Paul Adrian Glaubitz]

On 07/08/2016 07:20 PM, Holger Wansing wrote:
> You are right, strictly spoken.
> But there are several "old and removed" ports in the "unofficial ports" 
> section,
> like alpha or arm or hppa.
> To solve this, we would need to create a third section like "Old/Removed 
> ports",
> or the like.

Both alpha and hppa still exist, they have just become ports. Neither ia64 nor
sparc exist anywhere. That's a difference.

To see what targets in Debian are currently supported, both as release 
architectures
and as ports, look at a random buildd page [1]. As you can see, neither "sparc"
nor "ia64" are nowhere to be found while "alpha", "hppa" and "sparc64" are
preset - every architecture that is grayed out is currently unofficial, thus
a ports architecture.

Adrian
(a very active porter)

> [1] https://buildd.debian.org/status/package.php?p=base-files=sid

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#792204: Setting default CPU to ultrasparc for -m32 on sparc64 does not work

[John Paul Adrian Glaubitz]

On 07/07/2016 04:14 PM, John Paul Adrian Glaubitz wrote:
> With this patch applied, we should be able to fix this issue the same
> way it was fixed for gcc-6 [2].

Ok, here is an actually tested version of the patch (yes, I know :>).

To make it work, I put the patch into debian/patches, removed 
sparc-force-cpu.diff
from the same directory and debian/rules.patch, added sparc64-cpu32-support.diff
instead. After that, I patched debian/rules2 the same way it was patched for
gcc-6 [1].

Please note that both for gcc-5 and gcc-6 we are still ignoring the result of
dh_makeshlibs [2] which should probably be reverted again now as well now
that the symbols files are actually as expected.

Thanks,
Adrian

> [1] 
> http://anonscm.debian.org/viewvc/gcccvs/branches/sid/gcc-6/debian/rules2?r1=8914=8913=8914
> [2] 
> http://anonscm.debian.org/viewvc/gcccvs/branches/sid/gcc-5/debian/rules.d/binary-libstdcxx.mk?r1=8189=8188=8189

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
diff -Nru a/src/gcc/config/sparc/linux64.h b/src/gcc/config/sparc/linux64.h
--- a/src/gcc/config/sparc/linux64.h	2016-07-08 12:11:19.526313139 +0300
+++ b/src/gcc/config/sparc/linux64.h	2016-07-08 12:42:45.547699512 +0300
@@ -164,22 +164,42 @@
 #endif
 
 /* Support for a compile-time default CPU, et cetera.  The rules are:
-   --with-cpu is ignored if -mcpu is specified.
-   --with-tune is ignored if -mtune is specified.
+   --with-cpu is ignored if -mcpu is specified; likewise --with-cpu-32
+ and --with-cpu-64.
+   --with-tune is ignored if -mtune is specified; likewise --with-tune-32
+ and --with-tune-64.
--with-float is ignored if -mhard-float, -msoft-float, -mfpu, or -mno-fpu
  are specified.
In the SPARC_BI_ARCH compiler we cannot pass %{!mcpu=*:-mcpu=%(VALUE)}
here, otherwise say -mcpu=v7 would be passed even when -m64.
-   CC1_SPEC above takes care of this instead.  */
+   CC1_SPEC above takes care of this instead.
+
+   Note that the order of the cpu* and tune* options matters: the
+   config.gcc file always sets with_cpu to some value, even if the
+   user didn't use --with-cpu when invoking the configure script.
+   This value is based on the target name.  Therefore we have to make
+   sure that --with-cpu-32 takes precedence to --with-cpu in < v9
+   systems, and that --with-cpu-64 takes precedence to --with-cpu in
+   >= v9 systems.  As for the tune* options, in some platforms
+   config.gcc also sets a default value for it if the user didn't use
+   --with-tune when invoking the configure script.  */
 #undef OPTION_DEFAULT_SPECS
 #if DEFAULT_ARCH32_P
 #define OPTION_DEFAULT_SPECS \
+  {"cpu_32", "%{!m64:%{!mcpu=*:-mcpu=%(VALUE)}}" }, \
+  {"cpu_64", "%{m64:%{!mcpu=*:-mcpu=%(VALUE)}}" }, \
   {"cpu", "%{!m64:%{!mcpu=*:-mcpu=%(VALUE)}}" }, \
+  {"tune_32", "%{!m64:%{!mtune=*:-mtune=%(VALUE)}}" }, \
+  {"tune_64", "%{m64:%{!mtune=*:-mtune=%(VALUE)}}" }, \
   {"tune", "%{!mtune=*:-mtune=%(VALUE)}" }, \
   {"float", "%{!msoft-float:%{!mhard-float:%{!mfpu:%{!mno-fpu:-m%(VALUE)-float" }
 #else
 #define OPTION_DEFAULT_SPECS \
+  {"cpu_32", "%{m32:%{!mcpu=*:-mcpu=%(VALUE)}}" }, \
+  {"cpu_64", "%{!m32:%{!mcpu=*:-mcpu=%(VALUE)}}" }, \
   {"cpu", "%{!m32:%{!mcpu=*:-mcpu=%(VALUE)}}" }, \
+  {"tune_32", "%{m32:%{!mtune=*:-mtune=%(VALUE)}}" }, \
+  {"tune_64", "%{!m32:%{!mtune=*:-mtune=%(VALUE)}}" }, \
   {"tune", "%{!mtune=*:-mtune=%(VALUE)}" }, \
   {"float", "%{!msoft-float:%{!mhard-float:%{!mfpu:%{!mno-fpu:-m%(VALUE)-float" }
 #endif
diff -Nru a/src/gcc/config/sparc/sol2.h b/src/gcc/config/sparc/sol2.h
--- a/src/gcc/config/sparc/sol2.h	2015-10-01 15:01:18.0 +0300
+++ b/src/gcc/config/sparc/sol2.h	2016-07-08 12:46:25.148702254 +0300
@@ -231,22 +231,42 @@
 #endif
 
 /* Support for a compile-time default CPU, et cetera.  The rules are:
-   --with-cpu is ignored if -mcpu is specified.
-   --with-tune is ignored if -mtune is specified.
+   --with-cpu is ignored if -mcpu is specified; likewise --with-cpu-32
+ and --with-cpu-64.
+   --with-tune is ignored if -mtune is specified; likewise --with-tune-32
+ and --with-tune-64.
--with-float is ignored if -mhard-float, -msoft-float, -mfpu, or -mno-fpu
  are specified.
In the SPARC_BI_ARCH compiler we cannot pass %{!mcpu=*:-mcpu=%(VALUE)}
here, otherwise say -mcpu=v7 would be passed even when -m64.
-   CC1_SPEC above takes care of this instead.  */
+   CC1_SPEC above takes care of this instead.
+
+   Note that the order of the cpu* and tune* options matters: the
+   config.gcc file always sets with_cpu to some value, even if the
+   user didn't use --with-cpu when invoking the configure script.
+   This value is based on the target name.  Therefore we have to make
+   sure that --with-cpu-32 takes precedence to --with-cpu in < v9
+   systems, and that --with-cpu-64 takes precedence 

Bug#830515: quagga: "echo PING" logspam every 5 seconds

[Tobias Diedrich]

Package: quagga
Version: 1.0.20160315-1
Severity: minor
Tags: upstream

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Dear Maintainer,

since upgrading quagga I'm seeing logspam every 5 seconds:
Jul  8 22:10:33 nukunuku zebra[5299]: vty[??]@> echo PING
Jul  8 22:10:34 nukunuku bgpd[5327]: vty[??]@> echo PING
Jul  8 22:10:38 nukunuku zebra[5299]: vty[??]@> echo PING
Jul  8 22:10:39 nukunuku bgpd[5327]: vty[??]@> echo PING
Jul  8 22:10:43 nukunuku zebra[5299]: vty[??]@> echo PING
Jul  8 22:10:44 nukunuku bgpd[5327]: vty[??]@> echo PING
Jul  8 22:10:48 nukunuku zebra[5299]: vty[??]@> echo PING
Jul  8 22:10:49 nukunuku bgpd[5327]: vty[??]@> echo PING
Jul  8 22:10:53 nukunuku zebra[5299]: vty[??]@> echo PING
Jul  8 22:10:53 nukunuku bgpd[5327]: vty[??]@> echo PING
Jul  8 22:10:58 nukunuku zebra[5299]: vty[??]@> echo PING
Jul  8 22:10:58 nukunuku bgpd[5327]: vty[??]@> echo PING

quagga-users suggests applying this patch to remedy it:
http://patchwork.quagga.net/patch/1942/
"change command logging to be off by default, and add 'log_commands' to enable 
it."

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

Kernel: Linux 4.6.3 (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: sysvinit (via /sbin/init)

Versions of packages quagga depends on:
ii  adduser3.115
ii  debconf [debconf-2.0]  1.5.59
ii  iproute2   4.3.0-1+b1
ii  libc6  2.22-13
ii  libcap21:2.25-1
ii  libpam0g   1.1.8-3.3
ii  libreadline6   6.3-8+b4
ii  libtinfo5  6.0+20160319-2+b1
ii  logrotate  3.8.7-2

quagga recommends no packages.

Versions of packages quagga suggests:
pn  snmpd  

- -- Configuration Files:
/etc/quagga/daemons changed:
zebra=yes
bgpd=yes
ospfd=no
ospf6d=no
ripd=no
ripngd=no
isisd=no


- -- debconf information:
* quagga/really_stop: true

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iD8DBQFXgAl05q/seprH4LwRAmUoAJ4rQkJNaOYVmEfdcmZ2h9D4BptF/ACePPwP
QGF+sYZ8YSRH40gK2yEpCJ0=
=Oiwj
-END PGP SIGNATURE-

Bug#830514: plasma-desktop: Missing context menu (right click) on plasma desktop and desktop widgets

[Krzysztof Marczak]

Package: plasma-desktop
Version: 4:5.6.5-1
Severity: important

Dear Maintainer,

After latest upgrade there is missing context menu which should be shown after
right mouse click on plasma desktop or on desktop widgets.
Now it's not possible to unlock desktop widgets, add new widgets or modify
existing.





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

Kernel: Linux 4.6.0-1-amd64 (SMP w/8 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 plasma-desktop depends on:
ii  breeze   4:5.6.5-1
ii  kactivitymanagerd5.6.4-2
ii  kde-cli-tools4:5.6.5-1
ii  kded55.22.0-1
ii  kio  5.22.0-1
ii  libc62.22-13
ii  libcanberra0 0.30-3
ii  libfontconfig1   2.11.0-6.4
ii  libgcc1  1:6.1.1-8
ii  libkf5activities55.22.0-2
ii  libkf5activitiesexperimentalstats1   4:5.6.5-1
ii  libkf5archive5   5.23.0-1
ii  libkf5auth5  5.23.0-1
ii  libkf5baloo5 5.22.0-2
ii  libkf5bookmarks5 5.22.0-2
ii  libkf5codecs55.23.0-1
ii  libkf5completion55.23.0-1
ii  libkf5configcore55.23.0-1
ii  libkf5configgui5 5.23.0-1
ii  libkf5configwidgets5 5.22.0-1
ii  libkf5coreaddons55.23.0-1
ii  libkf5dbusaddons55.23.0-1
ii  libkf5emoticons-bin  5.22.0-1
ii  libkf5emoticons5 5.22.0-1
ii  libkf5globalaccel5   5.23.0-1
ii  libkf5guiaddons5 5.23.0-1
ii  libkf5i18n5  5.22.1-1
ii  libkf5iconthemes55.22.0-1
ii  libkf5itemmodels55.23.0-1
ii  libkf5itemviews5 5.23.0-1
ii  libkf5jobwidgets55.23.0-1
ii  libkf5kcmutils5  5.22.0-1
ii  libkf5kdelibs4support5   5.22.0-2
ii  libkf5kiocore5   5.22.0-1
ii  libkf5kiofilewidgets55.22.0-1
ii  libkf5kiowidgets55.22.0-1
ii  libkf5newstuff5  5.22.0-1
ii  libkf5notifications5 5.23.0-1
ii  libkf5notifyconfig5  5.22.0-1
ii  libkf5parts5 5.22.0-1
ii  libkf5people55.22.0-1
ii  libkf5peoplewidgets5 5.22.0-1
ii  libkf5plasma55.22.0-1
ii  libkf5plasmaquick5   5.22.0-1
ii  libkf5quickaddons5   5.22.0-1+b1
ii  libkf5runner55.22.0-1
ii  libkf5service-bin5.22.0-1
ii  libkf5service5   5.22.0-1
ii  libkf5solid5 5.23.0-1
ii  libkf5sonnetui5  5.23.0-1
ii  libkf5wallet-bin 5.22.0-1
ii  libkf5wallet55.22.0-1
ii  libkf5widgetsaddons5 5.23.0-1
ii  libkf5windowsystem5  5.23.0-1
ii  libkf5xmlgui55.22.0-1
ii  libkfontinst54:5.6.5-1
ii  libkfontinstui5  4:5.6.5-1
ii  libkworkspace5-5 4:5.6.5.1-1
ii  libphonon4qt5-4  4:4.9.0-3
ii  libpulse-mainloop-glib0  8.0-2+b2
ii  libpulse08.0-2+b2
ii  libqt5concurrent55.6.1+dfsg-3
ii  libqt5core5a 5.6.1+dfsg-3
ii  libqt5dbus5  5.6.1+dfsg-3
ii  libqt5gui5   5.6.1+dfsg-3
ii  libqt5network5   5.6.1+dfsg-3
ii  libqt5printsupport5  5.6.1+dfsg-3
ii  libqt5qml5   5.6.1-4
ii  libqt5quick5 5.6.1-4
ii  libqt5quickwidgets5  5.6.1-4
ii  libqt5sql5   5.6.1+dfsg-3
ii  libqt5svg5   5.6.1-2
ii  libqt5widgets5   5.6.1+dfsg-3
ii  libqt5x11extras5 5.6.1-2
ii  libqt5xml5   5.6.1+dfsg-3
ii  libstdc++6   6.1.1-8
ii  libtaskmanager5  4:5.6.5.1-1
ii  libx11-6 

Bug#295386: Discussion & proposal

[Asheesh Laroia]

I notice in the original bug report, Steve Langasek asked for, "I think it
would be better to either not offer users the choice of RC severities in
novice mode, or to only allow users to choose bug severities by
*description* rather than by name."

Then reportbug changed to remove the RC severities entirely, and Steve
remarked, "I said that, in novice mode, users should not be presented with
a list of severities *by name* to pick between because they won't have read
the documentation and won't know what the correct severity is."

Steve, I think that you changed your mind between filing the bug and adding
that comment. However I'm sympathetic to your desire to show RC bug
severities to novice users in a way that allows them to choose them, but
prevents them from choosing them merely due to a sense of self-importance.

I also noticed that the bug severities are listed most-severe first. See
below for a transcript from reportbug (some lines removed). I believe that
this puts the word "critical" at front & center of newcomers' minds, and
that this is a bad idea because it encourages choosing that option.

Therefore, I propose the following change:

- For non-novice users: show the lowest severity first and highest severity
last.

- For novice users: either (A) show the same as we show for all users, now
sorted with lowest severity first, or (B) skip the severity prompt, since
novice users are mostly unable to choose accurately, and tell novice users,
"If you need to change the severity, you can do so after the bug is filed,
or by changing your reportbug configuration level."

Steve, what is your preference between these options? Sandro Tosi, what is
yours?

My personal preference is to change the sorting for non-novice users as
described above, and also to do change the novice form according to option
(B).

Steve, I noticed that you suggested showing the RC bug severities without
their names. I attempted to create a proposed transcript that does that,
but I could not come up with a way to format it that still looked
reasonable to me. So if you can come up with a proposal, great! Until then
I am going to assume there is no reasonable way to do it.

Here's the transcript of current behavior.


$ reportbug dracut
[...]
Briefly describe the problem (max. 100 characters allowed). This will be
the bug email subject, so keep the summary as concise as possible, for
example: "fails to send email" or "does not start with -q option specified"
(enter Ctrl+c to
exit reportbug without reporting a bug).
> asdf
Rewriting subject to 'dracut: asdf'
How would you rate the severity of this problem or report?

1 criticalmakes unrelated software on the system (or the whole
system) break, or causes serious data loss, or introduces a security hole
on systems where you install the package.
2 grave   makes the package in question unusable by most or all
users, or causes data loss, or introduces a security hole allowing access
to the accounts of users who use the package.
3 serious is a severe violation of Debian policy (that is, the
problem is a violation of a 'must' or 'required' directive); may or may not
affect the usability of the package. Note that non-severe policy violations
may be
  'normal,' 'minor,' or 'wishlist' bugs. (Package
maintainers may also designate other bugs as 'serious' and thus
release-critical; however, end users should not do so.). For the canonical
list of issues worthing a
  serious severity you can refer to this webpage:
http://release.debian.org/testing/rc_policy.txt .
4 important   a bug which has a major effect on the usability of a
package, without rendering it completely unusable to everyone.
5 does-not-build  a bug that stops the package from being built from
source. (This is a 'virtual severity'.)
6 normal  a bug that does not undermine the usability of the whole
package; for example, a problem with a particular option or menu item.
7 minor   things like spelling mistakes and other minor cosmetic
errors that do not affect the core functionality of the package.
8 wishlistsuggestions and requests for new features.

Please select a severity level: [normal]



Here's my proposal instead:


$ reportbug dracut
[...]
Briefly describe the problem (max. 100 characters allowed). This will be
the bug email subject, so keep the summary as concise as possible, for
example: "fails to send email" or "does not start with -q option specified"
(enter Ctrl+c to
exit reportbug without reporting a bug).
> asdf
Rewriting subject to 'dracut: asdf'
How would you rate the severity of this problem or report?

1 wishlistsuggestions and requests for new features.
2 minor   things like spelling mistakes and other minor cosmetic
errors that do not affect the core functionality of the package.
3 normal  a bug that does not undermine the usability of the whole
package; for example, a problem with a particular option or menu 

Bug#830512: ITP: python-django-navtag -- Django template tag to handle navigation

[Michael Fladischer]

Package: wnpp
Severity: wishlist
Owner: Michael Fladischer 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: python-django-navtag
  Version : 2.1.1
  Upstream Author : Chris Beaven 
* URL : http://github.com/SmileyChris/django-navtag
* License : BSD-3-clause
  Programming Lang: Python
  Description : Django template tag to handle navigation


 A simple Django template tag to handle navigation item selection. It works
 through template inheritance and allows to define hierarchical navigation menu
 structures in the presentation layer. It differentiates itself from other
 solutions by sole reliance on templates.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCgAGBQJXgAdFAAoJEGlMre9Rx7W2v1wP/jrPB3Ha3LV7iQa1KQ0mFTXl
Ml7yiSzwJ07E+lBCLj+8NVIcKhUqhCUYt3WFV3kkrDm0Dt2Rf+ZPkG0R4LkQO61r
yuaVn3iLcWmm92zPzf7kpDMiES1uNZ5gY2rNVQyhFh2Bbzbn7cxhthNr1CMNd9zh
geZfTqnG4mlak2sYGmTxElUl19HyCMJfr9kiMnAppmAUAzyHWafRpaNRlV8JE0tf
X6GAHUoZjlSIOCYSji/bYWTSA9ELry75sLp5dxBg1Hf1/nWgU6x4JWu1Zewr/VE6
BaCJbTBNlRueZx2tYEQvrdh/aLvD0Odd1QX0Bw+wwVGh71oJ14oqp7YWTmSDb1aS
UlaawTnJCsdlonT+a5xbqr3ixz3Hqzxtc+7KCGSd8dRyw/O3Wsz+uQ3/7v8d1PjC
zA8uCBbJS3N5TTPwqrzAIMSSAFhbta6Sko/8ZujRqkucGHuD3DsN/4QpC1ryEV93
qVRE0usRnh8pqBLp3qGTmZJ3EIBHemnIvC5Cb5kexq14QsTGV/7VMGhD8kjQi2xA
jfQnI8aF/TKdS72sJ0CpHrZwEre4KZLGeT72+I1HPjEgVerzBRaY+loa95sIj7P3
WF6HLsIbhCMXbzAyJ53JdvLgVQQnmJjX714LIdyx1U0CY821Ion7j504XDDguQ6G
XJD2nuirOk62hXAlz6zt
=6pIa
-END PGP SIGNATURE-

Bug#830513: gnome-system-tools: Add mate-system-tools transitional package

[Jeremy Bicha]

Source: gnome-system-tools
Version: 3.0.0-5
Severity: wishlist

Debian 8 Jessie included mate-system-tools. This package has been
dropped from Debian because it is no longer maintained upstream. [1]

I have never used mate-system-tools but I imagine gnome-system-tools
works pretty much the same way (they were after all the same source a
few years ago). Therefore, please consider adding a transitional
package named mate-system-tools that depends on gnome-system-tools.

Thanks,
Jeremy Bicha

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

Bug#830510: faketime: '/usr/lib/faketime/libfaketime.so.1' from LD_PRELOAD cannot be preloaded

[Sven Joachim]

On 2016-07-08 21:04 +0200, Jakub Wilk wrote:

> Package: faketime
> Version: 0.9.6-5
> Severity: grave
>
> faketime no longer works:
>
> $ faketime '2008-12-24 08:15:42' date
> ERROR: ld.so: object '/usr/lib/faketime/libfaketime.so.1' from
> LD_PRELOAD cannot be preloaded (cannot open shared object file):
> ignored.
> Fri Jul  8 21:02:01 CEST 2016

The reason for this is that debian/rules now directly adds
-Wno-nonnull-compare to CFLAGS which causes dh to ignore
dpkg-buildflags.  Adding -Wno-nonnull-compare to DEB_CFLAGS_MAINT_APPEND
instead fixes this.

See debhelper(7) (emphasis mine):

,
|All of the dh_auto_* debhelper programs and dh set
|environment variables listed by dpkg-buildflags,
|*unless they are already set*.
`

Cheers,
   Sven

Bug#830511: kdepim4: kdepim4 build-depends on NBS libkgapi-dev

[Jeremy Bicha]

Source: kdepim4
Version: 4:4.14.10-5
Severity: serious
Justification: blocks removal of cruft

kdepim4 build-depends on libkgapi-dev but libkgapi-dev was dropped
from the libkgapi source nearly a year ago.

Thanks,
Jeremy Bicha

Bug#829151: RFS: setcolortemperature/1.1-1 ITP

[Jacob Adams]

control: retitle -1  RFS: setcolortemperature/1.3-1 ITP

On 07/08/2016 12:29 PM, Gianfranco Costamagna wrote:

> 
> the package is quite simple, but I would appreciate something more
> verbose when calling it with wrong parameters.
> e.g.
> sct
> sct -h
> sct -v
> sct 10
> sudo sct 10
> sudo sct 14
> 
> all gives no output.
> 
> After reading the manpage I discovered that numbers should be within a range.
> 
> I would appreciate a little help, and some error messages when bad input is 
> provided.

This has been fixed. Now when -h is passed usage is printed and if the
temperature passed is wrong usage will also be printed.

> other issues:
> $(CC) sct.c $(CFLAGS) $(LDFLAGS) -Wall -lX11 -lXrandr -o sct
> 
> 
> missing CPPFLAGS
> 
> LDFLAGS should go at the bottom, to avoid link failures with wl,asneeded
> (e.g. on Ubuntu where it is the default)

Fixed.

> there is a missing license in the tarball, please ask upstream to provide one

Added.

> other stuff LGTM
> 
> G.
> 


-- 
Jacob Adams
GPG Key: AF6B 1C26 E2D0 A988 432B  94F4 24C0 2B85 B59F E5A9

Bug#830308: d-i.debian.org: l10n-sync script breaks headers in individual package files in some situations

[Holger Wansing]

Hi,

Christian Perrier  wrote:
> Package: d-i.debian.org
> Severity: normal
> Tags: l10n
> 
> It turns out that, as things are right now, the l10n-sync scripts
> appears to break PO files headers in Danish and Belarusian
> translations of many packages, if not all of them.

It even more worse than this:

Not only the headers are corrupted, also many many translated Danish strings 
disappeared from the po files.

Current statistics for Danish show:

sublevel 1:
0 translated messages, 529 untranslated messages.

sublevel 3:
0 translated messages, 705 untranslated messages.
sublevel 4:
0 translated messages, 219 untranslated messages.
sublevel 5:
0 translated messages, 62 untranslated messages.


This all began at 27 May 2016.
There were translated strings before this date!



Holger


-- 

Created with Sylpheed 3.5.0 under
D E B I A N   L I N U X   8 . 0   " J E S S I E " .

Registered Linux User #311290 - https://linuxcounter.net/

Bug#830510: faketime: '/usr/lib/faketime/libfaketime.so.1' from LD_PRELOAD cannot be preloaded

[Jakub Wilk]

Package: faketime
Version: 0.9.6-5
Severity: grave

faketime no longer works:

$ faketime '2008-12-24 08:15:42' date
ERROR: ld.so: object '/usr/lib/faketime/libfaketime.so.1' from LD_PRELOAD 
cannot be preloaded (cannot open shared object file): ignored.
Fri Jul  8 21:02:01 CEST 2016



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

Kernel: Linux 4.6.0-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=pl_PL.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages faketime depends on:
ii  libc62.23-1
ii  libfaketime  0.9.6-5

--
Jakub Wilk

Bug#830353: ruby-kgio: FTBFS: ERROR: Test "ruby2.3" failed.

[Eric Wong]

Lucas Nussbaum  wrote:
> The full build log is available from:
>
> http://people.debian.org/~lucas/logs/2016/07/07/ruby-kgio_2.10.0-1_unstable_reb.normal.log
> 
> A list of current common problems and possible solutions is available at
> http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!
> 
> About the archive rebuild: The rebuild was done on EC2 VM instances from
> Amazon Web Services, using a clean, minimal and up-to-date chroot. Every
> failed build was retried once to eliminate random failures.

Thanks for the report.  Can you try the patch below?

I'd be interested to know what non-standard sysctl knobs are set
for kernel socket buffer sizes (in /proc/sys/net/{core,ipv4}/*mem*)

You can also increase the 20M to 30M or whatever (otoh, that
means using more memory during tests :<)

I'm not comfortable calling setsockopt to set SO_{SND,RCV}BUF
knobs since that can trigger VM deadlock bugs on some older
kernels, too.

Anyways, most of the kgio functionality is in Ruby 2.3 nowadays
and kgio can probably go away when support for 2.2 can be
dropped in gems.

8<
Subject: [PATCH] test: increase random blob size for giant socket buffers

Socket buffers on some systems may be too big to trigger
partial write/blocking behavior we need for our tests.
Increase it to 20M for now and see if we can fix an FTBFS
on larger machines: https://bugs.debian.org/830353

This should also speed up tests a little since urandom is
slow and reading 10M from it in the first place was lazy.
---
 test/lib_read_write.rb | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/test/lib_read_write.rb b/test/lib_read_write.rb
index 26e7aef..f5c5bf8 100644
--- a/test/lib_read_write.rb
+++ b/test/lib_read_write.rb
@@ -7,7 +7,12 @@ $-w = true
 require 'kgio'
 
 module LibReadWriteTest
-  RANDOM_BLOB = File.open("/dev/urandom") { |fp| fp.read(10 * 1024 * 1024) }
+  RANDOM_BLOB = File.open("/dev/urandom") do |fp|
+nr = 31
+buf = fp.read(nr)
+# get roughly a 20MB block of random data
+(buf * (20 * 1024 * 1024 / nr)) + (buf * rand(123))
+  end
 
   def teardown
 @rd.close if defined?(@rd) && ! @rd.closed?
-- 
EW

Bug#830503: intermittent dkim failures sending to Outlook 365

[Scott Kitterman]

On Friday, July 08, 2016 08:46:24 PM Daniel Pocock wrote:
> On 08/07/16 20:44, Scott Kitterman wrote:
> > On Friday, July 08, 2016 06:23:58 PM Daniel Pocock wrote:
> >> Package: opendkim
> >> Version: 2.9.2-2
...
> >> I notice that the DKIM-Signature header is repeated with different
> >> values for "b=..." and "t=" while all other values appear the same.
> >> 
> >> Are there known issues with OpenDKIM?  Is there any way to add any debug
> >> headers to the message to help troubleshoot?
> > 
> > I'm not aware of any outstanding issues that would cause this.  Do you
> > host
> > any mailing lists on this server that might result in messages being
> > processed (and signed) twice by the MTA?  If so, what you might be seeing
> > is body modifications by the MLM.
> > 
> > OpenDKIM will only sign once, so the likely answer is something in your
> > Postfix configuration is causing the milter to be triggered twice (I once
> > did this to myself by signing mail received via the Submission port - as
> > an example).
> 
> It isn't a mailing list server and I haven't configured it to modify
> messages.
> 
> The server does have Amavis and Spamassassin, could they clash with
> OpenDKIM in some way?

It's possible.  I'd like to see unsanitized output of postconf -n and your 
master.cf.  Direct mail is fine if you'd prefer they weren't memorialized in 
the BTS.

Scott K

Bug#796014: urandom seed not saved on shutdown

[Brian Minton]

Package: initscripts
Version: 2.88dsf-59.7
Followup-For: Bug #796014

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Dear Maintainer,

I'm still seeing this behavior.  My /var/lib/urandom hasn't been
updated, and I've rebooted my system several times.  

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

Kernel: Linux 4.6.0-trunk-amd64 (SMP w/16 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 initscripts depends on:
ii  coreutils   8.25-2
ii  debianutils 4.8
ii  lsb-base9.20160629
ii  mount   2.28-5
ii  sysv-rc 2.88dsf-59.7
ii  sysvinit-utils  2.88dsf-59.7

Versions of packages initscripts recommends:
ii  e2fsprogs  1.43.1-1
ii  psmisc 22.21-2.1+b1

initscripts suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iF4EAREIAAYFAld/9csACgkQa46zoGXPuqkSlwD8DVAS1IJcWiDTHSimTyGxwcKq
bYoXhOU68tuLtGPZqDoA/jrhyE9h5k3r8OwzKYFsvLUGLVHCUsXu/EtsW0Mlpykd
=qWH7
-END PGP SIGNATURE-

Bug#830503: intermittent dkim failures sending to Outlook 365

[Daniel Pocock]

On 08/07/16 20:44, Scott Kitterman wrote:
> On Friday, July 08, 2016 06:23:58 PM Daniel Pocock wrote:
>> Package: opendkim
>> Version: 2.9.2-2
>>
>> I'm using OpenDKIM and Postfix on Debian
>>
>> Outlook 365 and Hotmail users regularly have trouble receiving email
>> from some of the sending domains.
>>
>> One Outlook 365 user checked with their IT helpdesk and they sent me a
>> copy of the message headers.  In some of the messages they receive, it
>> has something like:
>>
>>
>>
>>
>> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=example.net; s=mail;
>>  t=1467730175; bh=..;
>>  h=Subject:To:References:From:Date:In-Reply-To:From;
>>  b==
>>
>> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=example.net; s=mail;
>>  t=1467730151; bh=(matches the previous message);
>>  h=Subject:To:References:From:Date:In-Reply-To:From;
>>  b=(doesn't match the previous header)
>>
>> Authentication-Results: spf=pass (sender IP is 195.8.117.5)
>>  smtp.mailfrom=example.net; example.org; dkim=fail (body hash did
>>  not verify) header.d=example.net;example.org; dmarc=bestguesspass
>>  action=none header.from=example.net;example.org; dkim=fail (body
>>  hash did not verify) header.d=example.net;
>>
>> X-DkimResult-Test: Failed
>>
>> Subject: This email has been identified as potential SPAM. Please
>> verify. (original subject follows.)
>>
>> I notice that the DKIM-Signature header is repeated with different
>> values for "b=..." and "t=" while all other values appear the same.
>>
>> Are there known issues with OpenDKIM?  Is there any way to add any debug
>> headers to the message to help troubleshoot?
> 
> I'm not aware of any outstanding issues that would cause this.  Do you host 
> any mailing lists on this server that might result in messages being 
> processed 
> (and signed) twice by the MTA?  If so, what you might be seeing is body 
> modifications by the MLM.  
> 
> OpenDKIM will only sign once, so the likely answer is something in your 
> Postfix configuration is causing the milter to be triggered twice (I once did 
> this to myself by signing mail received via the Submission port - as an 
> example).
> 

It isn't a mailing list server and I haven't configured it to modify
messages.

The server does have Amavis and Spamassassin, could they clash with
OpenDKIM in some way?

Bug#830503: intermittent dkim failures sending to Outlook 365

[Scott Kitterman]

On Friday, July 08, 2016 06:23:58 PM Daniel Pocock wrote:
> Package: opendkim
> Version: 2.9.2-2
> 
> I'm using OpenDKIM and Postfix on Debian
> 
> Outlook 365 and Hotmail users regularly have trouble receiving email
> from some of the sending domains.
> 
> One Outlook 365 user checked with their IT helpdesk and they sent me a
> copy of the message headers.  In some of the messages they receive, it
> has something like:
> 
> 
> 
> 
> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=example.net; s=mail;
>   t=1467730175; bh=..;
>   h=Subject:To:References:From:Date:In-Reply-To:From;
>   b==
> 
> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=example.net; s=mail;
>   t=1467730151; bh=(matches the previous message);
>   h=Subject:To:References:From:Date:In-Reply-To:From;
>   b=(doesn't match the previous header)
> 
> Authentication-Results: spf=pass (sender IP is 195.8.117.5)
>  smtp.mailfrom=example.net; example.org; dkim=fail (body hash did
>  not verify) header.d=example.net;example.org; dmarc=bestguesspass
>  action=none header.from=example.net;example.org; dkim=fail (body
>  hash did not verify) header.d=example.net;
> 
> X-DkimResult-Test: Failed
> 
> Subject: This email has been identified as potential SPAM. Please
> verify. (original subject follows.)
> 
> I notice that the DKIM-Signature header is repeated with different
> values for "b=..." and "t=" while all other values appear the same.
> 
> Are there known issues with OpenDKIM?  Is there any way to add any debug
> headers to the message to help troubleshoot?

I'm not aware of any outstanding issues that would cause this.  Do you host 
any mailing lists on this server that might result in messages being processed 
(and signed) twice by the MTA?  If so, what you might be seeing is body 
modifications by the MLM.  

OpenDKIM will only sign once, so the likely answer is something in your 
Postfix configuration is causing the milter to be triggered twice (I once did 
this to myself by signing mail received via the Submission port - as an 
example).

Scott K

Bug#828052: Please update Ports wiki page

[Jeffrey Walton]

> I think the status field saying "released", "discontinued" etc provides the 
> information with the current layout.
>
> Thanks for caring about the ports page. I marked the patches for review (in 
> my TODO) but couldn't find time :/
>

Convert it to a wiki page.

The work would have been done weeks ago without wasting roughly 40 or
60 man hours.

Jeff

Bug#830509: Fwd: python-gtkspellcheck: Debian version is outdated -> Up for adoption?

[Ben Wiederhake]

CC last NMU uploader

 Weitergeleitete Nachricht 
Betreff: python-gtkspellcheck: Debian version is outdated -> Up for 
adoption?

Datum: Fri, 08 Jul 2016 20:13:37 +0200
Von: Ben Wiederhake 
An: Debian Bug Tracking System 

Package: python-gtkspellcheck
Version: 3.0-1.1
Severity: important

Dear Maintainer,

I discovered that this package is actually pretty outdated: current is 
4.0.3.

At least one of the b.d.o bugs have already been fixed upstream.

I'm interested in packaging a newer version for Debian.  However, before I
start with that, I'd like to hear whether you (or the uploader of the 
last NMU)

are interested in updating the packaging yourself.

I'm also creating a public bug in case I need the MIA-team in the long run.

Cheers,
Ben Wiederhake

Bug#830509: python-gtkspellcheck: Debian version is outdated -> Up for adoption?

[Ben Wiederhake]

Package: python-gtkspellcheck
Version: 3.0-1.1
Severity: important

Dear Maintainer,

I discovered that this package is actually pretty outdated: current is 4.0.3.
At least one of the b.d.o bugs have already been fixed upstream.

I'm interested in packaging a newer version for Debian.  However, before I
start with that, I'd like to hear whether you (or the uploader of the last NMU)
are interested in updating the packaging yourself.

I'm also creating a public bug in case I need the MIA-team in the long run.

Cheers,
Ben Wiederhake

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

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

Versions of packages python-gtkspellcheck depends on:
ii  python  2.7.11-2
ii  python-enchant  1.6.6-2
ii  python-gi   3.20.1-1
ii  python-gtk2 2.24.0-4

Versions of packages python-gtkspellcheck recommends:
ii  iso-codes  3.68-1

python-gtkspellcheck suggests no packages.

Bug#829677: GNOME Boxes cannot starts VMs

[Pascal Obry]

Indeed all is working now.

Thanks a lot!

-- 

  Pascal Obry /  Magny Les Hameaux (78)

  The best way to travel is by means of imagination

  http://www.obry.net

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

Bug#830508: Most architectures are missing ola_dmxconsole/monitor

[Tom Dobes]

Package: ola
Version: 0.9.8-1
Severity: important

ola_dmxconsole and ola_dmxmonitor only exist in the amd64 package.
They are missing from the packages for all other architectures,
including all ARM variants and i386.

It looks like the makefile only builds these if HAVE_NCURSES is true.
Perhaps we need to add libncurses5-dev to Build-Depends?

Bug#828052: Please update Ports wiki page

[Laura Arjona Reina]

Hi 

On 8 de julio de 2016 19:20:13 GMT+02:00, Holger Wansing 
 wrote:
>Hi,
>
>John Paul Adrian Glaubitz  wrote:
>> 
>> 
>> > On Jul 7, 2016, at 8:57 PM, Holger Wansing
> wrote:
>> > 
>> > Hi,
>> > 
>> > Holger Wansing  wrote:
>> >> Hi,
>> >> 
>> >> Paul Wise  wrote:
>>  On Sat, Jun 25, 2016 at 9:55 AM, Jeffrey Walton wrote:
>>  
>>  The Ports wiki page (https://www.debian.org/ports/) appears to
>be out
>>  of date. Its causing confusion among users and maintainers. For
>>  example, a few bugs were reported for Sparc even though Tokarev,
>a
>>  QEMU--static maintainer, states its no longer supported.
>>  
>>  Spark should probably be labelled as discontinued.
>> >>> 
>> >>> I've CCed the SPARC porters, hopefully they can come up with a
>patch for this.
>> >>> 
>> >>> I expect they would be interested to hear about bugs in qemu so
>they
>> >>> can fix them.
>> >> 
>> >> 1. Please note that the page is not a wiki, as stated above.
>> >> 
>> >> 2. And additionally to the issues mentioned above, it's even
>worse:
>> >> 
>> >>   2.1 There are more archs listed as "released", while they got
>> >>   removed from Jessie: ia64, kFreeBSD 64-bit, kFreeBSD 32-bit,
>
>> >>   s390, and the already mentioned sparc.
>> > 
>> > I cooked a patch, to deal with all the suggestions made here:
>> > 
>> > - move ia64, kfreebsd-amd64, kfreebsd-i386, s390 and sparc to the
>"unofficial 
>> >  ports" section
>> 
>> ia64 isn't even an unofficial port, it was dropped completely. I
>think we even 
>> dropped support for it in src:glibc.
>> 
>> sparc has also been removed completely. It was replaced by sparc64.
>
>You are right, strictly spoken.
>But there are several "old and removed" ports in the "unofficial ports"
>section,
>like alpha or arm or hppa.
>To solve this, we would need to create a third section like
>"Old/Removed ports",
>or the like.
>

I think the status field saying "released", "discontinued" etc provides the 
information with the current layout.

Thanks for caring about the ports page. I marked the patches for review (in my 
TODO) but couldn't find time :/

Cheers

>
>Holger
>
>> > - set ia64 from "released" to "discontinued" and added a sentence
>to document
>> >  this change.
>> > - kfreebsd-amd64: added a sentence to document the current,
>non-official status
>> > - kfreebsd-i386: added a sentence to document the current,
>non-official status
>> > - set m68k from "discontinued/being revived" to "in progress"
>> > - set s390 from "released" to "replaced by s390x" and added a
>sentence to 
>> >  document this change.
>> > - sh: changed port name from "sh" to "sh4". And added a sentence to
>mention
>> >  the J-Core processor.
>> > 
>> > 
>> > A patch is attached, as well as the locally build html page, how it
>would
>> > look like.
>> > 
>> > 
>> > Comments?
>> > 
>> > Holger
>> > 
>> > 
>> > -- 
>> > 
>> > Created with Sylpheed 3.5.0 under
>> >D E B I A N   L I N U X   8 . 0   " J E S S I E " .
>> > 
>> > Registered Linux User #311290 - https://linuxcounter.net/
>> > 
>> > 
>> > 
>> 

Laura Arjona Reina
https://wiki.debian.org/LauraArjona

Bug#795287: videos 2016

[wold1]

https://www.youtube.com/watch?v=plPJKhQbw50
https://www.youtube.com/watch?v=Rvtl50T-gLA
https://www.youtube.com/watch?v=0WDe8Y9w4xE
https://www.youtube.com/watch?v=GNqdhJQGaKw

Bug#813549: cobbler: New version available upstream

[Nish Aravamudan]

Note that uscan/uupdate seems to pick up this new version fine.

Also, updating would fix Bug # 830302 without needing to patch.

-- 
Nishanth Aravamudan
Ubuntu Server
Canonical Ltd

Bug#830507: fence-agents: debian/watch file should be updated for move to github

[Nishanth Aravamudan]

Package: fence-agents
Severity: important

Dear Maintainer,

The debian/watch file refers to fedorahosted:

version=3
https://fedorahosted.org/releases/f/e/fence-agents/fence-agents-([\d\.]*)\.tar\.xz

but based upon
https://git.fedorahosted.org/cgit/fence-agents.git/tree/README,
https://github.com/ClusterLabs/fence-agents/releases should be used.

Thanks,
Nish

-- System Information:
Debian Release: stretch/sid
  APT prefers xenial-updates
  APT policy: (500, 'xenial-updates'), (500, 'xenial-security'), (500, 
'xenial'), (100, 'xenial-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.4.0-28-generic (SMP w/4 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)

-- 
Nishanth Aravamudan
Ubuntu Server
Canonical Ltd

Bug#830506: simbody includes and links statically ipopt library

[Daniele E. Domenichelli]

Source: simbody
Severity: important

Simbody includes and links statically its private version of the ipopt library
in libSimTKmath.so exports its symbols.

This causes issues when trying to link Ipopt and libSimTKmath in the same
executable or when an executable linked to libSimTKmath opens a plugin linked
to Ipopt (this happens for example when opening a plugin linked to Ipopt from
gazebo).



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

Kernel: Linux 4.6.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)

Bug#741196: libpetsc3.4.2: libpetsc.so.3.4.2 links with both GPL-licensed and GPL-incompatible libraries

[Francesco Poli]

On Thu, 7 Jul 2016 19:27:47 +0200 Lucas Nussbaum wrote:

> On 09/03/14 at 22:26 +0100, Francesco Poli (wintermute) wrote:
[...]
> >  (A) SCOTCH copyright holders should be contacted and persuaded to
> > re-license (or dual-license) it under GPLv2-or-later-compatible terms
>
> Hi Francesco,

Hello Lucas,
thanks for following up on this licensing issue!
I am very glad you stepped in.

>
> Have you tried the above?

Yes, I have, multiple times.

As I said in the original bug report:

| As stated in other bug reports, the best solution is (A). Thus, I renew
| my call for help to push in the direction of {re|dual}-licensing SCOTCH
| under the GNU LGPL v2.1: please see https://bugs.debian.org/740463#5
| for the details.

The relevant part of #740463#5 is:

| The best solution is (A): having SCOTCH re-licensed under
| GPLv2-or-later-compatible terms would eliminate all the SCOTCH
| license incompatibility issues.
| Since SCOTCH used to be LGPL-licensed (before switching to CeCILL-C!
| oh nooo!), I got in touch with the main author of SCOTCH
| (François Pellegrini) and tried to persuade him that SCOTCH should
| be re-licensed, in the hope that he would discuss the issue with
| the actual copyright holders (INRIA) and obtain the necessary paperwork.
| I talked to him in 2011, explaining the issue, but I apparently failed
| to convince him that there indeed is an issue.
| I have recently tried again to get in touch with him, but I haven't
| succeeded.
|
| Now I really need your help: please try hard to pursue solution (A).
| Succeeding would solve the issue for elmerfem, but also really benefit
| several other packages which suffer from similar problems with SCOTCH.

>
> It seems that the main SCOTCH copyright holders is Francois Pellegrini,

It is my understanding that he is the main author, but the copyright
holder is INRIA (along with ENSEIRB and CNRS).
Please see
https://tracker.debian.org/media/packages/s/scotch/copyright-5.1.12b.dfsg-2

However, I agree with you that François is really the person to be
persuaded.

Once he is convinced that SCOTCH should be re-licensed, I think he
will know who has to be contacted, in order to obtain the necessary
paperwork. Or, at least, I hope so.

> who is very active in the French Free Software community. One of the
> colleagues (same Inria research team) of Francois is Brice Goglin, who
> is a DD. So it might be useful to try to contact them.

This is the kind of help I have been asking for since I filed these
bug reports.
If you can get in touch with François Pellegrini, directly or
indirectly, and explain the issue to him in a convincing manner,
then I would be really really grateful.

As I said, I tried multiple times, but François no longer replies
to my e-mail messages. That's why I need help from people more likely
to be listened to.

>
> Also, I don't think that the CeCILL license is very popular at Inria
> anymore, but I might be wrong.

I hope this is the case, since license proliferation is really bad
and has caused many headaches to many concerned people.

Thanks for any help you may provide in solving this long-standing
issue.

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


pgpVCqfrEMdpN.pgp
Description: PGP signature

Bug#828052: Please update Ports wiki page

[Holger Wansing]

Hi,

John Paul Adrian Glaubitz  wrote:
> 
> 
> > On Jul 7, 2016, at 8:57 PM, Holger Wansing  wrote:
> > 
> > Hi,
> > 
> > Holger Wansing  wrote:
> >> Hi,
> >> 
> >> Paul Wise  wrote:
>  On Sat, Jun 25, 2016 at 9:55 AM, Jeffrey Walton wrote:
>  
>  The Ports wiki page (https://www.debian.org/ports/) appears to be out
>  of date. Its causing confusion among users and maintainers. For
>  example, a few bugs were reported for Sparc even though Tokarev, a
>  QEMU--static maintainer, states its no longer supported.
>  
>  Spark should probably be labelled as discontinued.
> >>> 
> >>> I've CCed the SPARC porters, hopefully they can come up with a patch for 
> >>> this.
> >>> 
> >>> I expect they would be interested to hear about bugs in qemu so they
> >>> can fix them.
> >> 
> >> 1. Please note that the page is not a wiki, as stated above.
> >> 
> >> 2. And additionally to the issues mentioned above, it's even worse:
> >> 
> >>   2.1 There are more archs listed as "released", while they got
> >>   removed from Jessie: ia64, kFreeBSD 64-bit, kFreeBSD 32-bit, 
> >>   s390, and the already mentioned sparc.
> > 
> > I cooked a patch, to deal with all the suggestions made here:
> > 
> > - move ia64, kfreebsd-amd64, kfreebsd-i386, s390 and sparc to the 
> > "unofficial 
> >  ports" section
> 
> ia64 isn't even an unofficial port, it was dropped completely. I think we 
> even 
> dropped support for it in src:glibc.
> 
> sparc has also been removed completely. It was replaced by sparc64.

You are right, strictly spoken.
But there are several "old and removed" ports in the "unofficial ports" section,
like alpha or arm or hppa.
To solve this, we would need to create a third section like "Old/Removed ports",
or the like.


Holger

> > - set ia64 from "released" to "discontinued" and added a sentence to 
> > document
> >  this change.
> > - kfreebsd-amd64: added a sentence to document the current, non-official 
> > status
> > - kfreebsd-i386: added a sentence to document the current, non-official 
> > status
> > - set m68k from "discontinued/being revived" to "in progress"
> > - set s390 from "released" to "replaced by s390x" and added a sentence to 
> >  document this change.
> > - sh: changed port name from "sh" to "sh4". And added a sentence to mention
> >  the J-Core processor.
> > 
> > 
> > A patch is attached, as well as the locally build html page, how it would
> > look like.
> > 
> > 
> > Comments?
> > 
> > Holger
> > 
> > 
> > -- 
> > 
> > Created with Sylpheed 3.5.0 under
> >D E B I A N   L I N U X   8 . 0   " J E S S I E " .
> > 
> > Registered Linux User #311290 - https://linuxcounter.net/
> > 
> > 
> > 
> 


-- 

Created with Sylpheed 3.5.0 under
D E B I A N   L I N U X   8 . 0   " J E S S I E " .

Registered Linux User #311290 - https://linuxcounter.net/

Bug#830489: RFS: python-qtpy/1.1.1-1

[Ghislain Vaillant]

On 08/07/16 17:23, Gianfranco Costamagna wrote:

e.g.
qtpy/_patch/qcombobox.py
qtpy/uic.py
Thomas Robitaille


Fixed in mentors.

Cheers,
Ghis

Bug#830505: cobbler: src:cobbler incorrectly builds power templates into pxe directory

[Nishanth Aravamudan]

Source: cobbler
Severity: important
Tags: patch

Dear Maintainer,

Seems like an obvious typo in the packaging, c from the previous
stanza.


-- System Information:
Debian Release: stretch/sid
  APT prefers xenial-updates
  APT policy: (500, 'xenial-updates'), (500, 'xenial-security'), (500, 
'xenial'), (100, 'xenial-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.4.0-28-generic (SMP w/4 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)

-- 
Nishanth Aravamudan
Ubuntu Server
Canonical Ltd
diff -Nru cobbler-2.6.6+dfsg1/debian/rules cobbler-2.6.6+dfsg1/debian/rules
--- cobbler-2.6.6+dfsg1/debian/rules2016-01-31 00:15:42.0 -0800
+++ cobbler-2.6.6+dfsg1/debian/rules2016-07-08 10:13:58.0 -0700
@@ -56,7 +56,7 @@
 
# Fix the /etc/cobbler/pxe folder
rm $(CURDIR)/debian/cobbler-common/etc/cobbler/pxe/*
-   cp $(CURDIR)/debian/power/* 
$(CURDIR)/debian/cobbler-common/etc/cobbler/pxe
+   cp $(CURDIR)/debian/pxe/* 
$(CURDIR)/debian/cobbler-common/etc/cobbler/pxe
 
# Move /etc/cobbler/{users.digest, settings} to /usr/share since we 
want to use
# debconf for configuring them.

Bug#824196: [Pkg-clamav-devel] Bug#824196: clamav-daemon: clamd crashes daily

[Will Aoki]

On Tue, May 24, 2016 at 10:51:24PM +0200, Sebastian Andrzej Siewior wrote:
> That is something. Would you mind to send me your clamd.conf +
> /var/lib/clamav without the daily.cvd + main.cvd? I just tried it with
> those pdf and nothing here leaks fds.

Posted at 
ftp://ftp.umnh.utah.edu/general-temporary/clamav/var_lib_clamav.tar.bz2

After additional testing, I think the problem lies with
local-js-sigs.ndb. WIth that file removed, clamav still dumps debug
warnings (when configured per the clamd.conf in the tarball) but does
not seem to leak file descriptors.

Bug#830504: RM: recite -- RoQA; RC-buggy, unmaintained, alternatives exist

[Jakub Wilk]

Package: ftp.debian.org

recite has been RC buggy for almost half a year (#800225).
It had no maintainer upload since 2004 and two NMUs since then.
It's dead upstream; last upstream release was in 1993.
It requires OSS, which almost nobody uses on Linux these days.
Alternatives exist: festival, espeak.
Popcon is low: about 50 installations and falling.

Please remove recite from unstable.

--
Jakub Wilk

Bug#825845: mrpt: FTBFS on big-endian systems, with test suite errors

[Gianfranco Costamagna]

Hi,

>I think I've (properly) fixed the issues in big-endian architectures

>for one set of tests.
>It would be great if you could launch a build in a test machine to confirm 
>it...
>
>The patch is in [1]. You could test it over release 1.4.0 (*without*
>the latest patch which, if you recall it, just put a #if 0 around the
>failing tests!), or just grab the whole thing from git master [2].

ok, rebased with current debian/unstable package and build good

>From Debian logs, I see that there is one more test that fails in
>*some* big endian architectures. I'm almost sure it could be debugged
>by running it with gdb.
>In these last weeks I managed to create a system to run unit tests
>under gdb as part of the Debian build, but it's disabled by default
>because it caused problems in armhf.
>You could also uncomment it (see lines [3] of debian/rules) to see if
>we can get more useful info about potential failures...
>Just replace
>
>MRPT_TEST_TARGET = test
>
>with:
>
>MRPT_TEST_TARGET = test_gdb

ok



I did grab the package from unstable, added the commit above, and did a 
complete build.
It didn't fail on s390x, so I don't know how to trigger that failure.


thanks,
G.

On Mon, Jul 4, 2016 at 12:13 PM, Gianfranco Costamagna
 wrote:
> Hi,
>
>
>>lease, find the workaround (not solution!) commit in [1]. Please, if
>
>>possible, apply it directly over the current v1.4.0 Debian package to
>>unblock building in big endian platforms. It would be great if you
>>could sponsor the update in Debian, not only in Ubuntu.
>>
>>If I find spare time to work in a real solution, I'll contact you just
>>in case you could help me testing the patches in porter machines...
>
>
> I can sponsor whatever you give me, a dsc, a tarball of debian packaging 
> directory,
> whatever (a git snapshot)
>
>
> Right now, I applied the two commits as patches, and the fix for 
> breaks+replaces
> fields, and I uploaded it in Ubuntu (to check if everything is correct)
>
> I called it ~build2 [1], so on the Debian upload it will be overridden 
> automatically
> by the auto import robot
>
>
> here [2]
>
> [1] https://launchpad.net/ubuntu/+source/mrpt/1:1.4.0-1build2
>
> [2] 
> http://launchpadlibrarian.net/270793330/mrpt_1%3A1.4.0-1build1_1%3A1.4.0-1build2.diff.gz
>
> I'm looking the build logs, if you can give me a dsc file I'll sponsor it in 
> a matter of minutes.
>
> If you don't change the version, just send me a tarball of the debian 
> directory, it should be enough for me!
>
> thanks for "fixing" :)
>
> Gianfranco



-- 
___

Jose Luis Blanco-Claraco
CITE-IV 1.05
Universidad de Almería, Departamento de Ingeniería
04120 Almería (Spain)
http://www.ual.es/~jlblanco/

___

Bug#709949: [libarchive] FTBFS on mips and powerpc: test_read_disk_directory_traversals atime mismatches

[Peter Pentchev]

Hi,

Should this bug be closed?  According to the buildd history:

  https://buildd.debian.org/status/logs.php?pkg=libarchive=mips

...libarchive-3.1.2-7 did indeed fail once on mips, but was then
rebuilt successfully, and has had no problems ever since; powerpc
seems to be exactly the same.

Of course, if somebody can reproduce the build failure, it should be
tracked down.

G'luck,
Peter

-- 
Peter Pentchev  r...@ringlet.net r...@freebsd.org p...@storpool.com
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115  C354 651E EFB0 2527 DF13


signature.asc
Description: PGP signature

Bug#829151: RFS: setcolortemperature/1.1-1 ITP

[Gianfranco Costamagna]

control: owner -1 !
control: tags -1 moreinfo
>Thanks for all your help reviewing my package!


the package is quite simple, but I would appreciate something more
verbose when calling it with wrong parameters.
e.g.
sct
sct -h
sct -v
sct 10
sudo sct 10
sudo sct 14

all gives no output.

After reading the manpage I discovered that numbers should be within a range.

I would appreciate a little help, and some error messages when bad input is 
provided.



other issues:
$(CC) sct.c $(CFLAGS) $(LDFLAGS) -Wall -lX11 -lXrandr -o sct


missing CPPFLAGS

LDFLAGS should go at the bottom, to avoid link failures with wl,asneeded
(e.g. on Ubuntu where it is the default)

there is a missing license in the tarball, please ask upstream to provide one

other stuff LGTM

G.

Bug#830503: intermittent dkim failures sending to Outlook 365

[Daniel Pocock]

Package: opendkim
Version: 2.9.2-2

I'm using OpenDKIM and Postfix on Debian

Outlook 365 and Hotmail users regularly have trouble receiving email
from some of the sending domains.

One Outlook 365 user checked with their IT helpdesk and they sent me a
copy of the message headers.  In some of the messages they receive, it
has something like:




DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=example.net; s=mail;

t=1467730175; bh=..;

h=Subject:To:References:From:Date:In-Reply-To:From;

b==


DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=example.net; s=mail;

t=1467730151; bh=(matches the previous message);

h=Subject:To:References:From:Date:In-Reply-To:From;

b=(doesn't match the previous header)


Authentication-Results: spf=pass (sender IP is 195.8.117.5)

 smtp.mailfrom=example.net; example.org; dkim=fail (body hash did

 not verify) header.d=example.net;example.org; dmarc=bestguesspass

 action=none header.from=example.net;example.org; dkim=fail (body

 hash did not verify) header.d=example.net;


X-DkimResult-Test: Failed



Subject: This email has been identified as potential SPAM. Please
verify. (original subject follows.)




I notice that the DKIM-Signature header is repeated with different
values for "b=..." and "t=" while all other values appear the same.

Are there known issues with OpenDKIM?  Is there any way to add any debug
headers to the message to help troubleshoot?

Bug#830489: RFS: python-qtpy/1.1.1-1

[Gianfranco Costamagna]

control: owner -1 !
control: tags -1 moreinfo

>I am looking for a sponsor for my package "python-qtpy"


missing copyrights:

e.g.
qtpy/_patch/qcombobox.py
qtpy/uic.py 
Thomas Robitaille

other stuff LGTM

G.

Bug#741650: /etc/init.d/o2cb: o2cb fail at startup, unable to bind net interface.

[Maurizio Cimaschi]

Hi Valentin,

thank you for your interest in this issue.


The cluster does not exist anymore, but the problem was probably 
due to the the fact that the cluster was using DHCP for network 
configuration. I agree that is not recomandable for server, but the 
cluster was intended for testing purpose e not for production environment.



It is clearly a minor bug that could be closed, but inserting a 
hook in the dhclient (man dhclient-script for details) script directory 
to reload the o2cb may solve this issue.



Regards.


On 08/07/16 12:16, Valentin Vidic wrote:

This probably depends on the type on networking on the host.  If the
problem still exists please send the network and cluster config.

Bug#830479: [pkg-gnupg-maint] Bug#830479: gnupg2: new trust level "poisoned"

[Simon Richter]

Hi,

On 08.07.2016 14:54, Werner Koch wrote:

>> with someone injecting the evil32 keys into the keyserver network it will
>> only be a matter of time until someone signs one of these by accident.

> If you believe that someone does not check the fingerprint of a key
> before they sign it, you should definitely set their ownertrust to
> _never_.  This way keys they sign are not considered in the WoT.

Exactly, but this currently requires me to run an external tool that
checks the signatures under the known bad keys and compare them with my
trustdb.

Ideally, gpg would allow me to do three things when I learn of a key
that has a uid of someone else:

1. set the trust to "never", so the key cannot act as an introducer.

This can be done already.

2. mark the key as invalid/unusable.

If someone I trust signs the fake key, that key is marked as "valid", so
signatures will be accepted and the key becomes a candidate for
encryption. As this is a result of updating the key and checking the
trustdb (which both happens noninteractively and automatically in many
contexts), the user does not have any notification, and since usually
the date is newer, that key is even preferred.

For the user to notice, they would have to compare the long key ID
before sending a mail, which is exactly what we want to avoid.

3. revoke the trust of anyone who signs that key

Again, this happens a lot later than when I learn of the fake key, so I
need help from gpg to notice this.

I know of several people who submit keys to keysigning parties and mark
everyone as untrustworthy who signs them (because no one with that name
went there and confirmed this to be their key), but this is still a
process outside of gpg. With the evil32 set being on the keyservers, I
believe this is a common enough use case that it should be supported out
of the box.

   Simon



signature.asc
Description: OpenPGP digital signature

Bug#830502: apparmor-profiles: Reconsider what profiles are shipped in /etc/apparmor.d/ and in which mode

[intrigeri]

Package: apparmor-profiles
Version: 2.10.95-4
Severity: normal

The apparmor-profiles package ships a number of profiles in
/etc/apparmor.d/, "in complain mode so that users can test and choose
which are desired". This includes policy for dovecot, dnsmasq,
avahi-daemon, ping.

This is confusing to some of us, and to users in general. And IIRC
Felix had some concerns about shipping these profiles there as well.

During the team meeting we had at DebConf, several options were
suggested:

a) Move the profiles that are not good enough to be enforced to
   a separate package

b) Move the profiles that are not good enough to be enforced to
   /usr/share/doc (where we already ship a number of profiles)

Also, it might be that some of these profiles are actually good enough
to be enforced by default, instead of being moved elsewhere.

Apparently, I've volunteered to work on that, but help would be
greatly welcome :)

Next step is to check what other distros (Ubuntu, OpenSUSE) do about
these profiles.

Cheers,
--
intrigeri

Bug#790969: [Pkg-lirc-maint] Bug#790969: Bug#790969: Same here...

[Alec Leamas]

On 03/07/16 11:21, Andreas Heinlein wrote:

I did as described and could reproduce the bug. Both the debug messages
and irrecord claiming it cannot find any toggle mask. What now?


First, since the bug is present also on 0.9.4 I filed an upstream bug 
[1]. If possible, I would appreciate if we could continue the discussion 
there.


Secondly, the logical step would be to use and check the kernel the 
original 3.16 jessie kernel - my gut feeling is that this is related to 
the kernel.


Third: could you please record one or two buttons (a few presses of each 
button) using mode2 and submit the mode2 output. Please mark each 
recording with the button used, and insert some newlines or so between 
each button press.


Cheers!

--alec


PS: Ashore just for a short time, returning to the sea ASAP. So, further 
replies might take some time, sorry.


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

Bug#829254: asset:precompile error when updating diaspora to 0.5.9.1

[Pirate Praveen]

On Friday 08 July 2016 08:48 PM, Cédric Boutillier wrote:
> On Fri, Jul 08, 2016 at 04:59:17PM +0530, Pirate Praveen wrote:
> 
>> The problem is libjs-handlebars is a node module (it should be changed
>> to node-handlebars I think) and handlebars_assets expects a browserified
>> version. Can I use the embedded version of handlebars.js from
>> handlebars_assets? I see ruby-uglifier does the same.
> 
> I don't think this is the way to go. ruby-uglifier has a bug open asking
> for using the binary packages from uglifyjs instead of the embedded copy
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=718367
> 
> 
> 

To be able to build handlebars.js and handlebars.runtime.js, we will
need grunt packaged first.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=673727
https://wiki.debian.org/Javascript/Nodejs/Tasks/grunt

I'll go with the embedded handlebars*.js for now and will build them
when grunt packaging is finished.

Any help in fixing the build is welcome.



signature.asc
Description: OpenPGP digital signature

Bug#830501: Gather data relevant to enabling AppArmor by default

[intrigeri]

Source: apparmor
Severity: normal

[I'll piggy-back on the BTS and pretend it's an appropriate TODO list
management system.]

In order to build a case for enabling AppArmor by default in Buster,
we need to gather some data:

 * usage:
   - in Debian: popcon
   - elsewhere: Tails, Ubuntu and others

 * usability cost: how often did AppArmor break stuff in sid?
   in testing? in stable? how fast were such issues fixed?

 * maintenance cost: how much work did we (and other maintainers
   affected by AppArmor) have to do to keep the policy up-to-date,
   since we started this effort? Let's focus on policy, and ignore the
   userspace tools packaging — that's a given.

 * security benefits: find CVEs / DSAs that were mitigated by the
   AppArmor policy we ship (not only it's useful for _us_ to check if
   our work had a measurable impact, but it also helps building the
   case in favor of enabling AppArmor by default, for example if
   having it would allow the security team to flag some issues no-dsa
   and focus on other matters)

I'll try to work on that shortly after the Stretch release to the
latest, so that we can raise this topic in the broader Debian
community as early as possible in the Buster development cycle.

Help is welcome!

Cheers,
--
intrigeri

Bug#830500: redis: FTBFS: Test failure

[Daniel Schepler]

Source: redis
Version: 2:3.2.1-1
Severity: serious

>From my pbuilder build log (on amd64):

...
[38/41 done]: integration/replication-3 (37 seconds)
[ok]: Client output buffer hard limit is enforced
[ok]: Test replication partial resync: ok after delay (diskless: no,
reconnect: 1)
[ok]: Connect multiple slaves at the same time (issue #141), diskless=no
[ok]: Slave should be able to synchronize with the master
[ok]: Detect write load to master
[ok]: Test replication partial resync: backlog expired (diskless: no,
reconnect: 1)
[ok]: Slave should be able to synchronize with the master
[ok]: Detect write load to master
[ok]: Test replication partial resync: no reconnection, just sync
(diskless: yes, reconnect: 0)
[ok]: Slave should be able to synchronize with the master
[ok]: Detect write load to master
[ok]: Client output buffer soft limit is not enforced if time is not overreached
[err]: Test replication partial resync: ok psync (diskless: yes,
reconnect: 1) in tests/integration/replication-psync.tcl
Expected condition '[s -1 sync_partial_ok] > 0' to be true ([s -1
sync_partial_ok] > 0)
[ok]: Slave should be able to synchronize with the master
[ok]: Detect write load to master
[ok]: Client output buffer soft limit is enforced if time is overreached
[39/41 done]: unit/obuf-limits (68 seconds)
...
!!! WARNING The following tests failed:

*** [err]: Test replication partial resync: ok psync (diskless: yes,
reconnect: 1) in tests/integration/replication-psync.tcl
Expected condition '[s -1 sync_partial_ok] > 0' to be true ([s -1
sync_partial_ok] > 0)
Cleanup: may take some time... OK
debian/rules:29: recipe for target 'override_dh_auto_test' failed
make[1]: *** [override_dh_auto_test] Error 1
make[1]: Leaving directory '/build/redis-3.2.1'
debian/rules:19: recipe for target 'build' failed
make: *** [build] Error 2
dpkg-buildpackage: error: debian/rules build gave error exit status 2
-- 
Daniel Schepler

Bug#830499: ITP: ncrack -- High-speed network authentication cracking tool

[Marcos]

Package: wnpp
Severity: wishlist
Owner: Marcos 

* Package name: ncrack
  Version : 0.5
  Upstream Author : Insecure.Com LLC
* URL : http://nmap.org/ncrack/
* License : GPLv2
  Programming Lang: C++
  Description : High-speed network authentication cracking tool

It was built to help companies secure their networks by proactively testing all
their hosts and networking devices for poor passwords. Security professionals
also rely on Ncrack when auditing their clients. Ncrack was designed using a
modular approach, a command-line syntax similar to Nmap and a dynamic engine
that can adapt its behaviour based on network feedback. It allows for rapid,
yet reliable large-scale auditing of multiple hosts.

Ncrack’s features include a very flexible interface granting the user full
control of network operations, allowing for very sophisticated bruteforcing
attacks, timing templates for ease of use, runtime interaction similar to
Nmap’s and many more. Protocols supported include RDP, SSH, http(s), SMB,
pop3(s), VNC, FTP, and telnet.

Bug#830498: plexus-compiler-1.0: FTBFS using locally rebuilt packages

[Daniel Schepler]

Source: plexus-compiler-1.0
Version: 1.9.2-6
Severity: important

>From my pbuilder build log, with all packages installed from a
repository of locally rebuilt packages:

...
[INFO] 
[INFO] Building Plexus Compiler 1.9.2
[INFO] 
[WARNING] The POM for
org.codehaus.plexus:plexus-component-metadata:jar:1.5.5 is missing, no
dependency information available
[INFO]
[INFO] 
[INFO] Skipping Plexus Compiler
[INFO] This project has been banned from the build due to previous failures.
[INFO] 
[INFO] 
[INFO] Reactor Summary:
[INFO]
[INFO] Plexus Compiler  FAILURE [  0.001 s]
[INFO] Plexus Compiler Api  SKIPPED
[INFO] Plexus Compiler Manager  SKIPPED
[INFO] Plexus Compiler Test Harness ... SKIPPED
[INFO] Plexus Compilers ... SKIPPED
[INFO] Plexus C# Compiler . SKIPPED
[INFO] Plexus Eclipse Compiler  SKIPPED
[INFO] Plexus Jikes Compiler .. SKIPPED
[INFO] Plexus Javac Component . SKIPPED
[INFO] 
[INFO] BUILD FAILURE
[INFO] 
[INFO] Total time: 0.302 s
[INFO] Finished at: 2016-07-03T21:28:47+00:00
[INFO] Final Memory: 9M/212M
[INFO] 
[ERROR] Plugin org.codehaus.plexus:plexus-component-metadata:1.5.5 or
one of its dependencies could not be resolved: Cannot access central
(https://repo.maven.apache.org/maven2) in offline mode and the
artifact org.codehaus.plexus:plexus-component-metadata:jar:1.5.5 has
not been downloaded from it before. -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with
the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions,
please read the following articles:
[ERROR] [Help 1]
http://cwiki.apache.org/confluence/display/MAVEN/PluginResolutionException
dh_auto_build: /usr/lib/jvm/default-java/bin/java -noverify -cp
/usr/share/maven/boot/plexus-classworlds-2.x.jar:/usr/lib/jvm/default-java/lib/tools.jar
-Dmaven.home=/usr/share/maven
-Dmaven.multiModuleProjectDirectory=/build/plexus-compiler-1.0-1.9.2
-Dclassworlds.conf=/etc/maven/m2-debian.conf
-Dproperties.file.manual=/build/plexus-compiler-1.0-1.9.2/debian/maven.properties
org.codehaus.plexus.classworlds.launcher.Launcher
-s/etc/maven/settings-debian.xml
-Ddebian.dir=/build/plexus-compiler-1.0-1.9.2/debian
-Dmaven.repo.local=/build/plexus-compiler-1.0-1.9.2/debian/maven-repo
package javadoc:jar javadoc:aggregate -DskipTests -Dnotimestamp=true
-Dlocale=en_US returned exit code 1
debian/rules:6: recipe for target 'build' failed
make: *** [build] Error 1
dpkg-buildpackage: error: debian/rules build gave error exit status 2
-- 
Daniel Schepler

Bug#826218: Complain still interferes

[intrigeri]

Control: retitle -1 Better document complain mode and debugging process
Control: severity -1 normal

Hi,

Guido Günther wrote (07 Jun 2016 05:58:56 GMT) :
> On Mon, Jun 06, 2016 at 12:47:08PM +0200, intrigeri wrote:
>> Guido, what do you think we should do about this
>> bug report now? Downgrade to normal severity and retitle to track
>> upstream progress of the planned improvements, perhaps?

> I'm all for downgrading and retitling.

Done!

> The information provided by upstream
> (thanks for that!) is too valuable to let it go to the bts archive
> as of yet.

ACK.

> I wouldn't have filed a bug if:

> * The manpage would have mentioned that deny rules are still enforced
>   (and don't print anything) in the aa-complain manpage. Christian
>   added a note on this at

> 
> https://bazaar.launchpad.net/~apparmor-dev/apparmor/master/revision/3482?start_revid=3482

> * The manpage would have redirected me to a page that lists the other
>   nice commands mentioned by John

> This informaton should IMHO go into upstream manpages / documentation
> and be linked to from the various manpages one steps on first
> (aa-complain, ...) in order to hopefully help people along to debug
> things.

> For the time being I dumpted things here:

> https://honk.sigxcpu.org/piki/development/apparmor-debugging/

u. volunteered to work on this \o/

Cheers,
--
intrigeri

Bug#830497: openjpa: FTBFS: the artifact javax.servlet:servlet-api:jar:debian has not been downloaded

[Daniel Schepler]

Source: openjpa
Version: 2.4.0-2
Severity: serious

>From my pbuilder build log:

...
[INFO] 
[INFO] Building OpenJPA JEST 2.4.0
[INFO] 
[WARNING] The POM for javax.servlet:servlet-api:jar:debian is missing,
no dependency information available
[INFO] 
[INFO] Reactor Summary:
[INFO]
[INFO] OpenJPA Utilities Library .. SUCCESS [  4.177 s]
[INFO] OpenJPA Kernel . SUCCESS [  4.931 s]
[INFO] OpenJPA JDBC ... SUCCESS [  2.821 s]
[INFO] OpenJPA Persistence  SUCCESS [  1.789 s]
[INFO] OpenJPA Persistence JDBC ... SUCCESS [  0.506 s]
[INFO] OpenJPA XML Store .. SUCCESS [  0.106 s]
[INFO] OpenJPA Slice .. SUCCESS [  0.379 s]
[INFO] OpenJPA JEST ... FAILURE [  0.019 s]
[INFO] OpenJPA Aggregate Jar .. SKIPPED
[INFO] OpenJPA Parent POM . SKIPPED
[INFO] 
[INFO] BUILD FAILURE
[INFO] 
[INFO] Total time: 15.301 s
[INFO] Finished at: 2016-07-04T07:27:51+00:00
[INFO] Final Memory: 39M/641M
[INFO] 
[ERROR] Failed to execute goal on project openjpa-jest: Could not
resolve dependencies for project
org.apache.openjpa:openjpa-jest:jar:2.4.0: Cannot access central
(https://repo.maven.apache.org/maven2) in offline mode and the
artifact javax.servlet:servlet-api:jar:debian has not been downloaded
from it before. -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to
execute goal on project openjpa-jest: Could not resolve dependencies
for project org.apache.openjpa:openjpa-jest:jar:2.4.0: Cannot access
central (https://repo.maven.apache.org/maven2) in offline mode and the
artifact javax.servlet:servlet-api:jar:debian has not been downloaded
from it before.
at 
org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.getDependencies(LifecycleDependencyResolver.java:221)
at 
org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.resolveProjectDependencies(LifecycleDependencyResolver.java:128)
at 
org.apache.maven.lifecycle.internal.MojoExecutor.ensureDependenciesAreResolved(MojoExecutor.java:245)
at 
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:199)
at 
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at 
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at 
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
at 
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
at 
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
at 
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:307)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:193)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:106)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:863)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:288)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:199)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:188)
at org.debian.maven.Wrapper.main(Wrapper.java:89)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
org.codehaus.plexus.classworlds.launcher.Launcher.launchStandard(Launcher.java:330)
at 
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:238)
at 
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
Caused by: org.apache.maven.project.DependencyResolutionException:
Could not resolve dependencies for project
org.apache.openjpa:openjpa-jest:jar:2.4.0: Cannot access central
(https://repo.maven.apache.org/maven2) in offline mode and the
artifact javax.servlet:servlet-api:jar:debian has not been downloaded
from it before.
at 

Bug#798476: debian-policy: don't require Uploaders

[Christian Hofstaedtler]

* Julien Cristau  [160708 15:31]:
> for some time I've been uploading packages with Maintainer set to a
> mailing list and no Uploaders field.  In cases where some package kind
> of fit within a team, but noone cares specifically about that individual
> package, I feel it's better than setting Maintainer to the Debian QA
> Group, which policy currently says is required, since the team will get
> bug mail, and any updates to the package will probably come from the
> team anyway.  So I'd like to see this requirement relaxed.

I also want to see this. It makes lots of sense, especially for
teams maintaining very large numbers of packages. Honestly, the
individual package does not carry heavy weight in some of those
teams. At the same time, many packages carry old Uploaders,
including names of people that have long been known to be MIA, and
are kept there only to avoid setting an empty Uploaders field.

These packages are clearly not not-maintained (teams care about
them), so orphaning or assinging to Debian QA Group would make no
sense whatsoever. (Also, as far as I'm aware, the large teams are
all very open for anybody to join.)

-- 
 ,''`.  Christian Hofstaedtler 
: :' :  Debian Developer
`. `'   7D1A CFFA D9E0 806C 9C4C  D392 5C13 D6DB 9305 2E03
  `-

Bug#830496: libspring-java: FTBFS: Could not resolve javax.el:el-api:2.2.

[Daniel Schepler]

Source: libspring-java
Version: 4.1.9-1
Severity: serious

>From my pbuilder build log:

...
:spring-web:compileJava (Thread[main,5,main]) completed. Took 0.18 secs.

FAILURE: Build failed with an exception.

* What went wrong:
Could not resolve all dependencies for configuration
':spring-web:compileClasspath'.
> Could not resolve javax.el:el-api:2.2.
  Required by:
  org.springframework:spring-web:4.1.9.RELEASE >
javax.servlet.jsp:javax.servlet.jsp-api:2.2.1
   > No cached version of javax.el:el-api:2.2 available for offline mode.
> Could not resolve javax.servlet:servlet-api:2.2.
  Required by:
  org.springframework:spring-web:4.1.9.RELEASE >
javax.servlet.jsp:javax.servlet.jsp-api:2.2.1
   > No cached version of javax.servlet:servlet-api:2.2 available for
offline mode.

* Try:
Run with --debug option to get more log output.

* Exception is:
org.gradle.api.artifacts.ResolveException: Could not resolve all
dependencies for configuration ':spring-web:compileClasspath'.
at 
org.gradle.api.internal.artifacts.ivyservice.DefaultLenientConfiguration.rethrowFailure(DefaultLenientConfiguration.java:62)
at 
org.gradle.api.internal.artifacts.ivyservice.DefaultResolvedConfiguration.rethrowFailure(DefaultResolvedConfiguration.java:36)
at 
org.gradle.api.internal.artifacts.ivyservice.SelfResolvingDependencyConfigurationResolver$FilesAggregatingResolvedConfiguration.rethrowFailure(SelfResolvingDependencyConfigurationResolver.java:112)
at 
org.gradle.api.internal.artifacts.ivyservice.ErrorHandlingConfigurationResolver$ErrorHandlingResolvedConfiguration.rethrowFailure(ErrorHandlingConfigurationResolver.java:189)
at 
org.gradle.api.internal.artifacts.configurations.DefaultConfiguration$ConfigurationFileCollection.getFiles(DefaultConfiguration.java:666)
at 
org.gradle.api.internal.artifacts.configurations.DefaultConfiguration.getFiles(DefaultConfiguration.java:292)
at 
org.gradle.api.internal.artifacts.configurations.DefaultConfiguration_Decorated.getFiles(Unknown
Source)
at 
org.gradle.api.internal.file.collections.DefaultFileCollectionResolveContext$FileTreeConverter.convertInto(DefaultFileCollectionResolveContext.java:202)
at 
org.gradle.api.internal.file.collections.DefaultFileCollectionResolveContext.doResolve(DefaultFileCollectionResolveContext.java:103)
at 
org.gradle.api.internal.file.collections.DefaultFileCollectionResolveContext.resolveAsFileTrees(DefaultFileCollectionResolveContext.java:74)
at 
org.gradle.api.internal.file.collections.DefaultFileCollectionResolveContext$FileTreeConverter.convertInto(DefaultFileCollectionResolveContext.java:188)
at 
org.gradle.api.internal.file.collections.DefaultFileCollectionResolveContext.doResolve(DefaultFileCollectionResolveContext.java:98)
at 
org.gradle.api.internal.file.collections.DefaultFileCollectionResolveContext.resolveAsFileTrees(DefaultFileCollectionResolveContext.java:74)
at 
org.gradle.api.internal.changedetection.state.DefaultFileCollectionSnapshotter.visitFiles(DefaultFileCollectionSnapshotter.java:41)
at 
org.gradle.api.internal.changedetection.state.AbstractFileCollectionSnapshotter.snapshot(AbstractFileCollectionSnapshotter.java:57)
at 
org.gradle.api.internal.changedetection.state.DefaultFileCollectionSnapshotter.snapshot(DefaultFileCollectionSnapshotter.java:29)
at 
org.gradle.api.internal.changedetection.rules.AbstractFileSnapshotTaskStateChanges.createSnapshot(AbstractFileSnapshotTaskStateChanges.java:47)
at 
org.gradle.api.internal.changedetection.rules.InputFilesTaskStateChanges.(InputFilesTaskStateChanges.java:33)
at 
org.gradle.api.internal.changedetection.rules.TaskUpToDateState.(TaskUpToDateState.java:52)
at 
org.gradle.api.internal.changedetection.changes.DefaultTaskArtifactStateRepository$TaskArtifactStateImpl.getStates(DefaultTaskArtifactStateRepository.java:142)
at 
org.gradle.api.internal.changedetection.changes.DefaultTaskArtifactStateRepository$TaskArtifactStateImpl.isUpToDate(DefaultTaskArtifactStateRepository.java:73)
at 
org.gradle.api.internal.tasks.execution.SkipUpToDateTaskExecuter.execute(SkipUpToDateTaskExecuter.java:55)
at 
org.gradle.api.internal.tasks.execution.ValidatingTaskExecuter.execute(ValidatingTaskExecuter.java:58)
at 
org.gradle.api.internal.tasks.execution.SkipEmptySourceFilesTaskExecuter.execute(SkipEmptySourceFilesTaskExecuter.java:52)
at 
org.gradle.api.internal.tasks.execution.SkipTaskWithNoActionsExecuter.execute(SkipTaskWithNoActionsExecuter.java:52)
at 
org.gradle.api.internal.tasks.execution.SkipOnlyIfTaskExecuter.execute(SkipOnlyIfTaskExecuter.java:53)
at 
org.gradle.api.internal.tasks.execution.ExecuteAtMostOnceTaskExecuter.execute(ExecuteAtMostOnceTaskExecuter.java:43)
at 
org.gradle.execution.taskgraph.DefaultTaskGraphExecuter$EventFiringTaskWorker.execute(DefaultTaskGraphExecuter.java:203)
at 

Bug#827506: linux-image-4.6.0-1-amd64: Intel i915 graphics locks up

[zi]

Hi cbarn,

you might try the latest Kernel from Sid:

uname -vr
4.6.0-1-amd64 #1 SMP Debian 4.6.3-1 (2016-07-04)

This dist-upgrade solved the problem with i915 on my system.

(I can confirm, that the problem existed with the previous the kernel  
4.6.2-2 on my system.


Hope I could help

Bug#830495: doxia: FTBFS using locally rebuilt packages

[Daniel Schepler]

Source: doxia
Version: 1.1.4-6
Severity: important

>From my pbuilder build log, with all packages installed from a local
repository of rebuilt packages:

...
[INFO] 
[INFO] Building Doxia 1.1.4
[INFO] 
[WARNING] The POM for
org.codehaus.plexus:plexus-component-metadata:jar:1.5.5 is missing, no
dependency information available
[INFO]
[INFO] 
[INFO] Skipping Doxia
[INFO] This project has been banned from the build due to previous failures.
[INFO] 
[INFO] 
[INFO] Reactor Summary:
[INFO]
[INFO] Doxia .. FAILURE [  0.002 s]
[INFO] Doxia :: Logging API ... SKIPPED
[INFO] Doxia :: Sink API .. SKIPPED
[INFO] Doxia :: Core .. SKIPPED
[INFO] Doxia :: Modules ... SKIPPED
[INFO] Doxia :: APT Module  SKIPPED
[INFO] Doxia :: Confluence Module . SKIPPED
[INFO] Doxia :: Simplified DocBook Module . SKIPPED
[INFO] Doxia :: FML Module  SKIPPED
[INFO] Doxia :: FO Module . SKIPPED
[INFO] Doxia :: iText Module .. SKIPPED
[INFO] Doxia :: Latex Module .. SKIPPED
[INFO] Doxia :: RTF Module  SKIPPED
[INFO] Doxia :: TWiki Module .. SKIPPED
[INFO] Doxia :: XDoc Module ... SKIPPED
[INFO] Doxia :: XHTML Module .. SKIPPED
[INFO] Doxia :: Book Component  SKIPPED
[INFO] 
[INFO] BUILD FAILURE
[INFO] 
[INFO] Total time: 0.345 s
[INFO] Finished at: 2016-07-08T07:07:49+00:00
[INFO] Final Memory: 10M/212M
[INFO] 
[ERROR] Plugin org.codehaus.plexus:plexus-component-metadata:1.5.5 or
one of its dependencies could not be resolved: Cannot access central
(https://repo.maven.apache.org/maven2) in offline mode and the
artifact org.codehaus.plexus:plexus-component-metadata:jar:1.5.5 has
not been downloaded from it before. -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with
the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions,
please read the following articles:
[ERROR] [Help 1]
http://cwiki.apache.org/confluence/display/MAVEN/PluginResolutionException
dh_auto_build: /usr/lib/jvm/default-java/bin/java -noverify -cp
/usr/share/maven/boot/plexus-classworlds-2.x.jar:/usr/lib/jvm/default-java/lib/tools.jar
-Dmaven.home=/usr/share/maven
-Dmaven.multiModuleProjectDirectory=/build/doxia-1.1.4
-Dclassworlds.conf=/etc/maven/m2-debian.conf
-Dproperties.file.manual=/build/doxia-1.1.4/debian/maven.properties
org.codehaus.plexus.classworlds.launcher.Launcher
-s/etc/maven/settings-debian.xml
-Ddebian.dir=/build/doxia-1.1.4/debian
-Dmaven.repo.local=/build/doxia-1.1.4/debian/maven-repo package
javadoc:jar javadoc:aggregate -DskipTests -Dnotimestamp=true
-Dlocale=en_US returned exit code 1
debian/rules:6: recipe for target 'build' failed
make: *** [build] Error 1
dpkg-buildpackage: error: debian/rules build gave error exit status 2
-- 
Daniel Schepler

Bug#829557: One more confirmation

[Stephane Bortzmeyer]

Running stretch, I confirm that the problem still exists today (after
a dist-upgrade).

Installing dbus-user-session AND REBOOTING cured it.

ii  liblightdm-gobject-1-01.18.2-1 
amd64simple display manager (gobject library)
ii  lightdm   1.18.2-1 
amd64simple display manager
ii  dbus  1.10.8-1 
amd64simple interprocess messaging system (daemon and utilities)
ii  dbus-user-session 1.10.8-1 
all  simple interprocess messaging system (systemd --user integration)
ii  dbus-x11  1.10.8-1 
amd64simple interprocess messaging system (X11 deps)

Bug#830494: RFS: python-qtawesome/0.3.3-2

[Ghislain Vaillant]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

* Package name: python-qtawesome
  Version : 0.3.3-2
  Upstream Author : The Spyder Development Team
* URL : https://github.com/spyder-ide/qtawesome
* License : Expat
  Section : python

It builds those binary packages:

  python-qtawesome - iconic fonts in PyQt and PySide applications 
(Python 2)

  python-qtawesome-common - common files for QtAwesome
  python-qtawesome-doc - documentation and examples for QtAwesome
  python3-qtawesome - iconic fonts in PyQt and PySide applications 
(Python 3)


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


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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/p/python-qtawesome/python-qtawesome_0.3.3-2.dsc


Changes since the last upload:

  * Enable upstream testsuite.
  * Add packaging testsuite.
  * d/clean: remove unnecessary listing of sphinx directory.
  * d/rules: improve formatting of sphinx-build command.
  * Bump standards version to 3.9.8, no changes required.

Regards,
Ghislain Vaillant

Bug#829608: [Debian-med-packaging] Bug#829608: orthanc: ftbfs with new dcmtk

[Sebastien Jodogne]

FYI, I have modified your original patch so as to be more bullet-proof
wrt. future evolutions of the dcmtk package:
http://anonscm.debian.org/cgit/debian-med/orthanc.git/commit/?id=8d9cbc2f8b4c8d6395ad59cee45ba92adf39b447


I dcutted the package from deferred, I'll be happy to sponsor an upload 
whenever you can
(or ask your usual sponsor)


Thanks! Andreas Tille is my usual sponsor, and it think he will take 
care of this upload: I have sent a ping on the Debian Med mailing list. 
I will get back in touch with you if this is not the case.


Sébastien-

Bug#830492: ITP: minetest-mod-animalmaterials -- Minetest mod providing models for animals

[Julien Puydt]

Package: wnpp
Severity: wishlist

* Package name : minetest-mod-animalmaterials
  Version  : 0.1.3
  Upstream author  : sapier
* URL  : https://github.com/sapier/animalmaterials
  License  : good question (issue #1 upstream)
  Programming Lang.: Lua
  Description  : Minetest mod providing models for animals
 This minetest extension provides animal materials (various types of
 meat), as well as cooking recipes with them (pun intended).

I plan to package it within the Debian Games Team repository, were other 
minetest-mod-* packages already are.


That will fix a big issue with the latest minetest-mod-mobf package -- 
that it doesn't actually work!


Snark on #debian-games

Bug#830493: Lacks depends

[Julien Puydt]

Package: minetest-mod-mobf
Version: 2.5.0-1
Severity: grave

In fact, the new version of mobf needs minetest mods available within 
the animalmaterials modpack. Without those, it doesn't bring anything 
more than error messages on the screen (and that only if you disable the 
buggy appearance of a "debian" among the mods of the pack... but that is 
bug #827669).


I'll try to package the animalmaterials modpack as 
minetest-mod-animalmaterials. Then this package will have to be modified 
to depend on it.


Snark on #debian-games

Bug#830489: RFS is reopened.

[Ghislain Vaillant]

On 08/07/16 14:50, Ghislain Vaillant wrote:

Hang on there is a mistake left to fix. Will report when done.

Ghis


The mistake is fixed on mentors. Sponsorship can resume.

Thanks,
Ghis

Bug#829614: plasma-workspace: Desktop search is also broken

[Martin Steigerwald]

Am Freitag, 8. Juli 2016, 15:46:24 CEST schrieben Sie:
> In data giovedì 7 luglio 2016 20:26:42, Martin Steigerwald ha scritto:
> > No error? Just no output?
> 
> For some reason the Debian bug-tracking system is not showing my full
> message, it curiously cut the interesting part!

Please don´t use HTML mails.

> In you click on "Message part 2" at the end of my message you'll be taken to
> the link
> https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=829614;msg=30 where
> you can see my full message, including terminal output

Please review "Krunner stopped finding and running anything in Debian testing" 
thread on debian-kde mailinglist in case you use Debian Testing.

Especially make sure libkf5plasma5 is at 5.23. Also to Gard: Please try this. 
Your issue bay also be fixed by this.

Please use debian-kde mailinglist for further communication until its clear if 
there is really a bug or if its just a package version issue in testing 
currently.

In case it would be beneficial to have a versioned dependency, you can still 
add that to the bug report later one.

Thank you,
Martin

-- 
Martin