Bug#850648: Missing source of manual-031.pdf

[Gianfranco Costamagna]

control: tags -1 moreinfo
On Mon, 9 Jan 2017 06:29:04 -0500 Doug Torrance  wrote:
> Hi Andreas,
> 
> On 01/09/2017 06:26 AM, Andreas Tille wrote:
> > to my understanding manual-031.pdf will be considered as "binary without
> > source" and thus rejected by ftpmaster.  The best way to solve this
> > would be to ask upstream for the source files - the second best using
> > Files-Excluded to remove the PDF from the source tarball.
> 
> Thanks for the note!  I'll try contacting upstream.
> 

please remove moreinfo once the issue has been addressed.

G.



signature.asc
Description: OpenPGP digital signature

Bug#850787: typo in IPaddr2 (ofc_log -> ocf_log)

[ISHIKAWA Mutsumi]

Package: resource-agents
Version: 1:3.9.7-3
Severity: normal
Tags: patch

ofc_log in IPaddr2 is not defined. I Think it is typo of ocf_log.

--- resource-agents-3.9.7/heartbeat/IPaddr2.orig2017-01-10 
16:34:21.044161399 +0900
+++ resource-agents-3.9.7/heartbeat/IPaddr2 2017-01-10 16:34:33.107916996 
+0900
@@ -700,7 +700,7 @@
;;
*tentative*)
if [ $i -eq 10 ]; then
-   ofc_log warn "IPv6 address : DAD is still in 
tentative"
+   ocf_log warn "IPv6 address : DAD is still in 
tentative"
fi
;;
*)

-- 
ISHIKAWA Mutsumi
  , 

Bug#850590: ITP: openmeca -- a graphical application to model and simulate mechanical systems

[Andreas Tille]

Hi Damien,

On Mon, Jan 09, 2017 at 11:31:33PM +0100, dada wrote:
> Good ! It's a great news ! :)

:-)
 
> You will find at http://yakuru.fr/~dada/omc-deb/ a first version of the
> debian package of openmeca.
> (Note that I build this package on Ubuntu 16.04.1 LTS without gpg signature)
> 
> This is the first time for me, please tell me what's wrong.

I need to admit that I have no time for this specific package - at least
not in this state of maintenance.  Becoming a member of Debian Science
team and using the Debian Science Git repository is my minimum requirement
to have a look at a package.  The Debian Science policy

   http://debian-science.alioth.debian.org/debian-science-policy.html

should help you to learn what's needed to become a member and how to
create a Git repository.  Once you have done this please post this to
the Debian Science list (in CC) and than we move on. :-)

> Thank you very much, Damien.

You are welcome

 Andreas.

-- 
http://fam-tille.de

Bug#850786: conky: window_type desktop disappears when the desktop is clicked

[cristian_ci]

Package: conky
Version: 1.9.0-6
Severity: normal

Dear Maintainer,

Conky disappears from the desktop when the desktop is clicked, if 'window_type' 
property is set to 'desktop' (default value) in conky configuration file.
This does not happen when 'window_type' property is set to 'panel'.
I've found this bug on several ubuntu releases (also 1.10.1 conky version).

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

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

Versions of packages conky depends on:
ii  conky-std  1.9.0-6

conky recommends no packages.

conky suggests no packages.

-- no debconf information

Bug#850748: redshift: fails on startup without GPS

[Ritesh Raj Sarraf]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Control: severity -1 normal
Control: tag -1 +moreinfo


This was known to work. I don't have a Jessie install locally but I do recollect
it working manually. Hence, I've lowered the severity.


On Mon, 2017-01-09 at 22:39 +0100, rugk wrote:
> When running the software it on a device without GPS support Redshift always
> fails with the error "No more methods to try [for getting the location]". This
> happens with geoclue2 activated and even when I manually pass some coordinates
> to Redshift.

The version in Jessie is built with RandR and Vidmode support. It also has
Geoclue1 support, something which was never known to work.

So, effectively, the only option that will work under Jessie is where you
specify the location manually. And I'm surprised that that did not work for you.
It must be something else causing the problem because otherwise there'd have
been a flood of bug reports.

Can you verify, how many instances of redshift are running ?

- -- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEQCVDstmIVAB/Yn02pjpYo/LhdWkFAlh0jkAACgkQpjpYo/Lh
dWkJzw/+KeyQOwb/IKJWlNANCmq8DBE+aRY6qUyeaOSDlFMGaQ1lHepotcAmronW
v42DSU3tCzsqMtQ5/NBgvNxNLyy8RJWFM7Hyid7QrQqmWu4POThCPYY5LBVSZvsc
b5WpS0+zlwZJRzIQ3I2L2kIu/URywAInE5YsBjDfiVQHO21HhljcqOmVI7bKF0Up
a1Eabh7ZWTi7m1GKI2w9q6HZO14kbHIUGuI2Q40NnO6qiE72nhOCvf41ftwYKlNV
PbUChVo+a+MjevakxOQ/C5cXkrzDbx4OFy5E74uAIuihKnStMryYpq5TFITf0bz1
+HT76JINyroz+/b4WrL2qKMUdO+xkQfk0RJ/80stSM1+3sMrpl8fJn9p1tzHAUv3
+Jny6DeOp29Y0jKlhS/QzWlp740UabtruPkxd4xhzuKshjWoPywHrKsYs//9owg3
SyoRSIRslhSFg9t2g6K+REsTZ0mJ4LcdrrO3mf+1xSO2PXrPc9mjLe9S2yRg3eCq
IsG0gilcTUDk0w4oMx5wCVslk3p5TYrStmpjHW1VQTIt+OH/357ROy8nAGisW47u
DYAo5ldFEn69diDfkbmYJCw/1hOmYyzPRMD/K7LVXPchJCq8jjeiFRe/Y6JnYMgn
dlPXZjM3bfBR2SwfQRKEzTWJCfWb3qg7uZKRe/LtMDdcyTBJMaA=
=NAST
-END PGP SIGNATURE-

Bug#850150: freemat ftbfs with LLVM 3.9

[Gianfranco Costamagna]

control: clone -1 -2
control: block -1 by -2
control: retitle -2 llvm-toolchain-3.9 make some reverse-dependencies FTBFS on 
i386
control: reassign -2 src:llvm-toolchain-3.9
control: found -2 1:3.9.1-1
control: tags -2 patch

On Wed, 4 Jan 2017 16:14:03 +0200 Graham Inggs  wrote:
> Hi
> 
> The attached updated fix-llvm-build.patch fixes the build almost 
> everywhere by adding LLVMCoverage to OPTIONAL_LIBS.
> 
> The build now fails on i386 with the following:
> 
> In file included from 
> /usr/lib/llvm-3.9/include/llvm/Target/TargetOptions.h:20:0,
>   from 
> /usr/lib/llvm-3.9/include/llvm/Target/TargetMachine.h:22,
>   from 
> /usr/lib/llvm-3.9/include/llvm/ExecutionEngine/ExecutionEngine.h:28,
>   from 
> /<>/freemat-4.2+dfsg1/libs/libMatC/CJitFuncClang.hpp:8,
>   from 
> /<>/freemat-4.2+dfsg1/libs/libMatC/JITFactory.cpp:2:
> /usr/lib/llvm-3.9/include/llvm/MC/MCAsmInfo.h:39:6: error: expected 
> identifier before ‘,’ token
> X86, /// Windows x86, uses no CFI, just EH tables
>^
> /usr/lib/llvm-3.9/include/llvm/MC/MCAsmInfo.h: In member function ‘bool 
> llvm::MCAsmInfo::usesWindowsCFI() const’:
> /usr/lib/llvm-3.9/include/llvm/MC/MCAsmInfo.h:555:58: error: expected 
> unqualified-id before ‘)’ token
>   WinEHEncodingType != WinEH::EncodingType::X86);
>^
> 
> Regards
> Graham
> 

as already said, this seems to be a regression in llvm-toolchain-3.9, somewhere 
that X86 is already defined
and clashing with the definition.
s/X86/x86 works, even if I don't know exactly the implications of that code 
(seems to be some windows-only define
FWICS)

the patch is here:
-- llvm-toolchain-3.9-3.9.1.orig/include/llvm/MC/MCAsmInfo.h
+++ llvm-toolchain-3.9-3.9.1/include/llvm/MC/MCAsmInfo.h
@@ -36,7 +36,7 @@ enum class EncodingType {
   ARM, /// Windows NT (Windows on ARM)
   CE,  /// Windows CE ARM, PowerPC, SH3, SH4
   Itanium, /// Windows x64, Windows Itanium (IA-64)
-  X86, /// Windows x86, uses no CFI, just EH tables
+  x86, /// Windows x86, uses no CFI, just EH tables
   MIPS = Alpha,
 };
 }
@@ -552,7 +552,7 @@ public:
   bool usesWindowsCFI() const {
 return ExceptionsType == ExceptionHandling::WinEH &&
(WinEHEncodingType != WinEH::EncodingType::Invalid &&
-WinEHEncodingType != WinEH::EncodingType::X86);
+WinEHEncodingType != WinEH::EncodingType::x86);
   }
 
   bool doesDwarfUseRelocationsAcrossSections() const {
--- llvm-toolchain-3.9-3.9.1.orig/lib/CodeGen/AsmPrinter/AsmPrinter.cpp
+++ llvm-toolchain-3.9-3.9.1/lib/CodeGen/AsmPrinter/AsmPrinter.cpp
@@ -278,7 +278,7 @@ bool AsmPrinter::doInitialization(Module
 default: llvm_unreachable("unsupported unwinding information encoding");
 case WinEH::EncodingType::Invalid:
   break;
-case WinEH::EncodingType::X86:
+case WinEH::EncodingType::x86:
 case WinEH::EncodingType::Itanium:
   ES = new WinException(this);
   break;
--- llvm-toolchain-3.9-3.9.1.orig/lib/Target/X86/MCTargetDesc/X86MCAsmInfo.cpp
+++ llvm-toolchain-3.9-3.9.1/lib/Target/X86/MCTargetDesc/X86MCAsmInfo.cpp
@@ -136,7 +136,7 @@ X86MCAsmInfoMicrosoft::X86MCAsmInfoMicro
 // 32-bit X86 doesn't use CFI, so this isn't a real encoding type. It's 
just
 // a place holder that the Windows EHStreamer looks for to suppress CFI
 // output. In particular, usesWindowsCFI() returns false.
-WinEHEncodingType = WinEH::EncodingType::X86;
+WinEHEncodingType = WinEH::EncodingType::x86;
   }
 
   ExceptionsType = ExceptionHandling::WinEH;

G.



signature.asc
Description: OpenPGP digital signature

Bug#847935: [Pkg-fonts-devel] Bug#847935: Bug#847935: MICRO sign does not show

[Fabian Greffrath]

Hi Erik,

Erik Thiele wrote:
> I have no clue really. I also do not know how to find out which font is
> used.

I think we can find this out. Please install the evince package and open
the affected PDF with Evince. It has a Properties->Font dialog box that
gives information about which font is used to substitute what font
requested by the PDF. There you will find the culprit.

Do you happen to have the fonts-texgyre package installed?

 - Fabian

Bug#850446: handbrake: New upstream release 1.0.1

[Fabian Greffrath]

Sebastian Ramacher wrote:
> The patch is in the process of being upstreamed:
> https://mailman.videolan.org/pipermail/libbluray-devel/2016-December/002518.html

Thanks for the pointer!

So, let's just delay the packaging of handbrake 1.x until this new
libbluray has entered unstable. I could push what I already have to the
git repo, although that's really nothing fancy.

 - Fabian

Bug#850784: arduino: No HiDPI support in arudino 1.0.5

[solitone]

Package: arduino
Version: 2:1.0.5+dfsg2-4.1
Severity: normal

stretch delivers arduino 1.0.5, which is pretty old. This means 
that some of the new features are not available. Specifically, it 
doesn't work well with HiDPI displays (aka retina displays). In 
the latest version (1.8.1) there is a global preference setting 
that allows to scale the interface to e.g. 200%, which is a nice 
setting for my MacBookPro 13". Would it be possible to include in 
stretch a more up to date version, including this feature?
-- 
System Information: Debian Release: stretch/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

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

Versions of packages arduino depends on:
ii  arduino-core   2:1.0.5+dfsg2-4.1
ii  default-jre [java6-runtime]2:1.8-57
ii  libjna-java4.2.2-2
ii  librxtx-java   2.2pre2-13
ii  openjdk-8-jre [java6-runtime]  8u111-b14-3

Versions of packages arduino recommends:
ii  extra-xdg-menus  1.0-4
ii  policykit-1  0.105-17

arduino suggests no packages.

-- no debconf information

Bug#850672: ITP: gnome-shell-extension-show-ip -- Shows the urrent private or public IP address in the GNOME Shell status drop-down menu

[Kyle Robbertze]

On 09/01/2017 17:29, Jeff Epler wrote:
> On Mon, Jan 09, 2017 at 11:16:48AM +0200, Kyle Robbertze wrote:
>>   Description : A GNOME Shell Extesion that shows the urrent private or 
> ^ insert "c"
>> public IP address in the status drop-down menu
> 
> Aside from the trivial typo, I think it would be good if the description 
> states
> that to determine the "public IP address", a non-Free service
> (http://ipinfo.io) is used by default. (yes, I understand that using some sort
> of public service is essentially the only way to portably find the "public IP
> address" of a system)
I have included the warning and also mentioned that it is possible to
use your own lookup service with the same json structure. The updated
package can be found on mentors.d.n.

https://mentors.debian.net/package/gnome-shell-extension-show-ip

Cheers
Kyle



signature.asc
Description: OpenPGP digital signature

Bug#850755: RM: nagios3/3.5.1.dfsg-2.2

[Sebastiaan Couwenberg]

On 01/09/2017 11:33 PM, Moritz Muehlenhoff wrote:
> nagios3 was removed from unstable, but for some reason is still in testing,
> please remove it from there as well.

It still has reverse dependencies in testing, specifically nagios2mantis
is listed in the britney output [0] which `dak rm -Rn -s testing
nagios3` also lists as the only affected package.

nagios2mantis is scheduled for removal from testing on the 14th, as is
check-mk but that doesn't have a dependency on nagios3 that keeps it in
testing.

Having these packages removed from testing explicitly instead of waiting
for the autoremoval would be nice, to not have chatter in the bugreport
able extend the deadline (although that seems unlikely).

[0] https://release.debian.org/britney/update_output.txt

Kind Regards,

Bas

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

Bug#848381: openldap 2.4.44+dfsg-4: Please update debconf PO translation for the package openldap

[Ryan Tandy]

Hi,

You are noted as the last translator of the debconf translation for 
openldap. The English template has been updated with one new message. I 
would be grateful if you could take the time and update it. Please send 
the updated file to me, or submit it as a wishlist bug against openldap.

Thanks in advance,

Ryan

# Dutch translation of openldap debconf templates.
# Copyright (C) 2008-2011 THE PACKAGE'S COPYRIGHT HOLDER
# This file is distributed under the same license as the openldap package.
# Bart Cornelis , 2008.
# Jeroen Schot , 2011.
# Frans Spiesschaert , 2014.
#
msgid ""
msgstr ""
"Project-Id-Version: openldap 2.4.25-4\n"
"Report-Msgid-Bugs-To: openl...@packages.debian.org\n"
"POT-Creation-Date: 2017-01-10 05:24+\n"
"PO-Revision-Date: 2014-11-04 10:58+0100\n"
"Last-Translator: Frans Spiesschaert \n"
"Language-Team: Debian Dutch l10n Team \n"
"Language: nl\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Plural-Forms: nplurals=2; plural=(n != 1);\n"

#. Type: boolean
#. Description
#: ../slapd.templates:1001
msgid "Omit OpenLDAP server configuration?"
msgstr "Wilt u het configureren van de OpenLDAP-server overslaan?"

#. Type: boolean
#. Description
#: ../slapd.templates:1001
msgid ""
"If you enable this option, no initial configuration or database will be "
"created for you."
msgstr ""
"Wanneer u deze optie kiest, worden er geen initiële configuratie en database "
"voor u aangemaakt."

#. Type: select
#. Choices
#: ../slapd.templates:2001
msgid "always"
msgstr "altijd"

#. Type: select
#. Choices
#: ../slapd.templates:2001
msgid "when needed"
msgstr "wanneer nodig"

#. Type: select
#. Choices
#: ../slapd.templates:2001
msgid "never"
msgstr "nooit"

#. Type: select
#. Description
#: ../slapd.templates:2002
msgid "Dump databases to file on upgrade:"
msgstr "Bij de opwaardering de databases exporteren naar bestand:"

#. Type: select
#. Description
#: ../slapd.templates:2002
msgid ""
"Before upgrading to a new version of the OpenLDAP server, the data from your "
"LDAP directories can be dumped into plain text files in the standard LDAP "
"Data Interchange Format."
msgstr ""
"Vooraleer een opwaardering naar een nieuwe versie van de OpenLDAP-server "
"uitgevoerd wordt, kunnen de data in uw LDAP-catalogi geëxporteerd worden "
"naar een gewoon tekstbestand in LDIF-indeling (dit is het gestandaardiseerde "
"'LDAP Data Interchange Format')."

#. Type: select
#. Description
#: ../slapd.templates:2002
msgid ""
"Selecting \"always\" will cause the databases to be dumped unconditionally "
"before an upgrade. Selecting \"when needed\" will only dump the database if "
"the new version is incompatible with the old database format and it needs to "
"be reimported. If you select \"never\", no dump will be done."
msgstr ""
"Wanneer u 'altijd' selecteert, worden de databases voor elke opwaardering "
"onvoorwaardelijk naar een bestand geëxporteerd. Wanneer u 'wanneer nodig' "
"selecteert, worden de databases enkel geëxporteerd wanneer de nieuwe "
"database-indeling incompatibel is met de oude indeling en de data opnieuw "
"geïmporteerd moeten worden. Wanneer u 'nooit' kiest wordt er geen database-"
"export gemaakt."

#. Type: string
#. Description
#: ../slapd.templates:3001
msgid "Directory to use for dumped databases:"
msgstr "Voor database-exports te gebruiken map:"

#. Type: string
#. Description
#: ../slapd.templates:3001
msgid ""
"Please specify the directory where the LDAP databases will be exported. In "
"this directory, several LDIF files will be created which correspond to the "
"search bases located on the server. Make sure you have enough free space on "
"the partition where the directory is located. The first occurrence of the "
"string \"VERSION\" is replaced with the server version you are upgrading "
"from."
msgstr ""
"Geef de map op waarnaar LDAP-databases geëxporteerd moeten worden. In deze "
"map worden verschillende LDIF-bestanden aangemaakt die overeenkomen met de "
"zoekbasissen op de server. U dient ervoor te zorgen dat u genoeg vrije "
"ruimte heeft op de partitie waar de map zich bevindt. Het eerste voorkomen "
"van de tekst 'VERSION' wordt vervangen door de server-versie vanwaar u "
"opwaardeert."

#. Type: boolean
#. Description
#: ../slapd.templates:4001
msgid "Move old database?"
msgstr "Wilt u de oude database verplaatsen?"

#. Type: boolean
#. Description
#: ../slapd.templates:4001
msgid ""
"There are still files in /var/lib/ldap which will probably break the "
"configuration process. If you enable this option, the maintainer scripts "
"will move the old database files out of the way before creating a new "
"database."
msgstr ""
"Er bevinden zich nog bestanden in /var/lib/ldap die het configuratieproces "
"waarschijnlijk zullen verstoren. Als u voor deze optie kiest, zullen de "
"scripts 

Bug#850032: not that important

[Russell Coker]

severity 850032 normal
thanks

I don't think this bug is important.  Few people will run the usrmerge package 
and I think it will be even less popular among SE Linux users because they are 
the people who don't tend to go for such exciting changes when they are 
optional.

In addition I don't want to risk important bugs delaying package transition.

I will upload a fix for this in a few days.

-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/

Bug#740685: policy will be fixed in 2.20161023.1-7

[Russell Coker]

Version 2.20161023.1-7 (which will be uploaded in 2-3 days) will fix the 
policy aspects of this, but it won't make resolvconf work as some changes are 
required in that package.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=850783

The above bug report is now the one stopping resolvconf from working correctly 
in Stretch.  It has all the information you need to customise your system so 
resolvconf works correctly in enforcing mode.

-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/

Bug#850709: closed by Guido Günther <a...@sigxcpu.org> (Re: [Pkg-libvirt-maintainers] Bug#850709: Add debian/bug-presubj)

[Christian Ehrhardt]

Thank you Guido for the confirmation, I almost thought so seeing the
history of debian/libvirt-daemon-system.bug-presubj.
But since I didn't create that part of the delta I wanted to make sure to
mention it at least before dropping.
So in that point of view I guess our remaining delta is just a relic of the
transition off of libvirt-bin and I'll drop ours accordingly.

Bug#850783: resolvconf: needs to set correct SE Linux context on created directories and files

[Russell Coker]

Package: resolvconf
Version: 1.79
Severity: normal
Tags: patch

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=740685

I've written SE Linux policy to fix the above bug, but also we need 2 minor
changes to resolvconf.

d /run/resolvconf 0755 root root -
d /run/resolvconf/interface 0755 root root -
f /run/resolvconf/resolv.conf 644 root root -
f /run/resolvconf/enable-updates 644 root root -

A file named /usr/lib/tmpfiles.d/resolvconf.conf with contents like the above
will cause systemd to create the temporary directories and files with the
correct SE Linux context.  It will also remove the need for making a
directory in the ExecStartPre section of /lib/systemd/system/resolvconf.service.
This works for me on one of my test systems.

A patch like the below should make it work correctly on SysVInit.  On systems
that don't run SE Linux it will have no effect.

--- /etc/init.d/resolvconf.orig 2017-01-10 04:15:38.66800 +
+++ /etc/init.d/resolvconf  2017-01-10 04:31:47.14000 +
@@ -60,10 +60,14 @@
# Create directory at the target
mkdir "$RUN_CANONICALDIR" || log_action_end_msg_and_exit 1 
"Error creating directory $RUN_CANONICALDIR"
fi
+   [ -x /sbin/restorecon ] && /sbin/restorecon "$RUN_CANONICALDIR"
+
# The resolvconf run directory now exists.
if [ ! -d "${RUN_DIR}/interface" ] ; then
mkdir "${RUN_DIR}/interface" || log_action_end_msg_and_exit 1 
"Error creating directory ${RUN_DIR}/interface"
fi
+   [ -x /sbin/restorecon ] && /sbin/restorecon "${RUN_DIR}/interface" 
"${RUN_DIR}/resolv.conf "${RUN_DIR}/enable-updates
+
# The interface directory now exists.  We are done.
return
 }

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

Kernel: Linux 4.8.0-2-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 /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages resolvconf depends on:
ii  debconf [debconf-2.0]  1.5.59
ii  ifupdown   0.8.16
ii  init-system-helpers1.46
ii  lsb-base   9.20161125

resolvconf recommends no packages.

resolvconf suggests no packages.

-- Configuration Files:
/etc/init.d/resolvconf changed:
[ -x /sbin/resolvconf ] || exit 0
PATH=/sbin:/bin
RUN_DIR=/etc/resolvconf/run
ENABLE_UPDATES_FLAGFILE="${RUN_DIR}/enable-updates"
POSTPONED_UPDATE_FLAGFILE="${RUN_DIR}/postponed-update"
. /lib/lsb/init-functions
case "$1" in
  start|restart|force-reload)
init_is_upstart && exit 1
;;
  stop)
init_is_upstart && exit 0
;;
esac
log_action_end_msg_and_exit()
{
log_action_end_msg "$1" ${2:+"$2"}
exit $1
}
create_runtime_directories()
{
umask 022
if [ ! -d "$RUN_DIR" ] ; then
[ -L "$RUN_DIR" ] || log_action_end_msg_and_exit 1 "$RUN_DIR is 
neither a directory nor a symbolic link"
# It's a symlink. Its target is not a dir.
{ RUN_CANONICALDIR="$(readlink -f "$RUN_DIR")" && [ 
"$RUN_CANONICALDIR" ] ; } || log_action_end_msg_and_exit 1 "Canonical path of 
the run directory could not be determined"
# Create directory at the target
mkdir "$RUN_CANONICALDIR" || log_action_end_msg_and_exit 1 
"Error creating directory $RUN_CANONICALDIR"
fi
[ -x /sbin/restorecon ] && /sbin/restorecon "$RUN_CANONICALDIR"
# The resolvconf run directory now exists.
if [ ! -d "${RUN_DIR}/interface" ] ; then
mkdir "${RUN_DIR}/interface" || log_action_end_msg_and_exit 1 
"Error creating directory ${RUN_DIR}/interface"
fi
[ -x /sbin/restorecon ] && /sbin/restorecon "${RUN_DIR}/interface" 
"${RUN_DIR}/resolv.conf "${RUN_DIR}/enable-updates
# The interface directory now exists.  We are done.
return
}
wipe_runtime_directories()
{
# Delete files in the resolvconf run directory (target) but not the 
directory itself
[ -d "$RUN_DIR" ] || return
rm -f "$RUN_DIR"/resolv.conf
rm -f "$ENABLE_UPDATES_FLAGFILE"
rm -f "$POSTPONED_UPDATE_FLAGFILE"
rm -rf "${RUN_DIR}/interface/*"
return
}
case "$1" in
  start)
# The "start" method should only be used at boot time.
# Don't run this on package upgrade, for example.
log_action_begin_msg "Setting up resolvconf"
# Wipe runtime directories in case they aren't on a tmpfs
wipe_runtime_directories
# Create runtime directories in case they are on a tmpfs
create_runtime_directories
# Request a postponed update (needed in case the base file has content).
:> "$POSTPONED_UPDATE_FLAGFILE" || log_action_end_msg_and_exit 1 
"failed requesting update"
# Enable updates and perform the postponed update.
resolvconf --enable-updates 

Bug#850664: RFS: python-pynzb/0.1.0-3

[Carl Suster]

Control: tag -1 -moreinfo

Hi Sean,

Thanks for your review!



 The Python 2 module can still be built fine, but I removed it since
there were no rdeps.


As in my reponse to your other RFS, I'd like to confirm that this is
DPMT policy.


I don't think that it's a team policy specifically, I was just prompted by the 
lintian tag which was enabled to inform about the slowly approaching EOL of 
Python 2 in Debian, aimed at packages in the buster cycle 
(https://bugs.debian.org/829744) which is where this package is going.


If you prefer to keep the Python 2 module then I'm happy to reinstate it.



Changes since the last upload:

  * 0001-set-message_id-properly-in-expat-parser.patch: fix an upstream code.
Tests pass for Python 2 with only this change.


Your grammar is misleading.  ITYM "Tests pass for Python 2 only with
this change."


Now reads: "This change allows the tests to pass for Python 2."



  * Move lxml to Suggests since there are fallbacks, but Build-Depend on it to
run the tests.


It would be clearer to split this into two changlog entries, i.e.

* Move lxml to Suggests [from ??].
* Add build-dep on lxml to run the tests.


Now reads:

  * Move lxml to Suggests rather than Depends since there are fallbacks using
standard library XML parsers.
  * Build-Depend on lxml in order to run the test for the implementation of the
NZB parser using lxml (LXMLNZBParser).



  * For Python 3, decode strings -> bytes as utf-8 for lxml.


How did you make this change?  With a patch to the upstream code?
Please explain.


Actually this was something I wasn't quite sure about. Although I'm only 
building the Python 3 package, I wanted the source package to be able to easily 
build both the Python 2 & 3 packages in case that was desired. For that reason I 
put the Python 3 specific changes in d/rules instead of making a patch. I'm not 
sure if that's considered bad practice, but I think the only alternatives would 
be (a) forget about Python 2 support and just add a patch or (b) add a patch 
with a branch in the code based on the runtime version.


Anyway I clarified the changelog entry for now:

  * For Python 3, add a command to PYBUILD_AFTTER_BUILD_python3 in d/rules to
change the code to decode strings -> bytes as utf-8 for lxml's benefit.

And this is the relevant line of d/rules:

# lxml expects a bytes object in Python 3 so we simply decode the string as
# utf-8 for the Python 3 build. If this turns out to be problematic, we can
# instead disable lxml support for the Python 3 build in pynzb/__init__.py and
# rely on the standard library fallbacks for XML parsing.
export PYBUILD_AFTER_BUILD_python3=2to3 -n -w {build_dir}/pynzb/; sed -i -e 
's/StringIO/BytesIO/g' -e 's/BytesIO(xml)/BytesIO(bytes(xml,"utf-8"))/' 
{build_dir}/pynzb/lxml_nzb.py




  * Fix watch file (although the last release was some time ago).


Please consider dropping the parathetical remark.  It's not really
appropriate for a packaging changelog.


Done. There is a new version in mentors and git.


Cheers,
Carl

Bug#850052: Bug#850005: dgit push without dgit build-source

[Nikolaus Rath]

On Jan 09 2017, Ian Jackson  wrote:
> Ian Jackson writes ("Re: Bug#850005: dgit push without dgit build-source"):
>> Control: clone -1 -2
>> Control: retitle -2 duplicated error message on missing cached dgit view
>> Control: severity -2 minor
>> 
>> Nikolaus Rath writes ("Bug#850005: dgit push without dgit build-source"):
>> > dpkg-source: info: extracting python-llfuse in python-llfuse-1.1.1+dfsg
>> > dpkg-source: info: unpacking python-llfuse_1.1.1+dfsg.orig.tar.xz
>> > dpkg-source: info: unpacking python-llfuse_1.1.1+dfsg-4.debian.tar.xz
>> > synthesised git commit from .dsc 1.1.1+dfsg-4
>> > Format `3.0 (quilt)', need to check/update patch stack
>> > dgit: split brain (separate dgit view) may be needed (--quilt=dpm).
>> > ! Push failed, while preparing your push.
>> > ! You can retry the push, after fixing the problem, if you like.
>> > dgit: --quilt=dpm but no cached dgit view:
>> > dgit:  perhaps tree changed since dgit build[-source] ?
>> > ! Push failed, while preparing your push.
>> > ! You can retry the push, after fixing the problem, if you like.
>> 
>> The "Push failed, ..." message should be printed only once, at the
>> end.
>
> I just tried this with 2.13, using one of the tests from the dgit test
> suite, and it prints the message only once.  I think this may have
> been a mispaste somehow ?

No, this was definitely for real. I know because it got my attention.

> I'm closing this clone of the bug, with this message.  If you can
> repro this duplicated message please reopen it.

I have tried, but not it fails differently:

With the python-llfuse from alioth:

$ dgit --version
dgit version 2.13
$ git checkout 2951d
$ debuild -S
$ dgit --dpm push
canonical suite name for unstable is sid
downloading 
http://ftp.debian.org/debian//pool/main/p/python-llfuse/python-llfuse_1.1.1+dfsg-5.dsc...
last upload to archive has NO git hash
using existing python-llfuse_1.1.1+dfsg.orig.tar.xz
using existing python-llfuse_1.1.1+dfsg-5.debian.tar.xz
dgit: file python-llfuse_1.1.1+dfsg-5.debian.tar.xz has hash 
274028fa7ad8efa8cd563f9f21af2049b101b4500caa907e36b10a9f738a8280 but .dsc 
demands hash d1d8ee5c6b4a8a136145c7019cdaabbdf3be13671c9714297189129c1c87 
(perhaps you should delete this file?)
! Push failed, while checking state of the archive.
! You can retry the push, after fixing the problem, if you like.

(The .dsc file was just created by debuild -S). Is there a way to
circumvent this problem to reproduce the original problem?

Best,
-Nikolaus

-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

 »Time flies like an arrow, fruit flies like a Banana.«

Bug#850781: dgit: Use of uninitialized value $isuite in concatenation (.) or string at /usr/bin/dgit line 703.

[Sean Whitton]

On Mon, Jan 09, 2017 at 08:50:48PM -0700, Sean Whitton wrote:
> I attach the .dsc to this e-mail.  The repository was a fresh `dgit
> clone`.  To help you repro, I will perform the upload without dgit.

Of course this won't help you repro at all.  Sorry.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#850781: dgit: Use of uninitialized value $isuite in concatenation (.) or string at /usr/bin/dgit line 703.

[Sean Whitton]

On Mon, Jan 09, 2017 at 08:50:48PM -0700, Sean Whitton wrote:
> I attach the .dsc to this e-mail.  The repository was a fresh `dgit
> clone`.  To help you repro, I will perform the upload without dgit.

Of course this won't help you repro at all.  Sorry.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#709932: Lintian's --fail-on-warnings

[Sean Whitton]

Dear Niels,

As part of your fix for #709932, do you intend to reintroduce the option
to have Lintian exit non-zero when any warning tags are emitted, by some
means other than the old --fail-on-warnings?

I configure sbuild to pass --fail-on-warnings to Lintian, so I can see
problems clearly in sbuild's final output at the end of its run.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#850305: dpmb: Move from asciidoc to asciidoc-base as dependency

[Joseph Herlant]

Thanks, I'll have a look asap.

Bug#850607: RFS: flask-login/0.4.0-1 [ITA]

[Carl Suster]

Control: tag -1 -moreinfo

Hi Sean,

Thanks for your interest in flask-login!


> Can a potential sponsor work out of your Vcs-Git repository?

The Python modules team has a standard location for git repositories on alioth 
so that's where I've kept it. Commit access is automatic for all DDs and by 
request for anyone else. You just have to abide by the policy 
(https://python-modules.alioth.debian.org/policy.html) which amounts to "use a 
git-dpm workflow unless there's a good reason not to".



> I notice that the changelog suite in your repository is unstable,
> but in the RFS you indicate that you want this package to be
> uploaded to experimental.  Which is right?

I initially chose experimental because I didn't want to interfere with the 
stretch freeze, but I was since told that it was fine to upload to unstable 
since the migration to testing is handled differently during the freeze. I only 
want to upload to experimental if it's necessary because of the freeze (I'm not 
targeting stretch), otherwise unstable is preferable.



>> I have dropped the Python 2 module binary package since there
>> were no rdeps and my understanding is that going forward we
>> don't want to keep around unnecessary Python 2 packages.
>
> I'm not on the python modules team -- could you how you got this
> understanding?  I'm not doubting your knowledge, but I'd like to
> confirm.

From the lintian tag new-package-should-not-package-python2-module:

  This package appears to be the first packaging of a new upstream
  software package but it appears to package a module for Python 2.

  The 2.x series of Python is due for deprecation and will not be
  maintained past 2020 so it is recommended that Python 2 modules
  are not packaged unless necessary.

  This warning can be ignored if the package is not intended for
  Debian or if it is a split of an existing Debian package.

  Severity: wishlist, Certainty: certain

  Check: scripts, Type: binary

This is not a new package obviously, but since the Python 2 module has no rdeps 
I figured that dropping it was in line with the above goal. It's no problem to 
reinstate it though.



>>   * Relicense debian/* as Expat to match upstream.
>
> Only Tonnerre Lombard can relicense Tonnerre Lombard's work.
> Please revert this change.

I understand, but the reason I felt I could do this was because I've overwritten 
pretty much every line under debian/ apart from the old changelog entry and the 
upstream license text. Anyway I've reverted the copyright to GPL-2+ in a new 
upload to mentors & git.



> If you're able to address the issues I've raised in this message,
> please remove the moreinfo tag in this bug, and don't forget to
> re-run `dch -r` to refresh the changelog timestamp.

Done!


Cheers,
Carl

Bug#850668: tar FTCBFS for any-kfreebsd: acl/xattr detection broken

[Jonathan Haack]

Unsubscribe

> On Jan 9, 2017, at 1:18 AM, Helmut Grohne  wrote:
> 
> Source: tar
> Version: 1.29b-1.1
> User: helm...@debian.org
> Usertags: rebootstrap
> 
> Hi,
> 
> I am reporting this issue as a joint discovery with Roger Leigh
> (X-Debbugs-CCed).
> 
> While building tar, it detects the availability of xattrs/acls. The
> relevant configure check resides in the macro gl_FILE_HAS_ACL which
> lives in m4/acl.m4. The relevant test has the cache variable
> gl_cv_getxattr_with_posix_acls. The test results are:
> 
> build arch   | host arch| result
> -+--+---
> linux-any| linux-any| yes
> kfreebsd-any | kfreebsd-any | no
> linux-any| kfreebsd-any | yes
> 
> The observed behaviour is easily explained by the fact that the compiled
> program includes . Since linux headers are not installed
> into multiarch paths yet, any compiler will find them as soon as
> linux-libc-dev is installed. Thus this test effectively tests whether we
> are building on linux or for linux.
> 
> Roger Leigh pointed out that FreeBSD does support xattrs and acls, which
> leads me to the conclusion that the test is operating wrongly. Maybe the
> include directive could be made conditional to #ifdef __linux__? More
> investigation is needed here, which is why I am Ccing d-bsd@l.d.o.
> 
> This bug has blocked bootstrapping kfreebsd-any for a while now, because
> I originally thought it was #837351 and nobody else had time to look
> into it (not sure what happened to Steven). It'd help a lot with keeping
> the bsd ports alive if FTBFS in essential packages could be fixed in a
> more timely manner. I guess that's also the reason why it got kicked
> from testing. :-/
> 
> In rebootstrap, I'll be working around this issue now and hand it over
> to the bsd porters.
> 
> Helmut
> 



signature.asc
Description: Message signed with OpenPGP

Bug#844943: python-bleach: FTBFS: Tests failures

[Pirate Praveen]

On Mon, 19 Dec 2016 20:54:02 +0530 Pirate Praveen 
wrote:
> Seems python-html5lib was updated without checking reverse dependency
> compatibility  https://github.com/mozilla/bleach/issues/212
> 

bleach and other projects using html5lib seems to have locked the
version of html5lib to the one with 7 nines. Can we also go back to the
older version which works?

It is not sustainable to expect maintainers to reverse dependencies to
fix breakage with
out giving them advance notice. Since python-bleach has autopkgtests
defined, it
would have been easy to find out if an update of python-html5lib would
break it or not using a tool like build-and-upload script from
pkg-ruby-extras team [1]

This is now blocking progress of pagure too (which we want to use for
git.debian.org).

[1]
https://anonscm.debian.org/cgit/pkg-ruby-extras/pkg-ruby-extras.git/tree/build-and-upload



signature.asc
Description: OpenPGP digital signature

Bug#850782: ITP: python-curio -- library for concurrent I/O with coroutines

[Ben Finney]

Package: wnpp
Severity: wishlist
Owner: Ben Finney 

* Package name: python-curio
  Version : 0.4
  Upstream Author : David Beazley 
* URL : https://github.com/dabeaz/curio
* License : BSD 3-clause
  Programming Lang: Python
  Description : library for concurrent I/O with coroutines
  Curio is a library for performing concurrent I/O and common
  system programming tasks such as launching subprocesses and
  farming work out to thread and process pools. It uses Python
  coroutines and the explicit async/await syntax introduced in
  Python 3.5. Its programming model is based on cooperative
  multitasking and existing programming abstractions such as
  threads, sockets, files, subprocesses, locks, and queues. You'll
  find it to be small and fast.

-- 
 \  “We tend to scoff at the beliefs of the ancients. But we can't |
  `\scoff at them personally, to their faces, and this is what |
_o__) annoys me.” —Jack Handey |
Ben Finney 


signature.asc
Description: PGP signature

Bug#850780: linux-image-4.8.0-2-amd64: can't boot on Acer Aspire V5, stuck on initrd

[Ben Hutchings]

Control: tag -1 moreinfo

On Tue, 2017-01-10 at 04:40 +0100, Ove Kåven wrote:
> Package: src:linux
> Version: 4.8.15-2
> Severity: critical
> Justification: breaks the whole system
> 
> I'm still stuck with linux 4.6 on this laptop. Both the current 4.7 and
> 4.8 images just hangs on "Loading initramfs". There aren't any further
> messages.
> 
> It has similarities to #841883, but I'm submitting a separate report
> just in case. (After all, perhaps 4.8.7-1 fixed the issue for that
> submitter, but it certainly didn't for me.)
> 
> I tried using "earlyprintk=vga" like suggested in #841850, but it had no
> effect. Maybe that option doesn't work if grub2 boots in graphics mode,
> but I'm not sure how to disable that without causing other boot errors.
> Maybe you have some ideas?
[...]

Please try with "earlyprintk=vga debug"

Ben.

-- 
Ben Hutchings
Make three consecutive correct guesses and you will be considered an
expert.



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

Bug#850781: dgit: Use of uninitialized value $isuite in concatenation (.) or string at /usr/bin/dgit line 703.

[Sean Whitton]

Package: dgit
Version: 3.0
Severity: normal

Thank you for dgit 3.0!  Unfortunately:

hephaestus ~/rfs/mytop % dgit import-dsc ../mytop_1.9.1-4.dsc rfs
gpgv: Signature made Mon 09 Jan 2017 04:22:08 PM MST
gpgv:using RSA key 03B346A87E36048870E56E9C2AD2A004BFB21FE1
gpgv: Can't check signature: No public key
dgit: warning: failed to verify signature on ../mytop_1.9.1-4.dsc
Dgit metadata in .dsc: NO git hash
using existing mytop_1.9.1.orig.tar.gz
using existing mytop_1.9.1-4.debian.tar.xz
gpgv: Signature made Mon 09 Jan 2017 04:22:08 PM MST
gpgv:using RSA key 03B346A87E36048870E56E9C2AD2A004BFB21FE1
gpgv: Can't check signature: No public key
dpkg-source: warning: failed to verify signature on ./mytop.dsc
dpkg-source: info: extracting mytop in mytop-1.9.1
dpkg-source: info: unpacking mytop_1.9.1.orig.tar.gz
dpkg-source: info: unpacking mytop_1.9.1-4.debian.tar.xz
Use of uninitialized value $isuite in concatenation (.) or string at 
/usr/bin/dgit line 703.

There did not look to be any interesting output with -.

I attach the .dsc to this e-mail.  The repository was a fresh `dgit
clone`.  To help you repro, I will perform the upload without dgit.

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

Kernel: Linux 4.8.0-1-686-pae (SMP w/2 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 dgit depends on:
ii  apt   1.4~beta2
ii  ca-certificates   20161102
ii  coreutils 8.25-2
ii  curl  7.50.1-1
ii  devscripts2.16.14
ii  dpkg-dev  1.18.10
ii  dput-ng [dput]1.11
ii  git [git-core]1:2.11.0-1
ii  git-buildpackage  0.8.7
ii  libdpkg-perl  1.18.10
ii  libjson-perl  2.90-1
ii  liblist-moreutils-perl0.416-1+b1
ii  libperl5.24 [libdigest-sha-perl]  5.24.1~rc4-1
ii  libtext-glob-perl 0.10-1
ii  libtext-iconv-perl1.7-5+b4
ii  libwww-perl   6.15-1
ii  perl  5.24.1~rc4-1

Versions of packages dgit recommends:
ii  openssh-client [ssh-client]  1:7.3p1-5

Versions of packages dgit suggests:
ii  sbuild  0.72.0-2

-- no debconf information

-- 
Sean Whitton
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 3.0 (quilt)
Source: mytop
Binary: mytop
Architecture: all
Version: 1.9.1-4
Maintainer: Werner Detter 
Homepage: http://www.mysqlfanboy.com/mytop-3/
Standards-Version: 3.9.8
Build-Depends: debhelper (>= 10)
Package-List:
 mytop deb utils optional arch=all
Checksums-Sha1:
 2f245459c1f465b15f0a7fe571bd5cb559c0f02e 22095 mytop_1.9.1.orig.tar.gz
 69ad171776e44d3f413d281c75bb6da4fbbbe518 10272 mytop_1.9.1-4.debian.tar.xz
Checksums-Sha256:
 179d79459d0013ab9cea2040a41c49a79822162d6e64a7a85f84cdc44828145e 22095 
mytop_1.9.1.orig.tar.gz
 6eb177ebbf68e79b30089d635a9eab1c7915f35ed930a2d08550c1876ae1146b 10272 
mytop_1.9.1-4.debian.tar.xz
Files:
 9c9c2eee657a1ec98b5456f6ac4e0447 22095 mytop_1.9.1.orig.tar.gz
 a8a8513dedddc566694ac5874a885f53 10272 mytop_1.9.1-4.debian.tar.xz

-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEEA7NGqH42BIhw5W6cKtKgBL+yH+EFAlh0GyAACgkQKtKgBL+y
H+ETkwf+NInGaNuLGyq9dk86k5elvla2ew6xc+1YLGrmnXs+OAh+nkPkH1gNPd/x
MDnsuoy2rmgyMGkX0QqAqBjqXtEND4TZxgH/nvWCsTEUI5oMkSNYtgHj70ny9iUA
Py7xFYCSYmPOyStS6Ii0FXrtw6v1QXoQ/HjNf4tNYhDqS3XLjxJj9SMCgloSNKpZ
nq8rziaO1aDmInPTHM7e5XctM1qYtCY2TORgjhCCt1sMOPfE5W0zLSGpMTzkbpmB
HT3oT48muKV02eKQZxV4+wUVN23spJUDwqUrNUFtU8o8Bo+2d6orM82YXrRXnaBi
aLL22Qv18XFVFbPNyT0PpE4pZ1fpDw==
=TJRd
-END PGP SIGNATURE-


mytop_1.9.1-4.debian.tar.xz
Description: application/xz


signature.asc
Description: PGP signature

Bug#850780: linux-image-4.8.0-2-amd64: can't boot on Acer Aspire V5, stuck on initrd

[Ove Kåven]

Package: src:linux
Version: 4.8.15-2
Severity: critical
Justification: breaks the whole system

I'm still stuck with linux 4.6 on this laptop. Both the current 4.7 and
4.8 images just hangs on "Loading initramfs". There aren't any further
messages.

It has similarities to #841883, but I'm submitting a separate report
just in case. (After all, perhaps 4.8.7-1 fixed the issue for that
submitter, but it certainly didn't for me.)

I tried using "earlyprintk=vga" like suggested in #841850, but it had no
effect. Maybe that option doesn't work if grub2 boots in graphics mode,
but I'm not sure how to disable that without causing other boot errors.
Maybe you have some ideas?

Not sure what other information would be useful from me. I couldn't use
reportbug because it currently seems broken (crashes while collecting
information). But here's the /proc/cpuinfo for the first cpu core, at least:

processor   : 0
vendor_id   : AuthenticAMD
cpu family  : 21
model   : 19
model name  : AMD A10-5757M APU with Radeon(tm) HD Graphics
stepping: 1
microcode   : 0x6001119
cpu MHz : 1400.000
cache size  : 2048 KB
physical id : 0
siblings: 4
core id : 0
cpu cores   : 2
apicid  : 16
initial apicid  : 0
fpu : yes
fpu_exception   : yes
cpuid level : 13
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext
fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc
extd_apicid aperfmperf eagerfpu pni pclmulqdq monitor ssse3 fma cx16
sse4_1 sse4_2 popcnt aes xsave avx f16c lahf_lm cmp_legacy svm extapic
cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs xop skinit wdt
lwp fma4 tce nodeid_msr tbm topoext perfctr_core perfctr_nb cpb
hw_pstate vmmcall bmi1 arat npt lbrv svm_lock nrip_save tsc_scale
vmcb_clean flushbyasid decodeassists pausefilter pfthreshold
bugs: fxsave_leak sysret_ss_attrs
bogomips: 4990.76
TLB size: 1536 4K pages
clflush size: 64
cache_alignment : 64
address sizes   : 48 bits physical, 48 bits virtual
power management: ts ttp tm 100mhzsteps hwpstate cpb eff_freq_ro

Bug#850664: RFS: python-pynzb/0.1.0-3

[Sean Whitton]

control: tag -1 +moreinfo

Dear Carl,

On Mon, Jan 09, 2017 at 12:56:51PM +1100, Carl Suster wrote:
> I am looking for a sponsor for my package "python-pynzb"

Thank you for your interest!

>  The Python 2 module can still be built fine, but I removed it since
> there were no rdeps.

As in my reponse to your other RFS, I'd like to confirm that this is
DPMT policy.

> Changes since the last upload:
>
>   * 0001-set-message_id-properly-in-expat-parser.patch: fix an upstream code.
> Tests pass for Python 2 with only this change.

Your grammar is misleading.  ITYM "Tests pass for Python 2 only with
this change."

>   * Move lxml to Suggests since there are fallbacks, but Build-Depend on it to
> run the tests.

It would be clearer to split this into two changlog entries, i.e.

* Move lxml to Suggests [from ??].
* Add build-dep on lxml to run the tests.

>   * For Python 3, decode strings -> bytes as utf-8 for lxml.

How did you make this change?  With a patch to the upstream code?
Please explain.

>   * Fix watch file (although the last release was some time ago).

Please consider dropping the parathetical remark.  It's not really
appropriate for a packaging changelog.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#850607: RFS: flask-login/0.4.0-1 [ITA]

[Sean Whitton]

control: tag -1 +moreinfo

Dear Carl,

On Sun, Jan 08, 2017 at 11:38:27PM +1100, Carl Suster wrote:
> I am looking for a sponsor for my package "flask-login"

Thank you for your work to revitalise the package.

> To be clear I am not targeting stretch even if that's somehow possible at this
> stage.

Can a potential sponsor work out of your Vcs-Git repository?

I notice that the changelog suite in your repository is unstable, but in
the RFS you indicate that you want this package to be uploaded to
experimental.  Which is right?

> I have dropped the Python 2 module binary package since there were no
> rdeps and my understanding is that going forward we don't want to keep
> around unnecessary Python 2 packages.

I'm not on the python modules team -- could you how you got this
understanding?  I'm not doubting your knowledge, but I'd like to
confirm.

>   * Relicense debian/* as Expat to match upstream.

Only Tonnerre Lombard can relicense Tonnerre Lombard's work.  Please
revert this change.

If you're able to address the issues I've raised in this message, please
remove the moreinfo tag in this bug, and don't forget to re-run `dch -r`
to refresh the changelog timestamp.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#850779: blacs-mpi: should powerpcspe be a target architecture?

[Drew Parsons]

Source: blacs-mpi
Version: 1.1-37
Severity: wishlist

Currently powerpcspe is not listed in the architecture list for
blacs-mpi.  Is there a specific reason why it's missing, or should it
be added?  

Your source generates debian/control from control.in.  Looks like the
update needs to be made in debian/rules where the architecture lists
are defined. You could use the lists in
/usr/share/mpi-default-dev/debian_defaults (from mpi-default-dev)
rather than maintaining your own list.

Then debian/control can be regenerated with the updated lists.

Cheers,
Drew

Bug#849318: RFS: eoconv/1.5-1

[Sean Whitton]

Dear Andreas,

On Sun, Dec 25, 2016 at 02:42:42PM +0100, Andreas Henriksson wrote:
> Your changes looks fine and I can sponsor them for you if you wish
> but have some questions for you below first.

This RFS has been waiting on your response for a few weeks now, and
winter is coming.  Are you prepared to upload, or can someone else take
this RFS off your hands?

In the future, please consider taking ownership of RFS bugs that you
intend to shepherd through to upload.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#850708: [pkg-gnupg-maint] Bug#850708: gpg: decryption failed: No secret key

[Vincent Lefevre]

On 2017-01-09 18:00:14 -0500, Daniel Kahn Gillmor wrote:
> On Mon 2017-01-09 10:02:20 -0500, Vincent Lefevre wrote:
> > Since the latest upgrade:
> >
> > * When I open a .gpg file with Emacs:
> >
> > * With "gpg -d note.gpg", same errors:
> >
> > gpg: AES encrypted data
> > gpg: cancelled by user
> > gpg: encrypted with 1 passphrase
> > gpg: decryption failed: No secret key
> >
> > The errors are immediate and 100% reproducible.
> 
> is this with a symmetrically-encrypted file, or with a file that is
> encrypted with a public key?

note.gpg: GPG symmetrically encrypted data (AES cipher)

> I'm unable to reproduce this problem.
> 
> what pinentry are you using?

pinentry-gtk-2

No problems with pinentry-curses.

> how is your pinentry launched or managed?

I don't know. I suppose that's gpg-agent that starts it.

> what happens if you do:
> 
> gpg-connect-agent 'get_passphrase cacheval123 errorrmsg leadprompt 
> description' /bye
> 
> this *should* throw up a password prompt in your graphical display.

Most of the time:

zira:~> gpg-connect-agent 'get_passphrase cacheval123 errorrmsg leadprompt 
description' /bye
ERR 83886179 Operation cancelled 

Sometimes a pinentry window appears.

> you can clear the same cached passphrase with:
> 
> gpg-connect-agent 'clear_passphrase cacheval123' /bye

If I do that first, I get the same error.

Same problem if I use a wrapper:

#!/bin/sh
exec /usr/bin/pinentry-gtk-2 "$@"

but if I use strace:

#!/bin/sh
exec strace -f -tt -o /home/vinc17/str.out /usr/bin/pinentry-gtk-2 "$@"

I can't reproduce the problem. :(

If I use

#!/bin/sh
exec /usr/bin/pinentry-gtk-2 "$@" 2> /tmp/stderr

I get in /tmp/stderr:

** (pinentry-gtk-2:2711): WARNING **: it took 16 tries to grab the keyboard

** (pinentry-gtk-2:2711): CRITICAL **: could not grab pointer: already grabbed 
(1)

Perhaps the problem. Couldn't gpg-agent capture pinentry's standard
error to give it back to the user in case of error?

If I add strace to make it work, then /tmp/stderr is empty.

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

Bug#850778: [plasma-desktop] Could not mount removable device

[Alex Volkov]

Package: plasma-desktop
Version: 4:5.8.2-1
Severity: normal

--- Please enter the report below this line. ---

Trying to mount a removable disk from tray gives: "You are not authorised to 
mount this device". The user is a member of plugdev and shit. Is it another 
systemd shit RedHat joyously gave to us all?

--- System information. ---
Architecture: 
Kernel:   Linux 4.8.11-bootes0-iommu-p-300

Debian Release: stretch/sid
  990 stable  security.debian.org 
  990 stable  ftp.fi.debian.org 
  990 stable  dl.google.com 
  990 stable  deb.torproject.org 
   90 unstabledeb.i2p2.no 
  500 testing ftp.fi.debian.org 
  500 testing deb.torproject.org 

--- Package information. ---
Depends (Version) 
| Installed
=-
+-==
breeze
| 4:5.8.2-1
kactivitymanagerd 
| 5.8.2-1
kde-cli-tools 
| 4:5.8.2-1
kded5 
| 5.27.0-1
kio   
| 5.27.0-2
oxygen-sounds 
| 4:5.8.2-1
plasma-desktop-data (= 4:5.8.2-1) 
| 4:5.8.2-1
plasma-framework  
| 5.27.0-1
plasma-integration
| 5.8.2-1+b1
plasma-workspace  
| 4:5.8.2-1
polkit-kde-agent-1
| 4:5.8.4-1
qml-module-org-kde-draganddrop
| 5.27.0-1+b1
qml-module-org-kde-kcoreaddons
| 5.27.0-1+b1
qml-module-org-kde-kquickcontrols 
| 5.27.0-1+b1
qml-module-org-kde-kquickcontrolsaddons   
| 5.27.0-1+b1
qml-module-org-kde-kwindowsystem  
| 5.27.0-1+b1
qml-module-org-kde-solid  
| 5.27.0-1
qml-module-qt-labs-folderlistmodel
| 5.7.1-1
qml-module-qt-labs-settings   
| 5.7.1-1
libc6   (>= 2.15) 
| 
libcanberra0 (>= 0.2) 
| 
libfontconfig1  (>= 2.11) 
| 
libgcc1(>= 1:3.0) 
| 
libkf5activities5 (>= 5.21.0) 
| 
libkf5activitiesstats1  (>= 5.20) 
| 
libkf5archive5(>= 4.96.0) 
| 
libkf5auth5   (>= 4.96.0) 
| 
libkf5baloo5  (>= 5.15.0) 
| 
libkf5bookmarks5  (>= 4.96.0) 
| 
libkf5codecs5 (>= 4.96.0) 
| 
libkf5completion5 (>= 4.97.0) 
| 
libkf5configcore5 (>= 5.24.0) 
| 
libkf5configgui5  (>= 5.25.0) 
| 
libkf5configwidgets5(>= 5.7.0+git20150228.0110+15.04) 
| 
libkf5coreaddons5   (>= 5.4.0+git20141202.0008+15.04) 
| 
libkf5dbusaddons5 (>= 4.99.0) 
| 
libkf5emoticons-bin   
| 
libkf5emoticons5  (>= 4.96.0) 
| 
libkf5globalaccel5(>= 5.10.0) 
| 
libkf5guiaddons5  (>= 4.96.0) 
| 
libkf5i18n5(>= 5.0.0) 
| 
libkf5iconthemes5  (>= 5.0.0) 
| 
libkf5itemmodels5 (>= 5.14.0) 
| 
libkf5itemviews5  (>= 4.96.0) 
| 
libkf5jobwidgets5 (>= 4.96.0) 
| 
libkf5kcmutils5   (>= 4.96.0) 
| 
libkf5kdelibs4support5(>= 4.99.0) 
| 
libkf5kiocore5  

Bug#850768: [Pkg-amule-devel] Bug#850768: amule-daemon fails on startup (same as #840496)

[Sandro Tosi]

On Mon, Jan 9, 2017 at 7:22 PM, David Garabana Barro  wrote:
> Unsharing directories with non english characters made it start 
> again. Once you share a single non english name, it crash again on start.

could you install amule-dbg and run amule thru gdb and once it crashes
run "bt ; bt full ; thread apply all bt" in gdb prompt? thanks

-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
G+: https://plus.google.com/u/0/+SandroTosi

Bug#850777: [gcc-6] internal compiler error on ppc64el (may be bug)

[lumin]

Package: gcc-6
Version: 6.3.0-2
Severity: normal

Hi,

GCC-6 failed when buildd is building torch7 package for ppc64el
architecture. The buiild log can be found here:

https://buildd.debian.org/status/fetch.php?pkg=lua-torch-torch7=ppc64el=0~20170106-gf624ae9-1=1483980176

Currently I don't know whether this is a upstream code bug
or GCC-6 bug. The upstream code seems to have introduced
the VSX (SIMD) instruction set.

Bug#850505: fortune-zh: please make the build reproducible

[lumin]

On Mon, 2017-01-09 at 17:38 +, Chris Lamb wrote:
> lumin wrote:
> 
> > Trying to upload package to ftp-master (ftp.upload.debian.org)
> Checking signature on .changes
> > Uploading to ftp-master (via ftp to ftp.upload.debian.org):
>   Uploading fortune-zh_2.1_all.deb: done.
>   Uploading fortune-zh_2.1_amd64.buildinfo: done.
>   Uploading fortune-zh_2.1_amd64.changes: done.
> Successfully uploaded packages.

Thank you for sponsoring. However Adam Borowski made an
even faster sponsorship... The repro problem is fixed
on all available architectures according to the page:
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/fortune-zh.html

> (btw should this really be a native package?)

Yes, and sure. The original upstream author of this
package is a Debian developer and the initial packaging was
native. The current upstream is myself and I'm following
the previous maintainer.

Bug#850776: zfs-auto-snapshot: cronjob exits with error after package removal

[Andreas Beckmann]

Package: zfs-auto-snapshot
Version: 1.2.1-1
Severity: important
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your packages cronjob exits with
error after the package has been removed.

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

1m6.2s DEBUG: Starting command: ['chroot', '/tmp/piupartss/tmpXPG5CS', 
'/etc/cron.daily/zfs-auto-snapshot']
1m6.2s DUMP: 
  /etc/cron.daily/zfs-auto-snapshot: 2: exec: zfs-auto-snapshot: not found
1m6.2s ERROR: Command failed (status=127): ['chroot', 
'/tmp/piupartss/tmpXPG5CS', '/etc/cron.daily/zfs-auto-snapshot']


cheers,

Andreas


zfs-auto-snapshot_1.2.1-1.log.gz
Description: application/gzip

Bug#850775: trafficserver: fails to upgrade from 'jessie-backports' - trying to overwrite /usr/lib/trafficserver/modules/authproxy.so

[Andreas Beckmann]

Package: trafficserver
Version: 7.0.0-2
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts
Control: affects -1 + trafficserver-experimental-plugins

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'jessie-backports'.
It installed fine in 'jessie-backports', 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...):

  Preparing to unpack .../trafficserver_7.0.0-2_amd64.deb ...
  Running in chroot, ignoring request.
  invoke-rc.d: policy-rc.d denied execution of stop.
  Unpacking trafficserver (7.0.0-2) over (6.2.0-1~bpo8+1) ...
  dpkg: error processing archive 
/var/cache/apt/archives/trafficserver_7.0.0-2_amd64.deb (--unpack):
   trying to overwrite '/usr/lib/trafficserver/modules/authproxy.so', which is 
also in package trafficserver-experimental-plugins 6.2.0-1~bpo8+1
  dpkg-deb: error: subprocess paste was killed by signal (Broken pipe)
  Running in chroot, ignoring request.
  invoke-rc.d: policy-rc.d denied execution of start.


cheers,

Andreas


trafficserver-experimental-plugins_7.0.0-2.log.gz
Description: application/gzip

Bug#850098: #850098 subliminal: change of upstream structure

[Carl Suster]

I see that subliminal is currently using the tarballs from PyPI and then 
patching in the source for the nautilus extension which is of course absent 
from there. Also the Github-hosted tarballs include a test suite which is not 
in the PyPI tarballs.


It seems that the upstream nautilus extension has now moved to a different 
dedicated upstream repo:


  https://github.com/Diaoul/nautilus-subliminal

Unfortunately this repository does not seem to have versioned releases, and has 
not seen an update in several months. My thinking is that if we continue to 
provide the nautilus extension at all, it should be built by a new source 
package src:subliminal-nautilus (which could potentially also build the nemo 
extension provided in a different branch of the upstream repo) tracking 
snapshots of the upstream git.


I am happy to work on this as part of packaging the latest upstream release, 
but I just wanted to check before I do so that:


  1) the source split I proposed is sensible (if so I'll probably just drop 
the nautilus extension for now and reopen https://bugs.debian.org/821455 until 
I repackage the extension in its new home), and


  2) if the split is ok, which if either Python packaging team would make a 
good home for the nautilus extension, and


  3) it's ok to change the tarballs to the Github ones and update the d/watch 
accordingly. The point of this would be to be able to run the test suite.


Cheers,
Carl

Bug#850774: libclojure-java: fails to upgrade squeeze -> wheezy -> jessie -> stretch

[Andreas Beckmann]

Package: libclojure-java
Version: 1.8.0-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts
Control: affects -1 + clojure

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'squeeze' to 'wheezy' to 'jessie' to 'stretch'.
It installed fine in 'squeeze', and upgraded to 'wheezy' and 'jessie'
successfully, but then the upgrade to 'stretch' failed.

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

  Selecting previously unselected package libclojure-java.
  Preparing to unpack .../libclojure-java_1.8.0-1_all.deb ...
  Unpacking libclojure-java (1.8.0-1) ...
  dpkg: error processing archive 
/var/cache/apt/archives/libclojure-java_1.8.0-1_all.deb (--unpack):
   trying to overwrite '/usr/share/java/clojure.jar', which is also in package 
clojure 1.1.0+dfsg-1


cheers,

Andreas


clojure_1.8.0-1.log.gz
Description: application/gzip

Bug#850773: xul-ext-kwallet5: Doesn't work with firefox "non-ESR"

[Alex Gould]

Package: xul-ext-kwallet5
Version: 1.0-2
Severity: normal

Dear Maintainer,

I tried installing the "firefox" package. I am able to look up my
passwords manually at about:preferences#security, but they are not
automatically filled into forms, or added/updated when visiting new
websites.

Thanks for your help!

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

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

Versions of packages xul-ext-kwallet5 depends on:
ii  firefox   50.1.0-1
ii  libc6 2.24-8
ii  libgcc1   1:6.2.1-5
ii  libkf5wallet-bin  5.27.0-1
ii  libkf5wallet5 5.27.0-1
ii  libqt5core5a  5.7.1+dfsg-2
ii  libqt5gui55.7.1+dfsg-2
ii  libstdc++66.2.1-5

xul-ext-kwallet5 recommends no packages.

xul-ext-kwallet5 suggests no packages.

-- no debconf information

Bug#850772: multipath-tools-boot: fails to upgrade from 'jessie' - trying to overwrite /etc/init.d/multipath-tools-boot

[Andreas Beckmann]

Package: multipath-tools-boot
Version: 0.6.4-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...):

  Preparing to unpack .../multipath-tools-boot_0.6.4-1_all.deb ...
  Unpacking multipath-tools-boot (0.6.4-1) over (0.5.0-6+deb8u2) ...
  dpkg: error processing archive 
/var/cache/apt/archives/multipath-tools-boot_0.6.4-1_all.deb (--unpack):
   trying to overwrite '/etc/init.d/multipath-tools-boot', which is also in 
package multipath-tools 0.5.0-6+deb8u2
  Preparing to unpack .../multipath-tools_0.6.4-1_amd64.deb ...
  invoke-rc.d: could not determine current runlevel
  invoke-rc.d: policy-rc.d denied execution of stop.
  Unpacking multipath-tools (0.6.4-1) over (0.5.0-6+deb8u2) ...


In case it does matter, this was observed during a
wheezy->jessie->stretch upgrade test.


cheers,

Andreas


multipath-tools-boot_0.6.4-1.log.gz
Description: application/gzip

Bug#850770: RM: hhvm/3.12.11+dfsg-1

[Faidon Liambotis]

On Tue, Jan 10, 2017 at 01:38:58AM +0100, Moritz Muehlenhoff wrote:
> please remove hhvm from testing. HHVM is still undergoing rapid changes and
> the current 3.12.x series is already out of upstream support. We can
> reconsider for buster.

We've discussed this with Moritz already but for the record and in case
it matters: I fully support this, with my HHVM maintainer hat on.

Regards,
Faidon

Bug#801796: nikola: New upstream release: 7.7.3

[Christoph Biedl]

Control: retitle -1 nikola: New upstream release: 7.8.2

[ Just another random nikola user ]

Chris Warrick wrote...

> Please get your act together and update this package. And if you can’t take
> care of a package, why bother maintaining it and having it altogether?
> Updating Nikola between versions is generally painless; we might add
> dependencies rarely, but we do our best to keep the base requirements list
> unchanged.

Unfortunately a recent change actually brought a new dependency, and so
the build fails:

| pkg_resources.DistributionNotFound: The 'piexif>=1.0.3' distribution was not 
found and is required by Nikola

The piexif package isn't packaged in Debian. If I understand correctly -
I'm not into Python -, https://bugs.debian.org/81 is about it, but
the deadline for an upload passed more than two weeks ago. So I guess
that's it for stretch :-/

Only thing that still could save the show was to disable the code that
uses this library, then do a fresh upload. Probably even more ugly than
it sounds.

Christoph


signature.asc
Description: Digital signature

Bug#850771: include doc/keys.en.html in binary package

[Trent W. Buck]

Package: inkscape
Version: 0.92.0-2
Severity: wishlist

The Inkscape "Help" menu needs internet access to work.
This is annoying for airgapped users.

IIRC most of the menu items link to non-DFSG content,
but one menu item is easy to fix: inkscape_help_keys.inx.
The inkscape source package contains the same content:

 -rw-r--r--   0/0  4250 inkscape-0.92.0/doc/keys.css

 -rw-r--r--   0/0381998 inkscape-0.92.0/doc/keys.be.html
 -rw-r--r--   0/0351116 inkscape-0.92.0/doc/keys.de.html
 -rw-r--r--   0/0389980 inkscape-0.92.0/doc/keys.el.html
 -rw-r--r--   0/083 inkscape-0.92.0/doc/keys.en.html
 -rw-r--r--   0/0351169 inkscape-0.92.0/doc/keys.fr.html
 -rw-r--r--   0/0356171 inkscape-0.92.0/doc/keys.ja.html
 -rw-r--r--   0/0335584 inkscape-0.92.0/doc/keys.zh_TW.html

Please install these somewhere like
file:///usr/share/doc/inkscape/html/ or
file:///usr/share/inkscape/doc/html/,
and patch inkscape_help_keys.inx to point to them instead of
http://inkscape.org/doc/keys092.html.


UPDATE: one problem I hadn't considered is language detection.
I presume the HTTP version does this via Accept-Language[0].
The keys.*.html files don't link to one another,
so inkscape_help_keys.inx or launch_webbrowser.py might need to be
extended provide equivalent functionality based on $LANG?

[0] https://en.wikipedia.org/wiki/Content_negotiation


PS: the keys.*.html in inkscape are copied from the separate inkscape-docs 
package (not in Debian).
Packaging that might be a better approach, I dunno.
At a glance, everything in it appears to be synced into the normal inkscape 
source tarball:
http://bazaar.launchpad.net/~inkscape.dev/inkscape-docs/trunk/files/

Bug#850763: Option for build directory is needed

[Alf Gaida]

> Can you try setting those environment variables and let me know if it 
works?

> If it does then this is just a docfix.

% sudo TMP=. lwr
DEBUG environment: TMP=.
DEBUG vmdebootstrap command: ... --squash=./tmp5fr6Ev/live ...

looks good so far

Cheers Alf

Bug#850756: cryptsetup: Please save password to kernel keyring

[Christoph Anton Mitterer]

On Mon, 2017-01-09 at 23:58 +0100, Laurent Bigonville wrote:
> Since gdm 3.22, there is a new pam module that unlock the gnome-
> keyring
> using the keyring using the password of the luks partition.
> 
> The idea is that on a single user laptop, the user uses the same
> password for his encrypted root and user in addition to autologin.

Don't think this should happen automatically... after all there are n
non-single-user-laptop scenarios, and while GDM/GNOME may be targeted
primarily towards only this scenario, Debian should not.


Cheers,
Chris.

smime.p7s
Description: S/MIME cryptographic signature

Bug#850770: RM: hhvm/3.12.11+dfsg-1

[Moritz Muehlenhoff]

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

Hi,
please remove hhvm from testing. HHVM is still undergoing rapid changes and
the current 3.12.x series is already out of upstream support. We can
reconsider for buster.

(Not filing an RC bug since it can't reenter after being removed at this
point anyway)

Cheers,
Moritz

Bug#850769: libdbusmenu-gtk4: Sends Ubuntu-specific signal child-added

[Ingo Bauersachs]

Package: libdbusmenu-gtk4
Version: 12.10.2-1
Severity: important
Tags: upstream

Dear Maintainer,

libdbusmenu sends the Gtk signal child-added to modify menus.
This signal is/was Ubuntu specific and should be replaced
with the insert signal. Sending child-added instead of
insert makes modifying menus of an AppIndicator tray icon
impossible, resulting in the following error message and
potentially segfaulting.

GLib-GObject-WARNING **:
/build/glib2.0-m2w47E/glib2.0-2.50.2/./gobject/gsignal.c:2523: signal 'child-
added' is invalid for instance '0x7f95243242c0' of type 'GtkMenu'

This has been fixed upstream. Please see Ubuntu bug
#1203888 for further information.

Bug #727533 is maybe related.



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

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

Versions of packages libdbusmenu-gtk4 depends on:
ii  libatk1.0-0  2.22.0-1
ii  libc62.24-8
ii  libcairo21.14.8-1
ii  libdbusmenu-glib412.10.2-1
ii  libfontconfig1   2.11.0-6.7
ii  libfreetype6 2.6.3-3+b1
ii  libgdk-pixbuf2.0-0   2.36.3-1
ii  libglib2.0-0 2.50.2-2
ii  libpango-1.0-0   1.40.3-3
ii  libpangocairo-1.0-0  1.40.3-3
ii  libpangoft2-1.0-01.40.3-3
ii  multiarch-support2.24-8

libdbusmenu-gtk4 recommends no packages.

libdbusmenu-gtk4 suggests no packages.

-- no debconf information

Bug#850768: amule-daemon fails on startup (same as #840496)

[David Garabana Barro]

Package: amule-daemon
Version: 1:2.3.2-1+b2
Severity: important
Tags: l10n

Dear Maintainer,

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

   * What led up to the situation?
After upgrading amule-daemon, it stopped starting
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
Deleting ~/.aMule/shareddir.dat made amule-daemon start again. Further 
investigation showed that problem arises when you share a directory using non 
english 
characters.
For example, accented vowels (á, é, Ó...)
   * What was the outcome of this action?
Unsharing directories with non english characters made it start again. 
Once you share a single non english name, it crash again on start.
   * What outcome did you expect instead?
Update shouldn't break amule-daemon internationalization

I'm pretty sure that this bug is the very same as #840496.

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


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

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

Versions of packages amule-daemon depends on:
ii  amule-common   1:2.3.2-1
ii  libboost-system1.62.0  1.62.0+dfsg-4
ii  libc6  2.24-8
ii  libcrypto++6   5.6.4-6
ii  libgcc11:6.2.1-5
ii  libpng16-161.6.26-6
ii  libreadline7   7.0-1
ii  libstdc++6 6.2.1-5
ii  libupnp6   1:1.6.19+git20160116-1.2
ii  libwxbase3.0-0v5   3.0.2+dfsg-2
ii  zlib1g 1:1.2.8.dfsg-4

Versions of packages amule-daemon recommends:
ii  amule-utils  1:2.3.2-1+b2
ii  unzip6.0-21

amule-daemon suggests no packages.

-- Configuration Files:
/etc/default/amule-daemon changed:
AMULED_USER="amuled"
AMULED_HOME="/srv/Descargas"
AMULED_UMASK=0002


-- no debconf information

Bug#850763: Option for build directory is needed

[Iain R. Learmonth]

On Tue, 10 Jan 2017 01:00:36 +0100 Alf Gaida  wrote:
> a option for a build directory is needed - right now live-wrapper try to 
> build in /tmp/$foo and fail
> because standard options for /tmp are 
> Options=mode=1777,strictatime,nosuid,nodev
> 
> One should not be forced to touch these settings because of security concerns.

Just going to bed now, but will look in the next few days.

Temporary directories are created using Python's tempfile functions:

"The default directory is chosen from a platform-dependent list, but the
user of the application can control the directory location by setting the
TMPDIR, TEMP or TMP environment variables."

Can you try setting those environment variables and let me know if it works?
If it does then this is just a docfix.

Thanks,
Iain.

Bug#850767: r-bioc-phyloseq: unsatisfiable Depends: r-cran-ade4 (>= 1.7.4)

[Andreas Beckmann]

Package: r-bioc-phyloseq
Version: 1.19.1-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to install due
to unsatisfiably dependency.

sid has r-cran-ade4 1.7-5-1 and stretch has 1.7-4-1
=> possily punctuation typo


Andreas

Bug#850766: ceph FTBFS on 32-bit architectures. xfs related error

[peter green]

Package: ceph
Severity: serious
Version: 10.2.5-4

ceph failed to build on all 32-bit architectures. The following error messages 
are taken from the i386 log, armel looked similar, I haven't checked the others.

configure:23432: checking xfs/xfs.h usability
configure:23432: g++ -c -g -O2 -fdebug-prefix-map=/«PKGBUILDDIR»=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
-D_FORTIFY_SOURCE=2 conftest.cpp >&5
In file included from conftest.cpp:81:0:
/usr/include/xfs/xfs.h:53:48: error: size of array 'xfs_assert_largefile' is 
too large
 extern int xfs_assert_largefile[sizeof(off_t)-8];
^
configure:23432: $? = 1
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME "ceph"
| #define PACKAGE_TARNAME "ceph"
| #define PACKAGE_VERSION "10.2.5"
| #define PACKAGE_STRING "ceph 10.2.5"
| #define PACKAGE_BUGREPORT "ceph-de...@vger.kernel.org"
| #define PACKAGE_URL ""
| #define STDC_HEADERS 1
| #define HAVE_SYS_TYPES_H 1
| #define HAVE_SYS_STAT_H 1
| #define HAVE_STDLIB_H 1
| #define HAVE_STRING_H 1
| #define HAVE_MEMORY_H 1
| #define HAVE_STRINGS_H 1
| #define HAVE_INTTYPES_H 1
| #define HAVE_STDINT_H 1
| #define HAVE_UNISTD_H 1
| #define HAVE_DLFCN_H 1
| #define LT_OBJDIR ".libs/"
| #define PACKAGE "ceph"
| #define VERSION "10.2.5"
| #define HAVE_STATIC_CAST /**/
| #define HAVE_FUNC /**/
| #define HAVE_PRETTY_FUNC /**/
| #define HAVE_PTHREAD 1
| #define HAVE_RES_NQUERY 1
| #define HAVE_SYNCFS 1
| #define HAVE_SYS_SYNCFS 1
| #define USE_NSS 1
| #define DEBUG_GATHER 1
| #define WITH_RADOSGW 1
| #define HAVE_CURL_MULTI_WAIT 1
| #define HAVE_LIBFUSE 1
| #define HAVE_LIBTCMALLOC 1
| #define HAVE_GPERFTOOLS_HEAP_PROFILER_H 1
| #define HAVE_GPERFTOOLS_MALLOC_EXTENSION_H 1
| #define HAVE_GPERFTOOLS_PROFILER_H 1
| #define SIZEOF_AO_T 4
| #define HAVE_LEVELDB_FILTER_POLICY 1
| #define HAVE_SSE /**/
| #define HAVE_SSE2 /**/
| #define HAVE_SSE3 /**/
| #define HAVE_SSSE3 /**/
| #define HAVE_CXX11 1
| #define HAVE_LIBROCKSDB 1
| #define HAVE_LIBAIO 1
| /* end confdefs.h.  */
| #include 
| #ifdef HAVE_SYS_TYPES_H
| # include 
| #endif
| #ifdef HAVE_SYS_STAT_H
| # include 
| #endif
| #ifdef STDC_HEADERS
| # include 
| # include 
| #else
| # ifdef HAVE_STDLIB_H
| #  include 
| # endif
| #endif
| #ifdef HAVE_STRING_H
| # if !defined STDC_HEADERS && defined HAVE_MEMORY_H
| #  include 
| # endif
| # include 
| #endif
| #ifdef HAVE_STRINGS_H
| # include 
| #endif
| #ifdef HAVE_INTTYPES_H
| # include 
| #endif
| #ifdef HAVE_STDINT_H
| # include 
| #endif
| #ifdef HAVE_UNISTD_H
| # include 
| #endif
| #include 
configure:23432: result: no
configure:23432: checking xfs/xfs.h presence
configure:23432: g++ -E -Wdate-time -D_FORTIFY_SOURCE=2 conftest.cpp
configure:23432: $? = 0
configure:23432: result: yes
configure:23432: WARNING: xfs/xfs.h: present but cannot be compiled
configure:23432: WARNING: xfs/xfs.h: check for missing prerequisite headers?
configure:23432: WARNING: xfs/xfs.h: see the Autoconf documentation
configure:23432: WARNING: xfs/xfs.h: section "Present But Cannot Be 
Compiled"
configure:23432: WARNING: xfs/xfs.h: proceeding with the compiler's result
configure:23432: checking for xfs/xfs.h
configure:23432: result: no
configure:23436: error: xfs/xfs.h not found (--without-libxfs to disable)

Looks like some kind of error related to xfs and large file support.

The package also failed to build on s390x for unrelated reasons.

Bug#850764: zoph: fails to remove: post-removal script returned error exit status 30

[Andreas Beckmann]

Package: zoph
Version: 0.9.4-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to remove.

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

  Removing zoph (0.9.4-1) ...
  Conf zoph disabled.
  To activate the new configuration, you need to run:
service apache2 reload
  dpkg: error processing package zoph (--remove):
   subprocess installed post-removal script returned error exit status 30


This looks like a debconf question not being asked in noninteractive mode.


cheers,

Andreas


zoph_0.9.4-1.log.gz
Description: application/gzip

Bug#850670: RFS: rpyc/3.3.0-1 [ITP]

[Carl Suster]

It's only because mentors doesn't support version=4.


That's right - I tested the watch files for all of my packages and they work 
fine locally.


For rpyc I chose GitHub rather than PyPI as the upstream tarball source since 
the former includes the tests and such, however there was a disagreement over 
the spelling of the version number for the current release. PyPI has 3.3.0 but 
GitHub has 3.3 - I added a uversionmange to turn version X.Y into X.Y.0 to 
normalise this since they normally use three components in the version string:


opts="filenamemangle=s/.+\/v?(\d\S*)\.tar\.gz/rpyc-$1\.tar\.gz/, \
uversionmangle=s/-[rR][cC]/~rc/; s/(^\d+\.\d+)([^.]*$)/$1.0$2/" \
  https://github.com/tomerfiliba/rpyc/releases .*/v?(\d\S*)\.tar\.gz debian 
uupdate


So the automatic d/watch template won't really work for this package anyway.

Cheers,
Carl

Bug#850756: cryptsetup: Please save password to kernel keyring

[Laurent Bigonville]

On Mon, 09 Jan 2017 23:58:11 +0100 Laurent Bigonville  
wrote:

> Hi,
>
> Since gdm 3.22, there is a new pam module that unlock the gnome-keyring
> using the keyring using the password of the luks partition.
>
> The idea is that on a single user laptop, the user uses the same
> password for his encrypted root and user in addition to autologin.
>
> Tje pam module read the kernel keyring to find that password with the
> followin code:
>
> serial = find_key_by_type_and_desc ("user", "cryptsetup", 0);
> if (serial == 0)
> return PAM_AUTHINFO_UNAVAIL;
>
> r = keyctl_read_alloc (serial, _password);
>
> So it would be nice if cryptsetup could store that password in the
> keyring after opening successfully the main luks partition.

Looking at systemd, I see that they are doing something similar:

serial = add_key("user", keyname, p, n, KEY_SPEC_USER_KEYRING);

with keyname="cryptsetup"

I see two options here, either debian/askpass.c is modified to either 
call add_key() function directly or "--keyname=cryptsetup" is passed to 
systemd-ask-password.


Or the keyctl command line is used with something like: keyctl add user 
cryptsetup my_password @u

Bug#850765: util-vserver: fails to remove: postrm called with unknown argument `remove'

[Andreas Beckmann]

Package: util-vserver
Version: 0.30.216-pre3120-1.3
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to remove.

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

  Removing util-vserver (0.30.216-pre3120-1.3) ...
  can not change context: migrate kernel feature missing and 'compat' API 
disabled: Function not implemented
  invoke-rc.d: could not determine current runlevel
  invoke-rc.d: policy-rc.d denied execution of stop.
  postrm called with unknown argument `remove'
  dpkg: error processing package util-vserver (--remove):
   subprocess installed post-removal script returned error exit status 1


cheers,

Andreas


util-vserver_0.30.216-pre3120-1.3.log.gz
Description: application/gzip

Bug#850762: setserial: missing dependency on lsb-base

[Andreas Beckmann]

Package: setserial
Version: 2.17-49.1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package failed to install. As
per definition of the release team this makes the package too buggy for
a release, thus the severity.

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

  Selecting previously unselected package setserial.
  (Reading database ... 
(Reading database ... 4394 files and directories currently installed.)
  Preparing to unpack .../setserial_2.17-49.1_amd64.deb ...
  Unpacking setserial (2.17-49.1) ...
  Setting up setserial (2.17-49.1) ...
  removing the old setserial entry in the rcn.d directories
  Update complete.
  update-rc.d: warning: start and stop actions are no longer supported; falling 
back to defaults
  update-rc.d: warning: start and stop actions are no longer supported; falling 
back to defaults
  update-rc.d: warning: start and stop actions are no longer supported; falling 
back to defaults
  update-rc.d: warning: start and stop actions are no longer supported; falling 
back to defaults
  /etc/init.d/setserial: 35: .: Can't open /lib/lsb/init-functions
  dpkg: error processing package setserial (--configure):
   subprocess installed post-installation script returned error exit status 2
  Errors were encountered while processing:
   setserial


cheers,

Andreas


setserial_2.17-49.1.log.gz
Description: application/gzip

Bug#849013: rewrite nvidia-detect

[Taylor Kline]

umm disregard my accidentally sent email that clearly shows I am just
learning how to use the mailing list.

I didn't do an extensive code review but it did detect my Optimus setup:

Find the NVIDIA driver version for Debian Stretch.
Checking PCI ID: 8086191b is not a valid NVIDIA device ID. Ignoring this PCI ID.
Checking PCI ID: 10de139b Found: GM107M [GeForce GTX 960M]

WARNING! This looks like a NVIDIA Optimus GPU,
maybe you prefeer a Bumblebee setup, or try
the experimental NVIDIA Prime support in 370 >

Your GPU(s) are supported by Nvidia driver version(s):
375xx
It is recommanded to install the following Debian package:
nvidia-driver

On Mon, Jan 9, 2017 at 3:52 PM, Floris  wrote:
> I made a rewrite of the nvidia-detect script.
>
> - The script is compatible with sh, bash and dash.
> - It is easy to add or remove supported Debian and NVIDIA versions.
> - Use the -d switch to mimic a Debian version.
> - support for multiple NVIDIA GPUs (or as PCI-ID on the command line)
> - No new dependencies, only pciutils
> - Try to detect NVIDIA Optimus (Unfortunately I doesn't have a device to
> test this)
>
> I'm only scripting as a hobby, so feel free to correct and teach me new
> things!
>
> Floris

Bug#850763: Option for build directory is needed

[Alf Gaida]

Package: live-wrapper
Version: 0.5
Severity: important

Dear maintainer,

a option for a build directory is needed - right now live-wrapper try to build 
in /tmp/$foo and fail
because standard options for /tmp are Options=mode=1777,strictatime,nosuid,nodev

One should not be forced to touch these settings because of security concerns.

Cheers Alf

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

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

Versions of packages live-wrapper depends on:
ii  debian-archive-keyring  2014.3
ii  isolinux3:6.03+dfsg-14
ii  python-apt  1.4.0~beta1
ii  python-cliapp   1.20160724-1
ii  python-requests 2.12.4-1
pn  python:any  
ii  vmdebootstrap   1.7-1
ii  xorriso 1.4.6-1+b1

live-wrapper recommends no packages.

Versions of packages live-wrapper suggests:
ii  cmdtest  0.27-1

-- no debconf information

Bug#850743: patch

[grin]

The fix is hopefully at
https://github.com/balabit/syslog-ng/pull/1316

g

Bug#850761: autolog: installation unconditionally starts autolog service

[Andreas Beckmann]

Package: autolog
Version: 0.40+debian-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package left processes
running after the package has been removed and/or purged.

In https://lists.debian.org/debian-devel/2009/08/msg00182.html and
followups it has been agreed that these bugs are to be filed with
severity serious.

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

0m20.6s ERROR: FAIL: Processes are running inside chroot:
  COMMAND  PID USER   FD   TYPE DEVICE SIZE/OFF   NODE NAME
  autolog 5592 root  cwdDIR   0,21  460 2528598545 
/tmp/piupartss/tmpYsXRo9
  autolog 5592 root  rtdDIR   0,21  460 2528598545 
/tmp/piupartss/tmpYsXRo9
  autolog 5592 root  memREG   0,21  1685264 2528649320 
/tmp/piupartss/tmpYsXRo9/lib/x86_64-linux-gnu/libc-2.24.so
  autolog 5592 root  memREG   0,21   149192 2528649324 
/tmp/piupartss/tmpYsXRo9/lib/x86_64-linux-gnu/ld-2.24.so
  autolog 5592 root4r   REG   0,210 2528598641 
/tmp/piupartss/tmpYsXRo9/run/utmp


cheers,


Andreas


autolog_0.40+debian-1.log.gz
Description: application/gzip

Bug#850760: nixstatsagent: modifies conffiles (policy 10.7.3): /etc/nixstats.ini

[Andreas Beckmann]

Package: nixstatsagent
Version: 1.1.2-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package modifies conffiles.
This is forbidden by the policy, see
https://www.debian.org/doc/debian-policy/ch-files.html#s-config-files

10.7.3: "[...] The easy way to achieve this behavior is to make the
configuration file a conffile. [...] This implies that the default
version will be part of the package distribution, and must not be
modified by the maintainer scripts during installation (or at any
other time)."

Note that once a package ships a modified version of that conffile,
dpkg will prompt the user for an action how to handle the upgrade of
this modified conffile (that was not modified by the user).

Further in 10.7.3: "[...] must not ask unnecessary questions
(particularly during upgrades) [...]"

If a configuration file is customized by a maintainer script after
having asked some debconf questions, it may not be marked as a
conffile. Instead a template could be installed in /usr/share and used
by the postinst script to fill in the custom values and create (or
update) the configuration file (preserving any user modifications!).
This file must be removed during postrm purge.
ucf(1) may help with these tasks.
See also https://wiki.debian.org/DpkgConffileHandling

In https://lists.debian.org/debian-devel/2012/09/msg00412.html and
followups it has been agreed that these bugs are to be filed with
severity serious.

debsums reports modification of the following files,
from the attached log (scroll to the bottom...):

  /etc/nixstats.ini


cheers,

Andreas


nixstatsagent_1.1.2-1.log.gz
Description: application/gzip

Bug#850601: desktop-base does not install on live images

[Alf Gaida]

Thanks a lot, works like charm, tested with lxqt, kde, gnome

Bug#815428: Update mathwar

[Alexey Loginov]

Mathwar was deleted from repo, but will you build it again because of
new version is available?

Bug#850759: FAILED to read or write files

[積丹尼 Dan Jacobson]

Package: apt
Version: 1.4~beta2
Severity: wishlist

Just wanted to note I saw some "FAILED to read or write files" messages,

# apt-get update
...
Get:22 http://free.nchc.org.tw/debian experimental/contrib Translation-en 
2016-12-23-1428.25.pdiff [489 B]
Get:18 http://free.nchc.org.tw/debian experimental/main Translation-en 
2017-01-09-1428.39.pdiff [2072 B]
Get:23 http://free.nchc.org.tw/debian experimental/contrib Translation-en 
2016-12-25-1427.59.pdiff [29 B]
Get:24 http://free.nchc.org.tw/debian experimental/contrib Translation-en 
2017-01-09-1428.39.pdiff [452 B]
Get:25 http://free.nchc.org.tw/debian unstable/main amd64 Packages 
2017-01-09-0238.23.pdiff [13.5 kB]
Get:26 http://free.nchc.org.tw/debian unstable/main amd64 Packages 
2017-01-09-0828.36.pdiff [7831 B]
Get:27 http://free.nchc.org.tw/debian unstable/main amd64 Packages 
2017-01-09-1428.39.pdiff [12.3 kB]
Get:21 http://free.nchc.org.tw/debian experimental/contrib amd64 Packages 
2017-01-09-1428.39.pdiff [431 B]
FAILED to read or write files
Ign:15 http://free.nchc.org.tw/debian experimental/main amd64 Packages 
2017-01-09-1428.39.pdiff
Get:24 http://free.nchc.org.tw/debian experimental/contrib Translation-en 
2017-01-09-1428.39.pdiff [452 B]
FAILED to read or write files
Ign:21 http://free.nchc.org.tw/debian experimental/contrib amd64 Packages 
2017-01-09-1428.39.pdiff
Get:27 http://free.nchc.org.tw/debian unstable/main amd64 Packages 
2017-01-09-1428.39.pdiff [12.3 kB]
Get:28 http://free.nchc.org.tw/debian unstable/main Translation-en 
2017-01-09-0238.23.pdiff [286 B]
Get:29 http://free.nchc.org.tw/debian unstable/main Translation-en 
2017-01-09-1428.39.pdiff [1121 B]
Get:30 http://free.nchc.org.tw/debian unstable/non-free amd64 Packages 
2017-01-09-1428.39.pdiff [202 B]
Get:29 http://free.nchc.org.tw/debian unstable/main Translation-en 
2017-01-09-1428.39.pdiff [1121 B]
Get:31 http://free.nchc.org.tw/debian experimental/main amd64 Packages [309 kB]
Get:32 http://free.nchc.org.tw/debian experimental/contrib amd64 Packages [1840 
B]
FAILED to read or write files
Ign:27 http://free.nchc.org.tw/debian unstable/main amd64 Packages 
2017-01-09-1428.39.pdiff
Get:30 http://free.nchc.org.tw/debian unstable/non-free amd64 Packages 
2017-01-09-1428.39.pdiff [202 B]
FAILED to read or write files
Ign:30 http://free.nchc.org.tw/debian unstable/non-free amd64 Packages 
2017-01-09-1428.39.pdiff
Get:33 http://free.nchc.org.tw/debian unstable/main amd64 Packages [7405 kB]
Get:34 http://free.nchc.org.tw/debian unstable/non-free amd64 Packages [82.6 kB]
Fetched 8370 kB in 44s (188 kB/s)
Reading package lists...
# echo $?
0

And there was nothing in journalctl odd. Disks mounted all OK. Nor did a
subsequent apt-get update show anything bad.

Bug#818821: Fixes for xview build failures on stretch

[Andreas Beckmann]

Control: tag -1 pending

On Thu, 8 Dec 2016 18:25:31 -0500 Benjamin Moody  
wrote:
> Here are patches to fix these issues.

Thanks.


I just uploaded a NMU fixing these and a few more issues to DELAYED/2,
which should keep the package in stretch.

 xview (3.2p1.4-28.2) unstable; urgency=medium
 .
   * Non-maintainer upload.
   * Switch B-D from flex to libfl-dev.
   * Fix several FTBFS issues, thanks to Benjamin Moody.  (Closes: #818821)
   * Fix crash under systemd (_SC_OPEN_MAX > FD_SETSIZE), thanks to
 Benjamin Moody.  (Closes: #784918)
   * Make packages arch:any.  (Closes: #791974)


Andreas

Bug#850708: [pkg-gnupg-maint] Bug#850708: gpg: decryption failed: No secret key

[Daniel Kahn Gillmor]

Control: tags 850708 + moreinfo unreproducible

Hi Vincent--

On Mon 2017-01-09 10:02:20 -0500, Vincent Lefevre wrote:
> Since the latest upgrade:
>
> * When I open a .gpg file with Emacs:
>
> * With "gpg -d note.gpg", same errors:
>
> gpg: AES encrypted data
> gpg: cancelled by user
> gpg: encrypted with 1 passphrase
> gpg: decryption failed: No secret key
>
> The errors are immediate and 100% reproducible.

is this with a symmetrically-encrypted file, or with a file that is
encrypted with a public key?

I'm unable to reproduce this problem.

what pinentry are you using?  how is your pinentry launched or managed?

what happens if you do:

gpg-connect-agent 'get_passphrase cacheval123 errorrmsg leadprompt 
description' /bye

this *should* throw up a password prompt in your graphical display.

you can clear the same cached passphrase with:

gpg-connect-agent 'clear_passphrase cacheval123' /bye


--dkg


signature.asc
Description: PGP signature

Bug#850657: [pkg-gnupg-maint] Bug#850657: gnupg: Please find gpg-agent on PATH

[Daniel Kahn Gillmor]

Control: tags 850657 + moreinfo
Control: severity 850657 wishlist

On Sun 2017-01-08 17:35:13 -0500, Ian Jackson wrote:
> gpg executes /usr/bin/gpg-agent, rather than fetching it from the
> PATH.
>
> This is contrary to Debian policy.

Can you point to the specific part of debian policy that this violates?

> (This behaviour got in my way because I wanted to pass exciting
> options to gpg-agent, which involved contortions.)

If you want to pass exciting options to gpg-agent, you can pass them
directly by launching the agent by hand.  there aren't many contortions
involved, afaict.  Can you explain what you're trying to do?

> Please change the package to execute all its programs from PATH.

this almost certainly won't be done.  for example, if a smarcard is
present, scdaemon is currently invoked from /usr/lib/gnupg/scdaemon ,
which isn't even in the path.

> Ideally upstream would change too but my experience is that upstreams
> often don't like this kind of change.

indeed, they don't like changes that make it more difficult to track
down problems, and knowing that the binary you're executing is the one
that was built with the one that you're running isn't a totally
unreasonable expectation.

There are lots of systems where users install some who-knows-what
variant of gpg in /usr/local, and it's entirely reasonable for
/usr/local/bin/gpg to want to execute /usr/local/bin/gpg-agent, while
/usr/bin/gpg might want to execute /usr/bin/gpg-agent.  (this kind of
approach would indeed raise a concern for future use of gpg once the
agent is running of course, but that's a separate issue, and one not
fixed by relying on $PATH either)

Can you explain more about why you need this?  I'm happy to help you
figure out what you want in general, but the argument for this change in
the moment seems pretty abstract.

--dkg


signature.asc
Description: PGP signature

Bug#850758: diffoscope: redundant undecoded AndroidManifest.xml (Binary XML) comparison in APK comparator

[Emanuel Bronshtein]

Package: diffoscope
Version: 67
Severity: normal

Dear Maintainer,

The result of comparing AndroidManifest.xml (Binary XML) file from APK file in 
apk.py comparator is shown twice, 
first, as AndroidManifest.xml (XML file decoded from original file by apktool)
second, as original/AndroidManifest.xml (the original undecoded binary file)

fix:
1. if there is a difference in decoded AndroidManifest.xml file, remove 
the original/AndroidManifest.xml.
   if there is no difference in AndroidManifest.xml but 
original/AndroidManifest.xml differ, show "No file format specific differences 
found inside, yet data differs" message (which shown by diffoscope in similar 
scenarios [when tool failed to find differences])

2. it will be better to indicate the AndroidManifest.xml type, such as 
for example:
show AndroidManifest.xml  as "AndroidManifest.xml 
(decoded)"
show original/AndroidManifest.xml as "AndroidManifest.xml 
(original / undecoded)"

examples:

https://verification.f-droid.org/org.opengemara.shiurim_2.apk.diffoscope.html

https://verification.f-droid.org/org.systemcall.scores_2.apk.diffoscope.html

TXT result example:

├── AndroidManifest.xml
@@ -1,9 +1,9 @@
│  
│ -

Bug#848748: #848748: blockdiag FTBFS: caused by new wand?

[Rebecca N. Palmer]

Control: tags -1 patch

The failing tests are:

==
FAIL: blockdiag.tests.test_generate_diagram.test_generate(at 0x7f79a5528f28>, 'svg', 
'/tmp/buildd/blockdiag-1.5.3+dfsg/.pybuild/pythonX.Y_3.5/build/src/blockdiag/tests/diagrams/multiple_nodes_definition.diag', 
['-f', '/usr/share/fonts/truetype/vlgothic/VL-Gothic-Regular.ttf'])

--
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/nose/case.py", line 198, in runTest
self.test(*self.arg)
  File 
"/tmp/buildd/blockdiag-1.5.3+dfsg/.pybuild/pythonX.Y_3.5/build/src/blockdiag/tests/utils.py", 
line 68, in wrap

raise AssertionError('Caught error')
AssertionError: Caught error
 >> begin captured stdout << -
---[ stderr ] ---
Exception ignored in: >

Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/wand/resource.py", line 232, in 
__del__

self.destroy()
  File "/usr/lib/python3/dist-packages/wand/image.py", line 2767, in 
destroy

for i in range(0, len(self.sequence)):
TypeError: object of type 'NoneType' has no len()


- >> end captured stdout << --

==
FAIL: 
blockdiag.tests.test_generate_diagram.svg_includes_source_code_tag_test

--
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/nose/case.py", line 198, in runTest
self.test(*self.arg)
  File 
"/tmp/buildd/blockdiag-1.5.3+dfsg/.pybuild/pythonX.Y_3.5/build/src/blockdiag/tests/utils.py", 
line 68, in wrap

raise AssertionError('Caught error')
AssertionError: Caught error
 >> begin captured stdout << -
---[ stderr ] ---
Exception ignored in: >

Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/wand/resource.py", line 232, in 
__del__

self.destroy()
  File "/usr/lib/python3/dist-packages/wand/image.py", line 2767, in 
destroy

for i in range(0, len(self.sequence)):
TypeError: object of type 'NoneType' has no len()


- >> end captured stdout << --

--
Ran 710 tests in 2.926s

FAILED (SKIP=351, failures=2)

The reason they fail now and not before is probably the new version of 
wand: it added an Image.destroy() 
(https://sources.debian.net/src/wand/0.4.4-1/wand/image.py/#L2760) that 
iterates over self.sequence (the frames of an animation) to free their 
memory.  This throws an exception on single images (where 
self.sequence=None), but as this is called from __del__, this exception 
is warned about then ignored 
(https://docs.python.org/3/reference/datamodel.html#object.__del__), and 
hence is not an error in normal use.  (As it does pointlessly scare the 
user, I'd consider it a wand bug, but not an RC one.)


However, blockdiag tests that use capture_stderr fail on any output 
containing "Traceback", including this warning message.


This can be worked around in blockdiag or fixed at source in wand; I 
attach patches for both options (the blockdiag one builds, but that's 
all the testing I've done; the wand one hasn't been tested at all).


(See also https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=840823#19 , 
particularly if you choose the wand option)
Description: Fix test failure with wand 0.4.1+
 
wand 0.4.1 added an Image.destroy()
(https://sources.debian.net/src/wand/0.4.4-1/wand/image.py/#L2760) that
iterates over self.sequence (the frames of an animation) to free their
memory; this throws an exception on single images (where
self.sequence=None), but as this is called from __del__, this
exception is warned about then ignored
(https://docs.python.org/3/reference/datamodel.html#object.__del__),
and hence is not an error in normal use.

However, blockdiag tests that use capture_stderr fail on any output
containing "Traceback", including this warning message.

This patch ignores this message to allow blockdiag to build.

Author: Rebecca Palmer 
Bug-Debian: https://bugs.debian.org/848748
Forwarded: no

--- blockdiag-1.5.3+dfsg.orig/src/blockdiag/tests/utils.py
+++ blockdiag-1.5.3+dfsg/src/blockdiag/tests/utils.py
@@ -64,7 +64,14 @@ def capture_stderr(func):
 
 func(*args, **kwargs)
 
-if re.search('(ERROR|Traceback)', sys.stderr.getvalue()):
+filtered_stderr=re.sub(r"""Exception ignored in: >
+Traceback \(most recent call last\):
+  File "/usr/lib/python3/dist-packages/wand/resource\.py", line [0-9]+, in __del__
+self\.destroy\(\)
+  File "/usr/lib/python3/dist-packages/wand/image\.py", line [0-9]+, in destroy
+for i in range\(0, len\(self\.sequence\)\):
+TypeError: object of type 'NoneType' has no 

Bug#793770: Cookie parsing bug may lead to 'HttpOnly' cookie bypass (CVE-2015-2156)

[Emmanuel Bourg]

Le 9/01/2017 à 23:37, Moritz Muehlenhoff a écrit :

> This is unfixed with a patch for nearly 1.5 years, can we please get this
> fixed for the stretch release.

Hi Moritz,

Thank you for the reminder. The fix was backported in the version 3.9.7.
I'll update the package to the latest 3.9.x version.

Emmanuel Bourg

Bug#850757: RFS: mytop/1.9.1-4

[Werner Detter]

Package: sponsorship-requests
Severity: normal

Dear Mentors,

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

 * Package name: mytop
   Version : 1.9.1-4
   Upstream Author : Jeremy D. Zawodny ,
 Mark Grennan 
 * URL : http://www.mysqlfanboy.com/mytop-3/ 
 * License : GPL-2+ 
   Section : utils

It builds those binary packages:
mytop - top like query monitor for MySQL

To access further information about this package, please visit the following 
URL:
https://mentors.debian.net/package/mytop

Alternatively, one can download the package with dget using this command:
dget -x https://mentors.debian.net/debian/pool/main/m/mytop/mytop_1.9.1-4.dsc

More information about hello can be obtained from https://www.example.com.
Changes since the last upload:

  * Add 14_fix_deprecated_show_innodb_status.patch which replaces deprecated
command SHOW INNODB STATUS with SHOW ENGINE INNODB STATUS
  * Removed whitespaces in changelog
  * Update to debhelper 10

debdiff attached [1]

Thanks,
Werner Detter


[1]
werner@debian:~$ debdiff mytop_1.9.1-3.dsc mytop_1.9.1-4.dsc 
diff -Nru mytop-1.9.1/debian/changelog mytop-1.9.1/debian/changelog
--- mytop-1.9.1/debian/changelog2016-11-20 10:31:06.0 +0100
+++ mytop-1.9.1/debian/changelog2017-01-09 23:15:07.0 +0100
@@ -1,3 +1,12 @@
+mytop (1.9.1-4) unstable; urgency=low
+
+  * Add 14_fix_deprecated_show_innodb_status.patch which replaces deprecated
+command SHOW INNODB STATUS with SHOW ENGINE INNODB STATUS
+  * Removed whitespaces in changelog
+  * Update to debhelper 10
+
+ -- Werner Detter   Mon, 09 Jan 2017 23:15:07 +0100
+
 mytop (1.9.1-3) unstable; urgency=low
 
   * Updated 11_fix_url_manpage.patch for new upstream url
@@ -33,7 +42,7 @@
   * Updating standards version to 3.9.4
   * Switch to dpkg-source 3.0 (quilt) format 
 - Add debian/source/format
-  * Checked and recreated patchs from old upstream against new version. 
+  * Checked and recreated patchs from old upstream against new version.
 Recreated necessary patches against new upstream version.
 - Add 01_fix_pod.patch
 - Add 02_remove_db_test.patch
diff -Nru mytop-1.9.1/debian/compat mytop-1.9.1/debian/compat
--- mytop-1.9.1/debian/compat   2016-11-19 15:46:23.0 +0100
+++ mytop-1.9.1/debian/compat   2017-01-09 23:15:07.0 +0100
@@ -1 +1 @@
-9
+10
diff -Nru mytop-1.9.1/debian/control mytop-1.9.1/debian/control
--- mytop-1.9.1/debian/control  2016-11-19 15:46:23.0 +0100
+++ mytop-1.9.1/debian/control  2017-01-09 23:15:07.0 +0100
@@ -2,7 +2,7 @@
 Section: utils
 Priority: optional
 Maintainer: Werner Detter 
-Build-Depends: debhelper (>= 9)
+Build-Depends: debhelper (>= 10)
 Homepage: http://www.mysqlfanboy.com/mytop-3/
 Standards-Version: 3.9.8
 
diff -Nru mytop-1.9.1/debian/patches/14_fix_deprecated_show_innodb_status.patch 
mytop-1.9.1/debian/patches/14_fix_deprecated_show_innodb_status.patch
--- mytop-1.9.1/debian/patches/14_fix_deprecated_show_innodb_status.patch   
1970-01-01 01:00:00.0 +0100
+++ mytop-1.9.1/debian/patches/14_fix_deprecated_show_innodb_status.patch   
2017-01-09 23:15:07.0 +0100
@@ -0,0 +1,14 @@
+Description: replace deprecated SHOW INNODB STATUS command
+Author: Werner Detter 
+DEP: 3
+--- a/mytop
 b/mytop
+@@ -1326,7 +1326,7 @@ sub GetInnoDBStatus()
+ }
+ }
+ 
+-my @data = Hashes("SHOW INNODB STATUS");
++my @data = Hashes("SHOW ENGINE INNODB STATUS");
+ 
+ open P, "|$config{pager}" or die "$!";
+ print keys %{$data[0]};
diff -Nru mytop-1.9.1/debian/patches/series mytop-1.9.1/debian/patches/series
--- mytop-1.9.1/debian/patches/series   2016-11-19 15:46:23.0 +0100
+++ mytop-1.9.1/debian/patches/series   2017-01-09 23:15:07.0 +0100
@@ -11,3 +11,4 @@
 11_fix_url_manpage.patch
 12_fix_spelling_and_allignment.patch
 13_fix_scope_for_show_slave_status_data.patch
+14_fix_deprecated_show_innodb_status.patch


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

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

Bug#850756: cryptsetup: Please save password to kernel keyring

[Laurent Bigonville]

Package: cryptsetup
Version: 2:1.7.3-3
Severity: wishlist

Hi,

Since gdm 3.22, there is a new pam module that unlock the gnome-keyring
using the keyring using the password of the luks partition.

The idea is that on a single user laptop, the user uses the same
password for his encrypted root and user in addition to autologin.

Tje pam module read the kernel keyring to find that password with the
followin code:

serial = find_key_by_type_and_desc ("user", "cryptsetup", 0);
if (serial == 0)
return PAM_AUTHINFO_UNAVAIL;

r = keyctl_read_alloc (serial, _password);

So it would be nice if cryptsetup could store that password in the
keyring after opening successfully the main luks partition.

Regards,

Laurent Bigonville

-- Package-specific info:

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

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

Versions of packages cryptsetup depends on:
ii  cryptsetup-bin 2:1.7.3-3
ii  debconf [debconf-2.0]  1.5.59
ii  dmsetup2:1.02.137-1
ii  libc6  2.24-8

Versions of packages cryptsetup recommends:
ii  busybox 1:1.22.0-19+b1
ii  console-setup   1.156
ii  initramfs-tools [linux-initramfs-tool]  0.126
ii  kbd 2.0.3-2

Versions of packages cryptsetup suggests:
ii  dosfstools  4.0-2
ii  keyutils1.5.9-9
ii  liblocale-gettext-perl  1.07-3+b1

-- debconf information excluded

Bug#847843: Debian bug #847843

[Jörg Frings-Fürst]

Hello Mike,
hello Daniel,

Am Montag, den 09.01.2017, 15:49 + schrieb Mike Gabriel:
> Hi Daniel, hi Jrg.
> 
> On  Mi 04 Jan 2017 14:59:28 CET, Daniel E. Markle wrote:
> 
> > No idea what the orphan report is talking about r.e. my e-mail's  
> > 'bouncing' as
> > I'm certainly getting these. I was out for the holidays however.
> > 
> > I certainly support the idea of team maintenance if debian-edu-pkg-team 
> > wants
> > to take it.
> > 
> > The latest upstream should be packaged instead though, 4.2.4a has a lot of
> > bugfixes and parameter file updates.
> 
> So what is the best way of continuing now? For now, I'd say let's ask  
> Jrg to finalize the upload, leave you as a maintainer and have Jrg  
> and me as uploaders.
> 

I think thats the best way.


> We also need to get you Daniel access to the Git repo that Jrg put together.
> 
> Does everyone agree? Comments? Feedback? Jrg, will you be able to  
> upload within the next 2 weeks?

It was uploaded 5 days ago. Because of the split into 2 packages
xtrkcad is still in the New-Queue.

> 
> Thanks + Greets,
> Mike

CU
Jörg

PS.: I get always: The reported error was "RCPT TO dmar...@ashtech.net>
gescheitert:: Recipient address rejected: Domain
not found".

Jörg
-- 
New:
GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB  30EE 09F8 9F3C 8CA1 D25D
GPG key (long) : 09F89F3C8CA1D25D
GPG Key: 8CA1D25D
CAcert Key S/N : 0E:D4:56

Old pgp Key: BE581B6E (revoked since 2014-12-31).

Jörg Frings-Fürst
D-54470 Lieser

Threema: SYR8SJXB

IRC: j_...@freenode.net
 j_...@oftc.net

My wish list: 
 - Please send me a picture from the nature at your home.


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

Bug#793770: Cookie parsing bug may lead to 'HttpOnly' cookie bypass (CVE-2015-2156)

[Moritz Muehlenhoff]

severity 793770 grave
thanks

On Mon, Jul 27, 2015 at 11:51:53AM +0200, Luca Bruno wrote:
> Source: netty-3.9
> Version: 3.9.0.Final-1
> Severity: important
> Tags: security upstream patch
> 
> LinkedIn Security Team discovered a "Cookie" header parsing bug in Netty
> that could lead to universal bypass of the HttpOnly flag on cookies.
> 
> If the HttpOnly flag is included in the HTTP Set-Cookie response header,
> the cookie cannot usually be accessed through client-side script.
> This bug can be however leveraged to leak the cookie's name-value in the DOM,
> where a malicious script can access the content without any restriction.
> 
> CVE-2015-2156 has been assigned for this issue, which has been fixed upstream
> in release 3.9.8.Final and 3.10.3.Final.
> Please mention the CVE ID in the changelog when fixing this issue.
> 
> References:
>  * Security update
>http://netty.io/news/2015/05/08/3-9-8-Final-and-3.html
>  * Issue technical details / PoC
>
> http://engineering.linkedin.com/security/look-netty%E2%80%99s-recent-security-update-cve%C2%AD-2015%C2%AD-2156
>  * Fixing commit
>
> https://github.com/slandelle/netty/commit/800555417e77029dcf8a31d7de44f27b5a8f79b8

This is unfixed with a patch for nearly 1.5 years, can we please get this
fixed for the stretch release.

Cheers,
Moritz

Bug#850755: RM: nagios3/3.5.1.dfsg-2.2

[Moritz Muehlenhoff]

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

nagios3 was removed from unstable, but for some reason is still in testing,
please remove it from there as well.

Cheers,
Moritz

Bug#850590: ITP: openmeca -- a graphical application to model and simulate mechanical systems

[dada]

Hello Andreas,
Good ! It's a great news ! :)

You will find at http://yakuru.fr/~dada/omc-deb/ a first version of the 
debian package of openmeca.
(Note that I build this package on Ubuntu 16.04.1 LTS without gpg 
signature)


This is the first time for me, please tell me what's wrong.

Thank you very much, Damien.


Le 2017-01-09 10:04, Andreas Tille a écrit :

Hi Damien,

I think this package fits nicely into the Debian Science team and 
might

be useful in more than one of its tasks[1].

Kind regards

  Andreas.

[1] https://blends.debian.org/science/tasks/

On Sun, Jan 08, 2017 at 10:00:45AM +0100, Damien Andre wrote:

Package: wnpp
Severity: wishlist
Owner: Damien Andre 

* Package name: openmeca
  Version : 2.1.2
  Upstream Author : Damien Andre 
* URL : https://gitlab.com/damien.andre/openmeca
* License : GPL v3
  Programming Lang: C++
  Description : a graphical application to model and simulate 
mechanical systems


OpenMeca is based on the chronoengine library. The aim of openmeca 
is to provide a software for simulating mechanical systems easily. 
openmeca allow us to builds a 3D sketch, where the bonds are 
represented by symbols and gives a simple way to apply loading and 
boundary conditions. Thanks to numerical sensors, different kind of 
data (force, torque, displacement, velocity, etc.) could be extracted 
from the simulation.


Hello, I am developing the openmeca software. openmeca is a 
scientific software especially designed for teaching mechanical 
dynamics. I started this development a long time ago (8 years) and I 
think that the program is correct now.


I propose to work myself on the packaging. By following the FAQ 
instructions, I just made a first version of the source and binary 
package. However, I probably need help from debian mentors to improve 
the quality of the package.


Best regards, Damien.

Bug#850754: RM: moodle/2.7.17+dfsg-1

[Moritz Muehlenhoff]

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

Please remove moodle from testing, it was reintroduced by the recennt BTS
hiccup and was meant to kept out.

Bug#751902: bug 751902

[Moritz Muehlenhoff]

On Sat, Jun 21, 2014 at 09:41:06AM +1000, Alexander Zangerl wrote:
> retitle 751902 "duplicity should enable boto's certificate verification 
> option"
> severity 751902 normal
> forwarded 751902 https://bugs.launchpad.net/duplicity/+bug/1314234
> thanks
> 
> i'm downgrading this bug to normal severity, as the issue affects only one
> (of about a dozen) different storage backends in duplicity (actually the only 
> purely commercial backend).

Given that this is unfixed upstream for years, let's exclude the backend from
the Debian binary package?

Cheers,
Moritz

Bug#537866: system-wide PKCS#11 modules

[Timo Aaltonen]

Hi, just FYI that FreeIPA doesn't need this anymore (uses a private db
instead), so I have no need for it either.

thanks

Bug#850753: fresh upstream (and ubuntu) is available (1.12.3)

[Yaroslav Halchenko]

Package: docker.io
Version: 1.11.2~ds1-6
Severity: wishlist

$> whohas -d Debian,Ubuntu docker.io   
Ubuntu  docker.io0.9.1~dfsg1-2
http://packages.ubuntu.com/trusty/docker.io
Ubuntu  docker.io1.6.2~dfsg1-1ubunt   
http://packages.ubuntu.com/trusty-updates/docker.io
Ubuntu  docker.io1.10.3-0ubuntu6  
http://packages.ubuntu.com/xenial/docker.io
Ubuntu  docker.io1.12.1-0ubuntu13~1   
http://packages.ubuntu.com/xenial-updates/docker.io
Ubuntu  docker.io1.12.1-0ubuntu15 
http://packages.ubuntu.com/yakkety/docker.io
Ubuntu  docker.io1.12.3-0ubuntu4  
http://packages.ubuntu.com/zesty/docker.io
Debian  docker.io1.6.2~dfsg1-1~bpo8   
http://packages.debian.org/jessie-backports/docker.io
Debian  docker.io1.11.2~ds1-6 
http://packages.debian.org/sid/docker.io


and 1.13.0 seems to be right on the way according to rc's on
https://github.com/docker/docker/releases

I wonder if that would be a better choice for stretch release than
current one we have

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

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

Versions of packages docker.io depends on:
ii  adduser  3.115
ii  containerd   0.2.1~ds1-3
ii  init-system-helpers  1.46
ii  iptables 1.6.0+snapshot20161117-4
ii  libapparmor1 2.10.95-8
ii  libc62.24-8
ii  libdevmapper1.02.1   2:1.02.137-1
ii  libsqlite3-0 3.15.2-2
ii  libsystemd0  232-8
ii  runc 0.1.1+dfsg1-1

Versions of packages docker.io recommends:
ii  ca-certificates  20161130
ii  cgroupfs-mount   1.3
ii  git  1:2.11.0-1
ii  xz-utils 5.2.2-1.2

Versions of packages docker.io suggests:
ii  aufs-tools   1:4.1+20161010-1
ii  btrfs-progs  4.7.3-1
ii  debootstrap  1.0.87
pn  docker-doc   
pn  rinse
pn  zfs-fuse | zfsutils  

-- no debconf information

Bug#850749: gcc-6: Please enable gccgo on m68k

[John Paul Adrian Glaubitz]

On 01/09/2017 10:54 PM, Matthias Klose wrote:
> Do you have test results for a build?

I did not run the testsuite, if that's what you are asking and it
seems that there are some issues that need to be resolved first.

However, I would like to have gccgo enabled to be able to easily
install it and work on fixing the issues.

Adrian

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

Bug#850752: syslog-summary: Ignore logic invalid when multiple lines should be ignored

[Olivier Mehani]

Package: syslog-summary
Version: 1.14-2.1
Severity: important
Tags: patch upstream

Dear Maintainer,

   * What led up to the situation?

** syslog file containing multiple INFO lines following each
other
** ignore pattern to block INFO lines in
/etc/syslog-summary/ignore.rules.

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

run syslog-summary on this file

   * What was the outcome of this action?

about half of the INFO lines are not ignored and output in the
summary

   * What outcome did you expect instead?

no INFO lines in the summary output


   * Patch

There are 2 PR against upstream to fix this (I was a bit eager
to fix this...) [0,1], the oldest 5 years old.

My proposed patch [1] is at the end of this report, but [0] is a
one-line change.

[0] https://github.com/dpaleino/syslog-summary/pull/1
[1] https://github.com/dpaleino/syslog-summary/pull/3

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

Kernel: Linux 4.8.0-2-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 syslog-summary depends on:
pn  python:any  

Versions of packages syslog-summary recommends:
ii  python-magic  1:5.29-2

syslog-summary suggests no packages.

-- Configuration Files:
/etc/syslog-summary/ignore.rules changed [not included]

-- no debconf information

>From cb5748700d9f9d42b8680fa1ef3cc232df97823a Mon Sep 17 00:00:00 2001
From: Olivier Mehani 
Date: Mon, 9 Jan 2017 21:16:33 +1100
Subject: [PATCH] Fix ignore logic

The previous structure failed to ignore two lines in a row.

Signed-off-by: Olivier Mehani 
---
 syslog-summary | 47 +++
 1 file changed, 23 insertions(+), 24 deletions(-)

diff --git a/syslog-summary b/syslog-summary
index 17ad38b..8ffb27b 100755
--- a/syslog-summary
+++ b/syslog-summary
@@ -197,31 +197,30 @@ def summarize(filename, states):
ignored_count += 1
if DEBUG:
print "Ignoring: %s" % line
-   line = file.readline()
-   
-   date, rest = split_date(line)
-   if date:
-   found = pidpat.search(rest)
-   if found:
-   rest = found.group(1) + ": " + 
rest[found.end():]
-
-   count = 1
-   repeated = None
-   if REPEAT:
-   repeated = repeatpat.search(rest)
-   if repeated and previous:
-   count = int(repeated.group(1))
-   rest = previous
-
-   if counts.has_key(rest):
-   counts[rest] = counts[rest] + count
else:
-   assert count == 1
-   counts[rest] = count
-   order.append(rest)
-
-   if not repeated:
-   previous = rest
+   date, rest = split_date(line)
+   if date:
+   found = pidpat.search(rest)
+   if found:
+   rest = found.group(1) + ": " + 
rest[found.end():]
+   
+   count = 1
+   repeated = None
+   if REPEAT:
+   repeated = repeatpat.search(rest)
+   if repeated and previous:
+   count = int(repeated.group(1))
+   rest = previous
+   
+   if counts.has_key(rest):
+   counts[rest] = counts[rest] + count
+   else:
+   assert count == 1
+   counts[rest] = count
+   order.append(rest)
+   
+   if not repeated:
+   previous = rest
line = file.readline()
file.close()
 
-- 
2.11.0

Bug#850509: [Ceph-maintainers] Bug#850509: missing systemd targets

[Gaudenz Steinlin]

Control: tags -1 +pending

Hi Hans

Hans Grobler  writes:

> Package: ceph
> Version: 10.2.5-3
>
> Dear Maintainer,
>
> A number of systemd target files are missing, for example
> ceph-mon.target and ceph-osd.target. See
> http://tracker.ceph.com/issues/15573
>  for a similar upstream bug.
> Please include these so that auto-start can be properly configured and
> make the Debian packages consistent with the official documentation
> (e.g. http://docs.ceph.com/docs/master/rados/operations/operating/
> ).

Thanks for your report and the links. I really missed these targets.
This is now fixed in the GIT repository and will be part of the next
upload. I'm currently trying to fix some build failures but have now
hopefully resolved all of these. If the currently running mipsel build
succeeds, I'll do another upload tomorrow.

Gaudenz
-- 
PGP: 836E 4F81 EFBB ADA7 0852 79BF A97A 7702 BAF9 1EF5


signature.asc
Description: PGP signature

Bug#848287: python-testing.mysqld: (build-)depends on mysql-{client,server}

[Dominik George]

Dear MySQL/Mariadb maintainers,

> > I was able to identify the issue, but need help fixing it.
> > 
> > The problem is that the testing module uses the default root user of the
> > newly created database, and it uses the UNIX socket, and that has
> > peercred authentication by default in MariaDB.
> > 
> > I tried the following to disable peercred for the socket:
> > 
> > $ cat >init.sql
> > USE mysql;
> > UPDATE user SET plugin='' WHERE User='root';
> > FLUSH PRIVILEGES;
> > 
> > $ mysqld … --initialize-insecure --init-file=init.sql
> > 
> > But it still does not allow connecting a non-root user as root through
> > the UNIX socket.
> > 
> > Any help appreciated.
> 
> Cc'ing pkg-mysql-maint, maybe someone there can help.

As I would like to fix this issue before the full freeze, can you give
any hints on how to circumvent this change in default behaviour of the
mariadb "drop in replacement"?

Kind regards,
Nik

-- 
PGP-Fingerprint: 3C9D 54A4 7575 C026 FB17  FD26 B79A 3C16 A0C4 F296

Dominik George · Hundeshagenstr. 26 · 53225 Bonn
Mobile: +49-1520-1981389 · https://www.dominik-george.de/

Teckids e.V. · FrOSCon e.V.
Fellowship of the FSFE · Piratenpartei Deutschland
Opencaching Deutschland e.V. · Debian Maintainer

LPIC-3 Linux Enterprise Professional (Security)


signature.asc
Description: PGP signature

Bug#850751: gajim: Unexpected fingerprint collision in gnupg

[Dominik George]

Package: gajim
Version: 0.16.6-1
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

I leep getting this exception every few minutes, since I don't know exactl when:

Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/nbxmpp/dispatcher_nb.py", line 495, in 
dispatch
handler['func'](session, stanza)
  File "/usr/share/gajim/src/common/connection_handlers.py", line 1929, in 
_presenceCB
conn=self, stanza=prs))
  File "/usr/share/gajim/src/common/nec.py", line 76, in push_incoming_event
self._generate_events_based_on_incoming_event(event_object)
  File "/usr/share/gajim/src/common/nec.py", line 98, in 
_generate_events_based_on_incoming_event
if new_event_object.generate():
  File "/usr/share/gajim/src/common/connection_handlers_events.py", line 833, 
in generate
self._generate_keyID(sig_tag)
  File "/usr/share/gajim/src/common/connection_handlers_events.py", line 761, 
in _generate_keyID
self.jid, self.keyID)
  File "/usr/share/gajim/src/common/helpers.py", line 1313, in 
prepare_and_validate_gpg_keyID
public_keys = gajim.connections[account].ask_gpg_keys()
  File "/usr/share/gajim/src/common/connection.py", line 697, in ask_gpg_keys
return self.gpg.get_keys()
  File "/usr/share/gajim/src/common/gpg.py", line 117, in get_keys
result = super(GnuPG, self).list_keys(secret=secret)
  File "/usr/share/gajim/src/common/gnupg.py", line 1197, in list_keys
return self._get_list_output(p, 'list')
  File "/usr/share/gajim/src/common/gnupg.py", line 1163, in _get_list_output
getattr(result, keyword)(L)
  File "/usr/share/gajim/src/common/gnupg.py", line 494, in fpr
raise ValueError('Unexpected fingerprint collision: %s' % fp)
ValueError: Unexpected fingerprint collision: 
20869A4BE67D1DCDFFF6F6C159FC8E1D6F2A8001

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

Kernel: Linux 4.8.0-2-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 /usr/bin/lksh
Init: systemd (via /run/systemd/system)

Versions of packages gajim depends on:
ii  dnsutils1:9.10.3.dfsg.P4-10.1
ii  python-gtk2 2.24.0-5.1
ii  python-nbxmpp   0.5.4-1
ii  python-openssl  16.2.0-1
ii  python-pyasn1   0.1.9-2
pn  python:any  

Versions of packages gajim recommends:
ii  alsa-utils  1.1.2-1
ii  ca-certificates 20161130
ii  dbus1.10.14-1
ii  notification-daemon 3.20.0-1
ii  plasma-workspace [notification-daemon]  4:5.8.4-1
ii  pulseaudio-utils9.0-5
ii  python-crypto   2.6.1-7
ii  python-dbus 1.2.4-1
ii  sox 14.4.1-5+b1

Versions of packages gajim suggests:
ii  aspell-de [aspell-dictionary]   20161207-1
ii  aspell-de-1901 [aspell-dictionary]  1:2-31
ii  aspell-en [aspell-dictionary]   2016.11.20-0-0.1
ii  avahi-daemon0.6.32-1
ii  dvipng  1.14-2+b2
pn  gnome-keyring   
ii  gstreamer0.10-plugins-ugly  0.10.19-2.1+b3
ii  kwalletcli  3.00-1
ii  libgtkspell02.0.16-1.1
ii  libxss1 1:1.2.2-1
pn  nautilus-sendto 
ii  network-manager 1.4.4-1
ii  python-avahi0.6.32-1
ii  python-gconf2.28.1+dfsg-1.2
ii  python-gnome2   2.28.1+dfsg-1.2
pn  python-gnomekeyring 
ii  python-gupnp-igd0.2.4-1
pn  python-kerberos 
ii  python-pycurl   7.43.0-2
ii  texlive-latex-base  2016.20161130-1

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQJ4BAEBCABiFiEEPJ1UpHV1wCb7F/0mt5o8FqDE8pYFAlh0BZ4xGmh0dHBzOi8v
d3d3LmRvbWluaWstZ2VvcmdlLmRlL2dwZy1wb2xpY3kudHh0LmFzYxIcbmlrQG5h
dHVyYWxuZXQuZGUACgkQt5o8FqDE8pYG1hAAvXSSym6HbPhYK+9KxfIUqBn5TnDp
a9r3QA+aZ/Jv63E1E+GDVh6kX8GmlUzBG9KFilblKtP8MujFlriL2BDyWXZZcIx/
EnyMRU9U3oWp/iBcYHXt5A/sjPwmtytVgCPBJSZ7r4sjhPnTnJrlwEhnku0uK9zZ
rNFUcprSsjm4mDkXqOV6yQHpa3JAYAzqCHQSC1C64sas+drlGpkkxF2fVITOs5n1
cGMoBpS4DXfEumcbdhAjBLbxtf0GyDd8TXZoa17h8rpFxWUhz4R8FNwAm0nVOC69
fNpeBK0/XKsZ99/u1VvfNjZ7sTKy7Z2e3BxP/6+z2EEMj72Aqzt0eZfBNm2Yh1vd
dp2StEqAQB3LK/XCwkv/W9i85QkKdZUvddNc+FN5W0yhUKERD/x98cU+OeUKVxfG
TgpxuYP3vx8oAyYK7jeOs3Iu5wD0Nnf68IoeDvzHnYLkqX0C1ZUBCbokvKZYesnE
qja/oeRhAfRDfEGvYMfRYFcWuPqTtNLSuC4V626nJ9gf4glG9/ByFWXw0hploszt
VJNOOFN9i4l5w9x7URpkGtIdwtjo9zppYF4p3l6mZ/e4gHnDg2ZIFlFeLcxzWeKE
QwLjVB60sChDgABKWR362i6wsmfVKiJ9I0va7FDCfZVM6ajOowxAYZ1ldaW5RfhX
esTNRkh8NIAofZQ=
=DmWq
-END PGP SIGNATURE-

Bug#850749: gcc-6: Please enable gccgo on m68k

[Matthias Klose]

On 09.01.2017 22:44, John Paul Adrian Glaubitz wrote:
> Source: gcc-6
> Version: 6.3.0-2
> Severity: normal
> Tags: patch
> User: debian-...@lists.debian.org
> Usertags: m68k
> 
> Hi!
> 
> I just successfully verified that enabling gccgo on m68k produces a
> working gccgo package. I merely modified debian/rules.defs in the
> current gcc-6 package to remove "m68k" from the "go_no_cpus" statement
> and ran a regular build with sbuild on m68k.
> 
> I would like to play with gccgo on m68k, so it would be great if this
> could be enabled in the next gcc-6 package upload. After gccgo has
> been enabled here, it should also be enabled in gcc-7 and gcc-defaults
> for m68k.

Do you have test results for a build?

Bug#591291: pbuilder needs to mount /dev/shm

[Guido Günther]

On Sun, Aug 01, 2010 at 10:05:41PM +0200, Stefan Fritsch wrote:
> Package: pbuilder
> Version: 0.199
> Severity: normal
> 
> Pbuilder should mount a tmpfs at /dev/shm to allow posix shared memory and
> semaphores to work in the build chroot.
> 
> Apr's configure currently disables posix semaphores when built with
> cowbuilder or pbuilder (bug #591286).

Here's another datapoint (I failed to recognize that /dev/shm is not a
tmpfs yet in the chroot):

https://lists.debian.org/debian-lts/2017/01/msg00044.html

Would linkint /run/shm -> /dev/shm do the trick?
Cheers,
 -- Guido

Bug#850720: firefox: Use pkg-info.mk to figure out source name and version

[Mike Hommey]

On Mon, Jan 09, 2017 at 10:32:06PM +0100, Rohan Garg wrote:
> Hey
> 
> > Try your patch on the firefox package in experimental, and the
> > firefox-esr package in testing/unstable.
> 
> Gotcha.
> 
> Would it be possible meanwhile to fix epoch handling when trying to
> figure out the upstream version?

There is no epoch in the Debian version, and if you're deriving the
debian package to add one, you can just as much apply your patch.

Mike

Bug#850745: ldapvi: misleading documentation: refers to website intentionally left blank

[David Lichteblau]

Just added a redirect from the old URL to make it meaningful.  Hopefully
that improves the user experience.  Thanks for the report!

Bug#850750: unblock: firejail/0.9.44.4-1

[Reiner Herrmann]

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

Please unblock package firejail

firejail 0.9.44.4-1 contains fixes for 3 CVEs compared to the
version in stretch (CVE-2017-5180, CVE-2017-5206, CVE-2017-5207).
Please lower the migration time for it.

Kind regards,
  Reiner

unblock firejail/0.9.44.4-1
diff -Nru firejail-0.9.44.2/configure firejail-0.9.44.4/configure
--- firejail-0.9.44.2/configure 2016-12-02 14:18:09.0 +0100
+++ firejail-0.9.44.4/configure 2017-01-07 13:58:37.0 +0100
@@ -1,6 +1,6 @@
 #! /bin/sh
 # Guess values for system-dependent variables and create Makefiles.
-# Generated by GNU Autoconf 2.69 for firejail 0.9.44.2.
+# Generated by GNU Autoconf 2.69 for firejail 0.9.44.4.
 #
 # Report bugs to .
 #
@@ -580,8 +580,8 @@
 # Identity of this package.
 PACKAGE_NAME='firejail'
 PACKAGE_TARNAME='firejail'
-PACKAGE_VERSION='0.9.44.2'
-PACKAGE_STRING='firejail 0.9.44.2'
+PACKAGE_VERSION='0.9.44.4'
+PACKAGE_STRING='firejail 0.9.44.4'
 PACKAGE_BUGREPORT='netblu...@yahoo.com'
 PACKAGE_URL='http://firejail.wordpress.com'
 
@@ -1259,7 +1259,7 @@
   # Omit some internal or obsolete options to make the list less imposing.
   # This message is too long to be a string in the A/UX 3.1 sh.
   cat <<_ACEOF
-\`configure' configures firejail 0.9.44.2 to adapt to many kinds of systems.
+\`configure' configures firejail 0.9.44.4 to adapt to many kinds of systems.
 
 Usage: $0 [OPTION]... [VAR=VALUE]...
 
@@ -1320,7 +1320,7 @@
 
 if test -n "$ac_init_help"; then
   case $ac_init_help in
- short | recursive ) echo "Configuration of firejail 0.9.44.2:";;
+ short | recursive ) echo "Configuration of firejail 0.9.44.4:";;
esac
   cat <<\_ACEOF
 
@@ -1424,7 +1424,7 @@
 test -n "$ac_init_help" && exit $ac_status
 if $ac_init_version; then
   cat <<\_ACEOF
-firejail configure 0.9.44.2
+firejail configure 0.9.44.4
 generated by GNU Autoconf 2.69
 
 Copyright (C) 2012 Free Software Foundation, Inc.
@@ -1726,7 +1726,7 @@
 This file contains any messages produced by compilers while
 running configure, to aid debugging if configure makes a mistake.
 
-It was created by firejail $as_me 0.9.44.2, which was
+It was created by firejail $as_me 0.9.44.4, which was
 generated by GNU Autoconf 2.69.  Invocation command line was
 
   $ $0 $@
@@ -4303,7 +4303,7 @@
 # report actual input values of CONFIG_FILES etc. instead of their
 # values after options handling.
 ac_log="
-This file was extended by firejail $as_me 0.9.44.2, which was
+This file was extended by firejail $as_me 0.9.44.4, which was
 generated by GNU Autoconf 2.69.  Invocation command line was
 
   CONFIG_FILES= $CONFIG_FILES
@@ -4357,7 +4357,7 @@
 cat >>$CONFIG_STATUS <<_ACEOF || ac_write_fail=1
 ac_cs_config="`$as_echo "$ac_configure_args" | sed 's/^ //; 
s/[\\""\`\$]/&/g'`"
 ac_cs_version="\\
-firejail config.status 0.9.44.2
+firejail config.status 0.9.44.4
 configured by $0, generated by GNU Autoconf 2.69,
   with options \\"\$ac_cs_config\\"
 
diff -Nru firejail-0.9.44.2/configure.ac firejail-0.9.44.4/configure.ac
--- firejail-0.9.44.2/configure.ac  2016-12-02 14:17:36.0 +0100
+++ firejail-0.9.44.4/configure.ac  2017-01-07 13:57:38.0 +0100
@@ -1,5 +1,5 @@
 AC_PREREQ([2.68])
-AC_INIT(firejail, 0.9.44.2, netblu...@yahoo.com, , 
http://firejail.wordpress.com)
+AC_INIT(firejail, 0.9.44.4, netblu...@yahoo.com, , 
http://firejail.wordpress.com)
 AC_CONFIG_SRCDIR([src/firejail/main.c])
 #AC_CONFIG_HEADERS([config.h])
 
diff -Nru firejail-0.9.44.2/debian/changelog firejail-0.9.44.4/debian/changelog
--- firejail-0.9.44.2/debian/changelog  2016-12-04 21:44:08.0 +0100
+++ firejail-0.9.44.4/debian/changelog  2017-01-07 20:24:40.0 +0100
@@ -1,3 +1,24 @@
+firejail (0.9.44.4-1) unstable; urgency=high
+
+  * New upstream release.
+- Security fixes for: CVE-2017-5180, CVE-2017-5206, CVE-2017-5207
+  (Closes: #850528, #850558)
+  * Drop patches applied upstream.
+
+ -- Reiner Herrmann   Sat, 07 Jan 2017 20:24:40 +0100
+
+firejail (0.9.44.2-3) unstable; urgency=high
+
+  * Add followup fix for CVE-2017-5180 (Closes: #850160).
+
+ -- Reiner Herrmann   Fri, 06 Jan 2017 13:44:25 +0100
+
+firejail (0.9.44.2-2) unstable; urgency=high
+
+  * Add upstream fix for CVE-2017-5180 (Closes: #850160).
+
+ -- Reiner Herrmann   Wed, 04 Jan 2017 23:56:30 +0100
+
 firejail (0.9.44.2-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru firejail-0.9.44.2/platform/rpm/old-mkrpm.sh 
firejail-0.9.44.4/platform/rpm/old-mkrpm.sh
--- firejail-0.9.44.2/platform/rpm/old-mkrpm.sh 2016-12-03 20:14:29.0 
+0100
+++ firejail-0.9.44.4/platform/rpm/old-mkrpm.sh 2017-01-07 17:43:11.0 
+0100
@@ -1,5 +1,5 @@
 #!/bin/bash
-VERSION="0.9.44.2"
+VERSION="0.9.44.4"
 rm -fr ~/rpmbuild
 rm -f firejail-$VERSION-1.x86_64.rpm
 
@@ -458,6 +458,9 @@
 chmod u+s /usr/bin/firejail
 
 

Bug#850749: gcc-6: Please enable gccgo on m68k

[John Paul Adrian Glaubitz]

Source: gcc-6
Version: 6.3.0-2
Severity: normal
Tags: patch
User: debian-...@lists.debian.org
Usertags: m68k

Hi!

I just successfully verified that enabling gccgo on m68k produces a
working gccgo package. I merely modified debian/rules.defs in the
current gcc-6 package to remove "m68k" from the "go_no_cpus" statement
and ran a regular build with sbuild on m68k.

I would like to play with gccgo on m68k, so it would be great if this
could be enabled in the next gcc-6 package upload. After gccgo has
been enabled here, it should also be enabled in gcc-7 and gcc-defaults
for m68k.

Thanks,
Adrian

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
--- debian/rules.defs.old   2017-01-09 22:07:01.0 +0100
+++ debian/rules.defs   2017-01-09 22:07:57.601561567 +0100
@@ -929,7 +929,7 @@
   with_libcc1 :=
 endif
 
-go_no_cpus := avr arm hppa m68k sh4
+go_no_cpus := avr arm hppa sh4
 ifeq (,$(filter $(distrelease),lenny etch squeeze dapper hardy jaunty karmic 
lucid maverick natty oneiric))
   go_no_cpus := $(filter-out arm, $(go_no_cpus))
 endif

Bug#850748: redshift: fails on startup without GPS

[rugk]

Source: redshift
Version: 1.9.1-4
Severity: grave
Tags: newcomer
Justification: renders package unusable

Dear Maintainer,

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

When running the software it on a device without GPS support Redshift always
fails with the error "No more methods to try [for getting the location]". This
happens with geoclue2 activated and even when I manually pass some coordinates
to Redshift.

An example (sry, for German output):
$ redshift -vvv
Versuche Location Provider `geoclue2'...
Dienst »geoclue2« wird benutzt.
Position: 51.30° N, 12.33° O
Farbtemperatur: 5500K tagsüber, 3500K nachts
Solar elevations: day above 3.0, night below -6.0
Helligkeit: 1.00:1.00
Gamma (Tagsüber): 1.000, 1.000, 1.000
Gamma (Nachts): 1.000, 1.000, 1.000
Keine weiteren Methoden verfügbar.
$ redshift -l 51:32 -vvv
Position: 51.00° N, 32.00° O
Farbtemperatur: 5500K tagsüber, 3500K nachts
Solar elevations: day above 3.0, night below -6.0
Helligkeit: 1.00:1.00
Gamma (Tagsüber): 1.000, 1.000, 1.000
Gamma (Nachts): 1.000, 1.000, 1.000
Keine weiteren Methoden verfügbar.

Both tries do not work.

The full upstream report is available under
  https://github.com/jonls/redshift/issues/333
where the maintainer also suspected that it is a built/compilation error.
He suspects that "Redshift was not compiled with any adjustment methods".
Here his explanation (link:
https://github.com/jonls/redshift/issues/333#issuecomment-271186561):
> Redshift has several ways of adjusting the gamma ramps: Vidmode, Randr,
Quartz (on macOS), wingdi (on Windows), etc. When compiling, you have to
specify which adjustment method you want to include in the the application. If
you didn't include any, Redshift won't be able to do anything, it will just
fail with "no adjustment methods left to try".



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

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

Bug#850747: Installation Troubles

[Raymond Clark]

Package: installation-reports

Boot method: followed instructions to load initrd.gz and zImage into memory per 
https://www.debian.org/releases/wheezy/armel/ch05s01.html.en#boot-firmware
Image version: wheezy
Date: 1/9/2017 14:30 MST

Machine: Intel SS4000E
Processor: ARM
Memory: 256M
Partitions: none

Output of lspci -knn (or lspci -nn): not available

Base System Installation Checklist:
[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it

Initial boot:   [E]
Detect network card:[ ]
Configure network:  [ ]
Detect CD:  [ ]
Load installer modules: [ ]
Detect hard drives: [ ]
Partition hard drives:  [ ]
Install base system:[ ]
Clock/timezone setup:   [ ]
User/password setup:[ ]
Install tasks:  [ ]
Install boot loader:[ ]
Overall install:[ ]

Comments/Problems:

Have tried several times and seem to meet same demise each time. I know wheezy 
is backlevel but I understand it is the last to support the SS4000E.
The console output is below and it seems to be a problem with initrd at 
0.172929 below.

Thank you for any assistance.
 
RedBoot> load -v -r -b 0x0180 -m ymodem initrd.gz

CRaw file loaded 0x0180-0x01cc9a8e, assumed entry at 0x0180
xyzModem - CRC mode, 1(SOH)/4903(STX)/0(CAN) packets, 3 retries
RedBoot> load -v -r -b 0x01008000 -m ymodem zImage
CRaw file loaded 0x01008000-0x01167347, assumed entry at 0x01008000
xyzModem - CRC mode, 1(SOH)/1405(STX)/0(CAN) packets, 4 retries
RedBoot> exec -r 0x0180 -c "console=ttyS0,115200 rw root=/dev/ram 
mem=256M@0xa000 BOOT_DEBUG=2"
Using base address 0x01008000 and length 0x0015f348
Uncompressing Linux... done, booting the kernel.
[0.00] Initializing cgroup subsys cpuset
[0.00] Initializing cgroup subsys cpu
[0.00] Linux version 3.2.0-4-iop32x (debian-ker...@lists.debian.org) 
(gcc version 4.6.3 (Debian 4.6.3-14) ) #1 Debian 3.2.78-1
[0.00] CPU: XScale-80219 [69052e20] revision 0 (ARMv5TE), cr=397f
[0.00] CPU: VIVT data cache, VIVT instruction cache
[0.00] Machine: Lanner EM7210
[0.00] Memory policy: ECC disabled, Data cache writeback
[0.00] Built 1 zonelists in Zone order, mobility grouping on.  Total 
pages: 65024
[0.00] Kernel command line: console=ttyS0,115200 rw root=/dev/ram 
mem=256M@0xa000 BOOT_DEBUG=2
[0.00] PID hash table entries: 1024 (order: 0, 4096 bytes)
[0.00] Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
[0.00] Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
[0.00] Memory: 256MB = 256MB total
[0.00] Memory: 251556k/251556k available, 10588k reserved, 0K highmem
[0.00] Virtual kernel memory layout:
[0.00] vector  : 0x - 0x1000   (   4 kB)
[0.00] fixmap  : 0xfff0 - 0xfffe   ( 896 kB)
[0.00] vmalloc : 0xd080 - 0xfe00   ( 728 MB)
[0.00] lowmem  : 0xc000 - 0xd000   ( 256 MB)
[0.00] modules : 0xbf00 - 0xc000   (  16 MB)
[0.00]   .text : 0xc0008000 - 0xc0382854   (3563 kB)
[0.00]   .init : 0xc0383000 - 0xc03a2000   ( 124 kB)
[0.00]   .data : 0xc03a2000 - 0xc03d2d40   ( 196 kB)
[0.00].bss : 0xc03d2d64 - 0xc0419248   ( 282 kB)
[0.00] NR_IRQS:32
[0.00] sched_clock: 32 bits at 200MHz, resolution 5ns, wraps every 
21474ms
[0.00] Console: colour dummy device 80x30
[0.000410] Calibrating delay loop... 398.13 BogoMIPS (lpj=1990656)
[0.050067] pid_max: default: 32768 minimum: 301
[0.050384] Security Framework initialized
[0.050551] Mount-cache hash table entries: 512
[0.051520] Initializing cgroup subsys cpuacct
[0.051582] Initializing cgroup subsys memory
[0.051647] Initializing cgroup subsys devices
[0.051670] Initializing cgroup subsys freezer
[0.051692] Initializing cgroup subsys net_cls
[0.051714] Initializing cgroup subsys blkio
[0.051771] Initializing cgroup subsys perf_event
[0.051955] CPU: Testing write buffer coherency: ok
[0.052751] hw perfevents: enabled with xscale1 PMU driver, 3 counters 
available
[0.056286] devtmpfs: initialized
[0.059550] print_constraints: dummy:
[0.060315] NET: Registered protocol family 16
[0.065854] PCI: bus0: Fast back to back transfers disabled
[0.068299] pci :00:01.0: BAR 0: assigned [mem 0x8000-0x8001]
[0.068355] pci :00:01.0: BAR 1: assigned [mem 0x8002-0x8003]
[0.068395] pci :00:01.0: BAR 6: assigned [mem 0x8004-0x8005 
pref]
[0.068432] pci :00:02.0: BAR 0: assigned [mem 0x8006-0x8007]
[0.068470] pci :00:02.0: BAR 1: assigned [mem 0x8008-0x8009]
[0.068509] pci :00:02.0: BAR 6: assigned [mem 0x800a-0x800b 
pref]
[0.068547] pci :00:03.0: BAR 0: assigned [mem 0x800c-0x800c0fff 
64bit]
[0.068588] pci :00:05.0: BAR 0: 

Bug#850746: retext segfaults when attempting to open 'open file' dialogue

[John Hackett]

Package: retext
Version: 6.0.2-2
Severity: normal

Dear Dmitry,

When using retext to open a file immediately after a dist-upgrade from jessie 
to stretch, I find that retext segfaults in the following manner when I attempt 
to open a file by using the dialog loaded for file->open. It happens like so:

```
% retext
Using configuration file: /home/tethra/.config/ReText project/ReText.conf

(python3:25248): Gdk-WARNING **: 
/build/gtk+3.0-9JqLNv/gtk+3.0-3.22.5/./gdk/x11/gdkwindow-x11.c:5573 drawable is 
not a native X11 window
Process Process-1:
[1]25248 segmentation fault  retext
Traceback (most recent call last):  
 
  File "/usr/lib/python3.5/multiprocessing/process.py", line 249, in _bootstrap
self.run()
  File "/usr/lib/python3.5/multiprocessing/process.py", line 93, in run
self._target(*self._args, **self._kwargs)
  File "/usr/share/retext/ReText/converterprocess.py", line 62, in 
_converter_process_func
job = receiveObject(conn_child)
  File "/usr/share/retext/ReText/converterprocess.py", line 31, in receiveObject
sizeBuf = recvall(sock, 4)
  File "/usr/share/retext/ReText/converterprocess.py", line 24, in recvall
raise EOFError('Received 0 bytes from socket while more bytes were 
expected. Did the sender process exit unexpectedly?')
EOFError: Received 0 bytes from socket while more bytes were expected. Did the 
sender process exit unexpectedly?
```

I've attempted to resolve this by reinstalling the package after purging, and a 
good old fashioned reboot, but to no avail.

Best regards
John

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

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

Versions of packages retext depends on:
ii  python3-docutils0.13.1+dfsg-1
ii  python3-enchant 1.6.7-1
ii  python3-markdown2.6.7-1
ii  python3-markups 2.0.0-1
ii  python3-pygments2.1.3+dfsg-1
ii  python3-pyqt5   5.7+dfsg-2+b1
ii  python3-pyqt5.qtwebkit  5.7+dfsg-2+b1
pn  python3:any 

Versions of packages retext recommends:
ii  docutils-common   0.13.1+dfsg-1
ii  shared-mime-info  1.7-1

Versions of packages retext suggests:
ii  adwaita-icon-theme 3.22.0-1
ii  gir1.2-glib-2.01.50.0-1
ii  gsettings-desktop-schemas  3.22.0-1

-- no debconf information

Bug#850720: firefox: Use pkg-info.mk to figure out source name and version

[Rohan Garg]

Hey

> Try your patch on the firefox package in experimental, and the
> firefox-esr package in testing/unstable.

Gotcha.

Would it be possible meanwhile to fix epoch handling when trying to
figure out the upstream version?

Cheers
Rohan Garg

Bug#850720: firefox: Use pkg-info.mk to figure out source name and version

[Mike Hommey]

On Mon, Jan 09, 2017 at 09:59:25PM +0100, Rohan Garg wrote:
> Hey
> > This change most likely breaks building ESR and Beta.
> >
> 
> Oh, can you give me more info on how I can check my changes against that?

Try your patch on the firefox package in experimental, and the
firefox-esr package in testing/unstable.

Mike