Bug#824078: libdvd-pkg: fails to report "apt-get check" errors (and others) correctly

[Austin English]

On Mon, 16 May 2016 00:10:35 +1000 Dmitry Smirnov 
wrote:
> On Sunday, 15 May 2016 3:15:50 PM AEST Cyril Brulebois wrote:
> > instead of being told again and again how much of a snow flake
> > your package is, and how OK it is for it to behave like it currently does.
> 
> You seems to imply that everything is terribly wrong with the package that 
> sounds like exadderation. Design may not be perfect but I'm not aware of 
> better one...
> 
> I'm all for improvements. But on this instance it is hard to safely improve 
> on problems that you highlighted. It is more difficult than just propagate 
> error codes or I would have already fixed it... I hope you understand...

I don't understand. I understand that there's a *potential* problem. But
here we have an *actual* problem, where the script is silently ignoring
errors which is causing problems in downstream, and as far as I can
tell, the current solution is to ignore actual errors in favor of
preventing *potential* solutions?

What exactly needs to be tested in the current packaging scheme so that
behavior could be changed? I volunteer to help with that, if it's made
clear what needs to be done.



signature.asc
Description: OpenPGP digital signature

Bug#823325: mariadb-10.0: Various security fixes from 10.0.25 release

[Salvatore Bonaccorso]

Hello Otto,

On Wed, May 04, 2016 at 09:39:12AM +0300, Otto Kekäläinen wrote:
> Acknowledged. I started working on the updates on Saturday but my
> build/test machine broke down and I haven't yet successfully rescued
> the btrfs file system on it. I intend to to the upgrades ASAP but
> right now I cannot promise a schedule, sorry.

Were you able to recover already from that build machine failure?

Bug#824817: Please include bytecode.cvd in one .deb

[Mathieu Parent]

Package: clamav-testfiles
Version: 0.99.2+dfsg-2
Severity: wishlist

Hi,

There is no offline way to test clamav. I need this to ensure c-icap is
working properly using autopkgtest.

I propose that you include bytecode.cvd in clamav-testfiles.

Thanks

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

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

-- no debconf information

Bug#824816: dh-systemd: systemd2init doesn't convert exec fields with arguments correctly

[Phil]

Package: dh-systemd
Version: 1.33
Severity: normal

Dear Maintainer,

Running systemd2init on a systemd unit file that has arguments on exec fields
will create incorrect values in the output file.

As an example, when the unit file contains:
ExecStartPre=/bin/foo -z bar -y baz -x qux

The .init file produced has:
/bin/fooqux



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

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

Versions of packages dh-systemd depends on:
ii  debhelper  9.20160403
ii  perl   5.22.2-1

dh-systemd recommends no packages.

Versions of packages dh-systemd suggests:
ii  augeas-tools  1.2.0-0.3

-- no debconf information

Bug#824815: Bootloader burning verification error

[Milan Kupcevic]

Package: arduino
Version: 2:1.0.5+dfsg2-4
Severity: important
Control: tags -1 patch


Since avrdude version 6.2 efuse bitmask has been changed for ATmega168
and ATmega328, arduino has not been able to burn bootloaders to the
boards with the mentioned microcontrollers.

Please update arduino efuse values accordingly.

A patch with necessary updates is attached.

Milan
diff --git a/hardware/arduino/boards.txt b/hardware/arduino/boards.txt
index de9f4ef..0769116 100644
--- a/hardware/arduino/boards.txt
+++ b/hardware/arduino/boards.txt
@@ -8,7 +8,7 @@ uno.upload.maximum_size=32256
 uno.upload.speed=115200
 uno.bootloader.low_fuses=0xff
 uno.bootloader.high_fuses=0xde
-uno.bootloader.extended_fuses=0x05
+uno.bootloader.extended_fuses=0xfd
 uno.bootloader.path=optiboot
 uno.bootloader.file=optiboot_atmega328.hex
 uno.bootloader.unlock_bits=0x3F
@@ -28,7 +28,7 @@ atmega328.upload.speed=57600
 
 atmega328.bootloader.low_fuses=0xFF
 atmega328.bootloader.high_fuses=0xDA
-atmega328.bootloader.extended_fuses=0x05
+atmega328.bootloader.extended_fuses=0xfd
 atmega328.bootloader.path=atmega
 atmega328.bootloader.file=ATmegaBOOT_168_atmega328.hex
 atmega328.bootloader.unlock_bits=0x3F
@@ -49,7 +49,7 @@ diecimila.upload.speed=19200
 
 diecimila.bootloader.low_fuses=0xff
 diecimila.bootloader.high_fuses=0xdd
-diecimila.bootloader.extended_fuses=0x00
+diecimila.bootloader.extended_fuses=0xf8
 diecimila.bootloader.path=atmega
 diecimila.bootloader.file=ATmegaBOOT_168_diecimila.hex
 diecimila.bootloader.unlock_bits=0x3F
@@ -70,7 +70,7 @@ nano328.upload.speed=57600
 
 nano328.bootloader.low_fuses=0xFF
 nano328.bootloader.high_fuses=0xDA
-nano328.bootloader.extended_fuses=0x05
+nano328.bootloader.extended_fuses=0xfd
 nano328.bootloader.path=atmega
 nano328.bootloader.file=ATmegaBOOT_168_atmega328.hex
 nano328.bootloader.unlock_bits=0x3F
@@ -91,7 +91,7 @@ nano.upload.speed=19200
 
 nano.bootloader.low_fuses=0xff
 nano.bootloader.high_fuses=0xdd
-nano.bootloader.extended_fuses=0x00
+nano.bootloader.extended_fuses=0xf8
 nano.bootloader.path=atmega
 nano.bootloader.file=ATmegaBOOT_168_diecimila.hex
 nano.bootloader.unlock_bits=0x3F
@@ -217,7 +217,7 @@ mini328.upload.speed=115200
 
 mini328.bootloader.low_fuses=0xff
 mini328.bootloader.high_fuses=0xd8
-mini328.bootloader.extended_fuses=0x05
+mini328.bootloader.extended_fuses=0xfd
 mini328.bootloader.path=optiboot
 mini328.bootloader.file=optiboot_atmega328-Mini.hex
 mini328.bootloader.unlock_bits=0x3F
@@ -238,7 +238,7 @@ mini.upload.speed=19200
 
 mini.bootloader.low_fuses=0xff
 mini.bootloader.high_fuses=0xdd
-mini.bootloader.extended_fuses=0x00
+mini.bootloader.extended_fuses=0xf8
 mini.bootloader.path=atmega
 mini.bootloader.file=ATmegaBOOT_168_ng.hex
 mini.bootloader.unlock_bits=0x3F
@@ -259,7 +259,7 @@ ethernet.upload.speed=115200
 
 ethernet.bootloader.low_fuses=0xff
 ethernet.bootloader.high_fuses=0xde
-ethernet.bootloader.extended_fuses=0x05
+ethernet.bootloader.extended_fuses=0xfd
 ethernet.bootloader.path=optiboot
 ethernet.bootloader.file=optiboot_atmega328.hex
 ethernet.bootloader.unlock_bits=0x3F
@@ -280,7 +280,7 @@ fio.upload.speed=57600
 
 fio.bootloader.low_fuses=0xFF
 fio.bootloader.high_fuses=0xDA
-fio.bootloader.extended_fuses=0x05
+fio.bootloader.extended_fuses=0xfd
 fio.bootloader.path=arduino:atmega
 fio.bootloader.file=ATmegaBOOT_168_atmega328_pro_8MHz.hex
 fio.bootloader.unlock_bits=0x3F
@@ -302,7 +302,7 @@ bt328.upload.disable_flushing=true
 
 bt328.bootloader.low_fuses=0xff
 bt328.bootloader.high_fuses=0xd8
-bt328.bootloader.extended_fuses=0x05
+bt328.bootloader.extended_fuses=0xfd
 bt328.bootloader.path=bt
 bt328.bootloader.file=ATmegaBOOT_168_atmega328_bt.hex
 bt328.bootloader.unlock_bits=0x3F
@@ -324,7 +324,7 @@ bt.upload.disable_flushing=true
 
 bt.bootloader.low_fuses=0xff
 bt.bootloader.high_fuses=0xdd
-bt.bootloader.extended_fuses=0x00
+bt.bootloader.extended_fuses=0xf8
 bt.bootloader.path=bt
 bt.bootloader.file=ATmegaBOOT_168.hex
 bt.bootloader.unlock_bits=0x3F
@@ -366,7 +366,7 @@ lilypad328.upload.speed=57600
 
 lilypad328.bootloader.low_fuses=0xFF
 lilypad328.bootloader.high_fuses=0xDA
-lilypad328.bootloader.extended_fuses=0x05
+lilypad328.bootloader.extended_fuses=0xfd
 lilypad328.bootloader.path=atmega
 lilypad328.bootloader.file=ATmegaBOOT_168_atmega328_pro_8MHz.hex
 lilypad328.bootloader.unlock_bits=0x3F
@@ -387,7 +387,7 @@ lilypad.upload.speed=19200
 
 lilypad.bootloader.low_fuses=0xe2
 lilypad.bootloader.high_fuses=0xdd
-lilypad.bootloader.extended_fuses=0x00
+lilypad.bootloader.extended_fuses=0xf8
 lilypad.bootloader.path=lilypad
 lilypad.bootloader.file=LilyPadBOOT_168.hex
 lilypad.bootloader.unlock_bits=0x3F
@@ -408,7 +408,7 @@ pro5v328.upload.speed=57600
 
 pro5v328.bootloader.low_fuses=0xFF
 pro5v328.bootloader.high_fuses=0xDA
-pro5v328.bootloader.extended_fuses=0x05
+pro5v328.bootloader.extended_fuses=0xfd
 pro5v328.bootloader.path=atmega
 pro5v328.bootloader.file=ATmegaBOOT_168_atmega328.hex
 pro5v328.bootloader.unlock_bits=0x3F
@@ 

Bug#824814: FTBFS: Missing Build-Dependencies

[Jörg Frings-Fürst]

Package: jq
Version: 1.5+dfsg-1
Severity: serious

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

by build with pbuilder (DIST=sid pdebuild) I get the warning:

checking for Ruby dependencies... configure: WARNING:
*
*  Ruby dependencies for building jq documentation not found.   *
*  You can still build, install and hack on jq, but the manpage *
*  will not be rebuilt and some of the tests won't run. *
*  See docs/README.md for how to install the docs dependencies. *
*
no
checking for size_t... yes


and then a the tests:

PASS: tests/mantest
PASS: tests/jqtest
PASS: tests/onigtest
FAIL: tests/shtest

   jq 1.5-1-a5b5cbe: ./test-suite.log


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

.. contents:: :depth: 2

FAIL: tests/shtest
==


I attach the build- and the test-log later.

CU
Jörg



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

Kernel: Linux 4.5.0-2-amd64 (SMP w/6 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)

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCgAGBQJXPob2AAoJEAn4nzyModJdbFAP/j1Vpe2rNgj/FR+Hberkau5m
zBWSjC3BRTAA7kw8upWGQEVkyLStvkFwPO9/WHEOktJebXxiMTJXVO0gMcLRni/l
9jrWLGGwFkZ+bkAqmmbTqe0SemftOlnpjV5Ta3vjm151bYKfpBXxhPBuYHLOIksv
0tztAbe6HQvuJNNpAaIlhKYqJIcYFDLK2kDLonJ9ghsUkHgdmgy9TqjEpa3+5AyH
nBCGXAGZE8QW2vXPbkuE0R92+gQTQ/25QbUJTuaBTnh86I76dnSAxZ46EU1WMJG+
6dkWGWiol9ssCuwTNG3rUx0ypLy5bMC/SiZMxEgu7/VJcIlJ9ATk1WGlRWHQu0Vr
AzEZfm5DZslnrV4NHgVfoELnjfK9tL3hjL4ZzW7o434/bL0v+PLxK7V1a3btUxMI
aaLWj2xB+QgN9hKnD7v2mHxOGUWmHnLNFUSZAPymaCegaGh8Aa3iVRfzvEeKxx60
RAT9NidR0CujFDsENelSjJoDkhwbE1YWyH6Wd3/sWpCk4yUTEpZvsKKY3jGQphOC
W+4vuzJY+g6aUAXQTPEtOucQ8kfgiAgz9qSzufa8f3yCHrHasRCQv5D7pDaX8d84
Cc1CsUdq51/3dPLDZQEXk0LS+D3gcHW5cT3jZKbkUsa8+AuNH/T7QdIEJoAd0Wpd
GcegNlM/6pBO5kDK3wQX
=Tlyw
-END PGP SIGNATURE-

Bug#824813: dh-systemd: systemd2init always falls back to default values

[Phil]

Package: dh-systemd
Version: 1.33
Severity: normal
Tags: patch

Dear Maintainer,

The .init file produced by systemd2init always has default values for every
field, EG. DESC= and DAEMON=/usr/sbin/\$NAME

This appears to be caused by the script (via augtool) checking 2 non-existing
locations for the systemd unit file.

The attached patch fixes the issue for me, but I haven't tested it on a Redhat
machine (which the script also accommodates).



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

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

Versions of packages dh-systemd depends on:
ii  debhelper  9.20160403
ii  perl   5.22.2-1

dh-systemd recommends no packages.

Versions of packages dh-systemd suggests:
ii  augeas-tools  1.2.0-0.3

-- no debconf information
--- a/systemd2init/systemd2init
+++ b/systemd2init/systemd2init
@@ -19,16 +19,14 @@
 
 lsconf() {
 RET=
-	aug_path="/files/lib/systemd/system//${SYSTEMD_SERVICE}${1}"
-	[ -f "$SYSTEMD_SERVICE" ] && aug_path="/files$(pwd)//${SYSTEMD_SERVICE}${1}"
-	augtool -r "$WORKINGDIR" -t "Systemd incl $(pwd)/$SYSTEMD_SERVICE" ls "$aug_path"
+	aug_path="/files/${SYSTEMD_SERVICE}${1}"
+	augtool -r "$WORKINGDIR" -t "Systemd incl $SYSTEMD_SERVICE" ls "$aug_path"
 }
 
 getconf() {
 RET=
-	aug_path="/files/lib/systemd/system/${SYSTEMD_SERVICE}${1}"
-	[ -f "$SYSTEMD_SERVICE" ] && aug_path="/files$(pwd)/${SYSTEMD_SERVICE}${1}"
-	augtool -r "$WORKINGDIR" -t "Systemd incl $(pwd)/$SYSTEMD_SERVICE" get "$aug_path" | \
+	aug_path="/files/${SYSTEMD_SERVICE}${1}"
+	augtool -r "$WORKINGDIR" -t "Systemd incl $SYSTEMD_SERVICE" get "$aug_path" | \
 		sed -e "s;^${aug_path}[[:space:]]*\((none)\|(o)\|= \)[[:space:]]*;;"
 }
 

Bug#811033: Workaround

[Adam McKenna]

So to save everyone else the hour and a half I spent figuring out how to
fix this, here's what you need to do:

# lvconvert --mirrors -1  
# vgchange -ay
# lvconvert -m 1 

Where lv_device is the device that's having issues, and  is the
SECONDARY device on the RAID1 mierror.

This will throw a warning, but will remove the secondary device.

vgchange should then be able to bring up the (now un-mirrored) volumes.

 After vgchange, run lvconvert again to add the mirror back.  This requires
a resync.

The above has to be done after every reboot.

Bug#824640: shadowsocks: Shadowsocks upstream has removed available public source code

[Shell Xu]

About the version thing. I asked author which release should I used. He
said anyone you want. I said "even the lastest one?". Yes, that's good.
So I took the lastest commit as a release. Because it contains some feature
I need.

On Thu, May 19, 2016 at 11:26 PM, u  wrote:

> Hi!
>
> thanks for your quick answer.
>
> Shell Xu:
> > Hi, u:
> >
> > That's very interesting. Let's see what happened one by one.
> >
> > First of all, source code are not been "deleted". It's just a branch
> > called "rm". If you switch branch to master, code is still been there (
> > https://github.com/shadowsocks/shadowsocks/tree/master).
>
> You're correct. My mistake. However this branch has been set as main
> branch.
>
> > Next thing is really interesting. You can find my commit in
> repository (
> >
> https://github.com/shadowsocks/shadowsocks/commit/3b242bee5eb191599a0d051497003127986ea290
> ).
> > But if you click "Browse files", and pull to the end. It tunes out at the
> > time I did the packaging job, the repository address is "
> > https://github.com/clowwindy/shadowsocks/wiki; (its wiki), and License
> is
> > MIT.
> > Yes, I did the right job at that time. The repository is modified,
> > translated to someone else, and license changed.
>
> ack. Thanks for clarifying this. I actually did not see a release of
> this version at all.
>
> > I followed commit logs, and here is the log which license changed. (
> >
> https://github.com/shadowsocks/shadowsocks/commit/ce805f0aeaea03646e01b623c4e2185f63a3562f
> ).
> > The whole project are re-licensed to Apache to protect the name of
> > contributors. It's happened far after my work, even after Debian accept
> it.
> > (according here: https://packages.qa.debian.org/s/shadowsocks.html, it's
> > 2014-09-16) In this situation, I think the old code still can be used
> under
> > MIT, and new code can only be used under Apache. So I should use new
> > license if package new one. But I don't have to update package to follow
> > the new license.
>
> Correct.
>
> > As you might noticed, shadowsocks is a software which designed to
> > broken the GFW. So it's not weird that government wanna erase this whole
> > project. The main author (clowwindy) was found by police, and have a
> little
> > conversation. (which we call it "drink tea") He is forbidden to maintain
> > the project, even talk about it. So I don't trust any commit after that
> > time. (just before 2015-08-20) Because government might inject something
> in
> > it after that time.
>
> Thanks for clarifying this.
>
> > Here is the thing I wanna do.
> >
> > I'll update the package to version 2.8.2 in stretch. (of course, it's
> > not a "release", because the author never planed to release at the time
> > been called for "tea". and of course, under Apache License) That will be
> > the final version. Any "new" version after that time should been review
> > carefully.
>
> Fair enough.
>
> > And, I'll remove this project from Debian in next release (after
> > stretch). Because we should had something new at that time. (Or
> hopefully,
> > we can finally get ride of GFW at that time)
>
> Let's hope so!
>
> I'll retitle this bug report accordingly then.
>
> Cheers!
>



-- 
彼節者有間，而刀刃者無厚；以無厚入有間，恢恢乎其於游刃必有餘地矣。
blog: http://shell909090.org/blog/
twitter: @shell909090 
about.me: http://about.me/shell909090

Bug#824154: mupen64plus-qt: Crash when useing: File → Open ROM directly after clicking

[Dan Hasting]

On Fri, 13 May 2016 01:07:01 +0200 Kevin Bradenstein 
 wrote:

Package: mupen64plus-qt
Version: 1.8-2
Severity: normal

Dear Maintainer,

I freshly installed mupen64plus-qt but I am unable to open a ROM file.

I start mupen64plus-qt via my console.
Directly after clicking File → Open ROM... in the menu the programm
ended with following message:

zsh: segmentation fault  mupen64plus-qt

I started gdb and got the following backtrace:

Program received signal SIGSEGV, Segmentation fault.
0x76cddc6a in QUrl::fromLocalFile(QString const&) () from 
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5
(gdb) bt
#0  0x76cddc6a in QUrl::fromLocalFile(QString const&) () from 
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#1  0x7788479e in QFileDialog::getOpenFileName(QWidget*, QString const&, QString 
const&, QString const&, QString*, QFlags) () from 
/usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#2  0x004162ea in ?? ()
#3  0x0045980d in ?? ()
#4  0x76db2f8a in QMetaObject::activate(QObject*, int, int, void**) () 
from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#5  0x7766d3b2 in QAction::triggered(bool) () from 
/usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#6  0x7766f838 in QAction::activate(QAction::ActionEvent) () from 
/usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#7  0x777f1cd2 in ?? () from 
/usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#8  0x777f7f6c in ?? () from 
/usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#9  0x777fbee0 in QMenu::mouseReleaseEvent(QMouseEvent*) () from 
/usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#10 0x776b9f28 in QWidget::event(QEvent*) () from 
/usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#11 0x777fc933 in QMenu::event(QEvent*) () from 
/usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#12 0x77676ffc in QApplicationPrivate::notify_helper(QObject*, QEvent*) 
() from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#13 0x7767cbb9 in QApplication::notify(QObject*, QEvent*) () from 
/usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#14 0x76d845ab in QCoreApplication::notifyInternal(QObject*, QEvent*) 
() from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#15 0x7767bad2 in QApplicationPrivate::sendMouseEvent(QWidget*, QMouseEvent*, 
QWidget*, QWidget*, QWidget**, QPointer&, bool) () from 
/usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#16 0x776d47dd in ?? () from 
/usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#17 0x776d6a3b in ?? () from 
/usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#18 0x77676ffc in QApplicationPrivate::notify_helper(QObject*, QEvent*) 
() from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#19 0x7767c4b6 in QApplication::notify(QObject*, QEvent*) () from 
/usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#20 0x76d845ab in QCoreApplication::notifyInternal(QObject*, QEvent*) 
() from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#21 0x770c6171 in 
QGuiApplicationPrivate::processMouseEvent(QWindowSystemInterfacePrivate::MouseEvent*)
 ()
   from /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5
#22 0x770c7e35 in 
QGuiApplicationPrivate::processWindowSystemEvent(QWindowSystemInterfacePrivate::WindowSystemEvent*)
 ()
   from /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5
#23 0x770abe68 in 
QWindowSystemInterface::sendWindowSystemEvents(QFlags)
 ()
   from /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5
#24 0x7fffee8fe0b0 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5XcbQpa.so.5
#25 0x755741a7 in g_main_context_dispatch () from 
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#26 0x75574400 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#27 0x755744ac in g_main_context_iteration () from 
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#28 0x76ddaa3f in 
QEventDispatcherGlib::processEvents(QFlags) ()
   from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#29 0x76d81d6a in 
QEventLoop::exec(QFlags) () from 
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#30 0x76d89e0c in QCoreApplication::exec() () from 
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#31 0x004102ea in ?? ()
#32 0x761e45f0 in __libc_start_main (main=0x40ff50, argc=1, argv=0x7fffe068, 
init=, fini=,
rtld_fini=, stack_end=0x7fffe058) at libc-start.c:291
#33 0x00410af9 in ?? ()




Let me know if this patch fixes it:
https://github.com/dh4/mupen64plus-qt/commit/e294d147a2140510d98cddce1c4855f0eedb496e

You can download the development build off the README or clone and compile it 
yourself (instructions for that are in the README as well).

Bug#691843: Package Adoption

[Jason Crain]

On Thu, May 19, 2016 at 09:08:34PM -0400, Javier Prats wrote:
> I'm interested in picking up this package.  How may I proceed?

These adoption and orphan bugs tend to not be monitored by anyone, so if
you want to contact the maintainer, you need to cc them on the email.

If you're new to packaging, I suggest you start with the debian-mentors
FAQ (https://wiki.debian.org/DebianMentorsFaq) and various documents it
links to.  If after reading that you still have questions, ask on the
#debian-mentors IRC channel or the debian-mentors mailing list.

Bug#824812: out-of-date backport

[Nicholas D Steeves]

Package: diskscan
Version:0.18-1~bpo8+1

Hi Joao,

Diskscan-0.19-1 is in testing.  I'm presently testing it on a
SAT-supported USB drive.  Please backport, or let me know if you'd
like me to maintain one.  I can either upload packages, or if you'd
prefer push my local jessie-backports branch of diskscan--with tagged
releases, courtesy of gbp.  Mattia Rizzolo from the debian-multimedia
team helped get me up to speed with maintaining packages in git.

Kind regards,
Nicholas

Bug#824211: swh-plugins: Package new upstream version

[Jaromír Mikeš]

2016-05-20 0:51 GMT+02:00 Javier Serrano Polo :
> El dj 19 de 05 de 2016 a les 19:41 +0200, Jaromír Mikeš va escriure:
>> Yes, that would be definitely possible, but I would to to know where
>> next releases will be published to tune watch file accordingly.
>
> Nine years have passed without a release. I think a watch file is
> obsolete. I would rely on "New upstream release" bugs from users.

Hi Javier,

I would rather hear from upstream what is planned than just wild guess
of user ;)
Did you asked upstream author if new releases is planned?
He is active and for lv2 version doing releases ...

https://github.com/swh/lv2/releases

So I would guess there could be also for ladspa version soon ... new
plugin is good reason for it.

Please ask him and let me know.

mira

Bug#824803: trying to overwrite '/usr/share/texlive/texmf-dist/tex/generic/hyph-utf8/loadhyph/loadhyph-de-1901.tex', which is also in package texlive-base 2015.20160320-1

[Norbert Preining]

tag 824803 + pending
thanks

Hi Julian,

thanks for the report. Yes indeed, not only lang-german, but all
the lang-* packages as hyphenation patterns have moved out
into the separate packages.

I have added replaces/breaks for all the lang packages.

> You cannot really conflict with texlive-lang-german from texlive-base.
> You need to Conflict with the old base from lang-german.

Not conflict, but break, but yes. What you have seen is an additional
safety net so that we start installing tl-base only when all others
are available.

> The current way definitely does not work, because it tells us to upgrade
> lang-german to 2016 before upgrading base from 2015 to 2016 which
> fails because base 2015 and german 2016 contain the same file.

With the added replaces/breaks it will deconfigure base, then replaces
the files, and install everything. At least that is the theory ;-)

TL 2016 is in freeze, so I am uploading the current state soon.

All the best

Norbert


PREINING, Norbert   http://www.preining.info
JAIST, Japan TeX Live & Debian Developer
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0  ACF0 6CAC A448 860C DC13

Bug#691843: Package Adoption

[Javier Prats]

Hello,

I'm interested in picking up this package.  How may I proceed?

Javier Prats

Bug#792894: systemd unit files for isc-dhcp-server

[Terry Burton]

Hi Marc, et al.

As you know from discussions on the dhcp-users mailing list I've been
threatening to do some systemd packaging work for ISC DHCP so I'm
taking your contributions as a starting point.

I can't speak for the Debian packaging team so maybe Michael Gilbert
can review this and let us know whether this is on track.

I've taken a look at your unit files and taken the liberty to create
some new ones based on them that I've added to my repo here [2].

I've used the latest Debian sys-v init script from the packaging
repository [3] as my reference for what's sane.

Compared to the originals units:

(1) I've added "Wants" to isc-dhcp-server.target which ensures that
subordinate services are started. Therefore you only need "enable" the
.target file to ensure that the v4 and v6 daemons are started assuming
they are configured.
(2) In the -v4 service file I've replaced references to dhcpd4.conf
with dhcpd.conf since this provides compatibility across upgrades.
(3) I've added an EnvironmentFile option that reads the user provided
settings from /etc/default/isc-dhcp-server. I think only INTERFACES,
INTERFACESv4, INTERFACESv6 and possibly OPTIONS remain relevant for
reasons given in (8) and (9) below.
(4) You use ConditionPathExists=/etc/dhcp/{dhcpd.conf,dhcpd6.conf} to
determine whether to start the units. I like this approach and have
kept it as it provides nice semantics in (5) and (6) below for whether
to start the v4 and v6 subcomponent services.
(5) Since a dhcpd6.conf file isn't currently installed by the package
(and probably shouldn't be, at least not yet) there is no attempt to
start a IPv6 instance - following the principle of least surprise. You
can simply add a dhcpd6.conf file and restart isc-dhcp-server.target
to enable the v6 instance.
(6) You can correspondingly disable the v4 instance by moving
dhcpd.conf out of the way.
(7) I note that this is a different condition for deciding whether or
not to start the daemon than the sys-v script which us whether or not
INTERFACESv{4,6} is defined in /etc/default/isc-dhcp-server. Such a
condition can't be done cleanly in systemd, i.e. you cannot have an
enabled service (or component of a compound target) that simply
decides not to start based on an arbitrary test). Perhaps the sys-v
init script can be aligned to the dhcpd{,6}.conf exists approach?
(8) Since you can't expand environment variables in the
ConditionPathExists and therefore refer directly to the config files
you may as well also hardcode the the values for DHCPDv{4,6}_CONF in
the ExecStart/ExecStartPre lines, i.e. don't read these from
/etc/default/isc-dhcp-server.
(9) I've dropped support for extracting OPTIONS (and OPTIONSv4,
OPTIONSv6)  from /etc/default/isc-dhcp-server since it isn't honoured
by the most recent sysv-init script [3]. If this is accidental then
its trivial to add this back into both systemd and sys-v.
(10) Support for changing the PID file location in
/etc/default/isc-dhcp-server now seems a little odd given that we no
longer take the conf file from here so I've dropped it. This could
alternatively be passed in OPTIONSv{4,6} if we were to enable these.

A general problem that I've noticed which might cause us to modify the
isc-dhcp-server.target approach is that the following commands will
not have the expected effect:

service isc-dhcp-server {start,stop,restart}
systemctl {start,stop,restart} isc-dhcp-server

(1) It doesn't appear as though you can invoke .target unit files
using /usr/sbin/service. This'll drive some purists nuts!
(2) Additionally, these commands as-is will actually invoke LSB
compatibility and trigger the sys-v init script rather than the native
isc-dhcp-server.target unit file.
(3) The packaging would need to do something ensure that the
isc-dhcp-server init script (via LSB) and isc-dhcp-server.target unit
are not both started at boot.

This could spoil an otherwise neat approach. Any suggestions welcome...

I'm not intending to wire up the maintainer scripts until we have an
agreed approach so you'll have to hand-pick the unit files from my
repo [2] into {/etc,/lib}/systemd/system for the time being.

Would you mind taking a look to make sure these work for you, caveats
aside, and let me have any feedback.


[1] https://lists.isc.org/pipermail/dhcp-users/2016-May/020093.html
[2] 
https://github.com/terryburton/isc-dhcp-debian/commit/26d3a94e00853f17141a6f748169dc2a26366b15
[3] 
http://anonscm.debian.org/cgit/pkg-dhcp/isc-dhcp.git/tree/debian/isc-dhcp-server.init.d


Thanks.

Bug#824806: [pkg-golang-devel] Bug#824806: golang: random_build_path_by_golang_compiler is #824806

[Michael Hudson-Doyle]

FWIW my impression is that this issue has been addressed upstream and will
be fixed in the 1.7 release, but maybe someone should check?

Bug#824441: [Aptitude-devel] Bug#824441: aptitude segfaults when marking texlive-generic-extra as auto-installed

[James Tocknell]

Found a different case where aptitude segfaults, this time I marked a few
packages as auto-installed, and after holding the up arrow for a few
seconds, aptitude segfaulted. A backtrace from this is below:
Program received signal SIGSEGV, Segmentation fault.
0x77b3feed in debVersioningSystem::CheckDep(char const*, int, char
const*) () from /usr/lib/x86_64-linux-gnu/libapt-pkg.so.5.0
#0  0x77b3feed in debVersioningSystem::CheckDep(char const*, int,
char const*) () from /usr/lib/x86_64-linux-gnu/libapt-pkg.so.5.0
#1  0x557767c1 in infer_reason (pkg=..., reasons=std::set with 1
elements = {...}) at ../../../../src/generic/apt/infer_reason.cc:178
#2  0x55650418 in reason_fragment (pkg=...,
breakage=@0x7fffcece: false) at ../../src/reason_fragment.cc:447
#3  0x5564abcc in info_area_multiplex::set_package
(this=0x56b436e0, pkg=..., ver=...) at ../../src/pkg_view.cc:454
#4  0x556227e0 in sigc::internal::signal_emit2::emit (_A_a2=..., _A_a1=..., impl=0x5604f970)
at /usr/include/sigc++-2.0/sigc++/signal.h:1266
#5  sigc::signal2::emit (this=, _A_a2=..., _A_a1=...) at
/usr/include/sigc++-2.0/sigc++/signal.h:2989
#6  sigc::signal2::operator() (_A_a2=..., _A_a1=..., this=)
at /usr/include/sigc++-2.0/sigc++/signal.h:2997
#7  pkg_item::do_highlighted_changed (this=0x592d43a0,
highlighted=) at ../../src/pkg_item.cc:115
#8  0x771d5b8d in sigc::internal::signal_emit1::emit(sigc::internal::signal_impl*,
cwidget::widgets::treeitem* const&) ()
   from /usr/lib/x86_64-linux-gnu/libcwidget.so.3
#9  0x771cee93 in cwidget::widgets::tree::line_up() () from
/usr/lib/x86_64-linux-gnu/libcwidget.so.3
#10 0x771d3e41 in
cwidget::widgets::tree::handle_key(cwidget::config::key const&) () from
/usr/lib/x86_64-linux-gnu/libcwidget.so.3
#11 0x5561641d in menu_tree::handle_key
(this=this@entry=0x55c98cf0,
k=...) at ../../src/menu_tree.cc:430
#12 0x55633973 in pkg_tree::handle_key (this=0x55c98cf0, k=...)
at ../../src/pkg_tree.cc:363
#13 0x771d9ab3 in
cwidget::widgets::widget::dispatch_key(cwidget::config::key const&) () from
/usr/lib/x86_64-linux-gnu/libcwidget.so.3
#14 0x771c1da7 in
cwidget::widgets::table::handle_key(cwidget::config::key const&) () from
/usr/lib/x86_64-linux-gnu/libcwidget.so.3
#15 0x771d9ab3 in
cwidget::widgets::widget::dispatch_key(cwidget::config::key const&) () from
/usr/lib/x86_64-linux-gnu/libcwidget.so.3
#16 0x771ad4bb in
cwidget::widgets::passthrough::handle_key(cwidget::config::key const&) ()
from /usr/lib/x86_64-linux-gnu/libcwidget.so.3
#17 0x771d9ab3 in
cwidget::widgets::widget::dispatch_key(cwidget::config::key const&) () from
/usr/lib/x86_64-linux-gnu/libcwidget.so.3
#18 0x771c1da7 in
cwidget::widgets::table::handle_key(cwidget::config::key const&) () from
/usr/lib/x86_64-linux-gnu/libcwidget.so.3
#19 0x771d9ab3 in
cwidget::widgets::widget::dispatch_key(cwidget::config::key const&) () from
/usr/lib/x86_64-linux-gnu/libcwidget.so.3
#20 0x771ad4bb in
cwidget::widgets::passthrough::handle_key(cwidget::config::key const&) ()
from /usr/lib/x86_64-linux-gnu/libcwidget.so.3
#21 0x771d9ab3 in
cwidget::widgets::widget::dispatch_key(cwidget::config::key const&) () from
/usr/lib/x86_64-linux-gnu/libcwidget.so.3
#22 0x7718e1f1 in
cwidget::widgets::menubar::handle_key(cwidget::config::key const&) () from
/usr/lib/x86_64-linux-gnu/libcwidget.so.3
#23 0x771d9ab3 in
cwidget::widgets::widget::dispatch_key(cwidget::config::key const&) () from
/usr/lib/x86_64-linux-gnu/libcwidget.so.3
#24 0x7715bdc9 in
cwidget::toplevel::input_thread::get_input_event::dispatch() () from
/usr/lib/x86_64-linux-gnu/libcwidget.so.3
#25 0x771536b5 in cwidget::toplevel::mainloop(int) () from
/usr/lib/x86_64-linux-gnu/libcwidget.so.3
#26 0x5568c64a in ui_main () at ../../src/ui.cc:3075
#27 0x555b50e0 in main (argc=, argv=)
at ../../src/main.cc:1398
quit


On 17 May 2016 at 13:16, James Tocknell  wrote:

> amd64 is missing aptitude-dbgsym (which is why I asked), but it appears to
> be created by gbp, so I've used that to build a debug package, which gives
> the following backtrace:
> Program received signal SIGSEGV, Segmentation fault.
> 0x77b3feed in debVersioningSystem::CheckDep(char const*, int, char
> const*) () from /usr/lib/x86_64-linux-gnu/libapt-pkg.so.5.0
> #0  0x77b3feed in debVersioningSystem::CheckDep(char const*, int,
> char const*) () from /usr/lib/x86_64-linux-gnu/libapt-pkg.so.5.0
> #1  0x557767c1 in infer_reason (pkg=..., reasons=std::set with 0
> elements) at 

Bug#824673: wine32-development-tools:i386 cannot be installed on amd64

[Javier Serrano Polo]

El dj 19 de 05 de 2016 a les 15:47 +0200, Jens Reyer va escriure:
> So for winegcc there is no reason to install wine32-tools on amd64?

An extra -L flag needs to be specified with wine64-tools.

> What about the other tools in that package?

No idea.

> So you have wine64-tools with libwine-dev:i386 installed, but no
> libwine-dev:amd64?

Correct.

> And you're sure that this is necessary and works?

It works. I do not install libwine-dev:amd64 to avoid a lot of
dependencies.

> libwine-dev's *.h and *.idl files in /usr/include/wine/ are arch
> independent, only the *.def files in /usr/lib//wine/ are arch
> specific.
> So for the former it doesn't matter which package is installed, and for
> the latter I don't see how the 64-bit winegcc is able to find the 32-bit
> files.

The -L/usr/lib/i386-linux-gnu/wine flag is needed.


smime.p7s
Description: S/MIME cryptographic signature

Bug#824809: nmu: libpng1.6, gdal transition in experimental

[Andreas Beckmann]

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

Let's finish the libpng1.6 and gdal transitions in experimental:

nmu weston_1.9.92-2 . ANY . experimental . -m "Rebuild against libpng1.6."
nmu wesnoth-1.13_1:1.13.4-1 . ANY . experimental . -m "Rebuild against 
libpng1.6."
nmu libharu_2.3.0+dfsg-1~exp1 . ANY . experimental . -m "Rebuild against 
libpng1.6."
nmu flightgear_3.6.0~git20151105+1d36b4-1~exp1 . ANY . experimental . -m 
"Rebuild against libpng1.6."
nmu opencv_3.0.0+dfsg-1~exp2 . ANY . experimental . -m "Rebuild against 
libpng1.6."
nmu qtbase-opensource-src_5.6.0+dfsg-2 . ANY . experimental . -m "Rebuild 
against libpng1.6."
nmu qtwebkit-opensource-src_5.6.0+dfsg-1 . ANY . experimental . -m "Rebuild 
against libpng1.6."

nmu vtk6_6.3.0+dfsg1-1~exp2 . ANY . experimental . -m "Rebuild against gdal 
2.1.0."


Andreas

Bug#824810: jq: Package description "lies" about runtime dependencies

[Olaf Meeuwissen]

Package: jq
Version: 1.5+dfsg-1
Severity: minor

Despite the package description claiming jq has zero runtime
dependencies, it Depends: on libonig2.

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

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

Versions of packages jq depends on:
ii  libc6 2.22-7
ii  libonig2  5.9.6-1

jq recommends no packages.

jq suggests no packages.

-- no debconf information

Hope this helps,
-- 
Olaf Meeuwissen, LPIC-2   FLOSS Engineer -- EPSON AVASYS CORPORATION
   Free Software Foundation Associate Member since 2004-01-27
Support Free Software  https://my.fsf.org/donate
Join the Free Software Foundationhttps://my.fsf.org/join

Bug#824811: firmware-realtek: rtl8192ce doesn't transfer data

[koczis]

Package: firmware-realtek
Version: 20160110-1~bpo8+1 & 0.43
Severity: important

Dear Maintainer,

   * What led up to the situation?
Trying to connect to my WiFi LAN and access Internet.

   * What exactly did you do (or not do) that was effective (or ineffective)?
Effective: network scan, connection itself
Ineffective: data transfer (router ping, Internet access)

Additionally:
- please see "Networking> No Internet through WiFi" SolydX board
- assume my router setup is OK - works through eth0
- notice rtl8192cu is working with my "Asus USB N-10 Nano" dongle

- "lspci -nn" line for my PCI WiFi device:
02:00.0 Network controller [0280]: Realtek Semiconductor Co., Ltd. RTL8192CE 
PCIe Wireless Network Adapter [10ec:8178] (rev 01)

- "lsusb" line for my "Asus USB N-10 Nano"
Bus 001 Device 005: ID 0b05:17ba ASUSTek Computer, Inc.


-- System Information:
Distributor ID: SolydXK
Description:SolydX 8 64-bit
Release:8
Codename:   solydxk
Architecture: x86_64

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

firmware-realtek depends on no packages.

firmware-realtek recommends no packages.

Versions of packages firmware-realtek suggests:
ii  initramfs-tools  0.120+deb8u1

-- no debconf information

Bug#824808: gdal: please make the build reproducible (fileordering)

[Alexis Bienvenüe]

Source: gdal
Version: 2.1.0+dfsg-2
Severity: wishlist
Tags: patch upstream
User: reproducible-bui...@lists.alioth.debian.org
Usertags: fileordering
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Dear Maintainer,

While working on the “reproducible builds” effort [1], we have noticed
that 'gdal' could not be built reproducibly.

Either one of the two attached patches fixes the order files are passed
to libtool — but I don't know if one of them could be an acceptable
solution.
One applied, gdal can be built reproducibly in our current experimental
framework.

Regards,
Alexis Bienvenüe.

[1]: https://wiki.debian.org/ReproducibleBuilds
Description: Sort files
 Sort files passed as arguments to make the build reproducible.
Author: Alexis Bienvenüe 

Index: gdal-2.1.0+dfsg/GNUmakefile
===
--- gdal-2.1.0+dfsg.orig/GNUmakefile
+++ gdal-2.1.0+dfsg/GNUmakefile
@@ -53,7 +53,7 @@ $(GDAL_SLIB): $(GDAL_OBJ) $(GDAL_LIB)
-o $(GDAL_SLIB)
 
 $(LIBGDAL):$(GDAL_OBJ:.o=.lo)
-   $(LD) $(LDFLAGS) $(LIBS) -o $@ $(GDAL_OBJ:.o=.lo) \
+   $(LD) $(LDFLAGS) $(LIBS) -o $@ `LC_ALL=C ls $(GDAL_OBJ:.o=.lo) 
2>/dev/null` \
-rpath $(INST_LIB) \
-no-undefined \
-version-info $(LIBGDAL_CURRENT):$(LIBGDAL_REVISION):$(LIBGDAL_AGE)
Description: Sort files
 Sort files passed as arguments to make the build reproducible.
Author: Alexis Bienvenüe 

Index: gdal-2.1.0+dfsg/GNUmakefile
===
--- gdal-2.1.0+dfsg.orig/GNUmakefile
+++ gdal-2.1.0+dfsg/GNUmakefile
@@ -53,7 +53,11 @@ $(GDAL_SLIB):$(GDAL_OBJ) $(GDAL_LIB)
-o $(GDAL_SLIB)
 
 $(LIBGDAL):$(GDAL_OBJ:.o=.lo)
-   $(LD) $(LDFLAGS) $(LIBS) -o $@ $(GDAL_OBJ:.o=.lo) \
+   $(MAKE) $(LIBGDAL).buildit
+
+.PHONY: $(LIBGDAL).buildit
+$(LIBGDAL).buildit:
+   $(LD) $(LDFLAGS) $(LIBS) -o $(LIBGDAL) $(sort $(wildcard 
$(GDAL_OBJ:.o=.lo))) \
-rpath $(INST_LIB) \
-no-undefined \
-version-info $(LIBGDAL_CURRENT):$(LIBGDAL_REVISION):$(LIBGDAL_AGE)

Bug#819096: Frequent hangs/crashes when changing network configuration

[Ben Hutchings]

On Tue, 2016-05-17 at 18:55 +0200, Michael Biebl wrote:
> Control: severity -1 important
> 
> Hi Ben
> 
> On Fri, 25 Mar 2016 08:50:04 + Simon McVittie  wrote:
> > 
> > On Wed, 23 Mar 2016 at 15:48:33 +, Ben Hutchings wrote:
> > > 
> > > If I change the network configuration through the right hand menu in
> > > GNOME Shell it may hang for 10 seconds or (apparently) indefinitely.
> > Do you get the same thing in 3.18.1-1 from testing? If you do, please
> > mark this bug as found there so it doesn't have to block migration.
> > 
> > If you can provide some more specific steps-to-reproduce (something like
> > "be on wifi, switch to mobile broadband, switch back to wifi"), or a
> > rough idea of what proportion of the time those steps will trigger this
> > bug, that would probably also be useful information.
> Since we didn't have any further feedback and I can't seem to reproduce
> the issue, I'm downgrading the severity (for now).
> Otherwise this bug blocks gnome-shell and other important updates to
> enter testing.

Sorry about that, I haven't yet found a reliable reproducer and I
should have let you know sooner.  I agree this should be downgraded.

Ben.

-- 
Ben Hutchings
Experience is what causes a person to make new mistakes instead of old ones.

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

Bug#824807: RM: xfce4-mixer/experimental -- RoQA; depends on gstreamer 0.10

[Andreas Beckmann]

Package: ftp.debian.org
Severity: normal

xfce4-mixer was already removed from unstable (804261), the same applies
to experimental.


Andreas

Bug#824211: swh-plugins: Package new upstream version

[Javier Serrano Polo]

El dj 19 de 05 de 2016 a les 19:41 +0200, Jaromír Mikeš va escriure:
> Yes, that would be definitely possible, but I would to to know where
> next releases will be published to tune watch file accordingly.

Nine years have passed without a release. I think a watch file is
obsolete. I would rely on "New upstream release" bugs from users.


smime.p7s
Description: S/MIME cryptographic signature

Bug#824806: golang: random_build_path_by_golang_compiler is #824806

[Geert Stappers]

Hello reproducible-builds team

Please add #824806 to 
https://tests.reproducible-builds.org/issues/unstable/random_build_path_by_golang_compiler_issue.html


Thanks
Regards
Geert Stappers

Bug#824081: Debian bug report

[Raphaël Halimi]

Le 13/05/2016 11:55, Santiago Ruano Rincón a écrit :
> El 13/05/16 a las 10:16, Raphael Hertzog escribió:
>> I don't think that any of this is required... the problem is that we run
>> the hook from the current directory which is not accessible to the
>> "debian-security-support" user. We should probably just "cd /" at the
>> start of the hook script...
>>
>> Or "cd $TEMPDIR" before running check-support-status.
> 
> Try this package then:
> https://people.debian.org/~santiago/debian/santiago-unstable/debian-security-support_2016.05.13~1_all.deb

It seems that this package fixed the issue, I didn't see the error
message since I installed it.

Regards,

-- 
Raphaël Halimi



signature.asc
Description: OpenPGP digital signature

Bug#824802: debian-edu-config: fails to upgrade from 'jessie' - trying to overwrite /etc/default/ldap2zone

[Holger Levsen]

control: tags -1 + pending

On Fri, May 20, 2016 at 12:19:13AM +0200, Andreas Beckmann wrote:
> On 2016-05-20 00:15, Wolfgang Schweer wrote:
> > ldap2zone 0.2-8 dropped shipping /etc/default/ldap2zone. Debian Edu 
> > Stretch needs this file to configure the DNS service and now has to 
> > provide it. I guess a solution will be possible.
> Breaks+Replaces: ldap2zone (<< 0.2-8~)
 
Thanks Andreas & Wolfgang, fixed in git!


-- 
cheers,
Holger


signature.asc
Description: Digital signature

Bug#823775: installation failure, file overwritting

[Hideki Yamane]

On Sun, 8 May 2016 22:30:51 +0200
Eduard Bloch  wrote:
> Preparing to unpack .../ubuntu-archive-keyring_2012.05.19-5_all.deb ...
> Unpacking ubuntu-archive-keyring (2012.05.19-5) ...
> dpkg: error processing archive 
> /var/cache/apt/archives/ubuntu-archive-keyring_2012.05.19-5_all.deb 
> (--unpack):
>  trying to overwrite '/usr/share/keyrings/ubuntu-archive-keyring.gpg', which 
> is also in package ubuntu-keyring 2010.11.09

 ubuntu-keyring is not in Debian repository.
 But okay to add it to Conflicts: .

-- 
Regards,

 Hideki Yamane henrich @ debian.or.jp/org
 http://wiki.debian.org/HidekiYamane

Bug#824806: golang: random_build_path_by_golang_compiler

[Geert Stappers]

Source: golang
Severity: wishlist
User: reproducible-bui...@lists.alioth.debian.org
Usertags: toolchain
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Moin fellow DDs,

At 
https://tests.reproducible-builds.org/issues/unstable/random_build_path_by_golang_compiler_issue.html
are a few packages listed that are effected. However there are more golang 
packages.

Those few effected packages are either the last or the first packages
which are unreproducible due random build path by golang compiler.

The above URL of https://tests.reproducible-builds.org/issues/ has no bugreport
about identifier random_build_path_by_golang_compiler listed yet.

This BR is for filling that "gap".


Cheers
Geert Stappers

Bug#824730: u-boot: Please add a package for DRA7xx systems

[Vagrant Cascadian]

Control: tags 824730 pending

On 2016-05-19, Ben Hutchings wrote:
> On Thu, 2016-05-19 at 11:05 -0700, Vagrant Cascadian wrote:
>> On 2016-05-19, Ben Hutchings wrote:
>> > u-boot 2016.03 works for me on a DRA74 EVM (aka Vayu) board.  Please
>> > apply the attached patch to add a package for this platform.
>> 
>> Thanks for the patch!
>> 
>> Would you be ok with adding it to the u-boot-omap package?
> [...]
>
> That seems reasonable - the DRA7xx platform is quite similar to OMAP5.

Ok, added to both master and the experimental-2016.05 branches in git.

Also fixed the FTBFS with master by pulling in a couple more patches
From upstream, thanks for the reminder on that!

live well,
  vagrant


signature.asc
Description: PGP signature

Bug#824800: hunspell-es: fails to upgrade from 'jessie' - trying to overwrite /usr/share/hunspell/es_ES.aff

[Andreas Beckmann]

On 2016-05-19 23:52, Mattia Rizzolo wrote:
> The question is: shouldn't the update have tried to update both?  Do we
> actually try support partial upgrades?

Even if a "regular" upgrade would upgrade both packages, there is no
guarantee on ordering. So I'm trying to exercise worst-case upgrade
paths that are valid (i.e. not violating package relationships).

I'm not even sure that this falls under "partial" upgrade. If myspell-es
would get removed from testing (it has no rdepends), this bug (in
huspell-es) would get more exposure.


Andreas

Bug#824802: debian-edu-config: fails to upgrade from 'jessie' - trying to overwrite /etc/default/ldap2zone

[Andreas Beckmann]

On 2016-05-20 00:15, Wolfgang Schweer wrote:
> ldap2zone 0.2-8 dropped shipping /etc/default/ldap2zone. Debian Edu 
> Stretch needs this file to configure the DNS service and now has to 
> provide it. I guess a solution will be possible.

Breaks+Replaces: ldap2zone (<< 0.2-8~)


Andreas

Bug#824802: debian-edu-config: fails to upgrade from 'jessie' - trying to overwrite /etc/default/ldap2zone

[Wolfgang Schweer]

On Thu, May 19, 2016 at 11:43:21PM +0200, Andreas Beckmann wrote:
> >From the attached log (scroll to the bottom...):
> 
>   Selecting previously unselected package debian-edu-config.
>   Preparing to unpack .../debian-edu-config_1.901_all.deb ...
>   Unpacking debian-edu-config (1.901) ...
>   dpkg: error processing archive 
> /var/cache/apt/archives/debian-edu-config_1.901_all.deb (--unpack):
>trying to overwrite '/etc/default/ldap2zone', which is also in package 
> ldap2zone 0.2-5

Thanks for your work, Andreas.

ldap2zone 0.2-8 dropped shipping /etc/default/ldap2zone. Debian Edu 
Stretch needs this file to configure the DNS service and now has to 
provide it. I guess a solution will be possible.

Wolfgang


signature.asc
Description: Digital signature

Bug#824803: trying to overwrite '/usr/share/texlive/texmf-dist/tex/generic/hyph-utf8/loadhyph/loadhyph-de-1901.tex', which is also in package texlive-base 2015.20160320-1

[Julian Andres Klode]

On Thu, May 19, 2016 at 11:55:08PM +0200, Julian Andres Klode wrote:
> Package: texlive-lang-german
> Version: 2015.20160320-1
> Severity: serious

You cannot really conflict with texlive-lang-german from texlive-base.
You need to Conflict with the old base from lang-german.

But Maybe you can have both, I'm not sure (like Conflict from base,
and Breaks + Replaces from lang-german).

The current way definitely does not work, because it tells us to upgrade
lang-german to 2016 before upgrading base from 2015 to 2016 which
fails because base 2015 and german 2016 contain the same file.

-- 
Debian Developer - deb.li/jak | jak-linux.org - free software dev

When replying, only quote what is necessary, and write each reply
directly below the part(s) it pertains to (`inline'). Thank you.

Bug#824805: ITP: r-bioc-go.db -- annotation maps describing the entire Gene Ontology

[Andreas Tille]

Package: wnpp
Severity: wishlist
Owner: Andreas Tille 

* Package name: r-bioc-go.db
  Version : 3.3.0
  Upstream Author : Marc Carlson
* URL : 
http://bioconductor.org/packages/release/data/annotation/html/GO.db.html
* License : Artistic-2.0
  Programming Lang: GNU R
  Description : annotation maps describing the entire Gene Ontology
 This package is part of BioConductor and provides a set of annotation
 maps describing the entire Gene Ontology assembled using data from GO.


Remark: This package is needed for some unit tests of BioConductor packages.
It will be maintained by the Debian Med team at
svn://anonscm.debian.org/debian-med/trunk/packages/R/r-bioc-go.db/trunk/

Bug#824765: apt-listbugs: segfault on stretch

[Francesco Poli]

Control: severity -1 important
Control: tags -1 + moreinfo


On Thu, 19 May 2016 16:13:59 +0200 Nicolas Braud-Santoni wrote:

> Package: apt-listbugs
> Version: 0.1.17
> Severity: serious
> 
> Dear Maintainer,
> 
> I encountered an apt-listbugs segfault when it was run
>   as part of an apt invocation.

Hello Nicolas,
thanks for your bug report.

Please do not inflate the severity, though: I use apt-listbugs/0.1.17
on a number of machines, and I have never experienced any segfault.

> 
> Please find enclosed a log of what was displayed on the terminal,
>   along with the resulting coredump.

Thanks for all this information, I will soon try to understand what's
going on.

In the meanwhile, could you please do the following test?

Please invoke the interactive Ruby interpreter and issue the following
commands:

  $ irb
  irb(main):001:0> require 'unicode'
  => true
  irb(main):002:0> Unicode.width("that is")
  => 7
  irb(main):003:0> Unicode.width("cioè")
  => 4
  irb(main):004:0> exit


Please let me know, thanks.


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


pgpNmJdSG0Kxa.pgp
Description: PGP signature

Bug#812948: libbson-doc: contains manpages with generic names: index(3), installing(3), errors(3)

[Andreas Beckmann]

Followup-For: Bug #812948
Control: retitle -1 libbson-doc: contains manpages with generic names: 
index(3), installing(3), errors(3)

Another very generic name is errors.3.gz, clashing with libcoin80-doc
from jessie.

Several packages are shipping $PKG_errors.3.gz to avoid such
collisions.


Andreas

Bug#824804: update-rc.d: may invoke insserv without -f flag when initscripts is installed but not configured

[Felipe Sateler]

X-Debbugs-Cc: andr...@fatal.se
Package: init-system-helpers
Version: 1.33
Severity: normal

Filing so that this is tracked somewhere.

update-rc.d currently has support for invoking insserv with the -f flag,
to allow initscripts-less installations. This should allow packages to drop
dependencies on the initscripts package. However, this does not work if the
dependency is dropped, because now apt/dpkg can choose to configure the
package before it configures initscripts. This leads to the situation that
/etc/init.d/mountkernfs.sh exists (and thus invoke-rc.d does not pass -f flag),
but the links in /etc/rc?.d/S??mountkernfs.sh are not created yet, and then
insserv fails.

A practical example of this happened when util-linux dropped the initscripts
dependency on #823665.

Possible solutions:

1. Unconditionally pass -f to insserv. This has some appeal to me as I don't
   think packaging bugs should in general abort installations, but I can see
   the argument for preserving the check.
2. Extend the check to the links (ie, check if
   `glob /etc/rc?.d/S??mountkernfs.sh` is not empty.
3. Consult the dpkg database via dpkg-query to determine if initscripts has been
   configured
4. Have dpkg/apt support ordering without dependencies (not likely to
   happen soon).


I think (2) is the easiest and fastest way out of this problem, but
(4) would be the real fix.

-- 

Saludos,
Felipe Sateler

Bug#824794: python-snuggs: FTBFS: ../../../test_snuggs.py:154: AssertionError

[Sebastiaan Couwenberg]

Control: tags -1 pending

Hi Chris,

Thanks for reporting this issue.

It seems the recent update to NumPy 1.11.0 has changed a couple of
exceptions. I've added a patch to support the new exceptions in the
tests in question and forwarded it upstream.

The new python-snuggs revision is on its way to unstable.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Bug#824800: hunspell-es: fails to upgrade from 'jessie' - trying to overwrite /usr/share/hunspell/es_ES.aff

[Mattia Rizzolo]

On Thu, May 19, 2016 at 11:35:47PM +0200, Andreas Beckmann wrote:
> during a test with piuparts I noticed your package fails to upgrade from
> 'jessie'.
> It installed fine in 'jessie', then the upgrade to 'stretch' fails
> because it tries to overwrite other packages files without declaring a
> Breaks+Replaces relation.
> 
> >From the attached log (scroll to the bottom...):
> 
>   Selecting previously unselected package hunspell-es.
>   Preparing to unpack .../hunspell-es_1%3a5.1.3-1_all.deb ...
>   Unpacking hunspell-es (1:5.1.3-1) ...
>   dpkg: error processing archive 
> /var/cache/apt/archives/hunspell-es_1%3a5.1.3-1_all.deb (--unpack):
>trying to overwrite '/usr/share/hunspell/es_ES.aff', which is also in 
> package myspell-es 1.11-9

Guess I can add something here too.  That would be a conflicts, though.
myspell-es in stretch has a "Conflicts: hunspell-es" that clearly
prevents this situation in stretch.

The question is: shouldn't the update have tried to update both?  Do we
actually try support partial upgrades?

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#824801: option to force native build

[Eduard Bloch]

Package: git-buildpackage
Version: 0.7.4
Severity: wishlist

Hi,

I remember having reported a similar issue a couple of years ago and
back then it was closed with a useless coment. This time I stumbled upon
it again and still cannot find a SANE solution. With SANE, I mean
user-friendly. I, as user, wish to have an option to make a test build.
Without having an upstream tarball!
(that is the key point. The debian branch is a fork of the upstream
branch after all, it should just work).

WRT dpkg-buildpackage itself, I can easily force it to act like on a
native package and just build me my binary packages. But with gbp, this
simple task becomes PITA: it wants me to have some upstream reference or
else... (see below).

Sorry, there really should be an easy and user-friendly way to let me
just build it, no matter whether there is an upstream tag or not. I
did RTFM and nothing ringed a bell there. If there is an easy way,
please document it properly.



dh_clean
rm -rf debian/apt-cacher-ng.service debian/apt-cacher-ng.tmpfile 
dbgen/dbgenerator.* dbgen/dbupdate
debconf-updatepo
...
gbp:info: Orig tarball 'apt-cacher-ng_0.9.3.orig.tar.xz' not found at 
'../tarballs/'
gbp:error: Pristine-tar couldn't checkout "apt-cacher-ng_0.9.3.orig.tar.xz": 
fatal: Path 'apt-cacher-ng_0.9.3.orig.tar.xz.delta' does not exist in 
'refs/heads/pristine-tar'
pristine-tar: git show 
refs/heads/pristine-tar:apt-cacher-ng_0.9.3.orig.tar.xz.delta failed

Regards,
Eduard.

-- 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.5.0-trunk-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/bash
Init: sysvinit (via /sbin/init)

Versions of packages git-buildpackage depends on:
ii  devscripts2.16.4
ii  git   1:2.8.1-1
ii  man-db2.7.5-1
ii  python-dateutil   2.4.2-1
ii  python-pkg-resources  20.10.1-1
ii  python-six1.10.0-3
pn  python:any

Versions of packages git-buildpackage recommends:
ii  cowbuilder   0.79
ii  pbuilder 0.224
ii  pristine-tar 1.33
ii  python-requests  2.9.1-3

Versions of packages git-buildpackage suggests:
ii  python-notify  0.1.1-4
ii  sudo   1.8.15-1.1
ii  unzip  6.0-20

-- no debconf information

-- 
 Verdammte Toffifee-Kacke. Die untere Schale aus 'ner 48er-Packung
rauswuehlen ist scheisse.
 towo: ich enthalte mich mal eines kommentars
 Mh?
 Toffifee-Dev, oder was?

Bug#824802: debian-edu-config: fails to upgrade from 'jessie' - trying to overwrite /etc/default/ldap2zone

[Andreas Beckmann]

Package: debian-edu-config
Version: 1.901
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'jessie'.
It installed fine in 'jessie', then the upgrade to 'sid' fails
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.

See policy 7.6 at
https://www.debian.org/doc/debian-policy/ch-relationships.html#s-replaces

>From the attached log (scroll to the bottom...):

  Selecting previously unselected package debian-edu-config.
  Preparing to unpack .../debian-edu-config_1.901_all.deb ...
  Unpacking debian-edu-config (1.901) ...
  dpkg: error processing archive 
/var/cache/apt/archives/debian-edu-config_1.901_all.deb (--unpack):
   trying to overwrite '/etc/default/ldap2zone', which is also in package 
ldap2zone 0.2-5


cheers,

Andreas


ldap2zone=0.2-5_debian-edu-config=1.901.log.gz
Description: application/gzip

Bug#804623: osptoolkit: SSLv3 method

[Sebastian Andrzej Siewior]

On 2015-11-14 14:10:27 [+0100], Kurt Roeckx wrote:
> You should change the call from SSLv3_client_method() to
> SSLv23_client_method().
> 
> The SSLv3_* call only talks SSLv3 while the SSLv23_* call is the
> only one supporting multiple protocol version.
> 
> I suggest you also get that fixed in the stable branches.

Dear maintainer, do you plan to update the package? I see that upstream
is currently at 4.11.1 and is using TLSv1 version. This works while
SSLv23 is the prefered method.

However, in stable (and unstable) you have the SSLv3 version and since
openssl 1.0.1j-1 v3 has been disabled which means you package stopped
working with SSL since then.

> Kurt

Sebastian

Bug#824800: hunspell-es: fails to upgrade from 'jessie' - trying to overwrite /usr/share/hunspell/es_ES.aff

[Andreas Beckmann]

Package: hunspell-es
Version: 1:5.1.3-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'jessie'.
It installed fine in 'jessie', then the upgrade to 'stretch' fails
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.

See policy 7.6 at
https://www.debian.org/doc/debian-policy/ch-relationships.html#s-replaces

>From the attached log (scroll to the bottom...):

  Selecting previously unselected package hunspell-es.
  Preparing to unpack .../hunspell-es_1%3a5.1.3-1_all.deb ...
  Unpacking hunspell-es (1:5.1.3-1) ...
  dpkg: error processing archive 
/var/cache/apt/archives/hunspell-es_1%3a5.1.3-1_all.deb (--unpack):
   trying to overwrite '/usr/share/hunspell/es_ES.aff', which is also in 
package myspell-es 1.11-9
  Errors were encountered while processing:
   /var/cache/apt/archives/hunspell-es_1%3a5.1.3-1_all.deb


cheers,

Andreas


myspell-es=1.11-9_hunspell-es=1%5.1.3-1.log.gz
Description: application/gzip

Bug#824799: youtube-dl: please package youtube release 2016.05.16 which upstream released some days ago.

[shirish शिरीष]

Package: youtube-dl
Version: 2016.02.22-1
Severity: wishlist

Dear Maintainer,
Please package release 2016.05.16 which were released by upstream few days.

Looking forward to it.

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

Kernel: Linux 4.5.0-2-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 youtube-dl depends on:
ii  python-pkg-resources  20.10.1-1
pn  python:any

Versions of packages youtube-dl recommends:
ii  aria2 1.21.0-1
ii  curl  7.47.0-1
ii  ffmpeg7:3.0.2-2
ii  mpv   0.14.0-1+b2
ii  rtmpdump  2.4+20151223.gitfa8646d.1-1
ii  wget  1.17.1-2

youtube-dl suggests no packages.

-- 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#824707: systemd: I get fsck's every other boot: due to systemd-timesyncd not updating hwclock?

[Manuel Bilderbeek]

Hi,

On 19-05-16 23:04, Michael Biebl wrote:

Looks like I need to have systemd-timesync run *before* systemd-fsck!?


If your hwclock drifts that much, maybe
/etc/e2fsck.conf:
 [options]
 broken_system_clock=1

(as referenced in my earlier reply) is an option.
Can you try that?


Sure, but won't that effectively disable fsck'ing based on 'time since 
last check'?


Also, is it normal that that config file doesn't exist yet?

--
Kind regards,

Manuel

Bug#824766: armory: New home for armory and new upstream release

[Joseph Bisch]

On Thu, May 19, 2016 at 09:33:17AM -0600, Joseph Bisch wrote:
> On Thu, May 19, 2016 at 04:15:02PM +0200, Diederik de Haas wrote:
> > As can be read in the links from this issue
> > https://github.com/etotheipi/BitcoinArmory/issues/325 Armory
> > Technologies has stopped working on armory, at least for the time being.
> > As can be read in the linked threads, there is now a fork which seemed
> > to be (somewhat) official, namely
> > https://github.com/goatpig/BitcoinArmory and there have been several
> > releases there, the latest being 0.94.1.
> > 
> > Maybe it's a good idea to switch the Debian package to the fork?
> 
> Yes, I would say that Goatpig's fork is the most official version of
> Armory in development currently. He was the defacto maintainer of the
> open source version of Armory at Armory Technologies up until the
> company stopped development.
> 
> I won't be able to get to this myself before the weekend at the
> earliest (just moved and going to be starting a new job). Patches to
> package 0.94.1 are welcome from anyone. Just be sure to base the
> packaging off of the pkg-bitcoin repo[0].

I actually got to take a look at this. I decided not to package new
versions of Armory until the git tags are signed to verify the integrity
of the source code (e.g. so GitHub or someone with access to GitHub's
servers cannot modify the code). I have filed a bug[0] upstream asking
for Goatpig to sign tags. I hope to be able to package 0.94.1 and future
versions of Armory soon, but without signed tags, I think it would be
irresponsible of me to package financial software. I just filed the bug
upstream, so it might be a while before I hear back from Goatpig.

[0] - https://github.com/goatpig/BitcoinArmory/issues/40

Joseph

Bug#824798: coreutils: ls still adding single quotes (in error messages)

[Ken McDonell]

Package: coreutils
Version: 8.25-2
Severity: normal

Dear Maintainer,

This is related to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=810295
that has (thankfully) been fixed by reverting the coreutils quoting change.

This is fixed ...
kenj@vm07:/tmp$ touch foo 'foo bar'
kenj@vm07:/tmp$ ls foo*
foo  foo bar

But this remains broken (with respect to 30+ years of history)
kenj@vm07:/tmp$ ls foo-bar
ls: cannot access 'foo-bar': No such file or directory

The quotes around the filename just should not be there.

This is a big deal because it breaks a very large number of QA tests
that we have that compare actual versus expected output for PCP
(www.pcp.io) ... and many of these tests use sh and ls and some
expect files to be not found ... these tests fail on Debian stretch
while passing on hundreds of other platforms.

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

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

Versions of packages coreutils depends on:
ii  libacl12.2.52-3
ii  libattr1   1:2.4.47-2
ii  libc6  2.22-7
ii  libselinux12.5-2
ii  multiarch-support  2.22-7

coreutils recommends no packages.

coreutils suggests no packages.

-- no debconf information

Bug#824796: hunspell-lt: should break older myspell-lt (not conflict against it)

[Mattia Rizzolo]

control: tag -1 sid

On Thu, May 19, 2016 at 10:50:04PM +0200, Jonas Smedegaard wrote:
> myspell-lt is now (since 1.2.1-7 and possibly 1.2.1-6 too) a transitional
> package depending on hunspell-lt. Consequently hunspell-lt need to change
> from conflicting against myspell-lt to breaking older versions.

Actually, I had already done that when I uploaded myspell-lt as
transitional, but I was waiting on some other changes for lo-dicts.
https://anonscm.debian.org/git/pkg-openoffice/libreoffice-dictionaries.git/commit/?id=fd810ac171afc94a2ae66d37e99f4998526fc6b7

> Severity set to serious because currently it is not possible to install
> these packages: icedove-l10n-lt firefox-l10n-lt firefox-esr-l10n-lt 
> iceowl-l10n-lt.

yeah, guess serious is fine... It's gonna be closed soon enough :P
That said, I expect src:ispell-lt (which builds myspell-lt) to not
migrate to testing until the fixed lo-dicts without the conflict will
migrate too, so this situation should be restricted in unstable no
matter what.

> Arguably all those packages should instead be fixed, but fixing one
> package is likely faster to do at first.  Or reassign if you disagree...

yeah, well... I'm not planning on removing myspell-lt before stretch
anyway, so I'm not going to file bugs right now, but feel free to, if
you want.

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#824707: systemd: I get fsck's every other boot: due to systemd-timesyncd not updating hwclock?

[Michael Biebl]

Am 19.05.2016 um 21:30 schrieb Manuel Bilderbeek:
> 
> -- Logs begin at ma 2028-05-22 12:37:10 CEST, end at do 2016-05-19
> 21:22:23 CEST. --
> 
> Looks like I need to have systemd-timesync run *before* systemd-fsck!?

If your hwclock drifts that much, maybe
/etc/e2fsck.conf:
[options]
broken_system_clock=1

(as referenced in my earlier reply) is an option.
Can you try that?


Regards,
Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#824797: unattended-upgrades: does not recover from (temporarily) broken packages (Cache has broken packages, exiting)

[Jens Thiele]

Package: unattended-upgrades
Version: 0.83.3.2+deb8u1
Severity: normal

Dear Maintainer,

Recently the samba packages in jessie had a problem with a file
conflict and the unattended upgrade failed:

>From the logs (sorry for the german):
2016-04-15 07:39:11,224 INFO Packages that will be upgraded: libsmbclient 
libwbclient0 python-samba samba samba-common samba-common-bin 
samba-dsdb-modules samba-libs
2016-04-15 07:39:11,227 INFO Dpkg-Protokoll wird nach 
»/var/log/unattended-upgrades/unattended-upgrades-dpkg.log« geschrieben
2016-04-15 07:40:19,320 ERROR Installation der Upgrades fehlgeschlagen!
2016-04-15 07:40:19,323 ERROR Fehlermeldung: »installArchives() failed«
2016-04-15 07:40:19,325 ERROR Dpkg gab einen Fehler zurück. Siehe 
»/var/log/unattended-upgrades/unattended-upgrades-dpkg.log« für Einzelheiten

Entpacken von samba-libs:armhf (2:4.2.10+dfsg-0+deb8u2) über 
(2:4.2.10+dfsg-0+deb8u1) ...
dpkg: Fehler beim Bearbeiten des Archivs 
/var/cache/apt/archives/samba-libs_2%3a4.2.10+dfsg-0+deb8u2_armhf.deb 
(--unpack):
Versuch, »/usr/lib/arm-linux-gnueabihf/samba/libsmbd-base.so.0« zu 
überschreiben, welches auch in Paket samba 2:4.2.10+dfsg-0+deb8u1 ist
dpkg-deb: Fehler: Unterprozess einfügen wurde durch Signal (Datenübergabe 
unterbrochen (broken pipe)) getötet

Afterwards unattended-upgrades stopped updating the system, reporting
"Cache has broken packages, exiting":

# LC_ALL=C unattended-upgrade -v --apt-debug -d
Initial blacklisted packages:
Initial whitelisted packages:
Starting unattended upgrades script
Allowed origins are: ['origin=Debian,n=jessie', 'origin=karme.de,n=jessie']
ignoring ver '' with 
priority < 0
adjusting candidate version: ''
Cache has broken packages, exiting
Cache has broken packages, exiting

In the meantime the samba packages were fixed and I would expect
unattended-upgrade to install the new versions.
Unfortunately one has to run apt-get update && apt-get -f upgrade
first, to get it going again.

-- System Information:
Debian Release: 8.4
  APT prefers stable
  APT policy: (990, 'stable')
Architecture: armhf (armv7l)

Kernel: Linux 3.16.0-4-armmp-lpae (SMP w/2 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)

Versions of packages unattended-upgrades depends on:
ii  apt1.0.9.8.3
ii  apt-utils  1.0.9.8.3
ii  debconf [debconf-2.0]  1.5.56
ii  init-system-helpers1.22
ii  lsb-base   4.1+Debian13+nmu1
ii  lsb-release4.1+Debian13+nmu1
ii  python33.4.2-2
ii  python3-apt0.9.3.12
ii  ucf3.0030
ii  xz-utils   5.1.1alpha+20120614-2+b3

unattended-upgrades recommends no packages.

Versions of packages unattended-upgrades suggests:
ii  bsd-mailx  8.1.2-0.20141216cvs-2
ii  exim4-daemon-light [mail-transport-agent]  4.84.2-1

-- Configuration Files:
/etc/apt/apt.conf.d/50unattended-upgrades changed:
// Unattended-Upgrade::Origins-Pattern controls which packages are
// upgraded.
//
// Lines below have the format format is "keyword=value,...".  A
// package will be upgraded only if the values in its metadata match
// all the supplied keywords in a line.  (In other words, omitted
// keywords are wild cards.) The keywords originate from the Release
// file, but several aliases are accepted.  The accepted keywords are:
//   a,archive,suite (eg, "stable")
//   c,component (eg, "main", "crontrib", "non-free")
//   l,label (eg, "Debian", "Debian-Security")
//   o,origin(eg, "Debian", "Unofficial Multimedia Packages")
//   n,codename  (eg, "jessie", "jessie-updates")
// site  (eg, "http.debian.net")
// The available values on the system are printed by the command
// "apt-cache policy", and can be debugged by running
// "unattended-upgrades -d" and looking at the log file.
//
// Within lines unattended-upgrades allows 2 macros whose values are
// derived from /etc/debian_version:
//   ${distro_id}Installed origin.
//   ${distro_codename}  Installed codename (eg, "jessie")
Unattended-Upgrade::Origins-Pattern {
// Codename based matching:
// This will follow the migration of a release through different
// archives (e.g. from testing to stable and later oldstable).
//  "o=Debian,n=jessie";
//  "o=Debian,n=jessie-updates";
//  "o=Debian,n=jessie-proposed-updates";
//  "o=Debian,n=jessie,l=Debian-Security";
// Archive or Suite based matching:
// Note that this will silently match a different release after
// migration to the specified archive (e.g. testing becomes the
// new stable).
//  "o=Debian,a=stable";
//  "o=Debian,a=stable-updates";
//  "o=Debian,a=proposed-updates";
"origin=Debian,n=${distro_codename}";
"origin=karme.de,n=${distro_codename}";
};
// List of packages to not update (regexp are 

Bug#824796: hunspell-lt: should break older myspell-lt (not conflict against it)

[Jonas Smedegaard]

Package: hunspell-lt
Version: 1:5.1.3-1
Severity: serious
Tags: l10n

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

myspell-lt is now (since 1.2.1-7 and possibly 1.2.1-6 too) a transitional
package depending on hunspell-lt. Consequently hunspell-lt need to change
from conflicting against myspell-lt to breaking older versions.

Severity set to serious because currently it is not possible to install
these packages: icedove-l10n-lt firefox-l10n-lt firefox-esr-l10n-lt 
iceowl-l10n-lt.

Arguably all those packages should instead be fixed, but fixing one
package is likely faster to do at first.  Or reassign if you disagree...

 - Jonas

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJXPib4AAoJECx8MUbBoAEh+wUP/3KVuK/13Xqkn0jWyeCbY6NF
3vht+vpgAhGT0Vp1DBTM16k0mHDwd+T0v7GAb2Pv1rvsK0ZJ7tXZ3WaObRWSfR35
o+Otu1/rCeqonbxb3MdenHc1OJ4bjUfZ4ZqQ+XYAHJLp4ywTa2EBJ84L2xMIJUXQ
BDP26dKjW4SHWB7oWa29oGRA9hJBITYG2pF+aYKHDejoqGb/CqpWEMxPHrN7UJzB
Hi2hFfJ6Yyd6JNabHOIZovgroQqL961JRxJRj3xG6UNpfkckgBzPeLSRZp+Yn/mD
x7/dVFthXKvzMPwDUqUMCyCMoLbLpZ7i+deVGqDGxiQ2y4HbbPfHDHsVofHfzOs4
gtRcEvPAYrX5kn5APK326hKckKYTr+1qNeHKhFs78uLYJIC3ylXiOb4JZmf14BDx
YRGkLXTuUXSMFseZUfuN007picOUfmfx4k5mpwAWL9XIDrons3JezRrpG0Z2xHlI
8kWQ+qYrwWcTgzGno7YFCR1q2Rn3tYcPUTVYwPlqdr7a2TOfpUkNR5Yjn19+T/Vs
mOYksh5zWQP5IXZi+k0ZkBjjkkZrRdLN6phPcxQlLXU8Uypu63i6g3/SKi1XUisP
v+zvPvaL/UujzCtTVKGdm/lHbT1fgYI0IxLp+HmNcwPenszOwv4i/5ECEoI6X5QD
o0p0v1jmYMOb26Kokx0d
=l1jQ
-END PGP SIGNATURE-

Bug#824795: smartmontools: remove obsolete /usr/share/man/man8/update-smart-drivedb.8.gz man page

[Bjørn Mork]

Package: smartmontools
Version: 6.4+svn4214-1
Severity: minor

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Looks like this was left over when removing the update-smart-drivedb
script:

 bjorn@nemi:~$  dpkg -L smartmontools|grep update
 /usr/share/man/man8/update-smart-drivedb.8.gz


Bjørn

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

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

Versions of packages smartmontools depends on:
ii  debianutils  4.4+b1
ii  init-system-helpers  1.33
ii  libc62.22-9
ii  libcap-ng0   0.7.4-2
ii  libgcc1  1:6.1.1-3
ii  libselinux1  2.3-2
ii  libstdc++6   6.1.1-3
ii  lsb-base 4.1+Debian13+nmu1

Versions of packages smartmontools recommends:
ii  bsd-mailx [mailx]  8.1.2-0.20141216cvs-2

Versions of packages smartmontools suggests:
pn  gsmartcontrol   
pn  smart-notifier  

- -- no debconf information

-BEGIN PGP SIGNATURE-

iEYEARECAAYFAlc+I88ACgkQ10rqkowbIsm3cwCfS6Uh14dLM3/Aht695SmfprEv
uEwAnA4WU+Pbyg5QbCvKkL1h1gOt/wiP
=G+re
-END PGP SIGNATURE-

Bug#824794: python-snuggs: FTBFS: ../../../test_snuggs.py:154: AssertionError

[Chris Lamb]

Source: python-snuggs
Version: 1.3.1-2
Severity: serious
Justification: fails to build from source
User: reproducible-bui...@lists.alioth.debian.org
Usertags: ftbfs
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Dear Maintainer,

python-snuggs fails to build from source in unstable/amd64:

  [..]

  dh_testdir
  dh_testroot
  dh_prep
  dh_testdir
  dh_testroot
  dh_install
  dh_installdocs
  dh_installchangelogs
  dh_compress
  dh_fixperms
  dh_installdeb
  dh_gencontrol
  dh_md5sums
  dh_builddeb
  dpkg-deb: building package 'python-snuggs-build-deps' in 
'../python-snuggs-build-deps_1.3.1-2_all.deb'.
  
  The package has been created.
  Attention, the package has been created in the current directory,
  not in ".." as indicated by the message above!
  Selecting previously unselected package python-snuggs-build-deps.
  (Reading database ... 23081 files and directories currently installed.)
  Preparing to unpack python-snuggs-build-deps_1.3.1-2_all.deb ...
  Unpacking python-snuggs-build-deps (1.3.1-2) ...
  Reading package lists...
  Building dependency tree...
  Reading state information...
  Correcting dependencies... Done
  The following additional packages will be installed:
libblas-common libblas3 libgfortran3 liblapack3 python-all python-click
python-colorama python-numpy python-py python-pyparsing python-pytest
python-setuptools python3-all python3-click python3-colorama python3-numpy
python3-pkg-resources python3-py python3-pyparsing python3-pytest
python3-setuptools
  Suggested packages:
gfortran python-dev python-nose python-numpy-dbg python-numpy-doc subversion
python-pytest-xdist python-pyparsing-doc python-mock python-setuptools-doc
python3-dev python3-nose python3-numpy-dbg
  The following NEW packages will be installed:
libblas-common libblas3 libgfortran3 liblapack3 python-all python-click
python-colorama python-numpy python-py python-pyparsing python-pytest
python-setuptools python3-all python3-click python3-colorama python3-numpy
python3-pkg-resources python3-py python3-pyparsing python3-pytest
python3-setuptools
  0 upgraded, 21 newly installed, 0 to remove and 0 not upgraded.
  1 not fully installed or removed.
  Need to get 7155 kB of archives.
  After this operation, 31.7 MB of additional disk space will be used.
  Get:1 http://httpredir.debian.org/debian sid/main amd64 python-setuptools all 
20.10.1-1 [203 kB]
  Get:2 http://httpredir.debian.org/debian sid/main amd64 python-all amd64 
2.7.11-1 [936 B]
  Get:3 http://httpredir.debian.org/debian sid/main amd64 libgfortran3 amd64 
6.1.1-3 [265 kB]
  Get:4 http://httpredir.debian.org/debian sid/main amd64 libblas-common amd64 
3.6.0-2 [13.5 kB]
  Get:5 http://httpredir.debian.org/debian sid/main amd64 libblas3 amd64 
3.6.0-2 [158 kB]
  Get:6 http://httpredir.debian.org/debian sid/main amd64 liblapack3 amd64 
3.6.0-2 [1949 kB]
  Get:7 http://httpredir.debian.org/debian sid/main amd64 python-numpy amd64 
1:1.11.0-1 [1770 kB]
  Get:8 http://httpredir.debian.org/debian sid/main amd64 python3-all amd64 
3.5.1-3 [936 B]
  Get:9 http://httpredir.debian.org/debian sid/main amd64 python3-numpy amd64 
1:1.11.0-1 [1769 kB]
  Get:10 http://httpredir.debian.org/debian sid/main amd64 
python3-pkg-resources all 20.10.1-1 [112 kB]
  Get:11 http://httpredir.debian.org/debian sid/main amd64 python3-setuptools 
all 20.10.1-1 [122 kB]
  Get:12 http://httpredir.debian.org/debian sid/main amd64 python-py all 
1.4.31-1 [81.8 kB]
  Get:13 http://httpredir.debian.org/debian sid/main amd64 python-pytest all 
2.9.1-1 [166 kB]
  Get:14 http://httpredir.debian.org/debian sid/main amd64 python3-py all 
1.4.31-1 [81.9 kB]
  Get:15 http://httpredir.debian.org/debian sid/main amd64 python3-pytest all 
2.9.1-1 [166 kB]
  Get:16 http://httpredir.debian.org/debian sid/main amd64 python-colorama all 
0.3.7-1 [25.7 kB]
  Get:17 http://httpredir.debian.org/debian sid/main amd64 python-click all 
6.6-1 [56.1 kB]
  Get:18 http://httpredir.debian.org/debian sid/main amd64 python3-colorama all 
0.3.7-1 [18.1 kB]
  Get:19 http://httpredir.debian.org/debian sid/main amd64 python3-click all 
6.6-1 [56.2 kB]
  Get:20 http://httpredir.debian.org/debian sid/main amd64 python-pyparsing all 
2.1.4+dfsg1-1 [70.4 kB]
  Get:21 http://httpredir.debian.org/debian sid/main amd64 python3-pyparsing 
all 2.1.4+dfsg1-1 [70.5 kB]
  Fetched 7155 kB in 0s (108 MB/s)
  Selecting previously unselected package python-setuptools.
  (Reading database ... 
(Reading database ... 5%
(Reading database ... 10%
(Reading database ... 15%
(Reading database ... 20%
(Reading database ... 25%
(Reading database ... 30%
(Reading database ... 35%
(Reading database ... 40%
(Reading database ... 45%
(Reading database ... 50%
(Reading database ... 55%
(Reading database ... 60%
(Reading database ... 65%
(Reading database ... 70%
(Reading database ... 75%
(Reading database ... 80%
(Reading database ... 85%
(Reading database ... 90%
(Reading database ... 95%

Bug#821259: libjpeg-progs: jpegtran -drop patch missing

[Bill Allombert]

On Sun, Apr 17, 2016 at 05:54:44AM +0200, Ram Kromberg wrote:
> Package: libjpeg-progs
> Version: 1:9b-1
> Severity: wishlist
> 
> Dear Maintainer,
> 
> Bug #160390 either regressed or was erroneously closed to begin with.
> The -drop patch, as released in http://jpegclub.org/jpegtran/ under
> http://jpegclub.org/droppatch.v9b.tar.gz is not merged into the
> package.

Hello Ram,

Someone (not me) closed this bug by mistake. Sorry about that.

> It is quite trivial to patch and compile the package following the
> usual "sudo apt-get build-dep libjpeg-progs", "apt-get source
> libjpeg-progs" and simply overriding the three source files to apply
> the patch. "configure" and "make install" compile and deploy to
> /usr/local/ successfully. Once deployed, The -drop lossless merging
> functionality works as expected.

As I understand the issue is that the resulting image is not displayed
correctly when using the non-patched libjpeg.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#824793: mount.8: refers to package nfs-utils

[Greg Wooledge]

Package: mount
Version: 2.25.2-6
Severity: normal

In the "Mount options for nfs and nfs4" section, the mount(8) man page
says "nfs-utils package must be installed".  It should say nfs-common
instead.

-- System Information:
Debian Release: 8.4
  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/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 mount depends on:
ii  libc6  2.19-18+deb8u4
ii  libmount1  2.25.2-6
ii  libselinux12.3-2
ii  libsmartcols1  2.25.2-6

mount recommends no packages.

Versions of packages mount suggests:
ii  nfs-common  1:1.2.8-9

-- debconf-show failed

Bug#824792: new upstream release: 0.8.0

[Ondřej Surý]

Package: src:librabbitmq
Version: 0.7.1-1
Severity: wishlist

Hi folks,

looks like there's a new upstream version (since Apr 10).  Let me know
if you don't have time, I could prepare NMU (and fix the missing .a in
one go).

Cheers,
Ondrej

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

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

Bug#487946: ThankYou

[Justin Gerulis]

Your welcome.
On May 19, 2016 3:34 PM, "justingerulis27"  wrote:

> Urgent__Your__GiftCard__
>
>
> Congatulations___justingerulis27
>
>
> __0pen__lmmediatIy__
>
>
> [1ooousd]__GiftCard__Pending__ [u][n][s][u][b]
> [o][p][t][0][u][t]
> 
> 
> 
> éç"à_(ç"_'(
>
>

Bug#824263: cmake: please sort file lists from file(GLOB ...)

[Reiner Herrmann]

The patch has now been applied in cmake's next branch:
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=edcccde7


signature.asc
Description: Digital signature

Bug#824791: texlive-bin also FTBFS on i386 using gcc-6

[Preuße]

Package:  texlive-bin
Version: 2016.20160513.41080-2
Severity: important

For what it's worth, I've also just seen a test failure in tests/upmendex on
i386, during a test rebuild of all packages using gcc-defaults from
experimental. This is not reproducible for all arches, e.g. amd64 is not 
affected.

FAIL: tests/upmendex


This is upmendex version 0.50 (TeX Live 2016).
Scanning input file ../../../texk/upmendex/tests/foo.idxdone (3
entries accepted, 0 rejected).
3 entries accepted, 0 rejected.
Sorting indexdone(0 comparisons).
Sorting pagesdone(4 comparisons).
Making index filedone.
0 warnings, written in foo.ilg1.
Output written in foo.ind1.
This is upmendex version 0.50 (TeX Live 2016).
Scanning dictionary file ../../../texk/upmendex/tests/uni.dictdone.
Scanning input file ../../../texk/upmendex/tests/uni.idxdone (8
entries accepted, 0 rejected).
8 entries accepted, 0 rejected.
Sorting indexdone(24 comparisons).
Sorting pagesdone(0 comparisons).
Making index file.Segmentation fault
FAIL tests/upmendex.test (exit status: 1)
-- 
Hilmar

Bug#824627: [pkg-GD-devel] Bug#824627: libgd2: CVE-2015-8874

[Ondřej Surý]

Thanks Salvatore,

I'll take care of it tomorrow, and I'll push upstream to release a
bugfix release as well.

Cheers,
-- 
Ondřej Surý 
Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server
Knot Resolver (https://www.knot-resolver.cz/) – secure, privacy-aware,
fast DNS(SEC) resolver
Vše pro chleba (https://vseprochleba.cz) – Potřeby pro pečení chleba
všeho druhu

On Wed, May 18, 2016, at 08:21, Salvatore Bonaccorso wrote:
> Source: libgd2
> Version: 2.1.0-5
> Severity: important
> Tags: security upstream patch
> 
> Hi,
> 
> the following vulnerability was published for libgd2.
> 
> CVE-2015-8874[0]:
> | Stack consumption vulnerability in GD in PHP before 5.6.12 allows
> | remote attackers to cause a denial of service via a crafted
> | imagefilltoborder call.
> 
> It can be reproduced with the testcase from the php commit.
> 
> If you fix the vulnerability please also make sure to include the
> CVE (Common Vulnerabilities & Exposures) id in your changelog entry.
> 
> For further information see:
> 
> [0] https://security-tracker.debian.org/tracker/CVE-2015-8874
> 
> Please adjust the affected versions in the BTS as needed. I have not
> checked older versions thatn the one in jessie.
> 
> Regards,
> Salvatore
> 
> -- 
> pkg-GD-devel mailing list
> pkg-gd-de...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-gd-devel

Bug#824260: texlive-bin also FTBFS on i386 using gcc-6

[Preuße]

Package:  texlive-bin
Version: 2016.20160513.41080-2
Severity: important

For what it's worth, I've also just seen a test failure in tests/upmendex on
i386, during a test rebuild of all packages using gcc-defaults from
experimental. This is not reproducible for all arches, e.g. amd64 is not 
affected.

FAIL: tests/upmendex


This is upmendex version 0.50 (TeX Live 2016).
Scanning input file ../../../texk/upmendex/tests/foo.idxdone (3
entries accepted, 0 rejected).
3 entries accepted, 0 rejected.
Sorting indexdone(0 comparisons).
Sorting pagesdone(4 comparisons).
Making index filedone.
0 warnings, written in foo.ilg1.
Output written in foo.ind1.
This is upmendex version 0.50 (TeX Live 2016).
Scanning dictionary file ../../../texk/upmendex/tests/uni.dictdone.
Scanning input file ../../../texk/upmendex/tests/uni.idxdone (8
entries accepted, 0 rejected).
8 entries accepted, 0 rejected.
Sorting indexdone(24 comparisons).
Sorting pagesdone(0 comparisons).
Making index file.Segmentation fault
FAIL tests/upmendex.test (exit status: 1)
-- 
Hilmar

Bug#824707: systemd: I get fsck's every other boot: due to systemd-timesyncd not updating hwclock?

[Manuel Bilderbeek]

Hi,

Thanks for taking interest in this annoying problem. Today I again got 
an fsck at boot...


On 18-05-16 23:35, Michael Biebl wrote:

fsck.ext[234] should no longer run an fsck because of that.
Which version of e2fsprogs have you installed?


Should be latest in testing:

ii  e2fsprogs1.43~WIP.2016.03.15-2 
  amd64ext2/ext3/ext4 file system utilities




What are the contents of /etc/adjtime?


$ cat /etc/adjtime
0.00 1463602260 0.00
1463602260
UTC


In any case, that sounds like a e2fsprogs related problem.


Anything else I can do to gather more information to find the source of 
the problem?


On 19-05-16 00:03, Martin Pitt wrote:
> timesyncd does *not* write to the hw clock directly. The kernel has
> done that by itself now every 11 minutes for a fair while now, if the
> hw clock is in UTC. (If it's not, then timesyncd tells the kernel to
> not sync). See manager_adjust_clock() in
>
> 
https://github.com/systemd/systemd/blob/master/src/timesync/timesyncd-manager.c#L314


How can I tell that the kernel should sync it?

Perhaps this:

$ timedatectl
  Local time: do 2016-05-19 21:21:30 CEST
  Universal time: do 2016-05-19 19:21:30 UTC
RTC time: do 2016-05-19 19:21:30
   Time zone: Europe/Amsterdam (CEST, +0200)
 Network time on: yes
NTP synchronized: yes
 RTC in local TZ: no


FYI, this is the log entry of today's boot:

mei 22 12:37:10 sonata systemd-fsck[343]: /dev/sda1 has gone 4385 days 
without being checked, check forced.


... well at least now it logs why it's doing the fsck...

mei 22 12:41:25 sonata systemd-fsck[343]: /dev/sda1: 858066/3055616 
files (7.5% non-contiguous), 8046780/12207384 blocks

mei 22 12:41:26 sonata systemd[1]: Started File System Check on /dev/sda1.
mei 22 12:41:26 sonata systemd[1]: Mounting /media/olddisk1...
mei 22 12:41:26 sonata systemd[1]: Mounted /media/olddisk1.
mei 22 12:41:26 sonata kernel: EXT4-fs (sda1): mounted filesystem with 
ordered data mode. Opts: (null)
mei 22 12:41:26 sonata systemd-fsck[348]: /dev/sda6 has gone 4385 days 
without being checked, check forced.
mei 22 13:01:33 sonata systemd-fsck[348]: /dev/sda6: 974019/30523392 
files (8.8% non-contiguous), 114529416/122069894 blocks

mei 22 13:01:34 sonata systemd[1]: Started File System Check on /dev/sda6.
mei 22 13:01:34 sonata systemd[1]: Mounting /media/olddisk6...

...

mei 22 13:02:02 sonata systemd[1420]: Startup finished in 18ms.
mei 22 13:02:02 sonata systemd[1]: Started User Manager for UID 1000.
mei 19 18:54:52 sonata systemd[1]: Time has been changed
mei 19 18:54:52 sonata systemd[1420]: Time has been changed
mei 19 18:54:52 sonata systemd[1175]: Time has been changed
mei 19 18:54:52 sonata systemd-timesyncd[478]: Synchronized to time 
server 83.98.201.134:123 (2.debian.pool.ntp.org).
mei 19 18:54:52 sonata systemd[1]: apt-daily.timer: Adding 4h 20min 
45.246388s random time.


I don't know what's happening, but my RTC tends to get ahead A LOT. 
Although I can't match the 4385 days with the 3 days difference I saw in 
this boot log.


Oh, wait, I can... check the start of the log:

-- Logs begin at ma 2028-05-22 12:37:10 CEST, end at do 2016-05-19 
21:22:23 CEST. --


Looks like I need to have systemd-timesync run *before* systemd-fsck!?

--
Grtjs, Manuel

PS: MSX FOR EVER! (Questions? http://faq.msxnet.org/ )
PPS: Visit my homepage at http://manuel.msxnet.org/

Bug#824710: Missing build-dependency on libgwengui-gtk2-dev

[Micha Lenk]

Control: tags -1 +pending

As I broke it by changing libaqbanking-dev, I just prepared a fix for it
and uploaded it as gnucash 1:2.6.12-1.1 to
/UploadQueue/DELAYED/3-day/.

Please see the attached diff (ready for "git am") with all the changes
of the uploaded NMU (gnucash 1:2.6.12-1.1).

Cheers,
Micha
>From b9418bd4bf67e2e3cb248c12d3ba2e0c319ecd99 Mon Sep 17 00:00:00 2001
From: Micha Lenk 
Date: Thu, 19 May 2016 20:49:17 +0200
Subject: [PATCH] Add build-dependency on libgwengui-gtk2-dev

Closes: #824710
---
 debian/changelog | 7 +++
 debian/control   | 1 +
 2 files changed, 8 insertions(+)

diff --git a/debian/changelog b/debian/changelog
index 98b4a32..544f333 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+gnucash (1:2.6.12-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Add build-dependency on libgwengui-gtk2-dev (closes: #824710).
+
+ -- Micha Lenk   Thu, 19 May 2016 20:47:23 +0200
+
 gnucash (1:2.6.12-1) unstable; urgency=medium
 
   * New upstream release [March 2016].
diff --git a/debian/control b/debian/control
index e621fe0..ebaa854 100644
--- a/debian/control
+++ b/debian/control
@@ -14,6 +14,7 @@ Build-Depends: debhelper (>= 9), intltool, pkg-config, dh-autoreconf, dh-python,
  libgnomecanvas2-dev,
  libgoffice-0.8-dev,
  libgtk2.0-dev (>= 2.24),
+ libgwengui-gtk2-dev,
  libofx-dev,
  libwebkitgtk-dev,
  libxml2-dev,
-- 
2.1.4

Bug#824751: [Pkg-zfsonlinux-devel] Bug#824751: zfsutils-linux, zutils: error when trying to install together

[Petter Reinholdtsen]

[Daniel Baumann]
> Hi,
>
> how about renaming ztest in zfsutils to zfstest?

I had a look at how this was handled in zfsutils on kfreebsd, and
according to

the package do not have any ztest.1 manual page.

I suspect we should discuss with the kFreeBSD maintainers how to best
handle this situation on both Linux and kFreeBSD.

-- 
Happy hacking
Petter Reinholdtsen

Bug#824790: linux-image-4.5.0-1-amd64: lots of WARNINGs in hfsc_dequeue+0x300/0x320 when using sch_hfsc+sch_codel

[Mirek Kratochvil]

Package: src:linux
Version: 4.5.1-1
Severity: normal
Tags: upstream

Dear Maintainer,

When attaching a codel or fq_codel qdisc to a leaf hfsc class, sometimes a
bunch of warnings (dmesg attached) show up. That would not be a problem, but
the warnings seem to be triggered for each packet for some time, and as a side
situation the processing renders the system more or less unresponsive for
several seconds (which may be a problem for QoS machine).

A bug that is probably related (but concerning hfsc+sfq) is #631945 , my
configuration is mostly the same, except with codel instead of SFQ. No similar
fix exists for codel.

When trying to rule out the causes, I found that the amount of traffic doesn't
matter (the machine is currently processing around 1Gbit/s). fq_codel shows the
same behavior, no other qdisc I tested causes the warnings.

I hope someone could point out what's wrong with codel, if I see the cause I
can write/send a patch to upstream.

-mk

-- Package-specific info:
** Version:
Linux version 4.5.0-1-amd64 (debian-ker...@lists.debian.org) (gcc version 5.3.1 
20160409 (Debian 5.3.1-14) ) #1 SMP Debian 4.5.1-1 (2016-04-14)

** Command line:
BOOT_IMAGE=/vmlinuz-4.5.0-1-amd64 
root=UUID=76eda643-1cd8-4a76-92f5-a79ac4bd7bd0 ro panic=60 quiet

** Tainted: WE (8704)
 * Taint on warning.
 * Unsigned module has been loaded (currently expected).

** Kernel log:
[1311017.332962] WARNING: CPU: 4 PID: 0 at 
/build/linux-HoPide/linux-4.5.1/net/sched/sch_hfsc.c:1429 
hfsc_dequeue+0x300/0x320 [sch_hfsc]()
[1311017.332966] Modules linked in: sch_codel(E) sch_fq_codel(E) act_mirred(E) 
act_gact(E) sch_ingress(E) sch_sfq(E) cls_u32(E) sch_hfsc(E) ext4(E) crc16(E) 
mbcache(E) jbd2(E) crc32c_generic(E) x86_pkg_temp_thermal(E) 
intel_powerclamp(E) sg(E) coretemp(E) kvm_intel(E) kvm(E) mgag200(E) ttm(E) 
drm_kms_helper(E) joydev(E) drm(E) iTCO_wdt(E) iTCO_vendor_support(E) 
i2c_algo_bit(E) acpi_power_meter(E) irqbypass(E) crct10dif_pclmul(E) 
crc32_pclmul(E) ghash_clmulni_intel(E) hmac(E) drbg(E) ansi_cprng(E) evdev(E) 
pcspkr(E) aesni_intel(E) aes_x86_64(E) lrw(E) gf128mul(E) glue_helper(E) 
ablk_helper(E) cryptd(E) ipmi_devintf(E) 8250_fintek(E) button(E) wmi(E) 
acpi_pad(E) ipmi_si(E) ipmi_msghandler(E) shpchp(E) sb_edac(E) edac_core(E) 
mei_me(E) mei(E) tpm_tis(E) lpc_ich(E) tpm(E) mfd_core(E) processor(E) ifb(E) 
autofs4(E)
[1311017.332997]  xfs(E) libcrc32c(E) hid_generic(E) usbhid(E) hid(E) sr_mod(E) 
cdrom(E) sd_mod(E) crc32c_intel(E) ixgbe(E) dca(E) vxlan(E) ip6_udp_tunnel(E) 
udp_tunnel(E) mdio(E) ahci(E) libahci(E) ehci_pci(E) ehci_hcd(E) libata(E) 
tg3(E) ptp(E) pps_core(E) usbcore(E) libphy(E) usb_common(E) megaraid_sas(E) 
scsi_mod(E) fjes(E)
[1311017.333010] CPU: 4 PID: 0 Comm: swapper/4 Tainted: GW   E   
4.5.0-1-amd64 #1 Debian 4.5.1-1
[1311017.333011] Hardware name:/08DM12, BIOS 2.1.2 01/20/2014
[1311017.333011]  0286 c030b3f15909e533 81307b65 

[1311017.333013]  c0473060 8107905d 880c1076c148 
12a1f2eb6d9f
[1311017.333016]  880c1076c000 880c1076c490 8800c8da3000 
c0471540
[1311017.333018] Call Trace:
[1311017.333018][] ? dump_stack+0x5c/0x77
[1311017.333024]  [] ? warn_slowpath_common+0x7d/0xb0
[1311017.333027]  [] ? hfsc_dequeue+0x300/0x320 [sch_hfsc]
[1311017.333031]  [] ? __qdisc_run+0x65/0x190
[1311017.333032]  [] ? net_tx_action+0xd6/0x230
[1311017.333034]  [] ? __do_softirq+0xf8/0x290
[1311017.333037]  [] ? irq_exit+0x9b/0xa0
[1311017.333040]  [] ? smp_apic_timer_interrupt+0x3e/0x50
[1311017.333043]  [] ? apic_timer_interrupt+0x82/0x90
[1311017.333044][] ? cpuidle_enter_state+0x118/0x2c0
[1311017.333047]  [] ? cpuidle_enter_state+0x105/0x2c0
[1311017.333049]  [] ? cpu_startup_entry+0x287/0x340
[1311017.333053]  [] ? start_secondary+0x15a/0x190
[1311017.333058] ---[ end trace f0baeef58cceeec5 ]---
[1311017.333066] [ cut here ]
[1311017.333072] WARNING: CPU: 6 PID: 0 at 
/build/linux-HoPide/linux-4.5.1/net/sched/sch_hfsc.c:1429 
hfsc_dequeue+0x300/0x320 [sch_hfsc]()
[1311017.333077] Modules linked in: sch_codel(E) sch_fq_codel(E) act_mirred(E) 
act_gact(E) sch_ingress(E) sch_sfq(E) cls_u32(E) sch_hfsc(E) ext4(E) crc16(E) 
mbcache(E) jbd2(E) crc32c_generic(E) x86_pkg_temp_thermal(E) 
intel_powerclamp(E) sg(E) coretemp(E) kvm_intel(E) kvm(E) mgag200(E) ttm(E) 
drm_kms_helper(E) joydev(E) drm(E) iTCO_wdt(E) iTCO_vendor_support(E) 
i2c_algo_bit(E) acpi_power_meter(E) irqbypass(E) crct10dif_pclmul(E) 
crc32_pclmul(E) ghash_clmulni_intel(E) hmac(E) drbg(E) ansi_cprng(E) evdev(E) 
pcspkr(E) aesni_intel(E) aes_x86_64(E) lrw(E) gf128mul(E) glue_helper(E) 
ablk_helper(E) cryptd(E) ipmi_devintf(E) 8250_fintek(E) button(E) wmi(E) 
acpi_pad(E) ipmi_si(E) ipmi_msghandler(E) shpchp(E) sb_edac(E) edac_core(E) 
mei_me(E) mei(E) tpm_tis(E) lpc_ich(E) tpm(E) mfd_core(E) processor(E) ifb(E) 
autofs4(E)
[1311017.333138]  xfs(E) libcrc32c(E) hid_generic(E) usbhid(E) hid(E) sr_mod(E) 
cdrom(E) 

Bug#824781: icedove-l10n-en-gb: should recommend hunspell-en-gb and not *-en-us

[Jonas Smedegaard]

Quoting Jonas Smedegaard (2016-05-19 19:11:27)
> As subject says, iceowl-l10n-en-gb should recommend hunspell-en-gb, 
> but not hunspell-en-us nor myspell-en-us.

...and as subject _now_ says, this is really about icedove-l10n-en-gb.

Sorry for the confusion.

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Bug#800324: linux-image-4.2.0-1-amd64: Recurring traces from kernel/sched/core.c:1975 wake_up_process+0x31/0x50()

[Roman Lebedev]

Dear maintainer, this issue is not reproducible on latest kernels
(4.4.0+) with radeon videodriver.
I suppose this can be closed.

Roman.

On Mon, Sep 28, 2015 at 2:22 PM, Roman Lebedev  wrote:
> On Mon, Sep 28, 2015 at 2:10 PM, Ben Hutchings  wrote:
>> On Mon, 2015-09-28 at 12:21 +0300, Roman Lebedev wrote:
>>> On Sun, Sep 27, 2015 at 11:57 PM, Ben Hutchings  
>>> wrote:
>> [...]
>>> > > snd_hda_codec_realtek kvm snd_hda_codec_generic snd_hda_codec_hdmi
>>> > > crct10dif_pclmul crc32_pclmul eeepc_wmi ghash_clmulni_intel asus_wmi
>>> > > snd_hda_intel sha256_ssse3 sha256_generic ohci_pci sparse_keymap hmac
>>> > > rfkill video ohci_hcd drbg mxm_wmi ehci_pci ehci_hcd snd_hda_codec
>>> > > snd_hda_core ansi_cprng aesni_intel aes_x86_64 evdev xhci_pci lrw
>>> > > gf128mul glue_helper serio_raw xhci_hcd snd_hwdep ablk_helper usbcore
>>> > > snd_pcm cryptd snd_timer snd sp5100_tco pcspkr usb_common
>>> > > edac_mce_amd edac_core fam15h_power k10temp i2c_piix4 e1000e wmi
>>> > > soundcore acpi_cpufreq
>>> > > [39595.406818]  button ptp pps_core tpm_infineon shpchp sg processor
>>> > > tpm_tis tpm thermal_sys tcp_yeah tcp_vegas pcore(O) it87 hwmon_vid
>>> >
>>> > [...]
>>> >
>>> > What is pcore?
>>> That is a  AMD CodeXL Power Profiler Linux kernel module
>>> from http://developer.amd.com/tools-and-sdks/opencl-zone/codexl/
>>> -> amdcodexl_1.8-9654_amd64.deb
>>
>> Can you try removing that?
> Yes, already did, waiting...
> Though, during that time when those traces occurred in dmesg,
> i was not using amdcodexl, so pcore.ko shouldn't be the reason.
>
>>
>> Ben.
> Roman.
>
>>
>> --
>> Ben Hutchings
>> All extremists should be taken out and shot.

Bug#824767: [pkg-ntp-maintainers] Bug#824767: The new apparmor profile includes a non-existing file, causes apparmor not to start

[Kurt Roeckx]

On Thu, May 19, 2016 at 02:17:02PM +, Marga Manterola wrote:
> 
> This should be fixed by adding a call to dh_apparmor (see for example:
> https://sources.debian.net/src/evince/3.20.0-3/debian/rules/), I think this
> should do
> the trick:
> dh_apparmor --profile-name=usr.sbin.ntp -pntp

I think that should be usr.sbin.ntpd.


Kurt

Bug#824698: redir: New upstream, and new release(s)

[Lucas Kanashiro]

Hi,

Thanks for your work on redir :)

I intend to update the package with the latest upstream release ASAP.

Cheers,
-- 
Lucas Kanashiro

Bug#824710: Acknowledgement (Missing build-dependency on libgwengui-gtk2-dev)

[Micha Lenk]

Just for the records, this is how the build fails:

...
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I../../.. -I../../../src
-I../../../src/import-export -I../../../src/gnome
-I../../../src/register/ledger-core
-I../../../src/register/register-gnome
-I../../../src/register/register-core -I../../../src/gnome-utils
-I../../../src/app-utils -I../../../src/engine -I../../../src/core-utils
-I../../../src/gnc-module -I../../../src/libqof/qof -pthread
-I/usr/include/gtk-2.0 -I/usr/lib/x86_64-linux-gnu/gtk-2.0/include
-I/usr/include/gio-unix-2.0/ -I/usr/include/cairo
-I/usr/include/pango-1.0 -I/usr/include/atk-1.0 -I/usr/include/cairo
-I/usr/include/pixman-1 -I/usr/include/libpng16
-I/usr/include/gdk-pixbuf-2.0 -I/usr/include/libpng16
-I/usr/include/pango-1.0 -I/usr/include/harfbuzz
-I/usr/include/pango-1.0 -I/usr/include/glib-2.0
-I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/freetype2
-pthread -I/usr/include/glib-2.0
-I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/aqbanking5
-I/usr/include/gwenhywfar4 -DG_LOG_DOMAIN=\"gnc.import.aqbanking\"
-Wdate-time -D_FORTIFY_SOURCE=2 -Wdeclaration-after-statement
-Wno-pointer-sign -D_FORTIFY_SOURCE=2 -g -O2 -fstack-protector-strong
-Wformat -Werror=format-security -std=gnu99 -Wall -Wunused
-Wmissing-prototypes -Wmissing-declarations -Wno-unused -c
gnc-gwen-gui.c  -fPIC -DPIC -o .libs/gnc-gwen-gui.o
gnc-gwen-gui.c:64:37: fatal error: gwen-gui-gtk2/gtk2_gui.h: No such
file or directory
compilation terminated.
Makefile:716: recipe for target 'gnc-gwen-gui.lo' failed
make[6]: *** [gnc-gwen-gui.lo] Error 1
make[6]: Leaving directory
'/tmp/buildd/gnucash-2.6.12/src/import-export/aqb'
Makefile:773: recipe for target 'all-recursive' failed
make[5]: *** [all-recursive] Error 1
make[5]: Leaving directory
'/tmp/buildd/gnucash-2.6.12/src/import-export/aqb'
Makefile:758: recipe for target 'all-recursive' failed
make[4]: *** [all-recursive] Error 1
make[4]: Leaving directory '/tmp/buildd/gnucash-2.6.12/src/import-export'
Makefile:563: recipe for target 'all-recursive' failed
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory '/tmp/buildd/gnucash-2.6.12/src'
Makefile:796: recipe for target 'all-recursive' failed
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory '/tmp/buildd/gnucash-2.6.12'
Makefile:650: recipe for target 'all' failed
make[1]: *** [all] Error 2
make[1]: Leaving directory '/tmp/buildd/gnucash-2.6.12'
dh_auto_build: make -j1 returned exit code 2
debian/rules:15: recipe for target 'build' failed
make: *** [build] Error 2
dpkg-buildpackage: error: debian/rules build gave error exit status 2
E: Failed autobuilding of package

Bug#824730: u-boot: Please add a package for DRA7xx systems

[Ben Hutchings]

On Thu, 2016-05-19 at 11:05 -0700, Vagrant Cascadian wrote:
> On 2016-05-19, Ben Hutchings wrote:
> > u-boot 2016.03 works for me on a DRA74 EVM (aka Vayu) board.  Please
> > apply the attached patch to add a package for this platform.
> 
> Thanks for the patch!
> 
> Would you be ok with adding it to the u-boot-omap package?
[...]

That seems reasonable - the DRA7xx platform is quite similar to OMAP5.

Ben.

-- 
Ben Hutchings
Software Developer, Codethink Ltd.

Bug#821532: mlmmj-php-web, mlmmj-php-web-admin: PHP 7.0 Transition

[Chris Knadle]

Ondřej Surý:
> php7.7 sounds odd, but it's result of this command:
> 
> a2query -m | sed -n 's/^\(php[\.0-9]*\) (enabled.*)/\1/p'
> 
> Hmm, I'll speak with apache2 maintainers how to solve this. It looks
> like you need to install apache2 first and then install
> libapache2-mod-php7.0.

Yeah that was it.  I really appreciate the help, I'm not sure I would have
figured that out.  Removing libapache2-mod-php7.0 required removing php as
well as mlmmj-php-web, etc temporarily, reinstalling libapache2-mod-php7.0
after apache2 works fine.

> Unfortunatelly you should not depend on apache2 package:
> 
> https://lintian.debian.org/tags/apache2-module-depends-on-real-apache2-package.html

Hmm.  If that's the case then I'm guessing the way to fix this dependency
issue would involve splitting off certain things from the apache2 package
into yet another binary package.  :-/  Ugh.

Thanks much.

   -- Chris

-- 
Chris Knadle
chris.kna...@coredump.us

Bug#487946: 'apt-get update' considers connection failures non-transient

[Ray Dillinger]

There is no reason to have multiple sources in your
/etc/apt/sources.list file, if apt-get update/upgrade only cares about
the first one!

I use multiple sources in the hopes that

(a) The load should be distributed among those mirrors.

(b) Multiple downloads should be happening at once.  At least two
or three, because any one download could stall and I don't want
to waste time.

(c) If a download from some mirror stalls, time when my bandwidth
could be in use should not be  wasted waiting for it. Downloads
from available mirrors should continue, and if the number of
downloads in progress drops too low, then a download from an
additional mirror ought to be triggered to insure that bandwidth
on my end remains reliably useful.

(d) If a package turns out to be unavailable from some mirror, or if
the download of that package from that source is still incomplete
and stalled when there is available bandwidth because other
downloads are finished, or if checksum of a downloaded package
fails, that package ought to be downloaded from elsewhere rather
than causing a failure.  Apt should fail only if there are packages
it can not get from ANY source.

(e) A mirror that stalls or fails a lot should be lowered in priority
over time, both so that its load is reduced as it apparently needs,
and so my bandwidth is usually dedicated to downloading from the
most reliable mirrors.  I don't want any of the mirrors to be
considered 'primary' - treating one as such just because of its
position in the sources list is crazy!

I'm pretty sure I remember these things all being true, way back in
Lenny or Wheezy.  When did they get disabled?  Multiple sources now
make apt take LONGER and fail MORE instead of saving time failing LESS
as they used to.

Bear




signature.asc
Description: OpenPGP digital signature

Bug#824789: RM: suitesparse-metis -- ROM; superseded by suitesparse package

[Sébastien Villemot]

Package: ftp.debian.org
Severity: normal

Dear ftpmasters,

Please remove the suitesparse-metis package from contrib. It is no longer
needed since the suitesparse package in main provides the same functionality
(the METIS library has been relicensed, and suitesparse 1:4.5.3-1 now links
against it).

Cheers,

-- 
 .''`.Sébastien Villemot
: :' :Debian Developer
`. `' http://sebastien.villemot.name
  `-  GPG Key: 4096R/381A7594


signature.asc
Description: PGP signature

Bug#824788: FTBFS in sid: recipe for target 'rheolef.pdf' failed

[Sébastien Villemot]

Package: src:rheolef
Version: 6.6-1
Severity: serious

Dear Maintainer,

rheolef currently FTBFS in sid. The problem comes from the compilation of
rheolef.pdf.

See the full build log at:

 
https://buildd.debian.org/status/fetch.php?pkg=rheolef=amd64=6.6-1%2Bb3=1463565280

Cheers,

-- 
 .''`.Sébastien Villemot
: :' :Debian Developer
`. `' http://sebastien.villemot.name
  `-  GPG Key: 4096R/381A7594


signature.asc
Description: PGP signature

Bug#824730: u-boot: Please add a package for DRA7xx systems

[Vagrant Cascadian]

On 2016-05-19, Ben Hutchings wrote:
> u-boot 2016.03 works for me on a DRA74 EVM (aka Vayu) board.  Please
> apply the attached patch to add a package for this platform.

Thanks for the patch!

Would you be ok with adding it to the u-boot-omap package? It isn't
exactly a perfect fit, but have loosely lumped other not-quite-omap
platforms together in it so far. Trying to balance proliferation of
packages (and getting stuck in the NEW queue all the time) by grouping
together "related" platforms.


> The master branch of u-boot.git currently doesn't build because the
> patch "board: ti: AM57xx: Add detection logic for AM57xx-evm" refers to
> files in board/ti/common/ which does not exist.

Sorry about that, I've been focusing on getting 2016.05 uploaded to
unstable soon, but it has issues with some platforms, so I've left it in
experimental. I haven't worked much on the 2016.03 branch currently in
master lately.


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#824786: celeryd: Initscript doesn't start daemon

[Alex Kiousis]

Package: celeryd
Severity: important

Dear Maintainer,

Default celeryd package ships with the (upstream) SysV initscript and
creates a system user named celery. By default this user has /bin/false
as a shell. So if you set correct variables in /etc/default/celery and
start the daemon, celery never starts.

This is the relevant function from the initscript:

_chuid () {
su "$CELERYD_USER" -c "$CELERYD_MULTI $*"
}

Simply changing this to:
su "$CELERYD_USER" --shell=/bin/sh -c "$CELERYD_MULTI $*"

works. I don't know if this is the best way to fix this, though.

I'm marking this important because the package celeryd only provides the
initscript. Running the worker proccess by hand of course works.

Bug#772947: [linkchecker] linkchecker broken on https URLs: ImportError: cannot import name get_subj_alt_name

[Antoine Beaupré]

Package: linkchecker
Version: 9.3-1
Followup-For: Bug #772947

This is still an issue.

The package is orphaned so i will likely prepare a NMU if i can find
the time.

In the meantime, w3c-checker works.

-- System Information:
Debian Release: 8.4
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'proposed-updates'), (500, 
'stable'), (1, 'testing')
Architecture: amd64 (x86_64)

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

Versions of packages linkchecker depends on:
ii  libc62.19-18+deb8u4
ii  python   2.7.9-1
ii  python-requests  2.4.3-6

linkchecker recommends no packages.

Versions of packages linkchecker suggests:
pn  clamav-daemon   
pn  linkchecker-gui 
pn  linkchecker-web 
pn  python-argcomplete  
ii  python-cssutils 0.9.10-1
ii  python-gconf2.28.1+dfsg-1.1
ii  python-geoip1.3.2-1
pn  python-meliae   
pn  python-twill

-- no debconf information

Bug#824787: RFS: acmetool/0.0.51

[Peter Colberg]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for the package "acmetool":

  git clone https://anonscm.debian.org/git/letsencrypt/acmetool.git
   
  cd acmetool && pristine-tar checkout ../acmetool_0.0.51.orig.tar.gz  

For verification, these are the current branch heads:

  git show-ref --heads
  b4e506ba03160462e258d0b769a6eef0ecf5b52d refs/heads/master
  d426d432fe2c3cdc87db3dc177d561e006bb8ca7 refs/heads/pristine-tar
  31837d34e6892b788020ddad9c18171985936c81 refs/heads/upstream

It builds these binary packages:

  acmetool -- automatic certificate acquisition tool for Let's Encrypt

Changes since the last upload:

acmetool (0.0.51-1) unstable; urgency=medium

  * New upstream release
  * Drop patches applied upstream
  * Build depend on
- golang-gopkg-cheggaaa-pb.v1-dev
- golang-gopkg-square-go-jose.v1-dev
- golang-github-hlandau-degoutils-dev (>= 0.0~git20160421.0.389a847)
  * Build depend on dh-golang (>= 1.17~) and install with --no-source
  * Do not compress example scripts
  * Add lintian overrides for spelling error false positives

 -- Peter Colberg   Wed, 18 May 2016 07:48:14 -0400

Regards,
Peter

Bug#824702: apt: Incorrect translation in apt list --upgradable ru_RU.UTF8 locale

[Yuri Kozlov]

В Wed, 18 May 2016 23:19:21 +0200
Julian Andres Klode  пишет:

> On Wed, May 18, 2016 at 11:27:59PM +0300, oleg wrote:
> > Package: apt
> > Version: 1.2.12
> > Severity: minor
> > 
> > Dear Maintainer,
> > in ru_RU.UTF8 locale is incorrect translation, for example:
> > 
> > vim/unstable 2:7.4.1829-1 amd64 [upgradable from: 2:7.4.1689-3]
> > vim/unstable 2:7.4.1829-1 amd64 [может быть обновлён до:
> > 2:7.4.1689-3]
> > 
> > correct is something like «может быть обновлён с:»
> 
> Adding debian-l10n-russ...@lists.debian.org to the loop.

Here fixed and updated (version from git) russian translation.

-- 
Best Regards,
Yuri Kozlov



ru.po.gz
Description: application/gzip

Bug#824211: swh-plugins: Package new upstream version

[Jaromír Mikeš]

2016-05-19 16:20 GMT+02:00 Jonas Smedegaard :
> Quoting Jaromír Mikeš (2016-05-19 15:45:28)
>> 2016-05-13 20:40 GMT+02:00 Javier Serrano Polo :
>> > Package: swh-plugins
>> > Version: 0.4.15+1-8
>> > Severity: wishlist
>> >
>> > The upstream project is maintained at https://github.com/swh/ladspa . It
>> > includes a vocoder plug-in that is shipped with the lmms package. To
>> > reuse this plug-in, lmms could put it under /usr/lib/ladspa, but that
>> > would conflict with a new version of swh-plugins. Could you tell if you
>> > will package a new upstream version, which is preferable, or if lmms can
>> > publish this plug-in in the meantime?
>>
>> I don't see any release here yet :(
>> https://github.com/swh/ladspa/releases
>
> Then perhaps consider release a snapshot of upstream development - to me
> that feels more sensible (without having looked closer at the code) than
> us indirectly doing the same via a snapshot created by another upstream
> (the lmms project).

Yes, that would be definitely possible, but I would to to know where
next releases will be published to tune watch file accordingly.

mira

Bug#824785: icedove-l10n-all: should be in package section metapackages

[Jonas Smedegaard]

Package: icedove-l10n-all
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

As subject says, icedove-l10n-all is a metapackage and belongs in the
corresponding package section.

 - Jonas

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJXPfpUAAoJECx8MUbBoAEh5GYP/3LQy6oH/z6as6kyy0yQ2ZBK
zlHTC6yebY3APNwHKbdBQ0lxasEoOvGUOw7HRdA2QlDBm3hGTd7+JcvcaLQkCsx9
6GNrVbwhYfO246o0l8Ms65uM2T4q+WdMsgIKgCSNggWpr5DyRbzhls5TGk65TBv/
DfThHoq1dGGdXpYRCwLD4gIkWkTlHEVzmG1aKuD87j6GeboNFT91GGQsDEt2DEfK
7qcJKvjy68bFmz1HyE2xX501eOpiinNmjBUqsmx+Md3cW5b2OXNEZdqjDlWa2IMb
mPRUGEe7sfbKyN9EfTDhZ/H2ulQIqNZC1rYZHuAwD12SjbLBAE6qyXg+F5Tpxg2G
oeK7QQ/BI6jveRZ6cm3Hx5rBGxAvJt/w8LwR1JAfbLXAN6oh5bv7MaUNBj/yNu/U
8hiDMInI7bJkjm64V/T/ToxuxG03fzzkoElvcvrGzlz1GYSBxCmEL7PWaNDJx5W9
NIR9C+z+WZkHQtDSTi8A7BmbwpMqLGG9pXfjSgUrkVb2cfTjS6KDfP8JY8pzrbtg
j0peNBqtGS5CzYBe96fNjCNmw6oPmgpavBCu+cH7X4dX8qyvmrEM1IO9PmncVDCo
xeeIWmX0nVZIHTwPVZmq/lm+3fnIm+g9gqmJDjq/qnpbwfCKrO8HflRyaZBulKdS
4CQSZXl/bi0XaTSVHQ1t
=DnKR
-END PGP SIGNATURE-

Bug#824784: firefox-l10n-all: should be in package section metapackages

[Jonas Smedegaard]

Package: firefox-l10n-all
Version: 46.0.1-1
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

As subject says: firefox-l10n-all is a metackage and therefore belong in
the corresponding package section.

 - Jonas

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJXPfoBAAoJECx8MUbBoAEho8EQAIHPPKShvfAoN9mE79hrP2Ga
bkat6bzqtHjAGgJo01jiCxNA3GOzwu9jQTVE733JXGJsrBU8qT7kBP229y26+Rkd
kZH+axXbI8avRWYQyZokgAqRpYV+DZaxJmbl+fNFEW7NDIkmJlfLNgErIkvdecig
pfWhF3HG+HBZdXUYhtR9tFDA6Wnd4W1fGoLuu2Y7vlXFDkXgHyhhxkd2XkOilMdX
PjsP/roo1vEkA0MGmPCphark14CafcyNI0mjFxDCOrDhsw7qO14uARXabWrWF4ct
J0eaYg+i4XjSOg2cuttunERZrBqyPY2tcMLbAOz0wD1ENIKJdtWTUL3mZeoYq0sy
DnfVHGdlJbJnE9zOPH2LMLie+QiNY4DjDgYYkVjqmgQtQizzY611kra2EgGxnXEB
Xxg2rndrazmrWWATzQRJMvnCiOkCYvqIdrNEF8U1E0HP52vyWNLWi7E2ATB66WY8
U1aOrFNb8ZoLHzz0ZVha9zU5/HM0PmfF/oGzftceVvji9gGKhLQiqT9M33vdvNc6
IFEDyd2+Obf0qF4O6T/SuRXew/L/O3IMknL1JKQfx0nzFUi6/BYM6dGsX9krCSEl
3pOG7TMFVtVZ1PkwQyeXidA58bHws8/4MYgoX9yMvIk/e2x8wimRzWj5dOn2vU4F
PGMHKFIu830/+j1W7Zfa
=aog0
-END PGP SIGNATURE-

Bug#824712: RFH: smokeping

[Antoine Beaupré]

On 2016-05-19 10:21:21, Iain R. Learmonth wrote:
> Hi,
>
> On 19/05/16 13:33, Antoine Beaupré wrote:
>> Hmm... I'm hesitant in joining yet another team here, too much mail. :)
>
> By joining the team, I mainly meant giving you VCS commit access. If
> you're not using the package much anymore then I probably wouldn't
> expect you to be tracking the package too closely, but as you've
> previously maintained it I might want to ask you questions and allow you
> the ability to commit fixes for anything I'm not understanding.

I'm fine with that!

>> But i'd be happy to share maintenance or even delegate responsability
>> completely if people are up to it.
>
> Does this sound acceptable?

All of the above is, feel free to move to shared maintenance and give me
access, it sounds like a great solution.

Thanks for the fast response!

A.

-- 
If it's important for you, you'll find a way.
If it's not, you'll find an excuse.
- Unknown

Bug#824683: [PKG-Openstack-devel] Bug#824683: keystone: CVE-2016-4911: Incorrect Audit IDs in Keystone Fernet Tokens can result in revocation bypass

[Salvatore Bonaccorso]

Hi,

On Thu, May 19, 2016 at 10:54:10AM +0200, Thomas Goirand wrote:
> On 05/19/2016 06:18 AM, Salvatore Bonaccorso wrote:
> > Hi Thomas,
> > 
> > On Thu, May 19, 2016 at 12:21:28AM +0200, Thomas Goirand wrote:
> >> On 05/18/2016 06:55 PM, Salvatore Bonaccorso wrote:
> >>> Source: keystone
> >>> Version: 2:9.0.0-1
> >>> Severity: grave
> >>> Tags: security patch upstream
> >>>
> >>> Hi,
> >>>
> >>> the following vulnerability was published for keystone.
> >>>
> >>> CVE-2016-4911[0]:
> >>> Incorrect Audit IDs in Keystone Fernet Tokens can result in revocation 
> >>> bypass
> >>>
> >>> If you fix the vulnerability please also make sure to include the
> >>> CVE (Common Vulnerabilities & Exposures) id in your changelog entry.
> >>>
> >>> For further information see:
> >>>
> >>> [0] https://security-tracker.debian.org/tracker/CVE-2016-4911
> >>> [1] https://bugs.launchpad.net/keystone/+bug/1577558
> >>>
> >>> Regards,
> >>> Salvatore
> >>
> >> Hi Salvatore,
> >>
> >> It is my view that this bug doesn't deserve Severity: grave, as Fernet
> >> Tokens aren't the default in Keystone (it defaults to UUID tokens, and
> >> Fernet Tokens are a very new thing).
> >>
> >> Your thoughts?
> > 
> > Thanks for your feedback. Wanted to be rather safe than sorry.
> > 
> >> Anyway, Keystone in Stable isn't affected (it doesn't have the feature),
> >> and never the less, I'll update the package in Sid/Testing.
> > 
> > I can confirm that it should only affect 9.0.0, so sid. Could you
> > upload the isolated fix? I will then update the tracker information
> > once it enters the archive.
> > 
> > Thanks!
> > 
> > Regards,
> > Salvatore
> 
> Hi Salvatore,
> 
> I have uploaded Keystone 9.0.0-2 with the upstream patch. Upstream also
> confirmed that previous version, currently in jessie-backports, isn't
> affected by this issue. So, once Keystone migrates to Testing, we're
> good to go.

Thanks. I have updated the security-tracker information.

Regards,
Salvatore

Bug#820526: closed by Matthias Klose <d...@debian.org> (Bug#820526: fixed in giflib 5.1.4-0.1)

[Salvatore Bonaccorso]

Hi,

I'm reopening this bug since the commit
https://sourceforge.net/p/giflib/code/ci/ea8dbc5786862a3e16a5acfa3d24e2c2f608cd88/
is not yet applied in the 5.1.4 upload.

Regards,
Salvatore

Bug#824783: icedove-l10n: should recommend myspell-* as alternative to hunspell-*

[Jonas Smedegaard]

Source: icedove-l10n
Version: 1:38.0.1-1
Severity: normal
Tags: l10n

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Icedove locale packages recommend hunspell but not myspell dictionary for
the following locales:

gl vi

Please recommend myspell-* as alternative to hunspell-*.

As I understand it, hunspell has features not in myspell (e.g. related
to combining words common in germanic languages), and hunspell-* should
therefore probably be listed first in general.

 - Jonas

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJXPfXrAAoJECx8MUbBoAEhKqcP/jQmK0P6CrGijpVLzyQzeP66
B28+bvT5Ifx8nI2XO/Yg2suvvRaICg2mwGVrfl/rl/1RxT29phJ8SRW41MjPdVOL
cQDyuF6XoWkV2PoOhkPTc6GCqeGlH87QwqjxjrYbMXuYMi4kZPbIWSUvZazo3oaM
BpJX6Bs5dS2AvbHwoHbC7ewkn2B75IWOEoWL5nlDY0S7k812nMnLyRiGnK+SKbwV
c55ipHWDok8t/nkuH6FwcALa3Re0OCBO0F14+5ziAUBCXA6zr4vksPNQdbGiV15u
6l42c1qUQBPElRhbRkupx9FWTBNUAYwg27AdQryX+tCrBSIpPpHOAkmbUfUASgwr
kBy1M1NoHrfsJM+Ew+cxGkjFZhBiA8TSK8O7pPEF/X862VNfYUE1m4RVkhYOK7jX
LxU40BWWsZbAIr7Ypg2B+cKyz3TEPYIwakSj7XPvW6sro83L36eHcSqLWK2m438+
+ZL4A8hggAtQift3x0hjHPI6xtv0Ek98FJM6wWfXxi8uzcF/+0etECKZzyZs+LRy
qv0zpbvqocf5WtWRRPtucDNd7XOie6EoWDrYtWs8NHS2FJYW2ZZqxUbh/euVaJby
0pNoLEh++o+a0o/kfhLoztTNTDHqHX0csq/AsEWI+5BvmqawpzLKx7M+j2xZk7pg
jnwj/hzOegckDJhYHrbx
=GPZL
-END PGP SIGNATURE-

Bug#824782: icedove-l10n: should recommend hunspell-*

[Jonas Smedegaard]

Source: icedove-l10n
Version: 1:38.0.1-1
Severity: normal
Tags: l10n

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Icedove locale packages for the following locales do not recommend on a
dictionary even though (at least) hunspell dictionary is available:

be bn br eu is si uk

Please recommend hunspell-* for those packages (with fallback on myspell
where available).

 - Jonas

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJXPfSkAAoJECx8MUbBoAEhF3cP/1bHPOQATj6npW8efD43UkXh
CFJAMLZy90TwCoMdh3xMmfAIPG/d2iERp61x3DqTXjV6rlBXG5FNaQF2aEeSxDmV
nZ1h6ZsxYNee+/EQ3KugKMRTeTdD35fFzQt+m495OEc/+cVET0MUIk2scUf2HNV3
iknxK4ucp3c4YwyNicyVqWa+zFLo9f0aB25tMrqxeCJLzIvhe4tCaHCfM1IZI6gY
8gNDi+xqTYBcvSI4lkhcpOybB/XXAzR9jc46bexilM3tBc73CcKdT8qSpKz3YzfH
ckfAn6A8kpITuyhRERuUR5wzK6mvZ4VT0rbTJQliQL5+KCbRwc1JNHfF69D9Pn6I
cszT3WzFJwg/0xj19L/la9Z09e82923/KwcayuE3SzgC8ecJdi6BlB26EGJM/QCY
7j4JrtwBji1jBvfA2HP3xvbOLTfjv6oG3VLXGTzvzLxl7zAPmi0174OY72V5HGxn
HOQ+EtLKF4IjZ4BAOc+02s0WI9AKn+llK1FbN3iCoszVjXt7FNfOdYVXOPCYS1jS
Gk79R48tLeETcxhDCDO51VJChwJoYEpAOsh2iPSZIKsnhqaacqMMkKvMoUNugrVc
Qg6KAWuUQcICTgHYeeVuNxLHOIJWYqy7Aquai2c0De/no8Ar5rzFt/YwgpXjUkLE
/LvOx0znvabETESVyBWI
=a0y4
-END PGP SIGNATURE-

Bug#824781: iceowl-l10n-en-gb: should recommend hunspell-en-gb (not hunspell-en-us or myspell-en-us)

[Jonas Smedegaard]

Package: iceowl-l10n-en-gb
Version: 1:38.0.1-1
Severity: normal
Tags: l10n

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

As subject says, iceowl-l10n-en-gb should recommend hunspell-en-gb, but
not hunspell-en-us nor myspell-en-us.

 - Jonas

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJXPfO7AAoJECx8MUbBoAEhc5UP/jFoAM0MPyXEcLl7b2DqJpGZ
FtpF7KQ22hlYRNmfdMRu5oECeGpfEGcFsvFQaVsKZFb146stIbSbadq/xEWp4zvn
UZS8CkoaInj8AxHrfNKwwRkND0pSDsKZ/BCBuF1E5Vrx41RIHVjGiWuc7NVKz8qq
yWp6MoktxTh60D3o/XAfASGW7XPaZSQikuy0UzCnP/b/P3XUWTgrAM/r0Zrt2XqH
E3VoDvmjjyFhMmPRP3GCGKeEHTToU7JK4c+TG6xvU8lM67UGV8dUltWSnEUVfqqu
nFpouTTEu2pCsp71UeR/JhIz9Z86XKLvOofoB2+d3el+Ao7mAlrBwpSjhwc7Y3Ny
9f0tS4Q+FpyyOCuafFN6fpLZUmhmSuhkeZseSF1f/MojOGF9FVTobPr/HSZSvOOf
hWFfOtJBmCneVtoKv8rOpUjvUKcK+OebB1qI3ul5wOhjmmw1Wnyv6Pt3RwfDGPXz
As+LZdNmwedsKbIHICM9qmUEoNnMRynvjb74Q84dqlhI2JqDk3mANQgGBEOcUdyJ
kSCvw9QoPf3ALss/kA1pa57lKbr6QkZT4uKkPPtsbZj0YqP6SXxXrUUwWM3/G9W3
8bSJT3Q33LYdJ9ZxESEVo3InpzzzitBDaSByZWYNRbD5q4T+Y5OxwoCGq7TjPXQk
UXPKn2v79Nc6JkFILxiG
=34YS
-END PGP SIGNATURE-

Bug#819394: RFS: stormlib/9.20-1 [ITP]

[Pali Rohár]

On Wednesday 27 April 2016 13:01:20 Gianfranco Costamagna wrote:
> Hi, the packaging seems good now, I would like to ask you a final question:
> 
> how do you feel about using the same license for debian packaging and 
> upstream?
> (asking about changing GPL-3+ to MIT).

Ok, I changed debian files to MIT (same as upstream).

> Forwarding patches otherwise would be impossible without a relicense.
> 
> and the copyright still needs to be updated:
> 
> >So in this case, how to update copyright? Just for src/lzma? Or for all
> >other embedded libraries even when they are not used and needed?
> 
> 
> you have to list *every* copyright and license on copyright file, regardless
> of it being used or not.
> This is a showstopper for ftpmasters.

Done, now all embedded libraries have entry in copyright file.

Package is now updated on mentors server. Something more is needed?

-- 
Pali Rohár
pali.ro...@gmail.com

Bug#756023: init: Move "Essential: yes" from init to init-system-helpers

[Michael Biebl]

Am 19.05.2016 um 18:29 schrieb Ansgar Burchardt:
> On Thu, 2016-05-19 at 18:27 +0200, Michael Biebl wrote:
>> Could we add the Important: yes field to "init"? Having that makes a
>> lot of sense to me.
> 
> To init or to its dependencies (systemd-sysv, sysvinit-core)?  The
> latter would not only warn when uninstalling all init systems, but also
> when switching between them (perhaps not by intention).

To "init" I guess. I don't think we should pester users with that
message if they deliberately switch to an alternative.
The main objective of having Important:yes in init would be to avoid
"accidentally" uninstalling /sbin/init and rendering your system unbootable.

Michael


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#824776: icedove-l10n: should recommend hunspell-* as alternative to myspell-*

[Jonas Smedegaard]

Quoting Jonas Smedegaard (2016-05-19 17:47:55)
> Icedove locale packages recommend myspell but not hunspell dictionary for
> the following locales:
> 
> bg ca cs el es-ar es-es gd gl he hr it lt nl no pl pt ru sk sl sv-se

Correction: not gl


> Please recommend hunspell-* as alternative to myspell-*.
> 
> As I understand it, hunspell has features not in myspell (e.g. related
> to combining words common in germanic languages), and hunspell-* should
> therefore probably be listed first in general.
> 
> NB! Both hunspell-sv-se and hunspell-sv exist - the former should likely
> be favored over the latter (the latter may have far more words - judging
> from my knowledge of its sister project in Denmark).
> 
> NB! hunspell-no is alternative to both myspell-nb-no and myspell-nn-no
> (no is country code, not language code).

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Bug#789984: pulseaudio: Incorrect detecting 2.1 audiosystem on newer laptops (ASUS N750J series)

[Scott Leggett]

On Thu, 25 Jun 2015 23:29:36 +0300 ioann  wrote:
> Package: pulseaudio
> Version: 5.0-13
> Severity: normal
> 
> Hello! I have notebook ASUS N750JK and Subwoofer "Sonic Master". The package
> pulseaudio don't have news modes (2.1) for this machine. Now exist new version
> of pulseaudio (v6). Please, replease to new version of pulseaudio in stable
> realease. Thank you.

A newer version of pulseaudio is now available in jessie-backports. Does
it fix your issue?

-- 
Regards,
Scott.


signature.asc
Description: Digital signature

Bug#756023: init: Move "Essential: yes" from init to init-system-helpers

[Michael Biebl]

Am 19.05.2016 um 18:27 schrieb Michael Biebl:
> Am 19.05.2016 um 18:11 schrieb Martin Pitt:

>>
>>>  - Now:
>>>+ "init" package: Remove "Essential: yes"
>>>+ "init-system-helpers" package: Add "Essential: yes"
>>>  - Later:
>>>+ "init": Change priority from "required" to "important".
>>
>> I committed both in
>>
>>   
>> http://anonscm.debian.org/cgit/collab-maint/init-system-helpers.git/commit/?id=da29f8242
> 
> Could we add the Important: yes field to "init"? Having that makes a lot
> of sense to me.

Now that i-s-h is Essential: yes, we could drop the Depends: i-s-h from
the init meta package.

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#756023: init: Move "Essential: yes" from init to init-system-helpers

[Ansgar Burchardt]

On Thu, 2016-05-19 at 18:27 +0200, Michael Biebl wrote:
> Could we add the Important: yes field to "init"? Having that makes a
> lot of sense to me.

To init or to its dependencies (systemd-sysv, sysvinit-core)?  The
latter would not only warn when uninstalling all init systems, but also
when switching between them (perhaps not by intention).

Ansgar

Bug#824048: Any change in blastp? (Was: Bug#824048: python-biopython: FTBFS: AssertionError: 10 != 1)

[Peter Cock]

Great - I'm glad that made sense, my email had more typos than usual
as I was in a hurry to leave the office earlier.

Thanks,

Peter

On Thu, May 19, 2016 at 4:20 PM, Andreas Tille  wrote:
> Hi Peter,
>
> I've just uploaded a package featuring the patch.
>
> Thanks a lot for the quick and helpful response
>
>   Andreas.
>
> On Thu, May 19, 2016 at 03:31:59PM +0100, Peter Cock wrote:
>> RE: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=824048
>>
>> I've committed this as "fix",
>>
>> https://github.com/biopython/biopython/commit/cb5b8f7cf16dfa9aada8d3c71ab8d588ebf0693f
>>
>> This was a sanity test which failed due to a change in the NCBI output.
>>
>> We don't currently try to parse the plain text output in this test
>> (the NCBI discourage parsing the plain text output, and we'd like
>> to drop our plain text BLAST parser anyway).
>>
>> If it is easier, you could just comment out or remote this for
>> the Biopython 1.66 Debian package?
>>
>> Thanks for letting us know,
>>
>> Peter
>>
>
> --
> http://fam-tille.de

Bug#756023: init: Move "Essential: yes" from init to init-system-helpers

[Michael Biebl]

Am 19.05.2016 um 18:11 schrieb Martin Pitt:
> Control: tag -1 pending
> 
> Hello all,
> 
> Ansgar Burchardt [2016-05-05 15:05 +0200]:
>> I would like "init" to be optional in Debian 9 for chroot environments
>> and some uses of containers.  A first step seems to be making "init" no
>> longer essential; it would nice nice if the priority could later be
>> downgraded as well (to "important") so that a minimal debootstrap will
>> not install it.
> 
> We revisited that again last week on IRC, and confirmed that
> invoke-rc.d and update-rc.d behave well enough in environments without
> any init. This was the main thing I wanted to assert before we do
> this, I'm not aware of any other reasons why this would not work any
> more.
> 
>>  - Now:
>>+ "init" package: Remove "Essential: yes"
>>+ "init-system-helpers" package: Add "Essential: yes"
>>  - Later:
>>+ "init": Change priority from "required" to "important".
> 
> I committed both in
> 
>   
> http://anonscm.debian.org/cgit/collab-maint/init-system-helpers.git/commit/?id=da29f8242

Could we add the Important: yes field to "init"? Having that makes a lot
of sense to me.

Regards,
Michael


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature