Bug#848308: RM: rtslib -- ROM; superseded by rtslib-fb, from new LIO-fb upstream

[Ritesh Raj Sarraf]

Package: ftp.debian.org
Severity: normal

The rtslib upstream  is not active to our expectations. Thus we switched
the LIO stack from LIO to LIO-fb.

Bug#750138: scap-workbench

[Petter Reinholdtsen]

Btw, the upstream/1.1.3 tag seem to be missing from your git repository.
-- 
Happy hacking
Petter Reinholdtsen

Bug#848298: mongodb: Build for s390x

[Apollon Oikonomopoulos]

Control: tags -1 wontfix upstream fixed-upstream

Hi Jeremy,

On 19:50 Thu 15 Dec , Jeremy Bicha wrote:
> MongoDB has recently gained support for running on s390x.
> 
> The official documentation says s390x is supported on MongoDB 3.4
> Enterprise Edition.[1]
> 
> IBM has documentation [2]that says it's possible to build and run it
> on 3.2. They have ~16 backported patches in their git repo branched
> off an older 3.2 version. (I noticed at least one of the patches was
> already applied in a more recent 3.2 release.
> 
> I don't have access to an s390x machine. I just know some people were
> interested in seeing this work on Debian/Ubuntu.

Thanks for the heads-up. Although I'm not completely opposed to the 
idea, there are at least two important reasons I think we should not do 
this for 3.2 (and thus I'm marking it as wontfix, at least for now):

 - The patchset is quite intrusive: it adds support for big-endian 
   architectures *in general* and touches a lot of code also used by 
   little-endian architectures, with unknown impact.

 - The IBM branch is based off 3.2.0 and I suspect it will be 
   non-trivial to forward-port everything to 3.2.11. Furthermore not all 
   IBM patches seem to have been accepted upstream as-is.

Thus said, I prefer to enable s390x support when we upload 3.4, where 
it's officially supported and guaranteed not to interfere with the other 
architectures. Note that I haven't made up my mind yet as to whether we 
should push for 3.4 in Stretch or not; 3.4 it is still very young, while 
3.2 is new-enough and has been tested in production.

Regards,
Apollon

Bug#819703: Good day

[ROBAS MORA, MARINA]

I, Liliane Donated 2,000,000 Dollars to you, Contact me on ( 
lbetten...@outlook.pt ) for more details.





??




Este mensaje y sus archivos adjuntos, enviados desde FUNDACIÓN UNIVERSITARIA 
SAN PABLO-CEU, pueden contener información confidencial y está destinado a ser 
leído sólo por la persona a la que va dirigido por lo que queda prohibida la 
difusión, copia o utilización de dicha información por terceros. Si usted lo 
recibiera por error, por favor, notifíquelo al remitente y destruya el mensaje 
y cualquier documento adjunto que pudiera contener.

En cumplimiento de la Ley Orgánica 15/1999, de 13 de diciembre, de Protección 
de Datos de Carácter Personal, le recordamos que podrá en todo momento 
ejercitar los derechos de acceso, rectificación, cancelación y oposición sobre 
sus datos personales que hayan podido ser incorporados en nuestros ficheros a 
través del envío de un correo electrónico al remitente, especificando en el 
cuerpo del mensaje la dirección de e-mail sobre la que desea ejercitar su 
derecho.

Cualquier información, opinión, conclusión, recomendación, etc. contenida en el 
presente mensaje no relacionada con la actividad de FUNDACIÓN UNIVERSITARIA SAN 
PABLO-CEU y/o emitida por persona sin capacidad para ello, deberá considerarse 
como no proporcionada ni aprobada por FUNDACIÓN UNIVERSITARIA SAN PABLO-CEU, 
que pone los medios a su alcance para garantizar la seguridad y ausencia de 
errores en la correspondencia electrónica, pero no puede asegurar la 
inexistencia de virus o la no alteración de los documentos transmitidos 
electrónicamente, por lo que declina cualquier responsabilidad a este respecto.

This message and its attachments, sent from FUNDACIÓN UNIVERSITARIA SAN 
PABLO-CEU, may contain confidential information and is intended to be read only 
by the person to which it is directed. Therefore any disclosure, copying or use 
by third parties of this information is prohibited. If you receive this in 
error, please notify the sender and destroy the message and any attachments 
that it may contain.

In compliance with Law 15/1999, December 13, of Personal Data Protection, we 
remind you that you may at any time exercise your rights of access, 
rectification, cancellation and opposition of your personal data that may have 
been stored in our files by sending an e- mail to the sender, specifying the 
message body of the e-mail address on which you wish to exercise your right.

Any information, opinion, conclusion, recommendation,... contained in this 
message and which is unrelated to the business activity of FUNDACIÓN 
UNIVERSITARIA SAN PABLO-CEU and/or issued by unauthorized personnel, shall be 
considered unapproved by FUNDACIÓN UNIVERSITARIA SAN PABLO-CEU. FUNDACIÓN 
UNIVERSITARIA SAN PABLO-CEU implements control measures to ensure, as far as 
possible, the security and reliability of all its electronic correspondence. 
However, FUNDACIÓN UNIVERSITARIA SAN PABLO-CEU does not guarantee that emails 
are virus-free or that documents have not be altered, and does not take 
responsibility in this respect.

Bug#848305: mongodb: Add missing changelog entry for 1:2.6.12-3

[Apollon Oikonomopoulos]

Control: tags -1 pending

Hi Salvatore,

On 06:42 Fri 16 Dec , Salvatore Bonaccorso wrote:
> Source: mongodb
> Version: 1:3.2.11-2
> Severity: wishlist
> Tags: patch
> 
> Hi Apollon, hi Laszlo
> 
> Please consider adding back the debian/changelog entry for 1:2.6.12-3
> which contained the reference for the CVE fix. Patch attached.
> 
> Thanks lot for considering. If you disagree, please close and mark as
> wontfix.

Sorry, I missed that when I merged the branches (using -s ours while I 
shouldn't have). I will do so in the next upload, for the time being I 
marked #832908 manually as fixed in 3.2.11, as I've applied the patch 
there as well.


Regards,
Apollon

Bug#848100: neovim-qt: Please install as alternative for "gvim"

[Philipp Marek]

Hi James,

thank you for your help!


> > Please install a gvim alternative:
> > # update-alternatives --install /usr/bin/gvim gvim /usr/bin/nvim-qt 50
> 
> Sounds reasonable.  jpleau is looking into that.
Thanks!

> > BTW, the initial size of the nvim-qt window is ~9 by 4 characters for me... 
> > shouldn't nvim-qt have some more sane defaults?
> 
> I don't see that here.  What happens if you run "nvim-qt -- -u NONE"?
> If that works fine, then there's some configuration/plugin that's
> affecting this.
Hrmm, yeah, you're right again.

I notice that usr_31.txt is not updated - ":winpos" says "not implemented", 
changing "columns" or "lines" makes no difference, ...


If I've got a gvim trace file ("-V255/tmp/gvim-trace"), what could I search 
for to find out which plugin causes that?

Bug#848307: gdb-doc has no binaries on any arch

[Sven Joachim]

Source: gdb-doc
Version: 7.12-1
Severity: serious

The latest upload of gdb-doc included only the source, but the
autobuilders are not allowed to build the binary package because there
is no XS-Autobuild field in debian/control.

And because of #825398 the binary package has already been removed from
unstable, so you will have to build and upload it. :-(

Bug#842675: Fix, NMU to DELAYED/5

[Hilko Bengen]

Hi,

here is a set of patches that I intend to NMU to DELAYED/5 later. I have
changed the .symbols file to use C++ name demangling and added some
optional symbols that seem to come directly from the Qt library.

I have also taken the liberty to add a missing dependency on lsb-base
which was flagged as an error by Lintian.

Cheers,
-Hilko
>From 94e74966b47a28e0753c75311d7073d9763ffc25 Mon Sep 17 00:00:00 2001
From: Hilko Bengen 
Date: Wed, 14 Dec 2016 17:46:21 +0100
Subject: [PATCH 1/4] Use demangled symbols

---
 debian/liblightdm-qt-3-0.symbols | 260 ++-
 1 file changed, 118 insertions(+), 142 deletions(-)

diff --git a/debian/liblightdm-qt-3-0.symbols b/debian/liblightdm-qt-3-0.symbols
index a1cd79c..3ceea6a 100644
--- a/debian/liblightdm-qt-3-0.symbols
+++ b/debian/liblightdm-qt-3-0.symbols
@@ -1,143 +1,119 @@
 liblightdm-qt-3.so.0 liblightdm-qt-3-0 #MINVER#
- _ZN10QDBusErrorD1Ev@Base 1.8.7
- _ZN10QDBusErrorD2Ev@Base 1.8.7
- _ZN10QDBusReplyI7QStringED1Ev@Base 1.8.7
- _ZN10QDBusReplyI7QStringED2Ev@Base 1.8.7
- _ZN11SessionItemD1Ev@Base 1.8.7
- _ZN11SessionItemD2Ev@Base 1.8.7
- _ZN20SessionsModelPrivate12loadSessionsEN8QLightDM13SessionsModel11SessionTypeE@Base 1.8.7
- _ZN20SessionsModelPrivateC1EPN8QLightDM13SessionsModelE@Base 1.8.7
- _ZN20SessionsModelPrivateC2EPN8QLightDM13SessionsModelE@Base 1.8.7
- _ZN5QHashIi10QByteArrayE11deleteNode2EPN9QHashData4NodeE@Base 1.8.7
- _ZN5QHashIi10QByteArrayE13detach_helperEv@Base 1.8.7
- _ZN5QHashIi10QByteArrayE13duplicateNodeEPN9QHashData4NodeEPv@Base 1.8.7
- _ZN5QListI11SessionItemE18detach_helper_growEii@Base 1.8.7
- _ZN5QListI11SessionItemE6appendERKS0_@Base 1.8.7
- _ZN5QListI8UserItemE13detach_helperEi@Base 1.8.7
- _ZN5QListI8UserItemE18detach_helper_growEii@Base 1.8.7
- _ZN5QListI8UserItemE6appendERKS0_@Base 1.8.7
- _ZN6QDebugD1Ev@Base 1.8.7
- _ZN6QDebugD2Ev@Base 1.8.7
- _ZN8QLightDM10UsersModel11qt_metacallEN11QMetaObject4CallEiPPv@Base 1.8.7
- _ZN8QLightDM10UsersModel11qt_metacastEPKc@Base 1.8.7
- _ZN8QLightDM10UsersModel16staticMetaObjectE@Base 1.8.7
- _ZN8QLightDM10UsersModelC1EP7QObject@Base 1.8.7
- _ZN8QLightDM10UsersModelC2EP7QObject@Base 1.8.7
- _ZN8QLightDM10UsersModelD0Ev@Base 1.8.7
- _ZN8QLightDM10UsersModelD1Ev@Base 1.8.7
- _ZN8QLightDM10UsersModelD2Ev@Base 1.8.7
- _ZN8QLightDM13SessionsModel11qt_metacallEN11QMetaObject4CallEiPPv@Base 1.8.7
- _ZN8QLightDM13SessionsModel11qt_metacastEPKc@Base 1.8.7
- _ZN8QLightDM13SessionsModel16staticMetaObjectE@Base 1.8.7
- _ZN8QLightDM13SessionsModelC1ENS0_11SessionTypeEP7QObject@Base 1.8.7
- _ZN8QLightDM13SessionsModelC1EP7QObject@Base 1.8.7
- _ZN8QLightDM13SessionsModelC2ENS0_11SessionTypeEP7QObject@Base 1.8.7
- _ZN8QLightDM13SessionsModelC2EP7QObject@Base 1.8.7
- _ZN8QLightDM13SessionsModelD0Ev@Base 1.8.7
- _ZN8QLightDM13SessionsModelD1Ev@Base 1.8.7
- _ZN8QLightDM13SessionsModelD2Ev@Base 1.8.7
- _ZN8QLightDM14GreeterPrivate13cb_showPromptEP14LightDMGreeterPKc17LightDMPromptTypePv@Base 1.8.7
- _ZN8QLightDM14GreeterPrivate14cb_showMessageEP14LightDMGreeterPKc18LightDMMessageTypePv@Base 1.8.7
- _ZN8QLightDM14GreeterPrivate19cb_autoLoginExpiredEP14LightDMGreeterPv@Base 1.8.7
- _ZN8QLightDM14GreeterPrivate25cb_authenticationCompleteEP14LightDMGreeterPv@Base 1.8.7
- _ZN8QLightDM14GreeterPrivate7cb_idleEP14LightDMGreeterPv@Base 1.12.2
- _ZN8QLightDM14GreeterPrivate8cb_resetEP14LightDMGreeterPv@Base 1.12.2
- _ZN8QLightDM14GreeterPrivateC1EPNS_7GreeterE@Base 1.8.7
- _ZN8QLightDM14GreeterPrivateC2EPNS_7GreeterE@Base 1.8.7
- _ZN8QLightDM14PowerInterface10canRestartEv@Base 1.8.7
- _ZN8QLightDM14PowerInterface10canSuspendEv@Base 1.8.7
- _ZN8QLightDM14PowerInterface11canShutdownEv@Base 1.8.7
- _ZN8QLightDM14PowerInterface11qt_metacallEN11QMetaObject4CallEiPPv@Base 1.8.7
- _ZN8QLightDM14PowerInterface11qt_metacastEPKc@Base 1.8.7
- _ZN8QLightDM14PowerInterface12canHibernateEv@Base 1.8.7
- _ZN8QLightDM14PowerInterface16staticMetaObjectE@Base 1.8.7
- _ZN8QLightDM14PowerInterface21PowerInterfacePrivateC1Ev@Base 1.8.7
- _ZN8QLightDM14PowerInterface21PowerInterfacePrivateC2Ev@Base 1.8.7
- _ZN8QLightDM14PowerInterface7restartEv@Base 1.8.7
- _ZN8QLightDM14PowerInterface7suspendEv@Base 1.8.7
- _ZN8QLightDM14PowerInterface8shutdownEv@Base 1.8.7
- _ZN8QLightDM14PowerInterface9hibernateEv@Base 1.8.7
- _ZN8QLightDM14PowerInterfaceC1EP7QObject@Base 1.8.7
- _ZN8QLightDM14PowerInterfaceC2EP7QObject@Base 1.8.7
- _ZN8QLightDM14PowerInterfaceD0Ev@Base 1.8.7
- _ZN8QLightDM14PowerInterfaceD1Ev@Base 1.8.7
- _ZN8QLightDM14PowerInterfaceD2Ev@Base 1.8.7
- _ZN8QLightDM17UsersModelPrivate12cb_userAddedEP15LightDMUserListP11LightDMUserPv@Base 1.8.7
- _ZN8QLightDM17UsersModelPrivate14cb_userChangedEP15LightDMUserListP11LightDMUserPv@Base 1.8.7
- _ZN8QLightDM17UsersModelPrivate14cb_userRemovedEP15LightDMUserListP11LightDMUserPv@Base 1.8.7
- _ZN8QLightDM17UsersModelPrivate9loadUsersEv@Base 1.8.7
- _ZN8QLightDM17UsersModelPrivateC1EPNS_10UsersModelE@Base 1.8.7
- 

Bug#848247: [Pkg-libvirt-maintainers] Bug#848247: Collection of fixes for libvirt smoke tests

[Christian Ehrhardt]

On Thu, Dec 15, 2016 at 6:26 PM, Guido Günther  wrote:

> Thanks for these. I've pulled parts in but I thins some are not needed:
>

Thanks for all the applied's removing those and continuing discussion on
the remaining ones.


> >
> > d/t/control, d/t/smoke-qemu-session, d/t/smoke-lxc: fix up smoke tests
> >
> > ERR: error: Failed to connect socket to '/var/run/libvirt/libvirt-sock':
> No
> >  such file or directory
> > FIX: install libvirt-daemon-system
>
> No, we run as non-root so (so we can use qemu:///session)
>

Yeah - I think I'm good with that.
Initially when in the autopkgtest env I think I missed to export that
properly.
I later fixed it up for my tests on the lxc tests and things were ok.

One thing I also found without "needs-root" was that the
`virt-host-validate qemu` failed on /dev/kvm being root/root and thereby
not accessible from non-root.
Is /dev/kvm set up differently by default on Debian so that it is
accessible to you?

Other than the discussion I think I need adapt and rerun when I re-merge to
your next release with the other fixes accepted here in place.
I'd come back to this bug with more detail then if I still would need
anything of the needs-root/libvirt-daemon-system.

> ERR: arch can be x86_64
> > FIX: modify grep "arch name='x86_64'" -> "arch.*x86_64""
>
> Which versions did you see this with?
>

In terms of qemu still an older one as merging that will follow libvirt, so
atm a combination of libvirt 2.5-experimental and qemu 2.6.1.
Both with Ubuntu Delta, but I'd doubt that would change this part of the
behavior.
But if it is the qemu version - then for all sorts of backporting activity
(if ever) it might be useful to have the more relaxed regexp I suggested.


> > ERR: potential race, guest dies on most non bare metal platforms after a
> few
> >  seconds
> > FIX: well, not a fix but add FIXME comment on 2nd level virtualization
> >  issues
>
> I'm not sure how this helps here.
>

Well it does not "help", it was just a reminder for myself when going
through the code.
I'm perfectly fine not applying that one for now and just forgetting it.

A real fix would be a guest that does not insist on all the features and
would boot up just fine (I haven't found kernel parameters to do so and
building an extra guest for that seems over-engineering).


> ERR: potential race on the check of lxc log after start
> > FIX: lacking a better fix a sleep and sync to closen the remaining
> > race window
>
> Hmm...did you see this? If so we should rather check for running again
> with virsh and then check the log.
>

No I haven't seen it in this test, but I had an almost equal test a while
ago (start, check for running) which worked on x86.
But then when the tests spread to other architectures it sometimes failed
on ppc64el and almost always on s390x.

We could convert it to a retry loop that does
while ! check-running
   sleep
   if > retry FAIL

The same would probably apply



-- 
Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd

Bug#750138: Info received (Bug#750138: scap-workbench)

[Petter Reinholdtsen]

Very good to hear from you.  :)

[Frank lin Piat]
> What about collab-maint ?

Works for me.  But it is a decision I believe is best left to the
package maintainer, so it is up to you. :)

> There are a few more lintian info/warning to fix. I would fix later.
> I: scap-workbench source: unused-license-paragraph-in-dep5-copyright
> expat (paragraph at line 56)I: scap-workbench:
> spelling-error-in-binary usr/bin/scap-workbench Allows to Allows one
> toI: scap-workbench: hardening-no-bindnow usr/bin/scap-workbenchW:
> scap-workbench: extra- license-file
> usr/share/doc/scap-workbench/COPYING.gzI: scap-workbench:
> desktop-entry-lacks-keywords-entry usr/share/applications/scap-
> workbench.desktop

Aha.  Do you want to fix them before the next upload?
-- 
Happy hacking
Petter Reinholdtsen

Bug#848306: should stop distributing rpc.svcgssd

[Daniel Pocock]

Package: nfs-common
Version: 1:1.3.4-1
Severity: important

Upstream no longer encourages the use of rpc.svcgssd and encourages use
of gssproxy instead

Need to remove it from the configure flags in debian/rules

Users should migrate to gssproxy

The nfs-utils packages should add appropriate suggests or recommends
dependencies for gssproxy

Bug#848305: mongodb: Add missing changelog entry for 1:2.6.12-3

[Salvatore Bonaccorso]

Source: mongodb
Version: 1:3.2.11-2
Severity: wishlist
Tags: patch

Hi Apollon, hi Laszlo

Please consider adding back the debian/changelog entry for 1:2.6.12-3
which contained the reference for the CVE fix. Patch attached.

Thanks lot for considering. If you disagree, please close and mark as
wontfix.

Regards,
Salvatore

p.s.: the kernel team does similar, once a stable update say 4.8.11 is
  released, and the preparation for 4.9 is done in experimental, the
  sid branch is merged into the master branch and so keeping
  debian/changelog consistent back. Example:
  
https://anonscm.debian.org/cgit/kernel/linux.git/commit/?id=878978046681f8bff7396fe459e288b2a3d8e794

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

Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
>From fba77262b606db2497babaeacd68bf91fa6dd2dc Mon Sep 17 00:00:00 2001
From: Salvatore Bonaccorso 
Date: Fri, 16 Dec 2016 06:37:13 +0100
Subject: [PATCH] Add missing changelog entry for 1:2.6.12-3

---
 debian/changelog | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/debian/changelog b/debian/changelog
index c5d895cf..7de8dd18 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -81,6 +81,13 @@ mongodb (1:3.2.8-1) experimental; urgency=medium
 
  -- Apollon Oikonomopoulos   Thu, 14 Jul 2016 16:42:32 +0300
 
+mongodb (1:2.6.12-3) unstable; urgency=high
+
+  * Fix CVE-2016-6494 , prevent group and other access to .dbshell
+(closes: #832908).
+
+ -- Laszlo Boszormenyi (GCS)   Mon, 08 Aug 2016 21:56:32 +
+
 mongodb (1:2.6.12-2) unstable; urgency=medium
 
   * Do not use tcmalloc on ppc64el (fixes FTBFS on ppc64el).
-- 
2.11.0

Bug#760916: brltty interferes with getty autostart

[Dave Mielke]

[quoted lines by Michael Biebl on 2016/12/16 at 05:59 +0100]

>could you give me an update on this issue? Is this still an issue?

No, it isn't. It was fixed almost exactly a year ago. The fix is in brltty 5.4 
for sure.

-- 
Dave Mielke   | 2213 Fox Crescent | The Bible is the very Word of God.
Phone: 1-613-726-0014 | Ottawa, Ontario   | http://Mielke.cc/bible/
EMail: d...@mielke.cc | Canada  K2A 1H7   | http://FamilyRadio.org/

Bug#845187: systemd: pressing ctrl-alt-delete repeatedly to force immediate reboot leads to systemd getting stuck with something

[Michael Biebl]

Control: tags -1 + moreinfo

On Mon, 21 Nov 2016 10:07:53 +0100 Martin Steigerwald
 wrote:
> Package: systemd
> Version: 232-5
> Severity: normal
> 
> Dear Martin, dear Michael, dear Maintainers-
> 
> I noticed by pressing Ctrl-Alt-Delete repeatedly quickly at the 90 seconds
> timeout for stopping a service that didn´t seem to agree with being stopped
> at shutdown that systemd did initiate an immediate reboot.
> 
> This does no longer work. Systemd still says it triggers an immediate reboot
> but then seems to be stuck. I waited for a while but there was not output.
> 
> I could let it sit for a little more and also provide a screenshot of what
> is displayed on screen, what I have seen so far didn´t give me a hint what is
> getting stuck there.
> 
> Maybe there is some debugging stuff I can activate before doing so? If so,
> can I also tell systemd to store the debugging stuff in a while before
> actually shutting down the laptop? Otherwise important information may have
> been scrolled out of the visible screen already.
> 

Is this problem reproducible?
Hitting ctrl+alt+del 7times quickly in a row does reliably reboot here.



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



signature.asc
Description: OpenPGP digital signature

Bug#816876: systemd: bootsched fails after systemd is installed resumes working after systemd is removed

[Michael Biebl]

Control: tags -1 + moreinfo

On Sat, 05 Mar 2016 22:16:43 -0700 jda2000  wrote:
> Source: systemd
> Severity: normal
> 
> Dear Maintainer,
> 
> In the course of an update from Debian 7 to Debian 8 on a color iMac sytemd 
> replaced sysv style init.
> Subsequently, bootsched from powerpc-utils stopped working.  It would run and 
> return 0 status but
> the system would not power-on at the appointed time.
> 
> Following the instructions found here:
>   https://ispire.me/downgrade-from-debian-sid-to-stable-from-jessie-to-wheezy/
> sysvinit was re-installed and systemd removed:
> 
> apt-get install sysvinit-core sysvinit sysvinit-utils
> (reboot)
> apt-get remove --purge --auto-remove systemd
> 
> During this process a message flashed by saying that a supernode(?) had a 
> future date
> probably due to an invalid hardware clock setting and the notation "FIXED"
> 
> On a hunch, I skipped the rest of the roll-back and retested /sbin/bootshed
> That test and a few subsequent all worked. 
> 
> and earlier attempt to fix the problem with:
> 
> # hwclock --set --date "$(date)"
> 
> had not worked.
> 
> I'm staying on Debian 8 since /sbin/bootsched is working.
> 
> I submit this report to document the work-around in case there are other 
> color iMacs out there still.
> 
> -- System Information:
> Debian Release: 8.3
>   APT prefers stable
>   APT policy: (500, 'stable')
> Architecture: powerpc (ppc)
> 
> Kernel: Linux 3.16.0-4-powerpc
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: sysvinit (via /sbin/init)


Can you be more clear what the bug in systemd is supposed to be?

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



signature.asc
Description: OpenPGP digital signature

Bug#783618: systemd: journald ignores MaxLevelKMsg=warning

[Michael Biebl]

Control: tags -1 + moreinfo

On Tue, 28 Apr 2015 14:36:26 +0200 Alexander Wuerstlein
 wrote:
> Package: systemd
> Version: 215-17
> Severity: normal
> 
> Dear Maintainer,
> 
>* After noticing that journald fills dmesg with irrelevant messages
>  such as:
> > syslog:info  : [2730378.422878] systemd-journald[4060]: Deleted empty 
> > journal 
> > /var/log/journal/c2544241fd44405fba80ed9cf7fe0f29/user-31146@c21ba3b937144879a1feba0ae91775ae--.journal
> >  (8388608 bytes).
>* I read the documentation and tried to suppress those messages
>  (since they are loglevel info) by adding MaxLevelKMsg=warning to
>  journald.conf 
>* I would have expected said messages to be no longer logged to
>  dmesg/kmsg.
>* Yet those messages still appear in dmesg.

I think this is fixed in newer systemd versions.

Can you please try to reproduce the problem with systemd v232 from
unstable/stretch.

Thanks,
Michael

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



signature.asc
Description: OpenPGP digital signature

Bug#760916: brltty interferes with getty autostart

[Michael Biebl]

On Wed, 21 Jan 2015 18:56:42 -0500 Dave Mielke  wrote:
> [quoted lines by Samuel Thibault on 2015/01/22 at 00:46 +0100]
> 
> >Reading is fine, since it's done through /dev/vcsa, which doesn't count
> >in VT_GETSTATE.
> 
> Not exactly. The tty device still needs to be opened in order to do things 
> like 
> fetch the Unicode map.
> 
> It's possible, of course, that things like the Unicode map, the screen font 
> map, the character translation table, etc are common to all vts, in which 
> case 
> they could be fetched from tty1. I'm not familiar enough with the internals 
> to 
> know for sure.
> 
> I noticed a comment in the source for systemd-logind stating that tty1 is 
> special, so using it would seem to be okay. We still need to be sure that all 
> of what we need for mapping the font positions returned by the vcs devices 
> back 
> to the original characters is common to all ttys so that fetching them from 
> tty1 would be valid for other ttys.

Hi Samuel, hi Dave,

could you give me an update on this issue? Is this still an issue?

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



signature.asc
Description: OpenPGP digital signature

Bug#755674: systemd-sysv: unmounting bind mounts takes age (due to recursion?)

[Michael Biebl]

Version: 228-1

On Sat, 6 Feb 2016 23:57:15 +0100 Samuel Thibault 
wrote:
> Michael Biebl, on Sat 30 Jan 2016 20:36:19 +0100, wrote:
> > v208 is rather old. Could you please try if you can reproduce the issue
> > with v228 from unstable/testing.
> 
> Using 228, reproducing the issue with a few mounts as described,
> yielding to 2400 lines in /proc/mounts , shutdown takes a couple dozens
> of seconds. That's bearable.
> 

Ok, thanks for the feedback.

Closing the bug report accordingly.


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



signature.asc
Description: OpenPGP digital signature

Bug#845685: neovim-qt: FTBFS on kFreeBSD: tst_neovimconnector fails

[James McCoy]

On Thu, Dec 15, 2016 at 11:03:40PM -0500, Aaron M. Ucko wrote:
> James McCoy  writes:
> 
> > As far as I can tell, what's happening is the async network connection
> > that's started by the connectToNeovim call has already errored out by
> > the time the onError SPY is created.  The test then times out waiting
> > for the error to occur.
> 
> That's an unfortunate design.  Perhaps you could compensate by
> conditionalizing the SPYWAIT line on
> 
>   c->errorCause() != NeovimConnector::NoError

Looks like that does help.  The code is still racy, but that does get
the test to pass.

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Bug#827438: systemd: boot fails with rootfs on luks after systemd upgrade

[Michael Biebl]

Control: tags -1 + moreinfo

On Thu, 16 Jun 2016 08:39:53 +0200 Sander van Grieken
 wrote:
> Package: systemd
> Version: 229-6
> Severity: important
> 
> Upgrading systemd from 229-6 to 230-2 broke my boot.
> 
> I have a LUKS rootfs on top of a mdadm managed raid0. Starting from 230-2 it
> doesn't recognize the luks volume at boot.
> 
> The raid0 is not explicitly made with mdadm, it was previously handled by
> dmraid I believe (fakeraid?)
> 
> I'm using dracut-40 instead of initramfs
> (yes there's a newer dracut, but that has troubles with booting this setup 
> too,
> so I've pinned on 040)
> 

So, does it already fail during initramfs or actually later, during
regular boot? Failing to find the rootfs sounds like an initramfs
problem, so in this case it should probably be reassigned to dracut.

Michael

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



signature.asc
Description: OpenPGP digital signature

Bug#816384: systemd: Systemd tries to rename ppp interface when .link files present for existing NICs

[Michael Biebl]

Control: tags -1 + moreinfo

Hi

On Tue, 01 Mar 2016 15:45:01 +0300 Vladimir Kudrya  wrote:
> Dear Maintainer, when .link files are in place in /etc/systemd/network to 
> rename
> NICs based on MAC addresses, systemd tries to rename ppp0 link which is being
> created by NetworkManager. This results in failure to establish PPTP 
> connection.
> 
> $ cat /etc/systemd/network/10-eth0.link
> [Match]
> MACAddress="xx:xx:xx:xx:xx:xx"
> [Link]
> Name=eth0
> 
> $ cat /etc/systemd/network/10-wlan0.link
> [Match]
> MACAddress="yy:yy:yy:yy:yy:yy"
> [Link]
> Name=wlan0
> 
> Nothing here can possibly be related to any ppp iface. But here is the journal
> while trying to establish PPTP via NetworkManager. "ppp0" is being renamed to 
> "rename13"
> when these files are in place. It does not happen when they are not.

ppp0 being renamed to rename13 sounds suspiciously like the old network
interface naming is still being used.
Can you attach your /etc/udev/rules.d/70-persistent-net.rules if present


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



signature.asc
Description: OpenPGP digital signature

Bug#848275: [Pkg-samba-maint] cifs-utils_2%3a6.6-2_amd64.deb broken postinst

[Mathieu Parent]

) is Please do "reply to all".


2016-12-16 2:06 GMT+01:00 Gianluca Alloisio :
> Here you go:
>
> $ LC_ALL=en dpkg -S /usr/lib/*/cifs-utils/idmapwb.so
> cifs-utils: /usr/lib/x86_64-linux-gnu/cifs-utils/idmapwb.so
> dpkg-query: no path found matching pattern
> /usr/lib/x86-linux-gnu/cifs-utils/idmapwb.so
> 1

This second file (/usr/lib/x86-linux-gnu/cifs-utils/idmapwb.sonot known by dpkg.
it looks like it was installed without dpkg, or your dpkg db was
replaced/corrupted/...

Anyway, the new upload of cifs-utils removes the wildcard in postinst,
so it'll be fixed for you too.

Regards

-- 
Mathieu

Bug#620105: gliv: Segmentation fault not while loading an image

[Celejar]

Package: gliv
Version: 1.9.7-2
Followup-For: Bug #620105

I'm also getting segfaults when opening gliv on a certain directory:

$ gliv /media/wd-storage/images/
/media/wd-storage/images/VID_20160830_201544309.mp4: unknown extension
/media/wd-storage/images/VID_20161121_083651899.mp4: unknown extension
/media/wd-storage/images/VID_20161020_130906695.mp4: unknown extension
/media/wd-storage/images/VID_20161020_124222333.mp4: unknown extension
/media/wd-storage/images/VID_20161020_124658707.mp4: unknown extension
/media/wd-storage/images/VID_20161117_194524695.mp4: unknown extension
/media/wd-storage/images/VID_20161007_133446359.mp4: unknown extension
/media/wd-storage/images/VID_20161117_194549577.mp4: unknown extension
/media/wd-storage/images/VID_20160916_132902300.mp4: unknown extension
/media/wd-storage/images/VID_20160927_180455254.mp4: unknown extension
/media/wd-storage/images/VID_20161020_123225413.mp4: unknown extension
/media/wd-storage/images/VID_20161014_165823281.mp4: unknown extension
/media/wd-storage/images/VID_20161010_132201604.mp4: unknown extension
/media/wd-storage/images/VID_20160916_133842020.mp4: unknown extension
/media/wd-storage/images/VID_20160927_180516577.mp4: unknown extension
Segmentation fault not while loading an image
Segmentation fault

-- 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.14-lila (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 gliv depends on:
ii  libc6 2.19-18+deb8u6
ii  libgdk-pixbuf2.0-02.31.1-2+deb8u5
ii  libgl1-mesa-glx [libgl1]  10.3.2-1+deb8u1
ii  libglib2.0-0  2.42.1-1+b1
ii  libglu1-mesa [libglu1]9.0.0-2
ii  libgtk2.0-0   2.24.25-3+deb8u1
ii  libgtkglext1  1.2.0-3.2
ii  libpango1.0-0 1.36.8-3
ii  libx11-6  2:1.6.2-3

gliv recommends no packages.

gliv suggests no packages.

-- no debconf information

Bug#845685: neovim-qt: FTBFS on kFreeBSD: tst_neovimconnector fails

[Aaron M. Ucko]

James McCoy  writes:

> As far as I can tell, what's happening is the async network connection
> that's started by the connectToNeovim call has already errored out by
> the time the onError SPY is created.  The test then times out waiting
> for the error to occur.

That's an unfortunate design.  Perhaps you could compensate by
conditionalizing the SPYWAIT line on

  c->errorCause() != NeovimConnector::NoError

?

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

Bug#847136: emdebian-archive-keyring: cannot upgrade - gpg: no valid OpenPGP data found.

[Wookey]

I'm very confused about this bug. Having read this, and 846892 and
844724 I still don't know what the correct gpg magic rune to use is.

Currently emdebian-archive-keyring.gpg is created with:
gpg --no-permission-warning -q --homedir . --no-default-keyring \
--keyring ./emdebian-archive-keyring.gpg --import 1804772E.txt

If I understand right that makes a .gpg file in the "binary OpenPGP
format" keyring that apt-key understands in stable, but makes a
'keybox' format keyring (that apt-key doesn't understand) in unstable. Right?

Is there a gpg rune to check what format is in use?

Do I have to give apt-key a key or a keyring? Does it matter?

the key 1804772E.txt is in the form "PGP public key block Public-Key
(old)" according to file. Maybe it doesn't actually need transforming at all?

I can put it into a keyring as above and then export from that keyring to a key
with 
gpg2 --export --keyring ./emdebian-archive-keyring.gpg --no-default-keyring  > 
emdebian-archive-keyring.asc

but so far as I understand things that creates a key, not a
keyring. And it's two steps, rather than one.

The SUPPORTED KEYRING FILES section says:
Binary keyring files intended to be used with any apt version should therefore 
always be created with --export

but so far as I can see --export doesn't create a keyring, it just
creates a key. and AIUI apt-key wants a keyring (.gpg), not a key.

I am clearly confused about how this is supposed to work. 

All I really want to know is 'what is the rune to get 1804772E.txt
into the right format to to go in /etc/apt/trusted.gpg.d', and 'what
should it be called?'

I guess I can work this out by trial and error, but it would be good
to be sure I was doing the right thing.

Wookey
-- 
Principal hats:  Linaro, Debian, Wookware, ARM
http://wookware.org/


signature.asc
Description: Digital signature

Bug#848304: Installation report for Stretch on cubietruck (armhf)

[John Kerenyi]

Package: installation-reports

Boot method: Debian installer on sd card, using Cubietruck firmware + 
partition.img
Image version: 
http://ftp.uk.debian.org/debian/dists/stretch/main/installer-armhf/current/images/netboot/SD-card-images/
Date: 2016-12-15 7:00 PM Pacific standard time

Machine: Cubietruck (Allwinner)
Processor: ARMv7 Processor rev 4 (v7l)
Memory: 2061944 kB
Partitions: Installation didn't complete this step

Output of lspci -knn (or lspci -nn): None (shelled out from installer and this 
produced no output)

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

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

Comments/Problems:

Installing Stretch using current (dated 31 Oct 2016) firmware and net installer 
does not complete. The following error is encountered during the install:

"No kernel modules were found. This probably is due to a mismatch between the kernel 
used by this version of the installer and the kernel version available in the archive. If 
you're installing from a mirror, you can work around this problem by choosing to install 
a different version of Debian. The install will probably fail to work if you continue 
without kernel modules. Continue the install without loading kernel modules?"

Selecting "Yes" causes the installation to fail at the disk partitioning step, 
apparently due to the lack of an appropriate kernel module. I have the three files made 
available for debugging by the installer: hardware-summary.txt, syslog.txt, and 
partman.txt and can share them upon request.

Under the theory that waiting a while might allow the repository and the kernel 
to sync, I attempted the installation multiple times over the course of several 
weeks and never got a different result, hence this installation report. I also 
tried prior versions of the installer as well as the stable version (Jessie) 
and none that I tried completed successfully.

In the past I have successfully installed Debian on the Cubietruck using the sd 
card method, as well as other ARM devices; so I am experienced in this 
installation process.

Bug#848303: electrum: Transactions not accepted by network

[Luca Venturini]

Package: electrum
Version: 1.9.8-4~bpo70+1
Severity: important

Dear Maintainer,

the sending transactions are not recognized by the network.

If you try to send a bitcoin transaction, you get the following error:

Your client produced a transaction that is not accepted by the network 
any more.  Please upgrade to Electrum 2.5.1 or newer.


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

Kernel: Linux 3.16.0-0.bpo.4-amd64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash

Versions of packages electrum depends on:
ii  python   2.7.3-4+deb7u1
ii  python-electrum  1.9.8-4~bpo70+1

electrum recommends no packages.

electrum suggests no packages.

-- no debconf information

Bug#848251: slop: missing list indent in package description

[Antoine Beaupré]

Control: tags -1 +pending +patch

Thanks for the bug report, since the change is minor, it will be shipped
only when other changes warrant a new upload.

See if the patch is correct here:

https://anonscm.debian.org/git/collab-maint/slop.git/commit/?id=ce0f81cffc723fddeba2704279c25ef9f4f6c629

A.

-- 
What this country needs is more unemployed politicians.
- Angela Davis

Bug#588434: libpam-ldap: unable to change password in default configuration

[Evan King]

Some details I neglected to mention:

 - Whether pam_encryptfs is installed/configured has no effect.
 - My /etc/nsswitch.conf file is almost identical:

passwd: files ldap
group:  files ldap
shadow: files ldap
+gshadow:files

hosts:  files dns
networks:   files

protocols:  db files
services:   db files
ethers: db files
rpc:db files

netgroup:   nis

The gshadow line is additional on the bad host, but removing it (or 
adding it to the good host) has no effect.


Differences in packages installed related to ldap:

root@goodhost:/etc/pam.d# apt search ldap | grep installed
auth-client-config/xenial,xenial,now 0.9ubuntu1 all [installed,automatic]
curl/xenial-updates,xenial-security,now 7.47.0-1ubuntu2.2 amd64 [installed]
+dovecot-ldap/xenial-updates,now 1:2.2.22-1ubuntu2.2 amd64 [installed]
ldap-auth-client/xenial,xenial,now 0.5.3 all [installed]
ldap-auth-config/xenial,xenial,now 0.5.3 all [installed]
ldap-utils/xenial-updates,now 2.4.42+dfsg-2ubuntu3.1 amd64 [installed]
+libaprutil1-ldap/xenial,now 1.5.4-1build1 amd64 [installed,automatic]
+libcurl3/xenial-updates,xenial-security,now 7.47.0-1ubuntu2.2 amd64 
[installed,automatic]
libcurl3-gnutls/xenial-updates,xenial-security,now 7.47.0-1ubuntu2.2 
amd64 [installed]

libldap-2.4-2/xenial-updates,now 2.4.42+dfsg-2ubuntu3.1 amd64 [installed]
libldb1/xenial,now 2:1.1.24-1ubuntu3 amd64 [installed]
libnss-ldap/xenial,now 265-3ubuntu2 amd64 [installed]
libpam-ldap/xenial,now 184-8.7ubuntu1 amd64 [installed]
+libsasl2-modules-ldap/xenial,now 2.1.26.dfsg1-14build1 amd64 [installed]
+monit/xenial,now 1:5.16-2 amd64 [installed]
+php5-ldap/now 5.5.9+dfsg-1ubuntu4.20 amd64 [installed,local]
+postfix-ldap/xenial,now 3.1.0-3 amd64 [installed]
+python-ldap/xenial,now 2.4.22-0.1 amd64 [installed]
python-ldb/xenial,now 2:1.1.24-1ubuntu3 amd64 [installed]
sudo/xenial-updates,now 1.8.16-0ubuntu1.2 amd64 [installed]

root@badhost:/etc/pam.d# apt search ldap | grep installed
auth-client-config/xenial,now 0.9ubuntu1 all [installed,automatic]
curl/xenial-security,xenial-updates,now 7.47.0-1ubuntu2.2 amd64 
[installed,automatic]

ldap-auth-client/xenial,now 0.5.3 all [installed,automatic]
ldap-auth-config/xenial,now 0.5.3 all [installed,automatic]
ldap-utils/xenial-updates,now 2.4.42+dfsg-2ubuntu3.1 amd64 [installed]
libcurl3-gnutls/xenial-security,xenial-updates,now 7.47.0-1ubuntu2.2 
amd64 [installed,automatic]
libldap-2.4-2/xenial-updates,now 2.4.42+dfsg-2ubuntu3.1 amd64 
[installed,automatic]

libldb1/xenial,now 2:1.1.24-1ubuntu3 amd64 [installed,automatic]
libnet-ldap-perl/xenial,now 1:0.6500+dfsg-1 all [installed,automatic]
libnss-ldap/xenial,now 265-3ubuntu2 amd64 [installed]
libpam-ldap/xenial,now 184-8.7ubuntu1 amd64 [installed]
libslp1/xenial,now 1.2.1-11 amd64 [installed,automatic]
python-ldb/xenial,now 2:1.1.24-1ubuntu3 amd64 [installed,automatic]
+slapd/xenial-updates,now 2.4.42+dfsg-2ubuntu3.1 amd64 [installed]
+slapd-smbk5pwd/xenial-updates,now 2.4.42+dfsg-2ubuntu3.1 amd64 [installed]
sudo/xenial-updates,now 1.8.16-0ubuntu1.2 amd64 [installed]

I toyed with the possibility that sasl might be the missing piece to no 
avail.  Frankly I hope it's not.


Cheers,
 - Evan

Bug#847458: RFS: clues-emacs/0~2014.09.23.69d873c-1 ITP

[Dmitry Bogatov]

[2016-12-14 15:51] Sean Whitton 
>
> part 1 text/plain 441
> On Wed, Dec 14, 2016 at 05:06:39AM +0300, Dmitry Bogatov wrote:
> > I received reply from upstream, so now version is oficially 1.0.0.  One
> > more review, please.
>
> You need `dch -r`.  Otherwise, cab58bc0530e73165bf01d66a37966d08ca26280
> LGTM.

I upgraded to next upstream version (purely cosmetic) 1.0.1 and made dch -r.

-- 
X-Web-Site: https://sinsekvu.github.io | Note that I process my email in batch,
Accept-Languages: eo,ru,en | at most once every 24 hours. If matter
Accept: text/plain, text/x-diff| is urgent, you have my phone number.


pgpDSXPV0Y3yN.pgp
Description: PGP signature

Bug#588434: Subject: libpam-ldap: unable to change password in default configuration

[Evan King]

I can confirm that either removing use_authtok or installing 
libpam-cracklib bypasses the issue, but also that there is a third fix 
which does not involve:
 - adding a dependency that introduces unrelated (possibly unwanted) 
features

 - breaking the functionality intended by including use_authtok
 - maintaining a hack to override the package-supplied configuration

I don't know exactly what that fix is, only that it exists, because I 
have two Ubuntu 16.04 machines, one of which exhibits this problem and 
the other does not.


In the interest of discovering this fix, I've determined the following:

They both have an identical set of libpam modules installed and 
identically configured:


root@host:~# apt search libpam | grep installed
libpam-cap/xenial,now 1:2.24-12 amd64 [installed]
libpam-ldap/xenial,now 184-8.7ubuntu1 amd64 [installed]
libpam-modules/xenial,now 1.1.8-3.2ubuntu2 amd64 [installed]
libpam-modules-bin/xenial,now 1.1.8-3.2ubuntu2 amd64 [installed]
libpam-mount/xenial,now 2.14-1.1 amd64 [installed]
libpam-runtime/xenial,now 1.1.8-3.2ubuntu2 all [installed]
libpam-systemd/xenial-updates,now 229-4ubuntu13 amd64 [installed,automatic]
libpam0g/xenial,now 1.1.8-3.2ubuntu2 amd64 [installed]

There are some different service-specific configurations added, but 
every file that appears in both of these ls outputs is identical:


root@goodhost:/etc/pam.d# ll
total 104K
-rw-r--r-- 1 root root  258 2016-01-14 18:35:17 atd
-rw-r--r-- 1 root root  384 2010-01-26 13:01:31 chfn
-rw-r--r-- 1 root root   92 2010-01-26 13:01:31 chpasswd
-rw-r--r-- 1 root root  581 2010-01-26 13:01:31 chsh
-rw-r--r-- 1 root root 1.3K 2016-12-15 15:44:53 common-account
-rw-r--r-- 1 root root 1.4K 2016-12-15 15:44:53 common-auth
-rw-r--r-- 1 root root   70 2010-07-31 01:52:24 common-pammount
-rw-r--r-- 1 root root 1.6K 2016-12-15 18:16:36 common-password
-rw-r--r-- 1 root root 1.6K 2016-12-15 15:44:54 common-session
-rw-r--r-- 1 root root 1.5K 2016-12-15 15:44:54 
common-session-noninteractive

-rw-r--r-- 1 root root  606 2016-04-05 18:59:02 cron
-rw-r--r-- 1 root root   81 2010-04-19 14:18:56 dovecot
-rw-r--r-- 1 root root 4.8K 2016-01-29 21:21:30 login
-rw-r--r-- 1 root root  100 2011-12-21 12:13:38 monit
-rw-r--r-- 1 root root   92 2010-01-26 13:01:31 newusers
-rw-r--r-- 1 root root  520 2010-04-13 19:01:47 other
-rw-r--r-- 1 root root   92 2010-01-26 13:01:31 passwd
-rw-r--r-- 1 root root  255 2014-02-11 14:45:25 polkit-1
-rw-r--r-- 1 root root  143 2016-03-12 11:14:57 runuser
-rw-r--r-- 1 root root  138 2016-03-12 11:14:57 runuser-l
-rw-r--r-- 1 root root   84 2010-03-19 18:16:58 samba
-rw-r--r-- 1 root root 2.1K 2016-08-11 13:25:09 sshd
-rw-r--r-- 1 root root 2.3K 2015-11-12 18:12:32 su
-rw-r--r-- 1 root root  239 2016-08-17 10:20:48 sudo
-rw-r--r-- 1 root root  251 2016-10-26 10:04:44 systemd-user


root@badhost:/etc/pam.d# ll
total 85K
-rw-r--r-- 1 root root  258 2016-01-14 18:35:17 atd
-rw-r--r-- 1 root root  384 2015-11-12 18:12:32 chfn
-rw-r--r-- 1 root root   92 2015-11-12 18:12:32 chpasswd
-rw-r--r-- 1 root root  581 2015-11-12 18:12:32 chsh
-rw-r--r-- 1 root root 1.3K 2016-12-15 21:36:41 common-account
-rw-r--r-- 1 root root 1.4K 2016-12-15 21:36:41 common-auth
-rw-r- 1 root root   70 2016-12-15 15:31:07 common-pammount
-rw-r--r-- 1 root root 1.6K 2016-12-15 21:36:41 common-password
-rw-r--r-- 1 root root 1.6K 2016-12-15 21:36:41 common-session
-rw-r--r-- 1 root root 1.5K 2016-12-15 21:36:41 
common-session-noninteractive

-rw-r--r-- 1 root root  606 2016-04-05 18:59:02 cron
-rw-r--r-- 1 root root 4.8K 2016-01-29 21:21:30 login
-rw-r--r-- 1 root root  145 2016-12-09 03:43:43 mysql
-rw-r--r-- 1 root root   92 2015-11-12 18:12:32 newusers
-rw-r--r-- 1 root root  520 2016-03-16 15:09:13 other
-rw-r--r-- 1 root root   92 2015-11-12 18:12:32 passwd
-rw-r--r-- 1 root root  255 2016-01-17 19:13:21 polkit-1
-rw-r--r-- 1 root root  143 2016-03-12 11:14:57 runuser
-rw-r--r-- 1 root root  138 2016-03-12 11:14:57 runuser-l
-rw-r--r-- 1 root root   84 2016-03-07 21:23:05 samba
-rw-r--r-- 1 root root 2.1K 2016-04-28 05:52:36 sshd
-rw-r--r-- 1 root root 2.3K 2015-11-12 18:12:32 su
-rw-r--r-- 1 root root  239 2016-03-30 16:57:11 sudo
-rw-r--r-- 1 root root  251 2016-04-12 07:34:03 systemd-user
-rw-r--r-- 1 root root   55 2016-04-15 07:04:33 vmtoolsd

At this point I'm out of ideas on how to identify the difference that 
stops use_authtok from breaking passwd, but very interested in doing so.


Cheers,
 - Evan

Bug#848121: [Pkg-sysvinit-devel] Bug#848121: File conflict between manpages and initscripts

[Michael Biebl]

On Thu, 15 Dec 2016 11:10:18 -0200 Henrique de Moraes Holschuh
 wrote:
> On Wed, 14 Dec 2016, Ian Jackson wrote:
> > Michael Kerrisk (man-pages) writes ("Re: Bug#848121: [Pkg-sysvinit-devel] 
> > File conflict between manpages and initscripts"):
> > > On 14 December 2016 at 16:45, Ian Jackson
> > >  wrote:
> > > >  - rename the manpage about /etc/default/tmpfs to tmnfs-config(5)
> > > >(or something, better name welcome).
> > > 
> > > FWIW, I think this may be the best option.
> > 
> > I do see that the arguments against changing all the filesystem
> > manpages are pretty strong.
> > 
> > It's not quite clear to me quite who the maintainers of the sysvinit
> > package are - ie, who needs to agree.  I have been following the
> 
> Consider this a vote for the use of tmpfs-config(5) in initscripts,
> since tmpfs(5) will require "apropos tmpfs" anyway to find it.

tmpfs-config(5) sounds like an acceptable name to me. So if this is
considered a vote, here is a +1 from me :-)

> Actually, in hindsight, that /etc/default/tmpfs config file was a bad
> idea.  It should have always been "either override in /etc/fstab or
> stick with the defaults".

I agree here as well. But that's water unter the bridge.

For anyone making the change in initscripts to rename the man page,
please also make sure to rename the reference in /etc/default/tmpfs,
which currently contains

# Configuration for tmpfs filesystems mounted in early boot, before
# filesystems from /etc/fstab are mounted.  For information about
# these variables see the tmpfs(5) manual page.





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



signature.asc
Description: OpenPGP digital signature

Bug#845685: neovim-qt: FTBFS on kFreeBSD: tst_neovimconnector fails

[James McCoy]

On Fri, Nov 25, 2016 at 03:24:23PM -0500, Aaron M. Ucko wrote:
> The kFreeBSD build of neovim-qt failed:
> 
> Start  2: tst_neovimconnector
>2/12 Test  #2: tst_neovimconnector ..***Failed   15.12 sec
>   * Start testing of NeovimQt::Test *
>   Config: Using QtTest library 5.7.1, Qt 5.7.1 (x86_64-little_endian-lp64 
> shared (dynamic) release build; by GCC 6.2.0 20161109)
>   PASS   : NeovimQt::Test::initTestCase()
>   QWARN  : NeovimQt::Test::reconnect() MsgpackIO fatal error "IO device needs 
> to be sequential"
>   PASS   : NeovimQt::Test::reconnect()
>   QDEBUG : NeovimQt::Test::isReady() Unknown Neovim function "Array 
> vim_get_api_info()"
>   QDEBUG : NeovimQt::Test::isReady() Unknown Neovim function "Array 
> vim_get_api_info()"
>   QDEBUG : NeovimQt::Test::isReady() Unknown Neovim function "Array 
> vim_get_api_info()"
>   PASS   : NeovimQt::Test::isReady()
>   QWARN  : NeovimQt::Test::encodeDecode() Encoding String into 
> MsgpackIODevice without an encoding (defaulting to utf8)
>   QWARN  : NeovimQt::Test::encodeDecode() Decoding String from 
> MsgpackIODevice without an encoding (defaulting to utf8)
>   QDEBUG : NeovimQt::Test::encodeDecode() Unknown Neovim function "Array 
> vim_get_api_info()"
>   PASS   : NeovimQt::Test::encodeDecode()
>   FAIL!  : NeovimQt::Test::connectToNeovimTCP() 'SPYWAIT(onError)' returned 
> FALSE. ()
>  Loc: [/«PKGBUILDDIR»/test/tst_neovimconnector.cpp(62)]

I did look into this, and have an idea of what the problem is.  However,
I'm not sure what the right way to fix it is.

The test in question is:

void connectToNeovimTCP() {
// These 2 cases WILL FAIL because there is no Neovim instance 
running
NeovimConnector *c = 
NeovimConnector::connectToNeovim("127.0.0.1:64999");
QCOMPARE(c->connectionType(), NeovimConnector::HostConnection);
QSignalSpy onError(c, SIGNAL(error(NeovimError)));
QVERIFY(onError.isValid());
QVERIFY(SPYWAIT(onError));

QCOMPARE(c->errorCause(), NeovimConnector::SocketError);
c->deleteLater();
}

As far as I can tell, what's happening is the async network connection
that's started by the connectToNeovim call has already errored out by
the time the onError SPY is created.  The test then times out waiting
for the error to occur.

I've mentioned this to upstream, but they haven't been very active
lately.

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Bug#847806: libopenmpi2: broken SONAME links

[Andreas Beckmann]

Followup-For: Bug #847806
Control: found -1 2.0.2~git.20161225-5

This is not yet fixed. This is not a duplicate of #837525.


Andreas

Bug#848302: global: FTBFS on hurd

[Wookey]

Package: global
Version: 6.5.5-1
Severity: normal

Saving this as a bug to avoid it getting forgotten.

Wookey noted:
global fails to build on hurd:
https://buildd.debian.org/status/fetch.php?pkg=global=hurd-i386=6.5.5-1=1481673154

Punit replied:
This one has interesting back story - there has been a patch for this
issue after v6.4. See below -

% cvs diff -r 1.104 -r 1.105 find.c
Index: find.c
===
RCS file: /sources/global/global/libutil/find.c,v
retrieving revision 1.104
retrieving revision 1.105
diff -r1.104 -r1.105
3c3,4
<  *2009, 2011, 2012, 2014, 2015 Tama Communications Corporation
---
>  *2009, 2011, 2012, 2014, 2015, 2016
>  * Tama Communications Corporation
81c82,86
<
---
> #ifndef PATH_MAX
> #error Since this platform does not have PATH_MAX, you should define it
> #error using an appropriate value for the platform.
> /* #define PATH_MAX 1024 */
> #endif

Further investigation led me to [0][1]. I am tempted to un-comment the
#define as a temporary fix. A proper fix will need re-writing PATH_MAX
usage upstream.

[0] https://www.gnu.org/software/hurd/community/gsoc/project_ideas/maxpath.html
[1] https://www.gnu.org/software/hurd/hurd/porting/guidelines.html
(Search for PATH_MAX)

Bug#848100: neovim-qt: Please install as alternative for "gvim"

[James McCoy]

On Wed, Dec 14, 2016 at 07:25:11AM +0100, Ph. Marek wrote:
> Please install a gvim alternative:
> # update-alternatives --install /usr/bin/gvim gvim /usr/bin/nvim-qt 50

Sounds reasonable.  jpleau is looking into that.

> BTW, the initial size of the nvim-qt window is ~9 by 4 characters for me... 
> shouldn't nvim-qt have some more sane defaults?

I don't see that here.  What happens if you run "nvim-qt -- -u NONE"?
If that works fine, then there's some configuration/plugin that's
affecting this.

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Bug#813658: Please enable virgl support

[john]

Package: qemu-system-x86
Version: 1:2.7+dfsg-3+b1
Followup-For: Bug #813658

Dear Maintainer,

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

Hi, Is it possible use virgl/opengl with debian's package?
(No recompile or hand make binary)

When I launch qemu-system-x86_64 -args  -display,gl=on
(which is "man qemu-system-x86_64" say),
It complain "SDL1 display code has no opengl support" issus.

Please make debian's qemu package support virgl/opengl, thanks.

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


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

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

Versions of packages qemu-system-x86 depends on:
ii  ipxe-qemu   1.0.0+git-20161027.b991c67-1
ii  libaio1 0.3.110-3
ii  libasound2  1.1.2-1
ii  libbluetooth3   5.43-1
ii  libbrlapi0.65.4-3
ii  libc6   2.24-8
ii  libcacard0  1:2.5.0-2
ii  libfdt1 1.4.2-1
ii  libgcc1 1:6.2.1-6
ii  libglib2.0-02.50.2-2
ii  libgnutls30 3.5.7-2
ii  libjpeg62-turbo 1:1.5.1-2
ii  libncurses5 6.0+20161126-1
ii  libnettle6  3.3-1
ii  libpixman-1-0   0.34.0-1
ii  libpng16-16 1.6.26-6
ii  libpulse0   9.0-5
ii  libsasl2-2  2.1.27~101-g0780600+dfsg-1
ii  libsdl1.2debian 1.2.15+dfsg1-4
ii  libseccomp2 2.3.1-2.1
ii  libspice-server10.12.8-1
ii  libtinfo5   6.0+20161126-1
ii  libusb-1.0-02:1.0.21-1
ii  libusbredirparser1  0.7.1-1
ii  libuuid12.29-1
ii  libvdeplug2 2.3.2+r586-2.1
ii  libx11-62:1.6.4-2
ii  libxen-4.8  4.8.0~rc5-1
ii  libxenstore3.0  4.8.0~rc5-1
ii  qemu-system-common  1:2.7+dfsg-3+b1
ii  seabios 1.9.3-2
ii  zlib1g  1:1.2.8.dfsg-4

Versions of packages qemu-system-x86 recommends:
ii  qemu-utils  1:2.7+dfsg-3+b1

Versions of packages qemu-system-x86 suggests:
ii  kmod  23-1
pn  ovmf  
pn  qemu-block-extra  
pn  samba 
pn  sgabios   
pn  vde2  

-- no debconf information

Bug#836330: PGObject:Util::DBChange Debian packaging.

[Robert J. Clay]

This one also still needs an update;  at least for the Copyright holder in
the module files themselves , which lists "The LedgerSMB Core Team."
instead of the author "Chris Travers, "


-- 
Robert J. Clay
rjc...@gmail.com

Bug#848301: fortune-mod: typo in 'The Least Successful Collector' fortune

[Cory Bloor]

Package: fortune-mod
Version: 1:1.99.1-7
Severity: minor

Dear Maintainer,

'The Least Successful Collector' refers to "The Hisory of the French 
Revolution", which is missing the 't' in 'History'.

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

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

Versions of packages fortune-mod depends on:
ii  libc6   2.23-0ubuntu5
ii  librecode0  3.6-22

Versions of packages fortune-mod recommends:
ii  fortunes-min [fortune-cookie-db]  1:1.99.1-7

Versions of packages fortune-mod suggests:
ii  bsdmainutils  9.0.6ubuntu3
pn  fortunes  
ii  x11-utils 7.7+3

-- no debconf information

Bug#819314: procps: [sysctl] Missing dependency when used with systemd

[Michael Biebl]

Am 16.12.2016 um 00:27 schrieb Michael Biebl:
> Afaics, this is fixed in stretch.
> systemd-networkd.service has After=systemd-sysctl.service, so does
> ifup@.service and networking.service.

The relevant commits in ifupdown are
https://anonscm.debian.org/cgit/collab-maint/ifupdown.git/commit/?id=3c7cf828b4306e5282db7cc1dda33593579175eb

https://anonscm.debian.org/cgit/collab-maint/ifupdown.git/commit/?id=117cfa63ed4f3dd3d81d2e09a0903052340e3d18

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



signature.asc
Description: OpenPGP digital signature

Bug#848258: mesa-opencl-icd: New OpenCL errors with Mesa and Blender

[Michel Dänzer]

On 16/12/16 04:11 AM, Marc Jeffrey Driftmeyer wrote:
> Package: mesa-opencl-icd
> Version: 13.0.2-3
> Severity: normal
> 
> Dear Maintainer,
> 
> Thank you for your work! The current blender/blender-data 2.78-dsfg-4 or 
> whatever it is exactly named segfaults but that's a separate story. I can 
> live with that being rebuilt.
> 
> However, the work done in LLVM/Mesa has tripped new bugs.

You should get in touch with Mesa upstream developers about these
issues. Your Debian bug reports are mostly creating additional overhead
for the Debian package maintainers, for little gain towards your goal of
using Blender with OpenCL.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer

Bug#848300: cvxopt: vcs-* urls point to googlecode.com

[Diane Trout]

Source: cvxopt
Version: 1.1.4-1.5
Severity: minor

Dear Maintainer,

The source package lists these urls for the package version control repository.

Vcs-Browser: http://bollin.googlecode.com/svn/cvxopt/trunk/
Vcs-Svn: https://bollin.googlecode.com/svn/cvxopt/trunk/

googlecode is long dead.

Perhaps consider moving the packaging repository to alioth?

Diane



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

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

Bug#848299: icedove crashes with SIGPIPE in libc's send.c

[Mirko Vogt]

Package: icedove
Version: 1:45.4.0-1
Severity: grave
Justification: renders package unusable

One of icedove's threads randomly(TM) crashes with SIGPIPE in libc's send.c

This can happen shortly after being started or after running for a
couple of hours. No direct trigger identified so far.

Output of gdb:

[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `/usr/bin/icedove'.
Program terminated with signal SIGPIPE, Broken pipe.
#0  0x77bcd65f in __libc_send (fd=67, buf=0x7fffa9834000, n=31,
flags=0) at ../sysdeps/unix/sysv/linux/x86_64/send.c:26
26  ../sysdeps/unix/sysv/linux/x86_64/send.c: No such file or directory.
[Current thread is 1 (Thread 0x7fffe2ffe700 (LWP 28924))]

backtrace for this particular thread:

(gdb) bt
#0  0x77bcd65f in __libc_send (fd=67, buf=0x7fffa9834000, n=31,
flags=0) at ../sysdeps/unix/sysv/linux/x86_64/send.c:26
#1  0x75ea4e4b in ?? () from /usr/lib/x86_64-linux-gnu/libnspr4.so
#2  0x7fffeeca759a in ?? () from /usr/lib/x86_64-linux-gnu/libssl3.so
#3  0x7fffeec9b999 in ?? () from /usr/lib/x86_64-linux-gnu/libssl3.so
#4  0x7fffeec9d694 in ?? () from /usr/lib/x86_64-linux-gnu/libssl3.so
#5  0x7fffeecad9fb in ?? () from /usr/lib/x86_64-linux-gnu/libssl3.so
#6  0x73998afe in ?? () from /usr/lib/icedove/libxul.so
#7  0x73998b86 in ?? () from /usr/lib/icedove/libxul.so
#8  0x722d6fc0 in ?? () from /usr/lib/icedove/libxul.so
#9  0x722db356 in ?? () from /usr/lib/icedove/libxul.so
#10 0x722d8c50 in ?? () from /usr/lib/icedove/libxul.so
#11 0x722d8fdc in ?? () from /usr/lib/icedove/libxul.so
#12 0x722e0cb5 in ?? () from /usr/lib/icedove/libxul.so
#13 0x7225ea53 in ?? () from /usr/lib/icedove/libxul.so
#14 0x72278ae9 in ?? () from /usr/lib/icedove/libxul.so
#15 0x7245be9b in ?? () from /usr/lib/icedove/libxul.so
#16 0x7244bf62 in ?? () from /usr/lib/icedove/libxul.so
#17 0x72260742 in ?? () from /usr/lib/icedove/libxul.so
#18 0x75ea8549 in ?? () from /usr/lib/x86_64-linux-gnu/libnspr4.so
#19 0x77bc4464 in start_thread (arg=0x7fffe2ffe700) at
pthread_create.c:333
#20 0x76e679df in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:105

Core dump exists but I'm not keen of publishing it due to included
sensitive data. I'm happy to help debugging though.

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

Kernel: Linux 4.9.0-rc8+ (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 icedove depends on:
ii  debianutils   4.8.1
ii  fontconfig2.11.0-6.7
ii  libasound21.1.2-1
ii  libatk1.0-0   2.22.0-1
ii  libc6 2.24-7
ii  libcairo2 1.14.6-1.1
ii  libdbus-1-3   1.10.14-1
ii  libdbus-glib-1-2  0.108-1
ii  libevent-2.0-52.0.21-stable-2.1
ii  libffi6   3.2.1-6
ii  libfontconfig12.11.0-6.7
ii  libfreetype6  2.6.3-3+b1
ii  libgcc1   1:6.2.1-5
ii  libgdk-pixbuf2.0-02.36.0-1
ii  libglib2.0-0  2.50.2-2
ii  libgtk2.0-0   2.24.31-1
ii  libhunspell-1.4-0 1.4.1-2+b1
ii  libicu57  57.1-5
ii  libnspr4  2:4.12-6
ii  libnss3   2:3.26.2-1
ii  libpango-1.0-01.40.3-3
ii  libpangocairo-1.0-0   1.40.3-3
ii  libpangoft2-1.0-0 1.40.3-3
ii  libpixman-1-0 0.34.0-1
ii  libsqlite3-0  3.15.2-1
ii  libstartup-notification0  0.12-4
ii  libstdc++66.2.1-5
ii  libvpx4   1.6.0-3
ii  libx11-6  2:1.6.3-1
ii  libxcomposite11:0.4.4-1
ii  libxdamage1   1:1.1.4-2+b1
ii  libxext6  2:1.3.3-1
ii  libxfixes31:5.0.2-1
ii  libxrender1   1:0.9.9-2
ii  libxt61:1.1.5-1
ii  psmisc22.21-2.1+b1
ii  zlib1g1:1.2.8.dfsg-2+b3

Versions of packages icedove recommends:
ii  hunspell-en-us [hunspell-dictionary]  20070829-6
ii  iceowl-extension  1:45.4.0-1

Versions of packages icedove suggests:
pn  apparmor  
pn  fonts-lyx 
ii  libgssapi-krb5-2  1.15~beta1-1

-- no debconf information

Bug#828606: xmlsec1: diff for NMU version 1.2.23-0.1

[John Belmonte]

Looks good, thank you Sebastian.

On Thu, Dec 15, 2016 at 12:27 PM, Sebastian Andrzej Siewior <
sebast...@breakpoint.cc> wrote:

> Control: tags 828606 + patch
> Control: tags 828606 + pending
>
> Dear maintainer,
>
> I've prepared an NMU for xmlsec1 (versioned as 1.2.23-0.1) and
> uploaded it to DELAYED/4. Please feel free to tell me if I
> should delay it longer.
> I replaced the orig tar archive from 1.2.20 to 1.2.23 and dropped the
> patches since they are applied upstream. The OpenSSL 1.1.0 support is
> already part of this release so this comes for free.
>
> Regards.
> Sebastian
>

Bug#824214: Debian pkg for PGObject::Util::DBAdmin

[Robert J. Clay]

We're running out of time to get this one into Debian before they freeze in
preparation for the new release (in this case, stop accepting new packages)
and it still needs clarification regarding the copyright years.

On Thu, Sep 15, 2016 at 12:02 PM, Robert J. Clay  wrote:

> Chris,
>
> In case your  efficito.com adx isn't checked very often...
>
> -- Forwarded message --
> From: Robert J. Clay 
> Date: Wed, Sep 14, 2016 at 6:38 PM
> Subject: Re: Debian pkg for PGObject::Util::DBAdmin
> To: Chris Travers , Erik Huelsmann 
> Cc: 824...@bugs.debian.org, Development discussion for LedgerSMB <
> ledger-smb-de...@lists.sourceforge.net>
>
>
> Chris,
>
>  Do you an idea when you might be able to work on this?  The freeze
> for Debian 9 isn't all that close but it's not all that far away either and
> I'd really like to get this into Debian well before that
>
>
> On Wed, Aug 24, 2016 at 7:27 PM, Robert J. Clay  wrote:
>
>> Chris,
>>
>>I was working the Debian packaging for the PGObject::Util::DBAdmin
>> today.  I was able to update the packaging to v0.09 (which, btw, does not
>> appear to be push to github repo for the module) but found some issues:
>>
>>   - Incorrect copyright years in the README & module files,  "2014"
>> instead of the
>>  "2014-2016" that it looks like it should be:
>>   https://rt.cpan.org/Ticket/Display.html?id=117202
>>   https://github.com/ledgersmb/PGObject-Util-DBAdmin/issues/10
>>
>>   - Found a couple of minor spelling errors in the module file, and for
>> which I created a
>> patch:  https://github.com/ledgersmb/PGObject-Util-DBAdmin/issues/9
>>
>> Note also that I could put a preliminary version of the pkg up on
>> apt.ledgersmb.org if it might be a bit before these issues can be
>> addressed...
>>
>> The git packaging repo for it can be found at:
>> https://anonscm.debian.org/cgit/pkg-perl/packages/libpgobjec
>> t-util-dbadmin-perl.git
>>
>>
>>
>> --
>> Robert James Clay
>> rjc...@gmail.co m
>> j...@rocasa.com
>>
>>
>
>
> --
> Robert J. Clay
> rjc...@gmail.com
>
>
>
> --
> Robert J. Clay
> rjc...@gmail.com
>



-- 
Robert J. Clay
rjc...@gmail.com

Bug#848298: mongodb: Build for s390x

[Jeremy Bicha]

Package: mongodb
Version: 1:3.2.11-1
Severity: wishlist

MongoDB has recently gained support for running on s390x.

The official documentation says s390x is supported on MongoDB 3.4
Enterprise Edition.[1]

IBM has documentation [2]that says it's possible to build and run it
on 3.2. They have ~16 backported patches in their git repo branched
off an older 3.2 version. (I noticed at least one of the patches was
already applied in a more recent 3.2 release.

I don't have access to an s390x machine. I just know some people were
interested in seeing this work on Debian/Ubuntu.

[1] 
https://docs.mongodb.com/manual/administration/production-notes/#prod-notes-supported-platforms
[2] 
https://github.com/linux-on-ibm-z/docs/wiki/Building-MongoDB-3.2-on-RHEL-7-and-SLES-12
[3] https://github.com/linux-on-ibm-z/mongo/commits/master-s390

Thanks,
Jeremy Bicha

Bug#848297: gst-plugins-bad1.0: docstring collision

[Daniel Shahaf]

Package: gst-plugins-bad1.0
Version: 1.10.2-1
Severity: minor
Tags: patch upstream
User: reproducible-bui...@lists.alioth.debian.org
Usertags: randomness

Dear Maintainer,

The documentation of GstColorEffectsPreset sometimes uses the docstring
of GstColorEffectsPreset and sometimes the docstring of GstMirrorMode [1]:

│   │   │   ├── 
./usr/share/gtk-doc/html/gst-plugins-bad-plugins-1.0/gst-plugins-bad-plugins-coloreffects.html
│   │   │   │ @@ -188,15 +188,15 @@
│   │   │   │  
│   │   │   │  enum 
GstColorEffectsPreset
│   │   │   │ -How to split the video frame and which side reflect
│   │   │   │ +The lookup table to use to convert input colors

I believe that that is caused by the docstring of GstMirrorMode
mistakenly referring to GstColorEffectsPreset:

[[[
diff --git a/gst/geometrictransform/gstmirror.h 
b/gst/geometrictransform/gstmirror.h
index 2084f2c..22e6aa5 100644
--- a/gst/geometrictransform/gstmirror.h
+++ b/gst/geometrictransform/gstmirror.h
@@ -66,7 +66,7 @@ typedef struct _GstMirror GstMirror;
 typedef struct _GstMirrorClass GstMirrorClass;
 
 /**
- * GstColorEffectsPreset:
+ * GstMirrorMode:
  * @GST_MIRROR_MODE_LEFT: Split horizontally and reflect left into right
  * @GST_MIRROR_MODE_RIGHT: Split horizontally and reflect right into left
  * @GST_MIRROR_MODE_TOP: Split horizontally and reflect top into bottom
]]]

Cheers,

Daniel

P.S. Apologies for not making a more thorough investigation; I would,
but for health reasons.

[1] 
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/armhf/gst-plugins-bad1.0.html

Bug#832613: kronatools_2.7+dfsg-1_amd64.changes REJECTED

[Ian Jackson]

Andreas Tille writes ("Re: kronatools_2.7+dfsg-1_amd64.changes REJECTED"):
> On Thu, Dec 15, 2016 at 10:00:10PM +, Thorsten Alteholz wrote:
> > according to [1] it is even a word mark, so I don't think it is a good 
> > idea to let anything related to diagnostic software with krona in its 
> > name into the archive.
> 
> Thanks for your torough checking. As discussed long ago[2]
> 
>   "KronaTools" may work, since the actual trademark is just
>   "Krona". You could also use "Radiant", which was the original name
>   (and still in SourceForge with a redirect). We avoided Radiant so
>   our name could be trademarked, but you wouldn't have that problem
>   I'm guessing.

The upstream you are dealing with, here, clearly don't really
understand trademarks very well.  If "krona" is trademarked (and that
DHS page claims it is) then "kronatools" would clearly be a breach.

You'll have to call it something without the word "krona" in.

> It would help to hear other opinions before trying another upload to
> new: What name do you think is a proper name for this project in Debian.

I haven't been able to figure out what this program does.  Your links
don't give your own Description and the upstream say:

  Krona Tools is a set of scripts to create Krona charts from several
  Bioinformatics tools as well as from text and XML files.

Either this is circular, or "Krona chart" was a medical (or
medico-informatical) term before this software existed and it
shouldn't have been trademarked (although I doubt anyone wants to
fight that).

radiant-diagnostic or something maybe ?  (I see there is also a Ruby
CMS called "radiant".)

Ian.

-- 
Ian Jackson    These opinions are my own.

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

Bug#848296: Error building libsoldout with clang

[Luke Benes]

Package: libsoldout
Version: 1.4-1

If you try to build Debian’s version of libsoldout with clang you get the 
following error:

clang: error: argument unused during compilation: '-pie'

http://clang.debian.net/logs/2016-08-30/libsoldout_1.4-1_unstable_clang.log

I filed a bug report upstream and the developer correctly pointed out that this 
is a Debian specific bug. He recommend you do not use the '-pie' flags.

https://github.com/faelys/libsoldout/issues/41

Could we use the developers suggestions or put an ifdef to make those flags gcc 
only?
  
   

Bug#831470: gdb manual: missing documentation of the -tui option

[Paul Wise]

On Thu, 2016-12-15 at 13:11 +0100, Hector Oron wrote:

>   Given all the above I tend to think that we should propose upstream to
>   document such option in the manpage instead of us modifying it.

That sounds fine to me too.

Also, would be nice if they dropped the cover texts and invariant
sections so that the docs could move back into Debian main.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#835029: please add opensc-pkcs11.module

[Timo Aaltonen]

Hi,

This should do it.

diff --git a/debian/opensc-pkcs11.install b/debian/opensc-pkcs11.install
index c1b3136..41e4d3e 100644
--- a/debian/opensc-pkcs11.install
+++ b/debian/opensc-pkcs11.install
@@ -1,3 +1,4 @@
 debian/tmp/usr/lib/*/*pkcs11*.so
 debian/tmp/usr/lib/*/lib*.so.*
 debian/tmp/usr/lib/*/pkcs11/*.so
+debian/opensc-pkcs11.module/usr/share/p11-kit/modules
diff --git a/debian/opensc-pkcs11.module b/debian/opensc-pkcs11.module
new file mode 100644
index 000..9c7aba8
--- /dev/null
+++ b/debian/opensc-pkcs11.module
@@ -0,0 +1,3 @@
+# This file describes how to load the opensc module
+# See: http://p11-glue.freedesktop.org/doc/p11-kit/config.html
+module: opensc-pkcs11.so


-- 
t

Bug#848295: openni-sensor-primesense: please make the build reproducible

[Reiner Herrmann]

Source: openni-sensor-primesense
Version: 5.1.0.41-6
Severity: wishlist
Tags: patch upstream
User: reproducible-bui...@lists.alioth.debian.org
Usertags: fileordering
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi!

While working on the "reproducible builds" effort [1], we have noticed
that openni-sensor-primesense could not be built reproducibly.
During build it links object files in non-deterministic order.

The attached patch fixes this by sorting the list of source files.

Regards,
 Reiner

[1]: https://wiki.debian.org/ReproducibleBuilds
diff --git a/debian/patches/0013-Reproducible-builds.patch b/debian/patches/0013-Reproducible-builds.patch
new file mode 100644
index 000..d7151a6
--- /dev/null
+++ b/debian/patches/0013-Reproducible-builds.patch
@@ -0,0 +1,14 @@
+Author: Reiner Herrmann 
+Description: Sort list of source files for deterministic linking order
+
+--- a/Platform/Linux/Build/Common/CommonDefs.mak
 b/Platform/Linux/Build/Common/CommonDefs.mak
+@@ -42,7 +42,7 @@
+ endif
+ 
+ # expand file list
+-SRC_FILES_LIST = $(wildcard $(SRC_FILES))
++SRC_FILES_LIST = $(sort $(wildcard $(SRC_FILES)))
+ 
+ # define the intermediate directory
+ INT_DIR = $(PLATFORM)-$(CFG)
diff --git a/debian/patches/series b/debian/patches/series
index 8f33b95..f93fb2e 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -10,3 +10,4 @@
 0010-Add-ARMhf-support.patch
 0011-Add-Arm64-support-thanks-Edmund-Grimley-Evans.patch
 0012-Add-mips-support-thanks-Daniel-Knezevic.patch
+0013-Reproducible-builds.patch

Bug#682457: glabels unnecessarily restricts the width of lines to 4 points

[Jakob Haufe]

Hi,

current glabels allows lines to be up to 10 points wide, which is appropriate
IMHO. Does this solve your issue?

Cheers,
sur5r

-- 
ceterum censeo microsoftem esse delendam.


pgp5r7Cq0Ofi9.pgp
Description: OpenPGP digital signature

Bug#750138: Info received (Bug#750138: scap-workbench)

[Frank lin Piat]

Hello,
On Thu, 2016-12-15 at 15:28 +0100, Petter Reinholdtsen wrote:
> Frank, do you plan to set up a shared git repo for the package now?

What about collab-maint ?

> The build failed everywhere, probably because of missing build
> dependencies, see
> https://buildd.debian.org/status/package.php?p=scap-workbench
> >.

FTBFS was due to a hardcoded value. Fix thanks to Aaron M. Ucko
(#848250)

> I notice a new version is available from upstream.

I have merged and tested it. It seems ok so I pushed it.(some remote
features seems to require openscap >= 1.2.12 but unstable has 1.2.9, I
haven't tested it)
Pierre, do you intend to upgrade openscap ? Do you want some help ?

> The git repo seem to lack a pristine-tar branch.  Is this
> intentional?

Fixed

There are a few more lintian info/warning to fix. I would fix later.
I: scap-workbench source: unused-license-paragraph-in-dep5-copyright
expat (paragraph at line 56)I: scap-workbench: spelling-error-in-binary 
usr/bin/scap-workbench Allows to Allows one toI: scap-workbench:
hardening-no-bindnow usr/bin/scap-workbenchW: scap-workbench: extra-
license-file usr/share/doc/scap-workbench/COPYING.gzI: scap-workbench:
desktop-entry-lacks-keywords-entry usr/share/applications/scap-
workbench.desktop
Thanks

Bug#848293: postgresql-9.6-mysql-fdw: update mysql dependencies for mariadb

[Emilio Pozuelo Monfort]

Package: postgresql-9.6-mysql-fdw
Version: 2.1.2-3
Severity: serious

postgresql-9.6-mysql-fdw depends on libmysqlclient-dev.

That should be updated to:

  default-libmysqlclient-dev

as we are making mariadb the default mysql provider.

Thanks,
Emilio

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

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

Bug#848294: diaspora-installer-mysql: update mysql dependencies for mariadb

[Emilio Pozuelo Monfort]

Package: diaspora-installer-mysql
Version: 0.6.0.0+debian4
Severity: serious

diaspora-installer-mysql depends on mysql-server and libmysqlclient-dev.

Those dependencies should be updated as:

  default-mysql-server | virtual-mysql-server, default-libmysqlclient-dev

as we are making mariadb the default mysql provider.

Thanks,
Emilio

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

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

Bug#848292: fastqtl: please make the build reproducible

[Reiner Herrmann]

Source: fastqtl
Version: 2.184+dfsg-4
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: fileordering
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi!

While working on the "reproducible builds" effort [1], we have noticed
that fastqtl could not be built reproducibly.
There is already a patch that intends to fix a fileordering-related
reproducibility issue.
But it uses `sort -z', which expects a NULL-separated list.
This is easily fixed by sorting without -z.

Regards,
 Reiner

[1]: https://wiki.debian.org/ReproducibleBuilds
diff --git a/debian/patches/03_Reproducible_builds.patch b/debian/patches/03_Reproducible_builds.patch
index bfe3386..f2c8ff3 100644
--- a/debian/patches/03_Reproducible_builds.patch
+++ b/debian/patches/03_Reproducible_builds.patch
@@ -12,9 +12,9 @@ Forwarded: TODO
 -FILE_O=$(shell for file in `find src -name *.cpp`; do echo obj/$$(basename $$file .cpp).o; done)
 -FILE_H=$(shell find src -name *.h)
 -FILE_CPP=$(shell find src -name *.cpp)
-+FILE_O=$(shell for file in `find src -name *.cpp | LC_ALL=C sort -z`; do echo obj/$$(basename $$file .cpp).o; done)
-+FILE_H=$(shell find src -name *.h | LC_ALL=C sort -z)
-+FILE_CPP=$(shell find src -name *.cpp | LC_ALL=C sort -z)
++FILE_O=$(shell for file in `find src -name *.cpp | LC_ALL=C sort`; do echo obj/$$(basename $$file .cpp).o; done)
++FILE_H=$(shell find src -name *.h | LC_ALL=C sort)
++FILE_CPP=$(shell find src -name *.cpp | LC_ALL=C sort)
  
  #default
  all: linux

Bug#818978: systemd crashes in lxc on container stop

[Michael Biebl]

Control: forwarded -1 https://github.com/systemd/systemd/issues/4810

This was fixed upstream by
https://github.com/systemd/systemd/commit/ad2706db7cceba69203f3ac2b6ef65d7490c5f29

Attached is a backport of that patch for v215

It seems to fix the issue seen on jessie.
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
From: Lennart Poettering 
Date: Tue, 29 Nov 2016 22:50:21 +0100
Subject: core: rework logic to determine when we decide to add automatic deps
 for mounts

This adds a concept of "extrinsic" mounts. If mounts are extrinsic we consider
them managed by something else and do not add automatic ordering against
umount.target, local-fs.target, remote-fs.target.

Extrinsic mounts are considered:

- All mounts if we are running in --user mode

- API mounts such as everything below /proc, /sys, /dev, which exist from
  earliest boot to latest shutdown.

- All mounts marked as initrd mounts, if we run on the host

- The initrd's private directory /run/initrams that should survive until last
  reboot.

This primarily merges a couple of different exclusion lists into a single
concept.

(cherry picked from commit ad2706db7cceba69203f3ac2b6ef65d7490c5f29)
---
 src/core/mount.c   | 62 +++---
 src/shared/path-util.h | 25 
 2 files changed, 64 insertions(+), 23 deletions(-)

diff --git a/src/core/mount.c b/src/core/mount.c
index 102bbef91..44f79ba8a 100644
--- a/src/core/mount.c
+++ b/src/core/mount.c
@@ -350,19 +350,35 @@ static int mount_add_quota_links(Mount *m) {
 return 0;
 }
 
-static bool should_umount(Mount *m) {
+static bool mount_is_extrinsic(Mount *m) {
 MountParameters *p;
+assert(m);
 
-if (path_equal(m->where, "/") ||
-path_equal(m->where, "/usr"))
-return false;
+/* Returns true for all units that are "magic" and should be excluded from the usual start-up and shutdown
+ * dependencies. We call them "extrinsic" here, as they are generally mounted outside of the systemd dependency
+ * logic. We shouldn't attempt to manage them ourselves but it's fine if the user operates on them with us. */
+
+if (UNIT(m)->manager->running_as != SYSTEMD_SYSTEM) /* We only automatically manage mounts if we are in system mode */
+return true;
 
+if (PATH_IN_SET(m->where,  /* Don't bother with the OS data itself */
+"/",
+"/usr"))
+return true;
+
+if (PATH_STARTSWITH_SET(m->where,
+"/run/initramfs",/* This should stay around from before we boot until after we shutdown */
+"/proc", /* All of this is API VFS */
+"/sys",  /* … dito … */
+"/dev")) /* … dito … */
+return true;
+
+/* If this is an initrd mount, and we are not in the initrd, then leave this around forever, too. */
 p = get_mount_parameters(m);
-if (p && mount_test_option(p->options, "x-initrd.mount") &&
-!in_initrd())
-return false;
+if (p && mount_test_option(p->options, "x-initrd.mount") && !in_initrd())
+return true;
 
-return true;
+return false;
 }
 
 static int mount_add_default_dependencies(Mount *m) {
@@ -375,14 +391,17 @@ static int mount_add_default_dependencies(Mount *m) {
 if (UNIT(m)->manager->running_as != SYSTEMD_SYSTEM)
 return 0;
 
+/* We do not add any default dependencies to /, /usr or /run/initramfs/, since they are guaranteed to stay
+ * mounted the whole time, since our system is on it.  Also, don't bother with anything mounted below virtual
+ * file systems, it's also going to be virtual, and hence not worth the effort. */
+if (mount_is_extrinsic(m))
+return 0;
+
 p = get_mount_parameters(m);
 
 if (!p)
 return 0;
 
-if (path_equal(m->where, "/"))
-return 0;
-
 if (mount_is_network(p)) {
 after = SPECIAL_REMOTE_FS_PRE_TARGET;
 after2 = SPECIAL_NETWORK_TARGET;
@@ -409,11 +428,9 @@ static int mount_add_default_dependencies(Mount *m) {
 return r;
 }
 
-if (should_umount(m)) {
-r = unit_add_two_dependencies_by_name(UNIT(m), UNIT_BEFORE, UNIT_CONFLICTS, SPECIAL_UMOUNT_TARGET, NULL, true);
-if (r < 0)
-return r;
-}
+r = unit_add_two_dependencies_by_name(UNIT(m), UNIT_BEFORE, UNIT_CONFLICTS, SPECIAL_UMOUNT_TARGET, NULL, true);
+if (r < 0)
+return r;
 
 return 0;
 }
@@ -667,6 +684,7 @@ static void mount_dump(Unit *u, FILE 

Bug#845830: cl-sql: switch to build depend on the metapackage default-libmysqlclient-dev

[Emilio Pozuelo Monfort]

Please make sure you also update cl-sql-mysql's runtime dependency on
libmysqlclient-dev to:

  default-libmysqlclient-dev

Thanks,
Emilio

Bug#845907: ruby-mysql2: switch to build depend on the metapackage default-libmysqlclient-dev

[Emilio Pozuelo Monfort]

Please make sure you also update your mysql-server build-dependency to

  default-mysql-server | virtual-mysql-server

Thanks,
Emilio

Bug#845905: ruby-dataobjects-mysql: switch to build depend on the metapackage default-libmysqlclient-dev

[Emilio Pozuelo Monfort]

Please make sure you also update your mysql-server build-dependency to

  default-mysql-server | virtual-mysql-server

Thanks,
Emilio

Bug#848288: ruby-em-synchrony: (build-)depends on mysql-{client,server}

[Emilio Pozuelo Monfort]

Package: ruby-em-synchrony
Version: 1.0.5-1
Severity: serious

Your package build-depends on mysql-server. Since we're transitioning to
mariadb as the default mysql provider, you should switch your build
dependency to default-mysql-server | virtual-mysql-server.

Cheers,
Emilio

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

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

Bug#848289: ruby-riddle: (build-)depends on mysql-{client,server}

[Emilio Pozuelo Monfort]

Package: ruby-riddle
Version: 1.5.12-3
Severity: serious

Your package build-depends on mysql-server. Since we're transitioning to
mariadb as the default mysql provider, you should switch your build
dependency to default-mysql-server | virtual-mysql-server.

Cheers,
Emilio

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

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

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

[Emilio Pozuelo Monfort]

Source: python-testing.mysqld
Version: 1.4.0-1
Severity: serious

Your package (build-)depends on mysql-server/client. Since we're
transitioning to mariadb as the default mysql provider, you should
switch your build dependencies and dependencies to something like:

default-mysql-server | virtual-mysql-server, default-mysql-client | 
virtual-mysql-client

I have seen in your override that you have forwarded this upstream.
I am filing this anyway to keep track of this along with the rest of the
packages.

Cheers,
Emilio

Cheers,
Emilio

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

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

Bug#848290: python-tooz: (build-)depends on mysql-{client,server}

[Emilio Pozuelo Monfort]

Source: python-tooz
Version: 1.40.0-3
Severity: serious

Your package build-depends on mysql-server. Since we're transitioning to
mariadb as the default mysql provider, you should switch your build
dependency to default-mysql-server | virtual-mysql-server.

Cheers,
Emilio

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

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

Bug#848291: mysql-connector-python: build-depends on mysql-{client,server}

[Emilio Pozuelo Monfort]

Source: mysql-connector-python
Version: 2.1.3-1
Severity: serious

Your package build-depends on mysql-server. Since we're transitioning to
mariadb as the default mysql provider, you should switch your build
dependency to default-mysql-server | virtual-mysql-server.

Cheers,
Emilio

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

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

Bug#732141: Status of this RFP

[Jakob Haufe]

Hi Dmitry,

you opened an RFP bug for zint and at the same time started packaging it.

I'm currently re-evaluating the possibility of enabling the Zint backend in
glabels and would thus be interested in having zint packaged for Debian.

Right now, [1] seems to be active and is also referenced from [2].

So my question is: Do you plan to maintain zint in Debian, do you want help
or do you want someone else to take over?

Cheers,
sur5r

[1] https://sourceforge.net/projects/zint/
[2] http://www.zint.org.uk/

-- 
ceterum censeo microsoftem esse delendam.


pgpQJlroIIJt_.pgp
Description: OpenPGP digital signature

Bug#826344: please backport v0.7.5

[Guido Günther]

Hi,
On Sat, Jun 04, 2016 at 01:48:37PM -0400, Nicholas D Steeves wrote:
> Package: git-buildpackage
> Version: 0.7.5
> 
> Following up on Bug#826341: I suspect a backported v0.7.6 package
> would save time/work  :-)  If #826341 is closed as wont-fix, please
> consider backporting git-buildpackage nonetheless.

Since my uploads in June as well as my recent one still are stuck in the
backports queue I've put a built for Jessie here:

https://honk.sigxcpu.org/projects/git-buildpackage/snapshots/

Cheers,
 -- Guido

Bug#819314: procps: [sysctl] Missing dependency when used with systemd

[Michael Biebl]

On Thu, 31 Mar 2016 16:45:40 +0200 Martin Mares  wrote:
> Hello!
> 
> > Are you sure?
> > networking.service has
> > > After=local-fs.target network-pre.target apparmor.service 
> > > systemd-sysctl.service
> > 
> > This makes sure that networking.service, which deals with type auto
> > interfaces, is started after systemd-sysctl.service.
> 
> On my system (Wheezy recently upgraded to Jessie):
> 
> | ● networking.service - LSB: Raise network interfaces.
> |Loaded: loaded (/etc/init.d/networking)
> |   Drop-In: /run/systemd/generator/networking.service.d
> |└─50-insserv.conf-$network.conf
> | /lib/systemd/system/networking.service.d
> |└─network-pre.conf
> |Active: active (exited) since Sun 2016-03-20 21:56:51 CET; 1 weeks 3 
> days ago
> 
> /run/systemd/generator/networking.service.d/50-insserv.conf-$network.conf
> contains only:
> 
> | # Automatically generated by systemd-insserv-generator
> | 
> | [Unit]
> | Wants=network.target
> | Before=network.target
> 
> /lib/systemd/system/networking.service.d/network-pre.conf contains only:
> 
> | [Unit]
> | After=network-pre.target
> 
> No trace of systemd-sysctl.service anywhere.
> 
> > And for hotplugged devices
> > 
> > /lib/udev/rules.d/99-systemd.rules contains
> > > 99-systemd.rules:# Apply sysctl variables to network devices (and only to 
> > > those) as they appear.
> > > 99-systemd.rules:ACTION=="add", SUBSYSTEM=="net", KERNEL!="lo", 
> > > RUN+="/lib/systemd/systemd-sysctl --prefix=/net/ipv4/conf/$name 
> > > --prefix=/net/ipv4/neigh/$name --prefix=/net/ipv6/conf/$name 
> > > --prefix=/net/ipv6/neigh/$name"
> 
> This works for per-interface options, but not for /net/ipv6/conf/default.
> (However, I probably should abandon using conf/default anyway, since some
> kernel modules are loaded before sysctl is set.)
> 
>

Afaics, this is fixed in stretch.
systemd-networkd.service has After=systemd-sysctl.service, so does
ifup@.service and networking.service.

So, question is what to do about this in jessie.
We already ship
/lib/systemd/system/networking.service.d/network-pre.conf in systemd,
containing
[Unit]
After=network-pre.target

We could extend that to include After=systemd-sysctl.service.

It would be cleaner if that was shipped in ifupdown itself, but in
jessie, systemd also provides ifup@.service. Both were mistakes in
hindsight, which I'm not sure is worth fixing retroactively.

Guus, do you have any preference here. Do you want to take over that
file from systemd and make a jessie stable upload?
If not, I'd add the After ordering to the jessie systemd package.

Let me know what you think.

Regards,
Michael




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



signature.asc
Description: OpenPGP digital signature

Bug#848286: jscommunicator-web-phone: Tries to use jquery-ui.js, but only jquery-ui.min.js symlink is available

[James Valleroy]

Package: jscommunicator-web-phone
Version: 2.1.3-1
Severity: normal

Dear Maintainer,

I enabled the included apache conf, and loaded the /jscommunicator-web-phone
page in the browser. But there's a 404 when it tries to find jquery-ui.js.

The package creates a symlink named jquery-ui.min.js, but in phone.shtml it's
looking for jquery-ui.js.



-- 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-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages jscommunicator-web-phone depends on:
ii  apache2 [httpd]   2.4.23-8
ii  libjs-jscommunicator  2.1.3-1

Versions of packages jscommunicator-web-phone recommends:
ii  repro1:1.10.2-1
ii  resiprocate-turn-server  1:1.10.2-1

jscommunicator-web-phone suggests no packages.

-- no debconf information

Bug#848285: jackd2: spits verbose output and exits immediately when the client stops sending audio

[Francesco Poli (wintermute)]

Package: jackd2
Version: 1.9.10+20150825git1ed50c92~dfsg-4
Severity: grave
Justification: renders package unusable

Hello and thanks for maintaining jackd2!

After the upgrade

  [UPGRADE] jackd2:amd64 1.9.10+20150825git1ed50c92~dfsg-3 -> 
1.9.10+20150825git1ed50c92~dfsg-4
  [UPGRADE] jackd2-firewire:amd64 1.9.10+20150825git1ed50c92~dfsg-3 -> 
1.9.10+20150825git1ed50c92~dfsg-4
  [UPGRADE] libjack-jackd2-0:amd64 1.9.10+20150825git1ed50c92~dfsg-3 -> 
1.9.10+20150825git1ed50c92~dfsg-4

I experienced a grave bug: as soon as the client (audacious, firefox through
ALSA redirection in ~/.asoundrc, ...) stops sending audio to the jackd
sound server, the latter spits a bunch of output messages and exits
immediately (as if the --temporary option were passed, no!, even worse!).

Steps to reproduce:

  0) run jackd with the following command line:

 $ jackd --realtime -d alsa --device hw:1 --softmode --hwmeter --rate 44100 
&

  1) run, e.g., audacious (configured to use the Jack output plugin)

  2) play some audio: everything seems to work, even though jackd seems
 to have become more verbose than ever, with a long sequence of
 output lines similar to:

 [...]
 Jack: JackSocketServerChannel::Execute : fPollTable i = 1 fd = 9
 Jack: JackSocketServerChannel::Execute : fPollTable i = 2 fd = 10
 Jack: JackSocketServerChannel::Execute : fPollTable i = 1 fd = 9
 Jack: JackSocketServerChannel::Execute : fPollTable i = 2 fd = 10
 Jack: JackSocketServerChannel::Execute : fPollTable i = 1 fd = 9
 Jack: JackSocketServerChannel::Execute : fPollTable i = 2 fd = 10
 [...]

  3) click on the stop button in the audacious interface: jackd spits the
 following output and exits immediately:

 Jack: JackSocketServerChannel::Execute : fPollTable i = 1 fd = 9
 Jack: JackSocketServerChannel::Execute : fPollTable i = 2 fd = 10
 Jack: JackRequest::DeactivateClient
 Jack: JackEngine::ClientDeactivate ref = 2 name = audacious
 Jack: JackEngine::PortDisconnect ref = -1 src = 9 dst = 65535
 Jack: JackEngine::PortDisconnect ref = -1 src = 9 dst = 3
 Jack: JackGraphManager::Disconnect port_src = 9 port_dst = 3
 Jack: JackConnectionManager::Disconnect port_src = 9 port_dst = 3
 Jack: JackConnectionManager::Disconnect port_src = 3 port_dst = 9
 Jack: JackConnectionManager::DecConnectionRef: ref1 = 2 ref2 = 0
 Jack: JackEngine::ClientNotify: no callback for notification = 12
 Jack: JackEngine::ClientNotify: no callback for notification = 12
 Jack: JackEngine::ClientNotify: no callback for notification = 12
 Jack: JackEngine::PortDisconnect ref = -1 src = 10 dst = 65535
 Jack: JackEngine::PortDisconnect ref = -1 src = 10 dst = 4
 Jack: JackGraphManager::Disconnect port_src = 10 port_dst = 4
 Jack: JackConnectionManager::Disconnect port_src = 10 port_dst = 4
 Jack: JackConnectionManager::Disconnect port_src = 4 port_dst = 10
 Jack: JackConnectionManager::DirectDisconnect last: ref1 = 2 ref2 = 0
 Jack: JackConnectionManager::DecConnectionRef: ref1 = 2 ref2 = 0
 Jack: JackEngine::ClientNotify: no callback for notification = 12
 Jack: JackEngine::ClientNotify: no callback for notification = 12
 Jack: JackEngine::ClientNotify: no callback for notification = 12
 Jack: JackEngine::ClientNotify: no callback for notification = 10
 Jack: JackEngine::ClientNotify: no callback for notification = 10
 Jack: JackEngine::ClientNotify: no callback for notification = 10
 Jack: JackEngine::ClientNotify: no callback for notification = 10
 Jack: JackEngine::ClientNotify: no callback for notification = 10
 Jack: JackEngine::ClientNotify: no callback for notification = 10
 Jack: JackConnectionManager::DirectDisconnect last: ref1 = 2 ref2 = 1
 Jack: JackGraphManager::DisconnectRefNum cur_index = 3 ref1 = 2 ref2 = 1
 Jack: JackConnectionManager::DirectDisconnect last: ref1 = 1 ref2 = 2
 Jack: JackGraphManager::DisconnectRefNum cur_index = 3 ref1 = 1 ref2 = 2
 Jack: JackPosixProcessSync::TimedWait time out = 464380
 Jack: JackPosixProcessSync::TimedWait finished delta = 16446.0
 Jack: JackSocketServerChannel::Execute : fPollTable i = 1 fd = 9
 Jack: JackRequest::Notification
 Jack: JackDriver::ClientNotify ref = 1 driver = freewheel name = freewheel 
notify = 18
 Jack: JackDriver::ClientNotify ref = 1 driver = freewheel name = freewheel 
notify = 18
 Jack: JackDriver::ClientNotify ref = 1 driver = freewheel name = freewheel 
notify = 18
 Jack: JackDriver::ClientNotify ref = 1 driver = freewheel name = freewheel 
notify = 18
 Jack: JackEngine::ClientNotify: no callback for notification = 4
 Jack: JackEngine::ClientNotify: no callback for notification = 4
 Jack: JackEngine::ClientNotify: no callback for notification = 4
 Jack: JackSocketServerChannel::Execute : fPollTable i = 2 fd = 10
 Jack: JackSocketServerChannel::Execute : fPollTable i = 1 fd = 

Bug#848284: rxvt-unicode-256color: please take over rxvt rxvt-unicode aterm

[Adam Borowski]

Package: rxvt-unicode-256color
Version: 9.22-1+b1
Severity: wishlist

Hi!
Because it's a shame to ship terminals incapable of UTF-8 when a
fully-capable fork exists, please produce dummy transitional packages
that depend on rxvt-unicode-256color:
* rxvt
* rxvt-unicode
* aterm

This has been OKed by rxvt's maintainer, rxvt-unicode is produced by your
source, aterm is orphaned.  All of these come from the same codebase
origins, and none have drastic changes that would make users complain.

As for why -256color, that's a separate issue.  There's no real way to
detect lack of 256 color support: the only terminals with meaningful TERM
variables are "linux" (console) and rxvt variant, everyone else claims to be
"xterm": real xterm, all vte-based (ie, ~80% of terminals in use), konsole,
putty, even Win10 console.  Thus, most new programs simply output these
codes unconditionally, which works reliably everywhere[1] but on rxvt
variants other than -256color.  And you don't have the usage share to
persuade people it's a wrong thing to do.


Meow!

[1]. Well, on Linux and FreeBSD console you get only 16 colors because of
hardware limitations, but those colors get picked closest to what was
requested, which can't be said of rxvt.

Bug#826165: opensc-pkcs11: Signing fails with: PKCS11 function C_SignFinal failed: rv = CKR_GENERAL_ERROR (0x5)

[E]

Здрасти, Жоро,

I have not reported the bug upstream. OpenSC was just updated on Debian
Sid (0.16.0-2) but this issue has not been not fixed.

Since you have the same problem on Slackware, I guess it is not unique
to Debian. If you could report it to the OpenSC developers upstream,
that would be great.

Bug#848281: hp-plugin: downloads plugin for wrong architecture

[Brian Potkin]

On Thu 15 Dec 2016 at 23:26:26 +0100, Guido Günther wrote:

>   hp-plugin -i
> 
> on armv7l the program downloads plugins for i386 nevertheless e.g.
> 
> hbpl1.so:ELF 32-bit LSB shared object, Intel 80386, version 1 
> (SYSV), dynamically linked, stripped
> hbpl1-x86_32.so: ELF 32-bit LSB shared object, Intel 80386, version 1 
> (SYSV), dynamically linked, stripped
> lj.so:   ELF 32-bit LSB shared object, Intel 80386, version 1 
> (SYSV), dynamically linked, not stripped
> lj-x86_32.so:ELF 32-bit LSB shared object, Intel 80386, version 1 
> (SYSV), dynamically linked, not stripped
> 
> although it should download for armhf.

Please take a look at jessie-backports.

Regards,

-- 
Brian.

Bug#831894: systemd: "Out of memory" timing error when calling systemctl in pipeline

[Michael Biebl]

Control: fixed -1 232-7
Hi Brian

thanks for the detail bug report.

On Wed, 20 Jul 2016 09:59:18 -0500 Brian Kroth  wrote:
> 
> Hi, I was trying to do some simple systemctl scripting for some service 
> change rollouts and discovered what looks to be a timing bug related to 
> calling systemctl in a pipeline.
> 
> When called like this we get an "Out of memory." error on most of our VMs, 
> though they certainly have enough free memory available on the system.
> 
> I have not yet observed the issue on a physical machine yet.
> 
> # systemctl list-unit-files | awk '( $1 ~ /inetd.service$/ ) { print $1 }' | 
> xargs -r -t systemctl stop
> systemctl stop inetd.service openbsd-inetd.service 
> Out of memory.
> 
> 
> If on the other hand I do the same thing with either a slightly different 
> (and less heavy weight) systemctl call at the beginning, or else add a short 
> splay before the xargs call, then it works without the error:
> 
> # systemctl list-units | awk '( $1 ~ /inetd.service$/ ) { print $1 }' | xargs 
> -r -t systemctl stop
> systemctl stop inetd.service 
> (no memory error reported)
> 
> # systemctl list-unit-files | awk '( $1 ~ /inetd.service$/ ) { print $1 }' | 
> ( sleep .05; xargs -r -t systemctl stop )
> systemctl stop inetd.service openbsd-inetd.service
> (no memory error reported)
> 
> 
> In case it helps, below is the output of running the first command with the 
> SYSTEMD_LOG_LEVEL=debug environment variable set.
> 
> I've tried to strace it to see where exactly the error turns up, but that 
> seems to disrupt the timing enough that the error message does not appear.
> 
> Let me know if you need any other info.

I can reproduce the issue on jessie, but it seems to work fine on
stretch/sid with v232, so marking the bug accordingly.

I don't consider this issue important enough (especially since it is
fixed in stretch) that I will work on this myself.

If someone wants to dig deeper and finds a fix which is not too
intrusive, this would be great though and I would consider including
this in the next stable point release. A git bisect might help find the
usptream commit which fixed this issue.

Regards,
Michael




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



signature.asc
Description: OpenPGP digital signature

Bug#848283: mon-contrib: non-deterministically shipping one of two sms.alert files

[Reiner Herrmann]

Source: mon-contrib
Version: 1.0+dfsg-3
User: reproducible-bui...@lists.alioth.debian.org
Usertags: fileordering
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi!

While working on the "reproducible builds" effort [1], we have noticed
that mon-contrib could not be built reproducibly.
The source package contains two files named "sms.alert":
- alerts/sms/sms/sms.alert
- alerts/sms/sms.alert

In debian/rules they are both installed to
/usr/lib/mon-contrib/alert.d/sms.alert:
  https://sources.debian.net/src/mon-contrib/1.0%2Bdfsg-3/debian/rules/#L29

But as 'find' returns the list of files in non-deterministic order,
it's also not deterministic which file is finally shipped in the
binary package.

Regards,
 Reiner

[1]: https://wiki.debian.org/ReproducibleBuilds

Bug#832613: kronatools_2.7+dfsg-1_amd64.changes REJECTED

[Andreas Tille]

Hi Thorsten,

On Thu, Dec 15, 2016 at 10:00:10PM +, Thorsten Alteholz wrote:
> 
> according to [1] it is even a word mark, so I don't think it is a good 
> idea to let anything related to diagnostic software with krona in its 
> name into the archive.

Thanks for your torough checking. As discussed long ago[2]

  "KronaTools" may work, since the actual trademark is just "Krona". You could 
also use "Radiant", which was the original name (and still in SourceForge with 
a redirect). We avoided Radiant so our name could be trademarked, but you 
wouldn't have that problem I'm guessing.

It would help to hear other opinions before trying another upload to
new: What name do you think is a proper name for this project in Debian.

Any opinions?

Kind regards

 Andreas.

> [1] 
> https://www.dhs.gov/department-homeland-security-intellectual-property-policy

[2] 
https://lists.alioth.debian.org/pipermail/debian-med-packaging/2016-August/045589.html
https://github.com/marbl/Krona/issues/16 

-- 
http://fam-tille.de

Bug#847018: zfs-dkms: fails to build against kernel version 4.8.0-2-amd64i

[Petter Reinholdtsen]

[Achim Schaefer]
> Maybe you could provide a good source of informations, so I might be
> able to do it.

I notice you already got a good recipe, but just wanted to add that
https://tracker.debian.org/pkg/zfs-linux > is a  good page to use
to find relevant links about the zfs package in Debian.

--
Happy hacking
Petter Reinholdtsen

Bug#833754: xerces-c: FTBFS on s390x with gcc6/icu57

[Bill Blough]

On a whim, I decided to install the Hercules s390 emulator and see if I
could reproduce the problem there.  It's slow (4+ hours to do a build of
xerces) but it appears to work, and the issue shows up there as well.

I started trying to trace down the memory issue in real time, but the
variables I needed to inspect had been optimized out.  As it turns out,
building with reduced/no optimization (I tested both -O1 and -O0) allows
all of the tests to pass except for one (XSValueTest).  Can someone
please confirm this on the porterbox?

Adding

export DEB_BUILD_MAINT_OPTIONS=noopt

to the top of d/rules and rebuilding should do it.

Thanks!

Bug#848229: systemd: Should systemd provide netbase?

[Marco d'Itri]

On Dec 15, Michael Biebl  wrote:

> Having systemd Provides: netbase doesn't really make sense. systemd
> doesn't provide that functionality after all.
Indeed.

> You could ask the netbase maintainer, Marco, though, if he was open to
> drop the Recommends: ifupdown or demote it to Suggests.
> That would seem like a reasonable suggestion to me.
Yes. #824884.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#848282: eyed3: Please add CPE info in d/upstream/metadata

[Petter Reinholdtsen]

Package: eyed3
Version: 0.7.9-1
Severity: wishlist

Please add the eyed3 CPE in d/upstream/metadata.  The value is useful
for mapping CVEs to packages in Debian.  The format is documented in
https://wiki.debian.org/UpstreamMetadata >?  As far as I can tell,
the CPE value should be "cpe:/a:travis_shirk:eyed3".  This is the one
used for the old CVE.

-- 
Happy hacking
Petter Reinholdtsen

Bug#783217: [showq] Crash when saved

[Jaromír Mikeš]

Hi Michael,

I just upload new git snapshot of showq to debian.
Can you please check if this bug still exists or can be closed?

best regards

mira

Bug#705898: [showq] Fader-Cues are broken after interruption with "Escape"

[Jaromír Mikeš]

Hi Michael,

I just upload new git snapshot of showq to debian.
Can you please check if this bug still exists or can be closed?

best regards

mira

Bug#847812: pysolfc: crash on startup

[Markus Koschany]

Control: severity -1 normal
Control: tags -1 unreproducible

On 12.12.2016 00:21, Ben Hildred wrote:
> Package: pysolfc
> Version: 2.0-4
> Severity: grave
> Justification: renders package unusable
> 
> $  pysolfc
> Traceback (most recent call last):
>   File "/usr/games/pysolfc", line 32, in 
> sys.exit(main(sys.argv))
>   File "/usr/share/games/pysolfc/pysollib/main.py", line 359, in main
> r = pysol_init(app, args)
>   File "/usr/share/games/pysolfc/pysollib/main.py", line 196, in pysol_init
> app.loadImages1()
>   File "/usr/share/games/pysolfc/pysollib/app.py", line 712, in loadImages1
> im = loadImage(fn)
>   File "/usr/share/games/pysolfc/pysollib/tile/tkutil.py", line 276, in
> makeImage
> im = PIL_Image(file)
>   File "/usr/share/games/pysolfc/pysollib/tile/tkutil.py", line 254, in
> __init__
> ImageTk.PhotoImage.__init__(self, image)
>   File "/usr/lib/python2.7/dist-packages/PIL/ImageTk.py", line 120, in 
> __init__
> self.paste(image)
>   File "/usr/lib/python2.7/dist-packages/PIL/ImageTk.py", line 187, in paste
> _imagingtk.tkinit(tk.interpaddr(), 1)
> OverflowError: Python int too large to convert to C long

Hello,

pysolfc works fine in Debian testing. There is no startup error on my
system.

Markus Koschany





signature.asc
Description: OpenPGP digital signature

Bug#848281: hp-plugin: downloads plugin for wrong architecture

[Guido Günther]

Source: hplip
Version: 3.14.6-1+b2
Severity: normal

Runnig

  hp-plugin -i

on armv7l the program downloads plugins for i386 nevertheless e.g.

hbpl1.so:ELF 32-bit LSB shared object, Intel 80386, version 1 
(SYSV), dynamically linked, stripped
hbpl1-x86_32.so: ELF 32-bit LSB shared object, Intel 80386, version 1 
(SYSV), dynamically linked, stripped
lj.so:   ELF 32-bit LSB shared object, Intel 80386, version 1 
(SYSV), dynamically linked, not stripped
lj-x86_32.so:ELF 32-bit LSB shared object, Intel 80386, version 1 
(SYSV), dynamically linked, not stripped

although it should download for armhf.
Cheers,
 -- Guido

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

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

Bug#848229: systemd: Should systemd provide netbase?

[Olliver Schinagl]

On 15-12-16 19:43, Michael Biebl wrote:

Am 15.12.2016 um 19:41 schrieb Michael Biebl:

Control: reassign -1 netbase
Control: retitle -1 Drop/Demote recommends on ifupdown

Am 15.12.2016 um 13:17 schrieb Olliver Schinagl:

Package: systemd
Version: 232-3
Severity: normal
File: systemd-networkd

Dear Maintainer,

currently, when installing a small server, with systemd(-sysv),isc-dhcp-
server,openntpd

it pulls in some dependencies, of which one comes from netbase, which is a
dependancy of openntpd.

While the choice ultimatly is with the user, having systemd-networkd and
systemd-resolved, which covers most basic network needs and in theory supplies
netbase. So should systemd not also thus provide netbase?

If a user wants to install other network tools or packages depend on specific
networking packages, they can list them as such, naturally.

Having systemd Provides: netbase doesn't really make sense. systemd
doesn't provide that functionality after all.
I don't know what netbase does and does not provide, but 
systemd-networkd provides pretty much everything you need to setup and 
run (quite an advanced) network these days? So what doesn't systemd provide?


You could ask the netbase maintainer, Marco, though, if he was open to
drop the Recommends: ifupdown or demote it to Suggests.
That would seem like a reasonable suggestion to me.

So I'm reassigning this to netbase and let Marco decide.

Keep in mind though, that ifupdown will likely be installed anyway,
since it has Priority: important


Well I installed a container via debootstrap and minbase and only added 
isc-dhcp-server. Then I decided I wanted  which needs netbase 
and only then it started to pull in ifupdown etc.

Bug#848129: pie-link specs should not be passed when pie is not enabled

[Matthias Klose]

On 15.12.2016 13:27, Guillem Jover wrote:
> Hi!
> 
> On Wed, 2016-12-14 at 12:54:41 +0100, Matthias Klose wrote:
>> Package: dpkg-dev
>> Version: 1.18.15
>> Severity: important
>> Tags: sid stretch
>>
>> This is seen on all architectures where pie is not enabled by default. These
>> specs should not be passed when pie is not in effect.
> 
> I assume you mean enabled by default by gcc.

No, this particular build log doesn't show any -fPIE/-pie flags, so it is
neither enabled by dpkg-buildflags nor by gcc.

>> Seen only when looking at the python2.7 ftbfs on x32.  And verified that
>> the python2.7 build succeeds again when the specs are not passed.
> 
> If python2.7 does not build with the PIE spec files on x32 that means
> that either there's a portability issue on x32 in python2.7, or that
> there's a more fundamental problem with x32 and PIE (f.ex. openssl1.0
> also only fails on x32 with PIE specs, see #845193, although openssl
> builds fine there).
> 
> If the latter, I'd be fine with blacklisting PIE on x32 as "not yet
> working", so that it cannot be enabled at all from the dpkg side.
> (It also might well be that these packages would fail anyway in case
> gcc enabled PIE by default on x32.) Otherwise I guess I'll merge this
> and the other report and probably either reassign to gcc or close.
> 
> 
> The rationale for ending up enabling this globally in dpkg, was that
> enabling this partially in gcc means handling this in packaging is an
> inconsistent mess.
> 
> We'd have some packages building with PIE in some architectures and
> not on others (default hardening build flags option), packages building
> with PIE enabled everywhere using gcc default or dpkg PIE enabling specs
> (with hardening=+pie), or PIE disabled everywhere using PIE disabling
> specs or nothing where gcc does not enable it.
> 
> So we'd need specs files in some places no matter what. And the option
> of just never using specs files, and not making it possible to disable
> PIE for example or enable it on other arches explicily would be
> inconsistent and a pain for maintainers.

Well, Balint asked to enable the pie defaults in GCC. I wasn't aware that more
work regarding the specs was needed.  Ideally these changes should be done in
one place, not in two.

> We've also never enabled hardening flags partially, all hardening
> flags are always enabled as long as they work, otherwise they are just
> globally blacklisted on certain arches, even if the packages requests
> them.

The pie flags are the first ones which have a performance impact, and probably
were never tested on our non-linux targets. So yes, I'm careful to apply these
on each target.  Please live with it that defaults may differ.

I don't think that dpkg-buildflags should have any business passing spec files
for cases where these spec files are not needed.  This is monkey-patching GCC
for unrelated or convenience reasons.  This did go wrong as seen with #843791,
#843826, and now with at least the python2.7 x32 build.  For the latter it is
not important that the build can/should be fixed or being worked around, but
that just passing these specs is causing side effects.  The GCC packages don't
divert dpkg-buildflags either, and I see this in the end as a diversion as well.
 And I can't find any docs about what these specs are supposed to do.

For the upload of the GCC 6.3.0 release candidate I'm ignoring these spec files
when they are not needed.  I think this is the least invasive option for the
upcoming stretch release. A 'note' message is printed when these options are
ignored, so this shouldn't be an issue with any -Werror option either.

> I find the current situation pretty suboptimal TBH. :/

Balint and the release team asked to enable this.  I raised concerns that this
would be too late for the release cycle, but my concerns were ignored (sorry,
can't find this email in a bug report, must be on some ML).  I'm fine to undo
the pie enabling for stretch and work on a better solution for buster if anybody
requests this.  There are plenty of bug reports where people are not happy with
the pie defaults in GCC.

Ideally I'd like to see a solution where no spec file changes are required and
the the appropriate changes are integrated in GCC upstream.

Matthias

Bug#848280: qtltools: please make the build reproducible

[Reiner Herrmann]

Source: qtltools
Version: 1.0+dfsg-1
Severity: wishlist
Tags: patch upstream
User: reproducible-bui...@lists.alioth.debian.org
Usertags: fileordering
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi!

While working on the "reproducible builds" effort [1], we have noticed
that qtltools could not be built reproducibly.
It collects source files with find, which returns files in
undeterministic readdir() order, which causes object files to be linked
in the same undeterministic order.

The attached patch fixes this by sorting the files.

Regards,
 Reiner

[1]: https://wiki.debian.org/ReproducibleBuilds
diff --git a/debian/patches/reproducible_build.patch b/debian/patches/reproducible_build.patch
new file mode 100644
index 000..b38c78b
--- /dev/null
+++ b/debian/patches/reproducible_build.patch
@@ -0,0 +1,16 @@
+Author: Reiner Herrmann 
+Description: Sort source files for deterministic linking order
+
+--- a/Makefile
 b/Makefile
+@@ -27,8 +27,8 @@
+ BFILE=bin/QTLtools
+ HFILE=$(shell find src -name *.h)
+ TFILE=$(shell find lib -name *.h)
+-CFILE=$(shell find src -name *.cpp)
+-OFILE=$(shell for file in `find src -name *.cpp`; do echo obj/$$(basename $$file .cpp).o; done)
++CFILE=$(shell find src -name *.cpp | LC_ALL=C sort)
++OFILE=$(shell for file in `find src -name *.cpp | LC_ALL=C sort`; do echo obj/$$(basename $$file .cpp).o; done)
+ VPATH=$(shell for file in `find src -name *.cpp`; do echo $$(dirname $$file); done)
+ 
+ #DEFAULT VERSION (I.E. UNIGE DESKTOP RELEASE VERSION)
diff --git a/debian/patches/series b/debian/patches/series
index 825a79b..bc92ec2 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1,2 +1,3 @@
 Makefile_config.patch
 Spelling_error.patch
+reproducible_build.patch

Bug#847809: ITP: tcvt -- multicolumn virtual terminal

[Ferenc Wágner]

Adrien CLERC  writes:

> Le 11/12/2016 à 23:39, Ferenc Wágner a écrit :
>
>> * Package name: tcvt
>>   Version : git snapshot 82c24e2
>>   Upstream Author : Helmut Grohne 
>> * URL : http://subdivi.de/~helmut/tcvt/
>
> From the main page:
> Multibyte encodings such as utf8 are not supported, because Python is buggy.
>
> Is that still an issue? I highly doubt that a terminal application that
> doesn't support UTF8 is useful nowadays.

Unfortunately, this is still an issue and indeed limits the
applicability domain of the software.  However, it became feasible to
fix by dropping Python 2 support and work is ongoing now.
-- 
Regards,
Feri

Bug#847651: doomsday: Segfaults at startup

[Markus Koschany]

On Sun, 11 Dec 2016 14:13:46 + James Cowgill 
wrote:
> Control: severity -1 grave
> 
> On 10/12/16 10:16, eingousef wrote:
> > Package: doomsday
> > Version: 1.15.8-3
> > Severity: important
> > 
> > Dear Maintainer,
> > 
> > Doomsday just segfaults at startup, producting to following output :
> > 
> > $ doomsday
> > zsh: segmentation fault  doomsday
> 
> I can confirm this. Doomsday is fairly useless at the moment.

That's true. I had a go at this but I can't figure out what is going
wrong here. A rebuild doesn't resolve the issue.



signature.asc
Description: OpenPGP digital signature

Bug#848279: deprecate InRelease in favor of Release.gpg

[Patrick Schleizer]

Package: apt
Severity: wishlist
X-Debbugs-CC: whonix-de...@whonix.org

In light of CVE-2016-1252...

When there is Release.gpg implemented in apt, why not deprecate InRelease?

Bug#848278: mercurial: hg convert (svn) dies with "abort: No module named builtins!"

[Matti Hamalainen]

Package: mercurial
Version: 3.9.2-1
Severity: normal

Dear Maintainer,

Attempting to run Mercurial's 'convert' function in Debian testing dies with
error "abort: No module named builtins!", at least for Subversion source repos.
I am not certain when or from where this issue comes from, or if it is an issue
with Mercurial package or perhaps Python depencies, but the convert
functionality has certainly worked in
14 November 2016, which is the last time I ran conversion for a certain repo.

An example run with --debugger option plus traceback, without --debugger the
traceback is not shown.

$ hg --debugger convert svn://svn.code.sf.net/p/vice-emu/code/trunk convert-
repo-vice/
entering debugger - type c to continue starting hg or h for help
--Call--
> /usr/lib/python2.7/contextlib.py(21)__exit__()
-> def __exit__(self, type, value, traceback):
(Pdb) c
scanning source...
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/mercurial/dispatch.py", line 204, in
_runcatch
return _dispatch(req)
  File "/usr/lib/python2.7/dist-packages/mercurial/dispatch.py", line 880, in
_dispatch
cmdpats, cmdoptions)
  File "/usr/lib/python2.7/dist-packages/mercurial/dispatch.py", line 637, in
runcommand
ret = _runcommand(ui, options, cmd, d)
  File "/usr/lib/python2.7/dist-packages/mercurial/dispatch.py", line 1010, in
_runcommand
return checkargs()
  File "/usr/lib/python2.7/dist-packages/mercurial/dispatch.py", line 971, in
checkargs
return cmdfunc()
  File "/usr/lib/python2.7/dist-packages/mercurial/dispatch.py", line 877, in

d = lambda: util.checksignature(func)(ui, *args, **cmdoptions)
  File "/usr/lib/python2.7/dist-packages/mercurial/util.py", line 1038, in
check
return func(*args, **kwargs)
  File "/usr/lib/python2.7/dist-packages/hgext/convert/__init__.py", line 391,
in convert
return convcmd.convert(ui, src, dest, revmapfile, **opts)
  File "/usr/lib/python2.7/dist-packages/hgext/convert/convcmd.py", line 611,
in convert
c.convert(sortmode)
  File "/usr/lib/python2.7/dist-packages/hgext/convert/convcmd.py", line 501,
in convert
heads = self.source.getheads()
  File "/usr/lib/python2.7/dist-packages/hgext/convert/subversion.py", line
428, in getheads
rev = optrev(self.last_changed)
  File "/usr/lib/python2.7/dist-packages/hgext/convert/subversion.py", line
116, in optrev
optrev = svn.core.svn_opt_revision_t()
  File "/usr/lib/python2.7/dist-packages/libsvn/core.py", line 2685, in
__init__
except __builtin__.Exception:
  File "/usr/lib/python2.7/dist-packages/mercurial/demandimport.py", line 147,
in __getattribute__
self._load()
  File "/usr/lib/python2.7/dist-packages/mercurial/demandimport.py", line 96,
in _load
mod = _hgextimport(_import, head, globals, locals, None, level)
  File "/usr/lib/python2.7/dist-packages/mercurial/demandimport.py", line 53,
in _hgextimport
return importfunc(name, globals, *args, **kwargs)
ImportError: No module named builtins
> /usr/lib/python2.7/dist-packages/mercurial/demandimport.py(53)_hgextimport()
-> return importfunc(name, globals, *args, **kwargs)
(Pdb) q
abort: No module named builtins!



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

Kernel: Linux 4.8.14-grsec-qcmm (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 mercurial depends on:
ii  libc6 2.24-7
ii  mercurial-common  3.9.2-1
ii  python2.7.11-2
pn  python:any
ii  ucf   3.0036

Versions of packages mercurial recommends:
ii  openssh-client  1:7.3p1-5

Versions of packages mercurial suggests:
pn  kdiff3 | kdiff3-qt | kompare | meld | tkcvs | mgdiff  
pn  qct   

-- no debconf information

Bug#848105: [rt.cpan.org #119235] Bio/Coordinate/Pair.pm removed from BioPerl in version 1.00070001

[Andreas Tille]

On Thu, Dec 15, 2016 at 12:40:01PM -0500, Chris Fields via RT wrote:
> 
> Just a last minute addition, I'm checking in with Lincoln to see if I can 
> attempt a new Bio-Graphics CPAN release (I am apparently still listed as a 
> co-maintainer on PAUSE).

OK, if you would confirm that Bio-Graphics could be brought into a state
that it works with Bio-Coordinate I would reconsider my plan to switch
the Debian packages back to the old series of BioPerl since this would
have been the safest way to ensure that all depenencies in Debian will
work properly. 

Kind regards

  Andreas.

-- 
http://fam-tille.de

Bug#847018: zfs-dkms: fails to build against kernel version 4.8.0-2-amd64i

[Fabian Grünbichler]

On 12/15/2016 10:46 PM, Achim Schaefer wrote:
> Hi Petter,
> 
> I'm not sure how to fetch the git version, so without any hint where to
> start I don't know how to do this.
> 
> Maybe you could provide a good source of informations, so I might be
> able to do it.
> (I've done a much simpler version of the patch in my tree, and got it
> compiled. As well I was able to fetch git repos when someone gave me the
> link to th erepo.
> But I don't know where to search for the repo, I don't know the normal
> debian build procedure, ...
> 
> Achim
> On 15.12.2016 22:12, Petter Reinholdtsen wrote:
>> Control: tags -1 + pending
>>
>> Thank you everyone who contributed to this bug report.  I am afraid the
>> zfs maintainers in Debian is heavily understaffed.  But I found time to
>> fetch the upstream commit and apply it to the Debian git repository.
>>
>> Please test the git version and let us know if it work for you.  I lack
>> the time to test it myself and without testing I do not want to upload
>> it.
> 
> 
> 

did a quick test, packages and module compile without problems,
importing, scrubbing and some regular create/destroy/.. operations also
work as expected. will do some more in-depth testing tomorrow and report
back.

@Achim: you should be able to do the following (after installing git,
git-buildpackage, the build-dependencies of zfsutils-linux and maybe
some other stuff ;)):

$ git clone git://anonscm.debian.org/pkg-zfsonlinux/zfs.git
$ cd zfs
$ git checkout -b testdebiankernelfix
Switched to a new branch 'testdebiankernelfix'
$ gbp dch --debian-branch=testdebiankernelfix
$ sed 's/zfs-linux (0.6.5.8-2)/zfs-linux (0.6.5.8-2~test1)/' -i
debian/changelog
$ git commit -am "update changelog"
$ gbp buildpackage --git-no-pristine-tar
--git-debian-branch=testdebiankernelfix -uc -us

now you should have the following files:

$ ls -1 ../*0.6.5.8-2~test*.deb
../libnvpair1linux_0.6.5.8-2~test1_amd64.deb
../libuutil1linux_0.6.5.8-2~test1_amd64.deb
../libzfs2linux_0.6.5.8-2~test1_amd64.deb
../libzfslinux-dev_0.6.5.8-2~test1_amd64.deb
../libzpool2linux_0.6.5.8-2~test1_amd64.deb
../zfs-dbg_0.6.5.8-2~test1_amd64.deb
../zfs-dkms_0.6.5.8-2~test1_all.deb
../zfs-dracut_0.6.5.8-2~test1_all.deb
../zfs-initramfs_0.6.5.8-2~test1_all.deb
../zfsutils-linux_0.6.5.8-2~test1_amd64.deb
../zfs-zed_0.6.5.8-2~test1_amd64.deb

install the subset of those which you currently have installed (probably
not the dracut, -dbg and -dev ones, maybe not the zfs-zed one, most
likely everything else ;)) with "dpkg -i" and it should trigger a
rebuild of the zfs module during installation.

I replaced the version number such that it is higher than the one
currently in stretch/sid (to make it obvious which one you are using),
but lower than the next regular update by the maintainers (so that that
will not be skipped).

Bug#793372: systemd breaks LXC cgroup memory limitations

[Michael Biebl]

Control: tags -1 + moreinfo

On Sat, 30 Jan 2016 04:00:47 +0100 Michael Biebl  wrote:
> On Wed, 20 Jan 2016 23:43:52 +0100 Carlos Alberto Lopez Perez
>  wrote:
> > On 23/07/15 13:57, Pablo Abelenda wrote:
> > > After this income information, I have switched back both the host and
> > > the container, to sysvinit. With the systems booted on sysvinit, the
> > > memory limitation is working as it is expected.
> > > 
> > 
> > I have been investigating this further and I'm not sure at this point if
> > the bug is on systemd or LXC.
> > 
> > I have posted my findings to the lxc-users mailing list:
> > 
> > http://thread.gmane.org/gmane.linux.kernel.containers.lxc.general/10825
> > 
> 
> So, can you be more specific where the bug in systemd is?

I guess this question is still open. So tagging the bug report accordingly.


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



signature.asc
Description: OpenPGP digital signature

Bug#847018: zfs-dkms: fails to build against kernel version 4.8.0-2-amd64i

[Achim Schaefer]

Hi Petter,

I'm not sure how to fetch the git version, so without any hint where to
start I don't know how to do this.

Maybe you could provide a good source of informations, so I might be
able to do it.
(I've done a much simpler version of the patch in my tree, and got it
compiled. As well I was able to fetch git repos when someone gave me the
link to th erepo.
But I don't know where to search for the repo, I don't know the normal
debian build procedure, ...

Achim
On 15.12.2016 22:12, Petter Reinholdtsen wrote:
> Control: tags -1 + pending
>
> Thank you everyone who contributed to this bug report.  I am afraid the
> zfs maintainers in Debian is heavily understaffed.  But I found time to
> fetch the upstream commit and apply it to the Debian git repository.
>
> Please test the git version and let us know if it work for you.  I lack
> the time to test it myself and without testing I do not want to upload
> it.





smime.p7s
Description: S/MIME Cryptographic Signature

Bug#843638: same problem

[folkert]

I've got this problem as well.

Tried building it from source (apt-get source + dpkg-buildpackage)
but this fails:

libtoolize: copying file 'm4/lt~obsolete.m4'
configure.ac:33: error: possibly undefined macro: AC_PROG_INTLTOOL
  If this token and others are legitimate, please use
m4_pattern_allow.
  See the Autoconf documentation.
autoreconf: /usr/bin/autoconf failed with exit status: 1
dh_autoreconf: autoreconf -f -i returned exit code 1
debian/rules:6: recipe for target 'build' failed

Bug#767885: systemd fails to start services from time to time

[Michael Biebl]

Control: tags -1 + moreinfo

On Mon, 03 Nov 2014 10:45:56 +0100 Andreas Florath 
wrote:
> after upgrading to the latest version of systemd, from time to
> time either services are not started or the system startup hangs
> completely.
> 
> When the system startup hangs, the symptoms are very similar to
> the ones reported in #754218.
> 
> I investigated this problem with different services, like:
> * kbd.service
> * pcscd.service
> * networking.service
> 
> When the system starts and a service was not started, it is also
> not possible to start this manually:
> 
> $ systemctl start kbd.service
> 
> hangs forever (or until a timeout of five minutes).
> 
> The 'strace -f systemctl start xyz.service' output looks always very
> similar.  Find a trace attached.
> 
> The problem occurs on my desktop machine and also on one of my VMs
> (did not upgrade my other VMs yet...)
> 

Hi Andre, sorry for the late reply.

Is this problem still reproducible on an up-to-date sid system?


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



signature.asc
Description: OpenPGP digital signature

Bug#848277: nfs-common: /usr/sbin/start-statd: 10: exec: 200: not found

[Sven Joachim]

Package: nfs-common
Version: 1:1.3.4-1
Severity: important

Even after fixing nfs-config.service (see #848145), I could no longer
use my NFS 3 mounts because rpc.statd failed to start:

,
| /usr/sbin/start-statd: 10: exec: 200: not found
`

That's because dash, unlike bash, does not support file descriptors
higher than 9 in redirection and treats the command as if it had been
"exec 200 > /var/run/rpc.statd.lock".

According to POSIX.1-2008[1], you cannot rely on a number higher than 9
here:

,
| The largest possible value is implementation-defined; however, all
| implementations shall support at least 0 to 9, inclusive, for use by the
| application.
`

Indeed, using 9 rather than 200 actually works.


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

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

Versions of packages nfs-common depends on:
ii  adduser  3.115
ii  init-system-helpers  1.46
ii  keyutils 1.5.9-9
ii  libc62.24-8
ii  libcap2  1:2.25-1
ii  libcomerr2   1.43.3-1
ii  libdevmapper1.02.1   2:1.02.136-1
ii  libevent-2.0-5   2.0.21-stable-2.1
ii  libgssapi-krb5-2 1.15-1
ii  libk5crypto3 1.15-1
ii  libkeyutils1 1.5.9-9
ii  libkrb5-31.15-1
ii  libmount12.29-1
ii  libnfsidmap2 0.25-5
ii  libtirpc10.2.5-1
ii  libwrap0 7.6.q-25
ii  lsb-base 9.20161125
ii  rpcbind  0.2.3-0.5
ii  ucf  3.0036

Versions of packages nfs-common recommends:
ii  python  2.7.11-2

Versions of packages nfs-common suggests:
pn  open-iscsi  
pn  watchdog

-- no debconf information


1. http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html 
(§2.7)

Bug#848249: diffoscope: set_locale needs to call tzset

[Chris Lamb]

Hi Brett,

> So the whole thing with the set_locale test fixture is a little subtle.  The
> best reference I found for this is
> .

Very nice research, thank you. :)

> If you want to make sure it runs before any test, we can do that too.  I've
> attached a patch for that as well.

Applied with thanks. I think this better than relying on the import doing the
right thing, especially as its likely that someone armed with pylint is likely
to remove such an apparent no-op.


Regards,

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