Bug#838694: icu: CVE-2016-7415: Stack based buffer overflow in locid.cpp

[Salvatore Bonaccorso]

On Tue, Oct 04, 2016 at 10:59:52PM +0200, László Böszörményi (GCS) wrote:
> > Laszlo, do you know more already? Other distributions seem in the same
> > boat, like Red Hat in
> > https://bugzilla.redhat.com/show_bug.cgi?id=1377361#c3
>  Sorry, I was on a trip and just arrived back on Sunday evening. Did
> an other security upload and then killed my machine. Minus one
> keyboard (a special one) and a monitor. Only now could boot the
> remaining hardware.
> I don't know more about this issue - upstream keep such bugreports
> secret, if any. I don't have a good connection with them (yet), but
> will try to know more about this.

Ack and thanks a lot already!

Regards,
Salvatore

Bug#832062: supertuxkart: source for GPL song Boom_boom_boom.ogg missing

[Vincent Cheng]

(Looping in ftpmasters to see if they have any comments re: #832062)

Hi Deve,

On Tue, Oct 4, 2016 at 1:19 PM, Deve  wrote:
> Hi,
>
> After direct contact with the author, I corrected the information about
> author and license in this commit:
>
> https://sourceforge.net/p/supertuxkart/code/16762/
>
> Also note that source files (the .mod file and lossless .wav file) are
> available in our media repo:
> https://sourceforge.net/p/supertuxkart/code/HEAD/tree/media/trunk/music/mods/

Great, thanks for the link!

> More information:
> http://forum.freegamedev.net/viewtopic.php?f=17=6562
> https://github.com/supertuxkart/stk-code/issues/2577
>
> I hope that this should be enough to fix this issue.

Would it be at all possible for "Vim" to publicly state their approval
of licensing "Boom_boom_boom.ogg" under the CC-BY-SA 4.0 license (by
replying directly to this bug report / upstream github issue / forum
thread at [1])? Unfortunately their last public statement in [1]
imposes a not-for-profit condition on using their work, which violates
DFSG#6.

Does ftpmaster or anyone else in the Debian Games team have any
thoughts about this issue? I think a public statement from the
original composer of the track in question would be sufficient (unless
"Vim" has a gpg key tied to their identity, which doesn't seem to be
the case), unless anyone has any objections? I don't think we can
reasonably expect more proof from upstream that this file is
DFSG-compatible.

Regards,
Vincent

[1] http://forum.freegamedev.net/viewtopic.php?f=17=6562#p70981

Bug#773747: pgpdump: infinite loop on crafted file

[Paul Wise]

On Mon, 22 Dec 2014 17:14:24 -0500 Jose-Luis Rivas wrote:
> On 22/12/14, 10:52pm, Jakub Wilk wrote:
> > This command hangs:
> > 
> > printf '\243\003' | pgpdump
> 
> Just got this messages, thanks, now it's actually attached.

This is fixed in upstream version 0.30, please upload it.

Please include the CVE number in the changelog.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#839701: libreoffice-gnome: internal crash from native print dialog (Gnome/GTK)

[Drew Parsons]

On Tue, 2016-10-04 at 15:31 +0200, Rene Engelhard wrote:
> 
> Though I consider this configuration questionable per se; on
> a company I worked before it afaicr just worked because the PPD (and
> printer)
> supported it so that you can just print and give you pw _on the
> printer_...

Give the password at the printer! ouch...

> What happens if you used -gtk2? (And remove -gtk3, maybe, given it
> will
> take precendence anyway)? Could very well be that it's Gtk3-only.

You're right, under -gtk2 it brings up the dialog box asking for the
password to the printer.  Looks like it's -gtk3 only. I'll file the
upstream bug.

Drew

Bug#839570: Browserified javascript and DFSG 2 (reopening)

[Pirate Praveen]

On 2016, ഒക്‌ടോബർ 4 7:49:28 PM IST, Sam Hartman  wrote:
>You're asking questions that don't make sense from a p.process
>standpoint, doing things that have a very low probability of making
>anyone happy, 

A quick update, I have asked ftp masters to make a ruling on the issue. #839801.

I feel these responses make TC more like a bureaucracy, where focus is given on 
process and having people to go around asking many people.

I have to go now, will try to reply in detail later.


-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Bug#839801: Browserified javascript and DFSG source

[Pirate Praveen]

package: ftp.debian.org

Hi ftp masters,

A bug was filed against libjs-handlebars (#817092) with severity serious for 
missing source code.

I approached TC about this issue as I did not agree to this interpretation 
(#830978). But they asked me to talk to you.

I reopened that bug here #839570.

So I request ftp masters,

1. To make an official ruling on this issue.
2. If this is considered RC, give an exception to stretch release so there is 
enough time to package grunt and fix this properly. I believe moving these 
packages to contrib/non-free is not an ideal solution as many users will have 
to enable these sections to install packages like diaspora, gitlab, pagure, 
prometheus etc.

Bug#839800: wireless-tools FTCBFS: uses the build architecture compiler for the udeb pass

[Helmut Grohne]

Source: wireless-tools
Version: 30~pre9-11
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

wireless-tools fails to cross build from source, because it uses the
build architecture compiler which leads to a dh_strip failure. Since
debhelper 10.2.1, dh_auto_build passes a suitable cross compiler via CC,
so the main pass now succeeds. The direct make invocation for the udeb
pass still uses the build architecture compiler though. After changing
that to dh_auto_build as well (see attached patch), wireless-tools cross
builds just fine. Please consider applying it.

Helmut
diff --minimal -Nru wireless-tools-30~pre9/debian/changelog 
wireless-tools-30~pre9/debian/changelog
--- wireless-tools-30~pre9/debian/changelog 2016-04-30 20:28:49.0 
+0200
+++ wireless-tools-30~pre9/debian/changelog 2016-10-05 05:25:10.0 
+0200
@@ -1,3 +1,10 @@
+wireless-tools (30~pre9-11.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Also use dh_auto_build for the udeb pass. Closes: #-1
+
+ -- Helmut Grohne   Wed, 05 Oct 2016 05:24:34 +0200
+
 wireless-tools (30~pre9-11) unstable; urgency=medium
 
   * Add ConditionPathExists=/etc/iftab to ifrename.service. Closes: #823028
diff --minimal -Nru wireless-tools-30~pre9/debian/rules 
wireless-tools-30~pre9/debian/rules
--- wireless-tools-30~pre9/debian/rules 2016-03-24 22:30:00.0 +0100
+++ wireless-tools-30~pre9/debian/rules 2016-10-05 05:24:32.0 +0200
@@ -10,7 +10,7 @@
dh_auto_install -- install install-static PREFIX=debian/tmp
# Hack to make udeb friendly binaries
$(MAKE) clean
-   $(MAKE) BUILD_NOLIBM=y CFLAGS="-Os -I."
+   dh_auto_build -- BUILD_NOLIBM=y CFLAGS="-Os -I."
dh_install -pwireless-tools-udeb iwconfig iwgetid sbin/
dh_install -plibiw30-udeb libiw.so.30 lib/
 

Bug#839799: caja still doesn't work from console and gives theme errors

[shirish शिरीष]

Package: caja
Version: 1.16.0-1
Severity: normal

Dear Maintainer,
Even after upgrading to 1.16 I am still unable to use caja from the console.

This is what I get from the console -

┌─[shirish@debian] - [~] - [10004]
└─[$] caja

(caja:3934): Gtk-WARNING **: Theme parsing error: gtk.css:63:28: The
:prelight pseudo-class is deprecated. Use :hover instead.

(caja:3934): Gtk-WARNING **: Theme parsing error: gtk.css:73:35: The
:prelight pseudo-class is deprecated. Use :hover instead.

It basically displays then and then doesn't appear,  sometimes the
console (zsh in my case) disappears altogether.

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

Kernel: Linux 4.7.0-1-amd64 (SMP w/2 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 caja depends on:
ii  caja-common   1.16.0-1
ii  desktop-file-utils0.23-1
ii  gvfs  1.30.0-1
ii  libatk1.0-0   2.22.0-1
ii  libc6 2.24-3
ii  libcairo-gobject2 1.14.6-1+b1
ii  libcairo2 1.14.6-1+b1
ii  libcaja-extension11.16.0-1
ii  libexempi32.3.0-2
ii  libexif12 0.6.21-2
ii  libgail-3-0   3.22.1-1
ii  libgdk-pixbuf2.0-02.36.0-1
ii  libglib2.0-0  2.50.0-2
ii  libglib2.0-data   2.50.0-2
ii  libgtk-3-03.22.1-1
ii  libice6   2:1.0.9-1+b1
ii  libmate-desktop-2-17  1.16.0-1
ii  libpango-1.0-01.40.3-2
ii  libpangocairo-1.0-0   1.40.3-2
ii  libselinux1   2.5-3
ii  libsm62:1.2.2-1+b1
ii  libstartup-notification0  0.12-4
ii  libunique-3.0-0   3.0.2-2
ii  libx11-6  2:1.6.3-1
ii  libxext6  2:1.3.3-1
ii  libxml2   2.9.4+dfsg1-2
ii  libxrender1   1:0.9.9-2
ii  mate-desktop  1.16.0-1
ii  shared-mime-info  1.7-1

Versions of packages caja recommends:
ii  gvfs-backends  1.30.0-1

Versions of packages caja suggests:
ii  engrampa1.16.0-1
ii  gstreamer1.0-tools  1.8.3-1
ii  meld3.16.3-1

-- no debconf information


-- 
  Regards,
  Shirish Agarwal  शिरीष अग्रवाल
  My quotes in this email licensed under CC 3.0
http://creativecommons.org/licenses/by-nc/3.0/
http://flossexperiences.wordpress.com
EB80 462B 08E1 A0DE A73A  2C2F 9F3D C7A4 E1C4 D2D8

Bug#839798: rfkill FTCBFS: uses buid architecture compiler

[Helmut Grohne]

Source: rfkill
Version: 0.5-1
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

rfkill fails to cross build from source, because it uses the build
architecture compiler (hardcoded in Makefile) which leads to dh_strip
giving up on wrong architecture objects. The attached patch passes a
suitable CC to the make invocation and makes cross builds succeed.
Please consider applying it.

Helmut
diff --minimal -Nru rfkill-0.5/debian/changelog rfkill-0.5/debian/changelog
--- rfkill-0.5/debian/changelog 2013-09-26 16:21:19.0 +0200
+++ rfkill-0.5/debian/changelog 2016-10-05 05:17:42.0 +0200
@@ -1,3 +1,10 @@
+rfkill (0.5-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Pass triplet-prefixed CC to make. (Closes: #-1)
+
+ -- Helmut Grohne   Wed, 05 Oct 2016 05:17:29 +0200
+
 rfkill (0.5-1) unstable; urgency=low
 
   * New upstream release.
diff --minimal -Nru rfkill-0.5/debian/rules rfkill-0.5/debian/rules
--- rfkill-0.5/debian/rules 2013-09-26 16:10:22.0 +0200
+++ rfkill-0.5/debian/rules 2016-10-05 05:17:27.0 +0200
@@ -11,6 +11,10 @@
 
 DPKG_EXPORT_BUILDFLAGS = 1
 include /usr/share/dpkg/buildflags.mk
+include /usr/share/dpkg/architecture.mk
+ifeq ($(origin CC),default)
+CC = $(DEB_HOST_GNU_TYPE)-gcc
+endif
 
 configure: configure-stamp
 configure-stamp:
@@ -22,7 +26,7 @@
 
 build-stamp: configure-stamp
dh_testdir
-   $(MAKE) VERSION_SUFFIX="$(shell dpkg-parsechangelog | sed -e 
'/^Version:/! d; s/^[^-]*-//; q') ($(shell dpkg-vendor --query VENDOR))"
+   $(MAKE) VERSION_SUFFIX="$(shell dpkg-parsechangelog | sed -e 
'/^Version:/! d; s/^[^-]*-//; q') ($(shell dpkg-vendor --query VENDOR))" 
CC="$(CC)"
touch $@
 
 clean:

Bug#839797: uptimed: [INTL:ru] Russian debconf templates translation update

[Yuri Kozlov]

Package: uptimed
Version: 1:0.4.0+git20150923.6b22106-1
Severity: wishlist
Tags: l10n patch

Dear Maintainer,

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

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

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

Russian debconf templates translation update is attached.

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

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


ru.po.gz
Description: application/gzip

Bug#834881: onboard: new upstream release 1.3.0

[Jeremy Bicha]

On Sun, Oct 2, 2016 at 5:24 AM, Jeremy Bicha  wrote:
> On Sun, Oct 2, 2016 at 5:00 AM, Ritesh Raj Sarraf  wrote:
>> Now that GNOME 3.22 is out, are there other issue why you are holding off the
>> upload ?

It's now in the new queue since we added the gnome-shell-extension as
a separate binary package.

Jeremy

Bug#523972: xserver-xorg-video-radeon:

[John Lewis]

Package: xserver-xorg-video-radeon
Version: 1:7.5.0-1
Followup-For: Bug #523972

I had similar issues with an R7 360. I have more information on this
thread. https://lists.x.org/archives/xorg/2016-September/058291.html

Bug#816457: iw: new upstream version (4.7)

[Diederik de Haas]

On Sat, 9 Jul 2016 11:18:16 +0200 Julian Wollrath  wrote:
> attached is a patch, that updates the packaging from svn for upstream
> version 4.7.

I see only a change in the changelog and append-cppflags.patch, but not the 
code itself ...

Apart from that, it would be nice to have a recent version of iw in Stretch.

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

Bug#839796: Ability to specify size for --skip-errors

[Anthony DeRobertis]

Package: pv
Version: 1.6.0-1
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

pv's --skip-errors behavior is currently to try skipping 1 byte a few
times, then 2 bytes a few times, then 1 byte a few more (because it was
at 14 bytes), then 4 a few, then... blah blah, until it finally finishes
by skipping 512 bytes 7 times; all in all, I counted 25 attempts,
totaling of course 4k.

Because it's a disk, with 4k sectors. Bad blocks on the disk,
fundamentally, can not be smaller than 4k. (Nor larger, really, but of
course you can have two in a row.)

This wouldn't be a huge deal, except that disks take forever attempting
to read bad sectors. 30 seconds per failed read is quite possible (some
take longer, actually, and Linux times out, then you get to wait through
a reset cycle, though strictly speaking that's admin error in failing to
raise the Linux timeout)

I'm not sure if there is *any* storage device which can have a 1-byte
error. Wikipedia tells me there were once floppy formats with 128-byte
sectors. It was apparently common enough with 8-inch and even 5¼-inch
floppies. (Did floppies have error-detecting codes? No idea).

Also, I think without O_DIRECT, you can't actually get a bad block
smaller than Linux's page size of 4k.

So really it seems like -E ought to just skip 4k at once.

Or at least there ought to be an option to specify the skip size. I'd
suggest -E should take an optional argument, the skip size, and default
to 4k.

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

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

Versions of packages pv depends on:
ii  libc6  2.24-3

pv recommends no packages.

Versions of packages pv suggests:
ii  doc-base  0.10.7

- -- no debconf information

-BEGIN PGP SIGNATURE-

iFwEARECABwFAlf0UwcVHGFudGhvbnlAZGVyb2JlcnQubmV0AAoJEPs/iMJV6ln+
uVUAniIVKf8qQWiweAEMRlrXA15iTG5kAJkBhpKsCm0E9hKyNrObR5F/DtQpWg==
=EH8x
-END PGP SIGNATURE-

Bug#838899: xorg: debian 9 Xorg -configure generated xorg.conf breaks lightdm on video-vmware and video-dummy

[Hans Henrik Bergan]

there was recently an update to.. among other things,
xserver-xorg-video-core i believe. in any case, i just did "apt-get update;
apt-get upgrade; apt-get dist-upgrade;" , noticed there was xorg-related
updates, tested again, and xserver-xorg-video-dummy works again now it
seems :)

Bug#839795: FTBFS, needs to be updated for liblognorm v2 and libfastjson

[Michael Biebl]

Source: sagan
Version: 1.0.1-0.3
Severity: serious
Tags: fixed-upstream

liblognorm v2 is based on libfastjson and no longer json-c.

sagan needs to be updated accordingly. The latest upstream release 1.1.2
has support for liblognorm >= 2.0.0 and libfastjson.




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

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

Bug#839687: [Python-modules-team] Bug#839687: how to manage setuptools-scm packages in debian?

[Antoine Beaupré]

On 2016-10-04 16:17:19, Ondrej Novy wrote:
> Hi,
>
> 2016-10-03 23:53 GMT+02:00 Antoine Beaupré :
>
>> Answering my own question (and it would be nice to have this documented
>> somewhere!), the solution is to use a more recent dh-python dependency
>> and depend on python-setuptools-scm explicitely, *and* use
>> --buildsystem=pybuild.
>>
>
> as author of this addon in pybuild: Yes, this is correct. :)
>
>
>> I cargo-culted the  (>= 2.20160609~) dependency from python-keyring, but
>> I don't really know what I am doing.
>>
>
> as author of change in python-keyring: yep >= 2.20160609~ is correct :)
>
> I expected something about this to be documented in a README.Debian
>> file.
>>
>
> in dh-python? Maybe on wiki?

I looked in /usr/share/doc/python-setuptools-scm/ and didn't find a
README. That's where I looked first. I also looked at the pybuild page
here:

https://wiki.debian.org/Python/Pybuild

I didn't look in dh-python's docs.

A.
-- 
Quis custodiet ipsos custodes?
Who watches the watchmen?
Qui police la police?
Tu. You. Toi.

Bug#839794: network-manager: wifi networks not re-scanned after disabling and enabling device

[Mark Hedges]

Package: network-manager
Version: 1.4.0-4
Severity: important

Hi.  I just upgraded stretch and got the new 4.7 kernel.

I have a Thinkpad X1 Carbon.  Fn-F8 is the wifi hardware killswitch.

When I first boot the machine, I see wifi networks in the Network
Manager applet.

If I disable wifi with Fn-F8, and re-enable wifi with Fn-F8, I see no networks.

Before the upgrade, when I re-enabled wifi it would scan available
networks and display them.

Now it displays nothing.  I cannot connect to anything.  I can't
choose any of my saved network connections, either.

It is going to be inconvenient to reboot every time I need to use
wifi.  I prefer to turn the device off when I am not using it.

Maybe the log below is relevant.  I tried disabling and re-enabling
again.  A pending scan from the previous time got stuck?

Is this related to the other bugs about randomly generating the MAC?
How do I turn that off?  I don't need that.  Wouldn't it make me seem
like I am a hostile node, to always be faking my MAC?  The whole
purpose of a MAC address is to have unique identifiers for each
hardware device on a network, so that it isn't likely for two devices
to try to use the same MAC and collide.  Randomly changing the MAC as
a default policy increases the possibility of MAC collisions.

Thanks.
Mark

Oct  4 16:51:22 walnut wpa_supplicant[2659]: rfkill: WLAN soft blocked
Oct  4 16:51:22 walnut wpa_supplicant[2659]: rfkill: WLAN soft blocked
Oct  4 16:51:22 walnut NetworkManager[3952]:   [1475625082.1684]
manager: WiFi now disabled by radio killswitch
Oct  4 16:51:22 walnut wpa_supplicant[2659]: nl80211: deinit
ifname=p2p-dev-wlp4s0 disabled_11b_rates=0
Oct  4 16:51:22 walnut NetworkManager[3952]:   [1475625082.1685]
device (wlp4s0): state change: disconnected -> unavailable (reason
'none') [30 20 0]
Oct  4 16:51:22 walnut systemd[1]: Starting Load/Save RF Kill Switch Status...
Oct  4 16:51:22 walnut systemd[1]: Started Load/Save RF Kill Switch Status.
Oct  4 16:51:22 walnut wpa_supplicant[2659]: nl80211: deinit
ifname=wlp4s0 disabled_11b_rates=0
Oct  4 16:51:31 walnut NetworkManager[3952]:   [1475625091.5192]
manager: WiFi now enabled by radio killswitch
Oct  4 16:51:31 walnut kernel: [ 1102.716085] iwlwifi :04:00.0: L1
Enabled - LTR Enabled
Oct  4 16:51:31 walnut kernel: [ 1102.717372] iwlwifi :04:00.0: L1
Enabled - LTR Enabled
Oct  4 16:51:31 walnut systemd[1]: Starting Load/Save RF Kill Switch Status...
Oct  4 16:51:31 walnut systemd[1]: Started Load/Save RF Kill Switch Status.
Oct  4 16:51:31 walnut kernel: [ 1102.849546] iwlwifi :04:00.0: L1
Enabled - LTR Enabled
Oct  4 16:51:31 walnut kernel: [ 1102.850070] iwlwifi :04:00.0: L1
Enabled - LTR Enabled
Oct  4 16:51:31 walnut kernel: [ 1102.931906] IPv6:
ADDRCONF(NETDEV_UP): wlp4s0: link is not ready
Oct  4 16:51:31 walnut NetworkManager[3952]:   [1475625091.7941]
sup-iface[0x123b6e0,wlp4s0]: supports 5 scan SSIDs
Oct  4 16:51:31 walnut NetworkManager[3952]:   [1475625091.7952]
device (wlp4s0): supplicant interface state: starting -> ready
Oct  4 16:51:31 walnut NetworkManager[3952]:   [1475625091.7953]
device (wlp4s0): state change: unavailable -> disconnected (reason
'supplicant-available') [20 30 42]
Oct  4 16:51:31 walnut kernel: [ 1102.989589] IPv6:
ADDRCONF(NETDEV_UP): wlp4s0: link is not ready
Oct  4 16:51:34 walnut NetworkManager[3952]:   [1475625094.8022]
device (wlp4s0): supplicant interface state: ready -> inactive
Oct  4 16:51:57 walnut NetworkManager[3952]:   [1475625117.8568]
device (wlp4s0): set-hw-addr: set MAC address to EE:B3:9D:D5:69:D6
(scanning)
Oct  4 16:51:57 walnut kernel: [ 1129.063086] IPv6:
ADDRCONF(NETDEV_UP): wlp4s0: link is not ready
Oct  4 16:51:57 walnut NetworkManager[3952]:   [1475625117.8685]
device (wlp4s0): supplicant interface state: inactive -> disabled
Oct  4 16:51:57 walnut NetworkManager[3952]:   [1475625117.8981]
device (wlp4s0): supplicant interface state: disabled -> inactive
Oct  4 16:51:57 walnut wpa_supplicant[2659]: wlp4s0: Reject scan
trigger since one is already pending
ct  4 16:53:34 walnut NetworkManager[3952]:   [1475625214.7814]
device (wlp4s0): supplicant interface state: inactive -> scanning





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

Kernel: Linux 4.7.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 network-manager depends on:
ii  adduser3.115
ii  dbus   1.10.10-1
ii  init-system-helpers1.45
ii  libaudit1  1:2.6.7-1
ii  libbluetooth3  5.36-1+b2
ii  libc6  2.24-3
ii  libglib2.0-0   2.50.0-1
ii  libgnutls303.5.4-2
ii  libgudev-1.0-0 230-3
ii  libmm-glib01.6.2-1
ii  libndp01.6-1
ii  libnewt0.520.52.18-3
ii  libnl-3-200

Bug#839793: Manual page header corrupted

[Anthony DeRobertis]

Package: libcommon-sense-perl
Version: 3.74-1+b3
Severity: minor

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I've confirmed with debsums that the checksum is OK, so this doesn't
appear to be a local issue.

Typing 'man common::sense' gives:

^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^Hlibcommon-sense-perl-3.74::debian::libcommon-sense-perl::usr::lib::x86i64-linux-gnu::perl5::5.24::common::sense(3pm)x-gnu::perl5::5.24::common::sense(3pm)

NAME
   common::sense - save a tree AND a kitten, use common::sense!

Except those ^H are in standout, presumably they're actually control-H.

zless /usr/share/man/man3/common::sense.3pm.gz confirms the title is at
least corrupted:

.IX Title 
"libcommon-sense-perl-3.74::debian::libcommon-sense-perl::usr::lib::x86_64-linux-gnu::perl5::5.24::common::sense
 3pm"
.TH 
libcommon-sense-perl-3.74::debian::libcommon-sense-perl::usr::lib::x86_64-linux-gnu::perl5::5.24::common::sense
 3pm "2015-08-19" "perl v5.24.1" "User Contributed Perl Documentation"

And debsums is OK:

$ debsums libcommon-sense-perl
/usr/lib/x86_64-linux-gnu/perl5/5.24/common/sense.pm  OK
/usr/lib/x86_64-linux-gnu/perl5/5.24/common/sense.pod OK
/usr/share/doc/libcommon-sense-perl/changelog.Debian.amd64.gz OK
/usr/share/doc/libcommon-sense-perl/changelog.Debian.gz   OK
/usr/share/doc/libcommon-sense-perl/changelog.gz  OK
/usr/share/doc/libcommon-sense-perl/copyright OK
/usr/share/lintian/overrides/libcommon-sense-perl OK
/usr/share/man/man3/common::sense.3pm.gz  OK


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

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

Versions of packages libcommon-sense-perl depends on:
ii  perl5.24.1~rc3-3
ii  perl-base [perlapi-5.24.1]  5.24.1~rc3-3

libcommon-sense-perl recommends no packages.

libcommon-sense-perl suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iFwEARECABwFAlf0RHkVHGFudGhvbnlAZGVyb2JlcnQubmV0AAoJEPs/iMJV6ln+
XJIAn2EDjU4xyyMLRadaoC0FrCI+rcqNAJoCQ+kvvGcT5CyRQEFuojnVofD47A==
=3buB
-END PGP SIGNATURE-

Bug#782654: Bug#838416: ITP: bazel -- Fast and correct automated build system by Google

[Kyle Moffett]

On Mon, Oct 3, 2016 at 9:29 AM, Chris Lamb  wrote:
> > Also, I would be pretty keen on seeing roughtime packaged
> > in Debian, so don't hesitate to ping me in you need a
> > co-maintainer.
>
> Well, if you could package Bazel… :)

Unfortunately, there's more work than just "packaging" Bazel.  Just to
package Bazel, the open issues are:
  (1) Getting Bazel's dependencies packaged in Debian, with acceptable versions.
  (2) Fixing the Bazel build process to use Debian JAR files, rather
than pre-built versions shipped with Bazel.
  (3) Fixing the Bazel build process to comply with Debian policy
around static linking and self-extracting binaries.

But... even with that, Bazel cannot be used to _build_ a Debian
package, because it does not create Debian-policy-compliant binaries,
and it does not support all the Debian cross-compiler flags.  In order
to fix that, a bunch more integration work is needed, including
rewriting the Bazel "architecture specs" to use Debian architecture
names or tuples instead, and to fix the built-in rules to properly
support fully-dynamic linking and library installation paths.

So, yeah, it's a lot of work, and I haven't really had time to make
much progress.

Cheers,
Kyle Moffett

Bug#817296: gnudoq: Removal of debhelper compat 4

[Markus Koschany]

Control: tags -1 pending

On Wed, 09 Mar 2016 21:10:35 +0100 ni...@thykier.net wrote:
> Source: gnudoq
> Severity: important
> Usertags: compat-4-removal
> 
> Hi,
> 
> The package gnudoq uses debhelper with a compat level of 4,
> which is deprecated and scheduled for removal.

[...]

Dear maintainer,

I've uploaded an NMU for gnudoq versioned as 0.94-2.2. Please find
attached the debdiff.

Regards,

Markus
diff -Nru gnudoq-0.94/debian/changelog gnudoq-0.94/debian/changelog
--- gnudoq-0.94/debian/changelog2016-10-05 01:17:56.0 +0200
+++ gnudoq-0.94/debian/changelog2016-10-05 01:10:03.0 +0200
@@ -1,9 +1,22 @@
+gnudoq (0.94-2.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Switch to source format 3.0 (quilt).
+  * Switch to compat level 10. (Closes: #817484)
+  * Remove dh_desktop because it does nothing anymore. (Closes: #817296)
+  * Remove duplicate Section field from binary package.
+  * d/control: Add ${misc:Depends} substvar.
+  * gnudoq.desktop: Create a valid desktop file.
+  * gnudoq.desktop: Change GenericName to Sudoku. (Closes: #743468)
+
+ -- Markus Koschany   Wed, 05 Oct 2016 01:10:03 +0200
+
 gnudoq (0.94-2.1) unstable; urgency=low
 
   * Non-maintainer upload.
   * Add fix-643396-format-security.patch. Fix FTBFS: error: format not a
 string literal and no format arguments [-Werror=format-security].
-(Closes: #643396). 
+(Closes: #643396).
 
  -- Salvatore Bonaccorso   Fri, 25 Nov 2011 18:50:05 +0100
 
@@ -51,7 +64,7 @@
 
 gnudoq (0.93.dfsg.1-2) unstable; urgency=low
 
-  * Fix to build against lates libqt4 (Closes: #355932). 
+  * Fix to build against lates libqt4 (Closes: #355932).
 
  -- Arnaud Cornet   Thu,  9 Mar 2006 11:11:00 +0100
 
diff -Nru gnudoq-0.94/debian/compat gnudoq-0.94/debian/compat
--- gnudoq-0.94/debian/compat   2016-10-05 01:17:56.0 +0200
+++ gnudoq-0.94/debian/compat   2016-10-05 01:10:03.0 +0200
@@ -1 +1 @@
-4
+10
diff -Nru gnudoq-0.94/debian/control gnudoq-0.94/debian/control
--- gnudoq-0.94/debian/control  2016-10-05 01:17:56.0 +0200
+++ gnudoq-0.94/debian/control  2016-10-05 01:10:03.0 +0200
@@ -3,13 +3,12 @@
 Priority: optional
 Maintainer: Arnaud Cornet 
 Standards-Version: 3.7.3
-Build-Depends: cdbs, libqt4-dev, qt4-dev-tools, g++ (>= 4.0.2-2), debhelper 
(>= 5.0.37), quilt
+Build-Depends: cdbs, libqt4-dev, qt4-dev-tools, g++ (>= 4.0.2-2), debhelper 
(>= 10)
 Homepage: http://www.thelemmings.net/static.php?page=GNUDoQ
 
 Package: gnudoq
 Architecture: any
-Section: games
-Depends: ${shlibs:Depends}
+Depends: ${shlibs:Depends}, ${misc:Depends}
 Description: An open source, graphical Su Doku generator and solver with 
printer support
  GNUDoQ is an open source, graphical Su Doku generator and solver that features
  a powerful Su Doku generator, a Su Doku solver a Puzzle printouts or PDF
diff -Nru gnudoq-0.94/debian/gnudoq.desktop gnudoq-0.94/debian/gnudoq.desktop
--- gnudoq-0.94/debian/gnudoq.desktop   2016-10-05 01:17:56.0 +0200
+++ gnudoq-0.94/debian/gnudoq.desktop   2016-10-05 01:10:03.0 +0200
@@ -1,10 +1,10 @@
 [Desktop Entry]
-Encoding=UTF-8
 Name=GNUDoQ
-GenericName=Board Game
+GenericName=Sudoku
 Type=Application
-Categories=Application;Game;BoardGame;
-Terminal=0
+Categories=Game;BoardGame;
 Exec=gnudoq
-Icon=/usr/share/pixmaps/gnudoq-icon.xpm
+Icon=gnudoq-icon
 Comment=GNUDoQ, Su Doku generator and solver.
+Comment[de]=GNUDoQ, ein Sudokugenerator und -löser
+Keywords=sudoku;logic;puzzle;
diff -Nru gnudoq-0.94/debian/rules gnudoq-0.94/debian/rules
--- gnudoq-0.94/debian/rules2016-10-05 01:17:56.0 +0200
+++ gnudoq-0.94/debian/rules2016-10-05 01:10:03.0 +0200
@@ -2,10 +2,6 @@
 
 include /usr/share/cdbs/1/rules/debhelper.mk
 include /usr/share/cdbs/1/class/qmake.mk
-include /usr/share/cdbs/1/rules/patchsys-quilt.mk
 
 QMAKE=qmake-qt4
 
-binary-install::
-   dh_desktop -pgnudoq
-
diff -Nru gnudoq-0.94/debian/source/format gnudoq-0.94/debian/source/format
--- gnudoq-0.94/debian/source/format1970-01-01 01:00:00.0 +0100
+++ gnudoq-0.94/debian/source/format2016-10-05 01:10:03.0 +0200
@@ -0,0 +1 @@
+3.0 (quilt)


signature.asc
Description: OpenPGP digital signature

Bug#839783: Please package Emacs 25.1

[John Zaitseff]

Hi,

> > Emacs 25.1 has been out for almost a month now (it was released
> > 17th September 2016).  Could you please package this new version
> > for Debian?
>
> Yep - been working on it, and should be finished soon.  The DFSG
> split makes the process a little more work than you might
> otherwise expect.

Looking forward to it, particularly if it can then be backported to
Jessie without too much effort!

John

-- 
John Zaitseff,--_|\The ZAP Group
Phone:  +61 2 9643 7737 /  \   Sydney, Australia
E-mail: j.zaits...@zap.org.au   \_,--._*   http://www.zap.org.au/
  v

Bug#839594: More concise write-up of the issue

[William L. DeRieux IV]

--
In libsysinfo-0.2.2/Linux/sysinfo_linux.c fucntion get_mem_size(void):
--
long long get_mem_size(void) {

long long mem_size=0;

   /* First try any arch-specific memsize functions */
mem_size=get_arch_specific_mem_size();
if (mem_size == MEM_USE_MEMINFO) {
   mem_size = 0;
   goto use_meminfo;
}

if (mem_size == MEM_USE_SYSINFO) {
   mem_size = 0;
   goto use_sysinfo;
}

   /* Next try the 2.4.x+ method of iomem */
if (mem_size == 0) mem_size = get_mem_size_iomem();

   /* Try stat-ing /proc/kcore */
if (mem_size == 0) mem_size = get_mem_size_stat();

use_sysinfo:

   /* sysinfo should return same as /proc/meminfo */
   /* which, sadly, is often from 1MB-20MB off*/
if (mem_size == 0) mem_size = get_mem_size_sysinfo();

use_meminfo:
   /* If all else fails, try using /proc/meminfo */
if (mem_size == 0) mem_size = get_mem_size_meminfo();

return mem_size;
}
--
1) a call is made to get_arch_specific_mem_size()
 -- this will either return 0, MEM_USE_MEMINFO, or MEM_USE_SYSINFO.
 -- certain cpu_archs will return 0 (such as x86/x86_64)

2) if the return value is 0 it will call get_mem_size_iomem() [otherwise 
it will call get_mem_size_meminfo() or get_mem_size_sysinfo as appropriate]
 -- if not run as root the return value will always be 0 (or the system 
memsize, if run as root)


3) if the return value of iomem was 0 (and it will be, again without root)
   a call is made to get_mem_size_stat() reading from /proc/kcore -- 
currently this returns 128TB


   $ sudo file /proc/kcore
 /proc/kcore: ELF 64-bit LSB core file x86-64, version 1 (SYSV), 
SVR4-style, from 'BOOT_IMAGE=/boot/vmlinuz-4.7.0-1-amd64 
root=UUID=8d8c2528-acc4-47a8-b815-967b59'


   $ sudo ls -lh /proc/kcore
 -r 1 root root 128T Oct  3 21:30 /proc/kcore

   Note that /proc/kcore cannot be relied upon because it is a mapping 
of the maximum amount of memory that the kernel can allocate and

   not how much ram is actually installed (at least not for 64-bit cpus)
--

The usefulness of these memory function(s):
1) get_mem_size_meminfo() and get_mem_size_sysinfo() -- are unreliable 
they will report less RAM than is actually installed
2) get_mem_size_stat() -- /proc/kcore unreliable on 64bit cpus (maybe 
even 32bit if less ram is installed than the 32bit max)
3) get_mem_size_iomem() -- fairly reliable in all cases, but requires 
root privs to read


--

The only reliable memory function is get_mem_size_iomem(), but -- in my 
opinion -- requiring linuxlogo to be executed as root is unnecessary and 
unacceptable.


As as result my recommendation would be to remove the feature altogether.

Bug#801366: ITP: jupyter-notebook -- Jupyter interactive notebook: libjs-jquery-typeahead

[Jerome BENOIT]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hello Gordon,

I can see that your package libjs-jquery-typeahead [1] is ready; I mean,
I can git-buildpackage it in a schroot environment (but I can hardly say more).

Please, can you bring it to Debian ASAP ?

Thanks in advance,
Jerome


[1] https://git.chronitis.net/jquery-typeahead.js/

- -- 
Jerome BENOIT | calculus+at-rezozer^dot*net
https://qa.debian.org/developer.php?login=calcu...@rezozer.net
AE28 AE15 710D FF1D 87E5  A762 3F92 19A6 7F36 C68B
-BEGIN PGP SIGNATURE-

iQQcBAEBCgAGBQJX9DeyAAoJED+SGaZ/NsaLsjsgAJl3oXs7g/i5kk9KRsTz7gf+
OaZwRajMfSatWYpbp6JGk5vvWHnR8LBILlWMfS+3AYWJKq/5hUR/450asamzuLcf
PpAVRXYjGzoYi5ewpNZJpinZ6SsGR141YOSzC5WbDuDwIBBZ5nDpYgaFLry9gem9
EeF1z5woXwBIO+6JyRt2IlH6Jx//HN1k/xx5dUpwXvBjjdX8FkyYhBZ114fUTgAA
/sFRv6M8gR3XjjACOFFcl/GAaCqX6YMP9yLfPSb6yzUgN9A63l5FUoU8jJx3GIq0
ONSjvglzAeXsMcaSx5dX4OYjWdCL0gD7LDgsMKzUIE9FMTO1owIjwuUCgzj78hJj
HNkuGOzaF/EI9g305zsld2Ew7kOIA9hgTIc102L4RhvlnW7w83SHFjIxjQrjMxsM
b912DbgzRrl3xf8HOl1zHcOHklMzrht1+AYIXOa2ev7C/35FhdyO3QmEIPe1gkfW
b/VsX0S8rULKVvPdkxdJ37zCoCa9UaW1W5FvbM0aVkugzsCl8i/8IdqNL6Fd+oNS
9+1VMCjJMjzVygb2LuKJkqzr7sAzOwumXimGWtyja7m7P2PPz5xk/3YjzGi90sAR
AcapF34qFXaS3F72OJGDRNHoyoa93n/ECH9zCgncpRfsqpiUCy5o5HS3ca0rvbt2
1ZIaJbvMLPmX3EPZWdmZfqKvw+TK1mGs8cmQlHSSB7af8/ngWW6v09tEK6JKiBOi
mERdDkwZGUua6v58RneSRIw+opEyW9v7pGxNsIXc26YqB797QPunE4reNfXa21tC
WPdBHDU/zAEZhyRAYShsXB5FqcIhhRBXizzcd5B7la0gjZ8Xuc7gPWgxw2WLznUE
5qZIeC9sYoT1XiBfUGu1fgknLoWxB1h7ti66C5DNgsEktKXVQzgtQmmjG+0OJHbO
BbsX9tTnHkjyDGsCiKuoUqrwgTHxr8VzzoNlH1+j+v5CW7Q7Eyu9wILPk8uqA16k
DOLOHBISvuxtDX2Yyu2kCaDF+DehKxGZeH527hzaQfvrdZGtFh2KPqX6WZDssfB3
g4juI68Jp27Ps2gNwGyxOsrcZ4dfh7a2VYCPoWxwsNUElrXLq3B23gyISd0NNCn9
g0wzkYjRAfbBIPi2ixJejVztww0LdD8K7zpmCNBUk5lo0aF5dRu18HKLls49fpQJ
W/voEpNoiLHQg0GIV3a/atgxckPWp9FK3qMF1q1CTYUZu+dBGYpSbRyIvrO+QAr+
S86oE7P8jl1ot0ylK10E4ITvU98vwa6kiMUPrkx9LfhSzbjERGmL4AbIeg+cMRK7
F50cry6p236buozdNQIAW9lbzs8z1IVQHMTJZb1xdww0ZWhNPu9g64deHrIRKaU=
=xeUk
-END PGP SIGNATURE-

Bug#832584: Fix build on sparc64

[John Paul Adrian Glaubitz]

Hi Kurt!

On 07/27/2016 11:10 AM, James Clarke wrote:
> Please add gcc-multilib and libc6-dbg as Build-Depends on sparc64. With
> them, the package builds successfully.

Is there a reason why this particular bug hasn't been fixed yet?

It would be good to have this fixed rather soonish since we are currently 
working
on making sparc64 a release architecture in Debian and we need to reduce the 
number
of sparc64-related bugs as much as possible.

I'd be happy to perform an NMU for this particular bug. It's basically just a 
matter
of fixing debian/control, so it can be done within a few minutes.

Thanks,
Adrian

-- 
 .''`.  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



signature.asc
Description: OpenPGP digital signature

Bug#839033: RM: llvm-toolchain-snapshot [armel mips64el] -- RoQA; FTBFS, outdated snapshot

[Emilio Pozuelo Monfort]

On Wed, 28 Sep 2016 01:33:20 +0200 Andreas Beckmann  wrote:
> Package: ftp.debian.org
> Severity: normal
> 
> Hi,
> 
> llvm-toolchain-snapshot is at version 4.0~svn... now, but due to FTBFS
> armel still has 3.8 binaries left. Packages picking these up during
> build may have problems migrating to testing ... and may need removal on
> armel, too.
> On mips64el there is no current build either, but only a few cruft
> packages are left.
> 
> There is also more cruft left from llvm-toolchain-snapshot 3.7, but I'm
> not sure how to properly request decrufting in this case:
> 
> clang-3.7-doc | 1:3.7~svn230892-1 | all
> liblldb-3.7 | 1:3.7~svn230892-1 | powerpc
> liblldb-3.7-dev | 1:3.7~svn230892-1 | powerpc
> lldb-3.7 | 1:3.7~svn230892-1 | powerpc
> lldb-3.7-dev | 1:3.7~svn230892-1 | all
> llvm-3.7-doc | 1:3.7~svn230892-1 | all
> llvm-3.7-examples | 1:3.7~svn230892-1 | all
> llvm-toolchain-snapshot | 1:3.7~svn230892-1 | source

The armel binaries are:

>From src:llvm-toolchain-snapshot: clang-3.8  clang-3.8-examples
clang-format-3.8  clang-modernize-3.8  cpp11-migrate-3.8  libclang-3.8-dev
libclang-common-3.8-dev  libclang1-3.8  libclang1-3.8-dbg  liblldb-3.8
liblldb-3.8-dbg  liblldb-3.8-dev  libllvm-3.8-ocaml-dev  libllvm3.8
libllvm3.8-dbg  lldb-3.8  llvm-3.8  llvm-3.8-dev  llvm-3.8-runtime
llvm-3.8-tools  python-clang-3.8  python-lldb-3.8

>From src:llvm-defaults: llvm  llvm-runtime  llvm-dev  libllvm-ocaml-dev  clang
clang-modernize  clang-tidy  clang-format  libclang1  libclang-dev  lldb

Other rdeps: gnome-builder  emscripten  qtcreator

For gnome-builder, I have dropped the clang support on armel in $VCS. Should be
uploaded soon.

For qtcreator, I have filed #839791.

As for the rest:

emilio@tatooine:~$ dak rm -Rn -a armel -b clang-3.8  clang-3.8-examples
clang-format-3.8  clang-modernize-3.8  cpp11-migrate-3.8  libclang-3.8-dev
libclang-common-3.8-dev  libclang1-3.8  libclang1-3.8-dbg  liblldb-3.8
liblldb-3.8-dbg  liblldb-3.8-dev  libllvm-3.8-ocaml-dev  libllvm3.8
libllvm3.8-dbg  lldb-3.8  llvm-3.8  llvm-3.8-dev  llvm-3.8-runtime
llvm-3.8-tools  python-clang-3.8  python-lldb-3.8  llvm  llvm-runtime  llvm-dev
libllvm-ocaml-dev  clang  clang-modernize  clang-tidy  clang-format  libclang1
libclang-dev  lldb  emscripten
W: -a/--architecture implies -p/--partial.
Will remove the following packages from unstable:

 clang |   1:3.8-34 | armel
 clang-3.8 | 1:3.8~svn247576-1 | armel
clang-3.8-examples | 1:3.8~svn247576-1 | armel
clang-format |   1:3.8-34 | armel
clang-format-3.8 | 1:3.8~svn247576-1 | armel
clang-modernize-3.8 | 1:3.8~svn247576-1 | armel
clang-tidy |   1:3.8-34 | armel
cpp11-migrate-3.8 | 1:3.8~svn247576-1 | armel
emscripten |   1.22.1-1 | armel
libclang-3.8-dev | 1:3.8~svn247576-1 | armel
libclang-common-3.8-dev | 1:3.8~svn247576-1 | armel
libclang-dev |   1:3.8-34 | armel
 libclang1 |   1:3.8-34 | armel
libclang1-3.8 | 1:3.8~svn247576-1 | armel
libclang1-3.8-dbg | 1:3.8~svn247576-1 | armel
liblldb-3.8 | 1:3.8~svn247576-1 | armel
liblldb-3.8-dbg | 1:3.8~svn247576-1 | armel
liblldb-3.8-dev | 1:3.8~svn247576-1 | armel
libllvm-3.8-ocaml-dev | 1:3.8~svn247576-1 | armel
libllvm-ocaml-dev |   1:3.8-34 | armel
libllvm3.8 | 1:3.8~svn247576-1 | armel
libllvm3.8-dbg | 1:3.8~svn247576-1 | armel
  lldb |   1:3.8-34 | armel
  lldb-3.8 | 1:3.8~svn247576-1 | armel
  llvm |   1:3.8-34 | armel
  llvm-3.8 | 1:3.8~svn247576-1 | armel
llvm-3.8-dev | 1:3.8~svn247576-1 | armel
llvm-3.8-runtime | 1:3.8~svn247576-1 | armel
llvm-3.8-tools | 1:3.8~svn247576-1 | armel
  llvm-dev |   1:3.8-34 | armel
llvm-runtime |   1:3.8-34 | armel
python-clang-3.8 | 1:3.8~svn247576-1 | armel
python-lldb-3.8 | 1:3.8~svn247576-1 | armel

Maintainer: LLVM Packaging Team 

--- Reason ---

--

Checking reverse dependencies...
# Broken Depends:
gnome-builder: gnome-builder
libclc: libclc-amdgcn
libclc-ptx
libclc-r600
llvm-toolchain-snapshot: lldb-3.8-dev
 llvm-3.8-examples
qtcreator: qtcreator

# Broken Build-Depends:
alberta: clang
beignet: clang-3.8
 libclang-3.8-dev
 llvm-3.8-dev
castxml: libclang-3.8-dev
 llvm-3.8-dev
clamav: llvm-dev
codelite: libclang-3.8-dev
  liblldb-3.8-dev
  llvm-3.8
diffoscope: llvm
freemat: libclang-dev
 llvm-dev
gnome-builder: libclang-dev
   llvm
hedgewars: clang
httping: clang
irony-mode: libclang-dev
iwyu: libclang-3.8-dev
  llvm-3.8-dev
kdevelop: libclang-3.8-dev (>= 1:3.8.1)
  llvm-3.8-dev (>= 1:3.8.1)
ldc: llvm-3.8-dev
libblocksruntime: clang
libc++: clang
libclang-perl: libclang-dev
   llvm
libclc: clang-3.8
llvm-3.8-dev
libdispatch: clang (>= 2.8)
lightspark: llvm-dev (>= 1:3.3)
llvm-defaults: libllvm-3.8-ocaml-dev
   llvm-3.8-dev
mesa: libclang-3.8-dev (>= 1:3.8)
  llvm-3.8-dev (>= 1:3.8)
pocl: clang-3.8
  

Bug#839790: monkeysphere: FTBFS (failing tests)

[Santiago Vila]

Package: src:monkeysphere
Version: 0.39-1
Severity: serious

Dear maintainer:

I tried to build this package in stretch with "dpkg-buildpackage -A"
(which is what the "Arch: all" autobuilder would do to build it)
but it failed:


[...]
 debian/rules build-indep
dh build-indep
   dh_testdir -i
   dh_update_autotools_config -i
   dh_auto_configure -i
   dh_auto_build -i
make -j1
make[1]: Entering directory '/<>'
gcc -o src/agent-transfer/agent-transfer -g -O2 
-fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security  -lassuan -L/usr/lib/x86_64-linux-gnu -lgpg-error  
-lgcrypt --pedantic -Wall -Werror -std=c99 -Wl,-z,relro 
src/agent-transfer/main.c
make[1]: Leaving directory '/<>'
   dh_auto_test -i
make -j1 test
make[1]: Entering directory '/<>'
MONKEYSPHERE_TEST_NO_EXAMINE=true ./tests/keytrans
##
### generating openpgp key...
gpg: keybox '/<>/tests/tmp/ms.Zon/pubring.kbx' created
gpg: /<>/tests/tmp/ms.Zon/trustdb.gpg: trustdb created
gpg: key AC90591EE638015A marked as ultimately trusted
gpg: directory '/<>/tests/tmp/ms.Zon/openpgp-revocs.d' created
gpg: revocation certificate stored as 
'/<>/tests/tmp/ms.Zon/openpgp-revocs.d/D56C1E5D05F4EB8DE961EE8AAC90591EE638015A.rev'
gpg: done
##
### retrieving key timestamp...
gpg: checking the trustdb
gpg: marginals needed: 3  completes needed: 1  trust model: pgp
gpg: depth: 0  valid:   1  signed:   0  trust: 0-, 0q, 0n, 0m, 0f, 1u
##
### exporting key to ssh file...
##
### reconvert key, and compare to key in gpg keyring...
conversions look good!
Now working with key AC90591EE638015A at time 1475603896
gpg: marginals needed: 3  completes needed: 1  trust model: pgp
gpg: depth: 0  valid:   1  signed:   0  trust: 0-, 0q, 0n, 0m, 0f, 1u
/<>/tests/tmp/ms.Zon/pubring.kbx
-
pub   rsa1024 2016-10-04 [SC]
  D56C1E5D05F4EB8DE961EE8AAC90591EE638015A
uid   [ultimate] testtest

##
### test User ID addition...
gpg: key AC90591EE638015A: "monkeymonkey" 1 new user ID
gpg: key AC90591EE638015A: "monkeymonkey" 1 new signature
gpg: Total number processed: 1
gpg:   new user IDs: 1
gpg: new signatures: 1
gpg: marginals needed: 3  completes needed: 1  trust model: pgp
gpg: depth: 0  valid:   1  signed:   0  trust: 0-, 0q, 0n, 0m, 0f, 1u
/<>/tests/tmp/ms.Zon/pubring.kbx
-
pub   rsa1024 2016-10-04 [SC]
  D56C1E5D05F4EB8DE961EE8AAC90591EE638015A
uid   [ultimate] monkeymonkey
uid   [ultimate] testtest

--- /<>/tests/tmp/ms.Zon/expectedout   2016-10-04 
19:58:18.124385554 +0200
+++ /dev/fd/63  2016-10-04 19:58:18.124385554 +0200
@@ -1,4 +1,5 @@
 pub:u:1024:1:AC90591EE638015A:1475603896:::u:::scSC
+fpr:D56C1E5D05F4EB8DE961EE8AAC90591EE638015A
 uid:u1475603896::E90EC72E68C6C2A0751DADC70F54F60D27B88C3D::monkeymonkey
 sig:!::1:AC90591EE638015A:1475603896monkeymonkey:13x:8
 uid:u1475603896::8200BD0425CC70C7D698DF3FE412044EAAB83F94::testtest
FAILED!
### removing temp dir...
Makefile:117: recipe for target 'test-keytrans' failed
make[1]: *** [test-keytrans] Error 1
make[1]: Leaving directory '/<>'
dh_auto_test: make -j1 test returned exit code 2
debian/rules:3: recipe for target 'build-indep' failed
make: *** [build-indep] Error 2
dpkg-buildpackage: error: debian/rules build-indep gave error exit status 2


The relevant part of the build log is included above.

Apparently, this failure does not seem related to the (not finished yet) gnupg
transition, because it also happens in unstable:

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/monkeysphere.html

Thanks.

Bug#839791: qtcreator: builds with clang support on armel

[Emilio Pozuelo Monfort]

Source: qtcreator
Version: 4.1.0-1
Severity: serious

Hi!

qtcreator builds with LLVM 3.8 on armel, however LLVM 3.8 is not
available there. (Well, there is an old version still in the archive,
built from a snapshot from llvm-toolchain-snapshot, which hasn't been
removed yet, that will happen soon in #839033.

Note this is blocking testing migration:

qtcreator (4.0.3-1 to 4.1.0-1)
Maintainer: Debian Qt/KDE Maintainers
26 days old (needed 5 days)
Invalidated by dependency
Depends: qtcreator llvm-toolchain-snapshot (not considered)
Not considered

So please, drop the clang support on armel, so that your package can migrate
and so that we can drop the old llvm binaries.

FWIW, I'm doing the same thing in gnome-builder.

Thanks,
Emilio

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

Kernel: Linux 4.7.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)

Bug#828097: Possible to keep old tidy?

[Adrian Bunk]

On Wed, Oct 05, 2016 at 01:17:28AM +0300, Adrian Bunk wrote:
> On Tue, Oct 04, 2016 at 09:21:00PM +, Gianfranco Costamagna wrote:
> > Hi,
> > (not sure why this bug is still open)
> > 
> > 
> > >The upgrade of tidy to the newer version breaks what MediaWiki expects
> > >(see test failures:
> > >),
>...

Looking at the log again, are there any actual semantic changes in the 
output of the different tidy versions that affect MediaWiki?

This looks like testcase failures due to different indentation,
not like something that would make any difference at all when
viewed with a browser.

cu
Adrian

-- 

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

Bug#834081: FTBFS on various architectures, test suite times out

[Michael Biebl]

Hi Pierre!

On Fri, 12 Aug 2016 09:31:53 +0200 Michael Biebl  wrote:
> Source: liblognorm
> Version: 2.0.1-1
> Severity: serious
> 
> Hi,
> 
> as can be seen on [1], the liblognorm package FTBFS on arm64, ppc64el
> and s390x (some archs are still building and might be affected as well).
> 
> In all cases the build was killed after 150min due to inactivity when
> trying to build the test suite.
> 
> 
> [1] https://buildd.debian.org/status/package.php?p=liblognorm=unstable

Since I haven't heard back from you regarding #834121 and #834081 and
this was blocking rsyslog from entering testing, I've made an NMU fixing
both issues. The debdiff is attached.

I've also forwarded the patch for this issue upstream, so it should
hopefully be merged for the next upstream release.

Cheers,
Michael


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
diff -Nru liblognorm-2.0.1/debian/changelog liblognorm-2.0.1/debian/changelog
--- liblognorm-2.0.1/debian/changelog   2016-08-09 09:41:20.0 +0200
+++ liblognorm-2.0.1/debian/changelog   2016-10-05 00:36:31.0 +0200
@@ -1,3 +1,14 @@
+liblognorm (2.0.1-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix infinite loop in lognormalizer's read_line() function due to incorrect
+use of fgetc(). (Closes: #834121)
+  * Fix misleading indentation warnings with GCC6.
+  * Fix dependencies of liblognorm-dev which requires libfastjson-dev instead
+of libjson-c-dev. (Closes: #834081)
+
+ -- Michael Biebl   Wed, 05 Oct 2016 00:36:31 +0200
+
 liblognorm (2.0.1-1) unstable; urgency=medium
 
   [ Pierre Chifflier ]
diff -Nru liblognorm-2.0.1/debian/control liblognorm-2.0.1/debian/control
--- liblognorm-2.0.1/debian/control 2016-08-09 09:41:20.0 +0200
+++ liblognorm-2.0.1/debian/control 2016-10-05 00:36:31.0 +0200
@@ -21,7 +21,7 @@
 Depends: liblognorm5 (= ${binary:Version}),
 ${misc:Depends},
 ${sphinxdoc:Depends},
-libjson-c-dev,
+libfastjson-dev,
 libestr-dev
 Multi-Arch: foreign
 Description: log normalizing library - development files
diff -Nru 
liblognorm-2.0.1/debian/patches/0001-fix-infinite-loop-in-read_line.patch 
liblognorm-2.0.1/debian/patches/0001-fix-infinite-loop-in-read_line.patch
--- liblognorm-2.0.1/debian/patches/0001-fix-infinite-loop-in-read_line.patch   
1970-01-01 01:00:00.0 +0100
+++ liblognorm-2.0.1/debian/patches/0001-fix-infinite-loop-in-read_line.patch   
2016-10-05 00:36:02.0 +0200
@@ -0,0 +1,40 @@
+From 09838dec129e1d006d4e911c86f077204f50f54a Mon Sep 17 00:00:00 2001
+From: Michael Biebl 
+Date: Wed, 5 Oct 2016 00:18:17 +0200
+Subject: [PATCH 1/3] fix infinite loop in read_line()
+
+fgetc returns an int and we were using char to store the result. This is
+not safe on certain architectures. As a result, the loop in
+lognormalizer's read_line() function never finished.
+
+GCC complained about this issue:
+
+lognormalizer.c: In function 'read_line':
+lognormalizer.c:185:10: warning: comparison is always false due to limited 
range of data type [-Wtype-limits]
+   if (ch == EOF) break;
+  ^~
+
+Fix this by using type int instead of char.
+
+Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=834121
+Fixes: #217
+---
+ src/lognormalizer.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/src/lognormalizer.c b/src/lognormalizer.c
+index cdf9204..10e3ba8 100644
+--- a/src/lognormalizer.c
 b/src/lognormalizer.c
+@@ -179,7 +179,7 @@ read_line(FILE *fp)
+   size_t line_capacity = DEFAULT_LINE_SIZE;
+   char *line = NULL;
+   size_t line_len = 0;
+-  char ch = 0;
++  int ch = 0;
+   do {
+   ch = fgetc(fp);
+   if (ch == EOF) break;
+-- 
+2.9.3
+
diff -Nru 
liblognorm-2.0.1/debian/patches/0002-use-proper-type-for-OffsetHour-in-ln_parseRFC5424Dat.patch
 
liblognorm-2.0.1/debian/patches/0002-use-proper-type-for-OffsetHour-in-ln_parseRFC5424Dat.patch
--- 
liblognorm-2.0.1/debian/patches/0002-use-proper-type-for-OffsetHour-in-ln_parseRFC5424Dat.patch
 1970-01-01 01:00:00.0 +0100
+++ 
liblognorm-2.0.1/debian/patches/0002-use-proper-type-for-OffsetHour-in-ln_parseRFC5424Dat.patch
 2016-10-05 00:36:02.0 +0200
@@ -0,0 +1,52 @@
+From c65023ef46cbfb4cd3f4c177a479d70e39bcd4b2 Mon Sep 17 00:00:00 2001
+From: Michael Biebl 
+Date: Wed, 5 Oct 2016 00:23:38 +0200
+Subject: [PATCH 2/3] use proper type for OffsetHour in ln_parseRFC5424Date()
+
+GCC spotted the following errors:
+
+v1_parser.c: In function 'ln_parseRFC5424Date':
+v1_parser.c:266:17: warning: comparison is always false due to limited range 
of data type [-Wtype-limits]
+   if(OffsetHour < 0 || OffsetHour > 23)
+ ^
+
+parser.c: In function 'ln_v2_parseRFC5424Date':
+parser.c:227:17: warning: comparison is always false due to limited range of 
data type [-Wtype-limits]

Bug#839789: loganalyzer: update for syntax removals in PHP7.0

[Nishanth Aravamudan]

Package: loganalyzer
Version: 3.6.6+dfsg-3
Severity: important
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu yakkety ubuntu-patch

Dear Maintainer,

In Ubuntu, the attached patch was applied to achieve the following:

  * debian/patches/update_for_php7_removals.patch: PHP7.0 has removed
same-named constructors and the \e modifier to preg_replace.  Closes
LP: #1575543.

Thanks for considering the patch.

*** /tmp/tmpms9N8N/loganalyzer_3.6.6+dfsg-3ubuntu1.debdiff
diff -Nru loganalyzer-3.6.6+dfsg/debian/patches/series 
loganalyzer-3.6.6+dfsg/debian/patches/series
--- loganalyzer-3.6.6+dfsg/debian/patches/series2016-05-22 
01:05:53.0 -0700
+++ loganalyzer-3.6.6+dfsg/debian/patches/series2016-10-04 
15:13:22.0 -0700
@@ -1 +1,2 @@
 01-remove-tracking-image.patch
+update_for_php7_removals.patch
diff -Nru loganalyzer-3.6.6+dfsg/debian/patches/update_for_php7_removals.patch 
loganalyzer-3.6.6+dfsg/debian/patches/update_for_php7_removals.patch
--- loganalyzer-3.6.6+dfsg/debian/patches/update_for_php7_removals.patch
1969-12-31 16:00:00.0 -0800
+++ loganalyzer-3.6.6+dfsg/debian/patches/update_for_php7_removals.patch
2016-10-04 15:13:31.0 -0700
@@ -0,0 +1,68 @@
+Description: PHP7.0 has removed same-named constructors and the \e modifier to 
preg_replace
+Author: Nishanth Aravamudan 
+Bug: https://github.com/rsyslog/loganalyzer/issues/14
+Bug-Ubuntu: https://launchpad.net/bugs/1575543
+
+--- a/src/classes/class_template.php
 b/src/classes/class_template.php
+@@ -59,7 +59,7 @@
+   var $extension  = '';
+   var $template,  $vars,  $page;
+ 
+-  function Template ($fname = '') {
++  function __construct ($fname = '') {
+   if ($fname)
+   $this->filename  =  $fname;
+   }
+@@ -200,7 +200,7 @@
+   $template = 
str_replace('{'.$k.'}',  "$v",  $template);
+ 
+   // Replace variables with 
options, use Callback function!
+-  $template = preg_replace( 
'/{'.$k.':(.*?):(.*?)}/ie', 'InsertTemplateVariable("$v", "\\1", "\\2")', 
$template );
++  $template = 
preg_replace_callback( '/{'.$k.':(.*?):(.*?)}/i', function ($m) { return 
InsertTemplateVariable("$v", "$m[1]", "$m[2]"); }, $template );
+   }
+   }
+   }
+@@ -334,4 +334,4 @@
+   return $szResult; 
+ }
+ 
+-?>
+\ No newline at end of file
++?>
+--- a/src/classes/logstreamdisk.class.php
 b/src/classes/logstreamdisk.class.php
+@@ -63,7 +63,7 @@
+   private $_lastPageUID = -1;
+ 
+   // Constructor
+-  public function LogStreamDisk($streamConfigObj) {
++  public function __construct($streamConfigObj) {
+   $this->_logStreamConfigObj = $streamConfigObj;
+   }
+ 
+@@ -1086,4 +1086,4 @@
+   $this->_p_buffer = -1;
+   }
+ }
+-?>
+\ No newline at end of file
++?>
+--- a/src/classes/logstreamlineparsersyslog.class.php
 b/src/classes/logstreamlineparsersyslog.class.php
+@@ -52,7 +52,7 @@
+ //protected $_arrProperties = null;
+ 
+   // Constructor
+-  public function LogStreamLineParsersyslog() {
++  public function __construct() {
+   return; // Nothing
+   }
+ 
+@@ -148,4 +148,4 @@
+ 
+ }
+ 
+-?>
+\ No newline at end of file
++?>


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

Kernel: Linux 4.8.0-17-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#838992: mutt: using mutt, will not default to home mail directory: "c", "?" with "set folder" remains in /var/mail

[Alberto Garcia]

On Sat, Oct 01, 2016 at 05:30:32AM +, Antonio Radici wrote:

> I believe I need more info on this:
> a) What directory do you expect instead?
> b) where is directory that you expect, set in .muttrc?

I'll also give my input on what changed in the folder navigation in
Mutt recently.

This particular change happened between 1.7.0-2 and 1.7.0-3, I'm not
sure if it also applies to the problems the other uses have reported:

$ mkdir -p ~/Mail/INBOX/{cur,new,tmp}
$ echo 'set spoolfile=~/Mail/INBOX/' > .muttrc

Now open mutt and press 'c' followed by '?' to list the mailboxes.

1) In previous versions of Mutt you'd see what's under ~/Mail (the
   'INBOX' directory in this case). If you select INBOX then it would
   go to the index view and open the INBOX maildir (which is empty).

   In Mutt >= 1.7.0-3 you see what's under ~/Mail/INBOX/ (that is, the
   cur, new and tmp directories internal to the maildir format). But
   you cannot do anything with those, you need to navigate to the
   parent directory and from there open INBOX.

   This is annoying but it can be fixed by removing the trailing '/'
   from the 'spoolfile' line in the .muttrc file. Still, it took me
   a while to realize that and it's very irritating when changing
   folders, so it would be nice to have it fixed in the package.

2) From the folder view, navigate to the parent directory over and over
   until you reach the root directory.

   In older versions of Mutt you simply press Enter all the time
   because '..' is highlighted by default when you change directories.

   In Mutt >= 1.7.0-3 when you move to the parent directory the cursor
   does not highlight '..', but rather the directory where you are
   coming from.

   I'm hesitant to consider this a bug, but it's certainly a change
   of behavior that is very noticeable to regular Mutt users. I'm not
   sure what the use case is, but when you want to attach a file and
   you need to browse the directory tree in order to open it I find
   the old behavior more convenient. I sometimes have to use different
   versions of Mutt in different machines so that makes things worse.

I guess these issues are due to a change in the folder browsing code
and are related to the ones originally described in this bug report,
but if you think otherwise I can report a new bug.

Thanks,

Berto

Bug#832098: transition: llvm-defaults

[Emilio Pozuelo Monfort]

On 04/10/16 19:40, Sylvestre Ledru wrote:
> Le 04/10/2016 à 19:01, Emilio Pozuelo Monfort a écrit :
>> Hi Sylvestre,
>>
>> On 22/07/16 11:48, Emilio Pozuelo Monfort wrote:
>>> On 22/07/16 11:40, Sylvestre Ledru wrote:
 Package: release.debian.org
 Severity: normal
 User: release.debian@packages.debian.org
 Usertags: transition

 Hello,

 This is again the time to transition to a more recent version of LLVM.
 This time, I would be more agressive and skip the 3.7 transition:
 * takes too much time
 * 3.8 is stable with its 3.8.1 release
 * 3.7 is no longer maintained
 * we have too many releases of llvm in the archive
 * I don't remember seeing critical changes between 3.7 and 3.8
>>>
>>> Yes please! But first the build problems need to be fixed:
>>>
>>> https://buildd.debian.org/status/package.php?p=llvm-toolchain-3.8=sid
>>
>> Everything got fixed except for armel, which didn't receive any reply to the
>> call for help in #820535. So I think we can proceed without llvm 3.8 on 
>> armel.
>> Some packages may need to drop support there or just get removed on armel.
>> Packages are already moving to llvm 3.8 anyway.
>>
>> So I'd say go ahead and update the llvm-defaults package for 3.8. Let me know
>> when that happens so I can schedule binNMUs.
> Done!

clamav freemat gnome-builder and libclang-perl binNMUed.

Cheers,
Emilio

Bug#839747: debian-installer-netboot-images: FTBFS in testing (no properly formatted SHA256 checksum lines found)

[Santiago Vila]

On Wed, Oct 05, 2016 at 12:22:31AM +0200, Cyril Brulebois wrote:
> Hi,
> 
> Santiago Vila  (2016-10-04):
> > I am aware that this is the same version in jessie, but if it's not
> > appropriate for stretch, then we might better have this package
> > autoremoved from stretch than present and not building.
> 
> FWIW it gets propped-up from jessie on each point release.
> 
> It might make sense to start uploading it to unstable since we're
> slowly approaching freeze time. Say: starting with the next d-i
> release.

I agree. That would be indeed a lot better than any of the other options.

Thanks.

Bug#782054: Please support Courier Maildir++

[Nik Melchior]

I don't know whose interpretation of Maildir++ is correct, but Courier does in
fact prepend a '.' for top-level mailboxes.  I'm stuck in the same situation
as Guillem, where I need to create a symlink farm in order to make both
courier and mbsync find my mailboxes.

Unfortunately, Guillem's patches do not work for me.  With
0002-maildir-Fix-Maildir-support.patch applied, I can synchronize my top-level
mailboxes, but mbsync errors out when trying to descend into a hierarchy.  For
example:

"Maildir error: store 'local', folder 'lists.ip': SubFolders style Maildir++
does not support dots in mailbox names"

Since it seems that at least courier and evolution expect the leading '.', it
would be nice if mbsync could support that style.

Thanks,
-- Nik

Bug#839747: debian-installer-netboot-images: FTBFS in testing (no properly formatted SHA256 checksum lines found)

[Cyril Brulebois]

Hi,

Santiago Vila  (2016-10-04):
> I am aware that this is the same version in jessie, but if it's not
> appropriate for stretch, then we might better have this package
> autoremoved from stretch than present and not building.

FWIW it gets propped-up from jessie on each point release.

It might make sense to start uploading it to unstable since we're
slowly approaching freeze time. Say: starting with the next d-i
release.

Cc-ing Didier, usual uploader.


KiBi.


signature.asc
Description: Digital signature

Bug#828097: Possible to keep old tidy?

[Adrian Bunk]

On Tue, Oct 04, 2016 at 09:21:00PM +, Gianfranco Costamagna wrote:
> Hi,
> (not sure why this bug is still open)
> 
> 
> >The upgrade of tidy to the newer version breaks what MediaWiki expects
> >(see test failures:
> >), and updating
> >MediaWiki to be compatible with the newer tidy isn't an option either:
> >.
> 
> >>So is it possible to keep the older version of tidy around? Preferably
> >also via the php-tidy library, though I'm not sure exactly how that
> >integration would work.
> 
> 
> I really don't think this is possible.
> There can be only one tidy implementation, and we have maintainer choose
> the actively maintained one (also Fedora did, and I'm sure other distro too).
> 
> Fix the code with the new library is your best solution.
> Or make somebody upload the old tidy with a different library name, and patch
> the code to use that one.
> (I would oppose such bad way to deal with a library update btw)

There is no technical reason why the two tidy versions couldn't coexist 
long-term in the archive if someone would ITP the old version back into 
unstable - the libraries have different so-names so that was already 
handled, and by using alternatives and/or calling the old binary tiny-old.

This would not be desirable, but shouldn't cause any problems.

The tidy PHP extension is a different story.

php-horde-text-filter is the only rdep of php{,5,7.0}-tidy that
is not completely broken (galette is pretty RC-buggy), so making
the tidy PHP extension in stretch use the old tidy would also
likely be doable.[1]

But the solution with minimum impact for everyone else would be to ITP 
the old tidy version back into unstable with the binary renamed to 
tidy-old, and patching MediaWiki to not use the PHP extension.

Looking at [2], it seems that for buster the problem will be fixed by 
MediaWiki no longer using tidy?

> G.

cu
Adrian

BTW: Why doesn't the mediawiki package have any kind of dependency
 on tidy or php-tidy?

[1] Which tidy version does php-horde-text-filter expect?
[2] https://www.mediawiki.org/wiki/Parsing/Replacing_Tidy

-- 

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

Bug#832116: edgar: Source missing for some GPL licensed assets

[Markus Koschany]

On Sat, 23 Jul 2016 12:19:50 +0200 Francesco Poli
 wrote:
> On Fri, 22 Jul 2016 17:54:27 -0500 Zorian M wrote:
> 
> > I've sent an email to the author of "Devilish design" to request an
> > additional CC-BY license
> [...]
> 
> Hello,
> I stumbled upon this bug report and I feel like commenting on it.
> 
> I disagree that re-licensing the rendered ogg files would be enough to
> solve this issue.
> 
> The Debian Social Contract states, in part:
> 
> | 1. Debian will remain 100% free
> |
> | We provide the guidelines that we use to determine if a work is
> | "free" in the document entitled "The Debian Free Software
> | Guidelines". We promise that the Debian system and all its
> | components will be free according to these guidelines.
> [...]
> 
> DFSG#2 requires the availability of source code.
> 
> Hence, distributing the source-less files under a license that does not
> require the availability of source would not solve the issue.

This is certainly not true for an ogg file which might very well be the
only available source.

> 
> The Debian Project must distribute the source (for works included in
> packages in Debian main) anyway, regardless of how permissive is the
> license.

This is quoted out of context. If game assets like music or images are
shipped under a permissive license, then there is no requirement to ship
some hypothetical "source" as well. There are a lot of artists who reuse
png, bmp, ogg or other media as their primary source material.

See https://wiki.debian.org/Games/Source for a collection of quotes
regarding this topic, especially the thread on debian-devel and posts like

https://lists.debian.org/debian-devel/2014/03/msg00293.html

[...]

>> >
>> > Also, Medicine.ogg is, according to OpenGameArt.org, created by
>> > Alexander Zhelanov, and is licensed only under CC-BY 3.0.
> 
> If this is again a rendered ogg file generated from a distinct source
> form, then the source must be included in the Debian source package.
> 
> 
> What I expressed is my own opinion on the topic, but it is shared by a
> good number of other people.
> I hope I explained things clearly enough.
> 
> Please address this issue in a proper way.
> Thanks for your time.

Indeed you have expressed your own opinion and some others might agree
but this is _not_ the official stance of the Debian project. Please
carefully read the aforementioned thread on debian-devel

"https://www.debian.org/vote/2006/vote_004

That GR proposal does not require source for non-programmatic works.  It
only "strongly recommends" it, and says explicitly that such source
doesn't have to be in the archive.

Quote from Russ Albery on debian-devel
 https://lists.debian.org/debian-devel/2014/03/msg00299.html;

Regards,

Markus





signature.asc
Description: OpenPGP digital signature

Bug#839783: Please package Emacs 25.1

[Rob Browning]

John Zaitseff  writes:

> Emacs 25.1 has been out for almost a month now (it was released 17th
> September 2016).  Could you please package this new version for
> Debian?

Yep - been working on it, and should be finished soon.  The DFSG split
makes the process a little more work than you might otherwise expect.

Thanks
-- 
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4

Bug#833782: /usr/sbin/VBoxService: VBoxService exits immediately

[Gianfranco Costamagna]

control: tags -1 help

> Sometimes when I boot my VM, the virtualbox-guest-utils service fails.
> It appears to start and then immediately exit with status 0.
> 

this seems to be a race condition, due to some bug in the old sysvinit script.
I would really like somebody giving a patch to make it systemd friendly
The upstream service file is too different to be useful here :/

G.



signature.asc
Description: OpenPGP digital signature

Bug#839787: php-elisp: Pleae add URL to package description debian/control

[Jari Aalto]

Package: php-elisp
Version: 1.13.5-3
Severity: minor

When listing the package desction with apt-cache show it would be
helpful to let reader know which PHP Emacs package is in question.
(There are few PHP modes for Emacs in Emacs wiki).

Please include URL to upstream in the debian/control::Description

   http://php-mode.sf.net

Jari

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

Kernel: Linux 3.2.0-4-amd64 (SMP w/2 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 php-elisp depends on:
ii  emacs24 [emacsen]  24.5+1-6+b2

Versions of packages php-elisp recommends:
pn  speedbar  

Versions of packages php-elisp suggests:
pn  php5  
ii  php5-cli  5.6.24+dfsg-1+b1

-- no debconf information

Bug#839788: trackballs: unable to play the game because it segfaults

[Markus Koschany]

Source: trackballs
Version: 1.1.4-4.2
Severity: grave
Tags: help

Dear maintainer,

while I was preparing an NMU to fix #831119 and other bugs, I
discovered that the game is unplayable because it segfaults as soon
as I try to start a new game.

This issue might be related to #306998. I can't get a full
backtrace but gdb indicates that the issue is also related to guile-2.0.
Maybe the 0003-Port-to-Guile-2.0.patch is incomplete.

I don't think this game should be released with Stretch unless some is
able to fix this bug.

Regards,

Markus

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

Kernel: Linux 4.7.0-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Bug#839758: RFS (on ITP): node-source-map-support -- Fixes stack traces for files with source maps

[Gianfranco Costamagna]

Hi,

>   I am looking for a sponsor for my package "node-source-map-support"


done!

G.

Bug#838808: Fix for the GtkGLExtmm FTBFS

[Adrian Bunk]

Control: tags 838808 +patch

A fix for the GtkGLExtmm FTBFS is attached.

cu
Adrian

-- 

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

Description: Remove -DG_DISABLE_DEPRECATED from gtkglext/gtkmm/gl/Makefile.am
 GtkGLExtmm uses GLib functionality that is now deprecated.
 .
 This is enough for Debian for now, but if GtkGLExtmm upstream ever
 becomes active again chances are they would rather fix this properly
 by using non-deprecated APIs.
Author: Adrian Bunk 
Bug-Debian: https://bugs.debian.org/838808

--- gtkglextmm-1.2.0.orig/gtkglext/gtkmm/gl/Makefile.am
+++ gtkglextmm-1.2.0/gtkglext/gtkmm/gl/Makefile.am
@@ -9,7 +9,6 @@ sublib_cflags = \
 	-I$(top_srcdir)/gdkglext	\
 	$(GTKGLEXTMM_DEP_CFLAGS)	\
 	-DGTKMM_GL_COMPILATION		\
-	-DG_DISABLE_DEPRECATED		\
 	-DGDK_DISABLE_DEPRECATED	\
 	-DGDK_PIXBUF_DISABLE_DEPRECATED	\
 	-DGTK_DISABLE_DEPRECATED

Bug#826629: Possible offb unload fix.

[Lennart Sorensen]

On Tue, Oct 04, 2016 at 09:39:12PM +0200, Mathieu Malaterre wrote:
> Here is what I see:
> 
> [   52.270154] bus: 'pci': add driver radeonfb
> [   52.270224] bus: 'pci': driver_probe_device: matched device
> :00:10.0 with driver radeonfb
> [   52.270233] bus: 'pci': really_probe: probing driver radeonfb with
> device :00:10.0
> [   52.270256] devices_kset: Moving :00:10.0 to end of list
> [   52.270264] radeonfb_pci_register BEGIN
> [   52.270267] radeonfb: MM1
> [   52.275001] radeonfb :00:10.0: enabling device (0006 -> 0007)
> [   52.279727] radeonfb: MM2
> [   52.295202] radeonfb: MM3
> [   52.299816] radeonfb: MM4
> [   52.304934] radeonfb: MM0 9800 800 radeonfb
> [   52.309768] checking generic (9c008000 96000) vs hw (9800 800)
> [   52.309776] fb: switching to radeonfb from OFfb ATY,RockHo
> [   52.315075] Console: switching to colour dummy device 80x25
> [   52.315595] device: 'fb0': device_unregister
> [   52.315736] PM: Removing info for No Bus:fb0
> [   52.317348] device: 'fb0': device_create_release
> [   52.317407] radeonfb: MM5 0
> [   52.317447] device: 'vtcon1': device_unregister
> [   52.317500] PM: Removing info for No Bus:vtcon1
> [   52.317565] device: 'vtcon1': device_create_release
> [   52.318992] radeonfb :00:10.0: BAR 0: can't reserve [mem
> 0x9800-0x9fff pref]
> [   52.319029] radeonfb (:00:10.0): cannot request region 0.
> [   52.319066] radeonfb: probe of :00:10.0 failed with error -16

So offb_destroy is NOT called.  Well that explains the problem.

Unfortunately it seems the reason it isn't called is that the
fb->info->count is not zero, because it is still open.  I am not sure
how the ability to unregister a conflicting framebuffer is supposed to
work if it stays active until it is replaced.

The kick out appears to successfully remove offb from being the active
fb, but since the release hasn't been called yet, the resources are not
yet freed, so radeonfb fails when trying to reserve them.  If offb_destroy
had been called the resources would be free and there would almost
certainly not be a problem.

Now the radeon.ko gets away with this because it doesn't try to reserve
the memory and never calls pci_request_region at all.

How about adding this to your patch:

--- a/drivers/video/fbdev/aty/radeon_base.c
+++ b/drivers/video/fbdev/aty/radeon_base.c
@@ -2319,14 +2319,14 @@ static int radeonfb_pci_register(struct pci_dev *pdev,
if (ret < 0) {
printk( KERN_ERR "radeonfb (%s): cannot request region 0.\n",
pci_name(rinfo->pdev));
-   goto err_release_fb;
+   //goto err_release_fb;
}
 
ret = pci_request_region(pdev, 2, "radeonfb mmio");
if (ret < 0) {
printk( KERN_ERR "radeonfb (%s): cannot request region 2.\n",
pci_name(rinfo->pdev));
-   goto err_release_pci0;
+   //goto err_release_pci0;
}
 
/* map the regions */

So it will still complain, but it will ignore the fact the memory
reservation failed, and still continue and do the ioremap and try to
use it.

That is how radeon.ko works as far as I can tell.

Of course once that is done, then the changes to offb.c become irrelevant.

-- 
Len Sorensen

Bug#839786: RFP: homeassistant -- home automation platform running on Python 3

[Dara Adib]

Package: wnpp
Severity: wishlist

* Package name: homeassistant
  Version : 0.29.26
  Upstream Author : Paulus Schoutsen 
* URL : https://home-assistant.io/
* License : MIT
  Programming Lang: Python 3, JavaScript
  Description : home automation platform running on Python 3

Home Assistant is a home automation platform running on Python 3. The
goal of Home Assistant is to be able to track and control all devices
at home and offer a platform for automating control.

Its main dependencies (python3-jinja2, python3-pip, python3-requests,
python3-tz, python3-voluptuous, python3-yaml) are already in sid,
though install_requires currently contains "voluptuous==0.9.2", which
would be slightly relaxed, and "typing>=3,<4", which is part of the
Python 3.5 standard library in sid.

If there is interest, I'd be happy to work on a package and
(co-)maintain, but I need help with properly packaging the frontend
static files:
https://github.com/home-assistant/home-assistant/tree/dev/homeassistant/components/frontend/www_static

The static files include fonts-roboto, minified JavaScript, and gziped
files. It looks like these are generated from git submodules and
third-party npm packages and then checked in for convenience:
https://github.com/home-assistant/home-assistant/blob/dev/script/build_frontend

Bug#831119: trackballs: FTBFS with GCC 6: glHelp.cc:132:23: error: 'Real abs(Real)' conflicts with a previous declaration

[Markus Koschany]

Control: tags -1 pending

On Thu, 14 Jul 2016 09:28:48 +0200 Lucas Nussbaum  wrote:
> Source: trackballs
> Version: 1.1.4-4.2
> Severity: serious
> Tags: stretch sid
> User: debian...@lists.debian.org
> Usertags: qa-ftbfs-20160713 qa-ftbfs
> Justification: FTBFS with GCC 6 on amd64
> 
> Hi,
> 
> During a rebuild of all packages in sid using the gcc-defaults package
> available in experimental to make GCC default to version 6, your package 
> failed
> to build on amd64. For more information about GCC 6 and Stretch, see:
> - https://wiki.debian.org/GCC6
> - https://lists.debian.org/debian-devel-announce/2016/06/msg7.html
[...]

Dear maintainer,

I've uploaded an NMU for trackballs versioned as 1.1.4-4.3. Please find
attached the debdiff.

Regards,

Markus
diff -Nru trackballs-1.1.4/debian/changelog trackballs-1.1.4/debian/changelog
--- trackballs-1.1.4/debian/changelog   2016-01-27 04:40:05.0 +0100
+++ trackballs-1.1.4/debian/changelog   2016-10-04 21:11:56.0 +0200
@@ -1,3 +1,24 @@
+trackballs (1.1.4-4.3) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Add gcc6.patch and fix FTBFS with GCC-6. (Closes: #831119)
+  * Provide a new trackballs.xpm icon for menu file.
+Converted from share/icons/trackballs-32x32.png. (Closes: #420727)
+  * Add and install trackballs.desktop file.
+Thanks to Stefan Potyra for the initial patch. (Closes: #414651)
+  * Add german-translations.patch.
+Thanks to Erik Pfannenstein for the report and patch. (Closes: #598517)
+  * Fix installation path for arch-independent files like icons and locales
+to /usr/share as appropriate.
+  * Add debian/clean and ensure that the game can be built twice in a row.
+  * Drop -dbg package and use the automatic -dbgsym package instead.
+  * Delete empty directories and do not install them.
+  * Switch to compat level 10.
+  * d/control: Remove duplicate Section field from binary packages.
+  * Remove dirs file. It is obsolete.
+
+ -- Markus Koschany   Tue, 04 Oct 2016 21:11:56 +0200
+
 trackballs (1.1.4-4.2) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru trackballs-1.1.4/debian/clean trackballs-1.1.4/debian/clean
--- trackballs-1.1.4/debian/clean   1970-01-01 01:00:00.0 +0100
+++ trackballs-1.1.4/debian/clean   2016-10-04 21:11:56.0 +0200
@@ -0,0 +1,2 @@
+po/de.gmo
+stamp-h
diff -Nru trackballs-1.1.4/debian/control trackballs-1.1.4/debian/control
--- trackballs-1.1.4/debian/control 2016-01-27 04:39:00.0 +0100
+++ trackballs-1.1.4/debian/control 2016-10-04 21:11:56.0 +0200
@@ -17,7 +17,6 @@
 
 Package: trackballs
 Architecture: any
-Section: games
 Depends: trackballs-data, ${shlibs:Depends}, ${misc:Depends}
 Recommends: trackballs-music
 Description: An OpenGL-based game of marbles through a labyrinth
@@ -36,18 +35,8 @@
  gameplay. For more information and screenshots of the game please see
  .
 
-Package: trackballs-dbg
-Architecture: any
-Section: debug
-Depends: trackballs (=${binary:Version}), ${shlibs:Depends}, ${misc:Depends}
-Description: Debugging symbols for Trackballs
- This package includes the debugging symbols useful for debugging
- the Trackballs game contained in the trackballs package. The debugging
- symbols are used for execution tracing and core dump analysis.
-
 Package: trackballs-data
 Architecture: all
-Section: games
 Depends: ${misc:Depends}
 Enhances: trackballs
 Description: Data files for trackballs
diff -Nru trackballs-1.1.4/debian/dirs trackballs-1.1.4/debian/dirs
--- trackballs-1.1.4/debian/dirs2016-01-27 04:20:05.0 +0100
+++ trackballs-1.1.4/debian/dirs1970-01-01 01:00:00.0 +0100
@@ -1,2 +0,0 @@
-usr/bin
-usr/share/pixmaps
diff -Nru trackballs-1.1.4/debian/menu trackballs-1.1.4/debian/menu
--- trackballs-1.1.4/debian/menu2016-01-27 04:20:05.0 +0100
+++ trackballs-1.1.4/debian/menu2016-10-04 21:11:56.0 +0200
@@ -1,2 +1,5 @@
-?package(trackballs):needs="X11" section="Games/Puzzles" \
-  title="trackballs" command="/usr/games/trackballs"
+?package(trackballs):needs="X11" \
+ section="Games/Puzzles" \
+ title="trackballs" \
+ command="/usr/games/trackballs" \
+ icon="/usr/share/pixmaps/trackballs.xpm"
diff -Nru trackballs-1.1.4/debian/patches/gcc6.patch 
trackballs-1.1.4/debian/patches/gcc6.patch
--- trackballs-1.1.4/debian/patches/gcc6.patch  1970-01-01 01:00:00.0 
+0100
+++ trackballs-1.1.4/debian/patches/gcc6.patch  2016-10-04 21:11:56.0 
+0200
@@ -0,0 +1,36 @@
+From: Markus Koschany 
+Date: Tue, 4 Oct 2016 20:29:06 +0200
+Subject: gcc6
+
+Forwarded:no
+Debian-Bug: https://bugs.debian.org/831119
+Origin: 
http://pkgs.fedoraproject.org/cgit/rpms/trackballs.git/tree/trackballs-1.1.4-gcc6.patch?id=2a9a9ed8b0ca2f65d390f4239a6919ae242b8e1c
+---
+ src/glHelp.cc   | 1 -
+ src/menuMode.cc | 1 -
+ 2 files changed, 2 deletions(-)
+
+diff --git 

Bug#839785: am-utils: broken shutdown: amq -p causes abort, results in complete hang due to stale /net mount

[Andreas Mohr]

Package: am-utils
Version: 6.2+rc20110530-3.2
Severity: critical
Justification: makes unrelated software on the system break (unrelated 
processes hanging)

Hello,

I installed am-utils package today,
and then uninstalled it.
Was pretty astonished to find that
after package uninstall
unrelated processes started hanging (df etc.).
[the usual very annoying symptoms of stale mounts]

Thus figured out rather quickly that there was a stale mount left, despite
am-utils stop having been initiated by package uninstall already:

andi:(pid4532,port1022) on /net type nfs
(rw,relatime,sync,vers=2,rsize=1024,wsize=1024,namlen=255,acregmin=0,acregmax=0,acdirmin=0,acdirmax=0,hard,noac,nolock,proto=udp,port=1022,timeo=7,retrans=3,sec=sys,local_lock=all,addr=127.0.0.1)


# sh -x /etc/init.d/am-utils stop
+ PATH=/usr/sbin:/sbin:/usr/bin:/bin
+ export PATH
+ CONF=/etc/default/am-utils
+ test -x /usr/sbin/amd
+ stop_amd
+ amq -p
+ pid=
+ [ -z  ]
+ echo Stopping automounter: amd not running
Stopping automounter: amd not running
+ [ 0 -eq 0 ]
+ exit 0


[subsequent shutdown handling is thus completely and fully out-maneuvered]


I realized that in fact amd was not running any more at this point.


So, I re-start:ed the service.


At this point, manually doing
   # strace -f amq -p
will show:

stat64("/usr/lib/cmov", 0xbfb262d0) = -1 ENOENT (No such file or
directory)
open("/usr/lib/libnss_db.so.2", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such
file or directory)
stat64("/usr/lib", {st_mode=S_IFDIR|0755, st_size=86016, ...}) = 0
munmap(0xb771b000, 163182)  = 0
open("/etc/protocols", O_RDONLY|O_CLOEXEC) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=2932, ...}) = 0
read(3, "# Internet (IP) protocols\n#\n# Up"..., 1024) = 1024
close(3)= 0
socket(AF_INET, SOCK_STREAM, IPPROTO_TCP) = 3
bind(3, {sa_family=AF_INET, sin_port=htons(0),
sin_addr=inet_addr("0.0.0.0")}, 16) = 0
connect(3, {sa_family=AF_INET, sin_port=htons(111),
sin_addr=inet_addr("127.0.0.1")}, 16) = 0
gettimeofday({1475612569, 410100}, NULL) = 0
futex(0xb7678180, FUTEX_WAKE_PRIVATE, 2147483647) = 0
futex(0xb76782e0, FUTEX_WAKE_PRIVATE, 2147483647) = 0
write(3,
"\200\0\0008Y\304\273\254\0\0\0\0\0\0\0\2\0\1\206\240\0\0\0\2\0\0\0\3\0\0\0\0"...,
60) = 60
poll([{fd=3, events=POLLIN}], 1, 6) = 1 ([{fd=3, revents=POLLIN}])
read(3,
"\200\0\0\34Y\304\273\254\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\3\371",
400) = 32
close(3)= 0
socket(AF_INET, SOCK_STREAM, IPPROTO_TCP) = 3
open("/etc/bindresvport.blacklist", O_RDONLY) = 4
fstat64(4, {st_mode=S_IFREG|0644, st_size=367, ...}) = 0
read(4, "#\n# This file contains a list of"..., 1024) = 367
read(4, "", 1024)   = 0
close(4)= 0
bind(3, {sa_family=AF_INET, sin_port=htons(604),
sin_addr=inet_addr("0.0.0.0")}, 16) = 0
connect(3, {sa_family=AF_INET, sin_port=htons(1017),
sin_addr=inet_addr("127.0.0.1")}, 16) = 0
write(3,
"\200\0\0(m.M]\0\0\0\0\0\0\0\2\0\4\223\363\0\0\0\1\0\0\0\t\0\0\0\0"...,
44) = 44
poll([{fd=3, events=POLLIN}], 1, 4) = 1 ([{fd=3, revents=POLLIN}])
read(3, "", 4000)   = 0
write(2, "amq: failed to get PID of amd\n", 30amq: failed to get PID of
amd
) = 30
exit_group(1)   = ?
+++ exited with 1 +++



Having attached to a running amd process right before that amq invocation
this will then have resulted in the following report there:
# strace -f -p 4657
strace: Process 4657 attached
_newselect(1024, [3 4 5 6], NULL, NULL, {282, 847391}) = 1 (in [5], left
{281, 93032})
rt_sigprocmask(SIG_BLOCK, [HUP INT TERM CHLD], NULL, 8) = 0
gettimeofday({1475612569, 412383}, NULL) = 0
accept(5, {sa_family=AF_INET, sin_port=htons(604),
sin_addr=inet_addr("127.0.0.1")}, [16]) = 7
dup(0)  = 8
close(8)= 0
gettimeofday({1475612569, 412959}, NULL) = 0
gettimeofday({1475612569, 413030}, NULL) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
_newselect(1024, [3 4 5 6 7], NULL, NULL, {281, 0}) = 1 (in [7], left
{280, 999649})
rt_sigprocmask(SIG_BLOCK, [HUP INT TERM CHLD], NULL, 8) = 0
gettimeofday({1475612569, 413806}, NULL) = 0
poll([{fd=7, events=POLLIN}], 1, 35000) = 1 ([{fd=7, revents=POLLIN}])
read(7,
"\200\0\0(m.M]\0\0\0\0\0\0\0\2\0\4\223\363\0\0\0\1\0\0\0\t\0\0\0\0"...,
16384) = 44
open("/etc/hosts.allow", O_RDONLY)  = 8
fstat64(8, {st_mode=S_IFREG|0644, st_size=707, ...}) = 0
read(8, "# /etc/hosts.allow: list of host"..., 1024) = 707
read(8, "", 1024)   = 0
close(8)= 0
open("/etc/hosts.deny", O_RDONLY)   = 8
fstat64(8, {st_mode=S_IFREG|0644, st_size=858, ...}) = 0
read(8, "# /etc/hosts.deny: list of hosts"..., 1024) = 858
close(8)= 0
time([1475612569])  = 1475612569
socket(AF_LOCAL, SOCK_DGRAM|SOCK_CLOEXEC, 0) = 8
connect(8, {sa_family=AF_LOCAL, sun_path="/dev/log"}, 110) = -1 ENOENT
(No 

Bug#838589: pg8000: please provide Python 3 package

[Rahul Amaram]

I have created the package and signed it. But upload to debian queue is 
failing. Will retry again tomorrow.


Thanks,
Rahul.

On Tuesday 04 October 2016 08:02 AM, Rahul Amaram wrote:


Thanks Dominik. Will get this closed today for sure.

Thanks,
Rahul.






--
http://rahul.amaram.name

Bug#828097: Possible to keep old tidy?

[Gianfranco Costamagna]

Hi,
(not sure why this bug is still open)


>The upgrade of tidy to the newer version breaks what MediaWiki expects
>(see test failures:
>), and updating
>MediaWiki to be compatible with the newer tidy isn't an option either:
>.

>>So is it possible to keep the older version of tidy around? Preferably
>also via the php-tidy library, though I'm not sure exactly how that
>integration would work.


I really don't think this is possible.
There can be only one tidy implementation, and we have maintainer choose
the actively maintained one (also Fedora did, and I'm sure other distro too).

Fix the code with the new library is your best solution.
Or make somebody upload the old tidy with a different library name, and patch
the code to use that one.
(I would oppose such bad way to deal with a library update btw)

G.

Bug#835488: Seems to be resolved

[Andreas von Heydwolff]

Hi all,

the latest imagemagick update resolved the issue for me when using
gscan2pdf 1.5.2; I cannot say anything about the php variant though but
I guess the bug should appear fixed in all such conversion uses.

Thanks and greetings to the maintainers!
A.

Bug#839784: libhdf5-dev: pkg-config file references ONLY the C library

[Dima Kogan]

Package: libhdf5-dev
Version: 1.8.16+docs-8+b1
Severity: normal

Hi.

The libhdf5-dev package ships a single .pc file: hdf5-serial.pc, which
contains

  Libs: -L/usr/lib/x86_64-linux-gnu/hdf5/serial -lhdf5

This serves to link in the C interface to the HDF5 library by adding to
the LDLIBS in GNU Make:

  $(shell pkg-config --libs hdf5-serial)

If, however, you have a project that uses the C++ interface, then you
need something uglier:

  $(shell pkg-config --libs-only-L hdf5-serial) -lhdf5_cpp

This is also bad because it goes against the whole purpose of
pkg-config: the user now has to know about the internal layout of the
package.

It looks like we have 6 flavors of shared objects for hdf5-serial:

  /usr/lib/x86_64-linux-gnu/hdf5/serial/libhdf5.so
  /usr/lib/x86_64-linux-gnu/hdf5/serial/libhdf5_cpp.so
  /usr/lib/x86_64-linux-gnu/hdf5/serial/libhdf5_fortran.so
  /usr/lib/x86_64-linux-gnu/hdf5/serial/libhdf5_hl.so
  /usr/lib/x86_64-linux-gnu/hdf5/serial/libhdf5_hl_cpp.so
  /usr/lib/x86_64-linux-gnu/hdf5/serial/libhdf5hl_fortran.so

Would it make sense to ship a .pc file for each one?

Thanks!

Bug#838739: linux-image-amd64: meta depends on image not available

[Ben Hutchings]

On Tue, 2016-10-04 at 22:52 +0200, Vincent Danjean wrote:
> Le 24/09/2016 à 09:05, nutzteil a écrit :
> > 
> > Package: linux-image-amd64
> > Version: 4.6+74~bpo8+1
> > Severity: normal
> > 
> > Hello,
> > current meta-Package linux-image-$ARCH jessie-backports depends on
> > linux-image 4.6,
> >  which is no longer available in jessie-backports.
> > 
> > Same incident for meta-Package linux-headers-$ARCH
> 
>   It seems the problem comes from the migration to signed
> kernel/modules in testing/unstable. The backport of the linux package
> do not revert this part, so only linux-image-*-unsigned packages are
> present in backport. And linux-signed has not been backported.
> 
>   Ben: what it the correct path? Should linux-signed be backported?
[...]

It has; it's waiting in NEW.

Ben.

-- 
Ben Hutchings
Who are all these weirdos? - David Bowie, reading IRC for the first
time


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

Bug#658886: Removing proll from Debian?

[Adrian Bunk]

Hi,

proll is a JavaStation PROM replacement.

JavaStations are 32bit, so not supported by the new sparc64 port.
The old 32bit sparc port has already been remved from Debian.

Guillem mentions in #658886 that QEMU once used to use proll
(but didn't anymore in 2012?).

Am I right that proll is no longer of use for anyone and should be 
removed from unstable, or are there any usecases left?

cu
Adrian

-- 

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

Bug#838706: [Pkg-zfsonlinux-devel] Bug#838706: spl-dkms should require dkms > 2.2.0 as of 0.6.5.8

[Bernhard Schmidt]

Hi,

I just hit the very same problem with spl-linux from bpo on a Jessie
system (with dkms 2.2.0.3-2). 

It builds fine with dkms 2.2.0.3-4~bpo8+1. I assume this could be
changed by this (in 2.2.0.3-3)

  [ Aron Xu ]
  * Added patches from Darik Horn and Ubuntu:
- Correct handling of POST_BUILD (Closes: #704989)

Obviously I have no clue of dkms, but in my test it fixed the issue.

If this is correct I'd suggest to raise the versioned dependency for
dkms on spl-dkms and zfs-dkms to (>= 2.2.0.3-3~), which should be a
no-op in sid and will just pull in dkms from jessie-backports on systems
installing ZFS from jessie-backports.

Alternatively this change could be done only for the backported package
(Ccing Al for his input here)

Bernhard


signature.asc
Description: Digital signature

Bug#835533: dasher: Please package Dasher 5.0 beta

[Adrian Bunk]

(Cc-ing ftpmaster, debian-devel)

On Tue, Oct 04, 2016 at 07:05:09PM +0200, Emilio Pozuelo Monfort wrote:
> (Cc-ing debian-a11y)
> 
> Hi,

Hi Emilio,

> On 30/09/16 13:03, Andreas Henriksson wrote:
> > While the patch would solve the RC bug and get dasher back into
> > testing, I'm hesitant to assist in uploading it because the
> > question "Do we *want* to ship dasher in it current state?" is
> > not something your patch addresses. If we do get dasher back
> > into testing we'll likely have to also support it for the
> > lifetime of stretch. If we're struggling now to find people
> > willing to invest any time into dasher maintenance how will
> > we be able to make any guarantees about being able to support
> > it for the lifetime of stretch?
> > 
> > Until we have a somewhat enthusiastic maintainer it's probably
> > better to make dasher available "on the side" rather than in
> > the main distribution IMHO. Could you tell me your view on
> > this and what your motivation for posting the patch was to better
> > help me understand your situation?
> 
> dasher is a critical piece of software for some people who couldn't use their
> computer without it. Other than this FTBFS, I don't think it's in a bad state
> (unless I missed something). So I'd say we should fix this bug and ship it, or
> let the accessibility team (co-)maintain this (as they do with Orca) and give 
> us
> a hand with it, if they want to do that.

you are too late.

Andreas did not apply my trivial patch to fix the RC bug.[1]

Even though Andreas was worried about noone being available to maintain 
dasher,[2] he did not follow my suggestion to send a WNPP bug.[3]

Andreas succeeded in getting dasher removed from Debian,[4]
conveniently not mentioning that he could have fixed the
"has not been part of testing" by applying my trivial fix.

Andreas claiming "there's noone willing to commit to actually taking 
care of the package" in the removal request is also quite at odds with
him being completely silent on my suggestion to file a WNPP bug.

The ftp admins were fast enough to not give anyone a realistic chance to 
react to the removal request.

It is a problem for users when software that is in one stable release 
disappears in the next stable release, and I guess dasher can forever 
serve as a good example of critical software having been removed from 
unstable without a single good reason.

I am also personally unhappy that creating a patch for the RC bug
triggered removal from unstable instead of getting the fix applied.

> Cheers,
> Emilio

cu
Adrian

[1] https://bugs.debian.org/811640#24
[2] https://bugs.debian.org/835533#15
[3] https://bugs.debian.org/835533#25
[4] https://bugs.debian.org/839735

-- 

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

Bug#839783: Please package Emacs 25.1

[John Zaitseff]

Package: emacs
Severity: wishlist

Hi,

Emacs 25.1 has been out for almost a month now (it was released 17th
September 2016).  Could you please package this new version for
Debian?

If you are not able to do so, are you able to use work done by
others?  I could possibly work on it myself, then you simply do the
uploading, as I am not (yet) a Debian developer.

Yours truly,

John Zaitseff

-- 
John Zaitseff,--_|\The ZAP Group
Phone:  +61 2 9643 7737 /  \   Sydney, Australia
E-mail: j.zaits...@zap.org.au   \_,--._*   http://www.zap.org.au/
  v

Bug#839782: ITP: sagenb-export -- Convert SageNB Notebooks

[Jerome Benoit]

Package: wnpp
Severity: wishlist
Owner: Jerome Benoit 

* Package name: sagenb-export
  Version : 2.0
  Upstream Author : Volker Braun 
* URL : https://github.com/vbraun/ExportSageNB
* License : GPL
  Programming Lang: Python
  Description : Convert SageNB Notebooks

This is a tool to convert SageNB notebooks to other formats,
in particular IPython/Jupyter notebooks.

Bug#673959: O: cobalt-panel-utils -- System utilities for Sun Cobalt's LCD and LEDs

[Adrian Bunk]

On Mon, Sep 26, 2016 at 08:28:47AM +0200, Tobias Frost wrote:
> Hi Adrian, Chris
> 
> Am Sonntag, den 25.09.2016, 22:09 +0100 schrieb Chris Lamb:
> > Adrian,
> > 
> > > 
> > > [..]
> > 
> > In the first case please re-upload the latest version and ping me; I
> > will
> > fast-track it through NEW.
> > 
> > (Or Tobias uploads, it doesn't matter).
> 
> I do not have intention to reintroduce it. It should be done by someone
> how wants to take care about it -- as Maintainer. Without maintainer we
> will have it rotting again.
>...

"rotting" is just a way to make "it worked" sound bad.

I am still hoping that someone of the MIPS maintainers could say whether 
or not there is a chance that some Cobalts might still be working with
stretch - this is the relevant question.

cu
Adrian

-- 

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

Bug#828097: Possible to keep old tidy?

[Kunal Mehta]

Hi,

The upgrade of tidy to the newer version breaks what MediaWiki expects
(see test failures:
), and updating
MediaWiki to be compatible with the newer tidy isn't an option either:
.

So is it possible to keep the older version of tidy around? Preferably
also via the php-tidy library, though I'm not sure exactly how that
integration would work.

Thanks,
-- Kunal



signature.asc
Description: OpenPGP digital signature

Bug#838694: icu: CVE-2016-7415: Stack based buffer overflow in locid.cpp

[GCS]

On Mon, Oct 3, 2016 at 2:37 PM, Salvatore Bonaccorso  wrote:
> On Sat, Oct 01, 2016 at 08:45:20PM -0400, Roberto C. Sánchez wrote:
>> I tried for quite some time to reproduce this based on the original PHP
>> bug report, but I was unable.  I have annotated the security tracker
>> with my (lack of) findings so far.
 That doesn't mean it's not vulnerable as Salvatore already noted.

> Laszlo, do you know more already? Other distributions seem in the same
> boat, like Red Hat in
> https://bugzilla.redhat.com/show_bug.cgi?id=1377361#c3
 Sorry, I was on a trip and just arrived back on Sunday evening. Did
an other security upload and then killed my machine. Minus one
keyboard (a special one) and a monitor. Only now could boot the
remaining hardware.
I don't know more about this issue - upstream keep such bugreports
secret, if any. I don't have a good connection with them (yet), but
will try to know more about this.

Regards,
Laszlo/GCS

Bug#839781: virtinst: virt-clone changes the file format from qcow to raw

[Daniel Bareiro]

Package: virtinst
Version: 1:1.0.1-5
Severity: important

Dear Maintainer,

I think I've found a bug in virt-clone. When I clone a virtual machine
with a qcow disk, the cloned machine changes its disk to raw format.

However, the XML configuration file for the cloned machine indicates a
qcow type. Due to this inconsistency, a failure occurs when start the
cloned virtual machine since Libvirt expect to find a qcow disk, but it
is a raw disk.

Sequence of steps to reproduce the problem:

# virt-clone --original example --name clone1 --file /space/images/clone1.qcow


ss01:/var/lib/libvirt/images# file example.qcow2
example.qcow2: QEMU QCOW Image (v3), 2147483648 bytes

ss01:/space/images# file clone1.qcow
clone1.qcow: DOS/MBR boot sector


Thanks in advance.


Kind regards,
Daniel

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

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

Versions of packages virtinst depends on:
ii  python-libvirt 1.2.9-1
ii  python-libxml2 2.9.1+dfsg1-5+deb8u2
ii  python-urlgrabber  3.9.1-4.1
pn  python2.7:any  
pn  python:any 

Versions of packages virtinst recommends:
ii  qemu-utils   1:2.1+dfsg-12+deb8u6
ii  virt-viewer  1.0-1

virtinst suggests no packages.

-- no debconf information

-- 
Ing. Daniel Bareiro

Opción Libre - Soberanía tecnológica para su empresa
WWW: http://www.opcion-libre.com.ar
Tel: +54 11 5235-3090
Correo-e: conta...@opcion-libre.com.ar


signature.asc
Description: Digital signature

Bug#839780: please package new version 0.16.6

[W. Martin Borgert]

Package: gajim
Version: 0.16.5-2
Severity: wishlist

It has been released ereyesterday with some bug fixes:
https://trac.gajim.org/query?status=closed=0.16.6

Bug#838739: linux-image-amd64: meta depends on image not available

[Vincent Danjean]

Le 24/09/2016 à 09:05, nutzteil a écrit :
> Package: linux-image-amd64
> Version: 4.6+74~bpo8+1
> Severity: normal
> 
> Hello,
> current meta-Package linux-image-$ARCH jessie-backports depends on 
> linux-image 4.6,
>  which is no longer available in jessie-backports.
> 
> Same incident for meta-Package linux-headers-$ARCH

  It seems the problem comes from the migration to signed
kernel/modules in testing/unstable. The backport of the linux package
do not revert this part, so only linux-image-*-unsigned packages are
present in backport. And linux-signed has not been backported.

  Ben: what it the correct path? Should linux-signed be backported?
(with other dependencies?) Or should the "-unsigned" part of the
linux package be reverted in the backport suite? Or should the
backport of linux-latest be modified to point to the -unsigned images?

  Regards,
Vincent


> bye
> christian


-- 
Vincent Danjean   GPG key ID 0xD17897FA vdanj...@debian.org
GPG key fingerprint: 621E 3509 654D D77C 43F5  CA4A F6AE F2AF D178 97FA
Unofficial pkgs: http://moais.imag.fr/membres/vincent.danjean/deb.html
APT repo:  deb http://people.debian.org/~vdanjean/debian unstable main

Bug#839772: gajim contains a code copy of python-gnupg

[W. Martin Borgert]

On 2016-10-04 15:03, Daniel Kahn Gillmor wrote:
> gajim ships:
>
>   /usr/share/gajim/src/common/gnupg.py

The file must also be mentioned in debian/copyright, even when
removed from the binary package.

Bug#839567: rake does not work with jruby

[Christian Hofstaedtler]

* Helmut Grohne  [161004 06:59]:
> I think the implications of having jruby drop ruby-interpreter deserve
> more thought from the ruby team.
> 
> It appears to me that jruby would just work with a fair amount of ruby
> modules[1]. Yet, after dropping that provides, trying to install e.g.
> jruby and ruby-text will also pull in another ruby implementation. So it
> seems to me that the virtual package ruby-interpreter has actually been
> used with two very different meanings which is now causing the problem:
> One meaning is to provide /usr/bin/ruby and the other is a means to
> execute ruby code. At the moment, jruby clearly doesn't do the former,
> but still does the latter.

This is true; right now, being a "ruby-interpreter" implies:

 1. actually have /usr/bin/ruby and related bins.
 2. support all native extensions. **

> [..]

> The Python world has "solved" this issue by packaging each and every
> module (in addition to extensions) for all of the interpreters. For a
> module foo, we now have python-foo, python3-foo and pypy-foo (in the
> worst case, e.g. -six, -wand, -pkg-resources, ...).

Which is a lot of work. Previously, ruby had version-specific packages
(not different from having interpreter-specific packages).

> Please consider learning from them and - if possible - choosing a
> different approach here. Consider employing a different policy that
> makes the aforementioned combination feasible:

We thought through a number of options before moving to the current
state. IIRC some of these were:

  - All libs get an interpreter/version-specific package and
dependencies are always on a specific package. The virtual
ruby-interpreter package can go away.
This is a lot of busy work: introducing and removing binary
packages all the time, when there is no actual code change in
*most* packages.

  - Do not support more than version/implementation. We are
doing this today. The existence of ruby-interpreter is
an internal artifact.

  - All libs support all interpreters. We are doing this during
transitions (e.g. 2.1->2.2). This is why ruby-interpreter
exists today ***.

[..]

> 2. Given that all invocation points must depend on an interpreter, ruby
>modules should not depend on a ruby-interpreter unless they require a
>particular implementation.

Well, s/should not/do not need to/ in our case. I'd agree it would
be nicer if that would be done in all packages, but it is not a
priority.

> The Multi-Arch nerd over here also notes that this way allows annotating
> a significant chunk of ruby modules with Multi-Arch: foreign and that
> tracker.d.o will tell you where (e.g. ruby-rd).

Noted. A number of dependency cycles would also go away, I imagine.


** Plus, ruby-interpreter serves as an escape hatch for
bootstrapping rubyX.Y on new archs.
*** This is done using code in dh_ruby.


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



signature.asc
Description: PGP signature

Bug#824139: ocaml: CVE-2015-8869

[Salvatore Bonaccorso]

Hi Moritz,

On Tue, Oct 04, 2016 at 10:27:38PM +0200, Moritz Muehlenhoff wrote:
> B0;115;0cOn Thu, May 12, 2016 at 08:50:57PM +0200, Salvatore Bonaccorso wrote:
> > Source: ocaml
> > Version: 3.12.1-4
> > Severity: important
> > Tags: security upstream patch fixed-upstream
> > Forwarded: http://caml.inria.fr/mantis/view.php?id=7003
> > Control: fixed -1 3.12.1-4+deb7u1
> > 
> > Hi,
> > 
> > the following vulnerability was published for ocaml.
> > 
> > CVE-2015-8869[0]:
> > buffer overflow and information leak
> 
> There have been various uploads since then, has this been fixed?

Just checked the current version in unstable, and it does not look yet
fixed. From the upstream bug report it looks that from upstream point
of view it will be for 4.03.0+dev / +beta1.

Regards,
Salvatore

Bug#839593: cme: support (or switch to) UTF-8 encoding

[gregor herrmann]

On Tue, 04 Oct 2016 10:20:40 +0200, Dominique Dumont wrote:

> > % cme modify dpkg-control 'source Uploaders:.insort("María Prueba
> > ")'
> > 
> > and
> > 
> > % perl -MConfig::Model=cme -e 'cme("dpkg-control")->modify("source
> > Uploaders:.insort(\"María Prueba \")");'
> > 
> > result in a broken 'í', which gets mangled into 'Ã', probably because
> > perl's default encoding is still latin1.
> 
> You're right.
> 
> According to perlrun(1), you can run also cme this way :
> $ perl -C A -S cme modify dpkg-control '...'

Ack.
 
> I'll tweak cme upstream to assume that @ARGV is utf8. I'll assume that 
> everybody use utf8 (even outside of Debian) until a bug report proves me 
> wrong.

Thanks, sounds good to me.
 
> There's nothing I can do with the 2nd form you propose. Even with a 
> one-liner, 
> you writing a script and you have to inform perl that you are using utf8 in 
> the script.

Sure, I just wanted to try a different option :)


Cheers,
gregor

-- 
 .''`.  Homepage https://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06
 : :' : Debian GNU/Linux user, admin, and developer -  https://www.debian.org/
 `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   NP: Tom Waits: Swordfish Trombone


signature.asc
Description: Digital Signature

Bug#700841: Re : trouble with debootstrap a ppc SPE build

[jhcha54008]

Hi,

as you wrote [1], debootstrap targetting a debian port fails 
because of an expired key in the stable release. 
This looks like bug #700841.

You need the debian-ports-archive-keyring package from unstable
or stretch (even if you are using debian 7 or 8).

Or you may add the current key from the web page 
https://www.ports.debian.org/archive 

Debian ports generates a new key in the beginning of the year.
Only at release time does the debian-ports-archive-keyring 
package enter the stable distribution, possibly containing 
already expired keys.

Regards,
JH Chatenet

[1] https://lists.debian.org/debian-powerpc/2016/10/msg00015.html

Bug#839547: gnupg: unable to decrypt file

[Paul Rogé]

Hi Daniel,

> how are you running this?  you said earlier this is rxvt-unicode,
> but inside of what kind of graphical environment?  Can do you know
> how gpg-agent was started?

I'm using  dwm (6.1-3 amd64)

> How is gpg-agent started?  What happens if you kill gpg-agent and
> then try the decryption command again immediately?
> 
> gpgconf --kill gpg-agent
> gpg --decrypt FILENAME

gpgconf --kill gpg-agent
gpg --decrypt file.gpg
gpg: encrypted with 2048-bit RSA key, ID 3A2B8EB7865452A1, created
2014-02-28
  "Paul Rogé "
gpg: public key decryption failed: Operation cancelled
gpg: decryption failed: No secret key

Bug#824139: ocaml: CVE-2015-8869

[Moritz Muehlenhoff]

B0;115;0cOn Thu, May 12, 2016 at 08:50:57PM +0200, Salvatore Bonaccorso wrote:
> Source: ocaml
> Version: 3.12.1-4
> Severity: important
> Tags: security upstream patch fixed-upstream
> Forwarded: http://caml.inria.fr/mantis/view.php?id=7003
> Control: fixed -1 3.12.1-4+deb7u1
> 
> Hi,
> 
> the following vulnerability was published for ocaml.
> 
> CVE-2015-8869[0]:
> buffer overflow and information leak

There have been various uploads since then, has this been fixed?

Cheers,
Moritz

Bug#839779: python3-jsonpatch: version is incorrectly set as 1.19

[Scott Moser]

Package: python3-jsonpatch
Version: 1.19-3
Severity: normal

The version in debian is incorrectly identified as 1.19.  Upstream version
is currently at 1.14 per 
 https://github.com/stefankoegl/python-json-patch
and
 https://pypi.python.org/pypi/jsonpatch

$ tar xvf python-json-patch_1.19.orig.tar.xz
python-json-patch-1.19/
...
python-json-patch-1.19/jsonpatch.py
..

$ python3 -c 'import jsonpatch; print(jsonpatch.__version__)'
1.10

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

Kernel: Linux 4.4.0-9136-generic (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 python3-jsonpatch depends on:
ii  python3-json-pointer  1.10-1
pn  python3:any   

python3-jsonpatch recommends no packages.

python3-jsonpatch suggests no packages.

-- no debconf information

Bug#779817: rhn-client-tools: CVE-2015-1777

[Moritz Muehlenhoff]

Moritz Muehlenhoff wrote:
> Package: rhn-client-tools
> Severity: important
> Tags: security
> 
> Please see https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2015-1777

What's the status? This bug is a year old, was that addressed upstream?

Cheers,
Moritz

Bug#825840: Possible fix for colour invertion on ATY,Rockhopper2

[Lennart Sorensen]

On Tue, Oct 04, 2016 at 09:22:17PM +0200, Mathieu Malaterre wrote:
> On Tue, Oct 4, 2016 at 4:44 PM, Lennart Sorensen
>  wrote:
> > On Tue, Oct 04, 2016 at 03:49:12PM +0200, Samuel Thibault wrote:
> >> € grep bogl_set_palette *
> >> bogl.c:  bogl_set_palette = bogl_fb_set_palette;
> >> bogl.c: bogl_set_palette = bogl_fb_set_palette;
> >> bogl.c: bogl_set_palette = bogl_tcfb_set_palette;
> >> bogl.c:   the palette with bogl_set_palette() for this to take effect. */
> >> bogl.h:void (*bogl_set_palette) (int c, int nc, const unsigned char 
> >> palette[][3]);
> >> bogl-test.c:  bogl_set_palette (0, 16, palette);
> >> bogl-test.c:  bogl_set_palette (6, 8, pixmap->palette);
> >> bowl.c:  bogl_set_palette (0, 16, (const unsigned char (*)[3]) palette);
> >> bterm.c:  bogl_set_palette(0, 16, palette);
> >> bterm.c:bogl_set_palette(0, 16, palette);
> >> ChangeLog:* bterm.c (main): Call bogl_set_palette after VT switch.
> >>
> >> It looks like bterm always set only colors 0-15.
> >
> > So it does.  Hmm, I will compare the code some more.
> >
> > Has it been confirmed that radeonfb does not have wrong colours while
> > offb on the same machine does?
> >
> > And what video mode does radeonfb run with?  I wish someone had dmesg
> > dumps of both offb and radeonfb, but I am not having much luck finding
> > any with google.
> 
> Attached.

Could you try what offb does if you boot with the kernel option:
video=1680x1050-32

I just wonder if that makes bterm work with right colors.

Of course it might not like it if it doesn't know how to change the mode
on an "Unknown" type of device.

Unfortunately /proc/iomem on powerpc is apparently totally useless.

-- 
Len Sorensen

Bug#839687: [Python-modules-team] Bug#839687: Bug#839687: how to manage setuptools-scm packages in debian?

[Ondrej Novy]

2016-10-04 9:28 GMT+02:00 Brian May :

> In the past I have found I need to set (in debian/rules):
>
> export SETUPTOOLS_SCM_PRETEND_VERSION=$(shell cat PKG-INFO | sed -n
> 's/^Version: //p')
>

this is what newer pybuild do automatically now.

-- 
Best regards
 Ondřej Nový

Email: n...@ondrej.org
PGP: 3D98 3C52 EB85 980C 46A5  6090 3573 1255 9D1E 064B

Bug#832062: supertuxkart: source for GPL song Boom_boom_boom.ogg missing

[Deve]

Hi,

After direct contact with the author, I corrected the information about 
author and license in this commit:


https://sourceforge.net/p/supertuxkart/code/16762/

Also note that source files (the .mod file and lossless .wav file) are 
available in our media repo:

https://sourceforge.net/p/supertuxkart/code/HEAD/tree/media/trunk/music/mods/

More information:
http://forum.freegamedev.net/viewtopic.php?f=17=6562
https://github.com/supertuxkart/stk-code/issues/2577

I hope that this should be enough to fix this issue.

Regards,
Deve

Bug#839778: jetty: Misleading comments in /etc/default/jetty

[Chris Chiappa]

Package: jetty
Version: 6.1.26-3
Severity: normal

/etc/default/jetty says:

# Listen to connections from this network host
# Use 0.0.0.0 as host to accept all connections.
# Uncomment to restrict access to localhost
#JETTY_HOST=$(uname -n)

However, setting JETTY_HOST to the actual host name causes it to still
be reachable from third party hosts.  I need to explicitly set it to
"localhost" to get it to only be reachable from localhost.


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

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

Versions of packages jetty depends on:
ii  adduser  3.115
ii  apache2-utils2.4.23-5
ii  default-jre-headless [java5-runtime-headless]2:1.8-57
ii  jsvc 1.0.15-6
ii  libjetty-java6.1.26-5
ii  openjdk-7-jre-headless [java5-runtime-headless]  7u95-2.6.4-3
ii  openjdk-8-jre-headless [java5-runtime-headless]  8u102-b14.1-2
ii  openjdk-9-jre-headless [java5-runtime-headless]  9~b133-1

jetty recommends no packages.

Versions of packages jetty suggests:
ii  libjetty-extra   6.1.26-5
ii  libjetty-extra-java  6.1.26-5
pn  libjetty-java-doc

-- Configuration Files:
/etc/default/jetty changed:
NO_START=0
VERBOSE=yes
JETTY_HOST=localhost

/etc/jetty/jetty.xml changed:

http://jetty.mortbay.org/configure.dtd;>












  
10
200
20
  
  








  
  


3
2
false
8443
5000
5000
65536

  
  




















 


  

 
   
 
   
   
 
   
   
 
   
 

  














  

  
  /contexts
  5

  















  

  
  /webapps
  false
  true
  false
  /etc/webdefault.xml

  









  

  
Test Realm
/etc/realm.properties
0
  

  









  

  /_mm_dd.request.log
  _MM_dd
  90
  true
  false
  false
  GMT

  




true
true
true
1000



-- no debconf information

Bug#839687: [Python-modules-team] Bug#839687: how to manage setuptools-scm packages in debian?

[Ondrej Novy]

Hi,

2016-10-03 23:53 GMT+02:00 Antoine Beaupré :

> Answering my own question (and it would be nice to have this documented
> somewhere!), the solution is to use a more recent dh-python dependency
> and depend on python-setuptools-scm explicitely, *and* use
> --buildsystem=pybuild.
>

as author of this addon in pybuild: Yes, this is correct. :)


> I cargo-culted the  (>= 2.20160609~) dependency from python-keyring, but
> I don't really know what I am doing.
>

as author of change in python-keyring: yep >= 2.20160609~ is correct :)

I expected something about this to be documented in a README.Debian
> file.
>

in dh-python? Maybe on wiki?

-- 
Best regards
 Ondřej Nový

Email: n...@ondrej.org
PGP: 3D98 3C52 EB85 980C 46A5  6090 3573 1255 9D1E 064B

Bug#834080: elasticsearch: FTBFS: Could not resolve dependencies for project org.elasticsearch:elasticsearch:jar:1.7.5

[Hans Joachim Desserud]

tags 834080 patch
thanks

After adding a build dependency on libantlr3-runtime-java,
elasticsearch built successfully. (See the attached patch)

--
mvh / best regards
Hans Joachim Desserud
http://desserud.orgdiff --git a/debian/control b/debian/control
index 865a79a..af12177 100644
--- a/debian/control
+++ b/debian/control
@@ -4,6 +4,7 @@ Uploaders: Hilko Bengen 
 Section: database
 Build-Depends-Indep: debhelper (>= 9), maven, maven-debian-helper (>= 1.6), default-jdk,
  groovy (>= 2.4),
+ libantlr3-runtime-java,
  libcarrotsearch-hppc-java,
  libcommons-lang3-java,
  libcompress-lzf-java,

Bug#833523: redis-server: configuring /etc/redis/redis.conf can break automated updates

[Chris Lamb]

Kai Kretschmann wrote:

> After any update the conf file gets overwritten with the distribution
> one

Can you provide a reliable testcase? I cannot:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=833523#10


Regards,

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

Bug#839777: openssl: Curve25519 not available from ecparam

[Jonathan Champ]

Package: openssl
Version: 1.1.0b-1
Severity: normal

Dear Maintainer,

Expected behavior: Curve25519 available as X25519
Actual behavior: Curve not available

Output:

  $ openssl version
  OpenSSL 1.1.0b  26 Sep 2016
  $ openssl ecparam -list_curves | grep 25519
  $ openssl ecparam -name X25519 -text
  unable to create curve (X25519)

Thank you for taking a look!

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

Kernel: Linux 4.7.0-1-amd64 (SMP w/8 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 openssl depends on:
ii  libc6  2.24-3
ii  libssl1.1  1.1.0b-1

openssl recommends no packages.

Versions of packages openssl suggests:
ii  ca-certificates  20160104

-- no debconf information

Bug#839547: gnupg: unable to decrypt file

[Daniel Kahn Gillmor]

Hi Paul--

hope it's ok that i'm responding to the public BTS as well.  i've
removed your trace below.

On Tue 2016-10-04 14:48:59 -0400, Paul Rogé wrote:

> I'm sending you another log file (I sent Daniel one earlier). The
> numbers that seem like they might be sensitive are replaced by Xs. And I
> am not posting it to the bug report system in case I missed something.
> This is an attempt to export my secret key using:
>
> $ gpg --export-secret-keys 40E25F025E23DE01 > ~/Desktop/private.key
> gpg: key : error receiving
> key from agent: Operation cancelled - skipped
> gpg: key : error receiving
> key from agent: Operation cancelled - skipped
> gpg: WARNING: nothing exported

how are you running this?  you said earlier this is rxvt-unicode, but
inside of what kind of graphical environment?  Can do you know how
gpg-agent was started?

Let's stick with the --decrypt use case instead of the
--export-secret-keys use case for now.

How is gpg-agent started?  What happens if you kill gpg-agent and then
try the decryption command again immediately?

gpgconf --kill gpg-agent
gpg --decrypt FILENAME

regards,

--dkg

Bug#836348: closed by Mike Gabriel <sunwea...@debian.org> (Bug#836348: fixed in mate-desktop-environment 1.16.0+1)

[Roman Horník]

Great job, thanks!

I've found just minor flaws - it's impossible to change the desktop
background color (I'm using solid color only; it now remains black, but V/H
color transient still works), also - fading/blending effect (while changing
desktop background) doesn't work.
I'm very satisfied. Thanks a lot!

2016-10-04 14:27 GMT+02:00 Debian Bug Tracking System :

> This is an automatic notification regarding your Bug report
> which was filed against the mate-desktop-environment-core package:
>
> #836348: mate-desktop-environment-core: Unusable Caja and very chatty Mate
> Panel after upgrading GTK libs to 3.21
>
> It has been closed by Mike Gabriel .
>
> Their explanation is attached below along with your original report.
> If this explanation is unsatisfactory and you have not received a
> better one in a separate message then please contact Mike Gabriel <
> sunwea...@debian.org> by
> replying to this email.
>
>
> --
> 836348: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=836348
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>
>
> -- Přeposlaná zpráva --
> From: Mike Gabriel 
> To: 836348-cl...@bugs.debian.org
> Cc:
> Date: Tue, 04 Oct 2016 12:23:43 +
> Subject: Bug#836348: fixed in mate-desktop-environment 1.16.0+1
> Source: mate-desktop-environment
> Source-Version: 1.16.0+1
>
> We believe that the bug you reported is fixed in the latest version of
> mate-desktop-environment, which is due to be installed in the Debian FTP
> archive.
>
> A summary of the changes between this version and the previous one is
> attached.
>
> Thank you for reporting the bug, which will now be closed.  If you
> have further comments please address them to 836...@bugs.debian.org,
> and the maintainer will reopen the bug report if appropriate.
>
> Debian distribution maintenance software
> pp.
> Mike Gabriel  (supplier of updated
> mate-desktop-environment package)
>
> (This message was generated automatically at their request; if you
> believe that there is a problem with it please contact the archive
> administrators by mailing ftpmas...@ftp-master.debian.org)
>
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Format: 1.8
> Date: Tue, 04 Oct 2016 10:52:14 +0200
> Source: mate-desktop-environment
> Binary: mate-desktop-environment-core mate-core mate-desktop-environment
> mate-desktop-environment-extras mate-desktop-environment-extra
> Architecture: source all
> Version: 1.16.0+1
> Distribution: unstable
> Urgency: medium
> Maintainer: MATE Packaging Team 
> Changed-By: Mike Gabriel 
> Description:
>  mate-core  - MATE Desktop Environment (essential components, dummy
> package)
>  mate-desktop-environment - MATE Desktop Environment (metapackage)
>  mate-desktop-environment-core - MATE Desktop Environment (essential
> components, metapackage)
>  mate-desktop-environment-extra - MATE Desktop Environment (extra
> components, dummy package)
>  mate-desktop-environment-extras - MATE Desktop Environment (extra
> components, metapackage)
> Closes: 836348
> Changes:
>  mate-desktop-environment (1.16.0+1) unstable; urgency=medium
>  .
>[ Martin Wimpress ]
>* New upstream release. (Closes: #836348).
> Checksums-Sha1:
>  597b802fcff808b55c6bdc7e8983ef6b7a87f819 2229
> mate-desktop-environment_1.16.0+1.dsc
>  e76dba40cd2cb11985c6c8c31ff2a76503d684a4 4224
> mate-desktop-environment_1.16.0+1.tar.xz
>  a23ad718baeb2bf02b858b6fb33fecf11da39813 3438 mate-core_1.16.0+1_all.deb
>  bd758923f624a8aed363870fa15133d3836021b2 3990
> mate-desktop-environment-core_1.16.0+1_all.deb
>  87d6312a2bb3229ec5f174053af589d15e35cf3c 3448 mate-desktop-environment-
> extra_1.16.0+1_all.deb
>  4d2a24ea036864cfb6670b1af9161dc101ff97e1 3614 mate-desktop-environment-
> extras_1.16.0+1_all.deb
>  5acefa676838d3a7f1738bee94242af64189c095 3716
> mate-desktop-environment_1.16.0+1_all.deb
> Checksums-Sha256:
>  a4332f26b7433e2d8111dfabed72ff3f33bc3e34877c3dd85c42d734f446e72c 2229
> mate-desktop-environment_1.16.0+1.dsc
>  68a1263f62cad848abf58ffa054dd33a6de736b8c53e562e481c36c5cc09d613 4224
> mate-desktop-environment_1.16.0+1.tar.xz
>  d5e2a53ddc091b7ca9c9d75b1f4aa1aca3fcdc0b1f55ddf05c89f82b265441bd 3438
> mate-core_1.16.0+1_all.deb
>  4eb720371abf524a7dfbe454e28be7abb4bddae9ddea6c4b2ad39b4e2cf22af4 3990
> mate-desktop-environment-core_1.16.0+1_all.deb
>  7babf1cfcb620e3fb41aeebf1984e7d85ca0d68f87be36a2a1ed41ca6dba46f9 3448
> mate-desktop-environment-extra_1.16.0+1_all.deb
>  42209d6439fb2ddc8bc44c08acf1ec405fcdefd16576d8cc7d0e5f2866038b55 3614
> mate-desktop-environment-extras_1.16.0+1_all.deb
>  8c9de4e96d55402ec0dd8045b74f34d2a0ab8533b5dcef5e8c0aa14a26bd 3716
> mate-desktop-environment_1.16.0+1_all.deb
> Files:
>  5e8addfcf91d3a8bb99bcb18a55b386d 2229 x11 optional
> mate-desktop-environment_1.16.0+1.dsc
>  b754a1d40f710dd07c274a0d259636a1 4224 x11 

Bug#839771: collectd-core: collectd graphite plugin is missing libyajl2 dependency

[Marc Fournier]

On Tue, Oct 04, 2016 at 08:02:43PM +0100, Shish wrote:
> 
> I ran "apt upgrade", collectd failed to restart, complaining that it
> didn't understand the graphite section of the config file, because the
> write_graphite plugin wasn't loaded. It recommended that I tried running
> lld on the .so file, which I did, and it said that libyajl.so.2 was not
> found. I ran apt install libyajl2, then it worked. I expect libyajl2
> should be marked as recommends rather than suggests, since not having it
> will break currently working installations?

write_graphite should not be linked against libyajl ! Congrats, you found a
genuine bug :-)

I just submitted a patch upstream to fix this:
https://github.com/collectd/collectd/pull/1976

In the meantime, installing libyajl2 should be harmless, and is probably
the only possible workaround.

Thanks for reporting this problem !

Marc

Bug#622078: libpdf-api2-perl: occasional broken conversion of TIFF images

[Jeffrey Ratcliffe]

tags 622078 patch
thanks

The following patches fix
1. The bug itself
2. The warnings (which turned out to be nothing to do with the bug)
From 3fada157720f71e1ef8585ddecd2306de24bd0ce Mon Sep 17 00:00:00 2001
From: Jeffrey Ratcliffe 
Date: Tue, 4 Oct 2016 20:47:41 +0200
Subject: [PATCH 1/2] Fix LZW decoding problems from Debian bug #622078

---
 lib/PDF/API2/Resource/XObject/Image/TIFF.pm | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/lib/PDF/API2/Resource/XObject/Image/TIFF.pm b/lib/PDF/API2/Resource/XObject/Image/TIFF.pm
index 8de298d..154006e 100644
--- a/lib/PDF/API2/Resource/XObject/Image/TIFF.pm
+++ b/lib/PDF/API2/Resource/XObject/Image/TIFF.pm
@@ -186,6 +186,10 @@ sub handle_lzw
 {
 my ($self,$pdf,$tif)=@_;
 $self->filters('FlateDecode');
+my $imageWidth = $tif->{imageWidth};
+my $mod = $imageWidth % 8;
+if ($mod > 0) {$imageWidth += 8 - $mod}
+my $max_raw_strip = $imageWidth*$tif->{bitsPerSample}*$tif->{RowsPerStrip}/8;
 
 if(ref($tif->{imageOffset})) {
 $self->{' stream'}='';
@@ -196,6 +200,9 @@ sub handle_lzw
 $tif->{fh}->seek(shift @{$tif->{imageOffset}},0);
 $tif->{fh}->read($buf,shift @{$tif->{imageLength}});
 $buf=deLZW(9,$buf);
+if (length($buf) > $max_raw_strip) {
+$buf = substr($buf, 0, $max_raw_strip)
+}
 $self->{' stream'}.=$buf;
 }
 } 
@@ -560,6 +567,9 @@ sub readTags {
   } elsif($valTag==277) {
 # samples per pixel
 $self->{samplesPerPixel}=$valOffset;
+  } elsif($valTag==278) {
+# RowsPerStrip
+$self->{RowsPerStrip}=$valOffset;
   } elsif($valTag==279) {
 # image data length/strip lengths
 if($valCount==1) {
-- 
2.4.4

From 15d142b167312cf5fa52eda2dcd0a39aa58fc747 Mon Sep 17 00:00:00 2001
From: Jeffrey Ratcliffe 
Date: Tue, 4 Oct 2016 20:49:09 +0200
Subject: [PATCH 2/2] Fix IO::Handle warnings from Debian bug #622078

---
 lib/PDF/API2/Resource/XObject/Image/TIFF.pm | 8 
 1 file changed, 8 insertions(+)

diff --git a/lib/PDF/API2/Resource/XObject/Image/TIFF.pm b/lib/PDF/API2/Resource/XObject/Image/TIFF.pm
index 154006e..b79a3b4 100644
--- a/lib/PDF/API2/Resource/XObject/Image/TIFF.pm
+++ b/lib/PDF/API2/Resource/XObject/Image/TIFF.pm
@@ -372,6 +372,7 @@ sub new {
   $fh->seek( $self->{offset}, 0 );
 
   # checking byte order of data
+  $self->{byteOrder} = undef; # suppress warning from IO::Handle
   $fh->read( $self->{byteOrder}, 2 );
   $self->{byte}='C';
   $self->{short}=(($self->{byteOrder} eq 'MM') ? 'n' : 'v' );
@@ -379,11 +380,13 @@ sub new {
   $self->{rational}=(($self->{byteOrder} eq 'MM') ? 'NN' : 'VV' );;
 
   # get/check version id
+  $self->{version} = undef; # suppress warning from IO::Handle
   $fh->read( $self->{version}, 2 );
   $self->{version}=unpack($self->{short},$self->{version});
   die "Wrong TIFF Id '$self->{version}' (should be 42)." if($self->{version} != 42);
 
   # get the offset to the first tag directory.
+  $self->{ifdOffset} = undef; # suppress warning from IO::Handle
   $fh->read( $self->{ifdOffset}, 4 );
   $self->{ifdOffset}=unpack($self->{long},$self->{ifdOffset});
 
@@ -457,6 +460,7 @@ sub readTags {
 
   while($self->{ifd} > 0) {
 $fh->seek( $self->{ifd}, 0 );
+$self->{ifdNum} = undef; # suppress warning from IO::Handle
 $fh->read( $self->{ifdNum}, 2 );
 $self->{ifdNum}=unpack($self->{short},$self->{ifdNum});
 $self->{bitsPerSample}=1;
@@ -531,12 +535,14 @@ sub readTags {
 # ImageDescription
 my $here=$fh->tell;
 $fh->seek($valOffset,0);
+$self->{imageDescription} = undef; # suppress warning from IO::Handle
 $fh->read($self->{imageDescription},$valLen);
 $fh->seek($here,0);
   } elsif($valTag==282) {
 # xRes
 my $here=$fh->tell;
 $fh->seek($valOffset,0);
+$self->{xRes} = undef; # suppress warning from IO::Handle
 $fh->read($self->{xRes},$valLen);
 $fh->seek($here,0);
 $self->{xRes}=[unpack($self->{rational},$self->{xRes})];
@@ -545,6 +551,7 @@ sub readTags {
 # yRes
 my $here=$fh->tell;
 $fh->seek($valOffset,0);
+$self->{yRes} = undef; # suppress warning from IO::Handle
 $fh->read($self->{yRes},$valLen);
 $fh->seek($here,0);
 $self->{yRes}=[unpack($self->{rational},$self->{yRes})];
@@ -598,6 +605,7 @@ sub readTags {
 # imageID
 my $here=$fh->tell;
 $fh->seek($valOffset,0);
+$self->{imageId} = undef; # suppress warning from IO::Handle
 $fh->read($self->{imageId},$valLen);
 $fh->seek($here,0);
 #  } elsif($valTag==) {
-- 
2.4.4

Bug#820535: [llvm-dev] llvm-toolchain-3.8 on lower arm targets

[Emilio Pozuelo Monfort]

Hi Tim,

On 04/10/16 20:46, Tim Northover wrote:
> Hi Emilio,
> 
> On 4 October 2016 at 11:14, Emilio Pozuelo Monfort via llvm-dev
>  wrote:
>> In file included from /«PKGBUILDDIR»/lib/Support/ThreadPool.cpp:14:0:
>> /«PKGBUILDDIR»/include/llvm/Support/ThreadPool.h: In member function
>> 'std::shared_future llvm::ThreadPool::async(Function&&, Args&& ...)':
>> /«PKGBUILDDIR»/include/llvm/Support/ThreadPool.h:78:77: error: return type
>> 'class std::shared_future' is incomplete
>>inline std::shared_future async(Function &, Args &&... ArgList) 
>> {
>>  
>> ^
>>
>> Any idea about this failure?
>>
>> For the Debian armel porters, we're switching to LLVM 3.8, so this failure
>> (which happens on 3.8, 3.9 and llvm-toolchain-snapshot) is likely going to 
>> cause
>> some package removals on armel as we try to get rid of older LLVM versions.
>> Helping fixing this issue would be appreciated to prevent that.
> 
> This looks like the kind of failure you get when your host toolchain
> doesn't support C++11 properly (specifically lock-free atomics in this
> case).  When I've seen it before GCC was defaulting to a CPU that's
> too old to do atomics properly,

Oh, yeah. The std::shared_future reference ringed a bell in that direction. This
is https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727621 FWIW.

> and that configuration is very
> unlikely to be supported by LLVM ever (any more).

Understandable.

> It looks like Debian may only support ARMv7 for armel anyway, in which
> case you should add something like "-march=armv7-a" to your C flags
> (-DCMAKE_C_FLAGS=-march=armv7-a and possibly
> -DCMAKE_CXX_FLAGS=-march=armv7-a too).

No, unfortunately armel on Debian targets armv4t, so we're out of luck. See the
above bug report. armhf targets armv7 IIRC, so that's why we don't hit this
issue there. Raspbian armel targets armv6, so that's why they are fine.

I guess this means no more LLVM on armel for now. For the next Debian release
(Buster) we'll have to see if we bump the minimum requirements on armel, or if
we drop the architecture entirely (at least as an official port).

Cheers,
Emilio

Bug#826629: Possible offb unload fix.

[Mathieu Malaterre]

On Tue, Oct 4, 2016 at 9:13 PM, Lennart Sorensen
 wrote:
> On Tue, Oct 04, 2016 at 08:41:45PM +0200, Mathieu Malaterre wrote:
>> Hi Len,
>>
>> Here is the release function I am using:
>>
>> static void offb_destroy(struct fb_info *info)
>> {
>> struct offb_par *par = (struct offb_par *) info->par;
>> if (info->screen_base)
>> iounmap(info->screen_base);
>> if (par->cmap_adr != NULL) {
>> iounmap(par->cmap_adr);
>> par->cmap_adr = NULL;
>> }
>> release_mem_region(info->apertures->ranges[0].base,
>> info->apertures->ranges[0].size);
>> framebuffer_release(info);
>> }
>>
>>
>> (you need the cast to avoid warning about deref of void*).
>>
>> And if I do `modprobe radeonfb`:
>>
>> [   72.163546] bus: 'pci': add driver radeonfb
>> [   72.163618] bus: 'pci': driver_probe_device: matched device
>> :00:10.0 with driver radeonfb
>> [   72.163627] bus: 'pci': really_probe: probing driver radeonfb with
>> device :00:10.0
>> [   72.163651] devices_kset: Moving :00:10.0 to end of list
>> [   72.163659] radeonfb_pci_register BEGIN
>> [   72.163680] radeonfb :00:10.0: enabling device (0006 -> 0007)
>> [   72.163721] radeonfb :00:10.0: BAR 0: can't reserve [mem
>> 0x9800-0x9fff pref]
>> [   72.163726] radeonfb (:00:10.0): cannot request region 0.
>> [   72.163746] radeonfb: probe of :00:10.0 failed with error -16
>
> Could you put a print statement in offb_destroy to make sure that is
> actually being called?
>
> And this is radeonfb with code added to actually try to kick out offb,
> right?

Here is what I see:

[   52.270154] bus: 'pci': add driver radeonfb
[   52.270224] bus: 'pci': driver_probe_device: matched device
:00:10.0 with driver radeonfb
[   52.270233] bus: 'pci': really_probe: probing driver radeonfb with
device :00:10.0
[   52.270256] devices_kset: Moving :00:10.0 to end of list
[   52.270264] radeonfb_pci_register BEGIN
[   52.270267] radeonfb: MM1
[   52.275001] radeonfb :00:10.0: enabling device (0006 -> 0007)
[   52.279727] radeonfb: MM2
[   52.295202] radeonfb: MM3
[   52.299816] radeonfb: MM4
[   52.304934] radeonfb: MM0 9800 800 radeonfb
[   52.309768] checking generic (9c008000 96000) vs hw (9800 800)
[   52.309776] fb: switching to radeonfb from OFfb ATY,RockHo
[   52.315075] Console: switching to colour dummy device 80x25
[   52.315595] device: 'fb0': device_unregister
[   52.315736] PM: Removing info for No Bus:fb0
[   52.317348] device: 'fb0': device_create_release
[   52.317407] radeonfb: MM5 0
[   52.317447] device: 'vtcon1': device_unregister
[   52.317500] PM: Removing info for No Bus:vtcon1
[   52.317565] device: 'vtcon1': device_create_release
[   52.318992] radeonfb :00:10.0: BAR 0: can't reserve [mem
0x9800-0x9fff pref]
[   52.319029] radeonfb (:00:10.0): cannot request region 0.
[   52.319066] radeonfb: probe of :00:10.0 failed with error -16

With patch attached.
diff -ru tmp/linux-4.7.5/drivers/video/fbdev/aty/radeon_base.c linux-4.7.5/drivers/video/fbdev/aty/radeon_base.c
--- tmp/linux-4.7.5/drivers/video/fbdev/aty/radeon_base.c	2016-09-24 10:10:18.0 +0200
+++ linux-4.7.5/drivers/video/fbdev/aty/radeon_base.c	2016-10-04 21:17:09.864838492 +0200
@@ -2259,6 +2259,43 @@
 	.read	= radeon_show_edid2,
 };
 
+static int radeon_kick_out_firmware_fb(struct pci_dev *pdev)
+{
+	struct apertures_struct *ap;
+
+	ap = alloc_apertures(1);
+	if (!ap)
+		return -ENOMEM;
+
+	ap->ranges[0].base = pci_resource_start(pdev, 0);
+	ap->ranges[0].size = pci_resource_len(pdev, 0);
+
+		printk(KERN_INFO "radeonfb: MM0 %x %x %s\n", ap->ranges[0].base, ap->ranges[0].size, KBUILD_MODNAME);
+	remove_conflicting_framebuffers(ap, KBUILD_MODNAME, false);
+	//remove_conflicting_framebuffers(ap, KBUILD_MODNAME, true);
+	kfree(ap);
+
+	return 0;
+}
+
+/*static int radeon_kick_out_firmware_fb2(struct pci_dev *pdev)
+{
+	struct apertures_struct *ap;
+
+	ap = alloc_apertures(1);
+	if (!ap)
+		return -ENOMEM;
+
+	ap->ranges[0].base = pci_resource_start(pdev, 0);
+	ap->ranges[0].size = pci_resource_len(pdev, 0);
+
+		printk(KERN_INFO "radeonfb: MM1 %d %d %s\n", ap->ranges[0].base, ap->ranges[0].size, KBUILD_MODNAME);
+	remove_conflicting_framebuffers(ap, KBUILD_MODNAME, false);
+	//remove_conflicting_framebuffers(ap, KBUILD_MODNAME, true);
+	kfree(ap);
+
+	return 0;
+}*/
 
 static int radeonfb_pci_register(struct pci_dev *pdev,
  const struct pci_device_id *ent)
@@ -2270,6 +2307,7 @@
 	int err = 0;
 
 	pr_debug("radeonfb_pci_register BEGIN\n");
+		printk(KERN_INFO "radeonfb: MM1\n");
 	
 	/* Enable device in PCI config */
 	ret = pci_enable_device(pdev);
@@ -2278,6 +2316,7 @@
 		   pci_name(pdev));
 		goto err_out;
 	}
+		printk(KERN_INFO "radeonfb: MM2\n");
 
 	info = framebuffer_alloc(sizeof(struct radeonfb_info), >dev);
 	if (!info) {
@@ -2286,6 +2325,7 @@
 		ret = -ENOMEM;
 		goto err_disable;
 	

Bug#789690: atop process ends up in cron.service's cgroup

[Sam Morris]

On Tue, 2016-10-04 at 08:09 +0200, Marc Haber wrote:
> tags #789690 unreproducible moreinfo
> thanks
> 
> Hi Sam,
> 
> I do not see this behavior any more in the atop from experimental.
> Are
> you in a position to try this version?
> 
> I would like to mark this bug as "fixed in experimental" and will do
> so unless you have said that the experimental version still has the
> issue by the end of October 2016
> 
> Greetings
> Marc
> 

Hi Marc, I'm not able to try this on a system running jessie right now
but having looked at the changes in the package I'm sure that the bug
will be fixed by the systemd units included in that version--thanks!

BTW, I noticed the newly-shipped cron job. According to sd_booted(3),
you should test whether systemd was used to boot the system by running
[ -d /run/systemd/system ] rather than examining /proc/1/exe. This is a
stable interface that will not change in the future. You can also test
the exit status of 'systemd-notify --booted'.

Another pattern I have seen used by a couple of packages is to ship a
.timer and a .service file to perform the regular task, and a
corresponding cron job that invokes the same command when the system is
not booted with systemd. For example, see /etc/cron.daily/apt-compat
and apt-daily.{timer,service}.

Regards,

-- 
Sam Morris 
PGP: rsa4096/CAAA AA1A CA69 A83A
892B  1855 D20B 4202 5CDA 27B9


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

Bug#839776: xosd-bin: data piped into osd_cat results in very slow screen-wide redraws

[Daniel Kahn Gillmor]

Package: xosd-bin
Version: 2.2.14-2.1
Severity: normal
Control: affects -1 xserver-xorg

I have a command i sometimes run which pipes its stdout into osd_cat.

since recent upgrades to switch over to X.org's builtin modesetting
driver, the display of things through osd_cat has become very slow --
the use of osd_cat causes severe delays in the refresh of other
windows, for example.

My machine's graphical hardware is:

 00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core 
Processor Family Integrated Graphics Controller (rev 09)

let me know if i can provide more detailed debugging info.

 --dkg


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

Kernel: Linux 4.7.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 xosd-bin depends on:
ii  libc6 2.24-3
ii  libx11-6  2:1.6.3-1
ii  libxext6  2:1.3.3-1
ii  libxosd2  2.2.14-2.1

xosd-bin recommends no packages.

xosd-bin suggests no packages.

-- no debconf information

Bug#825840: Possible fix for colour invertion on ATY,Rockhopper2

[Mathieu Malaterre]

On Tue, Oct 4, 2016 at 4:44 PM, Lennart Sorensen
 wrote:
> On Tue, Oct 04, 2016 at 03:49:12PM +0200, Samuel Thibault wrote:
>> € grep bogl_set_palette *
>> bogl.c:  bogl_set_palette = bogl_fb_set_palette;
>> bogl.c: bogl_set_palette = bogl_fb_set_palette;
>> bogl.c: bogl_set_palette = bogl_tcfb_set_palette;
>> bogl.c:   the palette with bogl_set_palette() for this to take effect. */
>> bogl.h:void (*bogl_set_palette) (int c, int nc, const unsigned char 
>> palette[][3]);
>> bogl-test.c:  bogl_set_palette (0, 16, palette);
>> bogl-test.c:  bogl_set_palette (6, 8, pixmap->palette);
>> bowl.c:  bogl_set_palette (0, 16, (const unsigned char (*)[3]) palette);
>> bterm.c:  bogl_set_palette(0, 16, palette);
>> bterm.c:bogl_set_palette(0, 16, palette);
>> ChangeLog:* bterm.c (main): Call bogl_set_palette after VT switch.
>>
>> It looks like bterm always set only colors 0-15.
>
> So it does.  Hmm, I will compare the code some more.
>
> Has it been confirmed that radeonfb does not have wrong colours while
> offb on the same machine does?
>
> And what video mode does radeonfb run with?  I wish someone had dmesg
> dumps of both offb and radeonfb, but I am not having much luck finding
> any with google.

Attached.


dmesg.radeonfb.txt.gz
Description: GNU Zip compressed data


fbset.radeonfb.txt.gz
Description: GNU Zip compressed data


iomem.radeonfb.txt.gz
Description: GNU Zip compressed data


dmesg.offb.txt.gz
Description: GNU Zip compressed data


fbset.offb.txt.gz
Description: GNU Zip compressed data


iomem.offb.txt.gz
Description: GNU Zip compressed data

Bug#839755: sympa: Sympa should depends on libjs-jquery >= 1.11

[Stefan Hornburg (Racke)]

On 10/04/2016 05:50 PM, Olivier Tétard wrote:
> Package: sympa
> Version: 6.2.16~dfsg-1
> Severity: minor
> 
> Hi,
> 
> Sympa embeds Foundation 5 which requires jQuery >= 1.11 (in fact, Foundation 
> doesn’t load correctly with jQuery version that is available on stable).
> 
> Thanks for you work.
> 
> Cheers,
> Olivier;

Hello Olivier,

I ran into an issue with the Foundation package as well, and I also suggest to 
add this requirement.

Regards
 Racke

> 
> 
> -- System Information:
> Debian Release: stretch/sid
>   APT prefers testing
>   APT policy: (650, 'testing'), (600, 'unstable'), (1, 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 4.7.0-1-amd64 (SMP w/4 CPU cores)
> Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> 
> 


-- 
Ecommerce and Linux consulting + Perl and web application programming.
Debian and Sympa administration.

Bug#839775: libmath-gsl-perl: fix for #826009 overwrites ccflags

[Niko Tyni]

Package: libmath-gsl-perl
Version: 0.36-2

It looks like debian/patches/0003-Use-Config-cccdlflags-in-the-build.patch
(which was introduced to fix #826009) overwrites ccflags rather than
appending to them, removing for instance hardening flags added by
debian/patches/0001-Hardening-Build-Patch.patch.

Somewhat unfortunately we only noticed this now, right after
upstream merged the patch in 0.39. It would be good to push a fix
upstream soonish.

I suspect this was just a typo of mine and something like

-$ccflags = $Config{cccdlflags} . ' ' . $ldflags;
+$ccflags = $Config{cccdlflags} . ' ' . $ccflags;

will fix it. 
-- 
Niko Tyni   nt...@debian.org

Bug#839774: tourney-manager: add libterm-readline-gnu-perl as Suggests dependency

[holger]

Package: tourney-manager
Version: 20070820-4
Severity: wishlist

tourney-manager has an interactive shell interface. It uses Term::ReadLine
and would be much more comforable to use if the libterm-readline-gnu-perl is
available instead of just the basic Perl readline package.

Regards,
Holger

Bug#839773: qa.debian.org: debsources: packages with upstream signature listed in .dsc are not added

[Matthieu Caneill]

Package: qa.debian.org
Severity: important
User: qa.debian@packages.debian.org
Usertags: debsources

debsources fails to unpack source packages, complaining on upstream
signatures being listed in the .dsc:

dpkg-source: error: unrecognized file for a v2.0 source package:
libtool_2.4.6.orig.tar.xz.asc
dpkg-source: info: extracting libtool in 
/srv/debsources/sources/main/libt/libtool/2.4.6-2

This is due to our outdated version of dpkg-source.
Relevant discussion can be found at
https://lists.debian.org/debian-dpkg/2016/05/msg00041.html

Cheers,
--
Matthieu

-- 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)


signature.asc
Description: PGP signature

Bug#826629: Possible offb unload fix.

[Lennart Sorensen]

On Tue, Oct 04, 2016 at 08:41:45PM +0200, Mathieu Malaterre wrote:
> Hi Len,
> 
> Here is the release function I am using:
> 
> static void offb_destroy(struct fb_info *info)
> {
> struct offb_par *par = (struct offb_par *) info->par;
> if (info->screen_base)
> iounmap(info->screen_base);
> if (par->cmap_adr != NULL) {
> iounmap(par->cmap_adr);
> par->cmap_adr = NULL;
> }
> release_mem_region(info->apertures->ranges[0].base,
> info->apertures->ranges[0].size);
> framebuffer_release(info);
> }
> 
> 
> (you need the cast to avoid warning about deref of void*).
> 
> And if I do `modprobe radeonfb`:
> 
> [   72.163546] bus: 'pci': add driver radeonfb
> [   72.163618] bus: 'pci': driver_probe_device: matched device
> :00:10.0 with driver radeonfb
> [   72.163627] bus: 'pci': really_probe: probing driver radeonfb with
> device :00:10.0
> [   72.163651] devices_kset: Moving :00:10.0 to end of list
> [   72.163659] radeonfb_pci_register BEGIN
> [   72.163680] radeonfb :00:10.0: enabling device (0006 -> 0007)
> [   72.163721] radeonfb :00:10.0: BAR 0: can't reserve [mem
> 0x9800-0x9fff pref]
> [   72.163726] radeonfb (:00:10.0): cannot request region 0.
> [   72.163746] radeonfb: probe of :00:10.0 failed with error -16

Could you put a print statement in offb_destroy to make sure that is
actually being called?

And this is radeonfb with code added to actually try to kick out offb,
right?

-- 
Len Sorensen

Bug#839772: gajim contains a code copy of python-gnupg

[Daniel Kahn Gillmor]

Package: gajim
Version: 0.16.5-2
Severity: normal
Control: affects -1 python-gnupg

gajim ships:

  /usr/share/gajim/src/common/gnupg.py

However, this is just a copy of python-gnupg, which ships it in
/usr/lib/python2.7/dist-packages/gnupg.py

It would be better to avoid shipping this file in gajim and to make
the dependency on python-gnupg explicit that it can be maintained
properly in one place, as described in debian policy 4.13.

This appears to already be known in
https://anonscm.debian.org/viewvc/secure-testing/data/embedded-code-copies?view=co

Regards,

   --dkg

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

Kernel: Linux 4.7.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 gajim depends on:
ii  dnsutils1:9.10.3.dfsg.P4-10.1
ii  python-gtk2 2.24.0-5
ii  python-nbxmpp   0.5.3-1
ii  python-openssl  16.1.0-1
ii  python-pyasn1   0.1.9-2
pn  python:any  

Versions of packages gajim recommends:
ii  alsa-utils   1.1.2-1
ii  ca-certificates  20160104
ii  dbus 1.10.10-1
ii  notification-daemon  3.20.0-1
ii  pulseaudio-utils 9.0-3
ii  python-crypto2.6.1-6+b1
ii  python-dbus  1.2.4-1

Versions of packages gajim suggests:
pn  aspell-en | aspell-dictionary  
ii  avahi-daemon   0.6.32-1
pn  dvipng 
ii  gnome-keyring  3.20.0-3
pn  gstreamer0.10-plugins-ugly 
pn  kwalletcli 
ii  libgtkspell0   2.0.16-1.1
ii  libxss11:1.2.2-1
pn  nautilus-sendto
ii  network-manager1.4.0-4
pn  python-avahi   
ii  python-gconf   2.28.1+dfsg-1.1
ii  python-gnome2  2.28.1+dfsg-1.1
pn  python-gnomekeyring
pn  python-gupnp-igd   
pn  python-kerberos
ii  python-pycurl  7.43.0-1
ii  texlive-latex-base 2016.20160819-2

-- no debconf information

Bug#836582: gscan2pdf pops up an unpaper error window for each page

[Jeffrey Ratcliffe]

Thanks. I am currently working on another bug, but will look at this
as soon as I have finished

Bug#839771: collectd-core: collectd graphite plugin is missing libyajl2 dependency

[Shish]

Package: collectd-core
Version: 5.6.0-1
Severity: important

Dear Maintainer,

I ran "apt upgrade", collectd failed to restart, complaining that it
didn't understand the graphite section of the config file, because the
write_graphite plugin wasn't loaded. It recommended that I tried running
lld on the .so file, which I did, and it said that libyajl.so.2 was not
found. I ran apt install libyajl2, then it worked. I expect libyajl2
should be marked as recommends rather than suggests, since not having it
will break currently working installations?


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

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

Versions of packages collectd-core depends on:
ii  debconf [debconf-2.0]  1.5.59
ii  init-system-helpers1.45
ii  libc6  2.24-3
ii  libltdl7   2.4.6-2

Versions of packages collectd-core recommends:
ii  perl 5.24.1~rc3-3
ii  rrdtool  1.6.0-1+b1

Versions of packages collectd-core suggests:
pn  apache2  
pn  apcupsd  
pn  bind9
pn  ceph 
pn  collectd-dev 
ii  default-jre-headless 2:1.8-57
ii  hddtemp  0.3-beta15-52
pn  httpd-cgi
ii  iptables 1.6.0-3
pn  ipvsadm  
pn  libatasmart4 
pn  libconfig-general-perl   
ii  libcurl3-gnutls  7.50.1-1
ii  libdbi1  0.9.0-4
pn  libesmtp6
pn  libganglia1  
ii  libgcrypt20  1.7.3-1
ii  libgdk-pixbuf2.0-0   2.36.0-1
ii  libglib2.0-0 2.50.0-1
pn  libgps22 
pn  libhiredis0.13   
ii  libhtml-parser-perl  3.72-2+b1
ii  libip4tc01.6.0-3
ii  libip6tc01.6.0-3
ii  libldap-2.4-22.4.42+dfsg-2+b3
pn  liblua5.3-0  
ii  liblvm2app2.22.02.164-1
pn  libmemcached11   
ii  libmnl0  1.0.4-1
pn  libmodbus5   
pn  libmosquitto1
ii  libmysqlclient18 5.6.30-1
ii  libnotify4   0.7.6-2
ii  libnspr4 2:4.12-2
ii  libnss3  2:3.26-2
ii  libopenipmi0 2.0.22-1
pn  liboping0
pn  libowcapi-3.1-1  
ii  libpcap0.8   1.7.4-3
ii  libperl5.24  5.24.1~rc3-3
ii  libpq5   9.6.0-1.pgdg70+1
pn  libprotobuf-c1   
ii  libpython2.7 2.7.12-3
pn  librabbitmq4 
pn  librdkafka1  
ii  libregexp-common-perl2016060801-1
pn  libriemann-client0   
ii  librrd8  1.6.0-1+b1
pn  librrds-perl 
ii  libsensors4  1:3.4.0-3
pn  libsigrok2   
ii  libsnmp305.7.3+dfsg-1.5+b1
ii  libssl1.0.2  1.0.2j-1
pn  libtokyotyrant3  
ii  libudev1 231-4
pn  libupsclient4
ii  liburi-perl  1.71-1
pn  libvarnishapi1   
pn  libvirt0 
pn  libxen-4.6   
ii  libxml2  2.9.4+dfsg1-2
ii  libyajl2 2.1.0-2
pn  lm-sensors   
pn  mbmon
ii  memcached1.4.28-1
pn  mysql-server | virtual-mysql-server  
ii  nginx1.10.1-3
ii  nginx-full [nginx]   1.10.1-3+b1
ii  notification-daemon  3.20.0-1
pn  nut  
pn  olsrd
pn  openvpn  
pn  pdns-server  
pn  postgresql   
ii  redis-server 3:3.2.4-1
pn  slapd
pn  time-daemon  
pn  varnish  
ii  zlib1g   1:1.2.8.dfsg-2+b1
pn  zookeeper

-- debconf information excluded

Bug#655976: queue-viewer: support binary debdiffs

[Adam D. Barratt]

On Sun, 2016-10-02 at 13:18 +0200, Julien Cristau wrote:
> On Tue, Sep 27, 2016 at 20:35:43 +0100, Adam D. Barratt wrote:
> 
> > - How should we invoke debdiff? We can avoid multiple debdiff
> > invocations via "debdiff --show-moved --controlfiles=ALL --from
> > base1.deb base2.deb --to new1.deb new2.deb" or, if we want to make the
> > command line shorter, generate .changes files for the two sets of
> > packages and then feed those to debdiff. In the latter case, we'd want
> > to create symlink farms, as the .deb files would need to be in the same
> > directory as the .changes files.
> > 
> I don't think length of the command line is a big concern?

I guess not, as we're not doing anything crazy like invoking a shell.

> > - Is there a way we can make the wdiff output easier to review? We need
> > to consider both on-screen display (presumably primarily via a web
> > browser) and the possibility of mailing the result, as we do for source
> > uploads.
> > 
> If the html part could have some colors to show added/removed bits,
> that'd be nice.

Ack.

> > - Should queue-viewer always display links to debdiffs for every
> > architecture, or only those where those is an "interesting" difference?
> > What would be a useful UI for that?

Possibilities that come to mind:

- a new "binary debdiffs" column
- a "binary debdiffs" row in the upload information

> > - What differences are we interested in? Some will always occur -
> > version number changes from $old_source_ver to $new_source_ver (with
> > adjustment for binNMUs); the addition of a "Source" header for a
> > newly-binNMUed package; a change in Size / Installed-Size within a
> > certain delta.
> 
> Also adjusting for epoch, and binary packages with different versioning
> schemes from the source.  diffpackages doesn't quite deal with that,
> yet...

Yeah, a little intelligence would be needed to catch all of those. We
can improve that as we go along of course.

> I think it's ok to leave filtering to a later date though, if we
> can get something it'll be better than the current "notice issues on the
> point release Saturday".

Indeed, I'm just wary of the queue-viewer output becoming too noisy and
either difficult to use (in case of the online version) or ignored (for
mails).

>From an implementation perspective, I had wondered if it was worth
trying to fit the binary methods in to the existing debrelease.debdiff
class which handles source diffs, but I'm not sure if that would just
make things more difficult.

Adam

Bug#839770: keysym syntax can't handle M-C-s

[martin f krafft]

Package: rxvt-unicode
Version: 9.22-1+b1
Severity: minor
Tags: upstream

I used to have

  URxvt.searchable-scrollback:   CM-s

and wanted to replace that with the "new" syntax:

  URxvt.keysym.MC-s: searchable-scrollback:start

While the former works as expected, the latter does not properly.
Specifically, MC-s does work, but so does M-s by itself. This is of
course highly annoying and also not designed behaviour according to
the manpage:

  "a key mapping will match if at least the specified identifiers
  are being set, and no other key mappings with those and more bits
  are being defined."

This means that CM-NumLock-Shift-s will trigger the same as CM-s,
unless that is actually defined.

However, in my case, M-S does not fulfill "at least the specified
identifiers", as Control is missing.

The workaround seems to be to add

  URxvt.keysym.M-s:  builtin:

Note that this is not required in other cases, e.g. CM-Return works
fine (M-Return is not modified).

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

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

Versions of packages rxvt-unicode depends on:
ii  base-passwd   3.5.40
ii  libc6 2.24-3
ii  libfontconfig12.11.0-6.7
ii  libfreetype6  2.6.3-3+b1
ii  libgcc1   1:6.2.0-4
ii  libgdk-pixbuf2.0-02.36.0-1
ii  libglib2.0-0  2.50.0-1
ii  libperl5.24   5.24.1~rc3-3
ii  libstartup-notification0  0.12-4
ii  libx11-6  2:1.6.3-1
ii  libxft2   2.3.2-1
ii  libxrender1   1:0.9.9-2
ii  ncurses-base  6.0+20160917-1

Versions of packages rxvt-unicode recommends:
ii  fonts-dejavu2.37-1
ii  fonts-ipaexfont-gothic [fonts-japanese-gothic]  00301-2
ii  fonts-ipafont-gothic [fonts-japanese-gothic]00303-16

rxvt-unicode suggests no packages.

-- no debconf information

-- 
 .''`.   martin f. krafft  @martinkrafft
: :'  :  proud Debian developer
`. `'`   http://people.debian.org/~madduck
  `-  Debian - when you have better things to do than fixing systems


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)